(57)【要約】　【課題】　希望した取引を安心して履行できる。　【解決手段】　サーバは、顧客コンピュータからある希望取引の条件を受信すると（Ｓ３５０でＹＥＳ）、その希望取引を書き込んだ顧客の信頼性を与信限度額に基づいて判断し（Ｓ３６０）、信頼性があるならば（Ｓ３６０でＹＥＳ）、それと同じ案件で有利な条件のものが掲示されていない限り登録され（Ｓ３８０〜Ｓ４３０）、以後、その希望取引は電子掲示板にその顧客の者としてではなく、サーバ管理者である銀行が呈示するものとして掲示される。【選択図】　図８
2004005731.tif 000002
【特許請求の範囲】
【請求項１】
顧客コンピュータとネットワークを介して接続されたサーバを用いて電子商取引を行う電子商取引システムにおいて、
　前記サーバは、いずれかの顧客コンピュータからある希望取引の条件を受信すると、その顧客の信頼性を判断し、信頼性があるならば、その希望取引をその顧客のものとしてではなく自己のものとして自己の電子掲示板に掲示することを特徴とする電子商取引システム。
【請求項２】
請求項１記載の電子商取引システムであって、
　前記サーバは、自己の電子掲示板に掲示された希望取引に対していずれかの顧客コンピュータから取引成約の申し出を受信すると、その申し出た顧客の信頼性を判断し、信頼性があるならば、その取引を許可する電子商取引システム。
【請求項３】
請求項１又は２記載の電子商取引システムであって、
　前記サーバは、顧客の信頼性をチェックするに際し、その顧客の今回の取引与信額を含めたその顧客の総与信額が、予め定められたその顧客の与信限度額内に収まっているかどうかを判断し、収まっているならば信頼性があると判断する電子商取引システム。
【請求項４】
請求項３記載の電子商取引システムであって、
　前記総与信額は、その顧客の今回の取引与信額と、自己の電子掲示板に掲示中のその顧客の取引与信額と、約定済みだが未だ信用取引期間が満了していないその顧客の取引残高の与信額とを合算したものである電子商取引システム。
【請求項５】
請求項１〜４のいずれかに記載の電子商取引システムであって、
　前記サーバは、今回受信した希望取引と価格のみが異なり他の条件が全て同じものが自己の電子掲示板に既に掲示されているか否かを判断し、既に掲示されているならば、取引相手にとって有利な価格が付けられているものを優先して掲示する電子商取引システム。
【請求項６】
請求項５記載の電子商取引システムであって、
　前記サーバは、今回受信した希望取引と価格のみが異なり他の条件が全て同じものが自己の電子掲示板に既に掲示されているか否かを判断し、既に掲示されているならば、いずれが取引相手にとって有利な価格かを判断し、既に掲示されているものの方が有利な価格ならば、今回受信したものを掲示せず、逆に、今回受信したものの方が有利な価格ならば、既に掲示されているものと差し替える一方で、その顧客へ電子掲示板から削除した旨を通知する電子商取引システム。
【請求項７】
請求項１〜６のいずれかに記載の電子商取引システムであって、
　前記サーバは、サーバ管理者自らの希望取引を自己の電子掲示板に掲示可能である電子商取引システム。
【請求項８】
請求項１〜７のいずれかに記載の電子商取引システムであって、
　前記サーバは、銀行が管理する電子商取引システム。
【請求項９】
請求項１〜８のいずれかに記載の電子商取引システムであって、
　前記取引は、クレジットデリバティブである電子商取引システム。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、顧客コンピュータとネットワークを介して接続されたサーバを用いて電子商取引を行う電子商取引システムに関する。
【背景技術】
【０００２】
　従来、インターネットを利用して顧客が取引ニーズを書き込み、売りサイドと買いサイドを仲介するシステムとして、オークションタイプのものや逆オークションタイプのものが知られている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
　しかしながら、このようなシステムでは、売り・買い当事者間の取引となることから、顧客は取引相手をなかなか確定できないことに加え、取引相手の信用状態や、取引商品が本当に条件通りのものかなどの判断がつきにくい場合が多く、トラブル発生の要因となっていた。
【０００４】
　本発明は上記問題点を解決することを課題とするものであり、希望した取引を安心して履行できる電子商取引システムを提供することを目的とする。
【課題を解決するための手段】
【０００５】
　上記課題を解決するため、本発明は、顧客コンピュータとネットワークを介して接続されたサーバを用いて電子商取引を行う電子商取引システムにおいて、前記サーバは、いずれかの顧客コンピュータから希望取引を受信すると、その顧客の信頼性を判断し、信頼性があるならば、その希望取引をその顧客のものとしてではなく自己のものとして自己の電子掲示板に掲示することを特徴とする。
【０００６】
　本発明は例えば次のように利用される。即ち、ある顧客がこのサーバの電子掲示板に掲載された各希望取引を閲覧し、自分自身のニーズに合った希望取引があるかどうかを調べ、具体的な取引ニーズがあるもののサーバの電子掲示板上にはそれに合致するものがない場合、その顧客は自分のコンピュータからサーバの電子掲示板に希望取引を書き込む。サーバは、その顧客コンピュータからある希望取引の条件を受信すると、その希望取引を書き込んだ顧客の信頼性を判断し、信頼性があるならば、その希望取引をその顧客のものとしてではなく、サーバ管理者のものとして、自己の電子掲示板上に掲示する。
【０００７】
　このように、本発明によれば、サーバ管理者が顧客の信用を保証する形で、顧客の希望取引をサーバ管理者の希望取引として自己の電子掲示板上に掲示するため、その希望取引に対して成約の申し出をしようとする顧客は安心して取引を履行できるという効果が得られる。
【０００８】
　本発明の電子商取引システムにおいて、サーバは、自己の電子掲示板に掲示された希望取引に対していずれかの顧客コンピュータから成約の申し出を受信すると、その申し出た顧客の信頼性を判断し、信頼性があるならば、その取引を許可することが好ましい。この場合、取引成約の申し出をする顧客の信頼性がある場合のみその取引を許可するため、トラブルの発生が抑えられる。なお、このとき、サーバ管理者は、希望取引を書き込んだ顧客及びその取引の成約を申し出た顧客のカウンターパーティ（仲介者）として取引を行ってもよい。そうすることにより、取引を希望する両顧客は自分の取引相手方を常にサーバ管理者として確定できるため、安心して取引をすることができる。その場合にはサーバが両方の顧客コンピュータと取引作業を実行するようにしてもよい。
【０００９】
　本発明の電子商取引システムにおいて、サーバは、顧客の信頼性をチェックするに際し、その顧客の今回の取引与信額を含めたその顧客の総与信額が、予め定められたその顧客の与信限度額に収まっているかどうかを判断し、収まっているならば信頼性があると判断することが好ましい。ここで、与信限度額とは、顧客の信用状況を判断して定められた顧客ごとの与信の最高額をいう。顧客が新たな希望取引を書き込む際には、電子掲示板上にその顧客ではなくサーバ管理者の希望取引として掲示されることから、サーバ管理者としても顧客の信用度に応じてその希望取引をその顧客が行ううえでの適正を見定める必要がある。その適正判断の一方法として、その顧客の総与信額がその顧客の与信限度額を超えているか否かをチェックするのである。与信限度額は、信用調査に基づいて定められているため、この与信限度額の範囲内であれば安心して取引できるという利点がある。
【００１０】
　このとき、総与信額は、その顧客の今回の取引与信額と、自己の電子掲示板に掲示中のその顧客の取引与信額と、約定済みだが未だ信用取引期間が満了していないその顧客の取引残高の与信額とを合算したものであることが好ましい。
【００１１】
　本発明の電子商取引システムにおいて、サーバは、今回受信した希望取引と価格のみが異なり他の条件が全て同じものが自己の電子掲示板に既に掲示されているか否かを判断し、既に掲示されているならば、取引相手にとって有利な価格が付けられているものを優先して掲示することが好ましい。この場合、取引相手の利益が優先されるため、取引の活性化が図られる。
【００１２】
　また、今回受信した希望取引と価格のみが異なり他の条件が全て同じものが自己の電子掲示板に既に掲示されているとき、既に掲示されているものの方が有利な価格ならば、今回受信したものを掲示せず、逆に、今回受信したものの方が有利な価格ならば、既に掲示されているものと差し替える一方で、その顧客へ電子掲示板から削除した旨を通知することが好ましい。この場合、既に掲示されていた希望取引が顧客の知らないうちに削除されてしまうことがないため、顧客が困惑することがない。なお、既に掲示されているものの方が有利な価格の場合には、今回希望取引を書き込んだ顧客のコンピュータに対して書き込みできない旨のメッセージを送ることが好ましい。
【００１３】
　本発明の電子商取引システムにおいて、サーバは、サーバ管理者自らの希望取引を自己の電子掲示板に掲示可能であることが好ましい。この場合、電子掲示板に掲示される品揃えの拡充を図ることができる。
【００１４】
　本発明の電子商取引システムにおいて、サーバは銀行が管理することが好ましい。この場合、電子掲示板上の希望取引は銀行が呈示しているものとして掲示されるが、一般に銀行は顧客からの信用度が高いため、安心して取引をすることができる。特に、銀行が、希望取引を書き込んだ顧客及びその希望取引の注文をした顧客のカウンターパーティ（仲介者）として取引を行う場合、取引を希望する顧客は自分の取引相手方を常に銀行として確定できるため、安心して取引をすることができる。
【００１５】
　本発明の電子商取引システムにおいて、取引は特にどのような商品やサービスを対象としてもよいが、クレジットデリバティブであることが好ましい。クレジットデリバティブとは、ローンや証券といった金融取引に内在する信用リスクに着目し、その信用リスク部分を原資産から抽出することによってその移転を可能にする金融派生商品をいう。本発明の電子商取引システムは、このようなクレジットデリバティブの取引に適しているため、クレジットデリバティブの市場の拡大に役立つ。
【００１６】
　ここで、クレジットデリバティブの具体例について説明する。例えば、Ａ社がＢ社の債権を持っているが、Ｂ社のイベント時（倒産や支払不履行などの信用毀損事由発生時）にはそれらが不良債権になってしまう。その危険を回避すべく、Ｂ社のイベント時に元本を保証してほしい、その代わりプレミアム（手数料）を払うと希望することがある。この場合、Ａ社は、プレミアムを払ってプロテクションを購入することを希望しているという。Ａ社はプレミアムを支払うことになるが、一括払いするのであれば与信額はゼロ、分割払いするのであればそのプレミアム支払い総額を基にして与信額が算出される。
【００１７】
　一方、Ｃ社はＤ社にイベントが発生するとは考えていないとき、運用利回りを上げるために、Ｄ社の債権保有者に対してＤ社のイベント時にはその元本を保証してあげる、その代わりプレミアムを受けたいと希望することがある。この場合、Ｃ社はプレミアムを受け取ってプロテクションを売却することを希望しているという。Ｃ社はイベント時にＤ社の債権の元本を支払うことになるので、その元本・期間・債権の銘柄に応じた与信額が算出される。
【発明を実施するための最良の形態】
【００１８】
　以下に、本発明の好適な実施形態を図面に基づいて説明する。図１は、本実施形態の装置構成の概略説明図である。
　本実施形態は、銀行が管理するサーバ１０と、その銀行の顧客が管理する顧客コンピュータ２０と、サーバ１０及び各顧客コンピュータ２０を接続するインターネット３０から構成されている。
【００１９】
　サーバ１０は、通信回線３１を介してインターネット３０に接続されている。このサーバ１０は、インターネット３０を介して、記憶装置１１内の取引案件データベースから電子掲示板の掲示内容を顧客コンピュータ２０に出力したり、記憶装置１１内の顧客管理用データベースから顧客情報を読み出して各種処理を行ったり、その顧客管理用データベースに顧客情報を保存又は更新したり、顧客コンピュータ２０から受信した情報に基づいて各種処理を行ったりする。
【００２０】
　顧客コンピュータ２０は、インターネットプロバイダへのダイヤルアップ用通信回線３２を介してインターネット３０に接続されている。この顧客コンピュータ２０を管理する顧客には、サーバ１０を管理する銀行から、その銀行の会員専用ホームページを閲覧するためのパスワードとユーザＩＤが予め与えられている。
【００２１】
　次に、顧客がサーバ管理者である銀行のホームページを利用する手順の概略について説明する。（１）まず、サーバ管理者である銀行よりパスワードとユーザＩＤを受け取ったあと、そのパスワードとユーザＩＤを使ってその銀行の会員専用ホームページにアクセスし、その銀行の電子掲示板上に掲示された各希望取引の価格を閲覧し、自分自身のニーズにあった希望取引があるかどうかを調べる。（２）そして、自分自身のニーズにあった希望取引があったならば、ホームページ上から取引成約を申し出る。一方、自分自身のニーズにあった希望取引がなければ、電子掲示板にその希望取引を書き込む。（３）但し、取引成約申し出時や希望取引書き込み時において、その取引の与信額を加えたその顧客の総与信額がその顧客の与信限度額を上回ると、その顧客の信頼性に問題があるため、成約申し出や取引書き込みが拒否される。また、電子掲示板上には顧客の名前は表示されず、サーバ管理者である銀行が成約を申し出たもの又は希望取引を書き込んだものとして電子掲示板に掲示される。
【００２２】
　次に、顧客がサーバ管理者である銀行のホームページを利用する手順の詳細について、図２の取引制御プログラムのフローチャートに基づいて説明する。なお、以下には、便宜上、サーバ１０を主体として説明する。また、クレジットデリバティブの取引について説明する。
【００２３】
　サーバ１０は、所定タイミングごとに取引制御プログラムを読み出し、このプログラムを実行する。まず、サーバ１０は、ステップ（以下「Ｓ」と略す）１００において、顧客コンピュータ２０からパスワードとユーザＩＤを受信したか否か、つまり、顧客コンピュータ２０においてパスワードとユーザＩＤが入力されたか否かを判断し、受信していなければ（Ｓ１００でＮＯ）、このプログラムを終了する。
【００２４】
　一方、パスワードとユーザＩＤを受信したならば（Ｓ１００でＹＥＳ）、そのパスワードとユーザＩＤが適正か否かを判断する（Ｓ１１０）。ここで、サーバ１０の顧客管理用データベースには、予め顧客ごとにパスワードとユーザＩＤが登録されているため、今回受信したパスワードとユーザＩＤが顧客管理用データベースに登録されているか否かによって、適正か否かを判断する。そして、パスワードとユーザＩＤが不適正ならば（Ｓ１１０でＮＯ）、エラーメッセージとして例えば「パスワードとユーザＩＤが不適正です。」等を顧客コンピュータ２０へ送信し（Ｓ１２０）、このプログラムを終了する。すると、顧客コンピュータ２０のディスプレイにはエラーメッセージが表示されるため、顧客は入力ミスしたことを認識できる。なお、文字データの代わりに音声データでメッセージを送信してもよい。
【００２５】
　一方、パスワードとユーザＩＤが適正ならば（Ｓ１１０でＹＥＳ）、その顧客コンピュータ２０へ会員専用ホームページのトップページを送信する（Ｓ１３０）。すると、顧客コンピュータ２０のディスプレイには、図３に示すトップページが表示される。このトップページにはメニュー一覧が表示され、「本日のプライスインディケーション」、「掲示板入力内容の確認等」等のメニューが表示されている。続いて、サーバ１０は、顧客コンピュータ２０からいずれかのメニューが要求されたか否か、つまり、顧客コンピュータ２０においてメニュー一覧の中からいずれかのメニューがクリックされたかを判断し（Ｓ１４０）、いずれのメニューも要求されていなければ（Ｓ１４０でＮＯ）、後述するＳ１６０へ進む。一方、いずれかのメニューが要求されたならば（Ｓ１４０でＹＥＳ）、要求されたメニューに応じたルーチンを実行し（Ｓ１５０）、その後Ｓ１６０に進んで終了信号が送信されてきたか否か、つまり終了ボタン（図示略）がクリックされたか否かを判断し、終了信号が送信されてなければ（Ｓ１６０でＮＯ）、再びＳ１４０に戻り、終了信号が送信されたならば（Ｓ１６０でＹＥＳ）、このプログラムを終了する。
【００２６】
　次に、トップページのメニュー一覧で「本日のプライスインディケーション」がクリックされたときに実行される呈示ルーチンについて、図４のフローチャートに基づいて説明する。このルーチンが開始されると、サーバ１０は顧客コンピュータ２０へ電子掲示板の情報を送信する（Ｓ２００）。すると、顧客コンピュータ２０のディスプレイには、例えば図５に示すような電子掲示板が表示される。この電子掲示板には、「２０００年○月×日の当行のプライスインディケーションです。」と記載され、例えば銘柄名「Ａ」、商品名「○○○」が売却希望取引として掲示されている。つまり、これらの希望取引がサーバ管理者である銀行の呈示しているものとして掲示されている。
【００２７】
　続いて、顧客コンピュータ２０から取引明細の要求があったか否か、つまり、顧客コンピュータ２０において図５の電子掲示板の各取引の選択ボックスがチェックされた状態で「取引明細」ボタンがクリックされたか否かを判断し（Ｓ２１０）、否定判断されたならば（Ｓ２１０でＮＯ）、Ｓ２８０へ進む。一方、肯定判断されたならば（Ｓ２１０でＹＥＳ）、取引明細要求のあった取引を取引データベースから読み出し、その内容を顧客コンピュータ２０へ送信する（Ｓ２２０）。例えば銘柄名「Ａ」、商品名「○○○」の選択ボックスがチェックされた状態で「取引明細」ボタンがクリックされたならば、顧客コンピュータ２０のディスプレイには、図６に示すような取引明細が表示される。
【００２８】
　続いて、顧客コンピュータ２０から取引成約の申し出があったか否か、即ち、顧客コンピュータ２０において図６の取引明細の欄外にある「取引成約希望」ボタンがクリックされたか否かを判断し（Ｓ２３０）、取引成約の申し出がなければ（Ｓ２３０でＮＯ）、前画面への戻り要求があったか否かを判断し（Ｓ２３５）、戻り要求がなければ（Ｓ２３５でＮＯ）、再びＳ２３０以下を繰り返し、戻り要求があったならば（Ｓ２３５でＹＥＳ）、Ｓ２００へ戻る。一方、取引成約の申し出があったならば（Ｓ２３０でＹＥＳ）、今回の取引与信額を含めたその顧客の総与信額が、予め定められたその顧客の与信限度額内に収まっているかどうかを判断する（Ｓ２４０）。
【００２９】
　具体的には、顧客管理用データベースから、その顧客が現在電子掲示板に掲示中の取引与信額（書き込み済の取引与信額）、約定済みだが未だ信用取引期間が満了していないその顧客の取引残高の与信額（既取引残高の与信額）、及び、その顧客の与信限度額を読み出し、前二者に今回の取引与信額を含めた額つまりその顧客の総与信額がその顧客の与信限度額内に収まっているかどうかを判断する。これを式で表せば、下記数１式を満たすか否かを判断するということになる。
【００３０】
【数１】
2004005731.tif 000003
【００３１】
　ところで、与信額の算出方法は種々考えられるが、ここではその一例についてクレジットデリバティブのデフォルトスワップを例に挙げて図７に基づいて説明する。デフォルトスワップには、顧客がプロテクションを購入する場合とプロテクションを売却する場合がある。まず、プロテクションを購入する場合、顧客は保有債権の元本を第三者に保証してもらう代わりに平常時にプレミアムを支払うため、そのプレミアムの支払い能力が問題になる。ここで、プレミアムが一括払いの場合には約定時に支払いが完了するため、与信額はゼロである。一方、プレミアムが分割払いの場合には約定後にもプレミアムを払い続ける必要があるため、取引の全期間に渡って支払うプレミアムの総額を基にして与信額を算出する。
【００３２】
　次に、プロテクションを売却する場合、顧客は保証しようとする債権の元本を保証することから、イベント時（倒産時や支払不履行発生時）には保有債権をデフォルト資産として引き渡してもらう代わりにその元本を支払う必要があるため、その元本の支払い能力が問題になる。この場合、外部格付け機関による債権銘柄のランクと取引期間に基づいたリスク率を決定し、更に元本金額とリスク率を考慮して与信額を算出する。また、ランクが優良であるほど、また取引年数が短いほど、リスク率は低くなる。
【００３３】
　与信限度額は各顧客ごとにその顧客の信用状況や取引規模などに基づいて定められた額であるが、この与信限度額の算出方法も種々考えられる。例えば、顧客の信用状況としては外部格付け機関によるランクを利用することが考えられる。
【００３４】
　さて、Ｓ２４０において、その顧客の総与信額がその顧客の与信限度額内に収まっていなければ（Ｓ２４０でＮＯ）、その顧客コンピュータ２０へエラーメッセージ（例えば「与信限度額オーバーで書き込みできません。」等）を送信し（Ｓ２５０）、その後Ｓ２８０へ進む。すると、その顧客コンピュータ２０のディスプレイにはエラーメッセージが表示されるため、顧客はなぜ書き込みできなかったことを認識できる。一方、その顧客の総与信額がその顧客の与信限度額内に収まっているならば（Ｓ２４０でＹＥＳ）、つまり上記数１式が満たされているならば、その取引成約を申し出た顧客及びその取引を書き込んだ顧客の両方の顧客コンピュータ２０に対してその取引が成立した旨を送信し（Ｓ２６０）、顧客管理用データベースのうち、取引成約を申し出た顧客及びその取引を書き込んだ顧客のそれぞれのデータを更新し（Ｓ２７０）、その後Ｓ２８０へ進む。Ｓ２８０では、顧客コンピュータ２０から終了信号が送信されたか否か、即ち終了ボタン（図示略）がクリックされたか否かを判断し、終了信号が送信されていなければ（Ｓ２８０でＮＯ）、再びＳ２００に戻り、終了信号が送信されたならば（Ｓ２８０でＹＥＳ）、顧客コンピュータ２０へトップページを送信したうえでこのルーチンを終了する。
【００３５】
　ここで、Ｓ２７０のデータ更新について更に詳しく説明する。まず、取引成約を申し出た顧客については、既取引残高の与信額が更新される。即ち、その顧客がプロテクションを購入した場合には、取引の全期間に渡って支払うプレミアムの総額を基にして算出された与信額を加えた値に更新され、プロテクションを売却した場合には、元本金額とリスク率を考慮して算出された与信額を加えた値に更新される。一方、取引を書き込んだ顧客については、既取引残高の与信額及び書き込み済の取引与信額が更新される。即ち、書き込み済の取引与信額のうち今回約定された取引与信額分が既取引残高の与信額に振り替えられる。
【００３６】
　次に、トップページのメニュー一覧で「掲示板入力内容の確認等」がクリックされたときに実行される確認ルーチンについて、図８のフローチャートに基づいて説明する。なお、顧客は、現在電子掲示板に自分自身が掲示している内容を確認したり変更したりするときに、「掲示板入力内容の確認等」をクリックする。サーバ１０は、このルーチンが開始されると、その顧客が電子掲示板に現在掲示中の内容をその顧客コンピュータ２０へ送信する（Ｓ３００）。すると、顧客コンピュータ２０のディスプレイには、例えば図９に示すような「お客様による現在の掲載内容」が一覧表示される。この一覧表には、「現在、掲示板に掲載されているお客様の希望取引は以下の通りです。」と記載され、例えば銘柄名「Ａ」、商品名「○○○」が売却希望取引として掲示され、その他に２件の取引が掲示されている。また、画面下側には、「変更」、「削除」、「追加」の各ボタンが表示されている。
【００３７】
　サーバ１０は、顧客コンピュータ２０から「変更」、「削除」、「追加」のいずれかの要求がなされたか否か、即ち、顧客コンピュータ２０においてこれらのボタンのうちいずれかがクリックされたか否かを判断し（Ｓ３１０）、いずれも要求されていなければ（Ｓ３１０でＮＯ）、Ｓ４６０へ進む。一方、いずれかが要求されたならば、いずれが要求されたかを判断する（Ｓ３２０）。
【００３８】
　このＳ３２０で「追加」が要求されたならば、新たな希望取引の条件を入力する画面（条件入力画面）を顧客コンピュータ２０へ送信する（Ｓ３３０）。すると、顧客コンピュータ２０のディスプレイには、図１０の条件入力画面が表示される。続いてサーバ１０は、顧客コンピュータ２０から新たな希望取引の条件を受信したか否か、即ち、図１０の条件入力画面において顧客が四角枠内に数値等を入力したあと登録ボタンをクリックしたか否かを判断し（Ｓ３５０）、否定判断されたならば（Ｓ３５０でＮＯ）、そのまま待機し、肯定判断されたならば（Ｓ３５０でＹＥＳ）、今回の取引与信額を含めたその顧客の総与信額が、予め定められたその顧客の与信限度額内に収まっているかどうかを判断する（Ｓ３６０）。具体的には、前述の呈示ルーチンのＳ２４０と同様、上記数１式を満たすか否かを判断する。また、今回入力された希望取引の与信額の算出も前述の呈示ルーチンと同様、今回の取引がプロテクションの購入ならば、取引の全期間に渡って支払うプレミアムの総額を基にして与信額を算出し、今回の取引がプロテクションの売却ならば、元本金額とリスク率を考慮して与信額を算出する。
【００３９】
　そして、Ｓ３６０において、その顧客の総与信額がその顧客の与信限度額内に収まっていなければ（Ｓ３６０でＮＯ）、エラーメッセージ（例えば「与信限度額オーバーで書き込みできません。」等）を顧客コンピュータ２０へ送信し（Ｓ３７０）、その後Ｓ４６０へ進む。Ｓ３７０により、その顧客コンピュータ２０のディスプレイにはエラーメッセージが表示されるため、顧客は書き込みできなかったことを認識する。一方、その顧客の総与信額がその顧客の与信限度額内に収まっていれば（Ｓ３６０でＹＥＳ）、Ｓ３８０へ進む。
【００４０】
　Ｓ３８０では、プレミアムだけが異なる希望取引が既に電子掲示板に呈示されているか否かを判断し、そのような取引が呈示されていないならば（Ｓ３８０でＮＯ）、今回の希望取引を取引案件データベースに加えると共に顧客管理用データベースのその顧客のデータを更新し（Ｓ４２０）、更にその顧客コンピュータ２０に今回の希望取引を登録した旨を送信し（Ｓ４３０）、Ｓ４６０へ進む。これ以後、いずれかの顧客コンピュータ２０において「本日のプライスインディケーション」が開かれると、電子掲示板には今回の希望取引が呈示されることになる。なお、Ｓ４２０では、顧客管理用データベースにつき、その顧客の書き込み済与信額を今回の取引与信額を加えた値に更新する。
【００４１】
　一方、プレミアムだけが異なる希望取引が既に電子掲示板に呈示されているならば（Ｓ３８０でＹＥＳ）、今回の希望取引の方が取引相手にとって有利か否かを判断する（Ｓ３９０）。具体的には、希望取引がプロテクションの購入ならば、プレミアムの高い方が取引相手（プロテクションを売却する側）にとって有利であり、希望取引がプロテクションの売却ならば、プレミアムの低い方が取引相手（プロテクションを購入する側）にとって有利である。
【００４２】
　そして、今回の希望取引の方が取引相手にとって不利ならば（Ｓ３９０でＮＯ）、今回希望取引を送信してきた顧客コンピュータ２０へエラーメッセージ（例えば「既に同じ希望取引がより有利な条件で掲示されていますので書き込みできません」等）を送信し（Ｓ４１０）、その後Ｓ４６０へ進む。Ｓ４１０により、その顧客コンピュータ２０のディスプレイにはそのエラーメッセージが表示されるため、顧客はなぜ書き込みできなかったかを認識できる。一方、今回の希望取引の方が取引相手にとって有利ならば（Ｓ３９０でＹＥＳ）、既にその希望取引を書き込んでいた顧客の顧客コンピュータ２０へエラーメッセージ（例えば「同じ希望取引がより有利な条件で掲示されましたので削除しました」等）を送信し（Ｓ４００）、その後既に述べたＳ４２０以降の処理を行う。
【００４３】
　さて、Ｓ３２０に戻り、「変更」が要求されたならば、選択された希望取引（図９の選択ボタンがチェックされている取引）の条件が記入されている画面（条件変更画面）を顧客コンピュータ２０へ送信する（Ｓ３４０）。このとき、顧客コンピュータ２０のディスプレイには図１０と類似の画面、つまり図１０の四角枠の項目が埋められている画面が表示される。続くＳ３５０において、サーバ１０は、顧客コンピュータ２０から変更後の希望取引の条件を受信したか否か、つまり、変更したい項目の四角枠に上書きしたうえで登録ボタンをクリックしたか否かを判断し、その後は既に述べたＳ３６０以降の処理を実行する。
【００４４】
　また、Ｓ３２０において「削除」が要求されたならば、選択された希望取引を取引案件データベースから削除すると共に、顧客管理用データベースのその顧客の書き込み済与信額につき、削除した取引与信額を差し引いた値に更新する（Ｓ４４０）。そして、選択された希望取引の削除が完了した旨を顧客コンピュータ２０へ送信し（Ｓ４５０）、Ｓ４６０へと進む。
【００４５】
　最後にＳ４６０では、顧客コンピュータ２０から終了信号が送信されたか否か、即ち終了ボタン（図示略）がクリックされたか否かを判断し、終了信号が送信されていなければ（Ｓ４６０でＮＯ）、再びＳ３００に戻り、終了が送信信号されたならば（Ｓ４６０でＹＥＳ）、顧客コンピュータ２０へトップページを送信したうえでこのルーチンを終了する。
【００４６】
　次に、本実施形態の一具体例を説明する。ある顧客が自分の顧客コンピュータ２０からパスワードとユーザＩＤを適正に入力すると、サーバ１０は会員専用ホームページのトップページをその顧客コンピュータ２０へ送信する（Ｓ１００〜Ｓ１３０）。すると、顧客コンピュータ２０のディスプレイには図３のトップページが表示される。ここで、その顧客がメニュー一覧から「本日のプライスインディケーション」をクリックすると、サーバ１０は図４の呈示ルーチンを実行し、電子掲示板情報をその顧客コンピュータ２０へ送信する（Ｓ２００）。すると、顧客コンピュータ２０のディスプレイには図５の電子掲示板が表示されるので、その顧客は電子掲示板に掲載された各希望取引を閲覧し、自分自身のニーズに合った希望取引があるかどうかを調べる。
【００４７】
　このとき、具体的な取引ニーズがあるもののサーバ１０の電子掲示板上にはそれに合致するものがない場合、その顧客は電子掲示板の表示を終了する操作を行う。すると、サーバ１０は顧客コンピュータ２０へトップページを送信し、呈示ルーチンを終了する。そして、今度はメニュー一覧から「掲示板入力内容の確認等」をクリックすると、サーバ１０は図８の確認ルーチンを実行し、その顧客の掲示内容を送信する（Ｓ３００）。すると、顧客コンピュータ２０のディスプレイには図９の画面が表示される。次いでその顧客は、この画面の「追加」をクリックし、これによって表示される図１０の条件入力画面に希望取引の条件を入力し、「登録」をクリックすると、サーバ１０は、今回の希望取引の与信額を含むその顧客の総与信額がその顧客の与信限度額内に収まっているか否かを判断し（Ｓ３６０）、収まっていなければエラーメッセージを送信し（Ｓ３７０）、収まっていれば同じ案件で有利な条件のものが掲示されていない限り登録され（Ｓ３８０〜Ｓ４３０）、以後、この電子掲示板にその銀行が呈示する希望取引として掲示される。つまり、サーバ１０は、顧客コンピュータ２０から希望取引を受信すると、その希望取引を書き込んだ顧客の信頼性を与信限度額に基づいて判断し、信頼性があるならば、その希望取引をその顧客のものとしてではなく、サーバ管理者である銀行のものとして、自己の電子掲示板上に掲示する。
【００４８】
　一方、電子掲示板上に、その顧客がもつ具体的な取引ニーズと合致するものがある場合、その希望取引につき取引明細を要求し、図６のような取引明細を調べた上で「取引成約希望」ボタンをクリックする。すると、サーバ１０は、今回の希望取引の与信額を含むその顧客の総与信額がその顧客の与信限度額内に納まっているか否かを判断し（Ｓ２４０）、収まっていなければエラーメッセージを送信し（Ｓ２５０）、収まっていればサーバ管理者である銀行が仲介して取引を行う。つまり、サーバ１０は、顧客コンピュータから取引成約の申し出を受信すると、その申し出た顧客の信頼性を与信限度額に基づいて判断し、信頼性があるならば、その取引をサーバ管理者である銀行が仲介して行う。
【００４９】
　以上詳述した本実施形態によれば、以下の効果が得られる。
1)サーバ管理者である銀行が顧客の信用を保証する形で、顧客の希望取引をサーバ管理者の希望取引として自己の電子掲示板上に掲示するため、その希望取引に対して成約の申し出をしようとする顧客は安心して取引を履行できるという効果が得られる。
2)取引成約の申し出をする顧客の信頼性がある場合のみその取引を許可するため、トラブルの発生が抑えられる。
3)サーバ管理者である銀行が、希望取引を書き込んだ顧客及び取引成約を申し出た顧客のカウンターパーティ（仲介者）として取引を行うため、取引を希望する顧客は自分の取引相手方を常に銀行として確定でき、安心して取引をすることができる。
4)与信限度額に基づいて顧客の信頼性を判断しているが、与信限度額は、信用調査に基づいて定められているため、この与信限度額の範囲内であれば安心して取引できるという利点がある。
5)今回入力された希望取引とプレミアムのみが異なり他の条件が全て同じものが自己の電子掲示板に既に掲示されている場合には、取引相手にとって有利な方を優先して掲示するため、取引相手の利益が優先され、取引の活性化が図られる。このとき、既に書き込まれていた希望取引を削除する場合には、削除される顧客にその旨を知らせるため、顧客が困惑することがない。
【００５０】
　尚、本発明の実施の形態は、上記実施形態に何ら限定されるものではなく、本発明の技術的範囲に属する限り種々の形態を採り得ることはいうまでもない。
　例えば、上記実施形態において、サーバ１０は、サーバ管理者である銀行自らの希望取引を自己の電子掲示板に掲示可能としてもよい。この場合、電子掲示板に掲示される品揃えの拡充を図ることができる。
【００５１】
　また、上記実施形態ではクレジットデリバティブを取引する場合について説明したが、特にこれに限られず、通常取引の対象となり得る商品やサービスであれば本発明を適用することができる。
【００５２】
　更に、上記実施形態では銀行がサーバ管理者である場合について説明したが、特にこれに限られず、法人・個人を問わずに本発明を適用することができる。但し、取引を安心して履行することを考慮すれば、例えば上場企業などのように社会的信頼の高い会社等がサーバ管理者であることが好ましい。
【００５３】
　更にまた、図４の呈示ルーチンにおいて、Ｓ２２０のあとＳ２３０〜Ｓ２７０を省略して直ちにＳ２８０へ進むようにしてもよい。この場合、取引成約の申し出をしたい顧客は電話やファクシミリなどでその申し出を行い、そのような申し出があった場合には、サーバ管理者はＳ２３０〜Ｓ２７０を含むプログラムを実行するようにしてもよい。
【００５４】
　そして、図５の電子掲示板において、顧客が銘柄名をクリックするとその銘柄名の会社のホームページが開くようにしてもよい。この場合、その会社の詳しい情報が得られるため、取引成約を申し出るか否かの判断基準にすることができる。これに併せて、図８のフローチャートにおいて、各データベースを更新する際にその銘柄名の会社に自動的にリンクを張るようにしてもよい。
【図面の簡単な説明】
【００５５】
【図１】本実施形態の装置構成の概略説明図である。
【図２】取引制御プログラムのフローチャートである。
【図３】会員専用ホームページのトップページの画面を表す説明図である。
【図４】呈示ルーチンのフローチャートである。
【図５】「本日のプライスインディケーション」（電子掲示板）の表示画面を表す説明図である。
【図６】取引明細画面を表す説明図である。
【図７】クレジットデリバティブ（デフォルトスワップ）の説明図である。
【図８】確認ルーチンのフローチャートである。
【図９】「お客様による現在の掲載内容」の表示画面を表す説明図である。
【図１０】条件入力画面を表す説明図である。
【符号の説明】
【００５６】
１０・・・サーバ、
２０・・・顧客コンピュータ、
３０・・・インターネット、
３１・・・通信回線、
３２・・・ダイヤルアップ用通信回線
【図１】
2004005731.tif 000004
【図２】
2004005731.tif 000005
【図３】
2004005731.tif 000006
【図４】
2004005731.tif 000007
【図５】
2004005731.tif 000008
【図６】
2004005731.tif 000009
【図７】
2004005731.tif 000010
【図８】
2004005731.tif 000011
【図９】
2004005731.tif 000012
【図１０】
2004005731.tif 000013