特許 7390197 金融情報処理装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-11-22

(45)【発行日】2023-12-01

(54)【発明の名称】金融情報処理装置

(51)【国際特許分類】

   G06Q 20/24 20120101AFI20231124BHJP

   G06Q 50/10 20120101ALI20231124BHJP

【ＦＩ】

G06Q20/24

G06Q50/10

【請求項の数】 9

(21)【出願番号】P 2020010158

(22)【出願日】2020-01-24

(65)【公開番号】P2021117688

(43)【公開日】2021-08-10

【審査請求日】2022-12-01

(73)【特許権者】

【識別番号】302064762

【氏名又は名称】株式会社日本総合研究所

(74)【代理人】

【識別番号】110002871

【氏名又は名称】弁理士法人坂本国際特許商標事務所

(72)【発明者】

【氏名】野本 はるな

【審査官】平井 嗣人

(56)【参考文献】

【文献】特開２００５－０５６２１１（ＪＰ，Ａ）

【文献】特開２００５－１７４０３３（ＪＰ，Ａ）

【文献】特開２００６－２７７２２３（ＪＰ，Ａ）

【文献】特開２０１７－１５６８６０（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

ユーザに対応付けられた所定口座の残高情報を取得する残高情報取得部と、
前記ユーザに対応付けられた債務額情報であって、前記ユーザが債権者に負う債務の金額を表す債務額情報を取得する債務額情報取得部と、
前記ユーザに対応付けられた設定額情報であって、定期的な支払いタイミングでの定期的な支払額を表す設定額情報を取得する設定額情報取得部と、
前記所定口座からの前記定期的な支払額の支払いに応じて、前記定期的な支払額分だけ前記債務の金額が減るように前記債務額情報を更新する第１債務額情報更新部と、
金利分だけ前記債務の金額が増えるように前記債務額情報を更新する第２債務額情報更新部と、
次の前記定期的な支払いタイミングよりも前のタイミングでの前記残高情報と、前記設定額情報とに基づいて、次の前記定期的な支払いタイミングでの前記定期的な支払額に対する増額分又は減額分を算出する変額分算出部とを備える、金融情報処理装置。

【請求項2】

次の前記定期的な支払いタイミングでの前記定期的な支払額を、前記設定額情報の前記定期的な支払額に対して、前記変額分算出部により算出された前記増額分又は前記減額分だけ自動的に増額補正又は減額補正する変額補正部を更に備える、請求項１に記載の金融情報処理装置。

【請求項3】

次の前記定期的な支払いタイミングとは異なるタイミングでの繰り上げ返済額を、前記変額分算出部により算出された前記増額分に、自動的に設定する繰り上げ返済処理部を更に備える、請求項１に記載の金融情報処理装置。

【請求項4】

前記変額分算出部は、前記残高情報の残高と前記設定額情報の前記定期的な支払額との差分を算出し、算出した差分に基づいて、前記増額分又は前記減額分を算出する、請求項１から３のうちのいずれか１項に記載の金融情報処理装置。

【請求項5】

前記ユーザに対応付けられた制約情報であって、前記増額分又は前記減額分に関する制約情報を取得する制約情報取得部を更に備え、
前記変額分算出部は、前記制約情報に更に基づいて、前記増額分又は前記減額分を算出する、請求項４に記載の金融情報処理装置。

【請求項6】

次の前記定期的な支払いタイミングまでの、前記所定口座からの出金又は前記所定口座への入金を予測する予測部を更に備え、
前記変額分算出部は、前記予測部による予測結果に更に基づいて、前記増額分又は前記減額分を算出する、請求項４又は５に記載の金融情報処理装置。

【請求項7】

前記残高情報は、前記所定口座の残高について、複数の金額範囲のうちの、どの金額範囲であるかを示す、請求項１から６のうちのいずれか１項に記載の金融情報処理装置。

【請求項8】

サーバのみにより、ユーザ端末に実装されるアプリケーションプログラムのみにより、又は、サーバとユーザ端末に実装されるアプリケーションプログラムとの組み合わせにより実現される、請求項１から７のうちのいずれか１項に記載の金融情報処理装置。

【請求項9】

ユーザに対応付けられた所定口座の残高情報を取得し、
前記ユーザに対応付けられた債務額情報であって、前記ユーザが債権者に負う債務の金額を表す債務額情報を取得し、
前記ユーザに対応付けられた設定額情報であって、定期的な支払いタイミングでの定期的な支払額を表す設定額情報を取得し、
前記所定口座からの前記定期的な支払額の支払いに応じて、前記定期的な支払額分だけ前記債務の金額が減るように前記債務額情報を更新し、
金利分だけ前記債務の金額が増えるように前記債務額情報を更新し、
次の前記定期的な支払いタイミングよりも前のタイミングでの前記残高情報と、前記設定額情報とに基づいて、次の前記定期的な支払いタイミングでの前記定期的な支払額に対する増額分又は減額分を算出する、
処理をコンピュータに実行させる金融情報処理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、金融情報処理装置に関する。

【背景技術】

【0002】

クレジットカードの利用金額の引き落としのタイミングを制御する技術が知られている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１３－２００７４６号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

ところで、リボルビング払いのような利子が発生するような支払い形態は、利便性が高いと感じるユーザが多い一方、抵抗感があるユーザも依然として多いのが現状である。

【0005】

そこで、１つの側面では、本発明は、リボルビング払いのような利子が発生するような支払い形態に対するユーザの抵抗感を低減することを目的とする。

【課題を解決するための手段】

【0006】

１つの側面では、ユーザに対応付けられた所定口座の残高情報を取得する残高情報取得部と、
前記ユーザに対応付けられた債務額情報であって、前記ユーザが債権者に負う債務の金額を表す債務額情報を取得する債務額情報取得部と、
前記ユーザに対応付けられた設定額情報であって、定期的な支払いタイミングでの定期的な支払額を表す設定額情報を取得する設定額情報取得部と、
前記所定口座からの前記定期的な支払額の支払いに応じて、前記定期的な支払額分だけ前記債務の金額が減るように前記債務額情報を更新する第１債務額情報更新部と、
金利分だけ前記債務の金額が増えるように前記債務額情報を更新する第２債務額情報更新部と、
次の前記定期的な支払いタイミングよりも前のタイミングでの前記残高情報と、前記設定額情報とに基づいて、次の前記定期的な支払いタイミングでの前記定期的な支払額に対する増額分又は減額分を算出する変額分算出部とを備える、金融情報処理装置が提供される。

【発明の効果】

【0007】

１つの側面では、本発明によれば、リボルビング払いのような利子が発生するような支払い形態に対するユーザの抵抗感を低減することが可能となる。

【図面の簡単な説明】

【0008】

【図1】一実施例による金融情報処理システムの概略を示す図である。

【図2】クレジット会社サーバのハードウェア構成の一例を示す図である。

【図3】実施例１による、金融機関サーバ、クレジット会社サーバ、及びユーザ端末のそれぞれの機能の一例を示す図である。

【図4】クレジット会社サーバで記憶される各種情報の説明図である。

【図5】クレジット会社サーバで記憶されるユーザ情報の説明図である。

【図6】クレジット会社サーバにより実現される処理の一例を示す概略フローチャートである。

【図7】増額分自動設定処理（図６のステップＳ６４２）の一例を示す概略フローチャートである。

【図8】実施例２による、金融機関サーバ、クレジット会社サーバ、及びユーザ端末のそれぞれの機能の一例を示す図である。

【図9】実施例３による、金融機関サーバ、クレジット会社サーバ、及びユーザ端末のそれぞれの機能の一例を示す図である。

【図10】クレジット会社サーバにより実現される処理の一例を示す概略フローチャートである。

【図11】繰り上げ返済自動設定処理（図１０のステップＳ１０４２）の一例を示す概略フローチャートである。

【発明を実施するための形態】

【0009】

以下、添付図面を参照しながら各実施例について詳細に説明する。

【0010】

［実施例１］
図１は、一実施例による金融情報処理システム１の概略を示す図である。以下では、ユーザとは、金融情報処理システム１のユーザであって、後述するクレジットカード会社Ａの会員でもあるユーザを指す。金融情報処理システム１は、典型的には、多数のユーザを有するが、以下では、ユーザとは、特に言及しない限り、ある任意の一人のユーザを指す。

【0011】

金融情報処理システム１は、金融機関サーバ２０と、クレジット会社サーバ３０と、ユーザ端末４０とを含む。金融機関サーバ２０、クレジット会社サーバ３０、及びユーザ端末４０は、ネットワーク４を介して互いに対して通信可能に接続される。なお、ネットワーク４は、無線通信網や、インターネット、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、有線ネットワーク、又はこれらの任意の組み合わせ等を含んでよい。

【0012】

金融機関サーバ２０は、金融機関が管理・運営するサーバである。金融機関サーバ２０は、特定の一の金融機関に係るサーバであってもよいし、複数の金融機関に係るサーバであってもよい。金融機関サーバ２０は、ホストコンピュータ２１を中心とする勘定系、事務処理系の複数のコンピュータシステムで構成され、ユーザの口座情報を管理するデータベースである口座管理ＤＢ２２や日々の取引のトランザクションを処理するための口座取引ＤＢ２３を備えている。

【0013】

クレジット会社サーバ３０は、クレジットカード会社が管理・運営するサーバである。クレジットカード会社は、クレジットカードを発行し、会員に対して各種サービスを提供する。本実施例では、一例として、クレジット会社サーバ３０を管理・運営するクレジットカード会社は、クレジットカード会社Ａとする。なお、クレジット会社サーバ３０を管理・運営するクレジット会社は、複数存在してもよい。

【0014】

クレジット会社サーバ３０は、サーバコンピュータにより形成される。なお、クレジット会社サーバ３０は、複数のサーバコンピュータにより実現されてもよい。なお、銀行がクレジットカード会社を兼ねている場合は、金融機関サーバ２０とクレジット会社サーバ３０は一体であってよいが、以下の説明では、両者を別のサーバとして扱うことにする。

【0015】

ユーザ端末４０は、ユーザが管理・利用できる端末であり、以下で説明する各種機能を実現できるアプリケーションプログラムがインストールされる。ユーザ端末４０は、通信機能を備える端末であれば種類は任意である。従って、ユーザ端末４０は、携帯型の端末であってもよいし、固定型の端末であってもよい。すなわち、ユーザ端末４０は、例えばスマートフォンや携帯電話、ウエアラブル端末、タブレット端末のような携帯端末や、パーソナルコンピュータ等の固定端末であってもよい。なお、ユーザは、複数のユーザ端末４０を所持してもよい。

【0016】

ユーザ端末４０は、処理装置４１と、表示部４２とを含む。

【0017】

処理装置４１のハードウェア構成は、後出の図２に示すハードウェア構成と同様であってよい。処理装置４１には、以下で説明する各種機能を実現できるアプリケーションプログラムが実装される。

【0018】

表示部４２は、液晶ディスプレイや、有機ＥＬ（Ｅｌｅｃｔｒｏ－Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ等であってよい。

【0019】

図２は、クレジット会社サーバ３０のハードウェア構成の一例を示す図である。
図２に示す例では、クレジット会社サーバ３０は、制御部１０１、主記憶部１０２、補助記憶部１０３、ドライブ装置１０４、及びネットワークＩ／Ｆ部１０６を含む。

【0020】

制御部１０１は、主記憶部１０２や補助記憶部１０３に記憶されたプログラムを実行する演算装置であり、記憶装置からデータを受け取り、演算、加工した上で、記憶装置などに出力する。

【0021】

主記憶部１０２は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などである。主記憶部１０２は、制御部１０１が実行する基本ソフトウェアであるＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やアプリケーションソフトウェアなどのプログラムやデータを記憶又は一時保存する記憶装置である。

【0022】

補助記憶部１０３は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などであり、アプリケーションソフトウェアなどに関連するデータを記憶する記憶装置である。

【0023】

ドライブ装置１０４は、記録媒体１０５、例えばフレキシブルディスクからプログラムを読み出し、記憶装置にインストールする。

【0024】

記録媒体１０５は、所定のプログラムを格納する。この記録媒体１０５に格納されたプログラムは、ドライブ装置１０４を介してクレジット会社サーバ３０にインストールされる。インストールされた所定のプログラムは、クレジット会社サーバ３０により実行可能となる。

【0025】

ネットワークＩ／Ｆ部１０６は、ネットワーク４を介して接続された通信機能を有する周辺機器（金融機関サーバ２０やユーザ端末４０を含む）とクレジット会社サーバ３０とのインターフェイスである。

【0026】

なお、金融機関サーバ２０のハードウェア構成も、図２と同様であってよい。

【0027】

金融機関サーバ２０、クレジット会社サーバ３０、及びユーザ端末４０は、以下で説明するように、リボルビング払いにおいて口座残高に応じた自動増額機能を実現する。本実施例では、一例として、リボルビング払いを含むクレジットカードに係る支払いに関して、例えば毎月１５日が締日であり、翌月１０日が支払日（引き落とし実行日）であるとする。なお、締日や支払日は、複数種類ありうり、その場合、締日や支払日は、ユーザごとに異なりうる。ただし、各種の締日及び支払日は、いずれも、月ごとに１度到来するものとする。

【0028】

図３は、本実施例による、金融機関サーバ２０、クレジット会社サーバ３０、及びユーザ端末４０のそれぞれの機能の一例を示す図である。なお、図３は、口座残高に応じた自動増額機能を実現するための構成例であり、金融機関サーバ２０等の機能のすべてを表すものではない。従って、金融機関サーバ２０等は、図３に示す以外の機能を備えてもよい。図４は、クレジット会社サーバ３０で記憶される設定額情報及び制約情報の説明図である。図５は、クレジット会社サーバ３０で記憶されるユーザ情報の説明図である。図４及び図５において、「＊＊＊」は、何らかの情報が規定されていることを示し、「・・・」は、同様の情報が繰り返し記憶されていることを示す。

【0029】

金融機関サーバ２０は、図３に示すように、残高情報生成部２５０と、引き落とし予測部２５２と、支払実行部２５４と、残高履歴記憶部２５６と、を含む。

【0030】

残高情報生成部２５０は、ユーザに対応付けられた所定口座の残高情報を生成する。ユーザに対応付けられた所定口座は、ユーザが、引き落とし口座として指定した口座であり、１つ以上存在してもよい。残高情報は、通常の残高情報のように、１円まで正確な情報であってもよいが、本実施例では、好ましくは、およその残高を示す情報である。これは、正確な残高の開示を望まないユーザを考慮したものである。例えば、残高情報は、所定口座の残高について、以下のような複数の金額範囲（１）から（５）、すなわち、

【0031】

（１）１万円以下、（２）１万円から５万円、（３）５万円から１０万円、（４）１０万円から２０万円、（５）２０万円以上のうちの、どの金額範囲であるかを示す。なお、複数の金額範囲は、ユーザごとに設定されてもよい。

【0032】

残高情報生成部２５０は、残高情報をクレジット会社サーバ３０に送信する。送信タイミングは任意であるが、例えば、残高情報生成部２５０は、クレジット会社サーバ３０からの要求に応じて残高情報を送信してもよいし、定期的な所定タイミング（例えば月ごとの締日に合わせたタイミング）に、残高情報を送信してもよい。

【0033】

引き落とし予測部２５２は、所定タイミング（例えば月ごとの締日）から引き落とし実行日（月ごと）までの期間（以下、「猶予期間」とも称する）における引き落としの有無や、引き落とし額を予測する。引き落とし予測部２５２は、残高履歴記憶部２５６内の残高履歴情報に基づいて、猶予期間における引き落としの有無や、引き落とし額を予測できる。例えば、毎月、猶予期間において公共料金の引き落としがある場合は、引き落とし予測部２５２は、当該公共料金の引き落としと、その額を予測できる。また、毎年、特定の月における猶予期間において保険料の引き落としがある場合は、引き落とし予測部２５２は、当該保険料の引き落としと、その額を予測できる。なお、残高履歴情報に基づく予測方法は、任意であり、人工知能等が利用されてもよい。また、予測額は、切り上げや四捨五入を行うことで、比較的余裕のある額と（例えば１万円単位で切り上げ）されてもよい。

【0034】

引き落とし予測部２５２は、予測結果を表す引き落とし予測情報をクレジット会社サーバ３０に送信する。引き落とし予測情報の送信タイミングは任意であるが、例えば、引き落とし予測部２５２は、クレジット会社サーバ３０からの要求に応じて引き落とし予測情報を送信してもよいし、定期的な所定タイミング（例えば月ごとの締日に合わせたタイミング）に、引き落とし予測情報を送信してもよい。

【0035】

支払実行部２５４は、定期的にクレジット会社サーバ３０から送られる請求額情報に基づいて、定期的に所定口座から、請求額情報に応じた金額を引き落とす。支払実行部２５４は、請求額情報に応じた金額の引き落し（クレジットカード会社Ａに係る口座への当該金額の送金）を完了すると、その旨の通知（送金情報）をクレジット会社サーバ３０に送信する。なお、支払実行部２５４は、残高が足りずに、請求額情報に応じた金額の引き落としが不能である場合は、その旨をクレジット会社サーバ３０に通知してよい。

【0036】

残高履歴記憶部２５６には、ユーザに対応付けられた所定口座における残高の履歴が記憶される。残高の履歴は、ユーザに対応付けられた所定口座の残高が変更されるごとに蓄積される。なお、残高の履歴は、所定期間（例えば１年以上の期間）分が記憶されてよい。

【0037】

クレジット会社サーバ３０は、図３に示すように、残高情報取得部３５０と、引き落とし予測情報取得部３５１と、債務額情報取得部３５２と、設定額情報取得部３５４と、制約情報取得部３５６と、第１債務額情報更新部３５８と、第２債務額情報更新部３６０と、出金予測部３６２（予測部の一例）と、増額分算出部３６４（変額分算出部の一例）と、増額補正部３６６（変額補正部の一例）と、請求額情報送信部３６８と、債務額情報記憶部３７０と、設定額情報記憶部３７２と、制約情報記憶部３７４と、残高情報記憶部３７６と、引き落とし予測情報記憶部３７８と、ユーザ情報記憶部３８０とを含む。

【0038】

残高情報取得部３５０から請求額情報送信部３６８のような各処理部は、例えば図２に示す制御部１０１が主記憶部１０２内のプログラムを実行することで実現できる。また、債務額情報記憶部３７０からユーザ情報記憶部３８０のような各記憶部は、例えば図２に示す主記憶部１０２や補助記憶部１０３により実現できる。なお、金融機関サーバ２０の機能についても同様であるが、残高情報取得部３５０等の各機能部の区分は、説明上の都合があり、一の機能部の機能の一部が他の機能部により実現されてもよい。例えば、設定額情報記憶部３７２及び制約情報記憶部３７４は、同一のデータベース（例えば、会員である各ユーザの登録情報等を記憶するユーザ情報記憶部３８０）により実現されてもよい。

【0039】

残高情報取得部３５０は、金融機関サーバ２０から残高情報を取得する。残高情報は、上述のとおりである。残高情報取得部３５０は、締日に合わせて月ごとに１回だけ、金融機関サーバ２０に、残高情報を要求してもよいし、支払日まで複数回、金融機関サーバ２０に、残高情報を要求してもよい。残高情報取得部３５０は、残高情報を受信すると、残高情報記憶部３７６内の残高情報を更新する。

【0040】

引き落とし予測情報取得部３５１は、金融機関サーバ２０から引き落とし予測情報を取得する。引き落とし予測情報は、上述のとおりである。引き落とし予測情報取得部３５１は、締日に合わせて月ごとに１回だけ、金融機関サーバ２０に、引き落とし予測情報を要求してもよい。引き落とし予測情報取得部３５１は、引き落とし予測情報を受信すると、引き落とし予測情報記憶部３７８内の引き落とし予測情報を更新する。

【0041】

債務額情報取得部３５２は、ユーザに対応付けられた債務額情報であって、ユーザが債権者（クレジットカード会社Ａ又はそれと同一視できる者）に負う債務の金額を表す債務額情報を取得する。本実施例では、債務額情報は、債務額情報記憶部３７０内に、各ユーザに対応付けて記憶される。従って、この場合、債務額情報取得部３５２は、債務額情報記憶部３７０から債務額情報を取得する。

【0042】

設定額情報取得部３５４は、ユーザに対応付けられた設定額情報であって、定期的な支払いタイミングでの定期的な支払額を表す設定額情報を取得する。定期的な支払いタイミングは、月ごとの引き落とし実行日に対応する。定期的な支払額は、いわゆるリボルビング払いの支払額であり、月ごとに一定額とすることができる。本実施例では、設定額情報は、設定額情報記憶部３７２内に、各ユーザに対応付けて記憶される。従って、この場合、設定額情報取得部３５４は、設定額情報記憶部３７２から、ユーザに対応付けられた設定額情報を取得する。

【0043】

制約情報取得部３５６は、ユーザに対応付けられた制約情報であって、自動増額機能による増額分に関する制約情報を取得する。自動増額機能による増額分は、リボルビング払いの支払額に上乗せされる増額分に対応する。増額分は、完全に自動的に決定されてもよいが、好ましくは、ユーザの意向が考慮される。制約情報は、ユーザの意向を反映させるための情報であり、増額分に対する制約（上限値等）をユーザが設定する場合のその設定情報である。例えば、制約情報は、増額分に対する上限値や、残高情報の残高との関係で増額分に課される制約情報（例えば、増額分は、定期的な支払額の支払い後における残高の半分以下である等の制約）であってよい。本実施例では、制約情報は、制約情報記憶部３７４内に、各ユーザに対応付けて記憶される。従って、この場合、制約情報取得部３５６は、制約情報記憶部３７４から、ユーザに対応付けられた制約情報を取得する。

【0044】

第１債務額情報更新部３５８は、所定口座からの定期的な支払額の支払いに応じて、債務額情報記憶部３７０内の債務額情報を更新する。なお、所定口座からの定期的な支払額の支払いは、クレジットカード会社Ａに係る口座への入金や、金融機関サーバ２０からの送金情報等に基づいて確認されてもよい。第１債務額情報更新部３５８は、定期的な支払額分だけ債務の金額が減るように債務額情報記憶部３７０内の債務額情報を更新する。

【0045】

第２債務額情報更新部３６０は、債務額情報記憶部３７０内の債務額情報の履歴に基づいて、金利分だけ債務の金額が増えるように債務額情報記憶部３７０内の債務額情報を更新する。すなわち、第２債務額情報更新部３６０は、リボルビング払いに係る金利（リボ払い手数料）を発生させる。金利は、例えば実質年率１５．０％であってよい。

【0046】

また、第２債務額情報更新部３６０は、締日ごとに、当月の利用額（例えばクレジットカード等による決算額）だけ債務の金額が増えるように債務額情報記憶部３７０内の債務額情報を更新する。

【0047】

出金予測部３６２は、次の定期的な支払いタイミングまでの、所定口座（ユーザに対応付けられた所定口座）からの出金を予測する。この場合、出金予測部３６２は、出金の有無や、出金の額を予測してよい。予測方法は、任意であるが、金融機関サーバ２０の引き落とし予測部２５２の予測結果を表す引き落とし予測情報（引き落とし予測情報記憶部３７８内の引き落とし予測情報）に基づいて、出金を予測してよい。この場合、出金予測部３６２は、金融機関サーバ２０の引き落とし予測部２５２の予測結果を、そのまま利用することができる。すなわち、出金予測部３６２は、引き落とし予測部２５２の予測結果による引き落とし額を、出金の額として予測する。なお、金融機関サーバ２０の引き落とし予測部２５２の予測結果の予測額が比較的細かい単位である場合、出金予測部３６２は、当該予測額を切り上げや四捨五入を行うことで補正してもよい。

【0048】

増額分算出部３６４は、次の定期的な支払いタイミングでの定期的な支払額に上乗せ可能な増額分（以下、単に「増額分」とも称する）を算出する。本実施例では、増額分算出部３６４は、次の定期的な支払いタイミングよりも前のタイミングでの残高情報と、設定額情報とに基づいて、増額分を算出する。増額分算出部３６４は、次の定期的な支払いタイミングよりも前の適切なタイミング（猶予期間内の適切なタイミング）で増額分を算出する。なお、増額分算出部３６４は、債務額情報記憶部３７０内の債務額情報に基づいて、定期的な支払額に増額分を加えた値が債務額を超えないように、増額分を算出する。以下では、説明の複雑化を防止する都合上、債務額情報記憶部３７０内の債務額情報の債務額は十分大きいものとする。

【0049】

具体的には、増額分算出部３６４は、残高情報の残高と設定額情報の定期的な支払額との差分を算出し、算出した差分に基づいて、増額分を算出する。例えば、残高情報の残高が、上述した「（４）１０万円から２０万円」であり、設定額情報の定期的な支払額が“３万円”である場合、増額分算出部３６４は、残高情報の残高の下限値１０万円を用いて、７万円（１０万円－３万円＝７万円）を差分として算出してよい。

【0050】

増額分算出部３６４は、好ましくは、制約情報に更に基づいて、増額分を算出してよい。制約情報は、上述のように、増額分に対する制約（上限値等）に関する設定情報である。例えば、残高情報の残高が、上述した「（４）１０万円から２０万円」であり、制約情報が、「増額分は、定期的な支払額の支払い後における残高の半分以下である」という制約である場合、定期的な支払額の支払い後における残高の半分は、残高情報の残高の下限値１０万円を用いて、３．５万円（（１０万円－３万円）／２）である。従って、この場合、増額分算出部３６４は、３．５万円の増額分を算出する。

【0051】

また、増額分算出部３６４は、好ましくは、出金予測部３６２による予測結果に更に基づいて、増額分を算出してよい。これは、上述のような猶予期間内での所定口座からの何らかの引き落とし（例えば公共料金の引き落とし）によって、残高情報の残高が維持されない可能性があるためである。この場合、増額分算出部３６４は、例えば、残高情報の残高を、出金予測部３６２により予測される出金の額だけ減らす方向に補正した上で、増額分を算出してよい。例えば、残高情報の残高が、上述した「（４）１０万円から２０万円」であり、出金予測部３６２により予測される出金の額が２万円であり、設定額情報の定期的な支払額が“３万円”である場合、増額分算出部３６４は、残高情報の残高の下限値１０万円を用いて、残高情報の残高を、下限値１０万円から出金の予測額２万円を引いた８万円に補正した上で、５万円（８万円－３万円＝５万円）の増額分を算出してよい。

【0052】

また、増額分算出部３６４は、制約情報とともに出金予測部３６２による予測結果を考慮して、増額分を算出してもよい。この場合、制約情報に基づく増額分と、出金予測部３６２による予測結果に基づく増額分のうちの、少ないほうが採用されてもよい。上述した例では、出金予測部３６２による予測結果を考慮した場合は、５万円の増額分であるが、制約情報を考慮した場合は、３．５万円の増額分である。従って、この場合、少ない方の３．５万円の増額分が採用される。あるいは、増額分算出部３６４は、例えば、残高情報の残高を、出金予測部３６２により予測される出金の額だけ減らす方向に補正した上で、制約情報に基づいて増額分を算出してもよい。

【0053】

増額補正部３６６は、次の定期的な支払いタイミングでの定期的な支払額を、設定額情報の定期的な支払額に対して、増額分算出部３６４により算出された増額分だけ、自動的に増額補正する。すなわち、増額分算出部３６４により算出された増額分が０よりも大きい場合、次の定期的な支払いタイミングでの定期的な支払額は、設定額情報の定期的な支払額ではなく、当該支払額に、増額分算出部３６４により算出された増額分だけ増加した額とされる。設定額情報の定期的な支払額が３万円であり、かつ、増額分算出部３６４により算出された増額分が３．５万円である場合、増額補正部３６６は、次の定期的な支払いタイミングでの定期的な支払額を、３万円に３．５万円だけ増加した額、すなわち７．５万円に自動的に変更する。なお、“自動的に”とは、ユーザからの定期的な指示をその都度受けることなく実現される態様を指す。

【0054】

増額補正部３６６は、次の定期的な支払いタイミングよりも前の適切なタイミング（猶予期間内の適切なタイミング）で自動的に増額補正する。例えば、増額補正部３６６は、増額分算出部３６４が０よりも大きい増額分を算出した場合は、増額補正が実現されるように、ユーザに対応付けた増額補正情報を生成し、所定のメモリ領域に記憶する。増額補正情報は、例えば増額分を表す情報であってよい。

【0055】

請求額情報送信部３６８は、請求額情報を生成し、生成した請求額情報を金融機関サーバ２０に送信する。請求額情報送信部３６８は、増額補正部３６６が増額補正情報を生成した場合は、当該増額補正情報と、設定額情報記憶部３７２内の設定額情報とに基づいて、請求額情報を生成する。具体的には、請求額情報送信部３６８は、増額補正情報の増額分を、設定額情報の定期的な支払額に対して上乗せすることで、次の定期的な支払いタイミングでの請求額を決定（確定）し、決定した請求額を表す請求額情報を生成する。

【0056】

債務額情報記憶部３７０には、上述した債務額情報が記憶される。なお、債務額情報は、ユーザごとに、ユーザに対応付けて記憶されてよい。

【0057】

設定額情報記憶部３７２には、上述した設定額情報が記憶される。設定額情報は、ユーザにより初期設定され、その後、いつでも変更可能とされてよい。例えば、図４に示す例では、設定額情報記憶部３７２には、あるユーザに対応付けて設定額“３万円”の設定額情報４００Ｉが記憶されている。

【0058】

制約情報記憶部３７４には、上述した制約情報が記憶される。制約情報は、ユーザにより初期設定され、その後、いつでも変更可能とされてよい。例えば、図４に示す例では、制約情報記憶部３７４には、あるユーザに対応付けて上限（“定期的な支払額の支払い後における残高の半分”）に関する制約情報４０２Ｉが記憶されている。なお、変形例では、制約情報は省略されてもよい。この場合、増額分算出部３６４は、制約情報以外の情報に基づいて、増額分を算出できる。

【0059】

残高情報記憶部３７６には、上述した残高情報が記憶される。残高情報は、ユーザごとに、ユーザに対応付けて記憶される。なお、残高情報記憶部３７６内の残高情報は、比較的長い期間にわたり蓄積される態様で記憶されてもよい。この場合、残高情報記憶部３７６内の残高情報は、出金予測部３６２による予測に利用されてもよい。

【0060】

引き落とし予測情報記憶部３７８には、上述した引き落とし予測情報が記憶される。引き落とし予測情報は、ユーザごとに、ユーザに対応付けて記憶される。なお、引き落とし予測情報は、月ごとに記憶されてよい。そして、月ごとの引き落とし予測情報は、複数年にわたり平均化された状態で記憶されてもよい。

【0061】

ユーザ情報記憶部３８０には、会員である各ユーザの登録情報等が記憶される。登録情報は、図５に一部だけ示すように、ユーザＩＤごとに、所定口座を表す口座特定情報や、自動増額機能のオン／オフ情報、締日、支払日、クレジットカードの種別等を表す情報であってよい。なお、口座特定情報は、各ユーザにより初期設定され、その後、いつでも変更可能とされてよい。また、自動増額機能のオン／オフ情報は、自動増額機能を利用するか否かの情報であり、各ユーザにより初期設定され、その後、いつでも変更可能とされてよい。

【0062】

ユーザ端末４０は、図３に示すように、増額補正通知部４０２と、設定変更部４０４とを含む。増額補正通知部４０２及び設定変更部４０４は、処理装置４１の制御部（図２の制御部１０１のような制御部）が、処理装置４１の記憶部（図２の補助記憶部１０３のような記憶部）内のアプリケーションプログラムを実行することで実現できる。

【0063】

増額補正通知部４０２は、クレジット会社サーバ３０の増額補正部３６６による増額補正が実行された場合に、その旨の通知（以下、「増額通知」と称する）を出力する。例えば、増額補正通知部４０２は、ユーザ端末４０の表示部４２上に、増額通知を出力する。当該通知は、プッシュ通知の形態であってもよい。その他、増額通知は、メール等で実現されてもよい。なお、増額通知は、増額分が容易に分かるような態様で出力されてよい。

【0064】

なお、増額補正通知部４０２は、クレジット会社サーバ３０の増額補正部３６６による増額補正が実行されたか否かを任意の方法で判定してもよい。例えば、増額補正通知部４０２は、クレジット会社サーバ３０からの直接的な情報（すなわち増額補正が実行された旨の通知）に基づいて、クレジット会社サーバ３０の増額補正部３６６による増額補正が実行されたことを把握できる。あるいは、増額補正通知部４０２は、ユーザ端末４０にクレジット会社サーバ３０から請求額情報の控え情報が送信される場合は、当該控え情報に基づいて、クレジット会社サーバ３０の増額補正部３６６による増額補正が実行されたことを把握できる。

【0065】

設定変更部４０４は、ユーザからの入力情報に応じて、上述した設定額情報や制約情報等のような各種情報を修正するための修正指示を、クレジット会社サーバ３０に送信する。クレジット会社サーバ３０は、設定変更部４０４から修正指示に応じて、上述した設定額情報や制約情報等のような各種情報を修正する。

【0066】

このような本実施例による金融情報処理システム１によれば、ユーザの所定口座の残高に連動して自動的に、次の定期的な支払いタイミングでの定期的な支払額が、設定額から自動的に増加されるので、ユーザはその都度、自身の懐具合を勘案しながら増額設定を行う必要がなくなる。また、増額設定し忘れる月が発生することで、予期せぬ手数料の増加が生じることがない。このようにして、本実施例によれば、リボルビング払いをしたことがない一般的なユーザが感じやすいリボルビング払いの欠点を極力少なくできる。その結果、リボルビング払いのような利子が発生するような支払い形態に対する抵抗感を低減することが可能となる。

【0067】

なお、本実施例では、口座残高に応じた自動増額機能は、図４に示すように、クレジット会社サーバ３０が主体となって実現されているが、クレジット会社サーバ３０の機能の一部又は全部がユーザ端末４０により実現されてもよいし、逆に、ユーザ端末４０の機能の一部又は全部が、クレジット会社サーバ３０により実現されてもよい。例えば、クレジット会社サーバ３０の機能の全部がユーザ端末４０により実現される場合、債務額情報取得部３５２は、クレジット会社サーバ３０から債務額情報を取得してもよい。

【0068】

なお、本実施例１では、猶予期間中における所定口座の残高の変動要因として所定口座からの出金だけを考慮しているが（例えば、引き落とし予測部２５２、出金予測部３６２等）、それに代えて又は加えて、猶予期間中における所定口座の残高の変動要因として所定口座への入金を考慮してもよい。

【0069】

次に、図６及び図７のフローチャートを参照して、金融情報処理システム１のクレジット会社サーバ３０の動作例について説明する。以降の処理フロー図（フローチャート）においては、各ステップの入力と出力の関係を損なわない限り、各ステップの処理順序を入れ替えてもよい。

【0070】

図６は、クレジット会社サーバ３０により実現される処理の一例を示す概略フローチャートである。図６に示す処理は、例えば１日１回のような周期で、繰り返し実行されてよい。ここでは、一例として、図６に示す処理は、その月の最先の締日からその月の最遅の支払日までの期間だけ、１日１回の周期で繰り返し実行される。

【0071】

ステップＳ６００では、クレジット会社サーバ３０は、すべての対象ユーザ（すべての会員のうちの、自動増額機能がオンであるユーザ情報を有するすべてのユーザ、以下同じ）のうち、本日が締日であるユーザが存在するか否かを判定する。なお、各ユーザの締日は、クレジット会社サーバ３０のユーザ情報記憶部３８０内のユーザ情報（図５）に基づいて判定できる。判定結果が“ＹＥＳ”の場合、ステップＳ６０２に進み、それ以外の場合は、ステップＳ６１８に進む。

【0072】

ステップＳ６０２では、クレジット会社サーバ３０は、本日が締日であるユーザに対応付けられたユーザＩＤ（以下、単に「ユーザ」とも称する）をすべて抽出する。

【0073】

ステップＳ６０４では、クレジット会社サーバ３０は、ステップＳ６０２で抽出したユーザに、増額補正フラグ“１”を対応付ける。増額補正フラグは、ユーザごとに設定され、“１”である状態は、増額分の算出対象のユーザであることを示し、“０”である状態は、増額分の算出対象でないユーザであることを示す。なお、増額補正フラグの初期値は、“０”とされる。

【0074】

ステップＳ６０６では、クレジット会社サーバ３０は、増額補正フラグ“１”が対応付けられたユーザのそれぞれに係る残高情報を、金融機関サーバ２０に要求する。残高情報は、上述のとおりである。なお、クレジット会社サーバ３０は、当該要求に応じて金融機関サーバ２０から送信される残高情報を受信すると、残高情報記憶部３７６を更新する。なお、残高情報記憶部３７６の更新は、残高情報の受信時に実行されてよい。

【0075】

ステップＳ６０８では、クレジット会社サーバ３０は、増額補正フラグ“１”が対応付けられたユーザのそれぞれに係る引き落とし予測情報（引き落とし予測部２５２による予測結果）を、金融機関サーバ２０に要求する。なお、クレジット会社サーバ３０は、当該要求に応じて金融機関サーバ２０から送信される引き落とし予測情報を受信すると、引き落とし予測情報記憶部３７８を更新する。

【0076】

ステップＳ６１８では、クレジット会社サーバ３０は、すべての対象ユーザのうち、本日が支払日であるユーザが存在するか否かを判定する。なお、各ユーザの支払日は、クレジット会社サーバ３０のユーザ情報記憶部３８０内のユーザ情報（図５）に基づいて判定できる。判定結果が“ＹＥＳ”の場合、ステップＳ６２０に進み、それ以外の場合は、ステップＳ６４０に進む。

【0077】

ステップＳ６２０では、クレジット会社サーバ３０は、本日が支払日であるユーザに対応付けられたユーザＩＤ（以下、単に「ユーザ」とも称する）をすべて抽出し、適当なルールでソートする。

【0078】

ステップＳ６２２では、クレジット会社サーバ３０は、ステップＳ６２０で抽出したユーザのうちから、一のユーザを判定対象として選択する。

【0079】

ステップＳ６２４では、クレジット会社サーバ３０は、設定額情報記憶部３７２から、選択したユーザに対応付けられた設定額情報を抽出する。

【0080】

ステップＳ６２６では、クレジット会社サーバ３０は、選択したユーザに対応付けられた増額補正フラグが“１”であるか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ６２８に進み、それ以外の場合は、ステップＳ６３０に進む。

【0081】

ステップＳ６２８では、クレジット会社サーバ３０は、ステップＳ６２４で抽出した設定額情報の設定額に、選択したユーザに対応付けられた増額補正情報の増額分を付加した値（金額）を、請求額として設定する。

【0082】

ステップＳ６３０では、クレジット会社サーバ３０は、ステップＳ６２４で抽出した設定額情報の設定額を、請求額として設定する。

【0083】

ステップＳ６３２では、クレジット会社サーバ３０は、今回の判定対象の一のユーザに対応付けられた増額補正フラグを“０”にリセットする。

【0084】

ステップＳ６３４では、クレジット会社サーバ３０は、ステップＳ６２８又はステップＳ６３０で設定した請求額に基づいて、選択したユーザに対応付けられた請求額情報を生成する。そして、クレジット会社サーバ３０は、生成した請求額情報を金融機関サーバ２０に送信する。なお、この際、クレジット会社サーバ３０は、選択したユーザに対応付けられたユーザ端末４０にも、請求額情報の請求額が、所定口座から引き落とされる旨の通知を送信してもよい。

【0085】

ステップＳ６３６では、クレジット会社サーバ３０は、ステップＳ６２０で抽出したすべてのユーザが、判定対象として選択されたか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ６４０に進み、それ以外の場合は、ステップＳ６３８に進む。

【0086】

ステップＳ６３８では、クレジット会社サーバ３０は、他の一のユーザを判定対象として選択する。このようにして、ステップＳ６２０で抽出したすべてのユーザが、判定対象として選択されるまで、ステップＳ６２４からステップＳ６３４の処理が繰り返し実行される。

【0087】

ステップＳ６４０では、クレジット会社サーバ３０は、すべての対象ユーザのうち、増額補正フラグ“１”が対応付けられたユーザが存在するか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ６４２に進み、それ以外の場合は、終了する。

【0088】

ステップＳ６４２では、クレジット会社サーバ３０は、増額補正フラグ“１”が対応付けられたユーザに関して、増額分自動設定処理を実行する。増額分自動設定処理の一例は、図７を参照して後述する。

【0089】

図７は、増額分自動設定処理（図６のステップＳ６４２）の一例を示す概略フローチャートである。

【0090】

ステップＳ６４２０では、クレジット会社サーバ３０は、増額補正フラグ“１”が対応付けられたユーザのそれぞれに係る残高情報を要求する。残高情報は、上述のとおりである。なお、クレジット会社サーバ３０は、当該要求に応じて金融機関サーバ２０から送信される残高情報を受信すると、残高情報記憶部３７６を更新する。なお、残高情報記憶部３７６の更新は、残高情報の受信時に実行されてよい。

【0091】

ステップＳ６４２１では、クレジット会社サーバ３０は、前回の処理周期（例えば前日）から残高情報が更新されたユーザが存在するか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ６４２２に進み、それ以外の場合は、終了する。

【0092】

ステップＳ６４２２では、クレジット会社サーバ３０は、前回の処理周期（例えば前日）から残高情報が更新されたすべてのユーザを抽出し、適当なルールでソートする。

【0093】

ステップＳ６４２４では、クレジット会社サーバ３０は、ステップＳ６４２２で抽出したユーザのうちから、一のユーザを選択する。

【0094】

ステップＳ６４２６では、クレジット会社サーバ３０は、設定額情報記憶部３７２から、選択したユーザに対応付けられた設定額情報を読み出す。

【0095】

ステップＳ６４２７では、クレジット会社サーバ３０は、債務額情報記憶部３７０から、選択したユーザに対応付けられた債務額情報を読み出す（取得する）。

【0096】

ステップＳ６４２８では、クレジット会社サーバ３０は、制約情報記憶部３７４から、選択したユーザに対応付けられた制約情報を読み出す。

【0097】

ステップＳ６４２９では、クレジット会社サーバ３０は、引き落とし予測情報記憶部３７８から、選択したユーザに対応付けられた引き落とし予測情報を読み出す。

【0098】

ステップＳ６４３０では、クレジット会社サーバ３０は、残高情報記憶部３７６から、選択したユーザに対応付けられた残高情報を読み出す。

【0099】

ステップＳ６４３１では、クレジット会社サーバ３０は、ステップＳ６４２９で読み出した引き落とし予測情報に基づいて、ユーザに対応付けられた所定口座からの出金（残高情報の更新後における出金）を予測する。出金の予測方法は、上述のとおりであってよい。

【0100】

ステップＳ６４３２では、クレジット会社サーバ３０は、ステップＳ６４２６からステップＳ６４３０で読み出した設定額情報、債務額情報、制約情報、及び残高情報と、ステップＳ６４３１での出金の予測結果とに基づいて、増額分を算出する。増額分の算出方法は、上述したとおりであってよい。

【0101】

ステップＳ６４３４では、クレジット会社サーバ３０は、ステップＳ６４３２で算出した増額分に基づいて、増額補正用の増額補正情報を生成する。なお、この際、ステップＳ６４３２で算出した増額分が０である場合は、クレジット会社サーバ３０は、ユーザに対応付けられた増額補正フラグを“０”にリセットしてよい。

【0102】

ステップＳ６４３６では、クレジット会社サーバ３０は、ステップＳ６４２２で抽出したすべてのユーザが選択されたか否かを判定する。判定結果が“ＹＥＳ”の場合、終了し、それ以外の場合は、ステップＳ６４３８に進む。

【0103】

ステップＳ６４３８では、クレジット会社サーバ３０は、他の一のユーザを選択する。このようにして、ステップＳ６４２２で抽出したすべてのユーザが選択されるまで、ステップＳ６４２６からステップＳ６４３４の処理が繰り返し実行される。

【0104】

図６及び図７に示す処理によれば、各ユーザに対して、締日から支払日までの期間（すなわち猶予期間）において、残高情報に応じて算出された増額分に基づいて請求額が決定されるので、各ユーザは、毎月、増額分を手動で設定する必要がなくなる。これにより、利便性が向上する。また、図６及び図７に示す処理によれば、猶予期間中、毎日、残高情報に基づいて増額分が増減されうるので、猶予期間中における残高情報の実際の変動を加味できる態様で、増額分を算出（更新）できる。これにより、出金予測部３６２によって予測できないような変動が発生し場合でも、適切な増額分を算出できる。ただし、変形例では、金融機関サーバ２０からの残高情報の取得は、月ごとに猶予期間における１回だけに限定されてもよい（すなわちステップＳ６４２０が省略されてもよい）。

【0105】

また、本実施例において、定期的なタイミングでの定期的な支払（リボルビング払い）を実施していないユーザ（設定額情報記憶部３７に記憶されている設定額情報「０円」のユーザ）に対しても、所定の場合（例えば残高不足が生じた場合等）に、臨時的に又は恒久的に、定期的な支払額を発生させてもよい（０円よりも大きい増額分を設定してもよい）。リボルビング払いにすると利子が発生するが、延滞発生時も同様に利子が発生する一方、リボルビング払いに変更することで信用度低下を回避できるメリットもあるからである。なお、ユーザに対して設定額情報を増加するときは、事前に通知するようにしてもよい。

【0106】

［実施例２］
上述した実施例１では、金融機関サーバ２０、クレジット会社サーバ３０、及びユーザ端末４０は、リボルビング払いにおいて口座残高に応じた自動増額機能を実現するが、本実施例２では、金融機関サーバ２０Ａ、クレジット会社サーバ３０Ａ、及びユーザ端末４０Ａは、リボルビング払いにおいて口座残高に応じた自動減額機能を実現する。

【0107】

図８は、本実施例による、金融機関サーバ２０Ａ、クレジット会社サーバ３０Ａ、及びユーザ端末４０Ａのそれぞれの機能の一例を示す図である。なお、図８は、口座残高に応じた自動減額機能を実現するための構成例であり、金融機関サーバ２０Ａ等の機能のすべてを表すものではない。従って、金融機関サーバ２０Ａ等は、図８に示す以外の機能を備えてもよい。なお、図８において、上述した実施例１で説明した構成要素と実質的に同様であってよい構成要素については、同一の参照符号を付して説明を省略する場合がある。

【0108】

金融機関サーバ２０Ａは、図８に示すように、残高情報生成部２５０と、入金予測部２５２Ａと、支払実行部２５４と、残高履歴記憶部２５６と、を含む。

【0109】

入金予測部２５２Ａは、猶予期間における入金の有無や、入金額を予測する。入金予測部２５２Ａは、残高履歴記憶部２５６内の残高履歴情報に基づいて、猶予期間における入金の有無や、入金額を予測できる。例えば、毎月、猶予期間において給与や各種の支援金（例えば子育て支援関連のお金）の入金がある場合は、入金予測部２５２Ａは、当該支援金の入金と、その額を予測できる。また、毎年、特定の月における猶予期間において利息や配当の入金がある場合は、入金予測部２５２Ａは、当該利息や配当の入金と、その額を予測できる。なお、残高履歴情報に基づく予測方法は、任意であり、人工知能等が利用されてもよい。また、予測額は、切り下げを行うことで、比較的余裕のある額と（例えば１万円単位で切り下げ）されてもよい。

【0110】

入金予測部２５２Ａは、予測結果を表す入金予測情報をクレジット会社サーバ３０Ａに送信する。入金予測情報の送信タイミングは任意であるが、例えば、入金予測部２５２Ａは、クレジット会社サーバ３０Ａからの要求に応じて入金予測情報を送信してもよいし、定期的な所定タイミング（例えば月ごとの締日）に、入金予測情報を送信してもよい。

【0111】

クレジット会社サーバ３０Ａは、図８に示すように、残高情報取得部３５０と、入金予測情報取得部３５１Ａと、債務額情報取得部３５２と、設定額情報取得部３５４と、制約情報取得部３５６Ａと、第１債務額情報更新部３５８と、第２債務額情報更新部３６０と、入金予測部３６２Ａ（予測部の一例）と、減額分算出部３６４Ａ（変額分算出部の一例）と、減額補正部３６６Ａ（変額補正部の一例）と、請求額情報送信部３６８と、債務額情報記憶部３７０と、設定額情報記憶部３７２と、制約情報記憶部３７４と、残高情報記憶部３７６と、入金予測情報記憶部３７８Ａと、ユーザ情報記憶部３８０Ａとを含む。

【0112】

入金予測情報取得部３５１Ａは、金融機関サーバ２０Ａから入金予測情報を取得する。入金予測情報は、上述のとおりである。入金予測情報取得部３５１Ａは、締日に合わせて月ごとに１回だけ、金融機関サーバ２０Ａに、入金予測情報を要求してもよい。入金予測情報取得部３５１Ａは、入金予測情報を受信すると、入金予測情報記憶部３７８Ａ内の入金予測情報を更新する。

【0113】

制約情報取得部３５６Ａは、ユーザに対応付けられた制約情報であって、自動減額機能による減額分に関する制約情報を取得する。自動減額機能による減額分は、リボルビング払いの支払額から減額される減額分に対応する。減額分は、完全に自動的に決定されてもよいが、好ましくは、ユーザの意向が考慮される。制約情報は、ユーザの意向を反映させるための情報であり、減額分に対する制約（下限値等）をユーザが設定する場合のその設定情報である。例えば、制約情報は、減額分に対する下限値や、残高情報の残高との関係で減額分に課される制約情報（例えば、減額分は、請求額を差し引いたときの残高が所定額以上となること等のような、制約）であってよい。本実施例では、制約情報は、制約情報記憶部３７４内に、各ユーザに対応付けて記憶される。従って、この場合、制約情報取得部３５６Ａは、制約情報記憶部３７４から、ユーザに対応付けられた制約情報を取得する。

【0114】

入金予測部３６２Ａは、次の定期的な支払いタイミングまでの、所定口座（ユーザに対応付けられた所定口座）からの入金を予測する。この場合、入金予測部３６２Ａは、入金の有無や、入金の額を予測してよい。予測方法は、任意であるが、金融機関サーバ２０Ａの入金予測部２５２Ａの予測結果を表す入金予測情報（入金予測情報記憶部３７８Ａ内の入金予測情報）に基づいて、入金を予測してよい。この場合、入金予測部３６２Ａは、金融機関サーバ２０Ａの入金予測部２５２Ａの予測結果を、そのまま利用することができる。すなわち、入金予測部３６２Ａは、入金予測部２５２Ａの予測結果による入金額を、そのまま入金額として予測する。なお、金融機関サーバ２０Ａの入金予測部２５２Ａの予測結果の予測額が比較的細かい単位である場合、入金予測部３６２Ａは、当該予測額を切り下げ等により補正してもよい。

【0115】

減額分算出部３６４Ａは、次の定期的な支払いタイミングでの定期的な支払額から減額される減額分（以下、単に「減額分」とも称する）を算出する。本実施例では、減額分算出部３６４Ａは、次の定期的な支払いタイミングよりも前のタイミングでの残高情報と、設定額情報とに基づいて、減額分を算出する。減額分算出部３６４Ａは、次の定期的な支払いタイミングよりも前の適切なタイミング（猶予期間内の適切なタイミング）で減額分を算出する。なお、減額分算出部３６４Ａは、債務額情報記憶部３７０内の債務額情報に基づいて、定期的な支払額から減額分を差し引いた値が債務額を超えないように、減額分を算出する。以下では、説明の複雑化を防止する都合上、債務額情報記憶部３７０内の債務額情報の債務額は十分大きいものとする。

【0116】

具体的には、減額分算出部３６４Ａは、残高情報の残高と設定額情報の定期的な支払額との差分を算出し、算出した差分に基づいて、減額分を算出する。例えば、残高情報の残高が、上述した「（４）１０万円から２０万円」であり、設定額情報の定期的な支払額が“３０万円”である場合、減額分算出部３６４Ａは、残高情報の残高の下限値１０万円を用いて、－２０万円（１０万円－３０万円＝－２０万円）を差分として算出してよい。この場合、減額分算出部３６４Ａは、２０万円の減額分を算出する。

【0117】

減額分算出部３６４Ａは、好ましくは、制約情報に更に基づいて、減額分を算出してよい。制約情報は、上述のように、減額分に対する制約（下限値等）に関する設定情報である。例えば、残高情報の残高が、上述した「（４）１０万円から２０万円」であり、制約情報が、「減額分は、請求額を差し引いたときの残高が３万円以上である」という制約である場合、残高情報の残高の下限値１０万円を用いて、２３万円の減額分を算出する。

【0118】

また、減額分算出部３６４Ａは、好ましくは、入金予測部３６２Ａによる予測結果に更に基づいて、減額分を算出してよい。これは、上述のような猶予期間内での所定口座からの何らかの入金（例えば給与や支援金の入金）によって、残高情報の残高が増加する可能性があるためである。この場合、減額分算出部３６４Ａは、例えば、残高情報の残高を、入金予測部３６２Ａにより予測される入金の額だけ増加する方向に補正した上で、減額分を算出してよい。例えば、残高情報の残高が、上述した「（４）１０万円から２０万円」であり、入金予測部３６２Ａにより予測される入金の額が１０万円であり、設定額情報の定期的な支払額が“３０万円”である場合、減額分算出部３６４Ａは、残高情報の残高の下限値１０万円を用いて、残高情報の残高を、下限値１０万円から入金の予測額１０万円を足した２０万円に補正した上で、１０万円（２０万円－３０万円＝－１０万円）の減額分を算出してよい。

【0119】

また、減額分算出部３６４Ａは、制約情報とともに入金予測部３６２Ａによる予測結果を考慮して、減額分を算出してもよい。この場合、減額分算出部３６４Ａは、例えば、残高情報の残高を、入金予測部３６２Ａにより予測される入金の額だけ増加する方向に補正した上で、制約情報に基づいて減額分を算出してよい。

【0120】

減額補正部３６６Ａは、次の定期的な支払いタイミングでの定期的な支払額を、設定額情報の定期的な支払額に対して、減額分算出部３６４Ａにより算出された減額分だけ、自動的に減額補正する。すなわち、減額分算出部３６４Ａにより算出された減額分が０よりも大きい場合、次の定期的な支払いタイミングでの定期的な支払額は、設定額情報の定期的な支払額ではなく、当該支払額から、減額分算出部３６４Ａにより算出された減額分だけ差し引いた額とされる。設定額情報の定期的な支払額が３０万円であり、かつ、減額分算出部３６４Ａにより算出された減額分が２０万円である場合、減額補正部３６６Ａは、次の定期的な支払いタイミングでの定期的な支払額を、３０万円から２０万円だけ差し引いた額、すなわち１０万円に自動的に変更する。

【0121】

減額補正部３６６Ａは、次の定期的な支払いタイミングよりも前の適切なタイミング（猶予期間内の適切なタイミング）で自動的に減額補正する。例えば、減額補正部３６６Ａは、減額分算出部３６４Ａが０よりも大きい減額分を算出した場合は、減額補正が実現されるように、ユーザに対応付けた減額補正情報を生成し、所定のメモリ領域に記憶する。減額補正情報は、例えば減額分を表す情報であってよい。

【0122】

請求額情報送信部３６８は、請求額情報を生成し、生成した請求額情報を金融機関サーバ２０Ａに送信する。請求額情報送信部３６８は、減額補正部３６６Ａが減額補正情報を生成した場合は、当該減額補正情報と、設定額情報記憶部３７２内の設定額情報とに基づいて、請求額情報を生成する。具体的には、請求額情報送信部３６８は、減額補正情報の減額分を、設定額情報の定期的な支払額から差し引くことで、次の定期的な支払いタイミングでの請求額を決定（確定）し、決定した請求額を表す請求額情報を生成する。

【0123】

入金予測情報記憶部３７８Ａには、上述した入金予測情報が記憶される。入金予測情報は、ユーザごとに、ユーザに対応付けて記憶される。なお、入金予測情報は、月ごとに記憶されてよい。そして、月ごとの入金予測情報は、複数年にわたり平均化された状態で記憶されてもよい。

【0124】

ユーザ情報記憶部３８０Ａには、会員である各ユーザの登録情報等（図示せず）が記憶される。登録情報は、ユーザＩＤごとに、所定口座を表す口座特定情報や、自動減額機能のオン／オフ情報、締日、支払日、クレジットカードの種別等を表す情報であってよい。なお、口座特定情報は、各ユーザにより初期設定され、その後、いつでも変更可能とされてよい。また、自動減額機能のオン／オフ情報は、自動減額機能を利用するか否かの情報であり、各ユーザにより初期設定され、その後、いつでも変更可能とされてよい。

【0125】

ユーザ端末４０Ａは、図８に示すように、減額補正通知部４０２Ａと、設定変更部４０４とを含む。

【0126】

減額補正通知部４０２Ａは、クレジット会社サーバ３０Ａの減額補正部３６６Ａによる減額補正が実行された場合に、その旨の通知（以下、「減額通知」と称する）を出力する。例えば、減額補正通知部４０２Ａは、ユーザ端末４０Ａの表示部４２上に、減額通知を出力する。当該通知は、プッシュ通知の形態であってもよい。その他、減額通知は、メール等で実現されてもよい。なお、減額通知は、減額分が容易に分かるような態様で出力されてよい。

【0127】

なお、減額補正通知部４０２Ａは、クレジット会社サーバ３０Ａの減額補正部３６６Ａによる減額補正が実行されたか否かを任意の方法で判定してもよい。例えば、減額補正通知部４０２Ａは、クレジット会社サーバ３０Ａからの直接的な情報（すなわち減額補正が実行された旨の通知）に基づいて、クレジット会社サーバ３０Ａの減額補正部３６６Ａによる減額補正が実行されたことを把握できる。あるいは、減額補正通知部４０２Ａは、クレジット会社サーバ３０Ａからの請求額情報に基づいて、クレジット会社サーバ３０Ａの減額補正部３６６Ａによる減額補正が実行されたことを把握できる。

【0128】

このような本実施例２によれば、ユーザの所定口座の残高に連動して自動的に、次の定期的な支払いタイミングでの定期的な支払額が、設定額から自動的に減額されるので、ユーザはその都度、自身の懐具合を勘案しながら減額設定を行う必要がなくなる。また、減額設定し忘れる月が発生することで、予期せぬ残高不足が生じることがない。このようにして、本実施例によれば、リボルビング払いをしたことがない一般的なユーザが感じやすいリボルビング払いの欠点を極力少なくできる。その結果、リボルビング払いのような利子が発生するような支払い形態に対する抵抗感を低減することが可能となる。

【0129】

なお、本実施例２によるクレジット会社サーバ３０Ａの動作例については、上述した実施例１のようにフローチャートを用いて説明しないが、“増額”が“減額”に変わる点とそれに関連する点だけが異なるだけであり、図６及び図７と実質的に同様の態様であってよい。

【0130】

なお、本実施例２では、口座残高に応じた自動減額機能は、図８に示すように、クレジット会社サーバ３０Ａが主体となって実現されているが、クレジット会社サーバ３０Ａの機能の一部又は全部がユーザ端末４０Ａにより実現されてもよいし、逆に、ユーザ端末４０Ａの機能の一部又は全部が、クレジット会社サーバ３０Ａにより実現されてもよい。

【0131】

また、本実施例２では、猶予期間中における残高の変動要因として入金だけを考慮しているが、それに代えて又は加えて、上述した実施例１のように、猶予期間中における残高の変動要因として出金（所定口座からの引き落とし）を考慮してもよい。例えば、引き落とし予測部２５２や、出金予測部３６２等が追加されてもよい。

【0132】

また、本実施例２は、上述した実施例１と組み合わせることも可能である。すなわち、リボルビング払いにおいて、月ごとに、口座残高に応じて自動増額機能と自動減額機能のいずれか一方が選択的に実現されてもよい。すなわち、口座残高に応じて、設定額情報に基づく定期的な支払額に対する変額分の自動最適化機能が実現されてもよい。

【0133】

［実施例３］
上述した実施例１では、金融機関サーバ２０、クレジット会社サーバ３０、及びユーザ端末４０は、リボルビング払いにおいて口座残高に応じた自動増額機能を実現するが、本実施例３では、金融機関サーバ２０Ｂ、クレジット会社サーバ３０Ｂ、及びユーザ端末４０Ｂは、リボルビング払いにおいて口座残高に応じた自動繰り上げ返済機能を実現する。

【0134】

図９は、本実施例による、金融機関サーバ２０Ｂ、クレジット会社サーバ３０Ｂ、及びユーザ端末４０Ｂのそれぞれの機能の一例を示す図である。なお、図９は、口座残高に応じた自動繰り上げ返済機能を実現するための構成例であり、金融機関サーバ２０Ｂ等の機能のすべてを表すものではない。従って、金融機関サーバ２０Ｂ等は、図９に示す以外の機能を備えてもよい。なお、図９において、上述した実施例１で説明した構成要素と実質的に同様であってよい構成要素については、同一の参照符号を付して説明を省略する場合がある。

【0135】

金融機関サーバ２０Ｂは、図９に示すように、残高情報生成部２５０と、引き落とし予測部２５２と、支払実行部２５４と、繰り上げ返済実行部２５５と、残高履歴記憶部２５６と、を含む。

【0136】

繰り上げ返済実行部２５５は、クレジット会社サーバ３０Ｂから送られる繰り上げ返済要求に基づいて、所定口座から、繰り上げ返済要求に応じた金額（繰り上げ返済額）を引き落とす。繰り上げ返済実行部２５５は、繰り上げ返済要求に応じた金額の引き落し（クレジットカード会社Ａに係る口座への当該金額の送金）を完了すると、その旨の通知（送金情報）をクレジット会社サーバ３０Ｂに送信する。

【0137】

クレジット会社サーバ３０Ｂは、図９に示すように、残高情報取得部３５０と、引き落とし予測情報取得部３５１と、債務額情報取得部３５２と、設定額情報取得部３５４と、制約情報取得部３５６と、第１債務額情報更新部３５８Ｂと、第２債務額情報更新部３６０と、出金予測部３６２（予測部の一例）と、増額分算出部３６４（変額分算出部の一例）、繰り上げ返済処理部３６６Ｂと、請求額情報送信部３６８と、債務額情報記憶部３７０と、設定額情報記憶部３７２と、制約情報記憶部３７４と、残高情報記憶部３７６と、引き落とし予測情報記憶部３７８と、ユーザ情報記憶部３８０Ｂとを含む。

【0138】

第１債務額情報更新部３５８Ｂは、所定口座からの定期的な支払額の支払いに応じて、債務額情報記憶部３７０内の債務額情報を更新する。なお、所定口座からの定期的な支払額の支払いは、クレジットカード会社Ａに係る口座への入金や、金融機関サーバ２０Ｂからの送金情報等に基づいて確認されてもよい。第１債務額情報更新部３５８は、定期的な支払額分だけ債務の金額が減るように債務額情報記憶部３７０内の債務額情報を更新する。

【0139】

また、第１債務額情報更新部３５８Ｂは、所定口座からの繰り上げ返済額の支払い（すなわち繰り上げ返済）に応じて、債務額情報記憶部３７０内の債務額情報を更新する。なお、所定口座からの繰り上げ返済は、クレジットカード会社Ａに係る口座への入金や、金融機関サーバ２０Ｂからの送金情報等に基づいて確認されてもよい。第１債務額情報更新部３５８は、繰り上げ返済額分だけ債務の金額が減るように債務額情報記憶部３７０内の債務額情報を更新する。

【0140】

繰り上げ返済処理部３６６Ｂは、次の定期的な支払いタイミングよりも前の繰り上げ返済に係る繰り上げ返済額を、増額分算出部３６４により算出された増額分に、自動的に設定する。すなわち、増額分算出部３６４により算出された増額分が０よりも大きい場合、次の定期的な支払いタイミングよりも前の繰り上げ返済額は、増額分算出部３６４により算出された増額分に設定される。増額分算出部３６４により算出された増額分が３．５万円である場合、繰り上げ返済処理部３６６Ｂは、次の定期的な支払いタイミングよりも前の繰り上げ返済額を、３．５万円に自動的に設定する。

【0141】

繰り上げ返済処理部３６６Ｂは、次の定期的な支払いタイミングよりも前の適切なタイミング（例えば、猶予期間内の適切なタイミング）で、繰り上げ返済額を自動的に設定する。例えば、繰り上げ返済処理部３６６Ｂは、０よりも大きい繰り上げ返済額を設定した場合は、当該増額分を繰り上げ返済額とした繰り上げ返済が実現されるように、ユーザに対応付けた繰り上げ返済要求を生成し、生成した繰り上げ返済要求を、金融機関サーバ２０Ｂに送信する。なお、繰り上げ返済要求は、ユーザＩＤとともに繰り上げ返済額を表す情報であってよい。

【0142】

ユーザ情報記憶部３８０Ｂには、会員である各ユーザの登録情報等（図示せず）が記憶される。登録情報は、ユーザＩＤごとに、所定口座を表す口座特定情報や、自動繰り上げ返済機能のオン／オフ情報、締日、支払日、クレジットカードの種別等を表す情報であってよい。なお、口座特定情報は、各ユーザにより初期設定され、その後、いつでも変更可能とされてよい。また、自動繰り上げ返済機能のオン／オフ情報は、自動繰り上げ返済機能を利用するか否かの情報であり、各ユーザにより初期設定され、その後、いつでも変更可能とされてよい。

【0143】

ユーザ端末４０Ｂは、図９に示すように、繰り上げ返済通知部４０２Ｂと、設定変更部４０４とを含む。

【0144】

繰り上げ返済通知部４０２Ｂは、クレジット会社サーバ３０Ｂの繰り上げ返済処理部３６６Ｂによる繰り上げ返済額が設定された場合に、その旨の通知（以下、「繰り上げ返済通知」と称する）を出力する。例えば、繰り上げ返済通知部４０２Ｂは、ユーザ端末４０Ｂの表示部４２上に、繰り上げ返済通知を出力する。当該繰り上げ返済通知は、プッシュ通知の形態であってもよい。その他、繰り上げ返済通知は、メール等で実現されてもよい。なお、繰り上げ返済通知は、繰り上げ返済額が容易に分かるような態様で出力されてよい。また、繰り上げ返済通知は、繰り上げ返済の効果（例えば利息の節約分）が容易に分かるような態様で出力されてよい。

【0145】

なお、繰り上げ返済通知部４０２Ｂは、クレジット会社サーバ３０Ｂの繰り上げ返済処理部３６６Ｂにより繰り上げ返済額が設定されたか否かを任意の方法で判定してもよい。例えば、繰り上げ返済通知部４０２Ｂは、クレジット会社サーバ３０Ｂからの直接的な情報（すなわち繰り上げ返済額が設定された旨の通知）に基づいて、クレジット会社サーバ３０Ｂの繰り上げ返済処理部３６６Ｂにより繰り上げ返済額が設定されたことを把握できる。

【0146】

このような本実施例３によれば、ユーザの所定口座の残高に連動して自動的に、繰り上げ返済が自動的に実現されるので、ユーザはその都度、自身の懐具合を勘案しながら繰り上げ返済の設定を行う必要がなくなる。また、繰り上げ返済の設定を行い忘れる月が発生することで、予期せぬ手数料の増加が生じることがない。また、繰り上げ返済が実現されることで、同繰り上げ返済が実現されずに同額が支払日に増額される場合に比べて、支払日までに発生する利息を低減できる。このようにして、本実施例によれば、リボルビング払いをしたことがない一般的なユーザが感じやすいリボルビング払いの欠点を極力少なくできる。その結果、リボルビング払いのような利子が発生するような支払い形態に対する抵抗感を低減することが可能となる。

【0147】

なお、本実施例３では、口座残高に応じた自動減額機能は、図９に示すように、クレジット会社サーバ３０Ｂが主体となって実現されているが、クレジット会社サーバ３０Ｂの機能の一部又は全部がユーザ端末４０Ｂにより実現されてもよいし、逆に、ユーザ端末４０Ｂの機能の一部又は全部が、クレジット会社サーバ３０Ｂにより実現されてもよい。

【0148】

また、本実施例３は、上述した実施例１や実施例２と組み合わせることも可能である。すなわち、リボルビング払いにおいて、月ごとに、口座残高に応じて、自動繰り上げ返済機能とともに又は自動繰り上げ返済機能に代えて、自動増額機能と自動減額機能のいずれか一方が選択的に実現されてもよい。また、自動増額機能と組み合わせる場合、自動増額機能を実現するための増額分の算出方法と、自動繰り上げ返済機能を実現するための増額分（＝繰り上げ返済額）の算出方法とを、異ならせてもよい。例えば、自動増額機能を実現するための増額分の算出方法と、自動繰り上げ返済機能を実現するための増額分（＝繰り上げ返済額）の算出方法とは、同一条件下（すなわち残高情報と設定額情報とが同じ状況下）で、自動増額機能を実現するための増額分の方が繰り上げ返済額よりも多くなるように、異なってもよい。

【0149】

また、本実施例３では、猶予期間中における所定口座の残高の変動要因として所定口座からの出金だけを考慮しているが、それに代えて又は加えて、猶予期間中における所定口座の残高の変動要因として所定口座への入金を考慮してもよい。

【0150】

次に、図１０のフローチャートを参照して、クレジット会社サーバ３０Ｂの動作例について説明する。

【0151】

図１０は、クレジット会社サーバ３０Ｂにより実現される処理の一例を示す概略フローチャートである。図１０に示す処理は、例えば１日１回のような周期で、繰り返し実行されてよい。ここでは、一例として、図１０に示す処理は、その月の最先の締日からその月の最遅の支払日までの期間だけ、１日１回の周期で繰り返し実行される。

【0152】

ステップＳ１０００では、クレジット会社サーバ３０Ｂは、すべての対象ユーザ（すべての会員のうちの、自動繰り上げ返済機能がオンであるユーザ情報を有するすべてのユーザ、以下同じ）のうち、本日が締日であるユーザが存在するか否かを判定する。なお、各ユーザの締日は、クレジット会社サーバ３０Ｂのユーザ情報記憶部３８０Ｂ内のユーザ情報（図５）に基づいて判定できる。判定結果が“ＹＥＳ”の場合、ステップＳ１００２に進み、それ以外の場合は、ステップＳ１０１８に進む。

【0153】

ステップＳ１００２では、クレジット会社サーバ３０Ｂは、本日が締日であるユーザに対応付けられたユーザＩＤ（以下、単に「ユーザ」とも称する）をすべて抽出する。

【0154】

ステップＳ１００４では、クレジット会社サーバ３０Ｂは、ステップＳ１００２で抽出したユーザに、繰り上げフラグ“１”を対応付ける。繰り上げフラグは、ユーザごとに設定され、“１”である状態は、繰り上げ返済に係る設定対象のユーザであることを示し、“０”である状態は、繰り上げ返済に係る設定対象でないユーザであることを示す。なお、繰り上げフラグの初期値は、“０”とされる。

【0155】

ステップＳ１００６では、クレジット会社サーバ３０Ｂは、繰り上げフラグ“１”が対応付けられたユーザのそれぞれに係る残高情報を、金融機関サーバ２０Ｂに要求する。残高情報は、上述のとおりである。なお、クレジット会社サーバ３０Ｂは、当該要求に応じて金融機関サーバ２０Ｂから送信される残高情報を受信すると、残高情報記憶部３７６を更新する。なお、残高情報記憶部３７６の更新は、残高情報の受信時に実行されてよい。

【0156】

ステップＳ１００８では、クレジット会社サーバ３０Ｂは、繰り上げフラグ“１”が対応付けられたユーザのそれぞれに係る引き落とし予測情報（引き落とし予測部２５２による予測結果）を、金融機関サーバ２０Ｂに要求する。なお、クレジット会社サーバ３０Ｂは、当該要求に応じて金融機関サーバ２０Ｂから送信される引き落とし予測情報を受信すると、引き落とし予測情報記憶部３７８を更新する。

【0157】

ステップＳ１０１８では、クレジット会社サーバ３０Ｂは、すべての対象ユーザのうち、本日が支払日であるユーザが存在するか否かを判定する。なお、各ユーザの支払日は、クレジット会社サーバ３０Ｂのユーザ情報記憶部３８０Ｂ内のユーザ情報（図５）に基づいて判定できる。判定結果が“ＹＥＳ”の場合、ステップＳ１０２０に進み、それ以外の場合は、ステップＳ１０４０に進む。

【0158】

ステップＳ１０２０では、クレジット会社サーバ３０Ｂは、本日が支払日であるユーザに対応付けられたユーザＩＤ（以下、単に「ユーザ」とも称する）をすべて抽出し、適当なルールでソートする。

【0159】

ステップＳ１０２２では、クレジット会社サーバ３０Ｂは、ステップＳ１０２０で抽出したユーザのうちから、一のユーザを選択する。

【0160】

ステップＳ１０２４では、クレジット会社サーバ３０Ｂは、設定額情報記憶部３７２から、選択したユーザに対応付けられた設定額情報を抽出する。

【0161】

ステップＳ１０２８では、クレジット会社サーバ３０Ｂは、ステップＳ１０２４で抽出した設定額情報の設定額を、請求額として設定する。

【0162】

ステップＳ１０３４では、クレジット会社サーバ３０Ｂは、ステップＳ１０２８で設定した請求額に基づいて、選択したユーザに対応付けられた請求額情報を生成する。そして、クレジット会社サーバ３０Ｂは、生成した請求額情報を金融機関サーバ２０Ｂに送信する。なお、この際、クレジット会社サーバ３０Ｂは、選択したユーザに対応付けられたユーザ端末４０Ｂにも、請求額情報の請求額が、所定口座から引き落とされる旨の通知を送信してもよい。

【0163】

ステップＳ１０３６では、クレジット会社サーバ３０Ｂは、ステップＳ１０２０で抽出したすべてのユーザが選択されたか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ１０４０に進み、それ以外の場合は、ステップＳ１０３８に進む。

【0164】

ステップＳ１０３８では、クレジット会社サーバ３０Ｂは、他の一のユーザを選択する。このようにして、ステップＳ１０２０で抽出したすべてのユーザが選択されるまで、ステップＳ１０２４からステップＳ１０３４の処理が繰り返し実行される。

【0165】

ステップＳ１０４０では、クレジット会社サーバ３０Ｂは、すべての対象ユーザのうち、繰り上げフラグ“１”が対応付けられたユーザが存在するか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ１０４２に進み、それ以外の場合は、終了する。

【0166】

ステップＳ１０４２では、クレジット会社サーバ３０Ｂは、繰り上げフラグ“１”が対応付けられたユーザに関して、繰り上げ返済自動設定処理を実行する。繰り上げ返済自動設定処理の一例は、図１１を参照して後述する。

【0167】

図１１は、繰り上げ返済自動設定処理（図１０のステップＳ１０４２）の一例を示す概略フローチャートである。

【0168】

ステップＳ１０４２２では、クレジット会社サーバ３０Ｂは、残高情報が取得されかつ引き落とし予測情報が取得されたユーザが存在するか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ１０４２３に進み、それ以外の場合は、終了する。

【0169】

ステップＳ１０４２３では、クレジット会社サーバ３０Ｂは、残高情報が取得されかつ引き落とし予測情報が取得されたすべてのユーザを抽出し、適当なルールでソートする。

【0170】

ステップＳ１０４２４では、クレジット会社サーバ３０Ｂは、ステップＳ１０４２３で抽出したユーザのうちから、一のユーザを判定対象として選択する。

【0171】

ステップＳ１０４２６では、クレジット会社サーバ３０Ｂは、設定額情報記憶部３７２から、選択したユーザに対応付けられた設定額情報を読み出す。

【0172】

ステップＳ１０４２７では、クレジット会社サーバ３０は、債務額情報記憶部３７０から、選択したユーザに対応付けられた債務額情報を読み出す（取得する）。

【0173】

ステップＳ１０４２８では、クレジット会社サーバ３０Ｂは、制約情報記憶部３７４から、選択したユーザに対応付けられた制約情報を読み出す。

【0174】

ステップＳ１０４２９では、クレジット会社サーバ３０Ｂは、引き落とし予測情報記憶部３７８から、選択したユーザに対応付けられた引き落とし予測情報を読み出す。

【0175】

ステップＳ１０４３０では、クレジット会社サーバ３０Ｂは、残高情報記憶部３７６から、選択したユーザに対応付けられた残高情報を読み出す。

【0176】

ステップＳ１０４３１では、クレジット会社サーバ３０Ｂは、ステップＳ１０４２９で読み出した引き落とし予測情報に基づいて、ユーザに対応付けられた所定口座からの出金（残高情報の更新後における出金）を予測する。出金の予測方法は、上述のとおりであってよい。

【0177】

ステップＳ１０４３２では、クレジット会社サーバ３０Ｂは、ステップＳ１０４２６からステップＳ１０４３０で読み出した設定額情報、債務額情報、制約情報、及び残高情報と、ステップＳ１０４３１での出金の予測結果とに基づいて、増額分を算出する。増額分の算出方法は、上述したとおりであってよい。

【0178】

ステップＳ１０４３３では、クレジット会社サーバ３０Ｂは、ステップＳ１０４３２で算出した増額分が０よりも大きいか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ１０４３４に進み、それ以外の場合は、ステップＳ１０４３７に進む。

【0179】

ステップＳ１０４３４では、クレジット会社サーバ３０Ｂは、ステップＳ１０４３２で算出した増額分を、繰り上げ返済額に設定する。

【0180】

ステップＳ１０４３５では、クレジット会社サーバ３０Ｂは、ステップＳ１０４３４で設定した繰り上げ返済額に基づいて、当該繰り上げ返済額の繰り上げ返済要求を生成し、生成した繰り上げ返済要求を金融機関サーバ２０Ｂに送信する。

【0181】

ステップＳ１０４３６では、クレジット会社サーバ３０Ｂは、今回の判定対象の一のユーザに対応付けられた繰り上げフラグを“０”にリセットする。

【0182】

ステップＳ１０４３７では、クレジット会社サーバ３０Ｂは、ステップＳ１０４２３で抽出したすべてのユーザが、判定対象として選択されたか否かを判定する。判定結果が“ＹＥＳ”の場合、終了し、それ以外の場合は、ステップＳ１０４３８に進む。

【0183】

ステップＳ１０４３８では、クレジット会社サーバ３０Ｂは、他の一のユーザを判定対象として選択する。このようにして、ステップＳ１０４２３で抽出したすべてのユーザが、判定対象として選択されるまで、ステップＳ１０４２６からステップＳ１０４３６の処理が繰り返し実行される。

【0184】

図１０及び図１１に示す処理によれば、各ユーザに対して、締日から支払日までの期間（すなわち猶予期間）において、残高情報に応じて算出された増額分に基づいて繰り上げ返済額が設定されるので、各ユーザは、毎月、繰り上げ返済額を手動で設定する必要がなくなる。これにより、利便性が向上する。

【0185】

なお、上述した実施例３では、繰り上げ返済は、次の定期的な支払いタイミングよりも前に実行されるが、次の定期的な支払いタイミングよりも後に実行されてもよい。すなわち、実行タイミングは、次の定期的な支払いタイミングと異なっていればよい。

【0186】

以上、各実施例について詳述したが、特定の実施例に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形及び変更が可能である。また、前述した実施例の構成要素を全部又は複数を組み合わせることも可能である。

【符号の説明】

【0187】

１ 金融情報処理システム
４ ネットワーク
２０、２０Ａ、２０Ｂ 金融機関サーバ
３０、３０Ａ、３０Ｂ クレジット会社サーバ
４０、４０Ａ、４０Ｂ ユーザ端末
４１ 処理装置
４２ 表示部
２５０ 残高情報生成部
２５２ 引き落とし予測部
２５２Ａ 入金予測部
２５４ 支払実行部
２５５ 返済実行部
２５６ 残高履歴記憶部
３５０ 残高情報取得部
３５１ 引き落とし予測情報取得部
３５１Ａ 入金予測情報取得部
３５２ 債務額情報取得部
３５４ 設定額情報取得部
３５６、３５６Ａ 制約情報取得部
３５８ 第１債務額情報更新部
３６０ 第２債務額情報更新部
３６２、３６２Ａ 出金予測部
３６４ 増額分算出部
３６４Ａ 減額分算出部
３６６ 増額補正部
３６６Ａ 減額補正部
３６６Ｂ 繰り上げ返済処理部
３６８ 請求額情報送信部
３７０ 債務額情報記憶部
３７２ 設定額情報記憶部
３７４ 制約情報記憶部
３７６ 残高情報記憶部
３７８ 引き落とし予測情報記憶部
３７８Ａ 入金予測情報記憶部
３８０、３８０Ａ、３８０Ｂ ユーザ情報記憶部
４０２ 増額補正通知部
４０２Ａ 減額補正通知部
４０２Ｂ 繰り上げ返済通知部
４０４ 設定変更部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】