JP2001229336A - 企業間での職務ベースの認可のための方法 - Google Patents
企業間での職務ベースの認可のための方法Info
- Publication number
- JP2001229336A JP2001229336A JP2000391424A JP2000391424A JP2001229336A JP 2001229336 A JP2001229336 A JP 2001229336A JP 2000391424 A JP2000391424 A JP 2000391424A JP 2000391424 A JP2000391424 A JP 2000391424A JP 2001229336 A JP2001229336 A JP 2001229336A
- Authority
- JP
- Japan
- Prior art keywords
- job
- transaction
- authorization
- hashed
- hash
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 152
- 238000013475 authorization Methods 0.000 claims abstract description 245
- 230000008569 process Effects 0.000 claims abstract description 44
- 230000000694 effects Effects 0.000 claims abstract description 14
- 239000000284 extract Substances 0.000 claims abstract description 11
- 230000007246 mechanism Effects 0.000 claims description 31
- 238000012795 verification Methods 0.000 claims description 26
- 238000012790 confirmation Methods 0.000 claims description 22
- 230000005540 biological transmission Effects 0.000 claims description 6
- 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 claims description 2
- 101100006844 Schizosaccharomyces pombe (strain 972 / ATCC 24843) cmc4 gene Proteins 0.000 description 33
- 238000010586 diagram Methods 0.000 description 12
- 238000012546 transfer Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 5
- 238000004364 calculation method Methods 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 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
- 238000012545 processing Methods 0.000 description 2
- 238000012797 qualification Methods 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
- DIWRORZWFLOCLC-UHFFFAOYSA-N Lorazepam Chemical compound C12=CC(Cl)=CC=C2NC(=O)C(O)N=C1C1=CC=CC=C1Cl DIWRORZWFLOCLC-UHFFFAOYSA-N 0.000 description 1
- 101100492653 Oryza sativa subsp. japonica AT15 gene Proteins 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
- 238000011161 development Methods 0.000 description 1
- 238000007429 general method Methods 0.000 description 1
- 230000007935 neutral effect Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
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)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (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)
Abstract
(57)【要約】
【課題】 取引が適切に認可され、従って履行可能なよ
うに保証する便利でコンピュータ化された手段を提供す
ることにより、電子商取引を助成すること。 【解決手段】 複数の相互接続されるコンピュータ及び
複数の資源を含むコンピュータ・ネットワーク上で動作
する、取引認可方法が提供される。各コンピュータはプ
ロセッサ、メモリ及び入出力装置を含み、各資源は少な
くとも１つのコンピュータに動作上接続されて、プロセ
ス・フローにおいて少なくとも１つの活動を実行する。
本方法は、認可に関連付けられる少なくとも１つのタイ
プの職務証明を抽出し、職務証明そのものが信頼できる
か否かを確認することにより、取引の電子認可を検証可
能に編成する。本方法は、職務にもとづく認可構造を提
供することにより、取引に関する各々の及びあらゆる署
名を個々に認可する必要性を排除する。この構造は、取
引の認可を確認するために、公衆ネットワーク上でアク
セス可能である。
うに保証する便利でコンピュータ化された手段を提供す
ることにより、電子商取引を助成すること。 【解決手段】 複数の相互接続されるコンピュータ及び
複数の資源を含むコンピュータ・ネットワーク上で動作
する、取引認可方法が提供される。各コンピュータはプ
ロセッサ、メモリ及び入出力装置を含み、各資源は少な
くとも１つのコンピュータに動作上接続されて、プロセ
ス・フローにおいて少なくとも１つの活動を実行する。
本方法は、認可に関連付けられる少なくとも１つのタイ
プの職務証明を抽出し、職務証明そのものが信頼できる
か否かを確認することにより、取引の電子認可を検証可
能に編成する。本方法は、職務にもとづく認可構造を提
供することにより、取引に関する各々の及びあらゆる署
名を個々に認可する必要性を排除する。この構造は、取
引の認可を確認するために、公衆ネットワーク上でアク
セス可能である。
Description
【０００１】
【発明の属する技術分野】本発明は電子商取引に関し、
特に、公衆ネットワーク及び専用ネットワークの両方を
介して、企業間の取引の承諾を認可及び確認する方法に
関する。
特に、公衆ネットワーク及び専用ネットワークの両方を
介して、企業間の取引の承諾を認可及び確認する方法に
関する。
【０００２】
【従来の技術】公衆ネットワークを介する様々な企業間
の電子商取引ソルーションの大規模な展開は、セキュリ
ティ問題の慎重な考慮を要求する。これは１例を通じて
最もよく説明される。
の電子商取引ソルーションの大規模な展開は、セキュリ
ティ問題の慎重な考慮を要求する。これは１例を通じて
最もよく説明される。
【０００３】会社Ａ及び会社Ｂの２社が、申し出、注文
または取り消しなどの企業取引（すなわち、個人または
組織間の法的に拘束力のある活動）を行う正式協定を有
する。会社Ａ及びＢ間の取引タイプの可能なセットは、
Ｔ（Ａ、Ｂ）＝｛Ｔ１、Ｔ２、．．．、Ｔｎ｝により表
され、ここで例えばＴ∈Ｔ（Ａ、Ｂ）は、Ｔ→"製品Ｙ
を１単位当たり価格ＰでＸ単位購入する"ことを意味す
るものとする。
または取り消しなどの企業取引（すなわち、個人または
組織間の法的に拘束力のある活動）を行う正式協定を有
する。会社Ａ及びＢ間の取引タイプの可能なセットは、
Ｔ（Ａ、Ｂ）＝｛Ｔ１、Ｔ２、．．．、Ｔｎ｝により表
され、ここで例えばＴ∈Ｔ（Ａ、Ｂ）は、Ｔ→"製品Ｙ
を１単位当たり価格ＰでＸ単位購入する"ことを意味す
るものとする。
【０００４】セットＴ（Ａ、Ｂ）により表される取引タ
イプは、一般的であると見なされ、特定の取引が発生す
る実時間において、取引記述Ｔ（Ａ、Ｂ）で与えられる
もの以外の、追加の詳細が提供されなければならない。
例えば取引Ｔにおいて、依頼者はＸ、Ｙ及びＰの値を提
供し、これは時間の経過に伴い変化し得る。
イプは、一般的であると見なされ、特定の取引が発生す
る実時間において、取引記述Ｔ（Ａ、Ｂ）で与えられる
もの以外の、追加の詳細が提供されなければならない。
例えば取引Ｔにおいて、依頼者はＸ、Ｙ及びＰの値を提
供し、これは時間の経過に伴い変化し得る。
【０００５】取引のセットＴ（Ａ、Ｂ）を指定する問
題、それらが如何に実行されるか、及び交換されるデー
タなどは、ＩＳＯ９７３５における電子データ交換（Ｅ
ＤＩ：Electronic Data Exchange）構文を用いて解決さ
れる（http://www.r3.ch/standards/edifact/index.htm
l参照）。更に、これらの会社はインターネットを介し
て調整し、取引セットＴ（Ａ、Ｂ）で指定される彼らの
一般的な取引を履行しなければならない。
題、それらが如何に実行されるか、及び交換されるデー
タなどは、ＩＳＯ９７３５における電子データ交換（Ｅ
ＤＩ：Electronic Data Exchange）構文を用いて解決さ
れる（http://www.r3.ch/standards/edifact/index.htm
l参照）。更に、これらの会社はインターネットを介し
て調整し、取引セットＴ（Ａ、Ｂ）で指定される彼らの
一般的な取引を履行しなければならない。
【０００６】典型的な状況は、会社ＡのユーザＵＡが、
会社Ｂの管理下にあるユーザＵＢから、タイプＴ∈Ｔ
（Ａ、Ｂ）の取引を受信することである。ここでユーザ
ＵＡが会社Ｂからの依頼、すなわち会社Ａに対して、製
品Ｙを１単位当たり価格Ｐ＝１ドルでＸ＝１０００単位
生産するようにとの依頼を提示され、更にユーザが公衆
ネットワークを介して、ソフトウェア操作を通じて操作
すると仮定する。依頼は公衆ネットワークから発信する
ので、ユーザＵＡが考慮し得る少なくとも３つのセキュ
リティ問題が存在する。第１は、取引の詳細（Ｘ、Ｙ、
Ｐ、ＵＡ、ＵＢ）が機密であり、保全性を考慮して符号
化されているかであり、第２は、取引を依頼するユーザ
ＵＢが、実際に会社Ｂにより管理されていることをどの
ように確認するかであり、第３は、たとえ取引を依頼す
るユーザＵＢが会社Ｂにより雇われていることが知れた
としても、ユーザＵＢが実際にこうした取引をＸ、Ｙ及
びＰの所与の値で依頼することを許可されているかの確
認方法が、明確でないことである。
会社Ｂの管理下にあるユーザＵＢから、タイプＴ∈Ｔ
（Ａ、Ｂ）の取引を受信することである。ここでユーザ
ＵＡが会社Ｂからの依頼、すなわち会社Ａに対して、製
品Ｙを１単位当たり価格Ｐ＝１ドルでＸ＝１０００単位
生産するようにとの依頼を提示され、更にユーザが公衆
ネットワークを介して、ソフトウェア操作を通じて操作
すると仮定する。依頼は公衆ネットワークから発信する
ので、ユーザＵＡが考慮し得る少なくとも３つのセキュ
リティ問題が存在する。第１は、取引の詳細（Ｘ、Ｙ、
Ｐ、ＵＡ、ＵＢ）が機密であり、保全性を考慮して符号
化されているかであり、第２は、取引を依頼するユーザ
ＵＢが、実際に会社Ｂにより管理されていることをどの
ように確認するかであり、第３は、たとえ取引を依頼す
るユーザＵＢが会社Ｂにより雇われていることが知れた
としても、ユーザＵＢが実際にこうした取引をＸ、Ｙ及
びＰの所与の値で依頼することを許可されているかの確
認方法が、明確でないことである。
【０００７】最初の２つの点は、A．Menezes、P．van O
orschot、及びS．VanstoneによるHandbook of Applied
Cryptography、CRC press、1996で述べられる標準のセ
キュリティ・プロトコル及び暗号化アルゴリズムを用い
て解決される。特に、公開キー暗号化により、各ユーザ
Ｕｘは１つまたは複数の認証（ISO/IEC9594、Informati
on Technology - Open Systems Interconnection - The
Directory：Authentication Framework、1993参照）を
交付され、それらがデジタル署名を通じて、彼らの識別
を証明するために使用される。
orschot、及びS．VanstoneによるHandbook of Applied
Cryptography、CRC press、1996で述べられる標準のセ
キュリティ・プロトコル及び暗号化アルゴリズムを用い
て解決される。特に、公開キー暗号化により、各ユーザ
Ｕｘは１つまたは複数の認証（ISO/IEC9594、Informati
on Technology - Open Systems Interconnection - The
Directory：Authentication Framework、1993参照）を
交付され、それらがデジタル署名を通じて、彼らの識別
を証明するために使用される。
【０００８】ユーザＵＡ及びＵＢが個人的に知り合いで
ある場合、既存の信頼関係だけでユーザＵＡがユーザＵ
Ｂからの依頼を認可されたものとして受諾するのに十分
であり、実際このようにして多くの企業間取引が現在行
われている。この場合、ユーザＵＡ及びＵＢは、将来取
引を行うために明確にある信頼関係を確立しているか、
ことによると信頼が前の成功取引により獲得されたもの
である。しかしながら、一般的な電子商取引は、以前に
取引関係または信頼関係を有さない人々及び会社を引き
合わせ、取引はともかく"自己認可的（self-authorizin
g）"なものとなる。従来、データ、アプリケーション、
資源またはより一般的には単にオブジェクトの認可は、
ある形式のアクセス制御を用いて管理された。例えば、
D．E．Denningによる"Cryptography and Data Securit
y"、Addison-Wesley Publishing Company、1982を参照
のこと。その最も一般的な形式として、各オブジェクト
Ｏに対して各ユーザが有するアクセス権を明示的にリス
トするアクセス制御マトリックスＭが存在する。多くの
ユーザＵｉ及びオブジェクトＯｊが存在するとき、アク
セス制御マトリックスＭを管理することは困難である。
ある場合、既存の信頼関係だけでユーザＵＡがユーザＵ
Ｂからの依頼を認可されたものとして受諾するのに十分
であり、実際このようにして多くの企業間取引が現在行
われている。この場合、ユーザＵＡ及びＵＢは、将来取
引を行うために明確にある信頼関係を確立しているか、
ことによると信頼が前の成功取引により獲得されたもの
である。しかしながら、一般的な電子商取引は、以前に
取引関係または信頼関係を有さない人々及び会社を引き
合わせ、取引はともかく"自己認可的（self-authorizin
g）"なものとなる。従来、データ、アプリケーション、
資源またはより一般的には単にオブジェクトの認可は、
ある形式のアクセス制御を用いて管理された。例えば、
D．E．Denningによる"Cryptography and Data Securit
y"、Addison-Wesley Publishing Company、1982を参照
のこと。その最も一般的な形式として、各オブジェクト
Ｏに対して各ユーザが有するアクセス権を明示的にリス
トするアクセス制御マトリックスＭが存在する。多くの
ユーザＵｉ及びオブジェクトＯｊが存在するとき、アク
セス制御マトリックスＭを管理することは困難である。
【０００９】ことによると、最も一般的なタイプの認可
は、取引Ｔを記述する一般的に作成された文書または書
式であり、そこでは特定の詳細が依頼者により依頼時に
提供され、依頼者は次に、タイプＴの取引または依頼を
承認できる一人のまたは複数の人々から、書式上の手書
き署名のセットを収集するように要求される。例えば、
Ｔは出張依頼書用紙であり、そこでは行き先、滞在期
間、予想費用、及び移動方法の提示が要求される。依頼
者はこれらの詳細を記述し、依頼書に署名し、用紙を様
々な上司に提示して、用紙上の所定の場所に彼らの署名
を依頼する。一般に、署名が要求される用紙上の場所
は、課長や部長またはＣＥＯなどの署名を依頼される人
々の職務によりラベル付けされる。
は、取引Ｔを記述する一般的に作成された文書または書
式であり、そこでは特定の詳細が依頼者により依頼時に
提供され、依頼者は次に、タイプＴの取引または依頼を
承認できる一人のまたは複数の人々から、書式上の手書
き署名のセットを収集するように要求される。例えば、
Ｔは出張依頼書用紙であり、そこでは行き先、滞在期
間、予想費用、及び移動方法の提示が要求される。依頼
者はこれらの詳細を記述し、依頼書に署名し、用紙を様
々な上司に提示して、用紙上の所定の場所に彼らの署名
を依頼する。一般に、署名が要求される用紙上の場所
は、課長や部長またはＣＥＯなどの署名を依頼される人
々の職務によりラベル付けされる。
【００１０】認可のこの用紙は"書式署名モデル（form-
signature model）"と呼ばれたり、共同署名または共同
署名データによる認可と呼ばれる。例えば、出張依頼取
引（Ｔ＝"出張依頼"）は、依頼者、依頼者の課長、次に
依頼者の部長の署名を要求する。一旦要求された署名が
収集されると、依頼者は署名文書により取引を認可す
る。すなわち、例えば旅行業者にフライトやホテルを予
約させる。通常、旅行業者は、戻り日が出発日よりも後
であること、或いは費用の限界を超えていないことなど
の一般的なチェックを除き、出張依頼の詳細の確認に関
与しない。旅行業者にとって重要なことは、依頼書に付
随する署名のセット、及びこれらの署名により表される
職務である。多額の資金を伴わない多くの事務作業にと
って、書式署名モデルは業務の認可を与えるのに十分で
ある。しかしながら、より多額の資金または資源を取引
に委ねられる場合、各署名が信頼できるものであり、署
名の収集が実際にその会社を結びつけることが確実であ
ることが重要となる。これらの場合、下級の社員が取引
を認可する権限を有することを確認するために、企業の
当局者（すなわち、社長、監査役、または他の役員など
の取引管理者）からあらゆる取引の直接承認を得ること
が必要となる。
signature model）"と呼ばれたり、共同署名または共同
署名データによる認可と呼ばれる。例えば、出張依頼取
引（Ｔ＝"出張依頼"）は、依頼者、依頼者の課長、次に
依頼者の部長の署名を要求する。一旦要求された署名が
収集されると、依頼者は署名文書により取引を認可す
る。すなわち、例えば旅行業者にフライトやホテルを予
約させる。通常、旅行業者は、戻り日が出発日よりも後
であること、或いは費用の限界を超えていないことなど
の一般的なチェックを除き、出張依頼の詳細の確認に関
与しない。旅行業者にとって重要なことは、依頼書に付
随する署名のセット、及びこれらの署名により表される
職務である。多額の資金を伴わない多くの事務作業にと
って、書式署名モデルは業務の認可を与えるのに十分で
ある。しかしながら、より多額の資金または資源を取引
に委ねられる場合、各署名が信頼できるものであり、署
名の収集が実際にその会社を結びつけることが確実であ
ることが重要となる。これらの場合、下級の社員が取引
を認可する権限を有することを確認するために、企業の
当局者（すなわち、社長、監査役、または他の役員など
の取引管理者）からあらゆる取引の直接承認を得ること
が必要となる。
【００１１】電子商取引の書式署名モデルは、１）業務
を遂行するために要求される業務及び情報（日付、価
格、名前など）の電子表現と、２）署名機構と、３）電
子業務データに付随する署名を、その業務のための認可
を与える特権に関連付ける機構とを含む。一般に１）及
び２）は、現在の方法及び技術を用いて直接解決される
が、３）は十分に解決されていない。１）及び２）に関
して、用紙ベースの書式がＨＴＭＬまたはワープロ文書
として電子的に表され、業務Ｔに関して、Ｄ（Ｔ）が業
務Ｔの電子書式またはテンプレートを示すものとする。
Ｔが"出張依頼"と仮定すると、例えばＤ（Ｔ）は出張の
詳細について要求するＨＴＭＬ文書であり得、職務のリ
ストが存在し得る。そして、これらの職務を演ずるユー
ザは出張依頼詳細に署名しなければならない。更に、Ｒ
ＳＡまたはＤＳＳなどのデジタル署名を提供する幾つか
の技法が存在し、従って、電子商取引において書式署名
モデルを実現する基本ツールが使用可能である。電子商
取引書式署名モデルにおいてより困難な部分は、収集さ
れた署名のセットが業務の認可を意味することを決定ま
たは確認することである。
を遂行するために要求される業務及び情報（日付、価
格、名前など）の電子表現と、２）署名機構と、３）電
子業務データに付随する署名を、その業務のための認可
を与える特権に関連付ける機構とを含む。一般に１）及
び２）は、現在の方法及び技術を用いて直接解決される
が、３）は十分に解決されていない。１）及び２）に関
して、用紙ベースの書式がＨＴＭＬまたはワープロ文書
として電子的に表され、業務Ｔに関して、Ｄ（Ｔ）が業
務Ｔの電子書式またはテンプレートを示すものとする。
Ｔが"出張依頼"と仮定すると、例えばＤ（Ｔ）は出張の
詳細について要求するＨＴＭＬ文書であり得、職務のリ
ストが存在し得る。そして、これらの職務を演ずるユー
ザは出張依頼詳細に署名しなければならない。更に、Ｒ
ＳＡまたはＤＳＳなどのデジタル署名を提供する幾つか
の技法が存在し、従って、電子商取引において書式署名
モデルを実現する基本ツールが使用可能である。電子商
取引書式署名モデルにおいてより困難な部分は、収集さ
れた署名のセットが業務の認可を意味することを決定ま
たは確認することである。
【００１２】ユーザＵがデジタル的にデータに署名する
場合、ユーザＵは公開キーＰｕｂ（Ｕ）及び私用キーＰ
ｒｉ（Ｕ）を有することを意味する。Ｐｕｂ（Ｕ）は、
ここではＣｅｒｔ（Ｕ）として示される証明書内に記憶
される。証明書Ｃｅｒｔ（Ｕ）は公開データベースまた
はディレクトリ内に記憶され、誰もがそれを検索して、
私用キーＰｒｉ（Ｕ）を有するユーザＵにより生成され
たと言われる署名を確認できる。証明書Ｃｅｒｔ（Ｕ）
は、ユーザＵの１つまたは幾つかの名前または識別子を
含み、従ってユーザＵは署名を生成したユーザとして、
一意的に識別される。しかしながら、文書Ｄ（Ｔ）上の
署名のセットを調査することにより、別のユーザが取引
Ｔを依頼しているかを確認する際、重要な点は、誰が各
署名を生成したかではなく、彼らがＴを認可する権限を
有するか否かである。
場合、ユーザＵは公開キーＰｕｂ（Ｕ）及び私用キーＰ
ｒｉ（Ｕ）を有することを意味する。Ｐｕｂ（Ｕ）は、
ここではＣｅｒｔ（Ｕ）として示される証明書内に記憶
される。証明書Ｃｅｒｔ（Ｕ）は公開データベースまた
はディレクトリ内に記憶され、誰もがそれを検索して、
私用キーＰｒｉ（Ｕ）を有するユーザＵにより生成され
たと言われる署名を確認できる。証明書Ｃｅｒｔ（Ｕ）
は、ユーザＵの１つまたは幾つかの名前または識別子を
含み、従ってユーザＵは署名を生成したユーザとして、
一意的に識別される。しかしながら、文書Ｄ（Ｔ）上の
署名のセットを調査することにより、別のユーザが取引
Ｔを依頼しているかを確認する際、重要な点は、誰が各
署名を生成したかではなく、彼らがＴを認可する権限を
有するか否かである。
【００１３】従って、企業の当局者をあらゆる取引を確
認する必要性から解放し、不確かな公衆ネットワーク上
において、標準のセキュリティまたは暗号化プロトコル
を用いて、電子商取引契約の認可の効率的な認可及び確
認を可能にする方法が必要とされる。更に、それぞれの
会社の決定構造に関する最小の情報を明らかにする企業
間認可を実行する方法が必要とされる。
認する必要性から解放し、不確かな公衆ネットワーク上
において、標準のセキュリティまたは暗号化プロトコル
を用いて、電子商取引契約の認可の効率的な認可及び確
認を可能にする方法が必要とされる。更に、それぞれの
会社の決定構造に関する最小の情報を明らかにする企業
間認可を実行する方法が必要とされる。
【００１４】
【発明が解決しようとする課題】本発明の目的は、取引
が適切に認可され、従って履行可能なように保証する便
利でコンピュータ化された手段を提供することにより、
電子商取引を助成することである。
が適切に認可され、従って履行可能なように保証する便
利でコンピュータ化された手段を提供することにより、
電子商取引を助成することである。
【００１５】本発明の別の目的は、ハッシュ・テーブル
が使用される場合に空間要求を低減し、また認可ツリー
内の決定プロシージャ情報を曖昧化した上で、取引の認
可を可能にすることであり、従って本発明の方法は、特
に企業間取引において有用である。
が使用される場合に空間要求を低減し、また認可ツリー
内の決定プロシージャ情報を曖昧化した上で、取引の認
可を可能にすることであり、従って本発明の方法は、特
に企業間取引において有用である。
【００１６】
【課題を解決するための手段】複数の相互接続されるコ
ンピュータ及び複数の資源を含むコンピュータ・ネット
ワーク上で動作する、取引認可方法が提供される。各コ
ンピュータはプロセッサ、メモリ及び入出力装置を含
み、各資源は少なくとも１つのコンピュータに動作上接
続され、プロセス・フローにおいて少なくとも１つの活
動を実行する。本方法は、認可に関連付けられる少なく
とも１つのタイプの職務証明を抽出し、職務証明そのも
のが信頼できるか否かを確認することにより、取引の電
子認可を検証可能に編成する。本方法は、職務にもとづ
く認可構造を提供することにより、取引に関する各々の
及びあらゆる署名を個々に認可する必要性を排除する。
この構造は、取引の認可を確認するために公衆ネットワ
ーク上でアクセス可能である。
ンピュータ及び複数の資源を含むコンピュータ・ネット
ワーク上で動作する、取引認可方法が提供される。各コ
ンピュータはプロセッサ、メモリ及び入出力装置を含
み、各資源は少なくとも１つのコンピュータに動作上接
続され、プロセス・フローにおいて少なくとも１つの活
動を実行する。本方法は、認可に関連付けられる少なく
とも１つのタイプの職務証明を抽出し、職務証明そのも
のが信頼できるか否かを確認することにより、取引の電
子認可を検証可能に編成する。本方法は、職務にもとづ
く認可構造を提供することにより、取引に関する各々の
及びあらゆる署名を個々に認可する必要性を排除する。
この構造は、取引の認可を確認するために公衆ネットワ
ーク上でアクセス可能である。
【００１７】本方法は企業内及び企業間の両方の状況に
おいて適用可能である。なぜなら、本方法は匿名の証明
書により表される、職務にもとづく匿名の認可決定を行
うからである。このように、取引の信頼性を確認すると
き、社員の識別が明かされる必要がない。
おいて適用可能である。なぜなら、本方法は匿名の証明
書により表される、職務にもとづく匿名の認可決定を行
うからである。このように、取引の信頼性を確認すると
き、社員の識別が明かされる必要がない。
【００１８】更に、本方法は特定の取引に対して認可ツ
リーを用いることにより、そのタイプの取引を認可でき
る職務の組み合わせを決定する。
リーを用いることにより、そのタイプの取引を認可でき
る職務の組み合わせを決定する。
【００１９】企業間認可に関わる本発明の別の特徴とし
て、認可ツリーのハッシュド・バージョンが使用され、
それにより会社の承認構造に関する最小の情報を明かす
ことにより、所与のユーザが取引を行うことを認可され
る証明を提供する。このように、本方法は会社の決定構
造の詳細を曖昧化する態様において、その決定構造の確
認を可能にする。
て、認可ツリーのハッシュド・バージョンが使用され、
それにより会社の承認構造に関する最小の情報を明かす
ことにより、所与のユーザが取引を行うことを認可され
る証明を提供する。このように、本方法は会社の決定構
造の詳細を曖昧化する態様において、その決定構造の確
認を可能にする。
【００２０】
【発明の実施の形態】図１を参照すると、取引認可方法
（ＴＡＭ：Transaction Authorization Method）２が、
電子商取引において契約４の有効性を保証する手段を提
供し、ここでこうした契約はそれらの有効性が容易に確
認できるように構築される。
（ＴＡＭ：Transaction Authorization Method）２が、
電子商取引において契約４の有効性を保証する手段を提
供し、ここでこうした契約はそれらの有効性が容易に確
認できるように構築される。
【００２１】ＴＡＭ２は、分散ワークフロー管理システ
ム６内で動作するメッセージ交換機構を有する。方法２
は、１）依頼１０を認可するために、ユーザ８によりア
クセス可能であり、２）幾つかのデータベース７０、８
２、９６または２０２（図１１参照）へのアクセスを有
し、３）ユーザに接触して、署名１８を要求する属性を
有する。
ム６内で動作するメッセージ交換機構を有する。方法２
は、１）依頼１０を認可するために、ユーザ８によりア
クセス可能であり、２）幾つかのデータベース７０、８
２、９６または２０２（図１１参照）へのアクセスを有
し、３）ユーザに接触して、署名１８を要求する属性を
有する。
【００２２】ＴＡＭ２は、コンピュータ・ネットワーク
２５または３１（図２参照）を介する分散システム２１
内のコンピュータ・システム２０上で動作する。ここで
分散システム２１は、複数の相互接続コンピュータ２２
及び複数の資源２３を含む。ＴＡＭ２はコンピュータ読
取り可能媒体上で符号化されて、コンピュータ・システ
ム２０上で、またはイントラネット２５またはインター
ネット３１上のコンピュータ・システム及び１つ以上の
サーバ（５４ａ、５４ｂ）間で動作する。
２５または３１（図２参照）を介する分散システム２１
内のコンピュータ・システム２０上で動作する。ここで
分散システム２１は、複数の相互接続コンピュータ２２
及び複数の資源２３を含む。ＴＡＭ２はコンピュータ読
取り可能媒体上で符号化されて、コンピュータ・システ
ム２０上で、またはイントラネット２５またはインター
ネット３１上のコンピュータ・システム及び１つ以上の
サーバ（５４ａ、５４ｂ）間で動作する。
【００２３】コンピュータ・システム２０は一般に、コ
ンピュータ２２、表示装置２４、キーボードなどの入力
装置２６、１次記憶装置３０、及び２次記憶装置３２を
含む。本発明のＴＡＭ２により符号化されたソフトウェ
アのローディングの後、また場合によっては、インター
ネット・エクスプローラ５．０などのブラウザを通じて
サーバ２５または５４をアクセスした後、表示装置２４
がグラフィカル・ユーザ・インタフェース（ＧＵＩ）３
４を表示することにより、本方法に関連付けられるテキ
スト及びグラフィックスのユーザへの表示を容易にす
る。表示装置２４はプリンタ及びコンピュータ表示画面
を含み、後者にはＣＲＴ、ＬＥＤ表示装置、ＬＣＤ、フ
ラット・スクリーン、スクリーン・フォーン（screen p
hone）、及びプロジェクタなどが含まれる。入力装置２
６は多数から成り、キーボード及びポインティング・デ
バイスを含む。ポインティング・デバイスには、左マウ
ス・ボタン２８及び右マウス・ボタン２９を有するマウ
ス２７、トラック・ボール、ライトペン、サムホイー
ル、デジタイジング・タブレット、音声認識ソフトウェ
アを使用するマイクロフォン、及びタッチ・スクリーン
及びパッドが含まれる。
ンピュータ２２、表示装置２４、キーボードなどの入力
装置２６、１次記憶装置３０、及び２次記憶装置３２を
含む。本発明のＴＡＭ２により符号化されたソフトウェ
アのローディングの後、また場合によっては、インター
ネット・エクスプローラ５．０などのブラウザを通じて
サーバ２５または５４をアクセスした後、表示装置２４
がグラフィカル・ユーザ・インタフェース（ＧＵＩ）３
４を表示することにより、本方法に関連付けられるテキ
スト及びグラフィックスのユーザへの表示を容易にす
る。表示装置２４はプリンタ及びコンピュータ表示画面
を含み、後者にはＣＲＴ、ＬＥＤ表示装置、ＬＣＤ、フ
ラット・スクリーン、スクリーン・フォーン（screen p
hone）、及びプロジェクタなどが含まれる。入力装置２
６は多数から成り、キーボード及びポインティング・デ
バイスを含む。ポインティング・デバイスには、左マウ
ス・ボタン２８及び右マウス・ボタン２９を有するマウ
ス２７、トラック・ボール、ライトペン、サムホイー
ル、デジタイジング・タブレット、音声認識ソフトウェ
アを使用するマイクロフォン、及びタッチ・スクリーン
及びパッドが含まれる。
【００２４】各資源２３はコンピュータ２２の少なくと
も１つに動作上接続され、本方法２のプロセス・フロー
において、少なくとも１つの活動を実行する。資源２３
には、プリンタ、データベース、特殊用途サーバ、セキ
ュリティ装置、モデムなどが含まれる。
も１つに動作上接続され、本方法２のプロセス・フロー
において、少なくとも１つの活動を実行する。資源２３
には、プリンタ、データベース、特殊用途サーバ、セキ
ュリティ装置、モデムなどが含まれる。
【００２５】ＧＵＩ３４はデータ入力及びＴＡＭ２の制
御のための入力フィールド、並びにステータス及び他の
情報の表示のための出力ウィンドウを提供し、ワークフ
ロー・システムの管理及び操作を容易にする。ＴＡＭ２
は以下で詳述するように、取引に関連する情報を含むデ
ータベース３３をアクセスする。
御のための入力フィールド、並びにステータス及び他の
情報の表示のための出力ウィンドウを提供し、ワークフ
ロー・システムの管理及び操作を容易にする。ＴＡＭ２
は以下で詳述するように、取引に関連する情報を含むデ
ータベース３３をアクセスする。
【００２６】コンピュータ２２はＣＰＵ３６、並びに当
業者には周知の他のコンポーネントを含む。これらのコ
ンポーネント及びそれらの相互作用についての詳細につ
いては、米国特許第５７８７２５４号を参照されたい。
２次記憶装置３２はＴＡＭ３２をサポートし、好適には
ＨＴＴＰ準拠であり、同様に多数のインターネット・ア
クセス・ツールをサポートする。ＣＰＵ３６は、バス４
２に接続される入出力サブシステムなどのインタフェー
ス４１を介して、１次記憶装置３０からコンピュータ命
令をフェッチする。コンピュータ２２は、例えばＩＢＭ
の製品である"ＩＢＭアプティバ"・コンピュータ、或い
はインテル社のＸ８６またはPentium（商標）シリーズ
・プロセッサまたは互換プロセッサにもとづく、ＩＢＭ
ＰＣコンピュータ・システムと互換の任意の他のコン
ピュータ、若しくは他の好適なコンピュータである。Ｃ
ＰＵ３６はオペレーティング・システムを使用し、これ
は使用するハードウェアに応じてＤＯＳ、"ウィンドウ
ズ（登録商標）３．Ｘ"、"ウィンドウズＸＸＸＸ"、"Ｎ
Ｔ"、"ＯＳ／Ｘ"、"ＡＩＸ"、"ＬＩＮＵＸ"、または任
意の他の好適なオペレーティング・システムである。Ｃ
ＰＵ３６はこれらのフェッチされたコンピュータ命令を
実行する。これらの命令の実行は、ＣＰＵ３６がデータ
を取り出したり、データを１次記憶装置３０に書込んだ
り、ＴＡＭ２の統計表示などの情報を１つ以上の表示装
置２４上に表示したり、１つ以上の入力装置２６からコ
マンド信号を受信したり、データを２次記憶装置３２ま
たは集合的にコンピュータ・ネットワーク２５（図２参
照）を形成する他のコンピュータ・システムに転送した
りすることを可能にする。当業者であれば、１次記憶装
置３０及び２次記憶装置３２が、任意のタイプのコンピ
ュータ記憶装置を含み得ることが理解できよう。それら
にはＲＡＭ、ＲＯＭ、特定用途向け集積回路（ＡＳＩ
Ｃ）、及びＣＤ−ＲＯＭなどの磁気及び光記憶媒体を含
む記憶装置が含まれる。
業者には周知の他のコンポーネントを含む。これらのコ
ンポーネント及びそれらの相互作用についての詳細につ
いては、米国特許第５７８７２５４号を参照されたい。
２次記憶装置３２はＴＡＭ３２をサポートし、好適には
ＨＴＴＰ準拠であり、同様に多数のインターネット・ア
クセス・ツールをサポートする。ＣＰＵ３６は、バス４
２に接続される入出力サブシステムなどのインタフェー
ス４１を介して、１次記憶装置３０からコンピュータ命
令をフェッチする。コンピュータ２２は、例えばＩＢＭ
の製品である"ＩＢＭアプティバ"・コンピュータ、或い
はインテル社のＸ８６またはPentium（商標）シリーズ
・プロセッサまたは互換プロセッサにもとづく、ＩＢＭ
ＰＣコンピュータ・システムと互換の任意の他のコン
ピュータ、若しくは他の好適なコンピュータである。Ｃ
ＰＵ３６はオペレーティング・システムを使用し、これ
は使用するハードウェアに応じてＤＯＳ、"ウィンドウ
ズ（登録商標）３．Ｘ"、"ウィンドウズＸＸＸＸ"、"Ｎ
Ｔ"、"ＯＳ／Ｘ"、"ＡＩＸ"、"ＬＩＮＵＸ"、または任
意の他の好適なオペレーティング・システムである。Ｃ
ＰＵ３６はこれらのフェッチされたコンピュータ命令を
実行する。これらの命令の実行は、ＣＰＵ３６がデータ
を取り出したり、データを１次記憶装置３０に書込んだ
り、ＴＡＭ２の統計表示などの情報を１つ以上の表示装
置２４上に表示したり、１つ以上の入力装置２６からコ
マンド信号を受信したり、データを２次記憶装置３２ま
たは集合的にコンピュータ・ネットワーク２５（図２参
照）を形成する他のコンピュータ・システムに転送した
りすることを可能にする。当業者であれば、１次記憶装
置３０及び２次記憶装置３２が、任意のタイプのコンピ
ュータ記憶装置を含み得ることが理解できよう。それら
にはＲＡＭ、ＲＯＭ、特定用途向け集積回路（ＡＳＩ
Ｃ）、及びＣＤ−ＲＯＭなどの磁気及び光記憶媒体を含
む記憶装置が含まれる。
【００２７】図３を参照すると、電子商取引の間にオン
ラインで実行される取引４０の多くのクラスが存在す
る。この開示では、各取引４０が依頼者４２と検証者ま
たは値提供者４４との間で発生する。依頼者４２は製品
またはサービス４６を所望し、値提供者４４は、依頼者
の依頼書５２を表す電子文書５０が適切に認可されてい
ることを確かめたいと思う。すなわち、値提供者４４は
文書５０の信頼性を確認したいと思う。ほとんどの一般
的な状況では、依頼者４２及び検証者４４は同一の会社
により雇用されていることも、そうでないこともある。
ラインで実行される取引４０の多くのクラスが存在す
る。この開示では、各取引４０が依頼者４２と検証者ま
たは値提供者４４との間で発生する。依頼者４２は製品
またはサービス４６を所望し、値提供者４４は、依頼者
の依頼書５２を表す電子文書５０が適切に認可されてい
ることを確かめたいと思う。すなわち、値提供者４４は
文書５０の信頼性を確認したいと思う。ほとんどの一般
的な状況では、依頼者４２及び検証者４４は同一の会社
により雇用されていることも、そうでないこともある。
【００２８】例えば、依頼書５２に関連付けられる文書
５０は、製品またはサービスの契約であり、例えば要求
元会社の社員から会社の旅行業者への、または出張のた
めの必要資金が使用可能か否かを判断するために、社員
から同一会社の金融当局者へ提出される出張依頼書５４
（図６参照）である。
５０は、製品またはサービスの契約であり、例えば要求
元会社の社員から会社の旅行業者への、または出張のた
めの必要資金が使用可能か否かを判断するために、社員
から同一会社の金融当局者へ提出される出張依頼書５４
（図６参照）である。
【００２９】図４を参照すると、本方法のより詳細なフ
ロー図が示される。そこでは、ＴＡＭ２が次のステップ
を実行する。第１のステップ６０で、従業員が取引４０
をＴＡＭ２から要求する。第２のステップ６２で、ＴＡ
Ｍ２が取引４０の詳細６６のＨＴＭＬ表現６４を、デジ
タル文書データベース（ＤＤＤ：Digital Document Dat
abase）７０（図７参照）から要求する。第３のステッ
プ７２で、デジタル文書データベース７０が取引詳細６
６のＨＴＭＬ表現６４をＴＡＭ２に返却する。第４のス
テップ７４で、ＴＡＭ２が取引当局（ＴＡ：Transactio
n Authority）８０の職務証明書７６を、職務証明書デ
ータベース（ＲＣＤ：Role CertificateDatabase）８２
から要求する。職務証明書データベースは、匿名の職務
証明書から成り（ここで匿名性は、ユーザの名前が証明
書内に含まれていないことによる）、これはＴＡ８０の
職務証明書を含む（これについては以下で詳述する）。
第５のステップ８４では、職務証明書データベース８２
がＴＡ８０の職務証明書７６を返却し、ＴＡＭ２がデジ
タル文書データベース７０から返却された取引依頼詳細
６０のＨＴＭＬ表現６４上のＴＡの署名１２６を確認す
る。第６のステップ８６では、ＴＡＭ２がＨＴＭＬ取引
詳細６６を依頼者４２に返却する。第７のステップ９０
では、依頼者がＨＴＭＬ表現６４を見て、指定された詳
細（例えば名前、行き先、費用など）を完成し、完成さ
れたＨＴＭＬ表現６４を署名し、残りの署名を収集する
ために、署名済みのＨＴＭＬ表現をＴＡＭ２に返却す
る。第８のステップ９２では、ＴＡＭ２が取引の認可構
造（ＡＳ：Authorization Structure）９４を、認可構
造データベース（ＡＳＤ：Authorization Structure Da
tabase）９６から要求する。返却された認可構造９４が
ＴＡ８０により事前署名され、署名がＴＡＭ２により確
認される。ＴＡＭ２は職務名１０２の承認セット１００
及び関わるユーザの収集を選択して、これらの職務名に
署名する。第９のステップ１０４では、ＴＡＭ２が一般
社員依頼者４２の署名１０６を有する取引依頼書５２の
取引詳細６６を、承認セット１００に対応する職務を有
する他の者に転送し、承認セット１００に含まれる各々
の職務の署名を収集する。例えば、課長及び部長の署名
が収集され、各々が文書５４のそれぞれの職務欄に署名
される。第１０のステップ１１０では、ＴＡＭ２が承認
セット１００の各メンバの職務証明書７６及びそれぞれ
の署名を要求する。第１１のステップ１１２では、ＴＡ
Ｍ２が署名１０６及び職務証明書７６を含む文書５４を
依頼者４２に転送する。こうして、取引４０の有効性を
確認するために要求される全ての認可詳細６６を含むデ
ジタル文書１１４が作成される。ステップ１１６では、
任意的に、本方法２は署名済み文書１１４を確認する。
ロー図が示される。そこでは、ＴＡＭ２が次のステップ
を実行する。第１のステップ６０で、従業員が取引４０
をＴＡＭ２から要求する。第２のステップ６２で、ＴＡ
Ｍ２が取引４０の詳細６６のＨＴＭＬ表現６４を、デジ
タル文書データベース（ＤＤＤ：Digital Document Dat
abase）７０（図７参照）から要求する。第３のステッ
プ７２で、デジタル文書データベース７０が取引詳細６
６のＨＴＭＬ表現６４をＴＡＭ２に返却する。第４のス
テップ７４で、ＴＡＭ２が取引当局（ＴＡ：Transactio
n Authority）８０の職務証明書７６を、職務証明書デ
ータベース（ＲＣＤ：Role CertificateDatabase）８２
から要求する。職務証明書データベースは、匿名の職務
証明書から成り（ここで匿名性は、ユーザの名前が証明
書内に含まれていないことによる）、これはＴＡ８０の
職務証明書を含む（これについては以下で詳述する）。
第５のステップ８４では、職務証明書データベース８２
がＴＡ８０の職務証明書７６を返却し、ＴＡＭ２がデジ
タル文書データベース７０から返却された取引依頼詳細
６０のＨＴＭＬ表現６４上のＴＡの署名１２６を確認す
る。第６のステップ８６では、ＴＡＭ２がＨＴＭＬ取引
詳細６６を依頼者４２に返却する。第７のステップ９０
では、依頼者がＨＴＭＬ表現６４を見て、指定された詳
細（例えば名前、行き先、費用など）を完成し、完成さ
れたＨＴＭＬ表現６４を署名し、残りの署名を収集する
ために、署名済みのＨＴＭＬ表現をＴＡＭ２に返却す
る。第８のステップ９２では、ＴＡＭ２が取引の認可構
造（ＡＳ：Authorization Structure）９４を、認可構
造データベース（ＡＳＤ：Authorization Structure Da
tabase）９６から要求する。返却された認可構造９４が
ＴＡ８０により事前署名され、署名がＴＡＭ２により確
認される。ＴＡＭ２は職務名１０２の承認セット１００
及び関わるユーザの収集を選択して、これらの職務名に
署名する。第９のステップ１０４では、ＴＡＭ２が一般
社員依頼者４２の署名１０６を有する取引依頼書５２の
取引詳細６６を、承認セット１００に対応する職務を有
する他の者に転送し、承認セット１００に含まれる各々
の職務の署名を収集する。例えば、課長及び部長の署名
が収集され、各々が文書５４のそれぞれの職務欄に署名
される。第１０のステップ１１０では、ＴＡＭ２が承認
セット１００の各メンバの職務証明書７６及びそれぞれ
の署名を要求する。第１１のステップ１１２では、ＴＡ
Ｍ２が署名１０６及び職務証明書７６を含む文書５４を
依頼者４２に転送する。こうして、取引４０の有効性を
確認するために要求される全ての認可詳細６６を含むデ
ジタル文書１１４が作成される。ステップ１１６では、
任意的に、本方法２は署名済み文書１１４を確認する。
【００３０】図１０を参照すると、本方法２において、
匿名職務証明書７６は署名確認キー１２０と職務名１２
２との関連を示す。これは署名１０６の確認キー１２０
と名前（図示せず）との関連を示す、ＩＴＵ−Ｔ Ｘ．
５０９（１９９７Ｅ）（以下Ｘ５０９と記す）で述べら
れる標準の証明書とは異なる。より詳細には、Ｘ５０９
は公開キーと名前との関連であり、公開キーは暗号化及
び署名確認の両方のために使用される。しかしながら、
本方法２はユーザが職務資格１２２において暗号化を実
行することには関わらず、ユーザが職務資格において署
名１０６を生成することに関するものである。職務証明
書７６は証明書の所有者に関連する情報を有さないこと
により匿名である。証明書Ｃｅｒｔの所有者は、証明書
内に埋め込まれた公開キーに対応する私用キーを有する
ユーザとして暗に定義される。
匿名職務証明書７６は署名確認キー１２０と職務名１２
２との関連を示す。これは署名１０６の確認キー１２０
と名前（図示せず）との関連を示す、ＩＴＵ−Ｔ Ｘ．
５０９（１９９７Ｅ）（以下Ｘ５０９と記す）で述べら
れる標準の証明書とは異なる。より詳細には、Ｘ５０９
は公開キーと名前との関連であり、公開キーは暗号化及
び署名確認の両方のために使用される。しかしながら、
本方法２はユーザが職務資格１２２において暗号化を実
行することには関わらず、ユーザが職務資格において署
名１０６を生成することに関するものである。職務証明
書７６は証明書の所有者に関連する情報を有さないこと
により匿名である。証明書Ｃｅｒｔの所有者は、証明書
内に埋め込まれた公開キーに対応する私用キーを有する
ユーザとして暗に定義される。
【００３１】職務証明書７６は本方法２において重要な
役割を果たす。ここで任意の会社Ｃにおいて、明確な職
務ＲＣ＝｛Ｒ１、Ｒ２、．．、Ｒｍ｝のセットが存在
し、会社Ｃ内の各ユーザＵが１つまたは複数の職務ＵＲ
⊆ＲＣを割当てられると仮定する。本方法２の目的上、
各ユーザは彼らの名前、公開キー及び他のフィールドを
含み、ローカル認証局ＣＡ（certificate authority）
により署名されたＸ．５０９公開キー証明書ＣｅｒｔＣ
Ａ（Ｕ）を有するものとする。Ｘ．５０９証明書は、電
子メール・アドレス、代替名、及び方針情報などの一般
情報のための拡張フィールドを含むので、指定された職
務１２２が拡張フィールドとして含まれることは可能で
ある。しかしながら、証明書は名前フィールドを含むの
で、職務１２２及び証明書の所有者は明示的にリンクさ
れる。ＩＥＴＦワーキング・グループも職務１２２、グ
ループ・メンバシップ、及び名前への保全許可（securi
ty clearance）などの属性を結びつける属性証明書（Ａ
Ｃ：attribute certificate）の概念を現在開発中であ
る（S．Farrellによる"An Internet Attribute Certifi
cate Profile for Authorization"、August 20、1998参
照）。しかしながら、属性証明書は公開キーを含まない
ので、属性証明書内で指定される名前は、既存のＸ．５
０９ＣｅｒｔＣＡ（Ｕ）内で指定される個人Ｕに関する
補足情報を提供するように意図される。証明書保持者の
名前はＡＣ内に含まれるので、名前及び職務は直接リン
クされる。本方法２の目的上、職務証明書７６及び属性
証明書の両方が受け入れ可能である。なぜなら、本方法
は職務１２２を含む証明書を使用してアクションを認可
するからであるが、本方法では、職務がそれが割当てら
れるユーザに直接関連付けられないことが望ましい。
役割を果たす。ここで任意の会社Ｃにおいて、明確な職
務ＲＣ＝｛Ｒ１、Ｒ２、．．、Ｒｍ｝のセットが存在
し、会社Ｃ内の各ユーザＵが１つまたは複数の職務ＵＲ
⊆ＲＣを割当てられると仮定する。本方法２の目的上、
各ユーザは彼らの名前、公開キー及び他のフィールドを
含み、ローカル認証局ＣＡ（certificate authority）
により署名されたＸ．５０９公開キー証明書ＣｅｒｔＣ
Ａ（Ｕ）を有するものとする。Ｘ．５０９証明書は、電
子メール・アドレス、代替名、及び方針情報などの一般
情報のための拡張フィールドを含むので、指定された職
務１２２が拡張フィールドとして含まれることは可能で
ある。しかしながら、証明書は名前フィールドを含むの
で、職務１２２及び証明書の所有者は明示的にリンクさ
れる。ＩＥＴＦワーキング・グループも職務１２２、グ
ループ・メンバシップ、及び名前への保全許可（securi
ty clearance）などの属性を結びつける属性証明書（Ａ
Ｃ：attribute certificate）の概念を現在開発中であ
る（S．Farrellによる"An Internet Attribute Certifi
cate Profile for Authorization"、August 20、1998参
照）。しかしながら、属性証明書は公開キーを含まない
ので、属性証明書内で指定される名前は、既存のＸ．５
０９ＣｅｒｔＣＡ（Ｕ）内で指定される個人Ｕに関する
補足情報を提供するように意図される。証明書保持者の
名前はＡＣ内に含まれるので、名前及び職務は直接リン
クされる。本方法２の目的上、職務証明書７６及び属性
証明書の両方が受け入れ可能である。なぜなら、本方法
は職務１２２を含む証明書を使用してアクションを認可
するからであるが、本方法では、職務がそれが割当てら
れるユーザに直接関連付けられないことが望ましい。
【００３２】従って、本方法２はユーザＵに対して、匿
名職務証明書７６（ＣｅｒｔＣＡ（Ｕ、Ｒ））を使用
し、これは次の変更を有するＸ．５０９ｖ３証明書であ
る。すなわち、１）名前フィールドが架空のユーザを表
す、２）ユーザＵの職務１２２を含む拡張フィールドが
存在する、３）Ｃｅｒｔ（ｕ）からＣｅｒｔ（ｕ、Ｒ）
への順方向参照をを含む拡張フィールドが存在する。
名職務証明書７６（ＣｅｒｔＣＡ（Ｕ、Ｒ））を使用
し、これは次の変更を有するＸ．５０９ｖ３証明書であ
る。すなわち、１）名前フィールドが架空のユーザを表
す、２）ユーザＵの職務１２２を含む拡張フィールドが
存在する、３）Ｃｅｒｔ（ｕ）からＣｅｒｔ（ｕ、Ｒ）
への順方向参照をを含む拡張フィールドが存在する。
【００３３】順方向参照は、例えばＥ（Ｃ、Ｕ、パスワ
ード）の形式を取り、これは会社Ｃの公開キーまたはロ
ーカル認証局の公開キーによる、ユーザＵ及びパスワー
ドの連結の公開キー暗号化を示す。順方向参照は単に、
会社が職務証明書の所有者を識別するための機構であ
り、本方法にとって他の重要性は有さない。ユーザＵが
幾つかの職務１２２を有する場合、各職務に対する職務
証明書７６が存在する。ここで重要な点は、各職務証明
書が公開キー及び対応する私用キーを有し、それにより
ユーザが彼らの資格において署名を生成することであ
る。従って、各ユーザは少なくとも２つの証明書、すな
わち、彼らの名前を公開キーに結びつける標準のＸ．５
０９ｖ３証明書ＣｅｒｔＣＡ（Ｕ）、及び彼らの職務を
公開キーに結びつける匿名職務証明書７６（ＣｅｒｔＣ
Ａ（Ｕ、Ｒ））を有する。ＣｅｒｔＣＡ（Ｕ）は順方向
参照によりＣｅｒｔＣＡ（Ｕ、Ｒ）にリンクされるが、
所与のＣｅｒｔＣＡ（Ｕ、Ｒ）に対して、ユーザＵのＣ
ｅｒｔＣＡ（Ｕ）または識別を決定する明白な方法は存
在しない。本方法２の目的上、職務証明書７６（Ｃｅｒ
ｔＣＡ（Ｕ、Ｒ））に関連付けられる私用キー１２４に
より生成される署名１０６は、職務署名１２６として定
義される。
ード）の形式を取り、これは会社Ｃの公開キーまたはロ
ーカル認証局の公開キーによる、ユーザＵ及びパスワー
ドの連結の公開キー暗号化を示す。順方向参照は単に、
会社が職務証明書の所有者を識別するための機構であ
り、本方法にとって他の重要性は有さない。ユーザＵが
幾つかの職務１２２を有する場合、各職務に対する職務
証明書７６が存在する。ここで重要な点は、各職務証明
書が公開キー及び対応する私用キーを有し、それにより
ユーザが彼らの資格において署名を生成することであ
る。従って、各ユーザは少なくとも２つの証明書、すな
わち、彼らの名前を公開キーに結びつける標準のＸ．５
０９ｖ３証明書ＣｅｒｔＣＡ（Ｕ）、及び彼らの職務を
公開キーに結びつける匿名職務証明書７６（ＣｅｒｔＣ
Ａ（Ｕ、Ｒ））を有する。ＣｅｒｔＣＡ（Ｕ）は順方向
参照によりＣｅｒｔＣＡ（Ｕ、Ｒ）にリンクされるが、
所与のＣｅｒｔＣＡ（Ｕ、Ｒ）に対して、ユーザＵのＣ
ｅｒｔＣＡ（Ｕ）または識別を決定する明白な方法は存
在しない。本方法２の目的上、職務証明書７６（Ｃｅｒ
ｔＣＡ（Ｕ、Ｒ））に関連付けられる私用キー１２４に
より生成される署名１０６は、職務署名１２６として定
義される。
【００３４】従って、ユーザが取引４０上に署名１２６
を生成すると、検証者１３０は、例えばユーザが課長か
それとも部長か、或いはこの職務が所与の業務に如何に
関係するかなど、ユーザが社内で有する職務１２２に関
心を持つ。ユーザによって引き受けられる職務１２２だ
けが、業務が認可されたか否かを確認する上での関心事
であるので、ユーザの識別や名前は実際には重要ではな
い。
を生成すると、検証者１３０は、例えばユーザが課長か
それとも部長か、或いはこの職務が所与の業務に如何に
関係するかなど、ユーザが社内で有する職務１２２に関
心を持つ。ユーザによって引き受けられる職務１２２だ
けが、業務が認可されたか否かを確認する上での関心事
であるので、ユーザの識別や名前は実際には重要ではな
い。
【００３５】図５を参照すると、確認作業を達成するた
めに、ＴＡＭ２は作成され署名済み文書１１４の確認を
可能にする確認補助方法１１６を含む。第１のステップ
１３２では、職務署名１２６が文書１１４上でチェック
される。第２のステップ１３４では、取引が認可された
取引であることを保証するために、取引タイプ自身がチ
ェックされる。第２のステップ１３４のサブステップ１
３６では、職務名１２２が職務証明書７６から抽出され
る。第２のステップ１３４の第２のサブステップ１４０
では、職務名１２２がハッシュされる。第２のステップ
１３４の第３のサブステップ１４２では、取引４０の計
算されたハッシュ値が、認可構造（ＡＳ）９４内で受信
された取引４０の値に等しいことを保証するために、チ
ェックが行われる。第２のステップ１３４の第４のサブ
ステップ１４４では、取引４０上のＴＡ８０の署名１２
６が正しいことを保証するためにチェックが行われる。
正しい場合、取引４０が確認され、この事実の通知が依
頼者４２に送信される。
めに、ＴＡＭ２は作成され署名済み文書１１４の確認を
可能にする確認補助方法１１６を含む。第１のステップ
１３２では、職務署名１２６が文書１１４上でチェック
される。第２のステップ１３４では、取引が認可された
取引であることを保証するために、取引タイプ自身がチ
ェックされる。第２のステップ１３４のサブステップ１
３６では、職務名１２２が職務証明書７６から抽出され
る。第２のステップ１３４の第２のサブステップ１４０
では、職務名１２２がハッシュされる。第２のステップ
１３４の第３のサブステップ１４２では、取引４０の計
算されたハッシュ値が、認可構造（ＡＳ）９４内で受信
された取引４０の値に等しいことを保証するために、チ
ェックが行われる。第２のステップ１３４の第４のサブ
ステップ１４４では、取引４０上のＴＡ８０の署名１２
６が正しいことを保証するためにチェックが行われる。
正しい場合、取引４０が確認され、この事実の通知が依
頼者４２に送信される。
【００３６】このように、確認は単に署名をチェックす
るプロセスであり、検証者１３０は取引４０の詳細６６
には関わらない。ここで署名者が取引４０の詳細６６を
チェックし、これらの詳細が所与のタイプＴの取引に関
する会社方針から外れる場合、彼らの署名１０６を保留
するものとする。この仮定は再度、検証者１３０が一般
に、署名済み用紙の詳細にではなしに、提供される署名
により関心を寄せる書式署名モデルに固有である。
るプロセスであり、検証者１３０は取引４０の詳細６６
には関わらない。ここで署名者が取引４０の詳細６６を
チェックし、これらの詳細が所与のタイプＴの取引に関
する会社方針から外れる場合、彼らの署名１０６を保留
するものとする。この仮定は再度、検証者１３０が一般
に、署名済み用紙の詳細にではなしに、提供される署名
により関心を寄せる書式署名モデルに固有である。
【００３７】この残りの詳細説明では、出張依頼取引が
ＴＡＭ２のステップを説明するために使用される。
ＴＡＭ２のステップを説明するために使用される。
【００３８】図６を参照すると、ＩＢＭ出張依頼書５４
の構造が示される。従来、書類文書が、特に出張依頼の
承認などの様々な取引に使用されてきた。取引当局（Ｔ
Ａ）８０（図７参照）の業務は、これらの書類用紙をデ
ジタル文書６４（幾つかの可能な書式が存在するが、好
適にはＨＴＭＬ形式）に変換することである。各書式に
対してＴＡ８０は取引詳細６６と見なされるもの、及び
認可情報１４６と見なされるものを分離する。出張依頼
書５４では、取引詳細６６は依頼者名、行き先、旅費、
出発日などが含まれる。書類用紙及びそれから構成され
るＨＴＭＬ文書６４上では、ほとんどの取引詳細６６は
単に、依頼者４２により提供される情報のプレースホル
ダである。
の構造が示される。従来、書類文書が、特に出張依頼の
承認などの様々な取引に使用されてきた。取引当局（Ｔ
Ａ）８０（図７参照）の業務は、これらの書類用紙をデ
ジタル文書６４（幾つかの可能な書式が存在するが、好
適にはＨＴＭＬ形式）に変換することである。各書式に
対してＴＡ８０は取引詳細６６と見なされるもの、及び
認可情報１４６と見なされるものを分離する。出張依頼
書５４では、取引詳細６６は依頼者名、行き先、旅費、
出発日などが含まれる。書類用紙及びそれから構成され
るＨＴＭＬ文書６４上では、ほとんどの取引詳細６６は
単に、依頼者４２により提供される情報のプレースホル
ダである。
【００３９】認可詳細１４６は一般に、取引４０を連帯
で認可するように要求される人達の職務１２２のリスト
から成る。書類用紙の認可とは、通常、それに署名する
ことを意味し、ＨＴＭＬ文書６４では、認可詳細６６
は、どの職務１２２のどの人間が取引４０を認可するか
を示す。出張依頼書５４では、出頭依頼を認可する承認
セット１００に対応する認可詳細６６が、依頼者１６
５、課長１６７、及び部長１６９の電子署名１０６から
成る（図９参照）。これは依頼者４２、及び課長の職務
１２２の人間、及び部長の職務１２２の人間が、デジタ
ル的にＨＴＭＬ書式６４に署名しなければ、それが認可
されないことを意味する。
で認可するように要求される人達の職務１２２のリスト
から成る。書類用紙の認可とは、通常、それに署名する
ことを意味し、ＨＴＭＬ文書６４では、認可詳細６６
は、どの職務１２２のどの人間が取引４０を認可するか
を示す。出張依頼書５４では、出頭依頼を認可する承認
セット１００に対応する認可詳細６６が、依頼者１６
５、課長１６７、及び部長１６９の電子署名１０６から
成る（図９参照）。これは依頼者４２、及び課長の職務
１２２の人間、及び部長の職務１２２の人間が、デジタ
ル的にＨＴＭＬ書式６４に署名しなければ、それが認可
されないことを意味する。
【００４０】図７を参照すると、出張依頼書６４に対し
てＴＡ８０は出張取引詳細６６をＨＴＭＬで作成し、こ
れらの詳細に署名し、署名済み文書をデジタル文書デー
タベース７０に記憶する。従って、ＴＡ８０の職務を、
関連署名確認キー１２０を含むＴＡ職務証明書７６（図
８参照）を交付された人間に割当てることが必要であ
る。ＴＡ８０はまた、突き合わせ署名キー１５０を別に
交付される。ＴＡ８０署名キー１５０と一緒に生成され
る署名は、ＴＡ職務証明書７６内の確認キー１２０と共
に確認される（図１０参照）。
てＴＡ８０は出張取引詳細６６をＨＴＭＬで作成し、こ
れらの詳細に署名し、署名済み文書をデジタル文書デー
タベース７０に記憶する。従って、ＴＡ８０の職務を、
関連署名確認キー１２０を含むＴＡ職務証明書７６（図
８参照）を交付された人間に割当てることが必要であ
る。ＴＡ８０はまた、突き合わせ署名キー１５０を別に
交付される。ＴＡ８０署名キー１５０と一緒に生成され
る署名は、ＴＡ職務証明書７６内の確認キー１２０と共
に確認される（図１０参照）。
【００４１】ＴＡ８０は出張依頼書６４の認可構造９４
を生成し、文書に署名し、次に認可構造データベース９
６に記憶する。認可構造９４は、取引４０を認可するた
めに使用される職務を表す。
を生成し、文書に署名し、次に認可構造データベース９
６に記憶する。認可構造９４は、取引４０を認可するた
めに使用される職務を表す。
【００４２】デジタル文書データベース７０及び認可構
造データベース９６内の情報は、それ自体秘密であるこ
とを要求されない。しかしながら、情報の保全性が保護
されることは必要である。この理由から、ＴＡ８０はこ
うした文書に署名しなければならない。
造データベース９６内の情報は、それ自体秘密であるこ
とを要求されない。しかしながら、情報の保全性が保護
されることは必要である。この理由から、ＴＡ８０はこ
うした文書に署名しなければならない。
【００４３】図８を参照すると、認可構造（ＡＳ）９８
が如何に生成されるかに関する詳細は、本発明の主題で
ない社会的及び戦略的管理要因に依存する。認可構造９
８の主な属性は、その構造が承認セット１００の概念に
依存することである。承認セット１００が意味する内容
を説明するために、セットＰＴ、１＝｛Ｕ、Ｍ、ＤＨ｝
が取引Ｔの承認セットとする。この例では、取引Ｔが１
つの承認セットだけを有するが、一般には、取引はＰ
Ｔ、１、ＰＴ、２、．．．、ＰＴ、ｊにより示される幾
つかの承認セットを有する。各承認セット１００は職務
１２２のセットを含み（すなわち、ＰＴ、ｉ⊆Ｒ、潜在
的に複数セット）、任意のユーザＵが、Ｄ（Ｔ、Ｕ）に
より表される取引Ｔに対して認可されることを意味す
る。Ｔのある承認セットＰＴ、ｉ＝｛Ｒ１、Ｒ
２、．．．、Ｒｍ｝に対して、職務Ｒ１、Ｒ
２、．．．、Ｒｍのｍ人のユーザが、彼らのそれぞれの
証明書を用いてＤ（Ｔ、Ｕ）に署名する。
が如何に生成されるかに関する詳細は、本発明の主題で
ない社会的及び戦略的管理要因に依存する。認可構造９
８の主な属性は、その構造が承認セット１００の概念に
依存することである。承認セット１００が意味する内容
を説明するために、セットＰＴ、１＝｛Ｕ、Ｍ、ＤＨ｝
が取引Ｔの承認セットとする。この例では、取引Ｔが１
つの承認セットだけを有するが、一般には、取引はＰ
Ｔ、１、ＰＴ、２、．．．、ＰＴ、ｊにより示される幾
つかの承認セットを有する。各承認セット１００は職務
１２２のセットを含み（すなわち、ＰＴ、ｉ⊆Ｒ、潜在
的に複数セット）、任意のユーザＵが、Ｄ（Ｔ、Ｕ）に
より表される取引Ｔに対して認可されることを意味す
る。Ｔのある承認セットＰＴ、ｉ＝｛Ｒ１、Ｒ
２、．．．、Ｒｍ｝に対して、職務Ｒ１、Ｒ
２、．．．、Ｒｍのｍ人のユーザが、彼らのそれぞれの
証明書を用いてＤ（Ｔ、Ｕ）に署名する。
【００４４】この時、承認セット１００すなわち（Ｐ
Ｔ、ｉ）は、職務１２２のセットを表し、それらの連帯
当局者が、タイプＴの取引４０を認可するために十分で
あると見なされる。ツリー１５４（図９参照）は、取引
Ｔの承認セット１００すなわちＰＴ＝｛ＰＴ、１、Ｐ
Ｔ、２、．．．、ＰＴ、ｋ｝を表すために使用される。
書式署名モデルに関して、ＰＴはタイプＴの取引を認可
するための決定プロシージャを示す。Merkleによる米国
特許第４３０９５６９号は、こうしたツリー１５４の一
般的な使用について述べている。
Ｔ、ｉ）は、職務１２２のセットを表し、それらの連帯
当局者が、タイプＴの取引４０を認可するために十分で
あると見なされる。ツリー１５４（図９参照）は、取引
Ｔの承認セット１００すなわちＰＴ＝｛ＰＴ、１、Ｐ
Ｔ、２、．．．、ＰＴ、ｋ｝を表すために使用される。
書式署名モデルに関して、ＰＴはタイプＴの取引を認可
するための決定プロシージャを示す。Merkleによる米国
特許第４３０９５６９号は、こうしたツリー１５４の一
般的な使用について述べている。
【００４５】図９を参照すると、各取引タイプＴに対し
て認可ツリー（ＡＴ：auhorizationtree）１５４は、ル
ートからの第１のレベル１６０に、ｋ個のノード１５６
が存在するように生成され、これらのノードは取引タイ
プＴに対するｋ個の承認セット１００、すなわちＰＴ＝
｛ＰＴ、１、ＰＴ、２、．．．、ＰＴ、ｉ｝に対応す
る。第２のレベル１６４のノードはリーフ１６６であ
り、各承認セット１００の職務１２２を表す。
て認可ツリー（ＡＴ：auhorizationtree）１５４は、ル
ートからの第１のレベル１６０に、ｋ個のノード１５６
が存在するように生成され、これらのノードは取引タイ
プＴに対するｋ個の承認セット１００、すなわちＰＴ＝
｛ＰＴ、１、ＰＴ、２、．．．、ＰＴ、ｉ｝に対応す
る。第２のレベル１６４のノードはリーフ１６６であ
り、各承認セット１００の職務１２２を表す。
【００４６】取引Ｔに対する承認セット１００（ＰＴ）
が、ＰＴ、１＝｛Ｒ１、Ｒ２｝及びＰＴ、２＝｛Ｒ３、
Ｒ４、Ｒ５｝及びＰＴ、３＝｛Ｒ６｝の場合、ＡＴ１５
４は２つのレベルを有する。第１のレベル１６０は、３
つのノード１５６によるＰＴ、１、ＰＴ、２及びＰＴ、
３を表し、各ＰＴ、ｉ１００は、承認セット内の職務１
２２の数と同一の数のリーフ１６６を有する。従って、
例えばＰＴ、１（１００）は図９に示されるように、Ｒ
１及びＲ２を表す２つの子（両方ともリーフ１６６）を
有する。
が、ＰＴ、１＝｛Ｒ１、Ｒ２｝及びＰＴ、２＝｛Ｒ３、
Ｒ４、Ｒ５｝及びＰＴ、３＝｛Ｒ６｝の場合、ＡＴ１５
４は２つのレベルを有する。第１のレベル１６０は、３
つのノード１５６によるＰＴ、１、ＰＴ、２及びＰＴ、
３を表し、各ＰＴ、ｉ１００は、承認セット内の職務１
２２の数と同一の数のリーフ１６６を有する。従って、
例えばＰＴ、１（１００）は図９に示されるように、Ｒ
１及びＲ２を表す２つの子（両方ともリーフ１６６）を
有する。
【００４７】少なくとも１つの承認セット１００すなわ
ちＰＴ、ｉにおいて、ＰＴ、ｉ内の各職務１２２の署名
が獲得される場合、取引４０は認可されたと見なされる
ので、ＰＴ、ｉを表すノード１５６は"ＡＮＤ"ノード１
７０と見なされ、ＡＴ１５４のルート１６２は"ＯＲ"ノ
ード１７２と見なされる。ＡＮＤノード１７０は、ノー
ドの全ての子が依頼書Ｄ（Ｔ、Ｕ）に同意しなければな
らないことを意味し（承認セット１００内の全ての職務
１２２が署名しなければならない）、ＯＲノード１７２
は少なくとも１つの子が依頼書Ｄ（Ｔ、Ｕ）に同意しな
ければならないことを意味する（少なくとも１つの承認
セットが連帯署名しなければならない）。或いは、ＡＴ
８０は、取引４０を認可できる職務１２２の離接的表現
（disjunctive representation）と解釈されてもよい。
ちＰＴ、ｉにおいて、ＰＴ、ｉ内の各職務１２２の署名
が獲得される場合、取引４０は認可されたと見なされる
ので、ＰＴ、ｉを表すノード１５６は"ＡＮＤ"ノード１
７０と見なされ、ＡＴ１５４のルート１６２は"ＯＲ"ノ
ード１７２と見なされる。ＡＮＤノード１７０は、ノー
ドの全ての子が依頼書Ｄ（Ｔ、Ｕ）に同意しなければな
らないことを意味し（承認セット１００内の全ての職務
１２２が署名しなければならない）、ＯＲノード１７２
は少なくとも１つの子が依頼書Ｄ（Ｔ、Ｕ）に同意しな
ければならないことを意味する（少なくとも１つの承認
セットが連帯署名しなければならない）。或いは、ＡＴ
８０は、取引４０を認可できる職務１２２の離接的表現
（disjunctive representation）と解釈されてもよい。
【００４８】図８を参照すると、出張依頼書６４では、
承認セット１００が依頼者４２、課長及び部長から成
る。これらは以下で詳述される。
承認セット１００が依頼者４２、課長及び部長から成
る。これらは以下で詳述される。
【００４９】図１０を参照すると、認可構造（ＡＳ）９
８は承認セット１００にもとづき、これらのセットが指
定の職務１２２からなるので、各ユーザは職務名により
指定される１つ以上の職務を交付される。ユーザは彼ら
の資格において、所与の職務名１２２の下で署名するこ
とを要求されるので、ユーザは次に職務証明書７６を交
付される。職務証明書７６は職務名１２２、署名確認キ
ー１２０、職務証明書７６上の役職者署名１０６、及び
他の管理情報（職務証明書の交付日時、満了日時など）
を含む。ユーザが職務証明書７６を与えられるとき、職
務証明書内の確認キー１２０に合致する対応する署名キ
ー１５０も与えられる。実際、ユーザは対応する署名キ
ー１５０を所有することにより、彼が所与の職務証明書
７６を所有することを証明する。結果的に、署名キー１
５０はそれが交付されるユーザにより、秘密にされなけ
ればならない。交付される職務証明書７６の各々もま
た、職務証明書データベース８２（ＲＣＤ）に記憶され
る。
８は承認セット１００にもとづき、これらのセットが指
定の職務１２２からなるので、各ユーザは職務名により
指定される１つ以上の職務を交付される。ユーザは彼ら
の資格において、所与の職務名１２２の下で署名するこ
とを要求されるので、ユーザは次に職務証明書７６を交
付される。職務証明書７６は職務名１２２、署名確認キ
ー１２０、職務証明書７６上の役職者署名１０６、及び
他の管理情報（職務証明書の交付日時、満了日時など）
を含む。ユーザが職務証明書７６を与えられるとき、職
務証明書内の確認キー１２０に合致する対応する署名キ
ー１５０も与えられる。実際、ユーザは対応する署名キ
ー１５０を所有することにより、彼が所与の職務証明書
７６を所有することを証明する。結果的に、署名キー１
５０はそれが交付されるユーザにより、秘密にされなけ
ればならない。交付される職務証明書７６の各々もま
た、職務証明書データベース８２（ＲＣＤ）に記憶され
る。
【００５０】以上で、本方法２の初期化が完了する。要
するに、初期化は書類用紙からデジタル文書６４への変
換と、取引当局８０による署名を含む。更に、ＴＡ８０
が各取引４０に対する認可構造９８（ＡＳ）を決定し、
この認可構造にも署名する。認可構造９８内の情報は指
定された職務にもとづき、職務当局１８０は各ユーザに
１つ以上の職務証明書７６を交付する。職務当局１８０
から交付される指定職務１２２のセットが、認可構造９
８の構造内のＴＡ８０により使用される。
するに、初期化は書類用紙からデジタル文書６４への変
換と、取引当局８０による署名を含む。更に、ＴＡ８０
が各取引４０に対する認可構造９８（ＡＳ）を決定し、
この認可構造にも署名する。認可構造９８内の情報は指
定された職務にもとづき、職務当局１８０は各ユーザに
１つ以上の職務証明書７６を交付する。職務当局１８０
から交付される指定職務１２２のセットが、認可構造９
８の構造内のＴＡ８０により使用される。
【００５１】次に図１１を参照しながら、出張依頼書６
４を認可する例について述べる。ここでユーザが出張依
頼書を作成し、それを認可してもらいたいと仮定する。
出張認可のユーザすなわち依頼者４２は、これをＴＡＭ
２の支援を通じて達成する。好適な実施例では、ＴＡＭ
２は会社のイントラネット２５上のサーバ・アプリケー
ションであり、ブラウザなどのＷｅｂインタフェースを
介して接続され得る。従って、ユーザはそのＵＲＬを介
してＴＡＭ２と連絡でき、自身が出張依頼書６４を作成
したいことを示す。ここで、出張依頼書の依頼者４２の
職務は一般社員である。
４を認可する例について述べる。ここでユーザが出張依
頼書を作成し、それを認可してもらいたいと仮定する。
出張認可のユーザすなわち依頼者４２は、これをＴＡＭ
２の支援を通じて達成する。好適な実施例では、ＴＡＭ
２は会社のイントラネット２５上のサーバ・アプリケー
ションであり、ブラウザなどのＷｅｂインタフェースを
介して接続され得る。従って、ユーザはそのＵＲＬを介
してＴＡＭ２と連絡でき、自身が出張依頼書６４を作成
したいことを示す。ここで、出張依頼書の依頼者４２の
職務は一般社員である。
【００５２】第１のステップ１８２では、ユーザすなわ
ち社員４２がＴＡＭ２から、出張依頼取引４０を要求す
る。ＴＡＭ２はユーザ４２から出張依頼書５２を受信
し、デジタル文書データベース７０と連絡を取り、この
クラスの取引４０の取引詳細６６のコピーを獲得する。
デジタル文書データベース７０はＨＴＭＬで表された詳
細６６をＴＡＭ２に返却する。ここでＨＴＭＬは事前に
取引当局（ＴＡ）８０により署名済みである。
ち社員４２がＴＡＭ２から、出張依頼取引４０を要求す
る。ＴＡＭ２はユーザ４２から出張依頼書５２を受信
し、デジタル文書データベース７０と連絡を取り、この
クラスの取引４０の取引詳細６６のコピーを獲得する。
デジタル文書データベース７０はＨＴＭＬで表された詳
細６６をＴＡＭ２に返却する。ここでＨＴＭＬは事前に
取引当局（ＴＡ）８０により署名済みである。
【００５３】第２のステップ１８４では、ＴＡＭ２が取
引詳細６６のＨＴＭＬ表現６４をデジタル文書データベ
ース７０から要求する。ＨＴＭＬ詳細が正しいか否かを
チェックするために、ＴＡＭ２はＴＡ８０の職務証明書
７６を職務証明書データベース８２（これはまた一般社
員１６５、課長１６７、部長１６９及び他の職務の職務
証明書、並びに会社内の異なるレベルの管理を含む）か
ら要求し、次に署名１０６を確認する。署名が適正な場
合、ＴＡＭ２は継続する。
引詳細６６のＨＴＭＬ表現６４をデジタル文書データベ
ース７０から要求する。ＨＴＭＬ詳細が正しいか否かを
チェックするために、ＴＡＭ２はＴＡ８０の職務証明書
７６を職務証明書データベース８２（これはまた一般社
員１６５、課長１６７、部長１６９及び他の職務の職務
証明書、並びに会社内の異なるレベルの管理を含む）か
ら要求し、次に署名１０６を確認する。署名が適正な場
合、ＴＡＭ２は継続する。
【００５４】第３のステップ１８６では、デジタル文書
データベース７０が出張依頼取引詳細６６のＨＴＭＬ表
現６４を返却する。
データベース７０が出張依頼取引詳細６６のＨＴＭＬ表
現６４を返却する。
【００５５】第４のステップ１９０では、ＴＡＭ２がＴ
Ａ８０の職務証明書７６を、職務証明書データベース８
２から要求する。第５のステップ１９２では、職務証明
書データベース８２がＴＡ８０の職務証明書７６を返却
し、ＴＡＭ２がデジタル文書データベース７０から返却
された、取引依頼詳細６６のＨＴＭＬ表現６４上のＴＡ
の署名１０６を確認する。
Ａ８０の職務証明書７６を、職務証明書データベース８
２から要求する。第５のステップ１９２では、職務証明
書データベース８２がＴＡ８０の職務証明書７６を返却
し、ＴＡＭ２がデジタル文書データベース７０から返却
された、取引依頼詳細６６のＨＴＭＬ表現６４上のＴＡ
の署名１０６を確認する。
【００５６】第６のステップ１９４では、ＴＡＭ２がＨ
ＴＭＬ取引詳細６６を依頼者４２に返却し、依頼者のブ
ラウザが詳細をＨＴＭＬ形式６４として表示する。そし
てこれは入力を要求する。要求される入力は、出張依頼
書５４の取引詳細６６の構成要素となる。第７のステッ
プ１９６では、依頼者４２がＨＴＭＬ表現６４を見て、
指定された詳細６６（例えば名前、行き先、費用など）
をブラウザを通じて完成し、完成されたＨＴＭＬ表現６
４に署名する。ユーザすなわち依頼者４２は、彼らの職
務すなわち"一般社員"を示す職務証明書７６に署名済み
である。
ＴＭＬ取引詳細６６を依頼者４２に返却し、依頼者のブ
ラウザが詳細をＨＴＭＬ形式６４として表示する。そし
てこれは入力を要求する。要求される入力は、出張依頼
書５４の取引詳細６６の構成要素となる。第７のステッ
プ１９６では、依頼者４２がＨＴＭＬ表現６４を見て、
指定された詳細６６（例えば名前、行き先、費用など）
をブラウザを通じて完成し、完成されたＨＴＭＬ表現６
４に署名する。ユーザすなわち依頼者４２は、彼らの職
務すなわち"一般社員"を示す職務証明書７６に署名済み
である。
【００５７】第８のステップ２００では、ＴＡＭ２が署
名済みの依頼者入力（すなわち署名済みのＨＴＭＬ表
現）をユーザ４２から受信し、次に認可構造データベー
ス９６と連絡し、出張依頼取引４０の認可構造９８を獲
得する。ＴＡＭ２はデータベース９６から認可構造９８
を受信し、構造上のＴＡ８０の署名１０６をチェックす
る。認可構造９８からＡＭ２は職務名１２２の承認セッ
ト１００、並びにこれらの職務名に署名するために接触
するユーザの収集を抽出する。この場合、一人の一般社
員の依頼者４２、課長及び部長しか存在しない。
名済みの依頼者入力（すなわち署名済みのＨＴＭＬ表
現）をユーザ４２から受信し、次に認可構造データベー
ス９６と連絡し、出張依頼取引４０の認可構造９８を獲
得する。ＴＡＭ２はデータベース９６から認可構造９８
を受信し、構造上のＴＡ８０の署名１０６をチェックす
る。認可構造９８からＡＭ２は職務名１２２の承認セッ
ト１００、並びにこれらの職務名に署名するために接触
するユーザの収集を抽出する。この場合、一人の一般社
員の依頼者４２、課長及び部長しか存在しない。
【００５８】この時点で、ＴＡＭ２の目的は、承認セッ
トを構成する連帯職務１２２の人達からの署名の収集を
獲得することである。依頼者４２は既に職務"一般社員"
としての署名１０６を提供しており、ＴＡＭ２は職務欄
の"課長"１６７及び"部長"１６９に、２つの署名を獲得
しなければならない。
トを構成する連帯職務１２２の人達からの署名の収集を
獲得することである。依頼者４２は既に職務"一般社員"
としての署名１０６を提供しており、ＴＡＭ２は職務欄
の"課長"１６７及び"部長"１６９に、２つの署名を獲得
しなければならない。
【００５９】ＴＡＭ２はユーザ及び彼らの職務１２２を
リストするユーザ・ディレクトリ・データベース２０２
をアクセスして、例えば一方の署名１０６として、ユー
ザ"John Brown"を職務"課長"として、また他の署名とし
て、ユーザ"Sue Smith"を職務"部長"として選択する。
リストするユーザ・ディレクトリ・データベース２０２
をアクセスして、例えば一方の署名１０６として、ユー
ザ"John Brown"を職務"課長"として、また他の署名とし
て、ユーザ"Sue Smith"を職務"部長"として選択する。
【００６０】第９のステップでは、ＴＡＭ２が取引依頼
詳細６６を一般社員依頼者４２の署名１０６と一緒に、
依頼者の課長John Brownに転送する。John Brownのブラ
ウザはＨＴＭＬ出張用紙６４を、依頼者の記入済みの取
引詳細６６と一緒に表示し、また依頼者４２により提供
される署名１０６が正しい旨を示す。John Brownは次に
出張依頼書５４を認可するか否かを決定する。認可が与
えられる場合、John Brownは出張依頼書５４のＨＴＭＬ
と、依頼者４２により提供された出張詳細６６とに署名
し、それらがＴＡＭ２に返却される。
詳細６６を一般社員依頼者４２の署名１０６と一緒に、
依頼者の課長John Brownに転送する。John Brownのブラ
ウザはＨＴＭＬ出張用紙６４を、依頼者の記入済みの取
引詳細６６と一緒に表示し、また依頼者４２により提供
される署名１０６が正しい旨を示す。John Brownは次に
出張依頼書５４を認可するか否かを決定する。認可が与
えられる場合、John Brownは出張依頼書５４のＨＴＭＬ
と、依頼者４２により提供された出張詳細６６とに署名
し、それらがＴＡＭ２に返却される。
【００６１】第１０のステップでは、ＴＡＭ２が取引依
頼書６４を署名１０６と共に、"部長"のSue Smithに転
送する。Sue Smithは出張依頼書５４の詳細６６及び依
頼書上の前の署名のセットを提供される（この場合、依
頼者４２による署名、及びJohn Brownの署名）。全てが
妥当な場合、Sue Smithは部長としての彼女の職務にお
いて受信した全ての情報に署名し、これをＴＡＭ２に返
信する。
頼書６４を署名１０６と共に、"部長"のSue Smithに転
送する。Sue Smithは出張依頼書５４の詳細６６及び依
頼書上の前の署名のセットを提供される（この場合、依
頼者４２による署名、及びJohn Brownの署名）。全てが
妥当な場合、Sue Smithは部長としての彼女の職務にお
いて受信した全ての情報に署名し、これをＴＡＭ２に返
信する。
【００６２】第１１のステップでは、ＴＡＭ２が承認セ
ット１００を構成することを意図する署名１０６のセッ
トを受信する。これが実際に真実であることをチェック
するために、ＴＡＭ２は依頼者４２、John Brown課長、
及びSue Smith部長の職務証明書７６を受信し、全ての
署名を確認する。第１２のステップでは、署名１０６が
有効と確認されると、ＴＡＭ２は署名及び職務証明書７
６を含む文書６４を依頼者４２に転送する。こうして、
取引４０の正当性を確認するために要求される全ての認
可詳細６６を含む、図１２に示されるデジタル文書１１
４が生成される。これで依頼者４２は出張依頼書上に、
この取引４０のクラスの承認セット１００を構成する署
名１０６のセットを保持することになる。この情報は、
依頼者４２が出張依頼書５４の申請を実際に認可された
ことに関して、検証者１３０として示される別のユーザ
を納得させるために使用される。
ット１００を構成することを意図する署名１０６のセッ
トを受信する。これが実際に真実であることをチェック
するために、ＴＡＭ２は依頼者４２、John Brown課長、
及びSue Smith部長の職務証明書７６を受信し、全ての
署名を確認する。第１２のステップでは、署名１０６が
有効と確認されると、ＴＡＭ２は署名及び職務証明書７
６を含む文書６４を依頼者４２に転送する。こうして、
取引４０の正当性を確認するために要求される全ての認
可詳細６６を含む、図１２に示されるデジタル文書１１
４が生成される。これで依頼者４２は出張依頼書上に、
この取引４０のクラスの承認セット１００を構成する署
名１０６のセットを保持することになる。この情報は、
依頼者４２が出張依頼書５４の申請を実際に認可された
ことに関して、検証者１３０として示される別のユーザ
を納得させるために使用される。
【００６３】図１２を参照すると、完成された取引４０
が示され、取引詳細６６及び依頼者４２により保持され
る署名１０６を有する。詳細には、１）ＴＡ８０により
署名された取引詳細のＨＴＭＬ、及び２）ユーザにより
提供される入力を含み、これらの両者は依頼者４２によ
り署名され、更に３）この情報が課長により多重署名さ
れ、全てが部長により多重署名される。
が示され、取引詳細６６及び依頼者４２により保持され
る署名１０６を有する。詳細には、１）ＴＡ８０により
署名された取引詳細のＨＴＭＬ、及び２）ユーザにより
提供される入力を含み、これらの両者は依頼者４２によ
り署名され、更に３）この情報が課長により多重署名さ
れ、全てが部長により多重署名される。
【００６４】図１３を参照すると、依頼者４２により保
持される職務証明書７６及び認可構造９８が示される。
持される職務証明書７６及び認可構造９８が示される。
【００６５】次に図１４を参照して、取引処理として、
依頼者４２が出張依頼書５４を検証者１３０に転送する
ことに関連するステップについて述べる。この方法は確
認補助方法１１６と呼ばれる。
依頼者４２が出張依頼書５４を検証者１３０に転送する
ことに関連するステップについて述べる。この方法は確
認補助方法１１６と呼ばれる。
【００６６】この確認方法をより理解するために、認可
構造９８が如何に構築されるかについての詳細を理解す
ることが重要である。確認補助方法１１６は暗号ハッシ
ュ関数を使用し、これが任意のストリングを、例えば１
６バイトまたは２０バイトの固定長出力にマップする。
出張依頼書５４の場合、認可構造９８は承認セットを構
成する３つの職務１２２にハッシュする（従って、会社
の実際の認可構造にハッシュする）ことにより構築され
る。すなわち、それらはＨ１＝ハッシュ（一般社員）、
Ｈ２＝ハッシュ（課長）、及びＨ３＝ハッシュ（部長）
である。
構造９８が如何に構築されるかについての詳細を理解す
ることが重要である。確認補助方法１１６は暗号ハッシ
ュ関数を使用し、これが任意のストリングを、例えば１
６バイトまたは２０バイトの固定長出力にマップする。
出張依頼書５４の場合、認可構造９８は承認セットを構
成する３つの職務１２２にハッシュする（従って、会社
の実際の認可構造にハッシュする）ことにより構築され
る。すなわち、それらはＨ１＝ハッシュ（一般社員）、
Ｈ２＝ハッシュ（課長）、及びＨ３＝ハッシュ（部長）
である。
【００６７】例えば、Ｈ１はストリング"一般社員"のハ
ッシュであると言われる。最後に、Ｈ１、Ｈ２及びＨ３
はストリングとして処理され、連結されて、次にＴ＝ｈ
ａｓｈ（Ｈ１、Ｈ２、Ｈ３）としてハッシュされる。言
い回しは"取引当局８０（ＴＡ）が認可構造９８に署名
する"となり、これは取引当局が取引Ｔ４０の値に署名
することを意味する。従って、ＴＡ８０は"ハッシュの
ハッシュ"（hash of hashes）に署名することになる。
ッシュであると言われる。最後に、Ｈ１、Ｈ２及びＨ３
はストリングとして処理され、連結されて、次にＴ＝ｈ
ａｓｈ（Ｈ１、Ｈ２、Ｈ３）としてハッシュされる。言
い回しは"取引当局８０（ＴＡ）が認可構造９８に署名
する"となり、これは取引当局が取引Ｔ４０の値に署名
することを意味する。従って、ＴＡ８０は"ハッシュの
ハッシュ"（hash of hashes）に署名することになる。
【００６８】全てのユーザは、ＴＡ８０により署名され
る認可構造が、最初に職務１２２の収集をハッシュし、
次にこれらの値をもう一度ハッシュすることにより導出
されることを知る点で、認可構造９８（ＡＳ）に署名す
るこの一般的な方法を承知している。
る認可構造が、最初に職務１２２の収集をハッシュし、
次にこれらの値をもう一度ハッシュすることにより導出
されることを知る点で、認可構造９８（ＡＳ）に署名す
るこの一般的な方法を承知している。
【００６９】出張依頼例を特に参照すると、依頼者４２
は１）ＴＡ８０により署名されるＨＴＭＬ形式の出張依
頼書５４と、２）職務が"一般社員"、"課長"及び"部長"
の３人のユーザに対応する３つの職務証明書７６と、
３）図１２に示されるように、最初に一般社員により、
次に課長、次に部長により署名される取引詳細６６と、
４）図１５に示されるようなハッシュ結果の職務１２２
上の署名を送信する。
は１）ＴＡ８０により署名されるＨＴＭＬ形式の出張依
頼書５４と、２）職務が"一般社員"、"課長"及び"部長"
の３人のユーザに対応する３つの職務証明書７６と、
３）図１２に示されるように、最初に一般社員により、
次に課長、次に部長により署名される取引詳細６６と、
４）図１５に示されるようなハッシュ結果の職務１２２
上の署名を送信する。
【００７０】図５を再度参照すると、ＴＡＭ２は検証者
１３０が作成された署名済み文書１１４を確認すること
を可能にする確認補助方法１１６を含む。検証者は基本
的に、依頼者４２が取引４０、この場合、出張依頼書５
４を認可されるか否かの確認に関心がある。依頼者４２
は検証者１３０に、取引ＨＴＭＬ（ＴＡ８０により署名
済み）、職務証明書７６の収集、職務証明書内の確認キ
ー１２０に対応する各署名キー１５０により署名された
取引詳細、及び認可構造９８を送信する。図１０から、
各職務証明書１２２は職務当局１８０（ＲＡ）により署
名されることが思い起こされる。第１のステップ１３２
では、検証者１３０は職務当局１８０の確認キー１２０
を用いて、文書１１４上の各職務証明書７６をチェック
する。第２のステップ１３４では、検証者１３０が提供
された職務証明書７６内の確認キー１２０を用いて取引
詳細６６上の署名１０６をチェックする。第２のステッ
プ１３４のサブステップ１３６では、依頼者４２が認可
されるか否かをチェックするために、検証者１３０は職
務証明書７６から指定職務１２２を抽出する。第２のス
テップ１３４の第２のサブステップ１４０では、職務名
が前述のハッシュのハッシュ・プロセスを用いてハッシ
ュされる。第２のステップ１３４の第３のサブステップ
１４２では、取引４０の計算されたハッシュ値が取引当
局８０により当初署名された値に対してチェックされ、
それが認可構造９８内で受信された取引４０の値と等し
いことを保証する。次に、ハッシュのハッシュ・プロセ
スの出力が、ハッシュのハッシュ・プロセス上の署名１
０６をチェックする入力として使用される。第２のステ
ップ１３４の第４のサブステップ１４４では、生成され
たハッシュのハッシュ・ストリングがＴＡ８０により署
名されたハッシュド・ストリングに合致する場合、検証
者１３０は依頼書５２が認可されるものと想定する。合
致する場合、取引４０は確認されたことになり、この事
実の通知が依頼者４２に送信される。
１３０が作成された署名済み文書１１４を確認すること
を可能にする確認補助方法１１６を含む。検証者は基本
的に、依頼者４２が取引４０、この場合、出張依頼書５
４を認可されるか否かの確認に関心がある。依頼者４２
は検証者１３０に、取引ＨＴＭＬ（ＴＡ８０により署名
済み）、職務証明書７６の収集、職務証明書内の確認キ
ー１２０に対応する各署名キー１５０により署名された
取引詳細、及び認可構造９８を送信する。図１０から、
各職務証明書１２２は職務当局１８０（ＲＡ）により署
名されることが思い起こされる。第１のステップ１３２
では、検証者１３０は職務当局１８０の確認キー１２０
を用いて、文書１１４上の各職務証明書７６をチェック
する。第２のステップ１３４では、検証者１３０が提供
された職務証明書７６内の確認キー１２０を用いて取引
詳細６６上の署名１０６をチェックする。第２のステッ
プ１３４のサブステップ１３６では、依頼者４２が認可
されるか否かをチェックするために、検証者１３０は職
務証明書７６から指定職務１２２を抽出する。第２のス
テップ１３４の第２のサブステップ１４０では、職務名
が前述のハッシュのハッシュ・プロセスを用いてハッシ
ュされる。第２のステップ１３４の第３のサブステップ
１４２では、取引４０の計算されたハッシュ値が取引当
局８０により当初署名された値に対してチェックされ、
それが認可構造９８内で受信された取引４０の値と等し
いことを保証する。次に、ハッシュのハッシュ・プロセ
スの出力が、ハッシュのハッシュ・プロセス上の署名１
０６をチェックする入力として使用される。第２のステ
ップ１３４の第４のサブステップ１４４では、生成され
たハッシュのハッシュ・ストリングがＴＡ８０により署
名されたハッシュド・ストリングに合致する場合、検証
者１３０は依頼書５２が認可されるものと想定する。合
致する場合、取引４０は確認されたことになり、この事
実の通知が依頼者４２に送信される。
【００７１】前述の補助方法１１６において、ＴＡＭ２
は依頼者４２からの情報を検証者１３０に転送する。任
意的に、依頼者４２から検証者１３０への転送は、電子
メールにより行われてもよい。依頼者４２は局所的にＴ
ＡＭ２を使用し、全ての認可詳細６６を収集し、この全
ての情報を電子メールを介して検証者１３０に送信す
る。例えば、全ての署名１０６及び費用が収集され、次
に依頼書５２が旅行業者に電子メールにより転送され
る。続いて旅行業者が予約を行う。
は依頼者４２からの情報を検証者１３０に転送する。任
意的に、依頼者４２から検証者１３０への転送は、電子
メールにより行われてもよい。依頼者４２は局所的にＴ
ＡＭ２を使用し、全ての認可詳細６６を収集し、この全
ての情報を電子メールを介して検証者１３０に送信す
る。例えば、全ての署名１０６及び費用が収集され、次
に依頼書５２が旅行業者に電子メールにより転送され
る。続いて旅行業者が予約を行う。
【００７２】これまで、依頼者４２及び検証者１３０は
同一会社に所属すると仮定してこなかった。これは必要
ではない。なぜなら、本方法２は検証者１３０が同一会
社に所属するか否かに関わらず機能するからである。彼
らが同一会社に所属する場合、彼らはイントラネット２
５により接続されて、同一のサーバ５４ａを共有するか
もしれない。検証者１３０の位置はそれ自身、重要でな
い。検証者１３０の職務１２２は、依頼者４２により提
供される情報を確認することである。
同一会社に所属すると仮定してこなかった。これは必要
ではない。なぜなら、本方法２は検証者１３０が同一会
社に所属するか否かに関わらず機能するからである。彼
らが同一会社に所属する場合、彼らはイントラネット２
５により接続されて、同一のサーバ５４ａを共有するか
もしれない。検証者１３０の位置はそれ自身、重要でな
い。検証者１３０の職務１２２は、依頼者４２により提
供される情報を確認することである。
【００７３】取引４０の正当性を確認するために、検証
者１３０は以下のことを必要とする。 １）取引４０において使用される職務証明書７６上の署
名１０６の正当性をチェックするために使用される、職
務当局１８０の署名確認キー１２０。 ２）認可構造９８上の署名１０６の正当性をチェックす
るための、取引当局８０の署名確認キー１２０（ハッシ
ュのハッシュ・プロセス）。 ３）認可構造９８上の取引当局８０の署名がチェック可
能なように、指定職務１２２を収集し、ハッシュのハッ
シュ・プロセスを実行する方法の知識。
者１３０は以下のことを必要とする。 １）取引４０において使用される職務証明書７６上の署
名１０６の正当性をチェックするために使用される、職
務当局１８０の署名確認キー１２０。 ２）認可構造９８上の署名１０６の正当性をチェックす
るための、取引当局８０の署名確認キー１２０（ハッシ
ュのハッシュ・プロセス）。 ３）認可構造９８上の取引当局８０の署名がチェック可
能なように、指定職務１２２を収集し、ハッシュのハッ
シュ・プロセスを実行する方法の知識。
【００７４】職務当局１８０及び取引当局８０の署名確
認キー１２０は、それらが秘密にされる必要がない点で
公開情報である。従って、それらは全ての者により使用
可能で、確認可能と見なされる。ハッシュのハッシュ・
プロセスは、全ての潜在的な検証者１３０により本方法
２を用いて理解される必要がある。
認キー１２０は、それらが秘密にされる必要がない点で
公開情報である。従って、それらは全ての者により使用
可能で、確認可能と見なされる。ハッシュのハッシュ・
プロセスは、全ての潜在的な検証者１３０により本方法
２を用いて理解される必要がある。
【００７５】ハッシュのハッシュ・プロセスは前述の出
張依頼書５４の例では、極めて単純である。なぜなら、
１つの承認セット１００しか存在しないからである。し
かしながら、基本方法２は次のように、幾つかの承認セ
ット１００を含むように拡張され得る。例えば、出張依
頼５４はＣＥＯ及びＣＥＯ秘書により認可され、この場
合、出張依頼書の２つの承認セット（Ｐ１及びＰ２）
は、Ｐ１＝｛一般社員、課長、部長｝及びＰ２＝｛ＣＥ
Ｏ、ＣＥＯ秘書｝となる。
張依頼書５４の例では、極めて単純である。なぜなら、
１つの承認セット１００しか存在しないからである。し
かしながら、基本方法２は次のように、幾つかの承認セ
ット１００を含むように拡張され得る。例えば、出張依
頼５４はＣＥＯ及びＣＥＯ秘書により認可され、この場
合、出張依頼書の２つの承認セット（Ｐ１及びＰ２）
は、Ｐ１＝｛一般社員、課長、部長｝及びＰ２＝｛ＣＥ
Ｏ、ＣＥＯ秘書｝となる。
【００７６】承認セット１００及びそれらを構成する職
務１２２は、図９に示されるような認可ツリー１５４
（ＡＴ）に構成される。認可ツリー１５４は認可構造の
１例である。取引当局８０が認可構造９８に署名するた
めに、ＡＴは最初にストリングに変換されなければなら
ず、これは前述と類似のハッシュのハッシュ・プロセス
を用いて行われる。
務１２２は、図９に示されるような認可ツリー１５４
（ＡＴ）に構成される。認可ツリー１５４は認可構造の
１例である。取引当局８０が認可構造９８に署名するた
めに、ＡＴは最初にストリングに変換されなければなら
ず、これは前述と類似のハッシュのハッシュ・プロセス
を用いて行われる。
【００７７】最初に、各職務名１２２はＨ１、Ｈ２、Ｈ
３、Ｈ４、Ｈ５を次のように与えるようにハッシュされ
る。 Ｈ１＝hash（一般社員） Ｈ２＝hash（課長） Ｈ３＝hash（部長） Ｈ４＝hash（ＣＥＯ） Ｈ５＝hash（ＣＥＯ秘書） これらの値は、各承認セットの１つのハッシュを獲得す
るために、次のようにハッシュされなければならない。
すなわち、Ｈ６＝hash（Ｈ１、Ｈ２、Ｈ３）、Ｈ７＝ha
sh（Ｈ４、Ｈ５）である。ここでＨ６は承認セットＰ１
のハッシュであり、Ｈ７は承認セットＰ２のハッシュ
（Ｐ２'）である。従って、各承認セット１００に対し
て１つのハッシュが存在することになり、これらは承認
セット・ハッシュと呼ばれる。ここでhash（Ｈ１、Ｈ
２、Ｈ３）は、Ｈ１、Ｈ２及びＨ３が連結され、続いて
ハッシュされるストリングであることを意味する。最後
に、認可ツリーのハッシュはＴ＝hash（Ｈ６、Ｈ７）と
して生成される。
３、Ｈ４、Ｈ５を次のように与えるようにハッシュされ
る。 Ｈ１＝hash（一般社員） Ｈ２＝hash（課長） Ｈ３＝hash（部長） Ｈ４＝hash（ＣＥＯ） Ｈ５＝hash（ＣＥＯ秘書） これらの値は、各承認セットの１つのハッシュを獲得す
るために、次のようにハッシュされなければならない。
すなわち、Ｈ６＝hash（Ｈ１、Ｈ２、Ｈ３）、Ｈ７＝ha
sh（Ｈ４、Ｈ５）である。ここでＨ６は承認セットＰ１
のハッシュであり、Ｈ７は承認セットＰ２のハッシュ
（Ｐ２'）である。従って、各承認セット１００に対し
て１つのハッシュが存在することになり、これらは承認
セット・ハッシュと呼ばれる。ここでhash（Ｈ１、Ｈ
２、Ｈ３）は、Ｈ１、Ｈ２及びＨ３が連結され、続いて
ハッシュされるストリングであることを意味する。最後
に、認可ツリーのハッシュはＴ＝hash（Ｈ６、Ｈ７）と
して生成される。
【００７８】このハッシング・プロセスは図１５に示さ
れる。取引当局８０により署名されるのは取引４０の値
である。
れる。取引当局８０により署名されるのは取引４０の値
である。
【００７９】検証者１３０は取引４０上の署名を用い
て、前述の１つの承認セット１００を有する例の場合と
同様に、依頼者４２が所与の取引４０（この場合出張依
頼書５４）に関して認可されることをチェックする。
て、前述の１つの承認セット１００を有する例の場合と
同様に、依頼者４２が所与の取引４０（この場合出張依
頼書５４）に関して認可されることをチェックする。
【００８０】取引４０上の署名１０６を確認するため
に、検証者１３０は、図９及び図１５に関連して前述し
たツリー・ハッシング・プロセスの全部または一部を繰
り返す。ここで図１５では、ハッシュされた参照項目
が、未ハッシュの参照番号に続くプライム符号により、
図９のそれと区別される。依頼者４２が承認セットＰ１
を構成する職務の人達からの署名１０６を獲得したと仮
定する。この場合、依頼者４２は検証者１３０に３つの
職務証明書７６を送信しており、そこから検証者は職務
名"一般社員"、"課長"及び"部長"を抽出できる。検証者
１３０は次に前述のように、Ｈ１、Ｈ２、Ｈ３及びＨ６
を形成することができる。こうして、検証者１３０は、
取引４０を認可した承認セット１００の承認セット・ハ
ッシュを形成することができる。
に、検証者１３０は、図９及び図１５に関連して前述し
たツリー・ハッシング・プロセスの全部または一部を繰
り返す。ここで図１５では、ハッシュされた参照項目
が、未ハッシュの参照番号に続くプライム符号により、
図９のそれと区別される。依頼者４２が承認セットＰ１
を構成する職務の人達からの署名１０６を獲得したと仮
定する。この場合、依頼者４２は検証者１３０に３つの
職務証明書７６を送信しており、そこから検証者は職務
名"一般社員"、"課長"及び"部長"を抽出できる。検証者
１３０は次に前述のように、Ｈ１、Ｈ２、Ｈ３及びＨ６
を形成することができる。こうして、検証者１３０は、
取引４０を認可した承認セット１００の承認セット・ハ
ッシュを形成することができる。
【００８１】認可ツリー１５４上の署名確認を完了する
ために、依頼者４２は取引４０を認可する承認セットに
加えて、全ての他の承認セット１００の承認セット・ハ
ッシュを検証者１３０に提供する必要がある。前述の例
では、Ｐ１は取引４０を認可しているのでＰ２のハッシ
ュが提供されなければならず、これはこの場合、前述の
ようにＨ７に等しい。
ために、依頼者４２は取引４０を認可する承認セットに
加えて、全ての他の承認セット１００の承認セット・ハ
ッシュを検証者１３０に提供する必要がある。前述の例
では、Ｐ１は取引４０を認可しているのでＰ２のハッシ
ュが提供されなければならず、これはこの場合、前述の
ようにＨ７に等しい。
【００８２】Ｈ７が与えられると、検証者１３０はＴを
形成できる。なぜなら、検証者はＨ６を形成することが
でき、Ｔ上の署名１０６がチェックされ得るからであ
る。従って、認可ツリー１５４上の署名１０６をチェッ
クする目的のために、依頼者４２は検証者１３０に職務
証明書７６を送信し、そこから職務１２２が抽出され、
ハッシュされて、取引を認可する承認セット１００のハ
ッシュ、並びに取引を認可していない各承認セットのハ
ッシュが形成される。これらの２つの情報により、検証
者１３０は取引４０のハッシュ値を計算し、次に署名１
０６をチェックする。
形成できる。なぜなら、検証者はＨ６を形成することが
でき、Ｔ上の署名１０６がチェックされ得るからであ
る。従って、認可ツリー１５４上の署名１０６をチェッ
クする目的のために、依頼者４２は検証者１３０に職務
証明書７６を送信し、そこから職務１２２が抽出され、
ハッシュされて、取引を認可する承認セット１００のハ
ッシュ、並びに取引を認可していない各承認セットのハ
ッシュが形成される。これらの２つの情報により、検証
者１３０は取引４０のハッシュ値を計算し、次に署名１
０６をチェックする。
【００８３】前述の出張依頼書では、ＴＡＭ２がワール
ド・ワイド・ウェブを通じて接触され、従ってＴＡＭは
ウェブ・サーバ・プロセスと見なされる。本方法のワー
クフロー・システムでは、ユーザは好適には専用のネッ
トワーク・チャネルを通じてＴＡＭと接触する。両方の
実施例は本質的に同じである。すなわち、ＴＡＭ２はユ
ーザによりアクセスされ得るコンピュータ・システム２
０上のどこかに存在する。またＴＡＭはまた、データベ
ース７０、８２、４６及び２０２、及び他のユーザをア
クセスできる。従来理解されているように、これは例え
ば電子メールにより、またはウェブへのイントラネット
またはインターネット接続を介して達成され得る。
ド・ワイド・ウェブを通じて接触され、従ってＴＡＭは
ウェブ・サーバ・プロセスと見なされる。本方法のワー
クフロー・システムでは、ユーザは好適には専用のネッ
トワーク・チャネルを通じてＴＡＭと接触する。両方の
実施例は本質的に同じである。すなわち、ＴＡＭ２はユ
ーザによりアクセスされ得るコンピュータ・システム２
０上のどこかに存在する。またＴＡＭはまた、データベ
ース７０、８２、４６及び２０２、及び他のユーザをア
クセスできる。従来理解されているように、これは例え
ば電子メールにより、またはウェブへのイントラネット
またはインターネット接続を介して達成され得る。
【００８４】ＴＡ８０は、ＴＡにより生成される署名１
０６が信頼される点で、依頼者４２及び検証者１３０に
より信頼される。この意味において、ＴＡ８０は取引４
０のＨＴＭＬ表現６４を適切に形成し、それに署名する
ために、また取引の認可構造９８を形成し、それに署名
するために信頼される。しかしながら、広義には、ＴＡ
Ｍ２は信頼される必要はない。ユーザはＴＡＭ２を信頼
して、自分たちのためにあるセキュリティ機能を実行す
るが、ユーザは代わりにローカル・プロセスを使用し
て、ＴＡＭにより実行される全ての作業が適切であるこ
とを確認してもよい。
０６が信頼される点で、依頼者４２及び検証者１３０に
より信頼される。この意味において、ＴＡ８０は取引４
０のＨＴＭＬ表現６４を適切に形成し、それに署名する
ために、また取引の認可構造９８を形成し、それに署名
するために信頼される。しかしながら、広義には、ＴＡ
Ｍ２は信頼される必要はない。ユーザはＴＡＭ２を信頼
して、自分たちのためにあるセキュリティ機能を実行す
るが、ユーザは代わりにローカル・プロセスを使用し
て、ＴＡＭにより実行される全ての作業が適切であるこ
とを確認してもよい。
【００８５】ウェブの実施例では、ＴＡＭ２はインター
ネット３１上の検証者１３０及び依頼者４２の両者によ
りアクセス可能な独立のサーバ５４ｂである点で、中立
である（すなわち、全てにより信頼される）。特に、本
当に信頼が置ける構成要素は、（デジタル取引及び認可
構造を生成する）取引当局８０と、（前述の職務の人達
に職務証明書７６を割当てる）職務当局１８０である。
従って、検証者１３０は、取引当局８０によりＨＴＭＬ
表現６４及び認可構造９８上に生成された署名１０６、
及び職務証明書７６上の署名のための職務当局１８０を
信頼するだけでよい。
ネット３１上の検証者１３０及び依頼者４２の両者によ
りアクセス可能な独立のサーバ５４ｂである点で、中立
である（すなわち、全てにより信頼される）。特に、本
当に信頼が置ける構成要素は、（デジタル取引及び認可
構造を生成する）取引当局８０と、（前述の職務の人達
に職務証明書７６を割当てる）職務当局１８０である。
従って、検証者１３０は、取引当局８０によりＨＴＭＬ
表現６４及び認可構造９８上に生成された署名１０６、
及び職務証明書７６上の署名のための職務当局１８０を
信頼するだけでよい。
【００８６】前述の出張依頼５４では、ＴＡＭ２は依頼
者４２のために確実な役割を演じる。なぜなら、ＴＡＭ
は情報をフェッチし、署名１０６をチェックするからで
ある。しかしながら、全ての情報が例えばサーバ５４ｂ
上に存在する公衆データベース（デジタル文書データベ
ース７０、認可構造データベース９６、及び職務証明書
データベース８２）内にあることが明らかである。依頼
者４２はデジタル文書データベース７０をアクセスし、
出張依頼ＨＴＭＬ文書６４を直接獲得し、それ上のＴＡ
８０の署名１０６をチェックできる（ＴＡ８０の確認キ
ー１２０は誰でも使用可能である）。依頼者４２は次に
署名１０６に必要なユーザと接触して、承認セット１０
０を形成し、職務証明書データベース８２などをアクセ
スすることにより署名をチェックする。
者４２のために確実な役割を演じる。なぜなら、ＴＡＭ
は情報をフェッチし、署名１０６をチェックするからで
ある。しかしながら、全ての情報が例えばサーバ５４ｂ
上に存在する公衆データベース（デジタル文書データベ
ース７０、認可構造データベース９６、及び職務証明書
データベース８２）内にあることが明らかである。依頼
者４２はデジタル文書データベース７０をアクセスし、
出張依頼ＨＴＭＬ文書６４を直接獲得し、それ上のＴＡ
８０の署名１０６をチェックできる（ＴＡ８０の確認キ
ー１２０は誰でも使用可能である）。依頼者４２は次に
署名１０６に必要なユーザと接触して、承認セット１０
０を形成し、職務証明書データベース８２などをアクセ
スすることにより署名をチェックする。
【００８７】ＴＡＭ２がデータベースのフェッチ及び署
名の収集を実行するとき、これは本方法が実際に如何に
機能するかということを除き、単に依頼者４２にとって
の利便性である。信頼ではなく、利便性が決定的な条件
の場合には、ＴＡＭ２は全ての当事者により信頼される
必要はない。
名の収集を実行するとき、これは本方法が実際に如何に
機能するかということを除き、単に依頼者４２にとって
の利便性である。信頼ではなく、利便性が決定的な条件
の場合には、ＴＡＭ２は全ての当事者により信頼される
必要はない。
【００８８】前述のように、企業内認可及び企業間認可
の主な違いは、前者の場合には、会社がその認可構造９
８を検証者１３０に明かすことにあまり関わらない。企
業間認可の状況では、認可構造が所与の業務に対する認
可ツリー１５４であり、全ての認可ツリーの収集を含む
データベースへのアクセスが、社外のユーザには制限さ
れるべきである。
の主な違いは、前者の場合には、会社がその認可構造９
８を検証者１３０に明かすことにあまり関わらない。企
業間認可の状況では、認可構造が所与の業務に対する認
可ツリー１５４であり、全ての認可ツリーの収集を含む
データベースへのアクセスが、社外のユーザには制限さ
れるべきである。
【００８９】前述の方法２を企業間認可の状況に適応化
するための幾つかの方法が存在する。ユーザＵＡ及びユ
ーザＵＢによりそれぞれ表される、会社Ａと会社Ｂとの
間の取引４０の最初の例に戻ると、最も直接的なアプロ
ーチは、各会社が企業当局（ＥＡ：enterprise authori
ty）を有し、署名１０６を確認するために使用される公
開キーが、企業当局により会社のために生成される。企
業当局は会社内で発生する全ての取引の検証者であるこ
とにより、全ての企業間取引を認可する。取引が認可さ
れると、企業当局はこの趣旨で記述書に署名し、これが
別の会社のユーザにより確認され得る。
するための幾つかの方法が存在する。ユーザＵＡ及びユ
ーザＵＢによりそれぞれ表される、会社Ａと会社Ｂとの
間の取引４０の最初の例に戻ると、最も直接的なアプロ
ーチは、各会社が企業当局（ＥＡ：enterprise authori
ty）を有し、署名１０６を確認するために使用される公
開キーが、企業当局により会社のために生成される。企
業当局は会社内で発生する全ての取引の検証者であるこ
とにより、全ての企業間取引を認可する。取引が認可さ
れると、企業当局はこの趣旨で記述書に署名し、これが
別の会社のユーザにより確認され得る。
【００９０】更に、ＴＡＭ２は好適には分散ワークフロ
ー管理システム６内で動作するが、本方法は単にメッセ
ージ交換機構から構成されてもよい。この実施例では、
メッセージ交換機構は、従来のワークフロー管理システ
ム６として動作せずに、代わりに、依頼者４２と社内の
特定の職務を有する人間との間で、添付物を有する電子
メールまたはＨＴＭＬ電子メールなどの、電子メッセー
ジ・フローを管理する。こうした機構の管理は、ＰＣ常
駐型の職務ベースのプログラム（すなわち、ユーザ８の
特定の職務に適するようにカストマイズされたプログラ
ム）のような単純なものを通じて、ファイル・サーバ・
タイプのデータベース（図１１に示されるデータベース
７０、９６、８２及び２０２に類似）、及びデータベー
スのリレーショナル構造に従うように編成されるプルダ
ウン・メニュー及びサブメニューを用いて実現される。
典型的なメニュー項目は、例えば"取引タイプ"であり、
これが異なるタイプの取引（例えば"出張依頼書"など）
をリストするサブメニューをオープンする。特定の取引
４０を活動化すると、こうした取引に要求される承認セ
ット１００を示す別のサブメニューをオープンする。承
認セット１００を活動化すると、次に添付物として取引
詳細６６を有する電子メールをオープンする。電子メー
ルは承認セット１００内の人達に事前にアドレス指定さ
れ、署名の配布及び確認を容易にする。
ー管理システム６内で動作するが、本方法は単にメッセ
ージ交換機構から構成されてもよい。この実施例では、
メッセージ交換機構は、従来のワークフロー管理システ
ム６として動作せずに、代わりに、依頼者４２と社内の
特定の職務を有する人間との間で、添付物を有する電子
メールまたはＨＴＭＬ電子メールなどの、電子メッセー
ジ・フローを管理する。こうした機構の管理は、ＰＣ常
駐型の職務ベースのプログラム（すなわち、ユーザ８の
特定の職務に適するようにカストマイズされたプログラ
ム）のような単純なものを通じて、ファイル・サーバ・
タイプのデータベース（図１１に示されるデータベース
７０、９６、８２及び２０２に類似）、及びデータベー
スのリレーショナル構造に従うように編成されるプルダ
ウン・メニュー及びサブメニューを用いて実現される。
典型的なメニュー項目は、例えば"取引タイプ"であり、
これが異なるタイプの取引（例えば"出張依頼書"など）
をリストするサブメニューをオープンする。特定の取引
４０を活動化すると、こうした取引に要求される承認セ
ット１００を示す別のサブメニューをオープンする。承
認セット１００を活動化すると、次に添付物として取引
詳細６６を有する電子メールをオープンする。電子メー
ルは承認セット１００内の人達に事前にアドレス指定さ
れ、署名の配布及び確認を容易にする。
【００９１】図１５に示される認可ツリー１５４のハッ
シュを用いる実施例では、職務ＵＲのユーザが取引４０
を要求できる以外に、検証者１３０がユーザの会社の決
定構造に関する少量の情報だけを習得する利点を有す
る。他方、あらゆる企業間要求が確認及び署名のために
企業当局（ＥＡ）に渡されるために、ＥＡサーバが潜在
的なボトルネックとなる。別の解決策は、他の会社によ
る確認の目的で、公衆インターネット３１上において認
可ツリー１５４を会社の外部から使用可能にすることで
ある。もちろん、主な問題は、認可ツリー１５４を直接
明かすことにより、会社内の決定プロセスに関する多く
の情報が明かされることである。次のセクションでは、
企業間認可のために好適な、本方法２の幾つかの変更に
ついて述べる。
シュを用いる実施例では、職務ＵＲのユーザが取引４０
を要求できる以外に、検証者１３０がユーザの会社の決
定構造に関する少量の情報だけを習得する利点を有す
る。他方、あらゆる企業間要求が確認及び署名のために
企業当局（ＥＡ）に渡されるために、ＥＡサーバが潜在
的なボトルネックとなる。別の解決策は、他の会社によ
る確認の目的で、公衆インターネット３１上において認
可ツリー１５４を会社の外部から使用可能にすることで
ある。もちろん、主な問題は、認可ツリー１５４を直接
明かすことにより、会社内の決定プロセスに関する多く
の情報が明かされることである。次のセクションでは、
企業間認可のために好適な、本方法２の幾つかの変更に
ついて述べる。
【００９２】例えば、企業当局からあらゆる取引４０の
直接承認を得なければならない代わりに（すなわち、取
引管理者８０が、下級社員が取引を認可する権限を有す
ることを確認する）、企業当局は認可構造９８を承認す
るだけでよい。この場合、認可の確認は常に企業当局に
渡るわけではなく、認可は認可構造９８の要件を満たす
だけでよい。
直接承認を得なければならない代わりに（すなわち、取
引管理者８０が、下級社員が取引を認可する権限を有す
ることを確認する）、企業当局は認可構造９８を承認す
るだけでよい。この場合、認可の確認は常に企業当局に
渡るわけではなく、認可は認可構造９８の要件を満たす
だけでよい。
【００９３】別の利点として、一旦ＴＡ８０が取引及び
認可構造９８を生成し、ＲＡ１８０が職務証明書７６を
作成すると、本方法２を用いて作成された契約が容易且
つ自動的に確認される点で、システム２０は非常に確実
となる。
認可構造９８を生成し、ＲＡ１８０が職務証明書７６を
作成すると、本方法２を用いて作成された契約が容易且
つ自動的に確認される点で、システム２０は非常に確実
となる。
【００９４】以上、本方法２は１つの職務の承認セット
１００により機能することが理解された。しかしなが
ら、２つ以上の職務１２２が承認セット１００内で指定
される場合、認可結果の信頼性が向上する利点がある。
更に、本方法２の低レベルの資源集中型実施例が、幾つ
かの職務１２２から成る承認セット１００内の１つ、例
えば最初にリストされる職務証明書７６の抽出及び確認
により得られる。上級社員の職務証明書７６を最初にリ
ストされるように、承認セット１００の構造を定義する
ことによりこの実施例の信頼性が向上する。それにも関
わらず、こうした実施例は、承認セット１００自身の職
務内容と併せて、全ての職務証明書７６を抽出及び確認
する実施例（すなわち、取引４０上の職務証明書７６
が、取引を認可するために要求される特定の職務１２２
に実際に対応する）と比較して、本質的に信頼性に劣
る。
１００により機能することが理解された。しかしなが
ら、２つ以上の職務１２２が承認セット１００内で指定
される場合、認可結果の信頼性が向上する利点がある。
更に、本方法２の低レベルの資源集中型実施例が、幾つ
かの職務１２２から成る承認セット１００内の１つ、例
えば最初にリストされる職務証明書７６の抽出及び確認
により得られる。上級社員の職務証明書７６を最初にリ
ストされるように、承認セット１００の構造を定義する
ことによりこの実施例の信頼性が向上する。それにも関
わらず、こうした実施例は、承認セット１００自身の職
務内容と併せて、全ての職務証明書７６を抽出及び確認
する実施例（すなわち、取引４０上の職務証明書７６
が、取引を認可するために要求される特定の職務１２２
に実際に対応する）と比較して、本質的に信頼性に劣
る。
【００９５】ここで述べた本発明の実施例において、複
数の変形及び変更が可能である。本発明の特定の実施例
について述べてきたが、前述の開示において、広範囲の
変更及び代替実施例が可能である。ある場合には、本発
明の幾つかの機構は、他の機構の対応する使用無しに使
用され得る。従って、前述の説明は１例の説明として提
供されただけであり、広く解釈されるべきであり、本発
明の趣旨及び範囲内において、様々な変更が可能であ
る。
数の変形及び変更が可能である。本発明の特定の実施例
について述べてきたが、前述の開示において、広範囲の
変更及び代替実施例が可能である。ある場合には、本発
明の幾つかの機構は、他の機構の対応する使用無しに使
用され得る。従って、前述の説明は１例の説明として提
供されただけであり、広く解釈されるべきであり、本発
明の趣旨及び範囲内において、様々な変更が可能であ
る。
【００９６】まとめとして、本発明の構成に関して以下
の事項を開示する。
の事項を開示する。
【００９７】（１）複数の相互接続されるコンピュータ
及び複数の資源を含むコンピュータ・ネットワーク上で
動作するプロセス・フローを有するコンピュータによる
方法であって、各コンピュータがプロセッサ、メモリ及
び入出力装置を含み、各資源が少なくとも１つのコンピ
ュータに動作上接続されて、プロセス・フローにおいて
少なくとも１つの活動を実行するものにおいて、認可に
関連付けられる職務証明を抽出し、職務証明そのものが
信頼できるか否かを確認することにより、取引の電子認
可を検証可能に編成する方法。 （２）職務証明に関連付けられる職務がハッシュされ、
ハッシュ化職務のデータベース内のハッシュ化職務と比
較される、前記（１）記載の方法。 （３）職務証明が取引を認可するために要求され、認可
に関連付けられる職務証明が、認可構造の職務の承認セ
ット内の職務に対応することを確認することにより、認
可が更に保証される、前記（１）記載の方法。 （４）認可構造が認可ツリーである、前記（３）記載の
方法。 （５）職務が取引に関連付けられる職務証明から抽出さ
れ、抽出された各職務がハッシュされ、これらのハッシ
ュされた職務が連結されて、再度ハッシュされ、次に他
の承認セットのハッシュが存在すれば、認可構造に従い
それと連結されて、再度ハッシュされ、計算結果のハッ
シュ値が取引管理者により署名されたハッシュ値と比較
され、一致する場合取引が認可される、前記（３）記載
の方法。 （６）複数の相互接続されるコンピュータ及び複数の資
源を含むコンピュータ・ネットワーク上で動作する分散
ワークフロー管理システムであって、各コンピュータが
プロセッサ、メモリ及び入出力装置を含み、各資源が少
なくとも１つのコンピュータに動作上接続されて、プロ
セス・フローにおいて少なくとも１つの活動を実行する
ものにおいて、認可に関連付けられる少なくとも１つの
タイプの職務証明を抽出し、職務証明そのものが信頼で
きるか否かを確認することにより、取引の電子認可を検
証可能に編成する方法によりコード化されるシステム。 （７）職務証明に関連付けられる職務がハッシュされ、
ハッシュ化職務のデータベース内のハッシュ化職務と比
較される、前記（６）記載のシステム。 （８）職務証明が取引を認可するために要求され、認可
に関連付けられる職務証明が、認可構造の職務の承認セ
ット内の職務に対応することを確認することにより、認
可が更に保証される、前記（６）記載のシステム。 （９）認可構造が認可ツリーである、前記（８）記載の
システム。 （１０）職務が取引に関連付けられる職務証明から抽出
され、抽出された各職務がハッシュされ、これらのハッ
シュされた職務が連結されて、再度ハッシュされ、次に
他の承認セットのハッシュが存在すれば、認可構造に従
いそれと連結されて、再度ハッシュされ、計算結果のハ
ッシュ値が取引管理者により署名されたハッシュ値と比
較され、一致する場合取引が認可される、前記（８）記
載のシステム。 （１１）複数の相互接続されるコンピュータ及び複数の
資源を含むコンピュータ・ネットワーク上で動作するプ
ロセス・フローを有するコンピュータによる方法であっ
て、各コンピュータがプロセッサ、メモリ及び入出力装
置を含み、各資源が少なくとも１つのコンピュータに動
作上接続されて、プロセス・フローにおいて少なくとも
１つの活動を実行するものにおいて、認可に関連付けら
れる少なくとも１つのタイプの職務証明を抽出し、職務
証明そのものが信頼できるか否かを確認することによ
り、取引の電子認可を確認する方法。 （１２）職務証明に関連付けられる職務がハッシュさ
れ、ハッシュ化職務のデータベース内のハッシュ化職務
と比較される、前記（１１）記載の方法。 （１３）職務証明が取引を認可するために要求され、認
可に関連付けられる職務証明が、認可構造の職務の承認
セット内の職務に対応することを確認することにより、
認可が更に保証される、前記（１１）記載の方法。 （１４）認可構造が認可ツリーである、前記（１３）記
載の方法。 （１５）職務が取引に関連付けられる職務証明から抽出
され、抽出された各職務がハッシュされ、これらのハッ
シュされた職務が連結されて、再度ハッシュされ、次に
他の承認セットのハッシュが存在すれば、認可構造に従
いそれと連結されて、再度ハッシュされ、計算結果のハ
ッシュ値が取引管理者により署名されたハッシュ値と比
較され、一致する場合取引が認可される、前記（１３）
記載の方法。 （１６）複数の相互接続されるコンピュータ及び複数の
資源を含むコンピュータ・ネットワーク上で動作する分
散ワークフロー管理システムであって、各コンピュータ
がプロセッサ、メモリ及び入出力装置を含み、各資源が
少なくとも１つのコンピュータに動作上接続されて、プ
ロセス・フローにおいて少なくとも１つの活動を実行す
るものにおいて、認可に関連付けられる少なくとも１つ
のタイプの職務証明を抽出し、職務証明そのものが信頼
できるか否かを確認することにより、取引の電子認可を
確認する方法によりコード化されるシステム。 （１７）職務証明に関連付けられる職務がハッシュさ
れ、ハッシュ化職務のデータベース内のハッシュ化職務
と比較される、前記（１６）記載のシステム。 （１８）職務証明が取引を認可するために要求され、認
可に関連付けられる職務証明が、認可構造の職務の承認
セット内の職務に対応することを確認することにより、
認可が更に保証される、前記（１６）記載のシステム。 （１９）認可構造が認可ツリーである、前記（１８）記
載のシステム。 （２０）職務が取引に関連付けられる職務証明から抽出
され、抽出された各職務がハッシュされ、これらのハッ
シュされた職務が連結されて、再度ハッシュされ、次に
他の承認セットのハッシュが存在すれば、認可構造に従
いそれと連結されて、再度ハッシュされ、計算結果のハ
ッシュ値が取引管理者により署名されたハッシュ値と比
較され、一致する場合取引が認可される、前記（１８）
記載のシステム。 （２１）コンピュータ読取り可能媒体上でコード化され
る取引認可方法であって、 ａ）取引の依頼を受信し、 ｂ）取引の詳細を有する文書の電子表現をデジタル文書
データベースから獲得し、 ｃ）取引管理者により署名された職務証明を職務証明デ
ータベースから獲得し、署名を確認し、 ｄ）取引詳細を依頼者に返却し、 ｅ）依頼者により署名され、完成された表現を依頼者か
ら待機して受信し、 ｆ）取引管理者により事前に署名された取引の認可構造
を、認可構造データベースに要求し、署名を確認し、職
務名の承認セット及びこれらの職務名に署名するために
接触する承認セットのユーザ・メンバを選択し、 ｇ）依頼者の署名を有する取引依頼の詳細を、選択され
た承認セットに対応する職務を有する他の者に転送し、
承認セット内で示される各職務の署名を収集し、 ｈ）職務証明データベースからの職務証明及び承認セッ
トの各メンバの署名を要求し、それらを文書上でコード
化し、 ｉ）取引の正当性を確認するために要求される認可詳細
と、署名及び職務証明を含む完成された電子文書を依頼
者に転送するステップとを含む、取引認可方法。 （２２）職務証明及び認可構造が承認セット及び職務に
関するハッシュ化情報を含み、こうしたハッシュ化情報
が未ハッシュの職務証明及び承認セットを代理する、前
記（２１）記載の方法。 （２３）コンピュータ読取り可能媒体上でコード化され
る取引確認方法であって、 ａ）取引、取引当局により署名される関連取引詳細、職
務当局により署名される指定職務を証明する職務証明の
収集、職務証明内の確認キーに対応する各署名キーによ
り署名される取引詳細、及び認可構造を表す電子文書を
受信し、 ｂ）職務当局の確認キーを用いて、文書上の各証明をチ
ェックし、 ｃ）提供される職務証明内の確認キーを用いて、取引詳
細の署名を以下のようにチェックするものであって、 ｉ）職務証明から指定職務を抽出し、 ii）ハッシュのハッシュ・プロセスを用いて、職務をハ
ッシュし、 iii）取引の計算されたハッシュ値を、取引当局により
最初に署名されたものに対してチェックして、それが認
可構造内で受信される取引の値と等しいことを保証し、 iv）ハッシュのハッシュ・プロセスの出力を入力として
用いて、ハッシュのハッシュ・プロセスの署名をチェッ
クし、生成されたハッシュのハッシュ・ストリングが、
取引当局により署名されたハッシュ化ストリングと合致
する場合、依頼が認可されたと見なし、 ｄ）結果を報告するステップとを含む、方法。 （２４）取引認可方法によりコード化される分散ワーク
フロー管理システムであって、該方法が、 ａ）取引の依頼を受信する受信手段と、 ｂ）取引の詳細を有する文書の電子表現をデジタル文書
データベースから獲得する検索手段と、 ｃ）取引管理者により署名された職務証明を職務証明デ
ータベースから獲得し、署名を確認する検索手段と、 ｄ）取引詳細を依頼者に返却する伝送手段と、 ｅ）依頼者により署名され、完成された表現を依頼者か
ら受信する受信手段と、 ｆ）取引管理者により事前に署名された取引の認可構造
を、認可構造データベースに要求する問い合わせ手段
と、 ｇ）署名を確認する確認手段と、 ｈ）職務名の承認セット及びこれらの職務名に署名する
ために接触する承認セットのユーザ・メンバを選択する
選択手段と、 ｉ）依頼者の署名を有する取引依頼の詳細を、選択され
た承認セットに対応する職務を有する他の者に転送し、
承認セット内で示される各職務の署名を収集する伝送手
段と、 ｊ）職務証明データベースからの職務証明及び承認セッ
トの各メンバの署名を要求する検索手段と、 ｋ）ステップｊ）で収集された署名を文書上でコード化
するコード化手段と、 ｌ）取引の正当性を確認するために要求される認可詳細
と、署名及び職務証明を含む完成された電子文書を依頼
者に転送する伝送手段とを含む、システム。 （２５）職務証明及び認可構造が承認セット及び職務に
関するハッシュ化情報を含み、こうしたハッシュ化情報
が未ハッシュの職務証明及び承認セットを代理する、前
記（２４）記載のシステム。 （２６）取引確認方法によりコード化される分散ワーク
フロー管理システムであって、該記方法が、 ａ）取引、取引当局により署名される関連取引詳細、職
務当局により署名される指定職務を証明する職務証明の
収集、職務証明内の確認キーに対応する各署名キーによ
り署名される取引詳細、及び認可構造を表す電子文書を
受信し、 ｂ）職務当局の確認キーを用いて、文書上の各証明をチ
ェックし、 ｃ）提供される職務証明内の確認キーを用いて、取引詳
細の署名を以下のようにチェックするものであって、 ｉ）職務証明から指定職務を抽出し、 ii）ハッシュのハッシュ・プロセスを用いて、職務をハ
ッシュし、 iii）取引の計算されたハッシュ値を、取引当局により
最初に署名されたものに対してチェックして、それが認
可構造内で受信される取引の値と等しいことを保証し、 iv）ハッシュのハッシュ・プロセスの出力を入力として
用いて、ハッシュのハッシュ・プロセスの署名をチェッ
クし、生成されたハッシュのハッシュ・ストリングが、
取引当局により署名されたハッシュ化ストリングと合致
する場合、依頼が認可されたと見なし、 ｄ）結果を報告するステップとを含む、システム。 （２７）複数の相互接続されるコンピュータ及び複数の
資源を含むコンピュータ・ネットワーク上で動作するメ
ッセージ交換機構であって、各コンピュータがプロセッ
サ、メモリ及び入出力装置を含み、各資源が少なくとも
１つのコンピュータに動作上接続されて、コンピュータ
・ネットワークを介して別の資源に送信されるメッセー
ジを読み書き可能なものにおいて、認可に関連付けられ
る職務証明を抽出し、職務証明そのものが信頼できるか
否かを確認することにより、取引の電子認可を検証可能
に編成する機構。 （２８）職務証明に関連付けられる職務がハッシュさ
れ、ハッシュ化職務のデータベース内のハッシュ化職務
と比較される、前記（２７）記載の機構。 （２９）職務証明が取引を認可するために要求され、認
可に関連付けられる職務証明が、認可構造の職務の承認
セット内の職務に対応することを確認することにより、
認可が更に保証される、前記（２７）記載の機構。 （３０）認可構造が認可ツリーである、前記（２９）記
載の機構。 （３１）職務が取引に関連付けられる職務証明から抽出
され、抽出された各職務がハッシュされ、これらのハッ
シュされた職務が連結されて、再度ハッシュされ、次に
他の承認セットのハッシュが存在すれば、認可構造に従
いそれと連結されて、再度ハッシュされ、計算結果のハ
ッシュ値が取引管理者により署名されたハッシュ値と比
較され、一致する場合取引が認可される、前記（２９）
記載の機構。 （３２）複数の相互接続されるコンピュータ及び複数の
資源を含むコンピュータ・ネットワーク上で動作するメ
ッセージ交換機構であって、各コンピュータがプロセッ
サ、メモリ及び入出力装置を含み、各資源が少なくとも
１つのコンピュータに動作上接続されて、プロセス・フ
ローにおいて少なくとも１つの活動を実行するものにお
いて、認可に関連付けられる少なくとも１つのタイプの
職務証明を抽出し、職務証明そのものが信頼できるか否
かを確認することにより、取引の電子認可を確認する方
法によりコード化される機構。 （３３）職務証明に関連付けられる職務がハッシュさ
れ、ハッシュ化職務のデータベース内のハッシュ化職務
と比較される、前記（３２）記載の機構。 （３４）職務証明が取引を認可するために要求され、認
可に関連付けられる職務証明が、認可構造の職務の承認
セット内の職務に対応することを確認することにより、
認可が更に保証される、前記（３２）記載の機構。 （３５）認可構造が認可ツリーである、前記（３４）記
載の機構。 （３６）職務が取引に関連付けられる職務証明から抽出
され、抽出された各職務がハッシュされ、これらのハッ
シュされた職務が連結されて、再度ハッシュされ、次に
他の承認セットのハッシュが存在すれば、認可構造に従
いそれと連結されて、再度ハッシュされ、計算結果のハ
ッシュ値が取引管理者により署名されたハッシュ値と比
較され、一致する場合取引が認可される、前記（３４）
記載の機構。
及び複数の資源を含むコンピュータ・ネットワーク上で
動作するプロセス・フローを有するコンピュータによる
方法であって、各コンピュータがプロセッサ、メモリ及
び入出力装置を含み、各資源が少なくとも１つのコンピ
ュータに動作上接続されて、プロセス・フローにおいて
少なくとも１つの活動を実行するものにおいて、認可に
関連付けられる職務証明を抽出し、職務証明そのものが
信頼できるか否かを確認することにより、取引の電子認
可を検証可能に編成する方法。 （２）職務証明に関連付けられる職務がハッシュされ、
ハッシュ化職務のデータベース内のハッシュ化職務と比
較される、前記（１）記載の方法。 （３）職務証明が取引を認可するために要求され、認可
に関連付けられる職務証明が、認可構造の職務の承認セ
ット内の職務に対応することを確認することにより、認
可が更に保証される、前記（１）記載の方法。 （４）認可構造が認可ツリーである、前記（３）記載の
方法。 （５）職務が取引に関連付けられる職務証明から抽出さ
れ、抽出された各職務がハッシュされ、これらのハッシ
ュされた職務が連結されて、再度ハッシュされ、次に他
の承認セットのハッシュが存在すれば、認可構造に従い
それと連結されて、再度ハッシュされ、計算結果のハッ
シュ値が取引管理者により署名されたハッシュ値と比較
され、一致する場合取引が認可される、前記（３）記載
の方法。 （６）複数の相互接続されるコンピュータ及び複数の資
源を含むコンピュータ・ネットワーク上で動作する分散
ワークフロー管理システムであって、各コンピュータが
プロセッサ、メモリ及び入出力装置を含み、各資源が少
なくとも１つのコンピュータに動作上接続されて、プロ
セス・フローにおいて少なくとも１つの活動を実行する
ものにおいて、認可に関連付けられる少なくとも１つの
タイプの職務証明を抽出し、職務証明そのものが信頼で
きるか否かを確認することにより、取引の電子認可を検
証可能に編成する方法によりコード化されるシステム。 （７）職務証明に関連付けられる職務がハッシュされ、
ハッシュ化職務のデータベース内のハッシュ化職務と比
較される、前記（６）記載のシステム。 （８）職務証明が取引を認可するために要求され、認可
に関連付けられる職務証明が、認可構造の職務の承認セ
ット内の職務に対応することを確認することにより、認
可が更に保証される、前記（６）記載のシステム。 （９）認可構造が認可ツリーである、前記（８）記載の
システム。 （１０）職務が取引に関連付けられる職務証明から抽出
され、抽出された各職務がハッシュされ、これらのハッ
シュされた職務が連結されて、再度ハッシュされ、次に
他の承認セットのハッシュが存在すれば、認可構造に従
いそれと連結されて、再度ハッシュされ、計算結果のハ
ッシュ値が取引管理者により署名されたハッシュ値と比
較され、一致する場合取引が認可される、前記（８）記
載のシステム。 （１１）複数の相互接続されるコンピュータ及び複数の
資源を含むコンピュータ・ネットワーク上で動作するプ
ロセス・フローを有するコンピュータによる方法であっ
て、各コンピュータがプロセッサ、メモリ及び入出力装
置を含み、各資源が少なくとも１つのコンピュータに動
作上接続されて、プロセス・フローにおいて少なくとも
１つの活動を実行するものにおいて、認可に関連付けら
れる少なくとも１つのタイプの職務証明を抽出し、職務
証明そのものが信頼できるか否かを確認することによ
り、取引の電子認可を確認する方法。 （１２）職務証明に関連付けられる職務がハッシュさ
れ、ハッシュ化職務のデータベース内のハッシュ化職務
と比較される、前記（１１）記載の方法。 （１３）職務証明が取引を認可するために要求され、認
可に関連付けられる職務証明が、認可構造の職務の承認
セット内の職務に対応することを確認することにより、
認可が更に保証される、前記（１１）記載の方法。 （１４）認可構造が認可ツリーである、前記（１３）記
載の方法。 （１５）職務が取引に関連付けられる職務証明から抽出
され、抽出された各職務がハッシュされ、これらのハッ
シュされた職務が連結されて、再度ハッシュされ、次に
他の承認セットのハッシュが存在すれば、認可構造に従
いそれと連結されて、再度ハッシュされ、計算結果のハ
ッシュ値が取引管理者により署名されたハッシュ値と比
較され、一致する場合取引が認可される、前記（１３）
記載の方法。 （１６）複数の相互接続されるコンピュータ及び複数の
資源を含むコンピュータ・ネットワーク上で動作する分
散ワークフロー管理システムであって、各コンピュータ
がプロセッサ、メモリ及び入出力装置を含み、各資源が
少なくとも１つのコンピュータに動作上接続されて、プ
ロセス・フローにおいて少なくとも１つの活動を実行す
るものにおいて、認可に関連付けられる少なくとも１つ
のタイプの職務証明を抽出し、職務証明そのものが信頼
できるか否かを確認することにより、取引の電子認可を
確認する方法によりコード化されるシステム。 （１７）職務証明に関連付けられる職務がハッシュさ
れ、ハッシュ化職務のデータベース内のハッシュ化職務
と比較される、前記（１６）記載のシステム。 （１８）職務証明が取引を認可するために要求され、認
可に関連付けられる職務証明が、認可構造の職務の承認
セット内の職務に対応することを確認することにより、
認可が更に保証される、前記（１６）記載のシステム。 （１９）認可構造が認可ツリーである、前記（１８）記
載のシステム。 （２０）職務が取引に関連付けられる職務証明から抽出
され、抽出された各職務がハッシュされ、これらのハッ
シュされた職務が連結されて、再度ハッシュされ、次に
他の承認セットのハッシュが存在すれば、認可構造に従
いそれと連結されて、再度ハッシュされ、計算結果のハ
ッシュ値が取引管理者により署名されたハッシュ値と比
較され、一致する場合取引が認可される、前記（１８）
記載のシステム。 （２１）コンピュータ読取り可能媒体上でコード化され
る取引認可方法であって、 ａ）取引の依頼を受信し、 ｂ）取引の詳細を有する文書の電子表現をデジタル文書
データベースから獲得し、 ｃ）取引管理者により署名された職務証明を職務証明デ
ータベースから獲得し、署名を確認し、 ｄ）取引詳細を依頼者に返却し、 ｅ）依頼者により署名され、完成された表現を依頼者か
ら待機して受信し、 ｆ）取引管理者により事前に署名された取引の認可構造
を、認可構造データベースに要求し、署名を確認し、職
務名の承認セット及びこれらの職務名に署名するために
接触する承認セットのユーザ・メンバを選択し、 ｇ）依頼者の署名を有する取引依頼の詳細を、選択され
た承認セットに対応する職務を有する他の者に転送し、
承認セット内で示される各職務の署名を収集し、 ｈ）職務証明データベースからの職務証明及び承認セッ
トの各メンバの署名を要求し、それらを文書上でコード
化し、 ｉ）取引の正当性を確認するために要求される認可詳細
と、署名及び職務証明を含む完成された電子文書を依頼
者に転送するステップとを含む、取引認可方法。 （２２）職務証明及び認可構造が承認セット及び職務に
関するハッシュ化情報を含み、こうしたハッシュ化情報
が未ハッシュの職務証明及び承認セットを代理する、前
記（２１）記載の方法。 （２３）コンピュータ読取り可能媒体上でコード化され
る取引確認方法であって、 ａ）取引、取引当局により署名される関連取引詳細、職
務当局により署名される指定職務を証明する職務証明の
収集、職務証明内の確認キーに対応する各署名キーによ
り署名される取引詳細、及び認可構造を表す電子文書を
受信し、 ｂ）職務当局の確認キーを用いて、文書上の各証明をチ
ェックし、 ｃ）提供される職務証明内の確認キーを用いて、取引詳
細の署名を以下のようにチェックするものであって、 ｉ）職務証明から指定職務を抽出し、 ii）ハッシュのハッシュ・プロセスを用いて、職務をハ
ッシュし、 iii）取引の計算されたハッシュ値を、取引当局により
最初に署名されたものに対してチェックして、それが認
可構造内で受信される取引の値と等しいことを保証し、 iv）ハッシュのハッシュ・プロセスの出力を入力として
用いて、ハッシュのハッシュ・プロセスの署名をチェッ
クし、生成されたハッシュのハッシュ・ストリングが、
取引当局により署名されたハッシュ化ストリングと合致
する場合、依頼が認可されたと見なし、 ｄ）結果を報告するステップとを含む、方法。 （２４）取引認可方法によりコード化される分散ワーク
フロー管理システムであって、該方法が、 ａ）取引の依頼を受信する受信手段と、 ｂ）取引の詳細を有する文書の電子表現をデジタル文書
データベースから獲得する検索手段と、 ｃ）取引管理者により署名された職務証明を職務証明デ
ータベースから獲得し、署名を確認する検索手段と、 ｄ）取引詳細を依頼者に返却する伝送手段と、 ｅ）依頼者により署名され、完成された表現を依頼者か
ら受信する受信手段と、 ｆ）取引管理者により事前に署名された取引の認可構造
を、認可構造データベースに要求する問い合わせ手段
と、 ｇ）署名を確認する確認手段と、 ｈ）職務名の承認セット及びこれらの職務名に署名する
ために接触する承認セットのユーザ・メンバを選択する
選択手段と、 ｉ）依頼者の署名を有する取引依頼の詳細を、選択され
た承認セットに対応する職務を有する他の者に転送し、
承認セット内で示される各職務の署名を収集する伝送手
段と、 ｊ）職務証明データベースからの職務証明及び承認セッ
トの各メンバの署名を要求する検索手段と、 ｋ）ステップｊ）で収集された署名を文書上でコード化
するコード化手段と、 ｌ）取引の正当性を確認するために要求される認可詳細
と、署名及び職務証明を含む完成された電子文書を依頼
者に転送する伝送手段とを含む、システム。 （２５）職務証明及び認可構造が承認セット及び職務に
関するハッシュ化情報を含み、こうしたハッシュ化情報
が未ハッシュの職務証明及び承認セットを代理する、前
記（２４）記載のシステム。 （２６）取引確認方法によりコード化される分散ワーク
フロー管理システムであって、該記方法が、 ａ）取引、取引当局により署名される関連取引詳細、職
務当局により署名される指定職務を証明する職務証明の
収集、職務証明内の確認キーに対応する各署名キーによ
り署名される取引詳細、及び認可構造を表す電子文書を
受信し、 ｂ）職務当局の確認キーを用いて、文書上の各証明をチ
ェックし、 ｃ）提供される職務証明内の確認キーを用いて、取引詳
細の署名を以下のようにチェックするものであって、 ｉ）職務証明から指定職務を抽出し、 ii）ハッシュのハッシュ・プロセスを用いて、職務をハ
ッシュし、 iii）取引の計算されたハッシュ値を、取引当局により
最初に署名されたものに対してチェックして、それが認
可構造内で受信される取引の値と等しいことを保証し、 iv）ハッシュのハッシュ・プロセスの出力を入力として
用いて、ハッシュのハッシュ・プロセスの署名をチェッ
クし、生成されたハッシュのハッシュ・ストリングが、
取引当局により署名されたハッシュ化ストリングと合致
する場合、依頼が認可されたと見なし、 ｄ）結果を報告するステップとを含む、システム。 （２７）複数の相互接続されるコンピュータ及び複数の
資源を含むコンピュータ・ネットワーク上で動作するメ
ッセージ交換機構であって、各コンピュータがプロセッ
サ、メモリ及び入出力装置を含み、各資源が少なくとも
１つのコンピュータに動作上接続されて、コンピュータ
・ネットワークを介して別の資源に送信されるメッセー
ジを読み書き可能なものにおいて、認可に関連付けられ
る職務証明を抽出し、職務証明そのものが信頼できるか
否かを確認することにより、取引の電子認可を検証可能
に編成する機構。 （２８）職務証明に関連付けられる職務がハッシュさ
れ、ハッシュ化職務のデータベース内のハッシュ化職務
と比較される、前記（２７）記載の機構。 （２９）職務証明が取引を認可するために要求され、認
可に関連付けられる職務証明が、認可構造の職務の承認
セット内の職務に対応することを確認することにより、
認可が更に保証される、前記（２７）記載の機構。 （３０）認可構造が認可ツリーである、前記（２９）記
載の機構。 （３１）職務が取引に関連付けられる職務証明から抽出
され、抽出された各職務がハッシュされ、これらのハッ
シュされた職務が連結されて、再度ハッシュされ、次に
他の承認セットのハッシュが存在すれば、認可構造に従
いそれと連結されて、再度ハッシュされ、計算結果のハ
ッシュ値が取引管理者により署名されたハッシュ値と比
較され、一致する場合取引が認可される、前記（２９）
記載の機構。 （３２）複数の相互接続されるコンピュータ及び複数の
資源を含むコンピュータ・ネットワーク上で動作するメ
ッセージ交換機構であって、各コンピュータがプロセッ
サ、メモリ及び入出力装置を含み、各資源が少なくとも
１つのコンピュータに動作上接続されて、プロセス・フ
ローにおいて少なくとも１つの活動を実行するものにお
いて、認可に関連付けられる少なくとも１つのタイプの
職務証明を抽出し、職務証明そのものが信頼できるか否
かを確認することにより、取引の電子認可を確認する方
法によりコード化される機構。 （３３）職務証明に関連付けられる職務がハッシュさ
れ、ハッシュ化職務のデータベース内のハッシュ化職務
と比較される、前記（３２）記載の機構。 （３４）職務証明が取引を認可するために要求され、認
可に関連付けられる職務証明が、認可構造の職務の承認
セット内の職務に対応することを確認することにより、
認可が更に保証される、前記（３２）記載の機構。 （３５）認可構造が認可ツリーである、前記（３４）記
載の機構。 （３６）職務が取引に関連付けられる職務証明から抽出
され、抽出された各職務がハッシュされ、これらのハッ
シュされた職務が連結されて、再度ハッシュされ、次に
他の承認セットのハッシュが存在すれば、認可構造に従
いそれと連結されて、再度ハッシュされ、計算結果のハ
ッシュ値が取引管理者により署名されたハッシュ値と比
較され、一致する場合取引が認可される、前記（３４）
記載の機構。
【図１】本発明のコンピュータ・システムのブロック図
である。
である。
【図２】本発明の方法に従い符号化されるネットワーク
の概略図である。
の概略図である。
【図３】トランザクションの概略図である。
【図４】本発明の方法のフロー図である。
【図５】本発明の確認補助方法のフローチャートであ
る。
る。
【図６】本方法において使用される出張依頼書の概略図
である。
である。
【図７】本方法の取引当局を示すブロック図である。
【図８】本方法の認可構造を示すブロック図である。
【図９】出張依頼の認可ツリーを示す図である。
【図１０】職務証明書と本方法との相互作用を示すブロ
ック図である。
ック図である。
【図１１】本方法におけるＴＡＭと様々なデータベース
との相互作用を示すブロック図である。
との相互作用を示すブロック図である。
【図１２】完成された出張依頼の概略図である。
【図１３】出張依頼における職務証明書を示す概略図で
ある。
ある。
【図１４】依頼書の検証者への転送を示す概略図であ
る。
る。
【図１５】図９のツリーのハッシュを示す図である。
２ 取引認可方法（ＴＡＭ） ４ 契約 ６ 分散ワークフロー管理システム ８ ユーザ １０ 依頼 １８ 署名 ２０ コンピュータ・システム ２１ 分散システム ２２ 相互接続コンピュータ ２３ 資源 ２４ 表示装置 ２５ イントラネット（コンピュータ・ネットワーク） ２６ 入力装置 ２７ マウス ２８ 左マウス・ボタン ２９ 右マウス・ボタン ３０ １次記憶装置 ３１ インターネット（コンピュータ・ネットワーク） ３２ ２次記憶装置 ３３ データベース ３４ グラフィカル・ユーザ・インタフェース（ＧＵ
Ｉ） ３６ ＣＰＵ ４０ 取引 ４１ インタフェース ４２、１６５ 依頼者 ４４、１３０ 検証者 ４６ 製品またはサービス ５０ 電子文書 ５２ 依頼書 ５４ 出張依頼書 ６０ 取引依頼詳細 ６４ ＨＴＭＬ表現 ６６ 取引詳細 ７０ デジタル文書データベース（ＤＤＤ） ７６ 職務証明書 ８０ 取引当局（ＴＡ） ８２ 職務証明書データベース（ＲＣＤ） ９４ 認可構造（ＡＳ） ９６ 認可構造データベース（ＡＳＤ） １００ 承認セット １０２ 職務名 １０６、１２６ 署名 １１４ デジタル文書 １１６ 確認補助方法 １２０ 署名確認キー １２２ 職務 １４６ 認可情報 １５０ 突き合わせ署名キー １５４ 認可ツリー（ＡＴ） １５６ ノード １６０ 第１のレベル １６２ ルート １６４ 第２のレベル １６５ 一般社員（電子署名） １６６ リーフ １６７ 課長（電子署名） １６９ 部長（電子署名） １７０ "ＡＮＤ"ノード １７２ "ＯＲ"ノード １８０ 職務当局 ２０２ ユーザ・ディレクトリ・データ（ＵＤＢ）
Ｉ） ３６ ＣＰＵ ４０ 取引 ４１ インタフェース ４２、１６５ 依頼者 ４４、１３０ 検証者 ４６ 製品またはサービス ５０ 電子文書 ５２ 依頼書 ５４ 出張依頼書 ６０ 取引依頼詳細 ６４ ＨＴＭＬ表現 ６６ 取引詳細 ７０ デジタル文書データベース（ＤＤＤ） ７６ 職務証明書 ８０ 取引当局（ＴＡ） ８２ 職務証明書データベース（ＲＣＤ） ９４ 認可構造（ＡＳ） ９６ 認可構造データベース（ＡＳＤ） １００ 承認セット １０２ 職務名 １０６、１２６ 署名 １１４ デジタル文書 １１６ 確認補助方法 １２０ 署名確認キー １２２ 職務 １４６ 認可情報 １５０ 突き合わせ署名キー １５４ 認可ツリー（ＡＴ） １５６ ノード １６０ 第１のレベル １６２ ルート １６４ 第２のレベル １６５ 一般社員（電子署名） １６６ リーフ １６７ 課長（電子署名） １６９ 部長（電子署名） １７０ "ＡＮＤ"ノード １７２ "ＯＲ"ノード １８０ 職務当局 ２０２ ユーザ・ディレクトリ・データ（ＵＤＢ）
───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.7 識別記号 ＦＩ テーマコート゛(参考） Ｇ０９Ｃ 1/00 ６４０ Ｇ０９Ｃ 1/00 ６４０Ｚ ６６０ ６６０Ｂ Ｈ０４Ｌ 9/32 Ｈ０４Ｌ 9/00 ６７５Ｄ (72)発明者 オコナー・ルーク スイス、アドリスウィル シィ・エイチ− 8134、シホルホフ 16
Claims (36)
- 【請求項１】複数の相互接続されるコンピュータ及び複
数の資源を含むコンピュータ・ネットワーク上で動作す
るプロセス・フローを有するコンピュータによる方法で
あって、各コンピュータがプロセッサ、メモリ及び入出
力装置を含み、各資源が少なくとも１つのコンピュータ
に動作上接続されて、プロセス・フローにおいて少なく
とも１つの活動を実行するものにおいて、 認可に関連付けられる職務証明を抽出し、職務証明その
ものが信頼できるか否かを確認することにより、取引の
電子認可を検証可能に編成する方法。 - 【請求項２】職務証明に関連付けられる職務がハッシュ
され、ハッシュ化職務のデータベース内のハッシュ化職
務と比較される、請求項１記載の方法。 - 【請求項３】職務証明が取引を認可するために要求さ
れ、認可に関連付けられる職務証明が、認可構造の職務
の承認セット内の職務に対応することを確認することに
より、認可が更に保証される、請求項１記載の方法。 - 【請求項４】認可構造が認可ツリーである、請求項３記
載の方法。 - 【請求項５】職務が取引に関連付けられる職務証明から
抽出され、抽出された各職務がハッシュされ、これらの
ハッシュされた職務が連結されて、再度ハッシュされ、
次に他の承認セットのハッシュが存在すれば、認可構造
に従いそれと連結されて、再度ハッシュされ、計算結果
のハッシュ値が取引管理者により署名されたハッシュ値
と比較され、一致する場合取引が認可される、請求項３
記載の方法。 - 【請求項６】複数の相互接続されるコンピュータ及び複
数の資源を含むコンピュータ・ネットワーク上で動作す
る分散ワークフロー管理システムであって、各コンピュ
ータがプロセッサ、メモリ及び入出力装置を含み、各資
源が少なくとも１つのコンピュータに動作上接続され
て、プロセス・フローにおいて少なくとも１つの活動を
実行するものにおいて、 認可に関連付けられる少なくとも１つのタイプの職務証
明を抽出し、職務証明そのものが信頼できるか否かを確
認することにより、取引の電子認可を検証可能に編成す
る方法によりコード化されるシステム。 - 【請求項７】職務証明に関連付けられる職務がハッシュ
され、ハッシュ化職務のデータベース内のハッシュ化職
務と比較される、請求項６記載のシステム。 - 【請求項８】職務証明が取引を認可するために要求さ
れ、認可に関連付けられる職務証明が、認可構造の職務
の承認セット内の職務に対応することを確認することに
より、認可が更に保証される、請求項６記載のシステ
ム。 - 【請求項９】認可構造が認可ツリーである、請求項８記
載のシステム。 - 【請求項１０】職務が取引に関連付けられる職務証明か
ら抽出され、抽出された各職務がハッシュされ、これら
のハッシュされた職務が連結されて、再度ハッシュさ
れ、次に他の承認セットのハッシュが存在すれば、認可
構造に従いそれと連結されて、再度ハッシュされ、計算
結果のハッシュ値が取引管理者により署名されたハッシ
ュ値と比較され、一致する場合取引が認可される、請求
項８記載のシステム。 - 【請求項１１】複数の相互接続されるコンピュータ及び
複数の資源を含むコンピュータ・ネットワーク上で動作
するプロセス・フローを有するコンピュータによる方法
であって、各コンピュータがプロセッサ、メモリ及び入
出力装置を含み、各資源が少なくとも１つのコンピュー
タに動作上接続されて、プロセス・フローにおいて少な
くとも１つの活動を実行するものにおいて、 認可に関連付けられる少なくとも１つのタイプの職務証
明を抽出し、職務証明そのものが信頼できるか否かを確
認することにより、取引の電子認可を確認する方法。 - 【請求項１２】職務証明に関連付けられる職務がハッシ
ュされ、ハッシュ化職務のデータベース内のハッシュ化
職務と比較される、請求項１１記載の方法。 - 【請求項１３】職務証明が取引を認可するために要求さ
れ、認可に関連付けられる職務証明が、認可構造の職務
の承認セット内の職務に対応することを確認することに
より、認可が更に保証される、請求項１１記載の方法。 - 【請求項１４】認可構造が認可ツリーである、請求項１
３記載の方法。 - 【請求項１５】職務が取引に関連付けられる職務証明か
ら抽出され、抽出された各職務がハッシュされ、これら
のハッシュされた職務が連結されて、再度ハッシュさ
れ、次に他の承認セットのハッシュが存在すれば、認可
構造に従いそれと連結されて、再度ハッシュされ、計算
結果のハッシュ値が取引管理者により署名されたハッシ
ュ値と比較され、一致する場合取引が認可される、請求
項１３記載の方法。 - 【請求項１６】複数の相互接続されるコンピュータ及び
複数の資源を含むコンピュータ・ネットワーク上で動作
する分散ワークフロー管理システムであって、各コンピ
ュータがプロセッサ、メモリ及び入出力装置を含み、各
資源が少なくとも１つのコンピュータに動作上接続され
て、プロセス・フローにおいて少なくとも１つの活動を
実行するものにおいて、 認可に関連付けられる少なくとも１つのタイプの職務証
明を抽出し、職務証明そのものが信頼できるか否かを確
認することにより、取引の電子認可を確認する方法によ
りコード化されるシステム。 - 【請求項１７】職務証明に関連付けられる職務がハッシ
ュされ、ハッシュ化職務のデータベース内のハッシュ化
職務と比較される、請求項１６記載のシステム。 - 【請求項１８】職務証明が取引を認可するために要求さ
れ、認可に関連付けられる職務証明が、認可構造の職務
の承認セット内の職務に対応することを確認することに
より、認可が更に保証される、請求項１６記載のシステ
ム。 - 【請求項１９】認可構造が認可ツリーである、請求項１
８記載のシステム。 - 【請求項２０】職務が取引に関連付けられる職務証明か
ら抽出され、抽出された各職務がハッシュされ、これら
のハッシュされた職務が連結されて、再度ハッシュさ
れ、次に他の承認セットのハッシュが存在すれば、認可
構造に従いそれと連結されて、再度ハッシュされ、計算
結果のハッシュ値が取引管理者により署名されたハッシ
ュ値と比較され、一致する場合取引が認可される、請求
項１８記載のシステム。 - 【請求項２１】コンピュータ読取り可能媒体上でコード
化される取引認可方法であって、 ａ）取引の依頼を受信し、 ｂ）取引の詳細を有する文書の電子表現をデジタル文書
データベースから獲得し、 ｃ）取引管理者により署名された職務証明を職務証明デ
ータベースから獲得し、署名を確認し、 ｄ）取引詳細を依頼者に返却し、 ｅ）依頼者により署名され、完成された表現を依頼者か
ら待機して受信し、 ｆ）取引管理者により事前に署名された取引の認可構造
を、認可構造データベースに要求し、署名を確認し、職
務名の承認セット及びこれらの職務名に署名するために
接触する承認セットのユーザ・メンバを選択し、 ｇ）依頼者の署名を有する取引依頼の詳細を、選択され
た承認セットに対応する職務を有する他の者に転送し、
承認セット内で示される各職務の署名を収集し、 ｈ）職務証明データベースからの職務証明及び承認セッ
トの各メンバの署名を要求し、それらを文書上でコード
化し、 ｉ）取引の正当性を確認するために要求される認可詳細
と、署名及び職務証明を含む完成された電子文書を依頼
者に転送するステップとを含む、取引認可方法。 - 【請求項２２】職務証明及び認可構造が承認セット及び
職務に関するハッシュ化情報を含み、こうしたハッシュ
化情報が未ハッシュの職務証明及び承認セットを代理す
る、請求項２１記載の方法。 - 【請求項２３】コンピュータ読取り可能媒体上でコード
化される取引確認方法であって、 ａ）取引、取引当局により署名される関連取引詳細、職
務当局により署名される指定職務を証明する職務証明の
収集、職務証明内の確認キーに対応する各署名キーによ
り署名される取引詳細、及び認可構造を表す電子文書を
受信し、 ｂ）職務当局の確認キーを用いて、文書上の各証明をチ
ェックし、 ｃ）提供される職務証明内の確認キーを用いて、取引詳
細の署名を以下のようにチェックするものであって、 ｉ）職務証明から指定職務を抽出し、 ii）ハッシュのハッシュ・プロセスを用いて、職務をハ
ッシュし、 iii）取引の計算されたハッシュ値を、取引当局により
最初に署名されたものに対してチェックして、それが認
可構造内で受信される取引の値と等しいことを保証し、 iv）ハッシュのハッシュ・プロセスの出力を入力として
用いて、ハッシュのハッシュ・プロセスの署名をチェッ
クし、生成されたハッシュのハッシュ・ストリングが、
取引当局により署名されたハッシュ化ストリングと合致
する場合、依頼が認可されたと見なし、 ｄ）結果を報告するステップとを含む、方法。 - 【請求項２４】取引認可方法によりコード化される分散
ワークフロー管理システムであって、該方法が、 ａ）取引の依頼を受信する受信手段と、 ｂ）取引の詳細を有する文書の電子表現をデジタル文書
データベースから獲得する検索手段と、 ｃ）取引管理者により署名された職務証明を職務証明デ
ータベースから獲得し、署名を確認する検索手段と、 ｄ）取引詳細を依頼者に返却する伝送手段と、 ｅ）依頼者により署名され、完成された表現を依頼者か
ら受信する受信手段と、 ｆ）取引管理者により事前に署名された取引の認可構造
を、認可構造データベースに要求する問い合わせ手段
と、 ｇ）署名を確認する確認手段と、 ｈ）職務名の承認セット及びこれらの職務名に署名する
ために接触する承認セットのユーザ・メンバを選択する
選択手段と、 ｉ）依頼者の署名を有する取引依頼の詳細を、選択され
た承認セットに対応する職務を有する他の者に転送し、
承認セット内で示される各職務の署名を収集する伝送手
段と、 ｊ）職務証明データベースからの職務証明及び承認セッ
トの各メンバの署名を要求する検索手段と、 ｋ）ステップｊ）で収集された署名を文書上でコード化
するコード化手段と、 ｌ）取引の正当性を確認するために要求される認可詳細
と、署名及び職務証明を含む完成された電子文書を依頼
者に転送する伝送手段とを含む、システム。 - 【請求項２５】職務証明及び認可構造が承認セット及び
職務に関するハッシュ化情報を含み、こうしたハッシュ
化情報が未ハッシュの職務証明及び承認セットを代理す
る、請求項２４記載のシステム。 - 【請求項２６】取引確認方法によりコード化される分散
ワークフロー管理システムであって、該記方法が、 ａ）取引、取引当局により署名される関連取引詳細、職
務当局により署名される指定職務を証明する職務証明の
収集、職務証明内の確認キーに対応する各署名キーによ
り署名される取引詳細、及び認可構造を表す電子文書を
受信し、 ｂ）職務当局の確認キーを用いて、文書上の各証明をチ
ェックし、 ｃ）提供される職務証明内の確認キーを用いて、取引詳
細の署名を以下のようにチェックするものであって、 ｉ）職務証明から指定職務を抽出し、 ii）ハッシュのハッシュ・プロセスを用いて、職務をハ
ッシュし、 iii）取引の計算されたハッシュ値を、取引当局により
最初に署名されたものに対してチェックして、それが認
可構造内で受信される取引の値と等しいことを保証し、 iv）ハッシュのハッシュ・プロセスの出力を入力として
用いて、ハッシュのハッシュ・プロセスの署名をチェッ
クし、生成されたハッシュのハッシュ・ストリングが、
取引当局により署名されたハッシュ化ストリングと合致
する場合、依頼が認可されたと見なし、 ｄ）結果を報告するステップとを含む、システム。 - 【請求項２７】複数の相互接続されるコンピュータ及び
複数の資源を含むコンピュータ・ネットワーク上で動作
するメッセージ交換機構であって、各コンピュータがプ
ロセッサ、メモリ及び入出力装置を含み、各資源が少な
くとも１つのコンピュータに動作上接続されて、コンピ
ュータ・ネットワークを介して別の資源に送信されるメ
ッセージを読み書き可能なものにおいて、 認可に関連付けられる職務証明を抽出し、職務証明その
ものが信頼できるか否かを確認することにより、取引の
電子認可を検証可能に編成する機構。 - 【請求項２８】職務証明に関連付けられる職務がハッシ
ュされ、ハッシュ化職務のデータベース内のハッシュ化
職務と比較される、請求項２７記載の機構。 - 【請求項２９】職務証明が取引を認可するために要求さ
れ、認可に関連付けられる職務証明が、認可構造の職務
の承認セット内の職務に対応することを確認することに
より、認可が更に保証される、請求項２７記載の機構。 - 【請求項３０】認可構造が認可ツリーである、請求項２
９記載の機構。 - 【請求項３１】職務が取引に関連付けられる職務証明か
ら抽出され、抽出された各職務がハッシュされ、これら
のハッシュされた職務が連結されて、再度ハッシュさ
れ、次に他の承認セットのハッシュが存在すれば、認可
構造に従いそれと連結されて、再度ハッシュされ、計算
結果のハッシュ値が取引管理者により署名されたハッシ
ュ値と比較され、一致する場合取引が認可される、請求
項２９記載の機構。 - 【請求項３２】複数の相互接続されるコンピュータ及び
複数の資源を含むコンピュータ・ネットワーク上で動作
するメッセージ交換機構であって、各コンピュータがプ
ロセッサ、メモリ及び入出力装置を含み、各資源が少な
くとも１つのコンピュータに動作上接続されて、プロセ
ス・フローにおいて少なくとも１つの活動を実行するも
のにおいて、 認可に関連付けられる少なくとも１つのタイプの職務証
明を抽出し、職務証明そのものが信頼できるか否かを確
認することにより、取引の電子認可を確認する方法によ
りコード化される機構。 - 【請求項３３】職務証明に関連付けられる職務がハッシ
ュされ、ハッシュ化職務のデータベース内のハッシュ化
職務と比較される、請求項３２記載の機構。 - 【請求項３４】職務証明が取引を認可するために要求さ
れ、認可に関連付けられる職務証明が、認可構造の職務
の承認セット内の職務に対応することを確認することに
より、認可が更に保証される、請求項３２記載の機構。 - 【請求項３５】認可構造が認可ツリーである、請求項３
４記載の機構。 - 【請求項３６】職務が取引に関連付けられる職務証明か
ら抽出され、抽出された各職務がハッシュされ、これら
のハッシュされた職務が連結されて、再度ハッシュさ
れ、次に他の承認セットのハッシュが存在すれば、認可
構造に従いそれと連結されて、再度ハッシュされ、計算
結果のハッシュ値が取引管理者により署名されたハッシ
ュ値と比較され、一致する場合取引が認可される、請求
項３４記載の機構。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP00810016 | 2000-01-07 | ||
| EP00810016.6 | 2000-01-07 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001229336A true JP2001229336A (ja) | 2001-08-24 |
| JP3871300B2 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 |
|---|---|---|---|---|
| WO2022070405A1 (ja) * | 2020-10-02 | 2022-04-07 | 富士通株式会社 | 制御方法、生成方法、生成プログラムおよび情報処理装置 |
Families Citing this family (50)
| 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 |
| US20020152086A1 (en) * | 2001-02-15 | 2002-10-17 | Smith Ned M. | Method and apparatus for controlling a lifecycle of an electronic contract |
| US20020157004A1 (en) * | 2001-02-15 | 2002-10-24 | Smith Ned M. | Method of enforcing authorization in shared processes using electronic contracts |
| 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 |
| 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 |
| 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 |
| 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 |
| US8341415B1 (en) * | 2008-08-04 | 2012-12-25 | Zscaler, Inc. | Phrase matching |
| US9342621B1 (en) | 2008-08-04 | 2016-05-17 | 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 |
| EP2877954B1 (en) * | 2012-07-27 | 2021-09-01 | 9408-3078 Québec Inc. | Method of managing role-based digital rights in a computer system |
| 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 | ***通信集团河北有限公司 | 一种访问控制方法、装置及*** |
| EP2947848B1 (en) * | 2014-05-20 | 2018-07-11 | 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 |
| US10291604B2 (en) * | 2016-06-03 | 2019-05-14 | Docusign, Inc. | Universal access to document transaction platform |
| 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 |
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 |
| CA2194475A1 (en) * | 1994-07-19 | 1996-02-01 | Frank W. Sudia | Method for securely using digital signatures in a commercial cryptographic system |
| US7904722B2 (en) * | 1994-07-19 | 2011-03-08 | Certco, Llc | Method for securely using digital signatures in a commercial cryptographic system |
| EP0697662B1 (en) * | 1994-08-15 | 2001-05-30 | International Business Machines Corporation | Method and system for advanced role-based access control in distributed and centralized computer systems |
| 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 (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2022070405A1 (ja) * | 2020-10-02 | 2022-04-07 | 富士通株式会社 | 制御方法、生成方法、生成プログラムおよび情報処理装置 |
| JPWO2022070405A1 (ja) * | 2020-10-02 | 2022-04-07 | ||
| JP7376838B2 (ja) | 2020-10-02 | 2023-11-09 | 富士通株式会社 | 制御方法、制御プログラムおよび情報処理装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| AU7186300A (en) | 2001-07-12 |
| CN1304104A (zh) | 2001-07-18 |
| KR100497022B1 (ko) | 2005-06-23 |
| US7222107B2 (en) | 2007-05-22 |
| JP3871300B2 (ja) | 2007-01-24 |
| KR20010070373A (ko) | 2001-07-25 |
| AU782518B2 (en) | 2005-08-04 |
| US20010021928A1 (en) | 2001-09-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3871300B2 (ja) | 企業間での職務ベースの認可のための方法 | |
| Augot et al. | A user-centric system for verified identities on the bitcoin blockchain | |
| Ellison | SPKI requirements | |
| US6438690B1 (en) | Vault controller based registration application serving web based registration authorities and end users for conducting electronic commerce in secure end-to-end distributed information system | |
| EP1540881B1 (en) | System and method for the transmission, storage and retrieval of authenticated documents | |
| US7457950B1 (en) | Managed authentication service | |
| US8892475B2 (en) | Provision of authorization and other services | |
| US20090271321A1 (en) | Method and system for verification of personal information | |
| US20030051144A1 (en) | Dynamic electronic chain-of-trust document with audit trail | |
| US20010027527A1 (en) | Secure transaction system | |
| KR102280061B1 (ko) | 블록체인 기반의 did를 이용한 법인 관련 증명서 발급 시스템 및 방법 | |
| US8479006B2 (en) | Digitally signing documents using identity context information | |
| JP6042766B2 (ja) | 電子取引システム、電子取引方法、及びプログラム | |
| US7363509B2 (en) | Method, system and program product for electronically executing contracts within a secure computer infrastructure | |
| US20050188204A1 (en) | Electronic notary service | |
| Ellison | RFC2692: SPKI Requirements | |
| US20190066123A1 (en) | Method for storing, delivering, and displaying documentation and credentials related to intrastate and interstate commerce | |
| CN115514489A (zh) | 知识密集型零工经济服务***及其运行方法 | |
| JP2003108708A (ja) | セキュアアプリケーションフレームワーク及び該セキュアアプリケーションフレームワークを用いた電子申請システム，装置，方法並びにプログラム | |
| Prabu et al. | Academic Information Storage and Verification Using Blockchain Technologies | |
| EP1115074A2 (en) | A method for inter-enterprise role-based authorization | |
| WO2024142441A1 (ja) | 電子認証システムおよび電子認証方法 | |
| Jaafar et al. | A proposed Security Model for E-government Based on Primary Key Infrastructure and Fingerprints. | |
| TWI718659B (zh) | 使用代碼驗證的資料傳輸方法與系統 | |
| AU743570B1 (en) | Means and method of registering new users in a system of registered users |
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 |