JP6307855B2 - 通知データ生成装置、コンピュータプログラム、通知データ生成方法、通知システム - Google Patents

Description

本発明は、督促が必要な顧客を特定し、特定した顧客に対する通知データを生成する通知データ生成装置等に関する。

金融機関で行う融資業務の一部として、返済が滞っている顧客に対して返済を督促する業務が行われている。この督促業務は、コールセンタのオペレータが顧客に電話連絡することにより行っている。また、督促状を郵送するという手段も取られている。
一方、例えば、ＡＴＭ（Automated Teller Machine）、ＣＤ（Cash Dispenser）の端末装置を利用する顧客に対して、各種の情報を提供することが行われている（特許文献１、特許文献２）。

特許第５０４３２５５号公報 特開平１０−２７２０７号公報

しかし、自宅への電話連絡は顧客が不在又は留守の場合は、連絡を取ることが出来ない。携帯電話への連絡でも顧客が電話を取れない状況であったり、居留守をしたりして電話を取らない場合もあり、確実に連絡が取れるとは限らない。督促状は届いたとしても開封して顧客が内容確認したか否かはわからない。
督促業務においては、顧客に督促内容を確実に伝達し、また、督促が顧客に伝達された記録を保持することが求められる。伝達した記録がなければ、返済しない顧客に法的措置を取ることは認められないからである。
このように督促状（文書）又は電話による連絡が困難な顧客は、他の手段で連絡を行うことが必要となる。

本発明はこのような事情に鑑みてなされたものであり、督促対象の顧客との連絡に関する履歴に基づいて、通知を行う顧客を特定し、顧客への通知を行う手段を提供することを目的とする。

一つの態様では、コールセンターシステムで管理される督促対象の顧客の識別情報を記憶する顧客情報記憶部と、前記コールセンターシステムで管理される顧客との連絡に関する履歴を該顧客の識別情報と対応付けて記憶する履歴記憶部と、勘定系システムにおける顧客により入出金の操作が行われる装置において顧客情報を検出した場合に、前記顧客情報記憶部に記憶されている識別情報に対応付けられた履歴を前記履歴記憶部から読み出す読み出し部と、読み出した前記履歴の内容が所定の督促の条件を満たす顧客を特定する特定部と、特定した前記顧客が満たす前記所定の督促の条件に対応する、前記入出金の操作を行う装置に表示させる通知データであって、前記入出金の操作を行う装置に対する顧客の操作により前記通知データが確認された情報を取得した場合に前記履歴記憶部の履歴を更新するために表示させる通知データを生成する生成部と、を備える。

本発明の一観点によれば、督促対象の顧客との連絡に関する履歴に基づいて、通知を行う顧客を特定し、特定した顧客に対応する通知データを生成することが可能となる。

督促システムの構成の一例を示す説明図である。 コールセンタシステムに含まれるコールセンタサーバのハードウェア構成の一例を示すブロック図である。 債務者ＤＢのレコードレイアウトの一例を示す説明図である。 ローンＤＢのレコードレイアウトの一例を示す説明図である。 交渉履歴ＤＢのレコードレイアウトの一例を示す説明図である。 ＡＴＭ督促判定ＤＢのレコードレイアウトの一例を示す説明図である。 テンプレートＤＢのレコードレイアウトの一例を示す説明図である。 メッセージＤＢのレコードレイアウトの一例を示す説明図である。 オペレータＤＢのレコードレイアウトの一例を示す説明図である。 勘定系システムに含まれる勘定系サーバのハードウェア構成の一例を示すブロック図である。 入出金履歴ＤＢのレコードレイアウトの一例を示す説明図である。 ＡＴＭ装置のハードウェア構成の一例を示すブロック図である。 督促処理の手順の一例を示すフローチャートである。 ケース判定処理の手順の一例を示すフローチャートである。 メッセージ生成処理の手順の一例を示すフローチャートである。 メッセージ表示処理の手順の一例を示すフローチャートである。 メッセージが表示されているＡＴＭ装置の表示部の一例を示す説明図である。 同期処理の手順の一例を示すフローチャートである。 コールセンタのオペレータ端末に表示される画面の一例を示す説明図である。 メッセージが表示されているＡＴＭ装置の表示部の一例を示す説明図である。 メッセージが表示されているＡＴＭ装置の表示部の一例を示す説明図である。 実施の形態２に係るＡＴＭ督促判定ＤＢのレコードレイアウトの一例を示す説明図である。 実施の形態３に係る不在判定補正ＤＢのレコードレイアウトの一例を示す説明図である。 実施の形態４に係るコールセンタのオペレータ端末に表示される画面の一例を示す説明図である。 実施の形態４に係るコールセンタのオペレータ端末に表示される画面の一例を示す説明図である。 コールセンタサーバの機能構成の一例を示すブロック図である。 ＡＴＭ装置の機能構成の一例を示すブロック図である。 実施の形態５にかかる督促システムの構成の一例を示す説明図である。

以下、本願に開示する督促システムを、図面を参照しつつ、詳細に説明する。

（実施の形態１）
図１は督促システムの構成の一例を示す説明図である。督促システムはコールセンタシステム１、勘定系システム２、端末装置３、これらを接続するネットワークＮを含む。コールセンタシステム１は、主としてオペレータが電話により支払いを延滞している顧客に対して、督促を行うためのシステムである。勘定系システム２は端末装置３を介して行われる顧客と銀行との取引に関する情報処理を行う。端末装置３は顧客が銀行と取引を行う場合に用いる端末である。

コールセンタシステム１はコールセンタサーバ１１（通知データ生成装置）、データベース１２、オペレータ端末１３を含む。勘定系システム２は勘定系サーバ２１、データベース２２を含む。端末装置３は例えば、ＡＴＭ装置３１、ＰＣ（Personal Computer）３２、携帯電話３３、スマートフォン３４、タブレット端末３５である。

図２はコールセンタシステム１に含まれるコールセンタサーバ１１のハードウェア構成の一例を示すブロック図である。コールセンタサーバ１１はＣＰＵ（Central Processing Unit）１１ａ、ＲＡＭ（Random Access Memory）１１ｂ、ＲＯＭ（Read Only Memory）１１ｃ、通信部１１ｄ、大容量記憶装置１１ｅ、読取部１１ｆを含む。各構成はバスで接続されている。ＣＰＵ１１ａはＲＯＭ１１ｃに記憶された制御プログラム１１ｐに従いハードウェア各部を制御する。ＲＡＭ１１ｂは例えばＳＲＡＭ（Static RAM）、ＤＲＡＭ（Dynamic RAM）、フラッシュメモリである。ＲＡＭ１１ｂはＣＰＵ１１ａによるプログラムの実行時に発生するデータを一時的に記憶する。通信部１１ｄはネットワークＮを介して、勘定系サーバ２１と通信する機能を備える。大容量記憶装置１１ｅは例えばハードディスク、ＳＳＤ（Solid State Drive）である。大容量記憶装置１１ｅはデータベース１２に記憶すべきデータを一時的に記憶する。また、制御プログラム１１ｐを大容量記憶装置１１ｅに記憶するようにしておいても良い。

読取部１１ｆはＣＤ（Compact Disk）−ＲＯＭ、ＤＶＤ（Digital Versatile Disc）−ＲＯＭを含む可搬型記憶媒体１１１を読み取る。ＣＰＵ１１ａが読取部１１ｆを介して、制御プログラム１１ｐを可搬型記憶媒体１１１より読み取り、大容量記憶装置１１ｅに記憶することとしても良い。また、ネットワークＮを介して他のコンピュータからＣＰＵ１１ａが制御プログラム１１ｐをダウンロードし、大容量記憶装置１１ｅに記憶しても良い。さらにまた、半導体メモリ１１２から、ＣＰＵ１１ａが制御プログラム１１ｐを読み込むこととしても良い。

次にコールセンタシステム１のデータベース１２に記憶されているデータについて説明する。データベース１２には、債務者ＤＢ（DataBase）１２ａ、ローンＤＢ１２ｂ、交渉履歴ＤＢ１２ｃ（履歴記憶部）、ＡＴＭ督促判定ＤＢ１２ｄ、テンプレートＤＢ１２ｅ（雛型記憶部）、メッセージＤＢ１２ｆ（通知データ記憶部）、オペレータＤＢ１２ｇが記憶されている。

図３は債務者ＤＢ１２ａのレコードレイアウトの一例を示す説明図である。債務者ＤＢ１２ａは顧客番号欄、住所欄、氏名欄、電話番号欄、職業欄、勤務先欄、勤務先ＴＥＬ欄、携帯電話欄、性格欄、婚姻歴欄、ライフスタイル欄、機微情報欄、メモ欄を含む。顧客番号欄は顧客を一意に特定するための番号を記憶する。住所欄は顧客の自宅の住所を記憶する。氏名欄は顧客の漢字氏名を記憶する。電話番号欄は顧客の自宅の電話番号を記憶する。職業欄は顧客の職業を記憶する。勤務先欄は勤務先の名称を記憶する。勤務先ＴＥＬ欄は顧客勤務先の電話番号を記憶する。携帯電話欄は顧客が有している携帯電話の電話番号を記憶する。性格欄は顧客の性格を記憶する。顧客の性格はオペレータが電話連絡を通じて把握し記憶する。婚姻歴欄は顧客の婚姻歴（未婚、既婚、死別）を記憶する。ライフスタイル欄は顧客のライフスタイルを記憶する。ライフスタイルはローン審査の書類やオペレータが電話連絡を通じて入手し記憶する。機微情報欄は顧客に関する機微な情報、例えば、宗教信仰に関すること、係争や裁判に関すること、浪人中などの社会的な地位に関することを記憶する。メモ欄はオペレータ間共有する情報を記憶する。

図４はローンＤＢ１２ｂのレコードレイアウトの一例を示す説明図である。ローンＤＢ１２ｂは顧客番号欄、口座番号欄、ローン名欄、引き落とし日欄、引き落とし額欄、残高欄、引き落とし口座番号欄を含む。顧客番号欄は顧客番号を記憶する。口座番号欄は顧客のローン口座を一意に特定する口座番号を記憶する。引き落とし日欄は引き落とし口座から毎月の返済額が引き落とされる日付を記憶する。引き落とし額欄は毎月に引き落とされる額、すなわち毎月の返済金額を記憶する。残高欄は返済残高を記憶する。引き落とし口座番号欄は毎月の返済額を引き落とす対象となる口座の番号を記憶する。

図５は交渉履歴ＤＢ１２ｃのレコードレイアウトの一例を示す説明図である。交渉履歴ＤＢ１２ｃは顧客番号欄、口座番号欄、履歴番号欄、交渉日時欄、相手欄、内容欄、テンプレートＮｏ．欄、オペレータ欄を含む。顧客番号欄は交渉をした又は交渉を試みた顧客の顧客番号を記憶する。口座番号欄は取扱対象となっているローン口座の番号を記憶する。履歴番号欄は交渉履歴の順番号を記憶する。交渉日時欄は交渉をした又は交渉を試みた日時を記憶する。相手欄は電話でオペレータと話した者を記憶する。例えば、顧客本人であれば「本人」と記憶する。その他の者であれば「その他」と記憶する。不在で連絡が取れなかった場合は「不在」と記憶する。なお、「不在」には、携帯電話に掛けても顧客が電話に出ない場合を含む。内容欄は、交渉の内容を示す情報を含む。例えば、電話連絡に対して顧客が応対し、入金の約束がなされた場合には、「入金約束」の情報が記憶される。また、詳細を後述するＡＴＭ督促が行なわれた場合には、「ＡＴＭ督促」の情報が記憶される。また、内容欄には、入金の約束の期日を示す情報が含まれても良い。また、入金の約束の期日を示す情報は図５の内容欄とは別途に保持されていても良い。テンプレートＮｏ．欄は、ＡＴＭ装置３１を用いた通知を行った場合に、通知したメッセージを生成するのに用いたテンプレートのＮｏ．を記憶する。オペレータ欄はオペレータによる交渉がされた場合に担当したオペレータのＩＤを記憶する。

図６はＡＴＭ督促判定ＤＢ１２ｄのレコードレイアウトの一例を示す説明図である。ここでＡＴＭ督促とはＡＴＭ装置３１に返済を督促するメッセージを表示、債務者たる顧客に返済を促すことである。ＡＴＭ督促判定ＤＢ１２ｄはケースＮｏ．欄、項目１欄、演算子１欄、項目２欄、演算子２欄、項目３欄、テンプレートＮｏ．欄を含む。ケースＮｏ．欄はＡＴＭ督促を行うケースを一意に特定するための番号を記憶する。項目１欄、項目２欄、項目３欄はＡＴＭ督促を行うための条件をそれぞれ記憶する。演算子１欄、演算子２欄はそれぞれ論理演算子を記憶する。演算子１欄、演算子２欄に記憶される演算子は論理積を示すＡＮＤ又は論理和を示すＯＲである。演算子１欄に記憶された演算子は、項目１欄に設定された条件の真偽と項目２欄に設定された条件の真偽とを論理演算する際に用いる。演算子２欄に記憶された演算子は、項目１欄に設定された条件の真偽と項目２欄に設定された条件の真偽とを論理演算した結果と、項目３欄に設定された条件の真偽とを論理演算する際に用いる。

図７はテンプレートＤＢ１２ｅのレコードレイアウトの一例を示す説明図である。テンプレートＤＢ１２ｅはＮｏ．欄、ローン名欄、開封日欄、メッセージ欄、期限欄、金額欄、結び欄を含む。Ｎｏ．欄はテンプレートを一意に示すＩＤを記憶する。ローン名欄は生成するメッセージに含まれるローン名についての参照情報（ポインタ情報）を記憶する。開封日欄は生成するメッセージに含める日付についての参照情報を記憶する。メッセージ欄は生成するメッセージに含める定型句を記憶する。期限欄は生成するメッセージに含まれる次の支払期限についての参照情報を記憶する。金額欄は生成するメッセージに含まれる次に支払うべき返済金額についての参照情報を記憶する。結び欄は生成するメッセージの結び部分となる定型句を記憶する。なお、ローン名欄及び開封日欄の間、並びに期限欄及び金額欄の間にある欄は、メッセージ生成の際に補う必要がある語句が記憶されている。

図８はメッセージＤＢ１２ｆのレコードレイアウトの一例を示す説明図である。メッセージＤＢ１２ｆは引き落とし口座番号欄、メッセージ欄、テンプレートＮｏ．欄、開封日欄を含む。引き落とし口座番号欄はメッセージの宛名である顧客が保有する口座番号を記憶する。メッセージ欄は顧客に当てたメッセージを記憶する。テンプレートＮｏ．欄はメッセージの生成に用いたテンプレートの番号を記憶する。開封日欄は顧客がメッセージを読んで確認ボタンを押した日付を記憶する。開封日欄に日付が記憶されているか否かで、顧客がメッセージを確認したか否かを判定することが可能である。

図９はオペレータＤＢ１２ｇのレコードレイアウトの一例を示す説明図である。オペレータＤＢ１２ｇはＩＤ欄、氏名欄、パスワード欄、督促ボタン欄を含む。ＩＤ欄はオペレータを一意に特定するＩＤを記憶する。氏名欄はオペレータの氏名を記憶する。パスワード欄はオペレータがオペレータ端末１３にログインする際に入力すべきパスワードを記憶する。督促ボタン欄はＡＴＭ督促の指示をオペレータに許可するか否かを記憶する。督促ボタン欄に１が記憶されているオペレータは担当する顧客に対するＡＴＭ督促を督促システムに対して指示する権限を有する。督促ボタン欄に０が記憶されているオペレータは督促システムに対してＡＴＭ督促を指示することはできない。オペレータが督促システムに対してＡＴＭ督促を指示可能とするのは、ＡＴＭ督促判定ＤＢ１２ｄに定義されたケースに適合しない場合であっても、ＡＴＭ督促を行えるようにするためである。スキルの高いオペレータは電話での顧客の態度と自己の経験とを照らしあわせることにより、返済まで長期期間掛かることを予想することが可能だからである。このような場合、督促の初期段階にＡＴＭ督促を利用することにより、効率的に督促業務を進行することが可能となる。

図１０は勘定系システム２に含まれる勘定系サーバ２１のハードウェア構成の一例を示すブロック図である。勘定系サーバ２１はＣＰＵ２１ａ、ＲＡＭ２１ｂ、ＲＯＭ２１ｃ、通信部２１ｄ、大容量記憶装置２１ｅ、読取部２１ｆを含む。各構成はバスで接続されている。ＣＰＵ２１ａはＲＯＭ２１ｃに記憶された制御プログラム２１ｐに従いハードウェア各部を制御する。ＲＡＭ２１ｂは例えばＳＲＡＭ、ＤＲＡＭ、フラッシュメモリである。ＲＡＭ２１ｂはＣＰＵ２１ａによるプログラムの実行時に発生するデータを一時的に記憶する。通信部２１ｄはネットワークＮを介して、コールセンタサーバ１１と通信する機能を備える。大容量記憶装置２１ｅは例えばハードディスク、ＳＳＤである。大容量記憶装置２１ｅはデータベース２２に記憶すべきデータを一時的に記憶する。また、制御プログラム２１ｐを大容量記憶装置２１ｅに記憶するようにしておいても良い。

読取部２１ｆはＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭを含む可搬型記憶媒体２１１を読み取る。ＣＰＵ２１aが読取部２１ｆを介して、制御プログラム２１ｐを可搬型記憶媒体２１１より読み取り、大容量記憶装置２１ｅに記憶することとしても良い。また、ネットワークＮを介して他のコンピュータからＣＰＵ２１ａが制御プログラム２１ｐをダウンロードし、大容量記憶装置２１ｅに記憶しても良い。さらにまた、半導体メモリ２１２から、ＣＰＵ２１ａが制御プログラム２１ｐを読み込むこととしても良い。

次に勘定系システム２のデータベース２２に記憶されているデータについて説明する。データベース２２には、メッセージＤＢ２２ａ、入出金履歴ＤＢ２２ｂが記憶されている。メッセージＤＢ２２ａはコールセンタシステム１のメッセージＤＢ１２ｆと同様であるので説明を省略する。

図１１は入出金履歴ＤＢ２２ｂのレコードレイアウトの一例を示す説明図である。入出金ＤＢ２２ｂは、口座番号欄、種別欄、金額欄を含む。口座番号欄は取引に使われた口座の口座番号を記憶する。種別欄は行われた取引の種別、例えば出金、入金を記憶する。金額欄は取引された金額が記憶される。

図１２はＡＴＭ装置３１のハードウェア構成の一例を示すブロック図である。ＡＴＭ装置３１は端末装置３の一例である。ＡＴＭ装置３１はＣＰＵ３１ａ、ＲＡＭ３１ｂ、カードリーダ３１ｃ、操作部３１ｄ、表示部３１ｅ、通信部３１ｆ、記憶部３１ｇを含む。各構成はバスで接続されている。ＣＰＵ３１ａは記憶部３１ｇに記憶された制御プログラム３１ｐに従いハードウェア各部を制御する。ＲＡＭ３１ｂは例えばＳＲＡＭ、ＤＲＡＭ、フラッシュメモリである。ＲＡＭ３１ｂはＣＰＵ３１ａによるプログラムの実行時に発生するデータを一時的に記憶する。カードリーダ３１ｃは顧客が有するキャッシュカードを読み取り顧客番号を取得する。操作部３１ｄは例えば表示部と一体となったタッチパネルであり、顧客からの操作入力を受け付ける。表示部３１ｅは顧客へのメッセージを表示する。通信部３１ｆはネットワークＮを介して、勘定系サーバ２１と通信する機能を備える。

次にコールセンタサーバ１１で行われる情報処理について説明する。以下に示す情報処理の前提として、督促対象となる延滞者リスト（顧客情報記憶部、図示しない）は作成されているものとする。延滞者リストは延滞者の顧客番号、延滞しているローンの口座番号を含む。コールセンタサーバ１１は延滞者リストの作成を所定期間毎に行う。例えば、日次のバッチ処理として、一日一回実行される。

図１３は督促処理の手順の一例を示すフローチャートである。コールセンタサーバ１１のＣＰＵ１１ａは延滞者リストから延滞者の顧客番号及びローンの口座番号を取り出す（ステップＳ１）。ＣＰＵ１１ａは延滞者のケース判定を行う（ステップＳ２）。

図１４はケース判定処理の手順の一例を示すフローチャートである。ＣＰＵ１１aはＡＴＭ督促判定ＤＢ１２ｄから未処理のレコード、すなわち未検討のケースに係るデータを取得する（ステップＳ１１）。ＣＰＵ１１ａは取得したケースに適合するか否かを判定するために必要となる処理対象となっている延滞者に関するデータを取得する（ステップＳ１２）。取得したデータを元に、ＣＰＵ１１ａは処理対象となっている延滞者はケースに適合するか否かを判定する（ステップＳ１３）。ケースに適合する場合（ステップＳ１３でＹＥＳ）、ＣＰＵ１１ａは適合したケースに対応したテンプレートＮｏ．を取得する（ステップＳ１４）。ＣＰＵ１１ａは戻り値を取得したテンプレートのＮｏ．に設定する（ステップＳ１５）。ケースに適合しない場合（ステップＳ１３でＮＯ）、未検討ケースがあるか否かＣＰＵ１１ａは判定する（ステップＳ１６）。未検討ケースがある場合（ステップＳ１６でＹＥＳ）、ＣＰＵ１１ａは処理をステップＳ１１に戻す。未検討ケースがない場合（ステップＳ１６でＮＯ）、ＣＰＵ１１ａは戻り値を０に設定する（ステップＳ１７）。ステップＳ１５又はステップＳ１７の後、ＣＰＵ１１ａは処理を終了し、呼び出し元に処理を戻す。

図１３に戻り、ＣＰＵ１１ａはケース判定の結果、ＡＴＭ督促を行うか否かを判定する（ステップＳ３）。ＡＴＭ督促を行う場合、すなわち戻り値が０以外の場合は（ステップＳ３でＹＥＳ）、ＣＰＵ１１ａはメッセージ生成を行う（ステップＳ４）。

図１５はメッセージ生成処理の手順の一例を示すフローチャートである。ＣＰＵ１１ａはケース判定処理の戻り値となっているテンプレートＮｏ．に対応したテンプレートデータをテンプレートＤＢ１２ｅから取得する（ステップＳ２１）。ＣＰＵ１１ａはテンプレートに指定されている参照情報を元に、メッセージ生成に必要な項目を取得する（ステップＳ２２）。ＣＰＵ１１ａは取得した項目をテンプレートに埋め込み、メッセージを生成する（ステップＳ２３）。ＣＰＵ１１ａは処理対象となっている延滞者の顧客番号とローンの口座番号から引き落とし口座番号を取得する（ステップＳ２４）。ＣＰＵ１１ａは生成したメッセージを取得した引き落とし口座番号及びメッセージ生成に使用したテンプレートＮｏ．と対応付けて、メッセージＤＢ１２ｆに記憶する（ステップＳ２５）。ＣＰＵ１１ａは処理を終了し、呼び出し元に処理を戻す。

ＡＴＭ督促を行わない場合、すなわち戻り値が０の場合（ステップＳ３でＮＯ）、ＣＰＵ１１ａは従来の電話督促を行うことをオペレータに促す（ステップＳ５）。オペレータは電話督促を行い、その結果をオペレータ端末１３より入力する。ＣＰＵ１１ａは入力された履歴を交渉履歴ＤＢ１２ｃに登録する（ステップＳ６）。ＣＰＵ１１ａはステップＳ４又はステップＳ６の後に、処理すべき他の延滞者が居るか否か判定する（ステップＳ７）。処理すべき他の延滞者がいる場合（ステップＳ７でＹＥＳ）、ＣＰＵ１１ａは処理をステップＳ２へ戻す。処理すべき他の延滞者が居ない場合（ステップＳ７でＮＯ）、ＣＰＵ１１ａは処理を終了する。

次にメッセージの生成についての具体例について説明する。以下では顧客番号１００のローン口座番号１００１に延滞が発生しているものとして説明する。

図１３のステップＳ１で、ＣＰＵ１１ａは顧客番号１００及びローン口座番号１００１を取得する。次にＣＰＵ１１ａはケース判定処理（ステップＳ２）を行う。図１４のステップＳ１１で、ＣＰＵ１１ａはケースＮｏ．が１のケースを取得する。図６に示したようにケースＮｏ．１では、項目１が「不在回数＝連続３回」、項目２が「職業＝会社員」、項目３が「性格＝ルーズ」である。また、演算子１が「ＡＮＤ」、演算子２も「ＡＮＤ」である。つまり、このケースでは、不在回数が連続３回、かつ職業が会社員、かつ性格がルーズの場合に、ＡＴＭ督促を行うことが定義されている。

次にＣＰＵ１１ａは顧客番号１００に関して、当該データを取得する（ステップＳ１２）。不在回数は交渉履歴ＤＢ１２ｃより求まる。図５に示す交渉履歴ＤＢ１２ｃにおいて、顧客番号が１００及びローン口座番号が１００１のレコードを取得し履歴番号の降順にソートすると、直近、３回連続して不在であることが分かる。よって、項目１については、「真」である。職業は債務者ＤＢ１２ａを調べる。図３に示すように顧客番号１００の顧客の職業は会社員である。よって、項目２についても「真」である。さらにまた、性格についても債務者ＤＢ１２ａを調べる。図３に示すように顧客番号１００の顧客の性格はルーズとなっている。よって、項目３についても「真」である。演算子１及び演算子２は「ＡＮＤ」であるので、項目１から項目３までの３つの真理値を論理積すると、その結果、図１４示すフローチャートのステップＳ１３でＣＰＵ１１ａは適合と判定することとなる。

ＣＰＵ１１ａは適合したケースに対応したテンプレートＮｏ．を取得する（ステップＳ１４）。ここでは、図６に示すように１である。ＣＰＵ１１ａは戻り値を１に設定して、処理を終了する。

ＣＰＵ１１ａは図１３のステップＳ３でＹＥＳと判定し、メッセージ生成を行う。図１５のステップＳ２１で、ＣＰＵ１１ａはテンプレートＤＢ１２ｅからテンプレートを取得する。次に取得したテンプレートを用いてメッセージを生成する場合に必要なデータをＣＰＵ１１ａは取得する。図７に示したよう、テンプレートＮｏ．が１のテンプレートでは、ローン名はローンＤＢ１２ｂのローン名であることが分かる。ここで、図４に示したように、顧客番号が１００及びローン口座番号が１００１のローンのローン名は「住宅ローン」であることが分かる。

次に、開封日は最終不在日となっている。最終不在日については交渉履歴ＤＢ１２ｃより求めることが可能である。図５に示すように、顧客番号が１００及びローン口座番号が１００１の顧客の最終不在日は12/2 10:00であることが分かる（履歴番号４を参照）。

また、期限は１週間以内であるから、開封日から一週間後は12/9である。さらに、金額は毎月の引き落とし額である。毎月の引き落とし額はローンＤＢ１２ｂを調べる。図４に示すように、顧客番号が１００及びローン口座番号が１００１のローンの毎月の引き落とし額は、40,000円である。以上で、メッセージを生成するために必要なデータは揃ったことになる。これらのデータとテンプレートより、ＣＰＵ１１ａはメッセージを生成する（ステップＳ２３）。生成されるメッセージは次のとおりである。「住宅ローン の件で 12/2 10:00 にお電話しましたが、ご連絡がとれませんでしたのでＡＴＭにて連絡いたします。 12/9 までに 40,000円 の入金をお願い致します。」分かち書きにしているのは、テンプレートに定義された定型句、及びメッセージ生成前に取得したデータの区別を明確にするためである。

さらに、ＣＰＵ１１ａは、顧客番号が１００及びローン口座番号が１００１のローン引き落とし口座番号をローンＤＢ１２ｂより取得する（ステップＳ２４）。図４に示すように、顧客番号が１００及びローン口座番号が１００１のローン引き落とし口座番号は、「001-普通-1234567」である。そして、メッセージ生成に用いたテンプレートのＮｏ．は１である。ＣＰＵ１１ａはメッセージ、引き落とし口座番号、テンプレートＮｏ．をメッセージＤＢ１２ｆに記憶する（ステップＳ２５）。その結果を示しているのが、図８である。

以上が、連絡困難な延滞者に対するメッセージ生成までの一連の処理である。次にメッセージが延滞者に表示され、確認ボタンが押されるまでについての処理を説明する。後述するように、コールセンタシステム１のメッセージＤＢ１２ｆと勘定系システム２のメッセージＤＢ２２ａとは定期的に同期処理が行われることにより、上述の処理にて生成したメッセージはメッセージＤＢ２２ａに記憶されることになる。

図１６はメッセージ表示処理の手順の一例を示すフローチャートである。なお、上述のように端末装置はＡＴＭ装置３１を想定している。まず、ＡＴＭ装置３１のＣＰＵ３１ａは、操作部３１ｄを介して顧客が行う取引種別を受け付ける（ステップＳ３１）。ここでいう取引種別とは、例えば、入金、出金であり、ＡＴＭ装置３１を用いて顧客が銀行と行える取引の種別である。

次に顧客の本人認証を行う（ステップＳ３２）。本人認証は例えば以下のようにして行う。ＣＰＵ３１ａはキャッシュカードをカードリーダ３１ｃに読み取らせることを顧客に促す文章を表示部３１ｅに表示する。ＣＰＵ３１ａはカードリーダ３１ｃを介してキャッシュカードより顧客番号を読み取る。ＣＰＵ３１ａは表示部３１ｅに暗証番号の入力を促す文章を表示し、操作部３１ｄを介して暗証番号を受け付ける。ＣＰＵ３１ａは顧客番号及び受け付けた暗証番号の組み合わせが正しいか、勘定系サーバ２１に問合せを行う。勘定系サーバ２１のＣＰＵ２１ａは債務者ＤＢ（図示しない）に記憶されている顧客番号及び暗証番号の組みと、問合せを受けた顧客番号及び暗証番号の組みとを比較し正しい組み合わせか否かを判定する。ＣＰＵ２１ａは判定結果をＡＴＭ装置３１に返す。

ＡＴＭ装置３１のＣＰＵ３１ａは、本人認証の判定結果を判定する（ステップＳ３３）。ＣＰＵ３１ａは本人認証が成功した場合（ステップＳ３３でＹＥＳ）、メッセージの検索を行う（ステップＳ３４）。ＣＰＵ３１ａは本人認証が失敗した場合（ステップＳ３３でＮＯ）、ステップＳ３２に戻し、再度、本人認証を行う。

メッセージの検索は勘定系サーバ２１を介して行う。ＣＰＵ３１ａは勘定系サーバ２１に顧客番号を送信し、顧客番号に対応付けられたメッセージがあるか否か問い合わせる。勘定系サーバ２１のＣＰＵ２１ａはメッセージＤＢ２２ａを検索し、顧客番号に対応付けられたメッセージがあるか否かを調べる。ＣＰＵ２１ａはメッセージがない場合はその旨を、メッセージがある場合はある旨とメッセージをＡＴＭ装置３１に送信する。

ＡＴＭ装置３１のＣＰＵ３１ａは勘定系サーバ２１から返信結果により、メッセージの有無を判定する（ステップＳ３５）。ＣＰＵ３１ａはメッセージがある場合（ステップＳ３５でＹＥＳ）、表示部３１ｅに表示すると共に、メッセージを確認したことを入力するための確認ボタンを表示する（ステップＳ３６）。図１７はメッセージが表示されているＡＴＭ装置３１の表示部３１ｅの一例を示す説明図である。

ＣＰＵ３１ａは確認ボタンによる確認入力がされた否かを判定する（ステップＳ３７）。ＣＰＵ３１ａは確認入力がない場合（ステップＳ３７でＮＯ）、再度、ステップＳ３７を実行する。ＣＰＵ３１ａは確認入力があった場合（ステップＳ３７でＹＥＳ）、確認入力があった旨を勘定系サーバ２１に送信する（ステップＳ３８）。勘定系サーバ２１のＣＰＵ２１ａは、確認入力を受信した日時をメッセージＤＢ２２ａの確認日時欄に記憶する。ステップＳ３８の後、またはメッセージがない場合（ステップＳ３５でＮＯ）、ＣＰＵ３１ａは顧客が選択した取引を行い（ステップＳ３９）、処理を終了する。当該取引に関する処理は周知の技術なので説明を省略する。

次に、コールセンタシステム１のメッセージＤＢ１２ｆと勘定系システム２のメッセージＤＢ２２ａとの同期処理について説明する。図１８は同期処理の手順の一例を示すフローチャートである。同期処理はコールセンタサーバ１１及び勘定系サーバ２１が協働して行う。

コールセンタサーバ１１のＣＰＵ１１ａは勘定系サーバ２１に問い合わせを行い、メッセージＤＢ２２ａが記憶しているメッセージの中から、表示済みのメッセージを取得する（ステップＳ４１）。すなわち、ＣＰＵ１１ａ確認日時が記録されているメッセージを取得する。ＣＰＵ１１ａは取得したメッセージの確認日時を基に、それに対応したメッセージＤＢ１２ｆのレコードに確認日時を記憶し、表示済情報を反映させる（ステップＳ４２）。

ＣＰＵ１１ａは取得したメッセージの確認日時を基に、交渉履歴ＤＢ１２ｃにメッセージが確認された旨を記憶する（ステップＳ４３）。具体的には、ＣＰＵ１１ａは確認日時の日付を交渉履歴ＤＢ１２ｃの交渉日欄に、確認日時の時刻を交渉履歴ＤＢ１２ｃの時刻欄に記憶する。ＣＰＵ１１ａは区分欄に「交渉」、相手欄に「本人」を記憶する。履歴内容欄に「ＡＴＭ督促」を、担当者欄に「システム」を記憶する。ＣＰＵ１１ａは「交渉メモ」欄にメッセージを記憶する。

ＣＰＵ１１ａは表示済みメッセージの消し込みを行う（ステップＳ４４）。ＣＰＵ１１ａはステップＳ４１で取得したメッセージを削除することを勘定系サーバ２１に送信する。勘定系サーバ２１のＣＰＵ２１ａは受信した情報に基づき、表示済みメッセージを削除する。加えて、コールセンタサーバ１１のＣＰＵ１１ａはメッセージＤＢ１２ｆから表示済みメッセージを削除しても良い。

ＣＰＵ１１ａはメッセージ追加を行う（ステップＳ４５）。具体的には次のような処理である。ＣＰＵ１１ａは未表示メッセージのＣＰＵ１１ａは勘定系サーバ２１に問い合わせを行い、メッセージＤＢ２２ａが記憶しているメッセージの中から、未表示のメッセージを取得する。ＣＰＵ１１ａはメッセージＤＢ１２ｆに記憶されている未表示のメッセージと取得した未表示メッセージとを突き合わせ、メッセージＤＢ１２ｆに記憶されているが、メッセージＤＢ２２ａに記憶していないメッセージを特定する。ＣＰＵ１１ａは勘定系サーバ２１に特定したメッセージを送信する。勘定系サーバ２１のＣＰＵ２１ａは受信した未表示のメッセージをメッセージＤＢ２２ａに追加する。ＣＰＵ２１ａは処理を終了する。図１９はコールセンタのオペレータ端末４４に表示される画面の一例を示す説明図である。図１９に示す画面は顧客情報表示欄１９１、顧客連絡先情報表示欄１９２、ローン情報表示欄１９３、履歴情報表示欄１９４を含む。ＡＴＭ装置３１によるメッセージ表示の履歴は、履歴情報表示欄１９４のレコード１９４ａである。

次に、ＡＴＭ督促を繰り返し行う場合の生成メッセージの変化について説明する。一回目のＡＴＭ督促により、入金がなかった場合、約束不履行となる。なお、約束不履行の判定については、例えば、交渉履歴に含まれる、ＡＴＭ督促に伴う入金の期日を超過しても顧客からの入金がなされなかった場合、約束不履行と判定することとしても良い。このような状況となった顧客は、図６のケースＮｏ．２に適合する。ケースＮｏ．２では、項目１が「テンプレートＮｏ．＝１」、項目２が「約束不履行」、項目３は規定されていない。演算子１は「ＡＮＤ」である。ここで、項目１は、前回のメッセージ生成の際に用いられたテンプレートＮｏ．が１である場合、「真」となる。項目２は「約束不履行」が生じていたら、「真」となる。すなわち、ケースＮｏ．２はテンプレートＮｏ．１により生成されたメッセージをＡＴＭ装置３１で見て、指定期日までの支払に応じたものの、期日までに支払をせずに約束不履行となっている顧客が該当する。そのような顧客はケースＮｏ．２に適合するので、テンプレートＮｏ．２により生成したメッセージが、ＡＴＭ装置３１に表示される。図２０はメッセージが表示されているＡＴＭ装置３１の表示部の一例を示す説明図である。図２０にはテンプレートＮｏ．２により生成したメッセージが表示されている。

図２０に示したメッセージで同意したのにも関わらず、約束不履行になった場合は、図６のケースＮｏ．３に適合し、テンプレートＮｏ．３により生成されたメッセージが表示されることとなる。図２１はメッセージが表示されているＡＴＭ装置３１の表示部の一例を示す説明図である。テンプレートＮｏ．３により生成したメッセージが表示されている。

上述のように、実施の形態１では、延滞者に宛てたメッセージがある場合、延滞者である顧客がＡＴＭ装置３１で取引を行う前に、表示部にメッセージを表示する。そして、その内容を確認した旨の入力を顧客が行わない限り、通常の取引に進めないようにしているので、メッセージの伝達を確実に行うことが可能となる。また、確認入力がされた日時を記憶するので、コールセンタから電話連絡した場合と同様に、履歴情報として管理することが可能となる。

また、メッセージの出力回数が増えるたびに、それまでよりも強く督促を行なうメッセージを生成するので、顧客に入金をより強く促すことが可能となる。

先に述べたように、督促業務においては、再三の電話督促にも関わらず支払に応じない場合、延滞者に対して法的手段をとり、返済を要求する。法的手段をとるためには、金融庁から求められている回収義務を充足することが必要となる。回収義務を果たした証拠としては、例えば、本人に確実にコンタクトをとり、引き落としの要求を本人に直接実施した証拠が必要となる。しかし、コールセンタから電話を掛けたが、本人が不在のため連絡取れずという記録のみでは、回収を果たしたとして認められない可能性がある。そのような背景からも、メッセージの表示及びメッセージ確認の記録は上記の回収義務を果たした証拠となり得る情報とすることができる。

なお、実施の形態１ではメッセージの出力回数が増えるたびに、それまでよりも強く督促を行なうメッセージを生成することとしたが、それに限られない。債務者ＤＢ１２ａの内容変更の度合いよりメッセージの強さが異なるテンプレートを用いることとしてもよい。例えば、連絡先、住所、職業が頻繁に変わる顧客に対しては、通常よりも強いメッセージを生成するようにする。まず、テンプレートＤＢ１２ｅに内容的にほぼ同一であるが、文体、文調、用いる語の異なる複数のテンプレートを用意する。

ＡＴＭ督促判定ＤＢ１２ｄの判定項目として「変更度合い＝高」、「変更度合い＝中」、又は「変更度合い＝低」いずれか１つを含むケースを設け、それぞれについて強さがことなるテンプレートを割り当てれば良い。

（実施の形態２）
実施の形態１では、ＡＴＭ督促を行う条件の１つとして、不在回数が連続３回という条件を示した。この回数条件を他の条件により異ならせることも考えられる。例えば、ローン残高の大きさに応じて変化させる。残高が大きいほど、回収不能となった時のダメージも大きくなるので、残高が大きいほど、回数を小さくする。また、連絡先、住所、職業の変更度合いが頻繁な顧客は回数を小さくする。連絡先、住所、職業の変更度合いが頻繁な顧客は、社会との接点をなるべく持たないようにしていると思われるので、電話をしても出ない可能性が高いからである。

図２２は実施の形態２に係るＡＴＭ督促判定ＤＢ１２ｄのレコードレイアウトの一例を示す説明図である。ケースＮｏ．１１から１３は、ローン残高により連続不在回数の条件を異ならせている場合の例である。ケースＮｏ．２２及び２３は連絡先、住所、職業の変更度合いにより、連続不在回数の条件を異ならせている場合の例である。実施の形態２が実施の形態１と異なる点は、ＡＴＭ督促判定ＤＢ１２ｄの内容に過ぎない。ハードウェア構成、情報処理の内容は実施の形態１と同様であるので、説明を省略する。

実施の形態２においては、以下のような効果を奏する。ＡＴＭ督促を行う基準となる不在の連続回数を、ローン残高、顧客情報の変更度合いという顧客毎に異なる要素を基に定めるので、顧客毎に適切な閾値を設定することが可能となる。それにより、無駄な電話連絡の回数を減らすことが可能となる。

（実施の形態３）
実施の形態２ではＡＴＭ督促を行う基準となる不在の連続回数を変化させる場合を述べたが、交渉履歴から不在回数をカウントする場合のカウントの仕方を変えても良い。以下の説明においては、実施の形態１と異なる点を主に説明し、実施の形態１と同様な事項については、説明を省略する。

図２３は実施の形態３に係る不在判定補正ＤＢのレコードレイアウトの一例を示す説明図である。不在判定補正ＤＢはコールセンタシステム１のデータベースに１２に記憶する。不在判定補正ＤＢはＮｏ．欄、条件欄、補正内容欄を含む。Ｎｏ．欄は、レコードの順番号を記憶する。条件欄は不在回数を補正する条件を記憶する。補正内容欄は不在回数の補正内容を記憶する。

図２３における補正Ｎｏ．１は処理対象の顧客の性格が頑固、ルーズ又は要注意の場合、交渉履歴から求めた不在回数に１を加えてから、ＡＴＭ督促判定ＤＢ１２ｄを用いたＡＴＭ督促判定を行うことを示している。補正Ｎｏ．２は職業が看護師の場合、不在時間が夜間、例えば２０：００から翌０８：００の間の場合は、不在であったとしても不在としてはカウントしないことを表している。看護師は夜勤が多いことを考慮した補正内容である。

実施の形態３においては、以下のような効果を奏する。ＡＴＭ督促を行う基準となる不在の連続回数を補正可能とした。そのことにより、例えば、日勤の人であれば連絡が取れる可能性の高い時間に不在にしたとしても、職業柄夜間勤務が多い職に付いている人であっても、不在の連続回数をカウントされない。それにより、不在の連続回数を適切にカウントすることが可能となる。

（実施の形態４）
実施の形態１から実施の形態３では、コールセンタサーバ１１がＡＴＭ督促判定ＤＢ１２ｄを用いて、ＡＴＭ督促を行うか否かを判定していたが、オペレータの判断でＡＴＭ督促を行うこととしてもよい。例えば、顧客が着信拒否をしている場合、顧客の電話番号が変わったことにより、登録されている番号に掛けても、使われていない番号であるとアナウンスされる場合、又は顧客が入院している場合、ＡＴＭ督促が適しているからである。なお、すべてのオペレータにＡＴＭ督促を行うことを許可した場合、スキルの低いオペレータが判断を誤って、ＡＴＭ督促を行ってしまう可能性がある。それを防止するため、スキルの高いオペレータのみが指示可能とする。なお、オペレータがＡＴＭ督促を指示する場合は、オペレータ端末１３にテンプレートＤＢ１２ｅを用いて生成したメッセージを複数表示、その中からオペレータが選択するものとする。または、オペレータがオペレータ端末１３から入力しても良い。

図２４、２５は実施の形態４に係るコールセンタのオペレータ端末に表示される画面の一例を示す説明図である。図２４はＡＴＭ督促の指示が許されていないオペレータに対して表示される画面の例である。図２５はＡＴＭ督促の指示が許されているオペレータに対して表示される画面の例である。両画面の違いは、「ＡＴＭ督促」ボタン２４１が使える状態となっている否かである。

実施の形態４は以下の効果を奏する。ＡＴＭ督促判定ＤＢ１２ｄに設定されたケースに適合する顧客ではないが、ＡＴＭ督促すべきとオペレータが判断した顧客に対して、ＡＴＭ督促を行うことが可能となる。

図２６はコールセンタサーバ１１の機能構成の一例を示すブロック図である。図２６は実施の形態１から４に係るコールセンタサーバ１１の構成を機能ブロック図で表現したものである。

コールセンタサーバ１１は読み出し部１１１ａ、特定部１１２ａ、生成部１１３ａ、第２読み出し部１１４ａを含む。ＣＰＵ１１ａが制御プログラム１１ｐを実行することにより、コールセンタサーバ１１は以下のように動作する。

読み出し部１１１ａは、顧客情報記憶部（延滞者リスト）に記憶されている識別情報（顧客番号＋ローン口座番号）に対応付けられた履歴を履歴記憶部（交渉履歴ＤＢ１２ｃ）から読み出す。
特定部１１２ａは、読み出した履歴の内容が所定の条件を満たす顧客を特定する。
生成部１１３ａは、特定した顧客に対する通知データ（メッセージ）を生成する。
第２読み出し部１１４ａは、読み出し部が読み出した識別情報に対応付いた顧客の職業、性格を含む顧客情報を読み出す。

図２７はＡＴＭ装置３１の機能構成の一例を示すブロック図である。図２７は実施の形態１から４に係るＡＴＭ装置３１の構成を機能ブロック図で表現したものである。

ＡＴＭ装置３１は判定部３１１ａ、表示部３１２ａ、受付部３１３ａを含む。ＣＰＵ３１ａが制御プログラム３１ｐを実行することにより、ＡＴＭ装置３１は以下のように動作する。

判定部３１１ａは、取得した識別情報と対応付いた通知データが通知データ記憶部に記憶されているか否かを判定する。表示部３１２ａは、通知データが記憶されていると判定部３１１ａが判定した場合、前記識別情報と対応付いた通知データを通知データ記憶部から読み出し表示する。
受付部３１３ａは、通知データを確認した旨の入力を受け付ける。また、受付部３１３ａは、確認した旨の入力受け付けるまでは、それ以外の入力を受け付けない。

（実施の形態５）
上述の実施の形態１から４において、コールセンタシステム１、勘定系システム２は個別のシステムとしていたが、単一のシステムとすることも可能である。図２８は実施の形態５にかかる督促システムの構成の一例を示す説明図である。督促システムは端末装置３、金融機関システム４、これらを接続するネットワークＮを含む。

金融機関システム４はロードバランサ４１、アプリケーションサーバ４２、データベース４３、オペレータ端末４４を含む。ロードバランサ４１は端末装置３からの処理要求を負荷分散させる装置である。ロードバランサ４１は端末装置３からの処理要求を、所定の負荷分散アルゴリズムに基づいて、いずれかのアプリケーションサーバ４２に振り分ける。アプリケーションサーバ４２は端末装置３から要求された処理を実行する。アプリケーションサーバ４２は処理結果を要求元の端末装置３に返却する。端末装置３、データベース４３及びオペレータ端末４４は、それぞれ実施の形態１から４と同様であるから説明を省略する。

アプリケーションサーバ４２は要求された処理内容に応じて、上述のコールセンタサーバ１１又は勘定系サーバ２１としての機能を果たすものである。アプリケーションサーバ４２のハードウェア構成、情報処理内容はコールセンタサーバ１１又は勘定系サーバ２１と同様であるので、説明を省略する。なお、図２８ではアプリケーションサーバ４２を３台としてあるが、２台以下でも４台以上でも良い。また、各アプリケーションサーバ４２の負荷状況に応じて、アプリケーションサーバ４２を動的に増減させても良い。

データベース４３は債務者ＤＢ４３ａ、ローンＤＢ４３ｂ、交渉履歴ＤＢ４３ｃ、ＡＴＭ督促判定ＤＢ４３ｄ、テンプレートＤＢ４３ｅ、メッセージＤＢ４３ｆ、オペレータＤＢ４３ｇ、入出金履歴ＤＢ４３ｈを含む。債務者ＤＢ４３ａ、ローンＤＢ４３ｂ、交渉履歴ＤＢ４３ｃ、ＡＴＭ督促判定ＤＢ４３ｄ、テンプレートＤＢ４３ｅ、メッセージＤＢ４３ｆ、オペレータＤＢ４３ｇ、入出金履歴ＤＢ４３ｈは、それぞれ上述の債務者ＤＢ１２ａ、ローンＤＢ１２ｂ、交渉履歴ＤＢ１２ｃ、ＡＴＭ督促判定ＤＢ１２ｄ、テンプレートＤＢ１２ｅ、メッセージＤＢ１２ｆ、オペレータＤＢ１２ｇ、入出金履歴ＤＢ２２ｂと同様であるので、説明を省略する。

上述においては、端末装置３としてＡＴＭ装置３１を例としたが、ＰＣ３２、携帯電話３３、スマートフォン３４、タブレット端末３５を用いた場合も同様である。その場合は、Ｗｅｂブラウザを用いたアクセスであるから、メッセージを確認した旨の操作を行わずに、Ｗｅｂブラウザを終了すれば、確認した記録を取ることができない。その点で、ＡＴＭ装置３１と異なる。顧客がＡＴＭ装置３１を用いることにより、現金を引き出すというＡＴＭ装置３１のみで可能な取引であると想定されるからである。現金を引き出すためには、顧客はメッセージを確認した旨の操作を行わざるを得ないので、確実に確認した記録を取ることが可能となる。

メッセージは端末装置３に表示する以外に、通帳又はレシートに印字しても良い。通帳は顧客が所持するものであり、メッセージ内容を確認したことの物的証拠となり得るからである。

また、顧客がメッセージを確認した後に、ＡＴＭ装置３１を用いて行った取引の履歴は、勘定系システム２の入出金履歴ＤＢ２２ｂに記憶されている。勘定系システム２における入出金履歴は、銀行の本来業務に関わる記録であるため、改ざん対策は十分に行われており、内容の真正性は確保されている。したがって、入出金履歴の付されている日時とメッセージ確認の日時とを比較し、両者の日時が近接している場合は、メッセージ確認の記録の信頼性が補強されることとなる。

ところで、ＡＴＭ督促を行うことにより、督促業務を進行することが可能となる。ＡＴＭ督促の状況と、オペレータのスキルに応じて、延滞者に対応するオペレータを選択可能である。例えば、ＡＴＭ督促と同じ内容を再度伝えるだけであるならば、話す内容は明確であるので、スキルの低いオペレータでも対応可能である。一方、数度に渡りＡＴＭ督促により入金を約束したものの入金していない滞納者は、対応が難しい顧客と言えるので、スキルの高いオペレータによる対応が必要となる。このようにＡＴＭ督促の記録を含めた対応履歴を用いることにより、コールセンタサーバ１１が自動的に、各滞納者を担当するオペレータを割り当てることが可能となる。

各実施例で記載されている技術的特徴（構成要件）はお互いに組合せ可能であり、組み合わせることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものでは無いと考えられるべきである。本発明の範囲は、上記した意味では無く、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

以上の実施の形態１から５に関し、さらに以下の付記を開示する。

（付記１）
督促対象の顧客の識別情報を記憶する顧客情報記憶部と、
顧客との連絡に関する履歴を該顧客の識別情報と対応付けて記憶する履歴記憶部と、
前記顧客情報記憶部に記憶されている識別情報に対応付けられた履歴を前記履歴記憶部から読み出す読み出し部と、
読み出した前記履歴の内容が所定の条件を満たす顧客を特定する特定部と、
特定した前記顧客に対する通知データを生成する生成部と
を備える通知データ生成装置。

（付記２）
前記特定部は、顧客への連絡が不能であった旨の情報を含む履歴が所定回数連続している顧客を特定する
付記１記載の通知データ生成装置。

（付記３）
通知データの雛形を記憶する雛型記憶部を備え、
前記生成部は前記読み出した履歴に基づいて、前記雛型記憶部が記憶する雛形を選択して読み出し、読み出した雛形を用いて通知データを生成する
付記１又は２に記載の通知データ生成装置。

（付記４）
前記履歴には、前記生成部が生成した通知データの生成履歴が含まれ、
前記生成部は前記生成履歴を用いて雛形を選択する
付記３に記載の通知データ生成装置。

（付記５）
前記読み出し部が読み出した識別情報に対応付けられた顧客の職業、性格を含む顧客情報を読み出す第２読み出し部を備え、
前記特定部は、読み出した顧客情報と前記履歴に基づいて、顧客を特定する
付記１から付記４に記載の通知データ生成装置。

（付記６）
督促対象の顧客の識別情報を読み出し、
読み出した識別情報に対応付けられた履歴を読み出し、
読み出した履歴の内容が所定の条件を満たす顧客を特定し、
特定した顧客に対する通知データを生成する
処理をコンピュータに実行させるコンピュータプログラム。

（付記７）
制御部を有するコンピュータによる通知データ生成方法において、
督促対象の顧客の識別情報を読み出し、
読み出した識別情報に対応付けられた履歴を読み出し、
読み出した履歴の内容が所定の条件を満たす顧客を特定し、
特定した顧客に対する通知データを生成する
通知データ生成方法。

（付記８）
顧客を特定し、特定した顧客に対する通知データを生成する通知データ生成装置と、該通知データ生成装置が生成した通知データを識別情報と対応付けて記憶する通知データ記憶部と、前記通知データを表示する表示装置と、を備え
前記表示装置は、
取得した識別情報と対応付けられた通知データが前記通知データ記憶部に記憶されているか否かを判定する判定部、
通知データが記憶されていると前記判定部が判定した場合、前記識別情報と対応付けられた通知データを前記通知データ記憶部から読み出し表示する表示部、
操作を受け付ける受付部を有し、
前記表示部に前記通知データが表示された後、該通知データに対する応答操作を受け付けるまで、前記受付部はそれ以外の操作を受け付けない
ことを特徴とする通知システム。

（付記９）
取得した識別情報と対応付けられた通知データの有無を判定する判定部と、
通知データが有りと前記判定部が判定した場合、前記識別情報と対応付けられた通知データを取得して表示する表示部と、
操作を受け付ける受付部と
前記表示部に前記通知データが表示された後、該通知データに対する応答操作を受け付けるまで、前記受付部はそれ以外の操作を受け付けない
表示入力装置。

（付記１０）
取得した識別情報と対応付けられた通知データの有無を判定し、
通知データが有りと判定した場合、前記識別情報と対応付けられた通知データを取得して表示し、
前記通知データを確認した旨の入力を促し、
前記通知データを確認した旨の入力を受け付けるまでは、それ以外の入力を受け付けない
処理をコンピュータに実行させるコンピュータプログラム。

（付記１１）
制御部を有するコンピュータにより情報処理を行う情報処理方法において、
取得した識別情報と対応付けられた通知データの有無を判定し、
通知データが有りと判定した場合、前記識別情報と対応付けられた通知データを取得して表示し、
前記通知データを確認した旨の入力を促し、
前記通知データを確認した旨の入力受け付けるまでは、それ以外の入力を受け付けない
情報処理方法。

１ コールセンタシステム
１１ コールセンタサーバ（通知データ生成装置）
１１ａ ＣＰＵ
１１ｂ ＲＡＭ
１１ｃ ＲＯＭ
１１ｄ 通信部
１１ｅ 大容量記憶装置
１１ｆ 読取部
１１１ 可搬型記録媒体
１１２ 半導体メモリ
１２ データベース
１２ａ 債務者ＤＢ
１２ｂ ローンＤＢ
１２ｃ 交渉履歴ＤＢ（履歴記憶部）
１２ｄ ＡＴＭ督促判定ＤＢ
１２ｅ テンプレートＤＢ（雛型記憶部）
１２ｆ メッセージＤＢ（通知データ記憶部）
１２ｇ オペレータＤＢ
１３ オペレータ端末
２ 勘定系システム
２１ 勘定系サーバ
２１ａ ＣＰＵ
２１ｂ ＲＡＭ
２１ｃ ＲＯＭ
２１ｄ 通信部
２１ｅ 大容量記憶装置
２１ｆ 読取部
２２ データベース
２２ａ メッセージＤＢ（通知データ記憶部）
２２ｂ 入出金履歴ＤＢ
３ 端末装置
３１ ＡＴＭ装置
３１ａ ＣＰＵ
３１ｂ ＲＡＭ
３１ｃ カードリーダ
３１ｄ 操作部
３１ｅ 表示部
３１ｆ 通信部
３１ｇ 記憶部
４ 金融機関システム
４１ ロードバランサ
４２ アプリケーションサーバ
４３ データベース
４３ａ 債務者ＤＢ
４３ｂ ローンＤＢ
４３ｃ 交渉履歴ＤＢ（履歴記憶部）
４３ｄ ＡＴＭ督促判定ＤＢ
４３ｅ テンプレートＤＢ（雛型記憶部）
４３ｆ メッセージＤＢ（通知データ記憶部）
４３ｇ オペレータＤＢ
４３ｈ 入出金履歴ＤＢ
４４ オペレータ端末
Ｎ ネットワーク

Claims (8)

1. コールセンターシステムで管理される督促対象の顧客の識別情報を記憶する顧客情報記憶部と、
   前記コールセンターシステムで管理される顧客との連絡に関する履歴を該顧客の識別情報と対応付けて記憶する履歴記憶部と、
   勘定系システムにおける顧客により入出金の操作が行われる装置において顧客情報を検出した場合に、前記顧客情報記憶部に記憶されている識別情報に対応付けられた履歴を前記履歴記憶部から読み出す読み出し部と、
   読み出した前記履歴の内容が所定の督促の条件を満たす顧客を特定する特定部と、
   特定した前記顧客が満たす前記所定の督促の条件に対応する、前記入出金の操作を行う装置に表示させる通知データであって、前記入出金の操作を行う装置に対する顧客の操作により前記通知データが確認された情報を取得した場合に前記履歴記憶部の履歴を更新するために表示させる通知データを生成する生成部と、
   を備える通知データ生成装置。
2. 前記特定部は、顧客への連絡が不能であった旨の情報を含む履歴が所定回数連続している顧客を特定する
   請求項１記載の通知データ生成装置。
3. 通知データの雛形を記憶する雛型記憶部を備え、
   前記生成部は前記読み出した履歴に基づいて、前記雛型記憶部が記憶する雛形を選択して読み出し、読み出した雛形を用いて通知データを生成する
   請求項１又は２に記載の通知データ生成装置。
4. 前記履歴には、前記生成部が生成した通知データの生成履歴が含まれ、
   前記生成部は前記生成履歴を用いて雛形を選択する
   請求項３に記載の通知データ生成装置。
5. 前記読み出し部が読み出した識別情報に対応付けられた顧客の職業、性格を含む顧客情報を読み出す第２読み出し部を備え、
   前記特定部は、読み出した顧客情報と前記履歴に基づいて、顧客を特定する
   請求項１から請求項４に記載の通知データ生成装置。
6. コールセンターシステムで管理される督促対象の顧客の識別情報を読み出し、
   読み出した識別情報に対応付けられた前記コールセンターシステムで管理される顧客との連絡に関する履歴を読み出し、
   読み出した前記履歴の内容が所定の督促の条件を満たす顧客を特定し、
   特定した前記顧客が満たす前記所定の督促の条件に対応する、前記入出金の操作を行う装置に表示させる通知データであって、前記入出金の操作を行う装置に対する顧客の操作により前記通知データが確認された情報を取得した場合に前記履歴を更新するために表示させる通知データを生成する
   処理をコンピュータに実行させるコンピュータプログラム。
7. 制御部を有するコンピュータによる通知データ生成方法において、
   コールセンターシステムで管理される督促対象の顧客の識別情報を読み出し、
   読み出した識別情報に対応付けられた前記コールセンターシステムで管理される顧客との連絡に関する履歴を読み出し、
   読み出した前記履歴の内容が所定の督促の条件を満たす顧客を特定し、
   特定した前記顧客が満たす前記所定の督促の条件に対応する、前記入出金の操作を行う装置に表示させる通知データであって、前記入出金の操作を行う装置に対する顧客の操作により前記通知データが確認された情報を取得した場合に前記履歴を更新するために表示させる通知データを生成する
   通知データ生成方法。
8. コールセンターシステムで管理される督促対象の顧客の識別情報を読み出し、
   読み出した識別情報に対応付けられた前記コールセンターシステムで管理される顧客との連絡に関する履歴を読み出し、
   読み出した前記履歴の内容が所定の督促の条件を満たす顧客を特定し、特定した前記顧客が満たす前記所定の督促の条件に対応する、前記入出金の操作を行う装置に表示させる通知データであって、前記入出金の操作を行う装置に対する顧客の操作により前記通知データが確認された情報を取得した場合に前記履歴を更新するために表示させる通知データを生成する通知データ生成装置と、該通知データ生成装置が生成した通知データを識別情報と対応付けて記憶する通知データ記憶部と、前記通知データを表示する表示装置と、を備え、
   前記表示装置は、
   取得した識別情報と対応付けられた通知データが前記通知データ記憶部に記憶されているか否かを判定する判定部、
   通知データが記憶されていると前記判定部が判定した場合、前記識別情報と対応付けられた通知データを前記通知データ記憶部から読み出し表示する表示部、
   操作を受け付ける受付部を有し、
   前記表示部に前記通知データが表示された後、該通知データに対する応答操作を受け付けるまで、前記受付部はそれ以外の操作を受け付けず、
   前記通知データに対する応答操作を受け付けた場合、受け付けた旨を前記通知データ生成装置に送信する
   ことを特徴とする通知システム。

Images