信用管理システムおよび方法
ウェブサービス、デジタル著作権管理システム、および／または他のアプリケーションとともに使用するための信用管理の仕組みを容易に設定するためのシステムおよび方法が提示される。信用管理の仕組みを設定するための方法が、信用管理の仕組みの特定の態様を自己矛盾のないやり方で定義するようにユーザを促すグラフィカル・ユーザ・インターフェイス（ＧＵＩ）をユーザへと提供することを含んでいる。一実施形態においては、方法が、ロールを定義するようにユーザを促すロールＧＵＩ、ロールに対応するサービスを定義するようにユーザを促すサービスＧＵＩ、ロールのうちの少なくとも１つをプリンシパルに関連付けるなど、プリンシパルを定義するようにユーザを促すプリンシパルＧＵＩ、およびノードとして機能するように指名されたプリンシパルについてロールバインディングを提示し、ノード間の相互作用を定義するようにユーザを促すノードＧＵＩを提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２００６年８月１１日付の米国特許仮出願第６０／８２２，０６８号の利益を主張し、この米国特許仮出願を、ここでの言及によって援用する。
【０００２】
この特許文書の開示の一部は、著作権保護の対象となる題材を含んでいる。著作権者は、この特許文書または明細書を特許商標局のファイルまたは記録に表れるとおりに複製することについて異議を唱えないが、それ以外のあらゆる著作権の権利を留保する。
【背景技術】
【０００３】
ネットワークおよびコンピュータのセキュリティが重要さを増すにつれて、しっかりした信用管理の仕組みを設計および実装することが、ネットワークサービスおよび他のアプリケーションの生成において、より重要な部分となってきている。しかしながら、信用管理の仕組みの設計および実装は、そのような仕組みに頼るサービスおよびアプリケーションの機能に比較的無関係であることが多く、したがって、結果として、そのようなサービスおよびアプリケーションの設計者が、信用管理の仕組みを効率的かつ正しいやり方で設計および実装するための専門知識を欠いている可能性がある。
【０００４】
信用管理は、暗号法、公開鍵基盤、デジタル証明書（および、そのチェーニング）、セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）アサーション（例えば、ロールを定義するため）、などといった種々の基礎的要素の使用を伴う可能性がある。広く言えば、信用管理の仕組みは、典型的には、エンティティがなりすましではない真正なエンティティであることを確認するため、およびエンティティが当該エンティティに許された行為以外の行為を実行できないようにするために、システムがどのように振る舞うべきかを定めることである。自己矛盾のないセキュアな信用管理の仕組みを設定することは、所与のシステムにおいて、ロールおよび権限の重なり合うさまざまなエンティティが典型的に存在するため、複雑な仕事となる可能性がある。
【発明の概要】
【０００５】
ウェブサービス、デジタル著作権管理システム、および／または他のアプリケーションとともに使用するための信用管理の仕組みを容易に設定できるようにするためのシステムおよび方法が提示される。例えば、これに限られるわけではないが、本明細書に記載されるシステムおよび方法を、本出願と譲受人が同一である米国特許出願第１０／８６３，５５１号（米国特許出願公開第２００５／００２７８７１号）（「‘５５１号出願」）に記載されているメディアオーケストレーションのためのネットワーク環境（ＮＥＭＯ）というサービスオーケストレーション技術および／または本出願と譲受人が同一である米国特許出願第１１／５８３，６９３号（米国特許出願公開第２００７／０１８０５１９号）（「‘６９３号出願」）に記載の例えばセキュアなＤＲＭシステムを設計および実装するためのデジタル著作権管理（「ＤＲＭ」）技術などといった技術の使用に関係がある種々の利害関係者を助けるために使用することができる。‘５５１号出願および‘６９３号出願は、その全体がここでの言及によって本出願に取り入れられたものとされる。
【０００６】
一実施形態においては、ネットワーク環境において使用するための信用管理の仕組みを設定するための方法が、信用管理の仕組みの特定の態様を定義するようにユーザを促す種々のグラフィカル・ユーザ・インターフェイスをユーザへと提供することを含んでいる。とくには、ネットワーク環境において使用するための信用管理の仕組みを設定するための方法が、ロールを定義するようにユーザを促すロール・グラフィカル・ユーザ・インターフェイスを提供すること、ロールに対応するサービスを定義するようにユーザを促すサービス・グラフィカル・ユーザ・インターフェイスを提供すること、ロールのうちの少なくとも１つをプリンシパルに関連付けるなど、プリンシパルを定義するようにユーザを促すプリンシパル・グラフィカル・ユーザ・インターフェイスを提供すること、およびノードとして機能するように指名されたプリンシパルについてロールバインディングを提示し、ノード間の相互作用を定義するようにユーザを促すノード・グラフィカル・ユーザ・インターフェイスを提供することを含んでいる。一実施形態においては、この方法が、信用管理の仕組みが自己矛盾のないやり方で設定されることを保証する。例えば、多数の時点において、設定グラフィカル・ユーザ・インターフェイスが、選択の対象としての選択肢一式をユーザへと提示する。自己矛盾がないように保証するために、選択肢は、先の設定の決定にもとづき、有効な選択肢のみに限定される。
【０００７】
一実施形態においては、ネットワーク環境において使用するための信用管理の仕組みを設定するためのシステムが、ロールモジュール、サービスモジュール、プリンシパルモジュール、およびノードモジュールを含んでいる。ロールモジュールが、ロールを定義するようにユーザを促す。サービスモジュールが、ロールに対応するサービスを定義するようにユーザを促す。プリンシパルモジュールが、ロールのうちの少なくとも１つをプリンシパルに関連付けるなど、プリンシパルを定義するようにユーザを促し、ノードモジュールが、ノードとして機能するように指名されたプリンシパルについてロールバインディングを提示し、ノード間の相互作用を定義するようにユーザを促す。
【０００８】
本発明の諸作の他の態様および利点は、本発明の諸作の原理を例として示している添付の図面とともに検討される以下の詳細な説明から明らかになるであろう。
【図面の簡単な説明】
【０００９】
本発明の諸作を、以下の詳細な説明を添付の図面とともに参照することによって、より容易に理解できるであろう。添付の図面においては、同様の構成要素は、同様の参照番号によって指し示されている。
【００１０】
【図１】信用管理の仕組みを設定するための作業フローウィザードの例を示している。
【００１１】
【図２】ロール発行元の特定の属性を定めるためのロールＧＵＩを示している。
【００１２】
【図３】ロール呼び出し元の特定の属性を定めるためのロールＧＵＩを示している。
【００１３】
【図４】名前空間設定エディタを示している。
【００１４】
【図５】サービスを定義するためのサービスＧＵＩを示している。
【００１５】
【図６】プリンシパルおよびそれらの信任状を定義するためのプリンシパルＧＵＩを示している。
【００１６】
【図７】拡張鍵使用を定義するための拡張鍵使用エディタを示している。
【００１７】
【図８】ノードを定義するためのノードＧＵＩを示している。
【００１８】
【図９】設定ツールの実施形態を実施するためのコンピュータシステムの例を示している。
【００１９】
【図１０】図９の設定ツールの拡大図を示している。
【００２０】
【図１１】一実施形態に従って信用管理の仕組みを設定するための方法のプロセスフロー図である。
【発明を実施するための形態】
【００２１】
本発明の諸作を、以下で詳しく説明する。いくつかの実施形態を説明するが、本発明の諸作が、いずれかの実施形態に限定されるわけではなく、多数の代案、変更物、および均等物を包含することを理解すべきである。さらに、以下の説明においては、本発明の諸作の完全な理解をもたらすために、多数の具体的な詳細を記載するが、いくつかの実施形態は、そのような詳細の一部またはすべてを欠いても実施可能である。さらに、分かり易さの目的で、該当の技術分野において公知である特定の技術的題材については、本発明の諸作を不必要に曖昧にしてしまうことがないよう、詳しい説明を省略する。
【００２２】
ウェブサービス、デジタル著作権管理システム、および／または他のアプリケーションにおいて使用するための信用管理の仕組みを容易に設定できるようにするためのシステムおよび方法が提示される。例えば、これに限られるわけではないが、本明細書に記載されるシステムおよび方法を、‘５５１号出願に記載されているメディアオーケストレーションのためのネットワーク環境（ＮＥＭＯ）というサービスオーケストレーション技術および／または例えばセキュアなＤＲＭシステムを設計および実装するための‘６９３号出願に記載のデジタル著作権管理技術などといった技術の採用に関係がある種々の利害関係者を助けるために使用することができる。このようなシステムおよび方法が新規であり、そこで使用される構成要素、システム、および方法の多くも新規であることを、理解できるであろう。
【００２３】
‘５５１号出願にさらに詳しく記載されているとおり、信用管理は、暗号法、公開鍵基盤、デジタル証明書（および、そのチェーニング）、セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）アサーション（例えば、ロールを定義するため）、などといった種々の基礎的要素の使用を伴う可能性がある。広く言えば、信用管理の仕組みは、典型的には、エンティティがなりすましではない真正なエンティティであることを確認するため、およびエンティティが当該エンティティに許された行為以外の行為を実行できないようにするために、システムがどのように振る舞うべきかを定めることに関係する。自己矛盾のないセキュアな信用管理の仕組みを定めることは、所与のシステムにおいて、ロールおよび権限の重なり合うさまざまなエンティティが典型的に存在するため、複雑な仕事となる可能性がある。
【００２４】
好ましい実施形態においては、ウェブサービス、デジタル著作権管理システム、および／またはアプリケーションプログラムなどにおいて使用される信用管理の仕組みを容易に設定できるようにするために、設定ツール（本明細書において、単に「ツール」と称されることもある）が使用される。設定ツールの実施形態は、複雑なネットワーク（‘５５１号出願に記載のネットワーク、および／または他の任意の適切なネットワーク）を種々のシステム構成要素間の関係をより容易に把握できるようにする直感的かつグラフィカルな形態で表わすうえで、有用となりうる。
【００２５】
設定ツールの実施形態は、信用管理の仕組みを設定するときに内部整合性について信用管理の仕組みを常に検証することによって、さらには設定を曖昧さがなくかつコンピュータおよび人間にとって読解可能な形態で把握することによって、システム設計者を助けることができる。
【００２６】
設定ツールの実施形態は、システム設計者の生産性を向上させることができる。設計プロセスによって生成されるネットワークモデルから、すべてのＮＥＭＯプリンシパルについてすべての信用管理信任状を自動的に生成するために、設定ツールを使用することができる。いくつかの実施形態においては、設定ツールを、迅速に実現できる実装がモデルによって定められるとおりにＮＥＭＯノード間のライブなやり取りを実行できるよう、モデルによって暗示されるアプリケーションおよびサービスのためのスタブコードを有するデフォルトのＪａｖａ（登録商標）ベースのプロジェクトを生成するために使用することも可能である。このように、設定ツールの実施形態は、機能する基本機能を迅速に得るために開発者を助けることができ、したがって開発者が、設定ツールがないならば開発の労力の大きな部分を費やすことになりかねない信用管理の問題について知らないままで、ＮＥＭＯサービスおよび民生用アプリケーションのためのビジネスロジックの実装に集中できるようにする。
【００２７】
一実施形態においては、設定ツールが、信用管理の仕組みの設定においてユーザを案内する信用管理エディタを含んでいる。図１が、新たな信用管理の仕組みの設定または既存の信用管理の仕組みの設定の変更をユーザにとって可能にする作業フロー・ウィザード・ダイアログ１０の例を示している。図１に示した例では、作業フローウィザードの「作成」ボタン１２を選択すると、アプリケーションドメイン設定エディタ（本明細書において、信用管理エディタとも称される）がユーザへと提示される。
【００２８】
好ましい実施形態においては、信用管理エディタは、機能ごとのグラフィカル・ユーザ・インターフェイス（ＧＵＩ）によってユーザへと提示される４つの主モジュールを含んでいる。機能ごとのＧＵＩは、ロールＧＵＩ、サービスＧＵＩ、プリンシパルＧＵＩ、およびノードＧＵＩを含む。信用管理エディタの実施形態を、図２〜８を参照して説明する。図２を参照すると、信用管理エディタは、ツールバー１４ならびに機能ごとのタブ２０、２２、２４、２６、および２８を含んでいる。ツールバーは、例えばファイル管理の操作などといった共通のアプリケーション操作、ならびに名前空間（ＮＳ）および拡張鍵用途（ＸＫＵ）操作などといったいくつかのアプリケーション特有の操作へのアクセスを提供する。機能ごとのタブは、機能ごとのＧＵＩを起動するために使用される。機能ごとのＧＵＩおよびそれらに関する機能を、図２〜８を参照して後述する。
【００２９】
ロールＧＵＩ
図２が、ロールＧＵＩ３０が表示されている状態の信用管理エディタの実施形態を示している。ロールＧＵＩは、ロールを定義するようにユーザを促す。一実施形態においては、ロールは、所与のピアが特定の挙動パターンとの組み合わせにおいて呈する一式のサービスである。この実施形態においては、ロールＧＵＩが、「ロール」カラムと標識された左カラムと「エイリアス」カラムと標識された右カラムとを有する２列のロール名エディタを含んでいる。「ロール」カラムは、ロール名のリストで埋められるように構成され、「エイリアス」カラムは、対応するロールエイリアスで埋められるように構成されている。好ましい実施形態においては、ロールエイリアスが随意であり、定義される場合には、ロール名を短縮形で表示するために使用される。図２の実施形態においては、「リーフ（Ｌｅａｆ）」ロールおよび「モニタ（Ｍｏｎｉｔｏｒ）」ロールとして特定されるロールが定義されている。この例において、リーフロールは、サービスを提供しないクライアントのみのロールであり、モニタロールは、１つのサービス（さらに詳しくは、後述）を提供するロールである。
【００３０】
図２に示した実施形態においては、ロールＧＵＩが、発行元（ｉｓｓｕｒｅ）タブおよび呼び出し元（ｉｎｖｏｋｅｒ）タブをさらに含んでおり、これらが選択されると、対応する発行元マトリクスまたは呼び出し元マトリクスがユーザに提示される。図２は、発行元マトリクス３２が選択された状態のロールＧＵＩを示している。発行元マトリクスは、どのロールがどのロールをアサート（ａｓｓｅｒｔ）できるのかを定義するために使用される。一実施形態においては、ロールアサーションが、プリンシパルがロール「Ｙ」のロールアサーションを他のプリンシパルへと発行する資格を有するために、どのロール「Ｘ」を保有していなければならないかを特定する。例えば、「Ｘ」が「発行元ロール」に相当する一方で、「Ｙ」が「対象（ｓｕｂｊｅｃｔ）ロール」に相当する。図２の実施形態において、発行元マトリクスは、ｘ軸に発行元ロールを、ｙ軸に対象ロールを含んでおり、マトリクスのそれぞれの軸が、ロール名エディタに定められたそれぞれのロールによって自動的に埋められる。ロール間の相互作用が、発行元ロールと対象ロールとの間の交点にマーキングを施すことによって特定され、図２の実施形態においては、発行元ロールと対象ロールとの間の交点のマーキングが、マーキング付きの発行元ロールがマーキング付きの対象ロールをアサートできることを定義している。すなわち、発行元ロールと対象ロールとの間の交点のマーキングが、ロール発行元が、ｙ軸に示されている対象ロールをアサートするために、ｘ軸に示されているどのロールを有していなければならないかを示している。なお、図２に示した実施形態において、定義されたロールのうちの一部のみがロール発行元へと期せずして一致し、他のロールが、種々のＮＥＭＯサービスへのアクセスを許可するためにＮＥＭＯノードによって使用されるロールを参照できる。これは、一実施形態においては、「発行元」および「呼び出し元」という２つの別個のマトリクスをもたらす「ロール」の概念の過負荷に起因する。後者は、異なるロールを実行するノード間の相互作用（呼び出し）を記載する。前者は、それらのロールがそもそもどのように割り当てられるかである。ロールは、ときには両方の機能を有する。例えば、ロール「Ａ」を有するサービスが、ロール「Ｂ」のアサーションをロール「Ｃ」を有するクライアントへと発行することができる。この例では、発行元マトリクスが｛「Ａ」，「Ｂ」｝の組を定め、ロール「Ａ」がロール「Ｂ」をアサートできる旨を示す。同時に、「呼び出し元」マトリクスが｛「Ｃ」，「Ａ」｝の組を定め、ロール「Ｃ」を有するクライアントが、最も自然には、所与の信用管理エコシステムにおける参加者としてより多くの能力を得るため、新たなロール「Ｂ」のアサーションを許可するように求めるために、ロール「Ａ」を有するサービスに接触できることを意味する。
【００３１】
図３は、呼び出し元マトリクスが選択された状態のロールＧＵＩ３０を示している。呼び出し元マトリクス３４は、要求者（Ｒｅｑｕｅｓｔｅｒ）ロールと応答者（Ｒｅｓｐｏｎｄｅｒ）ロールとの間の関係を定義するために使用される。図３の実施形態においては、呼び出し元マトリクスが、ｙ軸に要求者ロールを、ｘ軸に応答者ロールを含んでおり、やはりマトリクスのそれぞれの軸が、ロール名エディタに定められたそれぞれのロールによって自動的に埋められる。ロール間の相互作用が、要求者ロールと応答者ロールとの間の交点にマーキングを施すことによって特定され、図３の実施形態においては、要求者ロールと応答者ロールとの間の交点のマーキングが、マーク付きの要求者ロールがマーク付きの応答者ロールを呼び出すことができる旨を示している。すなわち、要求者ロールと応答者ロールとの間の交点のマーキングが、或るノードにとって、ｙ軸に特定されるロールにて行為している別のノードのサービスを呼び出すために、ｘ軸に特定されるどのロールが必要であるのかを定めている。図３の例では、チェック付きの四角が、リーフロール（要求者）がモニタロール（応答者）を呼び出すことができる旨を示している。
【００３２】
ロールＧＵＩによれば、ユーザは、任意のロールに名前を付けること、およびロール間の関係を任意のやり方で定めることを、自由に行うことができる。後述されるとおり、発行元マトリクスおよび呼び出し元マトリクスに指定される関係が、後の設定作業に反映される。マトリクスによって図式的に表現されるロール間の関係のグラフィカルな表現が、信用管理ツールをユーザフレンドリにする特徴の１つである。ロールＧＵＩが、ロール間の関係を図式的に表現するために図２および３に示したような発行元マトリクスおよび呼び出し元マトリクスを使用しているが、他の表現形態も可能である。
【００３３】
ひとたびロールに名前が付けられ、ロールの関係が指定されると、それらのロールについてサービスを設定することができる。一実施形態においては、ロールごとのサービスを設定する前に、ユーザは、名前空間設定エディタを起動するように促される。名前空間設定エディタは、サービスおよびそれらの動作について定義されるすべての要求および応答のメッセージペイロードのスキーマタイプについて、名前空間を定めるようにユーザを促す。図４が、信用設定エディタ（図２および３を参照）のツールバーの「ＮＳ」ボタンを押すことによって起動される名前空間設定エディタ３８の実施形態を示している。図４の実施形態においては、名前空間設定エディタが、「エイリアス」、「名前空間」、および「スキーマ位置」の各カラムを含んでいる。「エイリアス」カラムは、それぞれの名前空間についてエイリアスを定めるために使用され、「名前空間」カラムは、ＸＭＬスキーマの名前空間を定めるために使用され、「スキーマ位置」カラムは、該当の名前空間のためのスキーマの位置を定めるために使用される。ひとたび名前空間が設定されると、ユーザは、「ＯＫ」ボタンを選択することによってアクティブな機能ごとのＧＵＩへと戻る。
【００３４】
サービスＧＵＩ
一実施形態においては、ロールおよび名前空間が定義された後に、サービスＧＵＩを起動すべくサービスタブ２２が選択される。図５が、サービスＧＵＩ４０が表示された状態の信用管理エディタの実施形態を示している。サービスＧＵＩは、ロールＧＵＩによって定義した各ロールに対応するサービスを定めるようにユーザを促すサービスエディタを含んでいる。サービスは、応答者ノードによって提示または提供される１式の特定の機能の表現を包んでいる。一実施形態においては、サービスＧＵＩが、ロールＧＵＩ３０によって先に定められたロール（例えば、図３において定義された「リーフ」およ「モニタ」ロール）で埋められる。それぞれのロールについて、ユーザは、該当のロールを有するノードによって提示されるサービス一式を定義することができる。なお、一部のロールは、発行元ロールまたはクライアントのみのロールであるがため、対応するサービスを持たなくてもよい。図５に示した典型的なサービスは、「存在（Ｐｒｅｓｅｎｃｅ）」サービスであり、その機能は、ノードが利用可能であることを保証することである。なお、ロールに関連付けられるサービスの数および種類がアプリケーションに特有である。特定のサービスに関連付けられるソフトウェアコードは、サービス特有のソフトウェアモジュールにおいて具現化される。ピア−トゥ−ピアのやり取りのためのサービスモジュールの開発は、例えば‘５５１号出願に説明されている。
【００３５】
それぞれのサービスは、１つ以上の対応する動作を有することができ、それぞれの動作は、定義することができる異なるメッセージング特性を有することができる。図５の実施形態においては、サービスＧＵＩ４０が、信用管理に関する特定のメッセージング特性を定めるようにユーザを促す。特性がカラムに整理され、カラムにおいて、ユーザが特定の指定を行うことができる。図５のサービスＧＵＩに示されている特定のメッセージング特性は、以下のとおりである。
（ａ）「エレメント（Ｅｌｅｍｅｎｔ）」フィールド−メッセージペイロードのＸＭＬスキーマタイプを表わしているＸＭＬエレメントタイプ。
（ｂ）「インテグリティ（Ｉｎｔｅｇｒｉｔｙ）」チェックボックス−メッセージの完全性が保護されていなければならないか否か（例えば、デジタル署名されていなければならないか否か）を示している。
（ｃ）「機密性（Ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ）」チェックボックス−メッセージが機密でなければならないか否か（例えば、暗号化されていなければならないか否か）を示している。
（ｄ）「タイムスタンプ（Ｔｉｍｅｓｔａｍｐ）」チェックボックス−メッセージにタイムスタンプが付与されていなければならないか否かを示している。
（ｅ）「ナンス（Ｎｏｎｃｅ）」チェックボックス−メッセージが唯一性を保証するためにナンス（一度だけの数字）を含んでいなければならないか否かを示している。
【００３６】
図５の実施形態においては、サービスＧＵＩ４０が、ロール、対応するサービス、および対応する動作を、種々のロール、対応するサービス、および対応する動作の間の関係を図式的に表示するために、フォルダおよび下位フォルダを使用して階層的なやり方で整理する。ロール、サービス、および動作の間の関係ならびに関連のメッセージング特性の図式的表示が、新しいサービスのそれぞれについてサービス関連のコードを書き、構成コードの列を読み通して同様の関係および特性を解読しなければならないことに比べ、信用管理エディタをよりユーザフレンドリにする特徴の１つである。
【００３７】
プリンシパルＧＵＩ
プリンシパルＧＵＩを起動するために、プリンシパルタブ２４が選択される。図６が、プリンシパルＧＵＩ５０が表示された状態の信用管理エディタの実施形態を示している。一実施形態においては、プリンシパルは、固有のアイデンティティを有するエンティティである。すなわち、プリンシパルは、大まかに、単一のアイデンティティの概念に対応するが、このアイデンティティが確立されるやり方は、ドメイン特有である。例えば、Ｘ．５０９の証明書およびＳＡＭＬのアサーションの両者が、それらの宛て先としての「対象」の概念を有している。対象の名前が、そのような信任状の中身の一部であり、所与のプリンシパルについて同じでなければならない。しかしながら、他の信任状は、例えば秘密鍵など、対象を有していないかもしれない。ひとたび秘密の信任状が漏れると、このプリンシパルは、なりすましの対象となりうる。
【００３８】
プリンシパルＧＵＩ５０は、先に定義されたロールのうちの少なくとも１つをプリンシパルに組み合わせ、プリンシパルに信用管理の仕組みにおけるそれらの意図される用途に適した信用状を供給するなど、信用管理の仕組みのプリンシパルを定めるようにユーザを促す。図６の実施形態においては、プリンシパルＧＵＩが、プリンシパル名エディタおよびプリンシパル信任状エディタを含んでいる。プリンシパル名エディタは、「名前」カラム、「ＵＲＮ」カラム、「ＮＥＭＯノード」カラム、および「取り込み（Ｉｍｐｏｒｔｅｄ）」カラムを含んでいる。プリンシパル名エディタの各カラムは、定義されたそれぞれのプリンシパルについて以下の情報を特定するようにユーザを促す。
名前−ツールの各所において当該プリンシパルを指して使用される短くてユーザフレンドリな名前。
ＵＲＮ−該当のプリンシパルへと発行／該当のプリンシパルによって発行される信任状に使用されるユニフォーム・リソース・ネーム（ＵＲＮ）。
Ｎｅｍｏノード−該当のプリンシパルがＮＥＭＯノードであるか否か。プリンシパルがＮＥＭＯノードでない場合、一実施形態においては、プリンシパルは信用状発行元のみでなければならない。
【００３９】
取り込み−該当のプリンシパルが、設計されるシステムの一部として定義または準備しなければならない内部プリンシパルか、あるいは信任状を取り込んで設計されるシステムの内部で使用しなければならない既存の外部プリンシパルであるか否か。この例は、信用管理の仕組みの全体を一から設定することを説明しているため、この四角には、この例ではチェックが入れられていない。
【００４０】
一実施形態においては、プリンシパル名エディタが、プリンシパルを何回複製すべきかを特定するようにユーザを促すカラムを含むことができる。さらなる実施形態においては、プリンシパル名テーブルが、複製されるべきプリンシパルのための開始識別子など、さらなる複製情報を含むことができる。プリンシパルを複製すべき場合には、プリンシパルのＵＲＮが、どこに固有の識別子を挿入すべきかを示す浮動文字を含むことができる。例えば、プリンシパルをＩＤ＝１から出発して１００回複製すべき場合には、それぞれのプリンシパルは、ＩＤ以外は同じＵＲＮを、１〜１００の範囲の１００個の異なるプリンシパルのＩＤとともに含むＵＲＮを有する。この特徴を、異なるＵＲＮをそれぞれ必要とする複数の同様の装置が生成される実働環境に適用することができる。
【００４１】
図６の例では、プリンシパル「ＣＡ」、「ＲＡ」、「リーフノード」、および「モニタノード」が定められている。この例では、プリンシパルＣＡは、認証機関として機能するように定められ、プリンシパルＲＡは、ロールアサーション機関として機能するように定められる。例えば、他の証明書に署名することができる１つ以上の証明書を有するプリンシパルは、ＣＡである（Ｘ．５０９証明書においては、ｋｅｙ ｕｓａｇｅ ４−「ｃｅｒｔｉｆｉｃａｔｅ ｓｉｇｎｉｎｇ」）。データ署名が可能な１つ以上の証明書（ｋｅｙ ｕｓａｇｅ １２８−「ｄａｔａ ｓｉｇｎｉｎｇ」）およびこの証明書を有するプリンシパルは、ＧＵＩにおいて属性発行元としてマークされ、ロール機関（ＲＡ）となる。したがって、プリンシパルは、その能力をその信任状から得る。プリンシパル「リーフノード」は、リーフロールを実行するために定められ、プリンシパル「モニタノード」は、モニタロールを実行するために定められる。
【００４２】
一実施形態においては、プリンシパル名エディタにおいて定義されたプリンシパルの信任状が、プリンシパル信任状エディタによって定義される。好ましい実施形態においては、証明書およびアサーションという２種類の信任状が存在し、例えば証明書が、名前を公開鍵へとバインド（ｂｉｎｄ）し、アサーションが、名前をロールへとバインドする。図６の実施形態においては、プリンシパルＧＵＩ５０が、以下の特性に関してプリンシパルの信任状を特定するようにユーザを促す。
発行プリンシパル（Ｉｓｓｕｉｎｇ Ｐｒｉｎｃｉｐａｌ）−証明書を発行するプリンシパル。
発行証明書（Ｉｓｓｕｉｎｇ Ｃｅｒｔｉｆｉｃａｔｅ）−現在の証明書を発行した証明書の名前。
属性発行元（Ａｔｔｒｉｂｕｔｅ Ｉｓｓｕｅｒ）−当該証明書が属性発行元として機能できるか否か。
用途（Ｕｓａｇｅ）−どの証明書を使用できるかを表わすコード値（例えば、Ｘ．５０９証明書における標準列挙キー使用）。
値（Ｖａｌｕｅ）−それぞれの証明書について拡張鍵使用を定める。例えば、一実施形態においては、値フィールドは、それぞれの信任状の種類についてさらに詳細な情報を有するポップアップダイアログを生じさせるコンテクスト依存のフィールドであってよい。証明書については、値フィールドは、鍵使用、使用期限、ＸＫＵ、などの情報を提供できる。ＳＡＭＬアサーションについては、値フィールドは、すべての属性名およびそれらの値のリスト、有効期間、などを含むことができる。
供給（Ｐｒｏｖｉｓｉｏｎｅｄ）−プリンシパルにこれらの信用状が最初に供給されたのか、あるいはフィールドにおける操作において取得されたのかを示す。
【００４３】
一実施形態においては、証明書機関として使用されるように意図されたそれぞれのプリンシパルに、証明書発行のための鍵用途を有する少なくとも１つの証明書（例えば、用途＝証明書発行）が供給される。証明書名は、ツールの各所で参照のために使用される短いユーザフレンドリな名前として選択されるべきである。ロール発行元として使用されるように意図されたそれぞれのプリンシパルには、いくつかのロール発行ルールが前もって定められている場合には、ロール署名のための少なくとも１つの証明書（用途＝データ署名）およびゼロ以上のロールアサーションが供給される。一実施形態においては、ＮＥＭＯノードとして特定されるそれぞれのプリンシパルが、それぞれメッセージの完全性および機密性を支持するために、データ署名のための証明書および鍵暗号化のための証明書という少なくとも２つの証明書を有する。
【００４４】
好ましい実施形態においては、属性アサーションが、属性で埋められる。例えば、アサーションは、その対象（プリンシパル）について特定の情報を「アサート」する。アサーションへの信用は、その署名者（アサーション発行元）への信用にもとづく。属性アサーションは、１つ以上の属性で構成される。一実施形態においては、それぞれの属性が、名前およびゼロ以上の値を有している。ロールアサーションは、ただ１つの属性「ロール」および１つ以上の値（ロール名）を有するアサーションの簡単な場合である。一実施形態においては、すべての属性が、初期値として「ロール」属性名を備えている。１つの簡略化された実施形態においては、これが、信用管理において役割を果たすただ１つの属性である。一実施形態においては、設定の際に自己矛盾がないことを保証するために、プリンシパル信用状テーブルが、先に定められたロールのみを有効な属性アサーションとして選択できるようにプログラムされる。
【００４５】
図６の例のプリンシパル信任状テーブルを参照すると、プリンシパル「ＣＡ」は、「ＣＡ−Ｃｅｒｔ」として特定される１つの証明書、「ＣＡ」として特定される発行プリンシパル、「ＣＡ−Ｃｅｒｔ」として特定される発行証明書、および４という用途を有しており、ここで４＝証明書署名である。プリンシパル「ＲＡ」は、「ＲＡ−Ｃｅｒｔ」として特定される１つの証明書、「ＣＡ」として特定される発行プリンシパル、「ＣＡ−Ｃｅｒｔ」として特定される発行証明書、および１２８という用途を有しており、ここで１２８＝データ署名である。プリンシパル「ＲＡ」は、属性発行元としても特定される。
【００４６】
プリンシパル「リーフノード」は、２つの証明書「ＬｅａｆＮｏｄｅ−Ｃｅｒｔ」および「ＬｅａｆＮｏｄｅ−ＣｏｎｆｉｄｅｎｔｉａｌｉｔｙＣｅｒｔ」、ならびに１つのアサーション「ＬｅａｆＮｏｄｅ−ＬｅａｆＲｏｌｅ」を含んでいる。証明書「ＬｅａｆＮｏｄｅ−Ｃｅｒｔ」は、発行プリンシパル「ＣＡ」、発行証明書「ＣＡ−Ｃｅｒｔ」、および１２８という用途を有しており、「ＬｅａｆＮｏｄｅ−ＣｏｎｆｉｄｅｎｔｉａｌｉｔｙＣｅｒｔ」は、発行プリンシパル「ＣＡ」、発行証明書「ＣＡ−Ｃｅｒｔ」、および３２という用途を有しており、ここで３２＝暗号化である。１つの典型的な実施形態においては、発行証明書は、鍵用途４（証明書署名）を有する任意の証明書である。したがって、発行プリンシパルは、少なくとも１つの発行証明書を有するプリンシパルである。アサーション「ＬｅａｆＮｏｄｅ−ＬｅａｆＲｏｌｅ」は、発行プリンシパル「ＲＡ」およびすでに定めた「Ｌｅａｆ」ロールの属性を有している。一実施形態においては、用途フィールドにおいて、先に定義されたロールのみが有効な選択肢としてユーザに提示される。この特徴は、自己矛盾のない有効な設定へとユーザを案内するうえで役に立つ。
【００４７】
図６に示されている例では、プリンシパル「モニタノード」が、２つの証明書「ＭｏｎｉｔｏｒＮｏｄｅ−Ｃｅｒｔ」および「ＭｏｎｉｔｏｒＮｏｄｅ−ＣｏｎｆｉｄｅｎｔｉａｌｉｔｙＣｅｒｔ」、ならびに１つのアサーション「ＭｏｎｉｔｏｒＮｏｄｅ−ＭｏｎｉｔｏｒＲｏｌｅ」を含んでいる。証明書「ＭｏｎｉｔｏｒＮｏｄｅ−Ｃｅｒｔ」は、発行プリンシパル「ＣＡ」、発行証明書「ＣＡ−Ｃｅｒｔ」、および１２８という用途を有しており、「ＭｏｎｉｔｏｒＮｏｄｅ−ＣｏｎｆｉｄｅｎｔｉａｌｉｔｙＣｅｒｔ」は、発行プリンシパル「ＣＡ」、発行証明書「ＣＡ−Ｃｅｒｔ」、および３２という用途を有している。アサーション「ＭｏｎｉｔｏｒＮｏｄｅ−ＭｏｎｉｔｏｒＲｏｌｅ」は、発行プリンシパル「ＲＡ」およびすでに定めた「Ｍｏｎｉｔｏｒ」ロールの属性を有している。
【００４８】
一実施形態においては、拡張鍵使用が、信用設定エディタのツールバー１４に示されている「ＸＫＵ」ボタンを選択することによって起動される拡張鍵エディタを使用して定められる。図７は、「ＯＩＤ」カラムおよび「エイリアス」カラムを含んでいる拡張鍵エディタ５２の実施形態を示している。ＯＩＤカラムは、延長鍵使用のために有効なオブジェクト識別子（ＯＩＤ）を定める。エイリアスカラムは、ツールの各所において使用される短くてユーザフレンドリなエイリアスを定める。
【００４９】
再び図６を参照すると、プリンシパルＧＵＩ５０のプリンシパル信任状テーブルが、種々のプリンシパルおよび対応する信任状の間の関係を図式的に表示するために、プリンシパルおよび対応する信任状（証明書およびアサーション）をフォルダおよび下位フォルダを使用して階層的なやり方で整理する。さらに、信任状の設定可能な特性が、それぞれのプリンシパルについて図式的に表示される。プリンシパルおよび信任状の間の関係ならびに関連の信任状特性の図式的表示が、それぞれのプリンシパルを設定するためにプログラムコードを書き、あるいは構成コードの列を読み通して同様の関係および特性を解読しなければならないことに比べ、信用管理エディタをよりユーザフレンドリにする。
【００５０】
図６に示した例では、とくにはプリンシパルＧＵＩ５０において、ＡがＢを署名し、ＢがＣを署名し、ＣがＡを署名するなどの循環する依存関係を避けるために、プリンシパルの順序が重要である。したがって、利用可能な発行プリンシパルおよび発行証明書のリストであって、それぞれのプリンシパルの証明書について利用可能なリストが、先に生成されたプリンシパルのリスト（したがって、それらの信任状）から埋められる。
【００５１】
ノードＧＵＩ
ノードＧＵＩを起動するために、ノードタブ２６が選択される。図８が、ノードＧＵＩ６０が表示された状態の信用管理エディタの実施形態を示している。ノードは、システムの仕組みにおける参加者の表現である。ノードは、サービス消費者の役割および／またはサービス提供者の役割を含む複数のロールにて機能することができる。ノードは、家庭用電子機器、メディアプレイヤーなどのソフトウェアエージェント、あるいはコンテンツ検索エンジン、ＤＲＭライセンスプロバイダ、またはコンテンツロッカーなどの仮想サービス提供者、などといったさまざまな形態で実現することができる。ノードＧＵＩは、ノード（例えば、ＮＥＭＯノード）として機能するように指名されたプリンシパルについてロールバインディング（ｒｏｌｅ ｂｉｎｄｉｎｇ）を提示し、ノード間の相互作用を定義するようにユーザを促す。一実施形態において、ノードＧＵＩは、ノード定義テーブルおよびノード相互作用エディタを含んでいる。ノード定義テーブルは、プリンシパルＧＵＩ５０（図６を参照）においてＮＥＭＯノードとして指名されたプリンシパルについてロールバインディングを図式的に表わす。図８の例においては、ロールバインディングが、図３に関して説明した呼び出し元マトリクスに定められたロールの関係にもとづいて、クライアントまたはサービス・ロール・バインディングとして表わされている。例えば、所与のノードについて利用可能なクライアントおよび／またはサービスバインディングのリストは、プリンシパルの有する一式のＳＡＭＬアサーション、およびそれらのアサーションが定めるロールにもとづくことができる。次に、この例では、クライアントバインディング、サービスバインディング、または両者に使用することができるロールが、呼び出し元マトリクスに依存する（一実施形態において、同じロールを呼び出し元マトリクスにおいて「要求者」および「応答者」の両者として定義できることを思い出されたい）。本明細書において使用されるとき、用語「ノード」は、（例えば、信任状を使用して）他のノードとの相互作用に関与するプリンシパルを広く指す。
【００５２】
さらに、好ましい実施形態においては、信用管理エディタが、ノードを、それらの対応するプリンシパルが対応するロールアサーションによって設定されている場合にのみ、特定のロールについて設定できるようにする。これらの特徴の両方が、自己矛盾のない設定が確立されることを保証する。
【００５３】
一実施形態においては、それぞれのサービスまたはクライアント・ロール・バインディングが、プリンシパルのロールアサーションのうちの１つを参照する。ひとたび例示されると、サービス・ロール・バインディングが、所与のロールについて先に定義された各サービスについてのサービスバインディングによってあらかじめ自動的に埋められる。一実施形態においては、サービスバインディングを変更できるが、ロールの契約の破棄を構成しかねない除去または追加はできない。図５に関して上述したように、サービスＧＵＩ４０が、所与のロールにて動作するノードについて提示する必要のあるサービスを定める。一実施形態においては、ひとたび「サービス・ロール・バインディング」が所与のロール「Ｘ」について追加されると、ノードＧＵＩ６０のもとで所与のノードについて、以下のアサーションがなされる。すなわち、ａ）ノードが、ロール「Ｘ」を定めるＳＡＭＬアサーションを有し（自動的に検証される）；ｂ）ロール「Ｘ」が、「呼び出し元」マトリクスにおいて「応答者ロール」として少なくとも１回言及され（自動的に検証される）；ｃ）ノードが他のノードへとサービスを提供するためにこのＳＡＭＬアサーションを使用することを意図する。一実施形態においては、ロールの契約が、サービスロール「Ｘ」を受け入れることによって、ノードが所与のロール「Ｘ」についてサービスＧＵＩのもとで定められるサービスについて、それらの一部分だけでなくすべてを提供しなければならないと述べている。それは、ノードＧＵＩにおいて、所与のロール「Ｘ」についてのすべてのサービスバインディングの固定のリストを自動的に埋めることによって行使される。
【００５４】
一実施形態においては、それぞれのクライアント・ロール・バインディングが、所与のロールを有するクライアントが呼び出すことができなければならないそれぞれのサービスについてのクライアントバインディングによってあらかじめ自動的に埋められる。一実施形態においては、ロールバインディングをあらかじめ埋めることが、ａ）呼び出し元マトリクスから、ロール「Ｘ」が「要求者ロール」であるすべての組を発見し、すべての「応答者ロール」のリストを生成し、ｂ）サービスＧＵＩ４０から、それぞれの「応答者ロール」についてサービスのリストを得て、ｃ）すべてのサービスリストを１つの大きなリスト（これが、すべてのクライアントバインディングのリストである）へと組み合わせることを含む。一実施形態においては、「クライアントの契約」のようなものが存在しない。すなわち、ノードがクライアントロール「Ｘ」で行為できるというだけでは、ノードが、ノードが所与のクライアントロールによって接触できるすべてのサービスに接触しなければならないということにはならない。所与の種類の要求を発行できるということが、能力である一方で、任意の時点において所与の種類の要求に応答できるということは、義務である。例えば、クライアントが呼び出すことができるロール（したがって、サービス）は、図３に関して上述したロール呼び出し元マトリクス３４によって定められる。
【００５５】
一実施形態においては、それぞれのクライアントまたはサービスバインディングが、以下の特性に関して定義される。
ロールアサーション（Ｒｏｌｅ Ａｓｓｅｒｔｉｏｎ）−プリンシパルＧＵＩ５０において特定される対応するロールアサーションの名前。
サービス種類（Ｓｅｒｖｉｃｅ Ｔｙｐｅ）−サービスバインディングについては、このフィールドが、提示されるサービスの種類を特定する一方で、クライアントバインディングについては、このフィールドが、所与のクライアントによって呼び出すことができるサービスを特定する。
完全性Ｃｅｒｔ（Ｉｎｔｅｇｒｉｔｙ Ｃｅｒｔ）−メッセージ署名に使用された証明書の名前。
機密性Ｃｅｒｔ（Ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ Ｃｅｒｔ）−メッセージ暗号化に使用された証明書の名前。
メッセージングＴＡ（信用アンカ（Ｔｒｕｓｔ Ａｎｃｈｏｒ））−メッセージ署名および／または暗号化のためのピアの証明書を認証するために使用するために、証明書機関プリンシパルのうちの１つについて定められた信用アンカ証明書。
属性ＴＡ（信用アンカ）−ピアのロール署名証明書を認証するために使用される証明書機関プリンシパルのうちの１つについて定められた信用アンカ証明書。
信用ＡＡ（属性アサーション（Ａｔｔｒｉｂｕｔｅ Ａｓｓｅｒｔｉｏｎ）Ｃｅｒｔ−発行しているピアのロールによって信用されたプリンシパルの証明書。
【００５６】
図８の実施形態においては、ノードＧＵＩ６０が、種々のノードの間の関係およびそれらの対応するロールバインディングを図式的に表示するために、ノード、サービス・ロール・バインディング、およびクライアント・ロール・バインディングをフォルダおよび下位フォルダを使用して階層的なやり方で整理する。ノードの間の関係、サービス・ロール・バインディング、クライアント・ロール・バインディング、および関連のロールバインディング特性の図式的な表示は、構成コードの列を読み通して同様の関係および特性を解読しなければならないことに比べ、信用管理エディタをユーザフレンドリにする。
【００５７】
すべてのクライアントおよびサービスバインディングをリストにすることに加え、一実施形態において、ノードＧＵＩ６０は、それらのバインディングのそれぞれについて信用管理のポリシーを定める。それぞれのクライアントまたはサービスバインディングが、ａ）それのロールを証明するためにどのアサーションを使用するかを定め（親のロールバインディングから自動的に引き継がれる）、ｂ）メッセージ署名のためにどの証明書を使用するかを定め、ｃ）メッセージ暗号化のためにどの証明書を使用するかを定め、ｄ）やり取りの相手である他のモードのメッセージ証明書を認証するためにどの信用アンカ証明書を使用するか（メッセージング信用アンカ、またはＭＴＡ）を定め、ｅ）ロールアサーション署名証明書を認証するためにどの信用アンカ証明書を使用するか（属性信用アンカ、またはＡＴＡ）を定め、およびｆ）誰が信用されたロールアサーション署名者であるかを名前によって定める（信用属性機関、またはＴＡＡ）。一実施形態においては、ＴＡＡは随意である。多くの場合、ＡＴＡを使用してロールアサーション署名者ＴＡＡを認証できる限りにおいて、ＴＡＡは信用される。一実施形態においては、ノードＧＵＩが、有効な証明書の選択のみを提示し、暗号化および署名の証明書は、所与のプリンシパルのそれでなければならず（自身の固有のメッセージを署名または暗号化するために、自身の固有の証明書のみを使用することができる）、さらにはそれらが、対応する鍵用途（署名のための１２８、および暗号化のための３２）を有していなければならない。ＭＴＡおよびＡＴＡは、証明書の署名のために鍵用途４を有する別のプリンシパルの証明書でなければならない。ＴＡＡは、データ署名の鍵用途１２８を有し、さらに「プリンシパル」ＧＵＩにおいて「属性機関」としてマークされている証明書でなければならない。
【００５８】
ノードＧＵＩ６０の下部のノード相互作用エディタは、ユーザが互いに呼び出されるべきノードロールバインディング組を列挙することを可能にする。一実施形態においては、信用管理エンジンが、特定の要求者ノードのロールバインディングのもとで設定されたそれぞれのクライアントバインディングが、応答者ノードの所与のロールバインディングのもとで設定された対応するサービスバインディングを呼び出すことができるか否かをチェックし、ここで「呼び出すことができる」とは、それぞれのノードのバインディングについて設定された信任状のそれらの対応する信用管理ポリシーとの適合性を指す。一実施形態においては、列挙されたロールバインディング組が無効である場合に、速やかにユーザに通知される。一実施形態においては、設定エディタが、割り当てられた信任状の適合性をチェックすることによってロールバインディング組の有効性を判断する。例えば、一実施形態においては、それぞれの相互作用ペア｛クライアント・ロール・バインディングＡ、サービス・ロール・バインディングＢ｝について、以下が検証される。すなわち、ａ）バインディングＡについて定められるメッセージング信用アンカ（ＭＴＡ）証明書が、バインディングＢにおいて使用される署名および暗号化証明書の両者の先祖でなければならず、逆もまた同様でなければならず、ｂ）バインディングＡについて定められる属性信用アンカ（ＡＴＡ）が、バインディングＢにおいて使用されるロールアサーションの署名者の先祖でなければならず、逆もまた同様でなければならない。図８の実施形態においては、ノードＧＵＩの設定ステータスウインドウが、設定の有効性についての通知をもたらす。設定が無効である場合、設定エラーの表示が、設定ステータスウインドウに表示される。
【００５９】
再び図８のノードＧＵＩ６０を参照すると、設定について作業を行いつつ、任意の時点において、ＸＭＬタブ２８を選択することによって、生成された設定の基礎をなすＸＭＬ表現を閲覧することが可能である。表示されるＸＭＬドキュメントは編集可能であるが、直接の変更は、典型的には基礎をなす図式の知識を必要とするため、推奨されない。
【００６０】
ひとたびネットワーク設定が完了し、設定ステータスウインドウが設定が有効である旨を示すと、設定プロセスは完了する。設定を、将来の参照のためにローカルのファイルシステムに保存することができる。この時点で、開発者は、実装プロジェクトを生成するために設定ウィザードを続けることができる。
【００６１】
本明細書に記載の設定ツールは、ウェブサービス、デジタル著作権管理、および／または他のアプリケーションにおいて使用するための信用管理の仕組みの設定を簡単にする。信用管理の仕組みの設定が、一貫性について常に検証され、将来の参照のために保存することが可能である。
【００６２】
図９は、設定ツールの実施形態を実行するための例示のコンピュータシステム７０を示している。コンピュータシステムが、入力／出力７２、中央演算ユニット（ＣＰＵ）７４、データストレージ７６、およびシステムメモリ７８を含んでいる。入力／出力は、例えばディスプレイおよび／またはキーボードを含んでいる。ＣＰＵは、この技術分野において公知のとおり従来からの多機能プロセッサを含んでいる。データストレージは、例えば、磁気ディスクおよび／または光ディスク、ならびに／あるいは他の任意の適切なストレージ手段を備えている。データストレージは、この技術分野において公知のとおり、固定式であっても、リムーバブルであってもよい。システムメモリは、例えば、ＣＰＵによる実行または使用のための情報またはインストラクションを保存し、さらには／あるいはプロセッサによるインストラクションの実行中に一時変数または他の中間情報を保存するために、ランダム・アクセス・メモリ（ＲＡＭ）および読み出し専用メモリ（ＲＯＭ）の何らかの組み合わせを含むことができる。図９の実施形態においては、システムメモリが、オペレーティングシステム８０および上述の設定ツール８２を保存する。しかしながら、図９が説明の目的のために提示されたものであって、本発明を限定しようとするものではなく、追加の構成要素を備える他のコンピュータシステムおよび／または図９に示した構成要素の何らかの適切な部分集合も使用可能であることを、理解すべきである。実際、当業者であれば、例えばパーソナルコンピュータおよびメインフレームなど、実質的に任意の種類のコンピューティングシステムを使用できることを、理解できるであろう。
【００６３】
図１０が、図９の設定ツール８２の拡大図を示している。図１０に示した例においては、設定ツールが、ロールモジュール８４、サービスモジュール８６、プリンシパルモジュール８８、およびノードモジュール９０を含んでいる。一実施形態においては、それぞれのモジュールが、上述の機能ごとのＧＵＩに対応する機能を実行するための実行可能なインストラクションを含んでいる。さらに、設定ツールは、名前空間モジュール９２および拡張鍵使用モジュール９４を含んでいる。名前空間モジュールは、図４に関して上述したような名前空間エディタを実装するための実行可能なインストラクションを含んでおり、拡張鍵使用モジュールは、図７に関して上述したような拡張鍵エディタを実装するための実行可能なインストラクションを含んでいる。
【００６４】
機能ごとのＧＵＩを、別個の画面の眺めに表示されるものとして説明したが、機能ごとのＧＵＩを、種々の組み合わせにて同時に提示することも可能である。さらに、ＧＵＩの特定のレイアウトを提示したが、他のレイアウトも可能である。
【００６５】
図１１は、一実施形態に従って信用管理の仕組みを設定するための方法のプロセスフロー図である。ブロック１１０２において、ロールを定義するようにユーザを促すロールＧＵＩが提供される。ブロック１１０４において、ロールに対応するサービスを定義するようにユーザを促すサービスＧＵＩが提供される。ブロック１１０６において、ロールのうちの少なくとも１つをプリンシパルに関連付けるなど、プリンシパルを定義するようにユーザを促すプリンシパルＧＵＩが提供される。ブロック１１０８において、ノードとして機能するように指名されたプリンシパルについてロールバインディングを提示し、ノード間の相互作用を定義するようにユーザを促すノードＧＵＩが提供される。
【００６６】
信用管理の仕組みの設定のプロセスは、新たな信用管理の仕組みの設定、またはすでに設定済みの信用管理の仕組みの変更を含むことができる。
【００６７】
以上、分かり易さの目的のために或る程度詳しく説明を行ったが、その原理から離れることなく特定の変更および変形が可能であることは明らかであろう。なお、本明細書に記載のプロセスおよび装置の両者を実現するために、多数の別のやり方が存在する。したがって、これらの実施形態は、例示として理解すべきものであって、本発明を限定するものと理解してはならない。
【技術分野】
【０００１】
本出願は、２００６年８月１１日付の米国特許仮出願第６０／８２２，０６８号の利益を主張し、この米国特許仮出願を、ここでの言及によって援用する。
【０００２】
この特許文書の開示の一部は、著作権保護の対象となる題材を含んでいる。著作権者は、この特許文書または明細書を特許商標局のファイルまたは記録に表れるとおりに複製することについて異議を唱えないが、それ以外のあらゆる著作権の権利を留保する。
【背景技術】
【０００３】
ネットワークおよびコンピュータのセキュリティが重要さを増すにつれて、しっかりした信用管理の仕組みを設計および実装することが、ネットワークサービスおよび他のアプリケーションの生成において、より重要な部分となってきている。しかしながら、信用管理の仕組みの設計および実装は、そのような仕組みに頼るサービスおよびアプリケーションの機能に比較的無関係であることが多く、したがって、結果として、そのようなサービスおよびアプリケーションの設計者が、信用管理の仕組みを効率的かつ正しいやり方で設計および実装するための専門知識を欠いている可能性がある。
【０００４】
信用管理は、暗号法、公開鍵基盤、デジタル証明書（および、そのチェーニング）、セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）アサーション（例えば、ロールを定義するため）、などといった種々の基礎的要素の使用を伴う可能性がある。広く言えば、信用管理の仕組みは、典型的には、エンティティがなりすましではない真正なエンティティであることを確認するため、およびエンティティが当該エンティティに許された行為以外の行為を実行できないようにするために、システムがどのように振る舞うべきかを定めることである。自己矛盾のないセキュアな信用管理の仕組みを設定することは、所与のシステムにおいて、ロールおよび権限の重なり合うさまざまなエンティティが典型的に存在するため、複雑な仕事となる可能性がある。
【発明の概要】
【０００５】
ウェブサービス、デジタル著作権管理システム、および／または他のアプリケーションとともに使用するための信用管理の仕組みを容易に設定できるようにするためのシステムおよび方法が提示される。例えば、これに限られるわけではないが、本明細書に記載されるシステムおよび方法を、本出願と譲受人が同一である米国特許出願第１０／８６３，５５１号（米国特許出願公開第２００５／００２７８７１号）（「‘５５１号出願」）に記載されているメディアオーケストレーションのためのネットワーク環境（ＮＥＭＯ）というサービスオーケストレーション技術および／または本出願と譲受人が同一である米国特許出願第１１／５８３，６９３号（米国特許出願公開第２００７／０１８０５１９号）（「‘６９３号出願」）に記載の例えばセキュアなＤＲＭシステムを設計および実装するためのデジタル著作権管理（「ＤＲＭ」）技術などといった技術の使用に関係がある種々の利害関係者を助けるために使用することができる。‘５５１号出願および‘６９３号出願は、その全体がここでの言及によって本出願に取り入れられたものとされる。
【０００６】
一実施形態においては、ネットワーク環境において使用するための信用管理の仕組みを設定するための方法が、信用管理の仕組みの特定の態様を定義するようにユーザを促す種々のグラフィカル・ユーザ・インターフェイスをユーザへと提供することを含んでいる。とくには、ネットワーク環境において使用するための信用管理の仕組みを設定するための方法が、ロールを定義するようにユーザを促すロール・グラフィカル・ユーザ・インターフェイスを提供すること、ロールに対応するサービスを定義するようにユーザを促すサービス・グラフィカル・ユーザ・インターフェイスを提供すること、ロールのうちの少なくとも１つをプリンシパルに関連付けるなど、プリンシパルを定義するようにユーザを促すプリンシパル・グラフィカル・ユーザ・インターフェイスを提供すること、およびノードとして機能するように指名されたプリンシパルについてロールバインディングを提示し、ノード間の相互作用を定義するようにユーザを促すノード・グラフィカル・ユーザ・インターフェイスを提供することを含んでいる。一実施形態においては、この方法が、信用管理の仕組みが自己矛盾のないやり方で設定されることを保証する。例えば、多数の時点において、設定グラフィカル・ユーザ・インターフェイスが、選択の対象としての選択肢一式をユーザへと提示する。自己矛盾がないように保証するために、選択肢は、先の設定の決定にもとづき、有効な選択肢のみに限定される。
【０００７】
一実施形態においては、ネットワーク環境において使用するための信用管理の仕組みを設定するためのシステムが、ロールモジュール、サービスモジュール、プリンシパルモジュール、およびノードモジュールを含んでいる。ロールモジュールが、ロールを定義するようにユーザを促す。サービスモジュールが、ロールに対応するサービスを定義するようにユーザを促す。プリンシパルモジュールが、ロールのうちの少なくとも１つをプリンシパルに関連付けるなど、プリンシパルを定義するようにユーザを促し、ノードモジュールが、ノードとして機能するように指名されたプリンシパルについてロールバインディングを提示し、ノード間の相互作用を定義するようにユーザを促す。
【０００８】
本発明の諸作の他の態様および利点は、本発明の諸作の原理を例として示している添付の図面とともに検討される以下の詳細な説明から明らかになるであろう。
【図面の簡単な説明】
【０００９】
本発明の諸作を、以下の詳細な説明を添付の図面とともに参照することによって、より容易に理解できるであろう。添付の図面においては、同様の構成要素は、同様の参照番号によって指し示されている。
【００１０】
【図１】信用管理の仕組みを設定するための作業フローウィザードの例を示している。
【００１１】
【図２】ロール発行元の特定の属性を定めるためのロールＧＵＩを示している。
【００１２】
【図３】ロール呼び出し元の特定の属性を定めるためのロールＧＵＩを示している。
【００１３】
【図４】名前空間設定エディタを示している。
【００１４】
【図５】サービスを定義するためのサービスＧＵＩを示している。
【００１５】
【図６】プリンシパルおよびそれらの信任状を定義するためのプリンシパルＧＵＩを示している。
【００１６】
【図７】拡張鍵使用を定義するための拡張鍵使用エディタを示している。
【００１７】
【図８】ノードを定義するためのノードＧＵＩを示している。
【００１８】
【図９】設定ツールの実施形態を実施するためのコンピュータシステムの例を示している。
【００１９】
【図１０】図９の設定ツールの拡大図を示している。
【００２０】
【図１１】一実施形態に従って信用管理の仕組みを設定するための方法のプロセスフロー図である。
【発明を実施するための形態】
【００２１】
本発明の諸作を、以下で詳しく説明する。いくつかの実施形態を説明するが、本発明の諸作が、いずれかの実施形態に限定されるわけではなく、多数の代案、変更物、および均等物を包含することを理解すべきである。さらに、以下の説明においては、本発明の諸作の完全な理解をもたらすために、多数の具体的な詳細を記載するが、いくつかの実施形態は、そのような詳細の一部またはすべてを欠いても実施可能である。さらに、分かり易さの目的で、該当の技術分野において公知である特定の技術的題材については、本発明の諸作を不必要に曖昧にしてしまうことがないよう、詳しい説明を省略する。
【００２２】
ウェブサービス、デジタル著作権管理システム、および／または他のアプリケーションにおいて使用するための信用管理の仕組みを容易に設定できるようにするためのシステムおよび方法が提示される。例えば、これに限られるわけではないが、本明細書に記載されるシステムおよび方法を、‘５５１号出願に記載されているメディアオーケストレーションのためのネットワーク環境（ＮＥＭＯ）というサービスオーケストレーション技術および／または例えばセキュアなＤＲＭシステムを設計および実装するための‘６９３号出願に記載のデジタル著作権管理技術などといった技術の採用に関係がある種々の利害関係者を助けるために使用することができる。このようなシステムおよび方法が新規であり、そこで使用される構成要素、システム、および方法の多くも新規であることを、理解できるであろう。
【００２３】
‘５５１号出願にさらに詳しく記載されているとおり、信用管理は、暗号法、公開鍵基盤、デジタル証明書（および、そのチェーニング）、セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）アサーション（例えば、ロールを定義するため）、などといった種々の基礎的要素の使用を伴う可能性がある。広く言えば、信用管理の仕組みは、典型的には、エンティティがなりすましではない真正なエンティティであることを確認するため、およびエンティティが当該エンティティに許された行為以外の行為を実行できないようにするために、システムがどのように振る舞うべきかを定めることに関係する。自己矛盾のないセキュアな信用管理の仕組みを定めることは、所与のシステムにおいて、ロールおよび権限の重なり合うさまざまなエンティティが典型的に存在するため、複雑な仕事となる可能性がある。
【００２４】
好ましい実施形態においては、ウェブサービス、デジタル著作権管理システム、および／またはアプリケーションプログラムなどにおいて使用される信用管理の仕組みを容易に設定できるようにするために、設定ツール（本明細書において、単に「ツール」と称されることもある）が使用される。設定ツールの実施形態は、複雑なネットワーク（‘５５１号出願に記載のネットワーク、および／または他の任意の適切なネットワーク）を種々のシステム構成要素間の関係をより容易に把握できるようにする直感的かつグラフィカルな形態で表わすうえで、有用となりうる。
【００２５】
設定ツールの実施形態は、信用管理の仕組みを設定するときに内部整合性について信用管理の仕組みを常に検証することによって、さらには設定を曖昧さがなくかつコンピュータおよび人間にとって読解可能な形態で把握することによって、システム設計者を助けることができる。
【００２６】
設定ツールの実施形態は、システム設計者の生産性を向上させることができる。設計プロセスによって生成されるネットワークモデルから、すべてのＮＥＭＯプリンシパルについてすべての信用管理信任状を自動的に生成するために、設定ツールを使用することができる。いくつかの実施形態においては、設定ツールを、迅速に実現できる実装がモデルによって定められるとおりにＮＥＭＯノード間のライブなやり取りを実行できるよう、モデルによって暗示されるアプリケーションおよびサービスのためのスタブコードを有するデフォルトのＪａｖａ（登録商標）ベースのプロジェクトを生成するために使用することも可能である。このように、設定ツールの実施形態は、機能する基本機能を迅速に得るために開発者を助けることができ、したがって開発者が、設定ツールがないならば開発の労力の大きな部分を費やすことになりかねない信用管理の問題について知らないままで、ＮＥＭＯサービスおよび民生用アプリケーションのためのビジネスロジックの実装に集中できるようにする。
【００２７】
一実施形態においては、設定ツールが、信用管理の仕組みの設定においてユーザを案内する信用管理エディタを含んでいる。図１が、新たな信用管理の仕組みの設定または既存の信用管理の仕組みの設定の変更をユーザにとって可能にする作業フロー・ウィザード・ダイアログ１０の例を示している。図１に示した例では、作業フローウィザードの「作成」ボタン１２を選択すると、アプリケーションドメイン設定エディタ（本明細書において、信用管理エディタとも称される）がユーザへと提示される。
【００２８】
好ましい実施形態においては、信用管理エディタは、機能ごとのグラフィカル・ユーザ・インターフェイス（ＧＵＩ）によってユーザへと提示される４つの主モジュールを含んでいる。機能ごとのＧＵＩは、ロールＧＵＩ、サービスＧＵＩ、プリンシパルＧＵＩ、およびノードＧＵＩを含む。信用管理エディタの実施形態を、図２〜８を参照して説明する。図２を参照すると、信用管理エディタは、ツールバー１４ならびに機能ごとのタブ２０、２２、２４、２６、および２８を含んでいる。ツールバーは、例えばファイル管理の操作などといった共通のアプリケーション操作、ならびに名前空間（ＮＳ）および拡張鍵用途（ＸＫＵ）操作などといったいくつかのアプリケーション特有の操作へのアクセスを提供する。機能ごとのタブは、機能ごとのＧＵＩを起動するために使用される。機能ごとのＧＵＩおよびそれらに関する機能を、図２〜８を参照して後述する。
【００２９】
ロールＧＵＩ
図２が、ロールＧＵＩ３０が表示されている状態の信用管理エディタの実施形態を示している。ロールＧＵＩは、ロールを定義するようにユーザを促す。一実施形態においては、ロールは、所与のピアが特定の挙動パターンとの組み合わせにおいて呈する一式のサービスである。この実施形態においては、ロールＧＵＩが、「ロール」カラムと標識された左カラムと「エイリアス」カラムと標識された右カラムとを有する２列のロール名エディタを含んでいる。「ロール」カラムは、ロール名のリストで埋められるように構成され、「エイリアス」カラムは、対応するロールエイリアスで埋められるように構成されている。好ましい実施形態においては、ロールエイリアスが随意であり、定義される場合には、ロール名を短縮形で表示するために使用される。図２の実施形態においては、「リーフ（Ｌｅａｆ）」ロールおよび「モニタ（Ｍｏｎｉｔｏｒ）」ロールとして特定されるロールが定義されている。この例において、リーフロールは、サービスを提供しないクライアントのみのロールであり、モニタロールは、１つのサービス（さらに詳しくは、後述）を提供するロールである。
【００３０】
図２に示した実施形態においては、ロールＧＵＩが、発行元（ｉｓｓｕｒｅ）タブおよび呼び出し元（ｉｎｖｏｋｅｒ）タブをさらに含んでおり、これらが選択されると、対応する発行元マトリクスまたは呼び出し元マトリクスがユーザに提示される。図２は、発行元マトリクス３２が選択された状態のロールＧＵＩを示している。発行元マトリクスは、どのロールがどのロールをアサート（ａｓｓｅｒｔ）できるのかを定義するために使用される。一実施形態においては、ロールアサーションが、プリンシパルがロール「Ｙ」のロールアサーションを他のプリンシパルへと発行する資格を有するために、どのロール「Ｘ」を保有していなければならないかを特定する。例えば、「Ｘ」が「発行元ロール」に相当する一方で、「Ｙ」が「対象（ｓｕｂｊｅｃｔ）ロール」に相当する。図２の実施形態において、発行元マトリクスは、ｘ軸に発行元ロールを、ｙ軸に対象ロールを含んでおり、マトリクスのそれぞれの軸が、ロール名エディタに定められたそれぞれのロールによって自動的に埋められる。ロール間の相互作用が、発行元ロールと対象ロールとの間の交点にマーキングを施すことによって特定され、図２の実施形態においては、発行元ロールと対象ロールとの間の交点のマーキングが、マーキング付きの発行元ロールがマーキング付きの対象ロールをアサートできることを定義している。すなわち、発行元ロールと対象ロールとの間の交点のマーキングが、ロール発行元が、ｙ軸に示されている対象ロールをアサートするために、ｘ軸に示されているどのロールを有していなければならないかを示している。なお、図２に示した実施形態において、定義されたロールのうちの一部のみがロール発行元へと期せずして一致し、他のロールが、種々のＮＥＭＯサービスへのアクセスを許可するためにＮＥＭＯノードによって使用されるロールを参照できる。これは、一実施形態においては、「発行元」および「呼び出し元」という２つの別個のマトリクスをもたらす「ロール」の概念の過負荷に起因する。後者は、異なるロールを実行するノード間の相互作用（呼び出し）を記載する。前者は、それらのロールがそもそもどのように割り当てられるかである。ロールは、ときには両方の機能を有する。例えば、ロール「Ａ」を有するサービスが、ロール「Ｂ」のアサーションをロール「Ｃ」を有するクライアントへと発行することができる。この例では、発行元マトリクスが｛「Ａ」，「Ｂ」｝の組を定め、ロール「Ａ」がロール「Ｂ」をアサートできる旨を示す。同時に、「呼び出し元」マトリクスが｛「Ｃ」，「Ａ」｝の組を定め、ロール「Ｃ」を有するクライアントが、最も自然には、所与の信用管理エコシステムにおける参加者としてより多くの能力を得るため、新たなロール「Ｂ」のアサーションを許可するように求めるために、ロール「Ａ」を有するサービスに接触できることを意味する。
【００３１】
図３は、呼び出し元マトリクスが選択された状態のロールＧＵＩ３０を示している。呼び出し元マトリクス３４は、要求者（Ｒｅｑｕｅｓｔｅｒ）ロールと応答者（Ｒｅｓｐｏｎｄｅｒ）ロールとの間の関係を定義するために使用される。図３の実施形態においては、呼び出し元マトリクスが、ｙ軸に要求者ロールを、ｘ軸に応答者ロールを含んでおり、やはりマトリクスのそれぞれの軸が、ロール名エディタに定められたそれぞれのロールによって自動的に埋められる。ロール間の相互作用が、要求者ロールと応答者ロールとの間の交点にマーキングを施すことによって特定され、図３の実施形態においては、要求者ロールと応答者ロールとの間の交点のマーキングが、マーク付きの要求者ロールがマーク付きの応答者ロールを呼び出すことができる旨を示している。すなわち、要求者ロールと応答者ロールとの間の交点のマーキングが、或るノードにとって、ｙ軸に特定されるロールにて行為している別のノードのサービスを呼び出すために、ｘ軸に特定されるどのロールが必要であるのかを定めている。図３の例では、チェック付きの四角が、リーフロール（要求者）がモニタロール（応答者）を呼び出すことができる旨を示している。
【００３２】
ロールＧＵＩによれば、ユーザは、任意のロールに名前を付けること、およびロール間の関係を任意のやり方で定めることを、自由に行うことができる。後述されるとおり、発行元マトリクスおよび呼び出し元マトリクスに指定される関係が、後の設定作業に反映される。マトリクスによって図式的に表現されるロール間の関係のグラフィカルな表現が、信用管理ツールをユーザフレンドリにする特徴の１つである。ロールＧＵＩが、ロール間の関係を図式的に表現するために図２および３に示したような発行元マトリクスおよび呼び出し元マトリクスを使用しているが、他の表現形態も可能である。
【００３３】
ひとたびロールに名前が付けられ、ロールの関係が指定されると、それらのロールについてサービスを設定することができる。一実施形態においては、ロールごとのサービスを設定する前に、ユーザは、名前空間設定エディタを起動するように促される。名前空間設定エディタは、サービスおよびそれらの動作について定義されるすべての要求および応答のメッセージペイロードのスキーマタイプについて、名前空間を定めるようにユーザを促す。図４が、信用設定エディタ（図２および３を参照）のツールバーの「ＮＳ」ボタンを押すことによって起動される名前空間設定エディタ３８の実施形態を示している。図４の実施形態においては、名前空間設定エディタが、「エイリアス」、「名前空間」、および「スキーマ位置」の各カラムを含んでいる。「エイリアス」カラムは、それぞれの名前空間についてエイリアスを定めるために使用され、「名前空間」カラムは、ＸＭＬスキーマの名前空間を定めるために使用され、「スキーマ位置」カラムは、該当の名前空間のためのスキーマの位置を定めるために使用される。ひとたび名前空間が設定されると、ユーザは、「ＯＫ」ボタンを選択することによってアクティブな機能ごとのＧＵＩへと戻る。
【００３４】
サービスＧＵＩ
一実施形態においては、ロールおよび名前空間が定義された後に、サービスＧＵＩを起動すべくサービスタブ２２が選択される。図５が、サービスＧＵＩ４０が表示された状態の信用管理エディタの実施形態を示している。サービスＧＵＩは、ロールＧＵＩによって定義した各ロールに対応するサービスを定めるようにユーザを促すサービスエディタを含んでいる。サービスは、応答者ノードによって提示または提供される１式の特定の機能の表現を包んでいる。一実施形態においては、サービスＧＵＩが、ロールＧＵＩ３０によって先に定められたロール（例えば、図３において定義された「リーフ」およ「モニタ」ロール）で埋められる。それぞれのロールについて、ユーザは、該当のロールを有するノードによって提示されるサービス一式を定義することができる。なお、一部のロールは、発行元ロールまたはクライアントのみのロールであるがため、対応するサービスを持たなくてもよい。図５に示した典型的なサービスは、「存在（Ｐｒｅｓｅｎｃｅ）」サービスであり、その機能は、ノードが利用可能であることを保証することである。なお、ロールに関連付けられるサービスの数および種類がアプリケーションに特有である。特定のサービスに関連付けられるソフトウェアコードは、サービス特有のソフトウェアモジュールにおいて具現化される。ピア−トゥ−ピアのやり取りのためのサービスモジュールの開発は、例えば‘５５１号出願に説明されている。
【００３５】
それぞれのサービスは、１つ以上の対応する動作を有することができ、それぞれの動作は、定義することができる異なるメッセージング特性を有することができる。図５の実施形態においては、サービスＧＵＩ４０が、信用管理に関する特定のメッセージング特性を定めるようにユーザを促す。特性がカラムに整理され、カラムにおいて、ユーザが特定の指定を行うことができる。図５のサービスＧＵＩに示されている特定のメッセージング特性は、以下のとおりである。
（ａ）「エレメント（Ｅｌｅｍｅｎｔ）」フィールド−メッセージペイロードのＸＭＬスキーマタイプを表わしているＸＭＬエレメントタイプ。
（ｂ）「インテグリティ（Ｉｎｔｅｇｒｉｔｙ）」チェックボックス−メッセージの完全性が保護されていなければならないか否か（例えば、デジタル署名されていなければならないか否か）を示している。
（ｃ）「機密性（Ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ）」チェックボックス−メッセージが機密でなければならないか否か（例えば、暗号化されていなければならないか否か）を示している。
（ｄ）「タイムスタンプ（Ｔｉｍｅｓｔａｍｐ）」チェックボックス−メッセージにタイムスタンプが付与されていなければならないか否かを示している。
（ｅ）「ナンス（Ｎｏｎｃｅ）」チェックボックス−メッセージが唯一性を保証するためにナンス（一度だけの数字）を含んでいなければならないか否かを示している。
【００３６】
図５の実施形態においては、サービスＧＵＩ４０が、ロール、対応するサービス、および対応する動作を、種々のロール、対応するサービス、および対応する動作の間の関係を図式的に表示するために、フォルダおよび下位フォルダを使用して階層的なやり方で整理する。ロール、サービス、および動作の間の関係ならびに関連のメッセージング特性の図式的表示が、新しいサービスのそれぞれについてサービス関連のコードを書き、構成コードの列を読み通して同様の関係および特性を解読しなければならないことに比べ、信用管理エディタをよりユーザフレンドリにする特徴の１つである。
【００３７】
プリンシパルＧＵＩ
プリンシパルＧＵＩを起動するために、プリンシパルタブ２４が選択される。図６が、プリンシパルＧＵＩ５０が表示された状態の信用管理エディタの実施形態を示している。一実施形態においては、プリンシパルは、固有のアイデンティティを有するエンティティである。すなわち、プリンシパルは、大まかに、単一のアイデンティティの概念に対応するが、このアイデンティティが確立されるやり方は、ドメイン特有である。例えば、Ｘ．５０９の証明書およびＳＡＭＬのアサーションの両者が、それらの宛て先としての「対象」の概念を有している。対象の名前が、そのような信任状の中身の一部であり、所与のプリンシパルについて同じでなければならない。しかしながら、他の信任状は、例えば秘密鍵など、対象を有していないかもしれない。ひとたび秘密の信任状が漏れると、このプリンシパルは、なりすましの対象となりうる。
【００３８】
プリンシパルＧＵＩ５０は、先に定義されたロールのうちの少なくとも１つをプリンシパルに組み合わせ、プリンシパルに信用管理の仕組みにおけるそれらの意図される用途に適した信用状を供給するなど、信用管理の仕組みのプリンシパルを定めるようにユーザを促す。図６の実施形態においては、プリンシパルＧＵＩが、プリンシパル名エディタおよびプリンシパル信任状エディタを含んでいる。プリンシパル名エディタは、「名前」カラム、「ＵＲＮ」カラム、「ＮＥＭＯノード」カラム、および「取り込み（Ｉｍｐｏｒｔｅｄ）」カラムを含んでいる。プリンシパル名エディタの各カラムは、定義されたそれぞれのプリンシパルについて以下の情報を特定するようにユーザを促す。
名前−ツールの各所において当該プリンシパルを指して使用される短くてユーザフレンドリな名前。
ＵＲＮ−該当のプリンシパルへと発行／該当のプリンシパルによって発行される信任状に使用されるユニフォーム・リソース・ネーム（ＵＲＮ）。
Ｎｅｍｏノード−該当のプリンシパルがＮＥＭＯノードであるか否か。プリンシパルがＮＥＭＯノードでない場合、一実施形態においては、プリンシパルは信用状発行元のみでなければならない。
【００３９】
取り込み−該当のプリンシパルが、設計されるシステムの一部として定義または準備しなければならない内部プリンシパルか、あるいは信任状を取り込んで設計されるシステムの内部で使用しなければならない既存の外部プリンシパルであるか否か。この例は、信用管理の仕組みの全体を一から設定することを説明しているため、この四角には、この例ではチェックが入れられていない。
【００４０】
一実施形態においては、プリンシパル名エディタが、プリンシパルを何回複製すべきかを特定するようにユーザを促すカラムを含むことができる。さらなる実施形態においては、プリンシパル名テーブルが、複製されるべきプリンシパルのための開始識別子など、さらなる複製情報を含むことができる。プリンシパルを複製すべき場合には、プリンシパルのＵＲＮが、どこに固有の識別子を挿入すべきかを示す浮動文字を含むことができる。例えば、プリンシパルをＩＤ＝１から出発して１００回複製すべき場合には、それぞれのプリンシパルは、ＩＤ以外は同じＵＲＮを、１〜１００の範囲の１００個の異なるプリンシパルのＩＤとともに含むＵＲＮを有する。この特徴を、異なるＵＲＮをそれぞれ必要とする複数の同様の装置が生成される実働環境に適用することができる。
【００４１】
図６の例では、プリンシパル「ＣＡ」、「ＲＡ」、「リーフノード」、および「モニタノード」が定められている。この例では、プリンシパルＣＡは、認証機関として機能するように定められ、プリンシパルＲＡは、ロールアサーション機関として機能するように定められる。例えば、他の証明書に署名することができる１つ以上の証明書を有するプリンシパルは、ＣＡである（Ｘ．５０９証明書においては、ｋｅｙ ｕｓａｇｅ ４−「ｃｅｒｔｉｆｉｃａｔｅ ｓｉｇｎｉｎｇ」）。データ署名が可能な１つ以上の証明書（ｋｅｙ ｕｓａｇｅ １２８−「ｄａｔａ ｓｉｇｎｉｎｇ」）およびこの証明書を有するプリンシパルは、ＧＵＩにおいて属性発行元としてマークされ、ロール機関（ＲＡ）となる。したがって、プリンシパルは、その能力をその信任状から得る。プリンシパル「リーフノード」は、リーフロールを実行するために定められ、プリンシパル「モニタノード」は、モニタロールを実行するために定められる。
【００４２】
一実施形態においては、プリンシパル名エディタにおいて定義されたプリンシパルの信任状が、プリンシパル信任状エディタによって定義される。好ましい実施形態においては、証明書およびアサーションという２種類の信任状が存在し、例えば証明書が、名前を公開鍵へとバインド（ｂｉｎｄ）し、アサーションが、名前をロールへとバインドする。図６の実施形態においては、プリンシパルＧＵＩ５０が、以下の特性に関してプリンシパルの信任状を特定するようにユーザを促す。
発行プリンシパル（Ｉｓｓｕｉｎｇ Ｐｒｉｎｃｉｐａｌ）−証明書を発行するプリンシパル。
発行証明書（Ｉｓｓｕｉｎｇ Ｃｅｒｔｉｆｉｃａｔｅ）−現在の証明書を発行した証明書の名前。
属性発行元（Ａｔｔｒｉｂｕｔｅ Ｉｓｓｕｅｒ）−当該証明書が属性発行元として機能できるか否か。
用途（Ｕｓａｇｅ）−どの証明書を使用できるかを表わすコード値（例えば、Ｘ．５０９証明書における標準列挙キー使用）。
値（Ｖａｌｕｅ）−それぞれの証明書について拡張鍵使用を定める。例えば、一実施形態においては、値フィールドは、それぞれの信任状の種類についてさらに詳細な情報を有するポップアップダイアログを生じさせるコンテクスト依存のフィールドであってよい。証明書については、値フィールドは、鍵使用、使用期限、ＸＫＵ、などの情報を提供できる。ＳＡＭＬアサーションについては、値フィールドは、すべての属性名およびそれらの値のリスト、有効期間、などを含むことができる。
供給（Ｐｒｏｖｉｓｉｏｎｅｄ）−プリンシパルにこれらの信用状が最初に供給されたのか、あるいはフィールドにおける操作において取得されたのかを示す。
【００４３】
一実施形態においては、証明書機関として使用されるように意図されたそれぞれのプリンシパルに、証明書発行のための鍵用途を有する少なくとも１つの証明書（例えば、用途＝証明書発行）が供給される。証明書名は、ツールの各所で参照のために使用される短いユーザフレンドリな名前として選択されるべきである。ロール発行元として使用されるように意図されたそれぞれのプリンシパルには、いくつかのロール発行ルールが前もって定められている場合には、ロール署名のための少なくとも１つの証明書（用途＝データ署名）およびゼロ以上のロールアサーションが供給される。一実施形態においては、ＮＥＭＯノードとして特定されるそれぞれのプリンシパルが、それぞれメッセージの完全性および機密性を支持するために、データ署名のための証明書および鍵暗号化のための証明書という少なくとも２つの証明書を有する。
【００４４】
好ましい実施形態においては、属性アサーションが、属性で埋められる。例えば、アサーションは、その対象（プリンシパル）について特定の情報を「アサート」する。アサーションへの信用は、その署名者（アサーション発行元）への信用にもとづく。属性アサーションは、１つ以上の属性で構成される。一実施形態においては、それぞれの属性が、名前およびゼロ以上の値を有している。ロールアサーションは、ただ１つの属性「ロール」および１つ以上の値（ロール名）を有するアサーションの簡単な場合である。一実施形態においては、すべての属性が、初期値として「ロール」属性名を備えている。１つの簡略化された実施形態においては、これが、信用管理において役割を果たすただ１つの属性である。一実施形態においては、設定の際に自己矛盾がないことを保証するために、プリンシパル信用状テーブルが、先に定められたロールのみを有効な属性アサーションとして選択できるようにプログラムされる。
【００４５】
図６の例のプリンシパル信任状テーブルを参照すると、プリンシパル「ＣＡ」は、「ＣＡ−Ｃｅｒｔ」として特定される１つの証明書、「ＣＡ」として特定される発行プリンシパル、「ＣＡ−Ｃｅｒｔ」として特定される発行証明書、および４という用途を有しており、ここで４＝証明書署名である。プリンシパル「ＲＡ」は、「ＲＡ−Ｃｅｒｔ」として特定される１つの証明書、「ＣＡ」として特定される発行プリンシパル、「ＣＡ−Ｃｅｒｔ」として特定される発行証明書、および１２８という用途を有しており、ここで１２８＝データ署名である。プリンシパル「ＲＡ」は、属性発行元としても特定される。
【００４６】
プリンシパル「リーフノード」は、２つの証明書「ＬｅａｆＮｏｄｅ−Ｃｅｒｔ」および「ＬｅａｆＮｏｄｅ−ＣｏｎｆｉｄｅｎｔｉａｌｉｔｙＣｅｒｔ」、ならびに１つのアサーション「ＬｅａｆＮｏｄｅ−ＬｅａｆＲｏｌｅ」を含んでいる。証明書「ＬｅａｆＮｏｄｅ−Ｃｅｒｔ」は、発行プリンシパル「ＣＡ」、発行証明書「ＣＡ−Ｃｅｒｔ」、および１２８という用途を有しており、「ＬｅａｆＮｏｄｅ−ＣｏｎｆｉｄｅｎｔｉａｌｉｔｙＣｅｒｔ」は、発行プリンシパル「ＣＡ」、発行証明書「ＣＡ−Ｃｅｒｔ」、および３２という用途を有しており、ここで３２＝暗号化である。１つの典型的な実施形態においては、発行証明書は、鍵用途４（証明書署名）を有する任意の証明書である。したがって、発行プリンシパルは、少なくとも１つの発行証明書を有するプリンシパルである。アサーション「ＬｅａｆＮｏｄｅ−ＬｅａｆＲｏｌｅ」は、発行プリンシパル「ＲＡ」およびすでに定めた「Ｌｅａｆ」ロールの属性を有している。一実施形態においては、用途フィールドにおいて、先に定義されたロールのみが有効な選択肢としてユーザに提示される。この特徴は、自己矛盾のない有効な設定へとユーザを案内するうえで役に立つ。
【００４７】
図６に示されている例では、プリンシパル「モニタノード」が、２つの証明書「ＭｏｎｉｔｏｒＮｏｄｅ−Ｃｅｒｔ」および「ＭｏｎｉｔｏｒＮｏｄｅ−ＣｏｎｆｉｄｅｎｔｉａｌｉｔｙＣｅｒｔ」、ならびに１つのアサーション「ＭｏｎｉｔｏｒＮｏｄｅ−ＭｏｎｉｔｏｒＲｏｌｅ」を含んでいる。証明書「ＭｏｎｉｔｏｒＮｏｄｅ−Ｃｅｒｔ」は、発行プリンシパル「ＣＡ」、発行証明書「ＣＡ−Ｃｅｒｔ」、および１２８という用途を有しており、「ＭｏｎｉｔｏｒＮｏｄｅ−ＣｏｎｆｉｄｅｎｔｉａｌｉｔｙＣｅｒｔ」は、発行プリンシパル「ＣＡ」、発行証明書「ＣＡ−Ｃｅｒｔ」、および３２という用途を有している。アサーション「ＭｏｎｉｔｏｒＮｏｄｅ−ＭｏｎｉｔｏｒＲｏｌｅ」は、発行プリンシパル「ＲＡ」およびすでに定めた「Ｍｏｎｉｔｏｒ」ロールの属性を有している。
【００４８】
一実施形態においては、拡張鍵使用が、信用設定エディタのツールバー１４に示されている「ＸＫＵ」ボタンを選択することによって起動される拡張鍵エディタを使用して定められる。図７は、「ＯＩＤ」カラムおよび「エイリアス」カラムを含んでいる拡張鍵エディタ５２の実施形態を示している。ＯＩＤカラムは、延長鍵使用のために有効なオブジェクト識別子（ＯＩＤ）を定める。エイリアスカラムは、ツールの各所において使用される短くてユーザフレンドリなエイリアスを定める。
【００４９】
再び図６を参照すると、プリンシパルＧＵＩ５０のプリンシパル信任状テーブルが、種々のプリンシパルおよび対応する信任状の間の関係を図式的に表示するために、プリンシパルおよび対応する信任状（証明書およびアサーション）をフォルダおよび下位フォルダを使用して階層的なやり方で整理する。さらに、信任状の設定可能な特性が、それぞれのプリンシパルについて図式的に表示される。プリンシパルおよび信任状の間の関係ならびに関連の信任状特性の図式的表示が、それぞれのプリンシパルを設定するためにプログラムコードを書き、あるいは構成コードの列を読み通して同様の関係および特性を解読しなければならないことに比べ、信用管理エディタをよりユーザフレンドリにする。
【００５０】
図６に示した例では、とくにはプリンシパルＧＵＩ５０において、ＡがＢを署名し、ＢがＣを署名し、ＣがＡを署名するなどの循環する依存関係を避けるために、プリンシパルの順序が重要である。したがって、利用可能な発行プリンシパルおよび発行証明書のリストであって、それぞれのプリンシパルの証明書について利用可能なリストが、先に生成されたプリンシパルのリスト（したがって、それらの信任状）から埋められる。
【００５１】
ノードＧＵＩ
ノードＧＵＩを起動するために、ノードタブ２６が選択される。図８が、ノードＧＵＩ６０が表示された状態の信用管理エディタの実施形態を示している。ノードは、システムの仕組みにおける参加者の表現である。ノードは、サービス消費者の役割および／またはサービス提供者の役割を含む複数のロールにて機能することができる。ノードは、家庭用電子機器、メディアプレイヤーなどのソフトウェアエージェント、あるいはコンテンツ検索エンジン、ＤＲＭライセンスプロバイダ、またはコンテンツロッカーなどの仮想サービス提供者、などといったさまざまな形態で実現することができる。ノードＧＵＩは、ノード（例えば、ＮＥＭＯノード）として機能するように指名されたプリンシパルについてロールバインディング（ｒｏｌｅ ｂｉｎｄｉｎｇ）を提示し、ノード間の相互作用を定義するようにユーザを促す。一実施形態において、ノードＧＵＩは、ノード定義テーブルおよびノード相互作用エディタを含んでいる。ノード定義テーブルは、プリンシパルＧＵＩ５０（図６を参照）においてＮＥＭＯノードとして指名されたプリンシパルについてロールバインディングを図式的に表わす。図８の例においては、ロールバインディングが、図３に関して説明した呼び出し元マトリクスに定められたロールの関係にもとづいて、クライアントまたはサービス・ロール・バインディングとして表わされている。例えば、所与のノードについて利用可能なクライアントおよび／またはサービスバインディングのリストは、プリンシパルの有する一式のＳＡＭＬアサーション、およびそれらのアサーションが定めるロールにもとづくことができる。次に、この例では、クライアントバインディング、サービスバインディング、または両者に使用することができるロールが、呼び出し元マトリクスに依存する（一実施形態において、同じロールを呼び出し元マトリクスにおいて「要求者」および「応答者」の両者として定義できることを思い出されたい）。本明細書において使用されるとき、用語「ノード」は、（例えば、信任状を使用して）他のノードとの相互作用に関与するプリンシパルを広く指す。
【００５２】
さらに、好ましい実施形態においては、信用管理エディタが、ノードを、それらの対応するプリンシパルが対応するロールアサーションによって設定されている場合にのみ、特定のロールについて設定できるようにする。これらの特徴の両方が、自己矛盾のない設定が確立されることを保証する。
【００５３】
一実施形態においては、それぞれのサービスまたはクライアント・ロール・バインディングが、プリンシパルのロールアサーションのうちの１つを参照する。ひとたび例示されると、サービス・ロール・バインディングが、所与のロールについて先に定義された各サービスについてのサービスバインディングによってあらかじめ自動的に埋められる。一実施形態においては、サービスバインディングを変更できるが、ロールの契約の破棄を構成しかねない除去または追加はできない。図５に関して上述したように、サービスＧＵＩ４０が、所与のロールにて動作するノードについて提示する必要のあるサービスを定める。一実施形態においては、ひとたび「サービス・ロール・バインディング」が所与のロール「Ｘ」について追加されると、ノードＧＵＩ６０のもとで所与のノードについて、以下のアサーションがなされる。すなわち、ａ）ノードが、ロール「Ｘ」を定めるＳＡＭＬアサーションを有し（自動的に検証される）；ｂ）ロール「Ｘ」が、「呼び出し元」マトリクスにおいて「応答者ロール」として少なくとも１回言及され（自動的に検証される）；ｃ）ノードが他のノードへとサービスを提供するためにこのＳＡＭＬアサーションを使用することを意図する。一実施形態においては、ロールの契約が、サービスロール「Ｘ」を受け入れることによって、ノードが所与のロール「Ｘ」についてサービスＧＵＩのもとで定められるサービスについて、それらの一部分だけでなくすべてを提供しなければならないと述べている。それは、ノードＧＵＩにおいて、所与のロール「Ｘ」についてのすべてのサービスバインディングの固定のリストを自動的に埋めることによって行使される。
【００５４】
一実施形態においては、それぞれのクライアント・ロール・バインディングが、所与のロールを有するクライアントが呼び出すことができなければならないそれぞれのサービスについてのクライアントバインディングによってあらかじめ自動的に埋められる。一実施形態においては、ロールバインディングをあらかじめ埋めることが、ａ）呼び出し元マトリクスから、ロール「Ｘ」が「要求者ロール」であるすべての組を発見し、すべての「応答者ロール」のリストを生成し、ｂ）サービスＧＵＩ４０から、それぞれの「応答者ロール」についてサービスのリストを得て、ｃ）すべてのサービスリストを１つの大きなリスト（これが、すべてのクライアントバインディングのリストである）へと組み合わせることを含む。一実施形態においては、「クライアントの契約」のようなものが存在しない。すなわち、ノードがクライアントロール「Ｘ」で行為できるというだけでは、ノードが、ノードが所与のクライアントロールによって接触できるすべてのサービスに接触しなければならないということにはならない。所与の種類の要求を発行できるということが、能力である一方で、任意の時点において所与の種類の要求に応答できるということは、義務である。例えば、クライアントが呼び出すことができるロール（したがって、サービス）は、図３に関して上述したロール呼び出し元マトリクス３４によって定められる。
【００５５】
一実施形態においては、それぞれのクライアントまたはサービスバインディングが、以下の特性に関して定義される。
ロールアサーション（Ｒｏｌｅ Ａｓｓｅｒｔｉｏｎ）−プリンシパルＧＵＩ５０において特定される対応するロールアサーションの名前。
サービス種類（Ｓｅｒｖｉｃｅ Ｔｙｐｅ）−サービスバインディングについては、このフィールドが、提示されるサービスの種類を特定する一方で、クライアントバインディングについては、このフィールドが、所与のクライアントによって呼び出すことができるサービスを特定する。
完全性Ｃｅｒｔ（Ｉｎｔｅｇｒｉｔｙ Ｃｅｒｔ）−メッセージ署名に使用された証明書の名前。
機密性Ｃｅｒｔ（Ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ Ｃｅｒｔ）−メッセージ暗号化に使用された証明書の名前。
メッセージングＴＡ（信用アンカ（Ｔｒｕｓｔ Ａｎｃｈｏｒ））−メッセージ署名および／または暗号化のためのピアの証明書を認証するために使用するために、証明書機関プリンシパルのうちの１つについて定められた信用アンカ証明書。
属性ＴＡ（信用アンカ）−ピアのロール署名証明書を認証するために使用される証明書機関プリンシパルのうちの１つについて定められた信用アンカ証明書。
信用ＡＡ（属性アサーション（Ａｔｔｒｉｂｕｔｅ Ａｓｓｅｒｔｉｏｎ）Ｃｅｒｔ−発行しているピアのロールによって信用されたプリンシパルの証明書。
【００５６】
図８の実施形態においては、ノードＧＵＩ６０が、種々のノードの間の関係およびそれらの対応するロールバインディングを図式的に表示するために、ノード、サービス・ロール・バインディング、およびクライアント・ロール・バインディングをフォルダおよび下位フォルダを使用して階層的なやり方で整理する。ノードの間の関係、サービス・ロール・バインディング、クライアント・ロール・バインディング、および関連のロールバインディング特性の図式的な表示は、構成コードの列を読み通して同様の関係および特性を解読しなければならないことに比べ、信用管理エディタをユーザフレンドリにする。
【００５７】
すべてのクライアントおよびサービスバインディングをリストにすることに加え、一実施形態において、ノードＧＵＩ６０は、それらのバインディングのそれぞれについて信用管理のポリシーを定める。それぞれのクライアントまたはサービスバインディングが、ａ）それのロールを証明するためにどのアサーションを使用するかを定め（親のロールバインディングから自動的に引き継がれる）、ｂ）メッセージ署名のためにどの証明書を使用するかを定め、ｃ）メッセージ暗号化のためにどの証明書を使用するかを定め、ｄ）やり取りの相手である他のモードのメッセージ証明書を認証するためにどの信用アンカ証明書を使用するか（メッセージング信用アンカ、またはＭＴＡ）を定め、ｅ）ロールアサーション署名証明書を認証するためにどの信用アンカ証明書を使用するか（属性信用アンカ、またはＡＴＡ）を定め、およびｆ）誰が信用されたロールアサーション署名者であるかを名前によって定める（信用属性機関、またはＴＡＡ）。一実施形態においては、ＴＡＡは随意である。多くの場合、ＡＴＡを使用してロールアサーション署名者ＴＡＡを認証できる限りにおいて、ＴＡＡは信用される。一実施形態においては、ノードＧＵＩが、有効な証明書の選択のみを提示し、暗号化および署名の証明書は、所与のプリンシパルのそれでなければならず（自身の固有のメッセージを署名または暗号化するために、自身の固有の証明書のみを使用することができる）、さらにはそれらが、対応する鍵用途（署名のための１２８、および暗号化のための３２）を有していなければならない。ＭＴＡおよびＡＴＡは、証明書の署名のために鍵用途４を有する別のプリンシパルの証明書でなければならない。ＴＡＡは、データ署名の鍵用途１２８を有し、さらに「プリンシパル」ＧＵＩにおいて「属性機関」としてマークされている証明書でなければならない。
【００５８】
ノードＧＵＩ６０の下部のノード相互作用エディタは、ユーザが互いに呼び出されるべきノードロールバインディング組を列挙することを可能にする。一実施形態においては、信用管理エンジンが、特定の要求者ノードのロールバインディングのもとで設定されたそれぞれのクライアントバインディングが、応答者ノードの所与のロールバインディングのもとで設定された対応するサービスバインディングを呼び出すことができるか否かをチェックし、ここで「呼び出すことができる」とは、それぞれのノードのバインディングについて設定された信任状のそれらの対応する信用管理ポリシーとの適合性を指す。一実施形態においては、列挙されたロールバインディング組が無効である場合に、速やかにユーザに通知される。一実施形態においては、設定エディタが、割り当てられた信任状の適合性をチェックすることによってロールバインディング組の有効性を判断する。例えば、一実施形態においては、それぞれの相互作用ペア｛クライアント・ロール・バインディングＡ、サービス・ロール・バインディングＢ｝について、以下が検証される。すなわち、ａ）バインディングＡについて定められるメッセージング信用アンカ（ＭＴＡ）証明書が、バインディングＢにおいて使用される署名および暗号化証明書の両者の先祖でなければならず、逆もまた同様でなければならず、ｂ）バインディングＡについて定められる属性信用アンカ（ＡＴＡ）が、バインディングＢにおいて使用されるロールアサーションの署名者の先祖でなければならず、逆もまた同様でなければならない。図８の実施形態においては、ノードＧＵＩの設定ステータスウインドウが、設定の有効性についての通知をもたらす。設定が無効である場合、設定エラーの表示が、設定ステータスウインドウに表示される。
【００５９】
再び図８のノードＧＵＩ６０を参照すると、設定について作業を行いつつ、任意の時点において、ＸＭＬタブ２８を選択することによって、生成された設定の基礎をなすＸＭＬ表現を閲覧することが可能である。表示されるＸＭＬドキュメントは編集可能であるが、直接の変更は、典型的には基礎をなす図式の知識を必要とするため、推奨されない。
【００６０】
ひとたびネットワーク設定が完了し、設定ステータスウインドウが設定が有効である旨を示すと、設定プロセスは完了する。設定を、将来の参照のためにローカルのファイルシステムに保存することができる。この時点で、開発者は、実装プロジェクトを生成するために設定ウィザードを続けることができる。
【００６１】
本明細書に記載の設定ツールは、ウェブサービス、デジタル著作権管理、および／または他のアプリケーションにおいて使用するための信用管理の仕組みの設定を簡単にする。信用管理の仕組みの設定が、一貫性について常に検証され、将来の参照のために保存することが可能である。
【００６２】
図９は、設定ツールの実施形態を実行するための例示のコンピュータシステム７０を示している。コンピュータシステムが、入力／出力７２、中央演算ユニット（ＣＰＵ）７４、データストレージ７６、およびシステムメモリ７８を含んでいる。入力／出力は、例えばディスプレイおよび／またはキーボードを含んでいる。ＣＰＵは、この技術分野において公知のとおり従来からの多機能プロセッサを含んでいる。データストレージは、例えば、磁気ディスクおよび／または光ディスク、ならびに／あるいは他の任意の適切なストレージ手段を備えている。データストレージは、この技術分野において公知のとおり、固定式であっても、リムーバブルであってもよい。システムメモリは、例えば、ＣＰＵによる実行または使用のための情報またはインストラクションを保存し、さらには／あるいはプロセッサによるインストラクションの実行中に一時変数または他の中間情報を保存するために、ランダム・アクセス・メモリ（ＲＡＭ）および読み出し専用メモリ（ＲＯＭ）の何らかの組み合わせを含むことができる。図９の実施形態においては、システムメモリが、オペレーティングシステム８０および上述の設定ツール８２を保存する。しかしながら、図９が説明の目的のために提示されたものであって、本発明を限定しようとするものではなく、追加の構成要素を備える他のコンピュータシステムおよび／または図９に示した構成要素の何らかの適切な部分集合も使用可能であることを、理解すべきである。実際、当業者であれば、例えばパーソナルコンピュータおよびメインフレームなど、実質的に任意の種類のコンピューティングシステムを使用できることを、理解できるであろう。
【００６３】
図１０が、図９の設定ツール８２の拡大図を示している。図１０に示した例においては、設定ツールが、ロールモジュール８４、サービスモジュール８６、プリンシパルモジュール８８、およびノードモジュール９０を含んでいる。一実施形態においては、それぞれのモジュールが、上述の機能ごとのＧＵＩに対応する機能を実行するための実行可能なインストラクションを含んでいる。さらに、設定ツールは、名前空間モジュール９２および拡張鍵使用モジュール９４を含んでいる。名前空間モジュールは、図４に関して上述したような名前空間エディタを実装するための実行可能なインストラクションを含んでおり、拡張鍵使用モジュールは、図７に関して上述したような拡張鍵エディタを実装するための実行可能なインストラクションを含んでいる。
【００６４】
機能ごとのＧＵＩを、別個の画面の眺めに表示されるものとして説明したが、機能ごとのＧＵＩを、種々の組み合わせにて同時に提示することも可能である。さらに、ＧＵＩの特定のレイアウトを提示したが、他のレイアウトも可能である。
【００６５】
図１１は、一実施形態に従って信用管理の仕組みを設定するための方法のプロセスフロー図である。ブロック１１０２において、ロールを定義するようにユーザを促すロールＧＵＩが提供される。ブロック１１０４において、ロールに対応するサービスを定義するようにユーザを促すサービスＧＵＩが提供される。ブロック１１０６において、ロールのうちの少なくとも１つをプリンシパルに関連付けるなど、プリンシパルを定義するようにユーザを促すプリンシパルＧＵＩが提供される。ブロック１１０８において、ノードとして機能するように指名されたプリンシパルについてロールバインディングを提示し、ノード間の相互作用を定義するようにユーザを促すノードＧＵＩが提供される。
【００６６】
信用管理の仕組みの設定のプロセスは、新たな信用管理の仕組みの設定、またはすでに設定済みの信用管理の仕組みの変更を含むことができる。
【００６７】
以上、分かり易さの目的のために或る程度詳しく説明を行ったが、その原理から離れることなく特定の変更および変形が可能であることは明らかであろう。なお、本明細書に記載のプロセスおよび装置の両者を実現するために、多数の別のやり方が存在する。したがって、これらの実施形態は、例示として理解すべきものであって、本発明を限定するものと理解してはならない。
【特許請求の範囲】
【請求項１】
ネットワーク環境において用いる信託管理のフレームワークを構成する方法であって、
ユーザに、ロールを規定するように指示するロール・グラフィックユーザインタフェースを提供する工程と、
前記ユーザに、前記ロールに対応するサービスを規定するように指示するサービス・グラフィックユーザインタフェースを提供する工程と、
前記ユーザに、プリンシパルを規定するように指示するプリンシパル・グラフィックユーザインタフェースを提供する工程であって、前記ロールのうちの少なくとも１つとプリンシパルとを関連付ける工程を含む、工程と、
ノードとして機能するように指定されたプリンシパルにロールのバインディングを与え、前記ユーザに、ノード間の遣り取りを規定するように指示するノード・グラフィックユーザインタフェースを提供する工程と
を含む、方法。
【請求項２】
ロール・グラフィックユーザインタフェースを提供する工程は、ユーザに、ロールネームを識別し、前記ロール間の遣り取りを識別するように指示するグラフィックユーザインタフェースを提供することを含む、請求項１に記載の方法。
【請求項３】
ロール・グラフィックユーザインタフェースを提供する工程は、ユーザに、ロールネームを識別し、どのロールがどのロールによって呼び出されることができるかを識別するように指示するグラフィックユーザインタフェースを提供する工程を含む、請求項１に記載の方法。
【請求項４】
前記ロール・グラフィックユーザインタフェースは、リクエスタのロールをマトリクスの１つの軸にし、リスポンダのロールをマトリクスの別の軸にして、マトリクスにおいてロールネームを提示する、請求項３に記載の方法。
【請求項５】
ロール間の遣り取りは、前記マトリクス内のリクエスタのロールとリスポンダのロールとの間の交点をマーキングすることによって識別される、請求項４に記載の方法。
【請求項６】
リクエスタのロールとリスポンダのロールとの間の交点におけるマークは、前記マーキングされたリクエスタのロールが前記マーキングされたリスポンダのロールを呼び出すことができることを示す、請求項５に記載の方法。
【請求項７】
前記ロール・グラフィックユーザインタフェースは、前記マトリクスの各軸上に各識別されたロールネームを配置するように構成される、請求項６に記載の方法。
【請求項８】
ロール・グラフィックユーザインタフェースを提供する工程は、ユーザに、ロールネームを識別し、どのロールがどのロールをアサートすることができるかを識別するように指示するグラフィックユーザインタフェースを提供する工程を含む、請求項１に記載の方法。
【請求項９】
前記サービス・グラフィックユーザインタフェースは、ユーザに、サービスに対するネームを識別し、前記サービスに関連付けられた少なくとも１つの操作を識別するように指示する、請求項１に記載の方法。
【請求項１０】
前記サービスに関連付けられた少なくとも１つの操作を識別する工程は、メッセージプロトコルを規定する工程を含む、請求項９に記載の方法。
【請求項１１】
メッセージプロトコルを規定する工程は、
ＸＭＬのスキーマタイプのメッセージを示す工程と、
メッセージがインテグリティ保護（ｉｎｔｅｇｒｉｔｙ ｐｒｏｔｅｃｔｅｄ）されなければならないかどうかを示す工程と、
メッセージが機密でなければならないかどうかを示す工程と、
メッセージがタイムスタンプされなければならないかどうかを示す工程と、
メッセージがノンスを含まなければならないかどうかを示す工程と
のうちの少なくとも１つを含む、請求項１０に記載の方法。
【請求項１２】
ユーザに、前記サービスに関連付けられたスキーマタイプのメッセージに対してネームスペースを規定するように指示するネームスペース・グラフィックユーザインタフェースを提供する工程をさらに含む、請求項１０に記載の方法。
【請求項１３】
前記サービス・グラフィックユーザインタフェースは、前記ロール・グラフィックユーザインタフェースにおいて識別される前記ロールに自動的に投入され、前記サービスはロールに関連付けられる、請求項９に記載の方法。
【請求項１４】
前記プリンシパル・グラフィックユーザインタフェースは、前記ユーザに、各プリンシパルに対して、プリンシパルネームおよびユニバーサルリソースネーム（ＵＲＮ）を識別するように指示する、請求項１に記載の方法。
【請求項１５】
前記プリンシパル・グラフィックユーザインタフェースは、ユーザに、各プリンシパルが外部ソースからインポートされたかどうかを識別するように指示する、請求項１３に記載の方法。
【請求項１６】
前記プリンシパル・グラフィックユーザインタフェースは、前記ユーザに、各プリンシパルに関連するクレデンシャルを識別するように指示する、請求項１３に記載の方法。
【請求項１７】
前記プリンシパル・グラフィックユーザインタフェースは、
イシューイングのプリンシパルと、
イシューイングの証明書と、
前記プリンシパルが属性のイシュアーであるかどうかと、
仕様書と
のうちの少なくとも１つに関連するプリンシパルのクレデンシャルを、ユーザに識別するように指示する、請求項１６に記載の方法。
【請求項１８】
前記ノード・グラフィックユーザインタフェースは、クライアントロールバインディングおよびサービスロールバインディングに関連するロールバインディングを提示する、請求項１に記載の方法。
【請求項１９】
各ロールバインディングに対して、前記ノード・グラフィックユーザインタフェースは、
ロールアサーションと、
サービスのタイプの指示と、
インテグリティ証明書のＩＤと、
機密証明書のＩＤと、
メッセージングのトラストアンカーのＩＤと、
属性のトラストアンカーのＩＤと、
信託された属性のアサーション証明書のＩＤと
のうちの少なくとも１つを提示する、請求項１８に記載の方法。
【請求項２０】
リクエスタのノードとして構成されたクライアントロールバインディングが、リスポンダのノードとして構成された対応のサービスバインディングを呼び出すことができるかを確認する工程をさらに含む、請求項４に記載の方法。
【請求項２１】
前記ノード・グラフィックユーザインタフェースは、ノード間の規定された遣り取りが有効であるかどうかに関する指示を提示する、請求項２０に記載の方法。
【請求項２２】
前記ノード・グラフィックユーザインタフェースは、ユーザに２つのノード間の遣り取りを識別するように指示するノード間遣り取りテーブルを提示する、請求項１に記載の方法。
【請求項２３】
遣り取りは、リクエスタのノード、リクエスタのロールバインディング、リスポンダのノード、およびリスポンダのロールバインディングを識別することによって、前記ノード間遣り取りテーブルにおいて提示される、請求項２２に記載の方法。
【請求項２４】
ネットワーク環境において用いる信託管理のフレームワークを構成するシステムであって、
ユーザに、ロールを規定するように指示するロールモジュールと、
前記ユーザに、前記ロールに対応するサービスを規定するように指示するサービスモジュールと、
前記ユーザに、プリンシパルを規定するように指示するプリンシパルモジュールであって、前記ロールのうちの少なくとも１つとプリンシパルとの関連付けをする、プリンシパルモジュールと、
ノードとして機能するように指定されたプリンシパルにロールのバインディングを与え、前記ユーザに、ノード間の遣り取りを規定するように指示するノードモジュールと
を備える、システム。
【請求項２５】
前記ロールモジュールは、ユーザに、ロールネームを識別し、どのロールがどのロールによって呼び出されることができるかを識別するように指示する、請求項２４に記載のシステム。
【請求項２６】
前記ロールモジュールは、ユーザに、ロールネームを識別し、どのロールがどのロールをアサートすることができるかを識別するように指示する、請求項２４に記載のシステム。
【請求項２７】
前記サービスモジュールは、ユーザに、サービスに対するネームを識別し、前記サービスに関連付けられた少なくとも１つの操作を識別するように指示する、請求項２４に記載のシステム。
【請求項２８】
前記サービスに関連付けられた少なくとも１つの操作を識別することがメッセージプロトコルを規定することを含み、メッセージプロトコルを規定することは、
ＸＭＬのスキーマタイプのメッセージを示すことと、
メッセージがインテグリティ保護（ｉｎｔｅｇｒｉｔｙ ｐｒｏｔｅｃｔｅｄ）されなければならないかどうかを示すことと、
メッセージが機密でなければならないかどうかを示すことと、
メッセージがタイムスタンプされなければならないかどうかを示すことと、
メッセージがノンスを含まなければならないかどうかを示すことと
のうちの少なくとも１つを含む、請求項２７に記載のシステム。
【請求項２９】
ユーザに、前記サービスに関連付けられたスキーマタイプのメッセージに対してネームスペースを規定するように指示するネームスペースモジュールを提供することをさらに含む、請求項２８に記載のシステム。
【請求項３０】
前記サービスモジュールは、サービス規定エディタを、前記ロール・グラフィックユーザインタフェース内において識別された前記ロールに自動的に投入し、前記サービスはロールに関連付けられる、請求項２４に記載のシステム。
【請求項３１】
前記ロールモジュールは、リクエスタのノードとして構成されたクライアントロールバインディングが、リスポンダのノードとして構成された対応のサービスバインディングを呼び出すことができるかを確認するように構成される、請求項２４に記載のシステム。
【請求項３２】
前記ノードモジュールは、ノード間の規定された遣り取りが有効であるかどうかに関する指示を提示する、請求項３１に記載のシステム。
【請求項３３】
前記ノードモジュールは、ユーザに２つのノード間の遣り取りを識別するように指示するノード間遣り取りテーブルを提示し、
前記遣り取りは、リクエスタのノード、リクエスタのロールバインディング、リスポンダのノード、およびリスポンダのロールバインディングを識別することによって、前記ノード間遣り取りテーブルにおいて提示され、
前記ノードモジュールは、前記識別された遣り取りの有効性の指示を提示するように構成される、請求項２４に記載のシステム。
【請求項３４】
ネットワーク環境において用いる信託管理のフレームワークを構成するシステムであって、
ユーザに、ロールを規定するように指示する手段と、
前記ユーザに、前記ロールに対応するサービスを規定するように指示する手段と、
前記ユーザに、プリンシパルを規定するように指示する手段であって、前記ロールのうちの少なくとも１つとプリンシパルとを関連付ける手段を含む、手段と、
ノードとして機能するように指定されたプリンシパルにロールのバインディングを与え、前記ユーザに、ノード間の遣り取りを規定するように指示する手段と
を含む、システム。
【請求項３５】
信託管理のフレームワークを構成する、実行可能な命令を含むコンピュータ可読媒体であって、前記実行可能な命令は、
ユーザに、ロールを規定するように指示するロール・グラフィックユーザインタフェースを提供することと、
前記ユーザに、前記ロールに対応するサービスを規定するように指示するサービスグラフィックユーザインタフェースを提供することと、
前記ユーザ、プリンシパルを規定するように指示するプリンシパル・グラフィックユーザインタフェースを提供することであって、前記ロールのうちの少なくとも１つとプリンシパルとを関連付けることを含む、ことと、
ノードとして機能するように指定されたプリンシパルにロールのバインディングを与え、前記ユーザに、ノード間の遣り取りを規定するように指示するノード・グラフィックユーザインタフェースを提供すること
の命令を含む、コンピュータ可読媒体。
【請求項１】
ネットワーク環境において用いる信託管理のフレームワークを構成する方法であって、
ユーザに、ロールを規定するように指示するロール・グラフィックユーザインタフェースを提供する工程と、
前記ユーザに、前記ロールに対応するサービスを規定するように指示するサービス・グラフィックユーザインタフェースを提供する工程と、
前記ユーザに、プリンシパルを規定するように指示するプリンシパル・グラフィックユーザインタフェースを提供する工程であって、前記ロールのうちの少なくとも１つとプリンシパルとを関連付ける工程を含む、工程と、
ノードとして機能するように指定されたプリンシパルにロールのバインディングを与え、前記ユーザに、ノード間の遣り取りを規定するように指示するノード・グラフィックユーザインタフェースを提供する工程と
を含む、方法。
【請求項２】
ロール・グラフィックユーザインタフェースを提供する工程は、ユーザに、ロールネームを識別し、前記ロール間の遣り取りを識別するように指示するグラフィックユーザインタフェースを提供することを含む、請求項１に記載の方法。
【請求項３】
ロール・グラフィックユーザインタフェースを提供する工程は、ユーザに、ロールネームを識別し、どのロールがどのロールによって呼び出されることができるかを識別するように指示するグラフィックユーザインタフェースを提供する工程を含む、請求項１に記載の方法。
【請求項４】
前記ロール・グラフィックユーザインタフェースは、リクエスタのロールをマトリクスの１つの軸にし、リスポンダのロールをマトリクスの別の軸にして、マトリクスにおいてロールネームを提示する、請求項３に記載の方法。
【請求項５】
ロール間の遣り取りは、前記マトリクス内のリクエスタのロールとリスポンダのロールとの間の交点をマーキングすることによって識別される、請求項４に記載の方法。
【請求項６】
リクエスタのロールとリスポンダのロールとの間の交点におけるマークは、前記マーキングされたリクエスタのロールが前記マーキングされたリスポンダのロールを呼び出すことができることを示す、請求項５に記載の方法。
【請求項７】
前記ロール・グラフィックユーザインタフェースは、前記マトリクスの各軸上に各識別されたロールネームを配置するように構成される、請求項６に記載の方法。
【請求項８】
ロール・グラフィックユーザインタフェースを提供する工程は、ユーザに、ロールネームを識別し、どのロールがどのロールをアサートすることができるかを識別するように指示するグラフィックユーザインタフェースを提供する工程を含む、請求項１に記載の方法。
【請求項９】
前記サービス・グラフィックユーザインタフェースは、ユーザに、サービスに対するネームを識別し、前記サービスに関連付けられた少なくとも１つの操作を識別するように指示する、請求項１に記載の方法。
【請求項１０】
前記サービスに関連付けられた少なくとも１つの操作を識別する工程は、メッセージプロトコルを規定する工程を含む、請求項９に記載の方法。
【請求項１１】
メッセージプロトコルを規定する工程は、
ＸＭＬのスキーマタイプのメッセージを示す工程と、
メッセージがインテグリティ保護（ｉｎｔｅｇｒｉｔｙ ｐｒｏｔｅｃｔｅｄ）されなければならないかどうかを示す工程と、
メッセージが機密でなければならないかどうかを示す工程と、
メッセージがタイムスタンプされなければならないかどうかを示す工程と、
メッセージがノンスを含まなければならないかどうかを示す工程と
のうちの少なくとも１つを含む、請求項１０に記載の方法。
【請求項１２】
ユーザに、前記サービスに関連付けられたスキーマタイプのメッセージに対してネームスペースを規定するように指示するネームスペース・グラフィックユーザインタフェースを提供する工程をさらに含む、請求項１０に記載の方法。
【請求項１３】
前記サービス・グラフィックユーザインタフェースは、前記ロール・グラフィックユーザインタフェースにおいて識別される前記ロールに自動的に投入され、前記サービスはロールに関連付けられる、請求項９に記載の方法。
【請求項１４】
前記プリンシパル・グラフィックユーザインタフェースは、前記ユーザに、各プリンシパルに対して、プリンシパルネームおよびユニバーサルリソースネーム（ＵＲＮ）を識別するように指示する、請求項１に記載の方法。
【請求項１５】
前記プリンシパル・グラフィックユーザインタフェースは、ユーザに、各プリンシパルが外部ソースからインポートされたかどうかを識別するように指示する、請求項１３に記載の方法。
【請求項１６】
前記プリンシパル・グラフィックユーザインタフェースは、前記ユーザに、各プリンシパルに関連するクレデンシャルを識別するように指示する、請求項１３に記載の方法。
【請求項１７】
前記プリンシパル・グラフィックユーザインタフェースは、
イシューイングのプリンシパルと、
イシューイングの証明書と、
前記プリンシパルが属性のイシュアーであるかどうかと、
仕様書と
のうちの少なくとも１つに関連するプリンシパルのクレデンシャルを、ユーザに識別するように指示する、請求項１６に記載の方法。
【請求項１８】
前記ノード・グラフィックユーザインタフェースは、クライアントロールバインディングおよびサービスロールバインディングに関連するロールバインディングを提示する、請求項１に記載の方法。
【請求項１９】
各ロールバインディングに対して、前記ノード・グラフィックユーザインタフェースは、
ロールアサーションと、
サービスのタイプの指示と、
インテグリティ証明書のＩＤと、
機密証明書のＩＤと、
メッセージングのトラストアンカーのＩＤと、
属性のトラストアンカーのＩＤと、
信託された属性のアサーション証明書のＩＤと
のうちの少なくとも１つを提示する、請求項１８に記載の方法。
【請求項２０】
リクエスタのノードとして構成されたクライアントロールバインディングが、リスポンダのノードとして構成された対応のサービスバインディングを呼び出すことができるかを確認する工程をさらに含む、請求項４に記載の方法。
【請求項２１】
前記ノード・グラフィックユーザインタフェースは、ノード間の規定された遣り取りが有効であるかどうかに関する指示を提示する、請求項２０に記載の方法。
【請求項２２】
前記ノード・グラフィックユーザインタフェースは、ユーザに２つのノード間の遣り取りを識別するように指示するノード間遣り取りテーブルを提示する、請求項１に記載の方法。
【請求項２３】
遣り取りは、リクエスタのノード、リクエスタのロールバインディング、リスポンダのノード、およびリスポンダのロールバインディングを識別することによって、前記ノード間遣り取りテーブルにおいて提示される、請求項２２に記載の方法。
【請求項２４】
ネットワーク環境において用いる信託管理のフレームワークを構成するシステムであって、
ユーザに、ロールを規定するように指示するロールモジュールと、
前記ユーザに、前記ロールに対応するサービスを規定するように指示するサービスモジュールと、
前記ユーザに、プリンシパルを規定するように指示するプリンシパルモジュールであって、前記ロールのうちの少なくとも１つとプリンシパルとの関連付けをする、プリンシパルモジュールと、
ノードとして機能するように指定されたプリンシパルにロールのバインディングを与え、前記ユーザに、ノード間の遣り取りを規定するように指示するノードモジュールと
を備える、システム。
【請求項２５】
前記ロールモジュールは、ユーザに、ロールネームを識別し、どのロールがどのロールによって呼び出されることができるかを識別するように指示する、請求項２４に記載のシステム。
【請求項２６】
前記ロールモジュールは、ユーザに、ロールネームを識別し、どのロールがどのロールをアサートすることができるかを識別するように指示する、請求項２４に記載のシステム。
【請求項２７】
前記サービスモジュールは、ユーザに、サービスに対するネームを識別し、前記サービスに関連付けられた少なくとも１つの操作を識別するように指示する、請求項２４に記載のシステム。
【請求項２８】
前記サービスに関連付けられた少なくとも１つの操作を識別することがメッセージプロトコルを規定することを含み、メッセージプロトコルを規定することは、
ＸＭＬのスキーマタイプのメッセージを示すことと、
メッセージがインテグリティ保護（ｉｎｔｅｇｒｉｔｙ ｐｒｏｔｅｃｔｅｄ）されなければならないかどうかを示すことと、
メッセージが機密でなければならないかどうかを示すことと、
メッセージがタイムスタンプされなければならないかどうかを示すことと、
メッセージがノンスを含まなければならないかどうかを示すことと
のうちの少なくとも１つを含む、請求項２７に記載のシステム。
【請求項２９】
ユーザに、前記サービスに関連付けられたスキーマタイプのメッセージに対してネームスペースを規定するように指示するネームスペースモジュールを提供することをさらに含む、請求項２８に記載のシステム。
【請求項３０】
前記サービスモジュールは、サービス規定エディタを、前記ロール・グラフィックユーザインタフェース内において識別された前記ロールに自動的に投入し、前記サービスはロールに関連付けられる、請求項２４に記載のシステム。
【請求項３１】
前記ロールモジュールは、リクエスタのノードとして構成されたクライアントロールバインディングが、リスポンダのノードとして構成された対応のサービスバインディングを呼び出すことができるかを確認するように構成される、請求項２４に記載のシステム。
【請求項３２】
前記ノードモジュールは、ノード間の規定された遣り取りが有効であるかどうかに関する指示を提示する、請求項３１に記載のシステム。
【請求項３３】
前記ノードモジュールは、ユーザに２つのノード間の遣り取りを識別するように指示するノード間遣り取りテーブルを提示し、
前記遣り取りは、リクエスタのノード、リクエスタのロールバインディング、リスポンダのノード、およびリスポンダのロールバインディングを識別することによって、前記ノード間遣り取りテーブルにおいて提示され、
前記ノードモジュールは、前記識別された遣り取りの有効性の指示を提示するように構成される、請求項２４に記載のシステム。
【請求項３４】
ネットワーク環境において用いる信託管理のフレームワークを構成するシステムであって、
ユーザに、ロールを規定するように指示する手段と、
前記ユーザに、前記ロールに対応するサービスを規定するように指示する手段と、
前記ユーザに、プリンシパルを規定するように指示する手段であって、前記ロールのうちの少なくとも１つとプリンシパルとを関連付ける手段を含む、手段と、
ノードとして機能するように指定されたプリンシパルにロールのバインディングを与え、前記ユーザに、ノード間の遣り取りを規定するように指示する手段と
を含む、システム。
【請求項３５】
信託管理のフレームワークを構成する、実行可能な命令を含むコンピュータ可読媒体であって、前記実行可能な命令は、
ユーザに、ロールを規定するように指示するロール・グラフィックユーザインタフェースを提供することと、
前記ユーザに、前記ロールに対応するサービスを規定するように指示するサービスグラフィックユーザインタフェースを提供することと、
前記ユーザ、プリンシパルを規定するように指示するプリンシパル・グラフィックユーザインタフェースを提供することであって、前記ロールのうちの少なくとも１つとプリンシパルとを関連付けることを含む、ことと、
ノードとして機能するように指定されたプリンシパルにロールのバインディングを与え、前記ユーザに、ノード間の遣り取りを規定するように指示するノード・グラフィックユーザインタフェースを提供すること
の命令を含む、コンピュータ可読媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公表番号】特表２０１０−５００６５２（Ｐ２０１０−５００６５２Ａ）
【公表日】平成２２年１月７日（２０１０．１．７）
【国際特許分類】
【出願番号】特願２００９−５２３８６０（Ｐ２００９−５２３８６０）
【出願日】平成１９年８月９日（２００７．８．９）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０１７７９４
【国際公開番号】ＷＯ２００８／０１９１５８
【国際公開日】平成２０年２月１４日（２００８．２．１４）
【出願人】（３９７０７２７６５）インタートラスト テクノロジーズ コーポレイション (56)
【Ｆターム（参考）】
【公表日】平成２２年１月７日（２０１０．１．７）
【国際特許分類】
【出願日】平成１９年８月９日（２００７．８．９）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０１７７９４
【国際公開番号】ＷＯ２００８／０１９１５８
【国際公開日】平成２０年２月１４日（２００８．２．１４）
【出願人】（３９７０７２７６５）インタートラスト テクノロジーズ コーポレイション (56)
【Ｆターム（参考）】
[ Back to top ]