特開2024-137643 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ 小米汽車科技有限公司の特許一覧

特開2024-137643端末デバイス及び端末デバイスのデータ処理方法

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024137643

(43)【公開日】2024-10-07

(54)【発明の名称】端末デバイス及び端末デバイスのデータ処理方法

(51)【国際特許分類】

B60R 25/24 20130101AFI20240927BHJP

G06F 21/33 20130101ALI20240927BHJP

H04L 9/08 20060101ALI20240927BHJP

E05B 19/00 20060101ALI20240927BHJP

E05B 49/00 20060101ALI20240927BHJP

【ＦＩ】

B60R25/24

G06F21/33

H04L9/08 B

H04L9/08 A

E05B19/00 J

E05B49/00 J

【審査請求】有

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2023189599

(22)【出願日】2023-11-06

(31)【優先権主張番号】202310308486.4

(32)【優先日】2023-03-24

(33)【優先権主張国・地域又は機関】CN

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ｉＯＳ

２．アンドロイド

(71)【出願人】

【識別番号】522381085

【氏名又は名称】小米汽車科技有限公司

(74)【代理人】

【識別番号】100118913

【弁理士】

【氏名又は名称】上田邦生

(74)【代理人】

【識別番号】100142789

【弁理士】

【氏名又は名称】柳順一郎

(74)【代理人】

【識別番号】100201466

【弁理士】

【氏名又は名称】竹内邦彦

(72)【発明者】

【氏名】スン，チャンユー

【テーマコード（参考）】

2E250

【Ｆターム（参考）】

2E250AA21

2E250FF23

2E250FF36

2E250HH01

(57)【要約】（修正有）

【課題】端末デバイス及び端末デバイスのデータ処理方法を提供する。
【解決手段】端末デバイスは通信装置を備える端末デバイスのデータ処理方法において、通信装置は、端末デバイスのネイティブシステムがデジタル車両キーのパブリックプロトコルに適応するためのコンポーネントを含むか否かを検出しＳ９１、ネイティブシステムが少なくとも１つのコンポーネントを欠落している場合、パブリックプロトコルに基づく通信をパブリックプロトコルの参加者であるターゲット通信者と行うＳ９２。
【選択図】図９

【特許請求の範囲】

【請求項1】

通信装置を備え、
該通信装置は、端末デバイスのネイティブシステムがデジタル車両キーのパブリックプロトコルに適合するためのコンポーネントを含むか否かを検出し、前記ネイティブシステムが少なくとも１つの前記コンポーネントを欠落している場合、前記パブリックプロトコルに基づく通信を、前記パブリックプロトコルの参加者であるターゲット通信者と行うように構成される端末デバイス。

【請求項2】

前記通信装置が、
車両サーバと通信可能であり、前記パブリックプロトコルにおいて規定された車両メーカアプリケーションの機能を実現するように構成されるデジタルキーモジュールと、
端末デバイスサーバと通信可能であり、前記パブリックプロトコルにおいて規定された端末デバイスメーカアプリケーションの機能を実現するように構成されるローカルアプリケーションモジュールと、
前記パブリックプロトコルにおいて規定されたデジタルキーフレームワークの機能を実現するように構成されるデジタルキーフレームワークモジュールと、
前記パブリックプロトコルにおいて規定されたデジタルキープログラムの機能を実現するように構成されるキー管理モジュールと、
を備える請求項１に記載の端末デバイス。

【請求項3】

前記通信装置が、デジタル車両キーデータを記憶するように構成される暗号化ホワイトボックスモジュールを備える請求項２に記載の端末デバイス。

【請求項4】

前記ローカルアプリケーションモジュールが、車両サーバにおける端末デバイスサービスモジュールに基づいて前記端末デバイスサーバと通信するように構成される請求項２に記載の端末デバイス。

【請求項5】

前記パブリックプロトコルは、証明書認証に基づくパブリックプロトコルであり、
前記ターゲット通信者が、車両サーバ及び端末デバイスサーバを備え、
前記端末デバイスが、キー共有要求を受信したことに応答して、前記デジタルキーモジュールを介して前記車両サーバと通信し、前記ローカルアプリケーションモジュールを介して前記端末デバイスサーバと通信することで、キー共有の認証ステップを完了し、共有されたデジタル車両キーを得るために用いられる請求項２に記載の端末デバイス。

【請求項6】

前記パブリックプロトコルは、ＣＣＣプロトコル又はＩＣＣＯＡプロトコルである請求項５に記載の端末デバイス。

【請求項7】

前記ターゲット通信者が、車両を備え、
前記端末デバイスが、前記通信装置を介して、前記パブリックプロトコルに基づく通信を前記車両と行うことで、セキュリティチャネルを確立し、且つ前記セキュリティチャネルを介して、前記車両を制御してターゲット動作を実行させるためのターゲット制御命令を前記車両に送信するために用いられる請求項１から６のいずれか一項に記載の端末デバイス。

【請求項8】

請求項１から６のいずれか一項に記載の端末デバイスに適用され、
前記端末デバイスのネイティブシステムがデジタル車両キーのパブリックプロトコルに適合するためのコンポーネントを含むか否かを検出するステップと、
前記ネイティブシステムが少なくとも１つの前記コンポーネントを欠落している場合、前記パブリックプロトコルに基づく通信を、前記パブリックプロトコルの参加者であるターゲット通信者と行うステップと、
を含む、端末デバイスのデータ処理方法。

【請求項9】

前記パブリックプロトコルは、証明書認証に基づくパブリックプロトコルであり、
前記ターゲット通信者が、車両サーバ及び端末デバイスサーバを備え、
前記パブリックプロトコルに基づく通信をターゲット通信者と行うステップが、
キー共有要求を受信したことに応答して、通信装置内のデジタルキーモジュールを介して前記車両サーバと通信し、前記通信装置内のローカルアプリケーションモジュールを介して前記端末デバイスサーバと通信することで、キー共有の認証ステップを完了し、共有されたデジタル車両キーを得るステップを含む請求項８に記載の方法。

【請求項10】

前記ターゲット通信者が、車両を備え、
前記パブリックプロトコルに基づく通信をターゲット通信者と行うステップが、
前記通信装置を介して、前記パブリックプロトコルに基づく通信を前記車両と行うことで、セキュリティチャネルを確立するステップと、
前記セキュリティチャネルを介して、前記車両を制御してターゲット動作を実行させるためのターゲット制御命令を前記車両に送信するステップと、
を含む請求項８に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、端末技術分野に関し、特に、端末デバイス及び端末デバイスのデータ処理方法に関する。

【背景技術】

【0002】

車両キーとしての端末デバイスは近年登場している人気技術であり、当該機能はデジタル車両キーとも呼ばれる。従来の有形の車両キーとは違い、デジタル車両キーは車両キーの機能を移動端末デバイスに統合することにより、車ドアの開閉、車両の起動などの機能を実現することができる。現在、一部の車両メーカや移動端末メーカが連携でデジタル車両キーの解決案を開発している。しかしながら、これらの解決案は適用性が低く、設定コストも高い。

【発明の概要】

【0003】

関連技術に存在する問題を解決するために、本開示は端末デバイス及び端末デバイスのデータ処理方法を提供する。

【0004】

本開示の実施例の第１態様によると、通信装置を備える端末デバイスを提供し、前記通信装置は、前記端末デバイスのネイティブシステムがデジタル車両キーのパブリックプロトコルに適合するためのコンポーネントを含むか否かを検出し、前記ネイティブシステムが少なくとも１つの前記コンポーネントを欠落している場合、前記パブリックプロトコルに基づく通信を、前記パブリックプロトコルの参加者であるターゲット通信者と行うように構成される。

【0005】

選択可能に、前記通信装置は、車両サーバと通信可能であり、前記パブリックプロトコルにおいて規定された車両メーカアプリケーションの機能を実現するように構成されるデジタルキーモジュールと、端末デバイスサーバと通信可能であり、前記パブリックプロトコルにおいて規定された端末デバイスメーカアプリケーションの機能を実現するように構成されるローカルアプリケーションモジュールと、前記パブリックプロトコルにおいて規定されたデジタルキーフレームワークの機能を実現するように構成されるデジタルキーフレームワークモジュールと、前記パブリックプロトコルにおいて規定されたデジタルキープログラムの機能を実現するように構成されるキー管理モジュールと、を備える。

【0006】

選択可能に、前記通信装置は、デジタル車両キーデータを記憶するように構成される暗号化ホワイトボックスモジュールを備える。

【0007】

選択可能に、前記ローカルアプリケーションモジュールは、車両サーバにおける端末デバイスサービスモジュールに基づいて前記端末デバイスサーバと通信するように構成される。

【0008】

選択可能に、前記パブリックプロトコルは、証明書認証に基づくパブリックプロトコルであり、前記ターゲット通信者は、車両サーバ及び端末デバイスサーバを備え、前記端末デバイスは、キー共有要求を受信したことに応答して、前記デジタルキーモジュールを介して前記車両サーバと通信し、前記ローカルアプリケーションモジュールを介して前記端末デバイスサーバと通信することで、キー共有の認証ステップを完了し、共有されたデジタル車両キーを得るために用いられる。

【0009】

選択可能に、前記パブリックプロトコルは、ＣＣＣプロトコル又はＩＣＣＯＡプロトコルである。

【0010】

選択可能に、前記ターゲット通信者は、車両を備え、前記端末デバイスは、前記通信装置を介して、前記パブリックプロトコルに基づく通信を前記車両と行うことで、セキュリティチャネルを確立し、且つ前記セキュリティチャネルを介して、前記車両を制御してターゲット動作を実行させるためのターゲット制御命令を前記車両に送信するために用いられる。

【0011】

本開示の実施例の第２の態様によると、上記第１態様のいずれか一項に記載の端末デバイスに適用される端末デバイスのデータ処理方法を提供し、前記方法は、前記端末デバイスのネイティブシステムがデジタル車両キーのパブリックプロトコルに適合するためのコンポーネントを含むか否かを検出するステップと、前記ネイティブシステムが少なくとも１つの前記コンポーネントを欠落している場合、前記パブリックプロトコルに基づく通信を、前記パブリックプロトコルの参加者であるターゲット通信者と行うステップと、を含む。

【0012】

選択可能に、前記パブリックプロトコルは、証明書認証に基づくパブリックプロトコルであり、前記ターゲット通信者は、車両サーバ及び端末デバイスサーバを備え、前記パブリックプロトコルに基づく通信をターゲット通信者と行うステップは、キー共有要求を受信したことに応答して、通信装置内のデジタルキーモジュールを介して前記車両サーバと通信し、前記通信装置内のローカルアプリケーションモジュールを介して前記端末デバイスサーバと通信することで、キー共有の認証ステップを完了し、共有されたデジタル車両キーを得るステップを含む。

【0013】

選択可能に、前記ターゲット通信者は、車両を備え、前記パブリックプロトコルに基づく通信をターゲット通信者と行うステップは、前記通信装置を介して、前記パブリックプロトコルに基づく通信を前記車両と行うことで、セキュリティチャネルを確立するステップと、前記セキュリティチャネルを介して、前記車両を制御してターゲット動作を実行させるためのターゲット制御命令を前記車両に送信するステップと、を含む。

【0014】

上記技術案では、端末デバイス内に通信装置が設置され、前記通信装置は、前記端末デバイスのネイティブシステムがデジタル車両キーのパブリックプロトコルに適合するためのコンポーネントを含むか否かを検出することができる。そして、前記ネイティブシステムが少なくとも１つの前記コンポーネントを欠落している場合、前記パブリックプロトコルに基づく通信を、前記パブリックプロトコルの参加者であるターゲット通信者と行う。

【発明の効果】

【0015】

このように、前記端末デバイスは、前記通信装置を介して、前記パブリックプロトコルに基づく通信をターゲット通信者と行うことができ、したがって、前記パブリックプロトコルに基づくデジタル車両キーの機能を実現することができる。このような方式により、パブリックプロトコルを様々な端末デバイスに適用することができ、したがって、前記パブリックプロトコルの適用範囲を拡大する。同時に、パブリックプロトコルをサポートしない端末デバイスも、前記通信装置を介して前記パブリックプロトコルに基づく通信を行うことができるので、デジタル車両キー機能が実現される。したがって、端末デバイス内においてプライベートプロトコルに基づいてデジタル車両キーを実現するためのコンポーネントを配置する必要がなくなり、これによってデジタル車両キーの設定コストを削減する。

【0016】

なお、以上の一般的な説明と以下の詳しい説明は例示的と説明的なものであり、本開示を限定するものではない。

【図面の簡単な説明】

【0017】

ここの図面は明細書に組み込まれて本明細書の一部となり、本開示に適合する実施例を示し、明細書とともに本開示の原理を説明する。

【図1】例示的な一実施例に示すＩＣＣＯＡプロトコルに基づくデジタル車両キーシステムのアーキテクチャ図である。

【図2】例示的な一実施例に示す端末デバイスのブロック図である。

【図3】例示的な一実施例に示す通信装置のブロック図である。

【図4】例示的な一実施例に示す通信装置及び暗号化ホワイトボックスのブロック図である。

【図5】例示的な一実施例に示すデジタル車両キーの運用を開始するフローチャートである。

【図6】例示的な一実施例に示すＩＣＣＯＡのデジタル車両キーのアーキテクチャ図である。

【図7】例示的な一実施例に示すキー共有のフローチャートである。

【図8】例示的な一実施例に示す移動端末と車両の標準認証のフローチャートである。

【図9】例示的な一実施例に示す端末デバイスのデータ処理方法のフローチャートである。

【発明を実施するための形態】

【0018】

ここで、例示的な実施例を詳しく説明し、その例は図面に示される。以下の説明は図面に関連する場合、別の表示がない限り、異なる図面における同じ数字は、同じ又は類似する要素を表す。以下の例示的な実施例で説明される実施形態は、本開示に一致するすべての実施形態を表すものではない。むしろ、それらは添付の特許請求の範囲で詳しく説明された、本開示の一部の態様に一致する装置と方法の例に過ぎない。

【0019】

本開示の端末デバイス及び端末デバイスのデータ処理方法を説明する前に、まず、本開示の適用シーンを説明する。

【0020】

端末デバイスを車両キーとすることは、近年登場している人気技術であり、当該機能はデジタル車両キーとも呼ばれる。従来の有形の車両キーと異なって、デジタル車両キーは車両キー機能を移動端末デバイスに統合することで、車ドアの開閉や車両の起動などの機能を実現することができる。

【0021】

例えば、いくつかのシーンでは、自動車メーカは、プライベートプロトコルに基づくデジタル車両キーを開発することができる。プライベートプロトコルに関連するデータを自動車メーカアプリケーションにカプセル化することにより、前記自動車メーカアプリケーションをインストールした端末デバイスは前記プライベートプロトコルに基づいて車両及び車両サーバとインタラクトすることができ、これによって車両制御、キー共有などのデジタル車両キーの機能を実現する。デジタル車両キーの機能を実現するために、自動車メーカアプリケーションは、端末デバイスにおいて実行する必要があり、例えばフォアグラウンドで実行し、端末デバイスのリソースを多く消費するので、又はバックグラウンドで保留することもできる。

【0022】

このため、一部の自動車メーカと移動端末メーカはデジタル車両キーの解決案、すなわちパブリックプロトコルに基づくデジタル車両キーの解決案を連携開発した。プライベートプロトコルと比べて、パブリックプロトコルはオペレーティングシステムの最下層に基づいてデジタル車両キーの機能を実現することができる。

【0023】

ここで、「ＩＣＣＯＡ」というパブリックプロトコルを例として説明し、図１に示すＩＣＣＯＡプロトコルに基づくデジタル車両キーシステムのアーキテクチャ図を参照されたい。パブリックプロトコルに基づく車両デジタルキーの解決案では、デジタル車両キーに関連する操作をデジタルキーフレームワーク（ＤｉｇｉｔａｌＫｅｙＦｒａｍｅｗｏｒｋ、ＤＫＦ）としてカプセル化することができる。デジタルキーフレームワークは、例えばデバイスペアリング、キーライフサイクル管理、キーロック解除、キーロック、共有、車両制御など、上位アプリケーションが呼び出すための様々なＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ、アプリケーションプログラミングインターフェース）を提供することができる。デジタルキーフレームワークをシステムレベルで設定することにより、端末デバイスはオペレーティングシステムの最下層に基づいてデジタル車両キーの機能を実現することができ、消費するリソースが少なく、ユーザ体験がよいという利点を有する。

【0024】

なお、パブリックプロトコルは、自動車メーカと移動端末メーカが連携で開発したものであるので、端末デバイスのタイプが制限される。例えば、端末メーカＡと自動車メーカが連携でパブリックプロトコル１を開発する場合、端末メーカＡ傘下の端末デバイスＡ１は前記パブリックプロトコル１をサポートできるが、端末メーカＢ傘下の端末デバイスＢ１は、前記パブリックプロトコル１をサポートしにくいので、ユーザ体験に影響を与える。例えば、いくつかのシーンでは、車両の使用者は、車両所有者とそのフレンドを含むことができ、しかしながら、車両所有者が使用するのはパブリックプロトコル１をサポートする端末デバイスＡ１であり、そのフレンドが使用するのはパブリックプロトコル１をサポートしない端末デバイスＢ１であるため、車両所有者はデジタル車両キーをフレンドに共有することができない。

【0025】

そのため、互換性を確保するために、自動車メーカは、通常、プライベートプロトコルに基づくデジタル車両キーの解決案及びパブリックプロトコルに基づくデジタル車両キーの解決案を同時に開発する必要がある。２種類の解決案はいずれも端末デバイスに設定することができる。しかし、これはデジタル車両キー解決案の開発・実装コストが高いことをもたらす。

【0026】

そのため、本開示は端末デバイスを提供し、前記端末デバイスは携帯電話、タブレットなどの移動端末デバイスであってもよいし、デジタルキー機能を搭載できる他のタイプの端末デバイスであってもよい。

【0027】

図２は、本開示に示す端末デバイスのブロック図であり、図２を参照すると、前記端末デバイスは通信装置を備え、前記通信装置は、前記端末デバイスのネイティブシステムがデジタル車両キーのパブリックプロトコルに適合するためのコンポーネントを含むか否かを検出し、前記ネイティブシステムが少なくとも１つの前記コンポーネントを欠落している場合、前記パブリックプロトコルに基づく通信を、前記パブリックプロトコルの参加者であるターゲット通信者と行うように構成される。

【0028】

ここで、前記端末デバイスのネイティブシステムは、前記端末デバイス出荷時に搭載されたシステムであってもよく、端末デバイスの相違に応じて、前記ネイティブシステムは、例えばｉＯＳシステム、鴻蒙システム、アンドロイドシステムなど、様々な形式があってもよく、本開示では限定されない。パブリックプロトコルに基づくデジタル車両キーを実現するために、対応するコンポーネントを端末デバイスにおいて設定する必要がある。これらのコンポーネントはセキュリティユニット、デジタルキーフレームワーク、信頼可能な実行環境などを含むことができ、その種類は、具体的には、関連するデジタル車両キーのパブリックプロトコルの説明を参照されたい。

【0029】

前記通信装置は、前記端末デバイスのネイティブシステムがデジタル車両キーのパブリックプロトコルに適合するためのコンポーネントを含むか否かを検出することができる。前記ネイティブシステムが１つ又は複数の前記コンポーネントを欠落している場合、前記通信装置は、前記パブリックプロトコルに基づく通信を、前記パブリックプロトコルの参加者であるターゲット通信者と行うことができる。

【0030】

ここで、前記通信装置は、ソフトウェア、ハードウェア、又はソフトウェアとハードウェアの組み合わせの形式で表すことができる。例えば、可能な一実施形態では、前記通信装置はＳＤＫ（ＳｏｆｔｗａｒｅＤｅｖｅｌｏｐｍｅｎｔＫｉｔ、ソフトウェア開発キット）の形で表すことができる。前記パブリックプロトコルは、証明書システムに基づくパブリックプロトコル、例えばＣＣＣ（ＣａｒＣｏｎｎｅｃｔｉｖｉｔｙＣｏｎｓｏｒｔｉｕｍ、カーコネクティビティコンソーシアム）プロトコル又はＩＣＣＯＡ（ＩｎｔｅｌｌｉｇｅｎｔＣａｒＣｏｎｎｅｃｔｉｖｉｔｙＯｐｅｎＡｌｌｉａｎｃｅ、インテリジェントカーコネクティビティオープアライアンス）プロトコルであってもよい。パブリックプロトコルは暗号鍵認証に基づくパブリックプロトコル、例えばＩＣＣＥ（ＩｎｔｅｌｌｉｇｅｎｔＣａｒＣｏｎｎｅｃｔｉｖｉｔｙＩｎｄｕｓｔｒｙＥｃｏｓｙｓｔｅｍＡｌｌｉａｎｃｅＤｉｇｉｔａｌＫｅｙＳｙｓｔｅｍ、インテリジェントカーコネクティビティインダストリーエコロジカルアライアンスデジタルキーシステム）プロトコルであってもよい。

【0031】

以下、「ＩＣＣＯＡ」というパブリックプロトコルを例として、前記通信装置を説明する。

【0032】

図３は、本開示に示す通信装置のブロック図である。１つの可能な実施形態では、前記通信装置はデジタルキーモジュールを備えることができる。前記デジタルキーモジュールは、車両サーバと通信可能であり、前記パブリックプロトコルにおいて規定された車両メーカアプリケーションの機能を実現するように構成される。

【0033】

ＩＣＣＯＡプロトコルにおいて、車両メーカアプリケーションが、デジタル車両キーに関連する機能インターフェースをユーザに提供する必要があることが規定されている。そのため、関連するキー管理機能方法をカプセル化して、前記デジタルキーモジュールを得ることができる。ここで、キー管理機能方法はキー作成、キー共有、キー削除、ＲＫＥ（ＲｅｍｏｔｅＫｅｙｌｅｓｓＥｎｔｒｙ、リモートキーレスエントリー）などを含むことができる。デジタルキーモジュールはＳＤＫの形で表し、かつ上記キー管理機能方法のインターフェースを提供することができる。

【0034】

図３を参照すると、１つの可能な実施形態において、前記通信装置は、前記パブリックプロトコルにおいて規定された端末デバイスメーカアプリケーションの機能を実現するように構成されるローカルアプリケーションモジュールを備える。

【0035】

前記ローカルアプリケーションモジュールは端末デバイスサーバと通信することができる。いくつかの実施のシーンでは、前記ローカルアプリケーションモジュールは、直接、前記端末デバイスサーバと通信するように構成され得る。いくつかの実施のシーンでは、車両サーバに端末デバイスサービスモジュールを設定してもよい。このように、前記ローカルアプリケーションモジュールは、車両サーバにおける端末デバイスサービスモジュールに基づいて前記端末デバイスサーバと通信するように構成される。

【0036】

ＩＣＣＯＡプロトコルにおいて、端末デバイスメーカアプリケーションが、デジタル車両キーに関連する機能インターフェースをユーザに提供し、かつデジタル車両キーの有効化、更新、共有、廃止などのサービスプロセスを実行する必要があることが規定さている。したがって、前記ローカルアプリケーションモジュールを得るために上記関連する機能方法をカプセル化することができる。ローカルアプリケーションモジュールはＳＤＫの形で示すこともでき、かつ車両キーの有効化、更新、共有、廃止などの業務機能のインターフェースを提供する。

【0037】

図３を参照すると、１つの可能な実施形態では、前記通信装置は、前記パブリックプロトコルにおいて規定されたデジタルキーフレームワークの機能を実現するように構成されるデジタルキーフレームワークモジュールを備える。

【0038】

例えば、デジタル車両キーライフサイクルにおけるデジタル車両キーＴＡ（ＴｒｕｓｔｅｄＡｐｐｌｉｃａｔｉｏｎ、信頼可能なアプリケーション）に関連する操作をカプセル化することができ、これによって前記デジタルキーフレームワークモジュールを得る。デジタルキーフレームワークモジュールは、呼び出しのために車両キー管理サービスをＡＰＩの形でデジタルキーモジュールとローカルアプリケーションモジュールに提供することができ、これらの機能は、デバイスペアリング、キーライフサイクル管理、キーロック解除、キーロック、共有、車両制御などを含むが、これらに限定されない。デジタルキーフレームワークモジュールはされにキー管理モジュールとインタラクトすることができ、これにより、キー管理モジュールが、車両から送信された認証メッセージをタイムリーに受信し且つ応答することを容易にする。

【0039】

また、デジタルキーフレームワークモジュールは、車両とブルートゥース（登録商標）ペアリングを行って、ブルートゥース接続を確立するように構成されてもよく、ブルートゥースペアリングと接続の方式は、汎用方式であってもよいし、ユーザ設定された方式であってもよい。車両とのインタラクションにおいて、前記デジタルキーフレームワークモジュールはブルートゥース認証データパケットに対して解析とカプセル化を行うことができる。

【0040】

図３を参照すると、１つの可能な実施形態では、前記通信装置は、前記パブリックプロトコルにおいて規定されたデジタルキープログラムの機能を実現するように構成されるキー管理モジュールを備える。

【0041】

ここで、キー管理モジュールはＴＡモジュールを備えることができ、前記ＴＡモジュールは、セキュリティ記憶ユニットにより提供されるセキュリティ能力を呼び出すことができ、これによってキーデータを構築し且つ記憶することができる。ここで、図４に示す通信装置と暗号化ホワイトボックスのブロック図を参照し、関連技術ではセキュアエレメント（ＳｅｃｕｒｅＥｌｅｍｅｎｔ、ＳＥ）を介してキーデータを記憶することと異なり、本開示では、ＴＡモジュールは暗号化ホワイトボックスの方式でキーデータを記憶することができる。いくつかの実施のシーンでは、ＴＡモジュールは端末デバイスネイティブシステムのセキュリティ記憶技術でキーデータを記憶することができる。例えば、アンドロイドシステムでは、ｋｅｙ－ｓｔｏｒｅ（アンドロイド暗号鍵）技術によりキーデータを記憶することができる。

【0042】

また、デジタル車両キーのペアリング、ロック解除、ロック、共有、車両制御などのサービスプロセスにおいて、ＴＡモジュールはさらにデータに対して暗号化、復号化及びセキュリティ制御を行うことができる。いくつかの実施のシーンでは、ＴＡモジュールはさらにユーザの身分を検証するために使用することができる。

【0043】

いくつかの実施のシーンでは、ＴＡモジュールは、呼び出しインターフェースを有するように構成されてもよい。前記キー管理モジュールはＣＡ（ＣｌｉｅｎｔＡｐｐｌｉｃａｔｉｏｎ、クライアントアプリケーション）モジュールをさらに含んでもよい。前記ＣＡモジュールはＴＡモジュールのインターフェースを呼び出すことでＴＡに関連する機能を実行することができる。

【0044】

また、前記通信装置は、前記端末内のアプリケーションにカプセル化することができ、本開示では限定されない。

【0045】

前記通信装置に基づいて、端末デバイスは、ターゲット通信者との間において、前記パブリックプロトコルに基づく通信を行うことができる。

【0046】

例えば、１つの可能な実施形態では、前記パブリックプロトコルは証明書認証に基づくパブリックプロトコルであり、前記端末デバイスは、前記通信装置を介して車両サーバ、端末デバイスサーバ及び車両と通信して、デジタル車両キーの有効化ステップを完成させて、デジタル車両キーを得るために用いられる。

【0047】

図５に示すデジタル車両キーの有効化フローチャート及び図６に示すＩＣＣＯＡのデジタル車両キーのアーキテクチャ図を参照する。本開示では、通信装置有効化ＩＣＣＯＡプロトコルに基づくデジタル車両キーのフローは以下のステップを含む。

【0048】

ステップ５１１～ステップ５１３では、ユーザは端末デバイスの通信装置を介してキー有効化のフローを開始することができる。ここで、ユーザはペアリング情報を入力することができる。前記ペアリング情報は車両サーバにより生成することができ、前記通信装置におけるデジタルキーモジュールは、車両サーバから前記ペアリング情報を取得することができる。なお、前記車両サーバは初期ペアリングパラメータを車両側に送信することができる。

【0049】

ステップ５２において、車両側は端末デバイスのＤＫＦモジュールとインタラクトし、かつＳＰＡＫＥ２＋アルゴリズム及び端末デバイスに基づいて双方向認証を行って、ＳＰＡＫＥ２＋セキュリティチャネルを確立することができる。ここで、車両が車両所有者の端末デバイスにバインドされている場合、キー有効化のフローを終了し、車両が車両所有者の端末デバイスにバインドされていない場合、ＳＰＡＫＥ２＋セキュリティチャネルに基づいて、後続のフローを続ける。

【0050】

車両（又は端末デバイス）はさらに、現在状態がキー有効化の条件を満たしているか否かを検査することができ、前記条件は適用のニーズに応じて設定することができる。ステップ５３において、キー有効化の条件を満たしている場合、車両は車両公開鍵証明書［Ｆ］を端末デバイスに伝送し、車両公開鍵証明書［Ｆ］は車両公開鍵及び車両サーバＣＡ署名を含む。

【0051】

ステップ５４１～５４３において、端末デバイスのキー管理モジュールは車両サーバＣＡ証明書［Ｃ］を用いて車両公開鍵証明書［Ｆ］を検証することができ、車両サーバＣＡ証明書［Ｃ］は車両サーバＣＡ公開鍵及び信頼可能なＣＡ署名を含む。検証成功後に、端末デバイスは車両公開鍵証明書［Ｆ］を保存することができる。例えば、端末デバイスは前記車両公開鍵証明書を暗号化ホワイトボックスに保存することができる。また、端末デバイスはデジタル車両キー公開・秘密鍵ペア［Ｋ］を生成することができ、デジタル車両キー公開・秘密鍵ペア［Ｋ］はデジタル車両キー公開鍵及びデジタル車両キー秘密鍵を含むことができる。端末デバイスはさらにキー管理モジュールの証明書［Ｈ］を介してデジタル車両キー公開鍵に署名して、デジタル車両キー公開鍵証明書［Ｌ］を生成することができる。ここで、キー管理モジュールの証明書［Ｈ］はキー管理モジュールのＣＡ公開鍵及びキー管理モジュールのＣＡ秘密鍵を含み、デジタル車両キー公開鍵証明書［Ｌ］はデジタル車両キー公開鍵及びキー管理モジュールのＣＡ署名を含む。

【0052】

ステップ５５において、端末デバイスは、端末デバイスサーバＣＡ証明書［Ｄ］、キー管理モジュールの証明書［Ｊ］及びデジタル車両キー公開鍵証明書［Ｌ］を順次車両に伝送する。ここで、端末デバイスサーバＣＡ証明書［Ｄ］は端末デバイスサーバＣＡ公開鍵及び車両サーバＣＡ署名を含む。キー管理モジュールの証明書［Ｊ］はキー管理モジュールのＣＡ公開鍵及び端末デバイスサーバＣＡ署名を含む。

【0053】

ステップ５６において、車両は、端末デバイスから伝送されてきた証明書チェーンを順次検証する。ここで、車両は車両サーバＣＡ証明書［Ｇ］を介して端末デバイスサーバＣＡ証明書［Ｄ］を検証することができ、車両サーバＣＡ証明書［Ｇ］は車両サーバＣＡ公開鍵及び信頼可能なＣＡ署名を含む。車両は端末デバイスサーバＣＡ証明書［Ｄ］によりキー管理モジュールの証明書［Ｊ］を検証することもでき、端末デバイスサーバＣＡ証明書［Ｄ］は端末デバイスサーバＣＡ公開鍵及び車両サーバＣＡ署名を含む。車両はキー管理モジュールの証明書［Ｊ］によりデジタル車両キー公開鍵証明書［Ｌ］を検証することができる。

【0054】

検証に成功した場合、車両はデジタル車両キー公開鍵及び対応するデジタル車両キー情報を保存することができる。このように、端末デバイスは車両公開鍵を検証し且つ保存し、車両はデジタル車両キー公開鍵を検証し且つ保存し、これによって車両所有者のキーペアリング段階の暗号鍵の生成と検証のステップを完成させる。この時、端末デバイスと車両とのペアリングに成功する。

【0055】

ステップ５７において、車両は送信状態を端末デバイスに指示し、車両のデジタル車両キーのペアリング状態を指示する。

【0056】

ステップ５８１～５８３において、車両は車両のデジタル車両キーの有効化状態を車両サーバに同期し、端末デバイスは端末デバイスのデジタル車両キーの有効化状態を端末デバイスサーバに伝送する。端末デバイスサーバはデジタル車両キーの有効化状態を車両サーバに同期する。

【0057】

ステップ５９において、車両サーバはキー有効化メッセージを送信して車両所有者に通知する。

【0058】

ステップ５１０において、端末デバイスと車両との間に第１回の標準認証を行い、且つ標準認証セキュリティチャネルを確立する。

【0059】

ステップ５１１において、デジタル車両キーサービスデータを設定する必要がある場合、車両は、デジタル車両キーサービスデータを保存する要求を端末デバイスに送信する。

【0060】

上記技術案を用いると、ネイティブシステムがＩＣＣＯＡプロトコルをサポートしない端末デバイスに対して、前記通信装置に基づいて、ＩＣＣＯＡプロトコルに基づくデジタル車両キーの運用を開始することができ、ひいてはＩＣＣＯＡプロトコルの適用範囲を拡大する。

【0061】

１つの可能な実施形態において、前記パブリックプロトコルは証明書認証に基づくパブリックプロトコルであり、前記ターゲット通信者は車両サーバ及び端末デバイスサーバを含み、前記端末デバイスは、キー共有要求を受信したことに応答して、前記デジタルキーモジュールを介して前記車両サーバと通信し、前記ローカルアプリケーションモジュールを介して前記端末デバイスサーバと通信することで、キー共有の認証ステップを完了し、共有されたデジタル車両キーを得るために用いられる。無論、いくつかの実施のシーンでは、前記端末デバイスはキー共有の開始側（すなわち、車両所有者の端末デバイス）としてもよく、もう１つの端末デバイスにデジタル車両キーを共有する。

【0062】

以下、デジタル車両キーを共有するフローを例示的に説明する。

【0063】

図７は本開示に示すキー共有のフローチャートであり、図７を参照すると、キー共有のフローは以下のステップを含む。

【0064】

ステップ７１において、ユーザは、有効期限や権限など、フレンドキー共有情報を設定することができる。ここで、前記車両所有者の端末デバイスのネイティブシステムがＩＣＣＯＡプロトコルをサポートする場合、ユーザは前記車両所有者の端末デバイスの端末デバイスメーカアプリケーションにおいて前記フレンドキー共有情報を設定することができ、前記端末デバイスメーカアプリケーションは、例えばウォレットアプリケーションであってもよい。前記車両所有者の端末デバイスのネイティブシステムがＩＣＣＯＡプロトコルをサポートしない場合、ユーザは前記通信装置を介して前記フレンドキー共有情報を設定することができる。

【0065】

ステップ７２において、車両所有者の端末デバイスは、車両所有者のデジタル車両キー秘密鍵を用いて前記フレンドキー共有情報に署名して、フレンドキー共有要求を生成する。

【0066】

ステップ７３において、車両所有者の端末デバイスはフレンドキー共有要求を車両所有者の端末デバイスサーバに送信し、車両所有者の端末デバイスサーバはこの共有要求を車両サーバに転送する。

【0067】

ステップ７４において、車両サーバは共有要求を受信し、車両所有者のデジタル車両キー公開鍵を用いて共有情報の署名を検証する。

【0068】

ステップ７５において、車両サーバは、共有情報の署名を検証することに成功した後、共有リンクＳｅｓｓｉｏｎＩＤを生成し、ＳｅｓｓｉｏｎＩＤは乱数発生器によりランダムに生成することができるので、漸増予測リスクを回避する。

【0069】

ステップ７６において、車両サーバは共有リンクＳｅｓｓｉｏｎＩＤを車両所有者の端末デバイスサーバに送信し、車両所有者の端末デバイスサーバは共有リンクＳｅｓｓｉｏｎＩＤを車両所有者の端末デバイスに転送する。

【0070】

ステップ７７において、車両所有者の端末デバイスは共有リンクＳｅｓｓｉｏｎＩＤを受信した後、ＳｅｓｓｉｏｎＩＤを含む共有リンクを生成し、車両所有者によりフレンドに共有する。

【0071】

ステップ７８において、フレンドはフレンド端末デバイスを介して共有リンクを開くことができる。前記フレンド端末デバイスのネイティブシステムがＩＣＣＯＡプロトコルをサポートする場合、フレンド端末デバイスは端末デバイスメーカアプリケーションにジャンプし、ＳｅｓｓｉｏｎＩＤに基づいてフレンド端末デバイスサーバからフレンドキー共有情報を取得する。ここで、フレンド端末デバイスサーバは車両サーバからフレンドキー共有情報を取得することができる。また、前記フレンド端末デバイスのネイティブシステムがＩＣＣＯＡプロトコルをサポートしない場合、フレンド端末デバイスは共有リンクを開く時、デジタルキーモジュールによりＳｅｓｓｉｏｎＩＤに基づいてフレンド端末デバイスサーバからフレンドキー共有情報を取得することができる。

【0072】

ステップ７９において、車両サーバはフレンドキー共有情報をフレンド端末デバイスサーバに伝送し、フレンド端末サーバはフレンドキー共有情報をフレンド端末デバイスに転送する。

【0073】

ステップ７１０において、フレンド端末デバイスは、フレンドキー共有に関連する情報を提示し、ユーザにより確認された後に続ける。ここで、現在のフレンド端末デバイスには、対応する車両キーがすでに存在する場合、キー共有のフローを終了し且つ対応する情報を提示する。

【0074】

ステップ７１１において、フレンド端末デバイスはフレンドデジタル車両キー公開・秘密鍵ペアを生成する。

【0075】

ステップ７１２において、前記フレンド端末デバイスのネイティブシステムがＩＣＣＯＡプロトコルをサポートする場合、フレンド端末デバイスは、信頼可能な実行環境ＣＡに基づいて、すでに生成されたフレンドデジタル車両キー公開鍵に署名して、フレンドデジタル車両キー公開鍵証明書を生成することができる。前記フレンド端末デバイスのネイティブシステムがＩＣＣＯＡプロトコルをサポートする場合、フレンド端末デバイスは、通信装置内のキー管理モジュールに基づいて、すでに生成されたフレンドデジタル車両キー公開鍵に署名して、フレンドデジタル車両キー公開鍵証明書を生成することができる。

【0076】

ステップ７１３において、フレンド端末デバイスはフレンド端末デバイスサーバに伝送要求を開始することができ、伝送内容は、フレンドデジタル車両キー公開鍵証明書、フレンド端末デバイスＴＥＥＣＡ証明書（フレンド端末デバイスのネイティブシステムがＩＣＣＯＡプロトコルをサポートしない場合はキー管理モジュールＣＡ証明書であり、キー管理モジュールＣＡ証明書は、フレンド端末サーバＣＡ秘密鍵がキー管理モジュールＣＡ公開鍵に署名することで得られるものである）、およびフレンド端末デバイスサーバＣＡ証明書がある。フレンド端末デバイスサーバは伝送内容を車両サーバに転送し、車両サーバはさらに車両所有者の端末デバイスサーバに転送する。その後、車両所有者の端末デバイスサーバはさらに前記伝送内容を車両所有者の端末デバイスに転送する。

【0077】

ステップ７１４において、車両所有者の端末デバイスは以上の伝送内容を受信した後、車両所有者の端末デバイスに記憶される車両サーバＣＡ証明書を用いてフレンド端末デバイスサーバＣＡ証明書を検証してから、フレンド端末デバイスサーバＣＡ証明書を用いてフレンド端末デバイスＴＥＥＣＡ証明書を検証し、最後に、フレンド端末デバイスＴＥＥＣＡ証明書を用いてフレンドデジタル車両キー公開鍵証明書を検証することができる。

【0078】

又は、伝送内容がフレンドデジタル車両キー公開鍵証明書、キー管理モジュールＣＡ証明書及びフレンド端末デバイスサーバＣＡ証明書を含む場合、車両所有者の端末デバイスは車両サーバＣＡ証明書を用いてフレンド端末デバイスサーバＣＡ証明書を検証してから、フレンド端末デバイスサーバＣＡ証明書を用いてキー管理モジュールＣＡ証明書を検証し、最後にキー管理モジュールＣＡ証明書を用いてフレンドデジタル車両キー公開鍵証明書を検証する。

【0079】

ステップ７１５において、車両所有者の端末デバイスは、以上の証明書チェーンの検証に成功したことを確認した場合、フレンドデジタル車両キー公開鍵を得る。このように、車両所有者の端末デバイスは車両所有者のデジタル車両キー秘密鍵を用いてフレンドキー共有情報とフレンドデジタル車両キー公開鍵に署名して、フレンドキー認証情報を生成することができる。

【0080】

ステップ７１６において、車両所有者の端末デバイスは車両所有者の端末デバイスサーバに伝送要求を送信し、伝送内容はフレンドキー認証情報と車両公開鍵証明書を含むことができる。車両所有者の端末デバイスサーバは伝送内容を車両サーバに転送し、車両サーバはさらに伝送内容をフレンド端末デバイスサーバに転送し、フレンド端末デバイスサーバによりさらに伝送内容をフレンド端末デバイスに転送する。

【0081】

ステップ７１７において、フレンド端末デバイスはフレンドキー認証情報と車両公開鍵証明書を受信した後、フレンドキー認証情報と車両公開鍵証明書を保存する。ここで、フレンドキー認証情報は、フレンドキーと車両の第１回の標準認証に用いられ、取引完成後に削除される。このような方式により、フレンドキー有効化は完成する。

【0082】

前記フレンド端末デバイスはさらにフレンドキー状態をフレンド端末デバイスサーバに同期することができ、フレンド端末デバイスサーバにより車両サーバに同期し、前記車両サーバはさらにフレンドキー状態を車両所有者の端末デバイスサーバに同期する。その後、車両所有者の端末デバイスサーバにより車両所有者の端末デバイスに同期する。

【0083】

ステップ７１８において、車両サーバはフレンドキーの状態変化を記録しかつ追跡し、ショートメッセージの形で車両所有者とフレンドに通知する。

【0084】

上記技術案を用いると、ネイティブシステムがＩＣＣＯＡプロトコルをサポートしない端末デバイスに対して、前記通信装置に基づいてデジタル車両キー共有のフローを実行することもでき、したがってＩＣＣＯＡプロトコルの適用範囲を拡大する。

【0085】

１つの可能な実施形態において、前記ターゲット通信者は車両を含み、前記端末デバイスは、前記通信装置を介して、前記パブリックプロトコルに基づく通信を前記車両と行うことで、セキュリティチャネルを確立し、且つ前記セキュリティチャネルを介して、前記車両を制御してターゲット動作を実行させるためのターゲット制御命令を前記車両に送信するために用いられる。

【0086】

例えば、デジタル車両キー有効化後、端末デバイスは前記デジタル車両キーを使用することができる。前記デジタル車両キーを使用する時、端末デバイスは前記通信装置に基づいて車両を認証することができる。

【0087】

ここで、認証プロセスは標準認証を含んでもよいし、快速認証を含んでもよい。標準認証において、車両は、事前に記憶されているデジタル車両キー公開鍵を用いて移動端末のデジタル車両キーの合法性を検証する。快速認証において、車両は前回の標準認証において生成され且つ記憶された快速認証暗号鍵を用いて移動端末デジタル車両キーの合法性を検証する。

【0088】

図８は本開示に示す移動端末と車両の標準認証のフローチャートであり、図８を参照すると、標準認証のプロセスは以下のステップを含む。

【0089】

ステップ８１において、車両は車両一時的公開・秘密鍵ペアを生成する。

【0090】

ステップ８２において、車両は移動端末に公開鍵交換要求を送信し、一時的車両公開鍵と車両ＩＤ（Ｖｅｈｉｃｌｅ＿ＩＤ）を伝送し、車両Ｖｅｈｉｃｌｅ＿ＩＤの生成ルールはＩＣＣＯＡプロトコルを参照されたい。

【0091】

ステップ８３において、移動端末はデジタル車両キー一時的公開・秘密鍵ペアを生成する。例えば、移動端末はキー管理モジュールにより一時的公開・秘密鍵ペアを生成することができる。

【0092】

ステップ８４において、移動端末は車両に公開鍵交換要求応答を送信し、デジタル車両キー一時的公開鍵とデジタル車両キーＩＤ（ＫｅｙＩＤ）を返し、デジタル車両キーＫｅｙＩＤの生成ルールはＩＣＣＯＡプロトコルを参照されたい。

【0093】

ステップ８５において、車両は車両認証情報を生成し、車両認証情報はデジタル車両キー一時的公開鍵、車両一時的公開鍵、およびデジタル車両キーＩＤの関連情報を含む。前記車両はさらに車両秘密鍵を用いて車両認証情報に署名することができる。

【0094】

ステップ８６において、車両は標準認証要求を移動端末に送信して、移動端末に車両認証情報署名を伝送する。

【0095】

ステップ８７において、移動端末は車両公開鍵を用いて署名を検証し、車両公開鍵証明書はキー有効化フローにより移動端末に送信される。このように、移動端末は車両公開鍵により前記車両の署名を検証することができ、これによって車両の身分を検証し、したがって偽物である車両が移動端末情報を取得することを回避することができる。

【0096】

ステップ８８において、車両認証情報署名が検証にパスした場合、移動端末はデジタル車両キー認証情報を生成し、デジタル車両キー認証情報は、デジタル車両キー一時的公開鍵、車両一時的公開鍵、および車両ＩＤ関連情報を含むことができる。その後、移動端末はデジタル車両キー秘密鍵を用いて前記デジタル車両キー認証情報に署名することができる。

【0097】

ステップ８９１とステップ８９２において、移動端末は、合意した対称暗号鍵に基づいて、ＫＤＦアルゴリズムを用いてセキュリティチャネル暗号鍵と快速認証暗号鍵を生成することができ、車両側は同じ暗号鍵合意アルゴリズムとＫＤＦアルゴリズムを用いてセキュリティチャネル暗号鍵と快速認証暗号鍵を生成する。同じセキュリティチャネル暗号鍵に基づいて、両方はセキュリティチャネルを確立する。

【0098】

ステップ８１０において、確立されたセキュリティチャネルに基づいて、移動端末は標準認証要求応答を車両に送信し、車両にデジタル車両キー認証情報署名を送信する。

【0099】

ステップ８１１において、移動端末から送信されたデジタル車両キーＩＤに基づいて、車両内部でデジタル車両キーＩＤを照会することで、対応するデジタル車両キー公開鍵を取得する。デジタル車両キー公開鍵を見つけた場合はステップ８１５を実行する。車両は、デジタル車両キーＩＤ及び対応するデジタル車両キー公開鍵を見つけることができない場合、確立されたセキュリティチャネルに基づいてステップ８１２～ステップ８１４を実行し、車両はステップ８１２～ステップ８１４によりフレンドキーのデジタル車両キー公開鍵を取得する。

【0100】

ここで、ステップ８１２において、車両向移動端末はデジタル車両キーデータ要求に送信し、前記デジタル車両キーデータ要求はフレンドキー認証情報を取得するために用いられる。

【0101】

ステップ８１３において、移動端末は車両にデジタル車両キーデータ要求応答を送信し、フレンドキー認証情報を返す。

【0102】

ステップ８１４において、車両はセキュリティチャネル暗号鍵を用いてフレンドキー認証情報を復号化した後、車両所有者デジタル車両キー公開鍵を用いてフレンドキー認証情報の署名を検証する。検証に成功した場合、フレンドキー認証情報内のフレンドデジタル車両キー公開鍵を保存する。

【0103】

ステップ８１５において、車両はデジタル車両キーＩＤに対応するデジタル車両キー公開鍵を用いて、移動端末から送信されたデジタル車両キー認証情報署名を検証する。検証に成功した場合、標準認証に成功する。標準認証にパスした後、車両と移動端末は、今回生成された快速認証暗号鍵を後続の快速認証のために同期して保存する。例えば、移動端末は前記快速認証暗号鍵を暗号化ホワイトボックスモジュールに保存することができる。

【0104】

ステップ８１６において、認証に成功した後、車両は移動端末に状態状況報告を送信し、車両の認証状態を移動端末に通知する。いくつかの実施のシーンでは、状態状況報告を送信する前に、車両は、確立されたセキュリティチャネルに基づいて、移動端末のサービスデータに対する読み書き操作を実行することができる。

【0105】

標準認証の後、移動端末は、確立されたセキュリティチャネルに基づいて命令伝送を行うことができ、これによって車両を制御する。

【0106】

上記実施例において、キーの有効化、キーの共有、およびキーの使用を例として、本開示の移動端末がパブリックプロトコル通信を行う方式を例示的に説明した。しかし、当業者であれば分かるように、本開示により提供される移動端末は、前記通信装置に基づいて、パブリックプロトコルに基づく様々な通信を実行して、さらに対応する機能を実現することができる。これらの機能は、キーの有効化、キーの共有、キーの使用、キーの廃止などを含むが、これらに限定されない。

【0107】

また、上記実施例において、ＩＣＣＯＡプロトコルを例として、本開示により提供される移動端末の実施形態を例示的に説明したが、他の実施シーンにおいて、前記パブリックプロトコルはＣＣＣプロトコル、ＩＣＣＥプロトコルなどであってもよい。

【0108】

例えば、ＩＣＣＥプロトコルにおいて、前記通信装置におけるデジタルキーモジュールは、車両サーバと通信可能であり、前記パブリックプロトコルにおいて規定された車両メーカアプリケーションの機能を実現するように構成される。これらの機能は、キーの管理や照会のためのユーザインターフェースを提供すること、キーと車両サーバのための対話チャネルを提供すること、有効化、更新、共有、廃止などのサービスフローを実行すること、キー有効化段階において車両ブルートゥース／ＵＷＢ（ＵｌｔｒａＷｉｄｅＢａｎｄ、超広帯域）にペアリング接続すること、ＤＫＦにより提供されるＡＰＩを介してキー管理モジュールに命令を送信することなどを含むことができる。そのため、上記機能方法をカプセル化して、前記デジタルキーモジュールを得ることができる。デジタルキーモジュールは、ＳＤＫの形で表し、かつ上記機能のインターフェースを提供することもできる。

【0109】

前記通信装置のローカルアプリケーションモジュールは、端末デバイスサーバと通信可能であり、前記パブリックプロトコルにおいて規定された端末デバイスメーカアプリケーションの機能を実現するように構成される。これらの機能は、デジタル車両キーの関連機能ユーザインターフェースを提供すること、車両サーバとインタラクトすること、有効化、更新、共有、廃止などのサービスフローを実行すること、キーライフサイクル状態変化を完成させる操作を実行した後に、自動車メーカサーバとの状態同期をトリガーすることなどを含むことができる。そのため、上記関連する機能方法をカプセル化して、前記ローカルアプリケーションモジュールを得ることができる。ローカルアプリケーションモジュールはＳＤＫの形で表し、かつ上記機能のインターフェースを提供することもできる。

【0110】

前記通信装置のデジタルキーフレームワークモジュールは、前記パブリックプロトコルにおいて規定されたデジタルキーフレームワークの機能を実現するように構成される。これらの機能は、デバイスペアリング、車両キーの配信と管理を含む。デジタルキーフレームワークモジュールは、キー管理モジュールが車両から送信された認証メッセージをタイムリーに受信しかつ応答することを容易にするように、デジタル車両キープログラムとインタラクトすることもできる。デジタルキーフレームワークモジュールはさらにキー管理モジュールのＡＰに対してアクセス制御を行い、かつアクセス制御のルールを維持することができる。

【0111】

前記キー管理モジュールは、前記パブリックプロトコルにおいて規定されたデジタルキープログラムの機能を実現するように構成される。例えば、前記キー管理モジュールは、前記暗号化ホワイトボックスに基づくセキュリティ取引機能を提供することができる。また、複数の車両キーの要求を満たすために、前記キー管理モジュールの実例は統一されたＡＩＤ（ａｐｐｌｉｃａｔｉｏｎｉｄｅｎｔｉｆｉｅｒ、アプリケーション識別子）を用いることができ、かつ異なるメーカキーデータが分離することを確保し、不正なクエリ要求を回避する。

【0112】

前記通信装置に基づいて、端末デバイスはターゲット通信者との間でＩＣＣＥプロトコルに基づく通信を行うことができ、その通信方式はＩＣＣＥプロトコルを参照されたく、明細書の簡潔さのために、本開示では詳しい説明を省略する。同様に、前記通信装置は、ＣＣＣプロトコルに規定された端末デバイスの機能を実現するために使用されてもよく、前記通信装置は、前記端末デバイスとターゲット通信者との間のＣＣＣプロトコルに基づく通信を確立するように構成され、本開示では詳しい説明を省略する。

【0113】

同じ発明の構想に基づいて、本開示は、本開示により提供される端末デバイスに適用される端末デバイスのデータ処理方法をさらに提供する。図９は、本開示に示す端末デバイスのデータ処理方法のフローチャートであり、図９を参照すると、前記方法は以下のステップを含む。

【0114】

ステップＳ９１において、端末デバイスのネイティブシステムがデジタル車両キーのパブリックプロトコルに適合するコンポーネントを含むか否かを検出する。

【0115】

ステップＳ９２において、ネイティブシステムが少なくとも１つのコンポーネントを欠落している場合、パブリックプロトコルに基づく通信をターゲット通信者と行い、ターゲット通信者はパブリックプロトコルの参加者である。

【0116】

例えば、１つの可能な実施形態において、パブリックプロトコルは証明書認証に基づくパブリックプロトコルであり、前記ターゲット通信者は車両サーバ及び端末デバイスサーバを含み、パブリックプロトコルに基づく通信をターゲット通信者と行うステップは、前記通信装置を介して車両サーバ、端末デバイスサーバ及び車両と通信することで、前記パブリックプロトコルに規定されたデジタル車両キーの有効化ステップを完成させて、デジタル車両キーを得るステップを含む。

【0117】

図５及び図６を参照すると、本開示では、通信装置に基づいてＩＣＣＯＡプロトコルのデジタル車両キーの運用を開始するフローは以下のステップを含む。

【0118】

ステップ５１１～ステップ５１３において、ユーザは端末デバイスの通信装置を介してキー有効化のフローを開始することができる。ここで、ユーザはペアリング情報を入力することができる。前記ペアリング情報は車両サーバによって生成することができ、前記通信装置におけるデジタルキーモジュールは、車両サーバから前記ペアリング情報を取得することができる。なお、前記車両サーバは初期ペアリングパラメータを車両側に送信することができる。

【0119】

ステップ５２において、車両側は端末デバイスのＤＫＦモジュールとインタラクトし、かつＳＰＡＫＥ２＋アルゴリズム及び端末デバイスに基づいて双方向認証を行うことができ、これによってＳＰＡＫＥ２＋セキュリティチャネルを確立する。ここで、車両がすでに車両所有者の端末デバイスにバインドされている場合、キー有効化のフローを終了し、車両が車両所有者の端末デバイスにバインドされていない場合、ＳＰＡＫＥ２＋セキュリティチャネルに基づいて、後続のフローを続ける。

【0120】

車両（又は端末デバイス）はさらに、現在状態がキー有効化の条件を満たしているか否かを検査することができ、前記条件は適用のニーズに応じて設定することができる。ステップ５３において、キー有効化条件を満たしている場合、車両は車両公開鍵証明書［Ｆ］を端末デバイスに伝送し、車両公開鍵証明書［Ｆ］は車両公開鍵及び車両サーバＣＡ署名を含む。

【0121】

ステップ５４１～５４３において、端末デバイスのキー管理モジュールは、車両サーバＣＡ証明書［Ｃ］を用いて車両公開鍵証明書［Ｆ］を検証することができ、車両サーバＣＡ証明書［Ｃ］は車両サーバＣＡ公開鍵及び信頼可能なＣＡ署名を含む。検証に成功した後、端末デバイスは車両公開鍵証明書［Ｆ］を保存することができる。例えば。端末デバイスは、前記車両公開鍵証明書を暗号化ホワイトボックスに保存することができる。また、端末デバイスはデジタル車両キー公開・秘密鍵ペア［Ｋ］を生成することができ、デジタル車両キー公開・秘密鍵ペア［Ｋ］はデジタル車両キー公開鍵及びデジタル車両キー秘密鍵を含む。端末デバイスはさらにキー管理モジュールの証明書［Ｈ］によりデジタル車両キー公開鍵に署名してデジタル車両キー公開鍵証明書［Ｌ］を生成することができる。ここで、キー管理モジュールの証明書［Ｈ］はキー管理モジュールのＣＡ公開鍵及びキー管理モジュールのＣＡ秘密鍵を含み、デジタル車両キー公開鍵証明書［Ｌ］はデジタル車両キー公開鍵及びキー管理モジュールのＣＡ署名を含む。

【0122】

ステップ５５において、端末デバイスは端末デバイスサーバＣＡ証明書［Ｄ］、キー管理モジュールの証明書［Ｊ］及びデジタル車両キー公開鍵証明書［Ｌ］を車両に順次伝送する。ここで、端末デバイスサーバＣＡ証明書［Ｄ］は端末デバイスサーバＣＡ公開鍵及び車両サーバＣＡ署名を含む。キー管理モジュールの証明書［Ｊ］はキー管理モジュールのＣＡ公開鍵及び端末デバイスサーバＣＡ署名を含む。

【0123】

【0124】

【0125】

ステップ５７において、車両は送信状態を端末デバイスに指示し、車両のデジタル車両キーのペアリング状態を指示する。

【0126】

【0127】

ステップ５９において、車両サーバはキー有効化メッセージを送信して車両所有者に通知する。

【0128】

ステップ５１０において、端末デバイスと車両との間に第１回の標準認証を行い、且つ標準認証セキュリティチャネルを確立する。

【0129】

【0130】

【0131】

１つの可能な実施形態において、前記パブリックプロトコルは証明書認証に基づくパブリックプロトコルであり、前記ターゲット通信者は車両サーバ及び端末デバイスサーバを含み、キー共有要求を受信したことに応答して、通信装置内のデジタルキーモジュールを介して前記車両サーバと通信し、前記通信装置内のローカルアプリケーションモジュールを介して前記端末デバイスサーバと通信することで、キー共有の認証ステップを完了し、共有されたデジタル車両キーを得るステップを含む。

【0132】

図７を参照すると、キー共有のフローは以下のステップを含む。

【0133】

【0134】

【0135】

【0136】

ステップ７４において、車両サーバは共有要求を受信し、車両所有者のデジタル車両キー公開鍵を用いて共有情報の署名を検証する。

【0137】

ステップ７５において、車両サーバは、共有情報の署名を検証することに成功した後、共有リンクＳｅｓｓｉｏｎＩＤを生成し、ＳｅｓｓｉｏｎＩＤは乱数発生器により生成することができるので、逓増予測リスクを回避する。

【0138】

【0139】

【0140】

【0141】

【0142】

【0143】

ステップ７１１において、フレンド端末デバイスはフレンドデジタル車両キー公開・秘密鍵ペアを生成する。

【0144】

【0145】

【0146】

【0147】

【0148】

【0149】

【0150】

【0151】

【0152】

【0153】

【0154】

１つの可能な実施形態において、前記ターゲット通信者は車両を含み、前記パブリックプロトコルに基づく通信をターゲット通信者と行うステップは、前記通信装置を介して、前記パブリックプロトコルに基づく通信を前記車両と行うことで、セキュリティチャネルを確立するステップと、前記セキュリティチャネルを介して、前記車両を制御してターゲット動作を実行させるためのターゲット制御命令を前記車両に送信するステップと、を含む。

【0155】

図８は本開示に示す移動端末と車両の標準認証のフローチャートであり、図８を参照すると、標準認証フローは以下のステップを含むことができる。

【0156】

ステップ８１において、車両は車両一時的公開・秘密鍵ペアを生成する。

【0157】

【0158】

【0159】

【0160】

【0161】

ステップ８６において、車両は標準認証要求を移動端末に送信して、移動端末に車両認証情報署名を伝送する。

【0162】

ステップ８７において、移動端末は車両公開鍵を用いて署名を検証し、車両公開鍵証明書はキー有効化フローにより移動端末に送信される。このように、移動端末は車両公開鍵により前記車両の署名を検証することができ、これによって車両の身分を検証し、したがって偽物の車両が移動端末情報を取得することを回避することができる。

【0163】

【0164】

ステップ８９１とステップ８９２において、移動端末は、合意した対称暗号鍵に基づいて、ＫＤＦアルゴリズムを用いてセキュリティチャネル暗号鍵と快速認証暗号鍵を生成することができ、車両側は同じ暗号鍵合意アルゴリズムとＫＤＦアルゴリズムを用いてセキュリティチャネル暗号鍵と快速認証暗号鍵を生成する。同じセキュリティチャネル暗号鍵に基づいて、双方はセキュリティチャネルを確立する。

【0165】

【0166】

【0167】

【0168】

ステップ８１３において、移動端末は車両にデジタル車両キーデータ要求応答を送信し、フレンドキー認証情報を返す。

【0169】

【0170】

【0171】

【0172】

標準認証の後、移動端末は、確立されたセキュリティチャネルに基づいて命令伝送を行うことができ、これによって車両を制御する。

【0173】

上記技術案において、端末デバイス内に通信装置が設置され、前記通信装置は、前記端末デバイスのネイティブシステムがデジタル車両キーのパブリックプロトコルに適合するためのコンポーネントを含むか否かを検出することができる。前記ネイティブシステムが少なくとも１つの前記コンポーネントを欠落している場合、前記パブリックプロトコルに基づく通信を、前記パブリックプロトコルの参加者であるターゲット通信者と行う。

【0174】

【0175】

もう１つの例示的な実施例において、コンピュータプログラム製品をさらに提供し、当該コンピュータプログラム製品は、プログラマブルデバイスにより実行可能なコンピュータプログラムを含み、当該コンピュータプログラムは、当該プログラマブルデバイスにより実行される際に上記端末デバイスのデータ処理方法を実行するためのコード部分を有する。

【0176】

当業者は明細書を考慮し且つ本開示を実践した後に、本開示の他の実施形態を容易に想到し得る。本願は、本開示のあらゆる変形、用途又は適応的な変化をカバーしようとしており、これらの変形、用途又は適応的な変化は、本開示の一般的な原理に従い、かつ本開示の開示されていない本技術分野の技術常識または慣用されている技術手段を含む。明細書と実施例は例示的なもののみとして見なされ、本開示の真の範囲と精神は以下の特許請求の範囲によって指示される。

【0177】

なお、本開示は上記説明され且つ図面に示されている正確な構造に限定されず、その範囲から逸脱しない限り、様々な修正と変更を行うことができることを理解されたい。本開示の範囲は、添付の特許請求の範囲のみによって限定される。

【図1】