JP6055432B2 - 監視システム、監視装置、及び監視プログラム - Google Patents

Description

本発明は、通帳への印字（記帳）を含む各種取り引きが可能な自動取引装置を監視するための技術に関する。

利用者（顧客）が入金、出金、振り込み等の所望の取り引きを行える自動取引装置は、広く用いられている。ＣＤ（Cash Dispenser）、及びＡＴＭ（Automated Teller Machine）等は、代表的な自動取引装置である。

自動取引装置のなかには、通帳を用いた取り引きを行えるものがある。通帳を用いた取り引きが行える自動取引装置では、取引内容を表す取引情報を通帳に印字する記帳も行えるようになっている。

通帳には、各種情報が記録されるＭＳ（Magnetic Stripe：磁気ストライプ）が設けられている。そのＭＳには、適切な位置から記帳できるように、口座情報に加えて、次の印字を開始すべき行（印字開始行）を表す情報（印字開始行情報）、及び次に印字を開始すべきページを表す情報（印字開始ページ情報）が記録される。

利用者によって通帳が挿入された自動取引装置は、ＭＳに記録された各種情報を読み取ると共に、通帳の画像を光学的に読み取る。それにより、自動取引装置は、印字開始行情報が表す位置から記帳が可能か否かを、読み取った画像を用いて確認するようになっている。印字開始行情報が表す位置に既に印字が行われているような場合、或いは印字開始行情報が表す位置の直前の行（最後の印字を行った行（印字最終行））に印字が行われていない場合、その確認によって、自動取引装置は記帳を行うべきでない通帳異常（以降「通帳印字異常」と表記）が発生していると見なしている。

このような通帳印字異常に対応するための従来技術としては、監視対象とする自動取引装置と監視装置とをネットワークにより接続し、検出された異常に係わる情報（以降「異常情報」と表記）を自動取引装置から監視装置に送信させる監視システムがある。

この従来の監視システムでは、通帳印字異常を検出した自動取引装置に、異常情報として、現在日時を表す日時情報、口座情報、その自動取引装置の識別情報（以降「装置情報」と表記）、及び異常の種類を表すエラー種別情報を監視装置に送信させるようになっている。監視装置は、異常を検出した自動取引装置から送信される異常情報を保存し、保存した異常情報を参照して、検出された異常を発生させた要因を推定する。

通帳の画像（イメージ）は、その通帳を搬送しながら読み取られるようになっている。通帳の印字対象ページには、搬送上の基準となるマークが印字されており、多くの自動取引装置は、印字開始行の特定を、そのマークを基準とした搬送量から行うようになっている。そのため、通帳印字異常は、挿入された通帳を自動取引装置が適切に搬送できない場合に発生する。また、通帳が挿入された自動取引装置に不具合がないとしても、挿入された通帳の状態が不適切であった場合、その通帳が適切に搬送できない可能性は高くなる。このようなことから、従来の監視システムを構成する監視装置は、通帳印字異常を発生させた要因を、通帳、及びその通帳が挿入された自動取引装置のなかから特定している。

通帳への記帳により、次に印字を開始すべき行は変化する。そのため、通帳への記帳を行った自動取引装置は、ＭＳに記録されている印字開始行情報を更新する。しかし、自動取引装置は、その記帳結果を確認しないのが普通である。

記帳を行ったことは、つまり通帳印字異常が検出されなかったことは、通帳の画像の読み取り時に、その通帳を適切に搬送できた可能性があることを意味する。しかし、通帳を適切に搬送できたことを確実に保証しない。また、印字中の搬送が適切に行われたことも保証しない。

例えば自動取引装置に、適切な搬送量よりも大きく通帳を搬送させる障害が発生していると想定する。その想定では、自動取引装置は、実際の印字開始行よりも後に位置する行（実際の印字開始行よりも大きい搬送量が必要な行）を印字開始行と見なすことになる。
そのため、通帳印字異常は検出されない。しかし、最後の印字を行った行（印字最終行）は、自動取引装置が認識している位置よりも後になる。それにより、印字開始行に印字が行われている可能性は非常に高い。従い、そのような記帳が行われた通帳が次に挿入される自動取引装置は、例え正常に通帳を搬送したとしても、通帳印字異常を検出する可能性が非常に高い。このようなことから、通帳印字異常を発生させた要因をより適切に推定するには、通帳への記帳を直前に行った自動取引装置も考慮する必要があると考えられる。

特開２０１３−１４５５３４号公報 特開２００２−８１１０号公報

１側面では、本発明は、通帳への記帳を中止すべき通帳異常（通帳印字異常）を発生させた要因をより適切に推定するための技術を提供することを目的とする。

本発明を適用した１システムでは、利用者が挿入した通帳の画像を読み取り、該読み取った画像から、通帳への印字である記帳を中止すべき通帳異常を検出する複数台の自動取引装置と、各自動取引装置が検出した通帳異常がネットワークを介して通知される監視装置とを備え、監視装置は、通帳異常を検出した自動取引装置である第１の自動取引装置から、通帳を特定可能な第１の識別情報、第１の自動取引装置を特定可能な第２の識別情報、及び通帳への記帳を直前に行った自動取引装置である第２の自動取引装置を特定可能な第３の識別情報を異常通知情報として受信する送受信部と、送受信部が受信した異常通知情報を、通帳異常が検出された日時を表す日時情報と共に保存する記憶部と、記憶部に保存された異常通知情報、及び日時情報を用いて、第２の自動取引装置が第１の自動取引装置に通帳異常を検出させた要因の候補として要因推定を行う解析部と、を有する。

本発明を適用した場合には、通帳への記帳を中止すべき通帳異常（通帳印字異常）を発生させた要因をより適切に推定することができる。

本実施形態による監視システムの構築例を説明する図である。 サーバの機能構成例を表す図である。 ＡＴＭの構成例を表す図である。 通知異常ＤＢの構成例を説明する図である。 抽出設定情報の構成例を説明する図である。 現装置情報、及び前装置情報から抽出されたエントリ例を説明する図である。 口座情報から抽出されたエントリ例を説明する図である。 通帳取引処理のフローチャートである。 要因判定処理のフローチャートである。

以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
図１は、本実施形態による監視システムの構築例を説明する図である。

この監視システム１は、銀行等の金融機関が設置した各自動取引装置３（３−１〜３−１０）の状態を監視するために構築されたシステムである。図１に表すように、監視システム１は、サーバ２、監視対象である複数台の自動取引装置３（３−１〜３−１０）、端末装置４をネットワーク５に接続した構成となっている。

図１では、自動取引装置３としてＡＴＭ（Automated teller machine）を１０台のみ表している。各ＡＴＭ３での取引を可能にさせるホストコンピュータ等は監視システム１には含まれないことから、省略している。

各ＡＴＭ３は、各種異常（エラー）を自律的に検出する機能を備え、異常を検出した場合、検出した異常をサーバ２に通知する。ＡＴＭ３が異常を通知するためにサーバ２に送信する異常情報は、エラー種別情報、発生日時情報、及び詳細情報を含む。

エラー種別情報は、検出された異常の種類を表す情報である。発生日時情報は、ＡＴＭ３が異常を検出したときの日時（現在日時）を表す情報である。詳細情報は、検出された異常に係わる詳細な内容を表す情報である。

エラー種別情報が表す異常の種類には、通帳のＭＳに記録された印字開始行情報が表す行に印字が行われている通帳印字異常が含まれる。その通帳印字異常が検出された場合、詳細情報は、通帳の識別情報である口座情報、その通帳印字異常を検出したＡＴＭ３の識別情報（以降「現装置情報」と表記）、及びその通帳への記帳を直前に行ったＡＴＭ３の識別情報（以降「前装置情報」と表記）を含む。

上記発生日時情報は、ＡＴＭ３から送信させなくとも良い。これは、異常情報を受信した日時を表す情報を、発生日時情報の代わりに用いても良いからである。このこともあり、異常情報の構成は上記のようなものに限定されない。

サーバ２は、本実施形態による監視装置である。本実施形態による監視システム１は、本実施形態による監視装置であるサーバ２を用いて構築されている。

サーバ２は、各ＡＴＭ３の状態を監視し、各ＡＴＭ３から送信された異常情報を管理する。そのサーバ２は、図１に表すように、ＣＰＵ（Central Processing Unit）１１、メモリ（メモリモジュール）１２、ＦＷＨ（Firm-Ware Hub）１３、ハードディスク装置（ＨＤ）１４、通信制御部１５、及びそれら各構成要素１１〜１５間を接続するバス１６を備えている。

ＦＷＨ１３は、ファームウェアを格納した不揮発性のメモリである。ハードディスク装置１４には、ＯＳ（Operating System）、各種アプリケーション・プログラム（以降「アプリケーション」と略記）、及び各種データ等が格納されている。ＣＰＵ１１は、電源のオンにより、ＦＷＨ１３からファームウェアをメモリ１２に読み出して起動し、その後、ハードディスク装置１４からＯＳ、及びアプリケーションをメモリ１２に読み出して起動する。

ハードディスク装置１４には、異常情報の保存用に構築されたデータベース（ＤＢ）である通知異常ＤＢ１４ａ、抽出設定情報１４ｂ、及び通帳印字異常の発生要因を推定するためのアプリケーション（以降「解析ソフト」と表記）１４ｃが格納されている。

サーバ２は、何れかのＡＴＭ３から通帳印字異常の発生を通知する異常情報を受信した場合、その通帳印字異常を発生させた要因の推定を行い、必要に応じて、その推定結果を予め設定された通知先に通知する。この機能は、解析ソフト１４ｃによって実現される。ここでは、その通知先として端末装置４を想定する。その端末装置４は、例えばＡＴＭ３の補修、及び管理のために設置されたＰＣ（Personal Computer）である。通知先は複数、設定しても良く、通知先はＰＣのような端末装置に限定されない。

図２は、サーバの機能構成例を表す図であり、図３は、ＡＴＭの構成例を表す図である。図２を参照したサーバ２の説明を行う前に、図３を参照し、各ＡＴＭ３について詳細に説明する。

各ＡＴＭ３は、図３に表すように、表示ユニット３０、カード処理ユニット４０、通帳処理ユニット５０、硬貨処理ユニット６０、紙幣処理ユニット７０、及び制御ユニット８０を備える。

表示ユニット３０は、取引に関する画面、各種メッセージ等の表示に用いられる表示部３０ａを備える。その表示部３０ａは、表示装置の他に、利用者が操作を行うためのタッチパネルを備えている。

硬貨処理ユニット６０は、利用者への硬貨の出金、及び利用者が入金した硬貨の収納等を行うユニットである。紙幣処理ユニット７０は、利用者への紙幣の出金、及び利用者が入金した紙幣の収納等を行うユニットである。

カード処理ユニット４０は、キャッシュカード、クレジットカード等の各種カードの利用を可能にさせるユニットである。図３に表すように、カード処理ユニット４０は、カード挿入／排出口４０ａ、磁気データ読取部４０ｂ、エンボスデータ読取部４０ｃ及び文字認識部４０ｄを備える。

カード処理ユニット４０の磁気データ読取部４０ｂ、及びエンボスデータ読取部４０ｃは、カード挿入／排出口４０ａから挿入されたカードに記録されている磁気データ、及びエンボス加工部分の読み取りを行う。文字認識部４０ｄは、エンボスデータ読取部４０ｃが読み取ったエンボス加工部分に形成されている文字認識を行う。読み取られた磁気データ、及び文字認識結果は、カード処理ユニット４０から制御ユニット８０に出力される。

通帳処理ユニット５０は、通帳を用いた各種取り引き（記帳を含む）を可能にするためのユニットである。図３に表すように、通帳処理ユニット５０は、通帳挿入／排出口５０ａ、磁気データ読取部５０ｂ、光学データ読取部５０ｃ及び文字認識部５０ｄを備えている。

通帳挿入／排出口５０ａは、通帳の挿入、及び排出用に設けられた構成要素である。通帳挿入／排出口５０ａに挿入された通帳は、内部に搬送され、その搬送中に、通帳のＭＳに記録された各種情報は磁気データ読取部５０ｂによって読み取られ、通帳画像は光学データ読取部５０ｃによって光学的に読み取られる。

通帳の印字対象ページ上には、ページ番号を表すバーコード、及び搬送上の基準となるマークが印字されている。文字認識部５０ｄは、光学データ読取部５０ｃが読み取った通帳画像上のバーコード、マーク、及び取引内容が印字された行の認識を行う。取引内容が印字された行の位置は、マークを基準とした搬送量から特定される。ＭＳから読み取られた各種情報（磁気情報）、及び印字が行われている印字行の認識結果は通帳処理ユニット５０から制御ユニット８０に出力される。

制御ユニット８０は、ＡＴＭ３全体を制御するユニットである。その制御ユニット８０は、図３に表すように、ＣＰＵ８０ａ、ＲＡＭ（Random Access Memory）８０ｂ、ハードディスク装置（ＨＤＤ：Hard Disk Drive）８０ｃ、グラフィックインタフェース８０ｄ、通信制御部８０ｅ、入出力インタフェース８０ｆ及びバス８０ｇを備える。

バス８０ｇは、各部８０ａ〜８０ｆを相互に接続させる。
ハードディスク装置８０ｃには、ＯＳ、及び各種アプリケーションを含む各種プログラム、並びに各種データが記憶されている。ＣＰＵ８０ａは、ハードディスク装置８０ｃ上の実行すべきプログラムをＲＡＭ２０ｂに読み出して実行する。それにより、ＣＰＵ８０ａは、ＡＴＭ３全体を制御する。ハードディスク装置８０ｃに記憶されるデータには、自ＡＴＭ３に割り当てられた識別情報（以降「装置情報」と表記）が含まれる。

グラフィックインタフェース８０ｄは、表示ユニット３０の表示部３０ａに画像を表示させるためのインタフェースである。ＣＰＵ８０ａは、グラフィックインターフェース８０ｄを用いて、表示部３０ａに表示させるべき画像を表示させる。

通信制御部８０ｅは、ネットワーク５を介して、サーバ２、及びホストコンピュータ等と通信を行うためのインタフェースである。

入出力インタフェース８０ｆは、カード処理ユニット４０、通帳処理ユニット５０、硬貨処理ユニット６０及び紙幣処理ユニット７０との通信を可能にするインタフェースである。

ＣＰＵ８０ａは、通帳処理ユニット５０から受信した情報、及び印字行の認識結果を用いて、通帳印字異常の発生の有無を判定する。その判定は、具体的には以下のようにして行われる。

通帳のＭＳには、磁気情報として、口座情報、印字開始行情報、印字開始ページ情報、及びその通帳への記帳を直前に行ったＡＴＭ３を一意に表す装置情報（前装置情報）等が記録される。ＣＰＵ８０ａは、印字開始ページ情報が表すページ番号が、バーコードが表すページ番号と一致するか否か確認する。それにより、ＣＰＵ８０ａは、印字開始ページ情報が表すページが開かれた状態で通帳が挿入されていない場合、そのページが開かれるまで、ページ捲りを通帳処理ユニット５０に行わせる。そのようにして、ＣＰＵ８０ａは、印字を開始すべきページが開かれた状態の通帳画像を光学データ読取部５０ｃに読み取らせる。

印字を開始すべきページが開かれた状態で光学データ読取部５０ｃが読み取った通帳画像上のマークの位置は、印字開始行を特定するうえでの基準となる。ＣＰＵ８０ａは、少なくとも印字開始行を想定した位置まで通帳を搬送させながら、光学データ読取部５０ｃに通帳画像を読み取らせることにより、印字開始行と認識する位置に印字が存在するか否か、及び印字開始行と認識する位置の直前の行に印字が存在するか否かの確認を文字認識部５０ｄに行わせる。その結果、印字開始行と認識する位置に印字が存在するか、或いは印字開始行と認識する位置の直前の行に印字が存在しないことが判明した場合、ＣＰＵ８０ａは、通帳印字異常が検出されたとして、その通帳印字異常をサーバ２に通知する。その通帳印字異常の通知のために送信する異常情報には、上記のように、通帳印字異常を表すエラー種別情報、発生日時情報、口座情報、ＭＳに記録されていた装置情報である前装置情報、自ＡＴＭ３に割り当てられた装置情報である現装置情報が含まれる。本実施形態では、前装置情報をＡＴＭ３に送信可能にするために、通帳のＭＳに対し、記帳を行ったＡＴＭ３に自身の装置情報を記録させるようにしている。

印字異常を検出しなかったＡＴＭ３が、結果として、印字開始行に印字を行うことも考えられる。その場合、次に通帳が挿入されるＡＴＭ３は、例え正常に動作したとしても、通帳印字異常を検出することになる。このことから、通帳印字異常を発生させた要因として、直前に記帳を行ったＡＴＭ３も考慮する必要がある。

ホストコンピュータは、取り引き内容を記録・保存している。そのため、直前に記帳を行ったＡＴＭ３は、ホストコンピュータへの問い合わせ、或いは記録・保存された取り引き内容の確認により、特定することが可能である。しかし、監視システム１の構築では、ホストコンピュータへの問い合わせ、及び記録・保存されたデータの利用を想定しないのが普通である。そのため、本実施形態では、記帳を行ったＡＴＭ３に、通帳のＭＳに自身の装置情報を記録させるようにしている。

ＣＰＵ８０ａは、通帳印字異常が検出されず、且つ記帳を含む処理を実行した場合、通帳のＭＳ上の印字開始行情報、印字開始ページ情報、及び装置情報を更新させる。それら磁気情報の更新は、磁気データ読取部５０ｂを用いて行われる。

サーバ２は、上記のように、通帳印字異常を検出したＡＴＭ３から受信する異常情報を用いて、その通帳印字異常を発生させた要因の推定を行い、必要に応じて、その推定結果を端末装置４に通知する。そのために、サーバ２は、図２に表すように、監視部２１、記憶部２２、解析部２３、及び通信部２４を備える。

監視部２１は、ネットワーク５を介した各ＡＴＭ３との通信を通して、必要な情報の取得、及び各ＡＴＭ３の状態の確認等を行う機能である。異常を検出したＡＴＭ３から送信される異常情報は、監視部２１によって受信され、記憶部２２上に構築された通知異常ＤＢ１４ａに格納される。

図１に表すハードディスク装置１４には、１４ａ〜１４ｃを付したＤＢ、或いはデータを表記している。それら１４ａ〜１４ｃは、記憶部２２にも表記している。これは、ハードディスク装置１４は少なくとも記憶部２２に含まれるからである。

この通知異常ＤＢ１４ａは、例えば一定期間内に受信した異常情報の格納用のＤＢである。図４に表すように、サーバ２が受信した各異常情報は、それぞれ１エントリ（レコード）に格納される。図４では、便宜的に、通帳印字異常を通知する異常情報のみを各エントリ（レコード）に表している。

本実施形態では、通帳印字異常を発生させた要因の候補として、今回、通帳が挿入されたＡＴＭ３（以降「現ＡＴＭ３」と表記）、その通帳への記帳を直前に行ったＡＴＭ３（以降「前ＡＴＭ３」と表記）、及びその通帳を想定している。通帳を要因の候補としているのは、通帳が搬送上、不適切な状態であった場合、通帳印字異常を発生させる可能性が高いからである。前ＡＴＭ３を要因の候補とすることにより、要因の推定はより適切に行えるようになる。

要因の推定（特定）では、何らかの具体的な対応が必要と考えるべき状態を想定している。これは、例え要因を推定したとしても、その推定結果を用いた対応をしないことを想定するのであれば、要因を推定する必要性は小さいからである。

各ＡＴＭ３の利用頻度、つまり単位時間当たりの利用者数は、ＡＴＭ３（ここでは店舗を含む）によって異なる。そのため、単位時間当たりに検出される通帳印字異常の数は、そのままＡＴＭ３の状態の推定に用いるのは望ましくない。このことから、抽出設定情報１４ｂは、ＡＴＭ３による単位時間当たりの利用者数の相違を排除する正規化のために用意している。

図５は、抽出設定情報の構成例を説明する図である。
本実施形態では、要因の推定は、通知異常ＤＢ１４ａから参照すべきエントリを抽出して行うようにしている。抽出設定情報１４ｂは、エントリの抽出の対象とする範囲をＡＴＭ３毎に制限するために用いられる。それにより、抽出設定情報１４ｂは、期間と、その期間が割り当てられた対象（ＡＴＭ３の装置情報、或いは通帳）の組み合わせを表す情報となっている。その期間とは、現在日時を基準に、エントリの抽出範囲の境界となる日時（最も古い日時）を表す情報であり、図５に表記の「α１」〜「α３」及び「β」は、それぞれ異なる数値を表している。

この抽出設定情報１４ｂにより、ＡＴＭ３を対象とする要因推定では、同じ所定回数の利用を想定し、その所定回数の利用時にＡＴＭ３から送信されたと推定されるエントリ分のみを通知異常ＤＢ１４ａからの抽出対象とさせるようにしている。この抽出設定情報１４ｂの記憶部２２（ハードディスク装置１４）への保存は、端末装置４を用いて行うことが可能である。

解析部２３は、通帳印字異常の通知を契機に、通知異常ＤＢ１４ａを参照し、要因を推定する機能である。要因の推定は、通帳とＡＴＭ３は別に行うようになっている。

ＡＴＭ３を対象にした要因の推定では、解析部２３は、通知された現装置情報、及び前装置情報を用いて抽出設定情報１４ｂを参照し、エントリの抽出対象範囲を確認する。その確認により、解析部２３は、現装置情報、及び前装置情報をそれぞれキーにして、通知異常ＤＢ１４ａから、キーとする装置情報が現装置情報、或いは前装置情報として格納されているエントリのなかで抽出対象範囲内となっているエントリのみを抽出する。図６は、そのようにして通知異常ＤＢ１４ａから抽出されたエントリ例を表している。

解析部２３は、エントリを抽出した後、通知された現装置情報、及び前装置情報毎に、その出現回数を計数する。それにより、本実施形態では、現装置情報、或いは前装置情報として装置情報が通知されたＡＴＭ３のなかで、その装置情報の出現回数が閾値とする所定値以上となっているＡＴＭ３を、通帳印字異常を発生させた要因と推定するようにしている。そのように推定しているのは、複数台のＡＴＭ３に同時に不具合が発生する可能性は比較的に低い、不具合が発生しているＡＴＭ３を別の不具合が発生していないＡＴＭ３を利用者が交互に利用することは少ない、等と考えられるからである。

通知された現装置情報、及び前装置情報の出現回数が共に所定値以上となる可能性がある。本実施形態では、その場合、通知された現装置情報、及び前装置情報の２つの装置情報が格納されたエントリの数、並びに、通知された現装置情報、及び前装置情報のうちの一方が現装置情報、及び前装置情報として格納されているエントリの数の計数を行う。

現装置情報、及び前装置情報として装置情報がエントリに格納されているＡＴＭ３は、不具合が発生している可能性が比較的に高いと考えられる。このことから、本実施形態では、現装置情報、及び前装置情報として同じ装置情報が格納されているエントリは、不具合が発生しているＡＴＭ３を推定するうえで有効なエントリと位置付けている。それにより、本実施形態では、装置情報が現装置情報、及び前装置情報として格納されているエントリの数が複数、存在するＡＴＭ３は、要因として推定するようにしている。

通知された現装置情報、及び前装置情報の２つの装置情報が格納されたエントリの数が多い場合、何れかの装置情報を有するＡＴＭ３にのみ不具合が存在していれば、不具合の発生していないＡＴＭ３の装置情報の出現回数も多くなり易い。しかし、現装置情報、及び前装置情報として同じ装置情報が格納されているエントリが存在しなければ、２台のＡＴＭ３のうちで不具合が発生しているＡＴＭ３の特定は困難である。このため、通知された現装置情報、及び前装置情報の２つの装置情報が格納されたエントリの数が多く、且つ現装置情報、及び前装置情報として同じ装置情報が格納されているエントリが存在しないような場合、２台のＡＴＭ３が要因と推定するようにしている。通知された現装置情報、及び前装置情報の２つの装置情報が格納されたエントリの数が多く、且つ通知された現装置情報、及び前装置情報の一方が格納されているエントリが存在する場合、１台のＡＴＭ３のみが要因と推定される。

また、通知された現装置情報、及び前装置情報の２つの装置情報が格納されたエントリの数が少ない場合（ここではエントリが存在しない場合も含む）、２台のＡＴＭ３にそれぞれ不具合が発生している可能性が高いと考えられる。そのため、この場合も、２台のＡＴＭ３が要因と推定するようにしている。

解析部２３は、上記のようにして、要因となっているＡＴＭ３の推定を高精度に行う。その要因の推定では、比較的に短い期間内に複数回、通帳印字異常を発生させていることを想定している。そのため、要因として推定されたＡＴＭ３は、メンテナンス（ここでは、動作確認等を含む）を行う必要性が高いと云える。このことから、要因として推定されたＡＴＭ３は、メンテナンスを行うべき対象として提示するのが望ましいものとなる。

本実施形態では、各ＡＴＭ３は、通帳印字異常の検出により、異なるＡＴＭ３の利用を促すメッセージを表示部３０ａに表示させるようにしている。そのため、多くの利用者は、通帳印字異常が検出された場合、２台以上の異なるＡＴＭ３を利用して、通帳を用いた取り引きを試みると考えられる。また、搬送上、不適切な状態となった通帳は、連続的に通帳印字異常が発生すると考えられる。このようなことから、同じ通帳で発生した通帳印字異常の最小発生間隔が設定時間より短かった場合、解析部２３は通帳を要因と推定する。

通帳を対象にした要因の推定では、解析部２３は、抽出設定情報１４ｂを参照し、通帳のエントリの抽出対象範囲を確認する。その確認結果を用いて、解析部２３は、口座情報をキーにして、通知異常ＤＢ１４ａから、キーとする口座情報が格納されているエントリの抽出を行う。図７は、そのようにして通知異常ＤＢ１４ａから抽出されたエントリ例を表している。

解析部２３は、エントリを抽出した後、発生日時情報が表す発生日時が前後する２つのエントリ毎に、発生間隔（＝前後する発生日時の間の間隔）を算出し、算出した発生間隔のなかで最小の発生間隔を最小発生間隔として抽出する。解析部２３は、そのようにして抽出される最小発生間隔を設定時間と比較することにより、通帳が要因か否かの判定を行う。

１台以上のＡＴＭ３を要因と推定した場合、解析部２３は、要因と推定されるＡＴＭ３のメンテナンス等の必要性の通知を通信部２４に指示する。その指示により、通信部２４は、端末装置４に対し、要因と推定されるＡＴＭ３の装置情報等を含むメッセージを送信し、そのＡＴＭ３へのメンテナンス等を促す。この結果、メンテナンス等を行うべきＡＴＭ３へのタイムリなメンテナンス等の対応が可能になる。

サーバ２が図１に表すような構成であった場合、監視部２１、及び通信部２４は、ＣＰＵ１１、メモリ１２、ＦＷＨ１３、ハードディスク装置１４、通信制御部１５、及びバス１６によって実現される。記憶部２２は、ハードディスク装置１４であるか、或いはハードディスク装置１４、メモリ１２、及びバス１６によって実現される。解析部２３は、ＣＰＵ１１、メモリ１２、ＦＷＨ１３、ハードディスク装置１４、及びバス１６によって実現される。

以降は、図８、及び図９にそれぞれフローチャートを表す処理について詳細に説明する。

図８は、通帳取引処理のフローチャートである。この通帳取引処理は、利用者が通帳を通帳挿入／排出口５０ａに挿入するか、或いは表示部３０ａを操作して、通帳を用いた取り引きを利用者が要求したことを契機に、その通帳を用いた各種取り引きを可能にするために実行される処理である。この通帳取引処理自体は、制御ユニット８０のＣＰＵ８０ａが、ハードディスク装置８０ｃ上の制御用プログラムを実行することで実現される。始めに図８を参照し、通帳を利用者が挿入した場合のＡＴＭ３の動作について詳細に説明する。

先ず、ＣＰＵ８０ａは、通帳挿入／排出口５０ａに設けられた通帳検出用のセンサが通帳を検出するのを待って、通帳の搬送を通帳処理ユニット５０に行わせる（Ｓ１１）。ＣＰＵ８０ａは、通帳の搬送を行わせている間に、通帳のＭＳに記録されている磁気情報の読み取り（Ｓ１２）、通帳画像（通帳イメージ）の読み取り、その文字認識を通帳処理ユニット５０に行わせる（Ｓ１３）。読み取られた磁気情報、通帳画像上の文字認識結果（印字開始行、及び印字開始行の直前の行での印字の有無を含む）は通帳処理ユニット５０から制御ユニット８０のＣＰＵ８０ａに出力される。

次に、ＣＰＵ８０ａは、通帳画像上の文字認識結果から、印字開始行のチェック結果がＮＧ、つまり印字開始行に印字が行われているか否か、及び印字開始行の直前の行に印字が行われているか否かを判定する（Ｓ１４）。印字開始行と認識する位置に何らかの印字が行われていた場合、或いは印字開始行と認識する位置の直前の行に何らかの印字が行われていない場合、Ｓ１４の判定はＹＥＳとなってＳ１９に移行する。印字開始行と認識する位置に印字が確認できない場合、及び印字開始行と認識する位置の直前の行に印字が確認された場合、Ｓ１４の判定はＮＯとなってＳ１５に移行する。

Ｓ１５では、ＣＰＵ８０ａは、表示部３０ａへの利用者の操作に応じた取り引きを可能にさせる取引処理を実行する。その後、ＣＰＵ８０ａは、取り引きが正常終了したか否か判定する（Ｓ１６）。通帳への記帳を含む手続きが終了した場合、Ｓ１６の判定はＹＥＳとなってＳ１７に移行する。通帳への記帳を行うことなく手続きが終了した場合、Ｓ１６の判定はＮＯとなってＳ１８に移行する。

Ｓ１７では、ＣＰＵ８０ａは、通帳を通帳挿入／排出口５０ａに向けて搬送させながら、通帳のＭＳに記録されている磁気情報の更新を行う。その更新により、印字開始行情報、及び印字開始ページ情報は記帳結果に応じて更新され、装置情報はハードディスク装置８０ｃに保存されている装置情報に更新される。

磁気情報を更新したＣＰＵ８０ａは、通帳を通帳挿入／排出口５０ａから排出させるまで搬送させる（Ｓ１８）。その通帳が検出されなくなった後、この通帳取引処理が終了する。

上記Ｓ１４の判定はＹＥＳとなって移行するＳ１９では、今回、挿入された通帳が直前に挿入された通帳と同じか否か判定する。通帳印字異常の検出により返却された通帳を再度、利用者が挿入した場合、２つの通帳は口座情報が一致する。そのため、Ｓ１９の判定はＹＥＳとなり、上記Ｓ１８に移行する。一方、２つの通帳の口座情報が一致しない場合、Ｓ１９の判定はＮＯとなってＳ２０に移行する。

Ｓ２０では、ＣＰＵ８０ａは、通帳印字異常が発生した旨を通知するための異常情報をサーバ２宛に送信させる。その異常情報は、エラー種別情報、発生日時情報、口座情報、現装置情報、及び前装置情報を含む。そのような異常情報を送信させた後、通帳取引処理が終了する。

このようにして、本実施形態では、通帳印字異常の検出により返却された通帳を再度、利用者が挿入した場合、通帳印字異常が検出されても異常情報は送信させないようにしている。これは、通帳自体、及び通帳が挿入されたＡＴＭ３の少なくとも一方が通帳印字異常の要因となっている場合、通帳を挿入する度に、通帳印字異常が検出される可能性が考えられるからである。

同じ通帳が同じＡＴＭ３に挿入される度に、通帳印字異常が検出され、異常情報が送信される場合、２回目以降に送信される異常情報は、要因の推定には不要である。最小発生間隔はより短くさせやすく、装置情報の出現回数は不要に多くさせる。それにより、２回目以降に送信される異常情報は、要因の推定精度を低下させる方向に作用する。このようなことから、本実施形態では、２回目以降の異常情報の送信は回避させるようにしている。

図９は、要因判定処理のフローチャートである。この要因判定処理は、通帳印字異常の発生を通知する異常情報の受信を契機に、その通帳印字異常を発生させた要因を特定（推定）するために実行される処理である。図２に表す解析部２３は、ＣＰＵ１１が、この要因判定処理を実行することで実現される。この要因判定処理自体は、ＣＰＵ１１が、ハードディスク装置１４上の解析ソフト１４ｃを実行することで実現される。

先ず、ＣＰＵ１１は、受信した異常情報により通知された現装置情報、及び前装置情報を用いて抽出設定情報１４ｂを参照して、通知異常ＤＢ１４ａからエントリの抽出対象範囲を確認する。その確認結果を用いて、ＣＰＵ１１は、通知された口座情報が格納されたエントリ、及び現装置情報、或いは前装置情報が格納されたエントリを通知異常ＤＢ１４ａから抽出する（以上Ｓ３１）。

次に、ＣＰＵ１１は、口座情報をキーにして抽出されたエントリを参照し、最小発生間隔を算出する（Ｓ３２）。続いて、ＣＰＵ１１は、最小発生間隔が設定時間より短いか否か判定する（Ｓ３３）。通帳印字異常が検出された後、通帳を別のＡＴＭ３に挿入しても通帳印字異常が検出されたような場合、最小発生間隔は設定時間よりも短くなる。そのため、Ｓ３３の判定はＹＥＳとなってＳ３４に移行する。一方、別のＡＴＭ３に通帳を挿入しても通帳印字異常が検出されなかったような場合、最小発生間隔は設定時間以上となる。そのため、Ｓ３３の判定はＮＯとなってＳ３４に移行する。

Ｓ３４では、ＣＰＵ１１は、通帳を、通知された通帳印字異常を発生させた要因と推定する。

この推定結果は、通帳印字異常を検出したＡＴＭ３に、通帳の再発行、或いは通帳の状態の確認を利用者に促すメッセージを表示させる契機としても良い。そのようなメッセージを提示させることにより、利用者がＡＴＭ３をより快適に利用できる環境を実現させることができる。

次に、ＣＰＵ１１は、通知された現装置情報、或いは前装置情報をキーにして抽出されたエントリを参照し、現装置情報、及び前装置情報毎に、その出現回数を計数する（Ｓ３５）。その計数を行った後、ＣＰＵ１１は、所定値以上の出現回数があるか否か判定する（Ｓ３６）。通知された現装置情報、及び前装置情報の２つの出現回数のうちの少なくとも１つが所定値以上であった場合、Ｓ３６の判定はＹＥＳとなってＳ３７に移行する。２つの出現回数が共に所定値未満であった場合、Ｓ３６の判定はＮＯとなり、ここで要因判定処理が終了する。

Ｓ３７では、ＣＰＵ１１は、所定値以上となった出現回数が２であるか否か判定する。２つの出現回数が共に所定値以上であった場合、Ｓ３７の判定はＹＥＳとなってＳ３８に移行する。２つの出現回数のうちの一方のみ、所定値以上であった場合、Ｓ３７の判定はＮＯとなってＳ４２に移行する。通知された現装置情報と前装置情報が同じであっても、Ｓ３７での判定はＮＯとなる。

Ｓ３８では、ＣＰＵ１１は、現装置情報、及び前装置情報として通知された２つの装置情報が格納されたエントリ数、及び現装置情報、或いは前装置情報として通知された１つの装置情報のみが格納されたエントリ数をそれぞれ計数する。次に、ＣＰＵ１１は、それぞれ計数したエントリ数から、現装置情報、及び前装置情報がそれぞれ割り当てられた２台のＡＴＭ３のなかの一方のみが要因である可能性が高いか否か判定する（Ｓ３９）。上記のように、現装置情報、及び前装置情報として通知された２つの装置情報が格納されたエントリ数が少ない場合、２台のＡＴＭ３が共に要因である可能性は高い。また、現装置情報、或いは前装置情報として通知された１つの装置情報のみが格納されたエントリ数が共に複数、存在するような場合も、２台のＡＴＭ３が共に要因である可能性は高い。そのように、２台のＡＴＭ３が共に要因である可能性が高い場合、Ｓ３９の判定はＮＯとなってＳ４０に移行する。

一方、現装置情報、及び前装置情報として通知された２つの装置情報が格納されたエントリ数が多く、且つ現装置情報、或いは前装置情報として通知された１つの装置情報のみが格納されたエントリ数のうちの１つのみが複数、存在するような場合、１台のＡＴＭ３のみが要因である可能性は高い。このため、そのような場合、Ｓ３９の判定はＹＥＳとなってＳ４２に移行する。

Ｓ４０では、ＣＰＵ１１は、現装置情報、及び前装置情報として装置情報が通知された２台のＡＴＭ３を共に要因として推定する。ＣＰＵ１１は、要因として推定した２台のＡＴＭ３を端末装置４宛に通知する（Ｓ４１）。その後、この要因判定処理が終了する。

一方、Ｓ３７でのＮＯの判定、或いはＳ３９でのＹＥＳの判定により移行するＳ４２では、ＣＰＵ１１は、装置情報の出現回数が所定値以上となった１台のＡＴＭ３、或いは計数したエントリ数から特定した１台のＡＴＭ３を要因として推定する。その後はＳ４１に移行し、ＣＰＵ１１は、要因として推定した１台のＡＴＭ３を端末装置４に通知する。

なお、本実施形態では、過去の要因の推定結果を反映させた要因の推定を行っていないが、要因の推定は、過去の要因の推定結果を反映させる形で行うようにしても良い。或るＡＴＭ３に不具合が存在している場合、そのＡＴＭ３が記帳を行った通帳が次に挿入されるＡＴＭ３が通帳印字異常を検出する可能性は高い。そのため、或るＡＴＭ３に存在する不具合により、実際には不具合が存在しない別のＡＴＭ３の装置情報が異常情報の形でサーバ２に通知される頻度が高くなる可能性がある。実際には不具合が存在しなくとも、装置情報が多くサーバ２に通知されるＡＴＭ３は、要因として推定される可能性が高くなる。このようなことから、要因として推定されたＡＴＭ３の装置情報が格納されているエントリを抽出対象から除外するようにしても良い。そのような除外を行った場合、メンテナンス等が必要なＡＴＭ３をより高精度に推定できるようになる。

故障と見なすまでの異常の発生頻度は、時間の経過に従って高くなる傾向がある。このことから、出現回数の計数では、現在日時と発生日時の間隔に応じた重みを設定し、設定した重みを出現回数の計数に反映させるようにしても良い。このことも含め、要因の推定方法も様々な変形を行うことができる。

１ 監視システム
２ サーバ
３ 自動取引装置（ＡＴＭ）
４ 端末装置
５ ネットワーク
１１ ＣＰＵ
１２ メモリ
１３ ＦＷＨ
１４ ハードディスク装置
１４ａ 通知異常ＤＢ
１４ｂ 抽出設定情報
１４ｃ 解析ソフト

Claims (5)

1. 利用者が挿入した通帳の画像を読み取り、該読み取った画像から、前記通帳への印字である記帳を中止すべき通帳異常を検出する複数台の自動取引装置と、各自動取引装置が検出した前記通帳異常がネットワークを介して通知される監視装置とを備え、
   前記監視装置は、
   前記通帳異常を検出した自動取引装置である第１の自動取引装置から、前記通帳を特定可能な第１の識別情報、前記第１の自動取引装置を特定可能な第２の識別情報、及び前記通帳への記帳を直前に行った自動取引装置である第２の自動取引装置を特定可能な第３の識別情報を異常通知情報として受信する送受信部と、
   前記送受信部が受信した異常通知情報を、前記通帳異常が検出された日時を表す日時情報と共に保存する記憶部と、
   前記記憶部に保存された異常通知情報、及び日時情報を用いて、前記第２の自動取引装置が前記第１の自動取引装置に前記通帳異常を検出させた要因の候補として要因推定を行う解析部と、を有する、
   ことを特徴とする監視システム。
2. 前記解析部は、前記異常通知情報を前記第１の自動取引装置から受信した場合に、当該異常通知情報に含まれる前記第１の識別情報、前記第２の識別情報、及び前記第３の識別情報をそれぞれキーにして、前記記憶部から該当する異常通知情報を抽出し、前記通帳、前記第１の自動取引装置、及び前記第２の自動取引装置のなかから、前記第１の自動取引装置に前記通帳異常を発生させた要因を推定する、
   ことを特徴とする請求項１記載の監視システム。
3. 前記解析部は、前記通帳毎、前記第１の自動取引装置毎、及び前記第２の自動取引装置毎に、前記記憶部から異常通知情報を抽出する対象期間を制限し、前記異常通知情報の抽出を行う、
   ことを特徴とする請求項２記載の監視システム。
4. ネットワークを介して接続された複数台の自動取引装置のなかで、利用者が挿入した通帳の画像を読み取り、該読み取った画像から、前記通帳への印字である記帳を中止すべき通帳異常を検出した自動取引装置である第１の自動取引装置から、前記通帳を特定可能な第１の識別情報、前記第１の自動取引装置を特定可能な第２の識別情報、及び前記通帳への記帳を直前に行った自動取引装置である第２の自動取引装置を特定可能な第３の識別情報を異常通知情報として受信する送受信部と、
   前記送受信部が受信した異常通知情報を、前記通帳異常が検出された日時を表す日時情報と共に保存する記憶部と、
   前記記憶部に保存された異常通知情報、及び日時情報を用いて、前記第２の自動取引装置が前記第１の自動取引装置に前記通帳異常を検出させた要因の候補として要因推定を行う解析部と、
   を有することを特徴とする監視装置。
5. ネットワークを介して複数台の自動取引装置と接続させた情報処理装置に、
   前記複数台の自動取引装置のなかで、利用者が挿入した通帳の画像を読み取り、該読み取った画像から、前記通帳への印字である記帳を中止すべき通帳異常を検出した自動取引装置である第１の自動取引装置から、前記通帳を特定可能な第１の識別情報、前記第１の自動取引装置を特定可能な第２の識別情報、及び前記通帳への記帳を直前に行った自動取引装置である第２の自動取引装置を特定可能な第３の識別情報を異常通知情報として受信させ、
   受信された前記異常通知情報を、前記通帳異常が検出された日時を表す日時情報と共に記憶部に保存させ、
   前記記憶部に保存された異常通知情報、及び日時情報を用いて、前記第２の自動取引装置が前記第１の自動取引装置に前記通帳異常を検出させた要因の候補として要因推定を行わせる、
   処理を実行させる監視プログラム。

Images