JP2005166007A - 取引システムおよびその方法 - Google Patents

Abstract

【課題】 受注による将来の確実な収入の見込みなどに基づく信用を、取引における代償の提供能力の証明として利用しうる取引システムを提供する。
【解決手段】 信用取引システム１６においては、発注者４０が受注者４２に発注するときに、与信機関３に対して与信を要求し（１）、この与信が可能である旨の通知（２）が与信機関３から発注者４０に返されると、発注者４０は、受注者４２に対する発注を行い、発注を与信機関３に通知する（３），（４）。発注を受けた受注者４２は、与信機関３に対して、与信の確認を行い（５）、与信が証明されると（６）、受注者４２は、発注者４０から発注を受け、受注を発注者４０に通知する（７）。
【選択図】図６

Description

本発明は、取引における信用を保証する取引システムおよびその方法に関する。

例えば、非特許文献１には、クレジットカードなどの情報を扱うＣＡＦＩＳ(Credit And Finance Information System)が開示されている。
また、特許文献１は、このＣＡＦＩＳを用いた情報管理方法を開示する。
ＣＡＦＩＳによれば、クレジットカード会員の信用情報の蓄積およびその配信などのサービスを行うことができるが、蓄積された会員の信用を、取引における支払い能力の証明として利用することはできない。
http://www.cafis.jp/ 特開２００２−４１７８４号公報

本発明は、上述のような背景からなされたものであり、受注による将来の確実な収入の見込みなどに基づく信用を、取引における代償の提供能力の証明として利用しうる取引システムおよびその方法を提供することを目的とする。

上記目的を達成するために、本発明に係る取引システムは、取引の発注および受注またはこれらのいずれかをそれぞれ行う複数の取引者と、前記取引者の１つ以上と接続され、前記取引者の間の取引をそれぞれ保証する１つ以上の保証者とを含む取引システムであって、前記保証者が複数あるときには、これら複数の保証者は相互に接続され、前記取引は、前記取引を発注する取引者（発注者）から前記取引を受注する取引者（受注者）への代償の提供を少なくとも含み、前記保証者それぞれは、前記接続された取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる見積手段と、前記接続された発注者からの要求に応じて、前記見積もられた代償枠に基づいて、前記取引における発注者の代償提供を保証する保証手段と、前記発注者により発注された取引を受注しようとする受注者からの要求に応じて、この発注者からの要求に応じてなされた取引における保証を確認する確認手段とを有し、前記発注者となりうる取引者は、前記保証者に対して、取引における前記保証を要求する保証要求手段と、前記保証の要求に応じて前記保証がなされた取引を、前記受注者に対して発注する発注手段とを有し、前記受注者となりうる取引者は、受注しようとする取引を発注した発注者と接続された保証者に対して、受注しようとする取引における前記保証の確認を要求する確認要求手段と、前記確認の要求に応じて前記保証が確認された取引を、前記発注者から受注する受注手段とを有する。

好適には、前記保証者および前記取引者は名前空間を構成し、前記名前空間においては、前記取引者それぞれには、前記名前空間における位置の検索に用いられる名前が付され、前記取引者に付された名前の指定を受けて、前記指定された名前が付された取引者の前記名前空間における位置を検索して提供する検索者をさらに有し、前記発注者となりうる取引者は、前記検索者に対して受注者の名前を指定して、前記発注者の位置を検索させ、検索の結果として得られた前記受注者の位置の提供を受ける位置検索手段をさらに有し、前記発注手段は、前記検索の結果として得られた前記発注者の位置を用いて、前記保証がなされた取引を、前記受注者に対して発注する。

好適には、前記保証者は複数であって、前記複数の保証者それぞれと、これらの保証者それぞれに接続された取引者とは、複数の信用名前空間を構成し、少なくとも前記複数の信用名前空間それぞれにおいては、前記取引者それぞれに一意に名前が付され、前記複数の信用名前空間は、相互に接続されて前記名前空間を構成し、前記発注者となりうる取引者の位置検索手段は、同じ前記信用名前空間に前記受注者が含まれないときに、前記検索者に対する前記受注者の位置の検索を行う。

好適には、前記発注者の代償枠の内、前記取引の発注のために前記受注者に提供されるために確保されていた部分を、前記発注者の代償枠から、受注者自身の代償枠に移転する取立者をさらに含む。

好適には、前記保証者は、前記取立者を兼ねる。

好適には、前記見積もられた代償枠の範囲で、前記取引者それぞれに代償を提供する代償提供者をさらに含む。

好適には、前記保証者は、前記代償提供者を兼ねる。

好適には、前記保証者の見積手段は、前記発注者となりうる取引者が、前記受注者として提供されうる代償に基づいて、前記取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる。

好適には、前記保証者は、前記発注者に接続され、前記発注者による要求に応じて、この発注者により発注された取引を保証する１つ以上の第１の保証者と、前記受注者と前記第１の保証者とに接続され、前記受注者による要求に応じて、この受注者により受注されようとする取引を保証する１つ以上の第２の保証者とを含み、前記第１の保証者それぞれにおいて、前記保証手段は、前記接続された発注者から、その実施に対して対価を支払うべき要求を受けて、前記見積もられた代償枠に基づいて、前記発注者に対して、前記代償提供を保証し、前記接続された第２の保証者から、その実施に対して対価を支払うべき要求を受けて、前記見積もられた代償枠に基づいて、前記第２の保証者に対して、前記代償提供を保証し、前記第２の保証者それぞれにおいて、前記確認手段は、前記接続された受注者からの要求に応じて、その実施に対して対価を支払うべき要求を出して、前記接続された第１の保証者に対して、前記代償提供の保証を要求し、前記第１の保証者による代償提供の保証に基づいて、前記受注されようとする取引の保証を、前記受注者に対して確認し、前記発注者となりうる取引者において、前記保証要求手段は、前記第１の保証者に対して、取引における前記保証を要求し、前記受注者となりうる取引者において、前記確認要求手段は、前記第２の保証者に対して、受注しようとする取引における前記保証の確認を要求する。

好適には、前記第１の保証者において、前記保証手段は、前記要求を受けると、前記発注者からの取引の発注を、前記受注者に対して確認し、前記発注者に対する代償提供の保証を行う。

好適には、前記受注者となりうる取引者において、前記確認要求手段は、前記第２の保証者に対して融資を要求し、前記第２の保証者それぞれにおいて、前記確認手段は、前記第１の保証者による代償提供の保証に基づいて、前記受注者となりうる保証者に対して、前記要求された融資を行う。

好適には、前記発注者となりうる取引者は、前記保証者に対して、前記代償枠の見積に用いられ得る見積情報を開示する情報開示手段をさらに有し、前記保証者の見積手段は、前記開示された情報にさらに基づいて、前記取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる。

好適には、前記発注者となりうる取引者の情報開示手段は、前記見積情報として、他の取引者との間の取引の状態を示す情報、前記他の取引者との間の取引の状態を裏付ける情報、前記受注者に対する代償の提供能力を裏付ける情報、および、前記受注者に対する代償の提供能力を担保する情報、またはこれらの内の１つ以上の組み合わせを開示する。

好適には、前記取引の状態を示す情報には、前記受注者として受注した取引において提供される代償、前記受注者として受注した取引を発注した取引者、前記発注者として発注した取引において提供する代償、および、前記発注者として発注した取引受注した取引者、前記取引を識別する符号、またはこれらの内の１つ以上の組み合わせが含まれる。

好適には、前記保証者は、前記取引を識別する符号に基づいて、取引システムで一意な取引識別子を作成する取引識別子作成手段をさらに含む。

好適には、前記取引は、前記作成された取引識別子により識別される。

好適には、前記保証者は、前記取引における保証の要求および確認またはこれらのいずれかを行ったときに、前記要求および確認またはこれらのいずれかを行った取引者に対して課金する第１の課金手段をさらに有する。

好適には、前記保証者は、前記取引における保証の要求および確認またはこれらのいずれかを行ったときに、前記要求および確認またはこれらのいずれかを行った取引者に対して、前記見積情報の開示の度合いに応じた額を課金する第２の課金手段
をさらに有する。

好適には、前記代償は、通貨である。

好適には、前記代償は、物である。

好適には、前記代償は、通貨または物を将来取得する権利である。

また、本発明に係る保証装置は、取引の発注および受注またはこれらのいずれかをそれぞれ行う複数の取引者の１つ以上と接続され、前記取引者の間の取引をそれぞれ保証する保証装置であって、前記保証装置は、他に前記保証装置があるときには、この他の保証装置と接続され、前記取引は、前記取引を発注する取引者（発注者）から前記取引を受注する取引者（受注者）への代償の提供を少なくとも含み、前記発注者となりうる取引者は、前記保証装置に対して、取引における前記保証を要求し、前記保証の要求に応じて前記保証がなされた取引を、前記受注者に対して発注し、前記受注者となりうる取引者は、受注しようとする取引を発注した発注者と接続された保証装置に対して、受注しようとする取引における前記保証の確認を要求し、前記確認の要求に応じて前記保証が確認された取引を、前記発注者から受注し、前記接続された取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる見積手段と、前記接続された発注者からの要求に応じて、前記見積もられた代償枠に基づいて、前記取引における発注者の代償提供を保証する保証手段と、前記発注者により発注された取引を受注しようとする受注者からの要求に応じて、この発注者からの要求に応じてなされた取引における保証を確認する確認手段とを有する。

また、本発明に係る取引装置は、取引の発注および受注またはこれらのいずれかを行う取引装置であって、前記取引は、前記取引を発注する取引装置（発注者）から前記取引を受注する取引装置（受注者）への代償の提供を少なくとも含み、前記取引装置の間の取引を保証する１つ以上の保証者それぞれは、前記取引装置の１つ以上と接続され、前記保証者が複数あるときには、これら複数の保証者は相互に接続され、前記接続された取引装置それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もり、前記接続された発注者からの要求に応じて、前記見積もられた代償枠に基づいて、前記取引における発注者の代償提供を保証し、前記発注者により発注された取引を受注しようとする受注者からの要求に応じて、この発注者からの要求に応じてなされた取引における保証を確認し、前記発注者となりうる取引装置は、前記保証者に対して、取引における前記保証を要求する保証要求手段と、前記保証の要求に応じて前記保証がなされた取引を、前記受注者に対して発注する発注手段とを有し、前記受注者となりうる取引装置は、受注しようとする取引を発注した発注者と接続された保証者に対して、受注しようとする取引における前記保証の確認を要求する確認要求手段と、前記確認の要求に応じて前記保証が確認された取引を、前記発注者から受注する受注手段とを有する。

また、本発明に係る取引方法は、取引の発注および受注またはこれらのいずれかをそれぞれ行う複数の取引者と、前記取引者の１つ以上と接続され、前記取引者の間の取引をそれぞれ保証する１つ以上の保証者とによる取引方法であって、前記保証者が複数あるときには、これら複数の保証者は相互に接続され、前記取引は、前記取引を発注する取引者（発注者）から前記取引を受注する取引者（受注者）への代償の提供を少なくとも含み、
前記保証者それぞれは、前記接続された取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もり、前記接続された発注者からの要求に応じて、前記見積もられた代償枠に基づいて、前記取引における発注者の代償提供を保証し、前記発注者により発注された取引を受注しようとする受注者からの要求に応じて、この発注者からの要求に応じてなされた取引における保証を確認し、前記発注者となりうる取引者は、前記保証者に対して、取引における前記保証を要求し、前記保証の要求に応じて前記保証がなされた取引を、前記受注者に対して発注し、前記受注者となりうる取引者は、受注しようとする取引を発注した発注者と接続された保証者に対して、受注しようとする取引における前記保証の確認を要求し、前記確認の要求に応じて前記保証が確認された取引を、前記発注者から受注する。

また、本発明に係る第１のプログラムは、取引の発注および受注またはこれらのいずれかをそれぞれ行う複数の取引者の１つ以上と接続され、前記取引者の間の取引をそれぞれ保証する保証装置におけるプログラムであって、前記保証装置は、他に前記保証装置があるときには、この他の保証装置と接続され、前記取引は、前記取引を発注する取引者（発注者）から前記取引を受注する取引者（受注者）への代償の提供を少なくとも含み、前記発注者となりうる取引者は、前記保証装置に対して、取引における前記保証を要求し、前記保証の要求に応じて前記保証がなされた取引を、前記受注者に対して発注し、前記受注者となりうる取引者は、受注しようとする取引を発注した発注者と接続された保証装置に対して、受注しようとする取引における前記保証の確認を要求し、前記確認の要求に応じて前記保証が確認された取引を、前記発注者から受注し、前記接続された取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる見積ステップと、前記接続された発注者からの要求に応じて、前記見積もられた代償枠に基づいて、前記取引における発注者の代償提供を保証する保証ステップと、前記発注者により発注された取引を受注しようとする受注者からの要求に応じて、この発注者からの要求に応じてなされた取引における保証を確認する確認ステップとをコンピュータに実行させる。

また、本発明に係る第２のプログラムは、取引の発注および受注またはこれらのいずれかを行う取引装置におけるプログラムであって、前記取引は、前記取引を発注する取引装置（発注者）から前記取引を受注する取引装置（受注者）への代償の提供を少なくとも含み、前記取引装置の間の取引を保証する１つ以上の保証者それぞれは、前記取引装置の１つ以上と接続され、前記保証者が複数あるときには、これら複数の保証者は相互に接続され、前記接続された取引装置それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もり、前記接続された発注者からの要求に応じて、前記見積もられた代償枠に基づいて、前記取引における発注者の代償提供を保証し、前記発注者により発注された取引を受注しようとする受注者からの要求に応じて、この発注者からの要求に応じてなされた取引における保証を確認し、前記発注者となりうる取引装置において、前記保証者に対して、取引における前記保証を要求する保証要求ステップと、前記保証の要求に応じて前記保証がなされた取引を、前記受注者に対して発注する発注ステップとをコンピュータに実行させ、前記受注者となりうる取引装置において、受注しようとする取引を発注した発注者と接続された保証者に対して、受注しようとする取引における前記保証の確認を要求する確認要求ステップと、前記確認の要求に応じて前記保証が確認された取引を、前記発注者から受注する受注ステップとをコンピュータに実行させる。

本発明によれば、受注による将来の確実な収入の見込みなどに基づく信用を、取引における支払い能力の証明として利用することができる。

［本発明の概要］
図１は、本発明の前提となる取引を例示する図である。
図１に示すように、従来から、複数の企業Ｙ１〜Ｙ４の間で発注およびその受注が行われ、取引がなされてきた。
つまり、図１には、まず、資金量＄Ａ（＄は米ドル）の企業Ｙ１が、＄Ｂの製品を、企業Ｙ２に対して発注し、次に、この発注を受けた企業Ｙ２が、＄Ｃの部品を企業Ｙ３に対して発注し、さらに、この発注を受けた企業Ｙ３が、＄Ｄの原料を企業Ｙ４に対して発注する例が示されている。

図１に示す場合においては、企業Ｙ１の発注に起因する一連の取引においては、発注額は＄Ａ＞＄Ｂ＞＄Ｃ＞＄Ｄとなる。
ここで、一般に、発注から対価の支払いまでには時間差があるので、企業Ｙ４が、原料を購入する代金＄Ｅ（＄Ｄ＞＄Ｅ）を、銀行などの金融機関Ｚから借り入れようとしても、常に、金融機関Ｚが企業Ｙ４に、資金を貸すかどうかは定かではない。
金融機関Ｚが、企業Ｙ４に資金を貸さなかったときには、企業Ｙ４は、資金繰りに行き詰まりかねない。

企業Ｙ１〜Ｙ３の業務および財務が健全で、十分な支払い能力があるときには、企業Ｙ４が原料を納品した後、企業Ｙ３から企業Ｙ４に、代金＄Ｄが支払われることは、ほぼ確実である。
しかしながら、一般に、金融機関Ｚが、企業Ｙ４に資金を貸すか否かは、企業Ｙ４と金融機関Ｚとの間の取引実績などにより判断されてきたので、企業Ｙ４が、将来に、ほぼ確実に得る収入が、金融機関Ｚの判断の材料として用いられることは、今までなかった。

つまり、このようなときには、金融機関Ｚは、企業Ｙ４が返済可能であるという保証を得ることができないために、企業Ｙ４に資金を貸さないということになりかねない。
この結果として、企業Ｙ４は、最悪の場合には、借りた資金を確実に返済可能であるという裏付けを持っているにもかかわらず、資金繰りに行き詰まってしまう。
本発明に係る取引方法は、このような従来の取引における不合理を解消することができるものであって、企業の発注、受注、発注および受注の相手企業（取引の状態を示す情報）、生産、在庫および物流などの状態（取引の状態を裏付ける情報）、財務状態（代償の提供能力を裏付ける情報）および担保の有無（代償の提供能力を担保する情報）などに基づいて与信を行うことにより、企業間における信用に基づく取引を実現する。

［信用取引システムの概要］
次に、本発明に係る信用取引システムの概要を説明する。

［基本要素］
本発明にかかる信用取引システムの基本要素は、以下の（１）〜（３）である。
（１）取引信用の保証
（２）保証のための根拠の開示
（３）取立て

［特徴］
本発明に係る信用取引システムは、下記（１）〜（４）に示すような特徴を有する。
（１）有効な管理範囲が明確な信用が、連鎖的に連続利用される。
（２）保証されるものは、その時点で存在する財（代償）ばかりではなく、将来の収入、および、得られる財（代償）をも含む。

（３）取引の信用のもととなる代償（財）を正確に確保し、管理するため、本発明に係る信用取引システムは、保証に関わった全ての取引自体を識別し、管理する。
これにより、信用として連鎖的に複数回使用された代償の所有者とオリジナルの根拠との整合性が正確に保たれるので、識別不能なキャッシュの総額よりも確実に、取引に起因する信用が管理されうる。

（４）取引信用を保証する与信機関は、複数存在するが、信用の評価はそれぞれ閉じている。
取引に起因して増殖可能な信用や財は、各与信機関の内部でのみ、管理され、統一された価値基準をもつ。
これは、各与信与信機関が信用保証のために代償を管理保持し、各個別の企業間取引に役立てているためである。
異なる与信機関で信用枠を管理されている企業間では、他の与信機関に直接、取引信用を依頼せずに通常通りの信用保証依頼を出し、この与信機関が相手方の与信機関と取引リスクを交換する。
これら関連する２つの与信機関の間での価値の落差は、今回使用できる取引信用枠の大きさ（額）や、取引情報を用いたリスク計算により手当てされる。

［信用取引システムの構成およびその処理］
以下、本発明に係る信用取引システムの構成およびその処理を説明する。

図２は、本発明に係る第１の信用取引システム１０を例示する図である。
図２に示すように、信用取引システム１０は、１つ以上の与信機関Ｘ（保証者；図２には、与信機関Ｘ１〜Ｘ３’を例示）、複数の企業（取引者；図２には、企業Ｙ１〜Ｙ４’を例示）、および、銀行などの１つ以上の金融機関Ｚ（与信機関Ｘが金融機関Ｚを兼ねてもよい）が、ネットワーク（図２には図示せず）を介して接続されて構成される。
なお、以下、取引の主体を企業と記すが、取引の主体は、必ずしも企業に限られず、個人であったり、国・地方自治体であったりしてもよい。

さらに、信用取引システム１０には、必要に応じて、与信機関Ｘ、企業Ｙおよび金融機関Ｚの間で認証を行うディレクトリ管理・認証機関Ｗが追加される。
信用取引システム１０においては、与信機関Ｘが、企業Ｙの信用を保証することにより、企業Ｙ間の信用に基づく取引、および、金融機関Ｚによる企業Ｙへの信用に基づく資金の貸し付けなどが行えるようになっている。

図３は、図２に示した企業Ｙ１〜Ｙ４に設定される信用枠を例示する図である。
信用取引システム１０における取引をさらに説明する。
例えば、企業Ｙ１に対しては、他の企業Ｙからの受注額、他の企業からの支払いの確実性、企業Ｙ１の資金量、企業Ｙ１が与信機関Ｘに対して提出した担保、他の企業Ｙおよび金融機関Ｚとの取引実績などに基づいて、図３に示すように、＄Ａの信用枠（代償枠）が、与信機関Ｘにより設定されている。

つまり、この信用枠＄Ａは、企業Ｙ１の資金量だけでなく、将来、確実に企業Ｙ１が得る収入、および、企業Ｙ１が、それまでの取引において積み上げた信用などが見込まれており、与信機関Ｘが、企業Ｙ１に対して、信用枠＄Ａを限度として信用を保証するということを示している。
なお、信用枠は、通貨を単位として設定される以外に、市場性を有する物（鉱工業産物・農産物など）を単位として設定されてもよいが、以下、特記なき限り、信用枠が通貨を単位として設定される場合を具体例とする。

信用取引システム１０において、例えば、企業Ｙ１が、企業Ｙ２に対して＄Ｂの発注を行うときには、まず、企業Ｙ１は、与信機関Ｘ１に対して、＄Ｂ（＄Ａ＞＄Ｂ）の支払い能力があることについて、与信を要求する。
与信機関Ｘ１は、上記信用枠＄Ａ、および、企業Ｙ１が与信機関Ｘ１に開示している開示情報（見積情報）に基づいて、企業Ｙ１に対する＄Ｂの与信が可能であるか否かを判断し、与信が可能なときには、その旨を通知する。

この開示情報には、上述のように、企業Ｙ１の発注、受注、発注および受注の相手企業、生産、在庫および物流などの状態、財務状態および担保の有無などを示す情報が含まれている。
また、企業Ｙ１の発注、受注および発注・受注の相手企業を示す情報などには、図２に明示されていない他の取引についての情報も含まれている（他の企業および与信機関についても同様）。

この与信可能な旨の通知を受けた企業Ｙ１は、企業Ｙ２に対して＄Ｂの発注を行い、発注を行った旨を与信機関Ｘ１に通知する。
＄Ｂの発注を受けた企業Ｙ２は、与信機関Ｘ１に、発注された取引に関して、企業Ｙ１に対して＄Ｂの与信を行ったことの確認を要求する。
与信機関Ｘ１が、企業Ｙ１に対する与信を証明すると、企業Ｙ２は、企業Ｙ１からの＄Ｂの発注を受ける。
つまり、企業Ｙ２から見ると、企業Ｙ２に対しては、この受注により、＄Ｂ分の信用が新たに追加されたことになる。

与信機関Ｘ１と、他の与信機関Ｘ２〜Ｘ３’との間では、各企業Ｙ１〜Ｙ４’それぞれの信用枠が相互に取引されており、例えば、企業Ｙ２が、与信機関Ｘ２に対して、＄Ｃ（例えば、＄Ｃ＜＄Ｂ）分の与信を要求すると、与信機関Ｘ２は、与信機関Ｘ１から、企業Ｙ２について、図２に示すように、＄Ｃ分の信用枠を得る。
与信機関Ｘ２は、上記信用枠＄Ｃ、および、企業Ｙ２の開示情報に基づいて、企業Ｙ２に対する＄Ｃの与信が可能であるか否かを判断し、与信が可能なときには、その旨を通知する。

この与信可能な旨の通知を受けた企業Ｙ２は、企業Ｙ３に対して＄Ｃの発注を行い、発注を行った旨を与信機関Ｘ２に通知する。
＄Ｃの発注を受けた企業Ｙ３は、与信機関Ｘ２に、発注された取引に関して、企業Ｙ２に対して＄Ｃの与信を行ったことの確認を要求する。

なお、企業Ｙ３が与信確認を要求すべき与信機関を見いだすにあたっては、例えば、下記（１）〜（３）に示すような様々な方法を採ることができる。
（１）企業Ｙ２が、企業Ｙ３に、いずれの与信機関に対して与信確認を行うべきかを予め通知する。
（２）企業Ｙ２が、企業Ｙ３に、確認先与信機関を指示する情報を、発注情報に付加して通知する、
（３）企業Ｙ２からの発注情報に含まれ、個々の発注を識別するために用いられるコードにより、確認先与信機関を検索するためのサーバをネットワーク上に設置する。
（４）あるいは、企業Ｙ３が、契約を結んでいる与信機関Ｘ３に対して、企業Ｙ２からの発注情報またはその一部を送り、与信機関Ｘ３が、送られてきた情報中に入っている信用取引システム１０全体で一意な取引識別子（取引ＩＤ）に基づき、その名前空間から認証者（認証を与えた与信機関）を特定する。
なお、取引ＩＤ、名前空間やその管理などについては別途説明する。

与信機関Ｘ２が、企業Ｙ２に対する与信を証明すると、企業Ｙ３は、企業Ｙ２からの＄Ｃの発注を受ける。
図２に例示する通り、以下同様に、企業Ｙ１〜Ｙ４の間で、これらの信用に基づいて、それぞれ取引額＄Ｂ〜＄Ｄの取引が行われる。

例えば、企業Ｙ３から＄Ｄの発注を受けた企業Ｙ４が、金融機関Ｚから、受注に要する資金＄Ｅ（例えば、＄Ｅ＜＄Ｄ）を得ようとするときには、まず、企業Ｙ４は、与信機関Ｘ３に対して、＄Ｅ分の与信を要求する。
与信機関Ｘ３は、企業Ｙ４の信用枠（例えば＄Ｄ；図３）などに基づいて、企業Ｙ４に対する＄Ｅの与信が可能であるか否かを判断し、与信が可能なときには、その旨を通知する。

この与信可能な旨の通知を受けた企業Ｙ４は、金融機関Ｚに対して＄Ｅの資金借り入れを要求し、この要求を行った旨を与信機関Ｘ３に通知する。
＄Ｅの資金借り入れの要求を受けると、金融機関Ｚは、与信機関Ｘ３から、企業Ｙ４に対する＄Ｅの与信を受けて、企業Ｙ４に対して、資金＄Ｅの貸し付けを行う。
つまり、企業Ｙ４は、これから確実に得られると保証された企業Ｙ３からの収入＄Ｄ（信用）に基づいて、金融機関Ｚから＄Ｅの資金の借り入れができたことになる。

このように、図２に示した信用取引システム１０においては、図１に示した従来からの取引方法における不具合が解消されている。
なお、与信機関Ｘは、企業Ｙの信用を支える必要があるので、国・地方自治体、銀行などの金融機関、あるいは、資産が豊富な大企業であることが望ましい。
また、図２に示すように、信用取引システム１０においては、信用は、企業Ｙ１から企業Ｙ４および金融機関Ｚの方向に移動し、企業Ｙ間の取引対象の商品・サービスなどは、企業Ｙ４および金融機関Ｚから、企業Ｙ１の方向に移動する。

図４は、本発明に係る第２の信用取引システム１２を例示する図である。
既に述べたように、図２に示した第１の信用取引システム１０においては、企業Ｙ４は、与信機関Ｙ３に対して与信を要求し、金融機関Ｚに対して資金を要求して、資金を借り入れるようになっている。
これに対して、図４に示す信用取引システム１２においては、企業Ｙ４は、与信機関Ｙ３に対して資金を要求し、与信機関Ｙ３から小切手などの引換証を得て、これを資金と引き替えるようになっている。
図４に示すように、与信機関Ｙと金融機関Ｚとの間で、信用枠の取引がなくても、本発明に係る信用取引システムが応用されうる。

図５は、本発明に係る第３の信用取引システム１４を例示する図である。
図５に示すように、第３の信用取引システム１４においては、取引の代償として、例えば、石油の所有権、占有権、またはそれらの予約権（記載の明確化のために、以下、これらを「石油」と総称する；単位バレル）が移転される。
このように、本発明に係る信用取引システムは、取引の代償として通貨が移転されるときだけでなく、取引の代償として物が移転される（企業間で対象物を物理的に運搬する場合だけでなく、対象物は倉庫内や移動する船舶等の中にそのまま置かれた状態で、例えば、その所有権だけが移動する場合も含む）ときに応用されうる。

なお、図５に示すように、信用取引システム１４においては、信用（石油）は、企業Ｙ１から企業Ｙ４および商社（石油元売り会社）Ｚの方向に移動し、企業Ｙ間の取引対象（石油その他の商品・サービス）もまた、企業Ｙ１から企業Ｙ４および商社（石油元売り会社）Ｚの方向に移動する。
つまり、信用の根拠を、通貨ではなく上述の権利においた場合には、Ｚは金融機関ではなく、その権利の対象となる商品を取り扱う商社などになる。
以下、特に断らない限り、本発明に係る信用取引システムにおいて、取引対象の代償（対価）として通貨が移転される（支払われる）場合を具体例として説明する。

［取引ＩＤを用いた取引の識別］
与信機関Ｘは、図２〜図５に示した取引それぞれに、一意な取引ＩＤを付して管理する。
つまり、例えば、与信機関Ｘ１は、企業Ｘ１から与信の要求を受けたときに、企業Ｘ１が、企業Ｘ２への発注に付した企業Ｘ１内において一意な発注番号などの局所的に一意の任意に構成された符号に、全与信機関を通じて企業Ｘ１に対して一意に付された識別子を付して、取引ＩＤとする。
この取引ＩＤは信用取引システム全体で当該特定の取引を他の取引と区別する一意性が保証されるように作成され、企業Ｙ１，Ｙ２間の取引を、他の取引から区別するために用いられる。

取引ＩＤは、その属性として、有効期間を含むことができ、この場合には、信用取引システムにおいては、有効期限内の取引ＩＤが示す企業間の取引のみが、有効な取引として取り扱われうる。
取引ＩＤが付された企業間の取引は、それぞれ個別にその内容（発注者、受注者、取引の対象物および取引額など）が管理されうる。
このようにして、企業間の取引に取引ＩＤを付加して管理することにより、例えば、企業倒産が発生したときに、取引ＩＤに対応する債権を、一般債権から分離された特定債権として取り扱うことができるので、取引の安全性が高まる。

［企業Ｙから与信機関Ｘへの情報開示］
図２〜図５に示した信用取引システムにおいては、企業Ｙから与信機関Ｚへの情報開示が必要となる。
例えば、図２に示した企業Ｙ１，Ｙ２間の取引においては、企業Ｙ１は、企業Ｙ２に対する発注を与信機関Ｘ１に通知するときに、その取引相手（ここでは企業Ｙ２）と、発注額などを、与信機関Ｘ１に対して開示する。
同様に、企業Ｙ２が、与信機関Ｘ１に対して与信の確認をするときには、その取引相手（ここではＹ１）とその額、および、与信対象取引と対応を取るために与信機関側で使用するための当該発注の識別情報などを、与信機関Ｘ１に対して開示する。

また、下記の信用枠の設定などのために、企業Ｙは、例えば、与信機関Ｘだけにではなく、一般に開示すべき財務情報を、与信機関Ｘに開示する。
さらに、企業Ｙは、財務情報を裏付ける経営情報、財務情報、在庫情報、製造（工程）情報、物流情報および取引先の情報などを、与信機関Ｘに開示する。

上述のように、企業Ｙと与信機関Ｘとの間は、ネットワークにより接続されているので、これらの情報を、必要に応じて、あるいは、一定期間ごとに、企業Ｙが与信機関Ｘに開示するようにすると、与信枠の設定に用いられる情報の信頼性が増す。
企業Ｙが、与信機関Ｘに、どのような種類の情報を、どのような頻度で、どのような方法で開示するかは、例えば、企業Ｙと与信機関Ｘとの間の契約に従って行われる。

企業Ｙから与信機関Ｘへの情報の開示は、例えば、企業Ｙが、ＥＲＰ(Enterprise Resource Planning)などと呼ばれ、財務管理、発注管理、受注管理、在庫管理、製造（工程）管理および物流管理などを統合したシステムを用いているときには、容易に実現され得る。
つまり、企業Ｙ側に、ＥＲＰシステムから、契約に従って、必要な情報を、必要な頻度で取り出し、与信機関Ｘが処理しうる形式に変換して、与信機関Ｘに開示する処理を行うソフトウェアを、ＥＲＰシステムに付加することにより、企業Ｙから与信機関Ｘへの契約に従った情報開示が実現される。

［信用枠の設定］
企業Ｙに設定される信用枠は、例えば、企業Ｙが、他の企業から支払いを受ける予定となっている対価（将来、対価を取得する権利）の総計と、企業Ｙの可処分資産と、企業Ｙが、与信機関Ｙに提出した担保との総額となる。
このように計算される総額は、企業Ｙの事業が拡大しているか否か、企業Ｙの経営および財務などが健全か否か、および、企業Ｙに対価を支払う取引先の経営および財務などが健全か否かなどによって増減されて信用枠とされる。

さらに、信用枠は、企業Ｙが与信機関Ｚにどの程度の情報を開示しているかに応じて増減されうる。
例えば、企業Ｙが、信用枠を裏付ける情報を、より多くの種類および頻繁で、与信機関Ｚに開示すればするほど、その信用枠は増やされる。
反対に、例えば、企業Ｙが、与信機関Ｚにこのような情報を、より少ない種類および頻度で開示すればするほど、その信用枠は減らされる。

なお、企業Ｙに設定される信用枠は、企業Ｙが複数の与信機関Ｘから与信を受けるときには、これら複数の与信機関の間で分割され得る。
また、企業Ｙに設定される信用枠は、企業Ｙが発注側となり、他の企業に対する対価の支払い義務が生じたときには、その対価の分だけ減少する。
また、企業Ｙに設定される信用枠は、企業Ｙが受注側となり、他の企業から対価を受ける権利が生じたときには、その対価の分だけ増加する。

［課金］
与信機関Ｘは、企業Ｙに対して、取引において与信を行うたびに課金を行う。
この課金は、手数料であっても、利息であってもよく、その名目は特に問われない。
万一、企業Ｙが、与信機関Ｘが与信したにもかかわらず、取引先に損害を与えたときには、与信機関Ｘが、その損害を保証するので、課金額は、信用枠と同様に、企業Ｙが、他の企業から支払いを受ける予定となっている対価の総計と、企業Ｙの可処分資産と、企業Ｙが、与信機関Ｙに提出した担保との総額などに応じて設定される。
つまり、例えば、企業Ｙのこの総額が多いときには、企業Ｙには多くの信用があると考えられるので課金額は少なく設定され、この反対に、この総額が少ないときには、課金額は多く設定される。

さらに、課金額は、企業Ｙが与信機関Ｘに対して開示する情報の種類および頻度によっても増減されうる。
つまり、例えば、企業Ｙが与信機関Ｘに対して、より多くの種類の情報を、より多い頻度で提供すればするほど、その内容に応じて課金額が少なく設定され、反対に、企業Ｙが与信機関Ｘに対して、より少ない種類の情報を、より少ない頻度で提供すればするほど、その内容に応じて課金額が多く設定される。

［取立て］
取引の最終段階として取立て（精算）が行われる。
取り立ては、受注者（売り手）と発注者（買い手）との間の信用枠の移動によって行われる。
取り立てによる信用枠の移動は、発注者の信用枠のうちで発注のために使用したことによって、当該発注のために確保されていた部分を発注者の信用枠から取立て、受注者自身の与信枠として確定させることにより行われる。

例えば、他の連鎖では充分な収入を得る受注者になっているような場合を除くと、企業Ｙ１のような発注−受注の連鎖における最初の発注者は、最終的には、自分が使った信用枠を相殺する金額を、予め与信機関との間で定めておいた期間内に指定されていた銀行口座へ振り込むなどして、与信機関に対して通貨で支払うという形態で取り立てをおこなう必要がある。
つまり、最初の発注者Ｙ１はその信用の根拠として、与信された金額をある期日に与信機関へ支払うという契約を与信機関と予め締結しておく。
このようにして、与信機関は本信用取引システム内の信用枠の移動だけでは決済できない負債については、発注者から通貨で取立てることができる。
また、最初の発注者でなくとも、例えば充分な信用力があったり、あるいは、充分な担保を差し入れておいたりすれば、使用した信用枠の一部を与信機関が所定期日後に通貨の形で取り立てることで決済を行うようにすることもできる。

また、代償が通貨ではなく図５に例示したように石油などの物である場合、その物の最終的な移行を保証するため、積み荷や倉庫中の物の所有権およびそれに付随した現物の差し押さえなどの権限を、当該与信機関が保持しておくことができる。
これにより、万一最終的な移行が期日までに行われなかった場合にはこの差し押さえの権限を行使することによって取立てを行うことができる。

本信用取引システム内では多数の発注および受注が行われ得るので、従って個々の発注、受注に伴う支払いや入金確認も膨大な件数になる。
図１に示した従来の取引方法においては、このような個々の支払いは個別に行われたり、高々、相手先企業別にまとめて行なわれたりする。

本発明に係る信用取引システムを使用することにより、それぞれの企業間毎にその締め日における全ての入金と全ての支払いを全てまとめて相互に相殺し、正味入金あるいは正味支払いを算出することが簡単に実現できる。
このようにすると、従来のような個別の支払いや入金確認に伴う金融機関への手数料や作業工数を大幅に削減することができる。

［認証および改ざん防止］
与信機関Ｘ、企業Ｙおよび金融機関Ｚ（図５においては商社（石油元売り会社）であるが、以下では金融機関で代表させる）の間の通信の安全性を保つために、これらの間の通信には、認証処理および改ざん防止処理が必要とされる。
本発明に係る信用取引システムにおける与信機関Ｘ、企業Ｙおよび金融機関Ｚの間の通信に適応される認証処理および改ざん防止処理は、例えば、公開鍵および秘密鍵を用いた暗号化など、既存の方法の応用により実現されうる。
図２〜図５に示したように、この認証および改ざん防止のための処理は、与信機関Ｘ、企業Ｙおよび金融機関Ｚそれぞれにより行なわれるほか、これらから独立して別途、設けられたディレクトリ管理・認証機関Ｗによっても行われうる。

［第１実施形態］
以下、本発明の第１の実施形態を説明する。

［第４の信用取引システム１６］
図６は、モデル化された本発明に係る第４の信用取引システム１６を示す第１の図である。
図２，図４に示した信用取引システム１０，１２を、企業Ｙ１，Ｙ２間の取引および企業Ｙ１，Ｙ２と与信機関Ｘ１との間のトランザクションに着目してモデル化すると、図６に示す信用取引システム１６を得ることができる。
図６に示すように、信用取引システム１６は、与信機関Ｘ１（以下、与信機関３とも記す）、および、発注側の企業（発注者）Ｙ１および受注側の企業（受注者）Ｙ２（以下、発注者４０，受注者４２とも記す）が、インターネットあるいは専用通信回線などのネットワーク１６０を介して接続されて構成される。

信用取引システム１６には、さらに、例えばＬＤＡＰ(Lightweight Directory Access Protocol)方式により、ネットワーク１６０に接続されたノードのディレクトリ管理を行い、また、公開鍵暗号方式（ＰＫＩ）により各ノードを認証するためのディレクトリ管理・認証機関４４が付加される。
なお、以下、与信機関３、発注者４０、受注者４２およびディレクトリ管理・認証機関４４およびそのコンピュータ（図７など）を総称して、ノードとも記す。

信用取引システム１６においては、既に図２などを参照して説明したように、発注者４０が受注者４２に発注するときに、与信機関３に対して与信を要求し（１）、この与信が可能である旨の通知が与信機関３から発注者４０に返されると（２）、発注者４０は、受注者４２に対する発注を行い、発注を与信機関３に通知する（３），（４）。
発注を受けた受注者４２は、与信機関３に対して、与信の確認を行い（５）、与信が証明されると（６）、受注者４２は、発注者４０の発注を受け、受注を発注者４０に通知する（７）。

［ハードウェア構成］
図７は、図６に示した与信機関３、発注者４０、受注者４２およびディレクトリ管理・認証機関４４において用いられるコンピュータのハードウェア構成を例示する図である。
図７に示すように、与信機関３、発注者４０、受注者４２およびディレクトリ管理・認証機関４４において用いられるコンピュータは、ＣＰＵ１０２およびメモリ１０４およびこれらの周辺回路などを含む本体１００、表示装置、キーボードおよびマウスなどを含む入出力装置１０６、ネットワーク１６０を介して他のノードとの間の通信を行う通信装置１１０、および、ＦＤ装置、ＣＤ装置およびＨＤＤ装置などの記録装置１１２から構成される。
つまり、与信機関３、発注者４０および受注者４２において用いられるコンピュータは、ネットワーク１６０を介して他のノードと通信が可能な一般的なコンピュータとしての構成部分を有している。

図８は、図６に示した与信機関３のコンピュータ（図７）上で実行される第１の与信プログラム３０の構成を示す図である。
図８に示すように、第１の与信プログラム３０は、ユーザインターフェース（ＵＩ）部３００、認証・通信処理部３０２、情報管理部３１０、取引者情報データベース（ＤＢ）３１２、取引管理部３１４、取引ＤＢ３１６、信用枠管理部３２０、信用枠ＤＢ３２２、取立処理部３２４、連携処理部３２６、与信審査部３３０、与信証明部３３２、資金提供部３４０、課金部３５０および課金ＤＢ３５２から構成される。

与信プログラム３０は、記録媒体１１４（図７）などを介して与信機関３のコンピュータに供給され、メモリ１０４にロードされて実行される（以下の各プログラムについて同様）。
与信プログラム３０は、金融機関Ｚを兼ねる与信機関３において用いられ、これらの構成部分により、図２〜図３を参照して説明した本発明に係る信用取引システムにおける与信のための処理を実現する。

与信プログラム３０において、ＵＩ部３００は、入出力装置１０６（図７）に対するユーザの操作などに応じて、与信プログラム３０の各構成部分の動作を制御する。
また、ＵＩ部３００は、与信プログラム３０の各構成部分により作成された情報・データ、および、各構成部分の処理内容などを、入出力装置１０６の表示装置に表示し、あるいは、記録装置１１２内の記録媒体１１４に対して記録する。

認証・通信処理部３０２は、発注者４０および受注者４２との間の通信に必要とされる通信処理、これらとの間の認証処理、および、これらとの間で伝送される情報・データの改ざん防止のための処理を行う。
情報管理部３１０は、発注者４０および受注者４２それぞれに対して、情報・データを要求し、この要求に応じて発注者４０および受注者４２それぞれから返される情報・データを受け、取引者情報ＤＢ３１２に記憶し、管理する。

また、情報管理部３１０は、取引者情報ＤＢ３１２に記憶した情報・データを、必要に応じて読み出し、与信プログラム３０の各構成部分の処理のために提供する。

発注者４０および受注者４２によって、与信機関３に開示される情報には、上述のように、発注者４０と受注者４２との間で行われる発注および受注の内容を示す情報、契約に従って開示される財務情報（一般に開示される財務情報の外に、契約に従って、発注者４０および受注者４２が与信機関３に提出した担保を示す担保情報、および、発注者４０および受注者４２の可処分資産を示す情報が含まれることがある）、および、財務情報を裏付ける情報（契約に従って、経営情報、財務情報、在庫情報、製造（工程）情報、物流情報および取引先の情報などが含まれることがある）などが含まれる。
情報管理部３１０は、これらの情報を、例えば、周期的に、あるいは、与信機関３における与信処理のために必要となったときに、発注者４０および受注者４２に対して要求し、開示を受ける。

取引管理部３１４は、発注者４０が取引それぞれに付す発注番号から、信用取引システム１６において行われる取引それぞれを一意に識別するために用いられる取引ＩＤを作成する。
また、取引管理部３１４は、作成した取引ＩＤと、取引の内容（発注者、受注者、取引の日時、取引される信用枠の量など）とを対応付けて、取引ＤＢ３１６に記憶し、管理する。

信用枠管理部３２０は、情報管理部３１０により提供される情報から、発注者４０および受注者４２それぞれの信用枠を計算し、信用枠ＤＢ３２２に記憶し、管理する。
信用枠管理部３２０は、例えば、情報管理部３１０が、発注者４０および受注者４２それぞれから情報を受け取るたび、発注者４０と受注者４２との間で取引が行われるたび、および、発注者４０および受注者４２に対する取り立て処理が発生するたびに、発注者４０および受注者４２それぞれの信用枠を計算する。
信用枠管理部３２０は、信用枠の計算において、新たな情報を必要とするときには、情報管理部３１０を介して、必要な情報の開示を、発注者４０および受注者４２それぞれに対して要求する。

図９は、図８に示した第１の信用枠管理部３２０が、受注者４２への支払いのために発注者４０の信用枠の一部をロックする様子を例示する図である。
信用枠管理部３２０は、図９に示すように、発注者４０の信用枠の内、受注者４２に支払われるべき部分を、支払い（取り立て）に備えて、他の受注者の支払いに回されないように取り置く（ロックする）。
信用枠管理部３２０は、図９に示した発注者４０の信用枠の内の各受注者への取り置き分に取引ＩＤを付して、信用枠ＤＢ３２２に記憶させ、管理する。

支払い（取り立て）により、発注者４０の信用枠の取り置き分（図９）が、受注者４２の信用枠として確定しても、与信者３における信用枠の総和に変更はない。
一方、与信者３が、他の与信者との間で信用枠をやりとりしたときには、与信者３の信用枠の総和は増減しうる。
また、発注者４０と受注者４２との間の取引により価値が創造されたときに、例えば、発注者４０が、その分を、与信者３への担保を増やすために用いると、与信者３の信用枠の総和は増大しうる。
反対に、発注者４０と受注者４２との間の取引により損失が出たときには、与信者３の信用枠の総和は減少しうる。

取立処理部３２４は、発注者４０と受注者４２との間の取り立てのための処理を行う。
つまり、取立処理部３２４は、発注者４０の信用枠のうちで発注のために使用したことによって、当該発注のために確保されていた部分を、発注者４０の信用枠から取立て、受注者４２の信用枠として確定させるための処理を行う。
なお、取立処理部３２４を、与信者３、発注者４０、受注者４２およびディレクトリ管理・認証機関４４と独立した別のノードとしたり、金融機関Ｚ（図２など）に、機能の一部として含めたりすることも可能である。

連携処理部３２６は、他の与信機関との連携のための処理（連携処理；ディレクトリ管理・認証機関４４に対する他のノードのロケーションの問い合わせおよび認証など）が含まれる。
例えば、信用取引システム１６に、他の与信機関（図示せず）３が含まれ、発注者４０が、他の与信機関３により与信される受注者（図示せず）との間で取引を行うときには、連携処理部３２６は、他の与信機関と協働して発注者４０と、他の与信機関により与信される受注者との間の取引のために必要な処理を行う。
複数の与信機関が連携して行う処理の詳細は、第２の実施形態として後述する。

与信審査部３３０は、発注者４０から与信の要求があったときに、信用枠ＤＢ３２２に記憶された発注者４０の信用枠、および、取引者情報ＤＢ３１２に記憶された開示情報に基づいて、発注者４０から要求された額の与信が可能か否かを審査する。
与信審査部３３０は、この審査の結果に、取引管理部３１４により作成・管理される取引ＩＤを付して、認証・通信処理部３０２を介して発注者４０に返す。

与信証明部３３２は、受注者４２から与信の確認があり、確認が要求された与信が、与信審査部３３０により可能と審査されたときには、与信を確認した旨に取引ＩＤを付して、受注者４２に対して通知する。
また、与信証明部３３２は、受注者４２から与信の確認があり、確認が要求された与信が、与信審査部３３０により不可と審査されたときには、与信を確認しない旨に取引ＩＤを付して、受注者４２に対して通知する。

資金提供部３４０は、発注者４０および受注者４２から、資金の提供の要求があったときに、この要求を審査し、信用枠の範囲内で、発注者に対して資金を提供する。
この資金の提供は信用枠の使用形態の一種であって、例えば、受注者４２が、信用取引システム１６に参加していないために、信用枠の電子的な取引ができないときに利用され、受注者４２に、発注者４０が有する信用枠の一部を、現金化して渡すために利用される。
なお、資金提供部３４０を、与信者３、発注者４０、受注者４２およびディレクトリ管理・認証機関４４と独立した別のノードとしたり、金融機関Ｚ（図２など）に、機能の一部として含めたりすることも可能である。

課金部３５０は、信用枠ＤＢ３２２に記憶された発注者４０および受注者４２の信用枠、および、取引者情報ＤＢ３１２に記憶された発注者４０および受注者４２の開示情報に基づいて、発注者４０および受注者４２それぞれに対する課金額を算出し、信用枠ＤＢ３２２に記憶、管理する。
課金部３５０は、信用枠ＤＢ３２２に記憶された発注者４０および受注者４２それぞれの課金額に基づいて、例えば、発注者４０および受注者４２の間で取引が発生するたびに、あるいは、月末など一定の期日ごとに、発注者４０および受注者４２それぞれに対する課金処理を行う。

［取引者プログラム４００］
図１０は、図６に示した発注者４０および受注者４２のコンピュータ（図７）上で動作する第１の取引者プログラム４００を示す図である。
なお、図１０に示す第１の取引者プログラム４００の各構成部分の内、図８に示した第１の与信プログラム３０の各構成部分と実質的に同じものには、同じ符号が付してある（特記なき限り、以下の各図において同様）。

図１０に示すように、取引者プログラム４００は、ＵＩ部３００、認証・通信処理部３０２、フィルタ部４１０、管理部４２０、財務処理部４２２、与信処理部４３０、発注管理部４４０（受注者４２が受注のみを行うときには、受注者４２のコンピュータ上で動作する取引者プログラム４００において不要）、受注管理部４４２（発注者４０が発注のみを行うときには、発注者４０のコンピュータ上で動作する取引者プログラム４００において不要）、および、連携処理部４４４から構成される。
つまり、取引者プログラム４００は、財務処理、製造（工程）管理、物流管理および在庫管理などを行うＥＲＰシステムに、フィルタ部４１０を付加した構成を採る。
取引者プログラム４００は、これらの構成部分により、発注者４０および受注者４２の間の取引、および、与信機関３との間の与信のために必要な処理を行う。

管理部４２０は、発注者４０および受注者４２における製造（工程）管理、物流管理および在庫管理などを行う。
また、管理部４２０は、発注者４０および受注者４２における製造（工程）管理、物流管理および在庫管理などに関する情報の内、契約により与信機関３に開示すべき情報を、与信機関３からの要求に応じて、フィルタ部４１０に対して出力する。

財務処理部４２２は、発注者４０および受注者４２における財務管理のための処理を行う。
また、財務処理部４２２は、第１の与信プログラム３０（図８）の資金提供部３４０および課金部３５０との間で、取り立て（精算）および課金に関する処理を行う。
また、財務処理部４２２は、発注者４０および受注者４２における財務管理処理に関する情報の内、契約により与信機関３に開示すべき情報を、与信機関３からの要求に応じて、フィルタ部４１０に対して出力する。

与信処理部４３０は、発注者４０において、与信機関３に対して、与信の要求を、取引ＩＤを付して行う。
また、与信処理部４３０は、受注者４２において、与信機関３に対して、与信の確認のための処理を、発注番号ＩＤを付して行う。
また、与信処理部４３０は、与信機関３に対する与信の要求、あるいは、与信の確認に対する応答に応じて、発注管理部４４０および財務処理部４２２の動作を制御する。

フィルタ部４１０は、与信機関３からの要求に応じて、管理部４２０、財務処理部４２２および与信処理部４３０から入力される情報・データをフィルタリングして、契約により与信機関３に開示されるべき情報・データのみを得る。
フィルタ部４１０は、フィルタリングの結果として得られた情報・データを、与信機関３のコンピュータ上で動作する取引者プログラム４００（図１０）が処理可能な形式に変換し、認証・通信処理部３０２を介して、与信機関３に対して送信する。

発注管理部４４０は、取引者プログラム４００のユーザの操作および与信処理部４３０の制御に従って、認証・通信処理部３０２を介して、発注者４０から受注者４２への発注処理を、取引ＩＤを付して行う。
受注管理部４４２は、取引者プログラム４００のユーザの操作および与信処理部４３０の制御に従って、認証・通信処理部３０２を介して、受注者４２から発注者４０への受注処理を行う。

連携処理部４４４は、発注者４０と受注者４２とが、複数の与信者３を連携させて取引するための処理（ディレクトリ管理・認証機関４４に対する他のノードのロケーションの問い合わせおよび認証など）他の与信機関との連携のための処理を行う。

［信用取引システム１６の全体的な動作］
以下、図６および図１１を参照して、信用取引システム１６の全体的な動作を説明する。
図１１は、図６に示した信用取引システム１６の全体的な動作（Ｓ１０）を示す通信シーケンス図である。
なお、図６および図１１には、発注者４０および受注者４２の間で、取引が正常に行われる場合が例示されている。
図１１に示すように、ステップ１００（Ｓ１００）において、契約に従って、発注者４０および受注者４２のコンピュータ（図６）上で動作する取引者プログラム４００により開示される開示情報が、与信機関３に対して送信される。

ステップ１０２（Ｓ１０２）において、発注者４０の取引者プログラム４００が、受注者４２に対する発注を行うために、与信機関３に対する与信要求のための処理を行う。
ステップ１０４（Ｓ１０４）において、発注者４０の取引者プログラム４００は、与信機関３に対して、与信を要求する（図６（１））。
この与信要求には、例えば、（１）発注者４０のＩＤと、（２）発注者４０の認証に用いられる署名、（３）発注内容を示す情報（発注者４０における発注番号、発注先（ここでは受注者４２）、支払い方法（支払期日・金額など）および収入の根拠（この発注のための新たな担保および信用枠を広げうる根拠など）、および、（４）これらの情報の改ざん防止のために用いられるデータなどが含まれる。

ステップ１０６（Ｓ１０６）において、与信機関３の第１の与信プログラム３０（図８）は、与信審査のための処理を行う。
ステップ１０８（Ｓ１０８）において、与信機関３の与信プログラム３０は、発注者４０および受注者４２に対して、契約に従って、審査のために必要な開示情報を適宜、要求し、発注者４０および受注者４２の取引者プログラム４００から開示情報を受ける。

なお、Ｓ１０８の処理において、与信機関３は、発注者４０だけではなく受注者４２からも開示情報を受け取る。
現在本取引信用システムに参加している（つまり図１４に関して後述する信用名前空間に登録されている）企業はその時点での存在が確認されている企業である。
物やサービスの購入のような取引の信用保証では支払い能力の保証が最優先であるので、この限りではステップ１０８においては受注者４２からの開示情報は必ずしも必要とされない。

ただし、受注者４２からの開示情報などを使用することで、与信機関３は受注する側の売買契約に基づく業務遂行義務の実施能力を評価することができる。
このようにして受注者４２側での業務遂行義務の実施能力を評価できれば、サプライチェーンを構成する各取引の流れを統合して監視できるので、更に取引リスクの低い高度な取引信用保証を実現することができる。
つまり、納品遅れによるビジネスの損失の連鎖等も予測可能となるので、信用名前空間中の連鎖する各取引への監視を強化することにより、より低リスクな経済活動支援が可能となる。

ステップ１１０（Ｓ１１０）において、与信機関３の与信プログラム３０は、発注者４０に対して、与信が可能である旨を通知する（図６（２））。
この与信可能通知には、例えば、（１）与信機関３のＩＤおよびその署名、（２）宛先（発注者４０）のＩＤ、（３）発注者４０内の発注番号およびこれから作成された取引ＩＤ、（４）この発注のために個別に用いられる信用枠（信用保証額）、および、（５）これらの情報の改ざんを防止するためのデータなどが含まれる。

ステップ１１２（Ｓ１１２）において、発注者４０の取引者プログラム４００は、受注者４２の取引者プログラム４００に対する発注処理を行う。
ステップ１１４，１１６（Ｓ１１４，１１６）において、発注者４０の取引者プログラム４００は、受注者４２に対する発注を行い、さらに、与信機関３に対して、発注を通知する（図６（３），（４））。

発注者４０から受注者４２に送られる発注には、発注者４０と受注者４２との間で取り決められた情報・データのほかに、例えば、（１）与信機関３のＩＤおよび署名、（２）発注者４０のＩＤおよび署名（例えば、受注者４２は、発注者４０の署名を検証するための公開鍵を、与信機関３から入手する）、（３）取引情報（取引ＩＤおよび発注内容確認項目）、および、（４）これらの情報の改ざんを防止するためのデータなどが含まれる。
また、発注者４０から与信機関３に対する発注通知には、例えば、（１）与信機関３のＩＤおよび署名、（２）取引ＩＤ、および、（３）これらの情報の改ざんを防止するためのデータなどが含まれる。

ステップ１１８（Ｓ１１８）において、受注者４２の取引者プログラム４００は、発注者４０を確認するための処理を行う。
ステップ１２０（Ｓ１２０）において、受注者４２の取引者プログラム４００は、与信機関３に対して、与信の確認を行う（図６（５））。
受注者４２から与信機関３への与信確認には、例えば、（１）受注者４２のＩＤおよび署名、（２）発注者４０のＩＤ、（３）取引ＩＤ、および、（４）これらの情報の改ざんを防止するためのデータなどが含まれる。

ステップ１２２（Ｓ１２２）において、与信機関の与信プログラム３０は、与信証明のための処理を行う。
ステップ１２４（Ｓ１２４）において、与信機関３の与信プログラム３０は、発注者４０および受注者４２に対して、契約に従って、与信証明のために必要な開示情報を適宜、要求し、発注者４０および受注者４２の取引者プログラム４００から開示情報を受ける。

ステップ１２６（Ｓ１２６）において、与信機関３の与信プログラム３０は、受注者４２に対して与信を証明する（図６（６））。
与信機関３から受注者４２に対する与信証明には、例えば、（１）与信機関３のＩＤおよび署名、（２）宛先（受注者４２）のＩＤ、（３）取引ＩＤ、（４）信用保証額、（５）取り立て（精算）・支払い方法に関する情報、および、これらの情報の改ざんを防止するためのデータなどが含まれる。

ステップ１２８（Ｓ１２８）において、受注者４２の取引者プログラム４００は、発注者４０からの受注のための処理を行う。
ステップ１３０（Ｓ１３０）において、受注者４２の取引者プログラム４００は、発注者４０の取引者プログラム４００に対して、受注を通知する（図６（７））。
ステップ１３２（Ｓ１３２）において、与信機関３と、発注者４０および受注者４２との間で、課金、資金提供および取り立て（精算）などが、適宜、行われる。

図１２は、図６に示した信用取引システム１６における他の取引形態を例示する図である。
図１２に示すように、信用取引システム１６においても、図４に示した与信機関Ｘ３、企業Ｙ４および金融機関Ｚの間のトランザクションが行われうる。

［第２の実施形態］
以下、本発明の第２の実施形態を説明する。

図１３は、複数の信用取引システム１０（図２）およびディレクトリ管理・認証機関４４などを含む本発明に係る第５の信用取引システム１８を例示する図である。
図１３に示すように、複数（ｎ個；ｎ≧２）の信用取引システム１０とディレクトリ管理・認証機関４４などとを含む信用取引システム１８を構築することも可能である。
以下、本発明の第２の実施形態として、複数の信用取引システムおよびディレクトリ管理・認証機関４４の連携により実現される信用取引を説明する。

図１４は、図１３に示した第５の信用取引システム１８に含まれる信用名前空間２０および名前空間２２を例示する図である。
例えば、図１４に示すように、図１３に示した信用取引システム１８が、相互に接続された３つの与信機関Ｘ１〜Ｘ３を含み、与信機関Ｘ１には企業Ｙ１１，Ｙ１２が接続され、与信機関Ｘ２には企業Ｙ２１，Ｙ２２が接続され、与信機関Ｘ３には企業Ｙ３１，Ｙ３２が接続されている場合を具体例とする。

図１４に示した場合においては、企業Ｙ１１，Ｙ１２は、与信機関Ｘ１により与信されており、この与信機関Ｘ１および与信機関Ｘ１により与信されている企業Ｙ１１，Ｙ１２が構成する空間は、以下、信用名前空間２０−１とも呼ばれる。
同様に、企業Ｙ２１，Ｙ２２は、与信機関Ｘ２により与信されており、この与信機関Ｘ２および与信機関Ｘ２により与信されている企業Ｙ２１，Ｙ２２が構成する空間は、以下、信用名前空間２０−２とも呼ばれる。

同様に、企業Ｙ３１，Ｙ３２は、与信機関Ｘ３により与信されており、この与信機関Ｘ３および与信機関Ｘ３により与信されている企業Ｙ３１，Ｙ３２が構成する空間は、以下、信用名前空間２０−３とも呼ばれる。

つまり、信用名前空間２０−１〜２０−３は、信用を保証する与信機関Ｘ１〜Ｘ３それぞれによる保証が有効な経済活動の範囲を示す。
与信期間Ｘ１〜Ｘ３による信用保証のために、信用保証の対象となる企業Ｘ１１，Ｙ１２，Ｘ２１，Ｙ２２，Ｘ３１，Ｙ３を識別する方法が定義される。
信用名前空間２０は、信用名前空間２０それぞれにおいて唯一の与信機関Ｘと、この与信機関Ｘに接続され（与信され）、相互に取引を行う複数の企業Ｙから構成され、与信機関Ｙおよび企業Ｙそれぞれには、信用名前空間２０それぞれにおいてユニークな（一意な）識別符号（名前）が付されている。

信用名前空間２０にも、それ自体を代表し、他の信用名前空間２０との区別のために用いられる識別符号と同等な名前が付され、この信用名前空間２０それぞれの名前は、複数の信用名前空間２０が形成し、経済的な取引の信用の連鎖が及ぶ大域的な範囲（名前空間２２）においてユニーク（一意）とされる。
なお、信用名前空間２０には、特定の用途に用いられる別名として、他の信用名前空間２０と区別可能なニックネームが付されることがある。

信用名前空間２０−１〜２０−３およびその企業Ｘ１１，Ｙ１２，Ｘ２１，Ｙ２２，Ｘ３１，Ｙ３２などにこのような名前を付与し、さらに、複数の信用名前空間２０、これらの信用名前空間内それぞれを構成する要素（与信機関Ｘ，企業Ｙ）、および、これらの信用名前空間それぞれを構成する要素間の階層構造を、名前空間２２の内に設けたディレクトリ管理・認証機関Ｗに登録すると、任意の要素が、このディレクトリ管理・認証機関Ｗを用いて、任意の信用名前空間２０を参照して、任意の要素の名前空間２２における位置を検索することができるようになる。
つまり、このようなディレクトリ管理・認証機関Ｗを設けることにより、任意の要素が、同じ信用名前空間２０に属する要素だけでなく、他の特定の信用名前空間２０の存在、および、その信用名前空間２０内にある要素の情報を取得することができるようになる。
また、このようなディレクトリ管理・認証機関Ｗを設けることにより、任意の要素が、特定の信用名前空間内にある特定の企業を識別することもできるようになる。

名前空間２２にディレクトリ管理・認証機関Ｗを設けた結果、互いが異なる信用名前空間２０の内に属する企業Ｙの間でも、互いの属する空間に関する情報をこのディレクトリ管理・認証機関Ｗを介して交換することができるようになる。
名前空間２２は、信用名前空間２０の名前とその中に存在する企業Ｙなどの名前を使うことにより、個々の企業Ｙなどを特定したり、その情報を取得したりできることを意味している。

言い換えると、名前空間２２とは、ディレクトリ管理・認証機関Ｗにより検索（名前解決）が可能な範囲であり、ディレクトリ管理・認証機関Ｗにより検索可能とは、この信用名前空間２０を参照できるディレクトリ管理・認証機関Ｗに格納されている情報が、各信用名前空間２０の階層構造を反映していることを意味する。
このような階層構造を反映したディレクトリサービス（ディレクトリ管理・認証機関Ｗ）に情報を問い合わせる通信手段の標準的な規格の例としては、上述したＬＤＡＰなどを挙げることができ、このようなディレクトリサービスは、Ｘ．５００として規格化されている。

具体的に説明すれば、与信機関Ｘ１〜Ｘ３それぞれが、以下の（１）〜（３）の処理を行うようにすると、名前空間２２において、複数の信用名前空間２０の間における取引が可能になる。
（１）第１の実施形態においてと同様に、与信機関Ｘ１〜Ｘ３が、信用名前空間２０−１〜２０−３それぞれの発注企業Ｙに対する与信を行う。
（２）与信機関Ｘ１〜Ｘ３それぞれが、同じ信用名前空間２０に含まれる受注企業Ｙによる与信確認に応じるだけでなく、他の信用名前空間２０に含まれる受注企業Ｙによる与信確認にも応じて、同じ信用名前空間２０に含まれる発注企業Ｙの与信証明を行う。
（３）与信機関Ｘ１〜Ｘ３それぞれが、必要に応じて、他の与信機関Ｘからの与信確認および与信証明を中継する。

図１５は、モデル化された本発明に係る第６の信用取引システム２４を示す図である。
図１４に示した信用取引システムを、企業Ｙ１１，Ｙ２１間の取引および企業Ｙ１１，Ｙ１２と与信機関Ｘ１，Ｘ２との間のトランザクションに着目してモデル化すると、図１５に示す信用取引システム２４を得ることができる。

図１５に示すように、信用取引システム２４は、与信機関Ｘ１，Ｘ２（与信機関３−１，３−２とも記す）、発注側の企業（発注者）Ｙ１１および受注側の企業（受注者）Ｙ２１（以下、発注者４０，受注者４２とも記す）、および、ディレクトリ管理・認証機関４４が、インターネットあるいは専用通信回線などのネットワーク１６０を介して接続されて構成される。
なお、信用取引システム２４においては、同時に複数のトランザクションが存在しうるが、図示の簡略化および明確化のために、図１５には、信用取引システム２４に１つのトランザクションが存在する場合が例示されている（以下、特記なき限り、トランザクションを示す各図について同様）。

図１５に示すように、信用取引システム１８において、発注者４０が受注者４２に発注するときには、発注者４０がディレクトリ管理・認証機関４４から受注者４２のディレクトリを得て（１），（２）、与信機関３−１に対して与信を要求し（３）、この与信が可能である旨の通知（４）が与信機関３−１から発注者４０に返されると、発注者４０は、受注者４２に対する発注を行い、発注を与信機関３−１に通知する（５），（６）。
発注を受けた受注者４２は、与信機関３−２を介して、与信者３−１に対して、与信の確認を行い（７），（８）、与信者３−２を介して与信者３−１から与信が証明されると（９），（１０）、受注者４２は、発注者４０の発注を受け、受注を発注者４０に通知する（１１）。
与信者３−１，３−２上で動作する第１の与信プログラム３０（図８）の連携処理部３２６、および、発注者４０および受注者４２上で動作する第１の取引者プログラム４００（図１０）の連携処理部４４４は、必要に応じて、ディレクトリ管理・認証機関４４に対するディレクトリの検索および認証のための処理を行う。

［信用取引システム２４の全体的な動作］
以下、信用取引システム２４の全体的な動作を説明する。
図１６は、図１５に示した信用取引システム２４の全体的な動作（Ｓ２０）を示す通信シーケンス図である。
なお、図１６には、発注者４０および受注者４２の間で、取引が正常に行われる場合が例示されており、図１６に示した各処理の内、図１１に示した処理と実質的に同じものには、同じ符号が付してある（特記なき限り、以下の各図において同様）。

図１６に示すように、ステップ１００（Ｓ１００）において、発注者４０および受注者４２それぞれは、契約に従って開示情報を、与信機関Ｘ１，Ｘ２（与信機関３−１，３−２）それぞれに対して送信する。
ステップ２００（Ｓ２００）において、発注者４０上で動作する取引者プログラム４００の第１の連携処理部４４４（図１０）は、ディレクトリ管理・認証機関４４に対して、受注者４２のディレクトリを問い合わせる（図１５（１））。
ステップ２０２（Ｓ２０２）において、ディレクトリ管理・認証機関４４は、受注者４２のディレクトリを含む応答を、発注者４０に対して返す（図１５（２））。

ステップ１０２（Ｓ１０２）において、発注者４０の取引者プログラム４００が、受注者４２に対する発注を行うために、与信機関３−１に対する与信要求のための処理を行う。
ステップ１０４（Ｓ１０４）において、発注者４０の取引者プログラム４００は、与信機関３−１に対して、与信を要求する（図１５（３））。

ステップ１０６（Ｓ１０６）において、与信機関３−１の第１の与信プログラム３０（図８）は、与信審査のための処理を行う。
ステップ１０８（Ｓ１０８）において、与信機関３−１の与信プログラム３０は、発注者４０などに対して、審査のために必要な開示情報を適宜、要求し、開示情報を受ける。

ステップ１１０（Ｓ１１０）において、与信機関３−１の与信プログラム３０は、発注者４０に対して、与信が可能である旨を通知する（図１５（４））。

ステップ１１２（Ｓ１１２）において、発注者４０の取引者プログラム４００は、受注者４２の取引者プログラム４００に対する発注処理を行う。
ステップ１１４，１１６（Ｓ１１４，１１６）において、発注者４０の取引者プログラム４００は、受注者４２に対する発注を行い、さらに、与信機関３−１に対して、発注を通知する（図１５（５），（６））。

ステップ１１８（Ｓ１１８）において、受注者４２の取引者プログラム４００は、発注を確認するための処理を行う。
ステップ２１０（Ｓ２１０）において、受注者４２の取引者プログラム４００は、与信者３−２を介して、与信機関３−１に対する与信確認を行う（図１５（７），（８））。

ステップ１２２（Ｓ１２２）において、与信機関３−１の与信プログラム３０は、与信証明のための処理を行う。
ステップ１２４（Ｓ１２４）において、与信機関３−１の与信プログラム３０は、発注者４０などに対して、与信証明のために必要な開示情報を適宜、要求し、開示情報を受ける。

ステップ２１２（Ｓ２１２）において、与信機関３−１の与信プログラム３０は、与信者３−２を介して、受注者４２に対する与信証明を行う（図１５（９），（１０））。
ステップ１２８（Ｓ１２８）において、受注者４２の取引者プログラム４００は、発注者４０からの受注のための処理を行う。

ステップ１３０（Ｓ１３０）において、受注者４２の取引者プログラム４００は、発注者４０の取引者プログラム４００に対して、受注を通知する（図１５（１１））。
ステップ１３２（Ｓ１３２）において、与信機関３と、発注者４０および受注者４２との間で、課金、資金提供および取り立て（精算）などが、適宜、行われる。
なお、図１５中に点線で示すように、与信者３−１，３−２、発注者４０および受注者４２から、ディレクトリ管理・認証機関４４に対するディレクトリ検索および認証のための処理は、必要に応じて、適宜、行われる。

図１７は、図１４に示した信用取引システムにおける取引の特徴を示す図である。
図１７に示すように、図１４に示した信用取引システムにおいては、与信機関Ｘ１〜Ｘ３による企業Ｙ１１〜Ｙ３１に対する与信は、信用名前空間２０−１〜２０−３それぞれに閉じて行われ、信用名前空間２０−１〜２０−３をまたがる与信確認および与信証明は、与信機関Ｘ１〜Ｘ３を介して行われ、取引ＩＤにより管理される。

従って、企業Ｙ１１〜Ｙ３１それぞれは、与信機関Ｘ１〜Ｘ３それぞれに対してのみ情報開示を行えばよく、図１４に示した信用取引システムにおいては、企業Ｙ１１〜Ｙ３１の情報が不必要に拡散することはない。
また、企業Ｙ１１〜Ｙ３１それぞれの信用枠は、与信機関Ｘ１〜Ｘ３それぞれにより管理され、複数の与信機関Ｘの間で分割されることがない。
従って、図１４に示した信用取引システムにおいては、企業Ｙ１１〜Ｙ３１それぞれの信用枠は、与信機関Ｘ１〜Ｘ３それぞれにより、一元的に管理されうる。

ここまで述べた信用名前空間、およびこれらの信用名前空間をまたぐためのディレクトリ管理・認証機関Ｗによるディレクトリサービスの意義、また、その具体的な構成・動作を、さらに説明する。
取引信用とは、取引における支払い義務を負う発注者（発注企業）側が、その支払い能力を、それが信用契約の結果属している信用名前空間１０の与信機関Ｘに証明し、保証してもらうことである。

取引の信用保証を得るためには、企業Ｙそれぞれは、その支払い能力の根拠や担保を、契約に基づいて、与信機関Ｘが求める方式により、提出あるいは開示する必要があり、これは、信用保証の有効範囲が、通常、各信用名前空間２０の中で閉じていることを意味する。
この取引信用を、他の信用名前空間２２の中にある企業Ｙとの取引に利用するためには、この信用名前空間２２内における企業Ｙの識別と、信用名前空間２２内における企業Ｙの識別を支援するディレクトリサービスが利用されうる。

各信用名前空間２２においては、与信機関Ｘが管理すべき取引のための各企業Ｙの与信枠（信用確保のために確保／ロックして、取引の代償として所有権が受注者側に移行する財）は、各取引を識別する取引ＩＤによって管理される。
同様に、複数の信用名前空間２２をまたがる取引が行われるときには、この信用名前空間２２の情報を取引ＩＤに反映することにより、名前空間２２において、各取引に関連する関連情報の唯一無二性、整合性および真正性が保証されうる。
例えば、信用名前空間２２の名前と、この信用名前空間２２における取引を識別するために用いられ、この信用名前空間２２においてユニークな（一意な）識別子とを連結することにより、名前空間２２全体で一意性が保証された取引ＩＤを作成することができる。

このような名前空間２２におけるディレクトリサービスの実現のために、ディレクトリ管理・認証機関Ｗは、以下のような情報を格納し、構造化された関係に基づいて関連する情報を検索し、取出す。
（１）与信機関Ｘごとに設定される信用名前空間２０の名前、および、
（２）これに属する以下の情報
（２−１）信用名前空間２２の基軸となっている与信機関Ｘの属性情報：
たとえば、システム上アクセスに必要な情報（アドレス、アクセス権、認証符号）や、取引処理上要求される情報（利用可能なビジネスプロトコル）。
（２−２）与信機関Ｘの一つと与信（取引信用）サービス契約を結んで、特定の信用名前空間に属する取引者（企業Ｙなど）のその信用名前空間２０内での名前、およびその取引者の属性情報（上述の与信機関の属性情報と同等な情報）。

このような情報を格納したディレクトリ管理・認証機関Ｗを使った検索においては、名前空間２２内での名前を指定して、それに関連付けられた情報を探し出すことができる。
また、検索の指定のやり方によっては、特定の信用名前空２０間に所属する取引者（企業Ｙ）の一覧を取出すこともできる。
また、信用名前空間２０内の取引者（企業Ｙ）名から、それが所属する信用名前空間２０名を探し出すという逆引きを行うこともできる。
実際の信用取引の保証においては、作業が煩雑になるのを避けるため、取引者同士は最初から自分が所属する信用名前空間２２の正確な名前を相手に提示し、これが間違っていたり、あるいは、失効していた場合には、再確認をその当事者に対して行うようにすることが望ましい。

更に、取引者（企業Ｙ）は、ディレクトリ管理・認証機関Ｗに、本人認証のための認証コードも登録するので、取引者（企業Ｙ）とその認証コードとの組み合わせを一意的にすることにより、取引者（企業Ｙ）が所属する信用名前空間２０が、１回の検索で割り出せるようにすることもできる。
このような逆引き検索においては、同一取引者（企業Ｙ）が、複数の信用名前空間２０に、同一名で所属しているときには、複数の信用名前空間２０の名前が、検索の回答として与えられることがある。

信用名前空間の構造を反映した上述のような情報を格納したディレクトリ管理・認証機関は、実際の取引において例えば以下のように利用することもできる。

例１：
発注者（企業）Ｙ１１と受注者（企業）Ｙ１２（例えば図１４）とが、ディレクトリ管理・認証機関Ｗを、互いの存在を確認する手段として利用する。
このときには、双方の取引者（企業Ｙ１１，Ｙ１２）は、自分が所属する信用名前空間２０−１を相手方に提示し、これを使ってディレクトリ管理・認証機関Ｗに相手方の存在確認を依頼する。
この際、取引者（企業Ｙ１１，Ｙ１２）は、その後の取引のため、ディレクトリ管理・認証機関Ｗが持っている認証機能を利用して相手の真正性を確認することができる。
これは、信用保証処理そのものというよりは、電子商取引における相互の本人確認であり、その後発行される発注書や受注確認書の安全性の確保のために役立つ。

例２（異なる信用名前空間の間で信用保証を行う場合での、相手方の与信機関及び信用名前空間の確認）：
典型的な例を以下に示す。
発注者（企業）Ｙ１１（例えば図１４）は自分の属する信用名前空間２０−１内の与信機関Ｘ１に、受注者（企業）Ｙ２１の名前に関連する情報、つまり、（１）受注者Ｙ２が所属する信用名前空間名２０−２の名前、および、（２）受注者Ｙ２１の信用名前空間２０−２内の名前を提示し、受注者（企業）Ｙ２１が所属する与信機関Ｘ２の正確な信用名前空間を確認する。
与信機関Ｘ１は、これらの情報を使うことにより、ディレクトリ管理・認証機関Ｗに対して１回の検索を行うことにより、相手方の与信機関Ｘ２および信用名前空間２０−２の確認を行うことができる。

この検索によって受注者（企業）Ｙ２１を発見することができなかったときには、与信機関Ｘ１は、発注者（企業）Ｙ１１に対してエラーを返し、このエラー処理として、与信機関Ｘ１は、発注者（企業）Ｙ１１に対して、受注者（企業）Ｙ２１が所属する信用名前空間２０−２を確認する。
この場合には、発注者（企業）Ｙ１１は受注者（企業）Ｙ２１から直接この情報を得たり、あるいは与信機関Ｘ１に与えた受注者（企業）Ｙ２１に関する情報が正確かどうかの確認などを行う必要がある。
例２として示した確認は、上述した例１の動作と連動して実行すると効率的である。

なお、受注者（企業）Ｙ２１の属する信用名前空間２０−２内の名前のみを用いて、ディレクトリ管理・認証機関Ｗにより、信用名前空間２０−２を逆引きするときには、ディレクトリ管理・認証機関Ｗは認証局でもあるので、実際には、受注者（企業）Ｙ２１の認証コードから、直接、その属性情報として、受注者（企業）Ｙ２１が所属する信用名前空間２０−２の名前を取出すことができる。
ただし、受注者（企業）Ｙ２１が複数の与信機関Ｘと契約しているときには、信用名前空間２０−２内の名前を用いて検索を行うと、今回の取引の結果として信用枠（代償）を移行させるべき与信機関Ｘの名前が、複数、取り出されることがある。

［第３の実施形態］
まず、第３の実施形態の理解を助けるために、その前提として、信用名前空間における取引ＩＤを、さらに詳細に説明する。

［取引ＩＤの位置づけと意味］
取引ＩＤは、特定の信用名前空間内の取引に対応付けられており、与信機関Ｘにより発行され、その取引ＩＤを発行した与信機関Ｘは、その取引ＩＤにより特定される取引の価値を保証する。
つまり、信用名前空間においては、その信用名前空間において取引ＩＤを発行した与信機関Ｘにより、その取引ＩＤに対応付けられた取引の価値と、その価値を利用する権利が、だれに属しているかが特定されうる。

［取引ＩＤの作成］
既に述べたように、取引ＩＤは、第１の与信プログラム３０（図８）により、発注者４０（図１５）が取引それぞれに付す発注番号などから作成される。
取引ＩＤは、さらに詳細には、与信プログラム３０などにより、以下に示す（１），（２）の処理により作成され、有効期間が設定されうる。
（１）与信機関３−１が、取引の対価（価値）の保証をするときには、取引ＩＤは、発注者４０が、与信機関３−１に対して、与信要求を、取引を識別するための情報（発注識別コード（発注番号など））とともに送ることを契機に作成される。
発注者４０が、与信要求とともに与信機関３に送る発注識別コードは、例えば、ディレクトリ管理・認証機関４４により発注者４０を識別するために用いられる本人識別用の情報と、発注者４０により取引を一意に特定するために用いられる内部コードとを含む。
与信機関３−１は、これらのような情報を含む発注識別コードを用いることにより、信用名前空間内で各取引を一意に識別可能であり、かつ、真正であることが保証された取引ＩＤを作成する。

（２）特定の一つの信用名前空間には与信機関はただ一つ存在し、その与信機関３−１のシステム内では、与信機関３−１は、発注者４０に対する与信を行うための処理とともに、発注者４０から得た発注識別コードから、その与信機関３のシステムにおいて固有の取引ＩＤを作成する。
以上述べた（１），（２）のいずれかの処理により、信用名前空間において、ある取引およびその価値と一意に対応付けられた取引ＩＤが作成され、信用空間内の各ノード（他の与信機関３−１および受注者４２など）は、取引ＩＤを利用することにより、取引ＩＤを発行した与信機関３−１から、その取引ＩＤに対応した取引の情報を得ることができる。

［取引ＩＤの管理］
既に述べたように、取引ＩＤは、与信機関３−１により発行され、上述のように有効期間が設定されうる。
取引ＩＤおよび取引ＩＤに対応付けられた取引の価値は、その取引ＩＤを発行した与信機関３−１により管理され、その取引ＩＤを発行した与信機関３−１が、他の与信機関３−２および受注者４２からの問い合わせに応じて、その取引ＩＤに対応付けられた取引の価値を提供する。
なお、取引ＩＤの真正性の保証、および、取引ＩＤを発行した与信機関３−１の自体の存在と、そこからの発行情報の真正性の保証は、ディレクトリ管理・認証機関４４により行われる。

［取引ＩＤの利用］
以下、取引ＩＤの利用例を示す。
（１）寿命（有効期間）のある価値の流通の効率化：
取引ＩＤの利用により、ある信用名前空間内で、有効期間のある特定の取引の価値が受け渡されるときに、その取引の価値の量と、その価値を利用する権利を有する者とが、明確に特定されうるので、取引の価値が、効率的に流通されうるようになる。
与信機関３は、多数の有効期間付きの取引が信用名前空間内で流通していても、各取引の保証に含まれるリスクを個別に認識すると同時にそのリスクの総和を集計することができ、効率的なリスク管理を実現することができる。また、各取引における価値の移転を、正確に把握することができる。
また、例えば、第１の信用名前空間から第２の信用名前空間に取引の価値が移転されるときに、第２の信用名前空間に属する与信機関３−２（与信機関Ｘ２）は、価値の根拠となる取引と、価値の量と、価値の利用権の所有者とを、第１の信用名前空間に属し、取引ＩＤを発行した与信機関３−１（与信機関Ｘ１；取引ＩＤ１）から明示的に知ることができる。
従って、第２の信用名前空間に属する与信機関３−２（与信機関Ｘ２）は、例えば、第１の信用名前空間に属する与信機関３−１からの情報と、第２の信用名前空間において固有の情報とを組み合わせることにより、第２の信用名前空間において有効な取引ＩＤ（取引ＩＤ２）を作成することができる。
この第２の信用名前空間における取引ＩＤ（取引ＩＤ２）を用いることにより、第２の信用名前空間に属する与信機関３−２（与信機関Ｘ２）は、第２の信用名前空間における他の取引の価値と、第１の信用空間から移転された取引の価値との総量を、第２の信用名前空間において、効率的に流通させることができる。

（２）支払いの保証と納品の保証の連携：
既に述べたように、取引ＩＤは、個々の取引の識別を可能とする。
従って、取引ＩＤを用いることにより、与信機関は、金銭が与信の対象となる取引だけでなく、物品の所在や所有の移動が与信の対象となる取引を扱うことができる。
つまり、例えば、物品の所在・所有が与信の対象となる取引を行う取引者（受注者）は、与信機関に、例えば、発注者に対する納品の保証を依頼することができ、この場合には、与信機関３により総量として与信される対象は、金銭ではなく、特定の物品に換算された価値となる。
なお、与信機関は、物品の所在の移動などが与信の対象となる一連の取引の連鎖に対しては、金銭が与信の対象となる一連の取引とは、逆方向に進行する取引の連鎖として与信の対象とすることができる。
金銭が与信の対象となる取引が行われる信用名前空間と、物品の移転などが与信の対象となる信用名前空間とは、別々に存在し、それぞれ一般には別個の与信機関によって管理される。これら２種類の信用名前空間で使用される各取引ＩＤは、お互いに連携させて使用されうる。
これにより、発注者、受注者双方の利便性が図られる。

［信用取引システム２６］
以下、本発明の第３の実施形態として、第７の信用取引システム２６を説明する。
図１８は、本発明にかかる第７の信用取引システム２６の構成を例示する図である。
図１８に示すように、第７の信用取引システム２６は、図１５に示した第６の信用取引システム２４における与信機関Ｘ１，Ｘ２を、それぞれ銀行などの金融機関Ｘ１，Ｚとした構成を採り、さらに、発注者Ｙ１１および受注者Ｙ２１において動作する取引者プログラム、および、金融機関Ｘ１，Ｚにおいて動作する与信プログラムの動作が変更されている（図２１，図２２を参照して後述）。
なお、図１５の与信機関Ｘ２と対応する位置に置かれる金融機関を別の記号Ｚで表したのは、図２６を用いて以下で行う説明においては金融機関Ｚは与信を行わないので、厳密に言えば図１５における与信機関と同じ記号を用いるのは不適切であり、また、図１などにおける金融機関Ｚと同様の機能を果たしているからである。
もちろん、金融機関Ｚがすでに説明してきた与信機能を更に持つことは当然あり得るので、金融機関Ｚが同時に与信機関であることには何の妨げもないことに注意すべきである。

信用取引システム２６において、金融機関Ｘ１は、発注者Ｙ１１に対する与信について与信料の支払いを受け、また、金融機関Ｚに対する保証について保証料の支払いを受ける。
与信料および保証料の金融機関Ｘ１への支払い方法の例として、金銭による支払い、あるいは、与信額・保証額の一部控除などを挙げることができる。
また、金融機関Ｚは、受注者Ｙ２１に対して、発注者Ｙ１１への与信に基づく融資を行う。

図１８〜図２０を参照して、信用取引システム２６のノード間のトランザクションを説明する。
図１９，図２０は、図１８に示した信用取引システム２６のノード間のトランザクションを示す第１および第２の図である。
なお、図１９，図２０においては、図示の簡略化および明確化のために、ネットワーク１６０、ディレクトリ管理・認証機関４４、および、ディレクトリ管理・認証機関４４と他のノードとの間のトランザクションは省略されている。

図１８および図１９に示すように、第７の信用取引システム２６において、発注者４０が受注者４２に発注するときには、発注者４０は、第６の信用取引システム２４（図１５）においてと同様に、ディレクトリ管理・認証機関４４から受注者４２のディレクトリを得る（１），（２）。
発注者４０は、金融機関３−１に対して与信を要求する（３）。
発注者４０は、この与信の要求に、発注しようとする取引の取引ＩＤを金融機関３−１が作成するために必要な情報（たとえば、発注者４０の社内発注処理システムが当該発注を識別するために割当てた発注識別コードなど）を付し、さらに、金融機関３−１に対して、与信のための料金（与信料）を支払う。

なお、与信料の額や支払方法などは当事者間の契約によって別途定めることができる。
例えば、これに限定されるものではないが、額については保証対象額に発注者毎に定められた所定割合を乗算した額などとしてよい。
また、与信料の支払いについても、与信要求時あるいは与信実行時に直ちに支払うだけではなく、例えば所定期間毎に与信料（あるいは金融機関へのこれ以外の支払いも合算して）を精算したり、あるいは金融機関から発注者への支払いなどとの相殺をしたりすることによっても処理することができる。
支払いについては以下に説明する金融機関同士、金融機関と受注者との間についてもこれと同様に多様な方法を取ることができる。

金融機関３−１は、発注者４０からの要求に応じて、与信が可能である旨の通知（４）を発注者４０に返す（４）。
金融機関３−１は、この通知に、上述のように発注者４０から送られてきた情報から作成した取引ＩＤを付す。
発注者４０は、受注者４２に対する発注を行う（５）。
発注者４０は、受注者４２に対する発注を、金融機関３−１に対して通知する。
なお、発注者４０から受注者４２に対する発注、および、発注者４０から金融機関３−１に対する通知には、金融機関３−１から発注者４０に送られた取引ＩＤが付される。

発注者４０から発注の通知を受けると、金融機関３−１は、受注者４２に対して、発注者４０からの発注があったことについての確認を要求し、受注者４２は、これに応答し、発注者４０からの発注があったことを確認する（７），（８）。
このとき、図１９に示すように、発注者４０から受注者４２への発注に起因して、発注者４０が受注者４２に対する支払いを行えるか否かについてのリスクが生じている。

図１８および図２０に示すように、発注を受けた受注者４２は、金融機関３−２に対して、融資を依頼する（９）。
受注者４２は、金融機関３−２に対する融資の依頼に、発注者４０からの発注に付された取引ＩＤを付す。

金融機関３−２は、金融機関３−１に対して、受注者４２に対する融資の保証を依頼する（１０）。
金融機関３−２は、この依頼に、受注者４２からの融資の依頼に付された取引ＩＤを付し、さらに、この保証のための料金（保証料）を、金融機関３−２１に対して支払う。
保証料の額や支払方法などは当事者間の契約によって別途定められるものであり、これに限定するものではないが、保証料の額を例えば保証される金額の所定割合、保証１回毎に決められる固定額などとすることができる。

また、金融機関３−２はこの保証料を、融資申込み者である受注者４２による融資申込みの際の取引ＩＤに基づく保証要求に応えて上述の保証手続を行った対価として、受注者４２に転嫁することになるが、その転嫁の形態についても、金利の上乗せや金利とは別途に各種の方法で徴収される保証料など、当事者間の契約によって適宜決めることができる。
また、その額も、金融機関間の保証料とは別の額とすることも、当事者間の契約などにより自由に定めることができる。

金融機関３−１は、金融機関３−２からの依頼に応じて、受注者４２への融資についての保証を行う（１１）。
金融機関３−１から融資についての保証を受けると、金融機関３−２は、受注者４２に対して融資を行う（１２）。
受注者４２は、金融機関３−２から融資された資金を用いて、受注のために、資材購入などを準備する。
融資を受けると、受注者４２は、発注者４０に対して受注を通知する（１３）。
なお、信用取引システム２６の各ノードは、以上説明したトランザクションを実現するために必要な処理を、適宜、実行する。

図２１は、図１８に示した信用取引システム２６の金融機関３において実行される第２の与信プログラム３６の構成を示す図である。
図２１に示すように、第２の与信プログラム３６は、図８に示した第１の与信プログラム３０に、与信料・保証料処理部３６０および与信料・保証料ＤＢ３６２を付加した構成を採る。
第２の与信プログラム３６は、金融機関３において、第１の与信プログラム３０の代わりに実行され、第１の与信プログラム３０と同様な処理の他、図１８〜図２０に示した与信料および保証料に関する処理を行う。

第２の与信プログラム３６において、与信料・保証料処理部３６０は、発注者４０から与信料の支払いを受けるための処理、および、他の金融機関３から、保証料の支払いを受けるための処理を行う。
与信料・保証料ＤＢ３６２は、発注者４０に対して設定される与信料の額、および、発注者４０および他の金融機関３などに応じて設定される保証料の額など、発注者４０から与信料の支払いを受けるための処理、および、他の金融機関３から、保証料の支払いを受けるための処理のために必要なデータを記憶し、与信料・保証料処理３６０の利用の用に供する。

図２２は、図１８に示した受注者４２において実行される第２の取引者プログラム４６０の構成を示す図である。
図２２に示すように、第２の取引者プログラム４６０は、図１０に示した第１の取引者プログラム４００に、融資処理部４６２を付加した構成を採る。
第２の取引者プログラム４６０は、受注者４２において、第１の与信プログラム３０の代わりに実行され、第１の取引者プログラム４００と同様な処理の他、図１８，図２０に示した融資に関する処理を行う。
第２の取引者プログラム４６０において、融資処理部４６２は、受注者４２が、金融機関３−２からの融資を受けるための処理を行う。

［信用取引システム２６の全体的な動作］
以下、信用取引システム２６の全体的な動作を説明する。
図２３は、図１８に示した信用取引システム２６の全体的な動作（Ｓ２４）を示す通信シーケンス図である。
図２３に示すように、ステップ１００（Ｓ１００）において、発注者４０および受注者４２それぞれは、契約に従って、開示情報を、金融機関Ｘ１，Ｘ２（金融機関３−１，３−２）それぞれに対して送信する。
ステップ２００（Ｓ２００）において、発注者４０（第２の取引者プログラム４６０；図２２）は、ディレクトリ管理・認証機関４４に対して、受注者４２のディレクトリを問い合わせる（図１８，図１９（１））。
ステップ２０２（Ｓ２０２）において、ディレクトリ管理・認証機関４４は、受注者４２のディレクトリを含む応答を、発注者４０に対して返す（図１８，図１９（２））。

ステップ２４０（Ｓ２４０）において、発注者４０は、金融機関３−１（与信プログラム３６）に対して与信を要求するための処理を行う。
ステップ２４２（Ｓ２４２）において、発注者４０は、金融機関３−１に対して、取引ＩＤを作成するために用いられる情報を含む与信要求を出し、与信料を支払う。
ステップ２５０（Ｓ２５０）において、金融機関３−１（第２の与信プログラム３６；図２１）は、与信審査のための処理を行う。
ステップ２５２（Ｓ２５２）において、与信機関３−１は、発注者４０に対して、与信が可能である旨の通知を、Ｓ２４０の処理において受けた情報から作成した取引ＩＤを付して返す（図１８，図１９（４））。

ステップ２６０（Ｓ２６０）において、発注者４０は、受注者４２（第２の取引者プログラム４６０）に対する発注処理を行う。
ステップ２６２，１１６（Ｓ２６２，Ｓ１１６）において、発注者４０は、受注者４２に対する発注を行い、さらに、与信機関３−１に対して、発注を通知する（図１８，図１９（５），（６））。

ステップ２７０（Ｓ２７０）において、受注者４２は、発注者４０を確認するための処理を行う。
ステップ２７２，２７４（Ｓ２７２，Ｓ２７４）において、金融機関３−１は、受注者４２に対して発注の確認を要求し、受注者４２は、受注を確認する応答を、金融機関３−１に対して返す（図１８，図１９（７），（８））。
ステップ２８０（Ｓ２８０）において、受注者４２は、金融機関３−２から融資を受けるための処理を行う。
ステップ２８２（Ｓ２８２）において、受注者４２は、金融機関３−２に対して、取引ＩＤを含む融資要求を出す（図１８，図２０（９））。

ステップ２９０（Ｓ２９０）において、金融機関３−２は、受注者４２からの取引ＩＤを用いて、発注者４０に与信を与えている金融機関３−１を、ディレクトリ管理・認証機関４４を用いて探しだすなど、受注者４２に対する融資のための処理を行う。
ステップ２９２（Ｓ２９２）において、金融機関３−２は、金融機関３−１に対して、取引ＩＤを含む保証要求を出し、さらに、保証料を支払う（図１８，図２０（１０））。
ステップ３００（Ｓ３００）において、金融機関３−１は、金融機関３−２に対して、取引ＩＤが示す取引の安全を保証するための処理を行う。
ステップ３０２（Ｓ３０２）において、金融機関３−１は、金融機関３−２に対して、取引ＩＤが示す取引の安全を保証する（図１８，図２０（１１））。

ステップ３０４（Ｓ３０４）において、金融機関３−２は、受注者４２に対する融資を行う（図１８，図２０（１２））。
ステップ３１０（Ｓ１３１０）において、受注者４２は、発注者４０からの受注のための処理を行う。
ステップ３１２（Ｓ３１２）において、受注者４２は、発注者４０に対して、受注を通知する（図１５（１３））。

図１８に示した信用取引システム２６において、金融機関３−１は、図１９，図２０に示すように、発注者４０による発注に伴って発生したリスクを負うことにより、発注者４０から与信料の支払いを受けることができ、さらに、金融機関３−２から保証料の支払いを受けることができる。
つまり、信用取引システム２６は、発注者４０の取引に伴うリスクを１回、負うだけで、その後にさらにリスクを負うことなく、複数回の収入の機会を得ることができる。

本発明は、取引における信用を保証する取引システムなどとして利用可能である。

図１は、本発明の前提となる取引を例示する図である。 本発明に係る第１の信用取引システムを例示する図である。 図２に示した企業Ｙ１〜Ｙ４に設定される信用枠を例示する図である。 本発明に係る第２の信用取引システムを例示する図である。 本発明に係る第３の信用取引システムを例示する図である。 モデル化された本発明に係る第４の信用取引システムを示す第１の図である。 図６に示した与信機関、発注者および受注者において用いられるコンピュータのハードウェア構成を例示する図である。 図６に示した与信機関のコンピュータ（図７）上で実行される第１の与信プログラムの構成を示す図である。 図８に示した第１の信用枠管理部が、受注者への支払いのために発注者の信用枠の一部をロックする様子を例示する図である。 図６に示した発注者および受注者のコンピュータ（図７）上で動作する第１の取引者プログラムを示す図である。 図６に示した信用取引システムの全体的な動作（Ｓ１０）を示す通信シーケンス図である。 図６に示した信用取引システムにおける他の取引形態を例示する図である。 複数の信用取引システム（図２）およびディレクトリ管理・認証機関などを含む本発明に係る第５の信用取引システムを例示する図である。 図１３に示した第５の信用取引システムに含まれる信用名前空間および名前空間を例示する図である。 モデル化された本発明に係る第６の信用取引システムを示す図である。 図１５に示した信用取引システムの全体的な動作（Ｓ２０）を示す通信シーケンス図である。 図１４に示した信用取引システムにおける取引の特徴を示す図である。 本発明にかかる第７の信用取引システムの構成を例示する図である。 図１８に示した信用取引システムのノード間のトランザクションを示す第１の図である。 図１８に示した信用取引システムのノード間のトランザクションを示す第２の図である。 図１８に示した信用取引システムの金融機関において実行される第２の与信プログラム３６の構成を示す図である。 図１８に示した受注者において実行される第２の取引者プログラムの構成を示す図である。 図１８に示した信用取引システムの全体的な動作（Ｓ２４）を示す通信シーケンス図である。

符号の説明

１０〜１８，２４・・・信用取引システム、
２０・・・信用名前空間、
２２・・・名前空間、
３・・・与信機関、
１００・・・本体、
１０２・・・ＣＰＵ、
１０４・・・メモリ、
１０６・・・入出力装置、
１１０・・・通信装置、
１１２・・・記録装置、
１１４・・・記録媒体、
３０，３６・・・与信プログラム、
３００・・・ＵＩ部、
３０２・・・認証・通信処理部、
３１０・・・情報管理部、
３１２・・・取引者情報ＤＢ、
３１４・・・取引管理、
３１６・・・取引ＤＢ、
３２０・・・信用枠管理部、
３２２・・・信用枠ＤＢ、
３３０・・・与信審査部、
３３２・・・与信証明部、
３４０・・・資金提供部、
３５０・・・課金部、
３５２・・・課金ＤＢ、
３６０・・・与信料・保証料処理部、
３６２・・・与信料・保証料ＤＢ、
４０・・・発注者、
４２・・・受注者、
４００，４６０・・・取引者プログラム、
４１０・・・フィルタ部、
４２０・・・管理部、
４２２・・・財務処理部、
４３０・・・与信処理部、
４４０・・・発注管理部、
４４２・・・受注管理部、
４６２・・・融資処理部、
４４・・・ディレクトリ管理・認証機関、

Claims (79)

1. 取引の発注および受注またはこれらのいずれかをそれぞれ行う複数の取引者と、前記取引者の１つ以上と接続され、前記取引者の間の取引をそれぞれ保証する１つ以上の保証者とを含む取引システムであって、前記保証者が複数あるときには、これら複数の保証者は相互に接続され、前記取引は、前記取引を発注する取引者（発注者）から前記取引を受注する取引者（受注者）への代償の提供を少なくとも含み、
   前記保証者それぞれは、
   前記接続された取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる見積手段と、
   前記接続された発注者からの要求に応じて、前記見積もられた代償枠に基づいて、前記取引における発注者の代償提供を保証する保証手段と、
   前記発注者により発注された取引を受注しようとする受注者からの要求に応じて、この発注者からの要求に応じてなされた取引における保証を確認する確認手段と
   を有し、
   前記発注者となりうる取引者は、
   前記保証者に対して、取引における前記保証を要求する保証要求手段と、
   前記保証の要求に応じて前記保証がなされた取引を、前記受注者に対して発注する発注手段と
   を有し、
   前記受注者となりうる取引者は、
   受注しようとする取引を発注した発注者と接続された保証者に対して、受注しようとする取引における前記保証の確認を要求する確認要求手段と、
   前記確認の要求に応じて前記保証が確認された取引を、前記発注者から受注する受注手段と
   を有する
   取引システム。
2. 前記保証者および前記取引者は名前空間を構成し、前記名前空間においては、前記取引者それぞれには、前記名前空間における位置の検索に用いられる名前が付され、
   前記取引者に付された名前の指定を受けて、前記指定された名前が付された取引者の前記名前空間における位置を検索して提供する検索者
   をさらに有し、
   前記発注者となりうる取引者は、
   前記検索者に対して受注者の名前を指定して、前記発注者の位置を検索させ、検索の結果として得られた前記受注者の位置の提供を受ける位置検索手段
   をさらに有し、
   前記発注手段は、前記検索の結果として得られた前記発注者の位置を用いて、前記保証がなされた取引を、前記受注者に対して発注する
   請求項１に記載の取引システム。
3. 前記保証者は複数であって、前記複数の保証者それぞれと、これらの保証者それぞれに接続された取引者とは、複数の信用名前空間を構成し、少なくとも前記複数の信用名前空間それぞれにおいては、前記取引者それぞれに一意に名前が付され、前記複数の信用名前空間は、相互に接続されて前記名前空間を構成し、
   前記発注者となりうる取引者の位置検索手段は、同じ前記信用名前空間に前記受注者が含まれないときに、前記検索者に対する前記受注者の位置の検索を行う
   請求項２に記載の取引システム。
4. 前記発注者の代償枠の内、前記取引の発注のために前記受注者に提供されるために確保されていた部分を、前記発注者の代償枠から、受注者自身の代償枠に移転する取立者
   をさらに含む請求項１〜３のいずれかに記載の取引システム。
5. 前記保証者は、前記取立者を兼ねる
   請求項１〜３のいずれかに記載の取引システム。
6. 前記見積もられた代償枠の範囲で、前記取引者それぞれに代償を提供する代償提供者
   をさらに含む請求項１〜３のいずれかに記載の取引システム。
7. 前記保証者は、前記代償提供者を兼ねる
   請求項４に記載の取引システム。
8. 前記保証者の見積手段は、前記発注者となりうる取引者が、前記受注者として提供されうる代償に基づいて、前記取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる
   請求項１〜７のいずれかに記載の取引システム。
9. 前記保証者は、前記発注者に接続され、前記発注者による要求に応じて、この発注者により発注された取引を保証する１つ以上の第１の保証者と、前記受注者と前記第１の保証者とに接続され、前記受注者による要求に応じて、この受注者により受注されようとする取引を保証する１つ以上の第２の保証者とを含み、
   前記第１の保証者それぞれにおいて、
   前記保証手段は、
   前記接続された発注者から、その実施に対して対価を支払うべき要求を受けて、前記見積もられた代償枠に基づいて、前記発注者に対して、前記代償提供を保証し、
   前記接続された第２の保証者から、その実施に対して対価を支払うべき要求を受けて、前記見積もられた代償枠に基づいて、前記第２の保証者に対して、前記代償提供を保証し、
   前記第２の保証者それぞれにおいて、
   前記確認手段は、
   前記接続された受注者からの要求に応じて、その実施に対して対価を支払うべき要求を出して、前記接続された第１の保証者に対して、前記代償提供の保証を要求し、
   前記第１の保証者による代償提供の保証に基づいて、前記受注されようとする取引の保証を、前記受注者に対して確認し、
   前記発注者となりうる取引者において、
   前記保証要求手段は、前記第１の保証者に対して、取引における前記保証を要求し、
   前記受注者となりうる取引者において、
   前記確認要求手段は、前記第２の保証者に対して、受注しようとする取引における前記保証の確認を要求する
   請求項１〜８のいずれかに記載の取引システム。
10. 前記第１の保証者において、
    前記保証手段は、前記要求を受けると、前記発注者からの取引の発注を、前記受注者に対して確認し、前記発注者に対する代償提供の保証を行う
    請求項９に記載の取引システム。
11. 前記受注者となりうる取引者において、
    前記確認要求手段は、前記第２の保証者に対して融資を要求し、
    前記第２の保証者それぞれにおいて、
    前記確認手段は、
    前記第１の保証者による代償提供の保証に基づいて、前記受注者となりうる保証者に対して、前記要求された融資を行う
    請求項９または１０に記載の取引システム。
12. 前記発注者となりうる取引者は、
    前記保証者に対して、前記代償枠の見積に用いられ得る見積情報を開示する情報開示手段
    をさらに有し、
    前記保証者の見積手段は、前記開示された情報にさらに基づいて、前記取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる
    請求項１〜１１のいずれかに記載の取引システム。
13. 前記発注者となりうる取引者の情報開示手段は、前記見積情報として、
    他の取引者との間の取引の状態を示す情報、
    前記他の取引者との間の取引の状態を裏付ける情報、
    前記受注者に対する代償の提供能力を裏付ける情報、および、
    前記受注者に対する代償の提供能力を担保する情報、または
    これらの内の１つ以上の組み合わせ
    を開示する
    請求項１２に記載の取引システム。
14. 前記取引の状態を示す情報には、
    前記受注者として受注した取引において提供される代償、
    前記受注者として受注した取引を発注した取引者、
    前記発注者として発注した取引において提供する代償、および、
    前記発注者として発注した取引受注した取引者、
    前記取引を識別する符号、または
    これらの内の１つ以上の組み合わせ
    が含まれる
    請求項１３に記載の取引システム。
15. 前記保証者は、
    前記取引を識別する符号に基づいて、取引システムで一意な取引識別子を作成する取引識別子作成手段
    をさらに含む
    請求項１４に記載の取引システム。
16. 前記取引は、前記作成された取引識別子により識別される
    請求項１５に記載の取引システム。
17. 前記保証者は、
    前記取引における保証の要求および確認またはこれらのいずれかを行ったときに、前記要求および確認またはこれらのいずれかを行った取引者に対して課金する第１の課金手段
    をさらに有する
    請求項１〜１６のいずれかに記載の取引システム。
18. 前記保証者は、
    前記取引における保証の要求および確認またはこれらのいずれかを行ったときに、前記要求および確認またはこれらのいずれかを行った取引者に対して、前記見積情報の開示の度合いに応じた額を課金する第２の課金手段
    をさらに有する
    請求項１２または１３に記載の取引システム。
19. 前記代償は、通貨である
    請求項１〜１８のいずれかに記載の取引システム。
20. 前記代償は、物である
    請求項１〜１８のいずれかに記載の取引システム。
21. 前記代償は、通貨または物を将来取得する権利である
    請求項１〜１８のいずれかに記載の取引システム。
22. 取引の発注および受注またはこれらのいずれかをそれぞれ行う複数の取引者の１つ以上と接続され、前記取引者の間の取引をそれぞれ保証する保証装置であって、前記保証装置は、他に前記保証装置があるときには、この他の保証装置と接続され、前記取引は、前記取引を発注する取引者（発注者）から前記取引を受注する取引者（受注者）への代償の提供を少なくとも含み、前記発注者となりうる取引者は、前記保証装置に対して、取引における前記保証を要求し、前記保証の要求に応じて前記保証がなされた取引を、前記受注者に対して発注し、前記受注者となりうる取引者は、受注しようとする取引を発注した発注者と接続された保証装置に対して、受注しようとする取引における前記保証の確認を要求し、前記確認の要求に応じて前記保証が確認された取引を、前記発注者から受注し、
    前記接続された取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる見積手段と、
    前記接続された発注者からの要求に応じて、前記見積もられた代償枠に基づいて、前記取引における発注者の代償提供を保証する保証手段と、
    前記発注者により発注された取引を受注しようとする受注者からの要求に応じて、この発注者からの要求に応じてなされた取引における保証を確認する確認手段と
    を有する保証装置。
23. 前記発注者の代償枠の内、前記取引の発注のために前記受注者に提供されるために確保されていた部分を、前記発注者の代償枠から、受注者自身の代償枠に移転する取立手段
    をさらに含む請求項２２に記載の保証装置。
24. 前記見積もられた代償枠の範囲で、前記取引者それぞれに代償を提供する代償提供手段
    をさらに含む請求項２２に記載の保証装置。
25. 前記見積手段は、前記発注者となりうる取引者が、前記受注者として提供されうる代償に基づいて、前記取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる
    請求項２２〜２４のいずれかに記載の保証装置。
26. 前記保証装置の内、第１の保証装置は、前記発注者に接続され、前記発注者による要求に応じて、この発注者により発注された取引を保証し、前記保証装置の内、第２の保証装置は、前記受注者と前記第１の保証装置とに接続され、前記受注者による要求に応じて、この受注者により受注されようとする取引を保証し、前記発注者となりうる取引者は、前記保証要求手段は、前記第１の保証装置に対して、取引における前記保証を要求し、前記受注者となりうる取引者は、前記第２の保証装置に対して、受注しようとする取引における前記保証の確認を要求し、
    前記第１の保証装置それぞれにおいて、
    前記保証手段は、
    前記接続された発注者から、その実施に対して対価を支払うべき要求を受けて、前記見積もられた代償枠に基づいて、前記発注者に対して、前記代償提供を保証し、
    前記接続された第２の保証装置から、その実施に対して対価を支払うべき要求を受けて、前記見積もられた代償枠に基づいて、前記第２の保証装置に対して、前記代償提供を保証し、
    前記第２の保証装置それぞれにおいて、
    前記確認手段は、
    前記接続された受注者からの要求に応じて、その実施に対して対価を支払うべき要求を出して、前記接続された第１の保証装置に対して、前記代償提供の保証を要求し、
    前記第１の保証装置による代償提供の保証に基づいて、前記受注されようとする取引の保証を、前記受注者に対して確認する
    請求項２２〜２５のいずれかに記載の保証装置。
27. 前記第１の保証装置において、
    前記保証手段は、前記要求を受けると、前記発注者からの取引の発注を、前記受注者に対して確認し、前記発注者に対する代償提供の保証を行う
    請求項２６に記載の保証装置。
28. 前記受注者となりうる取引者において、
    前記確認要求手段は、前記第２の保証装置に対して融資を要求し、
    前記第２の保証装置それぞれにおいて、
    前記確認手段は、
    前記第１の保証装置による代償提供の保証に基づいて、前記受注者となりうる保証装置に対して、前記要求された融資を行う
    請求項２６または２７に記載の保証装置。
29. 前記発注者となりうる取引者は、前記保証装置に対して、前記代償枠の見積に用いられ得る見積情報を開示し、
    前記見積手段は、前記開示された情報にさらに基づいて、前記取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる
    請求項２２〜２８のいずれかに記載の保証装置。
30. 前記見積情報は、少なくとも前記取引を識別する符号を含み、
    前記取引を識別する符号に基づいて、取引システムで一意な取引識別子を作成する取引識別子作成手段
    をさらに含む請求項２９に記載の保証装置。
31. 前記取引は、前記作成された取引識別子により識別される
    請求項３０に記載の保証装置。
32. 前記取引における保証の要求および確認またはこれらのいずれかを行ったときに、前記要求および確認またはこれらのいずれかを行った取引者に対して課金する第１の課金手段
    をさらに有する請求項２２〜３１のいずれかに記載の保証装置。
33. 前記取引における保証の要求および確認またはこれらのいずれかを行ったときに、前記要求および確認またはこれらのいずれかを行った取引者に対して、前記見積情報の開示の度合いに応じた額を課金する第２の課金手段
    をさらに有する請求項２９または３０に記載の保証装置。
34. 前記代償は、通貨である
    請求項２６〜３３のいずれかに記載の保証装置。
35. 前記代償は、物である
    請求項２６〜３３のいずれかに記載の保証装置。
36. 前記代償は、通貨または物を将来取得する権利である
    請求項２６〜３３のいずれかに記載の保証装置。
37. 取引の発注および受注またはこれらのいずれかを行う取引装置であって、前記取引は、前記取引を発注する取引装置（発注者）から前記取引を受注する取引装置（受注者）への代償の提供を少なくとも含み、前記取引装置の間の取引を保証する１つ以上の保証者それぞれは、前記取引装置の１つ以上と接続され、前記保証者が複数あるときには、これら複数の保証者は相互に接続され、前記接続された取引装置それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もり、前記接続された発注者からの要求に応じて、前記見積もられた代償枠に基づいて、前記取引における発注者の代償提供を保証し、前記発注者により発注された取引を受注しようとする受注者からの要求に応じて、この発注者からの要求に応じてなされた取引における保証を確認し、
    前記発注者となりうる取引装置は、
    前記保証者に対して、取引における前記保証を要求する保証要求手段と、
    前記保証の要求に応じて前記保証がなされた取引を、前記受注者に対して発注する発注手段と
    を有し、
    前記受注者となりうる取引装置は、
    受注しようとする取引を発注した発注者と接続された保証者に対して、受注しようとする取引における前記保証の確認を要求する確認要求手段と、
    前記確認の要求に応じて前記保証が確認された取引を、前記発注者から受注する受注手段と
    を有する
    取引装置。
38. 前記保証者および前記取引装置は名前空間を構成し、前記名前空間においては、前記取引装置それぞれには、前記名前空間における位置の検索に用いられる名前が付され、前記取引装置に付された名前の指定を受けて、前記指定された名前が付された取引装置の前記名前空間における位置が検索されて提供され、
    前記発注者となりうる取引装置は、
    前記検索者に対して受注者の名前を指定して、前記発注者の位置を検索させ、検索の結果として得られた前記受注者の位置の提供を受ける位置検索手段
    をさらに有し、
    前記発注手段は、前記検索の結果として得られた前記発注者の位置を用いて、前記保証がなされた取引を、前記受注者に対して発注する
    請求項３７に記載の取引装置。
39. 前記保証者は複数であって、前記複数の保証者それぞれと、これらの保証者それぞれに接続された取引装置とは、複数の信用名前空間を構成し、少なくとも前記複数の信用名前空間それぞれにおいては、前記取引装置それぞれに一意に名前が付され、前記複数の信用名前空間は、相互に接続されて前記名前空間を構成し、
    前記発注者となりうる取引装置の位置検索手段は、同じ前記信用名前空間に前記受注者が含まれないときに、前記検索者に対する前記受注者の位置の検索を行う
    請求項３８に記載の取引装置。
40. 前記保証者は、前記発注者に接続され、前記発注者による要求に応じて、この発注者により発注された取引を保証する１つ以上の第１の保証者と、前記受注者と前記第１の保証者とに接続され、前記受注者による要求に応じて、この受注者により受注されようとする取引を保証する１つ以上の第２の保証者とを含み、前記第１の保証者それぞれは、前記接続された発注者から、その実施に対して対価を支払うべき要求を受けて、前記見積もられた代償枠に基づいて、前記発注者に対して、前記代償提供を保証し、前記接続された第２の保証者から、その実施に対して対価を支払うべき要求を受けて、前記見積もられた代償枠に基づいて、前記第２の保証者に対して、前記代償提供を保証し、前記第２の保証者それぞれは、前記接続された受注者からの要求に応じて、その実施に対して対価を支払うべき要求を出して、前記接続された第１の保証者に対して、前記代償提供の保証を要求し、前記第１の保証者による代償提供の保証に基づいて、前記受注されようとする取引の保証を、前記受注者に対して確認し、
    前記発注者となりうる取引者において、
    前記保証要求手段は、前記第１の保証者に対して、取引における前記保証を要求し、
    前記受注者となりうる取引者において、
    前記確認要求手段は、前記第２の保証者に対して、受注しようとする取引における前記保証の確認を要求する
    請求項３７〜３９のいずれかに記載の取引装置。
41. 前記第２の保証者それぞれには、前記第１の保証者による代償提供の保証に基づいて、前記受注者となりうる保証者に対して、前記要求された融資を行い、
    前記受注者となりうる取引者において、
    前記確認要求手段は、前記第２の保証者に対して融資を要求する
    請求項４０に記載の取引装置。
42. 前記保証者は、前記取引を識別する符号に基づいて、一意な取引識別子を作成し、
    前記取引は、前記作成された取引識別子により識別される
    請求項３７〜４１のいずれかに記載の取引装置。
43. 前記発注者となりうる取引装置は、
    前記保証者に対して、前記代償枠の見積に用いられ得る見積情報を開示する情報開示手段
    をさらに有し、
    前記保証者は、前記開示された情報にさらに基づいて、前記取引装置それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる
    請求項３７〜４２のいずれかに記載の取引装置。
44. 前記発注者となりうる取引装置の情報開示手段は、前記見積情報として、
    他の取引装置との間の取引の状態を示す情報、
    前記他の取引装置との間の取引の状態を裏付ける情報、
    前記受注者に対する代償の提供能力を裏付ける情報、および、
    前記受注者に対する代償の提供能力を担保する情報、または
    これらの内の１つ以上の組み合わせ
    を開示する
    請求項４３に記載の取引装置。
45. 前記取引の状態を示す情報には、
    前記受注者として受注した取引において提供される代償、
    前記受注者として受注した取引を発注した取引装置、
    前記発注者として発注した取引において提供する代償、および、
    前記発注者として発注した取引受注した取引装置、
    前記取引を識別する符号、または
    これらの内の１つ以上の組み合わせ
    が含まれる
    請求項４４に記載の取引装置。
46. 前記代償は、通貨である
    請求項３７〜４４のいずれかに記載の取引装置。
47. 前記代償は、物である
    請求項３７〜４４のいずれかに記載の取引装置。
48. 前記代償は、通貨または物を将来取得する権利である
    請求項３７〜４４のいずれかに記載の取引装置。
49. 取引の発注および受注またはこれらのいずれかをそれぞれ行う複数の取引者と、前記取引者の１つ以上と接続され、前記取引者の間の取引をそれぞれ保証する１つ以上の保証者とによる取引方法であって、前記保証者が複数あるときには、これら複数の保証者は相互に接続され、前記取引は、前記取引を発注する取引者（発注者）から前記取引を受注する取引者（受注者）への代償の提供を少なくとも含み、
    前記保証者それぞれは、
    前記接続された取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もり、
    前記接続された発注者からの要求に応じて、前記見積もられた代償枠に基づいて、前記取引における発注者の代償提供を保証し、
    前記発注者により発注された取引を受注しようとする受注者からの要求に応じて、この発注者からの要求に応じてなされた取引における保証を確認し、
    前記発注者となりうる取引者は、
    前記保証者に対して、取引における前記保証を要求し、
    前記保証の要求に応じて前記保証がなされた取引を、前記受注者に対して発注し、
    前記受注者となりうる取引者は、
    受注しようとする取引を発注した発注者と接続された保証者に対して、受注しようとする取引における前記保証の確認を要求し、
    前記確認の要求に応じて前記保証が確認された取引を、前記発注者から受注する
    取引方法。
50. 前記保証者および前記取引者は名前空間を構成し、前記名前空間においては、前記取引者それぞれには、前記名前空間における位置の検索に用いられる名前が付され、
    前記取引者に付された名前の指定を受けて、前記指定された名前が付された取引者の前記名前空間における位置を検索して提供する検索者がさらに存在し、
    前記発注者となりうる取引者は、
    前記検索者に対して受注者の名前を指定して、前記発注者の位置を検索させ、検索の結果として得られた前記受注者の位置の提供を受け、
    前記検索の結果として得られた前記発注者の位置を用いて、前記保証がなされた取引を、前記受注者に対して発注する
    請求項４９に記載の取引方法。
51. 前記保証者は複数であって、前記複数の保証者それぞれと、これらの保証者それぞれに接続された取引者とは、複数の信用名前空間を構成し、少なくとも前記複数の信用名前空間それぞれにおいては、前記取引者それぞれに一意に名前が付され、前記複数の信用名前空間は、相互に接続されて前記名前空間を構成し、
    前記発注者となりうる取引者は、同じ前記信用名前空間に前記受注者が含まれないときに、前記検索者に対する前記受注者の位置の検索を行う
    請求項５０に記載の取引方法。
52. 前記保証者は、前記発注者に接続され、前記発注者による要求に応じて、この発注者により発注された取引を保証する１つ以上の第１の保証者と、前記受注者と前記第１の保証者とに接続され、前記受注者による要求に応じて、この受注者により受注されようとする取引を保証する１つ以上の第２の保証者とを含み、
    前記第１の保証者それぞれは、
    前記接続された発注者から、その実施に対して対価を支払うべき要求を受けて、前記見積もられた代償枠に基づいて、前記発注者に対して、前記代償提供を保証し、
    前記接続された第２の保証者から、その実施に対して対価を支払うべき要求を受けて、前記見積もられた代償枠に基づいて、前記第２の保証者に対して、前記代償提供を保証し、
    前記第２の保証者それぞれは、
    前記接続された受注者からの要求に応じて、その実施に対して対価を支払うべき要求を出して、前記接続された第１の保証者に対して、前記代償提供の保証を要求し、
    前記第１の保証者による代償提供の保証に基づいて、前記受注されようとする取引の保証を、前記受注者に対して確認し、
    前記発注者となりうる取引者は、前記第１の保証者に対して、取引における前記保証を要求し、
    前記受注者となりうる取引者は、前記第２の保証者に対して、受注しようとする取引における前記保証の確認を要求する
    請求項４９〜５１のいずれかに記載の取引方法。
53. 取引の発注および受注またはこれらのいずれかをそれぞれ行う複数の取引者の１つ以上と接続され、前記取引者の間の取引をそれぞれ保証する保証装置におけるプログラムであって、前記保証装置は、他に前記保証装置があるときには、この他の保証装置と接続され、前記取引は、前記取引を発注する取引者（発注者）から前記取引を受注する取引者（受注者）への代償の提供を少なくとも含み、前記発注者となりうる取引者は、前記保証装置に対して、取引における前記保証を要求し、前記保証の要求に応じて前記保証がなされた取引を、前記受注者に対して発注し、前記受注者となりうる取引者は、受注しようとする取引を発注した発注者と接続された保証装置に対して、受注しようとする取引における前記保証の確認を要求し、前記確認の要求に応じて前記保証が確認された取引を、前記発注者から受注し、
    前記接続された取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる見積ステップと、
    前記接続された発注者からの要求に応じて、前記見積もられた代償枠に基づいて、前記取引における発注者の代償提供を保証する保証ステップと、
    前記発注者により発注された取引を受注しようとする受注者からの要求に応じて、この発注者からの要求に応じてなされた取引における保証を確認する確認ステップと
    をコンピュータに実行させるプログラム。
54. 前記発注者の代償枠の内、前記取引の発注のために前記受注者に提供されるために確保されていた部分を、前記発注者の代償枠から、受注者自身の代償枠に移転する取立ステップ
    をさらにコンピュータに実行させる請求項５３に記載のプログラム。
55. 前記見積もられた代償枠の範囲で、前記取引者それぞれに代償を提供する代償提供ステップ
    をさらにコンピュータに実行させる請求項５３に記載の保証装置。
56. 前記見積ステップは、前記発注者となりうる取引者が、前記受注者として提供されうる代償に基づいて、前記取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる
    請求項５３〜５５のいずれかに記載の保証装置。
57. 前記保証装置の内、第１の保証装置は、前記発注者に接続され、前記発注者による要求に応じて、この発注者により発注された取引を保証し、前記保証装置の内、第２の保証装置は、前記受注者と前記第１の保証装置とに接続され、前記受注者による要求に応じて、この受注者により受注されようとする取引を保証し、前記発注者となりうる取引者は、前記保証要求ステップは、前記第１の保証装置に対して、取引における前記保証を要求し、前記受注者となりうる取引者は、前記第２の保証装置に対して、受注しようとする取引における前記保証の確認を要求し、
    前記第１の保証装置それぞれにおいて、
    前記保証ステップは、
    前記接続された発注者から、その実施に対して対価を支払うべき要求を受けて、前記見積もられた代償枠に基づいて、前記発注者に対して、前記代償提供を保証し、
    前記接続された第２の保証装置から、その実施に対して対価を支払うべき要求を受けて、前記見積もられた代償枠に基づいて、前記第２の保証装置に対して、前記代償提供を保証し、
    前記第２の保証装置それぞれにおいて、
    前記確認ステップは、
    前記接続された受注者からの要求に応じて、その実施に対して対価を支払うべき要求を出して、前記接続された第１の保証装置に対して、前記代償提供の保証を要求し、
    前記第１の保証装置による代償提供の保証に基づいて、前記受注されようとする取引の保証を、前記受注者に対して確認する
    請求項５３〜５６のいずれかに記載のプログラム。
58. 前記第１の保証装置において、
    前記保証ステップは、前記要求を受けると、前記発注者からの取引の発注を、前記受注者に対して確認し、前記発注者に対する代償提供の保証を行う
    請求項５７に記載のプログラム。
59. 前記受注者となりうる取引者において、
    前記確認要求ステップは、前記第２の保証装置に対して融資を要求し、
    前記第２の保証装置それぞれにおいて、
    前記確認ステップは、
    前記第１の保証装置による代償提供の保証に基づいて、前記受注者となりうる保証装置に対して、前記要求された融資を行う
    請求項５７または５８に記載のプログラム。
60. 前記発注者となりうる取引者は、前記保証装置に対して、前記代償枠の見積に用いられ得る見積情報を開示し、
    前記見積ステップは、前記開示された情報にさらに基づいて、前記取引者それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる
    請求項５３〜５９のいずれかに記載のプログラム。
61. 前記見積情報は、少なくとも前記取引を識別する符号を含み、
    前記取引を識別する符号に基づいて、取引システムで一意な取引識別子を作成する取引識別子作成ステップ
    をさらにコンピュータに実行させる請求項６０に記載のプログラム。
62. 前記取引は、前記作成された取引識別子により識別される
    請求項６１に記載のプログラム。
63. 前記取引における保証の要求および確認またはこれらのいずれかを行ったときに、前記要求および確認またはこれらのいずれかを行った取引者に対して課金する第１の課金ステップ
    をさらに有する請求項５３〜６２のいずれかに記載のプログラム。
64. 前記取引における保証の要求および確認またはこれらのいずれかを行ったときに、前記要求および確認またはこれらのいずれかを行った取引者に対して、前記見積情報の開示の度合いに応じた額を課金する第２の課金ステップ
    をさらにコンピュータに実行させる請求項６０または６１に記載のプログラム。
65. 前記代償は、通貨である
    請求項５７〜６４のいずれかに記載のプログラム。
66. 前記代償は、物である
    請求項５７〜６４のいずれかに記載のプログラム。
67. 前記代償は、通貨または物を将来取得する権利である
    請求項５７〜６４のいずれかに記載のプログラム。
68. 取引の発注および受注またはこれらのいずれかを行う取引装置におけるプログラムであって、前記取引は、前記取引を発注する取引装置（発注者）から前記取引を受注する取引装置（受注者）への代償の提供を少なくとも含み、前記取引装置の間の取引を保証する１つ以上の保証者それぞれは、前記取引装置の１つ以上と接続され、前記保証者が複数あるときには、これら複数の保証者は相互に接続され、前記接続された取引装置それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もり、前記接続された発注者からの要求に応じて、前記見積もられた代償枠に基づいて、前記取引における発注者の代償提供を保証し、前記発注者により発注された取引を受注しようとする受注者からの要求に応じて、この発注者からの要求に応じてなされた取引における保証を確認し、
    前記発注者となりうる取引装置において、
    前記保証者に対して、取引における前記保証を要求する保証要求ステップと、
    前記保証の要求に応じて前記保証がなされた取引を、前記受注者に対して発注する発注ステップと
    をコンピュータに実行させ、
    前記受注者となりうる取引装置において、
    受注しようとする取引を発注した発注者と接続された保証者に対して、受注しようとする取引における前記保証の確認を要求する確認要求ステップと、
    前記確認の要求に応じて前記保証が確認された取引を、前記発注者から受注する受注ステップと
    をコンピュータに実行させる
    プログラム。
69. 前記保証者および前記取引装置は名前空間を構成し、前記名前空間においては、前記取引装置それぞれには、前記名前空間における位置の検索に用いられる名前が付され、前記取引装置に付された名前の指定を受けて、前記指定された名前が付された取引装置の前記名前空間における位置が検索されて提供され、
    前記発注者となりうる取引装置において、
    前記検索者に対して受注者の名前を指定して、前記発注者の位置を検索させ、検索の結果として得られた前記受注者の位置の提供を受ける位置検索ステップ
    をさらにコンピュータに実行させ、
    前記発注ステップは、前記検索の結果として得られた前記発注者の位置を用いて、前記保証がなされた取引を、前記受注者に対して発注する
    請求項６８に記載のプログラム。
70. 前記保証者は複数であって、前記複数の保証者それぞれと、これらの保証者それぞれに接続された取引装置とは、複数の信用名前空間を構成し、少なくとも前記複数の信用名前空間それぞれにおいては、前記取引装置それぞれに一意に名前が付され、前記複数の信用名前空間は、相互に接続されて前記名前空間を構成し、
    前記発注者となりうる取引装置の位置検索ステップは、同じ前記信用名前空間に前記受注者が含まれないときに、前記検索者に対する前記受注者の位置の検索を行う
    請求項６９に記載のプログラム。
71. 前記保証者は、前記発注者に接続され、前記発注者による要求に応じて、この発注者により発注された取引を保証する１つ以上の第１の保証者と、前記受注者と前記第１の保証者とに接続され、前記受注者による要求に応じて、この受注者により受注されようとする取引を保証する１つ以上の第２の保証者とを含み、前記第１の保証者それぞれは、前記接続された発注者から、その実施に対して対価を支払うべき要求を受けて、前記見積もられた代償枠に基づいて、前記発注者に対して、前記代償提供を保証し、前記接続された第２の保証者から、その実施に対して対価を支払うべき要求を受けて、前記見積もられた代償枠に基づいて、前記第２の保証者に対して、前記代償提供を保証し、前記第２の保証者それぞれは、前記接続された受注者からの要求に応じて、その実施に対して対価を支払うべき要求を出して、前記接続された第１の保証者に対して、前記代償提供の保証を要求し、前記第１の保証者による代償提供の保証に基づいて、前記受注されようとする取引の保証を、前記受注者に対して確認し、
    前記発注者となりうる取引者において、
    前記保証要求ステップは、前記第１の保証者に対して、取引における前記保証を要求し、
    前記受注者となりうる取引者において、
    前記確認要求ステップは、前記第２の保証者に対して、受注しようとする取引における前記保証の確認を要求する
    請求項６８〜７０のいずれかに記載のプログラム。
72. 前記第２の保証者それぞれには、前記第１の保証者による代償提供の保証に基づいて、前記受注者となりうる保証者に対して、前記要求された融資を行い、
    前記受注者となりうる取引者において、
    前記確認要求ステップは、前記第２の保証者に対して融資を要求する
    請求項７１に記載のプログラム。
73. 前記保証者は、前記取引を識別する符号に基づいて、一意な取引識別子を作成し、
    前記取引は、前記作成された取引識別子により識別される
    請求項６８〜７２のいずれかに記載のプログラム。
74. 前記発注者となりうる取引装置は、
    前記保証者に対して、前記代償枠の見積に用いられ得る見積情報を開示する情報開示ステップ
    をさらにコンピュータに実行させ、
    前記保証者は、前記開示された情報にさらに基づいて、前記取引装置それぞれが、前記発注者として、前記受注者に提供可能な代償を示す代償枠を見積もる
    請求項６８〜７３のいずれかに記載のプログラム。
75. 前記発注者となりうる取引装置の情報開示ステップは、前記見積情報として、
    他の取引装置との間の取引の状態を示す情報、
    前記他の取引装置との間の取引の状態を裏付ける情報、
    前記受注者に対する代償の提供能力を裏付ける情報、および、
    前記受注者に対する代償の提供能力を担保する情報、または
    これらの内の１つ以上の組み合わせ
    を開示する
    請求項７４に記載のプログラム。
76. 前記取引の状態を示す情報には、
    前記受注者として受注した取引において提供される代償、
    前記受注者として受注した取引を発注した取引装置、
    前記発注者として発注した取引において提供する代償、および、
    前記発注者として発注した取引受注した取引装置、
    前記取引を識別する符号、または
    これらの内の１つ以上の組み合わせ
    が含まれる
    請求項７５に記載のプログラム。
77. 前記代償は、通貨である
    請求項６８〜７５のいずれかに記載のプログラム。
78. 前記代償は、物である
    請求項６８〜７５のいずれかに記載のプログラム。
79. 前記代償は、通貨または物を将来取得する権利である
    請求項６８〜７５のいずれかに記載のプログラム。

Images