金融機関において、現金の入出金取引に使用される装置であって、入出金取引業務のための処理を実行する業務アプリケーション実行手段と、障害の監視と復旧のための処理を実行する監視アプリケーション実行手段とを備え、前記業務アプリケーション実行手段から受信した障害発生通知を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する障害検知手段と、障害発生以前の動作履歴を含む、装置の状態情報を収集する情報収集手段と、装置で発生する障害の種別を認識するための障害識別パラメータと、該当する種別の障害に対する障害復旧手順を記憶する記憶装置と、前記情報収集手段が収集した状態情報の中に、前記記憶装置に記憶された障害識別パラメータが含まれているかどうかを判断する情報解析手段と、前記情報解析手段が、前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記記憶装置に記憶された該当する復旧制御手順を読み出して、その手順を実行する復旧制御手段と、前記情報解析手段が、前記状態情報の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワークを通じて係員の出動要求メッセージを送信する出動要求手段と、復旧制御手段または出動要求手段の処理結果報告をネットワークを通じて、送信する処理報告手段を備えたことを特徴とする自動取引装置。請求項1に記載の自動取引装置において、前記復旧制御手段による該当する障害復旧手順が正常に実行できないとき、前記情報収集手段は再び状態情報を収集し、前記情報解析手段が前記状態情報の中に新たな障害識別パラメータが含まれていると判断したとき、前記復旧制御手段は該当する復旧制御手順を実行することを特徴とする自動取引装置。請求項1または2に記載の自動取引装置において、前記復旧制御手段は、該当する障害復旧手順が正常に実行できないとき、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。請求項1乃至の3いずれかに記載の自動取引装置において、自動取引装置固有の障害を示す障害識別パラメータとその障害復旧手順を前記記憶装置に記憶したことを特徴とする自動取引装置。請求項1乃至4のいずれかに記載の自動取引装置において、誰も使用していないアイドル状態で、前記障害検知手段が復旧の必要な障害を検出したときには、前記情報収集手段が状態情報を収集し、前記情報解析手段が前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記復旧制御手段は該当する復旧制御手順を実行することを特徴とする自動取引装置。請求項5に記載の自動取引装置において、リソースメモリーの空き領域が一定値以下に減少した場合を、前記障害識別パラメータに含めておき、該当する障害復旧手順は、リブートを実行するとしたことを特徴とする自動取引装置。請求項5に記載の自動取引装置において、使用する媒体量の減少を含む、予め設定された装置の警戒レベルを示す情報を、前記情報収集手段が収集する状態情報に含め、前記警戒レベルを示す情報を前記障害識別パラメータに含めておき、該当する障害復旧手順は、前記警戒レベルを示す情報を含む出動要求メッセージを生成して、前記出動要求手段に対して、出動要求メッセージの送信を依頼するとしたことを特徴とする自動取引装置。請求項5乃至7のいずれかに記載の自動取引装置において、自動復旧制御に失敗をしたとき、もしくは、前記警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされたとき、前記復旧制御手段は、近接して配置された他の全ての自動取引装置が、使用可能な状態か使用不可能な状態か警戒レベルの状態かを示す装置稼働状態を取得し、自機を含めた使用不可能な状態もしくは警戒レベルの状態の自動取引装置の合計台数が限界値を越えた場合に限り、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。請求項5乃至7のいずれかに記載の自動取引装置において、自動復旧制御に失敗をしたとき、もしくは、前記復旧制御手段は、警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされた場合に、記憶装置に記憶されている巡回予定データを参照して、係員による巡回時までの時間が一定値以上の場合に限り、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。金融機関において、現金の入出金取引に使用される装置のコンピュータを、入出金取引業務のための処理を実行する業務アプリケーション実行手段と、障害の監視と復旧のための処理を実行する監視アプリケーション実行手段とを備え、前記業務アプリケーション実行手段から受信した障害発生通知を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する障害検知手段と、障害発生以前の動作履歴を含む、装置の状態情報を収集する情報収集手段と、装置で発生する障害の種別を認識するための障害識別パラメータと、該当する種別の障害に対する障害復旧手順を記憶する記憶装置と、前記情報収集手段が収集した状態情報の中に、前記記憶装置に記憶された障害識別パラメータが含まれているかどうかを判断する情報解析手段と、前記情報解析手段が、前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記記憶装置に記憶された該当する復旧制御手順を読み出して、その手順を実行する復旧制御手段と、前記情報解析手段が、前記状態情報の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワークを通じて係員の出動要求メッセージを送信する出動要求手段と、復旧制御手段または出動要求手段の処理結果報告をネットワークを通じて、送信する処理報告手段、として機能させる自動取引装置制御プログラム。請求項10に記載の自動取引装置制御プログラムを記録したコンピュータで読み取り可能な記録媒体。既知の従来の技術には、次のような解決すべき課題があった。自動取引装置の性能向上により、リモート操作で復旧するような簡単な障害は減少し、希に発生する障害は、係員が現場に出動しなければならないような種類のものが多い。このような、障害の発生時には、利用者を長時間待たせることなく、迅速に出動要請の要否を判断することが望まれる。更に、監視サーバや端末類を設置するので、監視システムへの投資や専任係員が必要である。規模の大きな金融機関では、何台もの監視サーバ等を設置し、多くの専任係員を配置するので、多額のコストが掛かるという問題があった。また、自動取引装置と監視サーバ間の通信が通信障害で途絶えると、リモート操作による障害対応が行えないという問題もある。上記の課題を解決するために、本発明は次のような自動取引装置を提供することを目的とする。1自動取引装置が、自動的に障害復旧のための処理を実行する。2必要な場合にすみやかに係員の出動要請を自動的に実行する。3自動復旧処理により、専任係員の負担を軽減し、監視コストを低減する。以下の構成はそれぞれ上記の課題を解決するための手段である。構成1金融機関において、現金の入出金取引に使用される装置であって、入出金取引業務のための処理を実行する業務アプリケーション実行手段と、障害の監視と復旧のための処理を実行する監視アプリケーション実行手段とを備え、前記業務アプリケーション実行手段から受信した障害発生通知を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する障害検知手段と、障害発生以前の動作履歴を含む、装置の状態情報を収集する情報収集手段と、装置で発生する障害の種別を認識するための障害識別パラメータと、該当する種別の障害に対する障害復旧手順を記憶する記憶装置と、前記情報収集手段が収集した状態情報の中に、前記記憶装置に記憶された障害識別パラメータが含まれているかどうかを判断する情報解析手段と、前記情報解析手段が、前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記記憶装置に記憶された該当する復旧制御手順を読み出して、その手順を実行する復旧制御手段と、前記情報解析手段が、前記状態情報の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワークを通じて係員の出動要求メッセージを送信する出動要求手段と、復旧制御手段または出動要求手段の処理結果報告をネットワークを通じて、送信する処理報告手段を備えたことを特徴とする自動取引装置。構成2構成1に記載の自動取引装置において、前記復旧制御手段による該当する障害復旧手順が正常に実行できないとき、前記情報収集手段は再び状態情報を収集し、前記情報解析手段が前記状態情報の中に新たな障害識別パラメータが含まれていると判断したとき、前記復旧制御手段は該当する復旧制御手順を実行することを特徴とする自動取引装置。構成3構成1または2に記載の自動取引装置において、前記復旧制御手段は、該当する障害復旧手順が正常に実行できないとき、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。構成4構成1乃至の3いずれかに記載の自動取引装置において、自動取引装置固有の障害を示す障害識別パラメータとその障害復旧手順を前記記憶装置に記憶したことを特徴とする自動取引装置。構成5構成1乃至4のいずれかに記載の自動取引装置において、誰も使用していないアイドル状態で、前記障害検知手段が復旧の必要な障害を検出したときには、前記情報収集手段が状態情報を収集し、前記情報解析手段が前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記復旧制御手段は該当する復旧制御手順を実行することを特徴とする自動取引装置。構成6構成5に記載の自動取引装置において、リソースメモリーの空き領域が一定値以下に減少した場合を、前記障害識別パラメータに含めておき、該当する障害復旧手順は、リブートを実行するとしたことを特徴とする自動取引装置。構成7構成5に記載の自動取引装置において、使用する媒体量の減少を含む、予め設定された装置の警戒レベルを示す情報を、前記情報収集手段が収集する状態情報に含め、前記警戒レベルを示す情報を前記障害識別パラメータに含めておき、該当する障害復旧手順は、前記警戒レベルを示す情報を含む出動要求メッセージを生成して、前記出動要求手段に対して、出動要求メッセージの送信を依頼するとしたことを特徴とする自動取引装置。構成8構成5乃至7のいずれかに記載の自動取引装置において、自動復旧制御に失敗をしたとき、もしくは、前記警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされたとき、前記復旧制御手段は、近接して配置された他の全ての自動取引装置が、使用可能な状態か使用不可能な状態か警戒レベルの状態かを示す装置稼働状態を取得し、自機を含めた使用不可能な状態もしくは警戒レベルの状態の自動取引装置の合計台数が限界値を越えた場合に限り、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。構成9構成5乃至7のいずれかに記載の自動取引装置において、自動復旧制御に失敗をしたとき、もしくは、前記復旧制御手段は、警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされた場合に、記憶装置に記憶されている巡回予定データを参照して、係員による巡回時までの時間が一定値以上の場合に限り、前記出動要求手段に対して、出動要求メッセージの送信を依頼することを特徴とする自動取引装置。構成10金融機関において、現金の入出金取引に使用される装置のコンピュータを、入出金取引業務のための処理を実行する業務アプリケーション実行手段と、障害の監視と復旧のための処理を実行する監視アプリケーション実行手段とを備え、前記業務アプリケーション実行手段から受信した障害発生通知を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する障害検知手段と、障害発生以前の動作履歴を含む、装置の状態情報を収集する情報収集手段と、装置で発生する障害の種別を認識するための障害識別パラメータと、該当する種別の障害に対する障害復旧手順を記憶する記憶装置と、前記情報収集手段が収集した状態情報の中に、前記記憶装置に記憶された障害識別パラメータが含まれているかどうかを判断する情報解析手段と、前記情報解析手段が、前記状態情報の中に前記障害識別パラメータが含まれていると判断したとき、前記記憶装置に記憶された該当する復旧制御手順を読み出して、その手順を実行する復旧制御手段と、前記情報解析手段が、前記状態情報の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワークを通じて係員の出動要求メッセージを送信する出動要求手段と、復旧制御手段または出動要求手段の処理結果報告をネットワークを通じて、送信する処理報告手段、として機能させる自動取引装置制御プログラム。構成11構成10に記載の自動取引装置制御プログラムを記録したコンピュータで読み取り可能な記録媒体。構成1の効果障害識別パラメータにより自動復旧が可能と判断した障害について、記憶装置に記憶された該当する復旧制御手順に従って自動的に障害復旧処理をするので、監視端末側の負担を軽減できる。さらに障害の種別によっては、係員が対応するよりも素早く的確に復旧ができる。また、障害の診断から係員の出動要求までの時間を短縮して、利用者の待ち時間を少なくできる。構成2の効果障害復旧手順を実行中に障害復旧に失敗することがある。このとき、再度状態情報を収集して、自動復旧を試みることができる。新たな障害識別パラメータが見つかれば、別の障害復旧手順を実行できる。構成3の効果自動復旧制御に失敗をしたときに、自動的に出動要求メッセージを送信して、迅速に係員を派遣できる。構成4の効果自動取引装置の内部に監視アプリケーション実行手段を設けるので、それぞれ機種の異なる自動取引装置について、固有の障害も自動的に復旧できる。構成5の効果誰も使用していないアイドル状態で復旧の必要な障害を検出したときには、自動的に復旧処理を実行する。構成6の効果リソースが減少すると、その後障害が発生する確率が高いので、これを障害発生と判断して、自動復旧させる。従って、利用時の障害発生を未然に防ぐことができる。構成7の効果紙幣等の媒体量の減少を示す情報を、警戒レベルを示す情報と呼ぶとき、この情報が状態情報に含まれている場合には、警戒レベルを示す情報を含む出動要求メッセージを生成する。その後、所定のタイミングで自動的に出動要求メッセージの送信を依頼する。構成8の効果無人店舗等で、近接して複数台の自動取引装置が配置されているときに、例えば、1台だけなら、使用不可能な状態あるいは警戒レベルの状態のままでも良い場合がある。このとき、ただちに出動要求メッセージを送信せずに待機する。これで、出動要求の頻度を低下させられる。構成9の効果間もなく次回の巡回があるような場合には、出動要請を見合わせることができる。図1は、本発明の自動取引装置の具体例を示す概略機能ブロック図である。図に示す例では、金融機関のある無人店舗に、4台の自動取引装置12ATMが内部LAN14を介して配置されている。そのうちの一台について、図の右側の一点鎖線の円内にその機能ブロックを図示した。例えば、4台の自動取引装置12は、互いに内部LAN14により接続されている。そして、全ての自動取引装置12が、図の一点鎖線の円内の構成を備えるものとする。自動取引装置12は、ネットワークインタフェースを介してネットワーク16に接続されている。ネットワーク16には、自動取引装置12を遠隔監視するために、監視端末18が接続されている。監視端末18は監視員60により操作される。監視員60は、自動取引装置12の状態を監視して、必要に応じて、障害の復旧処理を実行する。監視端末18には、情報を記憶するために、管理データ記憶装置20が接続されている。また、障害復旧のために出動する係員は、携帯端末17を所持している。携帯端末17には、ネットワーク16を通じて出動要求メッセージ41が届く構成になっている。自動取引装置12は利用者62により利用される。自動取引装置12を動作させるために、記憶装置22と演算処理装置24とが設けられている。記憶装置22は障害発生通知30、処理結果報告31、状態情報32、障害情報34、障害識別パラメータ36、障害復旧手順38、巡回予定データ40、出動要求メッセージ41、装置稼働状態42等を記憶する。演算処理装置24は、業務アプリケーション実行手段26、監視アプリケーション実行手段28等の機能ブロックを有する。監視アプリケーション実行手段28は、障害検知手段44、情報収集手段46、情報解析手段48、復旧制御手段50、認証処理手段52、出動要求手段54、結果報告手段56等を含んでいる。本発明では、金融機関等で使用され、現金の入出金取引に使用される自動取引装置12に対して、障害の自動復旧のための各種機能を付与する。このために、障害発生時に自動取引装置12の内部の詳細な情報を取得して、自動的に障害復旧処理を実行する手段を設ける。自動復旧後は、リモート監視端末18に対して、その処理結果を通知する。これにより、リモート監視端末18側で、係員による確認作業ができる。即ち、各自動取引装置12が、自動的に障害発生を検出して、自動的に障害復旧処理を起動し実行する。障害の検知自動取引装置12は、入出金取引業務のための処理を実行する業務アプリケーション実行手段26と、障害の監視と復旧のための処理を実行する監視アプリケーション実行手段28とを備える。業務アプリケーション実行手段26は、自動取引装置12での入出金取引などの取引業務を実行する。取引業務の制御の際に障害が発生すると、監視アプリケーション実行手段28に障害発生通知30を送信する。同時に、障害を検出したときに得られた障害情報34を監視アプリケーション実行手段28に送信する。そして、監視アプリケーション実行手段28からの通知を待つ。監視アプリケーション実行手段28は、常時、業務アプリケーション実行手段26の動作を監視している。業務アプリケーション実行手段26から障害発生通知30を受信したら、障害復旧処理を自動的に開始する。例えば、自動取引装置12の利用者62が現金入出金処理中に、紙幣の繰り出し障害や紙幣切れ障害等が発生した場合に障害発生となる。また、自動取引装置12を誰も使用していないアイドル状態でも、障害が発生することがある。例えば、業務アプリケーション実行手段26の誤動作や停止、システムリソースの不足、媒体不足、搬送ベルト劣化等については、監視アプリケーション実行手段28が、自ら、所定の部位の情報を読み取って、障害の発生を検出する。監視アプリケーション実行手段28が監視すべき所定の部位は、予め特定されている。例えば、装置各部のセンサの出力信号やカウンタの出力信号を記憶しておくための記憶領域を、一定時間おきに読み取って、障害の発生を検出する。監視アプリケーション実行手段28は、以上の障害検知のための処理を実行するために、障害検知手段44を備える。また、障害が検出されると、情報収集手段46により情報の収集が行われる。その後、情報解析手段48により、復旧手順が選択され、復旧制御手段50により、予め設定された自動復旧手順で復旧処理が実行される。自動復旧手順が設定されていない障害のときや、自動復旧に失敗したときには、係員に対して現場に出動するように要請する通信文を送信する。同時に、監視アプリケーション実行手段28から業務アプリケーションに対して、係員に出動要請メッセージを送信した旨の通知をする。情報の収集業務アプリケーション実行手段26は、障害発生通知30とともに、監視アプリケーション実行手段28に対して、所定の障害情報34を送信する。ここで、予め設定された手順で自動復旧できる障害と、自動復旧できない障害とがある。監視アプリケーション実行手段28に設けられた情報収集手段46は、必要な情報を独自に収集し、情報解析手段48は、収集した情報を独自に解析して、障害の種類を判断する。例えば、情報収集手段46は、障害発生以前の動作履歴を含む状態情報32を収集する。自動取引装置12本体の内部で収集できる状態情報32は、装置に設けられた全てのセンサの出力信号や、カード挿入や現金投入等の各種イベントが発生したときの装置各部の全ての動作履歴等がある。自動的に収集する場合には、可能な限り広く情報を収集することが好ましい。例えば、障害検出時の装置各部の状態情報と、例えば、主要な媒体センサの状態遷移を取得して、全ての状態情報を時間軸で整合させて配列する。自動取引装置自身が装置内部で情報収集をするので、詳細で大量の情報を取得できる。これに、業務アプリケーションから出力されるエラーコードを含めれば、発生した障害を非常に正確に判断できる。情報の解析収集した情報全てを解析して、障害の種別を判断するプログラムの設計は容易ではない。全自動で確実に復旧できる障害の範囲は限定されるから、この範囲の障害かどうかだけを判断する機能を持てばよい。判断できる障害を一定の範囲に限定して、その他の障害は、種別不明として取り扱えば、処理が簡単で確実になる。このために、一定の範囲の障害を特定できるような障害識別パラメータ36のリストを準備する。従来は業務アプリケーション実行手段からの報告を見て、係員が障害の種別を判断していた。障害の自動検出のために、既存の業務アプリケーションを書き換える必要はない。収集する状態情報と、障害識別パラメータ36を十分なものに設定しておくだけでよい。障害の検出には、取得した状態情報32に、いずれかの障害識別パラメータ36が含まれているかどうかを判定する。自動的に画一的に状態情報を収集するのが好ましい。状態情報32には障害と無関係な情報が多数含まれていて構わない。障害識別パラメータ36は、例えば、エラーコードと、特定の場所のセンサの出力や状態遷移と、特定のカウンタやレジスタの数値といった内容になる。即ち、エラーコードが111で、媒体出口側の媒体センサがON-OFF-ONと変化し、出力媒体数量が5で排出カウンタの数値が0というデータが状態情報に含まれていれば、該当する媒体が媒体出口で滞留しており、排出が完了していないという障害と判断される。その場合には、該当する媒体を5枚排出すれば障害が復旧できる。障害識別パラメータ36の情報量が多ければ、それだけ正確に障害の種別を正確に判断できる。障害検出の対象となる自動取引装置12は必ずしも全て同一の機種で、同一のメーカーのものとは限らない。各自動取引装置12が機種毎に固有の障害パターンを有する場合でも、それらを区別できる障害識別パラメータ36を準備しておけばよい。自動復旧できる障害の種類が増えたときには、障害識別パラメータ36のリストを追加するだけでよいから、メンテナンスが非常に容易な効果がある。障害復旧手順の選択取得した状態情報32に、いずれかの障害識別パラメータ36が含まれていたときには、該当する障害復旧手順38を選択して、復旧処理を実行させる。この制御のために、監視アプリケーション実行手段28は、復旧制御手段50を備える。復旧制御手段50は、障害識別パラメータ36と障害復旧手順38を対応付けた自動処理テーブルを参照する。図2は、自動処理テーブルの内容例説明図である。例えば、図のように、取引区分が入金や出金といった種類では、自動取引装置側と金融機関のホストコンピュータ19図1側の取引成立の可否、障害コード、装置内部の残留媒体の種類と有無、および、本人確認処理ができたかどうかという障害識別パラメータ36により、障害復旧手順38が決まる。障害復旧手順38は、処理パターンIDで特定される。自動処理テーブル39は、このように、障害識別パラメータ36と障害復旧手順38を対応付けるデータである。なお、障害復旧手順38はコマンドの集合でもよいし、復旧処理プログラムを記述したものでもよい。図3は、障害識別パラメータから障害復旧手順を得る処理の説明図である。図に示すように、自動処理テーブル39には、障害識別パラメータ36と障害復旧手順38とが対応付けられたデータがある。自動的に障害復旧処理をすることができるのはこれで全部である。従って、自動処理テーブル39中の全ての障害識別パラメータ36を順番に読み出して、自動取引装置の各部から収集した状態情報32中に、いずれかの障害識別パラメータ36が含まれているかどうか判断する。こうして、処理パターンIDを取得する。図の右側の処理パターンマスタから、各処理パターンIDに対して、実行すべきコマンドコードを順番に読み出すことができる。コマンドコードの内容は、図のコマンドマスタを参照する。障害復旧手順38は、このように、コマンドの集合として取り出される。復旧制御手段50は、該当する障害復旧手順38を読み出して、順番に装置各部にコマンドを送信し、復旧処理を実行する。障害復旧手順38の中には、利用者62に対するメッセージの出力処理も含まれるとよい。利用者62に対して、障害の種別や障害復旧の手順、待機時間等の案内を出力することが好ましい。画面に文字で表示してもよいし、音声で出力するようにしてもよい。障害復旧手順38には、例えば、本人確認処理、勘定系への取引結果の取消要求送信、装置内部に残留した銀行カード等の媒体返却、障害復旧処理の完了報告といった処理が含まれる。これらの処理を全て自動的に実行する。また、自動的に実行しても、確実で問題が生じる心配の無い障害だけを、障害識別パラメータ36のリストに含めるとよい。障害の種類と復旧方法障害の種類には、取引開始以前のアイドル状態で検出される障害と取引開始後に発生する障害がある。アイドル状態で検出される障害には、既に使用できない状態にあるものだけでなく、障害発生を予告すべき状態にあるものも含めることにする。取引開始後の障害には、銀行カードや現金等の取込前で発生した障害や銀行カードや現金等の取込後発生した障害などがある。前者の場合には、リセットをして最初から取引を開始できる状態に復旧できればよい。一方、後者の場合には、開始された取引がどこで中断したかを確認して、取引前の状態に戻す対応を行う。生態認証や暗証番号による本人確認を実行して、その後、カードや入金紙幣を利用者62に返還する。明細票レシート、出金紙幣は自動取引装置12に回収し、最後にリセットして障害復旧させる。処理が完了後は、結果報告手段56が処理結果報告31を生成して、監視端末18に送信する。係員の出動要求障害復旧の過程で、処理が正常に終了しないような場合には、自動復旧が困難と判断して、係員の出動要求メッセージ41の送信をする。復旧制御手段50による該当する障害復旧手順38が正常に実行できないとき、情報収集手段46が再び状態情報32を収集してもよい。いわゆる2次障害が発生した場合である。この状態情報32の中に新たな障害識別パラメータ36が含まれていると判断されたら、新たな復旧制御手順38を実行するとよい。情報収集手段46が取得した状態情報32に、予め用意したどの障害識別パラメータ36も含まれていないと判定されたときには、想定外の障害として係員の出動要求処理を行う。即ち、出動要求手段54が出動要求メッセージ41を生成して、携帯端末17に送信する。誰も使用していないアイドル状態で、障害検知手段44が復旧の必要な障害を検出することがある。例えば、搬送ベルト等の劣化、センサー異常等を検出したときである。このとき、情報収集手段46が状態情報32を収集する。情報解析手段48がこの状態情報32の中に障害識別パラメータ36が含まれていると判断したとき、復旧制御手段50は該当する復旧制御手順38を実行する。出動要求メッセージ41には、収集した状態情報32を含めるとよい。自動的に、出動要求メッセージ41を生成して、該当する宛先に送信する。電話、FAX、メール等の送信手段を利用するとよい。利用者62による取引開始後の障害で、係員の出動要求処理を実行するときには、自動取引装置12のディスプレイに待機依頼メッセージを表示し、あるいは、間もなく係員がまいりますので暫くお待ち下さいといった音声案内をする。上記の処理では、取得した状態情報32に、限定された障害識別パラメータ36が含まれているかどうかを判断するだけなので、きわめて迅速に係員の出動要求処理を実行できる。従って、利用者62を長時間待たせないという効果がある。誰も使用していないアイドル状態で、ただちに使用不能になるわけではないが、いずれ障害に至るような状態が検出されることがある。例えば、リソースメモリーの空き領域が一定値以下に減少したような場合が該当する。この場合には、リブートを実行すると自動的に健全な状態にモードすることができる。そこで、リソースが一定値以下に減少した状態を、障害識別パラメータに含めておく。そして、該当する障害復旧手順にはリブートを実行するコマンドを設定する。これで、利用時の障害発生を未然に防ぐことができる。一方、使用する媒体、例えば、紙幣の量が減少して、ニアエンドの状態になったといった状態がある。この状態も、まだ取引が可能であって、ただちに使用不能になるわけではないが、いずれ障害に至るような状態である。こうした状態を予め設定しておき、装置の警戒レベルを示す情報とする。情報収集手段46は、この警戒レベルを示す情報も状態情報32に含めて収集する。同時に、警戒レベルを示す情報を前記障害識別パラメータに含めておく。原則として、警戒レベルを障害と同様に取り扱う。該当する障害復旧手順は、警戒レベルを示す情報を含む出動要求メッセージ41を生成して、復旧制御手段50は、出動要求手段54に対して、出動要求メッセージ41の送信を依頼するという内容にする。この処理も、広い意味の障害復旧手順とすればよい。なお、アイドル状態で、警戒レベルを示す情報を含む出動要求メッセージを送信するという判断がされたときには、すぐに係員の出動要求を実行せず、残りの装置の状態を比較する。記憶装置22には、自機及び周辺の他の自動取引装置の装置稼働状態42が記憶されている。装置稼働状態42は、少なくとも、各装置が、取引可能な状態にあるか、メンテナンス中あるいは障害により取引できない状態にあるか、警戒レベルの状態にあるか等の情報を含むものとする。例えば、5台の自動取引装置12が設置された無人店舗で、1台の自動取引装置12について障害が発生していても、残りの4台の装置が正常に動作できる場合がある。このときには、係員の出動要求処理を見合わせて、障害を検出した装置を使用できない状態にして待機させる。もう1台、出動要求をすべき障害が発生したときには、係員の出動要求処理を実行する。また、次回の巡回点検スケジュールまでの時間が一定値以下の場合には、係員出動要求を見合わせる。これにより、係員の出動回数を減少させることができる。即ち、自機を含めた使用不可能な状態もしくは警戒レベルの状態の自動取引装置の合計台数が限界値を越えた場合に限り、出動要求手段54に対して、出動要求メッセージの送信を依頼する。出動要求メッセージには、使用が不可能な状態の自動取引装置や、警戒レベルの状態の自動取引装置の情報を含める。従来は、業務アプリケーションから監視端末側に送信されるエラーコードに基づいて、障害の種類を知り、監視員が自動取引装置にコマンドを送信して復旧操作をしていた。このとき、必要に応じて、自動取引装置から他の情報も取得して、復旧操作の方針を決定していた。監視対象として、様々な機種の自動取引装置が混在する場合も少なくない。従って、機種毎に復旧操作のためのマニュアルを準備して対応していた。一方、本発明では、各自動取引装置がそれぞれ自動的に独自に復旧処理を実行する。即ち、全ての自動取引装置に自動復旧プログラムをインストールする。機種の異なる自動取引装置が混在する場合には、それぞれ自動復旧のための手順が異なることがある。しかし、機種毎にそれぞれ別々の自動復旧プログラムを作成していては、プログラム作成コストも管理コストも莫大になる。そこで、本発明では、上記のように、障害が検知されると、無条件に画一的に装置各部の状態情報を取得するように制御する。そして、収集した状態情報の中に、障害識別パラメータが存在するかどうかを判断する。障害識別パラメータと障害復旧手順は機種毎に具体的に詳細に設定しておく。しかし、障害復旧を制御するための各プログラムは、ほぼ全ての機種に共通化することができる。従って、異なる機種の自動取引装置が混在する環境において、低コストで自動復旧プログラムを開発し監理運営することができる。以上が、本発明の概略説明である。以下、本発明の実施の形態を実施例毎に詳細に説明する。ここで、図1に示した各機能ブロックの基本的な機能を整理してから、具体的な動作の説明をする。業務アプリケーション実行手段26は、金融機関において、現金の入出金取引に使用される装置であって、入出金取引業務のための処理を実行する機能を持つ。監視アプリケーション実行手段28は、障害の監視と復旧のための処理を実行する機能を持つ。障害検知手段44は、業務アプリケーション実行手段26から受信した障害発生通知30を受信し、もしくは、予め特定された部位の情報を読み取って、障害の発生を検出する機能を持つ。情報収集手段46は、障害発生以前の動作履歴を含む、装置の状態情報32を収集する機能を持つ。記憶装置22に記憶された障害識別パラメータは、装置で発生する障害の種別を認識するためのものである。情報解析手段48は、情報収集手段46が収集した状態情報32の中に、記憶装置22に記憶された障害識別パラメータ36が含まれているかどうかを判断する機能を持つ。復旧制御手段50は、情報解析手段48が、状態情報32の中に障害識別パラメータが含まれていると判断したとき、記憶装置22に記憶された該当する復旧制御手順を読み出して、その手順を実行する機能を持つ。出動要求手段54は、情報解析手段48が、状態情報32の中にどの障害識別パラメータも含まれていないと判断したとき、ネットワーク16を通じて係員の出動要求メッセージ41を送信する機能を持つ。処理報告手段56は、復旧制御手段50または出動要求手段54の処理結果報告31をネットワーク16を通じて送信する機能を持つ。以上の装置は、障害識別パラメータにより自動復旧が可能と判断した障害について、記憶装置22に記憶された該当する復旧制御手順に従って自動的に障害復旧処理をするので、監視端末18側の負担を軽減できる。また、自動復旧できるものを限定しており、該当しない場合には直ちに係員の出動要求をするので、障害の診断から係員の出動要求までの時間を短縮して、利用者62の待ち時間を少なくできる。さらに、個々の自動取引装置固有の障害がある場合には、その自動復旧手順も記憶させておくことができる。なお、自動復旧処理に途中で失敗した場合に、再度新たな障害識別パラメータ36が含まれているかどうかを判断するとよい。例えば、返却のため搬送中のカードや紙幣がうまく搬送されなかったとき、該当する障害識別パラメータが準備されていれば、対応する復旧手順を実行して、自動復旧を完結させることができる。図4から図8までは障害復旧処理のシーケンスチャートである。ここでは、業務アプリケーション実行手段26と監視アプリケーション実行手段28とが連携して障害の復旧処理を実行する。ミドルウエア58は、業務アプリケーション実行手段26が自動取引装置12の画面を制御するためのインタフェースに相当する機能を持つ。ミドルウエア58は、また、自動取引装置12の各部のハードウエアやセンサ等と業務アプリケーション実行手段26とを制御するインタフェースである。ドライバに近い動作をする。APLは、アプリケーション実行手段の略である。図4~8は、いずれも、上から下に向かって時間が経過するものとする。以下、時間の経過を追って、各部の動作を説明する。まず、ミドルウエア58がセンサその他の信号を取得して、その内容から、障害検知がされる。図4では、ミドルウエア58から業務アプリケーション実行手段26に障害発生通知がされ、それが監視アプリケーション実行手段28に伝達される。この部分の伝達情報の内容は任意である。障害が発生した旨の通知が監視アプリケーション実行手段28に伝達されればよい。これを監視アプリケーション実行手段28の障害検知手段44が受信する。図4は媒体を返却する障害自動復旧シーケンスチャートである。例えば、入金取引を中止した際に、返却された紙幣の一部分を取り忘れて紙幣が残留しているといった情報が業務アプリケーション実行手段26に通知される。業務アプリケーション実行手段26は障害発生通知を監視アプリケーション実行手段28に対して行う。次に、監視アプリケーション実行手段28の情報収集手段46は情報収集を開始する。図4の例では、情報収集の一部を業務アプリケーション実行手段26に依頼している。業務アプリケーション実行手段26は、勘定データを取得し、取引ステータスを確認し、取引装置側での処理が正常に終了しているのか、勘定系のホストコンピュータ19図1側での処理が成立しているのかといった情報を収集する。監視アプリケーション実行手段28の復旧制御手段50は、自機が障害で取引できない状態になったので、装置稼働状態42の内容を変更する処理を実行する。次に、認証処理手段52が、障害発生後に自動取引装置12の前で待機している利用者62に対する認証処理を行う。処理内容は取引開始時の認証処理と全く同一である。従って、この処理も復旧制御手段50が業務アプリケーション実行手段26に依頼する。即ち、暗証入力用の画面を表示させ、暗証番号の入力を受け付ける。そして、残照電文を使用して暗証確認処理を実行する。認証処理が正常に終了すると、自動取引装置12の画面に、障害が発生して復旧処理中である旨のメッセージ等障害画面を表示する。認証処理が正常に終了した後、その結果が業務アプリケーション実行手段26から監視アプリケーション実行手段28に通知される。同時に業務アプリケーション実行手段26から監視アプリケーション実行手段28に対して、自動処理の要求と、取得した障害情報が送信される。図4の右下の部分で、監視アプリケーション実行手段28の情報解析手段48は、既に説明した自動処理テーブル39を利用して、障害復旧手順38を取得する。図5は障害復旧手順が実行されるときのシーケンスチャートである。次に図5の処理に進む。監視アプリケーション実行手段28の復旧制御手段50は、取得したコマンドを順番に発行する。例えば、この図では、始めに、紙幣を返却するというコマンドを発行する。同時に、自動取引装置12の画面に、紙幣が出ますのでお取り下さいといったメッセージを表示するよう業務アプリケーション実行手段26に指示する。コマンドは、監視アプリケーション実行手段28から業務アプリケーション実行手段26を介してミドルウエア58に転送される。ミドルウエア58は紙幣投入口を開いて利用者に紙幣を返却する。コマンドが正常に実行されたというコマンド応答が監視アプリケーション実行手段28に返される。次に、監視アプリケーション実行手段28は、取引の結果を印刷した明細票レシートを回収するというコマンドを発行する。明細票回収についても、正常に実行された旨のコマンド応答が監視アプリケーション実行手段28に返される。さらに、監視アプリケーション実行手段28は、リセットをするというコマンドを発行する。リセットが正常に実行された旨のコマンド応答が監視アプリケーション実行手段28に返される。以上のような処理に続いて、監視アプリケーション実行手段28の復旧制御手段50は、これで自動障害復旧処理が完了したと判断して、自機が正常に動作できるというように、装置稼働状態42を修正する。その後、業務アプリケーション実行手段26に制御を返すため、自動処理応答をする。業務アプリケーション実行手段26は、自動取引装置12の画面を通常の取引画面にして表示する。また、監視アプリケーション実行手段28の処理報告手段は、監視端末18に対して、処理結果報告31を送信する。図では、監視端末18の表示画面の更新通知をしている。この画面の例は図9で説明する。図6は利用者が離れた後の媒体を返却しない障害自動復旧シーケンスチャートである。中段の取引ステータス確認処理までは、図4の場合と同様の処理が行われる。図4の例では、監視端末18に対して、監視画面の更新のための更新通知が送信された。しかしながら、図6の場合は監視アプリケーションで監視端末への更新は不要と判断したため更新通知は送信していない。監視端末18の操作画面上で、任意のタイミングで画面更新ボタンが押下げられると、画面の更新がされる。この場合、取引が成立しているが、出金全額の取り忘れが生じている。従って、まず、取引勘定を取消す処理を実行している。その後、自動処理テーブルに含まれた該当する障害識別パラメータ36により、障害復旧手順が出力された。紙幣を金庫に収納して戻し、明細票レシートを回収し、装置をリセットするというコマンドが順番に送信される。その流れは、図5で説明したとおりである。ここでは、詳細な図示は省略した。なお、この例では、自動復旧処理が開始される前に、業務アプリケーション実行手段26が取引の取消処理を実行している。これは、業務アプリケーション実行手段26の既存の機能をそのまま利用したものである。監視アプリケーション実行手段28が業務アプリケーション実行手段26から障害通知を受信した後、状態情報を収集して、ただちに自動処理テーブルを利用した障害識別パラメータ36の検索をして、取引取消しというコマンドを含む障害復旧手順を取得するようにして構わない。図6の後段の処理も、図5の後段の処理と同一であるから、一部図示を省略し、具体的な説明も省略する。図7は、出動要求をする場合のシーケンスチャートである。自動処理テーブルを利用して障害復旧手順を取得し、監視アプリケーション実行手段28の復旧制御手段50が、該当するコマンドを送出するところまでは、図6の例と変わらない。ここで、ミドルウエア58がそのコマンドを受け付けたところ、何らかの原因で、いずれかのコマンドに対する処理に失敗したとする。この例では自動復旧処理において紙幣の収納、明細票レシートの回収あるいはリセット処理に失敗したということになる。このときは、ミドルウエア58から監視アプリケーション実行手段28に対し障害復旧処理に失敗したというコマンド応答が送信される。この場合には監視アプリケーション実行手段28から業務アプリケーション実行手段26に対し障害復旧失敗の応答がなされる。同時に監視アプリケーション実行手段28の出動要求手段54から携帯端末17に対して、出動要求メッセージ41がネットワーク16を通じて送信される。図8は、出動要求メッセージ送信後のシーケンスチャートである。監視アプリケーション実行手段28から監視端末18に対し画面の更新通知が行われる。監視端末18では監視画面を更新する。また、業務アプリケーション実行手段26は自動取引装置の画面に、出動要求中という案内表示を行う。利用者に、障害復旧中で取引出来ない状態にあることを伝えるためである。また、出動要求メッセージ41を送信すると、係員からの返信によって到着予定時刻が通知される。それが監視アプリケーション実行手段28から業務アプリケーション実行手段26に送信される。業務アプリケーション実行手段26は自動取引装置の画面に、係員の到着予定時刻を表示する。即ち、係員の予定時間を示す画面を表示する。同時に監視アプリケーション実行手段28は監視端末18に対し係員の到着予定時刻を通知して、監視端末18の監視画面が更新される。係員が現場に到着すると、自動取引装置を点検モードにする。ミドルウエア58はこのタイミングで、係員の入店検知を行い、自動的に入店通知が業務アプリケーション実行手段26に送信される。入店通知は業務アプリケーション実行手段26から監視アプリケーション実行手段28に送信され、さらに、監視アプリケーション実行手段28から監視端末18に送信される。これで、監視端末18の監視画面が更新される。即ち、監視端末18では現在係員が障害復旧処理中という内容の画面が表示される。その後、障害が除去されて、係員が自動取引装置を点検モードから通常モードに切り替えると、ミドルウエア58はそのタイミングで退店を検知する。退店通知は業務アプリケーション実行手段26を経由して監視アプリケーション実行手段28に送信され、監視端末18に転送されて監視画面が更新される。また、自動取引装置の画面が正常の取引画面に戻る。図9は監視端末18の表示画面の具体例説明図である。図1に示した監視端末18には、例えば、図9に示したような画面が表示される。これを監視員60が監視することにより、無人店舗等において、障害が発生した自動取引装置とその自動復旧処理の状況を常時確認できる。即ち、自動取引装置を設置した各店舗についてその障害の発生時刻、係員に対する出動要求をした依頼時刻などが表示されている。この内容は、既に図4~図8のシーケンスチャートで説明したとおり、監視対象の自動取引装置の状態変化に応じて時々刻々と更新される。従来は障害が発生するとその自動取引装置からの通知を受けて係員が対応していた。この発明では、図に示すような画面に、各装置が自動的に障害を復旧しあるいは自動的に係員に出動要求をした状態が一覧表示される。図10は出動の各状態が起きた時刻、障害からの復旧時刻を示す画面である。これも監視端末18に表示される。図に示すように、障害が発生した自動取引装置について、係員が到着する予定時刻、入店時刻、退店時刻、障害復旧処理が完了して自動取引装置が取引可能な状態なった時刻などが一覧で表示されるようになっている。これにより、監視対象が増加した場合でも、監視端末18側の係員は、自動復旧処理が出来ないものにだけ対応をすればよいので、負荷が軽減される。また、自動復旧できるかどうかの判断が早いので、すみやかに係員の出動要求ができ、顧客を長時間待たせないで、サービスの向上が図れる。図11以下は装置の具体的な動作フローチャートである。図11と図12は障害検出動作を示すメインルーチンである。業務アプリケーション実行手段26と監視アプリケーション実行手段28の動作を特に区別しないで説明する。これらの間の処理のシーケンスは図4等で説明したとおりである。まず、ステップS11では、装置各部からの障害通知を受信する待ち受け状態にある。ステップS12で、障害検知手段44が障害発生通知を受けると、ステップS13で取引装置の画面の切り替えを実行する。次に、情報収集手段46が、ステップS14でホストコンピュータからの情報を収集する。即ち、ホストコンピュータから取引成否の情報を取得する。障害通知を受信すると同時に、障害情報を受信することができる。さらにどのような情報を収集すべきか判断をしなくてもよい。予め定められた範囲の情報を収集するとよい。情報解析手段48は、収集した情報の中に、障害識別パラメータ36と一致しているものが含まれるかどうかを判断する。次に、認証処理手段52は、認証処理を開始する。ステップS15で暗証入力画面を表示しステップS16で暗証入力を待つ。ステップS17で暗証入力を検知するとステップS18でその入力データに基づきホストコンピュータに暗証確認を行う。ここで本人確認のための認証が終了するとステップS19において、自動取引装置の画面に障害を自動的に復旧する旨のメッセージを表示する。ここから、復旧制御手段50による障害復旧処理が開始される。ステップS20において本人確認が正常に終了したかどうかを判断する。本人確認が正常終了した場合にはステップS21に進み、それ以外の場合には、ステップS31へ進む。ステップS21で、障害復旧手順に基づいて、ホストコンピュータにおける取引の成否について修正処理を実行する。さらに、ステップS22から、復旧のためのコマンドにより修正処理が実行される。取引修正処理ができない場合には、ステップS31へ進む。ステップS23~25で、復旧指示のためのコマンドを送信し、応答を待ち、コマンドが正常に処理されたかどうか応答を検知する。そして、ステップS26で、応答が正常かどうかを判断して、正常な場合には、障害復旧処理が完了したとして、ステップS27に進む。ステップS27では、自動取引装置の画面を切り替えて、通常の取引画面に戻す。ステップS20で本人確認に失敗した場合と、ステップS22で取引修正ができない場合と、ステップS26で処理に失敗をした旨のコマンドの応答があったときは、ステップS31に進む。ステップS31以下は、出動要求手段54よる係員の出動要求処理である。図13は出動要求処理の動作フローチャートである。出動要求手段54はステップS32において警備端末から、あるいは係員かセンタから係員到着予定時刻の入力を待つ。ステップS33で到着予定時刻の入力が検知されると、ステップS34でATMの画面に到着予定時間を表示する。ステップS35では係員の入店通知を待ち、ステップS36で入店を検知するとステップS37でその結果を取得する。そして、ステップS38で、監視端末18に係員が入店したことを示す画面を表示する。ステップS39では係員の退店通知を待ち、ステップS40で退店を検知するとステップS41でその結果を取得する。ステップS42では係員が退店した旨の画面を、監視端末18に表示する。これで、自動取引装置が復旧したから、ステップS42で、自動取引装置を取引可能な状態の画面に戻す。図14は障害復旧処理動作の具体的なフローチャートである。ステップS51で自動復旧処理の要求を待つ。ステップS52で自動復旧処理の要求を検知すると、復旧制御手段50はその状態を監視端末18に通知する。そして、ステップS54で装置稼働状態42の内容を更新する。ここで情報収集手段46が必要な情報を収集し、ステップS55で情報解析手段48が障害識別パラメータ36を利用して対応する障害復旧手順38を検索する。ステップS57で、取得された障害復旧手順38から復旧処理のためのコマンドが生成される。ステップS58では該当するコマンドがミドルウエア58に送信される。ステップS59でミドルウエア58からの応答を待ち、ステップS60で応答を検知すると、ステップS61の判断をする。送信したコマンドに対し正常な応答が返ってきた場合には次のコマンドを送信する。ステップS62で全てのコマンドの送信が終了されたかどうかを判断する。残りのコマンドがあれば、ステップS58からステップS60の処理が繰り返される。図15は、係員の出動要求の前半処理フローチャートである。復旧制御手段50は、該当する障害復旧手順38が障害復旧手順38を正常に実行できないとき、出動要求手段54に対して、出動要求メッセージ41の送信を依頼する。即ち、いずれかのコマンドの応答が正常でない場合にはステップS61からステップS70に進み係員の出動要求処理に進む。全てのコマンドが送信され正常に応答がされた場合には、ステップS63において監視アプリケーション実行手段28から業務アプリケーション実行手段26に対して、正常に復旧処理が終了した旨の通知が行われる。その後、ステップS64で、自動取引装置の状態を更新し、装置稼働状態42に記録する。ステップS70で自動処理のコマンド処理に失敗したと判断された場合には、ステップS71で自動取引装置のステータスを更新し、ステップS72で装置稼働状態42を更新する。また、ステップS73で出動要求手段54が出動要求メッセージを送信しステップS74で係員の到着予定時刻の通知を待つ。ステップS75と76で装置稼働状態42を更新する。ステップS77で到着予定時刻の通知を検知すると、ステップS78と79で装置稼働状態42を更新する。これで、係員の入店待ちの状態になる。図16は係員の出動要求の後半処理フローチャートである。ステップS80で係員の到着予定時刻が監視アプリケーション実行手段28から業務アプリケーション実行手段26に通知される。ステップS81では業務アプリケーション実行手段26から監視アプリケーション実行手段28への係員の入店通知を待つ。ステップS82で入店通知を検知するとステップS83で、装置稼働状態を更新することを、監視端末18に通知する。ステップS84で装置稼働状態42を更新しステップS85に進む。ステップS85で入店通知を受け付けて、ステップS86で退店通知を待つ状態になる。ステップS87で退店通知を受信すると、ステップS87で警備センタに対し退店通知を送信する。これは警備センタにおける係員の業務管理に利用される。ステップS89では装置稼働状態を更新する通知を監視端末18に送信する。ステップS90で装置稼働状態42を更新する。これで、自動取引装置は取引可能な状態に復旧する。図17は実施例3の動作フローチャートである。利用者の取引中や取引終了直後には、上記の実施例のような障害が検知される。一方、既に説明したように、アイドル状態で障害を検出することもできる。障害検知手段44は、例えば、ステップS111で一定時間毎に自機の状態を診断する。ステップS112では、その結果を装置稼働状態42に記録する。ステップS113で、アイドル状態で障害を検出したかどうかを判断する。障害を検出しない場合には、ステップS111からステップS113までの処理を繰り返す。アイドル状態で障害を検出したら、ステップS113からステップS114に進む。ステップS114では、状態情報に警戒レベル情報が含まれているかどうかを判断する。ここでは、自動復旧可能な障害かどうかを判断している。状態情報に警戒レベル情報が含まれているときには、ステップS117に進み、出動要求メッセージを送信する。出動要求メッセージの中には、警戒レベルを示す情報を含める。これは既に説明したとおりである。ステップS114で、自動的に復旧できる障害と判断すると、ステップS115に進み、該当する障害復旧手順を実行する。ステップS116で、障害が復旧したかどうかを判断し、復旧していれば、処理を終了する。復旧しなければ、ステップS117に進み、出動要求メッセージを送信する。図18は実施例4の動作フローチャートである。実施例3のステップS116で、自動復旧制御に失敗をしたと判断すると、出動要求メッセージを送信した。また、図17のステップS114で、状態情報に警戒レベル情報が含まれていると判断したときには、警戒レベルを示す情報を含む出動要求メッセージを送信した。しかしながら、ただちに係員を出動させなくてもよい場合がある。同じ無人店舗に対して、短時間の間に2度出動をするというケースがあると無駄である。また、係員は保守点検のために、無人店舗を定期的に巡回している。それも考慮すべきである。そこで、図18のステップS121において、アイドル状態で、出動要求メッセージを送信するという判断がなされたとき、ステップS122以下の処理をする。ステップS122では、近接して配置された他の全ての自動取引装置が、使用可能な状態か使用不可能な状態か警戒レベルの状態かを示すデータを取得する。記憶装置22の装置稼働状態42を参照すればよい。そして、ステップS123で、自機を含めた使用不可能なものや警戒レベルの自動取引装置の合計台数をカウントする。無人店舗等で、近接して複数台の自動取引装置が配置されているときに、例えば、1台だけなら、使用不可能な状態のまま、あるいは警戒レベルのまま少しの間放置しても良い場合がある。このとき、ただちに出動要求メッセージ41を送信せずに待機する。これで、出動要求の頻度を低下させられる。ステップS123では、例えば、5台中2台以上使用不能になったときに出動要求をする。即ち、ステップS124で、この台数が、限界値、例えば、2台を越えたと判断したときには、ステップS26で、出動要求メッセージ41を送信する。しかし、例えば、巡回予定が短時間後に迫っているような場合にも、すぐに出動要求をする必要はない。そこで、ステップS125で、次回の巡回は近時か、例えば、当日中に必ず巡回があるかを判断する。この判断がノーの場合には、出動要求メッセージ41を送信する。出動要求メッセージ41には、自機と周辺の装置の装置稼働状態42を含めるとよい。それ以外の場合には、自機を使用不可能な状態にして待機させる。上記のように一部の自動取引装置が使用不能になった店舗の状態は、既に図9で説明したように、監視端末の画面で確認することができる。従って、巡回をする係員は、店舗に到着すると、ただちに該当する自動取引装置の障害復旧処理を開始する。これで、出動をする係員の負担を軽減できる。従って、大規模な監視センタを必要としないという効果がある。また、各自動取引装置が詳細な状態情報を収集するので、必要に応じて監視端末側へ転送すれば、詳細な情報把握により、その後の障害復旧率の向上を図ることができる。なお、上記の演算処理装置で実行されるコンピュータプログラムは、機能ブロックで図示した単位でモジュール化されてもよいし、複数の機能ブロックを組み合わせて一体化されてもよい。また、上記のコンピュータプログラムは、既存のアプリケーションプログラムに組み込んで使用してもよい。本発明を実現するためのコンピュータプログラムは、例えばCD-ROMのようなコンピュータで読み取り可能な記録媒体に記録して、インストールして利用することができる。