JP2020080153A - 証明書管理システムのサービス品質の提供 - Google Patents

Abstract

【課題】セキュリティ認証情報およびデジタル証明書などのデジタル資産を、安全に生成および提供するためのシステム、機器、および方法を提供する。【解決手段】クライアント２０２が証明書管理サービス２８０と対話する動作環境２００において、クライアント２０２は、ネットワーク２３５を介して証明書管理サービス２８０に対して証明書のリクエストを送信する。証明書管理サービス２８０は、登録局２２０、登録認証局２３０、偽名認証局２４０、連携局１ ２５０および連携局２ ２６０を含む。【選択図】図２

Description

本発明は、セキュリティ認証情報およびデジタル証明書などの特定のタイプのデジタル資産を安全に生成および提供するためのシステム、機器、および方法に関する。より詳細には、本発明は、コンピュータ化された機器におけるデジタル資産のプロビジョニングの遅延を低減または排除するために、コンピュータ化された機器におけるデジタル資産を安全にプロビジョニングしながらサービス品質（ＱｏＳ）レベルを提供するための改善されたシステム、方法、および技術に関する。

コンピュータがますます小型化および商品化されるにつれて、製造業者は、１つ以上の組み込み型コンピュータまたはプロセッサを含む、ますます多様な機器を製造している。コンピュータ化された機器内のコンピュータは、とりわけ、機器の動作を制御し、データを収集、保存、共有し、他のコンピュータや他のコンピュータ化された機器と通信し、それ自身のソフトウェアを更新することができる。

モノのインターネット（ＩｏＴ）は、プロセッサ、電子機器、ソフトウェア、データ、センサ、アクチュエータ、および／またはネットワーク接続を内蔵したコンピュータ化された物理機器のネットワークであり、インターネット、携帯電話ネットワーク、および他のワイヤレスネットワークを含むデジタルネットワークを介してこれらの機器にデータを接続および交換可能にする。通常、それぞれの「モノ」は、その組み込みコンピューティングシステムを通じて一意に識別可能であり、既存のインターネットインフラストラクチャ内で相互運用することができる。

ＩｏＴの意味での「モノ」とは、とりわけ、家電製品、ビジネスや企業の環境で使用される企業向け機器、製造機械、農業用機器、家庭や建物内のエネルギー消費型機器（スイッチ、コンセント、アプライアンス、照明システム、電球、テレビ、ガレージドアオープナー、スプリンクラーシステム、セキュリティシステムなど）、医療およびヘルスケア機器、インフラストラクチャ管理機器、ロボット、ドローン、および輸送機器および車両などの多様なコンピュータ化された機器を指すことができる。

例えば、全部ではないにしても大部分の現代の乗り物および輸送機械（例えば、自動車、トラック、航空機、列車、船舶、バイク、スクーターなど）は、それらのサブシステム内にいくつかの組み込みプロセッサまたは組み込みコンピュータを含み、少なくともいくつかの態様でコンピュータ制御される。同様に、ますます多くの現代の交通インフラ機器（例えば、信号機、交通カメラ、交通センサ、ブリッジモニタ、ブリッジ制御システムなど）は、少なくとも１つ、そしてしばしば多くの、組み込みプロセッサまたは組み込みコンピュータシステムを含み、少なくともいくつかの態様でコンピュータ制御される。交通ネットワークのこれらのコンピュータ制御要素は、通常、相互に通信して様々な種類の情報をやり取りし、安全で、正しく、効率的で、信頼できる動作のために、それらは車両間（Ｖ２Ｖ、車間（Ｃ２Ｃ）とも呼ばれる）通信における他の車両との間でおよび／または車両とインフラストラクチャ間（Ｖ２Ｉ、車インフラストラクチャ間（Ｃ２Ｉ）とも呼ばれる）通信におけるインフラストラクチャ要素との間で受信／送信される情報に反応し、応答し、動作を変更し、あるいは依存することができる。

コンピュータ化された機器内のコンピュータは、それらのソフトウェアおよび／またはファームウェアおよびデータに従って動作する。安全で適切な動作を確実にするために、コンピュータ化された機器は、製造業者によって意図されたように、適切なソフトウェア、ファームウェア、実行可能命令、デジタル証明書（例えば、公開鍵証明書）、および暗号鍵など（以下において、集合的に「デジタル資産」または「ソフトウェア」と呼ぶものとする）で適切に初期化および更新されなければならないので、ＩｏＴは、認可された、動作確認済みのソフトウェアおよびデータを実行している機器のみからなる。しかしながら、認可されていない人または組織（例えば、ハッカー）がコンピュータ化された機器内のソフトウェアを交換または変更するときに問題が生じる。また、古いソフトウェア、テストされていないソフトウェア、認可されていないソフトウェア、および／または既知のバグを有するソフトウェアがコンピュータ化された機器内に設置されている場合にも問題が生じる。

コンピュータネットワーキング、パケット交換ネットワーク、および電気通信の分野では、サービス品質（ＱｏＳ）は、選択したユーザ、顧客、クライアント機器、またはネットワークトラフィックに改善されたサービスを提供するように設計された一連のテクノロジーおよび技術を指す。ＱｏＳの目標は、サービスまたはネットワークのパフォーマンスを保証することである。ＱｏＳメトリックには、遅延、可用性、待機時間、帯域幅、アップロードデータ転送速度、ダウンロードデータ転送速度、セッションごとのアップロード／ダウンロード制限（つまり、ネットワークセッション中にアップロードまたはダウンロードできるメガバイトまたはギガバイトの合計量）が含まれ得る。サービスまたはネットワークは、異なるユーザおよびクライアント機器に異なるＱｏＳレベルを割り当てることができる。ＱｏＳはまた、アプリケーションプログラムからのリクエストに従って、ユーザまたはクライアント機器に一定レベルのパフォーマンスを保証することもできる。ＱｏＳの保証は、コンピューティング能力またはネットワーク能力が制限されている場合、または実行されるリクエストが遅延に敏感な場合に重要である。

したがって、コンピュータ化された機器内でデジタル資産のプロビジョニングの遅延を削減または排除するために、ＩｏＴ機器、車両、および輸送インフラストラクチャ機器などのコンピュータ化された機器内のデジタル資産を安全にプロビジョニングしながら、ＱｏＳレベルを提供するための改善されたシステム、方法、および技術を提供することが望ましい。

本明細書では、セキュリティ認証情報およびデジタル証明書などの特定のタイプのデジタル資産を生成するリクエストを実行しながら、ＱｏＳレベルを提供するためのシステム、方法、および機器が開示される。様々な実施形態では、システム、方法、および機器は、ＱｏＳマネージャを使用して、証明書管理システム（ＣＭＳ）から、証明書をリクエストするクライアントにＱｏＳレベルを提供する。一部の実施形態では、ＣＭＳは、セキュリティ認証情報や公開鍵証明書などの特定の種類のデジタル資産を作成および提供するために、ＱｏＳマネージャからのリクエストを受け入れる証明書管理サービスをホストする。ＱｏＳマネージャは、ＱｏＳアービターを使用してＱｏＳキューを作成および管理し、ＣＭＳが特定のＱｏＳレベルに基づいて個別の異なるリクエストを適切に管理できるようにする。様々な実施形態では、証明書管理サービスは、車両から車両（Ｖｅｈｉｃｌｅ−ｔｏ−Ｖｅｈｉｃｌｅ）および車両からインフラストラクチャ（Ｖ２Ｘ：Ｖｅｈｉｃｌｅ−ｔｏ−Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）機器、ならびに車から車（Ｃａｒ−ｔｏ−Ｃａｒ）および車からインフラストラクチャ（Ｃ２Ｘ：Ｃａｒ−ｔｏ−Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）機器のための証明書を作成できる。様々な実施形態では、システムには、証明書リクエストを送信するクライアントにＱｏＳレベルを提供するＱｏＳマネージャが含まれる。ＱｏＳマネージャは、ＱｏＳマネージャからの証明書のリクエストの受信に応答して、登録証明書や偽名（ｐｓｅｕｄｏｎｙｍ）証明書などの証明書を生成する証明書管理サービスに通信可能に接続される。

本明細書でさらに説明するように、ＱｏＳマネージャは、テナントに対応する仲介クライアントキューを管理し、ＱｏＳアービターを使用してＱｏＳキューに配置されるクライアントキューからのエントリの順序を選択することにより、ＱｏＳレベルを提供することにより、証明書管理サービスがマルチテナント（例えば、マルチクライアント）動作を提供できるようにする。例えば、カスタマイズされたワークフローを作成することができ、カスタマイズされた構成をエンティティ管理システムを介してエンドエンティティで管理できる。

様々な実施形態において、システムは、証明書管理サービスから証明書をリクエストする複数のクライアント（例えば、テナントまたは顧客）にサービス品質（ＱｏＳ）レベルを提供する。システムには、複数のクライアントから証明書リクエストを受信するように動作可能なパブリックアプリケーションプログラミングインターフェイス（ＡＰＩ）が含まれ、各々の証明書リクエストは、証明書を必要とするコンピュータ化された機器の数、証明書リクエストがいつ送信されたかを示すタイムスタンプ、および証明書をリクエストする特定のクライアントを示す。システムはまた、複数のクライアントからの証明書リクエストを複数の仲介クライアントキューに分配するように動作可能なＱｏＳマネージャを含む。複数のクライアントキューの各々は、証明書をリクエストする特定のクライアントに対応する。ＱｏＳマネージャはまた、クライアントキュー内のクライアントからの証明書リクエストを１つ以上のエントリのサブグループ（すなわち、より小さいグループ）に分割するように動作可能であり、１つ以上のエントリの各々は、証明書を必要とするコンピュータ化された機器の数のサブセットに対応するグループサイズを有する。システムは、ＱｏＳキューに配置される複数のクライアントキューからのエントリの順序を選択するように動作可能なＱｏＳアービターをさらに含む。ＱｏＳアービターは、ＱｏＳキュー内のエントリの数、証明書管理サービスの待機時間レベル、および証明書リクエストがいつ送信されたかを示すそれぞれのタイムスタンプに少なくとも部分的に基づいて、クライアントキューからエントリの順序を選択する。ＱｏＳマネージャはさらに、ＱｏＳアービターによって選択された順序でＱｏＳキューからエントリを取得し、次に、証明書管理サービスの内部登録局ＡＰＩを介して、取得されたエントリを証明書管理サービスに送信するように動作可能である。

一部の実施形態では、証明書を必要とするコンピュータ化された機器の数のサブセットに対応するグループサイズは、デフォルト値が１の調整可能な数値である。

特定の実施形態では、コンピュータ化された機器は、１つ以上のオンボードユニット（ＯＢＵ）、電子制御ユニット（ＥＣＵ）、およびロードサイドユニット（ＲＳＵ）に対応し、ＯＢＵは、車両、船舶（例えば、ボート）、航空機、宇宙船、医療機器、ロボット、ドローン、無線または有線の通信モジュール、およびＩｏＴ機器のうちの１つ以上に設置されるように構成され、ＥＣＵは、車両、船舶、航空機、宇宙船、医療機器、ロボット、ドローン、無線通信モジュール、有線通信モジュール、およびＩｏＴ機器のうちの１つ以上に設置されるように構成され、ＲＳＵは、交通制御機器、無線通信モジュール、デジタル広告板、および電子看板のうちの１つ以上に設置されるように構成される。

特定の実施形態では、複数のクライアントは、証明書管理サービスと証明書を必要とする少なくとも１つのコンピュータ化された機器との間のプロキシとして機能する少なくとも１つの配信機器を含む。配信機器は、例えば工場などの製造業者のサイトに配置できる。そのような実施形態によれば、少なくとも１つのコンピュータ化された機器は、配信機器が証明書管理サービスから証明書を受け取った後、配信機器から証明書を取得することができる。追加の実施形態では、複数のクライアントは、証明書管理サービスと証明書を必要とする少なくとも１つのコンピュータ化された機器との間のプロキシとして機能する少なくとも１つのサーバを含む。そのような実施形態によれば、少なくとも１つのコンピュータ化された機器は、サーバが証明書管理サービスから証明書を受け取った後、サーバから証明書を取得できる。

いくつかの実施形態によれば、各々の証明書リクエストは、リクエストを送信するクライアントのクライアント優先度レベルをさらに示し、ＱｏＳアービターはさらに、証明書リクエストで示されたそれぞれのクライアント優先度レベルに少なくとも部分的に基づいて、ＱｏＳキューに配置される複数のクライアントキューからのエントリの順序を選択するようにさらに動作可能である。いくつかのそのような実施形態によれば、ＱｏＳアービターは、追加のクライアントから受信した追加の証明書リクエストに示されるそれぞれのクライアント優先度レベルに少なくとも部分的に基づいて、ＱｏＳキューに配置されるエントリの順序を動的に並べ替えるようにさらに動作可能である。いくつかのそのような実施形態では、クライアントに対するクライアント優先度レベルは、クライアントに関連付けられたサービス層に基づく。いくつかのそのような実施形態によれば、サービス層は、最低のサービスレベルから最高のサービスレベルまでの範囲の複数の層のうちの１つに対応する。いくつかのそのような実施形態では、サービス層は、複数の層の１つに対応する英数字の文字列または数値である。

他の実施形態では、各証明書リクエストは、リクエストに関連付けられたリクエスト緊急度レベルをさらに示し、ＱｏＳアービターは、証明書リクエストに示されるそれぞれのリクエストの緊急度に少なくとも部分的に基づいてＱｏＳキューに配置される複数のクライアントキューからのエントリの順序を選択するように動作可能である。いくつかのそのような実施形態によれば、証明書リクエストのリクエスト緊急度レベルは、証明書リクエストを送信するクライアントによって指定される。特定のそのような実施形態によれば、リクエスト緊急度レベルは、最低緊急度オプションから最高緊急度オプションまでの範囲の複数のレベルのうちの１つに対応する。いくつかのそのような実施形態では、リクエストの緊急度レベルは、複数のレベルのうちの１つに対応する英数字の文字列または数値である。

さらに他の実施形態では、ＱｏＳアービターは、ラウンドロビン技術を使用して、ＱｏＳキューに配置される複数のクライアントキューからのエントリの順序を選択するように動作可能である。

さらに他の実施形態では、ＱｏＳアービターは、クライアントキューの各々に割り当てられた動的優先度に基づいて、ＱｏＳキューに配置される複数のクライアントキューからのエントリの順序を選択するように動作可能であり、クライアントキューの各々へ割り当てられるそれぞれの動的優先度は、クライアントキューの各々のエントリ数に少なくとも部分的に基づいてＱｏＳアービターによって割り当てられる。

追加の実施形態では、パブリックＡＰＩは、通信ネットワークを介して複数のクライアントから証明書リクエストを受信するように動作可能なＲｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）ＡＰＩであり、証明書リクエストは、登録証明書のリクエストを含み、証明書管理サービスに代わって、通信ネットワークを介して、複数のクライアントに、証明書管理サービスの登録認証局によって生成された登録証明書を送信する。いくつかのそのような実施形態によれば、証明書リクエストは偽名証明書のリクエストをさらに含み、パブリックＲＥＳＴ ＡＰＩは、証明書管理サービスに代わって、通信ネットワークを介して複数のクライアントに、証明書管理サービスの偽名認証局によって生成される偽名証明書を送信するようにさらに動作可能である。いくつかのそのような実施形態によれば、登録証明書は、複数のコンピュータ化された機器を含むエコシステムの認可された参加者として公開鍵証明書の所有者を識別する公開鍵証明書であり、エコシステムの各々の認可された参加者は、複数のコンピュータ化された機器との通信を可能にする１つ以上の偽名証明書を受け取ることができる。

他の実施形態では、ＱｏＳアービターはさらに、追加のクライアントから受信した追加の証明書リクエストに少なくとも部分的に基づいて、ＱｏＳキューに配置されるエントリの順序を動的に並べ替えるように動作可能である。

特定の実施形態では、コンピュータ実装方法は、証明書管理サービスから証明書をリクエストするクライアントにサービス品質（ＱｏＳ）レベルを提供する。コンピュータ実装方法は、パブリックアプリケーションプログラミングインターフェイス（ＡＰＩ）を介して、複数のクライアントから証明書リクエストを受信することを含む。各々の証明書リクエストは、証明書を必要とするコンピュータ化された機器の数、証明書リクエストがいつ送信されたかを示すタイムスタンプ、および証明書をリクエストするクライアントのクライアント識別子を示す。一部の実施形態では、クライアント識別子は、一意の英数字文字列、認証トークン、およびクライアント認証情報（例えば、Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＴＬＳ）証明書または他のタイプのデジタル証明書など）を１つ以上含むことができる。本方法は、ＱｏＳマネージャによって、複数のクライアントからの証明書リクエストを複数の仲介クライアントキューに分配することをさらに含み、複数のクライアントキューの各々は、証明書をリクエストする特定のクライアントに対応する。本方法はまた、ＱｏＳマネージャによって、クライアントのリクエストを１つ以上のエントリのサブグループ（つまり、より小さいグループ）に分割することを含み、１つ以上のエントリの各々は、証明書を必要とするコンピュータ化された機器の数のサブセットに対応する。本方法は、ＱｏＳキュー内のエントリの数、証明書管理サービスの待機時間レベル、および証明書リクエストがいつ送信されたかを示すそれぞれのタイムスタンプの少なくとも一部に基づいて、ＱｏＳアービターにより、ＱｏＳキューに配置される複数のクライアントキューからのエントリの順序を選択することをさらに含む。本方法はまた、ＱｏＳアービターによって選択された順序でＱｏＳキューからエントリをＱｏＳマネージャによって取得することを含む。本方法は、証明書管理サービスの内部登録局ＡＰＩを介して、取得したエントリを証明書管理サービスに送信することをさらに含む。

一部の実施形態では、ＱｏＳマネージャは、証明書管理サービスをホストするＣＭＳと通信可能に接続される。一部の実施形態では、ＣＭＳは、証明書管理サービスの内部アプリケーションプログラミングインターフェイス（ＡＰＩ）への呼び出しを介してＱｏＳマネージャと通信する。ＣＭＳは、複数のクライアントからのリクエストに応答して、ＱｏＳマネージャを介して証明書を安全に提供するように構成される。追加または代替の実施形態では、ＱｏＳマネージャをＣＭＳでホストされ得る。

ＱｏＳマネージャが複数のクライアントに代わって登録証明書のリクエストをＣＭＳの登録局に送信するように動作可能な特定の実施形態では、ＱｏＳマネージャは、登録局に送信される前にクライアントキューまたはＱｏＳキューの優先度を再設定するようにさらに動作可能とすることができる。例えば、ＱｏＳマネージャは、クライアントの登録証明書のリクエストを登録局に送信する前に、証明書をリクエストしているクライアントに優先度を付けることができる。

他の実施形態では、登録証明書は、複数のコンピュータ化された機器を含むエコシステムの認可された参加者として公開鍵証明書の所有者を識別する公開鍵証明書であることができ、エコシステムへの認可された各々の参加者は、複数のコンピュータ化された機器との通信を可能にする１つ以上の偽名証明書を受け取ることができる場合がある。

本明細書に組み込まれてその一部を構成する添付の図面は、本発明の実施形態を例示し、その説明と共に、本発明の原理を説明するのに役立つ。

本発明の実施形態に整合する、証明書などの認証情報を安全に提供するためのプロセスの一例を示すスイムレーン図の第１の部分である。

本発明の実施形態に整合する、証明書などの認証情報を安全に提供するためのプロセスの一例を示すスイムレーン図の第２の部分である。

本発明の実施形態に整合する、証明書管理サービスおよび単一のクライアントのための例示的な動作環境のブロック図である。

本発明の実施形態に整合する、単一のクライアントとＣＭＳとの間の例示的なデータフローを示すデータフロー図である。

本発明の実施形態に整合する、２つのクライアント環境で動作する例示的な証明書管理サービスのブロック図である。

本発明の実施形態に整合する、２つのクライアントとＣＭＳとの間の例示的なデータフローを示すデータフロー図である。

本発明の実施形態に整合する、マルチクライアント環境で動作する例示的な証明書管理サービスのブロック図である。

本発明の実施形態に整合する、複数のクライアントとＣＭＳとの間の例示的なデータフローを示すデータフロー図である。

本発明の実施形態に整合する、ＱｏＳレベルを複数のクライアントに提供するためにＱｏＳマネージャを使用する例示的な証明書管理サービスのブロック図である。

本発明の実施形態に整合する、ＱｏＳマネージャを実装するためのシステムの一例のブロック図である。

本発明の実施形態に整合する、複数のクライアントとＱｏＳマネージャを使用する証明書管理システムとの間の例示的なデータフローを示すデータフロー図である。

本発明の実施形態に整合するシステムおよび方法をホスティングするために使用することができるコンピューティングシステムの一例のブロック図である。

ここで、本発明の様々な実施形態について詳細に言及するが、それらの例は添付の図面に示されている。都合のよい場合にはいつでも、同じまたは同様の部分を指すために、図面全体を通して同じ符号を使用する。

現場での安全で適切な動作を保証するために、組み込み機器（例えば、車両に使用される電子制御ユニット（ＥＣＵ））は、セキュリティ資産などのデジタル資産をプロビジョニングすることによって製造中に適切に初期化される必要がある。デジタル資産には、様々なデジタル証明書、暗号化キー、一意の識別子、およびソフトウェアを含めることができる。ほとんどの場合、これらのデジタル資産を生成するＣＭＳまたは証明書管理サービスと製造工場は、地理的に異なる場所にあり、これらの場所は、従来、安全でないインターネット通信を介して相互接続されている。したがって、デジタル資産が悪意のある者によってまたは偶然にアクセスまたは変更されることがないように、これらのデジタル資産の起点から機器へのエンドツーエンドの安全なチャネルを作成することが望ましい。通常、異なる製造工場とテナント（例えば、顧客とクライアント）には、異なる数のデジタル資産（例えば、デジタル証明書のサイズの異なるバンドル）が必要である。したがって、大規模なリクエストに関連する計算能力のボトルネックまたは通信帯域幅の制限によるこれらのデジタル資産の提供の遅延を最小限に抑えることも望ましい。

従来の証明書管理システム（ＣＭＳ）および証明書管理サービスには、先着順で証明書を発行するという欠点がある。これにより、大規模なリクエストが顧客によってなされて受信されると、大規模なリクエストの後に証明書管理システムまたはサービスに到来するリクエストは、大規模なリクエストが完了するのを待たなければならないという技術的な問題が発生する。大規模な証明書リクエストが実行されるのを待つことに関連する遅延またはボトルネックを最小限に抑えるための従来の技術には、各顧客に対して専用の機器を備えた独立した証明書管理サービスを有することが含まれる。この従来のアプローチの問題は、専用の機器を割り当てることは高価で非効率的であり、所与の顧客専用の機器はアイドル状態で、別の顧客専用の機器は最大能力になるというマルチカスタマーソリューションの提供とは対照的である。本開示に整合するシステム、方法、および機器は、従来の証明書管理システムおよびサービスのこれらおよび他の問題に対処する。例示的な解決策は、複数の顧客（例えば、クライアント）がどのクライアントも欠乏させることなく重複するまたは同時の証明書リクエストを送信できるようにする公平性の方法を採用することにより、これらの問題に対処する。

プロビジョニングとは一般的に、適切なデータとソフトウェアを使ってコンピュータ化された機器を準備するためにとられる一連のアクションを指す。それはまた、機器をその運用環境に適切に設置して運用準備を整えるためにとられる一連のアクションも含むことができる。アクションは、適切なデジタル資産（例えば、オペレーティングシステム、機器ドライバ、ミドルウェア、アプリケーション、デジタル証明書など）を機器のデジタルストレージ（例えば、メモリ）にロードすること、および（必要な場合）各々の特定の機器に固有であり得る特定のデジタル資産を機器上で適切にカスタマイズし構成することを含む。アクションはまた、コンピュータ化された機器が正当な機器製造業者によって作成された正当な機器であり、コピーまたは偽造の機器ではないことを検証することを含むことができる。

アクションはまた、機器をその動作環境に正しく設置すること、および機器が正しく動作していることを検証するためにそれをテストすることを含むことができる。機器が１つの製造業者によって構築され、後で別の業者によってより大規模なシステムまたは機器に設置される可能性がある（例えば、部品メーカーにより作られたオンボードユニット（ＯＢＵ）が、自動車メーカーによって作られた自動車に取り付けられる可能性がある）という事実によって、安全性が確認されている機器のみを安全にプロビジョニングする機能は複雑である。不適切に設置された機器は、正しく機能しない可能性がある。

本発明と一致した様々な実施形態は、ＩｏＴ機器を含むコンピュータ化された機器の安全なプロビジョニングのワークフローの一部として証明書リクエストを実行するためのＱｏＳレベルを提供する。このような実施形態は、一部のクライアントからの大規模な証明書リクエストが他のクライアントからの小規模なリクエストを犠牲にしてボトルネックまたは過度の遅延を作成するのを防ぐのに役立つ。

本発明に整合する様々な実施形態は、安全なプロビジョニングおよび管理プラットフォームの一部として証明書リクエストを効率的に実行するために、ＱｏＳアービターを備えたＱｏＳマネージャを使用して、大規模な証明書リクエストをＱｏＳキューに配置されるより小さく管理しやすい部分に分割することもでき、これは機器およびシステムメーカーにサービスとして提供することができる。

図１Ａおよび図１Ｂはともに、本発明の実施形態に整合する、証明書などの認証情報を安全に提供するための例示的なプロセス１００を示すスイムレーン図である。特に、図１Ａおよび図１Ｂに示される例示的なプロセス１００は、Ｖ２Ｘ機器に証明書を提供するために、ＣＭＳコンポーネント間のリクエストおよび応答の交換を含む。しかしながら、本明細書で説明される実施形態は、Ｖ２Ｘ機器に限定されず、開示される原理は、Ｃ２Ｘ機器などの他のタイプのコンピュータ化された機器およびコンピュータ制御機器に適用され得る。つまり、ＣＭＳは、Ｖ２ＸまたはＣ２Ｘ証明書管理サービスとして機能する証明書管理サービスをホストできる。図１Ａおよび図１Ｂに示される例示的なプロセス１００は、証明書をＶ２Ｘ機器に提供する。図１Ａおよび図１Ｂは、リクエストと応答のＶ２Ｘフローの文脈でのＣＭＳの一例のコンポーネントを示している。

様々な実施形態において、プロセス１００または示される動作の一部またはすべては、（１つ以上のプロセッサまたは１つ以上のコンピューティングサブシステムを含み得る）コンピューティングシステム上で実行されるコードによって、ハードウェアのみのシステムによって、または２つのハイブリッドであるシステムによって実行され得る。図１Ａおよび図１Ｂの上部に示されるように、プロセス１００に関与するエンティティは、製造業者（図示せず）、ＣＭＳホスト（例えば、証明書管理サービスをホストするＣＭＳ）の登録局１２０、連携局１５０、１６０、偽名認証局１４０、および登録認証局１３０に配置された配信機器１０８を含む。様々な実施形態では、これらのエンティティは、図１Ａおよび１Ｂに関して以下および本開示全体で説明するように、証明書を提供するプロセス１００の一部としてタスクを実行するために互いに通信し得る。

特定の実施形態では、ＣＭＳホストは証明書管理サービスをホストするシステムであり得る。ＣＭＳはＱｏＳマネージャと通信する。一部の実施形態では、そのような通信は、証明書管理サービスの内部アプリケーションプログラミングインターフェイス（ＡＰＩ）への呼び出しを介して行われる。

ＣＭＳには、登録局１２０、１つ以上の連携局１５０、１６０、偽名認証局１４０、および登録認証局１３０が含まれる。例示的なＣＭＳは、登録局１２０のためのアプリケーションを実行する１つ以上のアプリケーションプラットフォームを含み得る。これらのアプリケーションプラットフォームは、登録局１２０が必要とする暗号計算を実行する１つ以上の計算エンジンに通信可能に接続されている。１つ以上のアプリケーションプラットフォームは、１つ以上の仮想マシン（ＶＭ）または１つ以上のハードウェアプラットフォーム（例えば、サーバ、コンピュータ、またはソフトウェアアプリケーションをホストおよび実行できるその他のコンピュータハードウェア）を含み得る。ＣＭＳはまた、登録認証局１３０を実行し、登録認証局１３０が必要とする暗号計算を実行する１つ以上の計算エンジンに通信可能に接続された１つ以上のＶＭを含み得る。登録認証局１３０は、登録証明書を生成し、条件付きで登録局１２０に送信するように動作可能である。図１Ａおよび図１Ｂの登録局１２０をホストする例示的なＣＭＳホストは、偽名認証局１４０のためのアプリケーションを実行し、偽名認証局１４０が必要とする暗号計算を実行する１つ以上の計算エンジンに通信可能に接続される１つ以上のＶＭをさらに含み得る。偽名認証局１４０は、偽名証明書を生成し、条件付きで登録局１２０に送信するように動作可能である。ＣＭＳホストはまた、第１および第２の連携局１５０、１６０を実行し、第１および第２の連携局１５０、１６０が必要とする暗号計算を実行する１つ以上の計算エンジンに通信可能に接続される１つ以上のＶＭを含み得る。第１の連携局１５０および第２の連携局１６０のそれぞれのアプリケーションは、連携値を生成し、条件付きで登録局１２０に送信するように動作可能であり得る。

図１Ａおよび図１Ｂに示される登録局１２０をホストするＣＭＳホストはまた、登録局１２０のためのアプリケーションを実行し、かつ登録局１２０が必要とする暗号計算を実行する１つ以上の計算エンジンに通信可能に接続される１つ以上のアプリケーションプラットフォームを含み得る。ＣＭＳホストは、登録認証局１３０のためのアプリケーションを実行し、かつ登録認証局１３０が必要とする暗号計算を実行する１つ以上の計算エンジンに通信可能に接続される１つ以上のアプリケーションプラットフォームをさらに含み得、登録認証局１３０は、登録証明書を生成し、条件付きで登録局１２０に送信するように動作可能であり得る。ＣＭＳホストはさらに、偽名認証局１４０のためのアプリケーションを実行し、かつ偽名認証局１４０が必要とする暗号計算を実行する１つ以上の計算エンジンに通信可能に接続される１つ以上のアプリケーションプラットフォームを含むことができ、偽名認証局１４０は、偽名証明書を生成し、条件付きで登録局１２０に送信するように動作可能であり得る。さらに、ＣＭＳホストは、第１の連携局１５０のためのアプリケーションを実行し、かつ第１の連携局１５０が必要とする暗号計算を実行する１つ以上の計算エンジンに通信可能に接続される１つ以上のアプリケーションプラットフォームを含み得る。最後に、ＣＭＳホストは、第２の連携局１６０のためのアプリケーションを実行し、かつ第２の連携局１６０が必要とする暗号計算を実行する１つ以上の計算エンジンに通信可能に接続される１つ以上のアプリケーションプラットフォームも含み得る。連携局１５０、１６０は、連携値を生成し、条件付きで登録局１２０に送信するように動作可能とすることができる。

さらに他の実施形態では、登録認証局１３０は、登録局１２０からの登録証明書のリクエストの受信に応答して登録証明書を生成するように動作可能とすることができ、偽名認証局１４０は、登録局１２０からの偽名証明書のリクエストの受信に応答して偽名証明書を生成するように動作可能とすることができ、第１の連携局１５０および第２の連携局１６０は、登録局１２０からの連携値のリクエストの受信に応答して連携値を生成するように動作可能とすることができる。代替または追加の実施形態では、登録認証局１３０は、コンピュータ化された機器から直接リクエストを受信することに応答して登録証明書を生成するように動作可能とすることができる。すなわち、登録証明書を取得する方法は複数あり、図１Ａおよび図１Ｂに示される例示的なプロセス１００は、単なる１つの例示的な方法である。

図１Ａの例に示されるように、プロセス１００は、登録関連の動作１０５〜１３５で開始する。登録認証局１３０の主な役割は、登録局１２０からのリクエストを実行して、登録証明書を、例えば、配信機器１０８などのエンドユーザ機器に発行することである。図１Ａに示される例示的な登録関連動作１０５〜１３５を参照して以下で説明するように、登録認証局１３０は、リクエストされた登録証明書を配信機器１０８に発行するために登録局１２０と直接対話することができる。追加または代替の実施形態では、登録認証局１３０は、証明書管理サービスをホストするＣＭＳと登録証明書を必要とするコンピュータ化された機器との間でプロキシとして機能するように動作可能な配信機器１０８と、登録証明書を必要とするコンピュータ化された機器と、登録証明書をリクエストするクライアントのためのプロキシとして機能するサーバと直接通信できる。例えば、登録認証局１３０は、製造業者のサイト（例えば、製造業者の工場）にある配信機器１０８と直接通信することができる。

１０５では、製造業者の配信機器１０８は、登録局１２０から登録証明書をリクエストし、登録証明書はコンピュータ化された機器にプロビジョニングされ（例えば、それによって使用され）、リクエストは登録証明書の宛先であるコンピュータ化された機器を識別し得る。リクエストは、例えば、新しいコンピュータ化された機器（例えば、新しい製品）に対する登録証明書をリクエストしている製造業者の配信機器１０８であってもよい。登録証明書は、エコシステムであって、すべての参加者が有効な登録証明書を共有しなければならず、認可された参加者はまた、エコシステム内での機器の通信と動作を可能にする（例えば、ＵＳＤＯＴのＶ２Ｘエコシステムの例では、車両とロードサイドインフラストラクチャとの間の通信と動作を可能にする）偽名証明書も受け取ることができるエコシステム（例えば、米国運輸省（ＵＳＤＯＴ）Ｖ２Ｘエコシステムなど）の認可された参加者としてその所有者を識別する公開鍵証明書である。

１１０では、登録証明書のリクエストは登録局１２０で受信され、次いで登録局１２０から登録認証局１３０に送信される。様々な実施形態において、この動作は、登録局１２０が、未承認の機器のリスト（例えば、ブラックリスト）を使用して登録証明書の宛先である機器（例えば、コンピュータ化された機器）の失効ステータスをチェックする署名検証を含むリクエストを解読および検証することと、リクエスタ（例えば、配信機器１０８）が登録局１２０からの登録証明書をリクエストできるかどうかを判断することとを伴い得る。例えば、動作１１０は、製造業者からのユーザが認可されたユーザ（例えば、スタッフの一部）であるかどうかを判定することを含み得る。いくつかの実施形態では、登録局１２０は、登録証明書を受信するためのコンピュータ化された機器（例えば、製品）が使用のために承認されているかどうかを１１０で判定することもできる。場合によっては、この判定を行うために、承認済み機器のリスト（ホワイトリストなど）が規制当局によって提供され、プロビジョニングコントローラによって使用され得る。登録証明書のリクエストが確認された後、リクエストは登録局１２０から登録認証局１３０に送信される。このリクエストは、登録局１２０によって作成される登録証明書生成リクエストとして送信できる。

１１５では、登録証明書のリクエストは、登録認証局１３０で受信される。リクエストの受信に応答して、１２０では、登録認証局１３０は、リクエストされた登録証明書を生成し、生成された登録証明書を登録局１２０に送り返す。１２５では、登録局１２０で登録証明書が受信され、１３０では、登録局１２０は、登録証明書を配信機器１０８に送信する。１３５では、配信機器１０８は登録証明書を受け取る。この時点で、配信機器１０８は、機器が登録証明書を使用できるように登録証明書を機器にプロビジョニングすることができ、登録関連の動作が完了する。

動作１４０〜１９９は、偽名証明書のプロビジョニングに関連している。いくつかの実施形態では、偽名証明書をリクエスト、生成、およびプロビジョニングするための動作１４０〜１９９は、ＱｏＳマネージャ（図１Ａおよび図１Ｂには図示されないが、図８および図９のＱｏＳマネージャ８０１および９０１を参照）を使用して、偽名証明書をリクエストする複数のクライアントにＱｏＳレベルを提供することを含む。１４０では、配信機器１０８は、登録局１２０からの偽名証明書をリクエストする。偽名証明書は、コンピュータ化された機器にプロビジョニング（例えば、それによって使用）され、リクエストは、偽名証明書の宛先であるコンピュータ化された機器を識別することができる。リクエストは、例えば、以前に登録証明書を受け取ったコンピュータ化された機器（例えば、登録されたコンピュータ化された機器）の偽名証明書をリクエストしている製造業者の配信機器１０８であり得る。偽名証明書のリクエストには、一定量（例えば、１週間相当、１か月相当、または１年相当）の公開鍵証明書に対するクライアントリクエストが含まれ得る。

１４５では、偽名証明書のリクエストが登録局１２０で受信され、登録局１２０は次に偽名証明書のプロビジョニングを開始する。

動作１５２〜１７０では、連携局１５０、１６０は、連携値のリクエストを実行するために登録局１２０と直接対話する。１５０では、登録局１２０は、連携値の第１の組（ＬＡ１）のリクエストを連携局１ １５０に送信する。

１５５では、連携値の第１の組のリクエストの受信に応答して、連携局１ １５０は、連携値の第１の組を生成および／または登録局１２０に送信する。すなわち、連携局１ １５０は、以前に生成された連携値の第１の組（すなわち、事前生成された連携値）を送信することができるか、または値が事前に生成されない場合は、連携局１ １５０は、連携値の第１の組を生成し、その後、送信することができる。１５７では、連携値の第１の組が登録局１２０で受信される。１６０では、登録局１２０は、連携値の第２の組（ＬＡ２）のリクエストを連携局２ １６０に送信する。

次に、図１Ｂに示すように、１６５では、連携値の第２の組のリクエストの受信に応答して、連携局２ １６０は、連携値の第２の組を生成および／または登録局１２０に送信する。様々な実施形態において、連携局２ １６０は、事前に生成された連携値の第２の組を送信することができるか、または代替的に、連携局２ １６０は、連携値の第２の組を生成および送信することができる。１７０では、連携値の第２の組が登録局１２０で受信される。

特定の実施形態では、図１Ａおよび図１Ｂに示す連携局１５０、１６０は、証明書リクエスタの識別子（つまり、証明書リクエスタの機器の一意の識別子）を失効の目的で発行された偽名証明書にリンクできる。すなわち、連携局１ １５０および連携局２ １６０は、プロセス１００の一部として、偽名認証局１４０によって発行された偽名証明書に、証明書リクエスタの機器の一意の識別子として第１および第２の組の連携値をそれぞれ提供する。連携局１ １５０および連携局２ １６０は、動作１５２および１６２で登録局１２０から送信された連携値のリクエストを受信し、動作１５５および１６５で登録局１２０にリクエストされた連携値を提供する。

引き続き図１Ｂを参照すると、１７５では、登録局１２０は、偽名証明書に対するリクエストを偽名認証局１４０に送信する。このリクエストは、登録局１２０によって作成される偽名証明書生成リクエストのバッチとして送信され得る。

１８０では、偽名証明書のリクエストは、偽名認証局１４０で受信される。リクエストの受信に応答して、１８５では、偽名認証局１４０は、リクエストされた偽名証明書を生成し、生成された偽名証明書を登録局１２０に送り返す。１９０では、偽名証明書が登録局１２０で受信される。

１９５では、配信機器１０８は、複数のリクエストを登録局１２０に送信して、リクエストされた偽名証明書の準備ができている（すなわち、生成されて利用可能）かどうかを問い合わせることができる。特定の実施形態では、動作１９５の問い合わせは、動作１４２で偽名証明書のリクエストが送信された後であればいつでも送信することができる。例えば、動作１４２で偽名証明書のリクエストを登録局１２０に送信した後、配信機器１０８は、登録局１２０に問い合わせを定期的に送信して、リクエストされた偽名証明書が読み取られたかどうかを判定する。この例では、動作１９５の問い合わせの１つ以上を、動作１４５〜１９０と並行して（すなわち、偽名証明書が生成されている間に）送信することができる。

１９８では、偽名証明書の準備が整うと、登録局１２０は、配信機器１０８に偽名証明書を送信する。１９９では、配信機器１０８は、偽名証明書を受信する。この時点で、配信機器１０８は、機器が偽名証明書を使用できるように機器に偽名証明書をプロビジョニングすることができ、偽名証明書をプロビジョニングするための動作が完了する。

追加または代替の実施形態では、上記のプロセス１００と同様のプロセスを使用して、例えばＣ２Ｘ機器などの他のコンピュータ化された機器に証明書を提供することができる。例えば、図１Ａおよび図１Ｂに示すコンポーネントと同様のコンポーネントを備えたＣＭＳは、１つ以上のオンボードユニット（ＯＢＵ）、電子制御ユニット（ＥＣＵ）、またはロードサイドユニット（ＲＳＵ）に証明書を提供できる。このようなＯＢＵおよびＥＣＵは、車両、船舶（例えば、ボート）、航空機（例えば、飛行機およびドローン）、宇宙船、医療機器、ロボット、無線または有線の通信モジュール、およびＩｏＴ機器にインストールされるように構成され得る。同様に、ＲＳＵは、交通制御機器（例えば、交通信号）、電子看板機器、およびデジタル表示機器（例えば、電子広告板）に設置され得る。

図２〜図９に関して本明細書で説明するＱｏＳマネージャ、ＱｏＳアービター、およびＱｏＳキューを使用して、Ｖ２ＸコンテキストならびにＣ２Ｘコンテキストで証明書をリクエストするクライアントにＱｏＳレベルを提供できることを理解すべきである。

図２は、単一のクライアント２０２が証明書管理サービス２８０と対話する例示的な動作環境２００を示している。いくつかの実施形態では、証明書管理サービス２８０は、Ｖ２Ｘ証明書管理サービスであり得る。追加または代替の実施形態では、証明書管理サービス２８０は、Ｃ２Ｘ証明書管理サービスであり得る。図示されるように、クライアント２０２は、ネットワーク２３５を介して１つ以上のコンピュータ化された機器に対して証明書のリクエストを送信することができる。図２の例では、ネットワーク２３５はインターネットである。特定の実施形態では、コンピュータ化された機器は、車両、船舶（例えば、ボート）、航空機、宇宙船、医療機器、ロボット、ドローン、無線または有線通信モジュール、およびＩｏＴ機器のうちの１つ以上に対応する。例えば、コンピュータ化された機器は、車両、船舶、航空機、宇宙船、ロボット、ドローン、医療機器、またはＩｏＴ機器のＯＢＵまたはＥＣＵに対応できる。また、例えば、コンピュータ化された機器は、交通制御機器（例えば、信号機、交通信号灯、または電子交通標識）、デジタル広告板、または電子看板のＲＳＵに対応することができる。

動作環境２００では、証明書のリクエストは、証明書管理サービス２８０のクライアントの表示状態転送（ＲＥＳＴ：ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ ｓｔａｔｅ ｔｒａｎｓｆｅｒ）ＡＰＩ２０５により受信される。図２に示すように、クライアントのＲＥＳＴ ＡＰＩ ２０５はパブリックＡＰＩとすることができ、証明書管理サービス２８０は、Ｖ２ＸまたはＣ２Ｘ証明書管理サービスとすることができる。証明書管理サービス２８０は、証明書のリクエストを受け入れ、タイムフレーム内でタスクを完了し、その後、ネットワーク２３５を介して結果（例えば、生成された証明書）をクライアント２０２に返す。いくつかの実施形態では、タイムフレームは、証明書管理サービス２８０の処理能力に応じて、数分、数時間、または数日であり得る。

証明書管理サービス２８０は、リクエストされた証明書を生成するためのコンポーネントを含む。図２の例では、これらのコンポーネントには、登録局２２０、登録認証局２３０、偽名認証局２４０、連携局１ ２５０、および連携局２ ２６０が含まれる。

追加または代替の実施形態では、証明書管理サービス２８０のコンポーネントは、証明書管理サービス２８０がＶ２ＸまたはＣ２Ｘ証明書管理サービスとして構成されているかどうかに応じて異なり得る。例えば、証明書管理サービス２８０がＣ２Ｘ証明書管理サービスとして機能する場合、証明書管理サービス２８０は、登録認証局２３０の役割と同様の役割を果たすように構成された長期認証局（ＬＴＣＡ：Ｌｏｎｇ Ｔｅｒｍ Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）を含むことができる。同様に、証明書管理サービス２８０がＣ２Ｘ証明書管理サービスとして具現化される場合、証明書管理サービス２８０は、偽名認証局２４０の役割と同様の役割を果たす認可機関（ＡＡ：Ａｕｔｈｏｒｉｚａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ）を含み得る。証明書管理サービス２８０のコンポーネントについては、以下の段落で説明する。

一例では、証明書管理サービス２８０は、ＣＭＳとして具現化することができる。証明書管理サービス２８０の様々な実施形態は、非常に大量の機器トランザクションおよび証明書生成処理のために使用され得る。様々な実施形態において、証明書管理サービス２８０は、複数のサーバ、複数のハードウェアセキュリティモジュール（ＨＳＭ）、複数の計算またはコンピューティングエンジン、および複数のアプリケーションプラットフォームを使用して実装され得る。例示的な一実施形態では、アプリケーションプラットフォームはそれぞれ、登録局２２０、登録認証局２３０、偽名認証局２４０、および連携局２５０および２６０をホストするための１つ以上の仮想マシン（ＶＭ）を含むことができる。追加または代替の実施形態では、アプリケーションプラットフォームはそれぞれ、例えば、アプリケーションサーバ、コンピュータ、またはソフトウェアアプリケーションをホストおよび実行できる他のコンピュータハードウェアなど、１つ以上のハードウェアプラットフォームを含むことができる。図２の例では、登録認証局２３０のアプリケーションプラットフォームは、登録認証局１３０のアプリケーションを実行する１つ以上のＶＭとすることができ、偽名認証局２４０のアプリケーションプラットフォームは、偽名認証局２４０のアプリケーションをホストして実行するように動作可能な１つ以上のＶＭとすることができる。同様に、連携局１ ２５０のアプリケーションプラットフォームは、連携局１のアプリケーションをホストおよび実行するように構成された１つ以上のＶＭとすることができ、連携局２ ２６０のアプリケーションプラットフォームは、連携局２のアプリケーションをホストおよび実行するように動作可能な１つ以上のＶＭとすることができる。証明書管理サービス２８０の非限定的な例は、プライベートデータセンター、例えばアマゾンのアマゾンウェブサービス（ＡＷＳ）などのクラウドデータセンター、またはプライベートデータセンターとクラウドデータセンターのハイブリッドで実装することができる。

いくつかの実施形態では、証明書管理サービス２８０は、例えば、図１Ａおよび１Ｂに関して説明したように機能し得る製造業者の配信機器１０８によって使用される、例えば、登録証明書および偽名証明書などのセキュリティ証明書を提供することができる。特定の実施形態では、証明書管理サービス２８０は、図１Ａおよび１Ｂに示される配信機器１０８に証明書を提供するために、デジタル資産管理システム（ＤＡＭＳ）と対話することができる。

図２に示すように、証明書管理サービス２８０のアーキテクチャは、登録局２２０、登録認証局２３０、偽名認証局２４０、連携局１ ２５０、および連携局２ ２６０を含む。これらのコンポーネントの各々は、タスクを実行するために、それぞれ専用の計算エンジン（図示せず）を利用できる。例えば、登録局２２０は登録局計算エンジンを利用でき、登録認証局２３０は登録認証局計算エンジンを利用でき、偽名認証局２４０は偽名認証局計算エンジンを利用でき、連携局１ ２５０は連携局１計算エンジンを利用でき、連携局２ ２６０は、連携局２計算エンジンを利用できる。これらの各コンポーネントの機能については、以下の段落で説明する。

証明書管理サービス２８０のアーキテクチャは、非セキュリティ関連のアプリケーションをセキュリティ機能から有利に分離する。図２の例に示すように、登録局２２０、登録認証局２３０、偽名認証局２４０、および連携局２５０、２６０は、独自の専用計算エンジンで実行される独自のＶＭ上のアプリケーションとして実装され、独自の専用計算エンジンのすべては、非セキュリティ関連のアプリケーションおよび機能から分離される。これにより、ＨＳＭのパフォーマンスが遅い、クラウドサービスプロバイダーがＨＳＭを提供できない、またはＨＳＭの適切な管理が不確実である従来のシステムに対する技術的およびセキュリティ上の利点と改善の両方が提供される。証明書管理サービス２８０では、ＨＳＭを必要とするすべての暗号動作が計算エンジン（例えば、１つ以上の計算エンジン）で実行される。

図２に示すように、重要なセキュリティ機能を互いに分離し、別々の計算エンジンに分離することにより、計算集中型の暗号およびセキュリティ機能（例えば、楕円曲線バタフライ展開計算または楕円曲線デジタル署名）は、例えば、登録局２２０、登録認証局２３０、偽名認証局２４０、および連携局２５０、２６０によって実行されるとき、既存の登録局システムよりも大幅に高速に実行される。この設計は、図８〜図１０を参照して以下で説明するサービス品質（ＱｏＳ：Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）マネージャと連携して、「ボトルネック」アプリケーションを必要に応じて個別にスケーリングできるようにすることで、マルチクライアント環境でのトランザクション処理の大幅な改善を可能にする。したがって、本開示に整合する実施形態は、既存の登録局システムに関連するボトルネックを減らすために、特定の技術的に有利なシステムアーキテクチャを提供する。例えば、登録局２２０で実行される登録局アプリケーションを拡張する必要がある場合、追加のＶＭを追加できるが、登録局の計算エンジンの安全な計算機能を変更することは必要とされ得ない。あるいはまた、セキュリティ計算がパフォーマンスを制限している場合は、追加の安全な登録局の計算エンジンを追加できる。この同じ多次元スケーリングは、証明書管理サービス２８０の他のコンポーネントにも当てはまる。これらの機能により、既存のセキュリティ認証情報管理システム（ＳＣＭＳ：Ｓｅｃｕｒｉｔｙ Ｃｒｅｄｅｎｔｉａｌ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍｓ）よりも大幅にパフォーマンスおよびスケーラビリティが向上する。

いくつかの実施形態では、登録局２２０、登録認証局２３０、偽名認証局２４０、および連携局２５０、２６０のそれぞれのアプリケーションプラットフォームは、それぞれの入力メッセージキューの組を介して計算エンジンに通信可能に接続され、これにより証明書管理サービス２８０のこれらのコンポーネントのすべては、互いに独立してスケーリングできる。

上述し、図２の非限定的な例に示すように、登録局２２０、認証局２３０、２４０、および連携局２５０、２６０の各々は、それら自身の仮想マシン（ＶＭ）上のアプリケーションとして実装され得る。追加または代替の実施形態では、登録局２２０、認証局２３０、２４０、および連携局２５０、２６０の１つ以上は、ハードウェアプラットフォーム（例えば、サーバまたは計算エンジン）上で実行することができる。アプリケーションプラットフォーム（例えば、ＶＭまたはハードウェアプラットフォーム）上で実行されるこれらのアプリケーションの各々の役割および機能については、以下の段落で説明する。

様々な実施形態において、登録局２２０は、デジタル証明書または他のタイプのデジタルセキュリティ資産に対するユーザリクエストを検証し、認証局（例えば、登録認証局２３０および偽名認証局２４０）がデジタル証明書を発行可能にするプロビジョニングネットワーク内の局とすることができる。様々な実施形態において、登録局２２０は、公開鍵インフラストラクチャ（ＰＫＩ）システム内で知られている登録局と同様であり得る。様々な実施形態において、クライアントのＲＥＳＴ ＡＰＩ ２０５は、証明書リクエストを登録局２２０に渡すことができ、これは、ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ ｓｔａｔｅ ｔｒａｎｓｆｅｒ（ＲＥＳＴ）ウェブサービスとして実装することができる。様々な実施形態では、登録局２２０の複数のインスタンスが同時に実行される場合がある。これは、図２に示される証明書管理サービス２８０の他のコンポーネントについても同様に表される。証明書管理サービス２８０の登録局機能は、その機能がＲＥＳＴウェブサービスとして実装された登録局２２０の複数のインスタンスによって実行できるという点で非集中型である。登録局２２０の主な役割は、署名偽名認証局２４０がどの証明書が特定のコンピュータ化された機器に最終的に到達するのかを知ることを防ぎながら、リクエストをプロビジョニングする証明書を許可および実行することである。登録局２２０は、証明書管理サービス２８０内でそれらの役割を果たすために、メッセージキューを介して偽名認証局２４０、連携局２５０、２６０と直接対話する。

特定の実施形態では、登録局２２０（および図２の他のコンポーネント）をデータベースに接続することができる。証明書管理サービス２８０は、データの保存および取得のために、データストアまたはデータベースのコレクションを利用してもよい。例えば、使用されるデータベースは、必要に応じてデータ分離を可能にする１つ以上のテーブルを各々が有する１つ以上のデータベース論理ユニットまたは物理ユニットからなることができる。本明細書で使用されるとき、「データベース」という用語は、１つ以上のデータベースまたはデータストアを指す。特定の実施形態では、複数のデータベースの使用により、登録局２２０と図２の他のコンポーネントとの間のデータ分離が可能になり得る。例えば、このような複数のデータベースの使用により、登録局２２０、認証局２３０、２４０、および連携局２５０、２６０間のデータ分離が可能になる。

好ましい実施形態では、証明書管理サービス２８０によって使用されるデータベースは、１つ以上の高速アクセス、低待機時間データベースのコレクションである。一部の実施形態では、データベースは、ＮｏＳＱＬデータベースまたはデータベースサービス（例えば、Ａｍａｚｏｎ Ｗｅｂサービスによって提供されるＤｙｎａｍｏＤＢデータサービス）とすることができる。様々な実施形態では、データベースに保存されるデータはアプリケーションに依存するが、過去に発行された証明書、様々な連携局の値、証明書が発行された機器のデータ、オペレーターのアクションなどを含み得る。なお、データは、暗号化されていない、暗号化された、またはそれらの組み合わせのいずれかで保存され得る。

様々な実施形態では、証明書管理サービス２８０は、登録局２２０によって生成されたデジタル証明書が異なるセグメント、例えば登録デジタル証明書と偽名デジタル証明書とに分割されるため、登録認証局２３０と偽名認証局２４０とを含む。

登録認証局２３０は、同時に実行する登録認証局２３０の複数のインスタンスが存在する可能性があるため、証明書管理サービス２８０の非中央コンポーネントである。例えば、いくつかの実施形態では、登録認証局２３０の複数のインスタンスが同時に実行している場合がある。登録認証局２３０は、登録局２２０から登録証明書のリクエストを受け取ることができる。登録認証局２３０の主な役割は、登録局２２０からのリクエストを実行して、例えば図１Ａおよび図１Ｂに示される配信機器１０８などのエンドユーザ機器に登録証明書を発行することである。図１Ａを参照して上述したように、登録認証局１３０は、ＣＭＳ内でその役割を果たすために登録局１２０と直接対話する。

偽名認証局２４０は、同時に実行している偽名認証局２４０の複数のインスタンスが存在する可能性があるという点で、ＣＭＳの非中央コンポーネントである。偽名認証局２４０については、様々な実施形態において、同時に並行して実行している偽名認証局２４０の複数のインスタンスがあり得る。偽名認証局２４０は、登録局２２０から偽名証明書のリクエストを受け取ることができる。偽名認証局２４０の主な役割は、登録局２２０からのリクエストを実行して、例えば図１Ａおよび図１Ｂに示される配信機器１０８などのエンドユーザ機器に偽名証明書を発行することである。特定の実施形態では、偽名認証局２４０は、Ｖ２Ｖ機能のための短期偽名証明書のリクエストを実行する。図５Ｂを参照して以下に説明するように、偽名認証局２４０は、ＣＭＳ内でその機能を果たすために登録局２２０と直接対話する。

様々な実施形態において、図２に示される連携局２５０、２６０は、証明書リクエスタの識別子（すなわち、証明書リクエスタの機器の一意の識別子）を、失効目的のために発行された偽名証明書にリンクする。すなわち、連携局１ ２５０および連携局２ ２６０は、それぞれの連携値を、証明書リクエスタの機器の一意の識別子として、発行された偽名証明書に提供する。連携局１ ２５０および連携局２ ２６０は、登録局２２０から連携値のリクエストを受信し、次いで、リクエストされた連携値を登録局２２０に提供することができる。連携局２５０、２６０は、連携値のリクエストを実行するために登録局２２０と直接対話する。

様々な実施形態において、計算エンジンはＨＳＭを含み、ＨＳＭによりこれらのコンポーネントは、ハッカーから過度に脅かされることなく安全な計算を実行できる。いくつかの実施形態では、組み込みＨＳＭを必要とせずに安全な計算を実行するように計算エンジンを設計することができ、このような実施形態では、ＨＳＭを具現化する。

様々な実施形態では、ＣＭＳでは異なるＨＳＭバージョンが使用できる。例えば、ＨＳＭには、１つ以上の計算エンジン内にプラグインカードとしてインストールされた組み込みＨＳＭが含まれ得る。そのような例示的な実施形態では、組み込みＨＳＭは、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）ＨＳＭまたはＰＣＩ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）ＨＳＭとして１つ以上の計算エンジンにインストールされてもよい。また、例えば、証明書管理サービス２８０のＨＳＭは、自身のエンクロージャ内の計算エンジンとは別の外部、ネットワーク取付けまたはネットワーク接続ＨＳＭを含むことができる。

当業者であれば、図２に示すコンポーネントおよび実施形態の詳細は、説明を簡潔かつ明確にするために提示された例であることを理解するであろう。この例は限定を意図するものではなく、多くの変形が可能であるので、本発明の原理から逸脱することなく他のコンポーネント、プロセス、実施形態の詳細、および変形形態を使用することができる。

図３は、本発明の実施形態に整合する、単一のクライアント３０２とＣＭＳ３８０との間の例示的なデータフローを示すデータフロー図である。図３の例では、ＣＭＳ３８０は、Ｖ２ＸまたはＣ２Ｘ ＣＭＳとして具現化され得る。いくつかの実施形態によれば、ＣＭＳ３８０は、図２を参照して上述した証明書管理サービス２８０などの証明書管理サービスをホストすることができる。

図３に示すように、クライアント３０２は、１つ以上のコンピュータ化された機器のための証明書のリクエスト３１０を送信する。一部の実施形態では、コンピュータ化された機器は、車両に搭載されるように構成されたＥＣＵまたはＯＢＵであり得る。追加または代替の実施形態では、コンピュータ化された機器は、交通制御機器（例えば、交通信号灯、電子交通標識など）、デジタル看板、およびその他のロードサイド電子標識に設置されるように構成されたＲＳＵであり得る。特定の実施形態では、各証明書リクエスト３１０は、証明書を必要とするコンピュータ化された機器の数、証明書リクエスト３１０がいつ送信されたかを示すタイムスタンプ、および証明書をリクエストするクライアント（例えば、図３の例におけるクライアント３０２の識別子）を示す。特定の実施形態では、クライアントの識別子（つまり、クライアント識別子）は、一意の英数字文字列、認証トークン、および例えばＴＬＳ証明書などのクライアント認証情報、または他の種類のデジタル証明書のうちの１つ以上を含み得るか、またはそれらであり得る。

ＣＭＳ３８０は、リクエスト３１０を受け入れ、計算時間３１５内にリクエストされた証明書バンドルを生成することによりリクエストされたタスクを完了する。証明書バンドルは、計算時間３１５内にＣＭＳ３８０によって作成され、計算時間３１５はタイムフレーム（例えば、分、時間、または日の数）である。計算時間３１５は、ＣＭＳ３８０の作業負荷、（リクエスト３１０に示されるように）証明書を必要とするコンピュータ化された機器の数、およびＣＭＳ３８０の待機時間レベルなどの様々な要因に応じて異なり得る。証明書バンドルを生成した後（つまり、計算時間３１５が経過した後）、ＣＭＳ３８０はクライアント３０２に返送される応答３２５として結果を戻す。

図４は、例示的な動作環境４００のブロック図である。特に、図４は、本発明の実施形態に整合する、２つのクライアント環境で動作する証明書管理サービス４８０を示している。簡潔にするために、図２と比較して図４内で生じる違いのみを以下に説明する。

図４では、例示的な動作環境４００は、証明書管理サービス４８０と同時に対話することができる２つのクライアント４０２、４２２（例えば、クライアント１およびクライアント２）を含む。図示されているように、クライアント４０２およびクライアント４２２は両方とも、ネットワーク４３５を介して１つ以上のコンピュータ化された機器に対する証明書のそれぞれの同時リクエストを送信することができる。図４の例では、ネットワーク４３５はインターネットである。いくつかの実施形態では、コンピュータ化された機器は、車両、船舶、航空機、宇宙船、医療機器、ロボット、ドローン、無線または有線通信モジュール、およびＩｏＴ機器（例えば、ＩｏＴアプライアンス、ＩｏＴセンサ、ＩｏＴスイッチ、ＩｏＴコントローラ、またはウェアラブルＩｏＴ機器）のうちの１つ以上に対応する。例えば、コンピュータ化された機器は、車両、船舶、航空機、宇宙船、ロボット、ドローン、医療機器、またはＩｏＴ機器のＯＢＵまたはＥＣＵに対応できる。さらに、例えば、コンピュータ化された機器は、交通制御機器（例えば、信号機、交通信号灯、または電子交通標識）、デジタル広告板、または電子看板のＲＳＵに対応することができる。

動作環境４００では、証明書のリクエストは、証明書管理サービス４８０のクライアントＲＥＳＴ ＡＰＩ ４０５によって受信される。図４に示すように、クライアントＲＥＳＴ ＡＰＩ ４０５はパブリックＡＰＩであることができ、証明書管理サービス４８０はＶ２ＸまたはＣ２Ｘ証明書管理サービスであることができる。証明書管理サービス４８０は、証明書のリクエストを受け入れ、タイムフレーム内でタスクを完了し、次いで、ネットワーク４３５を介してクライアント４０２、４２２に結果（例えば、生成された証明書）を返す。証明書管理サービス４８０には、リクエストされた証明書を生成するためのコンポーネントが含まれる。図４の例では、これらのコンポーネントは、登録局４２０、登録認証局４３０、偽名認証局４４０、連携局１ ４５０、および連携局４ ４６０を含む。

追加または代替の実施形態では、証明書管理サービス４８０のコンポーネントは、証明書管理サービス４８０がＶ２ＸまたはＣ２Ｘ証明書管理サービスとして構成されているかどうかによって異なる場合がある。例えば、図２を参照して上述したように、証明書管理サービス４８０がＣ２Ｘ証明書管理サービスとして機能する実施形態では、証明書管理サービス４８０は、登録認証局４３０の役割と類似の役割を果たすように構成された長期認証局（ＬＴＣＡ）を含むことができる。同様に、証明書管理サービス４８０がＣ２Ｘ証明書管理サービスとして具現化される場合、証明書管理サービス４８０は、偽名認証局４４０の役割と同様の役割を果たす認可機関を含むことができる。

動作環境４００には、両方が同じ証明書管理サービス４８０からの作業をリクエストできる２つの同時クライアント４０２、４２２がある。一例では、クライアント４０２（例えば、クライアント１）は、ネットワーク４３５を介して、多数のコンピュータ化された機器（例えば、１００，０００台を超える車両）に対するリクエストを送信することができ、クライアント４２２（例えば、クライアント２）は、クライアント１の証明書リクエストに続いて、比較的少数のコンピュータ化された機器（例えば、５０台未満）のための証明書のリクエストを送信することができる。ＱｏＳマネージャを使用しない単純な証明書管理サービス（Ｖ２ＸまたはＣ２Ｘ）の場合、これら２つのリクエストは、先着順に処理される。この例では、クライアント４２２（例えば、クライアント２）は、応答が提供される前に、クライアント１のジョブが完了するまで待機しなければならない。つまり、クライアント２のリクエストが比較的小さい場合でも、クライアント２のリクエストを実行するのにかかる時間は、普通ならたったの数分である代わりに、時間遅延は数時間または数日であり得る（すなわち、クライアント４０２からの大規模なリクエストが実行されるまでにどれだけの時間がかかろうとも）。

有利なことに、本明細書で開示される実施形態は、証明書管理サービスが複数のクライアントにＱｏＳレベルを提供できるようにするＱｏＳマネージャ（例えば、図８および図９のＱｏＳマネージャ８０１および９０１を参照）を使用して、クライアント４２２などのクライアントが、早い方の大規模なリクエストが実行されるのを待つことに関連する過度の遅延を経験しないようにする。例えば、図８〜１０を参照して本明細書で説明されるように、ＱｏＳマネージャは、証明書管理サービス４８０によって使用され、クライアント４０２、４２２からの証明書リクエストを２つの対応する仲介クライアントキューに分配することができ、２つのクライアントキューの各々は、証明書をリクエストする特定のクライアント（例えば、クライアント４０２またはクライアント４２２）に対応する。ＱｏＳマネージャはまた、クライアントのリクエストを、クライアントが証明書を必要とするコンピュータ化された機器の数のサブセットに各々のエントリが対応する１つ以上のエントリのより小さなグループ（つまり、サブグループ）に分割することができる。

図５は、本発明の実施形態に整合する、２つのクライアント５０２、５２２とＣＭＳ５８０との間の例示的なデータフローを示すデータフロー図である。簡潔にするために、図３と比較して図５内で生じる違いのみを以下に説明する。

図５に示す例では、ＣＭＳ５８０はＶ２Ｘ ＣＭＳまたはＣ２Ｘ ＣＭＳであり得る。特定の実施形態によれば、ＣＭＳ５８０は、図４を参照して上述した証明書管理サービス４８０などの証明書管理サービスをホストすることができる。

図５に示すように、クライアント５０２（例えば、クライアント１）は、大規模なリクエスト５１０、および多数のコンピュータ化された機器（例えば、１１０，０００台の車両）の証明書に対する大規模なリクエスト５１０を送信し、クライアント５２２（例えば、クライアント２）は、クライアント５０２からの大規模なリクエスト５１０に続いて、少数のコンピュータ化された機器（例えば、４０台の車両）の証明書に対する小規模なリクエスト５１２を送信する。様々な実施形態において、各々の証明書リクエスト５１０、５１２は、証明書を必要とするコンピュータ化された機器の数（例えば、大規模なリクエスト５１０については１１０，０００、小規模なリクエスト５１２については４０）、証明書リクエストがいつ送信されたかを示すタイムスタンプ、および証明書（例えば、大規模なリクエスト５１０に対してクライアント５０２および小規模なリクエスト５１２に対してクライアント５２２のそれぞれの識別子）をリクエストするクライアントを示す。例えば、各証明書リクエスト５１０、５１２は、証明書をリクエストする対応するクライアント５０２、５２２のクライアント識別子を含むことができる。一部の実施形態では、クライアント識別子は、クライアント５０２または５２２のいずれかを一意に識別し、一意の英数字文字列、認証トークン、または例えばＴＬＳ証明書などのクライアント認証情報、またはクライアント５０２または５２２に対応する他のタイプのデジタル証明書とすることができる。

図５は、ＱｏＳマネージャのない単純なＣＭＳ５８０が２つのリクエスト５１０、５１２を先着順で処理する方法を示している。大規模なリクエスト５１０がＣＭＳ５８０によって受信されると、ＣＭＳ５８０は、大規模なリクエスト５１０を実行するために必要な証明書のバンドルを生成するために必要な計算を実行するために計算時間５１５を必要とする。図５の例では、リクエストされた証明書のバンドルが生成されると、リクエストされた証明書のバンドルを含む応答５２５がＣＭＳ５８０からクライアント５０２に送信される。すなわち、クライアント５０２は、応答５２５を受信する前に計算５１５を待つだけである。この例では、クライアント５２２（例えば、クライアント２）は、小規模なリクエスト５１２に対する応答５２７を受信するために、待機時間５１６を待たなければならない。図示されるように、クライアント５２２の待機時間５１６は、クライアント１のジョブが完了するのに必要な全計算時間５１５と、小規模なリクエスト５１２に対する応答５２７が提供される前に小規模なリクエスト５１２を実行するために必要な追加の計算時間５１７を含む。つまり、クライアント２の小規模なリクエスト５１２は大規模なリクエスト５１０よりもはるかに少ない証明書のためであり、ＣＭＳ５８０によってはるかに迅速に実行することができても、別な方法でクライアント２の小規模なリクエスト５１２を実行するのにかかる数分だけの代わりに、待機時間５１６は数時間または数日（つまり、クライアント５０２からの大規模なリクエスト５１０が実行されるのに必要とされる計算時間５１５と、小規模なリクエスト５１２が実行される計算時間５１７）となる可能性がある。

図６は、本発明の実施に整合する、マルチクライアント環境６００で動作する例示的な証明書管理サービス６８０のブロック図である。簡潔にするために、図２および図４と比較して、図６内で生じる違いのみを以下に説明する。

図６では、例示的な動作環境６００は、証明書管理サービス６８０と同時に対話することができる複数のクライアント６０２、６２２（例えば、クライアント１およびクライアント２）、６２３、…６２ｎを含む。図示されるように、ｎ個のクライアント６０２、６２２、６２３、…６２ｎのグループはそれぞれ、ネットワーク６３５（例えば、インターネット）を介して１つ以上のコンピュータ化された機器に対する証明書のそれぞれのリクエストを送信することができる。これにより、図４および５を参照して上記で説明した遅延と同様の遅延が発生する可能性があるが、クライアント６０２、６２２、６２３、…６２ｎに複数の大規模なリクエスタが含まれる場合、特に大規模なリクエストが証明書管理サービス６８０によって受信された後に小規模なリクエストが送信された場合、問題が悪化する可能性がある。

動作環境６００では、証明書のリクエストは、証明書管理サービス６８０のクライアントＲＥＳＴ ＡＰＩ ６０５（例えば、Ｖ２ＸまたはＣ２Ｘ証明書管理サービスのパブリックＡＰＩ）によって受信される。証明書管理サービス６８０は、証明書のリクエストを受け入れ、タイムフレーム内でタスクを完了し、その後、ネットワーク６３５を介してクライアント６０２、６２２、６２３、…６２ｎに結果（例えば、生成された証明書）を返す。証明書管理サービス６８０には、リクエストされた証明書を生成するためのコンポーネントが含まれる。図６の例では、これらのコンポーネントは、登録局６２０、登録認証局６３０、偽名認証局６４０、連携局１ ６５０、および連携局６ ６６０を含む。

追加または代替の実施形態では、証明書管理サービス６８０のコンポーネントは、証明書管理サービス６８０がＶ２ＸまたはＣ２Ｘ証明書管理サービスとして構成されているかどうかに応じて異なる場合がある。例えば、図２および図４を参照して上述したように、証明書管理サービス６８０がＣ２Ｘ証明書管理サービスとして機能する実施形態では、証明書管理サービス６８０は、登録認証局６３０の役割と同様の役割を果たすように構成されたＬＴＣＡを含むことができる。同様に、証明書管理サービス６８０がＣ２Ｘ証明書管理サービスとして具現化される場合、証明書管理サービス６８０は、偽名認証局６４０と同様の役割を果たす認証局を含むことができる。

動作環境６００には、各々が同じ証明書管理サービス６８０からの作業をリクエストできる複数の同時クライアント６０２、６２２、６２３、…６２ｎ（例えば、ｎ個のクライアントのグループ）が存在する。一例では、クライアント６０２、６２２（例えば、クライアント１および２）は、ネットワーク６３５を介して、多数のコンピュータ化された機器（例えば、１００，０００台を超える車両）に対する大規模なリクエストを送信でき、クライアント１およびクライアント２の証明書リクエストに続いて、別のクライアント６２３は、証明書に対する別の大規模なリクエストを送信できる。次に、ｎ個のクライアントのグループ内の最後のクライアント６２ｎは、比較的少数のコンピュータ化された機器（例えば、５０台未満の車両）に対する小規模なリクエストを送信することができる。ＱｏＳマネージャを使用しない単純な証明書管理サービス（Ｖ２ＸまたはＣ２Ｘ）の場合、これらのリクエストは先着順に処理されるであろう。この例では、クライアント６２ｎ（例えば、ｎ個のクライアントの最後のクライアント）は、応答が提供される前に、前のクライアントのジョブが完了するまで待機しなければならない。つまり、クライアント６２ｎからのリクエストが比較的小さい場合でも、別な方法でクライアント６２ｎからの小規模なリクエストを実行するのにかかる数分だけの代わりに、時間遅延は数時間または数日（すなわち、クライアント６０２、６２２、６２３からの大規模なリクエストが実行されるのにどれだけの時間がかかろうとも）となる可能性がある。

上記の問題を解決するために、本明細書で開示する実施形態は、証明書管理サービスが複数のクライアントにＱｏＳレベルを提供できるようにするＱｏＳマネージャ（例えば、図８および図９のＱｏＳマネージャ８０１および９０１を参照）を有利に使用するため、クライアント６２ｎなどのクライアントは、より早い大規模なリクエストが実行されるのを待つことに関連する過度の遅延を経験しない。例えば、図８〜１０を参照して本明細書で説明するように、ＱｏＳマネージャを証明書管理サービス６８０で使用して、クライアント６０２、６２２、６２３、…６２ｎからの証明書リクエストをｎ個の対応する仲介クライアントキューに分配することができ、ｎ個のクライアントキューの各々は、証明書をリクエストした特定のクライアントに対応する。ＱｏＳマネージャはまた、クライアントキュー内のクライアントの証明書リクエストを１つ以上のエントリのより小さなグループに分割することができ、１つ以上のエントリの各々は、証明書を必要とするコンピュータ化された機器の数のサブセットに対応するグループサイズを有する。

図７は、本発明の実施に整合する、複数のクライアント（例えば、ｎ個のクライアント７０２、７２２、７２３、…７２ｎ）とＣＭＳ７８０との間の例示的なデータフローを示すデータフロー図である。簡潔にするために、図３および図５と比較して、図７内で生じる違いのみを以下に説明する。

図７に示す例では、ＣＭＳ７８０はＶ２Ｘ ＣＭＳまたはＣ２Ｘ ＣＭＳであり得る。特定の実施形態では、ＣＭＳ７８０は、図６を参照して上述した証明書管理サービス６８０などの証明書管理サービスをホストすることができる。

図７に示すように、クライアント７０２（例えば、クライアント１）は、多数のコンピュータ化された機器（例えば、１１０，０００台の車両）のための証明書に対する大規模なリクエスト７１０を送信し、クライアント７２２（例えば、クライアント２）は、クライアント７０２からの大規模なリクエスト７１０に続いて、別の大規模なリクエスト７１１を送信し、その後、クライアント７２３がさらに別の大規模なリクエスト７１３を送信する。大規模なリクエスト７１０、７１１、および７１３がＣＭＳ７８０によって受信された後、クライアント７２ｎは、比較的少数のコンピュータ化された機器（例えば、４０台の車両）のための証明書に対する小規模なリクエスト７１２を送信する。いくつかの実施形態では、各々の証明書リクエスト７１０、７１１、７１２、７１３は、証明書を必要とするコンピュータ化された機器の数（例えば、大規模なリクエスト７１０の場合は１１０，０００、小規模なリクエスト７１２の場合は４０）、特定の証明書リクエストがいつ送信されたかを示すタイムスタンプ（例えば、送信の時、分、秒を示す日付と時刻）、および証明書をリクエストするクライアント（例えば、大規模なリクエスト７１０、７１１、および７１３についてはクライアント７０２、７２２、７２３、ならびに小規模なリクエスト７１２についてはクライアント７２ｎのそれぞれの識別子）を示すデータフィールドを含む。例えば、各々の証明書リクエスト７１０、７１１、７１２、７１３は、証明書をリクエストする対応するクライアント７０２、７２２、７２ｎ、７２３のクライアント識別子を含むことができる。いくつかの実施形態では、クライアント識別子は、クライアント７０２、７２２、７２３、または７２ｎのうちの１つを一意に識別し、一意の英数字文字列、認証トークン、または例えばＴＬＳ証明書などのクライアント認証情報、または他の種類のデジタル証明書を含み得るか、またはそれらであり得る。

図７は、ＱｏＳマネージャのないＣＭＳ７８０が、複数のリクエスト７１０、７１１、７１２、７１３を先着順で順番に処理する方法を示している。ＣＭＳ７８０によって受信された大規模なリクエスト７１０、７１１、７１３のため、ＣＭＳ７８０は、多数のリクエストされた証明書を生成するために、長い連続した計算時間７１５、７１７、および７１８を必要とする。例えば、ＣＭＳ ７８０は、クライアント７０２からの大規模なリクエスト７１０を実行するために必要な証明書のバンドルを生成するために必要な計算を実行するために、計算時間７１５を必要とする。図７の例では、クライアント７０２によってリクエストされた証明書のバンドルが生成されると、証明書のバンドルを伴う応答７２５がＣＭＳ７８０からクライアント７０２に返送される。すなわち、クライアント７０２は、応答７２５を受信する前に計算７１５を待つだけでよい。この例では、クライアント７２２（例えば、クライアント２）は、応答７２７を受信するために、計算時間７１５および追加の計算時間７１７の待機をしなければならない。

最後に、小規模なリクエスト７１２を有するクライアント７２ｎは、大規模なリクエスト７１０、７１１、７１３の後にその小規模なリクエスト７１２が送信されたという事実により、すべてのクライアント７０２、７２２、７２３、７２ｎの最長時間を待機しなければならない。すなわち、ＱｏＳマネージャ（例えば、以下で説明する図８および図９のＱｏＳマネージャ８０１および９０１を参照）を使用せずに、クライアント７２ｎは、小規模なリクエスト７１２への応答７２７が提供される前に７１６という長い待機時間を経験するであろう。

図７に示されるように、クライアント７２ｎは、小規模なリクエスト７１２に対する応答７２９を受信する前に、待機時間７１６に耐えなければならない。これは、クライアント７２ｎの待機時間７１６には、クライアント２のリクエストを完了するための計算時間７１７、クライアント７２３からのリクエストを完了するための計算時間７１８、および小規模なリクエスト７１２を実行するために必要な計算時間７１９に加えて、クライアント１のジョブを完了するために必要な計算時間７１５全体が含まれているからである。すなわち、たとえクライアント７２ｎが、大規模なリクエスト７１０、７１１、および７１３よりもはるかに少ない証明書に対する小規模なリクエスト７１２を送信したとしても、待機時間７１６は数時間または数日の期間となる可能性がある。これは、待機時間７１６が、クライアント７０２、７２２、７２３からの大規模なリクエスト７１０、７１１、７１３が実行されるのに必要な組み合わせの計算時間７１５、７１７、７１８と、小規模なリクエスト７１２が実行されるための計算時間７１９との合計であるためである。図８および図９を参照して以下で説明するＱｏＳマネージャ８０１および９０１を使用しないと、最初に送信された大規模なリクエスト７１０、７１１、および７１３が実行されるのを最初に待つ必要なしに、クライアント７２ｎからの小規模なリクエスト７１２を実行するためのメカニズムはない。図８〜図１０を参照して以下に説明するように、ＱｏＳマネージャにより、ＣＭＳまたは証明書管理サービスがマルチクライアント環境でＱｏＳレベルを提供できる。

図８は、本発明の実施形態に整合するマルチクライアント環境８００における、複数のクライアント８０２、８２２、８２３、…８２ｎにＱｏＳレベルを提供するためにＱｏＳマネージャ８０１を使用する例示的な証明書管理サービス８８０のブロック図である。簡潔にするために、図２、図４、および図６と比較して、図８で発生する違いのみを以下に説明する。

図８では、例示的なマルチクライアント環境８００は、証明書管理サービス８８０と同時に対話することができる複数のクライアント８０２、８２２（例えば、合計ｎ個のクライアントのうちのクライアント１および２）、８２３、…８２ｎを含む。ｎ個のクライアント８０２、８２２、８２３、…８２ｎのグループは、それぞれ、ネットワーク８３５（例えば、インターネット）を介して１つ以上のコンピュータ化された機器のための証明書に対するそれぞれのリクエストを送信することができる。これにより、図４、図５、および図７を参照して上記で説明した遅延と同様の遅延が発生する可能性があるが、クライアント８０２、８２２、８２３、…８２ｎが複数の大規模なリクエストを送信した場合、特に大規模なリクエストが証明書管理サービス８８０によって受信された後に小規模なリクエストが送信された場合、問題が悪化する可能性がある。

証明書管理サービス８８０は、クライアント８０２、８２２、８２３、…８２ｎによって送信された証明書のリクエストを実行するためのコンポーネントを含む。図８に示すように、これらのコンポーネントには、ＱｏＳマネージャ８０１、パブリック登録局ＡＰＩ８０５、登録局８２０、登録局８２０の内部ＡＰＩ８２５、登録認証局８３０、偽名認証局８４０、連携局１ ８５０、および連携局８ ８６０が含まれる。

様々な実施形態において、パブリック登録局ＡＰＩ８０５は、ｎ個のクライアント８０２、８２２、８２３、…８２ｎからの証明書リクエストを受信するように動作可能であり、各々の証明書リクエストは、証明書を必要とするコンピュータ化された機器の数、証明書リクエストがいつ送信されたかを示すタイムスタンプ、および証明書をリクエストするクライアントを示す。例えば、各々の証明書リクエストは、証明書をリクエストするｎ個のクライアント８０２、８２２、８２３、…８２ｎのうちの１つに対するクライアント識別子を含み得る。一部の実施形態では、クライアント識別子は、クライアント８０２、８２２、８２３、…８２ｎのうちの１つを一意に識別し、一意の英数字文字列、認証トークン、および例えばＴＬＳ証明書などのクライアント認証情報、または他の種類のデジタル証明書のうちの１つ以上を含み得る。

追加または代替の実施形態では、各々のリクエストはまた、それぞれのクライアント優先度レベルを示すことができ、これはクライアントに関連付けられたサービス層に基づくことができる。いくつかの実施形態では、サービス層は、最低のサービスレベルから最高のサービスレベルまでの範囲の複数の層のうちの１つに対応する数値である（例えば、サービス層１〜１０、ここで１が最低のサービスレベルであり、５が中レベルのサービスレベルであり、１０が最高のサービスレベルである）。追加または代替の実施形態によれば、各々のリクエストは、リクエストに関連付けられたリクエスト緊急度レベルをさらに示すことができる。例えば、証明書リクエストのリクエスト緊急度レベルは、証明書リクエストを送信するクライアントによって指定され得る。そのようなリクエストの緊急度レベルは、最低の緊急度オプションから最高の緊急度オプションまでの範囲の複数のレベルのうちの１つに対応する数値とすることができる（例えば、１〜１０、１は最低の緊急度、５は中度の緊急度リクエスト、１０は最も緊急なリクエスト）。様々な実施形態において、クライアントは、クライアントごとまたはリクエストごとに優先度および緊急度レベルを高めるために、サービスプロバイダ（例えば、証明書管理サービス８８０を提供するエンティティまたは別のエンティティ）にプレミアムを支払うことを選択できる。同様に、クライアントは、リベートまたはその他のインセンティブと引き換えに、特定の緊急ではない優先度の低いリクエストに対して優先度と緊急度を選択的に下げることを選択できる。

有利なことに、図８に示す実施形態は、ＱｏＳマネージャ８０１を使用して、証明書管理サービス８８０がＱｏＳレベルをクライアント８０２、８２２、８２３、…８２ｎに提供できるようにし、これによってクライアント８２ｎなどのクライアントが、より早く、大規模なリクエストを実行するための待機に関連する過度の遅延を経験しないようにする。例えば、ＱｏＳマネージャ８０１は、証明書管理サービス８８０によって使用されて、クライアント８０２、８２２、８２３、…８２ｎからの証明書リクエストをｎ個の対応する仲介クライアントキューに分配でき、ｎ個のクライアントキューの各々は、証明書をリクエストした特定のクライアントに対応する。ＱｏＳマネージャ８０１はまた、クライアントキュー内のクライアントの証明書リクエストを１つ以上のエントリのより小さなグループに分割することができ、１つ以上のエントリの各々は、証明書を必要とするコンピュータ化された機器の数のサブセットに対応するグループサイズを有する。特定の実施形態では、グループサイズはユーザが調整可能なパラメータであり、既定値は１である。

ＱｏＳマネージャ８０１は、クライアント８０２、８２２、８２３、…８２ｎと証明書管理サービス８８０との間の仲介として機能する。ＱｏＳマネージャ８０１は、任意の数のクライアント（例えば、図８の例ではｎ個のクライアント）から複数の同時リクエストを受け入れ、それらを仲介クライアントキューに保持することができる。ＱｏＳマネージャ８０１は、大規模なリクエストを小規模なリクエストに分解し、それらの小規模なリクエストを別個のクライアントキューに送り込むことができる（図示せず、しかしながら、以下で説明する図９のクライアントキュー９０３、９０７、９０９、…９１ｎを参照）。これにより、小規模なリクエストをはるかにより早く完了することができ、任意の数のクライアントをサポートできる。また、ＱｏＳマネージャ８０１を使用することで、追加の小規模なリクエストが着信した場合、ＣＭＳまたはＱｏＳマネージャのない証明書管理サービスと比較して、はるかにより早く完了することができるであろう。

マルチクライアント環境８００において、証明書のリクエストは、ＱｏＳマネージャ８０１の登録局ＡＰＩ８０５（例えば、パブリックＡＰＩ）によって受信される。ＱｏＳマネージャ８０１は、証明書管理サービス８８０に代わって証明書のリクエストを受け入れる。様々な実施形態において、ＱｏＳマネージャ８０１は、ｎ個のクライアント８０２、８２２、８２３、…８２ｎからの証明書リクエストをｎ個の仲介クライアントキューに分配するように動作可能であり、ｎ個のクライアントキューの各々は、証明書をリクエストする特定のクライアントに対応する。ＱｏＳマネージャ８０１は、そのクライアントのクライアントキュー内の特定のクライアントのリクエストを１つ以上のエントリのサブグループ（すなわち、より小さいグループ）に分割するように構成することもでき、１つ以上のエントリの各々は、クライアントが証明書を必要とするコンピュータ化された機器の数のサブセットに対応するグループサイズを有する。以下の図９を参照してより詳細に説明するように、いくつかの実施形態では、ＱｏＳマネージャ８０１はＱｏＳアービター（図示せず、しかしながら、図９のＱｏＳアービター９０４を参照）を含む。ＱｏＳアービターは、ＱｏＳキュー内のエントリの数、証明書管理サービス８８０の待機時間レベル、および証明書リクエストがいつ送信されたかを示すそれぞれのタイムスタンプに少なくとも部分的に基づいて、ＱｏＳキューに配置される複数のクライアントキューからのエントリの順序を選択するように動作可能である。いくつかの実施形態によれば、ＱｏＳマネージャ８０１は、ＱｏＳアービターによって選択された順序でＱｏＳキューからエントリを取得し、登録局８２０の内部ＡＰＩ８２５を介して、取得されたエントリを証明書管理サービス８８０に送信する。次に、ＱｏＳマネージャ８０１は、証明書管理サービス８８０の登録局８２０の内部ＡＰＩ８２５への呼び出しを介して、ＱｏＳキューから証明書管理サービス８８０にエントリを転送する。次に、証明書管理サービス８８０は、タイムフレーム内でＱｏＳマネージャ８０１によってそれに転送されたタスクを完了し、次に結果（例えば、生成された証明書）をＱｏＳマネージャ８０１に返す。次に、ＱｏＳマネージャ８０１は、登録局ＡＰＩ８０５およびネットワーク８３５を介して、クライアント８０２、８２２、８２３、…８２ｎへの応答として結果を転送する。

動作環境８００には、複数の同時クライアント８０２、８２２、８２３、…８２ｎ（例えば、ｎ個のクライアントのグループ）があり、これは、ｎ個のクライアントと証明書管理サービス８８０との間の仲介として機能するＱｏＳマネージャ８０１と同時に対話することができる。一例では、クライアント８０２、８２２（例えば、クライアント１および２）は、ネットワーク８３５を介して、多数のコンピュータ化された機器（例えば、１００，０００台を超える車両）に対する大規模なリクエストを送信することができ、クライアント１およびクライアント２の証明書リクエストに続いて、別のクライアント８２３は、証明書に対する別の大規模なリクエストを送信することができる。次いで、ｎ個のクライアントのグループ内の最後のクライアント８２ｎは、比較的少数のコンピュータ化された機器（例えば、５０台未満の車両）に対する小規模なリクエストを送信することができる。上記のように、ＱｏＳマネージャ８０１を備えた証明書管理サービス８８０の場合、これらのリクエストはクライアントキューに配置され、クライアント８０２、８２２、８２３、…８２ｎにＱｏＳレベルを提供するために必要に応じて徐々に（例えば、特定のグループサイズのサブセットに）分割および処理される。すなわち、リクエストのサイズまたは優先度の変化に関係なく、先着順でリクエストを順番に処理する必要がある代わりに、ＱｏＳマネージャ８０１を有利に使用して、リクエストを順番に処理する必要を避ける。例えば、応答が提供される前に最後のクライアント（例えば、クライアント８２ｎ）が先行クライアントのすべてのジョブの完了を待機するようにリクエストする代わりに、ＱｏＳマネージャ８０１は、証明書管理サービス８８０が、後で到着するが過度の遅延なし（つまり、先行クライアント８０２、８２２、８２３からの大規模なリクエストが実行されるまでにいかに時間がかかろうとも、数時間または数日）に完了されるべき、クライアント８２ｎからのより小規模なリクエストを実行することを可能にする。

図９は、本発明の実装に整合する、ＱｏＳマネージャ９０１を実装するためのシステム９００の一例のブロック図である。簡潔にするために、図８と比較したときに図９内で生じる違いのみを以下に説明する。

図９では、例示的なシステム９００は、クライアントと証明書管理サービス９８０との間の仲介として機能するＱｏＳマネージャ９０１と同時に対話することができる複数のクライアント９０２、９２２（例えば、ｎ個の全クライアントのうちのクライアント１および２）、９２３、…９２ｎを含む。複数のクライアント９０２、９２２、９２３、…９２ｎはそれぞれ、ネットワーク９３５（例えば、図９の非限定的な例ではインターネット）を介して、１つ以上の機器の証明書に対するそれぞれのリクエストを送信することができる。

証明書管理サービス９８０は、クライアント９０２、９２２、９２３、…９２ｎによって送信された証明書のリクエストを実行するためのコンポーネントを含む。様々な実施形態において、公開登録局ＡＰＩ９０５は、ｎ個のクライアント９０２、９２２、９２３、…９２ｎから証明書リクエストを受信するように動作可能であり、各々の証明書リクエストは、証明書を必要とするコンピュータ化された機器の数、証明書リクエストがいつ送信されたかを示すタイムスタンプ、および証明書をリクエストするクライアントを示す。追加または代替の実施形態では、各々のリクエストはまた、それぞれのクライアント優先度レベルを示すことができ、これはクライアントに関連付けられたサービス層に基づくことができる。一部の実施形態では、サービス層は、最低のサービスレベルから最高のサービスレベルまでの範囲の複数の層のうちの１つに対応する英数字の文字列または数値である（例えば、サービス層１〜１０、ここで１は最低またはブロンズサービス層を表し、５は中層またはシルバー層を表し、７は高層またはゴールド層を表し、１０は最高層またはプラチナ層を表す）。追加または代替の実施形態によれば、各々のリクエストは、リクエストに関連付けられたリクエスト緊急度レベルをさらに示すことができる。例えば、証明書リクエストのリクエスト緊急度レベルは、証明書リクエストを送信するクライアントによって指定され得る。このようなリクエストの緊急度レベルは、最低の緊急度オプションから最高の緊急度オプションまでの範囲の複数のレベルの１つに対応する英数字の文字列または数値とすることができる（例えば、１〜１０、ここで１は低緊急度のリクエスト、５はデフォルトで通常の緊急度リクエスト、７は非常に緊急のリクエスト、１０は極めて緊急のリクエスト）。様々な実施形態において、クライアント９０２、９２２、９２３、…９２ｎのうちの１つ以上は、クライアントごとまたはリクエストごとに優先度および緊急度レベルを高めるために、サービスプロバイダ（例えば、ＱｏＳマネージャ９０１を提供するエンティティまたは別のエンティティ）にプレミアムを支払うことを選択できる。同様に、クライアントは、リベートまたはその他のインセンティブと引き換えに、特定の緊急ではない優先度の低いリクエストに対して優先度と緊急度を選択的に下げることを選択できる。

有利には、システム９００は、ＱｏＳマネージャ９０１を使用して、証明書管理サービス９８０がクライアント９０２、９２２、９２３、…９２ｎにＱｏＳレベルを提供できるようにし、これによってクライアント９２ｎなどのクライアントが、より早い、大規模なリクエストを実行するための待機に関連する過度の遅延を経験しないようにする。例えば、ＱｏＳマネージャ９０１は、証明書管理サービス９８０によって使用されて、クライアント９０２、９２２、９２３、…９２ｎからの証明書リクエストを、ｎ個の対応する仲介クライアントキュー９０３、９０７、９０９、…９１ｎに分配することができ、これらのｎ個のクライアントキューの各々は、証明書をリクエストした特定のクライアントに対応する。図９の例では、クライアントキュー９０３はクライアント９０２に対応し、クライアントキュー９０７はクライアント９２２に対応し、クライアントキュー９０９はクライアント９２３に対応し、クライアントキュー９１ｎはクライアント９２ｎに対応する。

図９に示すように、ＱｏＳマネージャ９０１はまた、クライアントキュー内のクライアントの証明書リクエストを１つ以上のエントリのより小さなグループに分割することができ、１つ以上のエントリの各々は、証明書を必要とするコンピュータ化された機器の数のサブセットに対応するグループサイズを有する。図９の非限定的な例では、グループサイズは５０である（例えば、５０台の車両のための証明書）。ただし、代替の実施形態では、グループサイズは任意の数にすることができ、証明書は任意のコンピュータ化された機器用（すなわち、車両に限定されない）にすることができることが理解される。例えば、グループサイズはクライアントによって異なる場合があり、特定の実施形態では、サイズはクライアントキュー９０３、９０７、９０９、…９１ｎのキューエントリごとに１台のコンピュータ化された機器である。代替または追加の実施形態では、グループサイズはユーザが調整可能なパラメータであり、既定値は１である。代替の一実施形態では、システム９００は、図９に示される専用クライアントキュー９０３、９０７、９０９、…９１ｎの代わりに、プールされたキューアプローチを使用することができる。例えば、図９に示すように、ｎ個のクライアントの各々とクライアントキューの数との間に１対１のマッピングを使用して、クライアントキューをクライアントごとに専用にする必要はない。つまり、顧客ごとに専用の（所定の）クライアントキューを有するシステム９００の代わりに、プールされたキューの実施形態はキューのプールを利用し、クライアントがアクティブなときにキューのプールから所与のキューのみを割り当てることができる。つまり、プールされたキューの実施形態では、クライアントが証明書リクエストを送信したとき（すなわち、クライアントがアクティブなとき）にのみ、そのクライアントにキューを割り当てることができる。専用キューの実施形態の１つの利点は、クライアントがクライアントの状態を非アクティブからアクティブまたはアクティブから非アクティブに変更する場合、システム９００がキューを割り当てるためのロジックまたは命令の実行を必要としないことである。プールされたキューの実施形態の１つの利点は、ＱｏＳキュー９０６に配置されるアクティブなジョブを探すときに、ＱｏＳアービター９０４が実行する必要がある作業を最適化できることである。すなわち、プールされたキューの実施形態では、ＱｏＳアービター９０４は、（非アクティブなクライアントに対しては空の専用クライアントキューをスキャンする必要が潜在的にあるのとは対照的に）アクティブなクライアントのキューを現在の保留中の証明書リクエストでスキャンすればよい。

ＱｏＳマネージャ９０１は、クライアント９０２、９２２、９２３、…９２ｎと証明書管理サービス９８０との間の仲介として機能する。ＱｏＳマネージャ９０１は、任意の数のクライアント（例えば、図９の例ではｎ個のクライアント）から複数の同時リクエストを受け入れ、それらを仲介のクライアントキュー９０３、９０７、９０９、…９１ｎに保持することができる。図９に示されるように、ＱｏＳマネージャ９０１は、大規模なリクエストを小規模なリクエストに分解し、それらの小規模なリクエストをクライアントキュー９０３、９０７、９０９、…９１ｎの別々のそれぞれのものにする。これにより、小規模なリクエストをはるかにより早く完了することができ、任意の数のクライアントをサポートできる。また、ＱｏＳマネージャ９０１を使用することで、大規模なリクエストを受信した後に追加の小規模なリクエストが入ってきた場合、それらの小規模なリクエストは、ＱｏＳマネージャ９０１のないＣＭＳまたは証明書管理サービスと比較して、はるかに早く完了することができる。

システム９００では、証明書のリクエストは、ＱｏＳマネージャ９０１の登録局ＡＰＩ９０５（例えば、パブリックＡＰＩ）によって受信される。ＱｏＳマネージャ９０１は、証明書管理サービス９８０に代わって証明書のリクエストを受け入れる。様々な実施形態において、ＱｏＳマネージャ９０１は、ｎ個のクライアント９０２、９２２、９２３、…９２ｎからの証明書リクエストをｎ個の仲介クライアントキューに分配するように動作可能であり、ｎ個のクライアントキューの各々は証明書をリクエストする特定のクライアントに対応する。ＱｏＳマネージャ９０１は、特定のクライアントのリクエストをそのクライアントのクライアントキュー内において１つ以上のエントリのより小さなグループに分割するように構成することもでき、１つ以上のエントリの各々は、クライアントが証明書を必要とするコンピュータ化された機器の数のサブセット（例えば、クライアントキュー９０３の部分１、２、３、４、…ｘを参照）に対応するグループサイズを有する。すなわち、ＱｏＳマネージャ９０１は、所与のクライアントからの大規模な証明書リクエストをより小さな断片に分解し、それらのより小さな断片をそのクライアントのクライアントキューに入れることができる。

様々な実施形態において、ＱｏＳマネージャ９０１は、ＱｏＳアービター９０４を含む。ＱｏＳアービター９０４は、ＱｏＳキュー９０６に配置されるクライアントキューからのエントリを選択する。特定の実施形態では、ＱｏＳアービター９０４は、ラウンドロビン技術を使用してＱｏＳキュー９０６に配置されるクライアントキュー９０３、９０７、９０９、…９１ｎからのエントリの順序を選択するように動作可能である。すなわち、ＱｏＳアービター９０４は、各クライアントキュー９０３、９０７、９０９、…９１ｎの各々からエントリを順次選択し、第１のクライアントキュー９０３から始まる順番に移動し、他の各クライアントキュー９０７、９０９、…９１ｎの各々を通って次々に進むことができる。ＱｏＳアービター９０４は、必要に応じてＱｏＳキュー９０６に単に十分なエントリを配置することのみによって、エントリを調整する。例えば、ＱｏＳキュー９０６は、許可されるエントリの数を制限することができる。システム９００の効率を改善するために、許可されるエントリの数は、証明書管理サービス９８０が常にビジーであることを保証するのに十分大きい値ではあるが、待機時間を最小限にするのに十分小さい値に設定することができる。すなわち、ＱｏＳキュー９０６のキューの深さは制限されており、この制限はＱｏＳアービター９０４によって知られている。

ＱｏＳアービター９０４は、新しいリクエストが入ってＱｏＳキュー９０６に配置されることを可能にするように、ＱｏＳキュー９０６のサイズを最小化することを追求することができる。いくつかの実施形態では、ＱｏＳアービター９０４が特定の順序でＱｏＳキュー９０６にアイテムを配置した場合でも、後で到着するが優先度の高いリクエストをＱｏＳキュー９０６の末尾ではなく先頭に挿入できる。言い換えれば、ＱｏＳキュー９０６内の新たなエントリは、通常、ＱｏＳキュー９０６の末尾に配置または設定される。図９のＱｏＳキュー９０６の先頭は、ＱｏＳキュー９０６の最下部にあるクライアント１（例えば、クライアント１（ｘ５０））のためのエントリである。このエントリは、内部ＡＰＩ９２５を介して証明書管理サービス９８０に向かう次のエントリになるであろうＱｏＳキュー９０６の先頭にある。しかしながら、場合によっては、ＱｏＳアービター９０４は、ＱｏＳキュー９０６の先頭、または先頭と末尾の間のどこかに新しいエントリを挿入することを選択することができる。例えば、ＱｏＳアービター９０４によるＱｏＳキュー９０６へのエントリの配置は、証明書リクエストで示されるクライアント優先度レベルおよび／または証明書リクエスト緊急度に基づくことができる。

いくつかの実施形態では、ＱｏＳアービター９０４は、追加のクライアントから受信した追加の証明書リクエスト（例えば、クライアント９２ｎからのリクエスト後に新しいクライアントから受信したリクエスト）に少なくとも部分的に基づいてＱｏＳキュー９０６に配置されるエントリの順序を動的に並べ替えるようにさらに動作可能である。さらに、例えば、ＱｏＳキュー９０６内のエントリの順序は、ＱｏＳアービター９０４により、クライアントキュー９０３、９０７、９０９、…９１ｎの各々に割り当てられた動的優先度に基づいて決定することができ、ここでクライアントキュー９０３、９０７、９０９、…９１ｎの各々に割り当てられたそれぞれの動的優先度は、クライアントキュー９０３、９０７、９０９、…９１ｎの各々のエントリの数に少なくとも部分的に基づいてＱｏＳアービターによって割り当てられる。

様々な実施形態において、ＱｏＳアービター９０４は、ＱｏＳキュー９０６のエントリの数、証明書管理サービス９８０の待機時間レベル、および証明書リクエストがいつ送信されたかを示すそれぞれのタイムスタンプに少なくとも部分的に基づいて、ｎ個のクライアントキュー９０３、９０７、９０９、…９１ｎから一連のエントリを選択して、ＱｏＳキュー９０６に配置されるように動作可能である。

図９の例では、ＱｏＳアービター９０４は、ラウンドロビン技術を使用してＱｏＳキュー９０６に配置される複数のクライアント（例えば、クライアント１、クライアント２…クライアントｎ）からのエントリの順序を選択している。追加または代替の実施形態では、ＱｏＳアービター９０４は、証明書リクエスト内で示され得るリクエスト緊急度レベルまたはクライアント優先度レベルに基づいてＱｏＳキュー９０６に配置されるｎ個のクライアントキュー９０３、９０７、９０９、…９１ｎからのエントリの順序を選択するようにさらに動作可能である。例えば、ラウンドロビン技術を使用して、すべてのクライアント９０２、９２２、９２３、…９２ｎ間のクライアントキュー９０３、９０７、９０９、…９１ｎからのエントリの順序を選択する代わりに、ＱｏＳアービター９０４は、クライアント間のバランスを変更するルールに基づいてエントリの順序を選択できる。例えば、エントリの順序は、高優先度で高給のクライアント（特定の自動車メーカーなど）および低優先度で低給のクライアント（例えば、アイドル時間の処理に対してのみ支払いたいと思う特定の大学）を示すそれぞれのクライアント優先度レベルに基づいて決定され得る。この例では、ＱｏＳアービター９０４は、優先度の低いクライアントからのエントリの前に優先度の高いクライアントからのエントリをＱｏＳキュー９０６に配置する。また、例えば、エントリの順序は、それぞれのリクエスト緊急度レベルに基づいて決定することができ、ＱｏＳアービター９０４は、より緊急度の低いリクエストに対応するエントリの前に優先度の高いリクエストに対応するエントリをＱｏＳキュー９０６に配置する。追加の実施形態では、ＱｏＳアービター９０４は、証明書管理サービス９８０が単位時間あたりクライアントごとに一定数を超える証明書を決して処理してはならないことを示すレート制限ルールに基づいて、ＱｏＳキュー９０６に対するエントリの順序を選択してもよい（例えば、所与のクライアントを１時間あたりまたは１日あたりｘ個以下の証明書に制限する）。

システム９００では、クライアント９０２、９２２、９２３、…９２ｎの所与のクライアントは、複数の同時の証明書リクエストを有し得る。特定の実施形態では、ＱｏＳマネージャ９０１は、同じクライアントからの複数のリクエストを区別しない場合がある。代替または追加の実施形態では、ＱｏＳマネージャ９０１は、単一クライアントからの同時リクエストをルールに基づいてさらに分割できる。例示的な一実施形態によれば、ＱｏＳマネージャ９０１は、クライアントがシステム９００に提供するそれぞれのリクエスト緊急度レベルおよびそのクライアントからのリクエスト間で緊急度レベルを実施するルールに基づいてクライアントのリクエストを分割することができる。この例示的な実施形態では、ＱｏＳマネージャ９０１は、ＱｏＳアービター９０４に、クライアントがその証明書リクエストの各々に対して提供する緊急度レベルに基づいて、所与のクライアントからの複数のリクエストの一部を処理する順序を指示し得る。別の一実施形態では、クライアントは、ＱｏＳマネージャ９０１がラウンドロビン技術を使用して、そのクライアントのすべての証明書リクエストにわたってエントリの順序を選択できるようにすることができる。

追加または代替の実施形態では、ＱｏＳアービター９０４は、証明書リクエスト内で示され得るリクエスト緊急度レベルまたはクライアント優先度レベルに基づいてＱｏＳキュー９０６に配置されるｎ個のクライアントキュー９０３、９０７、９０９、…９１ｎからのエントリの順序を選択するようにさらに動作可能である。図９に示すように、ＱｏＳアービター９０４は、ＱｏＳキュー９０６に配置される複数のクライアント（例えば、クライアント１、クライアント２…クライアントｎ）からのエントリの順序を選択している。

特定の実施形態では、証明書管理サービス９８０は、内部ＡＰＩ９２５への呼び出しを介して、ＱｏＳキュー９０６からエントリをプルする。ただし、上記のように、（９０２、９２２、９２３、９２ｎのいずれでもない新しいクライアントからの）新しいリクエスト、またはクライアント９０２、９２２、９２３、９２ｎのいずれかからのＱｏＳキュー９０６内の他のエントリよりも優先度が高い新しいリクエストに対して、その後、ＱｏＳアービター９０４は、処理すべきＣＭＳ９８０の次のエントリとして、新規のより高い優先度のエントリをＱｏＳキュー９０６内に置くことができる。一実施形態では、ＱｏＳアービター９０４は、ＱｏＳキュー９０６を一時的に凍結または一時停止し、新規のより高い優先度のエントリがＱｏＳキュー９０６に配置されるまで、証明書管理サービス９８０がそれ以上のエントリをＱｏＳキュー９０６からプルできないようにすることができる。代替の一実施形態では、ＱｏＳアービター９０４は、ＱｏＳキュー９０６からより低い優先度のエントリを除去してそれをより高い優先度のエントリに置き換えることができ、ＱｏＳアービター９０４は除去されたエントリを対応するクライアントキューに戻すことができる。

いくつかの実施形態によれば、ＱｏＳマネージャ９０１は、ＱｏＳアービター９０４によって選択された順序でＱｏＳキュー９０６からエントリを取得し、内部ＡＰＩ９２５を介して、取得されたエントリを証明書管理サービス９８０に送信する。次に、ＱｏＳマネージャ９０１は、証明書管理サービス９８０の登録局の内部ＡＰＩ９２５への呼び出しを介して、ＱｏＳキューから証明書管理サービス９８０にエントリを転送する。次に、証明書管理サービス９８０は、タイムフレーム内でＱｏＳマネージャ９０１によってそれに転送されたタスクを完了し、次に結果（例えば、生成された証明書）をＱｏＳマネージャ９０１に返す。次に、ＱｏＳマネージャ９０１は、登録局ＡＰＩ９０５およびネットワーク９３５を介して、クライアント９０２、９２２、９２３、…９２ｎへの応答として結果を転送する。

システム９００には、ＱｏＳマネージャ９０１を介して、同じ証明書管理サービス９８０からの作業をそれぞれリクエストすることができる複数のクライアント９０２、９２２、９２３、…９２ｎ（例えば、ｎ個のクライアントのグループ）が存在する。すなわち、複数の同時クライアント９０２、９２２、９２３、…９２ｎは、ｎ個のクライアントと証明書管理サービス９８０との間の仲介として機能するＱｏＳマネージャ９０１と同時に対話することができる。図９に示される例では、クライアント９０２、９２２（例えば、クライアント１および２）は、ネットワーク９３５を介して、多数のコンピュータ化された機器（例えば、１００，０００台を超える車両）に対する大規模なリクエストを送信することができ、別のクライアント９２３は、クライアント１およびクライアント２の証明書リクエストに続いて、証明書に対する別の大規模なリクエストを送信することができる。次いで、ｎ個のクライアントのグループ内の最後のクライアント９２ｎは、比較的少数のコンピュータ化された機器（例えば、５０台未満の車両）に対する小規模なリクエストを送信することができる。上記のように、ＱｏＳマネージャ９０１を含むシステム９００の場合、これらのリクエストは、ＱｏＳレベルをクライアント９０２、９２２、９２３、…９２ｎに提供するために、クライアントキュー９０３、９０７、９０９、…９１ｎに配置され、徐々に（例えば、図９の非限定的な例におけるグループサイズ５０のサブセットに）分割され処理される。つまり、ＱｏＳマネージャ９０１は、クライアント９０２、９２２、９２３、…９２ｎからのリクエストを、リクエストのサイズの変化や優先度に関係なく、先着順で順番に処理する必要がある代わりに、システム９００は、リクエストを順番に処理する必要を有利に防ぐ。例えば、応答が提供される前に、最後のクライアント（例えば、クライアント９２ｎ）が先行クライアントのジョブの完了を待機することをリクエストするのではなく、ＱｏＳマネージャ９０１は、証明書管理サービス９８０が、後で到着するが過度の遅延なし（すなわち、先行クライアント９０２、９２２、９２３からの大規模なリクエストが実行されるまでにいかに時間がかかろうとも、数時間または数日）に完了されるべき、クライアント９２ｎからのより小規模なリクエストを実行することを可能にする。

図１０は、本発明の実施形態に整合する、複数のクライアントキュー１００３、１００７、１００９、…１０１ｎとＱｏＳマネージャを使用するＣＭＳ１０８０との間の例示的なデータフローを示すデータフロー図である。簡潔にするために、図７と比較したときに図１０内で生じる違いのみを以下に説明する。

図１０に示される例では、ＣＭＳ１０８０は、Ｖ２Ｘ ＣＭＳまたはＣ２Ｘ ＣＭＳであり得る。特定の実施形態では、ＣＭＳ１０８０は、図９を参照して上述した証明書管理サービス９８０などの証明書管理サービスをホストすることができる。いくつかの実施形態では、ＱｏＳアービターを備えたＱｏＳマネージャ（例えば、図９を参照して上述したＱｏＳマネージャ９０１およびＱｏＳアービター９０４）は、ＣＭＳ １０８０に提出されるｎ個のクライアントキュー１００３、１００７、１００９、…１０１ｎからエントリを選択できる。

図１０に示すように、ＣＭＳ１０８０は、第１のクライアント（例えば、クライアント１）に対するクライアントキュー１００３から証明書の大規模なリクエスト１０１０を受信し、大規模なリクエスト１０１０に続いて、第２のクライアント（例えば、クライアント２）に対するクライアントキュー１００７からの別の大規模なリクエスト１０１３を受信し、その後、クライアントキュー１００９からさらに別の大規模なリクエスト１０１４が受信される。大規模なリクエスト１０１０、１０１３、および１０１４がＣＭＳ１０８０によって受信された後、比較的少数のコンピュータ化された機器（例えば、５０台の車両）の証明書に対する小規模なリクエスト１０１２がクライアントキュー１０１ｎから受信される。いくつかの実施形態では、各々の証明書リクエスト１０１０、１０１３、１０１４、１０１２には、証明書を必要とするコンピュータ化された機器の数（例えば、大規模リクエスト１０１０に対して１１０，０００、小規模リクエスト１１１２に対して５０）、特定の証明書リクエストがいつ送信されたかを示すタイムスタンプ（例えば、送信の時、分、秒を示す日付と時刻）、および証明書をリクエストするクライアント（例えば、大規模なリクエスト１０１０、１０１１、および１０１３に対するクライアント１００２、１０２２、および１０２３、ならびに小規模なリクエスト１０１２に対するクライアント１０２ｎのそれぞれの識別子）を示すデータフィールドが含まれる。

図１０は、ＱｏＳマネージャを備えたＣＭＳ１０８０が複数のリクエスト１０１０、１０１２、１０１３、１０１４を処理する方法を示している。ＱｏＳマネージャおよびそのＱｏＳアービターを使用することにより、後に到着するより小規模なリクエスト１０１２は、大規模なリクエスト１０１０、１０１３、１０１４が最初に実行されるのを待つことなく実行することができる。すなわち、図１０は、クライアントキュー１０１ｎからのより小規模なリクエスト１０１２が、以前のリクエスト１０１０、１０１３、１０１４のすべてが完了するのを待つ必要がない方法を示している。言い換えると、ＣＭＳ１０８０が小規模なリクエスト１０１２を実行する前に、大規模なリクエスト１０１０、１０１３、１０１４のすべてを完了することに関連する長い連続した計算時間が経過する必要はない。これは、ＱｏＳマネージャがリクエスト１０１０、１０１２、１０１３、１０１４をクライアントキュー１００３、１００７、１００９、…１０１ｎに配置される部分に分割することによって実現される。これらの部分は、１つ以上のエントリのサブグループ（つまり、より小さいグループ）であり、１つ以上のエントリの各々は、証明書を必要とするコンピュータ化された機器の数のサブセットに対応するグループサイズを有する。図１０の非限定的な例では、グループサイズは５０であり、車両に対して証明書がリクエストされる。代替または追加の実施形態では、グループサイズはデフォルト値が１の調整可能な数値であり、証明書はセキュリティ認証情報を必要とする様々なコンピュータ化された機器用であり得る。

図１０に示されるように、ＣＭＳ１０８０は、クライアント１００２からの大規模なリクエスト１０１０を実行するために必要な証明書のバンドルの第１の部分（例えば、クライアント１のリクエストの部分１）を生成するのに必要な計算を実行する計算時間１０１５を必要とする。図１０の例では、クライアント１０２２からの大規模なリクエスト１０１３の第１の部分（例えば、クライアント２のリクエストの部分１）に移る前に、クライアント１００２（例えば、クライアント１）によってリクエストされた証明書のバンドルの部分１のみが生成され、これには計算時間１０１７が必要である。次に、クライアント１０２３からの大規模なリクエスト１０１４の部分１が処理され、これには計算時間１０１８が必要である。次に、クライアント１０２ｎからの小規模なリクエスト１０１２は、計算時間１０１６で処理される。ＱｏＳマネージャを使用して大規模なリクエストを分割することにより、クライアント１０２ｎは、クライアント１００２、１０２２、１０２３からの大規模なリクエスト１０１０、１０１３、１０１４の部分１が完了する時間量を待つだけでよい。これは、大規模なリクエスト１０１０、１０１１、および１０１３の後に小規模なリクエスト１０１２が送信されたという事実にもかかわらずである。ＱｏＳマネージャを使用しないと（例えば、上述の図９のＱｏＳマネージャ９０１を参照）、クライアント１０２ｎは、小規模なリクエスト１０１２が実行される前に完了する大規模なリクエスト１０１０、１０１３、１０１４のすべての部分を待つ必要があるため、小規模なリクエスト１０１２への応答が提供される前に、長い待機時間を経験するだろう。

図１０に示すように、クライアント１０２ｎは、小規模なリクエスト１０１２に対する応答を受信する前に、部分１計算時間１０１５、１０１７、１０１８、および１０１６の合計を待つだけでよい。これは、クライアント１０２ｎの待機時間には、大規模なリクエスト１０１０、１０１３、１０１４のすべての部分が完了するのに必要な全計算時間が含まれていないためである。代わりに、クライアント１０２ｎは、小規模なリクエスト１０１２を完了するための計算時間１０１６に加えて、大規模なリクエスト１０１０、１０１３、１０１４の第１の部分を完了するための比較的小さい計算時間１０１５、１０１７、および１０１８だけ待つ必要がある。つまり、クライアント１０２ｎが大規模なリクエスト１０１０、１０１１、および１０１３の後に小規模なリクエスト１０１２を送信したとしても、待機時間はＱｏＳマネージャが使用されない場合よりもはるかに短くなるだろう。これは、大規模なリクエスト１０１０、１０１３、１０１４を部分に分割するＱｏＳマネージャがなければ、クライアント１０２ｎの待機時間は、クライアント１００２、１０２２、１０２３からの大規模なリクエスト１０１０、１０１３、１０１４を実行するのに必要な組み合わされた計算時間全体と小規模なリクエスト１０１２が実行されるための計算時間１０１６との合計になるためである。図９を参照して上述したＱｏＳマネージャ９０１の使用なしでは、先に送信された大規模なリクエスト１０１０、１０１３、および１０１４が実行されるのを最初に待つ必要なしに、クライアント１０２ｎからの小規模なリクエスト１０１２が実行される機構は存在しない。つまり、ＱｏＳマネージャにより、ＣＭＳ１０８０はマルチクライアント環境でＱｏＳレベルを提供できる。

次に、小規模なリクエスト１０１２が実行された後、ＣＭＳ１０８０はクライアント１００２からの大規模なリクエスト１０１０の部分２を処理し、これには計算時間１０１５’を必要とする。次に、クライアント１０２２からの大規模なリクエスト１０１３の部分２（例えば、クライアント２のリクエストの部分２）が処理され、これには計算時間１０１７’を必要とする。次に、クライアント１０２３からの大規模なリクエスト１０１４の部分２が処理され、これには計算時間１０１８’を必要とする。この時点で、クライアント１０２ｎからの小規模なリクエスト１０１２はすでに実行されているため、ＣＭＳ１０８０はクライアント１００２からの大規模なリクエスト１０１０の部分３を処理し、これには計算時間１０１５’’を必要とする。大規模なリクエスト１０１０、１０１３、および１０１４の残りの部分は、これらのリクエストが完了するまでこの方法で処理される。

いくつかの実施形態では、ＱｏＳアービター（例えば、図９のＱｏＳアービター９０４）は、ＣＭＳ１０８０によって使用されるＱｏＳキューに配置されるエントリの順序を動的に並べ替えることができる。このようにして、ＣＭＳ１０８０が処理するリクエスト部分の順序を動的に変更できる。例えば、ＱｏＳマネージャが追加のクライアントからの追加の証明書リクエスト（つまり、新しいクライアントからの小規模なリクエスト１０１２に続くリクエスト）を受信したことに応答して、エントリの順序を変更できる。さらに、例えば、エントリの順序は、クライアントの優先度レベルおよび／または証明書リクエストで示される証明書リクエストの緊急度に基づくことができる。また、例えば、エントリの順序は、クライアントキュー１００３、１００７、１００９、…１０１ｎの各々に割り当てられた動的優先度に基づいて変更でき、クライアントキュー１００３、１００７、１００９、…１０１ｎの各々に割り当てられたそれぞれの動的優先度は、クライアントキュー１００３、１００７、１００９、…１０１ｎの各々のエントリの数に少なくとも部分的に基づいて、ＱｏＳアービターによって割り当てられる。

図１１は、本発明の実施形態に整合するシステムおよび方法を実装するために使用することができるコンピューティングシステム１１００を含む、コンピューティング環境１１０１の一例のブロック図である。他のコンポーネントおよび／または配置もまた使用することができる。いくつかの実施形態では、コンピューティングシステム１１００を使用して、配信機器１０８、登録局１２０、連携局１５０、１６０、偽名認証局１４０などの図１〜１０の様々なコンポーネント、とりわけ、図１Ａおよび図１Ｂの登録認証局１３０、図２、図４、図６、および図８の証明書管理サービス２８０、４８０、６８０、８８０のコンポーネント、図９のＱｏＳマネージャ９０１、および図３、図５、図７、および図１０の証明書管理システム（ＣＭＳ）３８０、５８０、７８０、１０８０を少なくとも部分的に実装することができる。いくつかの実施形態では、コンピューティングシステム１１００と同様の一連のコンピューティングシステムは、それぞれ、専用ハードウェアでカスタマイズされ、および／または図１〜図１０のコンポーネントのうちの１つを実装するための専用サーバとしてプログラムすることができ、これは、ネットワーク１１３５を介して互いに通信することができる。

図１１に示す例では、コンピューティングシステム１１００は、ＣＰＵ１１０５、メモリ１１１０、入出力（Ｉ／Ｏ）機器１１２５、ハードウェアセキュリティモジュール（ＨＳＭ）１１４０、および不揮発性ストレージ機器１１２０などの多くのコンポーネントを含む。システム１１００は様々な方法で実装することができる。例えば、（サーバ、ワークステーション、パーソナルコンピュータ、ラップトップなどの）統合プラットフォームとしての実装は、ＣＰＵ１１０５、メモリ１１１０、不揮発性ストレージ１１２０、およびＩ／Ｏ機器１１２５を含むことができる。そのような構成では、コンポーネント１１０５、１１１０、１１２０、および１１２５は、ローカルデータバスを介して接続および通信することができ、外部Ｉ／Ｏ接続を介して（例えば、別個のデータソースまたはデータベースシステムとして実装される）データリポジトリ１１３０にアクセスすることができる。Ｉ／Ｏコンポーネント１１２５は、ローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ、例えば、携帯電話ネットワークまたはインターネット）などのネットワークを介して、および／または他の適切な接続を介して、直接通信リンク（例えば、有線またはローカルのＷｉＦｉ（登録商標）接続）を介して外部機器に接続することができる。システム１１００はスタンドアロンでもよいし、またはより大規模なシステムのサブシステムでもよい。

ＣＰＵ１１０５は、カリフォルニア州サンタクララのＩｎｔｅｌ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎによって製造されたＣｏｒｅ（登録商標）ファミリーのマイクロプロセッサ、またはカリフォルニア州サニーベールのＡＭＤ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎによって製造されたＡｔｈｌｏｎ（登録商標）ファミリーのマイクロプロセッサなどの１つ以上の既知のプロセッサまたは処理デバイスとすることができる。メモリ１１１０は、本発明の実施形態に関連する特定の機能、方法、およびプロセスを実行するためにＣＰＵ１１０５によって実行または使用される命令および情報を格納するように構成された１つ以上の高速ストレージデバイスとすることができる。ストレージ１１２０は、揮発性または不揮発性、磁気、半導体、テープ、光学、または他の種類のストレージデバイス、またはＣＤおよびＤＶＤなどのデバイスを含むコンピュータ可読媒体、および長期記憶を意図したソリッドステートデバイスとすることができる。

図示の実施形態では、メモリ１１１０は、ＣＰＵ１１０５によって実行されたときに、本発明に整合する様々な動作、手順、プロセス、または方法を実行する、ストレージ１１２０からまたはリモートシステム（図示せず）からロードされた１つ以上のプログラムまたはアプリケーション１１１５を含む。あるいはまた、ＣＰＵ１１０５は、システム１１００から遠隔に位置する１つ以上のプログラムを実行することができる。例えば、システム１１００は、実行時に本発明の実施形態に関連する機能およびプロセスを実行する、ネットワーク１１３５を介して１つ以上のリモートプログラムにアクセスすることができる。

特定の実施形態では、メモリ１１１０は、登録局１２０、配信機器１０８、証明書管理サービス２８０、４８０、６８０、８８０、ＣＭＳ３８０、５８０、７８０、１０８０、ＱｏＳマネージャ８０１、９０１、および／またはＱｏＳアービター９０４を備えたＣＭＳホストについて本明細書で説明する特殊な機能および動作を実行するためのプログラム１１１５を含むことができる。いくつかの実施形態では、メモリ１１１０は、本発明に補助機能を提供する他の方法およびプロセスを実装する他のプログラムまたはアプリケーションも含むことができる。

メモリ１１１０はまた、本発明とは無関係の他のプログラム（図示せず）および／またはＣＰＵ１１０５によって実行されると当該技術分野で周知のいくつかの機能を実行するオペレーティングシステム（図示せず）で構成することもできる。例として、オペレーティングシステムは、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ（登録商標）、Ａｐｐｌｅ Ｃｏｍｐｕｔｅｒｓ（登録商標）オペレーティングシステム、または他のオペレーティングシステムとすることができる。オペレーティングシステムの選択、さらにはオペレーティングシステムの使用にとっても、本発明にとって重要ではない。

ＨＳＭ１１４０は、デジタルセキュリティ資産を安全に生成および格納し、および／または様々な暗号および機密計算を安全に実行する、それ自身のプロセッサを有する機器とすることができる。ＨＳＭ１１４０は、暗号鍵などのデジタルセキュリティ資産とその他の機密データを可能性のある攻撃者によるアクセスから保護する。いくつかの実施形態では、ＨＳＭは、コンピューティングシステム１１００に直接取り付けられたプラグインカードまたはボードとすることができる。

Ｉ／Ｏ機器１１２５は、システム１１００によってデータを受信および／または送信することを可能にする１つ以上の入出力機器を含むことができる。例えば、Ｉ／Ｏ機器１１２５は、データがユーザから入力されることを可能にする（例えば、キーボード、タッチスクリーン、マウスなどの）１つ以上の入力機器を含むことができる。さらに、Ｉ／Ｏ機器１１２５は、データを出力するまたはユーザに提示することを可能にする（例えば、ディスプレイスクリーン、ＣＲＴモニタ、ＬＣＤモニタ、プラズマディスプレイ、プリンタ、スピーカ機器などの）１つ以上の出力機器を含むことができる。Ｉ／Ｏ機器１１２５はまた、コンピューティングシステム１１００が他のマシンおよび機器と（例えば、デジタルで）通信することを可能にする１つ以上のデジタルおよび／またはアナログ通信入出力機器を含むことができる。他の構成および／またはいくつかの入力機器および／または出力機器をＩ／Ｏ機器１１２５に組み込むことができる。

図示の実施形態では、システム１１００はネットワーク１１３５（例えば、インターネット、プライベートネットワーク、仮想プライベートネットワーク、携帯電話ネットワーク、または他のネットワーク、あるいはこれらの組み合わせ）に接続され、ネットワーク１１３５は次いで、様々なシステムおよびコンピューティングマシン（例えば、サーバ、パーソナルコンピュータ、ラップトップコンピュータ、クライアント機器など）に接続することができる。一般的に、システム１１００は、ネットワーク１１３５を介して外部のマシンおよび機器からデータを入力し、外部のマシンおよび機器にデータを出力することができる。

図１１に示す例示的な実施形態では、リポジトリ１１３０は、システム１１００の外部にあるスタンドアロンデータソース（例えば、データベース）である。他の実施形態では、リポジトリ１１３０は、システム１１００によってホストされ得る。様々な実施形態では、リポジトリ１１３０は、本発明と一致したシステムおよび方法を実装するために使用されるデータを管理および格納することができる。例えば、リポジトリ１１３０は、配信機器１０８などによってプロビジョニングされた証明書を有する各コンピュータ化された機器のステータスおよびログ情報を含むデータ構造を管理および保存することができる。

リポジトリ１１３０は、情報を記憶し、システム１１００を通じてアクセスおよび／または管理される１つ以上のデータベースを含むことができる。例として、リポジトリ１１３０は、Ｏｒａｃｌｅ（登録商標）データベース、Ｓｙｂａｓｅ（登録商標）データベース、または他のリレーショナルデータベースとすることができる。しかしながら、本発明によるシステムおよび方法は、別々のデータ構造またはデータベースに、あるいはデータベースまたはデータ構造の使用にさえ限定されない。

当業者であれば、図１１のシステムのコンポーネントおよび実装の詳細は、説明を簡潔かつ明確にするために提示された例であることを理解するであろう。他のコンポーネントおよび実装の詳細が使用されてもよい。

前述の例は、説明を明確にするために、ＯＢＵ、ＥＣＵ、およびＲＳＵなどのコンピュータ化された機器の特定の例を使用しているが、本発明はそれらの特定の例に限定されない。本発明に整合する様々な実施形態は、とりわけ、医療機器（例えば、透析機、注入ポンプなど）、ロボット、ドローン、自律走行車、無線通信モジュール（例えば、埋め込み型ユニバーサル集積回路カード（ｅＵＩＣＣ））などの多種多様なコンピュータ化された機器と共に、およびそれらのために使用することができる。

本明細書で説明されるアプリケーションの様々な動作は、少なくとも部分的に、１つ以上のＶＭによって実行され得る。追加または代替の実施形態では、本明細書で説明されるアプリケーションの動作は、関連する動作を実行するように（例えば、ソフトウェアによって）一時的に構成されるまたは恒久的に構成される１つ以上のプロセッサによって少なくとも部分的に実行され得る。一時的または永続的に構成されているかどうかにかかわらず、そのようなプロセッサは、本明細書で説明される１つ以上のアプリケーションの動作、機能、および役割を実行するように動作するプロセッサ実装モジュールを構成し得る。本明細書で使用されるとき、「プロセッサ実装モジュール」という用語は、１つ以上のプロセッサを使用して実装されるハードウェアモジュールを指す。

同様に、本明細書で説明される方法は、ハードウェアの一例である特定の１つまたは複数のプロセッサで、少なくとも部分的にプロセッサ実装することができる。例えば、方法の動作の少なくともいくつかは、１つ以上のプロセッサまたはプロセッサ実装モジュールによって実行され得る。さらに、１つ以上のプロセッサはまた、「クラウドコンピューティング」環境における、または「サービスとしてのソフトウェア」（ＳａａＳ：ｓｏｆｔｗａｒｅ ａｓ ａ ｓｅｒｖｉｃｅ）としての関連動作のパフォーマンスをサポートするように動作し得る。例えば、動作の少なくとも一部は、（プロセッサを含むマシンの例として）コンピュータのグループによって実行され、これらの動作はネットワーク（例えば、インターネット）および１つ以上の適切なインターフェイス（例えば、ＡＰＩ）を介してアクセスできる。

特定の動作のパフォーマンスは、単一のマシン内にあるだけでなく、多数のマシンに展開されるプロセッサ間で分散され得る。いくつかの例示的な実施形態では、プロセッサまたはプロセッサ実装モジュールは、単一の地理的位置（例えば、オフィス環境、製造環境、またはサーバファーム内）に配置され得る。他の例示的な実施形態では、プロセッサまたはプロセッサ実装モジュールは、いくつかの地理的位置にわたって分散され得る。

本発明の他の実施形態は、本明細書の考察および本明細書に開示された本発明の実施から当業者には明らかであろう。明細書および実施例は例示としてのみ考慮されることを意図しており、本発明の真の範囲は以下の特許請求の範囲によって示される。

Claims (20)

1. 証明書管理サービスから証明書をリクエストするクライアントにサービスの品質（ＱｏＳ）レベルを提供するシステムであって、前記システムは、
   複数のクライアントから証明書リクエストを受信するように動作可能なパブリックアプリケーションプログラミングインターフェイス（ＡＰＩ）であって、各々の証明書リクエストは、
   証明書を必要とする多数のコンピュータ化された機器と、
   前記証明書リクエストがいつ送信されたかを示すタイムスタンプと、
   前記証明書をリクエストするクライアントとを示すパブリックアプリケーションプログラミングインターフェイス（ＡＰＩ）と、
   ＱｏＳマネージャであって、
   前記複数のクライアントからの前記証明書リクエストを複数の仲介クライアントキューにわたって分散し、前記複数のクライアントキューの各々は、証明書をリクエストする特定のクライアントに対応するように、そして、
   クライアントキュー内のクライアントの証明書リクエストを１つ以上のエントリのサブグループに分割し、前記１つ以上のエントリの各々は、証明書を必要とするコンピュータ化された機器の数のサブセットに対応するグループサイズを有するように動作可能なＱｏＳマネージャと、
   ＱｏＳキュー内のエントリの数、前記証明書管理サービスの待機時間レベル、および前記証明書リクエストがいつ送信されたかを示すそれぞれのタイムスタンプに少なくとも部分的に基づいて、前記ＱｏＳキューに配置される前記複数のクライアントキューからエントリの順序を選択するように動作可能なＱｏＳアービターとを含み、
   前記ＱｏＳマネージャは、前記ＱｏＳアービターによって選択された順序で前記ＱｏＳキューからエントリを取得し、前記証明書管理サービスの内部登録局ＡＰＩを介して、前記取得されたエントリを前記証明書管理サービスに送信するように動作可能なシステム。
2. 前記グループサイズは、デフォルト値が１の調整可能な数値である、請求項１に記載のシステム。
3. 証明書を必要とする前記コンピュータ化された機器は、オンボードユニット（ＯＢＵ）、電子制御ユニット（ＥＣＵ）、およびロードサイドユニット（ＲＳＵ）のうちの１つ以上に対応する、請求項１に記載のシステム。
4. ＯＢＵは、車両、船舶、航空機、宇宙船、医療機器、ロボット、ドローン、無線通信モジュール、有線通信モジュール、およびモノのインターネット（ＩｏＴ）機器のうちの１つ以上に設置されるように動作可能であり、
   ＥＣＵは、車両、ボート、航空機、宇宙船、医療機器、ロボット、ドローン、無線通信モジュール、有線通信モジュール、およびＩｏＴ機器のうちの１つ以上に設置されるように動作可能であり、
   ＲＳＵは、交通制御機器、無線通信モジュール、デジタル広告板、および電子看板のうちの１つ以上に設置されるように動作可能である、請求項３に記載のシステム。
5. 前記複数のクライアントは、前記証明書管理サービスと証明書を必要とする少なくとも１つのコンピュータ化された機器との間のプロキシとして機能するように動作可能な少なくとも１つの配信機器またはサーバを含む、請求項１に記載のシステム。
6. 各々の証明書リクエストは、前記リクエストを送信するクライアントのクライアント優先度レベルをさらに示し、前記ＱｏＳアービターは、証明書リクエストに示されたそれぞれのクライアント優先度レベルに少なくとも部分的に基づいて前記ＱｏＳキューに配置された前記複数のクライアントキューからエントリの順序を選択するようにさらに動作可能である、請求項１に記載のシステム。
7. クライアントのクライアント優先度レベルは、前記クライアントに関連付けられたサービス層に基づいており、サービス層は、最低のサービスレベルから最高のサービスレベルまでの範囲の複数の層のうちの１つに対応する、請求項６に記載のシステム。
8. 前記ＱｏＳアービターは、追加のクライアントから受信した追加の証明書リクエスト内で示されるそれぞれのクライアント優先度レベルに少なくとも部分的に基づいて、前記ＱｏＳキューに配置された前記エントリの順序を動的に並べ替えるようにさらに動作可能である、請求項６に記載のシステム。
9. 各々の証明書リクエストは、前記リクエストに関連するリクエスト緊急度レベルをさらに示し、前記ＱｏＳアービターは、証明書リクエスト内で示されるそれぞれのリクエスト緊急度レベルに少なくとも部分的に基づいて、前記ＱｏＳキューに配置された前記複数のクライアントキューから前記エントリの順序を選択するように動作可能である、請求項１に記載のシステム。
10. 証明書リクエストのリクエスト緊急度レベルは、前記証明書リクエストを提出するクライアントによって指定され、リクエスト緊急度レベルは、最低緊急度オプションから最高緊急度オプションまでの範囲の複数のレベルのうちの１つに対応する、請求項９に記載のシステム。
11. 前記ＱｏＳアービターは、ラウンドロビン技術を使用して、前記ＱｏＳキューに配置される前記複数のクライアントキューからの前記エントリの順序を選択するように動作可能である、請求項１に記載のシステム。
12. 前記ＱｏＳアービターは、前記クライアントキューの各々に割り当てられた動的優先度に基づいて、前記ＱｏＳキューに配置される前記複数のクライアントキューから前記エントリの順序を選択するように動作可能であり、前記クライアントキューに割り当てられたそれぞれの前記動的優先度は、前記クライアントキューの各々のエントリ数に少なくとも部分的に基づいて前記ＱｏＳアービターによって割り当てられる、請求項１に記載のシステム。
13. 前記複数のクライアントからの前記証明書リクエストは、登録証明書のリクエストを含み、前記パブリックＡＰＩは、前記証明書管理サービスに代わって、通信ネットワークを介して、前記複数のクライアントに、前記証明書管理サービスの登録認証局によって生成された登録証明書を送信するようにさらに動作可能である、請求項１に記載のシステム。
14. 前記証明書リクエストには、偽名証明書のリクエストがさらに含まれ、
    前記パブリックＡＰＩは、前記証明書管理サービスに代わって、通信ネットワークを介して、前記証明書管理サービスの偽名認証局によって生成された偽名証明書を前記複数のクライアントに送信するようにさらに動作可能であり、
    前記複数のクライアントは、前記証明書管理サービスと証明書を必要とする少なくとも１つのコンピュータ化された機器との間のプロキシとして機能するように動作可能な少なくとも１つの配信機器を含み、
    前記少なくとも１つのコンピュータ化された機器は、前記配信機器から証明書を取得するように動作可能である、請求項１３に記載のシステム。
15. 登録証明書は、複数のコンピュータ化された機器を含むエコシステムの認可された参加者として公開鍵証明書の所有者を識別する公開鍵証明書であり、前記エコシステムの各々の認可された参加者は前記複数のコンピュータ化された機器との通信を可能にする１つ以上の偽名証明書を受け取ることができる、請求項１４に記載のシステム。
16. 前記ＱｏＳアービターは、追加のクライアントから受信した追加の証明書リクエストに少なくとも部分的に基づいて、前記ＱｏＳキューに配置される前記エントリの順序を動的に再配列するようにさらに動作可能である、請求項１に記載のシステム。
17. 証明書管理サービスから証明書をリクエストするクライアントにサービス品質（ＱｏＳ）レベルを提供するためのコンピュータ実装方法であって、前記コンピュータ実装方法は、
    パブリックアプリケーションプログラミングインターフェイス（ＡＰＩ）を介して、複数のクライアントから証明書リクエストを受信することであって、各々の証明書リクエストは、
    証明書を必要とする多数のコンピュータ化された機器と、
    前記証明書リクエストがいつ送信されたかを示すタイムスタンプと、
    前記証明書をリクエストするクライアントとを示す、受信することと、
    ＱｏＳマネージャによって、前記複数のクライアントからの前記証明書リクエストを複数の仲介クライアントキューに分配することであって、前記複数のクライアントキューの各々は、証明書をリクエストする特定のクライアントに対応する分配することと、
    前記ＱｏＳマネージャによって、クライアントのリクエストを１つ以上のエントリのサブグループに分割することであって、前記１つ以上のエントリの各々は、証明書を必要とするコンピュータ化された機器の数のサブセットに対応する分割することと、
    ＱｏＳキュー内のエントリの数、前記証明書管理サービスの待機時間レベル、および前記証明書リクエストがいつ送信されたかを示すそれぞれのタイムスタンプに少なくとも部分的に基づいて、前記ＱｏＳキューに配置される前記複数のクライアントキューからエントリの順序をＱｏＳアービターによって選択することと、
    前記ＱｏＳアービターによって選択された前記順序で前記ＱｏＳキューからエントリを前記ＱｏＳマネージャによって取得し、前記証明書管理サービスの内部登録局ＡＰＩを介して、前記取得されたエントリを前記証明書管理サービスに送信することとを含むコンピュータ実装方法。
18. 前記ＱｏＳキューに配置される前記複数のクライアントキューからの前記エントリの順序を選択することは、ラウンドロビン技術を使用することを含む、請求項１７に記載のコンピュータ実装方法。
19. 前記ＱｏＳキューに配置される前記複数のクライアントキューからの前記エントリの順序を選択することは、前記クライアントキューの各々に割り当てられた動的優先度に基づいており、前記クライアントキューの各々に割り当てられたそれぞれの前記動的優先度は、前記クライアントキューの各々のエントリ数に少なくとも部分的に基づいて前記ＱｏＳアービターによって割り当てられる、請求項１７に記載のコンピュータ実装方法。
20. 前記複数のクライアントは、前記証明書管理サービスと証明書を必要とする少なくとも１つのコンピュータ化された機器との間でプロキシとして機能するように動作可能な少なくとも１つの配信機器またはサーバを含む、請求項１７に記載のコンピュータ実装方法。

Images