JP4698219B2 - 認定された文書の電子的送信、保存および読み出しシステム並びに方法 - Google Patents

Description

出願人の発明は、例えば Electric Original^TM の様な、電子オリジナル情報オブジェクトの作成、保守、転送、読み出しおよび廃棄を提供するための、証拠および安全の検証可能な繋がりを提供するためのシステム並びに方法に関する。

本発明は好適に出願人の、信頼された管理ユーティリティ（Trusted Custodial Utility）を使用し、これは電子オリジナル記録並びに必要な処置を実行するために個人の権利を認証する際の仮想電子貯蔵庫として働く同等システム、提出された電子情報オブジェクトの信頼性、およびデジタル署名照合および使用者認定過程で使用される認定認証の状態を保持する。その様なＴＣＵおよび動作は特許文献１から特許文献４に記載されている。
米国特許第５，６１５，２６８号 米国特許第５，７４８，７３８号 米国特許第６，２３７，０９６号 米国特許第６，３６７，０１３号

以下の略語表が本記述の中で使用されている：
（略語）
ＣＡ 認証機関
ＣＲＬ 認証取り消し表
ＣＳＳ 認証状態サービス
ＨＴＭＬ ホームページ作成言語
ＩＤ 識別番号
ＩＥＴＦ インターネット・エンジニアリング作業部会
ＩＴＵ 国際電気通信連合
ＬＤＡＰ 軽量ディレクトリ接続プロトコル
ＯＣＳＰ オンライン認証状態プロトコル、IETF-RFC 2560 X.509 インターネット公開鍵インフラ・オンライン認証状態プロトコル-OCSP,１９９９年６月
ＰＩＮ 個人認識番号
ＰＫＣＳ 公開鍵暗号規格
ＰＫＩ 公開鍵インフラ
ＰＫＩＸ 公開鍵インフラ（Ｘ．５０９）
Ｓ／ＭＩＭＥ 安全多目的インターネット・メール内線番号
ＳＣＶＰ 簡略認証検証プロトコル、草案-IETF-PKIX-SCVP-06,２００年７月
ＳＳＬ 安全ソケット層
ＴＣＵ 信頼された管理ユーティリティ
ＵＥＴＡ 統一電子商取引法
ＸＭＬ 拡張マークアップ言語

国際および国内商取引における電子署名米国法(ESIGN : U.S. Electronic Signatures in Global and National Commerce Act)立法および、統一州法国民会議により起草されたＵＥＴＡをモデルとし、１９９９年に承認され法律成立を勧告された米国州法は、電子的に署名された情報オブジェクト（電子文書）に対する法的資格の保証を与え、これは潜在的に完全な電子取引の効率性および経済活動の実現を目指す政府、金融および電子商取引活動を活発にしている。

ＰＫＩおよびＣＡは電子情報オリジナル記録を生成する際に使用されるデジタル署名技術の基本要素である。ＰＫＩは複数のＣＡの集合であり、此処で信頼は使用者および使用者組織との間で、複数のＣＡ間で階層的関係を生成するかまたは協調関係にあるＣＡ内での相互保証を通して確立される。ひとつのＣＡは認定認証を発行する権限を与えられており、これは個人または事業体の身元をその個人または事業体の公開鍵に結びつけ（検証）、此処で個人にのみ整合する秘密鍵へのアクセスが与えられる（署名）。本出願の時点で、認証は通常 ITU X.509 認証基準に従い、それら自身は発行元ＣＡによりデジタル的に署名される。そのような認証は例えば米国特許第６，２３７，０９６号の図１０に描かれており、これは上記言及されかつ組み込まれている。これらの認定認証はシリアル番号、被験者（使用者）と発行者（ＣＡ）の身元情報、認証の有効期限（それが使用可能となる日時と使用できなくなる日時）、被験者の公開鍵、およびデジタル署名を生成し検証するために必要な暗号化アルゴリズム情報を含む。

デジタル署名を生成するために、情報オブジェクトがハッシュされ（一方向暗号化機能を用いて処理され、これはオブジェクト内の最低１ビットの変更を検出できる）、次にこのハッシュが個人の私的（秘密）鍵を用いて暗号化される。デジタル署名検証はこの処理工程を逆に辿ることで実現される。デジタル署名は、それらの認定認証から取り出された個人の秘密鍵を用いて暗号解読され、その結果はオリジナル情報オブジェクトの再ハッシュと比較される。これらの処理工程は異なるデジタル署名アルゴリズムを使用する場合は変わるはずである。デジタル署名は信頼している当事者と発行しているＣＡとの間に存在する信用としてのみ信頼性のあるものである；そしてその保証のレベルは物理的管理、業務およびＣＡにより実現される手続きにより得られる。

ＰＫＩ技術の目的は通信当事者に対して安全と信頼性のある環境の両方を生成し維持することである。その様な当事者はＰＫＩに依存して、使用者の身元を確立し、使用者の認証がもはや有効で無くなった場合に通知している。認証は個人が組織を脱退したとき、代わりの認証が発行されたとき、または署名鍵が失われるか、盗難されるかまたは危うくなった時に無効とされる。ベンダは認証状態を広範な種々の方法を用いて通知する。これらの多種多様な方法は、使用者が他の使用者の認証状態を得ることを更に難しくしている。

信頼関係および相互運用性の構成は、ＰＫＩ認証および機密保護方針とそれらの施策で決定される。認証方針により、認証発行の承認を得るために必要な（例えば２つの形式の画像ＩＤ、信用調査）個人審査（すなわち、認証要求情報および対象となる認証受領者の身元の適切性を適正であると認証する工程）のレベルが決定される。安全性方針は、申請環境を支援するために必要な、物理的、手続き的および処理管理を決定する。

ＣＡを生成し組織化するための２つの普及しているモデルが存在する。第１は階層化ＣＡモデルであり、これはその頂点がルートＣＡである逆ツリーに似ている。ルートＣＡはその直下のＣＡの認証に署名する。これらのＣＡは続いてそれらの下位ＣＡの認証に署名し、以下同様である。これらの関係は、ツリーの枝を形成する認証連鎖を生成する。２つのＣＡは信頼関係がそれらの間に存在することを証明するが、これはそれらの個々の認証連鎖を共通ノードに達するまで「歩行（Walking）」することにより行われる。いくつかのＣＡはグループ化され１つまたは複数のサービス提供チャンネル、工業縦割り分野（industry vertical）、組織または企業に関連付けられる場合もある。

第２モデルでは、１つのＣＡが単一企業に対して生成され、ＣＡサービスをその企業内の１つまたは複数の事業体に提供する。１つの企業ＣＡは通常、他の企業のいずれのＣＡとも予め確立された信頼関係は有していない。ＣＡ相互認証の形式で相互運用を可能とするために、明示的な処置が行われねばならず、此処で互いに信頼することを同意した２つまたはそれより多数のＣＡはそれぞれ互いの認証に署名し、デジタル署名検証に際してこれらの相互認証された認証を使用する。従って１つのＣＡで発行された認証は、他の相互認証されたＣＡおよびその使用者によって有効と確認される。

ＣＡが認証を無効にするのは、他にも理由は有るが、その中に含まれる情報が無効になった場合、使用者の秘密鍵が危うくなった場合、または使用者の認証に基づくアプリケーション特権を終了する必要がある場合である。ＣＡは認証が既に所有者に所有されている場合、認証を単に取り消したりその所有者から回収することは出来ない。その代わりに、その認証はＣＡのデータベース内で「無効」とされ、その認証状態が公表される。従ってＰＫＩの使用者は認証の有効性を、認証状態を発行しているＣＡまたは身元のはっきりした状態集積所（ディレクトリ）から要求することで確認できる。

認証状態を報告するために使用された従来の方法は、ＣＲＬとして知られているＣＡの無効とされた認証のリストを公表することによってであった。ＣＲＬは希望者および信頼している関係者によりダウンロードされて、特定使用者の認証が無効とされているか、また延長することによりその使用者のデジタル署名が未だ有効であるか否かの判断が行われる。時間が経つとＣＲＬはより長くなり、通信およびデータ処理のオーバヘッドの負担が掛かるようになる。この手法の別の欠点は、ＣＲＬがしばしば不定期間隔（例えば日に１回または２回）で公表されることである。従って、ＣＲＬはしばしば公表直後に古くさいものになってしまう。無効とされた認証はＣＲＬから認証期限切れの後、除かれるだけである。

ＰＫＩブリッジは複数のＣＡ間の相互運用性を提供するための方法であり、ＣＲＬを協調して分配することにより行われる。その様なブリッジは中央ＣＲＬ集積所であり、事実上互いに他の認証および安全方針を受領することを了承しあっている複数ＣＡの組を結合している。全てのＣＡは彼らのＣＲＬをそのブリッジに通知する。これにより、全ての個人または事業体の認証の集中的有効性確認が可能となる。その認証が過去に無効とされていなければ、それは依然有効であると考えられる。ＰＫＩブリッジの最大の欠点は、それらがそのブリッジに依存している全てのＣＡまたは使用者により認証状態に接続可能でなければならないことである。必要な帯域幅、計算および記憶容量は高価なものとなろう。

認証状態を得るための更に最近の方法は IETF OCSP であって、これは実時間認証状態を提供可能な、直接データベース問い合わせを行う。しかしながら、ベンダの中にはＣＲＬに基づくＯＣＳＰ応答システムを実現しているものもある。この型式の応答システムで報告された認証状態は、それらが基本としているＣＲＬにしか同期していない。IETF SCVP の様な実時間認証状態を実現する試みは、発展し続けている。本発明の時点で、状態チェック方法の混合および整合は、オープンＰＫＩ環境では未だ実際的なものとはなっていない。

認証妥当性確認の全ての手法は、その認証を発行したＣＡに対する、可か不可かの判断である。メンバＣＡの１つにより認証を発行された全ての使用者は、彼らの認証が一時停止されるか、無効となるかまたは期限切れとなるまで有効／使用可能である。参画を制御するための共通の主題は、認証が発行されるか否かである。発行は認証および安全方針並びにビジネス規則に基づき管理される。

信頼環境は完全無条件に参画料を支払える誰もが認証を発行される、から制限付きまたは限定、企業または対象団体の会員であることを必要とする、までの範囲がある。いずれの場合も、ＣＡ認証そして／または安全方針が相互運用性を可能とするか否かを左右する。

出願人の発明は、先に説明したものとは全く異なる観点からＰＫＩおよびＣＡの相互運用性問題に取り組んでいる。出願人の論点は、譲渡可能記録（所有権が取り引きされる）である電子オリジナル情報オブジェクトの作成、実行、保守、転送、検索、および破壊に適した信頼環境を確立することである。これらの目的を実現するために、電子オリジナルまたは権威あるコピーを管理するシステムはオリジナルをその全てのコピーから識別することが出来なければならない。紙のオリジナルと同様、オリジナルは１つのみでなければならない。譲渡可能記録の例は、電子売買可能法律文書および有価証券がある。電子オリジナル記録は、それが譲渡可能記録としての資格を与えられているか否かによらず、任意のソース記録である。電子オリジナル記録の複数システム間での転送は、唯１つのオリジナルのみしか存在しないことを保証する方法を用いて行われなければならない。

本発明は電子オリジナル記録の生成を、その記録の保管を機能的に独立した団体またはその記録の所有者の利益になるよう運用されているＴＣＵの管理にゆだねることで実施している。信頼環境を生成することは必要であるが、電子ソース記録を保守するためには充分でない。本発明のその目的のために、信頼環境は閉鎖的または限定された会員を有する対象となる共同体の体制により生成され、此処では予想される会員、組織およびそれらの使用者の身元は適切な審査手法を用いて保証されており、この審査はその共同体への入会の許可を管理している。更に、個人の組織、加入、役割および属性は登録時にＴＣＵにより定義される。個人はシステムおよびそれらの認定認証でユニークに識別されなければならない。加えて、個人および組織をその共同体から除くことが出来なければならないし、この処置がその共同体の他のメンバに通知されなければならない。ＣＡの相互運用性への従来の手法はこれらの目的を十分に達しているとは言えない。

審査は最低限、組織そして／または個人がその共同体の既知の会員の支援を受けていることを必要とする。加えて、ダンアンドブラッドストリートの様な組織に対する格付け、またはエキファクスの様な個人に対する信用調査、または同様の信用および支払い記録が、可能性のあるビジネス・パートナ、クライアントおよび顧客の容認可能性を評価するために使用される。審査組織およびその支援を受けた使用者は、ＴＣＵ登録が許可される前に信用できると見なされなければならない。組織が会員資格を定める契約条件に同意した後、それに支援された個人には各々ユニークな識別子とパスワードが与えられ、これらは彼らがＴＣＵにアクセスすることを可能とする。

一度個人が１つまたは複数のＴＣＵに登録されると、彼らはその取引の所有者に依って、取引の参加者として指名され、彼らの身元、役割そして／または責任に基づき、全てまたはオリジナル記録の確認された副集合の１つへの特別なアクセスが与えられる。身元確認および認定を容易にし、取引が完全に電子形式で行えるように、この識別された情報の選択されたサブセットが参加者の認定認証の中に含まれている。認定認証は使用者の身元を彼らの公開鍵と結びつけており、この公開鍵は彼らの整合する署名秘密鍵を用いて生成されたデジタル署名を有効と確認するために使用される。

認証または安全方針は、認証を発行するために必要な身元保証要求（例えば、２つの形式の画像ＩＤ、信用調査、個人紹介）に対処する。この認証は、デジタル署名典拠として必要とされる場合、使用者のＴＣＵアカウントに結びつけられるはずである。この繋がりはその使用者をユニークに識別する認証データ構成要素の副集合（例えば、認証ＩＤ、発行元ＣＡ名称、使用者共通名）を含まなければならない。一度使用者のアカウントと関連づけられると、認証は彼またはそのデジタル署名と共に使用されて、権威づけられた処置のあらかじめ定められた組を可能とし、また提出された情報オブジェクト上の使用者のデジタル署名を検証するために必要な身元証明を与える。これは所有者または電子記録の組を管理する所有者の代理人がＴＣＵに対して、電子記録の別のＴＣＵへの所有権の移動（すなわち、内部取引）そして／または保管の移動（すなわち、外部取引）を指示した場合に確かである。

先に記述したように、認定認証および公開鍵暗号は使用者認定並びにデジタル署名検証の両方を支援するために使用されている。認証は発行元ＣＡによりデジタル的に署名され、受取人の身元は公開鍵により封印される。このＣＡは認証を発行する際に、その認証の中で身元保証されている個人は、情報オブジェクトまたはその一部にデジタル的に署名するために使用された整合秘密鍵の保有者であることを主張する。

本発明は他のＰＫＩ準拠電子商取引（e-commerce）解決法とは異なっているが、それはＰＫＩが権限付与としてのみ見なされ、信用環境の単一根拠では無いからである。保証人であること（sponsorship）、会員に対する契約、および入会登録が基本要素である。認証および公開鍵暗号の使用は権限付与技術として見なされるが、認証はユニークに身元確認し、それが使用者のＴＣＵアカウントに結びつけられる前に特定使用者に関連づけられなければならない。

認証が採用された場合には、そのアカウントはこの認証と使用者アカウント間の結合が完了するときに一度だけ起動されるはずである。この結合は単純であって、認証ＩＤと発行元ＣＡを使用者のアカウント情報に付け加えるか、またはその認証で伝達される他の情報、例えば使用者の識別名（ITU X.509 規格参照）を使用するものである。この結合情報は登録形式の中で伝達されるか、または認証から直接抽出されるが、これはＴＣＵシステムの安全方針毎に行われる。対応チェックを使用して認証内の使用者記述が登録データ内のそれと一致するか裏付けを行い、これは認証が使用される度に行われる。使用者の認証は発行元ＣＡにより署名され、その無謬性および信頼性は発行元ＣＡの認証および公開鍵を用いて有効であると確認される。身元保証に使用される要素の集合的な組は、証明可能的にユニークでなければならない。一度このＴＣＵアカウントと使用者認証との結合が完了すると、ＴＣＵは認証状態を確認するために何処へ行けばよいかを知るだけでよい。

ＣＡ中枢環境の中で、単独ＰＫＩ、相互認証、またはＰＫＩブリッジ（複数ベンダ製品が多数のＣＡで使用されていて、認証状態チェックが実行される複雑なシステム）の生成が相互運用性に対して要求される。共通要素は全ての認証が等価で有ることである。複数の認証は異なる信頼レベルを伝達するはずであり、１つのオープン環境内の複数のアプリケーションはこれらの信頼レベルを解釈し異なるように使用する能力を持たなければならない。この理念は「貴方が望む全ての場所へ導く道を我々は造る」と言うことに特徴付けられる。使用者はＣＡ環境上で種々の基準（例えば、信用調査、支払い手段、認証のコスト）を使用して審査される。

逆に言えば、ＴＣＵは「承認されたＣＡ」の既知の集合のみに関心があり、その集合の中でのみそれらの認証は使用者アカウントに関連づけられる。他の全ての認証は無視される。この考え方は「貴方に開放されている道は、貴方のビジネスを導くために必要なものだけである。」と特徴付けることができる。使用者は二度審査される、一度目はＣＡ認証方針を満足すること、二度目はＴＣＵに登録されることにより彼らに必要なビジネスが存在すると証明されること。ＴＣＵで強制されるビジネス規則は、異なる信頼レベルで発行された認証に対応できる。

これまでのところ、全ての認証状態報告サービスは認証状態報告の単一手段を使用しており、これはＣＲＬ，ＯＣＳＰ，ＬＤＡＰ等である。本発明はこの点で異なっており、これは認証状態の検索および報告する目的用に全てのＣＡまたはＰＫＩを用いた相互運用性を可能としている。大体において、これはまたシステムまたはＴＣＵとＣＡ認証状態報告要素との間の実時間連続接続性への依存度を、認証状態をキャッシュすることにより低減させる。

出願人の１つの特徴として、それぞれのＣＡにより発行された認定認証の有効性をチェックするためのＣＳＳを提供するための１つの方法は、その認定認証を発行した発行元ＣＡから認定認証の状態を呼び出すために必要な情報を識別し；識別された情報に基づき、発行元ＣＡと通信するためのコネクタを構成し；その認定認証を呼び出すためのステップを含む。発行元ＣＡおよびコネクタは構成ストア内の承認されたＣＡのリスト上で指定される。

現地日時が、それらが認定認証有効期間の中で指示されている有効期間内であるか否かチェックされる。発行元ＣＡは承認済みＣＡのリスト内に、その発行元ＣＡをあらかじめ定められたビジネス規則に基づいて審査および承認することによって含まれているはずであり、その発行元ＣＡが審査され承認されていない場合、その発行元ＣＡは構成ストア内の非承認ＣＡのリスト上に指定されているはずである。発行元ＣＡの審査および承認は、信頼された認定認証の表示をＣＳＳに登録し、少なくとも表示、状態および有効期間データ要素をローカル・キャッシュ・メモリに追加することを含む。次にコネクタが、信頼された認定認証の状態が問い合わせられた際に、追加された状態を呼び出すために構成される。発行元ＣＡとの通信がまた、コネクタの順番に従って実行される。

この方法は更に、状態用のローカル・キャッシュ・メモリをチェックし、その状態がそのローカル・キャッシュ・メモリ内に見つけられ、ローカル日時が有効期間内の場合、その状態をローカル・キャッシュ・メモリから呼び出すことを含む。その状態がローカル・キャッシュ・メモリ内に見つからないか、またはローカル日時が有効期間内に無い場合、ＣＣＳは通信セッションを発行元ＣＡの認証状態報告構成要素と確立し、認証状態要求を構成されたコネクタに基づいて創作し、その状態を認証状態報告構成要素から検索し、認証状態報告構成要素との通信セッションを閉じ、少なくとも認定認証の識別、状態、および有効期限をローカル・キャッシュ・メモリに追加する。

認証状態はＣＲＬにより示され、発行元ＣＡの発行スケジュールに基づき、ＣＳＳはそのＣＲＬを構成ストア内のリストに示された認証状態報告構成要素から検索し、ＣＳＳはその発行元ＣＡに関連するキャッシュ・メモリを消去し、そしてＣＳＳは認定認証の状態をＣＲＬから決定し、その状態をその発行元ＣＡに関連するキャッシュ・メモリの中に格納する。

認証状態はまた、デルタ認証取り消し表（「ＣＲＬ」）でも表示され、発行元ＣＡにより１つのＣＲＬが利用可能であると公示されると、ＣＳＳはそのＣＲＬを構成ストア内にリスト表示されている認証状態報告構成要素から呼び出す；そのＣＲＬが完全なＣＲＬの場合、そのＣＳＳはその発行元ＣＡに関連するキャッシュ・メモリを消去して、状態をそのＣＲＬから決定しその状態をキャッシュ・メモリの中に格納する；そのＣＲＬが完全なＣＲＬを発表した後に発生した変化のみを含む場合、ＣＳＳはその状態をそのＣＲＬから決定しその状態をキャッシュ・メモリの中に格納する。

出願人の発明の別の特徴として、１つの発行元ＣＡにより発行された認定認証の状態を、１つのＴＣＵから１つのＣＳＳへの、その認定認証の状態を問い合わせに応じて呼び出す方法が、その状態が存在しそのＣＳＳのキャッシュ・メモリに現存する場合、その状態の所在を確認して報告し；そうでない場合は、ＣＳＳ構成ストアから状態の型式と検索方法を獲得するステップを実行し；その状態型式がＣＲＬで、その状態がキャッシュ・メモリ内に見つからない場合は、その状態を有効であると報告し；その状態型式がＣＲＬで無い場合は、その状態型式に基づいて認証状態要求を作成し；通信セッションを発行元ＣＡと確立し；その状態を発行元ＣＡの状態報告構成要素から、取得された検索方法を用いて検索して通信セッションを終了し；検索した状態を解釈し；検索され解釈された状態を、その状態型式に対するＣＳＳ方針で指定された期間を表す有効期限に関連づけ；少なくとも認定認証の識別子、状態、および有効期限をそのキャッシュ・メモリに追加し；そしてその状態をＴＣＵに対して問い合わせに応答して報告する、以上のステップを含む。

出願人の発明の更に別の特徴として、発行元ＣＡにより発行された認定認証の正確で時期を得た状態表示を提供するためのＣＳＳが、その認証の発行元ＣＡが状態表示用にＣＲＬを使用している場合、認定認証の状態をＣＲＬで表示されたものとして提供することを含む。そうでない場合は、キャッシュ・メモリが状態と期限切れでない有効期限データ要素を含む場合、キャッシュ・メモリで表示された状態が提供される。有効期限データ要素が期限切れの場合、その状態はキャッシュ・メモリから消去され、その状態がキャッシュ・メモリ内に存在しない場合は、実時間認証状態報告プロトコルを用いて要求され呼び出される。少なくとも認証の識別子、状態、および有効期限データ要素がキャッシュ・メモリに追加され、呼び出された状態が提供される。

状態使用計数器データ要素がキャッシュ・メモリに追加され、認証状態チェックがなされる度毎に増数更新または減数更新される。その状態使用計数器データが閾値を超えると、その状態は提供されキャッシュ・メモリはその状態に関して消去される。また状態最新アクセス・データ要素をキャッシュ・メモリに追加することも可能であり、状態最新アクセス・データ要素は状態使用計数器データ要素と共に、認証状態の利用頻度を判定することが可能である。

新たな認証の状態を呼び出す要求がＣＳＳに対して行われ、キャッシュ・メモリが割り当てられたサイズ限界に到達した場合、ＣＳＳは最も古い日付を示す、最新アクセス・データ要素をキャッシュ・メモリ内で検索し、それぞれのキャッシュ・メモリの事業体を消去し；次にＣＳＳは要求された状態を検索してそれをキャッシュ・メモリ内に配置し、その要求された状態を提供する。

出願人の発明の更に別の特徴として、第１当事者と第２当事者間で検証可能な証拠の痕跡を有する認定された情報オブジェクトの制御を移動することにより取引を実行する方法は、提出側当事者デジタル署名を有する第１デジタル署名ブロックを含む認定された情報オブジェクトと、その提出側当事者の少なくとも１つの識別子と暗号鍵に関する第１認定認証とを信頼された集積所から検索し、呼び出された認定された情報オブジェクトを第２当事者により、呼び出された認定された情報オブジェクトの中に第２当事者のデジタル署名ブロックを含めることで実行し、そして実行された認定された情報オブジェクトをＴＣＵへ転送することを含む。

このＴＣＵはこのデジタル署名を検証し、このデジタル署名に関連する認定認証を、少なくとも認定認証の状態をＣＳＳから呼び出すことにより有効と確認する。このＴＣＵはそれぞれのデジタル署名が検証されないか、またはそれぞれの認定認証の状態が期限切れかまたは取り消されている場合はデジタル署名ブロックを拒絶し、情報オブジェクト内の少なくとも１つの署名ブロックが拒絶されない場合、このＴＣＵは自身のデジタル署名ブロックと日時表示とを情報オブジェクトに付加し、そのオブジェクトの管理を第１当事者に代わって行う。

出願人の発明の種々の特徴並びに長所は、添付図と共に本説明を読むことにより明らかとなろう。

認証状態チェックはシステムまたはＴＣＵが提出された全ての電子情報オブジェクトを受け入れるに当たってきわめて重要な要素である。提出物が受け入れられるために、その認証状態は有効であると報告されなければならない。認証状態の問い合わせは、通常ＴＣＵと認証状態の発行元との間で行われる通信を必要とする。これらの通信頻度はＴＣＵ仲裁付託の数に比例して増大する。

認証状態チェックは実時間要求であり、状態問い合わせは仲裁付託の度毎に実行される。しかしながら、状態はＣＲＬの様な場合には実時間で更新されるものではない。全てのＣＲＬは特定の間隔で公開されており、通常は１日に一度または二度である。ＣＲＬ検索および繰り返される分析はシステム性能に良くない影響を与えかねない。本発明は多くの作業をＣＳＳに移すことにより、直接計算および通信要求を著しく削減している。単一の認証状態プロトコルがＴＣＵとＣＳＳとの間に導入されている。この状態プロトコルはＩＥＴＦ ＯＣＳＰに似た属性を有し、これは１つのアプリケーションがＣＡに対して１つの認証状態を問い合わせることを可能とし、処理オーバヘッドを最小としている。

ＣＳＳはその場所で十分な情報、通信手段および相互運用するのに必要な全てのＣＡに対する認証状態処理手段が具備および維持されている。従ってＣＳＳはアプリケーション設計を安定化させ最適化することを可能とする。ＣＳＳは好適に認証状態を分析およびキャッシュして、ＴＣＵ状態問い合わせへの状態応答時間を最小とする。従ってＣＳＳはＰＫＩ相互運用性の全ての従来形式の必要性を無くする。潜在的妥協回復(Potential compromise recovery)は大きく強化されるが、それはＴＣＵ使用者アカウントが容易に不活性状態にしたり、または使用者の１組をそのＣＡを承認されたＣＡのＣＳＳリストから取り除くことにより除去できるからである。

（認定認証の使用）
ＴＣＵへログインした後、参加者は更に彼ら自身の認定を、公開鍵および彼らの認定認証の使用を通して問い質されるはずである。そのような認定は、安全セッション確立、ＴＣＵサービスまたはデジタル署名の要求および電子情報オブジェクトの提出に関連している。

誰でもＴＣＵとやり取りを行う前に、４つの条件が合わなければならない：１）彼らは第１にシステム使用者として登録されなければならない、２）彼らは一対の公開鍵と彼らが読みとり専用アクセス以上を許されている場合、彼らに整合する認定認証を発行されて所持していなければならない、３）認証が承認されたＣＡから発行されていなければならない、そして４）その使用者の認証は期限切れでも、不活性状態または無効状態であってはならない。この最後の条件は通常ＴＣＵが発行元ＣＡに認定認証検索の問い合わせを行う時に要求される。認証状態報告に関して広範な基準およびＣＡ実施状態が存在するので、これは簡単でも単純な作業でも無い。

背景説明の章で述べたように、複数のＣＡまたはＰＫＩが含まれる際には、通常何らかの形式のＰＫＩ相互運用性が要求される。本発明はこの必要性を、認証状態サービスを作ることで無くしている。ＣＡ相互認証またはブリッジは不要であり、ＣＳＳにとって唯一必要な知識は承認された発行元ＣＡのリスト、かれらのＩＰアドレスまたは同様のもの、および認証状態を報告する彼らの手段である。

認証状態を検索するために、コネクタまたはプログラム・モジュールが各々の認証状態方法に対して定義される。全ての認定認証は被検者（使用者）および発行者（ＣＡ）フィールドを含む。発行者フィールドはＴＣＵ問い合わせをＣＳＳに導くために使用され、これは続いてそのキャッシュをその認証の状態が存在するかチェックする。状態がそのＣＳＳキャッシュの中に存在する場合、それはＴＣＵに戻される。状態が存在しない場合、ＣＳＳは適切なコネクタをインボークして、認証の状態を検索する。多数の方法が認証状態を報告し検索するために使用できるであろう：ＬＤＡＰ，ＯＣＳＰ，ＣＲＬ等。

全てのＴＣＵ動作を実行するために、使用者は最初にＴＣＵにログインしなければならない。一度成功すると、その使用者は彼らがその様な権限を許可されている場合、トランザクションを生成するかまたは選択することができる。彼らが電子情報オブジェクトの提出許可を有する場合、彼らはすぐに実行できる。電子情報オブジェクトを受け取ると、ＴＣＵは必要なデジタル署名有効性確認ステップを実行する。認証状態問い合わせが作成され、ＣＳＳへ送られる。有効状態が戻されると、ＴＣＵは提出物を認定されたコピーとして受け入れて格納し、それ以外の場合それは拒絶される。

（デジタル署名処理および認証状態チェック）
デジタル署名は情報オブジェクトの１つまたは複数の断片または全コンテンツに対して適用される。デジタル署名はそのトランザクションの当事者または代理人に属し、この代理人はそのトランザクションがビジネス過程の文脈の中で１つまたは複数の状態を獲得することを可能としている。デジタル署名は実際、実行されるタスクに関する追加情報に適用される場合もある。その様な一例は、財産権利書上(property deed)の土地法務官表記(country recorder’s notation)である。別のものは、ＴＣＵに提出される情報オブジェクトの信頼性を証明する当事者の署名のアプリケーションである。この後者の事例において、提出者はその情報オブジェクトを封入したりまたは封印するように言われ、この中でデジタル署名が全コンテンツに対して適用され、後での全ての修正変更を防止する。

デジタル署名が適用される際には何時でも、署名者は彼らのデジタル署名で拘束されるものに対する彼らの意図を確認するように要求される。最新の法規で要求されるこの同意動作は、表示ウィンドウまたはスプラッシュ・スクリーン内で読みとり可能なテキストの形式を取り、画像ボタンの呼び出しそして／または、暗号鍵および認証ストアである暗号トークンへのログオンを必要とするはずである。同意に対する前記意志の実際の表明は、選択されたコンテンツを用いて使用者のデジタル署名を計算する信頼されたアプリケーションの使用を通して行われ、それを署名ブロックの形式に対する彼らの認定認証と結びつける。この署名ブロックはまた認定および非認定データ要素を含むはずである。認定データ要素はデジタル署名計算（例えば地方日時）の中に含まれ、デジタル署名（完全性）により保護されていると考えられる。非認定データ要素は署名計算の後に追加され、保護されない。図４はシンタックス例を示し、これは署名ブロックのデータ要素と配置を含む。これは図示例としてのみ意図しているので文字通りに解釈されるべきものでは無い。

情報オブジェクトおよび全ての署名ブロックは、好適に封体（Ｓ／ＭＩＭＥ）または拡張可能情報シンタックス（ＸＭＬ，ＨＴＭＬ，ＸＨＴＭＬ）内のタグの中に配置されていて、取り扱いを簡便にしたり情報処理を容易にしている。このデータ構造は次に有効性確認のためにＴＣＵへ送られる。代わりに、署名ブロックは独立してＴＣＵに、決してＴＣＵを離れることのない実際のオリジナル記録に添えられるために送られる場合もある。後者の場合、各々の署名ブロックは個別に有効性確認がなされる。

デジタル署名有効性確認の過程は、提出の時点とその後の実行時とは異なる。ＴＣＵが最初にデジタル署名を見た時点で、４ステップの有効性確認が行われる：１）デジタル署名を検証する、デジタル署名で保護されているコンテンツが転送中に改変されていないことを証明する行程である；２）現在のＴＣＵ時刻がその個人の認定認証の許容可能有効期間（「それ以前で無く」「それ以降でも無い」）内に入っていることのチェック；３）認証状態を発行元ＣＡ、ＣＲＬ分散点、またはその他の承認された認証状態源からローカルに指定されたＣＳＳを用いて要求し検索する；４）そのＴＣＵ使用者アカウント情報が認証の中で伝達されたものと合致するか、および要求された行動がＴＣＵ規則データベースの中で認定されているかの有効性を確認する。その情報オブジェクトの提出者に対して、処理は１つの追加ステップを付加する。この第５番目のステップは提出者の身元が現在のセッションをＴＣＵと確立している当事者と合致するかをチェックする。全ての検査に合格すると、この行動は許可されそして／またはその情報オブジェクトは受容されて、その所有者に代わってＴＣＵで保持される。いずれかのステップで不合格となると、処置は初期化される。

この初期認証状態チェックの後、ＴＣＵの信頼環境は全ての保持されている情報オブジェクトの信頼性および無謬性を維持する。新たな版の文書が提出されない限り、いかなる追加の認証状態チェックも予期されていない。

本発明の２つの特徴は通常のＰＫＩ実現過程と異なる。第１に本発明はアプリケーション、すなわちＴＣＵ（または、認証状態有効性確認を要求する全てのアプリケーション／システム）および、電子１次資料記録を生成し維持するその能力が存在することに基づいている。第２は、「発行元ＣＡ」は信頼環境を管理する方針に同意すると認める必要があるだけであり、ＣＡ相互認証もＰＫＩブリッジも必要とされない。「発行元ＣＡ」を含めることに必要な正当化は、文書化されたビジネス関係である。ＴＣＵ登録処理の間に、使用者アカウントが生成され、これは使用者特有の認証情報を参照し、これは事実上使用者アカウントを使用者の認定認証と結びつける。

（ＴＣＵ使用）
典型的に一度組織がＴＣＵのサービスを利用することに同意すると、組織のトランザクションへのアクセスの管理がその組織の代理人に許可される。その組織の代理人は次に、その組織のトランザクションに関して選択された行動を実行するように権限を与える、個人の組を識別する。全ての行動は使用者がＴＣＵに関するアカウントを所持し、そのアカウントが起動され、そして使用者がログオン識別子を有し適切なパスワードまたは問い合わせ文句に応答出来ることを要求する。加えて、版（バージョン）付けられた電子１次資料記録の組で構成されている各々のトランザクションは、ビジネス過程の異なるステップで使用者アクセスを管理する、一組の認可を有する。これはトランザクション記録への権利の許可および剥奪で例示され、それはトランザクションが通常のビジネス経路、すなわち開始から永久保存または廃棄までを進むからである。許可されている場合は、電子オリジナル記録を見るのであればＴＣＵにログオンするだけで構わない。しかしながら、全てのシステム・レベル行動または電子オリジナル記録の導入または変更は個人に対して彼ら自身の更なる認定を公開鍵暗号を用いて、または彼らのデジタル署名および認定認証を適用して行うことを要求する。全ての事象において、個人の身元は有効であると確認されなければならない。デジタル署名が採用されている所では、これは必然的に：１）使用者が適切なアクセス許可を有し、２）デジタル署名を解読し、その上に基礎ハッシュまたはメッセージ要約が適用されているコンテンツが改変されていないことを検証し、３）提出時刻が認証有効期間内に入ることをチェックし、そして４）使用者認証が未だ有効であることをチェックする。

認証状態チェックは発行元ＣＡまたは認証状態応答機に問い合わせることを必要とする。このステップは全ての認定行動または電子オリジナル記録提出の度毎に行われなければならないので、通信帯域は超過となり遅延、未処理分、および未応答または遅い状態応答による拒絶の可能性が存在する。本発明はこれらおよびその他のＴＣＵ運用の高い保険機能を取り扱い、ＴＣＵと相互作用を行う全ての当事者の有効性を保証する。

その中でＴＣＵが運用される高い保証環境において、認証状態チェックは資格を与えられた使用者からサービスが要求された時にのみ必要とされる。情報オブジェクトに対して、認証状態は提出時にのみチェックされる必要がある。全てのデジタル署名が有効であると判定されると、その情報オブジェクトはそれ以降信頼できるものと見なされる。安全および手続き上の手法と方法とがＴＣＵの中に配備されていて、認定されていないドキュメントの改変または損失を招きかねない、犯意のある行為またはハードウェア故障を回避している。提出毎に結果として新たな版の電子オリジナル記録が生成される。ＴＣＵはオリジナル記録の最新版に関して知識を維持する責任が課せられている。この版は電子１次かつ転送可能記録と識別される。ＴＣＵは１次オリジナル記録の制御の前提を、信頼性のある日時スタンプをオリジナル記録に追加し、そのデジタル署名を適用しそしてその認証を添付することにより実証している。封体がオリジナル記録に適用されて安全性と処理利便性に対応している。この版付け処理は孤立の認定された証拠および管理の痕跡を生成するが、別の冗長監査記録が裏付けのために維持されている。

出願人のＣＳＳは今日ＰＫＩおよび電子商取引に存続する上記の制約を解消する。認証状態を会員ＣＡから取得するために必要なオリジナル情報は、それらが生成されたときにＣＳＳに登録される。外部承認されたＣＡのオリジナル情報は使用者登録処理中に入力される。ＣＳＳ検索情報は全ての認証状態源に対して必要とされる。いくつかの型式の認証状態源が存在し、ＣＳＳは各々の登録されている型式に対してコネクタまたは方法を持つ必要がある。

認証状態を伝達するためにいくつかのＣＡで使用されている１つの方法はＣＲＬであり、これは取り消された認証およびそれらの取り消し理由のリスト、そのＣＲＬの発行者、そのＣＲＬが発行された日時、およびＣＲＬの次の版が発行される予定日時を含む。全てのＣＲＬは発行元ＣＡまたは指定された署名者によって署名され、その無謬性と信頼性とを保証している。認証はその有効期間が超過するとＣＲＬから取り除かれる。

ＣＲＬが使用される所では、ＣＳＳはＣＲＬの最新翻訳をＣＡ分配点、例えば X.509 v2 CRL プロファイル（IETF RFC2459,１９９９年１月）から検索し、その署名の有効性を確認し、それを解析し、その結果を格納するキャッシュを生成する。ＣＳＳはＣＡのＣＲＬ発行間隔を用いて、次にＣＲＬのダウンロードを実行する時期を管理する。全てのＣＲＬは有効性フィールドを含み、それは通常ダウンロードを実行する際の幾ばくかの余裕を許すように設定されている。これは通信の混雑およびＣＡ不稼働時間を許し、ＣＳＳに対してこの期間を超過した場合、救済処置を強制する。その様な救済は新たに追加された取り消し認証に関連する全ての提出物の再有効性確認を含む。各々の新たなＣＲＬは先にロードされたＣＲＬを更新する。この規則の例外はデルタＣＲＬ行列である。デルタＣＲＬの内容が現在のキャッシュ内容に添付される。デルタＣＲＬに基づくＣＲＬ番号は、発行された最新の全ＣＲＬを参照する。デルタＣＲＬは短期間（分、時間）に、最後の全ＣＲＬの後に認証取り消しが発生した時にのみ発行される。ＣＳＳはＣＲＬおよびデルタＣＲＬの検索に対して責任を有し、これは発行間隔または告示およびＴＣＵ安全方針で確立された間隔を超えないと言うことに基づいている。

認証状態を分配するためにＣＡで使用される第２の方法はＯＣＳＰである。ＯＣＳＰが使用される所では、ＣＳＳは認証状態の問い合わせを受けた際にＯＣＳＰ応答機に問い合わせを行う。ＯＣＳＰ応答は彼らの無謬性および信頼性を保証するために署名される。ＣＳＳはＯＣＳＰ応答を解析し認証詳細および状態を別のキャッシュに追加する。ローカルＴＣＵ安全方針で決定された有効期間フラグが含まれており、何時その登録がキャッシュから取り除かれるかを決定する。この特徴はいくつかの情報オブジェクトが同一当事者／事業体によりＴＣＵに対して短期間にアップロードされた際の通信オーバヘッドを最小とすることを目的としている。この有効期間フラグは通常のＣＲＬ発行間隔（日に二度、毎日）よりも、通常はかなり短い（例えば５分）。ＣＳＳは認証状態を再びチェックするが、これは複数の情報オブジェクトが処理された場合、認証状態をキャッシュから消去する前に、認証取り消しが生じていないことを保証するために行われる。認証取り消しが有効期間中に生じている場合、所有者組織接続点が通知されなければならない。その他のいくつかの問い合わせ方法が存在するが、簡単のために説明は省く。それらの各々はそれらが利用される際に、コネクタおよびもしかすると別のキャッシュを必要とするかも知れないことを理解されたい。

図１は電子オリジナル資料を生成するための処理フローを示す。説明のため、情報オブジェクトは販売契約を前提としている。電子情報オブジェクトのコピー（実行されていない）がＴＣＵまたは文書準備システムから検索され、デジタル的にまたはホログラフ的に（手書き）適切な当事者によって署名される。実行処理過程を監視することにより、所有者の代理人は信頼されたアプリケーションを用いてデジタル的に署名し、情報オブジェクトを封印しそれをＴＣＵに送る。

事前に電子文書を生成し、実行または検索することにより、提出者はデジタル的に署名しそれをステップ１０１に示されるようにＴＣＵに提出する。このeSeal処理において、封体は署名されたコンテンツとデジタル署名ブロックとを含み、このデジタル署名ブロックは更に提出者のデジタル署名および認証を含み、全ての他の署名者が形成される。図１には５つの処理が示されている：（１）無効なデジタル署名そして／または取り消された認証が発見された際の行動、（２）状態がローカルにキャッシュされている場合の認証状態チェック、（３）認証状態が検索されなければならない場合の認証状態チェック、（４）ＣＲＬ検索および処理、そして（５）eSeal文書が信頼性のあるものと決定される際にeOriginalの生成。ステップ１０３において、ＴＣＵはeSealされた電子文書を受け取る。ステップ１０５において、ＴＣＵは提出者が電子文書を選択されたアカウントそして／またはトランザクションに追加する権限を有することを確認する。ステップ１０７において、ＴＣＵは電子的に封印されたデジタル電子文書内に含まれる全てのデジタル署名を暗号的に検証する。署名者のX.509認定認証内に見られる公開鍵が、検証処理過程の中で使用される。ステップ１０９において、認証有効期限が署名者の認定認証から抽出され、ステップ１１１において、有効期限が現在の日時に対してチェックされる。以上述べた検査のいずれか１つでも不合格となると、その提出物はステップ１１３で拒絶され、ステップ１１４において否認確認が送られる。処置はステップ１１７で記録される。

全ての検査に合格すると、封体の中に含まれる各認証に対する認証状態がステップ１１９でＣＳＳから要求される。ステップ１２１および１２３において、認証状態がチェックされそれが認証状態ストアの中に存在するかが確認される。ステップ１２５において、認証状態が検索され、ステップ１２７で認証の有効性がチェックされる。何らかの理由でいずれかの認証が無効であると見なされると、その提出物はステップ１１３で拒絶され、否認確認がステップ１１５で送られ、その処置はステップ１１７で記録される。その提出者は回復処置を探すように期待される。

ステップ１２７で全てのデジタル署名および認証がその提出物に対して有効であると決定され、次にステップ１２９において、ＴＣＵは日時スタンプおよびＴＣＵデジタル署名ブロックとを含む別の封体を適用する。次にＴＣＵはその提出物を電子オリジナル記録としてその記録の所有者の代わりに管理を引き受ける。ステップ１３１において、ＴＣＵはその電子オリジナルを保護された固定記憶域に配置し、ステップ１３３においてこのＴＣＵは肯定確認を送り、ステップ１１７においてＴＣＵは丁度完了した処置の通信記録をとる。

ステップ１２３において、認証状態が認証状態ストア内に存在しないと判定されると、次にＣＳＳはステップ１３５で発行元ＣＡフィールドを対象としている認証から検索する。ステップ１３７において、ＣＳＳはその発行元ＣＡが承認されたＣＡリスト上に存在するか確認するためにチェックし、このリストはステップ１３９のＣＡコネクタ・ストアにより保守されアクセスされるものである。そのＣＡがリストに存在しない場合、無効状態が戻され、処理工程はステップ１２５で再開され、ステップ１２７，１１３，１１５，および１１７と進み、結果として提出物の拒絶および否定確認の送信および記録入力が行われる。ステップ１３７で承認されたＣＡリスト上に発行元ＣＡが発見され、ステップ１４１においてそれがその認証状態報告手段がＣＲＬであると判断されると、有効状態表示がステップ１２５に戻される。ＣＡが既知で状態が対象の認証内に存在しないが、状態手段がＣＲＬの場合、ＣＲＬが存在しそれがそのＣＡに対して最新であるという条件で、その有効状態は有効であると見なされる。この処理工程はステップ１２７，１２９，１３１，１３３、および１１７と進み、結果として電子オリジナルを生成し、肯定確認を送信し、そして丁度完了した処置を記録に入力する。

ステップ１４１において、認証状態報告手段がＣＲＬでは無いと判断されると、ステップ１３７で得られたコネクタ情報を用いて認証状態報告機構に対して問い合わせがなされる。コネクタ記述の中で得られるものは、適切な認証状態集積所に問い合わせるために必要な全ての構成情報であって、ＣＡ、ディレクトリ、またはその他の任意の型式の認証状態集積所などである。ステップ１４５，１４７，１４９，および１５１に関連する状態ストア（すなわち、それぞれＬＤＡＰ，ディレクトリ、ＯＣＳＰ応答機、データベース、およびサーバ）はその様な集積所の例である。ステップ１４３での問い合わせに応答して、これらの１つが認証状態情報と共に応答し、その状態はステップ１５３で認証状態ストアに追加される。

ステップ１５３で追加されると、実行中認証状態処理工程はステップ１２１で再開し、ステップ１２３，１２５および１２７と継続して、その提出物が受領（ステップ１２９，１３１，１３８，１１７）または拒絶（ステップ１１３，１１５，１１７）のいずれかの結果となる。

ＣＲＬはステップ１５５においてあらかじめ定められた間隔で、またステップ１５７において、疑義のある妥協が報告された時および方針上即答が要求された際に必要に応じて発行される。この処理工程は図２で更に説明される。

ＣＡが既知で状態が存在せず、状態機構がＣＲＬ以外の場合、認証状態サービスはコネクタを選択して認証状態機構に問い合わせる（ステップ１４３）。このコネクタは状態検索を行い、解釈を可能とするために必要な情報を含む。ステップ１４５−１５１に示されている実時間認証状態の任意のソースが、認証状態問い合わせに現在状態で応答するが、この処理工程はこれらのソースに限定されるものではない。ステップ１５３において、状態が受け取られて認証状態ストアに追加される。状態が追加されると、１つの応答が生成され処置はステップ１２３に戻り、状態の処理はステップ１２５で再開され、先に説明したように完了する。

次に図２を参照するとＣＳＳはＣＲＬ検索をバックグラウンド処理として実行する。１つのＣＲＬは無効とされたかまたは現在日時が認証の中に含まれる有効期限を越えて一時停止された全ての認証のリストを含む。一時停止された認証はそれらがあたかも無効とされたかの様に取り扱われるが、それらは回復されて結果としてＣＲＬから取り除かれるはずである。無効とされた認証が回復されることは無い。

ステップ１５５において、ＣＡ管理者はあらかじめ定められた間隔でＣＲＬを発行するようにＣＡを構成する。ステップ１５７でＣＡ管理者はまた、ローカル認証または安全方針で指示された通りにデルタＣＲＬも発行する。ＣＡ管理者またはＣＡはデルタＣＲＬの発行を通告する。デルタＣＲＬは全ＣＲＬの発行間隔の間で認証が無効となるかまたは一時停止される度毎に作成される。デルタＣＲＬは無効とされたＣＲＬの完全なリストを含むはずである。ステップ２０１において、ＣＲＬおよびデルタＣＲＬがＣＲＬ集積所またはディレクトリに対して発行される。

ステップ２０３において、ＣＳＳはＣＲＬ発行スケジュールまたはデルタＣＲＬ通告を検索し、ステップ２０５は計画的な検索で使用されるタイマを表す。このタイマはまた全てのＣＲＬ内に含まれる「次回更新」フィールドに基づく検索も可能とする。ステップ２０７においてＣＲＬまたはデルタＣＲＬがＣＲＬ集積所から検索される。ステップ２０９において、ＣＲＬまたはデルタＣＲＬがステップ１５３で適切なキャッシュまたはステップ１２１で認証状態ストアのリストまたはディレクトリに確立されたスケジュールまたは通知に基づいて追加される前に、解析される。ＣＲＬを解析することにより管理が容易となりＣＲＬ入力参照でのオーバヘッドが削減される。ＣＳＳのステップ１１９，１２３，１２５，１３５，１３７および１４１が図２により完全に図示されており、これらは図１での説明のように実現されている。

次に図３を参照すると、認証状態ストアは多数のキャッシュを含み、それらは異なる報告機構からの認証状態を保持している。キャッシュ（図３にはそれらの内の５つが示されている）は、個別のＣＡ（キャッシュ３０１，３０３）またはＣＡの集合（キャッシュ３０７，３０９）に写像している。実時間で報告される状態に対して、その状態は空きが必要となるか（例えば、使用頻度が最も少ない）または方針上の要求（例えば、特定の指定期間のみ保持）が有るまで、キャッシュ上に残っている。状態は通常は一度基準を超えると取り除かれる。

これらのキャッシュの目的は、方針で示された期間認証状態を保持することであり、これにより認証状態およびＣＲＬ検索中に必要とされる通信オーバヘッドを削減する。従ってＣＳＳは通信を停止できる。

ＣＲＬは解析され、キャッシュ内に配置された個別の無効とされた認証状態は、ＣＲＬが繰り返しチェックされる場合に結果として生じる計算のオーバヘッドを削減する。これはキャッシュ３０５，３０７に示されている。キャッシュの内容は新たな全ＣＲＬが検索される度毎に置き換えられる。

次に図４を参照すると、シンタックス例が示されており、デジタル署名ブロック内に含まれる必要がある更に重要なデータ要素のいくつかを表している。図４はデータ要素の自由形式例であって、署名が複数のメッセージ断片および日／時スタンプに適用される際のデジタル署名を作り出す。この例はデジタル署名ブロックで使用されるはずのシンタックスを例示するように意図されている。<CumulativeHashValue>データ要素が、１つまたは複数の断片または全コンテンツの HashValuesおよび全てのAuthenticated Dataに適用されることに注意されたい。

図５は認証状態サービスを支援する基本ブロックを示す、安全通信アーキテクチャを示す。図は３つのＣＡ，ＣＳＳ、およびＴＣＵ間の相互作用を示す。ＣＳＳは好適にＴＣＵの地元に置かれていて高い利用性を保証している。その第１次的目的はＴＣＵに共通通信にインタフェースを提供し、認証状態情報の安全でタイムリな提供を保証することである。その第２次的な目的はサービスの保証された水準または品質を、認証状態情報を維持する際に要求される通信並びに計算オーバヘッドを管理することにより保証することである。

図５に示されるように、好適な通信ルータおよびハブを具備したＣＳＳサーバおよびＴＣＵは好適に通信ファイヤウォールの内側に配置されている。ルータおよびハブは情報をＣＳＳおよびＴＣＵに必要に応じて導く。この情報の中には eSeal 提出物を含むものがあり、これらの提出物は先に説明したようにＴＣＵに対してインターネットの様なネットワークを通して、使用者クライアント・アプリケーションから送られる。またＯＣＳＰ経由のＣＳＳおよびＴＣＵ通信も図示されている。

図５はまた３つのＣＡを図示しており、これらはそれぞれの通信ファイヤウォールの内側の異なる例示環境にある。企業ＣＡは点線で囲われた賃貸工業ＣＡとインタフェースするサーバを含むかも知れない。外部ＰＫＩまたは応答機は、例えばＰＫＩ，ＣＡ、および認証状態応答機の様な事業体とインタフェースするサーバを含む場合がある。階層的会員ＰＫＩはＣＲＬおよび認証状態用のＶ３ ＬＤＡＰ、ルートＣＡおよび抵当並びに賃貸工業、貸し手、閉鎖代理人、および所有権保証者向けＣＡの様な事業体とインタフェースする場合がある。

図６および図７は、それぞれ会員ＣＡおよび外部ＣＡ両方の使用者（加入者および事業体）登録処理中の認証状態サービスの使用を表す。会員ＣＡは使用者認証を発行するように信頼されている。外部ＣＡは外部事業体により運用され彼らの認証がＴＣＵ活動と共に使用される前に承認される必要があるものである。使用者身元認定は全てのＣＡで厳格に実行されるかまたは組織代理人に委託される必要がある。別の要求は、ＴＣＵが使用者へのアクセスを許可出来る前に、使用者の認証が１つまたは複数の承認する組織のアカウントに直接関連づけられるかまたはその使用する権限を与えられている必要がある。一度これが実施されると、ＴＣＵは使用者のデジタル署名を受け入れ、ＣＳＳに依存して認証状態有効確認を行う。

図６において、ＴＣＵ登録処理はステップ６０１で、組織の管理者／代理人が依頼人からの使用者登録情報を受け取ることにより開始する。ステップ６０３において、この管理者／代理人は、要求を行うために依頼人の信頼性を審査するように依頼される。依頼人は通常彼らのアカウントに対する管理のみを与えられている。ステップ６０５において、管理者／代理人はその使用者をＴＣＵに登録し、使用者アカウントを設定する。ステップ６０７において、管理者／代理人は次にトランザクション特権を使用者に割り当てる。トランザクション特権は、電子オリジナルおよびその他のソース記録を提出、バージョン管理、転送などを行える機能を含む。

ステップ６０９において、暗号トークン（デジタル署名機構）が初期化され、ステップ６１１において、一対の公開鍵がそのトークンに対して生成される。ステップ６１３で認証要求が作成され、そしてステップ６１５でその要求が組織のＣＡに送られる。ステップ６１７において、その認証が検索されてそのトークン上に配置される。ステップ６１９で、その認証が使用者ＴＣＵアカウントと結合されるかまたは関連づけられる。

ステップ６２１で使用者の身元の有効性が、例えば個人的にその使用者の身元確認を行える組織の管理者／代理人の所へ本人が出頭するなどして、確認される。通常、少なくとも２つの形式の身元証明が要求される。使用者の参画が依頼人により後援されているので、管理者／代理人により知られている誰かにその使用者の身元保証をするように依頼されるような、高価値トランザクションを除いて、これで十分である。ステップ６２３で、使用者は請負契約に署名するように依頼され、これにより使用者はその使用者のデジタル署名の使用が拘束力を持つことに同意する。ステップ６２５で使用者にはプリケーション使用者マニュアルが与えられ、いかなる取扱説明書も必要であるとみなされる。ステップ６２７および６２９において、使用者にはログオンＩＤ、暫定パスワード、および暗号トークンが与えられる。

ステップ６３１で使用者はシステムにログオンし、ステップ６３３でテスト文書をＴＣＵに提出する。ステップ６３５で、ＴＣＵは使用者のデジタル署名の有効性を確認し認証を与える。ステップ６３７でＴＣＵはＣＳＳに対して認証状態情報を問い合わせる。ステップ６３９において、ＴＣＵは状態を受け取り、それに応じて処理する。受け取った認証状態が有効な場合、登録はステップ６４１で完了し、その使用者はＴＣＵにアクセスし使用することが可能である。認証状態が無効の場合、登録はステップ６４３で終了し、管理者／代理人はエラーの原因を判定して救済処置を開始するが、それには概略で示した登録手続き手順のいくつかまたは全てを繰り返すことが含まれる。図６に概略を示した信頼性のある処理手順は、会員登録は完了した時点で、完全に有効となることを保証している。

図７では、方針で指示された条件に合致する場合、外部ＣＡで以前に発行された暗号トークンを使用者が使用することを許している。先に説明したように、登録ステップ６０１から６０７が先に行われる。使用者身元確認および契約とか６２１から６２７が先に説明したように行われる。

使用者は既にトークンを持っているので、処理工程は図６に示されたものとは異なる。ステップ７０１で使用者はトークンを互換読み取り機上に置き、ログオンする。ステップ７０３で、管理者アプリケーションは使用者の認証をそのトークンから検索する。ステップ７０５で認証情報が表示され、発行元ＣＡ身元情報が得られる。このＣＡ情報はステップ７０７で、そのＣＡが承認されたリストに載っているか審査するために使用される。そのＣＡが承認されたリスト上に無い場合、そのＣＡ情報はステップ７０９でＴＣＵ管理者に提供され、その管理者はステップ７１１で入会指針典拠(Application Policy Authority)とチェックし会員登録の継続を許可する。入会指針典拠は外部ＣＡを承認リストに追加することのみを認定できる。

ステップ７１３で許可が否定された場合、会員登録はステップ６４９で終了し、使用者に３つの選択肢を与える。１つは会員ＣＡで発行されたトークンを使用するように求める。別の選択肢はＣＡ拒絶決定の見直しを要求する。第３の選択肢は以前に承認された外部ＣＡの名称を問い合わせる。

ステップ７１３で発行元ＣＡが承認されているがリストには載っていない場合、ステップ７１５で管理者はそのＣＡとコネクタ情報承認済みリストを追加し、ＣＳＳが認証状態をそのＣＡから検索するように構成する。

ステップ６１９で、使用者認証が新たに作成された使用者アカウントに結合されるかまたは関連づけられる。図６のステップ６３１から６３９と同様、使用者はそのアカウントが正しく設定されて、その使用者がＴＣＵにアクセス出来るかを確認するために、試験提出をＴＣＵに対して行うように求められる。ＣＳＳが有効状態情報を戻すと、会員登録はステップ６４１で完了する。ＣＳＳが無効状態を戻すと、管理者はそのエラーの原因を判別し救済処置を実行し、それは先に説明した会員登録手順のいくつかまたは全てを繰り返すことを含む。もっとも起きやすい失敗原因は、ＣＳＳが外部ＣＡに接続して正しく認証状態を検索出来るかに関連している。

ＣＳＳは使用者認証および発行元ＣＡが共にＴＣＵまたは他のシステムへアクセスすることを認定されているかの有効性確認において、非常に重要な役割を担っている。１つの発行元ＣＡが承認済みリストから取り除かれる、そのコネクタ構造データが消去されると、全ての関連する使用者はそれ以降ＴＣＵへのアクセスを拒まれる。ＣＳＳは認証状態を要求する他のアプリケーションおよびシステム、複数のＰＫＩおよびＣＡとの相互作業を要求するアプリケーションおよびシステムを含む、と一緒に作業をすることが出来ることを理解されたい。

例えばＣＳＳの別の用途は、サービスを探している顧客とそのアプリケーション運用者との間に契約が存在しているところで、自己署名認証を含む信頼に足る認定認証に状態を提供することである。信頼に足る認証の表現（例えば、ＰＥＭ、認証ＩＤ、適用されたデジタル署名）はＣＳＳでキャッシュされ、状態は信頼されたコネクタを用いて問い合わされる。これによりアプリケーションが単一の認証状態を持つことを可能としており、これはその認証が自己署名されたものかまたはＣＡにより発行されたかを問わないことを意味する。この信頼された認証方法は共同体の１つまたは複数のＣＡに問い合わせるというよりむしろ、少数の管理された認証が１つの共同体で使用される場で使われる。従って、「ＣＡ」および「発行元ＣＡ」という用語はこの出願で使用されるように、従来のＣＡのみならず自己署名認証の認められた発行者も含む。

更に、ＣＳＳは認証状態を検索するためにコネクタの組み合わせも使用する。少なくとも１つのコネクタは、信頼された認証での使用に関して丁度説明した様に「仮想的」なものである。ＣＳＳは予め定められた、例えば順序が決められたシーケンスで認証状態が獲得されるまで、コネクタを呼び出す。この方法は状態ソースの階層（例えば、最も信頼の高いものから最も信頼の低いもの）を作成することを可能とする。

図８は自動車賃貸の例を図示し、如何にしてＣＳＳが電子商取引の中で利用されるかを示している。自動車のディーラまたはディーラの代行者、これ以降簡単のためにディーラと呼ぶ、にはコンピュータで表されている自動車ＣＡからそれぞれの認定認証が発行されている。自動車特約店に居ると思われる自動車の賃借人には、それぞれの認定認証が銀行ＣＡから発行されている。遠隔地に居る賃貸人にはそれぞれの認定認証が金融ＣＡから発行されている。これに代わって、賃借人または賃貸人のいずれかが自己署名認証を作成しておくことも可能であり、これにはディーラが賃貸アプリケーションおよびＣＳＳとして登録されており、これは例えば賃借人がそのディーラの馴染みの顧客の場合である。

この出願の中で説明されるように、ＣＳＳはこれらおよびその他の認証の状態を、承認された状態報告プロトコルを使用する任意の認証状態報告手段を用いて、検索して報告する。図８において、自動車ＣＡおよび金融ＣＡはＯＣＳＰを使用し、銀行ＣＡはＣＲＬを使用し、またディーラおよび賃借人は、彼らの認証および暗号化署名手段を含む何らかの形式のトークン（例えば、ＰＫＣＳ＃１１，ＰＫＣＳ＃１２，ブラウザ鍵ストアなど）を有するものと仮定している。図８はトランザクションの実行見本にすぎないことは理解されよう；個々のトランザクションで必要な通信に応じてより多くまたはより少ないＣＡが接続可能である。

ステップ８０１において、ディーラは賃借契約を起草するかまたはそれを賃貸アプリケーション、例えば特約店でローカルに、または遠隔サイト例えばアプリケーション・サーバで沿革的に実行されている実行プログラム、から検索する。ステップ８０３で、ディーラは賃借人と賃貸人との賃貸契約の実行を調整する。この賃貸契約書はローカルな賃借人と遠隔地の賃貸人の両方に同時に表示され、ディーラは質問に回答し必要で有れば訂正するように求められる。ディーラはこの賃貸契約を賃貸人にＵＲＬ（uniform resource locator）を提供することで表示するように手配し、これにより賃貸人がこの賃貸契約を再検討して契約書に署名することを可能とし、署名された版がディーラに戻される。賃借人およびディーラによりローカルに、例えば賃貸契約書の上に賃借人のデジタル署名をキャプチャするタブレットＰＣを用いて署名され、また賃貸人により遠隔地で署名された後、この賃貸契約書は電子貯蔵所に送信され（ステップ８０５）、これはアプリケーション・サーバと通信するように示されている。賃借人とディーラによるデジタル署名は好適に動的であり、これはアプリケーション・サーバが表示を「デジタル的に署名された」表示器を表示された画像に適用することで更新することによりなされる。実際のデジタル署名は好適に表示されない。

アプリケーション・サーバおよび関連する電子貯蔵所がディーラによって、賃貸人により遠隔的に署名するために契約書を保存するために使用されることは理解されよう。ステップ８０７から８１１を通して、賃貸人はこの貯蔵所から賃貸契約書を検索し、その契約内容にデジタル的に署名することにより同意し、そのデジタル的に署名された版を貯蔵所に戻す。ステップ８０７から８１１は多元サイト協調および同期トランザクション処理の両方を図示している。

ステップ８１３から８１７において、受領された電子文書（賃貸契約書）はデジタル署名をチェックされ、何かが見つかると、このデジタル署名は検証されてそれぞれの認定認証の有効性が確認される。ステップ８１７において、現地時刻がチェックされてそれが認証の有効期間に入るか保証し、ステップ８１９でＣＳＳは認証の状態が問い合わされる。ステップ８２１の応答の中で、ＣＳＳは第１に認証状態用のそのローカル・キャッシュ・メモリまたはデータ・ストアをチェックし、認証状態が存在し現在のものである場合、ＣＳＳはステップ８２７でその認証状態を「使用可能」として返却する。ステップ８２３で、認証状態が存在しないかまたは現行のものでない場合、ＣＳＳは発行元ＣＡにこの目的用に作成されたコネクタを用いて問い合わせる。ステップ８２５において、発行元ＣＡ、例えば銀行ＣＡ、またはその状態報告手段（例えばディレクトリ）は状態をＣＳＳへ、好適に同じコネクタを用いて戻し、ステップ８２７でＣＳＳは問い合わされた認証の状態をアプリケーション・サーバへ返答する。

全てのデジタル署名と認証が検証されて有効であると確認されたと想定すると、電子文書が信頼に足るものと証明し、アプリケーション・サーバはその電子文書の管理を引き受けて、ステップ８２９でそれを新たな版として電子貯蔵所の中に格納する。従って、適切な特徴を具備することでアプリケーション・サーバと電子貯蔵所は１つのＴＣＵとして協力することが分かるであろう。ステップ８３１において、新たな版が信頼できるコピー、送信可能記録である電子オリジナルとして指定されるが、それは日時スタンプを添付しＴＣＵのデジタル署名をその文書に適用することにより行われる。文書上の少なくとも１つのデジタル署名が有効である限り、このステップが実行される。

ステップ８３３において、いずれかのデジタル署名または認証が全ての試験に不合格となる場合、ディーラには回復処置を探すように警告され、これは典型的にステップ８０１から８２９を有効代替デジタル署名が適用されるまで繰り返すことを含む。この回復処理は署名者の認証の状態が無効とされているかまたは期限切れとなっている場合、新たな認証および暗号素材が発行されるまで完了することが出来ない。

例えば自動車賃貸契約書のような情報オブジェクトが電子形式、例えばＸＭＬ，ＰＤＦ，ＰＫＣＳ＃７，Ｓ／ＭＩＭＥ等で表現されており、これはデジタル署名の配置と検出とを可能とし、認定されていない変更を防止することは理解されよう。従って多数のこれらの形式を、安全封体または含まれる情報の封筒として考慮することが可能である。

ＣＳＳを認証の状態をチェックするために、鍵の使用とは無関係に使用できることを理解されよう。その様な認証は、これに限定するわけでは無いがその１次使用が身元確認および認定ではない、例えば、鍵同意／交換、認証署名、ＣＲＬ署名、鍵暗号化、データ暗号化、暗号化のみ、暗号解読のみ、および安全ソケット層（ＳＳＬ）を含む。従って、本出願内で使用されるように、「認定認証」という用語は一般的に、身元保証には使用されないこの様な認証も含むことを理解されよう。

加えて、ＣＳＳコネクタ好適に単一通信の中に、複数の認証状態チェックを組み込むことが可能である。なかんずく、この機能は使用者／事業体認証およびＣＡ認証のいくつかの連鎖または全ての連鎖、例えばルートＣＡから発行元ＣＡまでのＣＡの階層の有効性確認で使用される。これは認証経路内の全てのＣＡが依然として有効であることを追加して保証する。

本出願は認証状態サービス（ＣＳＳ）を構成するための方法を説明してきたが、これは必須の発行元ＣＡに認証状態を検索するために必要な設定情報を決定し、発行元ＣＡから認証状態を検索するために使用される認証状態参照技術と互換のコネクタを識別し、コネクタを選択されたコネクタと発行元ＣＡに特定の設定および通信パラメータで構成し、ＣＳＳ写像を発行元ＣＡとそのコネクタとの間で設定する、以上のステップを含む。ＣＡ指定とコネクタが構成ストア内の承認されたＣＡのリストに追加される。

それぞれの検証可能な証拠痕跡を有する認定された情報オブジェクトを転送することによりトランザクションを実行するための方法は、第１当事者が信頼された貯蔵所から認定された情報オブジェクトを検索するステップを含む。認定された情報オブジェクトは提出側当事者の第１デジタル署名、少なくとも提出側当事者の身元および暗号鍵に関する第１認証、信頼できる日時、信頼された貯蔵所のデジタル署名、少なくとも信頼された貯蔵所の身元および暗号鍵に関する認証を含む；提出側当事者のデジタル署名および認証は信頼された貯蔵所によって提出時に、情報オブジェクトの信頼性を証明することにより有効性の確認がなされている；また認定された情報オブジェクトは格納部の中に、信頼された貯蔵所の管理下に置かれた電子オリジナル情報オブジェクトとして配置される。

トランザクション実行方法は更に、使用に対してコミットすること、および、署名行動の前に彼らのデジタル署名に結合することをどの署名事業体にも要求し、少なくともデジタル署名および署名側当事者の認定認証を含んで構成された前記情報オブジェクトをいずれかの当事者により実行し、少なくともデジタル署名および署名側当事者の認定認証を含む署名ブロックを作成し、その署名ブロックを情報オブジェクトに関連づけ、複数の事業体が情報オブジェクトそして／または封体にデジタル的に署名する先の実行ステップを繰り返し、デジタル的に署名そして／または封入された情報オブジェクトをＴＣＵに転送する、以上のステップを含む。ＴＣＵは全てのデジタル署名を検証し、各関連する認定認証の有効性を確認し、状態をＣＳＳから検索する。署名ブロックは、署名者のデジタル署名ブロックが検証されないかまたは、署名者の認定認証の期限が切れているかまたは無効であると報告されている場合は拒絶される。いずれかの署名ブロックが拒絶されるとその結果、署名ブロックの置き換えまたは回復処置の開始が要求される。少なくとも１つの署名ブロックが有効であると判定されると、ＴＣＵはそれ自身の署名ブロック、また信頼性の高い日時を含む、を対象となる情報オブジェクトに添付し、所有者の代わりにそれを保持し管理する電子オリジナルを作成する。

デジタル署名ブロックの作成は、１つまたは複数の情報オブジェクト断片または全情報オブジェクトに対する１つまたは複数のコンテンツ・ハッシュを計算し、１つまたは複数のコンテンツ・ハッシュおよび全ての添付データ、例えば現地日時、署名原理、または指令にまたがるハッシュを計算し、計算されたハッシュを署名側当事者の秘密鍵を用いて暗号化し、これによって署名者のデジタル署名を形成し、そして署名者のデジタル署名を署名ブロックの中に署名者の認定認証と一緒に配置する、以上のステップを含む。添付データが現地日時を含む場合、デジタル署名の作成は更に現地日時を表示するか、署名者に対して日付および時刻が正しいかの確認を要求し、現地日付および時刻が正しくない場合修正するか、またはこれらが信頼された時刻サービスで設定され現地日付および時刻が変更されることを防止されている場合はシステム日時に依存する、以上のステップを含む。現地日時をチェックしてそれが正確であり、それが使用者の認定認証有効期限内でありその現地日時がその有効期限で指定されている日時の前でも後でも無いことを保証することが可能である。

検証で不合格となったデジタル署名の回復方法は、デジタル署名を再計算し署名ブロックを再送信することを要求する。認定認証有効期限侵害の回復方法は、使用者に対してその使用者の認証が期限切れとなっていることおよび更新しなければならないことを通知し、トランザクション所有者に対してそのトランザクションが不完全であることを通知することを含む。

１つまたは複数の署名ブロックおよびその中に含まれる情報の配置は、少なくとも１つの署名タグで指定される。１つまたは複数の手書き署名および日付がデジタル化され、情報オブジェクト実行に使用され、署名および日付の配置は少なくとも１つの署名タグで指定される。１つまたは複数の署名ブロックはＴＣＵに対して対応する署名タグの表示と共に個別に送ることが可能であり、ＴＣＵは別々にまたはグループで送られてきた全ての署名ブロックの有効性を確認することが出来る。デジタル署名の検証または認定認証有効性確認ステップのいずれかが不合格となると、ＴＣＵはその署名ブロックを拒否して回復方法を要求し、署名ブロック有効性確認ステップが合格すると、ＴＣＵはその署名ブロックを指定タグに配置する。署名ブロックを個別に送信するために、ＴＣＵは信頼性のある日付および時刻を各々の署名ブロックに追加する。ビジネス規則によれば、ＴＣＵはそれ自身の署名ブロックを添付し、これは主題情報オブジェクトと挿入された署名ブロックとを含む封体の中に信頼性のある日付と時刻とを含み、これにより電子オリジナル情報オブジェクトを作成する。複数の使用者署名ブロックが１つの封体の中に追加され、その封体はその他のビジネスおよび安全処理工程を実施するために再帰的に適用することができる。

ＴＣＵは電子オリジナル情報オブジェクト内に含まれるかまたは追加される署名ブロック内に存在するデジタル署名および認定認証の有効性確認を、ビジネス規則データベースの中で認定認証で身元保証された署名事業体が要求された処置を実行するための信頼性を有するかのチェックを行い、署名側事業体のデジタル署名を検証し、認証有効期限が現在の信用できる日付および時刻の範囲内で有るかをチェックし、伝達された現地日時がＴＣＵ日付および時刻内の許容差以内に入っているかをチェックし、認証状態をＣＳＳを用いてチェックすることにより、行う。これらのステップのいずれかの結果が無効または虚偽となった場合、そのデジタル署名は無効であると見なされ、要求された処置は不許可となり回復手段が探される;それ以外の場合は、そのデジタル署名は有効であると見なされ、要求された処置は許可される。

発行元ＣＡのＣＳＳへの登録は、その発行元ＣＡをＣＳＳ知識ベースの中に「認定済み」として、工業または組織ビジネス規則およびシステム方針に基づいて含めるための審査と承認のステップを含む。審査ステップが不合格となると、その発行元ＣＡはＣＳＳ構成ストアに「不認定」として追加されるかそして／またはＣＡ登録が終了する；それ以外の場合は、発行元ＣＡは「認定済み」として追加され、通信パラメータ（ＩＰアドレス、ＳＳＬ鍵および認証）および認証状態を報告するために使用される方法（ＯＣＳＰ，ＣＲＬ，ＬＤＡＰ）がＣＳＳ構造ストアに追加され、もし既設でない場合は認証状態を解釈するためにコネクタが追加される。この様にしてＣＳＳは１つのシステムまたはＴＣＵと多種多様な認証状態応答機との間の相互運用性を可能とする。

認証状態チェックは、通信を確立するために好適にＣＳＳを採用し、認証状態を承認された認証発行元ＣＡから検索してキャッシュする。ＣＳＳが認証状態問い合わせを１つのシステムまたはＴＣＵから受け取ると、ＣＳＳは最初にそのローカル・キャッシュをチェックしてその認証状態が存在するか確認し、発見されかつ有効期限内である場合には状態を返却する。認証状態が存在しないかまたは有効期限が切れている場合は、ＣＳＳは最初に接続情報をその構造ストアから要求することにより状態を検索する。ＣＳＳは次に通信セッションを、その構造ストア内で識別された認証状態報告構成要素と確立する。ＣＳＳはＣＳＳ構造ストア内に含まれる方法によって認証状態要求を作成し、そのＣＳＳは認証状態を認証状態報告構成要素から検索し、構成要素とのセッションを閉じる。ＣＳＳは少なくとも認証のＩＤ、認証状態および有効期限をそのキャッシュに追加し、認証状態を要求元システムまたはＴＣＵに返却する。

認証状態報告はＣＲＬとＣＲＬの処理とに基づいている。発行元ＣＡの発行スケジュールに基づき、ＣＳＳはＣＲＬをＣＳＳ構造ストア内のリストに挙げられている認証状態報告構成要素から検索する。ＣＳＳは発行元ＣＡに関連するキャッシュ・メモリを消去し、ＣＲＬからの認証状態を解析し、その認証状態を発行元ＣＡに関連するそのキャッシュの中に配置する。発行元ＣＡからそのＣＲＬが利用可能であるとの通知を受けると、ＣＳＳはＣＲＬをＣＳＳ構造ストア内のリストに挙げられている認証状態報告構成要素から検索する。基準によりそのＣＲＬが完全なＣＲＬを要求される場合には、ＣＳＳは発行元ＣＡに関連するキャッシュを消去し、そのＣＲＬを解析し、その認証状態および関連する情報を発行元ＣＡに関連するキャッシュの中に配置する。ＣＲＬが全ＣＲＬの発行後に生じた変化のみを含む場合、ＣＳＳは認証状態をＣＲＬから解析し、認証状態と関連する情報を発行元ＣＡに関連するキャッシュの中に配置する。

使用者、システムまたはＴＣＵが認証状態を獲得するために単一手段を使用することを可能とするＣＳＳを、認証状態を獲得するために使用することは、ＣＳＳに対して情報オブジェクト上の署名ブロック内に存在する認定認証の状態を、単一手段（例えばＯＣＳＰ）を使用して問い合わせ、状態問い合わせを発行元ＣＡで要求される形式に翻訳し、認証状態を検索そして／または報告する、以上のステップを含む。認証状態が無効とされると、その署名ブロックは使用されず回復方法が要求される；デジタル署名を検証し認証状態が有効である場合、署名ブロックが電子オリジナル情報オブジェクトに追加される。

ＴＣＵはＣＳＳに署名者の認定認証状態の有効性確認を問い合わせることが出来るが、それはその状態がＣＳＳキャッシュ／データ・ストア内に存在し現在有効な場合、認証状態を配置し報告し、認証状態をＣＳＳ構造ストアから検索するための型式と手段とを獲得することで行われる。特定の認証状態方法がＣＲＬで、措定された認証状態がＣＳＳ内の発行元ＣＡキャッシュ内に発見されない場合、ＣＳＳは認証状態を有効であると報告する。認証状態方法がＣＲＬで無い場合、ＣＳＳはＣＳＳ構造ストア内に含まれる方法によって認証状態要求を構成し、適切な通信を発行元ＣＡと確立する。ＣＳＳは認証状態を状態報告構成要素から、特定された認証状態チェック方法を用いて検索し、そして通信セッションを閉じる。ＣＳＳは検索された認証状態を解析または解釈し、有効期限値をＣＳＳ方針で述べられている状態型式で指定された期間と等しく結びつけ、少なくとも認証のＩＤ、および有効期限を発行元ＣＡの認証状態キャッシュに追加する。次にＣＳＳは認証状態を要求側システムに返却する。

認証がＣＳＳで認知されている承認された発行元ＣＡから発行される、システムまたはＴＣＵの中に使用者を登録するための方法は、使用者を確立された会員手順および基準を用いて審査し、承認された組織引受人により署名されている使用者登録情報を入力し、認証要求を作成して特定された発行元ＣＡへ送ることを含む。使用者の認定認証は検索され、発行され、そしてトークン上に配置されて発送される。デジタル署名、デジタル署名検証およびＣＳＳ認証状態チェックが、公開鍵対生成を保証するために実行され、認証発行処理過程が正しく完了する。使用者は使用者同意書に署名を要求されるが、これは使用者に対して彼らのデジタル署名の使用が彼らの手書き署名と同様の重みを持つことを約束し、トークンが使用者に渡され、使用者のシステムまたはＴＣＵアカウントが起動される。

使用者をシステムまたはＴＣＵに登録するための方法は、その使用者が既にＣＳＳからは以前に知られていない１つのＣＡから発行された認証を有している場合、その使用者の認定認証に対する使用者トークンを問い合わせて発行者情報を獲得し、発行元ＣＡがその中に含まれるかを調べるために使用者の認定認証に使用者のトークンを問い合わせることを含むことができる。含まれていない場合、工業または組織方針管理者に連絡を取って、その発行元ＣＡがそのＣＡを含めるためのシステム規則に合致するか否かの判断が行われる。発行元ＣＡが「非認定」と見なされると、登録は終了し、発行元ＣＡが「認定」と見なされると、登録処理は先に説明したように進行する。

使用者の認定認証コンテンツの一部を使用してその認証を使用者のアカウントと結びつけられるが、それは使用者がシステムまたはＴＣＵへアクセスすることを承認した後、使用者登録情報を入力し、使用者の認定認証を保持する使用者のトークンを挿入し、認証コンテンツを検索して表示し、使用者にそのコンテンツが正しいかの確認を行わせ、選択されたフィールドを認証から抽出されたシステムまたはＴＣＵ使用者登録データ、例えば認証ＩＤ、発行元ＣＡ使用者の識別名称の一部または認証拡張部で伝達されるその他の識別情報（例えばsubjectAltName）に追加して行われる。抽出されたデータはシステムまたはＴＣＵ方針で特定されていて、データの抽出および入力は自動化できる。

情報オブジェクトの提出者が提出された情報オブジェクトの信頼性を保証する方法は、提出者の署名ブロックを情報オブジェクトそして／または封体に添付し、それをシステムまたはＴＣＵへ転送するステップを含む。署名ブロック有効性確認に失敗すると、ＴＣＵは再送または回復方法を要求し、署名ブロック有効性確認に合格すると、ＴＣＵは次に提出者の身元が通信セッション開始者のそれと整合するかチェックし、開始者と提出者が異なる場合はその提出物を拒絶する。全てのチェックに合格すると、ＴＣＵはその署名ブロックを提出物に追加し、電子オリジナル情報オブジェクトを作成する。

有効期限データ要素を採用した実時間認証状態報告手段用に正確でタイムリーな認証状態を維持するＣＳＳ内の方法はこれらのステップを含む。ＣＲＬ状態方法が使用されている場合、ＣＳＳは状態を報告する。認証状態がキャッシュの中に有り、有効期限データ要素が超過していない場合、ＣＳＳは状態を報告する。有効期限データ要素が超過している場合、ＣＳＳは認証状態入力を発行元ＣＡキャッシュから消去する。状態が実時間認証状態報告手段（例えばＯＣＳＰ，ＬＤＡＰ問い合わせ等）を用いて検索され、その状態がキャッシュの中に存在しない場合、認証状態が要求され、検索されそして報告される。次にＣＳＳは少なくとも認証のＩＤ、認証状態および有効期限をそのキャッシュに追加し、認証状態を要求元システムまたはＴＣＵに返却する。

認証状態使用計数器データ要素がＣＳＳの発行元ＣＡキャッシュ内の認証の状態入力に追加され、その状態使用計数器は認証の状態がチェックされる毎に増数更新または減数更新される。この状態使用計数器がＣＳＳ方針で設定された閾値を超えると、認証状態が報告されるがＣＳＳは認証状態入力をその発行元ＣＡキャッシュから消去する。ＣＳＳが認証状態が不正または無効を返却すると、システムまたはＴＣＵはそのエラーを記録そして／または提出者そして／またはトランザクション所有者に報告し、要求された処置は不許可となり回復方法が探される。それ以外の場合、デジタル署名は有効と見なされ、要求された処置は許可される。認証状態最新被アクセス・データ要素が追加され、使用計数器と共に使用されて認証状態の活動レベルを判定する。

バックグラウンド処理によりＣＳＳが自動的に更新された認証状態を検索し、ＣＳＳ方針の基準に合致した時に、新たな有効期限および使用計数器データ要素を確立させることが可能である。この事前フェッチはシステムまたはＴＣＵ認証状態要求とＣＳＳ応答との間の平均時間を短縮することが可能である。

ＣＳＳに対して新たな認証の認証状態検索要求がなされ、発行元ＣＡキャッシュが割り当てられたバッファ・サイズ限界に達した場合、認証状態最新被アクセス・データ要素が、ＣＳＳの発行元ＣＡキャッシュ内の認証の状態入力に追加される。ＣＳＳは発行元ＣＡキャッシュの中で最新被アクセス・データ要素の最も古い日時（最も低い使用頻度）を探し、その入力を消去する。次にＣＳＳは要求された認証状態を検索し、それを発行元ＣＡキャッシュの空けられた場所に配置してその状態を方針に基づいて行動しているシステムまたはＴＣＵに報告する。

分散されたＣＳＳ内で状態をチェックする方法は、新たな発行元ＣＡが導入される度毎にＣＳＳとの間で調整し、他のＣＳＳが発行元ＣＡに対する問い合わせの１次責任を有する場合、全てのＣＳＳ知識ベース内への入力を確立し、他のＣＳＳへ発行元ＣＡの代わりに問い合わせてＣＳＳと発行元ＣＡとの間の通信を削減し、複数のローカル・システムが１つの発行元ＣＡに対して認証状態要求の多量の集中が有る場合、認証状態を同期およびキャッシュし、他のＣＳＳが指定された発行元ＣＡとの間で元の１次ＣＳＳよりも重い活動を有している場合、問い合わせ責任を共有または譲渡する。

１つの発行元ＣＡに関連する使用者の１群を、ＣＳＳ知識ベース内のその発行元ＣＡ紹介を「非承認」と変更することにより除外することを、発行元ＣＡに対して廃棄を承認するように要求し、その要求の利点を再検討して何らかの処置が必要であるか判断し、何らかの理由でその発行元ＣＡを無効とするように決定されると、ＣＳＳ知識ベース内の発行元ＣＡの状態を「非承認」と変更することにより実行できる。「非承認」としてリストに載せられているＣＡで発行された認証の状態に対するこれ以降の要求は、結果としてＣＳＳが不合格状態を返却することになる。

以前に発行元ＣＡ紹介を「非承認」と設定して無効とされた使用者の１群を再有効化するための方法は、発行元ＣＡの再可能化許可の承認を要求し、その要求の利点を再検討して何らかの処置が必要であるか判断し、発行元ＣＡが再有効化されるべきと決定されると、ＣＳＳ知識ベース内の発行元ＣＡの状態を「承認」に変更することで実行できる。ＣＳＳは回復された発行元ＣＡに対する認証状態要求を、それを他の「承認された」ＣＡで有るかのように処理する。

状態報告構成要素との通信は、その様な情報を配置、要求そして検索するために使用される各々の認証状態プロトコルに対して、モジュラおよび再使用可能装置を作成し、個別の認証状態プロトコルを理解する全てのＣＡおよび応答機と互換性のある装置の版を使用し、そして使用状態にある各々の状態報告プロトコル用の装置の版を有することで確立できる。この装置は、今後の認証状態報告プロトコルに容易に適合可能なように設計されている。

提出者が第１ＴＣＵで、提出が１つまたは複数の電子オリジナルの管理を第２ＴＣＵに転送するトランザクションの実行は、そのトランザクションの所有者に第１ＴＣＵに対して、１つまたは複数の電子オリジナル文書を第２ＴＣＵへ転送するように指示を出させることを含む。そのトランザクションの所有者は第２ＴＣＵに対して１つまたは複数の電子オリジナル文書を転送するように指示し、所有者は第１ＴＣＵにどの電子オリジナルが第２ＴＣＵへ送られるべきかを指定する指示書を与える。第１ＴＣＵは第２ＴＣＵとの通信を確立し、その処置の目的を第２ＴＣＵに確認する。第１ＴＣＵまたは所有者は指示書を第２ＴＣＵに転送し、管理の転送が完了したことを判別できるようにしている。第１ＴＣＵは各々の確認された電子オリジナルを第２ＴＣＵに転送し、これはＣＳＳを用いて各々の転送された電子オリジナル上の第１ＴＣＵのデジタル署名が変更されていないかを保証している。第１ＴＣＵのデジタル署名のいずれかが無効である場合、第２ＴＣＵは第１ＴＣＵに通告して回復方法（例えば、第１ＴＣＵに対して現行認定認証を用いて辞退するように求める）を探す。第１ＴＣＵが同意できない場合、第２ＴＣＵはその事象を記録に残して、そのトランザクションの所有者に、要求された管理の転送が失敗したことを通告する；それ以外の場合は、第２ＴＣＵは各々の成功裏に転送された情報オブジェクトに対する新たな封体を、日時スタンプとその署名ブロックとを追加して作成する。第２ＴＣＵは第１ＴＣＵに転送が成功する毎に通告し、完了すると第１ＴＣＵは所有者の自己判断で、それらがオリジナルと解釈されない方法でコピーに印をを付けて保持するか、または転送された情報オブジェクトとして存在している全てのコピーを廃棄する。この処理は全ての指定された電子オリジナルが転送されるまで繰り返される。この様にして、第２ＴＣＵは信頼できるコピーである、転送された記録の管理者となる。第２ＴＣＵは信頼できる日時、デジタル署名、封体を添付し指示書を格納して、管理の末尾の独立した要素とする。

トランザクションの実行に際して、所有者の指令はまた所有権の転送も行われることを述べており、所有権文書の転送は第１または第２ＴＣＵのいずれかで行われる。責任のあるＴＣＵが所有権文書の転送の信頼性を、全てのデジタル署名、認証有効期限を検証し、ＣＳＳを使用して認証状態をチェックすることにより確認する。次にこのＴＣＵは信頼性のある日時を添付し、デジタル署名をし、指示書が追加されたこれらの新たな電子オリジナル情報オブジェクトを封体として格納する。これらの電子オリジナルが第１ＴＣＵの中に配置される場合、所有権の転送が管理の転送前に実行され、指示書を所有権の末尾の一部となるように開始する。

転送された、いくつかの記録は単純な電子情報オブジェクトであり、電子オリジナルそのものではない。ＣＳＳはシステムまたはＴＣＵと通信するために、何らかの適切な認証状態プロトコルを使用する。

本発明はその本質的特徴から逸脱することなく多くの異なる形式で実施できるであろう、従って上記の実施例は図示を目的としたものとであり、全ての部分において制約するものでは無いと了解されなければならない。この説明および添付の特許請求の範囲で使用されるように、「含む」および「含んでいる」という用語は、言及されている特徴が、他の複数の特徴が存在することを除外することなく存在していることを示していることを意味していることを強調しておく。本発明の意図された範囲は、これまでの説明よりはむしろ添付の特許請求の範囲で指定されており、請求の範囲内に落ちる全ての変化は此処に含まれるものと意図している。

図１はＣＳＳを採用しているＴＣＵ電子情報オブジェクト有効性確認プロセスを示す図である。 図２は、複数のＣＲＬと複数のＣＲＬとが認証状態ストアに加算されるバックグラウンドＣＳＳ処理を示す図である。 図３は、分析されたＣＲＬ、ＯＣＳＰ応答、および他の認証状態報告方法から導出された状態の個別キャッシングを示す図である。 図４は、デジタル署名が情報オブジェクト断片および添付データに適用されている、データ要素例を含む署名ブロック用の拡張性のあるシンタックスを示す図である。 図５は、ＴＣＵとＣＳＳおよび会員および外部ＣＡからインターネット経由での認証状態ＣＳＳ検索との相互作用を示す図である。 図６は、認証状態チェック・ステップで終了するＴＣＵ使用者登録処理を示す図であり、此処でデジタル署名有効性確認は成功裏に登録されている。 図７は、外部ＣＡが使用者認証を発行し、認証状態チェック・ステップで終了している場合の使用者登録処理を示す図であり、此処でデジタル署名有効性確認は成功裏に登録されている。 図８は、自動車賃貸契約事例を示す図であり、如何にしてＣＳＳが電子商取引の中で利用できるかを示している。

Claims (30)

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. 請求項１６記載の方法において、認証状態がＣＳＳに対してデルタ認証取り消し表（「ＣＲＬ」）で表示され；発行元ＣＡからＣＲＬが利用可能であると通知を受けると、ＣＳＳはそのＣＲＬを構造ストア内のリストに載せられている認証状態報告構成要素から検索し；そのＣＲＬが完全なＣＲＬの場合、ＣＳＳはその発行元ＣＡに関連するキャッシュ・メモリを消去してその認証状態をＣＲＬから判断し、その認証状態をキャッシュ・メモリの中に格納し；そのＣＲＬが全ＣＲＬの発行後に生じた変化のみを含む場合、ＣＳＳは認証状態をＣＲＬから判断し、その認証状態をキャッシュ・メモリの中に格納する、前記方法。

Images