(57)【要約】【課題】口座振替における１つの支払請求に対して複数の口座で分担負担する場合に、複数口座間で適切な費用分担額を算出し、最後に請求元へ一括して振替えるシステムを提供する。【解決手段】判断手段１０１に接続された各種データベース１０７〜１１１の情報を基に、費用を分担負担する口座とその分担額の算出方法を選択し、分担額を同算出方法にて算出し、請求先口座から一括して振替を実行することにより複数口座による負担の分担を可能とした。【選択図】  図１
2006343903.tif 000002
【特許請求の範囲】
【請求項１】
口座振替により、対価の支払を行う場合における複数口座振替制御システムにおいて、前記対価の振替元となる複数の支払口座と前記対価に対する前記複数の支払口座の支払比率を含む支払情報とを記憶する手段と、前記対価の支払い要求があった場合、前記複数の支払い口座に設定されている前記支払情報に応じて、前記複数の口座それぞれの支払金額を算出する手段と、算出された支払金額それぞれと前記複数の口座それぞれの残高を比較して、前記複数の口座で振替が不可となる口座がないかを検知する手段と、振替が不可となる口座がある場合、不足金額を算出し、算出された前記不足金額を代替する口座を前記複数の口座から特定する手段とを有し、前記複数の口座に含まれる口座から前記対価の支払いを実行する複数口座振替制御システム。
【請求項２】
請求項１に記載の複数口座振替制御システムにおいて、前記支払い情報は、前記複数の支払い口座の支払い比率または前記複数の支払い口座の支払いの優先順位付けの情報であり、前記支払い金額を算出する手段は、前記特定される口座から振替るべき金額を、前記支払い情報に基づいて算出することを特徴とする複数口座振替制御システム。
【請求項３】
口座振替により、対価の支払を行う場合における複数口座振替制御方法において、前記対価の振替元となる複数の支払口座と前記対価に対する前記複数の支払口座の支払比率を含む支払情報とを記憶しておき、前記対価の支払い要求があった場合、前記複数の支払い口座に設定されている前記支払情報に応じて、前記複数の口座それぞれの支払金額を算出し、算出された支払金額それぞれと前記複数の口座それぞれの残高を比較して、前記複数の口座で振替が不可となる口座がないかを検知し、振替が不可となる口座がある場合、不足金額を算出し、算出された前記不足金額を代替する口座を前記複数の口座から特定することで、前記複数の口座に含まれる口座から前記対価の支払いを実行する複数口座振替制御方法。
【請求項４】
請求項３に記載の複数口座振替制御方法において、前記支払い情報は、前記複数の支払い口座の支払い比率または前記複数の支払い口座の支払いの優先順位付けの情報であり、前記支払い金額は前記特定される口座から振替るべき金額を、前記支払い情報に基づいて算出することを特徴とする複数口座振替制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、金融機関の口座振替に関して、請求に対して実際に支払・引落を行う１つの口座(以下、支払口座)と同請求に対して実質的に負担を行う複数の口座(以下、負担口座)との間で行われる自動振替および不足金自動相互補完、およびその自動返済に関する発明である。
【背景技術】
【０００２】
銀行や信金などの金融機関や郵便貯金の口座における自動振替サービスは、出金される１つの口座と入金される１つの口座との間で行われる１対１口座間取引による決済サービスである。そのため、請求に対して支払いを行う口座は自動振替サービス契約時に定められたただ１口座となることが普通である。
【０００３】
しかし、実際の取引を鑑みると、料金を支払う者(以下、支払者)と実際に料金を負担している者(以下、負担者)が異なる場合がある。例えば、家族の中に収入のある者が複数いて、彼らが共同で生活費を出し合い、世帯主の口座を生活費管理用口座として利用しているような場合では、実際に料金を支払っている支払者は世帯主であるが、実質的に負担している負担者は生活費を出している家族全員ということになる。
【０００４】
このような費用の支払者と負担者が異なっている場合に問題となるのは、負担者は各人に割り当てられた費用の分担分を支払者に対して都度支払わなくてはならず、また、支払者は費用の分担分を負担者の数だけ都度回収しなくてはならず、これらが非常に大きな手間となっている、ということである。
【０００５】
以上より、このような負担者から支払者への分担金の支払の手間を自動振替によって軽減するニーズがあると考えられる。しかし、これを実現するには、１対１口座間の自動振替取引とは違う、複数の口座間での自動振替における適切な制御・管理が必要になる。これに関連して、複数口座を制御・管理するという技術について、現在下記のような技術が存在している。
【０００６】
【特許文献１】特開２００３−２８８４９２においては、仮想口座を用いて複数口座の資金状況をまとめることにより、この仮想口座の資金状況の管理を通じて複数口座の資金状況を容易に管理することが可能になる、という技術がある。これにより、複数口座を保有することによって１つ１つの口座管理がなおざりになることを防ぐことが可能になる。
【０００７】
しかしながら、本公知例は１顧客が有する複数の口座を統合的に把握、管理する手段であって、複数顧客が保有する複数口座に対する技術ではない。また、本公知技術は複数口座の自動振替を制御するものではない。
【０００８】
【特許文献２】特開２００３−２８１４５８においては、１顧客が保有する複数の銀行に存在する複数口座を統合的に管理する技術がある。これにより、複数口座の入出金を時系列に統合して顧客に表示することや、残高不足時に口座振替先を変更するなどによって口座引落時の引落ミスを無くすこと、などが可能となる。
【０００９】
しかしながら、本公知技術では、前提として１顧客が保有する複数口座である必要があり、複数顧客による複数口座の統合管理を対象としていない。また、支払を複数口座で分担し合うという技術でもない。さらに、残高不足における処理については、本公知技術では支払口座が残高不足に陥っている場合に他の口座へと支払口座を変更するだけであるが、この技術ではいかなる引落に対しても自動補完が実施され、貸与関係の把握ができない。
【００１０】
上記の通り、複数負担者の複数口座による費用分担に関する従来技術では、複数口座を適切に制御・管理し、請求額を複数口座で適切に分担し、正確に振替を実施する方法が無いため、負担者が支払者に対して支払いを行わなくてはならないという手間を無くすことは実現していない。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明は、上記問題を解決するためのものであり、費用を支払う口座が１つであるのに対して、実質的に費用を負担する口座が複数ある場合の口座及び振替取引の適切な制御・管理を実現する制御システム及びその方法を提供することを目的とするものである。
【課題を解決するための手段】
【００１２】
上記目的を達成するため、本発明は、金融機関又は郵便貯金の口座より公共料金・電話料金・税金・保険料・学費・クレジット・会費などの支払請求について、支払口座と請求元の組合せごとに利用者が事前に決めた負担口座を特定する手段と、請求元ごとに利用者が事前に決めた負担額の分担方法を特定する手段と、負担額の分担方法に基づいて負担口座ごとに負担額を算出する手段と、各負担口座の負担額に対して残高をチェックする手段と、各負担口座において負担額を引落す手段と、支払口座を介して請求額を一括して請求元に対して振替える手段と、残高不足に陥った負担口座に対して別の負担口座から自動的に不足金を代弁し保管するための金額を算出する手段と、補完による貸与額を借りた側から貸した側に自動的に返済する金額を算出する手段と、算出された返済額を借りた口座から貸した口座へ返済する手段と、を備えていることを特徴とする。
【発明の効果】
【００１３】
本発明により、１つの支払口座に対する請求を自動的に複数の負担口座によって分担することが可能となり、負担者の支払者への入金の手間と支払者への未収金リスク（支払い口座が残額不足で支払い不可の事態）が低減される。
【発明を実施するための最良の形態】
【００１４】
以下に本発明の実施の形態を説明する。
【実施例１】
【００１５】
本発明の最良の実施例を図面に基づいて説明する。図１は、本発明に係る複数口座間動的振替制御システムの最良の実施例を示す構成図である。なお、本実施例は銀行に応用したものである。
【００１６】
まず、図１から順に図について説明する。
図１の１０１は、本方法を実現するための判定手段であり、演算装置１０２と記憶装置１０３とからなる。データは必要に応じて各データベースから前記記憶装置１０３に読込まれ、データを処理するソフトウエアは記憶装置１０３に保持されており、適切なソフトウエアに従って前記演算装置１０２によってデータの処理および条件判断が実行され、前記記憶装置１０３のデータが更新され、各データベースにも更新されたデータが保存されるものである。メインフレームやサーバーなどは判定手段に相当する処理機構を有する。
【００１７】
１０４はキーボードやマウスなどの入力装置であり、１０５はモニタやプリンタなどの出力装置、１０６はイントラネットやインターネットなどとの通信装置であり、ネットワークを介して他システムとの連携を実現する。なお、前記判断手段１０１へのデータの入出力は前記入力装置１０４、前記出力装置１０５のみならず前記通信装置１０６を用いて行われても良い。
【００１８】
１０７〜１１１は後述する各種データベースであり、前述の判定手段１０１に接続されており、前記記憶装置１０３との間でデータをやり取りする。
１０７は、請求元から寄せられたデータを、支払口座ごとに請求元、支払口座番号、支払者氏名、引落日、請求額等の自動引落に必要な取引データを管理する取引データベースであり、図２のように実装されるものである。
【００１９】
１０８は、複数口座間動的振替制御システムによる自動振替サービスについて、当サービスの利用者と金融機関や郵便貯金との契約に基づき、その契約に一意に付与された契約ＩＤとその請求元、その支払口座番号、その分担方法を示す処理ＩＤ、および自動補完を実施する際の方法を示す補完ＩＤ等を管理する契約インデックスデータベースであり、図３のように実装されるものである。なお、図３の３０４に示すように、分担方法を示す処理IDを設定して請求元ごとに請求された金額の分担方法を変更することができる。
【００２０】
１０９は、契約ＩＤに基づき、実際の契約内容を管理する契約データベースであり、図４のように実装される。図４はその契約における負担口座番号４０２、自動補完等の契約有無４０３、などの契約内容のデータを管理するためのものである。
１１０は、口座番号ごとに、口座保有者、残高、補完限度額、およびその口座の生死状態などのデータを管理する口座情報データベースであり、図７や図８のように実装されるものである。なお、図８は本実施例の処理により図７より遷移した結果であり、フォーマットとしては同一のものである。
１１１は、口座間ごとに、債権者口座番号、債務者口座番号、残高等の口座間の貸借情報データベースであり、図９のように実装されるものである。
【００２１】
図５および図６は、負担額決定のための計算処理を示す処理ＩＤとその処理内容、および、不足補完額決定のための計算処理を示す補完ＩＤとその処理内容を、説明のためそれぞれ一覧にしたものである。
【００２２】
次に、本発明の複数口座間動的振替制御サービスにおける最良の実施例の流れを図１０のフローチャートに沿って説明する。図１０は、振替取引が開始されてから自動引落が行われ、振替処理が終了するまでの流れを示したものである。
【００２３】
まず、自動振替取引が開始されると、ステップＳ１０１において実行されるべき取引内容データを前記取引データベースから抽出する。例えば、当日が１７日である時、引落日が「１７日」である取引を実行すべきである場合、引落日が「１７日」である取引データを前記取引データベースから抽出する。図２の例では、取引日２０４が「１７日」であり、請求元２０１が「Ａ電力」、支払口座番号２０２が「1111111」、支払者氏名２０３が「Ｄ木一郎」、請求額２０５が「10,000」である取引データを抽出する。
【００２４】
次に、支払口座が前記複数口座間動的振替制御サービスを締結している口座であるか否かを判定するステップＳ１０２を実行する。判定は、図３の前記契約インデックスデータベースから請求元３０２と支払口座番号３０３の組合せから契約ＩＤ３０１を見つけられるかどうかなどの基準によって判断する。例えば、引落日が「１７日」の取引を行う場合、その取引の請求元「A電力」と支払い口座番号「1111111」の組と同一の組を有する契約ＩＤ（３０１）「０００１」が図３の前記契約インデックスデータベースから導出することができるため、この場合前記引落は本サービスが締結されている口座であると判断する。仮に、請求元が「Ａ電力」、支払口座番号が「9999999」であるような取引を実行する場合は、図３の前記契約インデックスデータベースにおいて請求元と支払口座番号の組がそれぞれ「Ａ電力」「9999999」と一致する契約ＩＤを探すことになるが、図３の例からでは発見することが出来ないため、契約が締結されていないと判断する。
【００２５】
ステップＳ１０２の判定結果が否定の場合、この口座は前記サービスが契約されていない口座と判断し、通常の、すなわち本発明の動的振替制御サービスが適用されない自動振替処理であるステップＳ１０９へ移り、自動振替完了後、取引処理を終了する。
【００２６】
一方、上記判定Ｓ１０２の結果が肯定の場合は、次のステップＳ１０３へと進む。Ｓ１０３においては、分担対象となっている口座のすべてが利用不可になっていないかを判断する。前記の例では、図４に基づき契約ＩＤに０００１が付された負担口座番号４０２は「1111111」、「2222222」、「3333333」の３つであることがわかる。また、図７から各口座は番号「1111111」「2222222」「3333333」、その状態７０５よりすべて存在しかつ利用可能であるということを判定する。ちなみに、口座番号「4444444」は口座が閉塞されて利用不可であることを示しており、この口座は負担口座として利用することは出来ない。
【００２７】
上記判定Ｓ１０３が肯定の場合、すなわち、負担口座の対象となる全ての口座において取引が出来ない状態にある場合、取引を中止するステップＳ１０８へと進む。
上記Ｓ１０３の判定において否定の場合、すなわち、少なくとも１つ以上の負担口座が取引可能である場合、口座間の負担額の分担方法を決定するステップＳ１０４へと進む。
ステップＳ１０４では、契約インデックスデータベースに基づき、契約ＩＤ３０１から処理ＩＤ３０４を特定することによって前記分担方法を決定する。図３に基づき、例えば契約ＩＤ３０１が「0001」の場合では、負担額の算出方法である処理ＩＤ３０４は「P01」であることを決定する。各口座の負担額の計算は、負担額の合計が前記請求額と同じになるという条件を満たす任意のアルゴリズムや計算式で行うことが可能であるが、前記処理ＩＤ３０４を１つ指定することにより、あらかじめ決定しておいた複数のアルゴリズムや計算式の候補の中からただ1つを決定することによって負担額の計算方法を定める。
【００２８】
ステップＳ１０５においては、前記Ｓ１０４により決定した前記処理ＩＤ３０４に基づき、実際の処理を行う。まず、契約データベースから前記請求元からの請求を負担する負担口座を特定する。前記例では、前記契約ＩＤ３０１は「0001」であるから、図４に基づき、その請求額を分担する負担口座４０２を「1111111」、「2222222」、「3333333」と判断する。また、前記処理ＩＤ３０４の処理を実行するために必要なデータを引数として利用する場合は、本複数口座間動的振替制御サービスの契約データベースにおける、重み４０４、基本負担額４０５、最小負担額４０６、最高負担額４０７などの契約に付随するデータを利用しても良く、その処理の内容に応じて図８の口座情報データベースや図９の貸借情報データベース等のデータベースから必要に応じて必要なデータを適宜利用しても良い。なお、前記基本負担額４０５とは負担額決定において最も優先的に分担が決定される額であり、最低負担額４０６とは当該取引の分担額が必ず超えていなくてはならない額であり、最高負担額４０７とは当該取引の分担額が決して超えてはならない額のことである。
【００２９】
前記処理ＩＤ３０４が「P01」の場合、図５の例の処理ＩＤ５０１より、処理内容５０２より「あらかじめ定めた重みに従い、請求額を前記割合で按分する処理」を実行し、それぞれの負担額を決定する。ここで各口座間にどのような条件もない（後述する説明では、口座間に金銭のいかなる貸借もない）と仮定すると、図２および図３の例において、前記請求元３０１が「Ａ電力」である場合、負担口座は「1111111」、「2222222」、「3333333」の３つであり、それぞれの重みは「5」、「3」、「2」であるから、請求額「10,000」に対してそれぞれ「5,000」、「3,000」、「2,000」を負担することを算出する。
【００３０】
ステップＳ１０６においては、前記Ｓ１０５において算出した各口座の負担額と各口座の残高を比較し、すべての口座において支払い可能であるか否かを判定する。この判断が肯定であった場合は１つ以上の口座において残高不足である場合であるから、ステップＳ１０８の取引中止処理に移り、本処理を終了する。一方、否定の判断の場合、すべての負担口座において支払いが可能であるから、ステップＳ１０７へと進み、各口座から支払口座への振替を実施し、また、支払口座からは一括して請求元口座への自動振替を実施し、本複数口座間動的振替制御サービスを終了する。前記の例では、負担口座「1111111」、「2222222」、「3333333」の負担額は、「5,000」、「3,000」、「2,000」であるが、前記負担口座の残高は図７よりそれぞれ「9,000」、「7,000」、「7,000」であり、すべての負担口座において支払可能であるため、前記負担額を支払口座へと振替えた後に支払口座から請求元口座へと一括して請求額を振替える。また、図７の口座情報データベースを更新し、各負担口座の残高７０３を図８の残高８０３のように「4,000」、「4,000」、「5,000」とする処理を実施する。以上の処理が終了した後、本取引を終了する。
なお、前記判断Ｓ１０６で１つ以上の負担口座が負担額に対して残高不足である場合、引落を完了できずに取引を終了させてしまう。これは、支払者の金利負担や社会的信用低下などの不利益をもたらすため、これを回避する手段を設けても良い。
【００３１】
次に図１１を用いて自動補完の手段について以下説明する。図１１は、残高不足にある負担口座に対して自動的に負担口座間で不足額を貸与し、補完しあう手段を設けたフローチャートである。なお、説明の便宜上、以下の自動補完の手段についての説明では、口座情報データベースは図８の状態であること、取引は前記例と同じく「Ａ電力」であることを仮定する。
【００３２】
図１１の前記判断Ｓ１０６において肯定である場合、ステップＳ１０８ではなくステップＳ１１０へと進む。前記判断Ｓ１０６において前記請求元２０１が「Ａ電力」の場合、前記説明と同様、負担口座「1111111」、「2222222」、「3333333」の負担は「5,000」、「3,000」、「2,000」の請求配分になる。ここで前記例と異なり、前提となる口座の状態は図８であるから、口座番号８０１が「1111111」の口座残高８０３は「4,000」、前記負担額は「5,000」であるため「1,000」だけ残高不足となる。そのためステップＳ１１０へ進む。
前記判断Ｓ１１０において、結果が否定の場合、すなわち、すべての負担口座に自動補完サービスが契約されていない、サービスが契約されていて自動補完を実施したとしても残高不足額を補えそうにない(各負担口座の預金残高もしくは最高負担額の少ない方の総額を不足残高が上回る)などの理由により、自動補完が実施できない場合には取引を中止するステップＳ１０８へと進む。
【００３３】
これに対し、前記判定Ｓ１１０の結果が肯定の場合は、自動補完契約に基づく負担額の再計算を実施するため、ステップＳ１１１へと処理を移す。前記例の請求元が「Ａ電力」の場合では、図４より、前記契約ＩＤ４０１が「０００１」の負担口座において、少なくとも１つ以上の口座でサービスが契約されており、前記各負担口座の預金残高もしくは最高負担額の少ない方の総額を不足残高が上回ることがないため、自動補完により残高不足を補完できるため、前記判定Ｓ１１０は肯定となりステップＳ１１１へと進む。なお、Ｓ１０５〜Ｓ１０６〜Ｓ１１０〜Ｓ１１０〜Ｓ１１１のループが無限ループとならないように前記判定Ｓ１１０の条件は設定されるものである。
自動補完の設定により処理が戻されたステップＳ１１１では、負担額に対する残高不足分について、補完ＩＤ３０５に基づき不足補完方法を決定する。図３の例では、前記契約ＩＤ３０１が「0001」である取引について前記補完ＩＤ３０５は「C01」であると判断する。各口座の不足補完額の計算は、各負担口座の総残高不足額が補完額の合計と同じになるという条件を満たす任意のアルゴリズムや計算式で行うことが可能であるが、前記補完ＩＤ３０５を１つ指定することにより、あらかじめ用意しておいた複数のアルゴリズムや計算式の候補の中からただ１つ決定することによって計算方法を定める。
計算法決定後、前記ステップＳ１０５へと進む。前記Ｓ１１０において不足補完が可能な負担口座は既知であるから、Ｓ１０５では前記ステップＳ１１１において決定した補完方法に基づき各負担口座に対する負担額を決定する。なお、前記例のＳ１０５と同様、前記補完ＩＤ３０５に必要なデータは契約データベースや口座情報データベースより適宜読み込んで使用しても良い。
【００３４】
前記請求元２０１が「Ａ電力」の場合、前記説明の通り、負担口座「1111111」は残高が「1,000」不足している。本実施例ではこの不足分１０００を前記補完ＩＤ３０５が「C01」であるような補完処理によって、補完可能なすべての負担口座に対して補完額決定処理を実施する。補完ＩＤ６０１が「C01」の場合、図６に基づき、処理内容６０２により「あらかじめ定めた重みに従い、請求額を前記割合で按分する処理」を実行する。前記例の場合、補完可能な口座は「2222222」および「3333333」であるが、図４よりわかる「2222222」の重み「３」および「3333333」の重み「２」の比、すなわち「３：２」に従い、前記不足分「1,000」を「600」および「400」に按分してそれぞれに分担させる。前記例の負担額を考慮し、実際の請求額はそれぞれ「4,000」、「3,600」、「2,400」となる。
【００３５】
ステップＳ１０６では、前記分担は残高不足ではないから、その判定が否定となるため、この自動補完後の負担額により自動振替を実施する。なお、このときの自動補完額は、振込の際に口座間の賃貸関係に関するデータベースを更新するよって管理する。図９の例では、債権者口座番号９０１と債務者口座番号９０２に対して「2222222」と「1111111」の組については、貸付残高９０３は「600」、同様に、「3333333」と「1111111」の組については「400」をそれぞれ加算して管理する。
なお、自動補完に対する口座間の金銭貸借の解消は、月に１度、締日に実施する等により実施しても良いが、前記自動補完を応用し、次回の自動振替取引において貸与額を負担額に反映させることによって実質的に返済しても良い。
【００３６】
図１２を用いて自動補完分に対する自動返済を説明する。前記例におけるステップＳ１０５において、各口座間で金銭の貸借関係がないと仮定したが、賃貸関係があるものとして説明を行うことにする。今、請求元「Ａ電力」の口座番号「1111111」からの引落をすでに実施し、各口座の残額が図８となり、図９のような金銭貸借関係ができたことを仮定した上で「Ｂ水道局」による口座番号「2222222」への引落を実施することを例にする。
まず、自動補完がある場合でもない場合でも、Ｓ１０３までは図１０、図１１の処理と同じ処理を実施する。Ｓ１０４にて、請求元「Ｂ水道局」からの請求は処理IDがP1であることから「定率」で負担することがわかる。図４の契約ＩＤ「0002」を参照することでステップＳ１０５では口座番号「1111111」と「3333333」の２口座が定率による分担方法を実行することを決定し、定率により請求額「6,000」を「1:2」の比率で分担するように分負担額を算出する。すなわち、それぞれ「2,000」、「4,000」で分担し合うことを算出し、ステップＳ１０６へと移る。
【００３７】
ステップ１０６では、前記説明と同様、判断が肯定の場合、すなわち、各負担口座の残高と負担額の大小比較を実施し、残高不足となる負担口座が１つでもある場合は、ステップＳ１１０へ進む。一方、前記判断が否定の場合、すなわち、残高不足の負担口座が１つも無い場合は、ステップＳ１１２へと進む。前記の例では、負担口座「1111111」と「3333333」の残高はそれぞれ「4,000」、「5,000」であり、負担額はそれぞれ「2,000」、「4,000」であるから、前記判断Ｓ１０６は否定となり、ステップＳ１１２へと進む。
ステップＳ１１２では、すべての負担口座の組合せにおいて、貸借関係の有無を判断し、肯定の場合はステップＳ１１３を経由してステップＳ１０７へ進み、一方、否定の場合は直接前記ステップＳ１０７へと進む。貸借関係の有無は、貸借関係データベースにおいて債権者口座番号９０１と債務者口座番号９０２の組に対して、前記負担口座の組合せと同一のものがあるかないかによって判断する。前記の例であれば、負担口座「11111111」と「3333333」の組は図９の賃貸関係データベースの例において存在しているから肯定の判断となり、ステップＳ１１３へと進む。
【００３８】
ステップＳ１１３においては、負担口座間の貸借を無くすようにすべく負担額の修正を行う。貸借関係データベースより、前記負担口座の組合せにおける貸付残高を特定し、前記負担額と前記貸付残高を反映したものを新しい負担額とする。前記の例では、図９の債権者口座番号９０１の口座「3333333」と債務者口座番号９０２の口座「1111111」の間には貸付残高９０３に「400」の賃貸関係があるため、返済額を考慮した負担額算出を行う。返済額を含む負担額算出は、前記貸付残高９０３を下回るのであればどのように決定しても良い。ここでは、仮に全額を一括して返済するものとすると、前記例の債務者口座「1111111」の負担額「2,000」と前記賃貸の残高（債務金額）「400」の和「2,400」は、その残高「4,000」よりも小さい方ため、前記和「2,400」を修正後の新しい負担額と決定する。（前記残高の方が前記の負担額と債務金額の和より小さいときは前記残高が負担額となる。）なお、前記例の債権者口座「3333333」の負担額「4,000」と前記賃貸の残高（債権金額）「400」の差「3,600」を新たな負担額とする。
【００３９】
新たな負担額算出後、ステップＳ１０７へと進む。そして、前記ステップＳ１０７にて前記例におけるステップＳ１０７と同様、実際に振込みを実施した後、返済額の反映を賃貸データベースに反映した上で、取引を終了する。
なお、ここでの支払口座は誰かが保有する実態のある口座として説明してきたが、これを「仮想口座」として扱っても良い。ここで言う仮想口座とは、実際に銀行と預金者が預金契約等の手続きを行って開設され残高が発生する口座ではなく、本サービス専用で残高を持たずに口座振替用の口座番号を有する口座を指している。支払口座が仮想口座であっても良い理由は、本発明における支払口座は必ずしも同時に負担口座である必要はなく、残高を持つ必要が無いからである。
支払口座を仮想口座にすることの利点は、複数の預金者同士が支払いを負担する場合に誰か１人の口座を支払口座にする必要があること、プライバシーを気にすることなく取引明細を負担者全員で閲覧することが可能であること、などがある。
【産業上の利用可能性】
【００４０】
以上の説明の通り、本発明によって、請求額を負担口座に対して適切に分担させることが可能となり、また、不足額を自動で補完しあって支払口座に対して自動的に振替ることにより、負担者の振込の手間と支払者の未収リスクを軽減することが可能である。また、銀行においても本サービスに対する任意の手数料を設定し、手数料収入を得ることができる。
【図面の簡単な説明】
【００４１】
【図１】本発明に係る複数口座間動的振替制御システムの実施例の構成図。
【図２】請求元別の取引データベースのフォーマットを示す図。
【図３】請求元別の契約インデックスデータベースのフォーマットを示す図。
【図４】契約データベースのフォーマットを示す図。
【図５】処理ＩＤと処理内容の対応関係の例を説明した図。
【図６】補完ＩＤと補完内容の態様関係の例を説明した図。
【図７】口座情報データベースのフォーマットを示す図。
【図８】口座情報データベースのフォーマットを示す図。
【図９】口座間の貸借関係データベースのフォーマットを示す図。
【図１０】複数口座間動的振替制御システムを示すフローチャート。
【図１１】負担口座間自動補完機能付複数口座間動的振替制御システムのフローチャート。
【図１２】負担口座間自動補完機能及び自動返済機能付複数口座間動的振替制御システムのフローチャート。
【符号の説明】
【００４２】
１０１  判定装置
１０２  演算装置
１０３  記憶装置
１０４  入力装置
１０５  出力装置
１０６  通信装置
１０７  取引データベース
１０８  契約インデックスデータベース
１０９  契約データベース
１１０  口座情報データベース
１１１  貸借情報データベース
【図１】
2006343903.tif 000003
【図２】
2006343903.tif 000004
【図３】
2006343903.tif 000005
【図４】
2006343903.tif 000006
【図５】
2006343903.tif 000007
【図６】
2006343903.tif 000008
【図７】
2006343903.tif 000009
【図８】
2006343903.tif 000010
【図９】
2006343903.tif 000011
【図１０】
2006343903.tif 000012
【図１１】
2006343903.tif 000013
【図１２】
2006343903.tif 000014