JP2017024715A - マルチファクタセキュリティのためのモバイルデバイス及びキーフォブペアリング - Google Patents

Abstract

【課題】 複数のファクタを使用して車両へのアクセスを制御すること。【解決手段】 車両に対する第１のモバイルデバイスの第１の近接性ステータスを決定し、車両に対する第２のモバイルデバイスの第２の近接性ステータスを決定するシステム及び方法を提供する。さらに、車両の１つ又は複数の機能のアクセス性が、第１の近接性ステータス及び第２の近接性ステータスに少なくとも部分的に基づいて構成され得る。一例において、第１のモバイルデバイス及び第２のモバイルデバイスの１つ又は複数に関連付けられるポリシーを識別することができ、アクセス性は、このポリシーに更に基づいて構成される。【選択図】図１

Description

実施形態は、一般にセキュリティシステムに関する。より具体的には、実施形態は、複数のファクタを使用して車両へのアクセスを制御することに関する。

車両エントリシステムは、車両にアクセス及び／又は車両を始動させるのに使用され得る、近接性ベースのキーレスのリモコン（例えばキーフォブ（key fob））を含むことがある。これらの解決策は、特定の状況下では適切であるが、改善の余地がかなり残っている。

例えば車両の未許可のアクセス及び／又は操作は、単にキーフォブの所有を獲得することによって達成されることがあり得る。この場合、キーフォブの所有は、車両に対する唯一のユーザ認証のファクタであり得る。さらに、キーフォブを紛失するか盗まれた場合、新たなキーフォブを注文する必要があるが、これは、非常にコストが係り、遅延を生じ、また所有者にとって不便なことである。スマートフォンのアプリケーションにより車両のリモートコントロールを可能にするものもあるが、これらのアプリケーションは、その電話を車両に対するユーザ認証のファクタとして確立するのに、ログイン認証情報の使用に限定されることがあり、この場合、ログイン認証情報は容易に危険にさらされる可能性がある。さらに、スマートフォンベースの解決策は、電話と車両との間の媒介（例えばサービスプロバイダ）の使用を要することがある。

車両に対する第１のモバイルデバイスの第１の近接性ステータスを決定し、車両に対する第２のモバイルデバイスの第２の近接性ステータスを決定するシステム及び方法が提供され得る。加えて、車両の１つ又は複数の機能のアクセス性が、第１の近接性ステータス及び第２の近接性ステータスに少なくとも部分的に基づいて構成され得る。

本発明の実施形態の様々な利点は、以下の仕様及び添付の特許請求の範囲を読み、以下の図面を参照することによって、当業者に明らかになるであろう。
一実施形態に係る認証環境の例を示すブロック図である。 諸実施形態に係るファクタ置換シナリオの例を示すブロック図である。 諸実施形態に係るファクタ置換シナリオの例を示すブロック図である。 一実施形態に係る論理アーキテクチャの例を示すブロック図である。 一実施形態に係る一組のユーザプロファイルの例を示すブロック図である。 一実施形態に係るマルチファクタ認証環境を管理する方法の例を示すフローチャートである。 一実施形態に係るプロセッサの例を示すブロック図である。 一実施形態に係るシステムの例を示すブロック図である。

次に図１に移ると、認証環境１０が示されている。認証環境１０では、車両１４に対するアクセス及び制御が、車両１４とペアリングされる複数のモバイルデバイス１６、１８に関連して管理される。図示される例では、第１のモバイルデバイス１６がキーフォブ（例えばワイヤレスのハードウェアセキュリティトークン）であり、第２のモバイルデバイス１８はスマートフォンである。モバイルデバイス１６、１８は、スマートタブレット、パーソナルデジタルアシスタント（ＰＤＡ）、メディアプレイヤ、画像化デバイス等のような他のタイプのデバイスを含んでもよく、ユーザ１２は、車両１４に近づいて対話するときに、モバイルデバイス１６、１８を自身とともに携行することができる。更に詳細に説明されるように、ユーザ１２を認証するために、モバイルデバイス１６、１８の存在が必要とされることがあり、この場合、認証の成功により、車両１４の特定の機能が、ユーザ１２に対して利用可能にされ得る。例えばユーザ１２が、車両１４にアクセスすること（例えばドア及び／又はトランクのロック解除機能）、車両１４を始動させること（例えばイグニッション機能）、様々な設定をカスタマイズすること（例えばユーザ設定機能）、車両１４を運転すること（例えば車両操作機能）、車両１４とデバイスをペアリングすること（例えばデバイスペアリング機能）等を許可される前に、モバイルデバイス１６、１８の双方の存在が必要とされることがある。したがって、図示される環境１０は、車両１４のセキュリティが、複数のモバイルデバイス１６、１８の近接性のステータス（proximity status）に依存する、「マルチファクタ」認証環境を表す。

また、更に詳細に検討されるように、ユーザのポリシー及び／又はプロファイルを使用して、モバイルデバイス１６、１８の一方しか存在しない場合であっても、車両アクセス及びデバイスペアリングのような特定の機能をユーザに利用可能にしてもよい。さらに、２つのモバイルデバイスが示されているが、車両の機能にアクセスするのに、所与のユーザによって２つより多くのモバイルデバイスが使用されてもよい。例えばユーザ１２は、スマートフォン、スマートタブレット及びメディアプレイヤを車両１４とペアリングし、スマートフォンを、主（例えば「マスタ」）デバイスとして指定してもよい。この場合、主デバイスは、車両１４の他のデバイスとのペアリングに使用され得る。

例えば図２Ａは、第１のモバイルデバイス１６は存在するが、第２のモバイルデバイス１８は存在しない場合に、ユーザ１２が車両１４に入ることを許可されるという、ポリシーが実装される様子を示している。このようなケースは、第２のモバイルデバイス１８を紛失するか盗まれた場合、あるいはユーザ１２が単に第２のモバイルデバイス１８を持ってくるのを忘れた場合に起こり得る。ポリシーは、ユーザ１２に対応するユーザプロファイルとして、あるいは全てのユーザ又はユーザのグループに適用可能なグローバルポリシー（例えばデフォルトのプロファイル）として実装されてよく、このポリシーは、ユーザ１２が、該ユーザ１２のユーザプロファイルと関連付けられたログイン制約（例えば所定のパスコードを入力すること）を十分満たし、ペアリングプロセスを完了するという条件で、置換デバイス２０（例えばスマートフォン）が車両１４とペアリングされることを許容してもよい。

同様に、図２Ｂは、第２のモバイルデバイス１８は存在するが、第１のモバイルデバイス１６が存在しない場合に、ユーザプロファイルにより、ユーザ１２が車両１４に入ることが許容され得る様子を示す。このようなケースは、第１のモバイルデバイス１６を紛失するか盗まれた場合、あるいはユーザ１２が単に第１のモバイルデバイス１６を持ってくるのを忘れた場合に起こり得る。ユーザプロファイルは、ユーザ１２が、該ユーザ１２のユーザプロファイルと関連付けられたログイン制約を十分満たし、ペアリングプロセスを完了するという条件で、置換デバイス２２（例えばキーフォブ）が車両１４とペアリングされることを許容してもよい。したがって、マルチファクタ認証スキームは、車両１４に対して比較的高いセキュリティレベルを維持しつつ、ユーザ１２にとってかなり少ないコスト、遅延及び不便性で、新たなファクタを車両１４とペアリングすることを可能にすることができる。

次に図３に移ると、論理アーキテクチャ２４（２４〜２４ｄ）が示されている。論理アーキテクチャ２４は一般に、例えば車両１４（図１、図２Ａ及び図２Ｂ）のような車両に、ハードウェア、ソフトウェア、ファームウェア又はその組合せとして組み込まれてよい。図示される例では、第１のファクタモジュール２４ａは、近接性センサ（図示せず）を使用して、車両に対する第１のモバイルデバイス１６の第１の近接性ステータスを決定する。同様に、第２のファクタモジュール２４ｂは、近接性センサを使用して、車両に対する第２のモバイルデバイス１８の第２の近接性ステータスを決定することができる。セキュリティモジュール２４ｃは、要求コンポーネント４０を有してよい。要求コンポーネント４０は、ユーザの要求を、第１のモバイルデバイス１６のユーザインタフェース（ＵＩ）３０（例えばプッシュボタン、スイッチ等）を介して、第２のモバイルデバイス１８のＵＩ３２（例えばタッチスクリーン、マイクロフォン等）、車両のＵＩ３４（例えばドアハンドル、プッシュボタン、タッチスクリーン等）等を介して受信する。セキュリティモジュール２４ｃは、ユーザ要求に応答して、第１の近接性ステータス及び第２の近接性ステータスに少なくとも部分的に基づいて、車両の１つ又は複数の機能２６（２６ａ〜２６ｃ）のアクセス性を構成することができる。一例において、セキュリティモジュール２４ｃは、１つ又は複数のユーザプロファイル２８のようなポリシーを識別する。ユーザプロファイル２８の少なくとも１つは、第１のモバイルデバイス１６及び／又は第２のモバイルデバイス１８（及び当該デバイスに対応するユーザ）に関連付けられることがある。このような場合において、車両機能２６は、識別されたユーザプロファイルに更に基づいて構成されてよい。

例えばセキュリティモジュール２４ｃは、拒否コンポーネント３６を有する可能性もあり、拒否コンポーネント３６は、第１の近接性ステータス及び第２の近接性ステータスがユーザプロファイルのマルチファクタ条件を満たさない場合に、ユーザ要求を拒否する。より具体的には、マルチファクタ条件は、対象の車両機能をユーザに利用可能にするためには、モバイルデバイス１６、１８（例えばファクタ）が双方存在すべきことを規定することがある。このような場合において、第１の近接性ステータスは第１のモバイルデバイス１６が存在することを示しているが、第２の近接性ステータスが第２のモバイルデバイス１８が存在していないことを示している場合、マルチファクタ条件は満たされないことになる。同様に、第２の近接性ステータスは第２のモバイルデバイス１８が存在することを示しているが、第１の近接性ステータスが第１のモバイルデバイス１６が存在していないことを示している場合、マルチファクタ条件は満たされないことになる。

時間ベースの条件や位置ベースの条件のような他の条件を使用してもよい。例えばユーザプロファイルが、対象のユーザ（あるいはグローバルポリシー及び／又はデフォルトプロファイルが実装されている場合は全てのユーザ）は、特定の位置のある範囲（例えば通りのアドレス）内で車両を操作すべきことを規定しており、車両がその範囲外にあると判断した場合、拒否コンポーネント３６は、車両の操作を拒否すること（例えば車両のイグニッションを妨げることや、ドライバに警告を与えた後に車両をシャットダウンすること等）がある。別の例として、ユーザプロファイルが、対象のユーザは、ある時間内に車両を操作すべきことを規定しており、現在の時間が指定された時間外であると判断した場合も、拒否コンポーネント３６は車両の操作を拒否してよい。加えて、マルチファクタ条件の施行を、継続的に実施してもよい。例えば所与のユーザ要求が許可された後に、要求の許可につながった条件がもう満たされていないと決定した場合、条件の許可を事実上破棄してもよい。したがって、そのようなシナリオにおいても同様に、車両のシャットダウンが実装され得る。他の例には、ドライバが気を取られるシナリオを避けるため、車両を操作している間のラジオの利用の禁止が含まれ得る。

セキュリティモジュール２４ｃは、許可コンポーネント３８も有することができ、許可コンポーネント３８は、第１の近接性ステータス及び第２の近接性ステータスがユーザプロファイルのマルチファクタ条件を満たす場合に、ユーザ要求を許可する。更に詳細に検討されるように、許可コンポーネント３８は、例えば時間制約、位置制約、ログイン制約等のユーザプロファイルの１つ又は複数の制約を対象の車両機能に適用してもよい。特にログイン制約に関して、図示されるアーキテクチャ２４は、第１及び第２のモバイルデバイス１６、１８並びにデバイス２０（図２Ａ）、デバイス２２（図２Ｂ）のような置換デバイスを車両とペアリングするように構成されるペアリングモジュール２４ｄも含む。モバイルデバイス１６、１８及び置換デバイス２０（図２Ａ）、２２（図２Ｂ）を相互にペアリングしてもよい。双方のファクタが存在する場合、ペアリングモジュール２４ｄは、通常通りにペアリングプロセスを管理してよい。一方、ファクタのうちの１つしか存在しない場合、ペアリングモジュール２４ｄは、車両へ入ることを許可し、次いでペアリングプロセスを進める前にユーザにパスコード（例えば個人識別番号／ＰＩＮ、パスワード等）を入力するよう促すことがある。

更にペアリングモジュール２４ｄに関して、パスコードは、モバイルデバイス１６、１８の一方において入力されてよいが、一部の実施形態では、デバイス１６、１８をペアリングするために車両ＵＩ３４に直接入力されることを必要としてもよい。別の実施形態では、自動ペアリングが可能であり、この場合、「マスタ」（例えば主）デバイスが拒否されるまで、デフォルトのポリシー及び／又はユーザプロファイルが使用され得る。例えば一方のデバイスが、他のデバイスを一緒に車両とペアリングするために存在すべきマスタ（例えば１つのマスタキーフォブ）であると見なされてよい。一部の実施形態において、ペアリングは、（例えば子供や、未成年者、車両及びスマートフォンの他の非所有者によって操作される権限の少ない（lesser privileged）スマートフォンをペアリングするために）マスタデバイスも存在するときにのみ完了し得る。一部の実施形態において、第２のデバイス（例えばキーフォブではなくスマートフォン）が、他の二次デバイスにおけるユーザ制約の入力を可能にするため、ペアリングの時にマスタデバイスとして識別されることがある。これらの他の二次的な「非マスタ」デバイス（例えば権限の少ないスマートフォン）は、これら自身のユーザ制約を変更することができないことがある。二次デバイスは、デバイス上に格納されるユーザ制約を、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ワイヤレス、ＮＦＣ（近距離通信）、コンピュータ又は他のドッキングステーションとの同期等のような幾つかの手段により受け取ることができる。ユーザ制約はその後、マスタデバイスが存在する場合を除いて、修正不可能となることがある。

さらに、図示されるセキュリティモジュール２４ｃは、通知コンポーネント４２を有する。通知コンポーネント４２は、第１の近接性ステータスが第１のモバイルデバイスが存在しないと示すか、又は第２の近接性ステータスが第２のモバイルデバイスが存在しないと示す場合に、第１のモバイルデバイス１６のＵＩ３０、第２のモバイルデバイス１８のＵＩ３２及び／又は車両のＵＩ３４を介して通知を生成するように構成される。より具体的には、そのような通知は、本物のユーザがファクタのうちの１つがない（例えば忘れたファクタが欠けている）状態で車両を操作しようと試みている場合、並びに許可されていないユーザがファクタのうちの１つがない状態で車両を操作しようと試みている（例えば盗まれたファクタが存在する）場合、特に有益である。通知は、状況に応じて、近くのファクタ（例えばファクタを忘れた場合）及び／又は欠けているファクタ（例えばファクタが盗まれた場合）に送信され得る。

図示される例では、モバイルデバイス１６、１８はそれぞれ、１つ又は複数のマルチファクタ条件を有するポリシーを格納するポリシーリポジトリ１７と、車両のセキュリティモジュール２４ｃから要求を受信し、該要求に応答してポリシーをセキュリティモジュール２４ｃに伝送する無線インタフェース１９を含む。一例において、ポリシーはユーザプロファイルである。既に説明したように、所与のマルチファクタ条件は、第１のモバイルデバイス１６又は第２のモバイルデバイス１８が、車両の機能２６へのアクセスの試行中に車両の近くにない場合、車両の機能２６をアクセス可能にすべきかどうかを指示することができる。ポリシーは、ペアリングプロセス及び／又は車両の機能２６の１つ若しくは複数へのアクセスの試行と関連して、セキュリティモジュール２４ｃに伝送され得る。

更にペアリングプロセスに関して、図示されるモバイルデバイス１６、１８は、それぞれのデバイスと車両及び／又は他のデバイスをペアリングするように構成されるペアリングモジュール２１も含む。一例において、第１のモバイルデバイス１６のペアリングモジュール２１は、ＵＩ３０を介してパスコードを受信し、該パスコードがポリシーのログイン制約を満たすかどうか判断し、パスコードがログイン制約を満たす場合、第１のモバイルデバイス１６はペアリングされる。同様に、第２のモバイルデバイス１８のペアリングモジュール２１は、ＵＩ３２を介してパスコードを受信し、該パスコードがポリシーのログイン制約を満たすかどうか判断し、パスコードがログイン制約を満たす場合、第２のモバイルデバイス１８がペアリングされる。あるいは、パスコードがログイン制約を満たすかどうかの判断は、車両によって実行されてもよい。さらに、一部の例において、例えば第１のモバイルデバイス１６（例えばキーフォブ）のようなモバイルデバイスは、ログイン認証のエントリをサポートする能力を有しないことがある。このような場合、車両のＵＩ３４を使用するか、そのデバイスがマスタデバイスであれば、ログインプロセスを完全にバイパスしてもよい。

図４は、テーブルとして構成される一組のユーザプロファイル２８を示す。図示される例では、複数のユーザ（例えば「Ｄａｄ」、「Ｍｏｍ」、「Ｓａｌｌｙ」）はそれぞれ、プログラム可能／構成可能な様々なプリファレンスを有する。例えばパスコード、車両へのアクセスに必要なファクタの数（「アクセスファクタ」）、車両のイグニッションをアクティブにするのに必要なファクタの数（「始動ファクタ」）、車両を操作するのに必要なファクタの数（「ドライブファクタ」）、位置制約、時間制約等を全て、ユーザごとに定義することができる。さらに、指定されたパラメータを使用して、ユーザ要求を許可するかどうか、並びにユーザ固有の条件を許可された要求に適用するかどうかを決定してもよい。特に注目すべきことは、異なるユーザが異なるポリシーを有してよいことである。例えば図示される例では、ＭｏｎとＤａｄは、１つのファクタが存在すれば車両を始動させることができ、一方、Ｓａｌｌｙのプロファイルは、車両を始動させるためには２つのファクタを必要とする。ユーザプロファイル２８の図示されたセットは、テーブルとして構成されているが、ユーザプロファイル２８のセットは、関連データベース構造及び／又はリンクリストのような他の公知の構造を用いて、その中に表されるデータをトラックし、管理し、制御し、そして編成してもよい。

次に図５に移ると、マルチファクタ認証環境を管理する方法４４が示されている。方法４４は、マシン又はコンピュータ読取可能記憶媒体内に格納される論理命令のセット及び／又はファームウェアとして実装されてよく、そのような媒体は、例えばプログラマブル論理アレイ（ＰＬＡ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、結合プログラマブル論理デバイス（ＣＰＬＤ）のような構成可能なロジックで、特定用途向け集積回路（ＡＳＩＣ）、相補型ＭＯＳ（ＣＭＯＳ）又はトランジスタ−トランジスタ論理（ＴＴＬ）技術又はこれらの組合せのような回路技術を使用する固定の機能性の論理ハードウェアによる、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、フラッシュメモリ等である。例えば方法４４に示される動作を実行するコンピュータプログラムコードを、Ｃ＋＋若しくは同様のもののようなオブジェクト指向プログラミング言語及び「Ｃ」プログラミング言語若しく類似のプログラミング言語のような従来の手続的プログラミング言語を含む、１つ又は複数のプログラミング言語の任意の組み合わせて書くことができる。さらに、方法４４は、上述の回路技術のいずれかを使用する論理アーキテクチャ２４（図３）として実装されてもよい。

図示される処理ブロック４６は、例えば第１のモバイルデバイス、第２のモバイルデバイス及び車両等のユーザインタフェースを介してユーザ要求を受信することを提供する。ユーザ要求は、ドアのロック解除機能（例えばアクセス要求）、イグニッション機能（例えば始動要求）、ユーザ設定機能（例えばシートのプリファレンス、ラジオのプリファレンス）、車両操作機能（例えばドライブにおけるトランスミッションの配置／管理）、ペアリング機能（例えば置換デバイス）等のような車両の１つ又は複数の機能に対応し得る。ブロック４８において、マルチファクタ条件が満たされるかどうかの判断が行われる。上記したように、マルチファクタ条件は、車両に対する第１のモバイルデバイスの第１の近接性ステータス、車両に対する第２のモバイルデバイスの第２の近接性ステータス等を考慮してよく、この場合、マルチファクタ条件は、対象の車両機能をユーザに利用可能にするためには双方のモバイルデバイスが存在すべきことを指定してもよい。マルチファクタ条件が満たされない場合、ブロック５２において、ユーザ要求を拒否する。ブロック５２は、欠けている、紛失した及び／又は盗まれたモバイルデバイスについて車両の所有者に知らせるために、例えば第１のモバイルデバイス、第２のモバイルデバイス、車両又はこれらの任意の組合せのユーザインタフェースを介して通知を生成することを提供してもよい。

一方、マルチファクタ条件が満たされる場合、図示されるブロック５０は、ユーザ要求を許可し、いずれかの関連する制約を要求に適用する。マルチファクタ条件と制約の双方を、ユーザごとに定義して、適切なプロファイル、ポリシー等内に格納してもよい。一例において、制約は、特定の場所においてのみ車両機能が利用可能になるという位置制約である。別の例において、制約は、特定の時間に及び／又は特定の期間の間のみ車両機能が利用可能となるという時間制約である。更に別の例において、制約は、ユーザが所定のパスコードを入力した場合にのみ車両機能が利用可能となるというログイン制約である。ログイン制約は、デバイスのペアリング及びデバイスの置換に特に有益である。

図６は、一実施形態に係るプロセッサコア２００を図示している。プロセッサコア２００は、マイクロプロセッサ、組み込みプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサ又はコードを実行する他のデバイスのような任意のタイプのプロセッサ用のコアであってよい。図６では１つのプロセッサコア２００しか図示していないが、代替として、処理要素は、１つより多くの、図６に図示されるプロセッサコア２００を含んでもよい。プロセッサコア２００はシングルスレッドコアであってよく、あるいは少なくとも１つの実施形態に関して、プロセッサコア２００は、コアごとに１つより多くのハードウェアスレッドコンテキスト（すなわち「論理プロセッサ」）を含み得るという点で、マルチスレッド化されてもよい。

図６は、プロセッサ２００に結合されたメモリ２７０も含む。メモリ２７０は、当業者に公知であるか、あるいは利用可能であるような、（メモリ階層の様々なレイヤを含む）多様なメモリのいずれかであってよい。メモリ２７０は、プロセッサコア２００によって実行される１つ又は複数のコード２１３命令を含むことがあり、コード２１３は、上述のような論理アーキテクチャ２４（図３）を実装し得る。プロセッサコア２００は、コード２１３によって指示される命令のプログラムシーケンスに従う。したがって、プロセッサコア２００は、車両１４（図１）のような車両の一部であってよい。プロセッサコア２００は、モバイルデバイス１６、１８（図３）のようなモバイルデバイスにおいて使用されてもよく、これらのデバイスの機能性をサポートする。各命令は、フロントエンド部分２１０を入力し、１つ又は複数のデコーダ２２０によって処理され得る。デコーダ２２０は、その出力として、所定のフォーマットの固定幅のマイクロオペレーションのようなマイクロオペレーションを生成するか、他の命令、マイクロ命令又は元のコード命令を反映する制御信号を生成し得る。図示されたフロントエンド２１０は、レジスタリネームロジック２２５及びスケジュールロジック２３０も含み、これらは一般に、実行のために、リソースを割り当てて変換命令に対応するオペレーションをキューする。

プロセッサ２００は、１組の実行ユニット（ＥＵ：execution unit）２２５−１〜２２５−Ｎを有する実行ロジック２５０を含むよう示されている。一部の実施形態は、固有の機能又は機能のセットに専用の複数の実行ユニットを含んでよい。他の実施形態は、１つの実行ユニットのみを含むか、特定の機能を実行することができる１つの実行ユニットを含んでよい。図示される実行ロジック２５０は、コード命令によって指定されるオペレーションを実行する。

コード命令によって指定されたオペレーションの実行が完了すると、バックエンドロジック２６０は、コード２１３の命令を終了（retire）させる。一実施形態において、プロセッサ２００は、順不同の実行は許容するが、命令を順番に終了することを要求する。終了ロジック２６５は、当業者に公知であるような様々な形式を取ることができる（例えば順序付け（re-order）バッファ等）。このようにして、プロセッサコア２００は、少なくとも、デコーダによって生成される出力、レジスタリネームロジック２２５によって用いられるハードウェアレジスタ及びテーブル並びに実行ロジック２５０によって修正されるいずれかのレジスタ（図示せず）に関して、コード２１３の実行中に変換される。

図６には図示されていないが、処理要素は、プロセッサコア２００とともにチップ上の他の要素を含んでもよい。例えば処理要素は、プロセッサコア２００とともにメモリ制御ロジックを含んでもよい。処理要素は、Ｉ／Ｏ制御ロジックを含んでもよく、及び／又はメモリ制御ロジックと統合されるＩ／Ｏ制御ロジックを含んでもよい。処理要素は１つ又は複数のキャッシュも含み得る。

次に図７を参照すると、本発明の一実施形態に係るシステム１０００のブロック図が示されている。一例において、システム１０００は、上述の車両１４のような車両の一部である。システム１０００は、モバイルデバイス１６、１８（図３）のようなモバイルデバイス内で、これらのデバイスの機能性をサポートするのに使用されてもよい。図７に図示されているのは、マルチプロセッサシステム１０００であり、該マルチプロセッサシステム１０００は、第１の処理要素１０７０及び第２の処理要素１０８０を含む。２つの処理要素１０７０及び１０８０が示されているが、システム１００の実施形態は、そのような処理要素の１つのみを含むこともある。

システム１０００は、ポイントツーポイント相互接続システムとして図示されており、ここでは、第１の処理要素１０７０及び第２の処理要素１０８０が、ポイントツーポイント相互接続１０５０を介して結合される。図７に図示される相互接続のいずれか又は全てを、ポイントツーポイント相互接続ではなく、マルチドロップバスとして実装してもよいことを理解されたい。

図７に示されるように、処理要素１０７０及び１０８０はそれぞれ、第１及び第２のプロセッサコア（すなわちプロセッサコア１０７４ａ、１０７４ｂ及びプロセッサコア１０８４ａ、１０８４ｂ）を含むマルチコアプロセッサであってよい。そのようなコア１０７４ａ、１０７４ｂ、１０８４ａ、１０８４ｂは、上記で図６に関連して説明した手法と同様の手法により命令コードを実行するように構成され得る。

各処理要素１０７０、１０８０は、少なくとも１つの共有キャッシュ１８９６を含み得る。共有キャッシュ１８９６ａ、１８９６ｂは、それぞれコア１０７４ａ、１０７４ｂ、１０８４ａ、１０８４ｂのような、プロセッサの１つ又は複数のコンポーネントによって用いられるデータ（例えば命令）を格納することができる。例えば共有キャッシュは、プロセッサのコンポーネントによる高速アクセスのために、メモリ１０３２、１０３４（例えばコンピュータ読取可能媒体、コンピュータ読取可能記憶媒体等）内に格納されるデータをローカルにキャッシュすることができる。１つ又は複数の実施形態において、共有キャッシュは、レベル２（Ｌ２）、レベル３（Ｌ３）、レベル４（Ｌ４）又は他のレベルのキャッシュのような１つ又は複数の中間レベルのキャッシュ、最終レベルのキャッシュ（ＬＬＣ）及び／又はこれらの組合せを含み得る。

２つの処理要素１０７０、１０８０のみが示されているが、本発明の範囲はそのように限定されないことは理解されよう。他の実施形態において、１つ又は複数の追加の処理要素を所与のプロセッサに提示してもよい。あるいは、処理要素１０７０、１０８０の１つ又は複数が、アクセラレータやフィールドプログラマブルゲートアレイのような、プロセッサ以外の要素であってもよい。例えば追加の処理要素は、第１のプロセッサ１０７０と同じ追加のプロセッサと、第１のプロセッサ１０７０のようなプロセッサと異種又は非対称の追加のプロセッサ、（例えばグラフィクスアクセラレータ又はデジタル信号処理（ＤＳＰ）ユニットのような）アクセラレータ、フィールドプログラマブルゲートアレイ又は任意の他の処理要素を含んでもよい。アーキテクチャ、マイクロアーキテクチャ、熱、電力消費特性等を含むメリットのメトリクスのスペクトルに関して、処理要素１０７０と１０８０との間には様々な相違が存在する可能性がある。これらの相違は実質的に、処理要素１０７０、１０８０の間の非対称性及び異種性として現れることがある。少なくとも１つの実施形態に関して、様々な処理要素１０７０、１０８０が同じダイ・パッケージ内に存在し得る。

第１の処理要素１０７０は更に、メモリコントローラロジック（ＭＣ）１０７２と、ポイントツーポイント（Ｐ−Ｐ）インタフェース１０７６及び１０７８を含み得る。同様に、第２の処理要素１０８０も、ＭＣ１０８２と、Ｐ−Ｐインタフェース１０８６及び１０８８を含み得る。図７に示されるように、ＭＣ１０７２及び１０８２は、プロセッサを、それぞれのメモリ、すなわちメモリ１０３２及びメモリ１０３４に結合する。メモリ１０３２及びメモリ１０３４は、それぞれのプロセッサにローカルに取り付けられるメインメモリの一部であってよい。ＭＣロジック１０７２及び１０８２は、処理要素１０７０及び１０８０に統合されるよう図示されているが、代替的な実施形態では、ＭＣロジックは、処理要素１０７０、１０８０内に統合するのではなく、処理要素１０７０、１０８０の外にある別個のロジックとしてもよい。

第１の処理要素１０７０及び第２の処理要素１０８０は、それぞれＰ−Ｐ相互接続１０７６、１０８６及び１０８４を介してＩ／Ｏサブシステム１０９０に結合され得る。図７に示されるように、Ｉ／Ｏサブシステム１０９０は、Ｐ−Ｐインタフェース１０９４及び１０９８を含む。さらに、Ｉ／Ｏサブシステム１０９０は、Ｉ／Ｏサブシステム１０９０を高性能グラフィクスエンジン１０３８に結合するインタフェース１０９２を含む。一実施形態において、バス１０４９を使用して、グラフィクスエンジン１０３８をＩ／Ｏサブシステム１０９０に結合してもよい。あるいは、ポイントツーポイント相互接続１０３９がこれらのコンポーネントを結合してもよい。

続いて、Ｉ／Ｏサブシステム１０９０は、インタフェース１０９６を介して第１のバス１０１６に結合され得る。一実施形態において、第１のバス１０１６は周辺コンポーネント相互接続（ＰＣＩ）バス又はＰＣＩエクスプレスバスや別の第三世代のＩ／Ｏ相互接続バスのようなバスとすることができるが、本発明の範囲はこれに限定されない。

図７に示されるように、様々なＩ／Ｏデバイス１０１４は、バスブリッジ１０１８とともに第１のバス１０１６に結合されてよく、バスブリッジ１０１８は、第１のバス１０１６を第２のバス１０２０に結合することができる。Ｉ／Ｏデバイス１０１４は、例えば車両に対するモバイルデバイスの近接性ステータスを決定するのに使用され得る１つ又は複数の近接性センサを含み得る。例えば近接性センサは、近距離通信（ＮＦＣ）技術、無線自動識別（ＲＦＩＤ）技術、赤外線（ＩＲ）技術等を組み込むことができる。一実施形態において、第２のバス１０２０は、ローピンカウント（ＬＰＣ）バスとすることができる。様々なデバイスを第２のバス１０２０に結合してもよく、一実施形態において、そのようなデバイスには、例えばキーボード／マウス１０１２、（図示されないコンピュータネットワークと通信することができる）通信デバイス１０２６及びディスクドライブやコード１０３０を含むことができる他の大容量記憶デバイスが含まれる。コード１０３０は、上述の方法の１つ又は複数の実施形態を実行するための命令を含むことができる。したがって、図示されるコード１０３０は、論理アーキテクチャ２４（図３）を実装することがあり、上述のコード２１３（図６）と同様のものとすることができる。さらに、オーディオＩ／Ｏ１０２４を第２のバス１０２０に結合してもよい。

他の実施形態も考えられることに留意されたい。例えば図７のポイントツーポイントアーキテクチャの代わりに、システムは、マルチドロップバス又は別の上記通信トポロジを実装してもよい。また、図７の要素は、代替として、図７に示される統合チップよりも多くの、あるいは少ないチップを使用して区分化されてもよい。

したがって、本明細書で説明される技術は、スマートフォンやスマートタブレット等のような汎用デバイスを、車両のコンテキストにおける認証目的に使用できるようにすることにより、コストを低減することができる。加えて、多様なデバイスを車両と急きょペアリングすることができるという能力により、紛失するか盗まれた認証デバイスを交換することに関連する遅延も、大幅に低減することができる。さらに、セキュリティ制約を適用するためのカスタマイズ可能なプロファイル及び／又はポリシーの使用は、ユーザにとって非常に利便性の高いものであり、ユーザ経験を実質的に向上させることができる。加えて、モバイルデバイスは、車両と直接通信するように構成され得るので、サーバ及び／又はサービスプロバイダのような媒介を要することなく、近接性ステータスの情報を、汎用のモバイルデバイスと車両との間で直接決定することができる。

例として、車両に対する第１のモバイルデバイスの第１の近接性ステータスを決定する第１のファクタモジュールと、車両に対する第２のモバイルデバイスの第２の近接性ステータスを決定する第２のファクタモジュールとを含む装置が提供され得る。当該装置は、第１の近接性ステータス及び第２の近接性ステータスに少なくとも部分的に基づいて、車両の１つ又は複数の機能のアクセス性を構成する、セキュリティモジュールも含み得る。

さらに、セキュリティモジュールは、第１のモバイルデバイス及び第２のモバイルデバイスの１つ又は複数に関連付けられるポリシーを識別し、アクセス性は、ポリシーに更に基づいて構成される。

さらに、セキュリティモジュールは、第１のモバイルデバイス、第２のモバイルデバイス及び車両のうちの１つ又は複数のユーザインタフェースを介してユーザ要求を受信し、アクセス性は、ユーザ要求に応答して構成される。

また、セキュリティモジュールは、第１の近接性ステータス及び第２の近接性ステータスがポリシーのマルチファクタ条件を満たさない場合に、ユーザ要求を拒否する拒否コンポーネントを含み得る。

加えて、セキュリティモジュールは、第１の近接性ステータス及び第２の近接性ステータスがポリシーのマルチファクタ条件を満たす場合に、ユーザ要求を許可する許可コンポーネントを含み得る。

加えて、許可コンポーネントは、ポリシーの時間制約、ポリシーの位置制約及びポリシーのログイン制約のうちの１つ又は複数を、車両の１つ又は複数の機能のうちの少なくとも１つに適用し得る。

また、セキュリティモジュールは、第１の近接性ステータスが第１のモバイルデバイスが存在していないことを示すか、第２の近接性ステータスが第２のモバイルデバイスが存在していないことを示す場合、第１のモバイルデバイス、第２のモバイルデバイス及び車両のうちの１つ又は複数のユーザインタフェースを介して通知を生成する、通知コンポーネントを含み得る。

さらに、車両の１つ又は複数の機能の少なくとも１つは、ドアのロック解除機能、トランクのロック解除機能、イグニッション機能、ユーザ設定機能、車両操作機能及び置換デバイスのペアリング機能、のうちの１つ又は複数を含み得る。

さらに、上述の装置の例のうちのいずれかは、近接性センサを含んでもよく、第１のファクタモジュールは、近接性センサを使用して第１の近接性ステータスを決定し、第２のファクタモジュールは、近接性センサを使用して第２の近接性ステータスを決定する。

例として方法も含まれ、当該方法では、車両に対する第１のモバイルデバイスの第１の近接性ステータスを決定する。また、当該方法は、車両に対する第２のモバイルデバイスの第２の近接性ステータスを決定するステップと、第１の近接性ステータス及び第２の近接性ステータスに少なくとも部分的に基づいて、車両の１つ又は複数の機能のアクセス性を構成するステップも提供し得る。

さらに、方法は、第１のモバイルデバイス及び第２のモバイルデバイスの１つ又は複数に関連付けられるポリシーを識別するステップを更に含んでもよく、アクセス性は、ポリシーに更に基づいて構成される。

さらに、方法は、第１のモバイルデバイス、第２のモバイルデバイス及び車両のうちの１つ又は複数のユーザインタフェースを介してユーザ要求を受信するステップを更に含んでもよく、アクセス性は、ユーザ要求に応答して構成される。

また、アクセス性を構成するステップは、第１の近接性ステータス及び第２の近接性ステータスが、ポリシーのマルチファクタ条件を満たさない場合にユーザ要求を拒否するステップを含んでもよい。

加えて、アクセス性を構成するステップは、第１の近接性ステータス及び第２の近接性ステータスが、ポリシーのマルチファクタ条件を満たす場合に、ユーザ要求を許可するステップを含んでもよい。

加えて、アクセス性を構成するステップは、ポリシーの時間制約、ポリシーの位置制約及びポリシーのログイン制約のうちの１つ又は複数を、車両の１つ又は複数の機能のうちの少なくとも１つに適用するステップを更に含んでもよい。

また、アクセス性を構成するステップは、第１の近接性ステータスが第１のモバイルデバイスが存在していないことを示すか、第２の近接性ステータスが第２のモバイルデバイスが存在していないことを示す場合、第１のモバイルデバイス、第２のモバイルデバイス及び車両のうちの１つ又は複数のユーザインタフェースを介して通知を生成するステップを含んでもよい。

さらに、上述の方法の例のいずれかにおいて、車両の１つ又は複数の機能の少なくとも１つは、ドアのロック解除機能、トランクのロック解除機能、イグニッション機能、ユーザ設定機能、車両操作機能及び置換デバイスのペアリング機能、のうちの１つ又は複数を含み得る。

例には、プロセッサによって実行されると、車両に、上記の方法の例のいずれかを実行させる命令のセットを有する少なくとも１つのマシン読取可能媒体も含まれ得る。

また、例には、近接性センサと、該近接性センサを使用して、車両に対する第１のモバイルデバイスの第１の近接性ステータスを決定する第１のファクタモジュールとを有するシステムが含まれることがある。当該システムは、近接性センサを使用して、車両に対する第２のモバイルデバイスの第２の近接性ステータスを決定する第２のファクタモジュールと、第１の近接性ステータス及び第２の近接性ステータスに少なくとも部分的に基づいて、車両の１つ又は複数の機能のアクセス性を構成するセキュリティモジュールとを有することができる。

例には、マルチファクタ条件を有するポリシーを格納するポリシーリポジトリを有するモバイルデバイスも含まれ得る。当該モバイルデバイスは、車両のセキュリティモジュールから要求を受信し、該要求に応答してポリシーをセキュリティモジュールに伝送する無線インタフェースも含み得る。

さらに、マルチファクタ条件は、第１のモバイルデバイス又は第２のモバイルデバイスが、車両の近くにない場合、１つ又は複数の機能をアクセス可能にすべきかどうかを指示することがある。

さらに、モバイルデバイスは更に、第１のモバイルデバイスを車両とペアリングするペアリングモジュールを含んでもよい。

また、ペアリングモジュールは、第１のモバイルデバイスのユーザインタフェースを介してパスコードを受信することがあり、第１のモバイルデバイスは、パスコードがポリシーのログイン制約を満たす場合にのみ車両とペアリングされる。

加えて、無線インタフェースは、第１のモバイルデバイスがマスタデバイスであるという通知を受信することがあり、この場合、ポリシーは複数のユーザプロファイルを含む。

加えて、上述のモバイルデバイスの例のいずれかの無線インタフェースは、第１のモバイルデバイス又は第２のモバイルデバイスのいずれかが、車両の１つ又は複数の機能へのアクセスの試行中に、車両の近くにないという通知を受信することがある。

例には、プロセッサによって実行されると、第１のモバイルデバイスに、上記のモバイルデバイスの例に係る方法いずれかを実行させる命令のセットを備える少なくとも１つのマシン読取可能媒体も含まれ得る。

様々な実施形態が、ハードウェア要素、ソフトウェア要素及びその双方の組合せを使用して実装され得る。ハードウェア要素の例には、プロセッサ、マイクロプロセッサ、回路、回路要素（例えばトランジスタ、レジスタ、キャパシタ、インダクタ等）、集積回路、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理デバイス（ＰＬＤ）、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ロジックゲート、レジスタ、半導体デバイス、チップ、マイクロチップ、チップセット等が含まれ得る。ソフトウェアの例には、ソフトウェアコンポーネント、プログラム、アプリケーション、コンピュータプログラム、アプリケーションプログラム、システムプログラム、マシンプログラム、オペレーティングシステムソフトウェア、ミドルウェア、ファームウェア、ソフトウェアモジュール、ルーチン、サブルーチン、関数、メソッド、プロシージャ、ソフトウェアインタフェース、アプリケーションプログラムインタフェース（ＡＰＩ）、命令セット、コンピューティングコード、コンピュータコード、コードセグメント、コンピュータコードセグメント、ワード、値、記号又はこれらの任意の組み合わせが含まれ得る。実施形態が、ハードウェア要素及び／又はソフトウェア要素を使用して実装されるかどうかの判断は、所望の計算レート、パワーレベル、ヒートトレランス、処理サイクル量、入力データレート、出力データレート、メモリリソース、データバススピード及び他の設計若しくは性能制約のような、任意の数のファクタによって変化し得る。

少なくとも１つの実施形態の１つ又は複数の態様は、プロセッサ内の様々なロジックを表すマシン読取可能媒体上に格納される表現的命令によって実装されてよく、このような命令は、マシンによって読み取られると、該マシンに、本明細書で説明される技術を実行するロジックを作成させる。「ＩＰコア」として知られるこのような表現は、有形のマシン読取可能媒体に格納され、様々な顧客又は製造施設に供給されて、実際にロジック又はプロセッサを作る制作マシンへとロードされる。

本発明の諸実施形態は、全てのタイプの半導体集積回路（「ＩＣ」）チップと使用するのに適用可能である。これらのＩＣチップの例には、限定ではないが、プロセッサ、コントローラ、チップセットコンポーネント、プログラマブル論理アレイ（ＰＬＡ）、メモリチップ、ネットワークチップ等が含まれる。さらに、図面の一部において、信号の導体線（signal conductor line）が線で表されている。より多くの構成信号経路を示すよう一部が相違するか、構成信号経路の数を示すよう番号ラベルを有するか、及び／又は主な情報の流れの方向を示すよう１つ又は複数の端部に矢印を有することがある。しかしながら、これは限定的に解釈されるべきではない。むしろ、そのような付加的な詳細は、回路のより容易な理解を促進するために、１つ又は複数の例示の実施形態との関連で用いられ得る。いずれかの示される信号線は実際に、追加の情報を有しているか否かに関わらず、複数の方向に進み、かつ例えば異なるペアで実装されるデジタル又はアナログ線、光ファイバ線及び／又はシングルエンド線のような任意の適切な信号スキームで実装され得る、１つ又は複数の信号を備え得る。

例示のサイズ／モデル／値／範囲が与えられているが、本発明の実施形態は同じものに制限されない。製造技術（例えばフォトリソグラフィ）が時間とともに成長すると、より小さいサイズのデバイスが製造され得ることが予想される。加えて、ＩＣチップ及び他のコンポーネントへの周知の電力／接地接続は、説明及び検討の簡潔性並びに本発明の実施形態の特定の態様を曖昧にしないようにするために、図面内に示されていることも、示されていないこともある。さらに、本発明の実施形態を曖昧にするのを回避するために、配置構成をブロック図で示しているが、そのようなブロック図の配置構成の実装に関する仕様は、実施形態が実装されるプラットフォームに大いに依存する、すなわち、そのような仕様は十分に当業者の範囲内にあるべきである。本発明の例示の実施形態を説明するのに具体的な詳細（例えば回路）が示されている場合、本発明の実施形態は、これらの具体的な詳細を用いることなく実施されることが可能であり、あるいはその変形形態を用いて実施されることも可能であることを、当業者は認識されたい。したがって、説明は、限定ではなく例示として見なされるべきである。

一部の実施形態は、例えばマシン又は有形のコンピュータ読取可能媒体又は製品を使用して実装されてよく、これらの媒体又は製品は、マシンによって実行されると、該マシンに諸実施形態に係る方法及び／又は動作を実行させる、命令又は命令のセットを格納し得る。そのようなマシンは、例えば任意の適切な処理プラットフォーム、コンピューティングプラットフォーム、コンピューティングデバイス、処理デバイス、コンピューティングシステム、処理システム、コンピュータ、プロセッサ又は同様のものを含んでよく、またハードウェア及び／又はソフトウェアの任意の適切な組合せを使用して実装されてよい。マシン読取可能な媒体又は製品には、例えば任意の適切なタイプのメモリユニット、メモリデバイス、メモリ製品、メモリ媒体、記憶デバイス、記憶製品、記憶媒体及び／又は記憶ユニット、例えばメモリ、取外し可能又は取外し不可能媒体、消去可能／消去不可能媒体、書き込み可能又は書き換え可能媒体、デジタル又はアナログ媒体、ハードディスク、フロッピー（登録商標）ディスク、コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、記録可能コンパクトディスク（ＣＤ−Ｒ）、再書き込み可能コンパクトディスク（ＣＤ−ＲＷ）、光ディスク、磁気媒体、磁気光媒体、取外し可能メモリカード又はディスク、様々なタイプのデジタル多用途ディスク（ＤＶＤ）、テープ、カセット等が含まれる。命令には、ソースコード、コンパイル済みのコード、翻訳済みのコード、実行可能コード、静的コード、動的コード、暗号化されたコード等のように、任意の適切な高レベル、低レベル、オブジェクト指向、ビジュアル、コンパイル及び／又は翻訳済みプログラミング言語を使用して実装される任意の適切なタイプのコードが含まれ得る。

特段の指定がない限り、「処理する」、「計算する」、「算出する」、「決定する」等のような用語は、コンピュータ若しくはコンピュータシステム又は類似の電子的なコンピューティングデバイスの動作及び／又は処理を指すことを認識されたい。このようなコンピュータ若しくはコンピュータシステム又は類似の電子的なコンピューティングデバイスは、コンピューティングシステム内のレジスタ及び／メモリ内の（例えば電子的）物理的な量として表されるデータを、コンピューティングシステムのメモリ、レジスタ又は他の上記の情報ストレージ、伝送又はディスプレイデバイス内の物理的な量として同様に表される他のデータへ操作及び／又は変換する。諸実施形態は、このコンテキストに限定されない。

「結合する」という用語は、対象のコンポーネント間の任意のタイプの直接的又は間接的な関係を指すのに使用されてよく、電子的、機械的、流体、光、電磁気、電気機械又は他の接続に当てはまることがある。加えて、「第１」、「第２」等の用語は、本明細書において検討を容易にするためだけに使用されるものであり、特段の指定がない限り、特定の時間的又は年代的重要性は有していない。

当業者は、上記の説明から、本発明の諸実施形態の広範な技術を様々な形式で実装することができることを認識するであろう。したがって、本発明の実施形態は、特定の実施例との関連で説明されているが、図面、明細書及び請求項の教示から、当業者には他の修正が明らかになるので、本発明の実施形態の実際の範囲はそのようなものに限定されるべきではない。

Claims (16)

1. プロセッサによって実行されると、第１のモバイルデバイスに、
   １人の特定のユーザに関連付けられる複数のユーザ固有マルチファクタ条件を含むポリシーを格納することであって、前記ポリシーは、前記複数のユーザ固有マルチファクタ条件のうちの特定のユーザ固有マルチファクタ条件が、車両の前記１人の特定のユーザについて満たされるときに前記車両のどの機能がアクセス可能であるかを定義することと、
   前記車両のセキュリティモジュールから要求を受信することと、
   前記要求に応答して、前記セキュリティモジュールに前記ポリシーを伝送することと
   を実行させる、コンピュータプログラム。
2. 別の複数のユーザ固有マルチファクタ条件のうち、複数の特定のユーザのうち１人の他の特定のユーザに関連付けられる１つのユーザ固有マルチファクタ条件は、前記１人の他の特定のユーザに対して特有の前記車両の１つ以上の機能へのアクセスを許可するよう満たされる、
   請求項１に記載のコンピュータプログラム。
3. 前記第１のモバイルデバイスに更に、
   前記車両とのペアリング処理を完了することと、
   主デバイスとして修正可能な指定を実装することと、
   を実行させ、前記主デバイスとしての前記修正可能な指定は、第３のデバイスを前記車両とペアリングするために前記第１のモバイルデバイスを使用することを許可する、
   請求項１に記載のコンピュータプログラム。
4. 前記第１のモバイルデバイスに更に、
   第２のデバイスが、前記複数のユーザ固有マルチファクタ条件のうちの前記特定のユーザ固有マルチファクタ条件を満たす必要があるが、存在しないとき、第２のデバイスを第３のデバイスと置き換えることを実行させる、
   請求項３に記載のコンピュータプログラム。
5. 前記第１のモバイルデバイスに更に、
   前記複数のユーザ固有マルチファクタ条件のうちの前記特定のユーザ固有マルチファクタ条件をそれぞれ満たす必要がある前記第１のモバイルデバイス又は第２のモバイルデバイスのいずれかが、前記車両の１つ又は複数の機能へのアクセスの試行の間に前記車両の近くにない、という通知を受信させる、
   請求項１乃至４のいずれか一項に記載のコンピュータプログラム。
6. 前記複数のユーザ固有マルチファクタ条件のうちの前記特定のユーザ固有マルチファクタ条件は、ユーザ固有の制約に関連付けられる、
   請求項１に記載のコンピュータプログラム。
7. 前記ユーザ固有の制約は、ユーザ固有の位置制約とユーザ固有の時間制約のうちの１つ以上を含む、
   請求項６に記載のコンピュータプログラム。
8. プロセッサによって実行されると、車両に、
   １人の特定のユーザに関連付けられる複数のユーザ固有マルチファクタ条件を含むポリシーを識別することであって、前記ポリシーは、前記複数のユーザ固有マルチファクタ条件のうちの特定のユーザ固有マルチファクタ条件が、車両の前記１人の特定のユーザについて満たされるときに前記車両のどの機能がアクセス可能であるかを定義することと、
   前記複数のユーザ固有マルチファクタ条件のうちの前記特定のユーザ固有マルチファクタ条件が満たされるとき、前記車両の１つ以上の機能のアクセス性を構成することと、
   を実行させる、コンピュータプログラム。
9. 前記車両に更に、
   第１のデバイスの第１の近接性ステータスと第２のデバイスの第２の近接性ステータスが、前記複数のユーザ固有マルチファクタ条件のうちの前記特定のユーザ固有マルチファクタ条件が満たされることを示すとき、前記車両の１つ以上の機能に対するアクセスを、前記１人の特定のユーザに対して許可させる、
   請求項８に記載のコンピュータプログラム。
10. 別の複数のユーザ固有マルチファクタ条件のうち、複数の特定のユーザのうち１人の他の特定のユーザに関連付けられる１つのユーザ固有マルチファクタ条件は、前記他の特定のユーザに対して特有の前記車両の１つ以上の機能へのアクセスを許可するよう満たされる、
    請求項８に記載のコンピュータプログラム。
11. 前記車両に更に、
    前記ポリシーの時間制約、前記ポリシーの位置制約及び前記ポリシーのログイン制約のうちの１つ以上を、前記車両の１つ以上の機能のうちの少なくとも１つに適用させる、
    請求項８に記載のコンピュータプログラム。
12. 前記時間制約は、前記１人の特定のユーザが前記機能にアクセスすることを許可される、前記１人の特定のユーザに対して特有の期間を含む、
    請求項１１に記載のコンピュータプログラム。
13. 前記位置制約は、前記１人の特定のユーザが前記機能にアクセスすることを許可される、前記１人の特定のユーザに対して特有の地理的位置を含む、
    請求項１１に記載のコンピュータプログラム。
14. 前記車両に更に、
    第１のモバイルデバイスが存在しないか、第２のモバイルデバイスが存在しない場合、前記第１のモバイルデバイス、前記第２のモバイルデバイス及び前記車両のうちの１つ以上のユーザインタフェースを介して通知を生成する、
    請求項１１に記載のコンピュータプログラム。
15. 前記車両の前記１つ以上の機能の少なくとも１つは、ドアロック解除機能、トランクロック解除機能、イグニッション機能、ユーザ設定機能、車両操作機能及び置換デバイスペアリング機能のうちの１つ以上を含む、
    請求項８に記載のコンピュータプログラム。
16. 請求項１乃至１５のいずれか一項に記載のコンピュータプログラムを記録するコンピュータ読取可能記録媒体。

Images