(57)【要約】【課題】残高不足の防止と代替支払の容易化。【手段】支払管理装置１が支払者端末３に提供する引落予定一覧表示画面上で、支払者の口座から引き落とされる予定の支払一覧を表示する。同日中の支払については、例えば優先的に引き落とされる順に表示される。残高不足で引き落としができなかった支払についても表示される。支払者は、各支払について、支払先企業が定める支払ルールに従う範囲で支払を行うことができる。支払ルールとは、支払手段、支払期日、ペナルティの有無など、引き落としに代わる代替支払を実行するための支払条件の選択肢を含む。支払ルールは、基本的に、各企業から各支払者に対して設定されている。支払者の支払実績に応じ、企業側が設定した支払ルールが企業の許容する範囲で変更されても良い。【選択図】      図３
2004295302.tif 000002
【特許請求の範囲】
【請求項１】
企業に代金の支払いを行う支払者のコンピュータ及び前記企業のコンピュータとネットワークを介して接続可能な支払管理装置に用いられる支払管理方法であって、
前記支払者の口座からの支払予定を記憶する予定記憶ステップと、
前記支払予定に従い、前記支払者の口座から引き落としを実行する引き落としステップと、
前記支払予定通りに実行できない引き落としが生じた場合に前記支払者に引き落としに代わる代替支払を実行してもらうための前記企業の支払ルールを記憶するルール記憶ステップと、
前記ルール記憶ステップで記憶されている前記支払ルールを、前記支払者のコンピュータに送信する通知ステップと、
を含む、支払管理方法。
【請求項２】
前記企業のコンピュータから前記支払ルールの設定及び／または更新を受け付けるルール更新ステップをさらに含む、請求項１に記載の支払管理方法。
【請求項３】
前記支払者の支払実績を記憶する履歴ステップと、
前記支払者の過去の支払実績に基づいて、前記支払者の評価を行う評価ステップと、
前記支払者の評価結果に基づいて前記支払ルールを変更する基準となる評価反映ルールを記憶する評価反映ルール記憶ステップとをさらに含み、
前記ルール更新ステップは、前記評価ステップにおける評価結果と前記評価反映ルールとに基づいて、前記支払者に適用される支払ルールを設定及び／または更新する、
請求項２に記載の支払管理方法。
【請求項４】
企業に代金の支払いを行う支払者のコンピュータ及び前記企業のコンピュータにネットワークを介して接続可能な支払管理装置であって、
前記支払者の口座からの支払予定を記憶する予定記憶手段と、
前記支払予定に従い、前記支払者の口座から引き落としを実行する引き落とし手段と、
前記支払予定通りに実行できない引き落としが生じた場合、前記支払者に引き落としに代わる代替支払を実行してもらうための支払ルールを記憶するルール記憶手段と、
前記ルール記憶手段で記憶されている前記支払ルールを、前記支払者のコンピュータに送信する通知手段と、
を備える支払管理装置。
【請求項５】
企業に代金の支払いを行う支払者の第１コンピュータ及び前記企業の第２コンピュータにネットワークを介して接続可能な第３コンピュータを機能させる支払管理プログラムであって、
前記支払者の口座からの支払予定を記憶する予定記憶手段、
前記支払予定に従い、前記支払者の口座から引き落としを実行する引き落とし手段、
前記支払予定通りに実行できない引き落としが生じた場合、前記支払者に引き落としに代わる代替支払を実行してもらうための支払ルールを記憶するルール記憶手段、及び
前記ルール記憶手段で記憶されている前記支払ルールを、前記支払者のコンピュータに送信する通知手段、
として前記第３コンピュータを機能させる支払管理プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、商品・サービスの購入者がネットワークを介して購入代金を支払うための代金支払技術に関する。
【０００２】
【従来の技術】
特許文献１には、支払者が自らの判断で支払金額や支払日を決定でき、かつ、実際の代金支払も容易に行える代金支払システムが提案されている。このシステムにおいては、支払者に支払いの自由を与えている点で、一定の効果が認められる。また、特許文献２には、顧客は複数の支払い項目に優先順位を指定できる口座振替管理方法が提案されている。この方法を用いれば、例えば一月間の口座引き落としにおいて当該口座が残高不足となる場合は、顧客の指定する優先順位順で口座引き落としされる。
【０００３】
代金の支払いを金融機関に委託している企業にとって、残高不足により口座から代金の引き落としができないことは問題である。なぜなら、企業にとっては、代金が未決済となった場合の再請求のための事務処理や料金収受データの管理に、かなりの労力と通信費をはじめとする費用を発生させているからである。このような企業としては、例えばクレジットカード会社、電話や水道・ガスなどを提供している公共事業会社が挙げられる。残高不足の発生は支払者にとっても、残高不足の発生は労力がかかり好ましくない。
【０００４】
例えば、口座引き落としができなかった支払者に対し、○年○月○日に○○円の引落しができなかったことや、代替支払手段などを通知する必要がある。そのために、通知文書を作成し、これを郵送するなどの通信コストが企業側には生じる。
また例えば、口座引き落としができなかった支払者に対し、振込による支払いを企業が提案する場合がある。この場合、振込先口座番号の案内や請求書の管理番号を明記して振り込んでもらうことを、企業は支払者に依頼する。しかし実際には、企業の依頼通りの情報を明記して振り込みが実行されるとは限らない。そのような場合には、振込人の特定に労力が発生する。
【０００５】
さらに、口座振替不能となり、支払者からの電話による問合せが企業に行われた場合の労力を考えてみる。通常、支払者本人からの問い合わせであることを確認するために、企業は個人情報を確認する。しかし電話した人が支払者本人の配偶者である場合、話者は配偶者からの依頼で電話しているとしても、話者は支払者本人とは認定されず、問い合わせに応じてもらえない。これでは、企業の業務時間内に電話できない支払者にとっては、家族に問い合わせの代行を頼むこともできず、不便である。その不便さが、口座振替以外の他の手段による支払いの遅延を呼び、企業にとっても不利益を生ずる。
【０００６】
【特許文献１】特開２０００−２２７９３７号公報
【０００７】
【特許文献２】特開２００２−１６３４５８号公報
【０００８】
【発明が解決しようとする課題】
前記特許文献１に記載の代金支払いシステムは、支払者の支払の自由度を高めている。しかし、月毎の支払予定は変動するのが通常であり、支払者が全ての支払予定を把握しきれていない場合、残高不足が生じることがある。また、このシステムでは、残高不足が発生した後の企業・支払者の労力を改善することは難しい。前記特許文献２に記載の口座振替管理方法では、支払者が最も大事と考える支払から優先的に実行できる。しかし、毎月変わる全ての支払予定を支払者が把握することは難しく、全ての支払予定を把握できていないために、重要な支払ができなかったり、重要でない支払が実行されるという問題が生じる。また、この方法では、残高不足が発生した後に企業・支払者に生じる労力を軽減することは難しい。
【０００９】
さらに、残高不足後の支払に対しては、支払を促進しつつ企業の意志を反映させたいというニーズがある。例えば、引き落としに代えて振込による支払を企業から支払者に依頼する場合には、支払者がなかなか振り込まないことによる集金の遅れが生じる場合がある。このような場合に、企業から支払者に対し、振込を促進できる手段が望まれている。また、支払者の中にも、なかなか代金を振り込んでくれない人、すぐに代金を振り込んでくれる人など、さまざまである。なかなか代金を振り込まない支払者に対しては、企業としては振込以外の他の支払手段を提案したいという要望がある。しかし、残高不足を防ぎ、残高不足発生後の支払の労力を軽減し、支払者の支払意欲を促進しながら企業の意志を支払に反映させると言う全ての要望を満たす技術は、未だ提供されていない。
【００１０】
本発明は、支払者の口座に残高不足が生じることによる引き落とし不能の発生を防ぐ技術を提供することを目的とする。
また本発明は、支払者が自分自身の支払予定を管理することを容易にする技術を提供することを目的とする。
また本発明は、残高不足が発生した後の企業・支払者双方の労力を軽減する技術を提供することを目的とする。
さらに本発明は、支払を促進しつつ、企業の意志を反映する支払を支払者に行わせる技術を提供することを目的とする。
【００１１】
【課題を解決するための手段】
前記課題を解決するために、本願第１発明は、企業に代金の支払いを行う支払者のコンピュータ及び前記企業のコンピュータとネットワークを介して接続可能な支払管理方法であって下記ステップを含む支払管理方法を提供する。
・前記支払者の口座からの支払予定を記憶する予定記憶ステップ、
・前記支払予定に従い、前記支払者の口座から引き落としを実行する引き落としステップ、
・前記支払予定通りに実行できない引き落としが生じた場合に前記支払者に引き落としに代わる代替支払を実行してもらうための前記企業の支払ルールを記憶するルール記憶ステップ、
・前記ルール記憶ステップで記憶されている前記支払ルールを、前記支払者のコンピュータに送信する通知ステップ。
【００１２】
本願第２発明は、前記第１発明において、前記企業のコンピュータから前記支払ルールの設定及び／または更新を受け付けるルール更新ステップをさらに含む支払管理方法を提供する。
本願第３発明は、前記第２発明において、下記ステップをさらに含む支払管理方法を提供する。
・前記支払者の支払実績を記憶する履歴ステップ、
・前記支払者の過去の支払実績に基づいて、前記支払者の評価を行う評価ステップ、
・前記支払者の評価結果に基づいて前記支払ルールを変更する基準となる評価反映ルールを記憶する評価反映ルール記憶ステップ。
この方法において、前記ルール更新ステップは、前記評価ステップにおける評価結果と前記評価反映ルールとに基づいて、前記支払者に適用される支払ルールを設定及び／または更新する。
【００１３】
本願第４発明は、企業に代金の支払いを行う支払者のコンピュータ及び前記企業のコンピュータにネットワークを介して接続可能な支払管理装置を提供する。この装置は、以下の手段を含む。
・前記支払者の口座からの支払予定を記憶する予定記憶手段、
・前記支払予定に従い、前記支払者の口座から引き落としを実行する引き落とし手段、
・前記支払予定通りに実行できない引き落としが生じた場合、前記支払者に引き落としに代わる代替支払を実行してもらうための支払ルールを記憶するルール記憶手段、
・前記ルール記憶手段で記憶されている前記支払ルールを、前記支払者のコンピュータに送信する通知手段。
【００１４】
本願第５発明は、企業に代金の支払いを行う支払者の第１コンピュータ及び前記企業の第２コンピュータにネットワークを介して接続可能な第３コンピュータを機能させる支払管理プログラムを提供する。このプログラムは、前記第３コンピュータを下記の手段として機能させる。
・前記支払者の口座からの支払予定を記憶する予定記憶手段、
・前記支払予定に従い、前記支払者の口座から引き落としを実行する引き落とし手段、
・前記支払予定通りに実行できない引き落としが生じた場合、前記支払者に引き落としに代わる代替支払を実行してもらうための支払ルールを記憶するルール記憶手段、
・前記ルール記憶手段で記憶されている前記支払ルールを、前記支払者のコンピュータに送信する通知手段。
【００１５】
【発明の実施の形態】
＜第１実施形態例＞
［概要］
図１は、本発明に係る支払管理装置を含んで構成される支払管理システムの全体構成図である。支払管理装置１は、企業端末２及び支払者端末３とネットワーク４を介して通信可能である。支払管理装置１は、例えば銀行に設置されたコンピュータであり、企業に代わり決済処理を行う。図示していないが、支払管理装置１は例えば銀行の各支店に設置されたＡＴＭ端末と直接または間接的に通信できても良い。企業端末２とは、商品やサービスの提供者などが管理するコンピュータである。支払者端末３とは企業へ商品やサービスの対価を支払う支払者が管理するコンピュータである。図中、企業端末２及び支払者端末３は１つずつしか示していないが、通常は複数個存在する。
【００１６】
図２は、支払管理装置１の機能構成を示すブロック図である。支払管理装置１は、メモリ上にＤＢ群１００を有し、ＣＰＵ上で各種モジュール群１０を実行する。ＤＢ群１００及び各種モジュール群１０については詳細を後述する。
図３は、支払管理装置１が支払者端末３に提供する引落予定一覧表示画面の一例である。この画面上には、支払者の口座から引き落とされる予定の支払が、例えば日付の近い順に表示される。同日中の支払については、例えば優先的に引き落とされる順に表示される。また、残高不足で引き落としができなかった支払についても表示される。支払者は、各支払について、支払先企業が定める支払ルールに従う範囲で支払を行うことができる。支払ルールとは、支払手段、支払期日、ペナルティの有無など、引き落としに代わる代替支払を実行するための支払条件の選択肢を含む。支払ルールは、支払ルールウインドウＷｐに示されている。また、各支払についての支払ルールの詳細は、各支払を選択して例えばダブルクリックすることにより表示される。支払ルールは、基本的に、各企業から各支払者に対して設定されている。支払者の支払実績に応じ、企業側が設定した支払ルールが企業の許容する範囲で変更されても良い。
【００１７】
支払ルールを支払者に明示するために、支払管理装置１は大別して下記の処理を行う。
（１）契約内容の登録：企業と支払者との間の支払契約の登録受付
（２）支払ルールの登録・更新：企業が支払者に適用する支払ルールの登録受付
（３）支払者の実績の評価：支払者の支払実績の評価
（４）顧客要望の登録：引き落としに関する支払者の要望の登録受付
（５）支払条件の選択受付：支払ルールの範囲での支払条件の選択受付
（６）その他の処理
・引き落とし不能の通知
・出金監視処理による残高不足発生の予測とその警告
・日時処理による残高不足の予測とその警告
・振込予定の通知。
【００１８】
図３に例示するように、支払についての企業の意志を支払ルールという形で支払者に明示することにより、引き落としができなかった場合の集金に要する企業側の労力を軽減することができる。また、支払者は支払ルールに沿って支払条件を選択すれば再度の支払を実行できるので、引き落としができなかった場合の支払者側の再支払に要する労力を軽減することができる。引き落としの予定一覧を支払者に明示することにより支払者による残高管理を容易化し、残高不足を事前に防止することができる。支払ルールに必要に応じてペナルティを明示することにより、企業の意志に沿った支払を促進することができる。
【００１９】
［機能］
次に、支払管理装置１の機能について図面を参照して順次説明する。
（１）契約内容の登録
支払管理装置１は、企業と支払者との間の支払契約の登録を受け付ける。図４（Ａ）は、評価モジュール１６が企業端末２に提供する契約内容登録画面の一例である。評価モジュール１６は、前記モジュール群１０に含まれるモジュールである。後述するように契約内容を基に支払者の支払実績の評価を行う場合、契約内容の登録が必要となる。契約内容としては、請求サイクル、支払猶予の有無、ブラックリストへの登録の有無などが挙げられる。
【００２０】
図４（Ｂ）は、登録された契約内容を記憶する契約テーブル１０４ａの概念説明図である。契約テーブル１０４ａは、前述したＤＢ群１００の中の評価ＤＢ１０４に記憶される。契約テーブル１０４ａの１レコードには、企業を識別する企業ＩＤ、支払者を識別する支払者ＩＤ、各契約を識別する契約ＩＤが契約内容と共に記憶される。
（２）支払ルールの登録・更新
（２−１）支払ルールの登録・更新
支払管理装置１は、企業が支払者に適用する支払ルールの登録やその更新を受け付ける。支払者に対する企業の支払ルールの設定や更新を企業から受け付けることにより、各企業によって異なる企業の意志やその変更を取引に反映させることができる。具体的には、前記モジュール群１０の中の支払ルール更新モジュール１５は、支払ルールの登録や更新を行い、支払ルールＤＢ１０２に支払ルールを格納する。支払ルールＤＢ１０２は、前記ＤＢ群１００の中に含まれている。
【００２１】
図５〜図７は、支払ルール更新モジュール１５が企業端末２に提供する支払ルールの登録画面例である。図５（Ａ）では、残高不足により引き落としできなかった場合に、企業が支払者に対して許容する支払手段の登録を受け付ける。企業は複数の支払手段を登録することができる。またこの画面は、支払者に対してペナルティを課すかどうかについての登録も受け付ける。図５（Ｂ）、（Ｃ）は、登録された支払手段「再引落」をいつ行うかを、企業と支払者との契約に従って設定する画面例である。図６は支払手段として「振込」を登録する場合、図７は支払手段として「持参」を登録する場合の画面例である。登録される支払手段に応じ、登録すべき事項は若干異なっている。このようにして登録された支払ルールは、支払ＤＢ１０２中に、企業ＩＤ及び支払者ＩＤと関連付けて記憶される。
【００２２】
登録された支払ルールをそのまま支払者に適用する場合、支払ルールはさらに支払予定ＤＢ１０１に書き込まれる。図８（Ａ）は、前記ＤＢ群１００に含まれる支払予定ＤＢ１０１が蓄積する支払データの概念説明図である。支払データは、（ａ）支払を特定する各種情報、（ｂ）支払ルール、（ｃ）支払の状態を示す「処理フラグ」を含む。支払を特定する各種情報とは、例えば支払者ＩＤ、処理日、猶予期日、企業ＩＤ、契約ＩＤ、金額、支払データ管理番号、口座情報である。支払ルールは、図８の例では、引き落としに失敗した場合の支払手段として許可されているのは「振込」だけであり、「再引き落とし」及び「持参」は許可されていない。図８（Ｂ）は、「処理フラグ」がとりうる値とその値が示す支払状態を示す。例えば処理フラグ「不能」は、引き落としができず、その後の支払予定が未定であることを示す。また例えば処理フラグ「確認」は、予定されている引き落としの実行を支払者が確認したことを示す。
【００２３】
前述の情報に加え、さらに支払データは、同じ日に引き落とされる支払の中での優先順位を示す「同日順位」を含むと良い。優先順位は、前記顧客要望の登録に従い設定される。優先順位は、引き落としの実行順序の決定や引き落とし予定の支払のソートに用いることができる。これらに加え、支払データは、引き落とし不能の場合のペナルティの有無を含むこともできる。
（２−２）支払者の評価による支払ルールの変更
企業が登録した支払ルールをそのまま適用するのではなく、支払者の支払実績に応じて変更しても良い。優良な支払者にとっては選択できる支払条件の幅が広がり、支払実績の悪い支払者にとっては選択できる支払条件の幅が狭くなる。こうすることで、支払者間での不公平感をなくすことができる。そればかりか、残高不足や支払の遅滞を防止するインセンティブを支払者に提供することができる。
【００２４】
具体的には、前記支払ルール更新モジュール１５は、支払者の評価結果と評価反映ルールとに基づいて、前記支払者の支払ルールを設定及び／または更新する。支払者の評価は、前記評価モジュール１６が、前記支払者の過去の支払実績に基づいて行う。支払者の評価は、後述するように、支払実績をポイントに換算することにより行うことができる。前記支払者の支払実績は、前記ＤＢ群１００に含まれる顧客履歴ＤＢ１０３に記憶しておく。支払者の評価方法については詳細を後述する。評価反映ルールは、前記評価ＤＢ１０４中の評価反映ルールテーブル１０４ｂに記憶されている。評価反映ルールは、前記支払者の評価結果に基づいて前記支払ルールを変更する基準である。評価反映ルールは、例えば、ポイントが高くなるほど支払手段や日時の選択肢の幅が広がるように設定しておくとよい。
【００２５】
図９は、支払ルール更新モジュール１５が企業端末２に提供する評価反映ルール設定画面例である。この画面は、ポイントに応じた支払ルールの選択幅の設定を受け付ける。例えば、この図においては、ポイントが０〜２０の範囲の支払者に許可される支払手段は、「持参払い」、「コンビニ払い」のいずれかである。設定された評価反映ルールは、評価ＤＢ１０４の評価反映ルールテーブル１０４ｂに企業ごとに蓄積される。
（３）支払者の実績の評価
（３−１）評価方法
支払管理装置１は支払者の支払実績の評価を行う。評価結果は、前述したように、支払者に適用する支払ルールの変更に用いられる。
【００２６】
支払者の評価は、例えば支払実績をポイントに換算することにより行うことができる。支払実績をポイントに換算するためのポイント算出条件を、予め記憶しておくか、企業からその登録を受け付けて登録内容を記憶しておくと良い。ポイント算出条件の設定を受け付けることにより、各企業は自社が重視する観点に従って顧客を評価することができる。一例として、優良率や遅滞率、稼働率などの重み付けや比率の指定を受け付けることが挙げられる。ここで、優良率は、過去の支払が支払予定通りに行われている確率を示す。遅滞率は、支払が遅れた場合に契約で定められた次の支払日を遅滞した確率を示す。稼働率は、支払の頻度や支払の回数、支払年月の長さなどを示す。
【００２７】
以下に支払実績をポイントに換算する具体例を説明する。図１０（Ａ）は、前記ＤＢ群１００に含まれる顧客履歴ＤＢ１０３に蓄積されている履歴データの概念説明図である。履歴データは、評価結果であるポイントの算出の基礎となる。具体的には、履歴データは、最新の評価結果である「ポイント」及び支払実績を含む。支払実績は、ポイントを算出するのに必要なデータを含み、契約タイプに応じて異なる。この図では、前記優良率を算出するための「初回支払回数」、前記遅滞率を算出するための「猶予期限内支払回数」、前記稼働率を算出するための「支払回数」が、支払実績として記憶されている。
【００２８】
図１０（Ｂ）は、前記評価モジュール１６が企業端末２に提供する評価条件設定画面例である。前記評価モジュール１６は、支払者の支払実績を評価するための評価条件の設定を受け付け、設定された評価条件に従って前記支払者の評価を行う。この図では「稼働率と優良率との重み付け」、「稼働率算出重み付け」、「稼働率算出時の更新前実績ＭＡＸ」の設定を受け付けているが、評価条件はこの例に限定されない。設定された評価条件は、同図（Ｃ）に示すポイント算出条件管理テーブル１０４ｃとして、各支払者及び企業ごとに評価ＤＢ１０４に蓄積される。
【００２９】
図１１は、図１０で設定した評価条件による支払者のポイントの算出例を示す。同図（Ａ）は、月次払いのカードタイプの契約による支払実績の評価を示す。同図（Ｂ）は、半年払いの定期タイプの契約による支払実績の評価を示す。同図（Ｃ）は、月次払いの１２回払いを毎年更新する契約による支払実績の評価を示す。また図１２には、稼働率と優良率との重み付けを変えた場合のポイントの変化を示す。重み付けを変えても、優良率が高い支払者のポイントが高くなることが分かる。
【００３０】
図１１においては、ポイントの算出は次式により行っている。下式は、初回支払日に確実に引き落としが実行できている割合、すなわち優良率が高い支払者ほどポイントが高くなるように設定されている。また下式は支払者の支払回数や企業との契約年数が多いほど、すなわち稼働率が高いほどポイントが高くなるように設定されている。ただしこの算出方法は一例であり、この方法に限定されない。
ポイント＝（稼動率×α＋（優良率−遅滞率）×β）÷（α＋β）
ここで、α及びβは稼動率と優良率との重み付けを表し、（稼働率）：（優良率）＝α：βである。
【００３１】
前記稼働率（％）、優良率（％）、遅滞率（％）は次のように算出される。
2004295302.tif 000003
ここでｘ及びｙは更新前実績と今回実績との重み付けを表し、（更新前実績）：（今回実績）＝ｘ：ｙである。
遅滞率＝（１−期限までの支払い実績回数／請求回数）×１００
優良率＝初回支払い回数／請求回数×１００
（３−２）再評価
支払者のポイントは、支払者の支払実績が変化すると、その変化を反映することが好ましい。そのためには顧客の実績を適切なタイミングで再評価する必要がある。具体的には、前記評価モジュール１６は、後述する出金モジュール１３（引き落とし手段）による引き落としの試行後、引き落としの試行結果に基づいて支払者のポイントを再計算するとよい。再計算した結果、例えばポイントが「２０」から「２１」に上がったとする。この場合、支払ルールに「振込」が設定されていれば、前記図９に例示する評価反映ルールに基づいて、「振込」が新たな代替支払手段として追加される。逆に、例えばポイントが「１９」から「２０」に上がった場合、図９に例示する評価反映ルールに基づけば新たな代替支払手段の追加はない。従ってこの場合は再評価しても支払ルールは更新されない。再評価のタイミングはこの例に限定されず、例えば毎日１回など定期的に行うことも可能である。
【００３２】
（４）顧客要望の登録
支払管理装置１は、引き落としに関する支払者の要望の登録を受け付けるとよい。例えば、どの引き落としを優先的に行うかという引き落としの優先度の設定を受け付けることが挙げられる。具体的には、要望登録モジュール１７は、引き落としに関する支払者の要望の設定を支払者のコンピュータから受け付け、これを顧客要望ＤＢ１０６に蓄積する。また、設定された要望は、要望登録モジュール１７により支払予定ＤＢ１０１に反映される。出金モジュール１３は、設定された要望、例えば優先順序に従い、引き落としを実行する。これにより、支払者は自分が重要視する支払から優先的に引き落としてもらうことができる。なお、この実施形態では、出金モジュール１３は、引き落としだけでなく、現金の引き出しや口座振り込みなど他の出金処理も管理する。要望登録モジュール１７及び出金モジュール１３は前記モジュール群１０に、顧客要望ＤＢ１０６は前記ＤＢ群１００に、それぞれ含まれている。
【００３３】
図１３（Ａ）は、要望登録モジュール１７が支払者端末３に提供する顧客要望登録画面の一例である。支払者は、この画面において、「引き落とし不能になるとペナルティがつく支払の優先度を最も高くする」、「再引き落としができない支払の優先度を２番目に高くする」などの優先度を設定可能である。なお、優先度の設定の仕方や顧客の要望は、この例に限定されない。同図（Ｂ）は、顧客ＤＢ１０６に支払者ごとに蓄積される要望データの概念説明図である。設定された要望に基づいて、支払予定ＤＢ１０１の「同日順位」が設定される（前記図８参照）。
【００３４】
（５）支払条件の選択受付
（５−１）支払条件の通知と選択
支払管理装置１は、支払ルールの範囲での支払条件の選択を受け付ける。具体的には、出金モジュール１３は、支払予定ＤＢ１０１内の支払予定に従い、引き落としを実行する。通知モジュール１４により、支払者の口座からの引き落とし予定の一覧と、各支払について適用される支払ルールとを表示する画面を、支払者端末３に提供する。提供する支払ルールは、前述したように、引き落としに代わる代替支払を実行するための支払条件の選択肢を含む。さらに通知モジュール１４は、支払の選択と、選択された支払についての支払条件の選択と、を前記支払者のコンピュータから受け付ける。通知モジュール１４は、選択された支払条件に従い、引き落としを実行できなかった支払について支払予定を書き換える。出金モジュール１３は、その後、更新された支払予定に従い、引き落としを実行する。
【００３５】
図１４〜図１８は、通知モジュール１４が支払者端末３に提供する引落予定一覧表示画面及び契約別情報詳細表示画面の一例である。引落予定一覧表示画面には、支払者の口座から引き落とされる予定の支払一覧が表示されている。また、各支払の引き落としが不能の場合、どの支払手段による支払が可能かが表示されている。支払一覧は、例えば日付順にソートされている。同日に処理される支払は、支払者が設定している要望、例えば優先順位順にソートされている。契約別情報詳細表示画面には、引落予定一覧表示画面で選択された支払に適用される支払ルールの詳細が表示されている。表示される支払ルールは、通知モジュール１４が、企業が支払者に対して登録した支払ルールと、企業の評価反映ルールと、支払者のポイントとに基づいて算出した支払ルールである。
【００３６】
図１４の引落予定一覧表示画面において支払を選択し、その支払の契約別情報詳細表示画面において「確認」ボタンを押すと、図１５の画面に移行する。「持参登録」ボタンを押した場合は図１６へ、「引落中止」ボタンを押した場合は図１７へ、「振込」ボタンを押した場合は図１８へ、それぞれ移行する。支払者は、引落予定一覧表示画面及び契約別情報詳細表示画面において、引き落とし不能となった支払やこれから引き落とされる支払について、支払条件を変更することができる。支払者にとっては、どうすれば支払いできるかがすぐに分かるので再支払を労力をかけずに実行できる。また、企業にとっては、支払者に許可している範囲での方法により、労力をかけずに集金することができる。
【００３７】
（５−２）支払条件に振込を選択した場合
支払管理装置１は、支払者が支払条件として「振込」を選択した場合、支払者及び企業の双方に負担のない振込を実現する。具体的には、ＤＢ群１００に含まれる口座ＤＢ１０５により、支払者の口座の残高を記憶する。出金モジュール１３は、代替支払の支払条件として口座振込が選択された場合、支払予定ＤＢ１０１に記憶されている支払者ＩＤ及び企業ＩＤを用い、口座振込を実行する。このようにすれば、引き落としできなかった支払を振込により再度行う場合、支払者は振込先や振込人などという情報を入力することなく振り込みを実行できる。また、企業側は、誰からの振込かを容易に判別できる。支払者ＩＤとして、支払者の氏名やその口座番号を組み合わせて用いてもよい。また企業ＩＤとして、企業の名称やその口座番号を組み合わせて用いてもよい。
【００３８】
（５−３）予約
支払管理装置１は、引き落としの予約を受け付け、他の出金処理よりも予約された引き落としを優先すると良い。予約された引き落としに必要な金額は、他の出金処理、例えば現金の引き出し、口座振込、他の引き落としよりも優先され、擬似的に貯蓄される。
図１９（Ａ）は、前記図１４（Ｂ）において「予約」ボタンを押すと表示される画面例である。通知モジュール１４は、この画面上で、選択されている引き落としの予約を確認する。予約が確認されると、引き落とし予定一覧表示画面は、同図（Ｂ）に示す状態に変化する。予約された引き落としには、予約を示す印「予約済」が表示されている。同図（Ｃ）は、予約済みの支払についての契約別情報詳細表示画面である。この画面は、予約を解除するための「予約解除」ボタンによる予約の解除を受け付ける。
【００３９】
具体的には、通知モジュール１４は、前記引落予定一覧表示画面において１または複数の引き落としの予約を受け付ける。通知モジュール１４は、予約された引き落としの実行に必要な残高があるか否かを、口座残高を参照して判断する。また通知モジュール１４は、支払予定ＤＢ１０１を更新し、予約を書き込む。入金モジュール１２及び出金モジュール１３からなる口座管理ユニット１１は、前記口座に対する入出金を管理し、予約された引き落としに必要な金額を優先的に確保する。ここで、入金モジュール１２は、支払者の口座への入金処理、例えば他の口座からの振込や現金による入金を行う。
【００４０】
支払者は、絶対に引き落としを実行してもらいたい支払を予約しておくことにより、その引き落としに必要な資金を他の処理よりも優先的に確保することができる。例えば、支払者自身による現金の引き出しよりも予約引き落としが優先される。また、他の引き落としよりも予約引き落としが優先されるため、別の引き落としと予約引き落としとの両方を実行するのに足りる残高がない場合には、別の引き落としは実行されない。このようにすれば、重要な支払が残高不足により実行不可となることを防止することができる。
【００４１】
通知モジュール１４は、予約引き落としの予約の解除を受け付けてもよい。その場合、口座管理ユニット１１は、予約が解除された引き落としに必要な金額の確保を解除する。引き落としの予約の解除を受け付けることにより、支払者の利便性を高めることができる。
（５−４）顧客要望の変更
支払管理装置１は、引落予定一覧表示画面上で支払者の要望の変更を受け付けても良い。図２０は、通知モジュール１４が、ドラッグ＆ドロップにより支払順序の変更を受け付ける画面例である。
【００４２】
具体的には、通知モジュール１４は、引落予定一覧表示画面上で支払者の要望の変更を受け付け、支払予定ＤＢ１０１を更新する。出金モジュール１３は、更新された優先度に従って引き落としを実行する。支払者は、例えば自分が設定した優先度順にソートされた支払予定のリストを見て、優先度を変更することができる。これにより、支払者が通常想定していないが重要な支払を、滞りなく優先的に行うことができる。
（６）その他の処理
（６−１）引き落とし不能の通知
支払管理装置１は、引き落とし不能を予測し、支払者に通知すると良い。具体的には、口座管理ユニット１１が、支払予定ＤＢ１０１に記憶されている支払予定に従い、引き落としを実行すると残高が不足するか否かを判断する。この判断は、口座の残高及び入金予定に基づいて、引き落としに先立って行われる。次いで口座管理ユニット１１は、残高不足が生じると判断すると、支払者端末３に対して残高不足予測通知を送信する。この通知は、例えば電子メールにより行うことができる。通知を電子メールで行う場合、ＤＢ群１００のいずれかに支払者端末３の電子メールアドレスを蓄積しておく。残高不足を予測して事前に支払者に通知することにより、残高不足の発生を未然に防ぐことができる。
【００４３】
（６−２）出金監視処理による残高不足発生の予測とその警告
支払管理装置１は、引き落とし以外の出金処理による残高不足を予測し、支払者に通知すると良い。具体的には、口座管理ユニット１１は、支払者の口座からの出金要求を受け付けると、要求された出金額を出金してもいいか否かを判断する。すなわち、下記式（１）が成立する場合、口座管理ユニット１１は警告メッセージを出力する。出力先は、出金要求処理が入力された端末であり、支払者端末３や銀行のＡＴＭ端末が考えられる。
（（口座残高）−（予約引き落としに必要な金額）＋（予約引き落とし処理日までに入金予定額））＜（出金要求額）      ・・・（１）
（６−３）日時処理による残高不足の予測とその警告
支払管理装置１は、毎日、翌営業日の引き落としによる残高不足の発生を予測し、支払者に通知すると良い。具体的には、口座管理ユニット１１は、支払予定ＤＢ１０１を参照して引き落とし予定額を算出する。また、口座管理ユニット１１は、支払者の口座への振込予定から入金予定額を算出する。口座管理ユニット１１は、下記式（２）が成立する場合、支払者端末３に警告メッセージを送信する。送信方法は、前述と同様に電子メールを用いることが挙げられる。
【００４４】
（残高）＋（入金予定額）＜（引き落とし予定額）  ・・・（２）
（６−４）振込予定の通知
支払管理装置１は、振込予定を支払者に通知しても良い。具体的には、口座管理ユニット１１が支払者への口座の入金を予測すると、支払者端末３に入金予測通知を送信する。送信方法は前述と同様に電子メールを用いることが挙げられる。例えば企業から顧客の口座に保険給付金の振込が行われる場合、支払者の口座に対する「振込予定情報」を支払者に通知する。支払者の利便性を高めることができる。
【００４５】
［処理］
次に、支払管理装置１が行う処理の流れの一例について、図面を参照して説明する。
（１）メイン処理
図２１は、支払管理装置１が行うメイン処理の流れの一例を示すフローチャートである。この処理は、企業端末２または支払者端末３のいずれかからの支払装置１へのログイン要求により開始する。この処理により支払ルールの登録と通知が行われる。
【００４６】
ステップＳ１：支払管理装置１は、ログインの要求元を認証する。この認証は、図示しない認証情報を蓄積しておき、その認証情報の入力をログイン要求元に対して要求することにより行う。
ステップＳ２：支払管理装置１は、ログイン要求元が企業端末２なのか否かを判断する。
ステップＳ３、Ｓ４：企業端末２からのログインの場合、支払管理装置１は契約内容の登録要求なのか否かを判断する（Ｓ３）。この判断は、例えば図示しないメニュー画面上でのメニューの選択結果により行う。“Ｙｅｓ”と判断すると、契約内容登録画面による契約内容の登録を受け付ける（Ｓ４）。“Ｎｏ”と判断すると、ステップＳ５に移行する。
【００４７】
ステップＳ５、Ｓ６：支払管理装置１は支払ルールの登録要求なのか否かを判断する（Ｓ５）。この判断は、例えば図示しないメニュー画面上でのメニューの選択結果により行う。“Ｙｅｓ”と判断すると、支払ルールの登録を受け付ける（Ｓ６）。“Ｎｏ”と判断すると、ステップＳ７に移行する。
ステップＳ７、Ｓ８：支払管理装置１は評価条件の登録要求なのか否かを判断する（Ｓ７）。この判断は、例えば図示しないメニュー画面上でのメニューの選択結果により行う。“Ｙｅｓ”と判断すると、評価条件設定画面による評価条件の登録を受け付ける（Ｓ８）。“Ｎｏ”と判断すると処理を終了する。
【００４８】
ステップＳ９：支払管理装置１は、ログイン要求元が支払者端末３なのか否かを判断する。
ステップＳ１０、Ｓ１１：支払者端末３からのログインの場合、支払管理装置１は引き落とし予定一覧の表示要求なのか否かを判断する（Ｓ１０）。この判断は、例えば図示しない支払者用メニュー画面上でのメニューの選択結果により行う。“Ｙｅｓ”と判断すると、引落予定一覧表示画面を作成し、支払者端末３に提供する（Ｓ１１）。
【００４９】
ステップＳ１２、Ｓ１３：支払管理装置１は顧客要望の登録要求なのか否かを判断する（Ｓ１２）。この判断は、例えば図示しない支払者用メニュー画面上でのメニューの選択結果により行う。“Ｙｅｓ”と判断すると、顧客要望登録画面による顧客の要望の登録を受け付ける（Ｓ１３）。
この処理により、企業は企業の意志である支払ルールやその再評価に用いる評価条件を登録することができる。また支払者は、支払ルールを知ることができる。
【００５０】
（２）引き落とし処理
図２２は、支払管理装置１が行う引き落とし処理の流れの一例を示すフローチャートである。この処理は各引き落とし予定日に実行され、引き落とし不能の通知が支払者に送信される。
ステップＳ２１：支払管理装置１は、支払予定ＤＢ１０１から本日処理予定の支払データを読み出す。
ステップＳ２２：支払管理装置１は、支払予定に従い、引き落としを試行する。
【００５１】
ステップＳ２３：支払管理装置１は、ポイント更新サブルーチンにより、引き落としの成功または失敗による支払者のポイントを更新する。
ステップＳ２４、Ｓ２５：支払管理装置１は、ポイント更新サブルーチンの結果に基づいて、支払ルールの変更の有無を判断する（Ｓ２４）。変更有りと判断すると、支払予定ＤＢ１０１を更新する（Ｓ２５）。
ステップＳ２６、Ｓ２７：支払管理装置１は、引き落としが正常に終了したか否かを判断する（Ｓ２６）。引き落としが不能に終わった場合、支払管理装置１は支払者端末３に対し、支払ができなかったことを示す警告メッセージを送信する（Ｓ２７）。
【００５２】
この処理により、引き落としができなかったことを即座に支払者に知らしめ、遅滞なく代替支払を実行させる契機とすることができる。
（３）ポイント更新サブルーチン
図２３は、支払管理装置１が行うポイント更新サブルーチンの流れの一例を示すフローチャートである。この処理は、前記引き落とし処理でステップＳ２２に移行すると開始される。この処理により支払者のポイントが再計算される。
ステップＳ２０１：支払管理装置１は、顧客履歴ＤＢ１０３から支払者の最新の履歴データを読み出す。この履歴データには、試行された引き落としの結果が含まれる。
【００５３】
ステップＳ２０２：支払管理装置１は、引き落としが試行された支払についての契約内容を、評価ＤＢ１０４の契約テーブル１０４ａから読み出す。
ステップＳ２０３：支払管理装置１は、支払先企業の評価条件を、評価ＤＢ１０４のポイント算出条件管理テーブル１０４ｃから読み出す。
ステップＳ２０４：支払管理装置１は、企業と支払者との契約内容、支払者の最新の履歴、及びポイント算出条件管理テーブル１０４ｃの内容に基づいて、支払者の最新のポイントを算出する。
【００５４】
ステップＳ２０５：支払管理装置１は、支払先企業の評価反映ルールを、評価ＤＢ１０４の評価反映ルールテーブル１０４ｂから読み出す。
ステップＳ２０６：支払管理装置１は、最新のポイント、１つ前のポイント、及び評価反映ルールテーブル１０４ｂに基づいて、支払ルールを更新するか否かを判断する。
この処理により、引き落としが試行される度に支払者のポイントが再計算される。
【００５５】
（４）出金監視処理
図２４は、支払管理装置１が行う出金監視処理の流れの一例を示すフローチャートである。この処理は、口座管理ユニット１１が口座からの出金要求を受け取ることにより開始する。この処理は、出金により生じる残高不足を予測する。
ステップＳ３１：支払管理装置１は、出金要求額が現在の残高よりも多いか否かを判断する。“Ｙｅｓ”と判断すると処理を終了する。
ステップＳ３２：支払管理装置１は、（出金要求額）＞（現在の残高）である場合、翌営業日の引き落とし予定額を集計する。これは、支払予定ＤＢ１０１を参照して行う。
【００５６】
ステップＳ３３：支払管理装置１は、予約引き落としによる引き落とし予定額を集計する。
ステップＳ３４：支払管理装置１は、次式に基づいて翌営業日に残高不足が発生するか否かを判断する。次式が成り立てば残高不足は発生しない。
（（現在の残高）＋（予約引き落としの処理日までの入金予定額））＞
（（出金予定額）＋（引き落とし予定額）＋（予約引き落とし予定額））
ステップＳ３５：残高不足が発生する場合、支払管理装置１は、出金処理元に警告メッセージを送信する。例えば支払者端末３や銀行に設置されたＡＴＭ端末である。
【００５７】
ステップＳ３６、Ｓ３７：支払管理装置１は、出金額の変更を受け付ける。変更された場合、再度ステップＳ３１〜Ｓ３５が実行される（Ｓ３６）。変更されない場合、出金要求額を口座から出金する（Ｓ３７）。
この処理により、支払者が現金の引き出しや振込などを行ったために生じる残高不足を未然に防止しやすくなる。
（５）日次処理
図２５は、支払管理装置１が行う日次処理の流れの一例を示すフローチャートである。この処理は毎日１回実行され、翌々営業日の残高不足を予測する。
【００５８】
ステップＳ４１：支払管理装置１は、翌々営業日の引き落とし予定額を集計する。これは、支払予定ＤＢ１０１を参照して行う。
ステップＳ４２：支払管理装置１は、翌々営業日の入金予定に基づいて、翌々営業日の予想口座残高を算出する。入金予定は、口座管理ユニット１１の入金モジュール１２が管理している。
ステップＳ４３、Ｓ４４、Ｓ４５：支払管理装置１は、引き落とし予定総額が予想口座残高を上回るか否かを判断する（Ｓ４３）。上回る場合、支払管理装置１は、支払者端末３のアドレスをＤＢ群１００から読み出し（Ｓ４４）、警告メッセージを送信する（Ｓ４５）。
【００５９】
この処理により、残高不足の発生を未然に防ぐことができる。
＜その他の実施形態例＞
（Ａ）前記第１実施形態では、支払者及び企業共に１つの場合を例に取り説明した。支払者に対して複数の取引企業が存在する場合には、前述の処理は各企業ごとに行う。複数の支払者及び企業が存在する場合には、前述の処理は各支払者と各期ごとの組み合わせごとに行う。
（Ｂ）前述の支払管理方法をコンピュータ上で実行するためのプログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体は、本発明に含まれる。ここで記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。
【００６０】
＜付記＞
（付記１）
企業に代金の支払いを行う支払者のコンピュータ及び前記企業のコンピュータとネットワークを介して接続可能な支払管理装置に用いられる支払管理方法であって、
前記支払者の口座からの支払予定を記憶する予定記憶ステップと、
前記支払予定に従い、前記支払者の口座から引き落としを実行する引き落としステップと、
前記支払予定通りに実行できない引き落としが生じた場合に前記支払者に引き落としに代わる代替支払を実行してもらうための前記企業の支払ルールを記憶するルール記憶ステップと、
前記ルール記憶ステップで記憶されている前記支払ルールを、前記支払者のコンピュータに送信する通知ステップと、
を含む、支払管理方法。
【００６１】
支払ルールとは、例えば、代替支払を促進するためのペナルティ、支払手段の選択のルール、支払日の選択のルールなどである。ペナルティとしては、例えば延滞料金、支払手数料、ブラックリスト登録が挙げられる。支払手段としては、例えば再引き落とし、引き落としの中止、持参、コンビニエンスストアでの振込が挙げられる。支払日としては、翌月の同日とすることが挙げられる。引き落とし失敗の事実と共にこれら支払ルールを未払いの支払者に通知することにより、支払いを請求する企業側の意思に沿った形での代替支払を支払者に実行させることができる。
【００６２】
（付記２）
前記企業のコンピュータから前記支払ルールの設定及び／または更新を受け付けるルール更新ステップをさらに含む、付記１に記載の支払管理方法。
支払者に対する企業の支払ルールの設定や更新により、支払者に対する企業の意志やその変更を取引に反映させることができる。
（付記３）
前記支払者の支払実績を記憶する履歴ステップと、
前記支払者の過去の支払実績に基づいて、前記支払者の評価を行う評価ステップと、
前記支払者の評価結果に基づいて前記支払ルールを変更する基準となる評価反映ルールを記憶する評価反映ルール記憶ステップとをさらに含み、
前記ルール更新ステップは、前記評価ステップにおける評価結果と前記評価反映ルールとに基づいて、前記支払者に適用される支払ルールを設定及び／または更新する、
付記２に記載の支払管理方法。
【００６３】
支払者の評価は、例えば支払実績をポイントに換算することにより行うことができる。支払実績をポイントに換算するためのポイント算出条件を、予め記憶しておくか、企業からその登録を受け付けて登録内容を記憶しておくと良い。算出条件としては、過去の支払が支払予定通りに行われている優良率、支払が遅れた場合に契約で定められた次の支払日を遅滞した遅滞率、支払回数などが例として挙げられる。評価反映ルールは、例えば、ポイントが高くなるほど支払手段や日時の選択肢の幅を広げるように設定しておくことができる。
【００６４】
（付記４）
前記評価ステップは、前記支払者の過去の支払実績を評価するための評価条件の設定を受け付け、設定された評価条件に従って前記支払者の評価を行う、付記３に記載の支払管理方法。
ポイント算出条件の設定を受け付けることにより、各企業は自社が重視する観点に従って顧客を評価することができる。一例として、前述した優良率や遅滞率、支払回数などの重み付けや比率の指定を受け付けることが挙げられる。
【００６５】
（付記５）
前記評価ステップは、前記引き落としステップによる引き落としの試行後、引き落としの試行結果に基づいて前記支払者を再評価する、付記３に記載の支払管理方法。
顧客の評価は顧客の支払実績により変動する。従って、実績の変化を評価に反映させることが望ましい。そのためには顧客の実績を適切なタイミングで再評価する必要がある。例えば引き落としが試行される度にその結果を取り入れて再評価することが挙げられる。再評価のタイミングはこの例に限定されず、例えば定期的に行うことも可能である。
【００６６】
（付記６）
前記支払ルールは、引き落としに代わる代替支払を実行するための支払条件の選択肢を含み、
前記通知ステップは、前記支払条件の選択を前記支払者のコンピュータから受け付け、選択された支払条件に従い、引き落としを実行できなかった支払について前記予定記憶ステップで記憶されている支払予定を更新し、
前記引き落としステップは、更新された支払予定に従い、引き落としを実行する、
付記１に記載の支払管理方法。
【００６７】
支払条件の選択としては、例えば、再引き落としや現金振込・口座振り込みなどの支払手段の選択、翌月１０日払い・１５日払いなど支払日時の選択が挙げられる。
（付記７）
前記支払者の口座の残高を記憶する口座記憶ステップをさらに含み、
前記予定記憶ステップは、前記支払者の各支払について、支払者識別子及び支払先識別子を対応付けてさらに記憶し、
前記支払条件の選択肢には口座振込が含まれており、
前記引き落としステップは、前記口座からの出金処理をさらに管理し、代替支払の支払条件として口座振込が選択された場合、前記支払者識別子及び前記支払先識別子を用いて口座振込を実行する、
付記６に記載の支払管理方法。
【００６８】
引き落としできなかった支払を振込により再度行う場合、支払者は振込先や振込人などという情報を入力することなく振込できる。また、企業側は、誰からの振込かを容易に判別できる。支払者識別子としては、支払者の氏名に加えて口座番号を用いることが挙げられる。また支払先識別子としては支払先の名称に加えてその口座番号を用いることが挙げられる。
（付記８）
引き落としに関する前記支払者の要望の設定を受け付ける要望登録ステップをさらに含み、
前記予定記憶ステップは、前記要望登録ステップで受け付けた要望をさらに記憶し、
前記引き落としステップは、前記記憶された要望に従い、引き落としを実行する、
付記１に記載の支払管理方法。
【００６９】
例えば、どの引き落としを優先的に行うかという引き落としの優先度の設定を受け付けることが挙げられる。これにより、支払者は自分が重要視する支払から優先的に引き落としてもらうことができる。
（付記９）
前記通知ステップは、さらに、前記予定記憶ステップで記憶されている支払予定の一覧が前記要望に従って表示されている一覧画面を前記支払者のコンピュータに送信し、前記要望の更新を受け付け、
前記予定記憶ステップは、前記更新された要望を記憶し、
前記引き落としステップは、更新された要望に従って引き落としを実行する、
付記８に記載の支払管理方法。
【００７０】
支払者は、例えば自分が設定した優先度順にソートされた支払予定のリストを見て、優先度を変更することができる。これにより、支払者が通常想定していないが重要な支払を、滞りなく優先的に行うことができる。
（付記１０）
前記支払者の口座の残高を記憶する口座記憶ステップをさらに含み、
前記通知ステップは、さらに、
前記予定記憶ステップで記憶されている支払予定の一覧が表示されている一覧画面を前記支払者のコンピュータに送信し、
１または複数の引き落としの予約を受け付け、
予約された引き落としの実行に必要な残高があるか否かを、前記口座記憶ステップにおいて記憶されている口座残高に基づいて判断し、
前記引き落としステップは、前記口座に対する入出金をさらに管理し、前記予約された引き落としに必要な残高を優先的に確保する、
付記１に記載の支払管理方法。
【００７１】
支払者は、絶対に引き落としを実行してもらいたい支払を予約しておくことにより、その引き落としに必要な資金を他の処理よりも優先的に確保することができる。例えば、支払者自身による現金の引き出しよりも予約引き落としが優先される。また、他の引き落としよりも予約引き落としが優先されるため、別の引き落としと予約引き落としとの両方を実行するのに足りる残高がない場合には、別の引き落としは実行されない。このようにすれば、重要な支払が残高不足により実行不可となることを防止することができる。
【００７２】
（付記１１）
前記通知ステップは、さらに、前記予約された引き落としの予約の解除を受け付け、
前記引き落としステップは、前記予約が解除された引き落としに必要な金額の確保を解除する、
付記１０に記載の支払管理方法。
引き落としの予約の解除を受け付けることにより、支払者の利便性を高めることができる。
【００７３】
（付記１２）
前記引き落としステップは、前記支払者の口座からの出金要求を受け付け、前記予約された引き落としに必要な金額である予約金額を口座残高から引いた額が要求された出金額に満たない場合は警告メッセージを出力する、付記１０に記載の支払管理方法。
出金要求とは、引き落としや現金の引き出し・口座振り込みなど、口座残高が少なくなるような処理の要求を言う。出金要求があった場合、要求元に対して警告メッセージを出力する。要求元は、支払者自身のコンピュータやＡＴＭ端末などである。
【００７４】
（付記１３）
前記支払者の口座の残高を記憶する口座記憶ステップをさらに含み、
前記引き落としステップは、
前記予定記憶ステップにより記憶されている支払予定に従って引き落としを実行すると残高が不足するか否かを、前記口座の残高に基づいて引き落としに先立って判断し、
前記判断結果に応じ、前記支払者のコンピュータに対して残高不足予測通知を送信する、
付記１に記載の支払管理方法。
【００７５】
残高不足を予測して事前に支払者に通知することにより、残高不足の発生を未然に防ぐことができる。
（付記１４）
前記支払者の口座の残高を記憶する口座記憶ステップをさらに含み、、
前記引き落としステップは、前記口座に対する入出金をさらに管理し、前記口座への入金を予測した場合、前記支払者のコンピュータに対して入金予測通知を送信する、
付記１に記載の支払管理方法。
【００７６】
例えば企業から顧客の口座に保険給付金の振込が行われる場合、支払者の口座に対する「振込予定情報」を支払者に通知する。支払者の利便性を高めることができる。
（付記１５）
企業に代金の支払いを行う支払者のコンピュータ及び前記企業のコンピュータにネットワークを介して接続可能な支払管理装置であって、
前記支払者の口座からの支払予定を記憶する予定記憶手段と、
前記支払予定に従い、前記支払者の口座から引き落としを実行する引き落とし手段と、
前記支払予定通りに実行できない引き落としが生じた場合、前記支払者に引き落としに代わる代替支払を実行してもらうための支払ルールを記憶するルール記憶手段と、
前記ルール記憶手段で記憶されている前記支払ルールを、前記支払者のコンピュータに送信する通知手段と、
を備える支払管理装置。
【００７７】
（付記１６）
企業に代金の支払いを行う支払者の第１コンピュータ及び前記企業の第２コンピュータにネットワークを介して接続可能な第３コンピュータを機能させる支払管理プログラムであって、
前記支払者の口座からの支払予定を記憶する予定記憶手段、
前記支払予定に従い、前記支払者の口座から引き落としを実行する引き落とし手段、
前記支払予定通りに実行できない引き落としが生じた場合、前記支払者に引き落としに代わる代替支払を実行してもらうための支払ルールを記憶するルール記憶手段、及び
前記ルール記憶手段で記憶されている前記支払ルールを、前記支払者のコンピュータに送信する通知手段、
として前記第３コンピュータを機能させる支払管理プログラム。
【００７８】
（付記１７）
企業に代金の支払いを行う支払者の第１コンピュータ及び前記企業の第２コンピュータにネットワークを介して接続可能な第３コンピュータが実行する支払管理プログラムを記憶した、コンピュータ読み取り可能な記録媒体であって、
前記支払者の口座からの支払予定を記憶する予定記憶ステップと、
前記支払予定に従い、前記支払者の口座から引き落としを実行する引き落としステップと、
前記支払予定通りに実行できない引き落としが生じた場合に前記支払者に引き落としに代わる代替支払を実行してもらうための前記企業の支払ルールを記憶するルール記憶ステップと、
前記ルール記憶ステップで記憶されている前記支払ルールを、前記支払者のコンピュータに送信する通知ステップと、
を実行する支払管理プログラムを記憶した、コンピュータ読み取り可能な記録媒体。
【００７９】
【発明の効果】
本発明を用いれば、残高不足の発生を防ぎ、また残高不足が発生した後の企業・支払者双方の労力を軽減することができる。
【図面の簡単な説明】
【図１】支払管理装置を含んで構成される支払管理システムの全体構成図。
【図２】第１実施形態に係る支払管理装置の機能構成を示すブロック図。
【図３】引落予定一覧表示画面の一例。
【図４】（Ａ）企業端末２に提供する契約内容登録画面の一例。
（Ｂ）契約テーブル１０４ａの概念説明図
【図５】（Ａ）支払ルールの登録画面例（再引き落とし）
（Ｂ）支払ルール詳細登録画面例（その１）
（Ｃ）支払ルール詳細登録画面例（その２）
【図６】（Ａ）支払ルールの登録画面例（振込）
（Ｂ）支払ルール詳細登録画面例（その１）
（Ｃ）支払ルール詳細登録画面例（その２）
【図７】（Ａ）支払ルールの登録画面例（持参）
（Ｂ）支払ルール詳細登録画面例（その１）
（Ｃ）支払ルール詳細登録画面例（その２）
【図８】（Ａ）支払データの概念説明図
（Ｂ）「処理フラグ」がとりうる値とその値が示す支払状態の説明図
【図９】評価反映ルール設定画面例。
【図１０】（Ａ）履歴データの概念説明図
（Ｂ）評価条件設定画面例
（Ｃ）ポイント算出条件管理テーブルの概念説明図
【図１１】（Ａ）月次払いのカードタイプの契約によるポイントの算出例を示す説明図
（Ｂ）半年払いの定期タイプの契約によるポイントの算出例を示す説明図
（Ｃ）月次払いの１２回払いを毎年更新する契約によるポイントの算出例を示す説明図
【図１２】稼働率と優良率との重み付けを変えた場合のポイントの変化を示す説明図
（Ａ）稼働率：優良率＝１：１
（Ｂ）稼働率：優良率＝１：２
【図１３】（Ａ）顧客要望登録画面例
（Ｂ）要望データの概念説明図
【図１４】（Ａ）引き落とし予定一覧表示画面例（初期）
（Ｂ）契約別情報詳細表示画面例（初期）
【図１５】（Ａ）引き落とし予定一覧表示画面例（確認後）
（Ｂ）契約別情報詳細表示画面例（確認後）
【図１６】（Ａ）引き落とし予定一覧表示画面例（持参予定）
（Ｂ）契約別情報詳細表示画面例（持参予定）
【図１７】（Ａ）引き落とし予定一覧表示画面例（引き落とし中止後）
（Ｂ）契約別情報詳細表示画面例（引き落とし中止後）
【図１８】（Ａ）引き落とし予定一覧表示画面例（振込予定）
（Ｂ）契約別情報詳細表示画面例（振込予定）
【図１９】（Ａ）予約確認画面
（Ｂ）引き落とし予定一覧表示画面例（予約後）
（Ｃ）契約別情報詳細表示画面例（予約後）
【図２０】（Ａ）引き落とし予定一覧表示画面例（顧客要望変更前）
（Ｂ）引き落とし予定一覧表示画面例（顧客要望変更後）
【図２１】メイン処理の流れの一例を示すフローチャート
【図２２】引き落とし処理の流れの一例を示すフローチャート
【図２３】ポイント更新サブルーチンの流れの一例を示すフローチャート
【図２４】出金監視処理の流れの一例を示すフローチャート
【図２５】日次処理の流れの一例を示すフローチャート
【符号の説明】
１：支払管理装置
２：企業端末
３：支払者端末
【図１】
2004295302.tif 000004
【図２】
2004295302.tif 000005
【図３】
2004295302.tif 000006
【図４】
2004295302.tif 000007
【図５】
2004295302.tif 000008
【図６】
2004295302.tif 000009
【図７】
2004295302.tif 000010
【図８】
2004295302.tif 000011
【図９】
2004295302.tif 000012
【図１０】
2004295302.tif 000013
【図１１】
2004295302.tif 000014
【図１２】
2004295302.tif 000015
【図１３】
2004295302.tif 000016
【図１４】
2004295302.tif 000017
【図１５】
2004295302.tif 000018
【図１６】
2004295302.tif 000019
【図１７】
2004295302.tif 000020
【図１８】
2004295302.tif 000021
【図１９】
2004295302.tif 000022
【図２０】
2004295302.tif 000023
【図２１】
2004295302.tif 000024
【図２２】
2004295302.tif 000025
【図２３】
2004295302.tif 000026
【図２４】
2004295302.tif 000027
【図２５】
2004295302.tif 000028