JP5902731B2 - 返済シミュレーションシステム - Google Patents

Description

本発明は、返済シミュレーションシステムおよび返済シミュレーション方法に関する。

クレジットカードが一般に普及してから久しいが、近年では、クレジットカード決済に対する返済について、「リボルビング払い」方式による返済が利用されつつある。リボルビング払いは、毎月予め指定した一定額を返済する方式である。回数指定の分割払いが、決済がされる毎に個別に支払い回数などを指定するものであるのに対し、リボルビング払いは、各々の決済に対してではなく残高全体について毎月返済することによって合計残高を減額する方式となる。

上述したリボルビング払いでは、一旦、クレジットカード決済を行い、支払い回数を１回または複数回で指定した後に、当該決済に対する返済をリボルビング払いに変更する、いわゆる「あとからリボ」（あとリボ）サービスが展開されつつある。あとリボサービスの利用例として、例えば、クレジットカード利用者がクレジットカード決済に対する毎月の返済に窮すると、一部またはすべての未払い決済をリボルビング払いに変更することが考えられる。

日本クレジットカード協会、"買い物シミュレーション リボｄｅお買い物♪"、［online］、日本クレジットカード協会ホームページ、［平成25年11月29日検索］、インターネット（URL：http://www.jcca-office.gr.jp/consumer/revolving） 三井住友カード株式会社、"あとからリボ"、［online］、三井住友カード株式会社ホームページ、［平成25年11月29日検索］、インターネット（URL：https://www.smbc-card.com/mem/revo/revoato.jsp）

ところで、上述したあとリボサービスを利用してリボルビング払いに変更する場合は、利用者の未払い決済から、一部またはすべての未払い決済を選択してリボルビング払いに変更するのが通常である。しかしながら、実際には、利用者は自身の未払い決済のうちどの決済をリボルビング払いに変更するかについては関心がなく、単に、「毎月の支払いをいくらにしたい」と考えることが多い。このように考える利用者が多い中で、現実に発生しているクレジットカード会社の対応は以下の通りとなる。１）利用者は、自身が利用しているクレジットカード会社に電話をし、毎月の希望支払い額をオペレータに伝える。２）オペレータは、それに応じて、利用者のすべての未払い決済を参照して、どの未払い決済をリボルビング払いに変更すれば利用者の希望支払い額になるか（近づくか）を手動で計算する。３）オペレータは、再度、利用者に連絡をして、リボルビング払いに変更するかの合意をとり、実際にリボルビング払いへの変更手続きを行う。

上述した状況下において、オペレータによる、どの未払い決済をリボルビング払いに変更すれば利用者の希望支払い額になるかの計算は複雑であることが多く、また、計算が手動であるため、計算ミスのおそれもある。このことは、近年の小額決済が多くなるにつれてより一層顕著になる。

非特許文献１では、リボルビング払いのシミュレーションを行うシステムが開示されている。当該シミュレーションシステムを利用することで、手動による計算ではなく予め定義されたルールに基づいて、リボルビング払いによる支払い額を算出するので、その算出支払い額は正確なものとなる。しかし、当該システムは、新規にリボルビング払いを利用する際に支払い額を算出することを想定したものであり、未払い決済が存在する状況で、利用者のリボルビング枠やリボルビング残高などを考慮して支払い額を算出するものではない。

非特許文献２では、実際の利用者個々の未払い決済のレコードを表示して、その中からリボルビング払いに変更するレコードを選択して、支払い方法の変更を受け付けるシステムが開示されている。しかしながら、当該システムは、希望支払い額の算出を行うわけではなく、単に、未払い決済の一部またはすべてをリボルビング払いの変更を実行することができることに留まる。

本発明は、このような問題に鑑みてなされたものであり、利用者が希望する毎月の支払い額を入力することのみによって、当該利用者の未払い決済レコードを参照して、希望支払い額に最も近くなる額を算出することができる、返済シミュレーションシステムおよび返済シミュレーション方法を提供することを目的とする。

上記の課題を解決するために、本発明に係る返済シミュレーション方法は、クレジットカード決済における毎月の希望支払い額を算出するための、コンピュータにより実行される方法であって、前記コンピュータは、クレジットカード決済利用者のクレジットカード決済の決済額を含む決済履歴データを記憶した決済履歴データ記憶部と、前記クレジットカード決済利用者の毎月支払い額を含む利用者データを記憶した利用者データ記憶部とを備え、前記方法は、前記コンピュータに接続されたクライアントコンピュータから入力された利用者識別番号および希望支払い額を受信するステップと、前記受信した利用者識別番号に基づいて、前記決済履歴データ記憶部から決済履歴データレコードを取得するステップと、前記受信した利用者識別番号に基づいて、前記利用者データ記憶部から利用者データレコードを取得するステップと、前記取得した決済履歴データレコードに含まれる決済額を加算するステップと、前記受信した希望支払い額、前記加算した決済額、および、前記取得した利用者データレコードに含まれる毎月支払い額に基づいて、リボルビング変更額を算出するステップと、前記算出したリボルビング変更額に基づいて、前記取得した決済履歴データレコードの中から、リボルビング払いに変更する決済履歴データレコードを判定するステップとを備えたことを特徴とする。

本発明に係る返済シミュレーションシステムおよび返済シミュレーション方法によれば、利用者が希望する毎月の支払い額を入力することのみによって、当該利用者の未払い決済レコードを参照して、希望支払い額に最も近くなる額を算出することが可能になり、ひいては、従来から問題となっているオペレータの作業負担を軽減し、計算ミスを防ぐことができる。

本発明の一実施形態に係る返済シミュレーションシステムのネットワーク構成の例を示す図である。 本発明の一実施形態に係る返済シミュレーションシステムの詳細な構成の例を示すブロック図である。 本発明の一実施形態に係る返済シミュレーションシステムが実行する一連の処理を示すフローチャートである。 本発明の一実施形態に係る利用者データ記憶部４００の例を示す図である。 本発明の一実施形態に係る決済履歴データ記憶部５００の例を示す図である。 本発明の一実施形態に係る返済シミュレーション入力インタフェース６００の例を示す図である。 本発明の一実施形態に係る返済シミュレーション入力インタフェース７００の例を示す図である。 本発明の一実施形態に係る返済シミュレーションシステムが実行するリボルビング変更データを選択する処理を示すフローチャートである。 図５で示した決済履歴データ記憶部５００を更新した決済履歴データ記憶部９００の例を示す図である。

以下、添付した図面を参照して、本発明の実施形態に係る返済シミュレーションシステムを詳細に説明する。

図１は、本発明の一実施形態に係る返済シミュレーションシステムのネットワーク構成の例を示す図である。

返済シミュレーションサーバ１０１は、リボルビング払いへの変更受付サービスなどを提供するコンピューティングデバイスであり、本発明に係る返済シミュレーションシステムの主要な機能を備えるコンピューティングデバイスである。返済シミュレーションサーバ１０１は、専用線などのネットワーク１０２を介して１０３ａ、１０３ｂ、・・・、１０３ｎ（以下、「クライアントコンピュータ１０３」）と通信を行うように構成されている。

クライアントコンピュータ１０３は、本発明に係る返済シミュレーションシステムを提供する事業者に所属するオペレータ（以下、「オペレータ」）などが使用する端末であり、クライアントコンピュータから希望支払い額の入力を行い、その結果がクライアントコンピュータ１０３の表示部に表示される。なお、本実施形態では、クライアントコンピュータ１０３はオペレータによって使用されることを想定しているが、このような形式に限定されない。例えば、返済シミュレーションサーバ１０１とクライアントコンピュータ１０３とをインターネットなどのネットワークを介して接続して、クレジットカード利用者（以下、「利用者」）がクライアントコンピュータ１０３を使用して、ＷＥＢ画面上で本システムを利用する構成にしてもよい。

上述した返済シミュレーションサーバ１０１は、１つまたは複数のコンピューティングデバイスによって構成されてもよい。また、上述したクライアントコンピュータ１０３は、例えば、通信機能を備えるパーソナルコンピュータ、ワークステーション、ＰＤＡなどの情報端末機器であってもよい。コンピューティングデバイスおよび情報端末機器は、中央処理装置（ＣＰＵ）、メモリ、記憶装置などを備えるコンピューティングデバイスであって、メモリまたは記憶装置に格納されたコンピュータプログラムをＣＰＵが処理することによって統括的に制御され、本発明に係る処理を実行し、その機能を実現することができる。なお、上述したシステム構成は、例示のためのものであり、本発明を実行することができるシステム構成を限定するものではない。

次に、図２のブロック図を参照して、上述した返済シミュレーションシステムの構成を詳細に説明する。返済シミュレーションサーバ１０１は、制御部２０１、主記憶部２０３、補助記憶部２０４、入力部２０５、出力部２０６、ネットワークＩ／Ｆ２０７、およびデータベース２０８を備え、それら各要素がシステムバス２０２を介して接続される。

制御部２０１は、中央処理装置（ＣＰＵ）とも呼ばれ、上記各構成要素の制御やデータの演算を行い、また、補助記憶部２０４に格納されている各種プログラムを主記憶部２０３に読み出して実行する。

主記憶部２０３は、メインメモリとも呼ばれ、返済シミュレーションサーバ１０１が受信した入力データ、コンピュータ実行可能な命令および当該命令による演算処理後のデータなどを記憶する。

補助記憶部２０４は、ハードディスク（ＨＤＤ）などに代表される記憶装置であり、データおよびプログラムを長期的に保存する際に使用される。主記憶部２０３は、補助記憶部２０４よりも記憶容量が相対的に小さいため、一時的なデータの記憶や演算処理などに使用されるのに対し、補助記憶部２０４は、必要なデータの長期的な記憶および保存のために使用される。つまり、制御部２０１がプログラムを実行してデータの演算を行う場合には、補助記憶部２０４から必要なデータやプログラムを主記憶部２０３に読み出し、演算結果のデータを長期的に記憶・保存するには制御部２０１が補助記憶部２０４に演算結果のデータを書き込む。

入力部２０５は、クライアントコンピュータ１０３からの希望支払い額の入力などをネットワークＩ／Ｆ２０７を介して受信する。

出力部２０６は、クライアントコンピュータ１０３からの希望支払い額の入力などを受信して、返済シミュレーション処理を実行した後に、その実行結果を出力する。実行結果はネットワークＩ／Ｆを介してクライアントコンピュータ１０３に送信される。

データベース２０８は、後述する利用者データ記憶部４００および決済履歴データ記憶部５００などのデータテーブルを備える。

クライアントコンピュータ１０３は、ネットワークＩ／Ｆ２１１および表示部２１２を備える。ネットワークＩ／Ｆ２１１は、返済シミュレーションサーバ１０１とクライアントコンピュータ１０３との間の通信に使用されるインタフェースである。表示部２１２は、返済シミュレーション入力インタフェースを表示する。

次に、図３のフローチャートを使用して、本発明の一実施形態に係る返済シミュレーションシステムが実行する一連の処理を説明する。

利用者から、返済シミュレーションの依頼、すなわち、「毎月の支払い額をいくらにしたい」との依頼があったものとする。この利用者は、リボルビング支払い条件が「元利定額」、毎月支払い額が１００００円、リボルビング残高が０円、リボルビング枠が５０００００円、および、合計が６８０００円となる未払い決済を有していることを前提とする。「元利定額」支払いとは、リボルビング払いにおいて、予め指定した一定額を支払い、その中から利息を差し引いた金額を元利返済に充当する方式をいう。その他に「元金定額」、「元利定率」または「元金定率」方式などの支払い方式が存在するが、これらの支払い方式はリボルビング払いにおいて公知な支払い方式であるので、本明細書での説明は省略する。毎月支払い額とは、リボルビング払いにおいて、毎月、最低限支払う必要がある支払い額である。リボルビング残高は、現在有している未払い決済のうち、リボルビング払いを利用した未払い決済額の合計額である。リボルビング枠は、リボルビング払いを利用することができる金額の合計であり、リボルビング残高がリボルビング枠を超えることはできない。

オペレータは、クライアントコンピュータ１０３の表示部２１２に表示された返済シミュレーション入力インタフェースに、利用者の利用者番号を入力する（Ｓ３０１）。入力した利用者番号は、ネットワークＩ／Ｆ２１１を介して返済シミュレーションサーバ１０１に送信される。

返済シミュレーションサーバ１０１の入力部２０５は、利用者番号をネットワークＩ／Ｆ２０７を介して受信する（Ｓ３０２）。そして、返済シミュレーションサーバ１０１の制御部２０１は、当該利用者番号をキーに利用者データ記憶部４００から該当の利用者の利用者データレコードを取得する（Ｓ３０３）。

利用者データ記憶部４００は、図４で示すように、利用者のデータを記憶したデータベーステーブルであり、各利用者を識別する「利用者番号」、「氏名」、「カード期限」、「リボルビング枠」（円）、「リボルビング残高」（円）、「リボルビング支払い条件」および「毎月支払い額」（円）を備える。項目「リボルビング支払い条件」は、例えば、「１」（元利定額）、「２」（元金定額）などの値を有してもよい。

次に、制御部２０１は、Ｓ３０２で受信した利用者番号をキーに決済履歴データ記憶部５００から該当の利用者の決済履歴データレコードを取得する（Ｓ３０４）。

決済履歴データ記憶部５００は、図５で示すように、利用者のそれまでの決済履歴のデータを記憶したデータベーステーブルであり、「Ｎｏ．」（識別番号）、「利用者番号」、「利用日」（年月日）、「決済額」（円）、「利率」（％）、「支払い方法」、「業種コード」、「加盟店コード」および「払込フラグ」を備える。項目「支払い方法」は、例えば、「１」（１回払い）、「２」（２回払い）、「３」（毎月払い）、「９」（リボルビング払い）、などの値を有してもよい。項目「利率」は、各決済の支払いに適用される手数料率を示す。項目「業種コード」は、クレジットカード決済を利用した利用先店舗などの業種（例えば、百貨店、スーパー、サービス役務など）を識別するコードである。項目「加盟店コード」は、クレジットカード決済を利用した利用先店舗などの名称を識別するコードである。項目「払込フラグ」は、各決済履歴データレコードが、支払い済みであるか否かを示すフラグが設定され、本項目が空白の場合は、「未払い」であることを示す。

次に、返済シミュレーションサーバ１０１の出力部２０６は、上記取得した利用者データレコードおよび決済履歴データレコードを、ネットワークＩ／Ｆ２０７を介してクライアントコンピュータ１０３に送信する（Ｓ３０５）。

クライアントコンピュータ１０３は、上記送信された利用者データレコードおよび決済履歴データレコードを、ネットワークＩ／Ｆ２１１を介して受信する。そして、表示部２１２に表示した返済シミュレーション入力インタフェースに、上記受信した利用者データレコードおよび決済履歴データレコードを表示する（Ｓ３０６）。なお、この表示の際に、「利用場所・加盟店」を表示しているが、返済シミュレーションサーバ１０１またはクライアントコンピュータ１０３が、加盟店コードと対応する「加盟店名」を備えるデータベーステーブルを有してもよく（図示せず）、当該テーブルを参照して、該当の加盟店コードに対応する「加盟店名」を取得する構成にしてもよい。

上述した利用者データレコードおよび決済履歴データレコードを表示した返済シミュレーション入力インタフェース６００の例を、図６を参照して説明する。

返済シミュレーション入力インタフェース６００に表示された各項目には、Ｓ３０６で受信した利用者データレコードおよび決済履歴データレコードのデータが表示されている。希望支払い額入力ボックス６０１は、利用者が毎月の支払い額として希望する希望支払い額を入力するための入力ボックスである。変更前支払い額表示６０２に表示された「変更前支払い額」は、現時点での未払い決済額の合計額を示している。図６に示す、Ｎｏ．１乃至１１の各決済レコードは、利用日の昇順で表示されているが、利率順、決済額順などで表示してもよい。支払い方法指定選択メニュー６０３は、「１回払い」、「２回払い」などの支払い方法を選択することができる選択メニューである。例えば、本選択メニューで「１回払い」が選択されると、後述の処理において、支払い方法が１回払いの決済履歴データのみがリボルビング変更対象になるか否かの判定がされる。利率順指定選択メニュー６０４は、「低額優先」または「高額優先」などの利率順にリボルビング変更対象となるか否かの判定がされるかを指定することができる選択メニューである。例えば、本選択メニューで「低額優先」が選択されると、利率が低い順に決済履歴データがリボルビング変更対象となるか否かの判定がされ、「高額から」が選択されるとその逆になる。決済額順指定選択メニュー６０５は、「高額から」または「低額から」などの決済額順にリボルビング変更対象となるか否かの判定がされるかを指定することができる選択メニューである。例えば、本選択メニューで「高額から」が選択されると、利用額が高い順に決済履歴データがリボルビング変更対象となるか否かの判定がされ、「低額から」が選択されるとその逆になる。利用日順指定選択メニュー６０６は、「古い優先」または「新しい優先」などの利用日順にリボルビング変更対象となるか否かの判定がされるかを指定することができる選択メニューである。本選択メニューで「古い優先」が選択されると、利用日が古い順に決済履歴データがリボルビング変更対象になるか否かの判定がされ、「新しい優先」が選択されるとその逆になる。上述した利率順指定選択メニュー６０４、決済額順指定選択メニュー６０５および利用日順指定選択メニュー６０６の選択は、それぞれ組み合わせて選択することができるようにしてもよく、この場合は、順序指定優先度選択メニュー６０７により上記各々の順序選択を優先度付けしてもよい。図６の例では、利率が低利率順でかつ決済額が高額順にリボルビング変更対象として選択される。

次に、オペレータは、クライアントコンピュータ１０３の表示部２１２に表示された返済シミュレーション入力インタフェースの希望支払い額入力ボックス６０１に、利用者の希望支払い額を入力する（Ｓ３０７）。入力した希望支払い額は、ネットワークＩ／Ｆ２１１を介して返済シミュレーションサーバ１０１に送信される。

返済シミュレーションサーバ１０１の入力部２０５は、希望支払い額をネットワークＩ／Ｆ２０７を介して受信する（Ｓ３０８）。そして、返済シミュレーションサーバ１０１の制御部２０１は、Ｓ３０４で取得した決済履歴データレコードから、リボルビング変更対象となる決済履歴データレコード（以下、「リボルビング変更データ」）を選択する（Ｓ３０９）。リボルビング変更データの選択方法の詳細は、図８のフローチャートを参照して説明する。

まず、制御部２０１は、Ｓ３０４で取得したすべての決済履歴データレコードの決済額を加算して、未払い合計決済額を算出する（Ｓ３０９１）。図５の決済履歴データ記憶部５００を例にすると、Ｎｏ．１乃至１１のレコードの決済額を全て加算し、６８０００円として算出する。
未払い合計決済額＝決済履歴データレコードの決済額の合計 式１

次に、制御部２０１は、Ｓ３０４で取得したすべての決済履歴データレコードの中から、リボルビング変更をすることができない決済履歴データ（以下、「リボルビング変更不可データ」）を選択する（Ｓ３０９２）。ここで、リボルビング変更不可データとは、例えば、月払い指定したクレジットカード決済など、リボルビング払いが認められていないクレジットカード決済のレコードをいう。リボルビング変更不可データについては、項目「業種コード」にリボルビング変更不可として指定された業種コードが設定される。リボルビング変更不可データの選択は、例えば、「業種コード」および「リボルビング変更可否フラグ」を含むデータベーステーブルを設け（図示せず）、各決済履歴データレコードの業種コードをキーに上述したデータベーステーブルのリボルビング変更可否フラグの値を参照して、リボルビング変更不可データであるか否かを判定するような構成にしてもよい。図５の決済履歴データ記憶部５００を例にすると、Ｎｏ．１１のレコードが該当するものとする（支払い方法が「３」（月払い）であり、業種コード「１３２」がリボルビング変更不可として指定されている）。

次に、制御部２０１は、Ｓ３０３で取得した利用者データレコードの項目「リボルビング残高」の値に、Ｓ３０９１で算出した未払い合計決済額を加算して、加算済みリボルビング残高を算出する（Ｓ３０９３）。
加算済みリボルビング残高＝リボルビング残高＋未払い合計決済額 式２

次に、制御部２０１は、加算済みリボルビング残高と、Ｓ３０３で取得した利用者データレコードの項目「リボルビング枠」の値を比較して、加算済みリボルビング残高が多い場合は、加算済みリボルビング残高とリボルビング枠との差分をリボルビング超過額として算出する（Ｓ３０９４）。リボルビング残高がリボルビング枠を超えると、その超えた額分はリボルビング変更できなくなる。
リボルビング超過額＝加算済みリボルビング残高−リボルビング枠 式３

次に、制御部２０１は、Ｓ３０８で受信した希望支払い額から、Ｓ３０９２で選択したリボルビング変更不可データの決済額（以下、リボルビング変更不可額）と、リボルビング超過額と、Ｓ３０３で取得した利用者データレコードの項目「毎月支払い額」の金額とを減算して、リボルビング非変更額を算出する（Ｓ３０９５）。図５の決済履歴データ記憶部５００および図６の返済シミュレーション入力インタフェース６００を例にすると、希望支払い額３００００円から、リボルビング変更不可額１００００円（決済履歴データレコードのＮｏ．１１の決済額１００００円）とリボルビング超過額０円と毎月支払い額１００００円とを減算し、１００００円として算出する。
リボルビング非変更額＝希望支払い額−（リボルビング変更不可額＋リボルビング超過額＋毎月支払い額） 式４

次に、制御部２０１は、Ｓ３０９１で算出した未払い合計決済額から、リボルビング非変更額と、リボルビング変更不可額と、リボルビング超過額とを減算して、リボルビング変更額を算出する（Ｓ３０９６）。本実施形態では、未払い合計決済額６８０００円から、リボルビング非変更額１００００円とリボルビング変更不可額１００００円とリボルビング超過額０円とを減算し、４８０００円として算出する。
リボルビング変更額＝未払い合計決済額−（リボルビング非変更額＋リボルビング変更不可額＋リボルビング超過額） 式５

次に、制御部２０１は、Ｓ３０４で取得したすべての決済履歴データレコードから、Ｓ３０９２で選択したリボルビング変更不可データを除いたレコード（以下、リボルビング変更候補データ）から、所定の順番で、各レコードの決済額をリボルビング変更額から減算（各レコードの決済額をリボルビング変更額に充当する）する。そして、この減算を、リボルビング変更額がゼロ以下になるまで繰り返す。最終的に、リボルビング変更額を充当することができたすべてのリボルビング変更候補データがリボルビング変更データとして選択される。逆に、充当することができなかったリボルビング変更候補データが、リボルビング非変更データとして選択される（Ｓ３０９７）。ここで、所定の順番とは、１）利率が低い（高い）レコードから順番に充当（図６の返済シミュレーション入力インタフェース６００の利率順指定選択メニュー６０４で「低率優先」（「高率優先」）を選択した場合）、２）決済額が高い（低い）レコードから順番に充当（図６の返済シミュレーション入力インタフェース６００の決済額順指定選択メニュー６０５で「高額から」（「低額から」）を選択した場合、３）利用日が古い（新しい）レコードから順番に充当（図６の返済シミュレーション入力インタフェース６００の利用日順指定選択メニュー６０６で「古い優先」（「新しい優先」）を選択した場合）、のいずれかの順番で充当してもよい。上記利率順（低率）で充当していく場合は、利率の低い決済から順にリボルビング払いに変更されるので、利用者に対してより有利な利率となるような支払い額を算出することができる。

図５の決済履歴データ記憶部５００を例にすると、例えば、利率が低利率順でかつ決済額が高額順に充当していく場合、以下のように、リボルビング変更額４８０００円がゼロになるまで繰り返す。

表１の例では、Ｎｏ．６、７、４、９、５、２、１０および１のレコードについては充当可能となってリボルビング変更データとなる。一方、Ｎｏ．８および３については充当不可となってリボルビング非変更データとなる。なお、Ｎｏ．１のレコードについては、２０００円分（以下、「超過充当額」）の充当ができておらず、このような場合は、Ｎｏ．１レコードの決済額すべてをリボルビング変更してもよく、または、Ｎｏ．１レコードの決済額すべてをリボルビング変更しなくてもよい。Ｎｏ．１のすべての決済額をリボルビング変更する場合は、リボルビング変更額が５００００円となり、リボルビング非変更額から超過充当額２０００円を減算して再計算される。一方、すべて変更しない場合は、リボルビング変更額が４００００円となり、リボルビング非変更額に８０００円（Ｎｏ．１の決済額−超過充当額）を加算して再計算される。本実施形態では、Ｎｏ．１のすべての決済額をリボルビング変更するものとする。

なお、図６の返済シミュレーション入力インタフェース６００の支払い方法指定選択メニュー６０３で「１回払い」を選択した場合、支払い方法が「１回払い」の決済履歴データのみがリボルビング払いの対象となるので、上述した未払い合計決済額の算出（式１）において、支払い方法が「１回払い」以外の決済履歴データを加算対象から除外してもよい。同様に、その他の支払い方法（例えば、「２回払い」）が選択された場合、当該支払い方法以外の決済履歴データが式１における加算対象から除外される。このようにして、例えば、１回払いのみを対象にリボルビング変更することによって、様々な支払い方法での決済回数が多い（例えば、１回払い、２回払い、月払いなどの決済が混在）利用者にとって、リボルビング払いに変更した後も自身の支払いを把握することが容易になる。

次に、制御部２０１は、リボルビング非変更額と、リボルビング変更不可額と、リボルビング超過額と、毎月支払い額とを加算して、変更後支払い額を算出する（Ｓ３０９８）
変更後支払い額＝リボルビング非変更額＋リボルビング変更不可額＋リボルビング超過額＋毎月支払い額） 式６

以上のようにして、リボルビング変更データおよびリボルビング非変更データが選択されて、図８のフローチャートを終了する。なお、変更後支払い額については、決済額に対して利率を乗じて算出されるが、説明を簡潔にするために利率を考慮しないで説明した。

次に、図３のフローチャートに戻り、返済シミュレーションサーバ１０１の出力部２０６は、上記選択したリボルビング変更データ、リボルビング非変更データ、リボルビング変更不可データおよび変更後算出額などを含む、返済シミュレーション結果データをネットワークＩ／Ｆ２０７を介してクライアントコンピュータ１０３に送信する（Ｓ３１０）。ここで、本実施形態では、返済シミュレーション結果データにはリボルビング変更データ、リボルビング非変更データおよびリボルビング変更不可データが含まれる構成になっているが、このような構成に限定されず、例えば、それらのレコードの項目「Ｎｏ．」（識別子）のみを含める構成にしてもよい。この場合は、クライアントコンピュータ１０３が、Ｓ３０６で受信した決済履歴データレコードから、上記識別子の値によって、リボルビング変更データ、リボルビング非変更データまたはリボルビング変更不可データであるかを判定してもよい。

クライアントコンピュータ１０３は、上記送信された返済シミュレーション結果データを、ネットワークＩ／Ｆ２１１を介して受信する。そして、表示部２１２に表示した返済シミュレーション入力インタフェースに、上記受信した返済シミュレーション結果データを表示する（Ｓ３１１）。

上述した返済シミュレーション結果データを表示した返済シミュレーション入力インタフェース７００の例を、図７を参照して説明する。

返済シミュレーション結果データに含まれる変更後支払い額、リボルビング残高およびリボルビング変更額は、返済シミュレーション入力インタフェース７００の変更後支払い額表示７０１、リボルビング残高表示７０２およびリボルビング変更額表示７０３にそれぞれ表示される。また、返済シミュレーション結果データに含まれるリボルビング変更データと、リボルビング非変更データと、リボルビング不可データとは、それぞれ識別可能に表示される。その識別として、本実施形態では、リボルビング変更データについては、リボルビング変更選択チェックボックス７０４がチェックされた状態で表示され（Ｎｏ．６、７、４、９、５、２、１０および１のレコード）、リボルビング非変更データについては、リボルビング変更選択チェックボックス７０４がチェックされていない状態で表示され（Ｎｏ．８および３のレコード）、リボルビング不可データについては、リボルビング変更選択チェックボックス７０４が非表示の状態で表示される（Ｎｏ．１１のレコード）。なお、Ｎｏ．１１のレコードが示す決済は、リボルビング払いに変更することができないことを意味する。

次に、オペレータは、返済シミュレーション入力インタフェース７００に表示されたリボルビング変更データのレコードに対応するリボルビング変更選択チェックボックス７０４をすべてチェックして（本実施形態では、リボルビング取込データに対応するリボルビング変更選択チェックボックス７０４はすでにチェックされているのでそのままの状態で）、実行ボタン７０７を押下する（Ｓ３１２）。チェックしたリボルビング変更データは、ネットワークＩ／Ｆ２１１を介して返済シミュレーションサーバ１０１に送信されるが、必ずしも当該データを送信する必要はなく、当該データの識別子を送信する構成であってもよい。なお、リボルビング変更データのレコードに対応するリボルビング変更選択チェックボックス７０４のうちの一部のチェックボックスのチェックを外した場合は、そのチェックを外したリボルビング変更データについてはリボルビング変更がされなくなる。例えば、図７において、Ｎｏ．１０のレコードに対応するチェックボックスのチェックを外した場合は、そのレコードの決済額３０００円が、リボルビング残高およびリボルビング変更額から減算され、逆に、その額が変更後支払い額に加算されて、それらの額が再計算される。このような場合は、再計算ボタン７０６を押下することによって、再計算されたリボルビング残高、リボルビング変更額および変更後支払い額が再表示される。このようにして、リボルビング払いへの変更を実行する前に、変更後の支払い額を表示することができるので、従来技術と比較して、予め変更後の支払い額を確認してから、リボルビング払いへの変更を実行することができる。

最後に、オペレータが返済シミュレーション入力インタフェース７００の実行ボタン７０６を押下したことに応答して、返済シミュレーションサーバ１０１の制御部２０１は、リボルビング変更データをリボルビング払いに変更する処理を実行する（Ｓ３１２）。リボルビング払いへの変更処理の例を、図９を参照して説明する。

図９は、図５で示した決済履歴データ記憶部５００を、リボルビング払いへの変更処理によって更新した決済履歴データ記憶部９００を示すものである。上述したように、本実施形態では、Ｎｏ．６、７、４、９、５、２、１０および１のレコードについての決済に対する支払い方法がリボルビング払いに変更されるので、それらに対応する決済履歴データ記憶部９００のＮｏ．６、７、４、９、５、２、１０および１の項目「支払い方法」が「９」（リボルビング払い）に更新される。

次に、上記説明したリボルビング変更選択の第２の例を説明する。第２の例では、希望支払い額を３００００円、リボルビング残高を４７００００円として、その他の前提条件は、上述した図８のフローチャートの例と同一とする。この条件で、上記説明した式にあてはめる。
式１ 未払い合計決済額：６８０００円
式２ 加算済みリボルビング残高：５２８０００円
式３ リボルビング超過額：２８０００円
式４ リボルビング非変更額：０円（マイナス値は０円とする）
式５ リボルビング変更額：３００００円
式６ 変更後支払い額：４８０００円

上記算出した値を基に、決済履歴データレコードから、リボルビング変更額を減算（充当）する。

表２から理解できるように、第２の例では、リボルビング変更額が３００００円なので、Ｎｏ．６、７、４および９のレコードのみがリボルビング変更データとして選択され、その他のレコードはすべてリボルビング非変更データとして選択される。このような場合は、リボルビング枠を超過しているので、返済シミュレーション結果データを返済シミュレーション入力インタフェース７００に表示する際に、警告メッセージを表示してもよい（例えば、「一部リボルビング限度超過あり。限度超過分はリボルビング変更できません」）。

次に、上記説明したリボルビング変更選択の第３の例を説明する。第３の例では、希望支払い額を９００００円として、その他の前提条件は、上述した図８のフローチャートの例と同一とする。この条件で、上記説明した式にあてはめる。
式１ 未払い合計決済額：６８０００円
式２ 加算済みリボルビング残高：５８０００円
式３ リボルビング超過額：０円
式４ リボルビング非変更額：７００００円
式５ リボルビング変更額：０円（マイナス値は０円とする）
式６ 変更後支払い額：６８０００円

第３の例では、現在の未払い合計決済額が希望支払い額未満であるので、リボルビング払いに変更する必要がないことを意味する。このように、利用者が自身の決済の詳細を把握しておらず、リボルビング払いに変更する必要がないにも関わらず、勘違いでリボルビング払いに変更しようとした場合に、変更の必要がないことを即座に把握することができる。このような場合は、返済シミュレーション結果データを返済シミュレーション入力インタフェース７００に表示する際に、警告メッセージを表示してもよい（例えば、「毎月支払い額以下のためリボルビング変更されません。確認のうえ実行してください」）。

以上のように、本発明に係る返済シミュレーションシステムの説明を詳述したが、実施形態で説明した、利用者データ記憶部４００および決済履歴データ記憶部５００などの具体的なデータ構造は例示的なものにすぎず、特許請求する事項から逸脱しない範囲で変更がされてもよい。

１０２ ネットワーク
６０１ 希望支払い額入力ボックス
６０２ 変更前支払い額表示
６０３ 支払い方法指定選択メニュー
６０４ 利率順指定選択メニュー
６０５ 決済額順指定選択メニュー
６０６ 利用日順指定選択メニュー
７０１ 変更後支払い額表示
７０２ リボルビング残高表示
７０３ リボルビング変更額表示
７０４ リボルビング変更選択チェックボックス
７０５ 変更後支払い方法表示
７０６ 再計算ボタン
７０７ 実行ボタン

Claims (6)

1. クレジットカード決済における希望支払い額を算出するための、コンピュータにより実行される方法であって、前記コンピュータは、クレジットカード決済利用者のクレジットカード決済の決済額を含む決済履歴データを記憶した決済履歴データ記憶部と、前記クレジットカード決済利用者の毎月支払い額、リボルビング枠、およびリボルビング残高を含む利用者データを記憶した利用者データ記憶部とを備え、
   前記方法は、
   前記コンピュータに接続されたクライアントコンピュータから入力された利用者識別番号および希望支払い額を受信するステップと、
   前記受信した利用者識別番号に基づいて、前記決済履歴データ記憶部から決済履歴データレコードを取得するステップと、
   前記受信した利用者識別番号に基づいて、前記利用者データ記憶部から利用者データレコードを取得するステップと、
   前記取得した決済履歴データレコードに含まれる決済額を加算することによって、合計決済額を算出するステップと、
   前記算出した合計決済額を前記利用者データレコードに含まれるリボルビング残高に加算することによって、加算済みリボルビング残高を算出するステップと、
   前記受信した希望支払い額、前記算出した加算済みリボルビング残高、ならびに、前記取得した利用者データレコードに含まれる毎月支払い額およびリボルビング枠に基づいて、リボルビング変更額を算出するステップと、
   前記リボルビング変更額から、前記取得した各決済履歴データレコードに含まれる決済額を減算し、および、前記減算したリボルビング変更額が正の値になるか否かを判定することによって、前記算出したリボルビング変更額に基づいて、前記取得した決済履歴データレコードの中から、リボルビング払いに変更する決済履歴データレコードを判定するステップと
   を備えたことを特徴とする方法。
2. 前記決済履歴データ記憶部の各レコードは決済利率および利用日をさらに含み、
   前記リボルビング変更額から、前記取得した各決済履歴データレコードに含まれる決済額を減算するステップは、前記取得した決済履歴データレコードに含まれる決済額、決済利率および／または利用日の順序で、前記リボルビング変更額から、前記取得した各決済履歴データレコードに含まれる決済額を減算するステップを含む
   ことを特徴とする請求項１に記載の方法。
3. クレジットカード決済における希望支払い額を算出するためのコンピュータシステムであって、前記コンピュータシステムはクライアントコンピュータに接続され、
   クレジットカード決済利用者の決済履歴データを記憶した決済履歴データ記憶部であって、前記決済履歴データ記憶部の各レコードは決済額を含む、決済履歴データ記憶部と、
   前記クレジットカード決済利用者の利用者データを記憶した利用者データ記憶部であって、前記利用者データ記憶部の各レコードは、毎月支払い額、リボルビング枠、およびリボルビング残高を含む、利用者データ記憶部と、
   前記クライアントコンピュータから入力された利用者識別番号および希望支払い額を受信する受信部と、
   前記受信した利用者識別番号に基づいて、前記利用者データ記憶部から利用者データレコードを取得する利用者データ取得部と、
   前記受信した利用者識別番号に基づいて、前記決済履歴データ記憶部から決済履歴データレコードを取得する決済履歴データ取得部と、
   前記取得した決済履歴データレコードに含まれる決済額を加算することによって、合計決済額を算出する合計決済額算出部と、
   前記算出した合計決済額を前記利用者データレコードに含まれるリボルビング残高に加算することによって、加算済みリボルビング残高を算出する加算済みリボルビング残高算出部と、
   前記受信した希望支払い額、前記算出した加算済みリボルビング残高、ならびに、前記取得した利用者データレコードに含まれる毎月支払い額およびリボルビング枠に基づいて、リボルビング変更額を算出するリボルビング変更額算出部と、
   前記リボルビング変更額から、前記取得した各決済履歴データレコードに含まれる決済額を減算し、および、前記減算したリボルビング変更額が正の値になるか否かを判定することによって、前記算出した前記リボルビング変更額に基づいて、前記取得した決済履歴データレコードの中から、リボルビング払いに変更する決済履歴データレコードを判定するリボルビング払い判定部と
   を備えたことを特徴とするコンピュータシステム。
4. 請求項１または２に記載の方法をコンピュータに実行させるためのプログラム。
5. 請求項４に記載のプログラムを記録したコンピュータ可読記憶媒体。
6. プロセッサとメモリとを備えたコンピュータであって、前記メモリは前記プロセッサに請求項１または２に記載の方法を実行させるプログラムを記録したことを特徴とするコンピュータ。

Images