(57)【要約】【課題】システム全体として各ＡＴＭ装置のジャーナルデータのスプール件数を平準化することを可能とする。【解決手段】各ＡＴＭ１０は、ジャーナル送信制御部１２を有する。ジャーナル送信制御部１２は、未送信の複数件のジャーナルデータがある場合、これらジャーナルデータを、１件ずつ、任意の送信間隔を空けながら送信するジャーナル送信機能を有する。そして、ジャーナルデータのスプール件数に応じて、スプール件数が多いほど送信間隔が短くなるように、送信間隔の長さを動的に決定／変更する送信間隔設定機能も有する。【選択図】図２
2012141669.tif 000002
【特許請求の範囲】
【請求項１】
上位装置と、複数の自動取引装置とがネットワークに接続された自動取引システムであって、
前記自動取引装置は、
任意の事象発生毎に、この事象に係るジャーナルデータを生成して記憶するジャーナルデータ生成記憶手段と、
該記憶されているジャーナルデータのうち未送信のジャーナルデータを前記ネットワークを介して前記上位装置へ送信する手段であって、該未送信ジャーナルデータを１件ずつ任意の送信間隔を空けながら送信するジャーナル送信手段と、
任意のときに、前記未送信ジャーナルデータの件数に応じて、前記送信間隔の長さを決定する送信間隔設定手段と、
を有することを特徴とする自動取引システム。
【請求項２】
前記送信間隔設定手段は、前記未送信ジャーナルデータの件数が多いほど前記送信間隔が短くなるように、前記送信間隔の長さを決定することを特徴とする請求項１記載の自動取引システム。
【請求項３】
予め任意の１種類以上の閾値と該各閾値に対応付けた設定候補値が記憶されており、
前記送信間隔設定手段は、前記未送信ジャーナルデータの件数を各閾値と大小比較して、該大小比較結果に応じて前記設定候補値の何れかを前記送信間隔の長さとして決定することを特徴とする請求項２記載の自動取引システム。
【請求項４】
上位装置と、複数の自動取引装置とがネットワークに接続された自動取引システムにおける前記自動取引装置であって、
任意の事象発生毎に、この事象に係るジャーナルデータを生成して記憶するジャーナルデータ生成記憶手段と、
該記憶されているジャーナルデータのうち未送信のジャーナルデータを前記ネットワークを介して前記上位装置へ送信する手段であって、該未送信ジャーナルデータを１件ずつ任意の送信間隔を空けながら送信するジャーナル送信手段と、
任意のときに、前記未送信ジャーナルデータの件数に応じて、前記送信間隔の長さを決定する送信間隔設定手段と、
を有することを特徴とする自動取引システムの自動取引装置。
【請求項５】
上位装置と、複数の自動取引装置とがネットワークに接続された自動取引システムにおける前記自動取引装置のコンピュータを、
任意の事象発生毎に、この事象に係るジャーナルデータを生成して記憶するジャーナルデータ生成記憶手段と、
該記憶されているジャーナルデータのうち未送信のジャーナルデータを前記ネットワークを介して前記上位装置へ送信する手段であって、該未送信ジャーナルデータを１件ずつ任意の送信間隔を空けながら送信するジャーナル送信手段と、
任意のときに、前記未送信ジャーナルデータの件数に応じて、前記送信間隔の長さを決定する送信間隔設定手段、
として機能させる為のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、自動取引システム、その自動取引装置等に関する。
【背景技術】
【０００２】
金融機関等には、顧客に入金、出金、振込み等を行わせる為の現金自動取引装置（以下、ＡＴＭという）が設置されている。また、近年は、金融機関に限らず、コンビニエンスストア等にも現金自動取引装置（ＣＤ（Cash dispenser）等）が設置されている。尚、ＡＴＭは、Automated teller machineの略である。尚、振込み等では、現金を用いない取引もあるので、現金自動取引装置ではなく、単に自動取引装置等と呼ぶ場合もある。
【０００３】
ＡＴＭでは、各顧客によって何らかの取引（入金、出金、振込み等）の操作が行われる毎に、この取引の内容（顧客の氏名、口座番号、取引金額、取引日時等）の全部または一部を、内蔵のプリンタ等によってジャーナル用紙に印字すると共に、記憶装置（メモリ、ハードディスク等）に記憶している。この様な取引データは、ジャーナルデータや電子ジャーナル等と呼ばれている。
【０００４】
この様な電子ジャーナルは、ＡＴＭ装置の故障等によって消失する可能性があった。この為、各ＡＴＭをＷＡＮ（Wide Area Network（広域ネットワーク））等のネットワークに接続して、このネットワークに接続するサーバ装置を設け、各ＡＴＭが自装置のジャーナルデータをネットワークを介してサーバ装置に送信して格納させるシステム（以下、ＡＴＭシステムまたは自動取引システムという）が構築されている。
【０００５】
例えば、特許文献１，２，３等に記載の従来技術が知られている。
特許文献１には、複数のＡＴＭとホストコンピュータからなる自動取引システムが開示されている。また、各ＡＴＭが、取引内容を電子ジャーナルとしてジャーナル記録部に記録し、この電子ジャーナルをホストコンピュータへ送信することが開示されている。電子ジャーナルをＡＴＭとホストコンピュータの双方で管理することにより、何れか一方にデータの消失等の異常が生じても、電子ジャーナルを容易に復旧することが可能となる。
【０００６】
また、特許文献１には、ＡＴＭ毎に、電子ジャーナルを送信するタイミング（「毎回取引直後」、「毎日○時」等）を任意に設定可能とすることが開示されている。
また、特許文献２には、各ＡＴＭが、ジャーナルデータを一時記憶装置に保存し、また、ジャーナルデータを暗号化して通信回線を介してジャーナル管理サーバに送信することが開示されている。ジャーナル管理サーバは、受信したジャーナルデータを記憶装置に格納して一括管理する。各ＡＴＭにおいて、取引の実行等によりジャーナルデータが発生する毎に、このジャーナルデータをジャーナル管理サーバに送信する。
【０００７】
また、特許文献３には、ジャーナル収集サーバからの指示により、各ＡＴＭの記憶部から定期的に（リアルタイムでもよい）電子ジャーナルをジャーナル収集サーバの電子ジャーナルデータベースに収集することが開示されている。
【０００８】
尚、特許文献１では、電子ジャーナルをＡＴＭとホストコンピュータの双方で記憶・管理するが、この例に限らない。例えば、各ＡＴＭが、自端末で発生したジャーナルデータをホストコンピュータに送信して格納させたら、自端末に記憶している当該ジャーナルデータを削除する、等という構成のＡＴＭシステム等も存在する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００４−１６４２０９号公報
【特許文献２】特開２００８−８４３４５号公報
【特許文献３】特開２００８−２１７５２８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
例えばジャーナル集中化機能を採用しているＡＴＭシステムでは、上記のようにジャーナルデータ送信のため、ＡＴＭ−サーバ間で通信が発生する。ＡＴＭ−サーバ間の通信トラフィック量は、通信環境毎に異なる（例えば、回線の太さ、ＡＴＭの台数やサーバへの接続数、各ＡＴＭからのデータ送信頻度等による）。通信トラフィック量が増加し過ぎないように、ジャーナルデータの送信インターバル（後述する）を調整する必要がある。現状は、作業員等が、通信環境毎に通信トラフィック量を測定し、手動で送信インターバルを設定していた。しかし、これは固定的な設定であり、通信トラフィック量の動的な変化には対応できない。尚、通信トラフィック量は、季節、曜日、時間帯によっても変化するが、この様な中期的な変動以外に、上記サーバへの接続数や各ＡＴＭからのデータ送信頻度等に応じた短期的、極短期的な変動がある。
【００１１】
尚、実際には、各ＡＴＭシステム毎に、そのシステム内の全ＡＴＭの送信インターバルを同一（例えば１０秒等）とするケースが少なくない。よって、送信インターバルを変更する場合、全ＡＴＭの設定変更を行う必要があり、これを手動で行う場合には非常に手間が掛かることになる。
【００１２】
上記のように、従来では、例えば電子ジャーナルをＡＴＭとホストコンピュータの双方で記憶・管理する為に（但し、上記の通り、この例に限らないが）、各ＡＴＭは、自装置で発生した電子ジャーナルを、通信回線を介してサーバ装置に送信して格納・管理させる。
【００１３】
何れにしても、従来より、各ＡＴＭは、自装置においてジャーナルデータが発生する毎に、これを自装置内の記憶装置（例えばＨＤＤ（ハードディスクドライブ）等）に一旦スプールすると共に、例えば直ちにサーバ装置に送信して格納させていた。つまり、各ＡＴＭで発生したジャーナルデータが、リアルタイムでサーバ装置に送信されて格納されるＡＴＭシステムが、従来より存在している。
【００１４】
しかしながら、例えば以下に記すような理由により、複数の（場合によっては多数の）ジャーナルデータが、未送信でＡＴＭ側に蓄積される事態（スプール件数が増大する状況）が生じる場合がある。
【００１５】
例えば、サーバ装置が、非常に多数のＡＴＭのジャーナルデータ等を格納・管理するものである場合（例えば全店舗の全ＡＴＭのデータを集中管理する場合等）、ＡＴＭがサーバ装置に接続できない状況が発生し得る。つまり、サーバ装置へのアクセス数には上限がある（例えば、一度に２０台程度）。このため、例えば２０台のＡＴＭがサーバ装置にアクセスしている状況で、更に任意のＡＴＭがサーバ装置にアクセスしようとしても、接続できないことになる。
【００１６】
この様な場合、サーバ装置への接続を失敗したＡＴＭは、所定の送信リトライ間隔を置いて、再度、接続を試みることになり、それでも接続失敗したならば、更に所定の送信リトライ間隔を置いて、再々度、接続を試みることになる。但し、リトライ数には上限があり、上限に達したならば、今回の接続を諦め、所定の送信インターバルを挟んで、再び接続を試みることになる。そして、接続成功しないまま時間経過して、その間に新たな取引が行われて新たなジャーナルデータが発生することで、未送信のジャーナルデータが蓄積されていくことになる（スプール件数が増大する）。
【００１７】
あるいは、任意のＡＴＭの通信機能が一時的に不調になったり、あるいは任意のＡＴＭの通信回線断（例えば人間が不注意／間違い等により回線を外してしまう等）により、任意のＡＴＭにおいて一時的にジャーナルデータを送信できない状態となる場合があり得る。このような状態のときに発生したジャーナルデータは、未送信のまま当該ＡＴＭに蓄積されていくことになる。
【００１８】
あるいは、サーバ装置側に一時的に通信障害等が発生して、このサーバ装置に係る全てのＡＴＭが、自装置のジャーナルデータをサーバ装置に送信できない状態となることも考えられる。尚、この場合、繁忙店に設置されるＡＴＭと、閑散店に設置されるＡＴＭとでは、取引頻度が異なる為、未送信のジャーナルデータの件数（増加数）が、異なることになる。当然、繁忙店のＡＴＭの方が、未送信のジャーナルデータの件数（増加数）が多くなることになる。
【００１９】
ここで、各ＡＴＭは、基本的には、未送信ジャーナルデータを１件送信完了したら、所定の間隔（上記送信インターバル）を空けてから、次の未送信ジャーナルデータを送信するものである。換言すれば、複数の未送信ジャーナルデータがあった場合に、これらをまとめて一度に送信するようなことは行われないものである。例えば、仮に、上記接続失敗は無いものとし（常に接続成功するものとし）、未送信のジャーナルデータが３件あるものとする。この場合、まず、１件目のジャーナルデータを送信完了したら、そこから所定時間（送信インターバル）経過後に、２件目のジャーナルデータを送信開始する。２件目のジャーナルデータを送信完了したら、そこから所定時間（送信インターバル）経過後に、３件目のジャーナルデータを送信開始する。
【００２０】
この様に、３件連続して送信せずに、送信インターバルを挟んで１件ずつ送信する理由は、以下の通りである。
すなわち、まず、営業中であって、特に昼休み等の混雑時であり顧客が次々とＡＴＭを利用する状況を想定する。この様な状況では、ＡＴＭの演算処理部（ＣＰＵ等）は、顧客の取引に係る様々な制御処理（画面表示、カード読取、通帳記帳、入金／出金処理等）を次々と実行しており、更にジャーナルデータ送信処理を行うことになる。
【００２１】
ここで、上記の通り電子ジャーナルはまずＡＴＭ内の記憶装置に記憶するが、その際、暗号化してから記憶する。そして、サーバ装置に送信する際には、この暗号化電子ジャーナルを復号して平文の電子ジャーナルに戻した後、今度はサーバ装置との間で決めたセッション鍵等を用いて電子ジャーナルを暗号化してから、この暗号化データを送信することになる。つまり、電子ジャーナル送信には、かなりの処理負荷が掛かることになる。これは、上記顧客の取引に係る様々な制御処理（取引処理）に影響を与え、取引処理が遅くなる等の悪影響が生じるおそれがあった。この為、上記送信インターバルを設けることで処理負荷を軽減している。
【００２２】
上記送信インターバルは、予め任意に設定される時間であり、基本的に全てのＡＴＭで同じ時間が設定される（但し、この例に限らない）。また、複数のジャーナルデータがスプールされている場合、古いデータから順に送信される。
【００２３】
ジャーナルデータが大量にスプールされた場合、ジャーナルデータが生成されたタイミングとそれがサーバ装置に送信・格納されるタイミングとが、大幅にズレてしまう可能性がある。これは、リアルタイムでのジャーナル送信・格納を行うシステムにとっては、好ましくない状況である。また、各ＡＴＭ毎にはそのＡＴＭに係るジャーナルを古い方から順に送信できるが、システム全体で見た場合、ジャーナルデータが少量だけスプールされたＡＴＭでは既に最新のジャーナルデータを送っている状況でも、ジャーナルデータが大量にスプールされたＡＴＭでは未だ古いジャーナルデータを送っている状況となることも起こり得る。つまり、システム全体で見た場合に（サーバ装置側から見た場合に）、必ずしも古いデータから順にサーバが受信・格納できるものではない。
【００２４】
本発明の課題は、上位装置と複数の自動取引装置とがネットワークに接続され、各自動取引装置がジャーナルデータを上位装置に送信して格納させるシステムにおいて、個々の自動取引装置毎に自装置のジャーナルデータのスプール件数に基づいて送信インターバルを動的に調整することで、システム全体として各自動取引装置のジャーナルデータのスプール件数を平準化することができる、自動取引システム、その自動取引装置等を提供することである。
【課題を解決するための手段】
【００２５】
本発明の自動取引システムは、上位装置と、複数の自動取引装置とがネットワークに接続された自動取引システムであって、前記自動取引装置は、任意の事象発生毎に、この事象に係るジャーナルデータを生成して記憶するジャーナルデータ生成記憶手段と、該記憶されているジャーナルデータのうち未送信のジャーナルデータを前記ネットワークを介して前記上位装置へ送信する手段であって、該未送信ジャーナルデータを１件ずつ任意の送信間隔を空けながら送信するジャーナル送信手段と、任意のときに、前記未送信ジャーナルデータの件数に応じて、前記送信間隔の長さを決定する送信間隔設定手段とを有する。
【００２６】
各自動取引装置個々で、例えば随時、未送信ジャーナルデータ件数に応じて、送信間隔の長さを動的に決定／変更することで、例えば一例としては、未送信ジャーナルデータ件数が多い自動取引装置は、送信間隔が短くなって単位時間当たりの送信件数を増加させることになる。
【発明の効果】
【００２７】
本発明の自動取引システム、その自動取引装置等によれば、上位装置と複数の自動取引装置とがネットワークに接続され、各自動取引装置がジャーナルデータを上位装置に送信して格納させるシステムにおいて、個々の自動取引装置毎に自装置のジャーナルデータのスプール件数に基づいて送信インターバルを動的に調整することで、システム全体として各自動取引装置のジャーナルデータのスプール件数を平準化することができる。
【図面の簡単な説明】
【００２８】
【図１】本例のＡＴＭシステム全体の概略構成図である。
【図２】（ａ）、（ｂ）は、ＡＴＭ、集中サーバの概略ハードウェア構成図である。
【図３】ジャーナルデータ生成・送信に係る状態遷移図である。
【図４】送信用ファイル生成処理のフローチャート図である。
【図５Ａ】送信処理のフローチャート図である。
【図５Ｂ】送信処理のフローチャート図である。
【図６】ジャーナルデータのデータ項目の一例を示す図である。
【発明を実施するための形態】
【００２９】
以下、図面を参照して、本発明の実施の形態について説明する。
尚、本説明では、自動取引装置の一例としてＡＴＭ（Automated teller machine）を示し、自動取引システムの一例としてＡＴＭシステムを示すが、この例に限らない。例えば、自動取引装置の他の例として、所謂ＣＤ（Cash dispenser）等もある。自動取引システムは、ＡＴＭの代わりにＣＤが用いられるシステム、あるいはＡＴＭとＣＤが混在するシステム等であってもよい。但し、本説明ではＡＴＭを例にするものとする。また、本説明では、上位装置の一例として集中サーバ２０を例にして説明するが、この例に限らない。上位装置の他の例としては、例えば銀行のホストコンピュータ等であってもよい。
【００３０】
図１は、本例のＡＴＭシステム全体の概略構成図である。
図示の通り、複数のＡＴＭ１０と、集中サーバ２０とが、ネットワーク１に接続している。ネットワーク１は、例えばＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等であり、各ＡＴＭ１０と集中サーバ２０は、ＨＴＴＰ（Hypertext Transfer Protocol）通信によって相互にデータ送受信等が可能になっている。
【００３１】
各ＡＴＭ１０は、送信用ジャーナル記憶部１１を有する。集中サーバ２０は、集中ジャーナル記憶部２１を有する。また、各ＡＴＭ１０は、ジャーナル送信制御部１２を有する。また、集中サーバ２０は、ジャーナル集中管理部２２を有する。ジャーナル送信制御部１２は、自装置（ＡＴＭ１０）で発生したジャーナルデータを、送信用ジャーナル記憶部１１に記憶後、ネットワーク１を介して集中サーバ２０へ送信する。ジャーナル集中管理部２２は、各ＡＴＭ１０から送信されてくるジャーナルデータを受信して、集中ジャーナル記憶部２１に記憶する。
【００３２】
ここで、ジャーナル送信制御部１２は、未送信の複数件のジャーナルデータがある場合、これらジャーナルデータを、１件ずつ、任意の間隔（送信間隔；送信インターバル）を空けながら送信する、ジャーナル送信機能を有する。そして、未送信のジャーナルデータの件数に応じて送信インターバルの長さを動的に決定／変更する送信間隔設定機能も有する。これらの機能について、詳しくは後にフローチャート図等を参照して説明する。
【００３３】
また、図２（ａ）には、ＡＴＭ１０の概略ハードウェア構成を示す。
尚、ＡＴＭ１０のハードウェア構成は、既存の一般的なものであり、例えば上記特許文献１に図示されている構成を有する。ここでは、本発明に関係する構成のみを概略的に示す。
【００３４】
ＡＴＭ１０は、制御部３１、記憶部３２、通信部３３等を有する。
制御部３１は、ＣＰＵ／ＭＰＵ等の演算処理装置を有し、この演算処理装置は、記憶部３２に予め記憶されているアプリケーションプログラムを読出し・実行することにより、上記ジャーナル送信制御部１２等の処理機能を実現する（例えば後述する図４、図５に示すフローチャート図の処理を実行する）。ジャーナル送信制御部１２等の処理については、後にフローチャート図等を参照して説明する。
【００３５】
記憶部３２は、ハードディスクやフラッシュメモリ等であり、上記アプリケーションプログラムを記憶しており、またジャーナルデータ等の各種データを記憶する。尚、上記送信用ジャーナル記憶部１１は、記憶部３２の一部であると見做してもよい。
【００３６】
通信部３３は、上記ネットワーク１に接続しており、ネットワーク１を介して集中サーバ２０等と通信を行う通信機能部である。
ここで、特に図示・説明しないが、ＡＴＭ１０は既存の一般的な機能も有しており、例えば、任意の事象発生毎にこの事象に係るジャーナルデータを生成して記憶部３２に記憶するジャーナルデータ生成記憶部（不図示）等も有している。尚、上記任意の事象とは、例えば上述した顧客による何らかの取引操作（入金、出金、振込み等）であるが、この例に限らず、例えば保守員による何らかの保守作業、行員による何らかの係員操作等であってもよい。
【００３７】
上記ジャーナル送信制御部１２は、上記ジャーナルデータ生成記憶部（不図示）によって生成されて記憶部３２に記憶されたジャーナルデータのうち未送信のジャーナルデータを、上記の通りネットワーク１を介して集中サーバ２０へ送信することになる。
【００３８】
図２（ｂ）には、集中サーバ２０の概略ハードウェア構成を示す。
尚、集中サーバ２０のハードウェア構成は、既存の一般的なサーバ装置（汎用コンピュータ）の構成であってよく、ここでは簡略化して示すものとする。また、更に、入力装置やディスプレイ等があってもよい。
【００３９】
集中サーバ２０は、制御部４１、記憶部４２、通信部４３等を有する。
制御部４１は、ＣＰＵ／ＭＰＵ等の演算処理装置を有し、演算処理装置は、記憶部４２に予め記憶されているアプリケーションプログラムを読出し・実行することにより、上記ジャーナル集中管理部２２等の処理機能を実現する。
【００４０】
記憶部４２は、ハードディスク等であり、上記アプリケーションプログラムが予め記憶されており、また各ＡＴＭ１０で発生したジャーナルデータを記憶する（つまり、上記集中ジャーナル記憶部２１としての役割も果たす）。尚、上記集中ジャーナル記憶部２１は、記憶部４２の一部であると見做してもよい。
【００４１】
通信部４３は、上記ネットワーク１に接続しており、ネットワーク１を介して各ＡＴＭ１０と通信を行う通信機能部である。
【００４２】
図３に、上記ジャーナルデータ生成・送信に係る状態遷移図である。
図３に示す“ジャーナルデータ生成契機”、“生成処理”、“送信処理”が、ＡＴＭ１０側におけるジャーナルデータ生成・送信に係る状態遷移図である。上記ジャーナル送信制御部１２は、主に図示の送信処理を行うことになる。また、図３に示す“サーバ側処理”が、集中サーバ２０側におけるジャーナルデータ受信・格納に係る状態遷移図である。
【００４３】
図３において、ＡＴＭ１０側において、例えば任意の顧客によって任意の取引が行われる毎に、この取引に係るジャーナルデータが生成される。そして、例えば既に前回のジャーナルデータ送信時から送信インターバル分の時間が経過後であれば（あるいはその日の最初の取引の場合等には）、ジャーナルデータ生成後に直ちに送信処理を開始する。そうでなければ、送信インターバル分の時間が経過するまで、ジャーナルデータをスプールすることになる。
【００４４】
送信処理では、まず、ネットワーク１を介して集中サーバ２０に対して接続リクエストを送信し、集中サーバ２０から接続ＯＫの応答があったならば、上記生成したジャーナルデータをネットワーク１を介して集中サーバ２０へ送信する。尚、その際、ジャーナルデータが暗号化されて記憶されている場合には、これを復号した後、集中サーバ２０との間で決められたセッション鍵を用いてジャーナルデータを暗号化するようにしてもよい。当然、セッション鍵で暗号化したジャーナルデータを集中サーバ２０に送信し、集中サーバ２０側でセッション鍵を用いて復号することになる。
【００４５】
尚、上記の通り、サーバへの接続数には上限があるので、接続数オーバーの状態であれば接続ＯＫの応答は無いことになる（無応答や不図示の接続ＮＧの応答となる）。
集中サーバ２０のジャーナル集中管理部２２は、上記ジャーナルデータの受信処理を行い（例えば上記セッション鍵を用いて、暗号化ジャーナルデータを復号する等）、受信したジャーナルデータを上記記憶部４２（集中ジャーナル記憶部２１）に記憶する。
【００４６】
ＡＴＭ１０側では、上記ジャーナルデータを送信完了後、未だ未送信ジャーナルデータがある場合には、任意の送信インターバル（送信間隔）を空けてから、次の未送信ジャーナルデータの送信処理を開始する。よって、送信インターバルの間は、未送信のジャーナルデータがあっても、送信処理を実行することなく、取引処理を行う等している。そして、送信インターバルの時間経過したら、送信処理を開始する。これは、上記と同様、まず接続リクエストを出すことになる。
【００４７】
ここで、上記送信インターバルの設定時間は、従来では上述したように予め任意に設定される固定的なものである。あるいは、設定変更するにしても、手動等であり、状況に応じて動的に変更するものではなかった。これに対して、本システムでは、各ＡＴＭ１０が自動的に、自装置の送信インターバルの設定時間を、自装置の現在のジャーナルデータ・スプール件数（未送信のジャーナルデータの件数）等に基づいて、動的に決定／変更する。例えば一例としては、ジャーナルデータ・スプール件数が例えば１，２件程度の場合、すなわちジャーナルデータ生成毎に直ちに送信できている場合には、送信インターバルの設定時間を、予め決められているデフォルト値とする。そして、スプール件数が多くなるに従って、送信インターバルの設定時間を短くしていく。勿論、この例に限るものではない。
【００４８】
図３に示すジャーナルデータ１件分の「送信処理」に掛かる時間をＴ１とし、送信インターバル設定時間をＴ２とした場合、例えば仮にスプール件数を１０件とすると、１０回の「送信処理」と９回の送信インターバルに掛かる時間が、全体の処理時間Ｔallとなる。すなわち、１０×Ｔ１＋９×Ｔ２が、スプール件数＝１０件のジャーナルデータ送信に掛かる時間（＝Ｔall）となる。Ｔ１を一定とするならば、Ｔ２が短ければ短いほど、全体の処理時間Ｔallは短くなる。これは、換言すれば、単位時間当たりのジャーナルデータ送信件数は、送信インターバル時間Ｔ２が短ければ短いほど、多くなることになる（送信頻度が高くなる）。
【００４９】
ここで、例えば２台のＡＴＭ１０ａ、ＡＴＭ１０ｂ（不図示）があるものとし、ある時点でのジャーナルデータ・スプール件数が、ＡＴＭ１０ａは１０件、ＡＴＭ１０ｂは２０件であるものとする。本手法では、この様な場合に、例えば一例としては、ＡＴＭ１０ａの全体の処理時間Ｔallと、ＡＴＭ１０ｂの全体の処理時間Ｔallとが、結果的にほぼ同じとなるように、ＡＴＭ１０ａ、１０ｂそれぞれが、自端末の送信インターバルの設定時間を動的に決定することができる。換言すれば、システム全体として各ＡＴＭ１０ａ、１０ｂのジャーナルデータのスプール件数を平準化することができる
【００５０】
従来であれば、ＡＴＭ１０ａがジャーナルデータを１０件送信完了した時点で、ＡＴＭ１０ｂもジャーナルデータを１０件送信完了しており、ＡＴＭ１０ｂには未だ１０件の未送信ジャーナルデータが残っていることになる。これに対して、本手法では、ＡＴＭ１０ａ、１０ｂ間でのデータのスプール件数を平準化できる。また、システム前提として古いデータから順に集中サーバ２０に収集させることが可能となる。
【００５１】
図４、図５に、ＡＴＭ１０におけるジャーナルデータ送信に係る処理フローチャート図を示す。尚、これは、ジャーナル送信制御部１２による処理フローチャート図と見做しても良い。
【００５２】
まず、図４に示す送信用ファイル生成処理について説明する。
まず、上記のように、各ＡＴＭ１０においてジャーナルデータ生成記憶部（不図示）が、顧客によって何らかの取引（入金、出金、振込み等）が行われる毎に、この取引に係るジャーナルデータを生成して、例えば上記記憶部３２に記憶する。尚、このときジャーナルデータを記憶する記憶領域は、上記送信用ジャーナル記憶部１１としての記憶領域とは異なる領域である。そして、ジャーナル送信制御部１２は、例えば直ちに、図４に示す送信用ファイル生成処理を実行する。
【００５３】
図４の処理では、まず、不図示の編集用バッファを初期化する（ステップＳ１１）。
続いて、送信用ジャーナル編集処理を実行する（ステップＳ１２）。この編集処理は、上記記憶部３２に記憶した新規ジャーナルデータを読出して、これを所定の送信フォーマットに従って送信用ジャーナルファイルとして編集用バッファに格納する処理である。尚、所定の送信フォーマットとは、例えば送信元ＩＰアドレスとして自装置のＩＰアドレスが格納され、送信先ＩＰアドレスとして集中サーバ２０のＩＰアドレスが格納されたものである。また、尚、編集用バッファは、例えば制御部３１内（ＣＰＵ内など）にある。
【００５４】
そして、送信用ジャーナルファイル出力処理を実行する（ステップＳ１３）。この出力処理は、上記編集用バッファに格納した送信用ジャーナルファイルを、上記送信用ジャーナル記憶部１１へ出力して記憶する処理である。
【００５５】
ステップＳ１３の処理が成功して送信用ジャーナルファイルが送信用ジャーナル記憶部１１に正常に格納されたならば（ステップＳ１４，ＮＯ）、スプール件数ｍを１加算する（ｍ＝ｍ＋１）（ステップＳ１５）。そして、本処理を正常終了とする。
【００５６】
尚、この例では、送信用ジャーナル記憶部１１に記憶される送信用ジャーナルファイルを、未送信ジャーナルデータと見做してよい（これより、上記の通り、新たに１件格納する毎にスプール件数ｍを１加算する）。そして、送信用ジャーナル記憶部１１に記憶される送信用ジャーナルファイルは、後述する図５の処理によって集中サーバ２０へ送信成功したら、削除する。
【００５７】
尚、ステップＳ１５のスプール件数加算処理は、後述するスプール件数減算／取得処理とは排他である。
一方、ステップＳ１３の処理が失敗した場合には（ステップＳ１４，ＹＥＳ）、ステップＳ１５の処理を行うことなく、本処理を異常終了とする。
【００５８】
尚、送信用ジャーナル記憶部１１は、上記記憶部３２の一部の記憶領域であって、上記新規ジャーナルデータを記憶する記憶領域とは別の記憶領域であると考えても良い。また、尚、送信用ジャーナルファイルは、暗号化したうえで送信用ジャーナル記憶部１１に記憶するようにしてもよい。
【００５９】
上記送信用ジャーナルファイルは、後述する図５の処理によってネットワーク１を介して集中サーバ２０へ送信されるが、もし何らかの理由で送信成功しない状況が続くと、その間に新たな取引がある毎に、上記送信用ジャーナルファイルが新たに生成・記憶されていき、それに伴ってスプール件数ｍが増大していくことになる。
【００６０】
図５（図５Ａ、図５Ｂ）は、ジャーナル送信制御部１２による送信処理のフローチャート図である。
これは、図３に示す“送信処理”のフローチャート図と見做してよく、任意の“送信処理”を実行完了後、図示の送信インターバルＴ２を空けてから、図５の処理が開始され、次の“送信処理”が実行されることになる。
【００６１】
図５Ａにおいて、まず、不図示の送信用バッファを初期化する（ステップＳ２１）。この送信用バッファは、例えば制御部３１内（ＣＰＵ内など）にある。
続いて、送信用ジャーナル記憶部１１に記憶した上記送信用ジャーナルファイルを、送信用バッファへ読み込む（ステップＳ２２）。複数の送信用ジャーナルファイルがある場合には、作成日時を参照する等して、最も古いものを読み込む。
【００６２】
そして、ジャーナルデータ送信処理を実行する（ステップＳ２３）。この送信処理は、例えば図３に示すように、まず最初に接続リクエストを集中サーバ２０へ送信し、“接続ＯＫ”が返信されてきた場合には、上記送信用バッファに読み込んだ送信用ジャーナルファイルを、集中サーバ２０へ送信する。そして、図３には示してないが、集中サーバ２０側でファイル受信・格納成功した場合には、集中サーバ２０からファイル受信・格納成功を示す返信がある。これより、この返信を受信した場合には通信処理成功と判定して（ステップＳ２４，ＹＥＳ）、上記送信した送信用ジャーナルファイルを送信用ジャーナル記憶部１１から削除すると共に、スプール件数ｍを−１減算する（ｍ＝ｍ−１）（ステップＳ２５）。そして、ステップＳ２６の処理へ移行する。
【００６３】
尚、図３には示していないが、上記接続処理（接続リクエスト送信、“接続ＯＫ”返信）の際に集中サーバ２０との間でセッション鍵を決めた場合には、このセッション鍵を用いて送信用ジャーナルファイルを暗号化したうえで、これを集中サーバ２０へ送信するようにしてもよい。また、送信用ジャーナルファイルが既に自装置内部の暗号鍵で暗号化されている場合には、これを復号化したうえで、上記セッション鍵で暗号化するようにしてもよい。
【００６４】
また、上記ステップＳ２３の処理に関して、例えば上記接続リクエストに対して“接続ＯＫ”が返信されてこなかった場合等には、送信処理失敗と判定する（ステップＳ２４，ＮＯ）。送信処理失敗の場合、リトライ処理を行う。但し、リトライには上限があり、図示の例では５回を上限とし、５回リトライしてもファイル送信成功しなかった場合には、ステップＳ２５の処理を行うことなく、ステップＳ２６の処理へ移行する。この場合、今回の送信用ジャーナルファイル送信は失敗したものとし、任意の送信インターバルを空けた後、再び図５Ａの処理を開始することで、再度ファイル送信を試みることになる。
【００６５】
リトライ処理は、例えば接続リクエストに対して“接続ＯＫ”が返信されてこなかった場合等には（あるいは不図示の“接続ＮＧ”が返信されてきた場合等）、所定の送信リトライ間隔を空けてから、再び接続リクエスト送信を行う。尚、この送信リトライ間隔は、図３に示すように、送信インターバルに比べると、非常に短いものとなる。
【００６６】
ステップＳ２６以降では、現在のスプール件数ｍに基づく送信インターバル調整処理を行う。まず、ステップＳ２６において、現在のスプール件数ｍを取得する。
そして、図５Ｂにおいて、このスプール件数ｍを、予め決められている所定の閾値と比較・判定し、この比較・判定結果に応じて、送信インターバルの設定値を決める（ステップＳ２８，Ｓ２９，Ｓ３０，Ｓ３１，Ｓ３２，Ｓ３３）。
【００６７】
図示の例では、３つの閾値Ｐ１，Ｐ２，Ｐ３が予め決められており、Ｐ１＞Ｐ２＞Ｐ３の関係にある。つまり、３つの閾値のうち、閾値Ｐ１が最大値、閾値Ｐ３が最小値である。また、各閾値Ｐ１、Ｐ２、Ｐ３に対応する送信インターバルの設定候補時間Ｑ１，Ｑ２，Ｑ３が、予め決められている。これは、“Ｑ１＜Ｑ２＜Ｑ３”とすることを条件として、この条件を満たせば任意に決めてよいものとする。
【００６８】
例えば、一例としては、Ｐ１＝３００（件）、Ｐ２＝２００（件）、Ｐ３＝１００（件）等としてもよい。あるいは、他の例としては、Ｐ１＝３０（件）、Ｐ２＝１０（件）、Ｐ３＝３（件）等としてもよい。また、一例としては、例えば、Ｑ１＝２（秒）、Ｑ２＝５秒、Ｑ３＝１０秒等としてもよい。勿論、これらの例に限るものではなく、システム開発者等が任意に決めてよいものである。
【００６９】
まず、最大閾値であるＰ１と現在のスプール件数ｍとを比較し、“スプール件数ｍ＞閾値Ｐ１”であるか否かを判定する（ステップＳ２８）。そして、スプール件数ｍが閾値Ｐ１よりも大きい場合には（ステップＳ２８，ＹＥＳ）、送信インターバルの設定時間をＱ１とする（ステップＳ２９）。つまり、スプール件数が非常に多い場合には、送信インターバルを最も短くする。これによって、単位時間当たりのジャーナルデータ送信件数を増大させることができる。
【００７０】
“スプール件数ｍ≦閾値Ｐ１”である場合には（ステップＳ２８，ＮＯ）、続いて、“スプール件数ｍ＞閾値Ｐ２”であるか否かを判定する（ステップＳ３０）。当該ステップＳ３０の判定がＹＥＳの場合、すなわち、スプール件数ｍが「Ｐ２＜ｍ≦Ｐ１」の範囲内である場合には、送信インターバルの設定時間をＱ２とする（ステップＳ３１）。
【００７１】
“スプール件数ｍ≦閾値Ｐ２”である場合には（ステップＳ３０，ＮＯ）、続いて、スプール件数ｍ＞閾値Ｐ３”であるか否かを判定する（ステップＳ３２）。当該ステップＳ３２の判定がＹＥＳの場合、すなわち、スプール件数ｍが「Ｐ３＜ｍ≦Ｐ２」の範囲内である場合には、送信インターバルの設定時間をＱ３とする（ステップＳ３３）。
【００７２】
尚、例えば送信インターバルのデフォルト値を、設定候補値Ｑ３とするようにしてもよい。この場合、スプール件数ｍが比較的少ない状況では送信インターバルはデフォルト値に設定され、スプール件数ｍが大きくなるに従って、送信インターバルをデフォルト値よりも短くしていくことになる。
【００７３】
また、上記デフォルト値＝設定候補値Ｑ３とする例において、更に、Ｑ４＞Ｑ３となる設定候補値Ｑ４を設けると共に、ステップＳ３２の判定がＮＯとなった場合には送信インターバルをＱ４に設定するようにしてもよい。つまり、デフォルト値を通常の送信インターバルと見做すならば、送信インターバルを通常よりも短くする場合に限らず、通常よりも長くする場合も有り得るようにしてもよい。尚、「通常」とは、例えば従来における送信インターバルの設定値等（開発者等が、適切と考えて設定した固定的な値）である。
【００７４】
一方、図５Ｂに示す例では、ステップＳ３２の判定がＮＯの場合には、何も処理が行われないが、これは送信インターバルを現状（Ｑ３）のままとすることを意味する。例えば、スプール件数ｍが比較的少ない状況であるために送信インターバル＝Ｑ３である状態から、スプール件数ｍが増大していき閾値Ｐ３を越えた場合、送信インターバル＝Ｑ３の状態が継続するが、更にスプール件数ｍが増大していき閾値Ｐ２を越えた場合、送信インターバル＝Ｑ２へと設定変更される。その後、スプール件数ｍが減少に転じ、閾値Ｐ２以下になると送信インターバル＝Ｑ３へと設定変更され、更に閾値Ｐ３以下になると送信インターバル＝Ｑ３の状態が継続することになる。
【００７５】
尚、上記閾値を用いる処理は、一例であり、この例に限らない。基本的に、未送信のジャーナルデータの件数ｍ（スプール件数ｍ）が多いほど送信間隔（送信インターバル）が短くなるように、送信間隔の長さを動的に決定するものであれば何でもよい。例えば送信インターバルの基本値をＲとし、“送信インターバル＝Ｒ／ｍ”によって送信インターバルを算出するようにしてもよい。この場合、算出される送信インターバルは、スプール件数ｍが１件であれば、基本値Ｒのままとなり、２件ではＲ／２、３件ではＲ／３というように、スプール件数ｍの増加と反比例するように送信インターバルは短くなっていくことになる。
【００７６】
また、尚、上記設定候補値Ｑ１，Ｑ２等の値は任意に決めてよいし、送信インターバルの算出式も上記の例に限らず自由に作成してよいが、表側の処理への影響を考慮して決定／作成することが望ましい。表側の処理とは、例えば上述した顧客による取引に係る処理である。そもそも、送信インターバルを設ける理由は、複数のジャーナルデータの送信処理を連続して実行すると、ＣＰＵの処理負荷が増大し、それが表側の処理に影響して、取引に時間が掛かるようになる可能性がある為である。よって、この点を考慮して、送信インターバルを短くするにしても、取引に多大な悪影響（時間が掛かり過ぎる等）を与えない程度にすることが望ましい。
【００７７】
何れにしても、上記のように、個々のＡＴＭ１０毎に、自装置のスプール件数ｍに基づいて送信間隔の長さを決定するものであって、基本的に、スプール件数ｍが多いほど送信間隔が短くなるようにすることによって、システム全体として各ＡＴＭ１０のジャーナルデータのスプール件数を平準化することができる。
【００７８】
例えば、仮に２台のＡＴＭ１０（ＡＴＭ１０ａ、ＡＴＭ１０ｂと記すものとする）があるものとし、スプール件数ｍがＡＴＭ１０ａは１０件、ＡＴＭ１０ｂは２０件であるものとする。この例の場合、最初は、ＡＴＭ１０ｂはＡＴＭ１０ａの２倍のスプール件数を持つことになる。しかし、上記処理により送信間隔は、ＡＴＭ１０ｂがＡＴＭ１０ａよりも短くなることが期待できる。例えば、ＡＴＭ１０ｂがＡＴＭ１０ａの２倍のペースでジャーナルデータを集中サーバ２０へ送信することになった場合、ＡＴＭ１０ａのスプール件数ｍが５件になったとき、ＡＴＭ１０ｂのスプール件数ｍは１０件となっており、両者の差は縮まっている。更に、その後、両者の差は更に縮まっていくことになる。このように、システム全体として各ＡＴＭ１０のジャーナルデータのスプール件数を平準化することが可能となる。
【００７９】
また、例えば、集中サーバ２０側の通信障害により、上記ＡＴＭ１０ａとＡＴＭ１０ｂの両方が同じ時間帯に、ジャーナルデータ送信できずにスプール件数が増えていったものとする。そして、その間、ＡＴＭ１０ｂにおいては、ＡＴＭ１０ａの２倍のペースで取引が行われ、その結果、上記のようにスプール件数ｍがＡＴＭ１０ａの２倍になったとする。ここで、既に述べたように各ＡＴＭ１０は、自装置が保持する複数の未送信ジャーナルデータを、古いデータから順に送信する。
【００８０】
仮に、ＡＴＭ１０ａの未送信ジャーナルデータの生成日時が、古いものから順に、１０：００、１０：０２、１０：０４・・・というように２分毎であり、ＡＴＭ１０ｂの未送信ジャーナルデータの生成日時が、古いものから順に、１０：００、１０：０１、１０：０２、１０:０３・・・というように１分毎であるものとする。そして、上記“２倍のペースで送信”となった場合には、ＡＴＭ１０ａが１０：００のデータを送信するときには、ＡＴＭ１０ｂは１０：００と１０：０１のデータを送信することになる。同様に、ＡＴＭ１０ａが１０：０２のデータを送信するときには、ＡＴＭ１０ｂは１０：０２と１０：０３のデータを送信することになる。
【００８１】
よって、集中サーバ２０側から見ると、複数のＡＴＭ１０ａ、１０ｂからそれぞれ別個にジャーナルデータが送られてくるにも係らず、全体としてほぼ古いデータから順に受信して格納することになる（但し、厳密に古いデータ順になるとは限らず、多少前後する場合もある）。
【００８２】
あるいは、上記の通り、集中サーバ２０への接続数には上限がある為、集中サーバ２０に接続できない場合がある（接続レスポンスに対して接続数オーバーにより接続ＯＫの返信がないことになる）。この場合、何度かリトライを繰り返すが、それでも接続できない場合、送信インターバルを空けてから、再び接続（次回の接続）を試みることになる。
【００８３】
従来のように送信インターバルの長さが固定的で（動的に変更できない）且つ各ＡＴＭで同じ長さとした場合には、今回サーバ装置に接続していた他のＡＴＭは、次回も同じタイミングでサーバ装置に接続する可能性が高くなる。勿論、これは、次回だけでなく、次々回もその後も、略同様となる。この為、いつまでたってもサーバ装置へ接続できないＡＴＭが現れる可能性がある。このようなＡＴＭでは、スプール件数ｍが増大していくことになる。
【００８４】
これに対して、本手法では上記のようにスプール件数ｍが増えれば送信インターバルの長さを動的に変更するのであり、これは送信頻度を高くするだけでなく、送信タイミングをずらすことになる。よって、上記他のＡＴＭとは異なるタイミングで集中サーバ２０への接続を試みることになり、接続ＯＫとなる可能性が高まる。また、この様な状況では、このＡＴＭは、上記他のＡＴＭよりもスプール件数が多いことになるが、送信頻度が高くなることで他のＡＴＭよりも早いペースでジャーナルデータ送信が行える。つまり、この場合も、上記のように、システム全体として各ＡＴＭ１０のジャーナルデータのスプール件数を平準化することができる。
【００８５】
あるいは、この様な極端な状況にはならないにしても、サーバ接続に成功する確率についてＡＴＭ間で偏りが生じる場合が有り得る（成功確率が低いＡＴＭもあれば、成功確率が高いＡＴＭもあれば、成功確率が平均的なＡＴＭもある等）。これに起因して、各ＡＴＭのスプール件数（未送信のジャーナルデータの件数）についてＡＴＭ間で偏りが生じる場合が有り得る（スプール件数が多いＡＴＭもあれば、少ないＡＴＭもあれば、平均的なＡＴＭもある等）。この様な場合も、本手法によれば、各ＡＴＭ毎の上記送信間隔の動的変更により、サーバ接続の成功確率を変えたり、送信頻度を変えることが可能となり、上記のように、システム全体として各ＡＴＭ１０のジャーナルデータのスプール件数を平準化することが可能となる。
【００８６】
尚、上述したスプール件数に基づく送信インターバル調整処理は、図５Ｂのように１件のジャーナルデータの送信処理（成功、失敗は問わない）を行う毎に実行する例に限らず、任意のときに実行して構わない。
【００８７】
上述したスプール件数に基づく送信インターバル調整処理を実行したら、最後に、上記ステップＳ２４における通信処理の成功／失敗に応じて、正常終了または異常終了となる。すなわち、通信処理の成功していた場合には（ステップＳ３４，ＮＯ）正常終了となり、通信処理の失敗していた場合には（ステップＳ３４，ＹＥＳ）異常終了となる。
【００８８】
尚、集中サーバ２０側の処理は、従来と同じであってよい。従って、ここでは、フローチャート図などを示すことなく、簡単に説明するものとする。集中サーバ２０のジャーナル集中管理部２２は、任意のＡＴＭ１０からの上記接続リクエストを受信する毎に、現在の自装置への接続数が上限に達している場合には接続ＮＧを返信し（あるいは何も返信しない）、未だ上限に達していない場合には接続ＯＫを返信する。接続ＯＫの場合、ＡＴＭ１０から送られてくる上記送信用ジャーナルファイルを受信すると、これを集中ジャーナル記憶部２１に記憶する。送信用ジャーナルファイルがセッション鍵で暗号化されている場合には、復号してから集中ジャーナル記憶部２１に記憶する。
【００８９】
また、尚、送信インターバルの調整処理は、上述した例に限らない。例えば、スプール件数に基づくだけでなく、更に、ネットワーク１上の通信トラフィック量にも基づいて、送信インターバルの長さを調整するようにしてもよい。通信トラフィック量は、例えば、通信レスポンス時間を用いることで判断する。通信レスポンス時間とは、例えば、接続リクエスト送信時から返信（接続ＯＫ／ＮＧ）受信までの時間であるが、この例に限らない。
【００９０】
基本的には、通信レスポンス時間が短い（通信トラフィック量が少ない）場合は送信インターバルを短くし、通信レスポンス時間が長い（通信トラフィック量が多い）場合は送信インターバルを長くする。つまり、回線が混雑している場合には、混雑回避の為、ジャーナルデータ送信頻度を低くする。そして、回線が空いているときに、ジャーナルデータ送信頻度を高くして、多くのジャーナルデータを送信するようにする。具体的には、一例としては、上記ステップＳ２８〜Ｓ３３の処理と略同様にして、１または複数の閾値と各閾値に応じた設定候補値を予め記憶しておき、通信レスポンス時間を各閾値と比較することにより、送信インターバルを決定／変更する。
【００９１】
上述したように、本例のＡＴＭシステム、そのＡＴＭ１０等では、個々のＡＴＭ１０毎に、自装置のジャーナルデータのスプール件数に基づいて送信インターバルを動的に調整する。これによって、システム全体として各ＡＴＭ１０のジャーナルデータのスプール件数を平準化することができる。また、システム全体として古いジャーナルデータから順に集中サーバ２０に格納させることが可能となる。更に、状況によっては不要な待ち時間が減ることが期待でき、回線の有効利用が可能となる。更に、状況によっては回線の帯域占有率が下がることが期待でき、他の通信への影響を抑えることが可能となる。尚、従来の手動による送信インターバル調整に比べれば、作業負担が軽減されることは言うまでもない。
【００９２】
最後に、図６に、ジャーナルデータのデータ項目の一例を示しておく。
図示の例では、ジャーナルデータの内容は、装置銀行番号、装置支店番号、装置枝番、装置機械番号、装置号機、取引日付、取引種別、銀行番号、支店番号、口座番号、取引金額、おつり金額、元帳状態、状態コード（ＡＴＭの状態を表すコード）、処理／エラーコード、データ区分（「取引処理」、「係員処理」等）、印字データ等である。取引が“振込み”である場合には、振込先銀行番号、振込先支店番号、振込先口座番号なども加わることになる。
【符号の説明】
【００９３】
１０  ＡＴＭ
１１  送信用ジャーナル記憶部
１２  ジャーナル送信制御部
２０  集中サーバ
２１  集中ジャーナル記憶部
２２  ジャーナル集中管理部
３１  制御部
３２  記憶部
３３  通信部
４１  制御部
４２  記憶部
４３  通信部
【図１】
2012141669.tif 000003
【図２】
2012141669.tif 000004
【図３】
2012141669.tif 000005
【図４】
2012141669.tif 000006
【図５Ａ】
2012141669.tif 000007
【図５Ｂ】
2012141669.tif 000008
【図６】
2012141669.tif 000009