JP2023049594A - 車両用デジタルキーシステム、車両用デジタルキー管理方法、車両用装置、携帯端末 - Google Patents

Abstract

【課題】よりセキュリティ性の高い車両用デジタルキーシステム、車両用デジタルキー管理方法、車両用装置、携帯端末を提供する。【解決手段】サーバは、携帯端末からの要求に基づき、指定された車両を使用するためのサービス鍵と、複数のワンタイム認証鍵を発行し、携帯端末に配信する。ワンタイム認証鍵はサービス鍵を元に生成される使い捨ての認証鍵であって、有効期限が設定されている。ワンタイム認証鍵は、車両用装置が通信相手としての携帯端末を認証する際に消費される。携帯端末は、自身が保持するワンタイム認証鍵を随時入れ替える。【選択図】図１

Description

本開示は、車両を施錠／開錠するための鍵情報であるデジタルキーを生成及び配信する技術に関する。

特許文献１－２には、車両の管理者から発行される鍵情報を、ユーザによって携帯されるデバイスである携帯端末及び車載器のそれぞれに配信することにより、当該携帯端末を車両の電子キーとして使用可能とするシステムが開示されている。携帯端末としては例えばスマートフォンなどのインターネット接続可能な通信端末が想定される。このようにスマートフォンなどの携帯端末を車両キーとして使用することができれば、ユーザは車両使用の際に専用の電子キーを所持する必要がなくなり、利便性がよくなる。なお、特許文献１－２には、車両のオーナと、その他の人物（ゲスト）とで、車両の使用権限を異ならせる構成についても言及されている。

なお、車両に接続するデバイスの正当性を検証する方法としては多様な方法が存在する。例えば特許文献３には、動的に変更されるパラメータである変動符号と、固定的な鍵情報とを組み合わせることで生成される認証コードを用いて、車両に接続するデバイスを認証する方法が開示されている。これら先行技術文献の記載内容は、この明細書における技術的要素の説明として、参照により援用することができる。

特許第６６３５１０２号公報 特表２０１９－５３６３２９号公報 特許第６０７８６８６号公報

電気的な鍵情報を用いて車両の使用を可能とするシステムにおいては、よりセキュリティを強固にすることが求められる。当該需要に対応する１つの想定構成としては、携帯端末が、固有のサービス鍵を元に使い捨ての認証コードであるワンタイム認証鍵を生成し、当該ワンタイム認証鍵を用いて車両用装置に対して正当性を証明する構成が想定される。しかしながら、当該想定構成では、携帯端末の処理負荷を増大させてしまう。携帯端末としては処理能力が異なる多様なデバイスが想定される。演算能力の低いデバイスでも動作するよう、携帯端末に持たせる機能はなるべく簡素にすることが好ましい。

携帯端末の機能を簡素にするためのさらなる想定構成としては、ワンタイム認証鍵の生成機能をサーバに設け、携帯端末は、車両と通信する際にサーバからリアルタイムにワンタイム認証鍵を取得して使用する構成も考えられる。しかし、携帯端末がいつも通信可能な状況にあるとは限らない。携帯端末が通信圏外にある場合、サーバからワンタイム認証鍵が取得できず、車両が使用できなくなってしまう。すなわち、ユーザの利便性が低下しうる。

本開示は、上記の検討又は着眼点に基づいて成されたものであり、その目的の１つは、セキュリティ性とユーザの利便性を両立可能な車両用デジタルキーシステム、車両用デジタルキー管理方法、携帯端末、車両用装置を提供することにある。

ここに開示される車両用デジタルキーシステムは、車両に搭載されて使用される車両用装置（４）と、ユーザによって携帯される情報処理端末である携帯端末（１）と、車両を使用するための鍵情報として、携帯端末ごとに固有のサービス鍵を生成し、携帯端末及び車両用装置のそれぞれに直接的に又は間接的に配布するサーバ（３）と、を含む車両用デジタルキーシステムであって、車両用装置は、サービス鍵をもとに生成される、使い捨てのワンタイム認証鍵を用いて携帯端末の正当性を判断するように構成されており、サーバは、携帯端末からの要求に基づき、複数のワンタイム認証鍵を生成し、有効期限付きで携帯端末に配信し、携帯端末は、サーバからワンタイム認証鍵を受信し、所定の端末側記憶装置（１０５）に保存することと、ワンタイム認証鍵ごとの有効期限に基づき、端末側記憶装置に保存されているワンタイム認証鍵の一部又は全部を入れ替えるように構成されている。

上記構成によれば、携帯端末ごとに固有のサービス鍵をもとに生成される、ワンタイム認証鍵を用いて携帯端末（ひいてはユーザ）の認証を行うため、固定的な鍵情報を用いて携帯端末の認証を行う構成に比べてセキュリティを高める事ができる。また、携帯端末は、複数のワンタイム認証鍵を保持するように制御される。よって、携帯端末がサーバと通信不能な環境下にあっても、ユーザが車両を使用できなくなってしまう恐れを低減できる。加えて、上記構成によれば、携帯端末が保持するワンタイム認証鍵は有効期限に基づいて定期的に入れ替えられる。当該構成によれば、有効なワンタイム認証鍵が経時的に変更されるため、セキュリティをより一層強固にすることができる。

また、本開示の車両用デジタルキー管理方法は、ユーザによって携帯される情報処理端末である携帯端末（１）と、車両に搭載されて使用される車両用装置（４）と、車両を使用するための鍵情報として、携帯端末ごとに固有のサービス鍵を生成するサーバ（３）と、によって実行される車両用デジタルキー管理方法であって、サーバが、携帯端末からの要求に基づき、携帯端末のサービス鍵をもとに、複数の使い捨てのワンタイム認証鍵を生成し、有効期限付きで携帯端末に配信することと、携帯端末が、サーバからワンタイム認証鍵を受信し、所定の端末側記憶装置（１０５）に保存することと、携帯端末が、ワンタイム認証鍵ごとの有効期限に基づき、定期的に端末側記憶装置に保存されているワンタイム認証鍵の一部又は全部を入れ替えることと、車両用装置が、サーバ又は携帯端末との通信により、携帯端末が保有するワンタイム認証鍵のうちの何れか１つを特定することと、車両用装置が、特定されたワンタイム認証鍵を用いて携帯端末の正当性を判断することと、を含む。

上記方法によれば、車両用デジタルキーシステムと同様の作用により、セキュリティをより一層強固にすることができる。

本開示の車両用装置は、車両を使用する権限を有する人物であるユーザによって携帯される情報処理端末である携帯端末（１）、及び、車両を使用するための鍵情報として携帯端末ごとに固有のサービス鍵を生成するサーバ（３）のそれぞれの通信可能に構成された、車両に搭載されて使用される車両用装置であって、ユーザごとのサービス鍵が保存されている車両側記憶装置（４５）と、少なくとも１つのプロセッサを用いてなる車両制御部（４０）と、を含み、車両制御部は、車両側記憶装置に保存されているサービス鍵に基づいて、使い捨ての認証鍵であるワンタイム認証鍵を生成することと、ワンタイム認証鍵を用いて携帯端末の正当性を判断することと、を実行するように構成されている。

上記車両用装置によれば、携帯端末ごとに固有のサービス鍵をもとに生成される、ワンタイム認証鍵を用いて携帯端末（ひいてはユーザ）の認証を行うため、固定的な鍵情報を用いて携帯端末の認証を行う構成に比べてセキュリティを高める事ができる。

本開示の携帯端末は、車両に搭載されて使用される車両用装置（４）、及び、車両を使用するための鍵情報としてのサービス鍵を生成するサーバ（３）のそれぞれの通信可能に構成された、ユーザによって携帯される情報処理端末である携帯端末であって、サービス鍵のデータを記憶している端末側記憶装置（１０５）と、車両用装置と所定の近距離無線通信規格に準拠した無線通信である近距離無線通信を実施するための近距離通信部（１６）と、インターネットを介してサーバと通信するためのネット接続部（１７，１８）と、少なくとも１つのプロセッサを用いてなる端末制御部（１０）と、を備え、端末制御部は、インターネットに接続できていることを条件として、サーバに対し、サービス鍵を元に生成される有効期限付きのワンタイム認証鍵を複数まとめて配信するように要求する認証鍵要求信号を送信することと、サーバからワンタイム認証鍵を受信して端末側記憶装置に保存することと、ワンタイム認証鍵ごとの有効期限に基づき、端末側記憶装置に保存されているワンタイム認証鍵の一部又は全部を入れ替えることと、を実施するように構成されている。

上記携帯端末によれば、車両用デジタルキーシステムと同様の作用により、セキュリティをより一層強固にすることができる。

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

車両用デジタルキーシステムの全体像を示す図である。 携帯端末の構成を示すブロック図である。 端末制御部の機能ブロック図である。 専用キーの構成を示すブロック図である。 デジタルキーサーバの構成を示すブロック図である。 車両データベースに格納されるデータの種類の一例を示す図である。 ユーザデータベースに格納されるデータの種類の一例を示す図である。 データ処理部の機能ブロック図である。 車両とオーナ鍵とゲスト鍵の関係を説明するための図である。 車載システムの構成を示すブロック図である。 認証ＥＣＵの機能ブロック図である。 サービス鍵の発行及び登録にかかる処理の全体像を説明するための図である。 オーナ鍵の発行処理を説明するためのシーケンス図である。 オーナ鍵を車両に登録する処理を説明するためのシーケンス図である。 オーナ鍵を車両へ登録するための携帯端末の表示画面の一例を示す図である。 車両との通信接続にかかる携帯端末の表示画面の一例である。 ゲスト鍵の発行処理を説明するためのシーケンス図である。 ゲスト鍵発行要求信号に含まれるべき情報の一例を示す図である。 ゲスト端末に向けて送信される端末登録用パッケージに含まれるべき情報の一例を示す図である。 ゲスト鍵を車両に登録する処理を説明するためのシーケンス図である。 ゲスト鍵を車両に登録するための携帯端末の表示画面の一例を示す図である。 駐車中における認証ＥＣＵの作動例を説明するためのフローチャートである。 認証ＥＣＵが携帯端末を認証する処理の一例を示すシーケンス図である。 認証ＥＣＵが携帯端末を認証する処理の他の例を示すシーケンス図である。 携帯端末がワンタイム認証鍵を補充する処理のシーケンス図である。 携帯端末が鍵情報記憶部に保管されているワンタイム認証鍵を入れ替える処理のシーケンス図である。 認証ＥＣＵが実施する、ＥＣＵ時刻の修正及び有効期限に基づくゲスト鍵の削除を説明するためのシーケンス図である。 サービス鍵の削除にかかるシーケンスの全体像を説明するための図である。 オーナ鍵を削除する際の携帯端末とＤＫＳとのインタラクションを示すシーケンス図である。 オーナ鍵を削除する際のオーナ端末と認証ＥＣＵとのインタラクションを示すシーケンス図である。 ゲスト鍵を削除する際の携帯端末とＤＫＳとのインタラクションを示すシーケンス図である。 ゲスト鍵を削除する際の携帯端末と認証ＥＣＵとのインタラクションを示すシーケンス図である。 車載ＨＭＩを介してサービス鍵を削除する場合の一連の処理の流れを示すシーケンス図である。 発行件つきゲスト鍵が削除された場合のＤＫＳの作動例を説明するための図である。 オーナが所持する携帯端末が機種変更された場合のＤＫＳの作動を説明するためのフローチャートである。

以下、本開示の車両用デジタルキーシステムＳｙｓについて図を用いて説明する。車両用デジタルキーシステムＳｙｓは、車両Ｈｖを利用するための電子的な鍵であるサービス鍵を携帯端末１に配布することにより、ユーザが専用キー２を持たずとも車両Ｈｖへのアクセスを可能とするためのシステムである。車両用デジタルキーシステムＳｙｓは、図１に示すように、携帯端末１、専用キー２、デジタルキーサーバ（ＤＫＳ：Digital Key Server）３、及び、車両Ｈｖに搭載された車載システム７を含む。車載システム７は、認証ＥＣＵ４を含む。ＥＣＵはElectronic Control Unitの略であって、電子制御装置を指す。

＜前置き＞
以下の説明における車両Ｈｖは、一例として個人によって所有される車両である。もちろん、車両Ｈｖは会社組織が保有する社用車や、公的機関が保有する公用車であってもよい。さらに、車両Ｈｖは、貸出サービスに供される車両（いわゆるレンタカー）であってもよいし、カーシェアリングサービスに供される車両（いわゆるシェアカー）であってもよい。車両Ｈｖは、ロボットタクシーなど、旅客輸送サービスに供される車両でもよい。

車両Ｈｖは例えばエンジン車である。もちろん、車両Ｈｖは、ハイブリッド車や、電気自動車であってもよい。ここでのエンジン車は動力源としてエンジンのみを備える車両を指し、ハイブリッド車は動力源としてエンジンとモータを備える車両を指す。電気自動車は、モータのみを駆動源として備える車両を指す。本開示における走行用電源とは、車両Ｈｖが走行するための電源であって、車両がエンジン車である場合にはイグニッション電源を指す。車両Ｈｖが電気自動車やハイブリッド車である場合、システムメインリレーが走行用電源に相当する。本開示は四輪自動車に限らず、トレーラや、二輪自動車、三輪自動車等、道路上を走行可能な多様な車両に搭載可能である。原動機付き自転車も二輪自動車に含めることができる。

以下では、主として１つの車両Ｈｖを対象に車両用デジタルキーシステムＳｙｓの説明を行うが、ＤＫＳ３が管理する車両は複数存在しうる。また、１人のオーナが保持する車両Ｈｖは複数存在してもよい。

本開示のユーザとは、車両用デジタルキーシステムＳｙｓが提供するサービスの利用者を指す。車両用デジタルキーシステムＳｙｓが提供するサービスを利用するためのアカウントを作成済みの人物、換言すれば、後述するデジタルキーアプリ１０４をインストール済みの携帯端末１の所有者がユーザに相当する。

本開示の種々のシーケンス図及びフローチャートは何れも一例である。各シーケンス図／フローチャートが備えるステップ数や処理順序、実行条件等は適宜変更可能である。

＜全体像の概略＞
携帯端末１は、複数のユーザのそれぞれによって所持／携帯されうる汎用的な情報処理端末である。図１に示す携帯端末１ａは車両Ｈｖのオーナが所持する携帯端末１を示している。携帯端末１ｂは例えばオーナの家族が所有する携帯端末１であり、携帯端末１ｃはオーナの友人が所持する携帯端末１である。携帯端末１には、端末毎に固有の識別情報であるデバイスＩＤが割り当てられている。

デバイスＩＤとしては例えばデバイスアドレスや、ＵＵＩＤ（Universally Unique Identifier）などを採用可能である。なお、Bluetooth（登録商標）におけるデバイスアドレスは、４８ビットで表現されうる。また、ＵＵＩＤは１２８ビットで表現されうる。デバイスアドレスは、固定的なパブリックアドレスであってもよいしランダムアドレスであってもよい。パブリックアドレスはEthernet（登録商標）におけるＭＡＣ（Media Access Control）アドレスに相当する。その他、デバイスＩＤは、後述するデジタルキーアプリ１０４のインストール時に決定される乱数であってもよい。

携帯端末１は、無線基地局８及び広域通信ネットワーク９を介してＤＫＳ３とデータ通信可能に構成されている。図１に示す無線基地局８は、例えばセルラー通信用の基地局であっても良いし、Ｗｉ－Ｆｉ（登録商標）用のアクセスポイントであってもよい。アクセスポイントは、無線ＬＡＮ（Local Area Network）を形成する通信設備である。アクセスポイントの概念にはルーターの他、路側機も含めることができる。広域通信ネットワーク９は、例えばインターネットである。広域通信ネットワーク９を形成する設備にとって、携帯端末１はユーザ装置（ＵＥ：User Equipment）に相当する。

セルラー通信とは、例えば４Ｇや５Ｇといった規格に準拠した無線通信を指す。Ｗｉ－Ｆｉの規格としては、ＩＥＥＥ８０２．１１ｎやＩＥＥＥ８０２．１１ａｃ、ＩＥＥＥ８０２．１１ａｘ（いわゆるＷｉ－Ｆｉ６）など、多様な規格を採用可能である。本開示ではＷｉ－Ｆｉ（登録商標）規格に準拠した無線通信をＷｉ－Ｆｉ通信とも記載する。携帯端末１とＤＫＳ３との通信は、暗号化されたセルラー通信又はＷｉ－Ｆｉ通信で実施される。

ＤＫＳ３は、車両Ｈｖの外部に配置されたサーバである。ＤＫＳ３は、広域通信ネットワーク９に接続可能に構成されている。ＤＫＳ３は、広域通信ネットワーク９を介して携帯端末１と相互通信を行いうる。ＤＫＳ３は、携帯端末１からの要求に基づき、所定のユーザに対して車両Ｈｖを使用するためのサービス鍵を発行する。

また、車載システム７と携帯端末１は、近距離無線通信を実施可能に構成されている。ここでの近距離無線通信とは、実質的な通信可能距離が例えば５ｍから３０ｍ、最大でも１００ｍ程度となる所定の近距離無線通信規格に準拠した通信を指す。近距離無線通信の規格としては、例えばＢＬＥ（Bluetooth Low Energy）や、Bluetooth Classic、Wi-Fi（登録商標）、ZigBee（登録商標）等を採用することができる。近距離無線通信の方式としては、ＵＷＢ－ＩＲ（Ultra Wide Band - Impulse Radio）も採用可能である。本実施形態では一例として車載システム７と携帯端末１は、ＢＬＥ規格に準拠した無線通信であるＢＬＥ通信を実施可能に構成されている場合を例にとって各部の作動を説明する。以下におけるＢＬＥ通信との記載は、近距離無線通信と置き換えて実施することができる。通信接続及び暗号通信などにかかる通信方法の細部はＢＬＥ規格で規定されるシーケンスによって実施される。

なお、以下では車載システム７が携帯端末１との通信におけるマスターとして振る舞うように設定されている場合について説明する。携帯端末１は、スレーブとして振る舞う。ＢＬＥ通信におけるスレーブは、間欠的にアドバタイズ信号を送信するとともに、マスターからの要求に基づいてデータの送受信を実行するデバイスである。スレーブは、ペリフェラルとも称される。マスターは、スレーブとの通信接続状態や通信タイミングを制御する。マスターは、セントラルとも称される。他の態様として、携帯端末１が車載システム７との通信におけるマスターとして動作するように設定されていても良い。

車載システム７は、ＢＬＥ通信を行うためのＢＬＥ通信部５７と認証ＥＣＵ４とを含む。認証ＥＣＵ４は、車載システム７を構成するＥＣＵの１つである。認証ＥＣＵ４が車両用装置に相当する。認証ＥＣＵ４は、サービス鍵を有する携帯端末１と無線通信による自動的な認証処理を行う。そして、認証が成功していることを条件として、車両Ｈｖに対するユーザの位置に応じた車両制御を実施するパッシブエントリパッシブスタート機能を提供する。ここでの車両制御とは、ドアの施錠／開錠、電源オン／オフ、エンジン始動などである。なお、携帯端末１はユーザに対応するものであるため、携帯端末１を認証することは、ユーザを認証することに相当する。

＜サービス鍵の説明＞
サービス鍵は、携帯端末１毎に相違する。例えばサービス鍵は、デバイスＩＤに応じて定まる、携帯端末１ごとに異なるコードである。サービス鍵は、所定の文字数を備える英数字の羅列とする事ができる。例えばＤＫＳ３は、デバイスＩＤに所定の長さを有する乱数を加えた値を、所定のハッシュ関数に入力して得られる出力値をサービス鍵として採用する。ハッシュ関数としては、ＦＮＶ１３２や、ＦＮＶ１６４、ＭＤ－５、ＳＨＡ－１、ＳＨＡ－２５６、ＳＨＡ－５１２など多様な関数を採用可能である。サービス鍵の生成に使用する関数は、サービス鍵として必要とされるビット数（出力長）に合わせて適宜選択されうる。

サービス鍵は８ビット以上の長さを有するビット列で表現されうる。サービス鍵は長いほどそのセキュリティ性が強固となり好適である。サービス鍵は例えば１６バイト、２４バイト、２７バイトなどで表現されうる。ここでは一例として、サービス鍵は、２４バイトで構成されるものとする。サービス鍵を２７バイト以下とする構成によればサービス鍵を１つのＢＬＥ暗号通信パケットに収容可能となる。

なお、サービス鍵は、車両Ｈｖと携帯端末１の組み合わせ毎に異なる値とすることが好ましい。例えば車両ＩＤとデバイスＩＤを結合した値を入力値とする所定のハッシュ関数の出力値をサービス鍵としてもよい。車両ＩＤは車両ごとに割り当てられる固有の識別番号である。車両ＩＤとしては例えば車両識別コード（ＶＩＮ：Vehicle Identification Number）などを採用可能である。

さらにサービス鍵は、車両ＩＤとデバイスＩＤにさらに、発行要求を受け付けたエポック秒に対応する値を連結したデータを所定のハッシュ関数に入力して得られる出力値であってもよい。また、必ずしもサービス鍵の生成にハッシュ関数を使用する必要はない。サービス鍵は、デバイスＩＤに車両ＩＤを乗算、加算、又は連結して得られる値であってもよい。サービス鍵の材料としては、その他、ユーザが設定したパスワードなども採用可能である。例えばサービス鍵は、ユーザが登録した所定文字数のパスワードを所定のハッシュ関数に入れた値であっても良い。

サービス鍵には、複数の種類が存在する。サービス鍵の種類としては大きくはオーナ鍵とゲスト鍵がある。オーナ鍵は、車両Ｈｖのオーナに対して発行されるサービス鍵であって、概ね車両Ｈｖの使用に関する全ての権限を有する。オーナ鍵は、走行用電源のオンオフやドアの施開錠、遠隔操作など、車両Ｈｖの使用にかかる全ての権限を有するとともに、他のユーザのためのサービス鍵を発行する権限を有する。また、オーナ鍵は基本的に有効期限が設定されていない、無期限のサービス鍵である。

ゲスト鍵はゲストのためのサービス鍵であって、基本的にはオーナによって発行される。ここでのゲストとはオーナ以外のユーザを指す。ゲスト鍵は、オーナ鍵よりも権限が制限されたサービス鍵であって、有効期限も設定される。

ゲスト鍵は、より細かくは、他のゲスト鍵を発行する権限を有する発行権付きゲスト鍵と、他のゲスト鍵の発行権限を有さない発行権なしゲスト鍵に区分される。ユースケースの一例として、オーナの家族に対しては、オーナからの要求に基づき発行権付きゲスト鍵が発行されうる。また、オーナの友人／知人などに対しては発行権なしゲスト鍵が発行されうる。

以降ではオーナが所持する携帯端末１、換言すればオーナ鍵が保存されている携帯端末１をオーナ端末と称する。ゲストが所持する携帯端末１、換言すればゲスト鍵が保存されている携帯端末１をゲスト端末と称する。また、ゲスト端末のうち、発行権付きゲスト鍵が付与されている携帯端末１のことを発行権付きゲスト端末と称し、発行権なしゲスト鍵が付与されている携帯端末１のことを発行権なしゲスト端末と称する。図１に示す例においては携帯端末１ａがオーナ端末に相当し、携帯端末１ｂが発行権付きゲスト端末に相当する。また、携帯端末１ｃが発行権なしゲスト端末に相当する。

オーナ端末を親とすると、オーナ端末が発行したゲスト鍵を有する携帯端末１は、オーナ端末にとっての子に相当する。また発行権付き端末が発行したゲスト鍵を有する携帯端末１はオーナ端末にとっての孫に相当する。各ゲスト鍵の権限は、発行元によって決定される。ゲスト鍵の権限は、発行元よりも小さく（狭く）設定される。ただし、車両用デジタルキーシステムＳｙｓは他の態様として、発行元と同等の権限を有するゲスト鍵を発行可能に構成されていても良い。ＤＫＳ３は、オーナ端末又は発行権付きゲスト端末からの要求に基づき、ゲスト鍵を新規発行する。新規発行されたサービス鍵のタイプや権限設定は、発行元によって指定される。例えばＤＫＳ３は、オーナ端末からの要求に基づきゲスト鍵を新規発行する際、当該ゲスト鍵を発行権付きゲスト鍵とするか発行権なしゲスト鍵とするかは、オーナ端末から受信した信号に基づいて決定する。なお、発行権付きゲスト鍵は、発行権なしゲスト鍵しか発行できないように制限される。

＜携帯端末の構成及び機能について＞
ここではまず携帯端末１が備える構成／機能について図２を用いて説明する。携帯端末１としては、例えば、スマートフォンや、タブレット端末、ウェアラブルデバイスなどを採用することができる。ウェアラブルデバイスは、ユーザの身体に装着されて使用されるデバイスであって、リストバンド型、腕時計型、指輪型、メガネ型、イヤホン型など、多様な形状のものを採用可能である。

携帯端末１は、端末制御部１０、ディスプレイ１１、タッチパネル１２、慣性センサ１３、生体認証装置１４、近接場通信部１５、ＢＬＥ通信部１６、セルラー通信部１７、及びＷｉ－Ｆｉ通信部１８を備える。

端末制御部１０は、携帯端末１全体の動作を制御するモジュールである。端末制御部１０は、例えば端末プロセッサ１０１、ＲＡＭ（Random Access Memory）１０２、ストレージ１０３等を備えた、コンピュータとして構成されている。端末プロセッサ１０１はＲＡＭ１０２と結合された演算処理のためのハードウェア（換言すれば演算コア）である。端末プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）である。端末プロセッサ１０１は、ユーザが使用するデバイスで使用されるプロセッサであるため、ユーザプロセッサあるいはＵＥプロセッサと呼ぶことができる。端末プロセッサ１０１は、ＲＡＭ１０２へのアクセスにより、後述する各機能部の機能を実現するための種々の処理を実行する。ＲＡＭ１０２は揮発性の記憶媒体である。ストレージ１０３は、フラッシュメモリ等の不揮発性の記憶媒体を含む構成である。

デジタルキーアプリ１０４は、ユーザの認証や、サービス鍵の取得／保存、車載システム７との通信等をセキュアに行うためのアプリケーションソフトウェアである。デジタルキーアプリ１０４は、例えばストレージ１０３などにインストールされている。

端末制御部１０は、ディスプレイ１１、タッチパネル１２、慣性センサ１３、生体認証装置１４、近接場通信部１５、ＢＬＥ通信部１６、セルラー通信部１７、及びＷｉ－Ｆｉ通信部１８のそれぞれと相互通信可能に構成されている。端末制御部１０が備える機能については後述する。

ディスプレイ１１は、例えば液晶ディスプレイや有機ＥＬディスプレイである。ディスプレイ１１は端末制御部１０からの入力信号に応じた画像を表示する。タッチパネル１２は、静電容量式のタッチパネルであって、ディスプレイ１１に積層されている。タッチパネル１２及びディスプレイ１１は、ユーザが携帯端末１に鍵情報を登録したり、携帯端末１と車載システム７とをペアリングしたりするためのインターフェースに相当する。タッチパネル１２は入力装置である。タッチパネル１２が出力する信号は、携帯端末１に対するユーザの操作に対応する。以降では、タッチパネル１２の出力信号を操作信号とも記載する。

慣性センサ１３は、携帯端末１に作用する慣性力を検出するセンサである。加速度センサやジャイロセンサが慣性センサ１３に相当する。慣性センサ１３の出力（検出データ）は端末制御部１０に入力される。

生体認証装置１４は、例えばユーザの指紋や、顔画像などを用いて、ユーザを認証する装置である。生体認証装置１４は、手や指の静脈パターンや、虹彩パターンを用いてユーザを認証する装置であってもよい。また生体認証装置１４は、例えば声紋など、発話音声の特徴を用いて認証を行う装置であってもよい。ユーザの認証結果は、端末制御部１０に提供される。

近接場通信部１５は、ＮＦＣ（Near Field Communication）の規格に従った無線通信である近接場通信を実施するための通信モジュールである。ここでの近接場通信とは、通信可能な距離が数ｃｍから数十ｃｍ程度となる通信を指す。近接場通信は、ＢＬＥ通信よりも通信可能な距離が十分に小さい通信方式に相当する。通信可能な距離が十分に小さい通信方式とは、通信距離が１０分の１以下となる通信方式を指す。近接場通信を実現するための具体的な通信規格としては、例えばISO/IEC 14443やISO/IEC 18092等の多様な規格を採用することができる。近接場通信は、Type-F規格に適合するものであっても良いし、Type-A又はType-B規格に適合するものであってもよい。Type-F規格は、いわゆるFeliCa（登録商標）に相当する。携帯端末１において近接場通信部１５は任意の要素であって省略されても良い。

ＢＬＥ通信部１６は、ＢＬＥ通信を実施するための通信モジュールである。ＢＬＥ通信部１６、５７が近距離通信部に相当する。セルラー通信部１７は、セルラー通信を実施するための通信モジュールである。セルラー通信部１７は、例えばＬＴＥ等の無線通信プロトコルにおけるデータリンクレイヤ及び物理レイヤを担当する通信モジュールである。セルラー通信部１７は、無線基地局８との接続状況、例えば通信圏外か否かなどを示す情報を端末制御部１０に提供する。

Ｗｉ－Ｆｉ通信部１８は、Ｗｉ－Ｆｉ通信を実施可能に構成されている。Ｗｉ－Ｆｉ通信部１８は、アクセスポイントを介して広域通信ネットワーク９に接続可能に構成されている。Ｗｉ－Ｆｉは所定の無線ＬＡＮ規格の一種である。故に、Ｗｉ－Ｆｉ通信部１８は、無線ＬＡＮ規格に準拠した通信を実施するための通信モジュールである、無線ＬＡＮモジュールに相当する。

種々の通信モジュールは、送受信の対象とする周波数帯の電波を送受信可能なアンテナや、通信を制御するマイクロコンピュータである通信マイコン、変復調回路などを備える。なお、携帯端末１は、ＤＫＳ３との通信手段として、セルラー通信と、Ｗｉ－Ｆｉ通信の少なくとも何れか一方を実施可能に構成されていればよい。携帯端末１は、セルラー通信部１７とＷｉ－Ｆｉ通信部１８の両方を備えている必要はない。セルラー通信又はＷｉ－Ｆｉ通信にて携帯端末１が広域通信ネットワーク９に接続された、いわゆるオンラインの状態にある場合、端末制御部１０はＤＫＳ３と種々のデータ通信を行う。データ通信は、例えば、ＴＬＳ（Transport Layer Security）を用いた暗号通信によって実施されうる。セルラー通信部１７及びＷｉ－Ｆｉ通信部１８がネット接続部に相当する。

端末制御部１０は、端末プロセッサ１０１がデジタルキーアプリ１０４を実行することで発現される機能部として図３に示すようにサービス鍵管理部Ｆ１、ワンタイム認証鍵管理部Ｆ２、及び車両応答部Ｆ３を備える。各種機能部は、デジタルキーアプリ１０４がユーザを認証している状態において有効となりうる。

ユーザの認証（ログイン）は、デジタルキーアプリ１０４に対して所定のユーザＩＤとパスワードを入力することによって行われうる。ユーザの認証は、生体認証装置１４を用いて実施されても良い。デジタルキーアプリ１０４は車両用デジタルキーシステムＳｙｓの一部であるため、デジタルキーアプリ１０４にユーザがログインしている状態は、車両用デジタルキーシステムＳｙｓにユーザがログインしている状態に対応する。なお、ログイン状態はログインから所定の有効期限が過ぎた場合に解除され、デジタルキーアプリ１０４はユーザの再認証が必要なログオフ状態に遷移するものとする。

また、端末制御部１０は端末側記憶部１０５を備える。端末側記憶部１０５は、サービス鍵など、デジタルキーアプリ１０４が使用する種々のデータが格納される記憶領域である。端末側記憶部１０５は、ストレージ１０３又はＲＡＭ１０２が備える記憶領域を用いて実現される。端末側記憶部１０５は、鍵情報記憶部Ｍ１と、車両用データ一時記憶部Ｍ２とを備える。鍵情報記憶部Ｍ１は、サービス鍵や後述するワンタイム認証鍵、ユーザＩＤなどを格納するための記憶領域である。車両用データ一時記憶部Ｍ２は、ＤＫＳ３から受信した車両Ｈｖへ転送するためのデータを一時的に保存するための記憶領域である。端末側記憶部１０５が端末側記憶装置に相当する。

サービス鍵管理部Ｆ１は、ＤＫＳ３が発行した自端末のユーザ用のサービス鍵を管理する。本開示における自端末とは、端末制御部１０から見て自身が設けられている携帯端末１を指す。サービス鍵管理部Ｆ１は、タッチパネル１２から入力される操作信号に基づいて、自端末向けのサービス鍵の発行を要求したり、自端末用のサービス鍵を削除したりする。自端末向けのサービス鍵とは自端末のユーザのためのサービス鍵に相当する。

サービス鍵管理部Ｆ１は、ＤＫＳ３から自端末向けのサービス鍵を取得し、鍵情報記憶部Ｍ１に保存する。サービス鍵管理部Ｆ１は、サービス鍵の取得時、サービス鍵そのものとともに、付加的な情報である鍵関連情報を取得する。鍵関連情報とは、例えば、サービス鍵ＩＤや、有効期限、権限設定、タイプなどを指す。これらの情報は１つのデータセットとしてパッケージ化されて配信されうる。

サービス鍵ＩＤとは、サービス鍵を識別するための番号である。サービス鍵ＩＤは、たとえばユーザ毎にユニークな値が設定される。サービス鍵ＩＤは、アカウント作成時に生成された乱数であってもよい。仮にオーナが携帯端末１の機種変更を行ってサービス鍵の値が変更されたとしても、オーナに紐づくサービス鍵ＩＤは変更されない。なお、サービス鍵ＩＤは、車両ＩＤとユーザＩＤの組み合わせに応じたユニークな値に設定されても良い。

有効期限データは、無期限を示す所定値、又は、発行元が指定した期間／日付を示す。権限設定データは、自端末のユーザに許可されている機能（つまり権限）を示す。権限設定データは、例えばドアごとの施開錠の可否、走行用電源のオン／オフの可否などを示す。サービス鍵タイプはオーナ鍵かゲスト鍵かを示す。タイプ情報は権限設定データと統合されていても良い。

サービス鍵管理部Ｆ１は、自端末向けのサービス鍵の取得の他、自端末用のサービス鍵に関するステータス確認画面を表示する処理や、自端末向けのサービス鍵を削除するための処理を実行する。ステータス確認画面は、自端末用のサービス鍵のステータスを示す画面である。サービス鍵のステータスには、有効期限や、権限設定、有効／無効状態などが含まれる。ステータス確認画面に、発行元に相当するユーザの名称等に関する情報を含みうる。

なお、サービス鍵管理部Ｆ１が提供する機能は、自端末に割り当てられているサービス鍵のタイプ、換言すればサービス鍵の権限設定によって相違しうる。例えばオーナ端末のサービス鍵管理部Ｆ１は、ユーザが指定したゲスト用のゲスト鍵を発行するための処理や、ゲスト鍵を削除／一時的に無効化する処理を実行可能に構成されている。なお、オーナ端末に限っては、ゲスト鍵の発行時に、権限設定の一種として、ゲスト鍵を発行する権限の有無を指定可能に構成されている。また、オーナ端末のサービス鍵管理部Ｆ１は、車両Ｈｖにかかるサービス鍵を保有するゲストのリストや、各ゲスト鍵のステータスを示す画面を表示する。オーナ端末は、例えばＤＫＳ３よりゲスト鍵の情報を取得して表示しうる。さらに、オーナ端末のサービス鍵管理部Ｆ１は、ＤＫＳ３から取得する所定のデータセットを用いて、オーナ鍵に関する情報を車両Ｈｖに登録する処理も実施可能に構成されている。

また、発行権付き端末が備えるサービス鍵管理部Ｆ１は、ユーザが指定したゲストに対して発行権なしゲスト鍵を新規発行する処理を実行可能に構成されている。また、発行権付き端末が備えるサービス鍵管理部Ｆ１は、自分自身が発行したゲスト鍵のステータス確認や、当該ゲスト鍵の削除／無効化などを実行可能に構成されている。発行権なし端末のサービス鍵管理部Ｆ１は、ステータス確認や、自端末用のサービス鍵の削除／無効化が実施可能に構成されている。その他、ゲスト端末のサービス鍵管理部Ｆ１は、有効期限データに基づき、自端末用のサービス鍵の有効期限の確認を実施しうる。なお、ゲスト鍵の有効期限チェックはＤＫＳ３が実施してもよい

ワンタイム認証鍵管理部Ｆ２は、ＤＫＳ３から、車両Ｈｖとの認証処理に使用するワンタイム認証鍵を取得し、鍵情報記憶部Ｍ１に保存する。ワンタイム認証鍵管理部Ｆ２そのものは、ワンタイム認証鍵を生成する機能を備えない。当該構成によればワンタイム認証鍵の生成方法の詳細を秘匿化することができる。ひいては車両用デジタルキーシステムＳｙｓのセキュリティ性能を高めることができる。

ワンタイム認証鍵は、サービス鍵に、変動コード（変動因子）を組み合わせることによって得られるコードである。変動コードは、発行ごとに異なる値である。変動コードは、例えばエポック秒や、発行回数のカウント値、又は乱数とすることができる。さらに、変動コードは、所定の初期値から認証鍵の発行回数を減算した値であってもよい。仮にワンタイム認証鍵をＫａ、サービス鍵をＳＫ、変動コードをＣｄ、ワンタイム認証鍵の生成関数をＧとすると、ワンタイム認証鍵は、Ｋａ＝Ｇ（ＳＫ，Ｃｄ）で表現されうる。この場合、生成関数Ｇは、サービス鍵と変動コードの２つの入力を取る関数である。生成関数Ｇは、１つの入力値をとる関数であっても良く、その場合には、例えばＫａ＝Ｇ（ＳＫ＋Ｃｄ）等によってワンタイム認証鍵は生成されうる。ＳＫ＋Ｃｄは、サービス鍵と変動コードを単純につなぎ合わせた（つまり連結させた）コードであってもよいし、それらに対応する数列を２進数又は１６進数の概念で加算したものであってもよい。

なお、ワンタイム認証鍵を生成するための第１因子をサービス鍵とすると、変動コードはワンタイム認証鍵を生成するための第２因子と呼ぶことができる。変動コードは、認証鍵生成因子の１つである。さらに、ワンタイム認証鍵は、サービス鍵と変動コードの他に、所定の第３の因子を用いて生成されても良い。例えばワンタイム認証鍵は、発行回数を示すカウント値と、ＥＣＵ番号と、サービス鍵とを所定の順に結合してなるビット列を、所定の関数に入力することで生成されても良い。ワンタイム認証鍵は、１回使用されると破棄される、いわゆる使い捨ての認証鍵である。第３の因子は、認証ＥＣＵ４に事前に登録される情報であることが好ましい。

ワンタイム認証鍵管理部Ｆ２は、鍵情報記憶部Ｍ１に、所定数以上のワンタイム認証鍵が保存されている状態が維持されるよう、ＤＫＳ３に対してワンタイム認証鍵の配信を要求する信号を随時送信する。例えばワンタイム認証鍵管理部Ｆ２は、鍵情報記憶部Ｍ１に保存されているワンタイム認証鍵の残数（Ｎｏｔｋ）が所定の補充閾値（ＴｈＲｐ）未満となったことに基づいて、補充要否フラグをオンに設定する。ワンタイム認証鍵管理部Ｆ２は、補充要否フラグがオンに設定されており、且つ、オンライン状態であることに基づいて、ＤＫＳ３との通信により、複数のワンタイム認証鍵を取得する。補充閾値は例えば１５０や３００とすることができる。補充要否フラグは任意の要素であって、省略されても良い。補充閾値ＴｈＲｐは、２００や、４００、５００であってもよい。

なお、ワンタイム認証鍵には、発行日を起算とする有効期限が設定される。有効期限は例えば１ヶ月や３ヶ月、６ヶ月に設定されうる。ワンタイム認証鍵の有効期限もまたＤＫＳ３によって設定される。ＤＫＳ３は、オーナの指示操作に基づき、ワンタイム認証鍵に対する有効期限の長さを変更可能に構成されていても良い。仮に車両Ｈｖがレンタカーである場合には、ワンタイム認証鍵の有効期限はレンタル期間に対応するように設定されうる。なお当該技術思想はゲスト鍵の有効期限設定にも同様に適用可能である。

ワンタイム認証鍵管理部Ｆ２は、所定のタイミングで鍵情報記憶部Ｍ１に保存されているワンタイム認証鍵の有効期限をチェックし、有効期限切れとなっているワンタイム認証鍵については削除する。ワンタイム認証鍵の有効期限チェックはＤＫＳ３が実施してもよい。なお、期限切れのワンタイム認証鍵を削除した結果として、ワンタイム認証鍵の残数が補充閾値未満となった場合には、補充要否フラグをオンに設定するなど、ＤＫＳ３からワンタイム認証鍵を取得するための処理を実施する。

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

また、車両応答部Ｆ３は、認証ＥＣＵ４からの要求に基づき、認証ＥＣＵ４とＤＫＳ３との通信を中継する処理を行う。例えば車両応答部Ｆ３は、認証ＥＣＵ４からＢＬＥ通信で受信した時刻要求信号を、セルラー通信のフォーマットに変換してＤＫＳ３に送信する。また、ＤＫＳ３から受信した認証ＥＣＵ４向けのデータ、例えばサーバ時刻情報などを、ＢＬＥ通信のフォーマットに変換して認証ＥＣＵ４に転送する。

その他、携帯端末１は、近接場通信によって、車載システム７との認証処理を実行可能に構成されていても良い。携帯端末１は、近接場通信によって車載システム７とＢＬＥ通信にかかるペアリングを実施するように構成されていても良い。また、端末制御部１０は、デジタルキーアプリ１０４の機能として、車両Ｈｖのステータスを確認する画面である車両状態確認画面を表示可能に構成されていてもよい。車両状態確認画面は、ガソリン／バッテリの残量や、各窓及び各ドアの開閉状態、施錠状態、車内温度などを示す画面である。また、端末制御部１０は、車両Ｈｖが備える電装設備の一部を遠隔操作可能に構成されていても良い。例えば空調装置のオン／オフや、窓の開閉、ハザードランプの点灯／消灯などを遠隔操作可能に構成されていても良い。なお、車両状態確認や遠隔操作可能な内容は、サービス鍵の権限に応じて変更されても良い。

＜専用キーの構成及び機能について＞
ここでは専用キー２の構成及び機能について図４を用いて説明する。専用キー２は、車両Ｈｖを操作するための専用の電子キーである。専用キー２は、車両Ｈｖの購入時に、車両Ｈｖのオーナであることの証、又は、実体を有するマスターキーとして、車両Ｈｖとともにオーナに提供される。専用キー２は、基本的にオーナによって所持される。専用キー２は車両Ｈｖの付属物の１つと解することができる。専用キー２は、扁平な直方体型や、扁平な楕円体型（いわゆるフォブタイプ）、カード型など、多様な形状を採用可能である。専用キー２は、車両用携帯機、キーフォブ、キーカード、カードキー、アクセスキーなどと呼ばれうる。

専用キー２には、車両Ｈｖの鍵であることを証明する所定のコードである専用キーコードが登録されている。専用キーコードは、認証ＥＣＵ４にも登録されている。専用キー２は、認証ＥＣＵ４と所定の手順で通信することにより、車両Ｈｖにアクセスしようとしている人物がオーナであることを証明可能に構成されている。なお、専用キー２は任意の要素であって、省略されても良い。

専用キー２は、図４に示すように制御回路２０、及び近接場通信部２１を備える。制御回路２０は、専用キー２の動作を制御する回路である。制御回路２０は、ＭＣＵ（Micro Controller Unit）２０１、ＲＡＭ２０２、フラッシュメモリ２０３などを用いて実現されている。制御回路２０はＭＣＵの代わりに、ＭＰＵ（Micro-Processing Unit）やＦＰＧＡ（Field-Programmable Gate Array）を用いて実現されていてもよい。フラッシュメモリ２０３には前述の専用キーコードが保存されている。

近接場通信部２１は、近接場通信を実施するための通信モジュールである。専用キー２は、例えば車両Ｈｖが備える近接場通信部５６からの電波を電力に変換して機能するパッシブ型の無線タグとして構成されている。制御回路２０は、車両Ｈｖが備える近接場通信部５６と近接場通信部２１が通信接続している場合、認証ＥＣＵ４からの要求に基づき、専用キーコードそれ自体又は専用キーコードをもとに生成されるレスポンスコードを返送する。認証ＥＣＵ４は、専用キーコードを用いた認証処理が成功したことに基づいて、オーナ登録可能な状態に遷移しうる。このように専用キー２は、認証ＥＣＵ４をオーナ情報の登録が可能な状態に切り替えるためのデバイスとして機能しうる。

＜ＤＫＳの構成及び機能について＞
ここではＤＫＳ３の構成及び機能について説明する。ＤＫＳ３は図５に示すように、データ処理部３０、ネットワーク接続装置３１、車両ＤＢ３２、及びユーザＤＢ３３を備える。部材名称中のＤＢは、データベース（Database）の略である。

データ処理部３０は、ネットワーク接続装置３１から入力される信号／データに基づき多様な処理を実行する構成である。データ処理部３０はネットワーク接続装置３１、車両ＤＢ３２、及びユーザＤＢ３３のそれぞれと相互通信可能に接続されている。データ処理部３０は、サーバプロセッサ３０１、ＲＡＭ３０２、ストレージ３０３を用いて構成されている。サーバプロセッサ３０１は、各種演算処理を実行する演算コアであって、例えばＣＰＵやＧＰＵなどを用いて実現されている。ストレージ３０３には、所定のデジタルキー管理プログラムが格納されている。サーバプロセッサ３０１が当該デジタルキー管理プログラムを実行することにより、後述する種々の機能部が実現される。なお、サーバプロセッサ３０１が当該デジタルキー管理プログラムを実行することは、当該プログラムに対応する方法である車両用デジタルキー管理方法が実行されることに対応する。

ネットワーク接続装置３１は、広域通信ネットワーク９に接続するための通信モジュールである。ネットワーク接続装置３１は、例えば光ファイバなどを用いて広域通信ネットワーク９を構成する通信設備と相互通信可能に構成されている。これにより、携帯端末１がオンライン状態である場合、ＤＫＳ３は携帯端末１とデータ通信可能となる。

車両ＤＢ３２は、車両用デジタルキーシステムＳｙｓが管理する車両についての情報が登録されるデータベースである。車両ＤＢ３２には図６に示すように、車両ごとの車両ＩＤが、車両モデル情報や、オーナ情報、ゲスト情報と対応付けられて保存されている。車両モデル情報は、対象車両の車種や、年式、グレード、ＯＳ（Operating System）などにかかる情報を含む。

車両モデル情報は、認証ＥＣＵ４で使用されるソフトウェアのバージョンや、ＥＣＵ番号などを含んでいても良い。ここでのＥＣＵ番号は、複数の車両のそれぞれで使用される認証ＥＣＵ４を区別するための番号であって、認証ＥＣＵ４毎に相違する番号である。ＥＣＵ番号としては認証ＥＣＵ４の製造番号などを採用可能である。ＤＫＳ３は、ＥＣＵ番号を用いることで、仮に複数の車両Ｈｖに同一モデルの認証ＥＣＵ４が搭載されている場合であっても、特定の認証ＥＣＵ４を対象としたデータ配信などを実行可能となる。

オーナ情報は、車両Ｈｖのオーナについての情報であって、例えばユーザＩＤや、連絡先としての電話番号、メールアドレス、デバイスＩＤなどを含む。ゲスト情報は、車両Ｈｖに関するサービス鍵が配布されているユーザ（つまりゲスト）についての情報である。例えば車両ＤＢ３２には車両Ｈｖについてのゲスト情報として、ゲスト毎のユーザＩＤなどが登録されている。なお、車両ＤＢ３２は、ゲスト情報を備えていなくともよい。

ユーザＤＢ３３は、ユーザについての情報が登録されるデータベースである。ユーザＤＢ３３には、ユーザ毎のユーザデータとして、図７に示すように、ユーザＩＤ、パスワード、デバイスＩＤ、鍵関連情報、備考情報などが保存される。ユーザＩＤとパスワードは、ユーザを認証するためのデータセットである。ユーザＩＤとパスワードは、例えばアカウント作成時にユーザによって登録される。サービス利用のためのアカウントは、専用のウェブページ又はデジタルキーアプリ１０４を介して作成可能である。ユーザが所持する携帯端末１のデバイスＩＤは、例えばＤＫＳ３がデジタルキーアプリ１０４と通信することで登録されうる。

鍵関連情報は、例えば対象車両情報や、サービス鍵ＩＤ、サービス鍵、鍵属性、権限設定、オーナ鍵ＩＤを含む。対象車両情報は、ユーザが使用可能な車両のＩＤを示す。車両毎のサービス鍵情報が車両ＤＢ３２で管理される場合、ユーザＤＢ３３は鍵関連情報として対象車両情報を備えていなくとも良い。鍵タイプは、例えばオーナ鍵であるか、ゲスト鍵であるかなどを示す。鍵タイプは、対象車両に対するユーザの属性（オーナ／ゲスト）を示す情報と解することもできる。権限設定は前述の通り、施開錠可能なドアや、走行用電源のオン／オフが許可されているか否かなどを示す。オーナ鍵ＩＤは、対象車両のオーナのサービス鍵ＩＤを示す。オーナ鍵ＩＤがオーナ鍵番号に相当する。オーナのユーザデータにおけるオーナ鍵ＩＤの欄は空白であってもよいし、当該オーナ自身のサービス鍵ＩＤが登録されてもよい。

備考欄は、年齢や、運転技能の習熟度などが登録されうる。運転技能の習熟度は初心者か否か、例えば運転免許を取得してから１年以内か否かなどが登録されうる。その他、備考欄には事故の履歴などが登録されていても良い。これらの備考情報は、仮にカーシェアリングサービスなどに適用した場合の利用料金や、保険料金などの算出材料として使用されうる。

車両ＤＢ３２及びユーザＤＢ３３は何れも書き換え可能な不揮発性の記憶媒体を用いて実現されている。また、車両ＤＢ３２及びユーザＤＢ３３は何れもサーバプロセッサ３０１によるデータの書き込み、読出、削除等が実施可能に構成されている。なお、車両ＤＢ３２とユーザＤＢ３３は統合されていても良い。上述したデータベースの構成は一例である。車両ＤＢ３２及びユーザＤＢ３３は、上述した項目を全て保持している必要はない。また、車両ＤＢ３２は、別のサーバが備えていても良い。そもそも、本開示のＤＫＳ３は、複数のサーバに分けて実施されても良い。サーバ毎の役割分担／機能配置は適宜変更可能である。

データ処理部３０は、機能部として図８に示すように、ユーザ管理部Ｇ１、ユーザ認証部Ｇ２、サービス鍵発行部Ｇ３、ワンタイム認証鍵発行部Ｇ４、サービス鍵削除部Ｇ５、及び機種変更受付部Ｇ６を備える。

ユーザ管理部Ｇ１は、ユーザ情報を管理する構成である。例えばユーザ管理部Ｇ１は、ユーザの新規登録、削除、登録内容の変更をネットワーク接続装置３１から入力されるデータに基づいて実施する。ユーザの新規登録／削除とはアカウントの発行／削除に対応する。新規登録、削除、登録内容の変更にかかるユーザ操作／指示は例えば携帯端末１及びネットワーク接続装置３１を介して取得する。

以降ではアカウントの作成や削除、登録内容の変更、サービス鍵の発行／削除／無効化等といった、車両用デジタルキーシステムＳｙｓに対するユーザの操作／指示に対応する信号のことを、簡略的に操作信号とも記載する。もちろん、ユーザの操作を直接的に受け付けるインターフェースは携帯端末１に限定されない。ＤＫＳ３は、オフィスや家庭に設置されたコンピュータを介して上記操作信号を取得しうる。つまりＤＫＳ３は、デジタルキーアプリ１０４や専用のウェブページを介してユーザの操作信号を取得可能に構成されている。

ユーザ認証部Ｇ２は、ユーザＩＤとパスワードとの組み合わせからユーザを認証する処理を実施する。ユーザ認証部Ｇ２が、認証成功と判定していることに基づいて、サービス鍵発行部Ｇ３やワンタイム認証鍵発行部Ｇ４、サービス鍵削除部Ｇ５、機種変更受付部Ｇ６などは、ユーザの操作信号又はデジタルキーアプリ１０４からの要求に応じた処理を実行する。

サービス鍵発行部Ｇ３は、携帯端末１等に対するユーザ操作に基づき、サービス鍵を発行する。具体的には、オーナ端末や発行権付きゲスト端末から送信されてくるサービス鍵の発行要求信号に基づき、要求内容に応じたサービス鍵を発行する。ワンタイム認証鍵発行部Ｇ４は、携帯端末１から送信されてくるワンタイム認証鍵発行要求信号に基づき、要求元用のワンタイム認証鍵を発行する。サービス鍵削除部Ｇ５は、携帯端末１からの要求に基づき、指定されたサービス鍵を削除する。機種変更受付部Ｇ６は、機種変更の申請を受け付け、新たなデバイスＩＤに応じたサービス鍵を発行する構成である。

ワンタイム認証鍵発行部Ｇ４、サービス鍵削除部Ｇ５、及び機種変更受付部Ｇ６の詳細は別途後述する。

データ処理部３０は以上の機能部を備えることにより、システムが管理する車両毎のオーナとゲストとの対応関係を保持する。１つの車両に対して、オーナとなるユーザはただ１人である一方、ゲストは複数存在しうる。データ処理部３０は、１つの車両及びオーナに紐づくゲストの情報を統合的に管理する。

図９は１つの車両に対するオーナ鍵とゲスト鍵との対応関係を概念的に示したものである。データ処理部３０は、オーナ鍵のサービス鍵ＩＤ、つまりオーナ鍵ＩＤを元に、１つの車両及び１つのオーナ鍵に紐づく複数のゲスト鍵を管理する。なお、図９では１つの車両に対して３つのゲスト鍵が発行されている場合を示している。各ゲスト鍵は前述の通り、権限設定や有効期限が相違しうる。

＜車載システム７の構成及び機能について＞
ここでは車載システム７の構成及び機能について説明する。図１０に示すように車載システム７は、認証ＥＣＵ４、ディスプレイ５１、入力装置５２、ボディＥＣＵ５３、ロックモータ５４、電源ＥＣＵ５５、近接場通信部５６、ＢＬＥ通信部５７、及びセルラー通信部５８を備える。

認証ＥＣＵ４は、ディスプレイ５１、入力装置５２、ボディＥＣＵ５３、電源ＥＣＵ５５、近接場通信部５６、ＢＬＥ通信部５７、及びセルラー通信部５８のそれぞれと車両内ネットワークＮｗを介して又は専用の信号線によって相互通信可能に接続されている。ボディＥＣＵ５３はロックモータ５４と通信可能に接続されている。車両内ネットワークＮｗは、車両Ｈｖ内に構築されている通信ネットワークである。車両内ネットワークＮｗの規格としては、Controller Area Network（以降、ＣＡＮ：登録商標）や、Ethernet（登録商標）、FlexRay（登録商標）など、多様な規格を採用可能である。なお、ボディＥＣＵ５３などの一部は、車両内ネットワークＮｗを介さずに認証ＥＣＵ４と専用線で接続されていてもよい。装置同士の接続形態は適宜変更可能である。

認証ＥＣＵ４は、ＢＬＥ通信部５７等との協働により、携帯端末１の認証処理を実行するＥＣＵである。また、認証ＥＣＵ４は、携帯端末１の認証が成功していることを条件として、ドアの開錠や走行用電源オンなどといった、所定の車両制御を他のＥＣＵとの協働により実施する。認証ＥＣＵ４は上記処理を実行するコアモジュールとして車両制御部４０を備える。

当該認証ＥＣＵ４は、コンピュータを用いて実現されている。すなわち、認証ＥＣＵ４は、認証プロセッサ４１、ＲＡＭ４２、ストレージ４３、Ｉ／Ｏ４４、及びこれらの構成を接続するバスラインなどを備えている。認証プロセッサ４１は、例えばＣＰＵである。認証プロセッサ４１は、ＲＡＭ４２へのアクセスにより、後述する各機能部の機能を実現するための種々の処理を実行する。認証プロセッサ４１とＲＡＭ４２を含む構成が車両制御部４０に相当する。認証プロセッサ４１は、サーバプロセッサ３０１と対比して、車両プロセッサと呼ぶこともできる。ストレージ４３には、車両Ｈｖにアクセスするユーザ（実態的には携帯端末）の認証処理にかかるプログラムである車両用認証プログラムが格納されている。また、ストレージ４３には、認証ＥＣＵ４のＥＣＵ番号が保存されていてもよい。Ｉ／Ｏ４４は、他装置と通信するための回路モジュールである。認証ＥＣＵ４の機能の詳細は後述する。

ディスプレイ５１は、画像を表示するデバイスである。例えばディスプレイ５１は認証ＥＣＵ４からの入力に基づき、オーナ登録開始画面やサービス鍵削除画面などを表示しうる。オーナ登録開始画面は、オーナ鍵の登録を開始するための操作画面であって、例えばオーナのパスワードを入力するフォームなどを含みうる。サービス鍵削除画面は、ユーザにて指定されたサービス鍵のデータを車両側記憶部４５から削除するための画面である。認証ＥＣＵ４が保持するオーナ鍵のデータもまた、当該サービス鍵削除画面を介して削除可能に構成されている。ディスプレイ５１は、例えばインストゥルメントパネルの車幅方向の中央領域に設けられた、センターディスプレイである。ディスプレイ５１は、運転席の正面領域に配置された、いわゆるメータディスプレイであってもよい。

入力装置５２は、車載システム７、より具体的には認証ＥＣＵ４に対するユーザの指示操作を受け付けるための装置である。入力装置５２としては、例えばディスプレイ５１に積層されたタッチパネルを採用可能である。入力装置５２はステアリングホイールやインストゥルメントパネル等に設けられた機械的スイッチであっても良い。入力装置５２は、当該装置に対してユーザが行った操作に対応する電気信号を操作信号として認証ＥＣＵ４に出力する。入力装置５２が出力する操作信号は、ユーザの操作内容を示す。ディスプレイ５１及び入力装置５２は、認証ＥＣＵ４に対するサービス鍵の登録／削除／動作設定の変更などをユーザが行うためのインターフェースに相当する。ディスプレイ５１及び入力装置５２をまとめて、車載ＨＭＩ５０とも称する。ＨＭＩはヒューマンマシンインターフェース（Human Machine Interface）の略である。

ボディＥＣＵ５３は、認証ＥＣＵ４からの要求及びユーザの操作信号に基づいてボディ系アクチュエータを制御するＥＣＵである。ボディＥＣＵ５３は、種々のボディ系アクチュエータと通信可能に接続されている。ここでのボディ系アクチュエータには、各ドアのロック機構を構成するロックモータ５４が含まれる。

電源ＥＣＵ５５は、車両Ｈｖに搭載された走行用電源のオンオフ状態を制御するＥＣＵである。例えば電源ＥＣＵ５５は、例えば認証ＥＣＵ４からの指示信号に基づき、走行用電源をオンに設定する。なお、車両Ｈｖがエンジン車である場合には、電源ＥＣＵ５５は上記指示信号に基づきエンジンを始動させる。

近接場通信部５６は、近接場通信を実施するための通信モジュールである。近接場通信部５６は、専用キー２からデータを受信するためのリーダとしての機能を有している。近接場通信部５６は、通信距離内の専用キー２に近接場通信によってアクセスし、オーナ検証にかかる情報、例えば専用キーコード又は専用キーコードに基づくレスポンスコードを受信する。近接場通信部５６は、専用キー２に限らず、携帯端末１等、通信圏内に位置する多様なデバイスとも近接場通信を実施しうる。

近接場通信部５６としては、例えば車外用の通信モジュールと、車内用のモジュールとが設けられうる。車外用の近接場通信部５６は、施開錠制御に向けた認証を行うための構成に相当する。車内用の近接場通信部５６は、走行用電源のオンオフ制御に向けた認証を行うための構成に相当する。車外用の近接場通信部５６は、例えば運転席用の外側ドアハンドル付近に設けられている。外側ドアハンドル付近とは例えば外側ドアハンドルから０．２ｍ以内を指す。外側ドアハンドル付近には、外側ドアハンドルの内部も含まれる。また、車内用の近接場通信部５６は、車室内の運転席周りに配置されている。例えば車室内用の近接場通信部５６は、インストゥルメントパネルに配されたスタートボタン付近に配置されている。車内用の近接場通信部５６は、スタートボタンに内蔵されていてもよい。さらに、近接場通信部５６は、センターコンソールや、インストゥルメントパネルの車幅方向中央部に設けられていても良い。

ＢＬＥ通信部５７は、ＢＬＥ通信を実施するための通信モジュールである。ＢＬＥ通信部５７は、例えばセンターコンソールや、車内の天井部、フロント／リアガラスの上端部、Ｃピラーなどに配置されている。セルラー通信部５８はセルラー通信を実施するための通信モジュールである。車載システム７は、セルラー通信部５８の代わりに、又は、セルラー通信部５８と合わせて、Ｗｉ－Ｆｉ通信用のモジュールを備えていても良い。

認証ＥＣＵ４は、ＤＫＳ３及び携帯端末１と通信することにより、ユーザの認証にかかる処理を実行する。なお、認証ＥＣＵ４と携帯端末１との通信は、より具体的には、携帯端末１が備えるＢＬＥ通信部１６と、車載システム７が備えるＢＬＥ通信部５７の協働によって実現されうる。

認証ＥＣＵ４は、図１１に示すように機能部として、ユーザ管理部Ｈ１、及び、認証処理部Ｈ２を備える。これらの機能部は例えば認証プロセッサ４１が車両用認証プログラムを実行することによって実現される。また、認証ＥＣＵ４は、オーナ鍵等を記憶するための車両側記憶部４５を備える。車両側記憶部４５は、ストレージ４３又はＲＡＭ４２が備える記憶領域を用いて実現される。車両側記憶部４５は、オーナ鍵記憶部４５１と、ゲスト鍵記憶部４５２とを備える。

オーナ鍵記憶部４５１は、オーナ鍵に関する情報を格納するための記憶領域である。ゲスト鍵記憶部４５２は、ゲスト鍵に関する情報を格納するための記憶領域である。オーナ／ゲスト鍵に関する情報とは、サービス鍵そのものの他、サービス鍵ＩＤや、ユーザＩＤ、ユーザ名などを指す。ゲスト鍵に関する情報には、有効期限や権限設定なども含まれる。ゲスト鍵記憶部４５２は複数のゲスト鍵を保存可能に構成されている一方、オーナ鍵記憶部４５１は１つのオーナ鍵しか保存できないように構成されている。故に、新規オーナ鍵の登録は、古いオーナ鍵のデータ削除を伴う。車両側記憶部４５が車両側記憶装置に相当する。

ＤＫＳ３が発行したサービス鍵は、車両側記憶部４５に登録されることによって、有効化される。すなわち、ユーザは、当該ユーザ向けのサービス鍵が車両側記憶部４５に保存されていることを条件として、サービス鍵に割り当てられている権限の範囲において車両Ｈｖを利用可能となる。

ユーザ管理部Ｈ１は、車両Ｈｖを利用可能なユーザ、つまり、車両側記憶部４５に保存されているサービス鍵を管理する構成である。ユーザ管理部Ｈ１は、別途後述するように、携帯端末１とＢＬＥ通信を実施することにより、携帯端末１を介してＤＫＳ３が発行したサービス鍵に関するデータを取得し、車両側記憶部４５に保存する。また、ユーザ管理部Ｈ１は、携帯端末１を介して車両側記憶部４５に保存されているサービス鍵を削除するためのデータを取得し、対象となるサービス鍵に関するデータを削除する。

認証ＥＣＵ４は、動作モードとして、オーナ鍵の登録を受付可能なオーナ登録可能モードと、オーナ登録を受け付けない／拒否するオーナ登録禁止モードとを備える。認証ＥＣＵ４は、基本的にはオーナ登録禁止モードで動作する。そのため、オーナ登録禁止モードは通常モードと呼ぶことができる。認証ＥＣＵ４は、別途後述するセキュリティ解除コードが入力されたことに基づいて、一時的にオーナ登録禁止モードからオーナ登録可能モードへと移行する。

認証処理部Ｈ２は、ＢＬＥ通信部５７と連携して、通信相手が車両Ｈｖのユーザが所持する携帯端末１であることを確認（換言すれば認証）する処理を実施する。認証のための通信は、暗号化されて実施される。認証方式自体は、チャレンジ－レスポンス方式など多様な方式を用いて実施されうる。本実施形態では一例として、チャレンジコードとワンタイム認証鍵を用いたチャレンジ－レスポンス方式で認証が行われる。認証処理の詳細なシーケンスについては別途後述する。認証処理部Ｈ２は、認証処理で必要となるワンタイム認証鍵を動的に生成するワンタイム認証鍵生成部Ｈ２１をサブ機能部として備える。なお、ワンタイム認証鍵生成部Ｈ２１は任意の要素であって省略されても良い。

認証処理部Ｈ２が認証処理を実施するタイミングは、例えばＢＬＥ通信部５７と携帯端末１との通信接続が確立したタイミングとすることができる。認証処理部Ｆ４は、ＢＬＥ通信部５７と携帯端末１とが通信接続している間、所定の周期で認証処理を実施するように構成されていても良い。また、車両Ｈｖに対する所定のユーザ操作をトリガとして認証処理のための暗号通信を実施するように構成されていても良い。

認証処理の実行トリガとなるユーザ操作としては、ドアボタンの押下／ドアハンドルへのタッチ、スタートボタンの押下、ドアの開閉などが採用可能である。ドアボタンとは、ドアハンドルに設けられた、ドアを開錠／施錠するためのボタンを指す。ドアハンドルのへのタッチは、ドアハンドルに設けられたタッチセンサによって検出されうる。スタートボタンは、インストゥルメントパネルなどの車室内に設けられた、走行用電源のオン／オフを切り替えるためのボタンである。

＜オーナ鍵登録シーケンスについて＞
ここでは図１２、図１３、及び図１４を用いてオーナ鍵の発行から車両へ登録するまでのシーケンスの一例について説明する。オーナ鍵の発行から車両へ登録するまでのシーケンスは、図１２に示すように大きくは発行フェーズＰｈ１と、車両登録フェーズＰｈ２に分けることができる。

発行フェーズＰｈ１は、ＤＫＳ３が、ユーザからの要求、実態的には携帯端末１から送信される鍵発行要求信号に基づき、サービス鍵を発行するフェーズである。発行されたサービス鍵は、携帯端末１にのみ配布される。ＤＫＳ３が発行したサービス鍵は、車両Ｈｖに直接配布されることはなく、携帯端末１を経由して車両Ｈｖに登録される。車両登録フェーズＰｈ２は、ＢＬＥ通信によって携帯端末１が保持しているサービス鍵の情報を車両Ｈｖに登録するフェーズである。ＤＫＳ３が発行したサービス鍵は車両Ｈｖに登録されて初めて実質的に使用可能な状態、つまり有効化される。そのため車両登録フェーズＰｈ２は、有効化フェーズと呼ぶこともできる。なお、オーナ鍵に限らず、ゲスト鍵の発行～有効化も、発行フェーズＰｈ１と、車両登録フェーズＰｈ２とを含む。

図１３は、オーナ鍵の発行フェーズに対応する各デバイスのインタラクションを示すシーケンス図である。オーナ鍵の発行シーケンスは、オーナ端末とＤＫＳ３によって実行される。オーナ鍵の発行シーケンスは図１３に示すように、ステップＳ１０～Ｓ１７を含む。

ステップＳ１０は、ＤＫＳ３が、ユーザ／携帯端末１を認証し、通信相手がオーナ／オーナ端末であることを確認するステップである。オーナであることの認証は、ユーザＩＤ及びパスワードを用いて実施されても良いし、生体情報を用いて認証されても良い。生体情報を用いた認証は、生体認証装置１４によって実行されうる。なお、ステップＳ１０は携帯端末１のデジタルキーアプリ１０４がユーザを認証するステップであってもよい。

ステップＳ１１は、オーナ端末としての携帯端末１が、ユーザの操作に基づいて鍵発行要求信号を送信するステップである。ここで送信される鍵発行要求信号は、オーナ鍵の発行を要求する信号であるため、オーナ鍵発行要求信号と呼ぶことができる。鍵発行要求信号は、例えばデバイスＩＤ又はユーザＩＤなど、ＤＫＳ３が要求元を特定するための情報を含む。また、鍵発行要求信号は、発行対象とするサービス鍵のタイプを含む。なお、発行対象とするサービス鍵がゲスト鍵である場合には、鍵発行要求信号は、権限の設定や有効期限の設定などを示す情報を追加的に含みうる。その他、鍵発行要求信号は、対象とする車両の情報などを含んでいても良い。ただし、対象車両の情報は、ユーザＩＤなどを検索キーとして車両ＤＢ３２を参照することにより特定可能であるため、鍵発行要求信号に含まれていなくとも良い。

ステップＳ１２では、ＤＫＳ３が、オーナ端末から取得したオーナ鍵発行要求信号に基づいて、オーナ鍵としてのサービス鍵及びサービス鍵ＩＤを生成する。ステップＳ１２の実行主体は、より具体的にはサービス鍵発行部Ｇ３である。

ステップＳ１３ではＤＫＳ３が、ステップＳ１２で生成したサービス鍵をもとに、ワンタイム認証鍵を所定数作成する。ステップＳ１３の実行主体は、より具体的にはワンタイム認証鍵発行部Ｇ４である。サービス鍵発行時に生成するワンタイム認証鍵の数である初回発行数は、例えば３００など、補充閾値よりも所定量多く設定されている。

ステップＳ１４ではＤＫＳ３が、ステップＳ１２～Ｓ１３で生成した各種データを含むデータセットである端末登録用パッケージをオーナ端末に向けて送信する。端末登録用パッケージは、サービス鍵、サービス鍵ＩＤ、複数のワンタイム認証鍵、及び、各ワンタイム認証鍵の生成に用いた変動コードを含む。個々のワンタイム認証鍵は、当該ワンタイムの生成に使用された変動コードと紐付けられている。複数のワンタイム認証鍵及び変動コードを含むデータセットは、認証鍵パッケージとしてサービス鍵を含むデータセットとは別に送信されても良い。

また、端末登録用パッケージは、端末チェックコードと、対象車両に搭載されている認証ＥＣＵ４のＥＣＵ番号を含みうる。端末チェックコードは、データの完全性、受信データの正当性、及び改ざんの有無を、受信側である携帯端末１が検証するためのコードである。端末チェックコードは、ハミング符号であってもよいし、ペイロードを所定のハッシュ関数に入力して得られるハッシュ値であってもよい。端末チェックコードは、ＤＫＳ３と携帯端末１とが暗号通信するための鍵として事前に発行された暗号鍵を用いて生成されても良い。

ステップＳ１５では、オーナ端末としての携帯端末１が、ＤＫＳ３から配信された端末登録用パッケージを受信し、その中身を鍵情報記憶部Ｍ１に保存するステップである。サービス鍵管理部Ｆ１は、前述の端末チェックコードを用いて受信データの正当性を検証した上で、受信したサービス鍵及びその関連情報を鍵情報記憶部Ｍ１に保存する。

ステップＳ１６は、ＤＫＳ３が、車両Ｈｖにオーナ情報を登録するためのデータセットである車両登録用パッケージをオーナ端末に向けて送信する。車両登録用パッケージは、サービス鍵、サービス鍵ＩＤの他、車両チェックコードを含みうる。車両チェックコードは、データの完全性、受信データの正当性、及び改ざんの有無を、最終的な受信デバイスである認証ＥＣＵ４が検証するためのコードである。車両チェックコードは、端末チェックコードと同様にペイロードに応じたハミング符号やハッシュ値であってもよい。車両チェックコードは、ＤＫＳ３と認証ＥＣＵ４とが暗号通信するための鍵として事前に発行された暗号鍵を用いて生成されても良い。また、車両チェックコードは、ＥＣＵ番号をもとに生成されてもよい。なお、車両登録用パッケージには、端末チェックコードが付加されていても良い。当該構成によれば、ＤＫＳ３と認証ＥＣＵ４との通信の中継役であるオーナ端末も、受信した車両登録用パッケージの完全性、正当性等を検証可能となる。

ステップＳ１７では、オーナ端末としての携帯端末１が、ＤＫＳ３から配信された車両登録用パッケージを受信し、その中身を車両用データ一時記憶部Ｍ２に保存するステップである。受信処理には、前述の端末チェックコードを用いた検証処理が行われてもよい。なお、本実施形態では車両登録用パッケージと端末登録用パッケージを別々に送信するが、各種データの送信態様はこれに限らない。車両登録用パッケージと端末登録用パッケージは一連のデータとして送信されても良い。その際、重複するデータは省略されても良い。

次の図１４を用いてオーナ鍵を車両Ｈｖに登録するシーケンスについて説明する。オーナ鍵の車両Ｈｖへの登録シーケンスは、ステップＳ２０～Ｓ２９を含む。

まず本シーケンス開始時の初期状態（ステップＳ２０）として、認証ＥＣＵ４はオーナ登録禁止モード（つまり通常モード）で動作している。ステップＳ２１は、所定のセキュリティ解除ツール又はＤＫＳ３が、所定のセキュリティ解除信号を認証ＥＣＵ４に入力するステップである。セキュリティ解除ツール又はＤＫＳ３を用いた認証ＥＣＵ４へのセキュリティ解除信号の入力は、オーナ又はディーラスタッフによって実行される。

セキュリティ解除信号は、セキュリティ解除コードを含む信号である。セキュリティ解除信号は、１つの局面において、登録者がオーナ自身であることを証明する信号に相当する。セキュリティ解除信号は、認証ＥＣＵをオーナ登録禁止モード（通常モード）から、一時的にオーナ登録可能モードに切り替えるための信号に相当する。認証ＥＣＵ４はセキュリティ解除信号が入力されたことに基づいて、オーナ登録可能モードに移行する（ステップＳ２２）。セキュリティ解除信号がオーナ登録開始信号に相当する。

セキュリティ解除ツールは、例えば専用キー２である。また、セキュリティ解除コードとしては専用キーコードを採用可能である。例えば認証ＥＣＵ４は、車内用の近接場通信部５６が専用キー２と近接場通信を行い、専用キーコードを受信したことに基づいて、オーナ登録可能モードに移行してもよい。なお、認証ＥＣＵ４は、専用キーコードを受信したことに加えて、車載ＨＭＩ５０を介して所定のパスワードが入力されたことを条件に、オーナ登録可能モードに移行するよう構成されていても良い。

また、セキュリティ解除ツールは、ディーラショップなどで管理される専用ツールであってもよい。専用ツールと認証ＥＣＵ４との通信方式は、近接場通信であってもよいし、例えばＵＳＢケーブルなどを用いた有線通信であってもよい。ＤＫＳ３からのセキュリティ解除信号は、セルラー通信部５８を介して受信する。なお、ＤＫＳ３は、オーナ端末からの要求、又は、ディーラショップに設けられた所定の端末からの要求に基づいて、車両Ｈｖを宛先とするセキュリティ解除信号を送信する。当該構成によればオーナ又はディーラショップのスタッフは、オーナ端末又はディーラショップに設けられた所定の端末を操作することにより、認証ＥＣＵ４をオーナ登録可能モードに切り替えることができる。

認証ＥＣＵ４は、オーナ登録モードに移行すると、ステップＳ２４ａとして所定のスキャン間隔でＢＬＥ通信部５７を待受状態に設定し、携帯端末１の探索（いわゆるスキャニング）を実施させる。ここでの待受状態とは、アドバタイズ信号を受信可能な状態を指す。本実施形態ではパッシブスキャン方式にて車両周辺に存在する携帯端末１を検出する。他の態様として認証ＥＣＵ４は、スキャン要求の送信を伴うアクティブスキャン方式によって携帯端末１を探索しても良い。

一方、オーナ端末は、タッチパネル１２を介してオーナ鍵の登録開始操作を受け付ける（ステップＳ２３）と、オーナ鍵の登録に向けたアドバタイズの発信を所定の間隔で発信する（ステップＳ２４ｂ）。当該アドバタイズがＢＬＥ通信部５７を介して認証ＥＣＵ４で受信されることにより、認証ＥＣＵ４と携帯端末１は通信接続のための通信を開始する（ステップＳ２５）。なお、オーナ鍵の登録開始操作とは、例えば図１５に示すように、ディスプレイ１１に表示されるオーナ鍵登録開始ボタンＢ１の押下である。オーナ鍵の登録開始操作は、オーナ鍵の登録開始を指示する音声コマンドの入力であってもよい。

オーナ端末は、認証ＥＣＵ４とＢＬＥ通信の接続が確立すると、例えば図１６に示すペアリング確認画面を表示する。ペアリング確認画面は例えばペアリングを実行するか否かをユーザが選択するためのボタンＢ２ａ、Ｂ２ｂを含む。オーナ端末は、タッチパネル１２からの信号に基づき肯定ボタンＢ２ａが押下されたことを検知すると（ステップＳ２６）、認証ＥＣＵ４とのペアリング処理を実行する（ステップＳ２７）。これにより、認証ＥＣＵ４とオーナ端末との間で暗号化されたデータ通信が可能となる。ここでのペアリング処理には、暗号鍵の交換だけでなく、暗号鍵の保存（いわゆるボンディング）も含まれる。

ペアリング処理が完了し、認証ＥＣＵ４－オーナ端末間の暗号通信リンクが確立すると、オーナ端末は、車両用データ一時記憶部Ｍ２に保管されていた車両登録用パッケージをＢＬＥ通信で認証ＥＣＵ４に送信する（ステップＳ２８）。ステップＳ２４ａ～Ｓ２８までの一連の通信が、認証ＥＣＵ４にとってはオーナ端末からオーナ鍵を取得するための通信に相当する。

認証ＥＣＵ４は、オーナ端末からＢＬＥ通信で車両登録用パッケージを受信すると、当該パッケージに含まれる鍵関連データを車両側記憶部４５に保存する。より具体的には、受信したサービス鍵や、サービス鍵ＩＤ、をオーナ鍵記憶部４５１に保存する。これにより、オーナ鍵の車両登録が完了し、オーナ鍵が有効化される。

なお、オーナ登録禁止モードは、例えばオーナ権限を有するサービス鍵の受信又は保存を拒否することによって実現されてもよいし、通信接続そのものを拒否することで実現されても良い。また、１つの態様として認証ＥＣＵ４は、所定のオーナ登録用ＩＤを含むアドバタイズを起点とする通信リンクで受信したサービス鍵を、オーナ鍵としてオーナ鍵記憶部４５１に保存するように構成されていてもよい。その場合、認証ＥＣＵ４は、オーナ登録禁止モード時にはオーナ登録用ＩＤを含むアドバタイズを無視する一方、オーナ登録モードにはオーナ登録用ＩＤを含むアドバタイズに基づく通信接続を行う。オーナ登録用ＩＤは、オーナ情報を登録するための通信であることを示すＩＤであって、ＵＵＩＤ、Ｍａｊｏｒ、Ｍｉｎｏｒといった３種類の識別子の組み合わせで表現されうる。

上記の構成によれば、特定のオーナ登録開始信号が入力された場合にしか、オーナ鍵のデータが車両Ｈｖには登録されない。よって、オーナ鍵を常時登録可能な構成よりもセキュリティを高めることができる。

＜ゲスト鍵登録シーケンスについて＞
次に、図１７、図１８、図１９、図２０を用いてゲスト鍵の発行から、当該ゲスト鍵を車両Ｈｖに登録するまでのシーケンスの一例について説明する。ゲスト鍵の発行から車両登録するまでのシーケンスもまた、発行フェーズＰｈ１と、車両登録フェーズＰｈ２とに分けることができる。

図１７は、ゲスト鍵の発行フェーズＰｈ１に対応する各デバイスのインタラクションを示すシーケンス図である。ゲスト鍵の発行シーケンスは、オーナ端末と、対象ゲスト端末と、ＤＫＳ３によって実行される。対象ゲスト端末とは、サービス鍵の発行対象とするゲストに紐づく携帯端末１を指す。ゲスト鍵の発行シーケンスは図１７に示すように、ステップＳ３０～Ｓ３７を含む。

ゲスト鍵の発行及び車両への登録シーケンスの説明におけるゲスト端末とは、対象ゲスト端末を指す。なお以下ではオーナがゲスト鍵を発行する場合について説明するが、ゲスト鍵の発行者は、発行権付きゲスト鍵が付与されているゲストであってもよい。発行権付きゲスト鍵が付与されているゲストのことを、発行権もちゲストとも記載する。ゲスト鍵の発行等の説明におけるオーナ端末／オーナとの記載は、発行権付きゲスト端末／発行権もちゲストと読み替えて実施することができる。

ステップＳ３０は、サービス鍵の発行を希望するゲストの操作に基づいて、ゲスト端末が、オーナ端末に向けてゲスト鍵の発行依頼を送信するステップである。オーナ端末はゲスト端末からの発行依頼を受領すると、ＤＫＳ３に向けて、ゲスト鍵発行要求信号を送信する（ステップＳ３１）。なお、図示は省略しているが、ゲスト鍵の発行シーケンスもまた、ＤＫＳ３が、オーナとしてのユーザを認証するステップを含みうる。また、ステップＳ３０は任意の要素である。ゲスト端末からの発行依頼がなくとも、オーナ端末はオーナの操作に基づき所定のゲストを対象とするゲスト鍵発行要求信号を送信しうる。例えばオーナは、ゲストとの電話／メール等のやり取りに基づいてオーナ端末を操作することにより、任意のゲストに対してゲスト鍵を発行可能に構成されている。

ゲスト鍵発行要求信号は、例えば図１８に示すように、要求元情報、対象車両情報、対象ユーザＩＤ、有効期限情報、及び権限の設定情報のそれぞれを収容するデータフィールドを含む。要求元情報は、ゲスト鍵の発行要求元を示す情報であって、例えばオーナのユーザＩＤや、サービス鍵ＩＤ、デバイスＩＤなどを採用可能である。対象車両ＩＤは、新規発行するゲスト鍵で利用可能な車両を特定するための情報であって、ここでは車両Ｈｖの車両ＩＤを指す。対象ユーザＩＤは、ゲスト鍵の発行対象とするゲストのユーザＩＤである。ユーザＩＤの代わりにデバイスＩＤなどが対象ユーザ情報として採用されてもよい。有効期限に対応するデータフィールドには、オーナが指定した期間／日時に対応する値、又は所定値が入力される。権限設定情報は、ゲスト鍵の発行権の有無、走行用電源の切り替え権限の有無、施開錠できるドアなどを示す。

ＤＫＳ３は、オーナ端末からのゲスト鍵発行要求信号を受信すると、ステップＳ３２として、受信したゲスト鍵発行要求信号に基づいて、対象ゲスト向けのサービス鍵及びサービス鍵ＩＤを生成する。また、ステップＳ３３ではＤＫＳ３のワンタイム認証鍵発行部Ｇ４が、ステップＳ３２で生成したサービス鍵をもとに、ワンタイム認証鍵を所定の初回発行数だけ作成する。

ステップＳ３４ではＤＫＳ３が、ステップＳ３２～Ｓ３３で生成した各種データを含むデータセットである端末登録用パッケージをゲスト端末に向けて送信する。ゲスト鍵にかかる端末登録用パッケージは、例えば図１９に示すように、基本情報に加えて、ゲスト用情報を含みうる。基本情報は、オーナ鍵発行時に配信されるパッケージと概ね同様の項目を有する。つまり基本情報は、サービス鍵、サービス鍵ＩＤ、複数のワンタイム認証鍵、及び、ワンタイム認証鍵毎の変動コードを含む。ゲスト用情報は、ゲスト鍵用の付加的な情報である。例えばゲスト用情報は、発行元情報、オーナ鍵ＩＤ、対象車両情報、有効期限情報、権限設定情報を含む。発行元情報は、基本的にはオーナを示す。ただし、新規発行されたゲスト鍵が、発行権付きゲスト端末からの要求に基づいて生成されたものである場合、発行元情報のデータフィールド（欄）には、発行元としてのゲストを示す情報が格納されてもよい。端末登録用パッケージは、発行元情報とオーナ鍵ＩＤの何れか一方だけを備えるように構成されていても良い。ゲスト端末に向けて発せられる端末登録用パッケージもまた、端末チェックコードなどを含む。

ステップＳ３５では、ゲスト端末としての携帯端末１が、ＤＫＳ３から配信された端末登録用パッケージを受信し、その中身を鍵情報記憶部Ｍ１に保存する。ステップＳ３６では、ＤＫＳ３が、車両Ｈｖにゲスト鍵情報を登録するためのデータセットである車両登録用パッケージをゲスト端末に向けて送信する。ゲスト鍵にかかる車両登録用パッケージに含まれる情報種別は、ステップＳ３６で送信される車両登録用パッケージと同様とすることができる。ステップＳ３７では、ゲスト端末としての携帯端末１が、ＤＫＳ３から配信された車両登録用パッケージを受信し、その中身を車両用データ一時記憶部Ｍ２に保存するステップである。

次の図２０を用いて、ゲスト端末がＤＫＳ３から受領したゲスト鍵を車両Ｈｖに登録するシーケンスについて説明する。ゲスト鍵の車両Ｈｖへの登録シーケンスは、ステップＳ４０～Ｓ４７を含む。前提としてゲスト端末は車両Ｈｖの周辺、より具体的にはＢＬＥ通信可能な位置に存在するものとする。ゲスト端末が実行するステップの、実質的な実行主体は端末プロセッサ１０１である。また、認証ＥＣＵ４が実行するステップの、実質的な実行主体は認証プロセッサ４１である。

まず本シーケンス開始時の初期状態（ステップＳ４０）として、認証ＥＣＵ４は通常モードで動作している。認証ＥＣＵ４はゲスト鍵に関しては通常モードでも登録可能である。そのため、オーナ鍵の登録シーケンスと違い、オーナ及びゲストは、セキュリティ解除ツール等を用いて認証ＥＣＵ４の動作モードを変更する必要ない。認証ＥＣＵ４は、通常モード時においても、所定のスキャン間隔でスキャニングを実施する（ステップＳ４２ａ）。

一方、ゲスト端末は、タッチパネル１２を介してゲスト鍵の登録開始操作を受け付けると（ステップＳ４１）、ゲスト鍵の登録に向けたアドバタイズの発信を所定の間隔で発信する（ステップＳ４２ｂ）。当該アドバタイズがＢＬＥ通信部５７を介して認証ＥＣＵ４で受信されることにより、認証ＥＣＵ４と携帯端末１は通信接続のための通信を開始する（ステップＳ４３）。なお、ゲスト鍵の登録開始操作とは、例えば図２１に示すように、ディスプレイ１１に表示されるゲスト鍵登録開始ボタンＢ３の押下である。ゲスト鍵の登録開始操作は、所定の音声フレーズの入力であってもよい。

ゲスト端末は、認証ＥＣＵ４とＢＬＥ通信の接続が確立すると、例えば図１６に示すペアリング確認画面を表示する。ゲスト端末は、タッチパネル１２からの信号に基づき肯定ボタンＢ２ａが押下されたことを検知すると（ステップＳ４４）、認証ＥＣＵ４とのペアリング処理を実行する（ステップＳ４５）。これにより、認証ＥＣＵ４とゲスト端末との間で暗号化されたデータ通信が可能となる。

ペアリング処理が完了し、認証ＥＣＵ４－ゲスト端末間の暗号通信リンクが確立すると、ゲスト端末は、車両用データ一時記憶部Ｍ２に保管されていた車両登録用パッケージをＢＬＥ通信で認証ＥＣＵ４に送信する（ステップＳ４６）。

認証ＥＣＵ４は、ゲスト端末からＢＬＥ通信で車両登録用パッケージを受信すると、当該パッケージに含まれる鍵関連データを車両側記憶部４５に保存する。より具体的には、受信したサービス鍵や、サービス鍵ＩＤ、権限設定、有効期限などをゲスト鍵記憶部４５２に保存する。これにより、ゲスト鍵の車両Ｈｖへの登録が完了し、ゲスト鍵が有効化される。

上記構成によれば、ゲスト鍵を有効化するためにオーナ端末と認証ＥＣＵ４とがＢＬＥ通信で接続する必要がない。つまり、ゲスト鍵を発行するたびに、オーナが車両Ｈｖの近くまでオーナ端末を持っていく必要がない。よって、上記の構成によれば、ゲスト鍵の有効化にかかるオーナの負担を低減することができる。また、本実施形態では認証ＥＣＵ４は、オーナ鍵、ゲスト鍵といったサービス鍵のタイプによらずに、携帯端末１とのＢＬＥ通信によって車両登録用パッケージを取得し、保存する。当該構成によれば、車両Ｈｖにおけるデータ通信量を抑制可能となる。さらに、車両Ｈｖが地下駐車場など、通信圏外にある場合においても、ユーザの接近に伴ってサービス鍵を車両Ｈｖに登録可能となる。もちろん、他の態様として、認証ＥＣＵ４は、セルラー通信又はＷｉ－Ｆｉ通信によってＤＫＳ３から、車両登録用パッケージを取得しても良い。なお、携帯端末１を経由してサービス鍵を車両Ｈｖに送信する構成は、サービス鍵を間接的に認証ＥＣＵ４に配布する構成に相当する。

＜ユーザが車両を使用する場合のシステム作動例＞
ここでは図２２、図２３を用いて、ユーザが車両Ｈｖを利用する際の認証ＥＣＵの作動について説明する。前提として、ここで述べるユーザとは、車両Ｈｖのサービス鍵が保存されている携帯端末１を携帯している人物である。つまり、ここでのユーザとはオーナ又はゲストに相当し、携帯端末１とはオーナ端末又はゲスト端末に相当する。

まず、車両Ｈｖが駐車されている間、認証ＥＣＵ４は定期的にＢＬＥ通信部５７にスキャニングを実施させ、携帯端末１が車両周辺に存在するか否かを判定する（ステップＳ５１）。携帯端末１が車両周辺に存在するか否かの判定は、アドバタイズ等、携帯端末１から発せられるＢＬＥ信号を受信しているか否かに基づいて実施される。仮に携帯端末１からのＢＬＥ信号を受信している場合には（ステップＳ５１ ＹＥＳ）、当該携帯端末１と通信接続する（ステップＳ５２）。一方、スキャニングの結果、携帯端末１を発見できなかった場合には本フローを終了する。なお、フローを終了した場合には、所定のスキャン間隔が経過したタイミングでステップＳ５１を再実行する。図２２に示すフローチャートは、車両Ｈｖが駐車されている状態において所定のスキャン間隔で繰り返し実施されうる。

認証ＥＣＵ４は、携帯端末１と通信接続できた場合、ステップＳ５３として認証処理を実行する。認証処理については別途後述する。認証処理の結果として携帯端末１（ひいてはユーザ）の認証が成功した場合には（ステップＳ５４ ＹＥＳ）、スタンバイモードに移行する（ステップＳ５５）。

スタンバイモードは、ドアボタン等に対するユーザ操作に基づいて、開錠／施錠、走行用電源のオン／オフ切り替えなどを実施可能な状態に相当する。スタンバイモードは、１つの側面においてサービス鍵を有する携帯端末１／ユーザが車両周辺に存在すると認証プロセッサ４１が認識している状態に対応する。車両周辺には、車外だけでなく車室内も含まれる。本実施形態では一例として、認証成功との判定結果には有効期限が設定される。有効期限は例えば３秒や５秒、１０秒などに設定される。

一方、認証処理の結果として携帯端末１の認証に失敗した場合には（ステップＳ５４ ＮＯ）、本フローを終了する。なお、認証処理が失敗した場合には、認証が成功していないことをユーザが認識可能なように車載設備を動作させてもよい。例えば、認証処理が成功していない場合には、ディスプレイ５１に所定の認証失敗画像を表示しても良いし、サイドミラー等に設けられた灯火装置を所定パターンで点灯させても良い。認証ＥＣＵ４は、認証処理が失敗した場合、携帯端末１に向けてＢＬＥ通信で所定の制御信号を送信する事により、ディスプレイ１１に認証失敗画面を表示させてもよい。認証ＥＣＵ４は、ドア周りの路面に向けて光を発するウェルカムライトを所定パターンで点灯されることで、認証失敗したことを表現してもよい。

ステップＳ５６では、認証プロセッサ４１がドアボタンやタッチセンサ、スタートボタンなどからの信号に基づき、車両Ｈｖを使用するためのユーザ操作が行われたか否かを判定する。車両Ｈｖを使用するためのユーザ操作とは、例えばドアハンドルに触れる／握るなどといった、ドアを開けようとする行為を指す。スタートボタンの押下も車両Ｈｖを使用するためのユーザ操作に該当する。

認証プロセッサ４１は、上記ユーザ操作に対応する信号が車載センサより入力された場合（ステップＳ５６ ＹＥＳ）、ユーザが操作した部材及び車両Ｈｖの状態に応じた車両制御を実行する（ステップＳ５７）。例えば認証プロセッサ４１は、車両Ｈｖが施錠された状態において、ドアボタンが押下／ドアハンドルが把持されたことを検知した場合には、ドアを開錠する。また、認証プロセッサ４１は、スタートボタンが押下されたことを検知した場合には、走行用電源をオフからオンに、又はオンからオフに切り替える。

なお、実際に上記ドアの開錠／施錠、走行用電源のオン／オフといった車両制御を行う際には、認証結果だけなく、携帯端末１の推定位置やサービス鍵の権限、車両Ｈｖの状態が参照される。そして、所定の制御実行条件が充足されていない場合には、ユーザ操作に応じた車両制御の実行はキャンセルされうる。制御実行条件が充足されていない場合とは、例えばサービス鍵に設定されている権限が不足している場合や、検出されている携帯端末１の位置が車両から２ｍ以上離れている場合などである。携帯端末１の位置は、携帯端末１からの信号の受信状況に基づき特定されうる。携帯端末１の位置推定材料としては受信強度や、信号の到来方向、ＴｏＦ（Time of Flight）、ＲＴＴ（Round-Trip Time）など、多様な指標を採用可能である。

一方、車両Ｈｖを使用するためのユーザ操作が行われていない場合には（ステップＳ５６ ＮＯ）、認証結果の有効期限が切れたか否か、すなわち、認証成功と判定してから所定時間経過したか否かを判定する。有効期限内である間は（ステップＳ５８ ＮＯ）、スタンバイモードを維持する。一方、有効期限が切れた場合に、認証プロセッサ４１は認証処理のための通信を再度実行する。

上記の構成によれば、ユーザは専用キー２や携帯端末１を操作することなく、車両Ｈｖにアクセス可能となる。つまり、パッシブエントリパッシブスタート機能が実現され、ユーザの利便性を高めることができる。

＜認証処理について＞
ここでは認証ＥＣＵ４が携帯端末１を認証する処理のシーケンスについて説明する。認証ＥＣＵ４による携帯端末１の認証処理は、例えば図２３に示すようにステップＳ６１～Ｓ６８を備える。なお、認証処理は、携帯端末１と認証ＥＣＵ４との暗号化された通信リンクが確立していることを前提として実行される。

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

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

ステップＳ６４は、認証ＥＣＵ４が携帯端末１から受信した変動コードと、車両側記憶部４５に保存されている、通信相手に対応するサービス鍵とを用いて、ＤＫＳ３のワンタイム認証鍵発行部Ｇ４と同様の手法により、ワンタイム認証鍵を生成する。ここで認証ＥＣＵ４がワンタイム認証鍵の生成に使用するサービス鍵と変動コードの組み合わせは、携帯端末１がレスポンスコードの生成に使用したワンタイム認証鍵の生成材料と同じである。故にステップＳ６４で認証ＥＣＵ４が生成するワンタイム認証鍵は、携帯端末１がレスポンスコードの生成に使用したワンタイム認証鍵と同じとなる。このようなステップＳ６４は、携帯端末１から受信した変動コードと自信が保持する携帯端末１のサービス鍵をもとに、携帯端末１がレスポンスコードの生成に使用したワンタイム認証鍵を復元する処理に相当する。

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

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

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

なお、上述した認証シーケンスは一例であって、これに限らない。携帯端末１と認証ＥＣＵ４とで、レスポンスコード／検証用コードの生成に使用するワンタイム認証鍵が同一のものとなるように、各デバイスの動作は設計されていれば良い。例えば認証処理は図２４に示す手順で実施されても良い。つまり、認証処理は他の一例として、ステップＳ６１ａ～Ｓ６９ａを備えうる。

なお、図２４に示す認証処理パターンを採用する場合、前提構成として、認証ＥＣＵ４と携帯端末１は共通の複数のワンタイム認証鍵を保持しているものとする。例えば認証ＥＣＵ４は、車両登録用パッケージとして、複数のワンタイム認証鍵を含むデータセットを受信することにより、携帯端末１が保持するものと同じワンタイム認証鍵を取得する。また、車両側記憶部４５に保存されているワンタイム認証鍵が所定の補充閾値未満となった場合には、携帯端末１の認証が成功していることを条件として、携帯端末１から認証ＥＣＵ４が未取得のワンタイム認証鍵を受信する。これにより、認証ＥＣＵ４は、車両側記憶部４５に保存されているワンタイム認証鍵を補充しうる。なお、携帯端末１は別途後述するように随時ＤＫＳ３との通信によりワンタイム認証鍵を補充する。認証ＥＣＵ４はＤＫＳ３から直接ワンタイム認証鍵を取得するように構成されていても良い。その他、各ワンタイム認証鍵には、それらを識別するための番号が付与されているものとする。

ステップＳ６１ａは、認証ＥＣＵ４が、携帯端末１に向けて使用鍵確認信号を送信するステップである。使用鍵確認信号は、使用予定鍵の番号を問い合わせる信号である。使用予定鍵は、以降のレスポンスコードの生成に使用するワンタイム認証鍵を指す。使用鍵確認信号が調整メッセージに相当する。

携帯端末１は、使用鍵確認信号を受信すると、ステップＳ６２ａとして、使用予定鍵の番号を認証ＥＣＵ４に通知する。使用予定鍵の決定方法としては任意の方法を採用可能である。例えば携帯端末１が保持するワンタイム認証鍵の中で最も番号が小さいものを使用予定鍵に選定する。

なお、携帯端末１は後述するワンタイム認証鍵の有効期限管理によって有効期限が切れたものを順次削除する。認証ＥＣＵ４も同様の有効期限管理を行うが、認証ＥＣＵ４とい携帯端末１の時刻情報は完全に一致しているとは限らない。また、有効期限に基づくワンタイム認証鍵の廃棄処理を行うタイミングも相違しうる。それらの事情から、携帯端末１が保持する使用予定鍵を認証ＥＣＵ４が保持しているとは限らない。

認証ＥＣＵ４は、携帯端末１から通知された使用予定鍵を自身が保持していない場合には、別の鍵を使用するように携帯端末１に要求しても良い。ステップＳ６１ａ～Ｓ６２ａは認証ＥＣＵ４と携帯端末１の両方が保持するワンタイム認証鍵が選択されるまで繰り返し実施されてもよい。なお、使用予定鍵のすり合わせをより効率的に行うため、使用鍵確認信号は、認証ＥＣＵ４が保持するワンタイム認証鍵の中からランダムに／所定規則で選択された複数の候補の番号を含んでいても良い。携帯端末１はそれら複数の候補の中からランダムに／所定の規則に則って使用予定鍵を選択して回答するように構成されていても良い。

ステップＳ６３ａは、認証ＥＣＵ４がステップＳ６１と同様に、認証ＥＣＵ４がチャレンジコードを送信するステップである。ステップＳ６４ａは認証ＥＣＵ４が、携帯端末１から使用予定鍵として通知された番号に対応するワンタイム認証鍵と、ステップＳ６３ａで送信したチャレンジコードをもとに検証用コードを生成するステップである。ワンタイム認証鍵自体は、車両側記憶部４５に保存されているワンタイム認証鍵が使用される。

ステップＳ６５ａは、携帯端末１が、使用予定鍵として選定した番号に対応するワンタイム認証鍵と、認証ＥＣＵ４から受信したチャレンジコードと、を用いてレスポンスコードを生成するステップである。レスポンスコードの生成に使用されるワンタイム認証鍵自体は、事前にＤＫＳ３から取得して端末側記憶部１０５に保存済みのものである。携帯端末１は、レスポンスコードの生成が完了するとステップＳ６６ａとして当該レスポンスコードを認証ＥＣＵ４に向けて送信する。

認証ＥＣＵ４は、携帯端末１からレスポンスコードを受信すると、ステップＳ６７ａとして、当該レスポンスコードとステップＳ６５ａで生成した検証用コードとを比較することで、通信相手の正当性を判断する。つまり、２つのコードが一致している場合には認証成功と判定する（ステップＳ６８ａ）。一方、２つのコードが相違する場合には認証失敗と判定する（ステップＳ６９ａ）。

上記の方法によれば、レスポンスコードの生成に際して認証ＥＣＵ４と携帯端末１の間でやり取りされる情報は、使用予定鍵の番号とチャレンジコードであり、ワンタイム認証鍵自体は通信で送受信されない。鍵番号だけではワンタイム認証鍵を復元することはできない。よって、上記の方法によっても、前述の認証方法と同様に、無関係な人物が不正に認証処理を成功させる恐れを低減可能となる。なお、上記の例では、レスポンスコードの生成前に、携帯端末１が使用予定鍵の番号を認証ＥＣＵ４に通知する態様を述べたが、処理順序はこれに限らない。携帯端末１はレスポンスコードを生成した後に、認証ＥＣＵ４に対して、レスポンスコードの生成に使用したワンタイム認証鍵の番号を通知しても良い。

＜ワンタイム認証鍵の補充シーケンス＞
ここでは図２５を用いて、携帯端末１が実行するワンタイム認証鍵補充処理について説明する。ワンタイム認証鍵補充処理は、ワンタイム認証鍵が所定の補充閾値ＴｈＲｐ未満となったら補充する処理である。ワンタイム認証鍵補充処理は、図２５に示すようにステップＳ７１～Ｓ７７を備える。ワンタイム認証鍵補充処理は、例えば所定の残数確認周期で定期的に実行される。ワンタイム認証鍵補充処理は、携帯端末１がオンライン状態であることを条件として実行されても良い。ワンタイム認証鍵補充処理は、その他、ＤＫＳ３から送信された残数確認指示信号を受信したことや、ユーザが所定の残数確認操作を実施したことに基づいて開始されてもよい。ワンタイム認証鍵補充処理は、後述する保存認証鍵更新処理の一部として実行されても良い。残数確認指示信号の受信や、残数確認操作の受け付けなどが、確認イベントに相当する。

ワンタイム認証鍵補充処理の実行主体としての携帯端末１との表現は、端末プロセッサ１０１／ワンタイム認証鍵管理部Ｆ２と解することができる。

ステップＳ７１は、携帯端末１が、端末側記憶部１０５に保存されているワンタイム認証鍵の残数（Ｎｏｔｋ）を確認するステップである。ステップＳ７２は携帯端末１が、ステップＳ７１で取得したワンタイム認証鍵の残数（Ｎｏｔｋ）が所定の補充閾値（ＴｈＲｐ）未満であるか否かを判定するステップである。Ｎｏｔｋ＜ＴｈＲｐを充足する場合、携帯端末１はステップＳ７３として認証鍵要求信号をＤＫＳ３に向けて送信する。認証鍵要求信号が、ワンタイム認証鍵の配布を要求する信号である。認証鍵要求信号が補充要求信号に相当する。一方、Ｎｏｔｋ≧ＴｈＲｐを充足する場合、携帯端末１はワンタイム認証鍵の補充にかかるシーケンスを終了する。

なお、ワンタイム認証鍵の補充の要否は、前述の通り、補充要否フラグで管理されうる。Ｎｏｔｋ＜ＴｈＲｐを充足する場合、携帯端末１は補充要否フラグをオンに設定する。また、Ｎｏｔｋ≧ＴｈＲｐを充足する場合、携帯端末１は補充要否フラグをオフに設定する。仮に携帯端末１がオフライン状態である場合には補充要否フラグをオンに設定した状態を維持し、その後、オンラインとなったことに基づいて認証鍵要求信号を送信しうる。

ＤＫＳ３が、携帯端末１からの認証鍵要求信号を受信すると、ステップＳ７４として、ユーザＤＢ３３から要求元のサービス鍵を読み出す。そして、ＤＫＳ３は、当該サービス鍵とランダムに／所定の規則で生成される変動コードを用いて、複数のワンタイム認証鍵を生成する（ステップＳ７５）。ステップＳ７５で生成するワンタイム認証鍵の個数は、一定数であってもよいし、補充閾値と残数の差に所定値（例えば１００）を加えた値であっても良い。認証鍵要求信号は、ＤＫＳ３が必要な発行数を特定可能なように、携帯端末１におけるワンタイム認証鍵の残数を示す情報を含んでいても良い。

ＤＫＳ３は、ワンタイム認証鍵の生成が完了すると、ステップＳ７６として、認証鍵パッケージを携帯端末１に向けて送信する。認証鍵パッケージは、個々のワンタイム認証鍵に変動コードを紐付けたデータセットである。携帯端末１はＤＫＳ３から認証鍵パッケージを受信すると、それに含まれるデータを端末側記憶部１０５に保存する（ステップＳ７７）。

以上の構成によれば、携帯端末１が保持するワンタイム認証鍵が所定値未満となったことに基づいて随時補充される。よって、ワンタイム認証鍵が枯渇することによってユーザが車両Ｈｖを使用不能となる恐れを低減できる。また、補充閾値は例えば１００以上の十分に大きい値に設定される。当該設定によれば、ユーザが山間部などの通信圏外に一時的に滞在した場合であっても、通信圏外滞在中にワンタイム認証鍵が不足する恐れを低減できる。なお、デジタルキーアプリ１０４は、所定の最小値よりも大きい範囲において、ユーザが任意の値を補充閾値として登録可能に構成されていても良い。

＜ワンタイム認証鍵の定期更新シーケンス＞
ここでは図２６を用いて、携帯端末１が実行する保存認証鍵更新処理について説明する。保存認証鍵更新処理は、端末側記憶部１０５に保存されているワンタイム認証鍵の一部又は全部を定期的に入れ替える処理である。保存認証鍵更新処理は、図２６に示すようにステップＳ８１～Ｓ８３を備える。保存認証鍵更新処理は例えば所定の入れ替え周期で定期的に実行される。保存認証鍵更新処理は、携帯端末１がオンライン状態であることを条件として実行されても良い。保存認証鍵更新処理を構成する処理ステップの実行主体としての携帯端末１との表現は、端末プロセッサ１０１／ワンタイム認証鍵管理部Ｆ２と解することができる。

ステップＳ８１は、携帯端末１が、自身が保持する時刻情報である端末時刻に基づいて、端末側記憶部１０５に保存されているワンタイム認証鍵毎の有効期限を確認するステップである。携帯端末１は、有効期限が切れているワンタイム認証鍵に関しては削除する（ステップＳ８２）。なお、有効期限の確認は、有効期限として示されている日時と現在の日時とを比較することに相当する。端末時刻は、ＤＫＳ３などの所定サーバとの通信により随時修正される。

ステップＳ８３は携帯端末１が、ＤＫＳ３と連携して、ワンタイム認証鍵補充処理を実行するステップである。ワンタイム認証鍵補充処理については前述のとおりである。なお、有効期限に基づく補充処理においては、残数（Ｎｏｔｋ）が補充閾値（ＴｈＲｐ）未満であるか否かによらず、ステップＳ８２で削除した数だけ補充するように構成されていても良い。例えば携帯端末１は、ステップＳ８２で２０個のワンタイム認証鍵を削除した場合には、認証鍵要求信号として、２０個のワンタイム認証鍵の発行を要求する信号を送信しても良い。認証鍵要求信号は、発行希望数を示す情報を含んでいても良い。

上記の構成によれば、定期的に携帯端末１に保存されているワンタイム認証鍵の一部又は全部が、有効期限に基づいて入れ替えられる。当該構成によれば、使用可能なワンタイム認証鍵は経時的に変更される。そのため、セキュリティをより一層強固にすることができる。

＜認証ＥＣＵにおける時刻情報の更新について＞
認証ＥＣＵ４は、自身が保持する時刻情報であるＥＣＵ内部時刻に基づいてゲスト鍵の有効期限をチェックする。そのため、ＥＣＵ内部時刻は、ＤＫＳ３の時刻情報と同期していることが好ましい。ここでは、図２７を用いてＥＣＵ内部時刻をＤＫＳ３の時刻情報と同期するように補正した上で、ゲスト鍵の有効期限する処理について説明する。ＥＣＵ時刻情報の更新及びゲスト鍵の有効期限チェックにかかる一連のシーケンスは、図２７に示すように、ステップＳ９１～Ｓ９７を含む。なお、少なくともＥＣＵ内部時刻の更新にかかるシーケンスは、認証ＥＣＵ４と携帯端末１との間でＢＬＥの通信リンクが確立していることを条件として実行される。ここでの携帯端末１は、オーナ端末又はゲスト端末のどちらであってもよい。

ステップＳ９１は、認証ＥＣＵ４が携帯端末１に向けて時刻要求信号を送信する。時刻要求信号は、ＤＫＳ３が保持している時刻情報であるサーバ時刻情報を要求する信号である。時刻要求信号は、例えばＥＣＵ番号あるいは車両ＩＤなどの、要求元を示す情報を含んでいても良い。

携帯端末１は、認証ＥＣＵ４からの時刻要求信号をＢＬＥ通信で受信すると、ステップＳ９２として、セルラー通信又はＷｉ－Ｆｉ通信のフォーマットに準拠した時刻要求信号を生成し、ＤＫＳ３に送信する。ステップＳ９２は認証ＥＣＵ４からのデータをＤＫＳ３に転送するステップに相当する。なお、携帯端末１からＤＫＳ３に送信する時刻要求信号には、ＤＫＳ３がサーバ時刻情報の返送先を特定可能なように、携帯端末１の情報を含んでいることが好ましい。

ＤＫＳ３は、携帯端末１からの時刻要求信号を受信すると、サーバ時刻情報を要求元の携帯端末１に返送する（ステップＳ９３）。また、携帯端末１は、ＤＫＳ３から受信したサーバ時刻情報をＢＬＥ通信で認証ＥＣＵ４に転送する（ステップＳ９４）。

認証ＥＣＵ４は、携帯端末１からサーバ時刻情報を受信すると、当該サーバ時刻情報を用いてＥＣＵ内部時刻を修正する（ステップＳ９５）。ＥＣＵ内部時刻は、認証ＥＣＵ４が保持する時刻情報を指す。なお、各デバイスにおけるデータの受信処理には、チェックコードを用いた正当性の検証処理が含まれていてもよい。チェックコードを用いた検証処理の結果、正当性が認められなかった場合には、要求は棄却されうる。以上で述べたステップＳ９１～Ｓ９５がＥＣＵ時刻情報の更新にかかるシーケンスＳｑ１に相当する。

認証ＥＣＵ４は、例えばＥＣＵ内部時刻の修正が行われたことに基づいて、修正された時刻情報を用いて車両側記憶部４５に登録されているゲスト鍵毎の有効期限を確認する（ステップＳ９６）。そして、認証ＥＣＵ４は、有効期限が切れているゲスト鍵のデータを削除する（ステップＳ９７）。なお、ステップＳ９７は、鍵データは残したまま、フラグなどを用いて有効期限切れのゲスト鍵を無効化する処理であっても良い。

ステップＳ９６～Ｓ９７が、ゲスト鍵の有効期限チェックにかかるシーケンスＳｑ２に相当する。なお、ＥＣＵ時刻情報の更新にかかるシーケンスＳｑ１と、ゲスト鍵の有効期限チェックにかかるシーケンスＳｑ２は、別々に実施されても良い。ゲスト鍵の有効期限のチェックにかかるシーケンスＳｑ２は、ＥＣＵ時刻情報が更新された場合に限らず、所定の周期で実行されても良い。また、ゲスト鍵の有効期限のチェックは、走行用電源がオンからオフに切り替わったタイミングや、オフからオンに切り替わったことに基づいて実行されても良い。

認証ＥＣＵ４が備える時刻情報は、認証ＥＣＵ４が備えるクロック発振器の精度等により、実際の時刻あるいはサーバ時刻とずれうる。以上の構成によれば、携帯端末１と接続するたびに、ＥＣＵ内部時刻が修正される。そのため、認証ＥＣＵ４が誤った時刻情報に基づいてゲスト鍵を削除／無効化してしまう恐れを低減できる。

＜オーナ鍵の削除処理について＞
車両Ｈｖの売買／譲渡におって車両Ｈｖのオーナは変わりうる。オーナが変わった場合には、古いオーナのサービス鍵などは削除されることが好ましい。そのような事情から車両用デジタルキーシステムＳｙｓは、ゲスト鍵だけでなく、オーナ鍵の情報を削除可能に構成されている必要がある。

本実施形態のＤＫＳ３は、オーナ端末及び車載ＨＭＩのどちらのデバイスからもオーナ鍵の削除要求を受付可能に構成されている。ＤＫＳ３は、オーナ端末に対する操作に基づいてオーナ鍵を削除する場合、処理全体としては図２８に示すように端末内データ削除フェーズＰｈ３と、車両内データ削除フェーズＰｈ４とを含みうる。端末内データ削除フェーズＰｈ３は、携帯端末１から指定されたサービス鍵（ここではオーナ鍵）のデータを削除するフェーズである。車両内データ削除フェーズＰｈ４は、認証ＥＣＵ４から指定されたサービス鍵を削除するフェーズである。ここではオーナ端末に対する操作に基づいてオーナ鍵を削除する場合のシーケンスについて図２９、図３０を用いて説明する。

図２９は、端末内データ削除フェーズＰｈ３に対応する各デバイスのインタラクションを示すシーケンス図である。オーナ鍵データを携帯端末１から削除するシーケンスは、図２９に示すように、ステップＴ１０～Ｔ１８を含む。

ステップＴ１０は、ステップＳ１０と同様に、ＤＫＳ３が、ユーザ／携帯端末１を認証するステップである。ステップＴ１１は、オーナ端末としての携帯端末１が、ユーザの操作に基づいてオーナ鍵削除要求信号を送信するステップである。オーナ鍵削除要求信号は、例えばデバイスＩＤ、ユーザＩＤ、又はサービス鍵ＩＤなど、ＤＫＳ３が要求元を特定するための情報を含む。また、オーナ鍵削除要求信号は、削除対象とするサービス鍵を特定するための情報としてサービス鍵ＩＤ、ＥＣＵ番号、又は車両ＩＤの情報などを含んでいても良い。１人のユーザが複数の車両のオーナである場合を想定すると、オーナ鍵削除要求信号は削除対象とするサービス鍵を特定するための情報を含んでいることが好ましい。

ＤＫＳ３（サービス鍵削除部Ｇ５）は、オーナ端末からオーナ鍵削除要求信号を受信すると、ステップＴ１２として、車両用オーナ削除パッケージをオーナ端末に向けて送信する。車両用オーナ削除パッケージは、車両Ｈｖから全てのサービス鍵に関連するデータを削除するためのデータセットである。車両用オーナ削除パッケージは、端末チェックコードや車両チェックコードを含みうる。オーナ端末は、ＤＫＳ３から配信された車両用オーナ削除パッケージを受信すると、端末チェックコードを用いてその正当性を検証した上で、車両用データ一時記憶部Ｍ２に保存する（ステップＴ１３）。

また、ＤＫＳ３は、車両Ｈｖに対してゲスト鍵が発行されている場合、オーナ端末からのオーナ鍵削除要求信号に基づいて、ゲスト端末に向けてゲスト鍵削除コマンドを送信する（ステップＴ１４）。車両Ｈｖに対してゲスト鍵が発行されている場合とは、換言すれば削除対象とするオーナ鍵に紐づくゲスト鍵が存在する場合に相当する。ゲスト鍵削除コマンドは、ゲスト端末から車両Ｈｖ用のサービス鍵にかかるデータを削除するように指示する信号である。ゲスト鍵削除コマンドは、削除対象とするサービス鍵ＩＤや、端末チェックコードなどの情報を含む。ゲスト端末は、ゲスト鍵削除コマンドを受信すると、端末チェックコードを用いてその正当性を検証した上で、鍵情報記憶部Ｍ１から指定されたサービス鍵に関連するデータを全て削除する（ステップＴ１５）。より好ましい態様として、ゲスト端末は、ゲスト鍵の削除処理が完了するとその旨をＤＫＳ３に報告する。

ＤＫＳ３は、オーナ端末からのオーナ鍵削除要求信号に基づいて、オーナ端末に向けてオーナ鍵削除コマンドを送信する（ステップＴ１６）。オーナ鍵削除コマンドは、オーナ端末から車両Ｈｖ用のサービス鍵にかかるデータを削除するように指示する信号である。オーナ鍵削除コマンドは、削除対象とするサービス鍵ＩＤや、端末チェックコードなどの情報を含む。オーナ鍵削除コマンド及びゲスト鍵削除コマンドは、サービス鍵を削除するための指示コマンド、すなわちサービス鍵削除コマンドの一種に相当する。

オーナ端末は、オーナ鍵削除コマンドを受信すると、端末チェックコードを用いてその正当性を検証した上で、鍵情報記憶部Ｍ１から指定されたサービス鍵に関連するデータを全て削除する（ステップＴ１７）。なお、オーナ鍵削除コマンドは、車両用データ一時記憶部Ｍ２に保存されているデータにまでは作用しない。つまり、オーナ端末は、オーナ鍵削除コマンドを受信しても、車両用データ一時記憶部Ｍ２に保存されている車両用オーナ削除パッケージは削除せずに所定期間残す。より好ましい態様として、オーナ端末は、オーナ鍵の削除処理が完了するとその旨をＤＫＳ３に報告する。

ＤＫＳ３は、例えばオーナ端末及びゲスト端末からサービス鍵の削除が完了したことを受信したことに基づいて、削除要求されたオーナ鍵に関するデータをユーザＤＢ３３及び車両ＤＢ３２から削除する（ステップＴ１８）。なお、サーバ内データの削除は、車両Ｈｖから、車両内のデータ削除も完了したことの報告を受信してから実行されてもよい。本実施形態では車両用オーナ削除パッケージとオーナ鍵削除コマンドを別々に送信するが、各種データの送信態様はこれに限らない。車両用オーナ削除パッケージとオーナ鍵削除コマンドは一連のデータとしてまとめて送信されても良い。

次の図３０を用いて車両Ｈｖからオーナ鍵に関連するデータを削除するシーケンスについて説明する。オーナ鍵に関連する情報には、ゲスト鍵のデータも含まれる。車両Ｈｖからオーナ鍵に関連するデータを削除するシーケンスは、ステップＴ２１～Ｔ２４を含む。なお、オーナ鍵の登録シーケンスと違って、認証ＥＣＵ４は通常モードでもオーナ鍵の削除指示は受け付ける。図３０の説明における携帯端末１とは、車両用オーナ削除パッケージを保持している携帯端末１であり、旧オーナ端末と呼ぶことができる。

車両用オーナ削除パッケージを保持している携帯端末１が車両ＨｖのＢＬＥ通信圏内に入ると、サービス鍵を保持している状態と同様に、認証ＥＣＵ４は当該携帯端末１とＢＬＥによる通信接続を行う（ステップＴ２１）。そして、暗号通信が開始される（ステップＴ２２）。携帯端末１は、認証ＥＣＵ４との暗号通信リンクが確立したことに基づき、車両用データ一時記憶部Ｍ２に保存されている、車両Ｈｖ向けの車両用オーナ削除パッケージを送信する（ステップＴ２３）。

認証ＥＣＵ４は、携帯端末１から車両用オーナ削除パッケージを受信すると、当該パッケージに含まれる命令／プログラムに基づいて、車両側記憶部４５に保存されている全てのサービス鍵に関連するデータを削除する。このようにオーナ端末は、認証ＥＣＵ４との間にＢＬＥ通信のリンクが確立している場合に認証ＥＣＵ４からオーナ鍵を削除可能に構成されている。

なお、ステップＴ１１～Ｔ１３を含むシーケンスは、オーナ端末がＤＫＳ３と通信接続している状態において実行されても良い。その場合、オーナ端末がＤＫＳ３から取得した車両用オーナ削除パッケージは、ステップＴ２３により速やかに認証ＥＣＵ４へと転送され、車両側記憶部４５からもオーナ鍵が削除されうる。なお、認証ＥＣＵ４は、車両用オーナ削除パッケージを受信した場合、受信データに含まれる車両チェックコードに基づいて受信データの正当性を検証した上で、全てのサービス鍵データの削除を実行してもよい。

＜オーナ権限によるゲスト鍵の削除処理について＞
ゲストからの申し出や利用規約違反等に基づき、オーナは、有効期限内であってもゲスト鍵を削除可能に構成されていることが好ましい。ここではＤＫＳ３は、オーナ端末からの要求に基づき、指定されたゲスト鍵を削除する処理の流れについて図３１、図３２を用いて説明する。

オーナ鍵の削除と同様に、ゲスト鍵の削除処理も、携帯端末１からゲスト鍵に関連するデータを削除するフェーズＰｈ３と、車両Ｈｖからゲスト鍵のデータを削除するフェーズＰｈ４に分けることができる。図３１は、携帯端末１からゲスト鍵データを削除するフェーズＰｈ３に対応する各デバイスのインタラクションを示すシーケンス図である。ゲスト鍵データを携帯端末１から削除するシーケンスは、図３１に示すように、ステップＴ３０～Ｔ３９ｂを含む。

なお、オーナの操作を受け付けるデバイスは携帯端末１に限らず、デスクトップ／ノートＰＣ（ラップトップ）であってもよい。以降におけるオーナ端末は、オーナが操作するデスクトップ／ノートＰＣであってもよい。

ステップＴ３０は、オーナ端末におけるデジタルキーアプリ１０４が、操作者がオーナであることを認証するステップである。デジタルキーアプリ１０４における認証方法は、パスワードを用いる方法であっても良いし、生体情報を用いる方法であっても良い。オーナであるか否かの検証には、パスワードと生体情報の両方が使用されても良い。ユーザ認証は２段階認証など多用な方法が採用可能である。

ステップＴ３１は、オーナ端末が、タッチパネル１２から入力される操作信号に基づき、ディスプレイ１１に削除対象選択画面を表示するステップである。削除対象選択画面は、削除対象とするゲスト鍵、又は、それに対応するゲストを選択するための画面である。削除対象選択画面は、ゲスト又はゲスト鍵のリストを含む。なお、削除対象選択画面は、ゲストの一覧を示すゲストリスト画面あるいはゲスト削除画面と呼ぶこともできる。

ステップＴ３２では、オーナ端末が、タッチパネル１２の出力信号が示す、削除対象選択画面に対するユーザ操作に基づいて、削除対象とするゲスト鍵を特定する。削除対象とするゲスト鍵を選択するユーザ操作が削除指示操作に相当する。オーナ端末は、削除対象とするゲスト鍵がオーナによって選択されると、当該ゲスト鍵を対象とするゲスト鍵削除要求信号をＤＫＳ３に送信する（ステップＴ３３）。ゲスト鍵削除要求信号は、削除対象とするサービス鍵を特定するための情報として、削除対象のサービス鍵ＩＤ又はユーザＩＤを含む。なお、ゲスト鍵削除要求信号は、複数のゲスト鍵をまとめて削除するように要求する信号であっても良い。例えばゲスト鍵削除要求信号は、オーナ鍵に紐づく全てのゲスト鍵をまとめて削除するように要求する信号であっても良い。

ＤＫＳ３は、ゲスト鍵削除要求信号を受信すると、当該受信信号にて指定されているゲスト鍵に紐づくゲスト端末に向けて、ゲスト鍵削除コマンドを送信する（ステップＴ３４）。ゲスト端末は、ゲスト鍵削除コマンドを受信すると、端末チェックコードを用いてその正当性を検証した上で、指定されたサービス鍵に関連するデータを鍵情報記憶部Ｍ１から全て削除する（ステップＴ３５）。ゲスト鍵削除コマンドが削除指示信号に相当する。ゲスト端末は、より好ましい態様として、ゲスト鍵の削除処理が完了するとその旨をＤＫＳ３に報告する。

ステップＴ３６は、ＤＫＳ３が、オーナ端末に向けてゲスト鍵の削除が完了したことを通知するステップである。ＤＫＳ３は、ゲスト鍵削除コマンドの送信が完了したことに基づいてゲスト鍵削除完了通知を送信してもよいし、ゲスト端末から削除完了の報告を受信してからゲスト鍵削除を送信してもよい。

オーナ端末は、ＤＫＳ３からゲスト鍵削除完了通知を受信すると、削除完了通知画面をディスプレイ１１に表示する（ステップＴ３７）。削除完了通知画面は、削除したゲスト鍵に紐づくユーザ名などを含みうる。

また、ＤＫＳ３は、オーナ端末、及び、削除対象に設定されたゲスト鍵に対応するゲスト端末に向けて、車両用ゲスト削除パッケージを送信する（ステップＴ３８ａ、Ｔ３８ｂ）。各デバイスは、車両用ゲスト削除パッケージを受信すると、それを車両用データ一時記憶部Ｍ２に保存する（ステップＴ３９ａ、Ｔ３９ｂ）。車両用ゲスト削除パッケージが削除用データセットに相当する。

次に、図３２を用いて車両Ｈｖからゲスト鍵に関連するデータを削除するシーケンスについて説明する。車両Ｈｖからゲスト鍵に関連するデータを削除するシーケンスは、ステップＴ４１～Ｔ４４を含む。車両Ｈｖからゲスト鍵に関連するデータを削除するシーケンスに登場するゲスト端末とは、車両用ゲスト削除パッケージを保持しているゲスト端末に相当する。

オーナ端末又はゲスト端末としての携帯端末１が車両ＨｖのＢＬＥ通信圏内に入ると、認証ＥＣＵ４は当該携帯端末１とＢＬＥによる通信接続を行う（ステップＴ４１）。そして、暗号通信が開始される（ステップＴ４２）。携帯端末１は、認証ＥＣＵ４との暗号通信リンクが確立したことに基づき、車両用データ一時記憶部Ｍ２に保存されている、車両Ｈｖ向けの車両用ゲスト削除パッケージを送信する（ステップＴ４３）。

認証ＥＣＵ４は、オーナ端末／ゲスト端末から車両用ゲスト削除パッケージを受信すると、当該パッケージに含まれる命令／プログラムに基づいて、削除対象に指定されているゲスト鍵に関連するデータを、車両側記憶部４５から削除する。

なお、ステップＴ４１～Ｔ４３を含むシーケンスは、オーナ端末／ゲスト端末がＤＫＳ３と通信接続している状態において実行されても良い。また、認証ＥＣＵ４は、車両用ゲスト削除パッケージを受信した場合、受信データに含まれる車両チェックコードに基づいて受信データの正当性を検証した上で、全てのサービス鍵データの削除を実行してもよい。

上記の構成によれば、オーナは任意のタイミングで任意のゲスト鍵を削除可能となる。よって、ゲストによる車両Ｈｖの利用状況や、オーナの都合に応じて、ゲストによる車両Ｈｖの使用を停止させることが可能となる。

なお、ゲストが車両Ｈｖを使用している際に急にゲスト鍵が削除されると、ゲストに不都合が生じうる。特に、ゲストが車両Ｈｖを用いて本来の車両Ｈｖの保管場所から離れた場所に移動している場合に、急に車両Ｈｖが使用不可となると、ゲストもオーナも不都合が生じうる。そのような事情からゲスト鍵の削除の申請から、実際に削除処理が執行されるまでには一定時間の猶予が設けられうる。ゲスト鍵等の削除は、車両Ｈｖが規定された保管場所に駐車されていることを条件として実行されてもよい。ＤＫＳ３は、オーナによるゲスト鍵の削除申請が行われたことを示す画面を該当するゲスト端末に表示させても良い。

なお、上記の通り、オーナ端末は、車両に紐づくゲスト鍵を選択的に削除するための操作は受付可能に構成されている。一方、ゲスト鍵を削除せずに有効期限又は権限にかかる設定だけを変更する操作は受け付け不能に構成されている。ＤＫＳ３もまた、発行済みのサービス鍵に関し、当該サービス鍵を残したまま、権限設定及び有効期限を変更することは不能に構成されている。オーナは、あるゲストに対するサービス鍵の権限設定や有効期限を変更したい場合は、該当するゲスト鍵を一旦削除したのちに、所望の権限設定を行ったゲスト鍵を発行する事となる。

以上では、オーナがオーナ端末等を操作することでゲスト鍵を削除する場合を述べたが、ゲスト鍵はゲスト自身の操作でも削除されうる。ＤＫＳ３は、ゲストの操作に基づき、ゲスト鍵を削除した場合には、当該ゲスト鍵に紐づくオーナ端末に対してゲスト鍵が削除されたことの通知を送信する。オーナ端末は、当該通知に基づき、例えば削除されたゲスト鍵又はそのユーザ名を含むゲスト削除画面を表示する。あるいは、ＤＫＳ３からの通知に基づき、ゲストごとのステータス情報を更新する。

＜車載ＨＭＩを用いてサービス鍵の削除処理について＞
ここでは図３３を用いて車載ＨＭＩに対するユーザ操作に基づき、ユーザにより指定されたサービス鍵を削除する処理の流れについて説明する。車載ＨＭＩに対するユーザ操作に基づき、ユーザにより指定されたサービス鍵を認証ＥＣＵ４及び関連する携帯端末１から削除するシーケンスは、図３３に示すように、ステップＴ５０～Ｔ５７を含む。なお、前提として、ＤＫＳ３は、車載ＨＭＩを介して、操作者の権限に応じたサービス鍵の削除要求を受付可能に構成されている。例えば車載ＨＭＩ５０の操作者がオーナである場合、認証ＥＣＵ４及びＤＫＳ３は、ゲスト鍵のみならず、オーナ鍵に対する削除指示も車載ＨＭＩ５０を介して受付可能に構成されている。図３３を構成するステップのうち、認証ＥＣＵ４が実行するステップについて、その具体的な実行主体は認証プロセッサ４１と解することができる。

ステップＴ５０は認証ＥＣＵ４が、車載ＨＭＩ５０を操作しているユーザを認証するステップである。認証方法としては前述の通り、パスワードの入力を伴う方法や生体情報を用いる方法など多様な方法を採用可能である。当該ステップＴ５０は、車載ＨＭＩ５０の操作者を識別するステップと解することができる。また、認証ＥＣＵ４によるユーザの認証は、認証ＥＣＵ４による携帯端末１の認証結果が流用されても良い。認証ＥＣＵ４は、通信相手としての携帯端末１に対応するユーザを、車載ＨＭＩ５０の操作者とみなしても良い。

ステップＴ５１は、入力装置５２から入力される操作信号に基づいて認証ＥＣＵ４がディスプレイ５１にサービス鍵削除画面を表示する。サービス鍵削除画面は、削除対象とするサービス鍵ＩＤ、又は、ユーザを選択するための画面である。操作者がオーナであると認識されている場合、サービス鍵削除画面は、削除対象としてオーナ鍵も選択可能に構成されている。サービス鍵削除画面は、操作者としてのユーザの権限で削除可能なサービス鍵のリスト、又は、対応するユーザのリストを含みうる。

ステップＴ５２では認証ＥＣＵ４が、入力装置５２の出力信号が示す、サービス鍵削除画面に対するユーザ操作に基づいて、削除対象とするサービス鍵を特定する。そして認証ＥＣＵ４は、ステップＴ５３として車両側記憶部４５から削除対象に指定されたサービス鍵に関するデータを削除する。認証ＥＣＵ４は車両側記憶部４５からのデータ削除が完了すると、削除完了画面を表示する（ステップＴ５４）。削除完了画面は削除したサービス鍵に紐づくユーザ名などの情報を含みうる。なお、削除完了画面の表示は任意の要素であって省略されても良い。

認証ＥＣＵ４は、指定されたサービス鍵に関連するデータの削除が完了すると、ステップＴ５５として、サービス鍵の削除シーケンスが完了したことを示す削除完了通知信号をＤＫＳ３に向けて送信する。削除完了通知信号は、削除したサービス鍵のＩＤ又はそれに対応するユーザＩＤなどを含む。なお、削除対象としてオーナ鍵が指定された場合には、ステップＴ５３にて、車両側記憶部４５からすべてのサービス鍵が削除される。

ＤＫＳ３は、認証ＥＣＵ４からの削除完了通知信号を受信すると、当該受信信号にて指定されているサービス鍵に紐づく携帯端末１に向けて、サービス鍵削除コマンドを送信する（ステップＴ５６）。仮に車載ＨＭＩ５０に対する操作に基づき車両側記憶部４５からオーナ鍵が削除された場合には、ＤＫＳ３は、オーナ端末及び当該オーナ端末に紐づくすべてのゲスト端末に向けて、サービス鍵削除コマンドを送信する。

携帯端末１は、サービス鍵削除コマンドを受信すると、端末チェックコードを用いてその正当性を検証した上で、鍵情報記憶部Ｍ１から指定されたサービス鍵に関連するデータを全て削除する（ステップＴ５７）。各携帯端末１は、より好ましい態様として、サービス鍵の削除処理が完了するとその旨をＤＫＳ３に報告する。

上記の通り、オーナは、車載ＨＭＩ５０を用いても任意のゲストのサービス鍵を削除可能である。また、オーナは、車載ＨＭＩ５０を用いてオーナ鍵も削除可能である。なお、オーナの代わりに、ディーラショップのスタッフが車載ＨＭＩ５０を用いて同様の削除処理を実行可能である。

なお、認証ＥＣＵ４は、セキュリティ解除ツール又はＤＫＳ３からセキュリティ解除信号が入力されたことを条件として車載ＨＭＩ５０を用いたオーナ鍵の削除処理を実行するように構成されていても良い。そのような構成によれば、操作ミスや不正な操作によってオーナ鍵及びそれに紐づく全てのゲスト鍵が削除されてしまう恐れを低減できる。オーナ鍵の削除はゲスト鍵の削除よりもその影響範囲が大きい。故に、オーナ鍵の削除に向けたユーザ認証は、ゲスト鍵の削除に向けたユーザ認証よりも、より高度／複雑に構成されていてもよい。例えばオーナ鍵の削除するためのユーザ認証のステップ数は、ゲスト鍵を削除する際のユーザ認証ステップ数よりも多く設定されていても良い。

また、ＤＫＳ３は、以上で述べたようにオーナ鍵の削除操作が車載ＨＭＩ５０を介して実施されたか否かに応じて、オーナ端末に対して異なるデータを送信する。例えばオーナ鍵の削除操作がオーナ端末で行われた場合には、ＤＫＳ３はオーナ端末に向けて、車両用オーナ鍵削除パッケージを送信する一方、オーナ鍵の削除操作が車載ＨＭＩ５０で行われた場合には、ＤＫＳ３は車両用オーナ鍵削除パッケージを送信しない。当該構成によれば、オーナ端末のデータ通信量を抑制できる。また、そもそもオーナ鍵の削除操作が車載ＨＭＩ５０で行われた場合には、認証ＥＣＵ４はＤＫＳ３から削除用データセットを受信することなく、すべてのサービス鍵を削除する。つまり、ＤＫＳ３の通信量自体も削減できる。

＜ＤＫＳによるサービス鍵の管理方法の補足＞
ＤＫＳ３は、１つのオーナ鍵に紐づくゲスト鍵は、何れもオーナ鍵のサービス鍵ＩＤによって管理する。ＤＫＳ３は、発行権付きゲスト鍵を削除した場合であっても、図３４に示すように、当該発行権付きゲスト鍵の権限で発行された、孫世代／第３世代のゲスト鍵は削除しない。孫世代／第３世代のゲスト鍵はオーナ鍵に紐づくゲスト鍵として存続する。なお、図３４中の１ｘはオーナ鍵を、１ｙは発行権付きゲスト鍵を、１ｚは孫世代／第３世代のゲスト鍵を、それぞれ示している。１ｖは、オーナ鍵が発行したゲスト鍵であって、発行権の有無は任意である。便宜上、１つのオーナ鍵に紐づくゲスト鍵のグループをファミリとも称する。ファミリを構成するサービス鍵はオーナ鍵ＩＤで管理される。

さらに、ＤＫＳ３は、ユーザによる携帯端末１の機種変更の申請を受付可能に構成されている。ユーザによって機種変更が行われた場合、デバイスＩＤは変化しうる。しかしながら、サービス鍵ＩＤに関しては、機種変更が行われた場合であっても、変更されない。ファミリはオーナ鍵のサービス鍵ＩＤによって形成されるため、仮にオーナが携帯端末１の機種を変更した場合であっても、ゲスト鍵には影響はなく、ファミリ自体は存続する。例えばオーナが携帯端末１の機種を変更した場合であっても、オーナ端末のデバイスＩＤ及びサービス鍵が変更されるだけとなる。発行権限付きゲスト鍵を有するゲストの携帯端末１が変更された場合も同様である。つまり、車両用デジタルキーシステムＳｙｓは、ゲスト鍵の発行元となる携帯端末１が別のデバイスに変更された場合であっても、他のゲスト鍵に影響を及ぼさないように構成されている。

ＤＫＳ３は、例えば図３５に示す手順で、オーナ端末変更処理を実施する。オーナ端末変更処理は、オーナ端末の機種変更にかかる処理である。図３５に示すようにオーナ端末認証処理は、ステップＴ６１～Ｔ６８を含みうる。オーナ端末変更処理は、携帯端末１又はＰＣなどから、機種変更の申し出に相当する信号が入力されたことに基づいて開始される。オーナが操作する端末は、機種変更前の携帯端末１である旧端末であってもよいし、機種変更後の携帯端末１である新端末であってもよい。また、オーナが機種変更を申請するデバイスは、デスクトップ／ラップトップＰＣなど、インターネットにアクセスな端末であれば何でも良い。オーナによる所定のデータ引き継ぎ操作により、新端末にもデジタルキーアプリ１０４はインストールされ、且つ、ユーザＩＤ等の情報が登録されているものとする。

ステップＴ６１は、操作者／申請者がオーナであることを認証するステップである。オーナであることの認証方法は前述の通りである。ＤＫＳ３は、操作者がオーナであることを認証すると、ユーザＩＤ等に基づいてユーザＤＢ３３を参照し、オーナの旧デバイスＩＤ及びサービス鍵ＩＤを取得する（ステップＴ６２）。旧デバイスＩＤは、旧端末のデバイスＩＤを指す。また、ＤＫＳ３は新端末とデータ通信を実施することで、新端末のデバイスＩＤである新デバイスＩＤを取得する（ステップＴ６３）。ステップＴ６４は、ＤＫＳ３が新デバイスＩＤを用いてオーナ鍵としてのサービス鍵を新規発行するステップである。具体的なサービス鍵の生成方法は前述のとおりである。

ＤＫＳ３は、新オーナ鍵を生成すると、ユーザＤＢ３３の登録内容を更新する（ステップＴ６５）。例えば、オーナのユーザデータにおいては、旧オーナ鍵を削除して、新オーナ鍵を登録する。旧オーナ鍵とは機種変更前まで使用されていたサービス鍵であって、旧デバイスＩＤに基づくサービス鍵である。なお、本実施形態ではオーナのデバイスが変更された場合であってもオーナのサービス鍵ＩＤは変更されずに従前のＩＤが維持されるため、ゲストのユーザデータに関しては特段の処置は不要である。他の態様として、サービス鍵ＩＤも変更される場合には、ＤＫＳ３は、ゲスト鍵に紐づくオーナのサービス鍵ＩＤを新オーナ鍵ＩＤに置き換えうる。その他、ＤＫＳ３は、新オーナ鍵を生成すると、新オーナ鍵に対応するワンタイム認証鍵を所定数作成する。

そして、ＤＫＳ３は、新端末に向けて端末用鍵交換パッケージを送信する（ステップＴ６６）。端末用鍵交換パッケージは、少なくとも新オーナ鍵を含む。端末用鍵交換パッケージは、鍵情報記憶部Ｍ１に保存されているオーナ鍵を新オーナ鍵に置き換えさせるコマンド／プログラムであってもよい。端末用鍵交換パッケージは、新オーナ鍵に対応する複数のワンタイム認証鍵と、変動コードと、を含みうる。その他、端末用鍵交換パッケージは、端末チェックコードを含んでいても良い。ワンタイム認証鍵にかかるデータセットは、認証鍵パッケージとして端末用鍵交換パッケージとは別に送信されても良い。

新端末としての携帯端末１は、ＤＫＳ３から端末用鍵交換パッケージを受信すると、端末チェックコードをもとにデータの正当性を検証したのちに、新オーナ鍵にかかる受信データを鍵情報記憶部Ｍ１に保存する。具体的には、端末プロセッサ１０１は、受信した新オーナ鍵としてのサービス鍵と、変動コードと紐付けられた複数のワンタイム認証鍵を保存する。

また、ＤＫＳ３は、新オーナ鍵に関するデータを認証ＥＣＵ４に登録するためのデータセットである車両用鍵交換パッケージを、新端末に送信する。車両用鍵交換パッケージは、新オーナ鍵としてのサービス鍵と、車両チェックコードを含む。車両用鍵交換パッケージは、車両側記憶部４５に保存されているオーナ鍵を新オーナ鍵に置き換えさせるコマンド／プログラムであってもよい。

新端末としての携帯端末１は、車両用鍵交換パッケージを受信すると、車両用データ一時記憶部Ｍ２に保存する。そして、認証ＥＣＵ４とＢＬＥ暗号通信リンクが確立したことに基づいて、車両用鍵交換パッケージを認証ＥＣＵ４に転送する。つまり、車両用鍵交換パッケージもまた、車両用登録パッケージと同様に携帯端末１を介して認証ＥＣＵ４に配信される。

認証ＥＣＵ４は車両用鍵交換パッケージを受信すると、車両チェックコードをもとにデータの正当性を検証したのちに、新オーナ鍵にかかる受信データを車両側記憶部４５に保存する。具体的には、認証プロセッサ４１は、受信した新オーナ鍵としてのサービス鍵をオーナ鍵記憶部４５１に保存する。なお、これに伴い認証ＥＣＵ４は、オーナ鍵記憶部４５１に保存されていた旧オーナ鍵を削除する。サービス鍵ＩＤに関しては機種変更後も維持されるため、削除せずに流用しても良い。もちろんサービス鍵ＩＤも一旦削除した後に新規登録されてもよい。

なお、認証ＥＣＵ４は、オーナ鍵記憶部４５１にオーナ鍵が保存されている状態で、オーナ鍵の登録操作を受け付けた場合には、所定の警告メッセージをディスプレイ１１、５１に表示させても良い。警告メッセージは、例えばオーナがすでに登録済みであることを示すメッセージである。その他、認証ＥＣＵ４は、オーナ鍵記憶部４５１にオーナ鍵が保存されている状態でオーナ鍵の登録操作を受け付けた場合には、所定のパスワードの入力を促す画面をディスプレイ１１、５１に表示させても良い。ここで入力を要求するパスワードとしては、例えば、オーナのユーザＩＤに紐づくパスワード、あるいは、オーナ鍵を削除するための所定コードを採用することができる。

その他、ＤＫＳ３は、ステップＴ６８として、旧端末に向けてサービス鍵削除コマンドを送信する。これにより、旧端末がオンライン状態を維持している場合には、旧端末からサービス鍵が削除される。なお、ステップＴ６８は任意の要素であって省略されても良い。

＜システム全体にかかるその他の補足＞
以上では、車両Ｈｖは、一例として個人によって所有される車両とし、オーナもまた個人である場合を想定したが、上記の車両用デジタルキーシステムＳｙｓはＭａａＳ（Mobility as a Service）にも適用可能である。オーナは、例えば車両貸し出しサービスやシェアリングサービスを提供する企業／組織であってもよい。その場合、当該企業／組織に属するオペレータとしてのスタッフが、オーナ端末の操作を行いうる。また、オーナが保有する車両Ｈｖは５０台や１００台など、多数であってもよい。オーナとしてのサービス鍵ＩＤは、複数の車両に対して共通であってもよいし、車両ごとに相違していても良い。ＤＫＳ３の構成は、事業の形態に応じて、車両情報を管理するサーバと、サービス鍵を管理するサーバと分けられていても良い。

上述した実施形態では認証ＥＣＵ４はサービス鍵の登録／削除にかかるデータを、携帯端末１から取得する構成について述べたが、これに限らない。認証ＥＣＵ４はセルラー通信又はＷｉ－Ｆｉ通信によって、携帯端末１を介さずにＤＫＳ３から各種パッケージを受信するように構成されていても良い。

＜付言（１）＞
以上で述べた携帯端末１は、
ユーザの操作に基づいて車両を使用するためのサービス鍵を生成するサーバ（３）に向けて、当該ユーザが所有する車両についてのサービス鍵であって、オーナとしての権限を有するオーナ鍵を発行するように要求する、オーナ鍵発行要求信号を送信することと、
オーナ鍵発行要求信号に対するサーバの応答として、サーバからオーナ鍵を受信することと、
受信したオーナ鍵を所定の端末側記憶装置（１０５）に保存することと、
車両に搭載されている車両用装置（４）と近距離無線通信の通信リンクが確立していることを条件として、オーナ鍵を車両用装置に登録するための通信を開始することと、を実行するように構成されている、携帯可能な汎用的情報処理端末と解することができる。

また、デジタルキーアプリ１０４は、汎用的なコンピュータを携帯端末１として実行させるコンピュータプログラムと解することができる。加えて、デジタルキーアプリ１０４が保存されている記憶媒体は、コンピュータを上記の携帯端末１として動作させる命令セットが格納された記憶媒体に相当する。

＜付言（２）＞
本開示に記載の装置、システム、並びにそれらの手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサを構成する専用コンピュータにより、実現されてもよい。また、本開示に記載の装置及びその手法は、専用ハードウェア論理回路を用いて実現されてもよい。さらに、本開示に記載の装置及びその手法は、コンピュータプログラムを実行するプロセッサと一つ以上のハードウェア論理回路との組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。

例えば認証プロセッサが備える機能の一部又は全部はハードウェアとして実現されても良い。或る機能をハードウェアとして実現する態様には、１つ又は複数のＩＣなどを用いて実現する態様が含まれる。プロセッサ（演算コア）としては、ＣＰＵや、ＭＰＵ、ＧＰＵ、ＤＦＰ（Data Flow Processor）などを採用可能である。また、認証プロセッサが備える機能の一部又は全部は、複数種類の演算処理装置を組み合わせて実現されていてもよい。認証プロセッサが備える機能の一部又は全部は、システムオンチップ（ＳｏＣ：System-on-Chip）や、ＦＰＧＡ、ＡＳＩＣなどを用いて実現されていても良い。ＦＰＧＡはField-Programmable Gate Arrayの略である。ＡＳＩＣはApplication Specific Integrated Circuitの略である。上記補足説明は、端末プロセッサ及びサーバプロセッサついても同様に適用可能である。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体（non- transitory tangible storage medium）に記憶されていてもよい。プログラムの保存媒体としては、ＨＤＤ（Hard-disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリ等を採用可能である。

１ 携帯端末、２ 専用キー、３ デジタルキーサーバ（ＤＫＳ）、４ 認証ＥＣＵ、７ 車載システム、１０ 端末制御部、１１ ディスプレイ、１２ タッチパネル（入力装置）、１６・５７ ＢＬＥ通信部（近距離通信部）、１７ セルラー通信部（ネット接続部）、１８ Ｗｉ－Ｆｉ通信部（ネット接続部）１０１ 端末プロセッサ、１０４ デジタルキーアプリ、１０５ 端末側記憶部（端末側記憶装置）、Ｍ１ 怪情報記憶部、Ｍ２ 車両用データ１次記憶部、２０ 制御回路、２１・５６ 近接場通信部、３０ データ処理部、３２ 車両データベース、３３ ユーザデータベース、３０１ サーバプロセッサ、３０３ ストレージ、４０ 車両制御部、４１ 認証プロセッサ、４５ 車両側記憶部（車両側記憶装置）、４５１ オーナ鍵記憶部、４５２ ゲスト鍵記憶部、５０ 車載ＨＭＩ、５１ ディスプレイ、５２ 入力装置。

Claims (15)

1. 車両に搭載されて使用される車両用装置（４）と、
   ユーザによって携帯される情報処理端末である携帯端末（１）と、
   前記車両を使用するための鍵情報として、前記携帯端末ごとに固有のサービス鍵を生成し、前記携帯端末及び前記車両用装置のそれぞれに直接的に又は間接的に配布するサーバ（３）と、を含む車両用デジタルキーシステムであって、
   前記車両用装置は、前記サービス鍵をもとに生成される、使い捨てのワンタイム認証鍵を用いて前記携帯端末の正当性を判断するように構成されており、
   前記サーバは、前記携帯端末からの要求に基づき、複数の前記ワンタイム認証鍵を生成し、有効期限付きで前記携帯端末に配信し、
   前記携帯端末は、
   前記サーバから前記ワンタイム認証鍵を受信し、所定の端末側記憶装置（１０５）に保存することと、
   前記ワンタイム認証鍵ごとの有効期限に基づき、前記端末側記憶装置に保存されている前記ワンタイム認証鍵の一部又は全部を入れ替えるように構成されている車両用デジタルキーシステム。
2. 請求項１に記載の車両用デジタルキーシステムであって、
   前記車両用装置と前記携帯端末は、所定の近距離無線通信規格に準拠した無線通信である近距離無線通信によって相互にデータ通信可能に構成されており、
   前記ワンタイム認証鍵は、前記サービス鍵に毎回異なる変動コードを組み合わせることによって生成されるコードであって、
   前記携帯端末は、
   前記ワンタイム認証鍵とともに、当該ワンタイム認証鍵の生成に使用された前記変動コードを示す情報を前記サーバから受信することと、
   前記車両用装置との間に前記近距離無線通信のリンクが確立していることを条件として、前記車両用装置に対して前記変動コードを送信することと、を実行し、
   前記車両用装置は、
   前記サーバが発行した前記携帯端末についての前記サービス鍵を保持する車両側記憶装置（４５）を備え、
   前記車両側記憶装置に保存されている前記携帯端末の前記サービス鍵と、前記携帯端末から受信した前記変動コードとを組み合わせることで前記ワンタイム認証鍵を生成することと、
   生成した前記ワンタイム認証鍵を用いて前記携帯端末の正当性を判断するように構成されている車両用デジタルキーシステム。
3. 請求項１に記載の車両用デジタルキーシステムであって、
   前記車両用装置と前記携帯端末は、所定の近距離無線通信規格に準拠した無線通信である近距離無線通信によって相互にデータ通信可能に構成されており、
   前記車両用装置は、
   前記携帯端末に対して発行された複数の前記ワンタイム認証鍵を前記携帯端末又は前記サーバから取得して車両側記憶装置（４５）に保存することと、
   前記サーバが発行した複数の前記ワンタイム認証鍵の中から認証処理に使用する前記ワンタイム認証鍵を一致させるための調整メッセージを前記近距離無線通信にて前記携帯端末とやりとりすることと、
   前記調整メッセージに基づき特定される前記ワンタイム認証鍵を用いて前記携帯端末の正当性を判断するように構成されている車両用デジタルキーシステム。
4. 請求項１から３の何れか１項に記載の車両用デジタルキーシステムであって、
   前記携帯端末は、
   前記端末側記憶装置に保存されている前記ワンタイム認証鍵の残数が所定値未満であるか否かの判定を、定期的に又は所定の確認イベントの発生を検知したことに基づいて実行するように構成されており、
   前記ワンタイム認証鍵の残数が所定値未満であることを検知した際にインターネットにアクセス可能である場合には、前記サーバから前記ワンタイム認証鍵を取得するための通信を実行するように構成されている車両用デジタルキーシステム。
5. 請求項１から４の何れか１項に記載の車両用デジタルキーシステムであって、
   前記サーバは、
   前記車両のオーナが所持する前記携帯端末であるオーナ端末についての情報が、前記オーナとしての権限を有する前記サービス鍵であるオーナ鍵の情報と対応付けられて保存されているデータベース（３３）を備え、
   前記オーナ端末から発せられる所定のゲスト鍵発行要求信号を受信したことに基づき、前記オーナ以外の前記ユーザであるゲストのための前記サービス鍵であるゲスト鍵を発行することを実施可能に構成されており、
   前記ゲスト鍵には、他の前記ゲスト鍵を発行する権限を有する発行権付きゲスト鍵と、他の前記ゲスト鍵の発行権限を有さない発行権なしゲスト鍵の２種類が存在し、
   前記オーナ端末からの要求に基づき前記ゲスト鍵を発行する際、前記オーナ端末から受信した信号に基づき、当該ゲスト鍵を発行権付きゲスト鍵とするか前記発行権なしゲスト鍵とするかを決定するように構成されている車両用デジタルキーシステム。
6. 請求項５に記載の車両用デジタルキーシステムであって、
   前記発行権付きゲスト鍵を有する前記携帯端末、又は、前記オーナ端末は、ユーザ操作に基づき、前記ゲスト鍵発行要求信号として、新規に発行する前記ゲスト鍵に付与する権限の設定情報を含むデータセットを送信し、
   前記サーバは、前記ゲスト鍵の発行要求元から取得した前記設定情報に応じた制限を有する前記ゲスト鍵を発行する車両用デジタルキーシステム。
7. 請求項６に記載の車両用デジタルキーシステムであって、
   前記オーナ端末は、前記車両に紐づく前記ゲスト鍵を選択的に削除するための操作は受付可能に構成されている一方、前記ゲスト鍵を削除せずに有効期限又は権限にかかる設定だけを変更する操作は受け付け不能に構成されている車両用デジタルキーシステム。
8. 請求項５から７の何れか１項に記載の車両用デジタルキーシステムであって、
   前記サーバは、
   １つの前記車両に紐づく複数の前記ゲスト鍵を、前記オーナ鍵に紐づく識別番号であるオーナ鍵番号と対応付けて前記データベースに保存し、
   当該オーナ鍵番号を元に１つの前記車両に紐づく前記サービス鍵を管理するように構成されている車両用デジタルキーシステム。
9. 請求項８に記載の車両用デジタルキーシステムであって、
   前記サーバは、前記オーナ端末からの要求に基づき前記ゲスト鍵を発行した場合には、前記ゲスト鍵に対応する前記携帯端末であるゲスト端末に対して、前記ゲスト鍵とともに前記オーナ鍵番号を配信するように構成されている車両用デジタルキーシステム。
10. 請求項８又は９に記載の車両用デジタルキーシステムであって、
    前記サーバは、
    前記ユーザが所持する前記携帯端末の変更を受け付け可能に構成されており、
    前記オーナが所持する前記携帯端末が変更された場合であっても、前記オーナに紐づく前記ゲストに配布した前記サービス鍵は削除しないように構成されている車両用デジタルキーシステム。
11. 請求項１から１０の何れか１項に記載の車両用デジタルキーシステムであって、
    前記車両のオーナ以外の前記ユーザであるゲストのための前記サービス鍵であるゲスト鍵には、当該ゲスト鍵の発行要求元によって指定された有効期限が設定されており、
    前記車両用装置は、有効期限切れとなった前記ゲスト鍵の情報を自動的に削除するように構成されている車両用デジタルキーシステム。
12. 請求項１から１１の何れか１項に記載の車両用デジタルキーシステムであって、
    前記車両用装置と前記携帯端末は、所定の近距離無線通信規格に準拠した無線通信である近距離無線通信によって相互にデータ通信可能に構成されており、
    前記サーバと前記携帯端末は、インターネットを介して通信可能に構成されており、
    前記車両用装置は、
    前記携帯端末との間に前記近距離無線通信のリンクが確立したことに基づいて前記携帯端末を介して前記サーバから時刻情報を取得することと、
    取得した前記時刻情報を用いて、前記車両用装置が保持する時刻情報である内部時刻を修正することと、を実行可能に構成されている車両用デジタルキーシステム。
13. ユーザによって携帯される情報処理端末である携帯端末（１）と、
    車両に搭載されて使用される車両用装置（４）と、
    前記車両を使用するための鍵情報として、前記携帯端末ごとに固有のサービス鍵を生成するサーバ（３）と、によって実行される車両用デジタルキー管理方法であって、
    前記サーバが、前記携帯端末からの要求に基づき、前記携帯端末の前記サービス鍵をもとに、複数の使い捨てのワンタイム認証鍵を生成し、有効期限付きで前記携帯端末に配信することと、
    前記携帯端末が、前記サーバから前記ワンタイム認証鍵を受信し、所定の端末側記憶装置（１０５）に保存することと、
    前記携帯端末が、前記ワンタイム認証鍵ごとの有効期限に基づき、定期的に前記端末側記憶装置に保存されている前記ワンタイム認証鍵の一部又は全部を入れ替えることと、
    前記車両用装置が、前記サーバ又は前記携帯端末との通信により、前記携帯端末が保有する前記ワンタイム認証鍵のうちの何れか１つを特定することと、
    前記車両用装置が、特定された前記ワンタイム認証鍵を用いて前記携帯端末の正当性を判断することと、を含む車両用デジタルキー管理方法。
14. ユーザによって携帯される情報処理端末である携帯端末（１）、及び、車両を使用するための鍵情報として前記携帯端末ごとに固有のサービス鍵を生成するサーバ（３）のそれぞれの通信可能に構成された、前記車両に搭載されて使用される車両用装置であって、
    前記ユーザごとの前記サービス鍵が保存されている車両側記憶装置（４５）と、
    少なくとも１つのプロセッサを用いてなる車両制御部（４０）と、を含み、
    前記車両制御部は、
    前記車両側記憶装置に保存されている前記サービス鍵に基づいて、使い捨ての認証鍵であるワンタイム認証鍵を生成することと、
    前記ワンタイム認証鍵を用いて前記携帯端末の正当性を判断することと、を実行するように構成されている車両用装置。
15. 車両に搭載されて使用される車両用装置（４）、及び、前記車両を使用するための鍵情報としてのサービス鍵を生成するサーバ（３）のそれぞれの通信可能に構成された、ユーザによって携帯される情報処理端末である携帯端末であって、
    前記サービス鍵のデータを記憶している端末側記憶装置（１０５）と、
    前記車両用装置と所定の近距離無線通信規格に準拠した無線通信である近距離無線通信を実施するための近距離通信部（１６）と、
    インターネットを介して前記サーバと通信するためのネット接続部（１７，１８）と、
    少なくとも１つのプロセッサを用いてなる端末制御部（１０）と、を備え、
    前記端末制御部は、
    前記インターネットに接続できていることを条件として、前記サーバに対し、前記サービス鍵を元に生成される有効期限付きのワンタイム認証鍵を複数まとめて配信するように要求する認証鍵要求信号を送信することと、
    前記サーバから前記ワンタイム認証鍵を受信して前記端末側記憶装置に保存することと、
    前記ワンタイム認証鍵ごとの有効期限に基づき、前記端末側記憶装置に保存されている前記ワンタイム認証鍵の一部又は全部を入れ替えることと、を実施するように構成されている携帯端末。

Images