(57)【要約】【課題】コンピュータネットワークを利用して企業間の取引振りの情報を共有管理し、サービス利用者に対して公正に提供する。【解決手段】利用者端末から提供されるあらかじめ定められた項目を有する情報をネットワークを介して受信する。利用者が情報提供に係る量的な制約条件を満たしているか否かを受信情報に基づいて判定するとともに、この受信情報を含むこれまでの累積受信情報が利用者端末側からの情報提供に係る質的な制約条件を満たしているか否かを判定する。また、該受信情報および他の利用者端末から受信した情報を同一の項目内容毎に集計して集計情報を作成する。情報提供に係る量的な制約条件および情報提供に係る質的な制約条件を共に満足する場合に、情報提供をなした利用者端末に対し、作成された集計情報を送信、提供する。【選択図】　　図１
2004094346.tif 000002
【特許請求の範囲】
【請求項１】
利用者端末から提供されるあらかじめ定められた項目を有する情報をネットワークを介して受信するステップと、
前記利用者端末の利用者が情報提供に係る量的な制約条件を満たしているか否かを受信した前記情報に基づいて判定するステップと、
前記利用者端末の利用者が情報提供に係る質的な制約条件を満たしているか否かを受信した前記情報に基づいて判定するステップと、
受信した前記情報および他の利用者端末から受信した情報を前記項目について同一の項目内容毎に集計して集計情報を作成するステップと、
前記情報提供に係る量的な制約条件および前記情報提供に係る質的な制約条件を共に満足する場合に、情報提供をなした前記利用者端末に対し要求に応じて前記集計情報を送信するステップと、
を具備することを特徴とする情報提供方法。
【請求項２】
前記情報は前記利用者端末の利用者及び前記他の利用者端末の利用者とは異なる第三者の評価情報を含み、
前記第三者の利用者端末による前記評価情報への閲覧を許可するステップを具備することを特徴とする請求項１に記載の情報提供方法。
【請求項３】
前記利用者端末の利用者について各々の評価点を採点するステップと、
採点された前記評価点が所定の基準を下回る場合に、該当する利用者端末を排除するステップと、
をさらに具備することを特徴とする請求項１または２記載の情報提供方法。
【請求項４】
企業端末から提供される該企業の取引先についての取引情報をネットワークを介して受信するステップと、
前記企業が情報提供に係る量的な制約条件を満たしているか否かを受信した前記取引情報に基づいて判定するステップと、
前記企業が情報提供に係る質的な制約条件を満たしているか否かを受信した前記取引情報の累積蓄積情報に基づいて判定するステップと、
受信した前記取引情報および他の企業端末から受信した取引情報を同一の取引先について集計して該取引先の支払い振り情報を作成するステップと、
前記情報提供に係る量的な制約条件および前記情報提供に係る質的な制約条件を共に満足する場合に、情報提供をなした前記企業端末に対し要求に応じて前記支払い振り情報を送信するステップと、
を具備することを特徴とする取引情報管理方法。
【請求項５】
前記取引先の端末からの前記支払い振り情報への閲覧を許可するステップを具備することを特徴とする請求項５に記載の取引情報管理方法。
【請求項６】
前記企業端末について各々の評価点を採点するステップと、採点された前記評価点が所定の基準を下回る場合に、該当する企業端末を排除するステップと、
をさらに具備することを特徴とする請求項４または５記載の取引情報管理方法。
【請求項７】
利用者端末から提供されるあらかじめ定められた項目を有する情報をネットワークを介して受信するステップと、
前記利用者端末の利用者が情報提供に係る量的な制約条件を満たしているか否かを受信した前記情報に基づいて判定するステップと、
前記利用者端末の利用者が情報提供に係る質的な制約条件を満たしているか否かを受信した前記情報に基づいて判定するステップと、
受信した前記情報および他の利用者端末から受信した情報を前記項目について同一の項目内容毎に集計して集計情報を作成するステップと、
前記情報提供に係る量的な制約条件および前記情報提供に係る質的な制約条件を共に満足する場合に、情報提供をなした前記利用者端末に対し要求に応じて前記集計情報を送信するステップと、
をコンピュータに実行させるための情報提供処理プログラム。
【請求項８】
企業端末から提供される該企業の取引先についての取引情報をネットワークを介して受信するステップと、
前記企業が情報提供に係る量的な制約条件を満たしているか否かを受信した前記取引情報に基づいて判定するステップと、
前記企業が情報提供に係る質的な制約条件を満たしているか否かを受信した前記取引情報の累積蓄積情報に基づいて判定するステップと、
受信した前記取引情報および他の企業端末から受信した取引情報を同一の取引先について集計して該取引先の支払い振り情報を作成するステップと、
前記情報提供に係る量的な制約条件および前記情報提供に係る質的な制約条件を共に満足する場合に、情報提供をなした前記企業端末に対し要求に応じて前記支払い振り情報を送信するステップと、
をコンピュータに実行させるための取引情報管理プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はコンピュータネットワークを利用して企業間の取引情報を共同管理する方法及びプログラムに関する。
【０００２】
【従来の技術】
企業間の取引では掛売りが一般的であり、売り手側企業は商品を販売してからその代金を回収するまでの間、売掛債権を所持する。売掛債権は企業の資産の中で最大規模のものであることから、商品販売においては取引先の信用リスクを考慮することが重要である。また、売掛債権の管理等においても取引相手先の信用リスクの評価は重要であるが、従来、各企業は独自にこれを行っていた。例えば、営業部員が外部で聞きつけた「噂」は、新規取引先や既存の取引先の信用リスクを評価するために極めて重要な情報源である。また、最近ではいわゆるデータウェアハウスが提供する財務情報や企業評価情報をオンライン又はオフラインで入手し、これをもとに取引先企業の健全さを判断することも可能になってきた。
【０００３】
しかしながら、売掛金管理といった具体的な業務に関係する、最も重要な情報の一つである支払振りについては、依然として情報入手が困難とされている。
【０００４】
【発明が解決しようとする課題】
現状では、取引先が企業経営に行き詰まって他社への支払の滞納をはじめたとしても、実際に自社の取引についての滞納が発生するまでそのような支払振りを検知できない。リスク管理の観点では、取引先が滞納をはじめてからでは回収のために講じる手段が限られてくるため問題となる。そこで、自社との取引の滞納が発生する十分前の時点において相手先企業の支払振りの情報を入手することが望まれる。このような情報を事前に入手できれば、リスク管理をタイムリーに行えるようになる。
【０００５】
本発明はかかる事情を考慮してなされたものであり、その目的は、コンピュータネットワークを利用して企業間の取引振りの情報を共有管理し、これを公正に提供することのできる取引情報管理方法およびプログラムを提供することにある。
【０００６】
【課題を解決するための手段】
上記課題を解決し目的を達成するために本発明は次のように構成されている。
【０００７】
本発明に係る情報提供方法は、利用者端末から提供されるあらかじめ定められた項目を有する情報をネットワークを介して受信するステップと、前記利用者端末の利用者が情報提供に係る量的な制約条件を満たしているか否かを受信した前記情報に基づいて判定するステップと、前記利用者端末の利用者が情報提供に係る質的な制約条件を満たしているか否かを受信した前記情報に基づいて判定するステップと、受信した前記情報および他の利用者端末から受信した情報を前記項目について同一の項目内容毎に集計して集計情報を作成するステップと、前記情報提供に係る量的な制約条件および前記情報提供に係る質的な制約条件を共に満足する場合に、情報提供をなした前記利用者端末に対し要求に応じて前記集計情報を送信するステップと、を具備することを特徴とする。
【０００８】
また、本発明に係る取引情報管理方法は、企業端末から提供される該企業の取引先についての取引情報をネットワークを介して受信するステップと、前記企業が情報提供に係る量的な制約条件を満たしているか否かを受信した前記取引情報に基づいて判定するステップと、前記企業が情報提供に係る質的な制約条件を満たしているか否かを受信した前記取引情報の累積蓄積情報に基づいて判定するステップと、受信した前記取引情報および他の企業端末から受信した取引情報を同一の取引先について集計して該取引先の支払い振り情報を作成するステップと、前記情報提供に係る量的な制約条件および前記情報提供に係る質的な制約条件を共に満足する場合に、情報提供をなした前記企業端末に対し要求に応じて前記支払い振り情報を送信するステップと、を具備することを特徴とする。
【０００９】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施形態を説明する。
【００１０】
図１は本発明の一実施形態に係る取引情報共同管理システムの概略構成を示す図である。同図に示すように本システムは、複数の参加企業のそれぞれに設置された情報通信端末（以下、企業端末）１Ａ、１Ｂを有する。また、これら参加企業と関係している複数の取引先企業についての取引情報をネットワーク４を介した企業端末１Ａ、１Ｂからの情報提供により共同管理する一方、これら企業端末１Ａ、１Ｂからのアクセスに応じて、要求された特定の取引先企業についての支払い振り情報を提供する取引情報共同管理サーバ２を有する。
【００１１】
企業端末１Ａ、１Ｂは一般的なコンピュータを用いて構成することができ、その基本的なハードウェア構成として、図示しないが中央演算ユニット（ＣＰＵ）、メモリ、外部記録装置、通信インターフェース（Ｉ／Ｆ）、および表示装置やキーボード、マウス等の入力装置を備える。また、これらのハードウェアを制御するためのオペレーティングシステム（ＯＳ）を備える。また、このようなオペレーティングシステム上で動作するアプリケーションソフトウェアとして、企業端末１Ａ、１Ｂはそれぞれ販売管理ツール３Ａ、３Ｂを備えている。企業端末１Ａ、１Ｂの両者は構成が同一のものとすることができる。
【００１２】
取引情報共同管理サーバ２についても、企業端末１Ａ、１Ｂと同様に一般的なコンピュータを用いて構成することができるが、比較的性能が高いサーバ用途のコンピュータを用いることが好ましい。
【００１３】
図２は、本実施形態に係る情報提供サービスを実現するための、企業端末１Ａ、１Ｂおよび取引情報共同管理サーバ２の各々の機能構成を示すブロック図である。これらは、上述のオペレーティングシステム上で動作するプログラムとして実現することができる。同図に示すように、企業端末１Ａ、１Ｂは入力・表示機能部１０、データ送受信部１２、および取引情報格納部１４を備えている。これら機能部は上述の販売管理ツール３と連携しており、同販売管理ツール３Ａ、３Ｂが保有、管理している取引情報を参照可能である。なお、販売管理ツール３Ａ、３Ｂは、それぞれの企業（自社）が保有する取引情報を簡便に準備するためのものであり、必須の構成要素ではない。例えば自社の取引情報を入力・表示機能部１０を通じてユーザが直接、入力してもよい。
【００１４】
取引情報は、自社との取引相手先である企業を識別する取引先企業コード、取引金額（売掛金額）、支払い期限、延滞情報等を含み、取引の具体内容およびその状況を表す情報である。このような取引情報は取引情報格納部１４に格納されており、情報提供を目的として、後述する処理手順に従いデータ送受信部１２からネットワーク４を介し取引情報共同管理サーバ２宛てに送信される。
【００１５】
取引情報共同管理サーバ２は、データ送受信部２０、データ登録状況管理部２２、支払い振り情報集計部２４、採点部２６、管理情報記録部２８、支払い振り情報記録部３０、および評価点記録部３２を備える。
【００１６】
かかる構成において、取引情報共同管理サーバ２は、企業端末１Ａ、１Ｂから提供された取引情報を管理情報記録部２８に保持し、該取引情報内に示される取引相手先企業毎にその支払い振りの情報を作成し、支払い振り情報記録部３０に格納する。支払い振り情報は、企業端末１Ａ、１Ｂから提供された取引情報から、取引相手先企業毎に、売掛金額やその支払いの延滞の事実等を示す情報を集計することで作成される。
【００１７】
例えば、ある参加企業（例えば企業端末１Ａに対応）がＡ社を相手先として取引をしており、このＡ社との取引ではＡ社から該参加企業への支払いに延滞がなく、つまり支払い振りが良好であったとする。ここで、同じくＡ社を相手先として他の参加企業（例えば企業端末１Ｂに対応）が取引をしていたところ、この参加企業に対してＡ社が支払いを延滞したとする。この場合、該他の参加企業は企業端末１Ｂから取引情報共同管理サーバ２に対し、かかる延滞情報を含んだ取引情報を提供することになる。この延滞情報を含んだＡ社についての取引情報は、支払い振り情報集計部２４により抽出され、上述の企業端末１Ａからの提供情報とともに集計される。このような集計情報を支払い振り情報として、取引情報共同管理サーバ２は企業端末１を通じ該参加企業に送信する（サーバ側からの情報提供）。これにより企業端末１の参加企業は、自社との取引については支払い振りが良好であるにもかかわらず、Ａ社は支払い振りが良好ではないことを、早期に知ることができる。
【００１８】
また本実施形態に係る取引情報共同管理システムは、このような取引情報提供が公正に行われるように、参加企業に対して幾つかの制約を課す。
【００１９】
情報提供が公正なシステムと言う観点からは、次の２点が重要であると考えられる。すなわち、
（１）情報のやり取りに不公平がないこと。これを意図して、取引情報共同管理システムは、当該サービスへの参加企業の全てに対し、各々の企業端末側からの情報提供に係る量的な制約条件を課す。具体的には、取引情報共同管理サーバ２から支払い振り情報を受信し、これに基づく情報提供を受けた場合は、しかる後に、自社側からも必ず取引情報の提供を行うこと（例えば自社の取引相手先についての滞納の有無等の情報提供）を制約条件とする。
【００２０】
本実施形態では、企業端末１Ａ、１Ｂの販売管理システム３Ａ、３Ｂあるいは入力・表示機能部１０等を通じて入力された、支払い振りを含む取引情報が企業端末１Ａ、１Ｂから取引情報共同管理サーバ２に対して自動的に送信される。取引情報共同管理サーバ２側では、企業端末１Ａ、１Ｂから提供されたそのような情報の量（件数等）をそれぞれ把握しており、所定の基準を満たす量の情報提供がなされたことが確認された時点で、その企業端末１Ａ、１Ｂに対する取引情報共同管理サーバ２からの情報提供を許可する。
【００２１】
より具体的には、取引情報共同管理サーバ２の管理情報記録部２８は、企業端末１Ａ、１Ｂから取引の発生時にそれぞれ提供された取引情報のうち、取引の基本情報例えば取引ＩＤ、取引先企業コード（ＩＤ）、および当該取引の支払い期限からなるデータを企業端末ごと、および取引ごとに保存、管理している。このような取引の基本情報に基づいて、参加企業が適切に情報を提供しているか否かを判定する。つまり、取引の基本情報は、その参加企業自身が情報提供者と成り得ること、およびその参加企業は情報提供の対象となる情報を保有している可能性があることを示す。
【００２２】
なお、支払いが完了した時点や、債権放棄が決定された時点でこの情報は取引情報共同管理サーバ２から消去される。それまでは、当該参加企業は情報提供の義務を負う。また、後述するが、事前に参加企業側からの情報提供を行わなくても、取引情報共同管理サーバ２から特定企業についての支払い振り情報の提供を受けることが可能である。これは、該特定企業との取引がなく、新規に取引を開始しようとする場合への対応である。但し、その回数は制限される。
【００２３】
（２）情報の品質が保たれること。これについても情報提供が公正に行われるために重要である。具体的には、
（２−１）被評価対象の企業が自ら情報の正当性を確認できること
（２−２）精度の低い情報を提供する参加企業を排除すること
である。
これを意図して、取引情報共同管理システムは、本実施形態の情報提供サービスへの参加企業の全てに対し、各々の企業端末側からの情報提供に係る質的な制約条件を課す。上記（２−１）の観点では、例えばＸ社が被評価対象の企業であったとする。このＸ社に対しては、Ｘ社から相手先（すなわち当該サービスへの参加企業）への支払い振り情報を、Ｘ社自らが閲覧することを許可し、閲覧された該支払い振り情報についてのＸ社からのクレームを受け付ける。
【００２４】
上記（２−２）の観点では、参加企業各社について、各々が支払い振り情報を提供した時期又は該提供した支払い振り情報の内容をもとに、該参加企業各社それぞれの評価点を算出する。算出された評価点が所定の閾値よりも低い企業、つまり精度の低い不適切な情報を提供する企業は、参加企業から除外する。
【００２５】
そして、以上のような情報提供に係る量的な制約条件および情報提供に係る質的な制約条件を共に満足する場合に限り、本実施形態の取引情報共同管理システムは、情報提供をなした企業端末に対し、要求に応じて支払い振り情報を送信するように構成されている。
【００２６】
以下、図３乃至図６を参照して企業端末１Ａ、１Ｂ及び取引情報共同管理サーバ２の処理手順を説明する。図３及び図４は企業端末１Ａ、１Ｂの処理手順を示すフローチャート、図５及び図６は取引情報共同管理サーバ２の処理手順を示すフローチャートである。
【００２７】
まず企業端末１Ａ、１Ｂの処理手順を説明する。企業端末１Ａ、１Ｂにおいては、新規な取引が発生したとき、入力・表示機能部１０を通じてこの取引に関する情報を入力し、取引情報格納部１４にあらかじめ格納しておく。かかる取引情報の一例を次の表１に示す。
【００２８】
【表１】
2004094346.tif 000003
【００２９】
このように、取引情報は、取引先企業コード、取引コード、売掛金額、支払い期限、支払い日（回収日）、延長回数、延滞（延長）可否フラグ、および回収断念フラグといった項目を有する。
【００３０】
図３のステップＳ１に示すように、企業端末１Ａ、１Ｂは、参照企業が取引情報共同管理サーバ２に登録済みであるか否かを判定する。企業端末１Ａ、１Ｂが参照企業と全く取引が無い場合、上記表１の情報は空である。このとき、企業端末１Ａ、１Ｂは予め定められた参照可能件数の範囲内で取引情報共同管理サーバ２において支払い振り情報を参照し、閲覧できる（ステップＳ２）。なお、この参照可能件数は、参照を行う毎に減じられていく。参照可能件数がゼロになったとき、企業端末１Ａ、１Ｂ自らが取引情報を提供しない限り、もはや参照はできなくなる。
【００３１】
次に、企業端末１Ａ、１Ｂが現在、いずれかの相手先企業と取引を持っている場合、その支払いが発生したか否かを判定する（ステップＳ３）。支払いが有った場合、その時点でその取引についての売掛金の支払い日すなわち売掛債権の回収日をセットする（ステップＳ４）。
【００３２】
支払いが未だなされておらず、しかも支払い期限を超過したとき、つまり支払い期限の延長が発生したとき（ステップＳ５）は、ステップＳ４において廷長回数を１づつ増加させる（初期値はゼロとする）。また、延長後の回収期限をセットする（ステップＳ７）。なお、グループ企業内取引の場合など、支払いが遅れても構わない取引については、あらかじめ延滞可能フラグをセットしておく。
【００３３】
支払い期限の延長後も支払いがなされず、回収を断念した取引（ステップＳ８）には、回収断念フラグをセットする（ステップＳ９）。回収断念フラグがセットされた時点をデフォルト時点、すなわち債務不履行が確定した時点として記録する（ステップＳ１０）。
【００３４】
図４に示すように、各取引の支払い期限日が到来した時点（ステップＳ１１において、支払いがなされている場合は上述のステップＳ４において支払い日がセットされている。また、支払い期限日が到来しても支払いがなされておらず、期限の延長（または回収断念）を行った場合は、その旨が取引情報として登録がなされている。ここで、企業端末１Ａ、１Ｂが、取引情報共同管理サーバ２に対し支払い振り情報の参照をすでに行っている場合は、上述の参加企業側の制約条件の下、企業端末側からの情報提供を行う必要があるので、更新された取引情報を取引情報共同管理サーバ２に送信する（ステップＳ１３）。
【００３５】
次に、取引情報共同管理サーバ２側の処理手順を説明する。
【００３６】
企業端末１Ａ、１Ｂが当該取引情報共同管理サーバ２に接続し、更新された回収日、あるいは新規に設定された取引に関する上述の取引情報をデータ送受信部１２が送信すると（ステップＳ１３）、取引情報共同管理サーバ２のデータ送受信部２０がこれを受信する。ここで、図５のステップＳ２０に示すように情報提供受信有りと判断してステップＳ２１に移行する。情報提供の受信が無いとき、取引情報共同管理サーバ２は図６のステップＳ２６以降の処理、つまり情報提供要求に係る処理を行う。受信された取引情報はデータ登録状況管理部２２に送られる。データ登録状況管理部２２はこの受信情報に対して、以下のチェックを行う（ステップＳ２１）。
【００３７】
（１）過去に登録された、未回収の取引が削除されていないか？
（２）取引の金額が変更されていないか？
（３）延長回数が増加していないのに支払期限が変更されていないか？
これらのチェックは企業端末１Ａ、１Ｂからの不正に情報を取得する行為を排除する目的で行われる。次のステップＳ２２においてチェック結果の判定を行う。ここで、チェックに合格しない場合、採点部２６はステップＳ２３において情報提供元の参加企業の評価点を減点して評価点記録部３２に記録するとともに、該企業の端末にエラーメッセージを送信してステップＳ２０に戻る。一方、チェックに合格した場合、データ登録状況管理部２２は受信した提供情報、すなわち取引情報を管理情報記録部２８に記録、蓄積する（ステップＳ２４）。
【００３８】
なお、データ登録状況管理部２２は、最終フラグ更新日、取引期限、および現時点の日付を利用して、データ入力すべきタイミングを例えば次のように知ることが出きる。
【００３９】
（ア）（現時点の日付）−（取引期限）がゼロ以下のとき、フラグは、回収期限以前、回収済み、回収断念のいずれかである。これ以外ならエラーである。
【００４０】
（イ）（現時点の日付）−（取引期限）が１以上３０以下のとき、フラグは回収済み、回収断念、延滞１日以上３０日以内のいずれかである。これ以外ならエラーである。
【００４１】
（ウ）（現時点の日付）−（取引期限）が３１以上６０以下のとき、フラグは回収済み、回収断念、延滞３１日以上６０日以内のいずれかである。これ以外ならエラーである。
【００４２】
（エ）（現時点の日付）−（取引期限）が６１以上９０以下のとき、フラグは回収済み、回収断念、延滞６１日以上９０日以内のいずれかである。これ以外ならエラーである。
【００４３】
（オ）（現時点の日付）−（取引期限）が９１以上のとき、フラグは回収済み、回収断念、延滞９１日以上のいずれである。これ以外ならエラーである。
【００４４】
上記エラーの場合、企業端末１Ａ、１Ｂは「保留」を選択することができ、本システムでは一定数まで保留を認めることとする。一定数とは例えば全売上債権の５％などにする。
【００４５】
次に、取引情報の新たな記録、蓄積がステップＳ２４において行われた場合、支払い振り情報集計部２４は、この新たな取引情報が反映された支払い振り情報の作成を開始する。すなわち、この新たな取引情報から取引先企業ごとに情報を抽出して支払い振り情報記録部３０に記録するとともに、取引先企業ごと、および取引ごとに集計を行う。
【００４６】
例えば上述の表１に示した取引情報に加え、これとは別の情報提供元から次の表２に示す別の取引情報が受信されていると仮定する。
【００４７】
【表２】
2004094346.tif 000004
【００４８】
ここで支払い振り情報集計部２４は、上述の表１の取引情報と、この表２の取引情報とを集計し、例えば次の表３に示すような支払い振り情報を作成する（ステップＳ２５）。
【００４９】
【表３】
2004094346.tif 000005
【００５０】
なお、表３に記載のものは、取引先Ａ社についての支払い振り情報である。この表３のように全ての提供元からの取引情報からの情報が加算され、「支払い期限前」、「延滞１日から３０日以前（延滞日数１）」、「延滞３１日以上６０日以内（延滞日数２）」、「延滞６１日以上９０日以内（延滞日数３）」、「延滞９１日以上（延滞日数４）」、および「デフォルト」についての各金額の合計値が示されている。
【００５１】
なお、金額合計は、現時点における情報の集計結果でも良いし、過去一年以内ののべ金額としても良い。
【００５２】
延滞情報あるいはデフォルト情報が増加した場合は、被評価企業と連絡をとり、内容の確認を行うことが好ましい。また、必要であれば、延滞情報およびデフォルト情報を提供した企業にも確認をとってから情報の確定を行うことが好ましい。このとき、情報提供が誤りであることが判明した場合、採点部２６は情報提供元企業の評価点を減点し、評価点記録部３２に記録する。評価点の採点方法としては、例えば、返済情報およびデフォルト情報の提供回数に対する情報の誤り回数の割合（百分率）を計算することとする。また、返済情報およびデフォルト情報の提供回数をもとに情報ポイントを算出する。さらに、情報ポイントに基づいて参照可能件数の修正を行う。
【００５３】
図６のステップＳ２６において、企業端末１Ａ、１Ｂから情報提供の要求がなされた場合、まず企業端末１Ａ、１Ｂが現在、取引を持っているか否かを判定する（ステップＳ２７）。取引を持っていない場合、上述したようにこれら企業端末からは予め定められた参照可能件数の範囲内でのみ支払い振り情報を参照し、閲覧できる（ステップＳ２８）。また、この参照可能件数は、参照を行う毎に減じられていく。参照可能件数がゼロになったとき、企業端末１Ａ、１Ｂ自らが取引情報を提供しない限り、もはや参照はできなくなる。参照可能件数は、上述の情報ポイントをもとに算出される。
【００５４】
次に、採点部２６は情報提供の要求をなした企業端末１Ａ、１Ｂの評価点が所定の基準値（閾値）以上であるか否かを判定する（ステップＳ２９）。基準値を下回る場合、その企業端末１Ａ、１Ｂに対してはステップＳ２５で求めた支払い振り情報の提供を拒否する（ステップＳ３０）。評価点が基準値を満たしている場合、支払い振り情報集計部２４は支払い振り情報記録部３０からステップＳ２５で求めた支払い振り情報を読み出し、データ送受信部２０を介して企業端末１Ａ、１Ｂに送信する（ステップＳ３１）。なお、送信する支払い振り情報としては、企業端末１Ａ、１Ｂの取引先企業についての支払い振り情報を選択して送ることとする。
【００５５】
なお、以上のような取引情報共同管理サーバ２からの支払い振り情報の提供は、企業端末１Ａ、１Ｂから問合わせがあったときに随時行われて良い。また、取引先企業ではない企業（例えば企業コード指定）についての情報提供を行ってもよい。
【００５６】
また、情報セキュリティに関し次のような手順を実行してもよい。例えば、販売管理ツール３Ａ、３Ｂからそのクライアント毎に割り当てられたキーをもとに、ユーザ情報を暗号化し、この暗号化された情報を企業端末１Ａ、１Ｂが取引情報共同管理サーバ２に送信する。取引情報共同管理サーバ２は、ユーザごとに用意したキーをもとに送信されてきた情報を復号化をする。これが正しく復号された場合には通常の処理を行う一方、復号化が不可能である場合に、処理を停止するとともに支払い振り情報の提示を行わないようにする。また、この手順における企業端末１Ａ、１Ｂ側の手順を、取引情報共同管理サーバ２から派遣されたエージェントが行っても良い。
【００５７】
以上説明した本実施形態によれば、取引振りの情報を他社と共有することで取引先の支払い振りの情報（滞納情報）を一刻も早く知ることができる。また、取引をはじめる前に支払い振りの情報を参照することで、取引条件の変更を前もって行うことも可能になる。例えば、取引を止める、取引額を縮小する、利益率を上げる等の対応である。これらの対応は、取引が開始された後に行うのは困難である。
【００５８】
なお、本発明は上述した実施形態に限定されず種々変形して実施可能である。例えば本発明は企業間取引のみならず、企業対個人（Ｂ　ｔｏ　Ｃ）あるいは個人対個人（Ｃ　ｔｏ　Ｃ）の取引に関する情報を共同管理するものとして実施することもできる。
【００５９】
【発明の効果】
以上説明したように本発明によれば、コンピュータネットワークを利用して企業間の取引振りの情報を共有管理し、これを公正に提供することのできる取引情報管理方法およびプログラムを提供できる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る取引情報共同管理システムの概略構成を示す図
【図２】同実施形態に係る情報提供サービスを実現するための、企業端末および取引情報共同管理サーバの各々の機能構成を示すブロック図
【図３】企業端末側の処理手順を示すフローチャートであって、取引情報更新の処理手順を示すフローチャート
【図４】企業端末側の処理手順を示すフローチャートであって、支払い振り情報作成の処理手順を示すフローチャート
【図５】取引情報共同管理サーバ側の処理手順を示すフローチャートであって、企業端末側からの情報提供の受信処理手順を示すフローチャート
【図６】取引情報共同管理サーバ側の処理手順を示すフローチャートであって、企業端末側からの要求に基づく支払い振り情報提供の処理手順を示すフローチャート。
【符号の説明】
１０…入力・表示機能部
１２…データ送受信部
１４…取引情報格納部
２０…データ送受信部
２２…データ登録状況管理部
２４…支払い振り情報集計部
２６…採点部
２８…管理情報記録部
３０…支払い振り情報記録部
３２…評価点記録部
【図１】
2004094346.tif 000006
【図２】
2004094346.tif 000007
【図３】
2004094346.tif 000008
【図４】
2004094346.tif 000009
【図５】
2004094346.tif 000010
【図６】
2004094346.tif 000011