JP7768005B2 - 車両制御装置、車両制御方法 - Google Patents

Description

本開示は、通信相手の正当性を認証した上で車両の施錠／開錠にかかる車両制御を実施する車両制御装置、車両制御方法に関する。

従来、車両のロック／アンロックを制御するシステムとして、車載システムがキーデバイスと無線通信を実施することで、キーデバイスの位置推定及び認証処理を実施し、車両の施錠／開錠等を自動的に実行するシステムが知られている。当該システムはスマートエントリシステム、あるいは、パッシブエントリ・パッシブスタート（ＰＥＰＳ）システムなどと呼ばれる。

特許文献１には、オートロック機能により車両を施錠した際に車内に残っているキーデバイスを認識し、当該キーデバイスを無効化する構成が開示されている。車内に残されているキーデバイスを無効化しておかないと、開錠操作に基づく車両からの探索信号に対して車内に残っているキーデバイスが応答することにより、誰でも車両を開錠可能となってしまう。キーデバイスの無効化にかかる上記制御は、そのような課題に対応している。

その他、ＰＥＰＳキーシステムとしては、車内へのキーデバイスの閉じ込め（いわゆるインロック）を防止するために、施錠操作受付時に車室内にキーデバイスが残っていることを検知した場合に、警告音等を出力する制御が導入されていることもある。

特許第５８４６０２４号公報

閉じ込め防止の警告音出力や、車内に残されたキーデバイスの無効化といった制御は、無線通信により車内にキーデバイスが残っていることを確認できていることを条件として、設計者の意図通りに（つまり正常に）動作する。

しかしながら、無線通信による位置判定や照合処理は電波環境などの影響を受けるため、車内にキーデバイスが残っているにも関わらず、当該キーデバイスが車内にあると判定されないことが起こりうる。当然、施錠時において何らかの理由により車内に残っているキーデバイスを車載システムが認識できなかった場合、とじ込み防止等の制御は機能しない。

また、近年は、リレーアタック対策やデジタルキーシステムの導入により、キーデバイスと車載システムとの認証処理が高度化／複雑化しつつある。それに伴い、様々な理由により、携帯デバイスの認証失敗が起こりうる。つまり、今後は、閉じ込め防止の警告音出力や車内に残されたキーデバイスの無効化が不作動となるケースの増大が懸念される。

本開示は、上記の検討又は着眼点に基づいて成されたものであり、その目的の１つは、車両の鍵として機能しうる携帯デバイスが実際には車内に存在するにも関わらず、認証失敗によって当該携帯デバイスが車内には存在しないと判定する恐れを低減可能な車両制御装置、車両制御方法を提供することにある。

ここに開示される車両制御装置は、車両の鍵として事前に登録されている携帯デバイスであるキーデバイスと無線通信をすることによってキーデバイスの位置を判定する車両制御装置であって、通信相手から送信されてきたデータをもとに、通信相手がキーデバイスであるか否かを判定する無線認証処理と、通信相手からの信号の受信状況に基づいて当該通信相手が車内に存在するか否かを判定する位置判定処理とを実施する、デバイス位置確認部（Ｆ３）と、デバイス位置確認部が無線認証処理にて通信相手はキーデバイスであると判定しなかった場合に、通信相手から受信したデータをもとに、通信相手がキーデバイスと判定しなかった理由である認証失敗理由を特定する失敗理由特定部（Ｆ３３）と、を備え、デバイス位置確認部は、通信相手はキーデバイスであると判定できなかった場合でも、認証失敗理由が特定理由であり、かつ、通信相手の位置は車内であると判定している場合には、キーデバイスが車内に存在すると見なすように構成されている。

また、本開示の車両制御方法は、車両の鍵として事前に登録されている携帯デバイスであるキーデバイスと無線通信をすることによってキーデバイスの位置を判定する、少なくとも１つのプロセッサによって実施される車両制御方法であって、通信相手から送信される無線信号の受信状況に基づいて当該通信相手が、車内に存在するか否かを判定するステップと、通信相手から送信されてきたデータをもとに、通信相手がキーデバイスであるか否かを判定するステップと、通信相手がキーデバイスと判定しなかった場合、受信したデータの内容をもとに、通信相手をキーデバイスと判定しなかった理由である認証失敗理由を特定するステップと、通信相手はキーデバイスと判定しなかった場合でも、認証失敗理由が特定理由であり、かつ、通信相手が車内に存在すると判定されている場合には、キーデバイスが車内に存在すると見なすステップと、を含む。

上記の装置／方法によれば、携帯デバイスの認証が失敗した場合であっても、その理由が特定のものである場合には、当該携帯デバイスが車内に存在するものと見なされる。よって、携帯デバイスが実際には車内に存在するにも関わらず、認証失敗によって携帯デバイスが車内には存在しないと判定される恐れを低減可能となる。

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

車両用デジタルキーシステムの全体像を示す図である。 携帯デバイスの構成を示すブロック図である。 デバイス制御部の機能ブロック図である。 車載システムの構成を示すブロック図である。 ＢＬＥ通信機の搭載位置の一例を示す図である。 ＢＬＥ通信機の構成を示す図である。 スマートＥＣＵの機能ブロック図である。 無線認証処理の流れを示すシーケンス図である。 携帯デバイスの作動を説明するためのフローチャートである。 閉じ込め警告処理のフローチャートである。 トランク開錠処理のフローチャートである。 残留デバイス無効化処理のフローチャートである。 ＢＬＥ通信機の他の配置例を示す図である。 車両が備える独立空間部の一例を示す図である。

以下、本開示の実施形態について図を用いて説明する。図１は、車両用デジタルキーシステムＳｙｓの概略的な構成の一例を示す図である。図１に示すように車両用デジタルキーシステムＳｙｓは、車載システム１と、携帯デバイス２と、デジタルキーサーバ（ＤＫＳ：Digital Key Server）３を含む。車載システム１は、車両Ｈｖに搭載されているシステムである。携帯デバイス２は、車両Ｈｖのユーザによって携帯されるデバイスである。携帯デバイス２は、複数存在しうる。

＜前置き＞
以下の説明における車両Ｈｖは、一例として個人によって所有される４輪自動車である。車両Ｈｖのユーザとは、所有者（オーナー）や、その家族などを指す。車両Ｈｖは、会社組織が保有する社用車や、公的機関が保有する公用車であってもよい。車両Ｈｖが社用車や公用車である場合には、当該車両Ｈｖを管理する組織に属する人物がユーザとなりうる。車両Ｈｖは、貸出サービスに供される車両（いわゆるレンタカー）であってもよいし、カーシェアリングサービスに供される車両（いわゆるシェアカー）であってもよい。車両Ｈｖが上記サービスに供される車両（以下、サービス車両）である場合には、それらのサービスの利用契約を行っており、且つ、サービスの利用予約等に基づき、一時的に当該車両Ｈｖを利用する権限を有する人物がユーザとなりうる。

車両Ｈｖは例えば電動車、より具体的には外部充電可能なハイブリッド車（いわゆるプラグインハイブリッド車）である。電動車の概念には、電気自動車の他、ハイブリッド車や、燃料電池車も含まれる。尚、ハイブリッド車は動力源としてエンジンとモータを備える車両である。他の態様として車両Ｈｖは、エンジン車であってもよい。

車両Ｈｖは、セダンタイプなどの、キャビンとトランクとが連通していないタイプの車両である。車両Ｈｖは、トランクドアを開けた状態でも全ドアのロック機構を施錠状態に設定可能に構成されている。トランクドアは、リアハッチ、ハッチバック、リアゲートなどとも呼ばれうる。

車両Ｈｖは、右側に運転席が設けられている。他の態様として、車両Ｈｖは左側に運転席が設けられた車両でも良い。以下の説明における前後、左右、上下の各方向は、基準方向に関する注釈がない場合には（つまり基本的には）、車両Ｈｖを基準として規定される。

本開示に示す種々のフローチャートは何れも一例であって、フローチャートを構成するステップの数や、処理の実行順は適宜変更可能である。その他、以下の説明は、車両Ｈｖが使用される地域の法規及び慣習に適合するように適宜変更して実施可能である。

＜全体概要＞
車載システム１及び携帯デバイス２は何れも近距離通信可能に構成されている。ここでの近距離通信とは、実質的な通信可能距離が例えば１ｍから３０ｍ、最大でも１００ｍ程度となる所定の近距離無線通信規格に準拠した通信を指す。ここでの近距離通信の規格としては、例えばBluetooth（登録商標）や、Wi-Fi（登録商標）等を採用することができる。Bluetooth規格は、Bluetooth Classicでもよいし、ＢＬＥ（Bluetooth Low Energy）でもよい。Ｗｉ－Ｆｉ規格としても、ＩＥＥＥ８０２．１１ｎや、ＩＥＥＥ８０２．１１ａｃ、ＩＥＥＥ８０２．１１ａｘ（いわゆるＷｉ－Ｆｉ６）など、多様な規格を採用可能である。尚、ＩＥＥＥ（登録商標）は、Institute of Electrical and Electronics Engineersの略であり、米国電気電子学会を指す。その他、車載システム１と携帯デバイス２との通信方式、換言すれば、近距離通信方式としては、ＵＷＢ－ＩＲ（Ultra Wide Band - Impulse Radio）も採用可能である。さらに、車載システム１と携帯デバイス２は、１２５ｋＨｚや１３４ｋＨｚなどのＬＦ（Low Frequency）帯の電波を用いて無線通信可能に構成されていても良い。

以下では、車載システム１、及び、携帯デバイス２は、ＢＬＥ規格に準拠した無線通信（以降、ＢＬＥ通信）を実施可能に構成されている場合を例にとって、各部の作動を説明する。通信接続や暗号通信の開始などといった、通信シーケンスの細部はＢＬＥ規格に従って実施される。以下におけるＢＬＥ通信との記載は、ＵＷＢ通信や近距離通信と置き換え可能である。尚、車載システム１は、携帯デバイス２と実質的にデータ通信を行う装置として、スマートＥＣＵ４を備える。ＥＣＵは、Electronic Control Unitの略であり、電子制御装置を意味する。

以下ではスマートＥＣＵ４が携帯デバイス２との通信におけるマスターとして振る舞い、携帯デバイス２がスレーブとして振る舞うように設定されている場合について説明する。スマートＥＣＵ４は携帯デバイス２からのアドバタイズ信号を受信することで、携帯デバイス２との通信接続を確立し、車両Ｈｖの周辺に携帯デバイス２（ひいてはユーザ）が存在することを検出する。アドバタイズ信号は、自分自身の存在を他のデバイスに通知（すなわちアドバタイズ）するための信号である。尚、他の態様として、携帯デバイス２がスマートＥＣＵ４との通信におけるマスターとして動作するように設定されていても良い。

尚、ＢＬＥ規格に準拠した無線信号であるＢＬＥ信号は、多様な装置から発信されうる。本開示ではＢＬＥ信号を発信するデバイスをまとめてＢＬＥデバイスと称する。ＢＬＥデバイスは、車両Ｈｖ／スマートＥＣＵ４とペアリングされている登録済みデバイスと、ペアリングがなされていない未登録デバイスに区分される。ペアリングは、少なくとも通信相手のデバイスＩＤを内部ストレージ等に登録することを指す。デバイスＩＤは、ＢＬＥデバイスの識別番号である。デバイスＩＤとしては例えばデバイスアドレスや、ＵＵＩＤ（Universally Unique Identifier）などを採用可能である。携帯デバイス２は、登録済みデバイスである。アドバタイズ信号などのＢＬＥ信号は、送信元を示すデバイスＩＤを含む。スマートＥＣＵ４は受信信号に含まれるデバイスＩＤをもとに、通信相手が携帯デバイス２か未登録デバイスかを識別可能である。

また、スマートＥＣＵ４及び携帯デバイス２は、セルラー回線又はＷｉ－Ｆｉ（登録商標）回線を用いてＤＫＳ３と通信可能に構成されている。本開示ではセルラー回線を用いた通信をセルラー通信と称する。セルラー通信とは、例えば４Ｇや５Ｇといった規格に準拠した無線通信を指す。また、Ｗｉ－Ｆｉ回線を用いたデータ通信をＷｉ－Ｆｉ通信と称する。Ｗｉ－Ｆｉの規格としては、ＩＥＥＥ８０２．１１ｎやＩＥＥＥ８０２．１１ａｃ、ＩＥＥＥ８０２．１１ａｘ（いわゆるＷｉ－Ｆｉ６）など、多様な規格を採用可能である。

ＤＫＳ３は、車両Ｈｖの外部に配置されたサーバである。ＤＫＳ３は、インターネットなどの広域通信ネットワークを介してスマートＥＣＵ４及び携帯デバイス２のそれぞれとデータ通信を行いうる。ＤＫＳ３は、携帯デバイス２からの要求に基づき、携帯デバイス２に対し、車両Ｈｖを使用するためのサービス鍵及びワンタイム認証鍵を発行する。

サービス鍵は、携帯デバイス２を車両Ｈｖの鍵として機能させるための根幹となるコードである。サービス鍵は、車両Ｈｖと携帯デバイス２の組み合わせ毎に異なる。例えばＤＫＳ３は、車両ＩＤとデバイスＩＤを結合した値を入力値とする所定のハッシュ関数の出力値をサービス鍵として発行する。車両ＩＤは車両ごとに割り当てられる固有の識別番号であって、例えば車両識別コード（ＶＩＮ：Vehicle Identification Number）などである。尚、サービス鍵は、ユーザが登録した所定文字数のパスワードそのもの、又は、当該パスワードを所定のハッシュ関数に入れた値であっても良い。

ワンタイム認証鍵は、１回使用されると破棄される、いわゆる使い捨ての認証鍵である。ワンタイム認証鍵は、スマートＥＣＵ４が通信相手の正当性、つまり、真に携帯デバイス２であることを確認するためのコードである。ワンタイム認証鍵は、サービス鍵に、変動コード（変動因子）を組み合わせることによって生成される。変動コードは、ワンタイム認証鍵の発行ごとに異なる値である。変動コードは、例えばエポック秒や、ワンタイム認証鍵の発行回数、又は乱数とすることができる。例えばワンタイム認証鍵は、サービス鍵と変動コードを所定の生成関数に入力して生成されうる。生成関数はサービス鍵と変動コードの２つの入力を取る関数である。生成関数は所定のハッシュ関数であってもよい。生成関数への入力値は、サービス鍵と変動コードを単純につなぎ合わせた（つまり連結させた）値や、それらを乗算又は加算した値であってもよい。このようなワンタイム認証鍵は、トークンとも呼ばれうる。

＜携帯デバイス２について＞
携帯デバイス２は、ＢＬＥ通信機能を備えた、携帯可能かつ汎用的な情報処理端末である。携帯デバイス２としては、例えば、スマートフォンや、ウェアラブルデバイス等など、多様な通信端末を採用することができる。ウェアラブルデバイスは、ユーザの身体に装着されて使用されるデバイスであって、リストバンド型、腕時計型、指輪型、メガネ型、イヤホン型など、多様な形状のものを採用可能である。尚、本開示の携帯デバイス２は、スマートフォンなどの母艦（主機）と、ウェアラブルデバイスとに分けて実現されていても良い。

携帯デバイス２は、図２に示すようにデバイス制御部２０、ディスプレイ２１、タッチパネル２２、加速度センサ２３、生体認証装置２４、ＢＬＥ通信部２５、セルラー通信部２６、及びＷｉ－Ｆｉ通信部２７を備える。

デバイス制御部２０は、携帯デバイス２全体の動作を制御するモジュールである。デバイス制御部２０は、例えばデバイスプロセッサ２０１、ＲＡＭ（Random Access Memory）２０２、ストレージ２０３等を備えた、コンピュータとして構成されている。デバイスプロセッサ２０１は、例えばＣＰＵ（Central Processing Unit）である。ＲＡＭ２０２は揮発性の記憶媒体である。ストレージ２０３は、フラッシュメモリ等の不揮発性の記憶媒体を含む構成である。

また、デバイス制御部２０は、アプリケーションソフトウェア（以降、アプリ）としてデジタルキーアプリ２０４を備える。デジタルキーアプリ２０４は、ユーザの認証や、サービス鍵の取得／保存、スマートＥＣＵ４との通信等をセキュアに行うためのアプリである。デジタルキーアプリ２０４は、例えばストレージ２０３などにインストールされている。

ディスプレイ２１は、例えば液晶ディスプレイや有機ＥＬディスプレイである。ディスプレイ２１はデバイス制御部２０からの入力信号に応じた画像を表示する。タッチパネル２２は、静電容量式のタッチパネルであって、ディスプレイ２１に積層されている。タッチパネル２２は携帯デバイス２が備える入力装置である。タッチパネル２２及びディスプレイ２１は、ユーザがデジタルキーアプリ２０４にログインするためのパスワードを携帯デバイス２に入力したり、携帯デバイス２とスマートＥＣＵ４とをペアリングしたりするためのインターフェースに相当する。

加速度センサ２３は、携帯デバイス２に作用する加速度を検出するセンサである。加速度センサ２３の出力（検出データ）はデバイス制御部２０に入力される。加速度センサ２３の出力信号は、携帯デバイス２が携帯状態か放置状態かを示す信号として機能する。携帯状態とは、ユーザとともに移動したり、ユーザによって操作されたりしている状態を指す。放置状態とは、ユーザが携帯デバイス２を携帯していない状態、例えば、携帯デバイス２が安定した場所に所定時間以上置かれている状態を指す。安定した場所とは、机の上やカウンター、棚、床などを指す。駐車された車の座席やコンソールボックス、トランクなども安定した場所になりうる。

生体認証装置２４は、例えばユーザの指紋や、顔画像などを用いて、ユーザを認証する装置である。生体認証装置２４は、手や指の静脈パターンや、虹彩パターン、声紋などを用いてユーザを認証する装置であってもよい。ユーザの認証結果は、デバイス制御部２０に提供される。

ＢＬＥ通信部２５は、ＢＬＥ通信を実施するための通信モジュールである。セルラー通信部２６は、セルラー通信を実施するための通信モジュールである。Ｗｉ－Ｆｉ通信部２７は、Ｗｉ－Ｆｉ通信を実施するための通信モジュールである。種々の通信モジュールは、送受信の対象とする周波数帯の電波を送受信可能なアンテナや、通信を制御するマイクロコンピュータである通信マイコン、変復調回路などを備える。セルラー通信部２６及びＷｉ－Ｆｉ通信部２７は任意の要素であって省略されても良い。

デバイス制御部２０は、デバイスプロセッサ２０１がデジタルキーアプリ２０４を実行することで発現される機能部として図３に示すようにワンタイム認証鍵管理部Ｇ１、及び車両応答部Ｇ２を備える。

また、デバイス制御部２０は鍵情報記憶部ＫｙＭを備える。鍵情報記憶部ＫｙＭは、ストレージ２０３又はＲＡＭ２０２が備える記憶領域を用いて実現される。鍵情報記憶部ＫｙＭは、ＤＫＳ３で発行された自装置向け用のサービス鍵や、ワンタイム認証鍵、ユーザＩＤなどを格納するための記憶領域である。

ワンタイム認証鍵管理部Ｇ１は、ワンタイム認証鍵をＤＫＳ３から取得し、鍵情報記憶部ＫｙＭに保存する。ワンタイム認証鍵管理部Ｇ１は、鍵情報記憶部ＫｙＭに、所定数以上のワンタイム認証鍵が保存されている状態が維持されるよう、ＤＫＳ３に対してワンタイム認証鍵の配信を要求する信号を随時送信する。例えばワンタイム認証鍵管理部Ｇ１は、鍵情報記憶部ＫｙＭに保存されているワンタイム認証鍵の残数が所定の補充閾値未満となったことに基づいて、補充要否フラグをオンに設定する。ワンタイム認証鍵管理部Ｇ１は、補充要否フラグがオンに設定されており、且つ、オンライン状態であることに基づいて、ＤＫＳ３から複数のワンタイム認証鍵をダウンロードする。補充閾値は例えば１５０や３００とすることができる。

尚、ＤＫＳ３は、ワンタイム認証鍵と変動コードをセットで配信する。つまり、ワンタイム認証鍵管理部Ｇ１は、個々のワンタイム認証鍵を、当該ワンタイムの生成に使用された変動コードと紐付けられた状態でＤＫＳ３から取得する。ワンタイム認証鍵管理部Ｇ１そのものは、ワンタイム認証鍵を生成する機能を備えない。当該構成によればワンタイム認証鍵の生成方法の詳細を秘匿化することができる。ひいては車両用デジタルキーシステムＳｙｓのセキュリティ性能を高めることができる。

車両応答部Ｇ２は、スマートＥＣＵ４とＢＬＥ通信のリンク（コネクション）が確立したことに基づいて、スマートＥＣＵ４とＢＬＥによるデータ通信を実行する構成である。例えば車両応答部Ｇ２は、スマートＥＣＵ４とＢＬＥ通信リンクが確立したことに基づいて、認証のための無線通信を実施する。スマートＥＣＵ４－携帯デバイス２間の無線認証処理は例えばチャレンジ－レスポンス方式によって実施されうる。その場合、車両応答部Ｇ２は、スマートＥＣＵ４から送信されてきたチャレンジコードに対して、ワンタイム認証鍵を用いてレスポンスコードを生成し、スマートＥＣＵ４に返送する。

デバイス制御部２０は、加速度センサ２３からの信号に基づき携帯デバイス２が携帯状態か放置状態かを判定する。例えばデバイス制御部２０は静止状態が所定の放置判定時間以上継続したことに基づいて、デバイス制御部２０は放置状態と判定する。静止状態は、加速度センサ２３から所定値以上の加速度が検出されていない状態である。放置判定時間は例えば３分や５分に設定されている。放置状態と判定している場合には、車両応答部Ｇ２は車両Ｈｖに対してレスポンスコードを返送しない。放置判定時間が短いほど、不用意に携帯デバイス２がスマートＥＣＵ４からの呼びかけに応答する可能性を低減できるためセキュリティ性や節電性能を高められる。尚、デバイス制御部２０は、所定値以上の加速度が検知された場合に携帯状態と判定する。携帯状態との判定結果は、放置状態に移行したと判定されるまで維持されうる。

また、デバイス制御部２０は、デジタルキーアプリ２０４起動時にユーザ認証処理を実施する。ユーザ認証（ログイン）は、デジタルキーアプリ２０４に対して所定のユーザＩＤとパスワードを入力することによって行われうる。ユーザの認証は、生体認証装置２４を用いて実施されても良い。デジタルキーアプリ２０４は車両用デジタルキーシステムＳｙｓの一部であるため、デジタルキーアプリ２０４にユーザがログインしている状態は、車両用デジタルキーシステムＳｙｓにユーザがログインしている状態に対応する。このようにデバイス制御部２０は、生体情報又はパスワードを用いて操作者（つまりユーザ）の正当性を判断するユーザ認証機能を備える。

尚、ログイン状態はログイン時刻又は最終操作時刻から所定の有効期限が過ぎた場合や携帯デバイス２がシャットダウンされた場合に解除される。つまり、デジタルキーアプリ２０４は、所定の条件でログオフ状態に遷移する。ログオフ状態は、ユーザの再認証が必要な状態である。本開示では、生体情報又はパスワードを用いて携帯デバイス２／デジタルキーアプリ２０４がユーザを認証している状態のことをユーザ認証状態と称する。

その他、デバイス制御部２０は、デジタルキーアプリ２０４の機能として、車両Ｈｖのステータスを確認する画面である車両状態確認画面を表示可能に構成されていてもよい。車両状態確認画面は、ガソリン／バッテリの残量や、各窓及び各ドアの開閉状態、施錠状態、車内温度などを示す画面である。また、デバイス制御部２０は、車両Ｈｖが備える電装設備の一部を遠隔操作可能に構成されていても良い。例えばデバイス制御部２０は、タッチパネル２２に対するユーザ操作に基づき、車両Ｈｖの施錠／開錠や、空調装置のオン／オフ、窓の開閉、ハザードランプの消灯などを指示する無線信号を送信しうる。便宜上、車両Ｈｖを施錠するための指示信号を施錠指示信号と称する。

尚、携帯デバイス２は、車両Ｈｖの電子キーとしての専用デバイスであるスマートキーであってもよい。スマートキーは、車両Ｈｖの購入時に、車両Ｈｖとともにオーナに譲渡されるデバイスである。スマートキーは車両Ｈｖの付属物の１つと解することができる。スマートキーは、扁平な直方体型や、扁平な楕円体型（いわゆるフォブタイプ）、カード型など、多様な形状を採用可能である。スマートキーは、車両用携帯機、キーフォブ、キーカード、アクセスキーなどと呼ばれうる。

＜車載システム１の構成について＞
ここでは、車載システム１の構成及び作動について述べる。車載システム１は、図４に示すように、スマートＥＣＵ４、複数の施開錠センサ５、スタートスイッチ６、及び、複数のＢＬＥ通信機７を備える。また、車載システム１は、電源ＥＣＵ１１、ボディＥＣＵ１２、ボディ系アクチュエータ１３、ボディ系センサ１４、通知ＥＣＵ１５、車載ディスプレイ１６、警音器１７、及び広域通信機１８を備える。

スマートＥＣＵ４は、施開錠センサ５、スタートスイッチ６、及びＢＬＥ通信機７のそれぞれと専用の信号線で接続されている。また、スマートＥＣＵ４は、電源ＥＣＵ１１やボディＥＣＵ１２などと、車両内ネットワークＮｗを介して相互通信可能に接続されている。車両内ネットワークＮｗは、車両Ｈｖ内に構築されている通信ネットワークである。車両内ネットワークＮｗの規格としては、多様な規格を採用可能である。図４に示す装置同士の接続形態は一例であって、具体的な装置同士の接続態様は適宜変更可能である。

スマートＥＣＵ４は、ＢＬＥ通信機７等との協働により、車両Ｈｖに対するデバイス位置を判定するとともに、デバイス位置の判定結果に応じた車両制御を実施するＥＣＵである。本開示でのデバイス位置とは、携帯デバイス２の位置を意味する。携帯デバイス２は、ユーザに対応するものであるため、デバイス位置を判定することは、ユーザの位置を判定することに相当する。スマートＥＣＵ４は、例えばインストゥルメントパネル内に配置されている。スマートＥＣＵ４は、右側又は左側のＣピラーの室内側面に取り付けられていてもよい。Ｃピラーは、車両Ｈｖが備えるピラーのうち、前から３番目のピラーを指す。

スマートＥＣＵ４は、コンピュータを用いて実現されている。すなわち、スマートＥＣＵ４は、プロセッサ４１、ＲＡＭ４２、ストレージ４３、Ｉ／Ｏ４４、及びこれらの構成を接続するバスラインなどを備えている。本実施形態のスマートＥＣＵ４は、１つのＢＬＥ通信機７を筐体内に備える。

ストレージ４３は、フラッシュメモリ等の不揮発性の記憶媒体を含む構成である。ストレージ４３には、プロセッサ４１によって実行される制御プログラムが格納されている。制御プログラムは、携帯デバイス２の位置を判定するプログラムであるデバイス位置確認プログラムを含む。プロセッサ４１は、ＲＡＭ４２へのアクセスにより、後述する各機能部の機能を実現するための種々の処理を実行する。プロセッサ４１が制御プログラムを実行することは、当該制御プログラムに対応する車両制御方法が実行されることに相当する。Ｉ／Ｏ４４は、他装置と通信するための回路モジュールである。

ストレージ４３には、携帯デバイス２毎のデバイスＩＤが保存されている。また、ストレージ４３には、各ＢＬＥ通信機７の車両Ｈｖにおける搭載位置を示す通信機設定データが格納されている。各ＢＬＥ通信機７の搭載位置は、例えば、車両Ｈｖの任意の位置を中心とし、車両Ｈｖの幅方向及び前後方向の両方に平行な２次元座標系である車両座標系上の点として表現されうる。車両座標系を形成するＸ軸は車幅方向に平行に設定し、Ｙ軸は車両の前後方向に平行に設定可能である。座標系の中心としては、例えば、車体の中心、スマートＥＣＵ４の取り付け位置など任意の箇所を採用可能である。スマートＥＣＵ４の詳細については別途後述する。

施開錠センサ５は、ユーザが車両Ｈｖのドアを開錠及び施錠するためのタッチセンサである。施開錠センサ５は、各ドアに設けられている外側ドアハンドルに設けられている。外側ドアハンドルとは、ドアの外側面に設けられた、ドアを開閉するための把持部材を指す。施開錠センサ５は、トランクのドアハンドルを含む全ドアハンドルに設けられている。施開錠センサ５は、ユーザにタッチされたことを静電容量の変化あるいは圧力の変化から検出し、その旨を示す電気信号をスマートＥＣＵ４に出力する。尚、ユーザの開錠指示及び施錠指示の少なくとも何れか一方を受け付けるための構成としては、ボタン／スイッチを採用することもできる。施開錠用のボタンは、施開錠センサ５の代わりに、又は、施開錠センサ５とともに各ドアハンドルに設けられうる。本開示の施開錠センサ５は、施開錠用のドアボタンと読み替える事ができる。

スタートスイッチ６は、ユーザが走行用電源をオン／オフを切り替えるためのプッシュスイッチである。走行用電源は、車両Ｈｖが走行するための電源であって、車両がエンジン車である場合にはイグニッション電源を指す。車両Ｈｖが電動車である場合、走行用電源とはシステムメインリレーを指す。スタートスイッチ６は、ユーザによってプッシュ操作がされると、その旨を示す電気信号をスマートＥＣＵ４に出力する。スタートスイッチ６は始動スイッチと読み替えることができる。

ＢＬＥ通信機７は、ＢＬＥ通信を実施するための通信モジュールである。ＢＬＥ通信機７は、車両Ｈｖに複数設けられている。本実施形態の車載システム１は図５に示すように、ＢＬＥ通信機７として、ＢＬＥ通信機７ａ、７ｂ、７ｃ、７ｐ、及び７ｘを備える。ＢＬＥ通信機７ｘはスマートＥＣＵ４に内蔵されている一方、他のＢＬＥ通信機７はスマートＥＣＵ４の外部に配置されている。スマートＥＣＵ４の外部に設けられている各ＢＬＥ通信機７は、専用の通信線又は車両内ネットワークＮｗを介してスマートＥＣＵ４と相互通信可能に接続されている。

各ＢＬＥ通信機７は、スマートＥＣＵ４からの制御信号に基づいて動作する。また、各ＢＬＥ通信機７は受信データや、携帯デバイス２からの信号の受信状況に関するデータをスマートＥＣＵ４に提供する。本開示では、携帯デバイス２からの信号のことを、デバイス信号とも記載する。各ＢＬＥ通信機７には固有の通信機番号が設定されている。通信機番号は、複数のＢＬＥ通信機７を識別するための情報として機能する。

電源ＥＣＵ１１は、車両Ｈｖに搭載された走行用電源のオンオフ状態を制御するＥＣＵである。例えば電源ＥＣＵ１１は、例えばスマートＥＣＵ４からの要求信号に基づき、走行用電源をオフからオンに切り替える。尚、車両Ｈｖがエンジン車である場合には、電源ＥＣＵ１１はスマートＥＣＵ４からの指示信号に基づきエンジンを始動させる。

ボディＥＣＵ１２は、スマートＥＣＵ４やユーザからの要求に基づいて、ボディ系アクチュエータ１３を制御するＥＣＵである。ボディＥＣＵ１２は、種々のボディ系アクチュエータ１３や、種々のボディ系センサ１４と通信可能に接続されている。ここでのボディ系アクチュエータ１３とは、例えば、各ドアのロック機構を構成するドアロックモータである。ボディ系センサ１４には、ドア毎に配置されているカーテシスイッチなどが含まれる。カーテシスイッチは、ドアの開閉を検出するセンサである。ボディＥＣＵ１２は、例えばスマートＥＣＵ４からの要求に基づいて、車両Ｈｖの各ドアに設けられたドアロックモータに所定の制御信号を出力することで各ドアのロック機構を開錠状態から施錠状態に切り替えたり、その逆の制御を実施する。

通知ＥＣＵ１５は、車載ディスプレイ１６や警音器１７を用いて、携帯デバイス２の閉じ込めを警告する。閉じ込めは、ユーザに携帯デバイス２を車内に残したまま施錠することを指す。閉じ込めはインロックなどとも称される。車載ディスプレイ１６は、例えば液晶ディスプレイや有機ＥＬディスプレイである。車載ディスプレイ１６は、例えばインストゥルメントパネルの車幅方向の中央領域、又は、運転席の正面領域に配置されている。警音器１７は、車外に向けて警告音を出力する装置である。

通知ＥＣＵ１５は、スマートＥＣＵ４からの要求に基づき、車載ディスプレイ１６に警告メッセージを表示したり、警音器１７を作動させたりする。警告メッセージは例えば、「トランクに携帯デバイスが残っています」といったメッセージである。車載システム１は、警音器１７の代わりに／並列的に、車外の例えばトランクドア付近に向けて音声メッセージを出力可能なスピーカを備えていても良い。その場合には、警告音とともに／その代わりに、警告メッセージを音声出力しても良い。

広域通信機１８は、セルラー回線又はＷｉ－Ｆｉ回線を用いて広域通信ネットワークに接続するための通信設備である。広域通信機１８は、スマートＥＣＵ４がＤＫＳ３とデータ通信を実施するためのインターフェースとして機能しうる。

＜ＢＬＥ通信機の構成について＞
ここでは各ＢＬＥ通信機７の構成について説明する。各ＢＬＥ通信機７は、図６に示すようにアンテナ７１、送受信部７２、及びコントローラ７３を備える。アンテナ７１は、ＢＬＥ通信に用いられる周波数帯、すなわち２．４ＧＨｚ帯の電波を送受信するための金属エレメントである。アンテナ７１は送受信部７２と電気的に接続されている。アンテナ７１は複数のアンテナ素子を並べてなるアレーアンテナとして構成されていても良い。

送受信部７２は、ＢＬＥ信号の送信、及び、ＢＬＥ信号の受信の少なくとも何れか一方に係る信号処理を実施する回路モジュールである。送受信部７２は、変調、復調、周波数変換、増幅、デジタルアナログ変換、及び検波の少なくとも何れか１つを実施する。送受信部７２は、例えばＩＣとして実現されている。送受信部７２は、コントローラ７３と接続されている。送受信部７２は、変復調回路の他に、受信強度検出部７２１及び測距処理部７２２を備える。

受信強度検出部７２１は、アンテナ７１で受信した信号の強度を逐次検出する構成である。受信強度検出部７２１が検出する受信強度を示す信号又はその測定値そのものは、ＲＳＳＩ（Received Signal Strength Indicator/Indication）とも呼ばれうる。受信強度検出部７２１が検出した受信強度は、受信信号の送信元を示すデバイスＩＤ及び受信信号の周波数情報とともにコントローラ７３に向けて出力される。

測距処理部７２２は、通信相手と測距通信を実施することにより、ＢＬＥ通信機７から通信相手までの距離を示す測距値を生成する。ここでの測距値とは、携帯デバイス２から送信された信号がＢＬＥ通信機７で受信されるまでの信号の飛行時間を示すパラメータである。測距値は、受信強度とは異なるパラメータである。測距値とは、具体的には、ラウンドトリップ時間（ＲＴＴ：Round-Trip Time）又は２周波位相差である。測距通信とは、ＲＴＴ又は２周波位相差を測定するための通信と言い換えることができる。測距値は、片道分又は往復分の信号飛行時間（ＴｏＦ：Time of Flight）を示すため、ＴｏＦ関連値と呼ぶことができる。

尚、ＲＴＴは、通信相手に向けて応答要求信号を送信してから、通信相手からの応答信号を受信するまでの時間である。測距処理部７２２は、実際に信号を送信してから受信するまでの経過時間に対して、携帯デバイス２で生じる応答処理時間の想定値やＢＬＥ通信機７で生じうる遅延時間の想定値を減算するなどの所定の補正処理を施した値をＲＴＴとして用いてもよい。また、２周波位相差は、ＢＬＥ通信機７と携帯デバイス２とが連続波（ＣＷ：Continuous Wave）信号を送受信することで特定されるパラメータであって、２つの周波数のそれぞれで観測された送受信位相差の差である。２周波位相差は、周波数の変化による送受信位相差の変位量に対応する。

ＢＬＥ通信機７は、スマートＥＣＵ４からの指示に基づき、携帯デバイス２と測距通信を実施し、測距値を生成してプロセッサ４１に報告する。本実施形態ではより好ましい態様として、測距処理部７２２は、ＲＴＴと２周波位相差の両方を算出する。また、測距処理部７２２は、２周波位相差に関しては、ＢＬＥ通信に供される周波数の組み合わせごとに算出する。尚、測距値の生成（演算）は、コントローラ７３又はスマートＥＣＵ４が実施しても良い。例えば測距処理部７２２が周波数ごとの送受信位相差を特定し、スマートＥＣＵ４が周波数ごとの送受信位相差に基づいて、周波数の組み合わせごとの２周波位相差を算出しても良い。ＢＬＥ通信機７とスマートＥＣＵ４との機能分担は適宜変更可能である。

コントローラ７３は、スマートＥＣＵ４とのデータの受け渡しを制御するマイクロコンピュータである。コントローラ７３は、送受信部７２から入力された受信データを順次又はスマートＥＣＵ４からの要求に基づいてスマートＥＣＵ４に提供する。コントローラ７３は、スマートＥＣＵ４からの要求に基づいて、又は自発的に、携帯デバイス２からの信号の受信状況や測距値に関するデータをスマートＥＣＵ４に出力する。受信状況を示すデータには、デバイスＩＤごと及び周波数ごとの受信強度も含まれる。

＜ＢＬＥ通信機の搭載位置及び役割について＞
本実施形態の車載システム１は図５に示すように、ＢＬＥ通信機７ａ、７ｂ、７ｃ、７ｐ、及び７ｘを備える。ＢＬＥ通信機７ａは運転席用の外側ドアハンドルに設けられている。ＢＬＥ通信機７ｂは助手席用の外側ドアハンドルに設けられている。ＢＬＥ通信機７ｃはトランクドア付近に設けられている。ＢＬＥ通信機７ａ、７ｂ、及び７ｃは、車両Ｈｖに外面部に配置されたＢＬＥ通信機７である室外機に相当する。ＢＬＥ通信機７ｐは、車室内に配置されたＢＬＥ通信機７である。ＢＬＥ通信機７ｐは、例えばインストゥルメントパネルの車幅方向中央部に配置されている。ＢＬＥ通信機７ｐは室内機と呼ぶことができる。

ＢＬＥ通信機７ｘは、スマートＥＣＵ４に内蔵されているＢＬＥ通信機７である。ＢＬＥ通信機７ｘは、携帯デバイス２とのデータ通信に使用される。本開示では携帯デバイス２とのデータ通信に使用される通信機をゲートウェイ通信機とも称する。ゲートウェイ通信機は、代表機、データ通信機などと言い換えることもできる。尚、ＢＬＥ通信機７ｘはスマートＥＣＵ４の筐体外に配置されていても良い。ゲートウェイ通信機の設定はスマートＥＣＵ４によって動的に変更されても良い。

ＢＬＥ通信機７ｘは、携帯デバイス２からのアドバタイズ信号を受信すると、保存済みのデバイス情報を用いて自動的に携帯デバイス２との通信接続を確立する。通信接続確立後、スマートＥＣＵ４は携帯デバイス２と暗号化されたデータ通信を開始する。尚、ＢＬＥ通信機７ｘは、携帯デバイス２との通信接続を確立すると、通信接続している携帯デバイス２のデバイスＩＤを接続デバイス情報としてプロセッサ４１に提供する。

スマートＥＣＵ４は、ＢＬＥ通信機７ｘ以外のＢＬＥ通信機７を、デバイス位置を判定するための（つまり位置判定用の）通信機として使用する。位置判定用のＢＬＥ通信機７とは、１つの局面においては、携帯デバイス２との距離を測定するためのＢＬＥ通信機７に相当する。位置判定用のＢＬＥ通信機７のことを本開示では観測機とも称する。本実施形態ではＢＬＥ通信機７ａ、ＢＬＥ通信機７ｂ、ＢＬＥ通信機７ｃ、及びＢＬＥ通信機７ｐが観測機に相当する。尚、観測機は、測距機、あるいはサテライト通信機と呼ぶこともできる。

尚、ＢＬＥ通信では、デバイス間の通信接続が確立している状態では、３７個のチャンネルを逐次変更しながらデータの送受信を実施する。すなわち、コネクション確立後のデータ通信時は周波数ホッピングが行われる。そのため、通常は、通信接続しているＢＬＥ通信機７ｘしか携帯デバイス２からのデータ信号を捕捉できない。観測機はデバイス信号を観測できなくなる。そのような事情に対応する構成として、本実施形態のＢＬＥ通信機７ｘは、スマートＥＣＵ４に対して、携帯デバイス２との通信に使用するチャンネルを示す情報（以降、チャンネル情報）を逐次提供する。

スマートＥＣＵ４は、ＢＬＥ通信機７ｘから取得したチャンネル情報及びデバイスＩＤを、各観測機に参照情報として配信する。各観測機は、参照情報に示されるチャンネル情報によって、ＢＬＥで使用可能な多数のチャンネルのうち、何れのチャンネルを受信すれば、デバイス信号を受信できるのかを認識可能となる。その結果、観測機は、通信接続せずともデバイス信号の受信強度等を検出及び報告可能となる。

携帯デバイス２からゲートウェイ通信機に向けて送られた信号の観測機での受信状況に基づいてデバイス位置を判定する方式を、本開示ではスニッフィング方式とも称する。スニッフィング方式によれば、携帯デバイス２が通信接続するＢＬＥ通信機７を最小で１台に抑制可能となるため、携帯デバイス２での消費電力を抑制可能となる。また、スニッフィング方式によれば複数のＢＬＥ通信機７から携帯デバイス２までの距離を示す指標を並列的に収集可能となるため、携帯デバイス２を所持したユーザの接近に対するシステム応答性を高めることができる。もちろん、他の態様としては、各ＢＬＥ通信機７が個別に携帯デバイス２と双方向通信を実施し、受信強度や測距値などの情報をスマートＥＣＵ４に送信するように構成されていてもよい。

＜スマートＥＣＵ４の機能について＞
ここではスマートＥＣＵ４の機能及び作動について説明する。スマートＥＣＵ４は、ストレージ４３に保存されているプログラムを実行することにより、図７に示す種々の機能ブロックに対応する機能を提供する。すなわち、スマートＥＣＵ４は機能部として、車両情報取得部Ｆ１、通信制御部Ｆ２、デバイス位置確認部Ｆ３、及び応答処理部Ｆ４を備える。また、スマートＥＣＵ４は、デバイス情報記憶部ＤｖＭを備える。

デバイス情報記憶部ＤｖＭは、車両Ｈｖの電子キーとして利用される携帯デバイス２の情報を保存するための記憶媒体である。デバイス情報記憶部ＤｖＭは、ストレージ４３が備える記憶領域の一部を用いて実現されている。尚、デバイス情報記憶部ＤｖＭは、ストレージ４３とは物理的に独立した不揮発性の記憶媒体を用いて実現されていても良い。デバイス情報記憶部ＤｖＭはプロセッサ４１によるデータの書き込み、読出、削除等が実施可能に構成されている。

デバイス情報記憶部ＤｖＭには少なくとも１つの携帯デバイス２についての情報が保存されている。デバイス情報記憶部ＤｖＭには、携帯デバイス２毎のデバイスＩＤが、サービス鍵、ユーザＩＤなどと対応づけられて保存されている。ユーザＩＤは複数のユーザを識別するための識別子であってユーザごとに設定される。

プロセッサ４１は、広域通信機１８を介して、或る携帯デバイス２に対してＤＫＳ３が発行したサービス鍵を取得し、当該携帯デバイス２のデバイスＩＤ等と紐付けてデバイス情報記憶部ＤｖＭに保存する。尚、プロセッサ４１は、広域通信機１８経由ではなく、携帯デバイス２を介してＤＫＳ３が発行したサービス鍵に関するデータを取得し、デバイス情報記憶部ＤｖＭに保存してもよい。携帯デバイス２のデバイスＩＤ等は、ＢＬＥのペアリングにより取得及び登録される。

車両情報取得部Ｆ１は、車両Ｈｖに搭載されたセンサやＥＣＵ、スイッチなどから、車両Ｈｖの状態、及び、車両Ｈｖに対するユーザの操作を示す種々の車両情報を取得する。車両情報には、例えば走行用電源の状態（オン／オフ）や、各ドアの開閉状態、各ドアの施錠／開錠状態、施開錠センサ５及びスタートスイッチ６へのユーザの操作状態、シフトポジション等が含まれる。尚、施開錠センサ５やスタートスイッチ６からの電気信号を取得することは、これらの操作部材に対するユーザ操作を検出することに相当する。車両情報取得部Ｆ１は、１つの局面において施開錠センサ５のタッチや、ドアの開閉、スタートスイッチ６の押下などといった、車両Ｈｖに対するユーザの操作を検出する構成に相当する。

通信制御部Ｆ２は、車載システム１が備えるＢＬＥ通信機７の動作を制御する。通信制御部Ｆ２は、例えばユーザの登録時などにおいて、ＢＬＥ通信機７ｘを用いて、携帯デバイス２と鍵交換プロトコルの実行、いわゆるペアリング／ボンディングを実施する。ペアリングによって取得した携帯デバイス２についての情報であるデバイス情報は、ストレージ４３に保存されるとともに、各ＢＬＥ通信機７のコントローラ７３が備える不揮発性のメモリにも保存される。デバイス情報とは、例えば、ペアリングによって交換した暗号通信用／通信接続用の鍵や、デバイスＩＤなどである。

通信制御部Ｆ２は、ＢＬＥ通信機７ｘから、通信接続している携帯デバイス２のデバイスＩＤを取得する。スマートＥＣＵ４は、受信したデバイスＩＤに基づいて車両Ｈｖ周辺に存在するユーザを特定する。尚、車両Ｈｖが複数のユーザによって共用される場合には、各ユーザが保有する携帯デバイス２のそれぞれについてのデバイス情報が保存される。また、車両Ｈｖがサービス車両である場合、スマートＥＣＵ４は、ＤＫＳ３／それと連携する他のサーバから、利用予約しているユーザに対応するデバイス情報を事前に取得して所定の記憶媒体に一時的保管しても良い。

通信制御部Ｆ２は、ＢＬＥ通信機７ｘを介して携帯デバイス２から送信されてくる信号、例えばアドバタイズ信号を受信することで、携帯デバイス２が車載システム１と近距離通信可能な範囲内に存在することを検出し、通信接続にかかるシーケンスを実行する。ＢＬＥ通信機７ｘと携帯デバイス２との通信接続が確立している場合、通信制御部Ｆ２は、ＢＬＥ通信機７ｘを用いて携帯デバイス２とデータ通信を実施する。

その他、通信制御部Ｆ２は、各ＢＬＥ通信機７から、デバイス信号の周波数ごとの受信強度や、測距値を取得する。複数のＢＬＥ通信機７のそれぞれから提供される受信強度や測距値といった観測データは、デバイスＩＤや提供元の通信機ＩＤと紐付けられてＲＡＭ４２に保存される。通信制御部Ｆ２は、デバイス位置判定のために各ＢＬＥ通信機７に順番に携帯デバイス２と測距通信を実施させても良い。

デバイス位置確認部Ｆ３は、携帯デバイス２の位置を判定するモジュールである。本開示におけるデバイス位置確認部Ｆ３は、主として、トランク内に認証済みの携帯デバイス２が存在するか否かを判定する。デバイス位置確認部Ｆ３はサブ機能部として、無線認証部Ｆ３１、位置判定部Ｆ３２、及び失敗理由特定部Ｆ３３を備える。

無線認証部Ｆ３１は、ＢＬＥ通信機７ｘと連携して、通信相手の正当性、つまり通信相手が真に携帯デバイス２であることを確認（換言すれば認証）する処理を実施する。認証のための通信は、暗号化されて実施される。本実施形態の無線認証部Ｆ３１は一例として、チャレンジコードとワンタイム認証鍵を用いたチャレンジ－レスポンス方式で携帯デバイス２（通信相手）を認証する。無線認証処理の詳細なシーケンスについては別途後述する。尚、無線認証部Ｆ３１は、無線認証処理で必要となるワンタイム認証鍵を動的に生成する一時鍵生成部Ｆ３１１をさらなるサブ機能部として備える。一時鍵生成部Ｆ３１１は任意の要素であって省略されても良い。

本実施形態のスマートＥＣＵ４は、セキュリティ向上のため、無線認証処理が成功して初めて通信相手が真に携帯デバイス２であると判定し、施錠や開錠といった、種々の車両制御を実行する。換言すれば、本実施形態のスマートＥＣＵ４は、通信相手が真に携帯デバイス２であったとしても原則、無線認証処理が成功していない場合には、当該携帯デバイス２を車両Ｈｖの鍵としては機能させない。ただし、後述するように、認証失敗理由が特定理由である場合には、その限りではない。

無線認証部Ｆ３１が無線認証処理を実施するタイミングは、例えばＢＬＥ通信機７と携帯デバイス２との通信接続が確立したタイミングとすることができる。無線認証部Ｆ３１は、ＢＬＥ通信機７と携帯デバイス２とが通信接続している間、所定の周期で無線認証処理を実施するように構成されていても良い。

また、スマートＥＣＵ４は、車両Ｈｖを施錠する操作（以降、施錠操作）が行われたことをトリガとして、無線認証処理のための通信を実施する。施錠操作とは、走行用電源がオフ且つキャビンに通じる全てのドアが閉じられた状態で施開錠センサ５をタッチする行為を指す。また、携帯デバイス２から施錠指示信号を受信した場合も、車両Ｈｖを施錠する操作が行われた場合に相当する。スマートＥＣＵ４は、施錠操作を受け付けたことに基づいて車両Ｈｖの全ドアをロックする。

尚、スマートＥＣＵ４は、認証済みの携帯デバイス２が施開錠エリアに存在することが確認できていることを条件として、施開錠センサ５のタッチを施錠操作及び開錠操作として受け付ける。施開錠エリアは、車載システムがドアの施錠／開錠するためのエリアであって、車室外のうち、各ドアから所定距離（例えば１．５ｍ）以内となる領域である。認証済みの携帯デバイス２とは、無線認証処理が成功した携帯デバイス２である。

さらに、スマートＥＣＵ４は、車両Ｈｖが施錠されており且つトランクドアだけが開かれている状況でトランクドアが閉じられたことをトリガとして、トランク内に存在する通信相手を対象に無線認証処理を実施する。車両Ｈｖが施錠されている状態とは、車両Ｈｖが備えるすべてのドアのロック機構が施錠状態に設定される状態を指す。尚、トランクドアのロック機構は、トランクドアが開かれた状態でも、施錠状態に設定可能に構成されている。トランクドアが開かれたまま全ドアのロック機構が施錠状態に設定されたのちにトランクドアが閉じられると、トランクドアのラッチが固定され、トランクドアは開かなくなる。

車両Ｈｖが施錠されている状態には、閉扉待機状態を含めることができる。閉扉待機状態は、施錠操作を受け付けたタイミングで開いているドアが閉じられ次第施錠が完了する状態である。閉扉待機状態には、例えば前述のように、全ドアのロック機構が施錠状態に設定されている状態でトランクドアのみが開いているトランク閉待機状態も含まれる。閉扉待機状態には、予約ロック機能を用いて車両Ｈｖの施錠が予約されている状態を含めることができる。予約ロック機能は、ドアが開かれている状態で施錠操作を受け付け、全ドアが閉じられたことをトリガとして全ドアを施錠する機能である。このように閉扉待機状態は、ユーザの施錠操作を受付済みの状態に対応する。

その他、無線認証部Ｆ３１は、スタートスイッチ６が押下されたことや、車両Ｈｖが施錠されている状態においてユーザによって施開錠センサ５がタッチされたことなどをトリガとして無線認証処理のための通信を実施しうる。

位置判定部Ｆ３２は、各ＢＬＥ通信機７でのデバイス信号の受信状況に基づいて、デバイス位置を判定する。例えば位置判定部Ｆ３２は、複数のＢＬＥ通信機７での測距値と各ＢＬＥ通信機７の車両Ｈｖにおける搭載位置を組み合わせることにより、車両Ｈｖに対する位置座標を特定する。各ＢＬＥ通信機７の設置位置は既知であるため、３つ以上のＢＬＥ通信機７から携帯デバイス２までの距離を取得できれば、携帯デバイス２の位置座標は三角測量あるいは三辺測量の原理により算出可能である。携帯デバイス２の位置座標は車両座標系などで表現されうる。

また位置判定部Ｆ３２は、当該特定されたデバイス位置座標に基づいて携帯デバイス２がトランク内に存在するか否か、及び、携帯デバイス２がトランク用施開エリアに存在するか否かを判定する。トランク用施開錠エリアとは、トランクドアハンドル周りに形成される施開錠エリアであり、車外においてトランクドアの取手から所定距離（例えば１．５ｍ）以内となる領域である。

尚、位置判定部Ｆ３２は、処理負荷低減のため、未登録デバイスに対しては位置判定を行わないように構成されている。また、位置判定部Ｆ３２は、登録済みデバイスのうち、通信接続しているデバイス、又はＢＬＥ信号を受信できているデバイスのみを対象として位置判定を行ってもよい。位置判定対象を絞るほど、プロセッサ４１の処理負荷低減及び節電が可能となる。

失敗理由特定部Ｆ３３は、携帯デバイス２の無線認証処理が失敗した場合に、当該携帯デバイス２から受信したデータに基づいて、その理由である認証失敗理由を特定する。認証失敗理由としては、後述するレスポンスコードと検証用コードの不一致、携帯デバイス２からの応答不受信などがある。また、登録済みデバイスであるにも関わらず、無線認証処理が失敗する場合の理由としては、ユーザ未認証、放置状態、認証鍵切れなどがある。ユーザ未認証、放置状態、及び認証鍵切れについては別途後述する。ユーザ未認証、放置状態、及び認証鍵切れが特定理由に相当する。またレスポンスコードと検証用コードの不一致、及び、携帯デバイス２からの応答不受信などが、その他理由に相当する。

応答処理部Ｆ４は、車両Ｈｖに対するユーザ操作に反応して、デバイス位置確認部Ｆ３が特定しているデバイス位置に応じた制御／処理を他のＥＣＵと連携して実行する。例えば応答処理部Ｆ４は、閉じ込め警告処理や、残留デバイス無効化処理を実施する。閉じ込め警告処理は、施錠操作受付時にトランク内にキーデバイスが残っていることを検知した場合に、所定の警告音等を出力する車両制御である。閉じ込め警告処理を実行する条件が充足した場合、応答処理部Ｆ４は、通知ＥＣＵ１５に対して警告音等の出力を要求する信号を送信する。

残留デバイス無効化処理は、車両Ｈｖを施錠する操作を受け付けた際に、車内に残されているキーデバイスを無効化する車両制御である。無効化とは、一時的に車両Ｈｖの施開錠等のためのキーとして機能させなくすることを意味する。無効化は、通信相手から除外することや、無線認証処理の対象外に設定することによって実現しうる。閉じ込め警告処理や残留デバイス無効化処理の詳細は別途後述する。

その他、応答処理部Ｆ４は、デバイス位置確認部Ｆ３によって携帯デバイス２が施開錠エリアに存在すると判定されており、かつ、施開錠センサ５がユーザによってタッチされたことを検出した場合には、ボディＥＣＵ１２と協働してドアを施錠又は開錠する。また、応答処理部Ｆ４は、デバイス位置確認部Ｆ３にて携帯デバイス２がキャビン内に存在すると判定されており、かつ、スタートスイッチ６がユーザによって押下されたことを検出した場合、電源ＥＣＵ１１と連携して走行用電源をオフからオンに切り替える。

尚、本実施形態の応答処理部Ｆ４は、他のＥＣＵと連携して警告などのユーザ通知や、施錠、開錠、走行用電源のオンオフなどを実施するが、これに限らない。応答処理部Ｆ４としてのスマートＥＣＵ４が、ユーザ通知や、施錠、開錠などにかかる電装設備を直接的に制御するように構成されていても良い。或る車両制御の実行に向けた制御信号を他のＥＣＵに出力することも、当該車両制御を実行することに含まれる。

＜無線認証処理について＞
ここではスマートＥＣＵ４が、通信相手としての携帯デバイス２を認証する処理のシーケンスについて説明する。スマートＥＣＵ４による携帯デバイス２の無線認証処理は、例えば図８に示すようにステップＳ１１～Ｓ１８を備える。無線認証処理は、携帯デバイス２とスマートＥＣＵ４との暗号化されたＢＬＥ通信リンクが確立していることを前提として実行される。

尚、ＢＬＥ通信リンクが確立しているということは、通信相手がペアリング済みの携帯デバイス２であることを示唆する。通信接続のための認証を１段回目の認証処理である１次認証処理とすると、無線認証処理は、２段階目の認証処理である２次認証処理に相当する。

ステップＳ１１はスマートＥＣＵ４から携帯デバイス２に向けて、チャレンジコードを送信するステップである。チャレンジコードは、例えば予め用意された乱数表を用いて生成される所定長の乱数である。チャレンジコードは、スマートＥＣＵ４が備える時刻情報（いわゆるシステム時刻）をＳＥＥＤとして用いて生成された乱数であっても良い。チャレンジコードは多様な方法で決定されうる。

ステップＳ１２は携帯デバイス２が、デバイス情報記憶部ＤｖＭに保存されている任意のワンタイム認証鍵と、受信したチャレンジコードを、所定の方式で組み合わせることにより、レスポンスコードを生成するステップである。使用済みのワンタイム認証鍵は、随時破棄される。ステップＳ１３は携帯デバイス２が、ステップＳ１２で生成したレスポンスコード、及び、当該レスポンスコードの生成に使用したワンタイム認証鍵に対応する変動コードを、まとめて／別々にスマートＥＣＵ４に返送するステップである。

ステップＳ１４は、スマートＥＣＵ４が、携帯デバイス２から受信した変動コードと、デバイス情報記憶部ＤｖＭに保存されている、通信相手に対応するサービス鍵とを用いて、ワンタイム認証鍵を生成するステップである。ここでスマートＥＣＵ４がワンタイム認証鍵の生成に使用するサービス鍵と変動コードの組み合わせは、レスポンスコードの生成に使用されたワンタイム認証鍵の生成材料と同じである。故にステップＳ１４でスマートＥＣＵ４が生成するワンタイム認証鍵は、携帯デバイス２がレスポンスコードの生成に使用したワンタイム認証鍵と同じとなる。このようなステップＳ１４は、携帯デバイス２から受信した変動コードと自信が保持する携帯デバイス２のサービス鍵をもとに、携帯デバイス２がレスポンスコードの生成に使用したワンタイム認証鍵を復元する処理に相当する。

ステップＳ１５では、スマートＥＣＵ４がステップＳ１４で生成したワンタイム認証鍵と、ステップＳ１１で送信したチャレンジコードをもとに、検証用コードを生成するステップである。検証用コードの生成方法自体は、レスポンスコードの生成と同一である。通信相手が、デバイス情報記憶部ＤｖＭに登録されているサービス鍵を保持する携帯デバイス２である場合には、検証用コードとレスポンスコードは一致することが期待できる。また、通信相手が未登録のデバイスである場合には、レスポンスコードが返送されないか、又は、レスポンスコードと検証用コードとが不一致となる。よって以上で生成／受信するレスポンスコードは、通信相手の正当性を検証するための情報として機能する。

ステップＳ１６では、スマートＥＣＵ４がステップＳ１５で生成した検証用コードと、携帯デバイス２から受信したレスポンスコードとを比較することで、通信相手の正当性を判断する。つまり、２つのコードが一致している場合には認証成功と判定する（ステップＳ１７）。一方、２つのコードが相違する場合には認証失敗と判定する（ステップＳ１８）。尚、チャレンジコードの送信から所定の応答待機時間が経過してもレスポンスコードが返って来ない場合、スマートＥＣＵ４は認証失敗と判定しうる。また、本開示のスマートＥＣＵ４は、携帯デバイス２からレスポンスコードの代わりに、後述する認証不能信号を受信した場合にも認証失敗と判定する。

上記構成によれば、携帯デバイス２ごとに固有のサービス鍵をもとに生成される、ワンタイム認証鍵を用いて携帯デバイス２及びユーザの認証を行う。そのため、固定的な鍵情報を用いて携帯端末の認証を行う構成に比べてセキュリティを高める事ができる。また、上記の方法によれば、レスポンスコードの生成に際してスマートＥＣＵ４と携帯デバイス２の間でやり取りされる情報は変動コードとチャレンジコードである。認証に際してワンタイム認証鍵自体は認証ＥＣＵ－携帯端末間で送受信されない。そして、認証に使用されるワンタイム認証鍵は毎回変更される。よって、上記の方法によれば、第３者が不正に無線認証処理を成功させる恐れを低減可能となる。ここでの第３者とは、車両Ｈｖのユーザではない人物を指す。

尚、上述した認証シーケンスは一例であって、これに限らない。携帯デバイス２とスマートＥＣＵ４とで、レスポンスコード／検証用コードの生成に使用するワンタイム認証鍵が同一のものとなるように、各デバイスの動作は設計されていれば良い。例えば、スマートＥＣＵ４と携帯デバイス２は共通の複数のワンタイム認証鍵を保持していることを前提として、無線認証処理に使用するワンタイム認証鍵の番号を通知しあうように構成されていてもよい。

＜デバイス応答処理＞
ここではデバイス応答処理として、チャレンジコードを受信したときの携帯デバイス２の作動について図９を用いて説明する。携帯デバイス２は車両Ｈｖからチャレンジコードを受信すると、ユーザ認証状態であるか否かを判定する（Ｓ２１）。ここで、携帯デバイス２は、ユーザ認証状態ではない場合、すなわちデジタルキーアプリ２０４にユーザがログインしていない場合（Ｓ２１ ＮＯ）、ユーザ未認証信号を車両Ｈｖに返送する（Ｓ２２）。ユーザ未認証信号は、ユーザ認証状態ではないことを示すコードを含むＢＬＥ信号である。ユーザ未認証信号は、無線認証処理に応答できないこと、具体的にはレスポンスコードを返送しないことを示す応答信号である。

また、携帯デバイス２は、ユーザ認証状態である場合（Ｓ２１ ＹＥＳ）、現在の携帯デバイス２の状態が放置状態に該当するか否かを加速度センサ２３からの信号に基づき判定する（Ｓ２３）。現在の携帯デバイス２の状態が放置状態に該当する場合には（Ｓ２３ ＹＥＳ）、ノーモーション信号を車両Ｈｖに返送する（Ｓ２４）。ノーモーション信号は、放置状態であることを示すコードを含むＢＬＥ信号である。ノーモーション信号は、無線認証処理に応答できないこと、具体的にはレスポンスコードを返送しないことを示す応答信号である。

携帯デバイス２は、放置状態ではない場合（Ｓ２３ ＮＯ）、鍵情報記憶部ＫｙＭにワンタイム認証鍵が少なくとも１つ残っているか否かを判定する（Ｓ２５）。携帯デバイス２は、鍵情報記憶部ＫｙＭにワンタイム認証鍵が少なくとも１つ残っている場合には（Ｓ２５ ＹＥＳ）、残っているワンタイム認証鍵のうちの任意の１つを用いてレスポンスコードを生成し（Ｓ２６）、車両Ｈｖに返送する（Ｓ２７）。ステップＳ２６～Ｓ２７は、図８のステップＳ１２～Ｓ１３に対応するシーケンスである。

一方、鍵情報記憶部ＫｙＭにワンタイム認証鍵が１つも残っていない場合には、認証鍵切れ信号を車両Ｈｖに返送する（Ｓ２８）。認証鍵切れ信号は、ワンタイム認証鍵を切らしている状態である認証鍵切れ状態であることを示すコードを含むＢＬＥ信号である。認証鍵切れ信号は、無線認証処理に応答できないこと、具体的にはレスポンスコードを返送しないことを示す応答信号である。

以上のように携帯デバイス２は、チャレンジコードを受信した際、ユーザを認証済みか否か、放置状態か否か、ワンタイム認証鍵を保持しているか否かに応じた応答を実施する。本開示では、ユーザ未認証信号や、ノーモーション信号、認証鍵切れ信号をまとめて認証不能信号とも称する。スマートＥＣＵ４は、ユーザ未認証信号などの認証不能信号を受信した場合には、認証失敗（不成功）と判定する。また、失敗理由特定部Ｆ３３は、通信相手からユーザ未認証信号を受信した場合、認証失敗理由はユーザ未認証であると判定する。失敗理由特定部Ｆ３３は、通信相手からノーモーション信号を受信した場合、認証失敗理由は放置状態であると判定する。認証切れ信号を受信した場合、失敗理由特定部Ｆ３３は、認証失敗理由は認証鍵切れであると判定する。

尚、携帯デバイス２は、チャレンジコード受信時に限らず、チャレンジコードの受信前、例えばＢＬＥ通信リンクが確立したタイミングで、認証不能信号を送信してもよい。デバイス制御部２０は、スマートＥＣＵ４からの応答要求信号に対する応答として認証不能信号等を送信してもよいし、ＢＬＥ通信リンク確立後、任意のタイミングで自発的に認証不能信号を送信しても良い。認証不能信号を送信するタイミングは適宜変更可能である。

また、デバイス制御部２０は、認証不能信号を送信後、認証不能理由が解消した場合には、無線認証処理に対応可能となったことを示すレディ信号をスマートＥＣＵ４に送信してもよい。認証不能理由とは、ワンタイム認証鍵切れや、放置状態、ユーザ未認証などを指す。スマートＥＣＵ４は、レディ信号を受信した場合、当該レディ信号の送信元に対してチャレンジコードを送信し、無線認証処理を実行しても良い。

＜閉じ込め警告処理について＞
ここでは図１０に示すフローチャートを用いてスマートＥＣＵ４が実施する閉じ込め警告処理について説明する。閉じ込め警告処理は、閉扉待機状態、例えばトランク閉待機状態においてトランクドアが閉じられたことをトリガに実行される。閉じ込め警告処理は、一例としてステップＳ１０１～Ｓ１０８を備える。

ステップＳ１０１は、トランク内探索処理として、デバイス位置確認部Ｆ３がトランク内に携帯デバイス２が存在するか否かを判定するステップである。例えば、各ＢＬＥ通信機７に携帯デバイス２と測距通信を実施させることによりデバイス位置座標を特定し、携帯デバイス２がトランク内に存在するか否かを判定する。当該探索処理は、スマートＥＣＵ４とペアリング済みの携帯デバイス２を対象として実行されうる。ステップＳ１０１が位置判定処理に相当する。

ステップＳ１０１のトランク内探索処理の結果として、トランク内に携帯デバイス２が発見されなかった場合（Ｓ１０２ ＮＯ）、スマートＥＣＵ４はトランク内に閉じ込めた携帯デバイス２は存在しないとみなし、スマートＥＣＵ４は施錠を完了する（Ｓ１０３）。この場合、警告処理などの特別な制御は実施しない。施錠が完了した状態とは、トランクドアを含む全てのドアが閉じられ、且つ、施錠されている状態を指す。

一方、登録済みデバイスがトランク内に存在すると判定した場合には（Ｓ１０２ ＹＥＳ）、スマートＥＣＵ４は、トランク内デバイスの無線認証処理を実行する（Ｓ１０４）。トランク内デバイスとはトランク内に存在する携帯デバイス２を指す。

トランク内デバイスの無線認証処理が成功した場合には（Ｓ１０５ ＹＥＳ）、スマートＥＣＵ４は閉じ込め記録処理を実施する（Ｓ１０７）。閉じ込め記録処理は、トランク内に閉じ込めた携帯デバイス２が存在することを、内部状態として保持するための処理である。閉じ込め記録処理は、例えばトランク閉込フラグをオンに設定することと、トランク内デバイスのデバイスＩＤを、閉じ込めデバイス情報としてストレージ４３等に保存することと、を含む。トランク閉込フラグは、閉じ込めデバイスが存在するか否かを示すフラグである。閉じ込めデバイスは、トランク内に閉じ込められている携帯デバイス２を意味する。

また、本実施形態のスマートＥＣＵ４は、トランク内デバイスの無線認証処理が失敗した場合（Ｓ１０５ ＮＯ）、その理由である認証失敗理由を該当デバイスの受信データに基づき特定する。そして、当該認証失敗理由が、ユーザ未認証、放置状態、及び認証鍵切れの何れかに該当するか否かを判定する（Ｓ１０６）。

仮に認証失敗理由がユーザ未認証、放置状態、及び認証鍵切れの何れかである場合（Ｓ１０６ ＹＥＳ）、スマートＥＣＵ４は、携帯デバイス２がトランク内に存在するとみなし、無線認証処理が成功した場合と同様に、閉じ込め記録処理を実施する（Ｓ１０７）。一方、トランク内デバイスの無線認証処理がその他理由で失敗した場合には（Ｓ１０６ ＮＯ）、スマートＥＣＵ４は通常施錠状態に移行する。

スマートＥＣＵ４は、トランク内に携帯デバイス２を閉じ込めたことを検知した場合、通知ＥＣＵ１５と連携して、警告処理を実施する（Ｓ１０８）。警告処理は、例えば警音器１７から所定の警告音を出力させること、及び、車載ディスプレイ１６に警告メッセージを表示することの少なくとも何れか一方を含む。当該警告処理を実施することにより、ユーザはうっかり携帯デバイス２をトランク内に入れてしまったことを認識できる。

次に図１１に示すフローチャートを用いて、トランク開錠処理について説明する。トランク開錠処理は、トランクドアを開錠するための制御処理である。トランク開錠処理は、車両Ｈｖの施錠が完了している状態においてトランクドアに設けられた施開錠センサ５がユーザによってタッチされたことに基づいて実施される。図１１に示すトランク開錠処理は、図１０のステップＳ１０３又はステップＳ１０８の後工程として実施されうる。

ステップＳ２０１は、ストレージ４３等の記録を参照し、閉じ込めデバイスが存在するか否かを判定するステップである。閉じ込めデバイスが存在することが記録されている場合（Ｓ２０１ ＹＥＳ）、スマートＥＣＵ４は、トランク外確認処理及びトランク内確認処理を順に／同時に実行する（Ｓ２０２～Ｓ２０３）。トランク外確認処理は、トランク用施開錠エリア内に携帯デバイス２が存在するか否かを判定する処理であって、デバイス位置の判定処理と無線認証処理とを含む。トランク内確認処理は、トランク内に携帯デバイス２が存在するか否かを判定する処理であって、位置判定処理と無線認証処理とを含む。ステップＳ２０３としてのトランク内確認処理がオープン時確認処理に相当する。

ステップＳ２０４は、ステップＳ２０２～Ｓ２０３の結果として、トランク内又はトランク用施開錠エリアに携帯デバイス２を発見できたか否かを判定するステップである。携帯デバイス２を発見できた場合とは、単に携帯デバイス２が存在するだけでなく、当該携帯デバイス２の無線認証処理が成功した場合に相当する。トランク内又はトランク用施開錠エリアに携帯デバイス２を発見できた場合には、トランクドアを開錠する（Ｓ２２０）。

また、トランク内及びトランク用施開錠エリアに携帯デバイス２を発見できなかった場合には、特定理由で無線認証処理が失敗した携帯デバイス２が、トランク内又はトランク用施開錠エリアに存在するか否かを判定する（Ｓ２０５）。スマートＥＣＵ４は、トランク内又はトランク用施開錠エリアに、特定理由で無線認証処理が失敗した携帯デバイス２が存在する場合（Ｓ２０５ ＹＥＳ）、トランクドアを開錠する（Ｓ２２０）。

尚、トランク内又はトランク用施開錠エリアに、正規デバイスを発見できず、且つ、特定理由で無線認証処理が失敗した携帯デバイス２も存在しない場合（Ｓ２０５ ＮＯ）、スマートＥＣＵ４はトランクドアを施錠した状態を維持する（Ｓ２２１）。正規デバイスとは無線認証が成功した携帯デバイス２である。また、スマートＥＣＵ４は、閉じ込めデバイスが存在しない場合には（Ｓ２０１）、トランク内確認処理は実行せずに、トランク外確認処理のみを実行する（Ｓ２１０）。そして、トランク用施開錠エリアに正規デバイスを発見できた場合にはトランクドアを開錠する（Ｓ２２０）。

上記構成によれば、トランク閉待機状態において、うっかりトランク内に携帯デバイス２を置いた状態でトランクドアを閉じてしまい、さらに不運なことに認証鍵切れ等の特定理由により無線認証が失敗した場合でも、ユーザはトランクを開錠可能となる。尚、図１１に示すトランク開錠処理によれば、携帯デバイス２がトランクに閉じ込められている場合、原理的にはユーザ以外の人物でもトランクの施開錠センサ５をタッチすることでトランクドアを開けることが可能となりうる。しかしながら、上記ケースの場合、トランクドアが閉じられ次第、閉じ込め警告処理が実施される。そのため、携帯デバイス２をトランクに閉じ込めてしまった場合においては、ユーザは、車両Ｈｖを離れる前に上記のトランクの開錠操作を実施する。つまり、図１１に示すトランク開錠処理は、現実的にはユーザのみがトランクドアを開錠可能となるように作動する。

＜残留デバイス無効化処理について＞
ここでは図１２に示すフローチャートを用いて残留デバイス無効化処理について説明する。残留デバイス無効化処理は、施錠操作を受け付けたタイミングでトランク内に残されている携帯デバイス２を無効化する処理である。スマートＥＣＵ４は、走行用電源オンかつ全ドアが閉じている状態で施錠操作受け付けた際に、残留デバイス無効化処理を実施する。施錠操作を受け付けた場合とは、具体的には、施錠指示信号を受信した場合である。また、施開錠エリア内に正規デバイスが存在することを確認済みの状況で施開錠センサ５が押下された場合も施錠操作を受け付けた場合に含めることができる。

上述した閉じ込め警告処理は、ユーザがうっかり車内（トランク内）に携帯デバイス２を閉じ込めてしまった場合に対応する処理であるのに対し、残留デバイス無効化処理はユーザが意図的にトランク内に携帯デバイス２を閉じ込めた場合に対応する処理である。実行条件の観点においては、閉じ込め警告処理は施錠操作後のドア閉をトリガとして実行されるのに対し、残留デバイス無効化処理は施錠操作受付をトリガとして実行される点で相違しうる。残留デバイス無効化処理は一例としてステップＳ３０１～Ｓ３０６を含む。

ステップＳ３０１は、ステップＳ１０１と同様に、デバイス位置確認部Ｆ３がトランク内に携帯デバイス２が存在するか否かを判定するステップである。トランク内に存在する携帯デバイス２が発見された場合（Ｓ３０２ ＹＥＳ）、スマートＥＣＵ４は当該トランク内デバイスの無線認証処理を実施する（Ｓ３０３）。尚、トランク内に携帯デバイス２が発見されなかった場合には（Ｓ３０２ ＮＯ）、本フローは終了する。

トランク内デバイスの無線認証処理が成功した場合には（Ｓ３０４ ＹＥＳ）、スマートＥＣＵ４は当該トランク内デバイスを無効化する（Ｓ３０６）。具体的には、トランク内デバイスは開錠には使用不可であることを示すデータをストレージ４３等に保存する。

また、スマートＥＣＵ４は、トランク内デバイスの無線認証処理が失敗した場合（Ｓ３０４ ＮＯ）、その理由を該当デバイスの受信データに基づき特定する。そして、当該認証失敗理由が、ユーザ未認証、放置状態、及び認証鍵切れの何れかに該当するか否かを判定する（Ｓ３０５）。

仮に認証失敗理由がユーザ未認証、放置状態、及び認証鍵切れの何れかである場合（Ｓ３０５ ＹＥＳ）、スマートＥＣＵ４は、正規デバイスとしての携帯デバイス２がトランク内に存在するとみなし、当該トランク内デバイスを無効化する（Ｓ３０６）。つまり、スマートＥＣＵ４は、認証失敗理由が特定理由に該当する場合には、無線認証処理が成功した場合と同様の処理を実施する。一方、トランク内デバイスの無線認証処理がその他理由で失敗した場合には（Ｓ３０５ ＮＯ）、スマートＥＣＵ４はトランク内デバイスを無効化せずに本フローを終了する。

上記構成によれば、ユーザが施錠操作前にトランク内に置いた携帯デバイス２は無効化されるため、仮にトランクの施開錠センサ５のタッチをトリガとしてトランク内確認処理が実行されたとしても、無線認証処理は成功しない。よって、第３者が不正にトランクを開錠することを防ぐことができる。また、残留デバイス無効化処理は、全ドアが閉じた状態での施錠操作をトリガとして実行されるため、ユーザが閉じ込めデバイスとは別の携帯デバイス２を所持していることが前提となる。つまり、閉じ込めデバイスを無効化したとしても、ユーザは当該別の携帯デバイス２を用いて問題なく車両Ｈｖを開錠可能である。

＜スマートＥＣＵ４の作動と効果のまとめ＞
一般的なＰＥＰＳシステムでは無線認証処理の成功を必須条件として携帯デバイス２の位置に応じた車両制御を実行する。しかしながら、無線認証処理の実行条件や認証方式が複雑化／厳格化すると、実際には携帯デバイス２がトランク内に存在する場合であっても、トランク内に存在しないとみなす可能性が高まる。また、その結果として、デバイス位置に応じた制御が不作動となるケースも増えうる。セキュリティ性向上のために、携帯デバイス２が放置状態である場合にはレスポンスコードを返送しないように構成した場合にも、同様の課題が起こりうる。

そのような課題に対し、本実施形態の構成によれば、通信相手の無線認証処理が失敗した場合であっても、その理由が特定の理由である場合には、通信相手が登録済みデバイスであることを条件として、携帯デバイス２がトランク内に存在するとみなす。また、その結果、閉じ込めデバイスの無効化に失敗したり、閉じ込め警告処理が不作動となったりする恐れを低減できる。

尚、比較構成としては、無線認証処理に失敗した通信相手は、その認証失敗の理由に関わらず、正規デバイスではないとみなす構成が考えられる。そのような比較構成では、トランク内デバイスの認証に失敗した場合には、スマートＥＣＵ４はトランク内に携帯デバイス２が存在することを認識できない。その結果、ユーザの意図に反して携帯デバイス２をトランク内に閉じ込めてしまう。また比較構成では、認証に失敗した、トランク内にあえて残された携帯デバイス２を無効化することもできない。

尚、認証鍵切れとの失敗理由は、時間の経過に伴って、ＤＫＳ３からワンタイム認証鍵を取得することで解消することがある。よって、トランク内に残された携帯デバイス２は、時間経過とともにＤＫＳ３からワンタイム認証鍵を取得し、認証可能な状態に復帰することも起こりうる。トランク内に残された、無効化されていない携帯デバイス２が認証可能な状態に復帰した場合、第３者がトランクを開錠可能となってしまう。本実施形態によれば、上記比較構成が有する課題を緩和／解消することができる。

尚、認証鍵切れによってトランク内デバイスの認証が失敗する場合とは、例えば、施錠のための無線認証処理でワンタイム認証鍵を使い切ってしまった携帯デバイス２をトランク内に置いてトランクドアを閉じた場合である。本来、携帯デバイス２はワンタイム認証鍵の残数が１つになる前に、ＤＫＳ３からワンタイム認証鍵を補充するように作動するはずである。しかしながら、通信環境や携帯デバイス２の通信設定、ＤＫＳ３のメンテナンス等によっては、ワンタイム認証鍵の補充が間に合わないことも起こりうる。また、放置状態により携帯デバイス２の認証が失敗する場合とは、例えば、携帯デバイス２をトランク内に置いた状態を放置判定時間維持した後に、トランクドアを閉じた場合などである。ユーザが施錠操作を実施してトランクに携帯デバイス２を置いたのちに、荷物を整理したり、同乗者等と話したりしているうちに放置判定時間が経過した場合、放置状態に起因する認証失敗が起こりうる。ユーザ認証状態もまた、時間の経過等によって自然と解除されうる。本開示の構成によれば、頻繁ではないものの十分に起こりうる、上記ケースにおいて閉じ込め警告や残留デバイス無効化が不作動となる恐れを低減可能となる。

以上、本開示の実施形態を説明したが、本開示は上述の実施形態に限定されるものではなく、以降で述べる種々の変形例も本開示の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。例えば下記の種々の補足や変形例などは、技術的な矛盾が生じない範囲において適宜組み合わせて実施することができる。尚、以上で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略することがある。また、構成の一部のみに言及している場合、他の部分については上記説明を適用することができる。

＜トランク内確認処理の実施について＞
上述したトランク開錠処理では、スマートＥＣＵ４がトランク内に携帯デバイス２を閉じ込めていることを認識している場合にのみ、トランクの施開錠センサ５のタッチをトリガとしてトランク内確認処理を実施するものとしたが、これに限らない。トランクの施開錠センサ５がタッチされた場合には、閉じ込めの有無によらずに、トランク内確認処理とトランク外確認処理の両方を実施しても良い。その際、無効化されている携帯デバイス２に関しては、無視されうる。無効化された携帯デバイス２は、別の携帯デバイス２を用いて車両Ｈｖが開錠された場合に有効化されうる。

＜ＢＬＥ通信機の搭載位置＞
上述したＢＬＥ通信機７の配置数及び配置態様は一例であって適宜変更可能である。ＢＬＥ通信機７ａ及びＢＬＥ通信機７ｂはＢピラーやＣピラーの外側面に配置されていてもよい。尚、車両Ｈｖは、Ｂピラーとして、ドアモジュールが備えるドア側Ｂピラーと、車体の屋根部を備える支柱／フレームとしての車体側Ｂピラーに区分可能である。ドア側Ｂピラーは、前席用ドア又は後席用ドアにおいて車体側ピラーと当接する部分に相当する。室外機は、ドア側Ｂピラーのうち、サイドウインドウに隣接する部分、すなわちサイドウインドウの下端部よりも上側の部分を採用可能である。また、室外機は車外側Ｂピラーの車外側の面に配置されていても良い。

ＢＬＥ通信機７ｐは、シフトレバー付近や、スタートスイッチ６付近、センターコンソール、運転席の足元などに配置されていてもよい。ＢＬＥ通信機７ｐは、運転席用のドアの車内側面、例えばドアポケットや、運転席側のＢピラーの付け根などに配置されていても良い。また、室内機は複数存在しても良い。例えば車載システム１は、右側ドアの室内側の面に配置されたＢＬＥ通信機７と、左側ドアの室内側の面に配置されたＢＬＥ通信機７と、備えていても良い。車載システム１は、図１３に示すようにトランク内に配置されたＢＬＥ通信機７である、トランク内通信機７ｔを備えていても良い。

＜デバイス位置の判定方法について＞
トランク内に携帯デバイス２が存在するか否かは、トランク内通信機７ｔでの携帯デバイス２からの受信強度に基づいて判定されても良い。例えば位置判定部Ｆ３２は、トランク内通信機７ｔでの携帯デバイス２からの受信強度が所定値以上であることに基づいてトランク内に携帯デバイス２が存在すると判定しても良い。同様に、位置判定部Ｆ３２は、室内機での受信強度が所定値以上であることに基づいて携帯デバイス２がキャビンに存在すると判定しても良い。

＜閉じ込め警告／無効化の対象とする空間の変形例＞
車両Ｈｖは図１４に示すように、トランク内部空間ＣＳｔの他に、キャビン（Ｃｂｎ）とは独立した閉空間として、充電インレット収納部ＣＳｃや、ボンネットの内側に配置された前方収納部ＣＳｂなどを備えうる。トランク内部空間ＣＳｔはトランクの内側空間であり、充電インレット収納部ＣＳｃは充電リッドの内側空間である。携帯デバイス２の閉じ込め警告処理等の適用対象とする独立空間部ＣＳは、充電インレット収納部ＣＳｃや前方収納部ＣＳｂなどであっても良い。尚、充電リッドとは、充電プラグ／ケーブルと接続されるコネクタなどが配された開口部を塞ぐ蓋であって、充電ポートリッドとも称される。

また、以上では、トランク内に携帯デバイス２が放置された場合の作動について述べたが、上記構成は、キャビン内に携帯デバイス２が放置された場合にも適用可能である。スマートＥＣＵ４は、特定理由により無線認証が失敗した携帯デバイス２がキャビン内に存在する場合にも、無線認証処理が成功したデバイスがキャビン内に存在する場合と同様に、閉じ込め警告や無効化等を実施してもよい。車内には、キャビンの他、トランク内や、充電インレット収納部、前方収納部なども含まれる。

＜ワンタイム認証鍵の発行端末について＞
上述した実施形態では、ＤＫＳ３がワンタイム認証鍵を生成し、携帯デバイス２に配布する態様を例示したが、これに限らない。スマートＥＣＵ４が、無線認証処理が成功していることなどを条件として、ワンタイム認証鍵を生成して配布してもよい。ＤＫＳ３は任意の要素であって省略可能である。ＤＫＳ３やスマートＥＣＵ４が発行端末に相当する。

＜その他＞
スマートＥＣＵ４は、認証失敗理由が特定理由であることを条件として認証が成功した場合と同様に実行する制御は、閉じ込め警告と残留デバイス無効化の両方又は何れか一方だけであってもよい。キャビンに通ずるドアを開錠する制御に関しては、スマートＥＣＵ４は、施開錠エリアに存在する携帯デバイス２の認証が失敗した場合にはその失敗理由よらず、実施しないことが好ましい。走行用電源をオフからオンに切り替える制御に関しても、スマートＥＣＵ４は車内に存在する携帯デバイス２の認証が成功していない場合には、認証失敗理由によらず、実施しないことが好ましい。車両Ｈｖを施錠する制御に関しては、認証失敗理由が特定理由であること、通信相手が登録済みデバイス、及び通信相手が施開錠エリアに存在することを条件として、認証不成功であっても実施するように構成されていても良い。当該構成によれば、車両Ｈｖが第３者に使用される恐れを低減しつつ、ユーザの利便性を高める事が可能となる。

＜付言＞
本開示に記載の装置、システム、並びにそれらの手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサを構成する専用コンピュータにより、実現されてもよい。本開示に記載の装置及びその手法は、専用ハードウェア論理回路を用いて実現されてもよい。本開示に記載の装置及びその手法は、コンピュータプログラムを実行するプロセッサと一つ以上のハードウェア論理回路との組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。例えばスマートＥＣＵ４が備える機能の一部又は全部はハードウェアとして実現されても良い。或る機能をハードウェアとして実現する態様には、１つ又は複数のＩＣなどを用いて実現する態様が含まれる。プロセッサ（演算コア）としては、ＣＰＵや、ＭＰＵ、ＧＰＵ、ＤＦＰ（Data Flow Processor）などを採用可能である。スマートＥＣＵ４が備える機能の一部は、ＳｏＣ（System-on-Chip）、ＩＣ（Integrated Circuit）、又はＦＰＧＡ（Field-Programmable Gate Array）を用いて実現されていてもよい。ＩＣの概念には、ＡＳＩＣ（Application Specific Integrated Circuit）も含まれる。

また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体（non- transitory tangible storage medium）に記憶されていればよい。プログラムの記録媒体としては、ＨＤＤ（Hard-disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリ等を採用可能である。コンピュータをスマートＥＣＵ４として機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実態的記録媒体等の形態も本開示の範囲に含まれる。

１ 車載システム、２ 携帯デバイス、４ スマートＥＣＵ（車両制御装置）、７ ＢＬＥ通信機、４１ プロセッサ、Ｆ１ 車両情報取得部、Ｆ２ 通信制御部、Ｆ３ デバイス位置確認部、Ｆ４ 応答処理部、Ｆ３１ 無線認証部、Ｆ３２ 位置判定部、Ｆ３３ 失敗理由特定部、Ｆ３１１ 一時鍵生成部、ＣＳｔ トランク内部空間、ＣＳｂ 前方収納部、ＣＳｃ 充電インレット収納部、ＣＳ 独立空間部

Claims (13)

1. 車両の鍵として事前に登録されている携帯デバイスであるキーデバイスと無線通信をすることによって前記キーデバイスの位置を判定する車両制御装置であって、
   通信相手から送信されてきたデータをもとに、前記通信相手が前記キーデバイスであるか否かを判定する無線認証処理と、前記通信相手からの信号の受信状況に基づいて当該通信相手が車内に存在するか否かを判定する位置判定処理とを実施する、デバイス位置確認部（Ｆ３）と、
   前記デバイス位置確認部が前記無線認証処理にて前記通信相手は前記キーデバイスであると判定しなかった場合に、前記通信相手から受信した前記データをもとに、前記通信相手が前記キーデバイスと判定しなかった理由である認証失敗理由を特定する失敗理由特定部（Ｆ３３）と、を備え、
   前記デバイス位置確認部は、前記通信相手は前記キーデバイスであると判定できなかった場合でも、前記認証失敗理由が特定理由であり、かつ、前記通信相手の位置は車内であると判定している場合には、前記キーデバイスが前記車内に存在すると見なすように構成されている車両制御装置。
2. 請求項１に記載の車両制御装置であって、
   前記デバイス位置確認部は、
   前記通信相手からの信号の受信状況に基づいてキャビンとは独立した前記車両が備える閉空間である独立空間部（ＣＳ）に当該通信相手が存在するか否かを判定するものであって、
   前記通信相手は前記キーデバイスであると判定できなかった場合でも、前記認証失敗理由が前記特定理由であり、かつ、前記通信相手が前記独立空間部に存在すると判定されている場合には、前記キーデバイスが前記独立空間部に存在すると見なすように構成されている車両制御装置。
3. 請求項２に記載の車両制御装置であって、
   前記独立空間部は、トランクである車両制御装置。
4. 請求項３に記載の車両制御装置であって、
   前記デバイス位置確認部は、トランクドアだけが開かれた状態で前記車両が施錠状態に設定された後に前記トランクドアが閉じられたことをトリガとして、前記トランクに前記キーデバイスが存在するか否かを確認する車両制御装置。
5. 請求項４に記載の、前記トランクへの前記キーデバイスの閉じ込めを防止するための車両制御装置であって、
   前記トランクドアが閉じられた際に前記キーデバイスが前記トランクに存在すると前記デバイス位置確認部が判定した場合、前記トランク内に前記キーデバイスが存在することを警告するための処理を実施する応答処理部（Ｆ４）を備え、
   前記警告の後に前記トランクドアを開けるためのユーザ操作を検出した場合には、前記デバイス位置確認部が、前記トランク内に前記キーデバイスが存在するか否かを確認するオープン時確認処理を実施し、
   前記応答処理部は、前記オープン時確認処理にて前記トランク内に存在する前記キーデバイスが存在すると判定された場合には、前記トランクのロック機構を開錠状態に切り替えるための処理を実施する車両制御装置。
6. 複数の前記キーデバイスを登録可能に構成された、請求項３から５の何れか１項に記載の車両制御装置であって、
   前記デバイス位置確認部は、全てのドアが閉じられている状態において前記車両を施錠するためのユーザ操作を受け付けたことをトリガとして、前記トランク内に前記キーデバイスが存在するか否かを判定するように構成されている車両制御装置。
7. 請求項６に記載の車両制御装置であって、
   前記車両を施錠した際に前記キーデバイスが前記トランクに存在すると前記デバイス位置確認部が判定した場合に、当該トランク内に存在する前記キーデバイスを無効化する車両制御装置。
8. 請求項１から７の何れか１項に記載の車両制御装置であって、
   前記無線認証処理は、
   前記通信相手に向けてチャレンジコードを送信するステップと、
   前記通信相手が、前記チャレンジコードに対する応答として、所定の発行端末で生成された使い捨てのワンタイム認証鍵を用いてレスポンスコードを生成し、当該レスポンスコードを前記車両に向けて送信するステップと、を含み、
   前記キーデバイスは、前記ワンタイム認証鍵を持っていない場合には、前記ワンタイム認証鍵を切らしていることを示す認証鍵切れ信号を返送するように構成されており、
   前記デバイス位置確認部は、前記認証鍵切れ信号を受信した場合には、前記通信相手は前記キーデバイスであるとは判定せず、
   前記失敗理由特定部は、前記認証鍵切れ信号を受信したことに基づいて前記認証失敗理由は認証鍵切れと判定し、
   前記認証鍵切れが前記特定理由に設定されている車両制御装置。
9. 請求項１から８の何れか１項に記載の車両制御装置であって
   前記キーデバイスは、静止状態が所定時間継続している場合には、前記車両からの応答要求信号に対して、当該キーデバイスが所定時間動いていないことを示すノーモーション信号を返送するように構成されており、
   前記デバイス位置確認部は、前記ノーモーション信号を受信した場合には、前記通信相手は前記キーデバイスであるとは判定せず、
   前記失敗理由特定部は、前記ノーモーション信号を受信したことに基づいて前記認証失敗理由はノーモーションと判定し、
   前記ノーモーションが前記特定理由に設定されている車両制御装置。
10. 請求項１から９の何れか１項に記載の車両制御装置であって、
    前記キーデバイスは、生体情報又はパスワードを用いてユーザの正当性を判断するユーザ認証機能を備え、前記ユーザの認証が成功していない場合には、前記車両からの応答要求信号に対して、前記ユーザの認証が成功していないことを示すユーザ未認証信号を返送するように構成されており、
    前記デバイス位置確認部は、前記ユーザ未認証信号を受信した場合には、前記通信相手は前記キーデバイスであるとは判定せず、
    前記失敗理由特定部は、前記ユーザ未認証信号を受信したことに基づいて前記認証失敗理由はユーザ未認証と判定し、
    前記ユーザ未認証が、前記特定理由に設定されている車両制御装置。
11. 請求項２に記載の車両制御装置であって、
    前記独立空間部は、充電リッドの内側空間、又は、ボンネットの内側空間である車両制御装置。
12. 請求項１から１１の何れか１項に記載の車両制御装置であって、
    前記デバイス位置確認部は、
    前記通信相手のデバイスＩＤを取得し、当該デバイスＩＤが前記キーデバイスとして登録されていることを条件として、前記位置判定処理及び前記無線認証処理を実行し、
    前記無線認証処理が失敗した場合であっても、前記デバイスＩＤが前記キーデバイスとして登録済みのものであること、前記認証失敗理由が前記特定理由であること、及び、当該通信相手の位置が車内と判定されていることを条件として、前記通信相手の前記デバイスＩＤに対応する前記キーデバイスが車内に存在すると見なす、車両制御装置。
13. 車両の鍵として事前に登録されている携帯デバイスであるキーデバイスと無線通信をすることによって前記キーデバイスの位置を判定する、少なくとも１つのプロセッサによって実施される車両制御方法であって、
    通信相手から送信される無線信号の受信状況に基づいて当該通信相手が、車内に存在するか否かを判定するステップと、
    前記通信相手から送信されてきたデータをもとに、前記通信相手が前記キーデバイスであるか否かを判定するステップと、
    前記通信相手が前記キーデバイスと判定しなかった場合、受信した前記データの内容をもとに、前記通信相手を前記キーデバイスと判定しなかった理由である認証失敗理由を特定するステップと、
    前記通信相手は前記キーデバイスと判定しなかった場合でも、前記認証失敗理由が特定理由であり、かつ、前記通信相手が車内に存在すると判定されている場合には、前記キーデバイスが車内に存在すると見なすステップと、を含む車両制御方法。