JP2002504731A

JP2002504731A - コンピュータを利用した方法と取引支援システム

Info

Publication number: JP2002504731A
Application number: JP2000532823A
Authority: JP
Inventors: エアー・フランケル; デイビッド・ウィリアム・クラビッツ; チャールズ・トーマス・モントゴメリー; マーセル・モーデチェイ・ユン
Original assignee: サートコ
Priority date: 1998-02-19
Filing date: 1999-02-18
Publication date: 2002-02-12
Also published as: US7343346B2; US20010011220A1; US6353812B2; WO1999042965A1; US20080221914A1; AU3285599A; US8121949B2; US20020059143A1; EP1072025A1; CA2322042A1; US20130173471A1; US8321348B2; US20120143723A1

Abstract

(57)【要約】クライアントに対してサービスを提供する組織にめいめいが関連する複数の場所であって、コンピュータシステムと、組織の各クライアントについての情報を蓄積するデータベースと、少なくとも一つの前記組織のクライアントである当事者のデータ通信装置と通信するデータ通信装置とからなる前記場所を備えたインフラストラクチャからなるシステムにおいて、データ通信装置を有する二者の間での取引に関して保証を提供する方法であって、対応する組織のクライアントである取引の一方の当事者からその組織に関連する場所へ、その取引の他方の当事者を弁別する情報と性質に関する情報とを含む保証要請を伝達し、前記場所と、他方の当事者がクライアントとなっている組織に関連する場所との間で情報交換を行い、一方の当事者に対して対応する組織から保証要請に対する回答を伝達する方法。

Description

【発明の詳細な説明】

【０００１】（技術分野）本発明は、例えば金融取引の如くの取引でのコンピュータシステムの利用に関
し、特に、高度のセキュリティで実質的な取引を行う関係者の能力を高めること
に関する。

【０００２】（背景技術）商取引支援手段としてコンピュータ及び通信技術が広く使われるようになって
いる。個人小切手の照合やクレジットカードでの購入認証の如くの取引が日常行
われているところである。

【０００３】これまでに提案されているある種の取引支援方法にオフラインによる「身元確認」取引システムがあり、このシステムではサーティフィケーション・オーソリティ(Certification Authority, CA)が正確性を保証し、ユーザの証明書のデータの正確性で二種の公開鍵シグネチャによる取引システムを区別している。この
種のシステムでは、公開鍵や非公開鍵、デジタル署名などをの如くの最新技術を
利用している。デジタル署名の役割は、実署名に取って代わるもので、「電子世界」のユーザに文書署名のメカニズムをもたせることにある。デジタル署名で署名者を明らかにすることができると共に、当該署名者を署名された文書を間違い
なく関連付けることができる。ＣＡの公開鍵、非公開鍵、デジタル署名について
は、ブルース・シュナイアー著「Applied Cryptography(応用暗号化法)」(John Wi
ley & Sons出版社)で論じられている。本明細書においては「ユーザ」とは、人を指すのみならず、その人や団体に変わって行為をなすコンピュータプログラムを
も意味するものとする。

【０００４】デジタル署名を利用するシステムの規模を大きくするには、単に個人デジタル
署名スキームだけでは不充分である。単純な形では、めいめいのユーザが他のユ
ーザの「署名認証鍵」を持たなければならない。従って、ＣＡの考えとアーキテク
チャが提案されているのである。ＣＡとは、「ユーザの身元」をユーザの「署名認証鍵」と関連付けるあらゆる特定のメッセージの正確性を保証する機関である。従って、ＣＡアーキテクチャはデジタル署名の考えをブートストラップしている
。個々のユーザとしては各ユーザの認証鍵を持つ必要はなく、その代わりに署名
と、ユーザを認証鍵と関連つける標準メッセージにＣＡが署名する「証明書」が与
えられる。そのために、従来のものも含め、CCITT Recommendation X.509, 1989
で説明されているように種々のスキームがある。

【０００５】ＣＡによる基本的なアーキテクチャでは、証明書は署名者がユーザに対して「売り付ける(push)」か、または、ユーザがＣＡから「買い取る(pull)」かのいずれかである。ここでの「または」は、証明書が取り消されることもあり得るから、非
排他的である。何れにしても、「ＣＡアーキテクチャ」が既成事実で存在するもの
と見なす。高度な拡張性として、ＣＡのヒエラルキー(ＣＡのインフラストラクチャ(CA infrastructure))が考えられる。ユーザはそのユーザが信頼するＣＡに
達するまで、ツリー構造を昇る必要がある。この構造は必ずしもヒエラルキーを
備えている必要はなく、沢山の意味(semantic)を持っている必要がある。即ち、
種々のＣＡがある仕事、鍵の種類、取引などを処理する。

【０００６】前述のシステムは、一般には購入者である関係者の身元を確認するだけで充分
な取引を支援できることが判明している。しかし、斯かるシステムは、一人か、
複数の関係者が特定の行為を行うか、特定の目標を達成しなければならない、或
いは、特定に性質、資格などを持っていなければならないとか、ある状態ないし
条件になければならないとかなどの複雑な取引には適していない。本願出願人は
、取引に金融サービス支援が必要になっている商取引環境においては、証明書か
らわかる情報よりももっと適切な取引に関する情報があるのを見いだした。この
ようなことはその他の種々の取引、例えば、関係者の資格、身分などを確実にし
ていなければならない取引や、ヘルスケアなどについてもあてはまることである
。以後の本発明の説明においては、主として金融取引を例に挙げて説明するが、
これは単に説明上の一例に過ぎず、従って本発明は請求の範囲に基づいて解釈す
べきである点を断っておく。

【０００７】（発明の開示）（発明が解決しようとする技術的課題）本発明は、第三者をユーザの取引歴、特徴、状態などに基づいて取引毎に当該
ユーザの保証人とする「保証請合い」システムを提供するのを目的としている。こ
こでの「状態」とは、ユーザの条件、ステータス、資格など、ユーザの取引完遂能
力に関わる状態を意味する。

【０００８】また、大抵の商取引における当事者間に必要な信頼性のある最新保証を第三者
が与えることができるようにするのも、本発明の別の目的である。

【０００９】保証の発行と有効性を取引の性質と、該取引に関わる当事者の特徴と現況とに
基づかせることも、本発明のまた別の目的である。

【００１０】電子商取引の環境で利用できる公開鍵インフラストラクチャにおけるが如く入
手可能性を高め、取引量を拡大することも、本発明の更に別の目的である。

【００１１】大量の同時リクエストにも対応できる支援インフラストラクチャを提供するこ
とも、本発明のもう一つの目的である。

【００１２】単一のクライアントが要請者で、別の単一クライアントが保証の対象となって
いる同時リクエストにも対応させることも、本発明の更にもう一つの目的である
。

【００１３】特に、本発明の目的は、特定のクライアントが、以前に開始した取引について
の反応を待っている間に、新たな取引に対するサービスを要請することができる
ようにすると共に、複数のクライアントが、一つの保証対象項目にて浮いて同時
に保証を要請できるようにすることにある。

【００１４】本発明の別の目的は、保証に基づくシステムに通常関連する遅延や混雑を最小
限にするか、なくすように処理に融通を持たせることのできるシステムを提供す
ることである。これらの遅延は、末端(local)代表者の手許に全ての情報がなく、専ら他のソースから認証を得なければならないような場合に発生することがあ
る。また、保証の発行に関わる意思決定プロセスが自動化されていない、即ち、
人間による入力を必要としている場合でも、そのような遅延が発生する殊がある
。完全自動化した取引や、遅延を来している取引の両方を最適状態で受け付ける
能力は、システムにとって重要な特徴である。

【００１５】（その解決方法）本発明の前述した諸目的は、クライアントに対してサービスを提供する組織(i
nstitution)にめいめいが関連する複数の場所(location)であって、コンピュータシステムと、該コンピュータシステムと接続されて組織の各クライアントにつ
いての情報を蓄積するデータベースと、前記コンピュータシステムと接続されて
、少なくとも一つの前記組織のクライアントである当事者のデータ通信装置と通
信するデータ通信装置とからなる前記場所を備えたインフラストラクチャからな
るシステムにおいて、データ通信装置を有する二者の間での取引に関して保証を
提供する方法であって、対応する組織のクライアントである取引の一方の当事者からその組織に関連す
る場所へ、その取引の他方の当事者を弁別する情報と当該取引の性質に関する情
報とを含む保証要請を伝達し、前記場所と、他方の当事者がクライアントとなっている組織に関連する場所と
の間で情報交換を行い、一方の当事者に対して対応する組織から保証要請に対する回答を伝達すること
よりなる前記方法により達成できる。

【００１６】本発明による保証発行プロセスは、デジタル署名のよる環境でのユーザ証明取
引を拡大するものと見ることができる。保証対象となる債務者の身元についての
無条件認証照合(implicit verification check)と保証対象に関しての取引用デジタル署名の信憑性とを、プライバシーと保証発行基準に対処すたアクセス制御
機構とを融合したものである。

【００１７】支援インフラストラクチャによるサービスに対する料金支払いは、支援インフ
ラストラクチャ内に整理することができる。これには、スループット発行として
、また、サービスに対する支払いを確実にするために必要とされている。

【００１８】本発明の利点としては、保証を要請している当事者だけが支援インフラストラ
クチャと接触するだけでよいところにある。

【００１９】本発明のもう一つの利点としては、特定の組織ないし末端代表者のクライアン
トである当事者は、その末端代表者だけを信頼すればよいところにある。何故な
ら、そのクライアントに発行される保証は末端代表者が発行するものであり、ま
た、クライアントについてのデータを支援インフラストラクチャ内で公開するこ
とはクライアントの末端代表者により制御されているからである。

【００２０】保証請合いシステムは、取引の種類によっては、また、(保証を請け合って貰う)サービスに対して支払いを行う当事者によっては幾つかの形態で実施しうるものである。

【００２１】（発明の詳細な説明）前述したように、以後の詳細な説明は金融取引を一例にして説明するが、他の
主の取引にも利用できるものである。

【００２２】本発明によるシステムにおいて金融取引を支援するデータの交換には、少なく
とも三つの実体(entity)が関わっている。即ち、支援インフラストラクチャがそ
の一つである。この支援インフラストラクチャは、Local Representative(末端代表者)として知られている複数の組織から成り立っている。取引には、インフラストラクチャ外の二人かそれ以上の当事者が関わっているのが常である。各当
事者はインフラストラクチャにおける何れかの末端代表者のクライアントであり
、本明細書ではこの当事者を「クライアント」とっしょうしている。支援インフラ
ストラクチャは一つの単位と見ることができるが、現実には銀行の如く、地理的
に離散した単位である種々の金融組織から成り立っている。

【００２３】クライアントは、めいめいがインフラストラクチャの少なくとも一つの末端代
表者、例えば銀行と、商売上または個人的な関係を持っているもとの想定する。
二人のクライアントClient 1、Client 2についての典型的な関係と両者間の通信
リンクを図１に示す。各クライアントは、例えば末端代表者に対して、当該クラ
イアントに対して保証請合い手順を行うに当たって後で末端代表者が必要とする
かもしれない個人的、または、商売上の何れか一方、または両方のデータを提供
するために、当該クライアントに関わりのある末端代表者とつながっている。

【００２４】図１には示していないが、各末端代表者は、他の末端代表者、ＣＡ、保険会社
、出資者などとのつながりを有している。末端代表者は、電子支払いシステムの
みならず、文書作成、日時捺印、それにその他のサービスを必要とすることがあ
る。

【００２５】必要に応じてクライアントは、保証に関するステートメントとそれに関係のあ
る情報を定期的に受け取っているものと想定する。これは取引毎になされている
ものでないこともあり、従って、特定の取引に関わるメッセージの流れには示さ
れていないけれども、データの流れの一例を以下に説明する。

【００２６】本発明により保証が求められている場合、クライアントは幾つかの役割の中か
らどれかを採ることになる

【００２７】クライアントは、取引を進めるためにも保証を必要としている当事者、即ち、
被保証人とする。他のクライアントは、保証の「対象」、即ち、「対象」に対して保
証が必要となるものである。クライアントでない当事者について保証を与えるこ
とも可能ではあるが、本発明が対応する主の取引にはそのようなケースはあまり
関係がない。

【００２８】クライアントが採ることのできるもう一つの役割は保証の要請人となることで
ある。この「要請人」は被保証人と保証対象の何れかになることができる。

【００２９】これらの二つの考えられる役割は、図２と図３にそれぞれ示した二つの考えら
れる通信形態とそれぞれ関係している。各通信形態では一人のクライアントがそ
の末端代表者とつながっている必要がある。

【００３０】尚、支援インフラストラクチャとクライアントの間の関係はこれらの二つの役
割ごとに異なっている。図３の場合では、Client 2が取引要件を満たせるかどう
かの能力と、保証請合いに伴う料金の支払い能力との両方を単一の末端代表者が
判断できるものとしていることから、相互関係は簡単である。図２の場合では、
Client 1は保証に対して支払いをなしているものの、取引を支援するClient 2の
能力が問題となっていることから、状況はもっと複雑になっている。

【００３１】本発明を実施するためのシステムの実施の形態を図４に示しており、複数の末
端代表者で構成した支援インフラストラクチャからなる。各末端代表者は、例え
ば銀行の如くの金融組織であってもよく、証明発行機関や、保険会社、出資者の
何れであってもよい。支援インフラストラクチャは、地方、国、多国籍国家、或
いは全世界における一部、または、全ての組織で構成してもよい。末端代表者は
、必要とする重要度のセキュリティを備えた適当な通信チャンネルで互いにつな
がっている。

【００３２】各末端代表者にはコンピュータシステムと、該コンピュータシステムにつなが
っていて、データベースを格納しているデータ記憶システムと、当該末端代表者
と既成関係を有し、本明細書においてクライアントと称する当事者と通信するた
めの、例えばモデムの如くのある種のトランシーバとが備わっているものとする
。各クライアントは、個人であってもよいし、または、法人であってもよい。デ
ータベースには、末端代表者のクライアントに関わる全ての適切な情報が含まれ
ている。

【００３３】各クライアントには、データを少なくとも受信、保存、送信するように構築し
たコンピュータシステムと、例えばモデムの如く、対応する末端代表者との通信
リンクを確立するように構築されているトランシーバと、別の当事者と通信する
ための通信装置とが備わっているものとする。尚、この通信装置としては前述の
トランシーバであってもよいこともある。

【００３４】同一末端代表者のクライアントか、または、異なった末端代表者のクライアン
トの何れでもよい二人の当事者間での取引を支援するために支援インフラストラ
クチャを利用するが、その場合、少なくとも一方の当事者についての情報を取引
に関する情報と共に検査して、この検査結果さえ許せば、取引の当事者の一方側
による契約上の義務履行につての保証を発行する。

【００３５】図４に示したように、本発明の一つの特徴は、支援インフラストラクチャとの
通信が取引当事者の一方側だけ、本例の場合ではClient 2と取引について交渉し
ているClient 1だけが行う点にある。Client 1とClient 2とはここでは、別々の
末端代表者、即ち、Local Representative 1とLocal Representative 2のクライ
アントである。

【００３６】前述のシステムにおいては、後述の形になっているメッセージを交換すること
により本発明が実行される。後述のメッセージの交換は、Client 1とClient 2と
が取引を行う契約を行うことで合意した後に行われるものと想定している。この
合意が行われる前では、Client 1とClient 2とは取引の特異な面について、また
、取引を完遂する能力について情報を交わしあったものとしている。この取引で
Client 2にはある義務が果たされ、Client 1は、Client 2には少なくとも義務を
尊ぶ能力があるとの既知の信頼性のある当事者から保証の形での確約を求めてい
るとする。この場合、Client 1は潜在的な被保証人であり、保証要請人でもあり
、他方、Client 2は保証対象であり、末端代表者Local Representative 1はその
ための保証の発行が要請されているので、保証人である。

【００３７】メッセージ１メッセージ１には、保証要請のもとになる情報と共に、取引について最終合意
した説明が含まれている。メッセージ１(及び、それに先立つメッセージ)におけ
るこの情報は暗号化されていると共に、署名されていることがある。しかしなが
ら、従来公知の手段によりなされてもよいこの保護策は本発明にとっては必須要
件ではないので、ここでは詳述しない。

【００３８】メッセージ２メッセージ２には下記のフィールド(a)から(h)が含まれている。 a) 保証対象(Client 2)の身分 − 支援インフラストラクチャにより特異的に
認識される形になっている。支援インフラストラクチャ内においてLocal Repres
entative 2を見つけるためにLocal Representative 1が必要とする情報が含まれ
ている。

【００３９】 b) 被保証人(Client 1)の身分 − Client 2が被保証人から以前に受け取った
情報に基づいており、支援インフラストラクチャ内での被保証人の特異的身分に
対応していなければならない。

【００４０】 c) 被保証人の所望クラス − 被保証人にこの取引について保証が発行される
ため、或いは、保証対象についてのその他の非公開情報が出されるために、当該
被保証人が満たす必要のある最低要件を特定する情報。

【００４１】 d) 取引点数-保証対象 − 保証対象と彼の銀行(Local Representative 2)には有意なパラメータ。保証対象が、前の点数に１を足すことで増やしてこの点数
を出す。

【００４２】 e) 保証パラメータカテゴリ − 本件取引に適切であると信じられている、Lo
cal Representative 2が保有する情報を識別する。この情報は、保証対象の信用
格付け、産業界での立場、保証対象の履歴に基づく関係情報などの如くのものに
基づいている。

【００４３】 f) 包括範囲制限 − この取引において保証対象が対応する保証範囲の限度。 g) 保証期間 − 保証対象が指定する保証の有効期間。

【００４４】 h) 取引内容カテゴリ(transaction element category) − 本発明による死す
手もの望ましい特徴としては、インフラストラクチャに対して提供される情報を
制限する可能性を持たせることにあり、「取引内容カテゴリ」フィールドは、保証
を裏付けるのに適切な特定の取引に関する限られた情報を提供する手段をなす。

【００４５】 i) フィールド(b)から(h)についての保証対象(Client 2)の署名 − 保証対象
がリストアップした情報のつながりや取引の暗号群(cryptographic hash)に署名
する。取引の暗号群は、メッセージ２のエレメントとして含まれていない点に注
意のこと。暗号群の性質や生成、利用については、前掲のシュナイアー著書を参
照のこと。

【００４６】取引内容カテゴリのフィールドに含まれてもよい情報の一例としては、輸入出
銀行が発行する信用状に対するが如く、保証期間に適切な農産物をカバーするも
のとしての取引の識別があり、保証は商品の軍事利用に影響されやすい。ある場
合では、有意な保証を発行する能力を取引内容において考慮することがある。

【００４７】「保証パラメータカテゴリ」と「保証内容カテゴリ」との違いは、「保証パラメータカテゴリ」のフィールドは保証対象からLocal Representative 2に対する、本取引を支援するために公開される保証対象についての情報を識別する命令である
。この情報で取引が支援されるけれども、これは取引に基づいたものではなく、
保証対象の先行取引の記録を含む保証対象の履歴とステータスに基づくものであ
る。保証発行後の取引の状況を追跡することは、今ここで説明しているシステム
の流れの包括範囲外であることに注意のこと。「取引内容カテゴリ」は取引の性質
と内容に直接関係している。

【００４８】メッセージ３メッセージ３は、被保証人(Client１)がその末端代表者(Local Representativ
e 1)に保証の発行を要請するものである。被保証人からの署名済みメッセージに
は下記の情報が含まれている。

【００４９】 a) 保証対象の識別 − メッセージ２のフィールド(a)と同一。 b) 取引点数被保証人 − 被保証人とその銀行(Local Representative 1)に有
意なパラメータ。被保証人が、前の点数に１を足すことで増やしてこの点数を出
す。

【００５０】 c) 要請のあった包括範囲制限 − 被保証人が所望する保証範囲。 d) 取引の寄せ集め − 被保証人は最終取引契約書のコピーの寄せ集め(hash)
を形成する。この寄せ集めは、メッセージ２のための署名を算出する一部として
保証対象により形成される寄せ集めと同一。 e) 保証対象からのメッセージ２の署名済み部分(即ち、フィールド(b)から(i
))。Local Representative 1は、(e)に含まれる情報で被保証人を特異的に識別できる。

【００５１】 f) 被保証人取引内容説明 − 契約ないし保証が取引に含まれる条件に基づく
ものである場合、被保証人にとって重要な取引のエレメントや被保証人が受け取
る保証の有用性が「被保証人取引内容説明」にリストアップされる。この形の情報
は、取引に伴う交渉時に保証対象から得られた情報に基づいていたものであり、
メッセージ２において保証対象により識別された「取引内容カテゴリ」に関係して
いるものと想定する。これらの被保証人取引内容説明は、メッセージ１内で伝え
られる。これらの説明が取引についての全ての顕著な特徴の正確な要旨を表して
いることを確約することは、被保証人のためになることである。「法的に是認されない」取引の場合では、保証付与が拒否の目に遭うことになる。

【００５２】メッセージ３は、Local Representative 1と被保証人との間のメッセージ及び
/またはその後のメッセージの暗号化/認証の面に対処するように構築されていて
もよい。

【００５３】メッセージ３受取通知(３_ACK) メッセージ３受取通知は、メッセージ３を受け取ったこと、それに、メッセー
ジ３には処理に必要なクライアントからの情報が含まれていることを証明するも
のとして被保証人に対して出される。このメッセージ３受取通知には、Local Re
presentative 1が追加情報なしでは判断できない場合には保証は発行しない旨を
直ちに示すパスも含まれている。斯かる状況の一例としては、保証対象から除外
されているクライアントをリストアップした、Local Representative 1の手許に
あるリスト上のClient 2の身分情報が現れた場合がある。

【００５４】複雑な取引の場合では、被保証人のメッセージ３_ACK受取りとメッセージ６との間の時間間隔は予測できない場合がある。これは、Local Representative 1側
が保証について別途支援(例えば出資者の支援)を必要としていたり、追加情報を
得るために時間を要しているようなことがあり得るからである。大抵の場合では
、このような追加支援では人による検討が必要で、完全自動化はできないようで
ある。できる限り、メッセージ３_ACKで、必要な処理時間の予測値がわかると共に、将来のメッセージに備えて必要な通信とセキュリティが得られるようにする
べきである。特に、Local Representative 1から被保証人に対するメッセージに
あっては、保証対象についての情報を適切に保護するために暗号化が必要である
。言うまでもないことではあるが、被保証人に提供される斯かる情報は受容情報
として扱われるものと期待されている。(被保証人は、彼の待ったんだ意表者との契約の一環としてそうされることに同意しているのである。このことはメッセ
ージ３内で署名済み情報により増長されている。)この構成のメッセージで、可能であれば迅速な回答ができる一方、必要であれば回答を遅らすこともできる。

【００５５】メッセージ４メッセージ４は支援インフラストラクチャに内在するもので、それだからこそ
そのセキュリティは、本明細書では説明しない従来のインフラストラクチャ成分
により確保できるものと想定する。メッセージ４には、保証対象により生成され
たメッセージ２からの成分と、被保証人により生成されたメッセージ３に含まれ
ている生成された取引の寄せ集めとが含まれている。尚、被保証人により生成さ
れた取引の寄せ集めは保証対象により生成された取引の寄せ集めと同一でなけれ
ばならないから、保証対象により生成されたこの情報の署名は正確でなければな
らない。

【００５６】メッセージ４には a) 保証対象からの署名済みメッセージ２と、 b) 識別-保証対象と、 c) 取引点数-被保証人と、 d) 被保証人に関する情報とが含まれている。

【００５７】メッセージ４を受け取ると、Local Representative 2が後述のプロセスを実行
する。先ず、メッセージ２の署名が、保証対処の間違いない署名であることを確認す
るか、または、メッセージの出所を証明する。

【００５８】繰り返されるメッセージの在処を検出するために、データベース２には、各ク
ライアントごとの最近処理したＮ個の取引点数値のリストが蓄えられている。「取引点数-保証対象」がデータベースに含まれておらず、その値がデータベースが
保有する最小取引点数よりも大きければ、メッセージは有効な新要請とは見なさ
れない。

【００５９】メッセージ２からの「被保証人の所望クラス」は、メッセージ４におけるフィー
ルド(d)にある情報と比較される。これは、支援/非支援の判断を行うに当たりLo
cal Representative 2により利用される。

【００６０】保証対象が得られるデータは、もっともな最大保証範囲と全範囲の限度と共に
、その適合性が調べられる。これには、保証についての全ての未決要請とこれら
の要請(同一保証対象が関係する以前の取引についての(後述の)メッセージ８において報告されている)の関連状況が考慮されている必要がある。その結果、支援・非支援の判断に達することができる。

【００６１】取引についての実際の処理は、本発明の対象であるやり取り(exchange)外であ
る。その結果、判断プロセスには、発行されたが、実際は関連取引を終わらせる
には至っていない保証を検討することが含まれていることがある。

【００６２】末端代表者が、本システムのやり取り外で認証し得る彼らのクライアントに関
する知識を利用することが考えられる。一般にシステムは終わりまで取引の条件
全てに従うとは限らないから、これが必要になっている。

【００６３】保証の発行が支援されるのであれば、「データベース取引内容説明」をつくるの
に取引内容カテゴリが使われる。

【００６４】メッセージ５メッセージ５は、支援インフラストラクチャと同一であり、従って、そのセキ
ュリティは、ここでは説明しない従来のインフラストラクチャ成分(infrastruct
ure component)によりなされるものとする。

【００６５】メッセージ５には、 a) 被保証人の識別、 b) 取引点数、被保証人、 c) 支援/非支援判断、 d) 保証パラメータカテゴリにリストアップされている保証パラメータ、 e) 承認されている包括範囲限度(対応なき場合は該当しない) f) データベース取引内容説明(対応なき場合は該当しない)、及び g) 非支援判断の理由(対応なき場合は該当しない)が含まれている。

【００６６】メッセージ５を受け取ると、Local Representative 1が下記のプロセスを行う
。メッセージ５により取引を支援すべきと指示された場合、被保証人取引内容説
明(メッセージ３)とデータベース取引内容説明(メッセージ５)とが比較される。
両者に矛盾があれば保証は発行されない。Local Representative 1が入手する情
報を用いて、保証における該当するパラメータ(例えば期間の如く)を調整しても
よい。

【００６７】メッセージ６メッセージ６は、保証の状況を定めている。保証の発行が承認されたとすると
、保証に伴う費用情報と、保証の受け取り開始に必要な情報並びに保証の購入に
ついての制限事項(購入期限を省く)に関する情報なども提供されることになる。

【００６８】また、メッセージ６で、保証対象の末端代表者(メッセージ５から抽出)が定め
る保証パラメータに基づく報告が提供され、また、データベース取引内容説明( メッセージ５から抽出)に関するもので、被保証人取引内容説明と対照された該当情報も提供される。

【００６９】要件７に従い、保証対象に適切な情報の転送が、メッセージ２に含まれる取引
内容カテゴリと保証パラメータカテゴリとにより規定されるように制限される。

【００７０】尚、メッセージ６は保証ではないが、保証販売のオッファーである。メッセー
ジ６は、不実表示とはならないように構築されている。

【００７１】メッセージ７メッセージ７は被保証人が保証を受け、かつそれに対して支払いをなす旨の合
意である。

【００７２】メッセージ８メッセージ８は、支援インフラストラクチャに内在するものであるから、その
セキュリティは、ここでは説明しない従来のインフラストラクチャ成分により確
保されているものと想定する。

【００７３】このメッセージ８には、下記のフィールドが含まれている。 a) 識別-保証対象 − メッセージ２の情報に基づく、 b) 取引点数 − メッセージ２で明らかにされている、 c) 要請されている保証の発行/非発行状況のステートメントで、Local Repre
sentative 1により生成されると共に、この取引に関係のある要請の最終状況を示すもの、 d) この取引に承認された包括範囲の場合、最終包括範囲値(final coverage
value)

【００７４】これらのフィールドのそれぞれの性質と内容については、前述のメッセージか
ら明らかであろう。

【００７５】メッセージ９メッセージ９は、保証についての署名済みの表示であって、下記のフィールド
が含まれている。 a) 識別-保証対象 − メッセージ２における情報に基づく。 b) 識別-被保証人 − メッセージ２における情報に基づく。 c) 取引点数(データベース２におけるポインターとして識別-保証対象と共に
利用) ― メッセージ３における情報の基づく。 e) 取引の寄せ集め − メッセージ３における情報の基づく。 f) 最終包括範囲値、この取引に承認された包括範囲の場合。 g) 包括範囲の期限、メッセージ２ｇにおいて養成されている期間と一致する
のが普通。

【００７６】これらのフィールドのそれぞれの性質と内容については、前述のメッセージの
説明から明らかであろう。このメッセージ９も、保証パラメータの如くの包括範囲後が、作成時に「正確」
であると保証されているのであれば、この包括範囲の特定の面に関する情報を含
んでおり、この正確性の判定はLocal Representative 1とClient 1と被保証人と
の最初の契約に従う。

【００７７】支援インフラストラクチャへの料金保証が承認されて発行されれば、要請者(本例の場合、被保証人)に対して課金
されることが考えられる。このやり方では、システムにより否定されたか、或い
は、被保証人には承服できない要請に対する料金については定めがないが、シス
テム外のセキュリティ構造に安全度に不足がある場合(例えば、詐欺師が保証対象を装っているとか)での要請に起因して要請者に不適切な料金が課金させるのを防いでいる。料金の回収は、提供されたサービスに対する支払い(保証発行インフラストラクチャの最終過程(backend)と直接接触するクライアントが出す支払い承認を伴って)を整理するLocal Representative 1の能力により可能となる。取引に関わる他のクライアントに対しては課金されることはない。

【００７８】支援インフラストラクチャに料金を支払う重要な方法として考えていないが、
複数のレベルのサービスに対する料金についてはもっと一般的な料金体系で応じ
ることができる。例えば、第１レベルのサービスについては、プロセスがメッセ
ージ３の受け取り通知で終了した場合に料金を伴うものとする。第２レベルのサ
ービスについては、保証を発行することなくメッセージ６でプロセスが終了した
場合に料金を伴うものとする。そして、第３レベルのサービスには要請された保
証の発行が含まれるものとする。

【００７９】また、料金支払いについては、前掲のシュナイアー著書に説明されている如く
に従来公知の電子支払いシステムで行うことが考えられる。

【００８０】特定の例典型的な保証発行プロセスの特定の例を説明する。これから説明する礼は、幾
つか考えられるものの一つに過ぎないものであるが、本発明のシステムの適応性
の一部を代表するものであるのは言うまでもない。本例においては、保証対象と
は、支援インフラストラクチャにはソフトウェアと暗号のプロバイダとして知ら
れているものとする。また、保証対象は米国内の会社で、米国外への暗号技術の
流出について輸出規制の対象になっているものと想定する。本例での被保証人と
は非米国会社であると想定する。

【００８１】保証対象と被保証人との間での取引とは、暗号技術を含むソフトウェアの引き
渡しであるとする。それに、保証対象はペテンにかけようとしているものであり
、そのために米国輸出規制法による認可を得ていないものと想定する。

【００８２】この場合では、保証対象はメッセージ２の「取引内容カテゴリ」にソフトウェア
のカテゴリだけを含ませ、そのソフトウェアには暗号が含まれている事実を含ま
せないものとする。メッセージ３では、被保証人は、「被保証人取引内容説明」に
、取引にとっては重要と思われる全ての記述子が含まれていることを確実にしな
ければならない。ここで、被保証人は暗号技術とソフトウェアとの両方を記述子
として含ませたものと仮定する。

【００８３】すると、メッセージ４にはメッセージ２の取引内容カテゴリが含まれ、メッセ
ージ５で対応するデータベース取引内容説明が返されることになる。メッセージ
５を受信すると、Local Representative 1はメッセージ５における「データベース取引内容説明」とメッセージ３における「被保証人取引内容説明」との間に矛盾があるかどうかをチェックする。本例では、矛盾があれば保証が発行されないも
のとする。

【００８４】尚、被保証人には、メッセージ３における「被保証人取引内容説明」は保護を与
えるに充分なものであると確約する責任がある。被保証人が「被保証人取引内容説明」にソフトウェアだけを含ませたのであれば、保証が発行されることがある。

【００８５】後日になって取引が失敗した場合(恐らくは輸出規制が原因として)、被保証人
は保証についてクレームを出すことが考えられる。このクレームを処理するに当
たり、支援インフラストラクチャが取引全体を得て、その取引が法律に違反して
いること発見し、従って、保証による保護を与えることはできないと判断する。

【００８６】他方では、保証対象がメッセージ２に暗号化「取引内容カテゴリ」を含ませた場
合、メッセージ４における「被保証人に関する情報」と相俟って、Local Represen
tative 2は、本例の場合では被保証人が非米国会社であることから取引には問題
があるものとこれで見つけることができる。

【００８７】尚、本例で問題となっているのは輸出規制があること自体ではなくて、Local
Representative 1とClient 1との間、及び、Local Representative 2とClient 2
との間の契約で定められている保証範囲にまつわる取引の適法性ないし合法性で
ある。実際の保証範囲に関する規定は変わることがある。例えば、包括範囲は、
引き渡される保証パラメータ情報の正確性について保証することを厳密にしてい
るものであったり、或いは、保証対象が行わなければならない実際の取引の履行
について保証しているかもしれない。例えある取引の内容が保証されていたとし
ても、被保証人は、取引を更に続行するのに必要なリソースを拡大すべきだどう
かを判断するのに保証パラメータ情報を利用したがっていることもある。実際の
ところ、メッセージの流れで説明されている全体の保証プロセスは、二人のクラ
イアント間での取引交渉の間に繰り返されることがある。取引内容と保証パラメ
ータカテゴリとを組み込むことで自動化が可能であると共に、アクセス制御とプ
ライバシー要件の処理が捗るのである。

【００８８】本発明の方法の他の例としては、実施権者である製薬会社にモルヒネを販売、
引渡しする場合や、危険廃棄物処理の能力があるものと証明されて認可されてい
るところへ当該危険廃棄物を搬出する場合などがある。

【００８９】支援インフラストラクチャ内での複数クライアント間及び各末端代表者とクラ
イアント間の通信は、既存の演算装置とオペレーティングシステムとを利用して
既存の遠隔通信環境において、或いは、将来の演算装置とオペレーティングシス
テムとを利用して将来の遠隔通信環境において行うことができる。そのような遠
隔通信環境には、現に行われているインターネットや、ダイアルアップ通信ない
し私設ネットワーク通信などが含まれている。演算装置やオペレーティングシス
テムには、ビジネス界や個人の間で広く使われているコンピュータやオペレーテ
ィングシステム(ＰＣ、Ｗｉｎ９５、Ｗｉｎ-ＮＴ)や、銀行が利用している特殊コンピュータシステムなどがある。また、特別仕様ないし専用ハードウェアを利
用することも考えられる。特殊ハードウェアを利用することにはは幾つかの理由
が考えられる。その内の一つとして、システムのセキュリティを高め、、既存の
コンピュータシステムやオペレーティングシステムにある安全度の足りない部分
を補うことにある。他の理由としては、性能、主として暗号化機能を高めること
にある。

【００９０】メッセージ交換の制御は、商用コンピュータで稼働するソフトウェアを含むソ
フトウェアで行うことができ、斯かるソフトウェアは、広く利用されている商用
オペレーティングシステムと互換性があるのが通常である。

【００９１】本発明を実施するのに必要なソフトウェアには下記のものがある。 a) 通信ソフトウェア b) 処理ソフトウェア c) データベースソフトウェア

【００９２】通信ソフトウェアは、沢山ある既存の通信ソフトウェアから選んでもよいが、
その際、ネットワークや通信インターフェースの種類に応じて選ぶべきである。
大方のクライアント側での用途には、市販されているブラウザソフトウェアでも
、必要な通信能力を満たすことができるものと思われる。大抵の場合、本発明を
実施するに当たって利用する現在のところ最新型のコンピュータに既にバンドル
されている通信ソフトウェアを利用してもよい。

【００９３】処理ソフトウェアとしては、市販されている特殊目的用処理ソフトパッケージ
とも言われているカスタムアプリケーションパッケージがある。これらの特殊目
的用処理ソフトパッケージには、コンピュータディスプレに情報を表示するグラ
フィック・ユーザ・インターフェース(ＧＵＩ)ソフトや、本発明が必要とする暗号
化機能を実行できる既存の暗号化ソフトなどが挙げられる。また、斯かる暗号化
ソフトの一例としては、マイクロソフト社が販売している「ＭＳＣＡＰＩ」(商品
名)や、「ＣＤＳＡ」(商標。インテル社のCommon Data Security Architecture)な
どがある。本発明を実施するには、ユーザインターフェースと暗号化機能の統合
及びコンピュータに常駐するデータベースソフトウェアや通信ソフトウェアとの
適切なインターフェースの作製が必要である。

【００９４】それに、クライアント用ソフトウェア開発にソフトウェア設計チームを程良く
投入すること、また、銀行ないし末端代表者用ソフトウェア開発に幾らか多大な
投資が、本発明を実施する準備として必要である。

【００９５】また、残りの本発明を実施するに当たり必要なものにはデータベースがある。
これは、市販されているデータベースソフト製品を利用することで達成できる。
大抵の場合では、コンピュータに適当なデータベースソフト製品が既にバンドル
されている筈である。

【００９６】支持インフラストラクチャの構成部品へのソフトウェアのインストールは、当
該構成部品についてテクニカルサポートを行う情報技術専門家により標準的な手
順に従って行えるものと考えられる。クライアントの場合では、必要なソフトウ
ェアは、ディスクないしＣＤ-ＲＯＭの形で、或いは、例えばインターネットの如くの電子配布システムを利用するとか、幾つかの従来のソフトウェア引渡し方
法を利用してクライアントの末端代表者(銀行)から得られる。

【００９７】ソフトウェアで、ＧＵＩを介してユーザからの指図を受けることができる。必
要なメッセージ構造は、ユーザの指図及びデータベース内の情報に基づいて形成
できる。情報は送受信の間保護されると共に、デジタル署名機能(例えばＤＳＡ、デジタル署名アルゴリズム)、ＲＳＡとして知られている別種のデジタル署名アルゴリズム、或いは、市販されている暗号化ソフトパッケージに含まれている
Elliptic Curve DSA(ECDSA)などを利用してシステムの各所でチェックされる。ＤＳＡとＲＳＡについては、前掲のシュナイアー著書で説明されている。

【００９８】１９９６年１２月１３日にエーセイらが出願をなした米国特許出願第08/767,2
57号で本発明に関係のある開示がなされているので、当該出願を本願明細書に一
部をなすものとしてここに挙げておく。

【図面の簡単な説明】

【図１】本発明による保証発行取引に先立つ段階での考えられる接続形を
示す概略ブロック図。

【図２】本発明による保証発行取引を実行するために考えられる接続形の
概略ブロック図。

【図３】本発明による保証発行取引を実行するために考えられる別の接続
形の概略ブロック図。

【図４】本発明による保証発行取引を示す概略ブロック図。

【符号の説明】 Client 1、Client 2 ・・・・・・・クライアント Local Representative 1、Local Representative 2 ・・・・・・・末端代表者

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者チャールズ・トーマス・モントゴメリーアメリカ合衆国21146メリーランド州セバーナ・パーク、セント・アンドリューズ・ロード63番 (72)発明者マーセル・モーデチェイ・ユンアメリカ合衆国10025ニューヨーク州ニューヨーク、ウエスト・112・ストリート605 番Ｆターム(参考） 3E040 CA11 CA20 CB01

Claims

【特許請求の範囲】

【請求項１】クライアントに対してサービスを提供する組織にめいめいが
関連する複数の場所であって、コンピュータシステムと、該コンピュータシステ
ムと接続されて組織の各クライアントについての情報を蓄積するデータベースと
、前記コンピュータシステムと接続されて、少なくとも一つの前記組織のクライ
アントである当事者のデータ通信装置と通信するデータ通信装置とからなる前記
場所を備えたインフラストラクチャからなるシステムにおいて、データ通信装置
を有する二者の間での取引に関して保証を提供するシステムであって、前記各場
所が、記憶されている情報を他の場所と交わし合う手段と、それぞれの組織のク
ライアントである当事者の少なくとも一方から受けた要請の応答して、また、少
なくとも一つのデータベースに含まれている二人の当事者についての情報と前記
少なくとも一方の当事者から受けた取引の性質に関する情報とに基づいて、前記
取引の当事者の何れかに関する保証を作成する手段とからなるシステム。
【請求項２】クライアントに対してサービスを提供する組織にめいめいが
関連する複数の場所であって、コンピュータシステムと、該コンピュータシステ
ムと接続されて組織の各クライアントについての情報を蓄積するデータベースと
、前記コンピュータシステムと接続されて、少なくとも一つの前記組織のクライ
アントである当事者のデータ通信装置と通信するデータ通信装置とからなる前記
場所を備えたインフラストラクチャからなるシステムにおいて、データ通信装置
を有する二者の間での取引に関して保証を提供する方法であって、対応する組織のクライアントである取引の一方の当事者からその組織に関連す
る場所へ、その取引の他方の当事者を弁別する情報と当該取引の性質に関する情
報とを含む保証要請を伝達し、前記場所と、他方の当事者がクライアントとなっている組織に関連する場所と
の間で情報交換を行い、一方の当事者に対して対応する組織から保証要請に対する回答を伝達すること
よりなる方法。