JP2002536732A - 暗号化でサポートされるサービスのためのインフラストラクチャとアプリケーションを運用する方法 - Google Patents

Abstract

(57)【要約】 複数のエンティティの一部が暗号化でサポートされるサービスを提供するようなインフラストラクチャにおいて、複数のエンティティのうち加入者エンティティを複数のエンティティのうち本人エンティティに登録するための方法が開示されている。この方法によれば、加入者エンティティは、要求メッセージを複数のエンティティのうちレジストラエンティティに送信することによって本人エンティティにサービスを要求し、レジストラエンティティは加入者エンティティを検証し、サービス要求を本人エンティティに転送し、本人エンティティは、転送されてきた要求を格納しておき、確認通知メッセージをレジストラエンティティに送信し、この確認通知は受諾したことと、加入者エンティティが要求サービスのために必要とする認証／許可情報を記載しており、レジストラエンティティは、受信した確認通知メッセージの認証性を検証し、正しければ、確認通知メッセージを加入者エンティティに転送することを備えている。

Description

【発明の詳細な説明】

【０００１】 （発明の背景） （発明の分野） 本発明は、コンピュータおよびコミュニケーションネットワークを通して自動
的にサービス提供を行うための、暗号化および分散トラストメカニズムに関する
。

【０００２】 （背景および概要） 基本的暗号化インフラストラクチャ技法と方法論は公知である。これらの技法
および方法論としては、証明局（Certification Authorities CA）のほかに、
第三者機関（Trusted Third Parties）がある。ユーザ間の保証されたトランザ
クションをサポートするインフラストラクチャのコンテキストでトランザクショ
ンに信用（reliance）を提供するという考え方は、例えば、「Reliance Server
for Electronic Transaction System」という名称で、１９９８年１２月７日に
同日出願され、係属中の関連米国特許出願第０９／２０６，３８１号（これは、
米国特許出願第０８／７６７，２５７号の継続出願（米国特許第５，９０３，８
８２号として許可済み）である）および「Computer-Based Method and System F
or Aiding Transactions」という名称で１９９８年２月１９日に出願された関連
米国特許出願第０９／０２６，４６６号（ここでは、信用と保証（assurance）
を提供するインフラストラクチャが開示されている）に記載されている。

【０００３】 インフラストラクチャは、一般的に、インフラストラクチャをシステムとして
見たときシステムのエンティティである、多数のローカルの代表者（local repr
esentative）から構成されている。インフラストラクチャは、例えば、ユーザと
ビジネスクライアントを登録するように設定され、ビジネスエンティティとユー
ザ間のトランザクションをサポートするために保証をサポートし担保（warranty
）を提供する。

【０００４】 本発明は、インフラストラクチャを編成し、保守し、動的に管理するための補
完的方法を提供すると共に、インフラストラクチャとそのユーザの運用に係わり
をもつアプリケーションについてさらなる方法を提供している。また、本発明は
、マルチエンタープライズ、マルチエンティティ・インフラストラクチャのため
のダイナミックツールを提供すると共に、その編成、セットアップ、および保守
のための方法とも係わりをもっている。さらに、本発明は、インフラストラクチ
ャのエンティティと種々のユーザ間の関係を動的に管理するための方法も提供し
ている。リンキングを正確に維持すること、およびロケーションのリンキングを
インフラストラクチャの中でサポートするメカニズムも提供されている。

【０００５】 本発明によれば、暗号化ツール、アクセス制御とデリゲーションメカニズム（
delegation mechanism）などのセキュリティ技術、データベース技術は、コンピ
ュータ、ネットワーキングおよびワールドワイドウェブ（World Wide Web）技術
と共に、コヒーレントなサービスに変形されており、そこでは、プロバイダは編
成され、動的に維持され、他のビジネス機関とクライントと共に運用され、相互
間で協働している。

【０００６】 エレクトロニックトランザクションを使用してサービスを動的に維持し、運用
することは、信頼性があって、セキュアで、プライベートであると共に、強固で
あることが必要であり、その代表例としては、金融、バンキング、保険、医療、
国際的商取引、その他の取引分野などのセンシティブなサービス、輸出入ビジネ
ス、メディアと情報サービス、政治的制約が重視されているサービス、および必
要とされる信託、サポート、セキュリティおよび他の保証を達成するためのサポ
ートが要求されるような他の、多くの分野がある。これらの多数の分野では、本
発明によって提供されるような、インフラストラクチャのサポート、動的維持お
よび運用が要求されている。

【０００７】 本発明は、電子署名、電子契約と合意、デジタル証明、電子文書のメッセ−ジ
ングとレポーティング、暗号化、暗号鍵供託と回復、アクセス制御、デリゲーシ
ョン手法および通信プロトコルなどの、基本的暗号化とセキュリティおよび保全
性メカニズムを採用して、オンラインサービスを提供するために必要なインフラ
ストラクチャとアプリケーションを提供している。

【０００８】 また、本発明は、遂行されるトランザクションに対して信託と責任（accounta
bility）を必要とし、そこでは、多数のエンティティが係わりをもっている努力
と関連づけられたサービスも提供している。

【０００９】 別の側面では、本発明は、システムエンティティのサービス・インフラストラ
クチャを設定し、システムエンティティ間の関係を維持するための方法とメカニ
ズムを展開することにも係わりをもっている。

【００１０】 さらに、本発明は、ユーザとエンタープライズ代表者を、提供されるサービス
の加入者として登録する方法にも係わっている。

【００１１】 また、本発明は、システムエンティティ自体間と、システムエンティティとシ
ステムに未登録の組織との間で提供されるサービスを運用し、サポートする方法
にも係わっている。

【００１２】 本発明は、システムの加入者との間で実行されるサービストランザクションを
統制し、モニタする方法に係わっている。

【００１３】 本発明によれば、システムエンティティ間のすべての関係を、システムの成長
と変化に伴って動的に保守し、拡張する方法が組み込まれている。

【００１４】 さらに、本発明は、相互に関連付けられていて、コヒーレントで、フレキシブ
ルで、信頼性があって、強固なサービス提供メカニズムを保証するように接続さ
れている種々の方法を提供している。

【００１５】 本発明のシステムと方法は、実施されるトランザクションの信託と保証が係わ
りをもつ信頼性があって、フレキシブルで、強固なサービスを採用している。本
発明のシステムと方法は、ある種の取引および金融活動が、インターネットなど
の電子的ネットワーク領域で活動するような種々の分野で利用すると便利である
。本発明の暗号化および信託制御機能（trusted control features）が必要とさ
れる代表的な分野としては、金融サービス、保険サービス、医療サービス、種々
の政府、公証サービス、取引サービス、ニューズ、情報とメディアサービス、政
治コンサルティングサービス、政府サービス、仲裁サービス、国際的マーケット
サービス、および法律サービスがある。

【００１６】 例えば、本発明の方法は、マルチエンタープライズ組織を取り扱い、多数のユ
ーザおよびエンタープライズを取り扱うときに利用すると、特に好都合である。

【００１７】 本発明によれば、サービスメカニズムをサポートするために必要とされる基本
的暗号化、コンピュータおよび通信技術と、メッセ−ジングサポート手法が開示
されている。本発明によれば、フレキシブルなサービス手続きが係わりをもつ、
信頼性のあるサービスを遂行するための方法が提供されている。

【００１８】 本発明は、コンピュータと通信ネットワークを通してサービスを自動的に提供
することに関連する暗号化と分散信託メカニズムの分野に属するものである。本
発明によれば、電子署名、電子契約と合意、デジタル証明、電子文書のメッセ−
ジングとレポーティング、暗号化、暗号鍵供託と回復、アクセス制御、デリゲー
ション手法および通信プロトコルなどの、基本的暗号化とセキュリティおよび保
全性メカニズムを使用して、サービス提供で必要になるインフラストラクチャと
アプリケーションを提供している。サービスは、サービスの信託と責任が要求さ
れるようなアプリケーション分野や、多数のエンティティが係わりをもっている
ようなアプリケーション分野と関連付けられている。本発明は、システムエンテ
ィティのサービス・インフラストラクチャとエンティティ間の関係を確立し、維
持するための方法とメカニズムが係わりをもつと共に、その方法とメカニズムを
提供している。さらに、本発明は、ユーザとエンタープライズ代表者を、サービ
スの加入者として取り扱うための方法が係わりをもつと共に、その方法を提供し
ている。また、本発明は、システムエンティティ自体間およびシステムエンティ
ティと他の組織との間のサービスを運用し、サポートするための方法が係わりを
もち、その方法を提供している。本発明は、加入者とのサービストランザクショ
ンに関する方法が係わりをもつと共に、その方法を提供している。最後に、本発
明は、システムエンティティ間のすべての関係を、システムの成長と変化に伴っ
て動的に保守するための方法を提供している。これらの種々の方法は相互に関連
付けられ、コヒーレントで、フレキシブルで、信頼性があって、強固なサービス
メカニズムを保証するように接続されている。

【００１９】 トランザクションの信託と保証が係わりをもつ、信頼性があって、フレキシブ
ルで強固なサービスは、ある種の取引活動と金融活動が、インターネットのよう
な電子的ネットワークド領域で活動するような種々の分野で利用されることを目
的としている。暗号化とトラステッド制御が必要とされるような代表的分野とし
ては、金融サービス、保険サービス、医療サービス、種々の政府、公証サービス
、取引サービス、ニューズ、情報とメディアサービス、政治コンサルティングサ
ービス、政府サービス、仲裁サービス、国際的マーケットサービス、および法律
サービスがある。本発明の種々方法は、多数のユーザとエンタープライズが係わ
りをもつマルチエンタープライズ組織で利用すると、特に好都合である。本発明
には、サービスメカニズムの基礎となるために要求される基本的暗号化、コンピ
ュータおよび通信技術とメッセ−ジングサポートが開示されている。本発明には
、フレキシブルなサービス手続きが係わりをもつ、信頼性のあるサービスを遂行
するための方法も開示されている。

【００２０】 （詳細な説明） （エンティティと関係） 暗号化でサポートされるサービスが初期化されるとき、種々のエンティティは
サービスプロバイダとして示されている。これらのエンティティは、エンティテ
ィとして証明され、サービス組織（service organization）と呼ばれる組織のも
とに編成されている。なお、これらのエンティティは、ある組織に裏付けさせる
ことも、他のメカニズムで証明させることも可能である。ネットワークを利用し
てサービスプロバイダの資格証明（credential）を獲得し、提示するためには暗
号化手段が存在していることが必要である。この資格証明は、一時的な場合もあ
れば、異なるルールに従って変更される場合もある。本発明によれば、そのよう
なサービス提供ライセンスのセットアップと維持とを表わすメカニズムが提供さ
れている。一般的に、これらのどのメカニズムにおいても、本発明によれば、本
人（principal）（サービスプロバイダ）の資格証明と、資格証明を保証できる
当局を特定することが可能になっている。組織のあらゆる種類は、システムが進
化すると共に、サービスのスケール、規則および他の特性が変更されると、それ
に伴って変化することができる。本発明によれば、そのように変化する環境を長
期にわたって維持するための方法が提供されている。

【００２１】 システム内の種々エンティティは、ある種の関係をもち、あるものは双務的（
bilateral）で、あるものは公開的（public）である場合がある。これらの関係
は保全性をもって維持されている必要がある。これらの関係の長期と短期の変化
は妥当であるかどうか検査され、グローバルに知られた構造を保証するように同
期されている必要がある。公知の構造の例として、電子署名と公開鍵の分野にお
ける証明局の階層があるが、他の編成構造も可能である。他の例としては、サブ
サービスを提供する企業内の部課や、グローバルに認知されている職務（例えば
、パスポート交付−米国国務省で交付されているパスポートは、すべての国家と
国を識別する目的に利用するのに適している）を履行する政府内の部局などがあ
る。

【００２２】 その他の関係としては、サービスを受ける人が移動するようなサービス関係が
ある。例えば、カストマが銀行間を移動すると、銀行間でアカウントが動き回る
ことになる。いくつかの関係は、当事者間で署名された契約に基づいている。ま
た、いくつかの関係は、支払いシステムのようなシステムに参加しているものと
定義され、そこでは、一方の当事者は他方の当事者に支払ったり、銀行または組
織経由で支払ったりできるようになっている。本発明によれば、このような関係
は電子的に維持されるようになっている。

【００２３】 システム内の他のエレメントはユーザであって、ユーザ個人である場合と、ユ
ーザグループである場合とがある。ユーザは個人になることも、エンタープライ
ズまたはエンタープライズ代表者になることもできる。ユーザはグループになる
ことも、グループとして編成されることもできる。ユーザとエンティティは、長
期の属性（attribute）を有し、あとで取り上げるであろう機能（capabilities
）を与えられることができる。ユーザとエンタープライズであるエンティティと
の区別は、人為的なものである。その理由は、ユーザによっては自身がエンター
プライズになることができ、また、ユーザはサービスをサポートするトランザク
ションと派生トランザクション（derived transaction）を実行するためだけに
インフラストラクチャとアプリケーションを使用するからである。

【００２４】 エンティティ間の関係は普通サービスに関連し、金融、保険、医療、政府など
の産業のセクタと関連付けられているか、あるいは複数の分野にまたがるサービ
スになっている場合もある。サービスは、その性質上、分野、産業またはセクタ
と関連付けられた一連のアプリケーションが係わりをもっている。例えば、ユー
ザ間で金銭や他の金融証券の転送が行われるようなトランザクションをサポート
するサービスが考えられるが、サービスはこれだけに限定されるものではない。
別の例としては、クライアントに関連付けられたＩＤと条件に関する担保の提供
、支払いの保証、さもなければ、トランザクションの完了に責任をもつこと、お
そらくは、責任をとることや他の介入を行うこと、などがある。サービスの別の
例としては、金融および取引トランザクションに関して消費者にコンサルタント
することに関連するサービスがある。バンキングと保険が主要サービスになって
いるような金融分野の例のほかに、ここで説明しているインフラストラクチャと
アプリケーションを使用すると、他の多くのサービス分野を実現することが可能
である。

【００２５】 本発明の好ましい実施形態では、エンティティは、コンピュータと通信機器を
所有すると共に、トランザクションを実行し、通信し、レポートとドキュメント
を準備するためのソフトウェアや、トランザクションを行うための、他のコンピ
ューティングとオフィスサポートを所有しているものと想定されている。

【００２６】 （トランザクションとプロセス） 本発明によれば、ユーザをサービスの中で登録し、ユーザが許可によってサー
ビス特性と関連付けられるようにする方法が提供されている。このことは、ある
種の機能はユーザが異なるごとに異なっていることを意味している。また、登録
を変更または終了させるための方法も提供されている（すべての関係において終
了を記録することは重要なイベントである）。これらの機能およびユーザとエン
ティティとの関連付けとその関係は、どちらも変更することが可能である。ユー
ザとサービスシステム間の関係を管理するための方法も提供されている。この管
理は信用性があり、ある種のシステムエンティティによって認識されるバインデ
ィング（binding）を提供している。このバインディングは、ユーザに対しても
、ユーザの役割に対しても行うことができ、匿名にすることも可能であり、本発
明が提供する方法の範囲内で種々の変形も可能である。ユーザとユーザグループ
は、１つのエンタープライズに所属していることもあれば、別のエンタープライ
ズに登録されていることもある。登録と維持プロセスは、個別に実行することも
、バルクグループ（bulk group）で実行することも可能である。

【００２７】 システム内の種々エレメントは、種々の登録プロセスの対象になっている。最
初に、本人とレジストラ（registrar）が登録されている必要があり、そのあと
、組織を表す他のエンティティが登録されることになる。なお、エンティティを
暗号化またはトランザクションシステムに登録することを可能にする、多くの公
知登録プロセスまたはメカニズムの１つを採用することが可能である。

【００２８】 機能またはユーザ特性を定義するには、サービスの内容を調べる必要がある。
金融サービスでは、これらの機能は、ある種のクレジット、支払い、および許可
された支払い金額が係わりをもっているのが代表的である。さらに、機能は、ユ
ーザおよび組織グループとエンティティに関連付けられたクレジット、保証、ギ
ャランティ、および制限のレベルと関係付けることができる。他のサービスでは
、ある種のコンテンツ、ソフトウェアまたはコンピューティングサーバへのアク
セスと関連付けることが可能である。機能は、ユーザの特性と経歴に関連付けら
れた種々の許可が係わりをもつことも、ユーザに関連するリスクの評価（例えば
、医療分野での投薬許可）が係わりをもつこともできる。機能には、固定したも
の（例えば、属性）も、長期的なものもあれば、経時的に動的に変化するもの（
例えば、ユーザが不品行な振る舞いをしたとき行動異常検出）もある。エンティ
ティとユーザの機能と特性を管理することは、強行される方法である。

【００２９】 関係と機能は、システムの手続き、ルールおよび規則から派生させることがで
きる。一般的ルールと規則およびこれらを強行する方法を取り扱うための表現方
法は、種々のものが知られている。これらのルールは、暗号化とセキュリティ・
インフラストラクチャメカニズムの中に組み込まれている。

【００３０】 トランザクションは、ユーザとエンティティ間と、エンティティとエンティテ
ィ間と、エンティティと当局組織間との関係構造の中に定義されている。ユーザ
は、種々のエンティティとのトランザクションを通してサービスを受けることに
なる。トランザクションは、長期の関係と一時的制約（例えば、ネットワーク接
続性）に基づいて判断される。トランザクションは、インフラストラクチャ内の
多数のエンティティが係わりをもつことがある。ユーザがサービス要求をあるエ
ンティティに送ると、そのユーザはそのエンティティの組織と係わりをもつこと
になり、このエンティティは、そのサービス要求を処理するか、あるいはそれを
転送することも（あるいはその両方）、別のインフラストラクチャトランザクシ
ョンを作成することもできる。最後に、トランザクションは処理され、リスク管
理と意思決定がデータベース維持と更新と共に行われ、メッセージがやりとりさ
れ、サービスが提供される。トランザクションは電子的に終了することも、電子
的でない別のトランザクションをトリガすることもできる。

【００３１】 派生トランザクションは、基本的トランザクション（例えば、再保険、記名承
諾および集約（aggregation））をサポートするためにオンラインで生成される
。これらの派生トランザクションは、エンティティ間の進行中ビジネスと取引が
係わりをもっている。また、これらのトランザクションは、ユーザのある種の条
件を取り扱う第三者（トランザクションの保険を提供する）が係わりをもつこと
もあれば、追加サービスを提供する当事者（アフィニティ組織）が係わりをもつ
こともある。エンティティは、トランザクションまたはトランザクションの表現
を集約し、それらを別のトランザクションとして取り扱うことができる。仲裁サ
ービスは、匿名や他の保証を提供するために呼び出すことができる。オンライン
保証を組み入れるための必要条件（ユーザにそのステータスをある当事者と再交
渉させる）が要求される場合もある。他の派生トランザクションは、ユーザから
見えるものとユーザから見えないものとがあるが、これらを呼び出すことも可能
である。なお、派生トランザクションは、初期トランザクションと同じ構造にす
ることができる。例えば、初期トランザクションが担保を容認することを扱って
いれば、派生トランザクションは、担保容認エンティティによって開始すること
ができ、開始すると、この派生トランザクションは、追加担保サポートまたは保
険補償額または付随手段を求めて、必要とされる担保を安全に拡張することにな
る。保険トランザクションでは、再保険トランザクションが生成されることにな
る。これらの例は代表例であり、トランザクションと派生トランザクション間の
関係の性質に限定されるものではない。

【００３２】 保守トランザクションは、エンティティとユーザのインフラストラクチャをサ
ポートするために要求されるものである。レポーティングとメッセ−ジングは、
監査（auditing）とファイリングと共に、一般にオフラインで行われる進行中の
サポートの一部になっている。支払いと会計方法またはシステム外の支払いのト
リガリングは、トランザクションの一部として組み込まれている。リスク管理手
法、エキスパートシステム、人工知能方法論、統計およびデータマイニング（da
ta mining）は、例えば、ユーザの挙動に関する異常検出のために使用すること
ができる。

【００３３】 上記以外にも、多数の保守手続きが可能である。そのようなものとして、暗号
化関係の文献、例えば、D. Denning著「Cryptography and Data Security」およ
びB. Schneier著「Applied Cryptography」で公表されている鍵管理とプロトコ
ルの多くを利用して機能を反復し、暗号化ツールと鍵をリフレッシュすること、
などがある。なお、これらの文献はどちらも、その内容は引用により本明細書に
含まれている。

【００３４】 テクニカルトランザクションは付加的トランザクションであるが、このトラン
ザクションでは、システムをセキュアし、システムの利用可能性、オペレーショ
ン状態および保全性を保証することによるオーバヘッドが発生している。テクニ
カルトランザクションは、暗号化ロギング、保全性チェック、セキュアメッセ−
ジングおよびその他の暗号化メカニズムが係わりをもっているが、これらは、こ
の分野では公知技術である。テクニカルトランザクションは、分散データベース
を維持するためのトランザクションコミットメカニズムおよびフォルトトレラン
トな通信プロトコルが係わりをもっている。

【００３５】 （セキュリティ、保全性およびプライバシに関する考慮事項） エンティティおよびレコードとメッセージが、明確に定義されたドメイン内で
保護されることを保証するための方法が提供されている。サービスプロバイダで
あっても、自身のコンピュータ内のある種の保護デバイスとネットワークコンポ
ーネントからある種の情報を得ることができないことがある。プライバシは、個
人だけでなく、企業を保護するためにも重要である。匿名もその保護のために重
要になることがある。本発明によれば、秘密性、プライバシおよび匿名を提供す
る、種々のコンポーネント設計とトランザクションに組み込まれることを目的と
した方法が提供されている。特権の管理は、サービスを提供し、サービスを受け
るプロセスに固有のものになっている。

【００３６】 本発明のいくつかの側面のオペレーションでは、対称手法と非対称手法を使用
する暗号化テクノロジが、アクセス制御技術と共に利用可能になっていることが
前提になっている。

【００３７】 さらに、通信においては、セキュアが要求される各メッセージは、鍵で暗号化
されることが前提になっている。この鍵は、送信側と受信側に共有させることも
、鍵交換プロトコル（例えば、そこでは、一方または双方の当事者が公開鍵を公
表し、両当事者が共有鍵を派生できるようにしたＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ
ｎ鍵交換）から派生させることもできる。さらに、真正と発信元証明のために署
名が要求されるメッセージは、送信側によって署名される。共有暗号化情報は、
メッセージのバインディングとコネクション、メッセージのロギングとモニタリ
ングのために使用することができる。

【００３８】 メッセージ交換（トランザクション）という意味では、メッセージは、トラン
ザクションまたはセッションＩＤ、参加者、およびヒストリックメッセージのコ
ンテンツでタグを付けることができる。ユーザのステートも、タグの一部にする
ことができる。タグと利用可能な暗号化ツール（鍵と共有ランダムストリング）
を使用すると、メッセージは、現在の状況の範囲で認証することができる。認証
のためのメカニズムは、暗号化分野では公知である。このようにメッセージをバ
インディングすると、トランザクション全体の保全性が保証されることになる。
トランザクション保全性を保証するための暗号化の、このような使い方の例は、
米国特許出願第０９／０２６，４６６号（Frankel他、以下「Frankel」という）
に記載されているが、その内容は引用により本明細書に含まれている。

【００３９】 本発明のコンテキストにおけるプロトコルと手続きの説明では、上述した暗号
化ツールは、各メッセージに組み込まれているもとの想定されている。それがど
のように達成されるかの具体的内容は「Frankel」に従うことも、他の暗号化手
法を使用してトランザクション保全性と秘密性を達成することも可能である。暗
号化保全性とバインディングフィールドの正確な記述は省略されているが、例え
ば、本発明のコンテキストとプロトコルで「Frankel」がどのように採用される
かは、この分野の精通者ならば自明のことである。

【００４０】 他の暗号化サブシステムはメッセージに追加することも、サブプロトコル、例
えば、正しく実行されたトランザクションのあとに続く電子支払いシステムとし
て続けることもできる。

【００４１】 （説明） （サービスシステムのコンポーネント） このセクションでは、本発明の説明全体を通して使用される基本的プリミティ
ブについて説明する。最初に、システムの参加者（エンティティ）とシステム内
のオペレーションに関する、いくつかの用語について定義しておく。 ・機能（capability）：許可の一形態 ・属性（attribute）：名前付きオブジェクトに関連する特徴 ・加入者（subscriber）（またはユーザ）：ある形態の機能（つまり、提供サ
ービスへの登録）または属性（例えば、購買管理者などの役割としての任命）を
得ようとするシステムのエンティティ ・グループ（group）：システムエンティティの集まり（例えば、加入者グル
ープは加入者の集まりであり、レジストラグループはレジストラの集まりである
） ・ス−パバイザ（supervisor）：ある機能または属性のユーザまたはグループ
、あるいはエンティティのサービスの特性について変更を要求できるシステムエ
ンティティ ・マネージャ（manager）：オペレーションの維持と制御を担当するシステム
エンティティ ・補助エージェント（auxiliary agent）：２次的および支援オペレーション
を担当するシステムエンティティ（例えば、タイムススタンピングなど） ・レジストラ（registrar）：本人の権限に代行して機能および／または属性
の発行を容易にするシステムエンティティ ・本人の権限（Principal Authority）（または本人）：ある種の属性に対す
る権限またはある種の機能をピアレジストラに委任する権限を持つシステムエン
ティティ ・プロキシ／インタフェース（proxy/interface）：導管（conduit）としてま
たはエンティティのアクションの法的代表として他のエンティティの代行をする
システム内のエンティティ ・トランザクション（transaction）：加入者に関係するサービスの交換（int
erchange）。これはサービスの性質に基づいている。 ・派生トランザクション（derived transaction）：別のトランザクションに
よって開始された交換。「トランザクション」と「派生トランザクション」は本
明細書では同じ意味で用いられている。 ・インフラストラクチャ関係（infrastructure relations）：インフラストラ
クチャのサブ構造で、エンティティ間の関係を表しているもの。例えば、証明階
層（デジタル証明内）は、サブ構造を表すことができる。ある種のエンティティ
間の関係が可能である。例えば、「優先サービス関係」は、エンティティがある
種のサービス提供を指示するために準備する優先構造を定義している。

【００４２】 暗号化オペレーションでは、グループは、システムエンティティの集合または
エンティティのグルーピングと既存グループを定義している抽象的なものである
。グループは、同一タイプのエンティティまたは混成タイプのエンティティで構
成することができる。ここで問題にしているのは、ある種の関係をもつエンティ
ティ（例えば、同じ会社、同じ役割からのエンティティ、許容責任額の範囲内の
エンティティなど）から構成されているグループである。なお、どのグループに
も複数のスーパバイザが存在することがあり、その場合には、異なるタイプのス
ーパバイザは異なるタスクを実行することになる。例えば、レジストラは、ユー
ザまたはグループに対する特殊タイプのスーパバイザと考えることもできるが、
同一グループのためにリスク管理を担当する他のスーパバイザが存在することも
ある。

【００４３】 暗号化の立場から見たとき、システムは、マスタ鍵とトランザクション鍵の両
方をもつエンティティであると考えることができる。マスタ鍵は、トランザクシ
ョン鍵をリフレッシュするためにだけ使用されるので、マスタ鍵は、頻繁に使用
されることがなく、その働きも制限されている。従って、マスタ鍵は、危険にさ
らされることが少なくなっている。なお、どのタイプのエンティティも、潜在的
に鍵の階層をもつことができ、その階層は３レベル以上になっている可能性があ
る。例えば、異なるタイプのトランザクションごとにサブマスタ鍵を設定するた
めのマスタ鍵が１つまたは２つ以上存在することがあり、これらのマスタ鍵は、
トランザクション鍵を設定している。上述したように、種々のセキュリティと保
全性機能を提供するメッセージの暗号化部分は、種々の鍵を使用して追加されて
いる。

【００４４】 トランザクションカウントやステートといった、他のトランザクション検証情
報は、２つのシステムエンティティによって共有することができ、トランザクシ
ョンの有効性を検証し、鍵が危険にさらされているかどうかをテストする。この
共有は、付加的保護として使用され、認証と共に組み込まれている。例えば、暗
号化認証チャネルを利用して定期的に通信している二人の当事者がトランザクシ
ョンカウントを維持しているとき、トランザクションカウントが同期を失ったと
きは、一方の当事者の認証鍵が盗まれたことを意味している。ユーザの鍵と、ト
ランザクションカウントやステートなどのトランザクション検証情報は、スマー
トカードなどの、物理的に安全なデバイスにストアしておくことができる。

【００４５】 上記の用語は広義のものであり、各エンティティの最小限の機能（またはある
エンティティがシステム内で種々のタスクを担当している場合には、エンティテ
ィの役割の機能）を含んでいる。

【００４６】 （加入者登録、機能要求および契約署名） 以下では、本人に代行して、加入者のための機能または属性をレジストラで発
行するためのプロセスについて説明する。このセクションでは、まず、登録プロ
トコルを説明すると共に、レジストラの組み込みについても説明する。この場合
、レジストラがセキュリティ上の理由で使用されないときは、加入者と本人間の
通信を認証するための物理的手段が存在している必要がある。上述したように、
種々のエンティティは、サービスのために他のエンティティに登録されている。
このセクションで説明している登録メカニズムは、これらのタイプの登録を示し
ている実施例である。実際には、レジストラは、本人と共に登録され、エンティ
ティは、レジストラまたは別のエンティティに登録され、ビジネスユニットは、
クライアントとしてエンティティに登録され、ユーザのリストまたは個々のユー
ザは、エンティティに登録され、プロキシは、別のエンティティにエンティティ
を登録することができる。

【００４７】 一例として、加入者登録が行われる前のブートストラップ期間に、加入者（同
様に、本人）は、レジストラの公開署名鍵または秘密認証鍵の所有を、ある種の
認証チャネルを通して取得する。これは基本的セットアップサブルーチンであり
、認証暗号化セキュリティチャネルを設定するために必要な、多くの暗号化プロ
トコルに存在している。

【００４８】 （登録プロトコル） 図１は、本発明の一実施形態による登録プロトコルの例を示す図である。この
セクションでは、メッセージフロー１，２，３，４，および５について説明する
。なお、メッセージは、その全部または一部が暗号化されていることがある。暗
号化は、加入者とレジストラ間のセッション機密性を保持する目的で行われる（
他の目的のために行われることもある）。しかし、ある種のメッセージ要素を暗
号化して（レジストラに知られていない鍵を使用して）、本人に渡すことができ
る。メッセージ要素は、いずれかを暗号化することも、全部を暗号化することも
できる。

【００４９】 以下の行為は、サービスを加入者に提供するために実行されるものである（な
お、ここで加入者は１つまたは多数のシステムエンティティを表している）。さ
らに、このプロトコルが開始される前に、種々の当事者（加入者／レジストラ、
加入者／本人、レジストラ／本人）の間で交渉プロトコルが実行されている場合
があり、そこではサービスの条件が合意されている。

【００５０】 （加入者はサービスを要求する（メッセージフロー１）） 加入者は、自身に関連する要求をレジストラに送信する。メッセージフロー１
に関連する要求は次のものを含んでいる。 ・要求されたサービスのタイプを示す標識（例えば、初期またはある種の追加
サービスに「加入」すること、加入したサービスに関連するパラメータを「変更
」すること、サービスから「加入解除」すること。） オプションとして、要求は次のものの１つまたは２つ以上を含んでいる。 ・加入者および／またはセッションの単一レファレンス（例えば、これは、加
入者のＩＤ、ワンタイムサービスを表す仮名、またはサービスの継続使用を表す
仮名、などにすることができる。）セッションＩＤは、将来の応答をこの特定要
求（または要求の集合）にリンクすることができ、この中には、確認通知または
拒絶（拒否）メッセージが受信されたとき、加入者のコンテキスト情報を含める
ことができる。 ・加入者または加入グループに関する属性。次のものがある。 （ａ）自己表現 （ｂ）第三者を表わす表明属性。これには、次のものがある。 ・アドレス（例えば、仮想アドレス、物理アドレス） ・雇用情報（例えば、従業員） ・サービス提供のために必要とされる他のエンティティからの情報（例えば
、スタッフィングオフィスからの従業員番号など） ・他の当事者からの許可（例えば、サービスに対する第三者承認、委任、電
子「チケット」） ・認証情報。これは、サービスの使用を認証するためにサービスによって使用
される情報である。この中には、公開鍵、共有秘密、およびハッシュチェインの
要素を含めることができる。また、Diffie-Hellman鍵交換のラウンドのように、
秘密の値（例えば、鍵）を派生するために将来使用できる他の情報を含めること
も可能である。 ・トランザクションカウントやステートなどのトランザクション検証情報。こ
れは、トランザクションの有効性を検査するために本人によって使用される。（
この情報は、レジストラがトランザクションを加入者として作成するのを防止す
るために暗号化しておくことができる。）有効性検査を行うと、トランザクショ
ンが他のトランザクションのストリーム内で正しく保たれることになる。 ・加入者が受諾したものに合意する加入者による表現（サービスの項目と条件
、サービス料金の合意など）。支払いを送ることもできる。 ・好適サービス関係（preferred service relationship）。サービスプロバイ
ダは、これをガイドとしてオプションのサブサービスを探し出すことができる。
他のインフラストラクチャのサブ関係をサービス提供のガイドとして用意するこ
ともできる。 ・要求を受諾するために本人、レジストラおよび他のエンティティが必要とす
る他の情報 ・サービス提供のために本人、レジストラおよび他のエンティティが必要とす
る他の情報 ・本人、レジストラおよび他のエンティティが必要とするその他の情報（例え
ば、監査役（auditor）） ・加入者の真正を証明するもの（authenticator）：これはカレントメッセー
ジとその発信元の有効性を検査する。

【００５１】 （レジストラは要求を転送する（メッセージフロー２）） 加入者の検証を終えると（要にある真正を証明する人または人の要求などの他
のプロセスを通して）、レジストラは、要求を本人に転送し（メッセージフロー
２）、変更があれば、それも転送する。レジストラは、加入者の要求を自身で検
証することも、他の当事者との派生トランザクションを使用して検証することも
できる。転送される要求は、レジストラによって認証される。転送される要求に
は、次のような情報を含めることができる。

【００５２】 ・加入者からレジストラに送信されたフロー１からの情報（またはサブセット
）。さらに、次のような情報を送ることも可能である。 ・レジストラのＩＤ ・将来の応答を要求にリンクさせるレジストラの要求ＩＤ。この応答には、
確認通知を受信したときの加入者のメッセージコンテキスト情報を含めることが
できる。 ・レジストラによって提供される追加の要求属性と機能 ・加入者の要求機能、属性および契約に対する変更 ・レジストラによって要求に対して受諾された本人のＩＤ ・将来のレジストラのやりとりを検証するために本人によって使用される公
開および／または秘密検証鍵。または、他の暗号化関連情報。 ・レジスタ、本人および他のエンティティサービスの許容（受諾）コスト ・レジスタが受諾した内容を記述しているサービスの契約 ・将来の応答をこの特定要求（特定要求の集合）にリンクするレジストラの
要求ＩＤ。この中には、受諾または拒絶（拒否）メッセージが受信されたときの
レジストラのコンテキスト情報を含めることができる。 ・要求を受諾するために本人、レジストラおよび他のエンティティが必要と
する他の情報（例えば、好適サービス関係） ・サービス提供のために本人、レジストラおよび他のエンティティが必要と
する他の情報。 ・本人、レジストラまたは他のエンティティが必要とする他の情報（例えば
、監査役） ・ 上記情報のレジストラの真正を証明する人（秘密鍵認証または公開鍵署
名）

【００５３】 レジストラが要求を受諾しない場合には、レジストラは（認証された）拒絶メ
ッセージを加入者に送り返す（メッセージフロー４）。その際、このメッセージ
は、拒絶理由とサポート情報、拒絶ＩＤおよび要求（または要求のサブセット）
または要求のハッシュを付けて返送される。レジストラがそのサービスのコスト
を請求する場合も起こり得るが、その場合には、交渉プロトコルがあるので、レ
ジストラと加入者はコストを交渉することになる。

【００５４】 （本人は応答をする） 次に、本人は、転送された要求の認証性がレジストラによって検証されたあと
（メッセージフロー２）、応答を開始する。本人は、加入者の要求を検証する機
能をもっていれば（つまり、加入者の検証鍵をもっている）、その検証を行うこ
ともできる。本人は、機能を提供する前に必要とされる他の検証を行うこともで
きる。そのようなものとしては、ポリシチェック、犯罪記録チェック、銀行口座
検証、Ｄ＆Ｂレーティング、採用検証、アカウントのクレジッド限度額などがあ
るが、これらに限定されない。これは派生トランザクションを使用して行うこと
ができる。これらの第三者は、基本的には補助エージェントとレジスタラであり
、これらは機能または属性を直接に要求することはなく、加入者のＩＤ、属性お
よび／または機能を証明するだけである。

【００５５】 次に、本人は、受諾したことと、加入者が要求機能に関して必要とする認証／
許可情報を記載している確認通知を、レジストラに送信する（メッセージフロー
３）。加入者が機能を使用できるようにするために必要とされる追加情報の一部
には、ポリシ、加入者の公開鍵証明のほかに、システム内の他のエンティティが
あり、指示などを含めることも可能である。将来の応答をその特定要求にリンク
するための新しい要求ＩＤ、または予め生成された要求ＩＤを、メッセージに含
めておくこともできる。同様に、ＩＤにではなく、トランザクションにリンクさ
れた単一暗号化鍵を使用することができる。

【００５６】 提供できる他の情報としては、受諾コストと受諾契約がある。このメッセージ
（メッセージフロー３）は、レジストラに検証させるために、および加入者に検
証させるために（加入者が本人の検証鍵をもっている場合）認証される。

【００５７】 本人が機能を提供することを拒否する場合は、本人は、拒絶理由を付けた認証
済み拒絶メッセージを、メッセージフロー１および／またはメッセージフロー２
（および／またはそのハッシュ）と一緒にレジストラに、または直接に加入者に
送信することができる。レジストラは、フロー２で説明した拒絶プロトコルを使
用して加入者に送信することができる。

【００５８】 （１．１ レジストラは受信メッセージの認証性を検証する） レジストラは、受信メッセージの認証性を検証し（メッセージフロー３）、正
しければ、確認（受諾）メッセージを加入者に転送する。レジストラの確認通知
には、サービスに対する最終コストといった追加情報を含めておくことができる
。

【００５９】 （メッセージフロー５） １．本人が要求を開始する場合であっても、ユーザは、サービスを活性化するた
めの要求を得るために他のオペレーションを実行しなければならないことが起こ
り得る。加入者は、これらのオペレーションを実行したあと、その時点では要求
機能を取得していないことがある。その場合、加入者は、完全機能を得るために
本人と追加の通信を行うことが要求されることになる。追加情報は、起動手続き
で使用されるために、確認通知メッセージの中でユーザに送信されていることが
ある。

【００６０】 なお、レジストラは、システム内でオプションのエンティティとなることがで
きる。その場合には、本人は、レジストラの責任を代行できるので、レジストラ
の情報をブランクにしておくことで、より単純化されたプロトコルを実現するこ
とができる。

【００６１】 なお、上記プロトコルには、複数のレジストラ、複数の本人、および複数の加
入者を組み込んでおくことが可能であり、本明細書全体を通しても同様である。
いくつかの例を示すと、次の通りである。

【００６２】 複数の加入者：機能または属性がグループに基づくことがある。例えば、定義
された加入者の集合からの、少なくとも事前指定の定足数（quorum）の各々が署
名したときだけ、つまり、複数の加入者から単一の署名を行う、しきい署名方式
（threshold signature scheme）に基づいて行うことができる機能（例えば、Me
nezes, van Oorshut, Vanstone共著「The handbook of Applied Cryptography」
を参照。なお、本書の内容は引用により本明細書に含まれている。）これを可能
にするには、レジストラは、加入者の各々を取り扱い、１つのバッチまたは複数
の要求を上方に送信することができる。別のメカニズムでは、要求は個別に本人
に送信され（必要ならば、レジストラ経由で）、本人はポリシと機能に基づく必
要数が受信されたとき要求を管理している。

【００６３】 複数のレジストラ：レジストラは、特定の属性と機能に対してだけ要求するこ
とができ、あるいは要求することが許されている場合がある。そのような場合に
は、複数のレジストラは、行われた要求の構成が機能の構成となるように要求を
行う必要が起こることがある。つまり、レジストラＡが要求できるＸをユーザが
必要とし、レジストラＢが要求できるＹをユーザが必要としていれば、そのユー
ザはＡおよびＢと協働して、本人に対して要求を行う。これらの要求は、Ａから
Ｂへのシリアル順に本人に対して行うことができる（同様に、ＢからＡへのシリ
アル順に）。もう１つの方法は、すべての要求の各々が本人に現れたときであり
、本人はすべての要求を結合して、結合された機能／属性にする。また、レジス
トラは、レジストラが要求する機能ではなく、レジストラが実行する特定の検証
だけを証明することがあるので、あるポリシに基づく本人は、２つ以上のレジス
トラに加入者を登録させる必要がある。

【００６４】 複数の本人：ある本人は、十分な機能または属性を提供できないが、複数の本
人ならば提供できる場合である。これの例として、複数の保険会社（リスクを共
同負担する）のグループがある。別の例として、あるエンティティに関連する金
融情報と身元情報を保証する場合がある。この例では、ある本人は身元検証を扱
うことができるのに対し、別の本人は金融データを扱うことができる（このよう
に分離したのは、オペレーションとプライバシに制約があるためである）。

【００６５】 説明を簡単にするために、これらの複数エンティティプロトコルは、明示的に
解説されていないときでも、以下の説明個所のどこかに現れている。

【００６６】 登録はいくつかのステージで行われる。登録は交渉から始まり、そこでは「実
際の登録」は行われず、条項と条件を有する応答を受け取る。続いて、「登録簿
登録（enrolment registration）」が行われ、そこでエンティティが登録される
。そのあとに「起動登録（activation registration）」が続き、そこでサービ
スが実際に開始する。これらのステージが必要になるのは、保全性を保証し、検
査と検証を可能にするためである。

【００６７】 なお、ユーザは、サービスのためにプロキシサーバに登録することが可能であ
る。

【００６８】 また、プロキシまたはグループの代表者は、登録のためのグループリストを、
「バルク」で送ることも可能である。

【００６９】 登録プロセスは双務的であることが多い。つまり、一方のサイドは、サービス
を提供する機能をもつようにレジストラによって保証されているのに対し、他方
のサイドは、信用性のあるサービス受取人になるように保証されている。例えば
、一方のサイドは、金融サービスを要求することがあるので、そのサイドが登録
される組織は、その分野の能力と知識があることが保証されている必要がある。
他方、組織は、金融サービスの要求者の背景とある種の金融経歴を知っている必
要がある。双務的マッチング機能（クレジットを受ける人とクレジットを与える
人との）は、多くのシナリオでは代表的になっている。

【００７０】 最後に、登録と他の機能発行手続きが終了したときの応答は、マイクロプロセ
ッサ、ディスケット、またはスマートカード、あるいはバンド外（out of band
）でユーザに送信される紙に印刷された情報にすることができる。上記以外にも
、多数の変種が可能であり、これらは公知であるが、本発明の範囲に含まれるも
のである。

【００７１】 （契約署名） 図１の登録プロトコルを使用すると、信託された第三者を通して契約署名プロ
トコルを得ることができる。このプロトコルは、両当事者の署名による公平性と
相互のコミットメントを提供する。

【００７２】 登録プロトコルは、図１のメッセージフローとして実行され、本人と加入者と
の間で合意の交渉が行われ、そこでは、契約は、例えば、要求の中の属性または
他の情報にすることができる。両当事者が合意したとレジストラが認めると（本
人が確認通知したメッセージを調べることにより）、レジストラは、各当事者に
契約の暗号化署名を送信させる。なお、どちらの当事者も他方の当事者の署名を
読むことができないが、レジストラは読むことができる。次に、レジストラは、
合意された契約と共に各当事者の署名を検証する。両方の署名が検証されると、
レジストラは、本人の署名を加入者に、加入者の署名を本人に送信する。

【００７３】 このプロトコルは、非常にフレキシブルである。ここで説明しているプロトコ
ルは、３人以上の契約署名者用に変更することができる。また、加入者と本人が
、相互に合意された、いくつかの異なるドキュメントに署名することも可能であ
る。

【００７４】 この分野で公知であって、アーキテクチャで使用可能な契約署名プロトコルは
他にも存在する。

【００７５】 （機能または属性の変更） ある機能を追加する登録プロトコルと同様に、機能または属性の変更（削除を
含む）が必要になるケースもある。

【００７６】 １つのメカニズムは、本人が加入者の許可なしで変更を行い、認証済み通知を
加入者に送信するためのものである。変更は永続的なものと、一時的なものとが
あり、通知には、次のものを含めることが可能である。 ・変更の範囲 ・カバレッジの日付 ・変更理由 ・トランザクションを実行するために加入者が必要とする追加情報（例えば、
鍵など） ・上記のすべての認証

【００７７】 変更オペレーションは、ユーザによって開始することができる。変更を行うメ
カニズムはいくつかがある。レジストラを経由する本人に対する変更要求は、登
録要求フラグに「登録」ではなく、「変更」または「加入解除」のマークを付け
ることによって、登録プリミティブと同じように実行することができる。一般的
に、レジストラは、グループのスーパバイザである。別のメカニズムも存在する
が、そこでは、ユーザの検証鍵は本人によって保持されている。この場合には、
ユーザは、本人がレジストラを通さないで変更することを許容していれば、ユー
ザの検証鍵を使用して要求を直接に行うことができる。変更オペレーションは、
ユーザまたはグループのスーパバイザによって開始させることも、それらに代行
してプロキシに開始させることも可能である。

【００７８】 情報を搬送するプロトコルフローは、図１のプロトコルの構造に従って行うこ
とができる。

【００７９】 （認証情報または他のステート情報のリフレッシュ） 加入者と本人によってストアされた情報は、時々リフレッシュする必要がある
。以下では、システムはマスタ鍵とトランザクション鍵の両方をもっているもの
とする。マスタ鍵は、トランザクション鍵をリフレッシュするためにだけ使用さ
れるので、マスタ鍵が使用される頻度は少なく、その働きも制限されている。従
って、マスタ鍵は危険にさらされることが少なくなっている。リフレッシュは、
機能を保守するメカニズムとなるので、機能を頻繁に反復すると、その有効性が
保たれることになる。

【００８０】 これは、本人と加入者が、登録プロトコルまたはそれに続くプロトコルの間に
、マスタ鍵とステート情報の両方を設定することによって達成することができる
。設定されたマスタ暗号化および／または認証鍵を使用すると、加入者は、認証
済みチャネル上で暗号化を行うことができ、そこでは、加入者、レジストラまた
はその双方は、新しいトランザクション鍵とステート情報の両方を設定するため
に使用できる情報を秘密に送信することになる。Diffie-Hellman鍵交換などの、
認証済み公開鍵交換プロトコルを使用すると、秘密チャネルは必要でなくなる。
また、秘密鍵が各当事者に共有されているときも、認証済みチャネルが必要でな
くなる。秘密機能は、新トランザクションと新ステート情報の両方を生成するた
めに臨時的に実行されるので、各当事者は新トランザクション鍵と新ステート情
報を知っていることを証明してから、古い鍵とステートを破棄することになる。
情報をリフレッシュするための他の方法は、この分野では多数のものが知られて
いる。

【００８１】 （仮名） 加入者が以後のトランザクションのために仮名（pseudonym）を使用する必要
が起こる場合がある。そのようなケースでは、登録プロトコルに組み込むことが
できる方法が多数存在している。

【００８２】 仮名は、暗号鍵を使用してユーザのＩＤとして暗号化しておけば、本人は暗号
鍵を使用して解読し、真のＩＤを取得することができる。これは、加入者からレ
ジストラに、そのあと本人に送られる登録フローの一部にすることができる。こ
れは、登録期間に設定された鍵を使用して登録プロトコルのあとで合意すること
も可能であり、また、これを本人に生成させ、登録プロトコルで確認通知メッセ
ージの中で加入者に送信することもできる。仮名を取得し、長期間、短期間およ
びトランザクションごとに維持しておくための方法は、この分野では種々のもの
が知られている。

【００８３】 （レポーティング） エンティティは、相互に対して定期的レポーティングを行うことができる。認
証性の設定は、秘密鍵の認証、公開鍵の認証、物理的配達（例えば、メール）、
および他の手段を通して行うことができる。機能と属性のステートの定期的レポ
ーティングは、本人から加入者、グループ、スーパバイザ、および他のエンティ
ティに対して行われることが予想される。基本的に重要なことは、クレジット残
高、許容限度額などのレポーティングのように、ステートと属性がダイナミック
である場合に、定期的レポーティングが行われることである。

【００８４】 レポートを編集し、レポートの有効性を検査し、署名し、送信するための方法
は、この分野では種々のものが知られている。

【００８５】 （モニタリング） 重要な機能を実行するエンエィティの制御を確固たるものにするためには、別
のエンティティのアクションをトランザクション単位で許可する管理タイプのエ
ンティティが存在することが必要である。このプロトコルの構造は、モニタリン
グの対象となっているエンティティが、モニタリングオペレーションを否定でき
ないようにする。モニタリング手法は、この分野では種々のものが知られている
。

【００８６】 （通知メッセージ） 通知メッセージは、認証されるのが通常のメッセージであり、加入者は、その
機能、属性またはトランザクションのステータスについて、このメッセージで本
人に通知する。このメッセージは、本人にパフォーマンスを要求することもでき
る。

【００８７】 ユーザからの通知の一例として、本人からのサービス品質が不十分である場合
がある。加入者と本人との合意に応じて、補償を要求する通知もある。また、ト
ランザクションに関して加入者に対する本人の担保、保険またはその他の義務に
対する請求である場合もある。そのような場合には、サポート情報（トランザク
ションに関する通信のすべてまたはサブセット）が提供されることになる。補償
が要求されるときは、通知は、期待する補償の内容とその受け渡し方法を明示す
ることができる。サービスおよび関係に応じて、本人のサービスが、もう一ヶ月
間無料で提供されることを求める要求である場合も、メールでチェックを要求す
る場合も（アドレスを指定して）、銀行口座やＩＯＵや銀行為替手形に電信振替
することを要求する場合もある。クレジット限度額のように、機能または属性の
変更を要求する場合もある。通知メッセージは多種類になることが予想され、こ
れらは作業環境によって左右される。

【００８８】 代表例としては、本人から加入者への応答（受諾、拒絶、または変更提案）が
ある。通知と応答がリンクされているような、納得のいく合意が得られるまでは
、交渉プロトコルの実行が必要になる場合がある（契約署名と同じで、レジスト
ラを含む場合と含まない場合とがある）。これらのメッセージは、契約、取り消
されたチェック、および通知メッセージで与えられない他の情報のように、追加
のサポート情報について照会する場合もある。

【００８９】 通知は、本人と加入者の間で行われるのが中心であるが、これらの当事者に限
定されるものではない。通知は、例えば、システムで紛争が起こったとき行われ
る。従って、レジストラと加入者の間と本人とレジストラの間でも通信が行われ
る。これらの関係は、例えば、費用とサービスの品質に基づいている。特にレジ
ストラに対しては、登録要求のステータスを求める要求だけの場合もある。

【００９０】 （変更トランザクション処理プロシージャ） 通知と同じように、例えば、ある種の手続きの変更を別のエンティティに指示
する要求が、ユーザによって行われる。関係およびエージェントと好適サービス
関係の変更は、他のトランザクション特性と同様に、そのユーザ（またはエンテ
ィティ）の裁量に任されている。

【００９１】 なお、機能には、エンティティ自身が裁量で変更するものと、外部の承認を必
要とする機能とがある。

【００９２】 （サービス移行） エンティティまたはグループは、サービスを提供するエンティティの所属を移
動することができる。例えば、加入者のグループは、特定のサービスを提供する
ために使用されるレジストラと本人を変更することができる。これは、そのよう
な変更を要求する権限を持つスーパバイザであるのが一般である。この機能を使
用すると、加入者に対する混乱を最小限にしてサービスプロバイダを変更するこ
とができる。

【００９３】 この機能のもう１つの使い方は、グループのサイズが小さいとき、始めに複数
のグループからのサービスをエンティティによって提供させ、提供サービスを新
しいサービスプロバイダに移動することを可能にする。このようなケースでは、
サービスプロバイダによって使用される「ブランディング（branding）」または
ＩＤは、将来に意図されている構造を反映することができる。

【００９４】 関心のあるサービス移行では、サービスは外部エンティティ（プロキシ、サー
ビスプロバイダ）から自身に転送されている。例えば、ある会社は、別の会社が
サービスをその従業員に提供する権限を与えることができる（証明権限サービス
、金融サービス）。別の時期に、サービスはその会社自身に移動される。

【００９５】 暗号手法では、このような移行には、暗号鍵を開かなくても、暗号鍵を安全に
移動する手法を採用した「安全な鍵移動」が必要になる。

【００９６】 サービス移行のためのプロトコル例は図２に示されている。ユーザ（加入者）
は、認証されたメッセージを起動し（メッセージフロー１）、そこには、どのサ
ービスをどのエンティティからどのエンティティに移動するか、例えば、エンテ
ィティ１からエンティティ２に移動することが指示されている。メッセージフロ
ー１は、システム内の機能を許可し、保証することを担当するスーパバイザに送
信される。このスーパバイザは、メッセージの発信元、有効性および保全性をチ
ェックする（メッセージフロー１）。次に、スーパバイザは、メッセージフロー
２を作成し、そこには、指定されたサービスの機能をスーババイザに戻すことを
求める、エンティティ１に対する指示が含まれている。この機能は、スーパバイ
ザの有効性と許可をチェックしたあと、エンティティ１によってスーパバイザに
移動される。エンティティ１は、メッセージフロー３をスーパバイザに送信し、
サービスの放棄を指示する。次に、スーパバイザはメッセージフロー４を送信し
、ユーザに代行する特定サービスが要求されたことをエンティティ２に通知する
。エンティティ２は、メッセージフロー５の中でスーパバイザに応答し、受諾ま
たは拒絶がメッセ−ジフロー６でユーザに送り返される。サービスは、即時に開
始されることもあれば、ユーザの実際の登録をエンティティ２に保証するために
登録トランザクションが必要になる場合もある。拒絶の場合には、ユーザに通知
され、スーパバイザがそのサービスを保留していることになる。ユーザは、必要
ならば、プロトコルを再起動して、サービスをスーパバイザからエンティティ２
とは別のエンティティに移行することができる。

【００９７】 上記は、移行がスーパバイザでどのように処理されるかを示す１つのシナリオ
にすぎず、エンティティ１で機能を取り消し、エンティティ２でサービス機能を
容認する必要があることを示している。

【００９８】 （サービスビューロコンポーネント（service bureau components）） 図３は、本発明の実施形態によるバックエンド・インフラストラクチャのコン
ポーネントを示す図である。このセクションでは、上述したプリミティブを使用
して機能を提供するという考え方を詳しく説明している。これまでのセクション
では、機能の説明が中心であり、実際のコンポーネントの説明は行っていなかっ
た。コンフィギュレーションとしては、多数のものが可能である。

【００９９】 （レジストラ） レジストラエンティティは、それ自身で複数のエンティティで構成することが
できる。そのためには、サービスを複製し、レジストラの機能をコンパートメン
ト化する必要がある。例えば、レジストラの機能には、属性の要求が許されてい
るものと、それが許されていないものとがある。

【０１００】 レジストラは、次のようにシステムに組み込まれる設計になっている。

【０１０１】 １つまたは２つ以上のルートレジストラ権限（root registrar authorities）
は、レジストラのレジストラと共に生成される。ここで、登録プリミティブ、新
しいレジストラ、プリミティブにおける加入者の働きを使用すると、登録プリミ
ティブでレジストラの働きをするレジストラのレジストラを通して要求すること
ができ、登録プリミティブで本人の働きをするルートレジストラに対してレジス
トラ機能／属性を有する。

【０１０２】 図４は、２つのルートレジストラの例を示しており、そこでは、複数のレジス
トラは、加入者の異なる属性を要求することが許されている。図に示すように、
加入者ｂは、３レジストラをすべて使用して、属性Ｗ，Ｘ，ＹおよびＺを得てい
る。他方、加入者ａは、１つのレジストラだけを使用して属性Ｗを得ている。加
入者からの要求は、非ルートレジストラによって定義された機能と属性および非
ルートレジストラに許可を与える本人によって提供される機能と属性に応じて、
ルートレジストラに渡される場合と渡されない場合とがある。

【０１０３】 上述し、図５に図示のシステムは、管理モニタリング機能を追加すると強化す
ることができる。その目標は、エンティティ１とエンティティ２が正しくオペレ
ーションすることを保証することである。図示のように、その中には、マネージ
ャによるトランザクション単位の観察が含まれている。管理機能の１つとして、
エンティティ１または２によって未処理のままに許容される総負債額を制限する
機能がある。これは、トランザクション単位の交換Ａ，Ｂ，ＣおよびＤによって
サポートされている。

【０１０４】 モニタリングが正しく行われていないとトランザクションが行われないようす
る手法は、いくつかのものが採用されている。最初の手法では、各トランザクシ
ョンは、２つのエンティティによってレポートが可能になっている。（エンティ
ティ２は、エンティティ１が唯一の負債保持当事者である場合でもレポートを行
うようになっている）。もう１つの手法では、有効性検査されたコンポーネント
が、マネージャから最終的応答当事者への戻りメッセ−ジに組み込まれるように
なっている（ユーザ１またはユーザ２、両方のこともある）。この有効性検査さ
れたコンポーネントは、ＢまたはＤに組み込まれており、戻り通路を通って必要
に応じてユーザ１または２に送られる。

【０１０５】 （加入者） 加入者（図３参照）は、登録プロトコルで初期化される。プロセスとして、加
入者はシステムから、あるいは第三者（図示せず）経由で指示を受け取る。次に
、加入者は、必要な情報を収集し、レジストラに対する受理可能な要求を作る必
要がある。当事者は、サービスに対する契約または条項と条件（例えば、費用）
を交渉することができる（機能と属性で表されている）。本人またはレジストラ
から確認通知の応答があると、サービス適用のための、加入者が要求した機能と
属性および他の情報は起動されるので、ユーザは、セットアップを完了するため
に別のやりとりを要求することができる。拒絶のときは、ユーザはこのオペレー
ションをやり直す必要が起こる。

【０１０６】 なお、要求と拒絶は、将来のやりとりがリンクされるように特定することがで
きる。このようにすると、ヒストリ、監査の維持が可能になり、また、すでに実
行されていれば、ある種の処理を繰り返す必要がなくなるのでコストが低減化さ
れることになる。

【０１０７】 なお、加入者は、他の加入者に対して本人となることができる。上述したよう
に、加入者は、例えば、レジストラになることも、システム内の別のエンティテ
ィになることもできる。なお、インフラストラクチャが単なる階層でないのは、
加入者が複数の本人を使用して、例えば、上位機能の本人となることができるか
らである。このようにすると、ルート本人を２つ以上にすることができる。この
設計は非常にフレキシブルである。

【０１０８】 （本人） 本人は、それ自身１つまたは２つ以上のエンティティで構成することができる
。これは、サービスを登録し、あるいは本人の機能をコンパートメント化するた
めに必要になるものである。

【０１０９】 本人をシステム内に構築するために、１つまたは２つ以上の本人の権限が、本
人レジストラと共に生成される。ここで、登録プリミティブを使用すると、プリ
ミティブで加入者の働きをする新しい本人は、登録プリミティブでレジストラの
働きをする本人レジストラを通して、登録プリミティブで本人の働きをするルー
ト本人に対して本人機能を有することを要求することができる。これについては
、上述した。

【０１１０】 （グループ登録） 加入者（複数の加入者）は、グループのユーザを登録する機能をもつレジスト
ラへの登録プロトコルの期間中に、定義されたグループの特定機能および／また
は属性を要求することによって、グループに組み入れることができる。同様に、
これは変更プロトコルで行うこともできる。グループマネージャとスーパバイザ
の設定は、この時点で判断することができる。

【０１１１】 類似のプロトコルを実行すると、本人やレジストラなどの、他のタイプのエン
ティティグループを設定することができる。さらに、プロキシがグループを登録
することもできる。

【０１１２】 （マネージャ） マネージャには、いくつかのタイプがある。マネージャは加入者と同じように
初期化されるが、マネージャの役割を持つように初期化される。システムエンテ
ィティは、属性証明を通してマネージャとして指定することができる。さらに、
マネージャは、機能、委任、および可能ならば他の情報を受け取ることができる
。

【０１１３】 権限を有する本人に対するマネージャは、多数の機能をもつことができる。そ
のような機能としては、レジストラの監査、やりとりの保存、異常検出などの機
能、ランダムテストなどの品質保証機能、およびシステムパラメータの集約など
がある。マネージャの主要な役割は、共有リソースを管理することである。例え
ば、マネージャは、「アドレス空間」（フィールドに関連する）のある部分の割
り当てを各レジストラに委任することができる。マネージャの別の役割は、ある
種のシステムエンティティへの通信アクセス（またはアクセスのレート）を制限
することである。

【０１１４】 マネージャは、トランザクションをグループ化し、関連付ける役割を持つこと
もできる。例えば、マネージャは、トランザクションをカテゴリ別に分割するこ
とができる。例えば、トランザクションは、リスク別に分類することができる。
また、トランザクションの集合は、もっと大きなグループになるように結合する
ことができる。大きくされたグループの各々は、値、リスクパラメータなどの共
通特性を持つことも、各々が同じ開始鍵を持つこともできる。

【０１１５】 グループと加入者の他のマネージャとエンティティからレポーティングを受け
取るマネージャもいる。これらには、監査役割をもつマネージャ、加入者または
グループに対する変更を要求できる、あるいはレポートを該当エンティティに転
送するだけのスーパバイザとしてリスク管理役割をもつマネージャがいる。これ
らは、レポートを受け取る該当エンティティによって区別される。

【０１１６】 あるマネージャは、グループまたは加入者のスーパバイザとなり、グループの
レジストラの働きをすることができる。これらのスーパバイザは、グループの機
能、属性またはその他に対する変更を要求することもできる。

【０１１７】 これらのマネージャは、暗号化機能を実行することもできる。例えば、鍵と加
入者提供情報のバックアップ機能を実行することができる。これが必要になるの
は、例えば、法律上および／または強固上の理由によるものである。この場合も
、加入者は、基本的には、他のマネージャを含む、どのエンティティにもなるこ
とができる。

【０１１８】 （インフラストラクチャ内のオペレーション） サービスビューロなどの、インフラストラクチャおよびコンポーネントについ
て説明してきたが、次に、登録されたエンティティとサービスエンティティの集
合（オーバラップしていることもある）が与えられているときの、インフラスト
ラクチャ内のオペレーションについて説明することにする。

【０１１９】 第１ユーザなどのエンティティは、担保を要求するトランザクションを起動す
ることができる。この起動は、システム要素（本人）を伴い、そこでは、別のユ
ーザがクレジットのために登録されている。基本的な例では、あるトランザクシ
ョンコンテキストについて、最初のユーザが保証要求を開始するようになってい
る。トランザクションのメッセージのフローは、メッセージの正確な性質が開示
されている「Frankel他」のメッセージフローに従うことができる。拡張された
登録ユーザのコンテキストでは、プロバイダは、登録ステータスをチェックする
必要があり、これはユーザの経歴とステートの一部になっている。このトランザ
クションは、第２ユーザとインフラストラクチャ・エンティティが係わりを持っ
ており、そこでは、第２ユーザはサービスのために登録されている。すなわち、
このエンティティは、第２ユーザによって行われた表現が有効であることを第１
ユーザに保証することができる。第１ユーザはその担保を受け取る。

【０１２０】 なお、担保発行者は、リスク管理サブシステムと相談することも、発生したリ
スクを評価する補助エージェントと相談することもできる。

【０１２１】 このようなトランザクションが完了したとき、第１ユーザは、他のユーザがト
ランザクションで要求したものを提供するとの保証が得られる。その他の場合は
、他のユーザに代わって保証を発行したエンティティに対する担保が得られる。
トランザクションが失敗したときは、担保から派生するものとして当然に行われ
る請求のための、後続トランザクション（例えば、通知）が出されることになる
。この後続トランザクションでは、ある程度の補償が求められることになる。

【０１２２】 なお、ユーザがある程度の補償を要求する請求を始めるようなトランザクショ
ンは、最初に担保を出したプライマリエンティティに送ることができる。そのエ
ンティティは、別のエンティティ（保険エンティティ）を要求するトランザクシ
ョンを開始し、そこでトランザクションが出されることになる。これは派生トラ
ンザクションであり、そこでは、保険エンティティはプライマリエンティティに
対してある程度のカバレッジを提供することができ、プライマリエンティティの
方は、ユーザに対してある程度の補償を提供することができる。派生トランザク
ションのメッセージフローは、「Frankel他」の部分的メッセージ集合に従うこ
ともできる。別の派生トランザクションでは、再保険トランザクションは、多数
の初期トランザクションの集約に基づいている。

【０１２３】 図５に例が示されている。ユーザ１は、ユーザ２に対して担保を必要としてい
る。ユーザ１はその要求と共にメッセージ（メッセージフロー１）をユーザ２に
送信する。ユーザ２は、メッセージの有効性をチェックすると共に、トランザク
ションの記述の正確性とこれらのユーザが行っているセッションをチェックする
。そのあと、ユーザ２は、担保要求と、その有効性と認証性情報を、カレントト
ランザクションのコンテキストで担保の問題を扱っていると思われる、そのサー
ビスプロバイダ、すなわち、エンティティ２に転送する。メッセージフロー２は
、要求を搬送する。そのあと、エンティティ２は、エンティティ４との派生トラ
ンザクションを開始することになる。エンティティ２は、例えば、トランザクシ
ョンの内容が有効であり、トランザクションを扱うことが合法的であるとの事実
に関する保証を要求できるメッセージフロー（メッセージフロー３）を転送する
。エンティティ４は、トランザクションが合法的でない場合には責任を負うこと
になる。エンティティ４は、メッセージフロー４でエンティティ２に応答し、責
任サービスを提供する。メッセージフロー２からの情報、場合によっては、メッ
セージフロー５と必要な暗号化フィールドに関係する情報は、メッセージフロー
５でエンティティ１に送信される。メッセージフロー５の内容は有効性検査され
、エンティティ１は、エンティティ３との派生トランザクションを開始する。エ
ンティティ１は、トランザクションの記述とそのトランザクションに関してエン
ティティがもっている情報を、メッセージフロー６でエンティティ３に転送する
ことができる。また、自身とエンティティ２との契約条件を転送することができ
る。トランザクションは、発行される担保に対する保険が係わりをもつことにな
る。エンティティ３は、転送されてきたメッセージフロー６の情報を評価するこ
とができる。エンティティ３は、保険を提供することを決定できる。これはメッ
セージフロー７で返送される。ここで、エンティティ１は、担保を提供すること
に伴うリスクを評価することが可能になる。エンティティ１は、要求された担保
（またはその一部）を提供することを決定することができる。これはメッセージ
フロー８でエンティティ２に転送される。エンティティ２は、受け取った情報を
記録しておき、その正確性、保全性および発信元の有効性を検査することができ
る。そのあと、エンティティ２は、その保証と担保の応答を付けてメッセージフ
ロー９を転送する。ユーザ２は保証を受諾すると、その受諾を付けてメッセージ
フロー１０をユーザ１に転送することができる。

【０１２４】 プロセスが完了すると、その結果として、担保によって許容される他の、ある
種のトランザクションが行われる。すべてが順調であれば、それに関するレポー
トがユーザから開始されることになる。なんらかの障害が発生した場合には、ユ
ーザ２は、エンティティ１に対して請求を開始することができ、他のエンティテ
ィ（保険者としてのエンティティ３など）が係わりをもつ派生トランザクション
が行われることになる。この種のトランザクションは、保険者、担保引受当事者
および他の当事者（保険請負業者）による支払いの交渉と支払いが係わりをもつ
ことになる。

【０１２５】 情報を集約すると、トランザクションのバルクレポーティングが得られること
になる。その結果、和解と請求処理トランザクションが発生することになる。こ
のことは、レコードの自動監査を可能にし、規制や他の法律的要件に準拠するこ
とを容易化することにもなる。

【０１２６】 なお、上述した結合トランザクション（１つの初期保証トランザクション、派
生法的保証と保険トランザクション）は、種々のエンティティ間の、ある種の既
存関係が係わりをもち、そこでは、あるエンティティは、現在、サービスのため
に別のエンティティに登録されている。ユーザ１は、トランザクションの特定の
分野で担保を発行するためにエンティティ１に登録されている（すなわち、ユー
ザ１は、その特定分野でユーザ１によって作られた代表者に対する担保を発行す
るためにエンティティ１を要求する）。ユーザ２は、エンティティ１などのエン
ティティのＩＤおよびある種の機能と属性を保証するために、エンティティ２に
登録されている。エンティティ２は、代表者に関する法的保障を提供するために
エンティティ４に登録されている。最後に、エンティティ１は、トランザクショ
ンの特定分野における拡張担保に対する保険のためにエンティティ３に登録され
ている。

【０１２７】 すべての登録は、エンティティ４がエンティティ２のために法律サービスを提
供するために登録されているとき、他方のエンティティ２は、トランザクション
の分野で担保を求めるユーザのための信頼性サーバとしてエンティティ４に登録
されているという意味で双務的である。

【０１２８】 上記の例は、インフラストラクチャをオペレーションする例を示したにすぎな
い。他の多くのユーザは、保険要求とポリシ発行、信用状要求、ドキュメント変
換トランザクションに従うことができ、そこでは、サービスはドキュメントの所
有権署名、情報へのアクセス許可、船荷証券の変換などが係わりをもっている。
内部メッセージフロー構造と暗号化の使い方は、「Frankel他」に開示されてい
る内容から類推することができ、この分野の精通者ならば、種々のフィールドは
新コンテキストに従って適応することが可能である。

【０１２９】 実際には、図５自体は、他の多数のオペレーションシナリオを表すことを可能
にしている。具体的には、図５は完全に異なる、別のシナリオを表しており、金
融証明権限インフラストラクチャ内のユーザのステート有効性を検査することが
係わりをもっている。ここでは、ユーザ１がユーザ２に関する保証を必要とし、
その保証は、そのＩＤとユーザ２の金融状態の代表者の有効性とを保証している
、ユーザのデジタル署名の有効性が係わっていると想定することにする。ユーザ
１は、メッセージフロー１で有効性検査クエリ（validation query）（新しい情
報と一緒に）を開始すると、ユーザ２はそのクエリを転送し、エンティティ２へ
のクエリを許可する。なお、エンティティ２は、その金融状態を記録している銀
行になっている。エンティティ２は、派生トランザクションを開始し、要求者（
エンティティ１）のＩＤが正しいことを保証する。エンティティ２は、エンティ
ティ４であるユーザ１の証明局（ＣＡ）へのクエリを開始する（これはメッセー
ジフロー３で行われる）。この有効性は、メッセージフロー４でＣＡによって承
認することができる。ここで、銀行（エンティティ２）は、ユーザ２のＩＤ有効
性のクエリを、メッセージフロー３でエンティティ１（これは、エンティティ２
に代行してＣＡを運用する別の銀行であることもある）に転送することができる
。証明チェックの要求を受け取ると、エンティティ１は、そのエンティティ、つ
まり、エンティティ３のために働いているレポジトリのオペレータにクエリする
ことができる。エンティティ１は、そのクエリをメッセージフロー６でエンティ
ティ３に送信し、メッセージフロー７で応答を受け取る。ここで、ユーザ２の証
明（ＩＤ）の有効性が保証され、メッセージフロー８でエンティティ２に転送さ
れる。次に、エンティティ２はユーザ２の金融状態をチェックし、メッセージフ
ロー８で受信されたユーザ２のＩＤ有効性と一緒に金融状態の有効性を、メッセ
ージフロー９で送信する。ここで、ユーザ２は、ＩＤと金融状態の完全な有効性
を要求者のユーザ１に転送することができる。暗号的にいうと、トランザクショ
ンチェイン上のエンティティは、新しい情報とのバインディングも使用していた
ので、ユーザ１は、ユーザ２に関する正しい最新の表現を受け取ったことを知る
ことになる。

【０１３０】 このトランザクションで基礎となるサービス登録は、次のように行われる。ユ
ーザ２は、ＩＤ有効性のためにエンティティ１に登録され、ユーザ１は、同じサ
ービスのためにエンティティ４に登録される。エンティティ２は、ユーザ２の銀
行であり、ユーザ２の金融状態を報告することを担当している（すべてのユーザ
のためのＣＡサービスをエンティティ１から受け取ることもある）。エンティテ
ィ１は、エンティティ３からリポジトリサービスをリースしている。なお、ユー
ザ２は、そのサービスがエンティティ１と２の間で分割されている。一方はＩＤ
証明を担当し、他方は金融情報の証明を担当している。

【０１３１】 上記の例では、金融サービスとＩＤ証明が中心になっていた。他のサービス分
野での要求も同じようになっている。医療レコードの要求と、そのレコードから
の要求情報の応答は別のトランザクションであり、これは、インフラストラクチ
ャを使用し、上述したメッセージフローに従って実行することができる。「セン
シティブ情報にアクセスする」要求は、同じように扱うことができ、そこでは、
リモートユーザはサーバに尋ねて、インフラストラクチャがある種の内容を他の
ユーザに解放することを許容しているかを確かめることができる。

【０１３２】 本発明のすべての実施形態において、メッセージおよび／またはトランザクシ
ョンは、条項の交渉、例えば、メッセージおよび／またはトランザクションの提
供またはサポートについての費用の交渉が先に行われるようにすることができる
。あるトランザクションいくつかおよび／または全ての当事者の間で交換される
いくつかおよび／またはすべてのレポートを生成することができる。これらのレ
ポートは、そのトランザクションに関係するどのエンティティにも提供すること
ができる。本発明のすべての実施形態では、トランザクションのどの当事者も仮
名を使用することができ、いくつかおよび／または全てのメッセージは暗号化お
よび／または認証することができる。本発明のすべての実施形態では、すべての
メッセージは、実際にはメッセージのバッチにすることができる。

【０１３３】 （サービスオペレーションの例、それがもつ意義および特性） 本発明によれば、サービスビジネスの多数の組織が許容され、可能にされてい
る。本発明によれば、多数の組織が集合し、サービスのために合弁事業を決定す
ることを許容し、可能にしている。本発明によれば、規制された産業が「オンラ
イン」ビジネスで運営すると共に、許可とライセンスを与えるようにすることを
許容し、可能にしている。本発明によれば、会社がサービスを編成し、サポート
することを許容し、可能にしている。

【０１３４】 以下では、これまでに説明してきた方法がどのように採用できるかを、いくつ
かの例を示して説明することにする。本発明の基本的要素を必要とする方法の精
神に属する限り、他の多くのケースが可能であり、従って、これらの変更および
改良は、本発明の精神から逸脱するものではない。例えば、これらの方法の多く
のオペレーションは、プロキシまたはインタフェースを通して行うことができる
。かかる追加は期待されるものであり、本発明の範囲に含まれるものである。種
々の他のエージェントおよび機器は、システムの一部として使用することができ
る（特殊ハードウェア、メールの使用およびその他の手段）。これらも本発明の
範囲に含まれるものである。従って、これまでに開示してきた実施形態は、すべ
ての面において例示であり、これらに限定されるものではない。

【０１３５】 以下では、本発明が採用される事例をいくつか示して説明する。

【０１３６】 本発明によれば、種々の団体／エンティティ間の関係が許容されている。会社
は、別の会社にサービスを提供することでき（サービスビューロになることがで
き）、そこではサービス条項と条件は資格証明として証明され、これらはその相
手会社に関連するユーザだけが見えるようになっている。一方の組織のユーザは
、他方の組織によってサービスすることができる。サービスの条項と条件は、変
更されることがあるので、本発明によれば、サービスプロバイダは、競合するよ
うな形でユーザにサービスを提供することを可能にしている。ユーザは、サービ
スプロバイダの証明された特性（およびユーザに行われた追加的表現）に基づい
て意思決定を行うことができる。なお、リースサービスは、利用可能サービスの
サブセットを表すことができるので、あるエンティティは、ある種のサービスに
ついては自身のユーザに奉仕できると同時に、他のサービス集合は別のサービス
エンティティに実行させることができる。

【０１３７】 １つの大きな会社によってサービスされるユーザと会社は、別の会社に移動す
ることも、サービスを提供する機能をその会社自身に移行することもできる。こ
のようにすると、「サービス」の「リース」が可能になるが、自身でも十分にサ
ービスを提供することが可能になり、これらの２モード間の移行はスムーズに行
われることになる。

【０１３８】 関係はフレキシブルであるため、変更を許容し、成長またはサービスプロバイ
ダ（システムエンティティ）間の統合化を受け入れることを可能にしている。ま
た、組織間の一時的義務の委任を可能にしている。

【０１３９】 機能構造はフレキシブルであるため、ユーザはその関係が変化したとき、その
ステータスを変更することを可能にしている。例えば、ユーザは、システムによ
ってサービスされるのでより多くのクレジットを得ることができる。ユーザは、
ビジネスの一部をサービスプロバイダ間で移動することができる。エンティティ
間の類似の関係も変化することがある（同盟、アフィニティ組織、補足的提案、
プロモーションなど）。

【０１４０】 以上、暗号化でサポートされるサービスのためにインフラストラクチャとアプ
リケーションを運用する方法を説明してきた。この分野の精通者ならば理解され
るように、本発明は上述してきた実施形態以外でも実施することが可能である。
なお、上述してきた実施形態は単なる例示であり、これらに限定されるものでは
なく、本発明は特許請求の範囲に記載されている内容によってのみ制限されるも
のである。

【図面の簡単な説明】

本発明の目的および利点は、添付図面を参照して以下に詳述されている説明を
読むことにより明らかにされるが、図中において、類似部品は類似参照符号を付
けて示されている。

【図１】 本発明の実施形態にかかるプライマリ登録プロトコルを示す図である。

【図２】 本発明によるサービス移行とその例を示す図である。

【図３】 本発明の実施形態にかかるバックエンド・インフラストラクチャを示す図であ
る。

【図４】 本発明の実施形態にかかるレジストラ・インフラストラクチャを示す図である
。

【図５】 本発明の実施形態にかかるインフラストラクチャ内の結合トランザクションの
オペレーションとその例を示す図である。

【図６】 本発明の実施形態にかかるモニタリングサービスによる結合トランザクション
のオペレーションを示す図である。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０７Ｆ 7/10 Ｇ０７Ｆ 7/10 Ｈ０４Ｌ 9/32 Ｈ０４Ｌ 9/00 ６７５Ｄ ６７３Ａ (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＡＵ，ＣＡ，Ｊ Ｐ，ＵＳ (72)発明者 スチュアート スタッブルバイン アメリカ合衆国 10004 ニューヨーク州 ニューヨーク ブロード ストリート 55 スイート 22 (72)発明者 マルセル モルデチャイ ヨン アメリカ合衆国 10004 ニューヨーク州 ニューヨーク ブロード ストリート 55 スイート 22 Ｆターム(参考） 3E044 DE01 DE10 5B017 AA03 BA07 BB09 CA16 5B082 EA11 5B085 AE00 AE29 5J104 AA07 KA01 MA02 PA07

Claims (42)

【特許請求の範囲】
1. 【請求項１】 複数のエンティティのうちいくつかが暗号化でサポートされ
   ているサービスを提供するインフラストラクチャにおいて、複数のエンティティ
   のうち加入者エンティティを複数のエンティティのうち本人エンティティに登録
   する方法であって、 前記加入者エンティティが、要求メッセージを前記複数のエンティティのうち
   レジストラエンティティに送信することによって前記本人エンティティにサービ
   スを要求するステップと、 前記レジストラエンティティが、前記加入者エンティティを検証し、前記サー
   ビスの要求を前記本人エンティティに転送するステップと、 本人エンティティが、前記転送された要求を格納し、確認通知メッセージを前
   記レジストラエンティティに送信するステップであって、前記確認通知メッセー
   ジは、受諾したことと、前記要求されたサービスに関して前記加入者エンティテ
   ィが必要とする認証／許可情報とを明記しているステップと、 前記レジストラエンティティが、前記受信した確認通知メッセージの認証性を
   検証し、正しければ、該確認通知メッセージを前記加入者エンティティに転送す
   るステップと を備えたことを特徴とする方法。
2. 【請求項２】 請求項１に記載の方法において、前記要求メッセージは、前
   記加入者エンティティによって要求されたサービスのタイプを示す標識を含むこ
   とを特徴とする方法。
3. 【請求項３】 請求項２に記載の方法において、前記要求メッセージは、 （ａ）前記加入者エンティティの単一レファレンス、 （ｂ）前記加入者エンティティに関する属性、 （ｃ）サービスの使用を認証するために使用される認証情報、 （ｄ）トランザクションに関する検証情報、 （ｅ）加入者が受諾した内容に加入者エンティティが同意したとの表示、 （ｆ）好適サービス関係、 （ｇ）加入者の真正を証明するもの のうち１または２以上を含むことを特徴とする方法。
4. 【請求項４】 請求項３に記載の方法において、前記加入者の単一レファレ
   ンスは、（ａ）加入者のＩＤ、（ｂ）一時的サービスの仮名、（ｃ）サービスの
   継続した使用の仮名のうち少なくとも１つであることを特徴とする方法。
5. 【請求項５】 請求項３に記載の方法において、セッションＩＤは、将来の
   応答をこの特定の要求にリンクしていることを特徴とする方法。
6. 【請求項６】 請求項３に記載の方法において、前記加入者に関する属性は
   、 （ａ）自己表現と、 （ｂ）第三者を表わす表明属性と を含むことを特徴とする方法。
7. 【請求項７】 請求項６に記載の方法において、前記表現と属性は、 （ａ）アドレス、 （ｂ）採用情報、 （ｃ）サービス提供を受けるために必要とされる他のエンティティからの情報
   、 （ｄ）他の当事者からの許可 のうち少なくとも一部を含むことを特徴とする方法。
8. 【請求項８】 請求項１に記載の方法において、 前記本人エンティティにおいて前記加入者エンティティの登録を変更すること
   をさらに備えたことを特徴とする方法。
9. 【請求項９】 請求項１に記載の方法において、 サービスの登録を前記本人エンティティから前記複数のエンティティのうち別
   のエンティティへ移動することをさらに備えたことを特徴とする方法。
10. 【請求項１０】 請求項１に記載の方法において、前記サービスは、 前記加入者エンティティ、前記本人エンティティおよび可能性のある別のエン
    ティティが係わりもつ暗号化でサポートされるトランザクションを運用すること
    を含むことを特徴とする方法。
11. 【請求項１１】 請求項１に記載の方法において、前記加入者エンティティ
    は、複数の要素を含むことを特徴とする方法。
12. 【請求項１２】 請求項１１に記載の方法において、前記複数の要素は、あ
    るエンティティと関連づけられていることを特徴とする方法。
13. 【請求項１３】 請求項１に記載の方法において、前記サービスは、サービ
    スの全体のサブセットであることを特徴とする方法。
14. 【請求項１４】 請求項１に記載の方法において、サービスは担保サービス
    であることを特徴とする方法。
15. 【請求項１５】 請求項１３に記載の方法において、前記加入者エンティテ
    ィに対するサービス全体の別のサブセットは、本人エンティティとは別のエンテ
    ィティによって提供されることを特徴とする方法。
16. 【請求項１６】 請求項１５に記載の方法において、前記加入者エンティテ
    ィは、エンティティ間のサービスの全体のサブセットを変更できることを特徴と
    する方法。
17. 【請求項１７】 請求項８に記載の方法において、変更は、当局によって監
    視されることを特徴とする方法。
18. 【請求項１８】 請求項９に記載の方法において、サービスの移動は、当局
    によって監視されることを特徴とする方法。
19. 【請求項１９】 請求項１に記載の方法において、サービスの提供には、前
    記複数のエンティティから別のエンティティが係わりをもつことができることを
    特徴とする方法。
20. 【請求項２０】 請求項１９に記載の方法において、サービスの提供は、前
    記本人エンティティと前記別のエンティティの間で分割されることを特徴とする
    方法。
21. 【請求項２１】 請求項１に記載の方法において、前記加入者エンティティ
    を代行する前記本人エンティティによるサービス提供は、前記運用されるインフ
    ラストラクチャによって前記複数のエンティティ内のエンティティに与えられる
    ことを特徴とする方法。
22. 【請求項２２】 請求項１に記載の方法において、前記本人エンティティに
    よる前記サービス提供は、前記複数のエンティティ内の他のエンティティが係わ
    りをもつことを特徴とする方法。
23. 【請求項２３】 請求項１４に記載の方法において、前記担保サービスは、
    情報の表現が正しいかどうかに係わりをもつことを特徴とする方法。
24. 【請求項２４】請求項２３に記載の方法において、前記情報の表現は、（ａ
    ）ＩＤ情報、（ｂ）金融情報、（ｃ）前記インフラストラクチャ内のサービス提
    供から派生された情報のうち少なくとも１つであることを特徴とする方法。
25. 【請求項２５】 請求項１４に記載の方法において、前記システムは、役に
    立たない担保に対して請求を開始するメカニズムを含んでいることを特徴とする
    方法。
26. 【請求項２６】 請求項１に記載の方法において、前記サービス提供は、ア
    クセスの制御が係わりをもつことを特徴とする方法。
27. 【請求項２７】 請求項１に記載の方法において、前記複数のエンティティ
    のうち少なくとも１つは、会社であることを特徴とする方法。
28. 【請求項２８】 請求項１に記載の方法において、前記複数のエンティティ
    のうち少なくとも１つは、金融機関であることを特徴とする方法。
29. 【請求項２９】 請求項１に記載の方法において、前記本人エンティティは
    、エレメンタリエンティティのグループであることを特徴とする方法。
30. 【請求項３０】 請求項１に記載の方法において、本人エンティティによる
    前記サービス提供は、前記加入者エンティティによって指示されることを特徴と
    する方法。
31. 【請求項３１】 請求項８に記載の方法において、登録変更トランザクショ
    ンは、管理機能が係わりをもつことを特徴とする方法。
32. 【請求項３２】 請求項８に記載の方法において、登録変更トランザクショ
    ンは、暗号鍵管理が係わりをもつことを特徴とする方法。
33. 【請求項３３】 請求項１に記載の方法において、 種々のサービストランザクションの集合の中から少なくとも１つを、前記本人
    エンティティによって前記加入者エンティティに提供することをさらに備えたこ
    とを特徴とする方法。
34. 【請求項３４】 請求項３３に記載の方法において、前記提供は、デジタル
    ＩＤの証明が係わりをもつことを特徴とする方法。
35. 【請求項３５】 請求項３３に記載の方法において、前記サービストランザ
    クションの少なくとも１つは、エンティティの状態を保証することに係わりをも
    つことを特徴とする方法。
36. 【請求項３６】 請求項３３に記載の方法において、前記サービストランザ
    クションの少なくとも１つは、金融情報を保証することに係わりをもつことを特
    徴とする方法。
37. 【請求項３７】 請求項３３に記載の方法において、前記サービストランザ
    クションの少なくとも１つは、ＩＤの保証とエンティティの状態の保証が係わり
    をもつことを特徴とする方法。
38. 【請求項３８】 請求項１に記載の方法において、前記複数のエンティティ
    のうちいくつかは、少なくとも１つのトランザクションで他のエンティティによ
    って監視されることを特徴とする方法。
39. 【請求項３９】 請求項１に記載の方法において、サービスは、サービスの
    合意と契約に基づく費用が係わりをもつことを特徴とする方法。
40. 【請求項４０】 請求項１に記載の方法において、付加的制御と追加のエン
    ティティは、システム内のトランザクションの保全性を保証することを特徴とす
    る方法。
41. 【請求項４１】 請求項４０に記載の方法において、管理機能の保全性は、
    ２または３以上の独立レポートを提供することによって強化されることを特徴と
    する方法。
42. 【請求項４２】 請求項４０に記載の方法において、前記管理機能は、保証
    提供エンティティのアクションをトランザクション単位で制御することを特徴と
    する方法。