IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 許 家▲いえ▼の特許一覧

<>
  • 特許-債務返済システム及び債務管理方法 図1
  • 特許-債務返済システム及び債務管理方法 図2
  • 特許-債務返済システム及び債務管理方法 図3
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-01-12
(45)【発行日】2022-01-25
(54)【発明の名称】債務返済システム及び債務管理方法
(51)【国際特許分類】
   G06Q 40/02 20120101AFI20220118BHJP
【FI】
G06Q40/02
【請求項の数】 10
【外国語出願】
(21)【出願番号】P 2019225923
(22)【出願日】2019-12-13
(65)【公開番号】P2020173777
(43)【公開日】2020-10-22
【審査請求日】2019-12-13
(31)【優先権主張番号】108112359
(32)【優先日】2019-04-09
(33)【優先権主張国・地域又は機関】TW
(73)【特許権者】
【識別番号】519242034
【氏名又は名称】許 家▲いえ▼
(74)【代理人】
【識別番号】100081961
【弁理士】
【氏名又は名称】木内 光春
(74)【代理人】
【識別番号】100112564
【弁理士】
【氏名又は名称】大熊 考一
(74)【代理人】
【識別番号】100163500
【弁理士】
【氏名又は名称】片桐 貞典
(74)【代理人】
【識別番号】230115598
【弁護士】
【氏名又は名称】木内 加奈子
(72)【発明者】
【氏名】許 家▲いえ▼
【審査官】鈴木 和樹
(56)【参考文献】
【文献】特開2017-182284(JP,A)
【文献】特開2002-041780(JP,A)
【文献】特開2017-049717(JP,A)
【文献】特開2005-182560(JP,A)
【文献】特開2016-151919(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
(57)【特許請求の範囲】
【請求項1】
返済アカウントを記録するアカウント管理サーバと、
複数の貸付銀行の合計債務を2段階で返済する返済額を決定する返済額分配サーバと、
を備え、
前記返済額分配サーバは、
第1段階と第2段階の返済額を計算する返済額計算モジュールと、
複数の銀行が有する債権額の比率に応じて返済額を貸付銀行の前記返済アカウントに分配して転送するよう、前記アカウント管理サーバに通知する債務配分モジュールと、
を有し、
前記返済額計算モジュールは、
前記第1段階の返済額として、前記合計債務の元金は含まずに特定の時区間での利子を精算期間ごとに返済する返済額を計算し、
前記第2段階の返済額として、前記合計債務の元金と特定の時区間での利子を精算期間ごとに返済する返済額を計算する、
債務返済システム。
【請求項2】
前記返済額分配サーバは、前記第1段階の返済額又は前記第2段階の返済額を顧客端末に通知する返済額通知モジュールを更に有すること、
請求項1の債務返済システム。
【請求項3】
前記貸付銀行によって設立される貸付銀行サーバを備え、
前記返済額計算モジュールは、前記第2段階の前記貸付銀行の再請求額を計算し、
前記返済額分配サーバは、前記第2段階に応じて、前記返済額分配サーバは、債務比率及び前記再請求額に応じて債務者が負う債務を再請求するように前記貸付銀行サーバに通知する返済額通知モジュールを更に有すること、
請求項1の債務返済システム。
【請求項4】
前記返済額計算モジュールは、
少なくとも1つの取引の購入額に応じて、前記合計債務の利子率を調整し、
前記購入額が閾値額よりも低くない場合、前記返済額分配サーバは、前記合計債務の前記利子率を下げ、
前記購入額が閾値額よりも低い場合、前記返済額分配サーバは、前記合計債務の前記利子率を上げる、
請求項1の債務返済システム。
【請求項5】
顧客端末をさらに備え、
前記返済額分配サーバは、前記第1段階の購入額を再請求するように前記顧客端末に通知する返済額通知モジュールを更に有すること、
請求項1の債務返済システム。
【請求項6】
返済アカウントを記録するアカウント管理サーバと、複数の貸付銀行の合計債務を2段階で返済する返済額を決定する返済額分配サーバとを備える債務返済システムの債務管理方法であって、
前記返済額分配サーバが備える返済額計算モジュールが、第1段階の返済額として、前記合計債務の元金は含まずに特定の時区間での利子を精算期間ごとに返済する返済額を計算し、
前記返済額計算モジュールが、第2段階の返済額として、前記合計債務の元金と特定の時区間での利子を精算期間ごとに返済する返済額を計算し、
前記返済額分配サーバが備える債務配分モジュールが、複数の銀行が有する債権額の比率に応じて返済額を貸付銀行の前記返済アカウントに分配して転送するよう、前記アカウント管理サーバに通知する、
債務管理方法。
【請求項7】
前記返済額分配サーバが備える返済額通知モジュールが、前記第1段階の返済額又は前記第2段階の返済額を顧客の顧客端末に通知する、
請求項6の債務管理方法。
【請求項8】
前記返済額計算モジュールが、前記返済アカウントからの返済額を決定することの後に、前記第2段階の前記貸付銀行の再請求額を計算し、
前記返済額分配サーバが備える返済額通知モジュールが、前記第2段階に応じて、債務比率及び前記再請求額に応じて債務者が負う債務を再請求するように通知する、
請求項6の債務管理方法。
【請求項9】
前記返済額計算モジュールが、
前記返済アカウントからの返済額を決定することの後に、
少なくとも1つの取引の購入額に応じて、前記合計債務の利子率を調整することと、
前記購入額が閾値額よりも低くない場合、前記返済額分配サーバは、前記合計債務の前記利子率を下げることと、
前記購入額が閾値額よりも低い場合、前記返済額分配サーバは、前記合計債務の前記利子率を上げることと、
をさらに備える、
請求項6の債務管理方法。
【請求項10】
前記返済額分配サーバが備える返済額通知モジュールが、
前記返済アカウントからの返済額を決定することの後に、
前記第2段階に応じて、前記第1段階の購入額を再請求するように顧客端末に通知すること、
をさらに備える、
請求項6の債務管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、財務管理技術に関し、具体的には、債務返済システム及び債務管理方法の種類に関する。
【背景技術】
【0002】
我が国のカード債務を負う人の数は、約八十万から百万人に昇る。債務削減規則が、債務を返済する債務者に必要であり、その実施が、この10年間、法廷を通過している。具体的には、40.25%にあたる17532の返済プログラムのみが通過し、27.27%にあたる2,000人以上が通過し、免除されている。
【0003】
現在の信託規則では、非信託人は、信託財産、所有者の財産、及び他の顧客の信託財産を、個別に管理してよい。金銭が信託財産として使用された場合、それは、請求書によって個別に扱われてよい。
【0004】
カード債務を負う誰かの個人債務を取り扱う場合、もし債務者のそれぞれが金銭信託を介して金銭債務を取り扱うことができれば、その人達は、より専門的かつより効率的となる。債務返済を例にとると、金銭信託によって債務を清算することは、専門家に財務管理を依頼することと同等であり、時間を節約でき、心配も必要ない。専門家に投資リスクの判断を仰ぎ、それを経済分析の手段として使用することで、投資の収益性はより効率的となる。知識、時間、個人の体力の限界により、各金融商品及び投資対象について深く広い調査及び分析を行うことは不可能である。しかしながら、金銭信託を介すれば、感情的、盲目的、投機的な個人投資は回避され、目標、専門的な投資判断、及び収益が達成できる。
【0005】
さらに、銀行がカード債務を処理する場合、銀行は、カード保有者がカード債務を負った最初の月の後に、支払い通知を送る。その後、法廷を通して、法的手段がとられる(支払い命令の請求又は貸付金の返済を請求する訴訟を含む)。銀行は、その実行に許可が得られた時、法廷を通して、債務者の財産に強制支払い控除を実行できる。
【0006】
銀行が強制支払い控除を実行するとしても、それは、銀行がカード朋友者の全ての支払いを完全に控除できることを意味しない。法廷は、債務者は生活を維持しなければならないことを考慮し、実際には、銀行の強制支払い控除は、三分の一までが許可される。
【0007】
また、カード負債を負う人のカード負債は、異なる貸付銀行のものであることが注意される。これらのグループは、多くの貸付銀行による精力的な回復に直面し、身体的及び精神的に消耗し、圧倒されてしまう。従って、実際には、カード負債を負う人々の大多数は、現実逃避的となり、貸付銀行からのカード債務の回復から逃げるために現金(給料支払簿なし)を提供する職場を選んでしまう。結果として、カード発行銀行の巨大な債権者権利は表面的なものとなり、彼らは、時間が経った後に、不良債権に気付くことになる。
【発明の概要】
【発明が解決しようとする課題】
【0008】
上記を鑑みて、本開示は、段階的債務返済計画を提供し、複数の貸付銀行への返済を分配することができる債務返済システム及び債務管理方法を提供し、複数の銀行の信託業務を効率的に統合する。
【課題を解決するための手段】
【0009】
本開示の実施の形態の債務返済システムは、複数の貸付銀行サーバと、キャリア提供サーバと、少なくとも1つの消費者端末と、アカウント管理サーバと、返済額分配サーバと、を備える。これらの貸付銀行サーバは、それぞれ、顧客の合計債務を提供する。キャリア提供サーバは、購入キャリアを提供し、購入キャリアの購入状況を記録し、購入キャリアは、支払いのための物理カード又は仮想カードを含む。消費者端末は、購入キャリアを介して行われた取引を受信し、取引の購入額をキャリア提供サーバに提供する。アカウント管理サーバは、返済アカウントを提供し、返済アカウントは、購入額及び返済額の払い戻しを貯金する。返済額分配サーバは、合計債務及び取引の購入額に応じて、返済計画の第1段階及び第2段階を決定し、各貸付銀行サーバに対応する合計債務の債務比率に応じて、返済アカウントから転送された返済額を決定する。返済計画の第1段階の第1の返済額は、合計債務の元金なしの利子返済に関連し、返済計画の第2の段階の第2の返済額は、合計債務の元金ありの利子返済に関連する。
【0010】
さらに、本開示の実施の形態の債務管理方法は、以下の、購入キャリアを介して行われた取引を受信し、取引の購入額を取得するステップであって、購入キャリアは、支払いのための物理カード又は仮想カードを含む、取得するステップと、合計債務及び購入額に応じて、返済計画の第1段階及び第2段階を決定するステップであって、返済計画の第1段階の第1の返済額は、合計債務の元金なしの利子返済に関連し、返済計画の第2段階の第2の返済額は、合計債務の元金ありの利子返済に関連する、返済計画を決定するステップと、各貸付銀行の債務比率に応じて、返済アカウントから転送された返済額を決定するステップであって、返済アカウントは、第1又は第2の返済額、及び購入額の払い戻しを貯金するために使用される、返済額を決定するステップと、を備える。
【発明の効果】
【0011】
上記に基づくと、本開示の実施の形態は債務返済システム及び債務管理方法は、2段階の返済計画を提供し、顧客は、顧客の購入キャリアを介した現在の購入額に対応する払い戻しと結び付けられ、共に返済アカウントへと預金される、各清算サイクルの債務の利子のみを預金すればよい。返済アカウント内の資金は、貸付銀行投資に利用可能である。また、第2の段階において、返済アカウント内の資金は、さらに、各貸付銀行の債務比率に応じて再請求されてよく、顧客は、また、過剰な払い戻しを持ち出してよい。これにより、複数の貸付銀行の信託業務が統合されるだけでなく、債務者は、債務を清算することができ、貸付銀行は、債務者が負う債務の回復を成功させることができる。
【0012】
上記の本開示の特徴及び利点を理解可能にするために、実施の形態が、図面と共に、以下に説明される。
【0013】
付される図面は、本開示に対するさらなる理解を提供するために含まれ、本明細書に組み込まれ、その一部を構成する。図面は、本開示の実施の形態を示し、説明と共に、本開示の原理を説明するために供される。
【図面の簡単な説明】
【0014】
図1図1は、本開示の実施の形態に係る、債務返済システムの概要図である。
【0015】
図2図2は、本開示の実施の形態に係る、返済額分配サーバの要素のブロック図である。
【0016】
図3図3は、本開示の実施の形態に係る、債務管理方法のフローチャートである。
【発明を実施するための形態】
【0017】
図1は、本開示の実施の形態に係る、債務返済システムの概要図である。債務返済システム1は、顧客端末10と、1つ以上の消費者端末20と、貸付金を提供する複数の貸付銀行サーバ30と、購入キャリア25を提供するキャリア提供サーバ40と、アカウントを管理するアカウント管理サーバ50と、返済額分配サーバ100と、を備える。
【0018】
顧客端末10は、スマートフォン、タブレットパソコン、ノートパソコン、デスクトップパソコン、その他等の電子装置であってよく、ネットワークモジュール(例えば、第4世代又はその後の世代のモバイル通信、Wi-Fi、イーサネット(登録商標)等)と、ディスプレイ(例えば、LCD又はLEDディスプレイ等)と、プロセッサ(例えば、CPU、マイクロコントローラ、又は特定用途向け集積回路(ASIC)等)と、を少なくとも備え、インターネットに接続し、ユーザインタフェースを表示し、又は計算機能を通知及び実行する。本実施の形態において、顧客は、顧客端末10であり、貸付銀行と、カード債務、抵当貸付その他等の債務関係にある。
【0019】
消費者端末20は、物理店舗の物理端末(例えば、カードリーダ、クレジットカード機、又は(一次元又は二次元バーコード用の)スキャナ等)、又はオンライン店舗のチェックアウトプラットフォーム/仮想端末(例えば、クレジットカードネットワーク、eウォレット、第三者支払い取引プラットフォーム等)であってよく、購入キャリア25を提供するキャリア提供サーバ40と接続されてよく、取引情報(例えば、使用された購入キャリア25や購入額等)を提供する。また、購入キャリア25は、電子通貨に関連する仮想ウォレット(例えば、第三者支払い、オンラインバンク等の経済機関(例えば、銀行や保険会社に提供される))であってよく、クレジットカード、デビットカード、ストアバリューカード、又はメンバーシップであってよく、物理カード又は仮想カード(例えば、モバイル決済)であってよい。
【0020】
貸付銀行サーバ30、キャリア提供サーバ40、及びアカウント管理サーバ50は、さまざまな種類のサーバ、ワークステーション、バックホスト等の電子装置であってよく、ネットワークモジュール(例えば、第4世代モバイル通信、Wi-Fi、又はイーサネット(登録商標)等)と、ストレージ(例えば、従来のハードディスクドライブ(HDD)、ソリッドステートドライブ(SSD)等)と、プロセッサ(例えば、CPU、マイクロコントローラ、又はASIC等)と、を少なくとも備え、インターネットに接続され、顧客(例えば、債務者)の債務情報(例えば、利子、契約期間、元金、元金を含む全利子返済額、返済アカウント、及び信託アカウント等)及び取引情報(例えば、使用された購入キャリア25及びその購入額等)を記録し、計算機能を実行する。本実施の形態において、貸付金を提供する貸付銀行サーバ30は、顧客に貸付金(例えば、貸付金、カード債務、信用買い、債券)を提供する金融機関によって設立されるサーバを示す。キャリア提供サーバ40は、購入キャリア25を発行(提供)又は管理する金融機関によって設立されるサーバを表す。アカウント管理サーバ50は、(貸付銀行に金銭を転送できる)返済アカウントを提供する金融機関によって設立されるサーバを表す。この返済アカウントは、信託アカウント又は別の予め指定されたアカウントであってよい。
【0021】
返済額分配サーバ100は、コンピュータホスト、サーバ、又はバックホスト等の電子装置であってよい。図2は、本開示の実施の形態に係る、返済額分配サーバ100の要素のブロック図である。図2を参照すると、返済額分配サーバ100は、ストレージ110と、ネットワークモジュール130と、及びプロセッサ150と、を少なくとも備えるが、これに限定されない。
【0022】
ストレージ110は、任意の種類の固定又は取り外し可能なランダムアクセスメモリ(RAM)、リードオンリメモリ(ROM)、フラッシュメモリ、従来のハードディスクドライブ(HHD)、ソリッドステートドライブ(SSD)、若しくは同様の要素、又は上記の組み合わせであってよい。本実施の形態において、ストレージ110は、バッファデータ又は保存データ等のデータ又はファイル、ソフトウェアモジュール(例えば、返済額計算モジュール111、債務配分モジュール112、及び返済額通知モジュール等)、アプリケーション、債務情報、取引情報、債務比率、及び返済額を保存することに使用され、その詳細は、下記の実施の形態において詳細に説明される。
【0023】
ネットワークモジュール130は、第4世代(4G)又はその後の世代のモバイル通信、Wi-Fi、イーサネット(登録商標)、光ファイバーネットワーク等の通信トランシーバを支持してよい。
【0024】
プロセッサ150は、ストレージ110及びネットワークモジュール130に接続され、中央演算処理装置(CPU)、若しくは別のプログラマブル汎用若しくは専用マイクロプロセッサ、デジタルシグナルプロセッサ(DSP)、プログラマブルコントローラ、特定用途向け集積回路(ASIC)、若しくは別の同様の要素、又は上記の組み合わせであってよい。本開示の実施の形態において、プロセッサ150は、返済額分配サーバ100の動作の全てを実行するために使用され、ストレージ110に記録されたソフトウェア、モジュール、ファイル、及びデータを、それぞれ、ロード及び実行してよい。
【0025】
本開示の実施の形態の動作フローへの理解を容易にするために、以下は、本開示の実施の形態の債務返済額システムを介して債務を管理するプロセスを詳細に説明する複数の実施の形態である。以下、本開示の実施の形態において説明される方法が、債務返済システム1の各装置、並びに返済額分配サーバ100の様々な要素及びモジュールに関して説明される。本方法の各プロセスは、実施の形態の状態によって調整されてよく、限定されない。
【0026】
図3は、本開示の実施の形態に係る、債務管理方法のフローチャートである。図3を参照すると、債務者は、(貸付銀行サーバ30に対応する)各貸付銀行と、カード債務又は様々な種類の貸付金等の債務関係を有する。債務者は、返済アカウント(例えば、信託アカウント又は別のアカウント)及び予め指定されたアカウント(例えば、信託アカウント又は別のアカウント)を設立することを、各貸付銀行と合意してよい。債務者は、債務返済のために、この返済アカウントに金銭を預金してよい。アカウント管理サーバ50は、貸付銀行の予め指定されたアカウントに特定の金額を転送する固定又は設定された日付を有するように、返済アカウントを設定してよい。これらの貸付銀行サーバ30は、特定の顧客(例えば、債務者)の合計債務を、返済額分配サーバ100に提供してよい。この合計債務は、例えば、カード債務及び延滞利息の合計、全貸付金額、その他であり、要求に応じて調整されてよい。
【0027】
さらに、キャリア提供サーバ40は、債務者が使用する購入キャリア25を発行/提供する。各消費者端末20は、購入キャリア25を介して、債務者による取引を受信してよい(ステップS301)。各取引に応答して、消費者端末20は、取引の購入額を、キャリア提供サーバ40に提供する。その後、キャリア提供サーバ40は、購入キャリア25(又は購入履歴)に基づいて、購入状況を記録する。具体的には、購入状況は、一ヶ月の購入額、特定のチャンネルの購入時間及び金額、その他等の、購入キャリア25を介する物理又は仮想消費者端末20の購入額に関連する。キャリア提供サーバ40は、さらに、フィードバックの特定のパーセント、フィードバックポイント/トークン、購入額のその他等の購入後の払い戻しをする購入キャリア25を提供してよいことを述べておく。キャリア提供サーバ40は、取引の購入額の払い戻しを返済額分配サーバ100又は返済アカウントに転送してよい。払い戻しの使用は、以下の例において詳細に説明される。
【0028】
返済額分配サーバ100の返済額計算モジュール111は、債務者の合計債務及び一定の支払い請求の期間(例えば、一ヶ月、一シーズン、又は半年、その他)内の購入額に応じて、返済計画の第1段階及び第2段階を決定してよい(ステップS302)。具体的には、債務が大量にある場合、債務者にとっての最良の対応は、分割払い又は段階的な返済への割引を提供し、債務者が合計債務を清算できる能力を与えることである。従って、どのように返済計画を設定し、債務者及び債権者の両方の負担を軽減するかは、貸付銀行にとって価値のある課題である。本開示の実施の形態において、債務者の債務の元金が払われる前に、(各債務比率に応じた)固定利子が、各貸付銀行(金銭信託)アカウント(以下、単に信託アカウントと称する)に払われる必要がある。信託期間の間、各貸付銀行は、これらの(預金/貸付)のための資金を使用して、各貸付銀行信託アカウント資金のための広告又は別の種類の投資利益を稼いでよい。債務を金銭信託の手段で清算することは、専門家に財務管理を委託し、専門家により、投資リスクを判断し、金融商品を分析し、より効率的な投資利益を得ることを意味することを述べておく。
【0029】
さらに、本開示の実施の形態は、2段階の購入期間を提供する。この2段階の購入期間による返済計画の差は、利子に対応する合計債務返済の内容が異なることである。返済計画の第1段階の第1の返済額(例えば、債務者が払うべき金額)は、合計債務の元金なしの利子返済に関連する。返済額計算モジュール111は、合計債務の元金及び払い戻しなしの利子返済の利子に応じて、第1の返済額を決定する。具体的には、第1段階では、債務者は、(特定の利子率に応じた)合計債務からの利子を配分しさえすればよく、合計債務の元金を支払う必要はない。第1段階は、3年、5年、又は20年等の特定の時区間である。ここで、配分された支払いとは、特定の比率に応じて利子が清算期間(例えば、一ヶ月、又は一シーズン等)毎に均等に分割又は配分され、債務者は各特定清算期間に、返済アカウントに配分された利子を預金するだけでよいことを意味する。例えば、2%の年間利子率の場合、債務者は、12,000,000ドルのカード債務を負い、延ばされた利子もまた12,000,000ドルであり、合計債務は24,000,000ドルである。第1段階(例えば、初年度から二十年度)では、固定の2%の年間利子率に応じて、約4,000(24,000,000×2%/12)ドルの利子(利子返済のみ)が合計2年の240の期間(清算期間は一ヶ月と仮定)において一ヶ月毎に返済される。また、返済額通知モジュール113は、ネットワークモジュール130を介して、購入キャリア25を介する購入により発生した払い戻し(の全て又は一部)が返済アカウントに預金されたことを通知する。第1段階の各清算期間が満了すると、返済アカウントは、この清算期間内の払い戻し及び配分された利子が信託されている。例えば、購入キャリア25が今月に10,000ドルを消費し、1,000ドルの払い戻しを発生させたとすると、返済アカウントは、今月は1,000ドル(払い戻し)及び4,000ドル(配分された利子)が信託される。返済額通知モジュール113は、ネットワークモジュールを介して、段階(第1段階は第1の返済額に対応し、第2段階は第2の返済額に対応する)に応じた第1の返済額又は第2の返済額を顧客端末に通知してよい。アカウント管理サーバ50は、債務者のアカウントと共に、予め指定された借り方メカニズムを有してよく、各清算期間の満了毎に、所定の返済額を、債務者のアカウントから返済アカウントに自動的に転送してよい。債務者が一ヶ月に10,000ドルを消費したとすると、240ヶ月後、返済アカウントには合計12,000,000ドルが預金されている。
【0030】
また、返済計画の第2の段階の第2の返済額(例えば、債務者が払うべき金額)は、合計債務の元金ありの利子返済に関連する。返済額計算モジュール111は、合計債務の元金及び払い戻しありの利子返済の利子に応じて、第2の返済額を決定する。具体的には、第2段階では、債務者は、(特定の利子率に応じた)合計債務からの利子及び元金を配分する必要がある。第2段階は、第1段階の後の、3年、5年、又は20年等の特定の時区間である。ここで、配分された支払いとは、特定の比率に応じて元金及び利子が清算期間(例えば、一ヶ月、又は一シーズン等)毎に均等に分割又は配分され、債務者は各特定清算期間に、返済アカウントに配分された元金及び利子を預金するだけでよいことを意味する。例えば、2%の年間利子率の場合、債務者は、12,000,000ドルのカード債務を負い、延ばされた利子もまた12,000,000ドルであり、合計債務は24,000,000ドルである。合計2年の240の期間では、全利子は、513,839ドルであり、元金及び利子の合計は、2,913,839ドル(12,000,000+513,839)である。第2段階(例えば、21ヶ月目から40ヶ月目)では、毎月の寄与(清算期間は一ヶ月と仮定)は、元金及び利子のための約2,140(513,829/240)ドルである。すなわち、20年間の合計利子は、513,600ドル(おおよそ513,839ドル)である。別の実施の形態において、最初の利子合計は、2番目に高い桁を直接繰り上げてよく(例えば、513,839では10,000)(例えば、513,839は10,000で繰り上げられ520,000)、繰り上げの後に全利子は、債務者が各清算期間で支払うべき利子へと均等に分割される。例えば、240の期間で分割される520,000は、月当たり約2,166ドルである。あるいは、各清算期間で支払われるべき利子は、合計債務の利子に応じて調整されてよい。また、返済額通知モジュール113は、ネットワークモジュールを介して、段階(第1段階は第1の返済額に対応し、第2段階は第2の返済額に対応する)に応じた第1の返済額又は第2の返済額を顧客端末に通知してよい。アカウント管理サーバ50は、債務者のアカウントと共に、予め指定された借り方メカニズムを有してよく、各清算期間の満了毎に、所定の返済額を、債務者のアカウントから返済アカウントに自動的に転送してよい。債務者が一ヶ月に10,000ドルを消費したとすると、240ヶ月後、返済アカウントには合計753,600ドルが預金されている。
【0031】
次に、債務配分モジュール112は、各貸付銀行サーバ30に対応する合計債務の債務比率に応じて返済アカウントから転送された返済額を判定する(ステップS303)。具体的には、特定の顧客についての貸付銀行の数を統合するために、本開示の実施の形態の返済額を配分サーバ100は、自動債務配分システムを提供する。各貸付銀行は、特定の顧客について異なる債務の金額を有する。債務配分モジュール112は、顧客についての貸付銀行の全ての債務を合計し、合計(顧客の合計債務)における各貸付銀行の比率を計算してよい。例えば、貸付銀行Aは、100,000の顧客債務を有し、貸付銀行Bは、500,000の顧客債務を有し、貸付銀行Cは、500,000の顧客債務を有すると、債務比率は2:1:1(又は1/2、1/4、及び1/4)である。各段階のそれぞれの清算期間になると、返済アカウントは、特定の返済額が預金されている。債務配分モジュール112は、返済額が、(段階に応じた)第1の返済額及び第2の返済額と同じかを確認する。違っていれば、返済学通知モジュール113は、ネットワークモジュール130を介して、不足している金額を顧客端末10に通知する。同じあれば、債務配分モジュール112は、通知モジュール130を介して、債務比率に応じて各貸付銀行の返済アカウントに特定の金額をそれぞれ転送するように、アカウント管理サーバ50に通知する。例えば、5000ドルの返済額と2:1:1の債務比率であれば、2,500ドルが貸付銀行Aの予め指定されたアカウントに転送され、1,250ドルが貸付銀行Bの予め指定されたアカウントに転送され、1,250ドルが貸付銀行Cの予め指定されたアカウントに転送される。各貸付銀行は、転送された資金を使用して、預金/貸付広告収入又は別の種類の投資を行ってよい。
【0032】
第1段階(すなわち、元金なしの利子返済)では、元金なしの利子返済の利子、及び購入キャリア25を介する払い戻しは、返済アカウントから各貸付銀行の信託アカウントに預金される(ステップS304)ことが理解される。第2段階(すなわち、元金ありの利子返済)では、元金ありの利子返済の利子、及び購入キャリア25を介する払い戻しは、返済アカウントから各貸付銀行の信託アカウントに預金されることに加え、第1段階及び第2段階で預金された返済額は、それぞれ、債務比率に応じて、信託アカウントから、対応する貸付銀行の予め指定されたアカウントに預金される(ステップS305)ことを述べておく。返済額計算モジュール111は、第2段階におけるそれら貸付銀行サーバ30の再請求額を計算する。再請求額は、返済アカウント内の全ての所得の分割又は特定の比率による分配であってよい。例えば、第1段階は、返済アカウントに合計1,200,000ドルが預金されているはずであり、返済額計算モジュール111は、貸付銀行の再請求のための、第2段階の半分内の毎月、貸付銀行の予め指定されたアカウントに10,000ドル(すなわち、再請求額)を転送してよい。第2段階がくると、返済額通知モジュール113は、ネットワークモジュール130を介して、債務比率及び再請求額に応じて債務者が負う債務を再請求するように通知してよい。例えば、10,000ドルは、債務比率1:4に応じて、2,000ドル及び8,000ドルが、それぞれ、対応する貸付銀行の予め指定されたアカウントに転送されてよい。
【0033】
例えば、2つの段階の合計は、返済アカウントに預金された195000ドル及び3600ドルの合計資金(上記の例の1,200,000及び753,600の合計)である。各貸付銀行が、(預金/貸付)のために使用され、広告利益又は別の種類の投資利益を得たか、(年間利子1%の)少ない利子を計算するために使用されたかに関わらず、その最終返済額(返済額及び投資利益の合計)は、24,000,000ドルよりはるかに多く、債務分配モジュールが、キャリア保持者(債務者/銀行)のために第2段階での債務比率に応じて毎月の預金を行い、毎月の再請求を行うために十分である(貸付銀行の毎月の返済額のための24,000,000ドルの合計債務として使用できる)。
【0034】
また、第2段階がくると、返済額通知モジュール113は、また、ネットワークモジュール130を介して、第1段階の購入額を再請求するように通知してよい。貸付銀行は、信託アカウントに資金を預金することにより投資利益を取得し、その最終合計返済額は、最初の合計債務を超過してよい。これらの超過額は、債務者に返還され、彼らの購入行動を促進する。返済額計算モジュール111は、全利益、及び各貸付銀行サーバにより返還された合計債務の差に応じて、債務者に返還する購入額を決定してよい。例えば、この差は、月毎に配分され再請求される。換言すれば、債務者は、貸付銀行による返済額の投資からの利益を共有することができる。
【0035】
購入を促進するために、合計債務の利子率は、さらに調整されてよい。実施の形態において、返済額計算モジュール111は、購入キャリア25の取引の購入額に応じて、合計債務の利子を調整してよい。購入額が閾値額よりも低くない場合(例えば、10,000、30,000、又は50,000)、返済額計算モジュール111は、合計債務の利子率を下げる。払い戻しが購入額と共に増加すると、最終合計返済額も増加し、それにより、合計返済額は合計債務を超過する可能性が高い。例えば、貸付銀行は、年間利子率を0.5%、0.8%、及び1%分下げてよく、各清算期間に債務者が支払うべき返済額は下がる。さらに、購入額が閾値額よりも低い場合、返済額計算モジュール111は、合計債務の利子率を増加させ、それにより、合計返済額及び合計債務の差がより縮まる。
【0036】
いくつかの実施の形態において、第1段階での購入キャリア25を介する全購入額は、それぞれ、債務比率に応じて、信託アカウントから対応する貸付銀行の予め指定されたアカウントに預金されてもよい。例えば、債務者が月当たり10,000ドルを消費すると、全購入額は、2,400,000である。これらの購入額は、第2段階において債務者によって毎月再請求されてよく、これらは、貸付銀行の毎月の返済額のための2,400,000ドルとして使用されてよい。換言すれば、債務者が購入キャリア25を介して消費した金額は、第2段階の各清算期間に、購入キャリア25によって発行される金融機関に返還されなければならない。金融機関に対応するキャリア提供サーバ40は、第2の段階で各貸付銀行の予め指定されたアカウントに転送されるように、これらの金額を返済アカウントに預金する。
【0037】
上記の例は、全て、固定の利子率で利子を計算していることが理解される。別の実施の形態において、変動する利子が提供されてよく、貸付銀行は、借り方及び貸付についての答えを提供する。
【0038】
上記に基づくと、本開示の実施の形態の債務返済システム及び債務管理方法は、債務者及び貸付銀行のための2段階返済計画を提供する。購入キャリア25の使用と共に、債務者の購入からの払い戻しが返済金として使用される。また、2つの段階において、債務者は、元金なしの利子返済額及び元金なりの利子返済額に対応する利子のみを配分すればよい。これにより、債務者の経済的な負担は、大いに軽減される。貸付銀行について、これらの返済資金は、投資として使用されてよく、確認された不良債権の大量の債務(利子の利益)を完全に回復できる。さらに、本開示の実施の形態は、また、複数の貸付銀行の貸付業務を再編し、貸付銀行が、各債務者が負う債務を便利に管理することができるようにしてよい。
【0039】
上記の実施の形態を参照して本開示を説明したが、説明された実施の形態への変更を本開示の精神から逸脱せずに行うことができる点が、当業者にとって明らかである。従って、本開示の範囲は、上記の詳細な説明ではなく、添付される請求の範囲によって画定される。
【産業上の利用可能性】
【0040】
本開示の債務返済システム及び債務管理方法は、財務管理の分野に適用される。
【符号の説明】
【0041】
1 債務返済システム
10 顧客端末
20 消費者端末
25 購入キャリア
30 貸付銀行サーバ
40 キャリア提供サーバ
50 アカウント管理サーバ
100 返済額配分サーバ
110 ストレージ
130 ネットワークモジュール
150 プロセッサ
111 返済額計算モジュール
112 債務配分モジュール
113 返済額通知モジュール
S301~S305 ステップ

図1
図2
図3