以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
図1は、本実施形態による監視システムの構築例を説明する図である。
この監視システム1は、銀行等の金融機関が設置した各自動取引装置3(3−1〜3−10)の状態を監視するために構築されたシステムである。図1に表すように、監視システム1は、サーバ2、監視対象である複数台の自動取引装置3(3−1〜3−10)、端末装置4をネットワーク5に接続した構成となっている。
図1では、自動取引装置3としてATM(Automated teller machine)を10台のみ表している。各ATM3での取引を可能にさせるホストコンピュータ等は監視システム1には含まれないことから、省略している。
各ATM3は、各種異常(エラー)を自律的に検出する機能を備え、異常を検出した場合、検出した異常をサーバ2に通知する。ATM3が異常を通知するためにサーバ2に送信する異常情報は、エラー種別情報、発生日時情報、及び詳細情報を含む。
エラー種別情報は、検出された異常の種類を表す情報である。発生日時情報は、ATM3が異常を検出したときの日時(現在日時)を表す情報である。詳細情報は、検出された異常に係わる詳細な内容を表す情報である。
エラー種別情報が表す異常の種類には、通帳のMSに記録された印字開始行情報が表す行に印字が行われている通帳印字異常が含まれる。その通帳印字異常が検出された場合、詳細情報は、通帳の識別情報である口座情報、その通帳印字異常を検出したATM3の識別情報(以降「現装置情報」と表記)、及びその通帳への記帳を直前に行ったATM3の識別情報(以降「前装置情報」と表記)を含む。
上記発生日時情報は、ATM3から送信させなくとも良い。これは、異常情報を受信した日時を表す情報を、発生日時情報の代わりに用いても良いからである。このこともあり、異常情報の構成は上記のようなものに限定されない。
サーバ2は、本実施形態による監視装置である。本実施形態による監視システム1は、本実施形態による監視装置であるサーバ2を用いて構築されている。
サーバ2は、各ATM3の状態を監視し、各ATM3から送信された異常情報を管理する。そのサーバ2は、図1に表すように、CPU(Central Processing Unit)11、メモリ(メモリモジュール)12、FWH(Firm-Ware Hub)13、ハードディスク装置(HD)14、通信制御部15、及びそれら各構成要素11〜15間を接続するバス16を備えている。
FWH13は、ファームウェアを格納した不揮発性のメモリである。ハードディスク装置14には、OS(Operating System)、各種アプリケーション・プログラム(以降「アプリケーション」と略記)、及び各種データ等が格納されている。CPU11は、電源のオンにより、FWH13からファームウェアをメモリ12に読み出して起動し、その後、ハードディスク装置14からOS、及びアプリケーションをメモリ12に読み出して起動する。
ハードディスク装置14には、異常情報の保存用に構築されたデータベース(DB)である通知異常DB14a、抽出設定情報14b、及び通帳印字異常の発生要因を推定するためのアプリケーション(以降「解析ソフト」と表記)14cが格納されている。
サーバ2は、何れかのATM3から通帳印字異常の発生を通知する異常情報を受信した場合、その通帳印字異常を発生させた要因の推定を行い、必要に応じて、その推定結果を予め設定された通知先に通知する。この機能は、解析ソフト14cによって実現される。ここでは、その通知先として端末装置4を想定する。その端末装置4は、例えばATM3の補修、及び管理のために設置されたPC(Personal Computer)である。通知先は複数、設定しても良く、通知先はPCのような端末装置に限定されない。
図2は、サーバの機能構成例を表す図であり、図3は、ATMの構成例を表す図である。図2を参照したサーバ2の説明を行う前に、図3を参照し、各ATM3について詳細に説明する。
各ATM3は、図3に表すように、表示ユニット30、カード処理ユニット40、通帳処理ユニット50、硬貨処理ユニット60、紙幣処理ユニット70、及び制御ユニット80を備える。
表示ユニット30は、取引に関する画面、各種メッセージ等の表示に用いられる表示部30aを備える。その表示部30aは、表示装置の他に、利用者が操作を行うためのタッチパネルを備えている。
硬貨処理ユニット60は、利用者への硬貨の出金、及び利用者が入金した硬貨の収納等を行うユニットである。紙幣処理ユニット70は、利用者への紙幣の出金、及び利用者が入金した紙幣の収納等を行うユニットである。
カード処理ユニット40は、キャッシュカード、クレジットカード等の各種カードの利用を可能にさせるユニットである。図3に表すように、カード処理ユニット40は、カード挿入/排出口40a、磁気データ読取部40b、エンボスデータ読取部40c及び文字認識部40dを備える。
カード処理ユニット40の磁気データ読取部40b、及びエンボスデータ読取部40cは、カード挿入/排出口40aから挿入されたカードに記録されている磁気データ、及びエンボス加工部分の読み取りを行う。文字認識部40dは、エンボスデータ読取部40cが読み取ったエンボス加工部分に形成されている文字認識を行う。読み取られた磁気データ、及び文字認識結果は、カード処理ユニット40から制御ユニット80に出力される。
通帳処理ユニット50は、通帳を用いた各種取り引き(記帳を含む)を可能にするためのユニットである。図3に表すように、通帳処理ユニット50は、通帳挿入/排出口50a、磁気データ読取部50b、光学データ読取部50c及び文字認識部50dを備えている。
通帳挿入/排出口50aは、通帳の挿入、及び排出用に設けられた構成要素である。通帳挿入/排出口50aに挿入された通帳は、内部に搬送され、その搬送中に、通帳のMSに記録された各種情報は磁気データ読取部50bによって読み取られ、通帳画像は光学データ読取部50cによって光学的に読み取られる。
通帳の印字対象ページ上には、ページ番号を表すバーコード、及び搬送上の基準となるマークが印字されている。文字認識部50dは、光学データ読取部50cが読み取った通帳画像上のバーコード、マーク、及び取引内容が印字された行の認識を行う。取引内容が印字された行の位置は、マークを基準とした搬送量から特定される。MSから読み取られた各種情報(磁気情報)、及び印字が行われている印字行の認識結果は通帳処理ユニット50から制御ユニット80に出力される。
制御ユニット80は、ATM3全体を制御するユニットである。その制御ユニット80は、図3に表すように、CPU80a、RAM(Random Access Memory)80b、ハードディスク装置(HDD:Hard Disk Drive)80c、グラフィックインタフェース80d、通信制御部80e、入出力インタフェース80f及びバス80gを備える。
バス80gは、各部80a〜80fを相互に接続させる。
ハードディスク装置80cには、OS、及び各種アプリケーションを含む各種プログラム、並びに各種データが記憶されている。CPU80aは、ハードディスク装置80c上の実行すべきプログラムをRAM20bに読み出して実行する。それにより、CPU80aは、ATM3全体を制御する。ハードディスク装置80cに記憶されるデータには、自ATM3に割り当てられた識別情報(以降「装置情報」と表記)が含まれる。
グラフィックインタフェース80dは、表示ユニット30の表示部30aに画像を表示させるためのインタフェースである。CPU80aは、グラフィックインターフェース80dを用いて、表示部30aに表示させるべき画像を表示させる。
通信制御部80eは、ネットワーク5を介して、サーバ2、及びホストコンピュータ等と通信を行うためのインタフェースである。
入出力インタフェース80fは、カード処理ユニット40、通帳処理ユニット50、硬貨処理ユニット60及び紙幣処理ユニット70との通信を可能にするインタフェースである。
CPU80aは、通帳処理ユニット50から受信した情報、及び印字行の認識結果を用いて、通帳印字異常の発生の有無を判定する。その判定は、具体的には以下のようにして行われる。
通帳のMSには、磁気情報として、口座情報、印字開始行情報、印字開始ページ情報、及びその通帳への記帳を直前に行ったATM3を一意に表す装置情報(前装置情報)等が記録される。CPU80aは、印字開始ページ情報が表すページ番号が、バーコードが表すページ番号と一致するか否か確認する。それにより、CPU80aは、印字開始ページ情報が表すページが開かれた状態で通帳が挿入されていない場合、そのページが開かれるまで、ページ捲りを通帳処理ユニット50に行わせる。そのようにして、CPU80aは、印字を開始すべきページが開かれた状態の通帳画像を光学データ読取部50cに読み取らせる。
印字を開始すべきページが開かれた状態で光学データ読取部50cが読み取った通帳画像上のマークの位置は、印字開始行を特定するうえでの基準となる。CPU80aは、少なくとも印字開始行を想定した位置まで通帳を搬送させながら、光学データ読取部50cに通帳画像を読み取らせることにより、印字開始行と認識する位置に印字が存在するか否か、及び印字開始行と認識する位置の直前の行に印字が存在するか否かの確認を文字認識部50dに行わせる。その結果、印字開始行と認識する位置に印字が存在するか、或いは印字開始行と認識する位置の直前の行に印字が存在しないことが判明した場合、CPU80aは、通帳印字異常が検出されたとして、その通帳印字異常をサーバ2に通知する。その通帳印字異常の通知のために送信する異常情報には、上記のように、通帳印字異常を表すエラー種別情報、発生日時情報、口座情報、MSに記録されていた装置情報である前装置情報、自ATM3に割り当てられた装置情報である現装置情報が含まれる。本実施形態では、前装置情報をATM3に送信可能にするために、通帳のMSに対し、記帳を行ったATM3に自身の装置情報を記録させるようにしている。
印字異常を検出しなかったATM3が、結果として、印字開始行に印字を行うことも考えられる。その場合、次に通帳が挿入されるATM3は、例え正常に動作したとしても、通帳印字異常を検出することになる。このことから、通帳印字異常を発生させた要因として、直前に記帳を行ったATM3も考慮する必要がある。
ホストコンピュータは、取り引き内容を記録・保存している。そのため、直前に記帳を行ったATM3は、ホストコンピュータへの問い合わせ、或いは記録・保存された取り引き内容の確認により、特定することが可能である。しかし、監視システム1の構築では、ホストコンピュータへの問い合わせ、及び記録・保存されたデータの利用を想定しないのが普通である。そのため、本実施形態では、記帳を行ったATM3に、通帳のMSに自身の装置情報を記録させるようにしている。
CPU80aは、通帳印字異常が検出されず、且つ記帳を含む処理を実行した場合、通帳のMS上の印字開始行情報、印字開始ページ情報、及び装置情報を更新させる。それら磁気情報の更新は、磁気データ読取部50bを用いて行われる。
サーバ2は、上記のように、通帳印字異常を検出したATM3から受信する異常情報を用いて、その通帳印字異常を発生させた要因の推定を行い、必要に応じて、その推定結果を端末装置4に通知する。そのために、サーバ2は、図2に表すように、監視部21、記憶部22、解析部23、及び通信部24を備える。
監視部21は、ネットワーク5を介した各ATM3との通信を通して、必要な情報の取得、及び各ATM3の状態の確認等を行う機能である。異常を検出したATM3から送信される異常情報は、監視部21によって受信され、記憶部22上に構築された通知異常DB14aに格納される。
図1に表すハードディスク装置14には、14a〜14cを付したDB、或いはデータを表記している。それら14a〜14cは、記憶部22にも表記している。これは、ハードディスク装置14は少なくとも記憶部22に含まれるからである。
この通知異常DB14aは、例えば一定期間内に受信した異常情報の格納用のDBである。図4に表すように、サーバ2が受信した各異常情報は、それぞれ1エントリ(レコード)に格納される。図4では、便宜的に、通帳印字異常を通知する異常情報のみを各エントリ(レコード)に表している。
本実施形態では、通帳印字異常を発生させた要因の候補として、今回、通帳が挿入されたATM3(以降「現ATM3」と表記)、その通帳への記帳を直前に行ったATM3(以降「前ATM3」と表記)、及びその通帳を想定している。通帳を要因の候補としているのは、通帳が搬送上、不適切な状態であった場合、通帳印字異常を発生させる可能性が高いからである。前ATM3を要因の候補とすることにより、要因の推定はより適切に行えるようになる。
要因の推定(特定)では、何らかの具体的な対応が必要と考えるべき状態を想定している。これは、例え要因を推定したとしても、その推定結果を用いた対応をしないことを想定するのであれば、要因を推定する必要性は小さいからである。
各ATM3の利用頻度、つまり単位時間当たりの利用者数は、ATM3(ここでは店舗を含む)によって異なる。そのため、単位時間当たりに検出される通帳印字異常の数は、そのままATM3の状態の推定に用いるのは望ましくない。このことから、抽出設定情報14bは、ATM3による単位時間当たりの利用者数の相違を排除する正規化のために用意している。
図5は、抽出設定情報の構成例を説明する図である。
本実施形態では、要因の推定は、通知異常DB14aから参照すべきエントリを抽出して行うようにしている。抽出設定情報14bは、エントリの抽出の対象とする範囲をATM3毎に制限するために用いられる。それにより、抽出設定情報14bは、期間と、その期間が割り当てられた対象(ATM3の装置情報、或いは通帳)の組み合わせを表す情報となっている。その期間とは、現在日時を基準に、エントリの抽出範囲の境界となる日時(最も古い日時)を表す情報であり、図5に表記の「α1」〜「α3」及び「β」は、それぞれ異なる数値を表している。
この抽出設定情報14bにより、ATM3を対象とする要因推定では、同じ所定回数の利用を想定し、その所定回数の利用時にATM3から送信されたと推定されるエントリ分のみを通知異常DB14aからの抽出対象とさせるようにしている。この抽出設定情報14bの記憶部22(ハードディスク装置14)への保存は、端末装置4を用いて行うことが可能である。
解析部23は、通帳印字異常の通知を契機に、通知異常DB14aを参照し、要因を推定する機能である。要因の推定は、通帳とATM3は別に行うようになっている。
ATM3を対象にした要因の推定では、解析部23は、通知された現装置情報、及び前装置情報を用いて抽出設定情報14bを参照し、エントリの抽出対象範囲を確認する。その確認により、解析部23は、現装置情報、及び前装置情報をそれぞれキーにして、通知異常DB14aから、キーとする装置情報が現装置情報、或いは前装置情報として格納されているエントリのなかで抽出対象範囲内となっているエントリのみを抽出する。図6は、そのようにして通知異常DB14aから抽出されたエントリ例を表している。
解析部23は、エントリを抽出した後、通知された現装置情報、及び前装置情報毎に、その出現回数を計数する。それにより、本実施形態では、現装置情報、或いは前装置情報として装置情報が通知されたATM3のなかで、その装置情報の出現回数が閾値とする所定値以上となっているATM3を、通帳印字異常を発生させた要因と推定するようにしている。そのように推定しているのは、複数台のATM3に同時に不具合が発生する可能性は比較的に低い、不具合が発生しているATM3を別の不具合が発生していないATM3を利用者が交互に利用することは少ない、等と考えられるからである。
通知された現装置情報、及び前装置情報の出現回数が共に所定値以上となる可能性がある。本実施形態では、その場合、通知された現装置情報、及び前装置情報の2つの装置情報が格納されたエントリの数、並びに、通知された現装置情報、及び前装置情報のうちの一方が現装置情報、及び前装置情報として格納されているエントリの数の計数を行う。
現装置情報、及び前装置情報として装置情報がエントリに格納されているATM3は、不具合が発生している可能性が比較的に高いと考えられる。このことから、本実施形態では、現装置情報、及び前装置情報として同じ装置情報が格納されているエントリは、不具合が発生しているATM3を推定するうえで有効なエントリと位置付けている。それにより、本実施形態では、装置情報が現装置情報、及び前装置情報として格納されているエントリの数が複数、存在するATM3は、要因として推定するようにしている。
通知された現装置情報、及び前装置情報の2つの装置情報が格納されたエントリの数が多い場合、何れかの装置情報を有するATM3にのみ不具合が存在していれば、不具合の発生していないATM3の装置情報の出現回数も多くなり易い。しかし、現装置情報、及び前装置情報として同じ装置情報が格納されているエントリが存在しなければ、2台のATM3のうちで不具合が発生しているATM3の特定は困難である。このため、通知された現装置情報、及び前装置情報の2つの装置情報が格納されたエントリの数が多く、且つ現装置情報、及び前装置情報として同じ装置情報が格納されているエントリが存在しないような場合、2台のATM3が要因と推定するようにしている。通知された現装置情報、及び前装置情報の2つの装置情報が格納されたエントリの数が多く、且つ通知された現装置情報、及び前装置情報の一方が格納されているエントリが存在する場合、1台のATM3のみが要因と推定される。
また、通知された現装置情報、及び前装置情報の2つの装置情報が格納されたエントリの数が少ない場合(ここではエントリが存在しない場合も含む)、2台のATM3にそれぞれ不具合が発生している可能性が高いと考えられる。そのため、この場合も、2台のATM3が要因と推定するようにしている。
解析部23は、上記のようにして、要因となっているATM3の推定を高精度に行う。その要因の推定では、比較的に短い期間内に複数回、通帳印字異常を発生させていることを想定している。そのため、要因として推定されたATM3は、メンテナンス(ここでは、動作確認等を含む)を行う必要性が高いと云える。このことから、要因として推定されたATM3は、メンテナンスを行うべき対象として提示するのが望ましいものとなる。
本実施形態では、各ATM3は、通帳印字異常の検出により、異なるATM3の利用を促すメッセージを表示部30aに表示させるようにしている。そのため、多くの利用者は、通帳印字異常が検出された場合、2台以上の異なるATM3を利用して、通帳を用いた取り引きを試みると考えられる。また、搬送上、不適切な状態となった通帳は、連続的に通帳印字異常が発生すると考えられる。このようなことから、同じ通帳で発生した通帳印字異常の最小発生間隔が設定時間より短かった場合、解析部23は通帳を要因と推定する。
通帳を対象にした要因の推定では、解析部23は、抽出設定情報14bを参照し、通帳のエントリの抽出対象範囲を確認する。その確認結果を用いて、解析部23は、口座情報をキーにして、通知異常DB14aから、キーとする口座情報が格納されているエントリの抽出を行う。図7は、そのようにして通知異常DB14aから抽出されたエントリ例を表している。
解析部23は、エントリを抽出した後、発生日時情報が表す発生日時が前後する2つのエントリ毎に、発生間隔(=前後する発生日時の間の間隔)を算出し、算出した発生間隔のなかで最小の発生間隔を最小発生間隔として抽出する。解析部23は、そのようにして抽出される最小発生間隔を設定時間と比較することにより、通帳が要因か否かの判定を行う。
1台以上のATM3を要因と推定した場合、解析部23は、要因と推定されるATM3のメンテナンス等の必要性の通知を通信部24に指示する。その指示により、通信部24は、端末装置4に対し、要因と推定されるATM3の装置情報等を含むメッセージを送信し、そのATM3へのメンテナンス等を促す。この結果、メンテナンス等を行うべきATM3へのタイムリなメンテナンス等の対応が可能になる。
サーバ2が図1に表すような構成であった場合、監視部21、及び通信部24は、CPU11、メモリ12、FWH13、ハードディスク装置14、通信制御部15、及びバス16によって実現される。記憶部22は、ハードディスク装置14であるか、或いはハードディスク装置14、メモリ12、及びバス16によって実現される。解析部23は、CPU11、メモリ12、FWH13、ハードディスク装置14、及びバス16によって実現される。
以降は、図8、及び図9にそれぞれフローチャートを表す処理について詳細に説明する。
図8は、通帳取引処理のフローチャートである。この通帳取引処理は、利用者が通帳を通帳挿入/排出口50aに挿入するか、或いは表示部30aを操作して、通帳を用いた取り引きを利用者が要求したことを契機に、その通帳を用いた各種取り引きを可能にするために実行される処理である。この通帳取引処理自体は、制御ユニット80のCPU80aが、ハードディスク装置80c上の制御用プログラムを実行することで実現される。始めに図8を参照し、通帳を利用者が挿入した場合のATM3の動作について詳細に説明する。
先ず、CPU80aは、通帳挿入/排出口50aに設けられた通帳検出用のセンサが通帳を検出するのを待って、通帳の搬送を通帳処理ユニット50に行わせる(S11)。CPU80aは、通帳の搬送を行わせている間に、通帳のMSに記録されている磁気情報の読み取り(S12)、通帳画像(通帳イメージ)の読み取り、その文字認識を通帳処理ユニット50に行わせる(S13)。読み取られた磁気情報、通帳画像上の文字認識結果(印字開始行、及び印字開始行の直前の行での印字の有無を含む)は通帳処理ユニット50から制御ユニット80のCPU80aに出力される。
次に、CPU80aは、通帳画像上の文字認識結果から、印字開始行のチェック結果がNG、つまり印字開始行に印字が行われているか否か、及び印字開始行の直前の行に印字が行われているか否かを判定する(S14)。印字開始行と認識する位置に何らかの印字が行われていた場合、或いは印字開始行と認識する位置の直前の行に何らかの印字が行われていない場合、S14の判定はYESとなってS19に移行する。印字開始行と認識する位置に印字が確認できない場合、及び印字開始行と認識する位置の直前の行に印字が確認された場合、S14の判定はNOとなってS15に移行する。
S15では、CPU80aは、表示部30aへの利用者の操作に応じた取り引きを可能にさせる取引処理を実行する。その後、CPU80aは、取り引きが正常終了したか否か判定する(S16)。通帳への記帳を含む手続きが終了した場合、S16の判定はYESとなってS17に移行する。通帳への記帳を行うことなく手続きが終了した場合、S16の判定はNOとなってS18に移行する。
S17では、CPU80aは、通帳を通帳挿入/排出口50aに向けて搬送させながら、通帳のMSに記録されている磁気情報の更新を行う。その更新により、印字開始行情報、及び印字開始ページ情報は記帳結果に応じて更新され、装置情報はハードディスク装置80cに保存されている装置情報に更新される。
磁気情報を更新したCPU80aは、通帳を通帳挿入/排出口50aから排出させるまで搬送させる(S18)。その通帳が検出されなくなった後、この通帳取引処理が終了する。
上記S14の判定はYESとなって移行するS19では、今回、挿入された通帳が直前に挿入された通帳と同じか否か判定する。通帳印字異常の検出により返却された通帳を再度、利用者が挿入した場合、2つの通帳は口座情報が一致する。そのため、S19の判定はYESとなり、上記S18に移行する。一方、2つの通帳の口座情報が一致しない場合、S19の判定はNOとなってS20に移行する。
S20では、CPU80aは、通帳印字異常が発生した旨を通知するための異常情報をサーバ2宛に送信させる。その異常情報は、エラー種別情報、発生日時情報、口座情報、現装置情報、及び前装置情報を含む。そのような異常情報を送信させた後、通帳取引処理が終了する。
このようにして、本実施形態では、通帳印字異常の検出により返却された通帳を再度、利用者が挿入した場合、通帳印字異常が検出されても異常情報は送信させないようにしている。これは、通帳自体、及び通帳が挿入されたATM3の少なくとも一方が通帳印字異常の要因となっている場合、通帳を挿入する度に、通帳印字異常が検出される可能性が考えられるからである。
同じ通帳が同じATM3に挿入される度に、通帳印字異常が検出され、異常情報が送信される場合、2回目以降に送信される異常情報は、要因の推定には不要である。最小発生間隔はより短くさせやすく、装置情報の出現回数は不要に多くさせる。それにより、2回目以降に送信される異常情報は、要因の推定精度を低下させる方向に作用する。このようなことから、本実施形態では、2回目以降の異常情報の送信は回避させるようにしている。
図9は、要因判定処理のフローチャートである。この要因判定処理は、通帳印字異常の発生を通知する異常情報の受信を契機に、その通帳印字異常を発生させた要因を特定(推定)するために実行される処理である。図2に表す解析部23は、CPU11が、この要因判定処理を実行することで実現される。この要因判定処理自体は、CPU11が、ハードディスク装置14上の解析ソフト14cを実行することで実現される。
先ず、CPU11は、受信した異常情報により通知された現装置情報、及び前装置情報を用いて抽出設定情報14bを参照して、通知異常DB14aからエントリの抽出対象範囲を確認する。その確認結果を用いて、CPU11は、通知された口座情報が格納されたエントリ、及び現装置情報、或いは前装置情報が格納されたエントリを通知異常DB14aから抽出する(以上S31)。
次に、CPU11は、口座情報をキーにして抽出されたエントリを参照し、最小発生間隔を算出する(S32)。続いて、CPU11は、最小発生間隔が設定時間より短いか否か判定する(S33)。通帳印字異常が検出された後、通帳を別のATM3に挿入しても通帳印字異常が検出されたような場合、最小発生間隔は設定時間よりも短くなる。そのため、S33の判定はYESとなってS34に移行する。一方、別のATM3に通帳を挿入しても通帳印字異常が検出されなかったような場合、最小発生間隔は設定時間以上となる。そのため、S33の判定はNOとなってS34に移行する。
S34では、CPU11は、通帳を、通知された通帳印字異常を発生させた要因と推定する。
この推定結果は、通帳印字異常を検出したATM3に、通帳の再発行、或いは通帳の状態の確認を利用者に促すメッセージを表示させる契機としても良い。そのようなメッセージを提示させることにより、利用者がATM3をより快適に利用できる環境を実現させることができる。
次に、CPU11は、通知された現装置情報、或いは前装置情報をキーにして抽出されたエントリを参照し、現装置情報、及び前装置情報毎に、その出現回数を計数する(S35)。その計数を行った後、CPU11は、所定値以上の出現回数があるか否か判定する(S36)。通知された現装置情報、及び前装置情報の2つの出現回数のうちの少なくとも1つが所定値以上であった場合、S36の判定はYESとなってS37に移行する。2つの出現回数が共に所定値未満であった場合、S36の判定はNOとなり、ここで要因判定処理が終了する。
S37では、CPU11は、所定値以上となった出現回数が2であるか否か判定する。2つの出現回数が共に所定値以上であった場合、S37の判定はYESとなってS38に移行する。2つの出現回数のうちの一方のみ、所定値以上であった場合、S37の判定はNOとなってS42に移行する。通知された現装置情報と前装置情報が同じであっても、S37での判定はNOとなる。
S38では、CPU11は、現装置情報、及び前装置情報として通知された2つの装置情報が格納されたエントリ数、及び現装置情報、或いは前装置情報として通知された1つの装置情報のみが格納されたエントリ数をそれぞれ計数する。次に、CPU11は、それぞれ計数したエントリ数から、現装置情報、及び前装置情報がそれぞれ割り当てられた2台のATM3のなかの一方のみが要因である可能性が高いか否か判定する(S39)。上記のように、現装置情報、及び前装置情報として通知された2つの装置情報が格納されたエントリ数が少ない場合、2台のATM3が共に要因である可能性は高い。また、現装置情報、或いは前装置情報として通知された1つの装置情報のみが格納されたエントリ数が共に複数、存在するような場合も、2台のATM3が共に要因である可能性は高い。そのように、2台のATM3が共に要因である可能性が高い場合、S39の判定はNOとなってS40に移行する。
一方、現装置情報、及び前装置情報として通知された2つの装置情報が格納されたエントリ数が多く、且つ現装置情報、或いは前装置情報として通知された1つの装置情報のみが格納されたエントリ数のうちの1つのみが複数、存在するような場合、1台のATM3のみが要因である可能性は高い。このため、そのような場合、S39の判定はYESとなってS42に移行する。
S40では、CPU11は、現装置情報、及び前装置情報として装置情報が通知された2台のATM3を共に要因として推定する。CPU11は、要因として推定した2台のATM3を端末装置4宛に通知する(S41)。その後、この要因判定処理が終了する。
一方、S37でのNOの判定、或いはS39でのYESの判定により移行するS42では、CPU11は、装置情報の出現回数が所定値以上となった1台のATM3、或いは計数したエントリ数から特定した1台のATM3を要因として推定する。その後はS41に移行し、CPU11は、要因として推定した1台のATM3を端末装置4に通知する。
なお、本実施形態では、過去の要因の推定結果を反映させた要因の推定を行っていないが、要因の推定は、過去の要因の推定結果を反映させる形で行うようにしても良い。或るATM3に不具合が存在している場合、そのATM3が記帳を行った通帳が次に挿入されるATM3が通帳印字異常を検出する可能性は高い。そのため、或るATM3に存在する不具合により、実際には不具合が存在しない別のATM3の装置情報が異常情報の形でサーバ2に通知される頻度が高くなる可能性がある。実際には不具合が存在しなくとも、装置情報が多くサーバ2に通知されるATM3は、要因として推定される可能性が高くなる。このようなことから、要因として推定されたATM3の装置情報が格納されているエントリを抽出対象から除外するようにしても良い。そのような除外を行った場合、メンテナンス等が必要なATM3をより高精度に推定できるようになる。
故障と見なすまでの異常の発生頻度は、時間の経過に従って高くなる傾向がある。このことから、出現回数の計数では、現在日時と発生日時の間隔に応じた重みを設定し、設定した重みを出現回数の計数に反映させるようにしても良い。このことも含め、要因の推定方法も様々な変形を行うことができる。