自動取引装置
【課題】自動取引装置１２が、自動的に障害復旧のための処理をし、必要な場合にすみやかに係員の出動要請をする。
【解決手段】障害発生通知３０を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する障害検知手段４４と、障害発生以前の動作履歴を含む、装置の状態情報３２を収集する情報収集手段４６と、障害識別パラメータ３６と障害復旧手順３８を記憶する記憶装置２２と、状態情報３２の中に障害識別パラメータ３６が含まれているかどうかを判断する情報解析手段４８と、復旧制御手順を実行する復旧制御手段５０と、ネットワーク１６を通じて係員の出動要求メッセージ４１を送信する出動要求手段５４と、結果報告手段５６を備える。
【解決手段】障害発生通知３０を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する障害検知手段４４と、障害発生以前の動作履歴を含む、装置の状態情報３２を収集する情報収集手段４６と、障害識別パラメータ３６と障害復旧手順３８を記憶する記憶装置２２と、状態情報３２の中に障害識別パラメータ３６が含まれているかどうかを判断する情報解析手段４８と、復旧制御手順を実行する復旧制御手段５０と、ネットワーク１６を通じて係員の出動要求メッセージ４１を送信する出動要求手段５４と、結果報告手段５６を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、障害が発生したときに、復旧のための各種処理を自動的に実行する機能を持つ自動取引装置に関する。
【背景技術】
【０００２】
金融機関で使用されている自動取引装置（ＡＴＭ）は、その普及とともに性能が向上し、信頼性も著しく向上している。無人運転されるものも多く、障害の発生頻度は、数千回の取引をして１回程度という状況にある。従来は、無人店舗で自動取引装置に障害が発生した場合には、ネットワークを通じて監視サーバに通報が届く。監視サーバ側では、届いた障害情報を監視サーバに接続した端末に表示する。専任の係員が端末に表示した障害情報を確認して利用者と電話連絡しながら対処する。可能な場合にはリモート操作で復旧を試みて、回復しないときには、現場に係員を出動させる。係員は、診断プログラム等を起動して、復旧処理を実行する（特許文献１参照）（特許文献２参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９−１０４２６６号公報
【特許文献２】特開２００３−２９６７９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
既知の従来の技術には、次のような解決すべき課題があった。
自動取引装置の性能向上により、リモート操作で復旧するような簡単な障害は減少し、希に発生する障害は、係員が現場に出動しなければならないような種類のものが多い。このような、障害の発生時には、利用者を長時間待たせることなく、迅速に出動要請の要否を判断することが望まれる。更に、監視サーバや端末類を設置するので、監視システムへの投資や専任係員が必要である。規模の大きな金融機関では、何台もの監視サーバ等を設置し、多くの専任係員を配置するので、多額のコストが掛かるという問題があった。また、自動取引装置と監視サーバ間の通信が通信障害で途絶えると、リモート操作による障害対応が行えないという問題もある。
上記の課題を解決するために、本発明は次のような自動取引装置を提供することを目的とする。
（１）自動取引装置が、自動的に障害復旧のための処理を実行する。
（２）必要な場合にすみやかに係員の出動要請を自動的に実行する。
（３）自動復旧処理により、専任係員の負担を軽減し、監視コストを低減する。
【課題を解決するための手段】
【０００５】
以下の構成はそれぞれ上記の課題を解決するための手段である。
〈構成１〉
金融機関において、現金の入出金取引に使用される装置であって、入出金取引業務のための処理を実行する業務アプリケーション実行手段と、障害の監視と復旧のための処理を実行する監視アプリケーション実行手段とを備え、前記業務アプリケーション実行手段から受信した障害発生通知を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する障害検知手段と、障害発生以前の動作履歴を含む、装置の状態情報を収集する情報収集手段と、装置で発生する障害の種別を認識するための障害識別パラメータと、該当する種別の障害に対する障害復旧手順を記憶する記憶装置と、前記情報収集手段が収集した状態情報の中に、前記記憶装置に記憶された障害識別パラメータが含まれているかどうかを判断する情報解析手段と、前記情報解析手段が、前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記記憶装置に記憶された該当する復旧制御手順を読み出して、その手順を実行する復旧制御手段と、前記情報解析手段が、前記状態情報の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワークを通じて係員の出動要求メッセージを送信する出動要求手段と、復旧制御手段または出動要求手段の処理結果報告をネットワークを通じて、送信する処理報告手段を備えたことを特徴とする自動取引装置。
【０００６】
〈構成２〉
構成１に記載の自動取引装置において、前記復旧制御手段による該当する障害復旧手順が正常に実行できないとき、前記情報収集手段は再び状態情報を収集し、前記情報解析手段が前記状態情報の中に新たな障害識別パラメータが含まれていると判断したとき、前記復旧制御手段は該当する復旧制御手順を実行することを特徴とする自動取引装置。
【０００７】
〈構成３〉
構成１または２に記載の自動取引装置において、前記復旧制御手段は、該当する障害復旧手順が正常に実行できないとき、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。
【０００８】
〈構成４〉
構成１乃至の３いずれかに記載の自動取引装置において、自動取引装置固有の障害を示す障害識別パラメータとその障害復旧手順を前記記憶装置に記憶したことを特徴とする自動取引装置。
【０００９】
〈構成５〉
構成１乃至４のいずれかに記載の自動取引装置において、誰も使用していないアイドル状態で、前記障害検知手段が復旧の必要な障害を検出したときには、前記情報収集手段が状態情報を収集し、前記情報解析手段が前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記復旧制御手段は該当する復旧制御手順を実行することを特徴とする自動取引装置。
【００１０】
〈構成６〉
構成５に記載の自動取引装置において、リソース（メモリーの空き領域）が一定値以下に減少した場合を、前記障害識別パラメータに含めておき、該当する障害復旧手順は、リブートを実行するとしたことを特徴とする自動取引装置。
【００１１】
〈構成７〉
構成５に記載の自動取引装置において、使用する媒体量の減少を含む、予め設定された装置の警戒レベルを示す情報を、前記情報収集手段が収集する状態情報に含め、前記警戒レベルを示す情報を前記障害識別パラメータに含めておき、該当する障害復旧手順は、前記警戒レベルを示す情報を含む出動要求メッセージを生成して、前記出動要求手段に対して、出動要求メッセージの送信を依頼するとしたことを特徴とする自動取引装置。
【００１２】
〈構成８〉
構成５乃至７のいずれかに記載の自動取引装置において、自動復旧制御に失敗をしたとき、もしくは、前記警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされたとき、前記復旧制御手段は、近接して配置された他の全ての自動取引装置が、使用可能な状態か使用不可能な状態か警戒レベルの状態かを示す装置稼働状態を取得し、自機を含めた使用不可能な状態もしくは警戒レベルの状態の自動取引装置の合計台数が限界値を越えた場合に限り、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。
【００１３】
〈構成９〉
構成５乃至７のいずれかに記載の自動取引装置において、自動復旧制御に失敗をしたとき、もしくは、前記復旧制御手段は、警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされた場合に、記憶装置に記憶されている巡回予定データを参照して、係員による巡回時までの時間が一定値以上の場合に限り、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。
【００１４】
〈構成１０〉
金融機関において、現金の入出金取引に使用される装置のコンピュータを、入出金取引業務のための処理を実行する業務アプリケーション実行手段と、障害の監視と復旧のための処理を実行する監視アプリケーション実行手段とを備え、前記業務アプリケーション実行手段から受信した障害発生通知を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する障害検知手段と、障害発生以前の動作履歴を含む、装置の状態情報を収集する情報収集手段と、装置で発生する障害の種別を認識するための障害識別パラメータと、該当する種別の障害に対する障害復旧手順を記憶する記憶装置と、前記情報収集手段が収集した状態情報の中に、前記記憶装置に記憶された障害識別パラメータが含まれているかどうかを判断する情報解析手段と、前記情報解析手段が、前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記記憶装置に記憶された該当する復旧制御手順を読み出して、その手順を実行する復旧制御手段と、前記情報解析手段が、前記状態情報の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワークを通じて係員の出動要求メッセージを送信する出動要求手段と、復旧制御手段または出動要求手段の処理結果報告をネットワークを通じて、送信する処理報告手段、として機能させる自動取引装置制御プログラム。
【００１５】
〈構成１１〉
構成１０に記載の自動取引装置制御プログラムを記録したコンピュータで読み取り可能な記録媒体。
【発明の効果】
【００１６】
〈構成１の効果〉
障害識別パラメータにより自動復旧が可能と判断した障害について、記憶装置に記憶された該当する復旧制御手順に従って自動的に障害復旧処理をするので、監視端末側の負担を軽減できる。さらに障害の種別によっては、係員が対応するよりも素早く的確に復旧ができる。また、障害の診断から係員の出動要求までの時間を短縮して、利用者の待ち時間を少なくできる。
〈構成２の効果〉
障害復旧手順を実行中に障害復旧に失敗することがある。このとき、再度状態情報を収集して、自動復旧を試みることができる。新たな障害識別パラメータが見つかれば、別の障害復旧手順を実行できる。
〈構成３の効果〉
自動復旧制御に失敗をしたときに、自動的に出動要求メッセージを送信して、迅速に係員を派遣できる。
〈構成４の効果〉
自動取引装置の内部に監視アプリケーション実行手段を設けるので、それぞれ機種の異なる自動取引装置について、固有の障害も自動的に復旧できる。
〈構成５の効果〉
誰も使用していないアイドル状態で復旧の必要な障害を検出したときには、自動的に復旧処理を実行する。
〈構成６の効果〉
リソースが減少すると、その後障害が発生する確率が高いので、これを障害発生と判断して、自動復旧させる。従って、利用時の障害発生を未然に防ぐことができる。
〈構成７の効果〉
紙幣等の媒体量の減少を示す情報を、警戒レベルを示す情報と呼ぶとき、この情報が状態情報に含まれている場合には、警戒レベルを示す情報を含む出動要求メッセージを生成する。その後、所定のタイミングで自動的に出動要求メッセージの送信を依頼する。
〈構成８の効果〉
無人店舗等で、近接して複数台の自動取引装置が配置されているときに、例えば、１台だけなら、使用不可能な状態あるいは警戒レベルの状態のままでも良い場合がある。このとき、ただちに出動要求メッセージを送信せずに待機する。これで、出動要求の頻度を低下させられる。
〈構成９の効果〉
間もなく次回の巡回があるような場合には、出動要請を見合わせることができる。
【図面の簡単な説明】
【００１７】
【図１】本発明の自動取引装置の具体例を示す概略機能ブロック図である。
【図２】自動処理テーブルの内容例説明図である。
【図３】障害識別パラメータから障害復旧手順を得る処理の説明図である。
【図４】障害発生時に利用者に媒体を返却する自動処理の例である。
【図５】障害復旧手順が実行されるときのシーケンスチャートである。
【図６】利用者が離れた後の障害自動復旧シーケンスチャートである。
【図７】出動要求をする場合のシーケンスチャートである。
【図８】出動要求メッセージ送信後のシーケンスチャートである。
【図９】監視端末１８の表示画面の具体例説明図である。
【図１０】出動時刻や障害からの復旧時刻を示す画面である。
【図１１】障害検出動作を示すメインルーチンである。
【図１２】障害復旧動作を示すメインルーチンである。
【図１３】出動要求処理の動作フローチャートである。
【図１４】障害復旧処理動作の具体的なフローチャートである。
【図１５】係員の出動要求の前半処理フローチャートである。
【図１６】係員の出動要求の後半処理フローチャートである。
【図１７】実施例３の動作フローチャートである。
【図１８】実施例４の動作フローチャートである。
【発明を実施するための形態】
【００１８】
図１は、本発明の自動取引装置の具体例を示す概略機能ブロック図である。
図に示す例では、金融機関のある無人店舗に、４台の自動取引装置１２（ＡＴＭ）が内部ＬＡＮ１４を介して配置されている。そのうちの一台について、図の右側の一点鎖線の円内にその機能ブロックを図示した。例えば、４台の自動取引装置１２は、互いに内部ＬＡＮ１４により接続されている。そして、全ての自動取引装置１２が、図の一点鎖線の円内の構成を備えるものとする。
【００１９】
自動取引装置１２は、ネットワークインタフェースを介してネットワーク１６に接続されている。ネットワーク１６には、自動取引装置１２を遠隔監視するために、監視端末１８が接続されている。監視端末１８は監視員６０により操作される。監視員６０は、自動取引装置１２の状態を監視して、必要に応じて、障害の復旧処理を実行する。監視端末１８には、情報を記憶するために、管理データ記憶装置２０が接続されている。また、障害復旧のために出動する係員は、携帯端末１７を所持している。携帯端末１７には、ネットワーク１６を通じて出動要求メッセージ４１が届く構成になっている。
【００２０】
自動取引装置１２は利用者６２により利用される。自動取引装置１２を動作させるために、記憶装置２２と演算処理装置２４とが設けられている。記憶装置２２は障害発生通知３０、処理結果報告３１、状態情報３２、障害情報３４、障害識別パラメータ３６、障害復旧手順３８、巡回予定データ４０、出動要求メッセージ４１、装置稼働状態４２等を記憶する。演算処理装置２４は、業務アプリケーション実行手段２６、監視アプリケーション実行手段２８等の機能ブロックを有する。監視アプリケーション実行手段２８は、障害検知手段４４、情報収集手段４６、情報解析手段４８、復旧制御手段５０、認証処理手段５２、出動要求手段５４、結果報告手段５６等を含んでいる。
【００２１】
本発明では、金融機関等で使用され、現金の入出金取引に使用される自動取引装置１２に対して、障害の自動復旧のための各種機能を付与する。このために、障害発生時に自動取引装置１２の内部の詳細な情報を取得して、自動的に障害復旧処理を実行する手段を設ける。自動復旧後は、リモート監視端末１８に対して、その処理結果を通知する。これにより、リモート監視端末１８側で、係員による確認作業ができる。即ち、各自動取引装置１２が、自動的に障害発生を検出して、自動的に障害復旧処理を起動し実行する。
【００２２】
（障害の検知）
自動取引装置１２は、入出金取引業務のための処理を実行する業務アプリケーション実行手段２６と、障害の監視と復旧のための処理を実行する監視アプリケーション実行手段２８とを備える。業務アプリケーション実行手段２６は、自動取引装置１２での入出金取引などの取引業務を実行する。取引業務の制御の際に障害が発生すると、監視アプリケーション実行手段２８に障害発生通知３０を送信する。同時に、障害を検出したときに得られた障害情報３４を監視アプリケーション実行手段２８に送信する。そして、監視アプリケーション実行手段２８からの通知を待つ。
【００２３】
監視アプリケーション実行手段２８は、常時、業務アプリケーション実行手段２６の動作を監視している。業務アプリケーション実行手段２６から障害発生通知３０を受信したら、障害復旧処理を自動的に開始する。例えば、自動取引装置１２の利用者６２が現金入出金処理中に、紙幣の繰り出し障害や紙幣切れ障害等が発生した場合に障害発生となる。
【００２４】
また、自動取引装置１２を誰も使用していないアイドル状態でも、障害が発生することがある。例えば、業務アプリケーション実行手段２６の誤動作や停止、システムリソースの不足、媒体不足、搬送ベルト劣化等については、監視アプリケーション実行手段２８が、自ら、所定の部位の情報を読み取って、障害の発生を検出する。監視アプリケーション実行手段２８が監視すべき所定の部位は、予め特定されている。例えば、装置各部のセンサの出力信号やカウンタの出力信号を記憶しておくための記憶領域を、一定時間おきに読み取って、障害の発生を検出する。
【００２５】
監視アプリケーション実行手段２８は、以上の障害検知のための処理を実行するために、障害検知手段４４を備える。また、障害が検出されると、情報収集手段４６により情報の収集が行われる。その後、情報解析手段４８により、復旧手順が選択され、復旧制御手段５０により、予め設定された自動復旧手順で復旧処理が実行される。自動復旧手順が設定されていない障害のときや、自動復旧に失敗したときには、係員に対して現場に出動するように要請する通信文を送信する。同時に、監視アプリケーション実行手段２８から業務アプリケーションに対して、係員に出動要請メッセージを送信した旨の通知をする。
【００２６】
（情報の収集）
業務アプリケーション実行手段２６は、障害発生通知３０とともに、監視アプリケーション実行手段２８に対して、所定の障害情報３４を送信する。ここで、予め設定された手順で自動復旧できる障害と、自動復旧できない障害とがある。監視アプリケーション実行手段２８に設けられた情報収集手段４６は、必要な情報を独自に収集し、情報解析手段４８は、収集した情報を独自に解析して、障害の種類を判断する。
【００２７】
例えば、情報収集手段４６は、障害発生以前の動作履歴を含む状態情報３２を収集する。自動取引装置１２本体の内部で収集できる状態情報３２は、装置に設けられた全てのセンサの出力信号や、カード挿入や現金投入等の各種イベントが発生したときの装置各部の全ての動作履歴等がある。自動的に収集する場合には、可能な限り広く情報を収集することが好ましい。例えば、障害検出時の装置各部の状態情報と、例えば、主要な媒体センサの状態遷移を取得して、全ての状態情報を時間軸で整合させて配列する。自動取引装置自身が装置内部で情報収集をするので、詳細で大量の情報を取得できる。これに、業務アプリケーションから出力されるエラーコードを含めれば、発生した障害を非常に正確に判断できる。
（情報の解析）
収集した情報全てを解析して、障害の種別を判断するプログラムの設計は容易ではない。全自動で確実に復旧できる障害の範囲は限定されるから、この範囲の障害かどうかだけを判断する機能を持てばよい。判断できる障害を一定の範囲に限定して、その他の障害は、種別不明として取り扱えば、処理が簡単で確実になる。このために、一定の範囲の障害を特定できるような障害識別パラメータ３６のリストを準備する。従来は業務アプリケーション実行手段からの報告を見て、係員が障害の種別を判断していた。障害の自動検出のために、既存の業務アプリケーションを書き換える必要はない。収集する状態情報と、障害識別パラメータ３６を十分なものに設定しておくだけでよい。
【００２８】
障害の検出には、取得した状態情報３２に、いずれかの障害識別パラメータ３６が含まれているかどうかを判定する。自動的に画一的に状態情報を収集するのが好ましい。状態情報３２には障害と無関係な情報が多数含まれていて構わない。障害識別パラメータ３６は、例えば、エラーコードと、特定の場所のセンサの出力や状態遷移と、特定のカウンタやレジスタの数値といった内容になる。即ち、エラーコードが「１１１」で、媒体出口側の媒体センサがＯＮ−ＯＦＦ−ＯＮと変化し、出力媒体数量が５で排出カウンタの数値が０というデータが状態情報に含まれていれば、該当する媒体が媒体出口で滞留しており、排出が完了していないという障害と判断される。その場合には、該当する媒体を５枚排出すれば障害が復旧できる。障害識別パラメータ３６の情報量が多ければ、それだけ正確に障害の種別を正確に判断できる。障害検出の対象となる自動取引装置１２は必ずしも全て同一の機種で、同一のメーカーのものとは限らない。各自動取引装置１２が機種毎に固有の障害パターンを有する場合でも、それらを区別できる障害識別パラメータ３６を準備しておけばよい。自動復旧できる障害の種類が増えたときには、障害識別パラメータ３６のリストを追加するだけでよいから、メンテナンスが非常に容易な効果がある。
【００２９】
（障害復旧手順の選択）
取得した状態情報３２に、いずれかの障害識別パラメータ３６が含まれていたときには、該当する障害復旧手順３８を選択して、復旧処理を実行させる。この制御のために、監視アプリケーション実行手段２８は、復旧制御手段５０を備える。復旧制御手段５０は、障害識別パラメータ３６と障害復旧手順３８を対応付けた自動処理テーブルを参照する。
【００３０】
図２は、自動処理テーブルの内容例説明図である。
例えば、図のように、取引区分が入金や出金といった種類では、自動取引装置側と金融機関のホストコンピュータ１９（図１）側の取引成立の可否、障害コード、装置内部の残留媒体の種類と有無、および、本人確認処理ができたかどうかという障害識別パラメータ３６により、障害復旧手順３８が決まる。障害復旧手順３８は、処理パターンＩＤで特定される。自動処理テーブル３９は、このように、障害識別パラメータ３６と障害復旧手順３８を対応付けるデータである。なお、障害復旧手順３８はコマンドの集合でもよいし、復旧処理プログラムを記述したものでもよい。
【００３１】
図３は、障害識別パラメータから障害復旧手順を得る処理の説明図である。
図に示すように、自動処理テーブル３９には、障害識別パラメータ３６と障害復旧手順３８とが対応付けられたデータがある。自動的に障害復旧処理をすることができるのはこれで全部である。従って、自動処理テーブル３９中の全ての障害識別パラメータ３６を順番に読み出して、自動取引装置の各部から収集した状態情報３２中に、いずれかの障害識別パラメータ３６が含まれているかどうか判断する。こうして、処理パターンＩＤを取得する。図の右側の処理パターンマスタから、各処理パターンＩＤに対して、実行すべきコマンドコードを順番に読み出すことができる。コマンドコードの内容は、図のコマンドマスタを参照する。障害復旧手順３８は、このように、コマンドの集合として取り出される。
【００３２】
復旧制御手段５０は、該当する障害復旧手順３８を読み出して、順番に装置各部にコマンドを送信し、復旧処理を実行する。障害復旧手順３８の中には、利用者６２に対するメッセージの出力処理も含まれるとよい。利用者６２に対して、障害の種別や障害復旧の手順、待機時間等の案内を出力することが好ましい。画面に文字で表示してもよいし、音声で出力するようにしてもよい。
【００３３】
障害復旧手順３８には、例えば、本人確認処理、勘定系への取引結果の取消要求送信、装置内部に残留した銀行カード等の媒体返却、障害復旧処理の完了報告といった処理が含まれる。これらの処理を全て自動的に実行する。また、自動的に実行しても、確実で問題が生じる心配の無い障害だけを、障害識別パラメータ３６のリストに含めるとよい。
【００３４】
（障害の種類と復旧方法）
障害の種類には、取引開始以前のアイドル状態で検出される障害と取引開始後に発生する障害がある。アイドル状態で検出される障害には、既に使用できない状態にあるものだけでなく、障害発生を予告すべき状態にあるものも含めることにする。取引開始後の障害には、銀行カードや現金等の取込前で発生した障害や銀行カードや現金等の取込後発生した障害などがある。前者の場合には、リセットをして最初から取引を開始できる状態に復旧できればよい。一方、後者の場合には、開始された取引がどこで中断したかを確認して、取引前の状態に戻す対応を行う。
【００３５】
生態認証や暗証番号による本人確認を実行して、その後、カードや入金紙幣を利用者６２に返還する。明細票（レシート）、出金紙幣は自動取引装置１２に回収し、最後にリセットして障害復旧させる。処理が完了後は、結果報告手段５６が処理結果報告３１を生成して、監視端末１８に送信する。
【００３６】
（係員の出動要求）
障害復旧の過程で、処理が正常に終了しないような場合には、自動復旧が困難と判断して、係員の出動要求メッセージ４１の送信をする。復旧制御手段５０による該当する障害復旧手順３８が正常に実行できないとき、情報収集手段４６が再び状態情報３２を収集してもよい。いわゆる2次障害が発生した場合である。この状態情報３２の中に新たな障害識別パラメータ３６が含まれていると判断されたら、新たな復旧制御手順３８を実行するとよい。情報収集手段４６が取得した状態情報３２に、予め用意したどの障害識別パラメータ３６も含まれていないと判定されたときには、想定外の障害として係員の出動要求処理を行う。即ち、出動要求手段５４が出動要求メッセージ４１を生成して、携帯端末１７に送信する。
【００３７】
誰も使用していないアイドル状態で、障害検知手段４４が復旧の必要な障害を検出することがある。例えば、搬送ベルト等の劣化、センサー異常等を検出したときである。このとき、情報収集手段４６が状態情報３２を収集する。情報解析手段４８がこの状態情報３２の中に障害識別パラメータ３６が含まれていると判断したとき、復旧制御手段５０は該当する復旧制御手順３８を実行する。
【００３８】
出動要求メッセージ４１には、収集した状態情報３２を含めるとよい。自動的に、出動要求メッセージ４１を生成して、該当する宛先に送信する。電話、ＦＡＸ、メール等の送信手段を利用するとよい。利用者６２による取引開始後の障害で、係員の出動要求処理を実行するときには、自動取引装置１２のディスプレイに待機依頼メッセージを表示し、あるいは、「間もなく係員がまいりますので暫くお待ち下さい」といった音声案内をする。上記の処理では、取得した状態情報３２に、限定された障害識別パラメータ３６が含まれているかどうかを判断するだけなので、きわめて迅速に係員の出動要求処理を実行できる。従って、利用者６２を長時間待たせないという効果がある。
【００３９】
誰も使用していないアイドル状態で、ただちに使用不能になるわけではないが、いずれ障害に至るような状態が検出されることがある。例えば、リソース（メモリーの空き領域）が一定値以下に減少したような場合が該当する。この場合には、リブートを実行すると自動的に健全な状態にモードすることができる。そこで、リソースが一定値以下に減少した状態を、障害識別パラメータに含めておく。そして、該当する障害復旧手順にはリブートを実行するコマンドを設定する。これで、利用時の障害発生を未然に防ぐことができる。
【００４０】
一方、使用する媒体、例えば、紙幣の量が減少して、ニアエンドの状態になったといった状態がある。この状態も、まだ取引が可能であって、ただちに使用不能になるわけではないが、いずれ障害に至るような状態である。こうした状態を予め設定しておき、装置の警戒レベルを示す情報とする。情報収集手段４６は、この警戒レベルを示す情報も状態情報３２に含めて収集する。
【００４１】
同時に、警戒レベルを示す情報を前記障害識別パラメータに含めておく。原則として、警戒レベルを障害と同様に取り扱う。該当する障害復旧手順は、警戒レベルを示す情報を含む出動要求メッセージ４１を生成して、復旧制御手段５０は、出動要求手段５４に対して、出動要求メッセージ４１の送信を依頼するという内容にする。この処理も、広い意味の障害復旧手順とすればよい。
【００４２】
なお、アイドル状態で、警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされたときには、すぐに係員の出動要求を実行せず、残りの装置の状態を比較する。記憶装置２２には、自機及び周辺の他の自動取引装置の装置稼働状態４２が記憶されている。装置稼働状態４２は、少なくとも、各装置が、取引可能な状態にあるか、メンテナンス中あるいは障害により取引できない状態にあるか、警戒レベルの状態にあるか等の情報を含むものとする。
【００４３】
例えば、５台の自動取引装置１２が設置された無人店舗で、１台の自動取引装置１２について障害が発生していても、残りの４台の装置が正常に動作できる場合がある。このときには、係員の出動要求処理を見合わせて、障害を検出した装置を使用できない状態にして待機させる。
【００４４】
もう１台、出動要求をすべき障害が発生したときには、係員の出動要求処理を実行する。また、次回の巡回点検スケジュールまでの時間が一定値以下の場合には、係員出動要求を見合わせる。これにより、係員の出動回数を減少させることができる。即ち、自機を含めた使用不可能な状態もしくは警戒レベルの状態の自動取引装置の合計台数が限界値を越えた場合に限り、出動要求手段５４に対して、出動要求メッセージの送信を依頼する。出動要求メッセージには、使用が不可能な状態の自動取引装置や、警戒レベルの状態の自動取引装置の情報を含める。
【００４５】
従来は、業務アプリケーションから監視端末側に送信されるエラーコードに基づいて、障害の種類を知り、監視員が自動取引装置にコマンドを送信して復旧操作をしていた。このとき、必要に応じて、自動取引装置から他の情報も取得して、復旧操作の方針を決定していた。監視対象として、様々な機種の自動取引装置が混在する場合も少なくない。従って、機種毎に復旧操作のためのマニュアルを準備して対応していた。
【００４６】
一方、本発明では、各自動取引装置がそれぞれ自動的に独自に復旧処理を実行する。即ち、全ての自動取引装置に自動復旧プログラムをインストールする。機種の異なる自動取引装置が混在する場合には、それぞれ自動復旧のための手順が異なることがある。しかし、機種毎にそれぞれ別々の自動復旧プログラムを作成していては、プログラム作成コストも管理コストも莫大になる。
【００４７】
そこで、本発明では、上記のように、障害が検知されると、無条件に画一的に装置各部の状態情報を取得するように制御する。そして、収集した状態情報の中に、障害識別パラメータが存在するかどうかを判断する。障害識別パラメータと障害復旧手順は機種毎に具体的に詳細に設定しておく。しかし、障害復旧を制御するための各プログラムは、ほぼ全ての機種に共通化することができる。従って、異なる機種の自動取引装置が混在する環境において、低コストで自動復旧プログラムを開発し監理運営することができる。以上が、本発明の概略説明である。以下、本発明の実施の形態を実施例毎に詳細に説明する。
【実施例１】
【００４８】
ここで、図１に示した各機能ブロックの基本的な機能を整理してから、具体的な動作の説明をする。業務アプリケーション実行手段２６は、金融機関において、現金の入出金取引に使用される装置であって、入出金取引業務のための処理を実行する機能を持つ。監視アプリケーション実行手段２８は、障害の監視と復旧のための処理を実行する機能を持つ。
【００４９】
障害検知手段４４は、業務アプリケーション実行手段２６から受信した障害発生通知３０を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する機能を持つ。情報収集手段４６は、障害発生以前の動作履歴を含む、装置の状態情報３２を収集する機能を持つ。記憶装置２２に記憶された障害識別パラメータは、装置で発生する障害の種別を認識するためのものである。
【００５０】
情報解析手段４８は、情報収集手段４６が収集した状態情報３２の中に、記憶装置２２に記憶された障害識別パラメータ３６が含まれているかどうかを判断する機能を持つ。復旧制御手段５０は、情報解析手段４８が、状態情報３２の中に障害識別パラメータが含まれていると判断したとき、記憶装置２２に記憶された該当する復旧制御手順を読み出して、その手順を実行する機能を持つ。
【００５１】
出動要求手段５４は、情報解析手段４８が、状態情報３２の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワーク１６を通じて係員の出動要求メッセージ４１を送信する機能を持つ。処理報告手段５６は、復旧制御手段５０または出動要求手段５４の処理結果報告３１をネットワーク１６を通じて送信する機能を持つ。
【００５２】
以上の装置は、障害識別パラメータにより自動復旧が可能と判断した障害について、記憶装置２２に記憶された該当する復旧制御手順に従って自動的に障害復旧処理をするので、監視端末１８側の負担を軽減できる。また、自動復旧できるものを限定しており、該当しない場合には直ちに係員の出動要求をするので、障害の診断から係員の出動要求までの時間を短縮して、利用者６２の待ち時間を少なくできる。さらに、個々の自動取引装置固有の障害がある場合には、その自動復旧手順も記憶させておくことができる。
【００５３】
なお、自動復旧処理に途中で失敗した場合に、再度新たな障害識別パラメータ３６が含まれているかどうかを判断するとよい。例えば、返却のため搬送中のカードや紙幣がうまく搬送されなかったとき、該当する障害識別パラメータが準備されていれば、対応する復旧手順を実行して、自動復旧を完結させることができる。
【実施例２】
【００５４】
図４から図８までは障害復旧処理のシーケンスチャートである。
ここでは、業務アプリケーション実行手段２６と監視アプリケーション実行手段２８とが連携して障害の復旧処理を実行する。ミドルウエア５８は、業務アプリケーション実行手段２６が自動取引装置１２の画面を制御するためのインタフェースに相当する機能を持つ。ミドルウエア５８は、また、自動取引装置１２の各部のハードウエアやセンサ等と業務アプリケーション実行手段２６とを制御するインタフェースである。ドライバに近い動作をする。ＡＰＬは、アプリケーション実行手段の略である。
【００５５】
図４〜８は、いずれも、上から下に向かって時間が経過するものとする。以下、時間の経過を追って、各部の動作を説明する。まず、ミドルウエア５８がセンサその他の信号を取得して、その内容から、障害検知がされる。図４では、ミドルウエア５８から業務アプリケーション実行手段２６に障害発生通知がされ、それが監視アプリケーション実行手段２８に伝達される。この部分の伝達情報の内容は任意である。障害が発生した旨の通知が監視アプリケーション実行手段２８に伝達されればよい。これを監視アプリケーション実行手段２８の障害検知手段４４が受信する。
【００５６】
図４は媒体を返却する障害自動復旧シーケンスチャートである。
例えば、入金取引を中止した際に、返却された紙幣の一部分を取り忘れて紙幣が残留しているといった情報が業務アプリケーション実行手段２６に通知される。業務アプリケーション実行手段２６は障害発生通知を監視アプリケーション実行手段２８に対して行う。
【００５７】
次に、監視アプリケーション実行手段２８の情報収集手段４６は情報収集を開始する。図４の例では、情報収集の一部を業務アプリケーション実行手段２６に依頼している。業務アプリケーション実行手段２６は、勘定データを取得し、取引ステータスを確認し、取引装置側での処理が正常に終了しているのか、勘定系のホストコンピュータ１９（図１）側での処理が成立しているのかといった情報を収集する。監視アプリケーション実行手段２８の復旧制御手段５０は、自機が障害で取引できない状態になったので、装置稼働状態４２の内容を変更する処理を実行する。
【００５８】
次に、認証処理手段５２が、障害発生後に自動取引装置１２の前で待機している利用者６２に対する認証処理を行う。処理内容は取引開始時の認証処理と全く同一である。従って、この処理も復旧制御手段５０が業務アプリケーション実行手段２６に依頼する。即ち、暗証入力用の画面を表示させ、暗証番号の入力を受け付ける。そして、残照電文を使用して暗証確認処理を実行する。認証処理が正常に終了すると、自動取引装置１２の画面に、障害が発生して復旧処理中である旨のメッセージ等（障害画面）を表示する。
【００５９】
認証処理が正常に終了した後、その結果が業務アプリケーション実行手段２６から監視アプリケーション実行手段２８に通知される。同時に業務アプリケーション実行手段２６から監視アプリケーション実行手段２８に対して、自動処理の要求と、取得した障害情報が送信される。図４の右下の部分で、監視アプリケーション実行手段２８の情報解析手段４８は、既に説明した自動処理テーブル３９を利用して、障害復旧手順３８を取得する。
【００６０】
図５は障害復旧手順が実行されるときのシーケンスチャートである。
次に図５の処理に進む。監視アプリケーション実行手段２８の復旧制御手段５０は、取得したコマンドを順番に発行する。例えば、この図では、始めに、紙幣を返却するというコマンドを発行する。同時に、自動取引装置１２の画面に、「紙幣が出ますのでお取り下さい」といったメッセージを表示するよう業務アプリケーション実行手段２６に指示する。コマンドは、監視アプリケーション実行手段２８から業務アプリケーション実行手段２６を介してミドルウエア５８に転送される。ミドルウエア５８は紙幣投入口を開いて利用者に紙幣を返却する。コマンドが正常に実行されたというコマンド応答が監視アプリケーション実行手段２８に返される。
【００６１】
次に、監視アプリケーション実行手段２８は、取引の結果を印刷した明細票（レシート）を回収するというコマンドを発行する。明細票回収についても、正常に実行された旨のコマンド応答が監視アプリケーション実行手段２８に返される。さらに、監視アプリケーション実行手段２８は、リセットをするというコマンドを発行する。リセットが正常に実行された旨のコマンド応答が監視アプリケーション実行手段２８に返される。
【００６２】
以上のような処理に続いて、監視アプリケーション実行手段２８の復旧制御手段５０は、これで自動障害復旧処理が完了したと判断して、自機が正常に動作できるというように、装置稼働状態４２を修正する。その後、業務アプリケーション実行手段２６に制御を返すため、自動処理応答をする。業務アプリケーション実行手段２６は、自動取引装置１２の画面を通常の取引画面にして表示する。また、監視アプリケーション実行手段２８の処理報告手段は、監視端末１８に対して、処理結果報告３１を送信する。図では、監視端末１８の表示画面の更新通知をしている。この画面の例は図９で説明する。
【００６３】
図６は利用者が離れた後の媒体を返却しない障害自動復旧シーケンスチャートである。
中段の取引ステータス確認処理までは、図４の場合と同様の処理が行われる。図４の例では、監視端末１８に対して、監視画面の更新のための更新通知が送信された。しかしながら、図６の場合は監視アプリケーションで監視端末への更新は不要と判断したため更新通知は送信していない。監視端末１８の操作画面上で、任意のタイミングで画面更新ボタンが押下げられると、画面の更新がされる。この場合、取引が成立しているが、出金全額の取り忘れが生じている。従って、まず、取引勘定を取消す処理を実行している。
【００６４】
その後、自動処理テーブルに含まれた該当する障害識別パラメータ３６により、障害復旧手順が出力された。紙幣を金庫に収納して戻し、明細票（レシート）を回収し、装置をリセットするというコマンドが順番に送信される。その流れは、図５で説明したとおりである。ここでは、詳細な図示は省略した。
【００６５】
なお、この例では、自動復旧処理が開始される前に、業務アプリケーション実行手段２６が取引の取消処理を実行している。これは、業務アプリケーション実行手段２６の既存の機能をそのまま利用したものである。監視アプリケーション実行手段２８が業務アプリケーション実行手段２６から障害通知を受信した後、状態情報を収集して、ただちに自動処理テーブルを利用した障害識別パラメータ３６の検索をして、取引取消しというコマンドを含む障害復旧手順を取得するようにして構わない。図６の後段の処理も、図５の後段の処理と同一であるから、一部図示を省略し、具体的な説明も省略する。
【００６６】
図７は、出動要求をする場合のシーケンスチャートである。
自動処理テーブルを利用して障害復旧手順を取得し、監視アプリケーション実行手段２８の復旧制御手段５０が、該当するコマンドを送出するところまでは、図６の例と変わらない。ここで、ミドルウエア５８がそのコマンドを受け付けたところ、何らかの原因で、いずれかのコマンドに対する処理に失敗したとする。
【００６７】
この例では自動復旧処理において紙幣の収納、明細票（レシート）の回収あるいはリセット処理に失敗したということになる。このときは、ミドルウエア５８から監視アプリケーション実行手段２８に対し障害復旧処理に失敗したというコマンド応答が送信される。この場合には監視アプリケーション実行手段２８から業務アプリケーション実行手段２６に対し障害復旧失敗の応答がなされる。同時に監視アプリケーション実行手段２８の出動要求手段５４から携帯端末１７に対して、出動要求メッセージ４１がネットワーク１６を通じて送信される。
【００６８】
図８は、出動要求メッセージ送信後のシーケンスチャートである。
監視アプリケーション実行手段２８から監視端末１８に対し画面の更新通知が行われる。監視端末１８では監視画面を更新する。また、業務アプリケーション実行手段２６は自動取引装置の画面に、出動要求中という案内表示を行う。利用者に、障害復旧中で取引出来ない状態にあることを伝えるためである。また、出動要求メッセージ４１を送信すると、係員からの返信によって到着予定時刻が通知される。それが監視アプリケーション実行手段２８から業務アプリケーション実行手段２６に送信される。業務アプリケーション実行手段２６は自動取引装置の画面に、係員の到着予定時刻を表示する。
【００６９】
即ち、係員の予定時間を示す画面を表示する。同時に監視アプリケーション実行手段２８は監視端末１８に対し係員の到着予定時刻を通知して、監視端末１８の監視画面が更新される。係員が現場に到着すると、自動取引装置を点検モードにする。ミドルウエア５８はこのタイミングで、係員の入店検知を行い、自動的に入店通知が業務アプリケーション実行手段２６に送信される。
【００７０】
入店通知は業務アプリケーション実行手段２６から監視アプリケーション実行手段２８に送信され、さらに、監視アプリケーション実行手段２８から監視端末１８に送信される。これで、監視端末１８の監視画面が更新される。即ち、監視端末１８では現在係員が障害復旧処理中という内容の画面が表示される。その後、障害が除去されて、係員が自動取引装置を点検モードから通常モードに切り替えると、ミドルウエア５８はそのタイミングで退店を検知する。退店通知は業務アプリケーション実行手段２６を経由して監視アプリケーション実行手段２８に送信され、監視端末１８に転送されて監視画面が更新される。また、自動取引装置の画面が正常の取引画面に戻る。
【００７１】
図９は監視端末１８の表示画面の具体例説明図である。
図１に示した監視端末１８には、例えば、図９に示したような画面が表示される。これを監視員６０が監視することにより、無人店舗等において、障害が発生した自動取引装置とその自動復旧処理の状況を常時確認できる。即ち、自動取引装置を設置した各店舗についてその障害の発生時刻、係員に対する出動要求をした依頼時刻などが表示されている。
【００７２】
この内容は、既に図４〜図８のシーケンスチャートで説明したとおり、監視対象の自動取引装置の状態変化に応じて時々刻々と更新される。従来は障害が発生するとその自動取引装置からの通知を受けて係員が対応していた。この発明では、図に示すような画面に、各装置が自動的に障害を復旧しあるいは自動的に係員に出動要求をした状態が一覧表示される。
【００７３】
図１０は出動の各状態が起きた時刻、障害からの復旧時刻を示す画面である。
これも監視端末１８に表示される。図に示すように、障害が発生した自動取引装置について、係員が到着する予定時刻、入店時刻、退店時刻、障害復旧処理が完了して自動取引装置が取引可能な状態なった時刻などが一覧で表示されるようになっている。これにより、監視対象が増加した場合でも、監視端末１８側の係員は、自動復旧処理が出来ないものにだけ対応をすればよいので、負荷が軽減される。また、自動復旧できるかどうかの判断が早いので、すみやかに係員の出動要求ができ、顧客を長時間待たせないで、サービスの向上が図れる。
【００７４】
図１１以下は装置の具体的な動作フローチャートである。
図１１と図１２は障害検出動作を示すメインルーチンである。業務アプリケーション実行手段２６と監視アプリケーション実行手段２８の動作を特に区別しないで説明する。これらの間の処理のシーケンスは図４等で説明したとおりである。まず、ステップＳ１１では、装置各部からの障害通知を受信する待ち受け状態にある。ステップＳ１２で、障害検知手段４４が障害発生通知を受けると、ステップＳ１３で取引装置の画面の切り替えを実行する。
【００７５】
次に、情報収集手段４６が、ステップＳ１４でホストコンピュータからの情報を収集する。即ち、ホストコンピュータから取引成否の情報を取得する。障害通知を受信すると同時に、障害情報を受信することができる。さらにどのような情報を収集すべきか判断をしなくてもよい。予め定められた範囲の情報を収集するとよい。情報解析手段４８は、収集した情報の中に、障害識別パラメータ３６と一致しているものが含まれるかどうかを判断する。
【００７６】
次に、認証処理手段５２は、認証処理を開始する。ステップＳ１５で暗証入力画面を表示しステップＳ１６で暗証入力を待つ。ステップＳ１７で暗証入力を検知するとステップＳ１８でその入力データに基づきホストコンピュータに暗証確認を行う。ここで本人確認のための認証が終了するとステップＳ１９において、自動取引装置の画面に障害を自動的に復旧する旨のメッセージを表示する。ここから、復旧制御手段５０による障害復旧処理が開始される。
【００７７】
ステップＳ２０において本人確認が正常に終了したかどうかを判断する。本人確認が正常終了した場合にはステップＳ２１に進み、それ以外の場合には、ステップＳ３１へ進む。ステップＳ２１で、障害復旧手順に基づいて、ホストコンピュータにおける取引の成否について修正処理を実行する。さらに、ステップＳ２２から、復旧のためのコマンドにより修正処理が実行される。取引修正処理ができない場合には、ステップＳ３１へ進む。
【００７８】
ステップＳ２３〜２５で、復旧指示のためのコマンドを送信し、応答を待ち、コマンドが正常に処理されたかどうか応答を検知する。そして、ステップＳ２６で、応答が正常かどうかを判断して、正常な場合には、障害復旧処理が完了したとして、ステップＳ２７に進む。ステップＳ２７では、自動取引装置の画面を切り替えて、通常の取引画面に戻す。
【００７９】
ステップＳ２０で本人確認に失敗した場合と、ステップＳ２２で取引修正ができない場合と、ステップＳ２６で処理に失敗をした旨のコマンドの応答があったときは、ステップＳ３１に進む。ステップＳ３１以下は、出動要求手段５４よる係員の出動要求処理である。
【００８０】
図１３は出動要求処理の動作フローチャートである。
出動要求手段５４はステップＳ３２において警備端末から、あるいは係員かセンタから係員到着予定時刻の入力を待つ。ステップＳ３３で到着予定時刻の入力が検知されると、ステップＳ３４でＡＴＭの画面に到着予定時間を表示する。ステップＳ３５では係員の入店通知を待ち、ステップＳ３６で入店を検知するとステップＳ３７でその結果を取得する。そして、ステップＳ３８で、監視端末１８に係員が入店したことを示す画面を表示する。
【００８１】
ステップＳ３９では係員の退店通知を待ち、ステップＳ４０で退店を検知するとステップＳ４１でその結果を取得する。ステップＳ４２では係員が退店した旨の画面を、監視端末１８に表示する。これで、自動取引装置が復旧したから、ステップＳ４２で、自動取引装置を取引可能な状態の画面に戻す。
【００８２】
図１４は障害復旧処理動作の具体的なフローチャートである。
ステップＳ５１で自動復旧処理の要求を待つ。ステップＳ５２で自動復旧処理の要求を検知すると、復旧制御手段５０はその状態を監視端末１８に通知する。そして、ステップＳ５４で装置稼働状態４２の内容を更新する。ここで情報収集手段４６が必要な情報を収集し、ステップＳ５５で情報解析手段４８が障害識別パラメータ３６を利用して対応する障害復旧手順３８を検索する。ステップＳ５７で、取得された障害復旧手順３８から復旧処理のためのコマンドが生成される。
【００８３】
ステップＳ５８では該当するコマンドがミドルウエア５８に送信される。ステップＳ５９でミドルウエア５８からの応答を待ち、ステップＳ６０で応答を検知すると、ステップＳ６１の判断をする。送信したコマンドに対し正常な応答が返ってきた場合には次のコマンドを送信する。ステップＳ６２で全てのコマンドの送信が終了されたかどうかを判断する。残りのコマンドがあれば、ステップＳ５８からステップＳ６０の処理が繰り返される。
【００８４】
図１５は、係員の出動要求の前半処理フローチャートである。
復旧制御手段５０は、該当する障害復旧手順３８が障害復旧手順３８を正常に実行できないとき、出動要求手段５４に対して、出動要求メッセージ４１の送信を依頼する。即ち、いずれかのコマンドの応答が正常でない場合にはステップＳ６１からステップＳ７０に進み係員の出動要求処理に進む。全てのコマンドが送信され正常に応答がされた場合には、ステップＳ６３において監視アプリケーション実行手段２８から業務アプリケーション実行手段２６に対して、正常に復旧処理が終了した旨の通知が行われる。その後、ステップＳ６４で、自動取引装置の状態を更新し、装置稼働状態４２に記録する。
【００８５】
ステップＳ７０で自動処理のコマンド処理に失敗したと判断された場合には、ステップＳ７１で自動取引装置のステータスを更新し、ステップＳ７２で装置稼働状態４２を更新する。また、ステップＳ７３で出動要求手段５４が出動要求メッセージを送信しステップＳ７４で係員の到着予定時刻の通知を待つ。ステップＳ７５と７６で装置稼働状態４２を更新する。ステップＳ７７で到着予定時刻の通知を検知すると、ステップＳ７８と７９で装置稼働状態４２を更新する。これで、係員の入店待ちの状態になる。
【００８６】
図１６は係員の出動要求の後半処理フローチャートである。
ステップＳ８０で係員の到着予定時刻が監視アプリケーション実行手段２８から業務アプリケーション実行手段２６に通知される。ステップＳ８１では業務アプリケーション実行手段２６から監視アプリケーション実行手段２８への係員の入店通知を待つ。ステップＳ８２で入店通知を検知するとステップＳ８３で、装置稼働状態を更新することを、監視端末１８に通知する。ステップＳ８４で装置稼働状態４２を更新しステップＳ８５に進む。
【００８７】
ステップＳ８５で入店通知を受け付けて、ステップＳ８６で退店通知を待つ状態になる。ステップＳ８７で退店通知を受信すると、ステップＳ８７で警備センタに対し退店通知を送信する。これは警備センタにおける係員の業務管理に利用される。ステップＳ８９では装置稼働状態を更新する通知を監視端末１８に送信する。ステップＳ９０で装置稼働状態４２を更新する。これで、自動取引装置は取引可能な状態に復旧する。
【実施例３】
【００８８】
図１７は実施例３の動作フローチャートである。
利用者の取引中や取引終了直後には、上記の実施例のような障害が検知される。一方、既に説明したように、アイドル状態で障害を検出することもできる。障害検知手段４４は、例えば、ステップＳ１１１で一定時間毎に自機の状態を診断する。ステップＳ１１２では、その結果を装置稼働状態４２に記録する。ステップＳ１１３で、アイドル状態で障害を検出したかどうかを判断する。障害を検出しない場合には、ステップＳ１１１からステップＳ１１３までの処理を繰り返す。
【００８９】
アイドル状態で障害を検出したら、ステップＳ１１３からステップＳ１１４に進む。ステップＳ１１４では、状態情報に警戒レベル情報が含まれているかどうかを判断する。ここでは、自動復旧可能な障害かどうかを判断している。状態情報に警戒レベル情報が含まれているときには、ステップＳ１１７に進み、出動要求メッセージを送信する。出動要求メッセージの中には、警戒レベルを示す情報を含める。これは既に説明したとおりである。
【００９０】
ステップＳ１１４で、自動的に復旧できる障害と判断すると、ステップＳ１１５に進み、該当する障害復旧手順を実行する。ステップＳ１１６で、障害が復旧したかどうかを判断し、復旧していれば、処理を終了する。復旧しなければ、ステップＳ１１７に進み、出動要求メッセージを送信する。
【実施例４】
【００９１】
図１８は実施例４の動作フローチャートである。
実施例３のステップＳ１１６で、自動復旧制御に失敗をしたと判断すると、出動要求メッセージを送信した。また、図１７のステップＳ１１４で、状態情報に警戒レベル情報が含まれていると判断したときには、警戒レベルを示す情報を含む出動要求メッセージを送信した。しかしながら、ただちに係員を出動させなくてもよい場合がある。同じ無人店舗に対して、短時間の間に２度出動をするというケースがあると無駄である。また、係員は保守点検のために、無人店舗を定期的に巡回している。それも考慮すべきである。
【００９２】
そこで、図１８のステップＳ１２１において、アイドル状態で、出動要求メッセージを送信するという判断がなされたとき、ステップＳ１２２以下の処理をする。ステップＳ１２２では、近接して配置された他の全ての自動取引装置が、使用可能な状態か使用不可能な状態か警戒レベルの状態かを示すデータを取得する。記憶装置２２の装置稼働状態４２を参照すればよい。そして、ステップＳ１２３で、自機を含めた使用不可能なものや警戒レベルの自動取引装置の合計台数をカウントする。
【００９３】
無人店舗等で、近接して複数台の自動取引装置が配置されているときに、例えば、１台だけなら、使用不可能な状態のまま、あるいは警戒レベルのまま少しの間放置しても良い場合がある。このとき、ただちに出動要求メッセージ４１を送信せずに待機する。これで、出動要求の頻度を低下させられる。ステップＳ１２３では、例えば、５台中２台以上使用不能になったときに出動要求をする。
【００９４】
即ち、ステップＳ１２４で、この台数が、限界値、例えば、２台を越えたと判断したときには、ステップＳ２６で、出動要求メッセージ４１を送信する。しかし、例えば、巡回予定が短時間後に迫っているような場合にも、すぐに出動要求をする必要はない。そこで、ステップＳ１２５で、次回の巡回は近時か、例えば、当日中に必ず巡回があるかを判断する。この判断がノーの場合には、出動要求メッセージ４１を送信する。出動要求メッセージ４１には、自機と周辺の装置の装置稼働状態４２を含めるとよい。それ以外の場合には、自機を使用不可能な状態にして待機させる。
【００９５】
上記のように一部の自動取引装置が使用不能になった店舗の状態は、既に図９で説明したように、監視端末の画面で確認することができる。従って、巡回をする係員は、店舗に到着すると、ただちに該当する自動取引装置の障害復旧処理を開始する。これで、出動をする係員の負担を軽減できる。従って、大規模な監視センタを必要としないという効果がある。また、各自動取引装置が詳細な状態情報を収集するので、必要に応じて監視端末側へ転送すれば、詳細な情報把握により、その後の障害復旧率の向上を図ることができる。
【００９６】
なお、上記の演算処理装置で実行されるコンピュータプログラムは、機能ブロックで図示した単位でモジュール化されてもよいし、複数の機能ブロックを組み合わせて一体化されてもよい。また、上記のコンピュータプログラムは、既存のアプリケーションプログラムに組み込んで使用してもよい。本発明を実現するためのコンピュータプログラムは、例えばＣＤ−ＲＯＭのようなコンピュータで読み取り可能な記録媒体に記録して、インストールして利用することができる。
【符号の説明】
【００９７】
１２ 自動取引装置
１４ 内部ＬＡＮ
１６ ネットワーク
１７ 携帯端末
１８ 監視端末
１９ ホストコンピュータ
２０ 管理データ記憶装置
２２ 記憶装置
２４ 演算処理装置
２６ 業務アプリケーション実行手段
２８ 監視アプリケーション実行手段
３０ 障害発生通知
３１ 処理結果報告
３２ 状態情報
３４ 障害情報
３６ 障害識別パラメータ
３８ 障害復旧手順
３９ 自動処理テーブル
４０ 巡回予定データ
４１ 出動要求メッセージ
４２ 装置稼働状態
４４ 障害検知手段
４６ 情報収集手段
４８ 情報解析手段
５０ 復旧制御手段
５２ 認証処理手段
５４ 出動要求手段
５６ 結果報告手段
５８ ミドルウエア
６０ 監視員
６２ 利用者
【技術分野】
【０００１】
本発明は、障害が発生したときに、復旧のための各種処理を自動的に実行する機能を持つ自動取引装置に関する。
【背景技術】
【０００２】
金融機関で使用されている自動取引装置（ＡＴＭ）は、その普及とともに性能が向上し、信頼性も著しく向上している。無人運転されるものも多く、障害の発生頻度は、数千回の取引をして１回程度という状況にある。従来は、無人店舗で自動取引装置に障害が発生した場合には、ネットワークを通じて監視サーバに通報が届く。監視サーバ側では、届いた障害情報を監視サーバに接続した端末に表示する。専任の係員が端末に表示した障害情報を確認して利用者と電話連絡しながら対処する。可能な場合にはリモート操作で復旧を試みて、回復しないときには、現場に係員を出動させる。係員は、診断プログラム等を起動して、復旧処理を実行する（特許文献１参照）（特許文献２参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９−１０４２６６号公報
【特許文献２】特開２００３−２９６７９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
既知の従来の技術には、次のような解決すべき課題があった。
自動取引装置の性能向上により、リモート操作で復旧するような簡単な障害は減少し、希に発生する障害は、係員が現場に出動しなければならないような種類のものが多い。このような、障害の発生時には、利用者を長時間待たせることなく、迅速に出動要請の要否を判断することが望まれる。更に、監視サーバや端末類を設置するので、監視システムへの投資や専任係員が必要である。規模の大きな金融機関では、何台もの監視サーバ等を設置し、多くの専任係員を配置するので、多額のコストが掛かるという問題があった。また、自動取引装置と監視サーバ間の通信が通信障害で途絶えると、リモート操作による障害対応が行えないという問題もある。
上記の課題を解決するために、本発明は次のような自動取引装置を提供することを目的とする。
（１）自動取引装置が、自動的に障害復旧のための処理を実行する。
（２）必要な場合にすみやかに係員の出動要請を自動的に実行する。
（３）自動復旧処理により、専任係員の負担を軽減し、監視コストを低減する。
【課題を解決するための手段】
【０００５】
以下の構成はそれぞれ上記の課題を解決するための手段である。
〈構成１〉
金融機関において、現金の入出金取引に使用される装置であって、入出金取引業務のための処理を実行する業務アプリケーション実行手段と、障害の監視と復旧のための処理を実行する監視アプリケーション実行手段とを備え、前記業務アプリケーション実行手段から受信した障害発生通知を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する障害検知手段と、障害発生以前の動作履歴を含む、装置の状態情報を収集する情報収集手段と、装置で発生する障害の種別を認識するための障害識別パラメータと、該当する種別の障害に対する障害復旧手順を記憶する記憶装置と、前記情報収集手段が収集した状態情報の中に、前記記憶装置に記憶された障害識別パラメータが含まれているかどうかを判断する情報解析手段と、前記情報解析手段が、前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記記憶装置に記憶された該当する復旧制御手順を読み出して、その手順を実行する復旧制御手段と、前記情報解析手段が、前記状態情報の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワークを通じて係員の出動要求メッセージを送信する出動要求手段と、復旧制御手段または出動要求手段の処理結果報告をネットワークを通じて、送信する処理報告手段を備えたことを特徴とする自動取引装置。
【０００６】
〈構成２〉
構成１に記載の自動取引装置において、前記復旧制御手段による該当する障害復旧手順が正常に実行できないとき、前記情報収集手段は再び状態情報を収集し、前記情報解析手段が前記状態情報の中に新たな障害識別パラメータが含まれていると判断したとき、前記復旧制御手段は該当する復旧制御手順を実行することを特徴とする自動取引装置。
【０００７】
〈構成３〉
構成１または２に記載の自動取引装置において、前記復旧制御手段は、該当する障害復旧手順が正常に実行できないとき、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。
【０００８】
〈構成４〉
構成１乃至の３いずれかに記載の自動取引装置において、自動取引装置固有の障害を示す障害識別パラメータとその障害復旧手順を前記記憶装置に記憶したことを特徴とする自動取引装置。
【０００９】
〈構成５〉
構成１乃至４のいずれかに記載の自動取引装置において、誰も使用していないアイドル状態で、前記障害検知手段が復旧の必要な障害を検出したときには、前記情報収集手段が状態情報を収集し、前記情報解析手段が前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記復旧制御手段は該当する復旧制御手順を実行することを特徴とする自動取引装置。
【００１０】
〈構成６〉
構成５に記載の自動取引装置において、リソース（メモリーの空き領域）が一定値以下に減少した場合を、前記障害識別パラメータに含めておき、該当する障害復旧手順は、リブートを実行するとしたことを特徴とする自動取引装置。
【００１１】
〈構成７〉
構成５に記載の自動取引装置において、使用する媒体量の減少を含む、予め設定された装置の警戒レベルを示す情報を、前記情報収集手段が収集する状態情報に含め、前記警戒レベルを示す情報を前記障害識別パラメータに含めておき、該当する障害復旧手順は、前記警戒レベルを示す情報を含む出動要求メッセージを生成して、前記出動要求手段に対して、出動要求メッセージの送信を依頼するとしたことを特徴とする自動取引装置。
【００１２】
〈構成８〉
構成５乃至７のいずれかに記載の自動取引装置において、自動復旧制御に失敗をしたとき、もしくは、前記警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされたとき、前記復旧制御手段は、近接して配置された他の全ての自動取引装置が、使用可能な状態か使用不可能な状態か警戒レベルの状態かを示す装置稼働状態を取得し、自機を含めた使用不可能な状態もしくは警戒レベルの状態の自動取引装置の合計台数が限界値を越えた場合に限り、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。
【００１３】
〈構成９〉
構成５乃至７のいずれかに記載の自動取引装置において、自動復旧制御に失敗をしたとき、もしくは、前記復旧制御手段は、警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされた場合に、記憶装置に記憶されている巡回予定データを参照して、係員による巡回時までの時間が一定値以上の場合に限り、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。
【００１４】
〈構成１０〉
金融機関において、現金の入出金取引に使用される装置のコンピュータを、入出金取引業務のための処理を実行する業務アプリケーション実行手段と、障害の監視と復旧のための処理を実行する監視アプリケーション実行手段とを備え、前記業務アプリケーション実行手段から受信した障害発生通知を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する障害検知手段と、障害発生以前の動作履歴を含む、装置の状態情報を収集する情報収集手段と、装置で発生する障害の種別を認識するための障害識別パラメータと、該当する種別の障害に対する障害復旧手順を記憶する記憶装置と、前記情報収集手段が収集した状態情報の中に、前記記憶装置に記憶された障害識別パラメータが含まれているかどうかを判断する情報解析手段と、前記情報解析手段が、前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記記憶装置に記憶された該当する復旧制御手順を読み出して、その手順を実行する復旧制御手段と、前記情報解析手段が、前記状態情報の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワークを通じて係員の出動要求メッセージを送信する出動要求手段と、復旧制御手段または出動要求手段の処理結果報告をネットワークを通じて、送信する処理報告手段、として機能させる自動取引装置制御プログラム。
【００１５】
〈構成１１〉
構成１０に記載の自動取引装置制御プログラムを記録したコンピュータで読み取り可能な記録媒体。
【発明の効果】
【００１６】
〈構成１の効果〉
障害識別パラメータにより自動復旧が可能と判断した障害について、記憶装置に記憶された該当する復旧制御手順に従って自動的に障害復旧処理をするので、監視端末側の負担を軽減できる。さらに障害の種別によっては、係員が対応するよりも素早く的確に復旧ができる。また、障害の診断から係員の出動要求までの時間を短縮して、利用者の待ち時間を少なくできる。
〈構成２の効果〉
障害復旧手順を実行中に障害復旧に失敗することがある。このとき、再度状態情報を収集して、自動復旧を試みることができる。新たな障害識別パラメータが見つかれば、別の障害復旧手順を実行できる。
〈構成３の効果〉
自動復旧制御に失敗をしたときに、自動的に出動要求メッセージを送信して、迅速に係員を派遣できる。
〈構成４の効果〉
自動取引装置の内部に監視アプリケーション実行手段を設けるので、それぞれ機種の異なる自動取引装置について、固有の障害も自動的に復旧できる。
〈構成５の効果〉
誰も使用していないアイドル状態で復旧の必要な障害を検出したときには、自動的に復旧処理を実行する。
〈構成６の効果〉
リソースが減少すると、その後障害が発生する確率が高いので、これを障害発生と判断して、自動復旧させる。従って、利用時の障害発生を未然に防ぐことができる。
〈構成７の効果〉
紙幣等の媒体量の減少を示す情報を、警戒レベルを示す情報と呼ぶとき、この情報が状態情報に含まれている場合には、警戒レベルを示す情報を含む出動要求メッセージを生成する。その後、所定のタイミングで自動的に出動要求メッセージの送信を依頼する。
〈構成８の効果〉
無人店舗等で、近接して複数台の自動取引装置が配置されているときに、例えば、１台だけなら、使用不可能な状態あるいは警戒レベルの状態のままでも良い場合がある。このとき、ただちに出動要求メッセージを送信せずに待機する。これで、出動要求の頻度を低下させられる。
〈構成９の効果〉
間もなく次回の巡回があるような場合には、出動要請を見合わせることができる。
【図面の簡単な説明】
【００１７】
【図１】本発明の自動取引装置の具体例を示す概略機能ブロック図である。
【図２】自動処理テーブルの内容例説明図である。
【図３】障害識別パラメータから障害復旧手順を得る処理の説明図である。
【図４】障害発生時に利用者に媒体を返却する自動処理の例である。
【図５】障害復旧手順が実行されるときのシーケンスチャートである。
【図６】利用者が離れた後の障害自動復旧シーケンスチャートである。
【図７】出動要求をする場合のシーケンスチャートである。
【図８】出動要求メッセージ送信後のシーケンスチャートである。
【図９】監視端末１８の表示画面の具体例説明図である。
【図１０】出動時刻や障害からの復旧時刻を示す画面である。
【図１１】障害検出動作を示すメインルーチンである。
【図１２】障害復旧動作を示すメインルーチンである。
【図１３】出動要求処理の動作フローチャートである。
【図１４】障害復旧処理動作の具体的なフローチャートである。
【図１５】係員の出動要求の前半処理フローチャートである。
【図１６】係員の出動要求の後半処理フローチャートである。
【図１７】実施例３の動作フローチャートである。
【図１８】実施例４の動作フローチャートである。
【発明を実施するための形態】
【００１８】
図１は、本発明の自動取引装置の具体例を示す概略機能ブロック図である。
図に示す例では、金融機関のある無人店舗に、４台の自動取引装置１２（ＡＴＭ）が内部ＬＡＮ１４を介して配置されている。そのうちの一台について、図の右側の一点鎖線の円内にその機能ブロックを図示した。例えば、４台の自動取引装置１２は、互いに内部ＬＡＮ１４により接続されている。そして、全ての自動取引装置１２が、図の一点鎖線の円内の構成を備えるものとする。
【００１９】
自動取引装置１２は、ネットワークインタフェースを介してネットワーク１６に接続されている。ネットワーク１６には、自動取引装置１２を遠隔監視するために、監視端末１８が接続されている。監視端末１８は監視員６０により操作される。監視員６０は、自動取引装置１２の状態を監視して、必要に応じて、障害の復旧処理を実行する。監視端末１８には、情報を記憶するために、管理データ記憶装置２０が接続されている。また、障害復旧のために出動する係員は、携帯端末１７を所持している。携帯端末１７には、ネットワーク１６を通じて出動要求メッセージ４１が届く構成になっている。
【００２０】
自動取引装置１２は利用者６２により利用される。自動取引装置１２を動作させるために、記憶装置２２と演算処理装置２４とが設けられている。記憶装置２２は障害発生通知３０、処理結果報告３１、状態情報３２、障害情報３４、障害識別パラメータ３６、障害復旧手順３８、巡回予定データ４０、出動要求メッセージ４１、装置稼働状態４２等を記憶する。演算処理装置２４は、業務アプリケーション実行手段２６、監視アプリケーション実行手段２８等の機能ブロックを有する。監視アプリケーション実行手段２８は、障害検知手段４４、情報収集手段４６、情報解析手段４８、復旧制御手段５０、認証処理手段５２、出動要求手段５４、結果報告手段５６等を含んでいる。
【００２１】
本発明では、金融機関等で使用され、現金の入出金取引に使用される自動取引装置１２に対して、障害の自動復旧のための各種機能を付与する。このために、障害発生時に自動取引装置１２の内部の詳細な情報を取得して、自動的に障害復旧処理を実行する手段を設ける。自動復旧後は、リモート監視端末１８に対して、その処理結果を通知する。これにより、リモート監視端末１８側で、係員による確認作業ができる。即ち、各自動取引装置１２が、自動的に障害発生を検出して、自動的に障害復旧処理を起動し実行する。
【００２２】
（障害の検知）
自動取引装置１２は、入出金取引業務のための処理を実行する業務アプリケーション実行手段２６と、障害の監視と復旧のための処理を実行する監視アプリケーション実行手段２８とを備える。業務アプリケーション実行手段２６は、自動取引装置１２での入出金取引などの取引業務を実行する。取引業務の制御の際に障害が発生すると、監視アプリケーション実行手段２８に障害発生通知３０を送信する。同時に、障害を検出したときに得られた障害情報３４を監視アプリケーション実行手段２８に送信する。そして、監視アプリケーション実行手段２８からの通知を待つ。
【００２３】
監視アプリケーション実行手段２８は、常時、業務アプリケーション実行手段２６の動作を監視している。業務アプリケーション実行手段２６から障害発生通知３０を受信したら、障害復旧処理を自動的に開始する。例えば、自動取引装置１２の利用者６２が現金入出金処理中に、紙幣の繰り出し障害や紙幣切れ障害等が発生した場合に障害発生となる。
【００２４】
また、自動取引装置１２を誰も使用していないアイドル状態でも、障害が発生することがある。例えば、業務アプリケーション実行手段２６の誤動作や停止、システムリソースの不足、媒体不足、搬送ベルト劣化等については、監視アプリケーション実行手段２８が、自ら、所定の部位の情報を読み取って、障害の発生を検出する。監視アプリケーション実行手段２８が監視すべき所定の部位は、予め特定されている。例えば、装置各部のセンサの出力信号やカウンタの出力信号を記憶しておくための記憶領域を、一定時間おきに読み取って、障害の発生を検出する。
【００２５】
監視アプリケーション実行手段２８は、以上の障害検知のための処理を実行するために、障害検知手段４４を備える。また、障害が検出されると、情報収集手段４６により情報の収集が行われる。その後、情報解析手段４８により、復旧手順が選択され、復旧制御手段５０により、予め設定された自動復旧手順で復旧処理が実行される。自動復旧手順が設定されていない障害のときや、自動復旧に失敗したときには、係員に対して現場に出動するように要請する通信文を送信する。同時に、監視アプリケーション実行手段２８から業務アプリケーションに対して、係員に出動要請メッセージを送信した旨の通知をする。
【００２６】
（情報の収集）
業務アプリケーション実行手段２６は、障害発生通知３０とともに、監視アプリケーション実行手段２８に対して、所定の障害情報３４を送信する。ここで、予め設定された手順で自動復旧できる障害と、自動復旧できない障害とがある。監視アプリケーション実行手段２８に設けられた情報収集手段４６は、必要な情報を独自に収集し、情報解析手段４８は、収集した情報を独自に解析して、障害の種類を判断する。
【００２７】
例えば、情報収集手段４６は、障害発生以前の動作履歴を含む状態情報３２を収集する。自動取引装置１２本体の内部で収集できる状態情報３２は、装置に設けられた全てのセンサの出力信号や、カード挿入や現金投入等の各種イベントが発生したときの装置各部の全ての動作履歴等がある。自動的に収集する場合には、可能な限り広く情報を収集することが好ましい。例えば、障害検出時の装置各部の状態情報と、例えば、主要な媒体センサの状態遷移を取得して、全ての状態情報を時間軸で整合させて配列する。自動取引装置自身が装置内部で情報収集をするので、詳細で大量の情報を取得できる。これに、業務アプリケーションから出力されるエラーコードを含めれば、発生した障害を非常に正確に判断できる。
（情報の解析）
収集した情報全てを解析して、障害の種別を判断するプログラムの設計は容易ではない。全自動で確実に復旧できる障害の範囲は限定されるから、この範囲の障害かどうかだけを判断する機能を持てばよい。判断できる障害を一定の範囲に限定して、その他の障害は、種別不明として取り扱えば、処理が簡単で確実になる。このために、一定の範囲の障害を特定できるような障害識別パラメータ３６のリストを準備する。従来は業務アプリケーション実行手段からの報告を見て、係員が障害の種別を判断していた。障害の自動検出のために、既存の業務アプリケーションを書き換える必要はない。収集する状態情報と、障害識別パラメータ３６を十分なものに設定しておくだけでよい。
【００２８】
障害の検出には、取得した状態情報３２に、いずれかの障害識別パラメータ３６が含まれているかどうかを判定する。自動的に画一的に状態情報を収集するのが好ましい。状態情報３２には障害と無関係な情報が多数含まれていて構わない。障害識別パラメータ３６は、例えば、エラーコードと、特定の場所のセンサの出力や状態遷移と、特定のカウンタやレジスタの数値といった内容になる。即ち、エラーコードが「１１１」で、媒体出口側の媒体センサがＯＮ−ＯＦＦ−ＯＮと変化し、出力媒体数量が５で排出カウンタの数値が０というデータが状態情報に含まれていれば、該当する媒体が媒体出口で滞留しており、排出が完了していないという障害と判断される。その場合には、該当する媒体を５枚排出すれば障害が復旧できる。障害識別パラメータ３６の情報量が多ければ、それだけ正確に障害の種別を正確に判断できる。障害検出の対象となる自動取引装置１２は必ずしも全て同一の機種で、同一のメーカーのものとは限らない。各自動取引装置１２が機種毎に固有の障害パターンを有する場合でも、それらを区別できる障害識別パラメータ３６を準備しておけばよい。自動復旧できる障害の種類が増えたときには、障害識別パラメータ３６のリストを追加するだけでよいから、メンテナンスが非常に容易な効果がある。
【００２９】
（障害復旧手順の選択）
取得した状態情報３２に、いずれかの障害識別パラメータ３６が含まれていたときには、該当する障害復旧手順３８を選択して、復旧処理を実行させる。この制御のために、監視アプリケーション実行手段２８は、復旧制御手段５０を備える。復旧制御手段５０は、障害識別パラメータ３６と障害復旧手順３８を対応付けた自動処理テーブルを参照する。
【００３０】
図２は、自動処理テーブルの内容例説明図である。
例えば、図のように、取引区分が入金や出金といった種類では、自動取引装置側と金融機関のホストコンピュータ１９（図１）側の取引成立の可否、障害コード、装置内部の残留媒体の種類と有無、および、本人確認処理ができたかどうかという障害識別パラメータ３６により、障害復旧手順３８が決まる。障害復旧手順３８は、処理パターンＩＤで特定される。自動処理テーブル３９は、このように、障害識別パラメータ３６と障害復旧手順３８を対応付けるデータである。なお、障害復旧手順３８はコマンドの集合でもよいし、復旧処理プログラムを記述したものでもよい。
【００３１】
図３は、障害識別パラメータから障害復旧手順を得る処理の説明図である。
図に示すように、自動処理テーブル３９には、障害識別パラメータ３６と障害復旧手順３８とが対応付けられたデータがある。自動的に障害復旧処理をすることができるのはこれで全部である。従って、自動処理テーブル３９中の全ての障害識別パラメータ３６を順番に読み出して、自動取引装置の各部から収集した状態情報３２中に、いずれかの障害識別パラメータ３６が含まれているかどうか判断する。こうして、処理パターンＩＤを取得する。図の右側の処理パターンマスタから、各処理パターンＩＤに対して、実行すべきコマンドコードを順番に読み出すことができる。コマンドコードの内容は、図のコマンドマスタを参照する。障害復旧手順３８は、このように、コマンドの集合として取り出される。
【００３２】
復旧制御手段５０は、該当する障害復旧手順３８を読み出して、順番に装置各部にコマンドを送信し、復旧処理を実行する。障害復旧手順３８の中には、利用者６２に対するメッセージの出力処理も含まれるとよい。利用者６２に対して、障害の種別や障害復旧の手順、待機時間等の案内を出力することが好ましい。画面に文字で表示してもよいし、音声で出力するようにしてもよい。
【００３３】
障害復旧手順３８には、例えば、本人確認処理、勘定系への取引結果の取消要求送信、装置内部に残留した銀行カード等の媒体返却、障害復旧処理の完了報告といった処理が含まれる。これらの処理を全て自動的に実行する。また、自動的に実行しても、確実で問題が生じる心配の無い障害だけを、障害識別パラメータ３６のリストに含めるとよい。
【００３４】
（障害の種類と復旧方法）
障害の種類には、取引開始以前のアイドル状態で検出される障害と取引開始後に発生する障害がある。アイドル状態で検出される障害には、既に使用できない状態にあるものだけでなく、障害発生を予告すべき状態にあるものも含めることにする。取引開始後の障害には、銀行カードや現金等の取込前で発生した障害や銀行カードや現金等の取込後発生した障害などがある。前者の場合には、リセットをして最初から取引を開始できる状態に復旧できればよい。一方、後者の場合には、開始された取引がどこで中断したかを確認して、取引前の状態に戻す対応を行う。
【００３５】
生態認証や暗証番号による本人確認を実行して、その後、カードや入金紙幣を利用者６２に返還する。明細票（レシート）、出金紙幣は自動取引装置１２に回収し、最後にリセットして障害復旧させる。処理が完了後は、結果報告手段５６が処理結果報告３１を生成して、監視端末１８に送信する。
【００３６】
（係員の出動要求）
障害復旧の過程で、処理が正常に終了しないような場合には、自動復旧が困難と判断して、係員の出動要求メッセージ４１の送信をする。復旧制御手段５０による該当する障害復旧手順３８が正常に実行できないとき、情報収集手段４６が再び状態情報３２を収集してもよい。いわゆる2次障害が発生した場合である。この状態情報３２の中に新たな障害識別パラメータ３６が含まれていると判断されたら、新たな復旧制御手順３８を実行するとよい。情報収集手段４６が取得した状態情報３２に、予め用意したどの障害識別パラメータ３６も含まれていないと判定されたときには、想定外の障害として係員の出動要求処理を行う。即ち、出動要求手段５４が出動要求メッセージ４１を生成して、携帯端末１７に送信する。
【００３７】
誰も使用していないアイドル状態で、障害検知手段４４が復旧の必要な障害を検出することがある。例えば、搬送ベルト等の劣化、センサー異常等を検出したときである。このとき、情報収集手段４６が状態情報３２を収集する。情報解析手段４８がこの状態情報３２の中に障害識別パラメータ３６が含まれていると判断したとき、復旧制御手段５０は該当する復旧制御手順３８を実行する。
【００３８】
出動要求メッセージ４１には、収集した状態情報３２を含めるとよい。自動的に、出動要求メッセージ４１を生成して、該当する宛先に送信する。電話、ＦＡＸ、メール等の送信手段を利用するとよい。利用者６２による取引開始後の障害で、係員の出動要求処理を実行するときには、自動取引装置１２のディスプレイに待機依頼メッセージを表示し、あるいは、「間もなく係員がまいりますので暫くお待ち下さい」といった音声案内をする。上記の処理では、取得した状態情報３２に、限定された障害識別パラメータ３６が含まれているかどうかを判断するだけなので、きわめて迅速に係員の出動要求処理を実行できる。従って、利用者６２を長時間待たせないという効果がある。
【００３９】
誰も使用していないアイドル状態で、ただちに使用不能になるわけではないが、いずれ障害に至るような状態が検出されることがある。例えば、リソース（メモリーの空き領域）が一定値以下に減少したような場合が該当する。この場合には、リブートを実行すると自動的に健全な状態にモードすることができる。そこで、リソースが一定値以下に減少した状態を、障害識別パラメータに含めておく。そして、該当する障害復旧手順にはリブートを実行するコマンドを設定する。これで、利用時の障害発生を未然に防ぐことができる。
【００４０】
一方、使用する媒体、例えば、紙幣の量が減少して、ニアエンドの状態になったといった状態がある。この状態も、まだ取引が可能であって、ただちに使用不能になるわけではないが、いずれ障害に至るような状態である。こうした状態を予め設定しておき、装置の警戒レベルを示す情報とする。情報収集手段４６は、この警戒レベルを示す情報も状態情報３２に含めて収集する。
【００４１】
同時に、警戒レベルを示す情報を前記障害識別パラメータに含めておく。原則として、警戒レベルを障害と同様に取り扱う。該当する障害復旧手順は、警戒レベルを示す情報を含む出動要求メッセージ４１を生成して、復旧制御手段５０は、出動要求手段５４に対して、出動要求メッセージ４１の送信を依頼するという内容にする。この処理も、広い意味の障害復旧手順とすればよい。
【００４２】
なお、アイドル状態で、警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされたときには、すぐに係員の出動要求を実行せず、残りの装置の状態を比較する。記憶装置２２には、自機及び周辺の他の自動取引装置の装置稼働状態４２が記憶されている。装置稼働状態４２は、少なくとも、各装置が、取引可能な状態にあるか、メンテナンス中あるいは障害により取引できない状態にあるか、警戒レベルの状態にあるか等の情報を含むものとする。
【００４３】
例えば、５台の自動取引装置１２が設置された無人店舗で、１台の自動取引装置１２について障害が発生していても、残りの４台の装置が正常に動作できる場合がある。このときには、係員の出動要求処理を見合わせて、障害を検出した装置を使用できない状態にして待機させる。
【００４４】
もう１台、出動要求をすべき障害が発生したときには、係員の出動要求処理を実行する。また、次回の巡回点検スケジュールまでの時間が一定値以下の場合には、係員出動要求を見合わせる。これにより、係員の出動回数を減少させることができる。即ち、自機を含めた使用不可能な状態もしくは警戒レベルの状態の自動取引装置の合計台数が限界値を越えた場合に限り、出動要求手段５４に対して、出動要求メッセージの送信を依頼する。出動要求メッセージには、使用が不可能な状態の自動取引装置や、警戒レベルの状態の自動取引装置の情報を含める。
【００４５】
従来は、業務アプリケーションから監視端末側に送信されるエラーコードに基づいて、障害の種類を知り、監視員が自動取引装置にコマンドを送信して復旧操作をしていた。このとき、必要に応じて、自動取引装置から他の情報も取得して、復旧操作の方針を決定していた。監視対象として、様々な機種の自動取引装置が混在する場合も少なくない。従って、機種毎に復旧操作のためのマニュアルを準備して対応していた。
【００４６】
一方、本発明では、各自動取引装置がそれぞれ自動的に独自に復旧処理を実行する。即ち、全ての自動取引装置に自動復旧プログラムをインストールする。機種の異なる自動取引装置が混在する場合には、それぞれ自動復旧のための手順が異なることがある。しかし、機種毎にそれぞれ別々の自動復旧プログラムを作成していては、プログラム作成コストも管理コストも莫大になる。
【００４７】
そこで、本発明では、上記のように、障害が検知されると、無条件に画一的に装置各部の状態情報を取得するように制御する。そして、収集した状態情報の中に、障害識別パラメータが存在するかどうかを判断する。障害識別パラメータと障害復旧手順は機種毎に具体的に詳細に設定しておく。しかし、障害復旧を制御するための各プログラムは、ほぼ全ての機種に共通化することができる。従って、異なる機種の自動取引装置が混在する環境において、低コストで自動復旧プログラムを開発し監理運営することができる。以上が、本発明の概略説明である。以下、本発明の実施の形態を実施例毎に詳細に説明する。
【実施例１】
【００４８】
ここで、図１に示した各機能ブロックの基本的な機能を整理してから、具体的な動作の説明をする。業務アプリケーション実行手段２６は、金融機関において、現金の入出金取引に使用される装置であって、入出金取引業務のための処理を実行する機能を持つ。監視アプリケーション実行手段２８は、障害の監視と復旧のための処理を実行する機能を持つ。
【００４９】
障害検知手段４４は、業務アプリケーション実行手段２６から受信した障害発生通知３０を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する機能を持つ。情報収集手段４６は、障害発生以前の動作履歴を含む、装置の状態情報３２を収集する機能を持つ。記憶装置２２に記憶された障害識別パラメータは、装置で発生する障害の種別を認識するためのものである。
【００５０】
情報解析手段４８は、情報収集手段４６が収集した状態情報３２の中に、記憶装置２２に記憶された障害識別パラメータ３６が含まれているかどうかを判断する機能を持つ。復旧制御手段５０は、情報解析手段４８が、状態情報３２の中に障害識別パラメータが含まれていると判断したとき、記憶装置２２に記憶された該当する復旧制御手順を読み出して、その手順を実行する機能を持つ。
【００５１】
出動要求手段５４は、情報解析手段４８が、状態情報３２の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワーク１６を通じて係員の出動要求メッセージ４１を送信する機能を持つ。処理報告手段５６は、復旧制御手段５０または出動要求手段５４の処理結果報告３１をネットワーク１６を通じて送信する機能を持つ。
【００５２】
以上の装置は、障害識別パラメータにより自動復旧が可能と判断した障害について、記憶装置２２に記憶された該当する復旧制御手順に従って自動的に障害復旧処理をするので、監視端末１８側の負担を軽減できる。また、自動復旧できるものを限定しており、該当しない場合には直ちに係員の出動要求をするので、障害の診断から係員の出動要求までの時間を短縮して、利用者６２の待ち時間を少なくできる。さらに、個々の自動取引装置固有の障害がある場合には、その自動復旧手順も記憶させておくことができる。
【００５３】
なお、自動復旧処理に途中で失敗した場合に、再度新たな障害識別パラメータ３６が含まれているかどうかを判断するとよい。例えば、返却のため搬送中のカードや紙幣がうまく搬送されなかったとき、該当する障害識別パラメータが準備されていれば、対応する復旧手順を実行して、自動復旧を完結させることができる。
【実施例２】
【００５４】
図４から図８までは障害復旧処理のシーケンスチャートである。
ここでは、業務アプリケーション実行手段２６と監視アプリケーション実行手段２８とが連携して障害の復旧処理を実行する。ミドルウエア５８は、業務アプリケーション実行手段２６が自動取引装置１２の画面を制御するためのインタフェースに相当する機能を持つ。ミドルウエア５８は、また、自動取引装置１２の各部のハードウエアやセンサ等と業務アプリケーション実行手段２６とを制御するインタフェースである。ドライバに近い動作をする。ＡＰＬは、アプリケーション実行手段の略である。
【００５５】
図４〜８は、いずれも、上から下に向かって時間が経過するものとする。以下、時間の経過を追って、各部の動作を説明する。まず、ミドルウエア５８がセンサその他の信号を取得して、その内容から、障害検知がされる。図４では、ミドルウエア５８から業務アプリケーション実行手段２６に障害発生通知がされ、それが監視アプリケーション実行手段２８に伝達される。この部分の伝達情報の内容は任意である。障害が発生した旨の通知が監視アプリケーション実行手段２８に伝達されればよい。これを監視アプリケーション実行手段２８の障害検知手段４４が受信する。
【００５６】
図４は媒体を返却する障害自動復旧シーケンスチャートである。
例えば、入金取引を中止した際に、返却された紙幣の一部分を取り忘れて紙幣が残留しているといった情報が業務アプリケーション実行手段２６に通知される。業務アプリケーション実行手段２６は障害発生通知を監視アプリケーション実行手段２８に対して行う。
【００５７】
次に、監視アプリケーション実行手段２８の情報収集手段４６は情報収集を開始する。図４の例では、情報収集の一部を業務アプリケーション実行手段２６に依頼している。業務アプリケーション実行手段２６は、勘定データを取得し、取引ステータスを確認し、取引装置側での処理が正常に終了しているのか、勘定系のホストコンピュータ１９（図１）側での処理が成立しているのかといった情報を収集する。監視アプリケーション実行手段２８の復旧制御手段５０は、自機が障害で取引できない状態になったので、装置稼働状態４２の内容を変更する処理を実行する。
【００５８】
次に、認証処理手段５２が、障害発生後に自動取引装置１２の前で待機している利用者６２に対する認証処理を行う。処理内容は取引開始時の認証処理と全く同一である。従って、この処理も復旧制御手段５０が業務アプリケーション実行手段２６に依頼する。即ち、暗証入力用の画面を表示させ、暗証番号の入力を受け付ける。そして、残照電文を使用して暗証確認処理を実行する。認証処理が正常に終了すると、自動取引装置１２の画面に、障害が発生して復旧処理中である旨のメッセージ等（障害画面）を表示する。
【００５９】
認証処理が正常に終了した後、その結果が業務アプリケーション実行手段２６から監視アプリケーション実行手段２８に通知される。同時に業務アプリケーション実行手段２６から監視アプリケーション実行手段２８に対して、自動処理の要求と、取得した障害情報が送信される。図４の右下の部分で、監視アプリケーション実行手段２８の情報解析手段４８は、既に説明した自動処理テーブル３９を利用して、障害復旧手順３８を取得する。
【００６０】
図５は障害復旧手順が実行されるときのシーケンスチャートである。
次に図５の処理に進む。監視アプリケーション実行手段２８の復旧制御手段５０は、取得したコマンドを順番に発行する。例えば、この図では、始めに、紙幣を返却するというコマンドを発行する。同時に、自動取引装置１２の画面に、「紙幣が出ますのでお取り下さい」といったメッセージを表示するよう業務アプリケーション実行手段２６に指示する。コマンドは、監視アプリケーション実行手段２８から業務アプリケーション実行手段２６を介してミドルウエア５８に転送される。ミドルウエア５８は紙幣投入口を開いて利用者に紙幣を返却する。コマンドが正常に実行されたというコマンド応答が監視アプリケーション実行手段２８に返される。
【００６１】
次に、監視アプリケーション実行手段２８は、取引の結果を印刷した明細票（レシート）を回収するというコマンドを発行する。明細票回収についても、正常に実行された旨のコマンド応答が監視アプリケーション実行手段２８に返される。さらに、監視アプリケーション実行手段２８は、リセットをするというコマンドを発行する。リセットが正常に実行された旨のコマンド応答が監視アプリケーション実行手段２８に返される。
【００６２】
以上のような処理に続いて、監視アプリケーション実行手段２８の復旧制御手段５０は、これで自動障害復旧処理が完了したと判断して、自機が正常に動作できるというように、装置稼働状態４２を修正する。その後、業務アプリケーション実行手段２６に制御を返すため、自動処理応答をする。業務アプリケーション実行手段２６は、自動取引装置１２の画面を通常の取引画面にして表示する。また、監視アプリケーション実行手段２８の処理報告手段は、監視端末１８に対して、処理結果報告３１を送信する。図では、監視端末１８の表示画面の更新通知をしている。この画面の例は図９で説明する。
【００６３】
図６は利用者が離れた後の媒体を返却しない障害自動復旧シーケンスチャートである。
中段の取引ステータス確認処理までは、図４の場合と同様の処理が行われる。図４の例では、監視端末１８に対して、監視画面の更新のための更新通知が送信された。しかしながら、図６の場合は監視アプリケーションで監視端末への更新は不要と判断したため更新通知は送信していない。監視端末１８の操作画面上で、任意のタイミングで画面更新ボタンが押下げられると、画面の更新がされる。この場合、取引が成立しているが、出金全額の取り忘れが生じている。従って、まず、取引勘定を取消す処理を実行している。
【００６４】
その後、自動処理テーブルに含まれた該当する障害識別パラメータ３６により、障害復旧手順が出力された。紙幣を金庫に収納して戻し、明細票（レシート）を回収し、装置をリセットするというコマンドが順番に送信される。その流れは、図５で説明したとおりである。ここでは、詳細な図示は省略した。
【００６５】
なお、この例では、自動復旧処理が開始される前に、業務アプリケーション実行手段２６が取引の取消処理を実行している。これは、業務アプリケーション実行手段２６の既存の機能をそのまま利用したものである。監視アプリケーション実行手段２８が業務アプリケーション実行手段２６から障害通知を受信した後、状態情報を収集して、ただちに自動処理テーブルを利用した障害識別パラメータ３６の検索をして、取引取消しというコマンドを含む障害復旧手順を取得するようにして構わない。図６の後段の処理も、図５の後段の処理と同一であるから、一部図示を省略し、具体的な説明も省略する。
【００６６】
図７は、出動要求をする場合のシーケンスチャートである。
自動処理テーブルを利用して障害復旧手順を取得し、監視アプリケーション実行手段２８の復旧制御手段５０が、該当するコマンドを送出するところまでは、図６の例と変わらない。ここで、ミドルウエア５８がそのコマンドを受け付けたところ、何らかの原因で、いずれかのコマンドに対する処理に失敗したとする。
【００６７】
この例では自動復旧処理において紙幣の収納、明細票（レシート）の回収あるいはリセット処理に失敗したということになる。このときは、ミドルウエア５８から監視アプリケーション実行手段２８に対し障害復旧処理に失敗したというコマンド応答が送信される。この場合には監視アプリケーション実行手段２８から業務アプリケーション実行手段２６に対し障害復旧失敗の応答がなされる。同時に監視アプリケーション実行手段２８の出動要求手段５４から携帯端末１７に対して、出動要求メッセージ４１がネットワーク１６を通じて送信される。
【００６８】
図８は、出動要求メッセージ送信後のシーケンスチャートである。
監視アプリケーション実行手段２８から監視端末１８に対し画面の更新通知が行われる。監視端末１８では監視画面を更新する。また、業務アプリケーション実行手段２６は自動取引装置の画面に、出動要求中という案内表示を行う。利用者に、障害復旧中で取引出来ない状態にあることを伝えるためである。また、出動要求メッセージ４１を送信すると、係員からの返信によって到着予定時刻が通知される。それが監視アプリケーション実行手段２８から業務アプリケーション実行手段２６に送信される。業務アプリケーション実行手段２６は自動取引装置の画面に、係員の到着予定時刻を表示する。
【００６９】
即ち、係員の予定時間を示す画面を表示する。同時に監視アプリケーション実行手段２８は監視端末１８に対し係員の到着予定時刻を通知して、監視端末１８の監視画面が更新される。係員が現場に到着すると、自動取引装置を点検モードにする。ミドルウエア５８はこのタイミングで、係員の入店検知を行い、自動的に入店通知が業務アプリケーション実行手段２６に送信される。
【００７０】
入店通知は業務アプリケーション実行手段２６から監視アプリケーション実行手段２８に送信され、さらに、監視アプリケーション実行手段２８から監視端末１８に送信される。これで、監視端末１８の監視画面が更新される。即ち、監視端末１８では現在係員が障害復旧処理中という内容の画面が表示される。その後、障害が除去されて、係員が自動取引装置を点検モードから通常モードに切り替えると、ミドルウエア５８はそのタイミングで退店を検知する。退店通知は業務アプリケーション実行手段２６を経由して監視アプリケーション実行手段２８に送信され、監視端末１８に転送されて監視画面が更新される。また、自動取引装置の画面が正常の取引画面に戻る。
【００７１】
図９は監視端末１８の表示画面の具体例説明図である。
図１に示した監視端末１８には、例えば、図９に示したような画面が表示される。これを監視員６０が監視することにより、無人店舗等において、障害が発生した自動取引装置とその自動復旧処理の状況を常時確認できる。即ち、自動取引装置を設置した各店舗についてその障害の発生時刻、係員に対する出動要求をした依頼時刻などが表示されている。
【００７２】
この内容は、既に図４〜図８のシーケンスチャートで説明したとおり、監視対象の自動取引装置の状態変化に応じて時々刻々と更新される。従来は障害が発生するとその自動取引装置からの通知を受けて係員が対応していた。この発明では、図に示すような画面に、各装置が自動的に障害を復旧しあるいは自動的に係員に出動要求をした状態が一覧表示される。
【００７３】
図１０は出動の各状態が起きた時刻、障害からの復旧時刻を示す画面である。
これも監視端末１８に表示される。図に示すように、障害が発生した自動取引装置について、係員が到着する予定時刻、入店時刻、退店時刻、障害復旧処理が完了して自動取引装置が取引可能な状態なった時刻などが一覧で表示されるようになっている。これにより、監視対象が増加した場合でも、監視端末１８側の係員は、自動復旧処理が出来ないものにだけ対応をすればよいので、負荷が軽減される。また、自動復旧できるかどうかの判断が早いので、すみやかに係員の出動要求ができ、顧客を長時間待たせないで、サービスの向上が図れる。
【００７４】
図１１以下は装置の具体的な動作フローチャートである。
図１１と図１２は障害検出動作を示すメインルーチンである。業務アプリケーション実行手段２６と監視アプリケーション実行手段２８の動作を特に区別しないで説明する。これらの間の処理のシーケンスは図４等で説明したとおりである。まず、ステップＳ１１では、装置各部からの障害通知を受信する待ち受け状態にある。ステップＳ１２で、障害検知手段４４が障害発生通知を受けると、ステップＳ１３で取引装置の画面の切り替えを実行する。
【００７５】
次に、情報収集手段４６が、ステップＳ１４でホストコンピュータからの情報を収集する。即ち、ホストコンピュータから取引成否の情報を取得する。障害通知を受信すると同時に、障害情報を受信することができる。さらにどのような情報を収集すべきか判断をしなくてもよい。予め定められた範囲の情報を収集するとよい。情報解析手段４８は、収集した情報の中に、障害識別パラメータ３６と一致しているものが含まれるかどうかを判断する。
【００７６】
次に、認証処理手段５２は、認証処理を開始する。ステップＳ１５で暗証入力画面を表示しステップＳ１６で暗証入力を待つ。ステップＳ１７で暗証入力を検知するとステップＳ１８でその入力データに基づきホストコンピュータに暗証確認を行う。ここで本人確認のための認証が終了するとステップＳ１９において、自動取引装置の画面に障害を自動的に復旧する旨のメッセージを表示する。ここから、復旧制御手段５０による障害復旧処理が開始される。
【００７７】
ステップＳ２０において本人確認が正常に終了したかどうかを判断する。本人確認が正常終了した場合にはステップＳ２１に進み、それ以外の場合には、ステップＳ３１へ進む。ステップＳ２１で、障害復旧手順に基づいて、ホストコンピュータにおける取引の成否について修正処理を実行する。さらに、ステップＳ２２から、復旧のためのコマンドにより修正処理が実行される。取引修正処理ができない場合には、ステップＳ３１へ進む。
【００７８】
ステップＳ２３〜２５で、復旧指示のためのコマンドを送信し、応答を待ち、コマンドが正常に処理されたかどうか応答を検知する。そして、ステップＳ２６で、応答が正常かどうかを判断して、正常な場合には、障害復旧処理が完了したとして、ステップＳ２７に進む。ステップＳ２７では、自動取引装置の画面を切り替えて、通常の取引画面に戻す。
【００７９】
ステップＳ２０で本人確認に失敗した場合と、ステップＳ２２で取引修正ができない場合と、ステップＳ２６で処理に失敗をした旨のコマンドの応答があったときは、ステップＳ３１に進む。ステップＳ３１以下は、出動要求手段５４よる係員の出動要求処理である。
【００８０】
図１３は出動要求処理の動作フローチャートである。
出動要求手段５４はステップＳ３２において警備端末から、あるいは係員かセンタから係員到着予定時刻の入力を待つ。ステップＳ３３で到着予定時刻の入力が検知されると、ステップＳ３４でＡＴＭの画面に到着予定時間を表示する。ステップＳ３５では係員の入店通知を待ち、ステップＳ３６で入店を検知するとステップＳ３７でその結果を取得する。そして、ステップＳ３８で、監視端末１８に係員が入店したことを示す画面を表示する。
【００８１】
ステップＳ３９では係員の退店通知を待ち、ステップＳ４０で退店を検知するとステップＳ４１でその結果を取得する。ステップＳ４２では係員が退店した旨の画面を、監視端末１８に表示する。これで、自動取引装置が復旧したから、ステップＳ４２で、自動取引装置を取引可能な状態の画面に戻す。
【００８２】
図１４は障害復旧処理動作の具体的なフローチャートである。
ステップＳ５１で自動復旧処理の要求を待つ。ステップＳ５２で自動復旧処理の要求を検知すると、復旧制御手段５０はその状態を監視端末１８に通知する。そして、ステップＳ５４で装置稼働状態４２の内容を更新する。ここで情報収集手段４６が必要な情報を収集し、ステップＳ５５で情報解析手段４８が障害識別パラメータ３６を利用して対応する障害復旧手順３８を検索する。ステップＳ５７で、取得された障害復旧手順３８から復旧処理のためのコマンドが生成される。
【００８３】
ステップＳ５８では該当するコマンドがミドルウエア５８に送信される。ステップＳ５９でミドルウエア５８からの応答を待ち、ステップＳ６０で応答を検知すると、ステップＳ６１の判断をする。送信したコマンドに対し正常な応答が返ってきた場合には次のコマンドを送信する。ステップＳ６２で全てのコマンドの送信が終了されたかどうかを判断する。残りのコマンドがあれば、ステップＳ５８からステップＳ６０の処理が繰り返される。
【００８４】
図１５は、係員の出動要求の前半処理フローチャートである。
復旧制御手段５０は、該当する障害復旧手順３８が障害復旧手順３８を正常に実行できないとき、出動要求手段５４に対して、出動要求メッセージ４１の送信を依頼する。即ち、いずれかのコマンドの応答が正常でない場合にはステップＳ６１からステップＳ７０に進み係員の出動要求処理に進む。全てのコマンドが送信され正常に応答がされた場合には、ステップＳ６３において監視アプリケーション実行手段２８から業務アプリケーション実行手段２６に対して、正常に復旧処理が終了した旨の通知が行われる。その後、ステップＳ６４で、自動取引装置の状態を更新し、装置稼働状態４２に記録する。
【００８５】
ステップＳ７０で自動処理のコマンド処理に失敗したと判断された場合には、ステップＳ７１で自動取引装置のステータスを更新し、ステップＳ７２で装置稼働状態４２を更新する。また、ステップＳ７３で出動要求手段５４が出動要求メッセージを送信しステップＳ７４で係員の到着予定時刻の通知を待つ。ステップＳ７５と７６で装置稼働状態４２を更新する。ステップＳ７７で到着予定時刻の通知を検知すると、ステップＳ７８と７９で装置稼働状態４２を更新する。これで、係員の入店待ちの状態になる。
【００８６】
図１６は係員の出動要求の後半処理フローチャートである。
ステップＳ８０で係員の到着予定時刻が監視アプリケーション実行手段２８から業務アプリケーション実行手段２６に通知される。ステップＳ８１では業務アプリケーション実行手段２６から監視アプリケーション実行手段２８への係員の入店通知を待つ。ステップＳ８２で入店通知を検知するとステップＳ８３で、装置稼働状態を更新することを、監視端末１８に通知する。ステップＳ８４で装置稼働状態４２を更新しステップＳ８５に進む。
【００８７】
ステップＳ８５で入店通知を受け付けて、ステップＳ８６で退店通知を待つ状態になる。ステップＳ８７で退店通知を受信すると、ステップＳ８７で警備センタに対し退店通知を送信する。これは警備センタにおける係員の業務管理に利用される。ステップＳ８９では装置稼働状態を更新する通知を監視端末１８に送信する。ステップＳ９０で装置稼働状態４２を更新する。これで、自動取引装置は取引可能な状態に復旧する。
【実施例３】
【００８８】
図１７は実施例３の動作フローチャートである。
利用者の取引中や取引終了直後には、上記の実施例のような障害が検知される。一方、既に説明したように、アイドル状態で障害を検出することもできる。障害検知手段４４は、例えば、ステップＳ１１１で一定時間毎に自機の状態を診断する。ステップＳ１１２では、その結果を装置稼働状態４２に記録する。ステップＳ１１３で、アイドル状態で障害を検出したかどうかを判断する。障害を検出しない場合には、ステップＳ１１１からステップＳ１１３までの処理を繰り返す。
【００８９】
アイドル状態で障害を検出したら、ステップＳ１１３からステップＳ１１４に進む。ステップＳ１１４では、状態情報に警戒レベル情報が含まれているかどうかを判断する。ここでは、自動復旧可能な障害かどうかを判断している。状態情報に警戒レベル情報が含まれているときには、ステップＳ１１７に進み、出動要求メッセージを送信する。出動要求メッセージの中には、警戒レベルを示す情報を含める。これは既に説明したとおりである。
【００９０】
ステップＳ１１４で、自動的に復旧できる障害と判断すると、ステップＳ１１５に進み、該当する障害復旧手順を実行する。ステップＳ１１６で、障害が復旧したかどうかを判断し、復旧していれば、処理を終了する。復旧しなければ、ステップＳ１１７に進み、出動要求メッセージを送信する。
【実施例４】
【００９１】
図１８は実施例４の動作フローチャートである。
実施例３のステップＳ１１６で、自動復旧制御に失敗をしたと判断すると、出動要求メッセージを送信した。また、図１７のステップＳ１１４で、状態情報に警戒レベル情報が含まれていると判断したときには、警戒レベルを示す情報を含む出動要求メッセージを送信した。しかしながら、ただちに係員を出動させなくてもよい場合がある。同じ無人店舗に対して、短時間の間に２度出動をするというケースがあると無駄である。また、係員は保守点検のために、無人店舗を定期的に巡回している。それも考慮すべきである。
【００９２】
そこで、図１８のステップＳ１２１において、アイドル状態で、出動要求メッセージを送信するという判断がなされたとき、ステップＳ１２２以下の処理をする。ステップＳ１２２では、近接して配置された他の全ての自動取引装置が、使用可能な状態か使用不可能な状態か警戒レベルの状態かを示すデータを取得する。記憶装置２２の装置稼働状態４２を参照すればよい。そして、ステップＳ１２３で、自機を含めた使用不可能なものや警戒レベルの自動取引装置の合計台数をカウントする。
【００９３】
無人店舗等で、近接して複数台の自動取引装置が配置されているときに、例えば、１台だけなら、使用不可能な状態のまま、あるいは警戒レベルのまま少しの間放置しても良い場合がある。このとき、ただちに出動要求メッセージ４１を送信せずに待機する。これで、出動要求の頻度を低下させられる。ステップＳ１２３では、例えば、５台中２台以上使用不能になったときに出動要求をする。
【００９４】
即ち、ステップＳ１２４で、この台数が、限界値、例えば、２台を越えたと判断したときには、ステップＳ２６で、出動要求メッセージ４１を送信する。しかし、例えば、巡回予定が短時間後に迫っているような場合にも、すぐに出動要求をする必要はない。そこで、ステップＳ１２５で、次回の巡回は近時か、例えば、当日中に必ず巡回があるかを判断する。この判断がノーの場合には、出動要求メッセージ４１を送信する。出動要求メッセージ４１には、自機と周辺の装置の装置稼働状態４２を含めるとよい。それ以外の場合には、自機を使用不可能な状態にして待機させる。
【００９５】
上記のように一部の自動取引装置が使用不能になった店舗の状態は、既に図９で説明したように、監視端末の画面で確認することができる。従って、巡回をする係員は、店舗に到着すると、ただちに該当する自動取引装置の障害復旧処理を開始する。これで、出動をする係員の負担を軽減できる。従って、大規模な監視センタを必要としないという効果がある。また、各自動取引装置が詳細な状態情報を収集するので、必要に応じて監視端末側へ転送すれば、詳細な情報把握により、その後の障害復旧率の向上を図ることができる。
【００９６】
なお、上記の演算処理装置で実行されるコンピュータプログラムは、機能ブロックで図示した単位でモジュール化されてもよいし、複数の機能ブロックを組み合わせて一体化されてもよい。また、上記のコンピュータプログラムは、既存のアプリケーションプログラムに組み込んで使用してもよい。本発明を実現するためのコンピュータプログラムは、例えばＣＤ−ＲＯＭのようなコンピュータで読み取り可能な記録媒体に記録して、インストールして利用することができる。
【符号の説明】
【００９７】
１２ 自動取引装置
１４ 内部ＬＡＮ
１６ ネットワーク
１７ 携帯端末
１８ 監視端末
１９ ホストコンピュータ
２０ 管理データ記憶装置
２２ 記憶装置
２４ 演算処理装置
２６ 業務アプリケーション実行手段
２８ 監視アプリケーション実行手段
３０ 障害発生通知
３１ 処理結果報告
３２ 状態情報
３４ 障害情報
３６ 障害識別パラメータ
３８ 障害復旧手順
３９ 自動処理テーブル
４０ 巡回予定データ
４１ 出動要求メッセージ
４２ 装置稼働状態
４４ 障害検知手段
４６ 情報収集手段
４８ 情報解析手段
５０ 復旧制御手段
５２ 認証処理手段
５４ 出動要求手段
５６ 結果報告手段
５８ ミドルウエア
６０ 監視員
６２ 利用者
【特許請求の範囲】
【請求項１】
金融機関において、現金の入出金取引に使用される装置であって、
入出金取引業務のための処理を実行する業務アプリケーション実行手段と、
障害の監視と復旧のための処理を実行する監視アプリケーション実行手段とを備え、
前記業務アプリケーション実行手段から受信した障害発生通知を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する障害検知手段と、
障害発生以前の動作履歴を含む、装置の状態情報を収集する情報収集手段と、
装置で発生する障害の種別を認識するための障害識別パラメータと、該当する種別の障害に対する障害復旧手順を記憶する記憶装置と、
前記情報収集手段が収集した状態情報の中に、前記記憶装置に記憶された障害識別パラメータが含まれているかどうかを判断する情報解析手段と、
前記情報解析手段が、前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記記憶装置に記憶された該当する復旧制御手順を読み出して、その手順を実行する復旧制御手段と、
前記情報解析手段が、前記状態情報の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワークを通じて係員の出動要求メッセージを送信する出動要求手段と、
復旧制御手段または出動要求手段の処理結果報告をネットワークを通じて、送信する処理報告手段を備えたことを特徴とする自動取引装置。
【請求項２】
請求項１に記載の自動取引装置において、
前記復旧制御手段による該当する障害復旧手順が正常に実行できないとき、前記情報収集手段は再び状態情報を収集し、前記情報解析手段が前記状態情報の中に新たな障害識別パラメータが含まれていると判断したとき、前記復旧制御手段は該当する復旧制御手順を実行することを特徴とする自動取引装置。
【請求項３】
請求項１または２に記載の自動取引装置において、
前記復旧制御手段は、該当する障害復旧手順が正常に実行できないとき、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。
【請求項４】
請求項１乃至の３いずれかに記載の自動取引装置において、
自動取引装置固有の障害を示す障害識別パラメータとその障害復旧手順を前記記憶装置に記憶したことを特徴とする自動取引装置。
【請求項５】
請求項１乃至４のいずれかに記載の自動取引装置において、
誰も使用していないアイドル状態で、前記障害検知手段が復旧の必要な障害を検出したときには、前記情報収集手段が状態情報を収集し、前記情報解析手段が前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記復旧制御手段は該当する復旧制御手順を実行することを特徴とする自動取引装置。
【請求項６】
請求項５に記載の自動取引装置において、
リソース（メモリーの空き領域）が一定値以下に減少した場合を、前記障害識別パラメータに含めておき、該当する障害復旧手順は、リブートを実行するとしたことを特徴とする自動取引装置。
【請求項７】
請求項５に記載の自動取引装置において、
使用する媒体量の減少を含む、予め設定された装置の警戒レベルを示す情報を、前記情報収集手段が収集する状態情報に含め、前記警戒レベルを示す情報を前記障害識別パラメータに含めておき、該当する障害復旧手順は、前記警戒レベルを示す情報を含む出動要求メッセージを生成して、前記出動要求手段に対して、出動要求メッセージの送信を依頼するとしたことを特徴とする自動取引装置。
【請求項８】
請求項５乃至７のいずれかに記載の自動取引装置において、
自動復旧制御に失敗をしたとき、もしくは、前記警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされたとき、
前記復旧制御手段は、近接して配置された他の全ての自動取引装置が、使用可能な状態か使用不可能な状態か警戒レベルの状態かを示す装置稼働状態を取得し、
自機を含めた使用不可能な状態もしくは警戒レベルの状態の自動取引装置の合計台数が限界値を越えた場合に限り、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。
【請求項９】
請求項５乃至７のいずれかに記載の自動取引装置において、
自動復旧制御に失敗をしたとき、もしくは、前記復旧制御手段は、警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされた場合に、
記憶装置に記憶されている巡回予定データを参照して、係員による巡回時までの時間が一定値以上の場合に限り、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。
【請求項１０】
金融機関において、現金の入出金取引に使用される装置のコンピュータを、
入出金取引業務のための処理を実行する業務アプリケーション実行手段と、
障害の監視と復旧のための処理を実行する監視アプリケーション実行手段とを備え、
前記業務アプリケーション実行手段から受信した障害発生通知を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する障害検知手段と、
障害発生以前の動作履歴を含む、装置の状態情報を収集する情報収集手段と、
装置で発生する障害の種別を認識するための障害識別パラメータと、該当する種別の障害に対する障害復旧手順を記憶する記憶装置と、
前記情報収集手段が収集した状態情報の中に、前記記憶装置に記憶された障害識別パラメータが含まれているかどうかを判断する情報解析手段と、
前記情報解析手段が、前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記記憶装置に記憶された該当する復旧制御手順を読み出して、その手順を実行する復旧制御手段と、
前記情報解析手段が、前記状態情報の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワークを通じて係員の出動要求メッセージを送信する出動要求手段と、
復旧制御手段または出動要求手段の処理結果報告をネットワークを通じて、送信する処理報告手段、
として機能させる自動取引装置制御プログラム。
【請求項１１】
請求項１０に記載の自動取引装置制御プログラムを記録したコンピュータで読み取り可能な記録媒体。
【請求項１】
金融機関において、現金の入出金取引に使用される装置であって、
入出金取引業務のための処理を実行する業務アプリケーション実行手段と、
障害の監視と復旧のための処理を実行する監視アプリケーション実行手段とを備え、
前記業務アプリケーション実行手段から受信した障害発生通知を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する障害検知手段と、
障害発生以前の動作履歴を含む、装置の状態情報を収集する情報収集手段と、
装置で発生する障害の種別を認識するための障害識別パラメータと、該当する種別の障害に対する障害復旧手順を記憶する記憶装置と、
前記情報収集手段が収集した状態情報の中に、前記記憶装置に記憶された障害識別パラメータが含まれているかどうかを判断する情報解析手段と、
前記情報解析手段が、前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記記憶装置に記憶された該当する復旧制御手順を読み出して、その手順を実行する復旧制御手段と、
前記情報解析手段が、前記状態情報の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワークを通じて係員の出動要求メッセージを送信する出動要求手段と、
復旧制御手段または出動要求手段の処理結果報告をネットワークを通じて、送信する処理報告手段を備えたことを特徴とする自動取引装置。
【請求項２】
請求項１に記載の自動取引装置において、
前記復旧制御手段による該当する障害復旧手順が正常に実行できないとき、前記情報収集手段は再び状態情報を収集し、前記情報解析手段が前記状態情報の中に新たな障害識別パラメータが含まれていると判断したとき、前記復旧制御手段は該当する復旧制御手順を実行することを特徴とする自動取引装置。
【請求項３】
請求項１または２に記載の自動取引装置において、
前記復旧制御手段は、該当する障害復旧手順が正常に実行できないとき、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。
【請求項４】
請求項１乃至の３いずれかに記載の自動取引装置において、
自動取引装置固有の障害を示す障害識別パラメータとその障害復旧手順を前記記憶装置に記憶したことを特徴とする自動取引装置。
【請求項５】
請求項１乃至４のいずれかに記載の自動取引装置において、
誰も使用していないアイドル状態で、前記障害検知手段が復旧の必要な障害を検出したときには、前記情報収集手段が状態情報を収集し、前記情報解析手段が前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記復旧制御手段は該当する復旧制御手順を実行することを特徴とする自動取引装置。
【請求項６】
請求項５に記載の自動取引装置において、
リソース（メモリーの空き領域）が一定値以下に減少した場合を、前記障害識別パラメータに含めておき、該当する障害復旧手順は、リブートを実行するとしたことを特徴とする自動取引装置。
【請求項７】
請求項５に記載の自動取引装置において、
使用する媒体量の減少を含む、予め設定された装置の警戒レベルを示す情報を、前記情報収集手段が収集する状態情報に含め、前記警戒レベルを示す情報を前記障害識別パラメータに含めておき、該当する障害復旧手順は、前記警戒レベルを示す情報を含む出動要求メッセージを生成して、前記出動要求手段に対して、出動要求メッセージの送信を依頼するとしたことを特徴とする自動取引装置。
【請求項８】
請求項５乃至７のいずれかに記載の自動取引装置において、
自動復旧制御に失敗をしたとき、もしくは、前記警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされたとき、
前記復旧制御手段は、近接して配置された他の全ての自動取引装置が、使用可能な状態か使用不可能な状態か警戒レベルの状態かを示す装置稼働状態を取得し、
自機を含めた使用不可能な状態もしくは警戒レベルの状態の自動取引装置の合計台数が限界値を越えた場合に限り、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。
【請求項９】
請求項５乃至７のいずれかに記載の自動取引装置において、
自動復旧制御に失敗をしたとき、もしくは、前記復旧制御手段は、警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされた場合に、
記憶装置に記憶されている巡回予定データを参照して、係員による巡回時までの時間が一定値以上の場合に限り、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。
【請求項１０】
金融機関において、現金の入出金取引に使用される装置のコンピュータを、
入出金取引業務のための処理を実行する業務アプリケーション実行手段と、
障害の監視と復旧のための処理を実行する監視アプリケーション実行手段とを備え、
前記業務アプリケーション実行手段から受信した障害発生通知を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する障害検知手段と、
障害発生以前の動作履歴を含む、装置の状態情報を収集する情報収集手段と、
装置で発生する障害の種別を認識するための障害識別パラメータと、該当する種別の障害に対する障害復旧手順を記憶する記憶装置と、
前記情報収集手段が収集した状態情報の中に、前記記憶装置に記憶された障害識別パラメータが含まれているかどうかを判断する情報解析手段と、
前記情報解析手段が、前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記記憶装置に記憶された該当する復旧制御手順を読み出して、その手順を実行する復旧制御手段と、
前記情報解析手段が、前記状態情報の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワークを通じて係員の出動要求メッセージを送信する出動要求手段と、
復旧制御手段または出動要求手段の処理結果報告をネットワークを通じて、送信する処理報告手段、
として機能させる自動取引装置制御プログラム。
【請求項１１】
請求項１０に記載の自動取引装置制御プログラムを記録したコンピュータで読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１２−１５５５０５（Ｐ２０１２−１５５５０５Ａ）
【公開日】平成２４年８月１６日（２０１２．８．１６）
【国際特許分類】
【出願番号】特願２０１１−１３５９４（Ｐ２０１１−１３５９４）
【出願日】平成２３年１月２６日（２０１１．１．２６）
【出願人】（５００３５１０００）日本エイ・ティー・エム株式会社 (21)
【Ｆターム（参考）】
【公開日】平成２４年８月１６日（２０１２．８．１６）
【国際特許分類】
【出願日】平成２３年１月２６日（２０１１．１．２６）
【出願人】（５００３５１０００）日本エイ・ティー・エム株式会社 (21)
【Ｆターム（参考）】
[ Back to top ]