JP7336776B2 - 車両監視装置、および車両監視システム - Google Patents

Description

本開示は、車両監視装置、および車両監視システムに関する。

車両を遠隔監視するシステムが知られている。例えば、車両の全周囲の撮影画像を合成した合成画像を車外に送信する技術が知られている。特許文献１は、車両のサイドミラー、車両の先端、車両の後端、の各々に設置されたカメラの撮影画像を合成した合成画像を生成して、車両の使用者が携行するスマートフォンに送信する。

特許第６３４７９３４号公報

従来技術では合成画像を生成する際に、車両の全周囲の撮影画像を合成した全周囲画像の中央の自車両に相当する部分に、予め用意された車体の３Ｄ（ｔｈｒｅｅ－ｄｉｍｅｎｓｉｏｎａｌ）モデルの像をはめ込んだ合成画像を生成していた。このため、従来技術では、車両の使用者または所有者が携行するスマートフォンに表示される合成画像の車体部分は、実際の車体の画像ではなく３Ｄモデルの像なので、実際の車両の外装の状態を確認できない。すなわち、従来技術では、車両が被害を受ける事故の発生時に、車両の使用者または所有者のスマートフォンに車両の周辺の画像が映るにも関わらず、その画像には車両自体の実際の像は映っていないので、車両の使用者自身または所有者自身が事故現場に赴いて、実際に車両の外装を目視で直接確認する必要があった。これは車両の使用者または所有者にとって、身体的負担である。また、被害者である車両の使用者または所有者が事故現場に行くと、加害者と対面する事が起こる。更に、被害の補償を受ける為の事故処理の過程でも被害者の個人情報を加害者に暴露する事を強いられる事態が発生する。この様な事は車両の使用者または所有者にとって、非常に大きな心理的負担である。つまり、従来技術では、車両の使用者または所有者の負担が大きい。

本開示が解決しようとする課題は、車両の使用者または所有者の負担軽減を図ることができる、車両監視装置、および車両監視システムを提供することである。

本開示の車両監視装置は、画像取得部と、異常情報取得部と、被害判定部と、被害報告部と、画像記録部と、を備える。画像取得部は、車両の車体の外装の像を含む撮影画像を取得する。異常情報取得部は、前記車体の異常を示す車体異常情報を取得する。被害判定部は、前記撮影画像および前記車体異常情報に応じて、前記車体における被害の有無を判定する。被害報告部は、前記被害の判定結果に応じて、前記撮影画像、または前記撮影画像に基づいて生成された画像を含む被害報告を、情報処理装置に報告する。画像記録部は、前記撮影画像を記録する。前記画像記録部は、前記車体異常情報に基づいて、前記撮影画像を録画するか否かを判定する録画判定部を有し、前記録画判定部は、録画すると判定した時に前記被害判定部が被害無し、と判定した判定不一致の回数が所定回数以上であるときに、前記判定不一致の回数が所定回数未満であるときに比べて録画すると判定し難くする。

本開示に係る車両監視装置、および車両監視システムによれば、車両の使用者または所有者の負担軽減を図ることができる。

図１は、実施形態の車両監視システムの一例を示す図である。 図２Ａは、実施形態の事故報告サーバの機能ブロック図である。 図２Ｂは、実施形態の携帯端末の機能ブロック図である。 図３は、実施形態の車両の機能ブロック図である。 図４は、実施形態の、カメラ、音響センサ、および加速度センサの配置を示す模式図である。 図５は、実施形態のハードウェア構成図である。 図６Ａは、実施形態の被害報告画像の生成の説明図である。 図６Ｂは、実施形態の被害報告画像の生成の説明図である。 図７は、実施形態の射影変換と視点移動の説明図である。 図８は、実施形態の死角の処理の説明図である。 図９Ａは、実施形態の死角処理の説明図である。 図９Ｂは、実施形態のカメラ視点から撮影された撮影画像を示す図である。 図１０は、実施形態の射影面とする車体の３Ｄモデルの説明図である。 図１１は、実施形態の被害報告画像の模式図である。 図１２Ａは、実施形態のＵＲＬを含むＱＲコードを示す図である。 図１２Ｂは、実施形態のＵＲＬを含むバーコードを示す図である。 図１３は、実施形態の車両監視装置が実行する情報処理の流れを示すフローチャートである。 図１４は、実施形態の事故報告サーバが実行する情報処理の流れを示すフローチャートである。 図１５は、実施形態の加害者携帯端末が実行する情報処理の流れを示すフローチャートである。 図１６は、実施形態の被害者携帯端末が実行する情報処理の流れを示すフローチャートである。 図１７は、実施形態の警察官携帯端末が実行する情報処理の流れを示すフローチャートである。

以下に添付図面を参照して、本開示に係る車両監視装置、および車両監視システムの実施の形態について説明する。

なお、本実施形態では、車両監視装置、および車両監視システムを、日本で実施した形態を一例として説明する。しかし、本実施形態の車両監視装置、および車両監視システムを適用可能な国は、日本に限定されない。

図１は、本実施形態の車両監視システム１の一例を示す図である。

車両監視システム１は、車両１０に搭載された車両監視装置２０と、事故報告サーバ３０と、携帯端末４０と、を備える。車両監視装置２０と、事故報告サーバ３０と、携帯端末４０とは、公衆回線Ｎを介して通信可能に接続されている。

車両監視システム１は、車両１０の監視結果に基づいて、車両監視装置２０、事故報告サーバ３０、および携帯端末４０間で、連携した各種処理を実行する。処理の詳細は後述する。

車両１０は、二輪自動車、三輪自動車、または、四輪自動車などである。本実施形態では、車両１０が四輪自動車である場合を一例として説明する。車両１０は、例えば、人による運転操作を介して進行する車両、または、人による運転操作を介さずに自律進行可能な車両、の何れであってもよい。

車両監視装置２０は、車両１０を監視する装置である。本実施形態では、車両監視装置２０は、車両１０に搭載された形態を一例として説明する。

事故報告サーバ３０は、情報処理装置の一例である。事故報告サーバ３０は、事故報告代行サービスを提供するサーバである。事故報告代行サービスとは、車両１０の事故発生時に、被害者、加害者、および警察、の間で発生する各種の情報のやり取りを被害者および加害者に代行して行うサービスである。事故報告サーバ３０は、例えば、保険会社によって管理される。本実施形態では、事故報告サーバ３０が、自動車保険の保険会社によって管理される形態を一例として説明する。

携帯端末４０は、情報処理装置の一例である。携帯端末４０は、携帯端末４０の使用者または所有者によって操作される情報処理装置である。携帯端末４０は、例えば、スマートフォン、タブレット端末、などであるが、これらに限定されない。

本実施形態では、車両監視システム１は、加害者携帯端末４２、被害者携帯端末４４、および警察官携帯端末４６を、携帯端末４０に含める。

加害者携帯端末４２は、車両１０に対する加害者の情報処理装置である。加害者は、例えば、車両１０に対して損害を与えた人物である。被害者携帯端末４４は、車両１０の使用者または所有者である被害者の情報処理装置である。警察官携帯端末４６は、警察官の情報処理装置、または、警察が管理する情報処理装置である。本実施形態では、被害者は車両の「使用者または所有者」であるとしているが、毎度、「使用者または所有者」と記述する事は煩雑であり、車両の使用者は車両の所有者でもある事が多いので、無意味に煩雑であるとも言える。レンタカーやカーリースの様な所有形態では使用者と所有者が異なるが、「駐車中の車両を監視し、被害を受けた時に対応する人は、所有者よりも使用者である」と考えて、以後の実施例中では「使用者」とのみ記し、「使用者」を「使用者または所有者」と読み替えても良いものとする。

図２Ａは、事故報告サーバ３０の一例の機能ブロック図である。事故報告サーバ３０は、通信部３０Ａと、ＵＩ（ユーザ・インターフェース）部３０Ｂと、記憶部３０Ｃと、制御部３０Ｄと、を備える。通信部３０Ａ、ＵＩ部３０Ｂ、記憶部３０Ｃ、および制御部３０Ｄは、バス３０Ｅを介して通信可能に接続されている。

通信部３０Ａは、各種の情報を他の情報処理装置および車両監視装置２０との間で送受信する。例えば、通信部３０Ａは、公衆回線Ｎを介して、車両監視装置２０および他の携帯端末４０の各々と通信する。ＵＩ部３０Ｂは、各種の操作指示の受付機能、および、各種の情報の出力機能、を有する。受付機能は、例えば、タッチパネル、操作キー、キーボード、ポインティングデバイス、マウス、入力ボタン、マイク、などである。出力機能は、画像表示機能、音声出力機能、などである。画像表示機能は、例えば、公知のＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）や有機ＥＬ（Ｅｌｅｃｔｒｏ－Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイなどである。音声出力機能は、例えば、スピーカである。記憶部３０Ｃは、事故報告サーバ３０が車両監視装置２０、携帯端末４０（加害者携帯端末４２、被害者携帯端末４４、および警察官携帯端末４６を含む）との間で交わした通信のデータを記憶すると共に、携帯端末４０が事故報告サーバ３０に各種の情報を送信する際に用いるアプリケーションソフトを記憶しており、事故報告サーバ３０は携帯端末４０からのアクセスに応じて記憶部３０Ｃが記憶しているアプリケーションソフトを携帯端末４０に転送する。制御部３０Ｄは、事故報告サーバ３０における各種処理を実行する。

図２Ｂは、携帯端末４０の一例の機能ブロック図である。携帯端末４０は、通信部４０Ａと、ＵＩ部４０Ｂと、記憶部４０Ｃと、カメラ４０Ｆと、制御部４０Ｄと、を備える。通信部４０Ａ、ＵＩ部４０Ｂ、記憶部４０Ｃ、カメラ４０Ｆ、および制御部４０Ｄは、バス４０Ｅを介して通信可能に接続されている。

通信部４０Ａは、各種の情報を他の情報処理装置との間で送受信可能である様に構成されている。例えば、通信部４２Ａは、公衆回線Ｎを介して、事故報告サーバ３０、車両監視装置２０、の各々と通信する。但し、車両監視装置２０と通信する携帯端末４０は、被害者携帯端末４４だけに限られ、加害者携帯端末４２、および警察官携帯端末４６は車両監視装置２０と通信しない。ＵＩ部４０Ｂは、各種の操作指示の受付機能、および、各種の情報の出力機能、を有する。記憶部４０Ｃは携帯端末４０の内蔵メモリであり、携帯端末４０が事故報告サーバ３０に各種の情報を送信する際に用いるアプリケーションソフトを記憶する。カメラ４０Ｆは、撮影によって撮影画像データを得る。カメラ４０Ｆは、例えば、携帯端末４０の内蔵カメラである。以下では、撮影画像データを、単に、撮影画像と称して説明する。制御部４０Ｄは、加害者携帯端末４２における各種処理を実行する。各種処理には携帯端末４０が事故報告サーバ３０に各種の情報を送信する際に用いるアプリケーションソフトの実行も含まれ、アプリケーションソフトはＵＩ部４０Ｂに所定のメッセージを表示して行うべき操作を携帯端末４０の使用者に説明し、携帯端末４０の使用者の操作に応じてカメラ４０Ｆを起動して撮影を行い、撮影した画像を携帯端末４０の使用者の確認と承認のもとに通信部４０Ａを介して事故報告サーバ３０に送信する事も行う。

携帯端末４０が加害者携帯端末４２である場合、前記のアプリケーションソフトを記憶部４０Ｃにダウンロードする時点は、事故が発生した時点である。加害者に前記のアプリケーションソフトをダウンロードさせる手段については後述する。

携帯端末４０が、被害者携帯端末４４である場合、アプリケーションソフトを記憶部４０Ｃにダウンロードする時点は、事故が発生した時点でも良いし、車両１０を購入した時点、車両監視装置２０を車両１０に取り付けた時点、または車両保険を契約した時点、のいずれであっても良い。

警察官携帯端末４６は、可搬型でない情報処理装置、例えば警察が管理するサーバであってもよいし、携帯端末とサーバの組み合わせであっても良い。本願のシステムが好ましく機能した場合、事故現場の画像は車両監視装置２０と加害者携帯端末４２と被害者携帯端末４４とのいずれかにより取得されるので、警察官が事故現場に赴く必要が無いからである。

本実施形態では、事故報告サーバ３０が、自動車保険の保険会社によって管理される形態を例示するが、前記の警察が管理するサーバが事故報告サーバ３０と同一であってもよい。その場合、警察が管理する事故報告サーバ３０へ事故現場の画像や各種の情報を送信する事は、事故報告代行サービスの利用ではなく事故報告そのものになるので、事故報告サーバ３０が警察に事故を報告するステップが省略されるものと理解されたい。

なお、図２Ａ～図２Ｂに示す、事故報告サーバ３０、携帯端末４０、の各々の機能構成は一例であり、図２Ａ～図２Ｂに示す機能構成に限定されない。

図３は、車両１０の一例の機能ブロック図である。車両１０は、カメラ１１と、音響センサ１２と、加速度センサ１３と、通信装置１４と、航法装置１５と、車外向けＨＭＩ（Ｈｕｍａｎ Ｍａｃｈｉｎｅ Ｉｎｔｅｒｆａｃｅ）１６と、車両監視装置２０と、を備える。カメラ１１、音響センサ１２、加速度センサ１３、通信装置１４、航法装置１５、車外向けＨＭＩ１６、および車両監視装置２０は、車内ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１７を介して通信可能に接続されている。

カメラ１１は、撮影によって撮影画像、つまり撮影画像データを取得する。音響センサ１２は、音声データを取得する。音響センサ１２は、例えば、マイクである。以下、音声データを単に音声と呼ぶ。加速度センサ１３は、車両１０に加えられた加速度を検知するセンサである。通信装置１４は、公衆回線Ｎを介して、事故報告サーバ３０、被害者携帯端末４４、の各々と通信するための通信装置である。航法装置１５は、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）機能を搭載した装置であり、車両１０の位置情報を検出する。車外向けＨＭＩ１６は、車両１０の車外に対して各種の情報を出力する。車外向けＨＭＩ１６は、例えば、ディスプレイ、スピーカ、ライト、などであるが、これらに限定されない。

図４は、車両１０における、カメラ１１、音響センサ１２、および加速度センサ１３の配置の一例を示す模式図である。

カメラ１１は、車両１０の全周囲を撮影可能となるように、設置位置および画角が予め調整されており、カメラ１１で撮影される視野範囲５０には、車両１０の車体の外装が含まれている。カメラ１１は、画像センサ、または、車載カメラと称される場合がある。本実施形態では、車両１０は、視野範囲５０が互いに異なる複数のカメラ１１を備える。なお、複数のカメラ１１の視野範囲の一部は、重複していてもよい。

例えば、車両１０には、カメラ１１として、カメラ１１Ｆ、カメラ１１Ｂ、カメラ１１Ｒ、およびカメラ１１Ｌが設けられている。なお、車両１０に設けられるカメラ１１の数は、４つに限定されない。

カメラ１１Ｆは、車両１０の前端部に配置されている。カメラ１１Ｂは、車両１０の後端部に配置されている。カメラ１１Ｆおよびカメラ１１Ｂは、それぞれ、車両１０の前後のバンパーを撮影可能に配置されている。

カメラ１１Ｒは、例えば、車両１０の右サイドミラーに配置されている。カメラ１１Ｌは、例えば、車両１０の左サイドミラーに配置されている。すなわち、カメラ１１Ｒおよびカメラ１１Ｌは、それぞれ、車両１０の右と左の側面を撮影可能に配置されている。

カメラ１１Ｒ、カメラ１１Ｌ、カメラ１１Ｆ、およびカメラ１１Ｂは、車両１０の車体の外装を含む車両１０の全周囲について、互いに異なる方向を撮影した撮影画像を取得する。また、カメラ１１Ｒ、カメラ１１Ｌ、カメラ１１Ｆ、およびカメラ１１Ｂの各々の備えるレンズは、標準的なレンズより焦点距離が短く、１８０度以上の画角の視野範囲５０を有する。このため、これらのカメラ１１を用いることで、車両１０の全周囲を撮影可能である。

本実施形態では、カメラ１１Ｒ、カメラ１１Ｌ、カメラ１１Ｆ、およびカメラ１１Ｂの各々は、１９０度程度の視野範囲５０を有する形態を一例として説明する。本実施形態では、カメラ１１は、カメラ１１Ｒの視野範囲５０Ｒ、カメラ１１Ｆの視野範囲５０Ｆ、カメラ１１Ｌの視野範囲５０Ｌ、およびカメラ１１Ｂの視野範囲５０Ｂについて、互いに隣接する視野範囲５０の一部が重複するように設置されている。

なお、カメラ１１は、車両１０の外装を含み、且つ、車両１０を中心とした全周囲の撮影画像を取得可能となるように、設置位置および数が調整されていればよく、図４に示す設置位置および数に限定されない。

音響センサ１２は、車両１０で発生した音声を検知可能となるように、配置位置および配置数が予め調整されている。例えば、車両１０は、マイク１２Ａ、マイク１２Ｂ、マイク１２Ｃ、およびマイク１２Ｄを、音響センサ１２として備える。これらのマイク１２Ａ、マイク１２Ｂ、マイク１２Ｃ、およびマイク１２Ｄは、互いに異なる位置に配置されている。なお、車両１０に設けられる音響センサ１２の数は、４つに限定されない。

マイク１２Ａは、車両１０の右前方の音声を検知可能な位置に配置されている。マイク１２Ｂは、車両１０の左前方の音声を検知可能な位置に配置されている。マイク１２Ｃは、車両１０の左後方の音声を検知可能な位置に配置されている。マイク１２Ｄは、車両１０の右後方の音声を検知可能な位置に配置されている。

加速度センサ１３は、例えば、ナビゲーションシステムに設けられている。加速度センサ１３は３軸加速度センサであり、前後方向、左右方向、および上下方向の各々に、どれだけ加速されたかを検知する。

車外向けＨＭＩ１６は、車両１０の車外に向けて各種の情報を報知するための装置である。本実施形態では、車外向けＨＭＩ１６は、車両１０のサイドウィンドウに設置された透明ディスプレイである場合を一例として説明する。なお、車外向けＨＭＩ１６は、車両１０のサイドウィンドウに設置された形態に限定されない。

図３に戻り説明を続ける。このように、本実施形態の車両１０は、カメラ１１、音響センサ１２、加速度センサ１３、通信装置１４、航法装置１５、車外向けＨＭＩ１６、および車両監視装置２０を備え、車両１０が駐車している時は、車両監視装置２０が車両内の各種装置を制御して車両の監視、及び車両の周囲の監視に当たる。この目的のため、本実施形態の車両１０は、車両１０の全周囲を撮影するカメラ１１、音響センサ１２、および加速度センサ１３によって、車両１０の外界を監視可能に構成されている。また、車両監視装置２０は、カメラ１１で撮影された撮影画像などを記録する機能を有する。また、車両監視装置２０は、通信装置１４により、事故報告サーバ３０、被害者携帯端末４４と、公衆回線Ｎを介して通信可能に構成されている。また、車両監視装置２０は、航法装置１５で得た自車の位置情報を事故報告サーバ３０に通知することが可能である。また、車両監視装置２０は車外向けＨＭＩ１６を介して、加害者に事故報告を求める報知情報を車外に向けて報知する。報知情報の詳細は後述する。

次に、車両監視装置２０について詳細に説明する。車両監視装置２０は、入出力部２１と、制御部２２と、記憶部２３と、を備える。入出力部２１と、制御部２２と、記憶部２３とは、内部バス２４を介して通信可能に接続されている。

入出力部２１は、車内ＬＡＮ１７を介してカメラ１１、音響センサ１２、加速度センサ１３、通信装置１４、航法装置１５、および車外向けＨＭＩ１６と通信する通信インターフェースである。カメラ１１、音響センサ１２、加速度センサ１３、通信装置１４、航法装置１５、車外向けＨＭＩ１６、および車両監視装置２０は、車内ＬＡＮ１７を介して、命令や情報や画像を送受信する。

記憶部２３は、各種の情報を記憶する。記憶部２３は、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、フラッシュメモリ等の半導体メモリ素子、ハードディスク、光ディスク等である。なお、記憶部２３は、車両監視装置２０の外部に設けられた記憶装置であってもよい。また、記憶部２３は、リムーバブルな記憶媒体と、前記記憶媒体を読み書きする装置の組み合わせで構成された記憶装置であってもよい。また、記憶部２３を、複数の記憶装置から構成してもよい。

制御部２２は、プロセッサと呼ばれるＣＰＵを中心とした機能ブロックであり、各種の処理を実行する。

図５は、制御部の一般的な構成例を図示したものであり、車両監視装置２０の制御部２２、事故報告サーバ３０の制御部３０Ｄ、携帯端末４０の制御部４０Ｄ、の各々のハードウェア構成例を説明するものである。

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２５Ａ、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２５Ｂ、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２５Ｃ、およびＩ／Ｆ２５Ｄ等がバス２５Ｅにより相互に接続されている。

ＣＰＵ２５Ａは、プロセッサと呼ばれる演算装置である。ＲＯＭ２５Ｂは、ＣＰＵ２５Ａが実行する情報処理を定義するプログラムを記憶する。ＲＯＭ２５Ｂは複数の半導体デバイスで構成され、その一部をフラッシュメモリの様に、書き換え可能な不揮発性メモリで構成する事が一般的である。ＲＡＭ２５Ｃは、ＣＰＵ２５Ａによる処理に必要なデータを記憶する。プログラムはＲＡＭ２５Ｃが記憶しても良い。Ｉ／Ｆ２５Ｄは、データやプログラムを送受信するためのインターフェースである。特定の目的のために作成されたプログラムをアプリケーションと呼び、アプリケーションを外部から取り込む処理をダウンロードと呼ぶ。ＣＰＵ２５ＡはＩ／Ｆ２５Ｄを介してアプリケーションをダウンロードし、ＲＡＭ２５Ｃに記憶させた上で実行する。また、ＣＰＵ２５ＡはＲＡＭ２５Ｃに記憶させたアプリケーションを、ＲＯＭ２５Ｂのフラッシュメモリで構成された部分にコピーし、制御部の電源が一時的に遮断されても、ダウンロードを再度、行う必要が無い様にする。

本実施の形態の制御部２２、制御部３０Ｄ、および制御部４０Ｄの各々で実行される情報処理を定義するプログラムは、ＲＯＭ２５Ｂ等に予め組み込んで提供されるものと、Ｉ／Ｆ２５Ｄを介して外部からダウンロードされるものがある。なお、本実施の形態の制御部２２、制御部３０Ｄ、および制御部４０Ｄの各々で実行されるプログラムは、制御部２２、制御部３０Ｄ、および制御部４０Ｄの各々にインストール可能な形式又は実行可能な形式のファイルでＣＤ－ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ－Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録されて提供するように構成してもよいし、外部のサーバが記憶しているプログラムを、公衆回線を介してダウンロードするように構成してもよい。

図３に戻り説明を続ける。

車両監視装置２０の制御部２２は、画像取得部２２Ａ、車体異常情報取得部２２Ｂ、画像分析部２２Ｃ、音声分析部２２Ｄ、画像記録部２２Ｅ、画像異常情報生成部２２Ｇ、被害判定部２２Ｈ、被害報告画像生成部２２Ｉ、被害報告部２２Ｊ、通信制御部２２Ｋ。事故報告要求部２２Ｌ、およびＨＭＩ制御部２２Ｍ、を備える。画像記録部２２Ｅは、録画判定部２２Ｆを有する。

画像取得部２２Ａ、車体異常情報取得部２２Ｂ、画像分析部２２Ｃ、音声分析部２２Ｄ、画像記録部２２Ｅ、録画判定部２２Ｆ、画像異常情報生成部２２Ｇ、被害判定部２２Ｈ、被害報告画像生成部２２Ｉ、被害報告部２２Ｊ、通信制御部２２Ｋ、事故報告要求部２２Ｌ、およびＨＭＩ制御部２２Ｍは機能ブロックであり、それぞれが一つの装置やハードウェアに対応するものではない。例えば、全部の機能ブロックの処理を１個のプロセッサが実行しても良いし、一つの機能ブロックの処理を複数のプロセッサが実行しても良い。上記各部の機能は、ＣＰＵ２５Ａなどのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよいし、画像処理などの特定の処理に特化した専用のＬＳＩ、すなわちハードウェアにより実現してもよいし、ソフトウェアとハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、複数のプロセッサの各々は、１つの機能ブロックの処理を実行してもよいし、２以上の機能ブロックの処理を実行してもよい。

プロセッサは、記憶部２３に保存されたプログラムを読み出し実行することで、上記複数の各部を実現する。なお、記憶部２３にプログラムを保存する代わりに、プロセッサの回路内にプログラムを直接組み込むよう構成してもよい。この場合、プロセッサは回路内に組み込まれたプログラムを読み出し実行することで、上記複数の各部を実現する。

入出力部２１、画像取得部２２Ａ、車体異常情報取得部２２Ｂ、画像分析部２２Ｃ、音声分析部２２Ｄ、画像記録部２２Ｅ、録画判定部２２Ｆ、画像異常情報生成部２２Ｇ、被害判定部２２Ｈ、被害報告画像生成部２２Ｉ、被害報告部２２Ｊ、通信制御部２２Ｋ、事故報告要求部２２Ｌ、ＨＭＩ制御部２２Ｍ、および記憶部２３は、内部バス２４で接続されており、相互に連携して動作する。

画像取得部２２Ａは、車両１０の車体の外装の像を含む撮影画像を取得する。本実施形態では、画像取得部２２Ａは、カメラ１１であるカメラ１１Ｒ、カメラ１１Ｌ、カメラ１１Ｂ、およびカメラ１１Ｆ、の各々から撮影画像を取得する。

車体異常情報取得部２２Ｂは、車体異常情報を取得する。車体異常情報とは、車両１０の車体の異常を示す情報である。車体異常情報は、加速度センサ１３によって検知された加速度の情報、および、音響センサ１２によって検知された音声の情報、の少なくとも一方を含む。以下では、音声の情報を音声情報、加速度の情報を加速度情報と称して説明する場合がある。本実施形態では、車体異常情報が、加速度情報および音声情報を含む形態を一例として説明する。

画像分析部２２Ｃは、画像取得部２２Ａで取得された撮影画像を分析する。画像分析部２２Ｃは、カメラ１１で撮影される撮影画像について、撮影タイミングの異なる複数の撮影画像間の画像の差分を抽出する。すなわち、画像分析部２２Ｃは、撮影画像に含まれる像の変化を分析する。具体的には、画像分析部２２Ｃは、撮影画像に含まれる、車両１０の車体の外装の像の変化を分析する。

詳細には、画像分析部２２Ｃは、カメラ１１Ｒ、カメラ１１Ｌ、カメラ１１Ｂ、およびカメラ１１Ｆの各々で撮影される撮影画像について、撮影タイミングの異なる撮影画像間の画像の差分を抽出する。撮影画像間の画像の差分抽出には、公知の技術を用いればよい。画像分析部２２Ｃは、撮影画像の分析結果を、録画判定部２２Ｆ、画像異常情報生成部２２Ｇ、および録画判定部２２Ｆなどへ出力する。

音声分析部２２Ｄは、音響センサ１２で検知された音声の音声情報を分析する。音声分析部２２Ｄは、車体異常情報取得部２２Ｂで取得した車体異常情報に含まれる、音響センサ１２で検知された音声の音声情報を分析する。音声分析部２２Ｄは、音声情報の分析結果を、録画判定部２２Ｆ、画像異常情報生成部２２Ｇ、および録画判定部２２Ｆなどへ出力する。

画像記録部２２Ｅは、カメラ１１で撮影された撮影画像を記憶部２３へ記録する。画像記録部２２Ｅは、録画判定部２２Ｆを備える。

録画判定部２２Ｆは、車体異常情報に基づいて、撮影画像を録画するか否かを判定する。

ここで、車両１０が駐車していて、被害が発生する疑い有りと判定していない時は、カメラ１１は、コマ落としで静止画像を撮影する。録画判定部２２Ｆは、画像分析部２２Ｃおよび音声分析部２２Ｄによる分析結果が、車両１０に接近する物体の検知を示す場合、被害が発生する疑い有りと判定する。車両１０に接近する物体とは、例えば、車両１０に接近する人物や他の車両などである。そして、録画判定部２２Ｆは、被害が発生する疑い有り、と判定すると、静止画撮影を動画撮影に切り替え、動画撮影によって得られる撮影画像の録画を開始する。録画を開始する、とは、撮影画像の記憶部２３への記録を開始することを意味する。

例えば、駐車中の車両１０が駐車している駐車枠の隣の駐車枠に駐車しようとする、他の車両を検知した場面を想定する。この場合、他の車両を検知した時点から静止画撮影を動画撮影に切り替え、画像記録部２２Ｅは、車両１０の周辺の物体の動きが無い状態が所定時間（例えば、１分間）継続するまで、動画撮影を継続する。これは、隣に駐車した車両のドアが開いて車両１０に当たるドアパンチが発生した時に、このドアパンチの瞬間を撮影画像として記録する為である。

また、録画判定部２２Ｆは、物体の接近など、被害が発生する疑いのある時、または、被害が発生したと判定したときに、静止画撮影を動画撮影に切り替え、動画撮影によって得られる撮影画像の録画を開始してもよい。また、録画判定部２２Ｆは、動画撮影以外のタイミングでは、撮影された静止画像を、低頻度で記憶部２３へ記録してもよい。低頻度とは、例えば１０秒毎に１コマの様に、予め定められた間隔でよい。

画像異常情報生成部２２Ｇは、撮影画像に基づいて、車体の外装の像の変化を評価して画像異常情報を生成する。

画像異常情報生成部２２Ｇは、画像分析部２２Ｃで抽出された撮影画像間の画像の差分を評価することによって、車体の外装の像の変化を評価する。そして、画像異常情報生成部２２Ｇは、画像分析部２２Ｃによる分析結果である撮影画像間の画像の差分が閾値以上である領域の情報を、異常部位を表す画像異常情報として生成する。このため、画像異常情報生成部２２Ｇは、例えば、撮影画像に含まれる、車両１０の被害箇所、または、車両１０に対する加害物候補、などの異常部位を表す、画像異常情報を生成する。車両１０の被害箇所は、例えば、車体の外装にキズや凹みなどが生じた箇所である。

被害判定部２２Ｈは、車体異常情報および画像異常情報に基づいて、車両１０の車体における被害の有無を判定する。本実施形態では、被害判定部２２Ｈは、車体異常情報に含まれる音声情報および加速度情報、並びに、撮影画像間の画像の差分、を総合して、被害の有無を判定する。

例えば、被害判定部２２Ｈは、録画判定部２２Ｆによって接近する物体が検知されて被害が発生する疑いがあると判定され、加速度が検知され、また加速度検知の前後の撮影画像間の画像に差分が抽出されている、などの符合する複数の異常を検出したときに、被害有り、と判定する。

なお、被害判定部２２Ｈは、顕著な異常を判定した場合には、１つの異常であっても被害有り、と判定してもよい。例えば、加速度検知の対象とする第一の加速度検知閾値よりも大きい、第二の加速度検知閾値を超えるような大きな加速度を検知した時は、撮影画像間の差分が検知されていなくても、被害有り、と判定しても良い。

また、被害判定部２２Ｈは、車両１０の隣の他車両のドアの動きを含む撮影画像に基づいて、ドアが車両１０に当たっているコマが存在するか否かを判定する。コマは、１フレーム分の撮影画像を意味する。そして、被害判定部２２Ｈは、他車両のドアが車両１０に当たっているコマが存在する場合、被害有り、と判定してもよい。また、被害判定部２２Ｈは、撮影画像に含まれる衝突前後の車両１０の像に、閾値を超える差分があった時だけ、被害有り、と判定してもよい。

なお、本実施形態では、車両監視装置２０では、コマ落としで静止画撮影している時も、動画撮影している時も、常時、画像分析部２２Ｃが画像の差分を抽出し、画像異常情報生成部２２Ｇがキズなどの画像異常情報を生成する形態を一例として説明する。そして、被害判定部２２Ｈは、画像異常情報および車体異常情報に基づいて、被害の有無を判定する。しかし、画像分析部２２Ｃは、閾値を超える加速度および音声の少なくとも一方が検知されるイベントがあったときに、イベントの前に撮影した撮影画像と、イベントの後に撮影した撮影画像と、の画像の差分を抽出してもよい。そして、被害判定部２２Ｈは、閾値を超える差分がある場合に、被害有り、と判定してもよい。

また、駐車中に車両１０が受けるキズは、点状である事は稀で、線状のキズであったり、面的な凹みであったりすることが多い。このため、被害判定部２２Ｈは、画素単位の差分が閾値を超えている画素が、所定の数を超えている場合に、車体にキズがあったと判定し、被害有り、と判定してもよい。

また、キズの位置は移動しないので、車体に構造物の影が落ちている場合に、影の位置が変化したことで生じる差分があっても、差分が生じた位置が移動している事が判る場合は、キズではない、と判定できる。このため、この場合、被害判定部２２Ｈは、差分が生じた位置の移動を根拠として被害無し、と判定してよい。なお、キズの有無の判定には、画像処理の任意の技術を用いてよい。

ここで、図４を用いて説明したように、本実施形態では、車両１０に搭載されたカメラ１１（カメラ１１Ｒ、カメラ１１Ｌ、カメラ１１Ｆ、カメラ１１Ｂ）は、それぞれ、１９０°程度の視野範囲がある。このため、画像異常情報生成部２２Ｇでは、車両１０の車体の外装の内、カメラ１１の視野範囲５０に映り込んだ部分の画像異常情報を生成することができる。また、上述したように、加速度センサ１３は、３軸加速度センサであり、車両１０の車体が前後方向、左右方向、および上下方向に、どれだけ加速されたかを個別に検知できる。

駐車中の車両１０は自ら加速する事はないので、駐車中の車両１０で検知される加速度は、外部からの力による。加速度は、波形として観測可能であり、物が衝突した時は鋭いスパイク状の波形となり、手で押された時は緩やかな波形になる。このため、例えば車両１０の左側に停車した他車両のドアが車両１０に勢いよく衝突した時には、加速度センサ１３では、車両１０の左側からの加速度が鋭いスパイク状の波形として検知できる。

また、図４を用いて説明したように、本実施形態では、車両１０には、複数の音響センサ１２（マイク１２Ａ、マイク１２Ｂ、マイク１２Ｃ、マイク１２Ｄ）が設けられている。これらの複数の音響センサ１２は、互いに異なる位置に配置されている。このため、これらの複数の音響センサ１２で音声を受信すると、音声を受信した時刻の時間差から、音声が来た方向を推定できる。例えば、車両１０の左のドアが音を発した時には、マイク１２Ｂが受信した音声の方が、マイク１２Ａが受信した音声よりもタイミングが早いので、音声が左から来たと判別できる。また、マイク１２Ｃおよびマイク１２Ｄのように、車両１０の後方にも音響センサ１２を設けることで、車両１０の前後方向の音声の到来方向も、推定可能である。つまり、後方にも音響センサ１２を設ければ、左側に停車した他車両のドアが車両１０の後部のドアに衝突した場合と、前部のドアに衝突した場合とを判別することが出来る様になる。

このため、被害判定部２２Ｈは、車両１０の左のドアにキズがある事を撮影画像で検知した時に、左からの加速度の検知や、左からの音声の検知があれば、複数の検知で方向の符合があると判定してもよいし、時刻の符合があると判定してもよい。なお、全てが符合する事は必須ではなく、例えば撮影画像では異常がない場合でも、音声と加速度で方向やタイミングの符合があれば、被害判定部２２Ｈは、被害有り、と判定してもよい。車体にはカメラ１１に映らない部分が有るので、撮影画像でキズが無い事だけを理由に、被害判定部２２Ｈが被害無し、と判定する事は好ましくない。

異なる符合の組合せとしては、例えば、車両１０の左側に駐車した他車両のドアが車両１０に押し当てられて凹みが生じた場合が挙げられる。この場合には、加速度の検知と画像の異常が符合するが、押し当てられた時に検知可能なレベルの音が出ない場合もある。更に、別の符合の組合せとしては、例えば、車両１０の左のドアに金属片で引っ掻きキズを付けられた場合が挙げられる。この場合には、音響センサ１２が引っ掻かれる音を検知し、撮影画像でも引っ掻きキズが検知されるが、加速度センサ１３が検知可能なレベルの加速度が生じない事がある。

なお、音響センサ１２や加速度センサ１３で検知可能な方向は、画像処理で特定できるキズなどの異常部位の位置ほど厳密でない。このため、被害判定部２２Ｈは、音響センサ１２や加速度センサ１３で検知された方向と、撮影画像で検知された方向と、が概ね同じであれば、方向が符合している、と幅広く判定してよい。また、時刻の符合についても同様に、被害判定部２２Ｈは、音響センサ１２や加速度センサ１３の検知遅れや信号処理の時間間隔を考慮して、符合を幅広く判定してよい。例えば、車両１０の駐車中は、カメラ１１はコマ落としで撮影を行っている。このため、被害判定部２２Ｈは、車体の像に差分がある２コマの撮影画像間のタイミングで検知した、加速度や異常音があれば、符合する、と判定してもよい。また、被害判定部２２Ｈは、前後１コマは誤差範囲内として、符合の有無を判定してもよい。

また、被害判定部２２Ｈは、以下に示す第１条件および第２条件の少なくとも一方の条件を満たす場合、第１条件および第２条件のいずれの条件も満たさない場合に比べて、被害有り、と判定し易くしてもよい。

第１条件とは、加速度センサ１３による加速度の検知時刻、音響センサ１２による音声の検知時刻、および、画像異常情報の検出時刻、のうち少なくとも二つが符合する事を基準とする条件である。第２条件とは、加速度センサ１３によって検知された加速度の方向、音響センサ１２によって検知された音声の方向、および、画像異常情報が検出された車体の被害部位の方向、のうち少なくとも二つが符合する事を基準とする条件である。

ここで、閾値を超える加速度の検知や閾値を超える音声を検知するイベントが発生したときは、車両１０の車体が被害を受けている可能性がある。このため、前記のイベントが発生したときは、録画判定部２２Ｆで動画像の録画を開始したり、被害判定部２２Ｈが被害有り、と判定して、後述する被害報告部２２Ｊで事故報告サーバ３０および被害者携帯端末４４の少なくとも一方に被害報告を行ったりする。しかし、検知された加速度や音声が、例えば、機械式駐車場の作動によるものだったり、嵐などの自然現象によるものだったりする場合には、無駄な録画の実行や、使用者が煩わされる、などのデメリットを生じる。

そこで、車両監視装置２０では、加速度の検知と音声の検知と画像異常情報の検出との符合の有無を評価して、第１条件および第２条件のいずれの条件も満たさない場合、つまり、方向の符合や時刻の符合が無い場合には、イベントとして検知する閾値を引き上げ、動画撮影によって得られる撮影画像の録画を開始したり、被害者携帯端末４４へ報知したりする動作が、起き難くする調整をしてもよい。

例えば、閾値を超える加速度や音声の一方だけを検知していて、画像の差分の検知が無い場合を想定する。この場合には、車両監視装置２０では、加速度や音声をイベントとして判定する閾値を上げる制御を加えてもよい。また、この場合、検知される加速度や音声のレベルが平常に戻った時に、閾値を復旧する制御を更に加える事が好ましい。

また、録画判定部２２Ｆが録画すると判定した場合であっても、被害判定部２２Ｈが被害無し、と判定する場合がある。このため、録画判定部２２Ｆは、録画すると判定したときに被害判定部２２Ｈが被害無し、と判定した判定不一致の回数が所定回数以上であるときに、判定不一致の回数が所定回数未満であるときに比べて録画する、と判定し難くすることが好ましい。この所定回数は、不必要な録画で消費される記憶容量や電力を勘案して予め定めればよい。

次に、被害報告画像生成部２２Ｉについて説明する。

被害報告画像生成部２２Ｉは、車体異常情報、または画像異常情報と、撮影画像とに基づいて、車体の外装を車外の仮想視点から見た被害報告画像を生成する。

被害報告画像生成部２２Ｉは、被害判定部２２Ｈが被害有り、と判定した場合、被害報告画像を生成する。なお、被害報告画像の生成は、画像処理機能を有する機能ブロックが行えばよい。このため、例えば、画像分析部２２Ｃで被害報告画像を生成してもよい。

図６Ａおよび図６Ｂは、被害報告画像の生成の説明図である。図６Ａに示すように、カメラ１１は、撮影によって、車両１０の車体の外装の像を含む撮影画像を得る。例えば、カメラ１１Ｌによって撮影された撮影画像は、カメラ１１Ｌのカメラ視点Ｖ１を視点とした視野範囲５０Ｌの撮影画像である。

カメラ視点Ｖ１は、車両１０の側に立って外装の被害を確認しようとする人の目の位置よりも視点が低く、かつ車両に著しく近いので、カメラ視点Ｖ１から撮影した画像と、車両１０の外側に立った人が目で見た像との対応がわかりづらい恐れがある。そこで、被害報告画像生成部２２Ｉは、図６Ｂに示すように、カメラ視点Ｖ１を車両の外側に位置する仮想視点Ｖ２へと視点を移動させることにより、人が仮想視点Ｖ２から車両１０の被害部位を見た像と対応する画像を生成する。すなわち、被害報告画像生成部２２Ｉは、車両１０の外側、かつ上方に視点移動した仮想視点Ｖ２を視点とした視野範囲５２の画像を、被害報告画像として生成する。視点をカメラ視点Ｖ１から仮想視点Ｖ２に移動すると、例えばドアの中段に位置するキズＳは、被害報告画像上で、上下方向に拡大して表示されるため確認し易くなる。

但し、カメラ１１、例えばサイドミラー内に設置されたカメラ１１Ｌの撮影画像の場合、図６Ａの様な車体形状の車両１０であれば、ドアの上部がカメラ１１Ｌの視野範囲５０Ｌから外れた死角となるため、ドアの上部のＤの部分はカメラ１１Ｌの撮影画像に映らない。また、図６Ｂの様に、中段が丸く張り出した形状のドアであると、ドアの下部のＥの部分は張り出した部分に隠されるためにカメラ１１Ｌの撮影画像に映らない。カメラ視点Ｖ１から撮影した画像に映らない死角部分のうち、ドアの上部のＤの部分や、ドアの下部のＥの部分は仮想視点Ｖ２を起点とする視野範囲５２の中にあるので、被害報告画像上で何らかの像を表示する必要がある。これらの撮影画像には映らないが被害報告画像には表示される死角部分を車体の３Ｄモデルから合成した像で補う事も可能であるが、実際の車両の像と見分けにくい無傷の３Ｄモデルの像で代替すると、死角部分にキズが無いと誤解させる恐れがある。そこで、被害報告画像生成部２２Ｉを合成する画像処理では、撮影画像には映らない死角部分を、車体のワイヤフレームモデルの像、または、車体の色とは異なる色に着色した３Ｄモデルの像、などの様に、実画像と誤解される恐れが無い代替イメージ、で表し、撮影画像にも映った部分には、撮影画像を視点変換した画像をはめ込む様にする。

被害報告画像の生成について、詳細に説明する。被害報告画像生成部２２Ｉは、車体の表面に対応する射影面に、撮影画像を射影した射影像を、仮想視点Ｖ２から見た視点変換画像に変換する事により、被害報告画像を生成する。すなわち、被害報告画像生成部２２Ｉは、射影変換とカメラ視点Ｖ１から仮想視点Ｖ２への視点移動により被害報告画像を生成する。

被害報告画像生成部２２Ｉが被害報告画像を生成する際の仮想視点Ｖ２の方向は、加速度センサ１３によって検知された加速度の方向、音響センサ１２によって検知された音声の方向、および、画像異常情報によって表される異常を示す方向、の少なくとも１つと略一致する。車体から仮想視点Ｖ２までの水平距離と、地面に対する仮想視点Ｖ２の高さは、例えば車体側面の被害が検知された場合には、駐車枠が並列に並べられた駐車場において、自車両と隣接して駐車した車両との間に立った標準的な体格の人が、車体側面を覗き込む時の視点位置を想定して設定する。標準的な体格は性別や国や地域によって異なるが、例えば、車体から仮想視点Ｖ２までの水平距離を３０ｃｍ、地面に対する仮想視点Ｖ２の高さを１５０ｃｍ、としても良い。

図７は、射影変換と視点移動の一例の説明図である。カメラ１１による撮影は、三次元空間をカメラ視点Ｖ１から見た二次元画像である撮影画像６０に変換する。射影は、二次元画像を別の面に投影するものであり、スライドの画像をスクリーンに投影するプロジェクターの作用をイメージすればよい。

被害報告画像生成部２２Ｉは、撮影画像を射影面６４へ投影する。撮影画像が投影される射影面６４は、平面、曲面、の何れであってもよい。射影面６４を視点に対して傾けると、像は引き延ばされ、曲面に射影すると、画像は変形される。撮影画像上の画素を、射影面６４上の画素に対応付ける処理をマッピングと呼ぶ。射影面６４をカメラ視点Ｖ１から別の視点である仮想視点Ｖ２で見た画像に変換することを、視点変換と呼ぶ。また、視点変換により得られた画像を、視点変換画像６６と呼ぶ。射影面６４上の画像の内、視点変換で視点までの距離が近くなった部分は、視点変換画像６６上で拡大され、視点変換で視点までの距離が遠くなった部分は、視点変換画像６６上で縮小される。つまり、視点変換によっても、画像は変形される。

射影と視点変換を順に行うのではなく、撮影画像上の画素を、視点変換画像６６上の画素に、直接、対応付けるマッピング（変形）も可能である。処理が２ステップか１ステップかに依らず、撮影画像を変形して視点変換画像６６を得る処理を、視点移動と呼ぶ。射影や視点変換、視点移動は、マッピングテーブルにより画像を変形する処理で実行できる。

被害報告画像生成部２２Ｉは、上記の視点移動の処理により、撮影画像から視点変換画像６６を得る。

ここで、カメラ視点Ｖ１から仮想視点Ｖ２への視点移動は、“仮想的な視点移動”である。このため、実際に視点移動して撮影したものと、同じ画像を得ることはできない。すなわち、カメラ視点Ｖ１において死角であった部分の像は、仮想視点Ｖ２へと視点移動しても得られない。

図８は、死角の処理の説明図である。例えば、立方体Ｃを正面のカメラ視点Ｖ１から撮影した正方形の画像６０Ａを、仮想視点Ｖ２へ視点移動して、仮想的に斜め方向から立方体Ｃを撮影した様な視点変換画像６６とした場合を想定する。この場合、立方体Ｃの側面Ｄは、カメラ視点Ｖ１から撮影した時に死角になっており、撮影画像に写っていないので、撮影画像を視点変換画像６６にマッピングする際に、死角になっている側面Ｄの部分についてはマッピングする画素が無い。そこで、被写体が立方体Ｃであることが分かっている場合、死角になっている側面Ｄを３Ｄデータで補い、側面６３Ａがある様な視点変換画像６６を生成する。図８には、立方体Ｃの側面６３Ａを、ワイヤフレームと平面で補った例を一例として示した。

図９Ａは、被害報告画像６２の死角処理の一例の説明図である。被害報告画像生成部２２Ｉは、射影面６４に撮影画像を射影し、射影面６４において、撮影画像が射影されない領域は、撮影画像が射影された射影領域とは異なる形態の代替イメージで代替した、被害報告画像６２を生成する。

図示を容易にするため、車両１０のドアの側面１０Ｃの例で説明する。また、図９Ａには、ドアの側面１０Ｃの形状を簡単化して示した。カメラ視点Ｖ１から撮影された撮影画像を射影する射影面６４は、ドアの側面１０Ｃの形状の３Ｄモデルである。射影面６４を実物と一致させる事により、射影による変形を防止できる。

撮影画像では、ドアの上部のＤの部分は、カメラ１１の視野の外である為に死角になっており、ドアの下部のＥの部分はドアの張り出した部分の陰になる為に死角になっている。仮想視点Ｖ２から見た画像は、ドアを外から見た画像として見せるため、ドアの上部と下部も見せる必要がある。

そこで、本実施形態では、被害報告画像生成部２２Ｉは、車両１０の外装の３Ｄモデルである射影面６４に撮影画像をマッピングする。図９Ｂは、カメラ視点Ｖ１から撮影された撮影画像の一例である。図９Ｂの撮影画像は魚眼レンズを備えたカメラで撮影するので、車両１０の側面が大きく歪曲されて写っている。被害報告画像生成部２２Ｉは、撮影画像を射影面６４へマッピングする。魚眼レンズで撮影した画像は、通常、表示する前に歪曲を補正する処理を施すが、歪曲を補正する処理もマッピングで行うので、歪曲補正と射影変換を１回のマッピングで行う事が可能である。また、被害報告画像生成部２２Ｉは死角部分の処理として、死角であるＤやＥの部分にはマッピングをせずに、車両１０の外装のワイヤフレームモデルの像が代替イメージとして見える様に合成した、被害報告画像６２を生成する。

図１０は、射影面６４とする車体の３Ｄモデル６８の一例の説明図である。被害報告画像生成部２２Ｉは、３Ｄモデル６８を射影面６４として用いて、被害報告画像６２を生成する。

図１１は、被害報告画像６２の一例の模式図である。図１１に示すように、被害報告画像６２は、移動した視点である仮想視点Ｖ２から車体１０Ｂを見た画像である。被害報告画像６２は、図９Ｂに示す実写画像である撮影画像を射影した射影領域６２Ａと、死角の部分を代替イメージで代替した代替イメージ領域６３と、を含む。図１１には、代替イメージとして、車体１０Ｂの上部の死角の部分（６３、Ｄ）をワイヤフレームモデルの像６３Ｂで代替し、車体１０Ｂの下部の死角の部分（６３、Ｅ）を射影領域６２Ａに映った実際の車体の色とは異なる色に着色した３Ｄモデルの像６３Ｃで代替した例を示した。なお、代替イメージは、車体１０Ｂのワイヤフレームモデルの像、車体１０Ｂとは異なる色に着色した３Ｄモデルの像、に限定されず、例えば、死角部分を黒塗りした様なイメージであってもよい。

被害報告画像６２は、車両１０の使用者が車両１０に戻らずに被害を確認する事と、使用者が車両１０に戻った時に、被害報告画像６２と実際の車体１０ＢのキズＳの対応、および、加害者が撮影した撮影画像との対応を確認する際に、より確認を容易にする事を目的としている。このため、被害報告画像生成部２２Ｉは、車両１０に戻った時の使用者の視点位置を想定して視点移動する事により、見た目に近い被害報告画像６２を生成する。被害報告画像６２上のキズＳの位置は、実際の車体１０Ｂのキズと同じであり、車体の撮影画像に映らない構造物も表示してあるので、相対的にキズＳの位置を把握することが出来る。

なお、被害報告画像生成部２２Ｉは、画像異常情報によって表される異常部位を強調した被害報告画像６２を生成してもよい。キズＳは、異常部位の一例である。例えば、被害報告画像生成部２２Ｉは、被害報告画像６２でキズＳを発見しやすいように、画像の差分で検知したキズＳの位置を枠で囲むなどの強調処理を加えてもよい。また、この枠の表示領域を車両１０の使用者が操作指示したときに、枠内の画像を拡大表示したり、コントラストを向上させてキズＳを発見しやすくしたりする、等の工夫を加えてもよい。

図３に戻り説明を続ける。被害報告部２２Ｊは、被害判定部２２Ｈによる被害の判定結果に応じて、撮影画像または撮影画像に基づいて生成された画像を含む被害報告を、車両１０の外部の情報処理装置に報告する。詳細には、被害報告部２２Ｊは、被害報告を、通信制御部２２Ｋ、入出力部２１、通信装置１４、および公衆回線Ｎを介して、情報処理装置へ送信する。被害報告を報告する情報処理装置は、事故報告サーバ３０、および、被害者携帯端末４４、のうち少なくとも１つである。

本実施形態では、被害報告部２２Ｊは、被害報告画像６２を含む被害報告を、事故報告サーバ３０、および、被害者携帯端末４４、の少なくとも１つへ報告する。

本実施形態では、被害報告部２２Ｊは、車両１０の使用者の携帯端末４０である被害者携帯端末４４および事故報告サーバ３０の何れか一方または両方に、被害報告画像６２を被害報告の一部として転送する。なお、実施例として、車両監視システム１が事故報告サーバ３０を備える事は必須でなく、車両１０の使用者（すなわち被害者）が被害報告画像６２を見て被害を確認し、車両１０の所に戻って加害者と対応する構成でもよい。この場合、車両１０の使用者は、被害報告画像６２を見て車両１０の所に戻るべきか否かを決めることが出来る。また、車両監視システム１が事故報告サーバ３０を備える構成では、加害者側の事故報告の一部として、車両１０の被害部位を加害者が撮影した画像を事故報告サーバ３０に送信する事を求めるが、車両１０の使用者は、事故報告サーバ３０から加害者が報告した画像をダウンロードして被害報告画像６２と比較し、加害者が報告した画像が妥当か否か判断して事故報告サーバ３０に回答する様にしても良い。この時、加害者が報告した画像が妥当か否かに関わらず、被害部位被害者自身で撮影して事故報告サーバ３０に撮影画像を送信する様に被害者にも求め、事故報告サーバ３０側で事故報告の妥当性を判断できる様にしてもよい。この様に車両が報告する被害報告画像６２と、加害者が報告した画像と、被害者が報告した画像とを照合する様にすると、事故を捏造して保険金の詐取を狙う様な不正請求を予防することが出来る。

また、車両１０の使用者または車両１０の使用者である被害者の被害者携帯端末４４へ、最初に被害報告を送信する装置は、車両監視装置２０の被害報告部２２Ｊと、事故報告サーバ３０のいずれであってもよい。事故報告サーバ３０が被害者携帯端末４４へ被害報告を送信する場合、車両監視装置２０の被害報告部２２Ｊは、事故報告サーバ３０だけに被害報告を送信し、被害者携帯端末４４へは被害報告を送信しない。事故報告サーバ３０は、車両監視装置２０から受付けた被害報告を被害者携帯端末４４へ送信しても良いし、事故報告サーバ３０が被害報告画像６２を評価して、被害報告を肯定した場合だけ被害報告を被害者携帯端末４４へ送信する様にしても良い。例えば、受信した被害報告画像６２が、それ以前に受信していた被害報告画像と大差が無く、検知された加速度の情報が、機械式駐車場の作動によると指定される場合は、事故報告サーバ３０が被害報告をブロックして被害者携帯端末４４へ送信せず、車両１０の使用者を不必要に煩わせない様にすればよい。車両監視装置２０の被害報告部２２Ｊが被害者携帯端末４４へ直接、被害報告を送る構成にすると、被害者はより早く事態に対応する事が出来るが、被害報告が事故報告サーバ３０でフィルタリングされずに届くので、車両１０を見に行くと何も異常が無かったり、車両にキズがあるが、以前からあるキズだったり、という様な事も発生する。

事故報告要求部２２Ｌは、被害判定部２２Ｈによる被害の判定結果に応じて、事故報告を求める報知を車外に向けて実行する。事故報告を求める報知は、事故報告サーバ３０へのアクセスを求める要求を含む。

すなわち、本実施形態では、被害判定部２２Ｈが被害有りと判定、すなわち、車体外装の損傷があると判定した場合、車両監視装置２０は、車両１０の使用者である被害者の被害者携帯端末４４および事故報告サーバ３０の何れか一方または両方に報告を行う。また、この報告と同時に、車両監視装置２０の事故報告要求部２２Ｌは、加害者が事故報告サーバ３０にアクセスするＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を含む報知情報を表示して、加害者に事故報告を促す動作を行う。

本実施形態では、車両監視システム１は、事故報告サーバ３０を有する構成を中心に説明する。しかし、車両監視システム１の構成としては、事故報告サーバ３０は必須ではなく、車両１０の使用者である被害者が被害車両の所に戻って加害者を促し、事故を報告させる構成でもよい。但し、後者の方が、車両１０の使用者の負担が大きくなる。

報知情報について詳細を説明する。事故報告要求部２２Ｌは、ＵＲＬを含む文字列、ＵＲＬを含むＱＲ（Ｑｕｉｃｋ Ｒｅｓｐｏｎｓｅ）コード（登録商標）、またはＵＲＬを含むバーコード、のいずれかを報知情報として報知する。事故報告要求部２２Ｌは、報知情報の表示、報知情報の提示場所の表示、報知情報の提示場所の照明、報知情報の提示場所への視線誘導、および、報知情報の提示場所を表す音声の出力、の少なくも１つを行うことによって、報知情報の報知を行う。

ＵＲＬは、事故報告サーバ３０のＵＲＬであり、ＵＲＬへアクセスする事により、事故報告の手順の案内を受け、画像の送受、保険情報を含む事故処理を行うことが可能となる。

図１２Ａは、ＵＲＬを含むＱＲコードの一例を示す図である。図１２Ｂは、ＵＲＬを含むバーコードの一例を示す図である。

事故報告要求部２２Ｌは、事故報告サーバ３０へのアクセスを求める報知を車外に向けて実行すればよく、その手段は限定されない。例えば、車両１０の車室内にＵＲＬを含むＱＲコードを印刷したプレートを配置する。そして、事故報告要求部２２Ｌは、被害有り、と判定されたときに、ＱＲコードに照明を当てる制御を行うとともに、事故報告サーバ３０へのアクセスを求める音声を出力するように、車両１０に設けられたスピーカを制御してもよい。また、半透明なＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｉｓｔａｌ Ｄｉｓｐｌａｙ）パネルや有機ＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ）パネルを車外向けＨＭＩ１６として用い、この車外向けＨＭＩ１６を車窓に嵌め込む構成としてもよい。そして、事故報告要求部２２Ｌは、被害有り、判定されたときに、ＵＲＬを含むバーコードを車外向けＨＭＩ１６へ表示する様にしてもよい。また、最も簡易な提示方法としては、ＵＲＬを含む二次元コードを印刷したシールを、車両１０の窓や車体に予め貼っておき、それを携帯端末で読み込むように音声で指示もよい。

本実施形態では、ＵＲＬは、車両１０ごとに一意に定められている。例えば、事故報告サーバ３０を管理する保険会社は、保険契約ごとに異なるＵＲＬを発行する。このため、車両１０が車外に向けて報知するＵＲＬは、１台ごとに異なる。なお、保険会社は、ＵＲＬを車両１０ごとに予め発行してもよいし、車両１０が事故報告サーバ３０へアクセスした時点で、車両１０の契約番号や時刻などに応じてＵＲＬを決定してもよい。

ＵＲＬは、例えば、「ｈｔｔｐｓ：／／ａｂｃ＿ｈｏｋｅｎ．ｃｏ．ｊｐ／？Ｎｏ＝１２３４＆ＩＤ＝ｒｅｐｏｒｔ」の様な形式でよい。このＵＲＬを発信すると、事故報告サーバ３０である「ａｂｃ＿ｈｏｋｅｎ．ｃｏ．ｊｐ」が「？」以下のパラメータを受け取って、契約番号１２３４の車について、事故報告の受付をリクエストされていると判別する。

このように、保険契約毎にＵＲＬを変える事により、事故報告サーバ３０はＵＲＬを受信した時点で、アクセス元の契約番号を特定できる。保険会社は保険を契約する時に、契約者の氏名と車両番号を登録するので、事故報告サーバ３０では、被害者側から報告が無くても事故証明書の被害者側の記載事項を埋めることが出来る。事故証明書は、事故を特定する事項を付記して事故が発生した事を証明するものであり、出願時点の日本の制度では、事故証明書は警察官が作成した調書に基づいて自動車安全運転センターが発行する。つまり、警察官が事故証明書を作成する訳ではないし、警察が事故証明書を発行する訳でもない。しかし、本願は警察制度や関係団体の区分とは関係せず、被害者や加害者に必要なのは調書の作成ではなくて事故証明書の発行なので、実施例中で、警察官が事故証明書を作成する、または、警察が事故証明書を発行する、の様に組織や書類の区別を無視して説明する事があっても、被害者や加害者の実感に沿った表現として御容赦頂きたい。

本実施例のシステムを用いて、加害者が加害者携帯端末４２を用いて、報知されたＵＲＬにアクセスし、加害者側の記載事項の情報を提供すれば、事故証明書の作成に必要な情報が揃う事になる。一方、従来のシステムでは、加害者が自主的に警察に電話し、事故報告を行おうとした時に、警察から被害者を探す様に言われる事がある。これは、事故報告書の作成には当事者双方の供述が必要であり、当事者双方が警察署に出頭する場合は、警察は現場に出動せずに済むからである。しかし、駐車中の車両に衝突した時に、その被害車両の使用者が居合わせる確率は低く、探しても見つかるとは限らないし、被害者が見つからなければ警察に出動を依頼して警察官の到着を待つことになるので、加害者が現場に長時間、拘束される結果となる事がある。本願が開示する、加害者が事故報告サーバ３０に加害者側の記載事項の情報を提供し、事故報告サーバ３０が被害者側の記載事項の情報を補って警察に報告するシステムが実施されれば、加害者は被害者を探す必要が無くなり、加害者として事故報告サーバ３０への報告を終えれば警察への報告義務が満たされる事になるので、現場を立ち去っても構わない。つまり、加害者の負担が大幅に軽減される効果があり、更に、加害者が被害者に接触したり、加害者が被害者の個人情報を知ったりする事も不要なので、個人情報保護の効果もある。

また、被害者も、車両１０に戻った時に、加害者の報告、特に被害車両の被害報告画像６２が、実際の被害と相違ない事を確認すれば良いので、急いで車両１０の所に戻る必要は無い。むしろ、被害者は、加害者が報告を終わるまで待って車両１０の所に戻る様にする事により、加害者との接触や顔を知られる事を避け、個人間のトラブルに巻き込まれる事を回避する事が出来る。

このように、契約番号毎にＵＲＬを変える事により、加害者および被害者の双方の、時間的および心理的な負担軽減と、個人情報保護の効果を得ることが出来る。

また、事故報告サーバ３０には、車両１０、加害者携帯端末４２、被害者携帯端末４４、および、警察官携帯端末４６、がアクセスする。このため、アクセス元の発信者がだれか判別可能となるように、ＵＲＬの上記「？」以下のパラメータを、発信者の種類ごとに個々に変えてもよい。例えば、ＵＲＬの上記「？」以下のパラメータを、以下のようにすればよい。

車両１０は、「？Ｎｏ＝１２３４＆ＩＤ＝ｃａｒ」
加害者の加害者携帯端末４２は、「？Ｎｏ＝１２３４＆ＩＤ＝ｒｅｐｏｒｔ」
被害者の被害者携帯端末４４は、「？Ｎｏ＝１２３４＆ＩＤ＝ｏｗｎｅｒ」
警察官の警察官携帯端末４６は、「？Ｎｏ＝１２３４＆ＩＤ＝ｐｏｌｉｃｅ＆ＰＷ＝＊＊＊＊」

例えば、保険証書に表示されたＱＲコードで、車両１０のオーナー用アプリケーションをダウンロードした場面を想定する。この場合、このアプリケーションは、「ｈｔｔｐｓ：／／ａｂｃ＿ｈｏｋｅｎ．ｃｏ．ｊｐ／？Ｎｏ＝１２３４＆ＲＱ＝ｏｗｎｅｒ」をアクセスする様にすればよい。

また、事故報告サーバ３０が警察に報告するメールには、警察用のＵＲＬを記載して、そのＵＲＬでのアクセスに対して特別な権限を与え、加害者と被害者の個人情報を含むデータを確認した上で承認を求めてもよい。警察用のＵＲＬにパスワードを付けるのは、不正アクセスによる個人情報漏洩や改竄を防ぐためであり、特別権限のＵＲＬを推定されない様に、事故毎にパスワードを異ならせておくことが好ましい。

なお、事故報告を求める報知は、個人情報保護方針を表す報知を含んでいてもよい。また、事故報告を求める報知は、運転免許証または関係車両の写真の送信を要求する報知を含んでいてもよい。

事故報告を求める報知が、運転免許証または関係車両の写真の送信を要求する報知を含むことで、報知に基づいて事故報告サーバ３０へアクセスした加害者の加害者携帯端末４２は、事故証明書の作成に必要な情報を事故報告サーバ３０へ容易に提供することができる。また、事故報告サーバ３０は、事故証明書の作成に必要な情報、例えば、携帯端末の加入者番号（電話番号）を、加害者の加害者携帯端末４２から取得することが出来るが、加害者携帯端末４２から情報を取得する段階、または事故報告サーバ３０へ情報を送信する段階で、加害者の同意を求める事が望ましい。

また、事故報告を求める報知は、加害者に伝えるメッセージを含んでいてもよい。

加害者に伝えるメッセージは、例えば次のような音声であってもよい。「事故の当事者は警察に報告する義務があります。後部窓に掲示したＱＲコードを読み、そのＵＲＬにアクセスすると、保険会社の報告代行サービスを利用して警察に報告できます。あなたが入力した個人情報は、警察と保険会社だけに開示され、被害者には開示されません。」

加害者携帯端末４２がＵＲＬにアクセスすると、例えば、以下のメッセージが加害者携帯端末４２のＵＩ部４２Ｂに表示される。

ＵＲＬにアクセスすると表示されるメッセージは、例えば、「警察に報告する情報を入力するアプリケーションをダウンロードします。アプリケーションのサイズは〇〇ＭＢです。ダウンロードに同意しますか？」などである。アプリケーションは、事故報告アプリケーションである。

事故報告アプリケーションが加害者携帯端末４２にダウンロードされて起動すると、以降の処理を事故報告アプリケーションが引き継ぐ。例えば、事故報告アプリケーションは、加害者携帯端末４２のカメラ４２Ｃを起動して枠付きのカメラ画像をＵＩ部４２Ｂに表示し、以下のメッセージを順に表示する。

（１）「位置情報を取得して送信する事を許可して下さい」
（２）「あなたの電話番号とメールアドレスを取得して送信する事を許可して下さい」
（３）「以後に撮影する画像を警察への報告に使用する事を許可して下さい」
（４）「あなたの運転免許証が枠内に入るように撮って下さい」
（５）「あなたの自動車賠償責任保険証明書が枠内に入るように撮って下さい」
（６）「被害車両は、右側面への衝突を報告しています。被害車両の右側面全体が枠内に入る様に撮って下さい」
（７）「被害車両の衝突した部分に近づいて撮って下さい」
（８）「あなたの車の衝突した部分に近づいて撮って下さい」
（９）「警察への報告を実行したので現場を離れて構いません。任意保険の証書の撮影を求めるメールを送信しているので、帰宅後に対応して下さい。」
なお、以上のメッセージは一例であり、加害者の車のナンバープレートの写真や、加害者自身の顔写真を送る様に求めるメッセージを加えても良いし、言い回しを変えても良い。

加害者携帯端末４２を操作する加害者は、表示されるメッセージに従って加害者携帯端末４２を操作することで、事故証明書の作成に必要な加害者の各種の情報である事故証明情報を、容易に事故報告サーバ３０へ送信することができる。

加害者携帯端末４２にダウンロードされる事故報告アプリケーションの、本願の車両監視システムにおける役割は、警察への報告を簡単化し、加害者への負担を軽減する事にある。

本願の車両監視システムの一部である事故報告代行サービスの利用が簡単である事を周知すれば、報告の手間を嫌って、事故現場を去り、結果的に当て逃げとなる件数を減らすことが出来る。また、事故報告代行サービスが使える車両１０では、加害者側から補償を得られる確率が高い、という実績が得られれば、本実施形態の車両監視装置２０を備えた車両１０を多く販売することが出来る。

また、事故報告アプリケーションによって、事故証明書の記載事項を画像から読み取らせる事により、加害者の報告作業をほぼ撮影だけにすることが出来る。画像から文字情報を読み出すＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅｃｏｇｎｉｔｉｏｎ：光学的文字認識）処理は、事故報告サーバ３０側で行ってもよいが、事故報告アプリケーション側でＯＣＲ処理を行い、画像ではなくテキスト情報を事故報告サーバ３０に送るようにしてもよい。その方が、通信費を軽減でき、報告作業の時間も短縮出来る可能性がある。

なお、加害者には被害車両の撮影を求めるが、被害車両が送信した被害報告画像６２を事故報告アプリケーションに表示させて、被害報告画像６２と同じアングルで被害車両を撮影する様に求めてもよい。この様に、撮影のアングルを一致させる事により、加害者が報告する被害画像の妥当性を、より容易に確認することが出来る。

次に、事故報告サーバ３０について説明する。事故報告サーバ３０の制御部３０Ｄは、車両１０の車両監視装置２０から、公衆回線Ｎおよび通信部３０Ａを介して被害報告を受信すると、事故報告の処理を開始する。

上述したように、車両監視装置２０は、被害有り、と判定すると、事故報告サーバ３０に被害報告を報告し、事故報告サーバ３０のＵＲＬを含む報知情報を報知する。加害者が、加害者携帯端末４２を用いてＵＲＬにアクセスすると、事故報告サーバ３０は、事故報告アプリケーションをＵＲＬから加害者携帯端末４２へダウンロードさせ、事故報告アプリケーションの指示に従わせる。事故報告アプリケーションの指示は、例えば、加害者の位置情報とメールアドレスなどの連絡先の提供、加害者の運転免許証と自賠責保険証書の提供、被害車両の被害部位である異常部位を撮影した撮影画像の送信、および、加害車両の衝突部位を撮影した撮影画像の送信、などの指示である。加害車両とは、被害車両に対して被害を与えた加害者が運転する車両である。被害車両とは、加害車両によって被害を加えられた車両１０である。すなわち、事故報告アプリケーションの指示は、事故証明書の作成に必要な情報である事故証明情報を加害者に提供させるための指示である。なお、事故報告アプリケーションを加害者携帯端末４２へダウンロードさせない場合、同様の情報のリストを加害者携帯端末４２へ示し、これらの情報または画像の提供を求めればよい。

事故報告サーバ３０の制御部３０Ｄは、ＯＣＲソフトウェアで、事故証明書の記載事項を画像から読取り、画像不鮮明な場合には、再撮影を要求するよう、事故報告アプリケーションを介して加害者携帯端末４２へ指示すればよい。この処理は、事故報告サーバ３０の制御部３０Ｄが行ってもよいし、事故報告サーバ３０を操作するオペレータが行ってもよい。

以上は、車両監視装置２０が先ず事故報告サーバ３０に報告し、続いて加害者が事故報告サーバ３０にアクセスする、最も典型的で、最も好ましいケースであるが、加害者が事故報告サーバ３０にアクセスしないケースも往々にして発生する。端的に言えば、当て逃げされた場合である。事故報告サーバ３０の制御部３０Ｄは、加害者から事故報告サーバ３０へのアクセスが無いまま、被害者携帯端末４４から、事故報告の提出、及び、被害届の提出を承認する承認情報を受信したときに、被害届を警察官の情報処理装置、または警察が管理する情報処理装置へ送信する。被害届は、加害者が報告しない時に、被害者から警察に行う報告である。被害者は車両監視装置２０から車両周辺の画像を送信させて、加害者または加害車両が周辺に無く、かつ、事故報告サーバ３０に加害者からのアクセスが無い時に、被害届の提出を承認すると良い。

具体的には、車両監視装置２０が被害有り、と判定し、事故報告サーバ３０または被害者携帯端末４４に被害報告を報告した後、所定の時間が経っても加害者からの報告が無く、被害者が被害を受けたことを確認した場合、事故報告サーバ３０の制御部３０Ｄは、当て逃げが行われたと判断する。事故報告サーバ３０の制御部３０Ｄは、被害者携帯端末４４から承認情報を受信した場合に、被害者が被害届の提出を承認したと判別する。なお、被害有りと判定した時に、車両監視装置２０が事故報告サーバ３０だけに被害報告を報告する場合は、加害者からの報告が無いまま所定の時間が経過した時点で、事故報告サーバ３０が被害者携帯端末４４に、被害を受けたことの確認と、被害届の提出の承認を求める報知をしても良い。

駐車中の車両１０に衝突する事故を起こした時は、加害者には警察に報告する義務がある。加害者が警察へ事故の報告をしていない場合、事故報告サーバ３０は、被害者の承認を条件として、警察へ被害届を送信する。その際に、事故報告サーバ３０の制御部３０Ｄは、車両監視装置２０から受付けた被害報告に含まれる被害報告画像６２や、衝突前後の撮影画像や、衝突を検知した時刻と衝突時の車両の位置情報などのデータを、被害届に添付して送信すればよい。

被害者の承認を待つ理由は、車両１０に実害が無かった場合や、被害が軽微なために、被害者が被害届を出さない判断をする場合や、加害者が事故報告サーバ３０にアクセスせずに警察に報告している場合があるので、不要に被害届を出さない様にする為である。当て逃げが行われたと判断し、被害者の被害確認と承認を得た上で被害届を提出する処理は、事故報告サーバ３０の制御部３０Ｄでは処理せず、事故報告サーバ３０のオペレータが人手で対応する事にしてもよい。

典型的には、車両監視装置２０が先ず事故報告サーバ３０に報告し、続いて加害者が事故報告サーバ３０にアクセスするが、車両監視装置２０から事故報告サーバ３０への報告が無いのに、加害者が事故報告サーバ３０にアクセスするケースも例外的に発生する。例えば、加害車両のドアが被害車両に弱い勢いで当たったために加速度が小さく、画像の比較でも被害を検知しなかった場合を想定する。この場合、被害車両から事故報告サーバ３０へのアクセスは行われないが、被害車両がＵＲＬを常時見える形で表示していると、衝突させた加害者が加害者携帯端末４２を用いて自ら事故報告サーバ３０にアクセスする事も考えられる。この時、事故報告サーバ３０は、事故の有無を調査する為に被害車両と通信し、車両監視装置２０を遠隔操作することで、車両監視装置２０に記録されている撮影画像や音響センサ１２および加速度センサ１３の検知結果を検索し、検知閾値以下と判定していた加速度や車体画像の差分に該当するものがあれば、被害有り、と判定を覆してもよい。また、事故報告サーバ３０は、被害車両の全周を撮影した撮影画像の送信を車両監視装置２０へ求め、顕著な被害が無いと判定した時には、報告を保険会社として受理したので現場を離れて良い事と、車両１０の使用者が合意した時は警察に報告しない事がある、と、加害者へ伝えてもよい。この様な処理は例外的な対応であるので、事故報告サーバ３０の制御部３０Ｄには処理させず、事故報告サーバ３０のオペレータが人手で対応するようにしてもよい。

また、車両１０からの報告も、加害者からの報告も無く、被害者からの報告が最初に事故報告サーバ３０に届く事がある。例えば、加害車両のドアが被害車両に弱い勢いで当たったために加速度が小さく、画像の比較でも被害を検知しなかった場合には、被害車両は事故報告サーバ３０へ報告しない。ここで、加害者も自主的に事故報告サーバ３０へ報告せず、被害者が車両１０の所に戻った時に、被害に気付いた場合には、形式的には当て逃げが行われた事になる。この時も、事故報告サーバ３０は、被害車両の車両監視装置２０を遠隔操作して、車両監視装置２０に記録された撮影画像や音響センサ１２および加速度センサ１３の検知結果を検索し、閾値以下と判定していた加速度や車体画像の差分があれば、被害有り、と判定を覆してもよい。この場合は、加害者に責任があり、警察への事故の報告が行われていないので、警察への連絡は被害届となる。その際に、事故報告サーバ３０は、車両監視装置２０を検索して得た、衝突の前後の撮影画像やデータを、被害届に添付して警察に報告すればよい。但し、車両監視装置２０が被害を検知しない場合は、被害が軽微な場合である事が多いので、被害者が被害届の提出を選択しない事もある。よって、事故報告サーバ３０は、被害者の承認を条件として被害届を送信する手順にする事が好ましい。

警察の警察官携帯端末４６は、事故報告サーバ３０が送信した事故報告または被害届を、事故当時者からの事故報告または被害届として受信する。警察官携帯端末４６も、事故報告サーバ３０のＵＲＬからアプリをダウンロードすることが出来るので、事故報告または被害届には撮影画像などを含めず、事故報告サーバ３０にアップロードされた画像やデータを警察官携帯端末４６がダウンロードしたアプリを介して参照可能にしたり、画像やデータを必要に応じて警察官携帯端末４６にダウンロード可能にしたりする様にしても良い。この時、加害者携帯端末４２がアクセス可能なのは加害者側の情報だけ、被害者携帯端末４４がアクセス可能なのは被害者側の情報だけであるのに対し、警察官携帯端末４６からは、被害者と加害者の両方の情報にアクセス可能に設定されている。事故報告や被害届には、当事者双方の連絡先（例えば両者の電話番号）の情報も含まれるので、必要に応じて、当事者に報告内容の説明を求めても良い。警察官は、確認した情報に従って事故証明書のもととなる調書などの一件書類を作成する。事故報告サーバ３０が作成する事故報告書が、事故証明書の書式に合わせて作成されていて記載内に疑義が無ければ、警察官は調書の作成作業として、その事故報告書を承認すればよい。警察官が以上の作業を前記のアプリ上で行う場合、承認作業は承認ボタンを押すだけで済む。警察官が承認した事が事故報告サーバ３０に伝われば、事故報告サーバ３０側の１件の処理が終了する。保険金の請求は、従来通り事故証明書の提出を条件としても良いが、警察官が事故報告を承認している事を条件とする方が、警察を含む全ての当事者にとって効率的である。

次に、車両監視装置２０、事故報告サーバ３０、加害者携帯端末４２、被害者携帯端末４４、および警察官携帯端末４６の各々が実行する情報処理の流れの一例を説明する。なお、以下で説明する情報処理の流れは一例であり、上述した各機能部が更に上述した各種の処理を実行してもよい。

まず、車両監視装置２０が実行する情報処理の流れの一例を説明する。図１３は、車両監視装置２０が実行する情報処理の流れの一例を示すフローチャートである。

画像取得部２２Ａが撮影画像を取得し、車体異常情報取得部２２Ｂが車体異常情報を取得する（ステップＳ１００）。画像分析部２２Ｃは、ステップＳ１００で取得された撮影画像を分析し、音声分析部２２Ｄは、音響センサ１２で検知された音声の音声情報を分析する（ステップＳ１０２）。

録画判定部２２Ｆは、ステップＳ１００で取得した車体異常情報に基づいて、撮影画像を録画するか否かを判定する（ステップＳ１０４）。ステップＳ１０４で否定判断すると（ステップＳ１０４：Ｎｏ）、ステップＳ１００へ戻る。ステップＳ１０４で肯定判断すると（ステップＳ１０４：Ｙｅｓ）、ステップＳ１０６へ進む。ステップＳ１０６では、録画判定部２２Ｆは、静止画撮影を動画撮影に切り替え、動画撮影によって得られる撮影画像の録画を開始する（ステップＳ１０６）。

画像異常情報生成部２２Ｇは、撮影画像に基づいて、車体の外装の像の変化を評価して画像異常情報を生成する（ステップＳ１０８）。被害判定部２２Ｈは、車体異常情報および画像異常情報に基づいて、被害有り、か否かを判定する（ステップＳ１１０）。被害無し、と判定した場合（ステップＳ１１０：Ｎｏ）、本ルーチンを終了する。被害有り、と判定した場合（ステップＳ１１０：Ｙｅｓ）、ステップＳ１１２へ進む。

ステップＳ１１２では、被害報告画像生成部２２Ｉが、車体異常情報または画像異常情報と、撮影画像と、に基づいて、車体の外装を車外の仮想視点Ｖ２から見た被害報告画像６２を生成する（ステップＳ１１２）。

被害報告部２２Ｊは、撮影画像または撮影画像に基づいて生成された被害報告画像６２を含む被害報告を、情報処理装置に報告する（ステップＳ１１４）。詳細には、被害報告部２２Ｊは、被害報告を、事故報告サーバ３０または、被害者携帯端末４４へ報告するが、ここでは、被害報告部２２Ｊは事故報告サーバ３０だけに報告し、被害者携帯端末４４への報告は事故報告サーバ３０が行うものとして説明を進める。なお、被害報告部２２Ｊが事故報告サーバ３０と被害者携帯端末４４の両方に報告する場合は、車両監視装置のフローチャートは変化しない。図示は略すが、被害報告部２２Ｊが被害者携帯端末４４だけに報告する場合は、被害者が被害者携帯端末４４を操作して、事故報告サーバ３０への報告を許可した時だけ、事故報告サーバ３０へ報告する様にしても良い。この場合のフローチャートでは、Ｓ１１４の後に、被害者携帯端末４４からの報告許可を待つループを追加する事になる。この際に、事故報告サーバ３０への報告を許可しない場合にＳ１１６もスキップして終了する様にしても良い。これは、例えば車載監視装置の異常検知の信頼性が低い場合に適しており、人による判断を入れて、人が判断して許可するまでは事故報告サーバ３０への報告を上げない様にする工夫である。このようにすると、誤った事故報告が行われる可能性は低くなるが、加害者へ事故報告を求める報知が遅れて、加害者が報告せずに現場を離れる可能性が高くなる欠点もある。

事故報告要求部２２Ｌは、事故報告を求める報知を車外に向けて実行する（ステップＳ１１６）。そして、本ルーチンを終了する。

次に、事故報告サーバ３０が実行する情報処理の流れの一例を説明する。図１４は、事故報告サーバ３０が実行する情報処理の流れの一例を示すフローチャートである。事故報告サーバ３０の制御部３０Ｄが行う各種の情報の送受信は、通信部３０Ａを介して行われる。

事故報告サーバ３０の制御部３０Ｄは、車両監視装置２０から被害報告を受信したか否かを判断する（ステップＳ２００）。ステップＳ２００で否定判断すると（ステップＳ２００：Ｎｏ）、本ルーチンを終了する。ステップＳ２００で肯定判断すると（ステップＳ２００：Ｙｅｓ）、ステップＳ２０２へ進む。

制御部３０Ｄは、加害者携帯端末４２から事故報告サーバ３０のＵＲＬにアクセスがあったか否かを判断する（ステップＳ２０２）。ステップＳ２０２で肯定判断すると（ステップＳ２０２：Ｙｅｓ）、ステップＳ２０４へ進む。なお、フローチャートの表記では、待ち受けのループを省略する事があるが、待ち受けを行う事を本文中で説明するので、ご容赦頂きたい。ここでは、ステップＳ２０２に進んだ時にカウントを開始するタイマーがあって、加害者携帯端末４２から事故報告サーバ３０のＵＲＬにアクセスが無い時は、前記のタイマーが所定の値を超えていない事を条件として、ステップＳ２０２に戻るループを省略している。つまり、Ｓ２０２では所定時間内に加害者携帯端末４２から事故報告サーバ３０のＵＲＬにアクセスがあればＳ２０４に進み、加害者携帯端末４２から事故報告サーバ３０のＵＲＬにアクセスが無い状態で所定時間が経過した時はＳ２１４に進み、それ以外の場合は、Ｓ２０２の判断を行うループに留まる。

ステップＳ２０４では、制御部３０Ｄは、事故報告アプリケーションを加害者携帯端末４２へダウンロードさせる（ステップＳ２０４）。ここでも、加害者携帯端末４２へのダウンロードは、加害者の操作に応じて行われるので、操作待ちのループがある。

制御部３０Ｄは、加害者携帯端末４２から、事故証明書の作成に必要な情報である事故証明情報を受信する（ステップＳ２０６）。事故証明情報の取得は加害者携帯端末４２で行われるので、ステップＳ２０６も待ち受けループを含むものと理解されたい。

制御部３０Ｄは、被害者携帯端末４４へ、事故報告の提出の確認情報を送信する（ステップＳ２０８）。制御部３０Ｄは、通信部３０Ａを介して被害者携帯端末４４から承認情報を受信したか否認情報を受信したかを判断し（ステップＳ２１０）、否認情報を受信すると（ステップＳ２１０：Ｙｅｓ）、ステップＳ２１２へ進む。ステップＳ２１２では、制御部３０Ｄは、事故報告を警察官の警察官携帯端末４６または警察が管理する情報処理装置へ通信部３０Ａを介して送信し（ステップＳ２１２）、本ルーチンを終了する。また、ステップＳ２１０で否認情報を受信した場合は（ステップＳ２１０：Ｎｏ）、事故報告を送信せずに本ルーチンを終了する。これは、例えば、軽微な損害であって警察に報告する必要は無いと被害者が判断した場合に当たる。ステップＳ２１０でも、被害者携帯端末４４からの承認情報も否認情報も受信していない間は、受信待ちでステップＳ２１０に留まるループを省略している。

一方、ステップＳ２０２で否定判断すると（ステップＳ２０２：Ｎｏ）、制御部３０Ｄは、被害者携帯端末４４へ、被害届の提出の確認情報を送信する（ステップＳ２１４）。そして、制御部３０Ｄは、被害者携帯端末４４から承認情報を受信したか否かを判断する（ステップＳ２１６）。ステップＳ２１６で否定判断すると（ステップＳ２１６：Ｎｏ）、本ルーチンを終了する。ステップＳ２１６で肯定判断すると（ステップＳ２１６：Ｙｅｓ）、ステップＳ２１８へ進む。ここでも、被害者携帯端末４４からの承認情報も否認情報も受信していない間は、受信待ちでステップＳ２１６に留まるループを省略している。

制御部３０Ｄは、当て逃げが行われたと判断し（ステップＳ２１８）、被害届を、警察官の警察官携帯端末４６または警察が管理する情報処理装置へ送信し（ステップＳ２２０）、本ルーチンを終了する。

次に、加害者携帯端末４２が実行する情報処理の流れの一例を説明する。図１５は、加害者携帯端末４２が実行する情報処理の流れの一例を示すフローチャートである。加害者携帯端末４２の制御部４２Ｄが行う各種の情報の送受信は、通信部４２Ａを介して行われる。

加害者携帯端末４２の制御部４２Ｄは、事故報告サーバ３０のＵＲＬにアクセスする（ステップＳ３００）。そして、制御部４２Ｄは、事故報告サーバ３０から、事故報告アプリケーションをダウンロードする（ステップＳ３０２）。

加害者携帯端末４２を操作する加害者は、表示されるメッセージに従って加害者携帯端末４２のＵＩ部４２Ｂを操作することで、事故証明書の作成に必要な加害者の各種の情報である事故証明情報を入力する。この加害者の操作によって、加害者携帯端末４２の制御部４２Ｄは、事故証明情報を取得する（ステップＳ３０４）。事故証明情報は、例えば加害者の免許証に記載された氏名などであり、加害者に自身の免許証を撮影させて、撮影画像をＯＣＲソフトで処理する事により氏名などを取得する。

制御部４２Ｄは、取得した事故証明情報を、事故報告サーバ３０へ送信する（ステップＳ３０６）。そして、本ルーチンを終了する。

次に、被害者携帯端末４４が実行する情報処理の流れの一例を説明する。図１６は、被害者携帯端末４４が実行する情報処理の流れの一例を示すフローチャートである。被害者携帯端末４４の制御部４４Ｄが行う各種の情報の送受信は、通信部４４Ａを介して行われる。なお、ここでは車両監視装置２０は被害者携帯端末４４に、直接には報告せず、被害者携帯端末４４への報告は事故報告サーバ３０が行う場合について説明する。

被害者携帯端末４４の制御部４４Ｄは、事故報告サーバ３０から被害報告を受信したか否かを判断する（ステップＳ４００）。ステップＳ４００で否定判断すると（ステップＳ４００：Ｎｏ）、本ルーチンを終了する。ステップＳ４００で肯定判断すると（ステップＳ４００：Ｙｅｓ）、ステップＳ４０２へ進む。

制御部４４Ｄは、事故報告サーバ３０から被害届の提出または事故報告の提出の確認情報を、事故報告サーバ３０から受信する（ステップＳ４０２）。つまり、加害者から報告があって警察への報告が事故報告となる場合と、加害者から報告が無くて警察への報告が被害届となる場合との、どちらの場合であるかは、被害者携帯端末４４が事故報告サーバ３０から被害報告を受信した時点で既に決まっている。

制御部４４Ｄは、ＵＩ部４４Ｂへ被害報告画像などの確認情報を表示し、被害者による操作指示によって承認の入力を受付けたか否かを判断する（ステップＳ４０４）。被害者が被害報告画像などを確認して、補償が必要と考えた場合は事故報告、または被害届の送信を承認し、ＵＩ部４４Ｂが承認の入力を受付けた場合（ステップＳ４０４：Ｙｅｓ）、制御部４４Ｄは、被害届の提出または事故報告の提出の承認情報を、通信部４４Ａを介して事故報告サーバ３０へ送信する（ステップＳ４０６）。そして、本ルーチンを終了する。

一方、被害者が被害報告画像などを確認して、被害が軽微なので補償が必要無い、つまり警察への届け出は必要ない、と考えた場合は事故報告、または被害届の送信を否認し、ＵＩ部４４Ｂが否認の入力を受付けた場合（ステップＳ４０４：Ｎｏ）、制御部４４Ｄは、被害届の提出または事故報告の提出の否認情報を、事故報告サーバ３０へ送信する（ステップＳ４０８）。そして、本ルーチンを終了する。ここでも、ＵＩ部４４Ｂが承認の入力も、否認の入力も受け付けていない間はＳ４０４に留まるループを省略している。

ここまで、車両監視装置２０が被害者携帯端末４４に、直接には報告せず、被害者携帯端末４４への報告は事故報告サーバ３０が行う場合について説明したが、被害者携帯端末４４が車両監視装置２０からの報告を事故報告サーバ３０と略同時に受信する様にしてもよい。この様にすると、被害者は車両が被害を受けた事を、早く知ることが出来る。但し、その様にすると、結果として被害者が被害現場に行って、加害者と接触する事態が発生する可能性が大きい。これは、本発明としては回避すべき事態であるので、説明の本筋から外しており、図示も略している。車両監視装置２０が被害者携帯端末４４に直接、報告する場合に、被害者携帯端末４４で採りうる加害者との接触の回避策としては、車両監視装置２０から受信した車両周辺画像を表示して、例えば、「加害者に報告を求める報知を行っているので、加害者が現場にいる間は車両に戻らない方が安全である」の様に、被害者に自重を求める報知を加えても良い。これはフローチャートでは、ステップＳ４０２に相当する動作であるが、結果として事故報告を提出するか、被害届を提出するかは加害者次第なので、Ｓ４０２を複数ステップに分けて、車両が送信した被害報告や周辺画像を表示するステップと、加害者の報告を所定の時間内は待ち受けるループと、加害者の報告の有無に応じて、被害届の提出、または事故報告の提出のいずれかを承認するよう求めるステップを設けても良い。

次に、警察官携帯端末４６が実行する情報処理の流れの一例を説明する。図１７は、警察官携帯端末４６が実行する情報処理の流れの一例を示すフローチャートである。警察官携帯端末４６の制御部４６Ｄが行う各種の情報の送受信は、通信部４６Ａを介して行われる。

警察官携帯端末４６の制御部４６Ｄは、事故報告サーバ３０から事故報告または被害届を受信したか否かを判断する（ステップＳ５００）。ステップＳ５００で否定判断すると（ステップＳ５００：Ｎｏ）、本ルーチンを終了する。ステップＳ５００で肯定判断すると（ステップＳ５００：Ｙｅｓ）、ステップＳ５０２へ進む。

制御部４６Ｄは、ステップＳ５００で受信した事故報告または被害届を、事故当時者からの事故報告または被害届として受信する（ステップＳ５０２）。事故報告または被害届は電子メールであり、記入された事故報告サーバ３０のＵＲＬにアクセス（ステップＳ５０４）すると、事故報告サーバ３０から警察用の事故報告アプリケーションをダウンロードする（ステップＳ５０６）。警察用の事故報告アプリケーションを実行すると、警察官は事故証明情報、つまり事故証明書の記載事項の情報や、事故を裏付ける車両の損害部位の撮影画像などの証拠を閲覧でき、必要に応じて閲覧した情報や撮影画像や事故証明書（案）の文書ファイルなどをダウンロードできる（ステップＳ５０８）。警察官は事故証明書の発行に必要な情報が得られたと判断した場合は、事故報告または被害届の受付を承認する承認情報を事故報告サーバ３０に送信し（ステップＳ５１０）そして、本ルーチンを終了する。

以上説明したように、本実施形態の車両監視装置２０は、画像取得部２２Ａと、車体異常情報取得部２２Ｂと、被害判定部２２Ｈと、被害報告部２２Ｊと、を備える。画像取得部２２Ａは、車両１０の車体の外装の像を含む撮影画像を取得する。車体異常情報取得部２２Ｂは、車両１０の異常を示す車体異常情報を取得する。被害判定部２２Ｈは、撮影画像および車体異常情報に応じて、車体における被害の有無を判定する。被害報告部２２Ｊは、被害の判定結果に応じて、撮影画像または撮影画像に基づいて生成された画像を含む被害報告を、情報処理装置に報告する。

従来技術では、合成画像を生成する際に、車両の全周囲の撮影画像を合成した全周囲画像の中央の自車両に相当する部分に、予め用意された車体の３Ｄモデルの像をはめ込んだ合成画像を生成していた。このため、車両の使用者が携行するスマートフォンに表示される合成画像の車体部分は、実際の車体の画像ではなく３Ｄモデルの像なので、実際の車両の外装の状態を確認できない。すなわち、車両が被害を受ける事故の発生時に、車両の使用者のスマートフォンに車両の周辺の画像が映るにも関わらず、その画像には車両自体の実際の像は映っていないので、車両の使用者自身が事故現場に赴いて、実際に車両の外装を目視で直接確認する必要があった。これは車両の使用者にとって、身体的負担である。また、被害者である車両の使用者が事故現場に行くと、加害者と対面する事が起こり、被害の補償を受ける為の事故処理の過程で被害者の個人情報を加害者に暴露する事を強いられる事態が発生する。この様な事は車両の使用者にとって、非常に大きな心理的負担である。つまり、従来技術では、車両の使用者の負担が大きい。

一方、本実施形態の車両監視装置２０では、画像取得部２２Ａは、車両１０の車体の外装の像を含む撮影画像を取得する。車体異常情報取得部２２Ｂは、車両１０の異常を示す車体異常情報を取得する。被害判定部２２Ｈは、撮影画像および車体異常情報に応じて、車体における被害の有無を判定する。被害報告部２２Ｊは、被害の判定結果に応じて、撮影画像または撮影画像に基づいて生成された画像を含む被害報告を、情報処理装置に報告する。

このため、本実施形態では、車両１０の使用者は、報告された被害報告を確認することで、車両１０の外装を目視で直接確認することなく、被害を確認することができる。

従って、本実施形態の車両監視装置２０は、車両１０の使用者の負担軽減を図ることが出来る。

従来技術である特許文献１の技術は、車外の画像を携帯端末で見る事が出来るが、従来の俯瞰表示では、自車両はモデルに置き換えているので、自車両の被害を確認する事が出来ない。例えば、隣の車に乗る人がドアを開けた時に、自車両に当たった場合には、当てた人が車に乗ってドアを閉めると、携帯端末に表示された画像を見ても誰も写っていない状態となり、自車両のキズも写らないので、被害があるにもかかわらず、携帯端末に表示された画像の見た目から異常はない無いと誤解する恐れがある。また、後述の通り、加害者が事故を報告せずに現場を立ち去ってしまうと、使用者の経済的損失となる可能性が大である。

また、従来の車両監視装置では、加速度センサで車体が受けた力を検知しているので、近くを通過する車の風圧や、機械式駐車場の作動も検知する事がある。つまり、被害が無いのに衝撃があったと通知され、通知に応じて車外の画像を携帯端末で確認する事も起きる。この様な徒労に終わる確認作業は、使用者にとって時間的損失や精神的負担となる。実際に被害があった時、被害車両の使用者である被害者が携帯端末で見た画像に加害者側が映る事があり、それが、被害者に現場に行く事を躊躇わせる結果になる事もある。実際、駐車場でのトラブルが傷害事件や殺人事件に発展した例も数多くあるので、駐車場で加害者に対面する事は、被害者にとって非常に大きな精神的負担になる。しかし、駐車場に行かず、加害者を立ち去らせてしまうと、加害者の特定が困難になり、スムーズに補償を受ける事は期待できなくなる。車両監視装置が記録した画像を警察に提示して捜査を求める事は可能であるが、加害者の特定や被害の証明が出来ない事も多いので、使用者の経済的損失となる可能性が大である。

また、加害者が自主的に警察に届け出るなどして、加害者の保険で補償が受けられる場合も、事故証明書に加害者と被害者の個人情報が併記されるために、加害者と被害者の間で、個人情報が相互に開示される事になる。これは「本人の意思に反して個人情報を開示されない」、という個人情報保護の原則に反している。

一方、本実施形態の車両監視システム１は、車両監視装置２０と、車両監視装置２０と通信する情報処理装置と、を備える。情報処理装置は、事故報告代行サービスを提供する事故報告サーバ３０、車両１０に対する被害者の携帯端末である被害者携帯端末４４、および、車両１０に対する加害者の携帯端末である加害者携帯端末４２、の少なくとも１つである。また、情報処理装置は、警察官の情報処理装置である警察官携帯端末４６、または警察が管理する情報処理装置、を更に含んでいてもよい。

そして、これらの車両監視装置２０、事故報告サーバ３０、加害者携帯端末４２、被害者携帯端末４４、および警察官携帯端末４６は、本実施形態で説明した上記処理を実行する。

このため、本実施形態の車両監視システム１は、使用者の負担と損失を最小にすることができる。詳細には、本実施形態の車両監視システム１は、加害者が事故報告を容易に行う手段を提供する事により、加害者が事故報告をせずに立ち去る事を予防し、それによって、被害者が弁済を受ける事ができる様にする。また、車両監視システム１では、携帯端末４０を媒介手段として用いる事によって、不必要な異常検知の報告に煩わされない様にすることができる。また、車両監視システム１では、車体に被害がある場合には容易に被害を確認できるようにし、加害者には交渉窓口を提示して、被害者が加害者と対面したり個人情報を開示したりせずに補償を受けられる様にすることができる。

また、本実施形態の車両監視システム１によれば、関係者は各々、インセンティブを得ることができる。

まず、警察へのインセンティブについて説明する。

駐車中の車両１０への衝突は物損事故であり、当事者が警察に出頭する場合は、警察は出動しない。これは、物損事故は件数が非常に多く、警察の負担が大きいからである。例えば、物損事故の件数は、日本の２００９年度の統計では、７００万件／年であり、人身事故の約６倍である。そのため、加害者と被害者が警察に出頭できない、または、出頭しない場合に限って、警察は出動する。当事者が警察に出頭する理由は、保険の請求に事故証明書が必要だからである。ちなみに、事故証明書の発行は、オンライン申請が可能である。保険会社が事故証明書を求めるのは、事故の捏造による不正請求を防止する為であるが、そのために、刑事事件にならない７００万件の物損事故を警察に確認させている事になる。被害車両が事故を証明するデータを出力し、加害者が裏付ける画像と関係情報を提出して、警察が確認して事故証明書を発行するシステムにすれば、警察の負担を軽減できるし、保険不正請求詐欺を防止する事も出来る。

本実施形態の車両監視システム１によれば、警察の負担を軽減でき、また、保険不正請求詐欺を防止することができる。

次に、加害者側の課題と、加害者へのインセンティブについて説明する。

駐車中の車両１０への衝突は物損事故であり、警察に報告する「報告義務」が発生する。報告せず現場を去ると「当て逃げ」になる。日本の場合、刑は１年以下の懲役、または、１０万円以下の罰金である。しかし、被害車両の使用者が判らない場合は、被害車両を警察に見せる為に、警察の出動を求める事になり、加害者は現場に長時間、拘束される事になるし、警察の負担にもなる。また、被害者が不明な事が警察への報告を躊躇させ、結果的に当て逃げする誘因ともなる。

被害車両の使用者が現れた時の対応も、大きなストレスになる。警察を呼んでいる場合、被害者も現場に留まって貰う必要があるが、「買った肉が傷む」、「レストランを予約している」等、副次的な被害に対し、後で慰謝料を要求されるなどの長期的なトラブルが起きる事がある。

本実施形態の車両監視システム１では、加害者が事故報告サーバ３０に画像や情報を送ると、事故報告サーバ３０から警察へ自動的に報告される。被害車両が事故報告サーバ３０に画像や情報を送って被害者側からの報告もあれば、「報告義務」は充足される。このため、加害者は、被害者（被害車両の使用者）を待たずに現場を去る事が可能になり、拘束時間が短くて済む。また、本実施形態の車両監視システム１では、加害者の個人情報が原則的に被害者に開示されないシステムであるため、被害者から、後で慰謝料を要求されるなどのトラブルを恐れる必要が無くなる。

次に、被害者側の課題と、被害者へのインセンティブについて説明する。

従来の車両監視装置を用いた場合、駐車した車両１０への衝突を、被害者のスマートフォンなどの被害者携帯端末４４で通知されたら、買い物中でもイベント参加中でも、被害者は車両１０に戻らなければならない。特に手段を講じない限り、加害者が現場に留まって自主的に警察に報告する事は期待できないからである。加害者を特定できれば、加害者側または加害者側の保険の負担で修理できるのに対し、加害者が特定できない場合、修理費用は被害者の自腹または自分の保険の負担となる。後者の場合には、保険金の支払いを受ける代償として、保険料アップを招く事がある。そして、被害者が所用を放棄して車両１０に戻ったとしても、既に加害者が現場を去っている場合は、加害者に修理費用の負担を求める事が困難になる。加害者が特定できないので被害届を警察に出して捜査を依頼する事になるが、当て逃げは非常に件数が多く、警察が加害者を特定できる確率は非常に低いからである。

加害者が居た時の対応も、大きなストレスになる。被害者は加害者に弁償を要求する側になるので、被害者と加害者とで免許証を見せあうなどの個人情報の開示が必要であり、対応時の言動からトラブルになる事もある。また、加害者側の保険で弁償を受ける場合は、警察に報告して事故証明書の作成を求める必要がある。そのためには、警察の出動を求めるか、加害者と共に警察に出頭する必要がある。つまり、被害者は、事故対応の為に長時間、拘束される事になる。

一方、本実施形態の車両監視システム１によれば、加害者の情報提供と、被害車両の画像およびデータ送信で、警察への報告が充足され、修理代の補償が受けられる。このため、本実施形態の車両監視システム１を用いることで、被害者は車両１０に戻る必要が無くなり、加害者対応や警察対応で拘束される事も、加害者との個人情報の交換でトラブルになる恐れも、全て無くなる。

次に、保険会社側の課題と、保険会社へのインセンティブについて説明する。

保険会社が得られる利益として、事務の合理化がある。保険会社の事故処理の事務は、紙の書類の遣り取りが多く、電子化が出来ていない。例えば、事故証明書のオンライン発行の申請は、事故の当事者しか出来ないので、当事者（保険会社から見て保険金請求の申請者）から委任状を貰って、自動車安全運転センターの窓口で紙の事故証明書を受け取り、それを電子化するか、申請者に事故証明書の提出を求めて、提出された事故証明書の記載事項と、請求者が申告した情報とを目視で照合する作業が必要になる。保険会社が事故証明書を求める目的は、虚偽に基づく保険料の支払い請求、つまり保険金詐欺を防止することである。

保険金詐欺とは、例えば次のようなものである。人物Ａが駐車中の白い車に自車両を衝突させて、双方の車のバンパーが傷んだにも関わらず現場から逃走し、修理業者Ｃの店に損傷した自車両を持ち込んだとする。通常、自責で生じた自車両の損傷は保険適用外となり、その修理費用を保険金で賄うことは出来ないが、ここで仮定として、修理業者Ｃが、白い車に乗っていて保険適用外の自損事故で傷んだバンパーをまだ修理していない知人Ｂを紹介したとする。人物Ａと知人Ｂが警察官に物損事故を報告すると、警察官は当事者（人物Ａと知人Ｂ）に対して、該当車両を運転して警察署に出頭する様に求める。これは、事故現場の写真撮影や、第三者の目撃証言の聴取や、落下した塗料片などの採取といった、事故現場での裏付け捜査、つまり現場検証を省略する事を意味するが、当て逃げでなければ刑事事件にならない事と、物損事故が非常に多く、物損事故でも現場検証する規則にすると業務過多になる事を背景とした、止むを得ない方策でもある。この場合、警察官は、警察署で出来る裏付け捜査として、自主的に出頭した当事者双方に聴取し、双方の車両の傷んだバンパーを見比べて、聴取内容と矛盾が無ければ、聴取した通りの内容で調書を作成し、この調書に基づいて自動車安全運転センターが事故証明書を作成する。人物Ａが知人Ｂの車にぶつけたと証言した場合、人物Ａが契約している保険会社は事故証明書の提出を受けると、知人Ｂの車の損傷を修理する費用を保険金として支払う。この保険金を人物Ａと知人Ｂが山分けし、不足分を補って修理業者Ｃに修理を依頼すると、修理業者Ｃは２台の修理を受注する事ができる。

本実施形態の車両監視システム１によれば、被害車両が被害発生時に被害報告画像を作成し、事故報告サーバ３０に直ちに報告するので、事後的に事故を捏造して警察を騙す事は極めて困難になる。その結果、事実に反する事故証明書を根拠に保険金を詐取される事が予防できる。また、事故報告サーバ３０が窓口となって事故証明書の記載情報を収集し、警察が記載情報を確認して承認するシステムにすることができるので、事故報告サーバ３０が収集した情報が警察によって承認された時点で、保険料を支払う条件は充足された、と判定する仕組みにしてもよい。この様にすると、保険会社は、改めて事故証明書の発行を求める必要が無くなる。つまり、事故の届け出から保険料を支払うまでの作業を、事故報告サーバ３０上で完結させることが出来るので、保険会社の事故処理の事務は、紙の書類（例えば、事故証明書や事故証明書の交付を受ける為の委任状）を必須とする現在のシステムよりも、大幅に合理化できる。

よって、保険会社が本実施形態の事故報告サーバ３０を構築および運用する事により、事務処理コストを削減して利益を得る事は、経済的に合理的である。また、保険会社は、利益の一部を契約者に保険料の引き下げの形で還元してもよい。

次に、自動車会社へのインセンティブについて説明する。

日本の場合、２０２１年３月の時点で、自動車会社各社と保険会社各社が株主である「株式会社日本緊急通報サービス」が、ＨＥＬＰＮＥＴ（緊急通報サービス）を提供し、自動車会社の各社では、は緊急通報ボタンや加速度に応じて自動通報する機能を備えた車を、高付加価値のラインで販売している。高付加価値のラインは、例えば、高級車である。但し、緊急通報の通報先は警察と消防または救急車であり、物損事故の保険処理には対応しない。つまり、高付加価値のサービスとして向上の余地がある。

一方、本実施形態の車両監視システム１を適用することで、自動車メーカーは、駐車中の車両が被害を受ける事故があった時に、オーナーが事故対応に煩わされずに補償を受けられる事故報告機能を搭載した、より高付加価値の商品として車両１０を販売できる。また、保険会社が事故報告機能を備える車両１０を対象として保険料を引き下げる場合、販売店は、当該機能を実質的に割安に利用できる事をアピールできる。つまり、本実施形態の車両監視システム１を適用することで、より高付加価値のサービスを、割安感を演出しつつ提供できる。

次に、加害者と被害者の間の個人情報保護の仕組みを説明する。

自動車事故が発生した時は、当事者間で運転免許証を相互に確認する事が通例である。事故証明書にも当事者の個人情報が記載され、当事者は事故証明書を取得できる。つまり、加害者は被害者の車へ加害行為を行うと、被害者の個人情報を入手できる事になるが、これが常識的に広く行われている。

しかし、これは「本人の意思に反して個人情報を開示されない」、という個人情報保護の原則に反している。特に、被害者には何らの過失も無いのに、本人の意思に関わらず、加害者に個人情報を開示する事を強いられるので、全く理不尽である。

物損事故では、被害者は、加害者側の保険会社から修理費用を補償されれば良いので、そのために加害者に個人情報を開示させられたり、加害者の個人情報を知ったりする事は不要なはずである。加害者も、個人として被害者に弁償するのではなく、事故の保険金として保険会社が補償するので、被害者に個人情報を開示したり、被害者の個人情報を知ったりする事は不要なはずである。よって、例えば、個人情報保護の原則に則って、「相手側の同意のもとに、相手側の個人情報が記載された事故証明書を取得できる」（例えば、相手側の同意がない場合は、相手側の個人情報が黒塗りされた事故証明書が交付される）事を原則とし、裁判で争う場合に開示請求する手段を設けておけば、個人情報保護と知る権利を両立することが出来る。

加害者が当て逃げをする心理的要因として、被害者と個人的なトラブルになる事を恐れる事がある。事故の時点で、車両から個人情報が被害者に開示されず、保険会社が補償を代行する事の説明があれば、加害者が報告を躊躇する理由が一つ減る事になる。

上記で説明したように、本実施形態の車両監視システム１では、車両監視装置２０の事故報告要求部２２Ｌが行う事故報告を求める報知は、加害者に個人情報保護の方針を伝えるメッセージを含んでいてもよい。例えば、上述したように、加害者に伝えるメッセージは、例えば次のような音声であってもよい。「事故の当事者は警察に報告する義務があります。後部窓に掲示したＱＲコードを読み、そのＵＲＬにアクセスすると、警察に報告できます。あなたが入力した個人情報は、警察と保険会社だけに開示され、被害者には開示されません。」

このため、本実施野形態の車両監視システム１を適用することで、加害者が報告を躊躇することを抑制することができる。

なお、上述した実施の形態における、上記情報処理を実行するためのプログラムは、上記複数の機能部の各々を含むモジュール構成となっており、実際のハードウェアとしては、例えば、ＣＰＵ２５ＡがＲＯＭ２５Ｂから情報処理プログラムを読み出して実行することにより、上述した複数の機能部の各々がＲＡＭ２５Ｃ上にロードされ、上述した複数の機能部の各々がＲＡＭ２５Ｃ上に生成されるようになっている。なお、上述した複数の機能部の各々の一部または全部を、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）またはＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）などの専用のハードウェアを用いて実現することも可能である。

なお、上記には、実施の形態を説明したが、上記実施の形態は、例として提示したものであり、本開示の範囲を限定することは意図していない。上記新規な実施の形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。上記実施の形態は、本開示の範囲または要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１ 車両監視システム
１０ 車両
２０ 車両監視装置
２２Ａ 画像取得部
２２Ｂ 車体異常情報取得部
２２Ｅ 画像記録部
２２Ｆ 録画判定部
２２Ｇ 画像異常情報生成部
２２Ｈ 被害判定部
２２Ｉ 被害報告画像生成部
２２Ｊ 被害報告部
２２Ｌ 事故報告要求部
３０ 事故報告サーバ
４２ 加害者携帯端末
４４ 被害者携帯端末
４６ 警察官携帯端末

Claims (20)

1. 車両の車体の外装の像を含む撮影画像を取得する画像取得部と、
   前記車体の異常を示す車体異常情報を取得する異常情報取得部と、
   前記撮影画像および前記車体異常情報に応じて、前記車体における被害の有無を判定する被害判定部と、
   前記被害の判定結果に応じて、前記撮影画像、または前記撮影画像に基づいて生成された画像を含む被害報告を、情報処理装置に報告する被害報告部と、
   前記撮影画像を記録する画像記録部と、
   を備え、
   前記画像記録部は、
   前記車体異常情報に基づいて、前記撮影画像を録画するか否かを判定する録画判定部を有し、
   前記録画判定部は、
   録画すると判定した時に前記被害判定部が被害無し、と判定した判定不一致の回数が所定回数以上であるときに、前記判定不一致の回数が所定回数未満であるときに比べて録画すると判定し難くする、
   車両監視装置。
2. 前記撮影画像に基づいて前記車体の外装の像の変化を評価して画像異常情報を生成する画像異常情報生成部、
   を備え、
   前記被害判定部は、前記車体異常情報、および前記画像異常情報に基づいて、前記車体に対する前記被害の有無を判定する、
   請求項１に記載の車両監視装置。
3. 前記車体異常情報、または前記画像異常情報と、前記撮影画像とに基づいて、前記車体の外装を車外の仮想視点から見た被害報告画像を生成する、被害報告画像生成部、
   を更に備え、
   前記被害報告部は、
   前記被害報告画像を含む前記被害報告を、前記情報処理装置に報告する、
   請求項２に記載の車両監視装置。
4. 前記被害報告画像生成部は、
   前記車体の表面に対応する射影面に、前記撮影画像を射影した射影像を、前記仮想視点から見た視点変換画像に変換する事により、前記被害報告画像を生成する、
   請求項３に記載の車両監視装置。
5. 前記車体異常情報は、
   前記車両に設けられた加速度センサによって検知された加速度の情報、および、前記車両に設けられた音響センサによって検知された音声の情報、の少なくとも一方を含み、
   前記被害報告画像生成部が前記被害報告画像を生成する際の前記仮想視点の方向が、前記加速度センサによって検知された加速度の方向、前記音響センサによって検知された音声の方向、および、前記画像異常情報によって表される異常を示す方向、の少なくとも１つと略一致する、
   請求項４に記載の車両監視装置。
6. 前記被害報告画像生成部は、
   前記射影面に前記撮影画像を射影し、前記射影面において、前記撮影画像が射影されない領域は、該撮影画像が射影された射影領域とは異なる形態の代替イメージで代替した、前記被害報告画像を生成する、
   請求項４または請求項５に記載の車両監視装置。
7. 前記代替イメージは、
   前記車体のワイヤフレームモデルの像、または、前記車体の色とは異なる色に着色した３Ｄモデルの像である、
   請求項６に記載の車両監視装置。
8. 前記被害報告画像生成部は、
   前記画像異常情報によって表される異常部位を強調した前記被害報告画像を生成する、
   請求項３～請求項７の何れか１項に記載の車両監視装置。
9. 車両の車体の外装の像を含む撮影画像を取得する画像取得部と、
   前記車体の異常を示す車体異常情報を取得する異常情報取得部と、
   前記撮影画像および前記車体異常情報に応じて、前記車体における被害の有無を判定する被害判定部と、
   前記被害の判定結果に応じて、前記撮影画像、または前記撮影画像に基づいて生成された画像を含む被害報告を、情報処理装置に報告する被害報告部と、
   前記撮影画像に基づいて前記車体の外装の像の変化を評価して画像異常情報を生成する画像異常情報生成部と、
   を備え、
   前記被害判定部は、前記車体異常情報、および前記画像異常情報に基づいて、前記車体に対する前記被害の有無を判定し、
   前記車体異常情報は、
   前記車両に設けられた加速度センサによって検知された加速度の情報、および、前記車両に設けられた音響センサによって検知された音声の情報、の少なくとも一方を含み、
   前記被害判定部は、
   前記加速度センサによる加速度の検知時刻、前記音響センサによる音声の検知時刻、および、前記画像異常情報の検出時刻、のうち少なくとも二つが符合する第１条件、
   および、
   前記加速度センサによって検知された加速度の方向、前記音響センサによって検知された音声の方向、および、前記画像異常情報が検出された前記車体の被害部位の方向、のうち少なくとも二つが符合する第２条件、
   の少なくとも一方の条件を満たす場合、前記第１条件および前記第２条件のいずれの条件も満たさない場合に比べて被害有り、と判定し易くする、
   車両監視装置。
10. 車両の車体の外装の像を含む撮影画像を取得する画像取得部と、
    前記車体の異常を示す車体異常情報を取得する異常情報取得部と、
    前記撮影画像および前記車体異常情報に応じて、前記車体における被害の有無を判定する被害判定部と、
    前記被害の判定結果に応じて、前記撮影画像、または前記撮影画像に基づいて生成された画像を含む被害報告を、情報処理装置に報告する被害報告部と、
    前記撮影画像に基づいて前記車体の外装の像の変化を評価して画像異常情報を生成する画像異常情報生成部と、
    前記車体異常情報、または前記画像異常情報と、前記撮影画像とに基づいて、前記車体の外装を車外の仮想視点から見た被害報告画像を生成する、被害報告画像生成部と、
    を備え、
    前記被害判定部は、前記車体異常情報、および前記画像異常情報に基づいて、前記車体に対する前記被害の有無を判定し、
    前記被害報告部は、前記被害報告画像を含む前記被害報告を、前記情報処理装置に報告し、
    前記被害報告画像生成部は、前記車体の表面に対応する射影面に、前記撮影画像を射影した射影像を、前記仮想視点から見た視点変換画像に変換する事により、前記被害報告画像を生成し、
    前記被害報告画像生成部は、前記射影面に前記撮影画像を射影し、前記射影面において、前記撮影画像が射影されない領域は、該撮影画像が射影された射影領域とは異なる形態の代替イメージで代替した、前記被害報告画像を生成する、
    車両監視装置。
11. 前記被害の判定結果に応じて、事故報告を求める報知を車外に向けて実行する事故報告要求部を更に備える、請求項１～請求項１０の何れか１項に記載の車両監視装置。
12. 前記事故報告を求める報知は、
    事故報告代行サービスを提供する事故報告サーバへのアクセスを求める要求を含む、
    請求項１１に記載の車両監視装置。
13. 前記事故報告要求部は、
    前記事故報告サーバのＵＲＬを含む文字列、前記ＵＲＬを含むＱＲコード、または前記ＵＲＬを含むバーコード、のいずれかを報知情報として報知し、前記報知情報の表示、前記報知情報の提示場所の表示、前記報知情報の提示場所の照明、前記報知情報の提示場所への視線誘導、および、前記報知情報の提示場所を表す音声の出力、の少なくも１つを行うことによって、前記報知情報の報知を行う、
    請求項１２に記載の車両監視装置。
14. 前記ＵＲＬは、車両ごとに一意に定められている、
    請求項１３に記載の車両監視装置。
15. 前記事故報告を求める報知は、個人情報保護方針を表す報知を含む、
    請求項１１～請求項１４の何れか１項に記載の車両監視装置。
16. 前記事故報告を求める報知は、運転免許証または関係車両の写真の送信を要求する報知を含む、
    請求項１１～請求項１５の何れか１項に記載の車両監視装置。
17. 請求項１～請求項１６の何れか１項に記載の車両監視装置と、
    前記車両監視装置と通信する前記情報処理装置と、
    を備え、
    前記情報処理装置は、
    事故報告代行サービスを提供する事故報告サーバ、前記車両の使用者または前記車両の所有者である被害者の携帯端末、および、前記車両に対する加害者の携帯端末、の少なくとも１つである、
    車両監視システム。
18. 前記車両監視装置および前記事故報告サーバの少なくとも一方は、前記被害者の携帯端末へ、前記被害報告を送信する、
    請求項１７に記載の車両監視システム。
19. 前記事故報告サーバは、
    前記被害者の携帯端末から、事故報告の提出、または被害届の提出を承認する承認情報を受信したときに、被害届を警察官の情報処理装置、または警察が管理する情報処理装置へ送信する、
    請求項１７または請求項１８に記載の車両監視システム。
20. 前記警察官の情報処理装置、または警察が管理する情報処理装置は、
    前記事故報告サーバが送信した事故報告または被害届を、事故当事者からの事故報告、または被害者からの被害届として受信する、
    請求項１９に記載の車両監視システム。

Images