JP6569771B2 - 車両用のソフトウェア管理システム及び車両 - Google Patents

Description

本発明は、車両用のソフトウェア管理システム及び車両に関する。

従来より、ＤＣＭ（Data Communication Module）等の通信装置を有する車両と、該車両により該通信装置を介して接続され、該車両にインストールされているソフトウェアを更新可能な管理サーバと、を有する車両用のソフトウェア管理システムが知られている。

当該車両用のソフトウェア管理システムでは、管理サーバが最新のソフトウェア（車両にインストールされているソフトウェアについての最新バージョンのソフトウェア）を取得すると、該最新のソフトウェアへの更新が必要と判定し、該管理サーバが、該車両に対して最新のソフトウェアを送信する。これにより、当該車両用のソフトウェア管理システムによれば、該車両が、適宜最新のソフトウェアを取得できる。

特開２００９−１０２００３号公報

しかしながら、車両にインストールされているソフトウェアのうち、自動運転機能や運転支援機能等に関するソフトウェアについては、最新のソフトウェアへの更新に際して、車両のユーザによる許可が必要となる。このため、ユーザが許可操作を怠ると、自動運転機能や運転支援機能等に関するソフトウェアについては、古いバージョンのままユーザに利用され続けることになる。

このようなことから、車両用のソフトウェア管理システムにおいては、最新のソフトウェアへの更新に際して積極的に許可操作を行うユーザに対してインセンティブを与える構成とし、最新のソフトウェアへの早期更新を実現することが望ましい。

そこで、本開示は、車両にインストールされている自動運転機能または運転支援機能に関するソフトウェアを更新可能なソフトウェア管理システムにおいて、該ソフトウェアについて更新が必要となった場合に、早期更新を実現することを目的とする。

本開示の一局面によれば、車両用のソフトウェア管理システムは、以下のような構成を備える。即ち、
自動運転機能または運転支援機能を有する車両と、
前記車両にインストールされているソフトウェアを管理する管理サーバと、を有する車両用のソフトウェア管理システムであって、
前記車両にインストールされているソフトウェアであって、前記自動運転機能または前記運転支援機能に関するソフトウェアについて更新の要否を判定する更新要否判定手段と、
前記更新要否判定手段により更新が必要と判定され、ユーザにより更新が許可されなかった場合に、制限可能な状態に移行し、制限可能な状態に移行後の所定のタイミングで、前記自動運転機能または前記運転支援機能の一部または全部の作動について制限を開始し、前記更新要否判定手段により更新が必要と判定され、ユーザにより更新が許可されることで、前記自動運転機能または前記運転支援機能に関するソフトウェアを更新した場合に、該制限を解除する制限手段とを有する。

上記車両用のソフトウェア管理システムによれば、更新要否判定手段が、車両にインストールされているソフトウェアであって、自動運転機能または運転支援機能に関するソフトウェアについて更新の要否を判定する。また、上記車両用のソフトウェア管理システムによれば、更新要否判定手段により更新が必要と判定され、ユーザにより更新が許可された場合に、制限手段が、制限可能な状態に移行し、制限可能な状態に移行後の所定のタイミングで、自動運転機能または運転支援機能の一部または全部の作動について制限を開始し、更新要否判定手段により更新が必要と判定され、ユーザにより更新が許可されることで、自動運転機能または運転支援機能に関するソフトウェアを更新した場合に、制限手段が、制限を解除する。

これにより、自動運転機能または運転支援機能に関するソフトウェアの更新に際して、ユーザが許可操作を早期に行わなければ、当該車両では、自動運転機能または運転支援機能の一部または全部の作動が制限されることになる。換言すると、ユーザは、更新の許可操作を早期に行い、更新を完了させることで、当該車両において自動運転機能または運転支援機能の一部または全部の作動が制限されるといった事態を回避することができ（あるいは、作動が制限される時間を短くすることができ）、許可操作を積極的に行ったことによるインセンティブを得ることができる。

この結果、上記車両用のソフトウェア管理システムによれば、ユーザによる許可操作が早期に行われることとなり、自動運転機能または運転支援機能に関するソフトウェアについて更新が必要となった場合において、早期更新を実現できる。

本開示によれば、車両にインストールされている自動運転機能または運転支援機能に関するソフトウェアを更新可能なソフトウェア管理システムにおいて、該ソフトウェアについて更新が必要となった場合に、早期更新を実現できる。

車両用のソフトウェア管理システムの一例を示す図である。 管理サーバのハードウェア構成の一例を示す図である。 自動運転または運転支援システムの構成及び自動運転用または運転支援用ＥＣＵのハードウェア構成の一例を示す図である。 ソフトウェア情報及びユーザ情報の一例を示す図である。 運転支援ソフトウェア情報の一例を示す図である。 管理サーバのソフトウェア管理部及びユーザ管理部の機能構成の一例を示す図である。 運転支援用ＥＣＵのバージョン管理部の機能構成の一例を示す図である。 管理サーバにおける対象車両のＩＧ−ＯＮ状態管理処理及び対象携帯端末の接続状態管理処理の流れを示すフローチャートである。 管理サーバにおけるバージョン管理処理の流れを示すフローチャートである。 管理サーバにおけるバージョン管理処理の流れを示すフローチャートである。 車両における最新化処理の流れを示すフローチャートである。 車両における最新化処理の流れを示すフローチャートである。 携帯端末における更新許可処理の流れを示すフローチャートである。 管理サーバにおけるユーザ管理処理の流れを示すフローチャートである。 管理サーバにおけるバージョン管理処理の流れを示すフローチャートである。 管理サーバにおけるバージョン管理処理の流れを示すフローチャートである。 車両における最新化処理の流れを示すフローチャートである。 車両における最新化処理の流れを示すフローチャートである。 管理サーバにおけるバージョン管理処理の流れを示すフローチャートである。 管理サーバにおけるバージョン管理処理の流れを示すフローチャートである。 管理サーバにおけるソフトウェア送信処理の流れを示すフローチャートである。 車両における最新化準備処理の流れを示すフローチャートである。 車両における最新化準備処理の流れを示すフローチャートである。 車両における最新化処理の流れを示すフローチャートである。

以下、本発明の各実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。また、本明細書及び図面において用いる用語のうち、「自動運転機能」及び「運転支援機能」については、それぞれ以下に示すレベルを実現するための機能を指すものとする。
「自動運転機能」：
・車両の運転操作及び周辺監視を全て実行するレベル
・機能限界になった場合のみ、運転者が自ら運転操作を行うが、その以外の場合は、車両の運転操作及び周辺監視を全て実行するレベル
「運転支援機能」：
・運転者は安全運行の責任を持つが、操舵、制動、加速全ての運転支援を実行するレベル
・操舵、制動又は加速の運転支援を実行するが、操舵、制動、加速の全ての運転支援までは実行しないレベル
・運転者が車両の操舵・制動・加速のための運転操作を行うが、前方衝突警告などの、操舵、制動、加速以外の支援を実行するレベル
なお、ＡＣＣ（Adaptive Cruise Control）、ＬＫＡ（Lane Keeping Assist System）、ＩＰＡ（Intelligent Parking Assist）等の機能は、「運転支援機能」に含まれるものとする。

［第１の実施形態］
＜１．車両用のソフトウェア管理システムの全体構成＞
はじめに、車両用のソフトウェア管理システムの全体構成について説明する。図１は、車両用のソフトウェア管理システムの全体構成の一例を示す図である。図１に示すように、車両用のソフトウェア管理システム１００は、管理サーバ１１０と、車両１２０と、携帯端末１４０とを有する。本実施形態において、管理サーバ１１０と車両１２０とは、ネットワーク１５０を介して通信可能に接続される。また、管理サーバ１１０と携帯端末１４０とは、ネットワーク１５０を介して通信可能に接続される。

管理サーバ１１０には、ソフトウェア管理プログラム及びユーザ管理プログラムがインストールされており、これらのプログラムが実行されることで、管理サーバ１１０は、ソフトウェア管理部１１１及びユーザ管理部１１２として機能する。

ソフトウェア管理部１１１は、車両１２０に搭載された自動運転または運転支援システム１３２にインストールされている、自動運転機能または運転支援機能に関するソフトウェアを管理する。なお、自動運転機能または運転支援機能に関するソフトウェアは、最新バージョンのソフトウェアへの更新に際して、原則として、ユーザによる許可が必要なソフトウェアである。しかしながら、将来的には、ユーザによる許可が必要でなくなる可能性もある。そこで、以下では、自動運転機能または運転支援機能に関するソフトウェアを更新するための最新バージョンのソフトウェアには、ユーザによる許可が必要なソフトウェアと、ユーザによる許可が不要なソフトウェアとが含まれることを前提として説明を行う。

具体的には、ソフトウェア管理部１１１は、自動運転または運転支援システム１３２にインストールされているソフトウェアについて、最新バージョンのソフトウェアを新たに取得したか否かを監視する。ソフトウェア管理部１１１では、最新バージョンのソフトウェアを新たに取得すると、ソフトウェアＤＢ１１３に格納するとともに、該最新バージョンのソフトウェアによる更新が必要と判定し、該最新バージョンのソフトウェアを車両１２０に送信する。これにより、自動運転または運転支援システム１３２にインストールされているソフトウェアが更新される。

また、ソフトウェア管理部１１１は、自動運転または運転支援システム１３２にインストールされているソフトウェアの更新状況に応じて、自動運転機能または運転支援機能の一部または全部の作動を制限すべく、車両１２０に対して機能制限を指示する。

更に、ソフトウェア管理部１１１は、自動運転または運転支援システム１３２にインストールされているソフトウェアについての更新状況を、ユーザ情報ＤＢ１１４に格納する。

ユーザ管理部１１２は解析手段の一例であり、ユーザ情報ＤＢ１１４を参照し、自動運転または運転支援システム１３２にインストールされているソフトウェアの更新状況をユーザごとに解析する。

車両１２０は、ＤＣＭ（Data Communication Module）１３１と、自動運転システムまたは運転支援システム１３２とを有する。ＤＣＭ１３１は通信装置であり、ネットワーク１５０を介して、管理サーバ１１０に接続する。

自動運転または運転支援システム１３２は、インストールされている、自動運転機能または運転支援機能に関するソフトウェアを実行することで、自動運転機能または運転支援機能を実現する。また、自動運転または運転支援システム１３２では、インストールされている自動運転機能または運転支援機能に関するソフトウェアを、管理サーバ１１０から送信された最新バージョンのソフトウェアを用いて更新する。更に、自動運転または運転支援システム１３２では、自動運転機能または運転支援機能の一部または全部の作動を、管理サーバ１１０からの機能制限の指示に従って制限する。

携帯端末１４０には、更新許可プログラムがインストールされており、当該プログラムが携帯端末１４０において実行されることで、携帯端末１４０は、更新許可部１４１として機能する。

更新許可部１４１は、管理サーバ１１０と通信し、ソフトウェアＤＢ１１３に新たに格納された最新バージョンのソフトウェアが、ユーザによる許可が必要なソフトウェアであった場合に、ユーザによる更新許可の入力を受け付ける。管理サーバ１１０と車両１２０とが通信可能に接続されていない場合、管理サーバ１１０では、ソフトウェアの更新許否を携帯端末１４０に問い合わせる。このため、更新許可部１４１では、管理サーバ１１０から更新許否の問い合わせがあった場合に、ユーザからの更新許可の入力を受け付けて管理サーバ１１０に送信する。

このように、携帯端末１４０を介して、事前に更新許可の入力ができるようにしたことで、車両１２０のユーザは、車両１２０を運転操作するタイミングとは異なるタイミングで更新許可を入力することができる。この結果、車両１２０のユーザにとっては、ソフトウェアの更新が許可しやすくなる。また、車両１２０が管理サーバ１１０と通信可能に接続された場合に（例えば、ＩＧ−ＯＮ状態になった時に）、ユーザに対して更新許否の問い合わせを行うことなく、直ちに、ソフトウェアの更新を実行することができる。

＜２．管理サーバのハードウェア構成＞
次に、管理サーバ１１０のハードウェア構成について説明する。図２は、管理サーバのハードウェア構成の一例を示す図である。

図２に示すように、管理サーバ１１０は、ＣＰＵ（Central Processing Unit）２０１、ＲＯＭ（Read Only Memory）２０２、ＲＡＭ（Random Access Memory）２０３、補助記憶部２０４、ユーザインタフェース部２０５、通信部２０６を備える。なお、管理サーバ１１０の各部は、バス２０７を介して相互に接続されている。

ＣＰＵ２０１は、ＲＡＭ２０３を作業領域として、ＲＯＭ２０２及び補助記憶部２０４に格納されたプログラム（ソフトウェア管理プログラム、ユーザ管理プログラム等）を実行するコンピュータである。

ユーザインタフェース部２０５は、ＣＰＵ２０１がプログラムを実行する際に必要な情報を入力したり、ＣＰＵ２０１がプログラムを実行したことで生成された情報を出力する。

通信部２０６は、ネットワーク１５０と接続し、ネットワーク１５０を介して車両１２０のＤＣＭ１３１や携帯端末１４０との間で通信を行う。

＜３．自動運転または運転支援システムの構成＞
次に、車両１２０の自動運転または運転支援システム１３２のシステム構成及び該システムに含まれる自動運転用または運転支援用ＥＣＵ（Electronic Control Unit）のハードウェア構成について説明する。図３（ａ）は、自動運転または運転支援システム１３２のシステム構成の一例を示す図であり、図３（ｂ）は、当該システムに含まれる自動運転用ＥＣＵまたは運転支援用ＥＣＵのハードウェア構成を示す図である。

図３（ａ）に示すように、自動運転または運転支援システム１３２は、自動運転用または運転支援用ＥＣＵ３００を有する。また、自動運転スイッチ３０１、ＧＰＳ（Global Positioning System）３０２、車速センサ３０３、ヨーレートセンサ３０４、カメラ３０５、ミリ波データ３０６、ライダ３０７を有する。更に、アクセルペダルセンサ３０８、ブレーキペダルセンサ３０９、操舵角センサ３１０、スロットルアクチュエータ３１１、ブレーキアクチュエータ３１２、ステアリングアクチュエータ３１３、表示装置３１４、自動運転情報ＤＢ３１５を有する。

自動運転用または運転支援用ＥＣＵ３００は、自動運転または運転支援ソフトウェア格納部３２２にインストールされた自動運転機能に関するソフトウェアまたは運転支援機能に関するソフトウェアを実行することで、自動運転機能または運転支援機能を実現する。自動運転用または運転支援用ＥＣＵ３００は、自動運転スイッチ３０１〜ライダ３０７、アクセルペダルセンサ３０８〜自動運転情報ＤＢ３１５との間で情報を送受信しながら、自動運転機能または運転支援機能を実現する。なお、自動運転用または運転支援用ＥＣＵ３００により実現される自動運転機能または運転支援機能の説明は、ここでは省略する。

自動運転用または運転支援用ＥＣＵ３００には、更にバージョン管理プログラムがインストールされている。自動運転用または運転支援用ＥＣＵ３００は、当該バージョン管理プログラムを実行することで、バージョン管理部３２１としても機能する。

バージョン管理部３２１は、管理サーバ１１０より最新バージョンのソフトウェアを受信した場合に、既にインストールされているソフトウェアを、当該受信した最新バージョンのソフトウェアを用いて更新する。また、バージョン管理部３２１は、管理サーバ１１０から機能制限の指示を受けると、最新バージョンのソフトウェアによる更新が完了するまでの間の所定のタイミングで、自動運転機能または運転支援機能の一部または全部の作動を制限する処理を開始する。所定のタイミングとは、例えば、車両１２０が機能制限の指示を受けた後の次のＩＧ−ＯＮ状態のタイミングである。自動運転機能または運転支援機能の一部または全部の作動を制限する処理は、最新バージョンのソフトウェアによる更新が完了するまで継続し、更新が完了することで制限が解除される。なお、バージョン管理部３２１による当該機能の詳細は後述する。

図３（ｂ）に示すように、バージョン管理部３２１として機能する自動運転用または運転支援用ＥＣＵ３００は、ＣＰＵ３３１、ＲＡＭ３３２、接続部３３３、ＲＯＭ３３４を有する。本実施形態において、バージョン管理プログラムはＲＯＭ３３４に格納されている。また、バージョン管理プログラムは、ＲＡＭ３３２等を作業領域としてＣＰＵ３３１により実行されることで、接続部３３３を介して接続されたＤＣＭ１３１との間で情報を送受信しながら、バージョン管理部３２１としての機能を実現する。

なお、以下では説明の簡略化のため、車両１２０には運転支援システム１３２が搭載されているものとし、運転支援用ＥＣＵ３００の運転支援ソフトウェア格納部３２２にインストールされている運転支援機能に関するソフトウェアを更新する場合について説明する。ただし、自動運転システムが搭載されている場合（自動運転用ＥＣＵの自動運転ソフトウェア格納部にインストールされている自動運転機能に関するソフトウェアを更新する場合）も同様である。

＜４．管理サーバに格納される情報＞
次に、管理サーバ１１０のソフトウェアＤＢ１１３及びユーザ情報ＤＢ１１４にそれぞれ格納される情報について説明する。図４は、ソフトウェアＤＢに格納されるソフトウェア情報及びユーザ情報ＤＢに格納されるユーザ情報の一例を示す図である。

図４（ａ）に示すように、ソフトウェアＤＢ１１３に格納されるソフトウェア情報４００には情報の項目として、"ソフトウェアＩＤ"、"ソフトウェア名"、"作成者"、"作成日時"、"Ｖｅｒ"、"許可要否"が含まれる。

"ソフトウェアＩＤ"には、運転支援機能に関するソフトウェアを識別する識別子が格納される。"ソフトウェア名"には、ソフトウェアＩＤにより特定されるソフトウェアの名称が格納される。"作成者"には、ソフトウェアＩＤにより特定されるソフトウェアの作成者に関する情報が格納される。"作成日時"には、ソフトウェアＩＤにより特定されるソフトウェアの作成日時が格納される。

"Ｖｅｒ"には、ソフトウェアＩＤにより特定されるソフトウェアのバージョン情報が格納される。"許可要否"には、ソフトウェアＩＤにより特定されるソフトウェアが、更新に際して、ユーザによる許可が必要なソフトウェアであるか否かを示す情報が格納される。

図４（ｂ）に示すように、ユーザ情報ＤＢ１１４に格納されるユーザ情報４１０には情報の項目として、"車両ＩＤ"、"車両番号漂"、"ＤＣＭ"、"ユーザ属性"、"携帯端末"、"ソフトウェアの更新状況"、"機能制限"が含まれる。

"車両ＩＤ"には、車両を識別する識別子が格納される。"車両番号漂"には、車両ＩＤにより特定される車両のナンバープレートの情報が格納される。"ＤＣＭ"には、車両ＩＤにより特定される車両に搭載されたＤＣＭの種類が格納される。

"ユーザ属性"には、車両ＩＤにより特定される車両を所有するユーザの属性に関する情報が格納される。"ユーザ属性"には、"名前"、"性別"、年齢"、"住所"等の小項目が含まれる。"携帯端末"には、車両ＩＤにより特定される車両を所有するユーザが所持する携帯端末を識別するための情報が含まれる。

"ソフトウェアの更新状況"には、ソフトウェアＤＢ１１３に格納されたソフトウェアについての各車両における更新状況に関する情報が格納される。更新状況に関する情報は、ソフトウェアごとに分けて管理される。このため、"ソフトウェアの更新状況"には、更に、小項目として、"Ｓ／Ｗ１０１"、"Ｓ／Ｗ２０３"、"Ｓ／Ｗ３０１"・・・が含まれる。

また、更新状況に関する情報には、それぞれの車両の運転支援システム１３２にインストールされているソフトウェアのバージョン情報と、最新のソフトウェアにより更新が完了されるまでの各状況を示す情報（未許可、許可済み、完了）が含まれる。

更新状況に関する情報が"未許可"とは、更新に際してユーザによる許可が必要なソフトウェアであるが、未だユーザにより更新が許可されていない状況にあることを示している。また、更新状況に関する情報が"許可済み"とは、更新に際してユーザによる許可が必要なソフトウェアがユーザにより更新が許可された状況にあるが、ソフトウェアの更新までは完了していない状況にあることを示している。更に、更新状況に関する情報が"完了"とは、更新に際してユーザによる許可が必要なソフトウェアについて、既にユーザにより更新が許可され、ソフトウェアの更新が完了した状況にあることを示している。なお、更新に際してユーザによる許可が不要で、既にソフトウェアの更新が完了している場合についても、更新状況に関する情報は"完了"となる。

"機能制限"には、最新バージョンのソフトウェアであって、ユーザによる許可が必要なソフトウェアがソフトウェアＤＢ１１３に新たに格納され、各車両に機能制限フラグのＯＮ指示が送信された場合に、指示中であることを示す情報が格納される。機能制限フラグとは、運転支援機能の一部または全部の作動を制限することを可能にする制御フラグである。指示中であることを示す情報は、ユーザによる許可が必要なソフトウェアについて、ユーザにより更新許可が入力され、かつ、更新が完了した場合に削除される。図４（ｂ）の例では、車両ＩＤ＝"Ｃ２"の車両の運転支援ソフトウェア格納部にインストールされているソフトウェアＩＤ＝"Ｓ／Ｗ１０１"のソフトウェアが最新バージョンではなく、Ｖｅｒ＝"１．３．１"への更新が必要な状況にある。しかしながら、車両ＩＤ＝"Ｃ２"の車両のユーザにより更新が許可されていないため、図４（ｂ）の例では、"機能制限"には、指示中であることを示す情報が格納されている。

＜５．運転支援用ＥＣＵに格納される運転支援ソフトウェア情報＞
次に、運転支援用ＥＣＵ３００の運転支援ソフトウェア格納部３２２にインストールされているソフトウェアに関する情報を示す運転支援ソフトウェア情報について説明する。運転支援ソフトウェア情報は、運転支援ソフトウェア格納部３２２に格納されている。運転支援ソフトウェア情報は、運転支援ソフトウェア格納部３２２にインストールされている運転支援機能に関するソフトウェアが、管理サーバ１１０から送信されたソフトウェアにより更新されることで書き換えられる。また、運転支援ソフトウェア情報は、運転支援機能に関するソフトウェアにより実現される運転支援機能の一部または全部の作動が、管理サーバ１１０からの指示に基づいて制限された場合に書き換えられる。更には、当該制限が解除された場合にも書き換えられる。

図５は、運転支援ソフトウェア情報の一例を示す図である。このうち、図５（ａ）は、車両ＩＤ＝"Ｃ１"の車両の運転支援ソフトウェア格納部に格納された運転支援ソフトウェア情報を、図５（ｂ）は、車両ＩＤ＝"Ｃ２"の車両の運転支援ソフトウェア格納部に格納された運転支援ソフトウェア情報をそれぞれ示している。更に、図５（ｃ）は、車両ＩＤ＝Ｃ３の車両の運転支援ソフトウェア格納部に格納された運転支援ソフトウェア情報を示している。

図５に示すように、各運転支援ソフトウェア情報には、情報の項目として、"ソフトウェアＩＤ"、"ソフトウェア名"、"作成者"、"作成日時"、"Ｖｅｒ"、"機能制限フラグ"が含まれる。

"ソフトウェアＩＤ"には、運転支援ソフトウェア格納部３２２にインストールされているソフトウェアを識別するための識別子が格納される。"ソフトウェア名、"作成者"、作成日時"、"Ｖｅｒ"には、ソフトウェアＩＤにより識別されるソフトウェアの名称、作成者に関する情報、作成日時、バージョン情報がそれぞれ格納される。

"機能制限フラグ"には、ソフトウェアＩＤにより識別されるソフトウェアについて、管理サーバ１１０から機能制限フラグのＯＮ指示があった場合に"ＯＮ"が格納され、機能制限が解除された場合に"ＯＦＦ"が格納される。

図５（ａ）の例は、車両ＩＤ＝"Ｃ１"の車両の運転支援システム１３２に、ソフトウェアＩＤ＝"Ｓ／Ｗ１０１"により識別されるソフトウェアがインストールされていることを示している。また、図５（ａ）の例は、当該ソフトウェアがＶｅｒ＝"１．３．１"のソフトウェアであり、最新バージョンへの更新が完了しているため、"機能制限フラグ"に"ＯＦＦ"が格納されていることを示している。

図５（ｂ）の例は、車両ＩＤ＝"Ｃ２"の車両の運転支援システム１３２に、ソフトウェアＩＤ＝"Ｓ／Ｗ１０１"、"Ｓ／Ｗ２０３"により識別されるソフトウェアがインストールされていることを示している。また、図５（ｂ）の例は、ソフトウェアＩＤ＝"Ｓ／Ｗ１０１"により識別されるソフトウェアがＶｅｒ＝"１．３．０"のソフトウェアであり、最新バージョンでないことを示している。このため、"機能制限フラグ"に"ＯＮ"が格納されている。

また、図５（ｂ）の例は、ソフトウェアＩＤ＝"Ｓ／Ｗ２０３"により識別されるソフトウェアがＶｅｒ＝"２．１"のソフトウェアであり、最新バージョンへの更新が完了しているため、"機能制限フラグ"に"ＯＦＦ"が格納されていることを示している。

図５（ｃ）の例は、車両ＩＤ＝"Ｃ３"の車両の運転支援システム１３２に、ソフトウェアＩＤ＝"Ｓ／Ｗ２０３"、"Ｓ／Ｗ３０１"により識別されるソフトウェアがインストールされていることを示している。また、図５（ｃ）の例は、ソフトウェアＩＤ＝"Ｓ／Ｗ２０３"により識別されるソフトウェアがＶｅｒ＝"２．０"のソフトウェアであり、最新バージョンでないことを示している。ただし、図４（ｂ）で示したように、最新バージョンのソフトウェアについては、既に、更新が許可されており、管理サーバ１１０からは機能制限フラグのＯＮ指示が送信されないため、"機能制限フラグ"に"ＯＦＦ"が格納されている。

また、図５（ｃ）の例は、ソフトウェアＩＤ＝"Ｓ／Ｗ３０１"により識別されるソフトウェアが、ユーザによる許可が不要なソフトウェアであるため、"機能制限フラグ"に"ＯＮ"、"ＯＦＦ"が格納されることはないことを示している。

＜６．管理サーバの機能構成の詳細＞
次に、管理サーバ１１０のソフトウェア管理部１１１及びユーザ管理部１１２の機能構成の詳細について説明する。図６は、管理サーバのソフトウェア管理部及びユーザ管理部の機能構成の一例を示す図である。

図６に示すように、ソフトウェア管理部１１１は、接続状態管理部６０１、ソフトウェア取得部６０２、ソフトウェア種類判定部６０３、機能制限フラグ制御部６０４、告知指示部６０５、更新指示部６０６を有する。

接続状態管理部６０１は、管理サーバ１１０による管理対象の車両が、管理サーバ１１０に対して、通信可能に接続された状態にあるか否かを管理する。また、接続状態管理部６０１は、管理サーバ１１０による管理対象の車両のユーザが所持する携帯端末が、管理サーバ１１０に対して、通信可能に接続された状態にあるか否かを管理する。

ソフトウェア取得部６０２は、運転支援用ＥＣＵ３００にインストールされているソフトウェアを更新するための最新バージョンのソフトウェアを取得し、ソフトウェアＤＢ１１３に格納する。ソフトウェア取得部６０２は、当該最新バージョンのソフトウェアを新たに取得しソフトウェアＤＢ１１３に格納した場合に、運転支援用ＥＣＵ３００にインストールされているソフトウェアについて更新が必要と判定する。つまり、ソフトウェア取得部６０２は、運転支援用ＥＣＵ３００にインストールされているソフトウェアについて更新の要否を判定する更新要否判定手段として機能する。

ソフトウェア種類判定部６０３は、ソフトウェア取得部６０２により新たに取得され、ソフトウェアＤＢ１１３に格納された最新バージョンのソフトウェア（更新が必要と判定されたソフトウェア）が、更新に際して、ユーザによる許可が必要なソフトウェアであるか否かを判定する。

ソフトウェア種類判定部６０３は、ユーザによる許可が必要なソフトウェアであると判定した場合には、判定結果を、機能制限フラグ制御部６０４及び告知指示部６０５に通知する。また、ソフトウェア種類判定部６０３は、ユーザによる許可が不要なソフトウェアであると判定した場合には、判定結果を、更新指示部６０６に通知する。

機能制限フラグ制御部６０４は制御手段の一例である。機能制限フラグ制御部６０４は、ソフトウェア種類判定部６０３から判定結果を受信した場合に、対象車両に対して、機能制限フラグのＯＮ指示を送信する。機能制限フラグ制御部６０４は、機能制限フラグのＯＮ指示を送信した場合に、ユーザ情報４１０の"機能制限"に指示中であることを示す情報を格納する。

告知指示部６０５は、ソフトウェア種類判定部６０３から判定結果を受信した場合に、対象車両に対して、ユーザによる許可が必要なソフトウェアについての更新の許可要請を行うよう指示する。また、告知指示部６０５は、更新の許可要請の指示に応じて、対象車両のユーザにより更新許可の入力が行われたことを示す情報が対象車両より送信されたか否かを判定し、送信されたと判定した場合に、更新指示部６０６に更新が許可されたことを通知する。

更新指示部６０６は受信手段の一例である。更新指示部６０６は、ソフトウェア種類判定部６０３から判定結果を受信した場合、または、告知指示部６０５から更新が許可された旨の通知を受信した場合に、対象車両に対して、最新バージョンのソフトウェアを送信し、更新を指示する。更新指示部６０６による更新の指示に応じて、対象車両より、ソフトウェアの更新完了通知を受信した場合、更新指示部６０６では、ユーザ情報ＤＢ１１４のユーザ情報４１０の"ソフトウェアの更新状況"を書き換え、"機能制限"に格納された情報を削除する。

＜７．運転支援用ＥＣＵの機能構成の詳細＞
次に、運転支援用ＥＣＵ３００のバージョン管理部３２１の機能構成の詳細について説明する。図７は、運転支援用ＥＣＵのバージョン管理部の機能構成の一例を示す図である。

図７に示すように、バージョン管理部３２１は、告知部７０１、インストール実行部７０２、制限部７０３を有する。

告知部７０１は、管理サーバ１１０の告知指示部６０５より、更新の許可要請の指示を受信した場合に、車両１２０のユーザに対して、最新バージョンのソフトウェアによる更新許否を問い合わせる許可要請画面を表示する。また、告知部７０１は、許可要請画面を表示することで、ユーザからの更新許可の入力を受け付ける。告知部７０１では、ユーザから、更新許可の入力を受け付けた場合に更新が許可されたと判定し、管理サーバ１１０に対して、更新許可の入力が行われたことを示す情報を送信する。

インストール実行部７０２は更新手段の一例である。インストール実行部７０２は、管理サーバ１１０より、最新バージョンのソフトウェアを受信した場合に、最新バージョンのソフトウェアを用いて、運転支援ソフトウェア格納部３２２に既にインストールされているソフトウェアを更新する。また、インストール実行部７０２は、最新バージョンのソフトウェアによる更新が完了した場合に、更新完了通知を、管理サーバ１１０に送信するとともに、制限部７０３に送信する。

制限部７０３は制限手段の一例である。制限部７０３は、管理サーバ１１０より、機能制限フラグのＯＮ指示を受信した場合に、運転支援ソフトウェア格納部３２２に格納された運転支援ソフトウェア情報５１０の"機能制限フラグ"に"ＯＮ"を格納する。

また、制限部７０３は、車両がＩＧ−ＯＮ状態になった時に、運転支援ソフトウェア格納部３２２に格納された運転支援ソフトウェア情報５１０を参照し、機能制限フラグがＯＮ状態になっているか否かを判定する。制限部７０３は、機能制限フラグがＯＮ状態になっていると判定した場合に、当該ソフトウェアに関連する運転支援機能の一部または全部の作動を制限する（機能制限を実施する）。

また、制限部７０３は、インストール実行部７０２より、更新完了通知を受信した場合に、運転支援ソフトウェア格納部３２２に格納された運転支援ソフトウェア情報５１０の"機能制限フラグ"にＯＦＦを格納する。また、更新完了通知を受信した時点で既に機能制限を実施している場合にあっては、制限部７０３は、機能制限を解除する。

＜８．管理サーバにおいて実行される処理の説明＞
次に、管理サーバ１１０において実行される処理（対象車両のＩＧ−ＯＮ状態管理処理、対象携帯端末の接続状態管理処理、バージョン管理処理）について説明する。

（１）対象車両のＩＧ−ＯＮ状態管理処理及び対象携帯端末の接続状態管理処理
図８（ａ）、（ｂ）は、管理サーバにおける対象車両のＩＧ−ＯＮ状態管理処理及び対象携帯端末の接続状態管理処理の流れをそれぞれ示すフローチャートである。

図８（ａ）に示すように、ステップＳ８０１において、接続状態管理部６０１は、対象車両のＩＧ−ＯＮ信号を受信したか否かを判定する。ステップＳ８０１において、対象車両のＩＧ−ＯＮ信号を受信していないと判定した場合には、ステップＳ８０４に進む。

一方、ステップＳ８０１において、対象車両のＩＧ−ＯＮ信号を受信したと判定した場合には、ステップＳ８０２に進む。ステップＳ８０２において、接続状態管理部６０１は、対象車両がＩＧ−ＯＮ状態であると判定する。

ステップＳ８０３において、接続状態管理部６０１は、対象車両のＩＧ−ＯＦＦ信号を受信したか否かを判定する。ステップＳ８０３において、対象車両のＩＧ−ＯＦＦ信号を受信していないと判定した場合には、ステップＳ８０２に戻る。

一方、ステップＳ８０３において、対象車両のＩＧ−ＯＦＦ信号を受信したと判定した場合には、ステップＳ８０４に進む。ステップＳ８０４において、接続状態管理部６０１は、対象車両がＩＧ−ＯＦＦ状態であると判定する。

ステップＳ８０５において、接続状態管理部６０１は、対象車両が管理対象外となったか否かを判定する。管理対象外になっていないと判定した場合には、ステップＳ８０１に戻る。一方、管理対象外になったと判定した場合には、当該対象車両についてのＩＧ−ＯＮ状態管理処理を終了する。

図８（ｂ）に示すように、ステップＳ８１１において、接続状態管理部６０１は、対象携帯端末の接続要求を受信したか否かを判定する。ステップＳ８１１において、対象携帯端末の接続要求を受信していないと判定した場合には、ステップＳ８１４に進む。

一方、ステップＳ８１１において、対象携帯端末の接続要求を受信したと判定した場合には、ステップＳ８１２に進む。ステップＳ８１２において、接続状態管理部６０１は、対象携帯端末が接続状態であると判定する。

ステップＳ８１３において、接続状態管理部６０１は、対象携帯端末の切断要求を受信したか否かを判定する。ステップＳ８１３において、対象携帯端末の切断要求を受信していないと判定した場合には、ステップＳ８１２に戻る。

一方、ステップＳ８１３において、対象携帯端末の切断要求を受信したと判定した場合には、ステップＳ８１４に進む。ステップＳ８１４において、接続状態管理部６０１は、対象携帯端末が非接続状態であると判定する。

ステップＳ８１５において、接続状態管理部６０１は、対象携帯端末が管理対象外になったか否かを判定する。管理対象外になっていないと判定した場合には、ステップＳ８１１に戻る。一方、管理対象外になったと判定した場合には、当該対象携帯端末についての接続状態管理処理を終了する。

（２）バージョン管理処理の流れ
図９及び図１０は、管理サーバにおけるバージョン管理処理の流れを示すフローチャートである。図９に示すように、ステップＳ９０１において、ソフトウェア取得部６０２は、最新バージョンのソフトウェアを新たに取得し、ソフトウェアＤＢ１１３に格納したか否かを判定する。

ステップＳ９０１において、最新バージョンのソフトウェアを新たに取得していないと判定した場合には、ソフトウェア取得部６０２では、最新バージョンのソフトウェアへの更新が不要と判定し、ステップＳ９０２に進む。ステップＳ９０２において、接続状態管理部６０１は、対象車両からＩＧ−ＯＮ信号を受信したか否かを判定する。ステップＳ９０２においてＩＧ−ＯＮ信号を受信していないと判定した場合には、ステップＳ９１５に進む。

一方、ステップＳ９０２において、ＩＧ−ＯＮ信号を受信したと判定した場合には、ステップＳ９０３に進む。ステップＳ９０３において、更新指示部６０６は、対象車両のユーザにより既に更新が許可されたソフトウェアがあるか否かを判定する。

ステップＳ９０３において、既に更新が許可されたソフトウェアがあると判定した場合には、ステップＳ９０４に進む。ステップＳ９０４において、更新指示部６０６は、既に更新が許可されたソフトウェアを対象車両に送信し、ユーザ情報ＤＢ１１４のユーザ情報４１０の"ソフトウェアの更新状況"を書き換えた後、ステップＳ９０５に進む。一方、ステップＳ９０３において、更新が許可されたソフトウェアがないと判定した場合には、直接、ステップＳ９０５に進む。

ステップＳ９０５において、ソフトウェア種類判定部６０３は、対象車両の運転支援ソフトウェア格納部３２２にインストールされている各ソフトウェアのバージョン情報を、対象車両より取得する。

ステップＳ９０６において、ソフトウェア種類判定部６０３は、ステップＳ９０５において取得したバージョン情報に基づいて、対象車両の運転支援ソフトウェア格納部３２２にインストールされている各ソフトウェアが、最新バージョンであるか否かを判定する。

ステップＳ９０６において、最新バージョンであると判定した場合には、ステップＳ９１５に進む。一方、最新バージョンでないと判定した場合には、ステップＳ９０７に進む。

ステップＳ９０７において、ソフトウェア種類判定部６０３は、最新バージョンでないと判定したソフトウェアの中に、更新に際してユーザによる許可が不要なソフトウェアがあるか否かを判定する。

ステップＳ９０７において、ユーザによる許可が不要なソフトウェアがあると判定した場合には、ステップＳ９０８に進む。ステップＳ９０８において、更新指示部６０６は、最新バージョンのソフトウェアであって、ユーザによる許可が不要なソフトウェアについて、対象車両に送信する。更に、更新指示部６０６は、ユーザ情報ＤＢ１１４のユーザ情報４１０の"ソフトウェアの更新状況"を書き換えた後、ステップＳ９０９に進む。

一方、ステップＳ９０７において、ユーザによる許可が不要なソフトウェアがないと判定した場合には、直接、ステップＳ９０９に進む。

ステップＳ９０９において、ソフトウェア種類判定部６０３は、最新バージョンでないと判定したソフトウェアの中に、更新に際してユーザによる許可が必要なソフトウェアがあるか否かを判定する。

ステップＳ９０９において、ユーザによる許可が必要なソフトウェアがないと判定した場合には、ステップＳ９１５に進む。一方、ステップＳ９０９において、ユーザによる許可が必要なソフトウェアがあると判定した場合には、ステップＳ９１０に進む。

ステップＳ９１０において、機能制限フラグ制御部６０４は、ユーザによる許可が必要なソフトウェアについて、既に、機能制限フラグのＯＮ指示を送信しているか否かを判定する。ステップＳ９１０において、機能制限フラグのＯＮ指示を送信していないと判定した場合には、ステップＳ９１１に進む。

ステップＳ９１１において、機能制限フラグ制御部６０４は、ユーザによる許可が必要なソフトウェアについて、対象車両に対して、機能制限フラグのＯＮ指示を送信し、ステップＳ９１２に進む。一方、ステップＳ９１０において、機能制限フラグのＯＮ指示を送信済みであると判定した場合には、直接、ステップＳ９１２に進む。

ステップＳ９１２において、告知指示部６０５は、ユーザによる許可が必要なソフトウェアについて、対象車両に対して、更新の許可要請を行うよう指示する。

更新の許可要請の指示に応じて対象車両にて許可要請が行われると、ステップＳ９１３において、告知指示部６０５は、対象車両のユーザにより更新許可の入力が行われたことを示す情報を、対象車両より受信したか否かを判定する。ステップＳ９１３において、更新許可の入力が行われたことを示す情報を、対象車両より受信したと判定した場合には、ステップＳ９１４に進む。

ステップＳ９１４において、更新指示部６０６は、最新バージョンのソフトウェア（ユーザにより更新が許可されたソフトウェア）を、対象車両に送信する。また、更新指示部６０６は、ユーザ情報ＤＢ１１４のユーザ情報４１０の"ソフトウェアの更新状況"を書き換えた後、ステップＳ９１５に進む。

一方、ステップＳ９１３において、更新許可の入力が行われたことを示す情報を、対象車両より受信していないと判定した場合には、直接、ステップＳ９１５に進む。

ステップＳ９１５において、接続状態管理部６０１は、対象車両からＩＧ−ＯＦＦ信号を受信したか否かを判定する。ステップＳ９１５において、対象車両からＩＧ−ＯＦＦ信号を受信していないと判定した場合には、ステップＳ９０１に戻る。このように、管理サーバ１１０におけるバージョン管理処理は、対象車両よりＩＧ−ＯＦＦ信号を受信するまで継続する。

一方、ステップＳ９０１において、最新バージョンのソフトウェアを新たに取得し、ソフトウェアＤＢ１１３に格納したと判定した場合、ソフトウェア取得部６０２では、該最新バージョンのソフトウェアへの更新が必要と判定し、図１０のステップ１００１に進む。

ステップＳ１００１において、接続状態管理部６０１は、対象車両がＩＧ−ＯＮ状態にあるか否かを判定する。ステップＳ１００１において、対象車両がＩＧ−ＯＮ状態にあると判定した場合には、ステップＳ１００２に進む。

ステップＳ１００２において、ソフトウェア種類判定部６０３は、新たに格納した最新バージョンのソフトウェアが、ユーザによる許可が必要なソフトウェアであるか否かを判定する。ステップＳ１００２において、ユーザによる許可が不要なソフトウェアであると判定した場合には、ステップＳ１００６に進む。

一方、ステップＳ１００２において、ユーザによる許可が必要なソフトウェアであると判定した場合には、ステップＳ１００３に進む。

ステップＳ１００３において、機能制限フラグ制御部６０４は、ユーザによる許可が必要であると判定したソフトウェアに関連する運転支援機能の一部または全部の作動を制限するための機能制限フラグのＯＮ指示を対象車両に送信する。その後、ステップＳ１００４に進む。

ステップＳ１００４において、告知指示部６０５は、ユーザによる許可が必要であると判定したソフトウェアについて、対象車両に対して、更新の許可要請を行うよう指示する。

更新の許可要請の指示に応じて対象車両において許可要請が行われると、ステップＳ１００５において、告知指示部６０５は、対象車両より更新許可の入力が行われたことを示す情報を受信したか否かを判定する。ステップＳ１００５において、更新許可の入力が行われたことを示す情報を受信したと判定した場合には、ステップＳ１００６に進む。

ステップＳ１００６において、更新指示部６０６は、最新バージョンのソフトウェア（ユーザにより更新が許可されたソフトウェア）を、対象車両に送信する。また、更新指示部６０６は、ユーザ情報ＤＢ１１４のユーザ情報４１０の"ソフトウェアの更新状況"を書き換えた後、図９のステップＳ９０２に戻る。

一方、ステップＳ１００５において、更新許可の入力が行われたことを示す情報を受信していないと判定した場合には、直接、図９のステップＳ９０２に戻る。

一方、ステップＳ１００１において、対象車両がＩＧ−ＯＮ状態にないと判定した場合には、ステップＳ１０１１に進む。ステップＳ１０１１において、告知指示部６０５は、新たに格納した最新バージョンのソフトウェアが、ユーザによる許可が必要なソフトウェアであるか否かを判定する。ステップＳ１０１１において、ユーザによる許可が不要なソフトウェアであると判定した場合には、図９のステップＳ９０２に戻る。

一方、ステップＳ１０１１において、ユーザによる許可が必要なソフトウェアであると判定した場合には、ステップＳ１０１２に進む。ステップＳ１０１２において、接続状態管理部６０１は、対象車両に対応付けて登録されている携帯端末が接続状態か否かを判定する。

ステップＳ１０１２において、非接続状態であると判定した場合には、図９のステップＳ９０２に戻る。一方、ステップＳ１０１２において、接続状態であると判定した場合には、ステップＳ１０１３に進む。

ステップＳ１０１３において、告知指示部６０５は、ユーザによる許可が必要であると判定されたソフトウェアについて、対象携帯端末に対して、更新の許可要請を行うよう指示する。

更新の許可要請の指示に応じて対象携帯端末において許可要請が行われると、ステップＳ１０１４において、告知指示部６０５は、対象携帯端末より、更新許可の入力が行われたことを示す情報を受信したか否かを判定する。ステップＳ１０１４において、更新許可の入力が行われたことを示す情報を受信したと判定した場合には、ステップＳ１０１５に進む。

ステップＳ１０１５において、告知指示部６０５は、ユーザによる許可が必要であると判定したソフトウェアについて、既に、ユーザにより更新が許可されていると認識し、ユーザ情報４１０の"ソフトウェアの更新状況"を書き換えた後、ステップＳ９０２に戻る。

＜９．車両において実行される処理の説明＞
次に、車両１２０において実行される処理（最新化処理）の流れについて説明する。図１１及び図１２は、車両における最新化処理の流れを示すフローチャートである。図１１及び図１２に示すフローチャートは、車両がＩＧ−ＯＮ状態になることで処理が開始される。

図１１に示すように、ステップＳ１１０１において、制限部７０３は、運転支援ソフトウェア情報５１０を参照し、機能制限フラグがＯＮ状態のソフトウェアがあるか否かを判定する。ステップＳ１１０１において、機能制限フラグがＯＮ状態のソフトウェアがあると判定した場合には、ステップＳ１１０２に進む。一方、機能制限フラグがＯＮ状態のソフトウェアがないと判定した場合には、ステップＳ１１０３に進む。

ステップＳ１１０２において、制限部７０３は、機能制限フラグがＯＮ状態のソフトウェアに関連する運転支援機能の一部または全部の作動を制限する、機能制限を実施する。

ステップＳ１１０３において、ＤＣＭ１３１は、ＩＧ−ＯＮ信号を管理サーバ１１０に送信する。

ステップＳ１１０４において、インストール実行部７０２は、管理サーバ１１０から更新が許可されたソフトウェアを受信したか否かを判定する。携帯端末１４０を介してユーザにより更新が許可されたソフトウェアがあった場合、管理サーバ１１０から、更新が許可されたソフトウェアが送信される。このため、インストール実行部７０２では、管理サーバ１１０から更新が許可されたソフトウェアを受信したと判定した場合には、ステップＳ１１０５に進む。

ステップＳ１１０５において、インストール実行部７０２は、運転支援ソフトウェア格納部３２２に既にインストールされているソフトウェアを、更新が許可されたソフトウェアにより更新した後、ステップＳ１１０６に進む。

一方、ステップＳ１１０４において、管理サーバ１１０から更新が許可されたソフトウェアを受信していないと判定した場合には、直接、ステップＳ１１０６に進む。

ステップＳ１１０６において、インストール実行部７０２は、運転支援ソフトウェア格納部３２２にインストールされている各ソフトウェアのバージョン情報を取得し、管理サーバ１１０に送信する。

ステップＳ１１０７において、インストール実行部７０２は、管理サーバ１１０より、ユーザによる許可が不要なソフトウェアを受信したか否かを判定する。ステップＳ１１０７において、ユーザによる許可が不要なソフトウェアを受信したと判定した場合には、ステップＳ１１０８に進む。

ステップＳ１１０８において、インストール実行部７０２は、運転支援ソフトウェア格納部３２２に既にインストールされているソフトウェアを、ユーザによる許可が不要なソフトウェアを用いて更新した後、ステップＳ１１０９に進む。

一方、ステップＳ１１０７において、ユーザによる許可が不要なソフトウェアを受信していないと判定した場合には、直接、ステップＳ１１０９に進む。

ステップＳ１１０９において、制限部７０３は、管理サーバ１１０より機能制限フラグのＯＮ指示を受信したか否かを判定する。ステップＳ１１０９において、機能制限フラグのＯＮ指示を受信したと判定した場合には、ステップＳ１１１０に進む。

ステップＳ１１１０において、制限部７０３は、管理サーバ１１０からのＯＮ指示に基づいて、運転支援ソフトウェア情報５１０の"機能制限フラグ"に"ＯＮ"を格納した後、ステップＳ１１１１に進む。

一方、ステップＳ１１０９において、機能制限フラグのＯＮ指示を受信していないと判定した場合には、直接、ステップＳ１１１１に進む。

ステップＳ１１１１において、告知部７０１は、管理サーバ１１０より、更新の許可要請の指示を受信したか否かを判定する。ステップＳ１１１１において、更新の許可要請の指示を受信したと判定した場合には、ステップＳ１１１２に進む。

ステップＳ１１１２において、告知部７０１は、管理サーバ１１０より更新の許可要請が指示されたソフトウェアについて、許可要請画面を表示した後、図１２のステップＳ１２０１に進む。

一方、ステップＳ１１１１において、更新の許可要請の指示を受信していないと判定した場合には、図１２のステップＳ１２２１に進む。

ステップＳ１２０１において、告知部７０１は、許可要請画面において、ユーザにより、更新許可の入力が行われたか否かを判定する。ステップＳ１２０１において、許可要請画面が表示されてから所定時間内に、ユーザにより更新許可の入力が行われたと判定した場合には、ステップＳ１２０２に進む。

ステップＳ１２０２において、告知部７０１は、ユーザにより更新許可の入力が行われたことを示す情報を、管理サーバ１１０に送信する。ステップＳ１２０３において、インストール実行部７０２は、ユーザにより更新が許可されたソフトウェアを、管理サーバ１１０より受信する。

ステップＳ１２０４において、インストール実行部７０２は、管理サーバ１１０より受信したソフトウェアを用いて、運転支援ソフトウェア格納部３２２に既にインストールされているソフトウェアを更新する。

インストール実行部７０２による更新が完了すると、ステップＳ１２０５において、制限部７０３は、更新が完了したソフトウェアについて、運転支援ソフトウェア情報５１０の"機能制限フラグ"にＯＦＦを格納する。また、既に機能制限が実施されている場合には、制限部７０３が、更新が完了したソフトウェアに関連する運転支援機能についての機能制限を解除する（つまり、機能制限は、機能制限フラグがＯＦＦ状態になったタイミングで解除される）。

ステップＳ１２０６において、インストール実行部７０２は、更新が完了したことを示す更新完了通知を管理サーバ１１０に送信した後、ステップＳ１２２１に進む。

一方、ステップＳ１２０１において、許可要請画面が表示されてから所定時間内に、ユーザにより更新許可の入力が行われなかったと判定した場合には、ステップＳ１２１１に進む。ステップＳ１２１１において、制限部７０３は、機能制限を実施中であるか否かを判定する。

ステップＳ１２１１において、機能制限を実施中でないと判定した場合には、ステップＳ１２１２に進む。ステップＳ１２１２において、告知部７０１は、次にＩＧ−ＯＮ状態になった時に、許可要請されたソフトウェアについての機能制限が実施されることを、ユーザに告知した後、ステップＳ１２２１に進む。

一方、ステップＳ１２１１において、機能制限を実施中であると判定した場合には、直接、ステップＳ１２２１に進む。ステップＳ１２２１において、制限部７０３は、車両がＩＧ−ＯＦＦ状態になったか否かを判定する。ステップＳ１２２１において、ＩＧ−ＯＦＦ状態になっていないと判定した場合には、ステップＳ１１０７に戻る。一方、ＩＧ−ＯＦＦ状態になったと判定した場合には、最新化処理を終了する。

＜１０．携帯端末において実行される処理の説明＞
次に、携帯端末１４０において実行される処理（更新許可処理）の流れについて説明する。図１３は、携帯端末における更新許可処理の流れを示すフローチャートである。図１３に示すフローチャートは、携帯端末１４０において、更新許可プログラムが起動されることで処理が開始される。

ステップＳ１３０１において、更新許可部１４１は、管理サーバ１１０に接続する。ステップＳ１３０２において、更新許可部１４１は、管理サーバ１１０より、更新の許可要請の指示を受信したか否かを判定する。

ステップＳ１３０２において、更新の許可要請の指示を受信していないと判定した場合には、ステップＳ１３０７に進む。

一方、ステップＳ１３０２において、更新の許可要請の指示を受信したと判定した場合には、ステップＳ１３０３に進む。ステップＳ１３０３において、更新許可部１４１は、許可要請画面を表示する。

ステップＳ１３０４において、更新許可部１４１は、許可要請画面において、ユーザにより更新許可の入力が行われたか否かを判定する。許可要請画面が表示されてから所定時間内に、ユーザにより更新許可の入力が行われたと判定した場合には、ステップＳ１３０５に進む。ステップＳ１３０５において、更新許可部１４１は、ユーザにより更新許可の入力が行われたことを示す情報を、管理サーバ１１０に送信した後、ステップＳ１３０６に進む。

一方、ステップＳ１３０４において、許可要請画面が表示されてから所定時間内に更新許可の入力が行われなかったと判定した場合には、直接、ステップＳ１３０６に進む。

ステップＳ１３０６において、更新許可部１４１は、更新許可プログラムを終了する旨の指示が入力されたか否かを判定する。ステップＳ１３０７において、更新許可プログラムを終了する旨の指示が入力されていないと判定した場合には、ステップＳ１３０２に戻る。

一方、ステップＳ１３０６において、更新許可プログラムを終了する旨の指示が入力されたと判定した場合には、ステップＳ１３０７に進む。ステップＳ１３０７において、更新許可部１４１は、管理サーバ１１０との接続を遮断し、更新許可処理を終了する。

＜１１．車両用のソフトウェア管理システムにおける実施例＞
次に、車両用のソフトウェア管理システム１００における各実施例について、図９〜図１３を参照しながら説明する。なお、以下では、対象車両における１回目のＩＧ−ＯＮ状態において、対象車両にインストールされているソフトウェアのバージョン情報を確認し、２回目のＩＧ−ＯＮ状態において、機能制限を実施するものとする。

＜１１．１ 実施例１＞
実施例１では、１回目のＩＧ−ＯＮ状態において、ソフトウェアＤＢ１１３に複数の最新バージョンのソフトウェアが新たに格納されたが、対象車両にて更新が許可されず、２回目のＩＧ−ＯＮ状態において、機能制限が実施されるシーンについて説明する。なお、複数のソフトウェアには、ユーザによる許可が不要なソフトウェアと、ユーザによる許可が必要なソフトウェアとが含まれているものとする。

（１）実施例１の場合の管理サーバ１１０における処理（１回目のＩＧ−ＯＮ状態）
実施例１の場合、ソフトウェアＤＢ１１３に複数の最新バージョンのソフトウェアが新たに格納される前に、接続状態管理部６０１が、対象車両からＩＧ−ＯＮ信号を受信する（ステップＳ９０１（Ｎｏ）→Ｓ９０２（Ｙｅｓ））。

この時点では、更新が許可されたソフトウェアはない（ステップＳ９０３（Ｎｏ））。また、対象車両からは、運転支援ソフトウェア格納部３２２にインストールされている各ソフトウェアのバージョン情報が送信されるため、ソフトウェア種類判定部６０３では、これを取得する（ステップＳ９０５）。

この時点で、対象車両の運転支援ソフトウェア格納部３２２には、最新バージョンのソフトウェアがインストールされている。このため、管理サーバ１１０では、最新バージョンのソフトウェアが新たに取得され、ソフトウェアＤＢ１１３に格納されるまで待機することになる（ステップＳ９０６（Ｙｅｓ）→Ｓ９１５（Ｎｏ）→Ｓ９０１）。

ここで、複数の最新バージョンのソフトウェア（更新に際してユーザによる許可が不要なソフトウェアと、必要なソフトウェア）が新たに取得され、ソフトウェアＤＢ１１３に格納されたとする（ステップＳ９０１（Ｙｅｓ））。なお、この時点では、既に対象車両はＩＧ−ＯＮ状態にある（ステップＳ１００１（Ｙｅｓ）。

したがって、最新バージョンのソフトウェアのうち、ユーザによる許可が不要なソフトウェアについては、更新指示部６０６が対象車両に送信するとともに、ユーザ情報ＤＢ１１４を書き換える（ステップＳ１００２（Ｎｏ）→Ｓ１００６）。一方、ユーザによる許可が必要なソフトウェアについては、機能制限フラグ制御部６０４が、対象車両に対して機能制限フラグのＯＮ指示を送信する（ステップＳ１００２（Ｙｅｓ）→ステップＳ１００３）。また、告知指示部６０５が、対象車両に対して更新の許可要請を行うよう指示する（ステップＳ１００４）。

ここで、対象車両のユーザが、更新許可の入力を行わなかったとする。この場合、対象車両より、更新許可の入力が行われたことを示す情報が送信されることはない（ステップＳ１００５（Ｎｏ））。このため、更新指示部６０６が、ユーザによる許可が必要なソフトウェアを対象車両に送信することはない。その後、対象車両から、ＩＧ−ＯＦＦ信号を受信すると、管理サーバ１１０では、バージョン管理処理を終了する（ステップＳ９０２（Ｎｏ）→ステップＳ９１５（Ｙｅｓ））。

（２）実施例１の場合の車両１２０における処理（１回目のＩＧ−ＯＮ状態）
車両１２０が１回目にＩＧ−ＯＮ状態になった時点では、機能制限フラグはいずれもＯＦＦ状態であることから、機能制限は実施されず、ＤＣＭ１３１では、管理サーバ１１０にＩＧ−ＯＮ信号を送信する（ステップＳ１１０１（Ｎｏ）→Ｓ１１０３）。また、１回目にＩＧ−ＯＮ状態になった時点で、管理サーバ１１０から更新が許可されたソフトウェアが送信されることもない（ステップＳ１１０４（Ｎｏ））。

そこで、インストール実行部７０２では、運転支援ソフトウェア格納部３２２にインストールされている各ソフトウェアのバージョン情報を読み出し、管理サーバ１１０に送信する（ステップＳ１１０６）。

この時点では、運転支援ソフトウェア格納部３２２にインストールされている各ソフトウェアのバージョン情報は最新である。このため、管理サーバ１１０から、ユーザによる許可が不要なソフトウェアが送信されることも、機能制限フラグのＯＮ指示が送信されることもない（ステップＳ１１０７（Ｎｏ）→Ｓ１１０９（Ｎｏ））。また、管理サーバ１１０から更新の許可要請の指示が送信されることもない（ステップＳ１１１１（Ｎｏ）→Ｓ１２２１（Ｎｏ）→Ｓ１１０７）。

ここで、管理サーバ１１０により複数の最新バージョンのソフトウェア（更新に際してユーザによる許可が不要なソフトウェアと、ユーザによる許可が必要なソフトウェア）が新たに取得され、ソフトウェアＤＢ１１３に格納されたとする。

この場合、管理サーバ１１０から、ユーザによる許可が不要なソフトウェアが送信される。このため、インストール実行部７０２では、これを受信し、運転支援ソフトウェア格納部３２２に既にインストールされているソフトウェアを更新する（ステップＳ１１０７（Ｙｅｓ）→Ｓ１１０８）。また、管理サーバ１１０から、機能制限フラグのＯＮ指示が送信されるため、制限部７０３では、これを受信し、機能制限フラグをＯＮにする（ステップＳ１１０９（Ｙｅｓ）→Ｓ１１１０）。

更に、管理サーバ１１０から、更新の許可要請の指示が送信されるため、告知部７０１では、これを受信して許可要請画面を表示する（ステップＳ１１１１（Ｙｅｓ）→Ｓ１１１２）。

ここで、車両１２０のユーザが、更新許可の入力を行わなかったとする。この場合、告知部７０１では、ユーザにより更新許可の入力が行われなかったと判定する（ステップＳ１２０１（Ｎｏ））。なお、この時点では、未だ機能制限を実施していないことから、制限部７０３では、ユーザに対して、次にＩＧ−ＯＮ状態になった時に機能制限を実施することを告知する（ステップＳ１２１１（Ｎｏ）→Ｓ１２１２）。その後、車両１２０がＩＧ−ＯＦＦ状態になると、最新化処理を終了する（ステップＳ１２２１（Ｙｅｓ））。

（３）実施例１の場合の管理サーバ１１０における処理（２回目のＩＧ−ＯＮ状態）
１回目のＩＧ−ＯＮ状態において、複数の最新バージョンのソフトウェアが新たに取得されソフトウェアＤＢ１１３に格納されて以降、２回目にＩＧ−ＯＮ状態になるまでの間に、更なる最新バージョンのソフトウェアが取得されることはなかったものとして説明する。

この場合、ソフトウェアＤＢ１１３に更なる最新バージョンのソフトウェアが格納されることなく、対象車両より２回目のＩＧ−ＯＮ信号を受信する（ステップＳ９０１（Ｎｏ）→Ｓ９０２（Ｙｅｓ））。

この時点では、更新が許可されたソフトウェアはない。また、対象車両からは、運転支援ソフトウェア格納部３２２にインストールされている各ソフトウェアのバージョン情報が送信される（ステップＳ９０３（Ｎｏ）→Ｓ９０５）。

管理サーバ１１０では、１回目のＩＧ−ＯＮ状態において、ユーザによる許可が必要なソフトウェアを対象車両に送信していない。このため、対象車両より取得するバージョン情報のうち、ユーザによる許可が必要なソフトウェアについては、バージョン情報が最新のものではない（ステップＳ９０６（Ｎｏ）→Ｓ９０７（Ｎｏ）→Ｓ９０９（Ｙｅｓ））。

また、管理サーバ１１０では、１回目のＩＧ−ＯＮ状態において、当該ソフトウェアについて既に対象車両に対して機能制限フラグのＯＮ指示を送信しているため、ここでは機能制限フラグのＯＮ指示は送信しない（ステップＳ９１０（Ｙｅｓ））。一方、告知部７０１では、再度、更新の許可要請を行うよう指示する（ステップＳ９１２）。

なお、２回目のＩＧ−ＯＮ状態において、ユーザが、更新許可の入力を行った場合には、更新許可された当該ソフトウェアを送信し、ユーザ情報ＤＢ１１４を書き換える（ステップＳ９１３（Ｙｅｓ）→Ｓ９１４）。一方、２回目のＩＧ−ＯＮ状態においても、ユーザが、更新許可の入力を行わなかった場合には、当該ソフトウェアを送信することも、ユーザ情報ＤＢ１１４を書き換えることもない（ステップＳ９１３（Ｎｏ））。

その後、２回目のＩＧ−ＯＦＦ信号を受信した場合には、対象車両についてのバージョン管理処理を終了する（ステップＳ９１５（Ｙｅｓ））。

（４）実施例１の場合の車両１２０における処理（２回目のＩＧ−ＯＮ状態）
車両１２０が２回目にＩＧ−ＯＮ状態になった時点で、ユーザによる許可が必要なソフトウェアについての機能制限フラグはＯＮ状態になっている。このため、２回目にＩＧ−ＯＮ状態になると、制限部７０３では、機能制限を実施する（ステップＳ１１０１（Ｙｅｓ）→Ｓ１１０２）。その後、ＤＣＭ１３１が、管理サーバ１１０にＩＧ−ＯＮ信号を送信する（ステップＳ１１０３）。なお、この時点で、管理サーバ１１０から更新が許可されたソフトウェアが送信されることはない（ステップＳ１１０４（Ｎｏ））。

インストール実行部７０２では、運転支援ソフトウェア格納部３２２にインストールされている各ソフトウェアのバージョン情報を読み出し、管理サーバ１１０に送信する（ステップＳ１１０６）。

管理サーバ１１０に送信したバージョン情報のうち、１回目のＩＧ−ＯＮ状態において更新許可の入力が行われなかったソフトウェアについては、バージョン情報が最新ではない。このため、管理サーバ１１０からは、更新の許可要請の指示が送信される。なお、当該ソフトウェアについての機能制限フラグのＯＮ指示は、１回目のＩＧ−ＯＮ状態において既に管理サーバ１１０より送信済みであるため、ここでは送信されない（ステップＳ１１０７（Ｎｏ）→Ｓ１１０９（Ｎｏ）→Ｓ１１１１（Ｙｅｓ））。

更新の許可要請の指示を受信した告知部７０１では、更新の許可要請画面を表示し、ユーザによる更新許可の入力を受け付ける。

ここで、告知部７０１では、ユーザから更新許可の入力を受け付けたとする。この場合、告知部７０１では、更新許可の入力が行われたことを示す情報を管理サーバ１１０に送信する（ステップＳ１２０１（Ｙｅｓ）→Ｓ１２０２）。また、インストール実行部７０２では、更新が許可されたソフトウェアを管理サーバ１１０から受信し、運転支援ソフトウェア格納部３２２に既にインストールされているソフトウェアを更新する（ステップＳ１２０３→Ｓ１２０４）。更に、制限部７０３では、実施中の機能制限を解除するとともに、機能制限フラグをＯＦＦ状態にし、インストール実行部７０２では、更新完了通知を管理サーバ１１０に送信する（ステップＳ１２０５→Ｓ１２０６）。その後、車両１２０がＩＧ−ＯＦＦ状態になると、最新化処理を終了する（ステップＳ１２２１（Ｙｅｓ））。

なお、２回目のＩＧ−ＯＮ状態においても、ユーザが更新許可の入力を行わなかった場合には、車両１２０がＩＧ−ＯＦＦ状態になるまで機能制限を継続する（ステップＳ１２０１（Ｎｏ）→Ｓ１２１１（Ｙｅｓ）→Ｓ１２２１（Ｙｅｓ））。

＜１１．２ 実施例２＞
実施例２では、ＩＧ−ＯＦＦ状態において、複数の最新バージョンのソフトウェアが新たに取得されソフトウェアＤＢ１１３に格納されたが、１回目のＩＧ−ＯＮ状態で更新が許可されず、２回目のＩＧ−ＯＮ状態で機能制限が実施されるシーンについて説明する。なお、実施例１と同様に、複数の最新バージョンのソフトウェアには、ユーザによる許可が不要なソフトウェアと、必要なソフトウェアとが含まれているものとする。

（１）実施例２の場合の管理サーバ１１０における処理（１回目のＩＧ−ＯＮ状態）
実施例２の場合、対象車両が１回目のＩＧ−ＯＮ状態になる前に、複数の最新バージョンのソフトウェアが新たに取得されソフトウェアＤＢ１１３に格納される（ステップＳ９０１（Ｙｅｓ））。この場合、接続状態管理部６０１では、対象車両がＩＧ−ＯＮ状態であるか否かを判定する（ステップＳ１００１）。

この時点では、対象車両がＩＧ−ＯＮ状態ではないため、接続状態管理部６０１では、携帯端末が接続状態か否かを判定する（ステップＳ１００１（Ｎｏ）→Ｓ１０１１（Ｙｅｓ）→Ｓ１０１２）。接続状態管理部６０１では、携帯端末が非接続状態であれば、対象車両からＩＧ−ＯＮ信号が送信されるのを待つ（ステップＳ１０１２（Ｎｏ）→Ｓ９０２）。

ここで、対象車両が１回目のＩＧ−ＯＮ状態になると、接続状態管理部６０１では、ＩＧ−ＯＮ信号を受信する（ステップＳ９０２（Ｙｅｓ））。この時点では、更新が許可されたソフトウェアはない。また、対象車両からは、運転支援ソフトウェア格納部３２２にインストールされている各ソフトウェアのバージョン情報が送信される（ステップＳ９０３（Ｎｏ）→Ｓ９０５）。

ここで、ソフトウェアＤＢ１１３には、既に複数の最新バージョンのソフトウェアが格納されていることから、ソフトウェア種類判定部６０３では、取得したバージョン情報が最新ではないと判定する（ステップＳ９０６（Ｎｏ））。

ソフトウェアＤＢ１１３に既に格納されている複数の最新バージョンのソフトウェアのうち、ユーザによる許可が不要なソフトウェアについては、更新指示部６０６が対象車両に送信する。また、更新指示部６０６が、ユーザ情報ＤＢ１１４を書き換える（ステップＳ９０７（Ｙｅｓ）→Ｓ９０８）。

また、ユーザによる許可が必要なソフトウェアについては、未だ機能制限フラグのＯＮ指示を送信していない。このため、機能制限フラグ制御部６０４では、当該ソフトウェアについて、対象車両に対して機能制限フラグのＯＮ指示を送信する（ステップＳ９０９（Ｙｅｓ）→Ｓ９１０（Ｎｏ）→Ｓ９１１）。また、告知指示部６０５では、当該ソフトウェアについて、対象車両に対して更新の許可要請を行うよう指示する（ステップＳ９１２）。

ここで、告知部７０１が、対象車両より、更新許可の入力が行われたことを示す情報を受信しなかったとする（ステップＳ９１３（Ｎｏ））。

この場合、更新指示部６０６では、ユーザによる許可が必要なソフトウェアを対象車両に送信することはない。その後、対象車両から、ＩＧ−ＯＦＦ信号を受信すると、管理サーバ１１０では、バージョン管理処理を終了する（ステップＳ９１５（Ｙｅｓ））。

（２）実施例２の場合の車両１２０における処理（１回目のＩＧ−ＯＮ状態）
車両１２０が１回目にＩＧ−ＯＮ状態になった時点では、機能制限フラグはいずれもＯＦＦ状態であることから、機能制限は実施されず、ＤＣＭ１３１では、管理サーバ１１０にＩＧ−ＯＮ信号を送信する（ステップＳ１１０１（Ｎｏ）→Ｓ１１０３）。また、１回目のＩＧ−ＯＮ状態の時点で、管理サーバ１１０から更新が許可されたソフトウェアが送信されることはない（ステップＳ１１０４（Ｎｏ））。

そこで、インストール実行部７０２では、運転支援ソフトウェア格納部３２２にインストールされている各ソフトウェアのバージョン情報を読み出し、管理サーバ１１０に送信する（ステップＳ１１０６）。

この時点では、既に、管理サーバ１１０のソフトウェアＤＢ１１３には、複数の最新バージョンのソフトウェアが格納されている。したがって、管理サーバ１１０からは、ユーザによる許可が不要なソフトウェアが送信されるとともに、ユーザによる許可が必要なソフトウェアについて、機能制限フラグのＯＮ指示が送信される。このため、インストール実行部７０２では、ユーザによる許可が不要なソフトウェアについては更新する。また、ユーザによる許可が必要なソフトウェアについては機能制限フラグをＯＮ状態にする（ステップＳ１１０７（Ｙｅｓ）→Ｓ１１０８→Ｓ１１０９（Ｙｅｓ）→Ｓ１１１０）。

更に、管理サーバ１１０からは、ユーザによる許可が必要なソフトウェアについての更新の許可要請の指示が送信されるため、告知部７０１では、許可要請画面を表示する（ステップＳ１１１１（Ｙｅｓ）→Ｓ１１１２）。

ここで、ユーザが、更新許可の入力を行わなかったとする。この時点では、未だ機能制限を実施していないため、告知部７０１では、次にＩＧ−ＯＮ状態になった時に機能制限を実施することをユーザに告知する（ステップＳ１２０１（Ｎｏ）→Ｓ１２１１（Ｎｏ）→Ｓ１２１２）。その後、車両１２０がＩＧ−ＯＦＦ状態になると、最新化処理を終了する（ステップＳ１２２１（Ｙｅｓ））。

なお、実施例２の場合の管理サーバ１１０における処理（２回目のＩＧ−ＯＮ状態）及び車両１２０における処理（２回目のＩＧ−ＯＮ状態）については、上記実施例１と同じであるため、ここでは説明を省略する。

＜１１．３ 実施例３＞
実施例３では、ＩＧ−ＯＦＦ状態において、ソフトウェアＤＢ１１３に複数の最新バージョンのソフトウェアが新たに格納され、ユーザが携帯端末１４０にて更新許可の入力を行い、ＩＧ−ＯＮ状態になった時にソフトウェアを更新するシーンについて説明する。

（１）実施例３の場合の管理サーバ１１０における処理
実施例３の場合、対象車両がＩＧ−ＯＮ状態になる前に、複数の最新バージョンのソフトウェアが新たに取得されソフトウェアＤＢ１１３に格納される。このため、接続状態管理部６０１では、対象車両がＩＧ−ＯＮ状態であるか否かを判定する（ステップＳ９０１（Ｙｅｓ）→Ｓ１００１）。

この時点では、対象車両がＩＧ−ＯＮ状態ではないため、接続状態管理部６０１では、携帯端末１４０が接続状態か否かを判定する（ステップＳ１００１（Ｎｏ）→Ｓ１０１１（Ｙｅｓ）→Ｓ１０１２）。

ここで、携帯端末１４０が接続状態であったとする。この場合、告知指示部６０５では、携帯端末に対して、最新バージョンのソフトウェアのうち、ユーザによる許可が必要なソフトウェアについて、更新の許可要請を行うよう指示する（ステップＳ１０１２（Ｙｅｓ）→Ｓ１０１３）。

ここで、告知指示部６０５が、携帯端末より、更新許可の入力が行われたことを示す情報を受信したとする（ステップＳ１０１４（Ｙｅｓ））。この場合、更新指示部６０６では、ユーザによる許可が必要なソフトウェアについて、既に、ユーザにより更新が許可されたと認識する（ステップＳ１０１５）。

その後、対象車両がＩＧ−ＯＮ状態になると、接続状態管理部６０１では、対象車両よりＩＧ−ＯＮ信号を受信する（ステップＳ９０２（Ｙｅｓ））。この時点で、携帯端末１４０を介して既に更新が許可されたソフトウェアがあるため、更新指示部６０６では、更新が許可されたと認識したソフトウェアを、対象車両に送信する。また、更新指示部６０６では、ユーザ情報ＤＢ１１４のユーザ情報４１０を書き換える（ステップＳ９０３（Ｙｅｓ）→Ｓ９０４）。

また、更新指示部６０６では、対象車両より、運転支援ソフトウェア格納部３２２にインストールされている各ソフトウェアのバージョン情報を取得する（ステップＳ９０５）。この時点では、ユーザによる許可が必要なソフトウェアについては車両１２０に送信済みであるため、ユーザによる許可が必要なソフトウェアについてのバージョン情報は最新である。一方、ユーザによる許可が不要なソフトウェアについては、まだ車両１２０に送信していないため、ユーザによる許可が不要なソフトウェアについてのバージョン情報は最新ではない（ステップＳ９０６（Ｎｏ））。

このため、更新指示部６０６では、ユーザによる許可が不要なソフトウェアを対象車両に送信するとともに、ユーザ情報ＤＢ１１４を書き換える（ステップＳ９０７（Ｙｅｓ）→Ｓ９０８）。なお、この時点では、ユーザによる許可が必要なソフトウェアは送信済みであるため（ステップＳ９０９（Ｎｏ））、対象車両からＩＧ−ＯＦＦ信号を受信すると、対象車両についてのバージョン管理処理を終了する（ステップＳ９１５（Ｙｅｓ））。

（２）実施例３の場合の車両１２０における処理（１回目のＩＧ−ＯＮ）
車両１２０が１回目にＩＧ−ＯＮ状態になった時点では、機能制限フラグはいずれもＯＦＦ状態であることから、機能制限は実施されず、ＤＣＭ１３１では、管理サーバ１１０にＩＧ−ＯＮ信号を送信する（ステップＳ１１０１（Ｎｏ）→Ｓ１１０３）。

ここで、実施例３の場合、ＩＧ−ＯＮ状態になった時点で、管理サーバ１１０から更新が許可されたソフトウェアが送信される。したがって、インストール実行部７０２では、更新が許可されたソフトウェアを受信すると、運転支援ソフトウェア格納部３２２に既にインストールされているソフトウェアを更新する（ステップＳ１１０４（Ｙｅｓ）→Ｓ１１０５）。

その後、インストール実行部７０２では、運転支援ソフトウェア格納部３２２にインストールされている各ソフトウェアのバージョン情報を管理サーバ１１０に送信する（ステップＳ１１０６）。この時点では、ユーザによる許可が必要なソフトウェアについては最新バージョンに更新されているが、ユーザによる許可が不要なソフトウェアについては最新バージョンに更新されていない。

したがって、管理サーバ１１０からは、ユーザによる許可が不要なソフトウェアが送信される。インストール実行部７０２では、ユーザによる許可が不要なソフトウェアを受信すると、運転支援ソフトウェア格納部３２２に既にインストールされているソフトウェアを更新する（ステップＳ１１０７（Ｙｅｓ）→Ｓ１１０８）。

なお、管理サーバ１１０から、機能制限フラグのＯＮ指示、及び、ユーザによる許可が必要なソフトウェアについての更新の許可要請の指示は送信されない（ステップＳ１１０９（Ｎｏ）→Ｓ１１１１（Ｎｏ）→Ｓ１２２１）。

その後、車両１２０がＩＧ−ＯＦＦ状態になると、最新化処理を終了する（ステップＳ１２２１（Ｙｅｓ））。

（３）実施例３の場合の携帯端末１４０における処理
実施例３の場合、携帯端末１４０の更新許可部１４１が管理サーバ１１０に接続した後、管理サーバ１１０より、ユーザによる許可が必要なソフトウェアについての更新の許可要請の指示が送信される（ステップＳ１３０１→Ｓ１３０２（Ｙｅｓ））。

更新許可部１４１では、更新の許可要請の指示を受信すると、許可要請画面を表示し、ユーザによる更新許可の入力を受け付ける（ステップＳ１３０３）。ユーザが更新許可を入力した場合、更新許可部１４１では、管理サーバ１１０に対して、更新許可の入力が行われたことを示す情報を送信する（ステップＳ１３０４（Ｙｅｓ）→Ｓ１３０５）。

その後、ユーザにより、更新許可プログラムの停止指示が入力されると、更新許可部１４１では、管理サーバ１１０との接続を遮断し、更新許可処理を終了する（ステップＳ１３０６（Ｙｅｓ）→Ｓ１３０７）。

＜１２．管理サーバにおいて実行されるその他の処理の説明＞
次に、管理サーバ１１０において実行されるその他の処理（ユーザ管理部１１２によるユーザ管理処理）について説明する。

図１４は、管理サーバ１１０のユーザ管理部１１２により実行されるユーザ管理処理の流れを示すフローチャートである。図１４に示すフローチャートは、対象車両のＩＧ−ＯＮ状態管理処理、対象携帯端末の接続状態管理処理、バージョン管理処理と並行して実行される。

ステップＳ１４０１において、ユーザ管理部１１２は、告知指示部６０５が対象車両に対して、更新の許可要請を行うよう指示したか否かを判定する。ステップＳ１４０１において、指示していないと判定した場合には、ステップＳ１４０５に進む。

一方、指示したと判定した場合には、ステップＳ１４０２に進む。ステップＳ１４０２において、ユーザ管理部１１２は、告知指示部６０５が更新の許可要請を行うよう指示したソフトウェアについて、ユーザにより更新許可の入力が行われるまでの時間の管理を開始する。また、ユーザ管理部１１２は、告知指示部６０５が更新の許可要請を行うよう指示した回数の管理を開始する。

ステップＳ１４０３において、ユーザ管理部１１２は、告知指示部６０５により、更新の許可要請を行うよう指示したソフトウェアについて、ユーザにより更新許可の入力が行われたか否かを判定する。

ステップＳ１４０３において、更新許可の入力が行われていないと判定した場合には、更新許可の入力が行われるまで待機する。一方、更新許可の入力が行われたと判定された場合には、ステップＳ１４０４に進む。

ステップＳ１４０４において、ユーザ管理部１１２は、ユーザにより更新許可の入力が行われるまでにかかった時間及びその間に告知指示部６０５が更新の許可要請を行うよう指示した回数を集計する。

ステップＳ１４０５において、ユーザ管理部１１２は、対象車両が管理対象外となったか否かを判定する。管理対象外になっていないと判定した場合には、ステップＳ１４０１に戻る。一方、管理対象外になったと判定した場合には、当該対象車両についてのユーザ管理処理を終了する。

＜１３．まとめ＞
以上の説明から明らかなように、本実施形態にかかる車両用のソフトウェア管理システムでは、
・自動運転または運転支援システムにインストールされているソフトウェアについての最新バージョンのソフトウェアを管理サーバが取得しソフトウェアＤＢに格納した場合に、更新が必要と判定する構成とした。
・更新が必要と判定した場合に、新たに取得した最新バージョンのソフトウェアが、更新に際してユーザによる許可が必要なソフトウェアであるか否かを判定する構成とした。
・ユーザによる許可が必要なソフトウェアであると判定した場合に、車両に対して、当該ソフトウェアに関連する自動運転機能または運転支援機能の一部または全部の作動を制限するための機能制限フラグのＯＮ指示を送信する構成とした。
・機能制限フラグがＯＮ状態になった後であって、次にＩＧ−ＯＮ状態になった時に、当該ソフトウェアに関連する自動運転機能または運転支援機能の一部または全部の作動を制限する処理を開始する構成とした。
・車両のユーザが、当該ソフトウェアについて更新許可の入力を行い、当該ソフトウェアによる更新が完了することで、機能制限を解除する構成とした。

上記構成によれば、ユーザは、更新許可の入力を積極的に行うことで、自動運転機能または運転支援機能の一部または全部の作動が制限されるといった事態を回避できる（あるいは制限される時間を短くすることができる）というインセンティブを得ることができる。これにより、ユーザは、更新許可の入力を積極的に行うようになる。この結果、本実施形態に係る車両用のソフトウェア管理システムによれば、更新に際してユーザによる許可が必要なソフトウェアについての早期更新を実現できる。

［第２の実施形態］
上記第１の実施形態では、ユーザによる許可が必要なソフトウェアがソフトウェアＤＢ１１３に格納され、更新が必要と判定した場合に、管理サーバ１１０が、車両に対して、機能制限フラグのＯＮ指示を送信する構成とした。また、管理サーバ１１０から機能制限フラグのＯＮ指示を受けた場合に、車両１２０において、機能制限フラグをＯＮ状態にする構成とした。

これに対して、第２の実施形態では、管理サーバ１１０から車両１２０への機能制限フラグのＯＮ指示は行わない。一方で、第２の実施形態では、ユーザによる許可が必要なソフトウェアについて、ユーザが更新許可の入力を行わなかったと判定した場合に、車両１２０が機能制限フラグをＯＮ状態にする。以下、第２の実施形態について、第１の実施形態との相違点を中心に説明する。

＜１．管理サーバにおいて実行される処理の説明＞
はじめに、管理サーバ１１０において実行される処理のうち、バージョン管理処理について説明する。

図１５及び図１６は、バージョン管理処理の流れを示すフローチャートである。図１５に示すフローチャートにおいて、図９に示すフローチャートとの相違点は、図１５の場合、ステップＳ９１０、Ｓ９１１の処理がない点である。同様に、図１６に示すフローチャートにおいて、図１０に示すフローチャートとの相違点は、図１６の場合、ステップＳ１００３の処理がない点である。本実施形態では、管理サーバ１１０から車両１２０に対して機能制限フラグのＯＮ指示を行わないためである。

＜２．車両において実行される処理の説明＞
次に、車両１２０において実行される処理（最新化処理）について説明する。図１７及び図１８は、車両における最新化処理の流れを示すフローチャートである。

図１７に示すフローチャートにおいて、図１１に示すフローチャートとの相違点は、図１７の場合、ステップＳ１１０９、Ｓ１１１０の処理がない点である。本実施形態では、管理サーバ１１０から車両１２０に対して機能制限フラグのＯＮ指示を行わないためである。

また、図１８に示すフローチャートにおいて、図１２に示すフローチャートとの相違点は、図１８の場合、ステップＳ１８０１において、機能制限フラグをＯＮにする点である。本実施形態では、管理サーバ１１０から更新の許可要請の指示を受信し、告知部７０１が許可要請画面を表示した状態で、ユーザにより更新許可の入力が行われなかったと判定した場合に、制限部７０３が機能制限フラグをＯＮ状態にする。

このように、本実施形態では、車両１２０において、ユーザによる更新許可の入力が行われたか否かに応じて、車両１２０側で機能制限フラグのＯＮまたはＯＦＦを制御する。

＜３．まとめ＞
以上の説明から明らかなように、本実施形態にかかる車両用のソフトウェア管理システムでは、
・自動運転または運転支援システムにインストールされているソフトウェアについての最新バージョンのソフトウェアを管理サーバが取得しソフトウェアＤＢに格納した場合に、更新が必要と判定する構成とした。
・更新が必要と判定した場合に、新たに取得した最新バージョンのソフトウェアが、更新に際してユーザによる許可が必要なソフトウェアであるか否かを判定する構成とした。
・ユーザによる許可が必要なソフトウェアについて、ユーザにより更新が許可されなかったと判定した場合に、当該ソフトウェアに関連する自動運転機能または運転支援機能の一部または全部の作動を制限するための機能制限フラグをＯＮ状態にする構成とした。
・機能制限フラグがＯＮ状態になった後であって、次にＩＧ−ＯＮ状態になった時に、当該ソフトウェアに関連する自動運転機能または運転支援機能の一部または全部の作動を制限する処理を開始する構成とした。
・車両のユーザが、当該ソフトウェアについて更新許可の入力を行い、当該ソフトウェアによる更新が完了することで、機能制限を解除する構成とした。

上記構成によれば、ユーザは、更新許可の入力を積極的に行うことで、自動運転機能または運転支援機能の一部または全部の作動が制限されるといった事態を回避できる（あるいは制限される時間を短くすることができる）というインセンティブを得ることができる。これにより、ユーザは、更新許可の入力を積極的に行うようになる。この結果、本実施形態に係る車両用のソフトウェア管理システムによれば、更新に際してユーザによる許可が必要なソフトウェアについての早期更新を実現できる。

［第３の実施形態］
上記第１及び第２の実施形態では、ユーザによる許可が不要なソフトウェアについては、車両がＩＧ−ＯＮ状態になったことをトリガに車両に送信する構成とした。また、ユーザによる許可が必要なソフトウェアについては、ユーザによる更新許可の入力が行われたことをトリガに車両に送信する構成とした。

これに対して、第３の実施形態では、車両の状態が、更新に適した状態になったか否かを判定し、更新に適した状態になったと判定した場合に、管理サーバから車両に対して最新バージョンのソフトウェアを送信する構成とする。これにより、車両の通信負荷を分散させることが可能となる。以下、第３の実施形態について、上記第１の実施形態との相違点を中心に説明する。

＜１．管理サーバにおいて実行される処理の説明＞
はじめに、管理サーバ１１０において実行される処理（バージョン管理処理、ソフトウェア送信処理）の流れについて説明する。

（１）バージョン管理処理
図１９及び図２０は、バージョン管理処理の流れを示すフローチャートである。図１９に示すフローチャートにおいて、図９に示すフローチャートとの相違点は、図１９の場合、ステップＳ１９０１、Ｓ１９０２、Ｓ１９０３の処理内容が、図９のステップＳ９０４、Ｓ９０８、Ｓ９１４の処理内容とは異なる点である。なお、本実施形態では、運転支援ソフトウェア情報５１０に、ソフトウェアの"更新フラグ"が格納されるものとする。更新フラグとは、運転支援システム１３２にインストールされているソフトウェアを更新することが可能な状態であることを示すフラグである。運転支援ソフトウェア情報５１０に格納される"更新フラグ"は、管理サーバ１１０より、更新フラグのＯＮ指示を受信するとＯＮ状態となり、対応するソフトウェアが最新バージョンに更新されると、ＯＦＦ状態になるものとする。

ステップＳ１９０１において、更新指示部６０６は、対象車両に対して、更新が許可されたソフトウェアの更新フラグのＯＮ指示を送信する。

ステップＳ１９０２において、更新指示部６０６は、対象車両に対して、ユーザによる許可が不要なソフトウェアについての更新フラグのＯＮ指示を送信する。

ステップＳ１９０３において、更新指示部６０６は、対象車両に対して、ユーザによる許可が必要なソフトウェアについての更新フラグのＯＮ指示を送信する。

同様に、図２０に示すフローチャートにおいて、図１０に示すフローチャートとの相違点は、図２０の場合、ステップＳ２００１の処理内容が、図１０のステップＳ１００６の処理内容とは異なる点である。

ステップＳ２００１において、更新指示部６０６は、対象車両に対して、ユーザによる許可が必要なソフトウェアについての更新フラグのＯＮ指示を送信する。

このように、本実施形態では、管理サーバ１１０が、対象車両に対してソフトウェアの送信が可能な状態になったとしても、直ちにソフトウェアを送信せずに、対象車両に対して、当該ソフトウェアについての更新フラグのＯＮ指示を送信する。

これにより、対象車両では、車両１２０において更新に適した状態になったと判定した場合に、更新フラグがＯＮ状態のソフトウェアについて、管理サーバ１１０に送信要求を行うことが可能になる。

つまり、車両１２０において、受信及び更新に適した状態になった場合に、ソフトウェアの受信及び更新を実行することが可能になる。

（２）ソフトウェア送信処理
図２１は、管理サーバ１１０のソフトウェア管理部１１１によるソフトウェア送信処理の流れを示すフローチャートである。図２１に示すソフトウェア送信処理は、バージョン管理処理と並行して実行される。

ステップＳ２１０１において、更新指示部６０６は、対象車両より、ソフトウェアの送信要求があったか否かを判定する。ステップＳ２１０１において、ソフトウェアの送信要求があったと判定した場合には、ステップＳ２１０２に進む。

ステップＳ２１０２において、更新指示部６０６は、送信要求があったソフトウェアについて、対象車両に送信するとともに、ユーザ情報ＤＢ１１４を書き換える。

＜２．車両において実行される処理の説明＞
次に、車両１２０において実行される処理（最新化準備処理、最新化処理）について説明する。

（１）最新化準備処理
図２２及び図２３は、車両１２０における最新化準備処理の流れを示すフローチャートである。

図２２のフローチャートにおいて、図１１のフローチャートとの相違点は、図２２の場合、ステップＳ２２０１〜Ｓ２２０５の処理内容が、図１１のステップＳ１１０１、１１０４、Ｓ１１０５、Ｓ１１０７、Ｓ１１０８の処理内容とは異なっている点である。

ステップＳ２２０１において、制限部７０３は、運転支援ソフトウェア情報５１０を参照し、機能制限フラグがＯＮ状態で、かつ、更新フラグがＯＦＦ状態のソフトウェアがあるか否かを判定する。

ステップＳ２２０１において、機能制限フラグがＯＮ状態で、かつ、更新フラグがＯＦＦ状態のソフトウェアがあると判定した場合には、ステップＳ１１０２に進む。一方、ステップＳ２２０１において、機能制限フラグがＯＮ状態で、かつ、更新フラグがＯＦＦ状態のソフトウェアがないと判定した場合には、ステップＳ１１０３に進む。

機能制限フラグがＯＮ状態で、更新フラグがＯＦＦ状態のソフトウェアとは、ユーザによる許可が必要なソフトウェアであると判定されて、機能制限フラグがＯＮ状態となったが、ユーザにより、更新許可の入力が行われていないソフトウェアである。

なお、機能制限フラグがＯＮ状態で、更新フラグがＯＮ状態のソフトウェアとは、ユーザによる許可が必要なソフトウェアであると判定されて、機能制限フラグがＯＮ状態となったが、ユーザによる更新許可の入力が行われたソフトウェアである。ユーザにより更新許可の入力が行われることで、更新フラグはＯＮ状態となるが、更新に適した状態になるまで更新されないため、機能制限フラグはＯＮ状態のままとなる。この場合には、機能制限は実施されない。

ステップＳ２２０２において、インストール実行部７０２は、更新が許可されたソフトウェアについての更新フラグのＯＮ指示を受信したか否かを判定する。ステップＳ２２０２において、受信したと判定した場合、ステップＳ２２０３において、インストール実行部７０２は、更新が許可されたソフトウェアについての更新フラグをＯＮ状態にする。

ステップＳ２２０４において、インストール実行部７０２は、ユーザによる許可が不要なソフトウェアについての更新フラグのＯＮ指示を受信したか否かを判定する。ステップＳ２２０４において、受信したと判定した場合、ステップＳ２２０５において、インストール実行部７０２は、ユーザによる許可が不要なソフトウェアについての更新フラグをＯＮ状態にする。

同様に、図２３に示すフローチャートにおいて、図１２に示すフローチャートとの相違点は、図２３の場合、ステップＳ２３０１、Ｓ２３０２の処理内容が、図１２のステップＳ１２０３、Ｓ１２０４の処理内容とは異なっている点である。また、図２３の場合、図１２のステップＳ１２０５、Ｓ１２０６の処理がない点である。

ステップＳ２３０１において、インストール実行部７０２は、更新が許可されたソフトウェアについての更新フラグのＯＮ指示を、管理サーバ１１０より受信したか否かを判定する。

ステップＳ２３０１において、受信したと判定した場合には、ステップＳ２３０２において、インストール実行部７０２は、更新が許可されたソフトウェアについての更新フラグをＯＮ状態にする。

（２）最新化処理
図２４は、車両１２０における最新化処理の流れを示すフローチャートである。図２４に示す最新化処理は、最新化準備処理（図２２、図２３）と並行して実行される。ただし、最新化準備処理は、車両１２０がＩＧ−ＯＮ状態になったことを条件に実行開始するのに対して、最新化処理は、車両がＩＧ−ＯＮ状態でなくてもよく、管理サーバ１１０と通信可能な状態であればよい。

ステップＳ２４０１において、インストール実行部７０２は、車両１２０が、更新に適した状態にあるか否かを判定する。ステップＳ２４０１において、更新に適した状態にあると判定した場合、ステップＳ２４０２に進む。なお、更新に適した状態とは、例えば、車両１２０が停止している状態や、駐車場等に駐車している状態、あるいは、車両１２０が電気自動車の場合にあっては、充電中の状態等が挙げられる。

ステップＳ２４０２において、インストール実行部７０２は、更新フラグがＯＮ状態のソフトウェアがあるか否かを判定する。ステップＳ２４０２において、更新フラグがＯＮ状態のソフトウェアがあると判定した場合には、ステップＳ２４０３に進む。

ステップＳ２４０３において、インストール実行部７０２は、更新フラグがＯＮ状態のソフトウェアについて、管理サーバ１１０に最新バージョンの送信要求を行う。ステップＳ２４０４において、インストール実行部７０２は、送信要求に応じて管理サーバ１１０より、最新バージョンのソフトウェアが送信された場合に、これを受信する。更に、インストール実行部７０２は、受信したソフトウェアを用いて、運転支援ソフトウェア格納部３２２に既にインストールされているソフトウェアを更新する。

ステップＳ２４０５において、制限部７０３は、機能制限フラグをＯＦＦ状態にする。なお、既に機能制限が実施されている場合にあっては、機能制限を解除する（つまり、機能制限は、機能制限フラグがＯＦＦ状態になったタイミングで解除される）。

ステップＳ２４０６において、インストール実行部７０２は、更新完了通知を、管理サーバ１１０に送信する。

＜３．まとめ＞
以上の説明から明らかなように、本実施形態にかかる車両用のソフトウェア管理システムでは、
・自動運転または運転支援システムにインストールされているソフトウェアについての最新バージョンのソフトウェアを管理サーバが取得しソフトウェアＤＢに格納した場合に、更新が必要と判定する構成とした。
・更新が必要と判定した場合に、新たに取得した最新バージョンのソフトウェアが、更新に際してユーザによる許可が必要なソフトウェアであるか否かを判定する構成とした。
・ユーザによる許可が必要なソフトウェアであると判定した場合に、車両に対して、当該ソフトウェアに関連する自動運転機能または運転支援機能の一部または全部の作動を制限するための機能制限フラグのＯＮ指示を送信する構成とした。
・機能制限フラグがＯＮ状態になった後であって、次にＩＧ−ＯＮ状態になった時に、当該ソフトウェアに関連する自動運転機能または運転支援機能の一部または全部の作動を制限する処理を開始する構成とした。
・車両のユーザが、当該ソフトウェアについて更新許可の入力を行い、当該ソフトウェアによる更新が完了することで、機能制限を解除する構成とした。
・新たに取得した最新バージョンのソフトウェアのうち、ユーザによる許可が不要なソフトウェアについては、車両がＩＧ−ＯＮ状態になった場合に、車両に対して更新フラグのＯＮ指示を送信する構成とした。また、ユーザによる許可が必要なソフトウェアについては、ユーザによる更新許可の入力が行われた場合に、車両に対して更新フラグのＯＮ指示を送信する構成とした。
・車両において、更新に適した状態になったと判定した場合に、更新フラグがＯＮ状態のソフトウェアについて、管理サーバより最新バージョンのソフトウェアを受信し、更新する構成とした。

上記構成によれば、ユーザは、更新許可の入力を積極的に行うことで、自動運転機能または運転支援機能の一部または全部の作動が制限されるといった事態を回避できる（あるいは制限される時間を短くすることができる）というインセンティブを得ることができる。これにより、ユーザは、更新許可の入力を積極的に行うようになる。この結果、本実施形態に係る車両用のソフトウェア管理システムによれば、更新に際してユーザによる許可が必要なソフトウェアについての早期更新を実現できる。

加えて、上記構成によれば、自動運転機能または運転支援機能に関するソフトウェアを、車両が更新に適した状態になった場合に実行することができる。これにより、本実施形態に係る車両用のソフトウェア管理システムによれば、車両の通信負荷を分散させることが可能となる。

［変形例］
上記第１乃至第３の実施形態では、今回のＩＧ−ＯＮ状態において機能制限フラグがＯＮ状態になった場合には、次のＩＧ−ＯＮ状態において機能制限を実施する構成とした。しかしながら、機能制限を実施するタイミングは、これに限定されない。例えば、今回のＩＧ−ＯＮ状態において機能制限フラグがＯＮ状態になったタイミングで機能制限を実施するようにしてもよいし、機能制限フラグがＯＮ状態になった後に、最初に車両１２０が停止したタイミングで機能制限を実施するようにしてもよい。いずれにしても、機能制限フラグがＯＮ状態になった後の所定のタイミングで、機能制限が開始されればよい。

また、上記第１乃至第３の実施形態では、ソフトウェア取得部６０２が最新バージョンのソフトウェアを新たに取得しソフトウェアＤＢ１１３に格納したタイミングで、ソフトウェア種類判定部６０３が判定を行う構成とした。しかしながら、ソフトウェア種類判定部６０３が判定を行うタイミングはこれに限定されず、予め定められた日時に判定を行うようにしてもよい。あるいは、対象車両がＩＧ−ＯＮ状態にある場合、または、通信可能な状態にある場合に、判定を行うようにしてもよい。

また、上記第１乃至第３の実施形態では、管理サーバ１１０のソフトウェア取得部６０２が更新要否判定手段として機能するものとして説明した。しかしながら、更新要否判定手段としての機能は、車両１２０側に配してもよい。ただし、この場合、管理サーバ１１０のソフトウェア取得部６０２では、最新バージョンのソフトウェアを取得するたびに、最新バージョンのソフトウェアを取得したことを示す情報を車両１２０に送信するものとする。あるいは、管理サーバ１１０のソフトウェア取得部６０２では、最新バージョンのソフトウェアを取得するたびに、取得したソフトウェアのバージョン情報を車両１２０に送信するものとする。

これにより、車両１２０側に配された更新要否判定手段では、ソフトウェア取得部６０２から送信された情報に基づいて、運転支援用ＥＣＵ３００にインストールされているソフトウェアについて更新の要否を判定することができる。

なお、この場合、管理サーバ１１０のソフトウェア種類判定部６０３では、当該ソフトウェアの"許可要否"に関する情報を車両１２０に送信するものとする。そして、運転支援用ＥＣＵ３００のバージョン管理部３２１の告知部７０１及び制限部７０３は、更新要否判定手段による判定結果及び送信された"許可要否"に関する情報に基づいて動作することになる。つまり、更新及び許可が必要であった場合、告知部７０１では、更新の許可要請画面を表示し、更新許可の入力を受け付け、制限部７０３では、機能制限フラグをＯＮ状態にする。なお、制限部７０３の動作はこれに限られず、上記第２の実施形態のように、許可要請画面において更新許可の入力がなされなかった場合に、機能制限フラグをＯＮ状態にするようにしてもよい。

また、上記第１乃至第３の実施形態では、ソフトウェアＤＢ１１３に新たに格納される最新バージョンのソフトウェアに、ユーザによる許可が必要なソフトウェアと、ユーザによる許可が不要なソフトウェアとが含まれるものとして説明した。しかしながら、ソフトウェアＤＢ１１３に新たに格納される最新バージョンのソフトウェアは、いずれも、ユーザによる許可が必要なソフトウェアであってもよい。その場合、ソフトウェア種類判定部６０３の機能は不要となり、機能制限フラグ制御部６０４では、ソフトウェア取得部６０２により最新バージョンのソフトウェアが取得されソフトウェアＤＢ１１３に格納されると、対象車両に対して、機能制限フラグのＯＮ指示を送信することになる。

また、上記第１乃至第３の実施形態では、車両１２０のインストール実行部７０２がソフトウェアの更新を完了した場合に、制限部７０３が機能制限フラグをＯＦＦ状態にする構成とした。しかしながら、制限部７０３は、管理サーバ１１０からの指示に基づいて、機能制限フラグをＯＦＦ状態にするように構成してもよい。具体的には、管理サーバ１１０の更新指示部６０６が車両１２０より更新完了通知を受信した場合に、機能制限フラグ制御部６０４が機能制限フラグのＯＦＦ指示を車両１２０に送信するように構成してもよい。これにより、車両１２０における機能制限フラグのＯＮ及びＯＦＦは、管理サーバ１１０によって制御されることになる。

また、上記第１乃至第３の実施形態では、機能制限フラグのＯＮ状態とＯＦＦ状態とを制御する場合について説明したが、自動運転機能または運転支援機能の一部または全部の作動を制限するにあたっては、機能制限フラグを用いなくてもよい。

例えば、自動運転機能または運転支援機能に関するソフトウェアについて更新が必要と判定された場合であって、予め定められた複数の条件が同時に成立した場合に、自動運転機能または運転支援機能の一部または全部の作動を制限するようにしてもよい。予め定められた複数の条件には、例えば、ユーザにより更新が許可されなかったことが含まれていてもよい。なお、このとき、自動運転機能または運転支援機能に関するソフトウェアについての更新の要否の判定は、管理サーバ１１０側で行われても、車両１２０側で行われてもよい。同様に、予め定められた複数の条件が同時に成立したか否かの判定は、管理サーバ１１０側で行われても、車両１２０側で行われてもよい。

あるいは、自動運転機能または運転支援機能に関するソフトウェアについて更新が必要と判定され、管理サーバ１１０から車両１２０に対して機能制限の指示が送信された場合であって、車両１２０にて機能制限を開始すると判断した場合に、自動運転機能または運転支援機能の一部または全部の作動を制限するようにしてもよい。つまり、更新の要否の判定は、管理サーバ１１０側で行い、予め定められた複数の条件が同時に成立したか否かの判定は、管理サーバ１１０側で行われてもよい。

なお、上記実施形態に挙げた構成等に、その他の要素との組み合わせなど、ここで示した構成に本発明が限定されるものではない。これらの点に関しては、本発明の趣旨を逸脱しない範囲で変更することが可能であり、その応用形態に応じて適切に定めることができる。

１００ ：車両用のソフトウェア管理システム
１１０ ：管理サーバ
１１１ ：ソフトウェア管理部
１１２ ：ユーザ管理部
１２０ ：車両
１３１ ：ＤＣＭ
１３２ ：自動運転または運転支援システム
１４０ ：携帯端末
１４１ ：更新許可部
３００ ：自動運転用または運転支援用ＥＣＵ
３２１ ：バージョン管理部
４００ ：ソフトウェア情報
４１０ ：ユーザ情報
５１０〜５３０ ：運転支援ソフトウェア情報
６０１ ：接続状態管理部
６０２ ：ソフトウェア取得部
６０３ ：ソフトウェア種類判定部
６０４ ：機能制限フラグ制御部
６０５ ：告知指示部
６０６ ：更新指示部
７０１ ：告知部
７０２ ：インストール実行部
７０３ ：制限部

Claims (6)

1. 自動運転機能または運転支援機能を有する車両と、
   前記車両にインストールされている前記自動運転機能または前記運転支援機能に関するソフトウェアを管理する管理サーバと、を有する車両用のソフトウェア管理システムであって、
   前記ソフトウェアについて更新が必要と判定され、ユーザにより更新が許可されなかった場合において、前記車両がＩＧ−ＯＦＦ状態となり、その後、前記車両がＩＧ−ＯＮ状態となったタイミングで、前記自動運転機能または前記運転支援機能の一部または全部の作動について制限を開始する制限手段、
   を有することを特徴とする車両用のソフトウェア管理システム。
2. 前記制限手段は、
   前記ソフトウェアについて更新が必要と判定され、ユーザにより更新が許可されることで、前記ソフトウェアを更新した場合に、前記制限を解除することを特徴とする請求項１に記載のソフトウェア管理システム。
3. 前記制限手段は、
   前記ソフトウェアについて更新が必要と判定された場合であって、前記ユーザに対して更新を許可するよう告知してから、所定時間内に、前記ユーザにより更新許可の入力が行われなかった場合に、制限可能な状態に移行することを特徴とする請求項１に記載のソフトウェア管理システム。
4. 前記制限手段は、
   前記自動運転機能または前記運転支援機能に含まれる複数の機能のうち、更新が必要と判定されたソフトウェアに関する機能の作動を制限することを特徴とする請求項１に記載のソフトウェア管理システム。
5. 前記ソフトウェアについて更新が必要と判定されてから、前記ユーザにより更新が許可されるまでの状況を解析する解析手段を更に有することを特徴とする請求項１に記載のソフトウェア管理システム。
6. 自動運転機能または運転支援機能を有する車両であって、
   前記車両にインストールされている前記自動運転機能または前記運転支援機能に関するソフトウェアについて更新が必要と判定され、ユーザにより更新が許可されなかった場合において、前記車両がＩＧ−ＯＦＦ状態となり、その後、前記車両がＩＧ−ＯＮ状態となったタイミングで、前記自動運転機能または前記運転支援機能の一部または全部の作動について制限を開始する、ことを特徴とする車両。

Images