JP6003348B2 - 取引システム及び取引装置 - Google Patents

Description

この発明は、取引システム及び取引装置に関し、例えば、銀行などの金融機関やコンビニエンスストアなどに設置されるＡＴＭ（Ａｕｔｏｍａｔｅｄ Ｔｅｌｌｅｒ Ｍａｃｈｉｎｅ）を有する取引システムに適用し得る。

従来、複数拠点にＡＴＭを有する取引システムでは、監視・管理センタ等に配置された監視・管理装置で、一括して監視・管理される場合がある。

次に、上述のような従来の取引システムで、ＡＴＭに障害が発生してから、当該ＡＴＭの状態に関する情報（以下、「ログ情報」、又は「装置情報」と呼ぶ）を、保守担当者が取得するまでの流れの例について説明する。上述のような従来の取引システムで、ＡＴＭに障害が発生した場合は、エラーの通報等の警報を発する。これにより、ＡＴＭが設置されている金融機関の店舗等の係員に障害発生を通知し、その係員から監視・管理センタ等の保守部門へ障害発生が連絡されることになる。なお、並行して、ＡＴＭから監視・管理センタの監視・管理装置にアラームが通知される場合もある。そして、保守拠点等の保守担当者が、電話等により、当該ＡＴＭが設置されている店舗の係員等に対してヒアリングを行う。そして、当該保守担当者等の判断により、当該ＡＴＭからのログ収集判断の要否が行われる。そして、保守拠点に設置された端末からのリモートによるログ収集、又は当該ＡＴＭにオンサイトでのログ収集（保守担当者がＡＴＭからＣＤ−ＲやＤＶＤ−Ｒ等の持ち運び可能な媒体で直接ログ情報を収集）が行われることになる。

そして、上述のような流れで、ＡＴＭからログ情報を収集する運用について効率化するための従来技術として特許文献１〜３の記載技術がある。

特許文献１には、ＡＴＭで障害が発生した場合に、即時にその障害の解析に必要なログ情報等を、監視・管理センタに配置されたログ収集サーバにアップロードすることについて記載されている。

特許文献２、特許文献３には、ＡＴＭから監視・管理センタ等の外部装置へ、公衆電話網を用いて、アラームを通知することについて記載されている。

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

従来のＡＴＭでは、障害が発生し、オンサイトで保守担当がログ情報を取得する場合、オンサイトで当該ＡＴＭの障害の状況をある程度確認して、必要なログ情報を取得することができる。一方、従来のＡＴＭからリモートでログ情報を取得する場合には、オンサイト対応のようにＡＴＭの障害の状況を詳しく確認できないため、障害解析の正確さを優先する場合、すべてのログ情報を取得する必要がある。その場合、ＡＴＭから取得するログ情報のデータ量は、数百ＭＢになる場合もあるため、保守担当者が迅速に障害解析するには、保守拠点からＡＴＭまで高速な回線で接続する必要がある。しかし、ＡＴＭは金融機関で用いられるシステムであるため、低廉で高速通信が可能なインターネット等のオープンなネットワークを直接用いて、監視・管理センタからＡＴＭへアクセスすることは、セキュリティ上の観点から禁止される場合が多い。そして、インターネット等のオープンなネットワークを利用できない場合は、デジタル専用回線やＩＳＤＮ等比較的セキュリティの高い通信手段で、監視・管理センタからＡＴＭへアクセスする必要があるが、これらの通信手段は、インターネット接続と比較して非常に高コストであるため、低速の通信（例えば、６４ｋｂｐｓ程度の回線）でしか利用できない場合が多い。

そのため、取引装置の状態について情報を取得する際に、解析に必要な情報を効率的に取得することができる取引システム、取引装置及びプログラムが望まれている。

第１の本発明は、１又は複数の取引装置を有する取引システムにおいて、（１）上記取引装置の状態に関する情報を含む装置情報を、上記取引装置から取得して蓄積する装置情報蓄積手段を１又は複数備え、（２）それぞれの上記取引装置は、（２−１）当該取引装置で発生するイベントごとに、当該イベント発生時に当該取引装置内で保持する装置情報の内容、及び、保持した装置情報の供給先を定義した定義情報を記憶する定義情報記憶手段と、（２−２）当該取引装置でイベント発生時に、上記定義情報に従って、当該イベントに対応する装置情報を保持する装置情報保持手段と、（２−３）上記装置情報保持手段が保持した装置情報のうち、上記定義情報でいずれかの上記装置情報蓄積手段が供給先として定義されている装置情報について、上記定義情報で定義された上記装置情報蓄積手段に供給する装置情報供給手段とを有し、（２−４）上記装置情報供給手段は、上記装置情報保持手段が保持した装置情報のうち、上記定義情報で供給先が定義されていない装置情報について、ユーザの操作に応じて、１又は複数の上記装置情報蓄積手段に供給することを特徴とする。

第２の本発明の取引装置は、（１）当該取引装置で発生するイベントごとに、当該イベント発生時に当該取引装置内で保持する当該取引装置の状態に関する情報を含む装置情報の内容、及び、保持した装置情報の供給先を定義した定義情報を記憶する定義情報記憶手段と、（２）上記装置情報保持手段が保持した装置情報のうち、上記定義情報でいずれかの装置情報蓄積手段が供給先として定義されている装置情報について、上記定義情報で定義された上記装置情報蓄積手段に供給する装置情報供給手段とを有し、（３）上記装置情報供給手段は、上記装置情報保持手段が保持した装置情報のうち、上記定義情報で供給先が定義されていない装置情報について、ユーザの操作に応じて、１又は複数の上記装置情報蓄積手段に供給することを特徴とする。

本発明によれば、取引装置の状態について情報を取得する際に、解析に必要な情報を効率的に取得することができる取引システムを提供することができる。

実施形態に係るＡＴＭを備える取引システムの全体構成について示した説明図である。 実施形態に係るＡＴＭの機能的構成について示したブロック図である。 実施形態に係るＡＴＭの斜視図である。 実施形態に係るＡＴＭで表示されるモニタ画面の構成例について示した説明図である。 実施形態に係るＡＴＭのエラー処理定義データの内容例について示した説明図である。 実施形態に係るＡＴＭのログ取得方法定義データの内容例について示した説明図である。 実施形態に係るＡＴＭのログ送信方法定義データの内容例について示した説明図である。 実施形態に係るＡＴＭのｗｏｒｋフォルダの構造について示した説明図である。 実施形態に係るＡＴＭの圧縮フォルダの構造について示した説明図である。 実施形態に係るモニタ装置及びログサーバのログ情報保存フォルダの構造について示した説明図である。 実施形態に係るＡＴＭのエラー履歴データの内容例について示した説明図である。 実施形態に係るモニタ装置のエラー履歴データの内容例について示した説明図である。 実施形態に係るログサーバのエラー履歴データの内容例について示した説明図である。 実施形態に係るＡＴＭの動作について示したフローチャートである。 実施形態に係るＡＴＭでログ情報を送信する場合（送信方法＝２の場合）の動作について示したシーケンス図である。 実施形態に係るＡＴＭでログ情報を送信する場合（送信方法＝３の場合）の動作について示したシーケンス図である。 実施形態に係るＷｅｂ端末でログ情報等が参照される場合の動作について示したシーケンス図である。 実施形態に係るＷｅｂ端末で表示されるエラー参照Ｗｅｂ画面の内容例について示した説明図である。 実施形態に係るＡＴＭで表示されるＡＴＭエラー管理画面の内容例について示した説明図である。 実施形態に係るモニタ装置で表示される モニタ装置エラー管理画面の内容例について示した説明図である。

（Ａ）主たる実施形態
以下、本発明による取引システム及び取引装置の一実施形態を、図面を参照しながら詳述する。この実施形態では、本発明の取引装置を、ＡＴＭに適用した例について説明する。

（Ａ−１）実施形態の構成
図１は、この実施形態の取引システム１０００の全体構成について示したブロック図である。

図２は、この実施形態のＡＴＭ１００の機能的構成について示したブロック図である。

図３は、この実施形態のＡＴＭ１００の外観斜視図である。図３（ａ）は、実施形態のＡＴＭ１００を前面（正面）の方向から見た場合の斜視図である。図３（ｂ）は、実施形態のＡＴＭ１００を後面（背面）の方向から見た場合の斜視図である。

図１に示すように、取引システム１０００では、営業店Ｌ１、ホストセンタＬ２、集中監視センタＬ３、及び保守拠点Ｌ４という４つの拠点（４種類の拠点）に分散して装置が配置されている。

取引システム１０００では、金融機関の営業店Ｌ１に、Ｎ台のＡＴＭ１００（１００−１〜１００−Ｎ）が配置されている。なお、取引システム１０００において営業店Ｌ１や保守拠点Ｌ４の数は限定されないものである。また、営業店Ｌ１に配置するＡＴＭ１００の数も限定されないものである。

そして、各ＡＴＭ１００は、図１に示すように、ネットワークＮ１を介してホストセンタＬ２に配置されたホストコンピュータ２００に接続している。ネットワークＮ１の種類は限定されないものであるが、公衆電話網、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）、デジタル専用回線、ＩＰネットワーク（セキュリティ性の高い網が望ましい）等、既存のＡＴＭで用いられる種々の回線を適用することができる。

ＡＴＭ１００は、顧客から取引（例えば、振込取引や預入取引等）を受付けると、その取引の実行依頼(トランザクション処理の依頼)をホストコンピュータ２００に送信する。ホストコンピュータ２００としては、例えば、既存のＡＴＭを用いた取引処理が可能なホストコンピュータを適用することができるため詳しい説明は省略する。

各ＡＴＭ１００は、ネットワークＮ１とは別系統の営業店内ＬＡＮ１に接続している。そして、営業店内ＬＡＮ１上には、モニタ装置３００が配置されている。

モニタ装置３００は、各ＡＴＭ１００の監視・管理等を行うものである。また、モニタ装置３００は、ＡＴＭ１００から受信したログ情報を、ログサーバ５００に中継送信する中継装置としても機能するものとする。モニタ装置３００としては、例えば、ＰＣやワークステーション等のコンピュータに、ログ情報等を処理するための情報処理プログラム等をインストールすることにより実現することができる。なお、モニタ装置３００は、各ＡＴＭ１００から受信したログ情報のファイルを保存するためのログ情報保存フォルダ３０１と、各ＡＴＭ１００から受信したエラーを管理するエラー履歴データ３０２と、媒体（ＣＤ−Ｒ等）にデータを書き込むことが可能なＣＤドライブ３０３を有している。

そして、営業店内ＬＡＮ１には、集中監視センタＬ３へ接続するためのルータＲ１が配置されている。そして、ルータＲ１は、ネットワークＮ２及び集中監視センタＬ３のルータＲ２を介して、集中監視センタＬ３内の監視用ＬＡＮ２に接続することができる。すなわち、営業店内ＬＡＮ１と監視用ＬＡＮ２とは、ネットワークＮ２を介して接続している。なお、営業店内ＬＡＮ１と監視用ＬＡＮ２との間の接続構成については、上述の例に限定されず、種々のネットワーク構成を適用することができるが、セキュリティ性の高いネットワーク構成が望ましい。例えば、ネットワークＮ２としては、通信キャリアが提供するセキュリティ性の高いネットワーク回線（例えば、ＩＳＤＮ、デジタル専用回線、フレームリレー回線等）を適用することが望ましい。ただし、通信キャリアが提供するセキュリティ性の高いネットワーク回線は、高コストであるため、多くの場合、監視や保守のためだけに高速回線を適用することはむずかしい。そこで、この実施形態では、ネットワークＮ２として用いる回線の通信速度は、６４ｋｂｐｓ程度の通信速度であるものとして説明する。

なお、営業店Ｌ１が複数存在する場合には、集中監視センタＬ３側のルータＲ２では、それぞれの営業店のルータと通信可能なインタフェースを備える必要がある。
そして、監視用ＬＡＮ２には、管理端末４００、ログサーバ５００、及びＷｅｂサーバ７００が配置されている。

管理端末４００は、集中監視センタＬ３内の監視担当者等が利用する端末であり、各ＡＴＭ１００に対するリモート操作や、ログサーバ５００上に蓄積されたログ情報の参照等の処理を行うことが可能である。管理端末４００は、例えば、ＰＣやワークステーション等に、ログ情報等を処理するための情報処理プログラム等をインストールすることにより実現することができる。

ログサーバ５００は、各ＡＴＭ１００から受信したログ情報等をストレージ６００に蓄積する処理等を行うものである。また、ログサーバ５００は、各ＡＴＭ１００から受信したエラーを管理するエラー履歴データ５０１を記憶している。ログサーバ５００は、例えば、ＰＣやワークステーション等に、ログ情報等を処理するための情報処理プログラム等をインストールすることにより実現することができる。また、ストレージ６００上には、各ＡＴＭ１００から受信したログ情報のファイルを保存するためのログ情報保存フォルダ６０１が保持されている。

Ｗｅｂサーバ７００は、ログサーバ５００に蓄積されたログ情報等を、保守拠点Ｌ４に配置されたＷｅｂ端末８００等に参照させるためのＷｅｂサーバである。Ｗｅｂサーバ７００としては、例えば、既存のＷｅｂサーバシステムのプラットフォーム上に、ログサーバ５００のデータを参照可能なＷｅｂ画面の設定等を加えることにより構築することができる。

そして、Ｗｅｂサーバ７００には、監視用ＬＡＮ２とは別の系統の保守拠点収容ＬＡＮ３が接続されており、ルータＲ３、ネットワークＮ３、及び保守拠点Ｌ４内のルータＲ４を介して、保守拠点内ＬＡＮ４のＷｅｂ端末８００と通信することができる。

保守拠点収容ＬＡＮ３には、直接ＡＴＭ１００と接続することはできない。したがって、ネットワークＮ３は、ネットワークＮ２ほどのセキュリティレベルは求められないため、インターネット等のオープンなネットワークを利用するようにしてもよい。ただし、ルータＲ３、ルータＲ４には、ファイアーウォールや暗号化通信等のセキュリティ機能に対応したものを適用することが望ましい。

Ｗｅｂ端末８００は、保守拠点Ｌ４の保守担当者が、Ｗｅｂサーバ７００を介して、ログサーバ５００に蓄積されたログ情報等を参照可能な端末である。Ｗｅｂ端末８００としては、例えば、ＷｅｂブラウザがインストールされたＰＣ等を適用することができる。

次に、各ＡＴＭ１００の内部構成について説明する。ここでは、すべてのＡＴＭ１００は同じ構成であるものとして説明する。

ＡＴＭ１００は、図２に示すように制御部１０、データ記憶部２０、通信部３０、カードリーダライタ４０、操作表示部５０、プリンタ６０、通帳処理部７０、現金処理部８０、及びＣＤドライブ９０を有している。

制御部１０は、ＡＴＭ１００内の各部の動作制御や情報処理を行う機能を担っているものであり、取引処理部１１及び保守運用処理部１２を有している。取引処理部１１は、取引に係る処理の機能を担っている。また、保守運用処理部１２は、当該ＡＴＭ１００に係る保守運用に係る処理（例えば、エラーやログ情報の処理等）の機能を担っている。

データ記憶部２０は、制御部１０が情報処理を行うために必要な各種情報等を格納するデータ記憶手段であり、例えば、ハードディスクドライブを用いて構成することができる。なお、この実施形態では、データ記憶部２０は、２つのハードディスクドライブによるミラーリング構成（ＲＡＩＤ０の構成）となっているものとする。

制御部１０は、例えば、プロセッサ等を含むプログラムの実施構成（コンピュータ）に取引処理部１１に対応する取引プログラムや、保守運用処理部１２に対応する情報処理プログラム等をインストールすることにより実現することができる。例えば、ＡＴＭ１００では、上述の各プログラムを、データ記憶部２０に記憶しておき、起動したときに、読み込んで実行するようにしても良い。

通信部３０は、ネットワークＮ１や営業店内ＬＡＮ１に接続するためのネットワークインタフェースである。なお、通信部３０については、既存のＡＴＭ等と同様のものを適用することができるため、詳しい説明は省略する。

カードリーダライタ４０は、顧客からカード挿入排出口４０１に挿入されたキャッシュカードのデータ読取等を行うものである。なお、カードリーダライタ４０は、既存のＡＴＭ等と同様のものを適用することができるため、詳しい説明は省略する。

プリンタ６０は、伝票用紙に取引内容を印字して伝票排出部６０１から排出したり、ジャーナル用紙に取引履歴等を印字するものである。なお、プリンタ６０自体は、既存のＡＴＭ等と同様のものを適用することができるため、詳しい説明は省略する。

通帳処理部７０は、顧客から通帳挿入排出口７０１に挿入された通帳の処理（通帳への取引結果の印字等）や、収納している新品の通帳の処理（例えば、処理中の通帳のページが全て印字されて埋まった場合に、新品の通帳に印字して排出する処理等）を行うものである。なお、通帳処理部７０は、既存のＡＴＭ等と同様のものを適用することができるため、詳しい説明は省略する。

現金処理部８０は、顧客から入金された現金（紙幣及び又は硬貨）を収納する機能と、ＡＴＭ１００に収納されている現金を顧客に出金する機能を担っている。この実施形態では、現金処理部８０は、紙幣入出金口８０１から紙幣の入出金を行い、硬貨入出金口８０２から硬貨の入出金を行うことが可能となっている。なお、現金処理部８０は、既存のＡＴＭ等と同様のものを適用することができるため詳しい説明を省略する。

操作表示部５０は、当該ＡＴＭ１００のユーザインタフェース機能を担っている。具体的には、操作表示部５０は、主として顧客からの取引操作を受付ける操作画面を表示するための前面操作表示部５１と、主として営業店の係員や保守担当者が保守運用作業の際に利用する後面操作表示部５２とを有している。前面操作表示部５１及び後面操作表示部５２は、タッチパネルディスプレイ等を用いて、ユーザに操作画面を提示するとともに、ユーザからの操作受付を行うことが可能なデバイスである。図３に示すように、前面操作表示部５１は、ＡＴＭ１００の前面側（正面）に配置されており、後面操作表示部５２はＡＴＭ１００の後面（背面）に配置された扉Ｐ１につけられている。ＡＴＭ１００では、この扉Ｐ１を開くことにより、営業店の係員や保守担当者等が、内部の各ハードウェアにアクセスすることが可能となっているものとする。

また、後面操作表示部５２では、通常時表示する操作画面（デフォルトで表示する操作画面）として、当該ＡＴＭ１００の現在の状態等の概要（サマリ）を表示する操作画面（以下、「モニタ画面」と呼ぶ）を表示するものとする。モニタ画面では、現在の当該ＡＴＭ１００の状態の概要についてイラスト等を用いて表示している。

例えば、ＡＴＭ１００では、モニタ画面として図４に示すような操作画面を表示するようにしてもよい。例えば、図４に示すフィールドＦ１０１では、プリンタ６０の搬送路の状態、伝票やジャーナルを印刷する用紙の装填状況・残量、カードリーダライタ４０におけるキャッシュカードの残留等について視覚的に表した内容となっている。また、フィールドＦ１０２では、現金処理部８０に収納されている紙幣の残量（紙幣スタッカの残量）や紙幣搬送路（ベルトやローラ等）の状況等を視覚的に表した内容となっている。さらに、フィールドＦ１０３では、データ記憶部２０のハードディスクの運転状況等について、視覚的に表している。図４では、障害の発生したハードディスクドライブのシンボルに、障害発生を示すバツ印を付記している。さらに、フィールドＦ１０４では、通帳処理部７０における新品の通帳の残量、印字用のリボンの装填状況等について視覚的に表した内容となっている。さらにまた、フィールドＦ１０５では、現金処理部８０に収納されている硬貨の残量（硬貨スタッカの残量）や硬貨搬送路（ベルトやローラ等）の状況等を視覚的（目盛表示）に表した内容となっている。また、フィールドＦ１０６では、現在当該ＡＴＭ１００で発生している障害に係る情報（エラーの内容等）や、実行中の取引の進行状況等をメッセージ表示（文字表示）している。

なお、モニタ画面の構成については、上述の例に限定されず既存のＡＴＭの種々の構成を適用することができるため、詳しい説明を省略する。

次に、ＡＴＭ１００のデータ記憶部２０に格納される各情報について説明する。

なお、ＡＴＭ１００に搭載するコンピュータ（主として制御部１０及びデータ記憶部２０）のプラットフォーム（ＯＳ）は限定されないものであるが、以下では例として、Ｗｉｎｄｏｗｓ（登録商標）系のＯＳが適用されるものとして説明する。したがって、データ記憶部２０は、ＦＡＴ３２（Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅｓ ３２）やＮＴＦＳ（ＮＴ Ｆｉｌｅ Ｓｙｓｔｅｍ）等のファイルシステム上に、所定のディレクトリ構成のファイルが保存されることになる。

データ記憶部２０には、エラー処理定義データ２１、ログ取得方法定義データ２２、ログ送信方法定義データ２３、ｗｏｒｋフォルダ２４、圧縮フォルダ２５、ログ出力フォルダ２６、及びエラー履歴データ２７の情報が記憶される。

ログ出力フォルダ２６は、制御部１０が情報処理の過程で出力するログファイル等を保存するためのフォルダである。ログ出力フォルダ２６内の構成（ディレクトリ構造等）は、限定されないものであるが、ここでは例として「c:\dat\」というディレクトリの配下がログ出力フォルダ２６であるものとして説明する。なお、ログ出力フォルダ２６の構成は、既存のＡＴＭの種々の構成を適用することができおる。

図８は、ｗｏｒｋフォルダ２４の構造について示した説明図である。

図８に示すようにｗｏｒｋフォルダ２４では、当該ＡＴＭ１００でエラーが発生するごとに、対応する１つのディレクトリ（以下、「ログファイル格納ディレクトリ」と呼ぶ）を生成する。例えば、同時刻に複数のエラーが発生した場合でも、保守運用処理部１２は、複数のエラーそれぞれに対応したログファイル格納ディレクトリをｗｏｒｋフォルダ２４に生成して、保持したログ情報を格納する。

そして、図８に示すようにｗｏｒｋフォルダ２４内では、各ログファイル格納ディレクトリのディレクトリ名がユニークとなる必要がある。この実施形態では、ログファイル格納ディレクトリのディレクトリ名には、当該エラーの発生日時の文字列と、当該エラーの識別子（以下、「エラーＩＤ」と呼ぶ）の文字列が含まれるものとする。例えば、エラー発生日時が「２０１２年１０月２８日１５時３０分」、エラーＩＤが「１００１」の場合には、当該エラーに係るログファイル格納ディレクトリのディレクトリ名は「201210281530-1001」となるものとする。

そして、それぞれのログファイル格納ディレクトリには、後述する処理により生成される画像データファイル（モニタ画面のキャプチャ画像；ファイル名が「iop.jpg」のファイル）や、画像データファイル以外のログファイル（拡張子が、「txt」や「log」のファイル）が格納される。なお、エラーごとにログファイル格納ディレクトリに格納されるファイルの種類や数は異なる場合がある。

そして、保守運用処理部１２は、必要に応じて、ｗｏｒｋフォルダ２４内の各ログファイル格納ディレクトリに格納されたファイルについて、圧縮して圧縮フォルダ２５に格納する。

図９は、圧縮フォルダ２５の構造について示した説明図である。

圧縮フォルダ２５では、ログファイル格納ディレクトリごとに、画像データファイル（モニタ画面のキャプチャ画像）と、画像データファイル以外のファイルをまとめて圧縮した圧縮ファイルが格納される。ここでは、圧縮フォルダ２５には、ＣＡＢ形式によりログファイルが圧縮されるものとして説明する。なお、画像データファイルの内容は、圧縮処理されずログファイル格納ディレクトリのデータと同じ内容となる（ただしファイル名が異なる）。

圧縮フォルダ２５では、画像データファイル及び圧縮ファイルのファイル名に、ログファイル格納ディレクトリのディレクトリ名の文字列と、当該ＡＴＭ１００が配置された営業店の識別子（以下、「店番号」と呼ぶ）の文字列と、当該ＡＴＭ１００の当該営業店内での識別子（以下、「機番号」と呼ぶ）の文字列が含まれるものとする。

例えば、当該ＡＴＭ１００が設置された営業店の店番号が「０００１」、当該ＡＴＭ１００の機番号が「０００１」である場合には、圧縮ファイルのファイル名は、「0001_0001_201210281530-1001.cab」となり、画像データファイルのファイル名は「0001_0001_201210281530-1001.jpg」となる。なお、元となるログファイル格納ディレクトリに、画像データファイルが存在しない場合には、当然、圧縮フォルダ２５にも当該ログファイル格納ディレクトリに係る画像データファイルはコピーされないことになる。

圧縮フォルダ２５におけるファイル名は、取引システム１０００全体でユニークなファイル名となれば、その具体的なネーミングルール等は限定されないものである。

次に、エラー処理定義データ２１の内容について説明する。エラー処理定義データ２１では、エラーＩＤごとに、当該エラーが発生した場合の処理内容（主としてログ情報の処理）を定義している。

図５に示すように、エラー処理定義データ２１には、エラーＩＤごとに、分類、エラー内容、必要度、画面通知、対象ログ、ログ送信方法の項目が設定されている。

エラー処理定義データ２１において、「分類」の項目は、当該エラーの分類（例えば、当該エラーの発生元のデバイス等）を示している。

エラー処理定義データ２１において、「エラー内容」の項目は、当該エラーの概要を示している。

エラー処理定義データ２１において、「必要度」の項目は、同時に複数の障害が発生した場合の処理の優先度を数値化したパラメータである。必要度の数値が大きい程、保守作業（例えば、発生した障害にログ情報の解析等）が必要な度合いが高いことを表すものとする。

エラー処理定義データ２１において、「画面通知」の項目は、現在後面操作表示部５２に表示されているモニタ画面をキャプチャして画像データファイルとしてｗｏｒｋフォルダ２４に保存するか否かを示している。ここでは、画面通知の項目が「０」のエラーが発生した場合、保守運用処理部１２は、モニタ画面の画像データファイルの取得・保存を行わないものとする。また、画面通知の項目が「１」のエラーが発生した場合、保守運用処理部１２は、モニタ画面の画像データファイルをログ情報の一部として、ｗｏｒｋフォルダ２４内の対応するログファイル格納ディレクトリに保存するものとする。

保守運用処理部１２が、モニタ画面をキャプチャする構成については限定されないものであるが、ここでは、ＡＴＭ１００ではＷｉｎｄｏｗｓのプラットフォームが採用されているので、Ｗｉｎｄｏｗｓの「ＰｒｉｎｔＳｃｒｅｅｎ」の機能（例えば、キーボード上のＰｒｉｎｔＳｃｒｅｅｎボタンを押下した場合に実行される処理と同様の処理）によりモニタ画面をキャプチャするものとする。そして、保守運用処理部１２は、その画像データを、ＪＰＥＧ形式のファイルとして所定のフォルダに格納するものとする。

エラー処理定義データ２１において、「対象ログ」の項目は、当該エラーの発生に際して取得する必要があるログファイルの取得方法を定義している。

対象ログの項目に、ログファイルのファイル名（例えば、図５の「C:\dat\OSLOG1.log」等）が設定されている場合には、当該エラーが発生した場合、保守運用処理部１２はそのファイル名のログファイルを取得して、ｗｏｒｋフォルダ２４内の対応するログファイル格納ディレクトリにコピーすることを示している。

また、対象ログの項目に、「パターンＡ、Ｂ、Ｃ…」といった識別子（以下、「パターンＩＤ」と呼ぶ）が設定されている場合には、保守運用処理部１２は、ログ取得方法定義データ２２を参照して、そのパターンＩＤに対応する処理を行う。以下では、例えば、「パターンＡ」と表記した場合には、パターンＩＤが「Ａ」のログ取得方法を示しているものとする。

図６は、ログ送信方法定義データ２３の構成例について示した説明図である。

ログ送信方法定義データ２３には、図６に示す通り、パターンＩＤごとに、対象ログパターン名、処理内容の項目の情報が設定されている。

ログ送信方法定義データ２３において、「対象ログパターン名」の項目は、当該パターンＩＤに対応するログファイルの概要を示している。

ログ送信方法定義データ２３において、「処理内容」の項目は、当該パターンＩＤに対応するログファイルの取得方法を示している。例えば、パターンＡの処理内容としては「AAA.BATを実行」となっているため、「AAA.BAT」というバッチファイル（Ｗｉｎｄｏｗｓ上のＭＳ−ＤＯＳコマンドラインで実行可能なバッチファイル）を実行し、出力されるデータ（その時点の当該ＡＴＭの状態を示すデータ等）をログファイルとして取得することを示している。この場合、「AAA.BAT」というバッチファイルを実行することにより、パターンＡに対応するログファイルが得られることを示している。このように、保守運用処理部１２は、ログ取得方法定義データ２２の内容に従って、バッチファイル等の実行ファイルを実行することにより、当該ＡＴＭ１００の状態等に係るログファイルを取得することができる。保守運用処理部１２がログファイルを取得するために実行するバッチファイル等の実行ファイルの内容については、既存のＡＴＭにおける種々の構成（例えば、自己診断ツールやログファイル取得プログラム等）を適用することができるため詳しい説明を省略する。

図６のログ取得方法定義データ２２で、パターンＩＤが空欄「−」の行には、処理内容として「指定したパスのログをコピー」と記載されている。これは、エラー処理定義データ２１の対象ログの項目にログファイルのファイル名が設定されていた場合の処理内容（ログファイルのコピー）について示している。

エラー処理定義データ２１において、「ログ送信方法」の項目は、当該エラーに係るログ情報の処理方法について示している。

ログ送信方法の項目には、当該エラーに係る処理内容を示すコード番号が設定される。そして、ログ送信方法定義データ２３には、そのコード番号ごとに対応する、処理内容が定義されている。

図７は、ログ送信方法定義データ２３の内容例について示した説明図である。

例えば、コード番号が「０」に対応する処理内容は「何もしない」であり、当該エラーに係るログファイルはそのまま（ｗｏｒｋフォルダ２４に保存したまま）であることを示している。

また、コード番号が「１」に対応する処理内容は「圧縮フォルダに対象ログ退避」であり、当該エラーに対応するログファイル格納ディレクトリ内のファイルを圧縮して、圧縮フォルダ２５内に格納することを示している。

さらに、コード番号が「２」に対応する処理内容は「圧縮フォルダ、及びモニタ装置に対象ログを退避」であり、当該エラーに対応するログファイル格納ディレクトリ内のファイルを圧縮して、圧縮フォルダ２５内に格納し、さらに、モニタ装置３００に送信することを示している。

さらにまた、コード番号が「３」に対応する処理内容は「圧縮フォルダ、モニタ装置、及びログサーバに対象ログを退避」であり、当該エラーに対応するログファイル格納ディレクトリ内のファイルを圧縮して、圧縮フォルダ２５内に格納し、さらに、モニタ装置３００及びログサーバ５００に送信することを示している。

エラー履歴データ２７は、図１１に示すように１つのエラーについて１行のデータで表されている。そして、エラー履歴データ２７では、それぞれのエラーについて、エラー発生日時、エラーＩＤ、ログサーバ送信、モニタ装置送信、ログファイルサイズの項目の情報が設定されている。なお、エラー履歴データ２７では、その他の情報についても追加するようにしてもよい。

エラー履歴データ２７における「ログサーバ送信」の項目は当該エラーに係るログ情報（画像データファイル、及び圧縮ファイル）の、ログサーバ５００への送信状況について示している。ログサーバ送信の項目には、「未送信」、「送信済」、「送信不可」のいずれかが設定される。「ログサーバ送信」が「送信不可」の場合、当該エラーに係るログファイルは、ログサーバ５００へ送信できないことを示している。保守運用処理部１２は、ログサーバ５００にログ情報を送信するときに、当該ログ情報を構成する圧縮ファイル（ログファイル）のファイルサイズが所定以上の場合に送信不可と判断し、画像データファイルのみを送信する。ここでは、保守運用処理部１２は、圧縮ファイル（ログファイル）のサイズが２０ＭＢ以上の場合に、当該圧縮ファイル（ログファイル）については送信不可と判断するものとする。なお、保守運用処理部１２は、通信エラー等により圧縮ファイル（ログファイル）が送信できない場合（送信失敗した場合）にも送信不可と判断するようにしてもよい。

エラー履歴データ２７における「モニタ装置送信」の項目は当該エラーに係るログ情報（画像データファイル、及び圧縮ファイル）を、モニタ装置３００に送信したか否か（「未送信」又は「送信済」のいずれか）を示す。

エラー履歴データ２７における「ログファイルサイズ」の項目は当該エラーに係るログ情報を構成する圧縮ファイル（ログファイル）のファイルサイズを示している。

次に、モニタ装置３００及びログサーバ５００における、ログ情報保存フォルダ３０１及びログ情報保存フォルダ６０１の構造について図１０を用いて説明する。

モニタ装置３００は、ＡＴＭ１００からログ情報を構成するファイル（圧縮ファイル及び又は画像データファイル）を受信すると、ログ情報保存フォルダ３０１に保存する。また、ログサーバ５００は、ＡＴＭ１００からログ情報を構成するファイルを受信すると、ストレージ６００のログ情報保存フォルダ６０１に保存する。

ログ情報保存フォルダ３０１及びログ情報保存フォルダ６０１は、同じ構造となっているため、いずれの構造も図１０を用いて説明することができる。

ログ情報保存フォルダ３０１及びログ情報保存フォルダ６０１では、ＡＴＭ１００ごとにユニークとなるサブディレクトリを生成して、そのサブディレクトリ内に、当該ＡＴＭ１００から受信したログ情報のファイルを格納する。

ログ情報保存フォルダ３０１及びログ情報保存フォルダ６０１では、各サブディレクトリのディレクトリ名には、当該ＡＴＭ１００に係る店番号及び機番号の文字列が含まれている。例えば、店番号が「０００１」、機番号が「０００１」のＡＴＭ１００に係るサブディレクトリのディレクトリ名は「0001_0001」となる。

次に、エラー履歴データ２７の内容について説明する。エラー履歴データ２７は、当該ＡＴＭ１００において発生したエラーと、当該エラーに関する処理状況を管理するためのテーブルである。

次に、モニタ装置３００が記憶しているエラー履歴データ３０２の内容例について図１２を用いて説明する。

エラー履歴データ３０２は、当該モニタ装置３００と同じ営業店内のＡＴＭ１００で発生したエラーと、当該エラーに関する処理状況を管理するためのテーブルである。

モニタ装置３００では、同じ営業店内のＡＴＭ１００（制御部１０）から供給される、エラー通知、及び、ログ情報（ログ情報保存フォルダ３０１に格納されたファイル）に基づいて、エラー履歴データ３０２を更新する。

エラー履歴データ３０２は、図１２に示すように１つのエラーについて１行のデータで表されている。そして、エラー履歴データ３０２では、それぞれのエラーについて、店番号、機番号、エラー発生日時、エラーＩＤ、ログサーバ送信、ログ情報受信、ログファイルサイズの項目の情報が設定されている。なお、エラー履歴データ３０２では、その他の情報についても追加するようにしてもよい。

エラー履歴データ３０２において、「店番号」及び「機番号」の項目は、当該エラーに係るＡＴＭの「店番号」及び「機番号」である。

エラー履歴データ３０２において、「エラー発生日時」の項目は、例えば、ＡＴＭ１００からのエラー通知に含まれる日時としてもよい。

エラー履歴データ３０２において、「ログサーバ送信」の項目は、当該モニタ装置３００から、ログサーバ５００への当該エラーに係るログ情報の送信状況について示している。エラー履歴データ３０２において、ログサーバ送信の項目には、エラー履歴データ２７と同様に、「未送信」、「送信済」、「送信不可」のいずれかが設定される。

次に、ログサーバ５００（ストレージ６００）が記憶しているエラー履歴データ５０１の内容例について図１３を用いて説明する。

エラー履歴データ５０１は、取引システム１０００内のＡＴＭ１００で発生したエラーと、当該エラーに関する処理状況を管理するためのテーブルである。

ログサーバ５００では、ＡＴＭ１００（制御部１０）から供給される、エラーの通知（エラー通知）、及び、ログ情報（ログ情報保存フォルダ６０１に格納されたファイル）に基づいて、エラー履歴データ５０１を更新する。

エラー履歴データ５０１は、図１３に示すように１つのエラーについて１行のデータで表されている。そして、エラー履歴データ５０１では、それぞれのエラーについて、店番号、機番号、エラー発生日時、エラーＩＤ、モニタ画面、ログファイル、ログファイルサイズの項目の情報が設定されている。なお、エラー履歴データ５０１では、その他の情報についても追加するようにしてもよい。

エラー履歴データ５０１において、店番号、機番号、エラー発生日時、エラーＩＤ、ログファイルサイズの項目は、上述のエラー履歴データ３０２と同様であるので説明を省略する。

エラー履歴データ５０１において、「モニタ画面」の項目は、当該エラーに係る画像データファイル（モニタ画面の画像データファイル）の受信状況について示している。モニタ画面の項目には、「未受信」、「受信済」のいずれかが設定される。

エラー履歴データ５０１における「ログファイル」の項目は、当該エラーに係るログ情報を構成するログファイルの受信状況について示している。ログファイルの項目には、「未受信」、「受信済」、「受信不可」のいずれかが設定される。ログファイルの項目が「受信不可」の場合、送信側のＡＴＭ１００等で送信不可となっていることを示している。なお、ログサーバ５００では、エラー履歴データ５０１のログファイルの項目について、受信不可であるか否かについて、ＡＴＭ１００又はモニタ装置３００から通知を受けるようにしてもよい。

以上のように、取引システム１０００では、モニタ装置３００、ログサーバ５００、及びＡＴＭ１００内の圧縮フォルダ２５（退避先のフォルダ）が、ログ情報を蓄積（退避）するためのログ情報蓄積手段（装置情報蓄積手段）として機能している。この実施形態では、ログ情報蓄積手段の例として、上述の３種類を挙げているが、ログ情報蓄積手段の種類や数は上述の例に限定されないものである。

また、ＡＴＭ１００では、データ記憶部２０が、エラー履歴データ２７を記憶する定義情報記憶手段として機能している。さらに、ＡＴＭ１００では、制御部１０が、エラー発生時にログ情報を保持するログ情報保持手段（装置情報保持手段）と、ログ情報をログ情報蓄積手段に供給（退避処理や送信処理）するためのログ情報供給手段（装置情報供給手段）として機能している。さらにまた、ＡＴＭ１００では、制御部１０及び後面操作表示部５２が、モニタ画面を表示出力するための手段（装置状態画像表示出力手段）と、モニタ画像をキャプチャした画像データを取得する手段（装置状態画像データ取得手段）として機能している。また、ＡＴＭ１００では、制御部１０及びＣＤドライブ９０が、ＣＤ−Ｒ等の持ち運び可能な媒体にログ情報を書き込む手段（媒体書込手段）として機能している。さらに、取引システム１０００では、ログサーバ５００及びＷｅｂサーバ７００が、Ｗｅｂ画面をＷｅｂ端末８００（端末装置）に提供する手段（操作画面提供手段）として機能している。

（Ａ−２）実施形態の動作
次に、以上のような構成を有するこの実施形態の取引システムの動作を説明する。

（Ａ−２−１）ＡＴＭ１００の動作
まず、ＡＴＭ１００でエラー（障害）が発生した場合の制御部１０（保守運用処理部１２）が行う処理について図１４のフローチャートを用いて説明する。

ＡＴＭ１００の制御部１０（保守運用処理部１２）では、当該ＡＴＭ１００でエラー（障害）発生を検知すると、まず、ｗｏｒｋフォルダ２４の整理を行う（Ｓ１０１）。制御部１０が行うｗｏｒｋフォルダ２４の整理内容は限定されないものである。例えば、制御部１０は、ｗｏｒｋフォルダ２４内で生成されてから所定期間以上経過したファイルを削除するようにしてもよい。また、例えば、制御部１０は、ｗｏｒｋフォルダ２４内の利用容量（格納ファイルの総データ量）が所定の閾値以上となった場合には、ｗｏｒｋフォルダ２４内の利用容量がその閾値以下となるようにファイルを削除（例えば、タイムスタンプの古いファイルから削除）するようにしてもよい。

そして、制御部１０は、発生したエラーのうち１つのエラーについて、エラーＩＤを取得する（Ｓ１０２）。複数のエラーが同時にスタックして（重複して）発生している場合には、制御部１０は、スタックしているエラーのうち、必要度（エラー処理定義データ２１の必要度の項目）が最も高いエラーＩＤを取得する。制御部１０が、エラーの検知及びエラーＩＤの取得をする構成については、例えば、既存のＡＴＭにおける種々の構成を適用することができるため、詳しい説明は省略する。

そして、制御部１０は、エラー処理定義データ２１を読み込み、発生したエラーＩＤに対応するデータ（以下、「処理定義データ」と呼ぶ）を取得する（Ｓ１０３）。

そして、制御部１０は、取得した処理定義データから、当該エラーに対応する画面通知の要否を確認する（Ｓ１０４）。そして、制御部１０は、画面通知が必要（１）な場合にのみ、現在後面操作表示部５２に表示しているモニタ画面の画像を取得し、画像データファイルとして、当該エラーに対応するログファイル格納ディレクトリ（ディレクトリが生成されていない場合は、ディレクトリ生成も行う）に格納する（Ｓ１０５）。
そして、制御部１０は、処理定義データの対象ログの項目の設定内容に従った処理を行い、ログファイルを取得する。そして、制御部１０は、取得したログファイルを、当該エラーに対応するログファイル格納ディレクトリ（ディレクトリが生成されていない場合は、ディレクトリ生成も行う）に格納する（Ｓ１０６）。

そして、制御部１０は、当該エラーが発生したことを、当該ＡＴＭ１００と同一営業店内のモニタ装置３００と、ログサーバ５００に通知する（Ｓ１０７）。なお、この時制御部１０が行うエラー発生の通知には、少なくとも、当該エラーのエラーＩＤ、当該ＡＴＭ１００に係る店番号、機番号、及びエラー発生日時が含まれるものとする。なお、制御部１０がエラー発生を通知するタイミングについては限定されないものであり、例えば、ログファイル等の処理を行う前であってもよい。

そして、制御部１０は、取得した処理定義データのログ送信方法の項目（当該エラーに対応するログ送信方法）を参照する（Ｓ１０８）。

上述のステップＳ１０８でログ送信方法の項目が「０」だった場合には、制御部１０は、なにもせずに（特にログ情報の圧縮や送信を行わずに）（Ｓ１０９）、後述するステップＳ１１３の処理に移行する。

また、上述のステップＳ１０８でログ送信方法の項目が「１」だった場合には、制御部１０は、当該エラーに係るログファイル格納ディレクトリに格納されたログファイルを圧縮して圧縮ファイルを生成し、モニタ画面の画像ファイルデータとともに、圧縮フォルダ２５に、スナップショットとして格納する（Ｓ１１０）。

さらに、上述のステップＳ１０８でログ送信方法の項目が「２」だった場合には、制御部１０は、当該エラーに係るログファイル格納ディレクトリに格納されたログファイルを圧縮して圧縮ファイルを生成し、モニタ画面の画像ファイルデータとともに、圧縮フォルダ２５に、スナップショットとして格納する。そして、制御部１０は、生成した圧縮ファイルと画像ファイルデータとを含むログ情報を、モニタ装置３００（当該ＡＴＭ１００と同一店舗内のもの）に送信する（Ｓ１１１）。

さらにまた、上述のステップＳ１０８でログ送信方法の項目が「３」だった場合には、制御部１０は、当該エラーに係るログファイル格納ディレクトリに格納されたログファイルを圧縮して圧縮ファイルを生成し、モニタ画面の画像ファイルデータとともに、圧縮フォルダ２５に、スナップショットとして格納する。そして、制御部１０は、生成した圧縮ファイルと画像ファイルデータとを含むログ情報を、モニタ装置３００（当該ＡＴＭ１００と同一店舗内のもの）及びログサーバ５００に送信（Ｓ１１２）して当該エラーに係る処理を終了する。

ただし、制御部１０は、ログサーバ５００に送信しようとするログ情報を構成する圧縮ファイル（ログファイル）の容量が所定以上（２０ＭＢ以上）だった場合には、当該ログ情報については、圧縮ファイル（ログファイル）の送信は不可と判定する。そして、制御部１０は、存在する場合には画像データファイルのみをログサーバ５００に送信して、当該エラーに係る処理を終了する。

そして、制御部１０は、上述のステップＳ１０９〜Ｓ１１２のいずれかの処理が終了した後、スタックされているエラー（複数同時にエラー発生したが、いまだ未処理のエラー）が残っているか否かを確認する（Ｓ１１３）。そして、制御部１０は、スタックされているエラーが残っている場合、上述のステップＳ１０２の処理に戻ってスタックされているエラーの処理を開始し、スタックされているエラーが残っていない場合処理を終了する。

（Ａ−２−１）ＡＴＭ１００によるログ情報送信処理の動作
次に、ＡＴＭ１００が、モニタ装置３００にだけログ情報を送信する場合（ログ送信方法＝２の場合）の動作について図１５を用いて説明する。

図１５では、まず、ＡＴＭ１００でエラーが発生し（Ｓ２０１）、ログ情報の取得、ログ情報を構成するログファイルの圧縮処理等が行われたものとする（Ｓ２０２）。このステップＳ２０２の処理は、上述のステップＳ１０１〜Ｓ１０６の処理に対応する。

そして、ＡＴＭ１００から、当該エラーの発生の通知が、当該ＡＴＭ１００と同一営業店内のモニタ装置３００と、ログサーバ５００に通知される（Ｓ２０３、Ｓ２０４）。このステップＳ２０３、Ｓ２０４の処理は、上述のステップＳ１０７の処理に対応する。

そして、ＡＴＭ１００では、取得した処理定義データのログ送信方法の項目（当該エラーに対応するログ送信方法）が参照される（Ｓ２０５）。ＡＴＭ１００では、当該エラーに対応するログ送信方法は、「２」に設定されていたものとする。このステップＳ２０５の処理は、上述のステップＳ１０８の処理に対応する。

そして、ＡＴＭ１００は、当該エラーに対応するログ送信方法に従って、当該エラーに対応するログ情報（圧縮ファイル及び又は画像データファイルを含む）を、モニタ装置３００に送信する（Ｓ２０６）。

そして、モニタ装置３００では、ＡＴＭ１００からのエラー通知、及び、ログ情報供給に基づいて、エラー履歴データ３０２の内容が更新される（Ｓ２０７）。

また、ログサーバ５００では、ＡＴＭ１００からのエラー通知に基づいて、エラー履歴データ５０１の内容が更新される（Ｓ２０８）。

次に、ＡＴＭ１００が、モニタ装置３００及びログサーバ５００にログ情報を送信する場合（ログ送信方法＝３の場合）の動作について図１６を用いて説明する。

図１６では、まず、ＡＴＭ１００でエラーが発生し（Ｓ３０１）、ログ情報の取得、ログ情報を構成するログファイルの圧縮処理等が行われたものとする（Ｓ３０２）。

そして、ＡＴＭ１００から、当該エラーの発生の通知が、当該ＡＴＭ１００と同一営業店内のモニタ装置３００と、ログサーバ５００に通知される（Ｓ３０３、Ｓ３０４）。
なお、ステップＳ３０１〜Ｓ３０４のＡＴＭ１００による処理は、上述の図１５のステップＳ２０１〜Ｓ２０４と同様である。

そして、ＡＴＭ１００では、取得した処理定義データのログ送信方法の項目（当該エラーに対応するログ送信方法）が参照される（Ｓ３０５）。ＡＴＭ１００では、当該エラーに対応するログ送信方法は、「３」に設定されていたものとする。

そして、ＡＴＭ１００は、当該エラーに対応するログ情報（圧縮ファイル及び又は画像データファイルを含む）を、モニタ装置３００に送信する（Ｓ３０６）。

そして、ＡＴＭ１００は、当該エラーに対応するログ情報の収集を、ログサーバ５００に要求する（Ｓ３０７）。そして、ログサーバ５００では、当該ＡＴＭ１００からの要求に従って、ログ収集に応答し、ＡＴＭ１００からのログ情報の供給を受付ける（Ｓ３０８）。

ＡＴＭ１００からログサーバ５００へログ情報を送信する場合の手順については限定されないものであるが、この実施形態のログサーバ５００では、図１６に示すように、ＡＴＭ１００からログ収集に依頼を受付けて、当該ＡＴＭ１００に係るログ収集のタイミングをスケジューリングした後に収集を行うものとする。これは、ログサーバ５００側では、多数のＡＴＭ１００からのログ情報送信が輻輳しないようにスケジューリングするための処理である。なお、各ＡＴＭ１００からログサーバ５００へのログ情報送信をスケジューリングする方法は、これに限定されず、種々のスケジューリングのアルゴリズムを適用することができる。

そして、モニタ装置３００では、ＡＴＭ１００からのエラー通知、及び、ログ情報供給に基づいて、エラー履歴データ３０２の内容が更新される（Ｓ３０９）。

そして、ログサーバ５００では、ＡＴＭ１００からのエラー通知、及び、ログ情報供給に基づいて、エラー履歴データ５０１の内容が更新される（Ｓ３１０）。

（Ａ−２−２）Ｗｅｂ端末８００による情報参照について
次に、保守拠点Ｌ４のＷｅｂ端末８００で、ログ情報等が参照される処理の動作について説明する。

例えば、保守拠点Ｌ４の保守担当者が、あるＡＴ１００で障害が発生したことを、集中監視センタＬ３の監視担当者等から聞いた場合、その保守担当者は、Ｗｅｂ端末８００を用いて、当該ＡＴＭ１００に関するログ情報等を参照する。

図１７は、保守拠点Ｌ４のＷｅｂ端末８００で、Ｗｅｂサーバ７００を介してログサーバ５００に蓄積されたログ情報等が参照される処理の動作について示したシーケンス図である。

まず、保守担当者により、Ｗｅｂ端末８００が操作され、Ｗｅｂブラウザにより、Ｗｅｂサーバ７００にアクセスするための所定のＵＲＬへのアクセス（ＨＴＴＰによるアクセス）が実行されたものとする（Ｓ４０１）。

そして、Ｗｅｂサーバ７００では、Ｗｅｂ端末８００からの所定のＵＲＬに対するアクセスがされると、ログサーバ５００からエラー履歴データ５０１を取得する（Ｓ４０２）。このとき、Ｗｅｂサーバ７００は、エラー履歴データ５０１の全てのデータを取得するようにしてもよいし、直近に発生したエラー（例えば、１時間前までに発生したエラー等）に関する情報や、Ｗｅｂ端末８００からのリクエスト（例えば、指定ＵＲＬに付加された文字列等に基づくリクエスト）に基づいて、特定のＡＴＭ１００に関するエラー情報だけを抽出して取得するようにしてもよい。

ログサーバ５００からＷｅｂサーバ７００へ、エラー履歴データ５０１のデータを供給する構成については限定されないものであり、例えば、データベースの機能を用いたデータ供給（例えば、ＳＱＬ文によるデータリクエストに応答するデータ供給）を行うようにしてもよい。

そして、Ｗｅｂサーバ７００は、エラー履歴データ５０１の一部又は全部のデータを取得すると、そのエラー履歴データ５０１に基づいたＷｅｂ画面（以下、「エラー参照Ｗｅｂ画面」と呼ぶ）のデータ（ＨＴＭＬ形式等のデータ）を生成して、Ｗｅｂ端末８００に送信（ＨＴＴＰによる送信）する（Ｓ４０３）。そして、Ｗｅｂ端末８００では、Ｗｅｂサーバ７００から供給されたデータに基づいて、エラー参照Ｗｅｂ画面が表示される。

図１８は、エラー参照Ｗｅｂ画面の構成例について示した説明図である。

エラー参照Ｗｅｂ画面は、図１８に示す通り、エラーの発生状況を参照可能なテーブル形式の画面であり、各項目（各列）の内容は、エラー履歴データ５０１（上述の図１３）とほぼ共通している。

なお、図１８のエラー参照Ｗｅｂ画面は、図１３に示すエラー履歴データ５０１に基づいた内容となっている。以下では、エラー参照Ｗｅｂ画面について、エラー履歴データ５０１の構成との差異を説明する。

図１８に示すように、エラー参照Ｗｅｂ画面において、「モニタ画面」の項目には、空欄（ブランク）又は「参照」という文字のハイパーリンクが表示される。エラー参照Ｗｅｂ画面において、モニタ画面の項目に「参照」という文字のハイパーリンクが表示されているエラーについては、ログサーバ５００に当該エラーに対応するモニタ画面の画像データファイルが保持されている（エラー履歴データ５０１においてモニタ画面の項目が受信済になっている）ことを示している。保守担当者等により、いずれかのエラーに係るモニタ画面のハイパーリンク（「参照」と表示されたハイパーリンク）が選択（クリック）されると、Ｗｅｂ端末８００は、Ｗｅｂサーバ７００に対して、当該ハイパーリンクに対応する画像データファイル（当該エラーに対応するモニタ画面の画像データファイル）をリクエストを送信（操作信号を送信）することになる。

図１８に示すように、エラー参照Ｗｅｂ画面において、「ログ取得可否」の項目には、空欄（ブランク）、「可（ＸＭＢ）」という文字列のハイパーリンク（Ｘは対応するログファイルサイズ）、又は「現地で収集が必要（ＸＭＢ）」という文字列（Ｘは対応するログファイルサイズ）が表示される。

エラー参照Ｗｅｂ画面において、ログ取得可否の項目に「可（ＸＭＢ）」という文字列のハイパーリンクが表示されている場合には、当該エラーについては、ログサーバ５００でログファイルが保持されており、ダウンロード可能な状態であること（エラー履歴データ５０１において「ログファイル」の項目が「受信済」となっていること）を示している。

また、エラー参照Ｗｅｂ画面において、「ログ取得可否」の項目に「現地で収集が必要（ＸＭＢ）」という文字列が表示されている場合には、当該エラーについては、当該ＡＴＭ１００にログファイルの圧縮ファイルが退避されているが容量制限等により送信不可であったこと（エラー履歴データ５０１において「ログファイル」の項目が「受信不可」となっていること）を示している。

さらに、エラー参照Ｗｅｂ画面において、「ログ取得可否」の項目が空欄の場合には、当該エラーのログファイルについては未受信であること（エラー履歴データ５０１において「ログファイル」の項目が「未受信」となっていること）を示している。

保守担当者等により、いずれかのエラーに係る「ログ取得可否」のハイパーリンク（「可（ＸＭＢ）」と表示されたハイパーリンク）が選択（クリック）されると、Ｗｅｂ端末８００は、Ｗｅｂサーバ７００に対して、当該ハイパーリンクに対応するログファイル（当該エラーに対応する圧縮ファイル）をリクエストすることになる。

なお、図１８に示すモニタ画面又はログ取得可否の項目のハイパーリンクには、それぞれ、対応するファイル（画像データファイル又は圧縮ファイル）のファイル名（ログ情報保存フォルダ６０１におけるファイル名）がリンクされているものとする。Ｗｅｂサーバ７００は、例えば、エラー履歴データ５０１の内容（店番号、機番号、エラー発生日時等）に基づいて、各ファイルのファイル名を生成してハイパーリンクのリンク先に設定するようにしてもよい。また、ログサーバ５００からＷｅｂサーバ７００に、エラー履歴データ３０２と共に、各ファイルのファイル名を供給するようにしてもよい。

そして、図１８に示すようなエラー参照Ｗｅｂ画面で、いずれかのハイパーリンク（モニタ画面又はログ取得可否の項目のハイパーリンク）が選択(クリック)されると、Ｗｅｂ端末８００（Ｗｅｂブラウザ）は、Ｗｅｂサーバ７００に対して、当該ハイパーリンクに対応するデータ（画像データファイル、又は、ログファイルの圧縮ファイル）のダウンロードをリクエストする（Ｓ４０４）。

そして、Ｗｅｂサーバ７００は、Ｗｅｂ端末８００（Ｗｅｂブラウザ）からリクエストを受けたファイル（画像データファイル、又は、ログファイルの圧縮ファイル）を、ログサーバ５００からダウンロードする（Ｓ４０５）。

そして、Ｗｅｂサーバ７００は、Ｗｅｂ端末８００（Ｗｅｂブラウザ）に取得したファイルを送信する（Ｓ４０６）。そして、Ｗｅｂサーバ７００からファイル（ログファイル又は画像データファイル）を受信したＷｅｂ端末８００（Ｗｅｂブラウザ）では、当該ファイルの内容の表示処理等が行われることになる。
例えば、ダウンロードしたファイルが画像データファイルであれば、Ｗｅｂ端末８００（Ｗｅｂブラウザ）は、当該画像データファイルを表示したウィンドウをポップアップするようにしてもよい。また、例えば、ダウンロードしたファイルが圧縮ファイルである場合には、当該圧縮ファイルを解凍する処理等を行って、ログファイルの参照が可能な状態とするようにしてもよい。

（Ａ−２−３）ＡＴＭ１００におけるエラー管理
次に、ＡＴＭ１００を保守担当者等が直接操作し、ログファイル（圧縮ファイル）を直接取得（ＣＤ−Ｒにダウンロード）する処理等のエラー管理について説明する。

ＡＴＭ１００（制御部１０）では、後面操作表示部５２に対する操作に応じて、当該ＡＴＭ１００で発生したエラーに関する情報表示、及び、ログ情報に関する処理を受付けるための操作画面（以下、「ＡＴＭエラー管理画面」と呼ぶ）を表示する。

図１９は、ＡＴＭエラー管理画面の内容例について示した説明図である。

なお、図１９のＡＴＭエラー管理画面は、図１１に示すエラー履歴データ２７に基づいた内容となっている。以下では、ＡＴＭエラー管理画面について、エラー履歴データ２７の構成との差異を説明する。

「ログサーバ送信」の項目について、エラー履歴データ２７で「未送信」となっていた部分が、ＡＴＭエラー管理画面では「実行」と表示された実行ボタン（オブジェクト）に置き換わっている。ＡＴＭエラー管理画面で、いずれかのエラーに対応するログサーバ送信の項目の実行ボタンが押下されると、制御部１０（保守運用処理部１２）は、当該エラーに対応するログ情報（圧縮ファイル及び又は画像データファイル）をログサーバ５００に送信する処理（上述のステップＳ３０７、Ｓ３０８と同様の処理）を行う。

「モニタ装置送信」の項目について、エラー履歴データ２７で「未送信」となっていた部分が、ＡＴＭエラー管理画面では実行ボタン（オブジェクト）に置き換わっている。ＡＴＭエラー管理画面で、いずれかのエラーに対応するモニタ装置送信の項目の実行ボタンが押下されると、制御部１０（保守運用処理部１２）は、当該エラーに対応するログ情報（圧縮ファイル及び又は画像データファイル）をモニタ装置３００に送信する処理（上述のステップＳ３０６と同様の処理）を行う。

ＡＴＭエラー管理画面では、エラー履歴データ２７と比較すると、「媒体出力」の項目が追加されている。それぞれのエラーに対応する媒体出力の項目には、実行ボタン（オブジェクト）が表示されている。ＡＴＭエラー管理画面で、いずれかのエラーに対応する媒体出力の項目の実行ボタンが押下されると、制御部１０（保守運用処理部１２）は、当該エラーに対応するログ情報（圧縮ファイル及び又は画像データファイル）を、ＣＤドライブ３０３にセットされた媒体（ＣＤ−Ｒ）に追加書込みする処理を行う。制御部１０（保守運用処理部１２）は、ＣＤドライブ３０３にセットされた媒体の残り容量が許す限り、複数のエラーのエラー情報を書き込むことができる。

なお、ＡＴＭエラー管理画面で、ログ情報が圧縮フォルダ２５に退避されていないエラー（ログ送信方法が「０」のエラー）について実行ボタンが押下された場合には、ＡＴＭ１００の制御部１０は、当該エラーのログ情報について圧縮処理及び圧縮フォルダ２５への退避を行った上で、媒体出力や送信処理を行う。ただし、実行ボタンが押下された時点で、当該エラーに係るログ情報のファイルがｗｏｒｋフォルダ２４に格納されていない場合には、ＡＴＭ１００の制御部１０は、実行不可である旨のメッセージ出力等を行うようにしてもよい。

以上のように、保守担当者は、ＡＴＭ１００を操作することにより、大容量のログ情報であってもＣＤ−Ｒ等の媒体を用いて取得することができる。

（Ａ−２−４）モニタ装置３００におけるエラー管理
次に、モニタ装置３００を保守担当者等が直接操作し、ログファイル（圧縮ファイル）を直接取得（ＣＤ−Ｒにダウンロード）する処理等のエラー管理について説明する。

モニタ装置３００では、ユーザの操作に応じて、当該モニタ装置３００と同じ営業店のＡＴＭ１００で発生したエラーに関する情報表示、及び、ログ情報に関する処理を受付けるための操作画面（以下、「モニタ装置エラー管理画面」と呼ぶ）をディスプレイに表示する。

図２０は、モニタ装置エラー管理画面の内容例について示した説明図である。

なお、図２０のモニタ装置エラー管理画面は、図１２に示すエラー履歴データ３０２に基づいた内容となっている。以下では、モニタ装置エラー管理画面について、エラー履歴データ３０２の構成との差異を説明する。

モニタ装置エラー管理画面の「ログサーバ送信」の項目では、ログ情報が受信済のエラーのうち、当該モニタ装置３００からログサーバ５００へ未送信のエラーについて、「実行」と表示された実行ボタン（オブジェクト）が表示される。モニタ装置エラー管理画面で、いずれかのエラーに対応するログサーバ送信の項目の実行ボタンが押下されると、モニタ装置３００は、当該エラーに対応するログ情報（圧縮ファイル及び又は画像データファイル）をログサーバ５００に送信する処理を行う。なお、モニタ装置３００からログサーバ５００へログ情報を送信する処理は、例えば、ＡＴＭ１００の場合の処理（上述のステップＳ３０７、Ｓ３０８の処理）と同様の処理により行うことができる。

モニタ装置エラー管理画面では、エラー履歴データ３０２と比較すると、「媒体出力」の項目が追加されている。それぞれのエラーに対応する媒体出力の項目には、ログ情報が受信済のエラーについて、実行ボタン（オブジェクト）が表示されている。モニタ装置エラー管理画面で、いずれかのエラーに対応する媒体出力の項目の実行ボタンが押下されると、モニタ装置３００は、当該エラーに対応するログ情報（圧縮ファイル及び又は画像データファイル）を、ＣＤドライブ３０３にセットされた媒体（ＣＤ−Ｒ）に追加書込みする処理を行う。

以上のように、保守担当者は、モニタ装置３００を操作することにより、大容量のログ情報であってもＣＤ−Ｒ等の媒体を用いて取得することができる。

（Ａ−３）実施形態の効果
この実施形態によれば、以下のような効果を奏することができる。

（Ａ−３−１）従来のシステムでは、ＡＴＭで障害が発生した場合に、保守担当者は、過去の経験やマニュアルに基づいて、当該ＡＴＭから取得する必要のあるログ情報の内容を判断しなければならない場合があった。また、設計・開発部門に必要なログを確認することが必要な場合もある。そのため、従来のシステムでは、ＡＴＭの障害に対応する際に、事前に障害解析を行う担当者に、必要なログ情報をわたすまでに時間がかかるために、障害復旧に遅れが生じる場合があった。

これに対してこの実施形態では、ＡＴＭ１００で障害発生（エラー発生）と同時に、ログ情報をエラー処理定義データ２１に従って退避し、保守担当者等が使用するＷｅｂ端末８００からアクセス可能としている。これにより、保守担当者等は、即座にＡＴＭ１００のログ情報を取得して、障害解析に取り掛かることができる。

なお、ＡＴＭ１００の障害解析だけを行う担当者（例えば、開発担当者等）が居る拠点にも保守拠点Ｌ４と同様のＷｅｂ端末を配置して、障害解析の担当者にエラー参照Ｗｅｂ画面を参照させるようにしてもよい。

（Ａ−３−２）従来のシステムを利用する場合、ＡＴＭでの障害発生時に、保守担当者等から、営業店の係員や集中監視センタの監視担当者へのヒアリングだけでは、ＡＴＭから取得すべきログ情報の内容がしぼりこめない場合があった。一方、取得可能な全てのログ情報を取得する場合、そのログ情報の内容は膨大となり、保守担当者がオンサイトでＣＤ−Ｒ等の媒体で取得する必要があった。すなわち、この場合、保守担当者はログ情報の解析のためだけに現場（障害発生したＡＴＭの設置場所）まで移動する必要があり、結果として障害復旧が遅れてしまう場合があった。また、膨大なログの中から必要なログを抽出し、原因を搾り込む必要がある為、障害解析にも時間がかかり、更に障害復旧が遅れる要因となる場合があった。

これに対して、この実施形態のＡＴＭ１００は、エラー処理定義データ２１に従って、エラーごとに必要なログ情報だけを、ＡＴＭ１００内の退避先（圧縮フォルダ２５）、ログサーバ５００、及びモニタ装置３００等に退避して保管している。これにより、保守担当者は、ＡＴＭ１００で障害が発生した場合、不必要なログ情報まで取得する必要がないため、効率的な障害対応を行うことができる。

（Ａ−３−３）従来のシステムでは、保守担当者がオンサイトでＡＴＭからログ取得する場合、現場に移動するまでの時間等がかかるため、当該ＡＴＭ内で障害解析に必要なログ情報が削除（上書き等）される場合があった。その場合、保守担当者がＡＴＭからログ収集しても、必要なログ情報が含まれていないため、解析しても障害解析ができないことになる。

これに対して、この実施形態の取引システム１０００では、エラー処理定義データ２１に従って、エラーごとに必要なログ情報を、ＡＴＭ１００内の退避先（圧縮フォルダ２５）、ログサーバ５００、及びモニタ装置３００等の複数の退避先に退避することができる。これにより、この実施形態の取引システム１０００では、従来のように、時間経過によりＡＴＭ内で障害解析に必要なログ情報が削除されたりすることがなくなり、確実に障害解析に必要なログ情報を保守担当者等に参照させることができる。

（Ａ−３−４）ＡＴＭの障害解析において、障害が発生した時点の装置の状況を正確に且つ簡素に把握することは、対処方法を決定する上で非常に重要である。しかし、ＡＴＭの保守担当者にとって、営業店の係員や監視センタの監視担当者からの状況のヒアリングだけでは、情報が不足して不正確となる場合があった。また、ＡＴＭの障害発生時の状態を正確に把握するためには、ログ情報の各要素を時系列に整理し、サマリ化する必要がある場合もある。そして、そのようなサマリ化が必要な場合、従来のシステムの環境下では、保守担当者等による作業を多く必要とする場合があった。

これに対して、この実施形態のＡＴＭ１００では、エラー処理定義データ２１に従って、エラー発生時点（障害発生時点）のモニタ画面の画像データファイルを取得してログサーバ５００にログ情報の一部として供給している。そして、ログサーバ５００で蓄積されたその画像データファイルは、Ｗｅｂサーバ７００を介して、保守担当者が使用するＷｅｂ端末８００に出力することができる。これにより、保守担当者は、営業店Ｌ２に移動しなくても、障害発生したＡＴＭ１００の状態を端的且つ正確に確認することができる。すなわち、この実施形態の取引システム１０００では、迅速に保守担当者等に障害発生時の状態をサマリ化した情報（モニタ画面の画像データファイル）を出力することができ、従来よりも効率的な保守対応が可能となる。

（Ｂ）他の実施形態
本発明は、上記の各実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。

（Ｂ−１）上記の各実施形態では、本発明の取引システム及び取引装置を、金融機関等の取引システム（ＡＴＭを用いた取引システム）に適用する例について説明したが、その他の取引システムに適用するようにしても良い。例えば、電子マネー等を顧客の口座にチャージ（入金）する取引や、顧客の口座から電子マネーを引き落として商品（例えば、交通機関等のチケット等）を販売する取引装置を備える取引システムにも適用し得る。

（Ｂ−２）上記の実施形態では、Ｗｅｂ端末８００は、Ｗｅｂサーバ７００を介して、ログサーバ５００にアクセスしているが直接アクセスする構成としてもよい。すなわち、ログサーバ５００自体にＷｅｂサーバの機能を追加するようにしてもよい。

（Ｂ−３）上記の実施形態では、ＡＴＭ１００では、前面操作表示部５１、及び後面操作表示部５２）が配置されているが、ＡＴＭ１００に搭載される操作表示部（タッチパネルディスプレイ）の数は限定されないものである。例えば、ＡＴＭ１００において１つの操作表示部しか備えられていない場合は、取引処理部１１及び保守運用処理部１２で、１つの操作表示部（タッチパネルディスプレイ）を共用することになる。その場合、例えば、制御部１０（取引処理部１１及び保守運用処理部１２）では、２つの画面（例えば、取引用の操作画面及びモニタ画面）の映像信号を出力したままの状態とし、２つの画面のいずれかを切り替えて、１つの操作表示部（タッチパネルディスプレイ）に表示可能な構成としてもよい。そして、例えば、操作表示部（タッチパネルディスプレイ）に、取引処理部１１が出力した取引用の操作画面が表示された状態であっても、保守運用処理部１２からもモニタ画面の映像信号は出力したままの状態とすることで、制御部１０はエラー発生時にモニタ画面をキャプチャして画像データファイルを得ることができる。例えば、ＡＴＭ１００において、いわゆるマルチディスプレイの方式を適用することにより、２つの画面（例えば、取引用の操作画面及びモニタ画面）のいずれかを、一つの操作表示部（タッチパネルディスプレイ）に切替えて表示しつつ、常時モニタ画面のキャプチャが可能な構成とすることができる。

（Ｂ−４）ログサーバ５００のエラー履歴データ５０１における、「ログファイル」の項目については、当該エラーに係るログ情報（ログファイル）を受信中の場合に、「収集中」と設定するようにしてもよい。また、Ｗｅｂサーバ７００が出力するエラー参照Ｗｅｂ画面の「ログ取得可否」の項目についても、同様に「収集中」の表示とするようにしてもよい。

（Ｂ−５）上記の実施形態の取引システム１０００では、ＡＴＭ１００でエラーが発生した場合のログ情報の処理について説明したが、エラー以外のイベントが発生した場合でも、同様にログ情報の処理を行うようにしてもよい。ＡＴＭ１００で発生するエラー以外のイベントとしては、例えば、ＡＴＭ１００が起動した場合や、再起動した場合等が挙げられる。

１０００…取引システム、１００、１００−１〜１００−Ｎ…ＡＴＭ、１０…制御部、１１…取引処理部１２…保守運用処理部、２０…データ記憶部、２１…エラー処理定義データ、２２…ログ取得方法定義データ、２３…ログ送信方法定義データ、２４…ｗｏｒｋフォルダ、２５…圧縮フォルダ、２６…ログ出力フォルダ、２７…エラー履歴データ、３０…通信部、４０…カードリーダライタ、５０…操作表示部、５１…前面操作表示部、５２…後面操作表示部、Ｐ１…扉、６０…プリンタ、７０…通帳処理部、８０…現金処理部、９０…ＣＤドライブ、２００…ホストコンピュータ、３００…モニタ装置、３０１…ログ情報保存フォルダ、３０２…エラー履歴データ、３０３…ＣＤドライブ、４００…管理端末、５００…ログサーバ、５０１…エラー履歴データ、６００…ストレージ、６０１…ログ情報保存フォルダ、６０２…エラー履歴データ、７００…Ｗｅｂサーバ、８００…Ｗｅｂ端末。

Claims (9)

1. １又は複数の取引装置を有する取引システムにおいて、
   上記取引装置の状態に関する情報を含む装置情報を、上記取引装置から取得して蓄積する装置情報蓄積手段を１又は複数備え、
   それぞれの上記取引装置は、
   当該取引装置で発生するイベントごとに、当該イベント発生時に当該取引装置内で保持する装置情報の内容、及び、保持した装置情報の供給先を定義した定義情報を記憶する定義情報記憶手段と、
   当該取引装置でイベント発生時に、上記定義情報に従って、当該イベントに対応する装置情報を保持する装置情報保持手段と、
   上記装置情報保持手段が保持した装置情報のうち、上記定義情報でいずれかの上記装置情報蓄積手段が供給先として定義されている装置情報について、上記定義情報で定義された上記装置情報蓄積手段に供給する装置情報供給手段とを有し、
   上記装置情報供給手段は、上記装置情報保持手段が保持した装置情報のうち、上記定義情報で供給先が定義されていない装置情報について、ユーザの操作に応じて、１又は複数の上記装置情報蓄積手段に供給する
   ことを特徴とする取引システム。
2. それぞれの上記取引装置は、
   当該取引装置の状態を表す装置状態画像を表示出力することが可能な装置状態画像表示出力手段と、
   上記装置状態画像表示出力手段が表示出力する装置状態画像の画像データを取得することが可能な装置状態画像データ取得手段をさらに備え、
   上記定義情報には、イベントごとに、上記装置状態画像データ取得手段を用いて、現在の装置状態画像を装置情報の一部として取得する必要の有無が定義されており、
   上記装置情報保持手段は、上記定義情報に従って、必要な場合、上記装置状態画像データ取得手段を用いて、現在の装置状態画像を装置情報の一部として保持する
   ことを特徴とする請求項１に記載の取引システム。
3. それぞれの上記取引装置は、当該取引装置の状態に関する状態情報を保持することが可能な状態情報保持手段をさらに備え、
   それぞれの上記取引装置の上記装置情報保持手段は、上記定義情報に従って、必要な場合、上記状態情報保持手段を用いて、現在の当該取引装置の状態情報を装置情報の一部として保持する
   ことを特徴とする請求項２に記載の取引システム。
4. それぞれの上記取引装置は、上記装置情報保持手段が保持した装置情報を格納することが可能な装置情報格納部を、上記装置情報蓄積手段の一つとして備えることを特徴とする請求項３に記載の取引システム。
5. それぞれの上記取引装置は、上記装置情報格納部に格納された装置情報を、ユーザの操作に応じて媒体に書込むことが可能な媒体書込手段をさらに備えることを特徴とする請求項４に記載の取引システム。
6. それぞれの上記取引装置の上記装置情報供給手段は、ユーザの操作に応じて、上記装置情報格納部に格納された装置情報を、当該取引装置の外部に配置された上記装置情報蓄積手段に供給することを特徴とする請求項４に記載の取引システム。
7. 端末装置と
   上記装置情報蓄積手段に蓄積された装置情報の一覧を参照可能な操作画面を、上記端末装置に提供する操作画面提供手段と
   をさらに備えることを特徴とする請求項１に記載の取引システム。
8. 上記操作画面提供手段は、上記端末装置から操作信号が供給されると、当該操作信号で指定された装置情報を、上記端末装置に供給することを特徴とする請求項７に記載の取引システム。
9. 取引装置において、
   当該取引装置で発生するイベントごとに、当該イベント発生時に当該取引装置内で保持する当該取引装置の状態に関する情報を含む装置情報の内容、及び、保持した装置情報の供給先を定義した定義情報を記憶する定義情報記憶手段と、
   当該取引装置でイベント発生時に、上記定義情報に従って、当該イベントに対応する装置情報を保持する装置情報保持手段と、
   上記装置情報保持手段が保持した装置情報のうち、上記定義情報でいずれかの装置情報蓄積手段が供給先として定義されている装置情報について、上記定義情報で定義された上記装置情報蓄積手段に供給する装置情報供給手段とを有し、
   上記装置情報供給手段は、上記装置情報保持手段が保持した装置情報のうち、上記定義情報で供給先が定義されていない装置情報について、ユーザの操作に応じて、１又は複数の上記装置情報蓄積手段に供給する
   ことを特徴とする取引装置。

Images