JP5886055B2 - 自動取引装置の管理システム、サーバ装置及び自動取引装置の管理方法 - Google Patents

Description

本発明は、利用者により挿入された媒体を用いて取引を行う複数の自動取引装置と、該複数の自動取引装置とネットワークを介して接続され、該複数の自動取引装置を管理するサーバ装置とを有する管理システム、サーバ装置及び管理方法に関する。

金融機関等で自動取引に使用される自動取引装置（ＡＴＭ、Automated Teller Machine）等では、取引においてカードや通帳等の媒体を取り扱う。自動取引装置は、カードや通帳等の磁気データ等を読み取って、口座番号等の取引に必要な情報を取得する。自動取引装置が磁気データ等の読み取りに失敗した場合は、取引処理を継続することができないため、従来は、媒体を装置外に排出して顧客等に返却し、窓口へ誘導するのが通常である。

媒体から磁気データ等のデータ読み取りに失敗する要因には、媒体側に問題がある場合と、自動取引装置側に問題がある場合とがある。媒体側に問題があり、媒体の変形や磁気データの破損等によってデータの読み取りに失敗していることも多いが、磁気読み取りユニット自体の故障によることもある。しかし、現状では、要因の切り分けができず、一律に媒体要因として上記のように処理されている。

自動取引装置の異常を検出する技術に関しては、例えば、現物処理機の処理中に異常が発生すると、運転リトライを実行するとともに、異常発生回数等を検出して、検出した異常発生回数等に応じて警告を発する技術について開示されている（例えば、特許文献１）。

現金自動取引装置等の自動機について、取引を含む稼動時に発生した障害情報等をロギングデータとして保存しておき、後日保存データを読み出すときに障害発生原因の分析や障害発生の予測を行う技術についても開示されている（例えば、特許文献２）。

また、現金自動取引装置が、磁気カードに記録される読み取り異常に伴う再読み取り実行回数よりリードエラー連続回数や通算リードリトライ回数等をカウントし、磁気カードの寿命の予告や磁気カード制御機構の異常の警告を行う技術についても開示されている（例えば、特許文献３）。

特開平７−２６２２８８号公報 特開２００２−２６００６９号公報 特開平８−１６１４４８号公報

前述のとおり、従来は、データの読み取りに失敗した場合にその要因の切り分けができないため、装置（ハード）側に問題がある場合であっても一律に媒体要因として処理を行っていた。媒体を返却した場合には、検出した異常に関する情報は、自動取引装置には残らない。このため、自動取引装置側に問題があってもそのまま稼動され続けてしまうこととなり、その結果、装置側の異常の発見が遅れてしまうという問題がある。

上記の公知の技術によれば、媒体を受け付けた各装置において異常を検出して警告等の処理を実行している。例えば、顧客によっては、保有する媒体の取り扱い方法により、媒体を変形させる、あるいは磁気データを破損させる等、媒体側の問題を発生させ易い、ということがある。しかし、自動取引装置のそれぞれが情報の収集や分析を行う構成では、利用者が次に異なる装置を利用した場合には、異常を検出することができない。このように、従来技術によれば、効率的に異常を検出することができないという問題もある。

媒体の読み取り異常が、自動取引装置側の要因によるものであるのか、あるいは媒体側の要因によるものであるのかを効率的に検出できることが望ましい。
本発明は、自動取引装置における媒体の読み取り異常の要因をより効率的に検出することのできる技術を提供することを目的とする。

本発明の一態様に係るサーバ装置によれば、利用者により挿入された媒体を用いて取引を行う複数の自動取引装置とネットワークを介して接続され、該複数の自動取引装置を管理するサーバ装置であって、前記自動取引装置に挿入された媒体の読み取り異常が検出された場合には、該自動取引装置において取得した、該媒体の口座番号及び該媒体の種類と該自動取引装置を識別する装置情報とを互いに関連付けて蓄積していく蓄積部と、前記蓄積部に蓄積されている情報を参照して、新たに検出された媒体の読み取り異常が、前記自動取引装置あるいは該媒体のいずれによるものであるかを判定する判定部と、を備えることを特徴とする。

また、本発明の一態様に係る管理システムによれば、利用者により挿入された媒体を用いて取引を行う複数の自動取引装置と、該複数の自動取引装置とネットワークを介して接続され、該複数の自動取引装置を管理するサーバ装置とを有する管理システムであって、前記自動取引装置に挿入された前記媒体の読み取り異常を検出する異常検出部と、前記自動取引装置に挿入された媒体の口座番号及び該媒体の種類を取得する第１の取得部と、前記媒体の挿入された自動取引装置を識別する装置情報を取得する第２の取得部と、前記異常検出部において媒体の読み取り異常が検出された場合には、前記第１及び第２の取得部がそれぞれ取得した情報を互いに関連付けて蓄積していく蓄積部と、前記蓄積部に蓄積されている情報を参照して、前記異常検出部において新たに検出された媒体の読み取り異常が、前記自動取引装置あるいは該媒体のいずれによるものであるかを判定する判定部と、前記判定部の判定結果に応じて、前記媒体の読み取り異常の発生した前記自動取引装置を制御する異常制御処理部と、を備えることを特徴とする。

また、本発明の一態様に係る自動取引装置の管理方法によれば、利用者により挿入された媒体を用いて取引を行う複数の自動取引装置と、該複数の自動取引装置とネットワークを介して接続され、該複数の自動取引装置を管理するサーバ装置とを有する管理システムにおける自動取引装置の管理方法であって、前記自動取引装置に挿入された媒体の口座番号及び該媒体の種類を取得し、前記媒体の挿入された自動取引装置を識別する装置情報を取得し、前記媒体の読み取り異常が検出された場合には、前記口座番号及び媒体の種類と、前記装置情報とを互いに関連付けて蓄積していき、前記蓄積されている情報を参照して、新たに検出された媒体の読み取り異常が、前記自動取引装置あるいは該媒体のいずれによるものであるかを判定し、前記判定結果に応じて、前記媒体の読み取り異常の発生した前記自動取引装置を制御する、ことを特徴とする。

本発明によれば、自動取引装置における媒体の読み取り異常の要因をより効率的に検出することが可能となる。

第１の実施形態に係る管理システムの構成図である。 ＡＴＭの斜視図である。 ＡＴＭのハードウェア構成例を示す図である。 サーバのハードウェア構成例を示す図である。 第１の実施形態に係る管理システムのブロック図である データベースに蓄積される異常発生情報のデータ構造例を示す図である。 第１の実施形態に係るＡＴＭの制御ユニットによる取引処理を示したフローチャート（その１）である。 第１の実施形態に係るＡＴＭの制御ユニットによる取引処理を示したフローチャート（その２）である。 サーバの判定部における媒体読み取り異常の要因判定処理を示したフローチャートである。 サーバの要因判定処理において抽出されるデータを説明する図である。 データベースを更新後の異常発生情報のデータ構造例を示す図である。 装置保守後にデータベースを更新した後に発生した媒体読み取り異常についての要因判定処理について説明する図である。 第２の実施形態に係る管理システムのブロック図である。 第２の実施形態に係るＡＴＭの制御ユニットによる取引処理を示したフローチャート（その１）である。 第２の実施形態に係るＡＴＭの制御ユニットによる取引処理を示したフローチャート（その２）である。 第２の実施形態に係るサーバによるデータベースの更新方法を説明する図である。 第２の実施形態に係る要因判定処理による効果を説明する図である。

以下、本発明の実施の形態について、図面を参照して詳細に説明する。
＜第１の実施形態＞
図１は、本実施形態に係る管理システムの構成図である。図１に示す管理システム１は、サーバ装置（以下サーバ）２と、複数の自動取引装置（以下ＡＴＭ）１０とを有し、サーバ２とＡＴＭ１０とは、互いにＬＡＮ（Local Area Network）等のネットワーク４を介して接続されている。

サーバ２は、システム内のＡＴＭ１０を管理するために設けられたサーバ装置である。
ＡＴＭ１０は、金融機関の店舗内外に設けられ、利用者（顧客）の操作にしたがって、入出金や振込等の各種の取引を行う。ＡＴＭ１０は、各種の取引において、利用者により挿入された通帳やカード等の媒体を取り扱う。

ＡＴＭ１０は、一般的には複数台が設けられ、図１においては、Ｎ台のＡＴＭ１０ａ〜１０Ｎがネットワーク４を介してサーバ２と接続される構成を示す。図１においては、各ＡＴＭ１０を区別するために、ａ、ｂ、…Ｎ−１、Ｎ等の符号を付している。

各ＡＴＭ１０は、取引において挿入された通帳やカード等の媒体の読み取り異常が発生した場合には、発生した媒体読み取り異常に関する情報をサーバ２に送信する。
サーバ２は、ネットワーク４を介して、ＡＴＭ１０において発生した媒体読み取り異常に関する情報を受信すると、データベース（ＤＢ）２１に、受信した情報を媒体データ読取異常発生情報として蓄積していく。サーバ２は、システム内のＡＴＭ１０から受信して自装置に集約させた媒体データ読取異常発生情報を利用して、ＡＴＭ１０で新たに発生した媒体の読み取り異常の要因がＡＴＭ１０または媒体のいずれにあるかを判定し、ＡＴＭ１０に通知する。

ＡＴＭ１０は、サーバ２から通知された要因に応じた制御処理を行う。
なお、サーバ２については、ＡＴＭ１０のジャーナルを電子的に集中管理するための既存のサーバを利用してもよいし、新たに構築してもよい。

また、図１においては、本実施形態に係る異常検出時の処理に関する構成のみを示しているため、ＡＴＭ１０のそれぞれにおける取引を管理するホストコンピュータについては記載を省略している。

本実施形態に係る管理システム１を構成するＡＴＭ１０及びサーバ２の構成について、図２〜図４を参照して説明する。
図２は、ＡＴＭ１０の斜視図である。図２に示すＡＴＭ１０は、前面に、カード挿入／排出口４０ａ、通帳挿入／排出口５０ａ、硬貨入出金部６０ａ、紙幣入出金部７０ａを有する。また、ＡＴＭ１０は、利用者からの操作入力や利用者への表示を行うための表示部３０ａを有する。

図３は、図２のＡＴＭ１０のハードウェア構成例を示す図である。
図３に示すとおり、ＡＴＭ１０は、制御ユニット２０、表示ユニット３０、カード処理ユニット４０、通帳処理ユニット５０、硬貨処理ユニット６０及び紙幣処理ユニット７０を有する。

表示ユニット３０は、図２の表示部３０ａを有し、取引に関する画面やメッセージ等を表示して利用者からの操作入力を受け付ける。表示部３０ａは、ＡＴＭ１０の処理に応じ画面情報に基づいて画面を表示する。表示部３０ａとしては、例えば、ＬＣＤ（Liquid Crystal Display）を用いる。

硬貨処理ユニット６０及び紙幣処理ユニット７０は、それぞれ図２の硬貨入出金部６０ａ及び紙幣入出金部７０ａから挿入された硬貨及び紙幣を受け入れ、硬貨及び紙幣を計数したり、利用者からの所定の実行指示に応じて所定数の硬貨及び紙幣を放出したりする。

カード処理ユニット４０は、図２のカード挿入／排出口４０ａのほか、磁気データ読取部４０ｂ、エンボスデータ読取部４０ｃ及び文字認識部４０ｄを有する。カード処理ユニット４０は、利用者がカード挿入／排出口４０ａから挿入したＩＣカードや磁気カードを受け付けてカードに取引処理結果等を記録したり、処理結果の記録が完了したカードをカード挿入／排出口４０ａから返却したりする。

カード処理ユニット４０の磁気データ読取部４０ｂ、エンボスデータ読取部４０ｃ及び文字認識部４０ｄは、カード挿入／排出口４０ａから挿入されたカードについて読み取り異常が発生した場合に、口座番号をカードから取得する。具体的には、磁気データ読取部４０ｂは、ＩＣカードについて読み取り異常が発生した場合に、カードの磁気データから口座番号を取得する。エンボスデータ読取部４０ｃ及び文字認識部４０ｄは、磁気カードについて読み取り異常が発生した場合に、カードのエンボス加工から文字認識を行って、口座番号を取得する。カード処理ユニット４０は、取得した口座番号と、読み取りに失敗したデータの種類（カードの磁気データ／ＩＣカードのデータ等）とを制御ユニット２０に渡す。

通帳処理ユニット５０は、図２の通帳挿入／排出口５０ａのほか、磁気データ読取部５０ｂ、光学データ読取部５０ｃ及び文字認識部５０ｄを有する。通帳処理ユニット５０は、利用者が通帳挿入／排出口５０ａから挿入した通帳を受け付けて所定の位置まで搬送し、取引処理の内容を記帳に記録したり、記録が完了した通帳を通帳挿入／排出口５０ａから返却したりする。

通帳処理ユニット５０の磁気データ読取部５０ｂ、光学データ読取部５０ｃ及び文字認識部５０ｄは、通帳挿入／排出口５０ａから挿入された通帳について読み取り異常が発生した場合に、口座番号を通帳から取得する。具体的には、磁気データ読取部５０ｂは、通帳のイメージデータについて読み取り異常が発生した場合に、通帳の磁気データから口座情報を取得する。光学データ読取部５０ｃ及び文字認識部５０ｄは、通帳の磁気データについて読み取り異常が発生した場合に、イメージＯＣＲ（Optical Character Reader）で文字認識を行って、口座番号を取得する。通帳処理ユニット５０は、取得した口座番号と、読み取りに失敗したデータの種類（通帳の磁気データ／通帳のイメージデータ等）とを制御ユニット２０に渡す。

制御ユニット２０は、ＣＰＵ２０ａ、ＲＡＭ（Random Access Memory）２０ｂ、ＨＤＤ（Hard Disk Drive）２０ｃ、グラフィックインタフェース２０ｄ、通信制御部２０ｅ及び入出力インタフェース２０ｆを有し、各部はバス２０ｇにより相互に接続されている。制御ユニット２０は、ＡＴＭ１０で行われる取引処理等の所定の処理や、上述のＡＴＭ１０の各ユニットの制御を実行する。

ＣＰＵ２０ａは、ＨＤＤ２０ｃ等の記憶媒体に記憶された各種プログラムを実行することにより、ＡＴＭ１０全体を統括的に制御する。
ＲＡＭ２０ｂは、ＣＰＵ２０ａに実行させるＯＳ（Operating System）並びにプログラムの少なくとも一部を一時的に格納する。また、ＲＡＭ２０ｂは、ＣＰＵ２０ａによる処理に必要な各種データを格納し、例えば、ＡＴＭ１０を識別する装置番号等の情報を格納する。

ＨＤＤ２０ｃは、ＡＴＭ１０上のＯＳ及びアプリケーションのプログラムを格納する。また、ＨＤＤ２０ｃは、ＣＰＵ２０ａによる処理に必要な各種データを格納する。
グラフィックインタフェース２０ｄは、表示ユニット３０が接続され、ＣＰＵ２０ａからの指示にしたがって、画面を表示ユニット３０の表示部３０ａに表示させる。また、グラフィックインタフェース２０ｄは、表示ユニット３０の利用者による入力を検知する入力検知部（図３においては不図示）で検知された操作入力に応じた情報を取得する。

通信制御部２０ｅは、様々な場所に設置したＡＴＭ１０の管理を行うサーバ２や取引処理を管理するホストコンピュータ（図１等においては不図示）とネットワーク４を介して接続される。通信制御部２０ｅは、サーバ２等との間での電文の送受等を制御する。

入出力インタフェース２０ｆは、上記のカード処理ユニット４０、通帳処理ユニット５０、硬貨処理ユニット６０及び紙幣処理ユニット７０と相互に通信可能に接続されている。入出力インタフェース２０ｆは、これら各ユニットとの間でバス２０ｇを介して相互に信号の送受信を行う。

このように、図３に示すＡＴＭ１０の制御ユニット２０によれば、通常の取引処理に関する制御処理に加えて、通帳やカード等の媒体の読み取りが正常になされなかった場合には、サーバ２から通知された要因判定結果に応じた制御を行う。

図４は、サーバ２のハードウェア構成例を示す図である。
図４に示すとおり、サーバ２の制御部８０は、ＣＰＵ８０ａ、ＲＡＭ８０ｂ、ＨＤＤ８０ｃ及び通信制御部８０ｅを有する。

ＣＰＵ８０ａは、ＨＤＤ８０ｃ等の記憶媒体に記憶された各種プログラムを実行することにより、サーバ２全体を統括的に制御する。
ＲＡＭ８０ｂは、ＣＰＵ８０ａに実行させるＯＳ並びにプログラムの少なくとも一部を一時的に格納する。また、ＲＡＭ８０ｂは、ＣＰＵ８０ａによる処理に必要な各種データを格納する。

ＨＤＤ８０ｃは、サーバ２上のＯＳ及びアプリケーションのプログラムを格納する。また、ＨＤＤ８０ｃは、ＣＰＵ８０ａによる処理に必要な各種データを格納し、例えば、図１の媒体データ読取異常発生情報を格納する。

上記の構成のサーバ２及びＡＴＭ１０からなる管理システム１が、ＡＴＭ１０において発生した媒体の読み取り異常が発生した場合にどのように要因を判定し、要因に応じた制御を行うかについて、図５〜図１１を参照して説明する。

図５は、本実施形態に係る管理システム１のブロック図である。図５を参照して、ＡＴＭ１０において媒体の読み取り異常が発生した場合において、本実施形態に係る管理システム１の各構成の動作について説明する。

ＡＴＭ１０は、異常検出部１１、取得部１２及び異常制御処理部１５を有する。異常検出部１１、取得部１２及び異常制御処理部１５は、図３の制御ユニット２０のＣＰＵ２０ａにより実現される。

異常検出部１１は、図３のカード処理ユニット４０や通帳処理ユニット５０からの通知により、カード挿入／排出口４０ａや通帳挿入／排出口５０ａから挿入されたカードや通帳等の媒体の読み取り異常を検出する。

取得部１２は、第１の取得部１３及び第２の取得部１４を備え、異常検出部１１にて媒体の読み取り異常が検出された場合は、要因判定に必要な情報を取得する。第１の取得部１３は、媒体から口座情報や読み取りに失敗したデータの種類を取得し、第２の取得部１４は、図３のＲＡＭ２０ｂ等の記憶媒体から、ＡＴＭ１０を識別する装置番号を取得する。

サーバ２は、データベース（ＤＢ）２１及び判定部２２を有する。ＤＢ２１は、例えば図４のＨＤＤ８０ｃにより実現され、判定部２２は、図４のＣＰＵ８０ａにより実現される。

ＤＢ２１は、ネットワーク４を介してＡＴＭ１０から受信した媒体の読み取り異常に関する情報を蓄積していく。
判定部２２は、ＡＴＭ１０から新たに媒体の読み取り異常に関する情報を受信すると、ＤＢ２１に蓄積されている情報を参照して、新たに発生した媒体の読み取り異常の要因を判定する。要因判定処理の詳細については後述する。サーバ２は、判定結果をＡＴＭ１０に通知する。

ＡＴＭ１０の異常制御処理部１５は、サーバ２から通知されて判定結果に基づき、要因に応じた制御処理を実行する。
このように、本実施形態に係る管理システム１では、ＡＴＭ１０において媒体の読み取り異常が検出されると、口座情報や読み取りに失敗したデータの種類、及びＡＴＭ１０の装置番号を取得して、電文に含めてサーバ２に送信する。サーバ２は、受信した情報のうち、利用者の保有する口座や媒体に関する情報（口座番号及びデータの種類）と、ＡＴｍ１０を識別する情報（装置番号）とを互いに関連付けて蓄積していく。サーバ２は、ＡＴＭ１０から新たに口座情報やデータの種類並びに装置番号を受信すると、ＤＢ２１に蓄積されている情報、すなわち、過去に発生した媒体読み取り異常に関する情報より、新たに検出された媒体の読み取り異常が媒体要因であるか、ＡＴＭ１０が要因であるかを判定する。ＤＢ２１に蓄積する情報を、以下の説明においては、媒体データ読み取り異常発生情報、あるいは省略して異常発生情報とする。

図６は、ＤＢ２１に蓄積される異常発生情報のデータ構造例を示す図である。図６に示すとおり、異常発生情報は、発生日時、口座番号、装置番号及び対象データを有する。
異常発生情報のうち、口座番号、装置番号については上記のとおりであり、対象データとは、ＡＴＭ１０において読み取りを正常に行うことのできなかったデータの種類を表す。図３を参照して説明したとおり、例えばＩＣカードのＩＣチップから口座番号等の読み出しに失敗した場合は、磁気データやカードのエンボス加工等から口座番号を取得する。他の手段により口座番号を取得できた場合であっても、本来口座番号等を読み出すべきＩＣチップについては正常に読み取りが行えていないため、この場合は「ＩＣカードデータ」がデータの種類に相当し、対象データにより、媒体の種類が特定される。発生日時は、例えば、ＡＴＭ１０から口座番号やデータの種類、装置番号とともに送信される。発生日時については、サーバ２がＡＴＭ１０から蓄積すべき情報を受信したタイミングで取得する構成とすることもできる。

管理システム１は、ＡＴＭ１０の通常の取引処理において媒体の読み取り異常が発生した場合に、過去に蓄積しておいた情報を参照して、新たに発生した読み取り異常の要因を判断し、これに応じた制御を行う。以下に、ＡＴＭ１０及びサーバ２が実行する処理の流れについて説明する。

図７Ａ及び図７Ｂは、ＡＴＭ１０の制御ユニット２０による取引処理を示したフローチャートである。ＡＴＭ１０の制御ユニット２０は、図２の表示部３０ａ等を利用者が操作して所定の取引を開始したことを契機として、図７Ａ及び図７Ｂに示す処理を開始する。

まず、ステップＳ１で、制御ユニット２０は、カード処理ユニット４０や通帳処理ユニット５０において媒体を受け付けたことを認識すると、ステップＳ２で、カード処理ユニット４０や通帳処理ユニット５０において媒体から読み取ったデータを取得する。以下の説明においては、ＡＴＭ１０に挿入された媒体の種類や読み取りに失敗したデータの種類によらずに共通する動作について説明するため、媒体を受け付ける構成を「カード処理ユニット４０等」とする。

ステップＳ３で、制御ユニット２０（異常検出部１１）は、カード処理ユニット４０等から取得したデータを参照し、媒体データを正常に読み取ることができたか否かを判定する。媒体データとは、口座番号等の取引処理に必要な情報をいう。媒体データの読み取り結果が「正常」である場合は、ステップＳ４へと処理を移行させ、制御ユニット２０は、所定の取引処理を実行し、処理を終了する。

一方、ステップＳ３の判定において、媒体データの読み取り結果が「異常」である場合は、制御ユニット２０は、ステップＳ５へと処理を移行させる。
ステップＳ５で、制御ユニット２０（第１の取得部１３）は、口座情報及び読み取りに失敗したデータの種類を取得する。

口座番号の取得方法については、図３の説明においても述べたとおり、例えば挿入された媒体がＩＣカードであり、ＩＣチップからのデータの読み取りに失敗した場合には、カードの磁気データから口座番号を取得する。ＩＣカードの磁気データからもデータ読み取りに失敗した場合には、カードのエンボス加工から口座番号を取得する。磁気カードの磁気データからのデータの読み取りに失敗した場合は、カードのエンボスイメージから口座番号を取得する。通帳の磁気データからのデータの読み取りに失敗した場合は、通帳についてイメージＯＣＲを利用して口座番号を取得する。データの種類は、カード処理ユニット４０等の構成のいずれにおいてデータの読み取りに失敗したかにより取得する。

ステップＳ６で、制御ユニット２０（第２の取得部１４）は、装置番号をＲＡＭ２０ｂ等の記憶媒体から取得する。
ステップＳ７で、制御ユニット２０は、取得した口座番号、データの種類及び装置番号を、所定のフォーマットの電文に格納し、サーバ２に送信する。上述のとおり、サーバ２は、ＡＴＭ１０から新たに受信した情報とＤＢ２１に蓄積されている情報とから、要因が媒体あるいはＡＴＭ１０のいずれにあるかを判定し、ＡＴＭ１０に判定結果を返す。サーバ２の処理については、図８を参照して説明する。

ステップＳ８で、制御ユニット２０は、サーバ２から異常要因の判定結果を受信すると、ステップＳ９で、受信した判定結果が媒体要因であるか否かを判定する。判定結果が媒体要因である場合は、処理をステップＳ１０へと移行させ、判定結果がハード要因である（ＡＴＭ１０側の要因による）場合は、処理をステップＳ１２へと移行させる。

サーバ２の判定結果が媒体要因である場合は、ステップＳ１０で、制御ユニット２０（異常制御処理部１５）は、表示部３０ａに店舗窓口へと誘導する旨のメッセージを表示させる。そして、ステップＳ１１で、制御ユニット２０（異常制御処理部１５）は、カード処理ユニット４０等から媒体を返却させ、処理を終了する。

サーバ２の判定結果がハード要因である場合は、ステップＳ１２で、制御ユニット２０（異常制御処理部１５）は、表示部３０ａに他のＡＴＭ１０を利用するよう誘導する旨のメッセージを表示させる。そして、ステップＳ１３で、制御ユニット２０（異常制御処理部１５）は、カード処理ユニット４０等から媒体を返却させ、ステップＳ１４で、制御ユニット（異常制御処理部１５）は、ＡＴＭ１０を休止させると、処理を終了する。

図８は、サーバ２の判定部２２における媒体読み取り異常の要因判定処理を示したフローチャートである。サーバ２の判定部２２は、ＡＴＭ１０から口座番号、データの種類及び装置番号を含む電文を受信すると、図８に示す処理を開始する。

まず、ステップＳ２１で、判定部２２は、ＤＢ２１の異常発生情報を参照して、ＡＴＭ１０から受信した電文に含まれる口座番号と一致する口座番号のデータが、ＤＢ２１に所定の閾値Ｔｈ１（図８においては閾値１）を超える件数分登録されているか否かを判定する。ＡＴＭ１０に挿入された媒体の口座番号と一致する口座番号のデータが閾値Ｔｈ１を超える件数分登録されている場合は、処理をステップＳ２２へと移行させ、一致する口座番号のデータは閾値Ｔｈ１以下である場合は、処理をステップＳ２４へと移行させる。

ステップＳ２２で、判定部２２は、ステップＳ２１において口座番号が一致するとして抽出したデータの中に、ＡＴＭ１０から受信した電文に含まれるデータの種類と同一の対象データが、前述の閾値Ｔｈ１を超える件数分含まれるか否かを更に判定する。ＡＴＭ１０に挿入された媒体の種類を特定する対象データと同一の対象データが閾値Ｔｈ１を超える件数分含まれる場合は、処理をステップＳ２３へと移行させ、同一の対象データの件数が閾値Ｔｈ１以下である場合は、処理をステップＳ２４へと移行させる。

図９（ａ）は、ステップＳ２２の判定において抽出されるデータを説明する図である。ここでは、前述の閾値Ｔｈ１＝１である場合を例に説明する。
図９（ａ）では、口座番号が「３３３３３３３３３３」で対象データが「カード磁気データ」であり、受信した電文中の値と一致するデータがＤＢ２１に既に２件登録されている。口座番号「３３３３３３３３３３」の口座の磁気カードについては、過去にも読み取り異常が発生していることから、今回発生した媒体の読み取り異常は、媒体側に要因があるものと判定する。

ステップＳ２３では、判定部２２は、ＡＴＭ１０で発生した媒体読み取り異常は媒体要因である旨を示す所定値を格納した電文をＡＴＭ１０に送信し、処理を終了する。
ステップＳ２４で、判定部２２は、ＤＢ２１の異常発生情報を参照して、ＡＴＭ１０から受信した電文に含まれる装置番号と一致する装置番号のデータが、ＤＢ２１に所定の閾値Ｔｈ２（図８においては閾値２）を超える件数分登録されているか否かを判定する。媒体の挿入されたＡＴＭ１０を識別する装置番号と同一の装置番号のデータが閾値Ｔｈ２を超える件数分登録されている場合には、処理をステップＳ２５へと移行させ、同一の装置番号のデータの件数が閾値Ｔｈ２以下である場合は、処理をステップＳ２６へと移行させる。

図９（ｂ）は、ステップＳ２４の判定において抽出されるデータを説明する図である。ここでは、前述の閾値Ｔｈ２＝１である場合を例に説明する。
図９（ｂ）では、電文中の口座番号と一致するデータはＤＢ２１に未登録である。その一方で、装置番号が「ＡＴＭ＃１」であって、受信した電文中の値と一致するデータは、ＤＢ２１に既に２件登録されている。今回読み取り異常の発生した口座番号と一致する口座番号に関しては、過去に読み取り異常は発生していない。その一方で、装置番号「ＡＴＭ＃１」のＡＴＭ１０については過去にも読み取り異常が発生していることから、今回発生した媒体の読み取り異常は、ＡＴＭ１０側に要因があるものと判定する。

ステップＳ２５では、判定部２２は、ＡＴＭ１０で発生した媒体読み取り異常はハード要因である（ＡＴＭ１０側の要因による）旨を示す所定値を格納した電文をＡＴＭ１０に送信し、処理を終了する。ステップＳ２６では、判定部２２は、ＡＴＭ１０で発生した媒体読み取り異常は媒体要因である旨を示す所定値を格納した電文をＡＴＭ１０に送信し、処理を終了する。

なお、上記においては閾値Ｔｈ１＝Ｔｈ２＝１である場合を例に説明したが、これに限定されるものではない。閾値Ｔｈ１、Ｔｈ２として２以上の値を任意に設定することもできる。また、２つの閾値としては、互いに異なる値を設定することもできる。

上記のとおり、サーバ２は、今回検出されたケースを過去のケースと比較して、一致する口座番号の同一の媒体について過去にも一定件数以上の異常が検出されているか否か、同一のＡＴＭ１０で過去にも一定件数以上の媒体の読み取り異常が検出されているか否かにより、要因が媒体またはＡＴＭ１０のいずれにあるかを判断している。図７Ａ及び図７Ｂの説明で述べたとおり、ＡＴＭ１０は、サーバ２から通知された要因に応じた制御を行う。図７Ａ、図７Ｂ及び図８に示す一連の処理が終了した後に、媒体の再発行やＡＴＭ１０の保守作業が行われた場合には、読み取り異常が発生する要因は解消したものと判断して、ＤＢ２１の異常発生情報のうち、該当するデータを削除する構成としてもよい。

図１０は、ＤＢ２１を更新後の異常発生情報のデータ構造例を示す図である。図１０（ａ）は、ハード要因と判定されたＡＴＭ１０について保守作業を行った後のＤＢ２１の異常発生情報を例示し、図１０（ｂ）は、媒体要因と判定されたある口座の所定の媒体について再発行された後のＤＢ２１の異常発生情報を例示する。

サーバ２によりハード要因による媒体読み取り異常と判定されたＡＴＭ１０について装置保守を行った場合は、そのＡＴＭ１０については、更にハード要因による媒体読み取り異常は発生しないものと見込まれる。このため、図１０（ａ）に示す例では、装置番号「ＡＴＭ＃１」のデータについては、異常発生情報から削除している。これにより、装置番号「ＡＴＭ＃１」のＡＴＭ１０について無用にハード要因による読み取り異常と判定されることを防ぐ。このように、装置保守により問題が解消したＡＴＭ１０の装置番号を含むデータをＤＢ２１から削除することで、高精度での要因判定を維持することができる。これについて、図１１を参照して説明する。

図１１は、装置保守後にＤＢ２１を更新した後に発生した媒体読み取り異常についての要因判定処理について説明する図である。ここでは、装置番号「ＡＴＭ＃１」のＡＴＭ１０を含むデータをＤＢ２１から削除した場合を例に説明する。

図１１に例示するように、例えば装置保守が完了し、ＤＢ２１から装置番号「ＡＴＭ＃１」のデータを削除しておいたとする。この場合、装置番号「ＡＴＭ＃１」において口座番号「５５５５５５５５５５」の磁気カードについで媒体読み取り異常が発生しても、サーバ２において再度ハード要因と判定されてしまうことを回避できる。

また、サーバ２により媒体要因による媒体読み取り異常と判定された場合についても、同様に、媒体要因と判定された所定の口座（口座番号）の該当する媒体が再発行された場合は、データを削除する。再発行により、その媒体については更に媒体を要因とする読み取り異常は発生しないものと見込まれるためである。図１０（ｂ）に示す例では、口座番号「３３３３３３３３３３」、対象データ「カード磁気データ」を含むデータを異常発生情報から削除している。これにより、再発行後の媒体について、無用に媒体要因とする読み取り異常と判定されることを防ぎ、高精度での要因判定を維持する。

なお、ＤＢ２１からデータを削除する方法としては、例えば、装置保守や媒体の再発行の完了したタイミングで、ＡＴＭ１０等からサーバ２に向けて、削除すべきデータを特定する情報（装置番号／口座番号及びデータの種類）を含むデータ削除を依頼する旨の電文を送信してもよい。あるいは、例えば管理システム１の管理者等が直接にデータを削除したい装置番号等を指定して入力してもよい。サーバ２は、電文や入力指示に含まれる装置番号、あるいは口座番号及びデータの種類を含むデータをＤＢ２１から抽出して、該当するデータを削除する。

あるいは、装置保守や媒体の再発行が済んだ場合に該当データを削除しない構成とすることもできる。この場合は、図６に例示する構成の異常発生情報に、更に要因判定処理時の検索対象外データであるか否かを表す情報を付加する。データが要因判定処理において検索対象であるか否かを表す情報を、「検索対象情報」とする。

異常発生情報の中に検索対象情報が含まれる場合は、例えば、検索対象情報に値「０」が設定されていれば要因判定処理において検索対象とし、値「１」が設定されていれば、検索対象外とする。

サーバ２は、検索対象情報を利用して、要因判定処理においては高精度での要因判定を維持しつつ、媒体を破損しやすい利用者や障害の発生しやすいＡＴＭ１０等の情報を得ることが可能となる。すなわち、サーバ２は、ＤＢ２１の異常発生情報を参照することで、所定の口座番号の所定の種類のデータについては読み取り異常が多く発生していることや、所定の装置番号のＡＴＭ１０においては媒体の読み取り異常が多く発生していることを検出することができる。

例えば、ある口座番号のある種類のデータ（例えばカード磁気データ）を含むデータが、ＤＢ２１上に所定の閾値を上回る件数分登録されている場合には、その利用者は媒体の取り扱い方に問題がある可能性がある。そこで、サーバ２は、ＡＴＭ１０に対して指示を送信して、該当する口座番号の該当する媒体を受け付けた場合には、表示部３０ａに、図７ＢのステップＳ１０と同様の注意喚起のメッセージを表示させることもできる。例えば、通帳の磁気データについては、メッセージ「磁石付のバッグや携帯電話等、磁気を発するものと一緒に持ち歩いていませんか？」等を出力してもよい。ＩＣカードについては、メッセージ「カードを後ろポケットに入れたまま椅子に座る等していませんか？」等を出力してもよい。このように、媒体の種類に応じたメッセージをＡＴＭ１０の表示部３０ａに表示することで、利用者の注意が促され、無駄な媒体の再発行を削減できると見込まれる。

また、ＤＢ２１の異常発生情報に、所定のＡＴＭ１０の装置番号を含むデータが所定の閾値を上回る件数分登録されている場合には、そのＡＴＭ１０の装置保守の対応の仕方に問題がある可能性がある。そこで、サーバ２は、該当するＡＴＭ１０に対して電文を送信しておき、ＡＴＭ１０の保守作業時には、対応方法の見直し（ユニットの全取替え等）を促すメッセージを表示部３０ａに表示させることもできる。これにより、保守作業を軽減させることができ、保守作業により稼動していないＡＴＭ１０を減らすことが可能となる。

以上説明したように、本実施形態に係る管理システム１によれば、あるＡＴＭ１０において媒体の読み取り異常が検出されると、ＡＴＭ１０は、媒体から取得される口座番号、媒体の種類により特定されるデータの種類、及びＡＴＭ１０の装置番号とをサーバ２に送信する。サーバ２は、ＡＴＭ１０から受信した口座番号及び媒体の種類により特定されるデータの種類と、装置番号とを互いに関連付けて蓄積していく。読み取り異常の要因が媒体にある場合は、同一の口座番号及びデータの種類については、他のＡＴＭ１０を利用した場合であっても、読み取り異常が発生する。また、読み取り異常の要因がＡＴＭ１０にある場合は、同一のＡＴＭ１０を他の口座番号の媒体を用いて利用した場合であっても、読み取り異常が発生する。このことから、新たにあるＡＴＭ１０において媒体の読み取り異常が検出された場合には、サーバ２のＤＢ２１に蓄積した情報を参照して、要因が媒体にあるか、あるいはＡＴＭ１０にあるかを判定し、ＡＴＭ１０は、判定された要因に応じた制御を行う。管理システム１内で発生した媒体読み取り異常に関する情報をサーバ２に集約させて管理することで、要因の切り分けを適切且つ効率的に行い、要因に応じたＡＴＭ１０の制御を行うことが可能となる。

＜第２の実施形態＞
上記の実施形態においては、ＡＴＭ１０は、媒体の読み取り結果が異常である場合には、口座番号、読み取りに失敗したデータの種類及びＡＴＭ１０の装置番号をサーバ２に送信している。これに対し、本実施形態においては、ＡＴＭ１０における媒体読み取り結果が異常であるか否かによらず、読み取り結果とともに口座番号、データの種類及び装置番号をサーバ２に送信する。サーバ２は、媒体の読み取り結果が異常である場合にはデータを蓄積し、要因判定を行う。以下に、上記の実施形態と異なる点を中心に、本実施形態に係る管理システム１について説明する。

管理システム１の構成やＡＴＭ１０やサーバ２のハードウェア構成等については、上記の実施形態と同様であり、それぞれ図１〜図４を参照して先に説明したとおりである。

図１２は、本実施形態に係る管理システム１のブロック図である。前述のとおり、本実施形態に係る管理システム１では、サーバ２が媒体の読み取り異常を検出する。図５に示す上記の実施形態と異なる点を中心に、本実施形態に係る管理システム１の各構成の動作について説明する。

ＡＴＭ１０は、取得部１２及び異常制御処理部１５を有し、取得部１２は、第１の取得部１３及び第２の取得部１４を備える。異常制御処理部１５の動作は上記の実施形態と同様である。

本実施形態においては、第１の取得部１３は、ＡＴＭ１０に挿入された口座番号と、口座番号等の取引に必要な情報の読み取りを行ったデータの種類と、読み取り結果（正常／異常）とを取得し、第２の取得部１４は、自装置の装置番号を取得する。

上記の実施形態の説明において述べたとおり、図３のカード処理ユニット４０等は、あるデータの格納先から口座番号等の読み取りに失敗した場合には、他の手段を用いてデータの取得を試みる。実施例では、第１の取得部１３が取得するデータの種類としては、カード処理ユニット４０等が最初に読み出しを行ったデータの種類、すなわち、取引処理において本来データの読み出しを行うべき「データの種類」がこれに相当する。

これについて、ＩＣカードを例に説明する。カード処理ユニット４０は、ＩＣカードから口座番号等の情報を読み出すときは、まずＩＣチップからデータの読み出し処理を行う。カード処理ユニット４０は、ＩＣチップからのデータの読み出しに失敗すると、磁気データからのデータの読み出しを試みる。このような場合であっても、本来データを読み出すべきＩＣチップからのデータの読み出しには失敗しているとして、実施例では、第１の取得部１３は、データの種類としては「ＩＣカードデータ」を、媒体読み取り結果としては「異常」を取得する。

ＡＴＭ１０は、取得部１２で取得した情報、すなわち、読み取り結果、口座番号、データの種類及び装置番号を、電文に格納してサーバ２に送信する。
サーバ２は、ＤＢ２１、判定部２２及び異常検出部２３を有する。ＤＢ２１及び判定部２２の動作については上記の実施形態と同様である。異常検出部２３は、ＡＴＭ１０から受信した電文中の読み取り結果を参照して、媒体の読み取り異常を検出する。異常検出部２３は、媒体の読み取り異常を検出した場合には、ＡＴＭ１０から受信した電文に含まれる口座番号、データの種類及び装置番号を互いに関連付けて、ＤＢ２１に格納する。ＤＢ２１の異常発生情報のデータ構造例は、図１４（ａ）に示すとおりである。図１４（ａ）中の対象データには、第１の取得部１３が取得するデータの種類が格納される。上記の実施形態と同様に、対象データにより、媒体の種類が特定される。また、上記においては説明を割愛しているが、上記の実施形態と同様に、読み取り異常の発生した日時についてもＡＴＭ１０またはサーバ２において取得し、ＤＢ２１に格納している。

このように、サーバ２は、ＡＴＭ１０から受信した電文に含まれる媒体読み取り結果より、媒体の読み取り異常を検出した場合には、媒体要因判定処理の対象と判断して、上記の実施形態と同様に、ＤＢ２１への情報の蓄積及び図８の要因判定処理を実行する。ここでは、ＡＴＭ１０が実行する処理の流れについて、上記の実施形態と異なる点を中心に説明する。

図１３Ａ及び図１３Ｂは、ＡＴＭ１０の制御ユニット２０（図３）による取引処理を示したフローチャートである。ＡＴＭ１０の制御ユニット２０は、利用者が表示部３０ａを操作して所定の取引を開始したことを契機として、図１３Ａ及び図１３Ｂに示す処理を開始する。

ステップＳ３１及びステップＳ３２については、それぞれ図７ＡのステップＳ１及びステップＳ２と同様である。
ステップＳ３３で、制御ユニット２０（第１の取得部１３）は、口座情報、データの種類及びカード処理ユニット４０等における媒体の読み取り結果を取得する。ステップＳ３４で、制御ユニット２０（第２の取得部１４）は、装置番号をＲＡＭ２０ｂ等の記憶媒体から取得する。

ステップＳ３５で、制御ユニット２０は、ステップＳ３３及びステップＳ３４で取得した情報を所定のフォーマットの電文に格納し、サーバ２に送信する。
サーバ２は、受信した情報のうち、媒体の読み取り結果が「異常」であるものについてはＤＢ２１に蓄積する。また、サーバ２は、ＤＢ２１を参照して、図８の要因判定処理を実行し、ＡＴＭ１０に判定結果を返す。媒体結果の読み取り結果が「正常」であった場合には、サーバ２は、図８の要因判定処理は行わず、媒体の読み取りが正常である旨をＡＴＭ１０に返す。

ステップＳ３６で、制御ユニット２０は、サーバ２から要因判定結果を受信すると、ステップＳ３７で、要因判定結果が、媒体の読み取り結果が正常である旨の通知であるか否かを判定する。媒体の読み取り結果が正常である旨の通知を受信した場合には、処理をステップＳ３８へと移行させ、要因判定結果に、異常要因を含む通知を受信した場合には、処理をステップＳ３９へと移行させる。

ステップＳ３８の処理、及びステップＳ３９以降の処理については、それぞれ図７ＡのステップＳ４、及び図７ＢのステップＳ９以降の処理と同様である。
サーバ２側の動作については、上記の実施形態と同様に、媒体やＡＴＭ１０の問題が解消された場合には、ＤＢ２１を更新して、蓄積されている異常発生情報の中から該当するデータを削除する構成としてもよい。これについて、図１４を参照して説明する。

図１４は、本実施形態に係るサーバ２によるＤＢ２１の更新方法を説明する図である。図１４（ａ）は、ＤＢ２１に蓄積された更新前の異常発生情報の例であり、図１４（ｂ）は、更新後の異常発生情報の例である。

本実施形態においては、サーバ２は、ＡＴＭ１０において正常に口座番号等の情報を読み取ることのできた場合であっても、口座情報やデータの種類、及び装置番号を取得している。サーバ２は、判定部２２が判定した要因が媒体要因であるかハード要因であるかに応じて、それぞれ口座番号または装置番号をＲＡＭ８０ｂ等に一時記憶しておく。前述のとおり、要因判定処理の対象となるのは、ＡＴＭ１０において媒体の読み取り結果が「異常」である件に限られる。サーバ２は、一時記憶している口座番号や装置番号について、媒体の読み取り結果が「正常」である旨の電文を受信すると、ＤＢ２１を更新し、該当データを削除する。

図１４に示す例では、過去に装置番号「ＡＴＭ＃１」のＡＴＭ１０についてはハード要因と判定し、また、口座番号「３３３３３３３３３３」の口座の磁気カードについて、媒体要因と判定している。

サーバ２は、ハード要因である旨を通知した装置番号「ＡＴＭ＃１」のＡＴＭ１０から、媒体読み取り結果が正常である旨の電文を受信すると、装置番号「ＡＴＭ＃１」のＡＴＭ１０についてはハード要因の問題が解消したものと判断する。この場合は、サーバ２は、ＤＢ２１から装置番号「ＡＴＭ＃１」を含むデータを削除する。

また、サーバ２は、媒体要因である旨を通知した口座番号「３３３３３３３３３３」の口座の磁気カードについての読み取り結果が正常である旨の電文を受信すると、口座番号「３３３３３３３３３３」の口座の磁気カードについては問題が解消したものと判断する。この場合は、ＤＢ２１から口座番号「３３３３３３３３３３」を含むデータを削除する。

このように、本実施形態によれば、媒体読み取り結果が正常である場合についてもサーバ２に情報を送信するため、別途サーバ２に問題が解消された旨の通知をしなくとも、不要なデータをＤＢ２１から削除して、高精度での要因判定を維持することが可能となる。

データをＤＢ２１から削除するときは、１件分のデータを全て削除する必要はない。媒体要因の読み取り異常が解消された場合には、口座番号及びデータの種類（第１の取得部１３で取得する情報）のみを削除し、ハード要因の読み取り異常が解消された場合には、装置番号（第２の取得部１４で取得する情報）のみを削除してもよい。具体的には、図１４（ｂ）に示すように、例えば、問題の解消した装置番号「ＡＴＭ＃１」のみを削除して、関連付けられた口座番号等はＤＢ２１に残してもよい。また、口座番号「３３３３３３３３３３」のみを削除して、関連付けられた装置番号はＤＢ２１に残してもよい。

媒体読み取り異常の要因となった情報のみを削除することで、より高精度での要因判定処理を維持することができる。このような更新方法によれば、図１４（ｂ）に示す例では、例えば装置番号「ＡＴＭ＃２」「ＡＴＭ＃４」の情報が異常発生情報に残ることとなる。しかし、これらのＡＴＭ１０に異常がなければ、ハード要因による媒体読み取り異常が検出されることはないため、要因判定の精度に影響を与えることはない。

なお、図１４（ｂ）においては口座番号のみを削除する構成を例示しているが、口座番号とともに対象データについても削除する構成としてもよい。
また、各ＡＴＭ１０がサーバ２のＤＢ２１に蓄積されている異常発生情報に基づき、読み取り異常の発生した媒体やＡＴＭ１０を監視して、要因判定処理を行う構成とすることもできる。これについて、図１５を参照して説明する。

図１５は、本実施形態に係る要因判定処理による効果を説明する図である。
図１５に示す異常発生情報によれば、装置番号「ＡＴＭ＃３」のＡＴＭ１０にて口座番号「４４４４４４４４４４」の口座のＩＣカードデータの読み取りにおいて、媒体読み取り異常が発生している。

例えば、サーバ２の判定部２２は、図１５の異常発生情報を、システム内の全てのＡＴＭ１０に通知しておく。他のＡＴＭ１０（例えば装置番号「ＡＴＭ＃１」のＡＴＭ１０）において、通知された口座番号及びデータの種類について正常に媒体の読み取りを行うことができたとする。この場合は、装置番号「ＡＴＭ＃３」のＡＴＭ１０で発生した媒体読み取り異常の要因は、媒体にはなく、ＡＴＭ１０側にあると判断できる。ハード要因と判定したＡＴＭ１０は、装置番号「ＡＴＭ＃３」のＡＴＭ１０において発生した読み取り異常はハード要因である旨をサーバ２に通知する。サーバ２は、装置番号「ＡＴＭ＃３」のＡＴＭ１０に休止指示を送信し、保守が入るまでの間ＡＴＭ１０を休止させておく。

同様に、同一の装置番号「ＡＴＭ＃３」のＡＴＭ１０において、例えば他の口座番号のＩＣカードについては正常に読み取ることができる場合には、上記の読み取り異常の要因は、ＡＴＭ１０にはなく、媒体側にあると判断できる。この場合は、サーバ２は、システム１内の各ＡＴＭ１０に口座番号を通知しておく。媒体要因による読み取り異常と判断したＡＴＭ１０は、口座番号「４４４４４４４４４４」のＩＣカードデータの読み取り異常については媒体要因である旨をサーバ２に通知する。サーバ２は、管理システム１内のＡＴＭ１０に対し、媒体要因と判定された媒体に関する情報、すなわち、口座番号「４４４４４４４４４４」及びデータの種類「ＩＣカードデータ」を通知しておく。いずれかのＡＴＭ１０において、該当する口座の該当する媒体を受け付けた場合には、図１３ＢのステップＳ４０の注意喚起メッセージと同様のメッセージを表示部３０ａに表示させることができる。あるいは、利用者のメールアドレス等を管理システム１等に登録している場合には、同様のメッセージを含む電子メールを送信する等の処理を実行してもよい。

このように、ＡＴＭ１０側で要因判定を行う構成とした場合には、サーバ２やネットワーク４にかかる負荷を軽減しつつ、次の読み取り異常の発生を待つことなく、より早期に要因判定を行い、要因に応じたＡＴＭ１０の制御を行うことが可能となる。

なお、ＤＢ２１の異常発生情報を管理システム１内のＡＴＭ１０に通知しておき、各ＡＴＭ１０において読み取り異常の発生した媒体やＡＴＭ１０の監視を行う処理については、上記の実施形態に係る管理システム１に適用することも可能である。

以上説明したように、本実施形態に係る管理システム１によれば、ＡＴＭ１０において媒体を受け付けると、媒体より取得される口座番号、媒体の種類により特定されるデータの種類及び読み取りの成否を取得し、これらの情報とＡＴＭ１０の装置番号とをサーバ２に送信する。サーバ２は、読み取りの成否を参照し、媒体の読み取り異常を検出した場合には、口座番号及びデータの種類と、装置番号とを互いに関連付けて蓄積していく。サーバ２にて媒体読み取り発生時の情報を集約させることで、上記の実施形態と同様に、読み取り異常の要因の切り分けを適切且つ効率的に行い、要因に応じたＡＴＭ１０の制御を行うことが可能となる。

なお、本発明は、上述の実施の形態に例示した構成に限らず、その趣旨を逸脱しない範囲で種々変更可能であることは言うまでもない。

１ 管理システム
２ サーバ装置（サーバ）
４ ネットワーク
１０ 自動取引装置（ＡＴＭ）
２０ 制御ユニット
２１ データベース（媒体データ読取異常発生情報）
３０ 表示ユニット
３０ａ 表示部

Claims (6)

1. 利用者により挿入された媒体を用いて取引を行う複数の自動取引装置とネットワークを介して接続され、該複数の自動取引装置を管理するサーバ装置であって、
   前記自動取引装置に挿入された媒体の読み取り異常が検出された場合には、該自動取引装置において取得した、該媒体の口座番号及び該媒体の種類と該自動取引装置を識別する装置情報とを互いに関連付けて蓄積していく蓄積部と、
   新たに媒体の読み取り異常が検出されたことにより取得した媒体の口座番号及び媒体の種類と前記自動取引装置の装置情報とを、前記蓄積部に既に蓄積されている情報と比較することにより、前記新たに検出された媒体の読み取り異常が、前記自動取引装置あるいは該媒体のいずれによるものであるかを判定する判定部と、
   を備え、
   前記判定部は、
   前記新たに媒体の読み取り異常が検出された自動取引装置について前記自動取引装置に挿入された媒体の口座番号及び該媒体の種類と一致する口座番号及び媒体の種類が、該蓄積部に第１の閾値を超える件数蓄積されている場合には、該媒体を要因とする読み取り異常と判定し、
   該新たに媒体の読み取り異常が検出された自動取引装置について前記媒体の挿入された自動取引装置を識別する装置情報と一致する装置情報が、該蓄積部に第２の閾値を超える件数蓄積されている場合には、該自動取引装置を要因とする読み取り異常と判定し、
   前記新たに媒体の読み取り異常が検出された自動取引装置について、前記自動取引装置に挿入された媒体の口座番号及び該媒体の種類と一致する口座番号及び媒体の種類が、前記蓄積部には前記第１の閾値以下の件数蓄積されており、且つ前記自動取引装置を識別する装置情報と一致する装置情報が、前記蓄積部には前記第２の閾値以下の件数蓄積されている場合には、前記媒体を要因とする読み取り異常と判定する
   ことを特徴とするサーバ装置。
2. 前記自動取引装置に挿入された前記媒体の読み取り異常の有無を判断し、新たに前記自動取引装置から受信した情報を参照して、前記媒体の読み取りに異常なしと判断した場合は、前記蓄積部に蓄積している情報のうち、該受信した情報と一致する情報については削除する異常検出部と、
   を更に備えることを特徴とする請求項１記載のサーバ装置。
3. 利用者により挿入された媒体を用いて取引を行う複数の自動取引装置と、該複数の自動取引装置とネットワークを介して接続され、該複数の自動取引装置を管理するサーバ装置とを有する管理システムであって、
   前記自動取引装置に挿入された前記媒体の読み取り異常を検出する異常検出部と、
   前記自動取引装置に挿入された媒体の口座番号及び該媒体の種類を取得する第１の取得部と、
   前記媒体の挿入された自動取引装置を識別する装置情報を取得する第２の取得部と、
   前記異常検出部において媒体の読み取り異常が検出された場合には、前記第１及び第２の取得部がそれぞれ取得した情報を互いに関連付けて蓄積していく蓄積部と、
   前記第１及び第２の取得部において取得した媒体の口座番号及び媒体の種類と前記自動取引装置の装置情報とを、前記蓄積部に既に蓄積されている情報と比較することにより、前記異常検出部において新たに検出された媒体の読み取り異常が、前記自動取引装置あるいは該媒体のいずれによるものであるかを判定する判定部と、
   前記判定部の判定結果に応じて、前記媒体の読み取り異常の発生した前記自動取引装置を制御する異常制御処理部と、
   を備え、
   前記判定部は、
   前記第１の取得部にて取得した媒体の口座番号及び該媒体の種類と一致する口座番号及び媒体の種類が、該蓄積部に第１の閾値を超える件数蓄積されている場合には、該媒体を要因とする読み取り異常と判定し、
   前記第２の取得部にて取得した前記装置情報と一致する装置情報が、該蓄積部に第２の閾値を超える件数蓄積されている場合には、該自動取引装置を要因とする読み取り異常と判定し、
   前記第１の取得部にて取得した媒体の口座番号及び該媒体の種類と一致する口座番号及び媒体の種類が、前記蓄積部には前記第１の閾値以下の件数蓄積されており、且つ前記第２の取得部にて取得した装置情報と一致する装置情報が、前記蓄積部には前記第２の閾値以下の件数蓄積されている場合には、前記媒体を要因とする読み取り異常と判定することを特徴とする管理システム。
4. 前記異常検出部、前記第１の取得部及び前記第２の取得部は、前記複数の自動取引装置のそれぞれに備えられ、該第１及び第２の取得部は、該異常検出部において媒体の読み取り異常を検出した場合に、各情報を取得する処理を実行し、
   前記蓄積部は、前記サーバ装置に備えられ、該サーバ装置は、前記自動取引装置において発生した媒体読み取り異常について前記第１及び第２の取得部が取得した情報を、前記ネットワークを介して受信し、順次該蓄積部に蓄積してゆく
   ことを特徴とする請求項３記載の管理システム。
5. 前記第１及び第２の取得部は、前記複数の自動取引装置のそれぞれに備えられ、該第１の取得部は、前記媒体が挿入されると、前記口座番号及び媒体の種類とともに、該媒体の読み取りの成否を取得し、
   前記異常検出部及び前記蓄積部は、前記サーバ装置側に備えられ、該異常検出部は、前記ネットワークを介して前記自動取引装置から受信した情報を参照して、前記媒体の読み取り異常を検出した場合には、当該受信した情報を順次該蓄積部に蓄積してゆく
   ことを特徴とする請求項３記載の管理システム。
6. 利用者により挿入された媒体を用いて取引を行う複数の自動取引装置と、該複数の自動取引装置とネットワークを介して接続され、該複数の自動取引装置を管理するサーバ装置とを有する管理システムにおける自動取引装置の管理方法であって、
   前記自動取引装置に挿入された媒体の口座番号及び該媒体の種類を取得し、
   前記媒体の挿入された自動取引装置を識別する装置情報を取得し、
   前記媒体の読み取り異常が検出された場合には、前記口座番号及び媒体の種類と、前記装置情報とを互いに関連付けて蓄積していき、
   前記取得した媒体の口座番号及び媒体の種類と前記自動取引装置の装置情報とを、既に蓄積されている情報と比較し、これにおいて、
   前記取得した媒体の口座番号及び該媒体の種類と一致する口座番号及び媒体の種類が、第１の閾値を超える件数蓄積されている場合には、該媒体を要因とする読み取り異常と判定し、
   前記取得した前記装置情報と一致する装置情報が、第２の閾値を超える件数蓄積されている場合には、該自動取引装置を要因とする読み取り異常と判定し、
   前記取得した媒体の口座番号及び該媒体の種類と一致する口座番号及び媒体の種類が、前記第１の閾値以下の件数蓄積されており、且つ前記取得した装置情報と一致する装置情報が、前記第２の閾値以下の件数蓄積されている場合には、前記媒体を要因とする読み取り異常と判定し、
   前記判定結果に応じて、前記媒体の読み取り異常の発生した前記自動取引装置を制御する、
   ことを特徴とする管理方法。