JP6663497B2 - 自動取引装置、自動取引システム及び非一時的記録媒体 - Google Patents

Description

本発明は、自動取引装置、自動取引システム及び非一時的記録媒体に関する。

ＡＴＭ（Automated Teller Machine）などの現金自動取引装置は、銀行の店舗だけでなく、デパート、コンビニエンスストアまたは駅構内などに幅広く設置されている。自動取引装置は、現金や帳票など多くの種類の取引媒体を取扱う装置であり、自動取引装置の設計に際しては、紙幣部などの自動取引装置を構成する各種の処理部を制御する特定のモジュールを専業メーカから購入することで設計の効率化を行うことが多い。

一般的に、自動取引装置には、顧客との入出金紙幣を出し入れする紙幣部が搭載されている。特に、紙幣部は稼働する地域の特性や紙幣の種類・状態・運用など稼働にかかる機能や性能の実現にさまざまな技術が導入されている。また、それらを使いこなすことで従来よりも高い性能を発揮する自動取引装置を実現するため、モジュールを購入する場合においても自動取引装置の設計に高い技術が必要となる。

自動取引装置に内蔵される上記モジュールは、一般的には、制御部と通信回線やＵＳＢ（Universal Serial Bus）等のＩＯ（Input Output）インタフェースで接続される。制御部は、モジュールへの動作を指示するためのコマンド電文を送信し、モジュールが、その指示に従った動作を行い、その動作結果をレスポンス電文で制御部に返送する（特許文献１）。

特開２０１４−７８２７３号公報

上述のようなモジュールは、複雑かつ多数の機能を有し、その機能や性能を引き出すには、コマンド電文の順序や、レスポンス電文による情報判定と次の動作を適切に決定する技術を必要とする。そのため、モジュールの機能を最大限に引き出すにはコマンド電文やレスポンス電文の仕様を詳細に設計しなければならず、その設計負荷が高くなってしまうという課題がある。上記特許文献１では、上記課題については考慮されておらず、これらの課題を解決するための技術が求められていた。

本発明にかかる自動取引装置は、媒体を用いて取引を実行する処理部を有し、取引の指示に基づいて、取引に使用する情報を処理部から取得する第１のコマンドを生成する第１のコマンド提供部と、第１のコマンドに基づき処理部の実行する処理を指定し、第１のコマンドとは異なるコマンドに変換される第２のコマンドを生成する第２のコマンド提供部とを含む制御部を有するものとして構成される。

本発明の一実施の形態によれば、モジュールの機能を最大限に引き出すためのコマンド電文やレスポンス電文の仕様を簡素化することができ、設計負荷を低減できる。

ＡＴＭの外観斜視図である。 ＡＴＭの機能的な構成を示すブロック図である。 ＡＴＭ内の一般的な従来型のソフトウェア構成図である。 図３に示したソフトウェア構成において、制御部内の各部およびモジュールにおけるコマンド電文やレスポンス電文の流れを示す図である。 図４に示したソフトウェア構成においてファンクションライブラリを配置したＡＴＭ内のソフトウェアの構成図である。 図５に示したモジュールがサブモジュールを含む場合のソフトウェアの構成図である。 紙幣部接続処理フローの例を示す図である。 構成情報の例を示す図である。 ライセンス許可情報の例を示す図である。 ファンクションライブラリ本体機能の基本処理フローの例を示す図である。 処理内容テーブルの例を示す図である。 コマンド電文のフォーマットの例を示す図である。 レスポンス電文のフォーマットの例を示す図である。 リザーブに投入口繰出し状況の判定結果を含めたレスポンス電文の例を示す図である。 レスポンス電文に付加情報を含めて返送した場合の処理内容テーブルの例を示す図である。 付加情報を含めた場合のファンクションライブラリ本体機能の基本処理フローの例を示す図である。 ライセンスレベルを含めて定義したライセンス許可情報の例を示す図である。 図１７に示したライセンス許可情報を用いた場合の処理内容テーブルの例を示す図である。 図１７に示したライセンス許可情報を用いた場合のファンクションライブラリ本体機能の基本処理フローの例を示す図である。 ファンクションライブラリとモジュールである紙幣部との間のコマンド電文のフォーマットの例を示す図である。 標準的なエラーコードを改変や拡大した場合のファンクションライブラリ本体機能の基本処理フローの例を示す図である。 エラーコード変換テーブルの例を示す図である。 参照先管理テーブルの例を示す図である。 第一のコマレス管理テーブルの例を示す図である。 第二のコマレス管理テーブルの例を示す図である。 上位装置を含むシステムの構成を示す図である。 ファンクションライブラリ管理情報の例を示す図である。 部品毎のログ情報の例を示す図である。 分析ログ情報テーブルの例を示す図である。 交換情報管理テーブルの例を示す図である。 統計データ生成処理のフローの例を示す図である。

以下、本発明の一実施形態を、図面を参照して詳細に説明する。
以下では、自動取引装置を構成する各種の処理部を制御するモジュールのうち、紙幣処理装置である紙幣部を例に説明しているが、例えば、カード・明細票処理装置、通帳処理装置あるいは硬貨処理装置等の自動取引装置が一般的に備えている各種装置を制御する様々なモジュールについても同様に適用することができる。また、以下では、本発明にかかる取引媒体取扱装置の一例として、自動取引装置について記載しているが、ソータ等の紙幣の仕分装置、テラーマシーン等のテラーが扱う装置、中央銀行で利用される装置などにも適用できる。なお、本発明はこれらの実施の形態に限定されるものではない。

本実施例では、モジュール提供元が、制御部側で機能を実現するソフトウェアライブラリを設計し、モジュール提供先へモジュールと合わせて提供することで、適切な使いこなし技術を実現する手段を提案する。本提案によれば、モジュール提供元においては、モジュール提供先へのモジュール使いこなし技術の開示を最小限にとどめ、制御部が持つストレージを活用し追加コストなく運用や保守にかかる多くの機能実現が可能となる。その結果、モジュールの価値を高めることが可能となる。

また、モジュール提供先においては、複雑なモジュール使いこなし技術のすべてを理解する必要はなく、自動取引装置に必要な最小限の理解で充分になるとともに、モジュールを制御する最適なシステム設計ができる。したがって、制御部の資源を最大限有効活用しつつ性能を発揮することができる。さらに、保守等の設計優先度が低くなりがちな機能をモジュール提供元から供給を受けることで設計工数を削減し、短期間かつ高品質に自動取引装置の設計が可能となる。また、制御部に各種変換情報を有することにより、複数種類のモジュール又は複数の銀行で機能を実現した場合であっても、制御部の設計変更の負担を抑制することが可能となる。

図１は、自動取引装置（以下、ＡＴＭと呼ぶ。）１０の外観斜視図である。ＡＴＭ１０は、金融機関等に設置され、顧客の操作によって現金の預入や引出等の取引を行い、顧客の要求する種々の取引を自動的に実行する装置である。図１に示すように、ＡＴＭ１０は、その内部に、紙幣部１１と、カード・明細票部１２と、通帳部１３と、硬貨部１４と、操作部１５と、係員操作部１６と、を含んで構成されている。

紙幣部１１は、紙幣の金種や真偽を判別し、利用者が投入した紙幣を計数して収納したり、操作部１５から入力された入金金額等に応じて、紙幣収納庫に収納されている紙幣を繰出して入出金口に排出する等、紙幣に関する処理を行う。

カード・明細票部１２は、利用者がＡＴＭ１０との間で取引を行うためのキャッシュカードの受け入れ、カードに記憶された情報の取得、排出、取引記録を印字した明細票を利用者に排出する等、カードや明細票に関する処理を行う。

通帳部１３は、利用者がＡＴＭ１０との間で取引を行うための通帳の受け入れ、通帳に記録された情報の取得、排出、取引記録を印字やページめくり等、通帳に関する処理を行う。

硬貨部１４は、硬貨の金種や真偽を判別し、利用者が投入した硬貨を計数して収納したり、操作部１５から入力された入金金額等に応じて、硬貨収納庫に収納されている硬貨を繰出して入出金口に排出する等、硬貨に関する処理を行う。

すなわち、紙幣部１１、カード・明細票部１２、通帳部１３、及び硬貨部１４は、それぞれ対象媒体から、取引に利用される情報（例えば、取引金額、口座情報）を取得する処理である取引処理を行う。また、取引処理には、取引に利用される情報を取得するために、対象媒体を搬送する媒体搬送処理等の動作処理を含んでもよい。

操作部１５は、利用者から、取引の種別、入出金金額等、取引に関する様々な情報の入力や指定を受け付ける。

係員操作部１６は、運用中に発生した障害の情報や復旧操作情報の案内表示や、保守運用で種々の操作画面情報の表示を行う。

図２は、ＡＴＭ１０の機能的な構成を示すブロック図である。図２に示すように、ＡＴＭ１０は、紙幣部１１、カード・明細票部１２、通帳部１３、硬貨部１４、操作部１５が、それぞれ制御部２０に接続されている。また、制御部２０は、ホストコンピュータ等の外部装置に接続するための通信制御部１７に接続されている。以下では、紙幣部１１を例に、上記各部の具体的な構成を説明する。

紙幣部１１は、入出金部１１２と、識別部１１３と、一時保留部１１４と、搬送部１１５と、カセット１１６とを有し、これらが紙幣制御部１１１に接続されている。図２に示すように、紙幣部１１は、ＡＴＭ１０全体およびＡＴＭ１０を構成する各部の動作を制御する制御部２０からの指示を受け、紙幣の繰出し、搬送等を制御するとともに動作結果を制御部２０に報告する紙幣制御部１１１を核として、紙幣の投入、抜き取りを行なう入出金部１１２や、紙幣の金種識別を行なう識別部１１３、取引操作者が投入した紙幣を一時的に保留する一時保留部１１４、それぞれの部位を接続し紙幣を搬送する搬送部１１５、紙幣を収納する着脱可能な複数のカセット１１６から構成されている。なお、紙幣部１１によっては、一時保留部１１４がないことや、入出金部１１２が入金と出金が完全に別の場所となることや、入出金部１１２の数が異なることもあり、紙幣部１１の構成は、図２に限らない。

図３は、ＡＴＭ１０内の一般的なソフトウェア構成図である。図３に示すように、制御部２０には、ＡＴＭ１０の機能や上記各部を管理するための基本的なソフトウェアであるオペレーティングシステム（ＯＳ）２０１と、ＡＴＭ１０や上記各部の動作に必要な様々な情報を記憶するストレージ２０２と、ＡＴＭ１０の取引操作を受け付けるソフトウェアである業務アプリケーション（ＡＰ）２０３と、業務アプリケーション２０３と紙幣部１１との間で送受信され、紙幣部１１等の各部が実行可能なコマンド電文やレスポンス電文を生成する電文提供モジュール（ソフトウェア）であるサービスプロバイダ（ＳＰ）２０４と、上記各部のそれぞれに対応する通信制御部２０５（紙幣部通信制御部２０５１、カード・明細票部２０５２、通帳部通信制御部２０５３、硬貨部通信制御部２０５４）と、を有している。

制御部２０内で動作するオペレーティングシステム２０１上では、上記各部に対応する各種媒体を取扱うモジュール（紙幣部１１、カード・明細票部１２、通帳部１３、硬貨部１４のそれぞれで実行されるモジュール）と通信制御を行うモジュール用の通信制御部（紙幣部通信制御部２０５１、カード・明細票部２０５２、通帳部通信制御部２０５３、硬貨部通信制御部２０５４）、各モジュールと通信する電文の生成や編集、解析を行うサービスプロバイダ２０４、各モジュールの動作を組み合わせて取引動作を実現する業務アプリケーション２０３が動作する。その他、ストレージ２０２には、各動作に必要な情報やプログラム、動作結果記録などが記憶される。ここで、サービスプロバイダ２０４と業務アプリケーション２０３が明確に区分けされず、一体化している場合もある。

制御部２０は、ハードウェアとしては、例えば、ＣＰＵ（Central Processing Unit）及びメモリから構成され、ＡＴＭ１０を構成する上記各部の機能を実現するためのプログラムをストレージ２０２に記憶している。制御部２０は、例えば、ＡＴＭ１０の電源がＯＮされたタイミングで、上記ストレージ２０２からプログラムを不図示のメモリに読み出して実行することにより、上記機能を実現する。

なお、上記プログラムは、インストール可能な形式又は実行可能な形式のファイルでＵＳＢ（Universal Serial Bus）メモリ等のコンピュータで読み取り可能な記録媒体に記録されて提供したり、インターネット等のネットワークに接続された他のコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより、ストレージ２０２に提供または配布するように構成しても良い。

図４は、図３に示したソフトウェア構成において、制御部内の各部およびモジュールにおけるコマンド電文やレスポンス電文の流れを示す図である。図４では、紙幣部１１が実行するモジュールの場合について示している。なお、以降では、図３に示すモジュールの通信制御部の図示を省略するが、各通信制御部は、モジュールに対し通信制御を行うものとある。

図４に示すように、制御部２０では、業務アプリケーション２０３から取引に関する指示を受けると、サービスプロバイダ２０４が、その指示毎に、紙幣部１１に対するコマンド電文Ｃ１を生成、編集して出力する。コマンド電文Ｃ１としては、例えば、入金処理などの取引を実行する指示を含むコマンドがある。すなわち、サービスプロバイダ２０４は、紙幣部１１が実施可能なコマンドを生成する。ここで、紙幣部１１が実施可能なコマンドとは、紙幣部１１が理解できるコマンドを意味し、当該コマンドの情報に従い紙幣部が処理又は動作をするコマンドであってよい。すなわち、コマンドに含まれる情報を変更しなくとも紙幣部１１が動作する（紙幣部１１を直接動作させることができる）コマンドは、実施可能なコマンドに含まれる。なお、制御部２０と紙幣部１１との間の通信のために、コマンドを一時的に変更した場合であっても、制御部２０と紙幣部１１とで利用されるコマンドに含まれる情報が同一の場合は、実施可能なコマンドに含まれる。一方、サービスプロバイダ２０４や、ファンクションライブラリ２０６でコマンドに含まれる情報（特にコマンドコード）を変換した場合は、実施可能なコマンドに含まれなくともよい。

紙幣部１１は、サービスプロバイダ２０４からコマンド電文Ｃ１を受信すると、そのコマンドに従って処理を実行し、その結果をレスポンス電文Ｒ１としてサービスプロバイダ２０４に返す。レスポンス電文Ｒ１としては、例えば、入金取引などの取引で各金種のカセットに収納された紙幣の枚数、偽券と判別された紙幣の枚数、取引の処理が正常終了したか否かを示す取引の処理結果などを含むレスポンスがある。

サービスプロバイダ２０４は、上記レスポンス電文Ｒ１に応じて、業務アプリケーション２０３にコマンドＣ１に対応するレスポンスを送信する。業務アプリケーション２０３は、レスポンスに基づきコマンドＣ１の結果を外部へ通知する。

図３、４に示したソフトウェア構成では、業務アプリケーション２０３は、銀行側で定められた仕様で提供され、その業務アプリケーション２０３の仕様に合致するように、モジュール提供先でサービスプロバイダ２０４を設計する必要があった。この際、モジュール提供先では、モジュール提供元から提供されるモジュールの機能を最大限に引き出して設計することが求められる。しかし、モジュール提供先では、モジュール提供元から提供されるモジュールの仕様や複雑なコマンド電文やレスポンス電文の構造を必ずしも適切に理解することができないまま、サービスプロバイダ２０４の設計を行っていた。したがって、モジュール提供元が意図したとおりにモジュールの機能が発揮されているとはいえない場合があった。

そこで、以下に示すように、本実施例では、サービスプロバイダ２０４からの簡易な指示に従ってモジュールの詳細な機能を実現することができるソフトウェアライブラリをモジュール提供側で設計することにより、モジュール提供先におけるサービスプロバイダ２０４の設計負担を軽減しつつ、モジュール提供元における技術流出の危険性を低減している。

図５は、図４に示したソフトウェア構成において、モジュール提供元により設計されるソフトウェアライブラリであるファンクションライブラリ（ＦＬ）２０６を配置したＡＴＭ１０内のソフトウェアの構成図である。

ＡＴＭ１０は、ファンクションライブラリ２０６を備えることにより、従来から実施している取引処理（基本処理ともいう）に加え、拡張処理を容易に実施することが可能となる。取引処理は、取引で利用される情報を取得する処理であり、例えば、入金取引又は出金取引などであり、外部から指定された口座に入金する金額又は外部から指定された口座から出金する金額を紙幣部１１が計数する処理などがある。また、外部から投入された現金やカード等の媒体から、取引に利用される情報（例えば、取引金額や口座情報等をいう。）を取得する処理も含まれる。

一方、拡張処理は、取引処理とは異なる処理であり、取引では利用しない情報を取得する処理、取引処理又は拡張処理により取得した情報に基づき、ファンクションライブラリが実施する又は紙幣部１１に実施させる処理がある。より具体的には、紙幣部１１から状態情報を取得する取得処理と、紙幣部１１を動作させる又は紙幣部１１に設定をさせる動作処理と、取得処理により取得した情報に基づきファンクションライブラリ２０６が分析を行う分析処理を含む。取得処理は、例えば、紙幣部１１から状態情報（例えば、収納庫毎又は金種などの種別毎に収納されている紙幣の枚数、紙幣部の設定情報、紙幣部の障害情報、ログ情報（紙幣部１１の稼働状態を示す稼働ログ、取引処理で紙幣から取得した紙幣画像や記番号などの紙幣ログ））を取得する処理である。また、動作処理は、例えば、取得処理により取得した状態情報に基づき又は外部からの指示により紙幣部１１に取引処理とは異なる動作（例えば、紙幣部１１の収納している紙幣の計数又は精査など）をさせる又は紙幣部１１の設定を変更させる処理である。また、分析処理は、紙幣部１１の各部品の稼働ログに基づき、部品の障害発生の予兆検知を行う処理である。

続いて、ファンクションライブラリ２０６と、サービスプロバイダ２０４に関して説明する。ファンクションライブラリ２０６は、サービスプロバイダ２０４を経由して外部から受信したコマンドに基づき、紙幣部１１等の各部が実行可能なコマンド電文を送信し、紙幣部１１等の各部から受信したレスポンス電文をサービスプロバイダ２０４又は業務アプリケーション２０３が処理できるレスポンス電文として送信する電文提供モジュールであってよい。また、サービスプロバイダ２０４は、複数の業務アプリケーション２０３からの指示に基づき共通して実施される共通処理又は共通して利用されるデータの管理を実施する共通処理部を実現するソフトウェア、即ちミドルウェアであってよい。なお、図３、図４でも説明したように、業務アプリケーション２０３は、サービスプロバイダ２０４に取引指示を行うが、サービスプロバイダ２０４と一体化されている場合もある。そのため、以下では、サービスプロバイダ２０４、ファンクションライブラリ２０６、紙幣部１１間での処理について説明する。

次に、図５に示す処理の概要を説明する。サービスプロバイダ２０４は、紙幣部１１に対する動作指示をファンクションライブラリ２０６に発行し、ファンクションライブラリ２０６はその動作指示を受け、紙幣部１１への適切な動作指示に変換し紙幣部１１へ指示する。なお、図４と同様に本図では通信制御部の図示を省略するが、通信制御部が、モジュールに対し通信制御を行っている。

紙幣部１１は指示に従って動作を行い、その結果を、ファンクションライブラリ２０６に返送する。ファンクションライブラリ２０６は動作結果に従い、動作記録の収集など必要に応じて紙幣部へ追加動作を指示するなどを行ったり、あるいは動作情報の一部をストレージ２０２に格納するなど使いこなし技術に従った最適動作を行った上で、サービスプロバイダ２０４からの指示に対する動作結果をサービスプロバイダ２０４に返送する。ファンクションライブラリ２０６は、サービスプロバイダ２０４からの動作指示をそのまま紙幣部１１へ送信することもある、動作指示に含まれる情報を参照し、情報を変更した上で紙幣部１１へ送信する場合もある。

続いて、これらのサービスプロバイダ２０４とファンクションライブラリ２０６を、取引処理又は拡張処理のいずれかに応じて、使い分ける技術について説明する。例えば、制御部２０は、外部からの指示に基づいて取引処理を紙幣部１１に実施させる場合、サービスプロバイダ２０４が紙幣部１１に取引処理を実施させる（実施可能な）コマンド（例えば、コマンドコード）を生成する。また、外部からの指示に基づいて拡張処理を紙幣部１１に実施させる場合、ファンクションライブラリ２０６が拡張処理を実施する又は紙幣部１１に拡張処理を実施させる（実施可能な）コマンド（例えば、コマンドコード）を生成するようにしてもよい。なお、この場合、外部からの指示はサービスプロバイダ２０４を経由してもよいし、経由しなくてもよい。また、外部からの指示がサービスプロバイダ２０４を経由した場合、サービスプロバイダ２０４は、紙幣部に拡張処理を実施させるコマンドの生成をできないものでよい。

なお、上述のコマンドの生成とは、コマンドを新たに生成する意に限られず、既成のコマンドを利用することも含まれる。また、コマンドコードとは、紙幣部に実施させる処理を示す処理毎に固有の情報である。また、紙幣部が実施可能なコマンドコートとは、紙幣部１１が理解できるコマンドコードを意味し、当該コマンドコードの情報に従い紙幣部が処理又は動作をするコマンドであってよい。すなわち、コマンドコードを変更しなくとも紙幣部１１が動作する（紙幣部１１を直接動作させることができる）コマンドコードは、実施可能なコマンドコードに含まれる。なお、制御部２０と紙幣部１１との間の通信のために、コマンドコードを一時的に変更した場合であっても、制御部２０と紙幣部１１とで利用されるコマンドコードが同一の場合は、実施可能なコマンドに含まれる。一方、サービスプロバイダ２０４や、ファンクションライブラリ２０６でコマンドコードを変換した場合は、実施可能なコマンドコードには含まれなくともよい。

取引処理と、拡張処理とを異なるミドルウェアのそれぞれが、紙幣部１１に実施可能なコマンドを生成するようにしたことで、拡張処理の技術秘匿と機能拡張や変更に伴う設計工数の削減の両立が可能となる。また、この場合、上述のように、ファンクションライブラリ２０６は、サービスプロバイダ２０４が生成した紙幣部１１に取引処理を実施させるコマンドに関しては、そのまま（コマンドコードを変更することなく）紙幣部１１へ送信してもよい。そのまま紙幣部１１に送信することにより、取引処理を実施している既存の制御部２０のサービスプロバイダ２０４の設計変更を抑制することが可能となる。

以下では、図５を用いて、制御部２０が、取引処理を実施する場合に、ファンクションライブラリ２０６が取引処理及び拡張処理を紙幣部１１に実施させる例について説明する。なお、上記同様取引処理のコマンドコードは、サービスプロバイダ２０４が生成してもよい。

より具体的には、図５に示すように、制御部２０では、業務アプリケーション２０３から取引に関する指示を受けると、サービスプロバイダ２０４が、その指示に従って、ファンクションライブラリ２０６に対するコマンド電文Ｃａ１を生成、編集して出力する。コマンド電文Ｃａ１としては、例えば、入金処理を実行する指示を含むコマンドがある。図５に示すコマンド電文Ｃａ１と、図４に示したコマンド電文Ｃ１とは同じ電文を用いることができる。

ファンクションライブラリ２０６は、サービスプロバイダ２０４からコマンド電文Ｃａ１を受信すると、そのコマンドに従って、紙幣部１１に対するコマンド電文Ｃｂ１を生成、編集して出力する。コマンド電文Ｃｂ１としては、例えば、上記指示に含まれる入金処理を実行するコマンドのほか、カセットの金種の指定、偽券の取扱方法、紙幣受け付け率の指定を含むコマンドがある。また、コマンド電文Ｃｂ１には、現時点における紙幣部１１の状態を示す状態情報を取得するためのコマンドが含まれる。上記状態情報を取得するためのコマンドとしては、例えば、ログ情報を収集するコマンドがある。

紙幣部１１は、コマンド電文Ｃｂ１を受信すると、これらのコマンドに従って処理を実行し、その結果をレスポンス電文Ｒｂ１としてファンクションライブラリ２０６に返す。レスポンス電文Ｒｂ１としては、例えば、指定された金種のカセットに収納された紙幣の枚数、偽券と判別された紙幣の枚数、処理した際の紙幣の受け付け率、処理が正常終了したか否かを示す処理結果を含むレスポンスがある。

ファンクションライブラリ２０６は、上記レスポンス電文Ｒｂ１に応じた次の処理を実行するためのコマンド電文Ｃｂ２を生成、編集して出力する。例えば、ファンクションライブラリ２０６は、レスポンス電文Ｒｂ１として、指定された金種の紙幣のカセットの収納枚数が、あらかじめ定められた閾値以上である場合やこれ以上紙幣を受け付けられないため入金の取引を停止させる等の問い合わせを含む場合には、他のカセットに回収する指示をコマンド電文Ｃｂ２として出力し、コマンド電文Ｃｂ２に対するレスポンス電文Ｒｂ２を受信する。

以降、ファンクションライブラリ２０６は、業務アプリケーション２０３から指示された取引が完了するまで、紙幣部１１との間でコマンド電文およびレスポンス電文の受け渡しを行う。紙幣部１１から、業務アプリケーションより指示された取引に関する処理の終わりを示すレスポンスＲｂＮを受信すると、ファンクションライブラリ２０６は、サービスプロバイダ２０４に業務アプリケーションから指示された取引に関する処理の終わりを示すレスポンスＲａＮを送信する。サービスプロバイダ２０４は、当該レスポンスに基づき、業務アプリケーション２０３により、外部に取引の結果を通知する。

なお、図４の場合と異なり、図５では、サービスプロバイダ２０４が生成するコマンド電文は、紙幣部１１等の各部が実行不能な内容又は実行可能な内容のいずれであってもよい。実行不能な場合、ファンクションライブラリ２０６は、サービスプロバイダ２０４により送信された紙幣部１１等の各部が実行不能なコマンド電文に基づき、紙幣部１１等の各部が実行可能なコマンド電文を生成又は変更し、紙幣部１１等の各部から受信したレスポンス電文を、サービスプロバイダ２０４が処理できるレスポンス電文に変換して、サービスプロバイダ２０４に送信してもよい（詳細に関しては、後述する。）。一方、ファンクションライブラリ２０６は、実行可能なコマンドの場合は、そのまま紙幣部１１等とへ送信し、紙幣部１１から受信したレスポンスをそのままサービスプロバイダ２０４に返信してもよい。

このように、本実施例では、サービスプロバイダ２０４と紙幣部１１との間にファンクションライブラリ２０６を設けることにより、サービスプロバイダ２０４が第一のコマンド（例えば、コマンド電文Ｃａ１）をファンクションライブラリ２０６に送信し、第一のコマンドに対応する第一のレスポンス（例えば、レスポンスＲａＮ）をファンクションライブラリ２０６から受信するまでの間に、ファンクションライブラリ２０６が、サービスプロバイダ２０４に問い合わせる（レスポンス電文及びコマンド電文の送受信する）ことなく、第一のコマンドに基づき、モジュールに対する複数の第二のコマンド（例えば、コマンド電文Ｃｂ１、コマンド電文Ｃｂ２）の送信及び複数の第二のコマンドそれぞれに対応する第二のレスポンス（例えば、レスポンス電文Ｒｂ１、レスポンス電文Ｒｂ２）を受信する。これにより、サービスプロバイダ２０４は、ファンクションライブラリとの間での、第一のコマンド及び第一のレスポンスの数を抑制することが可能となる。

また、ファンクションライブラリは、一の第二のコマンドに対応する一の第二のレスポンス（例えば、レスポンス電文Ｒｂ１）の内容に基づき、一の第二のコマンドの次にモジュールに送信する次の第二のコマンド（コマンド電文Ｃｂ２））の種類を判断するようにしてもよい。この場合、ファンクションライブラリは、モジュールに対して、モジュールの状態に適したコマンドを選択して送信することが可能となり、モジュールへのコマンド送信及びレスポンス受信の数の抑制などによるＡＴＭ１０のシステム資源の効率的な利用ができる。

また、外部からの指示に基づき、サービスプロバイダ２０４が紙幣部１１に紙幣を搬送させて実行する入金取引又は出金取引等の取引処理を実行させる上述の第一のコマンドである取引コマンドを送信し、ファンクションライブラリ２０６は、取引コマンドに基づき、取引では使用されない状態情報を含むログ情報を収集する情報取得コマンドを生成し、紙幣部１１に送信し拡張処理を実行してもよい。なお、状態情報は、紙幣部１１が紙幣を搬送させたことにより生じる紙幣部１１の稼働情報、紙幣部１１が取引前若しくは後で保持している紙幣の種類毎の収納情報、紙幣部１１の部品毎のエラー情報を示す部品情報などを含む情報であってよい。さらには、ファンクションライブラリ２０６は、取引コマンドに基づき紙幣部１１から取得した情報は、サービスプロバイダ２０４に送信し、情報取得コマンドに基づき紙幣部１１が取得したログ情報は、サービスプロバイダ２０４には送信しないように処理する。この場合、ファンクションライブラリ２０６は、ログ情報をストレージ２０２に収納してもよい。

また、ファンクションライブラリ２０６は、サービスプロバイダ２０４により生成された紙幣部１１等の各部が実行不能なコマンドに基づき、紙幣部１１等の各部が実行可能なコマンドを生成又は変更してもよい。

また、処理の種類（例えば、拡張処理）によっては、サービスプロバイダを２０４介さずに、ファンクションライブラリ２０６が外部からの第一のコマンドに基づき紙幣部１１が実行可能な一の第二のコマンドを生成し、紙幣部１１へ送信し、紙幣部１１から受信した一の第二のコマンドに対する一の第二のレスポンスに基づき、紙幣部１１が実行可能な他の第二のコマンドを生成し、紙幣部１１に送信してもよい。

このように、ファンクションライブラリ２０６を設け、上述の処理を実施させることで、モジュール提供先では、サービスプロバイダ２０４を設計する負荷を抑制できるとともに、モジュール提供元では技術流出の懸念がなくなる。また、モジュールの運用や保守に必要な機能において動作履歴を活用することができる。また、図６は、図５に示したモジュールがサブモジュールを含む場合のソフトウェアの構成図である。図６に示す例では、図５に示したモジュールである紙幣部１１が、内部に１階層のサブモジュールである識別部１１３を有している。また、制御部２０には、上記識別部１１３に対応する識別部通信制御部が設けられている（不図示）。すなわち、制御部２０は、紙幣部１１と接続されると共に、紙幣部１１を介さずに識別部１１３とも接続されている。

制御部２０では、業務アプリケーション２０３から取引に関する指示を受けると、サービスプロバイダ２０４が、その指示に従って、ファンクションライブラリ２０６に対するコマンド電文Ｃａ１を生成、編集して出力する。コマンド電文Ｃａ１としては、例えば、入金処理を実行する指示を含むコマンドがある。図５に示すコマンド電文Ｃａ１と、図４に示したコマンド電文Ｃ１とは同じ電文を用いることができる。

ファンクションライブラリ２０６は、サービスプロバイダ２０４からコマンド電文Ｃａ１を受信すると、そのコマンドを解析し、モジュールである紙幣部１１に対するコマンド電文ＣｂＭ１と、サブモジュールである識別部１１３に対するコマンド電文ＣｂＳ１を生成、編集して出力する。コマンド電文ＣｂＭ１としては、図５の場合と同様のコマンドがある。また、コマンド電文ＣｂＳ１としては、例えば、紙幣の真偽判定のための閾値の設定を含むコマンドがある。この場合も、コマンド電文ＣｂＭ１と同様に、現時点における紙幣部１１の状態を示す状態情報を取得するためのコマンドを含めてもよい。

識別部１１３は、コマンド電文ＣｂＳ１を受信すると、これらのコマンドに従って処理を実行し、その結果をレスポンス電文ＲｂＳ１としてファンクションライブラリ２０６に返す。レスポンス電文ＲｂＳ１としては、例えば、紙幣の真偽判定のための閾値を含むレスポンスがある。

ファンクションライブラリ２０６は、レスポンス電文ＲｂＭ１を受信した場合と同様に、上記レスポンス電文ＲｂＳ１に応じた次の処理を実行するためのコマンド電文ＣｂＳ２を生成、編集して出力し、業務アプリケーション２０３から指示された取引が完了するまでコマンド電文およびレスポンス電文の受け渡しを行う。

すなわち、識別部１１３は、制御部２０が紙幣部１１へ送信したコマンドに基づき取引処理における紙幣の識別を実施すると共に、制御部２０が紙幣部１１を介さずに識別部１１３に送信したコマンドに基づき、取引処理とは異なる処理（例えば、拡張処理）を実施する。

このように、識別部１１３を、直接（紙幣部１１を経由せず）、ファンクションライブラリ２０６（又は制御部２０）と接続することで、識別部１１３への専用の動作指示や識別部１１３が持つ多量情報の収集を行うことができる。ここでは、ファンクションライブラリ２０６は、識別部通信制御部(不図示)を介して識別部１１３と通信を行なうため、紙幣部１１との通信と並行で処理することで、サービスプロバイダ２０４からコマンドが発行されてからレスポンスを返すまでの処理時間を短縮することができる。

また、ファンクションライブラリ２０６は、サービスプロバイダ２０４からの１のコマンド電文に基づき、紙幣部１１へのコマンド電文と、識別部１１３へのコマンド電文を生成してもよい。これにより、サービスプロバイダ２０４からのコマンド電文の指示の回数を抑制することが可能になり、モジュール提供先では、従来のように、サービスプロバイダ２０４を設計する必要がなくなるとともに、モジュール提供元では技術流出の懸念がなくなる。なお、本例では、モジュールが１階層の１つのサブモジュールを有している場合について説明したが、モジュールが多数階層の複数のサブモジュールを有している場合にも同様に適用することができる。この場合にはさらに上記処理時間を短縮することができる。続いて、本実施例で行われる処理について説明する。

図７は、ファンクションライブラリ２０６のライセンス管理や正しいモジュールが接続されているかを検証することを目的としたなりすまし防止機能を持たせた紙幣部接続処理フローの例を示す。本処理は、例えば、ＡＴＭ１０の電源がＯＮされたときに実行される。

紙幣部接続処理（７０１）では、ファンクションライブラリ２０６は、紙幣部１１と回線接続を行なうコマンド電文を生成し、紙幣部通信制御部２０５１に出力する。紙幣部通信制御部２０５１は、所定の通信手順を含むコマンド電文を生成し、紙幣部１１に対する回線接続を行う（７０２）。ファンクションライブラリ２０６は、紙幣部通信制御部２０５１から紙幣部１１と回線接続できた旨のレスポンス電文を受信したか否かを判定し（７０３）、接続できた旨のレスポンス電文を受信しなかったと判定した場合（７０３；Ｎｏ）、紙幣部１１からのレスポンス電文に含まれる接続不可を示す理由（例えば、通信タイムアウト、紙幣部１１の電源ｏｆｆ等のエラーを示すメッセージやコード）をサービスプロバイダ２０４に通知し（７１０）、本処理を異常終了させる（７１３）。

一方、ファンクションライブラリ２０６は、接続できた旨のレスポンス電文を受信したと判定した場合（７０３；Ｙｅｓ）、そのレスポンス電文に含まれる紙幣部のタイプ（型式）を示す紙幣部種別や紙幣部のハードウェア毎に固有のシリアル番号等の紙幣部を識別する情報を含む構成情報を読み取る（７０４）。読み取った構成情報の例を図８に示す。

図８に示すように、構成情報には、モジュールである紙幣部１１のハードウェア構成（例えば、カセットの数量、国や地域情報、入出金口の配置等の情報がある。）、シリアル番号、ファームウェアのバージョン数のほか、サブモジュールである識別部のシリアル番号、ファームウェアのバージョン数が含まれている。

続いて、ファンクションライブラリ２０６は、あらかじめストレージ２０２に記憶したＡＴＭ１０の有するライセンス許可情報と、ステップ７０４で読み取った構成情報とを参照し、読み取った構成情報がライセンス許可情報に登録されているか否かを判定する（７０５）。本例では、ライセンス許可情報がストレージ２０２に記憶されているが、ファンクションライブラリ２０６に記憶されていてもよい。ライセンス許可情報は、使用が許可された紙幣部１１を識別するための情報である。

ライセンス許可情報の例を図９に示す。ここでは動作を許可するライセンス許可シリアル番号をテーブル形式で保持している。図９では、ある種別（型式ＸＸＸＸＸ−ＸＸ）の紙幣部について、そのハードウェア構成、ライセンスが許可された複数のシリアル番号が登録されていることがわかる。図９のように、上記シリアル番号をすべて格納するほか、ある番号から他の番号まで、というようにシリアル番号を特定の範囲で指定して許可するか、ある桁の特定数値を指定することにより許可するといった手法により、紙幣部が許可された紙幣部であるか否かを判定してもよい。

ファンクションライブラリ２０６は、ステップ７０５で、読み取った構成情報がライセンス許可情報に登録されていないと判定し（７０５；Ｎｏ）、使用不可と判断したときには、サービスプロバイダ２０４にその旨を通知し（７１１）、処理を異常終了させる（７１３）。この場合、サービスプロバイダ２０４は、使用不可の情報を外部（ＡＴＭ１０が接続された上位装置やＡＴＭ１０の表示部（例えば、操作部１５、係員操作部１６））に通知してもよい。

一方、ファンクションライブラリ２０６は、ステップ７０５で、読み取った構成情報がライセンス許可情報に登録されていると判定し（７０５；Ｙｅｓ）、使用可能と判断したときには、紙幣部１１に対するコマンド電文を生成し、紙幣部通信制御部２０５１に出力する。紙幣部通信制御部２０５１は、所定の通信手順を含むコマンド電文を生成し、紙幣部１１の初期化処理を実行するコマンド電文を生成し、紙幣部１１は、そのコマンド電文に従って初期化処理を実行する（７０６）。ファンクションライブラリ２０６は、紙幣部１１が正常に初期化できたことを示すレスポンス電文を、紙幣部通信制御部２０５１を介して紙幣部１１から受信したか否かを判定する（７０７）。紙幣部１１の初期化の例としては、使用するカセットの金種の指定や、紙幣受け付け率の設定がある。

ファンクションライブラリ２０６は、紙幣部１１が正常に初期化できたことを示すレスポンス電文を受信したと判定した場合（７０７；Ｙｅｓ）には、サービスプロバイダ２０４に初期化が正常した旨を通知し（７０８）、接続処理を正常終了する（７０９）。一方、ファンクションライブラリ２０６は、紙幣部１１が正常に初期化できたことを示すレスポンス電文を受信しなかったと判定した場合（７０７；Ｎｏ）、初期化ができなかった旨をサービスプロバイダ２０４に通知し（７１２）、処理を異常終了する（７１３）。

図１０は、ファンクションライブラリ本体機能の基本処理フローを例として示す。本処理は、例えば、ファンクションライブラリ２０６が、Ｓ７０１、Ｓ１００２、Ｓ１０１３を、ＡＴＭ１０の電源がＯＮされたときに実行し、Ｓ１００３〜Ｓ１０１２、Ｓ１０１４をサービスプロバイダ２０４からのコマンドの受信に応じて実行してよい。

まず、本処理では、図７に示した紙幣部接続処理を実行し（７０１）、ファンクションライブラリ２０６は、紙幣部１１に接続できなかったときには接続不可として不可理由をサービスプロバイダ２０４に通知し、再接続指示待ちとする（１００２；Ｎｏ、１０１３）。一方、ファンクションライブラリ２０６は、紙幣部１１に正しく接続できたときには、サービスプロバイダ２０４からのコマンドを受信する（１００３）。ステップ１００３においてサービスプロバイダ２０４からコマンドを受信したときに次のステップに進み、ファンクションライブラリ２０６は、コマンドに対応した登録処理内容を処理内容テーブルの中から検索する。

図１１は、処理内容テーブルの例を示す図である。処理内容テーブルは、サービスプロバイダ２０４から受け取ったコマンドに対するモジュールである紙幣部１１への処理の順序を決める処理シーケンスを定めたテーブルである。本例ではモジュールへの処理シーケンスを定めているが、図６に示したようにモジュールがサブモジュールを有している場合には、モジュールと同様に定めることができる。

図１１に示すように、処理内容テーブルには、サービスプロバイダ２０４から受け取ったコマンドを識別するための番号と、その番号により識別されるコマンドと、そのコマンドの実行が許可されたものであるか否かを示す許可区分と、そのコマンドを受け取ったときに実行する処理シーケンスとが対応付けて記憶されている。

なお、ファンクションライブラリ２０６は、モジュールに対して発行するコマンドの種別毎にＩＤ等を付与し、コマンドの発行回数をカウントするようにしても良い。また、併せてコマンド発行の時刻や、モジュールの実行した処理が正常に終了したか否かを示す終了情報を管理しても良い。これにより、ファンクションライブラリ２０６でコマンドによるモジュールの動作状況（動作正常終了の回数や動作異常終了の回数等）を詳細に把握することができる。また、モジュール提供元では、該モジュールの動作状況に基づきモジュール提供元でのファンクションライブラリ２０６の使用状況を把握することができる。

ファンクションライブラリ２０６は、このような処理内容テーブルを用いてサービスプロバイダ２０４から受信したコマンドを検索し、まず、登録の有無および使用許可されているか否かを判定する（１００５）。

ファンクションライブラリ２０６は、サービスプロバイダ２０４から受信したコマンドが処理内容テーブルに登録されており、かつ使用許可されていると判定した場合（１００５；Ｙｅｓ）、次の処理に進む。一方、ファンクションライブラリ２０６は、サービスプロバイダ２０４から受信したコマンドが処理内容テーブルに登録されており、かつ使用許可されていないと判定した場合（１００５；Ｎｏ）、実行が許可されていないコマンドを受信したとして、処理が実行できない旨をサービスプロバイダ２０４に返送する（１０１４）。

一方、ファンクションライブラリ２０６は、使用許可を確認した場合は（１００５；Ｙｅｓ）、モジュールに対してどのような動作を指示するのかを決定するための指示決定処理（１００６〜１０１０）を実行する。ファンクションライブラリ２０６は、処理対象とするシーケンス番号を初期化する（１００６）。このシーケンス番号は、制御部２０内のメモリ（不図示）に記憶しておく。

次に、ファンクションライブラリ２０６は、図１１に示した処理内容テーブルを参照し、ステップ１００３で受信したコマンドに対応する処理シーケンスのうち、初期化したシーケンス番号に対応するモジュールである紙幣部１１へのコマンド電文を生成し、紙幣部通信制御部２０５１を介して、生成したコマンド電文を紙幣部１１に送信する（１００７）。ステップ１００７で送信されたコマンド電文に従って、紙幣部１１が処理を実行すると、ファンクションライブラリ２０６は、その動作結果を含むレスポンス電文を受信する（１００８）。

ファンクションライブラリ２０６は、モジュールから受信したレスポンス電文を解析してモジュールの動作結果を確認する。ファンクションライブラリ２０６は、図１１に示した処理内容テーブルの現在のシーケンス番号と、モジュールの動作結果とを参照して、次に行うべき処理のシーケンス番号を決定する（１００９）。ファンクションライブラリ２０６は、決定したシーケンス番号がその処理シーケンスの中で最後のシーケンス番号であるか否かを判定し（１０１０）、決定したシーケンス番号がその処理シーケンスの中で最後のシーケンス番号でないと判定した場合（１０１０；Ｎｏ）、ステップ１００７に戻って以降の処理を繰り返す。

一方、ファンクションライブラリ２０６は、決定したシーケンス番号がその処理シーケンスの中で最後のシーケンス番号であると判定した場合（１０１０；Ｙｅｓ）、サービスプロバイダ２０４へのレスポンス電文を生成し（１０１１）、サービスプロバイダ２０４にレスポンス電文を返送する（１０１２）。

以下、図１０に示したステップ１００３以降の処理を、より具体的に説明する。ステップ１００３において、ファンクションライブラリ２０６は、入金処理の実行指示を含むコマンド電文をサービスプロバイダ２０４から受信すると、ステップ１００４、１００５において、図１１に示した処理内容テーブルに入金コマンドとその許可区分が許可であることを確認する。続いて、ファンクションライブラリ２０６は、ステップ１００６において、シーケンス番号を「１」に初期化する。

さらに、ファンクションライブラリ２０６は、ステップ１００７において、入金コマンドに対応する処理シーケンスのうち、初期化したシーケンス番号に対応する順序で行うコマンド電文である入金コマンドを読み取り、モジュールである紙幣部１１へのコマンド電文を生成する（Ｃ１１０１）。ファンクションライブラリ２０６は、生成したコマンド電文を、紙幣部通信制御部２０５１を介して紙幣部１１に送信する。

ファンクションライブラリ２０６は、ステップ１００８において紙幣部１１からコマンド電文に対する処理の実行結果を含むレスポンス電文を受信し、その実行結果を解析する。ファンクションライブラリ２０６は、ステップ１００９において、レスポンス電文を解析した結果、紙幣部１１における処理が正常終了したと判定した場合にはシーケンス番号２に進み、ログ収集１（例えば、正常ログの収集処理）のコマンド電文を生成する（Ｃ１１０２）。ファンクションライブラリ２０６は、生成したコマンド電文を、紙幣部通信制御部２０５１を介して紙幣部１１に送信する。さらに、ファンクションライブラリ２０６は、ステップ１０１０において、入金処理のシーケンス（図１１における番号２のシーケンス）が全て終了したか否かを判定する。この場合には、次のシーケンス番号が指定されていないため、ステップ１０１１、１０１２に進み、ファンクションライブラリ２０６は、紙幣部１１から正常ログの収集処理の実行結果を含むレスポンス電文を受信し、その実行結果を解析する。ファンクションライブラリ２０６は、レスポンス電文を解析した結果、正常ログの収集処理が正常終了したと判定した場合には、入金処理が正常に終了したことを示すレスポンス電文を生成し（Ｃ１１０３）、生成したレスポンス電文をサービスプロバイダ２０４に送信する。一方、ファンクションライブラリ２０６は、レスポンス電文を解析した結果、正常ログの収集処理が異常終了したと判定した場合には、ステップ１０１１、１０１２において、入金処理が異常終了したことを示すレスポンス電文を生成し（Ｃ１１０４）、生成したレスポンス電文をサービスプロバイダ２０４に送信する。

上記処理と同様に、ファンクションライブラリ２０６は、ステップ１００９において、レスポンス電文を解析した結果、紙幣部１１における処理が正常終了しなかったと判定した場合にはシーケンス番号３に進み、ログ収集２（例えば、障害ログの収集処理）のコマンド電文を生成し（Ｃ１１０５）、生成したコマンド電文を、紙幣部通信制御部２０５１を介して紙幣部１１に送信する。さらに、ファンクションライブラリ２０６は、ステップ１０１０において、入金処理のシーケンスが全て終了したか否かを判定する。この場合には、次のシーケンス番号が指定されていないため、ステップ１０１１、１０１２に進み、ファンクションライブラリ２０６は、紙幣部１１から異常ログの収集処理の実行結果を含むレスポンス電文を受信し、その実行結果を解析する。

ファンクションライブラリ２０６は、レスポンス電文を解析した結果、障害ログの収集処理が正常終了したと判定した場合には、入金処理が異常に終了したことを示すレスポンス電文を生成し（Ｃ１１０６）、生成したレスポンス電文をサービスプロバイダ２０４に送信する。また、ファンクションライブラリ２０６は、レスポンス電文を解析した結果、障害ログの収集処理が異常終了したと判定した場合には、ステップ１０１１、１０１２において、入金処理が異常終了したことを示すレスポンス電文を生成し（Ｃ１１０７）、生成したレスポンス電文をサービスプロバイダ２０４に送信する。

すなわち、シーケンス番号３の場合、処理の異常終了としては、入金処理自体が異常終了したこと、障害ログ収集が異常終了したことの２つのケースがあるが、このような場合であっても、サービスプロバイダ２０４に対しては、いずれの場合も入金処理が異常終了したことだけを示すレスポンス電文を生成する。したがって、サービスプロバイダ２０４に対しては、従来どおり、入金処理が異常終了したことだけがレスポンス電文として通知される。

このように、本実施例では、サービスプロバイダ２０４から受信した第一のコマンドに従ってモジュールが処理を実行する場合、ファンクションライブラリ２０６が、その第一のコマンドと処理内容テーブルとを参照し、その第一のコマンドに基づくモジュールとの第二のコマンド／レスポンスのシーケンスを解析し、サービスプロバイダ２０４から受信した第一のコマンドごとに、モジュールとの第二のコマンド／レスポンスのシーケンスに基づく処理を実施した上で、サービスプロバイダへの第一のレスポンス電文を生成する。言い換えると、ファンクションライブラリは、一の第二のコマンドに対するモジュールからの応答である一の第二のレスポンスの情報に基づき、次にモジュールに送信する他の第二のコマンドを決定する。

より詳細には、制御部が、一の第二のレスポンスの情報毎に、次に生成する他の第二のコマンドの情報を記憶した処理内容情報を有し、ファンクションライブラリは、処理内容情報に基づき、モジュールから受信した一の第二のレスポンスの情報に対応する他の第二のコマンドの情報を含む他の第二のコマンドを送信している。このため、モジュールの提供元では、モジュールの提供先に委ねざるを得なかった機能の設計を自らおこなえる。また、モジュール提供先にとっては、複雑なコマンドレスポンス電文等の解析をすることなくサービスプロバイダの設計ができる。

図１２は、上記実施例で送受信されるコマンド電文のフォーマットの例を示す図である。図１２に示すように、コマンド電文のフォーマットには、コマンド電文の長さを示す電文長と、サービスプロバイダから送信されたコマンドを示すコマンドコードと、紙幣の受け入れ可能枚数を示す合計受付可能枚数と、金種ごとの受け入れ可能枚数を示す金種１受付可能枚数〜金種４受付可能枚数と、コマンド電文の拡張コマンドを設定するためのリザーブと、電文の妥当性を確認するためのチェックコードとが含まれる。図１０、１１の例では、サービスプロバイダ２０４から送信された入金コマンドがコマンドコードに設定されている。

図１３は、上記実施例で送受信されるレスポンス電文のフォーマットの例を示す図である。図１３に示すように、レスポンス電文のフォーマットには、レスポンス電文の長さを示す電文長と、モジュールが実行したコマンドを示すコマンドコードと、コマンドの実行結果を示す動作結果コードと、コマンド実行時に発生したエラーを示すエラーコードと、コマンドを実行して実際に紙幣が受け入れられた枚数を示す合計受付枚数と、金種ごとの受け入れ枚数を示す金種１受付枚数〜金種４受付枚数と、リジェクトされた紙幣枚数を示すリジェクト件数と、レスポンス電文の拡張コマンドを設定するためのリザーブと、電文の妥当性を確認するためのチェックコードとが含まれる。図１０、１１の例では、紙幣部１１が実行した入金コマンドがコマンドコードに設定されている。

図１２、１３は入金取引に利用されるコマンドに関し説明したが、出金取引など他の取引に利用される出金コマンドであっても、同様である。すなわち、紙幣取引を指示する紙幣取引コマンドは、コマンドの種別を示すコマンドコードと、紙幣の種類毎に取引可能な枚数を示す取引可能枚数を含んでよい。また、紙幣取引の結果を返信する紙幣取引レスポンスは、当該レスポンスに対応する紙幣取引コマンドの種別を示すコマンドコードと、紙幣部が計数した紙幣の種類毎の枚数である取引枚数を含む。

なお、上記実施例では、レスポンス電文としてリザーブには拡張用のコマンドを設定することなくやり取りした。しかし、例えば、紙幣部１１が入金計数動作を実行したときに投入口に返却した紙幣がある場合、その返却紙幣が計数動作を実行した結果リジェクトした紙幣である場合には、再度入金計数動作を実行することで、その返却紙幣を読み取ることができる可能性がある。しかし、返却紙幣が繰出し不良に伴うものであったときは、再度入金計数動作を行なうとジャム異常になる懸念がある。したがって、このような場合には、そのまま返却紙幣有りというレスポンス電文を送信し、その返却紙幣については再度読み取らずに処理を終了させるほうが好ましい場合もある。したがって、図１４に示すように、紙幣部１１が上記リザーブに投入口繰出し状況１４０１の判定結果を含めてレスポンス電文を送信してもよい。レスポンス電文はコマンド電文に対して返送されるため、図１２に示したコマンド電文のリザーブに、投入口繰出し状況１４０１を通知するコマンドを設定しておけばよい。このように、図１３に示したレスポンス電文例に、投入口繰出し状況等の、紙幣部１１を構成する各部の詳細な状況を示す付加情報を含めることにより、そのレスポンス電文を受信したファンクションライブラリ２０６は、その情報を用いてさらに細かい制御を行なうことができる。

図１５は、レスポンス電文に上述した状態情報などの付加情報を含めて返送した場合の処理内容テーブルの例を示す図である。図１５では、紙幣部１１が入金計数を実行したときに上記付加情報を含めたレスポンス電文を送信する場合の例を示している。また、図１６は、上記付加情報を含めた場合のファンクションライブラリ本体機能の基本処理フローを例として示す図である（例えば、拡張処理に含まれる動作処理などがある）。図１６では、図１０のステップと同一のステップについては同一の符合を付してその説明を省略している。また、図１０同様、例えば、ファンクションライブラリ２０６は、Ｓ７０１、Ｓ１００２、Ｓ１０１３を、ＡＴＭ１０の電源がＯＮされたときに実行し、Ｓ１００３〜Ｓ１００８、Ｓ１０１０〜Ｓ１０１２、Ｓ１０１４、Ｓ１０６１をサービスプロバイダ２０４からのコマンドの受信に応じて実行してよい。

図１０に示したＣ１１０１の場合と同様、ステップ１００６〜１００８では、ファンクションライブラリ２０６は、初期化したシーケンス番号に対応する順序で行うコマンド電文である入金コマンドを読み取り、上記付加情報として投入口繰出し状況１４０１を判定するためのコマンドを含むコマンド電文を生成する。そして、ファンクションライブラリ２０６は、そのコマンド電文を、紙幣部通信制御部２０５１を介して紙幣部１１に送信し、そのコマンド電文にしたがって処理されたレスポンス電文を、紙幣部１１から受信し、その実行結果を解析する。

このとき、ファンクションライブラリ２０６は、ステップ１６０１において、図１５に示した処理内容テーブルを参照し、返却媒体ありかつ繰出し不良なしを示す旨の実行結果を示す投入口繰出し状況１４０１を含むレスポンス電文を紙幣部１１から受信したか否かを判定する（Ｃ１５０１）。ファンクションライブラリ２０６は、返却媒体ありかつ繰出し不良なしを示す旨の実行結果を示す投入口繰出し状況１４０１を含むレスポンス電文を受信したと判定した場合、シーケンス番号２に進み、再度入金コマンドを含むコマンド電文を紙幣部１１に送信する（Ｃ１５０２）。このように、ファンクションライブラリ２０６は、紙幣部１１から受信したレスポンス電文の付加情報を参照して再度入金コマンドを発行すべきか否かを判定しているので、リジェクト紙幣の低減を図ることができる。

一方、ファンクションライブラリ２０６は、返却媒体ありかつ繰出し不良なしを示す旨の実行結果を示す投入口繰出し状況１４０１を含むレスポンス電文を受信したと判定した場合、シーケンス番号３に進み、図１０の場合と同様に、ログ収集１を実行し、そのまま処理を終了する。処理を終了する理由は、返却紙幣があっても、繰出し不良が発生していたときには再度入金を行なうとジャムになる可能性があり、そのまま動作終了したほうが高い信頼性が得られるためである。

すなわち、サービスプロバイダから受信した第一のコマンドに基づき、ファンクションライブラリ２０６が、紙幣部１１に第二のコマンドを送信し、紙幣部から状態情報を含む第二のレスポンスを受信し、当該状態情報に応じた処理を実行した上で、サービスプロバイダに第一のレスポンスを送信することで、サービスプロバイダは、複雑な処理を実施する必要がなくなる。

また、上記実施例では、図９に示したように、シリアル番号が登録されている紙幣部１１についてのみ図１１に示した処理内容テーブルの許可区分を「有」として定義し、コマンドの実行を許可することとした。しかし、モジュールの提供先によって、ライセンスを与えるレベルを分け、どのようなレベルのコマンドを実行させるのかをモジュールの提供元が定めておくことが望ましい場合もある。そこで、以下では、許可区分を「有無」だけでなく、ライセンスレベルに応じて分けて定義する場合について説明する。

図１７は、ライセンスレベルを含めて定義したライセンス許可情報の例を示す図である。図１７に示すように、本例では、紙幣部種別及び型式に対応付けてライセンスレベルが記憶されている。図１７では、ライセンスレベル１（基本機能のみ許可するレベル）、ライセンスレベル２（基本機能および拡張機能を許可するレベル）として定義されているため、シリアル番号１、２の紙幣部については拡張機能として提供されるコマンド電文およびレスポンス電文のやり取りが可能となる。なお、ライセンス許可シリアル番号として紙幣部の製造番号を用いることにより、紙幣部１つ１つの装置を識別することができるが、故障等に伴う紙幣部の入れ替えや修理を考慮する場合、紙幣部の製造番号とは別にライセンス管理専用のユニークな番号を用いてもよい。

図１８は、図１７に示したライセンス許可情報を用いた場合の処理内容テーブルの例を示す図である。図１８に示すように、ライセンスレベルを設けたときの処理内容テーブルには、許可区分に代えて許可区分レベル１８０１が定義されている。この例では、ライセンスレベルが１、２のいずれの紙幣部でもリセットコマンド、入金コマンド、収納コマンドのそれぞれと、これらのコマンドに対応する処理シーケンスの実行が可能である一方、自動精算コマンドおよびこれに対応する処理シーケンスは、拡張機能であるため、ライセンスレベルが２の紙幣部にのみ許可していることがわかる。以上のように、処理内容テーブルには、複数の取引機能及び拡張機能のコマンドとそのコマンドに対応する処理シーケンスの情報が格納されると共に、紙幣部は複数の取引機能又は拡張機能のうちいずれの機能の実行を許可されているかを指定するライセンス情報をさらに含むようにすることができる。

さらに、出金コマンドについては、ライセンスレベルに応じて、実行する処理シーケンスを分けて定義されている。ライセンスレベルが１の場合には、基本機能として出金処理とログ収集を実行する処理シーケンスである一方、ライセンスレベルが２の場合には、拡張機能として出金処理とログ収集のほか、回収やリセットの実行が可能な処理シーケンスであることがわかる。本例では、１つの処理内容テーブルに複数のライセンスレベルのそれぞれに対応する処理シーケンスを定義しているが、ライセンスレベルごとに処理テーブルを設けてもよい。以上のように、紙幣部毎にライセンスレベルを設定することにより、実行する機能の適否を柔軟に設定することができる。

図１９は、図１７に示したライセンス許可情報を用いた場合のファンクションライブラリ本体機能の基本処理フローを例として示す図である。図１９では、図１０のステップと同一のステップについては同一の符合を付してその説明を省略している。また、図１０、１６１９と同様に、一部の処理をＡＴＭ１０の電源がＯＮされたときに実行し、残りの処理をサービスプロバイダ２０４からのコマンドの受信に応じて実行してよい。

ファンクションライブラリ２０６は、ステップ１０３において、入金処理の実行指示を含むコマンド電文をサービスプロバイダ２０４から受信すると、ステップ１００４、１９０１において、図１１に示した処理内容テーブルに入金コマンドとその許可区分レベルを確認する。具体的には、ファンクションライブラリ２０６は、自装置のシリアル番号に対応するライセンスレベルを図１７に示したライセンス許可情報から読み取る。ファンクションライブラリ２０６は、読み取ったライセンスレベルが図１８に示した処理内容テーブルの入金コマンドに対応する許可区分レベルに設定されているか否かを判定し、読み取ったライセンスレベルが上記許可区分レベルに設定されていないと判定した場合には、図１０の１０１４と同様に、処理が実行できない旨をサービスプロバイダ２０４に返送する。一方、ファンクションライブラリ２０６は、図１０の場合と同様に、ステップ１００６以降の処理を実行する。

このように、ファンクションライブラリ２０６は、モジュールに与えられたライセンスレベルに応じてコマンド電文およびレスポンス電文の実行可否を判定しているので、モジュール提供先が保有するライセンスのレベルに応じて、どのような機能をモジュール提供先に開示するのかを、モジュール提供元主導で設計することができる。

また、上記実施例では、サービスプロバイダ２０４とファンクションライブラリ２０６との間のコマンド電文およびレスポンス電文と、ファンクションライブラリ２０６と紙幣部１１６との間のコマンド電文およびレスポンス電文とを、同じフォーマットで実行する場合について説明した。しかし、サービスプロバイダ２０４とファンクションライブラリ２０６との間のコマンド電文およびレスポンス電文を蓄積して解析する等により、ファンクションライブラリ２０６がどのようなコマンドを受信した場合にどのような処理シーケンスを実行するのかがモジュール提供先に漏洩し、モジュールの提供元からモジュールの提供先への技術流出の懸念が残る。そこで、以下では、モジュール使いこなし技術の隠蔽化を目的として、コマンド電文の一部を改変した場合について説明する。

図２０は、ファンクションライブラリ２０６とモジュールである紙幣部１１との間のコマンド電文のフォーマットの例を示す図である。図１２で示したコマンド電文のフォーマットが、サービスプロバイダ２０４とファンクションライブラリ２０６との間のコマンド電文とした場合を例に説明する。図１２では、ファンクションライブラリ２０６がサービスプロバイダ２０４から受け取るコマンド電文のコマンドコードの値が＄１０００であるところ、図２０では、紙幣部１１がファンクションライブラリ２０６から受け取るコマンド電文のコマンドコード２００１の値が＄７１００となっていることがわかる。すなわち、ファンクションライブラリ２０６は、サービスプロバイダ２０４からコマンド電文を受信すると、そのコマンド電文に含まれるコマンドコードの値に所定値を加える等して演算した後の値に変換し、紙幣部１１に送信するコマンド電文に含まれるコマンドコードの値に設定している。

このように、ファンクションライブラリ２０６が、コマンドコードを変更してモジュールに送信することで、サービスプロバイダ２０４とモジュールとを、同じコマンド電文で直接接続することがなくなり、モジュールの使いこなし技術の流出を防止することができ、ファンクションライブラリ２０６の必要性を高めることができる。なお、本例では、コマンドコードを変換する場合の一例について説明したが、コマンド電文が盗み見られた場合でもコマンドシーケンスの秘匿化を行なうため、ファンクションライブラリ２０６にコマンド電文の全体をスクランブルしたり、暗号化する機能を持たせてもよい。

また、上記実施例では、ファンクションライブラリ２０６からサービスプロバイダ２０４にレスポンス電文を送信する際に、処理シーケンスで異常終了となったときのエラーコードが同じである前提で説明した。しかし、ＡＴＭ１０を使用するクライアントのニーズやＡＴＭ１０が設置された地域、モジュールの供給先のニーズ等によっては、一律に同じ体系のエラーコードを採用しないほうが好ましい場合もある。

例えば、ＡＴＭ１０を使用するクライアント側でどのような対応をすればよいのかを容易に把握できるように、標準的なエラーコードの体系よりも簡易な体系のエラーコードを望む場合もある。そこで、以下では、標準的なエラーコードを改変や拡大してファンクションライブラリ２０６からサービスプロバイダ２０４に提供する場合について説明する。

図２１は、標準的なエラーコードを改変や拡大した場合のファンクションライブラリ本体機能の基本処理フローを例として示す図である。図２１では、図１０のステップと同一のステップについては同一の符合を付してその説明を省略している。また、図１０、１６１９と同様に、一部の処理をＡＴＭ１０の電源がＯＮされたときに実行し、残りの処理をサービスプロバイダ２０４からのコマンドの受信に応じて実行してよい。また、図２１では、ファンクションライブラリ２０６と紙幣部１１との接続を行う場合の処理を例示している。

ファンクションライブラリ２０６は、ステップ１００５において、図１１に示した処理内容テーブルを用いてサービスプロバイダ２０４から受信したコマンドを検索し、登録の有無および使用許可されていないと判定した場合（１００５；Ｎｏ）、その旨を示すエラーコードを不図示のメモリに記憶し（２１０１）、ステップ２１０６に進む。

一方、ファンクションライブラリ２０６は、登録の有無および使用許可されていると判定した場合（１００５；Ｙｅｓ）、シーケンス番号を初期化する（１００６）。このとき、ファンクションライブラリ２０６は、次のコマンドを実行するために、ファンクションライブラリ２０６のステータスが次のコマンドを実行可能な状態にあるか否かを判定し（２１０１）、次のコマンドを実行可能でないと判定した場合（２１０２；Ｎｏ）、その旨を示すエラーコードを不図示のメモリに記憶し（２１０３）、ステップ２１０６に進む。

一方、ファンクションライブラリ２０６は、次のコマンドを実行可能であると判定した場合（２１０２；Ｙｅｓ）、ステップ１００７〜１００９の処理を実行し、紙幣部１１から受信したレスポンス電文に含まれる付加情報に従って、ファンクションライブラリ２０６のステータスを更新し（２１０４）、紙幣部１１と接続できたか否かを判定する（２１０５）。そして、ファンクションライブラリ２０６は、紙幣部１１と接続できたと判定した場合（２１０５；Ｙｅｓ）、ステップ２１０１、２１０３で記憶したエラーコードをキーにしてエラーコード変換テーブルにアクセスし、エラーコードを変換する（２１０６）。

図２２は、エラーコード変換テーブル２２００の例を示す図である。図２２に示すように、エラーコード変換テーブル２２００では、紙幣部１１の標準仕様で定められたエラーコードである標準エラーコード２２０１と、カスタマイズされたエラーコード２２０２（本例では、３つの設定のエラーコード）とが対応付けて記憶されている。言い換えると、ファンクションライブラリ２０６が、紙幣部１１毎に固有の標準エラーコード２２０１と、サービスプロバイダ２０４又は銀行毎に固有のエラーコード２２０２とを対応付けている（設定１〜３のそれぞれが、サービスプロバイダ又は銀行毎に決まっている）。したがって、ファンクションライブラリ２０６は、ステップ２１０１、２１０３で記憶した標準エラーコードをいずれかのカスタマイズエラーコードに変換した上で、ステップ１０１１、１０１２において、サービスプロバイダ２０４へのレスポンス電文を生成し、送信する。なお、これらのエラーコードの設定は、製品出荷時に初期設定ファイルとして定めておくか、あるいはＡＴＭ１０の電源起動時にファンクションライブラリ２０６が起動し、サービスプロバイダ２０４にアクセスして取得すればよい。

すなわち、ファンクションライブラリ２０６は、エラーコード変換テーブルに基づき、紙幣部１１から受信したエラーに対応する標準エラーコードを、サービスプロバイダ２０４又は銀行に応じたエラーコードに変更する。これにより、サービスプロバイダ２０４の開発工数を抑制することが可能となる。

また、以上の処理は、図２３で後述するように複数種類の紙幣部１１を取り扱う場合にも適用できる。紙幣部１１の種類が異なると、ファンクションライブラリ２０６が実施する処理シーケンスが異なる場合がある。このような場合、図１１の処理内容テーブルを紙幣部１１の種類毎に記憶することにより、複数の紙幣部１１に対して、ファンクションライブラリ２０６を利用することが可能となる。このような場合を想定して、制御部２０は、参照先管理テーブルを記憶してもよい。

図２３は、参照先管理テーブルの例を示す図である。
参照先管理テーブル２３０１は、紙幣部１１の種類を示す紙幣部種別（例えば、図９の型ＸＸＸＸＸ-ＸＸ）と、図１１に示す処理内容テーブル毎に固有の識別情報とを関連づける。

ファンクションライブラリ２０６は、サービスプロバイダ２０４より紙幣部１１等のモジュールに対する動作指示を受けるとき又は初期設定時に、参照先管理テーブルを参照することにより、紙幣部１１から取得した又は外部から受け付けた紙幣部１１の種別に基づき、対応する参照すべき処理内容テーブルを決定する。そして、ファンクションライブラリ２０６は、決定した処理内容テーブルに定められたシーケンスに基づき、紙幣部１１との間で各処理を実施する。

参照先管理テーブル２３０１を有することにより、ファンクションライブラリ２０６は、紙幣部１１の種類に応じた処理内容の設定が可能となる。

続いて、図２１、２２の変形例に関して説明する。図２１、２２では、制御部２０が、後述する第一のコマレス管理情報（第一のコマレス管理テーブル）と後述する第二のコマレス管理情報（第二のコマレス管理テーブル）との両方の機能を有するエラーコード変換テーブルを有する場合に関し、エラーコードの変換を中心に説明したが、制御部２０が図２４Ａ、２４Ｂのように、第一のコマレス管理情報と第二のコマレス管理情報を別々に備えてもよい。

図２４Ａは、第一のコマレス（コマンドレスポンス）管理テーブル２４００Ａの例を示す図である。図１１、１５、１８の処理内容テーブルの“ＳＰからの受信コマンド”に関し、サービスプロバイダ２０４とファンクションライブラリ２０６との間で、コマンドコードが共通である場合を主として説明した。
しかし、サービスプロバイダ２０４の種類又は銀行の種別が複数になってくると、ファンクションライブラリ２０６とサービスプロバイダ２０４との間で送受信されるコマンド電文やレスポンス電文の定義（例えば、電文フォーマット、コマンドコード）が異なる場合が生じる。

このような場合、コマンド電文やレスポンス電文の定義をサービスプロバイダ２０４又は銀行毎に記憶することにより、複数のサービスプロバイダ２０４に対して、ファンクションライブラリ２０６を利用することが容易となる。このような場合を想定して、制御部２０は、例えば、第一のコマレス管理テーブル２４００Ａを記憶してもよい。以下では、コマンドコード/レスポンスコード（例えば、動作結果コード、エラーコード、付加情報）がサービスプロバイダ２０４又は銀行毎に異なる場合に関して説明するが、これに限るものではない。

第一のコマレス管理テーブル２４００Ａは、コマンド/レスポンスの種別毎２４０１Ａに、ファンクションライブラリ２０６で定義（管理）するコマンドコード/レスポンスコード２４０２Ａと、サービスプロバイダ２０４又は銀行毎に定義（管理）するコマンドコード/レスポンスコード２４０３Ａとを関連づける。

ここで、ファンクションライブラリ２０６で定義するコマンドコード/レスポンスコード２４０２Ａは、コマンド/レスポンスの種別毎に識別できる固有の値である。また、サービスプロバイダ２０４又は銀行毎に定義するコマンドコード/レスポンスコード２４０３Ａも、コマンド/レスポンスの種別毎に識別できる固有の値となる。ファンクションライブラリ２０６で定義するコマンドコード/レスポンスコード２４０２Ａとサービスプロバイダ２０４又は銀行毎に定義するコマンドコード/レスポンスコード２４０３Ａとは、一部又は全部の種別に関し、異なる値又は共通の値を有してもよい。

また、サービスプロバイダ２０４又は銀行毎に定義するコマンドコード/レスポンスコードは、一部又は全部の種別に関し、複数のサービスプロバイダ又は銀行間で異なる値又は共通の値であってよい。

ファンクションライブラリ２０６は、サービスプロバイダ２０４からコマンドを受信する際に、第一のコマレス管理テーブル２４００Ａを参照しサービスプロバイダ２０４又は銀行の種別に基づき、サービスプロバイダ２０４から受信するコマンドコードを対応するファンクションライブラリ２０６のコマンドコードへ変換する。また、ファンクションライブラリ２０６は、サービスプロバイダ２０４にレスポンスを送信する際に、第一のコマレス管理テーブル２４００を参照しサービスプロバイダ２０４又は銀行の種別に基づき、サービスプロバイダ２０４へ送信するレスポンスコードを対応するサービスプロバイダ２０４又は銀行のレスポンスコードへ変換する。あるいは、ファンクションライブラリ２０６は、初期設定時に第一のコマレス管理テーブル２４００Ａを参照しサービスプロバイダ２０４又は銀行の種別に基づき、接続されたサービスプロバイダ２０４に応じて、処理内容テーブル（図１１、１５、１８）の“ＳＰからの受信コマンド”を、当該サービスプロバイダ２０４の種別のコマンドコード/レスポンスコードに変更してもよい。

なお、サービスプロバイダ２０４又は銀行の種別は、サービスプロバイダ２０４又は外部からファンクションライブラリ２０６が受信し、ファンクションライブラリ２０６が設定してもよい。

制御部２０が、第一のコマレス管理テーブル２４００Ａを利用することにより、種別の異なるサービスプロバイダ２０４又は銀行と接続する場合にも、その取扱いを柔軟に行うことができ、適用する機能の拡張や削除にあわせたコマンドの追加、削除を容易に行うことができる。なお、コマンド電文/レスポンス電文のフォーマットや、他の要素に関しても、制御部２０は、サービスプロバイダ２０４又は銀行の種類毎に要素の種類を対応づけた同様の管理テーブルを有し、サービスプロバイダ２０４又は銀行の種類毎の要素の情報に基づき処理をできるようにしてもよい。

図２４Ｂは、第二のコマレス（コマンドレスポンス）管理テーブル２４００Ｂの例を示す図である。図１１、１５、１８の処理内容テーブルの“モジュールへの発行コマンド”は、紙幣部１１とファンクションライブラリ２０６との間で、コマンドコードが共通である場合に関して説明した。
しかし、紙幣部１１の種類（例えば、図８の紙幣部種別（型番））が複数になってくると、ファンクションライブラリ２０６と紙幣部１１との間で送受信されるコマンド電文やレスポンス電文の定義（例えば、電文フォーマット、コマンドコード）が異なる場合が生じる。このような場合、コマンド電文やレスポンス電文の定義を紙幣部１１の種類毎に記憶することにより、複数種類の紙幣部１１に対して、ファンクションライブラリ２０６を利用することが容易となる。このような場合を想定して、制御部２０は、例えば、第二のコマレス管理テーブルを記憶してもよい。以下では、コマンドコード/レスポンスコード（例えば、動作結果コード、エラーコード、付加情報）が紙幣部１１の種類毎に異なる場合に関して説明するが、これに限るものではない。

第二のコマレス管理テーブルは、コマンド/レスポンスの種別毎２４０１Ｂに、ファンクションライブラリ２０６で定義（管理）するコマンドコード/レスポンスコード２４０２Ｂと、紙幣部１１の種類毎に定義（管理）するコマンドコード/レスポンスコード２４０３Ｂとを関連づける。

ここで、ファンクションライブラリ２０６で定義するコマンドコード/レスポンスコード２４０２Ｂは、コマンド/レスポンスの種別毎に識別できる固有の値である。また、紙幣部１１の種類毎に定義するコマンドコード/レスポンスコード２４０３Ｂも、コマンド/レスポンスの種別毎に識別できる固有の値となる。ファンクションライブラリ２０６で定義するコマンドコード/レスポンスコード２４０２Ｂと紙幣部１１の種類毎に定義するコマンドコード/レスポンスコード２４０３Ｂとは、一部又は全部の種別に関し、異なる値又は共通の値を有してもよい。

また、紙幣部１１の種類毎に定義するコマンドコード/レスポンスコード２４０３Ｂは、一部又は全部の種別に関し、紙幣部１１の種類毎で異なる値又は共通の値であってよい。

ファンクションライブラリ２０６は、紙幣部１１からレスポンスを受信する際に、第二のコマレス管理テーブル２４００Ｂを参照し紙幣部１１の種類に基づき、紙幣部１１から受信するレスポンスコードを対応するファンクションライブラリのレスポンスコードへ変換する。また、ファンクションライブラリ２０６は、紙幣部１１コマンドを送信する際に、第二のコマレス管理テーブルを参照し紙幣部１１の種別に基づき、紙幣部１１へ送信するコマンドコードを対応する紙幣部１１のコマンドコードへ変換する。あるいは、ファンクションライブラリ２０６は、初期設定時に第二のコマレス管理テーブル２４００Ｂを参照し紙幣部１１の種別に基づき、接続された紙幣部１１に応じて、処理内容テーブル（図１１、１５、１８）の“モジュールへの発行コマンド”を当該紙幣部１１の種別のコマンドコード/レスポンスコードに変更してもよい。

なお、紙幣部１１の種別は、紙幣部１１又は外部からファンクションライブラリ２０６が受信し、ファンクションライブラリ２０６が設定してもよい。

制御部２０が、第二のコマレス管理テーブル２４００Ｂを利用することにより、種別の異なる紙幣部１１と接続する場合にも、その取扱いを柔軟に行うことができ、適用する機能の拡張や削除のにあわせたコマンドの追加、削除を容易に行うことができる。なお、コマンド電文/レスポンス電文のフォーマットや、他の要素に関しても、制御部は、紙幣部１１の種類毎に要素の種類を対応付けた同様の管理テーブルを有し、紙幣部１１の種類毎の要素の情報に基づき処理をできるようにしてもよい。

また、図２４Ａ、２４Ｂを別々に有することで、紙幣部１１の種類及びサービスプロバイダ２０４若しくは銀行の種類によらず、ファンクションライブラリ２０を有する制御部２０は容易に様々な種類のシステムに導入することが可能となる。

また、図２４Ａ、２４Ｂは、基本処理（例えば、入金、出金、収納（入金計数の後の収納））又は拡張処理（例えば、自動精査、ログ収集１）の両方のコマレスを変換する例を示したが、いずれか一方のコマレスを変換するものであってもよい。

［第２の実施形態］
図２５は、上述の紙幣部１１を含む複数のＡＴＭ１０が通信ネットワーク１００により接続される上位装置を含むシステムの一例を示す。上位装置としては、例えば、銀行がＡＴＭ１０の稼働等を管理する管理装置１１０や、保守会社が管理する保守装置１２０などがある。以下では、上位装置がファンクションライブラリ２０６を管理する場合について説明する。

管理装置１１０あるいは保守装置１２０等の上位装置は、記憶部（例えば、メモリ）とＣＰＵとを含む制御部１３０と、外部からの情報の入力を受け付ける操作端末１４０とを有する。上位装置の制御部１３０は、通信ネットワーク１００で接続されたＡＴＭ１０の通信制御部１０１との間で各種情報の送受信を行う。

記憶部は、ＡＴＭ１０又は紙幣部１１、紙幣識別部１１３の固有の情報２６０１（例えば、ＡＴＭシリアル番号、紙幣部シリアル番号、又は紙幣識別部シリアル番号）と、各ＡＴＭ１０のファンクションライブラリ２０６の種類を示す情報とを関連付けたファンクションライブラリ管理情報２６００を記憶している。

図２６は、ファンクションライブラリ管理情報２６００の例を示す図である。

ファンクションライブラリ管理情報２６００は、ＡＴＭ毎にファンクションライブラリを管理するための情報である。ファンクションライブラリ管理情報２６００は、ＡＴＭを識別するＡＴＭ情報２６０１と、ファンクションライブラリ２０６の種類を示す種類情報２６０２とを関連づける。ＡＴＭ情報２６０１は、ＡＴＭ毎に固有の情報であるＡＴＭＩＤ２６０３を含む。また、ＡＴＭ情報２６０１は、紙幣部を識別する情報である紙幣部シリアル番号２６０４、紙幣識別部を識別する情報である紙幣識別部シリアル番号２６０５を有しても良い。また、ファンクションライブラリ２０６の種類を示す種類情報２６０２は、例えば、ファンクションライブラリのバージョンを示すＦＬバージョン情報２６０６、ファンクションライブラリのライセンスのレベル又はライセンスの有無を示すライセンス情報２６０７、ファンクションライブラリがＡＴＭに提供する機能を示す機能種別情報２６０８（例えば、入金、収納、出金、自動精査など）、ファンクションライブラリの提供元ベンダを示す提供ベンダ情報２６０９などを含んで良い。また、ファンクションライブラリ管理情報は、ＡＴＭの設置場所を示す設置場所情報２６１０を含んでも良い。

さらに、上位装置は、ファンクションライブラリ管理情報２６００を用いて、上位装置の操作端末１４０が受け付けたファンクションライブラリ２０６の種類情報２６０２に基づき、当該ファンクションライブラリ２０６を有するＡＴＭ１０、紙幣部１１又は紙幣識別部１１３を抽出し、抽出したＡＴＭ１０、紙幣部１１、又は紙幣識別部１１３を示す情報を操作端末１４０に表示してもよい。

また、上位装置は、上位装置の操作端末１４０が受け付けたＡＴＭ１０、紙幣部１１又は紙幣識別部１１３を示す情報に基づき、当該ＡＴＭ１０のファンクションライブラリ２０６の種類情報２６０２を抽出し、抽出したファンクションライブラリ２０６の種類情報を操作端末１４０に表示してもよい。

これにより、上位装置から、ＡＴＭ１０、紙幣処理装置１１、紙幣識別部１１３とファンクションライブラリ２０６の管理が可能となる。

続いて、ファンクションライブラリ管理情報の更新に関して説明する。上位装置は、操作端末１４０から更新指示を受け付けると、ファンクションライブラリ管理情報２６００に基づき、更新指示を受け付けたＡＴＭ１０の固有の情報に対応する、当該ＡＴＭ１０にファンクションライブラリ２０６の種類情報２６０２の取得指示を送信する。

ＡＴＭ１０のファンクションライブラリ２０６は、業務アプリケーション２０３又はサービスプロバイダ２０４を経由して、当該取得指示を受信する。ファンクションライブラリ２０６は、当該指示に基づき、ストレージ２０２が記憶するファンクションライブラリ２０６の種類情報を取得し、ファンクションライブラリ２０６の種類情報を業務アプリケーション２０３又はサービスプロバイダ２０４を経由して、上位装置に送信する。

ＡＴＭ１０は、ファンクションライブラリ２０６の種類情報に加え、ＡＴＭ１０又は紙幣部１１の固有の情報も上位装置へ送信してもよい。上位装置は、ファンクションライブラリ２０６の種類情報を受信し、ファンクションライブラリ管理情報を更新する。上位装置の操作端末１４０は、更新したファンクションライブラリ管理情報を表示する。

なお、ファンクションライブラリ２０６は、上位装置から取得指示を受信したタイミングではなく、ファンクションライブラリ２０６が管理する種類情報に更新があった場合に、ファンクションライブラリ２０６の種類情報を業務アプリケーション２０３又はサービスプロバイダ２０４を経由して、上位装置に送信してもよい。ＡＴＭ１０は、ファンクションライブラリ２０６の種類情報に加え、ＡＴＭ１０又は紙幣部１１の固有の情報も上位装置へ送信してよい。

また、第１の実施形態と同様に、ファンクションライブラリ２０６は、モジュールに対して発行するコマンドの種別毎にコマンドの発行回数、コマンド発行の時刻、モジュールの実行した処理が正常に終了したか否かを示す終了情報を管理してもよい。さらに、上位装置やＡＴＭ１０の制御部２０が、以上の情報を個別に管理してもよい。これにより、モジュール提供元とモジュール提供先とでファンクションライブラリ２０６の使用状況に関し、情報の一致／不一致を確認することができる。

続いて、ファンクションライブラリ２０６の分析処理に関して説明する。ファンクションライブラリ２０６は、ファンクションライブラリ２０６を有する紙幣部１１が稼働することにより発生する紙幣部１１を構成する部品毎のログ情報を収集し、収集したログ情報に基づき、紙幣部１１の部品毎の障害発生の有無、可能性の有無、確率あるいは時期、又は部品毎の交換の要否、時期を判断する分析処理を実施する。ファンクションライブラリ２０６は、分析処理で判断した結果である分析情報をストレージ２０２に格納する。

一方、上位装置は、上位装置の操作端末１４０から分析処理の結果である分析情報の取得指示を受け付けると、取得指示を受け付けたＡＴＭ１０にファンクションライブラリ２０６の分析情報の取得指示を送信する。ファンクションライブラリ２０６は、業務アプリケーション２０３又はサービスプロバイダ２０４を経由して、当該取得指示を受信する。ファンクションライブラリ２０６は、当該取得指示に基づき、ストレージ２０２が記憶するファンクションライブラリ２０６の分析情報を取得し ファンクションライブラリ２０６の分析情報を業務アプリケーション２０３又はサービスプロバイダ２０４を経由して、上位装置に送信する。ＡＴＭ１０は、ファンクションライブラリ２０６の分析情報に加え、ＡＴＭ１０、紙幣部１１又は識別部１３の固有の情報も上位装置へ送信してもよい。上位装置は、ファンクションライブラリ２０６の分析情報を受信し、ＡＴＭ１０などの固有の情報及び分析情報を関連づけて記憶する。また、上位装置は、分析情報を操作端末１４０に表示してもよい。

上述の通り、ＡＴＭ１０のファンクションライブラリ２０６が紙幣部１１のログ情報を収集し、収集したログ情報に基づき紙幣部１１の状態を分析し、分析した結果を上位装置に送信するため、上位装置が、ログ情報を収集して分析する場合に比較し、上位装置の資源及び上位装置とＡＴＭ１０を接続する通信回線の資源などを有効利用することが可能となる。

以降では、分析処理についてより詳細に説明する。
図２７は、紙幣部１１を構成する部品毎のログ情報２７００の例を示す図である。
ログ情報は、ファンクションライブラリ２０６から受信したコマンドの種類であるコマンド種別２７０１（コマンドコードであってもよい）と、当該コマンドを受信した時間である受信日時２７０２とを有するものであってよい。また、ログ情報は、部品の稼働により紙幣部１１が取得した稼働値２７０３と、紙幣部１１が当該値を取得した日時を示す日時２７０４とを、部品毎に有するものであってよい。また、ログ情報には、部品の種類を示す部品種別２７０５と、紙幣部１１内での部品毎に固有な又はある部品種別の中でも配置される場所により固有な部品番号を示す部品番号情報２７０６を有してもよい。

なお、部品の種類毎に、対応するコマンド種別を有し、ファンクションライブラリ２０６が、処理内容テーブル（図１１、図１８）に基づき、どの種別の部品を取得するかを決定していてもよい。例えば、ログ収集１は、センサの値を収集し、ログ収集２は、ローラの値を取得するように設定してもよい。

ここで、部品は、例えば、光学センサ、磁気センサなどを含む検知部、ローラ、ベルトなどを含む搬送部などを含む。また、ログ情報は、例えば、紙幣部１１が有する複数の検知部、複数の搬送部のそれぞれが生成する情報であってよい。検知部のログ情報としては、例えば、センサ出力、検知レベルを含んでよい。また、搬送部のログ情報としては、例えば、搬送スキューなどの搬送エラー情報などを含んでよい。

続いて、収集したログ情報に基づき、ＡＴＭ１０の保守に関わる保守情報を生成する分析処理について説明する。ファンクションライブラリ２０６は、収集又は格納したログ情報に基づき、紙幣部１１の部品の現在又は最新の稼働値２７０３を示す実績データ、及び当該部品の過去の稼働値に基づく情報であって稼働値２７０３の傾向を示す統計データ（例えば、稼働値の時系列変化を示す情報）を生成する。続いて、ファンクションライブラリ２０６は、生成した統計データ及び実績データに基づき、障害発生の有無、障害発生の可能性の有無、障害発生の確率あるいは時期、又は部品毎の保守・交換の要否、時期を判断する分析処理を実施する。

図２８は、ファンクションライブラリ２０６が、種々の分析処理を実行する際に利用するログ種別を示す分析ログ情報テーブル２８００である。分析ログ情報テーブル２８００は、分析処理の種類を示す処理種別２８０１と、当該分析処理で利用するログの種類であるログ種別２８０、当該分析処理で利用するログの収集元である部品を示す情報である部品番号２８０３を関連づけたテーブルである。分析ログ情報テーブル２８００で指定される情報によって、分析処理を実行することができる。

図２９は、交換情報管理テーブル２９００の例を示す図である。
交換情報管理テーブル２９００は、紙幣部１１若しくは紙幣部１１を構成する部品を交換した時間を示す交換時刻２９０１、紙幣部１１を識別する情報である紙幣部シリアル番号２９０２、交換された部品を示す部品番号２９０３、及び交換した理由などを示す交換内容の情報を含んで良い。交換情報管理テーブル２９００は、部品番号２９０３と交換時刻２９０１とを関連付ける情報であり、部品番号２９０３の交換時刻２９０１を決定できるものであればよい。

ファンクションライブラリ２０６は、紙幣部１１又は部品の交換を検知すると、交換情報管理テーブル２９００の情報を更新する。より詳細には、ファンクションライブラリ２０６は、紙幣部１１から受信した情報に基づき、交換された部品番号２９０３を特定し、交換を実施した保守員等に交換内容２９０４を選択させる。また、交換情報管理テーブル２９００は、管理装置１１０の表示画面等に表示してもよく、紙幣部シリアル番号２９０２や交換箇所等、任意の条件でソートすることにより、管理者が、把握したい紙幣部１１の交換情報を即時に知ることができるようにしてもよい。

図３０は、統計データ生成処理のフローの一例を示す。
ファンクションライブラリ２０６は、交換情報管理テーブル２９００と分析ログ情報テーブル２８００を用いて、統計データを生成する際に、紙幣部１１又は部品の交換を考慮した統計データを生成してもよい。

以下詳細にファンクションライブラリ２０６の実施する統計データ生成処理について、説明する。
ファンクションライブラリ２０６は、分析ログ情報テーブル２８００に基づき、分析処理の処理種別に応じて、当該分析で利用するログ種別のログを生成する部品番号を特定する（Ｓ３０００）。続いて、ファンクションライブラリ２０６は、交換情報管理テーブル２９００に基づき、特定した部品番号の交換履歴の有無を判断する（Ｓ３００２）。ここで、交換履歴がない場合（Ｓ３００２：無）、部品毎に定めた所定期間のログ情報に基づき統計データを生成する（Ｓ３００８）。一方、交換履歴がある場合（Ｓ３００２：有）、交換情報管理テーブル２９００に基づき、交換時刻を取得する（Ｓ３００４）。ファンクションライブラリ２０６は、取得した交換時刻に基づき、統計データを生成する（Ｓ３００６）。

より詳細には、ファンクションライブラリ２０６は、取得した交換時刻よりも前のログ情報と、取得した交換時刻以後のログ情報とを区別して、統計データを生成する。言い換えると、ファンクションライブラリ２０６は、交換時刻よりも前のログ情報と交換時刻後のログ情報とを連続したデータとしては扱わない。例えば、交換時刻前後で２つの統計データを生成、又は交換時刻よりも前のログ情報と交換時刻以後のログ情報を稼働時間帯で対応させて１つの統計データを生成してもよい。以上のように、交換情報管理テーブル２９００と分析ログ情報テーブル２８００とを有することにより、分析処理に利用される部品に応じて、適切な統計データを生成することが可能となる。

なお、図１１に示すコマンドシーケンステーブルにおいては動作結果が正常か異常かで次に実行するコマンドのシーケンス番号を決定したが、モジュールからのレスポンス電文に含まれる情報、たとえば紙幣の残留有無など直近の動作結果にともなう各種情報、過去に実行した動作結果による情報、記憶済の各種設定情報等を元にシーケンス番号を切り替える、あるいはテーブルそのものを別に定義した新たなテーブルに切り替えることで多様かつ複数機能を切り替える仕組みを実現することが可能となる。

さらなる応用例として、図９に示したライセンス許可情報テーブルに装置別で使用するコマンドシーケンス定義テーブルを登録することで、機材別で使用可能な範囲や機能を切り替えることも可能となる。この方法を応用することで、ライセンス許可情報テーブルを更新することで、拡張機能を有効にするといった機能実現が可能となる。

なお、図９では、ライセンス許可情報を紙幣部１１の型式によって管理する例を示したが、仮想ＩＤを利用して管理するようにしてもよい。管理装置１３０等の上位装置が、仮想ＩＤを管理することにより、紙幣部１１の交換等により型式変更等が生じた場合にも、仮想ＩＤにより容易に管理することができる。

電文フォーマットについては、サービスプロバイダーファンクションライブラリ間の電文フォーマットと、ファンクションライブラリーモジュール間の電文フォーマットは、本提案目的の一つであるモジュール使いこなし技術の隠蔽化により異なるフォーマットにすることが望ましい。しかしながら、ファンクションライブラリがない状態で装置が構築済であるところにファンクションライブラリの組み込みを行う場合は、同じフォーマットとすることで組み込み設計の容易化が可能となる。この場合、モジュール使いこなし技術の隠蔽化を行うために、既存開示コマンドの情報を一部変更する、あるいは非開示コマンドを追加することで機能制限を設けるなどにより目的を達することができる。

また、既存電文フォーマットを使用する場合であっても電文内に含まれる情報を追加、たとえばモジュールが通知するエラーコードだけでなく動作状況に応じてファンクションライブラリが生成するエラーコードの通知など新たな情報を付加することで付加価値を高めることも可能である。

なお、本説明は、上記実施例そのままに限定されるものではなく、例えば、図１０、図１６、図２０、図２１の各フローを適宜組み合わせて実行する等、実施段階ではその要旨に逸脱しない範囲で構成要素や処理のフローチャートの一部または全部を、ＡＴＭが使用される環境に応じて組み合わせて実行することができる。

また、情報の保持方法として、図８、９、１１〜１５、１７，１８、２０、２２、２３、２４、２６、２８、２９では、テーブルの形式で保持する例を示したが、それぞれの情報を関連付けて記憶する方法であれば、テーブルの形式に限らない。

また、図１１、１５、１８では、“ＳＰからの受信コマンド”として、コマンド種別を記載しているが、制御部２０の管理状態に応じて、ファンクションライブラリがコマンドを識別するコマンド情報（例えば、ファンクションライブラリが管理するコマンドコード、又はサービスプロバイダが管理するコマンドコード）であってもよい。また、“モジュールへの発行コマンド”として、コマンド種別を記載しているが、制御部２０の管理状態に応じて、ファンクションライブラリがコマンドを識別するコマンド情報（例えば、ファンクションライブラリが管理するコマンドコード、又はモジュールが管理するコマンドコード）であってもよい。

また、自動取引装置を実施形態として記載したが、情報を有する媒体から情報を取得する媒体取扱装置であってもよい。

また、媒体取扱装置の実施する取引処理（基本処理）は、入金、出金、振替、振込などの取引を実施するために、対象媒体（例えば、紙幣、カード、明細票、通帳、硬貨）から情報（金額、口座情報）を取得する動作を、処理部（例えば、紙幣部、カード・明細票部、通帳部、硬貨部）が実施する処理であってよい。例えば、取引処理に伴い、各処理部に取り扱う媒体を搬送させる又は読み取る処理などを実施させる処理であってよい。また、紙幣取引レスポンスなどの取引レスポンスは、取引コマンドに基づき、媒体から取得した取引で使用する情報（例えば、当該取引で計数した金種毎の紙幣枚数、読み取ったカード番号、読み取った通帳番号、計数した金種毎の硬貨枚数）を返信するレスポンスであってよい。

また、取引処理は、利用者の口座を特定する情報又は特定された口座に反映される情報を取得する処理であってもよい。

また、ソータの場合は、取引との概念がないため、紙幣部の投入口に投入された紙幣の計数結果（例えば、紙幣種類毎の枚数、紙幣画像）を紙幣部が取得する処理が、基本処理に相当する。一方、基本処理では用いない情報を取得する処理、基本処理又は拡張処理により取得した情報に基づき、ファンクションライブラリが実施する又は紙幣部に実施させる処理が拡張処理となる。このため、当該計数結果を紙幣部が取得する処理を紙幣部に実施させる（実施可能な）コマンドをサービスプロバイダが生成し、拡張処理を紙幣部に実施させる（実施可能な）コマンドをファンクションライブラリが生成するものであってよい。なお、上述の通り、処理部の種類により、基本処理と拡張処理が変わることがあってもよい。

以上の実施形態では、少なくとも以下のいずれか一つ又は複数の特徴を有する。これらの特徴を有することにより、上述した効果を有する。

（１）外部から投入された媒体の情報に基づき取引を行う媒体取扱装置であって、投入された媒体から取引で用いる情報を取得する処理部と、処理部が実施可能なコマンドを生成する制御部を有し、制御部は、取引で用いる情報を取得する基本処理（例えば、取引処理）を処理部が実施可能なコマンドである基本処理コマンドを生成するサービスプロバイダと、基本処理とは異なる拡張処理を処理部が実施可能なコマンドである拡張処理コマンドを生成するファンクションライブラリとを有する。

（１）-２ファンクションライブラリは、基本処理コマンドをサービスプロバイダから受信し、変換することなく（基本処理コマンドと同一のコマンドを）、処理部に送信する。

（２）外部から投入された媒体の情報を取得する処理部を有する媒体取扱装置であって、処理部が実施可能な基本処理コマンド又は拡張処理コマンドを生成する制御部を有し、制御部は、処理部の種類毎に対応した基本処理コマンド又は拡張処理コマンドを管理する第二のコマレス管理情報を有し、第二のコマレス管理情報に基づき、処理部の種類に対応した第一のコマンド又は第二のコマンドを生成することを特徴とする。

（３）外部から投入された媒体の情報を取得する処理部を有する媒体取扱装置であって、外部又はサービスプロバイダに拡張処理の結果である拡張処理のレスポンスを送信するファンクションライブラリを有する制御部を備え、制御部は、銀行又はサービスプロバイダの種類毎に対応した拡張処理のレスポンスを管理する第一のコマレス管理情報を有し、第一のコマレス管理情報に基づき、銀行又はサービスプロバイダの種類に対応した拡張処理のレスポンスを生成する。

（４）媒体の有する情報を使用する処理である媒体処理を行う媒体取扱装置であって、媒体から情報を取得するモジュールと、モジュールと接続され、外部からの取引処理を開始させる指示に基づき、第一のコマンドを生成するサービスプロバイダと、サービスプロバイダから受信した第一のコマンドに基づき、モジュールに送信する第二のコマンドを生成するファンクションライブラリとを有する制御部とを備え、ファンクションライブラリは、一の第二のコマンドに対するモジュールからの応答である一の第二のレスポンスの情報に基づき、次にモジュールに送信する他の第二のコマンドを決定する。

（４）-１制御部は、一の第二のレスポンスの情報毎に、次に生成する他の第二のコマンドの情報を記憶した処理内容情報を有し、ファンクションライブラリは、処理内容情報に基づき、モジュールから受信した一の第二のレスポンスの情報に対応する他の第二のコマンドの情報を含む他の第二のコマンドを送信してもよい。

（４）-２ファンクションライブラリは、一の第一のコマンドに対して、複数の第二のコマンドを生成し、それぞれの第二のコマンドに対応する第二のレスポンスを全て受信した後に、一の第一のコマンドに対する応答である一の第一のレスポンスをサービスプロバイダに送信してもよい。

（５）媒体の有する情報を使用する処理である媒体処理を行う媒体取扱装置であって、媒体から情報を取得するモジュールと、モジュールと接続され、外部からの取引処理を開始させる指示に基づき、第一のコマンドを生成するサービスプロバイダと、サービスプロバイダから受信した第一のコマンドに基づき、モジュールに第二のコマンドを送信するファンクションライブラリとを有する制御部とを備え、ファンクションライブラリは、取引処理では使用しない情報（例えば、状態情報）をモジュールに取得させる情報取得コマンドを生成し、取引処理で使用する情報をモジュールに媒体から取得させる取引コマンド及び前記情報取得コマンドを第二のコマンドとしてモジュールに送信する。

（５）-１ファンクションライブラリは、取引コマンドに対するモジュールからの応答である取引レスポンスの内容（一の第二のレスポンスの情報）に基づき、情報取得コマンドの種類（他の第二のコマンドの情報）を決定してもよい。

（５）-２ファンクションライブラリは、一の情報取得コマンドに対するモジュールからの応答である一の情報取得レスポンスに基づき、次の情報取得コマンドを生成してもよい。

（５）-３モジュールは、取引コマンドに対するモジュールからの応答である取引レスポンス（一の第二のレスポンスの情報）にモジュールの状態を示す状態情報を含め、ファンクションライブラリは、取引レスポンスを受信し、取引レスポンスに含まれた状態情報に基づき、次に生成する第二のコマンド（他の第二のコマンドの情報）を決定してもよい。

（６）ファンクションライブラリは、モジュールの種類を示す情報と処理内容情報とを対応づけた参照先管理情報を有し、参照先管理情報に基づき、モジュールから取得したモジュールの種類を示す情報に対応した処理内容情報を決定してもよい。

（７）媒体を用いて取引を実行する処理部を有する自動取引装置であって、取引の指示に基づいて、取引に使用する情報を処理部から取得する第１のコマンドを生成する第１のコマンド提供部と、第１のコマンドに基づき処理部の実行する処理を指定し、第１のコマンドとは異なるコマンドに変換される第２のコマンドを生成する第２のコマンド提供部とを含む制御部を有する。

（７）-１第２のコマンド提供部は、第２のコマンドを指定する処理内容情報を有し、処理部から第１のコマンドに対する応答である第１のレスポンスに基づいて処理内容情報により第２のコマンドを決定する。

（７）-２第２のコマンド提供部は、第１のコマンド提供部から第１のコマンドを受信し、第１のコマンドのコマンドコードを変換することなく、第１のコマンドを処理部に送信する。

なお、実施形態において各処理を実現するためのプログラムは、電気・電子及び／又は磁気的な非一時的（ｎｏｎ‐ｔｒａｎｓｉｔｏｒｙ）な記録媒体に格納可能である。即ち、ファンクションライブラリ２０６の機能を実現するためのプログラムを、持ち運び可能な又はサーバなどの上位装置の非一時的な記録媒体に格納し、ＡＴＭ１０にインストール（格納）することで、その機能を実現させるようにしても良い。
以上、図面を用いて詳細に説明したが、本発明は上述の種々の例に限定されるものではなく、その趣旨を逸脱しない範囲で、種々の変更が可能である。

１０ ＡＴＭ
１１ 紙幣部
１１３ 識別部
１２ カード・明細票部
１３ 通帳部
１４ 硬貨部
１５ 操作部
１６ 係員操作部
２０１ オペレーティングシステム
２０２ ストレージ
２０３ 業務アプリケーション
２０４ サービスプロバイダ
２０６ ファンクションライブラリ

Claims (11)

1. 媒体を用いて取引を実行する処理部を有する自動取引装置であって、
   業務アプリケーションを介した前記取引の指示に基づいて、前記処理部が前記取引に使用する情報を取得する第１のコマンドを生成する第１のコマンド提供部と、前記第１のコマンドに基づき前記処理部の実行する処理を指定し、前記第１のコマンドとは異なるコマンドであり、前記処理部が前記指定する処理を実施する第２のコマンドを生成する第２のコマンド提供部とを含む制御部を有し、
   前記第２のコマンド提供部は、前記処理部から前記第１のコマンドに対する応答である第１のレスポンスに応じて定められた前記第２のコマンドを指定する処理内容情報を有し、
   前記第１のレスポンスと前記処理内容情報とに基づいて前記第２のコマンドを決定することを特徴とする自動取引装置。
2. 前記第２のコマンド提供部は、前記第１のコマンド提供部から前記第１のコマンドを受信し、前記第１のコマンドのコマンドコードを変換することなく、前記第１のコマンドを前記処理部に送信することを特徴とする請求項１に記載の自動取引装置。
3. 前記処理部は、前記第１のコマンドに応じて実行する取引処理と、前記第２のコマンドに応じて実行する拡張処理とを実行し、
   前記処理内容情報には、前記処理部に実行される前記取引処理及び前記拡張処理の情報が複数含まれ、前記処理部が複数のうちいずれの取引処理又は拡張処理を実行するかを指定する許可区分情報がさらに含まれることを特徴とする請求項２に記載の自動取引装置。
4. 前記媒体を収納する収納部をさらに有し、
   前記取引処理は、少なくとも前記媒体の計数を行う処理又は前記媒体から前記取引に利用する情報を取得する処理を含み、
   前記拡張処理は、少なくとも前記処理部の状態情報の取得処理、前記処理部を動作させる動作処理又は前記取得処理により取得した情報に基づき分析を行う分析処理を含むことを特徴とする請求項３に記載の自動取引装置。
5. 前記取引が、現金を用いて実行される入金取引又は出金取引である場合、
   前記処理部は、前記第１のコマンドに基づいて前記現金を搬送させて前記入金取引又は出金取引を実行し、
   前記第２のコマンド提供部は、前記第１のレスポンスである前記入金取引又は前記出金取引の結果に基づいて、前記処理部の状態情報の収集を実行することを特徴とする請求項４に記載の自動取引装置。
6. 前記処理部は、一又は複数の構成部を有し、
   前記一又は複数の構成部は、前記処理部が前記第２のコマンド提供部から受信する前記第１のコマンドに基づいて前記取引処理を実行すると共に、前記第２のコマンド提供部から直接受信する前記第２のコマンドに基づいて前記拡張処理を実行することを特徴とする請求項５に記載の自動取引装置。
7. 媒体を用いて取引を実行する処理部を有する複数の自動取引装置と、前記複数の自動取引装置に接続される上位装置とからなる自動取引システムであって、
   前記複数の自動取引装置の各々は、業務アプリケーションを介した前記取引の指示に基づいて、前記取引に使用する情報を前記処理部から取得する第１のコマンドを生成する第１のコマンド提供部と、前記第１のコマンドに基づき前記処理部の実行する処理を指定し、前記第１のコマンドとは異なるコマンドに変換される第２のコマンドを生成する第２のコマンド提供部とを有する制御部を有し、
   前記第２のコマンド提供部は、前記処理部から前記第１のコマンドに対する応答である第１のレスポンスに応じて定められた前記第２のコマンドを指定する処理内容情報を有し、
   前記第１のレスポンスと前記処理内容情報とに基づいて前記第２のコマンドを決定し、
   前記上位装置は、前記複数の自動取引装置の各々の前記第２のコマンド提供部を管理するコマンド管理情報を有することを特徴とする自動取引システム。
8. 前記複数の自動取引装置の各々の前記処理部は、前記第１のコマンドに応じて実行する取引処理と、前記第２のコマンドに応じて実行する拡張処理とを実行し、
   前記処理内容情報には、前記処理部に実行される前記取引処理及び前記拡張処理の情報が複数含まれ、前記処理部が複数のうちいずれの取引処理又は拡張処理を実行するかを指定する許可区分情報がさらに含まれ、
   前記コマンド管理情報には、前記複数の自動取引装置の各々の許可区分情報が含まれ、
   前記複数の自動取引装置は、前記許可区分情報に応じて実行する前記取引処理又は前記拡張処理を決定することを特徴とする請求項７に記載の自動取引システム。
9. 前記処理部は、複数の部品から構成され、
   前記第２のコマンド提供部は、前記第２のコマンドにより前記複数の部品の各々の稼働情報を取得することを特徴とする請求項８に記載の自動取引システム。
10. 前記稼働情報は、少なくとも前記複数の部品の各々の交換又は保守の実行の有無を示す交換保守情報と交換又は保守を実行した時刻情報とを含み、
    前記第２のコマンド提供部は、前記交換保守情報と前記時刻情報とに基づいて取得した前記稼働情報から分析対象とする対象データを決定し、
    前記上位装置は、前記対象データを用いて統計処理を実行することを特徴とする請求項９に記載の自動取引システム。
11. 媒体を用いて取引処理を実行する処理部と、業務アプリケーションを介した前記取引処理の指示に基づいて、前記処理部が前記取引に使用する情報を取得する第１のコマンドを送信する制御部とを有する自動取引装置に、
    前記第１のコマンドに基づき前記処理部の実行する処理を指定し、前記第１のコマンドとは異なるコマンドであり、前記処理部が前記指定する処理を実施する第２のコマンドを送信し、
    前記第２のコマンドを生成する第２のコマンド提供部は、前記処理部から前記第１のコマンドに対する応答である第１のレスポンスに応じて定められた前記第２のコマンドを指定する処理内容情報と前記第１のレスポンスとに基づいて前記第２のコマンドを決定するステップを実現させるプログラムを格納する非一時的記録媒体。

Images