(57)【要約】デジタル署名システムが、許可されたユーザが電子的に署名させることが許されるドキュメントを識別するアクセス制御規則を保持するデータベース、及び複数個の許可されたユーザからの署名要求を受取ることが可能な署名システムを有しており、各署名要求は署名されるべきドキュメントを包含しており、該署名システムは署名されるべきドキュメントを構文解析し且つそれにより得られた情報をデータベース内に格納されているアクセス制御規則と比較してその許可されたユーザがそのドキュメントを署名させることが許可されているか否かを決定し、且つその許可されたユーザがそのドキュメントを署名させることが許可されていることが決定される場合には、該署名システムが該署名システムにとって独特の真正性確認情報を使用してそのドキュメントに署名を行う。【選択図】図１
2004531918.tif 000002
【特許請求の範囲】
【請求項１】
デジタル署名システムにおいて、
許可されたユーザが電子的に署名することが許容されるドキュメントを識別するアクセス制御規則を保持するデータベース、
複数の許可されたユーザからの署名要求を受取ることが可能な署名システム、
を有しており、各署名要求は署名すべきドキュメントを包含しており、前記署名システムは署名すべきドキュメントの構文解析を行い且つそれにより得られた情報を前記データベースに格納されているアクセス制御規則と比較して前記許可されたユーザが前記ドキュメントに署名することが許可されているか否かを決定し、且つ前記許可されたユーザが前記ドキュメントに署名することが許可されていることが決定される場合には、前記署名システムが前記署名システムに対して独特の真正性確認情報を使用して前記ドキュメントに署名を行う、デジタル署名システム。
【請求項２】
請求項１において、前記アクセス制御規則が、各ユーザが署名することが許可されているドキュメントのタイプ及び属性の少なくとも１つを識別するデジタル署名システム。
【請求項３】
請求項２において、前記署名システムが前記署名すべきドキュメントを構文解析して前記ドキュメントのタイプ及び属性のうちの少なくとも１つを決定し且つ前記決定したドキュメントのタイプ及び属性を前記データベースに格納されているアクセス制御規則と比較して前記ユーザが前記ドキュメントに署名することが許可されているか否かを決定するデジタル署名システム。
【請求項４】
請求項１において、前記要求が、更に、その要求を行うユーザに対して独特のユーザ真正性確認情報を包含しており、且つ前記署名システムが、前記ユーザ真正性確認情報を介して前記ユーザの真正性確認を行い且つ前記ユーザの真正性確認が行われない限り前記ドキュメントの構文解析を行わないデジタル署名システム。
【請求項５】
請求項４において、前記ユーザ真正性確認情報が、対応するパブリックキー及びプライベートキーを具備するデジタル証明を有しているデジタル証明書を有しているデジタル署名システム。
【請求項６】
請求項５において、前記デジタル証明書がＸ−５０９証明書を有しているデジタル署名システム。
【請求項７】
請求項４において、更に、電子メールインターフェースを有しており、前記署名要求が前記署名システムに対してアドレスされたユーザからの電子メールの形態であるデジタル署名システム。
【請求項８】
請求項７において、前記ユーザ真正性確認情報がユーザの電子メールアドレスを有しているデジタル署名システム。
【請求項９】
請求項８において、前記署名システムが、ユーザの電子メールアドレスを前記データベース内に格納されている電子メールアドレスと比較することによりユーザの真正性確認を行うデジタル署名システム。
【請求項１０】
請求項１において、更に、署名されたドキュメントを検証することを要求するユーザからのドキュメント検証要求を受取り且つその署名されたドキュメントが該要求に応答して有効であるかを否かを決定するドキュメント検証サーバーを有しているデジタル署名システム。
【請求項１１】
請求項１において、前記ドキュメント検証サーバーが前記ドキュメントを署名した後に、その署名したドキュメントをユーザへ電子的に転送し、従ってユーザがその署名したドキュメントを受信者へ転送することが可能であるデジタル署名システム。
【請求項１２】
請求項１において、前記ドキュメントに署名した後に、その署名したドキュメントがユーザへ電子メールされるデジタル署名システム。
【請求項１３】
請求項１において、前記ドキュメントに署名された後に、その署名されたドキュメントが自動的に受信者へ電子的に転送されるデジタル署名システム。
【請求項１４】
請求項１３において、前記署名したドキュメントが受信者へ電子メールされるデジタル署名システム。
【請求項１５】
署名システムを使用してドキュメントにデジタル的に署名する方法において、
許可されたユーザが電子的に署名することが許容されるドキュメントを識別するアクセス制御規則を格納し、
少なくとも一人のユーザからの署名すべきドキュメントを包含する署名要求を受取り、
前記ユーザがドキュメントに署名することが許可されているか否かを決定し、
前記ユーザが許可されている場合には、署名すべきドキュメントを構文解析し、
前記構文解析により得られた情報を前記格納されているアクセス制御規則と比較して前記許可されたユーザが添付したドキュメントに署名することが許可されているか否かを決定し、
許可されたユーザが添付したドキュメントに署名することが許可されていることが決定される場合には、署名システムに対して独特の真正性確認情報を使用してドキュメントに署名する、
ことを包含している方法。
【請求項１６】
請求項１５において、前記アクセス制御規則が、各ユーザが署名することが許可されているドキュメントのタイプ及び属性のうちの少なくとも１つを識別する方法。
【請求項１７】
請求項１６において、前記構文解析ステップが署名すべきドキュメントを構文解析して前記ドキュメントのタイプ及び属性のうちの少なくとも１つを決定し、且つ前記比較ステップが前記ドキュメントの決定されたタイプ及び属性を前記データベースに格納されているアクセス制御規則と比較して前記ユーザがそのドキュメントに署名することが許可されているか否かを決定する方法。
【請求項１８】
請求項１５において、前記要求が、更に、前記要求を行うユーザに対して独特のユーザ真正性確認情報を包含しており、且つ前記署名システムが前記ユーザ真正性確認情報を介してユーザの真正性確認を行い且つ前記ユーザの真正性確認がされない限り前記ドキュメントの構文解析を行わない方法。
【請求項１９】
請求項１８において、前記ユーザ真正性確認情報が対応するパブリックキー及びプライベートキーを具備するデジタル証明書を有している方法。
【請求項２０】
請求項１９において、前記デジタル証明書がＸ−５０９証明書を有している方法。
【請求項２１】
請求項１５において、更に、Ｅメールインターフェースを有しており、前記署名要求が前記署名システムへアドレスされたユーザからの電子メールの形態である方法。
【請求項２２】
請求項２１において、許可されたユーザに対応する格納されている電子メールアドレスのリストに対してユーザの電子メールアドレスを比較することによりユーザが許可されたユーザであるか否かを決定する方法。
【請求項２３】
請求項１５において、更に、署名されたドキュメントをユーザへ電子的に転送し、従ってユーザがその署名したドキュメントを受信者へ転送することが可能であることを包含している方法。
【請求項２４】
請求項１５において、更に、署名したドキュメントをユーザへ電子メールすることを包含している方法。
【請求項２５】
請求項１５において、更に、署名したドキュメントを最終受信者へ電子的に転送することを包含している方法。
【請求項２６】
請求項２５において、前記署名したドキュメントを最終受信者へ電子メールする方法。
【請求項２７】
ドキュメントにデジタル的に署名する署名システムにおいて、
許可されたユーザが電子的に署名することが許容されるドキュメントを識別するアクセス制御規則を格納する格納手段、
少なくとも一人のユーザから署名すべきドキュメントを包含する署名要求を受取る受取手段、
前記ユーザがドキュメントに署名することが許可されているか否かを決定する決定手段、
前記ユーザが許可されている場合に署名すべきドキュメントを構文解析する構文解析手段、
許可されたユーザが添付したドキュメントに署名することが許可されているか否かを決定するために前記構文解析手段によって得られた情報を前記格納されているアクセス制御規則と比較する比較手段、
前記許可されたユーザが前記添付したドキュメントに署名することが許可されていることが決定される場合に前記署名システムに対して独特の真正性確認情報を使用して前記ドキュメントに署名を行う署名手段、
を有しているシステム。
【請求項２８】
請求項２７において、前記アクセス制御規則が、各ユーザが署名することが許可されているドキュメントのタイプ及び属性のうちの少なくとも１つを識別するシステム。
【請求項２９】
請求項２８において、前記構文解析手段が署名すべきドキュメントを構文解析して前記ドキュメントのタイプ及び属性のうちの少なくとも１つを決定し、且つ前記比較手段が前記ドキュメントの決定されたタイプ及び属性を前記データベース内に格納されているアクセス制御規則と比較して前記ユーザが前記ドキュメントに署名することが許可されているか否かを決定するシステム。
【請求項３０】
請求項２７において、前記要求が、更に、その要求を行うユーザに対して独特のユーザ真正性確認情報を包含しており、且つ前記署名システムが前記ユーザ真正性確認情報を介してユーザの真正性確認を行い且つユーザの真正性確認が行われない限り前記ドキュメントの構文解析を行わないシステム。
【請求項３１】
請求項３０において、前記ユーザ真正性確認情報が対応するパブリックキー及びプライベートキーを具備するデジタル証明書を有しているシステム。
【請求項３２】
請求項３１において、前記デジタル証明書がＸ−５０９証明書を有しているシステム。
【請求項３３】
請求項２７において、更に、電子メールインターフェース手段を有しており、前記署名要求が前記署名システムに対してアドレスされたユーザからの電子メールの形態であるシステム。
【請求項３４】
請求項３３において、ユーザの電子メールアドレスを許可されたユーザに対応する格納されている電子メールアドレスからなるリストと比較することによりそのユーザが許可されたユーザであるか否かを前記決定手段によって決定するシステム。
【請求項３５】
請求項２７において、更に、ユーザが署名されたドキュメントを受信者へ転送することが可能であるように署名されたドキュメントをユーザへ電子的に転送する転送手段を有しているシステム。
【請求項３６】
請求項２７において、更に、署名されたドキュメントをユーザへ電子メールする電子メール手段を有しているシステム。
【請求項３７】
請求項２７において、更に、署名されたドキュメントを最終受信者へ電子的に転送する手段を有しているシステム。
【請求項３８】
請求項３７において、署名されたドキュメントを最終受信者へ電子メールするシステム。
【請求項３９】
デジタル署名システムにおいて、
許可されたユーザが電子的に署名することが許容されるドキュメントを識別するアクセス制御規則を保持するデータベース手段、
複数の許可されたユーザからの署名要求を受取ることが可能な署名手段、
を有しており、各署名要求が署名すべきドキュメントを包含しており、前記署名手段が署名すべきドキュメントを構文解析し且つそれにより得られた情報を前記データベース手段内に格納されているアクセス制御規則と比較してその許可されたユーザがドキュメントに署名することが許可されているか否かを決定し、且つその許可されたユーザがドキュメントに署名することが許可されていることが決定される場合には、前記署名手段が前記署名手段に対して独特の真正性確認情報を使用してドキュメントに署名する、
デジタル署名システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、大略、デジタル署名に関するものであって、特に、デジタル署名を得るための方法及びシステムに関するものである。
【背景技術】
【０００２】
暗号化はデータの内容を保護する最も一般的に使用されている方法のうちの１つである。暗号化は、しばしば、転送中及び格納中のデータを保護するために使用される。その基本的な形態において、暗号化は、典型的に、平文テキストデータを暗号文テキストとして呼称される理解不可能な形態へ変換するアルゴリズムを使用することが関与する。暗号化において使用されるアルゴリズムはキー即ち鍵として知られているそこにおいて使用されるパラメータによって定義することが可能である。２つの公知の暗号化方法は、プライベートキー即ち秘密鍵のみを使用する対称方法、及びパブリックキー、即ち公開鍵、及びプライベートキーを使用する非対称方法である。
【０００３】
対称プライベートキー暗号化を使用する場合には、送信者はプライベートキーを使用してデータを暗号化する。次いで、受信者は同一のプライベートキーを使用してデータの解読を行う。対象プライベートキー暗号化の１つの欠点は、送信者及び受信者の両方が同一のプライベートキーを知っていねばならないということである。従って、送信者と受信者との間でのキーの交換がプライベートキーの露顕又は偽造の危険性を包含するセキュリティの危険性を発生する場合がある。
【０００４】
パブリックキー暗号化は、キー対を使用する非対称暗号化方法である。各キー対はパブリックキーとプライベートキーとを包含している。プライベートキーの保持者はそのプライベートキーを使用してデータを暗号化することが可能である。そのプライベートキーに対応するパブリックキーの保持者のみがそのパブリックキーを使用してそのデータを解読することが可能である。一方、そのパブリックキーの保持者はそのパブリックキーを使用してデータを暗号化することが可能である。次いで、その暗号化されたデータは安全にプライベートキーの保持者へ転送することが可能である。何故ならば、そのプライベートキーの保持者のみがそのデータを解読することが可能だからである。典型的に、各ユーザのパブリックキーはパブリックキーファイルにおいて発行されるか又は証明書内に埋め込まれている。ユーザのプライベートキーは秘密に維持することが可能である。
【０００５】
パブリックキー暗号化はプライベートキー暗号化と比較して増加したセキュリティを提供する。何故ならば、保持者のプライベートキーを誰にも開示することが必要ではないからである。パブリックキー暗号化は、又、データの受信者がデータの出所を証明することを可能とする。例えば、送信者がそれ自身の秘密のプライベートキーを使用してデータを暗号化する。そのデータを検証するために、受信者は送信者のパブリックキーを使用してそのデータを解読する。送信者のパブリックキーを使用してメッセージが成功裡に解読される場合には、そのメッセージはその送信者から発信されたものであるはずである。何故ならば、その送信者のみがそのプライベートキーに対してアクセスを有しているからである。
【０００６】
更に、デジタル署名は更なるレベルの保護を与えることが可能である。送信者はそれ自身のプライベートキーを使用してデータを暗号化することによりデータに「署名」を行うことが可能である。次いで、送信者は受信者のパブリックキーを使用して更に暗号化することによりその署名したデータをパッケージ化することが可能である。受信端において、受信者はそれ自身のプライベートキーを使用してそのパッケージを解読し、次いで、送信者のパブリックキーを使用して更に解読することにより送信者の署名を検証する。
【０００７】
デジタル署名は、又、その他の方法を使用して形成することも可能である。例えば、一方向ハッシュ関数を使用してデータを単一のブロックにダイジェスト（ハッシュ化）することが可能である。一方向ハッシュ関数は、その値へハッシュ化するデータを構築すること又は同一のダイジェストへハッシュ化するデータパターンを見つけ出すことが計算上非現実的であるという特性を有している。そのダイジェストを送信者のプライベートキーで暗号化させることが可能である。次いで、その結果的に得られる暗号化したダイジェストを署名として暗号化させたか又は暗号化させていないデータ（受信者のパブリックキーを使用して暗号化）へ添付することが可能である。受信した場合に、受信者は送信者のパブリックキーを使用してそのダイジェストを解読する。受信者は、又、暗号化されないで受信したデータをダイジェスト（ハッシュ化）する。データが暗号化されないで受信された場合には、それは、最初に、受信者のプライベートキーを使用して解読され、次いで、送信者によって使用されたのと同一の一方向ハッシュ関数を使用してダイジェスト化（ハッシュ化）させる。解読されたダイジェストを受信者が発生したダイジェストに対してチェックすることにより、送信者の署名を検証することが可能である。このタイプのデジタル署名はデータのインテグリティ即ち完全性の検査を与える。即ち、送信されるデータの何等かの修正は受信者端において異なるダイジェストとなり、従って、送信者が発生したダイジェストとの比較は、そのデータが露顕されたものであることの表示を与える。このタイプのデジタル署名は、又、データの出所の真正性確認（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）を与える。例えば、そのダイジェストを検証するために使用したパブリックキーに対応するプライベートキーの保持者のみがそのデータに署名することが可能であったものである。
【０００８】
ユーザのプライベートキーの所持を確保する態様でのデータ送信に対して一人のユーザが別のユーザを識別することを可能とするために、最初のユーザは信頼のおける供給源から他方のユーザのパブリックキーを得ることが可能でなければならない。証明機関（ＣＡ）がこのような信頼された供給源を与える。ＣＡはパブリックキー証明書を発行する。各証明書は、典型的に、ユーザ名及びパブリックキー、発行ＣＡ名称、連続番号及び有効期間を包含している。パブリックキー証明書に対する枠組はＣＣＩＴＴ「Ｘ．５０９：ディレクトリィ：真正性確認枠組（Ｘ．５０９：Ｔｈｅ  Ｄｉｒｅｃｔｏｒｙ：  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ）」、１９９３年４月（Ｘ．５０９）において定義されており、尚、それを引用によって本明細書に取込む。実際に、パブリックキー証明書はユーザ名をパブリックキーと結び付け且つ信頼された発行体（例えば、ＣＡ）によって署名される。典型的に、この証明書は配布までＣＡの機関によって署名される。ユーザからのデータの受信者は、その受信者がＣＡ機関の署名の検査を可能とする機関のパブリックキーを認識する限り、且つその受信者がＣＡを信用する範囲において、その署名を信用することが可能である。
【０００９】
ＣＡ枠組における１つの問題は、そのメッセージの送信者に与えられる信用の程度又は責任レベルの表示をその証明書が与えるものではないということである。即ち、ＣＡは、識別された信頼された機関（ＣＡ）がその送信者のパブリックキーがその人に属するものとして認識したということを証明するに過ぎない。
【００１０】
属性証明書は更なる保護の程度を与える。属性証明書は、証明される当事者に対して認可された権限を示すような態様でデジタル署名を証明する。この属性証明書は、証明される当事者のパブリックキー及び名前を識別する情報に加えて、認可される権限レベル及び課されている制限及びセーフガードを包含する。この情報は証明書に対する懸念事項を表わす場合がある。例えば、その情報は、証明内容に対する金額的限界及び／又は証明内容に対して与えられた信用レベルを包含する場合がある。
【００１１】
典型的に、法人又はビジネス環境において、各従業員はそれ自身のデジタル証明書が割当てられる。各従業員は所望する任意のドキュメントに署名するためにそれ自身のパブリックキーを使用することが可能である。従って、署名されたドキュメントの受信者は、その署名者の証明書が否認されていないことを検査することが必要である。このことは、典型的に、受信者が送信者の会社のディレクトリィにおける証明書取消リストをチェックすることによって達成される。受信者は、又、その会社のディレクトリィから従業員の属性証明書を検索することによって、その従業員がそのドキュメントに署名する権限が与えられていたことを検査することが可能である。
【００１２】
然しながら、これらの従来の方法は欠点を有している。例えば、その署名者と異なる会社のためにしばしば従事する受信者は、その従業員の権限レベルをチェックする負担を有している。このことはその組織が署名したドキュメントを送信する誰に対しても重要な内部法人情報を露顕させる可能性がある。例えば、送信者の権限を適切に検査するために、その会社内においてそれを署名する権限を有するものは誰であるかについての潜在的に重要な法人情報へ受信者がアクセスすることを必要とする。
【００１３】
別の制限は、従業員が会社を辞める場合に、その証明書は取り消されねばならないということである。それを証明書取消リスト（ＣＲＬ）に掲載することにより証明書を取り消すことが可能である。従って、ドキュメントの受信者は、署名者の証明書が取り消されていないことをチェックせねばならず、そのことは受信者の義務に付加的な負担を付加し且つ受信者に対して付加的な潜在的に重要な内部法人情報を与えることとなる。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
本発明は、以上の点に鑑みなされたものであって、上述した如き従来技術の欠点を解消し、改良したデジタル署名技術を提供することを目的とする。本発明の別の目的とするところは、デジタル署名を得るための改良した方法及びシステムを提供することである。
【課題を解決するための手段】
【００１５】
デジタル署名システムは、許可されたユーザが電子的に署名することが許容されるドキュメントを識別するアクセス制御規則を保持するデータベースと、複数個の許可されたユーザからの署名要求を受取ることが可能な署名システムとを有しており、各署名要求は署名されるべきドキュメント即ち文書を包含している。該署名システムは、署名されるべきドキュメントを構文解析し、且つそれにより得られた情報を該データベース内に格納されているアクセス制御規則と比較して、その許可されたユーザがそのドキュメントに署名することが許可されているか否かを決定する。その許可されたユーザがそのドキュメントに署名することが許可されていることが決定される場合には、該署名システムは、該署名システムにとって独特の真正性確認情報を使用してそのドキュメントに署名を行う。
【００１６】
該アクセス制御規則は、各ユーザが署名することが許可されているドキュメントのタイプ及び属性のうちの少なくとも１つを識別することが可能であり、且つ該署名システムは署名すべきドキュメントを構文解析して該ドキュメントのタイプ及び属性のうちの少なくとも１つを決定し且つ該ドキュメントの決定したタイプ及び属性を該データベース内に格納されているアクセス制御規則に対して比較して該ユーザがそのドキュメントに署名することが許可されているか否かを決定することが可能である。
【００１７】
該要求は、更に、その要求を行うユーザに対して独特のユーザ真正性確認情報を包含することが可能であり、その場合に、該署名システムは、ユーザ真正性確認情報を介してそのユーザの真正性確認を行い且つ該ユーザの真正性確認がなされない限り該ドキュメントを構文解析することはない。ユーザ真正性確認情報は、対応するパブリックキー及びプライベートキーを具備するデジタル証明書を有することが可能である。該デジタル証明書はＸ−５０９証明書を有することが可能である。
【００１８】
本システムは、更に、電子メールインターフェースを有することが可能であり、その場合に、署名要求は該署名システムに対してアドレスされたユーザからの電子メールの形態であり、且つユーザ真正性確認情報はユーザの電子メールアドレスを有することが可能である。該署名システムは、ユーザの電子メールアドレスを該データベース内に格納されている電子メールアドレスと比較することによってユーザの真正性確認を行うことが可能である。
【００１９】
署名システムを使用してドキュメントをデジタル的に署名する方法も開示されており、且つ許可されたユーザが電子的に署名を行うことが許容されるドキュメントを識別するアクセス制御規則を格納し、少なくとも一人のユーザからの署名すべきドキュメントを包含する署名要求を受取り、且つそのユーザがドキュメントに署名を行うことが許可されているか否かを決定することを包含している。そのユーザが許可されている場合には、その署名すべきドキュメントの構文解析を行う。構文解析により得られた情報を格納されているアクセス制御規則と比較してその許可されたユーザが添付されたドキュメントに署名することが許可されているか否かを決定し、且つその許可されたユーザが添付されたドキュメントに署名することが許可されていることが決定される場合に、署名システムに対して独特の真正性確認情報を使用してそのドキュメントに署名を行う。
【発明を実施するための最良の形態】
【００２０】
図面に例示した好適実施例を説明する場合に、説明の便宜上特定の用語を使用する。然しながら、本システム及び方法はそのように選択された特定の用語に制限されることを意図したものではなく、各特定の要素は同様の態様で動作する全ての技術的均等物を包含するものと理解すべきである。
【００２１】
１実施例に基づくドキュメントを署名するためのシステムが図１に示されている。本システムは、署名システム１００と一義的に関連する証明書又はプライベートキーを使用してドキュメントに電子的に署名を行うための署名システム１００、及び各許可されたユーザが署名することが許容されるドキュメントのタイプ及び属性を表わす情報を格納する署名ポリシーデータベース１００ａを有している。署名システム１００によって特定のドキュメントを署名させるために署名システム１００により少なくとも一人の署名要求者１０２ａ−１０２ｎが許可される。各要求者１０２ａ−１０２ｎは任意の所望のドキュメントを署名させるための要求を提出することが可能である。然しながら、署名システム１００は、その要求者が署名されることが許可されているドキュメントのみに署名を行う。例えば、要求者はドキュメントに署名されることの要求を準備し且つその要求を該ドキュメントと共に署名システム１００へ転送する。署名システム１００はそのドキュメントを構文解析してそのタイプと属性とを決定する。
【００２２】
ドキュメント構文解析は、例えば字句解析及び／又はその他の技術を使用してドキュメントをトークン又はワードへ分割すること、次いで該トークン又はワードのパターンを認識することが関与する。例えば、ＸＭＬドキュメントは開始タグ、終了タグ、コメント、要素等に分解することが可能である。ＸＭＬインボイスは、１組の有効な開始及び終了タグ、該タグと関連する属性、及びドキュメント内に包含されている要素に関する拘束条件によって特性付けることが可能である。１つのドキュメントを構文解析する場合に、署名システムは、ドキュメントが、例えば、有効なＸＭＬドキュメントであるか否かを決定する。有効なＸＭＬドキュメントである場合には、次に、それが有効なＸＭＬインボイスであるか否かを決定する。本システムは、ドキュメントの属性（例えば、総額＝＄１，０００）を識別する。本システムは、この情報を定義されているドキュメントのタイプと比較することが可能である。例えば、この場合に、そのインボイスは「＄２，５００未満のインボイス」として分類される場合がある。勿論、その他のドキュメントタイプを使用することが可能である。
【００２３】
次いで、署名システム１００はドキュメントタイプ及び属性をそのデータベース１００ａ内に格納されている情報に対して比較し、その要求者がそのドキュメントを署名させることが許可されているか否かを決定する。そのドキュメントを署名させることが許可されている場合には、署名システム１００はそれ自身の独特の即ち一義的な署名証明書を使用してそのドキュメントに署名を行う。次いで、その署名されたドキュメントは意図された受信者又は複数の受信者１０３ａ−１０３ｎへ転送される。次いで、署名されたドキュメントの受信者は、署名システムの署名証明者が取り消されていないことを検査することが必要であるに過ぎない。署名システム１００を使用する場合に、各署名者の権限乃至は許可レベルをチェックする責任はそれが属するビジネス又は組織体内に維持することが可能である。このことは署名されたドキュメントの受信者の作業を緩和させる。更に、内部法人情報が不必要に外部者に対して露顕されることはなく、且つ従業員がその組織体を辞める場合に、会社外部から見られる目視可能な効果は存在しない。
【００２４】
１実施例に基づく署名システムのより詳細な説明を図２Ａ及び２Ｂを参照して説明する。図２Ａは本システムをブロック図の形態で示しており且つ図２Ｂは本システムを機能的形態で示している。この実施例に基づく署名システムは、ドキュメント署名サーバー（ＤＳＳ）２、安全監査サーバー（ＳＡＳ）４及びドキュメント検証サーバー（ＤＶＳ）６を包含している。ＤＳＳ２、ＳＡＳ４、ＤＶＳ６は、ここでは、集約的に署名システム１として呼称し、且つ各々は図２Ａに示したようにネットワーク９上に設けられている。図２Ｂに示したように、ＤＳＳ２、ＳＡＳ４、ＤＶＳ６の各々はサーバーと要求者８とアドミニストレーター１２との間での安全な通信を可能とさせる安全なアプリケーションプログラムインターフェース（ＡＰＩ）を包含している。
【００２５】
ネットワーク９はこの実施例においてはローカルエリアネットワーク（ＬＡＮ）として記載するが、ネットワーク９は、その代わりに、ワイドエリアネットワーク（ＷＡＮ）又は、例えば、インターネット等のその他のタイプのネットワークトすることが可能であることを理解すべきである。更なる安全性の程度を与えるために、サーバー２−６は例えば安全ルーターを介して１個又はそれ以上のＬＡＮ又はインターネットへ接続されている別個の安全なＬＡＮ上に設けることが可能である。ネットワーク９に対して１個又はそれ以上のアドミニストレーターワークステーション又はターミナル５が接続されており、それらはアドミニストレーターが１個又はそれ以上のサーバー２−６へアクセスすることを可能とさせる。図示していないが、各サーバー２−６は許可された人員により遠隔アクセスを許容するためにモデム又はその他のタイプの通信装置を包含することが可能である。ネットワーク９は、又、それに接続されているユーザワークステーション又はターミナル７を有することが可能であり、それは従業員又はその他の許可された人員（要求者）がドキュメントが署名されることを要求するために署名システム１へアクセスすることを許容し及び／又は署名されたドキュメントが署名システム１により検証されることを可能とする。各ワークステーション又はターミナル５，７は、例えば、パソコン（ＰＣ）から構成することが可能である。図２Ｂに示したように、各ユーザワークステーション又はターミナル７は、１個又はそれ以上の要求者８ａ−８ｎと署名システム１との間にユーザフレンドリーなインターフェースを与える１個又はそれ以上のグラフィカルユーザインターフェース（ＧＵＩ）２５を包含することが可能である。更に、ワークステーション又はターミナル７上で稼動するその他のアプリケーション１９は、ドキュメントを署名させるため、署名されているドキュメントを検証するため、及び署名されているドキュメントの履歴を追跡するために安全なＡＰＩを使用することが可能である。各アドミニストレーターワークステーション又はターミナル５は、１つ又はそれ以上のアドミニストレーター１２ａ−１２ｎと署名システム１との間にユーザフレンドリーなインターフェースを与える１個又はそれ以上のＧＵＩ２６を包含することが可能である。
【００２６】
この実施例に基づいて署名を得るための方法及びシステムは、デジタル署名を必要とする全てのドキュメントが署名システム１により署名されるような組織幅環境において実現することが可能である。例えば、署名システム１が電子署名を必要とする全てのドキュメントに署名するようなポリシー即ち方針を会社が実現することが可能である。この実施例においては、各要求者８ａ−８ｎは会社Ｘの従業員を表わしている。勿論、要求者は、又、会社のドキュメントに署名させるために会社Ｘによって許可されている非従業員を包含することも可能である。
【００２７】
署名システム１は署名ポリシーデータベース１４を包含しており、それは各許可された人員が署名されることが許容されているドキュメントのタイプ及び／又は属性を定義する。各要求者８ａ−８ｎは、署名システム１が所望により任意のドキュメントに署名することを要求することが可能である。然しながら、署名システム１は、その要求者が署名されることが許可されているドキュメントのみに署名を行う。例えば、要求者８ａはターミナル７において署名要求ＧＵＩ１７を使用してドキュメントが署名されることの要求を準備することが可能である。ドキュメントが署名されることを包含するその要求は、要求者自身の証明書１０ａを使用してパッケージ化させ且つ安全なＡＰＩ２ａを介してＤＳＳ２へ送ることが可能である。ＤＳＳ２はそのドキュメントを構文解析して、そのタイプ及び属性を決定し、且つそのドキュメントを予め定義した会社ドキュメントタイプに従って分類することが可能である。ＤＳＳ２は、その要求者が署名されることが許容されているドキュメントのタイプ及び属性を検索する。次いで、ＤＳＳ２はそのドキュメントのタイプ及び属性をデータベース情報と比較する。ＤＳＳ２は、その従業員がそのタイプ及びそのような属性を有するドキュメントに署名されることが許可されている場合にのみそのドキュメントに署名を行う。要求者８ａがそのドキュメントに署名されることが許可されている場合には、ＤＳＳ２は、本実施例においては、Ｘ−５０９証明書である単一の会社幅証明証２７を使用してそのドキュメントに署名を行う。次いで、ＤＳＳ２は公式に署名したドキュメントを要求者８ａへ返す。次いで、要求者８ａはその署名されたドキュメントをそのまま、又はその署名されたドキュメントを要求者自身の証明書（例えば、Ｘ−５０９証明書１０ａ）を使用して電子的封筒内に封入することにより受信者へ転送することが可能である。代替的に、要求者８ａは、その要求を準備する場合に、例えば、受信者の電子メールアドレスを包含させ、且つＤＳＳ２がそのドキュメントに署名した後に、ＤＳＳ２によって終端受信者へ直接的にその署名されたドキュメントが送られることを要求することが可能である。次いで、ＤＳＳ２は、例えば、電子メールを介して電子的にその署名されたドキュメントを直接的に受信者へ転送することが可能である。
【００２８】
必ずというわけではないが典型的に会社Ｘの外部者である受信者は、次いで、署名を行う会社の署名証明証２７が取り消されていないことを検査することが必要であるに過ぎない。このことは、例えば、証明機関（ＣＡ）を介して行うことが可能である。典型的に、署名システムの証明書はプライベートキーが露顕された場合にのみ取り消される。次いで、署名されたドキュメントの受信者は、そのドキュメントの発信元がそのドキュメントを署名させるための会社Ｘの署名ポリシーによって許可されたものであることを知得し、そうでない場合には、署名システム１はそのドキュメントに署名を行うことはない。
【００２９】
署名システム１を使用することにより、各署名者の許可又は権限レベルをチェックする責任は、それが属するビジネス又は組織体内に維持される。このことは、署名されたドキュメントの受信者の作業を緩和させる。更に、内部企業情報が不必要に外部者へ露顕されることはなく、且つ従業員がその組織体を辞める場合に、その会社の外部から見られる目視可能な効果は存在しない。
【００３０】
上述したように、本システムの署名ポリシーは署名ポリシーデータベース１４内に格納されている。更に上述したように、該ポリシーは、例えば、誰が特定のタイプのドキュメントに署名されることが許可されているかを定義する。例えば、該ポリシーは各要求者が署名させることが可能である特定のタイプのドキュメント（契約、見積書、入札書、内部企業文書等）を制限することが可能である。該ポリシーは、又、各要求者が署名させることが許容されるドキュメントの属性を識別するためのドキュメント属性を定義することが可能である。例えば、該ポリシーは、要求者が署名させることが許容されるドキュメント内に見積価格限界又は購買価格限界を設定することが可能である。署名ポリシーＧＵＩ１１は、署名ポリシーデータベース１４内に格納される署名ポリシーを定義及び修正するために１つ又はそれ以上の許可されたアドミニストレーター１２ａ−１２ｎが本システムへアクセスすることを許容する。
【００３１】
図６はデータベース１４内に格納することが可能な情報のタイプの１例を示している。この例に示されるように、各従業員は、各要求者が署名させることが許容されるドキュメントの属性に関する制限を特定する許可（権限）制限及び購買タイプ制限を有している。各要求者は、又、署名させることが許容されるドキュメントのタイプ（例えば、契約、見積書、入札書等）に制限される。図６は会社Ｘの１つのドキュメントを示すに過ぎないが、データベース１４は署名させることが可能なドキュメントのタイプ及び属性を表わすドキュメントに署名することが許可された会社の各従業員に対しての情報を格納することが可能である。この例においては、各従業員は、許可限界未満の全購入額を有しており且つ購入するための権限が与えられている項目の特定のタイプに対してのみドキュメントに署名させることが許容されるに過ぎない。各従業員は、又、許可されているタイプのものである場合にドキュメントを署名させることが許容されるに過ぎない。勿論、署名ポリシーデータベースは、その他のドキュメントのタイプ及び属性を識別する情報を包含することが可能である。
【００３２】
図２Ｂに戻ると、ドキュメント検証ＧＵＩ２３は、署名システム１が署名されているドキュメントを検証することを要求するために要求者８によって使用することが可能である。即ち、要求者８が署名されているドキュメントを受取ると、該要求者は、その署名されているドキュメントを署名システム１へ転送させてそれを検証させることが可能である。ＤＶＳ６はこの要求に応答して署名されているドキュメントを検証する責任がある。ＤＶＳ６はドキュメントを構文解析し、該ドキュメントのタイプ及び属性を決定し、そのドキュメントが署名されているか否かを決定し、且つそうある場合には、その署名が有効であるか否かを決定する。ＤＶＳ６はそのドキュメント内において見出される属性及びそれらの値のリストを構築し且つこの情報は要求者へ戻すことが可能である。
【００３３】
以下に更に詳細に説明するように、ＳＡＳ４はＤＳＳ２及びＤＶＳ６によって実施されるべく要求された全てのトランズアクション即ち取引の記録を維持する。要求者８はドキュメント履歴ＧＵＩ２１を使用してＳＡＳ４から署名されたドキュメントに関する情報を要求する場合がある。例えば、要求者は署名されたドキュメントが受信者へ送られたか否かを決定し且つ何時送られたかを決定するために、前になされた署名要求のステータスを要求する場合がある。ＳＡＳ４は許可された要求に応答してその記録を検討し且つサーチを行い、且つ要求者に対して適切な応答を与えることが可能である。付加されたセキュリティの場合には、該記録はデジタル的に署名され且つ改竄防止型のものとすることが可能であり、従って許可されていない即ち権限のない当事者がそれに対してアクセスを有することはない。
【００３４】
署名システム１の１実施例の全体的な動作について図３に示したフローチャートを参照することにより説明する。例えば、ある組織内の各従業員（要求者）は、デジタル証明書が与えられており、それは任意の使用可能なパブリックキーインフラストラクチャ（ＰＫＩ）システムを使用して発生される。この実施例の目的のために、各従業員はＸ−５０９証明書が与えられる。ステップＳ２０において、例えば要求者８ａが署名要求ＧＵＩ１７を使用してＤＳＳ２への要求を用意する。例えば、署名要求ＧＵＩ１７はその要求を用意するのに必要な特定の入力に対して要求者にプロンプトを与えることが可能である。その要求は、例えば、特定の価格においての特定の項目に対する購入注文がＤＳＳ２によって署名されることの要求である場合がある。この要求は、署名されるべきドキュメント（購入注文）のコピーを包含する。次いで、その要求者はそれ自身の証明書を使用してその要求に署名し（ステップＳ２２）且つその署名した要求を安全なＡＰＩ２ａを介してＤＳＳ２へ転送する（ステップＳ２４）。受領すると、ＤＳＳ２はデータベース１４からその要求者のパブリックキーを検索し且つその要求の真正性確認を行う。その要求が真正性確認されない場合（Ｎｏ、ステップＳ２８）、その要求が真正性確認されなかったことを要求者へ通知を行い（ステップＳ３０）且つ処理が終了する。ＳＡＳ４もその要求が真正性確認されなかったことをこの時に通知することが可能であり、従って失敗した要求の記録を維持することが可能である。その要求が成功裡に真正性確認される場合（Ｙｅｓ、ステップＳ２８）、ＤＳＳ２は署名されるべきドキュメントを構文解析してそのタイプ及び属性を決定する（ステップＳ３２）。次いで、ＤＳＳ２はそのドキュメントのタイプ及び属性をデータベース１４内に格納されている該要求の許可（権限）限界と比較し（ステップＳ３３）、その要求者は要求されたドキュメントが署名されることが許可されているか否かを決定する。その要求者がそのドキュメントが署名されることが許可されていない場合（Ｎｏ、ステップＳ３４）、その要求者及び／又はＳＡＳ４はそのことが通知され（ステップＳ３２）且つ本手順は終了する。その要求者が許可されている場合（Ｙｅｓ、ステップＳ３４）、ＤＳＳ２はそれ自身のプライベート署名キー２７を使用してその文書に署名を行う（ステップＳ３８）。次いで、その署名されたドキュメントは、その要求に依存して、要求者へ戻されるか又は受信者へ直接的に転送される（ステップＳ４０）。ＳＡＳ４も、そのドキュメントが成功裡に署名されたことを通知させることが可能である。その要求者が、署名されたドキュメントが最終受信者へ直接的にいくのではなく要求者へ戻されることを要求した場合には、その署名されたドキュメントは要求者へ戻される。次いで、該要求者はそのドキュメントをそのまま最終受信者へ送ることが可能であり、又はそのプライベートキーを使用してそれをパッケージ化し（例えば、電子的封筒内に）且つ次いでそのパッケージしたドキュメントを最終受信者へ転送することが可能である。受信されると、最終受信者は送信者のパブリックキーを使用してそのパッケージを開き且つ以下に更に説明するようにＤＳＳ２パブリックキーでそのドキュメントの真正性確認を行う。一方、その署名されたドキュメントが署名システム１から受信者へ直接的に送られた場合には、そのドキュメントはＤＳＳ２パブリックキーを使用して真正性確認を行うことが可能である。
【００３５】
従業員（要求者）は、又、証明書を使用することによる以外その他の態様で識別し且つ真正性確認を行うことが可能である。例えば、図４は別の実施例を示しており、その場合に、各従業員３０ａ−３０ｎはそれらの電子メールアドレス（３２ａ−３２ｎ）によって識別され且つ真正性確認が行われる。従業員は図１０におけるような電子メール要求を用意する。該電子メール要求は、その電子メールが従業員によって送られた日付を表示する「ＤＡＴＥ」フィールドを包含している。該電子メール要求は、又、その電子メールを識別するための情報を与える「ＭＥＳＳＡＧＥ−ＩＤ」フィールドを包含している。「ＦＲＯＭ」フィールドはその電子メール要求を送る従業員に一時的に関連する電子メールアドレスであり且つその従業員を識別するために使用することが可能である。「ＴＯ」フィールドはＤＳＳ４２の電子メールアドレスである。「ＳＵＢＪＥＣＴ」フィールドは、典型的に、電子メールにおける要旨の迅速なる識別を与えるために使用される。この実施例によれば、電子メールの「ＳＵＢＪＥＣＴ」フィールドは、例えば、この電子メールが署名要求として識別する「ＳＩＧＮＡＴＵＲＥ  ＲＥＱＵＥＳＴ」等の予め定義したフレーズを包含することが可能である。メッセージフィールド「ＭＥＳＳＡＧＥ」は、署名し且つ受信者の電子メールを与えた後に、その電子メールが受信者へ直接転送されることの要求を包含するＤＳＳ４２に対して付加的な情報を供給するメッセージとすることが可能である。代替的に、該「ＭＥＳＳＡＧＥ」フィールドは、署名されたドキュメントが従業員要求者へ戻されることを要求する場合がある。署名されるべきドキュメントはファイル添付として電子メールへ添付される。
【００３６】
該電子メールを受信した後に、ＤＳＳ４２は該電子メールの「ＳＵＢＪＥＣＴ」フィールドを構文解析し、それを署名要求として認識し、且つその電子メールアドレスにより要求者を識別する。ＤＳＳ４２は、又、その電子メール要求の「ＭＥＳＳＡＧＥ」フィールドを構文解析し、その署名されたドキュメントが受信者へ直接的に転送されるべきことを決定し、且つ後の参照のためにその受信者の電子メールアドレスを格納する。次いで、ＤＳＳ４２は添付されたドキュメントをダウンロードし且つ構文解析する。データベース３１内に格納されている署名ポリシーを使用して、ＤＳＳ４２は、その従業員が要求されたドキュメントが署名されることが許可されているか否かを決定する。その従業員が許可されている場合には、ＤＳＳ４２は本システムのプライベート署名キー４７を使用してそのドキュメントに署名し、次いでＤＳＳ４２は電子メールを用意し、署名したドキュメントを添付し且つ署名したドキュメントを受信者の電子メールアドレスにおける受信者へ転送する。勿論、その要求が署名されたドキュメントを従業員要求者へ戻すことであった場合には、署名されたドキュメントはその要求の「ＦＲＯＭ」フィールドにおいて表示されるような従業員の電子メールアドレスへ電子メールにより戻すことが可能である。該従業員は、又、ＳＡＳ４４から署名したドキュメントに関する情報を検索し且つＤＶＳ４６を介して署名されたドキュメントを検証するために電子メールを使用することが可能である。
【００３７】
図５は図４に示したシステムの全体的な動作を示したフローチャートである。ステップＳ６０において、従業員が、ＤＳＳ４２がドキュメントに署名することを要求する電子メールを用意する。該電子メールは、アタッチメント即ち添付物として署名すべきドキュメントを包含することが可能である。該電子メールは、ＤＳＳ４２と関連する独特即ち一義的な電子メールアドレスへ指向させることによりＤＳＳ４２へ該従業員により転送される（ステップＳ６２）。受信すると、ＤＳＳ４２は、電子メールの「ＦＲＯＭ」フィールドに示されるような要求者の電子メールアドレスをデータベース３１内に格納されているような格納されている電子メールアドレスのデータベースと比較する（ステップＳ６４）。データベース３１内に格納されているこのタイプの情報の１例を図７に示してある。該データベースは各許可された従業員の名前及び対応する電子メールアドレス、及び各従業員が署名させるべく許可されているドキュメントのタイプ及び属性を包含している。要求者の電子メールアドレスをデータベース内の従業員とマッチさせることが不可能である場合（Ｎｏ、ステップＳ６６）、例えば、本システムを使用するべく許可されていないことを表わす通知が要求者の電子メールアドレスへ戻される（ステップＳ６８）。ＳＡＳ４４も、許可が拒否されたことを通知することが可能であり、該要求の時間、電子メール要求のメッセージＩＤ、要求者の電子メールアドレス等を記録する。次いで、この処理は終了する。その従業員の電子メールアドレスが該データベース内に格納されている場合には、該従業員はドキュメントを署名させるために本システムを使用することが許可されている（Ｙｅｓ、ステップＳ６６）。ＤＳＳ４２は電子メールアタッチメントから署名すべきドキュメントをダウンロードする（ステップＳ７０）。次いで、ＤＳＳ４２がそのドキュメントを構文解析してそのタイプと属性とを決定する（ステップＳ７２）。ＤＳＳ４２はそのドキュメントのタイプ及び属性をデータベース３１から検索されたその従業員に対して許可されているドキュメントタイプ及び属性と比較し（ステップＳ７４）、その従業員がそのドキュメントを署名させることが許可されているか否かを決定する。その従業員がそのドキュメントを署名させることが許可されていない場合（Ｎｏ、ステップＳ７６）、その従業員に通知される（ステップＳ７８）。通知はＳＡＳ４４へも供給することが可能である。次いで、本処理は終了する。その従業員が許可されている場合（Ｙｅｓ、ステップＳ７６）、ＤＳＳ４２はその証明書を使用してそのドキュメントに署名する（ステップＳ８０）。次いで、ＤＳＳ４２は該従業員又は受信者への電子メールを用意し（ステップＳ８２）且つなされた要求に依存してその署名されたドキュメントを従業員又は受信者へ電子メールすることが可能である（ステップＳ８４）。従業員へ戻される場合には、該従業員は公式的に署名されたドキュメントを受信者へ転送する責任を有している。
【００３８】
以上別々の実施例で示したが、図２Ａ及び２Ｂに関して説明したように要求者の証明書真正性確認及び図４に関して説明したような要求者の電子メール真正性確認は１つのシステム内において実現することが可能である。このように、本システムは要求を転送するために使用されるシステムのタイプに依存して、証明書又は電子メールアドレスを介して要求者の真正性確認を行うことが可能である。例えば、従業員がオフィスから離れており且つ適宜のＧＵＩを含むターミナルへのアクセスを有するものでない場合には、その従業員は、尚且つ、電子メールにより本システムへのアクセスを有することが可能である。
【００３９】
図８はデジタル署名システムにより使用するために組織体、会社等に対してデジタル証明書を供給するシステムを示している。デジタル証明機関８６は１つの証明機関として活動する。各会社のＸ５０９証明書（８０，８２，８４）がデジタル証明機関８６のディレクトリィ８８内に格納されている。証明書取消リスト９０もデジタル証明機関８６に供給される。各会社Ｘ，Ｙ，Ｚはデジタル証明機関８６との契約又は取り決めを有しており、該会社がデジタル的に署名したドキュメントを尊重する義務を課している。該契約又は取り決めが期間満了する場合、又はその会社のキー（鍵）が露顕されている場合には、その会社の証明書は取り消され且つ証明書取消リスト９０に加えられる。次いで、その会社に対して新たな証明書が発行されることが必要となる。
【００４０】
デジタル的に署名したドキュメントを受信すると、受信者はデジタル証明機関８６とコンタクトし、そこで証明取消リスト９０をチェックして送信者の会社の証明書が取り消されているか否かを決定する。取り消されていない場合には、該受信者はその会社のパブリックキーが与えられ、従って該受信者により受信したドキュメントを開くことを可能とする。そのドキュメントが送信側従業員自身の証明書を使用して封印されて受信者へ送られた場合には、該受信者は機関８６か又はその従業員の証明書を発行した適宜の機関から送信側の従業員のパブリックキーを獲得する。次いで、該受信者はその従業員のパブリックキーを使用して署名されたドキュメントの封印を解き、次いで、デジタル証明機関８６とコンタクトして取消リストをチェックし、その会社のＤＳＳ証明書２７が取り消されているか否かを決定し且つその会社のパブリックキーを獲得する。次いで、該受信者はその署名されたドキュメントを開くことが可能である。
【００４１】
再度図２Ｂを参照すると、アドミニストレーター１２は、各々、Ｘ５０９証明書を与えることが可能である。次いで、アドミニストレーターは、本システムに関するメインテナンスを実施する場合、本システムの監査を実施する場合等においてそのＸ５０９証明書を使用して真正性確認を行う。各アドミニストレーターが本システムのエリアに対して有するアクセスのレベルを表示するデータベース（不図示）を署名システム１に設けることが可能である。例えば、アドミニストレーターには安全監査サーバー１８へのアクセスを与え且つＤＶＳ８及びＤＳＳ２へのアクセスを拒否することが可能であり、一方別のアドミニストレーターにはシステム全体へのアクセスが与えられる。署名ポリシーＧＵＩ１１に加えて、アドミニストレーターにより使用するためのＧＵＩはドキュメントタイプＧＵＩ１５を包含することが可能である。ＧＵＩ１５は予め定めたドキュメントクラス（例えば、テキスト、ＨＴＭＬ、ＸＭＬ、ＣＳＶ等）のリストを表示し、各クラスは多数の定義された属性を有している。アドミニストレーター１２は、ドキュメントクラスを選択し且つそのドキュメントタイプの名称を特定することによりドキュメントタイプを形成することが可能である。ドキュメントクラスと関連する属性を表示することが可能であり、アドミニストレーターが特定の属性に対しての許容可能な値及び／又は値の範囲を特定することを可能とする。該アドミニストレーターは、又、特定の属性が、そのドキュメントタイプのドキュメントにおいて許されているか、必要とされているか、又は禁止されているか否かを特定することが可能である。全ての情報がドキュメントタイプに対して特定された後に、該アドミニストレーターは署名システム１がドキュメントタイプを形成することを命令することが可能である。アドミニストレーターは、又、ＳＡＳ４への安全なアクセスをアドミニストレーターに与える安全監査ＧＵＩ１３を使用することも可能である。
【００４２】
上述したように、全ての要求及び結果はＳＡＳ４によって記録することが可能である。格納された記録は、例えば、本システムへアクセスする当事者の名前、要求された動作のタイプ、要求の結果、要求を拒否した理由、要求の日付を包含することが可能である。ＳＡＳ４は、又、本システムによって署名された全てのドキュメントのアーカイブを維持することが可能である。図９は適切な権限を有するアドミニストレーターによってＳＡＳ４から検索することが可能な監査記録シートの一部の一例を示している。この監査記録シートは、アドミニストレーターにより、日付により、要求者の名前により、ドキュメントＩＤにより、又は例えば、ドキュメントタイプにより編纂し且つ検索することが可能である。図９に示したようなトランズアクション記録は、動作を要求する当事者の名前、要求された動作、その要求が拒否されたか承認されたかを表わす結果、拒否の理由及び動作の日付等を包含することが可能である。勿論、その他の種々のタイプの情報も記録することが可能である。例えば、要求者の部門、許可額／要求されたタイプ、電子メール要求メッセージＩＤ等を定期的にレビュー又は監査目的のために記録することが可能である。
【００４３】
上述した実施例は、許可されたドキュメントタイプ及び属性を署名すべきドキュメントのものと比較することにより要求者がドキュメントを署名させるのに許可されているか否かを決定するものとして説明したが、変形例が可能である。例えば、ドキュメント署名サーバーにおけるデータベース内にリストされている属性を有し且つタイプを有するドキュメントを除いて、全ての属性を有する任意のタイプのドキュメントを署名することが従業者に許可されているように本システムを調整することが望ましい場合がある。換言すると、データベースは、要求者が署名させることが許されないドキュメントを包含するように調整することが可能である。
【００４４】
上述したシステムは、１つ又はそれ以上の従来の汎用デジタルコンピュータ及び／又は本発明の示唆に基づいてプログラムされたサーバーを使用して便宜的に実現することが可能である。本発明の示唆に基づいて熟練したプログラマーにより適宜のソフトウエアコーディングを容易に用意することが可能である。上述したシステムは、又、応用特定集積回路を用意することにより又は従来の部品回路の適宜のネットワークを相互接続することにより実現することも可能である。
【００４５】
上述したシステムの多数の付加的な修正及び変形が上述した示唆に鑑み可能である。従って、特許請求の範囲を逸脱することなしに、本システムを本明細書に特定的に記載したものと異なって実施することが可能であることを理解すべきである。
【図面の簡単な説明】
【００４６】
【図１】１実施例に基づく署名システムのブロック図。
【図２Ａ】ブロック図。
【図２Ｂ】別の実施例に基づく署名システムの機能図。
【図３】１実施例に基づくデジタル署名を与える方法を示したフローチャート。
【図４】別の実施例に基づくデジタル署名システムの機能図。
【図５】図４に示した実施例に基づくデジタル署名を与える方法を示したフローチャート。
【図６】１実施例に基づくデータベース内に格納されている情報のタイプを示したテーブル。
【図７】１実施例に基づくデータベース内に格納されている情報のタイプを示したテーブル。
【図８】１実施例に基づくデジタル証明期間を示したブロック図。
【図９】１実施例に基づく監査記録を示したチャート。
【図１０】１実施例に基づいて使用される電子メールの１例。
【符号の説明】
【００４７】
１００：署名システム
１００ａ：署名ポリシーデータベース
１０２：要求者
１０３：受信者
【図１】
2004531918.tif 000003
【図２Ａ】
2004531918.tif 000004
【図２Ｂ】
2004531918.tif 000005
【図３】
2004531918.tif 000006
【図４】
2004531918.tif 000007
【図５】
2004531918.tif 000008
【図６】
2004531918.tif 000009
【図７】
2004531918.tif 000010
【図８】
2004531918.tif 000011
【図９】
2004531918.tif 000012
【図１０】
2004531918.tif 000013
【国際公開パンフレット】
2004531918.tif 000014
2004531918.tif 000015
2004531918.tif 000016
2004531918.tif 000017
2004531918.tif 000018
2004531918.tif 000019
2004531918.tif 000020
2004531918.tif 000021
2004531918.tif 000022
2004531918.tif 000023
2004531918.tif 000024
2004531918.tif 000025
2004531918.tif 000026
2004531918.tif 000027
2004531918.tif 000028
2004531918.tif 000029
2004531918.tif 000030
2004531918.tif 000031
2004531918.tif 000032
2004531918.tif 000033
2004531918.tif 000034
2004531918.tif 000035
2004531918.tif 000036
2004531918.tif 000037
2004531918.tif 000038
2004531918.tif 000039
2004531918.tif 000040
2004531918.tif 000041
2004531918.tif 000042
2004531918.tif 000043
2004531918.tif 000044
2004531918.tif 000045
2004531918.tif 000046
2004531918.tif 000047
2004531918.tif 000048
2004531918.tif 000049
2004531918.tif 000050
2004531918.tif 000051
2004531918.tif 000052
2004531918.tif 000053
【国際公開パンフレット（コレクトバージョン）】
2004531918.tif 000054
【国際調査報告】
2004531918.tif 000055
2004531918.tif 000056
2004531918.tif 000057