JP3871300B2 - 企業間での職務ベースの認可のための方法 - Google Patents
企業間での職務ベースの認可のための方法 Download PDFInfo
- Publication number
- JP3871300B2 JP3871300B2 JP2000391424A JP2000391424A JP3871300B2 JP 3871300 B2 JP3871300 B2 JP 3871300B2 JP 2000391424 A JP2000391424 A JP 2000391424A JP 2000391424 A JP2000391424 A JP 2000391424A JP 3871300 B2 JP3871300 B2 JP 3871300B2
- Authority
- JP
- Japan
- Prior art keywords
- job
- transaction
- authorization
- processor
- signature
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000013475 authorization Methods 0.000 title claims description 238
- 238000000034 method Methods 0.000 title claims description 132
- 230000008569 process Effects 0.000 claims description 35
- 239000000284 extract Substances 0.000 claims description 12
- 230000005540 biological transmission Effects 0.000 claims description 5
- 238000012790 confirmation Methods 0.000 description 24
- 101100006844 Schizosaccharomyces pombe (strain 972 / ATCC 24843) cmc4 gene Proteins 0.000 description 23
- 230000007246 mechanism Effects 0.000 description 23
- 238000012795 verification Methods 0.000 description 17
- 238000010586 diagram Methods 0.000 description 14
- 230000006870 function Effects 0.000 description 10
- 230000000694 effects Effects 0.000 description 8
- 238000004364 calculation method Methods 0.000 description 6
- 238000012546 transfer Methods 0.000 description 6
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012797 qualification Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000003213 activating effect Effects 0.000 description 2
- 239000011159 matrix material Substances 0.000 description 2
- TVZRAEYQIKYCPH-UHFFFAOYSA-N 3-(trimethylsilyl)propane-1-sulfonic acid Chemical compound C[Si](C)(C)CCCS(O)(=O)=O TVZRAEYQIKYCPH-UHFFFAOYSA-N 0.000 description 1
- YTAHJIFKAKIKAV-XNMGPUDCSA-N [(1R)-3-morpholin-4-yl-1-phenylpropyl] N-[(3S)-2-oxo-5-phenyl-1,3-dihydro-1,4-benzodiazepin-3-yl]carbamate Chemical compound O=C1[C@H](N=C(C2=C(N1)C=CC=C2)C1=CC=CC=C1)NC(O[C@H](CCN1CCOCC1)C1=CC=CC=C1)=O YTAHJIFKAKIKAV-XNMGPUDCSA-N 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000027455 binding Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 230000007935 neutral effect Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000000153 supplemental effect Effects 0.000 description 1
- 210000003813 thumb Anatomy 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4012—Verifying personal identification numbers [PIN]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/40—Business processes related to the transportation industry
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Development Economics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Marketing (AREA)
- Economics (AREA)
- Computer Security & Cryptography (AREA)
- Entrepreneurship & Innovation (AREA)
- Game Theory and Decision Science (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Human Resources & Organizations (AREA)
- Primary Health Care (AREA)
- Tourism & Hospitality (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Storage Device Security (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は電子商取引に関し、特に、公衆ネットワーク及び専用ネットワークの両方を介して、企業間の取引の承諾を認可及び確認する方法に関する。
【０００２】
【従来の技術】
公衆ネットワークを介する様々な企業間の電子商取引ソルーションの大規模な展開は、セキュリティ問題の慎重な考慮を要求する。これは１例を通じて最もよく説明される。
【０００３】
会社Ａ及び会社Ｂの２社が、申し出、注文または取り消しなどの企業取引（すなわち、個人または組織間の法的に拘束力のある活動）を行う正式協定を有する。会社Ａ及びＢ間の取引タイプの可能なセットは、Ｔ（Ａ、Ｂ）＝｛Ｔ１、Ｔ２、．．．、Ｔｎ｝により表され、ここで例えばＴ∈Ｔ（Ａ、Ｂ）は、
Ｔ→"製品Ｙを１単位当たり価格ＰでＸ単位購入する"
ことを意味するものとする。
【０００４】
セットＴ（Ａ、Ｂ）により表される取引タイプは、一般的であると見なされ、特定の取引が発生する実時間において、取引記述Ｔ（Ａ、Ｂ）で与えられるもの以外の、追加の詳細が提供されなければならない。例えば取引Ｔにおいて、依頼者はＸ、Ｙ及びＰの値を提供し、これは時間の経過に伴い変化し得る。
【０００５】
取引のセットＴ（Ａ、Ｂ）を指定する問題、それらが如何に実行されるか、及び交換されるデータなどは、ＩＳＯ９７３５における電子データ交換（ＥＤＩ：Electronic Data Exchange）構文を用いて解決される（http://www.r3.ch/standards/edifact/index.html参照）。更に、これらの会社はインターネットを介して調整し、取引セットＴ（Ａ、Ｂ）で指定される彼らの一般的な取引を履行しなければならない。
【０００６】
典型的な状況は、会社ＡのユーザＵＡが、会社Ｂの管理下にあるユーザＵＢから、タイプＴ∈Ｔ（Ａ、Ｂ）の取引を受信することである。ここでユーザＵＡが会社Ｂからの依頼、すなわち会社Ａに対して、製品Ｙを１単位当たり価格Ｐ＝１ドルでＸ＝１０００単位生産するようにとの依頼を提示され、更にユーザが公衆ネットワークを介して、ソフトウェア操作を通じて操作すると仮定する。依頼は公衆ネットワークから発信するので、ユーザＵＡが考慮し得る少なくとも３つのセキュリティ問題が存在する。第１は、取引の詳細（Ｘ、Ｙ、Ｐ、ＵＡ、ＵＢ）が機密であり、保全性を考慮して符号化されているかであり、第２は、取引を依頼するユーザＵＢが、実際に会社Ｂにより管理されていることをどのように確認するかであり、第３は、たとえ取引を依頼するユーザＵＢが会社Ｂにより雇われていることが知れたとしても、ユーザＵＢが実際にこうした取引をＸ、Ｙ及びＰの所与の値で依頼することを許可されているかの確認方法が、明確でないことである。
【０００７】
最初の２つの点は、A．Menezes、P．van Oorschot、及びS．VanstoneによるHandbook of Applied Cryptography、CRC press、1996で述べられる標準のセキュリティ・プロトコル及び暗号化アルゴリズムを用いて解決される。特に、公開キー暗号化により、各ユーザＵｘは１つまたは複数の認証（ISO/IEC9594、Information Technology - Open Systems Interconnection - The Directory：Authentication Framework、1993参照）を交付され、それらがデジタル署名を通じて、彼らの識別を証明するために使用される。
【０００８】
ユーザＵＡ及びＵＢが個人的に知り合いである場合、既存の信頼関係だけでユーザＵＡがユーザＵＢからの依頼を認可されたものとして受諾するのに十分であり、実際このようにして多くの企業間取引が現在行われている。この場合、ユーザＵＡ及びＵＢは、将来取引を行うために明確にある信頼関係を確立しているか、ことによると信頼が前の成功取引により獲得されたものである。しかしながら、一般的な電子商取引は、以前に取引関係または信頼関係を有さない人々及び会社を引き合わせ、取引はともかく"自己認可的（self-authorizing）"なものとなる。従来、データ、アプリケーション、資源またはより一般的には単にオブジェクトの認可は、ある形式のアクセス制御を用いて管理された。例えば、D．E．Denningによる"Cryptography and Data Security"、Addison-Wesley Publishing Company、1982を参照のこと。その最も一般的な形式として、各オブジェクトＯに対して各ユーザが有するアクセス権を明示的にリストするアクセス制御マトリックスＭが存在する。多くのユーザＵｉ及びオブジェクトＯｊが存在するとき、アクセス制御マトリックスＭを管理することは困難である。
【０００９】
ことによると、最も一般的なタイプの認可は、取引Ｔを記述する一般的に作成された文書または書式であり、そこでは特定の詳細が依頼者により依頼時に提供され、依頼者は次に、タイプＴの取引または依頼を承認できる一人のまたは複数の人々から、書式上の手書き署名のセットを収集するように要求される。例えば、Ｔは出張依頼書用紙であり、そこでは行き先、滞在期間、予想費用、及び移動方法の提示が要求される。依頼者はこれらの詳細を記述し、依頼書に署名し、用紙を様々な上司に提示して、用紙上の所定の場所に彼らの署名を依頼する。一般に、署名が要求される用紙上の場所は、課長や部長またはＣＥＯなどの署名を依頼される人々の職務によりラベル付けされる。
【００１０】
認可のこの用紙は"書式署名モデル（form-signature model）"と呼ばれたり、共同署名または共同署名データによる認可と呼ばれる。例えば、出張依頼取引（Ｔ＝"出張依頼"）は、依頼者、依頼者の課長、次に依頼者の部長の署名を要求する。一旦要求された署名が収集されると、依頼者は署名文書により取引を認可する。すなわち、例えば旅行業者にフライトやホテルを予約させる。通常、旅行業者は、戻り日が出発日よりも後であること、或いは費用の限界を超えていないことなどの一般的なチェックを除き、出張依頼の詳細の確認に関与しない。旅行業者にとって重要なことは、依頼書に付随する署名のセット、及びこれらの署名により表される職務である。多額の資金を伴わない多くの事務作業にとって、書式署名モデルは業務の認可を与えるのに十分である。しかしながら、より多額の資金または資源を取引に委ねられる場合、各署名が信頼できるものであり、署名の収集が実際にその会社を結びつけることが確実であることが重要となる。これらの場合、下級の社員が取引を認可する権限を有することを確認するために、企業の当局者（すなわち、社長、監査役、または他の役員などの取引管理者）からあらゆる取引の直接承認を得ることが必要となる。
【００１１】
電子商取引の書式署名モデルは、１）業務を遂行するために要求される業務及び情報（日付、価格、名前など）の電子表現と、２）署名機構と、３）電子業務データに付随する署名を、その業務のための認可を与える特権に関連付ける機構とを含む。一般に１）及び２）は、現在の方法及び技術を用いて直接解決されるが、３）は十分に解決されていない。１）及び２）に関して、用紙ベースの書式がＨＴＭＬまたはワープロ文書として電子的に表され、業務Ｔに関して、Ｄ（Ｔ）が業務Ｔの電子書式またはテンプレートを示すものとする。Ｔが"出張依頼"と仮定すると、例えばＤ（Ｔ）は出張の詳細について要求するＨＴＭＬ文書であり得、職務のリストが存在し得る。そして、これらの職務を演ずるユーザは出張依頼詳細に署名しなければならない。更に、ＲＳＡまたはＤＳＳなどのデジタル署名を提供する幾つかの技法が存在し、従って、電子商取引において書式署名モデルを実現する基本ツールが使用可能である。電子商取引書式署名モデルにおいてより困難な部分は、収集された署名のセットが業務の認可を意味することを決定または確認することである。
【００１２】
ユーザＵがデジタル的にデータに署名する場合、ユーザＵは公開キーＰｕｂ（Ｕ）及び私用キーＰｒｉ（Ｕ）を有することを意味する。Ｐｕｂ（Ｕ）は、ここではＣｅｒｔ（Ｕ）として示される証明書内に記憶される。証明書Ｃｅｒｔ（Ｕ）は公開データベースまたはディレクトリ内に記憶され、誰もがそれを検索して、私用キーＰｒｉ（Ｕ）を有するユーザＵにより生成されたと言われる署名を確認できる。証明書Ｃｅｒｔ（Ｕ）は、ユーザＵの１つまたは幾つかの名前または識別子を含み、従ってユーザＵは署名を生成したユーザとして、一意的に識別される。しかしながら、文書Ｄ（Ｔ）上の署名のセットを調査することにより、別のユーザが取引Ｔを依頼しているかを確認する際、重要な点は、誰が各署名を生成したかではなく、彼らがＴを認可する権限を有するか否かである。
【００１３】
従って、企業の当局者をあらゆる取引を確認する必要性から解放し、不確かな公衆ネットワーク上において、標準のセキュリティまたは暗号化プロトコルを用いて、電子商取引契約の認可の効率的な認可及び確認を可能にする方法が必要とされる。更に、それぞれの会社の決定構造に関する最小の情報を明らかにする企業間認可を実行する方法が必要とされる。
【００１４】
【発明が解決しようとする課題】
本発明の目的は、取引が適切に認可され、従って履行可能なように保証する便利でコンピュータ化された手段を提供することにより、電子商取引を助成することである。
【００１５】
本発明の別の目的は、ハッシュ・テーブルが使用される場合に空間要求を低減し、また認可ツリー内の決定プロシージャ情報を曖昧化した上で、取引の認可を可能にすることであり、従って本発明の方法は、特に企業間取引において有用である。
【００１６】
【課題を解決するための手段】
複数の相互接続されるコンピュータ及び複数の資源を含むコンピュータ・ネットワーク上で動作する、取引認可方法が提供される。各コンピュータはプロセッサ、メモリ及び入出力装置を含み、各資源は少なくとも１つのコンピュータに動作上接続され、プロセス・フローにおいて少なくとも１つの活動を実行する。本方法は、認可に関連付けられる少なくとも１つのタイプの職務証明を抽出し、職務証明そのものが信頼できるか否かを確認することにより、取引の電子認可を検証可能に編成する。本方法は、職務にもとづく認可構造を提供することにより、取引に関する各々の及びあらゆる署名を個々に認可する必要性を排除する。この構造は、取引の認可を確認するために公衆ネットワーク上でアクセス可能である。
【００１７】
本方法は企業内及び企業間の両方の状況において適用可能である。なぜなら、本方法は匿名の証明書により表される、職務にもとづく匿名の認可決定を行うからである。このように、取引の信頼性を確認するとき、社員の識別が明かされる必要がない。
【００１８】
更に、本方法は特定の取引に対して認可ツリーを用いることにより、そのタイプの取引を認可できる職務の組み合わせを決定する。
【００１９】
企業間認可に関わる本発明の別の特徴として、認可ツリーのハッシュド・バージョンが使用され、それにより会社の承認構造に関する最小の情報を明かすことにより、所与のユーザが取引を行うことを認可される証明を提供する。このように、本方法は会社の決定構造の詳細を曖昧化する態様において、その決定構造の確認を可能にする。
【００２０】
【発明の実施の形態】
図１を参照すると、取引認可方法（ＴＡＭ：Transaction Authorization Method）２が、電子商取引において契約４の有効性を保証する手段を提供し、ここでこうした契約はそれらの有効性が容易に確認できるように構築される。
【００２１】
ＴＡＭ２は、分散ワークフロー管理システム６内で動作するメッセージ交換機構を有する。方法２は、１）依頼１０を認可するために、ユーザ８によりアクセス可能であり、２）幾つかのデータベース７０、８２、９６または２０２（図１１参照）へのアクセスを有し、３）ユーザに接触して、署名１８を要求する属性を有する。
【００２２】
ＴＡＭ２は、コンピュータ・ネットワーク２５または３１（図２参照）を介する分散システム２１内のコンピュータ・システム２０上で動作する。ここで分散システム２１は、複数の相互接続コンピュータ２２及び複数の資源２３を含む。ＴＡＭ２はコンピュータ読取り可能媒体上で符号化されて、コンピュータ・システム２０上で、またはイントラネット２５またはインターネット３１上のコンピュータ・システム及び１つ以上のサーバ（５４ａ、５４ｂ）間で動作する。
【００２３】
コンピュータ・システム２０は一般に、コンピュータ２２、表示装置２４、キーボードなどの入力装置２６、１次記憶装置３０、及び２次記憶装置３２を含む。本発明のＴＡＭ２により符号化されたソフトウェアのローディングの後、また場合によっては、インターネット・エクスプローラ５．０などのブラウザを通じてサーバ２５または５４をアクセスした後、表示装置２４がグラフィカル・ユーザ・インタフェース（ＧＵＩ）３４を表示することにより、本方法に関連付けられるテキスト及びグラフィックスのユーザへの表示を容易にする。表示装置２４はプリンタ及びコンピュータ表示画面を含み、後者にはＣＲＴ、ＬＥＤ表示装置、ＬＣＤ、フラット・スクリーン、スクリーン・フォーン（screen phone）、及びプロジェクタなどが含まれる。入力装置２６は多数から成り、キーボード及びポインティング・デバイスを含む。ポインティング・デバイスには、左マウス・ボタン２８及び右マウス・ボタン２９を有するマウス２７、トラック・ボール、ライトペン、サムホイール、デジタイジング・タブレット、音声認識ソフトウェアを使用するマイクロフォン、及びタッチ・スクリーン及びパッドが含まれる。
【００２４】
各資源２３はコンピュータ２２の少なくとも１つに動作上接続され、本方法２のプロセス・フローにおいて、少なくとも１つの活動を実行する。資源２３には、プリンタ、データベース、特殊用途サーバ、セキュリティ装置、モデムなどが含まれる。
【００２５】
ＧＵＩ３４はデータ入力及びＴＡＭ２の制御のための入力フィールド、並びにステータス及び他の情報の表示のための出力ウィンドウを提供し、ワークフロー・システムの管理及び操作を容易にする。ＴＡＭ２は以下で詳述するように、取引に関連する情報を含むデータベース３３をアクセスする。
【００２６】
コンピュータ２２はＣＰＵ３６、並びに当業者には周知の他のコンポーネントを含む。これらのコンポーネント及びそれらの相互作用についての詳細については、米国特許第５７８７２５４号を参照されたい。２次記憶装置３２はＴＡＭ３２をサポートし、好適にはＨＴＴＰ準拠であり、同様に多数のインターネット・アクセス・ツールをサポートする。ＣＰＵ３６は、バス４２に接続される入出力サブシステムなどのインタフェース４１を介して、１次記憶装置３０からコンピュータ命令をフェッチする。コンピュータ２２は、例えばＩＢＭの製品である"ＩＢＭアプティバ"・コンピュータ、或いはインテル社のＸ８６またはPentium（商標）シリーズ・プロセッサまたは互換プロセッサにもとづく、ＩＢＭ ＰＣコンピュータ・システムと互換の任意の他のコンピュータ、若しくは他の好適なコンピュータである。ＣＰＵ３６はオペレーティング・システムを使用し、これは使用するハードウェアに応じてＤＯＳ、"ウィンドウズ３．Ｘ"、"ウィンドウズＸＸＸＸ"、"ＮＴ"、"ＯＳ／Ｘ"、"ＡＩＸ"、"ＬＩＮＵＸ"、または任意の他の好適なオペレーティング・システムである。ＣＰＵ３６はこれらのフェッチされたコンピュータ命令を実行する。これらの命令の実行は、ＣＰＵ３６がデータを取り出したり、データを１次記憶装置３０に書込んだり、ＴＡＭ２の統計表示などの情報を１つ以上の表示装置２４上に表示したり、１つ以上の入力装置２６からコマンド信号を受信したり、データを２次記憶装置３２または集合的にコンピュータ・ネットワーク２５（図２参照）を形成する他のコンピュータ・システムに転送したりすることを可能にする。当業者であれば、１次記憶装置３０及び２次記憶装置３２が、任意のタイプのコンピュータ記憶装置を含み得ることが理解できよう。それらにはＲＡＭ、ＲＯＭ、特定用途向け集積回路（ＡＳＩＣ）、及びＣＤ−ＲＯＭなどの磁気及び光記憶媒体を含む記憶装置が含まれる。
【００２７】
図３を参照すると、電子商取引の間にオンラインで実行される取引４０の多くのクラスが存在する。この開示では、各取引４０が依頼者４２と検証者または値提供者４４との間で発生する。依頼者４２は製品またはサービス４６を所望し、値提供者４４は、依頼者の依頼書５２を表す電子文書５０が適切に認可されていることを確かめたいと思う。すなわち、値提供者４４は文書５０の信頼性を確認したいと思う。ほとんどの一般的な状況では、依頼者４２及び検証者４４は同一の会社により雇用されていることも、そうでないこともある。
【００２８】
例えば、依頼書５２に関連付けられる文書５０は、製品またはサービスの契約であり、例えば要求元会社の社員から会社の旅行業者への、または出張のための必要資金が使用可能か否かを判断するために、社員から同一会社の金融当局者へ提出される出張依頼書５４（図６参照）である。
【００２９】
図４を参照すると、本方法のより詳細なフロー図が示される。そこでは、ＴＡＭ２が次のステップを実行する。第１のステップ６０で、従業員が取引４０をＴＡＭ２から要求する。第２のステップ６２で、ＴＡＭ２が取引４０の詳細６６のＨＴＭＬ表現６４を、デジタル文書データベース（ＤＤＤ：Digital Document Database）７０（図７参照）から要求する。第３のステップ７２で、デジタル文書データベース７０が取引詳細６６のＨＴＭＬ表現６４をＴＡＭ２に返却する。第４のステップ７４で、ＴＡＭ２が取引当局（ＴＡ：Transaction Authority）８０の職務証明書７６を、職務証明書データベース（ＲＣＤ：Role Certificate Database）８２から要求する。職務証明書データベースは、匿名の職務証明書から成り（ここで匿名性は、ユーザの名前が証明書内に含まれていないことによる）、これはＴＡ８０の職務証明書を含む（これについては以下で詳述する）。第５のステップ８４では、職務証明書データベース８２がＴＡ８０の職務証明書７６を返却し、ＴＡＭ２がデジタル文書データベース７０から返却された取引依頼詳細６０のＨＴＭＬ表現６４上のＴＡの署名１２６を確認する。第６のステップ８６では、ＴＡＭ２がＨＴＭＬ取引詳細６６を依頼者４２に返却する。第７のステップ９０では、依頼者がＨＴＭＬ表現６４を見て、指定された詳細（例えば名前、行き先、費用など）を完成し、完成されたＨＴＭＬ表現６４を署名し、残りの署名を収集するために、署名済みのＨＴＭＬ表現をＴＡＭ２に返却する。第８のステップ９２では、ＴＡＭ２が取引の認可構造（ＡＳ：Authorization Structure）９４を、認可構造データベース（ＡＳＤ：Authorization Structure Database）９６から要求する。返却された認可構造９４がＴＡ８０により事前署名され、署名がＴＡＭ２により確認される。ＴＡＭ２は職務名１０２の承認セット１００及び関わるユーザの収集を選択して、これらの職務名に署名する。第９のステップ１０４では、ＴＡＭ２が一般社員依頼者４２の署名１０６を有する取引依頼書５２の取引詳細６６を、承認セット１００に対応する職務を有する他の者に転送し、承認セット１００に含まれる各々の職務の署名を収集する。例えば、課長及び部長の署名が収集され、各々が文書５４のそれぞれの職務欄に署名される。第１０のステップ１１０では、ＴＡＭ２が承認セット１００の各メンバの職務証明書７６及びそれぞれの署名を要求する。第１１のステップ１１２では、ＴＡＭ２が署名１０６及び職務証明書７６を含む文書５４を依頼者４２に転送する。こうして、取引４０の有効性を確認するために要求される全ての認可詳細６６を含むデジタル文書１１４が作成される。ステップ１１６では、任意的に、本方法２は署名済み文書１１４を確認する。
【００３０】
図１０を参照すると、本方法２において、匿名職務証明書７６は署名確認キー１２０と職務名１２２との関連を示す。これは署名１０６の確認キー１２０と名前（図示せず）との関連を示す、ＩＴＵ−Ｔ Ｘ．５０９（１９９７Ｅ）（以下Ｘ５０９と記す）で述べられる標準の証明書とは異なる。より詳細には、Ｘ５０９は公開キーと名前との関連であり、公開キーは暗号化及び署名確認の両方のために使用される。しかしながら、本方法２はユーザが職務資格１２２において暗号化を実行することには関わらず、ユーザが職務資格において署名１０６を生成することに関するものである。職務証明書７６は証明書の所有者に関連する情報を有さないことにより匿名である。証明書Ｃｅｒｔの所有者は、証明書内に埋め込まれた公開キーに対応する私用キーを有するユーザとして暗に定義される。
【００３１】
職務証明書７６は本方法２において重要な役割を果たす。ここで任意の会社Ｃにおいて、明確な職務ＲＣ＝｛Ｒ１、Ｒ２、．．、Ｒｍ｝のセットが存在し、会社Ｃ内の各ユーザＵが１つまたは複数の職務ＵＲ⊆ＲＣを割当てられると仮定する。本方法２の目的上、各ユーザは彼らの名前、公開キー及び他のフィールドを含み、ローカル認証局ＣＡ（certificate authority）により署名されたＸ．５０９公開キー証明書ＣｅｒｔＣＡ（Ｕ）を有するものとする。Ｘ．５０９証明書は、電子メール・アドレス、代替名、及び方針情報などの一般情報のための拡張フィールドを含むので、指定された職務１２２が拡張フィールドとして含まれることは可能である。しかしながら、証明書は名前フィールドを含むので、職務１２２及び証明書の所有者は明示的にリンクされる。ＩＥＴＦワーキング・グループも職務１２２、グループ・メンバシップ、及び名前への保全許可（security clearance）などの属性を結びつける属性証明書（ＡＣ：attribute certificate）の概念を現在開発中である（S．Farrellによる"An Internet Attribute Certificate Profile for Authorization"、August 20、1998参照）。しかしながら、属性証明書は公開キーを含まないので、属性証明書内で指定される名前は、既存のＸ．５０９ＣｅｒｔＣＡ（Ｕ）内で指定される個人Ｕに関する補足情報を提供するように意図される。証明書保持者の名前はＡＣ内に含まれるので、名前及び職務は直接リンクされる。本方法２の目的上、職務証明書７６及び属性証明書の両方が受け入れ可能である。なぜなら、本方法は職務１２２を含む証明書を使用してアクションを認可するからであるが、本方法では、職務がそれが割当てられるユーザに直接関連付けられないことが望ましい。
【００３２】
従って、本方法２はユーザＵに対して、匿名職務証明書７６（ＣｅｒｔＣＡ（Ｕ、Ｒ））を使用し、これは次の変更を有するＸ．５０９ｖ３証明書である。すなわち、１）名前フィールドが架空のユーザを表す、２）ユーザＵの職務１２２を含む拡張フィールドが存在する、３）Ｃｅｒｔ（ｕ）からＣｅｒｔ（ｕ、Ｒ）への順方向参照をを含む拡張フィールドが存在する。
【００３３】
順方向参照は、例えばＥ（Ｃ、Ｕ、パスワード）の形式を取り、これは会社Ｃの公開キーまたはローカル認証局の公開キーによる、ユーザＵ及びパスワードの連結の公開キー暗号化を示す。順方向参照は単に、会社が職務証明書の所有者を識別するための機構であり、本方法にとって他の重要性は有さない。ユーザＵが幾つかの職務１２２を有する場合、各職務に対する職務証明書７６が存在する。ここで重要な点は、各職務証明書が公開キー及び対応する私用キーを有し、それによりユーザが彼らの資格において署名を生成することである。従って、各ユーザは少なくとも２つの証明書、すなわち、彼らの名前を公開キーに結びつける標準のＸ．５０９ｖ３証明書ＣｅｒｔＣＡ（Ｕ）、及び彼らの職務を公開キーに結びつける匿名職務証明書７６（ＣｅｒｔＣＡ（Ｕ、Ｒ））を有する。ＣｅｒｔＣＡ（Ｕ）は順方向参照によりＣｅｒｔＣＡ（Ｕ、Ｒ）にリンクされるが、所与のＣｅｒｔＣＡ（Ｕ、Ｒ）に対して、ユーザＵのＣｅｒｔＣＡ（Ｕ）または識別を決定する明白な方法は存在しない。本方法２の目的上、職務証明書７６（ＣｅｒｔＣＡ（Ｕ、Ｒ））に関連付けられる私用キー１２４により生成される署名１０６は、職務署名１２６として定義される。
【００３４】
従って、ユーザが取引４０上に署名１２６を生成すると、検証者１３０は、例えばユーザが課長かそれとも部長か、或いはこの職務が所与の業務に如何に関係するかなど、ユーザが社内で有する職務１２２に関心を持つ。ユーザによって引き受けられる職務１２２だけが、業務が認可されたか否かを確認する上での関心事であるので、ユーザの識別や名前は実際には重要ではない。
【００３５】
図５を参照すると、確認作業を達成するために、ＴＡＭ２は作成され署名済み文書１１４の確認を可能にする確認補助方法１１６を含む。第１のステップ１３２では、職務署名１２６が文書１１４上でチェックされる。第２のステップ１３４では、取引が認可された取引であることを保証するために、取引タイプ自身がチェックされる。第２のステップ１３４のサブステップ１３６では、職務名１２２が職務証明書７６から抽出される。第２のステップ１３４の第２のサブステップ１４０では、職務名１２２がハッシュされる。第２のステップ１３４の第３のサブステップ１４２では、取引４０の計算されたハッシュ値が、認可構造（ＡＳ）９４内で受信された取引４０の値に等しいことを保証するために、チェックが行われる。第２のステップ１３４の第４のサブステップ１４４では、取引４０上のＴＡ８０の署名１２６が正しいことを保証するためにチェックが行われる。正しい場合、取引４０が確認され、この事実の通知が依頼者４２に送信される。
【００３６】
このように、確認は単に署名をチェックするプロセスであり、検証者１３０は取引４０の詳細６６には関わらない。ここで署名者が取引４０の詳細６６をチェックし、これらの詳細が所与のタイプＴの取引に関する会社方針から外れる場合、彼らの署名１０６を保留するものとする。この仮定は再度、検証者１３０が一般に、署名済み用紙の詳細にではなしに、提供される署名により関心を寄せる書式署名モデルに固有である。
【００３７】
この残りの詳細説明では、出張依頼取引がＴＡＭ２のステップを説明するために使用される。
【００３８】
図６を参照すると、ＩＢＭ出張依頼書５４の構造が示される。従来、書類文書が、特に出張依頼の承認などの様々な取引に使用されてきた。取引当局（ＴＡ）８０（図７参照）の業務は、これらの書類用紙をデジタル文書６４（幾つかの可能な書式が存在するが、好適にはＨＴＭＬ形式）に変換することである。各書式に対してＴＡ８０は取引詳細６６と見なされるもの、及び認可情報１４６と見なされるものを分離する。出張依頼書５４では、取引詳細６６は依頼者名、行き先、旅費、出発日などが含まれる。書類用紙及びそれから構成されるＨＴＭＬ文書６４上では、ほとんどの取引詳細６６は単に、依頼者４２により提供される情報のプレースホルダである。
【００３９】
認可詳細１４６は一般に、取引４０を連帯で認可するように要求される人達の職務１２２のリストから成る。書類用紙の認可とは、通常、それに署名することを意味し、ＨＴＭＬ文書６４では、認可詳細６６は、どの職務１２２のどの人間が取引４０を認可するかを示す。出張依頼書５４では、出頭依頼を認可する承認セット１００に対応する認可詳細６６が、依頼者１６５、課長１６７、及び部長１６９の電子署名１０６から成る（図９参照）。これは依頼者４２、及び課長の職務１２２の人間、及び部長の職務１２２の人間が、デジタル的にＨＴＭＬ書式６４に署名しなければ、それが認可されないことを意味する。
【００４０】
図７を参照すると、出張依頼書６４に対してＴＡ８０は出張取引詳細６６をＨＴＭＬで作成し、これらの詳細に署名し、署名済み文書をデジタル文書データベース７０に記憶する。従って、ＴＡ８０の職務を、関連署名確認キー１２０を含むＴＡ職務証明書７６（図８参照）を交付された人間に割当てることが必要である。ＴＡ８０はまた、突き合わせ署名キー１５０を別に交付される。ＴＡ８０署名キー１５０と一緒に生成される署名は、ＴＡ職務証明書７６内の確認キー１２０と共に確認される（図１０参照）。
【００４１】
ＴＡ８０は出張依頼書６４の認可構造９４を生成し、文書に署名し、次に認可構造データベース９６に記憶する。認可構造９４は、取引４０を認可するために使用される職務を表す。
【００４２】
デジタル文書データベース７０及び認可構造データベース９６内の情報は、それ自体秘密であることを要求されない。しかしながら、情報の保全性が保護されることは必要である。この理由から、ＴＡ８０はこうした文書に署名しなければならない。
【００４３】
図８を参照すると、認可構造（ＡＳ）９８が如何に生成されるかに関する詳細は、本発明の主題でない社会的及び戦略的管理要因に依存する。認可構造９８の主な属性は、その構造が承認セット１００の概念に依存することである。承認セット１００が意味する内容を説明するために、セットＰＴ、１＝｛Ｕ、Ｍ、ＤＨ｝が取引Ｔの承認セットとする。この例では、取引Ｔが１つの承認セットだけを有するが、一般には、取引はＰＴ、１、ＰＴ、２、．．．、ＰＴ、ｊにより示される幾つかの承認セットを有する。各承認セット１００は職務１２２のセットを含み（すなわち、ＰＴ、ｉ⊆Ｒ、潜在的に複数セット）、任意のユーザＵが、Ｄ（Ｔ、Ｕ）により表される取引Ｔに対して認可されることを意味する。Ｔのある承認セットＰＴ、ｉ＝｛Ｒ１、Ｒ２、．．．、Ｒｍ｝に対して、職務Ｒ１、Ｒ２、．．．、Ｒｍのｍ人のユーザが、彼らのそれぞれの証明書を用いてＤ（Ｔ、Ｕ）に署名する。
【００４４】
この時、承認セット１００すなわち（ＰＴ、ｉ）は、職務１２２のセットを表し、それらの連帯当局者が、タイプＴの取引４０を認可するために十分であると見なされる。ツリー１５４（図９参照）は、取引Ｔの承認セット１００すなわちＰＴ＝｛ＰＴ、１、ＰＴ、２、．．．、ＰＴ、ｋ｝を表すために使用される。書式署名モデルに関して、ＰＴはタイプＴの取引を認可するための決定プロシージャを示す。Merkleによる米国特許第４３０９５６９号は、こうしたツリー１５４の一般的な使用について述べている。
【００４５】
図９を参照すると、各取引タイプＴに対して認可ツリー（ＡＴ：auhorization tree）１５４は、ルートからの第１のレベル１６０に、ｋ個のノード１５６が存在するように生成され、これらのノードは取引タイプＴに対するｋ個の承認セット１００、すなわちＰＴ＝｛ＰＴ、１、ＰＴ、２、．．．、ＰＴ、ｉ｝に対応する。第２のレベル１６４のノードはリーフ１６６であり、各承認セット１００の職務１２２を表す。
【００４６】
取引Ｔに対する承認セット１００（ＰＴ）が、ＰＴ、１＝｛Ｒ１、Ｒ２｝及びＰＴ、２＝｛Ｒ３、Ｒ４、Ｒ５｝及びＰＴ、３＝｛Ｒ６｝の場合、ＡＴ１５４は２つのレベルを有する。第１のレベル１６０は、３つのノード１５６によるＰＴ、１、ＰＴ、２及びＰＴ、３を表し、各ＰＴ、ｉ１００は、承認セット内の職務１２２の数と同一の数のリーフ１６６を有する。従って、例えばＰＴ、１（１００）は図９に示されるように、Ｒ１及びＲ２を表す２つの子（両方ともリーフ１６６）を有する。
【００４７】
少なくとも１つの承認セット１００すなわちＰＴ、ｉにおいて、ＰＴ、ｉ内の各職務１２２の署名が獲得される場合、取引４０は認可されたと見なされるので、ＰＴ、ｉを表すノード１５６は"ＡＮＤ"ノード１７０と見なされ、ＡＴ１５４のルート１６２は"ＯＲ"ノード１７２と見なされる。ＡＮＤノード１７０は、ノードの全ての子が依頼書Ｄ（Ｔ、Ｕ）に同意しなければならないことを意味し（承認セット１００内の全ての職務１２２が署名しなければならない）、ＯＲノード１７２は少なくとも１つの子が依頼書Ｄ（Ｔ、Ｕ）に同意しなければならないことを意味する（少なくとも１つの承認セットが連帯署名しなければならない）。或いは、ＡＴ８０は、取引４０を認可できる職務１２２の離接的表現（disjunctive representation）と解釈されてもよい。
【００４８】
図８を参照すると、出張依頼書６４では、承認セット１００が依頼者４２、課長及び部長から成る。これらは以下で詳述される。
【００４９】
図１０を参照すると、認可構造（ＡＳ）９８は承認セット１００にもとづき、これらのセットが指定の職務１２２からなるので、各ユーザは職務名により指定される１つ以上の職務を交付される。ユーザは彼らの資格において、所与の職務名１２２の下で署名することを要求されるので、ユーザは次に職務証明書７６を交付される。職務証明書７６は職務名１２２、署名確認キー１２０、職務証明書７６上の役職者署名１０６、及び他の管理情報（職務証明書の交付日時、満了日時など）を含む。ユーザが職務証明書７６を与えられるとき、職務証明書内の確認キー１２０に合致する対応する署名キー１５０も与えられる。実際、ユーザは対応する署名キー１５０を所有することにより、彼が所与の職務証明書７６を所有することを証明する。結果的に、署名キー１５０はそれが交付されるユーザにより、秘密にされなければならない。交付される職務証明書７６の各々もまた、職務証明書データベース８２（ＲＣＤ）に記憶される。
【００５０】
以上で、本方法２の初期化が完了する。要するに、初期化は書類用紙からデジタル文書６４への変換と、取引当局８０による署名を含む。更に、ＴＡ８０が各取引４０に対する認可構造９８（ＡＳ）を決定し、この認可構造にも署名する。認可構造９８内の情報は指定された職務にもとづき、職務当局１８０は各ユーザに１つ以上の職務証明書７６を交付する。職務当局１８０から交付される指定職務１２２のセットが、認可構造９８の構造内のＴＡ８０により使用される。
【００５１】
次に図１１を参照しながら、出張依頼書６４を認可する例について述べる。ここでユーザが出張依頼書を作成し、それを認可してもらいたいと仮定する。出張認可のユーザすなわち依頼者４２は、これをＴＡＭ２の支援を通じて達成する。好適な実施例では、ＴＡＭ２は会社のイントラネット２５上のサーバ・アプリケーションであり、ブラウザなどのＷｅｂインタフェースを介して接続され得る。従って、ユーザはそのＵＲＬを介してＴＡＭ２と連絡でき、自身が出張依頼書６４を作成したいことを示す。ここで、出張依頼書の依頼者４２の職務は一般社員である。
【００５２】
第１のステップ１８２では、ユーザすなわち社員４２がＴＡＭ２から、出張依頼取引４０を要求する。ＴＡＭ２はユーザ４２から出張依頼書５２を受信し、デジタル文書データベース７０と連絡を取り、このクラスの取引４０の取引詳細６６のコピーを獲得する。デジタル文書データベース７０はＨＴＭＬで表された詳細６６をＴＡＭ２に返却する。ここでＨＴＭＬは事前に取引当局（ＴＡ）８０により署名済みである。
【００５３】
第２のステップ１８４では、ＴＡＭ２が取引詳細６６のＨＴＭＬ表現６４をデジタル文書データベース７０から要求する。ＨＴＭＬ詳細が正しいか否かをチェックするために、ＴＡＭ２はＴＡ８０の職務証明書７６を職務証明書データベース８２（これはまた一般社員１６５、課長１６７、部長１６９及び他の職務の職務証明書、並びに会社内の異なるレベルの管理を含む）から要求し、次に署名１０６を確認する。署名が適正な場合、ＴＡＭ２は継続する。
【００５４】
第３のステップ１８６では、デジタル文書データベース７０が出張依頼取引詳細６６のＨＴＭＬ表現６４を返却する。
【００５５】
第４のステップ１９０では、ＴＡＭ２がＴＡ８０の職務証明書７６を、職務証明書データベース８２から要求する。第５のステップ１９２では、職務証明書データベース８２がＴＡ８０の職務証明書７６を返却し、ＴＡＭ２がデジタル文書データベース７０から返却された、取引依頼詳細６６のＨＴＭＬ表現６４上のＴＡの署名１０６を確認する。
【００５６】
第６のステップ１９４では、ＴＡＭ２がＨＴＭＬ取引詳細６６を依頼者４２に返却し、依頼者のブラウザが詳細をＨＴＭＬ形式６４として表示する。そしてこれは入力を要求する。要求される入力は、出張依頼書５４の取引詳細６６の構成要素となる。第７のステップ１９６では、依頼者４２がＨＴＭＬ表現６４を見て、指定された詳細６６（例えば名前、行き先、費用など）をブラウザを通じて完成し、完成されたＨＴＭＬ表現６４に署名する。ユーザすなわち依頼者４２は、彼らの職務すなわち"一般社員"を示す職務証明書７６に署名済みである。
【００５７】
第８のステップ２００では、ＴＡＭ２が署名済みの依頼者入力（すなわち署名済みのＨＴＭＬ表現）をユーザ４２から受信し、次に認可構造データベース９６と連絡し、出張依頼取引４０の認可構造９８を獲得する。ＴＡＭ２はデータベース９６から認可構造９８を受信し、構造上のＴＡ８０の署名１０６をチェックする。認可構造９８からＡＭ２は職務名１２２の承認セット１００、並びにこれらの職務名に署名するために接触するユーザの収集を抽出する。この場合、一人の一般社員の依頼者４２、課長及び部長しか存在しない。
【００５８】
この時点で、ＴＡＭ２の目的は、承認セットを構成する連帯職務１２２の人達からの署名の収集を獲得することである。依頼者４２は既に職務"一般社員"としての署名１０６を提供しており、ＴＡＭ２は職務欄の"課長"１６７及び"部長"１６９に、２つの署名を獲得しなければならない。
【００５９】
ＴＡＭ２はユーザ及び彼らの職務１２２をリストするユーザ・ディレクトリ・データベース２０２をアクセスして、例えば一方の署名１０６として、ユーザ"John Brown"を職務"課長"として、また他の署名として、ユーザ"Sue Smith"を職務"部長"として選択する。
【００６０】
第９のステップでは、ＴＡＭ２が取引依頼詳細６６を一般社員依頼者４２の署名１０６と一緒に、依頼者の課長John Brownに転送する。John BrownのブラウザはＨＴＭＬ出張用紙６４を、依頼者の記入済みの取引詳細６６と一緒に表示し、また依頼者４２により提供される署名１０６が正しい旨を示す。John Brownは次に出張依頼書５４を認可するか否かを決定する。認可が与えられる場合、John Brownは出張依頼書５４のＨＴＭＬと、依頼者４２により提供された出張詳細６６とに署名し、それらがＴＡＭ２に返却される。
【００６１】
第１０のステップでは、ＴＡＭ２が取引依頼書６４を署名１０６と共に、"部長"のSue Smithに転送する。Sue Smithは出張依頼書５４の詳細６６及び依頼書上の前の署名のセットを提供される（この場合、依頼者４２による署名、及びJohn Brownの署名）。全てが妥当な場合、Sue Smithは部長としての彼女の職務において受信した全ての情報に署名し、これをＴＡＭ２に返信する。
【００６２】
第１１のステップでは、ＴＡＭ２が承認セット１００を構成することを意図する署名１０６のセットを受信する。これが実際に真実であることをチェックするために、ＴＡＭ２は依頼者４２、John Brown課長、及びSue Smith部長の職務証明書７６を受信し、全ての署名を確認する。第１２のステップでは、署名１０６が有効と確認されると、ＴＡＭ２は署名及び職務証明書７６を含む文書６４を依頼者４２に転送する。こうして、取引４０の正当性を確認するために要求される全ての認可詳細６６を含む、図１２に示されるデジタル文書１１４が生成される。これで依頼者４２は出張依頼書上に、この取引４０のクラスの承認セット１００を構成する署名１０６のセットを保持することになる。この情報は、依頼者４２が出張依頼書５４の申請を実際に認可されたことに関して、検証者１３０として示される別のユーザを納得させるために使用される。
【００６３】
図１２を参照すると、完成された取引４０が示され、取引詳細６６及び依頼者４２により保持される署名１０６を有する。詳細には、１）ＴＡ８０により署名された取引詳細のＨＴＭＬ、及び２）ユーザにより提供される入力を含み、これらの両者は依頼者４２により署名され、更に３）この情報が課長により多重署名され、全てが部長により多重署名される。
【００６４】
図１３を参照すると、依頼者４２により保持される職務証明書７６及び認可構造９８が示される。
【００６５】
次に図１４を参照して、取引処理として、依頼者４２が出張依頼書５４を検証者１３０に転送することに関連するステップについて述べる。この方法は確認補助方法１１６と呼ばれる。
【００６６】
この確認方法をより理解するために、認可構造９８が如何に構築されるかについての詳細を理解することが重要である。確認補助方法１１６は暗号ハッシュ関数を使用し、これが任意のストリングを、例えば１６バイトまたは２０バイトの固定長出力にマップする。出張依頼書５４の場合、認可構造９８は承認セットを構成する３つの職務１２２にハッシュする（従って、会社の実際の認可構造にハッシュする）ことにより構築される。すなわち、それらはＨ１＝ハッシュ（一般社員）、Ｈ２＝ハッシュ（課長）、及びＨ３＝ハッシュ（部長）である。
【００６７】
例えば、Ｈ１はストリング"一般社員"のハッシュであると言われる。最後に、Ｈ１、Ｈ２及びＨ３はストリングとして処理され、連結されて、次にＴ＝ｈａｓｈ（Ｈ１、Ｈ２、Ｈ３）としてハッシュされる。言い回しは"取引当局８０（ＴＡ）が認可構造９８に署名する"となり、これは取引当局が取引Ｔ４０の値に署名することを意味する。従って、ＴＡ８０は"ハッシュのハッシュ"（hash of hashes）に署名することになる。
【００６８】
全てのユーザは、ＴＡ８０により署名される認可構造が、最初に職務１２２の収集をハッシュし、次にこれらの値をもう一度ハッシュすることにより導出されることを知る点で、認可構造９８（ＡＳ）に署名するこの一般的な方法を承知している。
【００６９】
出張依頼例を特に参照すると、依頼者４２は１）ＴＡ８０により署名されるＨＴＭＬ形式の出張依頼書５４と、２）職務が"一般社員"、"課長"及び"部長"の３人のユーザに対応する３つの職務証明書７６と、３）図１２に示されるように、最初に一般社員により、次に課長、次に部長により署名される取引詳細６６と、４）図１５に示されるようなハッシュ結果の職務１２２上の署名を送信する。
【００７０】
図５を再度参照すると、ＴＡＭ２は検証者１３０が作成された署名済み文書１１４を確認することを可能にする確認補助方法１１６を含む。検証者は基本的に、依頼者４２が取引４０、この場合、出張依頼書５４を認可されるか否かの確認に関心がある。依頼者４２は検証者１３０に、取引ＨＴＭＬ（ＴＡ８０により署名済み）、職務証明書７６の収集、職務証明書内の確認キー１２０に対応する各署名キー１５０により署名された取引詳細、及び認可構造９８を送信する。図１０から、各職務証明書１２２は職務当局１８０（ＲＡ）により署名されることが思い起こされる。第１のステップ１３２では、検証者１３０は職務当局１８０の確認キー１２０を用いて、文書１１４上の各職務証明書７６をチェックする。第２のステップ１３４では、検証者１３０が提供された職務証明書７６内の確認キー１２０を用いて取引詳細６６上の署名１０６をチェックする。第２のステップ１３４のサブステップ１３６では、依頼者４２が認可されるか否かをチェックするために、検証者１３０は職務証明書７６から指定職務１２２を抽出する。第２のステップ１３４の第２のサブステップ１４０では、職務名が前述のハッシュのハッシュ・プロセスを用いてハッシュされる。第２のステップ１３４の第３のサブステップ１４２では、取引４０の計算されたハッシュ値が取引当局８０により当初署名された値に対してチェックされ、それが認可構造９８内で受信された取引４０の値と等しいことを保証する。次に、ハッシュのハッシュ・プロセスの出力が、ハッシュのハッシュ・プロセス上の署名１０６をチェックする入力として使用される。第２のステップ１３４の第４のサブステップ１４４では、生成されたハッシュのハッシュ・ストリングがＴＡ８０により署名されたハッシュド・ストリングに合致する場合、検証者１３０は依頼書５２が認可されるものと想定する。合致する場合、取引４０は確認されたことになり、この事実の通知が依頼者４２に送信される。
【００７１】
前述の補助方法１１６において、ＴＡＭ２は依頼者４２からの情報を検証者１３０に転送する。任意的に、依頼者４２から検証者１３０への転送は、電子メールにより行われてもよい。依頼者４２は局所的にＴＡＭ２を使用し、全ての認可詳細６６を収集し、この全ての情報を電子メールを介して検証者１３０に送信する。例えば、全ての署名１０６及び費用が収集され、次に依頼書５２が旅行業者に電子メールにより転送される。続いて旅行業者が予約を行う。
【００７２】
これまで、依頼者４２及び検証者１３０は同一会社に所属すると仮定してこなかった。これは必要ではない。なぜなら、本方法２は検証者１３０が同一会社に所属するか否かに関わらず機能するからである。彼らが同一会社に所属する場合、彼らはイントラネット２５により接続されて、同一のサーバ５４ａを共有するかもしれない。検証者１３０の位置はそれ自身、重要でない。検証者１３０の職務１２２は、依頼者４２により提供される情報を確認することである。
【００７３】
取引４０の正当性を確認するために、検証者１３０は以下のことを必要とする。
１）取引４０において使用される職務証明書７６上の署名１０６の正当性をチェックするために使用される、職務当局１８０の署名確認キー１２０。
２）認可構造９８上の署名１０６の正当性をチェックするための、取引当局８０の署名確認キー１２０（ハッシュのハッシュ・プロセス）。
３）認可構造９８上の取引当局８０の署名がチェック可能なように、指定職務１２２を収集し、ハッシュのハッシュ・プロセスを実行する方法の知識。
【００７４】
職務当局１８０及び取引当局８０の署名確認キー１２０は、それらが秘密にされる必要がない点で公開情報である。従って、それらは全ての者により使用可能で、確認可能と見なされる。ハッシュのハッシュ・プロセスは、全ての潜在的な検証者１３０により本方法２を用いて理解される必要がある。
【００７５】
ハッシュのハッシュ・プロセスは前述の出張依頼書５４の例では、極めて単純である。なぜなら、１つの承認セット１００しか存在しないからである。しかしながら、基本方法２は次のように、幾つかの承認セット１００を含むように拡張され得る。例えば、出張依頼５４はＣＥＯ及びＣＥＯ秘書により認可され、この場合、出張依頼書の２つの承認セット（Ｐ１及びＰ２）は、Ｐ１＝｛一般社員、課長、部長｝及びＰ２＝｛ＣＥＯ、ＣＥＯ秘書｝となる。
【００７６】
承認セット１００及びそれらを構成する職務１２２は、図９に示されるような認可ツリー１５４（ＡＴ）に構成される。認可ツリー１５４は認可構造の１例である。取引当局８０が認可構造９８に署名するために、ＡＴは最初にストリングに変換されなければならず、これは前述と類似のハッシュのハッシュ・プロセスを用いて行われる。
【００７７】
最初に、各職務名１２２はＨ１、Ｈ２、Ｈ３、Ｈ４、Ｈ５を次のように与えるようにハッシュされる。
Ｈ１＝hash（一般社員）
Ｈ２＝hash（課長）
Ｈ３＝hash（部長）
Ｈ４＝hash（ＣＥＯ）
Ｈ５＝hash（ＣＥＯ秘書）
これらの値は、各承認セットの１つのハッシュを獲得するために、次のようにハッシュされなければならない。すなわち、Ｈ６＝hash（Ｈ１、Ｈ２、Ｈ３）、Ｈ７＝hash（Ｈ４、Ｈ５）である。ここでＨ６は承認セットＰ１のハッシュであり、Ｈ７は承認セットＰ２のハッシュ（Ｐ２'）である。従って、各承認セット１００に対して１つのハッシュが存在することになり、これらは承認セット・ハッシュと呼ばれる。ここでhash（Ｈ１、Ｈ２、Ｈ３）は、Ｈ１、Ｈ２及びＨ３が連結され、続いてハッシュされるストリングであることを意味する。最後に、認可ツリーのハッシュはＴ＝hash（Ｈ６、Ｈ７）として生成される。
【００７８】
このハッシング・プロセスは図１５に示される。取引当局８０により署名されるのは取引４０の値である。
【００７９】
検証者１３０は取引４０上の署名を用いて、前述の１つの承認セット１００を有する例の場合と同様に、依頼者４２が所与の取引４０（この場合出張依頼書５４）に関して認可されることをチェックする。
【００８０】
取引４０上の署名１０６を確認するために、検証者１３０は、図９及び図１５に関連して前述したツリー・ハッシング・プロセスの全部または一部を繰り返す。ここで図１５では、ハッシュされた参照項目が、未ハッシュの参照番号に続くプライム符号により、図９のそれと区別される。依頼者４２が承認セットＰ１を構成する職務の人達からの署名１０６を獲得したと仮定する。この場合、依頼者４２は検証者１３０に３つの職務証明書７６を送信しており、そこから検証者は職務名"一般社員"、"課長"及び"部長"を抽出できる。検証者１３０は次に前述のように、Ｈ１、Ｈ２、Ｈ３及びＨ６を形成することができる。こうして、検証者１３０は、取引４０を認可した承認セット１００の承認セット・ハッシュを形成することができる。
【００８１】
認可ツリー１５４上の署名確認を完了するために、依頼者４２は取引４０を認可する承認セットに加えて、全ての他の承認セット１００の承認セット・ハッシュを検証者１３０に提供する必要がある。前述の例では、Ｐ１は取引４０を認可しているのでＰ２のハッシュが提供されなければならず、これはこの場合、前述のようにＨ７に等しい。
【００８２】
Ｈ７が与えられると、検証者１３０はＴを形成できる。なぜなら、検証者はＨ６を形成することができ、Ｔ上の署名１０６がチェックされ得るからである。従って、認可ツリー１５４上の署名１０６をチェックする目的のために、依頼者４２は検証者１３０に職務証明書７６を送信し、そこから職務１２２が抽出され、ハッシュされて、取引を認可する承認セット１００のハッシュ、並びに取引を認可していない各承認セットのハッシュが形成される。これらの２つの情報により、検証者１３０は取引４０のハッシュ値を計算し、次に署名１０６をチェックする。
【００８３】
前述の出張依頼書では、ＴＡＭ２がワールド・ワイド・ウェブを通じて接触され、従ってＴＡＭはウェブ・サーバ・プロセスと見なされる。本方法のワークフロー・システムでは、ユーザは好適には専用のネットワーク・チャネルを通じてＴＡＭと接触する。両方の実施例は本質的に同じである。すなわち、ＴＡＭ２はユーザによりアクセスされ得るコンピュータ・システム２０上のどこかに存在する。またＴＡＭはまた、データベース７０、８２、４６及び２０２、及び他のユーザをアクセスできる。従来理解されているように、これは例えば電子メールにより、またはウェブへのイントラネットまたはインターネット接続を介して達成され得る。
【００８４】
ＴＡ８０は、ＴＡにより生成される署名１０６が信頼される点で、依頼者４２及び検証者１３０により信頼される。この意味において、ＴＡ８０は取引４０のＨＴＭＬ表現６４を適切に形成し、それに署名するために、また取引の認可構造９８を形成し、それに署名するために信頼される。しかしながら、広義には、ＴＡＭ２は信頼される必要はない。ユーザはＴＡＭ２を信頼して、自分たちのためにあるセキュリティ機能を実行するが、ユーザは代わりにローカル・プロセスを使用して、ＴＡＭにより実行される全ての作業が適切であることを確認してもよい。
【００８５】
ウェブの実施例では、ＴＡＭ２はインターネット３１上の検証者１３０及び依頼者４２の両者によりアクセス可能な独立のサーバ５４ｂである点で、中立である（すなわち、全てにより信頼される）。特に、本当に信頼が置ける構成要素は、（デジタル取引及び認可構造を生成する）取引当局８０と、（前述の職務の人達に職務証明書７６を割当てる）職務当局１８０である。従って、検証者１３０は、取引当局８０によりＨＴＭＬ表現６４及び認可構造９８上に生成された署名１０６、及び職務証明書７６上の署名のための職務当局１８０を信頼するだけでよい。
【００８６】
前述の出張依頼５４では、ＴＡＭ２は依頼者４２のために確実な役割を演じる。なぜなら、ＴＡＭは情報をフェッチし、署名１０６をチェックするからである。しかしながら、全ての情報が例えばサーバ５４ｂ上に存在する公衆データベース（デジタル文書データベース７０、認可構造データベース９６、及び職務証明書データベース８２）内にあることが明らかである。依頼者４２はデジタル文書データベース７０をアクセスし、出張依頼ＨＴＭＬ文書６４を直接獲得し、それ上のＴＡ８０の署名１０６をチェックできる（ＴＡ８０の確認キー１２０は誰でも使用可能である）。依頼者４２は次に署名１０６に必要なユーザと接触して、承認セット１００を形成し、職務証明書データベース８２などをアクセスすることにより署名をチェックする。
【００８７】
ＴＡＭ２がデータベースのフェッチ及び署名の収集を実行するとき、これは本方法が実際に如何に機能するかということを除き、単に依頼者４２にとっての利便性である。信頼ではなく、利便性が決定的な条件の場合には、ＴＡＭ２は全ての当事者により信頼される必要はない。
【００８８】
前述のように、企業内認可及び企業間認可の主な違いは、前者の場合には、会社がその認可構造９８を検証者１３０に明かすことにあまり関わらない。企業間認可の状況では、認可構造が所与の業務に対する認可ツリー１５４であり、全ての認可ツリーの収集を含むデータベースへのアクセスが、社外のユーザには制限されるべきである。
【００８９】
前述の方法２を企業間認可の状況に適応化するための幾つかの方法が存在する。ユーザＵＡ及びユーザＵＢによりそれぞれ表される、会社Ａと会社Ｂとの間の取引４０の最初の例に戻ると、最も直接的なアプローチは、各会社が企業当局（ＥＡ：enterprise authority）を有し、署名１０６を確認するために使用される公開キーが、企業当局により会社のために生成される。企業当局は会社内で発生する全ての取引の検証者であることにより、全ての企業間取引を認可する。取引が認可されると、企業当局はこの趣旨で記述書に署名し、これが別の会社のユーザにより確認され得る。
【００９０】
更に、ＴＡＭ２は好適には分散ワークフロー管理システム６内で動作するが、本方法は単にメッセージ交換機構から構成されてもよい。この実施例では、メッセージ交換機構は、従来のワークフロー管理システム６として動作せずに、代わりに、依頼者４２と社内の特定の職務を有する人間との間で、添付物を有する電子メールまたはＨＴＭＬ電子メールなどの、電子メッセージ・フローを管理する。こうした機構の管理は、ＰＣ常駐型の職務ベースのプログラム（すなわち、ユーザ８の特定の職務に適するようにカストマイズされたプログラム）のような単純なものを通じて、ファイル・サーバ・タイプのデータベース（図１１に示されるデータベース７０、９６、８２及び２０２に類似）、及びデータベースのリレーショナル構造に従うように編成されるプルダウン・メニュー及びサブメニューを用いて実現される。典型的なメニュー項目は、例えば"取引タイプ"であり、これが異なるタイプの取引（例えば"出張依頼書"など）をリストするサブメニューをオープンする。特定の取引４０を活動化すると、こうした取引に要求される承認セット１００を示す別のサブメニューをオープンする。承認セット１００を活動化すると、次に添付物として取引詳細６６を有する電子メールをオープンする。電子メールは承認セット１００内の人達に事前にアドレス指定され、署名の配布及び確認を容易にする。
【００９１】
図１５に示される認可ツリー１５４のハッシュを用いる実施例では、職務ＵＲのユーザが取引４０を要求できる以外に、検証者１３０がユーザの会社の決定構造に関する少量の情報だけを習得する利点を有する。他方、あらゆる企業間要求が確認及び署名のために企業当局（ＥＡ）に渡されるために、ＥＡサーバが潜在的なボトルネックとなる。別の解決策は、他の会社による確認の目的で、公衆インターネット３１上において認可ツリー１５４を会社の外部から使用可能にすることである。もちろん、主な問題は、認可ツリー１５４を直接明かすことにより、会社内の決定プロセスに関する多くの情報が明かされることである。次のセクションでは、企業間認可のために好適な、本方法２の幾つかの変更について述べる。
【００９２】
例えば、企業当局からあらゆる取引４０の直接承認を得なければならない代わりに（すなわち、取引管理者８０が、下級社員が取引を認可する権限を有することを確認する）、企業当局は認可構造９８を承認するだけでよい。この場合、認可の確認は常に企業当局に渡るわけではなく、認可は認可構造９８の要件を満たすだけでよい。
【００９３】
別の利点として、一旦ＴＡ８０が取引及び認可構造９８を生成し、ＲＡ１８０が職務証明書７６を作成すると、本方法２を用いて作成された契約が容易且つ自動的に確認される点で、システム２０は非常に確実となる。
【００９４】
以上、本方法２は１つの職務の承認セット１００により機能することが理解された。しかしながら、２つ以上の職務１２２が承認セット１００内で指定される場合、認可結果の信頼性が向上する利点がある。更に、本方法２の低レベルの資源集中型実施例が、幾つかの職務１２２から成る承認セット１００内の１つ、例えば最初にリストされる職務証明書７６の抽出及び確認により得られる。上級社員の職務証明書７６を最初にリストされるように、承認セット１００の構造を定義することによりこの実施例の信頼性が向上する。それにも関わらず、こうした実施例は、承認セット１００自身の職務内容と併せて、全ての職務証明書７６を抽出及び確認する実施例（すなわち、取引４０上の職務証明書７６が、取引を認可するために要求される特定の職務１２２に実際に対応する）と比較して、本質的に信頼性に劣る。
【００９５】
ここで述べた本発明の実施例において、複数の変形及び変更が可能である。本発明の特定の実施例について述べてきたが、前述の開示において、広範囲の変更及び代替実施例が可能である。ある場合には、本発明の幾つかの機構は、他の機構の対応する使用無しに使用され得る。従って、前述の説明は１例の説明として提供されただけであり、広く解釈されるべきであり、本発明の趣旨及び範囲内において、様々な変更が可能である。
【００９６】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００９７】
（１）複数の相互接続されるコンピュータ及び複数の資源を含むコンピュータ・ネットワーク上で動作するプロセス・フローを有するコンピュータによる方法であって、各コンピュータがプロセッサ、メモリ及び入出力装置を含み、各資源が少なくとも１つのコンピュータに動作上接続されて、プロセス・フローにおいて少なくとも１つの活動を実行するものにおいて、
認可に関連付けられる職務証明を抽出し、職務証明そのものが信頼できるか否かを確認することにより、取引の電子認可を検証可能に編成する方法。
（２）職務証明に関連付けられる職務がハッシュされ、ハッシュ化職務のデータベース内のハッシュ化職務と比較される、前記（１）記載の方法。
（３）職務証明が取引を認可するために要求され、認可に関連付けられる職務証明が、認可構造の職務の承認セット内の職務に対応することを確認することにより、認可が更に保証される、前記（１）記載の方法。
（４）認可構造が認可ツリーである、前記（３）記載の方法。
（５）職務が取引に関連付けられる職務証明から抽出され、抽出された各職務がハッシュされ、これらのハッシュされた職務が連結されて、再度ハッシュされ、次に他の承認セットのハッシュが存在すれば、認可構造に従いそれと連結されて、再度ハッシュされ、計算結果のハッシュ値が取引管理者により署名されたハッシュ値と比較され、一致する場合取引が認可される、前記（３）記載の方法。（６）複数の相互接続されるコンピュータ及び複数の資源を含むコンピュータ・ネットワーク上で動作する分散ワークフロー管理システムであって、各コンピュータがプロセッサ、メモリ及び入出力装置を含み、各資源が少なくとも１つのコンピュータに動作上接続されて、プロセス・フローにおいて少なくとも１つの活動を実行するものにおいて、
認可に関連付けられる少なくとも１つのタイプの職務証明を抽出し、職務証明そのものが信頼できるか否かを確認することにより、取引の電子認可を検証可能に編成する方法によりコード化されるシステム。
（７）職務証明に関連付けられる職務がハッシュされ、ハッシュ化職務のデータベース内のハッシュ化職務と比較される、前記（６）記載のシステム。
（８）職務証明が取引を認可するために要求され、認可に関連付けられる職務証明が、認可構造の職務の承認セット内の職務に対応することを確認することにより、認可が更に保証される、前記（６）記載のシステム。
（９）認可構造が認可ツリーである、前記（８）記載のシステム。
（１０）職務が取引に関連付けられる職務証明から抽出され、抽出された各職務がハッシュされ、これらのハッシュされた職務が連結されて、再度ハッシュされ、次に他の承認セットのハッシュが存在すれば、認可構造に従いそれと連結されて、再度ハッシュされ、計算結果のハッシュ値が取引管理者により署名されたハッシュ値と比較され、一致する場合取引が認可される、前記（８）記載のシステム。
（１１）複数の相互接続されるコンピュータ及び複数の資源を含むコンピュータ・ネットワーク上で動作するプロセス・フローを有するコンピュータによる方法であって、各コンピュータがプロセッサ、メモリ及び入出力装置を含み、各資源が少なくとも１つのコンピュータに動作上接続されて、プロセス・フローにおいて少なくとも１つの活動を実行するものにおいて、
認可に関連付けられる少なくとも１つのタイプの職務証明を抽出し、職務証明そのものが信頼できるか否かを確認することにより、取引の電子認可を確認する方法。
（１２）職務証明に関連付けられる職務がハッシュされ、ハッシュ化職務のデータベース内のハッシュ化職務と比較される、前記（１１）記載の方法。
（１３）職務証明が取引を認可するために要求され、認可に関連付けられる職務証明が、認可構造の職務の承認セット内の職務に対応することを確認することにより、認可が更に保証される、前記（１１）記載の方法。
（１４）認可構造が認可ツリーである、前記（１３）記載の方法。
（１５）職務が取引に関連付けられる職務証明から抽出され、抽出された各職務がハッシュされ、これらのハッシュされた職務が連結されて、再度ハッシュされ、次に他の承認セットのハッシュが存在すれば、認可構造に従いそれと連結されて、再度ハッシュされ、計算結果のハッシュ値が取引管理者により署名されたハッシュ値と比較され、一致する場合取引が認可される、前記（１３）記載の方法。
（１６）複数の相互接続されるコンピュータ及び複数の資源を含むコンピュータ・ネットワーク上で動作する分散ワークフロー管理システムであって、各コンピュータがプロセッサ、メモリ及び入出力装置を含み、各資源が少なくとも１つのコンピュータに動作上接続されて、プロセス・フローにおいて少なくとも１つの活動を実行するものにおいて、
認可に関連付けられる少なくとも１つのタイプの職務証明を抽出し、職務証明そのものが信頼できるか否かを確認することにより、取引の電子認可を確認する方法によりコード化されるシステム。
（１７）職務証明に関連付けられる職務がハッシュされ、ハッシュ化職務のデータベース内のハッシュ化職務と比較される、前記（１６）記載のシステム。
（１８）職務証明が取引を認可するために要求され、認可に関連付けられる職務証明が、認可構造の職務の承認セット内の職務に対応することを確認することにより、認可が更に保証される、前記（１６）記載のシステム。
（１９）認可構造が認可ツリーである、前記（１８）記載のシステム。
（２０）職務が取引に関連付けられる職務証明から抽出され、抽出された各職務がハッシュされ、これらのハッシュされた職務が連結されて、再度ハッシュされ、次に他の承認セットのハッシュが存在すれば、認可構造に従いそれと連結されて、再度ハッシュされ、計算結果のハッシュ値が取引管理者により署名されたハッシュ値と比較され、一致する場合取引が認可される、前記（１８）記載のシステム。
（２１）コンピュータ読取り可能媒体上でコード化される取引認可方法であって、
ａ）取引の依頼を受信し、
ｂ）取引の詳細を有する文書の電子表現をデジタル文書データベースから獲得し、
ｃ）取引管理者により署名された職務証明を職務証明データベースから獲得し、署名を確認し、
ｄ）取引詳細を依頼者に返却し、
ｅ）依頼者により署名され、完成された表現を依頼者から待機して受信し、
ｆ）取引管理者により事前に署名された取引の認可構造を、認可構造データベースに要求し、署名を確認し、職務名の承認セット及びこれらの職務名に署名するために接触する承認セットのユーザ・メンバを選択し、
ｇ）依頼者の署名を有する取引依頼の詳細を、選択された承認セットに対応する職務を有する他の者に転送し、承認セット内で示される各職務の署名を収集し、
ｈ）職務証明データベースからの職務証明及び承認セットの各メンバの署名を要求し、それらを文書上でコード化し、
ｉ）取引の正当性を確認するために要求される認可詳細と、署名及び職務証明を含む完成された電子文書を依頼者に転送するステップと
を含む、取引認可方法。
（２２）職務証明及び認可構造が承認セット及び職務に関するハッシュ化情報を含み、こうしたハッシュ化情報が未ハッシュの職務証明及び承認セットを代理する、前記（２１）記載の方法。
（２３）コンピュータ読取り可能媒体上でコード化される取引確認方法であって、
ａ）取引、取引当局により署名される関連取引詳細、職務当局により署名される指定職務を証明する職務証明の収集、職務証明内の確認キーに対応する各署名キーにより署名される取引詳細、及び認可構造を表す電子文書を受信し、
ｂ）職務当局の確認キーを用いて、文書上の各証明をチェックし、
ｃ）提供される職務証明内の確認キーを用いて、取引詳細の署名を以下のようにチェックするものであって、
ｉ）職務証明から指定職務を抽出し、
ii）ハッシュのハッシュ・プロセスを用いて、職務をハッシュし、
iii）取引の計算されたハッシュ値を、取引当局により最初に署名されたものに対してチェックして、それが認可構造内で受信される取引の値と等しいことを保証し、
iv）ハッシュのハッシュ・プロセスの出力を入力として用いて、ハッシュのハッシュ・プロセスの署名をチェックし、生成されたハッシュのハッシュ・ストリングが、取引当局により署名されたハッシュ化ストリングと合致する場合、依頼が認可されたと見なし、
ｄ）結果を報告するステップと
を含む、方法。
（２４）取引認可方法によりコード化される分散ワークフロー管理システムであって、該方法が、
ａ）取引の依頼を受信する受信手段と、
ｂ）取引の詳細を有する文書の電子表現をデジタル文書データベースから獲得する検索手段と、
ｃ）取引管理者により署名された職務証明を職務証明データベースから獲得し、署名を確認する検索手段と、
ｄ）取引詳細を依頼者に返却する伝送手段と、
ｅ）依頼者により署名され、完成された表現を依頼者から受信する受信手段と、
ｆ）取引管理者により事前に署名された取引の認可構造を、認可構造データベースに要求する問い合わせ手段と、
ｇ）署名を確認する確認手段と、
ｈ）職務名の承認セット及びこれらの職務名に署名するために接触する承認セットのユーザ・メンバを選択する選択手段と、
ｉ）依頼者の署名を有する取引依頼の詳細を、選択された承認セットに対応する職務を有する他の者に転送し、承認セット内で示される各職務の署名を収集する伝送手段と、
ｊ）職務証明データベースからの職務証明及び承認セットの各メンバの署名を要求する検索手段と、
ｋ）ステップｊ）で収集された署名を文書上でコード化するコード化手段と、
ｌ）取引の正当性を確認するために要求される認可詳細と、署名及び職務証明を含む完成された電子文書を依頼者に転送する伝送手段と
を含む、システム。
（２５）職務証明及び認可構造が承認セット及び職務に関するハッシュ化情報を含み、こうしたハッシュ化情報が未ハッシュの職務証明及び承認セットを代理する、前記（２４）記載のシステム。
（２６）取引確認方法によりコード化される分散ワークフロー管理システムであって、該記方法が、
ａ）取引、取引当局により署名される関連取引詳細、職務当局により署名される指定職務を証明する職務証明の収集、職務証明内の確認キーに対応する各署名キーにより署名される取引詳細、及び認可構造を表す電子文書を受信し、
ｂ）職務当局の確認キーを用いて、文書上の各証明をチェックし、
ｃ）提供される職務証明内の確認キーを用いて、取引詳細の署名を以下のようにチェックするものであって、
ｉ）職務証明から指定職務を抽出し、
ii）ハッシュのハッシュ・プロセスを用いて、職務をハッシュし、
iii）取引の計算されたハッシュ値を、取引当局により最初に署名されたものに対してチェックして、それが認可構造内で受信される取引の値と等しいことを保証し、
iv）ハッシュのハッシュ・プロセスの出力を入力として用いて、ハッシュのハッシュ・プロセスの署名をチェックし、生成されたハッシュのハッシュ・ストリングが、取引当局により署名されたハッシュ化ストリングと合致する場合、依頼が認可されたと見なし、
ｄ）結果を報告するステップと
を含む、システム。
（２７）複数の相互接続されるコンピュータ及び複数の資源を含むコンピュータ・ネットワーク上で動作するメッセージ交換機構であって、各コンピュータがプロセッサ、メモリ及び入出力装置を含み、各資源が少なくとも１つのコンピュータに動作上接続されて、コンピュータ・ネットワークを介して別の資源に送信されるメッセージを読み書き可能なものにおいて、
認可に関連付けられる職務証明を抽出し、職務証明そのものが信頼できるか否かを確認することにより、取引の電子認可を検証可能に編成する機構。
（２８）職務証明に関連付けられる職務がハッシュされ、ハッシュ化職務のデータベース内のハッシュ化職務と比較される、前記（２７）記載の機構。
（２９）職務証明が取引を認可するために要求され、認可に関連付けられる職務証明が、認可構造の職務の承認セット内の職務に対応することを確認することにより、認可が更に保証される、前記（２７）記載の機構。
（３０）認可構造が認可ツリーである、前記（２９）記載の機構。
（３１）職務が取引に関連付けられる職務証明から抽出され、抽出された各職務がハッシュされ、これらのハッシュされた職務が連結されて、再度ハッシュされ、次に他の承認セットのハッシュが存在すれば、認可構造に従いそれと連結されて、再度ハッシュされ、計算結果のハッシュ値が取引管理者により署名されたハッシュ値と比較され、一致する場合取引が認可される、前記（２９）記載の機構。
（３２）複数の相互接続されるコンピュータ及び複数の資源を含むコンピュータ・ネットワーク上で動作するメッセージ交換機構であって、各コンピュータがプロセッサ、メモリ及び入出力装置を含み、各資源が少なくとも１つのコンピュータに動作上接続されて、プロセス・フローにおいて少なくとも１つの活動を実行するものにおいて、
認可に関連付けられる少なくとも１つのタイプの職務証明を抽出し、職務証明そのものが信頼できるか否かを確認することにより、取引の電子認可を確認する方法によりコード化される機構。
（３３）職務証明に関連付けられる職務がハッシュされ、ハッシュ化職務のデータベース内のハッシュ化職務と比較される、前記（３２）記載の機構。
（３４）職務証明が取引を認可するために要求され、認可に関連付けられる職務証明が、認可構造の職務の承認セット内の職務に対応することを確認することにより、認可が更に保証される、前記（３２）記載の機構。
（３５）認可構造が認可ツリーである、前記（３４）記載の機構。
（３６）職務が取引に関連付けられる職務証明から抽出され、抽出された各職務がハッシュされ、これらのハッシュされた職務が連結されて、再度ハッシュされ、次に他の承認セットのハッシュが存在すれば、認可構造に従いそれと連結されて、再度ハッシュされ、計算結果のハッシュ値が取引管理者により署名されたハッシュ値と比較され、一致する場合取引が認可される、前記（３４）記載の機構。
【図面の簡単な説明】
【図１】本発明のコンピュータ・システムのブロック図である。
【図２】本発明の方法に従い符号化されるネットワークの概略図である。
【図３】トランザクションの概略図である。
【図４】本発明の方法のフロー図である。
【図５】本発明の確認補助方法のフローチャートである。
【図６】本方法において使用される出張依頼書の概略図である。
【図７】本方法の取引当局を示すブロック図である。
【図８】本方法の認可構造を示すブロック図である。
【図９】出張依頼の認可ツリーを示す図である。
【図１０】職務証明書と本方法との相互作用を示すブロック図である。
【図１１】本方法におけるＴＡＭと様々なデータベースとの相互作用を示すブロック図である。
【図１２】完成された出張依頼の概略図である。
【図１３】出張依頼における職務証明書を示す概略図である。
【図１４】依頼書の検証者への転送を示す概略図である。
【図１５】図９のツリーのハッシュを示す図である。
【符号の説明】
２ 取引認可方法（ＴＡＭ）
４ 契約
６ 分散ワークフロー管理システム
８ ユーザ
１０ 依頼
１８ 署名
２０ コンピュータ・システム
２１ 分散システム
２２ 相互接続コンピュータ
２３ 資源
２４ 表示装置
２５ イントラネット（コンピュータ・ネットワーク）
２６ 入力装置
２７ マウス
２８ 左マウス・ボタン
２９ 右マウス・ボタン
３０ １次記憶装置
３１ インターネット（コンピュータ・ネットワーク）
３２ ２次記憶装置
３３ データベース
３４ グラフィカル・ユーザ・インタフェース（ＧＵＩ）
３６ ＣＰＵ
４０ 取引
４１ インタフェース
４２、１６５ 依頼者
４４、１３０ 検証者
４６ 製品またはサービス
５０ 電子文書
５２ 依頼書
５４ 出張依頼書
６０ 取引依頼詳細
６４ ＨＴＭＬ表現
６６ 取引詳細
７０ デジタル文書データベース（ＤＤＤ）
７６ 職務証明書
８０ 取引当局（ＴＡ）
８２ 職務証明書データベース（ＲＣＤ）
９４ 認可構造（ＡＳ）
９６ 認可構造データベース（ＡＳＤ）
１００ 承認セット
１０２ 職務名
１０６、１２６ 署名
１１４ デジタル文書
１１６ 確認補助方法
１２０ 署名確認キー
１２２ 職務
１４６ 認可情報
１５０ 突き合わせ署名キー
１５４ 認可ツリー（ＡＴ）
１５６ ノード
１６０ 第１のレベル
１６２ ルート
１６４ 第２のレベル
１６５ 一般社員（電子署名）
１６６ リーフ
１６７ 課長（電子署名）
１６９ 部長（電子署名）
１７０ "ＡＮＤ"ノード
１７２ "ＯＲ"ノード
１８０ 職務当局
２０２ ユーザ・ディレクトリ・データ（ＵＤＢ）
【発明の属する技術分野】
本発明は電子商取引に関し、特に、公衆ネットワーク及び専用ネットワークの両方を介して、企業間の取引の承諾を認可及び確認する方法に関する。
【０００２】
【従来の技術】
公衆ネットワークを介する様々な企業間の電子商取引ソルーションの大規模な展開は、セキュリティ問題の慎重な考慮を要求する。これは１例を通じて最もよく説明される。
【０００３】
会社Ａ及び会社Ｂの２社が、申し出、注文または取り消しなどの企業取引（すなわち、個人または組織間の法的に拘束力のある活動）を行う正式協定を有する。会社Ａ及びＢ間の取引タイプの可能なセットは、Ｔ（Ａ、Ｂ）＝｛Ｔ１、Ｔ２、．．．、Ｔｎ｝により表され、ここで例えばＴ∈Ｔ（Ａ、Ｂ）は、
Ｔ→"製品Ｙを１単位当たり価格ＰでＸ単位購入する"
ことを意味するものとする。
【０００４】
セットＴ（Ａ、Ｂ）により表される取引タイプは、一般的であると見なされ、特定の取引が発生する実時間において、取引記述Ｔ（Ａ、Ｂ）で与えられるもの以外の、追加の詳細が提供されなければならない。例えば取引Ｔにおいて、依頼者はＸ、Ｙ及びＰの値を提供し、これは時間の経過に伴い変化し得る。
【０００５】
取引のセットＴ（Ａ、Ｂ）を指定する問題、それらが如何に実行されるか、及び交換されるデータなどは、ＩＳＯ９７３５における電子データ交換（ＥＤＩ：Electronic Data Exchange）構文を用いて解決される（http://www.r3.ch/standards/edifact/index.html参照）。更に、これらの会社はインターネットを介して調整し、取引セットＴ（Ａ、Ｂ）で指定される彼らの一般的な取引を履行しなければならない。
【０００６】
典型的な状況は、会社ＡのユーザＵＡが、会社Ｂの管理下にあるユーザＵＢから、タイプＴ∈Ｔ（Ａ、Ｂ）の取引を受信することである。ここでユーザＵＡが会社Ｂからの依頼、すなわち会社Ａに対して、製品Ｙを１単位当たり価格Ｐ＝１ドルでＸ＝１０００単位生産するようにとの依頼を提示され、更にユーザが公衆ネットワークを介して、ソフトウェア操作を通じて操作すると仮定する。依頼は公衆ネットワークから発信するので、ユーザＵＡが考慮し得る少なくとも３つのセキュリティ問題が存在する。第１は、取引の詳細（Ｘ、Ｙ、Ｐ、ＵＡ、ＵＢ）が機密であり、保全性を考慮して符号化されているかであり、第２は、取引を依頼するユーザＵＢが、実際に会社Ｂにより管理されていることをどのように確認するかであり、第３は、たとえ取引を依頼するユーザＵＢが会社Ｂにより雇われていることが知れたとしても、ユーザＵＢが実際にこうした取引をＸ、Ｙ及びＰの所与の値で依頼することを許可されているかの確認方法が、明確でないことである。
【０００７】
最初の２つの点は、A．Menezes、P．van Oorschot、及びS．VanstoneによるHandbook of Applied Cryptography、CRC press、1996で述べられる標準のセキュリティ・プロトコル及び暗号化アルゴリズムを用いて解決される。特に、公開キー暗号化により、各ユーザＵｘは１つまたは複数の認証（ISO/IEC9594、Information Technology - Open Systems Interconnection - The Directory：Authentication Framework、1993参照）を交付され、それらがデジタル署名を通じて、彼らの識別を証明するために使用される。
【０００８】
ユーザＵＡ及びＵＢが個人的に知り合いである場合、既存の信頼関係だけでユーザＵＡがユーザＵＢからの依頼を認可されたものとして受諾するのに十分であり、実際このようにして多くの企業間取引が現在行われている。この場合、ユーザＵＡ及びＵＢは、将来取引を行うために明確にある信頼関係を確立しているか、ことによると信頼が前の成功取引により獲得されたものである。しかしながら、一般的な電子商取引は、以前に取引関係または信頼関係を有さない人々及び会社を引き合わせ、取引はともかく"自己認可的（self-authorizing）"なものとなる。従来、データ、アプリケーション、資源またはより一般的には単にオブジェクトの認可は、ある形式のアクセス制御を用いて管理された。例えば、D．E．Denningによる"Cryptography and Data Security"、Addison-Wesley Publishing Company、1982を参照のこと。その最も一般的な形式として、各オブジェクトＯに対して各ユーザが有するアクセス権を明示的にリストするアクセス制御マトリックスＭが存在する。多くのユーザＵｉ及びオブジェクトＯｊが存在するとき、アクセス制御マトリックスＭを管理することは困難である。
【０００９】
ことによると、最も一般的なタイプの認可は、取引Ｔを記述する一般的に作成された文書または書式であり、そこでは特定の詳細が依頼者により依頼時に提供され、依頼者は次に、タイプＴの取引または依頼を承認できる一人のまたは複数の人々から、書式上の手書き署名のセットを収集するように要求される。例えば、Ｔは出張依頼書用紙であり、そこでは行き先、滞在期間、予想費用、及び移動方法の提示が要求される。依頼者はこれらの詳細を記述し、依頼書に署名し、用紙を様々な上司に提示して、用紙上の所定の場所に彼らの署名を依頼する。一般に、署名が要求される用紙上の場所は、課長や部長またはＣＥＯなどの署名を依頼される人々の職務によりラベル付けされる。
【００１０】
認可のこの用紙は"書式署名モデル（form-signature model）"と呼ばれたり、共同署名または共同署名データによる認可と呼ばれる。例えば、出張依頼取引（Ｔ＝"出張依頼"）は、依頼者、依頼者の課長、次に依頼者の部長の署名を要求する。一旦要求された署名が収集されると、依頼者は署名文書により取引を認可する。すなわち、例えば旅行業者にフライトやホテルを予約させる。通常、旅行業者は、戻り日が出発日よりも後であること、或いは費用の限界を超えていないことなどの一般的なチェックを除き、出張依頼の詳細の確認に関与しない。旅行業者にとって重要なことは、依頼書に付随する署名のセット、及びこれらの署名により表される職務である。多額の資金を伴わない多くの事務作業にとって、書式署名モデルは業務の認可を与えるのに十分である。しかしながら、より多額の資金または資源を取引に委ねられる場合、各署名が信頼できるものであり、署名の収集が実際にその会社を結びつけることが確実であることが重要となる。これらの場合、下級の社員が取引を認可する権限を有することを確認するために、企業の当局者（すなわち、社長、監査役、または他の役員などの取引管理者）からあらゆる取引の直接承認を得ることが必要となる。
【００１１】
電子商取引の書式署名モデルは、１）業務を遂行するために要求される業務及び情報（日付、価格、名前など）の電子表現と、２）署名機構と、３）電子業務データに付随する署名を、その業務のための認可を与える特権に関連付ける機構とを含む。一般に１）及び２）は、現在の方法及び技術を用いて直接解決されるが、３）は十分に解決されていない。１）及び２）に関して、用紙ベースの書式がＨＴＭＬまたはワープロ文書として電子的に表され、業務Ｔに関して、Ｄ（Ｔ）が業務Ｔの電子書式またはテンプレートを示すものとする。Ｔが"出張依頼"と仮定すると、例えばＤ（Ｔ）は出張の詳細について要求するＨＴＭＬ文書であり得、職務のリストが存在し得る。そして、これらの職務を演ずるユーザは出張依頼詳細に署名しなければならない。更に、ＲＳＡまたはＤＳＳなどのデジタル署名を提供する幾つかの技法が存在し、従って、電子商取引において書式署名モデルを実現する基本ツールが使用可能である。電子商取引書式署名モデルにおいてより困難な部分は、収集された署名のセットが業務の認可を意味することを決定または確認することである。
【００１２】
ユーザＵがデジタル的にデータに署名する場合、ユーザＵは公開キーＰｕｂ（Ｕ）及び私用キーＰｒｉ（Ｕ）を有することを意味する。Ｐｕｂ（Ｕ）は、ここではＣｅｒｔ（Ｕ）として示される証明書内に記憶される。証明書Ｃｅｒｔ（Ｕ）は公開データベースまたはディレクトリ内に記憶され、誰もがそれを検索して、私用キーＰｒｉ（Ｕ）を有するユーザＵにより生成されたと言われる署名を確認できる。証明書Ｃｅｒｔ（Ｕ）は、ユーザＵの１つまたは幾つかの名前または識別子を含み、従ってユーザＵは署名を生成したユーザとして、一意的に識別される。しかしながら、文書Ｄ（Ｔ）上の署名のセットを調査することにより、別のユーザが取引Ｔを依頼しているかを確認する際、重要な点は、誰が各署名を生成したかではなく、彼らがＴを認可する権限を有するか否かである。
【００１３】
従って、企業の当局者をあらゆる取引を確認する必要性から解放し、不確かな公衆ネットワーク上において、標準のセキュリティまたは暗号化プロトコルを用いて、電子商取引契約の認可の効率的な認可及び確認を可能にする方法が必要とされる。更に、それぞれの会社の決定構造に関する最小の情報を明らかにする企業間認可を実行する方法が必要とされる。
【００１４】
【発明が解決しようとする課題】
本発明の目的は、取引が適切に認可され、従って履行可能なように保証する便利でコンピュータ化された手段を提供することにより、電子商取引を助成することである。
【００１５】
本発明の別の目的は、ハッシュ・テーブルが使用される場合に空間要求を低減し、また認可ツリー内の決定プロシージャ情報を曖昧化した上で、取引の認可を可能にすることであり、従って本発明の方法は、特に企業間取引において有用である。
【００１６】
【課題を解決するための手段】
複数の相互接続されるコンピュータ及び複数の資源を含むコンピュータ・ネットワーク上で動作する、取引認可方法が提供される。各コンピュータはプロセッサ、メモリ及び入出力装置を含み、各資源は少なくとも１つのコンピュータに動作上接続され、プロセス・フローにおいて少なくとも１つの活動を実行する。本方法は、認可に関連付けられる少なくとも１つのタイプの職務証明を抽出し、職務証明そのものが信頼できるか否かを確認することにより、取引の電子認可を検証可能に編成する。本方法は、職務にもとづく認可構造を提供することにより、取引に関する各々の及びあらゆる署名を個々に認可する必要性を排除する。この構造は、取引の認可を確認するために公衆ネットワーク上でアクセス可能である。
【００１７】
本方法は企業内及び企業間の両方の状況において適用可能である。なぜなら、本方法は匿名の証明書により表される、職務にもとづく匿名の認可決定を行うからである。このように、取引の信頼性を確認するとき、社員の識別が明かされる必要がない。
【００１８】
更に、本方法は特定の取引に対して認可ツリーを用いることにより、そのタイプの取引を認可できる職務の組み合わせを決定する。
【００１９】
企業間認可に関わる本発明の別の特徴として、認可ツリーのハッシュド・バージョンが使用され、それにより会社の承認構造に関する最小の情報を明かすことにより、所与のユーザが取引を行うことを認可される証明を提供する。このように、本方法は会社の決定構造の詳細を曖昧化する態様において、その決定構造の確認を可能にする。
【００２０】
【発明の実施の形態】
図１を参照すると、取引認可方法（ＴＡＭ：Transaction Authorization Method）２が、電子商取引において契約４の有効性を保証する手段を提供し、ここでこうした契約はそれらの有効性が容易に確認できるように構築される。
【００２１】
ＴＡＭ２は、分散ワークフロー管理システム６内で動作するメッセージ交換機構を有する。方法２は、１）依頼１０を認可するために、ユーザ８によりアクセス可能であり、２）幾つかのデータベース７０、８２、９６または２０２（図１１参照）へのアクセスを有し、３）ユーザに接触して、署名１８を要求する属性を有する。
【００２２】
ＴＡＭ２は、コンピュータ・ネットワーク２５または３１（図２参照）を介する分散システム２１内のコンピュータ・システム２０上で動作する。ここで分散システム２１は、複数の相互接続コンピュータ２２及び複数の資源２３を含む。ＴＡＭ２はコンピュータ読取り可能媒体上で符号化されて、コンピュータ・システム２０上で、またはイントラネット２５またはインターネット３１上のコンピュータ・システム及び１つ以上のサーバ（５４ａ、５４ｂ）間で動作する。
【００２３】
コンピュータ・システム２０は一般に、コンピュータ２２、表示装置２４、キーボードなどの入力装置２６、１次記憶装置３０、及び２次記憶装置３２を含む。本発明のＴＡＭ２により符号化されたソフトウェアのローディングの後、また場合によっては、インターネット・エクスプローラ５．０などのブラウザを通じてサーバ２５または５４をアクセスした後、表示装置２４がグラフィカル・ユーザ・インタフェース（ＧＵＩ）３４を表示することにより、本方法に関連付けられるテキスト及びグラフィックスのユーザへの表示を容易にする。表示装置２４はプリンタ及びコンピュータ表示画面を含み、後者にはＣＲＴ、ＬＥＤ表示装置、ＬＣＤ、フラット・スクリーン、スクリーン・フォーン（screen phone）、及びプロジェクタなどが含まれる。入力装置２６は多数から成り、キーボード及びポインティング・デバイスを含む。ポインティング・デバイスには、左マウス・ボタン２８及び右マウス・ボタン２９を有するマウス２７、トラック・ボール、ライトペン、サムホイール、デジタイジング・タブレット、音声認識ソフトウェアを使用するマイクロフォン、及びタッチ・スクリーン及びパッドが含まれる。
【００２４】
各資源２３はコンピュータ２２の少なくとも１つに動作上接続され、本方法２のプロセス・フローにおいて、少なくとも１つの活動を実行する。資源２３には、プリンタ、データベース、特殊用途サーバ、セキュリティ装置、モデムなどが含まれる。
【００２５】
ＧＵＩ３４はデータ入力及びＴＡＭ２の制御のための入力フィールド、並びにステータス及び他の情報の表示のための出力ウィンドウを提供し、ワークフロー・システムの管理及び操作を容易にする。ＴＡＭ２は以下で詳述するように、取引に関連する情報を含むデータベース３３をアクセスする。
【００２６】
コンピュータ２２はＣＰＵ３６、並びに当業者には周知の他のコンポーネントを含む。これらのコンポーネント及びそれらの相互作用についての詳細については、米国特許第５７８７２５４号を参照されたい。２次記憶装置３２はＴＡＭ３２をサポートし、好適にはＨＴＴＰ準拠であり、同様に多数のインターネット・アクセス・ツールをサポートする。ＣＰＵ３６は、バス４２に接続される入出力サブシステムなどのインタフェース４１を介して、１次記憶装置３０からコンピュータ命令をフェッチする。コンピュータ２２は、例えばＩＢＭの製品である"ＩＢＭアプティバ"・コンピュータ、或いはインテル社のＸ８６またはPentium（商標）シリーズ・プロセッサまたは互換プロセッサにもとづく、ＩＢＭ ＰＣコンピュータ・システムと互換の任意の他のコンピュータ、若しくは他の好適なコンピュータである。ＣＰＵ３６はオペレーティング・システムを使用し、これは使用するハードウェアに応じてＤＯＳ、"ウィンドウズ３．Ｘ"、"ウィンドウズＸＸＸＸ"、"ＮＴ"、"ＯＳ／Ｘ"、"ＡＩＸ"、"ＬＩＮＵＸ"、または任意の他の好適なオペレーティング・システムである。ＣＰＵ３６はこれらのフェッチされたコンピュータ命令を実行する。これらの命令の実行は、ＣＰＵ３６がデータを取り出したり、データを１次記憶装置３０に書込んだり、ＴＡＭ２の統計表示などの情報を１つ以上の表示装置２４上に表示したり、１つ以上の入力装置２６からコマンド信号を受信したり、データを２次記憶装置３２または集合的にコンピュータ・ネットワーク２５（図２参照）を形成する他のコンピュータ・システムに転送したりすることを可能にする。当業者であれば、１次記憶装置３０及び２次記憶装置３２が、任意のタイプのコンピュータ記憶装置を含み得ることが理解できよう。それらにはＲＡＭ、ＲＯＭ、特定用途向け集積回路（ＡＳＩＣ）、及びＣＤ−ＲＯＭなどの磁気及び光記憶媒体を含む記憶装置が含まれる。
【００２７】
図３を参照すると、電子商取引の間にオンラインで実行される取引４０の多くのクラスが存在する。この開示では、各取引４０が依頼者４２と検証者または値提供者４４との間で発生する。依頼者４２は製品またはサービス４６を所望し、値提供者４４は、依頼者の依頼書５２を表す電子文書５０が適切に認可されていることを確かめたいと思う。すなわち、値提供者４４は文書５０の信頼性を確認したいと思う。ほとんどの一般的な状況では、依頼者４２及び検証者４４は同一の会社により雇用されていることも、そうでないこともある。
【００２８】
例えば、依頼書５２に関連付けられる文書５０は、製品またはサービスの契約であり、例えば要求元会社の社員から会社の旅行業者への、または出張のための必要資金が使用可能か否かを判断するために、社員から同一会社の金融当局者へ提出される出張依頼書５４（図６参照）である。
【００２９】
図４を参照すると、本方法のより詳細なフロー図が示される。そこでは、ＴＡＭ２が次のステップを実行する。第１のステップ６０で、従業員が取引４０をＴＡＭ２から要求する。第２のステップ６２で、ＴＡＭ２が取引４０の詳細６６のＨＴＭＬ表現６４を、デジタル文書データベース（ＤＤＤ：Digital Document Database）７０（図７参照）から要求する。第３のステップ７２で、デジタル文書データベース７０が取引詳細６６のＨＴＭＬ表現６４をＴＡＭ２に返却する。第４のステップ７４で、ＴＡＭ２が取引当局（ＴＡ：Transaction Authority）８０の職務証明書７６を、職務証明書データベース（ＲＣＤ：Role Certificate Database）８２から要求する。職務証明書データベースは、匿名の職務証明書から成り（ここで匿名性は、ユーザの名前が証明書内に含まれていないことによる）、これはＴＡ８０の職務証明書を含む（これについては以下で詳述する）。第５のステップ８４では、職務証明書データベース８２がＴＡ８０の職務証明書７６を返却し、ＴＡＭ２がデジタル文書データベース７０から返却された取引依頼詳細６０のＨＴＭＬ表現６４上のＴＡの署名１２６を確認する。第６のステップ８６では、ＴＡＭ２がＨＴＭＬ取引詳細６６を依頼者４２に返却する。第７のステップ９０では、依頼者がＨＴＭＬ表現６４を見て、指定された詳細（例えば名前、行き先、費用など）を完成し、完成されたＨＴＭＬ表現６４を署名し、残りの署名を収集するために、署名済みのＨＴＭＬ表現をＴＡＭ２に返却する。第８のステップ９２では、ＴＡＭ２が取引の認可構造（ＡＳ：Authorization Structure）９４を、認可構造データベース（ＡＳＤ：Authorization Structure Database）９６から要求する。返却された認可構造９４がＴＡ８０により事前署名され、署名がＴＡＭ２により確認される。ＴＡＭ２は職務名１０２の承認セット１００及び関わるユーザの収集を選択して、これらの職務名に署名する。第９のステップ１０４では、ＴＡＭ２が一般社員依頼者４２の署名１０６を有する取引依頼書５２の取引詳細６６を、承認セット１００に対応する職務を有する他の者に転送し、承認セット１００に含まれる各々の職務の署名を収集する。例えば、課長及び部長の署名が収集され、各々が文書５４のそれぞれの職務欄に署名される。第１０のステップ１１０では、ＴＡＭ２が承認セット１００の各メンバの職務証明書７６及びそれぞれの署名を要求する。第１１のステップ１１２では、ＴＡＭ２が署名１０６及び職務証明書７６を含む文書５４を依頼者４２に転送する。こうして、取引４０の有効性を確認するために要求される全ての認可詳細６６を含むデジタル文書１１４が作成される。ステップ１１６では、任意的に、本方法２は署名済み文書１１４を確認する。
【００３０】
図１０を参照すると、本方法２において、匿名職務証明書７６は署名確認キー１２０と職務名１２２との関連を示す。これは署名１０６の確認キー１２０と名前（図示せず）との関連を示す、ＩＴＵ−Ｔ Ｘ．５０９（１９９７Ｅ）（以下Ｘ５０９と記す）で述べられる標準の証明書とは異なる。より詳細には、Ｘ５０９は公開キーと名前との関連であり、公開キーは暗号化及び署名確認の両方のために使用される。しかしながら、本方法２はユーザが職務資格１２２において暗号化を実行することには関わらず、ユーザが職務資格において署名１０６を生成することに関するものである。職務証明書７６は証明書の所有者に関連する情報を有さないことにより匿名である。証明書Ｃｅｒｔの所有者は、証明書内に埋め込まれた公開キーに対応する私用キーを有するユーザとして暗に定義される。
【００３１】
職務証明書７６は本方法２において重要な役割を果たす。ここで任意の会社Ｃにおいて、明確な職務ＲＣ＝｛Ｒ１、Ｒ２、．．、Ｒｍ｝のセットが存在し、会社Ｃ内の各ユーザＵが１つまたは複数の職務ＵＲ⊆ＲＣを割当てられると仮定する。本方法２の目的上、各ユーザは彼らの名前、公開キー及び他のフィールドを含み、ローカル認証局ＣＡ（certificate authority）により署名されたＸ．５０９公開キー証明書ＣｅｒｔＣＡ（Ｕ）を有するものとする。Ｘ．５０９証明書は、電子メール・アドレス、代替名、及び方針情報などの一般情報のための拡張フィールドを含むので、指定された職務１２２が拡張フィールドとして含まれることは可能である。しかしながら、証明書は名前フィールドを含むので、職務１２２及び証明書の所有者は明示的にリンクされる。ＩＥＴＦワーキング・グループも職務１２２、グループ・メンバシップ、及び名前への保全許可（security clearance）などの属性を結びつける属性証明書（ＡＣ：attribute certificate）の概念を現在開発中である（S．Farrellによる"An Internet Attribute Certificate Profile for Authorization"、August 20、1998参照）。しかしながら、属性証明書は公開キーを含まないので、属性証明書内で指定される名前は、既存のＸ．５０９ＣｅｒｔＣＡ（Ｕ）内で指定される個人Ｕに関する補足情報を提供するように意図される。証明書保持者の名前はＡＣ内に含まれるので、名前及び職務は直接リンクされる。本方法２の目的上、職務証明書７６及び属性証明書の両方が受け入れ可能である。なぜなら、本方法は職務１２２を含む証明書を使用してアクションを認可するからであるが、本方法では、職務がそれが割当てられるユーザに直接関連付けられないことが望ましい。
【００３２】
従って、本方法２はユーザＵに対して、匿名職務証明書７６（ＣｅｒｔＣＡ（Ｕ、Ｒ））を使用し、これは次の変更を有するＸ．５０９ｖ３証明書である。すなわち、１）名前フィールドが架空のユーザを表す、２）ユーザＵの職務１２２を含む拡張フィールドが存在する、３）Ｃｅｒｔ（ｕ）からＣｅｒｔ（ｕ、Ｒ）への順方向参照をを含む拡張フィールドが存在する。
【００３３】
順方向参照は、例えばＥ（Ｃ、Ｕ、パスワード）の形式を取り、これは会社Ｃの公開キーまたはローカル認証局の公開キーによる、ユーザＵ及びパスワードの連結の公開キー暗号化を示す。順方向参照は単に、会社が職務証明書の所有者を識別するための機構であり、本方法にとって他の重要性は有さない。ユーザＵが幾つかの職務１２２を有する場合、各職務に対する職務証明書７６が存在する。ここで重要な点は、各職務証明書が公開キー及び対応する私用キーを有し、それによりユーザが彼らの資格において署名を生成することである。従って、各ユーザは少なくとも２つの証明書、すなわち、彼らの名前を公開キーに結びつける標準のＸ．５０９ｖ３証明書ＣｅｒｔＣＡ（Ｕ）、及び彼らの職務を公開キーに結びつける匿名職務証明書７６（ＣｅｒｔＣＡ（Ｕ、Ｒ））を有する。ＣｅｒｔＣＡ（Ｕ）は順方向参照によりＣｅｒｔＣＡ（Ｕ、Ｒ）にリンクされるが、所与のＣｅｒｔＣＡ（Ｕ、Ｒ）に対して、ユーザＵのＣｅｒｔＣＡ（Ｕ）または識別を決定する明白な方法は存在しない。本方法２の目的上、職務証明書７６（ＣｅｒｔＣＡ（Ｕ、Ｒ））に関連付けられる私用キー１２４により生成される署名１０６は、職務署名１２６として定義される。
【００３４】
従って、ユーザが取引４０上に署名１２６を生成すると、検証者１３０は、例えばユーザが課長かそれとも部長か、或いはこの職務が所与の業務に如何に関係するかなど、ユーザが社内で有する職務１２２に関心を持つ。ユーザによって引き受けられる職務１２２だけが、業務が認可されたか否かを確認する上での関心事であるので、ユーザの識別や名前は実際には重要ではない。
【００３５】
図５を参照すると、確認作業を達成するために、ＴＡＭ２は作成され署名済み文書１１４の確認を可能にする確認補助方法１１６を含む。第１のステップ１３２では、職務署名１２６が文書１１４上でチェックされる。第２のステップ１３４では、取引が認可された取引であることを保証するために、取引タイプ自身がチェックされる。第２のステップ１３４のサブステップ１３６では、職務名１２２が職務証明書７６から抽出される。第２のステップ１３４の第２のサブステップ１４０では、職務名１２２がハッシュされる。第２のステップ１３４の第３のサブステップ１４２では、取引４０の計算されたハッシュ値が、認可構造（ＡＳ）９４内で受信された取引４０の値に等しいことを保証するために、チェックが行われる。第２のステップ１３４の第４のサブステップ１４４では、取引４０上のＴＡ８０の署名１２６が正しいことを保証するためにチェックが行われる。正しい場合、取引４０が確認され、この事実の通知が依頼者４２に送信される。
【００３６】
このように、確認は単に署名をチェックするプロセスであり、検証者１３０は取引４０の詳細６６には関わらない。ここで署名者が取引４０の詳細６６をチェックし、これらの詳細が所与のタイプＴの取引に関する会社方針から外れる場合、彼らの署名１０６を保留するものとする。この仮定は再度、検証者１３０が一般に、署名済み用紙の詳細にではなしに、提供される署名により関心を寄せる書式署名モデルに固有である。
【００３７】
この残りの詳細説明では、出張依頼取引がＴＡＭ２のステップを説明するために使用される。
【００３８】
図６を参照すると、ＩＢＭ出張依頼書５４の構造が示される。従来、書類文書が、特に出張依頼の承認などの様々な取引に使用されてきた。取引当局（ＴＡ）８０（図７参照）の業務は、これらの書類用紙をデジタル文書６４（幾つかの可能な書式が存在するが、好適にはＨＴＭＬ形式）に変換することである。各書式に対してＴＡ８０は取引詳細６６と見なされるもの、及び認可情報１４６と見なされるものを分離する。出張依頼書５４では、取引詳細６６は依頼者名、行き先、旅費、出発日などが含まれる。書類用紙及びそれから構成されるＨＴＭＬ文書６４上では、ほとんどの取引詳細６６は単に、依頼者４２により提供される情報のプレースホルダである。
【００３９】
認可詳細１４６は一般に、取引４０を連帯で認可するように要求される人達の職務１２２のリストから成る。書類用紙の認可とは、通常、それに署名することを意味し、ＨＴＭＬ文書６４では、認可詳細６６は、どの職務１２２のどの人間が取引４０を認可するかを示す。出張依頼書５４では、出頭依頼を認可する承認セット１００に対応する認可詳細６６が、依頼者１６５、課長１６７、及び部長１６９の電子署名１０６から成る（図９参照）。これは依頼者４２、及び課長の職務１２２の人間、及び部長の職務１２２の人間が、デジタル的にＨＴＭＬ書式６４に署名しなければ、それが認可されないことを意味する。
【００４０】
図７を参照すると、出張依頼書６４に対してＴＡ８０は出張取引詳細６６をＨＴＭＬで作成し、これらの詳細に署名し、署名済み文書をデジタル文書データベース７０に記憶する。従って、ＴＡ８０の職務を、関連署名確認キー１２０を含むＴＡ職務証明書７６（図８参照）を交付された人間に割当てることが必要である。ＴＡ８０はまた、突き合わせ署名キー１５０を別に交付される。ＴＡ８０署名キー１５０と一緒に生成される署名は、ＴＡ職務証明書７６内の確認キー１２０と共に確認される（図１０参照）。
【００４１】
ＴＡ８０は出張依頼書６４の認可構造９４を生成し、文書に署名し、次に認可構造データベース９６に記憶する。認可構造９４は、取引４０を認可するために使用される職務を表す。
【００４２】
デジタル文書データベース７０及び認可構造データベース９６内の情報は、それ自体秘密であることを要求されない。しかしながら、情報の保全性が保護されることは必要である。この理由から、ＴＡ８０はこうした文書に署名しなければならない。
【００４３】
図８を参照すると、認可構造（ＡＳ）９８が如何に生成されるかに関する詳細は、本発明の主題でない社会的及び戦略的管理要因に依存する。認可構造９８の主な属性は、その構造が承認セット１００の概念に依存することである。承認セット１００が意味する内容を説明するために、セットＰＴ、１＝｛Ｕ、Ｍ、ＤＨ｝が取引Ｔの承認セットとする。この例では、取引Ｔが１つの承認セットだけを有するが、一般には、取引はＰＴ、１、ＰＴ、２、．．．、ＰＴ、ｊにより示される幾つかの承認セットを有する。各承認セット１００は職務１２２のセットを含み（すなわち、ＰＴ、ｉ⊆Ｒ、潜在的に複数セット）、任意のユーザＵが、Ｄ（Ｔ、Ｕ）により表される取引Ｔに対して認可されることを意味する。Ｔのある承認セットＰＴ、ｉ＝｛Ｒ１、Ｒ２、．．．、Ｒｍ｝に対して、職務Ｒ１、Ｒ２、．．．、Ｒｍのｍ人のユーザが、彼らのそれぞれの証明書を用いてＤ（Ｔ、Ｕ）に署名する。
【００４４】
この時、承認セット１００すなわち（ＰＴ、ｉ）は、職務１２２のセットを表し、それらの連帯当局者が、タイプＴの取引４０を認可するために十分であると見なされる。ツリー１５４（図９参照）は、取引Ｔの承認セット１００すなわちＰＴ＝｛ＰＴ、１、ＰＴ、２、．．．、ＰＴ、ｋ｝を表すために使用される。書式署名モデルに関して、ＰＴはタイプＴの取引を認可するための決定プロシージャを示す。Merkleによる米国特許第４３０９５６９号は、こうしたツリー１５４の一般的な使用について述べている。
【００４５】
図９を参照すると、各取引タイプＴに対して認可ツリー（ＡＴ：auhorization tree）１５４は、ルートからの第１のレベル１６０に、ｋ個のノード１５６が存在するように生成され、これらのノードは取引タイプＴに対するｋ個の承認セット１００、すなわちＰＴ＝｛ＰＴ、１、ＰＴ、２、．．．、ＰＴ、ｉ｝に対応する。第２のレベル１６４のノードはリーフ１６６であり、各承認セット１００の職務１２２を表す。
【００４６】
取引Ｔに対する承認セット１００（ＰＴ）が、ＰＴ、１＝｛Ｒ１、Ｒ２｝及びＰＴ、２＝｛Ｒ３、Ｒ４、Ｒ５｝及びＰＴ、３＝｛Ｒ６｝の場合、ＡＴ１５４は２つのレベルを有する。第１のレベル１６０は、３つのノード１５６によるＰＴ、１、ＰＴ、２及びＰＴ、３を表し、各ＰＴ、ｉ１００は、承認セット内の職務１２２の数と同一の数のリーフ１６６を有する。従って、例えばＰＴ、１（１００）は図９に示されるように、Ｒ１及びＲ２を表す２つの子（両方ともリーフ１６６）を有する。
【００４７】
少なくとも１つの承認セット１００すなわちＰＴ、ｉにおいて、ＰＴ、ｉ内の各職務１２２の署名が獲得される場合、取引４０は認可されたと見なされるので、ＰＴ、ｉを表すノード１５６は"ＡＮＤ"ノード１７０と見なされ、ＡＴ１５４のルート１６２は"ＯＲ"ノード１７２と見なされる。ＡＮＤノード１７０は、ノードの全ての子が依頼書Ｄ（Ｔ、Ｕ）に同意しなければならないことを意味し（承認セット１００内の全ての職務１２２が署名しなければならない）、ＯＲノード１７２は少なくとも１つの子が依頼書Ｄ（Ｔ、Ｕ）に同意しなければならないことを意味する（少なくとも１つの承認セットが連帯署名しなければならない）。或いは、ＡＴ８０は、取引４０を認可できる職務１２２の離接的表現（disjunctive representation）と解釈されてもよい。
【００４８】
図８を参照すると、出張依頼書６４では、承認セット１００が依頼者４２、課長及び部長から成る。これらは以下で詳述される。
【００４９】
図１０を参照すると、認可構造（ＡＳ）９８は承認セット１００にもとづき、これらのセットが指定の職務１２２からなるので、各ユーザは職務名により指定される１つ以上の職務を交付される。ユーザは彼らの資格において、所与の職務名１２２の下で署名することを要求されるので、ユーザは次に職務証明書７６を交付される。職務証明書７６は職務名１２２、署名確認キー１２０、職務証明書７６上の役職者署名１０６、及び他の管理情報（職務証明書の交付日時、満了日時など）を含む。ユーザが職務証明書７６を与えられるとき、職務証明書内の確認キー１２０に合致する対応する署名キー１５０も与えられる。実際、ユーザは対応する署名キー１５０を所有することにより、彼が所与の職務証明書７６を所有することを証明する。結果的に、署名キー１５０はそれが交付されるユーザにより、秘密にされなければならない。交付される職務証明書７６の各々もまた、職務証明書データベース８２（ＲＣＤ）に記憶される。
【００５０】
以上で、本方法２の初期化が完了する。要するに、初期化は書類用紙からデジタル文書６４への変換と、取引当局８０による署名を含む。更に、ＴＡ８０が各取引４０に対する認可構造９８（ＡＳ）を決定し、この認可構造にも署名する。認可構造９８内の情報は指定された職務にもとづき、職務当局１８０は各ユーザに１つ以上の職務証明書７６を交付する。職務当局１８０から交付される指定職務１２２のセットが、認可構造９８の構造内のＴＡ８０により使用される。
【００５１】
次に図１１を参照しながら、出張依頼書６４を認可する例について述べる。ここでユーザが出張依頼書を作成し、それを認可してもらいたいと仮定する。出張認可のユーザすなわち依頼者４２は、これをＴＡＭ２の支援を通じて達成する。好適な実施例では、ＴＡＭ２は会社のイントラネット２５上のサーバ・アプリケーションであり、ブラウザなどのＷｅｂインタフェースを介して接続され得る。従って、ユーザはそのＵＲＬを介してＴＡＭ２と連絡でき、自身が出張依頼書６４を作成したいことを示す。ここで、出張依頼書の依頼者４２の職務は一般社員である。
【００５２】
第１のステップ１８２では、ユーザすなわち社員４２がＴＡＭ２から、出張依頼取引４０を要求する。ＴＡＭ２はユーザ４２から出張依頼書５２を受信し、デジタル文書データベース７０と連絡を取り、このクラスの取引４０の取引詳細６６のコピーを獲得する。デジタル文書データベース７０はＨＴＭＬで表された詳細６６をＴＡＭ２に返却する。ここでＨＴＭＬは事前に取引当局（ＴＡ）８０により署名済みである。
【００５３】
第２のステップ１８４では、ＴＡＭ２が取引詳細６６のＨＴＭＬ表現６４をデジタル文書データベース７０から要求する。ＨＴＭＬ詳細が正しいか否かをチェックするために、ＴＡＭ２はＴＡ８０の職務証明書７６を職務証明書データベース８２（これはまた一般社員１６５、課長１６７、部長１６９及び他の職務の職務証明書、並びに会社内の異なるレベルの管理を含む）から要求し、次に署名１０６を確認する。署名が適正な場合、ＴＡＭ２は継続する。
【００５４】
第３のステップ１８６では、デジタル文書データベース７０が出張依頼取引詳細６６のＨＴＭＬ表現６４を返却する。
【００５５】
第４のステップ１９０では、ＴＡＭ２がＴＡ８０の職務証明書７６を、職務証明書データベース８２から要求する。第５のステップ１９２では、職務証明書データベース８２がＴＡ８０の職務証明書７６を返却し、ＴＡＭ２がデジタル文書データベース７０から返却された、取引依頼詳細６６のＨＴＭＬ表現６４上のＴＡの署名１０６を確認する。
【００５６】
第６のステップ１９４では、ＴＡＭ２がＨＴＭＬ取引詳細６６を依頼者４２に返却し、依頼者のブラウザが詳細をＨＴＭＬ形式６４として表示する。そしてこれは入力を要求する。要求される入力は、出張依頼書５４の取引詳細６６の構成要素となる。第７のステップ１９６では、依頼者４２がＨＴＭＬ表現６４を見て、指定された詳細６６（例えば名前、行き先、費用など）をブラウザを通じて完成し、完成されたＨＴＭＬ表現６４に署名する。ユーザすなわち依頼者４２は、彼らの職務すなわち"一般社員"を示す職務証明書７６に署名済みである。
【００５７】
第８のステップ２００では、ＴＡＭ２が署名済みの依頼者入力（すなわち署名済みのＨＴＭＬ表現）をユーザ４２から受信し、次に認可構造データベース９６と連絡し、出張依頼取引４０の認可構造９８を獲得する。ＴＡＭ２はデータベース９６から認可構造９８を受信し、構造上のＴＡ８０の署名１０６をチェックする。認可構造９８からＡＭ２は職務名１２２の承認セット１００、並びにこれらの職務名に署名するために接触するユーザの収集を抽出する。この場合、一人の一般社員の依頼者４２、課長及び部長しか存在しない。
【００５８】
この時点で、ＴＡＭ２の目的は、承認セットを構成する連帯職務１２２の人達からの署名の収集を獲得することである。依頼者４２は既に職務"一般社員"としての署名１０６を提供しており、ＴＡＭ２は職務欄の"課長"１６７及び"部長"１６９に、２つの署名を獲得しなければならない。
【００５９】
ＴＡＭ２はユーザ及び彼らの職務１２２をリストするユーザ・ディレクトリ・データベース２０２をアクセスして、例えば一方の署名１０６として、ユーザ"John Brown"を職務"課長"として、また他の署名として、ユーザ"Sue Smith"を職務"部長"として選択する。
【００６０】
第９のステップでは、ＴＡＭ２が取引依頼詳細６６を一般社員依頼者４２の署名１０６と一緒に、依頼者の課長John Brownに転送する。John BrownのブラウザはＨＴＭＬ出張用紙６４を、依頼者の記入済みの取引詳細６６と一緒に表示し、また依頼者４２により提供される署名１０６が正しい旨を示す。John Brownは次に出張依頼書５４を認可するか否かを決定する。認可が与えられる場合、John Brownは出張依頼書５４のＨＴＭＬと、依頼者４２により提供された出張詳細６６とに署名し、それらがＴＡＭ２に返却される。
【００６１】
第１０のステップでは、ＴＡＭ２が取引依頼書６４を署名１０６と共に、"部長"のSue Smithに転送する。Sue Smithは出張依頼書５４の詳細６６及び依頼書上の前の署名のセットを提供される（この場合、依頼者４２による署名、及びJohn Brownの署名）。全てが妥当な場合、Sue Smithは部長としての彼女の職務において受信した全ての情報に署名し、これをＴＡＭ２に返信する。
【００６２】
第１１のステップでは、ＴＡＭ２が承認セット１００を構成することを意図する署名１０６のセットを受信する。これが実際に真実であることをチェックするために、ＴＡＭ２は依頼者４２、John Brown課長、及びSue Smith部長の職務証明書７６を受信し、全ての署名を確認する。第１２のステップでは、署名１０６が有効と確認されると、ＴＡＭ２は署名及び職務証明書７６を含む文書６４を依頼者４２に転送する。こうして、取引４０の正当性を確認するために要求される全ての認可詳細６６を含む、図１２に示されるデジタル文書１１４が生成される。これで依頼者４２は出張依頼書上に、この取引４０のクラスの承認セット１００を構成する署名１０６のセットを保持することになる。この情報は、依頼者４２が出張依頼書５４の申請を実際に認可されたことに関して、検証者１３０として示される別のユーザを納得させるために使用される。
【００６３】
図１２を参照すると、完成された取引４０が示され、取引詳細６６及び依頼者４２により保持される署名１０６を有する。詳細には、１）ＴＡ８０により署名された取引詳細のＨＴＭＬ、及び２）ユーザにより提供される入力を含み、これらの両者は依頼者４２により署名され、更に３）この情報が課長により多重署名され、全てが部長により多重署名される。
【００６４】
図１３を参照すると、依頼者４２により保持される職務証明書７６及び認可構造９８が示される。
【００６５】
次に図１４を参照して、取引処理として、依頼者４２が出張依頼書５４を検証者１３０に転送することに関連するステップについて述べる。この方法は確認補助方法１１６と呼ばれる。
【００６６】
この確認方法をより理解するために、認可構造９８が如何に構築されるかについての詳細を理解することが重要である。確認補助方法１１６は暗号ハッシュ関数を使用し、これが任意のストリングを、例えば１６バイトまたは２０バイトの固定長出力にマップする。出張依頼書５４の場合、認可構造９８は承認セットを構成する３つの職務１２２にハッシュする（従って、会社の実際の認可構造にハッシュする）ことにより構築される。すなわち、それらはＨ１＝ハッシュ（一般社員）、Ｈ２＝ハッシュ（課長）、及びＨ３＝ハッシュ（部長）である。
【００６７】
例えば、Ｈ１はストリング"一般社員"のハッシュであると言われる。最後に、Ｈ１、Ｈ２及びＨ３はストリングとして処理され、連結されて、次にＴ＝ｈａｓｈ（Ｈ１、Ｈ２、Ｈ３）としてハッシュされる。言い回しは"取引当局８０（ＴＡ）が認可構造９８に署名する"となり、これは取引当局が取引Ｔ４０の値に署名することを意味する。従って、ＴＡ８０は"ハッシュのハッシュ"（hash of hashes）に署名することになる。
【００６８】
全てのユーザは、ＴＡ８０により署名される認可構造が、最初に職務１２２の収集をハッシュし、次にこれらの値をもう一度ハッシュすることにより導出されることを知る点で、認可構造９８（ＡＳ）に署名するこの一般的な方法を承知している。
【００６９】
出張依頼例を特に参照すると、依頼者４２は１）ＴＡ８０により署名されるＨＴＭＬ形式の出張依頼書５４と、２）職務が"一般社員"、"課長"及び"部長"の３人のユーザに対応する３つの職務証明書７６と、３）図１２に示されるように、最初に一般社員により、次に課長、次に部長により署名される取引詳細６６と、４）図１５に示されるようなハッシュ結果の職務１２２上の署名を送信する。
【００７０】
図５を再度参照すると、ＴＡＭ２は検証者１３０が作成された署名済み文書１１４を確認することを可能にする確認補助方法１１６を含む。検証者は基本的に、依頼者４２が取引４０、この場合、出張依頼書５４を認可されるか否かの確認に関心がある。依頼者４２は検証者１３０に、取引ＨＴＭＬ（ＴＡ８０により署名済み）、職務証明書７６の収集、職務証明書内の確認キー１２０に対応する各署名キー１５０により署名された取引詳細、及び認可構造９８を送信する。図１０から、各職務証明書１２２は職務当局１８０（ＲＡ）により署名されることが思い起こされる。第１のステップ１３２では、検証者１３０は職務当局１８０の確認キー１２０を用いて、文書１１４上の各職務証明書７６をチェックする。第２のステップ１３４では、検証者１３０が提供された職務証明書７６内の確認キー１２０を用いて取引詳細６６上の署名１０６をチェックする。第２のステップ１３４のサブステップ１３６では、依頼者４２が認可されるか否かをチェックするために、検証者１３０は職務証明書７６から指定職務１２２を抽出する。第２のステップ１３４の第２のサブステップ１４０では、職務名が前述のハッシュのハッシュ・プロセスを用いてハッシュされる。第２のステップ１３４の第３のサブステップ１４２では、取引４０の計算されたハッシュ値が取引当局８０により当初署名された値に対してチェックされ、それが認可構造９８内で受信された取引４０の値と等しいことを保証する。次に、ハッシュのハッシュ・プロセスの出力が、ハッシュのハッシュ・プロセス上の署名１０６をチェックする入力として使用される。第２のステップ１３４の第４のサブステップ１４４では、生成されたハッシュのハッシュ・ストリングがＴＡ８０により署名されたハッシュド・ストリングに合致する場合、検証者１３０は依頼書５２が認可されるものと想定する。合致する場合、取引４０は確認されたことになり、この事実の通知が依頼者４２に送信される。
【００７１】
前述の補助方法１１６において、ＴＡＭ２は依頼者４２からの情報を検証者１３０に転送する。任意的に、依頼者４２から検証者１３０への転送は、電子メールにより行われてもよい。依頼者４２は局所的にＴＡＭ２を使用し、全ての認可詳細６６を収集し、この全ての情報を電子メールを介して検証者１３０に送信する。例えば、全ての署名１０６及び費用が収集され、次に依頼書５２が旅行業者に電子メールにより転送される。続いて旅行業者が予約を行う。
【００７２】
これまで、依頼者４２及び検証者１３０は同一会社に所属すると仮定してこなかった。これは必要ではない。なぜなら、本方法２は検証者１３０が同一会社に所属するか否かに関わらず機能するからである。彼らが同一会社に所属する場合、彼らはイントラネット２５により接続されて、同一のサーバ５４ａを共有するかもしれない。検証者１３０の位置はそれ自身、重要でない。検証者１３０の職務１２２は、依頼者４２により提供される情報を確認することである。
【００７３】
取引４０の正当性を確認するために、検証者１３０は以下のことを必要とする。
１）取引４０において使用される職務証明書７６上の署名１０６の正当性をチェックするために使用される、職務当局１８０の署名確認キー１２０。
２）認可構造９８上の署名１０６の正当性をチェックするための、取引当局８０の署名確認キー１２０（ハッシュのハッシュ・プロセス）。
３）認可構造９８上の取引当局８０の署名がチェック可能なように、指定職務１２２を収集し、ハッシュのハッシュ・プロセスを実行する方法の知識。
【００７４】
職務当局１８０及び取引当局８０の署名確認キー１２０は、それらが秘密にされる必要がない点で公開情報である。従って、それらは全ての者により使用可能で、確認可能と見なされる。ハッシュのハッシュ・プロセスは、全ての潜在的な検証者１３０により本方法２を用いて理解される必要がある。
【００７５】
ハッシュのハッシュ・プロセスは前述の出張依頼書５４の例では、極めて単純である。なぜなら、１つの承認セット１００しか存在しないからである。しかしながら、基本方法２は次のように、幾つかの承認セット１００を含むように拡張され得る。例えば、出張依頼５４はＣＥＯ及びＣＥＯ秘書により認可され、この場合、出張依頼書の２つの承認セット（Ｐ１及びＰ２）は、Ｐ１＝｛一般社員、課長、部長｝及びＰ２＝｛ＣＥＯ、ＣＥＯ秘書｝となる。
【００７６】
承認セット１００及びそれらを構成する職務１２２は、図９に示されるような認可ツリー１５４（ＡＴ）に構成される。認可ツリー１５４は認可構造の１例である。取引当局８０が認可構造９８に署名するために、ＡＴは最初にストリングに変換されなければならず、これは前述と類似のハッシュのハッシュ・プロセスを用いて行われる。
【００７７】
最初に、各職務名１２２はＨ１、Ｈ２、Ｈ３、Ｈ４、Ｈ５を次のように与えるようにハッシュされる。
Ｈ１＝hash（一般社員）
Ｈ２＝hash（課長）
Ｈ３＝hash（部長）
Ｈ４＝hash（ＣＥＯ）
Ｈ５＝hash（ＣＥＯ秘書）
これらの値は、各承認セットの１つのハッシュを獲得するために、次のようにハッシュされなければならない。すなわち、Ｈ６＝hash（Ｈ１、Ｈ２、Ｈ３）、Ｈ７＝hash（Ｈ４、Ｈ５）である。ここでＨ６は承認セットＰ１のハッシュであり、Ｈ７は承認セットＰ２のハッシュ（Ｐ２'）である。従って、各承認セット１００に対して１つのハッシュが存在することになり、これらは承認セット・ハッシュと呼ばれる。ここでhash（Ｈ１、Ｈ２、Ｈ３）は、Ｈ１、Ｈ２及びＨ３が連結され、続いてハッシュされるストリングであることを意味する。最後に、認可ツリーのハッシュはＴ＝hash（Ｈ６、Ｈ７）として生成される。
【００７８】
このハッシング・プロセスは図１５に示される。取引当局８０により署名されるのは取引４０の値である。
【００７９】
検証者１３０は取引４０上の署名を用いて、前述の１つの承認セット１００を有する例の場合と同様に、依頼者４２が所与の取引４０（この場合出張依頼書５４）に関して認可されることをチェックする。
【００８０】
取引４０上の署名１０６を確認するために、検証者１３０は、図９及び図１５に関連して前述したツリー・ハッシング・プロセスの全部または一部を繰り返す。ここで図１５では、ハッシュされた参照項目が、未ハッシュの参照番号に続くプライム符号により、図９のそれと区別される。依頼者４２が承認セットＰ１を構成する職務の人達からの署名１０６を獲得したと仮定する。この場合、依頼者４２は検証者１３０に３つの職務証明書７６を送信しており、そこから検証者は職務名"一般社員"、"課長"及び"部長"を抽出できる。検証者１３０は次に前述のように、Ｈ１、Ｈ２、Ｈ３及びＨ６を形成することができる。こうして、検証者１３０は、取引４０を認可した承認セット１００の承認セット・ハッシュを形成することができる。
【００８１】
認可ツリー１５４上の署名確認を完了するために、依頼者４２は取引４０を認可する承認セットに加えて、全ての他の承認セット１００の承認セット・ハッシュを検証者１３０に提供する必要がある。前述の例では、Ｐ１は取引４０を認可しているのでＰ２のハッシュが提供されなければならず、これはこの場合、前述のようにＨ７に等しい。
【００８２】
Ｈ７が与えられると、検証者１３０はＴを形成できる。なぜなら、検証者はＨ６を形成することができ、Ｔ上の署名１０６がチェックされ得るからである。従って、認可ツリー１５４上の署名１０６をチェックする目的のために、依頼者４２は検証者１３０に職務証明書７６を送信し、そこから職務１２２が抽出され、ハッシュされて、取引を認可する承認セット１００のハッシュ、並びに取引を認可していない各承認セットのハッシュが形成される。これらの２つの情報により、検証者１３０は取引４０のハッシュ値を計算し、次に署名１０６をチェックする。
【００８３】
前述の出張依頼書では、ＴＡＭ２がワールド・ワイド・ウェブを通じて接触され、従ってＴＡＭはウェブ・サーバ・プロセスと見なされる。本方法のワークフロー・システムでは、ユーザは好適には専用のネットワーク・チャネルを通じてＴＡＭと接触する。両方の実施例は本質的に同じである。すなわち、ＴＡＭ２はユーザによりアクセスされ得るコンピュータ・システム２０上のどこかに存在する。またＴＡＭはまた、データベース７０、８２、４６及び２０２、及び他のユーザをアクセスできる。従来理解されているように、これは例えば電子メールにより、またはウェブへのイントラネットまたはインターネット接続を介して達成され得る。
【００８４】
ＴＡ８０は、ＴＡにより生成される署名１０６が信頼される点で、依頼者４２及び検証者１３０により信頼される。この意味において、ＴＡ８０は取引４０のＨＴＭＬ表現６４を適切に形成し、それに署名するために、また取引の認可構造９８を形成し、それに署名するために信頼される。しかしながら、広義には、ＴＡＭ２は信頼される必要はない。ユーザはＴＡＭ２を信頼して、自分たちのためにあるセキュリティ機能を実行するが、ユーザは代わりにローカル・プロセスを使用して、ＴＡＭにより実行される全ての作業が適切であることを確認してもよい。
【００８５】
ウェブの実施例では、ＴＡＭ２はインターネット３１上の検証者１３０及び依頼者４２の両者によりアクセス可能な独立のサーバ５４ｂである点で、中立である（すなわち、全てにより信頼される）。特に、本当に信頼が置ける構成要素は、（デジタル取引及び認可構造を生成する）取引当局８０と、（前述の職務の人達に職務証明書７６を割当てる）職務当局１８０である。従って、検証者１３０は、取引当局８０によりＨＴＭＬ表現６４及び認可構造９８上に生成された署名１０６、及び職務証明書７６上の署名のための職務当局１８０を信頼するだけでよい。
【００８６】
前述の出張依頼５４では、ＴＡＭ２は依頼者４２のために確実な役割を演じる。なぜなら、ＴＡＭは情報をフェッチし、署名１０６をチェックするからである。しかしながら、全ての情報が例えばサーバ５４ｂ上に存在する公衆データベース（デジタル文書データベース７０、認可構造データベース９６、及び職務証明書データベース８２）内にあることが明らかである。依頼者４２はデジタル文書データベース７０をアクセスし、出張依頼ＨＴＭＬ文書６４を直接獲得し、それ上のＴＡ８０の署名１０６をチェックできる（ＴＡ８０の確認キー１２０は誰でも使用可能である）。依頼者４２は次に署名１０６に必要なユーザと接触して、承認セット１００を形成し、職務証明書データベース８２などをアクセスすることにより署名をチェックする。
【００８７】
ＴＡＭ２がデータベースのフェッチ及び署名の収集を実行するとき、これは本方法が実際に如何に機能するかということを除き、単に依頼者４２にとっての利便性である。信頼ではなく、利便性が決定的な条件の場合には、ＴＡＭ２は全ての当事者により信頼される必要はない。
【００８８】
前述のように、企業内認可及び企業間認可の主な違いは、前者の場合には、会社がその認可構造９８を検証者１３０に明かすことにあまり関わらない。企業間認可の状況では、認可構造が所与の業務に対する認可ツリー１５４であり、全ての認可ツリーの収集を含むデータベースへのアクセスが、社外のユーザには制限されるべきである。
【００８９】
前述の方法２を企業間認可の状況に適応化するための幾つかの方法が存在する。ユーザＵＡ及びユーザＵＢによりそれぞれ表される、会社Ａと会社Ｂとの間の取引４０の最初の例に戻ると、最も直接的なアプローチは、各会社が企業当局（ＥＡ：enterprise authority）を有し、署名１０６を確認するために使用される公開キーが、企業当局により会社のために生成される。企業当局は会社内で発生する全ての取引の検証者であることにより、全ての企業間取引を認可する。取引が認可されると、企業当局はこの趣旨で記述書に署名し、これが別の会社のユーザにより確認され得る。
【００９０】
更に、ＴＡＭ２は好適には分散ワークフロー管理システム６内で動作するが、本方法は単にメッセージ交換機構から構成されてもよい。この実施例では、メッセージ交換機構は、従来のワークフロー管理システム６として動作せずに、代わりに、依頼者４２と社内の特定の職務を有する人間との間で、添付物を有する電子メールまたはＨＴＭＬ電子メールなどの、電子メッセージ・フローを管理する。こうした機構の管理は、ＰＣ常駐型の職務ベースのプログラム（すなわち、ユーザ８の特定の職務に適するようにカストマイズされたプログラム）のような単純なものを通じて、ファイル・サーバ・タイプのデータベース（図１１に示されるデータベース７０、９６、８２及び２０２に類似）、及びデータベースのリレーショナル構造に従うように編成されるプルダウン・メニュー及びサブメニューを用いて実現される。典型的なメニュー項目は、例えば"取引タイプ"であり、これが異なるタイプの取引（例えば"出張依頼書"など）をリストするサブメニューをオープンする。特定の取引４０を活動化すると、こうした取引に要求される承認セット１００を示す別のサブメニューをオープンする。承認セット１００を活動化すると、次に添付物として取引詳細６６を有する電子メールをオープンする。電子メールは承認セット１００内の人達に事前にアドレス指定され、署名の配布及び確認を容易にする。
【００９１】
図１５に示される認可ツリー１５４のハッシュを用いる実施例では、職務ＵＲのユーザが取引４０を要求できる以外に、検証者１３０がユーザの会社の決定構造に関する少量の情報だけを習得する利点を有する。他方、あらゆる企業間要求が確認及び署名のために企業当局（ＥＡ）に渡されるために、ＥＡサーバが潜在的なボトルネックとなる。別の解決策は、他の会社による確認の目的で、公衆インターネット３１上において認可ツリー１５４を会社の外部から使用可能にすることである。もちろん、主な問題は、認可ツリー１５４を直接明かすことにより、会社内の決定プロセスに関する多くの情報が明かされることである。次のセクションでは、企業間認可のために好適な、本方法２の幾つかの変更について述べる。
【００９２】
例えば、企業当局からあらゆる取引４０の直接承認を得なければならない代わりに（すなわち、取引管理者８０が、下級社員が取引を認可する権限を有することを確認する）、企業当局は認可構造９８を承認するだけでよい。この場合、認可の確認は常に企業当局に渡るわけではなく、認可は認可構造９８の要件を満たすだけでよい。
【００９３】
別の利点として、一旦ＴＡ８０が取引及び認可構造９８を生成し、ＲＡ１８０が職務証明書７６を作成すると、本方法２を用いて作成された契約が容易且つ自動的に確認される点で、システム２０は非常に確実となる。
【００９４】
以上、本方法２は１つの職務の承認セット１００により機能することが理解された。しかしながら、２つ以上の職務１２２が承認セット１００内で指定される場合、認可結果の信頼性が向上する利点がある。更に、本方法２の低レベルの資源集中型実施例が、幾つかの職務１２２から成る承認セット１００内の１つ、例えば最初にリストされる職務証明書７６の抽出及び確認により得られる。上級社員の職務証明書７６を最初にリストされるように、承認セット１００の構造を定義することによりこの実施例の信頼性が向上する。それにも関わらず、こうした実施例は、承認セット１００自身の職務内容と併せて、全ての職務証明書７６を抽出及び確認する実施例（すなわち、取引４０上の職務証明書７６が、取引を認可するために要求される特定の職務１２２に実際に対応する）と比較して、本質的に信頼性に劣る。
【００９５】
ここで述べた本発明の実施例において、複数の変形及び変更が可能である。本発明の特定の実施例について述べてきたが、前述の開示において、広範囲の変更及び代替実施例が可能である。ある場合には、本発明の幾つかの機構は、他の機構の対応する使用無しに使用され得る。従って、前述の説明は１例の説明として提供されただけであり、広く解釈されるべきであり、本発明の趣旨及び範囲内において、様々な変更が可能である。
【００９６】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００９７】
（１）複数の相互接続されるコンピュータ及び複数の資源を含むコンピュータ・ネットワーク上で動作するプロセス・フローを有するコンピュータによる方法であって、各コンピュータがプロセッサ、メモリ及び入出力装置を含み、各資源が少なくとも１つのコンピュータに動作上接続されて、プロセス・フローにおいて少なくとも１つの活動を実行するものにおいて、
認可に関連付けられる職務証明を抽出し、職務証明そのものが信頼できるか否かを確認することにより、取引の電子認可を検証可能に編成する方法。
（２）職務証明に関連付けられる職務がハッシュされ、ハッシュ化職務のデータベース内のハッシュ化職務と比較される、前記（１）記載の方法。
（３）職務証明が取引を認可するために要求され、認可に関連付けられる職務証明が、認可構造の職務の承認セット内の職務に対応することを確認することにより、認可が更に保証される、前記（１）記載の方法。
（４）認可構造が認可ツリーである、前記（３）記載の方法。
（５）職務が取引に関連付けられる職務証明から抽出され、抽出された各職務がハッシュされ、これらのハッシュされた職務が連結されて、再度ハッシュされ、次に他の承認セットのハッシュが存在すれば、認可構造に従いそれと連結されて、再度ハッシュされ、計算結果のハッシュ値が取引管理者により署名されたハッシュ値と比較され、一致する場合取引が認可される、前記（３）記載の方法。（６）複数の相互接続されるコンピュータ及び複数の資源を含むコンピュータ・ネットワーク上で動作する分散ワークフロー管理システムであって、各コンピュータがプロセッサ、メモリ及び入出力装置を含み、各資源が少なくとも１つのコンピュータに動作上接続されて、プロセス・フローにおいて少なくとも１つの活動を実行するものにおいて、
認可に関連付けられる少なくとも１つのタイプの職務証明を抽出し、職務証明そのものが信頼できるか否かを確認することにより、取引の電子認可を検証可能に編成する方法によりコード化されるシステム。
（７）職務証明に関連付けられる職務がハッシュされ、ハッシュ化職務のデータベース内のハッシュ化職務と比較される、前記（６）記載のシステム。
（８）職務証明が取引を認可するために要求され、認可に関連付けられる職務証明が、認可構造の職務の承認セット内の職務に対応することを確認することにより、認可が更に保証される、前記（６）記載のシステム。
（９）認可構造が認可ツリーである、前記（８）記載のシステム。
（１０）職務が取引に関連付けられる職務証明から抽出され、抽出された各職務がハッシュされ、これらのハッシュされた職務が連結されて、再度ハッシュされ、次に他の承認セットのハッシュが存在すれば、認可構造に従いそれと連結されて、再度ハッシュされ、計算結果のハッシュ値が取引管理者により署名されたハッシュ値と比較され、一致する場合取引が認可される、前記（８）記載のシステム。
（１１）複数の相互接続されるコンピュータ及び複数の資源を含むコンピュータ・ネットワーク上で動作するプロセス・フローを有するコンピュータによる方法であって、各コンピュータがプロセッサ、メモリ及び入出力装置を含み、各資源が少なくとも１つのコンピュータに動作上接続されて、プロセス・フローにおいて少なくとも１つの活動を実行するものにおいて、
認可に関連付けられる少なくとも１つのタイプの職務証明を抽出し、職務証明そのものが信頼できるか否かを確認することにより、取引の電子認可を確認する方法。
（１２）職務証明に関連付けられる職務がハッシュされ、ハッシュ化職務のデータベース内のハッシュ化職務と比較される、前記（１１）記載の方法。
（１３）職務証明が取引を認可するために要求され、認可に関連付けられる職務証明が、認可構造の職務の承認セット内の職務に対応することを確認することにより、認可が更に保証される、前記（１１）記載の方法。
（１４）認可構造が認可ツリーである、前記（１３）記載の方法。
（１５）職務が取引に関連付けられる職務証明から抽出され、抽出された各職務がハッシュされ、これらのハッシュされた職務が連結されて、再度ハッシュされ、次に他の承認セットのハッシュが存在すれば、認可構造に従いそれと連結されて、再度ハッシュされ、計算結果のハッシュ値が取引管理者により署名されたハッシュ値と比較され、一致する場合取引が認可される、前記（１３）記載の方法。
（１６）複数の相互接続されるコンピュータ及び複数の資源を含むコンピュータ・ネットワーク上で動作する分散ワークフロー管理システムであって、各コンピュータがプロセッサ、メモリ及び入出力装置を含み、各資源が少なくとも１つのコンピュータに動作上接続されて、プロセス・フローにおいて少なくとも１つの活動を実行するものにおいて、
認可に関連付けられる少なくとも１つのタイプの職務証明を抽出し、職務証明そのものが信頼できるか否かを確認することにより、取引の電子認可を確認する方法によりコード化されるシステム。
（１７）職務証明に関連付けられる職務がハッシュされ、ハッシュ化職務のデータベース内のハッシュ化職務と比較される、前記（１６）記載のシステム。
（１８）職務証明が取引を認可するために要求され、認可に関連付けられる職務証明が、認可構造の職務の承認セット内の職務に対応することを確認することにより、認可が更に保証される、前記（１６）記載のシステム。
（１９）認可構造が認可ツリーである、前記（１８）記載のシステム。
（２０）職務が取引に関連付けられる職務証明から抽出され、抽出された各職務がハッシュされ、これらのハッシュされた職務が連結されて、再度ハッシュされ、次に他の承認セットのハッシュが存在すれば、認可構造に従いそれと連結されて、再度ハッシュされ、計算結果のハッシュ値が取引管理者により署名されたハッシュ値と比較され、一致する場合取引が認可される、前記（１８）記載のシステム。
（２１）コンピュータ読取り可能媒体上でコード化される取引認可方法であって、
ａ）取引の依頼を受信し、
ｂ）取引の詳細を有する文書の電子表現をデジタル文書データベースから獲得し、
ｃ）取引管理者により署名された職務証明を職務証明データベースから獲得し、署名を確認し、
ｄ）取引詳細を依頼者に返却し、
ｅ）依頼者により署名され、完成された表現を依頼者から待機して受信し、
ｆ）取引管理者により事前に署名された取引の認可構造を、認可構造データベースに要求し、署名を確認し、職務名の承認セット及びこれらの職務名に署名するために接触する承認セットのユーザ・メンバを選択し、
ｇ）依頼者の署名を有する取引依頼の詳細を、選択された承認セットに対応する職務を有する他の者に転送し、承認セット内で示される各職務の署名を収集し、
ｈ）職務証明データベースからの職務証明及び承認セットの各メンバの署名を要求し、それらを文書上でコード化し、
ｉ）取引の正当性を確認するために要求される認可詳細と、署名及び職務証明を含む完成された電子文書を依頼者に転送するステップと
を含む、取引認可方法。
（２２）職務証明及び認可構造が承認セット及び職務に関するハッシュ化情報を含み、こうしたハッシュ化情報が未ハッシュの職務証明及び承認セットを代理する、前記（２１）記載の方法。
（２３）コンピュータ読取り可能媒体上でコード化される取引確認方法であって、
ａ）取引、取引当局により署名される関連取引詳細、職務当局により署名される指定職務を証明する職務証明の収集、職務証明内の確認キーに対応する各署名キーにより署名される取引詳細、及び認可構造を表す電子文書を受信し、
ｂ）職務当局の確認キーを用いて、文書上の各証明をチェックし、
ｃ）提供される職務証明内の確認キーを用いて、取引詳細の署名を以下のようにチェックするものであって、
ｉ）職務証明から指定職務を抽出し、
ii）ハッシュのハッシュ・プロセスを用いて、職務をハッシュし、
iii）取引の計算されたハッシュ値を、取引当局により最初に署名されたものに対してチェックして、それが認可構造内で受信される取引の値と等しいことを保証し、
iv）ハッシュのハッシュ・プロセスの出力を入力として用いて、ハッシュのハッシュ・プロセスの署名をチェックし、生成されたハッシュのハッシュ・ストリングが、取引当局により署名されたハッシュ化ストリングと合致する場合、依頼が認可されたと見なし、
ｄ）結果を報告するステップと
を含む、方法。
（２４）取引認可方法によりコード化される分散ワークフロー管理システムであって、該方法が、
ａ）取引の依頼を受信する受信手段と、
ｂ）取引の詳細を有する文書の電子表現をデジタル文書データベースから獲得する検索手段と、
ｃ）取引管理者により署名された職務証明を職務証明データベースから獲得し、署名を確認する検索手段と、
ｄ）取引詳細を依頼者に返却する伝送手段と、
ｅ）依頼者により署名され、完成された表現を依頼者から受信する受信手段と、
ｆ）取引管理者により事前に署名された取引の認可構造を、認可構造データベースに要求する問い合わせ手段と、
ｇ）署名を確認する確認手段と、
ｈ）職務名の承認セット及びこれらの職務名に署名するために接触する承認セットのユーザ・メンバを選択する選択手段と、
ｉ）依頼者の署名を有する取引依頼の詳細を、選択された承認セットに対応する職務を有する他の者に転送し、承認セット内で示される各職務の署名を収集する伝送手段と、
ｊ）職務証明データベースからの職務証明及び承認セットの各メンバの署名を要求する検索手段と、
ｋ）ステップｊ）で収集された署名を文書上でコード化するコード化手段と、
ｌ）取引の正当性を確認するために要求される認可詳細と、署名及び職務証明を含む完成された電子文書を依頼者に転送する伝送手段と
を含む、システム。
（２５）職務証明及び認可構造が承認セット及び職務に関するハッシュ化情報を含み、こうしたハッシュ化情報が未ハッシュの職務証明及び承認セットを代理する、前記（２４）記載のシステム。
（２６）取引確認方法によりコード化される分散ワークフロー管理システムであって、該記方法が、
ａ）取引、取引当局により署名される関連取引詳細、職務当局により署名される指定職務を証明する職務証明の収集、職務証明内の確認キーに対応する各署名キーにより署名される取引詳細、及び認可構造を表す電子文書を受信し、
ｂ）職務当局の確認キーを用いて、文書上の各証明をチェックし、
ｃ）提供される職務証明内の確認キーを用いて、取引詳細の署名を以下のようにチェックするものであって、
ｉ）職務証明から指定職務を抽出し、
ii）ハッシュのハッシュ・プロセスを用いて、職務をハッシュし、
iii）取引の計算されたハッシュ値を、取引当局により最初に署名されたものに対してチェックして、それが認可構造内で受信される取引の値と等しいことを保証し、
iv）ハッシュのハッシュ・プロセスの出力を入力として用いて、ハッシュのハッシュ・プロセスの署名をチェックし、生成されたハッシュのハッシュ・ストリングが、取引当局により署名されたハッシュ化ストリングと合致する場合、依頼が認可されたと見なし、
ｄ）結果を報告するステップと
を含む、システム。
（２７）複数の相互接続されるコンピュータ及び複数の資源を含むコンピュータ・ネットワーク上で動作するメッセージ交換機構であって、各コンピュータがプロセッサ、メモリ及び入出力装置を含み、各資源が少なくとも１つのコンピュータに動作上接続されて、コンピュータ・ネットワークを介して別の資源に送信されるメッセージを読み書き可能なものにおいて、
認可に関連付けられる職務証明を抽出し、職務証明そのものが信頼できるか否かを確認することにより、取引の電子認可を検証可能に編成する機構。
（２８）職務証明に関連付けられる職務がハッシュされ、ハッシュ化職務のデータベース内のハッシュ化職務と比較される、前記（２７）記載の機構。
（２９）職務証明が取引を認可するために要求され、認可に関連付けられる職務証明が、認可構造の職務の承認セット内の職務に対応することを確認することにより、認可が更に保証される、前記（２７）記載の機構。
（３０）認可構造が認可ツリーである、前記（２９）記載の機構。
（３１）職務が取引に関連付けられる職務証明から抽出され、抽出された各職務がハッシュされ、これらのハッシュされた職務が連結されて、再度ハッシュされ、次に他の承認セットのハッシュが存在すれば、認可構造に従いそれと連結されて、再度ハッシュされ、計算結果のハッシュ値が取引管理者により署名されたハッシュ値と比較され、一致する場合取引が認可される、前記（２９）記載の機構。
（３２）複数の相互接続されるコンピュータ及び複数の資源を含むコンピュータ・ネットワーク上で動作するメッセージ交換機構であって、各コンピュータがプロセッサ、メモリ及び入出力装置を含み、各資源が少なくとも１つのコンピュータに動作上接続されて、プロセス・フローにおいて少なくとも１つの活動を実行するものにおいて、
認可に関連付けられる少なくとも１つのタイプの職務証明を抽出し、職務証明そのものが信頼できるか否かを確認することにより、取引の電子認可を確認する方法によりコード化される機構。
（３３）職務証明に関連付けられる職務がハッシュされ、ハッシュ化職務のデータベース内のハッシュ化職務と比較される、前記（３２）記載の機構。
（３４）職務証明が取引を認可するために要求され、認可に関連付けられる職務証明が、認可構造の職務の承認セット内の職務に対応することを確認することにより、認可が更に保証される、前記（３２）記載の機構。
（３５）認可構造が認可ツリーである、前記（３４）記載の機構。
（３６）職務が取引に関連付けられる職務証明から抽出され、抽出された各職務がハッシュされ、これらのハッシュされた職務が連結されて、再度ハッシュされ、次に他の承認セットのハッシュが存在すれば、認可構造に従いそれと連結されて、再度ハッシュされ、計算結果のハッシュ値が取引管理者により署名されたハッシュ値と比較され、一致する場合取引が認可される、前記（３４）記載の機構。
【図面の簡単な説明】
【図１】本発明のコンピュータ・システムのブロック図である。
【図２】本発明の方法に従い符号化されるネットワークの概略図である。
【図３】トランザクションの概略図である。
【図４】本発明の方法のフロー図である。
【図５】本発明の確認補助方法のフローチャートである。
【図６】本方法において使用される出張依頼書の概略図である。
【図７】本方法の取引当局を示すブロック図である。
【図８】本方法の認可構造を示すブロック図である。
【図９】出張依頼の認可ツリーを示す図である。
【図１０】職務証明書と本方法との相互作用を示すブロック図である。
【図１１】本方法におけるＴＡＭと様々なデータベースとの相互作用を示すブロック図である。
【図１２】完成された出張依頼の概略図である。
【図１３】出張依頼における職務証明書を示す概略図である。
【図１４】依頼書の検証者への転送を示す概略図である。
【図１５】図９のツリーのハッシュを示す図である。
【符号の説明】
２ 取引認可方法（ＴＡＭ）
４ 契約
６ 分散ワークフロー管理システム
８ ユーザ
１０ 依頼
１８ 署名
２０ コンピュータ・システム
２１ 分散システム
２２ 相互接続コンピュータ
２３ 資源
２４ 表示装置
２５ イントラネット（コンピュータ・ネットワーク）
２６ 入力装置
２７ マウス
２８ 左マウス・ボタン
２９ 右マウス・ボタン
３０ １次記憶装置
３１ インターネット（コンピュータ・ネットワーク）
３２ ２次記憶装置
３３ データベース
３４ グラフィカル・ユーザ・インタフェース（ＧＵＩ）
３６ ＣＰＵ
４０ 取引
４１ インタフェース
４２、１６５ 依頼者
４４、１３０ 検証者
４６ 製品またはサービス
５０ 電子文書
５２ 依頼書
５４ 出張依頼書
６０ 取引依頼詳細
６４ ＨＴＭＬ表現
６６ 取引詳細
７０ デジタル文書データベース（ＤＤＤ）
７６ 職務証明書
８０ 取引当局（ＴＡ）
８２ 職務証明書データベース（ＲＣＤ）
９４ 認可構造（ＡＳ）
９６ 認可構造データベース（ＡＳＤ）
１００ 承認セット
１０２ 職務名
１０６、１２６ 署名
１１４ デジタル文書
１１６ 確認補助方法
１２０ 署名確認キー
１２２ 職務
１４６ 認可情報
１５０ 突き合わせ署名キー
１５４ 認可ツリー（ＡＴ）
１５６ ノード
１６０ 第１のレベル
１６２ ルート
１６４ 第２のレベル
１６５ 一般社員（電子署名）
１６６ リーフ
１６７ 課長（電子署名）
１６９ 部長（電子署名）
１７０ "ＡＮＤ"ノード
１７２ "ＯＲ"ノード
１８０ 職務当局
２０２ ユーザ・ディレクトリ・データ（ＵＤＢ）
Claims (22)
- コンピュータ・ネットワークを介して相互接続され、かつ、プロセッサ、メモリ及び入出力装置を含むコンピュータを用いて、依頼者が取引の認可を得る、検証可能な取引認可方法であって、
前記依頼者から前記取引の依頼が入力されると、前記プロセッサが、前記取引の詳細を含む電子化された電子文書をデジタル文書データベースから獲得するステップと、
前記プロセッサが、職務証明データベースから、取引管理者により署名された前記依頼者に関する職務証明を獲得して、前記依頼者に関する職務証明の署名を確認するステップと、
前記プロセッサが、前記取引の詳細を含む電子文書を前記依頼者に出力するステップと、
前記依頼者により前記文書が署名されて詳細が入力されると、前記プロセッサが、認可構造データベースから、前記取引に関連付けられた職務名の承認セットを選択して、この承認セットに基づいて前記職務証明の署名を再び確認するステップと、
前記プロセッサが、前記取引の詳細を、前記選択された承認セット内の職務を有するユーザ・メンバに出力するステップと、
これらユーザ・メンバから署名が入力されると、前記プロセッサが、これらの署名を収集するステップと、
前記プロセッサが、前記署名及び前記職務証明を含む電子文書を前記依頼者に出力するステップと
を含む、検証可能な取引認可方法。 - 前記電子文書の職務証明から職務を抽出し、
ハッシュ・プロセスを用いて、この職務をハッシュ化して、ハッシュ・ストリングを生成し、
この職務のハッシュ・ストリングを、取引当局に記憶された職務のハッシュ・ストリングと比較し、
これらハッシュ・ストリングが一致する場合には、前記依頼を認可するステップを含む、請求項１記載の検証可能な取引認可方法。 - 前記認可構造データベースは、認可ツリーで構成される、請求項１記載の検証可能な取引認可方法。
- コンピュータ・ネットワークを介して相互接続され、かつ、プロセッサ、メモリ及び入出力装置を含むコンピュータを用いて、依頼者が取引の認可を得る、検証可能な取引認可方法をコンピュータに実行させるためのプログラムを記録した記録媒体であって、
前記依頼者から前記取引の依頼が入力されると、前記プロセッサが、前記取引の詳細を含む電子化された電子文書をデジタル文書データベースから獲得するステップと、
前記プロセッサが、職務証明データベースから、取引管理者により署名された前記依頼者に関する職務証明を獲得して、前記依頼者に関する職務証明の署名を確認するステップと、
前記プロセッサが、前記取引の詳細を含む電子文書を前記依頼者に出力するステップと、
前記依頼者により前記文書が署名されて詳細が入力されると、前記プロセッサが、認可構造データベースから、前記取引に関連付けられた職務名の承認セットを選択して、この承認セットに基づいて前記職務証明の署名を再び確認するステップと、
前記プロセッサが、前記取引の詳細を、前記選択された承認セット内の職務を有するユーザ・メンバに出力するステップと、
これらユーザ・メンバから署名が入力されると、前記プロセッサが、これらの署名を収集するステップと、
前記プロセッサが、前記署名及び前記職務証明を含む電子文書を前記依頼者に出力するステップと
を含む、プログラムを記録した記録媒体。 - 前記電子文書の職務証明から職務を抽出し、
ハッシュ・プロセスを用いて、この職務をハッシュ化して、ハッシュ・ストリングを生成し、
この職務のハッシュ・ストリングを、取引当局に記憶された職務のハッシュ・ストリングと比較し、
これらハッシュ・ストリングが一致する場合には、前記依頼を認可するステップを含む、請求項４記載のプログラムを記録した記録媒体。 - 前記認可構造データベースは、認可ツリーで構成される、請求項４記載のプログラムを記録した記録媒体。
- コンピュータ・ネットワークを介して相互接続され、かつ、プロセッサ、メモリ及び入出力装置を含むコンピュータを用いて、依頼者が取引の認可を得る、取引認可方法であって、
前記依頼者から前記取引の依頼が入力されると、前記プロセッサが、前記取引の詳細を含む電子化された電子文書をデジタル文書データベースから獲得するステップと、
前記プロセッサが、職務証明データベースから、取引管理者により署名された前記依頼者に関する職務証明を獲得して、前記依頼者に関する職務証明の署名を確認するステップと、
前記プロセッサが、前記取引の詳細を含む電子文書を前記依頼者に出力するステップと、
前記依頼者により前記文書が署名されて詳細が入力されると、前記プロセッサが、認可構造データベースから、前記取引に関連付けられた職務名の承認セットを選択して、この承認セットに基づいて前記職務証明の署名を再び確認するステップと、
前記プロセッサが、前記取引の詳細を、前記選択された承認セット内の職務を有するユーザ・メンバに出力するステップと、
これらユーザ・メンバから署名が入力されると、前記プロセッサが、これらの署名を収集するステップと、
前記プロセッサが、前記署名及び前記職務証明を含む電子文書を前記依頼者に出力するステップと
を含む、取引認可方法。 - 前記電子文書の職務証明から職務を抽出し、
ハッシュ・プロセスを用いて、この職務をハッシュ化して、ハッシュ・ストリングを生成し、
この職務のハッシュ・ストリングを、取引当局に記憶された職務のハッシュ・ストリングと比較し、
これらハッシュ・ストリングが一致する場合には、前記依頼を認可するステップを含む、請求項７記載の取引認可方法。 - 前記認可構造データベースは、認可ツリーで構成される、請求項７記載の取引認可方法。
- コンピュータ・ネットワークを介して相互接続され、かつ、プロセッサ、メモリ及び入出力装置を含むコンピュータを用いて、依頼者が取引の認可を得る取引認可方法をコンピュータに実行させるためのプログラムを記録した記録媒体であって、
前記依頼者から前記取引の依頼が入力されると、前記プロセッサが、前記取引の詳細を含む電子化された電子文書をデジタル文書データベースから獲得するステップと、
前記プロセッサが、職務証明データベースから、取引管理者により署名された前記依頼者に関する職務証明を獲得して、前記依頼者に関する職務証明の署名を確認するステップと、
前記プロセッサが、前記取引の詳細を含む電子文書を前記依頼者に出力するステップと、
前記依頼者により前記文書が署名されて詳細が入力されると、前記プロセッサが、認可構造データベースから、前記取引に関連付けられた職務名の承認セットを選択して、この承認セットに基づいて前記職務証明の署名を再び確認するステップと、
前記プロセッサが、前記取引の詳細を、前記選択された承認セット内の職務を有するユーザ・メンバに出力するステップと、
これらユーザ・メンバから署名が入力されると、前記プロセッサが、これらの署名を収集するステップと、
前記プロセッサが、前記署名及び前記職務証明を含む電子文書を前記依頼者に出力するステップと
を含む、プログラムを記録した記録媒体。 - 前記電子文書の職務証明から職務を抽出し、
ハッシュ・プロセスを用いて、この職務をハッシュ化して、ハッシュ・ストリングを生成し、
この職務のハッシュ・ストリングを、取引当局に記憶された職務のハッシュ・ストリングと比較し、
これらハッシュ・ストリングが一致する場合には、前記依頼を認可するステップを含む、請求項１０記載のプログラムを記録した記録媒体。 - 前記認可構造データベースは、認可ツリーで構成される、請求項１０記載のプログラムを記録した記録媒体。
- コンピュータ・ネットワークを介して相互接続され、かつ、プロセッサ、メモリ及び入出力装置を含むコンピュータを用いて、依頼者が取引の認可を得る取引認可方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、
ａ）前記依頼者から前記取引の依頼が入力されると、前記プロセッサが、前記取引の詳細を含む電子化された電子文書をデジタル文書データベースから獲得するステップと、
ｂ）前記プロセッサが、職務証明データベースから、取引管理者により署名された前記依頼者に関する職務証明を獲得して、この前記依頼者に関する職務証明の署名を確認するステップと、
ｃ）前記プロセッサが、前記取引の詳細を含む電子文書を前記依頼者に出力するステップと、
ｄ）前記依頼者により前記文書が署名されて詳細が入力されると、前記プロセッサが、認可構造データベースから、前記取引に関連付けられた職務名の承認セットを選択して、この承認セットに基づいて前記職務証明の署名を再び確認するステップと、
ｅ）前記プロセッサが、前記取引の詳細を、前記選択された承認セット内の職務を有するユーザ・メンバに出力するステップと、
ｆ）これらユーザ・メンバから署名が入力されると、前記プロセッサが、これらの署名を収集するステップと、
ｇ）前記プロセッサが、前記署名及び前記職務証明を含む電子文書を前記依頼者に出力するステップと、
を含む、プログラムを記録した記録媒体。 - 前記職務証明データベースには、前記職務証明をハッシュ化して記憶され、
前記認可構造データベースには、前記承認セットをハッシュ化して記憶される請求項１３記載の記録媒体。 - コンピュータ・ネットワークを介して相互接続されたコンピュータを有する分散ワークフロー管理システムであって、
取引の詳細を含む電子化された文書が記憶されたデジタル文書データベースと、
取引管理者により署名された前記依頼者に関する職務証明が記憶された職務証明データベースと、
前記取引に関連付けられた職務名の承認セットが記憶された認可構造データベースと、
これらデータベースを制御するプロセッサと、
このプロセッサに接続された入出力装置と、を含み、
前記プロセッサが、依頼者から前記取引の依頼が入力されると、前記取引の詳細を含む電子化された電子文書をデジタル文書データベースから獲得する電子文書獲得手段と、
職務証明データベースから、取引管理者により署名された前記依頼者に関する職務証明を獲得して、前記依頼者に関する職務証明の署名を確認する職務証明獲得手段と、
前記取引の詳細を含む電子文書を前記依頼者に出力する依頼者伝送手段と、
前記依頼者により前記文書が署名されて詳細が入力されると、認可構造データベースから、前記取引に関連付けられた職務名の承認セットを選択して、この承認セットに基づいて前記職務証明の署名を再び確認する選択手段と、
前記取引の詳細を、前記選択された承認セット内の職務を有するユーザ・メンバに出力するユーザ・メンバ伝送手段と、
これらユーザ・メンバから署名が入力されると、前記プロセッサが、これらの署名を収集する収集手段と、
前記署名及び前記職務証明を含む電子文書を前記依頼者に出力する出力手段と、を含む分散ワークフロー管理システム。 - 前記職務証明データベースには、前記職務証明がハッシュ化されて記憶され、
前記認可構造データベースには、前記承認セットがハッシュ化されて記憶される請求項１５記載のシステム。 - コンピュータ・ネットワークを介して相互接続され、かつ、プロセッサ、メモリ及び入出力装置を含むコンピュータを用いて、依頼者が取引の認可を得る、検証可能な取引認可装置であって、
前記依頼者から前記取引の依頼が入力されると、前記プロセッサが、前記取引の詳細を含む電子化された電子文書をデジタル文書データベースから獲得するステップと、
前記プロセッサが、職務証明データベースから、取引管理者により署名された前記依頼者に関する職務証明を獲得して、前記依頼者に関する職務証明の署名を確認するステップと、
前記プロセッサが、前記取引の詳細を含む電子文書を前記依頼者に出力するステップと、
前記依頼者により前記文書が署名されて詳細が入力されると、前記プロセッサが、認可構造データベースから、前記取引に関連付けられた職務名の承認セットを選択して、この承認セットに基づいて前記職務証明の署名を再び確認するステップと、
前記プロセッサが、前記取引の詳細を、前記選択された承認セット内の職務を有するユーザ・メンバに出力するステップと、
これらユーザ・メンバから署名が入力されると、前記プロセッサが、これらの署名を収集するステップと、
前記プロセッサが、前記署名及び前記職務証明を含む電子文書を前記依頼者に出力するステップと
を実行する、検証可能な取引認可装置。 - 前記電子文書の職務証明から職務を抽出し、
ハッシュ・プロセスを用いて、この職務をハッシュ化して、ハッシュ・ストリングを生成し、
この職務のハッシュ・ストリングを、取引当局に記憶された職務のハッシュ・ストリングと比較し、
これらハッシュ・ストリングが一致する場合には、前記依頼を認可するステップを実行する、請求項１７記載の検証可能な取引認可装置。 - 前記認可構造データベースは、認可ツリーで構成される、請求項１７記載の検証可能な取引認可装置。
- コンピュータ・ネットワークを介して相互接続され、かつ、プロセッサ、メモリ及び入出力装置を含むコンピュータを用いて、依頼者が取引の認可を得る、取引認可装置であって、
前記依頼者から前記取引の依頼が入力されると、前記プロセッサが、前記取引の詳細を含む電子化された電子文書をデジタル文書データベースから獲得するステップと、
前記プロセッサが、職務証明データベースから、取引管理者により署名された前記依頼者に関する職務証明を獲得して、前記依頼者に関する職務証明の署名を確認するステップと、
前記プロセッサが、前記取引の詳細を含む電子文書を前記依頼者に出力するステップと、
前記依頼者により前記文書が署名されて詳細が入力されると、前記プロセッサが、認可構造データベースから、前記取引に関連付けられた職務名の承認セットを選択して、この承認セットに基づいて前記職務証明の署名を再び確認するステップと、
前記プロセッサが、前記取引の詳細を、前記選択された承認セット内の職務を有するユーザ・メンバに出力するステップと、
これらユーザ・メンバから署名が入力されると、前記プロセッサが、これらの署名を収集するステップと、
前記プロセッサが、前記署名及び前記職務証明を含む電子文書を前記依頼者に出力するステップと
を実行する、取引認可装置。 - 前記電子文書の職務証明から職務を抽出し、
ハッシュ・プロセスを用いて、この職務をハッシュ化して、ハッシュ・ストリングを生成し、
この職務のハッシュ・ストリングを、取引当局に記憶された職務のハッシュ・ストリングと比較し、
これらハッシュ・ストリングが一致する場合には、前記依頼を認可するステップを実行する、請求項２０記載の取引認可装置。 - 前記認可構造データベースは、認可ツリーで構成される、請求項２０記載の取引認可装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP00810016.6 | 2000-01-07 | ||
| EP00810016 | 2000-01-07 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001229336A JP2001229336A (ja) | 2001-08-24 |
| JP3871300B2 true JP3871300B2 (ja) | 2007-01-24 |
Family
ID=8174514
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000391424A Expired - Fee Related JP3871300B2 (ja) | 2000-01-07 | 2000-12-22 | 企業間での職務ベースの認可のための方法 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US7222107B2 (ja) |
| JP (1) | JP3871300B2 (ja) |
| KR (1) | KR100497022B1 (ja) |
| CN (1) | CN1304104A (ja) |
| AU (1) | AU782518B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11962578B2 (en) * | 2016-06-03 | 2024-04-16 | Docusign, Inc. | Universal access to document transaction platform |
Families Citing this family (52)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6611916B1 (en) * | 1998-12-17 | 2003-08-26 | Pitney Bowes Inc. | Method of authenticating membership for providing access to a secure environment by authenticating membership to an associated secure environment |
| US6825844B2 (en) * | 2001-01-16 | 2004-11-30 | Microsoft Corp | System and method for optimizing a graphics intensive software program for the user's graphics hardware |
| US7120868B2 (en) * | 2002-05-30 | 2006-10-10 | Microsoft Corp. | System and method for adaptive document layout via manifold content |
| US20020157004A1 (en) * | 2001-02-15 | 2002-10-24 | Smith Ned M. | Method of enforcing authorization in shared processes using electronic contracts |
| US20020152086A1 (en) * | 2001-02-15 | 2002-10-17 | Smith Ned M. | Method and apparatus for controlling a lifecycle of an electronic contract |
| US7206936B2 (en) * | 2001-12-19 | 2007-04-17 | Northrop Grumman Corporation | Revocation and updating of tokens in a public key infrastructure system |
| US7996888B2 (en) * | 2002-01-11 | 2011-08-09 | Nokia Corporation | Virtual identity apparatus and method for using same |
| US20030163685A1 (en) * | 2002-02-28 | 2003-08-28 | Nokia Corporation | Method and system to allow performance of permitted activity with respect to a device |
| US7260831B1 (en) * | 2002-04-25 | 2007-08-21 | Sprint Communications Company L.P. | Method and system for authorization and access to protected resources |
| US7562215B2 (en) * | 2003-05-21 | 2009-07-14 | Hewlett-Packard Development Company, L.P. | System and method for electronic document security |
| US7246311B2 (en) * | 2003-07-17 | 2007-07-17 | Microsoft Corporation | System and methods for facilitating adaptive grid-based document layout |
| US8132016B1 (en) | 2003-07-17 | 2012-03-06 | United Services Automobile Association (Usaa) | Method, system, and computer program product for the authentication of multiple users in a common session |
| JP4460251B2 (ja) * | 2003-09-19 | 2010-05-12 | 株式会社エヌ・ティ・ティ・ドコモ | 構造化文書署名装置、構造化文書適応化装置及び構造化文書検証装置。 |
| US7694143B2 (en) * | 2003-11-18 | 2010-04-06 | Oracle International Corporation | Method of and system for collecting an electronic signature for an electronic record stored in a database |
| US20050138031A1 (en) * | 2003-12-05 | 2005-06-23 | Wefers Wolfgang M. | Systems and methods for assigning task-oriented roles to users |
| US20050144144A1 (en) * | 2003-12-30 | 2005-06-30 | Nokia, Inc. | System and method for authenticating a terminal based upon at least one characteristic of the terminal located at a position within an organization |
| US20050149724A1 (en) * | 2003-12-30 | 2005-07-07 | Nokia Inc. | System and method for authenticating a terminal based upon a position of the terminal within an organization |
| US7472277B2 (en) * | 2004-06-17 | 2008-12-30 | International Business Machines Corporation | User controlled anonymity when evaluating into a role |
| US8117073B1 (en) * | 2004-09-17 | 2012-02-14 | Rearden Commerce, Inc. | Method and system for delegation of travel arrangements by a temporary agent |
| US7925540B1 (en) | 2004-10-15 | 2011-04-12 | Rearden Commerce, Inc. | Method and system for an automated trip planner |
| US7970666B1 (en) | 2004-12-30 | 2011-06-28 | Rearden Commerce, Inc. | Aggregate collection of travel data |
| US20080147450A1 (en) * | 2006-10-16 | 2008-06-19 | William Charles Mortimore | System and method for contextualized, interactive maps for finding and booking services |
| US20060200664A1 (en) * | 2005-03-07 | 2006-09-07 | Dave Whitehead | System and method for securing information accessible using a plurality of software applications |
| US7730523B1 (en) * | 2005-06-17 | 2010-06-01 | Oracle America, Inc. | Role-based access using combinatorial inheritance and randomized conjugates in an internet hosted environment |
| KR100785782B1 (ko) * | 2005-11-17 | 2007-12-18 | 한국전자통신연구원 | 권한위임 시스템 및 방법 |
| US7941374B2 (en) | 2006-06-30 | 2011-05-10 | Rearden Commerce, Inc. | System and method for changing a personal profile or context during a transaction |
| US20080004917A1 (en) * | 2006-06-30 | 2008-01-03 | Rearden Commerce, Inc. | System and method for automatically rebooking reservations |
| US7779453B2 (en) * | 2006-10-12 | 2010-08-17 | International Business Machines Corporation | Routing method and system |
| US20090210261A1 (en) * | 2008-02-20 | 2009-08-20 | Rearden Commerce, Inc. | System and Method for Multi-Modal Travel Shopping |
| US20090248457A1 (en) * | 2008-03-31 | 2009-10-01 | Rearden Commerce, Inc. | System and Method for Providing Travel Schedule of Contacts |
| US9342621B1 (en) | 2008-08-04 | 2016-05-17 | Zscaler, Inc. | Phrase matching |
| US8341415B1 (en) * | 2008-08-04 | 2012-12-25 | Zscaler, Inc. | Phrase matching |
| US20100100743A1 (en) * | 2008-10-17 | 2010-04-22 | Microsoft Corporation | Natural Visualization And Routing Of Digital Signatures |
| US20100211419A1 (en) * | 2009-02-13 | 2010-08-19 | Rearden Commerce, Inc. | Systems and Methods to Present Travel Options |
| US10438181B2 (en) | 2009-07-22 | 2019-10-08 | Visa International Service Association | Authorizing a payment transaction using seasoned data |
| US20110077986A1 (en) * | 2009-09-30 | 2011-03-31 | Motorola, Inc. | Decision cost analysis for enterprise strategic decision management |
| US9449288B2 (en) | 2011-05-20 | 2016-09-20 | Deem, Inc. | Travel services search |
| US9210161B2 (en) * | 2011-12-13 | 2015-12-08 | Business Objects Software Limited | Authentication certificates as source of contextual information in business intelligence processes |
| MX347104B (es) * | 2012-07-27 | 2017-04-12 | Clawd Tech Inc | Método de gestión de derechos digitales basados en roles en un sistema de cómputo. |
| US9824471B2 (en) | 2012-09-27 | 2017-11-21 | Oracle International Corporation | Automatic generation of hierarchy visualizations |
| US20140095390A1 (en) * | 2012-09-28 | 2014-04-03 | Oracle International Corporation | Mobile transaction approvals |
| US20140101437A1 (en) * | 2012-10-04 | 2014-04-10 | Wurldtech Security Technologies | Automated certification based on role |
| CN104917793A (zh) * | 2014-03-13 | 2015-09-16 | 中国移动通信集团河北有限公司 | 一种访问控制方法、装置及系统 |
| US9836587B2 (en) * | 2014-05-20 | 2017-12-05 | 2236008 Ontario Inc. | System and method for granting permission for a machine action |
| US10114939B1 (en) * | 2014-09-22 | 2018-10-30 | Symantec Corporation | Systems and methods for secure communications between devices |
| US10122533B1 (en) * | 2015-12-15 | 2018-11-06 | Amazon Technologies, Inc. | Configuration updates for access-restricted hosts |
| CN107330307A (zh) * | 2017-07-16 | 2017-11-07 | 成都牵牛草信息技术有限公司 | 一种表单数据操作权限授权方法 |
| CN109376526A (zh) * | 2018-09-27 | 2019-02-22 | 拉扎斯网络科技（上海）有限公司 | 权限控制方法、装置、电子设备及计算机可读存储介质 |
| US11133942B1 (en) * | 2019-05-15 | 2021-09-28 | Wells Fargo Bank, N.A. | Systems and methods of ring usage certificate extension |
| US11283623B1 (en) * | 2019-06-03 | 2022-03-22 | Wells Fargo Bank, N.A. | Systems and methods of using group functions certificate extension |
| WO2022070405A1 (ja) * | 2020-10-02 | 2022-04-07 | 富士通株式会社 | 制御方法、生成方法、生成プログラムおよび情報処理装置 |
| CN114296720A (zh) * | 2021-12-02 | 2022-04-08 | 北京思特奇信息技术股份有限公司 | 一种基于配置化生成h5界面的方法及系统 |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5557518A (en) * | 1994-04-28 | 1996-09-17 | Citibank, N.A. | Trusted agents for open electronic commerce |
| US7904722B2 (en) * | 1994-07-19 | 2011-03-08 | Certco, Llc | Method for securely using digital signatures in a commercial cryptographic system |
| CZ11597A3 (en) * | 1994-07-19 | 1997-09-17 | Bankers Trust Co | Method of safe use of digital designation in a commercial coding system |
| DE69427347T2 (de) * | 1994-08-15 | 2001-10-31 | International Business Machines Corp., Armonk | Verfahren und System zur verbesserten Zugriffssteuerung auf Basis der Rollen in verteilten und zentralisierten Rechnersystemen |
| US5677955A (en) * | 1995-04-07 | 1997-10-14 | Financial Services Technology Consortium | Electronic funds transfer instruments |
| EP0760565B1 (en) * | 1995-08-28 | 1998-07-08 | Ofra Feldbau | Apparatus and method for authenticating the dispatch and contents of documents |
| US6055637A (en) * | 1996-09-27 | 2000-04-25 | Electronic Data Systems Corporation | System and method for accessing enterprise-wide resources by presenting to the resource a temporary credential |
| US5996076A (en) * | 1997-02-19 | 1999-11-30 | Verifone, Inc. | System, method and article of manufacture for secure digital certification of electronic commerce |
| JPH10327147A (ja) * | 1997-05-21 | 1998-12-08 | Hitachi Ltd | 電子認証公証方法およびシステム |
| US6125349A (en) * | 1997-10-01 | 2000-09-26 | At&T Corp. | Method and apparatus using digital credentials and other electronic certificates for electronic transactions |
| US20020004900A1 (en) * | 1998-09-04 | 2002-01-10 | Baiju V. Patel | Method for secure anonymous communication |
| EP1115074A3 (en) * | 2000-01-07 | 2004-04-14 | International Business Machines Corporation | A method for inter-enterprise role-based authorization |
| EP1164745A3 (en) * | 2000-06-09 | 2005-03-30 | Northrop Grumman Corporation | System and method for usage of a role certificate in encryption, and as a seal, digital stamp, and a signature |
| US20020152086A1 (en) * | 2001-02-15 | 2002-10-17 | Smith Ned M. | Method and apparatus for controlling a lifecycle of an electronic contract |
-
2000
- 2000-11-28 AU AU71863/00A patent/AU782518B2/en not_active Ceased
- 2000-12-22 JP JP2000391424A patent/JP3871300B2/ja not_active Expired - Fee Related
- 2000-12-28 KR KR10-2000-0084142A patent/KR100497022B1/ko not_active IP Right Cessation
- 2000-12-29 CN CN00129495A patent/CN1304104A/zh active Pending
-
2001
- 2001-01-05 US US09/755,520 patent/US7222107B2/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11962578B2 (en) * | 2016-06-03 | 2024-04-16 | Docusign, Inc. | Universal access to document transaction platform |
Also Published As
| Publication number | Publication date |
|---|---|
| AU782518B2 (en) | 2005-08-04 |
| US7222107B2 (en) | 2007-05-22 |
| AU7186300A (en) | 2001-07-12 |
| JP2001229336A (ja) | 2001-08-24 |
| CN1304104A (zh) | 2001-07-18 |
| US20010021928A1 (en) | 2001-09-13 |
| KR20010070373A (ko) | 2001-07-25 |
| KR100497022B1 (ko) | 2005-06-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3871300B2 (ja) | 企業間での職務ベースの認可のための方法 | |
| EP3424176B1 (en) | Systems and methods for distributed data sharing with asynchronous third-party attestation | |
| Clauß et al. | Identity management and its support of multilateral security | |
| US7231659B2 (en) | Entity authentication in a shared hosting computer network environment | |
| US8375213B2 (en) | Systems and methods for enabling trust in a federated collaboration | |
| EP1540881B1 (en) | System and method for the transmission, storage and retrieval of authenticated documents | |
| RU2292589C2 (ru) | Аутентифицированный платеж | |
| US7072870B2 (en) | System and method for providing authorization and other services | |
| US20090271321A1 (en) | Method and system for verification of personal information | |
| EP1557737A2 (en) | Method, system and program procuct for electronically executing contracts within a secure computer infrastructure | |
| Berthold et al. | Identity management based on P3P | |
| WO2009155146A2 (en) | Digitally signing documents using identity context information | |
| WO2001082190A1 (en) | Multi-tiered identity verification authority for e-commerce | |
| US7490755B2 (en) | Method and program for establishing peer-to-peer karma and trust | |
| EP1274055A1 (en) | Method and system for confirming the fulfillment of a transition condition in electronic transactions | |
| Ehikioya et al. | A formal model of distributed security for electronic commerce transactions systems | |
| Lyons-Burke et al. | SP 800-25. Federal Agency Use of Public Key Technology for Digital Signatures and Authentication | |
| CN115514489A (zh) | 知识密集型零工经济服务系统及其运行方法 | |
| US7971068B2 (en) | Method, system and program product for protecting electronic contracts created within a secure computer infrastructure | |
| Mehta et al. | Security in e-services and applications | |
| EP1115074A2 (en) | A method for inter-enterprise role-based authorization | |
| US20020184100A1 (en) | Casual access application with context sensitive pin authentication | |
| AU743570B1 (en) | Means and method of registering new users in a system of registered users | |
| JP3106039U (ja) | 電子商取引システム | |
| TW202429852A (zh) | 電子認證系統及電子認證方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20001222 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20020624 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040406 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040702 |
|
| RD12 | Notification of acceptance of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7432 Effective date: 20040702 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20040702 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050510 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050729 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050729 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20051004 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051114 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20051219 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20061003 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20061004 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061016 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091027 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101027 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101027 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111027 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121027 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121027 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131027 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |