JP2013541099A - サービスとして信用できるデバイスクレーム - Google Patents

Abstract

本発明の実施形態は、デバイスクレームがそれに対して発行されたクライアントデバイスが、ネットワークアプリケーションにアクセスしようとする試みに関してデバイスクレームを使用できるように、サービスとしてクライアントデバイスが利用可能な信用できるデバイスクレームを発行する。サービスは、デバイスの特性および／または状態の評価を行い、この評価の結果をデバイスクレーム内で示し、デバイスクレームをデバイスに発行することができる。サービスは、ネットワークアプリケーションをアクセス可能にするエンティティの管理境界の外部から、クライアントデバイスによってアクセス可能とすることができ、したがって、公共的にアクセス可能なインターネットなどを介して、企業対消費者（Ｂ２Ｃ）および企業対企業（Ｂ２Ｂ）トポロジにおいて、ネットワークアプリケーションをアクセス可能にするエンティティに有益となる。

Description

本発明は、サービスとして信用できるデバイスクレームに関する。

多くの組織は、任意のデバイスを使用して任意の場所からいつでもアプリケーションに透過的にアクセスする機能をユーザに提供しようとしている。ユーザにこのレベルのアクセスを提供することは、セキュリティに関連する障害を含めて、多くの障害を克服することを必要とする。例えば、組織は、各ユーザの役割および／または組織との関係に応じて、アプリケーションおよび／またはデータへの様々なレベルのユーザアクセスを提供しようとすることがある。

米国特許出願第１２／８２２７２４号明細書 米国特許出願第ＸＸ号明細書 米国特許出願第１２／８２２７４５号明細書

本発明の譲受人に譲渡された、２０１０年６月２４日に出願された、「Network Layer Claims Based Access Control」と題する特許文献１は、（当業者には「アサーション（ａｓｓｅｒｔｉｏｎ）」としても知られている）「クレーム（ｃｌａｉｍ）」内で提供される情報を使用することによって、ＯＳＩスタックのネットワーク層においてアクセス制御決定を行うことに関する柔軟性を提供する技法を開示している。簡単に言えば、クレームは、リソースへのアクセスを要求するコンピュータについての数々の属性、要求されたアクセスを取り巻く状況、それへのアクセスが要求されるリソースのいずれかに関する情報、および／または他の情報を含むことができる。開示された技法によれば、クレーム内で提供される情報は、１つまたは複数のアクセス制御ポリシーに照らして評価することができ、特定のネットワークリソースへのアクセスを許可するか、それとも拒否するかを決定する際に使用することができる。クレーム内で提供される情報は、ネットワーク層においてアクセス制御決定を行うためにそれまで使用されていた情報よりも詳細であることができるので、ポリシーをより柔軟に策定することができ、また様々な性質またはタイプの情報を考慮したものにすることができる。

本発明の譲受人に譲渡された、本出願と同時に出願された、「Trustworthy Device Claims for Enterprise Applications」と題する特許文献２は、アプリケーションへのアクセスを要求するデバイスの特性および／または状態を記述する情報をクレームの形態でアプリケーションに提供できる技法を開示している。デバイスの特性および／または状態を記述するこれらのクレームは、これ以降、「デバイスクレーム（ｄｅｖｉｃｅ ｃｌａｉｍ）」と呼ばれる。デバイスクレームが提供されるアプリケーションは、セキュリティおよび非セキュリティ関連の機能を含む数々のタイプの機能のいずれかを駆動するために、デバイスクレーム内の情報を利用することができる。例えば、デバイスクレームは、アプリケーションによって使用されて、アクセス制御決定を駆動すること、ある機能またはデータを利用可能にする前に、説明されたデバイスが一定の基準を満たすことを検証すること、デバイスの特性に適した出力を生成することなどを可能にする。開示された技法によれば、デバイスは、リモート認証プロセスを受け、それを介して、デバイスクレームが生成され、その後、アプリケーションがそれを消費するように構成された形態に変換される、その後、デバイスクレームは、デバイスによって、アプリケーションへのアクセスを求める要求内に含めることができる。リモート認証プロセスを介して生成された結果として、デバイスクレームは、デバイスの特性および／または状態についての正確で真正な表現として、アプリケーションによって受け入れられる。

本発明の実施形態は、デバイスがサービスとして利用可能な信用できるデバイスクレームを発行する。この点について、アプリケーションを（例えば公共的にアクセス可能なインターネットを介して）ネットワーク上で利用可能にするエンティティは、場合によっては、デバイスクレームが提供できる情報（例えば、アクセスを要求するデバイスの特性および／または状態についての独立の評価）に価値を見出すことができるが、アプリケーションにアクセスしようとするデバイスへのデバイスクレームの発行に関連する管理的および費用的なオーバヘッドを負うことを望まないことがあると出願人は認識した。したがって、本発明のいくつかの実施形態は、デバイスがデバイスクレームをそこから獲得できるサービスを提供し、デバイスクレームは、その後、ネットワークアプリケーションにアクセスしようとする試みに関して使用することができる。サービスは、デバイスの特性および／または状態についての独立した評価を行い（例えば、実行および／または監視し）、この評価の結果をデバイスクレーム内で示し、後でアプリケーションにアクセスしようと試みる際に使用するためにデバイスクレームをデバイスに提供することができる。いくつかの実施形態では、サービスは、ネットワークアプリケーションを利用可能にするエンティティの管理境界の外部から、デバイスによってアクセス可能とすることができる。そのため、本発明の実施形態は、企業対消費者（Ｂ ｔｏ Ｃ）および企業対企業（Ｂ ｔｏ Ｂ）トポロジにおいて、ネットワークアプリケーションをデバイスからアクセス可能にする関係者に有益なことがある。

上述の説明は、本発明の実施形態についての非限定的な要約であり、本発明は、添付の特許請求の範囲によって確定される。

添付の図面は、原寸に比例して描こうとは意図されていない。図面では、様々な図に示される同一またはほぼ同一の各構成要素は、同様の番号によって表される。明瞭になるように、どの図面においても、必ずしもすべての構成要素にラベルが付けられているわけではない。
本発明のいくつかの実施形態による、信用できるデバイスクレームをクライアントデバイスに発行できるシステムを示すブロック図である。 本発明のいくつかの実施形態による、信用できるデバイス状態トークンサービス（ｄｅｖｉｃｅ ｓｔａｔｅ ｔｏｋｅｎ ｓｅｒｖｉｃｅ）のリストをクライアントデバイスがネットワークアプリケーションから受信し、信用できるＤＳＴＳを選択する、例示的なプロセスを示すフローチャートである。 本発明のいくつかの実施形態による、クライアントデバイスによって提出されたデバイスクレームをネットワークアプリケーションが評価する、例示的なプロセスを示すフローチャートである。 本発明の実施形態を実施できる例示的なコンピュータシステムを示すブロック図である。 本発明の態様を具現する命令を記憶できる例示的なメモリを示すブロック図である。

本発明のいくつかの実施形態によれば、ネットワークアプリケーションにアクセスしようとする試みに関して使用するためにデバイスがそこからデバイスクレームを獲得できるサービスが提供される。いくつかの実施形態では、ネットワークアプリケーションにアクセスしようとするデバイスの試みに応答して、デバイスの特性および／または状態についての独立した評価を行い、デバイスの特性および／または状態についての正確で真正な表現をデバイスクレームの形態で発行することについて、ネットワークアプリケーションおよび／またはデバイスから信用を得た１つまたは複数のデバイス状態トークンサービス（ＤＳＴＳ）の表示をデバイスに提供することができる。ＤＳＴＳによってデバイスに発行された後、デバイスクレームは、ネットワークアプリケーションにアクセスしようとする試みに関してデバイスによって使用することができ、またセキュリティおよび非セキュリティ関連の機能を駆動するためにネットワークアプリケーションによって使用することができる。

信用できるデバイスクレームをデバイスに発行するためのコンポーネントを備える例示的なシステムと、これらのコンポーネントがそれによって対話できる例示的な手順が、図１に示されている。示される例では、（デスクトップもしくはラップトップコンピュータ、モバイル電話、携帯情報端末、コンテンツ再生デバイス、テレビ、ゲームコンソール、および／または他の適切なデバイスタイプなど、任意の適切なコンピューティングデバイスとすることができる）クライアントデバイス１１０は、（図１には図示されていない）１つまたは複数のネットワークを介して、（いずれか１つまたは複数のアプリケーションコンポーネントを含むことができる）ネットワークアプリケーション１２０と通信する。１つまたは複数のネットワークは、いずれか１つまたは複数の適切な通信プロトコルに従った通信を実施することができ、いずれか適切な通信インフラストラクチャを備えることができる。１つまたは複数のネットワークは、例えば、公共的にアクセス可能なインターネットを含むことができる。

図１に示される例示的な手順は、矢印１５２によって示されるように、ネットワークアプリケーション１２０にアクセスしようとするクライアントデバイス１１０による試みで開始する。ネットワークアプリケーション１２０は、数々の方法のいずれかで、このアクセスの試みに応答することができる。図１に示される例では、ネットワークアプリケーション１２０は、矢印１５４によって示されるように、信用できるデバイスクレームを発行することについてネットワークアプリケーション１２０が信用する１つまたは複数のＤＳＴＳの表示（例えばリスト）をクライアントデバイス１１０に提供することによって応答する。その後、クライアントデバイス１１０は、評価を行うことについてクライアントデバイス１１０もやはり信用するＤＳＴＳを選択することができる。クライアントデバイスが、デバイスクレームを発行することについて信用を得た１つまたは複数のＤＳＴＳの表示をネットワークアプリケーションから受信し、デバイスクレームがそれに対して要求されるＤＳＴＳを選択する、例示的なプロセス２００が、図２に示されている。

プロセス２００が開始すると、クライアントデバイス１１０は、行為２１０において、クライアントデバイスの特性および／または状態についての独立した評価を実行することについて、またそれを示すデバイスクレームを発行することについて、ネットワークアプリケーション１２０から信用を得た１つまたは複数のＤＳＴＳの表示を受信する。図１に示される例では、ネットワークアプリケーション１２０は、（矢印１２２によって示されるように）ＤＳＴＳ１３０と信用関係を有するが、ＤＳＴＳ１４０とは有さない。

その後、プロセス２００は行為２２０に進み、クライアントデバイス１１０は、デバイスクレームがそれに対して要求されるＤＳＴＳを選択する。例えば、クライアントデバイス１１０は、ネットワークアプリケーション１２０によって提供されたリストから、クライアントデバイス１１０もやはり信用するＤＳＴＳを選択することができる。デバイスクレームを発行するプロセスにおいてＤＳＴＳによって実行されるいくつかの評価の侵入的性質を考えると、信用できることが好ましいことがある。ＤＳＴＳは、既存の信用関係のため、ＤＳＴＳが１つもしくは複数の基準を満たすため、または他の任意の理由で、クライアントデバイス１１０から信用を得ることができる。図１に示される例では、クライアントデバイス１１０は、（矢印１１５によって示されるように）ＤＳＴＳ１３０と、また（矢印１１８によって示されるように）ＤＳＴＳ１４０と既存の信用関係を有する。（図１にはただ２つのＤＳＴＳしか示されていないが、任意の適切な数のＤＳＴＳを提供できることを理解されたい）。行為２１０において受信した表示にＤＳＴＳ１３０が含まれると仮定すると、この例では、クライアントデバイス１１０は、デバイスクレームがそれに対して要求されるＤＳＴＳとして、ＤＳＴＳ１３０を選択する。

その後、プロセス２００は行為２３０に進み、クライアントデバイス１１０は、選択されたＤＳＴＳ１３０を認証する。ＤＳＴＳ１３０の認証は、例えば、悪意をもった行為者が、ＤＳＴＳ１３０を装って、クライアントデバイス１１０上の情報および／または機能に自由にアクセスすることを防止することができる。いくつかの実施形態では、クライアントデバイス１１０は、この目的でＤＳＴＳ１３０によって発行されたＸ．５０９証明書を評価することによって、または他の任意の適切な認証手段を使用して、ＤＳＴＳ１３０を認証することができる。その後、プロセス２００は行為２４０に進み、クライアントデバイス１１０は、デバイスクレームを要求し、その後、プロセス２００は終了する。

図２のプロセスは、デバイスクレームがそれに対して要求されるＤＳＴＳをクライアントデバイスが識別できる、１つの例示的な手順にすぎないことを理解されたい。例えば、行為２１０においてクライアントデバイス１１０に提供される表示は、ネットワークアプリケーション１２０から信用を得たＤＳＴＳだけを含む必要はなく、ネットワークアプリケーション１２０とクライアントデバイス１１０の両方から信用を得たＤＳＴＳを含むことができる。本発明の実施形態は、クライアントデバイスがＤＳＴＳを選択する実施にまったく限定されないことも理解されたい。例えば、（図１の矢印１５２によって示されるように）クライアントデバイス１１０からアクセス要求を受信すると、ネットワークアプリケーション１２０は、正確なデバイスクレームを発行することについてネットワークアプリケーション１２０が信用するＤＳＴＳに、クライアントデバイス１１０を単純にリダイレクトすることができる。本発明の実施形態は、数々の方法のいずれかで実施することができる。

図２に示される例示的なプロセスは、デバイスクレームがそれに対して要求される適切なＤＳＴＳを識別できない場合の（例えばクライアントデバイス１１０によって実行される）行為を含むように補足できることも理解されたい。適切なＤＳＴＳを識別できない場合、数々の動作のいずれかを実行することができる。例えば、クライアントデバイス１１０は、適切なＤＳＴＳの発見に関する情報をユーザに提示することができ、クライアントデバイス１１０は、適切なＤＳＴＳの発見に関する情報を獲得するために、ネットワークアプリケーション１２０に問い合わせることができ、および／または１つもしくは複数の他の動作が実行されてもよい。本発明の実施形態は、いずれか特定の実施に限定されない。

図２の例示的なプロセスが完了すると（すなわち、クライアントデバイス１１０がデバイスクレームを要求した後）、ＤＳＴＳ１３０（図１）は、クライアントデバイス１１０にデバイス状態ポリシーおよびスクリプトを提供することによって、デバイスクレームを求める要求に応答する。いくつかの実施形態では、ＤＳＴＳ１３０から獲得された情報は、クライアントデバイス１１０へのデバイスクレームの発行をサポートする情報を収集するように、クライアントデバイス１１０に命令することができる。

ＤＳＴＳ１３０によってクライアントデバイス１１０に提供されるスクリプトは、クライアントデバイス１１０によって実行された場合、クライアントデバイス１１０が上述の情報の一部または全部を収集する支援をすることができる。デバイスクレームの発行をサポートする、クライアントデバイスに関する情報が収集される例示的な技法は、本発明の譲受人に譲渡された、２０１０年９月３０日に出願された、「Trustworthy Device Claims for Enterprise Applications」と題する特許文献２において説明されており、特許文献２のいくつかの部分は、本明細書において援用される。特許文献３において開示された実施形態では、クライアントデバイス１１０上の（図１には図示されていない）データ収集コンポーネントが、ＤＳＴＳ１３０によって特定された情報を収集するために、１つまたは複数のデータ源と通信する。例えば、データ収集コンポーネントは、データ源に情報を提供し、各データ源からデバイス特性および／または状態を示す情報を受信することができる。例えば、データ収集コンポーネントは、デバイスのライフサイクル中に、（例えば、オペレーティングシステムのリブート、ハイバネーション／スリープからの再開、ソフトウェアパッチの１つもしくは複数のドライバのインストール、ネットワーク接続の開始、ロケーション変更、および／または他のイベントなど）数々のイベントのいずれかが発生した時点または発生した後に、クライアントデバイスの状態に関するコンテキスト情報を、データ源に提供することができる。それに応えて、データ源は、（例えば、セキュリティおよび／もしくはアンチウイルスソフトウェアが備えられているかどうか、ある（例えばセキュリティ）ソフトウェアが作動しているかどうか、クライアントデバイスがファイアウォールを利用しているかどうか、ファイアウォールが機能しているかどうか、アンチウイルスシグネチャが最新かどうかなど）クライアントデバイス１１０の「健全性」、（例えば、署名および／もしくは暗号化通信が使用されるかどうか、暗号化のタイプなど）アプリケーションにアクセスするためにクライアントデバイス１１０が使用する暗号法のタイプ、クライアントデバイス１１０のための識別子、（例えば、デスクトップコンピュータ、データベースサーバ、ウェブサーバなど）クライアントデバイス１１０が実行する役割、（例えば、会社、従業員、販売業者など）クライアントデバイス１１０のオーナ、クライアントデバイス１１０の地理的ロケーションについての情報、および／または他の数々のタイプの情報のいずれかを提供することができる。提供される情報は、その正確さを保証するために、データ源によって「署名」することができる。

上述のデータ源に加えて、クライアントデバイス１１０は、ローカルで実施されるＴＰＭ（トラステッドプラットフォームモジュール）コンポーネント（図１には図示されず）からも情報を受け取ることができる。ＴＰＭは、ＴＰＭのＰＣＲ（プラットフォーム構成レジスタ）内にイベントのログを記録すること、暗号鍵を生成し、保存し、使用できるようにすること、「ＴＣＧログ」と呼ばれるデータ構造上に、そのログでリモートパーティに報告されるイベントの信用性を証明するために、「クォート（ｑｕｏｔｅ）」を生成できるようにすること、連続するブートサイクルを区別し、ハイバネート／リスタートイベントにわたる追加のセキュリティ手段を提供するのに使用できる「ブートカウンタ」を維持することを含む、デバイスクレームの生成に関する多くの機能のいずれか、および／または他の機能を実行することができる。

その後、収集された情報は、矢印１５８によって示されるように、ＤＳＴＳ１３０に提供される。その後、ＤＳＴＳ１３０は、デバイスクレームを発行すべきかどうかを判定するために、クライアントデバイス１１０によって提供された情報を予備的に評価することができる。例えば、ＤＳＴＳ１３０は、ＴＰＭ測定が生成後に変更されていないことを確認するためにＴＰＭ測定を確認し、クライアントデバイス１１０がマルウェアに侵されていないかどうかを判定し、および／または他の予備的な評価を実行することができる。クレーム生成を開始すべきであるという予備的な判定が下された場合、ＤＳＴＳ１３０は、生成すべき特定のデバイスクレームを決定するために、クライアントデバイス１１０から受信した情報をさらに評価することができる。この決定は、少なくとも部分的に、受信した情報に基づいて、生成すべきデバイスクレームを管理するＤＳＴＳ１３０によって実施されるポリシーによって推進することができる。生成されたデバイスクレームは、ＤＳＴＳ１３０によって署名され、その後、矢印１６０によって示されるように、クライアントデバイス１１０に送信される。デバイスクレームは、任意の適切な配送手段を使用して、クライアントデバイス１１０に送信することができる。例えば、いくつかの実施形態は、クライアントデバイス１１０に送信されるＳＡＭＬ（セキュリティアサーションマークアップ言語）トークン内にデバイスクレームを含めることが可能である。しかし、デバイスクレームのための任意の適切な手段を利用することができる。

いくつかの実施形態では、クライアントデバイス１１０に送信される情報は、デバイスクレームをクライアントデバイスに結び付けるために、クライアントデバイスの識別情報の表示を含む。この結び付けは、悪意をもった行為者が、デバイスクレームを不正流用し、クライアントデバイス１１０を装って、ネットワークアプリケーション１２０にアクセスすることを防止することができる。結び付けは、ＤＳＴＳ１３０によるＸ．５０９証明書の発行を介してなど、任意の適切な技法を使用して達成することができる。

デバイスクレームを受信すると、クライアントデバイス１１０は、矢印１６２によって示されるように、ネットワークアプリケーション１２０にアクセスしようと試みる。例えば、クライアントデバイス１１０上で動作している（図１には図示されていない）ブラウザアプリケーションは、ネットワークアプリケーション１２０へのアクセスを求める要求内にデバイスクレームを含めることができる。もちろん、クライアントデバイス１１０は、ネットワークアプリケーション１２０にアクセスするためにブラウザアプリケーションを利用するようには限定されず、ネットワークアプリケーション１２０にアクセスしようと試みるために、任意の適切な技法および／またはコンポーネントを使用することができる。

その後、ネットワークアプリケーション１２０は、クライアントデバイス１１０から受信したデバイスクレームを評価することができる。評価を実行することができる例示的なプロセス３００が、図３に示されている。

プロセス３００が開始すると、行為３１０において、ネットワークアプリケーション１２０が、デバイスクレームを受信する。行為３２０において、ネットワークアプリケーション１２０は、デバイスクレームがそれに対して発行されたデバイスによってデバイスクレームが提供されたかどうかを判定する。このステップは、悪意をもった行為者が、ネットワークアプリケーションにアクセスしようと試みる際に、特定のデバイスを装うことを防止するために実行することができる。デバイスクレームがそれに対して発行されたデバイスによってデバイスクレームが提供されたことの検証は、数々の方法のいずれかで実行することができる。いくつかの実施形態では、ネットワークアプリケーションは、上述したように、デバイスクレームをクライアントデバイスに結び付けるためにＤＳＴＳ１３０によって発行されたＸ．５０９証明書を検査することによって、デバイスクレームを確認することができる。

ネットワークアプリケーション１２０が、デバイスクレームがそれに対して発行されたデバイスによってデバイスクレームが提供されたことを検証できない場合、プロセス３００は、行為３６０に進み、ネットワークアプリケーションは、アクセスが許可されないことをクライアントデバイスに通知する。その後、プロセス３００は終了する。

反対に、ネットワークアプリケーション１２０が、デバイスクレームがそれに対して発行されたデバイスによってデバイスクレームが提供されたことを検証した場合、プロセス３００は、行為３３０に進み、ネットワークアプリケーション１２０は、デバイスクレームが期限切れになっていないかどうかを判定する。この点について、クライアントデバイスは、ネットワークアプリケーションにアクセスしようとする複数の試みに関連して、所定の１組のデバイスクレームを利用することができ、いくつかの実施形態では、デバイスクレームは、規定された有効期限（例えば、発行後に経過した一定の時間数、および／または他の何らかの条件に基づく有効期限）を有することができる。例えば、デバイスクレームは、本質的にコンテキスト依存とすることができるので（例えば、デバイスクレームは、デバイスの状態、デバイスの物理的ロケーション、クライアントデバイスにあるソフトウェアパッチがインストールされているかどうかなどに関連することができるので）、その正確さは、発行後、ある程度の時間が経過すると、疑わしくなることがある。

ネットワークアプリケーション１２０が、デバイスクレーム（またはその一部）は期限切れであると判定した場合、プロセス３００は、行為３６０に進み、ネットワークアプリケーションは、アクセスが許可されないことをクライアントデバイスに通知する。ネットワークアプリケーション１２０は、例えば、新しいデバイスクレームを獲得すべきであることをクライアントデバイス１１０に通知することができる。その後、プロセス３００は終了する。

ネットワークアプリケーション１２０が、デバイスクレームは期限切れではないと判定した場合、プロセス３００は、行為３４０に進み、デバイスクレーム、またはデバイスクレームとの結び付きが確立されているクライアント識別情報が無効化されていないかどうかについて判定が行われる。この点について、デバイスクレームは、ＤＳＴＳによって無効化することができ、したがって、期限切れになる前に、数々の理由のいずれかのために、無効になることがある。例えば、ＤＳＴＳによって実施されるポリシーの変更、クライアントデバイスの状態および／もしくは特性の変化、または他の任意の理由が原因で、ＤＳＴＳは、デバイスクレームを無効化することがある。（例えば、デバイスクレームと一緒に発行される証明書を介して規定される）クライアントの識別情報も、無効化することができ、その識別情報に対して発行されたデバイスクレームは、いずれも無効にされる。

クライアントデバイスの識別情報および／またはデバイスクレームが無効化されたかどうかの判定は、数々の方法のいずれかで実行することができる。一例では、ネットワークアプリケーションは、ＯＣＳＰ（オンライン証明書状態プロトコル）、または他の任意の適切なプロトコルもしくは技法を使用して、クライアントデバイスの識別情報および／またはデバイスクレームが無効化されていないことを検証するために、クライアントデバイスにデバイスクレームを発行したＤＳＴＳ（図１に示される例ではＤＳＴＳ１３０）に問い合わせることができる。

行為３４０において、ネットワークアプリケーション１２０が、デバイスクレーム、またはデバイスクレームとの結び付きが確立されているクライアント識別情報は無効化されていると判定した場合、プロセス３００は、行為３６０に進み、ネットワークアプリケーションは、アクセスが許可されないことを、クライアントデバイスに通知する。いくつかの実施形態では、ネットワークアプリケーションは、新しい１組のデバイスクレームを獲得すべきであることをクライアントデバイスに教えることができる。その後、プロセス３００は終了する。

行為３４０において、ネットワークアプリケーション１２０が、デバイスクレームおよびクライアント識別情報は無効化されていないと判定した場合、プロセス３００は、行為３５０に進み、アクセスを許可するのに十分な根拠をデバイスクレームが提供したかどうかについて判定が行われる。この判定は、数々の要因のいずれかに基づくことができる。例えば、ネットワークアプリケーション１２０は、デバイスクレーム内の情報が１つまたは複数の所定の基準を満たさないために、デバイスクレームは不十分であると判定することができる。例えば、ある特定のクレームがない（例えば、アンチウイルスソフトウェアがインストールされていないこと、マルウェアがクライアントデバイス１１０上で動作していることなどを示している）ことがあり、１つまたは複数のクレーム値が不満足である（例えば、あるセキュリティパッチがないこと、および／もしくはＢｉｔＬｏｃｋｅｒなど、ある特定のセキュリティ手段がクライアントデバイス１１０上で作動していないことを示している）ことがあり、ならびに／または所定の基準が他の理由で満たされていない。ネットワークアプリケーション１２０は、アクセスを許可するのに十分な根拠をデバイスクレームが提供したかどうかを判定するために、デバイスクレーム内で提供された情報を数々の方法のいずれかで評価することができる。

アクセスを許可するのに十分な根拠をデバイスクレームが提供していない場合、プロセス３００は、行為３６０に進み、ネットワークアプリケーション１２０は、アクセスが許可されなかったことを、クライアントデバイスに通知する。いくつかの実施形態では、ネットワークアプリケーション１２０は、不備をどのように是正したらよいかを、クライアントデバイス１１０および／またはユーザに教える。例えば、ネットワークアプリケーション１２０は、ユーザが是正を支援できるように、なぜユーザにアクセスが許可されなかったのか、その理由の表示を提示するように、クライアントデバイス１１０に命じることができる。この点について、クライアントデバイス１１０は、ユーザが不備を是正する助けとなり得る情報を獲得するためのプログラムされたロジックを含むことができる。例えば、ネットワークアプリケーション１２０から受信した情報が本質的に技術的である場合（例えば、ユーザが容易に理解できないことがあるエラーコードによって表現されている場合）、クライアントデバイス１１０は、より容易に理解できる情報を（例えばＤＳＡＰサーバに問い合わせることによって）取得することができる。この情報は、例えば、教示的な文言、追加情報を有するサイトのＵＲＬなどを含むことができる。例えば、インストールされていることをＤＳＴＳが期待している最新のアンチウイルスパッチをインストールすることなどをユーザに命じる文言を、ユーザに提示することができ、そのため、ユーザは、デバイスクレームの不備を是正する行動を取ることができる。しかし、不備を是正する行動を取るうえで、本発明の必ずしもすべての実施形態がユーザに依存しているわけではないことを理解されたい。例えば、いくつかの実施形態では、クライアントデバイス１１０は、不備を自動的に是正するためのプログラムされたロジックを実行することができる。本発明の実施形態は、数々の方法のいずれかで実施することができる。

行為３６０が終了すると、プロセス３００は終了する。

行為３５０において、アクセスを許可するのに十分な根拠をデバイスクレームが提供したと判定された場合、プロセス３００は、行為３７０に進み、アクセスが許可される。その後、プロセス３００は終了する。

図１を再び参照すると、クライアントデバイス１１０にアクセスを許可すると、ネットワークアプリケーション１２０は、デバイスクレームを処理することができる。そのような処理は、セキュリティおよび非セキュリティ関連の機能を含む、数々の機能のいずれかを実行するために、デバイスクレーム内の情報を使用することを含むことができる。例えば、クライアントデバイス１１０の特性または能力を記述するデバイスクレーム内の情報は、特定のアプリケーション機能を駆動するために、またそれらの特性または能力に適するように出力を調整するためになど、ネットワークアプリケーション１２０によって使用することができる。本発明の実施形態は、デバイスクレーム内で提供される情報をいずれか特定の方法で使用することに限定されない。

いくつかの実施形態では、図１の例示的なプロセスをいくらか変更して、クライアントデバイスが、ネットワークアプリケーションと直接的に通信できない代わりに、仲介手段を介してネットワークアプリケーションと通信できるようにすることができる。この点について、図１は、アクセスゲートウェイ１２５を示しており、いくつかの実施形態では、アクセスゲートウェイ１２５は、クライアントデバイス１１０と通信して、例えば、（矢印１５２によって示されるように、上述の通り）ネットワークアプリケーション１２０へのアクセスを求める要求をクライアントデバイス１１０から受信し、（矢印１５４によって示されるように、上述の通り）アクセス要求に応答し、および／または（矢印１６２によって示されるように、上述の通り）クライアントデバイス１１０からデバイスクレームを受信することができる。

アクセスゲートウェイなどの仲介手段は、例えば、ネットワークアプリケーション１２０がデバイスクレームの処理をサポートしない状況、またはそれ以外ではデバイスクレームの処理のために適切に構成されていない状況において、有益となる。例えば、いくつかのレガシネットワークアプリケーションは、デバイスクレームを処理することが可能ではないことがあり、この機能を使えるようにするのに必要な再構成は、ネットワークアプリケーションを利用可能にしているエンティティによるかなりの投資を必要とすることがあることを出願人は認識した。したがって、仲介手段は、デバイスクレーム内で提供される情報を処理するための「クレーム対応の」フロントエンドをネットワークアプリケーション１２０に提供することができる。

仲介手段による処理は、セキュリティに関する機能を含むが、それに限定されない、数々の機能のいずれかを実行することを含むことができる。一例として、仲介手段は、アクセス制御決定を行うためにデバイスクレームを処理し、アクセスを許可されたクライアントデバイスからの情報だけをネットワークアプリケーション１２０に渡すことができる。別の例として、仲介手段は、ネットワークアプリケーションがそれを消費するように構成された形にデバイスクレームを変換するために、デバイスクレームを事前に処理することができ、その後、アプリケーションは、ある機能を実行する際に、その情報を使用することができる。コンピュータプログラミング分野の当業者は、図１の例示的なシステムにおける仲介手段について、数々の用途を思い浮かべることができ、本発明の実施形態は、いずれか特定の実施に限定されない。仲介手段およびそれによって実行される機能を利用するいくつかの例示的な実施が、本発明の譲受人に譲渡された、２０１０年６月２４日に出願された、「Trusted Intermediary For Network Layer Claims-Enabled Access Control」と題する特許文献３において開示されており、同出願は、その全体が参照により本明細書に組み込まれる。

上述したように、クライアントデバイスは、潜在的に、クライアントデバイスおよび／またはネットワークアプリケーションが信用関係を有するＤＳＴＳなど、複数のＤＳＴＳのいずれかからデバイスクレームを獲得することができる。デバイスクレームを発行する際に、各ＤＳＴＳによって使用されるポリシーの間の矛盾を防ぐため、本発明のいくつかの実施形態は、各ＤＳＴＳが同意する矛盾のないポリシースキームを提供する。例えば、いくつかの実施形態では、すべてのデバイスクレーム発行ポリシーは、１つのＤＳＴＳが、他のＤＳＴＳよりも制約的な要件をクライアントデバイスに課すことはあっても、どのＤＳＴＳも、別のＤＳＴＳによって実施されるポリシーに違反しない限りクライアントデバイスが満たすことができないポリシーを実施しないようにすることができる。例えば、１つのＤＳＴＳは、特定のデバイスクレームを発行するために、クライアントデバイスが先週中にソフトウェアパッチをインストールしないように要求できなくされることがあり、一方、別のＤＳＴＳは、デバイスクレームを発行するために、クライアントデバイスが一定の日数に限ってソフトウェアパッチを有さなくてもよいと指示する。いくつかの実施形態では、ポリシーの衝突は、追加的な表現（ａｄｄｉｔｉｖｅ ｔｅｒｍ）で条件を表現することで回避されるが、本発明の実施形態は、この点において限定されず、任意の適切なスキームを利用することができ、またはポリシーの無矛盾性が優先されない場合は、どのような方法も利用されない。

図１の例示的なシステムは、デバイスクレームをクライアントデバイスに提供することに関連する処理を実行するために、ＤＳＴＳを利用するが、本発明の実施形態は、そのような実施に限定されないことを理解されたい。ＤＳＴＳを含んでもよく、または含まなくてもよい、いずれか１つまたは複数の適切なコンポーネントを、代わりに利用することができる。例えば、上で参照した、本発明の譲受人に譲渡された、「Trustworthy Device Claims for Enterprise Applications」と題する特許文献２において説明されているように、デバイスクレームの生成および発行に関連する処理の部分は、認証サーバによって実行することができる。他の実施形態は、ＤＳＴＳをまったく利用しなくてよく、デバイスクレームの生成および／または発行のために他のコンポーネントを利用することができる。任意の適切な構成のコンポーネントを利用することができ、本発明の実施形態は、この点において限定されない。

本発明の特徴を実施するためのシステムおよび方法の様々な態様は、図４に示された例示的なコンピュータシステム４００など、１つまたは複数のコンピュータシステム上で実施することができる。コンピュータシステム４００は、入力デバイス４０２と、出力デバイス４０１と、プロセッサ４０３と、メモリシステム４０４と、ストレージ４０６とを含み、それらのすべては、１つまたは複数のバス、スイッチ、ネットワーク、および／または他の適切な相互接続を含むことができる相互接続メカニズム４０５を介して、直接的または間接的に結合される。入力デバイス４０２は、ユーザまたは機械（例えば人間の操作者）から入力を受け取り、出力デバイス４０１は、ユーザまたは機械（例えば液晶ディスプレイ）に情報を表示または送信する。入力デバイスおよび出力デバイスは、とりわけ、ユーザインタフェースを提示するために使用することができる。ユーザインタフェースを提供するために使用できる出力デバイスの例は、出力を可視的に提示するためのプリンタまたは表示スクリーンと、出力を可聴的に提示するためのスピーカまたは他の音声生成デバイスとを含む。ユーザインタフェースのために使用できる入力デバイスの例は、キーボードと、マウス、タッチパッド、およびデジタイジングタブレットなどのポインティングデバイスとを含む。別の例として、コンピュータは、音声認識を介して、または他の可聴フォーマットで、入力情報を受け取ることができる。

プロセッサ４０３は、一般に、（例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓファミリのオペレーティングシステム、または他の任意の適切なオペレーティングシステムなど）オペレーティングシステムと呼ばれるコンピュータプログラムを実行し、オペレーティングシステムは、他のコンピュータプログラムの実行を制御し、スケジューリング、入力／出力および他のデバイス制御、課金、コンパイル、ストレージ割り当て、データ管理、メモリ管理、通信およびデータフロー制御を提供する。共同で、プロセッサとオペレーティングシステムは、アプリケーションプログラムおよび他のコンピュータプログラム言語がそれに対して書かれるコンピュータプラットフォームを定義する。

プロセッサ４０３は、様々な機能を実施するために、１つまたは複数のコンピュータプログラムを実行することもできる。これらのコンピュータプログラムは、手続型プログラミング言語、オブジェクト指向プログラミング言語、マクロ言語、またはそれらの組み合わせを含む、任意のタイプのコンピュータプログラム言語で書くことができる。これらのコンピュータプログラムは、ストレージシステム４０６内に記憶することができる。ストレージシステム４０６は、揮発性または不揮発性媒体上に情報を保持することができ、固定式または着脱可能式とすることができる。ストレージシステム４０６は、図５により詳細に示されている。

ストレージシステム４０６は、コンピュータプログラムまたはプログラムによって使用される情報を定義する信号が記憶される、コンピュータ読み取り可能および書き込み可能な有形な不揮発性記録媒体５０１を含むことができる。記録媒体は、例えば、ディスクメモリ、フラッシュメモリ、および／または情報を記録および記憶するために使用可能な他の任意の製造物品とすることができる。一般に、動作中、プロセッサ４０３は、不揮発性記録媒体５０１からデータを読み取り、プロセッサ４０３が媒体５０１にアクセスするよりも高速に情報にアクセスすることを可能にする、揮発性メモリ５０２（例えばランダムアクセスメモリ、すなわちＲＡＭ）に書き込む。メモリ５０２は、図４に示されるストレージシステム４０６またはメモリシステム４０４内に配置することができる。プロセッサ４０３は、一般に、集積回路メモリ４０４、５０２内のデータを操作し、その後、処理が完了した後に、データを媒体５０１にコピーする。媒体５０１と集積回路メモリ要素４０４、５０２の間でのデータ移動を管理するための様々なメカニズムが知られているが、本発明は、現在知られているか、それとも今後開発されるかに係わらず、いかなるメカニズムにも限定されない。本発明は、特定のメモリシステム４０４またはストレージシステム４０６にも限定されない。

このように、本発明の少なくとも一実施形態のいくつかの態様を説明してきたが、当業者には様々な代替形態、変更形態、および改良形態が容易に思い浮かぶことを理解されたい。そのような代替形態、変更形態、および改良形態は、本開示の一部であることが意図されており、本発明の主旨および範囲内にあることが意図されている。したがって、上述の説明および図面は、例を挙げたにすぎない。

本発明の上述の実施形態は、数々の方法のいずれかで実施することができる。例えば、実施形態は、ハードウェア、ソフトウェア、またはそれらの組み合わせを使用して実施することができる。ソフトウェアで実施される場合、ソフトウェアコードは、任意の適切なプロセッサ上で実行することができ、または単一のコンピュータ内で提供されるか、それとも複数のコンピュータおよび／もしくはシステム間に分散させて提供されるかに係わらず、プロセッサの集合上で実行することができる。そのようなプロセッサは、集積回路コンポーネント内に１つまたは複数のプロセッサを有する、集積回路として実施することができるが、プロセッサは、任意の適切なフォーマットの回路を使用して実施することができる。

本明細書で説明する機能を実行するコンポーネントまたはコンポーネントの集合はいずれも、全体として、上述の機能を制御する１つまたは複数のコントローラと見なすことができることを理解されたい。１つまたは複数のコントローラは、専用ハードウェアを用いて、または上述の機能を実行するようにマイクロコードもしくはソフトウェアを使用してプログラムされた１つまたは複数のプロセッサを利用することによってなど、数々の方法で実施することができる。コントローラが、システム操作のためのデータを記憶または提供する場合、そのようなデータは、中央リポジトリ内に、複数のリポジトリ内に、またはそれらを組み合わせて記憶することができる。

コンピュータは、ラックマウント型コンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、またはタブレットコンピュータなど、多くの形態のいずれかで具現できることも理解されたい。加えて、コンピュータは、携帯情報端末（ＰＤＡ）、スマートフォン、または他の任意の適切なポータブルもしくは固定式電子デバイスを含む、一般にコンピュータとは見なされないが、適切な処理能力を有するデバイス内で具現することもできる。

また、コンピュータは、１つまたは複数の入力デバイスおよび出力デバイスを有することができる。これらのデバイスは、とりわけ、ユーザインタフェースを提示するために使用することができる。ユーザインタフェースを提供するために使用できる出力デバイスの例は、出力を可視的に提示するためのプリンタまたは表示スクリーンと、出力を可聴的に提示するためのスピーカまたは他の音声生成デバイスとを含む。ユーザインタフェースのために使用できる入力デバイスの例は、キーボードと、マウス、タッチパッド、およびデジタイジングタブレットなどのポインティングデバイスとを含む。別の例として、コンピュータは、音声認識を介して、または他の可聴フォーマットで、入力情報を受け取ることができる。

そのようなコンピュータは、ローカルエリアネットワーク、または企業ネットワークもしくはインターネットなどのワイドエリアネットワークを含む、任意の適切な形態の１つまたは複数のネットワークによって相互接続することができる。そのようなネットワークは、任意の適切な技術に基づくことができ、任意の適切なプロトコルに従って動作することができ、無線ネットワーク、有線ネットワーク、または光ファイバネットワークを含むことができる。

また、本明細書で概説した様々な方法またはプロセスは、１つまたは複数のプロセッサ上で実行可能な、様々なオペレーティングシステムまたはプラットフォームのいずれか１つを利用するソフトウェアとしてコード化することができる。加えて、そのようなソフトウェアは、多くの適切なプログラミング言語および／またはプログラミングもしくはスクリプトツールのいずれかを使用して書くことができ、フレームワークまたは仮想マシン上で実行される実行可能な機械語コードまたは中間コードとしてコンパイルすることもできる。

この点について、本発明は、１つまたは複数のコンピュータまたは他のプロセッサ上で実行された場合、上述の本発明の様々な実施形態を実施する方法を実行する、１つまたは複数のプログラムによって符号化された、コンピュータ可読媒体（または複数のコンピュータ可読媒体）（例えば、コンピュータメモリ、１つまたは複数のフロッピディスク、コンパクトディスク（ＣＤ）、光ディスク、デジタルビデオディスク（ＤＶＤ）、磁気テープ、フラッシュメモリ、フィールドプログラマブルゲートアレイもしくは他の半導体デバイス内の回路構成、または他の非一時的な有形なコンピュータ可読記憶媒体）として具現することができる。１つまたは複数のコンピュータ可読媒体は、上述の本発明の様々な態様を実施するために、記憶された１つまたは複数のプログラムを１つまたは複数の異なるコンピュータまたは他のプロセッサ上にロードできるように、トランスポート可能とすることができる。本明細書で使用される場合、「非一時的なコンピュータ可読記憶媒体」という用語は、製品（すなわち製造物品）または機械であると見なすことができるコンピュータ可読媒体だけを含む。

「プログラム」または「ソフトウェア」という用語は、上述の本発明の様々な態様を実施するようにコンピュータまたは他のプロセッサをプログラムするために利用できる、任意のタイプのコンピュータコードまたは１組のコンピュータ実行可能命令を指すために、本明細書では総称的な意味で使用される。加えて、この実施形態の一態様によれば、実行された場合に本発明の方法を実行する１つまたは複数のコンピュータプログラムは、単一のコンピュータまたはプロセッサ上に存在する必要はなく、本発明の様々な態様を実施するために、モジュール化して多くの異なるコンピュータまたはプロセッサ間に分散させることができることを理解されたい。

コンピュータ実行可能命令は、１つまたは複数のコンピュータまたは他のデバイスによって実行されるプログラムモジュールなど、多くの形態を取ることができる。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データタイプを実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。一般に、プログラムモジュールの機能は、様々な実施形態において望ましいように、組み合わせること、または分散させることができる。

また、データ構造は、任意の適切な形態のコンピュータ可読媒体内に記憶することができる。説明を簡潔にするために、データ構造は、データ構造内におけるロケーションを通して関係付けられるフィールドを有するように示すことができる。そのような関係は、フィールドのための記憶域にフィールド間の関係を伝えるコンピュータ可読媒体内のロケーションを割り当てることによっても同様に達成することができる。しかし、データ構造のフィールド内の情報間の関係を確立するために、ポインタ、タグ、またはデータ要素間の関係を確立する他のメカニズムを使用することを含む、任意の適切なメカニズムを使用することができる。

本発明の様々な態様は、単独で、組み合わせて、または上述の実施形態では具体的に説明されていない様々な構成で使用することができ、したがって、その応用において、上述の説明で説明された、または図面に示された、コンポーネントの詳細および構成に限定されない。例えば、一実施形態で説明された態様は、他の実施形態で説明された態様といずれかの方法で組み合わせることができる。

また、本発明は、方法として具現することができ、それの一例が提供された。方法の部分として実行される行為は、任意の適切な方法で順序付けることができる。したがって、本明細書で説明される例示的な実施形態では順次的な行為として示されていても、いくつかの行為を同時に実行することを含むことができる、説明されたのとは異なる順序で行為が実行される実施形態を構成することができる。

請求項要素を修飾するために、請求項内で使用される「第１の」、「第２の」、「第３の」などの序数詞は、それ自体では、いかなる優先度、優先権、もしくは１つの請求項要素が別の請求項要素よりも上の序列にあること、または方法の行為が実行される時間的順序を含意せず、ある名前を有する１つの請求項要素を（序数詞を使用しなければ）同じ名前を有する別の要素から区別するためのラベルとしてもっぱら使用されて、請求項要素を区別する。

また、本明細書で使用される表現および用語は、説明を目的としたものであり、限定的なものと見なすべきではない。本明細書における「ｉｎｃｌｕｄｉｎｇ」、「ｃｏｍｐｒｉｓｉｎｇ」、または「ｈａｖｉｎｇ」、「ｃｏｎｔａｉｎｉｎｇ」、「ｉｎｖｏｌｖｉｎｇ」、およびこれらの変形の使用は、その後に列挙される項目およびその均等物、ならびに追加項目を包含することが意図されている。

Claims (10)

1. ネットワークアプリケーションおよびクライアントデバイスを備えるシステムで使用するための方法であって、
   （Ａ）前記ネットワークアプリケーションと信用関係を有するデバイス状態トークンサービスが、前記クライアントデバイスの特性および／または状態を記述する情報を前記クライアントデバイスから受信する行為と、
   （Ｂ）前記情報を処理して前記クライアントデバイスに発行されるデバイスクレームを識別する行為と、
   （Ｃ）（Ｂ）で識別された前記デバイスクレームを生成する行為と、
   （Ｄ）（Ｃ）で生成された前記デバイスクレームを前記クライアントデバイスに発行する行為と
   を含むことを特徴とする方法。
2. 前記デバイス状態トークンサービスは、前記クライアントデバイスとも信用関係を有することを特徴とする請求項１に記載の方法。
3. （Ａ）に先立って、
   前記デバイス状態トークンサービスが、（Ａ）で提供される前記情報を収集するために前記クライアントデバイスによって使用可能なポリシーおよび／またはスクリプトをクライアントデバイスに提供する行為と、
   前記ポリシーおよび／またはスクリプトを実行することによって生成された結果を受信する行為であって、前記結果は、前記クライアントデバイス上のＴＰＭ（トラステッドプラットフォームモジュール）コンポーネントによって生成された情報を備える、行為と
   をさらに含むことを特徴とする請求項１に記載の方法。
4. クライアントデバイスおよびネットワークアプリケーションを備えるシステムで前記クライアントデバイスによって実行された場合に、
   （Ａ）前記ネットワークアプリケーションへのアクセスを要求する行為と、
   （Ｂ）デバイスクレームを発行することについて前記ネットワークアプリケーションから信用を得た１つまたは複数のデバイス状態トークンサービスの表示を受信する行為と、
   （Ｃ）デバイスクレームを発行することについて前記クライアントデバイスから信用を得たデバイス状態トークンサービスを、（Ｂ）で示された前記１つまたは複数のデバイス状態トークンサービスの中から選択する行為と、
   （Ｄ）前記クライアントデバイスの特性および／または状態を記述したデバイスクレームを発行するように求める要求を、（Ｃ）で選択された前記デバイス状態トークンサービスに伝達する行為と
   を含む方法を実行する符号化された命令を有することを特徴とする少なくとも１つのコンピュータ可読記憶媒体。
5. （Ｃ）は、前記クライアントデバイスが既存の信用関係を有するデバイス状態トークンサービスを、前記１つまたは複数のデバイス状態トークンサービスの中から選択する行為を含むことを特徴とする請求項４に記載の少なくとも１つのコンピュータ可読記憶媒体。
6. （Ｃ）は、所定の基準を満たすデバイス状態トークンサービスを、前記１つまたは複数のデバイス状態トークンサービスの中から選択する行為を含むことを特徴とする請求項４に記載の少なくとも１つのコンピュータ可読記憶媒体。
7. （Ｄ）の後に、発行されたデバイスクレームを受信する行為と、前記ネットワークアプリケーションへのアクセスを求める要求に関連して、前記発行されたデバイスクレームを利用する行為と
   をさらに含むことを特徴とする請求項４に記載の少なくとも１つのコンピュータ可読記憶媒体。
8. （Ａ）クライアントデバイスから１つまたは複数のデバイスクレームを受信し、
   （Ｂ）前記１つまたは複数のデバイスクレームが有効で真正であることを判定し、
   （Ｃ）（Ｂ）で前記１つまたは複数のデバイスクレームが有効で真正であると判定された場合、前記１つまたは複数のデバイスクレームを評価して、ネットワークアプリケーションへのアクセスを前記クライアントデバイスに許可すべきかどうかを判定し、
   （Ｄ）（Ｃ）でアクセスを許可すべきであると判定された場合、前記クライアントデバイスに前記ネットワークアプリケーションへのアクセスを許可する
   ようにプログラムされた少なくとも１つのプロセッサを備えることを特徴とするシステム。
9. （Ａ）〜（Ｄ）の少なくとも一部は、前記ネットワークアプリケーションによって実行されることを特徴とする請求項８に記載のシステム。
10. アクセスを許可すべきではないと判定された場合、アクセスが許可されるために取るべき措置を前記クライアントデバイスに教える行為をさらに含み、前記教える行為は、（Ｄ）でアクセスを許可すべきではないと判定される原因となった前記デバイスクレーム内の不備の是正に関する情報を前記クライアントデバイスに提供する行為を含むことを特徴とする請求項８に記載のシステム。

Images