(57)【要約】  ユーザ例えば債務者とサーバとの間でネットワーク通信を確立し、オンラインでの取引成立を図るシステム及び方法を提供する。本システム及び方法では、その取引に関する情報をサーバが受信し、そのサーバにもユーザにも帰属していない少なくとも１個の情報源からその取引に関連する利用可能な情報を探索し、その取引の相対当事者側の益になるよう制定されている諸ルールに従いサーバ上でルールベースエンジンを稼働させることによってその利用可能情報に含まれる情報を処理し、そしてそのルールベースエンジンが下した少なくとも１個の決定に従いユーザに対し少なくとも１個の打開案を示す。オンライン接続状態が保たれている間に、そのユーザ例えば債務者は示された打開案のうち１個を受け入れてもよいし、或いは合意の上で他の案を示し、更なる交渉に入ることもできる。
2008517405.tif 000002
【特許請求の範囲】
【請求項１】
ユーザとサーバとの間でネットワーク通信を確立するステップと、
ユーザが携わっている取引に関連する情報をサーバにて受信するステップと、
ユーザにもサーバにも帰属していない少なくとも１個の情報源から上記取引に関連する利用可能な情報を探すステップと、
上記取引の相対当事者側に益があるよう制定されているルールに従いサーバ上でルールベースエンジンを稼働させることによって、上記利用可能情報に含まれる情報を処理するステップと、
ルールベースエンジンが下した少なくとも１個の決定に従いユーザに対し少なくとも１個の打開案を示すステップと、
を有し、上記取引を成立に導く方法。
【請求項２】
請求項１記載の方法であって、上記取引が債務の履行であり、ユーザがその債務を負う債務者である方法。
【請求項３】
請求項２記載の方法であって、上記利用可能情報が、ユーザたる債務者についての信用情報調査報告書を含む方法。
【請求項４】
請求項３記載の方法であって、ルールベースエンジンが、上記債務に対し正当権限を有する金融機関が制定したルールに従う方法。
【請求項５】
請求項１記載の方法であって、ルールベースエンジンが、少なくとも１個の辞書を利用し、受け取った情報をサーバ向けの情報に翻訳する方法。
【請求項６】
請求項１記載の方法であって、打開案のうち少なくとも１個が、上記取引に対し正当な利害関係を有する金融機関が制定したルールに従い立てた案である方法。
【請求項７】
請求項１記載の方法であって、示されたどの打開案とも異なる案をユーザが随時提示するステップを有する方法。
【請求項８】
請求項１記載の方法であって、上記利用可能情報に含まれる情報を処理する際に、金融に関する当該利用可能情報を解析し打開案生成に必要な情報だけを取り出す方法。
【請求項９】
請求項８記載の方法であって、打開案を示すに当たり、サーバと通信して債務履行を図るようユーザに督促する方法。
【請求項１０】
請求項１記載の方法であって、ルールベースエンジンが、ユーザがその取引を上首尾に成立させる可能性を検討するルールに従う方法。
【請求項１１】
請求項７記載の方法であって、先に示したどの打開案とも異なる別の打開案を示すステップを有する方法。
【請求項１２】
請求項１１記載の方法であって、所定の解決ルールに従い上記別の打開案に対する賛否を決するステップを有する方法。
【請求項１３】
請求項１記載の方法であって、ユーザに示す少なくとも１個の打開案に係る少なくとも１個の決済選択肢を、そのユーザに示すステップを有する方法。
【請求項１４】
請求項１３記載の方法であって、決済選択肢として、割引額を直ちに支払う選択肢、一定額に分けて定期的に支払う選択肢又はその双方を示す方法。
【請求項１５】
ユーザとサーバとの間でネットワーク通信を確立するステップと、
ユーザからもサーバからも独立している情報源からそのユーザが携わっている金融取引に関連する利用可能な情報を探索し、該当する情報があればその利用可能情報をサーバにて受信するステップと、
上記金融取引の相対当事者側に益があるよう制定されているルールに従いサーバが上記利用可能情報を処理するステップと、
上記ルールに従い下された少なくとも１個の決定に従いユーザに対し少なくとも１個の打開案を示すステップと、
を有し、上記金融取引を成立に導く方法。
【請求項１６】
請求項１５記載の方法であって、上記金融取引が債務の履行であり、ユーザがその債務を負う債務者である方法。
【請求項１７】
請求項１６記載の方法であって、上記利用可能情報がユーザたる債務者についての信用情報調査報告書を含む方法。
【請求項１８】
請求項１５記載の方法であって、示されたどの打開案とも異なる案をユーザが随時提示するステップを有する方法。
【請求項１９】
請求項１５記載の方法であって、上記利用可能情報を処理する際に、その利用可能情報を解析して打開案生成に必要な情報だけを取り出す方法。
【請求項２０】
債務者とサーバとの間でネットワーク通信を確立するステップと、
債務者についての信用情報調査報告書を探索し、利用可能な信用情報調査報告書があればそれをサーバが取得するステップと、
債権者が制定したルールに従い信用情報調査報告書をサーバにて処理するステップと、
上記ルールに従い下された少なくとも１個の決定に従い債務者に対し債務履行のための打開案を示すステップと、
を有し、債務者が抱える債務を解消に導く方法。
【請求項２１】
ユーザからの通信を受信し、そのユーザにも自分にも帰属していない少なくとも１個の情報源から、そのユーザが携わっている取引に関連する利用可能な情報を探索するサーバを備え、
サーバの構成要素であるルールベースエンジンが、上記取引の相対当事者側に益があるよう制定されているルールに従い上記利用可能情報に含まれる情報を処理し、それによって下した少なくとも１個の決定に従いユーザに対し少なくとも１個の打開案を示すシステム。
【請求項２２】
請求項２１記載のシステムであって、サーバが、上記利用可能情報を取得し上記ルールに基づき解析する解析モジュールを有するシステム。
【請求項２３】
請求項２１記載のシステムであって、サーバが、複数のユーザが執った措置及び資産の内訳に応じ、複数の取引を含む資産を管理する資産管理モジュールを備えるシステム。
【請求項２４】
請求項２１記載のシステムであって、上記取引が債務の履行であり、ユーザがその債務を負う債務者であるシステム。
【請求項２５】
請求項２４記載のシステムであって、上記利用可能情報が、ユーザたる債務者についての信用情報調査報告書を含むシステム。
【請求項２６】
請求項２５記載のシステムであって、ルールベースエンジンが、上記債務に対し正当な権限を有する金融機関が制定したルールに従うシステム。
【請求項２７】
請求項２１記載のシステムであって、ルールベースエンジンが、取得した情報を、少なくとも１個の辞書を利用しサーバ向けの情報に翻訳するシステム。
【請求項２８】
請求項２１記載のシステムであって、打開案のうち少なくとも１個を上記ルールに従い立てるシステム。
【請求項２９】
請求項２８記載のシステムであって、サーバが、先に示したどの打開案とも異なる案の提示を上記ユーザから受けるシステム。
【請求項３０】
請求項２１記載のシステムであって、サーバが、打開案を示すに当たり、本サーバと通信して取引解決を図るようとユーザに督促するシステム。
【請求項３１】
請求項２１記載のシステムであって、ルールベースエンジンが、ユーザがその取引を上首尾に成立させる可能性を検討するルールを含むシステム。
【請求項３２】
請求項２９記載の方法であって、先に示したどの打開案とも異なる別の打開案を示す手段を備える方法。
【請求項３３】
請求項２１記載の方法であって、サーバが、先に示した少なくとも１個の打開案に係る少なくとも１個の決済選択肢をユーザに示す決済処理モジュールを有する方法。
【請求項３４】
ユーザからも自分からも独立している情報源からそのユーザが抱える当該金融取引に関連する利用可能な情報を探し、該当する情報があればその情報を取得するサーバを備え、
サーバの構成要素であるルールベースエンジンが、上記金融取引の相対当事者側に益があるよう制定されているルールに従い上記利用可能情報を処理し、
サーバが、上記ルールに従いルールベースエンジンが下した少なくとも１個の決定に従いユーザに対し少なくとも１個の打開案を示すシステム。
【請求項３５】
請求項３４記載のシステムであって、サーバが、上記利用可能情報を取得し上記ルールに従い解析する解析モジュールを有するシステム。
【請求項３６】
請求項３５記載のシステムであって、サーバが、複数のユーザが執った措置及び資産の内訳に応じ、複数の取引を含む資産を管理する資産管理モジュールを有するシステム。
【請求項３７】
請求項３４記載のシステムであって、上記金融取引が債務の履行であり、ユーザがその債務を負う債務者であるシステム。
【請求項３８】
請求項３７記載の方法であって、上記利用可能情報が、ユーザたる債務者についての信用情報調査報告書を含む方法。
【請求項３９】
請求項３８記載の方法であって、先に示されたどの打開案とも異なる案をユーザが随時提示できるようにする手段を備える方法。
【請求項４０】
債務者との接触を確立してその債務者から情報を受け取り、更にその債務者についての信用情報調査報告書を探索するサーバを備え、
サーバの構成要素であるルールベースエンジンが、その信用情報調査報告書の少なくとも一部分及びユーザが抱える債務に関連する他の情報を含む情報を取得し、債権者が制定したルールに従いそれらの情報を処理するよう構成されており、
サーバが、上記ルールに従い下された少なくとも１個の決定に従い債務者に対し債務履行のための打開案を示すシステム。
【請求項４１】
ユーザについての個人情報、ユーザ口座についての口座情報、マクロ経済についての情報及び取引についての情報のうち少なくとも一種類の情報を、その取引に携わっているユーザからも自分からも独立している情報源のみから、探索するサーバを備え、
この探索によって収集した情報を、上記取引を成立に導くための少なくとも１個の打開案の生成に供するシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、「債務履行用コンピュータシステム及び方法」(Debt Settlement Computer System and Method)と題する２００４年１０月１９日付米国暫定特許出願第６０／６２０１３１号に基づく利益を享受する出願である。
【０００２】
また、本願明細書中には米国にて著作権に基づき保護される表現が含まれている。米国法に基づく著作権者は、自分が保持するあらゆる著作権に基づく保護を受けることができるが、何人かが特許出願又はその明細書中にその表現全体を完全に複製する行為、並びにその包袋又は記録に基づき米国特許商標庁がその表現を刊行乃至発表する行為に対しては、異義を申し立てることができない。
【０００３】
本発明は、大まかには取引を処理し解決するシステム及び方法に関し、より詳細には、借金の取立、債務に関する情報の管理又はその双方をコンピュータネットワークを用いて行うシステム及び方法に関する。
【背景技術】
【０００４】
金融取引の中には、その打開のために、手間や時間がかかり往々にして費用もかかる方法を用い、関連情報を収集しお膳立てを整えねばならないものがある。例えば債務者に対して借金の返済を求める際には、その債務者に返済能力があるか否かを調べ、債権者が妥協できる返済条件を検討し、そして電話等を用い債務者個人に接触し返済を促す等して取立を行わねばならないのが普通である。更に面倒なのは、取立行為に制限が課せられていることである。例えば、債務者の職場に取立人が本人宛メッセージを残すことは禁じられているし、信用情報調査報告書（米国でいうクレジットレポート）を取得できる者及び状況も限定されている。
【０００５】
借金取立以外で打開が面倒な取引としては保険金請求交渉等がある。即ち、保険金請求交渉の際にも、請求者が希望する受取額、保険業者が希望する支払額、そして保険業者の代理人（保険代理人）と請求者を合意に導くやり方を、調査乃至推定する必要がある。典型的には、保険代理人と請求者又はその代理人とが面談又は電話で交渉し、双方とも妥協できる合意点を探る。その下敷きになる要因は種々あり、例えば傷病の程度、請求者の経済的地位乃至資格、合意までの所要費用その他の関連事情が勘案される。
【０００６】
また、従来から効き目のある借金取立方法とされているのは、債権者やその代理人（取立人）が債務者に直接電話する方法である。しかしながら、債権者がかなり激烈な言葉を投げて返済を督促することもあり、そうした場合、債務者は敵からの攻撃と受け取ってしまう。
【０００７】
また、個々の取立人への報酬は通常は債務者からの回収額に応じた成果報酬であるので、取立人は自分の報酬ができるだけ多くなるよう厳しく取り立てるのが普通である。これに対し、債権者の望みは貸付資産ポートフォリオに占める総回収額をできるだけ増やすことであり、そのためには債務者の返済能力を損なわないようにしなければならない。その点で、取立人に対する成果報酬制度は債権者の狙いと相容れない部分がある。即ち、各債務者からの回収額を増やすことと、総回収額を増やすこととの間には、二項対立的な関係があり、肉声その他の手段によって過度に攻撃的に借金の一部を取り立てると、債務者の返済能力が下がって残りの借金を返済できなくなり、債権者の手許への総回収額が減ってしまうことになりかねない。例えば、貸付資産ポートフォリオ上で貸付金が一億ドルあり、それらの債務の一部を免除し返済を求める場合、仮にその返済額を貸付金の９０％までしか減額せずに返済を迫ったら、そのうちの２０％しか回収できなくなるかもしれない。即ち、債権者が千八百万ドルしか得られないかもしれない。これに対して、気前よく７０％まで減額して返済を求めたら、そのうちの３０％を回収できるかもしれない。即ち、債権者が二千百万ドルという比較的多額の貸付金を回収できるかもしれない。
【０００８】
また、取立人による借金取立に通常必要なコストとしては、例えば給料、報酬及び運営設備費（電気代、事務所代、家具・卓上機器及びその維持費、電話機・電話代及びその維持費、管理職人件費、口座維持費等）がある。給料及び報酬は、借金取立だけでなく借り手返済能力調査にも必要である。
【０００９】
通常、取立を行うのは資金を提供した機関ではなく、その債権を大金で買い取った別の機関である。そうした機関は取立だけを目的として行動するので、取り立てる権限はあるもののしてよいことが限られている。そうした機関がひとたび負債取立に着手すると利子だけでなくペナルティも賦課されるので、滞納期間が長期化すると債務額が膨れあがり回収確率が下がってしまう。法定期間の７年（米国の場合）が経過し残債の大部分が法的に免除されることを防ぐには、債務者と早期に接触して勘定にけりを付けねばならない。更に厄介なことに、債権売買者の中には、貸付資産の購入から所有を経て売却に至るまで、口座状態を積極的に追跡しない者もいる。
【００１０】
債権を購入した機関やその代理人は、債務者に督促状を送って接触を試みる。その際には、通話記録が残るよう日常的に、高価なアウトバウンドダイアラキャンペーンをわざわざ使用する程である。こうした現代社会における取立では、債務者との接触に必要な情報（コンタクト情報）が重要であり、コンタクト情報の変化が取立上の一大問題とされている。しかしながら、レクシスネクシス（登録商標）、Ａｃｃｕｒｉｎｔ（商号）、ＴｒａｎｓＵｎｉｏｎ（商号）、Ｅｘｐｅｒｉａｎ（登録商標）、Ｅｑｕｉｆａｘ（商標）等、現存する近隣調査会社乃至興信所により最新の電話番号が解る口座は、作成されている口座のうちの２５％程しかない。即ち、平均して７５％の債務者に対しては、近隣調査会社等で電話番号を調べて接触することすら不可能である。そのため、最新と思われる電話番号が解っても、まずはその電話番号にダイアルしてみて、その電話番号が本当に生きているかどうか、またその電話番号で本当に債務者につながるかどうかを、確かめねばならない。電話番号は頻繁に変わるものであるので、債務者が電話番号を変えた後に、債権者側が前の電話番号に電話を掛けてしまい、それにより発生する費用が積み重なって債権者側の費用が大変な額になることもあるし、またそうした電話を掛けてしまうことで債権者側の効率がかなり下がっている。
【００１１】
取立人は、一般に、債務者に対峙する際様々な手法を駆使するのが普通である。そのうち主要なものとしては、裁判沙汰をちらつかせる、その債務者の個人信用情報が登録されている信用情報調査機関（米国でいうクレジットビューロー）に不都合な情報を登録するぞと仄めかす、返済額割引で釣る等の手法がある。しかしながら、こうした取立技術は、総じて、総回収額を最大限に高めることを意識して築かれたものではない。過去の経験の積み重ねに基づく経験則に従い妥協額を決定するとしても、通常は、例えば信用情報調査機関に滞納状況を報告することで債務者に対し幾分でも影響を与えることができるかどうか、またそれによって特定期日に特定額を払わせることができるかどうかを見極めるため等に、ある程度の調査、検討は行わねばならない。ただ、回収プロセスに費やせる費用には限りがあるので、債務者毎に融通を利かせ柔軟に打開案を練ることもできない。
【００１２】
成立促進手段が求められている取引としては、この他に、例えば保険金請求交渉、支払確約書（プレッジ）による慈善資金調達、献金・募金による政治資金調達等がある。こうした取引のための諸活動には様々な費用及び様々な人員が必要である。例えば他人に電話を掛ける人員が必要であるし、支払意志や支払額を確認するための人員も必要である。必要とはいえ、それを満たすのには手間がかかるし、それを満たすことが困難若しくは面倒な場合や、率直にいって不可能な場合もある。
【００１３】
【特許文献１】米国特許第６３３０５５１号明細書
【発明の開示】
【発明が解決しようとする課題】
【００１４】
上記事項に鑑み、本発明は、借金の取立及び回収等に係る取引を成立に導くことができ、類似目的で使用されていた従来システム及び方法より優れたシステム及び方法を、提供することを目的とする。
【課題を解決するための手段】
【００１５】
ここに、本発明の一実施形態によれば、ユーザ例えば債務者とサーバとの間でネットワーク通信を確立しオンラインで取引成立を促進するシステム及び方法が得られる。サーバは、その取引に関する情報を取得する他、その取引に関する金融情報、マクロ経済要因、履歴情報、信用情報調査報告書等の情報を他の情報源から取得する。サーバは、取得したそれらの情報や、その取引又はユーザに関連するそれ以外の情報等を、そのサーバ上で稼働するルールベースエンジンによって処理する。ルールベースエンジンが従うルールは、その取引の相対当事者例えば債権者の側に益があるよう、当該当事者にとって望ましい解決戦略に基づき定めた（或いは予め定めておいた）ルール等である。ユーザに対しては、例えば、ルールベースエンジンが下した１個又は複数個の決定に従い、少なくとも１個の打開案を示す。ユーザは、オンライン接続状態を保ちつつ、示された打開案のうち何れかを受け入れてもよいし、相手との同意の上で他の案を示し、更なる交渉に入ることもできる。
【００１６】
本発明の他の実施形態によれば、ユーザとサーバとの間でネットワーク通信を確立するステップと、ユーザが携わっている取引についての情報をサーバにて受け取るステップと、ユーザにもサーバにも帰属していない少なくとも１個の情報源から上記取引に関する利用可能な情報を探索するステップと、上記取引の相対当事者の側に益があるよう制定されているルールに従いサーバ上でルールベースエンジンを稼働させることによって上記利用可能情報に含まれる情報を処理するステップと、ルールベースエンジンが下した少なくとも１個の決定に従いユーザに対して少なくとも１個の打開案を示すステップと、を有する方法が得られる。
【発明を実施するための最良の形態】
【００１７】
以下、別紙図面を参照しつつ本発明について詳細に説明する。本件技術分野における習熟者（いわゆる当業者）であれば、以下の説明及び図示に基づき、上述のものもそれ以外のものも含め、本発明の有益性について理解することができよう。
【００１８】
また、本発明についてより完全な理解を期するため、以下の説明では図面を参照する。各図中、同様の事物に対しては同様の参照符号を付してある。
【００１９】
更に、以下の説明は特定の実施形態についての例示説明であり、どのような意味でも、本発明の要旨を限定する材料にしてはならない。
【００２０】
いわゆる当業者であれば、以下の図示説明で示す特定の実施形態に基づき本発明に係るシステム及び方法を実施に移すことができる。更に、当該実施形態に構造的変形、論理的改変、プロセス改変等を施した他の形態にて、本発明を実施することもできよう。即ち、例示した構成は採用しうる様々な構成のうちの典型例に過ぎない。各部材及び各機能は明示なき限り総じて付随的なものであり、その操作乃至動作の順序を入れ替えることもできる。また、ある実施形態の構成部分乃至機能的構成を他の実施形態に組み込むことや、ある実施形態の構成部分乃至機能的構成を他の実施形態のそれと置き換えることも可能である。
【００２１】
本発明に係るシステム及び方法は、大まかには取引成立を促進するためのシステムであり、借金解消、保険金請求、慈善基金応募等の取引を扱うことができる。その手段としては、一方の当事者についての情報を収集し、他方の当事者が制定した一組のルールに従いその情報を解析乃至操作し、そして情報収集解析結果に基づきその人物に対しある種の提案を行う自動情報収集システムを提供する。提案及び情報伝達は例えばインターネット等のコンピュータネットワークを介し暗号化された接続により行う。提案を受けた者は、示された選択肢のうち何れか一つを選ぶか、それを拒絶して他の必要な情報を入力することによって、その取引を成立方向に進めることができる。仮に、その取引に対し本発明を適用したが成立に至らなかったとしても、両当事者の取引成立能力及び意志を、やりとりされた情報に基づき判断することができるし、取引成立に向け次に採るべきステップが何なのか（例えば訴訟提起か取引断念か）をその情報から知ることができる。このように、本発明によれば、取引成立促進プロセス全体が自動化されるため、取引成立に要する費用、時間及び面倒を減らしつつ、その取引について両当事者が受入可能な条件を策定することができる。
【００２２】
また、例えばウェブサイトを介し接触してきた自然人からの要求に応えオンラインで提案を行い自動車保険申込やローン申込を受け付けるシステムが既に提案されているが、その種のシステムでは、アクセスしてきた者についての情報を何ら検討しないまま、その者に対し様々な提案を示すのが普通である。また、この種のサイトは、アクセス者に対し入力を求めるだけで、提案に先立つ外部検討乃至情報探索は何ら行わないので、例えば三人の貸し手がいれば三種類の提案が一人のアクセス者に対し示されることになる。これに対し、本発明においては、そのユーザやその取引に関連する外部情報を探索しその取引にまつわる見解の相違の解決を図る。例えば、債務履行や保険金請求等の二者対立取引にて両当事者間に生じる立場の違いを斟酌して、その解決を図る。
【００２３】
本発明においては、一方の当事者に一組のルールを制定する能力を与え、そのルールに従いルールベースエンジンを稼働させて打開案を生成することにより、両当事者を合意に導くようにしている。即ち、本発明においては、取引関連情報やユーザ関連情報を外部から取得し、一方の当事者にとり望ましい交渉ルールを含む諸ルールに従い稼働するルールベースエンジンにそれらの情報を与えることにより、取引成立を自動促進している。
【００２４】
以下、本発明に係るシステム及び方法の様々な実施形態の構成要素について、場合によってはアーキテクチャレベルで、また場合によっては論理レベルで説明する。それらの多くは従来周知の構造によって構成することができる。本願における機能説明及びプロセス説明を参照することによって、いわゆる当業者は、そのアーキテクチャを使用しそれらの機能及びプロセスを実施に移すことができよう。
【００２５】
後述する処理は、単独プラットフォームで実行してもよいし分散処理コンピュータプラットフォームで実行してもよい。また、そうした処理乃至機能を専用ハードウェアで実現してもよいし、汎用プロセッサやネットワークプロセッサにより実行されるソフトウェア乃至ファームウェアとして実現してもよい。処理対象情報や処理結果情報は、従来から本件技術分野にて知られている各種メモリに格納すればよい。例えば、所与コンピュータシステム乃至サブシステムを構成しているＲＡＭ（ランダムアクセスメモリ）等の一時記憶装置に格納してもよいし、磁気ディスク、書換可能型光ディスク等、種々の長期記憶装置に格納してもよいし、それらを併用することもできる。本発明の趣旨からすれば、既存のメモリ技術によるコンピュータ可読媒体だけでなく、その構造乃至情報のハードウェア乃至回路表現を含め、どのような形態の情報格納機構を採るものでも使用できる。
【００２６】
本発明に係るシステム及び方法の実施には様々な技術を利用できる。例えば、プログラムに従い動作するマイクロプロセッサ上で実行されるソフトウェアとして実施してもよいし、マイクロプロセッサ等のデバイスを複数個組み合わせたハードウェアで実施してもよい。マイクロプロセッサの他に使用できるものとしては、例えば、ＡＳＩＣ(application specific integrated circuit)、ＰＬＤ(programmable logic device)等の専用デバイス又はその組合せによるハードウェアがある。とりわけ、搬送波、ディスクドライブ等のコンピュータ可読媒体等、一群のコンピュータ可実行命令が格納されている格納媒体からそれらの命令を読み出す形態で、本発明に係る方法を実施するとよい。
【００２７】
更に、以下の説明では、本発明に係る取引成立促進システム及び方法の主たる例として債務取立事案の解決のためのシステム及び方法を示しているが、本発明の適用対象はそうした分野に限られるものではない。注記してある通り、本発明は、保険金請求、慈善寄付募集等を含め、様々な方面の取引を対象として実施することができる。
【００２８】
また、本願にて使用する概念のうち「機関」（エンティティ）は、自然人、法人、法人格なき団体等、法的に認められている様々な存在を包含する概念である。更に、これから説明する実施形態に係るシステム及び方法のことを、「知的債務解消システム」「ＩＤＳシステム」又は単に「ＩＤＳ」とも称することとする(IDS:Intelligent Debt Settlement System)。
【００２９】
本発明の実施形態に係るシステムは、債権者又はその代理人（取立会社、取立機構、弁護士等）用のウェブベースプラットフォームとしてオンラインで或いはインターネット上で運用される。従って、債務者は、自分が抱えている債務を、昼夜を問わずいつでもオンラインで解消することができる。また、債務者は、自宅又は職場にある自分専用のマシンから本システムにログイン又は接続して債務を解消できるので、債権者の取立部門や取立会社に電話して取立人と会話するという厄介な手続を省くことができる。また、本システムを用いることによって、債権者は、自分の決定基準、判断基準に従い回収条件を生成してオンラインで提示することができる。従って、本システムによれば、債務者と債権者又は取立人の双方をより迅速に、且つ双方にとりメリットがある条件にてオンラインで、合意に導くことができる。取立人が人を雇って借金を取り立てる必要もない。
【００３０】
債務者がオンラインセッションに参加すると、本システムは例えば信用情報調査報告書等の信用情報を取得する。本システムは、取得したその信用情報に基づき、また債権者が予め定めておいた回収条件に従いその債権者又はその代理人に益があるよう、その債務者の返済能力から見てその債務者が受け入れる可能性がある打開案を生成する。債務者は、回りに敵対乃至対立する人物がほとんどいない環境下で、示された打開案の中から一番望ましい案を選ぶことができる。本システムは、オンライン決済技術を用いた決済処理にも使用できる。また、実際に債務が履行された場合等に本システムから最新の情報を提供することによって、信用情報調査機関への登録内容を更新させることができる。更に、本システムから送られる通知によって、あらゆる利害関係者に対しその取引への注意を喚起することができる。本システムにより債権者向けに情報を表示させることによって、債権者が貸付資産ポートフォリオ上の返済パラメタをオンライン閲覧し、それをリアルタイムで管理することが可能になる。
【００３１】
本システムは、概ね、公開仕様に準拠して構築可能である。本システムの構築には、例えばＭｉｃｒｏｓｏｆｔ（登録商標）のＶｉｓｕａｌ  Ｓｔｕｄｉｏ、．ＮＥＴ  Ｆｒａｍｅｗｏｒｋ及びＳＱＬ  Ｓｅｒｖｅｒ  ２０００（何れも商品名）を使用でき、ＸＭＬに対してフルコンプライアントにすることができる。本システムは、例えばセキュアデータセンターにて稼働させ、パートナー企業を戦略的に支援するウェブ上の技術基盤サービスとして提供する。
【００３２】
本システムは、支払が滞っている消費者等の債務者のうちインターネットにアクセスできる者等を、末端ユーザとするシステムである。本システムを使用する可能性がある又は本システムに関与する可能性がある機関としては、他の機関例えば自然人に金銭を貸し付けている機関即ち「債権者」と、その金銭の貸付を受けている機関即ち「債務者」とがある。債権者になりうる機関としては例えば銀行、信用組合等の貸し手組織の他、他機関に金銭、商品、サービス等を提供する機関例えば弁護士、医師等があり、債権者の中で自力で債権を回収できる機関乃至能力を有するものを「大手債権者」と呼ぶ。他方、債権者に対し債務を負っている機関即ち債務者には、自然人、組合、企業、政府機関等、原理的にはなんびとでもまたどのような経済組織でもなることができる。更に、大手債権者の利益のために借金を取り立て通常は幾分かの手数料を得る者を「取立人」と呼び、債権を買い取り自力でその借金を取り立てる者のことを「債権買取人」と呼ぶ。「取立人」が通常は債権者乃至大手債権者の代理人として行動するのに対して、「債権買取人」は債権者乃至大手債権者から独立である。
【００３３】
図１に本システムの概略論理構成を示す。図中のコンピュータシステム１００は、取引成立促進全般に使用されるサーバ１０２を備えている。サーバ１０２は、債務者が操作する債務者側（ユーザ側）装置１０６例えばパーソナルコンピュータやＰＤＡ（携帯情報端末）と通信ネットワーク１１０経由で通信し、債権者自身が運用し又は債権者側に益になるよう運用されている債権者側サーバ１０４と通信ネットワーク１０８経由で通信する。債権者側サーバ１０４上では、例えば債権者が使用する従来型の回収用ソフトウェア１２０が稼働している。サーバ１０２は、更に信用情報調査機関側サーバ１１６と通信ネットワーク１０７経由で、また独立決済機関側サーバ１１４と通信ネットワーク１０９経由でそれぞれ通信する。
【００３４】
通信ネットワーク１０７、１０８、１０９及び１１０は例えばインターネット、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）等である。債務者側装置１０６上では、インターネットブラウザ等のアプリケーションプログラムの稼働によってＧＵＩ（グラフィカルユーザインタフェース）等のユーザインタフェースが提供され、債務者はそれを用いてサーバ１０２にアクセスする。サーバ１０２上に開設されている債務者アカウントは、例えば債務者がアクセスしてログイン情報を入力するとアクティブな状態になる。
【００３５】
サーバ１０２上で稼働するソフトウェア１１２については後に詳述する。債務者関連情報、例えば債権者側サーバ１０４上の債権情報は、サーバ１０２からアクセスできるようにアカウント交信データベース１１８に格納されている。サーバ１０２は、その内部情報源や外部情報源から取引成立促進に役立つ他の情報も取得し、ソフトウェア１１２との関連で後述する諸ルールをそれらの情報に適用することによって、債務者に提示する打開案を生成する。勘案される関連情報としては、例えばマクロ経済データ、金融情報、取引情報、個人情報等、何らかの形態でユーザ又は取引に関連する情報がある。例えば“債務者居住地域が天災に見舞われたときは自分の債権の債務履行期限を繰り延べる”よう債権者が希望しているとき、本システムでは、債務者居住地域の状況についての情報を探索して債権者の希望に応えることができる。こうした情報探索は、与えられているルールに従い実行することも、或いは与えられているルールとは別のルールに従い実行することもできる。情報探索先になりうるのは、例えばデータベース１１８、サーバ１０４、並びに図１に示されていない別の遠隔情報源（公共天候情報サーバ、金融データサーバ等）である。
【００３６】
ソフトウェア１１２は、回収用ソフトウェア１２０とのやりとりを通じ、リアルタイムに又はセキュアバッチプロセスによって、サーバ１０２上の債務者関連情報と債権者側サーバ１０４上の債務者関連情報とを同期させる。
【００３７】
図１に示すシステムの全般的役割は、債務者と債権者又はその代表者若しくは代理人とを合意に導き取引を成立させることである。その手段として、本システムは、債権者が制定したルールに従い債務者に対し何通りかの選択肢を示す。それらの選択肢は、通常、債権者が提出した情報を解析及び処理することによって、その債務者が受け入れられるものになるように生成する。サーバ１０２は、必要な情報を保持し又は必要な情報にアクセスできる状況を保ちつつ、情報の確保及び収集を通じ、債務者側装置１０６と債権者側サーバ１０４、信用情報調査機関側サーバ１１６及び独立決済機関側サーバ１１４との接触を管理する機能を発揮する。
【００３８】
図２に、サーバ１０２上で稼働するソフトウェア１１２の構成部分たるソフトウェアモジュール間の論理的関係を示す。サーバ１０２を複数使用し、それらの上でこれらのモジュールを分散稼働させてもよい。これらのモジュールのうち対債務者インタフェース２２２は、債務者側装置１０６を使用する債務者に対しインタフェースを提供し、その債務者から得られる情報を妥結エンジン２０６に供給する。対信用情報調査機関モジュール２０２は、現在サーバ１０２にアクセスしている債務者についての信用情報調査報告書を、その債務者についての情報が登録されている信用情報調査機関から取得する。
【００３９】
信用情報調査報告書は信用力調査機関や送付申請者に送られる。信用情報調査報告書は、通常、大量の情報から成り立っている。信用情報調査報告書には、例えば、対象とする人物又は機関の識別属性（その名称、住所、電話番号、出生日、出生地、年金番号（米国でいうソーシャルセキュリティナンバー）等の個人情報等）、その対象者が口座を開設している機関（利用クレジットカード発行者又は自動車若しくは住宅ローン提供者等）についての情報等の他、決済成否、審判決、破産等の重要情報が含まれている。場合によっては、信用力格付（米国でいうクレジットレーティング）や信用力得点（米国でいうクレジットスコア）の計算値も含まれている。対象者に活発な活動経歴がある場合、信用情報調査報告書に含まれる情報項目は数百個、数千個等々にも上ることになろう。
【００４０】
信用情報調査報告書は、一般に、その発行者に固有の書式で頒布される。例えばある信用情報調査機関Ａは、順に姓、名、ミドルネーム、現在居住地の郵便番号・都道府県名・市町村名・丁目番地、現在の電話番号、破産経歴、破産宣告日、破産宣告裁判所名、口座名義等々を含む一連のレコードからなるデータ書式又はスクリプトで信用情報調査報告書を頒布し、また別の信用情報調査機関Ｂは、順に名、ミドルネーム、姓、現在居住地の市外局番、現在の電話番号、現在居住地の郵便番号・都道府県名・市町村名・丁目番地、信用力得点、口座名義、口座現況、口座別各月決済額等々を含む一連のレコードからなる別のデータ書式又はスクリプトで信用情報調査報告書を頒布する、といった具合である。このように、全体として同じ情報が含まれていても、多々ある信用情報調査機関毎にその書式及び掲載順序が全く異なり、また他の信用情報調査機関では掲載しない情報がある信用情報調査機関からの信用情報調査報告書には掲載されているといったこともある。即ち、発行される信用情報調査報告書はその発行元の信用情報調査機関がどこかにより異なる。
【００４１】
本システムでは、対信用情報調査機関モジュール２０２を稼働させ、信用情報調査機関側サーバ１１６が自分の書式で作成した信用情報調査報告書を取得する。信用情報調査報告書の発行元については、通常、その報告書に付随している機関識別情報から、例えば機関Ａであるというように知ることができる。また、ある個人Ｘについての信用情報調査報告書を機関Ａから取得せよとの指令を与えることにより、モジュール２０２をサーバ１１６に接触させその信用情報調査報告書を取得することができる。従って、信用情報調査報告書を取得することで、モジュール２０２にはその信用情報調査報告書の発行元機関が企業Ａであることが解る。なお、取得した信用情報調査報告書に機関識別情報が付されていなくても、解析モジュール２０４に情報を与えて解析させればよい。
【００４２】
大まかにいえば、対信用情報調査機関モジュール２０２は、例えば信用情報調査機関Ａから信用情報調査報告書を取得せよとの要求を妥結エンジン２０６等から受け、その機関Ａのサーバ１１６から信用情報調査報告書を受け取り、受け取った報告書に対しある程度の機能的処理、例えば解析モジュール２０４で利用できる書式に変換する処理や特定の情報を取り出す処理を施す。信用情報調査機関が情報及び信用情報調査報告書の生成方法及び書式を変えることはあまりないので、信用情報調査機関から取得した信用情報調査報告書は、容易に所定書式に変換乃至ペーストすることができる。また、新規フィールド乃至情報の追加等、書式に変更が施された場合は、モジュール２０２又は２０４で使用されるパラメタに変更を加えることにより、その書式変更に対応し新規情報を受け取れるようにする。
【００４３】
対信用情報調査機関モジュール２０２及び解析モジュール２０４は個別的にも協働でも機能するが、総じていうなら、解析モジュール２０４の主たる役割は、信用情報調査報告書のかたちで取得した情報を解析して本システムで利用できる情報をもたらす一方、不要な情報を無視することにある。どの情報を抽出するかは状況次第であるが、例えば各人の氏名を保存し現在居住地の丁目・番地を無視する等、ある種の事前解析乃至処置は有益に行うことができる。解析モジュール２０４を用いた情報解析によって、本システムを構成する他の諸モジュールで好適に処理できる書式による情報を、得ることができる。
【００４４】
本システムでは、個々の債権者又は取立人毎に定めてある幾つかのルールに従って情報を解析する。例えば、ある債権者が債務者の信用力得点、破産履歴及び全口座最新残高だけに基づく取引を望んでいる場合、本システムでは対信用情報調査機関モジュール２０２及び解析モジュール２０４を稼働させてその種の情報だけを取り出す。即ち、取得した信用情報調査報告書に基づき、且つ債権者若しくはその代理人が制定したルールに従い、また場合によってはソフトウェア１２０の管理者が制定したルールも容れて、情報解析を実行する。債権者別ルールはスキーマ２１６、辞書２１４又はその双方に組み込まれているので、解析モジュール２０４は、妥結エンジン２０６を介して又は図示しないが妥結エンジン２０６を介さずに、そのルールを利用することができる。
【００４５】
例えば、信用情報調査機関Ａがある電子書式で作成した信用情報調査報告書を対信用情報調査機関モジュール２０２が取得し、その発行元が信用情報調査機関Ａであることが解ったとする。その信用情報調査報告書がある債権者又は取立人Ｐからの求めに応じて送付されたものである場合、このモジュール２０２や解析モジュール２０４には、機関Ａからの信用情報調査報告書を債権者又は取立人Ｐ側の益になるよう解析しなければならないことが解っている。モジュール２０４は、この知識に基づき且つ債権者又は取立人Ｐ向けルールに従い、その信用情報調査報告書から必要な情報だけを取り出す。例えば、債権者又は取立人Ｐ向けルールから判断して、そのルールを発動するのに必要な入力が、破産の回数及び日付、複数口座で６０日を超えて滞納した回数及び日付、判明している全銀行口座合計での引出可能残高、並びに信用力得点だけであるなら、モジュール２０４は、機関Ａが作成した信用情報調査報告書からそれらの所要情報を取り出す。
【００４６】
或いは、どの債権者又は取立人も同様に必要とする情報を取り出すための共通ルールを設けてもよい。例えば、信用力得点、全銀行口座合計での引出可能残高、識別情報、滞納回数、破産回数、破産日、並びにその人物に貸与できる金額を、共通情報として解析モジュール２０４が取り出すようにしてもよい。こうした情報は、その信用情報調査報告書を発行した信用情報調査機関がＡかＢかＣか等々によって信用情報調査報告書中の掲載場所に違いはあれど大抵の信用情報調査報告書には記載されており、従ってその発行元を問わず信用情報調査報告書から取り出すことができる。
【００４７】
なお、本願中では上記説明のように種々の例を示しているが、例示の目的は説明にあり、本発明に係るシステム及び方法の機能に何か限定を施すことを意図してはいない。即ち、例示していない形態での実施も可能であり、本願中に説明のある例によって本発明の要旨が限定解釈されるべきものではない。
【００４８】
こうして解析モジュール２０４を稼働することによって得られるのは、個々の人物乃至機関についての個々の信用情報調査報告書の解析結果であって、特定の債権者又は取立人に関わる情報だけを含む情報である。
【００４９】
言い換えれば、解析モジュール２０４を用い信用情報調査報告書を解析することにより、妥結エンジン２０６を用いた処理及び決定に使用できる情報が得られる。より詳細には、解析モジュール２０４を稼働させることによって、信用情報調査報告書内項目のうちユーザ即ち債権者又はその代理人が指定した項目及び最新の口座データを取り出して計算し、それら信用情報調査報告書データ及び口座データに基づく計算の結果を皆エンジン２０６に提出して、決定を下すための処理を行わせることができる。
【００５０】
妥結エンジン２０６は、各債務者についての信用情報調査報告書から得られる情報、例えばその債務者の返済能力や銀行及びクレジットカード口座履歴に関する情報に基づき、その債務者向けの打開案を複数通り、計算、算定及び生成する。債務者口座履歴は、エンジン２０６からアカウント交信データベース１１８にアクセスすることによって、判別することができる。このデータベース１１８には、例えば図１中のモジュール群とは別の手段によって取得した情報、或いは図１中の何れかのモジュールを介し信用情報調査機関側サーバ１１６、独立決済機関側サーバ１１４、債務者側装置１０６若しくはそのユーザ等から取得した情報を、債務者別に蓄えてある。蓄えてあるのは、例えば債務者別に信用情報調査機関等から取得した情報、例えば決済履歴、信用力得点、破産、滞納等の情報や識別情報である。ある債務者についてある種の情報を得たいけれども最近の日付の情報を入手できない場合には、可能であればデータベース１１８上の債務者情報を利用することができる。更に、債務者が本システムにログインし、提示された選択肢のうち何れかを選択するか或いは全てを拒絶したときには、妥当である限り、そのユーザがアクセスした時刻及びＵＲＬは最低限、情報として保存しておく。対債務者インタフェース２２２は、また、データベース１１８へのアクセスにより、妥結エンジン２０６への履歴情報供給を支援する。
【００５１】
対債務者インタフェース２２２には二つの機能がある。そのうち一つは、オンラインセッション中等に債務者に対し直接インタフェースを提供する機能であり、もう一つは、必要に応じアカウント交信データベース１１８上の債務者情報にアクセスする機能である。債務者が参加するオンラインセッションは、通常、録音済電話メッセージ、書信、或いは電子メール若しくはテキストメッセージによる電子的接触等によって通知を受けた債務者が開始させる。即ち、通知を受けた債務者は、指定されたウェブサイト、例えばサーバ１０２の所有者又はオペレータの管理乃至運用下にあるウェブサイトにアクセスし、ユーザとしてそのウェブサイトにログインする。このログインに際しては、アクセスしてきた者を、原則としてインタフェース２２２を介し且つ標準的なセキュアインターネットプロトコル等に従い本システムに接続し、更にその債務者に対し一連の認証質問を発して個人認証を確立する。認証質問としては、例えばその債務者の年金番号を問う質問の他、本物の債務者だけが漏れなく正答できる質問（「貴方の誕生日は？」「バンクオブアメリカのどの支店に口座を開きましたか？」「１９９４年に破産したとき貴方の代理人になった弁護士の姓は？」等の質問）を発する。ユーザは、個人認証を確立したければ一連の質問に正答する必要がある。加えて、手紙、電子メール、テキストメッセージ、電話メッセージ等により債務者に初めて接触する際にその債務者に対しある種のコードを知らせておき、ユーザとしてログインしようとする者に対して、個人認証確立用の認証質問への回答に加え、そのコードの入力を求めるようにするとよい。インタフェース２２２は、取立人又はサーバ１０２を管理、制御、保守乃至運用する機関（サーバ１０２管理機関）の状況又は希望に応じ、アクセスしてきた者を本物の債務者として認証するが、場合によってはよりセキュリティの高いやり方で個人認証を行う。使用できる認証方法としては、上述の方法の他に、例えばハードウェア及びソフトウェアによる音声認識用又は指紋認識利用型高精度認証方法等がある。
【００５２】
債務者がユーザとして確認乃至認証されたら、本システムにその債務者がログインした事実を、アカウント交信データベース１１８への情報格納等により記録する。債務者は、例えば返済可能な債務が幾つか列挙されているメニューから選択する操作によって、これからどの債務を俎上に上げるかを指定する。この操作が行われると、次の二種類の状況のうち何れかが生じる。第１に、信用情報調査報告書が既に得られており解析モジュール２０４による解析が済んでいる場合は、妥結エンジン２０６が、債務者が指定した債務の債権者が誰かを調べ、その債権者向けのルール及び判断条件を読み込み、債務者に提示する何個かの打開案を算定し、そして例えば債務者側装置１０６の画面上にそれらの打開案を選択肢として表示させる。第２に、信用情報調査報告書の取得及び解析が済んでいない場合は、短時間例えば数分間待機するよう債務者に求める。短時間で済まない場合は、指定時刻以降に再アクセスするよう債権者に求める。例えば、それまでには少なくとも一種類の打開案を準備するので米国東部標準時で午後４時以降に再びログインされたし、と求めるメッセージを、債務者に送信する。その際、債務者に対しセッションコード又は１個若しくは複数個のパスワードを知らせ、その入力によって再ログイン時に認証質問プロセスを省けるようにするとよい。
【００５３】
信用情報調査報告書解析結果を情報として利用できる状況で、債務者が個人認証され又は対債務者インタフェース２２２を介し本システムに再接続すると、妥結エンジン２０６は、債権者又は取立人等、その債務の履行の途を探っている機関向けのスキーマ２１６、ルール及び辞書２１４を読み込み、辞書２１４及びスキーマ２１６に依拠しつつ決定を下し又は選択肢を作成して、それらを債務者に提示する。本願でいうところのスキーマ２１６とは、状況に応じて適用できるように複数個のルールを構造化したフレームワークのことである。例えば、債権者又は取立人をＸとすると、Ｘについてのスキーマ２１６は例えば次の諸ルール
「一人の債務者に１回に提示する選択肢は最大３個までとする」
「その債務者が過去１０年間に複数回破産宣告を受けている場合、その債務者に提示する案では必ず借金のうち９０〜１００％の返済を求める」
「初回ログイン後一旦ログアウトする等何らかの理由乃至原因で接続が断たれた債務者に対しては、再ログインしても初回ログイン時に提示した打開案は提示せず、提示する案は借金のうち９０〜１００％の返済を求める案に限る」
「その信用力得点が６５０を超えている債務者に対しては、（１）未返済額の一括返済、（２）未返済額を年利８％で１２ヶ月割賦、並びに（３）未返済額を年利１０％で２４ヶ月割賦、という三種類の選択肢を提示し、併せて、選択肢（１）による返済に同意すれば貴方の信用力得点が大きく下がることはないが選択肢（２）及び（３）の場合は関連する全ての信用情報調査機関に対し滞納の事実を報告する、と宣告する。その債務者が選択肢（１）、（２）及び（３）の何れも受け入れなかった場合は、未返済額のうち９０％を一時払いで返済すればよいがその引替に関連する全ての信用情報調査機関に対し返済額不足を報告する、という単一の選択肢を提示する」
「その信用力得点が６７５を超えており、全口座合計での引出可能額に対する本件債務額の比が５％未満であり、且つ全口座合計での引出可能額に対する他の負債の合計額の比が２５％未満の債務者に対しては、（１）未返済額の９０％を返済すれば信用情報調査機関に報告しない、（２）未返済額の８５％を年利１０％１２回払いで返済してもよいがその場合は信用情報調査機関に滞納と報告する、（３）未返済額の８０％を年利１２．５％２４回払いで返済してもよいがその場合は信用情報調査機関に滞納と報告する、並びに（４）未返済額の５０％を一時払いし残りの５０％を年利５％１２ヶ月割賦すれば信用情報調査機関には報告しない、という四種類の選択肢を提示する」
を含むものになる。
【００５４】
この説明から理解できるように、生成するルール及びそのスキーマ２１６には、非常に複雑なものを含め、原則としてどのようなルール及び条件を含めることもできる。また、スキーマ２１６のモジュールとそれを構成する一群のルールは、債権者、取立人、サーバ１０２管理機関、又はそれらの連携で作成される。例えば、ある債権者Ｂがある条件下で適用したいと望んでいる一群のスキーマ２１６に、年利指定を伴う回収条件を適用するルールが含まれている場合、サーバ１０２管理機関の取り分として０．２５％の年利を自動的に上乗せするルール又はそのスキーマ２１６を、サーバ１０２管理機関が制定することができる。また、サーバ１０２管理機関は、その地域で適用される諸法令に従い、その地域の債務者に対し例えば２５％超の利率の適用を求める打開案が示されないように、ルール又はそのスキーマ２１６を制定することができる。更に、債権者からは打開案生成用の大まかなガイドラインだけを示すようにし、サーバ１０２管理機関がそのガイドラインを具体化してルール及びそのスキーマ２１６を制定するようにしてもよい。
【００５５】
例えば、ある債権者が示したガイドラインが、各債務者に案を三通りずつ示すこと、そのうち一つは未返済額全額返済案とすること、残りの二つは債務者の信用力得点に応じた利率及び返済期限での返済案にすること、並びに信用力得点が高い債務者には低めの利率を適用すること、を定めるシンプルなものであったとする。サーバ１０２管理機関は、債権者が示したこの情報に従いその債権者の望みを体現するルール及びそのスキーマ２１６を制定し、またその地域での上限金利規制に従いつつ債務者の信用力得点に応じて利率を変化させるスキーマ２１６を制定する。具体的には、未返済額全額返済案に加え、債務者の信用力得点が５００未満なら利率が何れも２５％で返済期限が異なる二案を提示し、５００以上６５０未満なら利率１０％１２ヶ月割賦案及び利率１２％２４ヶ月割賦案を提示し、６５０以上７５０未満なら利率６％１２ヶ月割賦案及び利率８％２４ヶ月割賦案を提示し、７５０以上なら利率５％１２ヶ月割賦案及び利率５％２４ヶ月割賦案を提示する、といったスキーマ２１６を制定する。
【００５６】
更に、必要に応じ打開案に信用情報調査機関への報告宣告を盛り込めるようにし、また打開案に盛り込む利率及び条件を定期的に更新できるようにしてもよい。それには、スキーマ２１６自体を変更でき又はルール適用時に使用する情報を変更できるようにする必要がある。例えば、貸付時プライムレートに応じて回収期限を定めるルールを含むスキーマ２１６を制定する際には、例えば辞書２１４への登録によってそのプライムレートを本システム内に組み込むようにすればよい。そうすれば、辞書２１４の更新によってそのルールを更新することができる。或いは、定期的に更新しつつプライムレートを出力する装置から何らかのインタフェースを介し、妥結エンジン２０６が日常的にプライムレートを取得するようにしてもよい。
【００５７】
そうした妥結エンジン２０６は、サーバ１０２のアドミニストレータやサーバ１０２に対し業務上その他の関わりを持つ他の機関が予め制定しておいたルールに従う典型的なルールベースエンジンであり、そのルールには、従って、債権者が定めた債権者別判断条件２１２を構成する情報が含まれている。更に、エンジン２０６にはインタラクティブ性があり、他者から与えられる情報を利用しエンジン２０６が打開案を生成して対債務者インタフェース２２２を介しユーザに提示する。
【００５８】
このように、妥結エンジン２０６の機能は、全体としていえば、対債務者インタフェース２２２を介し債務者とやりとりし、債務者のユーザ認証が済んだ後にその債務者についての信用情報解析結果を取得し、またその債務者についての様々な情報をアカウント交信データベース１１８から取得することである。エンジン２０６は、その債務者が負っている特定の債務について、辞書２１４、スキーマ２１６及び債権者別判断条件２１２に従い、その債務者向けに少なくとも１個の打開案を準備する。インタフェース２２２を介しその債務者にそれらの打開案が提示されると、その債務者は、そのうち何れか１個を選択することによって、その債務の解消を図ることができる。
【００５９】
妥結エンジン２０６による打開案生成には、従って、ルール又はそのスキーマ２１６、債権者別判断条件２１２、辞書２１４等が使用される。そのうちのルールは、例えばその債務者についての信用情報調査報告書から得られる情報例えばその債務者の最新の信用力得点等の情報を用いて、表現される。また、ルールの中には、例えば算術関数乃至論理関数によって表現されるルールもある。使用できる関数には様々な種類があり、また各ルールに多数の関数を組み込むこともできる。使用する関数のオペランドには、例えば債権者が提出した債務者関連情報等がセットされる。具体的には、債務規模、債務発生日、最終返済日等がオペランドにセットされる。
【００６０】
また、辞書２１４は、信用情報調査報告書、債権者別判断条件２１２及びスキーマ２１６の記述に使用されている用語に対する訳語を提供する機能を有している。妥結エンジン２０６は、対信用情報調査機関モジュール２０２及び解析モジュール２０４が取得及び解析した信用情報調査報告書や、債権者別判断条件２１２に基づき、ルール及びそのスキーマ２１６を取得し、辞書２１４を用いそれらを自分が利用できる書式に変換即ち翻訳する。例えば、ある信用情報調査報告書の「姓」フィールドに記載されている情報も、別の信用情報調査報告書の「名字」フィールドに記載されている情報も、中身は同じである。また、エンジン２０６では「最近の滞納日」として扱う情報が、種々の信用情報調査報告書では、「最近の滞納」フィールド、「最終未履行決済」フィールド、「直近義務不履行」フィールド等々と異なる情報として表されている。辞書２１４は、信用情報調査報告書用語及び債権者別スキーマ２１６用語をエンジン２０６が認識及び理解できる訳語に変換する手段である。また、辞書２１４には、このように一群の語彙を他の一群の語彙に関連付ける機能に加え、他種パラメタの翻訳乃至変換機能を組み込むこともできる。例えば、月利で表現されている利率を年利に換算する機能である。このように、辞書２１４には、信用情報調査報告書、スキーマ２１６内ルール、並びにエンジン２０６内部変数間の翻訳に役立つ訳語及びエントリが登録されている。
【００６１】
また、スキーマ２１６は、債権者側サーバ１０４からサーバ１０２へとインポートされるソースデータ、例えば債権者が管理するコンピュータシステムやサーバ（債権者側サーバ１０４等）から供給されるルール、判断条件その他の情報に基づき、生成される。いわゆる当業者にとり既知のスキーマエディタ等をサーバ１０２上で稼働させることができる場合には、債権者が本システムにアクセスし、サーバ１０２上のスキーマエディタを利用してスキーマ２１６を編集することができる。また、同種のスキーマエディタを本システム外で稼働させ、編集したスキーマを本システムに送り込むこともできる。なお、ソースデータは債権者側サーバ１０４等から供給されるものであり、そのデータ構造が供給元債権者側システム毎に様々に異なることから、サーバ１０２では、受け取ったソースデータを適宜変換してからスキーマ２１６生成に利用する。
【００６２】
生成された債権者別スキーマ２１６は、辞書２１４を豊かにし、情報をある形態から別の形態へと翻訳する機能を付加乃至増強するのに利用できる。即ち、オフライン状態でのマニュアル作業により、或いは自動的に、そのスキーマ２１６を解析することによって、そのスキーマ２１６にて用いられている用語、用語法、書式及び体裁を解明し、その結果を利用することによって、辞書２１４に、新たな翻訳機能乃至変換機能を加えることができる。また、ソースデータをインポートする際にそのソースデータにＥＴＬ処理（Ｅ：エクステンド、Ｔ：トランスファ、Ｌ：ロード）を施し１個又は複数個のルール辞書例えば辞書２１４を生成するスキーマ２１６を、制定しておくこともできる。その際、そのスキーマ２１６による処理に供するソースデータファイルを１個又は複数個任意に指定することができる。従って、何個かのソースデータファイルを指定しそのスキーマ２１６による処理に供することにより、それぞれ異なるフィールドタイプを有し異なるルールを含む様々な種類の辞書２１４を、得ることができる。
【００６３】
辞書２１４には、先にも述べた様々な提案変数及びガイドラインについての記述を含めることができる。ガイドラインとは、債務者プロファイルがその条件を満たすと特定の何種類かの打開案がその債務者に示されることとなる条件のことであり、辞書２１４、スキーマ２１６又は債権者別判断条件２１２のモジュールの一部に、或いはサーバ１０２上の他の場所に、組み込まれる。また、提案変数とは、所定の算術関数等に基づき打開案を生成する際に使用される変数のことである。例えば、債務者が特定地域に居住していることを条件に打開案を生成する場合における地域や、債務規模及び前回返済日からの経過日数を数式に代入して打開案を生成する場合における債務規模及び経過日数が、提案変数に該当する。提案変数は例えば基本デフォルト値の設定に使用し、その値を調整するルールを併用するようにする。例えば、回収期限までの日数を示す提案変数Expiration(days)を用い「Expiration(days)=25」即ち２５日以内返済と初期設定し、「If Accured Interest>=1000 then Value(Expiration(days))=37」即ち「累積利息≧１０００なら３７日以内返済」というルールに従い、債務者情報から見て「累積利息≧１０００」という条件が満たされている場合に初期値２５を３７に変えるようにする。こうしたルールは辞書２１４に組み込んでもよいが、債権者別判断条件２１２やスキーマ２１６に組み込む方がよいであろうし、またサーバ１０２上のどこかまた別の場所に組み込むようにしてもよい。
【００６４】
図８に、スキーマ２１６に従い且つソースデータに基づき辞書２１４に項目やルールを追加する処理、即ちマッピングの概略を概念的に示す。各スキーマ２１６は、それぞれ別の債権者又は取立人、例えば互いに別の金融機関からインポートされるソースデータを処理できるように、制定されている。インポートされたソースデータは、対応するスキーマ２１６に従い変換され、その結果に基づきスキーママップが生成され、そのスキーママップに従い、指定された１個又は複数個の辞書２１４に項目やルールが追加される。ソースデータにおけるフィールド構成と、最終的に辞書２１４に組み込む際に望まれるフィールド構成との間には、大抵の場合相違してるけれども、こうしたマッピングを行うことによって、その差を埋めることができる。例えば、ソースデータ中の４桁の「最優遇貸付金利」フィールドをサーバ１０２で処理できる５桁の「最優遇金利」フィールドに変換するには、「最優遇貸付金利」を「最優遇金利」と読み替え且つ数値に数字「０」を添えて桁を増やすスキーママッピングを行えばよい。
【００６５】
このマッピングに当たっては、１個のソースデータに基づき複数個の辞書に項目等を追加することもできるし、また複数個のソースデータファイルに基づき１個の辞書に項目等を追加することもできる。また、スキーママップを記述するのに種々の式を用いることもできる。そうした場合、それらの式によってある共通のソースデータ片から複数通りの計算値を導出でき、１個又は複数個の辞書２１４に含まれる多数且つ多様なフィールドに、それらの計算値をセットすることができる。
【００６６】
こうしたマッピング機能の他、オリジナル辞書をコピーして別にスタンドアロン辞書を生成する機能や、そのスタンドアロン辞書を編集してオリジナル辞書と異なるルールを含める機能等を、サーバ１０２に持たせることができる。加えて、上述したマッピングプロセスを用い、辞書２１４からデータをエキスポートすることもできる。それには、辞書データをエキスポートデータファイルに変換するスキーマ２１６Ｎを、生成すればよい。
【００６７】
こうして生成補強される辞書２１４を用いて生成される打開案の内容は、一般に債務者毎に異なるものになる。例えば、他の債務者に提示される返済条件とは異なる構成の返済条件を含む打開案が、各債務者に提示される。提示される打開案には、例えば割引額即時一括返済の案が含まれることがあるし、また固定金利月賦の案が含まれることもある。
【００６８】
そうした打開案を生成する際、妥結エンジン２０６は債権者別判断条件２１２に従う。この条件２１２は例えばサーバ１０２からアクセス可能なメモリ内に情報として格納されている。条件２１２は、それまでに１人又は複数人の債権者がそれぞれ自分のサーバ１０４を用いてめいめいにサーバ１０２にアクセスした際、それらの債権者からサーバ１０２が提供を受けた情報であり、打開案を生成する際エンジン２０６が従わねばならない一組のルールとして格納されている。
【００６９】
妥結エンジン２０６が準拠する諸ルールは、また、それらのルール及びその成果である回収結果を解析することによって、最適化するのが望ましい。諸ルールの最適化は、ある特定の債権者向けに、或いはある一群の債務者向けに、或いはその他の特定状況向けに、施すとよい。
【００７０】
例えば、回収率を勘案して最適化を施せば、債権者、取立人又はサーバ１０２管理機関の期待に応えることができる。具体的には、ある一群の債務についての回収率が１００％に近づいてきているとき残りの債務者に提示する利率を下げ或いは要返済額を残債全額からその９０％に下げ、逆に回収率が０％に近づいてきているときや所望水準に達していないとき残りの債務者に提示する利率を上げ或いは一括返済に限定し或いは９０％返済ではなく全額返済を求めるよう、ルールを最適化することができる。なお、諸ルールに対する最適化の仕方はこれ以外にもあり得る。
【００７１】
回収マネージャ２０８は本実施形態にてオプション的に作成されたモジュールであり、債権者が指定した取立人又は管財人等が債務者からの提案を検討しているか否か、承認したか否か等について、債権者はこのモジュールから通知を受けることができる。また、前述の取引成立促進プロセスには、債権者がサーバ１０２にログインし債務者側が示した一群の対案のキュー等を検討できるプロセスが、組み込まれている。債権者は、債務者側対案を受け入れたり、退けたりする等、個々の債務者に対し何らかの措置を講ずることができる。
【００７２】
なお、ソフトウェア１１２を構成する種々のブロック、モジュール乃至コンポーネントの論理的関係を図２に示したが、それらのコンポーネント間の境界線は決して固定的乃至不動的なものではなく、例えばある単一のコンポーネントである機能を実現する場合もあればその機能を複数個のコンポーネントの連携で実現する場合もある等、ソフトウェア１１２の機能は様々なコンポーネントにより様々に実現しうるので、上述した機能区分は固定的乃至不動的なものではない。例えば、妥結エンジン２０６は解析モジュール２０４から得られる信用情報調査報告書解析結果に対しルール及びそのスキーマ２１６を適用するだけで、回収マネージャ２０８が打開案を生成して対債務者インタフェース２２２を介し債務者に提示するようにしてもよい。
【００７３】
これもまたオプション的コンポーネントである決済プロセッサ２１０は、取立プロセス中の決済処理及び勘定機能（の一部）を担っている。即ち、前述の通り工夫されている打開案のうち債務者が所定期間内割賦等の返済条件を指定する案を受け入れると、このプロセッサ２１０は、その債務者からより多くの借金を取り立てることができるよう、その債務者に対し種々の決済方法、例えばクレジットカード決済、デビットカード決済、銀行口座定例引落等の方法を提示する。プロセッサ２１０は、更に、その返済金又は債権を全関係者に仕向分配する返済金仕向処理を取り仕切る。ここでいう関係者とは、例えば、従来からその債務者に対する督促に関与してきた諸機関やサーバ１０２を利用した合意形成に関与してきた諸機関のことである。決済プロセッサ２１０は、例えばサーバ１０２上に格納されている分配額決定ルールにアクセスし、それに従ってこの返済金仕向処理を実行する。例えば、クレジットカード決済された債務について、例外なしに回収額のうち４％をクレジットカード発行者が控除し、その上で残りの９６％からサーバ１０２管理機関が２％を取り債権者又は取立人が９８％取るよう、分配額決定ルールが定められている場合、プロセッサ２１０は、クレジットカード発行者、サーバ１０２管理機関及び債権者又は取立人に対し、回収額の４％、１．９２％又は９４．０８％（同順）を分配する。即ち、プロセッサ２１０の稼働によって、あらゆる決済方法による回収金がその決済方法毎に分類され、各方法による決済額が所定の分配額決定ルールに従い仕向分配されることとなる。この動作を実行するため、プロセッサ２１０は独立決済機関側サーバ１１４とやりとりする。独立決済機関側サーバ１１４とは例えば銀行、クレジットカード発行者その他の機関にて運用されているサーバのことであり、プロセッサ２１０は、債務者が指定した方法での決済をこのサーバ１１４を介して依頼し、また一時払い分及び後日払い分の決済額を一群の所定ルールに従い且つこのサーバ１１４を介して権限のある関係者に分配する。その際に準拠する種々のルールは本システム内で保持されていればよく、例えばスキーマ２１６に組み込んでもよいし、回収マネージャ２０８や決済プロセッサ２１０に組み込んでもよい。
【００７４】
本システムでは、サーバ１０２にてまたソフトウェア１１２との連携及びその実行を通じ、決済機関、債権者、取立人等々の組織構成単位をＯｒｇＵｎｉｔとして扱い、ＯｒｇＵｎｉｔ毎に決済額を分配することができる。即ち、取立人等の組織は取立部門、融資部門、会計部門等々の部署乃至ユニットから成り立っており、更にそれらのユニットがそれぞれ複数個のサブユニットから成り立っていることが多い。本システムはＯｒｇＵｎｉｔベースで構築されており、ＯｒｇＵｎｉｔ毎のルールや複数の又は全てのＯｒｇＵｎｉｔに共通のルール等、様々なルールを制定して適用するができ、同一組織内の複数の部署にそれぞれＯｒｇＵｎｉｔを関連付けることでそれらの部署間で決済額を分け合うことができる。
【００７５】
また、分配額決定ルールを総勘定元帳（Ｇ／Ｌ）勘定分配ルールにし、ＯｒｇＵｎｉｔ毎に複数種類の勘定科目一覧表、例えば現金主義トラストチャート及び発生主義オペレーショナルチャートを作成するようにするとよい。その場合、分配額決定ルールとしては、手数料、元金及び利息残高への分配金の振り分け方及びその順序を勘定科目一覧表毎に指定する諸ルールを制定しておく。また、その分配額決定ルールによって、例えば発生主義オペレーショナルチャート上の借り方受取勘定及び貸し方総収入に記載する等々と、分配金の記帳方法を指定するようにする。このような総勘定元帳勘定分配ルールを適用することにより、本システムを用いた入出金を全て自動記帳できる。更に、資産マネージャ２２０においては、貸付資産運用の節目イベント例えば完済や返済約定に結び付ける勘定ルールによって、各債務プールを対応するシステム内債権管理条項に結び付けているので、資産マネージャ２２０は、この自動記帳を通じ、成立した取引についての情報を得ることができる。更に、決済プロセッサ２１０による分配処理が実行されると、各ＯｒｇＵｎｉｔに対応する組織構成単位の許に分配金が届く。なお、ＯｒｇＵｎｉｔ単位での分配額決定を適正に行うには、それ相応に一群の勘定ルールを制定すればよい。
【００７６】
報告エンジン２１８は、債務、債務者側措置、提示済打開案、合意済打開案、回収済貸付額、回収予定貸付額等、本システム内で計算され本システムからもたらされる種々の関連情報を収集し、必要な情報をスプレッドシートその他の文書形式による報告書式に従いとりまとめ報告を生成する。その報告は融通の利く体裁の報告になっているので、債権者、取立人、（諸）サーバ１０２管理機関等、本システムにより成立が図られた諸取引に対し正当な利害関係のあるあらゆる機関にて、役立てることができる。即ち、債権者や取立人は、要求によって又は定期的に、回収済債務プール額、回収済額を含む返済条件、使用された返済手段、今後の返済予定額及び期日等についての報告を受ける。
【００７７】
例えば、報告エンジン２１８にて日刊、週刊、月刊等のペースで報告を生成し、その報告を随時、正当権限のある利害関係者（の一部）に送付するとよい。このエンジン２１８は、決済プロセッサ２１０と通信して債務履行状況情報を取得するよう、また回収マネージャ２０８との通信により情報報告管理ルール（債権者が予め制定しておいたもの）にアクセスするよう、構成するとよい。
【００７８】
資産マネージャ２２０は、更に債権残高管理、他機関宛貸付資産移転乃至販売管理等を実行する。この債権残高管理もまた本システム上のルールに従って行われるものであり、その対象になる決済には、各ＯｒｇＵｎｉｔに対応する組織構成単位による政府・自治体への納税、当該組織構成単位から他の機関乃至組織構成単位への規定額支払（例えば家賃、地代、手数料、会費、使用量等の機関間決済）等がある。
【００７９】
このように、資産マネージャ２２０の諸機能は、債権者別判断条件２１２を構成する情報を含む諸ルールに従い実現されるものである。マネージャ２２０の機能の例としては、更に、一組の所定条件例えば債権者が制定した条件に従い債権を複数個の子資産に分割すること（サブポートフォリオのグループに変換すること）によって、所定条件を満たした子資産を機関間又はＯｒｇＵｎｉｔに係る組織構成単位間で売却乃至移転可能にする機能がある。従って、自分の希望に合った貸付資産、例えばその貸付資産全体での債務額が１００００００〜５００００００ドルあり、借り手全員での信用力得点平均値が６２５超であり、しかもどの債務も１２０日を超えて滞納されていない貸付資産を、他の取立人を介してではなく債権者から直に入手したいと望んでいる取立人Ａは、そうした条件を満たす貸付資産であれば債権額１ドル当たり２０セントを債権者に支払って買い取る、というルールを制定することによって、この機能を利用することができる。このように、マネージャ２２０による貸付資産管理は諸ルールに従い行われる。
【００８０】
本発明の一実施形態に係る処理手順を図３Ａに、他の実施形態に係る処理手順を図３Ｂに、それぞれ示す。まず、図３Ａ中のステップ３０１では、債権者又は取立人側の全債務別債務者別情報に係る口座データをサーバ１０２側のそれと同期させて最新のものにする。ステップ３０２では、制定されている諸ルールに従い且つ取引毎に確認を得つつ随時、債権者又は取立人が貸付資産を管理し、細分し、機関間やＯｒｇＵｎｉｔに係る組織構成単位間で分配及び移転する。
【００８１】
債権者は、債務者に対し、印刷された郵便物、電話、電子メール等を用い、債務履行を促す督促状を送る。債権者、その債権の譲受人又はその債務の取立人は債務者のことを知っており、通常はその債務者について何らかのコンタクト情報を有しているので、督促状送付が可能である。債務者が引越しした可能性もあるしそのコンタクト情報が誤っている可能性もあるが、ステップ３０３では、債権者、債権譲受人又は取立人が上掲の方法により債務者との接触を図る。通常は、ウェブサイトにアクセスするための情報及びコードを各債務者に知らせておけば、多数の債務者がその求めに応じてそのウェブサイトにアクセスしてくる。また、債務者側から債権者、債権譲受人又は取立人に接触して債務履行の意向を示してきた場合には、サーバ１０２にアクセス乃至ログインするのに必要な情報を、その機にその債務者に伝えることができる。このように債務者との接触を確立、確保する手段は色々あるが、何れの手段でも、債務者側には、サーバ１０２にアクセスするためのコンタクト情報が伝わることとなる。
【００８２】
例えばサーバ１０２上に開設されているウェブサイトに債務者がログインしその債務者の個人認証が済むと、ステップ３０４にて、ソフトウェア１１２が対信用情報調査機関モジュール２０２を用い、認証された債務者についての信用情報調査報告書の送付を申請する。信用情報調査報告書を得ることができるのは、通常、正当権限を有する機関による明示的な許可がある場合だけであるが、モジュール２０２から信用情報調査機関側サーバ１１６に対して信用情報調査報告書送付申請を受けた信用情報調査機関は、その申請がその債務に係る正当な債権者又は取立人からのものであると推定して信用情報調査報告書を送付する。こうして信用情報調査報告書が得られたら、ステップ３０５にて、上述の通り解析モジュール２０４を稼働させてその報告書に含まれる情報を解析し、妥結エンジン２０６を稼働させて打開案を生成する。
【００８３】
ステップ３０６では、その債務者に対し例えばウェブページ上でその打開案を提示する。このとき提示される打開案は、上述の通り、信用情報調査報告書に含まれる情報の解析結果に基づき、また債権者又は取立人が制定したルールに従い、妥結エンジン２０６が算定したものである。図２１に、債務者に対し提示される一組の打開案の一例を示す。この例では、各案に返済期限が付記されており、債務者は、案毎に設けられているアイコン又はボタンを操作することによって、特定の案を受け入れることができる。
【００８４】
ステップ３０７では、サーバ１０２によって生成されるウェブページ上に、更に別のアイコン又はボタンも表示される。例えばこのアイコン又はボタンをクリックすることによって、債務者は、他にどのような条件を採りうるかにつきサーバ１０２を用い債権者と交渉する意志があることを、表明することができる。交渉条件は、債権者、取立人、サーバ１０２管理機関又はそれらの連合が指定する。例えば、債権者が交渉には応じられないと考える場合もあろう。また、取立人Ａでは債務者との交渉回数を１回に限るのに対して、取立人Ｂが３回までなら認容するといったこともあろう。
【００８５】
交渉を認める場合は、例えばＨＴＭＬによるウェブページ上に何個かのデータ入力フィールド、例えば即時返済可能額、今から１２ヶ月間、２４ヶ月間等々における各月返済可能額、適用利率、元本返済期日等を入力するためのフィールドを設け、債務者がそのフィールドを利用して（但し条件同士に矛盾がないように）自分の希望条件を設定できるようにする。このようにした場合、例えば、ユーザ側から複数月に亘る所定額返済を要望し、その条件を満たす案を生成するよう求めることができる。具体的には、債権者又は取立人側から最初に示された打開案が、１２ヶ月に亘り各月５００ドル返済する案及び２４ヶ月に亘り各月２７５ドルを返済する案の二種類を含んでおり、且つ、債務者が、どちらの案も実行困難乃至不可能なので複数月に亘り各月１５０ドルを返済したいと望んでいる場合、その債権者は、自分が各月毎に返済できる額を入力し返済条件乃至期限の指定等を求めることができる。また、未返済額のうちの２０％を即時返済し残りの８０％を三年間に亘り年利８％で割賦する案が最初に示されている場合でも、同様の情報を入力することができる。
【００８６】
本システム特にそのサーバ１０２からの応答は、交渉のためのルールとしてどのようなルールが制定されているかによって変わる。例えば、２０％を即時返済し８０％を年利８％で三年間掛けて返済する案を受け入れるようルールが制定されている場合は、そうした案が債務者から示されるとサーバ１０２は取引成立と判断し、クレジットカード口座や銀行口座に２０％分の金額を課金するのに必要な情報を要求する処理に進む。また、大抵の場合、最初に示された打開案への逆戻りは禁じられるので、債務者は、一旦交渉を要求したら最初の案に基づく妥結の機会を逸することになる。
【００８７】
また、債務者が示した対案を勘案するようルールが制定されている場合は、妥結エンジン２０６は図２中の他のモジュール群の助力を受けつつその案を評価し、応答の仕方を決定する。例えば、２０％を即時返済し８０％を年利８％三年間で返済する案が債務者から提示された場合、エンジン２０６は債権者が制定したルール、そのスキーマ２１６又はその双方を取得する。そのルール乃至スキーマ２１６が、「交渉の第１ラウンドでは即時返済分が５０％未満の案を受け入れてはいけないが、仮にそうした案が到来したら、エンジン２０６その他のモジュールは、５０％を即時返済し５０％を金利１０％１２ヶ月間又は２４ヶ月間で返済するよう提案してもよい」、と定めている場合、エンジン２０６は、それらのルールやスキーマ２１６に基づき、そうした対案をユーザに提示する。
【００８８】
債務者が何れかの選択肢を選んで債務解消を図った場合や、債務者側対案が債権者又は取立人にとり受け入れうるものである旨、与えられているルールに従いサーバ１０２が通知した場合、ステップ３０８にて、債務者が、決済方法を選んで決済操作を行い、更に合意した返済スケジュールに従って且つ選んだ決済方法を用いて今後の返済が行われるよう段取りを整える（ステップ３０８）。
【００８９】
また、ご理解頂けるように、債務者と債権者又は取立人側ルールとが反目し、取引が成立しないこともある。そうした場合は、債務者に対し、取引不調であるので電話で取立人に接触し引き続き解決の途を探られたし、と通知する。何れにせよ、この段階までにこのインタラクティブなオンラインセッションで得られている情報はセーブしておく。情報をセーブしておけば、その情報に基づき更に交渉を行うことや、その情報に基づきこの取引を成立させうる可能性について判断することができる。取立人は、更に、見解の相違が顕著であれば話し合いを断念し訴訟を提起することもできるし、相手に歩み寄って電話や本システムで再交渉することもできるし、或いはルールを変更した上で本システムを介し再交渉することもできる。例えば、別のルール及びそのスキーマ２１６を定め、債務者のログイン、それらのルール及びスキーマ２１６による新たな打開案提示、そしてそれに基づく取引成立の途を探れるようにする。
【００９０】
また、債務者が交渉を提案した場合に、先に債権者側から示した案を編集可能書式に変えて画面上に表示させ、債務者がその案を編集して債権者側に提示し、それに基づき取引成立を図るようにしてもよい。
【００９１】
また、債務者が交渉を求め又は別の打開案を提案した場合、その債務者を取立人キュー、例えば債権者又は取立人がサーバ１０２にアクセスしてモニタするチャットルームその他のオンラインデバイス乃至ツールに移動させるようにしてもよい。債務者は、貴方の案は取立人キューに回されました、その案に対して債権者側の決定が下されたらチャット、テキストメッセージ、電子メール等を介して通知します、との通知を受ける。
【００９２】
取引が成立したら、本システムは、ステップ３０９として示すように、独立決済機関の信託口座を利用した取引処理に進む。独立決済機関は債権者側に立って取引を監視及び管理するよう委任された機関であり、こうした機関を利用することによって、サーバ１０２管理機関は、自分で資金移動を行う必要がなくなる。例えばサーバ１０２管理機関が債権者、銀行等に代わり金銭信託を受けることが法令によって禁止されている場合、独立決済機関が利用されることとなるであろうが、それでもこの種の機関は必須ではなく、例えばサーバ１０２管理機関が銀行のように資金受託を認められている機関である場合は、独立決済機関を利用する必要も益もない。ステップ３１０では、本システムは、決済プロセッサ２１０に関して先に説明した分配ルールに従って決済処理を実行すること等により、回収金を分配する。ステップ３１１では会計機関に事後通知し、ステップ３１２では報告を生成する。
【００９３】
図３Ｂに、本システム全体の概略動作手順について別の例を示す。ステップ３５１では正当権限のある債権者又は取立人毎のルールをＯｒｇＵｎｉｔに係る組織構成単位が制定し、ステップ３５２では本システムに貸付資産ポートフォリオをロードし、ステップ３５３では債務者に負債解消の機会が到来したことを通知する。債務者はステップ３５４で本システムにログインし、ステップ３５５で個人認証を受け、ステップ３５６で債務を選択する。ステップ３５７では、サーバ１０２が、その債務者についての信用情報調査報告書を対信用情報調査機関モジュール２０２を用いて探索し、場合によってはその債務者に関する情報をアカウント交信データベース１１８から探索する。信用情報調査報告書が得られるまでにかかると見込まれる時間の長さに応じ、サーバ１０２は、債務者に対しある時刻まで或いはある時間待てと指示し、その債務者が戻ってくるまでの間に信用情報調査報告書の探索及びそれに含まれる情報の解析を行うか、或いは信用情報調査報告書の取得及び解析モジュール２０４による情報解析が終わるまでそのまま待たせるか、何れかの措置を講ずる。情報解析が済み債務者に応答可能な状況になったら、ステップ３５８にて、妥結エンジン２０６が、必要なら情報解析結果も利用し指定債務向けルールを読み込み、スキーマ２１６及び辞書２１４並びにもしそれらとは別に準備されているなら債権者別判断条件２１２も読み込む。ステップ３５９では、エンジン２０６が、ルール、そのスキーマ２１６、信用情報解析結果等、本システムの各部から得られる種々の適切な情報に基づき、少なくとも１個の打開案を準備し、ステップ３６０では、本システムがこの打開案を債務者に提示する。ステップ３６１では、債務者が何れかの案を選ぶ。交渉という選択肢が準備されている場合は、債務者は案の受入ではなく交渉を選択することもでき、交渉を選択した場合はステップ３６２にて自分の案を入力することができる。ステップ３６３では、エンジン２０６或いは債権者又は取立人の代表者その他の機関がこの対案を検討し、その債務者案を受け入れるか更にそれに対して対案を示すかを決める。債務者案に対して対案を示す場合、本システムは、ルールに従いその対案を生成し、交渉を認めるかどうかを決め、認める場合は債務者からの対案提示を認めるという動作を繰り返す。最終的には、ステップ３６４として示すように、取引成立か手詰まりの何れかになる。成立となった場合は、ステップ３６５にて決済処理し必要に応じステップ３６６で報告する。ご理解頂けるように、貸付資産の動きに応じたルールの変形・修正等、本願に記載の他の処理或いは図３Ｂに記載のない他の処理を、実施することもできる。
【００９４】
図４に、本システムをＭｉｃｒｏｓｏｆｔ（登録商標）プラットフォーム上で実施した構成、特に債務者とのやりとりのための部分のシステムアーキテクチャを示す。この対債務者システム４００では、オブジェクト指向プログラミング及びＳＱＬデータベース操作によって上述の機能を実現しており、全体として、ルール及びそのスキーマの適用による打開案の生成及び債務者に対するその提示に必要な情報を随時また定期的に取得しつつ、オブジェクトの生成若しくは受信及び操作を行っている。このアーキテクチャは複数個の段に分かれており、それらの段は、インターネットを介して外界にアクセスできるようウェブサーバに接続されている。
【００９５】
図中のウェブサーバ４０１には、いわゆる当業者にとって既知の技術であるところのＡＳＰ．ＮＥＴウェブアプリケーション４０２が組み込まれている。このアプリケーション４０２は、適格のある全ての債務者の装置１０６がインターネットを介し接続できるようにインタフェースを提供しており、債務者はこのインタフェースを介しサーバ１０２に接続して例えば個人認証のためそのサーバ１０２とやりとり等を行うことができる。対債務者インタフェース２２２が有する機能は大抵はこのサーバ４０１により実現される。また、オブジェクトプロキシ４０３は、前述の諸機能が実現されるよう、サーバ４０１と本対債務者システム４００内の他の段との間の情報のやりとりを司る。また、本システム４００を構成するコンポーネントとしては、このウェブサーバ４０１以外に、オブジェクト段サーバ４１０、データ段サーバ４２０及び対信用情報調査機関段サーバ４３０がある。そのうちオブジェクト段サーバ４１０は、サーバ４０１を介し債務者にインタフェースを提供すべく、オブジェクトの生成、受信、変換等を行う。
【００９６】
オブジェクト段サーバ４１０は、オブジェクトサービスモジュール４１１及び妥結エンジン４１２を備えている。モジュール４１１はオブジェクトを受け取り、必要ならデータ段への問合せやオブジェクトの変換を行い、そしてそのオブジェクトをエンジン４１２に供給する。ルール及びそのスキーマを合成・形成し、信用情報調査報告書内情報解析結果にそれらルール及びスキーマを適用することによって打開案を生成し、債務者に対し最初に又は必要であれば交渉段階でそれらを提示できるようにする機能を含め、妥結エンジン２０６の機能の多くはエンジン４１２により実現されている。図示の如く、サーバ４１０は、所要機能を実現できるようデータ段サーバ４２０及び対信用情報調査機関段サーバ４３０双方に接続されており、モジュール４１１と同じくエンジン４１２も、サーバ４２０からルールその他の情報を探索することができる。サーバ４２０は、打開案生成、貸付資産管理等を行うために格納してある上述した各種のデータ例えば種々のルール、スキーマ、辞書等にアクセスできるＳＱＬサーバ４２１を備えている。サーバ４１０のもう一つの接続先であるサーバ４３０は、通常、取引がうまく成立したときに決済に使用される決済サービスモジュール４３１を備えている。
【００９７】
決済サービスモジュール４３１は、決済のための通信をキューイング及び処理し、それらをＡＣＨ、ＣＣ等の決済方法を用いて、また適当な信託口座開設先独立決済機関内の担当部署であってあるＯｒｇＵｎｉｔに関連付けられているものと、債権者又は取立人内の担当部署であってあるＯｒｇＵｎｉｔに関連付けられているものと、の間で交わされている契約や協定に従って、その独立決済機関のゲートウェイへとそれらの通信をルーティングする。例えば、ある債権者又は取立人内担当部署Ａに係るクレジットカード決済は、協定に従ってある独立決済機関に任せ、ＡＣＨ決済も協定に従って別の独立決済機関に任せるようにする。また、本対債務者システム４００では、債権者又は取立人がダイナミックに独立決済機関を選択できるよう、利用できる種々の独立決済機関内担当部署及びそれらが提供する信託決済処理サービスの内容を債権者又は取立人内担当部署向けに表示させることもできる。これに応じ債権者又は取立人が何れかの独立決済機関を選択し利用する決済サービスを申請すると、選択された独立決済機関は申請された決済サービスによる決済を承認又は拒絶する。この決済申請にはデータとして質問票を添付する。独立決済機関側が決済を承認し契約条件を示してきた場合、妥結エンジン２０６が承認時契約ルールに従い稼働してその契約条件、例えば割引率、取引手数料、初期費用等の数値を調べ、決済サービス契約を結ぶ。決済サービス契約が成立したら、債権者又は取立人内担当部署が結んだその決済サービス契約に従い、債務者に対し返済用の決済方法を提示する。
【００９８】
対信用情報調査機関段サーバ４３０は、更に対信用情報調査機関ウェブサービスモジュール４３２を備えている。このモジュール４３２は、信用情報調査機関から信用情報調査報告書等のデータを随時取得し、不適当でない限り、債務者についての信用情報調査報告書を他に与える。このモジュール４３２は、論理構成図上の前述の対信用情報調査機関モジュール２０２に関して説明した機能の大部分を実現するモジュールであり、その接続先である解析サービスモジュール４３３は、論理構成図上の解析モジュール２０４に関して説明した機能の大部分を実現するモジュールである。対信用情報調査機関キュープロセッサ４３４は信用情報調査報告書送付申請をキューイングし、それらを対応する債務者に関連付ける。このように、図４に示した構成の大半は、図２に示した妥結エンジン２０６、モジュール２０２及び２０４、債権者別判断条件２１２、対債務者インタフェース２２２、辞書２１４並びにスキーマ２１６により実行される論理機能を、実現するのに使用されている。
【００９９】
図５に対債権者システム５００のアーキテクチャを示す。このシステム５００もやはり、サーバ段５０１、オブジェクト段サーバ５１０、データ段サーバ５２０及び対信用情報調査機関段サーバ５３０を備えており、図中にはやはりオブジェクト指向プログラミング及びＳＱＬを用いたＭｉｃｒｏｓｏｆｔ（登録商標）プラットフォームによるものを例示してある。このシステム５００は何れの債権者からも独立した状態に保たれているが、その動作は、基本的に取引成立促進プロセスのうちの債権者向け部分についてのもの、即ち債権者データを保全し取引成立促進処理における債権者関連機能を発動させる部分についてのものである。債権者向け部分とは、債権者、取立人等その債務について権限を有する諸機関が、図１に示したシステムの債務者向け部分との間で情報をやりとりしその取引の成立を図れるようにする部分である。このシステム５００によって実現される機能としては、債権者及び債務者データの収集、打開案生成に使用するデータの準備、債権者に対する取引成立及び交渉状況の通知、場合によっては希望に応じた報告の作成等、債権者にとって必要な機能がある。
【０１００】
この対債権者システム５００のサーバ段５０１には、図４に示した対債務者システム４００と同じくＡＳＰ．ＮＥＴウェブアプリケーション５０２及びオブジェクトプロキシ５０３が組み込まれているのに加え、ＦＴＰコンポーネント群及びデータレシーバが組み込まれている。債権者例えば銀行は、データ、ルール等、前述した取引成立促進プロセスを機能させるのに役立つ情報を登録するＦＴＰサイトをここに開設する。所定水準以上の均一性を確保するため、そのＦＴＰサイトには、少なくとも取引成立促進プロセスにて使用される情報のリスト、場合によってはそのデータファイル全体を保存するファイルフォルダ５０４を作成する。このフォルダ５０４を利用することによって、ルール、そのスキーマ、口座、債務等、本システムにて使用する情報を容易に取得できる。また、サーバ段５０１に組み込まれている対債権者データレシーバ５０５は、データを受信してその債権者のフォルダ５０４に書き込む。或いは、このレシーバ５０５から他のシステム内コンポーネントへと直接に、電子メール又はセキュアウェブサービスによってデータパッケージを送信するようにしてもよい。フォルダ５０４及びレシーバ５０５を利用することによって、債権者に対する直接双方向接続を好適に実現でき、債権者エージェントモジュール５１２との間でデータを送受信できる。
【０１０１】
オブジェクト段サーバ５１０は、対債権者オブジェクトサービスモジュール５１１及び債権者エージェントモジュール５１２を備えている。データオブジェクトはこの段にて受信されこの段から転送される。モジュール５１１は、オブジェクトを送受信して処理に供し、また処理後に対債務者システム４００での利用に供する。モジュール５１２は、債権者宛てにエキスポートするデータを生成及び暗号化し、サーバ段５０１上で稼働している対債権者データレシーバ５０５にその暗号化ファイルを送信する。データ段サーバ５２０もまたデータベースにアクセスできるよう構成されており、この段ではＳＱＬサーバ５２１を用いてそのサーバ５２０に発するデータのやりとりが行われる。やりとりされるデータ、即ちサーバ５２１によって送受信されるデータは、無論、債権者に関するデータである。また、対信用情報調査機関段サーバ５３０は取立人業務自動化サービスモジュール５３１を備えている。このモジュール５３１は、処理及び会計の関係上スケジュールに従って実行しなければならないイベント、例えば毎日の開店及び閉店や毎月の締め等のイベントを実行するためのモジュールであり、外部の決済機関等適切な装置と通信することにより、動きのある取引の状況の監視やバッチ報告のダウンロード等、債権者関連諸機能を実現するのに用いられている。取引状況はＳＱＬサーバ５２１によって更新され、それに応じてログ及び現在状況が更新される。更に、サーバ５３０はＭＳＭＱ（Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｍｅｓｓａｇｅ  Ｑｕｅｕｅｉｎｇ）通知を用いてサーバ５１０と通信することによりデータパッケージを準備及びエキスポートする。この債権者向け取立人業務自動化サービスは債務者向けの対信用情報調査機関段サーバ４３０によって実現される機能ほどは拡張性がなく、状況評価及び報告関連情報準備に関わるイベントのスケジュール実行を自動化するだけである。
【０１０２】
図６に、本発明の他の実施形態に係るシステム動作特に妥結手順を示す。この図には、図１に示した論理的システム構成要素たるソフトウェアコンポーネントの多くが明示されている。図６中の信用情報調査機関６０１とは、本システムにて取得したい信用情報調査報告書を発行する信用情報調査機関のことであり、本システムから接触できる信用情報調査機関のほぼ全てがこれに該当する。この図の妥結手順は、概ね対信用情報調査機関サーバ６０２による指示の下に、また丸付き数字で表されている順番に従ってシーケンシャルに、実行される。ステップ１（図中丸付きの１；以下同様）ではログインしてトークンを取得する。このトークンはサーバ６０２上で実行されるセッションにて個人認証を受けるためのトークンであり、情報としてサーバ６０２及び妥結エンジン内プロファイル構築モジュール６０３双方に送られる。ステップ２では抽出リスト即ち抽出すべきデータのリストを取得し、ステップ３では報告リスト即ち対信用情報調査機関サーバ６０２により報告されるべきデータのリストを取得する。通常、抽出リスト及び報告リストの仕様は信用情報調査機関毎に異なっており、概ね、上述した通り対信用情報調査機関モジュール２０２及び債権者別判断条件２１２が決める。例えばある信用情報調査機関Ａ向けの抽出リストにはルール又はそのスキーマとして格納されている情報、例えば信用力得点、債務者の名・姓、最近の破産申請日、２ヶ月超滞納の回数、全口座合計での持ち合わせ金額等が掲げられる。報告リストには、例えば成功裡に成立した取引、履行された債務、支払協定等、その信用情報調査機関に対し報告すべき情報項目が掲げられる。
【０１０３】
妥結手順の実質的な始まりはステップ４である。ステップ４では、例えばある特定の信用情報調査機関に対し信用情報調査報告書送付申請を提出する。この処理は例えば抽出リストに基づき行い、場合によっては報告リストに基づき行う。対信用情報調査機関サーバ６０２は、ステップ５にてＲＤＢＭＳ（リレーショナルデータベース管理システム）６０４から信用情報調査機関ログイン用情報を取得し、ステップ６にてＲＤＢＭＳ６０４から対信用情報調査機関サーバキュー６０５の現状を示すキュー情報やそのキュー６０５にセットされている別の申請についての情報を取得する。キュー情報を取得したサーバ６０２は、ステップ７にて、そのキュー６０５に申請をセットする。即ち、ＭＳＭＱ等適当な送信手段を用いてキュー６０５に申請を送りセットする。キュー６０５にセットされた命令は所定順序で実行されるので、何れは順番が巡ってその信用情報調査報告書送付申請が送信される。これに応答して信用情報調査機関６０１から送信された信用情報調査報告書を取得すると、ステップ８にて、キュー６０５から解析モジュール６０６に受信した信用情報調査報告書を送り、それに含まれる関連情報を解析させる。ブロック６０７は対信用情報調査機関解析実行ロジックである。解析が済んだらステップ９を実行し、モジュール６０６からサーバ６０２に報告通知指令を送る。情報解析結果を得たサーバ６０２は、ステップ１０にて妥結エンジン内プロファイル構築モジュール６０３に結果取得要求を送る。このモジュール６０３は、信用情報調査報告書等信用情報調査機関から得た情報についての解析結果の他、抽出リスト及び報告リストやＲＤＢＭＳ６０４のエントリに基づき、その信用情報調査報告書に係る債務者のプロファイルを構築する。関連する信用情報を利用できるようになったら、ステップ１１にて、モジュール６０３がその債務者のプロファイルを更新し、ＲＤＢＭＳ６０４に追加情報として入力する。
【０１０４】
妥結エンジン内決定モジュール６０８は、妥結エンジン内プロファイル構築モジュール６０３と協働して、図２中の妥結エンジン２０６をかたちづくっている。モジュール６０８は、状況に応じまた債権者又は取立人が認めうるように、一組の条件乃至案の仕様を生成する。決定モジュール６０９は、その仕様を受け取り具体化することによって、打開案を決定して出力する役割のモジュールである。この出力は、例えばＭＳＭＱその他のメッセージ書式で行う。
【０１０５】
なお、この図では妥結エンジン内決定モジュール６０８と決定モジュール６０９を別々に分けているが、図２においては打開案を決定する機能を妥結エンジン２０６に持たせている。即ち、図６中で２個に分かれているモジュール６０８及び６０９を統合して単一の妥結モジュールにすることもできる。また、図６においては、エンジン２０６が各種下位機能毎に分割して描かれている。例えば、外部情報源モジュールとリアルタイム通信するプロファイル構築機能や、それによって構築されたプロファイルにルールを適用して打開案を決定する上述の決定機能等である。
【０１０６】
決定モジュール６０９は、提案検討要請モジュール６１０に対しＭＳＭＱ経由で決定内容に関する通知を送る。このモジュール６１０は、これまでに示した案を保持する提案データベースであり、債務者にまだ送られていない案はこのモジュール６１０にキューイングされている。債務者に送る打開案は、該当ページを対コンシューマＡＳＰＸページロードモジュール６１１にロードすることによって、債務者に送信する。モジュール６１１は本システムに対するあらゆる応答を受信し、それをＭＳＭＱ等適切なメッセージ書式によってモジュール６１０に送る。モジュール６１０は、提示されたページ上で債務者が行った判断、例えば何れかの案その他の選択結果を、モジュール６０９ひいてはモジュール６０８に送る。すると、予め制定されているルールに従い、交渉、妥結、交渉／セッション打ち切り等、適当な措置が執られる。債権者や取立人が認める場合は、別の打開案が送られることもある。なお、ＲＤＢＭＳ６０４は、モジュール６１０から送られてくる処理結果、例えば取引成立、交渉／セッション打ち切り等の別に応じて更新される。
【０１０７】
図７に、例えば独立決済機関側サーバ１１４によって実行される独立決済機関側取引処理手順７００を示す。独立決済機関は、債権者を顧客として決済・支払サービスやＡＣＨ(Automated Clearing House)処理等の機能を提供する機関であり、顧客例えば銀行、与信者、取立機構等の利益を尊重しつつ資金の受取、保持、精算等を行う。図１に示したシステムでは、例えば全ての通信をインターネットを介し電子的に行うことによって、独立決済機関に開設した信託口座に資金を預託する。独立決済機関の顧客である債権者は、本システムを介してその独立決済機関に接続し、資金を扱う際にその独立決済機関が従うべき期限、条件及び手数料についてのルールを、本システムを利用して指定する。例えば、３日間が経過するまで又は債権者からの承認を受けるまで保持した後に資金を口座Ｊに移転せよとのルールが制定されている場合、その独立決済機関はそのルールに従って資金の保持及び移転を実施しなければならない。なお、前述した通り、サーバ１０２管理機関は、法令の遵守や暴利排除等の適正な要求に応えるため、債権者や取立人や決済機関の意向に関係なくルールを制定することがある。
【０１０８】
独立決済機関なら大抵は、デビットカード、マスター（商標）マネーカード、ＡＣＨ及びＥＦＴによる決済を処理することができ、顧客たる債権者又はその顧客からの指示に従い且つその利益を守りつつ決済を開始することができ、債権者の顧客から受け取った資金をその利益を守りつつ所定期間例えば３０日間預かることができ、そして、顧客から電子的手段で与えられる指令に従い、またその顧客自身が定め又はその顧客の益になるよう電子的に定められており且つ本システム上に電子的に蓄えられている諸分配ルールに従い、顧客口座に資金を分配することができる。
【０１０９】
図７中のステップ１では、債務者が自分の装置１０６を使用して支払情報、例えばＥＦＴやクレジットカードの情報を入力する。ステップ２では、入力された支払情報をサーバ１０２が受信し独立決済機関側サーバ１１４に転送する。ステップ３では、サーバ１１４が口座７０１、例えば当座預金口座、普通預金口座、貯蓄預金口座、クレジットカード口座等、対応する債務負担口座についての個人認証を求める認証要求を発行する。ステップ４では認証の成否を示す認証応答が発行される。認証失敗時はサーバ１１４はそのことを示す情報をサーバ１０２に送信し、サーバ１０２は予め定められている種々の支払拒絶時向けルールに従い所望の処理、例えば分割払いのみによる返済への変更、爾後の申し出の拒絶及びセッション打ち切り等を実行する。ステップ５では、認証の成否によらず、サーバ１０２が債務者に通信の結果を伝える。認証成功時は、ステップ６にてサーバ１１４がビン口座プロバイダ乃至商用口座プロバイダ７０２に支払要求を送り、ステップ７にてその口座プロバイダ７０２が資金を預託する。ステップ８では各利害関係者７０３に手数料を分配する。利害関係者７０３とは成立した取引に係る利害関係者、例えばサーバ１０２管理機関等のことである。ステップ９では、サーバ１０２がサーバ１１４に対し定期的に例えば週毎又は月毎に所定の支払を要求し、ステップ１０では、予め定めてある諸ルールに従い顧客口座７０４又は債権者口座７０５に資金を預託する。
【０１１０】
また、提案できる条件は金融的な条件に限られるわけではなく、上述した打開案やその一部には、無償品や無償サービスの提供、各種便宜乃至権利の提供等を申し出る種々の非金融的条件も含めることができる。こうした非金融的提案の提示もまた、妥結エンジン２０６が一種類又は複数種類のルールに従い管理する。例えば、無償品提供特約付の負債額９５％返済案を提示するというルールがある場合、１０００ドルの債務を負っている債務者には、９５０ドルの返済プラス自分の信用情報調査報告書の無償提供、という提案が提示される。債務者がそれを選択すると信用情報調査報告書が表示される。
【０１１１】
上述した図１のシステムを用いて得られる余録としては、債務者とサーバ１０２とのやりとりを通じ、またその債務者がサーバ１０２にオンライン接続している間にリアルタイムで、そのユーザの信用力得点をかなり高めることができる、ということがある。例えば、ある債務者がユーザとして本システムを用い債務履行を申し出たとする。この申し出は、図７に示した手順で受け付けられ処理される。確かにそのための資金があってそれを移動することができることが確認されると、サーバ１０２は、図１に示した債権者側サーバ１０４、信用情報調査機関側サーバ１１６又はその双方に、債務が履行されたことを報告する。サーバ１１６は、この債務履行報告を受け取ると、その債務履行という事実を考慮に入れつつ、その債務者の現在の信用力得点に基づきその債務者の信用力得点を再計算する。信用力得点の計算に際しては種々の要素が勘案されるし、また元データが同じでも信用情報調査機関が違えば信用力得点は異なる値になるが、一般的にいえば、負債を一部又は全部履行したという事実は、その債務者の信用力得点を高める有益な要素となる。信用力得点の再計算を終えたサーバ１１６は、その直後に又は暫く経過した時点で、信用力得点再計算結果をサーバ１０２に返送する。サーバ１０２は、例えば、この信用力得点を債務者宛に送りその債務者の装置１０６に表示させる。また、債務を履行すると信用力得点がどのように変化するかが解っていれば、サーバ１０２にて、返済額及び返済条件（即時返済、割賦等）に基づきその債務者の信用力得点の暫定値を計算することもできる。例えば、信用履歴（クレジットヒストリ）をくまなく調べたところ、滞納が数回だけで破産も５年前に１回だけであり、その債務者の信用力得点が６１２である場合は、懸案となっている２０００ドルの債務を返済することで、その債務者の信用力得点は高まるであろう。また、例えばある債務者が抱えている負債の合計が２００００〜３００００ドル、信用力得点が６１０〜６２０であり、その負債を履行するとその債務者の信用力得点が４ポイント上昇する場合、サーバ１０２や信用情報調査機関側サーバ１１６では、その債務者の信用力得点を６１６に高めると決定する（高まる見込みであると判断する）ことができる。
【０１１２】
図９に、本発明の実施形態例えば図１及び図２に示した実施形態における債権者又は取立人側処理手順の概略を示す。図中、ステップ９０１ではサーバ１０２に債権者又は取立人の口座を開設し、その債権者についての一般情報をデフォルト設定する。ステップ９０２ではその債権者又は取立人向けに取引成立条件を調整する。これは、例えばその取引成立条件を機関に口頭で伝えサーバ１０２向けの記述例えばＡＰＸやスクリプトに変換させることによって、或いはその他の適当な手段によって行う。ステップ９０３では、サーバ１０２に貸付資産オートフォリオをアップロードする。これは、例えば債権者側サーバ１０４から通信媒体１０８を介して行う。アップロードするポートフォリオには、全ての債権及びその識別情報を登録しておく。債権情報としては、例えば債務者の氏名、口座番号、債務額、債務発生日等を登録する。ステップ９０４では、債務者のアドレスを同じくサーバ１０４からサーバ１０２へとアップロードする。ステップ９０５では、これは必須ではないが、既存の格付システムを用いてその貸付資産に格付けする。例えば、ある種の適格指標に基づきＡ、Ｂ、Ｃ、Ｄ等のグレード文字を付すことによってその貸付資産に格付けする。一番高い格は例えばＡとする。文字による格付に代え、数字による格付（例えば１が高リスク、２が中リスク、３が低リスクという格付）等、他の方法による格付を行ってもよい。こうした格付は、打開案を生成するための諸ルールで使用できる。例えば、高リスクの貸付資産については年利１２％といった最高金利での返済しか認めないが、低リスクの貸付資産については年利８％といった最低金利での返済を認める、という具合である。また、これらの格付は任意に変更できる。ステップ９０６では、郵便、電子メール、テキストメッセージ、録音音声による電話その他の手段で債務者と通信することにより、債務者との接触を開始し図１のシステムを用いた取引解決を開始させる。なお、債務者アドレスは定期的に更新するのが望ましく、貸付資産格付も適宜やり直すのが望ましい。書信送付は、債権者又は取立人、サーバ１０２管理機関等、適切な又は権限のある機関が行うようにするとよい。
【０１１３】
図１０に債務者側処理手順の概略を示す。図中のステップ１００１では、サーバ１０２のウェブサイトを記した書信その他の通信を、債務者が受領する。大抵の場合、この通信では債務又は債権者が指定乃至特定されている。また、大抵の場合、この通信によって、サーバ１０２のウェブサイトが知っており且つそれを用いることでそのウェブサイトの利用が可能になるキーワード、パスワード乃至コードが伝達される。ステップ１００２では、債務者が、自分に与えられたキーワード、パスワード等、適切なコードを用いてそのウェブサイトにログインする。また、状況及び地域によっては、債権者、取立人又はサーバ１０２管理機関等の機関が債務者の信用情報調査報告書を入手することを、債務者たる個人又は機関が承認する必要がある。そうした場合には、オプションとして示されているステップ１００３にて信用情報調査報告書を取得する際に、その信用情報調査報告書を入手しようとしている機関が、確かにその債務者のためにその債務者の信用情報調査報告書を入手する権限のある機関であることを、その債務者が認証するようにする。債務者が信用情報調査報告書の入手を認めていない場合や何らかの理由で信用情報調査報告書を利用できないこともあり得るので、そうした場合には全く打開案を提示しない、或いはかなり限られた打開案例えば懸案債務の全額返済案だけを提示する、というルールを、定めておくとよい。そうしたルールを定めるのは債権者又は取立人或いはサーバ１０２管理機関である。債務者は、状況に応じ長短の差はあるがある程度の時間が経過した後に、ステップ１００４で打開案を受信して看取し、ステップ１００５でその中で最良の案を選択し、ステップ１００６で債務を履行する。債務者が利用できるオプションとして示されているステップ１００７では、債務者は自分の信用情報調査報告書を購入その他の手段により閲覧することができ、また申し込めば状況次第で自分の信用力得点を閲覧することができる。
【０１１４】
ここで、本システムにアクセスする機関に対して提示され又はその機関の利用に供される各種画面について、その概観を図１１〜図２２のスクリーンショットにより示しつつ説明する。なお、これらのスクリーンショットは本発明の概観を示すためのものであり、本発明の趣旨を限定するためのものではないので、それらと異なる概観、情報及びレイアウトによる画面を提示するものも本発明に含まれうる。
【０１１５】
図１１のインターネットブラウザ画面には、ある信用情報調査機関について取得対象項目が表示されている。例示されている信用情報調査機関マッピング画面１１０１は、概略、信用情報調査機関側サーバ１１６からの信用情報調査報告書入手方法を対信用情報調査機関モジュール２０２に指示する機能、即ち信用情報調査機関マッピング機能を実現するための画面であり、その上部には「Bureau Name」（信用情報調査機関名称）、「Type of the Report」（信用情報調査報告書種別）、「Extract List」（抽出リスト）等が、またその右半分には、取得した信用情報調査報告書から抽出すべき諸項目例えば「Number of Negative Trades」（取引失敗回数）、「Number of Trades」（取引回数）、「High Credits」（高額貸付）等を列記したリストが、それぞれ表示されている。オペレータは、この画面の左半分に示されているフィールドのうち選択可能なものの中から、モジュール２０２を用いて入手したい項目、とりわけそのモジュール２０２と解析モジュール２０４とによって解析させたい項目に係るフィールドを、選択、指定することができる。また、信用情報調査報告書から所望の情報を抽出するには、その債権者向けのスキーマ即ち共通の語彙に従い諸ルールを記述し、それらのルールをマシンに実行させればよい。
【０１１６】
図１２のインターネットブラウザ画面には、特定の債権者又は取立人向けに一般的妥結条件が表示されている。例示されている妥結条件画面１２０１には、機関名称即ち債権者又は取立人の名称の他、「87% Settlement」（８７％返済）、「90% Settlement」（９０％返済）といった様々なレベルのルールが表示されており、８７％返済については「Offer Variables」（提案変数）である「Expiration(days)」（返済日数）が３０日に、９０％返済については２５日に、それぞれ設定されている。８７％返済についての「Guidelines」（ガイドライン）は「債務残高５００．００ドル以上」となっているので、その債権者が抱える債務残高の最新額が５００．００ドル以上であるなら３０日以内８７％返済が提案される。また、その債権者が抱える累積利息が１０００．００ドル以上であるなら２５日以内８７％返済が、また不良債権償却額が５０００．００ドル以上であるなら８０％返済が、あるガイドラインの下に提案される。これらの提案及びガイドライン１２０２については、債権者又は取立人その他の機関の望み次第で、入替、条件追加、削除、変更等を施すことが可能である。発効日及び満了日を表示させることもできる。また、辞書に言葉を追加するという選択肢を画面１２０１上に表示させてもよい。
【０１１７】
図１３の画面には妥結用辞書が表示されている。例示されている妥結用辞書画面１３０１には、返済条件項目を生成及び編集しＸＭＬタグ等のタグを割り当てソースデータにマッチさせる選択肢１３０２も、表示されている。この妥結用辞書画面１３０１は特定の債権者及びその辞書「Debt」についての画面であり、表示されている種々の返済条件項目の中には、「Account Status」（口座現況）、「Accrual Interest」（累積利息）、「Age」（経年）等のエントリが含まれている。これらのエントリは用語として辞書に登録されており、信用情報調査報告書エントリその他のデータベースエントリとマッチさせることができる。また、１３０２の部分には例えばＸＭＬ書式によって項目名乃至タグやそのタイプが表示されており、１３０３の部分には、項目名例えば「Age」と、それを生成するための式、例えば「Current Date」（今日の日付）から「Debt Date」（貸付日）を減ずる式が、表示されている。
【０１１８】
図１４の画面には、ある貸付資産についての回収状況を報告するための一般報告書式が表示されている。この画面中、１４０１の部分には、日付、時刻、貸付資産登録口数、貸付総額、完済口数、登録口数に対する完済口数の比率、既返済額、貸付総額に対する既返済額の比率、返済要請額、貸付総額に対する返済要請額の比率、既返済額に対する返済要請額の比率、実返済額、返済要請額に対する実返済額の比率が表示されている。なお、こうした報告書は様々な書式で作成することができる。
【０１１９】
図１５の画面には、打開案生成のため債権者に提示されるブランク書式が表示されている。この書式中、ブランクになっている複数個のフィールドは、打開案データによって埋めるフィールドである。この書式に入力するのは、「Account」（口座番号）、「Status」（口座現況）、「Name」（名称）、「Original Creditor」（原債権者名）、「Principal Balance」（元本残高）、「Current Balance」（現残高）、更には一組の「Available Settlements」（提示できる案）、債務者からの「Proposals」（依頼）及び「Counter Offer」（対案）を入力することができる。この図のスクリーンショットは、債務者に対する打開案をダイナミックに作成したいと債権者が望む場合に、その債権者に提示するようにしてもよい。また、この画面上には、編集可能なフィールドが４個と計算値によって埋められるフィールドが２個表示されているので、債権者又は取立人は、自分の面前にこの図の画面を表示させることで、債務の詳細や最新の交渉状況を知ることができるだけでなく、債務割引額、返済日、適用金利、最終返済日等を入力することもできる。この画面で入力された情報はサーバ１０２によって受信され、債務者側装置１０６を介し債務者に提示される。この画面に表示されている二種類の選択肢、即ち「Calculate」（計算）という選択肢と「Submit Debtor」（債務者に提示）という選択肢のうち、「Calculate」を選択すると入力された期日及び金利に基づき月利や総既返済額が計算され、「Submit Debtor」を選択すると債権者又は取立人による提案がサーバ１０２を介して債務者に送信される。なお、債権者又は取立人側の案がその債権者又は取立人向けの諸ルールに違背している場合、例えば状況から見て適用金利が低すぎる場合等には、サーバ１０２からその債権者又は取立人に対して警告が発せられる。また、前述の通り、図１５に示した如きインタフェースを介し自然人が提出した打開案によって他の諸ルールがオーバライドされるように、打開案生成の元になる一組のルールのうち１個を定めることができる。
【０１２０】
図１６の画面には資産マネージャ及びＯｒｇＵｎｉｔの概念が表示されている。この図中の「TestMaster」は、「First Performance」の下位ＯｒｇＵｎｉｔである「Test Region」の貸付資産オートフォリオである。「Test Master」の下位には種々の「Settlement Dictionaries」（妥結用辞書）と「Portfolios」（貸付資産ポートフォリオ）とがあり、その右側には、「OrgUnit」（ＯｒｇＵｎｉｔ名）、「Portfolio Name」（ポートフォリオ名）、「Number of Accts」（債務口数）、「Assigned Total」（譲受口数）、「Adjusted Total」（調整口数）、「Number Settled」（完済口数）、「Assigned Settled」（授受完済口数）及び「Payments Received」（受領返済額）を表示乃至入力する欄がある。この資産マネージャのユーザは、従って、貸付資産ポートフォリオの新規作成や既存の貸付資産ポートフォリオの修正等を行うことができる。なお、前述の通り、下位ＯｒｇＵｎｉｔはその上位ＯｒｇＵｎｉｔの特性（プロパティ）を引き継いでいる。図１７の貸付資産用ルールマネージャ画面に表示されているように、本システムにおいては、貸付資産ポートフォリオに望み通りにルールを追加することができる。この図の例では、そのＯｒｇＵｎｉｔ名が「Test Region」、ポートフォリオ名が「Test Master」の貸付資産について債務解消又は債権移転のための諸ルール、例えば本貸付資産について年利８％未満の金利を提案してはならない、本貸付資産は１ドル当たり５０セント以上の対価を提示した機関になら売却してよい、といったルールを生成することができる。
【０１２１】
図１８の画面には、子貸付資産の概念が表示されている。この図に示すように、各貸付資産（親貸付資産）の下位に別の貸付資産（子貸付資産）を、何個か追加することができる。具体的には、この画面に表示されている貸付資産のうちの「FPGroup2」、「FPGroup22」及び「FPGroup3」が、貸付資産「Test Master」の子貸付資産に該当する貸付資産である。子貸付資産は自分の親貸付資産の属性及びルールを引き継ぐ。また、子貸付資産について、親貸付資産の属性及びルールとは異なる属性及びルールや親貸付資産の属性及びルールにない属性及びルールを、設けることができる。こうした子貸付資産ポートフォリオを生成することによって、貸付資産をカテゴリ分類することや、貸付資産の構成部分毎に数値評価することが可能になる他、その貸付資産が債務履行上のどの段階に位置しているかについてより好適な描像を得ることができる。また、図１９に、その貸付資産用の辞書をインポートするための辞書マネージャ画面を示す。この例示画面上で使用可能とされている辞書は「30 Days」、「60 Days」及び「90 Days」の三種類ある。各辞書の名称の冒頭に付されている数字は日数、例えばその貸付資産に属する債務の滞納日数を表している。滞納日数としては、最大滞納日数、最小滞納日数、平均滞納日数等、どのような滞納日数を用いてもよい。例えば、３０日を超えて履行が滞っている債務に対しては辞書「30 Days」を適用する、といった具合である。また、例えば辞書「30 Days」を適用することによって、例えば辞書「90 Days」を適用した場合には適用されない独特な選択肢やルールが適用されるようにすることができる。また、この図には「Import Dictionary」（インポート辞書）及び「Target Dictionaries」（ターゲット辞書）の概念も示されている。インポート辞書とは、他のＯｒｇＵｎｉｔ又は外部からインポートされる辞書のことであり、ターゲット辞書とは、潜在的にその貸付資産に対し適用可能で且つその貸付資産だけに適用される辞書のことである。
【０１２２】
図２０に、辞書選択結果及びその辞書の属性を示す。この例では、辞書として「Import Dictionary」が選択されており、またその辞書が７個の「Accounts」（アカウント）によって共有され且つその貸付資産だけで使用される（「Exclusive」（エクスクルーシブ）にする）旨、表示されている。エクスクルーシブに設定してある辞書は、その体裁を変更することができるが、その変更は他の６アカウントには適用されない。
【０１２３】
図２１に、債務者が閲覧可能な画面２１０１のスクリーンショットを示す。この画面上には、「Name」（債務者名）の他、「Creditor」（債権者名）、「Reference Number」（参照番号）、「Purchase Date」（購入日）、「Principal」（負債元本）、並びに「Contact Information」（コンタクト情報（「Save Changes」選択肢即ち情報更新選択肢付き）が表示されており、更に特記すべきことには、債務履行方法に関する２個の選択肢が表示されている。また、この画面上では「Balance Due」（要精算額）が１１５３．８５ドルであると表示されており、債務履行のための打開案として、７８４．６２ドルを一括返済する、という第１案と、手付けとして２３０．７７ドルを返済し１２ヶ月に亘り金利１０％で８１．１５ドルを毎月返済する、という第２案が表示されている。「Expiration Date」（提案有効期限乃至即時返済期限）は、第１案については４／２１／０４に設定されており、第２案については４／６／０４に設定されている。債務者は、この打開案に盛り込まれている何れかの案を受け入れることもできるし、自分から対案を提出して検討を求めるという選択肢を、選択することもできる。なお、前述した通り、債務者が自分の案を提示できる選択肢は、債権者又は取立人向けの諸ルールや債務者及び解決対象取引次第で、設けられることもあるし設けられないこともある。
【０１２４】
図２２に、妥結条件画面の他の例のスクリーンショットを示す。この図には、互いに別々のルール群である提案変数及びガイドラインが示されている。示されている提案は「90% Settlement」（９０％解決）２２０１の一種類だけである。この例で示されている条件２２０２は、債務者が「Employed」（雇員）であれば「Value」を１０に等しく設定し、返済額を９０％に引き下げる即ち９０％解決にするという条件である。ガイドラインでは「Collection Days」（回収日数）を３０日未満に定めているので、債務額の９０％を３０日以内に回収しなければならない。また、この例における９０％解決提案の有効期限は７日である。その「Effective Date」（発効日）及び「Cancel Date」（取消日）も表示されている。債権者やサーバ１０２管理機関は、この例に係る画面が提示されたとき、種々の条件の入力、変更等を望み通りに行うことができる。
【０１２５】
取引成立促進手続の別例
以上、特に債務履行に係る取引の解決に適用した例を以て本発明の概略を説明したが、本発明の対象は債務履行取引解決等に限定されるものではない。即ち、本発明に係るシステムは、一般に、様々なルール、スキーマ、辞書、モジュール、サーバ及びコンポーネントを用いた取引解決促進全般に適用可能である。
【０１２６】
本発明に係るシステム及びその基本的方法論は、例えば慈善寄進募集に利用できる。そうした用途では、寄進者についての一般的情報を様々な情報源から取得するのが望ましい。但し、信用情報調査報告書については、その入手が意味をなすこともあるしなさないこともある。また、寄進者（の一部）に対しては、前述のシステムと同様、ウェブサイトアドレスや識別番号例えば寄進者番号を伝えるようにする。そうした寄進者は、程度の差こそあれ様々な団体に対する何らかの寄進履歴を有しているはずであるので、そのプロファイルも利用できるであろう。
【０１２７】
大まかには、寄進者は、自分の装置１０６を用い、慈善団体又はその連合体が管理しているウェブサイトにアクセスし、サーバ１０２にログインする必要がある。サーバ１０２は、寄進者たるユーザについての情報が蓄えられているアカウント交信データベース１１８に依拠して、或いは可能ならば他の情報源から寄進者についての情報を取得して稼働する。使用できる他の情報源としては、例えば信用情報調査機関、個人情報データベース、インターネット上のその他の情報源等、個人プロファイルを補強できる種々の情報源がある。寄進者がサーバ１０２からの質問、例えば収入レベル、現在の自宅住所、現在の勤務先住所、現在の職務上の役職等を訊ねる質問に対し回答すると、サーバ１０２は、上述した通り各種のルールを適用して様々な案を導出し、ワンタイムギフトや決済方法についての選択肢を含む案を提示する。提示する各案には、例えば無料サービスの申し出を付しておくとよい。例えば、素性不明な寄進者や、収入レベルを明らかにするのを拒む等十分な情報を含む回答をよこさなかった寄進者には、予め定められている額の寄進額、例えば２５ドル一括、５０ドル一括、１００ドル一括、２５０ドル一括、５００ドル一括、月額２５ドル１年割賦、月額５０ドル１年割賦等の寄進方法選択肢を提示する。これに対して、何らかの情報が得られている寄進者には別の案を示す。例えば、年収が１５００００ドルを上回っており、自団体への過去１年間の寄進額が１０００ドルを上回っており、他の慈善団体への過去１年間の寄進額が１０００ドルを上回っていることが解っている寄進者には、そのことを以て発動する別のルールを適用する。また例えば、過去１年間の寄進額が５００ドル超２０００ドル未満であり、１０００００ドルを超える安定年収がある寄進者ユーザに対しては、サーバ１０２は、５００ドル一括、１０００ドル一括、２０００ドル一括及び５０００ドル一括という四種類の寄進額選択肢と共に、それらのうち何れかの選択肢を選択頂ければ貴方に銅賞、銀賞、金賞及びプラチナ賞（同順）という寄進者賞を授与しお名前を慈善団体年報に掲載します、という案を提示する。寄進者は、こうした提案を受け何れかの選択肢を選択してもよいし、寄進者から別の情報を入力できる別の選択肢が提示されている場合は、そうした選択肢を選択してもよい。例えば、１５００ドルきっかりを寄進したい寄進者は、その選択肢を選択して１５００ドル寄進の意志を明示入力すればよい。また、１２ヶ月に亘り毎月１５０ドルを寄進したい寄進者は、その選択肢を選択してその旨の入力をすればよい。そうした対案に対しては更に別のルールが適用されることとなるが、大抵は寄進者が申し出た寄進条件が受け入れられることになり、それでこの取引は成立する。資金移動の手順は、前述の例における債権者の立場に慈善団体が据わることを除けば、前述の手順と同じである。また、図２に例示したモジュールのうち幾つかは、ここで述べている例では不要になり或いはその機能が変わる。例えば、信用情報調査機関に接触せずアカウント交信データベース１１８その他の慈善団体関連データベースに接触する手順を採る場合、対信用情報調査機関モジュール２０２及び解析モジュール２０４は、求められている情報を信用情報調査機関ではなく慈善団体関連データベースから探索し、それによって得られた情報を解析する。更に、ここに述べている例では資産マネージャ２２０は寄金マネージャとして動作し、寄進された資金を所定のルールに従い適切な受益者に分配する。
【０１２８】
本発明を適用できる別の例として、保険金請求交渉の解決がある。その場合、本発明の実施形態に係るシステムのユーザとなるのは、保険金を請求する権利を有し又は保険金を請求した自然人若しくは機関又はその正当な代理人である。ここではその何れかに該当する者のことを請求者と呼ぶ。この例では、まず請求者たるユーザがサーバ１０２にログインすると、そのサーバ１０２が例えば信用情報調査機関側サーバ１１６やアカウント交信データベース１１８その他の外部データベース乃至情報源に接続される。この例の場合、データベース１１８には、請求者に提示したことがある打開案、法務情報源から取得した請求者関連金融情報、訴訟や事故の深刻さの程度等、様々な関連情報が蓄えられている。サーバ１０２は、それらから得られる情報や、類似する保険金請求交渉に対する保険金支払の履歴（データベース１１８に蓄えられているもの）に基づき、また保険業者が定めた諸ルールに従い、保険金支払に関する打開案を生成する。例えば、自動車事故によって身寄りのない５８歳の人物が死亡した事案の場合、請求者に対しては、５０００００ドル一括払い、各年３００００ドル２０年払い、各年２５０００ドル３０年払い等の案が提示される。保険業者が制定したルールによって請求者からの対案提示が認められている場合、その請求者は、保険業者側の案を受け入れることもまた自分から対案を提示することもできる。なお、保険金請求交渉の解決に本発明を適用する例では、ＥＴＦ、クレジットカード払い等による決済については特に考慮する必要はないので、所定ルールに従い取引が成立し合意が形成された後、権限のある債権者の承認を得た上で、独立利害関係者又は債権者による支払を行えばよい。保険金請求が認められた事実等、保険金支払に関する情報や、保険金請求台帳（ポートフォリオ）及び報告書は、必要に応じとりまとめるようにする。
【０１２９】
本発明を利用すれば、上述のもの以外の取引の成立促進も実現できる。
【０１３０】
以上、改良型の取引成立促進システム及び方法について説明を行った。当該システム及び方法は、実質的に或いは完全に、インターネットをベースとして実施することができる。従って、ユーザは、インターネットをブラウズする機能を有するプラットフォーム等を用い取引成立促進用サーバにアクセスすることにより、その取引の成立例えば債務の解消を図ることができる。
【０１３１】
また、本発明の本質的思想は、実施形態についての以上の説明から十分にくみ取ることができる。従って、従来からある知識を適用することによって、本発明の本質的思想の範囲内で、上述したシステム及び方法を様々な用途向けに変形し又は適合させることができる。即ち、そうした変形乃至適合措置が施された構成は、文理上本発明の技術的範囲内のものとなり、或いは本発明の実施形態の均等物になる。そして、本願にて説明に使用している用語法及び表現法によって、本発明の要旨が限定を受けるものではない。
【図面の簡単な説明】
【０１３２】
【図１】本発明の一実施形態に係る取引成立促進用コンピュータシステムを示す図である。
【図２】本システムにてサーバ上で稼働するソフトウェアモジュールの論理関係図である。
【図３Ａ】本システムにおける取立処理手順を示す図である。
【図３Ｂ】その変形例を示す図である。
【図４】本システムのうちの対債務者部分、特にそれをＭｉｃｒｏｓｏｆｔ（登録商標）プラットフォーム上で実施した場合のアーキテクチャを示す図である。
【図５】本システムのうちの対債権者部分のアーキテクチャを示す図である。
【図６】本システムの動作の変形例を示す図である。
【図７】独立決済機関側サーバとの通信手順を例示する図である。
【図８】スキーマに従いソースデータを辞書にマッピングする方法を例示する概念図である。
【図９】本システムにおける債権者又は取立人側処理手順の概略を示す図である。
【図１０】本システムにおける債務者側処理手順の概略を示す図である。
【図１１】インターネットブラウザ画面、特にある信用情報調査機関から取得したい情報の項目を表示している画面のスクリーンショットを示す図である。
【図１２】ある特定債権者又は取立人向けに一般的妥結条件を表示している画面のスクリーンショットを示す図である。
【図１３】返済条件項目を生成及び編集しＸＭＬタグ等のタグを割り当てソースデータにマッチさせる選択肢が表示されている妥結用辞書画面のスクリーンショットを示す図である。
【図１４】ある貸付資産について回収状況を報告するための一般報告書式画面のスクリーンショットを示す図である。
【図１５】打開案データで埋めるべき複数個のフィールドをブランクの状態で債権者に提示している打開案生成用一般書式画面のスクリーンショットを示す図である。
【図１６】本システムにより生成された資産マネージャ画面のスクリーンショット、特にＯｒｇＵｎｉｔ概念を示す図である。
【図１７】資産マネージャ画面のスクリーンショット、特にその上の貸付資産用ルールマネージャを示す図である。
【図１８】資産マネージャ画面のスクリーンショット、特に子資産概念を示す図である。
【図１９】資産マネージャ画面のスクリーンショット、特に辞書マネージャを示す図である。
【図２０】資産マネージャ画面のスクリーンショット、特に辞書選択結果及びその辞書の属性を示す図である。
【図２１】債務者（ユーザ）に示される画面のスクリーンショットを示す図である。
【図２２】妥結条件画面の他の例のスクリーンショット、特に示された打開案に代わる案を債務者が作成できる選択肢が表示されたものを示す図である。
【図１】
2008517405.tif 000003
【図２】
2008517405.tif 000004
【図３Ａ】
2008517405.tif 000005
【図３Ｂ】
2008517405.tif 000006
【図４】
2008517405.tif 000007
【図５】
2008517405.tif 000008
【図６】
2008517405.tif 000009
【図７】
2008517405.tif 000010
【図８】
2008517405.tif 000011
【図９】
2008517405.tif 000012
【図１０】
2008517405.tif 000013
【図１１】
2008517405.tif 000014
【図１２】
2008517405.tif 000015
【図１３】
2008517405.tif 000016
【図１４】
2008517405.tif 000017
【図１５】
2008517405.tif 000018
【図１６】
2008517405.tif 000019
【図１７】
2008517405.tif 000020
【図１８】
2008517405.tif 000021
【図１９】
2008517405.tif 000022
【図２０】
2008517405.tif 000023
【図２１】
2008517405.tif 000024
【図２２】
2008517405.tif 000025
【手続補正書】
【提出日】平成19年6月20日(2007.6.20)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ユーザとサーバとの間でネットワーク通信を確立するステップと、
ユーザが携わっている取引に関連する情報をサーバにて受信するステップと、
ユーザにもサーバにも帰属していない少なくとも１個の情報源から上記取引に関連する利用可能な情報を探すステップと、
上記取引の相対当事者側に益があるよう制定されているルールに従いサーバ上でルールベースエンジンを稼働させることによって、上記利用可能情報に含まれる情報を処理するステップと、
ルールベースエンジンが下した少なくとも１個の決定に従いユーザに対し少なくとも１個の打開案を示すステップと、
を有し、上記取引を成立に導く方法。
【請求項２】
請求項１記載の方法であって、上記取引が債務の履行であり、ユーザがその債務を負う債務者である方法。
【請求項３】
請求項２記載の方法であって、上記利用可能情報が、ユーザたる債務者についての信用情報調査報告書を含む方法。
【請求項４】
請求項３記載の方法であって、ルールベースエンジンが、上記債務に対し正当権限を有する金融機関が制定したルールに従う方法。
【請求項５】
請求項１記載の方法であって、ルールベースエンジンが、少なくとも１個の辞書を利用し、受け取った情報をサーバ向けの情報に翻訳する方法。
【請求項６】
請求項１記載の方法であって、打開案のうち少なくとも１個が、上記取引に対し正当な利害関係を有する金融機関が制定したルールに従い立てた案である方法。
【請求項７】
請求項１記載の方法であって、示されたどの打開案とも異なる案をユーザが随時提示するステップを有する方法。
【請求項８】
請求項１記載の方法であって、上記利用可能情報に含まれる情報を処理する際に、金融に関する当該利用可能情報を解析し打開案生成に必要な情報だけを取り出す方法。
【請求項９】
請求項８記載の方法であって、打開案を示すに当たり、サーバと通信して債務履行を図るようユーザに督促する方法。
【請求項１０】
請求項１記載の方法であって、ルールベースエンジンが、ユーザがその取引を上首尾に成立させる可能性を検討するルールに従う方法。
【請求項１１】
請求項７記載の方法であって、先に示したどの打開案とも異なる別の打開案を示すステップを有する方法。
【請求項１２】
請求項１１記載の方法であって、所定の解決ルールに従い上記別の打開案に対する賛否を決するステップを有する方法。
【請求項１３】
請求項１記載の方法であって、ユーザに示す少なくとも１個の打開案に係る少なくとも１個の決済選択肢を、そのユーザに示すステップを有する方法。
【請求項１４】
請求項１３記載の方法であって、決済選択肢として、割引額を直ちに支払う選択肢、一定額に分けて定期的に支払う選択肢又はその双方を示す方法。
【請求項１５】
ユーザとサーバとの間でネットワーク通信を確立するステップと、
ユーザからもサーバからも独立している情報源からそのユーザが携わっている金融取引に関連する利用可能な情報を探索し、該当する情報があればその利用可能情報をサーバにて受信するステップと、
上記金融取引の相対当事者側に益があるよう制定されているルールに従いサーバが上記利用可能情報を処理するステップと、
上記ルールに従い下された少なくとも１個の決定に従いユーザに対し少なくとも１個の打開案を示すステップと、
を有し、上記金融取引を成立に導く方法。
【請求項１６】
請求項１５記載の方法であって、上記金融取引が債務の履行であり、ユーザがその債務を負う債務者である方法。
【請求項１７】
請求項１６記載の方法であって、上記利用可能情報がユーザたる債務者についての信用情報調査報告書を含む方法。
【請求項１８】
請求項１５記載の方法であって、示されたどの打開案とも異なる案をユーザが随時提示するステップを有する方法。
【請求項１９】
請求項１５記載の方法であって、上記利用可能情報を処理する際に、その利用可能情報を解析して打開案生成に必要な情報だけを取り出す方法。
【請求項２０】
債務者とサーバとの間でネットワーク通信を確立するステップと、
債務者についての信用情報調査報告書を探索し、利用可能な信用情報調査報告書があればそれをサーバが取得するステップと、
債権者が制定したルールに従い信用情報調査報告書をサーバにて処理するステップと、
上記ルールに従い下された少なくとも１個の決定に従い債務者に対し債務履行のための打開案を示すステップと、
を有し、債務者が抱える債務を解消に導く方法。
【請求項２１】
ユーザからの通信を受信し、そのユーザにも自分にも帰属していない少なくとも１個の情報源から、そのユーザが携わっている取引に関連する利用可能な情報を探索するサーバを備え、
サーバの構成要素であるルールベースエンジンが、上記取引の相対当事者側に益があるよう制定されているルールに従い上記利用可能情報に含まれる情報を処理し、それによって下した少なくとも１個の決定に従いユーザに対し少なくとも１個の打開案を示すシステム。
【請求項２２】
請求項２１記載のシステムであって、サーバが、上記利用可能情報を取得し上記ルールに基づき解析する解析モジュールを有するシステム。
【請求項２３】
請求項２１記載のシステムであって、サーバが、複数のユーザが執った措置及び資産の内訳に応じ、複数の取引を含む資産を管理する資産管理モジュールを備えるシステム。
【請求項２４】
請求項２１記載のシステムであって、上記取引が債務の履行であり、ユーザがその債務を負う債務者であるシステム。
【請求項２５】
請求項２４記載のシステムであって、上記利用可能情報が、ユーザたる債務者についての信用情報調査報告書を含むシステム。
【請求項２６】
請求項２５記載のシステムであって、ルールベースエンジンが、上記債務に対し正当な権限を有する金融機関が制定したルールに従うシステム。
【請求項２７】
請求項２１記載のシステムであって、ルールベースエンジンが、取得した情報を、少なくとも１個の辞書を利用しサーバ向けの情報に翻訳するシステム。
【請求項２８】
請求項２１記載のシステムであって、打開案のうち少なくとも１個を上記ルールに従い立てるシステム。
【請求項２９】
請求項２８記載のシステムであって、サーバが、先に示したどの打開案とも異なる案の提示を上記ユーザから受けるシステム。
【請求項３０】
請求項２１記載のシステムであって、サーバが、打開案を示すに当たり、本サーバと通信して取引解決を図るようとユーザに督促するシステム。
【請求項３１】
請求項２１記載のシステムであって、ルールベースエンジンが、ユーザがその取引を上首尾に成立させる可能性を検討するルールを含むシステム。
【請求項３２】
請求項２９記載のシステムであって、先に示したどの打開案とも異なる別の打開案を示す手段を備えるシステム。
【請求項３３】
請求項２１記載のシステムであって、サーバが、先に示した少なくとも１個の打開案に係る少なくとも１個の決済選択肢をユーザに示す決済処理モジュールを有するシステム。
【請求項３４】
ユーザからも自分からも独立している情報源からそのユーザが抱える当該金融取引に関連する利用可能な情報を探し、該当する情報があればその情報を取得するサーバを備え、
サーバの構成要素であるルールベースエンジンが、上記金融取引の相対当事者側に益があるよう制定されているルールに従い上記利用可能情報を処理し、
サーバが、上記ルールに従いルールベースエンジンが下した少なくとも１個の決定に従いユーザに対し少なくとも１個の打開案を示すシステム。
【請求項３５】
請求項３４記載のシステムであって、サーバが、上記利用可能情報を取得し上記ルールに従い解析する解析モジュールを有するシステム。
【請求項３６】
請求項３５記載のシステムであって、サーバが、複数のユーザが執った措置及び資産の内訳に応じ、複数の取引を含む資産を管理する資産管理モジュールを有するシステム。
【請求項３７】
請求項３４記載のシステムであって、上記金融取引が債務の履行であり、ユーザがその債務を負う債務者であるシステム。
【請求項３８】
請求項３７記載のシステムであって、上記利用可能情報が、ユーザたる債務者についての信用情報調査報告書を含むシステム。
【請求項３９】
請求項３８記載のシステムであって、先に示されたどの打開案とも異なる案をユーザが随時提示できるようにする手段を備えるシステム。
【請求項４０】
債務者との接触を確立してその債務者から情報を受け取り、更にその債務者についての信用情報調査報告書を探索するサーバを備え、
サーバの構成要素であるルールベースエンジンが、その信用情報調査報告書の少なくとも一部分及びユーザが抱える債務に関連する他の情報を含む情報を取得し、債権者が制定したルールに従いそれらの情報を処理するよう構成されており、
サーバが、上記ルールに従い下された少なくとも１個の決定に従い債務者に対し債務履行のための打開案を示すシステム。
【請求項４１】
ユーザについての個人情報、ユーザ口座についての口座情報、マクロ経済についての情報及び取引についての情報のうち少なくとも一種類の情報を、その取引に携わっているユーザからも自分からも独立している情報源のみから、探索するサーバを備え、
この探索によって収集した情報を、上記取引を成立に導くための少なくとも１個の打開案の生成に供するシステム。
【国際調査報告】
2008517405.tif 000026