JP2019041179A - 移動体通信システム - Google Patents

Abstract

【課題】サーバが配信しているデータをユーザ側装置が取得する際に生じうる通信料を抑制可能な移動体通信システムを提供する。【解決手段】サーバ２は、要求元としての車載装置１の周辺に、要求元が要求しているデータを取得済みの他の車載装置１（つまり取得済み装置）が存在しているか否かを判定する。要求元の周辺に取得済み装置が存在している場合には、狭域通信で取得対象データを取得可能であることを要求元に通知する。要求元としての車載装置は、上記の通知を受け取った場合には、要求元の周辺に車載装置からデータを狭域通信によって取得するための処理を実施する。【選択図】図１

Description

本開示は、サーバと、移動体で使用されるユーザ側装置としてのユーザ側装置との移動体通信システムに関する。

従来、移動体で使用されるユーザ側装置としての複数のユーザ側装置のそれぞれが、広域通信網を介してサーバから所定の共通データをダウンロードして利用する移動体通信システムがある。なお、ここでの共通データとは、複数のユーザ側装置において共通して利用される同一内容のデータを指す。ユーザ側装置としてのユーザ側装置とは、広域通信網に無線アクセス可能に構成されている装置であって、例えばスマートフォン等のユーザ側装置の他、車両で使用されるユーザ側装置などが該当する。

このような移動体通信システムにおいては、仮に全てのユーザ側装置がサーバから直接的にデータを取得しようとすると、サーバや、広域通信網を構成するルータでの処理負荷が問題となりうる。また、ユーザ側装置が広域通信網を介してサーバからデータを取得する構成では、ダウンロードするデータのサイズに応じた通信料が発生しうる。

ところで、複数のユーザ側装置が同一のデータを共有する方法としては、複数のユーザ側装置同士が直接に通信（いわゆるアドホック通信）を行うことにより、互いにデータを共有する方法もある。そのようにアドホック通信によるデータ共有によれば、各通信端末がサーバへアクセスする必要がないため、サーバ等での処理負荷や、通信料を軽減できる。

特許文献１では、広域通信網を介してサーバからデータを取得するための構成と、他のユーザ側装置（以降、他装置）と直接通信を実施してデータを取得する構成とを備えるユーザ側装置において、取得対象とするデータの種別に応じて、データの取得先をサーバとするのか他装置とするのかを選択する構成が開示されている。

例えば特許文献１に開示の構成では、取得対象とするデータの種別が、他装置から取得すべき種別である場合、いったん周囲のユーザ側装置に対して当該データの配信を要求する。そして、周囲に当該データを配信可能な他装置が存在しなかった場合には、サーバに対して対象データの配信を要求し、対象データをサーバから取得する。

特開２０１７−５４０７号公報

特許文献１に開示の構成では、取得対象とするデータの種別が、サーバから取得すべき種別である場合、周囲に当該データを直接的に配信可能な他装置が存在する場合であってもサーバから取得する。つまり、不要に広域通信網を介した通信を実施する場合がある。他装置から直接的にデータを取得できる場合には、当該他装置から取得したほうが、通信料を抑制できるため、通信料の観点からは好ましい。

本開示は、この事情に基づいて成されたものであり、その目的とするところは、サーバが配信しているデータをユーザ側装置が取得する際に生じうる通信料を抑制可能な移動体通信システムを提供することにある。

その目的を達成するための本開示の移動体通信システムは、移動体で使用される複数のユーザ側装置（１）と、複数のユーザ側装置で共通して使用されるデータである共通使用データを、ユーザ側装置からの要求に基づき、要求元としてのユーザ側装置に配信するサーバ（２）と、を備える移動体通信システムであって、サーバと複数のユーザ側装置のそれぞれとは、広域通信網を介して相互通信可能に構成されており、複数のユーザ側装置のそれぞれは、現在位置を示す位置情報を示す通信パケットである位置報告パケットを逐次サーバに送信する報告部（Ｗ１）と、他のユーザ側装置である他装置と、広域通信網を介さない直接的な無線通信である狭域通信を実施するための通信モジュールである狭域通信部（１２）と、を備え、サーバは、所定の書き換え可能な記憶媒体を用いて実現されているデータベースであって、ユーザ側装置毎の共通使用データの取得状況と位置情報とを示すデータが保存されている管理データベース（２２）と、複数のユーザ側装置のそれぞれから送信されてくる位置報告パケットに基づき、管理データベースに保存されている複数のユーザ側装置のそれぞれの位置情報を更新する装置情報管理部（Ｇ１）と、ユーザ側装置からの共通使用データの配信要求を受け付けた場合に、管理データベースを参照し、当該要求元の周辺に、共通使用データを取得済みのユーザ側装置である取得済み装置が存在するか否かを判定する周辺装置探索部（Ｇ３）と、周辺装置探索部によって要求元の周辺に取得済み装置が存在すると判定されたことに基づいて、要求元に対して狭域通信によって共通使用データは取得可能であることを通知する通知部（Ｇ４）と、周辺装置探索部によって要求元の周辺に取得済み装置は存在しないと判定されたことに基づいて共通使用データを配信する配信部（Ｇ５）と、を備え、要求元としてのユーザ側装置は、配信要求に対するサーバからの応答として、狭域通信によって共通使用データを取得可能であることが通知された場合、狭域通信によって要求元の周辺に存在する取得済み装置から共通使用データを取得するための処理を実施する狭域回線取得部（Ｎ１）を備える。

以上の構成においてサーバは、要求元としてのユーザ側装置の周辺に、要求元が要求している共通使用データを取得済みの他のユーザ側装置（つまり取得済み装置）が存在しなかった場合には、要求元が要求しているデータを配信しうる。一方、要求元としてのユーザ側装置の周辺に、取得済み装置が存在する場合には、狭域通信で取得対象としての共通使用データを取得可能であることを通知する。

要求元としてのユーザ側装置は、上記の通知を受け取った場合には、狭域通信によって要求元の周辺に存在する取得済み装置からデータを取得するための処理を実施する。このような構成によれば、ユーザ側装置が広域通信でサーバからデータを取得する可能性は抑制され、通信料等を抑制することができる。

なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本開示の技術的範囲を限定するものではない。

移動体通信システム１００の概略的な構成を示す図である。 車載装置１の構成を示すブロック図である。 制御部１３の構成を示す機能ブロック図である。 サーバ２の構成を示すブロック図である。 管理データベース２２に保存されている個別状況データについて説明するための図である。 サーバ制御部２３の構成を示す機能ブロック図である。 制御部１３が実施するデータ取得処理のフローチャートである。 車載装置１がサーバ２宛に送信する配信要求パケットの概略的な構成の一例を示す図である。 サーバ制御部２３が実施する配信要求応処理のフローチャートである。 近時配信可能装置について説明するための図である。 サーバ２が車載装置１に送信する狭域取得可能通知の概略的な構成を示す図である。 制御部１３が実施する狭域要求応答処理のフローチャートである。 変形例２として開示のサーバ制御部２３が実施する配信要求応答処理に対応するフローチャートである。 変形例３として開示のサーバ制御部２３の作動を説明するための図である。 フラグメントの概念を説明するための図である。 フラグメント単位でデータの送受信をする場合の移動体通信システム１００の作動を説明するための図である。 フラグメント単位でデータの送受信をする場合の車載装置１の作動を説明するための図である。 正規性判定部Ｆ５を備える制御部１３を示すブロック図である。

以下、本開示の実施形態について図を用いて説明する。図１は、本開示に係る移動体通信システム１００の概略的な構成の一例を示す図である。図１に示すように、移動体通信システム１００は、複数の車両Ｍａ，Ｍｂ，Ｍｃの各々に搭載されている複数の車載装置１と、サーバ２と、を備える。

なお、図１では、便宜上、車載装置１が搭載されている車両（以降、搭載車両）として、車両Ｍａ，Ｍｂ、Ｍｃの３台しか図示していないが、実際には多数（例えば４台以上）存在する。以降において、搭載車両Ｍａ，Ｍｂ，Ｍｃに搭載されている車載装置１を区別する場合、車載装置１ａ、１ｂ、１ｃと記載する。

或る車載装置１にとっては、その車載装置１が搭載されている車両が自車両に相当し、自車両以外の車両は他車両に相当する。また、他車両に搭載されている車載装置１は他装置に相当する。例えば車載装置１ａにとっては車両Ｍａが自車両に相当し、車両Ｍｂ、Ｍｃは他車両である。また、車載装置１ａにとって車載装置１ｂ、１ｃは他装置である。他装置の存在を前提として、或る車載装置１にとっての自分自身を指す場合には自装置と記載する。車載装置１は車載システムとも言い換えることができる。車載装置１が請求項に記載のユーザ側装置に相当する。

各搭載車両は、道路上を走行する車両である。搭載車両は、四輪自動車のほか、二輪自動車、三輪自動車等であってもよい。二輪自動車には原動機付き自転車も含まれる。本実施形態では一例として搭載車両は、四輪自動車とする。

＜全体の概要＞
各車載装置１は、所定のソフトウェアを実行することによって、当該ソフトウェアに対応する機能を提供する装置である。また、サーバ２は、車載装置１で使用されるソフトウェアのバージョンアップが生じた場合に当該ソフトウェアの更新プログラムを配信するサーバである。

ソフトウェアの更新プログラムは、当該ソフトウェアを利用している車載装置１で共通して使用される。そのため、ソフトウェアの更新プログラムは複数の車載装置１で共通して使用されるデータ（つまり共通使用データ）に相当する。以降におけるソフトウェアとは、車載装置１が使用するソフトウェアであって、サーバ２がその更新プログラム等を配信するソフトウェアとする。なお、サーバ２は複数種類のソフトウェアの更新プログラムを配信するものであってもよい。

なお、各車載装置１で使用されるソフトウェアとしては、例えば、ＯＳ（Operating System）や、車両制御系のソフトウェア、周辺監視系ソフトウェア、ＨＭＩ制御系のソフトウェアなどがある。車両制御系ソフトウェアとは、車両の制御にかかるソフトウェアである。周辺監視系のソフトウェアとはミリ波レーダやレーザレーダ、カメラ等の周辺監視デバイスの出力データに基づいて車両周辺の情報を生成するソフトウェアである。ＨＭＩ制御系ソフトウェアとは、ドライバへの情報提示（いわゆるＨＭＩ：Human Machine Interface）に係るデバイスの作動を制御するためのソフトウェアである。

上述した種々のソフトウェアは、さらに機能毎に細分化されうる。例えば車両制御ソフトウェアは、ドライバの運転操作を支援するための車両制御を実行する運転支援系ソフトウェアや、自動運転機能を提供する自動運転ソフトウェアなどに区分されうる。エンジンやモータの駆動源を制御するソフトウェアや、操舵アクチュエータを制御するソフトウェアなども車両制御系ソフトウェアに該当する。

その他、ナビゲーション機能を提供するソフトウェアや、空調装置の作動を制御するソフトウェアなどといった、ユーザの利便性に係る機能を提供するアプリケーションソフトウェア（利便系ソフトウェア）も、車載装置１で使用されるソフトウェアに該当しうる。つまり、車両に搭載されている種々の電子制御装置（以降、ＥＣＵ：Electronic Control Unit）で使用されるソフトウェアは、車載装置１で使用されるソフトウェアに該当する。更新プログラムの配信等、サーバ２が取り扱うソフトウェアの種類は適宜設計されればよい。

各車載装置１は、広域通信網３に無線接続可能に構成されている。ここでの広域通信網３とは、携帯電話網やインターネット等の、電気通信事業者によって提供される公衆通信ネットワークを指す。図１に示す基地局４は、車載装置１が広域通信網３に無線接続するための無線基地局である。

また、各車載装置１は、所定の周波数帯の電波を用いて自装置としての車載装置１の周辺に存在する他の車載装置１と狭域通信可能に構成されている。ここでの狭域通信とは、広域通信網を介さない、他の車載装置１との直接的な無線通信である。

狭域通信を実現するための周波数、変調方式等を規定する規格は、任意の規格を採用する事ができる。ここでは一例として、車載装置１が車両に搭載されていることを踏まえ、狭域通信は、ＩＥＥＥ１６０９等にて開示されているＷＡＶＥ（Wireless Access in Vehicular Environment）の規格に準拠している実施されるものとする。なお、ＷＡＶＥは車両同士の直接的な無線通信（いわゆる車車間通信）についての規格である。車載装置１同士が実行する狭域通信は、別の観点によれば、車車間通信に相当する。

サーバ２は、広域通信網３と有線又は無線接続されている。サーバ２は、前述の通り、車載装置１で使用されているソフトウェアの更新プログラムを配信する構成である。サーバ２は、或るソフトウェアの更新プログラムが発生した場合には、その旨を当該ソフトウェアを使用している各車載装置１に通知する。これにより、各車載装置１は、サーバ２から取得すべきデータ（すなわち使用中のソフトウェアの更新プログラム）が存在するかを認識する。車載装置１は、サーバ２から取得すべきデータの存在を検出した場合、所定のタイミングで、当該データの配信要求をサーバ２に送信する。

なお、車載装置１は、ソフトウェアの更新プログラムがリリースされたか否かをサーバ２に所定の周期で問い合わせることで、車載装置１はサーバ２から取得すべきデータが存在するか否かを逐次判定してもよい。

そして、サーバ２は、車載装置１からの要求に基づき、要求元としての車載装置１に対して、当該車載装置１が要求しているデータ（以降、要求データ）を配信する。ただし、別途後述するように、要求元としての車載装置１の周辺に、既に要求データを取得している車載装置１（以降、取得済み装置）が存在する場合には、狭域通信によって当該取得済み装置から取得可能であることを通知し、狭域通信による取得を実施させる。以下、移動体通信システム１００を構成する種々の要素について順に詳細に説明する。

＜車載装置１の構成＞
まずは、車載装置１の構成について述べる。車載装置１は、図２に示すように、広域通信部１１、狭域通信部１２、及び制御部１３を備える。また、車載装置１は、車両内に構築されている通信ネットワーク５を介して、車両に搭載されている種々のセンサ６や、ロケータ７とも、単方向／双方向通信可能に接続されている。

センサ６は、搭載車両の状態を示す所定の物理状態量を検出するセンサである。例えば自車両の絶対方位を検出する方位センサがセンサ６に該当する。方位センサとしては例えば、地磁気センサが用いられる。また、走行速度を検出する車速センサもまた、センサ６に該当する。その他、方向指示器の動作状態を示す検出する方向指示器センサもセンサ６に該当するものとする。種々のセンサ６は、検出対象とする物理状態量の現在の値（つまり検出結果）を示すデータを車載装置１に逐次提供する。なお、種々の車載センサの検出結果は、１つ又は複数のＥＣＵ等を介して車載装置１に提供される構成となっていても良い。

なお、センサ６として車載装置１が接続されるべきセンサの種類は適宜設計されればよく、上述した全てのセンサと接続されている必要はない。また、上述した以外のセンサ、例えばアクセル踏込量を検出するアクセルセンサや、ブレーキ踏込量を検出するブレーキセンサ、シフトポジションを検出するシフトポジションセンサなどと接続されていても良い。

ロケータ７は、当該ロケータ７が用いられている車両（つまり自車両）の位置を逐次算出（換言すれば特定）する装置である。例えばロケータ７は、ＧＮＳＳ（Global Navigation Satellite System）を構成する測位衛星が送信する測位信号を受信するＧＮＳＳ受信機を備え、ＧＮＳＳ受信機が受信した測位信号を用いて位置を算出する。

なお、ロケータ７は、ＧＮＳＳ受信機の測位結果と、ジャイロセンサや車速センサなどの計測結果との組み合わせにより位置を決定するものであってもよい。さらに、ロケータ７は、決定した位置の軌跡を地図データが示す道路形状に重ね合わせる処理（いわゆるマップマッチング処理）を実施することで位置の補正を行う構成としてもよい。ロケータ７が逐次特定する現在位置を示す位置情報は、車載装置１に提供される。

広域通信部１１は、広域通信網３に無線接続し、車載装置１が広域通信網３を介して他の通信装置（ここではサーバ２）と通信するための通信モジュールである。この広域通信部１１は、より細かい要素として、図示しない広域通信用アンテナ及び広域通信用送受信部を備える。

広域通信用アンテナは、基地局４との無線通信に用いられる所定の周波数帯の電波を送受信するためのアンテナである。広域通信用送受信部は、広域通信用アンテナで受信した信号を復調して制御部１３に提供するとともに、制御部１３から入力されたデータを変調して広域通信用アンテナに出力し、無線送信する。

これら広域通信用アンテナ及び広域通信用送受信部の協働により、広域通信部１１は、受信したデータを制御部１３に出力するとともに、制御部１３から入力されたデータを変調して外部装置（例えばサーバ２）に送信する通信モジュールとして機能する。

狭域通信部１２は、所定の周波数帯の電波を用いて他の車載装置１と直接的な無線通信（つまり狭域通信）を実施するための通信モジュールである。この狭域通信部１２は、より細かい要素として、図示しない狭域通信用アンテナ及び狭域通信用送受信部を備える。

狭域通信用アンテナは、狭域通信に用いられる周波数帯（例えば７６０ＭＨｚ帯や５．８ＧＨｚ帯）の電波を送受信するためのアンテナである。狭域通信用送受信部は、狭域通信用アンテナで受信した信号を復調して制御部１３に提供するとともに、制御部１３から入力されたデータを変調して狭域通信用アンテナに出力し、無線送信する。

なお、本実施形態の狭域通信部１２は、車車間通信を実現する通信モジュールである。車車間通信用の通信モジュールとしての狭域通信部１２は、自装置を中心とする半径数百ｍ以内に存在する他装置と通信可能に構成されている。

ただし、本実施形態では一例として狭域通信部１２は、通信範囲が数百ｍ程度となる車車間通信規格に準拠した無線通信機能を提供する通信モジュールとするが、これに限らない。他の態様として狭域通信部１２は、通信範囲が例えば最大でも数十メートル程度となる所定の近距離無線通信規格に準拠した通信（以降、近距離通信とする）を実施する通信モジュールであっても良い。例えばBluetooth Low Energy（Ｂｌｕｅｔｏｏｔｈは登録商標）や、Ｗｉ−Ｆｉ（登録商標）、ＺｉｇＢｅｅ（登録商標）等が上述した近距離無線通信規格に該当する。

制御部１３は、ＣＰＵ１３１、ＲＡＭ１３２、ＲＯＭ１３３、フラッシュメモリ１３４、Ｉ／Ｏ１３５、及びこれらの構成を接続するバスラインなどを備えたコンピュータとして構成されている。ＣＰＵ１３１は中央演算処理装置であり、ＲＡＭ１３２は揮発性メモリであり、ＲＯＭ１３３は書き換え不可能な不揮発性の記憶媒体である。ＲＯＭ１３３には、ファームウェアや、車載装置１に割り当てられている装置固有の識別番号（以降、装置ＩＤ）等が保存されている。フラッシュメモリ１３４は書き換え可能な不揮発性の記憶媒体である。

フラッシュメモリ１３４には、自車両の車両モデルや、通常のコンピュータを車載装置１として機能させるためのプログラム（以降、ＵＥ用プログラム）が格納されている。ＵＥ用プログラムには、ＯＳや、ミドルウェア、アプリケーションソフトウェアなどが含まれる。アプリケーションソフトウェアには、サーバ２が取り扱うソフトウェアも含まれる。

なお、通常のコンピュータを車載装置１として機能させるためのプログラム（以降、ＵＥ用プログラム）は、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよく、その具体的な記憶媒体はフラッシュメモリ１３４に限らない。光や電磁波といった伝送媒体を除く、実体を有する記憶媒体であれば良い。ＣＰＵ１３１がＵＥ用プログラムを実行することは、ＵＥ用プログラムに対応する方法が実行されることに相当する。なお、ＵＥはUser Equipmentの略である。

制御部１３は、ＣＰＵ１３１がフラッシュメモリ１３４等に格納されている上述のＵＥ用プログラムを実行することによって、図３に示す種々の機能を提供する。すなわち、制御部１３は、例えばソフトウェアの更新プログラムの取得状況の管理などといった内部的な処理を実施する内部処理部Ｆｎと、広域通信部１１とのデータのやり取りに係る処理を実施する広域通信処理部Ｗｎと、狭域通信部１２とのデータのやり取りに係る処理を実施する狭域通信処理部Ｎｎと、を備える。

内部処理部Ｆｎは、より細かい機能ブロックとして、機能提供部Ｆ１、取得対象検出部Ｆ２、取得状況管理部Ｆ３、及びプログラム適用部Ｆ４を備える。広域通信処理部Ｗｎはより細かい機能ブロックとして、報告部Ｗ１、サーバ要求部Ｗ２、及びサーバ応答取得部Ｗ３を備える。狭域通信処理部Ｎｎはより細かい機能ブロックとして、狭域回線取得部Ｎ１、狭域要求受付部Ｎ２、及び配信処理部Ｎ３を備える。

なお、制御部１３が備える機能ブロックの一部又は全部は、ハードウェアとして実現されていてもよい。ハードウェアとして実現する態様には１つ又は複数のＩＣを用いて実現する態様も含まれる。機能提供部Ｆ１は、フラッシュメモリに格納されているソフトウェアを実行することにより、当該ソフトウェアに対応する所定の機能を提供する構成である。機能提供部Ｆ１は一般的なコンピュータでのアプリケーション層に相当する。

取得対象検出部Ｆ２は、自装置が取得すべきデータ（以降、取得対象データ）を検出する構成である。取得対象データとは、本実施形態においてはソフトウェアの更新プログラムである。本実施形態の取得対象検出部Ｆ２は、サーバ２から配信されるリリース通知に基づき、取得対象データとしての更新プログラムの存在を検出するものとする。なお、ここでのリリース通知とは、ソフトウェア更新プログラムが利用可能となったことを通知する通信パケットである。リリース通知には、当該データの取得期限が含まれていても良い。

取得対象検出部Ｆ２は、サーバ２から配信されてきたリリース通知に基づいて未取得の更新プログラムが存在することを検出した場合には、当該更新プログラムを取得対象リストに追加する。取得対象リストは、取得対象データのリストである。取得対象データが存在する場合、制御部１３は別途後述するデータ取得処理を実行する。

なお、取得対象検出部Ｆ２は、所定の確認周期で、広域通信処理部Ｗｎと協働して、ソフトウェアの更新プログラムがリリースされているか否かを問い合わせる処理を実施することによって、取得対象データの存在を検出してもよい。便宜上、広域通信処理部Ｗｎが生成して送信する、ソフトウェアの更新プログラムがリリースされているか否かを問い合わせる通信パケットのことを更新クエリとも称する。なお、取得対象データを検出することは、別の観点によれば、取得対象データが存在するか否かを判定することに相当する。

取得状況管理部Ｆ３は、取得対象検出部Ｆ２が検出した取得対象データの取得状況を管理する構成である。取得対象検出部Ｆ２が検出した時点においては、当該取得対象データの取得状況は、未取得に設定される。また、後述するデータ取得処理の結果、取得対象データを取得できた場合には、取得状況を取得済みに設定する。なお、取得対象データを取得できた場合には、取得対象リストから当該データの欄を削除することによって、取得済みであることを内部状態として管理しても良い。プログラム適用部Ｆ４は、サーバ２等から取得した更新プログラムを使用（換言すれば適用）する構成である。

報告部Ｗ１は、サーバ２に対して、自分自身の現在位置や、取得対象データの取得状況等を報告する構成である。例えば、報告部Ｗ１は、所定の報告周期で、位置報告処理を実施する。位置報告処理は、自分自身の現在位置を示す通信パケット（以降、位置報告パケット）を、広域通信網３を介してサーバ２へ逐次送信する処理である。報告周期は２００ミリ秒や１秒といった、数秒以内の値に設定されていることが好ましい。

位置報告パケットには、搭載車両の現在位置を示す位置情報に加えて、そのデータを送信した車載装置１を示す送信元情報や、当該データの生成時刻などの付加情報も含まれている。送信元情報は、送信元としての車載装置１に対して予め割り当てられた、他の車載装置１と区別するための識別情報（つまり装置ＩＤ）である。これらの付加情報は、例えば位置報告パケットとして機能する通信パケットのヘッダ等に記載されていればよい。

また、本実施形態ではより好ましい態様として、位置報告パケットには、自車両の走行速度（換言すれば移動速度）を示すデータ、進行方向としての方位を示すデータや、方向指示器の作動状態を示すデータも含まれているものとする。進行方向としての方位を示すデータや方向指示器の作動状態を示すデータは、送信元としての車載装置１の移動方向を示すデータに相当する。移動方向を示すデータは、絶対方位を示すデータに限らない。移動方向を示すデータは、現在位置からユーザによって設定されている目的地までの走行予定経路を示すデータであってもよい。

サーバ要求部Ｗ２は、取得対象データの配信を要求する通信パケット（以降、配信要求パケット）を送信する構成である。制御部１３が備える各機能ブロックの詳細については別途後述する。

＜サーバ２の構成について＞
次に、サーバ２の構成について説明する。サーバ２は、図４に示すように、サーバ側通信部２１、管理データベース（以降、管理ＤＢ）２２、及びサーバ制御部２３を備える。サーバ側通信部２１は、広域通信網３に接続し、種々の外部装置（例えば車載装置１）と通信するための通信モジュールである。なお、本実施形態では一例としてサーバ２は広域通信網３に有線接続している態様とするが、これに限らない。サーバ２は、広域通信網３に無線接続する構成となっていても良い。サーバ２は、複数のコンピュータを用いて実現されていてもよい。また、サーバ２は仮想的に実現されたサーバ（いわゆる仮想サーバ）などであってもよい。クラウドコンピューティング技術などを用いて実現することができる。

サーバ側通信部２１は、サーバ２を宛先とする通信パケットを受信し、サーバ制御部２３にその受信データを提供する。例えば、サーバ側通信部２１は、位置報告パケットや配信要求パケット、更新クエリなどを受信する。また、サーバ側通信部２１は、サーバ制御部２３から入力されたデータを変調して１つ又は複数の車載装置１に送信する。例えばサーバ側通信部２１は、リリース通知や更新プログラムを送信する。

なお、サーバ２は、データの送信方式として、ユニキャストと、マルチキャストと、ブロードキャストとを使い分けることができるように構成されているものとする。ユニキャストは、特定の１つの車載装置１を宛先としてデータを送信する方式であり、マルチキャストは特定の複数の車載装置１を宛先としてデータを送信する方式である。ブロードキャストは、全ての車載装置１に対してデータを送信する方式である。ユニキャストは例えば個々の車載装置１に対する応答を返す場合に採用する。一方、マルチキャストやブロードキャストは、例えばリリース通知を配信する場合に利用される。

管理ＤＢ２２は、書き換え可能な不揮発性の記憶媒体を用いて実現されるデータベースである。管理ＤＢ２２は、サーバ制御部２３によるデータの書き込み、読出、削除等が実施可能に構成されている。管理ＤＢ２２には、車載装置１毎の位置情報や、更新プログラムの取得状況などを示すデータ（以降、個別状況データ）が、装置ＩＤと対応付けられて保存されている。例えば車載装置１毎の個別状況データは、リスト形式など、任意のデータ構造によって保持されていれば良い。図５は、管理ＤＢ２２に保存されている車載装置１毎の個別状況データを概念的に示したものである。以降では一例として、車両Ｍａ、Ｍｂ、Ｍｃに割り当てられている装置ＩＤを順に、１０１、１０２、１０３として説明する。図５において装置ＩＤ＝１０１に対応付けられている種々の情報は、車両Ｍａについての個別状況データを示している。データ取得状況の欄における丸記号は取得済みであることを意味し、バツ記号は未取得であることを意味している。

サーバ制御部２３は、サーバ２の作動を制御する構成である。サーバ制御部２３は、ＣＰＵ２３１、ＲＡＭ２３２、ＲＯＭ２３３、フラッシュメモリ２３４、Ｉ／Ｏ２３５、及びこれらの構成を接続するバスラインなどを備えたコンピュータとして構成されている。フラッシュメモリ２３４には、通常のコンピュータをサーバ制御部２３として機能させるためのプログラム（以降、配信制御プログラム）などが格納されている。

なお、配信制御プログラムは、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよく、その具体的な記憶媒体はフラッシュメモリ２３４に限らない。光や電磁波といった伝送媒体を除く、実体を有する記憶媒体（例えばＨＤＤ：ハードディスクドライブ）であれば良い。ＣＰＵ２３１が配信制御プログラムを実行することは、配信制御プログラムに対応する方法が実行されることに相当する。

サーバ制御部２３は、ＣＰＵ２３１がフラッシュメモリ２３４に格納されている配信制御プログラムを実行することによって、図６に示す種々の機能を提供する。すなわち、サーバ制御部２３は、装置情報管理部Ｇ１、配信要求受付部Ｇ２、配信装置探索部Ｇ３、通知部Ｇ４、配信部Ｇ５、及び期限管理部Ｇ６を備える。

装置情報管理部Ｇ１は、車載装置１から送信されてくる位置報告パケットに基づいて、管理ＤＢ２２に保存されている車載装置１毎の位置情報等を更新する。すなわち、サーバ側通信部２１が位置報告パケットを受信する度に、管理ＤＢ２２に保存されている、当該通信パケットの送信元についての位置情報や、移動速度、進行方向、方向指示器の動作状態を更新する。

配信要求受付部Ｇ２は、車載装置１からの更新プログラムの配信要求を受け付ける構成である。配信要求受付部Ｇ２は、サーバ側通信部２１が受信した配信要求パケットに示される装置ＩＤから、要求元に対応する車載装置１（以降、要求元装置）を特定する。サーバ２にとって車載装置１から配信を要求されているデータ（つまり要求データ）は、要求元としての車載装置１にとっては取得対象データである。

また、サーバ制御部２３が備える他の機能ブロックについての詳細は別途後述するが、概略的には次の通りである。配信装置探索部Ｇ３は、要求元装置の周辺に存在する他の車載装置１でのデータ取得状況に基づいて、要求元装置は他の車載装置１から狭域通信で取得対象データを取得可能であるか否かを判定する構成である。配信装置探索部Ｇ３が請求項に記載の周辺装置探索部に相当する。

通知部Ｇ４は、配信装置探索部Ｇ３によって要求元装置は他の車載装置１から狭域通信で取得対象データを取得可能であると判定されたことに基づいて、要求元装置に対して狭域通信で取得対象データを取得可能であることを通知する構成である。配信部Ｇ５は、配信装置探索部Ｇ３によって要求元装置は他の車載装置１から狭域通信で取得対象データを取得不可能であると判定された場合に、要求元装置に対して、取得対象データを配信する構成である。

なお、狭域通信で取得対象データを取得不可能である状態には、取得困難な状態を含めても良い。狭域通信で取得対象データを取得困難な状態とは、例えば、周辺にすぐに配信可能な他装置が存在しない場合や、仮に存在したとしても残されている通信可能な時間がデータ配信に必要な時間に対して十分でない場合などである。

また通知部Ｇ４は、より具体的に、周辺にすぐに配信可能な他装置、もしくは、間もなく配信可能となる他装置がいない、等の取得困難な理由を含めて要求元装置に通知しても良い。便宜上、通知部Ｇ４によって送信される、狭域通信で取得対象データを取得可能であることを示す通信パケットを、狭域取得可能通知とも称する。

なお、本実施形態では一例として、配信装置探索部Ｇ３によって要求元装置は他の車載装置１から狭域通信で取得対象データを取得可能であると判定された場合には常に狭域取得通知を送信するものとするが、これに限らない。広域通信網の混雑状況や要求元装置からの要求内容によっては、要求元装置の周辺に要求データを保持している他装置が存在する場合であっても、狭域取得可能通知を送信せずに、配信部Ｇ５が要求データを配信するように構成されていても良い。例えば、要求元装置から広域通信で取得することを希望する旨の配信要求を受け付けた場合には、要求元装置の周辺に要求データを保持している他装置が存在する場合であっても、広域通信で配信してもよい。サーバ２は、要求元装置と、代理配信装置を含む周辺取得済み装置の少なくとも何れか一方に所定の指示信号を送信することで、要求元装置に狭域通信によって要求データを取得させる処理である配信制御処理を実行する機能を備えていればよい。

期限管理部Ｇ６は、過去に配信要求パケットを送信してきた車載装置１（以降、要求済み装置）のデータ取得状況を管理する構成である。期限管理部Ｇ６は、要求済み装置の取得期限までの残り時間を参照し、取得期限までの残り時間が十分であるかを逐次判定する。期限管理部Ｇ６は、取得期限を過ぎている場合、又は、取得期限まで残り時間が所定の閾値未満となっている要求済み装置が存在する場合には、配信部Ｇ５と協働して、当該装置に対して要求データを広域通信で配信する。そのような構成によれば、車載装置１は最終的には広域通信によって取得対象データを取得できる。つまり、車載装置１が取得対象データを取得できない状態が継続する恐れを低減できる。

＜データ取得処理＞
次に、制御部１３が実施するデータ取得処理について、図７を用いて説明する。データ取得処理は、取得対象検出部Ｆ２によって検出された取得対象データを取得するための処理である。図７に示すデータ取得処理は、例えば、取得対象検出部Ｆ２が取得対象データの存在を検出したタイミングで開始されればよい。また、取得対象データが存在している状態において、所定の要求実行条件が充足した場合に開始されてもよい。

例えばイグニッション電源等の走行用電源がオンとなってから所定時間以内であることを要求実行条件として採用しても良い。そのような設定によれば、自車両が走行を開始した直後に本フローが開始されることになる。そのため、本フロー開始後にすぐに走行用電源がオフとなってフローが中断したり、本フロー継続のためにバッテリ電源を消費することによってバッテリ上がりを発生させたりする恐れを低減する事ができる。

また、ユーザによって設定されている目的地と現在位置の位置関係から、イグニッション電源がオフとなるまでの残り時間（以降、トリップ継続時間）を推定し、そのトリップ継続時間が所定の閾値以上となっていることを要求実行条件に含めてもよい。そのような設定によっても上記と同様の効果を奏する。

さらに、ユーザによって設定されている目的地と現在位置の位置関係から定まる走行予定経路が、国道等の相対的に車両の通行量が多いことが期待される種別の道路を通過することを、要求実行条件に含めてもよい。そのような態様によれば後述するように、自車両の走行が終了するまでに、多数の他車両（換言すれば他装置）と並走、またはすれ違う可能性が高い。その結果、狭域通信によって取得対象データを取得できる可能性を高めることができる。その他、自車両の走行用電源がオフとなったことを要求実行条件に含めても良い。

このデータ取得処理は、制御部１３が広域通信部１１や狭域通信部１２と協働（換言すれば連携）して実行される。データ取得処理の最初のステップＳ１０１ではサーバ要求部Ｗ２が広域通信部１１と連携して配信要求パケットをサーバ２に送信してステップＳ１０２に移る。配信要求パケットは、例えば図８に示すように、送信元情報としての装置ＩＤ、取得対象情報、及び、取得期限を含んでいるものとする。

取得対象情報は、車載装置１が要求しているデータをサーバ２が特定するための情報である。取得対象情報は、上記の目的を達する情報であればなんでもよい。例えば取得対象データに、リリース番号などの識別番号が付与されている場合には、当該識別番号を取得対象情報として採用することができる。取得対象情報は、別の観点によれば、取得対象データについての情報（いわゆるメタデータ）である。例えばソフトウェアの種類や、バージョン番号、リリース日なども取得対象情報に該当する。

取得期限情報は、取得対象データの取得期限を示す情報である。取得期限は、制御部１３が取得対象データの種別に応じて設定する。また、リリース通知に取得期限が指定されている場合には、当該指定された期限を採用しても良い。つまり、取得期限はサーバ２が設定しても良い。なお、配信要求パケットの構成要素として取得期限情報は必須の要素ではない。配信要求パケットは、送信元情報と取得対象情報を含んでいればよい。取得期限は、日時で表現されてもよいし、配信要求パケットを送信してからの経過時間で表現されても良い。

ステップＳ１０２ではサーバ２からの応答を受信してステップＳ１０３を実行する。ステップＳ１０３ではサーバ２からの応答として、狭域取得可能通知を受信したか否かを判定する。ステップＳ１０２で受信したデータが狭域取得可能通知である場合にはステップＳ１０３を肯定判定し、ステップＳ１０４を実行する。一方、ステップＳ１０２で受信したデータが狭域取得可能通知ではない場合、つまり、ステップＳ１０２で受信したデータが取得対象データそのものである場合にはステップＳ１０７を実行する。

ステップＳ１０４では狭域回線取得部Ｎ１が狭域通信部１２と連携して、他の車載装置１に対して取得対象データの送信を要求する通信パケット（以降、狭域要求パケット）を同報送信してステップＳ１０５に移る。なお、狭域要求パケットには、サーバ２に対して送信する配信要求パケットと同様に、取得対象情報が含まれているものとする。

ステップＳ１０５では狭域回線取得部Ｎ１が、他の車載装置１から狭域通信で取得対象データが送信されてきたか否か（換言すれば受信したか否か）を判定する。狭域回線取得部Ｎ１は、狭域通信によって他の車載装置１から取得対象データを取得する構成である。他の車載装置１から狭域通信で取得対象データを受信できた場合にはステップＳ１０５を肯定判定してステップＳ１０６を実行する。

一方、ステップＳ１０４において狭域要求パケットを送信してから所定の応答待機時間経過しても、取得対象データを受信できなかった場合には、ステップＳ１０５を否定判定してステップＳ１０９を実行する。なお、応答待機時間は例えば数秒から数分間などに設定されていればよい。また、狭域回線取得部Ｎ１は、応答待機時間中に所定の要求間隔で狭域要求パケットを送信しても良い。その場合の応答待機時間の計測を開始する時点（換言すれば起算時点）は、１回目の狭域要求パケットを送信したときとすればよい。要求間隔は、応答待機時間の半分以下の値に設定されていればよい。例えば要求間隔は１００ミリ秒〜数秒程度に設定されていればよい。例えば応答待機時間が２秒に設定されている場合には、４００ミリ秒程度に設定されれば良い。

ステップＳ１０６ではステップＳ１０５で受信したデータを保存し、ステップＳ１０８に移る。ステップＳ１０７ではサーバ２から送信されてきた取得対象データを保存してステップＳ１０８を実行する。ステップＳ１０８では、取得状況を取得済みに変更してステップＳ１０９に移る。ステップＳ１０９では報告部Ｗ１がサーバ２に取得成功通知を送信して本フローを終了する。取得成功通知は、取得対象データを取得できたことをサーバ２に報告する通信パケットである。

なお、取得対象データとしての更新プログラムを、広域通信又は狭域通信によって取得できた場合に、その受信した更新プログラムを適用（換言すればインストール）するタイミングについては適宜設計されれば良い。例えば車両の走行制御に影響がない種類のソフトウェアの更新プログラムである場合には、受信次第、適用する処理を開始しても良い。また、ユーザによって指定されたタイミング（例えば走行用電源オフ時）に適用する処理を実行しても良い。ソフトウェア本体への適用等によって使用済みとなった更新プログラムは、所定のタイミングで削除されればよい。例えば１ヶ月保存されたのちに削除されればよい。削除のタイミングは、フラッシュメモリ１３４に保存されているデータの量に応じて制御部１３が判断しても良いし、サーバ２によって指定されても良い。

ステップＳ１１０では報告部Ｗ１がサーバ２に取得失敗通知を送信して本フローを終了する。取得失敗通知は、狭域通信での取得対象データの取得に失敗したことをサーバ２に報告する通信パケットである。ステップＳ１１０での処理が完了すると本フローを終了する。なお、狭域通信で取得対象データを取得できなかった場合、本フロー終了時点における取得対象データの取得状況は未取得のままである。

データ取得処理を実行した結果として取得対象データを取得できなかった場合には、制御部１３は、一定時間経過後に再びデータ取得処理を実行する。取得対象データを取得するまで、所定の周期でデータ取得処理を実行する。

＜配信要求応答処理＞
次に、サーバ制御部２３が実施する配信要求応答処理について、図９を用いて説明する。配信要求応答処理は、車載装置１からの配信要求に対する応答として実行する処理である。図９に示す配信要求応答処理は、サーバ側通信部２１が受信した配信要求パケットに基づいて配信要求受付部Ｇ２が、車載装置１からの配信要求を受け付ける度に逐次実行されれば良い。

まずステップＳ２０１では配信装置探索部Ｇ３が、管理ＤＢ２２を参照し、要求元装置と現在狭域通信可能な位置に存在し、かつ、要求元装置が要求しているデータ（つまり要求データ）を既に取得済みの車載装置１を検索する。要求データは前述の通り、要求元装置にとっての取得対象データに相当する。

ここでの現在（換言すれば現時点）とは、車載装置１からの配信要求を受け付けた時点を指す。現在要求元装置と狭域通信可能な範囲に存在する取得済み装置は、サーバ２が配信要求を受け付けた時点で狭域通信によって要求データを配信可能な車載装置１である。故に、現在要求元装置と狭域通信可能な範囲に存在する取得済み装置のことを以降では即時配信可能装置とも称する。

即時配信可能装置とは、例えば、要求元装置の現在位置から所定の狭域通信可能距離Ｒｎ（単位：ｍ）以内に存在する車載装置１とすることができる。狭域通信可能距離Ｒｎは数百ｍ程度であって、例えば１５０ｍである。狭域通信可能距離Ｒｎは狭域通信部１２が通信可能な距離の想定値として設計される。なお、狭域通信可能距離Ｒｎは、実際の電波の伝搬距離よりもソフトウェア的に短く設定することもできる。

そして、それらの装置の中から、さらに、要求データを取得済みの装置を抽出する。なお、要求データを取得済みの車載装置１には、現在、広域通信で当該データを取得中である車載装置１も含めてもよい。そのような車載装置１も、要求元装置が狭域要求パケットを送信するまでには、当該データを取得済みとなっていることが期待できるためである。便宜上、要求データを取得済みの車載装置１のことを取得済み装置とも記載する。

ステップＳ２０１での検索処理の結果、検索条件を充足する車載装置１が発見された場合には、ステップＳ２０２を肯定判定してステップＳ２０３を実行する。一方、ステップＳ２０１での検索処理の結果、検索条件を充足する車載装置１が発見されなかった場合には、ステップＳ２０２を否定判定してステップＳ２０４を実行する。

ステップＳ２０１〜Ｓ２０２の処理は、要求元装置が狭域通信可能な範囲内に、要求データを取得済みの車載装置１（つまり即時配信可能装置）が存在するか否かを判定する処理に相当する。ステップＳ２０３では通知部Ｇ４が、要求元装置に狭域取得可能通知を送信して本フローを終了する。

ステップＳ２０４では配信装置探索部Ｇ３が、管理ＤＢ２２を参照し、要求元装置とこれから狭域通信可能となる可能性がある取得済み装置を検索する。これから要求元装置と狭域通信可能となる可能性がある取得済み装置とは、少なくとも要求元装置としての車載装置１と、互いの距離が減少関係（つまり接近関係）にある取得済み装置である。以降では要求元装置と狭域通信可能となる可能性がある取得済み装置のことを、近時配信可能装置とも称する。

近時配信可能装置は、例えば図１０に示すように、要求元装置が移動している道路（以降、要求元走行路）Ｒ１の要求元装置の移動方向に存在し、かつ、要求元装置が存在する方向に移動している取得済み装置である。すなわち、要求元装置が搭載されている車両（要求元車両）Ｍ１にとっての対向車で使用されている他装置である。また、要求元走行路において要求元車両の前方に存在する交差点に接続している道路（以降、合流路）Ｒ２を走行している車両Ｍ３、Ｍ４で使用されている取得済み装置もまた、近時配信可能装置に該当しうる。

なお、抽出される取得済み装置は、所定の許容遅延時間以内に、要求元装置からの距離が狭域通信可能距離Ｒｎ以内となる取得済み装置であることが好ましい。或る車載装置１と要求元装置都の距離が、所定時間以内に狭域通信可能距離Ｒｎ以内となるか否かは、各車載装置１の現在位置、進行方向、及び移動速度から推定することができる。また、所定時間以内に狭域通信可能距離Ｒｎ以内となるか否かは、各車両の方向指示器の動作状態を考慮して推定することが好ましい。所定時間以内に２つの車両の距離が所定距離以内となるか否かを推定する方法については、例えば、衝突の可能性を推定するための方法を援用して実施する事ができるため、ここではその詳細な説明は省略する。許容遅延時間は、取得期限に応じて設定されれば良い。許容遅延時間は、取得期限の半分以下に設定されることが好ましい。

ステップＳ２０４での検索処理の結果、近時配信可能装置が発見された場合にはステップＳ２０５を肯定判定してステップＳ２０６を実行する。一方、ステップＳ２０４での検索処理の結果、近時配信可能装置が発見されなかった場合にはステップＳ２０５を否定判定してステップＳ２０７を実行する。なお、ステップＳ２０４〜Ｓ２０５の処理は、近時配信可能装置が存在するか否かを判定する処理に相当する。

請求項に記載の要求元の周辺に存在する取得済み装置には、ステップＳ２０４で抽出される近時配信可能装置も含まれうる。もちろん、ステップＳ２０２で抽出される即時配信可能装置も、請求項に記載の要求元の周辺に存在する取得済み装置に該当する。便宜上以降では、即時配信可能装置と、近時配信可能装置とを互いに区別しない場合には、周辺取得済み装置と記載する。

ステップＳ２０６では通知部Ｇ４が、要求元装置に対して狭域取得可能通知を送信して本フローを終了する。ただし、このステップＳ２０６で送信する狭域取得可能通知には、狭域通信によるデータ取得が可能となるまでの残り時間を示す情報（以降、狭域要求待機時間）が含まれていることが好ましい。現時点では狭域通信では取得対象データを取得できないことを要求元装置に認識させるためである。

本実施形態では上記の事情を鑑みて、ステップＳ２０３やステップＳ２０６において通知部Ｇ４が送信する狭域取得可能通知には、図１１に示すように、広域通信における宛先情報や狭域通信で取得可能であることを示すビット列に加えて、狭域要求待機時間が含まれているものとする。宛先情報は複数の車載装置１のうちの何れの車載装置１を対象とする通信パケットであるかを示す情報である。もちろん、狭域取得可能通知には、宛先情報の他に、送信元を示す情報等を含んでいてもよい。狭域通信で取得可能であることを示すビット列は、狭域通信可能であることを示す特定のビットパターンである。換言すれば、要求元装置が、受信した通信パケットが狭域取得可能通知であることを認識するためのビット列である。

要求待機時間は、近時配信可能装置と要求元装置との距離が狭域通信可能距離Ｒｎ以内となるまでの残り時間（以降、接続所要時間）とすればよい。近時配信可能装置が複数存在する場合には、近時配信可能装置毎の接続所要時間のうち、最も小さい値とすればよい。或る近似配信可能装置についての接続所要時間は前述の通り、各車載装置１の現在位置、進行方向、及び移動速度から算出することができる。

要求元装置は、狭域取得可能通知を取得した場合、狭域取得可能通知を受信した時点を起算時点として、当該狭域取得可能通知に示されている要求待機時間が経過したタイミングで狭域要求パケットを送信するものとする。例えば要求元装置は要求待機時間として５秒が設定されている狭域取得可能通知を受信した場合、当該狭域取得可能通知を受信した時点から５秒後に狭域要求パケットを同報送信する。

なお、即時配信可能装置が存在する場合に送信する狭域取得可能通知、すなわちステップＳ２０３で送信される狭域取得可能通知が示す狭域要求待機時間は、０秒に設定されればよい。そのような設定によれば、要求待機時間として０秒が設定されている狭域取得可能通知を受信した要求元装置は、当該狭域取得可能通知を受信次第、速やかに狭域要求パケットを同報送信することとなる。このように狭域取得可能通知に要求待機時間を含めることで要求元装置に狭域要求パケットを同報送信させるタイミングを制御することができる。

ステップＳ２０７では配信部Ｇ５が、要求データを送信して本フローを終了する。つまり、本実施形態のサーバ２は、周辺取得済み装置が存在しなかった場合に広域通信によるデータ配信を実施する。本実施形態のサーバ２が、周辺取得済み装置が存在しないと判定する場合とは、前述の通り、要求元装置が狭域通信可能な範囲内に要求データを取得済みの車載装置１（つまり即時配信可能装置）が存在せず、かつ、要求元装置とこれから狭域通信可能となる可能性がある取得済み装置（つまり近時配信可能装置）も存在しなかった場合である。

なお、他の態様として、即時配信可能装置が存在しなかった時点で、周辺取得済み装置が存在しないと判定し、広域通信によるデータ配信を実施しても良い。そのような態様は、要求元装置が狭域通信可能な範囲のみを、要求元装置の周辺と見なす態様に相当する。

ところで装置情報管理部Ｇ１は、ステップＳ２０７での広域通信でのデータ配信を実施した場合には、管理ＤＢ２２に登録されている当該要求元装置のデータ取得状況を、未取得から取得済みに変更する。つまり配信部Ｇ５の動作結果に基づいて要求元装置のデータ取得状況を更新する。また、装置情報管理部Ｇ１は、要求元装置から取得成功通知を受信した場合にも、管理ＤＢ２２に登録されている当該要求元装置のデータ取得状況を、未取得から取得済みに変更する。

また、装置情報管理部Ｇ１は、要求元装置から取得失敗通知を受信した場合には、管理ＤＢ２２に登録されている当該要求元装置のデータ取得状況を、未取得のままとする。

＜狭域要求応答処理＞
次に、車載装置１が実施する狭域要求応答処理について図１２を用いて説明する。狭域要求応答処理は、車載装置１から狭域通信によって送信されてきた配信要求に対して応答する処理である。狭域要求応答処理は、狭域通信部１２が受信した狭域要求パケットに基づいて、狭域要求受付部Ｎ２が他の車載装置１からの配信要求を受け付ける度に逐次実行されれば良い。狭域要求受付部Ｎ２は、狭域通信パケットの受信に基づいて他の車載装置１からのデータの配信要求を受け付ける構成である。狭域要求受付部Ｎ２は、狭域要求パケットが備える取得対象情報を参照することで、要求元装置が要求しているデータ（以降、要求データ）を特定する。

まずステップＳ３０１では取得状況管理部Ｆ３が、狭域要求受付部Ｎ２が特定した要求データを自装置が保有しているかを判定する。要求データを保有している状態とは、要求データを取得済みであって且つ未だ削除していない状態である。換言すれば、要求データを保有していない状態とは、要求データは未取得又は削除済みの状態である。要求データを自装置が保有している場合にはステップＳ３０２を実行する。一方、要求データを自装置が保有していない場合には本フローを終了する。なお、要求データを自装置が保有していない場合には、自装置は要求データを保有していない旨を示す通信パケットを狭域通信で返送してもよい。

ステップＳ３０２では配信処理部Ｎ３が狭域通信部１２と協働して、要求データをブロードキャスト又は要求元装置に対してユニキャストして本フローを終了する。

＜実施形態のまとめ＞
以上の構成によれば、サーバ２は、要求元装置の周辺に要求データを取得済みの他装置（つまり取得済み装置）が存在する場合には、狭域通信で取得対象データを取得可能であることを通知し、その時点では広域通信による要求データの配信を実施しない。一方、サーバ２は、要求元装置の周辺に取得済みの車載装置１が存在しない場合にのみ、広域通信によるデータ配信を実施する。そのため、車載装置１が広域通信で取得対象データを取得する可能性は抑制され、通信料等を抑制することができる。

以上、本開示の実施形態を説明したが、本開示は上述の実施形態に限定されるものではなく、以降で述べる種々の変形例も本開示の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。

なお、前述の実施形態で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略する。また、構成の一部のみに言及している場合、他の部分については先に説明した実施形態の構成を適用することができる。

［変形例１］
上述した実施形態では、狭域取得可能通知として、サーバ２は何れの他装置から要求データを狭域通信で取得すべきかを指定せずに、単に狭域通信で取得可能（予定を含む）であることのみを通知する。そのため、要求元装置は狭域要求パケットを同報送信することによって周囲に車載装置１に対して取得対象データの送信を要求する。このような態様では、即時配信可能装置が複数存在する場合、同報送信された狭域要求パケットに対して複数の車載装置１が、応答として同一のデータを送信するため、狭域通信用の電波が混雑し、他のシステムに影響を与えることが懸念される。

そこで、他の態様としてサーバ２は、狭域取得可能通知において、何れの車載装置１から取得するべきかを指定しても良い。その場合には、狭域取得可能通知には、宛先情報等に加えて、サーバ２が指定した車載装置１（以降、指定装置）を要求元装置が特定するための指定装置情報が含まれるものとする。指定装置情報は、指定装置の装置ＩＤなどとすればよい。また、上記の狭域取得可能通知を受信した要求元装置は、当該狭域取得可能通知に示されている指定装置とユニキャストな狭域通信を実施することによって、データの要求及び取得が実現される。このような態様によれば、同報送信された狭域要求パケットに対して複数の車載装置１が同一のデータを送信することで狭域通信用の電波が混雑する恐れを低減できる。

［変形例２］
車載装置１が狭域通信によって取得対象データを取得する方法は、上述した方法に限らない。サーバ２は、管理ＤＢ２２での検索処理に基づいて、取得済み装置が存在することを確認できた場合には、要求元装置に対しては所定時間待機するように指示するとともに、周辺取得済み装置としての特定の車載装置１に対しては要求元装置に対して要求データを狭域通信で送信するように指示してもよい。

図１３は上記の思想に基づく配信要求応答処理の流れ（換言すればサーバ制御部２３の作動）を示すフローチャートである。図１３に示す配信要求応答処理は、配信要求パケットを受信する度に実行されれば良い。なお、図９のフローチャートを用いて説明済みの部分については省略又は簡略化して説明する。

まずステップＳ４０１では配信装置探索部Ｇ３が、周辺取得済み装置が存在するか否かを判定する。周辺取得済み装置が存在する場合にはステップＳ４０２を実行する。一方、周辺取得済み装置が存在しない場合にはステップＳ４０５を実行する。

ステップＳ４０２では通知部Ｇ４が、所定時間、狭域通信で要求データを受信することを待機するように指示する狭域取得可能通知を要求元装置に対して返送してステップＳ４０３を実行する。狭域通信で要求データを受信することを待機するように指示する、狭域取得可能通知としての通信パケットが、請求項に記載の狭域受信待機指示に相当する。

このステップＳ４０２で送信される狭域取得可能通知で指示する待機時間は、次のステップで定まる代理配信装置と要求元装置と狭域通信可能となるまでの残り時間に所定の余裕を与えた時間とすればよい。なお、要求元装置は、当該狭域取得可能通知を受信した場合、狭域取得可能通知で指示される待機時間、他の車載装置１から取得対象データが配信されてくるのを待機する。待機時間経過しても取得対象データを受信できなかった場合にはサーバ２に対して取得失敗通知を送信すればよい。

ステップＳ４０３では配信装置探索部Ｇ３が、周辺取得済み装置の中から要求元装置に対してデータを配信する役割を担う装置（つまり代理配信装置）を決定する。周辺取得済み装置が１つしか存在しない場合には、当該装置を代理配信装置に決定すれば良い。周辺取得済み装置が複数存在する場合には、所定の規則で代理配信装置を選定する。例えば代理配信装置は、要求元装置から最も近い取得済み装置としてもよいし、要求元装置との狭域通信可能な時間が最も長くなる取得済み装置としてもよい。狭域通信可能な時間が最も長くなる装置とは、例えば要求元装置と同一方向に移動している他装置や、相対速度が小さい装置である。狭域通信可能な時間とは、要求元装置の狭域通信可能なエリア内に滞在する時間に相当する。狭域通信可能な時間は、各車載装置１の現在位置、進行方向、及び移動速度から算出することができる。ステップＳ４０３での処理が完了するとステップＳ４０４を実行する。

ところで、代理配信装置からのデータ取得の成否は、代理配信装置の進路変更や狭域通信範囲からの離脱等の影響を受ける。換言すれば、代理配信装置からのデータ取得は、代理配信装置の挙動に起因して失敗しうる。具体的には、このような問題は、要求データの取得期限が短い場合や、代理配信装置が高速で移動している場合に顕著となる。そのような課題に対し、上記のように代理配信装置として要求元装置から最も近い取得済み装置を採用する構成によれば、代理配信装置の進路変更や狭域通信範囲からの離脱等の影響を受けにくくする事ができる。つまり、代理配信装置の移動による影響等を受けにくくなり、狭域通信での間接的なデータ配信が成功する可能性を高めることができる。

また、上記のように代理配信装置として要求元装置から最も近い取得済み装置を採用する構成によれば、仮に近時配信可能装置が代理配信装置として選定されている場合であっても、代理配信装置と要求元装置とが狭域通信可能となる時刻が、取得期限に対応する時刻を過ぎてしまう可能性を抑制することができる。

また、要求元装置との狭域通信可能な時間が最も長い取得済み装置を代理配信装置として採用する構成によれば、要求データの相対的にデータサイズが大きい場合であっても、データの通信の途中で、代理配信装置が自装置の狭域通信範囲からの離脱すること等に起因してデータの取得が失敗する恐れを低減することができる。相対的に大きなサイズのデータを狭域通信で取得する場合には相対的に通信時間が長くなるため、代理配信装置から当該データを取得しきれない可能性があるが、上記の構成によればそのような可能性を低減することができる。

ステップＳ４０４では通知部Ｇ４が、ステップＳ４０３で決定した代理配信装置に対して、要求データを狭域通信で送信するように指示する通信パケット（以降、狭域配信指示）を送信して本フローを終了する。このステップＳ４０４で代理配信装置に対して送信する狭域配信指示、及び、ステップＳ４０２で要求元装置に対して送信する狭域取得可能通知のそれぞれが、請求項に記載の狭域通信によって要求元に代理配信装置から共通使用データを取得させるための通信パケットに相当する。

狭域配信指示としての通信パケットは、配信要求パケットと同様に、取得対象情報を示すデータ領域を備えている。また、狭域配信指示としての通信パケットは、代理配信装置が必ずしも即時配信可能装置とは限らないことを考慮して、狭域配信指示は、送信待機時間を示すデータ領域を備えていることが好ましい。送信待機時間は、前述の接続所要時間に相当する値とすればよい。代理配信装置が即時配信可能装置である場合には、送信待機時間は０秒に設定されれば良い。なお、サーバ２は、代理配信装置と要求元装置とが狭域通信可能な位置関係となったことを確認してから狭域配信指示を送信してもよい。その場合には狭域配信指示において送信待機時間を示すデータ領域は不要となる。

上記の構成によれば、サーバ２がより積極的に車載装置１間のデータの送受信を制御するため、要求元装置が取得対象データを狭域通信で取得できる可能性を高めることができる。

［変形例３］
以上ではサーバ２は、要求元装置の周辺に取得済み装置が存在しなかった場合にはデータ配信を実行するものとしたが、これに限らない。要求元装置の周辺に取得済み装置が存在しなかった場合には、要求元装置の現在位置から所定距離（例えば狭域通信可能距離Ｒｎ）以内に存在する車載装置１の中で、広域通信の効率が最もよいエリア（以降、高効率エリア）に存在する車載装置１を特定する。そして、当該車載装置１に要求データを配信することによって、直接的又は間接的に要求元装置にデータを配信しても良い。

具体的には、高効率エリアに存在する車載装置１が要求元装置以外の装置である場合には、いったん当該車載装置１に対して広域通信でデータを配信する。そして、広域通信で配信した車載装置１から狭域通信によって要求元装置に転送させる。広域通信で配信した車載装置１から要求元装置への転送プロセスは、上述した種々の方法（例えば変形例２の方法）を採用することができる。なお、高効率エリアに存在する車載装置１が要求元装置である場合には、要求元装置にデータを配信すればよい。

図１４はこの変形例３におけるサーバ２の作動を説明するための図である。図１４のＡ１で示すエリアは広域通信の効率が低レベルとなっているエリアを表しており、Ａ２で示すエリアは、広域通信の効率が中レベルとなっているエリアを表している。Ａ３で示すエリアは、広域通信の効率が高レベルとなっているエリアを表している。このような通信状況において、車両Ｍａに搭載されている車載装置１ａが要求元装置である場合には、車両Ｍｃに搭載されている車載装置１ｃにデータを配信したのちに狭域通信によって転送させる。

なお、広域通信の効率が低いエリアとは広域通信のリソースが混雑しているエリアである。Ｗｉ−Ｆｉを利用可能なエリアは相対的に通信効率が高いエリアとなる。地点毎の広域通信の効率の良し悪しは、広域通信を提供する電気通信事業者から取得すれば良い。また、各車載装置１との通信状況（例えばＳ／Ｎ比やビットエラー率、通信遅延時間等）から特定することもできる。

［変形例４］
上述した実施形態等では、サーバ２が車載装置１からの配信要求に対して更新プログラムを配信する構成について言及したが、サーバ２は別途、車載装置１からの要求を受け付ける前に（つまり事前に）所定のタイミングで、所定の車載装置１に対して更新プログラムを配信しても良い。

例えばサーバ２は所定の周期で、特定の大型駐車場に停留している複数の車載装置１の幾つかに更新プログラムを配信しても良い。その際、更新プログラムを事前配信する車載装置１は、少なくとも互いに狭域通信可能距離の２倍以上離れている装置とする。サーバ２は、重複なく漏れなく狭域通信による更新プログラムの共有が実行可能なように、事前配信する車載装置１を選定することが好ましい。

［変形例５］
以上ではサーバ２は、複数の車載装置１からの個々の配信要求に対して個別に応答する態様を開示したが、これに限らない。サーバ２は、車載装置１からの配信要求を逐次受け付けるとともに、逐次受け付けた配信要求を所定の周期（以降、応答周期）でまとめて応答するものであってもよい。換言すれば、サーバ２は、車載装置１からの配信要求を所定の応答タイミングが到来するまで蓄積し、応答タイミングとなった場合に蓄積されている複数の配信要求に対してまとめて対応するように構成されていても良い。応答タイミングは応答周期で到来するものである。応答周期は、要求データの種類に応じて適宜設計されればよく、例えばソフトウェアの更新プログラムの配信要求に対する応答周期は１分〜１時間程度の値に設定することができる。

例えば、配信要求受付部Ｇ２は車載装置１からの配信要求を、所定の記憶媒体に蓄積していく。ここで蓄積される配信要求には、要求データや要求元装置の装置ＩＤ等が含まれる。配信装置探索部Ｇ３は、所定の周期で蓄積されている配信要求を取り出し、管理ＤＢ２２に保存されている車載装置１毎の位置情報や、移動速度、進行方向に基づいて、蓄積されている複数の配信要求の送信元に、最も効率的に（具体的には少ない回数で）共通使用データを狭域通信で配信可能な位置に存在する少なくとも１つの取得済み装置を代理配信装置に選定する。そして、当該代理配信装置に対して狭域配信指示を送信する。

このような構成によれば、効率よく要求データを狭域通信で配信させることが可能となる。もちろん、この変形例５の構成は、上記の変形例４の構成と組み合わせて実施されてもよい。例えば、或るエリアに合計１０台の要求元装置が存在する場合に、取得済み装置が一台も存在しない場合には、より多くの要求元装置と狭域通信可能な位置に存在する車載装置１に対して広域通信で要求データを配信し、狭域通信で同報配信させてもよい。例えば、３台の要求元装置としか狭域通信できない位置に存在する車載装置１と、９台の要求元装置としか狭域通信できない車載装置１とが存在する場合には、後者に対して広域通信で要求データを配信し、代理配信装置として機能させる。

［変形例６］
取得対象データ（別の観点によれば要求データ）として送受信される、ソフトウェアの更新プログラムは、図１５に示すように、複数のフラグメントに分割されて取り扱われてもよい。図１５は、ソフトウェアの更新プログラムＤｔを、第１フラグメントＤｆ１〜第５フラグメントＤｆ５までの、５つのフラグメントに分割した態様を例示している。

このような構成によれば、図１６に示すように、フラグメント単位でデータの送受信可能となる。なお、図１６では、５つの車載装置１ａ〜１ｅに対して１つずつそれぞれ異なるフラグメントを広域通信によって配信している態様を示している。

また、各車載装置１は、自装置が備えていないフラグメントを取得対象データに設定する。そのため、上述のデータ取得処理の結果として、各車載装置１は自装置が持っていないフラグメントを狭域通信によって他装置から取得することができる。例えば、車載装置１ａは、第２フラグメントＤｆ２〜第５フラグメントＤｆ５を車載装置１ｂ〜１ｅのそれぞれから狭域通信によって取得することで元データとしての更新プログラムを取得することできる。

なお、車載装置１ａ〜１ｅが何れも狭域通信可能な位置関係となっている状況において、例えば車載装置１ｂが第２フラグメントＤｆ２を同報送信した場合、車載装置１ａだけでなく、車載装置１ｃ〜１ｅもまた、第２フラグメントＤｆ２を取得することができる。各車載装置１は、個々のフラグメントを狭域通信で共有することによって、元データしての更新プログラムを再構築して利用可能である。

このようにデータをフラグメントに分割して送受信する構成によれば、各車載装置１における通信料をより一層抑制することができる。また、送受信されるデータサイズが小さくなるため、１個のデータの送受信に要する時間が短縮される。その結果、対向車両とのすれ違いざまといった相対的に短い時間でもデータの送受信が成功する可能性を高めることができる。別の観点によれば、車載装置１の移動によって、データを送受信している途中で狭域通信が中断する（つまりデータの送受信が失敗する）恐れを低減することができる。

また、すれ違いざまでのフラグメントの取得を積み重ねれば、最終的には全てのフラグメントを収集し、更新プログラムを利用できるようになる。つまり、更新プログラムをフラグメント化することにより、各車載装置１が更新プログラムを取得しやすくなる。その結果、更新プログラムの適用も促進される。なお、図１６に示す車載装置１ｆは車載装置１ａ〜１ｅが搭載されている車両とは反対車線を走行する車両に搭載されている車載装置１である。車載装置１は、各車載装置１から順次フラグメントを狭域通信で取得することで、最終的に全てのフラグメントを揃えることができる。なお、図１６における実線矢印は、広域通信によるデータの移動方向を表しており、一点鎖線の矢印は、狭域通信によるデータの移動方向を表している。

個々のフラグメントは、最終的には他のフラグメントと組み合わされて、複数の車載装置１で使用される。故に、個々のフラグメントもまた請求項に記載の共通使用データに該当する。また、各フラグメントは前述の実施形態における取得対象データと同様に取り扱うことが可能である。故に、取得期限までに取得できなかったフラグメントはサーバ２から送信されて、最終的には全て揃うこととなる。また、そのような場合にであってもサーバ２から送信されるデータは、元データを構成する一部のフラグメントとなりうるため、元データを全てサーバ２から広域通信で取得する場合に比べて通信料（換言すれば広域通信での通信量）を抑制することができる。

さらに、図１７に示すように、車載装置１ａ、１ｂ、１ｃが互いに狭域通信可能な位置関係となっている状況において、車載装置１ａが第１フラグメントＤｆ１と第２フラグメントＤｆ２を要求しており、かつ、車載装置１ｂが第２フラグメントＤｆ２と第５フラグメントＤｆ５を要求している場合、車載装置１ｃは、各車載装置１ａ、１ｂが要求しているフラグメントの論理和（いわゆるＯＲ）をとったフラグメントを同報送信する。すなわち、第１フラグメントＤｆ１、第２フラグメントＤｆ２、及び第５フラグメントＤｆ５を順次同報送信する。要求されたフラグメントのみ送信することで、要求元装置は要求データを取得しつつ、狭域通信の通信量低減（狭域通信の混雑を低減）できる。

なお、変形例６における装置情報管理部Ｇ１は、車載装置１毎のデータ取得状況として、複数のフラグメントのそれぞれの取得状況を管理する。つまり、データ取得状況は、フラグメント単位で個別に管理する。また、サーバ２は車載装置１からの配信要求も、フラグメント単位で受け付ける。車載装置１は、２回目以降のデータ配信要求は、未取得のフラグメントのみを取得対象データに設定して実施すればよい。フラグメント単位での配信制御を行う場合には、車載装置１が要求しているフラグメント（つまり未取得フラグメント）を取得済みの車載装置が取得済み装置（特にフラグメント取得済み装置）に該当する。

［変形例７］
制御部１３は、図１８に示すように、正規性判定部Ｆ５を備えていても良い。正規性判定部Ｆ５は、狭域回線取得部Ｎ１が取得した更新プログラムの正規性を判定する構成である。なお、図１８では広域通信処理部Ｗｎや狭域通信処理部Ｎｎは省略している。

正規性判定部Ｆ５は、狭域回線取得部Ｎ１が同一種類のソフトウェアに対する更新プログラム（フラグメントを含む）を複数回受信した場合には、それら複数の受信データを比較することで、受信した更新プログラムの正規性を判定する。例えばそれぞれ異なる３つの車載装置１から同一種類のソフトウェアに対する更新プログラムを受信した場合には、それらが一致しているか否かを比較によって判定する。つまり、複数のデータの整合性（換言すれば同一性）を判定する。

そして、受信データが何れも同一の内容であることを確認できた場合には当該更新プログラムは正規の更新プログラムであると判定する。一方、複数の受信データの中に他のデータと内容が異なるデータが混ざっている場合には、不正な更新プログラムを受信した恐れがあると判定する。なお、複数の受信データの中に他のデータと内容が異なるデータが混ざっている場合であっても、多数決により正規なデータを決定してもよい。

プログラム適用部Ｆ４は、狭域通信で取得した更新プログラムについては正規性を確認できてから適用するものとする一方、不正なデータである恐れがある更新プログラムの適用は保留にする。つまり狭域回線取得部Ｎ１が取得した更新プログラムについては正規性判定部Ｆ５によって正規のデータであると判定されるまで使用しない。このような構成によれば、情報セキュリティの観点において安全性を高めることができる。

なお、車載装置１は、不正なデータである恐れがある更新プログラムを配信してきた車載装置１についての情報（例えば装置ＩＤ）を、サーバ２に報告するなどの処置を実施してもよい。そのような態様によればサーバ２は車載装置１からの報告に基づいて不審な挙動をしている車載装置１を特定することができる。また、不審な車載装置１を検出した場合には、当該車載装置１から配信されるデータは使用しないように、他の車載装置１に事前に通知するなどの処置を講ずることができる。

［変形例８］
変形例７では正規性判定部Ｆ５が複数の受信データを比較することによって受信データの正規性を判定する構成を記載したが、これに限らない。正規性判定部Ｆ５は受信データのハッシュ情報をサーバ２に問い合わせることで、サーバ２側で車載装置１が受信したデータが正規の（換言すれば正常な）データであるか否かを判定してもよい。ここでのハッシュ情報とは、元となるデータを所定のハッシュ関数に入力して定まる値（いわゆるハッシュ値）である。

その場合、サーバ２は、問い合わせられたデータが正規のデータであるか否かの回答を返送するものとする。このような態様によっても、正規性判定部Ｆ５は、狭域回線取得部Ｎ１が取得した更新プログラムが正規のものであるか否かを判定することができる。

また、正規性判定部Ｆ５は、サーバ２から事前に取得対象データのハッシュ情報を取得しておき、狭域通信で当該データを取得した場合に、サーバ２から取得したハッシュ情報と、受信データを用いて生成したハッシュ情報とを比較して正常性を判定してもよい。このような構成によっても上述した変形例７と同様の効果を奏する。さらに、同一種類のデータを複数回受信しなくてもデータの正常性を判定できるといった効果も奏する。

［変形例９］
車載装置１は、サーバ２から広域通信で取得対象データを取得した場合、自発的に所定回数、所定の周期で当該受信データを狭域通信でブロードキャストするようにされていても良い。

また、車載装置１は、データの取得に関する要求として、取得期限以外の条件をサーバ２に要求しても良い。例えば、広域通信によるデータ配信を禁止してもよい。また、広域通信による配信と、狭域通信による配信との優先順位を通知しても良い。サーバ２は車載装置１からの要望に応じて作動すればよい。

［変形例１０］
上述した実施形態におけるサーバ２は、配信装置探索部Ｇ３によって要求元装置の周辺に取得済み装置が存在すると判定されたことに基づいて、要求元装置に対して狭域取得可能通知を送信するものとしたが、これに限らない。配信装置探索部Ｇ３によって要求元装置の周辺に取得済み装置が存在すると判定された場合、要求元装置には何も指示せずに、周辺取得済み装置に対して、狭域通信で要求データを送信するように指示しても良い。

そのような構成においては、通知部Ｇ４が、周辺取得済み装置に対して、要求データを狭域通信で送信するように指示する通信パケット（つまり狭域配信指示）を送信すればよい。狭域配信指示を取得した車載装置１は、サーバ２から指示されたデータを狭域通信によって送信する。

［変形例１１］
移動体通信システム１００は、サーバ２に対してデータの配信を要求する装置として、狭域通信機能を備えない狭域通信非対応装置を含んでいてもよい。そのように車載装置１と狭域通信非対応装置とが混在している場合、サーバ２に送信される配信要求パケットには、要求元装置が狭域通信機能を備えているか否かを示すデータ領域が設けられているものとする。なお、狭域通信機能を備えているか否かは２値であるため１ビットで表現することができる。

また、サーバ２は、配信要求応答処理において、要求元装置が狭域通信機能を備えているか否かによって、配信要求応答処理の内容を変更する。要求元装置が狭域通信機能を備えている場合には上述した実施形態等と同様の配信要求応答処理を実行する。一方、要求元装置が狭域通信機能を備えていない場合には広域通信によるデータ配信を実行する。なお、装置情報管理部Ｇ１が管理する個別状況データには、車載装置１が狭域通信機能を備えているか否かを示すデータが含まれているものとする。

［変形例１２］
上述した実施形態では、サーバ２は、ソフトウェアの更新プログラムを配信するものとしたが、これに限らない。サーバ２は、ドライバの運転操作の手助けとなるリアルタイムな情報（以降、運転支援情報）を配信するものであってもよい。つまりサーバ２が配信するデータは、運転支援用のデータであってもよい。

運転支援用のデータとは、例えば事故地点映像データや、交差点等において自車両にとって死角となる領域の映像データである。また、運転支援用データは、例えば通行規制や渋滞、道路上の落下物などとった道路状況を示すデータとすることもできる。これらのデータもまた、複数の車載装置１で使用されるデータとなりうる。

また、サーバ２は複数種類のデータを配信するように構成されていても良い。その場合、車載装置１もまた、サーバ２が配信可能な複数種類のデータを適宜要求する。取得対象とするデータの取得期限は、サーバ２に配信要求するデータの種別によって決定されればよい。例えばソフトウェアの更新プログラムの取得期限は、リアルタイム性が要求される運転支援用のデータに比べて相対的に長い時間に設定される。ただし、ソフトウェアの更新プログラムの中でも、不具合（特にセキュリティの脆弱性等に関する不具合）を修正するためのプログラムは、速やかな取得及び適用が要求されるため、相対的に短い時間に設定されることが好ましい。機能の拡充のための更新プログラムの取得期限は相対的に長い時間に設定されても良い。

なお、事故地点映像データ等といった地点情報と結びついたリアルタイム性を有する情報は、特定の地域、特定の時間帯においてのみ有用な情報といえる。故に、変形例８で言及したように車載装置１がサーバ２から取得したデータを自発的に同報送信する構成においては、サーバ２は、当該データを同報送信する地域や時間帯が限定的となるように、車載装置１が受信データを同報送信する条件を指定することが好ましい。例えば、サーバ２が配信する運転支援用のデータには、有効期限と、有効地域が設定されていても良い。有効期限と、有効地域が設定されたデータを受信した車載装置１は、有効期限内であって、且つ有効地域内に存在する場合にのみ、当該受信データを同報送信する。そのような構成によれば、当該データを必要としないエリアにおいて同報送信するおそれを低減できる。

［変形例１３］
請求項に記載のユーザ側装置は、スマートフォンやタブレット端末等の携帯型の通信端末であってもよい。さらに、ユーザ側装置は、工作機器や、重機、飲料缶等の自動販売機などに備えられていても良い。

１００ 移動体通信システム、１・１ａ〜１ｅ 車載装置、２ サーバ、１１ 広域通信部、１２ 狭域通信部、１３ 制御部、２１ サーバ側通信部、２２ 管理データベース、２３ サーバ制御部、Ｆ１ 機能提供部、Ｆ２ 取得対象検出部、Ｆ３ 取得状況管理部、Ｆ４ プログラム適用部、Ｗ１ 報告部、Ｗ２ サーバ要求部、Ｗ３ サーバ応答取得部、Ｎ１ 狭域回線取得部、Ｎ２ 狭域要求受付部、Ｎ３ 配信処理部、Ｇ１ 装置情報管理部、Ｇ２ 配信要求受付部、Ｇ３ 配信装置探索部（周辺装置探索部）、Ｇ４ 通知部、Ｇ５ 配信部、Ｇ６ 期限管理部

Claims (12)

1. 移動体で使用される複数のユーザ側装置（１）と、複数の前記ユーザ側装置で共通して使用されるデータである共通使用データを、前記ユーザ側装置からの要求に基づき、要求元としての前記ユーザ側装置に配信するサーバ（２）と、を備える移動体通信システムであって、
   前記サーバと複数の前記ユーザ側装置のそれぞれとは、広域通信網を介して相互通信可能に構成されており、
   複数の前記ユーザ側装置のそれぞれは、
   現在位置を示す位置情報を示す通信パケットである位置報告パケットを逐次前記サーバに送信する報告部（Ｗ１）と、
   他の前記ユーザ側装置である他装置と、前記広域通信網を介さない直接的な無線通信である狭域通信を実施するための通信モジュールである狭域通信部（１２）と、を備え、
   前記サーバは、
   所定の書き換え可能な記憶媒体を用いて実現されているデータベースであって、前記ユーザ側装置毎の前記共通使用データの取得状況と位置情報とを示すデータが保存されている管理データベース（２２）と、
   複数の前記ユーザ側装置のそれぞれから送信されてくる前記位置報告パケットに基づき、前記管理データベースに保存されている複数の前記ユーザ側装置のそれぞれの位置情報を更新する装置情報管理部（Ｇ１）と、
   前記ユーザ側装置からの前記共通使用データの配信要求を受け付けた場合に、前記管理データベースを参照し、当該要求元の周辺に、前記共通使用データを取得済みの前記ユーザ側装置である取得済み装置が存在するか否かを判定する周辺装置探索部（Ｇ３）と、
   前記周辺装置探索部によって前記要求元の周辺に前記取得済み装置が存在すると判定されたことに基づいて、前記要求元に対して前記狭域通信によって前記共通使用データが取得可能であることを通知する通知部（Ｇ４）と、
   前記周辺装置探索部によって前記要求元の周辺に前記取得済み装置が存在しないと判定されたことに基づいて前記共通使用データを配信する配信部（Ｇ５）と、を備え、
   前記要求元としての前記ユーザ側装置は、
   前記配信要求に対する前記サーバからの応答として、前記狭域通信によって前記共通使用データを取得可能であることが通知された場合、前記狭域通信によって前記要求元の周辺に存在する前記取得済み装置から前記共通使用データを取得するための処理を実施する狭域回線取得部（Ｎ１）を備える移動体通信システム。
2. 請求項１に記載の移動体通信システムであって、
   前記報告部は、前記狭域回線取得部が前記共通使用データを取得できた場合には、前記共通使用データを取得できたことを示す通信パケットである取得成功通知を前記サーバに対して送信し、
   前記装置情報管理部は、前記ユーザ側装置から送信されてくる前記取得成功通知、及び前記配信部の動作結果に基づいて、前記管理データベースに登録されている前記ユーザ側装置毎の前記共通使用データの取得状況を更新するものであって、
   前記周辺装置探索部は、前記管理データベースに登録されている前記ユーザ側装置毎の現在位置と前記共通使用データの取得状況に基づいて、前記取得済み装置の中から、前記要求元としての前記ユーザ側装置に対して、前記狭域通信で前記共通使用データを送信する前記取得済み装置である代理配信装置を選定し、
   前記通知部は、前記周辺装置探索部が選定した前記代理配信装置と前記要求元のそれぞれに対して、前記狭域通信によって前記要求元に前記代理配信装置から前記共通使用データを取得させるための通信パケットを送信する移動体通信システム。
3. 請求項２において
   前記通知部は、前記周辺装置探索部が選定した前記代理配信装置に対し、前記狭域通信で前記共通使用データを前記要求元に送信するように指示する通信パケットである狭域配信指示を送信するとともに、前記要求元に対しては、前記狭域通信で前記共通使用データが配信されてくることを所定時間待機するように指示する通信パケットである狭域受信待機指示を送信する移動体通信システム。
4. 請求項２又は３に記載の移動体通信システムであって、
   複数の前記ユーザ側装置のそれぞれが送信する前記位置報告パケットには、現在位置を示す位置情報に加えて、移動方向と移動速度を示す情報が含まれており、
   前記狭域通信部が通信可能な距離としての想定値が、狭域通信可能距離として予め設定されており、
   前記装置情報管理部は、複数の前記ユーザ側装置のそれぞれから送信されてくる前記位置報告パケットに基づいて、前記ユーザ側装置のそれぞれの位置情報、移動方向、及び移動速度を示すデータを前記管理データベースに保存するものであって、
   前記周辺装置探索部は、
   前記管理データベースに登録されている前記ユーザ側装置毎の位置情報に基づいて、前記要求元から前記狭域通信可能距離以内に存在する前記取得済み装置である即時配信可能装置が存在するか否かを判定するとともに、
   前記即時配信可能装置が存在しなかった場合には、前記管理データベースに登録されている前記ユーザ側装置毎の位置情報、移動方向、及び移動速度に基づいて、現在から所定時間以内に、前記要求元との距離が前記狭域通信可能距離以下となる前記取得済み装置である近時配信可能装置が存在するか否かを判定し、
   前記即時配信可能装置及び前記近時配信可能装置の少なくとも何れか一方が存在する場合には、前記要求元の周辺に前記取得済み装置が存在すると判定する移動体通信システム。
5. 請求項２又は３に記載の移動体通信システムであって、
   複数の前記ユーザ側装置のそれぞれが送信する前記位置報告パケットには、現在位置を示す位置情報に加えて、移動方向と移動速度を示す情報が含まれており、
   前記装置情報管理部は、複数の前記ユーザ側装置のそれぞれから送信されてくる前記位置報告パケットに基づいて、前記ユーザ側装置のそれぞれの位置情報、移動方向、及び移動速度を示すデータを前記管理データベースに保存するものであって、
   前記周辺装置探索部は、
   前記管理データベースに登録されている前記ユーザ側装置毎の前記共通使用データの取得状況に基づいて前記取得済み装置を抽出するとともに、
   前記管理データベースに登録されている前記取得済み装置毎の現在位置、移動方向、及び移動速度に基づいて、前記要求元と最も長い間、前記狭域通信を実施可能な前記取得済み装置を前記代理配信装置に決定する移動体通信システム。
6. 請求項５に記載の移動体通信システムであって、
   前記狭域通信部が通信可能な距離としての想定値が、狭域通信可能距離として予め設定されており、
   前記周辺装置探索部は、
   前記管理データベースに登録されている前記ユーザ側装置毎の位置情報に基づいて、前記要求元から前記狭域通信可能距離以内に存在する前記取得済み装置である即時配信可能装置が存在するか否かを判定するとともに、
   前記即時配信可能装置が存在しなかった場合には、前記管理データベースに登録されている前記ユーザ側装置毎の位置情報、移動方向、及び移動速度に基づいて、現在から所定時間以内に、前記要求元との距離が前記狭域通信可能距離以下となる前記取得済み装置である近時配信可能装置が存在するか否かを判定し、
   前記即時配信可能装置及び前記近時配信可能装置の少なくとも何れか一方が存在する場合には、前記要求元の周辺に前記取得済み装置が存在すると判定する移動体通信システム。
7. 請求項２又は３に記載の移動体通信システムであって、
   前記周辺装置探索部は、
   前記管理データベースに登録されている前記ユーザ側装置毎の前記共通使用データの取得状況に基づいて前記取得済み装置を抽出するとともに、
   前記管理データベースに登録されている前記取得済み装置毎の現在位置に基づいて、前記要求元から最も近い前記取得済み装置を前記代理配信装置に決定する移動体通信システム。
8. 請求項２又は３に記載の移動体通信システムであって、
   複数の前記ユーザ側装置のそれぞれが送信する前記位置報告パケットには、現在位置を示す位置情報に加えて、移動方向と移動速度を示す情報が含まれており、
   前記装置情報管理部は、複数の前記ユーザ側装置のそれぞれから送信されてくる前記位置報告パケットに基づいて、前記ユーザ側装置のそれぞれの位置情報、移動方向、及び移動速度を示すデータを前記管理データベースに保存し、
   前記サーバは、前記ユーザ側装置からの前記共通使用データの前記配信要求を逐次受け付けるとともに、逐次受け付けた前記配信要求に対して所定の周期でまとめて応答するものであって、
   前記周辺装置探索部は、１周期内において複数の前記配信要求を受け付けた場合には、前記管理データベースに登録されている前記ユーザ側装置毎の現在位置、移動方向、移動速度、及び前記共通使用データの取得状況に基づいて、前記取得済み装置の中から、複数の前記要求元のそれぞれに対して最も効率的に前記共通使用データを配信可能な位置に存在する前記取得済み装置を前記代理配信装置に設定する移動体通信システム。
9. 請求項２から８の何れか１項に記載の移動体通信システムであって、
   前記配信部は、前記周辺装置探索部によって前記要求元の周辺は前記取得済み装置が存在しないと判定された場合に、前記要求元の現在位置から所定距離以内に存在する前記ユーザ側装置の中で、広域通信の効率が最も良い前記ユーザ側装置に対して前記共通使用データを配信することによって、前記要求元に対して直接的又は前記狭域通信を用いた間接的に前記共通使用データを提供する移動体通信システム。
10. 請求項１から９の何れか１項に記載の移動体通信システムであって、
    前記サーバは、１つの前記共通使用データを複数のフラグメントに分割して配信し、
    前記ユーザ側装置は、前記共通使用データを構成する複数の前記フラグメントのうち、未取得の前記フラグメントである未取得フラグメントが存在する場合に、当該未取得フラグメントの配信を前記サーバに要求し、
    前記装置情報管理部は、前記ユーザ側装置毎の前記共通使用データの取得状況として、複数の前記フラグメントのそれぞれの取得状況を管理するものであって、
    前記周辺装置探索部は、
    前記ユーザ側装置から前記未取得フラグメントの配信の要求を受け付けた場合に、前記管理データベースを参照し、当該要求元の周辺に、前記未取得フラグメントを保持している前記ユーザ側装置であるフラグメント取得済み装置が存在するか否かを判定し、
    前記通知部は、前記周辺装置探索部によって前記要求元の周辺に前記フラグメント取得済み装置が存在すると判定された場合に、前記要求元に対して前記狭域通信によって前記未取得フラグメントは取得可能であることを通知し、
    前記配信部は、前記周辺装置探索部によって前記要求元の周辺に前記フラグメント取得済み装置は存在しないと判定されたことに基づいて前記未取得フラグメントを配信し、
    前記狭域回線取得部は、前記配信要求に対する前記サーバからの応答として、前記狭域通信によって前記未取得フラグメントを取得可能であることが通知された場合に、前記狭域通信によって前記要求元の周辺に存在する前記フラグメント取得済み装置から前記未取得フラグメントを取得するための処理を実施する移動体通信システム。
11. 請求項１から１０の何れか１項に記載の移動体通信システムであって、
    前記共通使用データは車両で使用されるソフトウェアの更新プログラムであって、
    前記ユーザ側装置は車両に搭載されている装置であることを特徴とする移動体通信システム。
12. 請求項１１に記載の移動体通信システムであって、
    前記更新プログラムを使用するプログラム適用部（Ｆ４）と、
    前記狭域回線取得部が取得した前記更新プログラムの正規性を判定する正規性判定部（Ｆ５）と、を備え、
    前記プログラム適用部は、前記狭域回線取得部が取得した前記更新プログラムについては前記正規性判定部によって正規のデータであると判定されるまで使用しない移動体通信システム。

Images