JPH10508121A

JPH10508121A - ドキュメントをユニークに特定し認証する証明書を発行するデジタルドキュメント証明システム

Info

Publication number: JPH10508121A
Application number: JP8514727A
Authority: JP
Inventors: ハーバー、スチュワート、エイ; ストーネッタ、ダブリュ、スコット、ジュニア
Original assignee: シュアティテクノロジーズインコーポレイテッド
Priority date: 1994-10-28
Filing date: 1995-10-25
Publication date: 1998-08-04
Anticipated expiration: 2015-10-25
Also published as: KR980700752A; CA2203779A1; EP0819346A1; JP3554765B2; EP0819346A4; US5781629A; AU691366B2; CA2203779C; MX9703078A; AU4011895A; CN1174642A; CN1149783C; BR9509131A; NZ296340A; WO1996013921A1

Abstract

(57)【要約】デジタルドキュメントのタイムスタンプ処理（１０）が提供される。処理は、後にドキュメントの確証に用いることができるだけでなく、後にドキュメントをユニークに特定する名前（１８）又はニックネーム（１９）を含む証明（２０）を供給する。本発明に係る名前（１８）又はニックネーム（１９）は、単純で簡潔であるのみならず、それが示すドキュメントの自己認証に用いることができる。名前は、２組の当事者が、すばやく簡単に、同じ特定のドキュメントについて言及するのに用いられる。

Description

【発明の詳細な説明】ドキュメントをユニークに特定し認証する証明書を発行するデジタルドキュメント証明システム発明の背景本発明は、ドキュメントをユニークに特定し認証する証明書を発行するデジタルドキュメント証明システムに関するものである。より具体的には、本発明は、認証証明書によって、ユニークでユーザーフレンドリーな暗号化された安全な名前をデジタルデジタルドキュメントに与えるタイムスタンプシステムに関するものである。さまざまな状況において、当のドキュメントが作成後に改ざんされてないことを検証するために、ドキュメントが作成された日時を確証する必要が生じる。このような課題は、デジタルドキュメントにおいて、これらが極めて変更が容易であるために特に重要となる。デジタルドキュメントは、一般的に、過去の履歴を特定できない、変更容易なメディア上にデジタル形式で記録されているからである。しかし、一旦記録されると、デジタルドキュメントの完全なコピーが容易である。あまりに簡単で、ほとんどの場合、コンピュータベースのドキュメントの”オリジナルコピー”という言葉には意味がない。どのようなコピーも、メジャーな方法もしくはマイナーな方法で簡単に変更することができる。対照的に、無傷の紙のドキュメントは、より高い保証を与えてくれる。たとえば、どのようなものであれ紙のドキュメントに変更を行えば、それが小さな変更でも、物理的な法廷証拠(forensic evidence)を残すことになる。近年、いくつかのデジタルタイムスタンプシステムが提案されている。たとえば、本参照によってその内容を、ここに組入れる米国特許No.5,136,647と 5,136,646は、このようなシステムを記述している。5,136,646特許に記述されたシステムは、追加的にトランザクションナンバー、クライアントナンバー、日時、証明ナンバーを含む認証証明書を提供する。ドキュメントの真正さを確かめるために、タイムスタンプ「当局(authority)」の記録が、証明ナンバーとの関連で検査される。改良されたシステムが、”Inproving the Efficiency and Reliability of Digital Time-Stamping,”D．Byer，S．Haber，W．S．Stomtta(in Seaquences I I: Methods in Communication，Security，and Computer Science，ed．R．M．C apocelli，A．Desantis and U．Vaccaro，pp329-334，Spring-Verlag New York ，1993)に記載されている。二分木を利用したシステムを用いて、タイムスタンプされたドキュメントの真正さを確かめるために、この記事では、公開された木のルートに向かうパスに沿って（そのハッシュ値の”つながり(handedness)”に沿って、問題のドキュメントのハッシュ値と、直接結合されたハッシュ値の組を保持しておくことを提案している。もし、Ｎ個のドキュメントの全てについて「信頼できる」証明が成されたならば、この、システムは、”How to Time-stamp a Degital document,”S，haber，W．S．Stometta，Journal of cryptography， Vol．3，No．2，pp99-111（1991）に記載されているような、リニアリンキングに基づいたシステムにおいて、ＮからlogＮの検査のコストを低減することができる。前述したデジタルタイムスタンプシステムは、ユーザに、任意のデジタルドキュメントを”登録”する手段を与えるものである。”ドキュメント”は、もちろん、どのようなビットのどのようなシーケンスでもあり得る。たとえば、記述されたドキュメントの単語を表すものや、印刷されたテキストや、記録された音や、デジタル化されたビデオなどを表すものであり得る。ユーザがデジタルドキュメントとタイムスタンプ証明書を受け取ったとき、ユーザは、受け取った証明書が本当に受け取ったドキュメントから主張されている通りの時間に計算されたものかを確かめることができる。そうでない場合には、組（ドキュメントと証明書）は、検証もしくは認証テストを通らない。しかしながら、前述したシステムが意図通りの機能を果たしたとしても、更なる改良が必ず必要となる。たとえば、ユーザのデジタルドキュメントのニーズを簡易にするシステムは、常に、好ましい。具体的には、２組の当事者（party ）が、彼らが作成し、修正し、送信し、デジタル形式で記録した異なる複数のバージョンのドキュメントを用いて作業している状況を考える。この当事者（part y）は、記事を共同執筆している作家や科学者かもしれないし、会計記録を調べてるアナリシストや会計検査役かもしれないし、契約を交渉している弁護士かもしれないし、集中的にデジタルドキュメントを操作したり作成することを仕事に含む他の人かもしれない。このような当事者(party)は、記録をとったり、お互いに連絡をとるために、使っているドキュメントに言及する、便利な方法を必要としている。好ましくは、ドキュメントの名前は、短く、言及しやすいのが良い。また、名前は、少なくともそのドキュメントが利用される状況下においてあいまいなものであってはいけない。これには、名前とドキュメントの完全性に、何かしらの関連をつけることを必要とする。さらに、（１）異なるドキュメントや同じドキュメントの異なるパートとの関連や構造を反映する、（２）そのドキュメントについて便利だと思う、他の情報を含める方法で、制作者がドキュメントを名付けることができる、充分な柔軟性をもつことは、名前付けの体系上便利である。一般的に、名前付けの体系は、（１）何らかの任意の決め事に従って名前を選択する、（２）関数的に(functionally)ドキュメントに依存して名前を選択する。関数的な依存性は他方の当事者(party)で検証することのできるものである。任意な名前付け体系の例は、刊行物のInternational standard book numberin g(ISBN)方式である。”検証することのできる”（または、自己証明する）名前付け体系の例は、特定の一方向ハッシュ機能（後に詳述する）によって、そのハッシュ値を、各ドキュメントに割り当てるものである。任意の名前付け体系は、その体系がどのように確立され施行されるかによって変化する。通常のメカニズムは、特定のロケーション（物理的、または、論理的）で成される選択を含む。たとえば、パーソナルコンピュータ上でワードプロセッシングプログラムを使用して生成された新たなファイルの名前の、ユーザーの選択は、一般的に任意でありローカルである。パーソナルコンピュータ上のユーザの名前の選択は、彼もしくは彼女の都合によってなされる。ローカルでない中央的な名前付け体系に依存する、ISBNや国会図書館の分類方式も、同様に任意性がある。名前の選択が任意に過ぎない場合には、名前の、その名前の対象との関連は、本来的に検証できない。いいかえるならば、特定のドキュメントが、特定の名前のドキュメントと同じものであるか、人が検証する方法がない。デジタルドキュメントの名前が”検証することができる”ことを保証する方法の一つは、ビット列を定義した数学的関数の独立変数として用い、特定のドキュメントについて求めた関数値を、そのドキュメントの”名前”とすることである。利便性のために、関数は、計算が簡単なものであるべきである。名前をユニークなものにするために、関数は、また、１対１に計算されるものでなれればならない。さらに、ドキュメントの名前は、少なくともドキュメント自身の長さよりも短くなければならないという要請のために、関数は独立変数を圧縮するものでなければならない。そのため、通常、このような関数として、一方向ハッシュ関数が選ばれる。一方向ハッシュ関数は、計算が簡単で、任意長のビット列を入力し、固定長のビット列（”ハッシュ値”）を出力する。この関数は、次の条件を満たす。（１）同じハッシュ値出力を生成する二つの異なる入力を見つけることができない。（２）入力と、そのハッシュ値出力を与えられたときに、同じハッシュ値出力を伴う異なる入力を見つけることができない。これらの条件の結果、ハッシュ値からファイルのどのような情報も復元できない。このような計算処理の実行不可能性は、このような関数を攻撃する数学的（アルゴリズム的）知識と、現在のコンピュータで用いることのできる計算スピードとメモリとの、双方の現在の技術水準に依存している。技術水準が進めば、この関数の一方向の安全性を打ち破ることは可能である。現在では、一方向ハッシュ関数は、１２８ビット以上の出力とすることが推奨されている。これ以下では、この関数は一般的に安全ではない（どのように設計されたものであれ）。技術水準の進歩に伴い、安全なハッシュ関数に推奨される長さは増加する。一方向ハッシュ関数値によるドキュメントの名前付け体系は、本来的に”検証することができる”ものであるが、この体験に関連して、いくつかの不便な特徴もある。まず、第１に、人間のユーザにとって、思い出したり、他の人に簡単に伝えるには、名前の長さが長すぎることである。第２に、ドキュメントの作成者が、その名前の形式を制御できないことである。どのような一方向ハッシュ関数を用いた場合でも、ドキュメントのハッシュ値は、単純に、適正な長さの、ランダムに現れるビットの列である。このため、形式的もしくは内容的に関連するドキュメントの名前同士が関係を持たないという不便を作成者に与えるかもしれない。同様に、特定のドキュメントの名前は、基礎となった名付けられたドキュメントについての情報を何も与えない。第３に、技術の進歩に伴い、名前付け体系のためのどのような特定関数の選択も安全でなくなってきたために、長期間使用するドキュメントの名前は、安全のために、何度も変更する必要がある。以上のことより、改良されたデジタルスタンプシステムを実現することが望まれる。また、デジタルドキュメントを用いて作業する、改良された方法を実現することが望まれる。また、ドキュメントの名前に関連して情報を提供することができ、本来的に検証することができ、言及しやすく、短く、ユーザフレンドリーな名前を割り当てることができる、名前付けシステムを実現することが望まれる。発明の概要本発明は、改良したデジタルタイムスタンプシステムを提供することを目的とする。また、本発明は、デジタルドキュメントを用いて作業する改良された方法を提供することを目的とする。また、ドキュメントの名前に関連して情報を提供することができ、本来的に検証することができ、言及しやすく、短く、ユーザフレンドリーな名前を割り当てることができる、名前付けシステムを提供することを目的とする。本発明によれば、デジタルドキュメントのタイムスタンプを行う方法が提供される。この方法は、以下のステップを含む。(a) 第１のドキュメントの登録のリクエストを受け取り、(b) 他の複数のリクエストを受け取り、結合して、ハッシュし、複数のリクエストに応じた複数のハッシュ値の保管庫を形成し、 (c) 第１ドキュメントに対する、保管庫中のロケーションポインタを生成し、( d) ロケーションポインタによって前記第１のドキュメントを名付け、第１の名前を第１のドキュメントに与え、(c) 前記第１の名前を含む、前記第１のドキュメントの証明書を生成する。本発明によれば、後日、証明書をドキュメントの自己検証に用いることができるだけでなく、ユニークかつ便利よくタイムスタンプされたドキュメントに言及するのに、証明書中の名前を用いることができる。本方法によれば、タイムスタンプシステムを、同時に名前付けシステムとして、このような利便のためにサービス部やユーザに別のまたは並行するハードウエアを必要とすることなしに使用することができる。同時にデジタルドキュメントのタイムスタンプと名前付けを行う方法に加えて、本発明は、デジタルドキュメントの名前付け方法をも含む。この方法は、以下のステップを含む。 (a) 第１のドキュメントの登録のリクエストを受け取り、(b) 他の複数のリクエストを受け取り、結合して、ハッシュし、複数のリクエストに応じたハッシュ値の保管庫を形成し、(c) 第１ドキュメントに対する、保管庫中のロケーションポインタを生成し、(d) ロケーションポインタによって前記第１のドキュメントを名付け、第１のドキュメントに自己検証する名前を与える。本発明の、この態様によってデジタルドキュメントに与えられる名前は、本来的に検証可能であるのみならず、簡潔で使いやすい。さらに、この名前は、名付けたドキュメントと関連する情報を提供することができる。本発明の本態様の追加的な利点は、デジタルドキュメントのタイムスタンプに使う、新たな追加ハードウエアが必要ないことである。図面の簡単な説明前述した、また、その他の、本発明の目的と利点は、添付図面を参照した以下の詳細な説明を考慮して明らかとなる。各図面を通し、同様の参照番号は、同様部分を表している。図面において、図１は、発明に係るタイムスタンププロセスのフローダイアグラムである。図２Ａは、証明のための、アルファベットと数字で表現したデジタルドキュメントＦを示したものである。図２Ｂは、図２ＡのドキュメントＦの本発明に係る証明の、タイムスタンプリクエストを図示したダイアグラムである。図３は、二分木認証と名前保管庫の一部を図示したダイアグラムである。図４は、図３の名前保管庫に関連して、ユニークに図２ＡのドキュメントＦを名付ける認証証明書を図示したダイアグラムである。図５は、ドキュメントをユニークに名付ける、発明の他の処理のフローダイアグラムである。図６Ａ-６Ｃは、それぞれ、図５の処理に従った図２ＡのドキュメントＦの名前の第１、第２、第３の例を図示したダイアグラムである。図７は、リニアリンクリスト認証と名前保管庫を図示したダイアグラムである。発明の詳細な説明図１は、本発明に係るタイムスタンプ処理の第１の実施例のフローダイアグラムであり、以下で本発明の様々な特徴を図示した図２-４と関連して説明する。図１に示すように、本タイムスタンプ手順１は、デジタルドキュメントＦの証明書Rのリクエストをユーザが用意するステップ１１から始まる。このようなドキュメントFのアルファベットと数字表現５の例を図２Aに示す。デジタルドキュメントFは、デジタル形式でも、任意のアルファベットと数字のテキスト（図２Aに図示）や、ビデオや、オーディオや、絵画／写真を表現したものでも、その他の固定的データの形式でも良い。本処理は、任意長さのドキュメントに対して用いることができるが、図２Aの抜粋は、タイムスタンプを要求するドキュメントを充分に代表している。図２Bは、ドキュメントＦ(図２A)の証明書の提供を求める、本発明に従ったタイムスタンプリクエストR（図１のステップ１１でリクエスト発行者が用意する）のアルファベットと数字表現を図示したダイアグラムである。リクエストＲは、図２Aに示すドキュメントＦのハッシュ値２１(a5)と、リクエスト発行者のファイルネーム２２と、リクエスト発行者の識別番号２３を含む。便宜上、この例は、ハッシュ値２１(a5)は、MD5一方向ハッシュアルゴリズムの１２８ビットフォーマット（R.L.Rivestによって、”The MD5 Message-Digest Algolithm,”R equest fo comments（RFC）1321,Internet Activities Board，April，1992に記載されている）によって計算されたものとし、１６進表現で表している。もちろん、他の一方向ハッシュアルゴリズムも同様に用いることができる（たとえば、 Federal Information Processing Standard[FIPS]に示されているMDアルゴリズム、または、National Institute of Standards and Technology's Secure Hash Algolithm[SHA]を用いることができる）。ここで、この例で使用した、アルファベットと数字表現や、他の数字値の表現は、本発明の実施上、重要ではない。すなわち、他の表現も同様に用いることができる。図２Bに示したように、リクエスト発行者は、リクエスト発行者のファイルネームより、リクエストの対象となっている特定のファイルを識別することができる。これは、一般的にいって、ユーザのドキュメントのサービス部の証明書にとって重要ではないので、リクエストRのオプションとなっている。リクエスト発行者の識別番号２３より、サービス部は、ドキュメントの証明書をリクエストした特定のリクエスト発行者を識別することができる。図１に戻り、ステップ１１で、デジタルドキュメントF（図２A）の証明書のリクエストＲをユーザーが準備したら、ステップ１２において、リクエスト２０（図２B）をサービス部に送る。ステップ１３では、サービス部が、リクエストを結合する。こうすることによって、サービス部は、ドキュメントＦのハッシュ値a5(図２B)をＲから取り出し、この値を、証明書の２番目のリクエストが対象とする２番目のドキュメントのハッシュ値a6と結合（たとえば連結）する。ステップ１４では、サービス部は、組み合わせたものを一方向ハッシュ関数でハッシュし、ハッシュ値a5とa6にリンクした新たなハッシュ値を生成する。この様相は、本発明の原理に従った認証と名前付けの保管庫（たとえば、二分木）の部分を示した図３と、ドキュメントＦが図２Aのテキストで構成されている場合の図３の保管庫に対するMD5のハッシュ値の例を図示したテーブル（クレームの前に添付している）に示した。図３に示したように、デジタルドキュメントFは、ハッシュ値a5を含む、証明書のリクエストＲの対象である。後掲のテーブル（サブツリーA）に示したように、a5（図２AのドキュメントＦに対する）は、値”b76729 0cff8c87194cf306108a9794a”を持っている。（例示のために、テーブル中のハッシュ値a1-a4，a6-a8，b1-b8，d1，d3-d6，d8に任意の値を割り当てた。）図１のステップ１３と１４では、ハッシュ値a5は、ハッシュ値a6と結合（たとえば連結（concatenated）され、組み合わせたものは、図３のA5-6で示される新たなハッシュ値を生成するために、ハッシュされる。（ここで、下付きの”5- 6”は、そのハッシュ値が、サブツリーAの５番目と６番目の葉から、導かれた結果として生じたものであることを表している。）言い換えるならば、第１のビット列a5は、第２のビット列a6と結合され、その結果が、新たなビット列A5-6を形成するようハッシュされる。（たとえば、図３とテーブルに関連して、a5とa6を連結すると、"b767290cff8c87194cf306108a9794a15812318c8ec1d2cf94a79cb8952 f3c2"となり、そのハッシュ値は、"9dad90bbef28047744a26865acbbf24ee"となる）図１のステップ１５では、サービス部が、他の証明書のリクエストを受け取り、組み合わせ、ハッシュし、結果として得られたハッシュ値（図３に図示）の保管庫（図３に図示した木）を形成する処理を継続する。具体的には、図３に示したように、ハッシュ値a7とa８が結合され、ハッシュされ、結果としてのハッシュ値A7-8を形成する。この後、ハッシュ値A5-6とA7-8は結合され、ハッシュされ、結果としてのハッシュ値A5-8を形成する。同様に、ハッシュ値a1，a2，a3，a4 も、適切に結合され、一緒にハッシュされ、A1-2，A3-4を形成し、相互に結合されてハッシュされ、A1-4を形成する。ここで、サブツリーＡは、A1-4とA5-8を組み合わせ、組み合わせたものをハッシュし、ハッシュ値A1-8を形成することにより、”閉鎖される”。（ここで、下付きの”１-８”は、そのハッシュ値が、サブツリーAの１番目から８番目の葉から、導かれた結果として生じたものであることを表している。）言い換えるならば、ハッシュ値a1からa8で表されるドキュメントはサブツリーＡ中で相互にリンクされ、これらのハッシュ値の保管庫を形成する。この保管庫の要素は相互に、ハッシュ値Ai-jによって順番にリンクされている。図３において、サービス部は、さらに、ドキュメントハッシュ値ｂ1、ｂ2、ｂ3、ｂ4、ｂ5、ｂ6、ｂ7、ｂ8を含むリクエストを受信しつづけ、ルートB1-8をもつサブツリーBを形成する。サービス部は、さらに、ドキュメントハッシュ値ｄ1、ｄ3、ｄ4、ｄ5、ｄ6、ｄ8を含むリクエストを受信しつづけ、これらをハッシュ値ｄ2、ｄ7（それぞれ、ルートA1-8とルートB1-8から抽出する）と組み合わせ、ハッシュ値D1-2，D3-4，D5-6，D7-8と、その次のD1-4，D5-8から構成される、最終的な木Ｄを形成する。D1-4，D5-8は、相互に結合され、組み合わせたものはハッシュされ、D1-8となり、木Ｄのルートを形成する。図１に戻り、処理のステップ１６は、保証する項目の決定を含む。（たとえば、図３のサブツリーA，B，D，は閉鎖されており、ルートD1-8が保証する項目となる。後述するように、その後、認証が行われる前、保証された項目は、（１）保証する項目を直接公開する（すなわち、広く知られ、広く利用できるようにする）、（２）保証する項目を、他の、直接公開されたハッシュ値にリンクすることにより保証される。ステップ１７では、証明書のリクエストRについて、サービス部は、保証された項目D1-8について、”自己検証”ハッシュ値を計算する。”自己検証”ハッシュ値は、保証されたドキュメントＦの認証に必要なハッシュ値として定義され、a6，A7-8，a1-4，d1，D3-4，D5-8となる。ステップ１７は、また、自己検証ハッシュ値a6，A7-8，a1-4，d1，D3-4，D5-8に対してロケーション値（図３のつながり（handedness）値）を計算する。これは、それぞれ、R ，R，L，L，R，Rとなる。（ここで、Lは左、Rは右を示している。）このハッシュ値のリストと関連するロケーション値（たとえば、後に述べる認証証明書から得ることができる）を用いて、後日、当事者(party)は、保証された項目D1-8が計算されたときにサービス部によって受け取られ、登録されたもの（すなわち、ＦがF'と同じものである）としての、ドキュメントＦ’の真正さを調べたいとき（すなわち、ＦがF'と同じものである）、次のステップが実行される。はじめに、ドキュメントFのハッシュの右に自己検証ハッシュ値a6が結合され、結合されたものがハッシュされ、A'5-6を形成する。第２にハッシュ値A'5 -6の右に自己検証ハッシュ値A7-8が結合され、結合されたものがハッシュされA' 5-8を形成する。第３に、A'5-8の左に自己検証ハッシュ値A1-4が結合され、結合されたものがハッシュされA'1-8を形成する。第４に、ハッシュ値A'1-8の左に自己検証ハッシュ値ｄ1が結合され、結合されたものがハッシュされD'1-2を形成する。第５に、ハッシュ値D'1-2の右に自己検証ハッシュ値D3-4が結合され、結合されたものがハッシュされD'1-4を形成する。第６に、ハッシュ値D'1-4の右に自己検証ハッシュ値D5-8と結合され、結合されたものがハッシュされD'1-8を形成する。これによって、このドキュメントF'が真正であれば、公開物や保証された記録（たとえば、確認用記録を記憶した多様なサイトのだれかから）得た通りの値D1-8を、D'1-8は正確にとる（すなわち、D'1-8=D1-8）。その他の場合、変更されたドキュメントは、異なる値にハッシュされる。本発明に係るタイムスタンプシステムの他の特徴は、確認用に急いで公開する必要のない、ドキュメントのすばやい登録を簡単にする点である。言い換えるならば、証明書は、証明書が生成されリクエスト発行者に送られる時点で、公開が行われていなくても、証明書を与えることができる。必要となるのは、ユーザが組（ドキュメント証明書）を望む前に、何らかの種類の公開が行われることだけである。たとえば、図２において、やがてそれが保証されるかぎり（すなち、直接公開されるか、ハッシュ値に安全にリンクされるか）、ハッシュ値a1からa8 のハッシュ値で表されるドキュメントの登録時に、ハッシュ値D1-8は”公開”されている必要がない。他のタイムスタンプ方法とは対照的なことに、本発明の、この特徴は、登録のリクエストに対するすばやいレスポンスタイムを、これに対応するすばやい公開時を要求することなしに実現する。登録リクエスト処理を、公開プロセスと分離することにより、タイムスタンプシステムは、大量の登録リクエストに、サービス部の保管庫マネージャーに費用のかかる頻繁な公開の負担をかけることなく、よりよく対応することができる。図１に戻り、処理はステップ１８に進み、ここでは、サービス部が、ロケーション値（たとえば、つながり(handedness)）と保証する項目の識別子（たとえば、ルート）D1-8を結合し、組み合わせたもの”RRLLRR{D1-8識別子}”を形成する。本発明の特徴によれば、この組み合わせ（連結）は、短くて圧縮されているばかりでなくユニークで自己認証する、ドキュメントFの”名前”として用いることができる。たとえば、”RRLLRR{D1-8識別子}”という名前をもつドキュメントは世界に一つしかない。この名前は、一般的に１２８ビットかそれ以上である典型的な有用ハッシュ値に比べ、とても短い。さらに、それが示す特定のドキュメントの検証に用いることのできる、本質的にそれが示すハッシュ値と関連した名前の使用は、確実なものである。本発明によれば、処理はオプションのステップ１９に進み、ステップ１８で生成されたユニークな名前を、短い”ニックネーム”の形式に略する。たとえば、名前”RRLLRR[D1-8識別子]”は、まず、２進数表現に変換し（たとえば、”00 1100[２進数表現のD1-8識別子]”そして、アルファベットと数字表現に変換することにより、アルファベットと数字の形式で表現することができる。この本発明の”ニックネーム”の特徴は、具体的には、人々に、たとえば、電話で、そのドキュメントを参照するときに、タイムスタンプされたドキュメントの名前を手早く書き留めることを可能とする。たとえば、１２８ビットかそれ以上のハッシュ値をもつドキュメントFには、米国内の長距離の電話番号の長さもしくは１０文字以下の、本発明に従った”ニックネーム”を持たせることができる。図１において、処理はステップ２０に進み、当該ステップにおいて、サービス部は、ドキュメントFの自己検証ハッシュ値と、そのハッシュ値のロケーション（たとえば、つながり(handedness)）値、とユニークな名前もしくはニックネームを含む、ドキュメントＦの認証証明書を生成する。後掲するテーブルの値をとるサブツリーA,B,Cよりなる、図３の保管庫に対応する、図２Aのドキュメント Fの認証証明書３０を、図４に図示する。証明書３０は、(i)つながり(handednes s)値を伴う自己検証ハッシュ値３１、(ii)ルートD1-8へのポインタ（たとえば、図４のポインタ３２--2e5347f5は--は、アルファベットと数字表現で、ルートD1 -8のユニークな識別子を図示したものであり、後述するように、D1-8が生成された時間を表している）、(iii)ドキュメントFのユニークな名前３３、(iv)ドキュメントFのユニークなニックネームの、４種類の情報を含んでいる。必要であれば、証明書３０に、図２Bのリクエスト１０の情報を含めることもできる。また、名前２２は、見やすいように、左にずらしてもよい。図１の処理１０は、ステップ２１に進み、証明書３０が、サービス部からユーザに送り返される。このように、図１-４は、ドキュメントFにタイムスタンプし、認証証明書を提供し、後日疑わしいドキュメントF’に真正さの検証に使用できるのみならず、すばやく簡単な方法でドキュメントＦをユニークに言及することができる、本発明の実施例を図示している。この本発明のタイムスタンプシステムの、追加的な”名前付け”の特徴は、ユーザやサービス部に、追加的なまたはパラレルなハードウエアを必要とせずに、特別な”名前付け”の利便性をユーザに提供する。本発明の他の態様によれば、本発明の処理は、証明書にドキュメントの自己検証ハッシュ値を含まない、ドキュメントにユニークで自己検証できる”名前” を与えるのに用いることができる。このような本発明の特徴を、本発明に係る処理の他の実施例のフローダイアグラムである図５に示す。処理４０は、まず、ステップ４１で、ユーザが、デジタルドキュメントFの名前のリクエストRNを用意する。たとえば、リクエストRNは、図２BのタイムスタンプリクエストRに表した情報を含むことができる。処理４０の引き続くステップ４２では、リクエスト発行者が、リクエストをサービス部に送る。ステップ４３では、サービス部は、リクエストを結合（たとえば、連結）する。このようにして、サービス部は、前記図１と同様に、対象のドキュメントのハッシュ値を取り出し、この値を、第２の名前のリクエストの対象である第２のドキュメントのハッシュ値と結合（たとえば、連結）する。ここで、第２のリクエストは、サービス部システムによるタイムスタンプ証明書の提供を求めるリクエストであってもよい。サービス部の立場からみて、リクエストの種類は、一般的に重要ではない。ステップ４４において、サービス部は、他の名前（または証明書）のリクエストを受け取り、組み合わせ、ハッシュし、結果として得られたリンクされたハッシュ値（図３に図示）の保管庫（図３に図示した木）を形成する処理を継続する。ステップ４６では、サービス部は、保証する項目（たとえば、ルートD1-8）を特定する。先に図１において説明したように、後日、認証の前、この項目は、（１）保証する項目を直接公開する（すなわち、広く知られ、広く利用できるようにする）、（２）保証する項目を、他の、直接公開されたハッシュ値にリンクすることにより保証される。ステップ４７において、名前のリクエストＲＮについて、サービス部は、対象となったドキュメントに対する”自己検証”ハッシュ値と、” 自己検証”ハッシュ値のロケーション値（たとえば、つながり(handedness)）を、図１のステップ１７と同様に計算する。ステップ４８において、サービス部は、図１と同様に、ロケーション値とルートD1-8の識別子を結合し、組み合わせたものを形成する。追加的なステップ４９では、図１と同様に、ステップ４８で生成したユニークな名前を、さらに、短い”ニックネーム”の形式に略する。次のステップ５０では、サービス部は、”名前”をリクエスト発行者に送り返す。図６A-6Cは、本発明の図５の処理４０に従った名前の第１、第２、第３の例を、それぞれ図示したものである。図６Aに示すように、名前５５は、ロケーション値（たとえば、ハンデッドナス）とルート識別子（たとえば、公開された時間”8/18/94 7:37:25 AN EDT”によって特定したルート）の組み合わせ（たとえば、連結）よりなる。図６Bにおいて、図６Aの名前５５は、同じ時間を用いたニ進数表現で表されている（たとえば、UNIXスタンダードの時間：グリニッジ標準時間における、１９７０の最初の秒からの秒数）。図６Cでは、図６Bの名前５６を、アルファベットと数字形式で表すことにより、さらに簡略化している。図６A-図６Cでは、”時間”をルートの識別子として用いているが、もちろん、他のユニークな識別子も同様に用いることもできる。たとえば、シーケンシャルな、ルートの公開番号、すなわち所定の公開からの公開されたルート数も、同様に用いることができる。このような、シーケンシャルなルートの公開番号も、ルートが公開された時間と同じように、ルートを特定する。特定のドキュメントFの名前Nが計算された後、後日、当事者(party)が、提示されたドキュメントF’と名前Nとの関係を確かめたい場合には、当事者は、認証証明書Cのコピーを入手し（蓄積機能やその他の手段より）、次のような手順を行う必要がある。第１に当事者(party)は、Cに含まれる情報と、Nが正確に一致していることを検証する。次に、当事者(party)は、図１で説明した確証の手順を実行する。このように、図５の処理によれば、本来的に検証可能なばかりでなく、短く、簡単で、すばやく、書いたり、言ったりすることのできる名前やニックネームが提供される。たとえば、図６Cに示したように、図５の処理は、１２８ビット以上の典型的なハッシュ値をもつドキュメントに対しても、４０ビット（すなわち、１６進数表現で１０デジット以下）以下の名前を与えることができる。(しかし、１６進数表現よりも、もっと、ビット列を圧縮する、アルファベットと数字の符号化もある。たとえば、UUCP印刷可能キャラクター符号化は、アルファベットと数字の一文字あたり、４ビット以上の６ビットを使用する。このような符号化によれば、図６Cの名前は、７文字で表すことができる。これは、米国のローカルな電話番号の長さである。）さらに、ドキュメントの”名前”はユニークである。言い換えるならば、図５の処理を用いるシステムで名付けられた他のどのドキュメントも、同じ名前を持つことはない。これは、本発明の方法によって、本質的に保証される。さらに、名前を与えるハードウェアは、デジタルドキュメントのタイムスタンプにも用いることができる。ハッシュ値を保証し結びつける保管庫として”二分”木を図示した図３を用いて発明を説明したが、本発明を実施する方法は他にもいろいろある。たとえば、本発明の”保管庫”は、二分木に代えて、３分、４分、k分木や、これらの組み合わせを用いてもよい。もちろん、図３には、各々８つの葉をもつ３つのサブツリーA，B，C，を図示したが、他の木やサブツリーやのアレンジや組み合わせも同様に用いることができる。必要なことは、保管庫中の項目が、公開によって保管庫を保証するハッシュ関数を介してリンクされていることだけである。数学的には、ときとして保管庫の中の項目がグラフ中の全ての項目が一つの項目に直接パスによってリンクし得るgrowing directed acyclic graphを、保管庫中の項目が形成することを満たす。したがって、リニアリンクリストや、その他の種類のハッシュ関数の蓄積も、同様に用いることができる。たとえば、”How to Time-stamp a Degital docu ment,”S，Haber，W．S．Stometta，Journal of Cryptography，Vol．3，No．2 ，pp99-111(1991)に記載されたリニアリンクリストを、代わりに用いることができる。本発明の名前付け処理の実施に用いるリニアリンクリストの一部のダイアグラムである図７を示す。図７に示すように、名前のリクエストR1,R2,R3は、それぞれ、デジタルドキュメントF1,F2,F3に関係する。リクエストR1,R2,R3は、図２Bを用いて示したものと同様であってよい。これらのリクエストは、サービス部に送られ、サービス部は、ドキュメントF1のドキュメントハッシュ値a1を取りだし、既に存在しているハッシュ値A0と結合し、組み合わせたものをハッシュし、新たなリンクハッシュ値A0-1を作る。この、新たなリンクハッシュ値A0-1は、ドキュメントF2のハッシュ値a2と結合され、組み合わせたものをハッシュし、新たなリンクハッシュ値A1-2を作る。同様に、新たなリンクハッシュ値A1-2は、ドキュメントF3のハッシュ値a3と結合され、組み合わせたものをハッシュし、新たなリンクハッシュ値A3-4を作る。この処理を希望する限り、対応するデジタルドキュメントの無傷さを守るリンクハッシュ値の保管庫または蓄積を形成するように続ける。リクエスト発行者が図1-6と同様なユニークな”名前”を含む証明を用いることができるように、サービス部は、定期的に、保管庫の一部（たとえば、図７ではリンクハッシュ値 A4-5）を公開することにより、保管庫を保証する。”名前”は、”公開された” リンクハッシュ値への第１のポインタ（たとえば、リンクハッシュ値A4-5へのポインタ）を表すものと、保管庫中で名付けられるべき特定のドキュメントから” 公開された”リンクハッシュ値への第２のポインタを表すものとの組み合わせから導く。図７のリニアリンクリストの場合、この第２のポインタは、単純に、名付けられるべきドキュメントのリンクハッシュ値と”公開された”リンクハッシュ値との間のリンクハッシュ値の数を数えたものとなる。たとえば、図７のドキュメントF1，F2，F3に対する、この数は、それぞれ、４、３、２となる。この結果、ドキュメントF1，F2，F3の”名前”は、この例では、”4[リンクハッシュ値 A4-5へのロケーションポインタ」”、”3[リンクハッシュ値A4-5へのロケーションポインタ」”、”2[リンクハッシュ値A4-5へのロケーションポインタ」”となる。本発明によれば、この名前は、短く、簡潔で、ユニークであるだけでなく、自己検証ができるものである。本発明によれば、他のリンクハッシュ値の方法も、また、用いることができる。たとえば、頻繁に計算（毎秒または毎分）される木のルートを、そのルートがリニアリンクリストと結合した日毎の木に結合することができる。要約すると、本発明に含まれる方法は、デジタルドキュメントの名前づけに関連して挙げた様々な制約を避けながら、そのハッシュ値によって単独で名付けるドキュメントが検証可能な安全性をもつように、ドキュメントを名付ける。本発明のこの特徴の本質は、多くのドキュメントに依存するハッシュ値の保管庫を保持し、各ドキュメントに、名前が”リンクされた”保管庫中のロケーションの簡潔な表示によって名前を与えることである。本発明の好適な実施例において、ビット列は、一方向ハッシュ関数を用いて ”リンク”される。ハッシュ値の組または並べられたリストに対して、組織的に呼び出されるハッシュ関数によって、新しいハッシュ値が、古いものより、リンクリスト、二分木、または、他の組み合わせの構造を形成するように計算される。このようにして、ドキュメントは保管庫にリンクされ、保管庫中の各要素は相互にリンクされる。保管庫は、その一部を、様々な手段のいづれかにより広く知られ利用されるようにすることにより保証される。保管庫の残りの部分--登録されたドキュメント--は、このような部分と広く利用可能な部分にリンクすることにより保証される。ハッシュ値の成長パターン（すなわち、directed acyclic graph）で形成された組み合わせの構造の正確な形式にかかわらず、ハッシュ値のリストと、これに伴う（とても簡潔な）構造的な”進行方向(driving direction)”またはロケーション情報は、要約され広く利用可能とされたハッシュ値と共に特定のデジタルドキュメントに保管庫中でリンクするために用いられる。このハッシュ値のリストとロケーション情報は、ドキュメントの認証証明書に加えることができる。登録されたドキュメントの正確なコピーだけが、この証明書と保管庫中のロケーションにリンクすることができる。これは、一方向ハッシュ関数の特性と、保管庫の記録の広く知られ広く利用可能な性質によるものである。したがって、このような認証証明書をもつドキュメントには、信頼できるロケーション情報を簡潔に符号化したものが、名前として与えられる。これ以外の組（ドキュメント、証明書）は、”この名前をもつ”ようには計算されない。本発明によれば、名前付け方法は、異なる方法で実現できる。異なる組み合わせの構造は、異なるレベルの公知化によって、異なる方法で結合できる。たとえば、保管庫の公知化した組織への直接のリンクでもよい。具体的には、保管庫マネージャーによって保持されている全ての記録を公開し、ロケーション情報を直接のポインタと同じように簡単にすることもできる。または、保管庫の記録の公知の部分にリンクするために、そのルートが通常的に保管庫マネージャーに送られる、ユーザが作った彼もしくは彼女自身の木（または、他の構造）による、ローカルな木でもよい。本発明の、ある態様においては、この名前付け方法によって、ユーザは、彼または彼女のドキュメントの名前を選択、制御する個人的手段を得る。たとえば、ローカル木の態様を考えると、特定のドキュメントのローカル情報は、ローカル木中の位置の後ろにサービス部の木中の位置を記述したものとすることができる。ユーザは、適当なローカル木（または、他の構造）の引き続く葉ノードに、各引き続く部分を置くことにより、複数部分のドキュメントに名前をつけることができる。たとえば、図３の、８個のハッシュ値a1からa8は、本の８章を表すものとすることができる。これにより、このようなドキュメントの引き続く部分は、ローカル木（または構造）中で引き続くローカル位置を持つことができる。その後、ローカル保管庫のマネージャーが、このようなローカル木のルートをサービス部の保管庫のマネージャーに送った場合には、結果的に、このようなドキュメントの引き続く部分に、ローカル情報の適当な符号化によって引き続く名前が、登録情報として与えられる。適当な符号化の例としては、単純な葉の番号付けによるものがある。さらに、これらの名前のローカルでない部分は等しく、これらが同じドキュメントの部分である事実をはっきりと符号化している。たとえば、図３と後掲するテーブルを参照すると、ハッシュ値a1からa8は複数部分のドキュメントの引き続く部分を表しており、”3e5347f5”はルートD1-8の識別子であり、ハッシュ値a1からa8によって表される、ドキュメントの名前は、次のようになる。 a1:”1-LRR-2e5347f5”;a2:”2-LRR-2e5347f5”;a3:”3-LRR-2e5347f5”;a4:”4 -LRR-2e5347f5”;a5:”5-LRR-2e5347f5”;a6:”6-LRR-2e5347f5”;a7:”7-LRR-2 e5347f5”;a8:”8-LRR-2e5347f5” ドキュメントの部分を構造化する、もっと複雑な方法は、本発明の名前付け方法によって割り当てた自己証明する名前に符号化することである。たとえば、図３のd1からd8は本の８個の章の個々を表し、d2とd7で表される章は各々、ハッシュ値a1からa8とb1からb8で表される８個のセクションを持っている。このような状況に従い、図３のハッシュ値ai,bj,dkで表される、ドキュメントのさまざまな部分の”名前”は、たとえば、もし、ハッシュ値D1-8が、返答として、サービス部の保管庫マネージャーに送られ、ローカル名保管庫マネージャーがその名前Ｎを受け取るとして、次のようにすることができる。a1:”1-2-N”;a2:”2-2-N ”;a3:”3-2-N”;a4:”4-2-N”;a5:”5-2-N”;a6:”6-2-N”;a7:”7-2-N”;a8: ”8-2-N”;b1:”1-7-N”;b2:”2-7-N”;b3:”3-7-N”;b4:”4-7-N”;b5:”5-7-N ”;b6:”6-7-N”;b7:”7-7-N”;b8:”8-7-N”;d1:”1-N”;d2:”2-N”;d3:”3-N ”;d4:”4-N”;d5:”5-N”;d6:”6-N”;d7:”7-N”;d8:”8-N” 他の態様において、長いもしくは複雑な複数部分のドキュメントの内容のテーブルを、リクエストの、ある標準の位置に含めることもできる。たとえば、図３において、d1（１章）からd7（７章）で表される本の７個の章を持ち、d2とd7 で表される章は各々、ハッシュ値a1（セクション１）からa8（セクション８）と b1からb8で表される８個のセクションを持っている本の内容のテーブルのドキュメントを、d8が表すものとすることができる。本発明のこの態様の特徴は、複数部分のドキュメントのうちの一つの自己検証できるドキュメントはドキュメントの全ての部分についての記述を含め、この一つのドキュメントを、ある特定のトピックに関係するドキュメントの各部分をリストするのに利用できるようにしていることである。後に、認証するドキュメントと、その証明書を調べるのと共に、このように認証されたリストを、（１）各ドキュメントが、内容のテーブルと共に登録された各ドキュメントの正確なコピーであるか、（２）このリスト中の、どのドキュメントも失っていないか、を調べるのに利用することができる。ドキュメントの組織的構成を符号化するのに名前を使う、この方法は、本発明の自己確認できる名前が、デジタルドキュメントのユーザーや人間の読者に有用であるいくつかの異なる方法のうちの一つでしかない。たとえば、ドキュメントがリンクしている保管庫中のロケーションを符号化する、利便性ある一つの方法は、時間と日--簡単に理解できる何か--によることである。例として、図６を参照されたい。ユーザにとって、もっと有用で便利な、システムの名前を作成する他の方法は、次のように”個人化した”名前のリクエストをユーザに許可することである。サービス部の保管庫の記録が毎日、ある標準的な方法でフォーマットされる（たとえば、二分木を、毎分一度閉鎖することによって）とし、F()が、ASCII符号化列から、保管庫記録の位置への標準的な変換（マッピング）を表すとする。一個人化した名前付けのリクエストは、ASCII符号化された文字列、たとえば、”A BC Corp.”または”Jhone Smith's Ph.D.Dissertation”を伴う。毎日、個人化した名前のリクエストは、保管庫マネージャーによって、与えられたASCII符号列をF()で評価した名前のロケーションに、たとえば、F(”ABC Corp.”)またはF (”Jhone Smith's Ph.D.Dissertation”)で示される分に根付いた木にリクエストをリンクすることにより、リンクされる。この方法において、リクエスト発行者の、文字列---ドキュメントについて便利だと思う、どのような情報でもよい- --の個人化的な選択は、名付けられたドキュメントの、自己確認できる名前の一部となるようになされる。もちろん、たとえば毎分ではなく毎時間といった他の時間スケールにおいても同様のテクニックを適用することができる。さらに、共に係属している米国特許出願シリアル番号No.07/992,883 １９９２年１２月２１日出願に記載され、参照によってすべてに組入れられる（”In proving the Efficiency and Reliability of Digital Time-Stamping,”D．Bye r，S．Haber，W．S．Stomtta（in Sequences II: Methods in Communication，S ecurity，and Computer Science，ed．R．M．Capocelli，A．DeSantis and U． Vaccaro，pp329-334，Springer-Verlag,New York，1993）とともに）は、真正さの暗号的証明書を更新するための方法は、本発明の名前付け方法による証明書に直接適用される。これにより、テクノロジーの進歩に伴い証明書が適正に更新される限り、本発明で与えた自己確認できる名前は、変更することなく、長期間、効力をもつ。要約的にいって、本発明の性質は、与えられる名前が（名前付け処理が、あらかじめローカルな操作によってなされていても）例外なく自己確認できるので、従来の名前付け方法を改良しているといえる。また、本発明の性質は、本方法によって割り当てる名前は、短く、意味があり、柔軟性があり、更新でき（これによって、長期間守られ）、ドキュメントに関連してリクエスト発行者が選択した情報を提供するので、現在のドキュメント固有の名前付け方法を改良している。さらに、この名前付けシステムは、大量の名前付けリクエストを扱うする規模にすることができる。当業者は、本発明より、限定するためでなく例示するために示した前記実施例以外の実施態様をとることができる。また、本発明は、以下のクレームに限定されるものでもない。

【手続補正書】特許法第１８４条の８第１項【提出日】１９９６年１１月８日【補正内容】請求の範囲１、認証のために第１のデジタルドキュメントを登録する方法であって、以下のステップを含む、 a．第１のドキュメントの登録の第１のリクエストを、著者からサービス部に送り、前記第１のリクエストは第１のドキュメントの表示を含み、 b．サービス部において、前記第１のドキュメントの登録の第１のリクエストを受け取り、 c．サービス部において、複数のデジタルドキュメント各々の表示を含む、複数の他のデジタルドキュメントの登録の複数の他のリクエストを受け取り、 d．サービス部は、前記第１のリクエストと、前記複数の他のリクエストのうちの少なくとも一つを結合して、第１の値を形成し、 e．サービス部は、前記第１の値をハッシュし、 f．サービス部は、前記第１の値を含む複数のハッシュ値の保管庫を形成し、前記保管庫は、前記第２のリクエストと複数の他のリクエストに応じたものであり、 g．サービス部は、第１のドキュメントの、保管庫中のロケーションポインタを生成し、 h．サービス部は、前記ロケーションポインタを用いて前記第１のドキュメントを名付け、第１の名前を第１のドキュメントに与え、 i．サービス部は、前記第１の名前を含む、前記第１のドキュメントの証明書を生成する。２、クレイム１の方法であって、前記結合は連結である。３、クレーム１の方法であって、さらに、保管庫の一つの項目を公開することにより、保管庫を保証するステップを含む。４、クレーム２の方法であって、前記ステップ(g)は、第１のドキュメントの自己検証ハッシュ値と、自己検証ハッシュ値の、関連するロケーション値の一覧を定めることを含む。５、クレーム４の方法であって、前記ステップ(h)は、前記公開した項目と前記ロケーション値によって前記第１のドキュメントを名付け、前記第１のドキュメントに名前を与えることを含む。６、クレーム５の方法であって、前記証明書は、自己検証ハッシュ値の一覧を含む。７、クレーム６の方法であって、前記保管庫は、木であって、前記公開された項目は木のルートである。８、クレーム３の方法であって、前記公開された項目の識別子は、その項目が算出された日時のユーザーフレンドリーな表示を含む。９、クレーム７記載の方法であって、前記第１のドキュメントを名付けるステップは、前記関連するロケーション値と前記公開された項目の識別子の組み合わせに対して、圧縮符号アルゴリズムを適用し、前記第１のドキュメントに、簡単化したアルファベットおよび／または数字の名前を与えることを含む。１０、クレーム１の方法であって、前記ステップ(i)は、前記保管庫の項目の公開が行われるよりも、実質上、先だって行われ、本方法によって、登録のリクエストに対するすばやい応答を、対応するすばやい公開時を必要とすることなしに行う。１１、クレーム１の方法であって、ステップ(a)から(e)は、サービス部外で行われる。１２、クレーム１の方法であって、ローカル体も、前記ステップ(b)から(c) を実行し、保証されるべきローカル項目をもつローカル保管庫を形成し、その後に、ローカル体が、前記ローカル項目を含む第１のリクエストを、前記ステップ (b)から(i)を実行する外部のサービス部におくる。１３、クレーム１２の方法であって、外部のサービス部が実行するステップ (c)、(d)、(e)は、前記ローカル項目と他のハッシュ値を結合することを含む。１４、クレーム１２の方法であって、ローカル保管庫の一つの項目は、複数の関連するドキュメントの内容のテーブルの、ハッシュ値である。１５、クレーム１２の方法であって、ローカル保管庫の複数の項目は、複数部分のドキュメントに対応している。１６、クレーム１の方法であって、前記前記名前の第１の部分は、リクエスト発行者によって選択され、ドキュメントを証明する。１７、クレーム１６の方法であって、前記名前の第１の部分は、リクエスト発行者によって選択され、第１のドキュメントと情報を関連させる。１８、クレーム１６の方法であって、前記名前の第１の部分は、第１のドキュメントを証明する、リクエスト発行者についての情報を提供する。１９、クレーム１の方法であって、前記保管庫は、二分木である。２０、クレーム１の方法であって、前記保管庫は、リンクリストである。２１、クレーム１の方法であって、前記保管庫は、有向成長非循環グラフ(g rowing directed acyclic graph)である。２２、クレーム１の方法であって、頻繁に算出される木のルートが、比較的頻繁には算出されない、そのルートがリニアリンクリストに順番に結合される木に組み込まれる。２３、クレーム１の方法であって、証明書は、名前の寿命を延長するために、技術の進歩に従い、更新される。２４、クレーム１の方法であって、証明書は、記録設備に送られ、第１のリクエストの生成者に送られる。２５、デジタルドキュメントの正当性のための方法であって、第１のデジタルドキュメントが、第１のドキュメントの自己検証する名前と自己検証ハッシュ値と、自己検証ハッシュ値の関連するロケーション値を含む証明書を生成することにより登録されており、前記方法は、以下のステップを含む、 a．第２のデジタルドキュメントをハッシュし、第２のドキュメントのハッシュ値を供給し、 b．第２のドキュメントのハッシュ値を前記ロケーション値に応じた自己検証ハッシュ値とに、ハッシュと結合を施し、 c．ステップ(b)の結果得られたハッシュ値が、保証されたハッシュ値と一致するかを決定する。２６、クレーム２５の方法であって、前記結合は、連結である。２７、クレーム２５の方法であって、前記保証されたハッシュ値は、（１）直接公開された、（２）直接公開された項目にリンクしている、のいづれかの項目を含む。２８、クレーム２５の方法であって、前記自己検証する名前は、前記ロケーション値と前記保証された項目の組み合わせを含む。２９、クレーム２５の方法であって、前記ロケーション値は、二分木に対応している。３０、クレーム２５の方法であって、前記ロケーション値は、リンクリストに対応している。３１、クレーム２５の方法であって、証明書は、名前の寿命を延長するために、技術の進歩に従い、更新される。３２、クレーム２５の方法であって、前記保証された項目は、直接公開された他のハッシュ値にリンクしている。３３、クレーム２７の方法であって、前記公開されたハッシュ値は、前記第１のドキュメントが登録された後に公開され、本方法によって、登録のリクエストに対するすばやい応答を、対応するすばやい公開時を必要とすることなしに行える。３４、第１のドキュメントを名付ける方法であって、以下のステップを含む a．第１のドキュメントの名前付けの第１のリクエストを、著者からサービス部に送り、前記第１のリクエストは第１のドキュメントの表示を含み、 b．サービス部において、前記第１のドキュメントの名前付けの第１のリクエストを受け取り、 c．サービス部において、複数のデジタルドキュメント各々の表示を含む、複数の他のデジタルドキュメントの名前付けの複数の他のリクエストを受け取り、 d．サービス部は、前記第１のリクエストと、前記複数の他のリクエストのうちの少なくとも一つを結合して、第１の値を形成し、 e．サービス部は、前記第１の値をハッシュし、 f．サービス部は、前記第１の値を含む複数のハッシュ値の保管庫を形成し、前記保管庫は、前記第２のリクエストと複数の他のリクエストに応じたものであり、 g．サービス部は、第１のドキュメントの、保管庫中のロケーションポインタを生成し、 h．サービス部は、前記ロケーションポインタを用いて前記第１のドキュメントを名付け、自己検証する名前を第１のドキュメントに与える。３５、クレイム３４の方法であって、前記結合は連結である。３６、クレーム３４の方法であって、さらに、保管庫の一つの項目を公開することにより、保管庫を保証するステップを含む。３７、クレーム３６の方法であって、前記ステップ(g)は、第１のドキュメントの自己検証ハッシュ値と、自己検証ハッシュ値の、関連するロケーション値の一覧を定めることを含む。３８、クレーム３７の方法であって、前記ステップ(h)は、前記公開した項目と前記ロケーション値によって前記第１のドキュメントを名付け、前記第１のドキュメントに第１の名前を与える。３９、クレーム３８の方法であって、前記保管庫は、木であって、前記公開された項目は木のルートである。４０、クレーム３８記載の方法であって、前記第１のドキュメントを名付けるステップは、前記関連するロケーション値と前記公開された項目の識別子の組み合わせに対して、圧縮符号アルゴリズムを適用し、前記第１のドキュメントに、簡単化したアルファベットおよび／または数字の名前を与えることを含む。４１、クレーム３６の方法であって、前記公開された項目の識別子は、その項目が算出された日時のユーザーフレンドリーな表示を含む。４２、クレーム３４の方法であって、ステップ(a)から(d)は、サービス部外で行われる。４３、クレーム４２の方法であって、ローカル体も、前記ステップ(b)から( f)を実行し、保証されるべきローカル項目をもつローカル保管庫を形成し、その後に、ローカル体が、前記ローカル項目を含む第１のリクエストを、前記ステップ(b)から(h)を実行する外部のサービス部におくる。４４、クレーム４３の方法であって、外部のサービス部が実行するステップ (c)から(f)は、前記ローカル項目と他のハッシュ値を結合することを含む。４５、クレーム４３の方法であって、ローカル保管庫の一つの項目は、複数の関連するドキュメントの内容のテーブルの、ハッシュ値である。４６、クレーム４３の方法であって、ローカル保管庫の複数の項目は、複数部分のドキュメントに対応し、名付けられたドキュメント間の関係の論理的構造と実質的に対応している名前の一部を供給するように、ロケーション情報が符号化されている。４７、クレーム３４の方法であって、前記前記名前の第１の部分は、リクエスト発行者によって選択され、ドキュメントを証明する。４８、クレーム４７の方法であって、前記名前の第１の部分は、リクエスト発行者によって選択され、第１のドキュメントと情報を関連させる。４９、クレーム４７の方法であって、前記名前の第１の部分は、第１のドキュメントを証明する、リクエスト発行者についての情報を提供する。５０、クレーム３４の方法であって、前記保管庫は、二分木である。５１、クレーム３４の方法であって、前記保管庫は、リンクリストである。５２、クレーム３４の方法であって、前記保管庫は、有向成長非循環グラフ (growing directed acyclic graph)である。５３、クレーム３４の方法であって、頻繁に算出される木のルートが、比較的頻繁には算出されない、そのルートがリニアリンクリストに順番に結合される木に組み込まれる。５４、クレーム３４の方法であって、証明書は、名前の寿命を延長するために、技術の進歩に従い、更新される。５５、クレーム３４の方法であって、名前をリクエスト発行者に送るステップをさらに含み、前記ステップ(h)は、前記保管庫の項目の公開が行われるよりも、実質上、先だって行われ、本方法によって、名前づけのリクエストに対するすばやい応答を、対応するすばやい公開時を必要とすることなしに、行える。５６、ドキュメントのデジタル表現を認証する、前記クレーム１の方法に従って証明書が生成された証明書。５７、ドキュメントのデジタル表現を認証する、前記クレーム３４の方法に従って生成された名前を含む証明書。５８、認証する第１のデジタルドキュメントにタイムスタンプを施す方法であって、以下のステップを含む、 a．第１のドキュメントの登録のリクエストを受け取り、 b．他の複数のリクエストを受け取り、結合して、ハッシュし、複数のリクエストに応じた複数のハッシュ値の保管庫を形成し、 c．保管庫の保証に用いる保管庫中の項目を特定し、 d．前記特定した項目を含む、前記第１のドキュメントの証明書を生成し、リクエスト発行者に送り、 e．ステップ(d)の後に、前記特定した項目を保証する。５９、クレーム５８の方法であって、ステップ(c)は、特定した項目を直接公開することを含む。６０、クレーム５８の方法であって、ステップ(c)は、前記特定した項目を、他の保管庫にリンクし、その他の保管庫の項目を直接公開する。６１、クレーム１の方法であって、サービス部が著者に証明書を送る。６２、クレーム３４の方法であって、さらに、サービス部が、自己検証する名前を含む、第１のドキュメントの証明書を生成するステップを含む。６３、クレーム６２の方法であって、証明書を著者に送るステップを、さらに含む。６４、認証のために第１のデジタルドキュメントを登録する方法であって、以下の方法を含む a．著者からサービス部に、第１のデジタルドキュメントのリクエストを送り、 b．サービス部で、第１のリクエストを受け取り、 c．サービス部において、複数の他のリクエスト各々の表示を含む、複数の他のデジタルドキュメントの登録の複数の他のリクエストを受け取り、 d．サービス部は、前記第１のリクエストと、前記複数の他のリクエストのうちの少なくとも一つを結合し、 e．サービス部は、前記第１の値を含む複数のハッシュ値の保管庫を形成し、前記保管庫は、前記第２のリクエストと複数の他のリクエストに応じたものであり、 f．サービス部は、第１のデジタルドキュメントの、保管庫中のロケーションポインタを生成し、 g．サービス部は、前記ロケーションポインタを用いて前記第１のドキュメントを名付け、自己検証する名前を第１のドキュメントに与える。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)，ＡＭ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＮ，ＣＺ，ＥＥ，ＦＩ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＲ，ＬＴ，ＬＶ，ＭＤ，ＭＧ，ＭＮ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＲＯ，ＲＵ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＴ，ＵＡ，ＵＺ，ＶＮ (72)発明者ストーネッタ、ダブリュ、スコット、ジュニアアメリカ合衆国、ニュージャージー州 07960、モリストン、ハーディングテラス 34

Claims

【特許請求の範囲】１、認証のために第１のデジタルドキュメントを登録する方法であって、以下のステップを含む、 (a) 第１のドキュメントの登録のリクエストを受け取り、 (b) 他の複数のリクエストを受け取り、結合して、ハッシュし、複数のリクエストに応じた複数のハッシュ値の保管庫を形成し、 (c) 第１ドキュメントに対する、保管庫中のロケーションポインタを生成し、 (d) ロケーションポインタによって前記第１のドキュメントを名付け、第１の名前を第１のドキュメントに与え、 (e) 前記第１の名前を含む、前記第１のドキュメントの証明書を生成する。２、クレイム１の方法であって、前記結合は連結である。３、クレーム１の方法であって、さらに、保管庫の一つの項目を公開することにより、保管庫を保証するステップを含む。４、クレーム３の方法であって、前記ステップ(c)は、第１のドキュメントの自己検証ハッシュ値と、自己検証ハッシュ値の、関連するロケーション値の一覧を定めることを含む。５、クレーム４の方法であって、前記ステップ(d)は、前記公開した項目と前記ロケーション値によって前記第１のドキュメントを名付け、前記第１のドキュメントに名前を与える。６、クレーム５の方法であって、前記証明書は、自己検証ハッシュ値の一覧を含む。７、クレーム６の方法であって、前記保管庫は、木であって、前記公開された項目は木のルートである。８、クレーム３の方法であって、前記公開された項目の識別子は、その項目が算出された日時のユーザーフレンドリーな表示を含む。９、クレーム７記載の方法であって、前記第１のドキュメントを名付けるステップは、前記関連するロケーション値と前記公開された項目の識別子の組み合わせに対して、圧縮符号アルゴリズムを適用し、前記第１のドキュメントに、簡単化したアルファベットおよび／または数字の名前を与えることを含む。１０、クレーム１の方法であって、前記ステップ(c)は、前記保管庫の項目の公開が行われるよりも、実質上、先だって行われ、本方法によって、登録のリクエストに対するすばやい応答を、対応するすばやい公開時を必要とすることなしに行う。１１、クレーム１の方法であって、ステップ(a)から(e)は、サービス部外で行われる。１２、クレーム１１の方法であって、ローカル体も、前記ステップ(a)から( b)を実行し、保証されるべきローカル項目をもつローカル保管庫を形成し、その後に、ローカル体が、前記ローカル項目を含む第１のリクエストを、前記ステップ(a)から(e)を実行する外部のサービス部におくる。１３、クレーム１２の方法であって、外部のサービス部が実行するステップ (b)は、前記ローカル項目と他のハッシュ値を結合することを含む。１４、クレーム１２の方法であって、ローカル保管庫の一つの項目は、複数の関連するドキュメントの内容のテーブルのハッシュ値である。１５、クレーム１２の方法であって、ローカル保管庫の複数の項目は、複数部分のドキュメントに対応している。１６、クレーム１の方法であって、前記前記名前の第１の部分は、リクエスト発行者によって選択され、ドキュメントを証明する。１７、クレーム１６の方法であって、前記名前の第１の部分は、リクエスト発行者によって選択され、第１のドキュメントと情報を関連させる。１８、クレーム１６の方法であって、前記名前の第１の部分は、第１のドキュメントを証明する、リクエスト発行者についての情報を提供する。１９、クレーム１の方法であって、前記保管庫は、二分木である。２０、クレーム１の方法であって、前記保管庫は、リンクリストである。２１、クレーム１の方法であって、前記保管庫は、有向成長非循環グラフ(g rowing directed acyclic graph)である。２２、クレーム１の方法であって、頻繁に算出される木のルートが、比較的頻繁には算出されない、そのルートがリニアリンクリストに順番に結合される木に組み込まれる。２３、クレーム１の方法であって、証明書は、名前の寿命を延長するために、技術の進歩に従い、更新される。２４、クレーム１の方法であって、証明書は、記録設備に送られ、第１のリクエストの生成者に送られる。２５、デジタルドキュメントを認証する方法であって、以下のステップを含む (a) 第１のドキュメントの自己検証する名前と自己検証ハッシュ値と、前記自己検証ハッシュ値の関連するロケーション値と、を含む証明書を生成することにより、第１のドキュメントを登録し、 (b) 第１のドキュメントをハッシュし、第１１のドキュメントのハッシュ値を供給し、 (c) 第１のドキュメントのハッシュ値を、前記ロケーション値に従って前記自己検証ハッシュ値との、ハッシュと結合を行い。 (d) ステップ(c)の結果得られたハッシュ値が、保証されたハッシュ値に一致するかを決定する。２６、クレーム２５の方法であって、前記結合は、連結である。２７、クレーム２５の方法であって、前記保証されたハッシュ値は、（１）直接公開された、（２）直接公開された項目にリンクしている、のいづれかの項目を含む。２８、クレーム２５の方法であって、前記自己検証する名前は、前記ロケーション値と前記保証された項目の組み合わせを含む。２９、クレーム２５の方法であって、前記ロケーション値は、二分木に対応している。３０、クレーム２５の方法であって、前記ロケーション値は、リンクリストに対応している。３１、クレーム２５の方法であって、証明書は、名前の寿命を延長するために、技術の進歩に従い、更新される。３２、クレーム２５の方法であって、前記保証された項目は、直接公開された他のハッシュ値にリンクしている。３３、クレーム２７の方法であって、前記公開されたハッシュ値は、前記第１のドキュメントが登録された後に公開され、本方法によって、登録のリクエストに対するすばやい応答を、対応するすばやい公開時を必要とすることなしに行える。３４、第１のドキュメントを名付ける方法であって、以下のステップを含む (a) 第１のドキュメントの登録のリクエストを受け取り、 (b) 他の複数のリクエストを受け取り、結合して、ハッシュし、複数のリクエストに応じたハッシュ値の保管庫を形成し、 (c) 第１ドキュメントに対する、保管庫中のロケーションポインタを生成し、 (d) ロケーションポインタによって前記第１のドキュメントを名付け、自己検証する名前を第１のドキュメントに与える。３５、クレイム３４の方法であって、前記結合は連結である。３６、クレーム３４の方法であって、さらに、保管庫の一つの項目を公開することにより、保管庫を保証するステップを含む。３７、クレーム３６の方法であって、前記ステップ(c)は、第１のドキュメントの自己検証ハッシュ値と、自己検証ハッシュ値の、関連するロケーション値の一覧を定めることを含む。３８、クレーム３７の方法であって、前記ステップ(d)は、前記公開した項目と前記ロケーション値によって前記第１のドキュメントを名付け、前記第１のドキュメントに名前を与える。３９、クレーム３８の方法であって、前記保管庫は、木であって、前記公開された項目は木のルートである。４０、クレーム３８の方法であって、前記第１のドキュメントを名付けるステップは、前記関連するロケーション値と前記公開された項目の識別子の組み合わせに対して、圧縮符号アルゴリズムを適用し、前記第１のドキュメントに、簡単化したアルファベットおよび／または数字の名前を与えることを含む。４１、クレーム３６の方法であって、前記公開された項目の識別子は、その項目が算出された日時のユーザーフレンドリーな表示を含む。４２、クレーム３４の方法であって、ステップ(a)から(d)は、サービス部外で行われる。４３、クレーム４２の方法であって、ローカル体も、前記ステップ(a)から (b)を実行し、保証されるべきローカル項目をもつローカル保管庫を形成し、その後に、ローカル体が、前記ローカル項目を含む第１のリクエストを、前記ステップ(a)から(d)を実行する外部のサービス部におくる。４４、クレーム４３の方法であって、外部のサービス部が実行するステップ (b)は、前記ローカル項目と他のハッシュ値を結合することを含む。４５、クレーム４３の方法であって、ローカル保管庫の一つの項目は、複数の関連するドキュメントの内容のテーブルのハッシュ値である。４６、クレーム４３の方法であって、ローカル保管庫の複数の項目は、複数部分のドキュメントに対応し、名付けられたドキュメント間の関係の論理的構造と実質的に対応している名前の一部を供給するように、ロケーション情報が符号化されている。４７、クレーム３４の方法であって、前記前記名前の第１の部分は、リクエスト発行者によって選択され、ドキュメントを証明する。４８、クレーム４７の方法であって、前記名前の第１の部分は、リクエスト発行者によって選択され、第１のドキュメントと情報を関連させる。４９、クレーム４７の方法であって、前記名前の第１の部分は、第１のドキュメントを証明する、リクエスト発行者についての情報を提供する。５０、クレーム３４の方法であって、前記保管庫は、二分木である。５１、クレーム３４の方法であって、前記保管庫は、リンクリストである。５２、クレーム３４の方法であって、前記保管庫は、有向成長非循環グラフ (growing directed acyclic graph)である。５３、クレーム３４の方法であって、頻繁に算出される木のルートが、比較的頻繁には算出されない、そのルートがリニアリンクリストに順番に結合される木に組み込まれる。５４、クレーム３４の方法であって、証明書は、名前の寿命を延長するために、技術の進歩に従い、更新される。５５、クレーム３４の方法であって、名前をリクエスト発行者に送るステップをさらに含み、前記ステップ(d)は、前記保管庫の項目の公開が行われるよりも、実質上、先だって行われ、本方法によって、名前づけのリクエストに対するすばやい応答を、対応するすばやい公開時を必要とすることなしに、行える。５６、ドキュメントのデジタル表現を認証する、前記クレーム１の方法に従って証明書が生成された証明書。５７、ドキュメントのデジタル表現を認証する、前記クレーム３４の方法に従って生成された名前を含む証明書。５８、認証のために第１のデジタルドキュメントにタイムスタンプを施す方法であって、以下のステップを含む、 (a) 第１のドキュメントの登録のリクエストを受け取り、 (b) 他の複数のリクエストを受け取り、結合とハッシュを行う、複数のリクエストに応じた複数のハッシュ値の保管庫を形成し、 (c) 保管庫の保証に用いる保管庫中の項目を特定し、 (d) 前記特定した項目を含む、前記第１のドキュメントの証明書を生成し、リクエスト発行者に送り、 (e) ステップ(d)の後に、前記特定した項目を保証し、本方法によって、登録のリクエストに対するすばやい応答を、対応するすばやい公開時を必要とすることなしに行う。５９、クレーム５８の方法であって、ステップ(e)は、特定した項目を直接公開することを含む。６０、クレーム５８の方法であって、ステップ(c)は、前記特定した項目を、他の保管庫にリンクし、その他の保管庫の項目を直接公開する。