JP2004220395A

JP2004220395A - Credit system using portable information terminal

Info

Publication number: JP2004220395A
Application number: JP2003007908A
Authority: JP
Inventors: Kenichi Igarashi; 健一五十嵐
Original assignee: Honda Motor Co Ltd; Honda Finance Co Ltd
Current assignee: Honda Motor Co Ltd; Honda Finance Co Ltd
Priority date: 2003-01-16
Filing date: 2003-01-16
Publication date: 2004-08-05

Abstract

<P>PROBLEM TO BE SOLVED: To realize a low-cost technique for a secure reimbursement by a customer having a credit loan contract. <P>SOLUTION: A server connected to a network comprises a first storing device for storing information regarding a customer and information regarding a credit loan contract of the customer, a second storing device for storing a template for editing an electronic mail addressed to the customer, means for receiving payment result data notifying a payment by the customer from a bank, a mailer sending/receiving electronic mails, and a payment confirmation program started in response to arrival of a payment schedule date defined in the contract information. The payment confirmation program determines whether or not a payment is executed on the payment schedule date on the basis of the payment result data. When the program determined that the payment is not executed, a template for requesting payment is extracted from the second storing device, a mail address of a portable information terminal of the customer is extracted from the first storing device, and the electronic mail is edited and transmitted to the portable information terminal of the customer. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

【０００１】
【発明の属する技術分野】
この発明は、携帯情報端末を利用したクレジットシステムに関する。
【０００２】
【従来の技術】
自動車のような高額商品の購入は、クレジットローンやリースを利用することが多い。例えば、自動車のクレジットローンを契約する場合には、営業所においてクレジットローンの見積もりが行われる。顧客が、該見積もりを承認したならば、クレジットローン契約が行われる。このようなクレジットローンの見積もりを、携帯電話を用いて行う手法が提案されている（例えば、特許文献１参照）。この手法によると、ローンまたはリース契約のための見積もり条件が携帯電話に入力される。サーバは、携帯電話から見積もり条件を受け取り、該条件に応じた見積もり結果を算出する。見積もり結果は、携帯電話または他の出力装置に送信される。
【０００３】
また、携帯電話の料金について、督促を行う手法が提案されている（例えば、特許文献２参照）。この手法によれば、料金の滞納期間に応じて、携帯電話に対して督促または機能制限が行われる。
【０００４】
さらに、携帯電話を用いて、商品購入の決済を行う手法が提案されている（例えば、特許文献３参照）。
【０００５】
【特許文献１】
特開平２００１−１４２９６４号公報
【０００６】
【特許文献２】
特開平２００２−７７３９０号公報
【０００７】
【特許文献３】
特開平２００２−４２０１７号公報
【０００８】
【発明が解決しようとする課題】
クレジットローン契約では、月々の支払い金額および該金額の入金予定日が規定される。所定の入金予定日に所定の金額が入金されない場合、顧客に入金を督促する。通常、この督促は、ダイレクトメールを顧客に送付することによって行われる。
【０００９】
このような督促では、顧客がダイレクトメールを読まなかったり、ダイレクトメールを送付することのコストがかかるという問題があった。また、特に長期にわたってローンを返済するクレジットローン契約の場合、顧客は、所定の口座に所定の金額を入金することを失念してしまう場合がある。
【００１０】
本願発明は、クレジットローン契約をしている顧客に対して定期的に該ローンの返済に注意を向けさせ、確実に返済を実行してもらう安価な手法を実現するシステムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
この発明の一つの側面によると、顧客の携帯情報端末が接続可能なネットワークに接続されたクレジット・コンピュータ・システムが提供される。該システムは、顧客に関する情報および該顧客のクレジットローン契約に関する情報を記憶する第１の記憶装置と、顧客宛の電子メールを編集するためのテンプレートを記憶する第２の記憶装置と、金融機関から、前記顧客による入金を知らせる入金結果データを受信する手段を備える。さらに、該システムは、第１の記憶装置に記憶されたクレジットローン契約情報に規定される入金予定日が到来したことに応答して起動される入金確認プログラムを備える。入金確認プログラムは、（ａ）受信した入金結果データに基づいて、クレジットローン契約情報に規定される金額の入金が入金予定日に行われたかどうかを判断するステップと、（ｂ）入金が行われていないと判断されたならば、第２の記憶装置から、入金依頼用のテンプレートを抽出し、第１の記憶装置から、前記顧客の携帯情報端末のメールアドレスを抽出して、電子メールを編集するステップと、（ｃ）編集された電子メールを、顧客の携帯情報端末に送信するステップと、を実行する。
【００１２】
この発明によると、入金予定日に入金が行われなかった顧客の携帯情報端末に、入金依頼が記述された電子メールが自動的に送信されるので、入金を直接かつタイムリーに顧客に催促することができる。また、督促作業にかけるコストを安くすることができる。
【００１３】
この発明の一実施形態によると、入金確認プログラムは、さらに、上記のステップ（ａ）によって入金が行われたと判断したならば、第１の記憶装置に記憶されたクレジットローン契約情報を参照し、該顧客のクレジットローン契約上のローンが完済したかどうかを判断する。顧客のクレジットローン契約のローンが完済したと判断されたならば、第２の記憶装置から、該完済を通知するためのテンプレートを抽出し、第１の記憶装置から、該顧客の携帯情報端末のメールアドレスを抽出して、電子メールを編集する。編集された電子メールは、顧客の携帯情報端末に送信される。こうして、顧客は、自身のローンが完済されたことをタイムリーに知ることができる。
【００１４】
この発明の他の実施形態によると、入金確認プログラムは、さらに、上記のステップ（ａ）によって入金が行われたと判断されたならば、第２の記憶装置から、入金確認を通知するためのテンプレートを抽出し、第１の記憶装置から、該顧客の携帯情報端末のメールアドレスを抽出して、電子メールを編集する。編集された電子メールは、顧客の携帯情報端末に送信される。こうして、顧客は、今回の返済処理が成功裡に終了したことをタイムリーに知ることができる。
【００１５】
この発明の他の実施形態によると、入金確認プログラムは、さらに、第１の記憶装置に記憶されたクレジットローン契約情報に基づいて、該クレジットローン契約についての再見積もりを算出する。第２の記憶装置から、算出された再見積もりを提案するためのテンプレートを抽出し、第１の記憶装置から、該顧客の携帯情報端末のメールアドレスを抽出して、電子メールを編集する。編集された電子メールは、顧客の携帯情報端末に送信される。この発明によれば、顧客に有利となるローン組み替えを該顧客に提案することができる。
【００１６】
この発明の他の実施形態によると、入金確認プログラムは、さらに、第２の記憶装置から、顧客の今後の返済予定を知らせるためのテンプレートを抽出し、第１の記憶装置から、該顧客の携帯情報端末のメールアドレスを抽出して、電子メールを編集する。編集された電子メールは、顧客の携帯情報端末に送信される。この発明によると、顧客が入金を忘れることを防止することができる。
【００１７】
この発明の他の実施形態によると、クレジットローン契約に関する情報は、顧客の返済状況を示すデータを含む。再見積もりは、顧客の返済状況を示すデータに応じて算出される。
【００１８】
この発明によると、確実に入金が実施されるように、または早期返済によって顧客に有利になるように、ローン組み替えを顧客に促すことができる。
【００１９】
この発明の他の実施形態によるとクレジットローン契約に関する情報は、さらに、延滞カウンタ含む。上記のステップ（ｂ）は、さらに、延滞カウンタをインクリメントするステップを含む。顧客の返済状況を示すデータは、該顧客の過去の入金処理に関連付けられた延滞カウンタの値に基づいて生成されることができる。
【００２０】
この発明の他の実施形態によると、クレジットローン契約に関する情報は、前記ネットワークに接続可能な携帯情報端末上で生成され該クレジット・コンピュータ・システムにアップロードされた見積もり情報に基づいて生成される。この発明によると、携帯情報端末を用いて、顧客と対面しながら、クレジットローン契約のための見積書を作成することができる。
【００２１】
この発明の他の実施形態によると、携帯情報端末からシステムにアップロードされる見積もり情報は、顧客の運転免許証の画像データを含む。該システムは、さらに、前記運転免許証の画像データを文字データに変換するステップと、変換された文字データに基づいて、見積もり情報に含まれるデータと文字データとを照合するステップと、を実行する本人確認プログラムを備える。システムは、さらに、変換された文字データを用いて、顧客についてのクレジット審査に必要な情報を生成するプログラムを備えることができる。運転免許証の画像データを用いることにより、本人確認やクレジット審査を、高い信頼性で実施することが可能となる。
【００２２】
【発明の実施の形態】
次に図面を参照して、この発明の実施の形態を説明する。図１は、この発明の一実施例に従うクレジット・コンピュータ・システムの全体的なブロック図である。クレジット会社であるＸのサーバ２は、インターネット１に接続されている。サーバ２には、クレジットローンの契約処理を実施する契約エンジン１１と、クレジットローン契約に沿った入金が顧客によって行われているかどうかを監視する監視エンジン１２と、を備える。これらのエンジンは、典型的には、コンピュータプログラムによって実現される。
【００２３】
サーバ２の記憶装置（外部記憶装置でもよいし、メモリでもよい）上には、顧客データベース１３が設けられている。顧客データベース１３は、それぞれの顧客についての基本データ、契約データおよび返済状況データを格納する。基本データは、顧客の名前、ＩＤ、住所、電話番号、電子メールアドレス等の顧客の属性に関する情報を含む。契約データは、顧客のクレジットローン契約に関する情報を含む、返済状況データは、顧客のクレジットローン契約に対する返済状況に関する情報を含む。さらに、それぞれの顧客について、延滞カウンタが設けられている。延滞カウンタは、初期値としてゼロがセットされる。延滞カウンタは、それぞれの入金処理における延滞の回数をカウントする。
【００２４】
サーバ２の記憶装置（外部記憶装置でもよいし、メモリでもよい）上には、さらに、テンプレートファイル１４が設けられている。テンプレートファイル１４には、顧客宛ての電子メールを作成するための複数のテンプレートが格納されている。
【００２５】
自動車の販売を行う営業員は、インターネット１への接続機能を備えた携帯電話３を所有する。携帯電話３には、クレジットローンの見積もり処理を実施する見積もりエンジン１５が搭載されている。見積もりエンジン１５は、典型的にはコンピュータプログラムによって実現される。携帯電話３は、見積もりエンジン１５を、インターネット１を介してクレジットサーバ２からダウンロードすることができる。営業員は、顧客と対面しながら、該顧客のためのクレジットローンの見積もりを、該携帯電話３に搭載された見積もりエンジン１５を起動することによって行う。
【００２６】
見積もりエンジン１５は、いくつかの所定のフォームを備えている。これらのフォームは、携帯電話３のメモリに予め記憶される。必要に応じて、サーバ２から該フォームをダウンロードしてもよい。
【００２７】
顧客は、携帯電話４を所有している。顧客携帯電話４も、インターネット１への接続機能を備えている。携帯電話３および４は、このようなインターネットへの接続機能を備えた、ＰＤＡのような携帯情報端末でもよい。
【００２８】
サーバ２、営業員の携帯電話３および顧客の携帯電話４は、電子メールの送受信機能を搭載しており、該機能により、サーバ２、営業員の携帯電話３および顧客の携帯電話４の間で、インターネット１を介して電子メールを送受信することができる。さらに、サーバ２、営業員の携帯電話３および顧客の携帯電話４は、ファイル転送機能を搭載しており、、該機能により、サーバ２、営業員の携帯電話３および顧客の携帯電話４の間で、インターネット１を介してファイルを転送することができる。
【００２９】
所定の審査機関の予審サーバ５および所定の銀行の銀行サーバ６が、インターネット１に接続されている。予審サーバ５は、クレジットサーバ２から受信した顧客情報に基づいて、該顧客を審査するプログラムを備えている。会社Ｘが予審機関を備えている場合には、該予審サーバ５によって実現される機能をクレジットサーバ２に設けてもよい。
【００３０】
銀行サーバ６は、クレジットサーバ２から受信した請求データに基づいて、所定の日に所定の金額を顧客の口座から引き落とすプログラムを備えている。引き落とした結果のデータは、銀行サーバ６からクレジットサーバ２に返信される。
【００３１】
クレジットサーバ２、予審サーバ５および銀行サーバ６の間のネットワークは、インターネット１とは異なるネットワーク（例えば、専用回線）を用いてもよい。
【００３２】
図２は、本発明の一実施形態に従うクレジットシステムによって実施される処理の概念的な流れを示す。ステップＳ１において、クレジットローン契約のための見積もり処理を行う。見積もり処理は、営業員携帯電話３に設けられた見積もりエンジン１５によってローカル的に実施される。代替的に、見積もりエンジン１５をサーバ２に設け、サーバ２と通信しながら見積もり処理を行うようにしてもよい。
【００３３】
ステップＳ２において、クレジットローンの契約処理を行う。契約処理は、サーバ２に設けられた契約エンジン１１によって実施される。クレジットローンの契約処理は、顧客の本人確認、顧客の審査、および契約書作成等の処理を含む。
【００３４】
ステップＳ３において、所定の日に顧客の口座から所定の金額をクレジット会社に振り替えるための請求データを生成する処理が実施される。この処理は、契約エンジン１１によって実施されることができる。請求データは、銀行サーバ６に送信される。
【００３５】
ステップＳ４において、クレジットローンの監視処理を行う。監視処理は、サーバ２に設けられた監視エンジン１２によって実施される。監視処理は、顧客データベース１３に格納されたクレジットローン契約情報に従って、顧客によって入金が実施されたかどうかを監視する処理を含む。監視処理は、ローン残高が存在する限り実施される。
【００３６】
図３は、図２のステップＳ１に示される見積もり処理の詳細なフローチャートを示す。図４は、該見積もり処理で営業員携帯電話３または顧客携帯電話４に表示される画面例を示す。図３および図４を参照しながら、クレジットローンの見積もり処理を説明する。
【００３７】
以下の説明において、「指示」は、営業員によって携帯電話３上の所定のキーが押されたことに応答して、または所定のメニューが選択されたことに応答して発行される命令を示す。「指示」が発行されたことに応答して、見積もりエンジン１５は、該「指示」に対応する処理を行う。
【００３８】
ステップＳ１１において、携帯電話３上で「見積もり処理」が指示された時、該ルーチンは開始する。見積もりエンジン１５は、見積もり計算フォームを表示する（Ｓ１２）。図４の（ａ）は、「支払い回数指定」用の見積もりフォームである。他のフォーム（たとえば、支払額指定用のフォーム）を、キーの操作またはメニュー項目の選択等によって表示させることもできる。営業員は、見積もりフォームに、携帯電話３上のキーを用いて、年率、所要資金、支払い回数等のデータを入力する。
【００３９】
データ入力を終えた後、計算指示が発行されたならば（Ｓ１３）、見積もりエンジン１５は、見積もりフォームに入力されたデータに基づき、見積もり計算する（Ｓ１４）。見積もり計算した結果は、携帯電話３の画面上に表示される（Ｓ１５）。図４の（ｂ）には、見積もり結果として、月々の支払額、ボーナス時の支払額等が表示されている。
【００４０】
営業員は、顧客が見積もり結果に納得するまで、見積もり計算を繰り返すことができる。その場合、見積もり計算フォームにデータが入力されたことに応答して、ステップＳ１３〜Ｓ１５が繰り返し実施される。
【００４１】
顧客が見積もり結果に納得したならば、営業員は、携帯電話３上で見積もり終了の指示を出す。見積もり終了の指示が出されたならば（Ｓ１６）、見積もりエンジン１５は、見積もり結果を、顧客携帯電話４に送信する。見積もり結果は、電子メールとして送信してもよいし、ファイルとして送信してもよい。代替的に、該見積もり結果にＵＲＬを関連づけ、該ＵＲＬのみを顧客携帯電話に送信してもよい。顧客は、自身の携帯電話４上で見積もり結果を参照することができる。該見積もり結果は、顧客携帯電話４のメモリに格納することができる。
【００４２】
見積もりエンジン１５は、営業員携帯電話３のメモリから申込みフォームを抽出する。申込みフォームは、予め携帯電話３のメモリに格納しておくこともできるし、サーバ２からダウンロードすることもできる。見積もりエンジン１５は、申込みフォームに、上記の見積もり結果を挿入し、表示する（Ｓ１９）。図４の（ｃ）には、見積もり結果が挿入された申込みフォームが示されている。
【００４３】
申込みフォームは、顧客の携帯電話４に転送される。顧客は、自身の名前および住所等のデータを申込みフォームに入力する。代替的に、営業員の携帯電話３上で、申込みフォームに該顧客に関するデータを入力してもよい。
【００４４】
顧客に関するデータが入力された申込みフォームは、営業員の携帯電話３に返信される。営業員は、携帯電話３に設けられたカメラにより、顧客の運転免許証を撮影する。撮影された運転免許証は、画像データとして携帯電話３のメモリに格納される。携帯電話３上で画像データの取り込み指示が出されたことに応答して、見積もりエンジン１５は、該画像データを申込みフォームに取り込む（Ｓ２０）。図４の（ｄ）に、運転免許証の画像データが取り込まれた申込みフォームを示す。
【００４５】
代替的に、運転免許証に記載されたデータを、営業員が、携帯電話３のキーを用いて申込みフォームに入力することもできる。または、運転免許証の画像データを、申込みフォームとは異なるファイルとして、メモリに格納することができる。この場合、運転免許証の画像データは、申込みフォームに関連付けられるのが好ましい。
【００４６】
営業員は、申込みフォームの完成指示を出す。該指示に応答して（Ｓ２１）、見積もりエンジン１５は、顧客の基本データ（名前および住所等）、見積もり結果、および運転免許証の画像データを含む申込みデータを生成する（Ｓ２２）。
【００４７】
見積もりエンジン１５は、申込みデータを、クレジットサーバ２に送信する（Ｓ２３）。送信は、電子メール、ファイル、ＵＲＬのいずれの形態でもよい。運転免許証の画像データは、申込みデータの添付ファイルとして送信されてもよい。クレジットサーバ２への受信が完了したならば、該クレジットサーバ２から、申込みデータのコピーが、控えとして営業員携帯電話３および顧客携帯電話４に転送される。申込みデータのコピーは、携帯電話３および４のメモリに格納されることができる。営業員および顧客は、必要に応じて、申込みデータの内容を参照することができる。
【００４８】
図５は、図３のステップＳ２において実施されるクレジットローン契約の詳細な処理を示すフローチャートである。該ルーチンは、申込みデータを営業員携帯電話３から受信した時に開始される（Ｓ３１）。
【００４９】
契約エンジン１１は、申込みデータに含まれる（または添付される）運転免許証の画像データを、ＯＣＲ機能を用いて文字データに変換する（Ｓ３２）。変換された文字データは、クレジットサーバ２に接続された端末上で閲覧することができる。該端末で、変換された文字データに対して修正することもできる。
【００５０】
契約エンジン１１は、申込みデータの内容と免許証の文字データとを照合することで、本人確認作業を実施する（Ｓ３３）。例えば、顧客名、住所等について照合が実施される（Ｓ３３）。
【００５１】
本人確認作業には、クレジット会社の担当者が、申込みデータに含まれる顧客の電話番号に電話をかけることを含むことが多い。この作業のために、申込みデータに含まれる顧客の電話番号を端末画面に表示したり、印刷装置で印刷したりするようにしてもよい。また、顧客の電子メールアドレスを確認するために、顧客の携帯電話４に電子メールを送信することを含んでもよい。
【００５２】
契約エンジン１１は、本人確認が合格したならば（Ｓ３４）、申込みデータに基づいて予審用データを生成する（Ｓ３５）。予審用データは、クレジットローンを許可するかどうかの審査に必要とされるデータである。予審用データは、予審サーバ５に送信される。
【００５３】
必要に応じて、営業員携帯電話３は、審査の経過を契約エンジン１１に照会することができる。予審サーバ５から審査結果を受信したならば（Ｓ３６）、契約エンジン１１は、該審査結果を営業員携帯電話３に送信する（Ｓ３７）。
【００５４】
審査を合格したならば（Ｓ３８）、契約エンジン１１は、申込みデータに従って契約データを生成し、該契約データを顧客データベース１３に格納する（Ｓ３９）。さらに、契約エンジン１１は、契約データに基づいて契約書を作成し、これを印刷装置で出力する。契約書は営業所に郵送され、顧客によって契約書への署名および押印が行われる。署名および押印がなされた契約書は、会社Ｘに郵送され、契約書の控えは顧客に郵送される。契約が成立したことを通知する電子メールを、顧客携帯電話４に送信してもよい。
【００５５】
契約エンジン１１は、契約データに基づいて返済予定データを生成し、顧客データベース１３に格納する（Ｓ４０）。返済予定データは、月々の支払い額および入金予定日を含む。返済予定データは、返済予定表として印刷され、顧客に郵送される。該返済予定表を、電子メールによって顧客携帯電話４に送信してもよい。
【００５６】
図６は、図２のステップＳ３で実施される、金融機関への請求データを生成する処理を示す。該ルーチンは、基準日が到来したことに応答して起動される。基準日は、顧客の口座から所定の金額をクレジット会社に振り替える口座振替日に基づいて設定される。たとえば、基準日は、口座振替日の１０日前等に設定される。
【００５７】
基準日が到来したならば、契約エンジン１１は、顧客データベースに格納された契約データに基づいて請求データを生成する（Ｓ５２）。請求データには、顧客の口座、該口座から引き落とす日、および引き落とす金額が含まれる。請求データは、銀行サーバ６に送信される（Ｓ５３）。
【００５８】
図７は、図２のステップＳ４で実施される監視処理のフローチャートである。該ルーチンは、入金予定日が到来したときに開始される（Ｓ５５）。顧客の口座からの自動引き落としの場合は、入金予定日は引き落とし日を示す。銀行サーバ６による引き落とし作業が行われた後、上記請求データの結果が、クレジットサーバ２に送信される。一方、顧客自身によって所定の口座に入金される場合には、該入金の結果を示すデータが銀行サーバ６（または、他の代金回収機関）から送信される。または、サーバ２から銀行サーバ６（または、他の代金回収機関）にアクセスして、入金結果を取得するようにしてもよい。ステップＳ５６では、これらの入金結果を示すデータを受信したかどうかを判断する。
【００５９】
入金結果データを受信したならば、ステップＳ５７において、該入金結果データから、入金のあった顧客名（顧客の口座または顧客ＩＤでもよい）を識別する。監視エンジン１２は、該入金が行われた顧客について顧客データベース１３を参照し、今回の入金によって、顧客のクレジットローンが完済したかどうかを判断する（Ｓ５９）。
【００６０】
完済ならば、監視エンジン１２は、今回の入金により完済されたことを通知するテンプレートをテンプレートファイル１４から抽出し、該顧客の携帯電話のメールアドレスを顧客データベース１３から抽出し、電子メールを編集する。該完済通知用のテンプレートには、完済を知らせる定型文が記述されている。該テンプレートに、顧客名、完済額および完済日等を挿入することで、電子メールを編集する。編集された電子メールは、顧客の携帯電話４に送信される（Ｓ６０）。
【００６１】
完済でなければ、今回の入金について確認がとれたこと、および今後の（または次回の）返済予定を通知するテンプレートをテンプレートファイル１４から抽出し、顧客携帯電話４のメールアドレスを設定して電子メールを編集する。該電子メールは、顧客の携帯電話４に送信される（Ｓ６１）。図１０の（ａ）に、返済予定メールの一例が示されている。入金確認と返済予定とは、別の電子メールとして送信してもよい。返済予定メールは、入金予定日の所定期間前（例えば、入金予定日の１週間前）に送信するようにしてもよい。
【００６２】
ステップＳ６２において、現在の延滞カウンタの値を、今回の入金処理における返済状況を示すデータとして保存する。
【００６３】
たとえば、クレジットローン契約において支払い回数が「６回」ならば、返済状況データは６個の数字で表されることができる。各数字は、各入金処理における延滞カウンタの値を示す。たとえば、「０１００００」という返済状況データは、２回目の入金処理における延滞カウンタの値が１であったことを示す。すなわち、２回目の入金処理において、１回の延滞が起こったことを示す。
【００６４】
返済状況データは、評価データを含むこともできる。評価データは、過去の延滞カウンタの値に応じて設定されることができる。たとえば、評価データは、Ａ〜Ｄの４段階で表されることができる。延滞カウンタが３以上の入金処理が所定回数以上起こった顧客についての評価データには、最も低い評価を示す“Ｄ”が設定される。
【００６５】
返済状況データを更新した後で、ステップＳ６３において、延滞カウンタをゼロにクリアする。ステップＳ６４において、再見積もり処理（図９）を実施する。
【００６６】
ステップＳ５７において、監視エンジン１２は、入金が行われなかった顧客について、該顧客について設けられた延滞カウンタを１だけインクリメントする（Ｓ６５）。ステップＳ６６において、延滞処理ルーチン（図８）を実施する。
【００６７】
図８は、図７のステップＳ６６において実行される延滞処理ルーチンを示す。ステップＳ７１において、顧客の延滞カウンタの値を調べる。延滞カウンタが２以下ならば、入金依頼用のテンプレートをテンプレートファイル１４から抽出し、顧客データベース１３から該顧客携帯電話４のメールアドレスを抽出して、電子メールを編集する。編集された電子メールは、該顧客の携帯電話４に送信される（Ｓ７２）。該電子メールには、該顧客の入金すべき金額、振り込むべき口座、および入金期限等の情報を記述することができる。該電子メールには、支払い日を返信してもらうよう依頼する記述を含めてもよい。図１０の（ｂ）には、該入金依頼メールの一例が示されている。
【００６８】
顧客の支払い日（振り込み日）、すなわち新たな入金予定日が設定される（Ｓ７３）。新たな入金予定日は、監視エンジン１２によって自動的に算出されるようにしてもよい。該新たな入金予定日は、顧客データベース１３に登録される。
【００６９】
こうして、新たな入金予定日が到来した時、図７に示される監視ルーチンが再び実行される。該新たな入金予定日において、顧客による入金が行われなければ、ステップＳ６５において延滞カウンタがさらに１だけインクリメントされ、延滞処理ルーチンが実行される。
【００７０】
延滞回数（すなわち、延滞カウンタの値）が３以上になると、ステップＳ７１の判断がＹｅｓとなる。ステップＳ７４に進み、電話等による督促を実施するため、該顧客に関する基本データおよび契約データを顧客データベース１３から抽出する。抽出した情報は、印刷出力してもよいし、端末の画面上に表示するようにしてもよい。
【００７１】
図９は、図７のステップＳ６４において実施される再見積もり処理ルーチンを示す。
【００７２】
ステップＳ９１において、顧客についての返済状況データを調べる。返済状況が良好ならば、早期返済用の再見積もりデータを算出する（Ｓ９２）。早期返済用の再見積もりデータは、たとえば、現在のクレジットローン契約に規定されたローンの完済予定日を繰り上げるように、月々の支払い額を増やした場合の再見積もりデータである。これにより、現在のローン返済に比べて節約できる金額を顧客に呈示することができる。
【００７３】
返済状況が良好でないならば、返済を遅らせる再見積もりデータを算出する。たとえば、現在のクレジットローン契約に規定されたローンの完済予定日を繰り下げるように、月々の支払いが額を少なくした場合の再見積もりデータである。こうして、確実に返済することができるように、クレジットローン契約を見直すよう顧客を促すことができる。
【００７４】
返済状況が良好かどうかは、延滞カウンタの値に応じて、または評価データの値に応じて判断することができる。たとえば、値３以上の延滞カウンタの値を持たなければ、良好と判断し、値３以上の延滞カウンタの値を持てば、良好でないと判断する。または、評価データがＡまたはＢならば良好と判断し、ＣまたはＤならば良好でないと判断する。
【００７５】
ステップＳ９４において、ステップＳ９２または９３で作成された再見積もりデータを挿入するためのテンプレートをテンプレートファイル１４から抽出し、該顧客の携帯電話４のメールアドレスを設定して、電子メールを編集する。該電子メールは、顧客の携帯電話４に送信される。
【図面の簡単な説明】
【図１】この発明の一実施例のシステムの全体的な構成を示すブロック図。
【図２】この発明の一実施例における、見積もり処理において携帯電話上に表示される画面例を示す図。
【図３】この発明の一実施例における、クレジット処理のメインルーチンを示す図。
【図４】この発明の一実施例における、見積もり処理ルーチンを示す図。
【図５】この発明の一実施例における、契約処理ルーチンを示す図。。
【図６】この発明の一実施例における、請求データ作成ルーチンを示す図。
【図７】この発明の一実施例における、監視処理ルーチンを示す図。
【図８】この発明の一実施例における、延滞処理ルーチンを示す図。
【図９】この発明の一実施例における、再見積もり処理ルーチンを示す図。
【図１０】この発明の一実施例における、返済予定メールおよび入金依頼メールの一例を示す図。
【符号の説明】
２クレジットサーバ
３営業員携帯電話
４顧客携帯電話
６銀行サーバ[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a credit system using a portable information terminal.
[0002]
[Prior art]
Purchases of high-priced products such as automobiles often use credit loans or leases. For example, when contracting a car credit loan, the sales office estimates the credit loan. If the customer approves the quote, a credit loan contract is made. A method of performing such credit loan estimation using a mobile phone has been proposed (see, for example, Patent Document 1). According to this technique, an estimate for a loan or lease contract is entered into the mobile phone. The server receives an estimation condition from the mobile phone, and calculates an estimation result according to the condition. The estimation result is transmitted to a mobile phone or other output device.
[0003]
Further, a method for prompting a mobile phone charge has been proposed (see, for example, Patent Document 2). According to this technique, a prompt or function restriction is performed on the mobile phone in accordance with the charge delinquency period.
[0004]
Furthermore, a method for making a payment for product purchase using a mobile phone has been proposed (for example, see Patent Document 3).
[0005]
[Patent Document 1]
Japanese Patent Laid-Open No. 2001-142964
[0006]
[Patent Document 2]
Japanese Patent Laid-Open No. 2002-77390
[0007]
[Patent Document 3]
JP-A-2002-42017
[0008]
[Problems to be solved by the invention]
In the credit loan contract, a monthly payment amount and a scheduled payment date of the amount are defined. If a predetermined amount is not deposited on a predetermined scheduled payment date, the customer is prompted to deposit. This reminder is usually done by sending a direct mail to the customer.
[0009]
Such a reminder has a problem that the customer does not read the direct mail or the cost of sending the direct mail is high. In particular, in the case of a credit loan contract that repays a loan over a long period of time, a customer may forget to deposit a predetermined amount into a predetermined account.
[0010]
An object of the present invention is to provide a system that realizes a low-cost method for paying a loan loan to a customer who has a credit loan contract on a regular basis so that the loan is surely executed. To do.
[0011]
[Means for Solving the Problems]
According to one aspect of the present invention, a credit computer system connected to a network to which a customer's personal digital assistant can be connected is provided. The system includes a first storage device that stores information related to a customer and information related to the customer's credit loan contract, a second storage device that stores a template for editing an email addressed to the customer, and a financial institution. And means for receiving deposit result data informing the deposit by the customer. Further, the system includes a payment confirmation program that is activated in response to the scheduled payment date specified in the credit loan contract information stored in the first storage device. The payment confirmation program includes (a) a step of determining whether or not a payment of the amount specified in the credit loan contract information has been performed based on the received payment result data, and (b) a payment is performed. If it is determined that it is not, the template for deposit request is extracted from the second storage device, the email address of the customer's portable information terminal is extracted from the first storage device, and the email is edited. And (c) transmitting the edited electronic mail to the customer's portable information terminal.
[0012]
According to the present invention, since an e-mail in which a deposit request is described is automatically transmitted to the mobile information terminal of the customer who has not received the deposit on the scheduled deposit date, the customer is prompted to deposit directly and in a timely manner. be able to. In addition, the cost for the dunning work can be reduced.
[0013]
According to one embodiment of the present invention, the payment confirmation program further refers to the credit loan contract information stored in the first storage device when it is determined that the payment has been made in the step (a). It is determined whether the loan on the customer's credit loan contract has been paid off. If it is determined that the loan of the customer's credit loan contract has been paid off, a template for notifying the payment is extracted from the second storage device, and the customer's portable information terminal is extracted from the first storage device. Extract email address and edit email. The edited e-mail is transmitted to the customer's portable information terminal. In this way, the customer can know in a timely manner that his loan has been paid off.
[0014]
According to another embodiment of the present invention, the payment confirmation program further provides a template for notifying the payment confirmation from the second storage device if it is determined that the payment has been made in the step (a). Is extracted from the first storage device, and the e-mail is edited by extracting the e-mail address of the mobile information terminal of the customer. The edited e-mail is transmitted to the customer's portable information terminal. In this way, the customer can know in a timely manner that the current repayment process has been completed successfully.
[0015]
According to another embodiment of the present invention, the payment confirmation program further calculates a re-estimation for the credit loan contract based on the credit loan contract information stored in the first storage device. A template for proposing the calculated re-estimation is extracted from the second storage device, the mail address of the mobile information terminal of the customer is extracted from the first storage device, and the email is edited. The edited e-mail is transmitted to the customer's portable information terminal. According to the present invention, loan recombination that is advantageous to the customer can be proposed to the customer.
[0016]
According to another embodiment of the present invention, the payment confirmation program further extracts a template for informing a customer's future repayment schedule from the second storage device, and the customer's mobile phone from the first storage device. Extract the email address of the information terminal and edit the email. The edited e-mail is transmitted to the customer's portable information terminal. According to the present invention, it is possible to prevent the customer from forgetting the deposit.
[0017]
According to another embodiment of the present invention, the information related to the credit loan contract includes data indicating the repayment status of the customer. The re-estimation is calculated according to data indicating the customer's repayment status.
[0018]
According to the present invention, it is possible to prompt the customer to change the loan so that the deposit is surely performed or the customer can be favored by early repayment.
[0019]
According to another embodiment of the present invention, the information regarding the credit loan contract further includes an arrears counter. Step (b) above further includes the step of incrementing the arrears counter. Data indicating a customer's repayment status can be generated based on a past due counter value associated with the customer's past deposit process.
[0020]
According to another embodiment of the present invention, information related to a credit loan contract is generated based on estimate information generated on a portable information terminal connectable to the network and uploaded to the credit computer system. According to the present invention, it is possible to create an estimate for a credit loan contract while facing a customer using a portable information terminal.
[0021]
According to another embodiment of the present invention, the estimated information uploaded from the portable information terminal to the system includes image data of the customer's driving license. The system further performs a step of converting the image data of the driver's license into character data, and a step of collating data included in the estimation information with character data based on the converted character data. Provide identity verification program. The system may further include a program for generating information necessary for credit review about the customer using the converted character data. By using the image data of the driver's license, it becomes possible to carry out identity verification and credit examination with high reliability.
[0022]
DETAILED DESCRIPTION OF THE INVENTION
Next, an embodiment of the present invention will be described with reference to the drawings. FIG. 1 is an overall block diagram of a credit computer system according to one embodiment of the present invention. The X server 2 which is a credit company is connected to the Internet 1. The server 2 includes a contract engine 11 that performs a credit loan contract process, and a monitoring engine 12 that monitors whether or not payment is made in accordance with the credit loan contract. These engines are typically realized by computer programs.
[0023]
On the storage device of the server 2 (which may be an external storage device or a memory), a customer database 13 is provided. The customer database 13 stores basic data, contract data, and repayment status data for each customer. The basic data includes information about customer attributes such as customer name, ID, address, telephone number, and email address. The contract data includes information on the customer's credit loan contract, and the repayment status data includes information on the repayment status of the customer's credit loan contract. In addition, an arrears counter is provided for each customer. The arrears counter is set to zero as an initial value. The arrears counter counts the number of arrears in each deposit process.
[0024]
A template file 14 is further provided on the storage device of the server 2 (which may be an external storage device or a memory). The template file 14 stores a plurality of templates for creating an e-mail addressed to a customer.
[0025]
A salesperson who sells automobiles owns a mobile phone 3 having a function of connecting to the Internet 1. The mobile phone 3 is equipped with an estimation engine 15 that performs credit loan estimation processing. The estimation engine 15 is typically realized by a computer program. The mobile phone 3 can download the estimation engine 15 from the credit server 2 via the Internet 1. The salesperson makes an estimate of a credit loan for the customer while facing the customer by activating the estimation engine 15 mounted on the mobile phone 3.
[0026]
The estimation engine 15 comprises several predetermined forms. These forms are stored in advance in the memory of the mobile phone 3. The form may be downloaded from the server 2 as necessary.
[0027]
The customer owns the mobile phone 4. The customer mobile phone 4 also has a function of connecting to the Internet 1. The mobile phones 3 and 4 may be portable information terminals such as PDAs having such a function of connecting to the Internet.
[0028]
The server 2, the salesperson's mobile phone 3, and the customer's mobile phone 4 are equipped with an e-mail transmission / reception function. With this function, the server 2, the salesperson's mobile phone 3, and the customer's mobile phone 4 Electronic mail can be transmitted and received via the Internet 1. Further, the server 2, the salesperson's mobile phone 3 and the customer's mobile phone 4 are equipped with a file transfer function, which enables the server 2, the salesperson's mobile phone 3 and the customer's mobile phone 4 to be connected. Thus, the file can be transferred via the Internet 1.
[0029]
A preliminary examination server 5 of a predetermined examination organization and a bank server 6 of a predetermined bank are connected to the Internet 1. The preliminary examination server 5 includes a program for examining the customer based on the customer information received from the credit server 2. When the company X has a trial organization, the credit server 2 may be provided with a function realized by the trial server 5.
[0030]
The bank server 6 includes a program for debiting a predetermined amount from a customer account on a predetermined day based on the billing data received from the credit server 2. The data of the withdrawal result is returned from the bank server 6 to the credit server 2.
[0031]
As a network between the credit server 2, the trial server 5, and the bank server 6, a network (for example, a dedicated line) different from the Internet 1 may be used.
[0032]
FIG. 2 shows a conceptual flow of processing performed by a credit system according to an embodiment of the present invention. In step S1, an estimate process for a credit loan contract is performed. The estimation process is performed locally by the estimation engine 15 provided in the salesperson mobile phone 3. Alternatively, the estimation engine 15 may be provided in the server 2 and the estimation process may be performed while communicating with the server 2.
[0033]
In step S2, a credit loan contract process is performed. The contract process is performed by a contract engine 11 provided in the server 2. Credit loan contract processing includes processing such as customer identity verification, customer review, and contract creation.
[0034]
In step S3, processing for generating billing data for transferring a predetermined amount from a customer's account to a credit company on a predetermined day is performed. This process can be performed by the contract engine 11. The billing data is transmitted to the bank server 6.
[0035]
In step S4, a credit loan monitoring process is performed. The monitoring process is performed by the monitoring engine 12 provided in the server 2. The monitoring process includes a process of monitoring whether or not payment has been performed by the customer in accordance with the credit loan contract information stored in the customer database 13. The monitoring process is performed as long as the loan balance exists.
[0036]
FIG. 3 shows a detailed flowchart of the estimation process shown in step S1 of FIG. FIG. 4 shows an example of a screen displayed on the salesperson mobile phone 3 or the customer mobile phone 4 in the estimation process. The credit loan estimation process will be described with reference to FIGS.
[0037]
In the following description, “instruction” indicates a command issued in response to a salesperson pressing a predetermined key on the mobile phone 3 or in response to a predetermined menu being selected. . In response to the “instruction” being issued, the estimation engine 15 performs processing corresponding to the “instruction”.
[0038]
In step S11, when “estimation processing” is instructed on the mobile phone 3, the routine starts. The estimation engine 15 displays an estimation calculation form (S12). FIG. 4A shows an estimation form for “designation of the number of payments”. Other forms (for example, a payment amount designation form) can be displayed by operating a key or selecting a menu item. The salesperson uses the keys on the mobile phone 3 to enter data such as the annual rate, required funds, and the number of payments in the estimate form.
[0039]
If a calculation instruction is issued after the data input is completed (S13), the estimation engine 15 calculates an estimate based on the data input to the estimation form (S14). The result of the estimation calculation is displayed on the screen of the mobile phone 3 (S15). In FIG. 4B, the monthly payment amount, the bonus payment amount, and the like are displayed as estimation results.
[0040]
The sales employee can repeat the estimation calculation until the customer is satisfied with the estimation result. In that case, steps S13 to S15 are repeatedly performed in response to the data being input to the estimate calculation form.
[0041]
If the customer is satisfied with the estimation result, the sales employee gives an instruction to end the estimation on the mobile phone 3. If an instruction to end the estimation is issued (S16), the estimation engine 15 transmits the estimation result to the customer mobile phone 4. The estimation result may be transmitted as an e-mail or a file. Alternatively, a URL may be associated with the estimation result, and only the URL may be transmitted to the customer mobile phone. The customer can refer to the estimation result on his / her mobile phone 4. The estimation result can be stored in the memory of the customer mobile phone 4.
[0042]
The estimation engine 15 extracts the application form from the memory of the salesperson mobile phone 3. The application form can be stored in advance in the memory of the mobile phone 3 or can be downloaded from the server 2. The estimation engine 15 inserts the above estimation result into the application form and displays it (S19). FIG. 4C shows an application form in which the estimation result is inserted.
[0043]
The application form is transferred to the customer's mobile phone 4. The customer enters his / her name and address data into the application form. Alternatively, data related to the customer may be entered in the application form on the salesperson's mobile phone 3.
[0044]
The application form in which the data related to the customer is input is returned to the salesperson's mobile phone 3. The salesperson photographs the driver's license with the camera provided on the mobile phone 3. The photographed driver's license is stored in the memory of the mobile phone 3 as image data. In response to the image data capture instruction issued on the mobile phone 3, the estimation engine 15 captures the image data into the application form (S20). FIG. 4D shows an application form in which the image data of the driver's license is captured.
[0045]
Alternatively, the data written on the driver's license can be entered into the application form by the salesperson using the key of the mobile phone 3. Alternatively, the image data of the driver's license can be stored in the memory as a file different from the application form. In this case, the image data of the driver's license is preferably associated with the application form.
[0046]
The sales employee gives instructions for completing the application form. In response to the instruction (S21), the estimation engine 15 generates application data including the customer's basic data (name and address, etc.), the estimation result, and the image data of the driver's license (S22).
[0047]
The estimation engine 15 transmits the application data to the credit server 2 (S23). Transmission may be in any form of e-mail, file, or URL. The image data of the driver's license may be transmitted as an attachment file of application data. When the reception to the credit server 2 is completed, a copy of the application data is transferred from the credit server 2 to the salesperson mobile phone 3 and the customer mobile phone 4 as a record. A copy of the application data can be stored in the memory of the mobile phones 3 and 4. The sales staff and the customer can refer to the contents of the application data as necessary.
[0048]
FIG. 5 is a flowchart showing detailed processing of the credit loan contract executed in step S2 of FIG. The routine is started when the application data is received from the salesperson mobile phone 3 (S31).
[0049]
The contract engine 11 converts the image data of the driver's license included in (or attached to) the application data into character data using the OCR function (S32). The converted character data can be viewed on a terminal connected to the credit server 2. The terminal can also correct the converted character data.
[0050]
The contract engine 11 collates the contents of the application data with the character data of the license, thereby performing identity verification work (S33). For example, collation is performed for the customer name, address, etc. (S33).
[0051]
The person identification work often includes a person in charge of the credit company making a call to the customer's telephone number included in the application data. For this operation, the customer's telephone number included in the application data may be displayed on the terminal screen or printed by a printing device. It may also include sending an email to the customer's mobile phone 4 to confirm the customer's email address.
[0052]
If the identity verification has passed (S34), the contract engine 11 generates trial data based on the application data (S35). Preliminary data is data required for examination of whether or not to allow credit loans. The trial data is transmitted to the trial server 5.
[0053]
If necessary, the salesperson mobile phone 3 can query the contract engine 11 about the progress of the examination. If the examination result is received from the preliminary server 5 (S36), the contract engine 11 transmits the examination result to the salesperson's mobile phone 3 (S37).
[0054]
If the examination is passed (S38), the contract engine 11 generates contract data according to the application data, and stores the contract data in the customer database 13 (S39). Further, the contract engine 11 creates a contract based on the contract data, and outputs it on the printing apparatus. The contract is mailed to the sales office, and the contract is signed and stamped by the customer. The signed and signed contract is mailed to Company X, and a copy of the contract is mailed to the customer. An e-mail notifying that the contract has been established may be transmitted to the customer mobile phone 4.
[0055]
The contract engine 11 generates repayment schedule data based on the contract data and stores it in the customer database 13 (S40). The repayment schedule data includes the monthly payment amount and the scheduled payment date. The repayment schedule data is printed as a repayment schedule and mailed to the customer. The repayment schedule may be transmitted to the customer mobile phone 4 by e-mail.
[0056]
FIG. 6 shows processing for generating billing data for the financial institution, which is performed in step S3 of FIG. The routine is activated in response to the arrival of a reference date. The reference date is set based on an account transfer date for transferring a predetermined amount from the customer's account to the credit company. For example, the reference date is set 10 days before the account transfer date.
[0057]
If the reference date has arrived, the contract engine 11 generates billing data based on the contract data stored in the customer database (S52). The billing data includes the customer's account, the date of withdrawal from the account, and the amount to be withdrawn. The billing data is transmitted to the bank server 6 (S53).
[0058]
FIG. 7 is a flowchart of the monitoring process performed in step S4 of FIG. This routine is started when the scheduled deposit date arrives (S55). In the case of automatic debiting from the customer's account, the scheduled deposit date shows the debit date. After the withdrawal operation by the bank server 6 is performed, the result of the billing data is transmitted to the credit server 2. On the other hand, when depositing into a predetermined account by the customer himself / herself, data indicating the result of the deposit is transmitted from the bank server 6 (or another price collection organization). Or you may make it access the bank server 6 (or another price collection organization) from the server 2, and acquire a payment result. In step S56, it is determined whether data indicating these deposit results has been received.
[0059]
If the payment result data is received, in step S57, the name of the customer who received the payment (may be a customer account or customer ID) is identified from the payment result data. The monitoring engine 12 refers to the customer database 13 for the customer who has made the deposit, and determines whether or not the credit loan of the customer has been completed by this deposit (S59).
[0060]
If the payment is completed, the monitoring engine 12 extracts from the template file 14 a template for notifying that payment has been completed, extracts the mail address of the customer's mobile phone from the customer database 13, and edits the email. . In the template for notifying completion, a fixed sentence for notifying completion is described. The e-mail is edited by inserting the customer name, payment amount, payment date, etc. into the template. The edited e-mail is transmitted to the customer's mobile phone 4 (S60).
[0061]
If the payment is not completed, a template for notifying that the current payment has been confirmed and the future (or next) repayment schedule is extracted from the template file 14, and the email address of the customer's mobile phone 4 is set. Edit. The e-mail is transmitted to the customer's mobile phone 4 (S61). FIG. 10A shows an example of a repayment scheduled mail. The payment confirmation and the repayment schedule may be transmitted as separate e-mails. The repayment schedule mail may be transmitted before a predetermined period of the scheduled deposit date (for example, one week before the scheduled deposit date).
[0062]
In step S62, the current value of the arrears counter is stored as data indicating the repayment status in the current deposit process.
[0063]
For example, if the number of payments is “6” in the credit loan contract, the repayment status data can be represented by six numbers. Each number indicates the value of the arrears counter in each deposit process. For example, the repayment status data of “010000” indicates that the value of the arrears counter in the second deposit process is 1. That is, it indicates that one overdue has occurred in the second deposit process.
[0064]
Repayment status data can also include evaluation data. The evaluation data can be set according to the value of the past arrears counter. For example, the evaluation data can be expressed in four stages A to D. “D” indicating the lowest evaluation is set in the evaluation data for a customer who has received a deposit process having an arrears counter of 3 or more for a predetermined number of times.
[0065]
After updating the repayment status data, the arrears counter is cleared to zero in step S63. In step S64, a re-estimation process (FIG. 9) is performed.
[0066]
In step S57, the monitoring engine 12 increments the arrears counter provided for the customer who has not received the deposit by 1 (S65). In step S66, an overdue processing routine (FIG. 8) is performed.
[0067]
FIG. 8 shows an overdue processing routine executed in step S66 of FIG. In step S71, the customer's late counter value is checked. If the arrears counter is equal to or less than 2, the deposit request template is extracted from the template file 14, the mail address of the customer mobile phone 4 is extracted from the customer database 13, and the e-mail is edited. The edited electronic mail is transmitted to the mobile phone 4 of the customer (S72). The e-mail can describe information such as the amount of money to be deposited by the customer, the account to be transferred, and the payment deadline. The electronic mail may include a description requesting that the payment date be returned. FIG. 10B shows an example of the deposit request mail.
[0068]
The customer's payment date (transfer date), that is, a new payment scheduled date is set (S73). The new scheduled payment date may be automatically calculated by the monitoring engine 12. The new scheduled payment date is registered in the customer database 13.
[0069]
In this way, when a new scheduled payment date arrives, the monitoring routine shown in FIG. 7 is executed again. If payment by the customer is not performed on the new scheduled payment date, the late payment counter is further incremented by 1 in step S65, and the late payment processing routine is executed.
[0070]
When the number of overdue (that is, the value of the overdue counter) becomes 3 or more, the determination in step S71 is Yes. Proceeding to step S74, basic data and contract data relating to the customer are extracted from the customer database 13 in order to perform a reminder by telephone or the like. The extracted information may be printed out or displayed on the terminal screen.
[0071]
FIG. 9 shows a re-estimation processing routine executed in step S64 of FIG.
[0072]
In step S91, the repayment status data for the customer is checked. If the repayment status is good, re-estimation data for early repayment is calculated (S92). The re-estimation data for early repayment is, for example, re-estimation data when the monthly payment amount is increased so as to advance the scheduled payment date of the loan specified in the current credit loan contract. This makes it possible to present to the customer an amount that can be saved compared to the current loan repayment.
[0073]
If the repayment status is not good, re-estimation data for delaying the repayment is calculated. For example, re-estimation data in the case where the monthly payment is reduced so that the scheduled payment date of the loan specified in the current credit loan contract is deducted. In this way, the customer can be encouraged to review the credit loan contract to ensure that it can be repaid.
[0074]
Whether the repayment status is good can be determined according to the value of the arrears counter or according to the value of the evaluation data. For example, if it has no late counter value of 3 or more, it is judged good, and if it has a late counter value of 3 or more, it is judged not good. Alternatively, if the evaluation data is A or B, it is judged as good, and if it is C or D, it is judged not good.
[0075]
In step S94, the template for inserting the re-estimation data created in step S92 or 93 is extracted from the template file 14, the mail address of the mobile phone 4 of the customer is set, and the e-mail is edited. The e-mail is transmitted to the customer's mobile phone 4.
[Brief description of the drawings]
FIG. 1 is a block diagram showing the overall configuration of a system according to an embodiment of the present invention.
FIG. 2 is a diagram showing an example of a screen displayed on a mobile phone in an estimation process in one embodiment of the present invention.
FIG. 3 is a diagram showing a main routine of credit processing in one embodiment of the present invention.
FIG. 4 is a diagram showing an estimation processing routine in one embodiment of the present invention.
FIG. 5 is a diagram showing a contract processing routine in one embodiment of the present invention. .
FIG. 6 is a diagram showing a billing data creation routine in one embodiment of the present invention.
FIG. 7 is a diagram showing a monitoring processing routine in one embodiment of the present invention.
FIG. 8 is a diagram showing an arrears processing routine in one embodiment of the present invention.
FIG. 9 is a diagram showing a re-estimation processing routine in one embodiment of the present invention.
FIG. 10 is a diagram showing an example of a repayment schedule mail and a payment request mail in one embodiment of the present invention.
[Explanation of symbols]
2 credit server
3 Salesperson mobile phone
4 Customer mobile phones
6 Bank server

Claims

A credit computer system connected to a network to which a customer's personal digital assistant can be connected, the system comprising:
A first storage device for storing information relating to the customer and information relating to the credit loan contract of the customer;
A second storage device for storing a template for editing the e-mail addressed to the customer;
Result data receiving means for receiving payment result data informing the customer of payment from a financial institution;
A payment confirmation program that is activated in response to the scheduled payment date specified in the credit loan contract information stored in the first storage device,
The deposit confirmation program is
(A) based on the received payment result data, determining whether or not the deposit specified in the credit loan contract information has been made on the scheduled deposit date;
(B) If it is determined that the deposit has not been made, a template for a deposit request is extracted from the second storage device, and the customer's portable information terminal mail is extracted from the first storage device. Extracting the address and editing the email;
(C) sending the edited e-mail to the customer's personal digital assistant;
A credit computer system configured to execute.

The payment confirmation program further includes:
If it is determined in step (a) that the deposit has been made, the credit loan contract information stored in the first storage device is referred to and whether or not the loan on the customer's credit loan contract has been paid off. A step of judging;
If it is determined that the loan of the customer's credit loan contract has been completed, a template for notifying completion is extracted from the second storage device, and the mobile information of the customer is extracted from the first storage device. Extracting the email address of the device and editing the email;
Sending the edited email to the customer's personal digital assistant;
The credit computer system of claim 1, wherein the credit computer system is configured to perform:

The payment confirmation program further includes:
If it is determined in step (a) that the deposit has been made, a template for notifying the deposit confirmation is extracted from the second storage device, and the customer's mobile phone is extracted from the first storage device. Extracting the email address of the information terminal and editing the email;
Sending the edited email to the customer's personal digital assistant;
The credit computer system of claim 1, wherein the credit computer system is configured to perform:

The payment confirmation program further includes:
Calculating a re-estimation for the credit loan contract based on the credit loan contract information stored in the first storage device;
The template for proposing the calculated re-estimation is extracted from the second storage device, the email address of the customer's portable information terminal is extracted from the first storage device, and the email is edited. And steps to
Sending the edited email to the customer's personal digital assistant;
The credit computer system according to claim 1 or 3, wherein the credit computer system is configured to execute

The payment confirmation program further includes:
A template for notifying the customer's future repayment schedule is extracted from the second storage device, an email address of the mobile information terminal of the customer is extracted from the first storage device, and an email is edited And steps to
Sending the edited email to the customer's personal digital assistant,
The credit computer system according to claim 1 or 3, wherein the credit computer system is configured to execute

The information related to the credit loan contract includes data indicating the repayment status of the customer,
The credit computer system according to claim 4, wherein the re-estimation is calculated according to data indicating a repayment status of the customer.

The information on the credit loan contract further includes an arrears counter,
The credit computer system of claim 1, wherein step (b) further comprises incrementing the arrears counter.

The information on the credit loan contract further includes an arrears counter,
The step (b) further includes incrementing the overdue counter;
The credit computer system according to claim 6, wherein the data indicating the repayment status of the customer is generated based on a value of the arrears counter associated with the past deposit processing of the customer.

The credit computer contract according to claim 1, wherein the information related to the credit loan contract is generated based on estimate information generated on a portable information terminal connectable to the network and uploaded to the credit computer system. system.

The credit system according to claim 9, wherein the estimate information uploaded from the portable information terminal to the credit computer system includes image data of the customer's driver's license.

The credit computer system further comprises:
Converting the image data of the driver's license into character data;
Based on the converted character data, collating the data included in the estimate information with the character data;
The credit computer system according to claim 10, further comprising an identity verification program for executing

The credit computer system further comprises:
Converting the image data of the driver's license into character data;
Using the converted character data into the converted character data to generate information necessary for credit review for the customer;
The credit system according to claim 10, further comprising an examination information generation program for executing