(57)【特許請求の範囲】
【請求項１】
個人又は団体の支払能力に関する情報を記憶している信用機関装置、商品又はサービスの注文を行うための買い手装置、前記買い手装置から注文された商品又はサービスを提供するための売り手装置及び前記買い手装置と前記売り手装置間における取引を仲介するための情報処理を行う電子商取引装置とが互いに通信ネットワークを介して接続された電子信用システムを用いた電子信用サービス方法であって、
前記買い手装置が、前記通信ネットワークを介して前記信用機関装置に、当該買い手装置の利用者の支払能力を問い合わせる信用調査申請情報を送信し、前記通信ネットワークを介して前記電子商取引装置に、前記取引の注文を示す注文情報であって買い手IDと売り手IDと取引の対価を含む注文情報を送信し、
前記信用機関装置が、予め記憶された前記利用者の支払能力に関する情報及び前記信用調査申請情報に基づいて、前記利用者の支払能力を示す信用調査情報を算出し、算出された信用調査情報を記憶すると共に、前記通信ネットワークを介して前記買い手装置に、算出された信用調査情報を送信し、
前記電子商取引装置が、前記通信ネットワークを介して前記信用機関装置に、信用保証要求と前記注文情報に含まれる前記買い手IDと前記売り手IDと前記取引の対価とを送信し、
前記信用機関装置が、前記買い手IDに対応する信用調査情報を、記憶された前記信用調査情報から検索し、検索された信用調査情報と前記取引の対価との比較の結果を反映して信用保証IDと前記買い手IDと前記売り手IDと前記取引の対価とを含む信用保証結果を作成し、前記通信ネットワークを介して前記電子商取引装置に、前記信用保証結果を送信し、
前記電子商取引装置が、前記通信ネットワークを介して前記売り手装置に、前記注文情報に対応する情報に前記信用保証結果を付加して送信し、
前記電子商取引装置が、前記通信ネットワークを介して前記売り手装置から、前記注文情報に対応する情報に対する注文受付結果を受信し、前記通信ネットワークを介して前記買い手装置及び前記信用機関装置に、前記注文受付結果を送信し、
前記信用機関装置が、一定期間前記売り手装置からの代金保証要求がなかった場合、又は、前記注文受付結果として前記売り手装置からの注文拒絶を受信した場合に、記憶された前記信用調査情報を更新することを特徴とする電子信用サービス方法。
【請求項２】
個人又は団体の支払能力に関する情報を記憶している信用機関装置、商品又はサービスの注文を行うための買い手装置及び前記買い手装置から注文された商品又はサービスを提供するための売り手装置と通信ネットワークを介して接続され、前記買い手装置と前記売り手装置間における取引を仲介するための情報処理を行う電子商取引装置において、
前記通信ネットワークを介して前記買い手装置から、前記取引の注文を示す注文情報であって買い手IDと売り手IDと取引の対価を含む注文情報を受信する手段と、
前記通信ネットワークを介して前記信用機関装置に、信用保証要求と前記注文情報に含まれる前記買い手IDと前記売り手IDと前記取引の対価とを送信する手段と、
前記信用機関装置によって、予め記憶された前記利用者の支払能力に関する情報及び前記買い手装置から送信された信用調査申請情報に基づいて算出された信用調査情報であって前記買い手IDに対応する信用調査情報と前記取引の対価との比較の結果を反映して作成され信用保証IDと前記買い手IDと前記売り手IDと前記取引の対価とを含む信用保証結果を、前記通信ネットワークを介して前記信用機関装置から受信する手段と、
前記通信ネットワークを介して前記売り手装置に、前記注文情報に対応する情報に前記信用保証結果を付加して送信する手段と、
前記通信ネットワークを介して前記売り手装置から、前記注文情報に対応する情報に対する注文受付結果を受信し、前記通信ネットワークを介して前記買い手装置及び前記信用機関装置に、前記注文受付結果を送信する手段とを有し、
前記信用機関装置は、一定期間前記売り手装置からの代金保証要求がなかった場合、又は、前記注文受付結果として前記売り手装置からの注文拒絶を受信した場合に、記憶された前記信用調査情報を更新することを特徴とする電子商取引装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
インターネット等の通信ネットワークを利用した電子商取引において売り手の取引代金回収の保全を行う電子信用サービスに関する。
【０００２】
【従来の技術】
従来の電子商取引の決済手段としては、銀行振込、クレジットカード決済などあり、クレジットカード決済をインターネット上で実現する技術としては、「インターネットコマース新動向と技術」(共立出版株式会社)Ｐ５２〜Ｐ５７に記載のSET(Secure Electronic Transaction)がある。
【０００３】
SETを利用したクレジットカード決済では、電子店舗は、消費者から注文内容、カード番号、有効期限を含む情報を受け取り、受け取った情報を元に金融機関に対して信用照会を実施するという仕組みとなっていた。
【０００４】
また、従来の貿易金融EDIの信用保証手段としては、貿易金融EDI実施ガイドライン(電子商取引実証推進協議会(ECOM)、1999/3)Ｐ７４〜Ｐ８１に記載の信用状(L/C:Letter of Credit)取引がある。
【０００５】
信用状取引では、輸出入の売買契約成立後、買い手の取引銀行が買い手の依頼を受けて取引代金に相当する信用状発行保証金を買い手に預託させ、それを見返りにして銀行が取引代金の支払いを売り手に確約するという仕組みとなっていた。
【０００６】
【発明が解決しようとする課題】
従来の電子商取引におけるSETを利用したクレジットカード決済では、電子店舗は、消費者から注文内容、カード番号、有効期限を含む情報を受け取った後、受け取った情報を元に金融機関に対して信用照会を実施するため、信用照会で不可となる注文も一旦受け取り、注文を受け取るたびに信用照会の実施が必要となるため、売り手の作業負荷が大きくなるといった問題がある。
【０００７】
また、貿易金融EDIにおける信用状取引では、輸出入の売買契約成立後、信用状の開設を行うため、売り手は注文情報とは別に後から信用状を受け取ることになり、信用状を受け取るまで商品を送ることができないため、時間の無駄が発生し、注文情報と信用状の突き合わせが必要となるため、売り手の作業負荷が大きくなるとなるといった問題がある。
【０００８】
本発明は、通信ネットワークを利用した電子商取引において、事前に信用保証または信用保険の付加された注文情報を売り手に受け渡すことによって、売り手が買い手の信用を確認する作業を軽減し、売り手の取引代金回収の保全を行う電子信用サービスを実現することを目的とする。
【０００９】
【課題を解決するための手段】
本発明は、上記目的を達成するために、基本的には、信用審査結果を買い手毎に格納しておき、買い手からの注文情報を一旦受信し、事前に信用保証または信用保険の付加された注文情報を売り手に送信することにより、電子商取引における売り手の信用確認作業を軽減し、売り手の取引代金回収の保全を行うようにしたことを特徴とする。また、買い手の装置から仲介する装置または売り手の装置に、注文を示す情報と信用機関で審査された支払いに関する調査結果を示す情報を送信するものである。なお、調査結果は、何円まで支払い可能と、支払い可能金額を示してもよい。また、注文の量（金額、数量など）に応じて行ってもよい。注文に応じたとは、何円まで支払い可能ではなく、注文の金額を支払い可能か否かを提示するものである。
【００１０】
なお、本発明のより具体的な構成は以下の通りである。
１つの方法は、
信用機関サーバと電子商取引サーバと買い手クライアントと売り手クライアントと通信ネットワークとから成り、
買い手の信用を審査する信用審査および支払いを保証する信用保証を行い、
電子商取引における売り手の取引代金回収の保全を行う電子信用サービス方法であって、
信用機関サーバは、
買い手クライアントから信用審査申請情報を受信し、
受信した信用審査申請情報に基づき、買い手の信用を審査する信用審査処理を行い、
審査した信用審査結果を買い手クライアントに送信し、
電子商取引サーバは、
買い手クライアントから注文情報を受信し、
受信した注文情報の中の信用保証要否区分に基づき、信用保証の要否を判定し、
信用保証要否区分が信用保証必要の場合、
信用保証要求および注文情報を信用機関サーバに送信し、
信用機関サーバは、
電子商取引サーバから信用保証要求および注文情報を受信し、
受信した信用保証要求および注文情報に基づき、注文情報に対する信用保証処理を行い、
処理した信用保証結果を電子商取引サーバに送信し、
電子商取引サーバは、
信用機関サーバから信用保証結果を受信し、
信用保証結果付き注文情報を売り手クライアントに送信し、
売り手クライアントから注文受付結果を受信し、
受信した注文受付結果を信用機関サーバおよび買い手クライアントに送信し、
信用機関サーバは、
電子商取引サーバから注文受付結果を受信し、
電子商取引サーバは、
信用保証要否区分が信用保証不要の場合、
信用保証結果を信用保証未処理とした信用保証結果付き注文情報を売り手クライアントに送信し、
売り手クライアントから注文受付結果を受信し、
受信した注文受付結果を買い手クライアントに送信することを特徴とする。
【００１１】
もう１つの方法は、
信用機関サーバと電子商取引サーバと買い手クライアントと売り手クライアントと通信ネットワークとから成り、
買い手の信用を審査する信用審査および支払いを保証する信用保険を作成し、
電子商取引における売り手の取引代金回収の保全を行う電子信用サービス方法であって、
電子商取引サーバは、
買い手クライアントから注文情報を受信し、
予め売り手クライアントから登録されている信用保険要否条件に基づき、信用保険の要否を判定し、
信用保険が必要である場合、
信用保険作成要求および注文情報を信用機関サーバに送信し、
信用機関サーバは、
電子商取引サーバから信用保険作成要求および注文情報を受信し、
受信した信用保険作成要求および注文情報に基づき、注文情報に対する信用保険作成処理を行い、
作成した信用保険情報を電子商取引サーバに送信し、
電子商取引サーバは、
信用機関サーバから信用保険情報を受信し、
信用保険情報付き注文情報を売り手クライアントに送信し、
売り手クライアントから信用保険申込結果および注文受付結果を受信し、
受信した信用保険申込結果を信用機関サーバに送信し、
信用機関サーバは、
電子商取引サーバから信用保険申込結果を受信し、
電子商取引サーバは、
受信した注文受付結果を買い手クライアントに送信し、
信用保険が不要である場合、
信用保険情報を信用保険未作成とした信用保険情報付き注文情報を売り手クライアントに送信し、
売り手クライアントから注文受付結果を受信し、
受信した注文受付結果を買い手クライアントに送信することを特徴とする。
【００１２】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。
図１は、本発明の電子信用サービス方法のうち、信用保証により売り手の取引代金回収の保全を行う第１の実施の形態を示す全体処理フロー図である。
【００１３】
図２に示す電子信用サービスシステムのシステム構成図について説明する。
電子信用サービスシステムは、信用機関サーバ２１０と電子商取引サーバ２２０と買い手クライアント２３０と売り手クライアント２４０と、これらのサーバとクライアント間を接続する通信ネットワーク２５０とから構成されている。
【００１４】
信用機関サーバ２１０は、信用審査手段、信用保証手段、信用保険作成手段を持つ制御部２１１と信用審査申請情報、信用審査結果、信用保証結果、信用保険情報を記憶する記憶部２１２と通信部２１３とからなる計算機であり、電子商取引サーバ２２０は注文受付手段、信用保証要求手段、信用保険作成要求手段を持つ制御部２２１と注文情報、信用保証結果、信用保険情報を記憶する記憶部２２２と通信部２２３とからなる計算機であり、買い手クライアント２３０は、入力部２３１と表示部２３２と制御部２３３と記憶部２３４と通信部２３５とからなる計算機であり、売り手クライアント２４０は、入力部２４１と表示部２４２と制御部２４３と記憶部２４４と通信部２４５とからなる計算機である。
【００１５】
信用機関サーバ２１０および電子商取引サーバ２２０は、複数の買い手クライアント２３０と売り手クライアント２４０に対してサービスを提供するための処理能力を持った計算機と、多様なサービスとユーザに関する情報を格納するための大容量記憶装置を備えたものであることが望ましい。具体的には、大型計算機、高性能ワークステーションがよい。
【００１６】
また、買い手クライアント２３０および売り手クライアント２４０は、一般的に通信ネットワークに接続できる計算機システムと呼ばれるものであればよい。具体的には、パーソナルコンピュータや、テレビに双方向通信機能を備えた装置を付加したものであればよい。
【００１７】
通信ネットワーク２５０は、情報を他の情報処理装置に伝送する伝送媒体であればよい。
【００１８】
以下、図２を引用しながら、図１の全体処理フロー図および図３の詳細処理フロー図に従い、第１の実施の形態における処理動作を説明する。
まず最初に、信用審査申請処理を説明する。
【００１９】
＜ステップ１１１＞信用機関サーバ：信用審査申請情報の受信
信用機関サーバ２１０は、通信ネットワーク２５０を介して買い手クライアント２３０から信用審査申請情報４００を受信する。
【００２０】
あるいは、直接、通信ネットワーク２５０を介して買い手クライアント２３０から信用審査申請情報４００を受信するのではなく、他のシステムやファイルなどを介して間接的に、信用審査申請情報４００を受信してもよい。
【００２１】
図４に受信した信用審査申請情報４００の例を示す。信用審査申請情報４００は、買い手ＩＤ４０１、純資産４０２、使用総資本４０３、自己資本比率４０４、経常収支比率４０５とからなる。
【００２２】
＜ステップ１１２＞信用機関サーバ：信用審査処理
ステップ１１１で受信した信用審査申請情報４００に対して、信用機関サーバ２１０は、「信用格付とリスク管理」(銀行研修社、平成９年１１月４日)Ｐ５５〜Ｐ５９に記載の従来の財務数値や指標の分析を中心としたスコアリング・システムの方式などを用いて企業を評価し、保証限度額および保険料係数を決定する信用審査処理を行う。
【００２３】
スコアリング・システムとは、点数化による企業評価システムのことであり、対象企業の資産規模や利益規模などの絶対値や各種の財務比率などを点数化していくことにより、各項目毎の合計点で企業評価を行っていくというものである。
【００２４】
図５に信用審査結果５００の例を示す。信用審査結果５００は、買い手ＩＤ５０１、最大保証限度額５０２、現在保証限度額５０３、最小保険料係数５０４、現在保険料係数５０５とからなる。
【００２５】
ただし、第１の実施の形態では、最小保険料係数５０４、現在保険料係数５０５は使用しなくともよい。
【００２６】
＜ステップ１１３＞信用機関サーバ：信用審査結果を送信
ステップ１１２で審査した信用審査結果５００に対して、
信用機関サーバ２１０は、通信ネットワーク２５０を介して買い手クライアント２３０に信用審査結果５００を送信する。
【００２７】
あるいは、直接、通信ネットワーク２５０を介して買い手クライアント２３０に信用審査結果５００を送信するのではなく、他のシステムやファイルなどを介して間接的に、信用審査結果５００を送信してもよい。
【００２８】
次に、注文処理を説明する。
＜ステップ１２１＞電子商取引サーバ：注文情報の受信
電子商取引サーバ２２０は、通信ネットワーク２５０を介して買い手クライアント２３０から注文情報６００を受信する。
【００２９】
図６に受信した注文情報６００の例を示す。注文情報６００は、買い手ＩＤ６０１、売り手ＩＤ６０２、商品番号６０３、数量６０４、代金６０５、支払期日６０６、信用保証要否区分６０７とからなる。
【００３０】
＜ステップ１２２＞電子商取引サーバ：信用保証要否判定
ステップ１２１で受信した注文情報６００に対して、
電子商取引サーバ２２０は、注文情報６００中の信用保証要否区分６０７が「必要」か「不要」かを判定する。
【００３１】
＜ステップ１２３＞電子商取引サーバ：信用保証要求および注文情報の送信
ステップ１２２で判定した注文情報６００の信用保証要否区分６０７が「必要」であった場合、
電子商取引サーバ２２０は、通信ネットワーク２５０を介して信用機関サーバ２１０に信用保証要求および注文情報６００中の買い手ＩＤ６０１、売り手ＩＤ６０２、代金６０５、支払期日６０６を送信する。
【００３２】
＜ステップ１１４＞信用機関サーバ：信用保証要求および注文情報の受信
信用機関サーバ２１０は、通信ネットワーク２５０を介して電子商取引サーバ２２０から信用保証要求および注文情報６００を受信する。
【００３３】
＜ステップ１１５＞信用機関サーバ：信用保証処理
ここから、図３に示す詳細処理フロー図を用いて、信用保証処理１１５を詳しく説明する。
【００３４】
＜ステップ３０１＞信用機関サーバ：信用保証対象の注文をした買い手の信用審査結果の検索
ステップ１１４で受信した信用保証要求および注文情報６００に対して、信用機関サーバ２１０は、記憶部２１２から注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００を検索する。
【００３５】
＜ステップ３０２＞信用機関サーバ：該当する信用審査結果あり？
ステップ３０１で検索した結果に対して、信用機関サーバ２１０は、注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００が「あり」か「なし」かを判定する。
【００３６】
＜ステップ３０３＞信用機関サーバ：信用審査申請情報の取得
ステップ３０２で判定した検索結果が「なし」であった場合、信用機関サーバ２１０は、通信ネットワーク２５０を介して買い手クライアント２３０から信用審査申請情報４００を取得する。
【００３７】
あるいは、直接、通信ネットワーク２５０を介して買い手クライアント２３０から信用審査申請情報４００を取得するのではなく、他のシステムやファイルなどを介して間接的に、信用審査申請情報４００を取得してもよい。
【００３８】
＜ステップ３０４＞信用機関サーバ：信用審査処理
ステップ３０３で取得した信用審査申請情報４００に対して、信用機関サーバ２１０は、上述の信用審査処理を行う。
【００３９】
＜ステップ３０５＞注文情報の代金≦信用審査結果の現在保証限度額
ステップ３０２で判定した検索結果が「あり」であった場合、ステップ３０１で検索した注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００に対して、信用機関サーバ２１０は、注文情報６００中の代金６０５と注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００中の現在保証限度額を比較する。
【００４０】
ステップ３０２で判定した検索結果が「なし」であった場合、ステップ３０４で審査した注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００に対して、信用機関サーバ２１０は、注文情報６００中の代金６０５と注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００中の現在保証限度額を比較する。
【００４１】
＜ステップ３０６＞信用保証可否区分＝可能
ステップ３０５で比較した注文情報６００中の代金６０５が注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００中の現在保証限度額以下であった場合、信用機関サーバ２１０は、信用保証結果７００を作成し、信用保証可否区分７０６を「可能」とする。
【００４２】
図７に信用保証結果７００の例を示す。信用保証結果７００は、信用保証ＩＤ７０１、買い手ＩＤ７０２、売り手ＩＤ７０３、代金７０４、支払期日７０５、信用保証可否区分７０６とからなる。
【００４３】
＜ステップ３０７＞信用審査結果の更新
ステップ３０５で比較した注文情報６００中の代金６０５が注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００中の現在保証限度額以下であった場合、信用機関サーバ２１０は、信用審査結果を更新する。具体的には、注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００中の現在保証限度額５０３から注文情報６００中の代金６０５を差し引く。
【００４４】
＜ステップ３０８＞信用保証可否区分＝不可能
ステップ３０５で比較した注文情報６００中の代金６０５が注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００中の現在保証限度額より大きい場合、信用機関サーバ２１０は、信用保証結果７００を作成し、信用保証可否区分７０６を「不可能」とする。
【００４５】
ここから、図１に戻って、処理動作の続きを説明する。
＜ステップ１１６＞信用機関サーバ：信用保証結果の送信
信用機関サーバ２１０は、通信ネットワーク２５０を介して電子商取引サーバ２２０に信用保証結果７００を送信する。
【００４６】
＜ステップ１２４＞電子商取引サーバ：信用保証結果の受信
電子商取引サーバ２２０は、通信ネットワーク２５０を介して信用機関サーバ２１０から信用保証結果７００を受信する。
【００４７】
＜ステップ１２５＞電子商取引サーバ：信用保証結果付き注文情報の送信
ステップ１２４で信用保証結果を受信した後、または、ステップ１２２で判定した注文情報６００の信用保証要否区分６０７が「不要」であった場合、以下の処理を行う。電子商取引サーバ２２０は、通信ネットワーク２５０を介して売り手クライアント２４０に信用保証結果７００を付加した注文情報６００を送信する。
【００４８】
ただし、ステップ１２２で判定した注文情報６００の信用保証要否区分６０７が「不要」であった場合、信用保証可否区分７０６は「未処理」である。
【００４９】
＜ステップ１２６＞電子商取引サーバ：注文受付結果の受信
電子商取引サーバ２２０は、通信ネットワーク２５０を介して売り手クライアント２４０から注文受付結果を受信する。注文受付結果には、当該注文情報を受け付けるか拒絶するかの情報が含まれている。
【００５０】
＜ステップ１２７＞電子商取引サーバ：注文受付結果の送信
ステップ１２７で受信した注文受付結果に対して、電子商取引サーバ２２０は、通信ネットワーク２５０を介して信用機関サーバ２１０および買い手クライアント２３０に注文受付結果を送信する。
【００５１】
ただし、ステップ１２２で判定した注文情報６００の信用保証要否区分６０７が「不要」であった場合、信用機関サーバ２１０には注文受付結果を送信しない。
【００５２】
＜ステップ１１７＞信用機関サーバ：注文受付結果の受信
信用機関サーバ２１０は、通信ネットワーク２５０を介して電子商取引サーバ２２０から注文受付結果を受信する。
【００５３】
ただし、ステップ１２２で判定した注文情報６００の信用保証要否区分６０７が「不要」であった場合、本ステップはない。
【００５４】
信用機関サーバ２１０は、信用保証した注文情報に対して、取引代金の不払いが発生した場合、売り手クライアントから受け取った代金保証要求に対して、買い手クライアントに不払いか否かの問い合わせを行う。不払いであった場合、売り手に保証代金を支払うための情報処理を行う。
【００５５】
また、支払期日後、一定期間、代金保証要求がなかった場合、または、電子商取引サーバから信用保証した注文情報に対する注文受付結果として注文拒絶を受信した場合、信用審査結果５００中の現在保証限度額５０３を最大保証限度額５０２を限度として更新する。
【００５６】
以上のように本実施形態によれば、売り手は事前に信用保証の付加された注文を受け取ることになり、新規取引先の審査コスト、注文受付時の信用確認コストを軽減できる。また、取引代金回収の保全を行うことができる。
【００５７】
また、信用審査処理を行うタイミングは、(１)買い手クライアント２３０から電子商取引サーバ２２０への最初の注文情報送信以前に行う、(２)買い手クライアント２３０から電子商取引サーバ２２０への最初の注文情報送信時に行う、などの形態がある。
【００５８】
また、信用保証要否判定は、(１)買い手クライアント２３０から電子商取引サーバ２２０への注文情報６００中の信用保証要否区分６０７に基づき、判定する、(２)買い手クライアント２３０から電子商取引サーバ２２０へ事前に登録済みの信用保証要否条件に基づき、判定する、などの形態がある。
【００５９】
また、信用保証結果付き注文情報の送信は、(１)無条件に、売り手クライアント２４０に信用保証結果７００付き注文情報６００を送信する、(２) 売り手クライアント２４０から電子商取引サーバ２２０へ事前に登録済みの注文情報送信条件に基づき、売り手クライアント２４０に信用保証結果７００付き注文情報６００を送信する、などの形態がある。
【００６０】
次に、第２の実施の形態を説明する。
図９は、本発明の電子信用サービス方法のうち、信用保険により売り手の取引代金回収の保全を行う第２の実施の形態を示す全体処理フロー図である。
【００６１】
図２は、本実施形態を実現するための電子信用サービスシステムのシステム構成図であるが、第１の実施の形態と同じであるため、説明を省略する。
【００６２】
以下、図２を引用しながら、図９の全体処理フロー図および図１０の詳細処理フロー図に従い、第２の実施の形態における処理動作を説明する。
【００６３】
＜ステップ１２１＞電子商取引サーバ：注文情報の受信
電子商取引サーバ２２０は、通信ネットワーク２５０を介して買い手クライアント２３０から注文情報６００を受信する。
【００６４】
＜ステップ９２１＞電子商取引サーバ：信用保険要否判定
ステップ１２１で受信した注文情報６００に対して、
電子商取引サーバ２２０は、売り手クライアント２４０から事前に登録済みの信用保証要否条件に基づき、信用保険要否が「必要」か「不要」かを判定する。
【００６５】
信用保険要否条件には、信用保険を必要とする買い手、代金などの条件が含まれている。
【００６６】
＜ステップ９２２＞電子商取引サーバ：信用保険作成要求および注文情報の送信
ステップ９２１で判定した信用保険要否が「必要」であった場合、
電子商取引サーバ２２０は、通信ネットワーク２５０を介して信用機関サーバ２１０に信用保険作成要求および注文情報６００中の買い手ＩＤ６０１、売り手ＩＤ６０２、代金６０５、支払期日６０６を送信する。
【００６７】
＜ステップ９１１＞信用機関サーバ：信用保険作成要求および注文情報の受信
信用機関サーバ２１０は、通信ネットワーク２５０を介して電子商取引サーバ２２０から信用保険作成要求および注文情報６００を受信する。
【００６８】
＜ステップ９１２＞信用機関サーバ：信用保険作成処理
ここから、図１０に示す詳細処理フロー図を用いて、信用保険作成処理９１２を詳しく説明する。
【００６９】
＜ステップ１００１＞信用機関サーバ：信用保険対象の注文をした買い手の信用審査結果の検索
ステップ９１１で受信した信用保険作成要求および注文情報６００に対して、
信用機関サーバ２１０は、記憶部２１２から注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００を検索する。
【００７０】
＜ステップ３０２＞信用機関サーバ：該当する信用審査結果あり？
ステップ１００１で検索した結果に対して、
信用機関サーバ２１０は、注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００が「あり」か「なし」かを判定する。
【００７１】
＜ステップ３０３＞信用機関サーバ：信用審査申請情報の取得
ステップ３０２で判定した検索結果が「なし」であった場合、
信用機関サーバ２１０は、通信ネットワーク２５０を介して買い手クライアント２３０から信用審査申請情報４００を取得する。
【００７２】
あるいは、直接、通信ネットワーク２５０を介して買い手クライアント２３０から信用審査申請情報４００を取得するのではなく、他のシステムやファイルなどを介して間接的に、信用審査申請情報４００を取得してもよい。
【００７３】
＜ステップ３０４＞信用機関サーバ：信用審査処理
ステップ３０３で取得した信用審査申請情報４００に対して、
信用機関サーバ２１０は、上述の信用審査処理を行う。
【００７４】
図５に信用審査結果５００の例を示す。信用審査結果５００は、買い手ＩＤ５０１、最大保証限度額５０２、現在保証限度額５０３、最小保険料係数５０４、現在保険料係数５０５とからなる。
【００７５】
ただし、第２の実施の形態では、最大保証限度額５０２、現在保証限度額５０３は使用しない。
【００７６】
＜ステップ１００２＞信用保険料の算出
ステップ３０２で判定した検索結果が「あり」であった場合、ステップ１００１で検索した注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００に対して、
また、ステップ３０２で判定した検索結果が「なし」であった場合、ステップ３０４で審査した注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００に対して、
信用機関サーバ２１０は、信用保険情報８００を作成し、信用保証料８０６に値を設定する。信用保険料８０６は、例えば、注文情報６００中の代金６０５に注文情報６００中の買い手ＩＤ６０１に該当する信用審査結果５００中の現在保険料係数５０５を掛けることにより算出する。
【００７７】
図８に信用保証結果８００の例を示す。信用保険情報８００は、信用保険ＩＤ８０１、買い手ＩＤ８０２、売り手ＩＤ８０３、代金８０４、支払期日８０５、信用保険料８０６とからなる。
【００７８】
＜ステップ１００３＞信用審査結果の更新
ステップ１００２で算出した信用保険料８０６に基づき、
信用機関サーバ２１０は、信用審査結果５００を更新する。具体的には、現在保険料係数５０５を高くする。
【００７９】
ここから、図９に戻って、処理動作の続きを説明する。
【００８０】
＜ステップ９１３＞信用機関サーバ：信用保険情報の送信
信用機関サーバ２１０は、通信ネットワーク２５０を介して電子商取引サーバ２２０に信用保険情報８００を送信する。
【００８１】
＜ステップ９２３＞電子商取引サーバ：信用保険情報の受信
電子商取引サーバ２２０は、通信ネットワーク２５０を介して信用機関サーバ２１０から信用保険情報８００を受信する。
【００８２】
＜ステップ９２４＞電子商取引サーバ：信用保険情報付き注文情報の送信
ステップ９２３で信用保険情報を受信した後、
または、ステップ９２１で判定した信用保険要否が「不要」であった場合、
電子商取引サーバ２２０は、通信ネットワーク２５０を介して売り手クライアント２４０に信用保険情報８００を付加した注文情報６００を送信する。
【００８３】
ただし、ステップ９２１で判定した信用保険要否が「不要」であった場合、信用保険情報８００の信用保険料８０６は「空（未作成）」である。
【００８４】
＜ステップ９２５＞電子商取引サーバ：注文受付結果および信用保険申込結果の受信
電子商取引サーバ２２０は、通信ネットワーク２５０を介して売り手クライアント２４０から注文受付結果および信用保険申込結果を受信する。注文受付結果には、当該注文情報を受け付けるか拒絶するかの情報が含まれている。また、信用保険申込結果には、当該信用保険を申し込むか否かの情報が含まれている。
【００８５】
＜ステップ９２６＞電子商取引サーバ：信用保険申込結果の送信
ステップ９２５で受信した信用保険申込結果に対して、
電子商取引サーバ２２０は、通信ネットワーク２５０を介して信用機関サーバ２１０に信用保険申込結果を送信する。
【００８６】
ただし、ステップ９２１で判定した信用保険要否が「不要」であった場合、本ステップはない。
【００８７】
＜ステップ９１４＞信用機関サーバ：信用保険申込結果の受信
信用機関サーバ２１０は、通信ネットワーク２５０を介して電子商取引サーバ２２０から信用保険申込結果を受信する。
【００８８】
ただし、ステップ９２１で判定した信用保険要否が「不要」であった場合、本ステップはない。
【００８９】
＜ステップ１２７＞電子商取引サーバ：注文受付結果の送信
ステップ９２５で受信した注文受付結果に対して、
電子商取引サーバ２２０は、通信ネットワーク２５０を介して買い手クライアント２３０に注文受付結果を送信する。
【００９０】
信用機関サーバ２１０は、
信用保険を申し込んだ注文情報に対して、取引代金の不払いが発生した場合、売り手クライアントから受け取った代金保証要求に対して、買い手クライアントに不払いか否かの問い合わせを行う。不払いであった場合、売り手に保証代金を支払うための情報処理を行う。
【００９１】
また、支払期日後、一定期間、代金保証要求がなかった場合、または、電子商取引サーバから信用保険申込結果として「申込まず」を受信した場合、信用審査結果５００中の現在保険料係数５０５の限度を最小保険料係数５０４として更新する。
【００９２】
以上のように本実施形態によれば、売り手は事前に信用保険の付加された注文を受け取ることになり、新規取引先の審査コスト、注文受付時の信用確認コストを軽減できる。また、取引代金回収の保全を行うことができる。
【００９３】
また、信用審査処理を行うタイミングは、(１)買い手クライアント２３０から電子商取引サーバ２２０への最初の注文情報送信時に行う、(２)買い手クライアント２３０から電子商取引サーバ２２０への最初の注文情報送信以前に行う、などの形態がある。
【００９４】
また、信用保険要否判定は、(１) 売り手クライアント２４０から電子商取引サーバ２２０へ事前に登録済みの信用保険要否条件に基づき、判定する、(２)電子商取引サーバ２２０から売り手クライアント２４０へ注文情報６００を一旦送信し、注文毎に売り手クライアント２４０が信用保険の要否を判断する、などの形態がある。
【００９５】
以上、本発明における２つの実施の形態を説明したが、図２において、信用機関サーバと電子商取引サーバを分けているが、この２つを同一サーバ上に構築し、信用機関・電子商取引サーバ、買い手クライアント、売り手クライアント３者のシステム構成としてもよい。
【００９６】
また、図２において、信用機関サーバ、電子商取引サーバ、買い手クライアント、売り手クライアントはそれぞれ１台づつとなっているが、買い手クライアント、売り手クライアントが複数台存在することは言うまでもなく、信用機関サーバ、電子商取引サーバも複数台存在し、お互いに連携し、サービスを提供する構成もあり得る。
【図面の簡単な説明】
【図１】発明の第１の実施の形態を示す全体処理フロー図である。
【図２】本発明の第１、２の実施の形態を実現するためのシステム構成図である。
【図３】第１の実施形態における信用保証処理の詳細処理フロー図である。
【図４】信用審査申請情報の一例である。
【図５】信用審査結果の一例である。
【図６】注文情報の一例である。
【図７】信用保証結果の一例である。
【図８】信用保険情報の一例である。
【図９】本発明の第２の実施の形態を示す全体処理フロー図である。
【図１０】第２の実施形態における信用保険作成処理の詳細処理フロー図である。
【符号の説明】
信用機関サーバ…２１０、電子商取引サーバ…２２０、買い手クライアント…２３０、売り手クライアント…２４０、通信ネットワーク…２５０
【図１】
0003823009.tif 000002
【図２】
0003823009.tif 000003
【図３】
0003823009.tif 000004
【図４】
0003823009.tif 000005
【図５】
0003823009.tif 000006
【図６】
0003823009.tif 000007
【図７】
0003823009.tif 000008
【図８】
0003823009.tif 000009
【図９】
0003823009.tif 000010
【図１０】
0003823009.tif 000011