JP7348725B2 - 配信システム、配信方法および車載装置 - Google Patents

Description

本発明は、配信システム、配信方法および車載装置に関する。

従来、例えば、車両に搭載されたドライブレコーダなどの車載装置で撮像されたカメラ画像を他の車載装置へ配信する車載システムがある。このような車載システムでは、ユーザが所望する位置のカメラ映像をリアルタイムで確認することができる（例えば、特許文献１参照）。

特開２０１０－２３８２０９号公報

しかしながら、従来技術では、迅速にカメラ画像を配信するうえで改善の余地があった。具体的には、従来技術では、例えば、ユーザ操作に基づいて、カメラ映像の送信元となる車載装置と、受信側の車載装置とを選択したうえで、双方の車載装置の通信接続が開始されるため、カメラ画像を実際に受信側の車載装置が受信するまでに時間が掛かっていた。

本発明は、上記に鑑みてなされたものであって、迅速にカメラ画像を受信することができる配信システムおよび配信方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る配信システムは、選択部と、受信部とを備える。選択部は、車両で撮像されたカメラ画像の配信候補となる候補車両を所定条件に基づいて選択する。受信部は、前記選択部によって選択された前記候補車両との通信接続を開始しておき、前記候補車両のうち、配信元として決定された配信車両から前記カメラ画像を受信する。

本発明によれば、迅速にカメラ画像を受信することができる。

図１は、配信システムの概要を示す図である。 図２は、車載装置のブロック図である。 図３は、送信リスト情報の具体例を示す図である。 図４は、受信部による処理内容を説明する説明図である。 図５は、決定部による処理の具体例を示す図である。 図６Ａは、透かし画像の具体例を示す図（その１）である。 図６Ｂは、透かし画像の具体例を示す図（その２）である。 図７は、表示階層の具体例を示す図である。 図８は、カメラ画像の表示画面の一例を示す図である。 図９は、管理サーバのブロック図である。 図１０は、ユーザ情報ＤＢの具体例を示す図である。 図１１は、検出条件ＤＢの一例を示す図である。 図１２Ａは、選択部による処理の具体例を示す図（その１）である。 図１２Ｂは、選択部による処理の具体例を示す図（その２）である。 図１２Ｃは、選択部による処理の具体例を示す図（その３）である。 図１３は、車載装置が実行する処理手順を示すフローチャート（その１）である。 図１４は、車載装置が実行する処理手順を示すフローチャート（その２）である。 図１５は、車載装置が実行する処理手順を示すフローチャート（その３）である。 図１６は、管理サーバが実行する処理手順を示すフローチャートである。

以下、添付図面を参照して、本願の開示する配信システムおよび配信方法の実施形態を詳細に説明する。なお、以下に示す実施形態により本発明が限定されるものではない。

まず、図１を用いて、実施形態に係る配信システムおよび配信方法の概要について説明する。図１は、配信システムの概要を示す図である。

図１に示すように、実施形態に係る配信システムＳは、各車両に搭載された車載装置１と、管理サーバ１００とを含む。車載装置１は、例えば、通信機能を備えたドライブレコーダである。車載装置１は、撮像したカメラ画像や、車両の位置情報、走行状態に関する情報などを所定周期で管理サーバ１００へ送信する。

管理サーバ１００は、各車載装置１から送信された情報を例えば、データベースで管理するサーバ装置である。また、車載装置１は、他の車載装置１で撮像されたカメラ画像を管理サーバ１００を介さずにリアルタイムで受信することも可能である。

尚、ここでいうリアルタイムとは、配信車両が受信車両へ送信するカメラ画像を、配信車両が取得した時間と同じ時間、または少なくとも受信遅れが感じないレベルで配信車両と受信車両間でカメラ映像が送受される状態をリアルタイムと定義している。

ところで、近年、ネットワークの普及に伴い、車載装置が、他の車載装置で撮像されたカメラ画像を取得し、車内のディスプレイに表示する車載システムが普及しつつある。しかしながら、従来技術においては、各車載装置がカメラ画像を迅速に取得するうえで改善の余地があった。

具体的には、従来技術では、カメラ画像を受信する車両の車載装置１に対するユーザ操作を契機として、カメラ画像を配信する車載装置１の選別や、車載装置１間の通信接続が開始される。このため、ユーザが配信されたカメラ画像を確認するまでにタイムロスが生じる。

そこで、実施形態に係る配信システムＳでは、カメラ画像の配信候補となる候補車両を選択しておき、カメラ画像を受信する受信車両と、候補車両との通信接続を予め開始しておくこととした。

具体的には、図１に示すように、車両Ｃ２が渋滞に遭遇した場合、車両Ｃ３の乗員は、「渋滞の原因はなんだろう」と思考する場合を想定する。この場合、例えば、管理サーバ１００は、車両Ｃ３の位置情報、走行経路や、各道路の渋滞情報に基づき、車両Ｃ３が渋滞に遭遇することを予め予測することができる。

尚、上記は渋滞の例であるが、渋滞のようなユーザが情報を欲する周囲状況等を想定しておき(管理サーバ１００が想定情報を保持)、カメラや各種センサからの情報、またインターネット等の外部ネットワークから取得した情報と言った車両周囲状況等から想定した状況の発生を検出・予測した場合に、ユーザから要望されるであろう情報を推定する(管理サーバ１００が各想定情報に応じた推定要望情報やその情報を得る条件の情報等を保持)、と言った処理により、いろいろな事象に対応するユーザの要望する情報（思考）を予測することが可能となる。

管理サーバ１００は、車両Ｃ３が渋滞に遭遇すると推定した場合に、例えば、渋滞の先頭付近にいる車両Ｃ１や、車両Ｃ２を候補車両として選択する（ステップＳ１）。なお、候補車両は、複数である必要はなく、１つの車両を候補車両として選択することも可能である。また、候補車両を選択する選択条件の具体例について図１１を用いて後述する。

そして、管理サーバ１００は、例えば、カメラ画像を受信する受信車両である車両Ｃ３に搭載された車載装置１に対して、車両Ｃ１や車両Ｃ２の車載装置１のネットワークアドレスを通知する。これにより、受信車両の車載装置１と、候補車両の車両Ｃ１および車両Ｃ２の車載装置１とが通信接続を開始する（ステップＳ２）。

その後、実施形態に係る配信システムＳでは、例えば、受信車両は、渋滞の先頭に位置する車両Ｃ１、すなわち、渋滞の因子を撮像可能な車両を配信元となる配信車両として決定し、配信車両からカメラ画像を受信する（ステップＳ３）。これにより、車両Ｃ３の乗員が渋滞の原因を知りたいと思うタイミングにおいて、カメラ画像の提供を開始することができる。

このように、実施形態に係る配信システムＳでは、配信元の候補となる候補車両と、受信車両との通信接続を予め開始しておくことで、受信車両の乗員が所望するタイミングにおいて、迅速にカメラ画像を受信することが可能となる。

また、実施形態に係る配信システムＳでは、配信車両から受信車両へカメラ画像のリアルタイム配信を行うことで、受信車両の乗員が気になる地点の現在の様子を容易に把握させることが可能となる。

次に、図２を用いて実施形態に係る車載装置１の構成例について説明する。図２は、車載装置１のブロック図である。図２に示すように、実施形態に車載装置１は、カメラ３１、車載センサ３２、ＧＰＳ（Global Positioning System）装置３３、ナビゲーション装置３４および端末装置３５が接続される。

カメラ３１は、車両Ｃの周囲を撮像するカメラであり、所定のフレームレートでカメラ画像を生成する。車載センサ３２は、車両Ｃの走行状態や、エンジン等の各種車載機器の状態等を検出する各種センサである。

具体的には、例えばＣＡＮ‐ＢＵＳ（車内ＬＡＮ）上に流れる、車速、ブレーキ、ステアリング操舵角度、ヨーレート等が含まれ、車両の走行状態に関する情報だけでなく、車両を識別するための情報も含まれる。

ＧＰＳ装置３３は、車両の現在地を測位する装置である。ナビゲーション装置３４は、乗員によって設定された車両Ｃの目的地までの走行経路を設定する装置である。端末装置３５は、所謂テレマティクスサービスを実現するために例えば、携帯通信網を介して車載装置１と管理サーバ１００との間で情報を送受信するための通信機能を備えた通信モジュールである。便宜上、車載装置１と別体で図示しているが車載装置１に含まれる構成であってもよい。また、を車両Ｃの乗員が所有するスマートフォン、タブレット端末等の可搬性の通信機器であってもよい。さらには、端末装置３５にＧＰＳ装置３３が一体となった構成でもよい。

また、図２に示すように、車載装置１は、車載装置１が出力したカメラ画像などの映像や画像を表示する表示装置５０に接続される。表示装置５０は、表示部５１および操作部５２を備える。

表示部５１は、例えば、有機ＥＬや、液晶ディスプレイで構成されたタッチパネルディスプレイであり、車載装置１から出力される映像信号を表示する。操作部５２は、表示部５１に表示された映像または画像に基づき、乗員からの所定操作を受け付ける。

例えば、操作部５２は、配信車両の選択操作などを受け付けることができる。また、操作部５２は、カメラ映像の再生、停止、巻き戻し等の各種操作を受け付けることも可能である。また、ユーザは、操作部５２を介して、過去に撮像されたカメラ画像の配信を要求することも可能である。

すなわち、実施形態に係る配信システムＳでは、カメラ画像のリアルタイム配信に加え、過去に撮像されたカメラ画像を後から配信することも可能である。なお、操作部５２を例えば、表示装置５０とは別に設けることにしてもよい。

図２に示すように、車載装置１は、制御部１０と、記憶部２０とを備える。制御部１０は、送信部１１と、受信部１２と、決定部１３と、生成部１４と、再生部１５とを備える。

制御部１０は、例えば、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）、入出力ポートなどを有するコンピュータや各種の回路を含む。

コンピュータのＣＰＵは、例えば、ＲＯＭに記憶されたプログラムを読み出して実行することによって、制御部１０の送信部１１、受信部１２、決定部１３、生成部１４および再生部１５として機能する。

また、制御部１０の送信部１１、受信部１２、決定部１３、生成部１４および再生部１５の少なくともいずれか一部または全部をＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等のハードウェアで構成することもできる。

また、記憶部２０は、例えば、ＲＡＭやＨＤＤに対応する。ＲＡＭやＨＤＤは、送信リスト情報２１、撮像画像情報２２、受信画像情報２３およびマップ情報２４を記憶する。なお、車載装置１は、有線や無線のネットワークで接続された他のコンピュータや可搬型記録媒体を介して上記したプログラムや各種情報を取得することとしてもよい。

送信リスト情報２１は、各車載装置１が管理サーバ１００へ送信するデータのリストに関する情報である。図３は、送信リスト情報２１の具体例を示す図である。図３に示すように、送信リスト情報２１には、位置情報、車両情報、映像情報、エリア情報、経路情報、検索履歴情報などが含まれる。

位置情報は、車両の現在地に関する情報であり、車載装置１がＧＰＳ装置３３から通知される情報である。センサ情報は、車載センサ３２によって検出された各種車両情報の値に関する情報である。

画像情報は、カメラ３１によって撮像されたカメラ画像に関する情報である。エリア情報は、ナビゲーション装置３４のナビゲーション画像に表示されるエリアに関する情報である。例えば、エリア情報は、ナビゲーション画像の更新毎に、管理サーバ１００へ通知される。

経路情報は、ナビゲーション装置３４において設定された目的地および目的地までの走行予定経路に関する情報である。検索履歴情報は、例えば、端末装置３５によって検索されたＷｅｂ検索履歴に関する情報である。例えば、車載装置１は、端末装置３５から検索履歴情報を取得することができる。なお、図３に示す送信リスト情報２１は、一例であり、任意に変更することにしてもよい。

図２の説明に戻り、撮像画像情報２２について説明する。撮像画像情報２２は、カメラ３１によって撮像されたカメラ画像に関する情報であり、所謂ＥＸＩＦ（Exchangeable image file format）と呼ばれる、カメラ画像に紐づいている撮像日時・時刻情報、撮像位置情報（経度・緯度）、撮影モード（ＩＳＯ感度・解像度等）を対応付けた情報である。

マップ情報２４は、例えば、ナビゲーション装置３４が経路案内時に使用する地図画像に関する情報である。

制御部１０は、所定条件に基づいて、カメラ画像の送受信を行うとともに、受信したカメラ画像を加工して表示装置５０へ出力する。

送信部１１は、撮像したカメラ画像や、車両Ｃの位置情報、走行状態に関する情報などを所定周期で管理サーバ１００へ送信する。具体的には、送信部１１は、記憶部２０に記憶された送信リスト情報２１に基づき、送信データを生成し、管理サーバ１００へ送信する。

この際、送信部１１は、送信リスト情報２１に記載された情報が含まれる送信データを生成する必要はなく、データを選別して送信データを生成することにしてもよい。具体的には、例えば、送信部１１は、車両情報に含まれる、例えば急ブレーキが踏まれた時に検出されるブレーキ情報や急舵角操作の時に検出されるステアリング操舵に関する情報や、映像情報を送信することにしてもよい。

また、ここでは便宜上、急ブレーキが踏まれた時や急操舵操作時と言った各シーンと、各シーンに対する単一の車両情報を組み合わせた情報および映像情報を送信することと記載しているが、各シーンを細かく判定するために、各シーンに紐づく車両情報を少なくとも２つ以上用いて判定したり、少なくとも２つ以上の変化率などを判定基準として用いてもよい。

受信部１２は、管理サーバ１００によって選択された候補車両と通信接続を開始しておき、候補車両のうち、カメラ画像の配信元として決定された配信車両からカメラ画像を取得する。

具体的には、受信部１２は、後述するように、候補車両に搭載された車載装置１のＩＰアドレスを管理サーバ１００から受信する。そして、受信部１２は、ＩＰアドレスが割り当てられた候補車両の車載装置１に対して通信接続の要求を送信部１１に対して指示する。

また、説明の詳細は省略するが、カメラ映像という個人に紐づく情報を配信するにあたり、個人情報の秘匿の観点からカメラ映像に紐づく車両または個人を特定する固有ＩＤ情報（例えば、車両のＶｉｎＮｏ．等）を管理サーバ１００で管理しておき、配信元または受信先として悪意を持ったものでないことを証明するための認証を行った上で通信接続の要求を送信部１１に対して指示する構成としてもよい。

これにより、受信車両の車載装置１と、候補車両の車載装置１との通信接続が開始される。その後、受信部１２は、配信元として決定された配信車両からカメラ画像を受信する。

ところで、配信車両からカメラ画像を受信したのちに、カメラ画像を再生するビュワーアプリ（後述の再生部１５に対応）を起動させると、ビュワーアプリを起動させるためにかかる時間によりカメラ画像を表示するまでに遅延が生じ、リアルタイム性が損なわれる。

また、遅延の原因は、通信確立処理、データ伝送容量大、ビュワーアプリ起動・設定（画像データフォーマットの解析と解析結果に応じたビュワー動作設定）があり、それぞれ「通信確立の事前完了と維持」、「必要な容量に加工して送信（画像選択用には低容量映像の詳細確認用には高容量）」、「ビュワーの事前起動および再生画像フォーマットの事前解析」と言った対策が考えられる。

このため、受信部１２は、候補車両と通信接続を開始する際に、候補車両からカメラ映像のデータ容量を小さくした低容量映像を受信するとともに、再生部１５を起動させて、低容量映像の再生を開始しておく。

図４は、受信部１２による処理内容を説明する説明図である。なお、図４では、受信部１２が時刻ｔ１に候補車両である車両Ａ～Ｃと通信接続を開始し、時刻ｔ２において、配信車両が車両Ｃとして決定された場合を示す。

図４に示すように、受信部１２は、時刻ｔ１～ｔ２までの期間においては、各候補車両から低容量映像を受信する。ここで、低容量映像とは、時刻ｔ２以降に受信する高容量映像よりもデータ容量が小さいカメラ映像である。なお、ここでは、低容量映像との比較のため、時刻ｔ２以降に受信するカメラ画像を高容量映像としているが、高容量映像は、低容量映像よりもデータ容量が大きいカメラ映像を示す概念である。

本実施形態において、高容量映像に対して、フレームレートや、解像度、映像ビットレートを調整することで、低容量映像が生成される。すなわち、低容量映像は、高容量映像に比べて、フレームレートが低いカメラ画像、解像度が低いカメラ画像、ビットレートが低いカメラ画像のいずれか一つを含むカメラ画像である。

そして、受信部１２は、時刻ｔ２以降においては、配信車両である車両Ｃから高容量映像を受信する。このように、候補車両から低容量映像を受信しておき、車両の表示装置５０の操作部５２で選択された配信車両から高容量映像を受信する。

これにより、通信負荷を抑えつつ、カメラ画像を受信することが可能となる。なお、受信部１２は、時刻ｔ２以前に、候補車両から必ずしも低容量映像を受信しておく必要はなく、通信接続を確立させた状態で表示装置５０の表示部に映像を表示しない状態のまま待機しておくことにしてもよい。

また、同図に示すように、例えば、受信部１２は、配信車両以外のその他候補車両（車両Ａ、車両Ｂ）からの受信を停止する。なお、受信部１２は、時刻ｔ２以降において、配信車両以外の車両（車両Ａ、車両Ｂ）から引き続き、低容量映像を受信することにしてもよい。また、受信部１２は、複数の配信車両から高容量映像を受信することにしてもよい。

図２の説明に戻り、決定部１３について説明する。決定部１３は、候補車両のうち、配信車両を決定する。具体的には、例えば、決定部１３は、表示装置５０に表示された地図画像に対するユーザ操作に基づき、配信車両を決定することができる。

図５は、決定部１３による処理の具体例を示す図である。なお、図５では、ナビゲーション画像Ｎｉに表示された候補車両Ｃｖ１～Ｃｖ３から配信車両を決定する場合について説明する。

図５に示すように、実施形態に係る配信システムＳでは、ナビゲーション画像Ｎｉに表示された表示エリア内に位置する車両を候補車両として選択することができる。なお、ナビゲーション画像Ｎｉは、地図画像の一例である。

つまり、発生事象に応じた地図・候補車両を表示する画像、例えば、渋滞の場合は、渋滞発生区間＋その前後の地図、渋滞先頭、先頭より少し先（渋滞解消直後の状態）、渋滞中間部分（所定間隔、カーブ・橋梁・トンネル等の特異点等）の状況とそれら周辺の候補車両が視認でき、事象の発生状況概要を確認しながら、詳細情報収集対象とする配信候補車両を選択できるような画像が表示される。

例えば、ナビゲーション画像Ｎｉには、候補車両Ｃｖ１～Ｃｖ３の現在地および、カメラの向き（候補車両の進行方向）が表示される。そして、乗員は、ナビゲーション画像Ｎｉに表示された候補車両Ｃｖ１～Ｃｖ３から、カメラ画像の配信を希望する配信車両を所定操作（タッチパネル操作）によって選択することができる。

決定部１３は、配信車両を選択する所定操作に基づき、配信車両を決定する。決定部１３は、配信車両を決定すると、配信車両以外の候補車両との通信接続を解除するとともに、配信車両の車載装置１に対して、高容量映像の配信を依頼する。なお、ここでは、決定部１３が、候補車両を決定する場合について説明したが、管理サーバ１００側で候補車両を決定することも可能であるが、この点については、後述する。

図２の説明に戻り、生成部１４について説明する。生成部１４は、受信部１２によって自車両の前方に位置する前方車両からカメラ画像を取得した場合に、自車両から見たカメラ画像の画角に写る対象物の透かし画像を生成する。

図６Ａおよび図６Ｂは、透かし画像の具体例を示す図である。なお、図６でＡは、車両Ｃ１が、車両Ｃ１の前方に位置する車両Ｃ２からカメラ画像を受信する場合について説明する。

図６Ａに示すように、車両Ｃ２によって撮像されたカメラ画像Ｌ２を車両Ｃ１で表示する場合、カメラ画像Ｌ２には、車両Ｃ２が写らない。このため、例えば、車両Ｃ１のドライバが、車両Ｃ１で表示されるカメラ画像Ｌ２を視認する場合、車両Ｃ２の存在に気付かない場合がある。

一方、車両Ｃ１で撮像された撮影映像Ｌ１においては、車両Ｃ２が存在する。このため、生成部１４は、撮影映像Ｌ１から車両Ｃ２を所定の画像処理（例えば、画像のエッジ処理、検出エッジのフィルタリング処理・連結処理、また車両モデルを用いた画像認識処理）を行い、車両Ｃ２の透かし画像ＬＷを生成する。

ここで、透かし画像ＬＷは、車両Ｃ２の骨格を示すフレーム画像や、車両Ｃ２を透過させた半透明画像（例えば、ポリゴン画像）などを含む。

そして、実施形態に係る配信システムＳでは、透かし画像ＬＷをカメラ画像Ｌ２に重畳して表示することで、車両Ｃ１の乗員に対して、車両Ｃ２の存在を通知しつつ、車両Ｃ２の前方の様子を通知することができる。

尚、前方に複数台の車両が連なっている場合は、先頭車両のカメラ画像に直前の車両の透かし画像を表示するようにする。つまり、図６Ｂに示すように、車両Ｃ２の前方にも詰まった状態で車両Ｃ３が存在する場合（図６Ｂでは車両Ｃ１の前方に２台に車両が連なった場合であるが、それ以上でも同様である）は、車両Ｃ３のカメラ３１の撮影映像Ｌ３に、車両Ｃ１のカメラ３１の撮影映像Ｌ１に基づき生成された透かし画像ＬＷを重畳して表示する（車両Ｃ１の表示装置に表示）。

これにより、車両Ｃ１のドライバは前方の道路状況を的確に把握でき（車両Ｃ２のカメラ３１の撮影映像では車両Ｃ３が邪魔になり前方の道路状況を視認し難い）、また同時に直前車両の状況を容易に把握することが可能となる。

尚、交差点前等で停車した場合等、この表示が必要な場面を登録しておき、該当の場面が発生した場合にこの表示を行うようにするのが好ましい。また、連なった車両の状況は、管理サーバ１００からの周辺車両情報、周辺車両からの各自車両周囲情報等から把握することが可能である。

図２の説明に戻り、再生部１５について説明する。再生部１５は、受信部１２によって受信されたカメラ画像を再生する。上記のように、受信部１２は、候補車両から低容量映像を受信したのちに、配信車両から高容量映像を受信する。

表示映像Ｌｄは通常画像（例えばナビの地図画像）で、通常時にはこれが表示されている。低容量映像Ｌｌはユーザの情報要望の発生が予想される場合における情報表示の事前準備で、渋滞に巻き込まれる前に渋滞概要情報（映像選択用の画像）を準備しておき、渋滞に巻き込まれてユーザが詳細情報の要望が発生した際に直ぐに渋滞概要情報を提供できるように準備しておく動作である。

必要な情報を収集する際の通信確立とデータ通信にも時間がかかるので、ここでは事前に通信確立をしておき、詳細情報の要望があった場合に直ぐに情報を収集できる状態を維持している。また、高容量映像Ｌｈも通信確立とデータ通信に時間がかかるが、次に表示する映像情報の入手先は一か所であるため、要求される映像の撮影場所を推定し、その撮影場所の撮影装置（通信装置）と通信確立をしておき、直ちにデータを収集して詳細映像が表示できる準備しておく。このような動作により、表示要求される映像の高速表示が可能となる。

これにより、再生部１５は、高容量映像の受信に先立って、低容量映像の再生を開始することができる。そして、再生部１５は、低容量映像を表示装置５０に表示中の表示画像の背面で再生しておき、高容量映像の再生を開始した場合に、高容量映像を表示画像として再生する。

図７は、表示階層の具体例を示す図である。図７に示すように、配信車両の決定前においては、表示映像Ｌｄが最上位の表示階層となり、表示装置５０に表示される。このとき、低容量映像Ｌｌは、表示映像Ｌｄよりも下位の表示階層となり、表示装置５０には表示されない。なお、本例では、表示装置５０は車両のメータパネル（速度表示等を行う）に設けられたメータパネルディスプレイで構成されている。

一方、配信車両の決定後においては、再生部１５は、上記の表示階層の入れ替えを行い、高容量映像Ｌｈを最上位の表示階層とする。これにより、表示装置５０には、表示映像Ｌｄに優先して、高容量映像Ｌｈが表示されることとなる。

このように、再生部１５は、低容量映像Ｌｌを表示映像Ｌｄの背面で再生しておき、高容量映像Ｌｈを再生する場合に、表示階層を入れ替えることで、高容量映像Ｌｈを迅速に提供することができる。

また、再生部１５は、高容量映像Ｌｈを再生するに当たり、高容量映像Ｌｈの撮像位置を併せて出力し、表示装置５０に表示させる。図８は、カメラ映像の表示画面の一例を示す図である。

まず、この表示動作の全体像を図８の事例を例として説明する。各車両は車両の異常操作・動作（急ブレーキ・急操舵、異常振動等）をトリガとして、その特異地点の位置データ・発生日時データ等を管理サーバ１００に送信する。管理サーバ１００は予め収集・把握している各車両の位置、進行方向データ等から、特異地点に位置する、またこれから接近する車両Ａ１，Ａ２，Ａ３に対して特異地点の映像撮影指令を送信し、また映像撮影データを収集する。

そして、収集した特異地点の映像撮影データを適宜、映像要求のあった車両、あるいは所定条件の車両（特異地点にこれから接近する車両Ａ１，Ａ３：管理サーバ１００は予め収集・把握している各車両の位置、進行方向データ等から判断）に配信する。

尚、本例において通常は特異地点をまもなく通過する（所定距離手前）の車両に最新の特異点映像（特異点にもっとも接近して撮影が可能な状況にある車両の撮影画映像）を対象の車両に配信するが、各車両から要求のあった条件の映像、例えば最初に異常操作・動作（急ブレーキ・急操舵、異常振動等）が行われた時点前後の特異点映像と言った映像を配信することも有用な方法である。

図８に示すように、カメラ画像の表示画面においては、高容量映像Ｌｈとともに、高容量映像Ｌｈの撮像位置を示す地図画像Ｌｍが表示される。地図画像Ｌｍにおいては、自車両の位置を示す車両アイコンＡ１と、配信車両によるカメラ画像の撮像位置を示す車両アイコンＡ２とが重畳される。また、他の周辺車両を示す車両アイコンＡ３も該当の位置に表示される。

また、車両アイコンＡ２には、リアルタイム配信であることを示す「ＬＩＶＥ」の吹き出しが表示される。さらに、次に車両Ａ３が配信車両（特異地点への最接近車両となる）となった場合は、車両アイコンＡ３に「ＬＩＶＥ」の吹き出しが表示される。このように、車両アイコンＡ２を地図画像Ｌｍとともに表示することで、乗員が高容量映像Ｌｈ（カメラ画像）の撮像位置を容易に認識することが可能となる。

なお、地図画像Ｌｍの縮尺によっては、地図画像Ｌｍ上に自車両を表示しないことにしてもよい。また、地図画像Ｌｍの縮尺に応じて、リアルタイム配信であることを示す「ＬＩＶＥ」の吹き出しの表示サイズをリサイズして表示してもよい。本実施形態では、地図画像Ｌｍを地図の俯瞰画像を表示する例を記載しているが、地図画像Ｌｍは鳥瞰画像や衛星写真、また位置関係等が概略把握できる程度の簡単なイメージ図であってもよい。

次に、図９を用いて、実施形態に係る管理サーバ１００の構成例について説明する。図９は、管理サーバ１００のブロック図である。図９に示すように、管理サーバ１００は、交通情報サーバ２０１、天候情報サーバ２０２およびＳＮＳ（Social Networking Service）サーバ２０３に接続される。なお、交通情報サーバ２０１、天候情報サーバ２０２およびＳＮＳサーバ２０３は、外部装置の一例である。

交通情報サーバ２０１は、渋滞に関する情報や交通規制に関する情報、交通事故に関する情報等を管理するサーバである。天候情報サーバ２０２は、天候に関する情報を管理するサーバであり、ゲリラ豪雨に関する情報などを管理サーバ１００へ通知する。ＳＮＳサーバ２０３は、ＳＮＳを管理するサーバである。

管理サーバ１００は、各車載装置１の現在地に関する情報や、各車載装置１で撮像されたカメラ画像等を管理するサーバ装置である。図９に示すように、管理サーバ１００は、制御部１１０と、記憶部１２０とを備える。

制御部１１０は、取得部１１１と、検出部１１２と、選択部１１３とを備える。制御部１１０は、例えば、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）、入出力ポートなどを有するコンピュータや各種の回路を含む。

コンピュータのＣＰＵは、例えば、ＲＯＭに記憶されたプログラムを読み出して実行することによって、制御部１１０の取得部１１１、検出部１１２および選択部１１３として機能する。

また、制御部１１０の取得部１１１、検出部１１２および選択部１１３の少なくともいずれか一部または全部をＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等のハードウェアで構成することもできる。

また、記憶部１２０は、例えば、ＲＡＭやＨＤＤに対応する。ＲＡＭやＨＤＤは、ユーザ情報ＤＢ１２１、位置情報ＤＢ１２２、車両情報ＤＢ１２３、画像情報ＤＢ１２４および検出条件ＤＢ１２５を記憶する。なお、管理サーバ１００は、有線や無線のネットワークで接続された他のコンピュータや可搬型記録媒体を介して上記したプログラムや各種情報を取得することとしてもよい。

ユーザ情報ＤＢ１２１は、例えば、各車載装置１が搭載される車両の乗員（例えば、所有者）に関するデータベースである。図１０は、ユーザ情報ＤＢ１２１の具体例を示す図である。

図１０に示すように、ユーザ情報ＤＢ１２１には、車載装置ＩＤ、ＩＰアドレス、現在地、目的地、走行経路、お気に入り地点、所属グループ、デモグラフィック属性、サイコグラフィック属性等が互いに対応付けられたテーブルを記憶する。

車載装置ＩＤは、各車載装置１を識別する識別子である。ＩＰアドレスは、各車載装置１のネットワークアドレスである。現在地は、各車載装置１（車両）の現在地を示す。目的地は、各車両の現在の目的地を示し、走行経路は、現在地から目的地まで走行を予定している走行経路を示す。

お気に入り地点は、各車両Ｃのナビゲーション装置３４において、登録されたお気に入り地点を示す。所属グループは、配信システムＳにおいて、各乗員が所属するグループを示す。

所属グループは、例えば、乗員の所属する会社などのグループ単位であってもよいし、乗員同士の友人などで構成されるグループなどであってもよい。また、所属グループは、各乗員のユーザ属性に応じて、配信システムＳ側で決定することにしてもよい。

デモグラフィック属性は、乗員の人口統計学的な情報である。デモグラフィック属性は、例えば、「性別」、「年齢」などの情報が含まれる。サイコグラフィック属性は、乗員の心理学的な属性の情報であり、例えば、乗員の価値観、ライフスタイル、性格、嗜好などの情報である。

本実施形態においては、各車載装置１の目的地の履歴や、ＳＮＳサーバ２０３から通知される乗員の投稿履歴に基づいて、各乗員のサイコグラフィック属性を判定することができる。

管理サーバ１００は、目的地の履歴に基づき、目的地から推定される目的地の利用目的から上記のサイコグラフィック属性を判定することができる。また、管理サーバ１００は、ＳＮＳにおける乗員の投稿履歴に含まれるハッシュタグまたはハッシュタグ分析の結果によって各乗員のサイコグラフィック属性を判定する。なお、デモグラフィック属性およびサイコグラフィック属性は、ユーザ属性の一例である。

図９の説明に戻り、位置情報ＤＢ１２２について説明する。位置情報ＤＢ１２２は、各車両Ｃの位置情報を管理するデータベースである。例えば、位置情報ＤＢ１２２には、各車両Ｃの位置情報の履歴が車載装置１毎に記憶される。

車両情報ＤＢ１２３は、各車載装置１から送信される各車両Ｃの車載センサ３２によって検出されたセンサ値等の車両状況情報を管理するデータベースである。例えば、車両情報ＤＢ１２３には、車載装置１毎に時系列のセンサ値が記憶される。

画像情報ＤＢ１２４は、各車載装置１から送信されるカメラ画像を管理するデータベースである。例えば、画像情報ＤＢ１２４には、カメラ画像に対して、車載装置ＩＤ、撮像時刻、撮像位置に関する情報が対応付けられて記憶される。

検出条件ＤＢ１２５は、候補車両と、受信車両との通信接続を開始する接続開始条件に関する情報を管理するデータベースである。図１１は、検出条件ＤＢ１２５の一例を示す図である。

図１１に示すように、検出条件ＤＢ１２５には、例えば、条件ＩＤ、シチュエーション、候補車両、受信車両、事前告知等が互いに対応付けられて記憶される。条件ＩＤは、各接続開始条件を識別する識別子である。

シチュエーションは、接続開始条件を満たすシチュエーションを示す。また、候補車両は、シチュエーションに応じた候補車両の選択条件を示し、受信車両は、シチュエーションに応じた受信車両の選択条件を示す。また、事前告知は、カメラ画像の配信に先立って、シチュエーションの事象を、受信車両に事前告知するか否かを示す。

条件ＩＤ「０００１」においては、シチュエーションが急ブレーキであり、候補車両が通過車両、受信車両が後続車両である。この場合、急ブレーキ地点を通過し、急ブレーキ地点を撮像可能な通過車両が候補車両として選択されることとなる。

これにより、急ブレーキを行った要因（例えば、落下物や事故）を捉えたカメラ画像をこれから急ブレーキ地点を通過する後続車両へ通知することができる。

また、条件ＩＤ「０００１」においては、事前告知がありであり、例えば、「前方車両の急ブレーキを検出しました。急停車に注意してください」等のメッセージが受信車両へ通知され、受信車両の車載装置１を介して、乗員に通知される。なお、事前告知においては、音声で通知することにしてもよいし、画像で表示することにしてもよい。

また、条件ＩＤ「０００２」においては、シチュエーションがゲリラ豪雨であり、候補車両は、豪雨地帯に位置する車両Ｃであり、受信車両は、豪雨地点を通過予定の通過予定車両である。

この場合、候補車両からゲリラ豪雨の様子を捉えたカメラ画像が、受信車両へ配信される。すなわち、この場合、受信車両では、事前にゲリラ豪雨の実際の様子を確認することができるので、例えば、予定を変更するなどの事前の対応が可能となる。

また、条件ＩＤ「０００２」においては、事前告知がありであり、例えば、「走行予定経路において、ゲリラ豪雨が発生しました」等のメッセージが受信車両へ通知される。

また、条件ＩＤ「０００３」においては、シチュエーションが渋滞発生であり、候補車両が渋滞地点を通過する通過車両であり、受信車両は、通過予定車両である。例えば、渋滞の発生については、交通情報サーバ２０１から取得することにしてもよいし、イベント情報や、観光スポット情報に基づいて予め渋滞発生を推定することにしてもよい。

具体的には、管理サーバ１００は、交通情報サーバ２０１から現在発生中の渋滞情報を取得したり、コンサート等のイベント、観光スポットの規模、イベント開催／終了・施設等の開館／閉館時刻・現在（車両通過）時刻等に基づいて、推定される入場者数から渋滞の発生を予測したりすることができる。

また、条件ＩＤ「０００４」においては、話題エリアであり、候補車両が話題エリアに位置するエリア車両、受信車両がエリア車両の近郊を走行中の近郊車両である。例えば、配信システムＳにおいて、話題エリアは、ＳＮＳのハッシュタグに基づいて推定することができる。

また、条件ＩＤ「０００４」において、受信車両を近郊車両とすることで、乗員が気軽に話題エリアに立ち寄ることが可能となる。なお、受信車両については、話題エリアに興味があると推定される乗員の車両Ｃに限定することにしてもよい。

また、条件ＩＤ「０００５」においては、シチュエーションが前方車両停車予定であり、候補車両は、停車する停車車両である。また、この場合、受信車両は、停車車両の後続車両である。この場合、停車した停車車両で撮像されたカメラ画像を後続車両は受信することができる。なお、条件ＩＤ「０００５」の具体例については図１２Ｂを用いて後述する。

図９の説明に戻り、制御部１１０について説明する。制御部１１０は、上述の接続開始条件に基づいて候補車両および受信車両を選択する。

取得部１１１は、各車載装置１から所定の周期で送信される各種情報を取得する。具体的には、取得部１１１は、各車載装置１から位置情報を取得し、位置情報ＤＢ１２２へ格納する。

また、取得部１１１は、各車載装置１から車載センサのセンサ値等の車両情報を取得し、車両情報ＤＢ１２３へ格納する。また、取得部１１１は、各車載装置１からカメラ画像を取得し、画像情報ＤＢ１２４へ格納する。

また、取得部１１１は、交通情報サーバ２０１、天候情報サーバ２０２およびＳＮＳサーバ２０３などの外部装置から外部情報を取得し、検出部１１２へ通知する。

検出部１１２は、検出条件ＤＢ１２５に格納された上記のシチュエーションを検出する。検出部１１２は、図１１の条件ＩＤ「０００１」に示したように、シチュエーションとして、急ブレーキを検出する場合、車両情報ＤＢ１２３に格納されたセンサ情報に基づいて検出する。

なお、検出部１１２は、例えば、同一区間（略同一の地点）で複数の車両から急ブレーキが検出された場合に、条件ＩＤ「０００１」のシチュエーションを検出することにしてもよい。つまり、複数の急ブレーキ（所定期間内、あるいは所定以上の発生頻度）発生、つまり複数の特異事象の発生を条件にすることにより、あまり意味もなくたまたま事象が発生した場合と言ったノイズ的事象発生による無駄な情報配信を防止するようにしてもよい。

また、検出部１１２は、前方車両の急ブレーキ後に、後続車両が急ブレーキ地点を回避する回避運転を検出した場合に、条件ＩＤ「０００１」のシチュエーションを検出することにしてもよい。つまり、複数の条件を課すことにより、より厳密に情報配信の実施や内容を決めるようにしてもよい。

また、ここでは便宜上、急ブレーキが踏まれた時や急操舵操作時と言った各シーンと、各シーンに対する単一の車両情報を組み合わせた情報および映像情報を送信することと記載しているが、各シーンを細かく判定するために、各シーンに紐づく車両情報を少なくとも２つ以上用いて判定したり、少なくとも２つ以上の変化率などを判定基準として用いてもよい。

また、検出部１１２は、図１１の条件ＩＤ「０００２」～「０００４」に示すように、交通情報サーバ２０１、天候情報サーバ２０２、ＳＮＳサーバ２０３等の外部装置から通知された情報に基づいてシチュエーションを検出することもできる。

検出部１１２は、上記のシチュエーションを検出すると、検出したシチュエーションの条件ＩＤを選択部１１３へ通知する。

選択部１１３は、車両Ｃで撮像されたカメラ画像の配信候補となる候補車両を所定条件に基づいて選択する。具体的には、選択部１１３は、検出部１１２によって検出されたシチュエーションに応じて、候補車両を選択したり、シチュエーションによっては、受信車両を選択したりすることも可能である。

図１２Ａ～図１２Ｃは、選択部１１３による処理の具体例を示す図である。図１２Ａでは、図１１の条件ＩＤ「０００１」、「０００３」における選択部１１３の処理について説明する。また、図１２Ａおよび図１２Ｃにおいては、受信車両が車両Ｃ１である場合について説明する。

図１２Ａに示す目的地点Ｐｔは、例えば、急ブレーキ地点や、渋滞の先頭などといった車両Ｃ１の乗員がカメラ画像の撮像を希望する地点である。例えば、選択部１１３は、各車両の走行状況や、渋滞情報などに基づいて目的地点Ｐｔを設定することができる。

選択部１１３は、各車両Ｃの位置情報に基づき、車両Ｃ１よりも目的地点Ｐｔに近い位置を走行中の車両、すなわち、車両Ｃ１の前方車両について、候補車両として選択する。そして、選択部１１３は、各候補車両のＩＰアドレスを受信車両に対して送信することで、受信車両と候補車両との通信接続が開始されることとなる。

また、説明の詳細は省略するが、カメラ映像という個人に紐づく情報を配信するにあたり、個人情報の秘匿の観点からカメラ映像に紐づく車両または個人を特定する固有ＩＤ情報（例えば、車両のＶｉｎＮｏ．等）を管理サーバ１００で管理しておき、配信元または受信先として悪意を持ったものでないことを証明するための認証を行った上で通信接続の要求を送信部１１に対して指示する構成としてもよい。

すなわち、選択部１１３は、目的地点Ｐｔをこれから通過する通過車両を候補車両として選択することで、各候補車両が目的地点Ｐｔを通過するよりも前に、受信車両と候補車両との通信接続を開始しておくことが可能となる。あるいは、管理サーバ１００を介する場合は、管理サーバ１００と候補車両との通信接続を開始しておくことが可能となる。なお、選択部１１３は、車両Ｃ１の前方車両に限らず、車両Ｃ１の対向車両を候補車両として選択することも可能である。

なお、この場合、配信システムＳは、各候補車両の位置情報に基づき、各候補車両が目的地点Ｐｔを撮像可能となる期間において、順次、配信車両を決定することができる。なお、この場合における、配信車両の決定は、各候補車両の現在地に基づき、管理サーバ１００側で行うことにしてもよいし、あるいは、各候補車両に対して、目的地点Ｐｔの位置情報を通知しておき、各候補車両の車載装置１で行うこととしてもよい。

次に、図１２Ｂを用いて、図１１の条件ＩＤ「０００５」における選択部１１３の処理について説明する。図１２Ｂに示す例では、車両Ｃ１の進行方向に前方車両と、「一時停止」の標識Ｍとが存在する。

また、ここでは、車両Ｃ１に対して、前方車両で死角となる前方車両の前方（例えば、交差点の様子）が撮像されたカメラ画像を前方車両から車両Ｃ１に対して配信する場合について説明する。

この場合、検出部１１２は、各車両の走行位置および走行向きに基づき、車両Ｃ１および、車両Ｃ１の前方車両が標識Ｍの位置で停車することを予め予測することができる。そして、選択部１１３は、車両Ｃ１を受信車両として選択し、車両Ｃ１の前方車両を候補車両として選択する。

これにより、前方車両が停車した際に、前方車両から車両Ｃ１へカメラ画像を直ちに配信することが可能となる。特に、前方車両が、バスやトラックなどの大型車両である場合、車両Ｃ１には前方車両によって多くの死角が生じる。このため、条件ＩＤ「０００５」においては、前方車両が大型車両である場合に、特に有効となる。

なお、前方車両が大型車両か否かの判定については、例えば、記憶部に各車両の車種情報を記憶しておき、かかる車種情報に基づいて判定することができる。

また、車両Ｃ１の車載装置１では、受信したカメラ画像に対して、図６に示したように、透かし画像が生成され、かかる透かし画像を受信したカメラ画像に重畳して表示することとなる。

なお、ここでは、選択部１１３が、標識Ｍに基づいて受信車両および候補車両を選択する場合について説明したが、標識Ｍに加えて、交差点の位置情報に基づき、受信車両および候補車両を選択することにしてもよい。

これは、交差点において、前方車両が停車する可能性が高いためである。この場合、選択部１１３は、前方車両が交差点に進入することを予測できた場合に、かかる前方車両を候補車両として選択する。そして、前方車両が実際に停車した場合に、受信車両は、かかる停車車両からカメラ画像を受信し、前方車両が停車しなかった場合、通信接続を解除することとすればよい。

また、選択部１１３は、前方車両の停車の有無によらず、所定の条件を満たす場合に、前方車両を候補車両として選択することも可能である。具体的には、車両Ｃ１が、例えば、前方車両の追い抜きを行おうと考えている場合を想定する。この場合、例えば、選択部１１３は、車両Ｃ１と前方車両との相対速度や、車両Ｃ１と前方車両との車間距離等に基づき、車両Ｃ１が追い越しを行おうと考えていると推定することができる。

なお、標識Ｍおよび交差点は、道路情報の一例である。これら道路情報は、管理サーバ１００の記憶部１２０に予め格納され、選択部１１３は、記憶部１２０から読み出して上記の判定を行うことができる。

また、本実施形態において、選択部１１３は、各車両の表示装置５０に表示された地図画像に基づいて候補車両を選択することも可能である。具体的には、図１２Ｃに示すように、選択部１１３は、各車載装置１からナビゲーション画像Ｎｉの表示範囲に関する情報を取得し、取得した表示範囲内に位置する車両を候補車両として選択する。

具体的には、選択部１１３は、表示範囲に関する情報として各表示範囲の四隅（ｘ１～ｘ４）の座標情報を取得し、ナビゲーション画像Ｎｉで表示される表示範囲を識別する。そして、選択部１１３は、ユーザ情報ＤＢ１２１における各車両の現在地を参照し、表示範囲内に位置する車両を候補車両として選択する。

選択部１１３によって選択された候補車両に関する情報は、受信車両となる各車載装置１へ送信される。これにより、車両の表示装置５０には、図５に示したように、候補車両の位置情報が表示され、乗員は、表示された候補車両から配信車両を決定することができる。

このように、選択部１１３は、受信車両に表示されたナビゲーション画像Ｎｉの表示範囲内に位置する車両を候補車両として選択する。また、ナビゲーション画像Ｎｉには、候補車両が表示される。これにより、乗員が配信車両を容易に把握させることが可能となる。

また、選択部１１３は、図１１に示した条件ＩＤ「０００２」や、「０００３」において、候補車両を選択する場合、ゲリラ豪雨のエリアや話題エリアを走行中の車両をユーザ情報ＤＢ１２１に格納された各車両の現在地に基づいて選択する。

すなわち、選択部１１３は、交通情報サーバ２０１、天候情報サーバ２０２およびＳＮＳサーバ２０３などの外部装置から取得した外部情報に基づき、候補車両の選択対象となるエリアを選択し、選択したエリアから候補車両を選択する。

これにより、ユーザの多様なニーズに応じて適切に候補車両を絞り込むことが可能となるので、候補車両の選択精度を向上させることが可能となる。また、この場合、選択部１１３は、ユーザ情報ＤＢ１２１に格納された現在地、目的地、走行経路、迂回路（ゲリラ豪雨の場合、ゲリラ豪雨のエリアを迂回した場合の経路に存在する車両を候補とする）等に基づき、受信車両を選択することも可能である。

ここで、選択部１１３は、例えば、図１０に示した受信車両の走行予定経路、お気に入り地点、所属グループ、ユーザ属性（デモグラフィック属性、サイコグラフィック属性）や、各車両の過去の配信履歴等に基づいて候補車両を選択することも可能である。

例えば、選択部１１３は、走行予定経路を走行中の車両を候補車両として選択することで、受信車両の乗員は、走行予定経路の現在の様子を把握したいと思った際に、迅速にカメラ画像を得ることができる。

また、受信車両は、お気に入り地点へ行く頻度が高いことが想定される。このため、選択部１１３は、お気に入り地点にいる車両を候補車両として選択しておくことで、受信車両の乗員は、お気に入り地点の現在の様子を把握したいと思った際に、迅速にカメラ画像を得ることができる。

また、選択部１１３は、所属グループに基づいて候補車両を選択することで、受信車両の乗員は、所属グループに属する他の車両の現在地や、現在の様子を容易に把握することが可能となる。

また、選択部１１３は、ユーザ属性に基づいて候補車両を選択することで、趣味嗜好が近い乗員や、目的地の傾向が近い乗員が所有する車両同士を予め通信接続を開始することができる。これにより、配信システムＳの利便性を向上させることができる。

また、選択部１１３は、各車両に搭載された各車載装置１の過去の配信履歴を記憶しておき、例えば、所定回数以上、カメラ画像の送受信が行われた車両を候補車両として選択することもできる。

つまり、選択部１１３は、配信車両となることが予め見込まれる車両について、予め候補車両として選択する。これにより、受信車両で、他の車両で撮像されたカメラ画像が要求される場合に、迅速にカメラ画像を提供することができる。

なお、選択部１１３は、例えば、受信車両の位置から所定範囲内にいる車両に限定して、候補車両を選択することにしてもよい。これは、受信車両から遠すぎると、配信車両として選択されにくいためである。

すなわち、選択部１１３は、受信車両が全く走行を予定していない地域にいる車両を配信車両の選択候補から除外することができる。言い換えれば、受信車両の位置から所定範囲内に限定して、候補車両を選択することで、不要な通信接続を予め回避することができる。

また、選択部１１３は、上記の選択条件を適宜、組み合わせて候補車両を選択することも可能である。この場合、例えば、選択部１１３は、各選択条件に対してそれぞれ重みづけを行い、重み付けの結果に基づいて候補車両を選択することができる。

つまり、選択部１１３は、複数の選択条件を組み合わせて用いることで、配信車両として選択される可能性の高い候補車両を選択することができる。

次に、図１３～図１６を用いて実施形態に係る配信システムＳが実行する処理手順について説明する。図１３～図１５は、車載装置１が実行する処理手順を示すフローチャートである。図１６は、管理サーバ１００が実行する処理手順を示すフローチャートである。

まず、図１３を用いて、車載装置１が実行する一般的な処理フローについて説明する。図１３に示すように、車載装置１は、まず、送信データ（自車位置、車両情報等の定常送信データ）を生成し、送信データを送信する（ステップＳ１０１）。なお、ステップＳ１０１の処理は、ステップＳ１０２以降の処理によらず、所定周期で繰り返されるものとする。

続いて、車載装置１は、受信車両として選択されたか否かを判定する（ステップＳ１０２）。ここで、車載装置１は、受信車両として選択されていないと判定した場合（ステップＳ１０２，Ｎｏ）、候補車両として選択されたか否かを判定する（ステップＳ１０３）。

車載装置１は、候補車両として選択されていないと判定した場合（ステップＳ１０３，Ｎｏ）、処理を終了する。また、車載装置１は、ステップＳ１０３の判定処理において、候補車両として選択されたと判定した場合（ステップＳ１０３，Ｙｅｓ）、カメラ画像の配信処理を行い（ステップＳ１０４）、処理を終了する。

なお、ステップＳ１０４の配信処理の処理手順については、図１５を用いて後述する。また、車載装置１は、ステップＳ１０２の判定処理において、受信車両として選択されたと判定した場合（ステップＳ１０２，Ｙｅｓ）、カメラ画像の受信処理を行い（ステップＳ１０５）、処理を終了する。

次に、図１４を用いて、図１３に示すステップＳ１０５の受信処理の処理手順について説明する。図１４に示すように、まず、車載装置１は、候補車両に対して、低容量映像の配信を要求する（ステップＳ１１１）。

続いて、車載装置１は、低容量映像を受信し、再生を開始する（ステップＳ１１２）。続いて、車載装置１は、配信車両が決定したか否かを判定する（ステップＳ１１３）。

車載装置１は、配信車両が決定した場合（ステップＳ１１３，Ｙｅｓ）、配信車両から高容量映像を受信し（ステップＳ１１４）、高容量映像を表示して（ステップＳ１１５）、処理を終了する。

また、車載装置１は、配信車両が決定していない場合（ステップＳ１１３，Ｎｏ）、ステップＳ１１３の処理を継続して行うこととなる。

なお、低容量映像、高容量映像およびそれらの要求の伝送は、車載装置１間の通信でも、あるいは管理サーバ１００を介した通信で実施可能で、状況（通信可能距離であるか否か等で判断）に応じて切り替えることも可能である。

次に、図１５を用いて、図１３に示したステップＳ１０３の配信処理の処理手順について説明する。図１５に示すように、車載装置１は、まず、受信車両に対して、低容量映像の配信を開始し（ステップＳ１２１）、その後、配信車両が決定したか否かを判定する（ステップＳ１２２）。

車載装置１は、配信車両が決定した場合（ステップＳ１２２，Ｙｅｓ）、配信車両が自車両か否かを判定する（ステップＳ１２３）。車載装置１は、配信車両が自車両であった場合（ステップＳ１２３，Ｙｅｓ）、受信車両に対して、高容量映像を配信し（ステップＳ１２４）、処理を終了する。

また、車載装置１は、ステップＳ１２２の判定処理において、配信車両が決定されていなかった場合（ステップＳ１２２，Ｎｏ）、ステップＳ１２２の処理を継続して行う。

また、車載装置１は、ステップＳ１２３の判定処理において、配信車両が自車両でなかった場合（ステップＳ１２３，Ｎｏ）、低容量映像の配信停止を行い（ステップＳ１２５）、処理を終了する。

次に、図１６を用いて、管理サーバ１００による処理手順について説明する。図１６に示すように、管理サーバ１００は、各車載装置１および外部装置から送信データおよび外部情報を取得すると（ステップＳ２０１）、検出条件に合致するシチュエーションを検出したか否かを判定する（ステップＳ２０２）。

管理サーバ１００は、ステップＳ２０２の判定処理において、上記のシチュエーションを検出した場合（ステップＳ２０２，Ｙｅｓ）、受信車両および候補車両を選択する（ステップＳ２０３）。

そして、管理サーバ１００は、受信車両に対して接続開始を要求して（ステップＳ２０４）、処理を終了する。また、管理サーバ１００は、ステップＳ２０２の判定処理において、上記のシチュエーションを検出しなかった場合（ステップＳ２０２，Ｎｏ）、処理を終了する。

上述したように、実施形態に係る配信システムＳは、選択部１１３と、受信部１２とを備える。選択部１１３は、車両で撮像されたカメラ画像の配信候補となる候補車両を所定条件に基づいて選択する。受信部１２は、選択部１１３によって選択された候補車両との通信接続を開始しておき、候補車両のうち、配信元として決定された配信車両からカメラ画像を受信する。したがって、実施形態に係る配信システムＳによれば、迅速にカメラ画像を受信することができる。

ところで、上述した実施形態では、各車両に搭載された車載装置１間で、カメラ画像の送受信を行う場合について説明したが、これに限定されるものではない。すなわち、各車載装置１は、管理サーバ１００を介してカメラ画像の送受信を行うことにしてもよい。

また、車載装置１間の通信については、例えば、Ｗｉ－Ｆｉ（登録商標）などの近距離無線通信を用いるなど、車両間の距離に応じて適宜変更することにしてもよい。さらに、カメラ映像の伝送のかかる遅延時間を減らすために、Ｗｉ－Ｆｉおよび携帯電話網の両方の通信を使用し、所謂リンクアグリゲーションを用いてカメラ映像やカメラ映像に紐づく車両情報、位置情報を配信先車両または管理サーバ１００へ送信する構成であってもよい。

また、上述した実施形態では、低容量映像の受信・配信で通信確立を行い高容量映像の高速受信を図っているが、受信すべき低容量映像や他情報が無い場合はダミーデータの受送信等で通信確立や通信状態の維持を行ってもよい。

また、上述した実施形態では、受信車両が車両で撮像されたカメラ画像を受信する場合について説明したが、これに限定されるものではない。すなわち、受信車両は、街路灯や信号機と言ったインフラ設備に設置された固定カメラで撮像されたカメラ画像を受信することにしてもよい。

また、実施形態に係る配信システムＳにおいては、管理サーバ１００の機能の一部または全てを各車載装置１で担う構成とすることにしてもよいし、あるいは、各車載装置１の機能の一部または全てを管理サーバ１００が担う構成とすることにしてもよい。

さらなる効果や変形例は、当業者によって容易に導き出すことができる。このため、本発明のより広範な様態は、以上のように表しかつ記述した特定の詳細および代表的な実施形態に限定されるものではない。したがって、添付の特許請求の範囲および、その均等物によって定義される統括的な発明の概念の精神または範囲から逸脱することなく、様々な変化が可能である。

１ 車載装置
１１ 送信部
１２ 受信部
１３ 決定部
１４ 生成部
１５ 再生部
５０ 表示装置
５１ 表示部
５２ 操作部
１００ 管理サーバ
１１１ 取得部
１１２ 検出部
１１３ 選択部
２０１ 交通情報サーバ（外部装置の一例）
２０２ 天候情報サーバ（外部装置の一例）
２０３ ＳＮＳサーバ（外部装置の一例）
Ｓ 配信システム

Claims (10)

1. 所定条件に基づき、カメラ画像の配信元となる複数の候補車両を特定し、前記複数の候補車両と通信接続を確立し、前記複数の候補車両それぞれから低容量のカメラ画像を受信したのち、前記複数の候補車両のうち選択された配信車両から高容量のカメラ画像を受信する自車両の車載装置と、
   前記自車両の車載装置に、前記低容量のカメラ画像と前記高容量のカメラ画像を選択的に配信可能な前記候補車両の車載装置からなる
   配信システム。
2. 複数の車両から特異事象の発生を検出した場合、又は、後続車両が前記特異事象の発生地点を回避する回避運転を検出した場合、前記検出した車両を前記配信車両と決定する、
   請求項１に記載の配信システム。
3. 前記自車両の地図表示範囲内に位置する前記候補車両を操作者が選択操作することにより、当該選択操作された前記候補車両を前記配信車両と決定する、
   請求項１または２に記載の配信システム。
4. 前記自車両から所定範囲内に位置する車両を前記候補車両として選択する、
   請求項１、２または３に記載の配信システム。
5. 前記自車両の走行予定経路に基づいて前記候補車両を選択する、
   請求項１～４のいずれか一つに記載の配信システム。
6. 外部装置から取得した外部情報に基づいて前記候補車両の選択対象とするエリアを選択する、
   請求項１～５のいずれか一つに記載の配信システム。
7. 前記自車両のユーザ属性に基づいて前記候補車両を選択する、
   請求項１～６のいずれか一つに記載の配信システム。
8. 交差点または道路標識の少なくとも一方に関する道路情報に基づいて前記候補車両を選択する、
   請求項１～７のいずれか一つに記載の配信システム。
9. コンピュータが実行する配信方法であって、
   所定条件に基づき、カメラ画像の配信元となる複数の候補車両を特定し、前記複数の候補車両と通信接続を確立し、前記複数の候補車両それぞれから低容量のカメラ画像を受信したのち、前記複数の候補車両のうち選択された配信車両から高容量のカメラ画像を受信する、
   配信方法。
10. 所定条件に基づき、カメラ画像の配信元となる複数の候補車両を特定し、前記複数の候補車両と通信接続を確立し、前記複数の候補車両それぞれから低容量のカメラ画像を受信したのち、前記複数の候補車両のうち選択された配信車両から高容量のカメラ画像を受信する、
    車載装置。

Images