WO2019103157A1

WO2019103157A1 - データ構造、情報送信装置、情報処理装置、制御方法、プログラム及び記憶媒体

Info

Publication number: WO2019103157A1
Application number: PCT/JP2018/043584
Authority: WO
Inventors: 片多　啓二; 幸田　健志
Original assignee: パイオニア株式会社
Priority date: 2017-11-27
Filing date: 2018-11-27
Publication date: 2019-05-31

Abstract

マップ参照テーブルＲＴＭは、端末装置１の記憶部１２に記憶される地図の各々を特定するための参照マップＩＤと、当該参照マップＩＤにより特定される地図に関する情報とを含む。端末装置１は、サーバ装置２と通信セッションを確立した場合に、マップ参照テーブルＲＴＭを含むアップロード情報Ｉｕをサーバ装置２へ送信する。

Description

データ構造、情報送信装置、情報処理装置、制御方法、プログラム及び記憶媒体

　本発明は、車両等の移動体の周辺情報を取得する技術に関する。

　従来から、車両に設置されたセンサの出力に基づき地図データを更新する技術が知られている。例えば、特許文献１には、車両等の移動体に設置されたセンサの出力に基づいて部分地図の変化点を検出した場合に、当該変化点に関する変化点情報をサーバ装置に送信する運転支援装置が開示されている。また、非特許文献１には、車両側のセンサが検出したデータをクラウドサーバで収集するためのデータフォーマットに関する仕様が開示されている。

特開２０１６－１５６９７３号公報

ｈｅｒｅ社ホームページ、Ｖｅｈｉｃｌｅ　Ｓｅｎｓｏｒ　Ｄａｔａ　Ｃｌｏｕｄ　Ｉｎｇｅｓｔｉｏｎ　Ｉｎｔｅｒｆａｃｅ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ｖ２．０．２），［平成２９年１０月２７日検索］、インターネット＜ＵＲＬ：https://lts.cms.here.com/static-cloud-content/Company_Site/2015_06/Vehicle_Sensor_Data_Cloud_Ingestion_Interface_Specification.pdf＞

　各車両で検出した変化点等に関する情報をサーバ装置が収集して地図データの更新等を行うシステムでは、車両側から送信されるデータは、一般的に車がセンサーで計測した地物（路面や停止線、レーンマーカー等の道路構造、道路標識や横断歩道橋などの道路付帯設備、道路周辺の建物などの構造物、路上の車両等のその他）と地図上に記載されている対応する地物を参照して生成される。一方、地図は、作成方針等が異なると地図の内容も異なるものとなる。例えば、個々の地物等の絶対的な位置精度を重視する作成方針の場合と、地物間の相対的な位置関係の精度を重視する作成方針の場合とでは、作成される地図は異なる。また、作成方針が同一、さらには同一のフォーマットの地図であっても地図を作成する時期によっては、地球の地殻変動の影響による位置情報の変化が発生するため内容が異なってくる。従って、車両側から送信されるデータは、当該車両側で参照される地図に依存したデータとなっているため、参照された地図に応じて補正する必要がある。

　ドライバー無しで自動的に運行する自動運転車両や、道路状況に応じてドライバーの運転操作を補助・補正する高度な運転支援車両では、車両に複数の種類のセンサを搭載し、複数の種類の地図を参照する。前述の様に地図は補正・更新されていくので、更新区画ごとにバージョン、作成日が異なる。

　参照した地図を補正する場合は、車両が参照した（利用した）複数の地図の詳細情報を検出した変化点等に関する情報に付随してサーバ装置に送信する。サーバ装置はこれらの情報を該当する地図の補正・更新に利用する。複数の地図の詳細情は、移動体（移動中の車両）から無線通信手段（例：携帯電話通信網）を使って送信する必要があるが、必要なデータ量が大きくなってしまうという課題がある。

　本発明は、上記のような課題を解決するためになされたものであり、検出した物体の情報を各移動体から収集する情報処理装置が各移動体において使用された地図に関する情報を特定するのに好適なデータ構造及び当該データ構造を有するデータの授受を行う情報送信装置及び情報処理装置を提供することを主な目的とする。

　請求項に記載の発明は、移動体に搭載された検出装置が検出した物体に関する情報である検出物体情報を収集する情報処理装置に、前記検出装置が前記物体を検出する際に用いた地図を特定させるために、前記検出物体情報の収集に先立って前記情報処理装置に送信されるデータのデータ構造であって、前記物体を検出する際に前記移動体が利用可能な地図に関する情報と、前記移動体が利用可能な地図の各々を特定するための、前記地図に関する情報と関連付けた地図特定情報と、を含む。

　また、請求項に記載の発明は、情報送信装置であって、記憶部に記憶される地図の各々を特定するための地図特定情報と、当該地図特定情報により特定される地図に関する情報とを含む参照情報を記憶する記憶部と、前記参照情報を、移動体ごとに検出された物体に関する情報である検出物体情報を収集する情報処理装置へ、前記検出物体情報に先立って送信する送信部と、を有する。

　また、請求項に記載の発明は、検出された物体に関する情報である検出物体情報を移動体から収集する情報処理装置であって、移動体が利用可能な地図の各々を特定するための地図特定情報と、当該地図特定情報により特定される地図に関する情報とを含む参照情報を前記移動体から受信する受信部と、前記受信部が受信した参照情報を、当該参照情報を送信した移動体毎に記憶する記憶部と、を有する。

　また、請求項に記載の発明は、情報送信装置が実行する制御方法であって、記憶部に記憶される地図の各々を特定するための地図特定情報と、当該地図特定情報により特定される地図に関する情報とを含む参照情報を、移動体ごとに検出された物体に関する情報である検出物体情報を収集する情報処理装置へ、前記検出物体情報に先立って送信する送信工程と、を有する。

　また、請求項に記載の発明は、検出された物体に関する情報である検出物体情報を移動体から収集する情報処理装置が実行する制御方法であって、移動体が利用可能な地図の各々を特定するための地図特定情報と、当該地図特定情報により特定される地図に関する情報とを含む参照情報を前記移動体から受信する受信工程と、前記受信工程が受信した参照情報を、当該参照情報を送信した移動体毎に記憶部に記憶する記憶工程と、を有する。

　また、請求項に記載の発明は、移動体に搭載された検出装置が検出した物体に関する情報である検出物体情報を収集する情報処理装置が、前記検出装置が前記物体を検出する際に用いた地図を特定するために、前記検出物体情報の取得に先立って受信するデータのデータ構造であって、前記物体を検出する際に前記移動体が利用可能な地図に関する情報と、前記移動体が利用可能な地図の各々を特定するための、前記地図に関する情報と関連付けた地図特定情報と、を含む。

データ収集システムの概略構成である。端末装置及びサーバ装置のブロック構成を示す。端末装置が実行する処理概要を示したブロック図である。マップ参照テーブル及びセンサ参照テーブルのデータ構造の具体例を示す。プラットフォーム参照テーブル及びアルゴリズム参照テーブルのデータ構造の具体例を示す。アップロード情報のデータ構造の概要を示す。車両メタデータのデータ構造を示す。オブジェクト認識イベントのデータ構造を示す。位置推定イベントのデータ構造を示す。メディア情報のデータ構造及びメディアタイプに関する対応表を示す。アップロード情報送信処理のフローチャートである。位置推定イベントの検知処理のフローチャートである。アップロード情報受信処理のフローチャートである。サーバ装置が保有するマップ参照テーブル及び最新状態を反映したマップ参照テーブルの例を示す。第２実施例に係るアップロード情報受信処理のフローチャートである。第２実施例に係る参照テーブル再送処理のフローチャートである。変形例に係るデータ収集システムの概略構成である。変形例に係るオブジェクト認識イベントのデータ構造である。変形例に係るメディア情報のデータ構造である。

　本発明の好適な実施形態によれば、移動体に搭載された検出装置が検出した物体に関する情報である検出物体情報を収集する情報処理装置に、前記検出装置が前記物体を検出する際に用いた地図を特定させるために、前記検出物体情報の収集に先立って前記情報処理装置に送信されるデータのデータ構造であって、前記物体を検出する際に前記移動体が利用可能な地図に関する情報と、前記移動体が利用可能な地図の各々を特定するための、前記地図に関する情報と関連付けた地図特定情報と、を含む。ここで、「検出装置が検出した物体」とは、検出装置が単体で検出処理を行うことで検出された物体に限られず、検出装置の出力データに対して他の装置が所定の解析処理を行うことで検出された物体も含まれる。また、「移動体が利用可能な地図」とは、移動体の制御部等が利用（参照）可能な地図に限らず、移動体に搭載された装置（例えば検出装置又は検出装置の出力データを処理する装置）が利用可能な地図も含まれる。情報処理装置は、このようなデータ構造を有するデータを参照することで、移動体から検出物体情報と共に地図特定情報を受信した場合に、検出物体情報の生成に用いた地図を好適に特定することができる。従って、情報処理装置に対して移動体が利用した地図に関する情報を送信する際のデータ通信量を好適に削減することができる。

　上記データ構造の一態様では、前記地図に関する情報は、前記地図のバージョン、フォーマット、ベンダー、及び名称の少なくともいずれかに関する情報である。情報処理装置は、このようなデータ構造を有するデータを参照することで、移動体から送信された情報に地図特定情報が含まれていた場合に、移動体から送信された検出物体情報を補正するのに必要な地図の情報を好適に特定することができる。

　上記データ構造の一態様では、上記データ構造は、前記検出物体情報の送信前に前記情報処理装置に送信され、前記移動体に関する属性情報をさらに含む。この態様により、移動体は、検出物体情報の送信前において、地図特定情報と地図に関する情報との対応関係を示す情報を、移動体の属性情報と共に好適に情報処理装置に通知することができる。

　本発明の他の好適な実施形態によれば、情報送信装置は、記憶部に記憶される地図の各々を特定するための地図特定情報と、当該地図特定情報により特定される地図に関する情報とを含む参照情報を記憶する記憶部と、前記参照情報を、移動体ごとに検出された物体に関する情報である検出物体情報を収集する情報処理装置へ、前記検出物体情報に先立って送信する送信部と、を有する。この態様では、情報送信装置は、検出物体情報の送信に先立って、利用可能な地図に関する情報と、当該地図を特定するための地図特定情報との対応関係を好適に情報処理装置に通知することができる。これにより、情報送信装置は、例えば、利用した地図に関する情報を、データ通信量の増加を抑制しつつ、地図特定情報により情報処理装置に好適に通知することができる。

　上記情報送信装置の一態様では、前記送信部は、前記参照情報の送信後において、検出した物体に関する検出物体情報と、前記物体を検出する際に利用した地図を特定するための地図特定情報と、を前記情報処理装置へ送信する。これにより、情報送信装置は、検出物体情報の生成に利用した地図の情報を情報処理装置に通知する際のデータ通信量を好適に削減することができる。好適な例では、前記送信部は、前記情報処理装置と通信を確立したときに前記参照情報を送信するとよい。

　本発明の他の好適な実施形態によれば、検出された物体に関する情報である検出物体情報を移動体から収集する情報処理装置であって、移動体が利用可能な地図の各々を特定するための地図特定情報と、当該地図特定情報により特定される地図に関する情報とを含む参照情報を前記移動体から受信する受信部と、前記受信部が受信した参照情報を、当該参照情報を送信した移動体毎に記憶する記憶部と、を有する。この態様によれば、情報処理装置は、利用可能な地図に関する情報と、当該地図を特定するための地図特定情報との対応関係を、移動体ごとに好適に認識することができる。

　上記情報処理装置の一態様では、前記記憶部は、前記参照情報を、前記移動体の識別情報又は前記移動体との通信接続の識別情報と関連付けて記憶する。この態様により、情報処理装置は、通信対象である移動体に対応する参照情報を的確に識別できるように参照情報を記憶することができる。

　上記情報処理装置の他の一態様では、前記受信部は、前記参照情報の受信後、当該参照情報を送信した移動体から前記検出物体情報と前記地図特定情報とを受信し、前記情報処理装置は、前記地図特定情報と、前記参照情報とに基づき、前記物体を検出する際に利用された地図に関する情報を特定する特定部をさらに有する。この態様により、情報処理装置は、検出物体情報の送信元である移動体から受信した参照情報を参照することで、物体を検出する際に利用した地図に関する情報を、検出物体情報と共に送信される地図特定情報に基づき好適に特定することができる。

　上記情報処理装置の他の一態様では、情報処理装置は、前記特定部が特定した地図に関する情報に基づき、前記検出物体情報を補正する補正部をさらに有する。この態様により、情報処理装置は、検出物体情報の生成時に参照された地図の仕様等に依存しない検出物体情報を、好適に取得することができる。

　本発明の他の好適な実施形態によれば、情報送信装置が実行する制御方法であって、記憶部に記憶される地図の各々を特定するための地図特定情報と、当該地図特定情報により特定される地図に関する情報とを含む参照情報を、移動体ごとに検出された物体に関する情報である検出物体情報を収集する情報処理装置へ、前記検出物体情報に先立って送信する送信工程と、を有する。情報送信装置は、この制御方法を実行することで、利用した地図に関する情報を、データ通信量の増加を抑制しつつ、地図特定情報により情報処理装置に通知することが可能となる。

　本発明の他の好適な実施形態によれば、検出された物体に関する情報である検出物体情報を移動体から収集する情報処理装置が実行する制御方法であって、移動体が利用可能な地図の各々を特定するための地図特定情報と、当該地図特定情報により特定される地図に関する情報とを含む参照情報を前記移動体から受信する受信工程と、前記受信工程が受信した参照情報を、当該参照情報を送信した移動体毎に記憶部に記憶する記憶工程と、を有する。情報処理装置は、この制御方法を実行することで、利用可能な地図に関する情報と、当該地図を特定するための地図特定情報との対応関係を、移動体ごとに好適に認識することができる。

　本発明の他の好適な実施形態によれば、プログラムは、上記記載の制御方法を、コンピュータにより実行させる。コンピュータは、このプログラムを実行することで、上記記載の情報送信装置又は情報処理装置として機能する。好適には、上記プログラムは、記憶媒体に記憶される。

　本発明の他の好適な実施形態によれば、移動体に搭載された検出装置が検出した物体に関する情報である検出物体情報を収集する情報処理装置が、前記検出装置が前記物体を検出する際に用いた地図を特定するために、前記検出物体情報の取得に先立って受信するデータのデータ構造であって、前記物体を検出する際に前記移動体が利用可能な地図に関する情報と、前記移動体が利用可能な地図の各々を特定するための、前記地図に関する情報と関連付けた地図特定情報と、を含む。情報処理装置は、このようなデータ構造を有するデータを受信することで、移動体から検出物体情報と共に地図特定情報を受信した場合に、検出物体情報の生成に用いた地図を好適に特定することができる。

　以下、図面を参照して本発明の好適な実施例について説明する。

　＜第１実施例＞
　［データ収集システムの概要］
　図１は、第１実施例に係るデータ収集システムの概略構成である。データ収集システムは、移動体である各車両と共に移動する端末装置１と、各端末装置１とネットワークを介して通信を行うサーバ装置２とを備える。そして、データ収集システムは、各端末装置１から送信された情報に基づき、サーバ装置２が保有する地図を更新する。なお、以後において、「地図」とは、従来の経路案内用の車載機が参照するデータに加えて、ＡＤＡＳ（Ａｄｖａｎｃｅｄ　Ｄｒｉｖｅｒ　Ａｓｓｉｓｔａｎｃｅ　Ｓｙｓｔｅｍ）や自動運転に用いられるデータも含むものとする。

　端末装置１は、サーバ装置２と通信セッションを確立し、アップロード情報「Ｉｕ」をサーバ装置２に送信する。本実施例では、端末装置１は、サーバ装置２と通信セッションを確立した場合に、端末装置１が搭載された車両の属性情報等をアップロード情報Ｉｕに含めてサーバ装置２へ送信する。また、端末装置１は、カメラやライダ（ＬＩＤＡＲ：Ｌａｓｅｒ　Ｉｌｌｕｍｉｎａｔｅｄ　Ｄｅｔｅｃｔｉｏｎ　ａｎｄ　Ｒａｎｇｉｎｇ、Ｌａｓｅｒ　Ｉｍａｇｉｎｇ　Ｄｅｔｅｃｔｉｏｎ　ａｎｄ　ＲａｎｇｉｎｇまたはＬｉＤＡＲ：Ｌｉｇｈｔ　Ｄｅｔｅｃｔｉｏｎ　ａｎｄ　Ｒａｎｇｉｎｇ）などから構成されるセンサ部７の出力に基づき、所定のイベントを検知した場合に、検知したイベントに関する情報（「イベント情報」とも呼ぶ。）をアップロード情報Ｉｕに含めてサーバ装置２へ送信する。上記のイベントは、例えば、自車位置周辺の物体（オブジェクト）の認識に関するイベントである「オブジェクト認識イベント」などが存在する。端末装置１は、イベント情報を含むアップロード情報Ｉｕをサーバ装置２に送信する場合、後述するように、オブジェクト検出等のイベント検出時に使用した地図、センサ等を特定する情報をアップロード情報Ｉｕに付加する。アップロード情報Ｉｕのデータ構造については後述する。ライダなどの外界センサは、検出装置の一例であり、位置情報の生成に用いられる外界センサ、ＧＰＳ受信機、ジャイロセンサなどの自律測位装置等は位置検出装置の一例である。

　なお、端末装置１は、車両に取り付けられた車載機又は車載機の一部であってもよく、車両の一部であってもよい。あるいは、センサ部７を接続することができれば、ノート型ＰＣ等の可搬性のある端末機器であってもよい。端末装置１は、情報送信装置の一例である。

　サーバ装置２は、各端末装置１からアップロード情報Ｉｕを受信して記憶する。サーバ装置２は、例えば、収集したアップロード情報Ｉｕに基づき、後述する地図データの作成基準時点からの変化部分（変化点）を検出し、検出した変化点を反映するための地図データの更新などを行う。サーバ装置２は、情報処理装置の一例である。

　［端末装置の構成］
　図２（Ａ）は、端末装置１の機能的構成を表すブロック図を示す。図２（Ａ）に示すように、端末装置１は、主に、通信部１１と、記憶部１２と、入力部１３と、制御部１４と、インターフェース１５と、出力部１６とを有する。端末装置１内の各要素は、バスライン９８を介して相互に接続されている。

　通信部１１は、制御部１４の制御に基づき、アップロード情報Ｉｕをサーバ装置２へ送信したり、地図ＤＢ４を更新するための地図データをサーバ装置２から受信したりする。また、通信部１１は、車両を制御するための信号を車両に送信する処理、車両の状態に関する信号を車両から受信する処理を行ってもよい。

　記憶部１２は、制御部１４が実行するプログラムや、制御部１４が所定の処理を実行する為に必要な情報を記憶する。本実施例では、記憶部１２は、複数の地図ＤＢ４と、センサデータキャッシュ６と、車両属性情報「ＩＶ」と、複数の参照テーブル「ＲＴ」とを記憶する。

　地図ＤＢ４は、例えば、道路データ、施設データ、及び道路周辺の地物情報などを含むデータベースである。道路データには、経路探索用の車線ネットワークデータ、道路形状データ、交通法規データなどが含まれる。地物情報は、道路標識等の看板や停止線等の道路標示、センターライン等の道路区画線や道路沿いの構造物等の情報を含む。また、地物情報は、自車位置推定に用いるための地物の高精度な点群情報などを含んでもよい。その他、地図ＤＢ４には、位置推定に必要な種々のデータが記憶されてもよい。なお、記憶部１２は、データの種類（道路データ、施設データ、地物情報）ごとに分けられた複数の地図ＤＢ４を記憶してもよく、用途（案内用、自動運転用、障害検知用）等に分けられた複数の地図ＤＢ４を記憶してもよい。

　センサデータキャッシュ６は、センサ部７の出力データ（所謂生データ）を一時的に保持するキャッシュメモリである。車両属性情報ＩＶは、車両の種別、車両ＩＤ、車両長さ、車幅、車高、車両の燃料タイプなどの端末装置１を搭載する車両の属性に関する情報を示す。

　参照テーブルＲＴは、地図ＤＢ４、センサ部７の外界センサ、制御部１４が利用可能なプラットフォーム、制御部１４が実行するアルゴリズムの各々に対し、参照用の識別情報（「参照ＩＤ」とも呼ぶ。）と、それぞれの属性情報とを対応付けたテーブルである。参照テーブルＲＴは、端末装置１とサーバ装置２との通信セッションの確立直後に車両属性情報ＩＶと共にアップロード情報Ｉｕとしてサーバ装置２へ送信される。そして、参照テーブルＲＴは、イベント情報を含むアップロード情報Ｉｕをサーバ装置２が受信した場合に、イベント情報に含まれる参照ＩＤから、イベント検出時に使用された地図ＤＢ４及びセンサの情報等をサーバ装置２が特定するために参照される。参照テーブルＲＴの詳細については［データ構造］のセクションで詳しく説明する。

　入力部１３は、ユーザが操作するためのボタン、タッチパネル、リモートコントローラ、音声入力装置等であり、例えば、経路探索のための目的地を指定する入力、自動運転のオン及びオフを指定する入力などを受け付け、生成した入力信号を制御部１４へ供給する。出力部１６は、例えば、制御部１４の制御に基づき出力を行うディスプレイやスピーカ等である。

　インターフェース１５は、センサ部７の出力データを制御部１４やセンサデータキャッシュに供給するためのインターフェース動作を行う。センサ部７は、ライダ３１やカメラ３２などの車両の周辺環境を認識するための複数の外界センサと、ＧＰＳ受信機３３、ジャイロセンサ３４、ポジションセンサ３５、３軸センサ３６などの内界センサを含む。ライダ３１は、外界に存在する物体までの距離を離散的に測定し、当該物体の表面を３次元の点群として認識し、点群データを生成する。カメラ３２は、車両から撮影した画像データを生成する。ポジションセンサ３５は、各外界センサの位置を検出するために設けられ、３軸センサ３６は、各外界センサの姿勢を検出するために設けられている。なお、センサ部７は、図２（Ａ）に示した外界センサ及び内界センサ以外の任意の外界センサ及び内界センサを有してもよい。例えば、センサ部７は、外界センサとして、超音波センサ、赤外線センサ、マイクなどを含んでもよい。センサ部７に含まれる任意の外界センサは、検出装置として機能する。

　制御部１４は、１または複数のプラットフォーム上で所定のプログラムを実行するＣＰＵなどを含み、端末装置１の全体を制御する。制御部１４は、機能的には、位置推定部１７と、オブジェクト検出部１８と、アップロードデータ生成部１９とを含む。制御部１４は、生成部、送信部、判定部、プログラムを実行するコンピュータ等として機能する。

　図３は、端末装置１の位置推定部１７、オブジェクト検出部１８、及びアップロードデータ生成部１９の処理概要を示したブロック図である。

　位置推定部１７は、センサデータキャッシュ６に保持されているセンサ部７の出力データ及び地図ＤＢ４に基づき、自車位置（車両の姿勢も含む）を推定する。位置推定部１７は、種々の位置推定方法を実行可能となっている。位置推定部１７は、例えば、ＧＰＳ受信機３３及びジャイロセンサ３４等の自立測位センサの出力に基づくデッドレコニング（自律航法）による自車位置推定方法、自律航法に地図ＤＢ４の道路データなどをさらに照合する処理（マップマッチング）を行う自車位置推定方法、周囲に存在する所定のオブジェクト（ランドマーク）を基準としてライダ３１やカメラ３２などの外界センサの出力データと地図ＤＢ４の地物情報が示すランドマークの位置情報とに基づく自車位置推定方法などを実行する。そして、位置推定部１７は、現在実行可能な位置推定方法の中から最も高い推定精度となる位置推定方法を実行し、実行した位置推定方法に基づき得られた自車位置等を示した自車位置情報を、アップロードデータ生成部１９へ供給する。本実施例では、位置推定部１７は、実行した位置推定方法を特定する情報を自車位置情報に含めてアップロードデータ生成部１９へ供給する。

　オブジェクト検出部１８は、センサ部７が出力する点群情報、画像データ、音声データ等に基づき、所定のオブジェクトを検出する。この場合、例えば、オブジェクト検出部１８は、位置推定部１７が推定した自車位置に基づき、センサ部７により検出したオブジェクトに対応する地物情報を地図ＤＢ４から抽出する。そして、オブジェクト検出部１８は、センサ部７により検出したオブジェクトの位置及び形状等と、地図ＤＢ４から抽出した地物情報が示すオブジェクトの位置及び形状等とに違いがある場合、又は、地図ＤＢ４に該当する地物情報が存在しない場合などに、センサ部７により検出したオブジェクトに関する情報（「オブジェクトデータ」とも呼ぶ。）を、アップロードデータ生成部１９へ供給する。

　なお、オブジェクト検出部１８は、センサ部７により検出したオブジェクトと地図ＤＢ４の地物情報が示すオブジェクトとに形状や位置等に違いがあるか否かに関わらず、特定のオブジェクトを検出した場合に、当該オブジェクトに関するオブジェクトデータをアップロードデータ生成部１９へ供給してもよい。例えば、オブジェクト検出部１８は、センサ部７の出力に基づき、道路標識の内容、形状、位置等を認識した場合、又は、車線境界（即ち区画線等）の位置、形状等を認識した場合に、これらの認識結果をオブジェクトデータとしてアップロードデータ生成部１９へ供給してもよい。

　アップロードデータ生成部１９は、位置推定部１７から供給される自車位置情報と、オブジェクト検出部１８から供給されるオブジェクトデータと、センサデータキャッシュ６から供給されるセンサ部６の出力データ（所謂生データ）と、参照テーブルＲＴとに基づき、アップロード情報Ｉｕを生成する。そして、アップロードデータ生成部１９は、生成したアップロード情報Ｉｕを、通信部１１によりサーバ装置２へ送信する。例えば、アップロードデータ生成部１９は、サーバ装置２との通信セッションを確立した場合に、車両属性情報ＩＶ及び参照テーブルＲＴを含むアップロード情報Ｉｕを生成し、生成したアップロード情報Ｉｕを通信部１１によりサーバ装置２へ送信する。また、アップロードデータ生成部１９は、自車位置情報及びオブジェクトデータに基づきイベントが発生したと判定した場合、当該イベントに関するイベント情報を生成し、イベント情報を含むアップロード情報Ｉｕを通信部１１によりサーバ装置２へ送信する。本実施例においてアップロードデータ生成部１９が検出するイベントは、前述した「オブジェクト認識イベント」に加え、自車位置の推定を実施したことに関するイベントである「位置推定イベント」、車線の境界の認識に関するイベントである「車線境界認識イベント」、標識の認識に関するイベントである「標識認識イベント」などがある。なお、車線境界認識イベント及び標識認識イベント等は、オブジェクト認識イベントの一部としてオブジェクト認識イベントに統合されていてもよい。

　［サーバ装置の構成］
　図２（Ｂ）は、サーバ装置２の機能的構成を示すブロック図を示す。図２（Ｂ）に示すように、サーバ装置２は、主に、通信部２１と、記憶部２２と、制御部２３とを有する。サーバ装置２内の各要素は、バスライン９９を介して相互に接続されている。

　通信部２１は、制御部２３の制御に基づき、各端末装置１からアップロード情報Ｉｕを受信したり、地図ＤＢ４を更新するための地図データを各端末装置１へ送信したりする。

　記憶部２２は、制御部２３が実行するプログラムや、制御部２３が所定の処理を実行する為に必要な情報を記憶する。本実施例では、記憶部２２は、配信地図ＤＢ５と、参照テーブルＤＢ８と、イベント情報ＤＢ９とを記憶する。

　配信地図ＤＢ５は、各端末装置１に配信するための地図データであり、各端末装置１から受信するアップロード情報Ｉｕに含まれるイベント情報等に基づき更新が行われる。配信地図ＤＢ５は、地図ＤＢ４と同様、道路データ、施設データ、及び道路周辺の地物情報など、自動運転やＡＤＡＳなどで使用される種々のデータが記録されている。

　参照テーブルＤＢ８は、各端末装置１から受信するアップロード情報Ｉｕに含まれる参照テーブルＲＴを車両ごとに記憶したデータベースである。この場合、参照テーブルＲＴは、送信元である車両の車両ＩＤと関連付けられてもよく、参照テーブルＲＴの送信時に確立された通信セッションのセッションＩＤと関連付けられてもよい。イベント情報ＤＢ９は、各端末装置１から受信するアップロード情報Ｉｕに含まれるイベント情報を記録したデータベースである。イベント情報ＤＢ９に記録されたデータは、例えば、配信地図ＤＢ５の更新に用いられ、所定の統計処理、検証処理等が行われた後に配信地図ＤＢ５に反映される。

　制御部２３は、所定のプログラムを実行するＣＰＵなどを含み、サーバ装置２の全体を制御する。本実施例では、制御部２３は、通信部２１により参照テーブルＲＴを含むアップロード情報Ｉｕを端末装置１から受信した場合に、当該参照テーブルＲＴを車両ごとに参照テーブルＤＢ８に登録する。また、制御部２３は、通信部２１によりイベント情報を含むアップロード情報Ｉｕを端末装置１から受信した場合に、参照テーブルＤＢ８に登録された参照テーブルＲＴを参照することで、送信元の端末装置１がイベント検出に用いた地図、センサ、プラットフォーム、及びアルゴリズムに関する属性情報等を特定する。そして、制御部２３は、特定した地図、センサ、プラットフォーム、及びアルゴリズムに関する属性情報等に基づき、アップロード情報Ｉｕに含まれるイベント情報の補正や信頼度の付加などを行い（例えば、特定のベンダーの地図については信頼性を低く設定したり、既知の誤りがある場合にはイベント情報を補正する等を行う）、補正や信頼度の付加などが行われた後のイベント情報をイベント情報ＤＢ９に登録する。これにより、制御部２３は、イベント情報ＤＢ９を用いた配信地図ＤＢ５の更新時において、各端末装置１がイベント検出時に使用した地図、センサ、プラットフォーム、アルゴリズムの違いに基づく誤差等が生じないように、配信地図ＤＢ５の更新を好適に実行する。制御部２３は、受信部、特定部、補正部、加工部、変換部、プログラムを実行するコンピュータ等として機能する。

　［参照テーブル］
　まず、端末装置１がサーバ装置２に送信する各参照テーブルＲＴについて説明する。

　（１）マップ参照テーブル
　図４（Ａ）は、地図に関する参照テーブルＲＴ（「マップ参照テーブルＲＴＭ」とも呼ぶ。）のデータ構造の具体例を示す。マップ参照テーブルＲＴＭは、端末装置１が記憶する地図ＤＢ４を列挙したテーブルであり、「参照マップＩＤ」、「ベンダー」、「フォーマット」、「バージョン」の各項目を含む。

　「参照マップＩＤ」は、端末装置１が記憶する各地図ＤＢ４に対して割り振られた参照ＩＤであり、図４（Ａ）の例では、参照マップＩＤとして、０からの通し番号が割り振られている。参照マップＩＤは、地図特定情報の一例である。「ベンダー」は、各参照マップＩＤに対応する地図のベンダー（製造元）を特定する情報（例えば会社名など）である。「フォーマット」は、各参照マップＩＤに対応する地図のデータフォーマットを特定する情報である。「バージョン」は、各参照マップＩＤに対応する地図のバージョンを特定する情報である。例えば、図４（Ａ）の例では、参照マップＩＤが「１」の地図ＤＢ４は、「ベンダーＢ」により製造され、「フォーマットＹｆ」によりフォーマットされたバージョン「３」の地図であることを示している。なお、参照マップＩＤが「１」の地図ＤＢ４と参照マップＩＤが「２」の地図ＤＢ４とは、同一のベンダーである「ベンダーＢ」により製造されており、フォーマット及びバージョンがそれぞれ異なっている。なお、マップ参照テーブルＲＴＭの項目は、「参照マップＩＤ」、「ベンダー」、「フォーマット」、「バージョン」に限られず、地図の名称（型番などを含む）を示す項目などが設けられてもよいし、地図の種類・用途としての、道路上の白線の地図情報である白線地図や、標識のみを地図データ化した標識地図などの、地図の種類情報を示す項目などが設けられても良い。

　ここで、端末装置１は、マップ参照テーブルＲＴＭを予め記憶部１２に記憶してもよく、所定のタイミングにより自動で生成又は更新を行ってもよい。後者の場合、例えば、端末装置１は、車両の起動時などの所定のタイミングで、記憶部１２に記憶された地図ＤＢ４に付加された属性情報などを参照することで、各地図ＤＢ４のベンダー、フォーマット、バージョン等を認識し、マップ参照テーブルＲＴＭを自動生成する。マップ参照テーブルＲＴＭは、参照情報の一例である。

　次に、マップ参照テーブルＲＴＭの用途について説明する。端末装置１は、図４（Ａ）に示すマップ参照テーブルＲＴＭを記憶し、通信セッション確立時に車両ＩＤと関連付けてサーバ装置２へ送信する。そして、端末装置１は、イベント検知時には、イベント検知に用いた地図ＤＢ４に対応する参照マップＩＤをイベント情報に含めて車両ＩＤと共にサーバ装置２に送信する。この場合、サーバ装置２は、事前に端末装置１から受信したマップ参照テーブルＲＴＭを参照することで、イベント情報に含まれる参照マップＩＤから、参照された地図のベンダー、フォーマット、バージョンを好適に特定することができる。よって、この場合、端末装置１は、イベント検知の度にサーバ装置２へ送信するイベント情報には、イベント検知に用いた地図ＤＢ４のベンダー、フォーマット、バージョン等の情報として参照マップＩＤを含めればよいため、地図ＤＢ４のベンダー、フォーマット、バージョン等の情報を直接イベント情報に含める場合と比較して、通信量を好適に削減することができる。

　ここで、端末装置１が参照した地図のベンダー、フォーマット、バージョン等の各情報をサーバ装置２に通知する必要性について補足説明する。

　一般に、地図の作成方針は、ベンダー（地図会社）によって異なり、作成方針が異なると地図の内容も異なる。例えば、個々の地物等の絶対的な位置精度を重視する作成方針の場合と、地物間の相対的な位置関係の精度を重視する作成方針の場合とでは、作成される地図は異なるものとなる。同様に、地図のデータフォーマットが異なる場合には、同一ベンダーが作成した場合であっても、作成される地図はデータフォーマットに依存して異なる部分が生じる。従って、同じ緯度経度であっても、異なるベンダー又はデータフォーマットにより作成された地図を参照した場合には、指し示す位置が異なる場合がある。また、地殻変動により、陸地も常に移動するため、同じベンダーの同じデータフォーマットの地図であっても、新しいバージョンの地図と古いバージョンの地図とでは、同じ地物であっても異なる緯度経度が設定されていることがある。

　以上を勘案し、本実施例では、端末装置１は、参照マップＩＤをイベント情報に含めることで、イベント検出時に参照した地図ＤＢ４のベンダー、フォーマット、バージョンの各情報をサーバ装置２に通知する。この場合、サーバ装置２は、特定したベンダー、フォーマット、バージョンに基づき、配信地図ＤＢ５に適用する際に必要な補正処理（正規化処理）をイベント情報に含まれるオブジェクトの位置情報等に対して行う。これにより、サーバ装置２は、端末装置１が参照した地図ＤＢ４と更新対象である配信地図ＤＢ５との作成方針やデータフォーマット等に相違がある場合であっても、配信地図ＤＢ５の更新に好適なデータとなるようにイベント情報を補正して収集することができる。あるいは、更新対象の地図データフォーマットに適用可能なイベント情報のみを取捨選択して活用することができる。

（２）センサ参照テーブル
　図４（Ｂ）は、センサに関する参照テーブルＲＴ（「センサ参照テーブルＲＴＳ」とも呼ぶ。）のデータ構造の具体例を示す。センサ参照テーブルＲＴＳは、イベント検出に用いられる可能性があるセンサ部７の外界センサを列挙したテーブルであり、「参照センサＩＤ」、「タイプ」、「ベンダー」、「モデル」、「ＦＷバージョン」、「センサオフセット」、「センサ方向」、「垂直視野角」及び「水平視野角」の各項目を含む。

　「参照センサＩＤ」は、イベント検出に用いられるセンサ部７の外界センサに対して割り振られた参照ＩＤであり、図４（Ｂ）の例では、参照センサＩＤとして、０からの通し番号が割り振られている。「参照センサＩＤ」は、装置特定情報の一例である。「タイプ」は、各参照センサＩＤに対応するセンサの種別を特定する情報である。ここでは、「タイプ」として、ライダ、カメラ、レーダ、超音波センサの各外界センサが列挙されている。「ベンダー」は、各参照センサＩＤに対応するセンサのベンダー（製造元）を特定する情報（例えば会社名など）である。「モデル」は、各参照センサＩＤに対応するセンサのモデルを特定する情報である。「モデル」は、型番号などのセンサのハードウェアを特定する任意の情報であってもよい。「ＦＷバージョン」は、各参照センサＩＤに対応するセンサのファームウェアのバージョンを特定する情報である。「センサオフセット」は、各参照センサＩＤに対応するセンサの車両中心からの位置を特定する情報である。上述の位置は、例えば、ポジションセンサ３５の出力に基づき特定される。「センサ方向」は、各参照センサＩＤに対応するセンサの車両に対する相対的な方向を特定する情報である。上述の相対的な方向は、例えば、３軸センサ３６の出力に基づき特定される。「垂直視野角」及び「水平視野角」は、各参照センサＩＤに対応するセンサの垂直視野角及び水平視野角を特定する情報である。「タイプ」、「ベンダー」、「モデル」、「センサオフセット」、「センサ方向」、「垂直視野角」及び「水平視野角」において指定される情報は、検出装置情報の一例であり、「ＦＷバージョン」で指定される情報は、ファームウェア情報の一例である。

　このように、センサ参照テーブルＲＴＳには、イベント検出に用いられる可能性があるセンサ部７の各センサに対して、センサのタイプ、ベンダー、モデル、ファームウェアバージョン、設置位置、設置方向、視野角の各情報（即ちセンサのハードウェア及びソフトウェア等に関する情報）と参照センサＩＤとが関連付けられている。なお、端末装置１は、図４（Ｂ）に示すセンサ参照テーブルＲＴＳを予め記憶部１２に記憶してもよく、所定のタイミングにより自動で生成又は更新を行ってもよい。後者の場合、例えば、端末装置１は、車両の起動時などの所定のタイミングで、センサ部７の各センサと通信を行うことで、センサの種別、ハードウェア、ソフトウェア（ファームウェア）、設置位置、設置方向、視野角の各情報を取得し、図４（Ｂ）に示すようなセンサ参照テーブルＲＴＳを生成する。センサ参照テーブルＲＴＳは、参照情報の一例である。

　次に、センサ参照テーブルＲＴＳの用途について説明する。端末装置１は、このようなセンサ参照テーブルＲＴＳを記憶し、通信セッション確立時に車両ＩＤと関連付けてサーバ装置２へ送信する。そして、端末装置１は、イベント検知時には、イベント検知に用いたセンサに対応する参照センサＩＤをイベント情報に含めて車両ＩＤと共にサーバ装置２に送信する。この場合、サーバ装置２は、事前に端末装置１から受信したセンサ参照テーブルＲＴＳを参照することで、イベント情報に含まれる参照センサＩＤから、イベント検出時に使用されたセンサに関する情報を好適に特定することができる。よって、この場合、端末装置１は、イベント検知の度にサーバ装置２へ送信するイベント情報には、イベント検知に用いたセンサのタイプ等の各情報を直接含める必要がないため、通信量を好適に削減することができる。

　ここで、センサのタイプ、ベンダー、モデル、ファームウェアバージョンの各属性（仕様）に関する情報をサーバ装置２に通知する必要性について補足説明する。タイプ、モデル、ファームウェア等が異なるセンサにより、同一オブジェクトを同一位置で測定した場合、測定するセンサ固有のスペック等に起因して、出力データに違いが乗じる。以上を勘案し、本実施例では、端末装置１は、参照マップＩＤをイベント情報に含めることで、イベント検出時に使用したセンサのタイプ、ベンダー、モデル、ファームウェアバージョンの各情報をサーバ装置２に通知する。そして、サーバ装置２は、例えば、特定したセンサのタイプ、モデル、ファームウェア等の情報に基づき、配信地図ＤＢ５に適用する際に必要な補正処理（正規化処理）をイベント情報に含まれる位置情報等に対して行う。

　上述の補正処理として、例えば、サーバ装置２に含まれる制御部２３の補正部は、特定のモデルのライダによるオブジェクトの認識が、他のベンダのセンサによる認識に比べて、オブジェクトの位置（後述するオフセット位置によって示される）を近く認識する傾向にあることが判明している際には、当該特定モデルのライダから取得されたオブジェクトの位置に関する情報を、少し遠くの位置に補正する処理を行うことができる。他の例では、制御部２３の補正部は、センサのタイプ（種類）によるオブジェクト識別の得手、不得手を反映させて認識したオブジェクトの種類（後述するオブジェクトタイプによって示される）を補正することができる。具体的には、「人間」をオブジェクトとして識別した際に、カメラは当該人間の性別を識別しやすいのに対して、ライダは性別の識別には不得手である。そこで、ライダを使ったオブジェクト認識結果として「女性」を識別したとしても、当該認識結果を性別とは無関係の「人間」に補正することで、信頼性の高いデータとすることができる。

　なお、これらのことはセンサのモデル、ファームウェアバージョンについても同様のことが言える。

　これにより、サーバ装置２は、イベント検出時に使用されたセンサの属性等に起因したデータのばらつきを補正し、配信地図ＤＢ５の更新に好適なイベント情報を好適に収集することができる。

　また、上述したセンサのタイプ等の各情報は、当該センサにより検出した情報の信頼度と密接に関連する。よって、例えば、サーバ装置２は、センサ参照テーブルＲＴＳを参照することで特定したセンサのタイプ等の各情報に基づき、受信したイベント情報の信頼度を決定することもできる。例えば、ある特定のセンサの性能ばらつきや計測誤差が大きいことがわかっているような場合には、そのセンサを用いて生成されたデータについては信頼度を下げて処理することが可能である。従って、サーバ装置２は、例えば、センサのタイプ等の各情報と信頼度に関する情報とを対応付けたテーブル等を予め記憶しておく。そして、サーバ装置２は、センサ参照ＩＤが付加されたイベント情報の受信した場合、センサ参照ＩＤからセンサ参照テーブルＲＴＳを用いて特定したセンサのタイプ等の各情報に基づき、信頼度に関する上述のテーブル等を参照し、受信したイベント情報の信頼度を決定する。この場合、サーバ装置２は、例えば、決定した信頼度が所定値以上であるイベント情報が示すオブジェクト検出結果等を、十分信頼できる情報とみなし、他のイベント情報との統計処理などを行うことなく、配信地図ＤＢ５に即時に反映させるといった対応を行う。

　また、この場合、サーバ装置２は、イベント検出時に用いたセンサのタイプ等の各情報に加えて、端末装置１の位置における天候を示した天候情報をさらに勘案してイベント情報の信頼度を決定することもできる。例えば、サーバ装置２は、曇りの場合には、晴天又は雨の場合よりも、ライダの出力に基づくイベント情報の信頼度を上げる。他の例では、サーバ装置２は、晴れの場合には、曇り又は雨の場合よりも、カメラの出力に基づくイベント情報の信頼度を上げる。この場合、サーバ装置２は、各地点の天候を管理するサーバから、端末装置１から送信されるアップロード情報Ｉｕに含まれる位置情報が示す位置の天候情報を受信してもよく、照度センサや雨滴センサなどのセンサ部７の出力を端末装置１から受信することで端末装置１の位置の天候情報を推定してもよい。同様に、サーバ装置２は、イベント情報の生成時での時間帯をさらに勘案してイベント情報の信頼度を決定してもよい。この場合、例えば、サーバ装置２は、夜間の場合には、昼間の場合よりも、カメラの出力に基づき生成されたイベント情報の信頼度を下げる。

　（３）プラットフォーム参照テーブル
　図５（Ａ）は、端末装置１の制御部１４がプログラム等を実行するプラットフォームに関する参照テーブルＲＴ（「プラットフォーム参照テーブルＲＴＰ」とも呼ぶ。）のデータ構造の具体例を示す。プラットフォーム参照テーブルＲＴＰは、イベント検出時に用いられる可能性があるプラットフォームを列挙したテーブルであり、「参照プラットフォームＩＤ」、「ベンダー」、「ＨＷモデル」、「ＦＷバージョン」、「ＳＷバージョン」の各項目を含む。なお、「プラットフォーム」とは端末装置１の制御部１４が例えばオブジェクト認識を実行するプログラムが稼働するハードウェア、及び当該ハードウェアを制御するためのファームウェア、当該ハードウェア上で実行される基本ソフトであるオペレーティングシステム（ＯＳ）等、オブジェクト認識を実行するための基礎的構成を指す。

　「参照プラットフォームＩＤ」は、イベント検出時に用いられる可能性があるプラットフォームに対して割り振られた参照ＩＤであり、図５（Ａ）の例では、参照プラットフォームＩＤとして、０からの通し番号が割り振られている。「ベンダー」は、各参照プラットフォームＩＤに対応するプラットフォームのベンダーを特定する情報であり、「ＨＷモデル」は、各参照プラットフォームＩＤに対応するプラットフォームのハードウェアモデルの情報である。また、「ＦＷバージョン」は、各参照プラットフォームＩＤに対応するプラットフォームのファームウェアのバージョンの情報であり、「ＳＷバージョン」は、各参照プラットフォームＩＤに対応するプラットフォームのソフトウェア（すなわちオペレーティングシステム）のバージョンの情報である。

　このように、プラットフォーム参照テーブルＲＴＰには、イベント検出に用いられる可能性がある各プラットフォームに対して、プラットフォームの属性を特定するための各情報と参照プラットフォームＩＤとが関連付けられている。なお、端末装置１は、マップ参照テーブルＲＴＭ及びセンサ参照テーブルＲＴＳと同様、プラットフォーム参照テーブルＲＴＰを予め記憶部１２に記憶してもよく、所定のタイミングにより自動で生成又は更新を行ってもよい。後者の場合、端末装置１は、プラットフォームをインストールした時点でインストールしたプラットフォームの情報を表すレコードをプラットフォーム参照テーブルＲＴＰに追加してもよい。プラットフォーム参照テーブルＲＴＰは、参照情報の一例である。

　次に、プラットフォーム参照テーブルＲＴＰの用途について説明する。端末装置１は、このようなプラットフォーム参照テーブルＲＴＰを記憶し、通信セッション確立時に車両ＩＤと関連付けてサーバ装置２へ送信する。そして、端末装置１は、イベント検知時には、イベント検知に用いたプラットフォームに対応する参照プラットフォームＩＤをイベント情報に含めて車両ＩＤと共にサーバ装置２に送信する。この場合、サーバ装置２は、事前に端末装置１から受信したプラットフォーム参照テーブルＲＴＰを参照することで、イベント情報に含まれる参照プラットフォームＩＤから、イベント検出時に使用されたプラットフォームに関する属性情報を好適に特定することができる。よって、この場合、端末装置１は、イベント検知の度にサーバ装置２へ送信するイベント情報には、イベント検知に用いたプラットフォームのベンダー等の情報として参照プラットフォームＩＤを含めればよく、プラットフォームに関する各情報を直接含める必要がないため、通信量を好適に削減することができる。そして、例えば、サーバ装置２は、プラットフォーム参照テーブルＲＴＰを参照して参照プラットフォームＩＤから特定したプラットフォームの各情報に基づき、当該参照プラットフォームＩＤが付加されたイベント情報の補正又は／及び当該イベント情報への信頼度の付加などを行う。上述のイベント情報の補正として、例えば、特定のプラットフォームにおいて、オブジェクトを誤認識するバグがある場合、サーバ装置２に含まれる制御部２３の補正部は、当該プラットフォームにおいて認識されたオブジェクトの情報を補正することができる。具体的には、特定のプラットフォームにおいて「人間」の性別を誤認識するバグが既知である場合、サーバ装置２は当該プラットフォームの基で認識された「男性」若しくは「女性」のオブジェクトの情報を、性別とは無関係な「人間」の情報に補正することで信頼性の高いデータとすることができる。他の例では、制御部２３の補正部は、特定プラットフォームの基で認識されたオブジェクトの認識結果の情報に対して、信頼性を低く設定することができる。

　（４）アルゴリズム参照テーブル
　図５（Ｂ）は、端末装置１の制御部１４が実行するアルゴリズムに関する参照テーブルＲＴ（「アルゴリズム参照テーブルＲＴＡ」とも呼ぶ。）のデータ構造の具体例を示す。アルゴリズム参照テーブルＲＴＡは、制御部１４が位置推定イベント、オブジェクト認識イベント、車線境界認識イベントなどの各イベント検出時に用いる可能性があるアルゴリズムを列挙したテーブルであり、「タイプ」、「ベンダー」、「バージョン」の各項目を含む。

　「参照アルゴリズムＩＤ」は、イベント検出時に用いられる可能性があるアルゴリズムに対して割り振られた参照ＩＤであり、図５（Ｂ）の例では、参照アルゴリズムＩＤとして、０からの通し番号が割り振られている。「タイプ」は、各参照アルゴリズムＩＤに対応するアルゴリズムの種類を示す情報である。本実施例では、「タイプ」は、位置推定、オブジェクト認識などのアルゴリズムのカテゴリの情報に加えて、カテゴリ内の種類（方式Ａ、方式Ｂ等）に関する情報も含まれている。「ベンダー」は、各参照アルゴリズムＩＤに対応するアルゴリズムを実現するためのソフトウェアを提供するベンダーを特定する情報であり、「バージョン」は、上記ソフトウェアのバージョンを特定する情報である。

　このように、アルゴリズム参照テーブルＲＴＡには、イベント情報の生成時に実行したアルゴリズムに関する各情報と参照アルゴリズムＩＤとが関連付けられている。なお、アルゴリズム参照テーブルＲＴＡは、アルゴリズムのカテゴリごとに別テーブルとなっていてもよい。例えば、アルゴリズム参照テーブルＲＴＡは、位置推定用のテーブル、オブジェクト認識用のテーブル、車線境界認識用のテーブルを含む複数テーブルから構成されてもよい。

　端末装置１は、アルゴリズム参照テーブルＲＴＡを予め記憶部１２に記憶してもよく、対応するアルゴリズムのソフトウェアをインストールした時点でインストールしたソストウェアの情報に基づきアルゴリズム参照テーブルＲＴＡを更新してもよい。アルゴリズム参照テーブルＲＴＡは、参照情報の一例である。

　次に、アルゴリズム参照テーブルＲＴＡの用途について説明する。端末装置１は、図５（Ｂ）に示すアルゴリズム参照テーブルＲＴＡを記憶し、通信セッション確立時にサーバ装置２へ送信する。そして、端末装置１は、イベント検知時には、イベント検知に用いたアルゴリズムに対応する参照アルゴリズムＩＤをイベント情報に含めてサーバ装置２に送信する。この場合、サーバ装置２は、事前に端末装置１から受信したアルゴリズム参照テーブルＲＴＡを参照することで、イベント情報に含まれる参照アルゴリズムＩＤから、イベント情報生成時に使用されたアルゴリズムの情報を好適に特定することができる。よって、この場合、端末装置１は、イベント検知の度にサーバ装置２へ送信するイベント情報には、イベント検知に用いたアルゴリズムに関する情報として参照アルゴリズムＩＤを含めればよく、アルゴリズムに関する各情報を直接含める必要がないため、通信量を好適に削減することができる。

　一般に、位置推定イベントやオブジェクト認識イベントなどの各イベント検知処理では、適用するアルゴリズムによって、処理結果に対する精度及び信頼性が異なる。また、オブジェクト検出などにおいても、適用するアルゴリズムにより好適に検出可能なオブジェクトと、当該アルゴリズムでは精度良く検出できないオブジェクトとが存在する場合があり、このような場合を勘案した正確な配信地図ＤＢ５の更新処理を行うためには、適用するアルゴリズムの情報が必要となる。以上を勘案し、本実施例では、端末装置１は、参照アルゴリズムＩＤをイベント情報に含めることで、イベント検出時に使用したアルゴリズムに関する各情報をサーバ装置２に通知する。これにより、サーバ装置２は、アルゴリズムに関する情報を、例えば受信したイベント情報の信頼度の算出処理などに好適に用いることができる。

　より具体的には、第１の例では、「自動車」の認識に最適化されたアルゴリズムＩＤ＝２のオブジェクト認識アルゴリズムが、あるオブジェクトを「人間」と認識した場合、当該認識結果に対する信頼度を低く設定することができる。また、第２の例では、「人間」の認識に最適化されたアルゴリズムＩＤ＝３のオブジェクト認識アルゴリズムが、同じオブジェクト（アルゴリズムＩＤ＝２のオブジェクト認識アルゴリズムが「人間」と認識したオブジェクト）を「女性」と認識していた場合、アルゴリズムＩＤ＝２のオブジェクト認識アルゴリズムによる認識結果である「人間」を「女性」に修正する。これにより、アルゴリズムＩＤ＝２のオブジェクト認識アルゴリズムによる認識結果を、より具体的な情報として扱うことができる。

　［アップロード情報のデータ構造］
　次に、アップロード情報Ｉｕのデータ構造の具体例について説明する。以後では、一例として、ｈｅｒｅ社が公開する非特許文献１の仕様書（以後「ヒア仕様書」とも呼ぶ。）に記載の仕様を参考としたアップロード情報Ｉｕのデータ構造について例示する。

　（１）概要
　図６は、端末装置１が送信するアップロード情報Ｉｕのデータ構造の概要を示す図である。図６に示すように、アップロード情報Ｉｕは、ヘッダ情報と、走行経路情報と、イベント情報と、メディア情報とを含む。なお、ヘッダ情報は、ヒア仕様書の「Ｅｎｖｅｌｏｐｅ」に相当し、走行経路情報は、ヒア仕様書の「Ｐａｔｈ」に相当し、イベント情報は、ヒア仕様書の「Ｐａｔｈ　Ｅｖｅｎｔｓ」に相当し、メディア情報は、ヒア仕様書の「Ｐａｔｈ　Ｍｅｄｉａ」に相当する。

　ヘッダ情報（Ｅｎｖｅｌｏｐｅ）は、「バージョン（Ｖｅｒｓｉｏｎ）」、「送信元（Ｓｕｂｍｉｔｔｅｒ）」、「車両メタデータ（ｖｅｈｉｃｌｅＭｅｔａＤａｔａ）」の各項目を含む。なお、括弧内の英語表記はヒア仕様書内での名称を示す。端末装置１は、「バージョン」に、使用されるアップロード情報Ｉｕのデータ構造のバージョンの情報を指定し、「送信元」には、アップロード情報Ｉｕを送信する会社名（車両のＯＥＭ名又はシステムベンダー名）の情報を指定する。また、端末装置１は、「車両メタデータ」に、後述するように、車両属性情報ＩＶの各情報や参照テーブルＲＴの情報を指定する。

　走行経路情報（Ｐａｔｈ）は、「位置推定（Ｐｏｓｉｔｉｏｎ　Ｅｓｔｉｍａｔｅ）」の項目を含む。なお、括弧内の英語表記はヒア仕様書内での名称を示す。端末装置１は、この「位置推定」には、図７を参照して後述するように、位置推定時を示すタイムスタンプ情報の他、推定した緯度、経度、標高の情報、及びこれらの推定精度に関する情報などを指定する。

　イベント情報（Ｐａｔｈ　Ｅｖｅｎｔｓ）は、「位置推定イベント」、「オブジェクト認識イベント（Ｏｂｊｅｃｔ　Ｄｅｔｅｃｔｉｏｎ）」、「標識認識イベント（Ｓｉｇｎ　Ｒｅｃｏｇｎｉｔｉｏｎ）」、「車線境界認識イベント（Ｌａｎｅ　Ｂｏｕｎｄａｒｙ　Ｒｅｃｏｇｎｉｔｉｏｎ）」の各項目を含む。なお、括弧内の英語表記はヒア仕様書内での名称を示し、「位置推定イベント」は、出願人が新たに追加した項目を示す。端末装置１は、位置推定イベントを検知した場合に、その検知結果となる情報を「位置推定イベント」に指定する。「位置推定イベント」には、図９を参照して後述するように、例えば位置推定に適用するアルゴリズム等に関する情報などが指定される。また、端末装置１は、オブジェクト認識イベントを検知した場合に、その検知結果となる情報を「オブジェクト認識イベント」に指定する。「オブジェクト認識イベント」には、図８を参照して後述するように、標識及び車線境界線以外の特定のオブジェクトを検出した際の当該オブジェクトの認識結果に関する情報が指定される。また、端末装置１は、標識認識イベントを検知した場合に、その検知結果となる情報を「標識認識イベント」に指定する。「標識認識イベント」には、例えば標識を検出した際の当該標識の認識結果に関する情報が指定される。また、端末装置１は、車線境界認識イベントを検知した場合に、その検知結果となる情報を「車線境界認識イベント」に指定する。「車線境界認識イベント」には、例えば、車線の境界を検出した際の当該境界の認識結果に関する情報が指定される。なお、これらの「位置推定イベント」、「オブジェクト認識イベント」、「標識認識イベント」、「車線境界認識イベント」の各項目は任意項目となっている。従って、端末装置１は、検知したイベントに対応する項目にのみ、その検知結果となる情報を指定すればよい。「オブジェクト認識イベント」、「標識認識イベント」、又は「車線境界認識イベント」の項目を含むイベント情報は、検出物体情報の一例である。

　メディア情報（Ｐａｔｈ　Ｍｅｄｉａ）は、センサ部７の出力データ（検出情報）である生データを送信する際に使用されるデータタイプである。メディア情報のデータ構造については図１０を参照して後述する。

　（２）車両メタデータ
　図７（Ａ）は、ヘッダ情報に含まれる「車両メタデータ」のデータ構造を示す。図７は、「車両メタデータ」に含まれる要素（サブ項目）ごとに、各要素が必須であるか任意であるかの情報を示している。

　図７（Ａ）に示すように、「車両メタデータ」は、「車両種別（ｖｅｈｉｃｌｅＴｙｐｅＧｅｎｅｒｉｃＥｎｕｍ）」、「車両ＩＤ」、「車両長（ｖｅｈｉｃｌｅＬｅｎｇｔｈ＿ｍ）」、「車幅（ｖｅｈｉｃｌｅＷｉｄｔｈ＿ｍ）」、「車高（ｖｅｈｉｃｌｅＨｅｉｇｈｔ＿ｍ）」、「第１燃料タイプ（ｐｒｉｍａｒｙＦｕｅｌＴｙｐｅ）」、「マップ参照テーブル」、「センサ参照テーブル」、「プラットフォーム参照テーブル」及び「アルゴリズム参照テーブル」の各要素を少なくとも含んでいる。なお、括弧内の英語表記はヒア仕様書内での各要素の名称を示しており、括弧内表記がない「車両ＩＤ」、「マップ参照テーブル」、「センサ参照テーブル」、「プラットフォーム参照テーブル」及び「アルゴリズム参照テーブル」の各項目は、出願人が新たに追加した項目を示す。

　ここで、端末装置１のアップロードデータ生成部１９は、「車両種別」、「車両長」、「車幅」、「車高」、「第１燃料タイプ」等の各要素に、記憶部１２に記憶された車両属性情報ＩＶに基づく情報を指定する。なお、「車両長」、「車幅」、「車高」、「第１燃料タイプ」等の各要素は任意項目であり、車両属性情報ＩＶに対応する情報が存在しない場合などには、情報を指定しない。また、アップロードデータ生成部１９は、「車両ＩＤ」には、記憶部１２に記憶された車両属性情報ＩＶに含まれる車両の識別番号等を指定する。なお、車両ＩＤは、車両に割り当てられた固有のＩＤの他、端末装置１に割り当てられたＩＤであってもよく、車両の所有者を特定するＩＤであってもよい。車両ＩＤは、移動体特定情報の一例である。

　また、アップロードデータ生成部１９は、「マップ参照テーブル」に、記憶部１２に記憶したマップ参照テーブルＲＴＭの情報を指定する。例えば、「マップ参照テーブル」は、マップ参照テーブルＲＴＭのレコードの数によらずに全ての情報を指定できるように、繰り返し構造を有する。

　図７（Ｂ）は、図７（Ａ）の「マップ参照テーブル」が有する要素（サブ要素）と、各サブ要素に格納される情報との対応表を示す。図７（Ｂ）に示すデータ構造では、図４（Ａ）に示すマップ参照テーブルＲＴＭの項目である「参照マップＩＤ」、「ベンダー」、「フォーマット」、「バージョン」を繰り返して指定可能なデータ構造となっている。図７（Ａ）の例では、最初の「参照マップＩＤ」、「ベンダー」、「フォーマット」、「バージョン」のサブ要素には、図４（Ａ）のマップ参照テーブルＲＴＭの１番目のレコードに記録された各情報が指定されており、２回目に繰り返された「参照マップＩＤ」、「ベンダー」、「フォーマット」、「バージョン」のサブ要素には、図４（Ａ）のマップ参照テーブルＲＴＭの２番目のレコードに記録された各情報が指定されている。これにより、アップロードデータ生成部１９は、マップ参照テーブルＲＴＭの情報を好適に「車両メタデータ」に含めることができる。

　アップロードデータ生成部１９は、例えば図７（Ｂ）に示した「マップ参照テーブル」と同様の形式に従い、「センサ参照テーブル」に、記憶部１２に記憶したセンサ参照テーブルＲＴＳの情報を指定し、「プラットフォーム参照テーブル」に、記憶部１２に記憶したプラットフォーム参照テーブルＲＴＰの情報を指定し、「アルゴリズム参照テーブル」に、記憶部１２に記憶したアルゴリズム参照テーブルＲＴＡの情報を指定する。

　このように、「車両メタデータ」の項目に、「マップ参照テーブル」、「センサ参照テーブル」、「プラットフォーム参照テーブル」、「アルゴリズム参照テーブル」の各要素を設けることで、アップロードデータ生成部１９は、サーバ装置２とのセッション確立後に送信するアップロード情報Ｉｕに、各参照テーブルＲＴの情報を好適に含めることができる。なお、「マップ参照テーブル」、「センサ参照テーブル」、「プラットフォーム参照テーブル」、「アルゴリズム参照テーブル」の各要素は任意要素であるため、アップロードデータ生成部１９は、サーバ装置２とのセッション確立から２度目以降に送信するアップロード情報Ｉｕには、「マップ参照テーブル」、「センサ参照テーブル」、「プラットフォーム参照テーブル」、「アルゴリズム参照テーブル」の項目に対応する参照テーブルＲＴを含める必要がない。よって、アップロードデータ生成部１９は、例えば、サーバ装置２とセッションを確立するごとに、各参照テーブルＲＴの情報を一回限り送信すればよい。もしくは、サーバ装置２とセッションが確立し、アップロード情報Ｉｕを各参照テーブルＲＴと共に送信した後、参照テーブルＲＴの内容に変化が生じた際に、アップロード情報Ｉｕに変化が生じた参照テーブルＲＴのみを付して送信することにより、サーバ装置２は最新の参照テーブルを保有することができる。

　（３）オブジェクト認識イベント
　図８は、イベント情報に含まれる「オブジェクト認識イベント」のデータ構造を示す。図８は、「オブジェクト認識イベント」に含まれる要素（サブ項目）ごとに、各要素に対応する情報の指定が必須であるか任意であるかの情報を示している。

　図８に示すように、「オブジェクト認識イベント」は、「タイムスタンプ（ｔｉｍｅＳｔａｍｐＵＴＣ＿ｍｓ）」、「オブジェクトＩＤ（ｄｅｔｅｃｔｅｄＯｂｊｅｃｔＩＤ）」、「オフセット位置（ＰｏｓｉｔｉｏｎＯｆｆｓｅｔ）」、「オブジェクトタイプ（ｏｂｊｅｃｔＴｙｐｅ）」、「オブジェクトサイズ（ｏｂｊｅｃｔＳｉｚｅ＿ｍ）」、「オブジェクトサイズ精度（ｏｂｊｅｃｔＳｉｚｅＡｃｃｕｒａｃｙ＿ｍ）」、「メディアＩＤ（ｍｅｄｉａＩＤ）」、「参照マップＩＤリスト」、「参照センサＩＤリスト」、「参照プラットフォームＩＤリスト」及び「参照アルゴリズムＩＤリスト」の各要素を含んでいる。なお、括弧内の英語表記はヒア仕様書内での各要素の名称を示しており、括弧内表記がない「参照マップＩＤリスト」、「参照センサＩＤリスト」、「参照プラットフォームＩＤリスト」及び「参照アルゴリズムＩＤリスト」の各項目は、出願人が新たに追加した項目を示す。

　端末装置１のアップロードデータ生成部１９は、オブジェクト検出部１８からオブジェクトの検出結果を示すオブジェクトデータを受信した場合に、図８に示すデータ構造を有する「オブジェクト認識イベント」を含むイベント情報を生成する。ここで、アップロードデータ生成部１９は、「タイムスタンプ」にはオブジェクト検出時の時刻を指定し、「オブジェクトＩＤ」には、検出したオブジェクトのオブジェクトＩＤを指定する。なお、オブジェクトＩＤは、例えば、地図ＤＢ４に登録されたオブジェクト（地物）にそれぞれ割り当てられたＩＤであって、例えば各オブジェクトに対応する地物情報に含まれる。また、「オフセット位置」には、アップロードデータ生成部１９は、検出したオブジェクトの車両からの相対位置（例えば緯度差及び経度差等）の情報を指定する。同様に、アップロードデータ生成部１９は、検出したオブジェクトのサイズ情報及び当該サイズの精度情報がオブジェクト検出部１８から供給されるオブジェクトデータに含まれていた場合に、これらの情報を、「オブジェクトサイズ」、「オブジェクトサイズ精度」の各要素に指定する。また、アップロードデータ生成部１９は、センサ部７が出力した画像、ビデオ、点群データなどの生データを送信する必要がある場合に、当該生データに対して付与した識別情報を、「メディアＩＤ」に指定する。そして、「メディアＩＤ」の要素で指定されたメディア（生データ）の詳細情報等については、「メディア情報」の項目に別途格納される。

　「参照マップＩＤリスト」には、アップロードデータ生成部１９は、オブジェクト検出部１８が検出したオブジェクトの検出処理時に参照した１又は複数の地図ＤＢ４を特定するための参照マップＩＤを指定する。この参照マップＩＤは、マップ参照テーブルＲＴＭに規定されており、アップロードデータ生成部１９は、オブジェクトの検出処理に使用した地図ＤＢ４がマップ参照テーブルＲＴＭにおいて該当する参照マップＩＤを、「参照マップＩＤリスト」として指定する。なお、オブジェクトの検出処理時に複数の地図ＤＢ４を参照する可能性を考慮し、「参照マップＩＤリスト」では、複数の参照マップＩＤが指定可能となっている。ここで、マップ参照テーブルＲＴＭは、サーバ装置２との通信セッション確立時に既にサーバ装置２へ送信されている。よって、サーバ装置２は、参照マップＩＤが指定されたイベント情報を含むアップロード情報Ｉｕを受信した場合に、マップ参照テーブルＲＴＭを参照することで、オブジェクト検出に使用した１又は複数の地図ＤＢ４の各々のベンダー、フォーマット、バージョン等を特定することが可能となる。このように、端末装置１は、この参照マップＩＤを「オブジェクト認識イベント」のイベント情報に含めることで、オブジェクト認識イベントの検出時に参照した１又は複数の地図ＤＢ４の各々の属性に関する詳細情報を、最小限のデータ量により好適にサーバ装置２に通知することができる。

　同様に、「参照センサＩＤリスト」には、アップロードデータ生成部１９は、オブジェクト検出部１８が検出したオブジェクトの検出処理に使用したセンサ部７の１又は複数のセンサに対応する参照センサＩＤを指定する。この参照センサＩＤは、センサ参照テーブルＲＴＳに規定されており、アップロードデータ生成部１９は、オブジェクトの検出処理に使用したセンサがセンサ参照テーブルＲＴＳにおいて該当する参照センサＩＤを、「参照センサＩＤリスト」として指定する。なお、オブジェクトの検出処理時に複数のセンサを使用する可能性を考慮し、「参照センサＩＤリスト」では、複数の参照センサＩＤが指定可能となっている。ここで、センサ参照テーブルＲＴＳは、サーバ装置２との通信セッション確立時に既にサーバ装置２へ送信されている。よって、サーバ装置２は、１又は複数の参照センサＩＤが指定されたイベント情報を含むアップロード情報Ｉｕを受信した場合に、センサ参照テーブルＲＴＳを参照することで、オブジェクト検出に使用した各センサのタイプ、ベンダー、モデル、ファームウェアバージョン等を特定することが可能となる。このように、端末装置１は、１又は複数の参照センサＩＤを「オブジェクト認識イベント」のイベント情報に含めることで、オブジェクト認識イベントの検出時に使用した１又は複数のセンサの各々の属性に関する詳細情報を、最小限のデータ量により好適にサーバ装置２に通知することができる。

　さらに、「参照プラットフォームＩＤリスト」には、アップロードデータ生成部１９は、オブジェクト検出部１８が検出したオブジェクトの検出処理に使用した１又は複数のプラットフォームに対応する参照プラットフォームＩＤを指定する。この参照プラットフォームＩＤは、プラットフォーム参照テーブルＲＴＰに規定されており、アップロードデータ生成部１９は、オブジェクトの検出処理に使用したプラットフォームがプラットフォーム参照テーブルＲＴＰにおいて該当する参照プラットフォームＩＤを、「参照プラットフォームＩＤリスト」として指定する。なお、オブジェクトの検出処理時に複数のプラットフォームを使用する可能性を考慮し、「参照プラットフォームＩＤリスト」では、複数の参照プラットフォームＩＤが指定可能となっている。ここで、プラットフォーム参照テーブルＲＴＰは、サーバ装置２との通信セッション確立時に既にサーバ装置２へ送信されている。よって、サーバ装置２は、参照プラットフォ－ムＩＤが指定されたイベント情報を含むアップロード情報Ｉｕを受信した場合に、プラットフォーム参照テーブルＲＴＰを参照することで、オブジェクト検出に使用した各プラットフォームのベンダー、ハードウェアモデル、ファームウェアバージョン、ソフトウェアバージョン等を特定することが可能となる。このように、端末装置１は、１又は複数の参照プラットフォームＩＤを「オブジェクト認識イベント」のイベント情報に含めることで、オブジェクト認識イベントの検出時に使用したプラットフォームの各々の属性に関する詳細情報を、最小限のデータ量により好適にサーバ装置２に通知することができる。

　さらに、「参照アルゴリズムＩＤリスト」には、アップロードデータ生成部１９は、オブジェクト検出部１８が検出したオブジェクトの検出処理に使用したアルゴリズムに対応する１又は複数の参照ＩＤを指定する。この参照アルゴリズムＩＤは、アルゴリズム参照テーブルＲＴＡに規定されており、アップロードデータ生成部１９は、オブジェクトの検出処理に使用したアルゴリズムがアルゴリズム参照テーブルＲＴＡにおいて該当する参照アルゴリズムＩＤを、「参照アルゴリズムＩＤリスト」として指定する。なお、オブジェクトの検出処理時に複数のアルゴリズムを使用する可能性を考慮し、「参照アルゴリズムＩＤリスト」では、複数の参照アルゴリズムＩＤが指定可能となっている。ここで、アルゴリズム参照テーブルＲＴＡは、サーバ装置２との通信セッション確立時に既にサーバ装置２へ送信されている。よって、サーバ装置２は、参照アルゴリズムＩＤが指定されたイベント情報を含むアップロード情報Ｉｕを受信した場合に、アルゴリズム参照テーブルＲＴＡを参照することで、オブジェクト検出に使用した１又は複数のアルゴリズムのタイプ、当該アルゴリズムの処理を実装したソフトウェアのベンダー及びバージョン等を特定することが可能となる。このように、端末装置１は、１又は複数の参照アルゴリズムＩＤを「オブジェクト認識イベント」のイベント情報に含めることで、オブジェクト認識イベントの検出時に使用したアルゴリズムの各々に関する詳細情報を、最小限のデータ量により好適にサーバ装置２に通知することができる。

　ここで、「参照マップＩＤリスト」、「参照センサＩＤリスト」、「参照プラットフォームＩＤリスト」、「参照アルゴリズムＩＤリスト」の各要素は、任意要素となっている。よって、端末装置１は、例えば、これらの参照ＩＤを規定する参照テーブルＲＴのうち、送信していない参照テーブルＲＴが存在する場合などでは、当該参照テーブルＲＴに対応する参照ＩＤについては指定しない。

　（４）位置推定イベント
　図９は、イベント情報に含まれる「位置推定イベント」のデータ構造を示す。図９は、「位置推定イベント」に含まれる要素（サブ項目）ごとに、各要素に対応する情報の指定が必須であるか任意であるかの情報を示している。

　図９に示すように、「位置推定イベント」は、「タイムスタンプ」、「位置推定種別」、「基準オブジェクトＩＤ」、「緯度」、「経度」、「参照マップＩＤ」、「参照センサＩＤ」、「参照プラットフォームＩＤ」、「参照アルゴリズムＩＤ」の各要素を含んでいる。図９の例では、「タイムスタンプ」、「位置推定種別」の各要素は、情報の指定が必須となっており、「基準オブジェクトＩＤ」、「緯度」、「経度」、「参照マップＩＤ」、「参照センサＩＤ」、「参照プラットフォームＩＤ」、「参照アルゴリズムＩＤ」の各要素は、情報の指定が任意となっている。端末装置１のアップロードデータ生成部１９は、位置推定部１７が自車位置の推定を行った場合に、位置推定イベントが発生したと判定し、図９に示すデータ構造を有するイベント情報を生成する。なお、自車位置の推定に関するイベント情報は、自車位置の推定を行うたびに毎回生成する必要はなく、推定結果に大きな変化が生じた場合や、推定に使用したマップ、センサ、プラットフォーム、アルゴリズムに変化が生じた場合にイベント情報を生成するようにしても良い。

　「タイムスタンプ」には、アップロードデータ生成部１９は、位置推定を行った日時を示す情報を指定する。また、「位置推定種別」には、アップロードデータ生成部１９は、ランドマークとなるオブジェクトを基準としない位置推定（「絶対位置推定」とも呼ぶ。）を実行したか、又は、ランドマークとなるオブジェクトを基準とした位置推定（「相対位置推定」とも呼ぶ。）を実行したかの情報を指定する。ここで、絶対位置推定は、外界センサの出力に基づかない位置推定（例えばＧＰＳによる位置推定）を指し、相対位置推定は、外界センサによるオブジェクトの検出データと、地図ＤＢ４に含まれるオブジェクトの位置データとに基づく位置推定を指す。ここでは、アップロードデータ生成部１９は、絶対位置推定を行った場合には、上記要素を「０」とし、相対位置推定を行った場合には、上記要素を「１」に指定する。このように、「位置推定種別」を設けることで、例えば、アップロードデータ生成部１９は、実行した位置推定が外界センサを用いない比較的低精度な絶対位置推定を実行しているか、外界センサの出力を用いた比較的高精度な相対位置推定を実行しているかを好適にサーバ装置２に把握させることができる。また、「位置推定種別」は、後述する「緯度」及び「経度」で指定された位置情報が絶対的な位置を示すか相対的な位置を示すかを判定するために用いることもできる。

　また、「基準オブジェクトＩＤ」には、アップロードデータ生成部１９は、相対位置推定を行った場合に基準としたオブジェクトのオブジェクトＩＤである基準オブジェクトＩＤを指定する。このように、「基準オブジェクトＩＤ」を設けることで、アップロードデータ生成部１９は、位置推定で基準としたオブジェクトをサーバ装置２に好適に通知することができる。そして、例えば、基準オブジェクトＩＤは、後述するように、「緯度」及び「経度」で指定された相対的な位置情報から車両の絶対的な位置（緯度及び経度）を算出するために用いられる。他の例では、基準オブジェクトＩＤは、推定された位置情報の信頼度の設定に用いられてもよい。この場合、サーバ装置２は、例えば、配信地図ＤＢ５等を参照することで、基準オブジェクトＩＤに基づき、位置推定で基準としたオブジェクトの種別等を認識し、認識した種別等から位置推定の信頼度を推定する。例えば、サーバ装置２は、位置推定に好適なオブジェクトが基準オブジェクトＩＤに指定されている場合、信頼性が高い位置推定が行われていると見なし、当該位置推定が行われている間に端末装置１から受信したイベント情報に設定する信頼度を高くする。一方、サーバ装置２は、位置推定に不適なオブジェクトが基準オブジェクトＩＤに指定されている場合、信頼性が比較的低い位置推定が行われていると見なし、当該位置推定が行われている間に端末装置１から受信したイベント情報に設定する信頼度を低くする。同様に、サーバ装置２は、「位置推定種別」に指定された値を、上述の信頼度の設定に用いてもよい。

　「緯度」及び「経度」には、アップロードデータ生成部１９は、位置推定部１７が推定した自車位置の緯度及び経度をそれぞれ指定する。また、アップロードデータ生成部１９は、位置推定部１７により相対位置推定が行われた場合には、基準オブジェクトＩＤで指定したオブジェクトと推定自車位置との緯度及び経度の差（即ち基準オブジェクトに対する緯度差及び経度差）を、「緯度」及び「経度」にそれぞれ指定してもよい。この場合、サーバ装置２は、基準オブジェクトＩＤが示すオブジェクトの緯度及び経度を配信地図ＤＢ５に記憶された地図データのいずれかから取得し、「緯度」及び「経度」にそれぞれ指定された緯度差及び経度差を加算することで、車両の絶対的な位置である緯度及び経度を認識する。なお、基準オブジェクトの緯度及び経度を参照する地図データは、位置推定に関するイベント情報に含まれる参照マップＩＤが示す地図データ（すなわち位置推定に使用した地図データ）と同じにするのが望ましい。

　「参照マップＩＤ」には、アップロードデータ生成部１９は、位置推定部１７が位置推定処理で参照した地図ＤＢ４に対応する参照マップＩＤを指定する。「参照センサＩＤ」には、アップロードデータ生成部１９は、位置推定部１７が位置推定処理で出力データを使用したセンサに対応する参照センサＩＤを指定する。「参照プラットフォームＩＤ」には、アップロードデータ生成部１９は、位置推定部１７による位置推定処理時のプラットフォームに対応する参照プラットフォームＩＤを指定する。「参照アルゴリズムＩＤ」には、アップロードデータ生成部１９は、位置推定部１７が位置推定処理において適用したアルゴリズムに対応する参照アルゴリズムＩＤを指定する。この場合、「参照アルゴリズムＩＤ」には、変更後の位置推定手法のアルゴリズムに対応する参照アルゴリズムＩＤが指定される。なお、「参照マップＩＤ」、「参照センサＩＤ」、「参照プラットフォームＩＤ」、「参照アルゴリズムＩＤ」に代えて、図８で説明したオブジェクト認識イベントのデータ構造と同様、複数のＩＤを指定可能な「参照マップＩＤリスト」、「参照センサＩＤリスト」、「参照プラットフォームＩＤリスト」、「参照アルゴリズムＩＤリスト」が設けられてもよい。

　このように、端末装置１は、各参照ＩＤを「位置推定イベント」のイベント情報に含めることで、位置推定に使用した地図ＤＢ４、センサ、プラットフォーム及びアルゴリズムの詳細情報を、最小限のデータ量により好適にサーバ装置２に通知することができる。

　「位置推定イベント」のデータ構造は、図９に示す構造に限られない。例えば、アップロード情報Ｉｕの「走行経路情報」の「位置推定」の項目内の要素と重複する要素（例えば「緯度」及び「経度」）については、「走行経路情報」の「位置推定」にのみ設けられてもよい。他の例では、「推定位置種別」及び「基準オブジェクトＩＤ」の各要素は、「位置推定イベント」の項目に設けられる代わりに、「走行経路情報」の「位置推定」の項目内に設けられてもよい。

　なお、「オブジェクト認識イベント」及び「位置推定イベント」以外のイベント情報の項目である標識認識イベント及び車線境界認識イベント等についても同様に、ヒア仕様書で規定された各要素に加えて、「参照マップＩＤ」、「参照センサＩＤ」、「参照プラットフォームＩＤ」、「参照アルゴリズムＩＤ」の各要素を新たに設ける。これにより、アップロードデータ生成部１９は、各参照ＩＤをイベント情報内に指定することができるため、イベント情報の生成時に使用した地図ＤＢ４、センサ、プラットフォーム、アルゴリズムに関する詳細情報を、最小限のデータ通信量によりサーバ装置２に通知することができる。

　（５）メディア情報
　図１０（Ａ）は、図６に示されたアップロード情報Ｉｕのメディア情報のデータ構造の一例を示す。図１０（Ａ）は、「メディア情報」に含まれる要素ごとに、各要素に対応する情報の指定が必須であるか任意であるかの情報を示している。

　図１０（Ａ）に示すように、「メディア情報」は、「タイムスタンプ（Ｔｉｍｅｓｔａｍｐ）」、「メディアタイプ（Ｍｅｄｉａ　Ｔｙｐｅ）」、「メディアフォーマット（ＭｅｄｉａＦｏｒｍａｔ）」、「メディアコンテンツ（ＭｅｄｉａＣｏｎｔｅｎｔ）」、「メディアＩＤ（ＭｅｄｉａＩＤ）」、「参照センサＩＤ」、「センサオフセット（ＳｅｎｓｏｒＯｆｆｓｅｔ）」、「センサ方向（Ｓｅｎｓｏｒ　Ｄｉｒｅｃｔｉｏｎ）」、「メディアコンテンツ時間（Ｍｅｄｉａ　Ｃｏｎｔｅｎｔ　Ｄｕｒａｔｉｏｎ）」、「センサ垂直視野角（Ｓｅｎｓｏｒ　Ｖｅｒｔｉｃａｌ　Ｖｉｅｗｉｎｇ　Ａｎｇｌｅ）」、「センサ水平視野角（Ｓｅｎｓｏｒ　Ｈｏｒｉｚｏｎｔａｌ　Ｖｉｅｗｉｎｇ　Ａｎｇｌｅ）」、「センサロール角」、「センサピッチ角」及び「センサヨー角」の各要素を含んでいる。なお、括弧内の英語表記はヒア仕様書内での各要素の名称を示しており、括弧内表記がない「参照センサＩＤ」、「センサロール角」、「センサピッチ角」、及び「センサヨー角」の各項目は、出願人が新たに追加した項目を示す。また、図１０（Ａ）の例では、「タイムスタンプ」、「メディアコンテンツ」、「メディアＩＤ」の各要素は、情報の指定が必須となっており、他の各要素は、情報の指定が任意となっている。なお、「メディアコンテンツ」としては、静止画像、動画像、音声、その他センサーで取得した生データ、もしくはその加工データが例示できる。

　「タイムスタンプ」には、アップロードデータ生成部１９は、送信するメディアコンテンツ（生データ）を生成した日時を示す情報を指定する。「メディアタイプ」及び「メディアフォーマット」には、アップロードデータ生成部１９は、送信する生データの種類及びフォーマットの情報を指定する。「メディアコンテンツ」には、アップロードデータ生成部１９は、送信すべき生データのバイナリデータを格納する。「メディアＩＤ」には、アップロードデータ生成部１９は、送信する生データの識別情報であって、図８に示した「オブジェクト認識イベント」等のイベント情報で指定したメディアＩＤを指定する。「メディアコンテンツ時間」には、アップロードデータ生成部１９は、送信する生データがビデオなどの時間軸を有するメディアである場合に、当該メディアの時間長の情報を指定する。

　「参照センサＩＤ」には、アップロードデータ生成部１９は、送信する生データを出力したセンサがセンサ参照テーブルＲＴＳにおいて対応付けられている参照センサＩＤの情報を指定する。このように、アップロードデータ生成部１９は、メディア情報に参照センサＩＤの情報を含めることで、送信する生データの取得に利用したセンサの種別、ベンダー、ハードウェア、ソフトウェア（ファームウェア）、設置位置、設置方向、視野角の各情報をサーバ装置２に好適に通知することができる。サーバ装置２は、この場合、生データの取得に利用したセンサの種別、ベンダー、ハードウェア、ソフトウェア（ファームウェア）の各情報に基づき、受信した生データの加工処理を行う。上述の加工処理として、例えば、サーバ装置２は、メディア情報が、ある特定のカメラで撮影された画像である場合に、所定の画像処理を施して解像度を変化させたり、コントラストを調整して、画像認識処理において利用しやすくすることができる。他の例では、サーバ装置２は、メディアデータを取得した外界センサがマイクである場合、メディアデータであるオーディオデータを当該マイクのベンダーや機種の違いに起因する音響特性を抑えたオーディオデータに補正することができる。また、参照センサＩＤにより特定されるセンサの設置位置等の情報については、後述するように、センサを基準とした座標系から絶対的な座標系に生データの座標系を変換する処理等に使用される。なお、「参照センサＩＤ」の代わりに、生データの取得に利用したセンサの種別、ベンダー、ハードウェア、ソフトウェア（ファームウェア）、設置位置、設置方向、視野角の各情報をそれぞれ個別に指定可能な要素がメディア情報に設けられてもよい。

　「センサロール角」には、アップロードデータ生成部１９は、送信する生データを出力したセンサの車両に対するロール角の情報を指定する。「センサピッチ角」には、アップロードデータ生成部１９は、送信する生データを出力したセンサの車両に対するピッチ角の情報を指定する。「センサヨー角」には、アップロードデータ生成部１９は、送信する生データを出力したセンサの車両に対するヨー角の情報を指定する。アップロードデータ生成部１９は、これらのセンサのロール角、ピッチ角、ヨー角の情報を、例えば３軸センサ３６の出力に基づき特定する。

　図１０（Ｂ）は、「メディアタイプ」において指定する番号とメディアタイプとの対応表を示す。図１０（Ｂ）の例では、番号２には画像、番号３にはビデオ、番号４にはオーディオ、番号５にはライダデータ、番号１にはその他のメディアタイプがそれぞれ対応付けられている。

　ここで、メディア情報に「センサロール角」、「センサピッチ角」及び「センサヨー角」の各要素が設けられていることの効果について補足説明する。

　一般に、センサ部７のセンサが出力する生データは、当該センサを基準としたローカル座標系に基づくデータであり、対象とするセンサの位置及び姿勢に依存する。従って、サーバ装置２は、このような生データを事後的に解析してオブジェクト認識などを行う場合、対象の生データを、センサの位置及び姿勢の情報に基づき、車両を基準とした車両座標系に変換し、さらに走行経路情報などに含まれる車両の位置及び姿勢の情報に基づき、絶対座標系に変換する必要がある。一方、センサを基準とした座標系から車両を基準とした座標系等に変換する場合、参照センサＩＤにより特定されるセンサの設置位置の情報（即ち図４（Ｂ）の「センサオフセット」の情報）及びセンサの設置方向の情報（即ち図４（Ｂ）の「センサ方向」の情報）のみでは、ロール方向の情報などが含まれておらず、正確な座標変換を行うことができない。以上を勘案し、本実施例では、メディア情報に「センサロール角」、「センサピッチ角」及び「センサヨー角」の各要素を設け、端末装置１からサーバ装置２に生データを送信する際に、使用したセンサのロール角、ピッチ角、ヨー角の情報を指定可能なデータ構造とする。これにより、サーバ装置２は、端末装置１から受信する生データをメディア情報の各要素に基づき絶対座標系のデータに変換することが可能となり、絶対座標系で表された配置地図ＤＢ５の更新に好適に用いることができる。

　なお、「センサロール角」、「センサピッチ角」及び「センサヨー角」の各要素には、車両に対する相対的なロール角、ピッチ角、ヨー角の情報が指定される代わりに、絶対的な角度を示すロール角、ピッチ角、ヨー角の情報が指定されてもよい。この場合、例えば、端末装置１は、生データを出力するセンサに設けられた３軸センサ３６や方位センサ等のセンサ部７の出力に基づき、「センサロール角」及び「センサピッチ角」に、水平面に対するセンサのロール角及びピッチ角の情報を指定し、「センサヨー角」には、センサが向けられた方位の情報を指定する。この場合であっても、サーバ装置２は、センサを基準とした座標系から絶対的な座標系に生データの座標系を変換するために必要な情報を、好適に端末装置１に通知することができる。

　［処理フロー］
　次に、端末装置１及びサーバ装置２が実行する処理フローについて説明する。

　（１）アップロード情報送信処理
　図１１は、端末装置１が実行するアップロード情報Ｉｕの送信に関するフローチャートである。

　まず、端末装置１は、サーバ装置２と通信セッションを確立したか否か判定する（ステップＳ１０１）。そして、端末装置１は、サーバ装置２と通信セッションを確立した場合（ステップＳ１０１；Ｙｅｓ）、各参照テーブルＲＴ及び車両属性情報ＩＶを含むアップロード情報Ｉｕをサーバ装置２へ送信する（ステップＳ１０２）。この場合、端末装置１は、例えばアップロード情報Ｉｕが図６に示したデータ構造を有する場合、各参照テーブルＲＴ及び車両属性情報ＩＶを、ヘッダ情報に含まれる「車両メタデータ」の各要素として指定したアップロード情報Ｉｕをサーバ装置２へ送信する。

　次に、端末装置１は、所定のイベントを検知したか否か判定する（ステップＳ１０３）。例えば、端末装置１は、センサ部７の出力に基づき、イベント情報として送信すべきイベント（位置推定イベント、オブジェクト認識イベント等）が発生したか否か判定する。なお、位置推定イベントの検知処理の具体例については、図１２を参照して後述する。

　そして、端末装置１は、イベントを検知した場合（ステップＳ１０３；Ｙｅｓ）、イベント検知時に使用した地図ＤＢ４、センサ、プラットフォーム、及びアルゴリズムに対応する参照ＩＤを各参照テーブルＲＴに基づき特定し、当該各参照ＩＤを含むイベント情報を生成する（ステップＳ１０４）。この場合、端末装置１は、各参照テーブルＲＴに基づき特定した参照ＩＤの情報を、位置推定イベント、オブジェクト認識イベントなどに対応するイベント情報の「参照マップＩＤ」、「参照センサＩＤ」、「参照プラットフォームＩＤ」、「参照アルゴリズムＩＤ」の各要素において指定する。

　次に、端末装置１は、センサ部７の特定のセンサが出力する生データを送信するか否か判定する（ステップＳ１０５）。そして、端末装置１は、生データを送信する場合（ステップＳ１０５；Ｙｅｓ）、ポジションセンサ３５や３軸センサ３６の出力等に基づき、送信する生データを出力するセンサの位置及び姿勢等を検出する（ステップＳ１０６）。これにより、端末装置１は、図１０（Ａ）に示すメディア情報の「センサオフセット」、「センサロール角」、「センサピッチ角」及び「センサヨー角」等に指定すべき情報を特定する。そして、端末装置１は、生データを含むメディア情報を生成する（ステップＳ１０７）。

　そして、端末装置１は、アップロード情報Ｉｕをサーバ装置２へ送信する（ステップＳ１０８）。ここで、端末装置１は、生データを送信しない場合（ステップＳ１０５；Ｎｏ）、ステップＳ１０４で生成したイベント情報を含むアップロード情報Ｉｕをサーバ装置２へ送信する。一方、端末装置１は、ステップＳ１０７でメディア情報を生成した場合には、イベント情報及びメディア情報を含むアップロード情報Ｉｕをサーバ装置２へ送信する。なお、端末装置１は、イベント情報とメディア情報とを異なるタイミングで送信してもよい。例えば、端末装置１は、イベント情報を含むアップロード情報ＩｕをステップＳ１０４の直後にサーバ装置２へ送信した後、ステップＳ１０７で生成したメディア情報を別途サーバ装置２へ送信してもよい。

　次に、端末装置１は、サーバ装置２との通信セッションが切断されたか否か判定する（ステップＳ１０９）。そして、端末装置１は、サーバ装置２との通信セッションが切断された場合（ステップＳ１０９；Ｙｅｓ）、フローチャートの処理を終了する。一方、端末装置１は、サーバ装置２との通信セッションが切断されていない場合（ステップＳ１０９；Ｎｏ）、ステップＳ１０３へ処理を戻し、再びイベントの検知を行う。

　（２）位置推定イベント検知処理
　図１２は、位置推定イベントの検知処理の具体例を示したフローチャートである。端末装置１は、図１２のフローチャートの処理を、図１１のステップＳ１０３のイベント検知の判定処理の一部として実行する。

　まず、端末装置１は、現時点において実行可能な位置推定方法を特定する（ステップＳ２０１）。例えば、端末装置１は、ＧＰＳ受信機３３及びジャイロセンサ３４等の自立測位センサの出力に基づくデッドレコニングによる自車位置推定方法、自律航法とマップマッチングとを組み合わせて自車位置を推定する方法、ライダ３１やカメラ３２などの出力と地図ＤＢ４の地物情報とを照合させて自車位置を推定する方法など、予め定められた複数の自車位置推定方法のうち、現時点で実行可能な位置推定方法を特定する。例えば、端末装置１は、各位置推定方法に用いる各センサが正常に動作しているか否か、マップマッチングの可否、位置推定において基準とするオブジェクトの存否などを判定することで、現時点で実行可能な位置推定方法を特定する。

　そして、端末装置１は、ステップＳ２０１で特定した、現時点で実行可能な位置推定方法のうち、最も高精度な位置推定を実行する（ステップＳ２０２）。この場合、例えば、各位置推定方法には、位置推定精度に基づく優先順位などが予め定められており、端末装置１は、この優先順位に基づき、現時点で実行可能な位置推定方法のうち、最も高精度な位置推定方法を特定する。なお、上述の優先順位は、天候や道路種別などの外部環境によって異なってもよい。

　次に、端末装置１は、位置推定方法の切り替えが必要か否か判定する（ステップＳ２０３）。例えば、端末装置１は、ステップＳ２０１と同様の処理を行うことで、現時点で実行可能な位置推定方法を特定し、現在の位置推定方法よりも高精度な位置推定方法が実行可能となった場合、又は、現在の位置推定方法の実行が継続できなくなった場合に、位置推定方法の切り替えが必要と判断する。

　そして、位置推定方法の切り替えが必要である場合（ステップＳ２０３；Ｙｅｓ）、端末装置１は、位置推定方法の切り替えを行う（ステップＳ２０４）。そして、端末装置１は、位置推定イベントが発生したと判定する（ステップＳ２０５）。その後、端末装置１は、図１１のステップＳ１０４以降の処理を実行することで、図９で説明したデータ構造を有する位置推定イベントのイベント情報を含むアップロード情報Ｉｕを生成し、サーバ装置２へ生成したアップロード情報Ｉｕを送信する。なお、端末装置１は、実行する位置推定方法に変更がない場合であっても、相対位置推定において基準とするオブジェクトに変更があった場合、即ち位置推定イベントの「基準オブジェクトＩＤ」に指定すべきオブジェクトに変更があった場合には、位置推定イベントのイベント情報を含むアップロード情報Ｉｕの生成及び送信を行ってもよい。

　一方、位置推定方法の切り替えが必要でない場合（ステップＳ２０３；Ｎｏ）、端末装置１は、引き続きステップＳ２０３の判定処理を行う。

　（３）アップロード情報受信処理
　図１３は、サーバ装置２が実行するアップロード情報Ｉｕの受信処理の手順を示したフローチャートである。

　まず、サーバ装置２は、端末装置１からの接続要求があるか否か判定する（ステップＳ３０１）。そして、サーバ装置２は、接続要求があった場合（ステップＳ３０１；Ｙｅｓ）、端末装置１と通信セッションを確立し、参照テーブルＲＴや車両属性情報ＩＶを含むアップロード情報Ｉｕを端末装置１から受信する（ステップＳ３０２）。その後、サーバ装置２は、受信したアップロード情報Ｉｕから各参照テーブルＲＴを抽出し、端末装置１との間で確立した通信セッションのセッションＩＤ又はアップロード情報Ｉｕに含まれる車両ＩＤと関連付けて参照テーブルＤＢ８に記憶する（ステップＳ３０３）。これにより、サーバ装置２は、通信を確立したそれぞれの端末装置１から送信される参照テーブルＲＴを、端末装置１毎（即ち車両毎）に記憶することができる。

　次に、サーバ装置２は、通信セッションを確立した端末装置１からイベント情報を含むアップロード情報Ｉｕを受信する（ステップＳ３０４）。そして、サーバ装置２は、アップロード情報Ｉｕに含まれるイベント情報をイベント情報ＤＢ９に記録する。

　次に、サーバ装置２は、通信セッションを確立した端末装置１との通信セッションが切断されたか否か判定する（ステップＳ３０５）。そして、サーバ装置２は、通信セッションが切断されたと判断した場合（ステップＳ３０５；Ｙｅｓ）、通信セッションが切断された端末装置１とのセッションＩＤと関連付けられた参照テーブルＲＴを参照テーブルＤＢ８から削除する（ステップＳ３０６）。なお、サーバ装置２は、車両ＩＤと関連付けられた参照テーブルＲＴの送信元の端末装置１と通信セッションが切断された場合には、当該参照テーブルＲＴを参照テーブルＤＢ８から削除しなくともよい。この場合、参照テーブルＤＢ８から削除されずに残った参照テーブルＲＴは、送信元の端末装置１が再度サーバ装置２と通信セッションを確立した場合に、サーバ装置２により再び参照される。このように、前に確立した通信セッションにおいて受信した参照テーブルＲＴが参照テーブルＤＢ８に記録されている場合には、サーバ装置２は、各参照テーブルＲＴをステップＳ３０２で端末装置１から受信する処理、及び、ステップＳ３０３で参照テーブルＤＢ８に各参照テーブルＲＴを記憶する処理を実行しなくともよい。

　一方、通信セッションを確立した端末装置１との通信セッションが切断されていない場合（ステップＳ３０５；Ｎｏ）、サーバ装置２は、ステップＳ３０４において、引き続き端末装置１からイベント情報を含むアップロード情報Ｉｕの受信処理を行う。

　ここで、サーバ装置２がステップＳ３０４でイベント情報を含むアップロード情報Ｉｕを受信した際に実行する処理について具体的に説明する。

　例えば、サーバ装置２は、イベント情報に参照マップＩＤが含まれる場合には、参照テーブルＤＢ８から対応するマップ参照テーブルＲＴＭを参照することで端末装置１が参照した地図ＤＢ４のベンダー、フォーマット、バージョンを特定する。サーバ装置２は、更新対象の配信地図ＤＢ５に記憶された地図と、端末装置１が参照する地図ＤＢ４に記憶された各種の地図との差分に関する情報を把握している。これにより、サーバ装置２は、端末装置１が使用した地図ＤＢ４と更新対象の配信地図ＤＢ５とのずれ分を認識し、当該ずれ分だけ位置情報等を修正したイベント情報をイベント情報ＤＢ９に記録する。従って、この場合、サーバ装置２は、端末装置１が使用した地図ＤＢ４の属性に依存しないイベント情報を収集し、配信地図ＤＢ５の更新に用いることができる。

　また、サーバ装置２は、イベント情報に参照センサＩＤが含まれる場合には、参照テーブルＤＢ８から対応するセンサ参照テーブルＲＴＳを参照することで端末装置１がイベントを検知した時に使用したセンサのタイプ、ベンダー、モデル、ファームウェアバージョンなどのセンサの属性を認識する。そして、サーバ装置２は、認識したセンサの属性に応じた補正処理を、オブジェクト認識結果等を示すイベント情報に対して行い、補正後のイベント情報をイベント情報ＤＢ９に記録する。これにより、サーバ装置２は、イベント検出に使用したセンサのタイプ、モデル等の属性に依存しないようにイベント情報を補正し、配信地図ＤＢ５の更新に好適なイベント情報を収集することができる。また、サーバ装置２は、認識したセンサの属性に応じた信頼度の情報をイベント情報に付加し、イベント情報ＤＢ９に登録してもよい。

　同様に、サーバ装置２は、イベント情報に参照プラットフォームＩＤが含まれる場合には、参照テーブルＤＢ８から対応するプラットフォーム参照テーブルＲＴＰを参照することで端末装置１がイベント検出時に使用したプラットフォームのベンダー、モデルなどの属性を認識し、その認識結果に応じて、イベント情報の補正又は／及びイベント情報への信頼度の付加などを行う。また、サーバ装置２は、イベント情報に参照アルゴリズムＩＤが含まれる場合には、参照テーブルＤＢ８から対応するアルゴリズム参照テーブルＲＴＡを参照することで、端末装置１がイベント検出時に使用したアルゴリズムに関する情報を認識し、その認識結果に応じて、イベント情報の補正又は／及びイベント情報への信頼度の付加などを行う。

　また、生データを含むメディア情報を有するアップロード情報Ｉｕを受信した場合、サーバ装置２は、メディア情報の参照センサＩＤからセンサ参照テーブルＲＴＳを参照することで、生データを取得したセンサのタイプ、ベンダー、モデル、ファームウェアバージョンなどの属性を特定し、これらのセンサの属性を勘案して生データの加工処理を行う。これにより、サーバ装置２は、生データを取得したセンサの属性を勘案し、生データを好適に加工することができる。また、サーバ装置２は、メディア情報の「センサロール角」、「センサピッチ角」及び「センサヨー角」の各要素に指定されたセンサのロール角、ピッチ角、ヨー角の情報に基づき、端末装置１から受信する生データを、地図で採用される座標系である絶対座標系のデータに変換する。これにより、サーバ装置２は、受信した生データを、絶対座標系で表されたデータに変換し、配置地図ＤＢ５の更新に好適に用いることができる。

　また、位置推定イベントに関するイベント情報を有するアップロード情報Ｉｕを受信した場合、サーバ装置２は、例えば、図９の位置推定イベントの「位置推定種別」、「基準オブジェクトＩＤ」、「参照マップＩＤ」、「参照センサＩＤ」、「参照プラットフォームＩＤ」、「参照アルゴリズムＩＤ」等に指定された情報に基づき、現在の端末装置１の車両の位置推定に対する信頼度（精度）を推定する。そして、サーバ装置２は、推定した信頼度を勘案し、当該端末装置１から送信されるイベント情報に対する信頼度の設定等を行う。また、サーバ装置２は、位置推定種別が相対位置推定である場合には、「緯度」及び「経度」等に指定された相対位置情報を、基準オブジェクトＩＤが示すオブジェクトの位置情報に基づき、絶対的な位置情報に変換する。

　＜第２実施例＞
　第２実施例では、サーバ装置２は、イベント情報を含むアップロード情報Ｉｕを端末装置１から受信した場合であって、参照テーブルＲＴを参照しても不明な参照ＩＤがイベント情報に含まれていた場合に、端末装置１に対して参照テーブルＲＴの再送要求をさらに行う。これにより、サーバ装置２は、必要に応じて最新の参照テーブルＲＴを端末装置１から受信し、イベント情報で指定された参照ＩＤに対応する情報を好適に取得する。

　図１４（Ａ）は、サーバ装置２の参照テーブルＤＢ８において所定の車両ＩＤと関連付けられて記憶されたマップ参照テーブルＲＴＭを示し、図１４（Ｂ）は、図１４（Ａ）に示されるマップ参照テーブルＲＴＭの送信元の端末装置１が現時点で記憶するマップ参照テーブルＲＴＭを示す。この例では、マップ参照テーブルＲＴＭをサーバ装置２に送信した後に端末装置１がマップ参照テーブルＲＴＭを更新したことにより、最新のマップ参照テーブルＲＴＭには参照マップＩＤ「４」のレコードが追加されている。

　端末装置１は、参照マップＩＤ「４」の地図ＤＢ４を参照してオブジェクト認識イベントなどの所定のイベントを検出した場合、イベント情報に参照マップＩＤ「４」を付加したアップロード情報Ｉｕをサーバ装置２へ送信する。サーバ装置２は、このアップロード情報Ｉｕを受信した場合、送信元の端末装置１に対応する図１４（Ａ）に示すマップ参照テーブルＲＴＭを参照マップＤＢ８から抽出し、イベント情報に付加された参照マップＩＤ「４」に対応するレコードを探索する。この場合、サーバ装置２は、図１４（Ａ）に示すマップ参照テーブルＲＴＭに参照マップＩＤ「４」に対応するレコードが存在しないことから、端末装置１に対してマップ参照テーブルＲＴＭの再送要求を送信する。端末装置１は、上述の再送要求を受信した場合、記憶部１２に記憶された図１４（Ｂ）に示す最新のマップ参照テーブルＲＴＭを抽出し、マップ参照テーブルＲＴＭをサーバ装置２へ送信する。これにより、サーバ装置２は、端末装置１から最新のマップ参照テーブルＲＴＭを取得し、参照マップＩＤ「４」に対応する地図の詳細な情報を好適に特定することができる。なお、端末装置１は、マップ参照テーブルＲＴＭ全体をサーバ装置２へ送信する代わりに、マップ参照テーブルＲＴＭを新たに生成するための情報として、参照マップＩＤ「４」に対応するレコードのみを送信してもよい。この場合、サーバ装置２は、送信を要求するレコードに対応するＩＤを指定した送信要求を端末装置１に対して送信するとよい。

　図１５は、第２実施例においてサーバ装置２が実行するアップロード受信処理の手順を示すフローチャートである。図１５の例では、サーバ装置２は、端末装置１から受信した参照テーブルＲＴを車両ＩＤと関連付けて参照テーブルＤＢ８に記憶し、参照テーブルＤＢ８に記憶した参照テーブルＲＴに対象の参照ＩＤが存在しない場合などに当該参照テーブルＲＴの再送要求を行う。

　サーバ装置２は、端末装置１からの接続要求があった場合（ステップＳ４０１；Ｙｅｓ）、端末装置１と通信セッションを確立し、車両属性情報ＩＶなどを含むアップロード情報Ｉｕを端末装置１から受信する（ステップＳ４０２）。この場合、例えば、端末装置１は、サーバ装置２に参照テーブルＲＴを送信した履歴がない場合（例えばサーバ装置２と初めて通信セッションを確立した場合）には、参照テーブルＲＴをアップロード情報Ｉｕに含めてサーバ装置２に送信し、サーバ装置２に参照テーブルＲＴを送信した履歴がある場合には、参照テーブルＲＴをアップロード情報Ｉｕに含めなくともよい。なお、端末装置１は、サーバ装置２に参照テーブルＲＴ及び車両属性情報ＩＶの両方を送信した履歴がある場合には、上述のアップロード情報Ｉｕをサーバ装置２に送信しなくともよい。この場合、サーバ装置２は、ステップＳ４０２のアップロード情報Ｉｕの受信処理を行わない。そして、サーバ装置２は、受信したアップロード情報Ｉｕに参照テーブルＲＴが含まれる場合には、参照テーブルＲＴをアップロード情報Ｉｕに含まれる車両ＩＤと関連付けて参照テーブルＤＢ８に記憶する。

　次に、サーバ装置２は、通信セッションを確立した端末装置１からイベント情報を含むアップロード情報Ｉｕを受信したか否か判定する（ステップＳ４０４）。そして、サーバ装置２は、イベント情報を含むアップロード情報Ｉｕを受信した場合（ステップＳ４０４；Ｙｅｓ）、イベント情報内に不明な参照ＩＤが含まれているか否か判定する（ステップＳ４０５）。この場合の参照ＩＤは、参照マップＩＤ、参照センサＩＤ、参照プラットフォームＩＤ、参照アルゴリズムＩＤのいずれであってもよい。一方、サーバ装置２は、イベント情報を含むアップロード情報Ｉｕを受信しない場合（ステップＳ４０４；Ｎｏ）、ステップＳ４０８へ処理を進める。

　そして、サーバ装置２は、ステップＳ４０５において、イベント情報内に不明な参照ＩＤが含まれていると判断した場合（ステップＳ４０５；Ｙｅｓ）、即ち、参照テーブルＤＢ８に記録された参照テーブルＲＴに定義されていない参照ＩＤ又は不自然な参照ＩＤがイベント情報に含まれている場合、参照テーブルＲＴの再送要求を端末装置１へ送信する（ステップＳ４０６）。不自然な参照ＩＤとは、例えば受信したオブジェクト認識イベントとして受信したアップロード情報Ｉｕの内容が、参照ＩＤが示す情報と明らかに異なる場合を指す。例えば、オブジェクト認識イベントとして受信したアップロード情報Ｉｕにおいて、オブジェクトタイプとして「人間」が認識されたとの情報が記憶されていたにもかかわらず、参照アルゴリズムＩＤが、車線認識アルゴリズムを指している場合などを言う。また、別の例では、オブジェクト認識イベントとして受信したアップロード情報Ｉｕにおいて示されるメディアＩＤに対応するメディア情報が、「画像」であるにもかかわらず、参照センサＩＤが示すセンサが「マイク」を示している場合などである。このような場合、サーバ装置１が参照テーブルＤＢ８に記憶する参照テーブルＲＴの内容と、端末装置１が保有する参照テーブルＲＴとの間で、不整合が生じている可能性が高いため、参照テーブルＲＴの再送要求を行うことで、サーバ装置２の参照テーブルＤＢ８の内容を更新するのである。

　なお、ステップＳ４０６では、サーバ装置２は、マップ参照テーブルＲＴＭ、センサ参照テーブルＲＴＳ、プラットフォーム参照テーブルＲＴＰ、アルゴリズム参照テーブルＲＴＡの全ての再送を要求する再送要求を送信してもよく、不明又は不自然な参照ＩＤに対応する参照テーブルＲＴのみの再送を要求する再送要求を送信してもよい。そして、サーバ装置２は、上述の再送要求の応答として端末装置１から送信された参照テーブルＲＴを受信した場合、当該参照テーブルＲＴを送信元の端末装置１に対応する車両ＩＤと関連付けて参照テーブルＤＢ８に記憶する（ステップＳ４０７）。これにより、サーバ装置２は、新たに受信した参照テーブルＲＴを参照することで、ステップＳ４０４で受信したアップロード情報Ｉｕのイベント情報の生成時に用いた地図、センサ、プラットフォーム、又はアルゴリズム等に関する属性情報を好適に特定することができる。なお、サーバ装置２は、ステップＳ４０６で不明な参照ＩＤが存在すると判定した際に参照した参照テーブルＲＴについては、参照テーブルＤＢ８から削除するとよい。そして、ステップＳ４０７の実行後、サーバ装置２は、特定した地図、センサ、プラットフォーム、及びアルゴリズムの各属性情報に基づき補正したイベント情報をイベント情報ＤＢ９に登録する。

　一方、サーバ装置２は、イベント情報内に不明な参照ＩＤが含まれていない場合（ステップＳ４０５；Ｎｏ）、即ち、イベント情報に含まれる参照ＩＤがいずれも参照テーブルＤＢ８に記憶された参照テーブルＲＴに正しく定義されている場合、既に参照テーブルＤＢ８に登録された参照テーブルＲＴを参照することで、ステップＳ４０４で受信したアップロード情報Ｉｕのイベント情報の生成時に用いた地図、センサ、プラットフォーム、及びアルゴリズムの属性情報を好適に特定する。そして、サーバ装置２は、特定した地図、センサ、プラットフォーム、及びアルゴリズムの属性情報を反映したイベント情報をイベント情報ＤＢ９に登録する。

　次に、サーバ装置２は、端末装置１との通信セッションが切断されたか否か判定する（ステップＳ４０８）。そして、サーバ装置２は、端末装置１との通信セッションが切断された場合（ステップＳ４０８；Ｙｅｓ）、フローチャートの処理を終了する。この場合、サーバ装置２は、通信セッションが切断された端末装置１から送信された参照テーブルＲＴを破棄することなく継続して参照テーブルＤＢ８に記憶しておく。一方、サーバ装置２は、端末装置１との通信セッションが切断されていない場合（ステップＳ４０８；Ｎｏ）、再びステップＳ４０４へ処理を戻してアップロード情報Ｉｕの受信処理を行う。このように、第２実施例におけるサーバ装置２の制御部２３は、取得部、特定部、補正部、地図情報要求部、更新部、及びプログラムを実行するコンピュータの一例である。

　図１６は、第２実施例において端末装置１が実行する参照テーブルＲＴの再送処理の手順を示すフローチャートである。端末装置１は、図１６のフローチャートの処理を、図１１に示したアップロード送信処理と並行して繰り返し実行する。

　まず、端末装置１は、参照テーブルＲＴの再送要求をサーバ装置２から受信したか否か判定する（ステップＳ５０１）。そして、端末装置１は、参照テーブルＲＴの再送要求をサーバ装置２から受信した場合（ステップＳ５０１；Ｙｅｓ）、上述の再送要求において指定された参照テーブルＲＴをサーバ装置２へ送信する（ステップＳ５０２）。これにより、アップロード情報Ｉｕのイベント情報に含めた参照ＩＤを的確に定義した参照テーブルＲＴをサーバ装置２へ送信することができる。好適には、端末装置１は、参照テーブルＲＴの再送要求をサーバ装置２から受信した場合、記憶部１２に記憶した各参照テーブルＲＴの更新（再生成）処理を行い、更新処理後の参照テーブルＲＴをサーバ装置２へ送信してもよい。これにより、端末装置１は、端末装置１及び車両の最新の状態を的確に反映した参照テーブルＲＴを、サーバ装置２へ供給することができる。他の例では、端末装置１は、参照テーブルＲＴの再送要求をサーバ装置２から受信したか否かによらず、利用可能な地図、センサ、プラットフォーム、又はアルゴリズムのいずれかに変更があったことを検知した場合に、対応する参照テーブルＲＴを即時に更新してもよい。このように、第２実施例における端末装置１の制御部１４は、第１送信部、受信部、生成部、第２送信部、及びプログラムを実行するコンピュータの一例である。

　以上説明したように、上記実施例は、検出した物体の情報を各移動体から収集する情報処理装置へ送信するデータとして好適なデータ構造、及び当該データ構造を有するデータの授受を行う情報送信装置及び情報処理装置を提供することを一つの目的としている。

　また、各車両からセンサの出力データや物体の検出データなどを収集する場合、これらのデータの取得位置を示す車両の位置情報を取得する必要がある。一方、位置情報の取得方法は車両ごとに異なり、取得方法が異なる場合、得られる位置情報は、取得方法に応じて異なる場合がある。

　上記のような課題を解決するため、上記実施例は、移動体の位置に関する位置情報を送信するためのデータ構造として好適なデータ構造及び当該データ構造を有するデータの授受を行う情報送信装置及び情報処理装置を提供することを一つの目的としている。

　また、各車両で検出した変化点等に関する情報をサーバ装置が収集して地図データの更新等を行うシステムでは、車両側から送信されるデータは、一般的に地図を参照して生成される。一方、地図は、作成方針等が異なると地図の内容も異なるものとなる。例えば、個々の地物等の絶対的な位置精度を重視する作成方針の場合と、地物間の相対的な位置関係の精度を重視する作成方針の場合とでは、作成される地図は異なる。従って、車両側から送信されるデータは、当該車両側で参照される地図に依存したデータとなっているため、参照された地図に応じて補正する必要がある。

　上記のような課題を解決するため、上記実施例は、検出物体情報の生成に利用した地図を好適に特定可能な情報処理装置、及び検出物体情報を送信する情報送信装置を提供することを一つの目的としている。

　また、センサの出力に基づき検出された物体の情報を各車両から収集する場合、これらの情報は、各車両が変化点等の検出に使用したセンサによってばらつきが存在する。よって、各車両がセンサの出力に基づき検出した情報を収集して地図データの更新等を高精度に行うためには、各車両が使用したセンサの情報に基づき収集した情報の補正等を行う必要がある。

　上記のような課題を解決するため、上記実施例は、各移動体から検出した物体の情報を収集する情報処理装置に送信するために好適なデータ構造及び当該データ構造を有するデータを送信する情報送信装置を提供することを一つの目的としている。

　上記のような課題を解決するため、上記実施例は、検出した物体の情報を各移動体から収集する情報処理装置が各移動体において使用された検出装置に関する情報を特定するのに好適なデータ構造及び当該データ構造を有するデータの授受を行う情報送信装置及び情報処理装置を提供することを一つの目的としている。

　また、センサが出力する検出情報を各車両から収集する場合、これらの検出情報は、各車両に備わるセンサによってばらつきが存在する。よって、各車両のセンサが出力する検出情報を収集して地図データの更新等を高精度に行うためには、各車両が使用したセンサの情報に基づき収集した検出情報の補正等を行う必要がある。

　上記のような課題を解決するため、上記実施例は、検出情報を各移動体から収集する情報処理装置が受信するデータとして好適なデータ構造及び当該データ構造を有するデータの授受を行う情報送信装置及び情報処理装置を提供することを一つの目的としている。

　また、センサの出力に基づき検出された物体の情報を各車両から収集するシステムにおいて、データを供給する車両側で採用されるプラットフォームは車両ごとに異なる場合がある。この場合には、データを収集するサーバは、各車両側で採用されるプラットフォームの情報を取得し、収集したデータの解析等に利用する必要がある。

　上記のような課題を解決するため、上記実施例は、検出した物体の情報を各移動体から収集する情報処理装置が受信するデータとして好適なデータ構造及び当該データ構造を有するデータの授受を行う情報送信装置及び情報処理装置を提供することを一つの目的としている。

　また、センサの出力に基づき検出された物体の情報を各車両から収集するシステムにおいて、データを供給する車両側で実行されるアルゴリズムは車両ごとに異なる場合がある。そして、適用するアルゴリズムが異なる場合、生成されるデータはアルゴリズムに応じて異なるものとなる。

　上記のような課題を解決するため、本実施例は、検出した物体の情報を各移動体から収集する情報処理装置が受信するデータとして好適なデータ構造及び当該データ構造を有するデータの授受を行う情報送信装置及び情報処理装置を提供することを一つの目的としている。

　＜変形例＞
　次に、上述の第１及び第２実施例に好適な変形例について説明する。以下の変形例は、任意に組み合わせて上述の各実施例に適用してもよい。

　［変形例１］
　実施例で説明したサーバ装置２の処理を、複数のサーバ装置からなるサーバシステム（所謂クラウドサーバ）が実行してもよい。

　例えば、サーバシステムは、配信地図ＤＢ５を記憶するサーバと、参照テーブルＤＢ８を記憶するサーバと、イベント情報ＤＢ９を記憶するサーバと、図１３又は図１５に示すアップロード情報Ｉｕの受信処理を行うサーバとから構成されていてもよい。この場合、各サーバは、予め割り当てられた処理を実行するのに必要な情報を他のサーバから適宜受信して所定の処理を実行する。この場合、サーバシステムは、情報処理装置の一例である。

　また、アップロード情報Ｉｕに含まれるイベント情報は、端末装置１とサーバ装置２との間で授受が行われてもよく、サーバ間で授受が行われてもよい。図１７は、変形例に係るデータ収集システムの概略構成である。図１７に示すデータ収集システムは、複数の端末装置１と、車両クラウド２Ａと、地図クラウド２Ｂとを有する。車両クラウド２Ａは、主に車ベンダーが管理するサーバ群であり、地図クラウド２Ｂは、主に地図ベンダーが管理するサーバ群である。

　この場合、車両クラウド２Ａ及び地図クラウド２Ｂは、第１及び第２実施例のサーバ装置２と同様に、参照テーブルＲＴを含むアップロード情報Ｉｕ及び参照ＩＤが付されたイベント情報を含むアップロード情報Ｉｕを、各車両の端末装置１から受信してもよい。これにより、車両クラウド２Ａ及び地図クラウド２Ｂは、それぞれイベント情報を収集することが可能である。

　また、車両クラウド２Ａは、端末装置１から受信して蓄積したイベント情報を、個々の車両を特定可能な情報などを除外して地図クラウド２Ｂへ送信してもよい。このとき、車両クラウド２Ａは、各参照ＩＤが含まれるイベント情報と共に、参照テーブルＲＴを地図クラウド２Ｂへ送信するとよい。この場合、車両クラウド２Ａは、各端末装置１から受信した車両ごとの参照テーブルＲＴをそのまま地図クラウド２Ｂへ送信してもよく、自ら新たに生成した参照テーブルＲＴに置き換えて地図クラウド２Ｂへ送信してもよい。後者の場合、車両クラウド２Ａは、送信すべきイベント情報に含まれる各参照ＩＤを、自らが生成した参照テーブルＲＴと整合するように書き換える。このように、サーバ間でイベント情報の授受を行う場合であっても、参照テーブルＲＴを事前に共有することで、好適に通信データ量を削減することができる。

　［変形例２］
　端末装置１は、オブジェクト認識イベント、標識認識イベント、車線境界認識イベントなどのイベントを検出した場合、検出したイベントに対する信頼度（コンフィデンスレベル）を算出し、算出した信頼度に応じてイベント情報のサーバ装置２への送信の要否判定を行ってもよい。

　この場合、例えば、端末装置１は、カメラなどの外界センサの出力データから抽出した特徴量の認識適合率や、位置推定において取得される位置推定精度の情報（例えばＧＰＳの場合にはＤＯＰ値）などを勘案し、検出したイベントの信頼度を設定する。そして、端末装置１は、設定した信頼度が所定値以上である場合に限り、検出したイベントの検出結果を示すイベント情報を含むアップロード情報Ｉｕをサーバ装置２へ送信する。これにより、端末装置１は、信頼性が低いイベント情報を不要にサーバ装置２へ送信するのを防ぎ、通信データ量を好適に削減することができる。なお、端末装置１は、信頼度に応じてイベント情報のサーバ装置２への送信の要否判定を行う代わりに、設定した信頼度の情報をイベント情報に付加してサーバ装置２へ送信してもよい。この場合、端末装置１は、算出した信頼度の高低に関わらず、検出したイベントの検出結果を示すイベント情報を含むアップロード情報Ｉｕをサーバ装置２へ送信する。

　［変形例３］
　サーバ装置２は、マップ参照テーブルＲＴＭ、センサ参照テーブルＲＴＳ、プラットフォーム参照テーブルＲＴＰ、アルゴリズム参照テーブルＲＴＡの少なくともいずれかの参照テーブルＲＴについて、全車両に共通する参照テーブルＲＴを予め記憶してもよい。

　ここで、一例として、プラットフォーム参照テーブルＲＴＰを全車両で共通する場合について説明する。この場合、端末装置１とサーバ装置２は、それぞれ共通のプラットフォーム参照テーブルＲＴＰを予め記憶しておき、サーバ装置２は、イベント情報に参照プラットフォームＩＤが含まれていた場合には、上述の共通のプラットフォーム参照テーブルＲＴＰを参照することで、端末装置１のイベント検出時のプラットフォームの詳細情報を特定する。この場合、例えば、サーバ装置２は、プラットフォーム参照テーブルＲＴＰを予め記憶しておき、端末装置１との通信セッションの確立時などに、記憶したプラットフォーム参照テーブルＲＴＰを端末装置１へ配信することで、サーバ装置２と共通のプラットフォーム参照テーブルＲＴＰを端末装置１に保持させてもよい。

　この態様によれば、サーバ装置２は、車両ごとにプラットフォーム参照テーブルＲＴＰを管理する必要がなくなり、参照プラットフォームＩＤに基づくプラットフォームの情報の特定を好適に簡易化することができる。マップ参照テーブルＲＴＭ、センサ参照テーブルＲＴＳ、及びアルゴリズム参照テーブルＲＴＡについても同様に、サーバ装置２は、全ての車両に共通する参照テーブルＲＴを記憶及び参照してもよい。

　［変形例４］
　端末装置１は、複数の地図ＤＢ４を記憶部１２に記憶する代わりに、複数の地図ＤＢ４を記憶する地図管理装置から地図ＤＢ４の情報を適宜受信してもよい。

　［変形例５］
　第１及び第２実施例では、端末装置１は、イベント検出時に使用した地図、センサ、プラットフォーム、及びアルゴリズムに関する情報を、参照マップＩＤ、参照センサＩＤ、参照プラットフォームＩＤ、参照アルゴリズムＩＤの各参照ＩＤをイベント情報に含めることでサーバ装置２へ通知した。これに代えて、端末装置１は、少なくともいずれかの参照ＩＤに対応する情報を直接イベント情報に含めてサーバ装置２へ送信してもよい。

　図１８は、変形例に係るイベント情報の「オブジェクト認識イベント」のデータ構造の一例である。図１８に示す「オブジェクト認識イベント」のデータ構造は、「参照センサＩＤリスト」において１又は複数の参照センサＩＤを指定する代わりに、センサ参照テーブルＲＴＳの各項目に対応する「センサタイプ」、「センサベンダー」、「センサモデル」、「センサＦＷバージョン」を繰り返し指定可能なデータ構造となっている。同様に、図１８に示すデータ構造は、「参照プラットフォームＩＤリスト」において１又は複数の参照プラットフォームＩＤを指定する代わりに、プラットフォーム参照テーブルＲＴＰの各項目に対応する「プラットフォームベンダー」、「プラットフォームＨＷモデル」、「プラットフォームＦＷバージョン」、「プラットフォームＳＷバージョン」を繰り返し指定可能なデータ構造となっている。同様に、図１８に示すデータ構造は、「参照アルゴリズムＩＤリスト」において１又は複数の参照アルゴリズムＩＤを指定する代わりに、アルゴリズム参照テーブルＲＴＡの各項目に対応する「アルゴリズムタイプ」、「アルゴリズムベンダー」、「アルゴリズムバージョン」を繰り返し指定可能なデータ構造となっている。

　このように、端末装置１は、イベント検出時に使用したセンサ、プラットフォーム、及びアルゴリズムに関する情報をイベント情報に直接含めることによっても、これらの情報を好適にサーバ装置２に通知することができる。この場合、端末装置１は、対応する参照テーブルＲＴをサーバ装置２に送信する必要がない。また、サーバ装置２は、世の中にある様々な端末装置１が使用するセンサ、プラットフォーム、アルゴリズムについての情報を収集することができるため、それらを［変形例３］において示された全車両に共通する参照テーブルＲＴの作成に活用することができる。

　端末装置１は、メディア情報についても同様に、参照センサＩＤに代えて、生データを生成したセンサに関する情報を個別に指定してもよい。図１９は、変形例に係るメディア情報のデータ構造を示す。図１９の例では、参照センサＩＤに代えて、「センサタイプ」、「センサベンダー」、「センサモデル」、「センサＦＷバージョン」の要素が設けられている。端末装置１は、これらの要素に、送信する生データを取得したセンサの各情報を指定することで、参照センサＩＤを指定した場合と同様に、送信する生データを取得したセンサの各情報を好適にサーバ装置２に通知することができる。

　１　情報処理装置
　２　サーバ装置
　４　地図ＤＢ
　５　配信地図ＤＢ
　６　センサデータキャッシュ
　７　センサ部
　８　参照テーブルＤＢ
　９　イベント情報ＤＢ

Claims

　移動体に搭載された検出装置が検出した物体に関する情報である検出物体情報を収集する情報処理装置に、前記検出装置が前記物体を検出する際に用いた地図を特定させるために、前記検出物体情報の収集に先立って前記情報処理装置に送信されるデータのデータ構造であって、
　前記物体を検出する際に前記移動体が利用可能な地図に関する情報と、
　前記移動体が利用可能な地図の各々を特定するための、前記地図に関する情報と関連付けた地図特定情報と、
を含む、データ構造。
　前記地図に関する情報は、前記地図のバージョン、フォーマット、ベンダー、及び名称の少なくともいずれかに関する情報である請求項１に記載のデータ構造。
　前記検出物体情報の送信前に前記情報処理装置に送信され、
　前記移動体に関する属性情報をさらに含む請求項１または２に記載のデータ構造。
　記憶部に記憶される地図の各々を特定するための地図特定情報と、当該地図特定情報により特定される地図に関する情報とを含む参照情報を記憶する記憶部と、
　前記参照情報を、移動体ごとに検出された物体に関する情報である検出物体情報を収集する情報処理装置へ、前記検出物体情報に先立って送信する送信部と、
を有する情報送信装置。
　前記送信部は、前記参照情報の送信後において、検出した物体に関する検出物体情報と、前記物体を検出する際に利用した地図を特定するための地図特定情報と、を前記情報処理装置へ送信する請求項４に記載の情報送信装置。
　前記送信部は、前記情報処理装置と通信を確立したときに前記参照情報を送信する請求項４または５に記載の情報送信装置。
　検出された物体に関する情報である検出物体情報を移動体から収集する情報処理装置であって、
　移動体が利用可能な地図の各々を特定するための地図特定情報と、当該地図特定情報により特定される地図に関する情報とを含む参照情報を前記移動体から受信する受信部と、
　前記受信部が受信した参照情報を、当該参照情報を送信した移動体毎に記憶する記憶部と、
を有する情報処理装置。
　前記記憶部は、前記参照情報を、前記移動体の識別情報又は前記移動体との通信接続の識別情報と関連付けて記憶する請求項７に記載の情報処理装置。
　前記受信部は、前記参照情報の受信後、当該参照情報を送信した移動体から前記検出物体情報と前記地図特定情報とを受信し、
　前記地図特定情報と、前記参照情報とに基づき、前記物体を検出する際に利用された地図に関する情報を特定する特定部をさらに有する請求項７または８に記載の情報処理装置。
　前記特定部が特定した地図に関する情報に基づき、前記検出物体情報を補正する補正部をさらに有する請求項７～９のいずれか一項に記載の情報処理装置。
　情報送信装置が実行する制御方法であって、
　記憶部に記憶される地図の各々を特定するための地図特定情報と、当該地図特定情報により特定される地図に関する情報とを含む参照情報を、移動体ごとに検出された物体に関する情報である検出物体情報を収集する情報処理装置へ、前記検出物体情報に先立って送信する送信工程を有する制御方法。
　検出された物体に関する情報である検出物体情報を移動体から収集する情報処理装置が実行する制御方法であって、
　移動体が利用可能な地図の各々を特定するための地図特定情報と、当該地図特定情報により特定される地図に関する情報とを含む参照情報を前記移動体から受信する受信工程と、
　前記受信工程が受信した参照情報を、当該参照情報を送信した移動体毎に記憶部に記憶する記憶工程と、
を有する制御方法。
　請求項１１または１２に記載の制御方法を、コンピュータにより実行させるプログラム。
　請求項１３に記載のプログラムを記憶したことを特徴とする記憶媒体。
　移動体に搭載された検出装置が検出した物体に関する情報である検出物体情報を収集する情報処理装置が、前記検出装置が前記物体を検出する際に用いた地図を特定するために、前記検出物体情報の取得に先立って受信するデータのデータ構造であって、
　前記物体を検出する際に前記移動体が利用可能な地図に関する情報と、
　前記移動体が利用可能な地図の各々を特定するための、前記地図に関する情報と関連付けた地図特定情報と、
を含む、データ構造。