セキュア・テレマティクス
セキュリティ制御装置を含むテレマティクス・システム。セキュリティ制御装置は、車両内のリソースへのセキュア・アクセス及び制御使用を確実に責任を持って行う。セキュリティ制御装置に依存するセキュリティ手段は、例えば、アプリケーション開発業者のような証明書の所有者に権利を許可するデジタル証明書をベースとすることができる。アプリケーションを車両リソースと一緒に使用する場合には、証明したアプリケーションが、車両のリソースのセキュリティ及び車両ユーザの安全に決して悪影響を与えないように手順が実施される。利害関係を有するエンティティ間の関係は、セキュア車両リソースへのアクセス及びその使用を促進し、サポートするように確立される。エンティティとしては、車両メーカ、通信サービス・プロバイダ、通信装置販売業者、車両サブシステム供給業者、アプリケーション開発業者、及び車両の所有者／ユーザ等がある。エンティティのうちの少なくともいくつかは、車両リソースのセキュア・アクセス及び使用を強化し、容易にするように確立された連合のメンバーであってもよい。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はテレマティクスに関し、特に車両内での専用リソースの使用を含む機密保護通信に関する。
【背景技術】
【０００２】
商用車両及び個人用車両の使用目的を、単なる輸送手段から通信ハブ手段に拡張するのに役に立つ種々の技術が考案又は促進されてきた。車両は、安全、運行、情報収集、娯楽及び教育に関連する目的を含む多数の目的を提供し又は容易にするために、遠隔システムと無線で通信することができる。車両内及び車両との通信は、通常、車両の外部からの通信を送受信することができる携帯電話又は他の通信ソース／デバイスを含む。
【０００３】
車両通信を改善するためにかなりの努力が行われてきたが、テレマティクス分野の大きな潜在能力を実行するにはかなりの障害が依然として存在している。車両通信は、車両内に常駐するハードウェア及び／又はソフトウェアを含むことができる多数のシステム及びデバイスを必要とする場合がある。これらのものは、所有者又は借り手のようないくつかのエンティティに特有なものである場合がある。車両メーカ及びその他の当事者は、第三者が専用システムを使用することができるようになることを非常にいやがる。自動車メーカの場合には、車両インタフェース、記憶メモリ、車両バス及び車両デバイス内に多数の所有権を有する場合がある。第三者が不法に又は制御できない状態でアクセスできると、このようなシステムの安全性及び保全性が心配になる。十分な経済的及び財政的理由がなければ、第三者によるアクセス及び使用を許可することはできない。それ故、車両を含む通信を容易にする物理的インフラストラクチャを提供するばかりでなく、投資に対する経済的動機及び十分な利潤を提供することも重要である。
【０００４】
テレマティクスの潜在能力を発揮させるには、自動車メーカ、携帯電話を含む通信デバイスの製造業者、アプリケーション開発者及び通信サービス・プロバイダを含む多数のエンティティ間の協力が必要になる。これらエンティティのうちの１つ又は複数は、考慮に入れなければならないし、保護しなければならない専有の技術又は利害関係を有している。例えば、ハンドセット製造業者はハンドセットに関連しているし、車両メーカは車両デバイスに関連している。専有権を保護する代わりに、専有車両システム及び技術を利用するやむにやまれぬ用途が出現するまで、テレマティクスの開発は順調に進まないだろう。さらに、車両自体が、人体の安全性に対する信頼性が非常に重要な複雑なシステムである。試験し、配備された車両システムに何らかの修正を行った場合には、新しい危険が発生する。一方、専用システムの機密を保護し、種々のエンティティにより共有できるようになった場合には、セキュリティの問題はもはや欠点ではなくなり、車両通信に関連する全コストを低減することができる。さらに、車両内の専用システムへの受け入れ可能なアクセスを使用することができるようになれば、豊富なアプリケーションのセットを開発することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
それ故、多数の及び種々の車両通信に関連するエンドユーザを含む専用システム及び多数の当事者の利害関係を保護するためのフレームワークを提供できれば有利である。エンドユーザの利害関係は、ユーザのプライバシーの少なくともいくつかのアプリケーション保護を含むことができる。金融取引を行うために車両内のリソースを使用した場合には、エンドユーザのプライバシーは保護される。適当なセキュリティ及び／又はプライバシー保護の他に、十分な報酬を含む車両に関連するリソースに自由にアクセスすることができ
るようにする動機を提供する種々の当事者間に関係を確立することが望ましい場合もある。
【課題を解決するための手段】
【０００６】
本発明は、車両内の専用リソースを含むリソースを使用するためのシステム及び方法を提供する。このような使用を行うには、車両に搭載してある、又は車両内に設置することができるリソース内に専用及びその他の利害関係を有するエンティティ間に関係を確立する必要がある。関係の確立は、車両内の専用及び／又は非専用リソースと一緒に使用するリソースの承認、及び承認したリソースだけを使用するという確認と一緒に種々のエンティティ間の補償規定の定義を含む。
【０００７】
専用リソースは、下記のもの、すなわち、車両バス、車両デバイス、インタフェース、サブシステム、車両内の記憶メモリ、車両内で実行するアプリケーション、連結ハードウェア／ソフトウェア及び通信デバイスのうちの１つ又は複数を含むことができる。車両内のデジタル・バスは、ＭＯＳＴ、ＩＤＢ１３９４、ＴＴＰ、ＣＡＮ、ＦｌｅｘＲａｙ、ＬＩＮ、ＳＡＥ Ｊ１９３９、ＳＡＥ Ｊ１７０８／１５８７、ＳＡＥ Ｊ１８５０、ＩＳＯ９１４１、及び多数の専用及び非専用リソースと通信する共通なバスを含む。共通バスは、上記バス技術のうちの１つ又は複数をベースとすることができる。また、共通バスは、無線技術により実施することもできる。専用サブシステム及び／又は車両デバイスは、種々の電子制御ユニット（ＥＣＵ）、ナビゲーション全地球測位システム（ＧＰＳ）、インフレータ・サブシステム又はデバイス、携帯情報端末（ＰＤＡ）、ラップトップ・コンピュータ、車両監視システム（ＶＭＳ）、及び事故及び緊急通知アラーム（ＡＥＮＡ）を含むことができる。インタフェースは、多数の及び種々のアプリケーション・プログラミング・インタフェース（ＡＰＩ）を含むことができる。通信サブシステムは、認可及び非認可通信チャネルを使用する無線技術ネットワークと通信するポータブル又は携帯電話及びサブシステムを含むことができる。専用及び／又は非専用アプリケーションは、車両に供給される娯楽、車両からのデータ収集、車両に供給される教育情報、車両内の１つ又は複数のサブシステム及び／又は車両デバイスが使用するために車両に送信される情報に関連するアプリケーションを含むことができる。これらのアプリケーションは、セキュリティ・サービス、多重ユーザ・サービス、車両間通信サービス、地理的サービス、定期サービス、通信サービス、及び商用サービスに関連するものを含む種々の分野又はエリア内のものであってもよい。
【０００８】
相互に受け入れることができる条件に基づいて関係を形成することができるエンティティは、一次エンティティとしての車両メーカ、及びアプリケーション開発業者／プロバイダ、政府機関、通信、金融、ビジネス及び消費者サービス・プロバイダ、製品及び専用サブシステムのプロバイダ、及び／又はデバイス供給業者、及び車両の所有者／ユーザを含む他のエンティティ等がある。これらのエンティティのうちの２つ以上が協力する条件は、１つ又は複数の固定支払い、少なくとももう１つのエンティティへの少なくとも１つのエンティティが行う使用料支払い、地理的要件、リソース使用制限、及び非適応への救済策をベースとすることができる。必要な関係の確立に関連する一番重要な要因は、このようなリソース及びリソースのセキュリティに関連するこれらの安全性を考慮に入れた場合の相互に使用するためのリソースの認定を含む。エンティティのうちの少なくともいくつかは、メンバーであるエンティティが相互作用の一部として、セキュリティ要件及びプロトコルを受け入れる連合に加入したセキュリティ・アーキテクチャが実施する連合のメンバーになることができる。
【０００９】
システムのリソースは、車両に対して無線通信を行うことができる１つ又は複数の通信サブシステムを含む。これらの通信サブシステムは、その関連するインタフェース及び無線ＬＡＮ（ローカル・エリア・ネットワーク）のような１つ又は複数の適当な無線技術と
通信できるようにするための他の装置と一緒に携帯電話を含むことができる。システムは、また、車両バスに接続している車両デバイスから入手した情報にアクセスすることができる車両ゲートウェイを含むこともできる。好ましい実施形態の場合には、車両ゲートウェイは、多数の専用及び／又は非専用リソースと通信することもできる共通バスと通信する。
【００１０】
システムは、また、共通バスに接続しているセキュリティ制御装置を含む。セキュリティ制御装置は、所望のセキュリティを行うため、特に２つ以上のエンティティによるリソースの使用の制御を行うために、すべての情報が通過するハブとして機能することができる。セキュリティ制御装置は、エンティティ及び／又はリソースのセキュリティ認証に関連していて、エンティティ及び／又はリソース間のセキュア・チャネルの確立を容易にし、バス及び帯域幅調停サービスを提供する。セキュリティ制御装置は、本質的には、システム内でスイッチとして機能し、他のリソース又はサービスに対して代理として機能することができる。エンティティ及び／又はリソース間のすべてのトラヒックは、経路指定されるか、又は始動はセキュリティ制御装置により仲介される。セキュア・セッションが確立された後で、セキュリティ制御装置は、トラヒックを監視するために必要な場合だけ介入しさえすればよい。監視は、例えば、トラヒックが、１つ又は複数の特定のアプリケーションの所定のプロファイルに適合しているかどうかの確認に関連することができる。ある実施形態の場合には、セキュリティ制御装置は、ハブ又はスイッチとして共通バスに内蔵されていないで、確立した関係に関連する条件が満たされていることの確認に関連してその制御を行うために、共通バスと通信し、セキュリティに関連する活動を監視する。
【００１１】
好ましい実施形態の場合には、システムは、さらに、セキュリティ制御装置が認証サービスを提供することができる多数のインタフェース・モジュールを含む。これらのサービスは、通信サービス・モジュール、人間／機械インタフェース・サービス・モジュール、及び車両サービス・モジュールとして識別することができる。通信サービス・モジュールは、通信に関連するリソースへのアクセスを保護し、調停する。ヒューマン・インタフェース・サービス・モジュールは、表示及びオペレータの介入又は関与に関連するリソースへのアクセスを調停する。車両サービス・モジュールは、１つ又は複数の車両バスに接続している車両デバイスから入手した情報へのアクセスに関連する補助を含む車両ゲートウェイ・サービスへのアクセスを制御する。ある実施形態の場合には、これらのインタフェース・モジュールはセキュリティ制御装置に内蔵される。
【００１２】
システムの実施又はシステムに関連するステップ、動作及び／又は手順については、エンティティはその関係を確立する条件を受け入れる。これらの条件は、３つ以上のエンティティの条件と同じであってもよいし、異なるものであってもよい。例えば、関係の確立は、車両メーカ及びアプリケーションの所有者、又は専用車両デバイスと一緒に使用される、又は実行することができるアプリケーションに専用の利害関係を有する他のものを含むことができる。もう１つの関係を、この同じ自動車メーカと、アフター・マーケット車両デバイス又はアドオン車両デバイスのような専用サブシステム供給業者との間に確立することができる。自動車メーカ及びサブシステム供給業者が受け入れた条件は、自動車メーカとアプリケーション開発業者又は他のアプリケーション供給エンティティとの間の関係を確立する条件とは異なるものであってもよい。これに関連して、このようなアプリケーション・エンティティは、自動車メーカとサブシステム供給業者との間の関係を確立する条件と同じか又は異なる条件を含むサブシステム供給業者との関係を確立することができる。これらの条件は補償及びリソース使用に関連することができる。
【００１３】
関係のこのような確立は、また、システムが使用する承認、信任状又は証明書を発行することができる認証局の授権を含むことができる。認証局は、基本的に、車両内で使用するために承認されたリソースに対して機密保護状態で証明書を発行することについて責任
を持つ。このようなリソースは、専用のものでも非専用のものであってもよい。これらのリソースは、他のリソースを使用するアプリケーションを含むことができる。認証局は、車両メーカのような関係を確立するグループ内に含まれるエンティティのうちの１つであってもよく、又は認証局は独立の第三者であってもよい。認証局は２つ以上であってもよく、また認証局は、車両セキュリティ・ドメイン内のリソースに信任状を発行する車両内に常駐することができる。セキュリティ制御装置自体は、認証局として機能することができ、車両サブシステム又は他の車両リソースに証明書を発行することができる。承認されたアプリケーション及び／又はサブシステムに対して証明書を発行する他に、認証局は１つ又は複数のエンティティ自身の証明に関与することもできる。
【００１４】
ある実施形態の場合には、証明プロセスは、支持している所望のセキュリティに関連する１つ又は複数の署名鍵により初期化される認証局を有する。認証局は、公開鍵及び秘密鍵のペアを生成することができる。公開鍵は、セキュリティ制御装置に渡され、この制御装置に提出される１つ又は複数の証明書の署名を確認又は認証するために使用することができる。認証局は、また、１つ又は複数のアプリケーションが証明書を要求することができるようにする鍵をアプリケーション開発業者に発行することができる。例えば、認証局は、アプリケーション開発業者に送る少なくとも証明書要求秘密鍵を生成することができる。アプリケーション開発業者は、認証局に送られるアプリケーション証明書要求を生成するためにこの秘密鍵を使用する。認証局は、証明書に対する要求を許可するかどうかを決定する。この決定に関連して、いくつかの手順を実施することができる。認証局はこれらの手順を実施することができる。別の方法としては、アプリケーション確認機関のような他のエンティティもこれらの手順を実施することができる。このような機関は、アプリケーション開発業者のセキュリティの実行の監査、及び行動及び安全性を考慮するための多数のシステム環境内でのアプリケーションの試験に関連するステップを実行することができる。承認された場合には、認証局は証明書を発行することができる。証明書は、証明書の所有者への一意の識別子、アプリケーションに割り当てられた優先順位、証明書の有効期間、証明書が有効であると考えられる地理的位置又は他の位置、アプリケーションが正しく機能するために通信しなければならない他のリソース及び／又はエンティティの識別又は記述、及びアプリケーションを使用することができるＡＰＩのようないくつかの特性及び／又は権利を含むことができる。
【００１５】
証明プロセスは、補償類似クレジット又は関連エンティティが同意した１つ又は複数の条件の一部として支払うことができる特許使用料と相互関係を照合される確立された関係の他の側面と関連することもできる。証明書は、また、資格を失ったアプリケーションに対して無効にすることもできる。セキュリティ制御装置はリボケーション情報を含んでいて、そのためその認証プロセス中、セキュリティ制御装置は、特定のアプリケーションに対する証明書が無効にされているかどうかを判断することができる。
【００１６】
アプリケーションに対して証明書が許可された後で、証明書の内容によるアクセス及び使用が許可される。この機能の一部として、セキュリティ制御装置は、このようなアプリケーションが要求したアクセスを監視することができる。セキュリティ制御装置が許可した後で、アプリケーションは、証明書に表示されている特性及び／又は権利に基づいて、車両内の１つ又は複数のリソースと一緒に動作することができる。すでに説明したように、アプリケーションは、多数の使用又は機能に対する多数の及び種々の分野で多くの形をとることができる。
【００１７】
上記要約を読めば、本発明の多くの利点を容易に理解することができるだろう。本発明は、アーキテクチャ及び方法論を供給することにより、車両内でのテレマティクスの使用を拡張するので、所望の動機及びセキュリティに適合することができる。車両通信のための多数及び種々のアプリケーションの開発が奨励され、支持されている。車両リソースの
使用は、本発明のフレームワークにより強化することができる。乗客の安全性及び便宜性は、車両及びその乗客と通信するためのさらに多くのまた異なる方法を容易に行うことができるようにすることにより促進される。リソースを共有すれば、車両のユーザにさらに多くのサービスを提供することができ、同時にコストを低減することができる。より詳細に説明すると、本発明は車両リソースの統合性を保護する。ユーザ及び車両情報のプライバシーがよりよく保護される。テレマティクス・アプリケーションにさらに安全にアクセスし、車両内のリソースをさらに安全に使用することができる。アプリケーション・レベルで所望のセキュリティの実行に関連する基準及び手順が提供される。車両に関連する機能の選択及び機密保護の実行が促進される。アプリケーションの使用及び加入に関する支払いのような追加の歳入の流れのための機会が促進される。セキュア遠隔診断機能及び車両のソフトウェアのセキュア・アップグレードも含まれる。モバイル広告及び顧客に優しいプログラムを含む新しいビジネス又は市場モデルを容易に作成することができる。複数の車両バスが、さらに丈夫になり、他の車両のリソースとの通信に適合することができる。通信経路のインテリジェントでセキュアな選択も行われる。消費者及び／又はビジネスへのサービス及び／又は製品の供給に関連するリソースにアクセスする場合に、ユーザのプライバシーを保護する連合に加入したセキュリティ・フレームワークを使用するセキュリティ手段を実施することができる。
【００１８】
下記の説明を読めば、特に添付の図面を参照しながら読めば、本発明の他の利点を容易に理解することができるだろう。
【発明を実施するための最良の形態】
【００１９】
図１を参照すると、この図は車両により位置を決定することができるテレマティクス・セキュア・システム２０を示す。システム２０は、車両へ及び車両から通信を行うための装置又はサブシステムを含む。内蔵されたセルラー・トランシーバ及び最近開発された装置を含む多数の装置のうちの１つ又は複数を使用することができるが、そのうちのくつかの装置について説明する。音声及びデジタル・コマンド及びデジタル・データのようなデジタル及び／又はアナログ情報を送信／受信するために、携帯電話２４を車両内に保持することができる。携帯電話２４を使用すれば、車両の外で車両のリソースと通信したい遠隔ソースへ／からのものを含む無線通信を行うことができる。携帯電話２４は物理的に保持することができ、ドッキング／インタフェース・サブシステム２８により車両通信経路に電子的に適合することができる。このサブシステム２８を使用すれば、特に携帯電話２４が手ぶらモードで動作している場合、車両ユーザ（運転者及び／又は乗客）との通信を容易に行うことができる。携帯電話の種々の構造及びモデルの中から選択することができる携帯電話２４のように、ドッキング／インタフェース・サブシステム２８は、選択し使用する特定の携帯電話２４と互換性を有する１つ又は複数の異なる装置であってもよい。１９９４年７月２６日付けの米国特許第５，３３３，１７７号、１９９６年７月９日付けの米国特許第５，５３５，２７４号、２００２年４月２３日付けの米国特許第６，３７７，８２５号、及び２００２年１月２２日付けの米国特許第６，３４１，２１８号を含む本出願の所有者と同じ譲受人に譲渡された特許に、いくつかのドッキング／インタフェース・サブシステムの実施について開示されている。
【００２０】
ある実施形態の場合には、ドッキング／インタフェース・サブシステム２８は、通信サービス・モジュール３２と通信するか、又はこのモジュールに関連付けられている。モジュール３２は、車両内の又は車両に関連する通信リソースへのアクセスを保護し、調停する実行可能なプログラム・コードからなるソフトウェアであってもよい。通信サービス・モジュール３２に関連することができる基本機能としては、車両に関連する他のリソースに対するインターネットへの通信経路のサポート、車両内の１つ又は複数のバス上のセキュア通信への貢献、故障通知の出力、通信関連リソースの監視及びロギング使用、通信リソースに対する使用規則の施行、及び車両に関連するリンク及び／又はリソースの使用に
関連する認証及び許可を含むセキュリティ制御に関連するツールの管理等がある。通信サービス・モジュール３２は、また、２０００年９月１９日付けで、同様に本出願の譲受人に譲渡された米国特許第６，１２２，５１４号に開示されているように、通信リンクの自動又はインテリジェントな選択をサポートするために使用することもできる。車両に内蔵させることができる他の無線通信サブシステムとしては、無線ＬＡＮ３６及び無線ＰＡＮ３８がある。携帯電話２４のように、無線ＬＡＮ３６及び無線ＰＡＮ３８サブシステムは、通信サービス・モジュール３２により正しく調停及び保護されている車両への送信、また車両からの送信を行うために、互換性を有するインタフェース（例えば、ドッキング／インタフェース２８）と通信することができる。
【００２１】
通信リソースの他に、システム２０は、オペレータ又は人間相互作用又は制御を行うことができるようにヒューマン・インタフェース４０を含むことができ、また視覚的表示及び／又はオーディオ出力により、車両のユーザに情報を提供することもできる。ヒューマン・インタフェース４０は、多数の入力／出力機構又はデバイスを有することができる。これらの機構又はデバイスは、タッチ又は接触によるようないくつかの知覚的入力を受信するための適当な技術により実施される触覚及び／又は生体認証入力サブシステム４４を含むことができる。触覚デバイスは、ユーザが所望の制御情報を入力したり、既存の設定を修正したりすることができるようにするボタン、スイッチ、タッチ点／スクリーンのようなプログラム可能な入力素子を含むことができる。視覚情報又は走査情報に関連する入力も、これらのサブシステム４４のうちの１つ又は複数を使用して供給することができる。１つ又は複数の音声／オーディオ入力又はサブシステム４８も、ヒューマン・インタフェース４０の一部であってもよい。これらのサブシステム又は技術を使用することにより、音声入力を、音声認識機能を始動、又はそうでない場合には、制御する際に役に立つ所望の制御／コマンド目的に対して受信することができる。このようなサブシステム４８からのオーディオ出力は、娯楽、教育、予め記録した音声プロンプト、及び音声入力をベースとする応答及び指示（テキスト音声変換出力）の供給を含む他の情報の必要な目的を含む任意の数の目的のために使用することができる。１つ又は複数のディスプレイ５２は、ヒューマン・インタフェース４０の一部であってもよい。ディスプレイ又はディスプレイ５２のうちの１つは、位置関連情報を提示するためのナビゲーション目的のものであってもよい。ディスプレイ又はディスプレイ５２も、要求した車両デバイス情報を表示するために使用することができる。媒体入力５６は、記憶媒体としてのハード・ディスク、ＤＶＤ及びＣＤ−ＲＯＭ機械、及びマップ・データベースのような車両内で所望の媒体を見たり及び／又は聞いたりすることができるようにする１つ又は複数のサブシステムを含むことができる。通常、ヒューマン・インタフェース４０は、車両の一部であり、車両メーカ専用の１つ又は複数の構成要素及び／又はサブシステムを含む。
【００２２】
通信リソースのように、ヒューマン・インタフェース４０は、多くの点で通信サービス・モジュール３２に類似しているマン／マシン・インタフェース・サービス・モジュール６４を含む。マン／マシン・インタフェース・サービス・モジュール６４は、１つ又は複数の車両バス上のセキュア通信をサポートし、ヒューマン・インタフェース４０に関連する故障通知を行い、オペレータ・サブシステム及び構成要素に関連するリソースの使用、ヒューマン・インタフェース４０に関連する警察使用規則を監視し、ロギングすることができ、またヒューマン・インタフェース４０の構成要素／サブシステムの正しい使用の確認に関連するツールの監視及び管理に関連することができる。
【００２３】
また、多数の他のサブシステムをテレマティクス・セキュア・システム２０の一部として固定状態に又は取り外すことができるように組み込むこともできる。サブシステムは、元来の車両装置の一部として提供することもできるし、後で車両の付属装置として追加することもできる。これらのサブシステムは、専用リソースであっても、非専用リソースであってもよい。このようなサブシステム内の専用利害関係は、車両メーカ自身内に常駐す
ることもできるし、又は車両へのアクセスが許可されている他の当事者内に常駐することもできる。サブシステムは、車両に関連する地理的情報又は位置情報を提供する全地球測位システム（ＧＰＳ）７０、１つ又は複数のコンピュータ７４、及び記憶メモリ７６を含むことができる。１つ又は複数のコンピュータ７４は、ポータブル・タイプのものでもよいし、車両の乗客による使用のために車両から取り外したり、車両に組み込むことができるタイプのものであってもよい。コンピュータ７４は、携帯情報端末（ＰＤＡ）、ラップトップ、又は任意の他のインテリジェント及び／又は処理ユニットを含むことができる。コンピュータ７４は、システム２０の他のリソースに関連する通信、及び車両外部の通信を送受信するために使用することができる。記憶メモリ７６は、車両内及び／又は外に位置する他のリソースの使用に関連する専用データ及び／又はプログラム・コードを含むことができる。記憶メモリ７６は、また、１つ又は複数のハード・ディスク及び／又はＣＤ−ＲＯＭのような取り外し可能なメモリを含むことができる。
【００２４】
サブシステムは、また、車両内でデバイス８８が生成することができる、又は車両内でセキュリティ手段に関連する又はそれをサポートするエンティティ、又は任意の他の認可された第三者が生成することができる署名入り又は署名無しの情報を記憶し、及び検索する働きをする承認リポジトリ７８を含むことができる。このような情報は、１つ又は複数の車両リソースにより、実行中又は実行しようとしている通信、取引及び／又は他の活動に関連するエンティティに関連する特性に関連する情報又は声明を含む承認を含むことができる。承認の内容は、１人又は複数のユーザ又は関連する当事者のプライバシーを保護しながら、所望のアクセス及び／又は使用を許可するのに十分な情報を供給するために他の方法で変更することができる。ちなみに、通信に関連する特定の承認、権利、義務及び／又は能力に基づいて、取引及び／又は他のものを定義又は記述することができる。
【００２５】
承認リポジトリ７８は、政策決定エンジン８２及びデータベース９０を含むことができる。政策決定エンジン８２は、複数の記憶している情報のうちのどの情報を特定の要求に対して提供するのか決定する。その決定を行う際に決定エンジン８２が依存することができる要因は、要求者の識別、要求されている情報及び適当なユーザの承諾の存在を含むことができる。１つ又は複数の決定は、第三者との通信からの情報又は結果をベースとすることもできる。また、提供のための追加情報を入力するために、第三者を利用することもできる。また、データベース９０内に追加情報を記憶するために、またこのような追加情報を受け入れるかどうかを決定するために、要求を処理するように決定エンジン８２を構成することもできる。署名のある又は署名のない情報を、特定のサービス又は製品プロバイダ、すなわち目標プロバイダの使用の許可又は拒否に適用することができる。データベース９０は、特定のサービス又は製品又は情報の入手に関連するアクセスの許可に関連する任意の数の署名のある又は署名のない承認を記憶することができる。これらの承認は、政策決定エンジン８２の要求に対して使用することができ、データベース９０は、決定エンジン８２の許可に対して又は許可によってだけこの情報を公開するように構成されている。データベースは、ＬＤＡＰ、ＸＭＬ及びＳＱＬを含む関連及び／又は目的データベースのような任意の数のデータ記憶技術を使用して実施することができる。承認リポジトリ７８に対する適当なアプリケーションについては、本明細書中のセキュア・テレマティクス・システム２０の使用の説明のところで記述する。
【００２６】
車両内の追加のリソースは、車両ゲートウェイ８０を含むことができる。車両ゲートウェイ８０は、従来から、１つ又は複数の車両デバイス８８が接続しているか、又は電子制御ユニット（ＥＣＵ）８６により通信する１つ又は複数の車両バス８４と通信する。各ＥＣＵ８６は、特定の車両デバイス８８を含む１つ又は複数のデジタル・バス８４に対してインタフェースとして機能し、このような各ＥＣＵは、個々に８６ａ、８６ｂ、８６ｃ．．．と表示することができる。ＥＣＵ８６は、本体制御装置、シャーシ制御装置、エンジン制御装置、変速機制御装置、及びテレマティクス制御装置のような多数の異なる制御サ
ブシステムのうちの１つ又は複数を含むことができる。本体制御装置は、通常、座席、ＨＶＡＣ、インストルメント・クラスタ、パワーウィンドウ、電動ドア及び他の車両デバイスのようなすべての車内装置を制御する。車両デバイス８８は、別々に８８ａ、８８ｂ、８８ｃ．．．のように表示することができる。車両バス８４は、１つ又は複数のデジタル・バスであってもよく、ＭＯＳＴ、ＩＤＢ１３９４、ＴＴＰ、ＣＡＮ、ＦｌｅｘＲａｙ、ＬＩＮ、ＳＡＥ Ｊ１７０８／１５８７、ＳＡＥ Ｊ１９３９、ＳＡＥ Ｊ１８５０、ＩＳＯ９１４１と呼ばれる周知のバスを含むことができる。車両デバイス８８は、エンジン・モニタ、エンジン温度センサ、圧力センサ、エアバッグを作動するためのインフレータ・システム及び／又は（例えば、シート・ベルトに張力を与えるための）車両張力生成デバイスを含むことができる。車両ゲートウェイ８０は、車両バス８４へのアクセス及びその使用を制御する。ちなみに、車両ゲートウェイ８０により、１つ又は複数のバス８４を通して特定の１つ又は複数のバス８４に接続している１つ又は複数の選択したデバイス８８にコマンドを送ることができる。車両ゲートウェイ８０は、また、無線通信インタフェース、及びアンテナ等による直接受信遠隔無線入力を有することができる。このような入力は、車両のドアのロック／アンロック及び遠隔車両エンジン・スタートをサポートする際に使用するデバイスを含む車両デバイス８８に制御信号を送るために使用することができる。
【００２７】
車両サービス・モジュール９２は、車両ゲートウェイ８０と通信する。通信サービス・モジュール３２及びマン／マシン・インタフェース・サービス・モジュール６４のように、車両ゲートウェイ８０に関連する通信は、車両ゲートウェイ制御車両バス８４及び車両デバイス８８へのアクセスを制御するための車両サービス・モジュール９２を通る。車両サービス・モジュール９２の機能としては、１つ又は複数の車両又はテレマティクス・バス８４上のセキュア通信のサポート、車内無線通信（例えば、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ）のようなＰＡＮ）の実行への貢献、要求を外部におくるための車両バス・アクセスの調停、車両ゲートウェイ動作に関する故障通知の提供、車両ゲートウェイ８０、車両バス８４及び／又は車両デバイス８８の使用の監視及びロギング、車両ゲートウェイ８０と通信するこのようなリソースの使用に関連する規則の施行、及びアクセス・キー及びアクセスを承認する証明書のようなセキュリティの提供に関連するツールの管理等がある。
【００２８】
機密保護状態で通信ができるようにするために、好適には、システム２０は、車両内の全部ではないにしても多数の通信可能なリソースが通信する共通バス９６を含むことが好ましい。この実施形態の場合には、共通バス９６は、これらのリソースをセキュリティ制御装置１００にリンクすることができる。セキュリティ制御装置１００は、通信可能なリソースへの通信が通過するハブ又はスイッチの働きをする。図１には、セキュリティ制御装置１００への独立ライン又は接続として表示してあるが、一緒にリンクした場合、このようなすべてのラインは共通バスを表すことを理解されたい。共通バス９６は、車両バス又はデジタル・バス８４を供給する又は実施する技術を含む多数の使用可能なバス技術のうちの１つをベースとすることができる。共通バス９６は、また、無線技術により実施することもできる。
【００２９】
共通バス９６は、物理層及び論理層を含むように定義することができる。共通バス９６の物理通信層は、一緒にシステム２０のいくつかのリソースに接続している。車両メーカは、通常、このようなバスの特性を制御する。共通バス９６は、少なくとも下記の機能、すなわち、広くサポートでき、多重ポートを有し、ピアツウピア機能を使用することができるように、アプリケーション、オープン・アーキテクチャ、標準化フィーチャをサポーするのに十分な帯域幅を有するものでなければならない。論理層は、共通バス９６上のリソースが相互に通信することができる方法を提供する。論理層は、異なる製造業者からの異なるリソースをバスに正しくリンクし、バスと通信することができるように構成される
。論理層は、デバイス間、サービス間、いくつかのサービスに対する要求を容易に行うことができるようにするアプリケーション・プログラム・インタフェース（ＡＰＩ）間で通信を行うことができるようにするために、いくつかの異なるプロトコルを含むことができる。サービスは、他のデバイスと通信するための自分自身のＡＰＩを定義することができる。定義することができるＡＰＩは、リソース間又はリソースとハブの間にセキュア接続を確立するためのセキュリティ制御装置１００、共通バス９６上のリソースに対するインターネット通信及び無線通信を可能にする通信サービスＡＰＩ、車両に対する状態検索及び制御サービスを可能にする車両ゲートウェイ・サービスＡＰＩ、位置情報の送信を可能にするためのＧＰＳ７０用のＡＰＩ、オペレータ・ユニット４０により情報を表示するための表示ＡＰＩ、リソース機能を登録するための登録関連ＡＰＩ、及び情報の一般的配布のための放送関連ＡＰＩを含む。いくつかのＡＰＩはすでに入手可能であり、例えば、ＡＭＩ−Ｃ（Ａｕｔｏｍｏｔｉｖｅ Ｍｕｌｔｉ−Ｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ Ｃｏｌｌａｂｏｒａｔｉｏｎ）は、車両ゲートウェイ８０と通信するための定義済みの一組のプロトコルを有している。システム２０に関連するセキュリティ・プロトコルは、ＡＭＩ−Ｃ及び他の現存のプロトコルと互換性を有する。
【００３０】
テレマティクスの成長を成功させるには、車両の動作が悪影響を受けることがないように、車両リソースへの不法な要求から保護する必要がある。車両通信は、本質的にリスクを伴わないもの、及び低いリスク及び中程度のリスクのような間に異なるリスク・レベルを有するリスクが高いものに分類することができる。リスクの程度は、情報の感知性、情報のプライバシー、及び不法な通信が存在する場合起こり得る損害の影響の程度を含む多数の要因をベースとすることができる。リスクは、送信機能に関連する１つ又は複数のリソース、受信機能に関連する１つ又は複数のリソースを含む主要な要因に基づいて査定することができる。主要なリスク要因は、送信に関連する特定のアプリケーションに関連する。アプリケーションは、車両デバイス又は装置の構成の変化、車両状態の表示、車両のファームウェアのアップグレード、車両診断の実行、１つ又は複数のアプリケーションのダウンロード、媒体情報のダウンロード、宣伝のダウンロード、位置情報の入手、及びセキュリティ承認の更新又はチェックを含むことができる。
【００３１】
ある実施形態の場合には、セキュリティ制御装置１００は、１つ又は複数のセキュア・プロセッサ、及びセキュア・プロセッサ内に組み込まれる又は内蔵されるＧＰＳ受信機を含むことができる。この組合わせにより、特にＧＰＳ情報を１つ又は複数の特定のセキュリティ制御装置の動作に正確に関連づけたい場合には、正しいセキュア動作を行うことができる。好適には、セキュリティ制御装置１００は、システム２０内に、リソースを含むすべてのトラヒックが通過する中央ハブ又はスイッチとして構成することが好ましい。セキュア・セッションが確立した場合には、セキュリティ制御装置１００は、１つ又は複数のアプリケーションを含むデータ又は他の情報を監視するために必要に応じて介入するだけでよい。セキュリティ制御装置１００は、１つのチップとして実施することができる。セキュリティ制御装置１００の代表的責任及び機能は下記の通りである。
【００３２】
ユーザの認証：セキュリティ制御装置１００は、多数のログインの記憶に関与することができ、ログインの実行に関連して認証情報を入手することができる。セキュリティ制御装置１００は、認証サービス、エンティティ、又は各ログインに対する一組の信任状を維持し、各ログインの識別についてセキュリティ制御装置１００に通知することができる他のリソースを信任することができる。このようにして、セキュリティ制御装置１００は識別を管理する。例えば、車両が点火した場合及びタクシー・フリートの所有者が認証サービスを提供した場合、ログインを行うことができる。他の例を挙げると、スマートカードは、中央病院をセキュリティ制御装置１００が信任している認証サービスとして使用して、ログインを行うことができる。セキュリティ制御装置１００は、個人識別番号（ＰＩＮ）スマートカード、パスワード又は生体認証情報（ｂｉｏｍｅｔｒｉｃ ｉｎｆｏｒｍａ
ｔｉｏｎ）を含む多数の形のうちの１つ又は複数内にユーザ識別情報を記憶することができる。この情報は、携帯電話２４、Ｗ−ＬＡＮサブシステム３６及び／又はＷ／ＰＡＮサブシステム３８のような通信サービス・モジュール３２と通信している１つ又は複数の装置又はデバイスを通して、又は、別の方法としては、ヒューマン・インタフェース４０から車両ユーザ識別情報を受信することができるマン／マシン・インタフェース・サービス・モジュール６４を通してセキュリティ制御装置１００に送ることができる。
【００３３】
セキュア位置及び時間：内蔵ユニットとして又はそれにより通信する独立型デバイスとして、セキュリティ制御装置１００は、ＧＰＳ受信機（例えば、ＧＰＳ７０）と通信することができる。この受信機は、位置及び時間情報のセキュア・ソースを提供する。ＧＰＳ受信機は、自分が提供する情報への不正変更を根絶するか最小限度に低減するように構成されている。この信任された時間及び位置情報は、車両内のいくつかのリソースに適用されるすべての位置的制限をチェックするために使用することができる。
【００３４】
セキュリティ監視：セキュリティ制御装置１００は、構成中又は認証中に確立したセキュリティ状態が時間が経過しても引き続きそのまま維持されていることを確認するために、リソース間の共通バス９６の活動及び車両バス８４の活動を監視する。例えば、バス活動に関連する時間的条件がある場合には、セキュリティ制御装置１００は、所定の時間イベントが起きた場合、セキュア・チャネル接続を動的に中断する。
【００３５】
バス調停：セキュリティ制御装置１００は、車両内に位置する１つ又は複数のバス上の優先順位の高い活動と優先順位の低い活動間で調停を行う。例えば、緊急事態が発生した場合には、セキュリティ制御装置１００は、デジタル・オーディオ又はビデオのようなすべての優先順位が低い活動を中止することができる。
【００３６】
アプリケーションの認証（公開鍵インフラストラクチャ）：セキュリティ制御装置１００は、登録したリソースに関連するデジタル信任状情報の登録を含む。アプリケーションが共通バスへのセキュア・アクセスを要求した場合には、アプリケーションは、セキュリティ制御装置１００にその信任状、又はそのような信任状を示す証明書を提示する。一般的に、バス９６上のすべてのトラヒックが暗号化されない限りは、共通バス９６へのアクセスは拒否される。セキュリティ制御装置１００は、バス９６上のセキュリティを責任を持って確保する。一方、アプリケーションは、暗号化したトラヒックを聴取する。セキュリティ制御装置１００は、無効な認証局の署名、無効な又は未知の特性、証明書の有効期間切れ又は無効化のような多くの根拠に基づいて、共通バス９６へのアクセスを要求しているアプリケーションを拒否することができる。証明書が本物であると考えられる場合には、セキュリティ制御装置１００は、アプリケーションに、関連する秘密鍵による暗号化操作の実行のような有効なアクセス情報の提示による信任状の主要部分であることを証明するように要求する。応答に成功した場合には、セキュリティ制御装置１００は、将来の取引又は送信のためにアプリケーションとのセキュア・チャネルを開くことができる。インターネット・アプリケーション、ラップトップ使用、ＰＤＡ使用、又は消費者アプリケーションの場合には、セキュリティ制御装置１００による認証のために個々の各アプリケーションが必要になる。デジタル証明書については以下により詳細に説明する。連合に加入したアーキテクチャを含むアプリケーション認証に関連する実施形態についても説明する。
【００３７】
多重鍵：セキュリティ制御装置１００は、また、１つ又は複数の機能にアクセスすることができる２つ以上の鍵又は他のセキュリティ・ツールを要求することができる。アプリケーション又は特定のエンティティ／ユーザを認証するために、２つ以上の要因又は要求が必要な場合がある。例えば、車両の設定を行うには、特定の電話（第１の要因）及びヒューマン・インタフェース４０を通して入力した特定のＰＩＮ又はパスワード（第２の要
因）が必要な場合がある。追加の要因としては、時間、位置情報、オペレータ又はユーザからの生体認証情報（指紋、声紋、顔紋等）又はユーザの認証前にインターネットを通して要求することができるような第三者情報を含むことができる。
【００３８】
多重リソース：セキュリティ制御装置１００は、複数のリソースが１つのアプリケーションに参加又は関連できるようにすることができる。例えば、ナビゲーション・アプリケーションを実行するには、オペレータ・ユニット４０、車両ゲートウェイ８０及びＧＰＳ７０のディスプレイ上で稼働しているソフトウェアの認証が必要になる場合がある。ＧＰＳ位置及びＧＰＳ時間を必要とするアプリケーションの使用を含む多くの他の例を実行することができる。
【００３９】
複数の公開鍵プロトコル及びアルゴリズム：セキュリティ制御装置１００は、いくつかの公開鍵インフラストラクチャ（ＰＫＩ）プロトコルを使用することもできるし、これらを意識することもできる。一方、特定のリソースは、このようなプロトコルの１つだけに関する情報を有することができる。これにより、アプリケーション・プロバイダは、その通信に適している多数のプロトコル及びアルゴリズムから選択を行うことができる。しかし、セキュア・チャネルが確立されると、正しい通信が行われるように１つのアルゴリズムだけを選択することもできる。
【００４０】
キャリーイン・デバイス・ファイアウォール：車両内で使用することができるコンピュータ７４へのすべてのインタフェースをサポートするために、セキュリティ・ファイアウォール機能をセキュリティ制御装置１００に内蔵させることができる。ファイアウォールは、車両内のリソースを無効な、不必要な又は間違った形の要求から保護する。システム２０が提供するサービス及び情報へのアクセスを必要とする、このようなキャリーイン・コンピュータ上で稼働しているアプリケーションは証明を必要とする。セキュリティ制御装置１００は、認証及びこのようなアプリケーションとの鍵交換を処理する。特定のアプリケーションが証明されなかった場合には、セキュリティ制御装置１００は、証明されなかったアプリケーションがある種の所定の車両サービスを受けることができるようにすることができる。
【００４１】
図２を参照すると、この図は、テレマティク・セキュア・システム２０−１のもう１つの実施形態を示す。セキュリティ制御装置１００−１は、共通バス９６−１上のもう１つの装置又はリソースとしてシステム２０−１に内蔵されている。このアーキテクチャによれば、セキュリティ制御装置１００−１は、図１の実施形態で使用することができるすべてのセキュリティ機能を実行する。しかし、セキュリティ制御装置１００−１は、図１の実施形態とは異なり、共通バス９６−１上でスイッチとしての働きはしない。このことはセキュリティ制御装置１００−１の効果の点で欠点になる場合がある。何故なら、共通バス９６−１のセグメントを分離する機能がないために、もはやすべての通信が共通バス９６−１上のリソース間を通過するスイッチ又は中央ハブとして機能しないからである。しかし、セキュリティ制御装置１００−１は、依然として複数の鍵による認証、位置をベースとする認証、及び証明書管理を行うことができる。他の実施形態の場合には、セキュリティ制御装置１００は、また、例えば、通信サービス・モジュール３２、マン／マシン・インタフェース・サービス・モジュール６４及び／又は車両サービス・モジュール９２のようなサービス・モジュールのうちの任意の１つと一緒になることができる。この構成は、併合するリソースによる認証を改善する利点がある。何故なら、同じリソースを構成する場合には、認証を行う必要がないからである。一方、図２の実施形態のように、共通バス９６を分離する機能は失われる。
【００４２】
セキュリティ制御装置１００が行う主な機能は、テレマティクス・セキュア・システム２０へのアクセス及びその使用のための許可に関する。これらの機能を行うために、セキ
ュリティ制御装置１００は、前に許可を受けたデジタル証明書又は他のデジタル・セキュリティ承認又は信任状に関連するいくつかのツールに依存することができる。証明書は、システム２０にアクセスし使用するための特性又は権利の許可を証明する。証明書は、例えば、車両メーカからとは異なるエンティティによる車両への追加装置であるサブシステムのような１つ又は複数の他のリソース、又は車両と一緒に内蔵されていて、取り外すことができる又はできない専用サブシステムを使用する車両内で稼働するアプリケーションのようなリソースに適用することができる。また、車両を含むリソースへのアクセス及びその使用のための安全及びセキュリティ要件を含むすべての要件に適合するものとして全体的に自分自身を確立したエンティティに適用される証明書を入手することができる。エンティティが証明されている場合で、エンティティがそこから入手することができるリソースに対する要件に適合するという証明された記録を有している場合には、このエンティティからのリソースは、車両と一緒に使用するために受け入れることができる。
【００４３】
通常、デジタル証明書はセキュリティ制御装置１００に提示される。証明書は、アプリケーションのようなリソースに適用することができる。セキュリティ制御装置１００は、特定の証明書の提示者（例えば、アプリケーションの所有者又は免許を受けているユーザ）が、証明書に関連する権利を有しているかどうかを判断する。この確認又は認証スキームが満たされると、通信のセキュア・チャネルをアプリケーションに対して確立することができる。セキュア・チャネルは、適当な暗号の使用を含むことができる。
【００４４】
証明プロセスは、多数の手順及びツールを含む。重要な部分は、セキュア・テレマティクス・システム２０内で使用するための証明書を交付する認証局（ＣＡ）の確立又は識別である。ＣＡは、このようなリソースを供給する車両及び／又はエンティティ内で使用するための承認されたリソースへの証明書を責任を持って発行する。ＣＡは、ある種の違反又は不履行が判明した場合には、前に許可したリソース及び／又はエンティティの権利を無効化することができる。ＣＡは、その中の少なくともいくつかについては後で説明する下記のもの、すなわち、認証局の秘密署名鍵のセキュリティ、公開鍵リストのセキュリティ、証明書の提出者が関連する秘密鍵を所有していることを確認する機能、各証明書により妥当な特性を割り当てるための機能、多数の証明書要求を満足させるために要求者への応答を自動化するための機能、及び一次ＣＡの代わりに認証局の機能を提供する権限を与えられているもう１つの又は二次ＣＡを指定するための機能であり、一次ＣＡ上で帯域幅要件を低減するために使用することができる機能に関連する。ＣＡは、１つ又は複数の車両メーカ、アプリケーション開発業者、サービス・プロバイダ、及びその代表者、及び車両メーカ及び車両リソース供給業者及び／又は開発業者から独立している１人又は複数の第三者を含む多数のエンティティのうちの１つ又は複数を含むことができる。
【００４５】
証明書に関連する手順及びプロセスについては以下に説明するが、セキュア・テレマティクス・システム２０で実行するための１つ又は複数のアプリケーションに対して供給される証明書又は他のセキュリティ信任状又は承認に関連して特に詳細に説明する。しかし、このようなプロセス及び手順は、このようなリソースに関連する他のリソース及びエンティティに適用できるように適合させることができることを理解されたい。主な証明プロセスは、１つ又は複数のＣＡ署名鍵により初期化されるＣＡ、このようなアプリケーションが証明書を要求することができるようにする、アプリケーション開発業者に一組の鍵を発行するＣＡ、アプリケーションによる証明書要求の生成、及びそれのＣＡへの配信、及び証明書の要求を許可し、それをアプリケーションに返送するＣＡを含む。
【００４６】
ＣＡ署名鍵生成プロセスに関して、ＣＡは証明書に署名するために使用される署名鍵又は一組の署名鍵を有する。ＣＡ署名鍵生成プロセスが１回実行され、１つ又は複数の鍵が物理的に安全な方法で記憶される。署名鍵の生成は、ＣＡ署名公開鍵（ＣＡＳＰＫ）、及びＣＡ署名秘密鍵（ＣＡＳＲＫ）鍵のペアを生成するＣＡを含むことができる。その生成
後に、ＣＡは、機密保護状態でＣＡＳＲＫを記憶する。ＣＡＳＰＫは、ＣＡによりセキュリティ制御装置１００に送られ、そこでセキュリティ制御装置に提出される証明書の署名を確認するために使用される。証明書上に種々の署名をすることができる、複数のＣＡ署名鍵のペアを生成することができる。その場合、公開鍵のリストが確認のためにセキュリティ制御装置１００と一緒に組み込まれ、ＣＡ署名鍵の索引が証明書に追加される。
【００４７】
次に、証明書の要求の生成ができるようにするために、車両のリソースになるアプリケーションの開発業者に、いくつかのセキュリティ・ツール又は情報が提供される。しかし、開発業者にこのようなアクセス・ツール又は他の情報を提供する前に、特定のアプリケーションが最初に承認される。ある実施形態の場合には、ＣＡとは異なるエンティティにより承認手順が行われる。この異なるエンティティは、アプリケーション確認機関（ＡＶＡ）と呼ぶことができる。別の方法としては、ＣＡは、また、アプリケーションの確認又は承認を責任を持って行う。１つ又は複数のエンティティの識別が何であれ、システム２０に入力されるアプリケーションは、安全で、機密保護されていて、所定のガイドライン内で動作することが許可され、責任を持って確認される。ＣＡであれ、又は他の１つ又は複数のエンティティであれ、ＡＶＡの承認は、ＣＡがアプリケーションに対して証明書を発行することができるようになる前に入手される。この認定機関からの承認は、下記の主要なプロセス、すなわち、アプリケーション開発業者によるＡＶＡへのアプリケーションの提出、ＡＶＡによるアプリケーション開発業者のセキュリティの実行の監査、行動及び安全性を判定するためのシステム２０を含む多数の環境内でのＡＶＡによるアプリケーションの試験、承認を受けることができるようになる前に修正が必要な場合の、ＡＶＡによるアプリケーション開発業者への書面による通知の提出、及びＡＶＡがＣＡとは異なる場合の、ＡＶＡにより確認された場合の、ＣＡへのアプリケーションの承認の通知を必要とする場合がある。
【００４８】
アプリケーション提出プロセスに関して、アプリケーション開発業者は、そのアプリケーションをセキュア・テレマティクス・システム２０に入力できるようにとの要求を行わなければならない。要求は、下記のもの、すなわち相互非公開協定、アプリケーションのコピー、アプリケーションの完全な説明、アプリケーションをシステム２０の一部とするための１つ又は複数の理由、アプリケーションがその機能を行わなければならない一組の特性及び／又は権利、及び１つ又は複数の秘密鍵を保護するために使用するセキュリティ・インフラストラクチャの説明を含むことができる文書を伴うアプリケーションを提出しなければならない。
【００４９】
アプリケーション承認プロセスに関して、ＡＶＡは、アプリケーション開発業者にシステム２０に入力するのを許可する前にセキュリティ監査を行う。この監査は、開発サイト及び／又は製造サイトでの鍵の保護が十分であることの確認を含む正しいセキュリティの予防措置及び手順が正しく行われたことを確認するための、ＡＶＡによるアプリケーション開発サイトへの訪問、ＡＶＡによる１つ又は複数の鍵の保護に関連するセキュリティ・ファームウェア又は他のソフトウェアの再検討、及びアプリケーションが車両内の安全に悪影響を与えないこと及びアプリケーションがシステム２０内で十分に動作することを確認するための多数のセキュア・テレマティクス・システム環境内でのアプリケーションの試験を含むことができる。
【００５０】
また、承認に関して、いくつかの関連要因が考慮され及び／又はチェックされる。第一に、アプリケーションのあるバージョンの承認は、１つ又は複数の後のバージョンを自動的に承認するものではない。第二に、証明書を受け取ったすべてのアプリケーションは不正な変更を受ける恐れがある。ハッカー社会の誰かが、予想しない又は望ましくない方法で実行するために、アプリケーションを修正しようとするかも知れない。開発業者コミュニティのうちの１人又は複数が、有効な証明書を取得した後で、自分自身のアプリケーシ
ョンを修正するかも知れない。修正を行うと、アプリケーションが元の仕様ではなくなるか、セキュリティが不完全なものになり、アプリケーションが望ましくないハッキング又は攻撃に曝されるかもしれない。整合性を確保するために、ＡＶＡは、アプリケーションの一部のセキュア・ハッシュを計算し、そのハッシュを証明書に内蔵するためにＣＡに供給することができる。現場に配備された場合、アプリケーションは、それ自身の同じ部分をセキュリティ制御装置１００に提出しなければならない。認証の一部として、セキュリティ制御装置１００は、同じセキュア・ハッシュを計算し、それが証明書内の値又は特性と一致することを確認する。
【００５１】
アプリケーションの承認プロセスは、また、実施の考慮事項と一緒に、アプリケーション開発業者に対するガイドライン及びアプリケーションに対するガイドラインの厳守を必然的に伴う。この点に関して、アプリケーション開発業者は、自分自身の開発施設及び製造施設で、鍵の物理的セキュリティを行わなければならない場合がある。例えば、このような鍵に物理的にアクセスするには、いつでも最低２人の人物が立ち会わなければならない。アプリケーション開発業者は、通信チャネルの盗聴、エンティティの欺瞞、サービス拒否攻撃（例えば、ネットワークの過負荷）、ソフトウェア又はファームウェアのエミュレーション及び診断バックドアを含むアプリケーションが受けるかも知れない種々のタイプの攻撃について知っていなければならない。アプリケーション開発業者は、確認機関により管轄されるモジュール及び確認機関が管轄しないモジュールにアプリケーションを分割しなければならない場合がある。明確に分割した場合には、開発業者は、確認機関のバージョン管理機構により管轄されないモジュールをさらに好適に改訂することができる。アプリケーションの開発業者は、現場での更新に対するセキュア・ダウンロード手順を行わなければならない場合がある。何故なら、セキュア・ダウンロード手順を行うと、望ましくないアプリケーションがセキュア・テレマティクス・システム２０内に入り込むのが防止されるからである。
【００５２】
アプリケーション用のガイドラインは、車両環境に敏感であること、又は車両環境と優れた互換性を有することを含むことができる。例えば、あるアプリケーションは、車両が移動していない場合だけ適正なものになり、車両が移動中には不適切なものになる。何故なら、運転者の注意がある程度散漫になるからである。各アプリケーションは、ハードウェア保護、鍵の不明瞭さ及び暗号化技術により、その１つ又は複数の鍵を保護しなければならない。各アプリケーションは、システム２０内の優先順位の概要を知っていなければならない。ある種のアプリケーションは優先順位が低いと見なすことができ、優先順位の高いアプリケーションにより終わらせることができる。
【００５３】
アプリケーションの実施要因に関して、確認機関は、行動監査、セキュリティ監査、安全監査を責任を持って行うことができる。確認機関は、これらの目的に適合するために、確認手順又は監査手順を行う目的でソフトウェア・ツール及びハードウェア・ツールに依存することができる。
【００５４】
開発業者が確認機関の要件に適合したと判断した場合には、１つ又は複数の証明書要求の生成に関連するプロセスを継続的に行うことができる。より詳細に説明すると、ＣＡは、証明書要求公開鍵（ＣＲＰＫ）及び証明書要求秘密鍵（ＣＲＲＫ）のペアを生成する。同時に、ＣＡは、この鍵のペアに証明書要求識別子（ＣＲＩＤ）を割り当てる。鍵ペア及び識別子を生成した後で、ＣＡは、セキュア手順、経路又は手段により、ＣＲＩＤ及びＣＲＲＫを開発業者に配布する。このようなセキュリティは、手渡しを含むことができ、又は現場訪問中に確立した独立のセキュア・チャネルを通して行うこともできる。ＣＡは、また、証明書要求公開鍵リスト（ＣＲＰＫＬ）と呼ぶことができるローカル・データベース内に新しいエントリを生成する。新しいエントリは、将来アクセスすることができるように開発業者のＣＲＩＤにリンクしている。一意の識別子はＣＲＰＫＬへの次に使用可能
な索引であってもよいし、又は全地球的に一意の識別子（ＧＵＩＤ）であってもよいし、又は関連するＣＲＰＫを探すために使用することができる任意の他の一意の値であってもよい。新しいエントリは下記の情報を含むことができる。
【００５５】
（ａ）アプリケーションに関連するＣＲＰＫ。
（ｂ）許可する証明書の特性。要求した特性値、権利及び／又はＣＡが発行することができる義務の範囲を制限する特性範囲を入力することができる。特定のアプリケーションに証明書が許可された場合には、これらの特性は証明書の一部になる。
【００５６】
（ｃ）アプリケーションに対する証明書の許可に関連する任意の追加規則。これらの規則は、許可する証明書の最大数、証明書を発行する前に、証明書の許可及び金融取引が確認される要求（例えば、支払う補償金又は料金）の時間制限を含むことができる。
【００５７】
このような情報は、また、アプリケーションのセキュア・ハッシュを含むことができる。セキュア・ハッシュは、許可なしで多量のデータを元に戻すのが数学的に極度に面倒になるように、多量のデータの少数のビットへの変換を含む。「メッセージ認証コード」を生成するために、セキュア・セッション鍵によりセキュア・ハッシュ値を暗号化することができる。
【００５８】
すでに説明したように、許可する証明書は多数の特性又は権利を有する。証明書内の特性は、任意の量の情報、すなわち、証明書の所有者に対する一意の識別子、優先順位の高いアプリケーションが、優先順位の低いアプリケーションより先に帯域幅の割当てを受ける場合に、アプリケーションに割り当てられる優先順位レベル、証明書の期限切れの日付及び時刻、証明書が有効な地理的位置、証明書が有効な無線ＬＡＮ「ホットスポット」識別子、アプリケーションが正しく機能するために通信するために必要なシステム２０の一部である他のリソース（セキュリティ制御装置１００は、アプリケーションが正しく稼働するのに必要なすべてのリソースを含む共通セキュア・チャネルを開くためにこの情報を使用する）、アプリケーションが使用することができ、それによりあるＡＰＩへのアクセスの制限が、ある種の証明書のセキュリティ・リスクを低減するＡＰＩ、例えば、車両情報の状態を読み出すコマンドへのアクセスだけを許可する証明書は、１つ又は複数の機能を行うために、車両サービスを制御するコマンドへのアクセスを許可する証明書よりリスクが小さい、及び／又はユーザの確認手順、又は外部の第三者の認証手順の形をとることができる追加の認証を含むことができる。
【００５９】
例えば、ＣＲＲＫの受信により、システム２０を使用する権利がアプリケーション開発業者に許可された場合には、開発業者はＣＡにアプリケーション証明書要求を発行することにより証明書を入手することができる。証明書要求プロセスは、証明書を受け取るアプリケーションのタイプにより異なる。この場合、アプリケーションは、その証明書及びアプリケーションの配布方法を受信する。アプリケーションは、下記のものを含む証明書を要求することができる。
【００６０】
電子サブシステムに組み込まれているアプリケーションは、セキュア・テレマティクス・システム２０で使用するために受け入れることができる状態でアプリケーションを出荷するためにその製造プロセス中にＣＡから証明書を要求することができる。
【００６１】
ハード媒体（例えば、ＣＤ−ＲＯＭ又はＤＶＤ）を通して配布されるアプリケーションは、アプリケーション開発業者が管理する証明書要求プロセスを１回受ける。その配布の一部として、証明書及び１つ又は複数の鍵がアプリケーション内に組み込まれる。
【００６２】
あるアプリケーションは、ＷＡＮ、ＬＡＮ又はＰＡＮネットワークを通して配布するこ
とができる。アプリケーション開発業者は、ダウンロードの際にアプリケーションに対する証明書の動的な入手を選択することもできるし、又はハード媒体配布アプリケーションのようにその都度証明書を要求することもできる。
【００６３】
あるアプリケーションは、エンドユーザ環境内で稼働しながら、新しい証明書を要求することができる。アプリケーションは、システム２０にアクセスするために、新しい又は更新した証明書を要求することができる。この機能により、料金の支払いを含むことができる新しい又は更新した証明書を入手することにより、現場でユーザはアプリケーションを動作できるようにすることができる。
【００６４】
アプリケーション又はアプリケーション開発業者が証明書を要求していようがいまいが、今識別したばかりのアプリケーション及び証明書公開鍵（ＣＰＫ）及び証明書秘密鍵（ＣＲＫ）のペアを生成するアプリケーション、不揮発性メモリ内にＣＲＫを機密保護状態で記憶するアプリケーション、下記の構成要素、すなわち、ＣＡへの要求者を識別するＣＲＩＤ、アプリケーションの公開鍵であるＣＰＫ、要求される他の証明書の特性、及びＣＡに対する要求者を認証するために使用するＣＲＳにより、ＣＲＲＫを鍵として使用して、上記すべての情報にデジタル的に署名することにより生成される証明書要求署名（ＣＲＳ）を含む証明書要求を生成するアプリケーション、及びＣＡへの要求を配布するアプリケーションを含む事実上すべてのアプリケーションに適用することができる基本的なステップを実施することができる。上記要求は必ずしも送信のためのセキュア・チャネルを必要としない。
【００６５】
証明書生成に関して、ＣＡは、供給されたＣＲＩＤを参照パラメータとして使用して、データベースからＣＲＰＫ特性、規則及びセキュア・ハッシュを検索する。ＣＡは、またＣＲＰＫを使用してＣＲＳを確認する。ＣＡは、ＣＲＩＤに関連する規則のどれも失敗しなかったことを確認する。例えば、ＣＡは、ＣＡが許可した証明書の有効期限がまだ期限切れになっていないことを確認する。さらに、ＣＡは、要求した特性が、要求中にセキュア・テレマティクス・システム２０に入力するのに合意した特性の範囲内に含まれていることを確認する。アプリケーションは、ある期限切れの期間に証明書を要求できなくてもよい。ＣＡは、セキュア・ハッシュ内の特性を含む証明書を生成し、またＣＡ署名秘密鍵（ＣＡＳＲＫ）でそれにデジタル的に署名する。上記のことを実施した後で、ＣＡは、要求者に完成した証明書を返送する。この返送は機密保護されていないチャネルを通して行うことができる。受信後、アプリケーションは、証明書内の公開鍵が証明書要求の元の一部であるＣＰＫと一致することを確認し、ＣＡの署名を確認することにより証明書が本物であることを確認するよう求められる。
【００６６】
証明書を受信すると、アプリケーションは、セキュア・テレマティクス・システム２０にアクセスすることができる。通常、このアクセスは、セキュリティ制御装置１００との相互作用を含む。より詳細に説明すると、証明されたアプリケーションは、セキュア制御装置１００に証明書と一緒にサービス要求を送信する。セキュア制御装置１００は、公開鍵で暗号化した乱数を含むチャレンジ要求をアプリケーションに返送することができる。アプリケーションは、そのローカル秘密鍵により乱数を解読する。アプリケーションは、制御装置１００に乱数応答を返送する。アプリケーションからの応答で制御装置１００が受信した乱数が、チャレンジのために暗号化した数と一致する場合には、サービス要求は許可される。許可されると、制御装置１００は、アプリケーションにスタートするサービス又はセッションの表示を送信する。
【００６７】
証明書は、通常、満期の日付まで有効である。しかし、所定の条件があってその条件に該当した場合には証明書は無効化される。例を挙げて説明すると、秘密鍵が外部に漏れた場合のように、アプリケーションが危険になった場合には無効化されなければならない。
ＣＡは、セキュリティ制御装置１００内に組み込むことができる証明書無効化リスト（ＣＲＬ）を維持することができる。セキュリティ制御装置１００は、アプリケーションが無効化されていないことを確認するために、その認証プロセス中、ＣＲＬを参照する。ＣＲＬの更新は、証明書自身内の追加の第三者認証に対する要件を含ませることによりサポートすることができる。
【００６８】
証明書の生成は、アプリケーション開発業者が必要とする場合があるセキュリティ・コードを供給する現在入手可能なツール・キットを使用することができる。これらのツール・キットはＲＳＡのＣｅｒｔ−Ｃ及びＣｅｒｔｉｃｏｍのＴｒｕｓｔＰｏｉｎｔを含むことができる。
【００６９】
生成された証明書は、料金、支払い、特許権使用料又は他の補償要件の追跡を含む他の用途に使用することができる。システム２０内で専用リソースにアクセスしたい場合には、このような専用リソースにアクセスしたい及び／又は使用したいということを示すために、デジタル証明書を発行することができる。アプリケーションに対して証明書を発行する度に、証明書データベースにエントリされる。専用リソースへのアクセスを可能にする発行証明書の番号を検索するために、データベースに問い合わせすることができ、前に決定した料金又は特許権使用料をこのようなアクセス又は使用に対して課金することができる。
【００７０】
セキュア・テレマティクス・システム２０を使用すれば、車両に関連する１つ又は複数の他のリソースと一緒に、安全な方法でセキュア・アプリケーションを使用することができる。さらに、使用中のアクセスを制御する目的で、その専用リソースを使用できるようにするために、リソース内に専用の利害関係を有する所有者又は他の人に動機が提供される。専用リソースは、非専用リソースとは対照的に、１つ又は複数のエンティティが、リソース内に法的に保護することができる専用の利害関係を有するリソースである。法的に保護することができる専用の利害関係は、特許、商業上の秘密、著作権及び契約をベースとする権利を含む１つ又は複数の法的に認識された知的所有権をベースとすることができる。リソースの使用及びその拡張、特に専用リソースの使用は、テレマティクス・セキュア・システム２０と関連することができるエンティティとの関係を確立することにより育成することができる。これらのエンティティは、車両メーカ、通信デバイス販売業者、通信サービス・プロバイダ、専用サブシステム供給業者、アプリケーション開発業者及び車両ユーザを含むことができる。関係の確立は、エンティティによる条件の定義及び受諾を含むことができる。権利及び義務のようなこれらの条件は、異なるエンティティ又はエンティティのグループに対して異なるものであってもよい。これらの条件は、使用することができるリソースの十分な記述又は識別、使用に関連する補償関連要因、使用期間、専用リソースを使用することができる特定の定義又は制限、使用することができる場所を指定する地理的制限、１つ又は複数の条件を満たさなかった場合の救済策、及び指定の機関によるアプリケーションのような専用リソースの承認を含む上記証明書の取得を含む他の関連要件を含むことができる。
【００７１】
受け入れることができるセキュリティと一緒に、正しい場所に正しい関係を確立すれば、テレマティクス・セキュア・システム２０の種々のユーザ及び／又はアプリケーションを事前に識別することができる。例えば、アフター・マーケット・オーディオ装置の販売業者は、オペレータに関連する制御装置及びディスプレイ又はヘッド・ユニット４０へ車両ラジオをインタフェースするために、車両内の専用リソース及び／又は非専用リソースにアクセスしたい場合がある。付属ラジオ製造業者は、また音声認識を含む車両にすでに内蔵又は組み込まれている手ぶら携帯電話の使用のような車両オーディオ・システム及び手ぶら機能にアクセスしたい場合がある。さらに、個人の又は他の所望のデータをアップロード及び／又はダウンロードすることができるように、車両ＰＤＡインタフェースにア
クセスしたい場合もある。無線装置の承認及びセキュリティ制御装置１００と一緒に機能するデジタル証明書の入手に基づいて、このようなリソースをアフター・マーケット供給業者が使用できるようにすることができる。この場合、車両に関連する１つ又は複数の専用リソースに、１つ又は複数の専用利害関係を有するエンティティとしての車両メーカは、加入及び／又は車両を再販売した場合、１回の定額の支払いの形をしている場合もあるこのようなアクセス及び使用のために受領した歳入のような車両メーカに動機を提供する条件を含む適当な条件を使用するこのような販売業者との関係を確立することができる。
【００７２】
車両に関連する他のリソースと一緒に使用する適用可能なリソースを含む多数の他のアプリケーションを識別又は記述することができる。セキュリティ、多重ユーザ、地理的、規制による通信及び商行為に関連するものを含む多くの一般的な用途がある。１つ又は複数のアプリケーションは、これらのグループ又は分類のうちの２つ以上に分類することができ、他のアプリケーションは、これらのうちの１つ又は複数に明確に分類することができない。代表的なアプリケーションのいくつかについて次に説明する。
【００７３】
車両構成：車両内に構成情報を送るために携帯電話２４を使用することができる。この構成情報は、運転者識別、座席位置、ミラー位置、ラジオ局プリセット、及び車両内に位置する他のサブシステム又はデバイスの使用を含むことができる。情報を受信した場合、これらのものをテレマティクス制御ユニット８０又は他の車両常駐計算デバイスからのコマンドにより調整することができる。このようなアプリケーションは、下記のステップを必要とする場合がある。
【００７４】
１）携帯電話２４は、電源供給時にクレードル（ｃｒａｄｌｅ）内に設置される。
２）「ＰＩＮ」、生体認証、スマートカード、音声コマンド等のようなオペレータ識別が入力される。
【００７５】
３）携帯電話２４は、この情報を受信し、車両構成アプリケーションがスタートする。
４）セキュリティ制御装置１００は、例えば適当な鍵交換により構成アプリケーションを認証する。
【００７６】
５）認証に成功した後、セキュリティ制御装置は、セキュア・セッションがまだ進行していない場合には、車両ゲートウェイ８０であってもよい適当なバス、車両バス又はバス８４へのゲートウェイを含む通信チャネルを動作できるようにするか、又は認証する。
【００７７】
６）セキュリティ制御装置１００は、共通の暗号化したセッション鍵を選択し、またその鍵を携帯電話２４及び車両ゲートウェイ８０へ配布する。
７）車両構成コマンドは、セキュア暗号化チャネルを介して携帯電話２４から車両ゲートウェイ８０へ送信される。
【００７８】
８）車両ゲートウェイ８０は、そうしたい場合又は適当である場合に、車両が停止している場合だけ構成調整を行うべきであると確認する。
９）構成アプリケーションを含む全体のアクセス及び使用の一部として、上記調整を行う前にユーザの肯定応答が必要な場合がある。
【００７９】
アプリケーションのもう１つの代表的例は、指定エンティティ又は機関に送信される通知をトリガする車両内のエアバッグのようなインフレータ・システムの作動を含むことができる。このアプリケーションの関連ステップは下記のものを含む。
【００８０】
１）システムの初期化中、ＧＰＳ７０、車両ゲートウェイ８０、セキュリティ制御装置１００、及び緊急の際に使用するための通信サービス・モジュール３２を含むセキュア・
アラーム・チャネルが確立される。
【００８１】
２）十分な車両衝撃を検出した場合、インフレータ・システムのエアバッグが作動又は展開する。
３）車両ゲートウェイ８０は、インフレータ・システムをそこに接続した場合に、内蔵車両バス８４の両端に起こる場合があるこの車両デバイスから１つ又は複数のエアバッグ関連アラームを受信する。
【００８２】
４）セキュリティ制御装置１００は、セキュア接続を通してのアラームを受信する。
５）セキュリティ制御装置１００は、ＧＰＳ７０からのＧＰＳ情報を受信し、この情報を通信サービス・モジュール３２へ供給する。通信サービス・モジュール３２は、携帯電話２４又はＷ−ＬＡＮ及びＷ−ＰＡＮサブシステム３６、３８のような他の通信サブシステムにより、車両の遠隔の指定エンティティ又は機関に通知するために通信をスタートする。
【００８３】
加入サービスを含むナビゲーション・アプリケーションも実施することができる。例を挙げて説明すると、ＧＰＳ及びヒューマン・インタフェース４０が内蔵するナビゲーション・アプリケーションと一緒に車両を売ることができる。アプリケーションを引き続き使用するには、加入を更新しなければならない。確認可能な金融取引に基づいて確認される証明書要求を生成することにより、認証局からリアルタイム証明書が入手される。このアプリケーションに関連していくつかのステップを次に説明する。
【００８４】
１）車両ユーザは、ナビゲーション加入が失効しようとしていること、サービスの１年間のような後続の期間の間のサービスを引き続き受けることができることの通知を受ける。
【００８５】
２）ユーザは、クレジット・カード番号のような電子支払い情報の入力により申入れを受諾する。ユーザが取引を行うことができること、すなわちユーザが車両の所有者であることを確認するために二次ユーザ認証が必要になる場合がある。
【００８６】
３）アプリケーションは、通信サービス・モジュール３２を通して金融機関とのセキュア・チャネルを要求する。セキュリティ制御装置１００は、通信サービス・モジュール３２を通して、アプリケーション間の及び金融機関との共通のセキュア・チャネルを開設することにより、この取引を行うことができる。
【００８７】
４）アプリケーション及び金融サービスは、ユーザの口座に課金するためにセキュア・チャネルを通して通信する。
５）金融サービスは、課金に対して確認番号で応答する。
【００８８】
６）アプリケーションは、金融取引の受領書として課金の確認番号を含む認証局への証明書要求を作成する。
７）アプリケーションは、セキュア・チャネルを必要としない証明書要求をＣＡに送信する。
【００８９】
８）ＣＡは、要求を受信し、課金が行われたことを金融機関と確認し、アプリケーションに対して１年間の証明書を発行する。
９）アプリケーションは、ＧＰＳ７０へのアプリケーションによるアクセスを可能にするために、セキュリティ制御装置１００へ新しい証明書を提示する。
【００９０】
１０）ＣＡは、特許権使用料によるものを含む起こり得る料金について、車両製メーカ
及びアプリケーション開発業者へ加入通知を配布する。
セキュア・テレマティクス・システムは、承認リポジトリの更新及び下記のものを含むことができる証明書無効化リストを含む証明書関連手段にも関連する。
【００９１】
１）システム２０は、証明書への更新を行うことができるという通知を受信する。この通知は、無線リンク又は車両又はデジタル・バスを含む有線接続を通して受信することができる。
【００９２】
２）車両ユーザは、更新が可能であり、更新のアップロードの肯定応答及び／又は承認することができるという通知を受けることができる。
３）セキュリティ制御装置１００は、ソフトウェア又は証明書のソースを認証する。
【００９３】
４）アップロードは、車両がある地理的領域内に位置している間だけアップロードできるというような位置による制限を受ける場合がある。このような場合、アップロードするためにアプリケーションに対して提示した証明書は、必要な地理的領域の識別を含む。
【００９４】
５）アップロードをある時間帯だけアップロードすることができるというように、時間により制限することもできる。
６）暗号化通信を含むセキュア・セッションが、証明書ソースとセキュリティ制御装置１００との間に設定される。
【００９５】
７）新しい証明書及び／又は証明書無効化リストであってもよい更新が、セキュリティ制御装置へロードされる。
８）セキュリティ制御装置１００は、デジタル署名による証明書及び／又はＣＲＬを認証する。
【００９６】
９）そうしたい場合には、本物であることを確認するために第三者に参照することができる。
１０）セキュリティ制御装置１００は、その不揮発性メモリ内へ新しい証明書及び／又はＣＲＬを記憶する。
【００９７】
アプリケーションを更新するために、類似の手順又はステップを使用することができる。セキュリティ制御装置１００も失効証明書に対して更新を要求することができる。証明書は所定の日付で失効する。このことは、加入をベースとするサービスの場合に役に立つ場合がある。このような場合、内蔵ＧＰＳ７０のようなセキュア時間ソースが必要である。ローカル・ホットスポットのところの無線通信ネットワーク・クロック確認も使用することができる。
【００９８】
次に、いくつかのグループ又は分類により他のアプリケーションについて説明する。下記のものはセキュリティ・アプリケーションに関連する。
保証及び品質管理のためのセキュアＶＩＮ：車両メーカは、保証及び品質保証に関連する記憶している情報の統合性が失われていないことを確認するために、セキュリティ制御装置１００を使用する。指定のエンティティ又は機関に送られる自動衝突通知を記録する作動ログを内蔵することができる。セキュアＶＩＮ証明書／鍵を車両メーカのプラントでロードすることができる。
【００９９】
車両ユーザ・アプリケーションに対する車両情報へのアクセス：自動車メーカは、認定所有者だけに、車両情報、運転者情報及び車両制御へのアクセスを許可するためにセキュリティ制御装置を使用することができる。本質的に、これは、所有者又は他の認定ユーザに対する車両へのセキュア鍵であってもよい。その一例が、携帯電話又はＰＤＡによる車
両のドアのアンロックである。
【０１００】
診断ツールに対するセキュア・アクセス：車両メーカは、認定されたツールを有する認定ディーラだけに、診断情報及び車両構成へのアクセスを許可するためにセキュリティ制御装置１００を使用することができる。
【０１０１】
サービス・プロバイダ・アプリケーションへのアクセス：車両メーカは、認定されたツールを有する認定サービス・プロバイダに車両情報、運転者情報及び車両制御へのアクセスを許可するために、セキュリティ制御装置１００を使用することができる。
【０１０２】
ユーザ・インタフェース・リソースへのアクセス：車両メーカは、認定されたアプリケーション及びデバイスだけに車両ユーザ・インタフェースへのアクセスを許可するために、セキュリティ制御装置１００を使用することができる。車両メーカは、例えば、ハンドルのボタン又は内蔵音声認識により携帯電話を制御することができるようにすることにより、運転者の不注意による事故のリスクを少なくすることができる。
【０１０３】
セキュア・フリート車両状態：フリート・オペレータは、そのフリートの各車両及び負荷状態データへのアクセスを制御するために、セキュリティ制御装置１００を使用することができる。この情報は、車両メモリ７６内に機密保護状態で記憶することができ、認定されたエンティティだけがアクセスすることができる。
【０１０４】
フリート管理のためのセキュア位置データ：フリート・オペレータは、そのフリートの位置データへのアクセスを制御するために、セキュリティ制御装置１００を使用することができる。位置情報は、車両メモリ７６内に機密保護状態で記憶することができ、認定されたエンティティだけがアクセスすることができる。
【０１０５】
位置データの保護：車両の所有者又は他の認定ユーザは、所有者の車両の位置データへのアクセスを制御するために、セキュリティ制御装置１００を使用することができる。位置情報は、車両メモリ内に機密保護状態で記憶することができ、認定されたエンティティだけがアクセスすることができる。
【０１０６】
車両追跡及びセキュリティ：内部ＧＰＳアセット、車両バス・アクセス及び車両通信は、トラック会社が運送中の有害な物質の現在位置の認識のような多くのレベルの車両の安全及びセキュリティを提供することができる。
【０１０７】
テレマティクス・セキュア・システム２０は、下記のものを含むマルチユーザ・アプリケーションに対して適合させることができる。
多数の認定車両ユーザ：システム２０に関連するリソースは、例えば、特定のユーザの特別な利害関係をベースとする各ユーザに対する「ホットスポット」のフィルタリング、各家族のメンバー、従者又は認定車両オペレータに対する車両制御の制限又は提示、及び特定のユーザの認証に関連する加入のような通信オプションを提供する際に、同じ車両の各認定ユーザ用に特別に及び一意に構成することができる。
【０１０８】
レンタカーのカスタマイズ：レンタル車両のユーザは、個人用携帯電話を使用するために、及び／又は無線局を選択する目的で個人ディレクトリをアップロードするためにレンタルされた車両と相互作用を行うことができる。
【０１０９】
下記のものを含む地理的及び／又は定期的アプリケーションにアクセスするためにテレマティクス・セキュア・システム２０を使用することができる。
トラヒック情報加入：オペレータ・ユニット４０の一部となっている場合があるナビゲ
ーション表示スクリーンにより、種々のレベルの交通地図、警報及び特殊なルートを表示することができる。
【０１１０】
車両汚染制御：排気を低減するために、又は車両を電力走行に切り替える目的で、車両内の制御装置を修正又は調整するために、システム２０にアクセスすることができる。
現在の道路状況：建設場所又は事故からある距離のところで関連情報を同報通信することができる無線リンク警報局により、前方の道路建設場所又は大きな事故の高度の警報を提供することができる。ヒューマン・インタフェース４０により、表示又は音声情報を使用して車両のユーザ又は運転者に警告することができる。
【０１１１】
気象状況：車両の運転者が、異なるルートへの変更の可能性を含む適切な措置をとるための十分な時間的余裕を持つことができるように、霧、氷及び／又は雪のような気象状況の高度な警告をシステム２０により提供することができる。
【０１１２】
境界横断及びチェック：政府機関は、境界横断及び重量チェックに関連する車両データへのアクセスを制御するために、セキュリティ制御装置１００を使用することができる。このような情報は、車両メモリ７６内に機密保護状態で記憶することができ、認定されたエンティティだけがアクセスすることができる。
【０１１３】
スモッグ試験：政府機関は、スモッグ試験に関連する車両データへのアクセスを制御するために、セキュリティ制御装置１００を使用することができる。このような情報は、車両メモリ内に機密保護状態で記憶することができ、認定されたエンティティだけがアクセスすることができる。
【０１１４】
アプリケーションのもう１つの分類は、一般的に、無線ＬＡＮネットワーク技術又は他のプロトコルを使用して車両を所望した又は要求した情報を受信するクライアントであると見なすことができる通信に関連する。車両へのダウンロードにより送られる情報は、下記のものを含むことができる。音楽（ＭＰ−３又はＷＭＡフォーマットなど）、住所録エントリ、ナビゲーション・システム更新及び個人ナビゲーション地図、文書同期及び更新、車両ＰＤＡとの同期、オンライン・ゲーム状態の更新、認定ユーザに対する車両許可の更新及び修正、特定のユーザに対する電子商取引アプリケーションを制御するためのファイアウォール許可、運転者確認及びグループ・チャットのサポートを含むことができる。音楽ダウンロードのさらに特種な例は、特定の地理的領域との関連を含むことができる。例えば、イエローストン・パークに入る車両の位置の認識に基づいて、この公園を通過する際にエンジョイするように編集された音楽の形で、車両の運転者及び乗客に特別な提供をダウンロードすることができる。このような特殊な音楽の提供は、車両に乗っている人に、無線通信ネットワーク・広帯域リンク等を介してセキュア・テレマティクス・システム２０により行うことができる。特殊な音楽に関連する提供を受信した後で、デジタル基金リソース７８により受信に関連する料金を支払うことができる。この支払いの後で、以降の演奏のために、オペレータのユニット４０に受信可能なフォーマットでこの音楽がダウンロードされる。
【０１１５】
テレマティクス・セキュア・システム２０のある種の電子商取引アプリケーションについてはこの後で説明する。
サービス・プロバイダとしての車両：認定されたエンティティが機密保護状態でアクセスすることができる承認リポジトリ７８を有する車両の場合には、車両は、承認リポジトリ７８を使用する取引により支払いが行われるサービス源となることができる。このようなサービスは、賃貸、金融、修理及び／又は車両の維持に関連するサービスを含むことができる。このようなサービスは、基本的なナビゲーション・サービス及び／又はこのようなサービスに対するプレミアムであってもよい。車両メーカは、適正な支払いが行われな
かった場合には、適切な制限を車両に対して行うことができる（例えば、サービスの打ち切り、車両の使用の規制）。さらに、車両は、支払いを含む条件に適合した場合には、作動可能な機能を有する構成済みのデバイス、サブシステム及び構成要素を有することができる。これらの機能は、ある時間の間、特別のエンジン馬力を使用できるようにすることもできる。ちなみに、承認リポジトリ７８を有する車両は、承認リポジトリ７８を使用することができるエンティティ又は個人に関連する他の確認を要求することができる。このリソースへのアクセスを確認するために、網膜スキャナ、指紋確認等のような種々の生体認証装置を使用することができる。
【０１１６】
消費者エレクトロニクス・デバイスへのアクセスへの制御：このようなデバイスの製造業者は、認定ユーザだけにアクセスを許可するために、セキュリティ制御装置１００を使用する。これは、車両内に位置している場合に、携帯電話又はＰＤＡのプレミアム機能をアンロックするセキュア鍵であってもよい。
【０１１７】
使用料の支払い：政府機関は、使用料及び駐車料金を支払う際に使用するための承認リポジトリ７８へのアクセスを制御するために、セキュリティ制御装置１００を使用することができる。公共及び民間運送会社も、システム２０を使用することができる。外部料金所ゲートへのＷｉＦｉリンクは、走行距離料金及び走行関連料金コストの組合わせを決定する際に、タクシーの料金メータと通信することができる。さらに、システム２０は、ＷｉＦｉ機能を有するタクシーの乗客のＰＤＡに電子領収書を送信することができる。
【０１１８】
第三者サービス及び販売促進：車両の運転者及びすべて乗客は、車両の所定の距離又は範囲内に位置するビジネス施設からのものを含む入手できる製品及びサービスに関連する通信を受信することができる。これらの加入サービス及び販売促進は、ガソリンスタンドでの購入の際のデジタル・クーポン、ホットスポット・インターネット特権、レストランのメニュー及びその販売促進、及びＩＰ長距離の無料音声のような通信の提供に関連づけることができる。
【０１１９】
マルチメディアのダウンロード：車両の運転者及び１人又は複数の乗客と相互に関係づけることができる個人の加入者識別に基づく加入により音楽及びビデオをダウンロードすることができる。
【０１２０】
多くの他のアプリケーションも使用できること、及び上記アプリケーションはその代表的なものであることを理解されたい。テレマティクス・セキュア・システム２０は、確立することができる関係及びこのようなアプリケーションのうちの１つ又は複数と一緒に使用するために又は実行するために識別又は考案することができるリソースによってだけ制限することができる多数の種々のアプリケーションに対する環境を確立する。
【０１２１】
セキュリティ制御装置１００は、また、リソースへのアクセス及びその使用も、連合のメンバーが供給する１つ又は複数の承認又は信任状及び／又はその組合わせをベースとする連合に加入したアーキテクチャの一部として構成することができる。この実施形態の場合には、セキュリティ制御装置１００は、車両リソースへのアクセス要求を許可し、認証する際に、代理又は信頼調停者としての働きをする。アクセス要求の許可及び認証に関連して、セキュリティ制御装置１００は、エンティティ又は要求者が供給する承認又はセキュリティ信任状の複雑な組合わせを評価することができる。信任状をベースとして、セキュリティ制御装置１００は、アクセスを許可すべきか拒否すべきかを決定することができる。承認は、信任された事業主が本当であると主張している情報の署名入りの集合体である。承認はある当事者を意味するか、関連することができるだけである。承認は、権利、特権及び／又は義務に同時に関連するいくつかのレベル又はクラスにより分類することができる。例えば、承認は、識別子、又は要求しているエンティティを車両保守メンバー、
輸送プロバイダ、車両燃料プロバイダ、及びハイウェイ使用料エンティティのようなサービス・プロバイダの特定のクラスに関連づける他の情報を含むことができる。
【０１２２】
セキュリティ制御装置１００は、また、それ自身のために又は車両内の他のリソースのために、承認又はセキュリティ信任状と関連することができる。いくつかの例は、車両位置情報の提供を許可するユーザ又は車両識別の提供を含む必要がない信任状の提供を含むことができる。車両の一部としてのセキュリティ制御装置１００は、連合のメンバーであるエンティティが、セキュリティ信任状又は属性のような承認のフォーマット及び内容について合意している連合に加入したセキュリティ環境内で動作することができる。これらもこれらの信任状を交換するためにプロトコルを受け入れる。セキュリティ制御装置１００は、それ自身のため、及びそのドメイン下の車両リソースのためにプロトコルを実施することができる。
【０１２３】
より詳細に説明すると、セキュリティ制御装置１００は、広く認識されているルートＣＡが発行した署名証明書により、車両内のリソースに証明書を発行することができる。同時に、セキュリティ制御装置１００は、接続しているリソース内での認証及び許可に関する埋め込まれた承認を理解することができる。ＰＫＩモデルは依然としてサポートされている。何故なら、これらのリソースに発行されたＰＫＣは、セキュリティ制御装置１００が使用することができる承認のタイプのサブクラスと見なされるからである。
【０１２４】
ある実施形態の場合には、新しいリソース（例えば、デバイス）が接続されると、その新しいリソースは、セキュリティ制御装置１００に連絡し、又はその逆を行い、新しい証明書が要求される。その名前でそのリソースに証明書を発行するかどうかの決定は、セキュリティ制御装置１００が行う。この決定は、リソースの位置（例えば、１つ又は複数の車両バスに接続している）、ユーザからの入力（例えば、「あなたが今接続したリソースは、Ａｃｍｅ社製のラジオ４０７ｂですか」という質問が行われ、後でそうするにはラジオをどうするのかを質問することができる）、セキュリティ制御装置１００がその発行及び他の適当な情報を確認することができるリソース内の予め埋め込まれた承認をベースとしている。これらすべての入力を使用して、証明書を許可するかどうかについて、入手できる最大量の情報によりインテリジェントな決定が行われる。
【０１２５】
識別証明書はいつでも発行しなければならないが、これら証明書に関連する許可特権は注意深く分割しなければならない。ここで制御及びビジネス・モデルを念入りに作ることができる。セキュリティ制御装置１００は、いくつかの情報に基づいて、インテリジェントでないアプリケーションに対してある種の許可を与えるかどうかについて決定する。インテリジェント・アプリケーションの場合には、このアプリケーションは、ドメイン制御装置としての働きをすることができ、これらの優れたリソースが、それ自身で所望の任意の方法で潜在的に許可を決定することができるようにする。いずれにせよ、セキュリティ制御装置１００は、必要な構成要素であり、課金システムを追加することができる他のリソースを使用するために、種々のリソースに許可を割り当てる際にいくつかのフックが存在する。
【０１２６】
セキュリティ制御装置１００が、車両内のリソースにそれ自身の証明書を発行できるようになると、関連するすべてのリソースの露出が大きく低減する。何故なら、新しい証明書を容易に局所的に発行することができるからである。セキュリティ制御装置の証明書の発行者のセキュリティが危険になった場合には、それが署名したセキュリティ制御装置に対して新しい証明書を発行するだけでよい。さらに、連合に加入した状態で許可及び識別を処理することができる。ラジオ製造業者は、セキュリティ制御装置１００が、製造業者と一緒に確認することができ、信頼できるかどうかを決定するラジオ内部で、許可の承認をまとめることができる。
【０１２７】
次に、図３を参照しながら、車両が、セキュリティ制御装置１００の制御下で、このような連合の一部になっている用途及び動作について概略説明する。セキュリティ制御装置１００は、元の又は要求しているアプリケーション、及び目標サービス・プロバイダ、目標製品プロバイダ、又は他のプロバイダであってもよい目標プロバイダと通信する。通常、要求しているアプリケーションは、特定の機能又は活動のために目標プロバイダを使用しようとする。元のアプリケーションによるアクセスを許可すべきかどうかの決定に関連して、元のアプリケーションが認証されているかどうか、またそのアプリケーションを実行するための資格を有しているかどうかを確認するためにいくつかの手順が行われる。これら手順の主なステップは下記のものを含む。
【０１２８】
１．元のアプリケーションは、ある製品、サービス、リソース又は他の情報を要求している目標プロバイダと連絡する。
２．目標プロバイダは、元のアプリケーション、目標プロバイダの名前による署名入りの承認、及び元のアプリケーションがアクセスすることができるようにするために必要な情報を送信する。
【０１２９】
３．元のアプリケーションは、目標プロバイダを使用する目的で、元のアプリケーションによる許可に関連する新しい承認を要求するためにセキュリティ制御装置１００と連絡する。
【０１３０】
４．セキュリティ制御装置１００及び元のアプリケーションは、例えば、ＩＰネットワーク通信用のセキュア・ソケット層（ＳＳＬ）のような確立したプロトコルにより相互認証を行う。
【０１３１】
５．元のアプリケーションは、目標プロバイダからセキュリティ制御装置１００に送られた承認を提示する。
６．セキュリティ制御装置は、元のアプリケーションのための新しい承認を生成するために、元のアプリケーションから受信する承認を使用する。この新しい承認は、元のアプリケーションに関する情報を含むことができる。別の方法としては、上記情報は、元のアプリケーションの実行に関連する１人又は複数の当事者の識別に関連する高いレベルのプライバシーを維持するために、元の目標プロバイダの承認に関する承認に単に関連することもできる。
【０１３２】
７．元のアプリケーションは、添付のハンドル又は他の識別子を含むことができる目標プロバイダへこの一時的な承認を提示する。
８．目標プロバイダは、情報を使用し、それをセキュリティ制御装置１００の公開鍵と照合することにより一時的承認を確認する。別の方法として、又は追加的に、目標プロバイダは、この確認の実行に関連してセキュリティ制御装置１００により直接チェックすることもできる。この直接通信の一部として、セキュリティ制御装置１００により目標プロバイダに追加情報を提供することができる。
【０１３３】
９．受信した一時的承認の情報に基づいて、目標プロバイダは、目標プロバイダ及び／又は目標プロバイダから入手することができるサービス／製品の制御の下で、１つ又は複数のリソースを含むことができる元のアプリケーションへのアクセスを許可又は拒否する。
【０１３４】
図４を参照しながら、所望のプライバシーの維持に特に関連する連合に加入したアーキテクチャのさらに特殊な用途について説明する。この例の場合には、車両リソースは、車両ユーザが購入した製品に対する支払い、特にファースト・フード販売業者からの食品に
対する支払いのために使用される。この製品の購入に関連するセキュア取引を提供する連合の一部であるエンティティは、支払いの許可に関連する車両ユーザと一緒に、販売業者、金融機関（例えば、銀行）及びセキュリティ制御装置１００を通しての車両自体、及び承認リポジトリ７８を含む。この取引の例は、下記のステップを含む。
【０１３５】
１．車両ユーザ又は消費者は、支払いを要求する販売業者へ注文する。
２．セキュリティ制御装置１００は、支払い要求を受信し、支払い情報に関連する政策決定エンジン８２へ問合わせを行うことができる。政策決定エンジン８２は、セキュリティ制御装置１００が提出した問合わせに基づいて、必要な確認した又は署名した承認を受信するために、データベース９０又は他の適当な承認又は信用状リポジトリ９４にアクセスすることができる。
【０１３６】
３．決定エンジン８２は、車両ユーザへ支払い額、及び例えば、ヒューマン・インタフェース４０による支払いの選択を供給することができる。販売業者とセキュリティ制御装置１００との間には信頼関係が存在しないので、支払い額及び受領証は機密保護されていないし、信用もされない。セキュリティ及び信頼を確立するには、金融機関又は銀行を使用する。
【０１３７】
４．決定エンジン８２は、ユーザ入力をベースとする購入のための借り方の銀行口座を選択する。
５．次に、決定エンジン８２は、銀行口座及び信任状リポジトリ９４内の接続情報を発見する。信任状リポジトリ９４は、承認リポジトリ７８の一部として表示されているが、車両から遠く離れた場所に設置することもでき、このような任意の遠隔のリポジトリから必要な情報を入手するには、認証及び許可プロセスを実行しなければならない。
【０１３８】
６．一実施形態の場合又はそうしたい場合には、銀行と通信しているセキュリティ制御装置１００の助け及び制御を借りて、予め確立した永続的識別子を使用するのではなく、決定エンジン８２によりセキュリティ及び匿名性を強化することができ、取引を識別するために一時的な偽名を入手することができる。
【０１３９】
７．その位置がどこであれ、信任状リポジトリ９４は、決定エンジン８２へ 取引に関連する銀行名及び識別子を返送する。信任状リポジトリ９４が車両から遠い場合には、決定エンジン８２は、セキュリティ制御装置１００により無線セッションを使用して信任状リポジトリにアクセスすることができる。
【０１４０】
８．次に、決定エンジン８２は、セキュリティ制御装置１００へ銀行名及び取引識別子を含むことができる支払い信任状を供給する。
９．これらを入手した後、セキュリティ制御装置１００は、販売業者へ支払い信任状を送信する。
【０１４１】
１０．販売業者は、銀行により認証及び許可を行う。
１１．販売業者は、銀行支払い信任状を送信する。
１２．銀行は、セキュリティ制御装置１００により認証及び許可を行う。
【０１４２】
１３．銀行は、セキュリティ制御装置１００へ支払い要求を提示する。
１４．セキュリティ制御装置１００は、車両ユーザへ支払い要求を提示する。
１５．車両ユーザは、支払い要求を受領する。
【０１４３】
１６．セキュリティ制御装置１００は、支払い許可を表示し、銀行へ送信する。
１７．銀行は、支払いが販売業者に対して行われたことの肯定応答を行う。
図５を参照しながらもう１つの連合に加入したセキュリティ取引について説明する。この例の場合には、車両ユーザは名前を明らかにしないで使用料の支払いを行うことができる。連合のメンバーとしては、使用料エンティティ、ディレクトリに関連していて、輸送に関連しているシャトル会社、承認リポジトリ７８の決定エンジン８２と一緒に、セキュリティ制御装置１００を有する車両等がある。この取引例に関連するステップ及び通信としては下記のものがある。
【０１４４】
１．料金所エンティティは、相互認識証明書機関を使用するセキュリティ制御装置１００との認証済みのＳＳＬ接続をスタートする。
２．料金所エンティティは、支払い要求を提示する。
【０１４５】
３．セキュリティ制御装置１００は、適当な支払い源について決定エンジン８２に問い合わせる。
４．決定エンジン８２は、車両から遠隔地に位置するディレクトリとの認証済みセキュア接続をスタートし、確立する。
【０１４６】
５．決定エンジン８２は、ディレクトリへ許可済み承認を提示する。
６．ディレクトリは、シャトル会社が署名した又は許可した適当な支払い情報を含む信任状を生成する。
【０１４７】
７．決定エンジン８２は、セキュリティ制御装置１００へ信任状を返送する。
８．セキュリティ制御装置１００は、料金所エンティティへ信任状を提示する。
ある実施形態の場合には、アクセスを許可する前に、シャトル会社自身により追加の確認を行うことができる。次に、料金所エンティティにより支払いを行うことができ、又は取引を集計することができ、その後で、それらをその確立した関係に基づいてシャトル会社に提示することができる。関連実施形態の場合には、遠隔のディレクトリからのセキュリティ信任状の代わりに、永続的なキャッシュ付き承認は、セキュリティ制御装置が直ちにアクセスすることができる信任状に依存することができる。
【０１４８】
図６は、もう１つの名前を表示しない取引の例を示す。このシナリオによると、ハイヤー用のタクシーには名前を表示しないで支払いが行われ、タクシーのユーザ又は乗客は、デジタル署名されたレシートを受け取る。連合のメンバーとしては、クレジット・カード会社のような金融機関、公共運送会社又はタクシー会社、及びセキュリティ制御装置１００を含む車両リソース、及び承認リポジトリ７８を含むことができる車両ユーザ・デバイス等がある。クレジット・カード会社及びタクシー会社間の連合関係により、タクシーの運転者は、タクシーのユーザ又はクレジット・カード番号の識別を知る必要はなく、車両ユーザとタクシー会社との間に信頼関係がなくてもよい。この取引のステップ及び通信は下記のものを含む。
【０１４９】
１．タクシーのセキュリティ制御装置１００は、例えば、ラップトップ、携帯電話又はタクシー・ユーザに対する承認リポジトリ７８を含む他の消費者デバイスを使用するタクシー料金の支払いのためのソースであるという警告を受ける。
【０１５０】
２．目的地に着いた場合、セキュリティ制御装置１００はタクシー・メータからの料金の金額を読み出す。
３．セキュリティ制御装置１００は、予め存在している接続でもよいタクシー会社との認証済みのセキュア接続を確立する。
【０１５１】
４．タクシー会社へタクシーの識別子を伴う料金が送信される。
５．タクシー会社は、署名入り又は許可済みの料金承認又は応答を生成する。
６．セキュリティ制御装置１００は、タクシー・ユーザの消費者デバイスへ割当て料金を送信する。
【０１５２】
７．消費者デバイス自身は、支払いを許可するか、又は自分が料金の支払いに責任を負うというその表示を行うクレジット・カード会社を直接認証する。好適には、この通信はＳＳＬ保護されていることが好ましく、別の方法としては、又はそうしたい場合には、通信はインターネット・プロトコル（ＩＰ）層のところで暗号化できることが好ましい。そうすることにより、タクシー及びすべての他の乗客が料金を支払うタクシー・ユーザが通信する銀行に関する情報を入手することができなくなる。
【０１５３】
８．消費者デバイスは、クレジット・カード会社へ署名入り料金承認を送信する。
９．クレジット・カード会社は、タクシー会社と認証を行い、署名入り料金情報に基づいて支払いを行う。
１０．次に、タクシー会社は、タクシーのセキュリティ制御装置１００へ支払いの肯定応答を送信する。
１１．次に、セキュリティ制御装置１００は、消費者デバイスへ支払い肯定応答を送信することができる。
【０１５４】
ある実施形態の場合には、料金承認は、取引情報、料金の金額、タクシー識別子を含む属性承認であり、また走行の出発地と行き先のような他の情報も含むことができる。この場合、このようなすべての情報は、タクシー会社により承認又は許可される。
【０１５５】
ユーザ・アプリケーションの一部として支払いを含む必要がない連合に加入した環境のもう１つの例の場合には、出荷中の荷物又は他の品目の現在位置をチェックすることができるように、ステップ及び通信が記述される。図７を参照しながら、品目を受領する会社及び配送会社は、相互に受諾した条件を受け入れる。この例のこれらの手順又はステップは下記のものを含む。
【０１５６】
１．受領会社の出荷管理者は、会社のコンピュータへログオンする。
２．出荷管理者は、配送会社へ出荷物の位置を問い合わせる。
３．出荷管理者に関する情報が、出荷管理者が位置情報を入手することができるようにする決定を行いまた許可を与える目標ウェブ・サービスへ機密保護状態で転送される。出荷管理者に関する転送された情報は、受領会社の識別、出荷会社での出荷管理者の役割、及び品目追跡番号を含むことができる。出荷管理者に関する情報の転送に関しては、ある実施形態の場合には、シボレス（Ｓｈｉｂｂｏｌｅｔｈ）アーキテクチャとして識別されたミドルウェア・ソフトウェア・システム又はモジュールを使用することができる。シボレスアーキテクチャは、アクセス制御を受けるリソースの共有をサポートする周知のアーキテクチャである。
【０１５７】
４．情報が送られる目標ウェブ・サービスは、署名入り又は許可済み承認を生成する。この署名入り承認は、品目を含む車両のセキュリティ制御装置アドレス、ＧＰＳアクセス特権を指定するセキュリティ制御装置１００が信任した１つ又は複数の信任状、及び一意のセッション識別子又は許可を受けていない追加の使用及び／又は他の潜在的誤用を防止するために、出荷管理者を要求にリンクするハンドルを含むことができる。
【０１５８】
５．車両内のセキュリティ制御装置１００のアドレスをベースとして、ＳＳＬセッションが、出荷管理者とセキュリティ制御装置１００との間に直接確立される。
６．信任状が、関連有効チェックを行うセキュリティ制御装置１００へ提示される。
【０１５９】
７．ある変形例の場合には、セキュリティ制御装置１００は、信任状の有効性を確認す
るために配送会社に連絡することができ、車両位置取引に関する追加情報を要求することができる。このような場合、信任状は、認証情報及び許可情報を含んでいる必要はない。何故なら、これら情報は配送会社が供給するからである。
【０１６０】
８．次に、セキュリティ制御装置１００は車両ＧＰＳ座標を要求する。
９．これらの座標は、位置情報を要求した車両内のセキュリティ制御装置１００に返送される。
１０．ＧＰＳ座標は出荷管理者に送られる。
【０１６１】
この例のさらに有意な変形例の場合には、受領会社のサイトは、受領会社とセキュリティ制御装置１００の間のすべての相互関係に対してフロント・エンド・ポータルとしての働きをする。別の方法の場合も、到着推定時間を、車両の実際のＧＰＳ位置の代わりに出荷管理者に送ることができる。
【０１６２】
連合の実施のさらにもう１つの例の場合については、図８を参照しながら、特定のソフトウェア診断ツールを使用している車両の保守について説明する。車両診断ソフトウェア・ツールを実行するために、車両のバスへのセキュア・アクセスが許可される。連合のメンバーとしては、車両ディーラ又は製造業者、及び車両の保守に関連するエンティティ、及びセキュリティ制御装置１００を有する車両自体等がある。ある実施形態の場合には、車両ディーラが、この診断ソフトウェアの使用を許可する信任状を生成する。信任状は、特定の車両及び／又は期間に対する特有なものであってもよい。このアプリケーションに関連するシーケンスは下記のものを含む。
【０１６３】
１．ソフトウェアの使用に関連する信任状及び車両バスへの同時アクセスは、ソフトウェアを動作できるようにするために、車両診断エンティティのラップトップのようなコンピュータにロードされる。
【０１６４】
２．コンピュータ上の診断アプリケーションは、車両のセキュリティ制御装置１００とセキュア・セッションを確立する。
３．診断アプリケーションは、セキュリティ制御装置１００に信任状を提示する。
【０１６５】
４．セキュリティ制御装置１００は、ディーラとのセキュア接続を確立する。
５．セキュリティ制御装置１００は、確認のためにディーラにソフトウェア内に含まれている信任状を提示する。
【０１６６】
６．ディーラは信任状を確認する。
７．セキュリティ制御装置１００は、車両ディーラにより車両バスへのアクセスが許可された場合には、車両の所有者の許可を求めることができる。
【０１６７】
８．車両の所有者は、車両エンジン・バスへのアクセスを許可する。
９．セキュリティ制御装置１００は、車両エンジン・バスにアクセスし、情報を要求する。
１０．セキュリティ制御装置１００は、エンジン・バスから情報を読み出す。
１１．セキュリティ制御装置１００は、次にこの情報をコンピュータに送信する。
【０１６８】
車両エンジン・バスから情報を入手するプロセスは、信任状の確認が行われた後で反復して何度も行うことができる。信任状があれば、エンジン・バスに指定の時間の間及び／又は制限された回数だけアクセスすることができる。好適には、信任状は、個々の各コンピュータ又は他の診断デバイス宛に生成するのが好ましく、診断ソフトウェア自身に宛てて生成してはならない。
【０１６９】
本発明の上記説明は本発明を説明し、記述するためのものである。さらに、上記説明は本発明を本明細書に記載の形に制限するものではない。それ故、関連する技術の技量及び知識の上記開示による変更及び修正は、本発明の範囲に含まれる。上記実施形態は、さらに、本発明の実行の現在周知の最善のモードを説明するためのものであり、当業者がその実施形態又は他の実施形態及びその特定の適用又は用途に必要な種々の修正により本発明を使用することができるようにするためのものである。添付の特許請求の範囲は、従来技術が許す範囲の他の実施形態も含むものと解釈すべきである。
【図面の簡単な説明】
【０１７０】
【図１】セキュリティ制御装置が中央ハブ又はスイッチとして機能する、本発明のシステムのある実施形態のブロック図。
【図２】セキュリティ制御装置がシステムのためにセキュリティ機能を実施するが、中央ハブ又はスイッチではない、システムのもう１つの実施形態のブロック図。
【図３】元のアプリケーションによる目標サービスの使用を許可／認証するためのステップ及び通信を示す図面。
【図４】連合に加入したセキュリティ・フレームワーク内で製品（例えば、食品迅速購入アプリケーション）を機密保護状態で購入するためのステップ及び通信を示す図面。
【図５】連合に加入したセキュリティ・フレームワーク内で料金支払いを機密保護状態で行うためのステップ及び通信を示す図面。
【図６】連合に加入したセキュリティ・フレームワーク内で機密保護状態で輸送料金を支払うためのステップ及び通信を示す図面。
【図７】連合に加入したセキュリティ・フレームワーク内で車両位置アクセス情報を機密保護状態で入手するためのステップ及び通信を示す図面。
【図８】連合に加入したセキュリティ・フレームワーク内で消費者デバイスにより車両バスに機密保護状態でアクセスができるようにするためのステップ及び通信を示す図面。
【技術分野】
【０００１】
本発明はテレマティクスに関し、特に車両内での専用リソースの使用を含む機密保護通信に関する。
【背景技術】
【０００２】
商用車両及び個人用車両の使用目的を、単なる輸送手段から通信ハブ手段に拡張するのに役に立つ種々の技術が考案又は促進されてきた。車両は、安全、運行、情報収集、娯楽及び教育に関連する目的を含む多数の目的を提供し又は容易にするために、遠隔システムと無線で通信することができる。車両内及び車両との通信は、通常、車両の外部からの通信を送受信することができる携帯電話又は他の通信ソース／デバイスを含む。
【０００３】
車両通信を改善するためにかなりの努力が行われてきたが、テレマティクス分野の大きな潜在能力を実行するにはかなりの障害が依然として存在している。車両通信は、車両内に常駐するハードウェア及び／又はソフトウェアを含むことができる多数のシステム及びデバイスを必要とする場合がある。これらのものは、所有者又は借り手のようないくつかのエンティティに特有なものである場合がある。車両メーカ及びその他の当事者は、第三者が専用システムを使用することができるようになることを非常にいやがる。自動車メーカの場合には、車両インタフェース、記憶メモリ、車両バス及び車両デバイス内に多数の所有権を有する場合がある。第三者が不法に又は制御できない状態でアクセスできると、このようなシステムの安全性及び保全性が心配になる。十分な経済的及び財政的理由がなければ、第三者によるアクセス及び使用を許可することはできない。それ故、車両を含む通信を容易にする物理的インフラストラクチャを提供するばかりでなく、投資に対する経済的動機及び十分な利潤を提供することも重要である。
【０００４】
テレマティクスの潜在能力を発揮させるには、自動車メーカ、携帯電話を含む通信デバイスの製造業者、アプリケーション開発者及び通信サービス・プロバイダを含む多数のエンティティ間の協力が必要になる。これらエンティティのうちの１つ又は複数は、考慮に入れなければならないし、保護しなければならない専有の技術又は利害関係を有している。例えば、ハンドセット製造業者はハンドセットに関連しているし、車両メーカは車両デバイスに関連している。専有権を保護する代わりに、専有車両システム及び技術を利用するやむにやまれぬ用途が出現するまで、テレマティクスの開発は順調に進まないだろう。さらに、車両自体が、人体の安全性に対する信頼性が非常に重要な複雑なシステムである。試験し、配備された車両システムに何らかの修正を行った場合には、新しい危険が発生する。一方、専用システムの機密を保護し、種々のエンティティにより共有できるようになった場合には、セキュリティの問題はもはや欠点ではなくなり、車両通信に関連する全コストを低減することができる。さらに、車両内の専用システムへの受け入れ可能なアクセスを使用することができるようになれば、豊富なアプリケーションのセットを開発することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
それ故、多数の及び種々の車両通信に関連するエンドユーザを含む専用システム及び多数の当事者の利害関係を保護するためのフレームワークを提供できれば有利である。エンドユーザの利害関係は、ユーザのプライバシーの少なくともいくつかのアプリケーション保護を含むことができる。金融取引を行うために車両内のリソースを使用した場合には、エンドユーザのプライバシーは保護される。適当なセキュリティ及び／又はプライバシー保護の他に、十分な報酬を含む車両に関連するリソースに自由にアクセスすることができ
るようにする動機を提供する種々の当事者間に関係を確立することが望ましい場合もある。
【課題を解決するための手段】
【０００６】
本発明は、車両内の専用リソースを含むリソースを使用するためのシステム及び方法を提供する。このような使用を行うには、車両に搭載してある、又は車両内に設置することができるリソース内に専用及びその他の利害関係を有するエンティティ間に関係を確立する必要がある。関係の確立は、車両内の専用及び／又は非専用リソースと一緒に使用するリソースの承認、及び承認したリソースだけを使用するという確認と一緒に種々のエンティティ間の補償規定の定義を含む。
【０００７】
専用リソースは、下記のもの、すなわち、車両バス、車両デバイス、インタフェース、サブシステム、車両内の記憶メモリ、車両内で実行するアプリケーション、連結ハードウェア／ソフトウェア及び通信デバイスのうちの１つ又は複数を含むことができる。車両内のデジタル・バスは、ＭＯＳＴ、ＩＤＢ１３９４、ＴＴＰ、ＣＡＮ、ＦｌｅｘＲａｙ、ＬＩＮ、ＳＡＥ Ｊ１９３９、ＳＡＥ Ｊ１７０８／１５８７、ＳＡＥ Ｊ１８５０、ＩＳＯ９１４１、及び多数の専用及び非専用リソースと通信する共通なバスを含む。共通バスは、上記バス技術のうちの１つ又は複数をベースとすることができる。また、共通バスは、無線技術により実施することもできる。専用サブシステム及び／又は車両デバイスは、種々の電子制御ユニット（ＥＣＵ）、ナビゲーション全地球測位システム（ＧＰＳ）、インフレータ・サブシステム又はデバイス、携帯情報端末（ＰＤＡ）、ラップトップ・コンピュータ、車両監視システム（ＶＭＳ）、及び事故及び緊急通知アラーム（ＡＥＮＡ）を含むことができる。インタフェースは、多数の及び種々のアプリケーション・プログラミング・インタフェース（ＡＰＩ）を含むことができる。通信サブシステムは、認可及び非認可通信チャネルを使用する無線技術ネットワークと通信するポータブル又は携帯電話及びサブシステムを含むことができる。専用及び／又は非専用アプリケーションは、車両に供給される娯楽、車両からのデータ収集、車両に供給される教育情報、車両内の１つ又は複数のサブシステム及び／又は車両デバイスが使用するために車両に送信される情報に関連するアプリケーションを含むことができる。これらのアプリケーションは、セキュリティ・サービス、多重ユーザ・サービス、車両間通信サービス、地理的サービス、定期サービス、通信サービス、及び商用サービスに関連するものを含む種々の分野又はエリア内のものであってもよい。
【０００８】
相互に受け入れることができる条件に基づいて関係を形成することができるエンティティは、一次エンティティとしての車両メーカ、及びアプリケーション開発業者／プロバイダ、政府機関、通信、金融、ビジネス及び消費者サービス・プロバイダ、製品及び専用サブシステムのプロバイダ、及び／又はデバイス供給業者、及び車両の所有者／ユーザを含む他のエンティティ等がある。これらのエンティティのうちの２つ以上が協力する条件は、１つ又は複数の固定支払い、少なくとももう１つのエンティティへの少なくとも１つのエンティティが行う使用料支払い、地理的要件、リソース使用制限、及び非適応への救済策をベースとすることができる。必要な関係の確立に関連する一番重要な要因は、このようなリソース及びリソースのセキュリティに関連するこれらの安全性を考慮に入れた場合の相互に使用するためのリソースの認定を含む。エンティティのうちの少なくともいくつかは、メンバーであるエンティティが相互作用の一部として、セキュリティ要件及びプロトコルを受け入れる連合に加入したセキュリティ・アーキテクチャが実施する連合のメンバーになることができる。
【０００９】
システムのリソースは、車両に対して無線通信を行うことができる１つ又は複数の通信サブシステムを含む。これらの通信サブシステムは、その関連するインタフェース及び無線ＬＡＮ（ローカル・エリア・ネットワーク）のような１つ又は複数の適当な無線技術と
通信できるようにするための他の装置と一緒に携帯電話を含むことができる。システムは、また、車両バスに接続している車両デバイスから入手した情報にアクセスすることができる車両ゲートウェイを含むこともできる。好ましい実施形態の場合には、車両ゲートウェイは、多数の専用及び／又は非専用リソースと通信することもできる共通バスと通信する。
【００１０】
システムは、また、共通バスに接続しているセキュリティ制御装置を含む。セキュリティ制御装置は、所望のセキュリティを行うため、特に２つ以上のエンティティによるリソースの使用の制御を行うために、すべての情報が通過するハブとして機能することができる。セキュリティ制御装置は、エンティティ及び／又はリソースのセキュリティ認証に関連していて、エンティティ及び／又はリソース間のセキュア・チャネルの確立を容易にし、バス及び帯域幅調停サービスを提供する。セキュリティ制御装置は、本質的には、システム内でスイッチとして機能し、他のリソース又はサービスに対して代理として機能することができる。エンティティ及び／又はリソース間のすべてのトラヒックは、経路指定されるか、又は始動はセキュリティ制御装置により仲介される。セキュア・セッションが確立された後で、セキュリティ制御装置は、トラヒックを監視するために必要な場合だけ介入しさえすればよい。監視は、例えば、トラヒックが、１つ又は複数の特定のアプリケーションの所定のプロファイルに適合しているかどうかの確認に関連することができる。ある実施形態の場合には、セキュリティ制御装置は、ハブ又はスイッチとして共通バスに内蔵されていないで、確立した関係に関連する条件が満たされていることの確認に関連してその制御を行うために、共通バスと通信し、セキュリティに関連する活動を監視する。
【００１１】
好ましい実施形態の場合には、システムは、さらに、セキュリティ制御装置が認証サービスを提供することができる多数のインタフェース・モジュールを含む。これらのサービスは、通信サービス・モジュール、人間／機械インタフェース・サービス・モジュール、及び車両サービス・モジュールとして識別することができる。通信サービス・モジュールは、通信に関連するリソースへのアクセスを保護し、調停する。ヒューマン・インタフェース・サービス・モジュールは、表示及びオペレータの介入又は関与に関連するリソースへのアクセスを調停する。車両サービス・モジュールは、１つ又は複数の車両バスに接続している車両デバイスから入手した情報へのアクセスに関連する補助を含む車両ゲートウェイ・サービスへのアクセスを制御する。ある実施形態の場合には、これらのインタフェース・モジュールはセキュリティ制御装置に内蔵される。
【００１２】
システムの実施又はシステムに関連するステップ、動作及び／又は手順については、エンティティはその関係を確立する条件を受け入れる。これらの条件は、３つ以上のエンティティの条件と同じであってもよいし、異なるものであってもよい。例えば、関係の確立は、車両メーカ及びアプリケーションの所有者、又は専用車両デバイスと一緒に使用される、又は実行することができるアプリケーションに専用の利害関係を有する他のものを含むことができる。もう１つの関係を、この同じ自動車メーカと、アフター・マーケット車両デバイス又はアドオン車両デバイスのような専用サブシステム供給業者との間に確立することができる。自動車メーカ及びサブシステム供給業者が受け入れた条件は、自動車メーカとアプリケーション開発業者又は他のアプリケーション供給エンティティとの間の関係を確立する条件とは異なるものであってもよい。これに関連して、このようなアプリケーション・エンティティは、自動車メーカとサブシステム供給業者との間の関係を確立する条件と同じか又は異なる条件を含むサブシステム供給業者との関係を確立することができる。これらの条件は補償及びリソース使用に関連することができる。
【００１３】
関係のこのような確立は、また、システムが使用する承認、信任状又は証明書を発行することができる認証局の授権を含むことができる。認証局は、基本的に、車両内で使用するために承認されたリソースに対して機密保護状態で証明書を発行することについて責任
を持つ。このようなリソースは、専用のものでも非専用のものであってもよい。これらのリソースは、他のリソースを使用するアプリケーションを含むことができる。認証局は、車両メーカのような関係を確立するグループ内に含まれるエンティティのうちの１つであってもよく、又は認証局は独立の第三者であってもよい。認証局は２つ以上であってもよく、また認証局は、車両セキュリティ・ドメイン内のリソースに信任状を発行する車両内に常駐することができる。セキュリティ制御装置自体は、認証局として機能することができ、車両サブシステム又は他の車両リソースに証明書を発行することができる。承認されたアプリケーション及び／又はサブシステムに対して証明書を発行する他に、認証局は１つ又は複数のエンティティ自身の証明に関与することもできる。
【００１４】
ある実施形態の場合には、証明プロセスは、支持している所望のセキュリティに関連する１つ又は複数の署名鍵により初期化される認証局を有する。認証局は、公開鍵及び秘密鍵のペアを生成することができる。公開鍵は、セキュリティ制御装置に渡され、この制御装置に提出される１つ又は複数の証明書の署名を確認又は認証するために使用することができる。認証局は、また、１つ又は複数のアプリケーションが証明書を要求することができるようにする鍵をアプリケーション開発業者に発行することができる。例えば、認証局は、アプリケーション開発業者に送る少なくとも証明書要求秘密鍵を生成することができる。アプリケーション開発業者は、認証局に送られるアプリケーション証明書要求を生成するためにこの秘密鍵を使用する。認証局は、証明書に対する要求を許可するかどうかを決定する。この決定に関連して、いくつかの手順を実施することができる。認証局はこれらの手順を実施することができる。別の方法としては、アプリケーション確認機関のような他のエンティティもこれらの手順を実施することができる。このような機関は、アプリケーション開発業者のセキュリティの実行の監査、及び行動及び安全性を考慮するための多数のシステム環境内でのアプリケーションの試験に関連するステップを実行することができる。承認された場合には、認証局は証明書を発行することができる。証明書は、証明書の所有者への一意の識別子、アプリケーションに割り当てられた優先順位、証明書の有効期間、証明書が有効であると考えられる地理的位置又は他の位置、アプリケーションが正しく機能するために通信しなければならない他のリソース及び／又はエンティティの識別又は記述、及びアプリケーションを使用することができるＡＰＩのようないくつかの特性及び／又は権利を含むことができる。
【００１５】
証明プロセスは、補償類似クレジット又は関連エンティティが同意した１つ又は複数の条件の一部として支払うことができる特許使用料と相互関係を照合される確立された関係の他の側面と関連することもできる。証明書は、また、資格を失ったアプリケーションに対して無効にすることもできる。セキュリティ制御装置はリボケーション情報を含んでいて、そのためその認証プロセス中、セキュリティ制御装置は、特定のアプリケーションに対する証明書が無効にされているかどうかを判断することができる。
【００１６】
アプリケーションに対して証明書が許可された後で、証明書の内容によるアクセス及び使用が許可される。この機能の一部として、セキュリティ制御装置は、このようなアプリケーションが要求したアクセスを監視することができる。セキュリティ制御装置が許可した後で、アプリケーションは、証明書に表示されている特性及び／又は権利に基づいて、車両内の１つ又は複数のリソースと一緒に動作することができる。すでに説明したように、アプリケーションは、多数の使用又は機能に対する多数の及び種々の分野で多くの形をとることができる。
【００１７】
上記要約を読めば、本発明の多くの利点を容易に理解することができるだろう。本発明は、アーキテクチャ及び方法論を供給することにより、車両内でのテレマティクスの使用を拡張するので、所望の動機及びセキュリティに適合することができる。車両通信のための多数及び種々のアプリケーションの開発が奨励され、支持されている。車両リソースの
使用は、本発明のフレームワークにより強化することができる。乗客の安全性及び便宜性は、車両及びその乗客と通信するためのさらに多くのまた異なる方法を容易に行うことができるようにすることにより促進される。リソースを共有すれば、車両のユーザにさらに多くのサービスを提供することができ、同時にコストを低減することができる。より詳細に説明すると、本発明は車両リソースの統合性を保護する。ユーザ及び車両情報のプライバシーがよりよく保護される。テレマティクス・アプリケーションにさらに安全にアクセスし、車両内のリソースをさらに安全に使用することができる。アプリケーション・レベルで所望のセキュリティの実行に関連する基準及び手順が提供される。車両に関連する機能の選択及び機密保護の実行が促進される。アプリケーションの使用及び加入に関する支払いのような追加の歳入の流れのための機会が促進される。セキュア遠隔診断機能及び車両のソフトウェアのセキュア・アップグレードも含まれる。モバイル広告及び顧客に優しいプログラムを含む新しいビジネス又は市場モデルを容易に作成することができる。複数の車両バスが、さらに丈夫になり、他の車両のリソースとの通信に適合することができる。通信経路のインテリジェントでセキュアな選択も行われる。消費者及び／又はビジネスへのサービス及び／又は製品の供給に関連するリソースにアクセスする場合に、ユーザのプライバシーを保護する連合に加入したセキュリティ・フレームワークを使用するセキュリティ手段を実施することができる。
【００１８】
下記の説明を読めば、特に添付の図面を参照しながら読めば、本発明の他の利点を容易に理解することができるだろう。
【発明を実施するための最良の形態】
【００１９】
図１を参照すると、この図は車両により位置を決定することができるテレマティクス・セキュア・システム２０を示す。システム２０は、車両へ及び車両から通信を行うための装置又はサブシステムを含む。内蔵されたセルラー・トランシーバ及び最近開発された装置を含む多数の装置のうちの１つ又は複数を使用することができるが、そのうちのくつかの装置について説明する。音声及びデジタル・コマンド及びデジタル・データのようなデジタル及び／又はアナログ情報を送信／受信するために、携帯電話２４を車両内に保持することができる。携帯電話２４を使用すれば、車両の外で車両のリソースと通信したい遠隔ソースへ／からのものを含む無線通信を行うことができる。携帯電話２４は物理的に保持することができ、ドッキング／インタフェース・サブシステム２８により車両通信経路に電子的に適合することができる。このサブシステム２８を使用すれば、特に携帯電話２４が手ぶらモードで動作している場合、車両ユーザ（運転者及び／又は乗客）との通信を容易に行うことができる。携帯電話の種々の構造及びモデルの中から選択することができる携帯電話２４のように、ドッキング／インタフェース・サブシステム２８は、選択し使用する特定の携帯電話２４と互換性を有する１つ又は複数の異なる装置であってもよい。１９９４年７月２６日付けの米国特許第５，３３３，１７７号、１９９６年７月９日付けの米国特許第５，５３５，２７４号、２００２年４月２３日付けの米国特許第６，３７７，８２５号、及び２００２年１月２２日付けの米国特許第６，３４１，２１８号を含む本出願の所有者と同じ譲受人に譲渡された特許に、いくつかのドッキング／インタフェース・サブシステムの実施について開示されている。
【００２０】
ある実施形態の場合には、ドッキング／インタフェース・サブシステム２８は、通信サービス・モジュール３２と通信するか、又はこのモジュールに関連付けられている。モジュール３２は、車両内の又は車両に関連する通信リソースへのアクセスを保護し、調停する実行可能なプログラム・コードからなるソフトウェアであってもよい。通信サービス・モジュール３２に関連することができる基本機能としては、車両に関連する他のリソースに対するインターネットへの通信経路のサポート、車両内の１つ又は複数のバス上のセキュア通信への貢献、故障通知の出力、通信関連リソースの監視及びロギング使用、通信リソースに対する使用規則の施行、及び車両に関連するリンク及び／又はリソースの使用に
関連する認証及び許可を含むセキュリティ制御に関連するツールの管理等がある。通信サービス・モジュール３２は、また、２０００年９月１９日付けで、同様に本出願の譲受人に譲渡された米国特許第６，１２２，５１４号に開示されているように、通信リンクの自動又はインテリジェントな選択をサポートするために使用することもできる。車両に内蔵させることができる他の無線通信サブシステムとしては、無線ＬＡＮ３６及び無線ＰＡＮ３８がある。携帯電話２４のように、無線ＬＡＮ３６及び無線ＰＡＮ３８サブシステムは、通信サービス・モジュール３２により正しく調停及び保護されている車両への送信、また車両からの送信を行うために、互換性を有するインタフェース（例えば、ドッキング／インタフェース２８）と通信することができる。
【００２１】
通信リソースの他に、システム２０は、オペレータ又は人間相互作用又は制御を行うことができるようにヒューマン・インタフェース４０を含むことができ、また視覚的表示及び／又はオーディオ出力により、車両のユーザに情報を提供することもできる。ヒューマン・インタフェース４０は、多数の入力／出力機構又はデバイスを有することができる。これらの機構又はデバイスは、タッチ又は接触によるようないくつかの知覚的入力を受信するための適当な技術により実施される触覚及び／又は生体認証入力サブシステム４４を含むことができる。触覚デバイスは、ユーザが所望の制御情報を入力したり、既存の設定を修正したりすることができるようにするボタン、スイッチ、タッチ点／スクリーンのようなプログラム可能な入力素子を含むことができる。視覚情報又は走査情報に関連する入力も、これらのサブシステム４４のうちの１つ又は複数を使用して供給することができる。１つ又は複数の音声／オーディオ入力又はサブシステム４８も、ヒューマン・インタフェース４０の一部であってもよい。これらのサブシステム又は技術を使用することにより、音声入力を、音声認識機能を始動、又はそうでない場合には、制御する際に役に立つ所望の制御／コマンド目的に対して受信することができる。このようなサブシステム４８からのオーディオ出力は、娯楽、教育、予め記録した音声プロンプト、及び音声入力をベースとする応答及び指示（テキスト音声変換出力）の供給を含む他の情報の必要な目的を含む任意の数の目的のために使用することができる。１つ又は複数のディスプレイ５２は、ヒューマン・インタフェース４０の一部であってもよい。ディスプレイ又はディスプレイ５２のうちの１つは、位置関連情報を提示するためのナビゲーション目的のものであってもよい。ディスプレイ又はディスプレイ５２も、要求した車両デバイス情報を表示するために使用することができる。媒体入力５６は、記憶媒体としてのハード・ディスク、ＤＶＤ及びＣＤ−ＲＯＭ機械、及びマップ・データベースのような車両内で所望の媒体を見たり及び／又は聞いたりすることができるようにする１つ又は複数のサブシステムを含むことができる。通常、ヒューマン・インタフェース４０は、車両の一部であり、車両メーカ専用の１つ又は複数の構成要素及び／又はサブシステムを含む。
【００２２】
通信リソースのように、ヒューマン・インタフェース４０は、多くの点で通信サービス・モジュール３２に類似しているマン／マシン・インタフェース・サービス・モジュール６４を含む。マン／マシン・インタフェース・サービス・モジュール６４は、１つ又は複数の車両バス上のセキュア通信をサポートし、ヒューマン・インタフェース４０に関連する故障通知を行い、オペレータ・サブシステム及び構成要素に関連するリソースの使用、ヒューマン・インタフェース４０に関連する警察使用規則を監視し、ロギングすることができ、またヒューマン・インタフェース４０の構成要素／サブシステムの正しい使用の確認に関連するツールの監視及び管理に関連することができる。
【００２３】
また、多数の他のサブシステムをテレマティクス・セキュア・システム２０の一部として固定状態に又は取り外すことができるように組み込むこともできる。サブシステムは、元来の車両装置の一部として提供することもできるし、後で車両の付属装置として追加することもできる。これらのサブシステムは、専用リソースであっても、非専用リソースであってもよい。このようなサブシステム内の専用利害関係は、車両メーカ自身内に常駐す
ることもできるし、又は車両へのアクセスが許可されている他の当事者内に常駐することもできる。サブシステムは、車両に関連する地理的情報又は位置情報を提供する全地球測位システム（ＧＰＳ）７０、１つ又は複数のコンピュータ７４、及び記憶メモリ７６を含むことができる。１つ又は複数のコンピュータ７４は、ポータブル・タイプのものでもよいし、車両の乗客による使用のために車両から取り外したり、車両に組み込むことができるタイプのものであってもよい。コンピュータ７４は、携帯情報端末（ＰＤＡ）、ラップトップ、又は任意の他のインテリジェント及び／又は処理ユニットを含むことができる。コンピュータ７４は、システム２０の他のリソースに関連する通信、及び車両外部の通信を送受信するために使用することができる。記憶メモリ７６は、車両内及び／又は外に位置する他のリソースの使用に関連する専用データ及び／又はプログラム・コードを含むことができる。記憶メモリ７６は、また、１つ又は複数のハード・ディスク及び／又はＣＤ−ＲＯＭのような取り外し可能なメモリを含むことができる。
【００２４】
サブシステムは、また、車両内でデバイス８８が生成することができる、又は車両内でセキュリティ手段に関連する又はそれをサポートするエンティティ、又は任意の他の認可された第三者が生成することができる署名入り又は署名無しの情報を記憶し、及び検索する働きをする承認リポジトリ７８を含むことができる。このような情報は、１つ又は複数の車両リソースにより、実行中又は実行しようとしている通信、取引及び／又は他の活動に関連するエンティティに関連する特性に関連する情報又は声明を含む承認を含むことができる。承認の内容は、１人又は複数のユーザ又は関連する当事者のプライバシーを保護しながら、所望のアクセス及び／又は使用を許可するのに十分な情報を供給するために他の方法で変更することができる。ちなみに、通信に関連する特定の承認、権利、義務及び／又は能力に基づいて、取引及び／又は他のものを定義又は記述することができる。
【００２５】
承認リポジトリ７８は、政策決定エンジン８２及びデータベース９０を含むことができる。政策決定エンジン８２は、複数の記憶している情報のうちのどの情報を特定の要求に対して提供するのか決定する。その決定を行う際に決定エンジン８２が依存することができる要因は、要求者の識別、要求されている情報及び適当なユーザの承諾の存在を含むことができる。１つ又は複数の決定は、第三者との通信からの情報又は結果をベースとすることもできる。また、提供のための追加情報を入力するために、第三者を利用することもできる。また、データベース９０内に追加情報を記憶するために、またこのような追加情報を受け入れるかどうかを決定するために、要求を処理するように決定エンジン８２を構成することもできる。署名のある又は署名のない情報を、特定のサービス又は製品プロバイダ、すなわち目標プロバイダの使用の許可又は拒否に適用することができる。データベース９０は、特定のサービス又は製品又は情報の入手に関連するアクセスの許可に関連する任意の数の署名のある又は署名のない承認を記憶することができる。これらの承認は、政策決定エンジン８２の要求に対して使用することができ、データベース９０は、決定エンジン８２の許可に対して又は許可によってだけこの情報を公開するように構成されている。データベースは、ＬＤＡＰ、ＸＭＬ及びＳＱＬを含む関連及び／又は目的データベースのような任意の数のデータ記憶技術を使用して実施することができる。承認リポジトリ７８に対する適当なアプリケーションについては、本明細書中のセキュア・テレマティクス・システム２０の使用の説明のところで記述する。
【００２６】
車両内の追加のリソースは、車両ゲートウェイ８０を含むことができる。車両ゲートウェイ８０は、従来から、１つ又は複数の車両デバイス８８が接続しているか、又は電子制御ユニット（ＥＣＵ）８６により通信する１つ又は複数の車両バス８４と通信する。各ＥＣＵ８６は、特定の車両デバイス８８を含む１つ又は複数のデジタル・バス８４に対してインタフェースとして機能し、このような各ＥＣＵは、個々に８６ａ、８６ｂ、８６ｃ．．．と表示することができる。ＥＣＵ８６は、本体制御装置、シャーシ制御装置、エンジン制御装置、変速機制御装置、及びテレマティクス制御装置のような多数の異なる制御サ
ブシステムのうちの１つ又は複数を含むことができる。本体制御装置は、通常、座席、ＨＶＡＣ、インストルメント・クラスタ、パワーウィンドウ、電動ドア及び他の車両デバイスのようなすべての車内装置を制御する。車両デバイス８８は、別々に８８ａ、８８ｂ、８８ｃ．．．のように表示することができる。車両バス８４は、１つ又は複数のデジタル・バスであってもよく、ＭＯＳＴ、ＩＤＢ１３９４、ＴＴＰ、ＣＡＮ、ＦｌｅｘＲａｙ、ＬＩＮ、ＳＡＥ Ｊ１７０８／１５８７、ＳＡＥ Ｊ１９３９、ＳＡＥ Ｊ１８５０、ＩＳＯ９１４１と呼ばれる周知のバスを含むことができる。車両デバイス８８は、エンジン・モニタ、エンジン温度センサ、圧力センサ、エアバッグを作動するためのインフレータ・システム及び／又は（例えば、シート・ベルトに張力を与えるための）車両張力生成デバイスを含むことができる。車両ゲートウェイ８０は、車両バス８４へのアクセス及びその使用を制御する。ちなみに、車両ゲートウェイ８０により、１つ又は複数のバス８４を通して特定の１つ又は複数のバス８４に接続している１つ又は複数の選択したデバイス８８にコマンドを送ることができる。車両ゲートウェイ８０は、また、無線通信インタフェース、及びアンテナ等による直接受信遠隔無線入力を有することができる。このような入力は、車両のドアのロック／アンロック及び遠隔車両エンジン・スタートをサポートする際に使用するデバイスを含む車両デバイス８８に制御信号を送るために使用することができる。
【００２７】
車両サービス・モジュール９２は、車両ゲートウェイ８０と通信する。通信サービス・モジュール３２及びマン／マシン・インタフェース・サービス・モジュール６４のように、車両ゲートウェイ８０に関連する通信は、車両ゲートウェイ制御車両バス８４及び車両デバイス８８へのアクセスを制御するための車両サービス・モジュール９２を通る。車両サービス・モジュール９２の機能としては、１つ又は複数の車両又はテレマティクス・バス８４上のセキュア通信のサポート、車内無線通信（例えば、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ）のようなＰＡＮ）の実行への貢献、要求を外部におくるための車両バス・アクセスの調停、車両ゲートウェイ動作に関する故障通知の提供、車両ゲートウェイ８０、車両バス８４及び／又は車両デバイス８８の使用の監視及びロギング、車両ゲートウェイ８０と通信するこのようなリソースの使用に関連する規則の施行、及びアクセス・キー及びアクセスを承認する証明書のようなセキュリティの提供に関連するツールの管理等がある。
【００２８】
機密保護状態で通信ができるようにするために、好適には、システム２０は、車両内の全部ではないにしても多数の通信可能なリソースが通信する共通バス９６を含むことが好ましい。この実施形態の場合には、共通バス９６は、これらのリソースをセキュリティ制御装置１００にリンクすることができる。セキュリティ制御装置１００は、通信可能なリソースへの通信が通過するハブ又はスイッチの働きをする。図１には、セキュリティ制御装置１００への独立ライン又は接続として表示してあるが、一緒にリンクした場合、このようなすべてのラインは共通バスを表すことを理解されたい。共通バス９６は、車両バス又はデジタル・バス８４を供給する又は実施する技術を含む多数の使用可能なバス技術のうちの１つをベースとすることができる。共通バス９６は、また、無線技術により実施することもできる。
【００２９】
共通バス９６は、物理層及び論理層を含むように定義することができる。共通バス９６の物理通信層は、一緒にシステム２０のいくつかのリソースに接続している。車両メーカは、通常、このようなバスの特性を制御する。共通バス９６は、少なくとも下記の機能、すなわち、広くサポートでき、多重ポートを有し、ピアツウピア機能を使用することができるように、アプリケーション、オープン・アーキテクチャ、標準化フィーチャをサポーするのに十分な帯域幅を有するものでなければならない。論理層は、共通バス９６上のリソースが相互に通信することができる方法を提供する。論理層は、異なる製造業者からの異なるリソースをバスに正しくリンクし、バスと通信することができるように構成される
。論理層は、デバイス間、サービス間、いくつかのサービスに対する要求を容易に行うことができるようにするアプリケーション・プログラム・インタフェース（ＡＰＩ）間で通信を行うことができるようにするために、いくつかの異なるプロトコルを含むことができる。サービスは、他のデバイスと通信するための自分自身のＡＰＩを定義することができる。定義することができるＡＰＩは、リソース間又はリソースとハブの間にセキュア接続を確立するためのセキュリティ制御装置１００、共通バス９６上のリソースに対するインターネット通信及び無線通信を可能にする通信サービスＡＰＩ、車両に対する状態検索及び制御サービスを可能にする車両ゲートウェイ・サービスＡＰＩ、位置情報の送信を可能にするためのＧＰＳ７０用のＡＰＩ、オペレータ・ユニット４０により情報を表示するための表示ＡＰＩ、リソース機能を登録するための登録関連ＡＰＩ、及び情報の一般的配布のための放送関連ＡＰＩを含む。いくつかのＡＰＩはすでに入手可能であり、例えば、ＡＭＩ−Ｃ（Ａｕｔｏｍｏｔｉｖｅ Ｍｕｌｔｉ−Ｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ Ｃｏｌｌａｂｏｒａｔｉｏｎ）は、車両ゲートウェイ８０と通信するための定義済みの一組のプロトコルを有している。システム２０に関連するセキュリティ・プロトコルは、ＡＭＩ−Ｃ及び他の現存のプロトコルと互換性を有する。
【００３０】
テレマティクスの成長を成功させるには、車両の動作が悪影響を受けることがないように、車両リソースへの不法な要求から保護する必要がある。車両通信は、本質的にリスクを伴わないもの、及び低いリスク及び中程度のリスクのような間に異なるリスク・レベルを有するリスクが高いものに分類することができる。リスクの程度は、情報の感知性、情報のプライバシー、及び不法な通信が存在する場合起こり得る損害の影響の程度を含む多数の要因をベースとすることができる。リスクは、送信機能に関連する１つ又は複数のリソース、受信機能に関連する１つ又は複数のリソースを含む主要な要因に基づいて査定することができる。主要なリスク要因は、送信に関連する特定のアプリケーションに関連する。アプリケーションは、車両デバイス又は装置の構成の変化、車両状態の表示、車両のファームウェアのアップグレード、車両診断の実行、１つ又は複数のアプリケーションのダウンロード、媒体情報のダウンロード、宣伝のダウンロード、位置情報の入手、及びセキュリティ承認の更新又はチェックを含むことができる。
【００３１】
ある実施形態の場合には、セキュリティ制御装置１００は、１つ又は複数のセキュア・プロセッサ、及びセキュア・プロセッサ内に組み込まれる又は内蔵されるＧＰＳ受信機を含むことができる。この組合わせにより、特にＧＰＳ情報を１つ又は複数の特定のセキュリティ制御装置の動作に正確に関連づけたい場合には、正しいセキュア動作を行うことができる。好適には、セキュリティ制御装置１００は、システム２０内に、リソースを含むすべてのトラヒックが通過する中央ハブ又はスイッチとして構成することが好ましい。セキュア・セッションが確立した場合には、セキュリティ制御装置１００は、１つ又は複数のアプリケーションを含むデータ又は他の情報を監視するために必要に応じて介入するだけでよい。セキュリティ制御装置１００は、１つのチップとして実施することができる。セキュリティ制御装置１００の代表的責任及び機能は下記の通りである。
【００３２】
ユーザの認証：セキュリティ制御装置１００は、多数のログインの記憶に関与することができ、ログインの実行に関連して認証情報を入手することができる。セキュリティ制御装置１００は、認証サービス、エンティティ、又は各ログインに対する一組の信任状を維持し、各ログインの識別についてセキュリティ制御装置１００に通知することができる他のリソースを信任することができる。このようにして、セキュリティ制御装置１００は識別を管理する。例えば、車両が点火した場合及びタクシー・フリートの所有者が認証サービスを提供した場合、ログインを行うことができる。他の例を挙げると、スマートカードは、中央病院をセキュリティ制御装置１００が信任している認証サービスとして使用して、ログインを行うことができる。セキュリティ制御装置１００は、個人識別番号（ＰＩＮ）スマートカード、パスワード又は生体認証情報（ｂｉｏｍｅｔｒｉｃ ｉｎｆｏｒｍａ
ｔｉｏｎ）を含む多数の形のうちの１つ又は複数内にユーザ識別情報を記憶することができる。この情報は、携帯電話２４、Ｗ−ＬＡＮサブシステム３６及び／又はＷ／ＰＡＮサブシステム３８のような通信サービス・モジュール３２と通信している１つ又は複数の装置又はデバイスを通して、又は、別の方法としては、ヒューマン・インタフェース４０から車両ユーザ識別情報を受信することができるマン／マシン・インタフェース・サービス・モジュール６４を通してセキュリティ制御装置１００に送ることができる。
【００３３】
セキュア位置及び時間：内蔵ユニットとして又はそれにより通信する独立型デバイスとして、セキュリティ制御装置１００は、ＧＰＳ受信機（例えば、ＧＰＳ７０）と通信することができる。この受信機は、位置及び時間情報のセキュア・ソースを提供する。ＧＰＳ受信機は、自分が提供する情報への不正変更を根絶するか最小限度に低減するように構成されている。この信任された時間及び位置情報は、車両内のいくつかのリソースに適用されるすべての位置的制限をチェックするために使用することができる。
【００３４】
セキュリティ監視：セキュリティ制御装置１００は、構成中又は認証中に確立したセキュリティ状態が時間が経過しても引き続きそのまま維持されていることを確認するために、リソース間の共通バス９６の活動及び車両バス８４の活動を監視する。例えば、バス活動に関連する時間的条件がある場合には、セキュリティ制御装置１００は、所定の時間イベントが起きた場合、セキュア・チャネル接続を動的に中断する。
【００３５】
バス調停：セキュリティ制御装置１００は、車両内に位置する１つ又は複数のバス上の優先順位の高い活動と優先順位の低い活動間で調停を行う。例えば、緊急事態が発生した場合には、セキュリティ制御装置１００は、デジタル・オーディオ又はビデオのようなすべての優先順位が低い活動を中止することができる。
【００３６】
アプリケーションの認証（公開鍵インフラストラクチャ）：セキュリティ制御装置１００は、登録したリソースに関連するデジタル信任状情報の登録を含む。アプリケーションが共通バスへのセキュア・アクセスを要求した場合には、アプリケーションは、セキュリティ制御装置１００にその信任状、又はそのような信任状を示す証明書を提示する。一般的に、バス９６上のすべてのトラヒックが暗号化されない限りは、共通バス９６へのアクセスは拒否される。セキュリティ制御装置１００は、バス９６上のセキュリティを責任を持って確保する。一方、アプリケーションは、暗号化したトラヒックを聴取する。セキュリティ制御装置１００は、無効な認証局の署名、無効な又は未知の特性、証明書の有効期間切れ又は無効化のような多くの根拠に基づいて、共通バス９６へのアクセスを要求しているアプリケーションを拒否することができる。証明書が本物であると考えられる場合には、セキュリティ制御装置１００は、アプリケーションに、関連する秘密鍵による暗号化操作の実行のような有効なアクセス情報の提示による信任状の主要部分であることを証明するように要求する。応答に成功した場合には、セキュリティ制御装置１００は、将来の取引又は送信のためにアプリケーションとのセキュア・チャネルを開くことができる。インターネット・アプリケーション、ラップトップ使用、ＰＤＡ使用、又は消費者アプリケーションの場合には、セキュリティ制御装置１００による認証のために個々の各アプリケーションが必要になる。デジタル証明書については以下により詳細に説明する。連合に加入したアーキテクチャを含むアプリケーション認証に関連する実施形態についても説明する。
【００３７】
多重鍵：セキュリティ制御装置１００は、また、１つ又は複数の機能にアクセスすることができる２つ以上の鍵又は他のセキュリティ・ツールを要求することができる。アプリケーション又は特定のエンティティ／ユーザを認証するために、２つ以上の要因又は要求が必要な場合がある。例えば、車両の設定を行うには、特定の電話（第１の要因）及びヒューマン・インタフェース４０を通して入力した特定のＰＩＮ又はパスワード（第２の要
因）が必要な場合がある。追加の要因としては、時間、位置情報、オペレータ又はユーザからの生体認証情報（指紋、声紋、顔紋等）又はユーザの認証前にインターネットを通して要求することができるような第三者情報を含むことができる。
【００３８】
多重リソース：セキュリティ制御装置１００は、複数のリソースが１つのアプリケーションに参加又は関連できるようにすることができる。例えば、ナビゲーション・アプリケーションを実行するには、オペレータ・ユニット４０、車両ゲートウェイ８０及びＧＰＳ７０のディスプレイ上で稼働しているソフトウェアの認証が必要になる場合がある。ＧＰＳ位置及びＧＰＳ時間を必要とするアプリケーションの使用を含む多くの他の例を実行することができる。
【００３９】
複数の公開鍵プロトコル及びアルゴリズム：セキュリティ制御装置１００は、いくつかの公開鍵インフラストラクチャ（ＰＫＩ）プロトコルを使用することもできるし、これらを意識することもできる。一方、特定のリソースは、このようなプロトコルの１つだけに関する情報を有することができる。これにより、アプリケーション・プロバイダは、その通信に適している多数のプロトコル及びアルゴリズムから選択を行うことができる。しかし、セキュア・チャネルが確立されると、正しい通信が行われるように１つのアルゴリズムだけを選択することもできる。
【００４０】
キャリーイン・デバイス・ファイアウォール：車両内で使用することができるコンピュータ７４へのすべてのインタフェースをサポートするために、セキュリティ・ファイアウォール機能をセキュリティ制御装置１００に内蔵させることができる。ファイアウォールは、車両内のリソースを無効な、不必要な又は間違った形の要求から保護する。システム２０が提供するサービス及び情報へのアクセスを必要とする、このようなキャリーイン・コンピュータ上で稼働しているアプリケーションは証明を必要とする。セキュリティ制御装置１００は、認証及びこのようなアプリケーションとの鍵交換を処理する。特定のアプリケーションが証明されなかった場合には、セキュリティ制御装置１００は、証明されなかったアプリケーションがある種の所定の車両サービスを受けることができるようにすることができる。
【００４１】
図２を参照すると、この図は、テレマティク・セキュア・システム２０−１のもう１つの実施形態を示す。セキュリティ制御装置１００−１は、共通バス９６−１上のもう１つの装置又はリソースとしてシステム２０−１に内蔵されている。このアーキテクチャによれば、セキュリティ制御装置１００−１は、図１の実施形態で使用することができるすべてのセキュリティ機能を実行する。しかし、セキュリティ制御装置１００−１は、図１の実施形態とは異なり、共通バス９６−１上でスイッチとしての働きはしない。このことはセキュリティ制御装置１００−１の効果の点で欠点になる場合がある。何故なら、共通バス９６−１のセグメントを分離する機能がないために、もはやすべての通信が共通バス９６−１上のリソース間を通過するスイッチ又は中央ハブとして機能しないからである。しかし、セキュリティ制御装置１００−１は、依然として複数の鍵による認証、位置をベースとする認証、及び証明書管理を行うことができる。他の実施形態の場合には、セキュリティ制御装置１００は、また、例えば、通信サービス・モジュール３２、マン／マシン・インタフェース・サービス・モジュール６４及び／又は車両サービス・モジュール９２のようなサービス・モジュールのうちの任意の１つと一緒になることができる。この構成は、併合するリソースによる認証を改善する利点がある。何故なら、同じリソースを構成する場合には、認証を行う必要がないからである。一方、図２の実施形態のように、共通バス９６を分離する機能は失われる。
【００４２】
セキュリティ制御装置１００が行う主な機能は、テレマティクス・セキュア・システム２０へのアクセス及びその使用のための許可に関する。これらの機能を行うために、セキ
ュリティ制御装置１００は、前に許可を受けたデジタル証明書又は他のデジタル・セキュリティ承認又は信任状に関連するいくつかのツールに依存することができる。証明書は、システム２０にアクセスし使用するための特性又は権利の許可を証明する。証明書は、例えば、車両メーカからとは異なるエンティティによる車両への追加装置であるサブシステムのような１つ又は複数の他のリソース、又は車両と一緒に内蔵されていて、取り外すことができる又はできない専用サブシステムを使用する車両内で稼働するアプリケーションのようなリソースに適用することができる。また、車両を含むリソースへのアクセス及びその使用のための安全及びセキュリティ要件を含むすべての要件に適合するものとして全体的に自分自身を確立したエンティティに適用される証明書を入手することができる。エンティティが証明されている場合で、エンティティがそこから入手することができるリソースに対する要件に適合するという証明された記録を有している場合には、このエンティティからのリソースは、車両と一緒に使用するために受け入れることができる。
【００４３】
通常、デジタル証明書はセキュリティ制御装置１００に提示される。証明書は、アプリケーションのようなリソースに適用することができる。セキュリティ制御装置１００は、特定の証明書の提示者（例えば、アプリケーションの所有者又は免許を受けているユーザ）が、証明書に関連する権利を有しているかどうかを判断する。この確認又は認証スキームが満たされると、通信のセキュア・チャネルをアプリケーションに対して確立することができる。セキュア・チャネルは、適当な暗号の使用を含むことができる。
【００４４】
証明プロセスは、多数の手順及びツールを含む。重要な部分は、セキュア・テレマティクス・システム２０内で使用するための証明書を交付する認証局（ＣＡ）の確立又は識別である。ＣＡは、このようなリソースを供給する車両及び／又はエンティティ内で使用するための承認されたリソースへの証明書を責任を持って発行する。ＣＡは、ある種の違反又は不履行が判明した場合には、前に許可したリソース及び／又はエンティティの権利を無効化することができる。ＣＡは、その中の少なくともいくつかについては後で説明する下記のもの、すなわち、認証局の秘密署名鍵のセキュリティ、公開鍵リストのセキュリティ、証明書の提出者が関連する秘密鍵を所有していることを確認する機能、各証明書により妥当な特性を割り当てるための機能、多数の証明書要求を満足させるために要求者への応答を自動化するための機能、及び一次ＣＡの代わりに認証局の機能を提供する権限を与えられているもう１つの又は二次ＣＡを指定するための機能であり、一次ＣＡ上で帯域幅要件を低減するために使用することができる機能に関連する。ＣＡは、１つ又は複数の車両メーカ、アプリケーション開発業者、サービス・プロバイダ、及びその代表者、及び車両メーカ及び車両リソース供給業者及び／又は開発業者から独立している１人又は複数の第三者を含む多数のエンティティのうちの１つ又は複数を含むことができる。
【００４５】
証明書に関連する手順及びプロセスについては以下に説明するが、セキュア・テレマティクス・システム２０で実行するための１つ又は複数のアプリケーションに対して供給される証明書又は他のセキュリティ信任状又は承認に関連して特に詳細に説明する。しかし、このようなプロセス及び手順は、このようなリソースに関連する他のリソース及びエンティティに適用できるように適合させることができることを理解されたい。主な証明プロセスは、１つ又は複数のＣＡ署名鍵により初期化されるＣＡ、このようなアプリケーションが証明書を要求することができるようにする、アプリケーション開発業者に一組の鍵を発行するＣＡ、アプリケーションによる証明書要求の生成、及びそれのＣＡへの配信、及び証明書の要求を許可し、それをアプリケーションに返送するＣＡを含む。
【００４６】
ＣＡ署名鍵生成プロセスに関して、ＣＡは証明書に署名するために使用される署名鍵又は一組の署名鍵を有する。ＣＡ署名鍵生成プロセスが１回実行され、１つ又は複数の鍵が物理的に安全な方法で記憶される。署名鍵の生成は、ＣＡ署名公開鍵（ＣＡＳＰＫ）、及びＣＡ署名秘密鍵（ＣＡＳＲＫ）鍵のペアを生成するＣＡを含むことができる。その生成
後に、ＣＡは、機密保護状態でＣＡＳＲＫを記憶する。ＣＡＳＰＫは、ＣＡによりセキュリティ制御装置１００に送られ、そこでセキュリティ制御装置に提出される証明書の署名を確認するために使用される。証明書上に種々の署名をすることができる、複数のＣＡ署名鍵のペアを生成することができる。その場合、公開鍵のリストが確認のためにセキュリティ制御装置１００と一緒に組み込まれ、ＣＡ署名鍵の索引が証明書に追加される。
【００４７】
次に、証明書の要求の生成ができるようにするために、車両のリソースになるアプリケーションの開発業者に、いくつかのセキュリティ・ツール又は情報が提供される。しかし、開発業者にこのようなアクセス・ツール又は他の情報を提供する前に、特定のアプリケーションが最初に承認される。ある実施形態の場合には、ＣＡとは異なるエンティティにより承認手順が行われる。この異なるエンティティは、アプリケーション確認機関（ＡＶＡ）と呼ぶことができる。別の方法としては、ＣＡは、また、アプリケーションの確認又は承認を責任を持って行う。１つ又は複数のエンティティの識別が何であれ、システム２０に入力されるアプリケーションは、安全で、機密保護されていて、所定のガイドライン内で動作することが許可され、責任を持って確認される。ＣＡであれ、又は他の１つ又は複数のエンティティであれ、ＡＶＡの承認は、ＣＡがアプリケーションに対して証明書を発行することができるようになる前に入手される。この認定機関からの承認は、下記の主要なプロセス、すなわち、アプリケーション開発業者によるＡＶＡへのアプリケーションの提出、ＡＶＡによるアプリケーション開発業者のセキュリティの実行の監査、行動及び安全性を判定するためのシステム２０を含む多数の環境内でのＡＶＡによるアプリケーションの試験、承認を受けることができるようになる前に修正が必要な場合の、ＡＶＡによるアプリケーション開発業者への書面による通知の提出、及びＡＶＡがＣＡとは異なる場合の、ＡＶＡにより確認された場合の、ＣＡへのアプリケーションの承認の通知を必要とする場合がある。
【００４８】
アプリケーション提出プロセスに関して、アプリケーション開発業者は、そのアプリケーションをセキュア・テレマティクス・システム２０に入力できるようにとの要求を行わなければならない。要求は、下記のもの、すなわち相互非公開協定、アプリケーションのコピー、アプリケーションの完全な説明、アプリケーションをシステム２０の一部とするための１つ又は複数の理由、アプリケーションがその機能を行わなければならない一組の特性及び／又は権利、及び１つ又は複数の秘密鍵を保護するために使用するセキュリティ・インフラストラクチャの説明を含むことができる文書を伴うアプリケーションを提出しなければならない。
【００４９】
アプリケーション承認プロセスに関して、ＡＶＡは、アプリケーション開発業者にシステム２０に入力するのを許可する前にセキュリティ監査を行う。この監査は、開発サイト及び／又は製造サイトでの鍵の保護が十分であることの確認を含む正しいセキュリティの予防措置及び手順が正しく行われたことを確認するための、ＡＶＡによるアプリケーション開発サイトへの訪問、ＡＶＡによる１つ又は複数の鍵の保護に関連するセキュリティ・ファームウェア又は他のソフトウェアの再検討、及びアプリケーションが車両内の安全に悪影響を与えないこと及びアプリケーションがシステム２０内で十分に動作することを確認するための多数のセキュア・テレマティクス・システム環境内でのアプリケーションの試験を含むことができる。
【００５０】
また、承認に関して、いくつかの関連要因が考慮され及び／又はチェックされる。第一に、アプリケーションのあるバージョンの承認は、１つ又は複数の後のバージョンを自動的に承認するものではない。第二に、証明書を受け取ったすべてのアプリケーションは不正な変更を受ける恐れがある。ハッカー社会の誰かが、予想しない又は望ましくない方法で実行するために、アプリケーションを修正しようとするかも知れない。開発業者コミュニティのうちの１人又は複数が、有効な証明書を取得した後で、自分自身のアプリケーシ
ョンを修正するかも知れない。修正を行うと、アプリケーションが元の仕様ではなくなるか、セキュリティが不完全なものになり、アプリケーションが望ましくないハッキング又は攻撃に曝されるかもしれない。整合性を確保するために、ＡＶＡは、アプリケーションの一部のセキュア・ハッシュを計算し、そのハッシュを証明書に内蔵するためにＣＡに供給することができる。現場に配備された場合、アプリケーションは、それ自身の同じ部分をセキュリティ制御装置１００に提出しなければならない。認証の一部として、セキュリティ制御装置１００は、同じセキュア・ハッシュを計算し、それが証明書内の値又は特性と一致することを確認する。
【００５１】
アプリケーションの承認プロセスは、また、実施の考慮事項と一緒に、アプリケーション開発業者に対するガイドライン及びアプリケーションに対するガイドラインの厳守を必然的に伴う。この点に関して、アプリケーション開発業者は、自分自身の開発施設及び製造施設で、鍵の物理的セキュリティを行わなければならない場合がある。例えば、このような鍵に物理的にアクセスするには、いつでも最低２人の人物が立ち会わなければならない。アプリケーション開発業者は、通信チャネルの盗聴、エンティティの欺瞞、サービス拒否攻撃（例えば、ネットワークの過負荷）、ソフトウェア又はファームウェアのエミュレーション及び診断バックドアを含むアプリケーションが受けるかも知れない種々のタイプの攻撃について知っていなければならない。アプリケーション開発業者は、確認機関により管轄されるモジュール及び確認機関が管轄しないモジュールにアプリケーションを分割しなければならない場合がある。明確に分割した場合には、開発業者は、確認機関のバージョン管理機構により管轄されないモジュールをさらに好適に改訂することができる。アプリケーションの開発業者は、現場での更新に対するセキュア・ダウンロード手順を行わなければならない場合がある。何故なら、セキュア・ダウンロード手順を行うと、望ましくないアプリケーションがセキュア・テレマティクス・システム２０内に入り込むのが防止されるからである。
【００５２】
アプリケーション用のガイドラインは、車両環境に敏感であること、又は車両環境と優れた互換性を有することを含むことができる。例えば、あるアプリケーションは、車両が移動していない場合だけ適正なものになり、車両が移動中には不適切なものになる。何故なら、運転者の注意がある程度散漫になるからである。各アプリケーションは、ハードウェア保護、鍵の不明瞭さ及び暗号化技術により、その１つ又は複数の鍵を保護しなければならない。各アプリケーションは、システム２０内の優先順位の概要を知っていなければならない。ある種のアプリケーションは優先順位が低いと見なすことができ、優先順位の高いアプリケーションにより終わらせることができる。
【００５３】
アプリケーションの実施要因に関して、確認機関は、行動監査、セキュリティ監査、安全監査を責任を持って行うことができる。確認機関は、これらの目的に適合するために、確認手順又は監査手順を行う目的でソフトウェア・ツール及びハードウェア・ツールに依存することができる。
【００５４】
開発業者が確認機関の要件に適合したと判断した場合には、１つ又は複数の証明書要求の生成に関連するプロセスを継続的に行うことができる。より詳細に説明すると、ＣＡは、証明書要求公開鍵（ＣＲＰＫ）及び証明書要求秘密鍵（ＣＲＲＫ）のペアを生成する。同時に、ＣＡは、この鍵のペアに証明書要求識別子（ＣＲＩＤ）を割り当てる。鍵ペア及び識別子を生成した後で、ＣＡは、セキュア手順、経路又は手段により、ＣＲＩＤ及びＣＲＲＫを開発業者に配布する。このようなセキュリティは、手渡しを含むことができ、又は現場訪問中に確立した独立のセキュア・チャネルを通して行うこともできる。ＣＡは、また、証明書要求公開鍵リスト（ＣＲＰＫＬ）と呼ぶことができるローカル・データベース内に新しいエントリを生成する。新しいエントリは、将来アクセスすることができるように開発業者のＣＲＩＤにリンクしている。一意の識別子はＣＲＰＫＬへの次に使用可能
な索引であってもよいし、又は全地球的に一意の識別子（ＧＵＩＤ）であってもよいし、又は関連するＣＲＰＫを探すために使用することができる任意の他の一意の値であってもよい。新しいエントリは下記の情報を含むことができる。
【００５５】
（ａ）アプリケーションに関連するＣＲＰＫ。
（ｂ）許可する証明書の特性。要求した特性値、権利及び／又はＣＡが発行することができる義務の範囲を制限する特性範囲を入力することができる。特定のアプリケーションに証明書が許可された場合には、これらの特性は証明書の一部になる。
【００５６】
（ｃ）アプリケーションに対する証明書の許可に関連する任意の追加規則。これらの規則は、許可する証明書の最大数、証明書を発行する前に、証明書の許可及び金融取引が確認される要求（例えば、支払う補償金又は料金）の時間制限を含むことができる。
【００５７】
このような情報は、また、アプリケーションのセキュア・ハッシュを含むことができる。セキュア・ハッシュは、許可なしで多量のデータを元に戻すのが数学的に極度に面倒になるように、多量のデータの少数のビットへの変換を含む。「メッセージ認証コード」を生成するために、セキュア・セッション鍵によりセキュア・ハッシュ値を暗号化することができる。
【００５８】
すでに説明したように、許可する証明書は多数の特性又は権利を有する。証明書内の特性は、任意の量の情報、すなわち、証明書の所有者に対する一意の識別子、優先順位の高いアプリケーションが、優先順位の低いアプリケーションより先に帯域幅の割当てを受ける場合に、アプリケーションに割り当てられる優先順位レベル、証明書の期限切れの日付及び時刻、証明書が有効な地理的位置、証明書が有効な無線ＬＡＮ「ホットスポット」識別子、アプリケーションが正しく機能するために通信するために必要なシステム２０の一部である他のリソース（セキュリティ制御装置１００は、アプリケーションが正しく稼働するのに必要なすべてのリソースを含む共通セキュア・チャネルを開くためにこの情報を使用する）、アプリケーションが使用することができ、それによりあるＡＰＩへのアクセスの制限が、ある種の証明書のセキュリティ・リスクを低減するＡＰＩ、例えば、車両情報の状態を読み出すコマンドへのアクセスだけを許可する証明書は、１つ又は複数の機能を行うために、車両サービスを制御するコマンドへのアクセスを許可する証明書よりリスクが小さい、及び／又はユーザの確認手順、又は外部の第三者の認証手順の形をとることができる追加の認証を含むことができる。
【００５９】
例えば、ＣＲＲＫの受信により、システム２０を使用する権利がアプリケーション開発業者に許可された場合には、開発業者はＣＡにアプリケーション証明書要求を発行することにより証明書を入手することができる。証明書要求プロセスは、証明書を受け取るアプリケーションのタイプにより異なる。この場合、アプリケーションは、その証明書及びアプリケーションの配布方法を受信する。アプリケーションは、下記のものを含む証明書を要求することができる。
【００６０】
電子サブシステムに組み込まれているアプリケーションは、セキュア・テレマティクス・システム２０で使用するために受け入れることができる状態でアプリケーションを出荷するためにその製造プロセス中にＣＡから証明書を要求することができる。
【００６１】
ハード媒体（例えば、ＣＤ−ＲＯＭ又はＤＶＤ）を通して配布されるアプリケーションは、アプリケーション開発業者が管理する証明書要求プロセスを１回受ける。その配布の一部として、証明書及び１つ又は複数の鍵がアプリケーション内に組み込まれる。
【００６２】
あるアプリケーションは、ＷＡＮ、ＬＡＮ又はＰＡＮネットワークを通して配布するこ
とができる。アプリケーション開発業者は、ダウンロードの際にアプリケーションに対する証明書の動的な入手を選択することもできるし、又はハード媒体配布アプリケーションのようにその都度証明書を要求することもできる。
【００６３】
あるアプリケーションは、エンドユーザ環境内で稼働しながら、新しい証明書を要求することができる。アプリケーションは、システム２０にアクセスするために、新しい又は更新した証明書を要求することができる。この機能により、料金の支払いを含むことができる新しい又は更新した証明書を入手することにより、現場でユーザはアプリケーションを動作できるようにすることができる。
【００６４】
アプリケーション又はアプリケーション開発業者が証明書を要求していようがいまいが、今識別したばかりのアプリケーション及び証明書公開鍵（ＣＰＫ）及び証明書秘密鍵（ＣＲＫ）のペアを生成するアプリケーション、不揮発性メモリ内にＣＲＫを機密保護状態で記憶するアプリケーション、下記の構成要素、すなわち、ＣＡへの要求者を識別するＣＲＩＤ、アプリケーションの公開鍵であるＣＰＫ、要求される他の証明書の特性、及びＣＡに対する要求者を認証するために使用するＣＲＳにより、ＣＲＲＫを鍵として使用して、上記すべての情報にデジタル的に署名することにより生成される証明書要求署名（ＣＲＳ）を含む証明書要求を生成するアプリケーション、及びＣＡへの要求を配布するアプリケーションを含む事実上すべてのアプリケーションに適用することができる基本的なステップを実施することができる。上記要求は必ずしも送信のためのセキュア・チャネルを必要としない。
【００６５】
証明書生成に関して、ＣＡは、供給されたＣＲＩＤを参照パラメータとして使用して、データベースからＣＲＰＫ特性、規則及びセキュア・ハッシュを検索する。ＣＡは、またＣＲＰＫを使用してＣＲＳを確認する。ＣＡは、ＣＲＩＤに関連する規則のどれも失敗しなかったことを確認する。例えば、ＣＡは、ＣＡが許可した証明書の有効期限がまだ期限切れになっていないことを確認する。さらに、ＣＡは、要求した特性が、要求中にセキュア・テレマティクス・システム２０に入力するのに合意した特性の範囲内に含まれていることを確認する。アプリケーションは、ある期限切れの期間に証明書を要求できなくてもよい。ＣＡは、セキュア・ハッシュ内の特性を含む証明書を生成し、またＣＡ署名秘密鍵（ＣＡＳＲＫ）でそれにデジタル的に署名する。上記のことを実施した後で、ＣＡは、要求者に完成した証明書を返送する。この返送は機密保護されていないチャネルを通して行うことができる。受信後、アプリケーションは、証明書内の公開鍵が証明書要求の元の一部であるＣＰＫと一致することを確認し、ＣＡの署名を確認することにより証明書が本物であることを確認するよう求められる。
【００６６】
証明書を受信すると、アプリケーションは、セキュア・テレマティクス・システム２０にアクセスすることができる。通常、このアクセスは、セキュリティ制御装置１００との相互作用を含む。より詳細に説明すると、証明されたアプリケーションは、セキュア制御装置１００に証明書と一緒にサービス要求を送信する。セキュア制御装置１００は、公開鍵で暗号化した乱数を含むチャレンジ要求をアプリケーションに返送することができる。アプリケーションは、そのローカル秘密鍵により乱数を解読する。アプリケーションは、制御装置１００に乱数応答を返送する。アプリケーションからの応答で制御装置１００が受信した乱数が、チャレンジのために暗号化した数と一致する場合には、サービス要求は許可される。許可されると、制御装置１００は、アプリケーションにスタートするサービス又はセッションの表示を送信する。
【００６７】
証明書は、通常、満期の日付まで有効である。しかし、所定の条件があってその条件に該当した場合には証明書は無効化される。例を挙げて説明すると、秘密鍵が外部に漏れた場合のように、アプリケーションが危険になった場合には無効化されなければならない。
ＣＡは、セキュリティ制御装置１００内に組み込むことができる証明書無効化リスト（ＣＲＬ）を維持することができる。セキュリティ制御装置１００は、アプリケーションが無効化されていないことを確認するために、その認証プロセス中、ＣＲＬを参照する。ＣＲＬの更新は、証明書自身内の追加の第三者認証に対する要件を含ませることによりサポートすることができる。
【００６８】
証明書の生成は、アプリケーション開発業者が必要とする場合があるセキュリティ・コードを供給する現在入手可能なツール・キットを使用することができる。これらのツール・キットはＲＳＡのＣｅｒｔ−Ｃ及びＣｅｒｔｉｃｏｍのＴｒｕｓｔＰｏｉｎｔを含むことができる。
【００６９】
生成された証明書は、料金、支払い、特許権使用料又は他の補償要件の追跡を含む他の用途に使用することができる。システム２０内で専用リソースにアクセスしたい場合には、このような専用リソースにアクセスしたい及び／又は使用したいということを示すために、デジタル証明書を発行することができる。アプリケーションに対して証明書を発行する度に、証明書データベースにエントリされる。専用リソースへのアクセスを可能にする発行証明書の番号を検索するために、データベースに問い合わせすることができ、前に決定した料金又は特許権使用料をこのようなアクセス又は使用に対して課金することができる。
【００７０】
セキュア・テレマティクス・システム２０を使用すれば、車両に関連する１つ又は複数の他のリソースと一緒に、安全な方法でセキュア・アプリケーションを使用することができる。さらに、使用中のアクセスを制御する目的で、その専用リソースを使用できるようにするために、リソース内に専用の利害関係を有する所有者又は他の人に動機が提供される。専用リソースは、非専用リソースとは対照的に、１つ又は複数のエンティティが、リソース内に法的に保護することができる専用の利害関係を有するリソースである。法的に保護することができる専用の利害関係は、特許、商業上の秘密、著作権及び契約をベースとする権利を含む１つ又は複数の法的に認識された知的所有権をベースとすることができる。リソースの使用及びその拡張、特に専用リソースの使用は、テレマティクス・セキュア・システム２０と関連することができるエンティティとの関係を確立することにより育成することができる。これらのエンティティは、車両メーカ、通信デバイス販売業者、通信サービス・プロバイダ、専用サブシステム供給業者、アプリケーション開発業者及び車両ユーザを含むことができる。関係の確立は、エンティティによる条件の定義及び受諾を含むことができる。権利及び義務のようなこれらの条件は、異なるエンティティ又はエンティティのグループに対して異なるものであってもよい。これらの条件は、使用することができるリソースの十分な記述又は識別、使用に関連する補償関連要因、使用期間、専用リソースを使用することができる特定の定義又は制限、使用することができる場所を指定する地理的制限、１つ又は複数の条件を満たさなかった場合の救済策、及び指定の機関によるアプリケーションのような専用リソースの承認を含む上記証明書の取得を含む他の関連要件を含むことができる。
【００７１】
受け入れることができるセキュリティと一緒に、正しい場所に正しい関係を確立すれば、テレマティクス・セキュア・システム２０の種々のユーザ及び／又はアプリケーションを事前に識別することができる。例えば、アフター・マーケット・オーディオ装置の販売業者は、オペレータに関連する制御装置及びディスプレイ又はヘッド・ユニット４０へ車両ラジオをインタフェースするために、車両内の専用リソース及び／又は非専用リソースにアクセスしたい場合がある。付属ラジオ製造業者は、また音声認識を含む車両にすでに内蔵又は組み込まれている手ぶら携帯電話の使用のような車両オーディオ・システム及び手ぶら機能にアクセスしたい場合がある。さらに、個人の又は他の所望のデータをアップロード及び／又はダウンロードすることができるように、車両ＰＤＡインタフェースにア
クセスしたい場合もある。無線装置の承認及びセキュリティ制御装置１００と一緒に機能するデジタル証明書の入手に基づいて、このようなリソースをアフター・マーケット供給業者が使用できるようにすることができる。この場合、車両に関連する１つ又は複数の専用リソースに、１つ又は複数の専用利害関係を有するエンティティとしての車両メーカは、加入及び／又は車両を再販売した場合、１回の定額の支払いの形をしている場合もあるこのようなアクセス及び使用のために受領した歳入のような車両メーカに動機を提供する条件を含む適当な条件を使用するこのような販売業者との関係を確立することができる。
【００７２】
車両に関連する他のリソースと一緒に使用する適用可能なリソースを含む多数の他のアプリケーションを識別又は記述することができる。セキュリティ、多重ユーザ、地理的、規制による通信及び商行為に関連するものを含む多くの一般的な用途がある。１つ又は複数のアプリケーションは、これらのグループ又は分類のうちの２つ以上に分類することができ、他のアプリケーションは、これらのうちの１つ又は複数に明確に分類することができない。代表的なアプリケーションのいくつかについて次に説明する。
【００７３】
車両構成：車両内に構成情報を送るために携帯電話２４を使用することができる。この構成情報は、運転者識別、座席位置、ミラー位置、ラジオ局プリセット、及び車両内に位置する他のサブシステム又はデバイスの使用を含むことができる。情報を受信した場合、これらのものをテレマティクス制御ユニット８０又は他の車両常駐計算デバイスからのコマンドにより調整することができる。このようなアプリケーションは、下記のステップを必要とする場合がある。
【００７４】
１）携帯電話２４は、電源供給時にクレードル（ｃｒａｄｌｅ）内に設置される。
２）「ＰＩＮ」、生体認証、スマートカード、音声コマンド等のようなオペレータ識別が入力される。
【００７５】
３）携帯電話２４は、この情報を受信し、車両構成アプリケーションがスタートする。
４）セキュリティ制御装置１００は、例えば適当な鍵交換により構成アプリケーションを認証する。
【００７６】
５）認証に成功した後、セキュリティ制御装置は、セキュア・セッションがまだ進行していない場合には、車両ゲートウェイ８０であってもよい適当なバス、車両バス又はバス８４へのゲートウェイを含む通信チャネルを動作できるようにするか、又は認証する。
【００７７】
６）セキュリティ制御装置１００は、共通の暗号化したセッション鍵を選択し、またその鍵を携帯電話２４及び車両ゲートウェイ８０へ配布する。
７）車両構成コマンドは、セキュア暗号化チャネルを介して携帯電話２４から車両ゲートウェイ８０へ送信される。
【００７８】
８）車両ゲートウェイ８０は、そうしたい場合又は適当である場合に、車両が停止している場合だけ構成調整を行うべきであると確認する。
９）構成アプリケーションを含む全体のアクセス及び使用の一部として、上記調整を行う前にユーザの肯定応答が必要な場合がある。
【００７９】
アプリケーションのもう１つの代表的例は、指定エンティティ又は機関に送信される通知をトリガする車両内のエアバッグのようなインフレータ・システムの作動を含むことができる。このアプリケーションの関連ステップは下記のものを含む。
【００８０】
１）システムの初期化中、ＧＰＳ７０、車両ゲートウェイ８０、セキュリティ制御装置１００、及び緊急の際に使用するための通信サービス・モジュール３２を含むセキュア・
アラーム・チャネルが確立される。
【００８１】
２）十分な車両衝撃を検出した場合、インフレータ・システムのエアバッグが作動又は展開する。
３）車両ゲートウェイ８０は、インフレータ・システムをそこに接続した場合に、内蔵車両バス８４の両端に起こる場合があるこの車両デバイスから１つ又は複数のエアバッグ関連アラームを受信する。
【００８２】
４）セキュリティ制御装置１００は、セキュア接続を通してのアラームを受信する。
５）セキュリティ制御装置１００は、ＧＰＳ７０からのＧＰＳ情報を受信し、この情報を通信サービス・モジュール３２へ供給する。通信サービス・モジュール３２は、携帯電話２４又はＷ−ＬＡＮ及びＷ−ＰＡＮサブシステム３６、３８のような他の通信サブシステムにより、車両の遠隔の指定エンティティ又は機関に通知するために通信をスタートする。
【００８３】
加入サービスを含むナビゲーション・アプリケーションも実施することができる。例を挙げて説明すると、ＧＰＳ及びヒューマン・インタフェース４０が内蔵するナビゲーション・アプリケーションと一緒に車両を売ることができる。アプリケーションを引き続き使用するには、加入を更新しなければならない。確認可能な金融取引に基づいて確認される証明書要求を生成することにより、認証局からリアルタイム証明書が入手される。このアプリケーションに関連していくつかのステップを次に説明する。
【００８４】
１）車両ユーザは、ナビゲーション加入が失効しようとしていること、サービスの１年間のような後続の期間の間のサービスを引き続き受けることができることの通知を受ける。
【００８５】
２）ユーザは、クレジット・カード番号のような電子支払い情報の入力により申入れを受諾する。ユーザが取引を行うことができること、すなわちユーザが車両の所有者であることを確認するために二次ユーザ認証が必要になる場合がある。
【００８６】
３）アプリケーションは、通信サービス・モジュール３２を通して金融機関とのセキュア・チャネルを要求する。セキュリティ制御装置１００は、通信サービス・モジュール３２を通して、アプリケーション間の及び金融機関との共通のセキュア・チャネルを開設することにより、この取引を行うことができる。
【００８７】
４）アプリケーション及び金融サービスは、ユーザの口座に課金するためにセキュア・チャネルを通して通信する。
５）金融サービスは、課金に対して確認番号で応答する。
【００８８】
６）アプリケーションは、金融取引の受領書として課金の確認番号を含む認証局への証明書要求を作成する。
７）アプリケーションは、セキュア・チャネルを必要としない証明書要求をＣＡに送信する。
【００８９】
８）ＣＡは、要求を受信し、課金が行われたことを金融機関と確認し、アプリケーションに対して１年間の証明書を発行する。
９）アプリケーションは、ＧＰＳ７０へのアプリケーションによるアクセスを可能にするために、セキュリティ制御装置１００へ新しい証明書を提示する。
【００９０】
１０）ＣＡは、特許権使用料によるものを含む起こり得る料金について、車両製メーカ
及びアプリケーション開発業者へ加入通知を配布する。
セキュア・テレマティクス・システムは、承認リポジトリの更新及び下記のものを含むことができる証明書無効化リストを含む証明書関連手段にも関連する。
【００９１】
１）システム２０は、証明書への更新を行うことができるという通知を受信する。この通知は、無線リンク又は車両又はデジタル・バスを含む有線接続を通して受信することができる。
【００９２】
２）車両ユーザは、更新が可能であり、更新のアップロードの肯定応答及び／又は承認することができるという通知を受けることができる。
３）セキュリティ制御装置１００は、ソフトウェア又は証明書のソースを認証する。
【００９３】
４）アップロードは、車両がある地理的領域内に位置している間だけアップロードできるというような位置による制限を受ける場合がある。このような場合、アップロードするためにアプリケーションに対して提示した証明書は、必要な地理的領域の識別を含む。
【００９４】
５）アップロードをある時間帯だけアップロードすることができるというように、時間により制限することもできる。
６）暗号化通信を含むセキュア・セッションが、証明書ソースとセキュリティ制御装置１００との間に設定される。
【００９５】
７）新しい証明書及び／又は証明書無効化リストであってもよい更新が、セキュリティ制御装置へロードされる。
８）セキュリティ制御装置１００は、デジタル署名による証明書及び／又はＣＲＬを認証する。
【００９６】
９）そうしたい場合には、本物であることを確認するために第三者に参照することができる。
１０）セキュリティ制御装置１００は、その不揮発性メモリ内へ新しい証明書及び／又はＣＲＬを記憶する。
【００９７】
アプリケーションを更新するために、類似の手順又はステップを使用することができる。セキュリティ制御装置１００も失効証明書に対して更新を要求することができる。証明書は所定の日付で失効する。このことは、加入をベースとするサービスの場合に役に立つ場合がある。このような場合、内蔵ＧＰＳ７０のようなセキュア時間ソースが必要である。ローカル・ホットスポットのところの無線通信ネットワーク・クロック確認も使用することができる。
【００９８】
次に、いくつかのグループ又は分類により他のアプリケーションについて説明する。下記のものはセキュリティ・アプリケーションに関連する。
保証及び品質管理のためのセキュアＶＩＮ：車両メーカは、保証及び品質保証に関連する記憶している情報の統合性が失われていないことを確認するために、セキュリティ制御装置１００を使用する。指定のエンティティ又は機関に送られる自動衝突通知を記録する作動ログを内蔵することができる。セキュアＶＩＮ証明書／鍵を車両メーカのプラントでロードすることができる。
【００９９】
車両ユーザ・アプリケーションに対する車両情報へのアクセス：自動車メーカは、認定所有者だけに、車両情報、運転者情報及び車両制御へのアクセスを許可するためにセキュリティ制御装置を使用することができる。本質的に、これは、所有者又は他の認定ユーザに対する車両へのセキュア鍵であってもよい。その一例が、携帯電話又はＰＤＡによる車
両のドアのアンロックである。
【０１００】
診断ツールに対するセキュア・アクセス：車両メーカは、認定されたツールを有する認定ディーラだけに、診断情報及び車両構成へのアクセスを許可するためにセキュリティ制御装置１００を使用することができる。
【０１０１】
サービス・プロバイダ・アプリケーションへのアクセス：車両メーカは、認定されたツールを有する認定サービス・プロバイダに車両情報、運転者情報及び車両制御へのアクセスを許可するために、セキュリティ制御装置１００を使用することができる。
【０１０２】
ユーザ・インタフェース・リソースへのアクセス：車両メーカは、認定されたアプリケーション及びデバイスだけに車両ユーザ・インタフェースへのアクセスを許可するために、セキュリティ制御装置１００を使用することができる。車両メーカは、例えば、ハンドルのボタン又は内蔵音声認識により携帯電話を制御することができるようにすることにより、運転者の不注意による事故のリスクを少なくすることができる。
【０１０３】
セキュア・フリート車両状態：フリート・オペレータは、そのフリートの各車両及び負荷状態データへのアクセスを制御するために、セキュリティ制御装置１００を使用することができる。この情報は、車両メモリ７６内に機密保護状態で記憶することができ、認定されたエンティティだけがアクセスすることができる。
【０１０４】
フリート管理のためのセキュア位置データ：フリート・オペレータは、そのフリートの位置データへのアクセスを制御するために、セキュリティ制御装置１００を使用することができる。位置情報は、車両メモリ７６内に機密保護状態で記憶することができ、認定されたエンティティだけがアクセスすることができる。
【０１０５】
位置データの保護：車両の所有者又は他の認定ユーザは、所有者の車両の位置データへのアクセスを制御するために、セキュリティ制御装置１００を使用することができる。位置情報は、車両メモリ内に機密保護状態で記憶することができ、認定されたエンティティだけがアクセスすることができる。
【０１０６】
車両追跡及びセキュリティ：内部ＧＰＳアセット、車両バス・アクセス及び車両通信は、トラック会社が運送中の有害な物質の現在位置の認識のような多くのレベルの車両の安全及びセキュリティを提供することができる。
【０１０７】
テレマティクス・セキュア・システム２０は、下記のものを含むマルチユーザ・アプリケーションに対して適合させることができる。
多数の認定車両ユーザ：システム２０に関連するリソースは、例えば、特定のユーザの特別な利害関係をベースとする各ユーザに対する「ホットスポット」のフィルタリング、各家族のメンバー、従者又は認定車両オペレータに対する車両制御の制限又は提示、及び特定のユーザの認証に関連する加入のような通信オプションを提供する際に、同じ車両の各認定ユーザ用に特別に及び一意に構成することができる。
【０１０８】
レンタカーのカスタマイズ：レンタル車両のユーザは、個人用携帯電話を使用するために、及び／又は無線局を選択する目的で個人ディレクトリをアップロードするためにレンタルされた車両と相互作用を行うことができる。
【０１０９】
下記のものを含む地理的及び／又は定期的アプリケーションにアクセスするためにテレマティクス・セキュア・システム２０を使用することができる。
トラヒック情報加入：オペレータ・ユニット４０の一部となっている場合があるナビゲ
ーション表示スクリーンにより、種々のレベルの交通地図、警報及び特殊なルートを表示することができる。
【０１１０】
車両汚染制御：排気を低減するために、又は車両を電力走行に切り替える目的で、車両内の制御装置を修正又は調整するために、システム２０にアクセスすることができる。
現在の道路状況：建設場所又は事故からある距離のところで関連情報を同報通信することができる無線リンク警報局により、前方の道路建設場所又は大きな事故の高度の警報を提供することができる。ヒューマン・インタフェース４０により、表示又は音声情報を使用して車両のユーザ又は運転者に警告することができる。
【０１１１】
気象状況：車両の運転者が、異なるルートへの変更の可能性を含む適切な措置をとるための十分な時間的余裕を持つことができるように、霧、氷及び／又は雪のような気象状況の高度な警告をシステム２０により提供することができる。
【０１１２】
境界横断及びチェック：政府機関は、境界横断及び重量チェックに関連する車両データへのアクセスを制御するために、セキュリティ制御装置１００を使用することができる。このような情報は、車両メモリ７６内に機密保護状態で記憶することができ、認定されたエンティティだけがアクセスすることができる。
【０１１３】
スモッグ試験：政府機関は、スモッグ試験に関連する車両データへのアクセスを制御するために、セキュリティ制御装置１００を使用することができる。このような情報は、車両メモリ内に機密保護状態で記憶することができ、認定されたエンティティだけがアクセスすることができる。
【０１１４】
アプリケーションのもう１つの分類は、一般的に、無線ＬＡＮネットワーク技術又は他のプロトコルを使用して車両を所望した又は要求した情報を受信するクライアントであると見なすことができる通信に関連する。車両へのダウンロードにより送られる情報は、下記のものを含むことができる。音楽（ＭＰ−３又はＷＭＡフォーマットなど）、住所録エントリ、ナビゲーション・システム更新及び個人ナビゲーション地図、文書同期及び更新、車両ＰＤＡとの同期、オンライン・ゲーム状態の更新、認定ユーザに対する車両許可の更新及び修正、特定のユーザに対する電子商取引アプリケーションを制御するためのファイアウォール許可、運転者確認及びグループ・チャットのサポートを含むことができる。音楽ダウンロードのさらに特種な例は、特定の地理的領域との関連を含むことができる。例えば、イエローストン・パークに入る車両の位置の認識に基づいて、この公園を通過する際にエンジョイするように編集された音楽の形で、車両の運転者及び乗客に特別な提供をダウンロードすることができる。このような特殊な音楽の提供は、車両に乗っている人に、無線通信ネットワーク・広帯域リンク等を介してセキュア・テレマティクス・システム２０により行うことができる。特殊な音楽に関連する提供を受信した後で、デジタル基金リソース７８により受信に関連する料金を支払うことができる。この支払いの後で、以降の演奏のために、オペレータのユニット４０に受信可能なフォーマットでこの音楽がダウンロードされる。
【０１１５】
テレマティクス・セキュア・システム２０のある種の電子商取引アプリケーションについてはこの後で説明する。
サービス・プロバイダとしての車両：認定されたエンティティが機密保護状態でアクセスすることができる承認リポジトリ７８を有する車両の場合には、車両は、承認リポジトリ７８を使用する取引により支払いが行われるサービス源となることができる。このようなサービスは、賃貸、金融、修理及び／又は車両の維持に関連するサービスを含むことができる。このようなサービスは、基本的なナビゲーション・サービス及び／又はこのようなサービスに対するプレミアムであってもよい。車両メーカは、適正な支払いが行われな
かった場合には、適切な制限を車両に対して行うことができる（例えば、サービスの打ち切り、車両の使用の規制）。さらに、車両は、支払いを含む条件に適合した場合には、作動可能な機能を有する構成済みのデバイス、サブシステム及び構成要素を有することができる。これらの機能は、ある時間の間、特別のエンジン馬力を使用できるようにすることもできる。ちなみに、承認リポジトリ７８を有する車両は、承認リポジトリ７８を使用することができるエンティティ又は個人に関連する他の確認を要求することができる。このリソースへのアクセスを確認するために、網膜スキャナ、指紋確認等のような種々の生体認証装置を使用することができる。
【０１１６】
消費者エレクトロニクス・デバイスへのアクセスへの制御：このようなデバイスの製造業者は、認定ユーザだけにアクセスを許可するために、セキュリティ制御装置１００を使用する。これは、車両内に位置している場合に、携帯電話又はＰＤＡのプレミアム機能をアンロックするセキュア鍵であってもよい。
【０１１７】
使用料の支払い：政府機関は、使用料及び駐車料金を支払う際に使用するための承認リポジトリ７８へのアクセスを制御するために、セキュリティ制御装置１００を使用することができる。公共及び民間運送会社も、システム２０を使用することができる。外部料金所ゲートへのＷｉＦｉリンクは、走行距離料金及び走行関連料金コストの組合わせを決定する際に、タクシーの料金メータと通信することができる。さらに、システム２０は、ＷｉＦｉ機能を有するタクシーの乗客のＰＤＡに電子領収書を送信することができる。
【０１１８】
第三者サービス及び販売促進：車両の運転者及びすべて乗客は、車両の所定の距離又は範囲内に位置するビジネス施設からのものを含む入手できる製品及びサービスに関連する通信を受信することができる。これらの加入サービス及び販売促進は、ガソリンスタンドでの購入の際のデジタル・クーポン、ホットスポット・インターネット特権、レストランのメニュー及びその販売促進、及びＩＰ長距離の無料音声のような通信の提供に関連づけることができる。
【０１１９】
マルチメディアのダウンロード：車両の運転者及び１人又は複数の乗客と相互に関係づけることができる個人の加入者識別に基づく加入により音楽及びビデオをダウンロードすることができる。
【０１２０】
多くの他のアプリケーションも使用できること、及び上記アプリケーションはその代表的なものであることを理解されたい。テレマティクス・セキュア・システム２０は、確立することができる関係及びこのようなアプリケーションのうちの１つ又は複数と一緒に使用するために又は実行するために識別又は考案することができるリソースによってだけ制限することができる多数の種々のアプリケーションに対する環境を確立する。
【０１２１】
セキュリティ制御装置１００は、また、リソースへのアクセス及びその使用も、連合のメンバーが供給する１つ又は複数の承認又は信任状及び／又はその組合わせをベースとする連合に加入したアーキテクチャの一部として構成することができる。この実施形態の場合には、セキュリティ制御装置１００は、車両リソースへのアクセス要求を許可し、認証する際に、代理又は信頼調停者としての働きをする。アクセス要求の許可及び認証に関連して、セキュリティ制御装置１００は、エンティティ又は要求者が供給する承認又はセキュリティ信任状の複雑な組合わせを評価することができる。信任状をベースとして、セキュリティ制御装置１００は、アクセスを許可すべきか拒否すべきかを決定することができる。承認は、信任された事業主が本当であると主張している情報の署名入りの集合体である。承認はある当事者を意味するか、関連することができるだけである。承認は、権利、特権及び／又は義務に同時に関連するいくつかのレベル又はクラスにより分類することができる。例えば、承認は、識別子、又は要求しているエンティティを車両保守メンバー、
輸送プロバイダ、車両燃料プロバイダ、及びハイウェイ使用料エンティティのようなサービス・プロバイダの特定のクラスに関連づける他の情報を含むことができる。
【０１２２】
セキュリティ制御装置１００は、また、それ自身のために又は車両内の他のリソースのために、承認又はセキュリティ信任状と関連することができる。いくつかの例は、車両位置情報の提供を許可するユーザ又は車両識別の提供を含む必要がない信任状の提供を含むことができる。車両の一部としてのセキュリティ制御装置１００は、連合のメンバーであるエンティティが、セキュリティ信任状又は属性のような承認のフォーマット及び内容について合意している連合に加入したセキュリティ環境内で動作することができる。これらもこれらの信任状を交換するためにプロトコルを受け入れる。セキュリティ制御装置１００は、それ自身のため、及びそのドメイン下の車両リソースのためにプロトコルを実施することができる。
【０１２３】
より詳細に説明すると、セキュリティ制御装置１００は、広く認識されているルートＣＡが発行した署名証明書により、車両内のリソースに証明書を発行することができる。同時に、セキュリティ制御装置１００は、接続しているリソース内での認証及び許可に関する埋め込まれた承認を理解することができる。ＰＫＩモデルは依然としてサポートされている。何故なら、これらのリソースに発行されたＰＫＣは、セキュリティ制御装置１００が使用することができる承認のタイプのサブクラスと見なされるからである。
【０１２４】
ある実施形態の場合には、新しいリソース（例えば、デバイス）が接続されると、その新しいリソースは、セキュリティ制御装置１００に連絡し、又はその逆を行い、新しい証明書が要求される。その名前でそのリソースに証明書を発行するかどうかの決定は、セキュリティ制御装置１００が行う。この決定は、リソースの位置（例えば、１つ又は複数の車両バスに接続している）、ユーザからの入力（例えば、「あなたが今接続したリソースは、Ａｃｍｅ社製のラジオ４０７ｂですか」という質問が行われ、後でそうするにはラジオをどうするのかを質問することができる）、セキュリティ制御装置１００がその発行及び他の適当な情報を確認することができるリソース内の予め埋め込まれた承認をベースとしている。これらすべての入力を使用して、証明書を許可するかどうかについて、入手できる最大量の情報によりインテリジェントな決定が行われる。
【０１２５】
識別証明書はいつでも発行しなければならないが、これら証明書に関連する許可特権は注意深く分割しなければならない。ここで制御及びビジネス・モデルを念入りに作ることができる。セキュリティ制御装置１００は、いくつかの情報に基づいて、インテリジェントでないアプリケーションに対してある種の許可を与えるかどうかについて決定する。インテリジェント・アプリケーションの場合には、このアプリケーションは、ドメイン制御装置としての働きをすることができ、これらの優れたリソースが、それ自身で所望の任意の方法で潜在的に許可を決定することができるようにする。いずれにせよ、セキュリティ制御装置１００は、必要な構成要素であり、課金システムを追加することができる他のリソースを使用するために、種々のリソースに許可を割り当てる際にいくつかのフックが存在する。
【０１２６】
セキュリティ制御装置１００が、車両内のリソースにそれ自身の証明書を発行できるようになると、関連するすべてのリソースの露出が大きく低減する。何故なら、新しい証明書を容易に局所的に発行することができるからである。セキュリティ制御装置の証明書の発行者のセキュリティが危険になった場合には、それが署名したセキュリティ制御装置に対して新しい証明書を発行するだけでよい。さらに、連合に加入した状態で許可及び識別を処理することができる。ラジオ製造業者は、セキュリティ制御装置１００が、製造業者と一緒に確認することができ、信頼できるかどうかを決定するラジオ内部で、許可の承認をまとめることができる。
【０１２７】
次に、図３を参照しながら、車両が、セキュリティ制御装置１００の制御下で、このような連合の一部になっている用途及び動作について概略説明する。セキュリティ制御装置１００は、元の又は要求しているアプリケーション、及び目標サービス・プロバイダ、目標製品プロバイダ、又は他のプロバイダであってもよい目標プロバイダと通信する。通常、要求しているアプリケーションは、特定の機能又は活動のために目標プロバイダを使用しようとする。元のアプリケーションによるアクセスを許可すべきかどうかの決定に関連して、元のアプリケーションが認証されているかどうか、またそのアプリケーションを実行するための資格を有しているかどうかを確認するためにいくつかの手順が行われる。これら手順の主なステップは下記のものを含む。
【０１２８】
１．元のアプリケーションは、ある製品、サービス、リソース又は他の情報を要求している目標プロバイダと連絡する。
２．目標プロバイダは、元のアプリケーション、目標プロバイダの名前による署名入りの承認、及び元のアプリケーションがアクセスすることができるようにするために必要な情報を送信する。
【０１２９】
３．元のアプリケーションは、目標プロバイダを使用する目的で、元のアプリケーションによる許可に関連する新しい承認を要求するためにセキュリティ制御装置１００と連絡する。
【０１３０】
４．セキュリティ制御装置１００及び元のアプリケーションは、例えば、ＩＰネットワーク通信用のセキュア・ソケット層（ＳＳＬ）のような確立したプロトコルにより相互認証を行う。
【０１３１】
５．元のアプリケーションは、目標プロバイダからセキュリティ制御装置１００に送られた承認を提示する。
６．セキュリティ制御装置は、元のアプリケーションのための新しい承認を生成するために、元のアプリケーションから受信する承認を使用する。この新しい承認は、元のアプリケーションに関する情報を含むことができる。別の方法としては、上記情報は、元のアプリケーションの実行に関連する１人又は複数の当事者の識別に関連する高いレベルのプライバシーを維持するために、元の目標プロバイダの承認に関する承認に単に関連することもできる。
【０１３２】
７．元のアプリケーションは、添付のハンドル又は他の識別子を含むことができる目標プロバイダへこの一時的な承認を提示する。
８．目標プロバイダは、情報を使用し、それをセキュリティ制御装置１００の公開鍵と照合することにより一時的承認を確認する。別の方法として、又は追加的に、目標プロバイダは、この確認の実行に関連してセキュリティ制御装置１００により直接チェックすることもできる。この直接通信の一部として、セキュリティ制御装置１００により目標プロバイダに追加情報を提供することができる。
【０１３３】
９．受信した一時的承認の情報に基づいて、目標プロバイダは、目標プロバイダ及び／又は目標プロバイダから入手することができるサービス／製品の制御の下で、１つ又は複数のリソースを含むことができる元のアプリケーションへのアクセスを許可又は拒否する。
【０１３４】
図４を参照しながら、所望のプライバシーの維持に特に関連する連合に加入したアーキテクチャのさらに特殊な用途について説明する。この例の場合には、車両リソースは、車両ユーザが購入した製品に対する支払い、特にファースト・フード販売業者からの食品に
対する支払いのために使用される。この製品の購入に関連するセキュア取引を提供する連合の一部であるエンティティは、支払いの許可に関連する車両ユーザと一緒に、販売業者、金融機関（例えば、銀行）及びセキュリティ制御装置１００を通しての車両自体、及び承認リポジトリ７８を含む。この取引の例は、下記のステップを含む。
【０１３５】
１．車両ユーザ又は消費者は、支払いを要求する販売業者へ注文する。
２．セキュリティ制御装置１００は、支払い要求を受信し、支払い情報に関連する政策決定エンジン８２へ問合わせを行うことができる。政策決定エンジン８２は、セキュリティ制御装置１００が提出した問合わせに基づいて、必要な確認した又は署名した承認を受信するために、データベース９０又は他の適当な承認又は信用状リポジトリ９４にアクセスすることができる。
【０１３６】
３．決定エンジン８２は、車両ユーザへ支払い額、及び例えば、ヒューマン・インタフェース４０による支払いの選択を供給することができる。販売業者とセキュリティ制御装置１００との間には信頼関係が存在しないので、支払い額及び受領証は機密保護されていないし、信用もされない。セキュリティ及び信頼を確立するには、金融機関又は銀行を使用する。
【０１３７】
４．決定エンジン８２は、ユーザ入力をベースとする購入のための借り方の銀行口座を選択する。
５．次に、決定エンジン８２は、銀行口座及び信任状リポジトリ９４内の接続情報を発見する。信任状リポジトリ９４は、承認リポジトリ７８の一部として表示されているが、車両から遠く離れた場所に設置することもでき、このような任意の遠隔のリポジトリから必要な情報を入手するには、認証及び許可プロセスを実行しなければならない。
【０１３８】
６．一実施形態の場合又はそうしたい場合には、銀行と通信しているセキュリティ制御装置１００の助け及び制御を借りて、予め確立した永続的識別子を使用するのではなく、決定エンジン８２によりセキュリティ及び匿名性を強化することができ、取引を識別するために一時的な偽名を入手することができる。
【０１３９】
７．その位置がどこであれ、信任状リポジトリ９４は、決定エンジン８２へ 取引に関連する銀行名及び識別子を返送する。信任状リポジトリ９４が車両から遠い場合には、決定エンジン８２は、セキュリティ制御装置１００により無線セッションを使用して信任状リポジトリにアクセスすることができる。
【０１４０】
８．次に、決定エンジン８２は、セキュリティ制御装置１００へ銀行名及び取引識別子を含むことができる支払い信任状を供給する。
９．これらを入手した後、セキュリティ制御装置１００は、販売業者へ支払い信任状を送信する。
【０１４１】
１０．販売業者は、銀行により認証及び許可を行う。
１１．販売業者は、銀行支払い信任状を送信する。
１２．銀行は、セキュリティ制御装置１００により認証及び許可を行う。
【０１４２】
１３．銀行は、セキュリティ制御装置１００へ支払い要求を提示する。
１４．セキュリティ制御装置１００は、車両ユーザへ支払い要求を提示する。
１５．車両ユーザは、支払い要求を受領する。
【０１４３】
１６．セキュリティ制御装置１００は、支払い許可を表示し、銀行へ送信する。
１７．銀行は、支払いが販売業者に対して行われたことの肯定応答を行う。
図５を参照しながらもう１つの連合に加入したセキュリティ取引について説明する。この例の場合には、車両ユーザは名前を明らかにしないで使用料の支払いを行うことができる。連合のメンバーとしては、使用料エンティティ、ディレクトリに関連していて、輸送に関連しているシャトル会社、承認リポジトリ７８の決定エンジン８２と一緒に、セキュリティ制御装置１００を有する車両等がある。この取引例に関連するステップ及び通信としては下記のものがある。
【０１４４】
１．料金所エンティティは、相互認識証明書機関を使用するセキュリティ制御装置１００との認証済みのＳＳＬ接続をスタートする。
２．料金所エンティティは、支払い要求を提示する。
【０１４５】
３．セキュリティ制御装置１００は、適当な支払い源について決定エンジン８２に問い合わせる。
４．決定エンジン８２は、車両から遠隔地に位置するディレクトリとの認証済みセキュア接続をスタートし、確立する。
【０１４６】
５．決定エンジン８２は、ディレクトリへ許可済み承認を提示する。
６．ディレクトリは、シャトル会社が署名した又は許可した適当な支払い情報を含む信任状を生成する。
【０１４７】
７．決定エンジン８２は、セキュリティ制御装置１００へ信任状を返送する。
８．セキュリティ制御装置１００は、料金所エンティティへ信任状を提示する。
ある実施形態の場合には、アクセスを許可する前に、シャトル会社自身により追加の確認を行うことができる。次に、料金所エンティティにより支払いを行うことができ、又は取引を集計することができ、その後で、それらをその確立した関係に基づいてシャトル会社に提示することができる。関連実施形態の場合には、遠隔のディレクトリからのセキュリティ信任状の代わりに、永続的なキャッシュ付き承認は、セキュリティ制御装置が直ちにアクセスすることができる信任状に依存することができる。
【０１４８】
図６は、もう１つの名前を表示しない取引の例を示す。このシナリオによると、ハイヤー用のタクシーには名前を表示しないで支払いが行われ、タクシーのユーザ又は乗客は、デジタル署名されたレシートを受け取る。連合のメンバーとしては、クレジット・カード会社のような金融機関、公共運送会社又はタクシー会社、及びセキュリティ制御装置１００を含む車両リソース、及び承認リポジトリ７８を含むことができる車両ユーザ・デバイス等がある。クレジット・カード会社及びタクシー会社間の連合関係により、タクシーの運転者は、タクシーのユーザ又はクレジット・カード番号の識別を知る必要はなく、車両ユーザとタクシー会社との間に信頼関係がなくてもよい。この取引のステップ及び通信は下記のものを含む。
【０１４９】
１．タクシーのセキュリティ制御装置１００は、例えば、ラップトップ、携帯電話又はタクシー・ユーザに対する承認リポジトリ７８を含む他の消費者デバイスを使用するタクシー料金の支払いのためのソースであるという警告を受ける。
【０１５０】
２．目的地に着いた場合、セキュリティ制御装置１００はタクシー・メータからの料金の金額を読み出す。
３．セキュリティ制御装置１００は、予め存在している接続でもよいタクシー会社との認証済みのセキュア接続を確立する。
【０１５１】
４．タクシー会社へタクシーの識別子を伴う料金が送信される。
５．タクシー会社は、署名入り又は許可済みの料金承認又は応答を生成する。
６．セキュリティ制御装置１００は、タクシー・ユーザの消費者デバイスへ割当て料金を送信する。
【０１５２】
７．消費者デバイス自身は、支払いを許可するか、又は自分が料金の支払いに責任を負うというその表示を行うクレジット・カード会社を直接認証する。好適には、この通信はＳＳＬ保護されていることが好ましく、別の方法としては、又はそうしたい場合には、通信はインターネット・プロトコル（ＩＰ）層のところで暗号化できることが好ましい。そうすることにより、タクシー及びすべての他の乗客が料金を支払うタクシー・ユーザが通信する銀行に関する情報を入手することができなくなる。
【０１５３】
８．消費者デバイスは、クレジット・カード会社へ署名入り料金承認を送信する。
９．クレジット・カード会社は、タクシー会社と認証を行い、署名入り料金情報に基づいて支払いを行う。
１０．次に、タクシー会社は、タクシーのセキュリティ制御装置１００へ支払いの肯定応答を送信する。
１１．次に、セキュリティ制御装置１００は、消費者デバイスへ支払い肯定応答を送信することができる。
【０１５４】
ある実施形態の場合には、料金承認は、取引情報、料金の金額、タクシー識別子を含む属性承認であり、また走行の出発地と行き先のような他の情報も含むことができる。この場合、このようなすべての情報は、タクシー会社により承認又は許可される。
【０１５５】
ユーザ・アプリケーションの一部として支払いを含む必要がない連合に加入した環境のもう１つの例の場合には、出荷中の荷物又は他の品目の現在位置をチェックすることができるように、ステップ及び通信が記述される。図７を参照しながら、品目を受領する会社及び配送会社は、相互に受諾した条件を受け入れる。この例のこれらの手順又はステップは下記のものを含む。
【０１５６】
１．受領会社の出荷管理者は、会社のコンピュータへログオンする。
２．出荷管理者は、配送会社へ出荷物の位置を問い合わせる。
３．出荷管理者に関する情報が、出荷管理者が位置情報を入手することができるようにする決定を行いまた許可を与える目標ウェブ・サービスへ機密保護状態で転送される。出荷管理者に関する転送された情報は、受領会社の識別、出荷会社での出荷管理者の役割、及び品目追跡番号を含むことができる。出荷管理者に関する情報の転送に関しては、ある実施形態の場合には、シボレス（Ｓｈｉｂｂｏｌｅｔｈ）アーキテクチャとして識別されたミドルウェア・ソフトウェア・システム又はモジュールを使用することができる。シボレスアーキテクチャは、アクセス制御を受けるリソースの共有をサポートする周知のアーキテクチャである。
【０１５７】
４．情報が送られる目標ウェブ・サービスは、署名入り又は許可済み承認を生成する。この署名入り承認は、品目を含む車両のセキュリティ制御装置アドレス、ＧＰＳアクセス特権を指定するセキュリティ制御装置１００が信任した１つ又は複数の信任状、及び一意のセッション識別子又は許可を受けていない追加の使用及び／又は他の潜在的誤用を防止するために、出荷管理者を要求にリンクするハンドルを含むことができる。
【０１５８】
５．車両内のセキュリティ制御装置１００のアドレスをベースとして、ＳＳＬセッションが、出荷管理者とセキュリティ制御装置１００との間に直接確立される。
６．信任状が、関連有効チェックを行うセキュリティ制御装置１００へ提示される。
【０１５９】
７．ある変形例の場合には、セキュリティ制御装置１００は、信任状の有効性を確認す
るために配送会社に連絡することができ、車両位置取引に関する追加情報を要求することができる。このような場合、信任状は、認証情報及び許可情報を含んでいる必要はない。何故なら、これら情報は配送会社が供給するからである。
【０１６０】
８．次に、セキュリティ制御装置１００は車両ＧＰＳ座標を要求する。
９．これらの座標は、位置情報を要求した車両内のセキュリティ制御装置１００に返送される。
１０．ＧＰＳ座標は出荷管理者に送られる。
【０１６１】
この例のさらに有意な変形例の場合には、受領会社のサイトは、受領会社とセキュリティ制御装置１００の間のすべての相互関係に対してフロント・エンド・ポータルとしての働きをする。別の方法の場合も、到着推定時間を、車両の実際のＧＰＳ位置の代わりに出荷管理者に送ることができる。
【０１６２】
連合の実施のさらにもう１つの例の場合については、図８を参照しながら、特定のソフトウェア診断ツールを使用している車両の保守について説明する。車両診断ソフトウェア・ツールを実行するために、車両のバスへのセキュア・アクセスが許可される。連合のメンバーとしては、車両ディーラ又は製造業者、及び車両の保守に関連するエンティティ、及びセキュリティ制御装置１００を有する車両自体等がある。ある実施形態の場合には、車両ディーラが、この診断ソフトウェアの使用を許可する信任状を生成する。信任状は、特定の車両及び／又は期間に対する特有なものであってもよい。このアプリケーションに関連するシーケンスは下記のものを含む。
【０１６３】
１．ソフトウェアの使用に関連する信任状及び車両バスへの同時アクセスは、ソフトウェアを動作できるようにするために、車両診断エンティティのラップトップのようなコンピュータにロードされる。
【０１６４】
２．コンピュータ上の診断アプリケーションは、車両のセキュリティ制御装置１００とセキュア・セッションを確立する。
３．診断アプリケーションは、セキュリティ制御装置１００に信任状を提示する。
【０１６５】
４．セキュリティ制御装置１００は、ディーラとのセキュア接続を確立する。
５．セキュリティ制御装置１００は、確認のためにディーラにソフトウェア内に含まれている信任状を提示する。
【０１６６】
６．ディーラは信任状を確認する。
７．セキュリティ制御装置１００は、車両ディーラにより車両バスへのアクセスが許可された場合には、車両の所有者の許可を求めることができる。
【０１６７】
８．車両の所有者は、車両エンジン・バスへのアクセスを許可する。
９．セキュリティ制御装置１００は、車両エンジン・バスにアクセスし、情報を要求する。
１０．セキュリティ制御装置１００は、エンジン・バスから情報を読み出す。
１１．セキュリティ制御装置１００は、次にこの情報をコンピュータに送信する。
【０１６８】
車両エンジン・バスから情報を入手するプロセスは、信任状の確認が行われた後で反復して何度も行うことができる。信任状があれば、エンジン・バスに指定の時間の間及び／又は制限された回数だけアクセスすることができる。好適には、信任状は、個々の各コンピュータ又は他の診断デバイス宛に生成するのが好ましく、診断ソフトウェア自身に宛てて生成してはならない。
【０１６９】
本発明の上記説明は本発明を説明し、記述するためのものである。さらに、上記説明は本発明を本明細書に記載の形に制限するものではない。それ故、関連する技術の技量及び知識の上記開示による変更及び修正は、本発明の範囲に含まれる。上記実施形態は、さらに、本発明の実行の現在周知の最善のモードを説明するためのものであり、当業者がその実施形態又は他の実施形態及びその特定の適用又は用途に必要な種々の修正により本発明を使用することができるようにするためのものである。添付の特許請求の範囲は、従来技術が許す範囲の他の実施形態も含むものと解釈すべきである。
【図面の簡単な説明】
【０１７０】
【図１】セキュリティ制御装置が中央ハブ又はスイッチとして機能する、本発明のシステムのある実施形態のブロック図。
【図２】セキュリティ制御装置がシステムのためにセキュリティ機能を実施するが、中央ハブ又はスイッチではない、システムのもう１つの実施形態のブロック図。
【図３】元のアプリケーションによる目標サービスの使用を許可／認証するためのステップ及び通信を示す図面。
【図４】連合に加入したセキュリティ・フレームワーク内で製品（例えば、食品迅速購入アプリケーション）を機密保護状態で購入するためのステップ及び通信を示す図面。
【図５】連合に加入したセキュリティ・フレームワーク内で料金支払いを機密保護状態で行うためのステップ及び通信を示す図面。
【図６】連合に加入したセキュリティ・フレームワーク内で機密保護状態で輸送料金を支払うためのステップ及び通信を示す図面。
【図７】連合に加入したセキュリティ・フレームワーク内で車両位置アクセス情報を機密保護状態で入手するためのステップ及び通信を示す図面。
【図８】連合に加入したセキュリティ・フレームワーク内で消費者デバイスにより車両バスに機密保護状態でアクセスができるようにするためのステップ及び通信を示す図面。
【特許請求の範囲】
【請求項１】
車両に関連する専用リソースの使用を制御するための方法であって、
第１のバス、第１のインタフェース、第１のディスプレイ、第１の車両デバイス、第１のサブシステム、第１のアプリケーション及び第２のアプリケーションのうち複数のものを備えた、車両に関連する専用リソースを含む、複数のリソースを設けるステップと、
少なくとも３つのエンティティが関与する複数の関係を確立するステップであって、前記少なくとも３つのエンティティのうちの第１及び第２のエンティティが、それぞれ少なくとも第１及び第２の専用リソース内に専用の権利を有し、前記３つのエンティティそれぞれが、前記少なくとも第１の専用リソースの使用に関連する複数の条件を受け入れる、複数の関係を確立するステップと、
少なくとも前記第１及び第２の専用リソースを使用しながら、前記確立の後で少なくとも第１の機能を実行するステップとを備える方法。
【請求項２】
前記第１の車両デバイスは前記第１のバスと通信し、前記第１のアプリケーションは前記第１の車両デバイスに関連して実行され、前記第１のエンティティは前記第１の車両デバイス内には専用の権利を有しているが、前記第１のアプリケーション内には専用の権利を有さず、前記第２のエンティティは、前記第１のアプリケーション内には専用の権利を有しているが、前記第１の車両デバイス内には専用の権利を有していない、請求項１に記載の方法。
【請求項３】
前記第１のアプリケーションは、コマンドによる前記第１の車両デバイスの規制、複数の前記専用リソースのうちの少なくとも１つの使用許可に関連する証明書の変更、セキュリティ制御装置に関連する承認リポジトリへのアクセス、気象条件及び道路状況情報の提供、車両位置の監視、料金及び輸送料の支払い、車両に対するナビゲーション加入の処理、車両診断の実行、及び前記第１のサブシステムの使用に関連する制御の実行のうちの少なくとも１つに関連する請求項１に記載の方法。
【請求項４】
前記第１の車両デバイスは、エンジン・モニタ、油圧センサ、温度センサ及びインフレータ・デバイスのうちの少なくとも１つを含む請求項１に記載の方法。
【請求項５】
前記第１のサブシステムは、本体制御装置、シャーシ制御装置、エンジン制御装置、変速機制御装置、テレマティクス制御装置、全地球測位システム（ＧＰＳ）、車両内に位置する記憶メモリ、携帯情報端末（ＰＤＡ）、ラップトップ・コンピュータ、ＣＤ−ＲＯＭ、車両監視システム（ＶＭＳ）、プリンタ及び事故及び緊急通知アラーム（ＡＥＮＡ）のうちの少なくとも１つを含む請求項１に記載の方法。
【請求項６】
前記複数のリソースを設けるステップは、前記複数のリソースのうちの少なくともいくつかと通信するとともに、車両保証及び品質保証に関連する記憶している情報の監視；優先順位の調停；診断情報及び車両構成情報へのアクセスの許可；認定サービス・プロバイダへの車両情報、運転者情報及び車両制御へのアクセスの許可；前記車両の認定ユーザへの車両情報、運転者情報及び車両制御へのアクセスの許可；車両デバイスの制御を可能にすること又は変更へのアクセスの許可；前記車両内での通信に使用できる場合の、前記第１のサブシステムの１つ又は複数の機能へのアクセスの許可；ユーザに許可されたサービスへのアクセスの許可；承認リポジトリ使用への認定された貸し方及び借り方エンティティへのアクセスの許可；車両の位置データへのアクセスの許可；境界横断及び重量チェックに関連する車両データへのアクセスの許可；スモッグ試験に関連する車両データへのアクセスの許可；及び公共又は民間の輸送料、料金及び駐車料の支払いに関連する承認リポジトリへのアクセスの許可のうちの少なくとも１つを制御する際に使用するセキュリティ制御装置の供給を含む請求項１に記載の方法。
【請求項７】
前記複数の条件のうちの少なくとも１つの条件が、前記３つのエンティティのうちの少なくとも１つに対して異なる請求項１に記載の方法。
【請求項８】
前記確立ステップが、少なくとも前記第１の専用リソース、前記少なくとも第１の専用リソースを使用することができる時間、前記少なくとも第１の専用リソースの識別、前記第１の専用リソースを使用することができる使用、及び前記条件のうちの１つ又は複数が満足しない場合に使用することができる少なくとも１つの救済策のうちの少なくともいくつかを含む前記３つのエンティティが受け入れる前記複数の条件の記述を含む請求項１に記載の方法。
【請求項９】
前記確立ステップが、第１の証明書を使用する前記車両内で使用するための前記第１のアプリケーション及び前記第１のサブシステムのうちの少なくとも１つの証明を含む請求項１に記載の方法。
【請求項１０】
前記証明ステップが、前記３つのエンティティのうちの第３のエンティティによる少なくとも前記第１の専用リソースの使用の許可に関連する複数の鍵の生成を含む請求項９に記載の方法。
【請求項１１】
前記証明ステップが、前記３つのエンティティのうちの第３のエンティティに許可された第１の証明書の一部としての多数の特性の提供を含み、前記特性が、前記第３のエンティティを一意に識別する識別子；優先レベル；前記第１の証明書が有効な地理的エリア；前記第１の証明書の期限切れの日付；前記第１のアプリケーションを使用して、１つ又は複数の通信を行う専用リソース；使用のために入力することができる１つ又は複数のアプリケーション・プログラミング・インタフェース（ＡＰＩ）；及び前記複数のリソースのうちの１つ又は複数を使用を可能にするために必要な１つ又は複数の認証手順のうちの少なくとも１つを含む請求項９に記載の方法。
【請求項１２】
前記証明ステップが、前記３つのエンティティのうちの第３のエンティティによる第１の証明書の要求の生成と、認証局への前記第１の証明書要求の提供を含む請求項９に記載の方法。
【請求項１３】
前記証明ステップが、認証局からの署名鍵と前記第１の証明書との関連づけを含む請求項９に記載の方法。
【請求項１４】
前記証明ステップが、前記第１の証明書の要求者の署名鍵と前記第１のアプリケーションとの関連づけを含む請求項９に記載の方法。
【請求項１５】
前記証明ステップが、少なくとも第１の機関による前記第１のアプリケーションの承認を含む請求項９に記載の方法。
【請求項１６】
前記証明ステップが、認証局による証明書要求の生成を可能にすることを含む請求項９に記載の方法。
【請求項１７】
前記証明ステップが、認証局による前記第１の証明書の発行、及び前記第１の証明書の要求者による前記第１の証明書の精度のチェックを含む請求項９に記載の方法。
【請求項１８】
前記証明ステップが、認証局による証明書要求者への前記第１の証明書に関連する証明書要求の許可を含む請求項９に記載の方法。
【請求項１９】
第１の証明書の要求者が行うべき補償を確認するために、前記第１の証明書に関連する情報の使用をさらに含む請求項９に記載の方法。
【請求項２０】
少なくとも第１の所定の条件に基づく認証局による前記第１の証明書の無効化をさらに含む請求項９に記載の方法。
【請求項２１】
前記車両内のセキュリティ制御装置による前記第１の証明書の認証をさらに含む請求項９に記載の方法。
【請求項２２】
前記確立ステップが、前記エンティティのうちの少なくともいくつかが、前記リソースのうちの少なくとも１つへのアクセス及びその使用を可能にするための所定の信任状を有し、前記リソースが承認リポジトリをさらに含む請求項１に記載の方法。
【請求項２３】
車両内での専用リソースの使用を制御するためのシステムであって、
第１のバス、第１の車両デバイス、第１のサブシステム、第１のディスプレイ、第１のアプリケーション、第２のアプリケーション及び第１のインタフェースのうちの複数を含む前記車両内で使用するための専用リソースを含むリソースと、
前記専用リソースのうちの少なくとも第１のリソースと通信するセキュリティ制御装置とを備え、前記セキュリティ制御装置が、第１の証明書の第１の証明書所有者による前記少なくとも第１の専用リソースの使用の承認に関連する前記セキュリティ制御装置がアクセスすることができる記憶している証明書情報を含む証明書情報を使用する少なくとも前記第１の専用リソースの使用を制御し、前記承認が前記少なくとも第１の専用リソースに関連する専用の権利を有する少なくとも第１のエンティティを含むシステム。
【請求項２４】
前記記憶している証明書情報が、前記第１の証明書所有者の第１の証明書を認証するために使用する認証局の公開鍵を含む請求項２３記載システム。
【請求項２５】
前記セキュリティ制御装置が、前記記憶している証明書情報を使用する前記第１のアプリケーションの認証；記憶している証明書情報を使用する前記第１のアプリケーションに関連するユーザの認証；位置及び時間のうちの少なくとも一方を使用する前記少なくとも第１の専用リソースの使用の確認；前記第１のアプリケーションの実行を許可するかどうかを決定する際の少なくとも第１の鍵への依存；複数の前記専用リソースを同時に使用して実行するために、前記第１のアプリケーション及び前記第２のアプリケーションを含む多数のアプリケーションを使用可能にすること；前記リソースの少なくとも非専用リソースにアクセスすることができるようにすること；前記第１のバスの使用の調停；及び前記第１のバス上の活動の監視のうちの少なくとも１つの実行に関連する請求項２３に記載のシステム。
【請求項２６】
通信に関連する少なくとも前記第１の専用リソースと通信する、前記第１の専用リソースへのアクセスの保護及び調停、及び下記の機能、すなわち少なくとも前記第１の証明書及び少なくとも第１の鍵の管理；前記第１の専用リソースに対する１つ又は複数の使用規則の施行；前記第１の専用リソースに関連する使用の監視及びロギング；故障通知の提供；インターネットを通しての通信を含む前記車両外の通信のサポート；及び前記第１のバス上の通信のサポートのうちの少なくともいくつかの実行の際に使用するための通信サービス・モジュールのうちの少なくとも１つをさらに含む請求項２３に記載のシステム。
【請求項２７】
前記第１のディスプレイへのアクセスを保護、調停し、下記の機能、すなわち（ａ）ハンドル制御装置、ボタン、スイッチのような触覚入力、（ｂ）オーディオ及び音声認識、テキスト音声変換及び／又は音声プロンプト；（ｃ）前記第１のディスプレイを含む複数のディスプレイの管理、応答、処理又はそうでない場合これらとの関連；前記第１のディ
スプレイの使用に関連する前記第１の証明書及び少なくとも第１の鍵の管理；前記第１のディスプレイに関連する１つ又は複数の使用規則の施行；前記第１のディスプレイに関連する使用情報の監視及びロギング；前記第１のディスプレイに関連する故障通知の提供、及び前記第１のバス上の通信のサポートのうちの少なくともいくつかを実行するマン／マシン・インタフェース・サービス・モジュールをさらに含む請求項２３に記載のシステム。
【請求項２８】
車両ゲートウェイ及び車両サービス・モジュールをさらに含み、前記第１のバスが、車両バスと通信する車両デバイスから入手した情報へのアクセスを可能にする前記車両ゲートウェイと通信する第１の車両バスを含む１つ又は複数の車両バスを含み、前記車両サービス・モジュールが、下記の機能、すなわち前記第１の車両バスと通信する前記第１の車両デバイスを含む１つ又は複数の車両デバイスの使用に関連する前記第１の証明書及び少なくとも第１の鍵の管理；前記第１の車両バス及び前記車両デバイスに関連する１つ又は複数の使用規則の施行；前記第１の車両バス及び前記車両デバイスに関連する使用の監視及びロギング；前記第１の車両バス及び前記車両デバイスに関連する故障通知の提供；出力要求に対する第１の車両バス・アクセスの改善；及び前記第１の車両バス上のセキュリティのサポートのうちの少なくとも１つに関連する請求項２３記載システム。
【請求項２９】
前記専用リソースが、下記のもの、すなわち車両デバイス、診断メッセージ及びアラームのセンサ、全地球測位システム（ＧＰＳ）受信機、前記車両内に位置する記憶メモリ、コンパクト・ディスク読出し専用メモリ（ＣＤ−ＲＯＭ）、携帯電話、車両監視システム（ＶＭＳ）、インフレータ・システム、プリンタ、携帯情報端末（ＰＤＡ）、ラップトップ・コンピュータ、及び事故及び緊急通知アラーム（ＡＥＮＡ）のうちの少なくともいくつかを含む請求項２３に記載のシステム。
【請求項３０】
前記第１のアプリケーションが、下記のもの、すなわち車両デバイスへのアクセスの決定及び車両機能の制御；少なくとも１つの所定の機関へ送信されたアラーム通知への貢献；ナビゲーションに対する加入サービス；車両診断の実行；ファームウェアの改善；前記車両に対する構成の改善の実行；承認リポジトリへのアクセス及びその使用；車両、道路状況及び気象条件の提供；及び前記第１の専用リソースが使用できるかどうかの判断のうちの少なくとも１つに関連する請求項２３に記載のシステム。
【請求項３１】
セキュリティ制御装置を有する車両に関連する目標プロバイダに関連するアクセス及び使用を機密保護状態で制御するための方法であって、
車両内にセキュリティ制御装置を含むセキュリティ・システムを提供するステップと、
目標プロバイダを要求するステップと、
要求しているアプリケーションにより、前記目標プロバイダの使用の許可に関連する前記セキュリティ制御装置の使用の第１の情報を入手するステップと、
前記第１の情報に基づいて前記目標プロバイダに関連するユーザを決定するステップとを含む方法。
【請求項３２】
前記要求が、前記要求しているアプリケーションにより実行され、前記決定が前記目標プロバイダにより行われる請求項３１に記載の方法。
【請求項３３】
前記要求が、前記要求しているアプリケーションによりスタートする請求項３１に記載の方法。
【請求項３４】
前記第１の情報が、前記セキュリティ・システムから入力することができる複数の情報と関連し、前記セキュリティ・システムが、前記複数の情報を記憶するためのデータベース及びその間で通信する決定エンジンを含む請求項３１に記載の方法。
【請求項３５】
前記決定エンジンが、前記要求しているアプリケーションに関連する識別、要求中の情報、及び前記目標プロバイダの使用の許可に関連するエンティティからの内容を含む少なくとも１つの要因に基づいて前記第１の情報の提供を決定する請求項３４に記載の方法。
【請求項３６】
前記第１の情報が、前記要求しているアプリケーション、前記セキュリティ制御装置、及びその内容が前記要求しているアプリケーションを実施するために必要なエンティティのうちの少なくとも１つに関連する識別のプライバシーを維持する請求項３１に記載の方法。
【請求項３７】
前記セキュリティ制御装置が、前記車両内に位置する少なくとも第１のリソースに関連する信任状を発行する請求項３１に記載の方法。
【請求項１】
車両に関連する専用リソースの使用を制御するための方法であって、
第１のバス、第１のインタフェース、第１のディスプレイ、第１の車両デバイス、第１のサブシステム、第１のアプリケーション及び第２のアプリケーションのうち複数のものを備えた、車両に関連する専用リソースを含む、複数のリソースを設けるステップと、
少なくとも３つのエンティティが関与する複数の関係を確立するステップであって、前記少なくとも３つのエンティティのうちの第１及び第２のエンティティが、それぞれ少なくとも第１及び第２の専用リソース内に専用の権利を有し、前記３つのエンティティそれぞれが、前記少なくとも第１の専用リソースの使用に関連する複数の条件を受け入れる、複数の関係を確立するステップと、
少なくとも前記第１及び第２の専用リソースを使用しながら、前記確立の後で少なくとも第１の機能を実行するステップとを備える方法。
【請求項２】
前記第１の車両デバイスは前記第１のバスと通信し、前記第１のアプリケーションは前記第１の車両デバイスに関連して実行され、前記第１のエンティティは前記第１の車両デバイス内には専用の権利を有しているが、前記第１のアプリケーション内には専用の権利を有さず、前記第２のエンティティは、前記第１のアプリケーション内には専用の権利を有しているが、前記第１の車両デバイス内には専用の権利を有していない、請求項１に記載の方法。
【請求項３】
前記第１のアプリケーションは、コマンドによる前記第１の車両デバイスの規制、複数の前記専用リソースのうちの少なくとも１つの使用許可に関連する証明書の変更、セキュリティ制御装置に関連する承認リポジトリへのアクセス、気象条件及び道路状況情報の提供、車両位置の監視、料金及び輸送料の支払い、車両に対するナビゲーション加入の処理、車両診断の実行、及び前記第１のサブシステムの使用に関連する制御の実行のうちの少なくとも１つに関連する請求項１に記載の方法。
【請求項４】
前記第１の車両デバイスは、エンジン・モニタ、油圧センサ、温度センサ及びインフレータ・デバイスのうちの少なくとも１つを含む請求項１に記載の方法。
【請求項５】
前記第１のサブシステムは、本体制御装置、シャーシ制御装置、エンジン制御装置、変速機制御装置、テレマティクス制御装置、全地球測位システム（ＧＰＳ）、車両内に位置する記憶メモリ、携帯情報端末（ＰＤＡ）、ラップトップ・コンピュータ、ＣＤ−ＲＯＭ、車両監視システム（ＶＭＳ）、プリンタ及び事故及び緊急通知アラーム（ＡＥＮＡ）のうちの少なくとも１つを含む請求項１に記載の方法。
【請求項６】
前記複数のリソースを設けるステップは、前記複数のリソースのうちの少なくともいくつかと通信するとともに、車両保証及び品質保証に関連する記憶している情報の監視；優先順位の調停；診断情報及び車両構成情報へのアクセスの許可；認定サービス・プロバイダへの車両情報、運転者情報及び車両制御へのアクセスの許可；前記車両の認定ユーザへの車両情報、運転者情報及び車両制御へのアクセスの許可；車両デバイスの制御を可能にすること又は変更へのアクセスの許可；前記車両内での通信に使用できる場合の、前記第１のサブシステムの１つ又は複数の機能へのアクセスの許可；ユーザに許可されたサービスへのアクセスの許可；承認リポジトリ使用への認定された貸し方及び借り方エンティティへのアクセスの許可；車両の位置データへのアクセスの許可；境界横断及び重量チェックに関連する車両データへのアクセスの許可；スモッグ試験に関連する車両データへのアクセスの許可；及び公共又は民間の輸送料、料金及び駐車料の支払いに関連する承認リポジトリへのアクセスの許可のうちの少なくとも１つを制御する際に使用するセキュリティ制御装置の供給を含む請求項１に記載の方法。
【請求項７】
前記複数の条件のうちの少なくとも１つの条件が、前記３つのエンティティのうちの少なくとも１つに対して異なる請求項１に記載の方法。
【請求項８】
前記確立ステップが、少なくとも前記第１の専用リソース、前記少なくとも第１の専用リソースを使用することができる時間、前記少なくとも第１の専用リソースの識別、前記第１の専用リソースを使用することができる使用、及び前記条件のうちの１つ又は複数が満足しない場合に使用することができる少なくとも１つの救済策のうちの少なくともいくつかを含む前記３つのエンティティが受け入れる前記複数の条件の記述を含む請求項１に記載の方法。
【請求項９】
前記確立ステップが、第１の証明書を使用する前記車両内で使用するための前記第１のアプリケーション及び前記第１のサブシステムのうちの少なくとも１つの証明を含む請求項１に記載の方法。
【請求項１０】
前記証明ステップが、前記３つのエンティティのうちの第３のエンティティによる少なくとも前記第１の専用リソースの使用の許可に関連する複数の鍵の生成を含む請求項９に記載の方法。
【請求項１１】
前記証明ステップが、前記３つのエンティティのうちの第３のエンティティに許可された第１の証明書の一部としての多数の特性の提供を含み、前記特性が、前記第３のエンティティを一意に識別する識別子；優先レベル；前記第１の証明書が有効な地理的エリア；前記第１の証明書の期限切れの日付；前記第１のアプリケーションを使用して、１つ又は複数の通信を行う専用リソース；使用のために入力することができる１つ又は複数のアプリケーション・プログラミング・インタフェース（ＡＰＩ）；及び前記複数のリソースのうちの１つ又は複数を使用を可能にするために必要な１つ又は複数の認証手順のうちの少なくとも１つを含む請求項９に記載の方法。
【請求項１２】
前記証明ステップが、前記３つのエンティティのうちの第３のエンティティによる第１の証明書の要求の生成と、認証局への前記第１の証明書要求の提供を含む請求項９に記載の方法。
【請求項１３】
前記証明ステップが、認証局からの署名鍵と前記第１の証明書との関連づけを含む請求項９に記載の方法。
【請求項１４】
前記証明ステップが、前記第１の証明書の要求者の署名鍵と前記第１のアプリケーションとの関連づけを含む請求項９に記載の方法。
【請求項１５】
前記証明ステップが、少なくとも第１の機関による前記第１のアプリケーションの承認を含む請求項９に記載の方法。
【請求項１６】
前記証明ステップが、認証局による証明書要求の生成を可能にすることを含む請求項９に記載の方法。
【請求項１７】
前記証明ステップが、認証局による前記第１の証明書の発行、及び前記第１の証明書の要求者による前記第１の証明書の精度のチェックを含む請求項９に記載の方法。
【請求項１８】
前記証明ステップが、認証局による証明書要求者への前記第１の証明書に関連する証明書要求の許可を含む請求項９に記載の方法。
【請求項１９】
第１の証明書の要求者が行うべき補償を確認するために、前記第１の証明書に関連する情報の使用をさらに含む請求項９に記載の方法。
【請求項２０】
少なくとも第１の所定の条件に基づく認証局による前記第１の証明書の無効化をさらに含む請求項９に記載の方法。
【請求項２１】
前記車両内のセキュリティ制御装置による前記第１の証明書の認証をさらに含む請求項９に記載の方法。
【請求項２２】
前記確立ステップが、前記エンティティのうちの少なくともいくつかが、前記リソースのうちの少なくとも１つへのアクセス及びその使用を可能にするための所定の信任状を有し、前記リソースが承認リポジトリをさらに含む請求項１に記載の方法。
【請求項２３】
車両内での専用リソースの使用を制御するためのシステムであって、
第１のバス、第１の車両デバイス、第１のサブシステム、第１のディスプレイ、第１のアプリケーション、第２のアプリケーション及び第１のインタフェースのうちの複数を含む前記車両内で使用するための専用リソースを含むリソースと、
前記専用リソースのうちの少なくとも第１のリソースと通信するセキュリティ制御装置とを備え、前記セキュリティ制御装置が、第１の証明書の第１の証明書所有者による前記少なくとも第１の専用リソースの使用の承認に関連する前記セキュリティ制御装置がアクセスすることができる記憶している証明書情報を含む証明書情報を使用する少なくとも前記第１の専用リソースの使用を制御し、前記承認が前記少なくとも第１の専用リソースに関連する専用の権利を有する少なくとも第１のエンティティを含むシステム。
【請求項２４】
前記記憶している証明書情報が、前記第１の証明書所有者の第１の証明書を認証するために使用する認証局の公開鍵を含む請求項２３記載システム。
【請求項２５】
前記セキュリティ制御装置が、前記記憶している証明書情報を使用する前記第１のアプリケーションの認証；記憶している証明書情報を使用する前記第１のアプリケーションに関連するユーザの認証；位置及び時間のうちの少なくとも一方を使用する前記少なくとも第１の専用リソースの使用の確認；前記第１のアプリケーションの実行を許可するかどうかを決定する際の少なくとも第１の鍵への依存；複数の前記専用リソースを同時に使用して実行するために、前記第１のアプリケーション及び前記第２のアプリケーションを含む多数のアプリケーションを使用可能にすること；前記リソースの少なくとも非専用リソースにアクセスすることができるようにすること；前記第１のバスの使用の調停；及び前記第１のバス上の活動の監視のうちの少なくとも１つの実行に関連する請求項２３に記載のシステム。
【請求項２６】
通信に関連する少なくとも前記第１の専用リソースと通信する、前記第１の専用リソースへのアクセスの保護及び調停、及び下記の機能、すなわち少なくとも前記第１の証明書及び少なくとも第１の鍵の管理；前記第１の専用リソースに対する１つ又は複数の使用規則の施行；前記第１の専用リソースに関連する使用の監視及びロギング；故障通知の提供；インターネットを通しての通信を含む前記車両外の通信のサポート；及び前記第１のバス上の通信のサポートのうちの少なくともいくつかの実行の際に使用するための通信サービス・モジュールのうちの少なくとも１つをさらに含む請求項２３に記載のシステム。
【請求項２７】
前記第１のディスプレイへのアクセスを保護、調停し、下記の機能、すなわち（ａ）ハンドル制御装置、ボタン、スイッチのような触覚入力、（ｂ）オーディオ及び音声認識、テキスト音声変換及び／又は音声プロンプト；（ｃ）前記第１のディスプレイを含む複数のディスプレイの管理、応答、処理又はそうでない場合これらとの関連；前記第１のディ
スプレイの使用に関連する前記第１の証明書及び少なくとも第１の鍵の管理；前記第１のディスプレイに関連する１つ又は複数の使用規則の施行；前記第１のディスプレイに関連する使用情報の監視及びロギング；前記第１のディスプレイに関連する故障通知の提供、及び前記第１のバス上の通信のサポートのうちの少なくともいくつかを実行するマン／マシン・インタフェース・サービス・モジュールをさらに含む請求項２３に記載のシステム。
【請求項２８】
車両ゲートウェイ及び車両サービス・モジュールをさらに含み、前記第１のバスが、車両バスと通信する車両デバイスから入手した情報へのアクセスを可能にする前記車両ゲートウェイと通信する第１の車両バスを含む１つ又は複数の車両バスを含み、前記車両サービス・モジュールが、下記の機能、すなわち前記第１の車両バスと通信する前記第１の車両デバイスを含む１つ又は複数の車両デバイスの使用に関連する前記第１の証明書及び少なくとも第１の鍵の管理；前記第１の車両バス及び前記車両デバイスに関連する１つ又は複数の使用規則の施行；前記第１の車両バス及び前記車両デバイスに関連する使用の監視及びロギング；前記第１の車両バス及び前記車両デバイスに関連する故障通知の提供；出力要求に対する第１の車両バス・アクセスの改善；及び前記第１の車両バス上のセキュリティのサポートのうちの少なくとも１つに関連する請求項２３記載システム。
【請求項２９】
前記専用リソースが、下記のもの、すなわち車両デバイス、診断メッセージ及びアラームのセンサ、全地球測位システム（ＧＰＳ）受信機、前記車両内に位置する記憶メモリ、コンパクト・ディスク読出し専用メモリ（ＣＤ−ＲＯＭ）、携帯電話、車両監視システム（ＶＭＳ）、インフレータ・システム、プリンタ、携帯情報端末（ＰＤＡ）、ラップトップ・コンピュータ、及び事故及び緊急通知アラーム（ＡＥＮＡ）のうちの少なくともいくつかを含む請求項２３に記載のシステム。
【請求項３０】
前記第１のアプリケーションが、下記のもの、すなわち車両デバイスへのアクセスの決定及び車両機能の制御；少なくとも１つの所定の機関へ送信されたアラーム通知への貢献；ナビゲーションに対する加入サービス；車両診断の実行；ファームウェアの改善；前記車両に対する構成の改善の実行；承認リポジトリへのアクセス及びその使用；車両、道路状況及び気象条件の提供；及び前記第１の専用リソースが使用できるかどうかの判断のうちの少なくとも１つに関連する請求項２３に記載のシステム。
【請求項３１】
セキュリティ制御装置を有する車両に関連する目標プロバイダに関連するアクセス及び使用を機密保護状態で制御するための方法であって、
車両内にセキュリティ制御装置を含むセキュリティ・システムを提供するステップと、
目標プロバイダを要求するステップと、
要求しているアプリケーションにより、前記目標プロバイダの使用の許可に関連する前記セキュリティ制御装置の使用の第１の情報を入手するステップと、
前記第１の情報に基づいて前記目標プロバイダに関連するユーザを決定するステップとを含む方法。
【請求項３２】
前記要求が、前記要求しているアプリケーションにより実行され、前記決定が前記目標プロバイダにより行われる請求項３１に記載の方法。
【請求項３３】
前記要求が、前記要求しているアプリケーションによりスタートする請求項３１に記載の方法。
【請求項３４】
前記第１の情報が、前記セキュリティ・システムから入力することができる複数の情報と関連し、前記セキュリティ・システムが、前記複数の情報を記憶するためのデータベース及びその間で通信する決定エンジンを含む請求項３１に記載の方法。
【請求項３５】
前記決定エンジンが、前記要求しているアプリケーションに関連する識別、要求中の情報、及び前記目標プロバイダの使用の許可に関連するエンティティからの内容を含む少なくとも１つの要因に基づいて前記第１の情報の提供を決定する請求項３４に記載の方法。
【請求項３６】
前記第１の情報が、前記要求しているアプリケーション、前記セキュリティ制御装置、及びその内容が前記要求しているアプリケーションを実施するために必要なエンティティのうちの少なくとも１つに関連する識別のプライバシーを維持する請求項３１に記載の方法。
【請求項３７】
前記セキュリティ制御装置が、前記車両内に位置する少なくとも第１のリソースに関連する信任状を発行する請求項３１に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公表番号】特表２００６−５２１７２４（Ｐ２００６−５２１７２４Ａ）
【公表日】平成１８年９月２１日（２００６．９．２１）
【国際特許分類】
【出願番号】特願２００６−５０３１２２（Ｐ２００６−５０３１２２）
【出願日】平成１６年１月２８日（２００４．１．２８）
【国際出願番号】ＰＣＴ／ＵＳ２００４／００２４４１
【国際公開番号】ＷＯ２００４／０６８４２４
【国際公開日】平成１６年８月１２日（２００４．８．１２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
Ｂｌｕｅｔｏｏｔｈ
【出願人】（５０３２１６９７１）セルポート システムズ インコーポレイテッド (3)
【Ｆターム（参考）】
【公表日】平成１８年９月２１日（２００６．９．２１）
【国際特許分類】
【出願日】平成１６年１月２８日（２００４．１．２８）
【国際出願番号】ＰＣＴ／ＵＳ２００４／００２４４１
【国際公開番号】ＷＯ２００４／０６８４２４
【国際公開日】平成１６年８月１２日（２００４．８．１２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
Ｂｌｕｅｔｏｏｔｈ
【出願人】（５０３２１６９７１）セルポート システムズ インコーポレイテッド (3)
【Ｆターム（参考）】
[ Back to top ]