(57)【要約】【課題】単純なディスプレイやキーボードやプリンタ等の汎用デバイスに利用することができるが、現金入出金機や通帳プリンタ等の金融デバイスではその動作の複雑さゆえに制御の交信の情報量が多く、特許文献２の如きシステム構成では金融デバイスの制御に対応しきれない。【解決手段】上記課題を解決する手段として、金融機関の営業店に設置され、取引の要求を入力する複数の営業店端末（４及び５）と、営業店と回線を介して接続するセンタに設置され、営業店端末で入力した取引の要求に基づいてホストと交信するアプリケーションサーバ（１）と、営業店に設置され、ホストとの交信に対応するアプリケーションサーバからの命令に基づいて、現金入出金機（８）や通帳プリンタ（９）を制御する機能を有するデバイス制御サーバ（３）とを有する営業店システムを採用する。【選択図】図１
2006092056.tif 000002
【特許請求の範囲】
【請求項１】
金融機関の営業店に設置され、取引の要求を入力する複数の営業店端末と、
前記営業店と回線を介して接続するセンタに設置され、前記営業店端末で入力した取引の要求に基づいてホストと交信する第１のサーバと、
前記営業店に設置され、前記ホストとの交信に対応する前記第１のサーバからの命令に基づいて、金融デバイスを制御するデバイス制御プログラムを有する第２のサーバとを有することを特徴とする営業店システム。
【請求項２】
請求項１であって、
前記複数の営業店端末は、入力画面情報を有する第１のクライアントと、前記入力画面情報を有しない第２のクライアントとを含み、
前記第１のサーバは、前記営業店端末へ命令を発信するとき、前記第１のクライアントへの命令か前記第２のクライアントへの命令かを判断して前記第２のクライアントの命令と判断したときには入力画面情報を付加して発信するプログラムをさらに有することを特徴とする営業店システム。
【請求項３】
請求項１であって、
前記複数の営業店端末は、前記デバイス制御プログラムを有する第１のクライアントと、前記デバイス制御プログラムを有しない第２のクライアントとを含み、
前記第１のサーバは、前記第１のクライアントで入力した取引の要求に基づくデバイス宛の命令を前記第１のクライアントに発信し、前記第２のクライアントで入力した取引の要求に基づくデバイス宛の命令を前記第２のサーバに発信するよう振り分けるプログラムをさらに有することを特徴とする営業店システム。
【請求項４】
請求項２又は３であって、
前記第２のクライアントは、帳票の画像を取得する画像取得部と回線を介して接続し、当該画像取得部で入力した画像を文字認識するプログラムをさらに有することを特徴とする営業店システム。
【請求項５】
請求項１であって、
前記営業店端末は、前記取引の要求の入力に伴って前記現金入出金機及び前記通帳プリンタの少なくとも一方の占有の要求を入力し、
前記営業店端末で前記占有の要求の入力があったとき、前記第２のサーバは、当該現金入出金機及び当該通帳プリンタの少なくとも一方を当該営業店端末の占有に設定し、当該占有の要求に伴って要求を入力した取引が完了したとき、占有の設定を解除することを特徴とする営業店システム。
【請求項６】
営業店端末から取引の要求を受信し、当該受信に基づいて対応する取引のフローを呼び出し、当該取引のフローに基づいて複数のコンポーネントを呼び出して実行させるフロー制御プログラムを有する第１のサーバと、
前記受信に対応する前記第１のサーバの命令に基づいて、現金を入出金する現金入出金機及び通帳を搬送して印字する通帳プリンタの少なくとも一方を制御するデバイス制御プログラムを有する第２のサーバとを有することを特徴とする営業店システム。
【請求項７】
請求項６であって、
前記第１のサーバは、前記営業店端末が設置された営業店と通信回線を介して接続するセンタに設置され、
前記第２のサーバは、前記営業店に設置されていることを特徴とする営業店システム。
【請求項８】
請求項６であって、
前記第１のサーバは、前記フロー制御プログラムから前記営業店端末へ命令を発信するとき、当該営業店端末が入力画面情報を有する第１のクライアントであるか前記入力画面情報を有しない第２のクライアントであるかを判断し、前記第２のクライアントであると判断したときには入力画面情報を付加して発信するプログラムをさらに有することを特徴とする営業店システム。
【請求項９】
請求項６であって、
前記第１のサーバは、前記営業店端末が、前記デバイス制御プログラムを有する第１のクライアントであるか前記デバイス制御プログラムを有しない第２のクライアントであるかを判断し、前記第１のクライアントであると判断したとき、デバイス宛の命令を前記第１のクライアントに発信し、前記第２のクライアントであると判断したとき、デバイス宛の命令を前記第２のサーバに発信するプログラムをさらに有することを特徴とする営業店システム。
【請求項１０】
営業店に設置され、取引の要求を入力する複数の営業店端末と、
前記営業店と回線を介して接続するセンタに設置され、前記営業店端末で入力した取引の要求に基づいて対応する取引のフローを呼び出し、当該取引のフローに基づいて複数のコンポーネントを呼び出して実行させるフロー制御プログラムを有する第１のサーバと、
前記営業店端末での前記要求に対応する前記第１のサーバの命令に基づいて、現金を入出金する現金入出金機及び通帳を搬送して印字する通帳プリンタの少なくとも一方を制御するデバイス制御プログラムを有する第２のサーバとを有することを特徴とする営業店システム。
【請求項１１】
請求項１であって、
前記第２のサーバは、前記営業店に設置されていることを特徴とする営業店システム。
【請求項１２】
入力画面情報を有する第１のクライアントと、
前記入力画面情報を有しない第２のクライアントと、
前記第１のクライアントへの命令か前記第２のクライアントへの命令かを判断して前記第２のクライアントの命令と判断したときには入力画面情報を付加して発信するプログラムを有する第１のサーバとを含むことを特徴とする営業店システム。
【請求項１３】
請求項１２であって、
前記第１のサーバは、前記第１のクライアントと前記第２のクライアントの少なくとも一方が設置された営業店と通信回線を介して接続するセンタに設置されていることを特徴とする営業店システム。
【請求項１４】
営業店端末へ命令を発信するとき、当該営業店端末が入力画面情報を有する第１のクライアントであるか前記入力画面情報を有しない第２のクライアントであるかを判断し、前記第２のクライアントであると判断したときには入力画面情報をファイルから取得して発信するサーバ。
【請求項１５】
画面定義情報を有する第１のクライアントと当該画面定義情報を有しない第２のクライアントとに通信回線を介して接続するサーバが実行する取引処理実行方法であって、
前記第１のクライアント又は前記第２のクライアントから取引処理の要求を受信し、
取引処理の要求元を記憶し、
受信した取引処理の要求に対応する命令を複数のデバイスへ通信回線を介して送信し、
送信した複数の前記デバイスから制御完了通知を受信すると、記憶した取引処理の要求元が前記第２のクライアントであるとき、画面情報を付加して当該第２のクライアントに送信する。
【請求項１６】
現金を入出金する現金入出金機及び通帳を搬送して印字する通帳プリンタの少なくとも一方を制御するデバイス制御プログラムを有する第２のサーバと、
前記デバイス制御プログラムを有する第１のクライアントと、
前記デバイス制御プログラムを有しない第２のクライアントと、
現金入出金機及び通帳プリンタの少なくとも一方を利用する取引において、前記第１のクライアントであるか前記第２のクライアントであるかを判断し、前記第１のクライアントであると判断したとき、当該取引におけるデバイス宛の命令を前記第１のクライアントに発信し、前記第２のクライアントであると判断したとき、当該取引におけるデバイス宛の命令を前記第２のサーバに発信する第１のサーバとを含むことを特徴とする営業店システム。
【請求項１７】
請求項１６であって、
前記第２のサーバと、前記第１のクライアントと、前記第２のクライアントは、営業店に設置され、
前記第１のサーバは、前記営業店と通信回線を介して接続するセンタに設置されていることを特徴とする営業店システム。
【請求項１８】
当該営業店端末が、入出金する現金入出金機及び通帳を搬送して印字する通帳プリンタの少なくとも一方を制御するデバイス制御プログラムを有する第１のクライアントと当該デバイス制御プログラムを有しない第２のクライアントとに通信回線を介して接続するサーバが実行する取引処理実行方法であって、
命令を発信するとき、宛先が、前記第１のクライアントであるか前記第２のクライアントであるかを判断し、
前記第１のクライアントであると判断したとき、当該取引におけるデバイス宛の命令を前記第１のクライアントに発信し、前記第２のクライアントであると判断したとき、当該取引におけるデバイス宛の命令を前記デバイス制御プログラムを有する第２のサーバに通信回線を介して発信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、金融機関の営業店等で利用されるシステムに関するものである。
【背景技術】
【０００２】
金融機関の営業店では、特許文献１に開示されるような係員用端末が利用されている。この係員用端末は、営業店の窓口カウンタに設置され、現金取扱装置や通帳記帳用プリンタ等の金融デバイスを制御する機能を有している。
【０００３】
また、端末装置の小型化と増減の容易化とを図るため、特許文献２は、ディスプレイやプリンタからなる複数の端末部を、回線で接続された主制御部で見かけ上同時並行処理することを開示している。
【０００４】
【特許文献１】特開平５−２０４５８５号公報
【特許文献２】特開平９−１６０８９４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上記特許文献１の技術によれば、現金入出金装置や通帳プリンタ等の金融デバイスを端末によって全て制御しなければならないため営業店端末（Ｆａｔクライアント）にコストがかかる。
【０００６】
上記特許文献２の技術では、単純なディスプレイやキーボードやプリンタ等の汎用デバイスに利用することができるが、現金入出金機や通帳プリンタ等の金融デバイスではその動作の複雑さゆえに制御の交信の情報量が多く、特許文献２のようなシステム構成では金融デバイスの制御に対応しきれない。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、例えば以下の手段を採用する。
【０００８】
金融機関の営業店に設置され、取引の要求を入力する複数の営業店端末と、営業店と回線を介して接続するセンタに設置され、営業店端末で入力した取引の要求に基づいてホストと交信するアプリケーションサーバと、営業店に設置され、ホストとの交信に対応するアプリケーションサーバからの命令に基づいて、金融デバイスを制御するデバイス制御機能を有するデバイス制御サーバとを有する営業店システム。
【０００９】
特定画面定義情報を有するＲｉｃｈクライアントと、特定画面定義情報を有しないＴｈｉｎクライアントと、Ｒｉｃｈクライアントへの命令かＴｈｉｎクライアントへの命令かを判断してＴｈｉｎクライアントの命令と判断したときには特定画面情報を付加して発信する機能を有するアプリケーションサーバとを含む営業店システム。
【００１０】
現金を入出金する現金入出金機及び通帳を搬送して印字する通帳プリンタの少なくとも一方を制御するデバイス制御機能を有するデバイス制御サーバと、デバイス制御機能を有するＲｉｃｈクライアントと、デバイス制御機能を有しないＴｈｉｎクライアントと、現金入出金機及び通帳プリンタの少なくとも一方を利用する取引において、ＲｉｃｈクライアントであるかＴｈｉｎクライアントであるかを判断し、Ｒｉｃｈクライアントであると判断したとき、その取引におけるデバイス宛の命令をＲｉｃｈクライアントに発信し、Ｔｈｉｎクライアントであると判断したとき、その取引におけるデバイス宛の命令をデバイス制御サーバに発信するアプリケーションサーバとを含む営業店システム。
【発明の効果】
【００１１】
本発明によれば、複雑な金融デバイスを含む営業店システムの自由度又はコストダウンとの向上につながる。
【発明を実施するための最良の形態】
【００１２】
金融機関で利用される形態を例として説明する。なお、図１〜図５で説明するハードウェア構成及びソフトウェア構成及びそれらの機能は、一例でありすべての構成及びその機能を備えている必要はない。構成・機能を備えることにより作用や効果が記載の通り高まる。
【００１３】
図１は、金融機関のセンタ及び営業店それぞれの構成の概略を示すブロック図である。
【００１４】
センタには、ホストコンピュータ２（ホスト２）とアプリケーションサーバ１（ＡＰサーバ１）とがある。ホスト２は、金融機関の基幹であり、例えば預金取引、引出取引、振込取引等の勘定系取引で生じる預金高の増減（収支）を管理する。一般的には、メインフレームで構成されることが多いが、サーバであってもよい。ＡＰサーバ１については、後述する。
【００１５】
営業店には、営業店の窓口（カウンタ）でテラーが操作する複数のＴｈｉｎクライアント４及び／又はＲｉｃｈクライアント５と、液晶等でテラーに対して入力画面を表示するディスプレイ６と、ディスプレイ６の入力画面に対しデータを入力する入力装置（キーボード７、マウス、タッチパネル等）と、顧客からテラーが受け取った現金を入金したり、顧客へ受け渡す現金を出金したりする現金入出金機８と、通帳を搬送して印字ヘッドで印字し、場合によっては通帳の頁をめくる通帳プリンタ９と、振込伝票や預入伝票等の帳票のイメージを取得する画像取得装置（スキャナ等）１０と、デバイス制御サーバ３とがある。を具備してもよい。Ｔｈｉｎクライアント４であっても、スキャナは、Ｔｈｉｎクライアント４に接続し、スキャナで取得した画像を認識する文字認識ソフトも、Ｔｈｉｎクライアント４に格納しておき実行させることが望ましい。なぜなら、画像データの容量が大きいため、文字認識処理を行うためにＡＰサーバ１にデータ送信すると、ネットワークに負荷がかかってしまい、クライアントで処理した方が高速化できるためである。同じ理由で、ＡＰサーバ１に文字認識ソフトを置くよりは、デバイス制御サーバ３に文字認識ソフトを置く方が望ましい。
【００１６】
現金入出金機８は、入出金口にシャッタを有し、現金（紙幣）を繰り出して搬送するローラ・ベルト・モータや、現金の金種や真偽を鑑別する鑑別装置や、現金を収納する収納ボックス等を有する。通帳プリンタ９は、通帳を搬送するためのローラ・モータや、通帳に貼り付けられた磁気ストライプの磁気情報を読み書きする磁気リーダライタや、通帳の印字済み行を光学的に読み取るスキャナや、通帳に印字する印字ヘッドや、通帳の頁をめくる頁めくりローラを有する。なお、通帳プリンタ９は、上部に帳票を挿入する上インサータを有し、下部に通常を挿入する下インサータを有し、それぞれ挿入された媒体を搬送して印字等する。
【００１７】
現金入出金機８や通帳プリンタ９のように、通常のオフィスでは使用されず金融機関等で特に利用される機器（デバイス）を金融デバイスとよぶ。一般のレーザプリンタやインクジェットプリンタ等は、金融デバイスではない。金融デバイスには、他に例えば、口座を有する顧客（エンドユーザ）が操作する自動取引装置（現金入出金機８とは異なる。いわゆるＡＴＭ）、営業店へ来店した顧客を受け付けて窓口へ案内する順番を印字した紙を出力等する受付端末、顧客の操作を受けて例えばローン等のシミュレーションをするロビー端末、営業店端末に備えられた現金入出金機８とは別に営業店内の現金を管理する元方機、通帳を発行する通帳発行機（ＰＩＭ）、小切手等の債権を発行する債権発行機（ＢＩＭ）、カードにエンボス文字等を印字して発行するカード発行機（ＡＣＭ）、振込券を発行する振込券発行装置（ＴＴＣＭ）を含んでもよい。
【００１８】
Ｒｉｃｈクライアント５には、金融デバイスを接続している一方で、Ｔｈｉｎクライアント４には、金融デバイスを接続していない。これは、Ｒｉｃｈクライアント５が金融デバイスを制御する機能を有している一方で、Ｔｈｉｎクライアント４が金融デバイスを制御する機能を有していないためである。しかし、Ｔｈｉｎクライアント４からでもデバイス制御サーバ３に接続された金融デバイスを利用できる。Ｔｈｉｎクライアント４とＲｉｃｈクライアント５とを併用すると、通常に金融デバイスを用いるクライアントとしてＲｉｃｈクライアントを用い、繁忙時には金融デバイスを用いるクライアントしてＴｈｉｎクライアントを用いる、といったコストと利用率を考慮した導入が可能になる。
【００１９】
Ｒｉｃｈクライアント５とＴｈｉｎクライアント４を、それぞれ第１のクライアント、第２のクライアントともいう。また、まとめて営業店端末やクライアントともいう。ＡＰサーバ１をフロー制御サーバや第１のサーバともいう。デバイス制御サーバを第２のサーバともよぶ。サーバとホストとを総称して上位装置ともよぶ。
【００２０】
各構成を接続している回線は、容量の大きい、言い換えれば通信速度が速いものが望ましい。一般的には、クライアントやデバイス制御サーバ３と金融デバイスを接続している回線の容量が大きく、次いでクライアントとデバイス制御サーバ３とを接続している回線、営業店とセンタとを結んでいる回線の容量の順で大きい。なお、この回線の容量の関係から、図１及び２では、デバイス制御サーバ３とＲｉｃｈクライアント５に金融デバイスを接続しているが、デバイス制御サーバ３とＲｉｃｈクライアント５と金融デバイスとを並列に接続してもよい。
【００２１】
図２は、図１のハードウェアを店舗にレイアウトする一例を示す。金融デバイスの数を最適化してコストを低減し、現金を取り扱う一線、後方処理を行う二線という従来の営業店レイアウトの概念をなくし、業務毎の相談カウンタ等の配置を可能とすることができる。クライアント４/５（ＰＣ）、現金入出金機８（ＡＣＴ）、通帳プリンタ９（ＰＢＰＲ）、レーザプリンタ（ＬＢＰ）、スキャナ１０（ＢＬＳ）、自動取引装置（ＡＴＭ）を例として配置している。
【００２２】
図３は、ＡＰサーバ１と、デバイス制御サーバ３と、Ｒｉｃｈクライアント５と、Ｔｈｉｎクライアント４の詳細なブロック図を示す。
【００２３】
ＡＰサーバ１は、例えば半導体上の集積回路を含み半導体メモリ等を備えるプロセッサ１１と、例えば磁気ディスクに磁気情報を記憶するハードディスク１４と、回線と接続して電文を送受信するインタフェース１３とを有する。ハードディスク１４は、種々のプログラム、データ、ファイルを記憶しており、半導体メモリ等とあわせて記憶部ともいう。以下、プログラムが実行するとは、すなわち、プロセッサがプログラムをハードディスクから呼び出して実行することを意味する。
【００２４】
ＡＰサーバ１は、Ｔｈｉｎクライアント４向けの端末入出力制御、及び、Ｒｉｃｈクライアント５向けの端末入出力制御をする下位層と、処理手順を管理・制御するフローコントローラ１４０４、処理を実行するコンポーネント群１４０６等を含む上位層とを有する。なお、下位層と上位層は、例えばＴＣＰ／ＩＰの層構成におけるトランスポート層とアプリケーション層とのそれぞれに当たるとすることもできるが、下位層と上位層の両方がアプリケーション層にあってもよい。
【００２５】
下位層は、クライアントの種別、すなわちＴｈｉｎクライアント４とＲｉｃｈクライアント５との違いを吸収する。これにより、上位層は、クライアントの種別に拘わらない構成及び処理をとることが可能になる。ただし、下位層だけで違いを吸収せず、上位装置と一体で吸収するとしても、Ｔｈｉｎクライアント４とＲｉｃｈクライアント５とを併用させることはできる。
【００２６】
Ｔｈｉｎクライアント４とＲｉｃｈクライアント５の違いを吸収するために、ＡＰサーバ１の下位層は、Ｔｈｉｎクライアント４との送受信を制御するＴｈｉｎ向け入出力制御プログラム１４０１と、Ｒｉｃｈクライアント５との送受信を制御するＲｉｃｈ向け入出力制御プログラム１４０２と、Ｔｈｉｎ／Ｒｉｃｈ振分プログラム１４０７とを有する。
【００２７】
Ｔｈｉｎ／Ｒｉｃｈ振分プログラム１４０７は、上位層から受け取った電文を解析して、Ｔｈｉｎクライアント４に送るべきものか、Ｒｉｃｈクライアント５に送るべきものかを判断して前者であればＴｈｉｎ向け入出力制御プログラム１４０１に引き継ぎ、後者であればＲｉｃｈ向け入出力制御プログラムへ引き継ぐ。
【００２８】
Ｔｈｉｎ向け入出力制御プログラム１４０１は、Ｔｈｉｎクライアント４からの入力（送信）データを解析し、データを蓄積し、入力画面が複数のときには次画面を返して続く入力を求める。Ｔｈｉｎクライアント４のオペレータ（テラー）によって一連のデータ入力を受ける入力画面のうち、最後の入力画面に対する入力データを受信したとき、Ｔｈｉｎ向け入出力制御プログラム１４０１は、入力して蓄積したデータを、上位層に送信する。また、上位層からＴｈｉｎクライアント４向けの出力データを受け取り、出力データとして蓄積する。そして、画面定義情報１４０３からディスプレイ６ａに出力する入力画面のレイアウト（フォーマット）を取得して出力データを合成し、入力画面を作成してＴｈｉｎクライアント４に発信する。画面定義情報１４０３は、入力画面等のレイアウト情報と入力画面等の遷移情報を含むものでハードディスク１４に格納されている。なお、入力画面の例を図５に示す。
【００２９】
Ｒｉｃｈ向け入出力制御プログラム１４０２は、Ｒｉｃｈクライアント５からの入力（送信）データを解析し、上位層に送信する。また、上位層からＲｉｃｈクライアント５向けの出力データを受け取り、Ｒｉｃｈクライアント５向けに編集して発信する。
【００３０】
上位層は、クライアントやホスト２から受信した電文に基づいて、業務毎に個別化されたコンポーネントを選択して呼び出すフロー制御プログラム及びフロー定義情報とを有する。フロー定義情報で或る取引に対応する複数の業務の手順を定義しておくことで、該当する取引に用いるコンポーネントをフロー制御プログラムによって呼び出し実行する。すなわち、複数の取引で共通に用いるコンポーネントを、取引毎に用意しておく必要がなくなる。また、金融機関によって業務の手順が異なるが、フロー定義情報で定義している業務の手順を変更することで対応できるのでカスタマイズが容易になる。なお、従来は、或る金融機関の或る取引毎にそれぞれ一連の業務を記述した定義を備えていたため、重複が多くかつカスタマイズが容易でなかった。
【００３１】
また、業務の処理を実行するコンポーネントは、業務の内容のみでなくデータも管理し、そのコンポーネントでデータ編集／解析も実行する。これにより、コンポーネント間の独立性を保ち、コンポーネント毎の組み替え等を容易にする。コンポーネントによるデータ及び編集方式は、金融機関毎／取引毎／業務毎によって異なることが多いため定義可能とする。この工夫により、フロー制御機能を用いることに加えてさらに、金融機関毎や取引毎等のカスタマイズのコストが低減する。なお、本明細書では、取引は、業務を含み、業務は、金融デバイスの動作を含む関係にあるとする。金融デバイスの動作を含まない業務もあり、単一の業務のみからなる取引もある。
【００３２】
コンポーネント群１４０６には、電文解析・振分コンポーネント、電子ジャーナルコンポーネント、ユーザ管理コンポーネント、通帳制御コンポーネント、現金制御コンポーネント、現金・集計管理コンポーネント、ホストトランザクションコンポーネント等がある。なお、コンポーネント群１４０６は、一群のソフトウェアを指すが、ハードウェアを含むものであってもよい。
【００３３】
電文解析・振分コンポーネントは、送信定義情報を有し、送信定義情報に従い、渡されたデータを上位送信データの形式に編集（翻訳）し、ホスト２に送信する（ホストトランザクションコンポーネントを呼び出す）。ホスト２から返信されると、返信されたデータを解析（翻訳）して、適当なコンポーネントに振り分ける。
【００３４】
ユーザ管理コンポーネントは、ユーザのログイン/ログアウトを管理し、ユーザ管理サーバに通信してユーザに許された取引権限のチェックをする。
【００３５】
通帳制御コンポーネントは、通帳プリンタ９の動作を含む業務を処理し、磁気ストライプから読み取ったデータの解析、出力データの編集を実行する。
【００３６】
現金制御コンポーネントは、現金入出金機８の動作を含む業務を処理する。
【００３７】
電子ジャーナル制御コンポーネントは、入力モニタ定義に従い、入力データから入力モニタ印字データを編集し、入力モニタ印字をする。上位からの回答電文内に対して、（ロジカルデータの場合、出力定義情報に従って、データを編集し、）出力印字をする。また、ジャーナル検索機能も提供する。クライアントで管理するよりもサーバで集中管理することが効率的である。
【００３８】
現金・集計管理コンポーネントは、現金入出金装置の現金管理、クライアント毎、店舗毎の集計管理をする。
【００３９】
ホストトランザクションコンポーネントは、ホスト２と交信が発生すると与えられる通番やホスト２のステータス等を管理する。
【００４０】
上位層の共通基盤プログラム１４０５は、クライアント以外の例えば自動取引装置（ＡＴＭ）とも共通する基盤である。Ｔｈｉｎクライアント４及びＲｉｃｈクライアント５や金融デバイスの構成（アドレス、店番、機番、端末構成）やステータスを管理する構成管理プログラムと、ＡＰサーバ１でのトレース（障害履歴等）を取得して保守に活用するトレース取得プログラムと、ＤＢへアクセスするデータベースアクセスプログラムと、ＡＰサーバ１で障害が発生した場合にホストトランザクションコンポーネント、トレース取得プログラム、現金制御コンポーネント、通帳制御コンポーネントの情報を収集する、アラーム状態を制御する等の処理をする障害対処プログラムとを有する。
【００４１】
また、共通メモリエリア１４０８を有する。この共通メモリエリア１４０８はプロセッサ１１の内部メモリや半導体メモリにあってもよい。
【００４２】
デバイス制御サーバ３は、プロセッサ３１と、インタフェース３３と、ハードディスク３４とを有する。これらは、前述したプロセッサ１１、インタフェース１３、ハードディスク１４とハードウェアとしては、スペック等が異なるものの基本的に同様のものと考えてよい。
【００４３】
ただし、特にインタフェース３３は、ＡＰサーバ１向け通信基盤と、処理のシーケンスを担当し、例えばＡＰサーバ１からのデバイス指示を受信してＷＯＳＡ／ＸＦＳ−ＡＰIを呼び出したり、デバイスのイベントをＡＰサーバ１に通知したりする。このインタフェース３３には、ハードウェアとしてのコネクタだけでなく、ソフトウェア（デバイス制御ミドルウェアやデバイスエージェントともいう）が含まれる。
【００４４】
ハードディスク３４は、デバイスサービスプロバイダ、デバイスドライバ３４０２、構成管理プログラム等を格納する。
【００４５】
デバイスドライバ３４０２は、デバイスの具体的な動作を制御する。例えば、現金入出金機８における紙幣を搬送するモータの駆動や、入出金口のシャッタの開閉、通帳プリンタ９における印字ヘッドの上下左右への移動や、頁めくりローラの駆動等の指示を発する。
【００４６】
デバイスサービスプロバイダ３４０１（デバイスＳＰ３４０１）は、デバイスの動作を監視し、デバイスが正常に動作していない、つまり障害のときには障害対策の処置を講じる。例えば、指示信号の再送信等である。
【００４７】
構成管理プログラムは、各デバイスのステータス及び占有を管理する。
【００４８】
Ｔｈｉｎクライアント４とＲｉｃｈクライアント５は、プロセッサ４１・５１、インタフェース４３・５３、ハードディスク４４・５４を有する。これらも、前述したプロセッサ１１、インタフェース１３、ハードディスク１４とハードウェアとしては、スペック等が異なるものの基本的に同様のものと考えてよい。
【００４９】
インタフェース３３、デバイスＳＰ３４０１、デバイスドライバ３４０２についての記述は、Ｒｉｃｈクライアント５のインタフェース５３、デバイスＳＰ５４０２、デバイスドライバ５４０１も同様である。ただし、一般的に、デバイス制御サーバ３は、Ｒｉｃｈクライアント５よりも多くのデバイスに対応するドライバとサービスプロバイダ等を有する。
【００５０】
また、画面定義情報５４０３は、画面定義情報１４０３とほぼ同様である。ただし、画面定義情報１４０３は、Ｒｉｃｈクライアント５にない画面情報も有している。例えば、外国為替取引や融資相談取引のようないわゆるハイカウンタでの取引に利用する画面である。
【００５１】
Ｔｈｉｎクライアント４は、基本的にブラウザ４４０１しか有しない。一方、Ｒｉｃｈクライアント５は、Ｒｉｃｈクライアント５上の画面入出力に加え、画面定義情報５４０３に従い、入力チェック／編集、画面作成、画面遷移等を行う。また、入力データ、出力データの蓄積も行う。また、サーバからの一方を受信し、単独でメッセージを表示するか、あるいは、予め登録されているクライアントプロセスに通知を行う。デバイスが動作したときの通知もこれが受信する。
【００５２】
Ｒｉｃｈクライアント５とＴｈｉｎクライアント４とは、前者が、デバイス制御機能を有し、また、画面定義ファイルを有する一方で、後者が、デバイス制御機能を有さず、また、画面定義機能を有しない点で相違する。デバイス制御機能とは、具体例では、デバイスＳＰ５４０２、デバイスドライバ５４０１である。
【００５３】
Ｔｈｉｎクライアント４は、Ｒｉｃｈクライアント５に比べて安価な構成で済み、デバイスドライバ５４０１やデバイスサービスプロバイダ５４０２の更新もデバイス制御サーバ３を更新すればよいためメンテナンス性が高い。一方、Ｔｈｉｎクライアント４では通信回線を介してＡＰサーバから画面を受信し、また、デバイス制御サーバでデバイスの動作を制御してその結果を受け取るためテラーの操作に対するレスポンスが通信回線、ＡＰサーバ、デバイス制御サーバの影響をＲｉｃｈクライアント５よりも強く受ける。これにより、一般的にはＲｉｃｈクライアント５は、Ｔｈｉｎクライアント４よりもレスポンスが早いため操作性がよい。
【００５４】
Ｔｈｉｎクライアント４もＲｉｃｈクライアント５も、クライアントにはデータを蓄積せず、ジャーナル、集計データ等はサーバで蓄積、管理し、データ編集／解析や論理的な構成管理は全てＡＰサーバ１で行うこととする。この点で、Ｒｉｃｈクライアント５は、従来のＦａｔクライアントと相違する。
【００５５】
デバイス制御サーバ３を、センタのＡＰサーバ１とは別に、例えば営業店又は物理的に営業店に近い場所に設けることで、金融デバイスとの通信負荷が軽減する。現金入出金機や通帳プリンタ等の金融デバイスは、それらの動作（シャッタの開閉、現金の鑑別、現金や通帳の搬送、磁気ストライプの読み書き、頁めくり等）の複雑さゆえに交信の情報量が大きくて回線等の負荷が高く、他方、現金や通帳といった有価媒体を扱うため安定性や安全性が求められる。これらの特殊な事情により、通信負荷を軽減する効果が非常に高い。
【００５６】
図４は、ＡＰサーバ１のプロセッサ１１が各種プログラムを用いて実行する動作のフローチャートを示す。
【００５７】
Ｔｈｉｎクライアント４又はＲｉｃｈクライアント５は、取引（例えば預入取引）の指定を入力すると、Ｔｈｉｎクライアント４又はＲｉｃｈクライアント５のインタフェース４３・５３を通じネットワークを介して、ＡＰサーバ１に入力した取引の要求を発信する。取引の指定は、テラーのキー入力をキーボード７等で受けて取引の種別を指定する形でも良いし、帳票（例えば預入伝票）の画像をスキャナ等で読み取り、マーク／コード／文字等を認識して取引の種別を自動的に指定する形でしても良い。
【００５８】
ＡＰサーバ１（のプロセッサ１１）は、インタフェース１３を通じてＴｈｉｎクライアント４又はＲｉｃｈクライアント５から取引の要求を受信する（Ｓ３００１）。
【００５９】
Ｔｈｉｎ向け入出力制御プログラム１４０１又はＲｉｃｈ向け入出力制御プログラム１４０２は、それぞれＴｈｉｎクライアント４又はＲｉｃｈクライアント５からの取引の要求を受信し、取引の要求の発信元を特定して共通メモリエリア１４０８に記憶する（Ｓ３００２）。発信元は、例えば、取引の要求を含む電文に含まれるヘッダから、発信元を取得して特定する。記憶の形式としては、例えば「機番１１１１１」、「ネットワークアドレス」、「Ａ支店の１番クライアント」、「Ａ支店の１番Ｔｈｉｎクライアント４」が考えられる。また、クライアントで使用デバイスが指定されている場合には、その指定されている使用デバイスも共通メモリエリアに記憶する。記憶の形式としては、例えば「通帳プリンタ３号機」「現金入出金機２号機」が考えられる。指定は、後述する図５のようにオペレータによって指定されても良いし、クライアントやサーバで自動的に指定するようにしても良い。
【００６０】
フロー制御プログラム１４０４は、下位層で受信し上位層に伝えられた取引の要求に対応して、取引毎に設定されている業務フローをフロー定義情報で取引のコードをキーにして検索し取得する（Ｓ３００３）。言い換えれば、プロセッサ１１は、取引の要求に対応する業務フローを取得する。例えば、預入取引では、「ホストへ取引要求を通知→入金→計数→ホストへ入金額を通知→通帳記入」との業務フローが選択される。
【００６１】
フロー制御プログラム１４０４は、取得した業務フローに基づいてコンポーネントを選択して命令を与える（Ｓ３００４）。言い換えれば、取得した業務フローに基づいて対応するコンポーネントを取得する。業務フローは、取引対応のフローや取引のフローともいう。
【００６２】
例えば、「ホストへ取引要求を通知→入金→計数→ホストへ入金額を通知→通帳記入」のフローを取得した場合、「ホスト通知」の業務については、ホストトランザクション管理コンポーネントに命令を与え、「入金」と「計数」の業務について現金制御コンポーネントに「入金」と「計数」の命令を与え、「通帳記入」の業務については、通帳制御コンポーネントに通帳印字の命令を与える。
【００６３】
命令を与えられたコンポーネント群１４０６は、命令に基づきそれぞれの業務を順に実行する。例えば、ホスト２からホストトランザクション管理コンポーネントで取得した電文を、電文解析・振分コンポーネントで解析し、その電文に通帳プリンタ９に対する命令と、画面の命令と、現金入出金機８に対する命令とが含まれていることを検出すると、フロー制御プログラムは、通帳制御コンポーネントを呼び出す。通帳制御コンポーネントは、通帳プリンタ９に対して、例えば、通帳プリンタの下インサータに対し、印字（頁めくり含む）し、終了せよ、との命令を含む電文を発信する。
【００６４】
通常、まずホストトランザクション管理コンポーネントからホスト２へ取引要求を通知し、電文解析・振分コンポーネントでホスト２からの受信を解析して、他のコンポーネントへ命令を含む電文を振り分ける（Ｓ３００５）。
【００６５】
振り分けられた電文にデバイス宛の命令が含まれるかを判断する（Ｓ３００６）。デバイス宛の電文とは通帳制御コンポーネントや現金制御コンポーネントに振り分けられる電文である。
【００６６】
デバイス宛の命令が含まれる場合（Ｓ３００６でＹｅｓ）、共通メモリエリア１４０８を参照して指定された使用デバイスがある場合にはその使用デバイスに命令を送信する（Ｓ３００８）。例えば通帳印字の命令を含む電文が通帳制御コンポーネントに振り分けられ、使用デバイスとして通帳プリンタ３号機が指定されていた場合、通帳プリンタ３号機に送信する。指定された使用デバイスがない場合、予め設定された条件に従ってデバイスを決定し送信する。予め設定された条件としては、例えばＲｉｃｈクライアントから取引処理要求されていればそのＲｉｃｈクライアントに接続されているデバイス、Ｔｈｉｎクライアントから取引処理要求されていればそのＴｈｉｎクライアントに距離が近くかつ空いているデバイス又は若い番号の付されたデバイスを選択することが考えられる。送信した先のデバイスは共通メモリエリア１４０８に記憶しておく。なお、デバイスに命令を送信することは、そのデバイスを管理しているＲｉｃｈクライアント５やデバイス制御サーバ３を経由することを含む。
【００６７】
命令を送信したデバイスで処理が実行されると、制御完了通知を受信する（Ｓ３００９）。共通メモリエリア１４０８に記憶した送信先のデバイスの全てから制御完了通知を受信すると（Ｓ３０１０でＹｅｓ）、その旨を業務フローコンポーネントに通知する。マルチキャスト配信のような形態も考えられるので、処理を要する複数のデバイス（例えば現金入出金機と通帳プリンタ）から制御完了通知を受信したかどうかを判断することとしても良い。なお、デバイスの処理が実行される度に制御完了通知を受信するとデバイス、デバイス制御サーバ、Ｒｉｃｈクライアントで全ての処理が完了したかを判断することが不要になりコスト低減するが、それらで全てのデバイスで制御完了したかを判断するようにしてＡＰサーバ１に返信するようにしても良い。
【００６８】
Ｓ３０１２では、Ｔｈｉｎ／Ｒｉｃｈ振分プログラム１４０７で、受信した取引の要求の発信元がＴｈｉｎクライアント４であるかＲｉｃｈクライアント５であるかを共通メモリエリア１４０８の記憶で判断する。メモリの記憶が、「機番１１１１１」、「ネットワークアドレス」、「Ａ支店の１番クライアント」との形式である場合には、この記憶を参照するだけでは判断できないため、ハードディスク１４に格納している対応テーブル等を用いて、機番１１１１１／ネットワークアドレス／Ａ支店の１番クライアントがＴｈｉｎクライアント４に相当するかＲｉｃｈクライアント５に相当するかを判断する。
【００６９】
取引処理要求元がＴｈｉｎクライアント４であった場合（Ｓ３０１２でＴｈｉｎクライアント）、画面定義情報１４０３から対応する画面情報を取得して電文の内容を画面情報に貼り付けて合成する（Ｓ３０１４）。発信先のＴｈｉｎクライアント４には、画面定義情報１４０３を設けていないためである。合成した電文の内容と画面情報とをＴｈｉｎクライアント４に送信する（Ｓ３０１５）。
【００７０】
取引処理要求元がＲｉｃｈクライアント５であった場合（Ｓ３０１２でＲｉｃｈクライアント）、画面定義情報１４０３の画面情報と合成せずにＲｉｃｈクライアント５に送る（Ｓ３０１４）。Ｒｉｃｈクライアント５は、デバイス制御機能と画面定義情報とを有するためである。
【００７１】
このようにＡＰサーバ１で、クライアントの種別を判断する機能をもつことで、取引を実行する部分を共通化しつつ、Ｔｈｉｎクライアント４とＲｉｃｈクライアント５を並存させることが可能になる。
【００７２】
後述する変形例と異なり、クライアントの種別とは独立に及び/又は種別の決定に先立って送信するデバイスを判断することで、Ｒｉｃｈクライアント５からでもデバイス制御サーバ３を利用することができ、また、逆にＴｈｉｎクライアント４からでもＲｉｃｈクライアント４に接続されたデバイスを利用することができる。多くのクライアントを利用したい特殊な状況や一部のデバイスが故障しているときに有効である。
【００７３】
図５Ａと図５Ｂは、Ｔｈｉｎクライアント４のテラーが使用する現金入出金機８や通帳プリンタ９を指定する画面遷移の例を示す。
【００７４】
デバイスを使用する取引のときや、デバイスキーを押下すると、営業店内に配置された通帳プリンタ９又は現金入出金機８についてサーバで管理されている状況を示す、デバイス選択画面を表示する。この状況は、構成管理プログラム３４０３によって管理しており、占有状態の管理も同様である。
【００７５】
テラーによってデバイス選択画面で選択された金融デバイスをそのテラー（又はＴｈｉｎクライアント４）の占有状態にする。続く取引の画面上には、占有した金融デバイスの番号を示すアイコンを表示しておく。なお、Ｔｈｉｎクライアント４とから近い金融デバイスを自動的に割り当ててもよい。
【００７６】
初期画面（Ｇ５００１）において、ガイド番号入力及び画面索引機能を持つガイドキー押下を行い、取引対象画面である、普通入金画面を索引する。
【００７７】
普通入金画面（Ｇ５００２）で、通帳プリンタキーを押下すると、営業店内に配置された通帳プリンタ９の状況を示す、通帳プリンタ選択画面（Ｇ５００３）を表示する。通帳プリンタ９のデバイスステータスは、デバイス制御サーバ３内の構成管理プログラム３４０３で管理しており、Ｔｈｉｎクライアント４はＡＰサーバ１を介して、デバイス制御サーバ３と通信し、通帳プリンタ９のステータスを表示する通帳プリンタ選択画面（Ｇ５００３）を表示する。テラーが数字＋エンタキーを押下すると、これに対応した通帳プリンタ９をテラーの占有状態とする。Ｔｈｉｎクライアント４画面上では通帳プリンタ９選択画面を消去し、画面上に占有した通帳プリンタ９の番号を示すアイコンを表示し、どの通帳プリンタ９を占有した状態であるか、テラーに通知する（Ｇ５００４）。テラーが通帳プリンタ９に通帳及び伝票をセットすると、通帳セット及び伝票セット通知をデバイス制御サーバ３が検知し、ＡＰサーバ１を介して、占有しているＴｈｉｎクライアント４画面に、通帳セット状態及び伝票セット状態を表示する。また、通帳プリンタ９への通帳セットで磁気ストライプデータの読み取りを行い、読み取りデータのうち、取引画面上のフィールド定義に対応した口座番号のデータを切り出して、当該フィールドに表示を行う（Ｇ５００５）。
【００７８】
続いて、取引金額を入力すると、差額を表示する収支バランス画面（Ｇ５００６）を表示し、取引金額に対する現金取扱状況を通知する。普通入金画面（Ｇ５００６）で、現金入出金機キーを押下すると、営業店内に配置された現金入出金機８の状況を示す、現金入出金機選択画面（Ｇ５００７）を表示する。現金入出金機８のデバイスステータスは、デバイス制御サーバ３の構成管理プログラム３４０３で管理しており、Ｔｈｉｎクライアント４はＡＰサーバ１を介して、デバイス制御サーバ３と通信し、現金入出金機８のステータスを表示する現金入出金機選択画面（Ｇ５００７）を表示する。テラーが数字＋エンタキーを押下すると、これに対応した現金入出金機８をテラーの占有状態とする。Ｔｈｉｎクライアント４画面上では現金入出金機選択画面を消去し、画面上に占有した現金入出金機８の番号を示すアイコンを表示し、どの現金入出金機８を占有した状態であるか、ＡＰサーバ１を介して、Ｔｈｉｎクライアント４の取引画面上に表示する（Ｇ５００８）。テラーが現金入出金機８に現金をセットすると、入金状態をデバイス制御サーバ３が検知し、占有しているＴｈｉｎクライアント４に、通知する（Ｇ５０１０）。金種画面キー押下により、現金の取扱状況を確認するための金種画面（Ｇ５０１０）を表示し、現金入出金機８で入金した状況を反映する。この場合、９千円の取引金額に対して、１万円の入金を発生させるため、収支をあわせるためには、お釣として千円を出金する必要がある。よって、釣キー及び自動払キーにより、お釣として支払う千円を高位金種振り分けし、千円札１枚を現金入出金機８から支払う状況とし、取引金額と現金取扱金額の差額が０円となることを確認する（Ｇ５０１１）。金種画面キー押下で普通入金画面（Ｇ５０１２）を表示すると、収支バランス画面上の差額も０円となっていることが確認でき、普通入金としてのデータエントリが完結できる。
【００７９】
なお、通帳プリンタ９キーあるいは現金入出金機８キー等デバイスに特化したキーを割り当てることで、使用するデバイスを宣言しているが、まとめて金融デバイスキーとして取り扱い、一画面ですべての使用デバイスを宣言する方法も可能である。
【００８０】
完了キー押下し、ＡＰサーバ１を介してホスト２と送受信を実施し、デバイス宛出力電文を受信した場合、当該Ｔｈｉｎクライアント４が占有しているデバイスへの出力内容をデバイス出力指示画面（Ｇ５０１３）として表示し、ＡＰサーバ１からデバイス制御サーバ３を介して、占有しているデバイスに対しての出力処理を順次実施する。テラーは、現金入出金機８への出力指示内容をデバイス出力指示画面で確認し、占有している現金入出金機８から出金されているお釣を受け取った後、エンタキー押下により、次画面（Ｇ５０１４）へ進む。テラーは通帳プリンタ９への出力指示内容をデバイス出力指示画面で確認し、占有している通帳プリンタ９から通帳及び伝票を受け取った後、エンタキー押下により、デバイス出力指示画面を消去し、一件の取引終了を検知して初期画面（Ｇ５０１５）表示を行う。
【００８１】
図５の画面遷移例は、一つ一つのデバイス宛指示を確実に確認しながらオペレーションさせる方式であるが、デバイス宛出力指示について一度にすべてのデバイス宛指示を画面表示することもできる。その場合、テラーの立ち歩きを極力減らすことができる。
【００８２】
このようにテラーにデバイスを選択させ、デバイス宛出力指示を一つ一つオペレーションで確認させることにより、各テラーの判断及び責任のもとで通帳等の重要媒体や現金を取り扱うことができる。もちろん、取引個別の入力、あるいは入金処理がない取引の場合は、デバイスを選択せずに取引を実施し、当該Ｔｈｉｎクライアント４とからより近いデバイスから割り当てる等の優先順位をサーバ側で判断させることも可能である。
【００８３】
図６は、図４の変形例を示すものである。この変形例ではデバイスへの送信に先立って取引処理要求元を判断している。この変形例では、Ｒｉｃｈクライアントが自身で管理しているデバイスを使用して取引処理を実行する場合に、Ｒｉｃｈクライアントであると判断された後は従来と同様に処理できる利点がある。以下、Ｓ３００１〜Ｓ３００５迄は図４と共通なのでＳ６００６以降を説明する。
【００８４】
Ｓ３００５で呼び出された各コンポーネントで業務を実行し、ＡＰサーバ１の外部へ命令や報告を発信するとき、Ｔｈｉｎ／Ｒｉｃｈ振分プログラム１４０７は、受信した取引処理要求元がＴｈｉｎクライアント４であるかＲｉｃｈクライアント５であるかを共通メモリエリア１４０８の記憶で判断する（Ｓ６００６）。メモリの記憶が、「機番１１１１１」、「ネットワークアドレス」、「Ａ支店の１番クライアント」との形式である場合には、この記憶を参照するだけでは判断できないため、ハードディスク１４に格納している対応テーブル等を用いて、機番１１１１１／ネットワークアドレス／Ａ支店の１番クライアントがＴｈｉｎクライアント４に相当するかＲｉｃｈクライアント５に相当するかを判断する。
【００８５】
発信元がＴｈｉｎクライアント４であったとき、デバイス宛の命令があるか否かを判断する（Ｓ６００７）。デバイス宛の命令は、金融デバイスの動作を伴う命令であり、例えば、現金入出金機８のシャッタの開閉や紙幣の搬送、通帳プリンタ９の通帳の取込や頁めくり等が金融デバイスの動作である。預入取引の場合、現金入出金機８で紙幣を入金して、通帳プリンタ９で入金した金額を印字するので、コンポーネント群１４０６の各業務で発信する電文は、デバイス宛の命令を含んでいる。金融デバイスの動作を含まない取引は、例えば残高照会取引や融資相談取引である。
【００８６】
取引の要求元がＴｈｉｎクライアント４であり、かつ、取引がデバイス制御を含むとき、デバイス宛の命令をＴｈｉｎクライアント４ではなく、デバイス制御サーバ３に発信する（Ｓ６００８）。Ｔｈｉｎクライアント４は、デバイス制御の機能を有していないためである。発信先のデバイス制御サーバ３は、要求元のＴｈｉｎクライアント４に対応して予定されており、例えば要求元のＴｈｉｎクライアント４と同じ営業店に設置されているデバイス制御サーバ３である。
【００８７】
デバイス制御サーバ３では、コンポーネントの命令に基づいてデバイスを実際に動作させるための命令を発信する。例えば、通帳制御コンポーネントから発せられた下インサータに対する、印字（頁めくり含む）し、終了するとの電文をインタフェース１３を介して受信したとき、ドライバで実際にヘッド等を動かして印字する。デバイスＳＰ３４０１は、ヘッドの動き等を監視し、その動作の異常を検知した場合に信号を再送信する等の傷害対策を施し、正常な終了をチェックする。正常な終了をチェックすると、インタフェース１３を介してデバイス制御サーバ３からＡＰサーバ１へ向けて制御の完了の通知を発信する。
【００８８】
通帳制御コンポーネントや現金制御コンポーネントは、デバイス制御サーバ３から金融デバイスの動作完了の通知を受信する（Ｓ６００９）。フロー制御プログラム１４０４で取得した業務フローにおいて続く業務が、ホストへの通知である場合には、ホスト２と交信してさらに業務を続ける。
【００８９】
Ｔｈｉｎクライアント４へ電文を発信する場合、画面定義情報１４０３から対応する画面情報を取得して電文の内容を画面情報に貼り付けて合成し（Ｓ６０１０）、合成した電文の内容と画面情報とをＴｈｉｎクライアント４に送信する（Ｓ６０１１）。
【００９０】
発信元がＲｉｃｈクライアント５であったときには、デバイス宛の命令をＲｉｃｈクライアント５に送り（Ｓ６０１３）、ＡＰサーバ１が作成した電文も画面定義情報１４０３の画面情報と合成せずにＲｉｃｈクライアント５に送る（Ｓ６０１４）。
【００９１】
以上、本発明の一実施形態を説明した。なお、本発明の課題と効果は、本実施形態の構成や機能を取捨選択して変形しても達成できるものがある。例えば、デバイス制御サーバ３の機能（プログラム等）をＡＰサーバ１と一体で持たせても、Ｒｉｃｈクライアント５とＴｈｉｎクライアント４とを併用する課題と効果を達成できる。また、例えば、Ｒｉｃｈクライアント５が無くとも、デバイス制御サーバ３をＡＰサーバ１から分離してＴｈｉｎクライアント４の近くに置くことで金融デバイスの制御を安定化等する課題と効果を達成できる。
【図面の簡単な説明】
【００９２】
【図１】センタと営業店の構成の一例を示すブロック図
【図２】営業店内における金融デバイス配置の一例を示す図
【図３】サーバとクライアントの構成の一例を示すブロック図
【図４】ＡＰサーバでの処理の一例を示すフローチャート
【図５Ａ】Ｔｈｉｎクライアントの画面例１
【図５Ｂ】Ｔｈｉｎクライアントの画面例２
【図６】ＡＰサーバでの処理の変形例を示すフローチャート
【符号の説明】
【００９３】
１：アプリケーションサーバ、２：ホストコンピュータ、３：デバイス制御サーバ、４：Ｔｈｉｎクライアント、５：Ｒｉｃｈクライアント、８：現金入出金機、９：通帳プリンタ、１４０４：フロー制御プログラム、１４０６：コンポーネント群、１４０７：Ｔｈｉｎ／Ｒｉｃｈ振分プログラム、１４０３：画面定義情報。
【図１】
2006092056.tif 000003
【図２】
2006092056.tif 000004
【図３】
2006092056.tif 000005
【図４】
2006092056.tif 000006
【図５Ａ】
2006092056.tif 000007
【図５Ｂ】
2006092056.tif 000008
【図６】
2006092056.tif 000009