JP2007188254A - 制御方法及び装置 - Google Patents

Abstract

【課題】金融機関において行われる大口入出金業務の効率を安全性を保持しつつ向上させる。
【解決手段】現金を所定枚数毎に束ねて小束として保持する現金取扱機器を制御する方法は、現金取扱機器からの小束の出金を要求し且つ端末種別情報を含む出金要求を端末から受信するステップと、現金取扱機器が出金要求に係る小束を出金可能であるか判断する第１判断ステップと、出金要求に含まれる端末種別情報が出金要求の要求元の端末に現金取扱機器が隣接配置されていることを表しているか判断する第２判断ステップと、第１及び第２判断ステップにおいて肯定的な判断がなされた場合には、現金取扱機器に出金要求に係る小束の出金を指示するステップとを含む。
【選択図】 図１

Description

本発明は、銀行等の金融機関における営業店における情報処理技術に関する。

従来、銀行において、大口入出金業務は銀行窓口では処理せず、出納係が出納機から現金の入出金を行い、その都度現金の確認を行うなどの作業が発生していた。

また、特開平８−３１５２４８号公報には、会計において店員が現金に触れる機会を排除し、現金の受け渡しにおける金額の間違いの防止と店員による不正の防止を実現するための技術が開示されている。具体的には、現金の収納、入力された情報に従った会計演算、および会計の記録としてのレシートの発行を行うレジスタにおいて、顧客が現金を投入する現金投入口と、顧客へ現金を排出する現金排出口と、顧客が現金投入口より投入した現金の金種、正損、真偽、数等を鑑別し、入金可能な現金を収納し、さらにおつりを現金排出口へ排出する現金入出金機とを有する。但し、大口入出金を取り扱うものではなく、取引についての処理を行うレジスタにおける現金入出金を取り扱っているだけである。

さらに、特開平１１−２１９３９８号公報には、低コストにて、金融機関の店舗以外の施設で利用者が現金を受取れるサービスの実施を可能とする技術が開示されている。具体的には、利用者が金融機関の店舗以外の施設で現金を受取るために用いられるシステムであって、金融機関が発行し、利用者が所持しているカードの情報を読み取るためのカード情報読取手段と、利用者が予め金融機関に登録してある暗証番号を入力するための暗証番号入力手段と、利用者が受取りを希望する金額を入力するための受取り希望金額入力手段と、この受取り希望金額入力手段で入力された金額に関する情報が記録されたレシートを発給するレシート発給手段とを具備し、レシートを提示することにより、利用者が金融機関の店舗以外の施設で現金を受取れるようにしたものである。前提が、金融機関の店舗以外の施設で現金を受け取るような場合を想定しており、金融機関の店舗内における端末に応じて大口出金の態様（場所及びタイミング）を変化させるようなことは想定していない。
特開平８−３１５２４８号公報 特開平１１−２１９３９８号公報

従来技術では、大口入出金は窓口端末での取引とは非連携であり、運用による事務処理が行われていた。そのため、具体的には以下のような問題が存在していた。すなわち、ホスト勘定処理と大口入出金機の勘定は連携しておらず、行員による手照合及び精査業務の負荷が高い。精査業務で回金表記載やそれに伴う役席者への検印処理など多くの事務手数がかかる。また、行員が営業店端末の制御のみではなく、離席した対応が必要となる。さらに、行員自体が現金に触れるため、その受け渡し時には必ず精査（再勘定）を行う必要がある。また、大口入金機の在高が把握できないため、顧客受付後に始めて金庫室等から資金を調達する必要がある。そして、現金を行員が入出金するため、現金締め上げ処理を行うが、関連する機器（大口入出金機／キャッシャ）にある現物（現金）とホスト勘定を突合する事務が発生する。

大口入出金は金融機関の基本的な業務であるが利益を生む業務ではないにもかかわらず事務負荷が高く、業務効率向上の妨げとなっていた。一方、当然ながら、現金の取り扱いには細心の注意が必要である。

従って、本発明の目的は、金融機関において行われる大口入出金業務の効率を安全性を保持しつつ向上させるための技術を提供することである。

本発明の第１の態様に係る、現金を所定枚数毎に束ねて小束として保持する現金取扱機器（例えば実施の形態におけるリサイクルキャッシャ）を制御する方法は、現金取扱機器からの小束の出金を要求し且つ端末種別情報を含む出金要求を端末から受信するステップと、現金取扱機器が出金要求に係る小束を出金可能であるか判断する第１判断ステップと、出金要求に含まれる端末種別情報が出金要求の要求元の端末に現金取扱機器が隣接配置されていることを表しているか判断する第２判断ステップと、第１及び第２判断ステップにおいて肯定的な判断がなされた場合には、現金取扱機器に出金要求に係る小束の出金を指示するステップとを含む。

このように現金取扱機器を制御することによって大口の出金を行う場合においても、小束単位で出金されるので、金融機関の従業員による現金計数の手数を削減することができ、事務効率を向上させることができる。また、安全の観点から第１及び第２判断ステップにおける条件を満足しなければ即時に小束を出金することはなく、安全に業務を行うことができる。

また、上で述べた第１判断ステップにおいて否定的な判断がなされた場合には、エラー通知を出金要求の要求元の端末に送信するステップをさらに含むようにしてもよい。例えば、現金取扱機器における動作エラーや小束不足の場合には、即時に小束出金を指示できないので、事後的に出金するようにする。

さらに、上で述べた第２判断ステップにおいて否定的な判断がなされ且つ出金要求の要求元の端末が預金者が操作する端末である場合には、当該端末に出金要求がなされたことを表す帳票を出力させるステップをさらに含むようにしてもよい。大口出金については、顧客のみに端末の操作を行わせて出金するのではなく、金融機関の従業員が関与するようにする。この場合には、例えばＡＴＭ（Auto Teller Machine）を顧客が操作して出金要求を行ったとしても、帳票を打ち出すだけにして、実際には帳票に基づき金融機関の従業員が現金取扱機器から小束を出金するものである。

本発明の第２の態様に係る入金管理方法は、現金取扱機器において顧客により入金され且つ当該顧客の口座番号を特定することなく計数された現金の金額を、原資金額として口座番号とは別の入金識別情報に対応して取引管理データベースに登録する第１登録ステップと、現金取扱機器とは別の端末において特定された顧客の口座番号と原資金額以下の取引金額とを用いて、ホスト元帳を更新させるステップと、顧客の口座番号と原資金額以下の取引金額とを、入金識別情報に対応して取引管理データベースに登録する第２登録ステップとを含む。

大口入金においても顧客の操作によって現金取扱機器によって現金の計数を行い、入金識別情報（例えば実施の形態における通番）によってデータ連係を実現して、適切に口座に入金できるようにしている。これによって人間による現金計数関連業務を削減して、業務効率化がなされる。

なお、本方法などは、コンピュータと当該コンピュータに実行されるプログラムとで実施され、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配信される場合もある。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

本発明によれば、金融機関において行われる大口入出金業務の効率を安全性を保持しつつ向上させることができるようになる。

最初に、本発明の実施の形態に係るコンピュータ・システムを利用する銀行の営業店について図１を用いて説明する。なお、銀行の例を示すが、他の金融機関でも有効である。本実施の形態における銀行の営業店のロビー側に入店した顧客は、総合受付カウンタ１００１にて、その取引内容に応じて、ＡＴＭ（Auto Teller Machine）１００２、大口入金を行うためのリサイクルキャッシャ１００３又は１００９、各種取引を行うためのモジュールボックス１０１０（ここでは１０１０ａ及び１０１０ｂ）、大口出金などのための取次カウンタ１００７、図示しない相談窓口などのうち適切な場所を指定され、その場所で取引についての手続きを行う。

ＡＴＭ１００２では、顧客は、従来の入金、出金、振り込みに加えて以下で説明する大口の出金指示、大口入金における精算金受け取りなどを行うことができる。ＡＴＭ１００２の台数は何台であってもよい。リサイクルキャッシャ１００３及び１００９では、顧客は、大口の入金を行うことができる。リサイクルキャッシャ１００３及び１００９は、ロビー側に向いており且つ顧客が操作する入金側と、行員側に向いており且つ銀行員が操作する出金側とにユーザ・インターフェースを有している。なお、リサイクルキャッシャ１００９は、存在しない場合もある。

モジュールボックス１０１０には、行員が操作する営業店端末１００６（以下、ＵＢＴと呼ぶ。またここでは１００６ａ及び１００６ｂ）が設置されたクイックナビ１００４（ここでは１００４ａ及び１００４ｂ）と、連携するＡＴＭ１００５（ここでは１００５ａ及び１００５ｂ）とが設置されている。行員は、営業店端末１００６を操作することによって顧客が必要とする入金、出金、振り込みなどの各種取引の手続きを支援する。具体的には、モジュールボックス１０１０では、行員側で現金に触れることなく、顧客自身が、連携するＡＴＭ１００５とリサイクルキャッシャ１００３及び１００９とを操作して、必要な取引の手続きを完了させる。なお、モジュールボックス１０１０の数は、いくつであってもよい。

取次カウンタ１００７においては、大口出金が必要となる顧客に対して、例えばＵＢＴ１００８を行員が操作することによってリサイクルキャッシャ１００３又は１００９の出金側から出力される小束（例えば紙幣１００枚の束）を渡す。なお、大口の出金に係る小束の引き渡しは、取次カウンタ１００７にて行われるが、場合によってはＵＢＴ１００６又はＡＴＭ１００５又は１００２によって出金の指示を行う場合もある。但し、行員が出金を行うリサイクルキャッシャがＵＢＴ１００８に隣接するリサイクルキャッシャ１００９の場合と、その他の場合とでは必要な処理が異なる。

このような銀行の営業店では、行員が現金に触れる回数を大幅に削減して、その受け渡しに伴い発生する再勘定、現物（即ち現金）とホスト勘定との突き合わせ事務、その他の精査業務・手照合を削減することができるようになる。

次に、このような銀行の営業店において用いられるコンピュータ・システムについて図２乃至図５を用いて説明する。営業店システムでは、営業店ＬＡＮ（Local Area Network）１１０１に、リサイクルキャッシャ１００３、ＡＴＭ１００２、取引管理ＤＢ１５０２を管理する勘定系サーバ１５０１、取次カウンタ１００７におけるＵＢＴ１００８及びリサイクルキャッシャ１００９、モジュールボックス１０１０におけるＵＢＴ１００６及びＡＴＭ１００５、その他のＵＢＴ１０１１、他のシステムに接続するネットワーク１１０２などが接続されている。営業店ＬＡＮ１１０１には、図示しない情報系サーバなどが接続されているが、本実施の形態には直接関係しないので、これ以上説明しない。また、ネットワーク１１０２には、勘定系ホスト１２００その他の従来のコンピュータが接続されているが、本実施の形態には直接関係しないので、これ以上説明しない。

ＵＢＴ１００８は「ＵＢＴ取次」という端末種別情報を有しており、ＵＢＴ１００６及び１０１１は「ＵＢＴクイック」という端末種別情報を有している。

図３に、ＡＴＭ１００２又は１００５の機能ブロック図を示す。ＡＴＭ１００２又は１００５は、ＡＴＭの業務処理のためのＡＴＭ業務アプリケーション１０１、キャッシュカードの読み取りなどの処理を行うカード処理部１０２、通帳の読み取り・印字などの処理を行う通帳処理部１０３、紙幣の計数・出力などの処理を行う紙幣ユニット１０４、硬貨の計数・出力などの処理を行う硬貨ユニット１０５、端末種別情報（ＡＴＭ）１０６、預かり票などの印字を行う預かり票印字部１０７などを含む。

図４に、ＵＢＴ１００６、１００８又は１０１１の機能ブロック図を示す。ＵＢＴ１００６又は１００８は、ＵＢＴの業務処理のためのＵＢＴ業務アプリケーション２０１、通帳、支払票などの帳票を読み取るＯＣＲ（Optical Character Recognition）２０２、端末種別情報（ＵＢＴクイック／ＵＢＴ取次）２０３、通帳などのデータを読み出す通帳処理部２０４を有する。

図５に、リサイクルキャッシャ１００３又は１００９の機能ブロック図を示す。リサイクルキャッシャ１００３又は１００９は、顧客及び行員の操作ログを格納するログＤＢ３０１、リサイクルキャッシャ内の現金及び小束の在高管理を行うための在高管理ＤＢ３０２、ＲＣ（リサイクルキャッシャ）に係る処理のためのアプリケーション３０３、小束作成及び出力などの処理のための小束ユニット３０４、紙幣の入出力処理などを実施する紙幣ユニット３０５、硬貨の入出力処理などを実施する硬貨ユニット３０６、顧客への受付票を印字する受付票印字部３０７、行員カード又は顧客専用のカードを読み取るカード読取部３０８、行員のＩＤとパスワードの対を保持する利用者管理ＤＢ３０９を含む。

次に、図６乃至図６７を用いて図２乃至図５に示したコンピュータ・システムの処理について説明する。

（１）大口入金処理
（１−１）ＵＢＴを用いた大口入金処理
最初に、顧客が例えば２００万円を超える大口の入金を行う場合の処理を説明する。なお、通帳への記帳にＵＢＴを用いる場合とＡＴＭを用いる場合があり、ここではＵＢＴを用いる場合を説明する。

まず、顧客は、総合受付カウンタ１００１又はクイックナビ１００４などにおいて、大口入金のための専用カードを受け取り、リサイクルキャッシャ１００９のところへ行く。そして、顧客は、専用カードをリサイクルキャッシャ１００９に挿入又は読み取りを行わせる。リサイクルキャッシャ１００９のカード読取部３０８が、専用カードを読み取ると、ＲＣアプリケーション３０３は、入金を認識し、現金投入口を開ける。顧客は、持参した現金を現金投入口に投入し、リサイクルキャッシャ１００９は、顧客による現金投入を受け付ける（図６：ステップＳ１）。リサイクルキャッシャ１００９の紙幣ユニット３０５等は、投入された現金の計数処理を実施し、在高管理ＤＢ３０２の紙幣管理テーブル等を更新する（ステップＳ３）。在高管理ＤＢ３０２の紙幣管理テーブル等については、従来のものと同様であるから、これ以上述べない。

次に、リサイクルキャッシャ１００９のＲＣアプリケーション３０３は、取引名（入金）及び計数結果である金額（例えば１０００万円）を含む通番発行要求を、勘定系サーバ１５０１に送信する（ステップＳ５）。勘定系サーバ１５０１は、通番発行要求をリサイクルキャッシャ１００９から受信し（ステップＳ７）、通番（受付番号とも呼ぶ。ここでは「０００２」とする）を発行し、通番、取引名（入金）、原資金額（例えば１０００万円）及びステータス（通番発行）を、取引管理ＤＢ１５０２に登録する（ステップＳ９）。取引管理ＤＢ１５０２は、例えば図７に示すようなデータを格納している。具体的には、通番、口座番号、取引名、金額（原資）、取引金額、差額、金種、束数、パスワード及びステータスが、登録されるようになっている。ステップＳ９では、通番０００２のレコードが生成され、登録される。但し、口座番号、取引金額、差額、金種、束数、パスワードについてはこの段階では登録されない。勘定系サーバ１５０１は、発行した通番をリサイクルキャッシャ１００９に送信する（ステップＳ１１）。リサイクルキャッシャ１００９は、勘定系サーバ１５０１から通番を受信し（ステップＳ１３）、取引内容確認画面を表示して、パスワードの入力を促す（ステップＳ１５）。例えば図８に示すような画面を表示する。図８の例では、取引通番（０００２）及び入金額（１０００万円）が表示され、パスワードの入力を促すようになっている。

顧客は、この画面に対して例えば入力装置からパスワードの入力を行う。リサイクルキャッシャ１００９のＲＣアプリケーション３０３は、顧客からのパスワード（例えばＡＢＣＤ）の入力を受け付け（ステップＳ１７）、通番及びパスワードを勘定系サーバ１５０１に送信する（ステップＳ１９）。勘定系サーバ１５０１は、通番及びパスワードをリサイクルキャッシャ１００９から受信し（ステップＳ２１）、取引管理ＤＢ１５０２において通番に対応してパスワードとステータス（未済）を登録する（ステップＳ２３）。これによって取引管理ＤＢ１５０２に格納されるデータは例えば図９のようになる。すなわち、通番０００２に対応して、パスワード（ＡＢＣＤ）が追加登録され、ステータスが「未済」に更新されている。そして、勘定系サーバ１５０１は、リサイクルキャッシャ１００９に、処理結果（正常）を送信する（ステップＳ２５）。取引管理ＤＢ１５０２に対する処理が失敗した場合には、処理結果（異常）を送信する場合もある。

リサイクルキャッシャ１００９のＲＣアプリケーション３０３は、勘定系サーバ１５０１から処理結果（正常）を受信し（ステップＳ２７）、表示装置に処理完了を表示すると共に、受付票印字部３０７に受付票を印字させる（ステップＳ２９）。例えば、図１０に示すような受付票が出力される。図１０の例では、日付日時及び受付番号（通番）が印字されている。金額については領収書ではないため印字しない。なお、リサイクルキャッシャ１００９のＲＣアプリケーション３０３は、図示しない行員向けのプリンタにて、取引ジャーナル（図１１）を印字する。図１１の例では、日付時刻、受付番号（通番）、金種明細（万円札数、千円札数、硬貨数など）、合計金額が、予備として印刷される。

このように勘定系サーバ１５０１の取引管理ＤＢ１５０２において、入金が記録され、以下で述べる実際の入金処理において用いられる。

次に、図１２乃至図３０を用いて、実際の入金処理の処理フローを説明する。顧客は、リサイクルキャッシャ１００９から受付票を受け取ると、例えばクイックナビ１００４に行き、専用カードを返却し、通帳及び受付票を行員に渡す。そうすると、ＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、行員からの入力に応じて、原資設定画面を表示する（図１２：ステップＳ３１）。例えば図１３に示すような画面が表示される。図１３の例では、受付番号（通番）の入力欄と、パスワードの入力欄とが表示される。但し、本実施の形態では、ＵＢＴを用いる場合には、パスワードの入力は必要ない。

行員は、この画面に対して受付票の通番の入力を行う。ＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、通番の入力を受け付け（ステップＳ３３）、通番及び端末種別情報（ここでは「ＵＢＴクイック」）を含む検索要求を勘定系サーバ１５０１に送信する（ステップＳ３５）。勘定系サーバ１５０１は、ＵＢＴ１００６から通番及び端末種別情報（ＵＢＴクイック）を含む検索要求を受信し（ステップＳ３７）、端末種別情報がＵＢＴであるか判断する（ステップＳ３９）。端末種別情報がＵＢＴでない場合には端子Ａを介して図３１の処理に移行する。端末種別情報がＵＢＴでない場合にはＡＴＭということになるが、ここではあり得ない。端末種別情報がＵＢＴである場合には、通番により取引管理ＤＢ１５０２を検索し、該当レコードを抽出する（ステップＳ４１）。例えば図９のようなデータが取引管理ＤＢ１５０２に格納されている場合には、通番０００２のレコードを抽出する。また、勘定系サーバ１５０１は、そのレコードのステータスを「取得中」に更新する（ステップＳ４３）。例えば図１４に示すようなデータが登録される。図１４の例では、第２レコードのステータスが「取得中」に変更されている。そして、抽出したレコードのデータをＵＢＴ１００６に送信する（ステップＳ４５）。

ＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、勘定系サーバ１５０１から抽出レコードを受信し、表示装置に表示する（ステップＳ４７）。例えば図１５に示すような画面が表示される。図１５の例では、受付番号（通番）及び入金金額が表示される。行員は、表示内容を確認し、「完了キー」を押下げる。ＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、行員からの確認入力を受け付け、内部の原資金額カウンタに、ステップＳ４７で受信した原資金額をセットする（ステップＳ４９）。さらに、メニュー画面を表示する（ステップＳ５１）。ここで、顧客が普通預金への入金を要求しているとすると、行員はメニュー画面において普通預金入金を選択入力する。これに対してＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、普通預金入金の選択入力を受け付け（ステップＳ５３）、普通預金入金画面を表示する（ステップＳ５５）。例えば図１６に示すような画面を表示する。なお、この段階までにＵＢＴ１００６の通帳処理部２０４に通帳をセットして、口座番号を読み取っておくようにする。そうすると、普通預金入金画面は、口座番号の表示と、入金額の入力欄とを含むようになる。ここでは、原資金額と同額の金額を入金する場合なので、行員により、入金額が１０００万円と入力され、「完了キー」が押下げられる。処理は、端子Ｂを介して図１７の処理に移行する。

図１７の処理の説明に移行して、ＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、取引データ（入金金額）の入力を受け付け（ステップＳ５７）、原資金額（原資金額カウンタの値）≧取引金額（入金金額）であるか判断する（ステップＳ５９）。もし、原資金額＜取引金額となる場合には、入金金額があり得ないものとなっているので、ステップＳ５７に戻って再入力を求める。

原資金額≧取引金額であれば、ＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、勘定系ホスト１２００に、口座番号及び入金金額を含む入金処理を依頼する（ステップＳ６１）。勘定系ホスト１２００の処理については従来と同じであるから、ここではこれ以上説明しない。勘定系ホスト１２００は処理結果（正常又は異常）をＵＢＴ１００６に返信する。

ＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、勘定系ホスト１２００から処理結果を受信し、正常に完了したか判断する（ステップＳ６３）。もし何らかの異常が発生している場合にはエラー表示を行って（ステップＳ６５）、ステップＳ５７に戻り、再度処理を行う。

一方、勘定系ホスト１２００の処理が正常に完了している場合には、ＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、取引完了を表示装置に表示し、通帳処理部２０４に、入金データを通帳に印字させる（ステップＳ６７）。そして、原資金額カウンタの値を、（原資金額−取引金額）と更新する（ステップＳ６９）。また、メニュー画面を表示する（ステップＳ７１）。行員は、このメニュー画面において指示を出す。

そして、ＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、メニュー画面において「追加取引」の指示がなされたか判断する（ステップＳ７３）。例えば、原資金額が１０００万円で、普通預金への入金金額を９５０万円とし、その差額を定期預金や投資信託に入金する場合には、追加取引を行うためそのための指示を行う。追加取引が指示された場合には、端子Ｃを介して図１２のステップＳ５１に戻る。但し、ステップＳ５１で他の取引を選択する必要がある。他の処理についても基本的な処理内容は同じであるから、ここではこれ以上述べない。

「追加取引」の指示ではない場合には、ＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、入金額、取引金額（入金金額）、差額を含む原資設定・解除画面を表示する（ステップＳ７５）。例えば図１８のような画面が表示される。図１８の例では、受付番号（通番）、ＲＣ入金金額（原資金額）、取引金額（普通預金への入金金額）、差額が含まれる。上で述べた例では全額普通預金に入金しているので、差額が０円である。処理は端子Ｄを介して図１９の処理に移行する。

図１９の処理の説明に移行して、ＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、差額が０であるか判断する（ステップＳ７７）。差額が０ではない場合には返金が必要となるので、端子Ｅを介して図２２の説明に移行する。一方、差額が０であれば、処理を終了させるため、図１８に示した画面において、行員は「完了キー」を押下げる。そうすると、ＵＢＴ業務アプリケーション２０１は、行員による取引完了指示を受け付け（ステップＳ７９）、通番、取引金額（入金金額）、口座番号及び差額を含むＤＢ更新要求を勘定系サーバ１５０１に送信する（ステップＳ８１）。勘定系サーバ１５０１は、ＵＢＴ１００６から、通番、取引金額（入金金額）、口座番号及び差額（＝０）を含むＤＢ更新要求を受信し（ステップＳ８３）、通番に対応して、ステータス「済」、口座番号、取引金額（入金金額）、差額（＝０）を取引管理ＤＢ１５０２に登録する（ステップＳ８５）。例えば、ステップＳ８５によって取引管理ＤＢ１５０２に図２０に示すようなデータが登録される。図１４との差は、上で述べたＤＢ更新要求に含まれるデータ及びステータス「済」である。そして、処理結果（正常）をＵＢＴ１００６に返信する（ステップＳ８７）。

ＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、勘定系サーバ１５０１から処理結果（正常）を受信し（ステップＳ８９）、原資金額カウンタをクリアするなどの初期化を行い、メニュー画面を表示する（ステップＳ９１）。

このような処理を実施することによって、勘定系ホスト１２００に正しい入金データが登録され、通帳にも入金データが記帳される。さらに、取引管理ＤＢ１５０２によって正しく手続き状態が管理されるようになっている。

例えば図２１に示すように、原資設定・解除画面において入金金額が１０００万円より少ない９９０万円であって、差額が０でないのにもかかわらず、「完了キー」が押された場合には、差額返金が必要となる。このような場合には、図２２に示すような処理を行う。すなわち、端子Ｅの後に、ＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、行員からの取引完了指示がなされたか判断する（ステップＳ９３）。もし「完了キー」以外のキーが押下げられた場合には、端子Ｃを介して図１２のステップＳ５１に戻り、他の入金処理等を行う。

「完了キー」が押下げられ取引完了指示がなされた場合には、通番、取引金額（入金金額）、口座番号及び差額（≠０）を含むＤＢ更新要求を勘定系サーバ１５０１に送信する（ステップＳ９５）。勘定系サーバ１５０１は、ＵＢＴ１００６から、通番、取引金額（入金金額）、口座番号及び差額（≠０）を含むＤＢ更新要求を受信し（ステップＳ９７）、通番に対応して、口座番号、取引金額（入金金額）、差額を取引管理ＤＢ１５０２に登録する（ステップＳ９９）。但し、ここでは差額が０ではないので、ステータスを「未済」で保持する。これによって図２３に示すようなデータが取引管理ＤＢ１５０２に登録される。図２０との差は、差額とステータスである。そして、処理結果（正常）をＵＢＴ１００６に返信する（ステップＳ１０１）。

ＵＢＴ１００６のＵＢＴ業務アプリケーション２０１は、勘定系サーバ１５０１から処理結果（正常）を受信し（ステップＳ１０３）、原資金額カウンタをクリアするなどの初期化を行い、メニュー画面を表示する（ステップＳ１０５）。

この段階ではまだ返金が終わっていないので、同じモジュールボックス１０１０のＡＴＭ１００５で以下のような返金処理を図２４乃至図３０を用いて実施する。なお、ＡＴＭ１００５を操作するのは行員ではなく、顧客となる。これによって行員は現金に触れることがないため、事務作業量を削減することができるようになる。

ＡＴＭ１００５は、図２５のような取引メニューを表示している（ステップＳ１０７）。図２５の例では、入金ボタン、振込ボタン、出金ボタン及びＲＣ（リサイクルキャッシャ）連携ボタンが表示されるようになっている。ここで顧客は、ＲＣ連携ボタンを押すものとする。ＡＴＭ１００５のＡＴＭ業務アプリケーション１０１は、顧客によるＲＣ連携指示を受け付け（ステップＳ１０９）、図２６のような取引確認画面を表示する（ステップＳ１１１）。図２６の例では、受付番号（通番）及びパスワードの入力欄が表示されている。

顧客は、受付票の受付番号とリサイクルキャッシャ１００９で入力したパスワードをＡＴＭ１００５に入力する。ＡＴＭ１００５のＡＴＭ業務アプリケーション１０１は、顧客から受付番号（通番）及びパスワードの入力を受け付け（ステップＳ１１３）、受付番号（通番）、パスワード、ＡＴＭ１００５の端末種別情報（ＡＴＭ）を含む検索要求を勘定系サーバ１５０１に送信する（ステップＳ１１５）。

勘定系サーバ１５０１は、ＡＴＭ１００５から受付番号（通番）、パスワード、ＡＴＭ１００５の端末種別情報（ＡＴＭ）を含む検索要求を受信する（ステップＳ１１７）。そうすると、検索要求に含まれる受付番号（通番）で取引管理ＤＢ１５０２を検索して、対応して登録されているパスワードを読み出す。そして、受信したパスワードと読み出したパスワードを比較してパスワードチェックを行う（ステップＳ１１９）。なお、端末種別情報（ＡＴＭ）の場合には必ずパスワードチェックが必要となる。一方、端末種別情報がＵＢＴであれば、パスワードチェックは不要である。パスワードチェックに成功しなかった場合には（ステップＳ１２１：Ｎｏルート）、照合失敗をＡＴＭ１００５に通知する。ＡＴＭ１００５の業務アプリケーション１０１は、照合失敗を勘定系サーバ１５０１から受信して表示装置に照合失敗を示す（ステップＳ１２３）。そしてステップＳ１１３に戻る。

一方、パスワードチェックに成功した場合（ステップＳ１２１：Ｙｅｓルート）、勘定系サーバ１５０１は、受信した受付番号（通番）に対応して取引管理ＤＢ１５０２に登録されている原資金額、取引金額及び差額を読み出し、ステータス「取得中」に更新する（ステップＳ１２５）。この段階で取引管理ＤＢ１５０２に登録されているデータは例えば図２７に示すようになる。図２３とはステータス「取得中」の部分のみ異なる。そして、読み出した原資金額、取引金額及び差額をＡＴＭ１００５に返信する（ステップＳ１２７）。

ＡＴＭ１００５のＡＴＭ業務アプリケーション１０１は、勘定系サーバ１５０１から、原資金額、取引金額及び差額を受信し（ステップＳ１２９）、取引確認画面を表示する（ステップＳ１３１）。取引確認画面の一例を図２８に示す。図２８の例では、受付番号（通番）、ＲＣ入金金額（原資金額）、取引金額、差額（お釣）が表示されている。ここで、特に問題がなければ、顧客は確認ボタンを押す。

ＡＴＭ業務アプリケーション１０１は、顧客による確認入力を受け付け（ステップＳ１３３）、紙幣ユニット１０４及び硬貨ユニット１０５により差額を出金させる（図２９：ステップＳ１３５）。また、通番及び差額を含むＤＢ更新要求（完了）を勘定系サーバ１５０１に送信する（ステップＳ１３７）。勘定系サーバ１５０１は、ＡＴＭ１００５から通番及び差額を含むＤＢ更新要求（完了）を受信すると（ステップＳ１３９）、取引金額に差額を加算して新たな取引金額とし、差額を０とし、ステータス「済」として、通番に対応して取引管理ＤＢ１５０２に登録する（ステップＳ１４１）。ステップＳ１４１を実行すると、図３０に示すようなデータが取引管理ＤＢ１５０２に登録される。図２７との差は、取引金額と、差額と、ステータスとが異なっている。

そして、ＡＴＭ業務アプリケーション１０１は、取引結果（正常）をＡＴＭ１００５に送信する（ステップＳ１４３）。ＡＴＭ１００５のＡＴＭ業務アプリケーション１０１は、勘定系サーバ１５０１から取引結果（正常）を受信し（ステップＳ１４５）、取引メニューを表示装置に表示する（ステップＳ１４７）。

このような処理によって、差額の出金が必要となった場合においても、行員は現金に触れることなく、適切に差額出金を行うことができるようになる。

（１−２）ＡＴＭを用いた大口入金処理
上ではＵＢＴを用いた大口入金処理を説明したが、行員が何もせずＡＴＭ１００２等を顧客が直接操作することによって入金処理を行うことも可能である。なお、リサイクルキャッシャ１００９の処理については同じであるから説明を省略する。

リサイクルキャッシャ１００９への大口入金が終了して受付票を受領した後に、顧客は、ＡＴＭ１００２の設置場所に移動する。

ＡＴＭ１００２は、図２５のような取引メニューを表示している（ステップＳ１５１）。ここで顧客は、ＲＣ連携ボタンを押すものとする。ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、顧客によるＲＣ連携指示を受け付け（ステップＳ１５３）、図２６のような取引確認画面を表示する（ステップＳ１５５）。

顧客は、受付票の受付番号とリサイクルキャッシャ１００９で入力したパスワードをＡＴＭ１００２に入力する。ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、顧客から受付番号（通番）及びパスワードの入力を受け付け（ステップＳ１５７）、受付番号（通番）、パスワード、ＡＴＭ１００２の端末種別情報（ＡＴＭ）を含む検索要求を勘定系サーバ１５０１に送信する（ステップＳ１５９）。

勘定系サーバ１５０１は、ＡＴＭ１００２から受付番号（通番）、パスワード、ＡＴＭ１００２の端末種別情報（ＡＴＭ）を含む検索要求を受信する（ステップＳ１６１）。そうすると、検索要求に含まれる受付番号（通番）で取引管理ＤＢ１５０２を検索して、対応して登録されているパスワードを読み出す。そして、受信したパスワードと読み出したパスワードを比較してパスワードチェックを行う（ステップＳ１６３）。なお、端末種別情報（ＡＴＭ）の場合には必ずパスワードチェックが必要となる。一方、端末種別情報がＵＢＴであれば、パスワードチェックは不要となる。パスワードチェックに成功しなかった場合には（ステップＳ１６５：Ｎｏルート）、照合失敗をＡＴＭ１００２に通知する。ＡＴＭ１００２の業務アプリケーション１０１は、照合失敗を勘定系サーバ１５０１から受信して表示装置に照合失敗を示す（ステップＳ１６７）。そしてステップＳ１５７に戻る。

一方、パスワードチェックに成功した場合（ステップＳ１６５：Ｙｅｓルート）、勘定系サーバ１５０１は、受信した受付番号（通番）に対応して取引管理ＤＢ１５０２に登録されている原資金額を読み出し、ステータス「取得中」に更新する（ステップＳ１６９）。このステップの前には、取引管理ＤＢ１５０２は図９のようなデータを格納しており、本ステップによって、取引管理ＤＢ１５０２は図１４のようなデータを格納するようになる。また、この段階では、差額及び取引金額が登録されていないので原資金額のみが読み出される。そして、読み出した原資金額をＡＴＭ１００２に返信する（ステップＳ１７１）。

ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、勘定系サーバ１５０１から、原資金額を受信し（ステップＳ１７３）、原資設定画面を表示すると共に、原資金額カウンタに原資金額をセットする（ステップＳ１７５）。例えば図３２に示すような画面が表示される。図３２の例では、受付番号（通番）及びＲＣ入金金額（原資金額）が表示される。ここでリサイクルキャッシャ１００９に入金した金額が正しければ確認キーを押下げる。処理は端子Ｇを介して図３３の処理に移行する。

図３３の処理に移行して、ＡＴＭ業務アプリケーション１０１は、顧客による確認指示を受け付け、これに応答してメニュー画面を表示する（ステップＳ１７７）。これは図２５と同じである。そして、顧客が入金ボタンを押下げると、ＡＴＭ業務アプリケーション１０１は、入金指示を受け付け（ステップＳ１７９）、原資金額を含む入金画面を表示する（ステップＳ１８１）。例えば図３４のような画面を表示する。図３４の例では、口座番号の表示欄（この段階では表示無し）と、取引金額の入力欄とが表示される。この画面によって、通帳の挿入を促し、顧客は通帳をＡＴＭ１００２に挿入する。ＡＴＭ１００２は、通帳の挿入を受け付ける（ステップＳ１８３）。また、図３４によって、入金金額（すなわち取引金額）の入力を促し、顧客はＡＴＭ１００２に入金金額の入力を行う。ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、顧客から入金金額の入力を受け付け（ステップＳ１８５）、原資金額≧入金金額であるか判断する（ステップＳ１８７）。

原資金額＜入金金額の場合には不適切であるから、エラー表示を行ってステップＳ１８５に戻る（ステップＳ１８９）。一方、原資金額≧入金金額である場合には、ＡＴＭ業務アプリケーション１０１は、通帳処理部１０３に、挿入された通帳の読み取りを行わせ、読み取った口座番号を表示装置に表示する（ステップＳ１９１）。例えば図３５のような画面が表示される。図３５の画面例では、通帳から読み取った口座番号と、顧客によって入力された取引金額（入金金額）とが表示される。

そして、顧客が確認キーを押下げると、ＡＴＭ業務アプリケーション１０１は、確認指示を受け付け、これに応答して勘定系ホスト１２００に、口座番号及び入金金額を含む入金処理を依頼する（ステップＳ１９３）。勘定系ホスト１２００の処理については従来と同じであるから、ここではこれ以上説明しない。勘定系ホスト１２００は処理結果（正常又は異常）をＡＴＭ１００２に返信する。

ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、勘定系ホスト１２００から処理結果を受信し、正常に完了したか判断する（ステップＳ１９５）。もし何らかの異常が発生している場合にはエラー表示を行って（ステップＳ１９４）、ステップＳ１９３に戻り、再度処理を行う。

一方、勘定系ホスト１２００の処理が正常に完了している場合には、ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、取引完了を表示装置に表示し、通帳処理部１０３に、入金データを通帳に印字させる（ステップＳ１９７）。そして、原資金額カウンタの値を、（原資金額−取引金額）と更新する（ステップＳ１９９）。処理は端子Ｈを介して図３６の処理に移行する。

そしてＡＴＭ業務アプリケーション１０１は、口座番号、原資金額、入金金額（取引金額）及び差額を含む原資設定・解除画面を表示する（ステップＳ２０１）。例えば図３７に示すような画面を表示する。ここでは、入金金額＝原資金額なので、差額＝０となる。もし、差額が存在して追加取引を行う場合には、顧客は追加有ボタンを押下げる。差額が存在しない場合又は差額が存在するが差額を出金する場合等、図３７のような画面において、追加無ボタンを押下げる。

ＡＴＭ業務アプリケーション１０１は、追加有又は追加無の指示を受け付け、追加取引指示を受け付けたか判断する（ステップＳ２０３）。追加取引指示を受け付けた場合には、端子Ｇを介して図３３のステップＳ１７７に戻る。一方、追加無の指示を受け付けた場合には、差額＝０であるか判断する（ステップＳ２０５）。差額が０でない場合には端子Ｉを介して図３８の処理に移行する。一方、差額が０である場合には、通番、口座番号、取引金額及び差額（＝０）を含むＤＢ更新要求を勘定系サーバ１５０１に送信する（ステップＳ２０７）。

勘定系サーバ１５０１は、ＡＴＭ１００２から、通番、口座番号、取引金額及び差額を含むＤＢ更新要求を受信し（ステップＳ２０９）、通番に対応して、口座番号、取引金額、差額（＝０）及びステータス「済」を、取引管理ＤＢ１５０２に登録する（ステップＳ２１１）。差額が０であるからステータスを「済」とする。取引管理ＤＢ１５０２に登録されるデータは、例えば図２０に示したようなデータが登録される。

そして、勘定系サーバ１５０１は、処理結果（正常）をＡＴＭ１００２に送信する（ステップＳ２１３）。ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、処理結果（正常）を受信し（ステップＳ２１５）、内部の原資金額カウンタを０にクリアし（ステップＳ２１７）、取引メニューを表示装置に表示する（ステップＳ２１９）。

このようにすれば、行員が関与することなく、大口の入金処理を実施することができるようになる。

次に、端子Ｉ以降の処理を図３８を用いて説明する。ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、例えば図２８に示すような取引確認画面を表示装置に表示する（ステップＳ２２１）。顧客は、内容を確認し、確認ボタンを押下げる。ＡＴＭ業務アプリケーション１０１は、顧客からの確認指示を受け付け、これに応答して、紙幣ユニット１０４及び硬貨ユニット１０５により差額を出金させる（ステップＳ２２３）。また、通番及び差額を含むＤＢ更新要求（完了）を勘定系サーバ１５０１に送信する（ステップＳ２２５）。勘定系サーバ１５０１は、ＡＴＭ１００２から通番及び差額を含むＤＢ更新要求（完了）を受信すると（ステップＳ２２７）、取引金額に差額を加算して新たな取引金額とし、差額を０とし、ステータス「済」として、通番に対応して取引管理ＤＢ１５０２に登録する（ステップＳ２２９）。ステップＳ２２９を実行すると、図３０に示すようなデータが取引管理ＤＢ１５０２に登録される。

そして、ＡＴＭ業務アプリケーション１０１は、取引結果（正常）をＡＴＭ１００２に送信する（ステップＳ２３１）。ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、勘定系サーバ１５０１から取引結果（正常）を受信し（ステップＳ２３３）、原資金額カウンタの値を０にクリアし（ステップＳ２３５）、取引メニューを表示装置に表示する（ステップＳ２３７）。

このような処理によって、差額の出金が必要となった場合においても、顧客自身がＡＴＭ１００２をそのまま操作することによって、適切に差額出金を行うことができるようになる。

（２）大口出金処理
（２−１）即時出金処理
例えば、行員が、取次カウンタ１００７において顧客から大口出金を依頼され、ＵＢＴ１００８によって当該ＵＢＴ１００８に隣接するリサイクルキャッシャ１００９から即時出金して顧客に指定された金額を手渡す場合の処理を図３９乃至図４９を用いて説明する。なお、本実施の形態では、出金金額を含む支払伝票の記入が必要となる。

まず、行員は、ＵＢＴ１００８のＯＣＲ２０２及び通帳処理部２０４に、顧客から受け取った通帳及び支払伝票を挿入して読み取りを行わせる（図３９：ステップＳ２４１）。ＯＣＲ２０２は、通帳及び支払伝票から、取引名「出金」及び出金金額をイメージ認識する。なお、ここでは印鑑の照合などについては既に完了しているものとする。また、通帳処理部２０４は、磁気ストライプから口座番号を読み取る。

ＵＢＴ１００８のＵＢＴ業務アプリケーション２０１は、ステップＳ２４１の認識結果から、口座番号及び出金金額を含む出金画面を表示装置に表示する（ステップＳ２４３）。例えば、図４０に示すような出金画面が表示される。図４０の例では、口座番号及び出金金額が含まれる。

行員は、出金画面を確認して、「完了キー」を押下げる。ＵＢＴ１００８のＵＢＴ業務アプリケーション２０１は、行員からの完了指示を受け付け、これに応答して、口座番号及び出金金額を含むホスト元帳更新要求を勘定系ホスト１２００に送信する（ステップＳ２４５）。勘定系ホスト１２００は、口座番号及び出金金額を含むホスト元帳更新要求を受信し、従来同様の出金に係るホスト元帳更新処理を実施する。そして、処理結果をＵＢＴ１００８に送信する。現物（現金）を出金する前に勘定系ホスト１２００における元帳を更新する。

ＵＢＴ１００８のＵＢＴ業務アプリケーション２０１は、受信した処理結果から勘定系ホスト１２００の処理が正常に終了したか判断する（ステップＳ２４７）。勘定系ホスト１２００の処理が異常終了であれば、ステップＳ２４５に戻る。勘定系ホスト１２００の処理が正常終了であれば、支払内訳画面を表示装置に表示する（ステップＳ２４９）。例えば図４１に示すような画面を表示する。図４１の例では、出金金額の表示欄と、小束（万札）の束数の入力欄、小束（千円札）の束数の入力欄とが設けられている。

行員は、図４１のような画面において、必要金種について束数の入力を行う。ＵＢＴ１００８のＵＢＴ業務アプリケーション２０１は、必要金種について束数の入力を受け付け（ステップＳ２５１）、出金金額、金種・束数及び端末種別情報（ＵＢＴ取次）を含む出金要求を勘定系サーバ１５０１に送信する（ステップＳ２５３）。

勘定系サーバ１５０１は、ＵＢＴ１００８から、口座番号、取引名、出金金額、金種・束数及び端末種別情報（ＵＢＴ取次）を含む出金要求を受信すると（ステップＳ２５５）、まず生死監視信号をリサイクルキャッシャ１００９に出力する（ステップＳ２５７）。リサイクルキャッシャ１００９のＲＣアプリケーション３０３は、生死監視信号を受信し、正常に起動しているか否かを確認する処理である正常起動チェック処理を実施する（ステップＳ２５９）。ＲＣアプリケーション３０３は、正常起動チェック処理のチェック結果を勘定系サーバ１５０１に送信する（ステップＳ２６１）。勘定系サーバ１５０１は、リサイクルキャッシャ１００９からチェック結果を受信し（ステップＳ２６３）、正常起動中であるか判断する（ステップＳ２６５）。正常起動中である場合については、端子Ｊを経由して図４５の処理に移行する。一方、正常起動中でなければ、エラー通知をＵＢＴ１００８に送信する（ステップＳ２６７）。ＵＢＴ１００８のＵＢＴ業務アプリケーション２０１は、勘定系サーバ１５０１からエラー通知を受信し、表示装置に表示する（ステップＳ２６９）。例えば、図４２に示すような画面が表示される。図４２の例では、図４１に示した支払内訳画面の下部に、「ＲＣ機に異常が発生しています。カセット装填後、事後出金にて継続処理してください」といったメッセージが表示される。処理は端子Ｋを介して図４３の処理に移行する。

端子Ｋを介して図４３の処理の説明に移行し、勘定系サーバ１５０１は、通番を発行し、通番、口座番号、取引名（出金）、原資金額（＝出金金額）、取引金額（＝原資金額）、金種・束数及びステータス「未済」を、取引管理ＤＢ１５０２に登録する（ステップＳ２７１）。例えば図４４に示すようなデータが取引管理ＤＢ１５０２に登録される。図４４の例では、通番「０００１」が発行され、当該通番「０００１」に対応して口座番号、取引名、原資金額、取引金額、金種・束数及びステータス「未済」が登録される。

そして、勘定系サーバ１５０１は、以下の処理のため、例えば発行した通番をＵＢＴ１００８に送信する（ステップＳ２７３）。ＵＢＴ１００８のＵＢＴ業務アプリケーション２０１は、勘定系サーバ１５０１から通番を受信し、表示装置に表示する（ステップＳ２７５）。このようにすれば、行員は、後に通番を用いてリサイクルキャッシャ１００９に対して出金操作を行うことができる。但し、ステップＳ２７３及びＳ２７５については、任意である。

次に図４５乃至図５３を用いて端子Ｊ以降の処理を説明する。勘定系サーバ１５０１は、稼働可能確認をリサイクルキャッシャ１００９に送信する（ステップＳ２７７）。リサイクルキャッシャ１００９のＲＣアプリケーション３０３は、勘定系サーバ１５０１から稼働可能確認を受信し（ステップＳ２７９）、出金機能について稼働可能確認を行うか、又は出金機能（具体的には小束ユニット３０４、紙幣ユニット３０５、硬貨ユニット３０６）を起動する（ステップＳ２８１）。そして処理結果（正常）を勘定系サーバ１５０１に送信する（ステップＳ２８３）。なお、出金機能が稼働可能な状態でなければ、処理結果（異常）を返信する場合もある。その場合には、勘定系サーバ１５０１は、ステップＳ２６７、Ｓ２６９及びＳ２７１を実行する。

勘定系サーバ１５０１は、処理結果（正常）をリサイクルキャッシャ１００９から受信すると（ステップＳ２８５）、在高チェック要求をリサイクルキャッシャ１００９に送信する（ステップＳ２８７）。リサイクルキャッシャ１００９のＲＣアプリケーション３０３は、勘定系サーバ１５０１から在高チェック要求を受信し（ステップＳ２８９）、在高管理ＤＢ３０２に対して在高チェックを実施する（ステップＳ２９１）。在高管理ＤＢ３０２は、例えば図４６に示すようなデータを格納している。図４６の例では、金種、現束数、出金予定束数がカセット毎に管理されている。ＲＣアプリケーション３０３は、在高管理ＤＢ３０２から図４６に示したようなデータを読み出す。そして、在高データとして勘定系サーバ１５０１に送信する（ステップＳ２９３）。

勘定系サーバ１５０１は、リサイクルキャッシャ１００９から在高データを受信すると（ステップＳ２９５）、通番を発行し、当該通番、口座番号、取引名（出金）、原資金額（出金金額）、取引金額（＝原資金額）、金種・束数、ステータス「未済」を取引管理ＤＢ１５０２に登録する（ステップＳ２９７）。

そして、勘定系サーバ１５０１は、出金に係る金種・束数が、在高（金種・束数）で賄うことができるか判断する（ステップＳ２９９）。出金に係る金種・束数が、在高（金種・束数）で賄うことができない場合には、ＵＢＴ１００８にエラー通知を送信する。在高は、（現束数−出金予定束数）で判断する。ＵＢＴ１００８のＵＢＴ業務アプリケーション２０１は、勘定系サーバ１５０１からエラー通知を受信し、表示装置に表示する（ステップＳ３０１）。例えば図４７に示すような画面が表示される。図４７の画面例では、図４１に示した画面の下部に、「ＲＣ機内在高が不足しています。カセット装填後、事後出金にて継続処理してください。」というメッセージが表示される。在高が不足しているので、現金を補充する必要がある。事後出金となるため、後に述べるようなリサイクルキャッシャ１００９に対する処理を実施する。

一方、出金に係る金種・束数が、在高で賄うことができる場合には、勘定系サーバ１５０１は、出金に係る金種・束数を含む出金予定束数登録要求をリサイクルキャッシャ１００９に送信する（ステップＳ３０３）。リサイクルキャッシャ１００９のＲＣアプリケーション３０３は、出金に係る金種・束数を含む出金予定束数登録要求を受信し（ステップＳ３０５）、出金予定束数を登録する（ステップＳ３０７）。これによって、例えば、図４８に示すようなデータが在高管理ＤＢ３０２に登録されるようになる。図４８の例では、万札の小束が装填されているカセット０００１に対応して出金予定束数５が登録されている。処理は、端子Ｌ及びＭを介して図４９の処理に移行する。

リサイクルキャッシャ１００９のＲＣアプリケーション３０３は、処理結果（正常）を勘定系サーバ１５０１に送信する（ステップＳ３０９）。勘定系サーバ１５０１は、リサイクルキャッシャ１００９から処理結果（正常）を受信すると（ステップＳ３１１）、ＵＢＴ１００８の端末種別がＵＢＴ取次であるか判断する（ステップＳ３１３）。端末種別がＵＢＴ取次でない場合には、端子Ｎを介して図５３の処理に移行する。端末種別がＵＢＴ取次ではない場合には、ＵＢＴから離れた位置にリサイクルキャッシャが配置されており、即時出金すると問題があるから、事後出金となる。

勘定系サーバ１５０１は、通番に対応して、ステータス「依頼中」を取引管理ＤＢ１５０２に登録する（ステップＳ３１５）。これによって、取引管理ＤＢ１５０２は、図５０のようなデータを格納している。図４４との差は、ステータスの部分のみである。そして、通番及び金種・束数を含む出金要求をリサイクルキャッシャ１００９に送信する（ステップＳ３１７）。リサイクルキャッシャ１００９のＲＣアプリケーション３０３は、通番及び金種・束数を含む出金要求を勘定系サーバ１５０１から受信する（ステップＳ３１９）。この際、出金機能の起動確認などの処理を実施するようにしても良い。そして、ＲＣアプリケーション３０３は、小束ユニット３０４等に、出金要求に係る金種・束数の出金処理を実施させる（ステップＳ３２１）。この例では、万札の小束が５束リサイクルキャッシャ１００９から出金される。リサイクルキャッシャ１００９は、出金が完了すれば、処理結果（正常）を勘定系サーバ１５０１に送信する（ステップＳ３２３）。また、在高管理ＤＢ３０２において在高の更新処理を実施する（ステップＳ３２７）。これによって図５１に示すようなデータが在高管理ＤＢ３０２に登録されるようになる。図５１の例では、カセット０００１の現束数を、（現束数−出金予定束数）を登録する。また、出金予定束数を、出金した束数だけ減算する。

勘定系サーバ１５０１は、処理結果（正常）をリサイクルキャッシャ１００９から受信し（ステップＳ３２５）、リサイクルキャッシャ１００９において処理が正常終了したか否かを判断する（ステップＳ３２９）。何らかの理由で異常終了している場合には、異常メッセージをＵＢＴ１００８に送信する。ＵＢＴ１００８のＵＢＴ業務アプリケーション２０１は、異常メッセージを受信し、表示装置に表示する（ステップＳ３３１）。

さらに勘定系サーバ１５０１は、通番に対応してステータス「済」を取引管理ＤＢ１５０２に登録する（ステップＳ３３３）。これによって例えば図５２に示すようなデータが取引管理ＤＢ１５０２に登録される。図５０との差は、ステータスの部分のみである。ここまで実施すると、処理終了をＵＢＴ１００８に通知する（ステップＳ３３５）。

ＵＢＴ１００８のＵＢＴ業務アプリケーション２０１は、勘定系サーバ１５０１から処理終了の通知を受けると、表示装置に表示する（ステップＳ３３７）。

このようにすれば、リサイクルキャッシャ１００９がＵＢＴ１００８に隣接している場合、即時出金して迅速に顧客に大口出金に係る現金を渡すことができるようになる。

（２−２）事後出金処理（遠隔ＵＢＴからの指示）
例えばリサイクルキャッシャ１００９が設けられておらず、リサイクルキャッシャ１００３から大口出金を行う場合には、いずれのＵＢＴからも離れた位置にリサイクルキャッシャが配置されることになるので、出金が即時に行われると問題が生ずる。そこで事後出金処理を実施する。

具体的には、即時出金と同様の処理を実施するが、ＵＢＴ１００８の端末種別情報がＵＢＴクイックとなっているので、ステップＳ３１３でＮｏルートに移行して端子Ｎ以降の処理が行われる。すなわち、通番に対応してステータス「依頼中」を取引管理ＤＢ１５０２に登録する（図５３：ステップＳ３３９）。例えば、図５０のようなデータが取引管理ＤＢ１５０２に登録される。そして、勘定系サーバ１５０１は、通番を含む予約完了通知をＵＢＴ１００８に送信する（ステップＳ３４１）。

ＵＢＴ１００８は、通番を含む予約完了通知を受信すると（ステップＳ３４３）、通番を含む予約完了表示を実施する（ステップＳ３４５）。通番を行員に提示することによって、リサイクルキャッシャ１００９において通番に基づき検索を行うことができるようになる。

そして、行員はリサイクルキャッシャ１００３のところに行き、リサイクルキャッシャ１００３を操作する。そうすると図５４乃至図６０のような処理が行われる。行員は、リサイクルキャッシャ１００３に行員カードを挿入等して、行員のＩＤを読み取らせる。リサイクルキャッシャ１００３のカード読取部３０８は、行員カードの読み取りを行って、行員のＩＤを特定し、ＲＣアプリケーション３０３は、利用者認証画面を表示装置に表示する（ステップＳ３５１）。例えば、図５５に示すような画面が表示される。すなわち、行員に、パスワードの入力を促す。行員は、図５５のような画面にパスワードを入力する。

リサイクルキャッシャ１００３のＲＣアプリケーション３０３は、パスワードの入力を受け付け、行員ＩＤを用いて利用者管理ＤＢ３０９を検索して登録パスワードを読み出し、入力されたパスワードと登録パスワードとを比較する認証処理を実施する（ステップＳ３５３）。認証が失敗すれば（ステップＳ３５５：Ｎｏルート）、エラー表示を表示装置に行って（ステップＳ３５７）、ステップＳ３５１に戻る。一方、認証が成功すれば（ステップＳ３５５：Ｙｅｓルート）、検索画面を表示装置に表示する（ステップＳ３５９）。例えば図５６に示すような画面が表示される。図５６の例では、検索条件として、日時、通番、金額、口座番号を指定することができるようになっている。行員は、図５６の画面において検索条件を入力する。

リサイクルキャッシャ１００３のＲＣアプリケーション３０３は、検索条件の入力を受け付け（ステップＳ３６１）、検索条件を含むＤＢ検索要求を勘定系サーバ１５０１に送信する（ステップＳ３６３）。勘定系サーバ１５０１は、リサイクルキャッシャ１００３から検索条件を含むＤＢ検索要求を受信し、検索条件に従って取引管理ＤＢ１５０２（図５７）に対して検索を実施する（ステップＳ３６５）。そして、検索結果をリサイクルキャッシャ１００３に送信する（ステップＳ３６７）。リサイクルキャッシャ１００３のＲＣアプリケーション３０３は、検索結果を受信し、表示装置に表示する（ステップＳ３６９）。例えば図５８に示すような画面が表示される。図５８の例では、図５７に示した取引管理ＤＢ１５０２に格納されたデータと、処理すべき通番の入力欄と、指示内容の表示欄とが設けられている。この例では、例えばテンキーで１を指定すると出金を行い、２を指定すると詳細照会を行い、９を指定するとキャンセルとなる。ここでは、行員は、通番０００１と「１」の出金を指示する。

そうすると、リサイクルキャッシャ１００３のＲＣアプリケーション３０３は、通番及び出金の指示入力を受け付け（ステップＳ３７１）、指示された通番と当該通番に対応する金種・束数を含む出金要求を勘定系サーバ１５０１に送信する（ステップＳ３７３）。勘定系サーバ１５０１は、リサイクルキャッシャ１００３から通番及び金種・束数を含む出金要求を受信し（ステップＳ３７５）、通番に対応するステータス「依頼中」を取引管理ＤＢ１５０２に登録する（ステップＳ３７７）。なお、すでにステップＳ３９９を経ていて「依頼中」となっていれば、ステップＳ３７７は不要である。ただし、必ずしもステップＳ３３９を経由するわけではない。例えば図５９に示すようなデータが取引管理ＤＢ１５０２に登録されるようになる。なお、図５７との差はステータスの部分のみである。そして、処理結果（正常）をリサイクルキャッシャ１００３に送信する（ステップＳ３７９）。

リサイクルキャッシャ１００３のＲＣアプリケーション３０３は、処理結果（正常）を受信する（ステップＳ３８１）。そして、端子Ｐを介して図６０の処理に移行する。なお、勘定系サーバ１５０１の処理が異常終了する場合もあるが、その場合には以下の処理を実施しないで検索画面に戻る。

図６０の処理の説明に移行して、リサイクルキャッシャ１００３のＲＣアプリケーション３０３は、出金機能の動作チェックを行う（ステップＳ３８３）。必要であれば出金機能を再起動させる。そして、指示された通番に対応する金種・束数で、小束ユニット３０４に出金させる（ステップＳ３８５）。行員は、現金取り出し口における小束を取り出す。そして、リサイクルキャッシャ１００３のＲＣアプリケーション３０３は、在高管理ＤＢ３０２を更新する（ステップＳ３８７）。具体的には、（現束数−出金予定束数）を現束数に登録し、（出金予定束数−出力束数）を出金予定束数に登録する。このような処理を実施すると図５１に示すようなデータが在高管理ＤＢ３０２に登録される。さらに、通番を含む出金完了通知を勘定系サーバ１５０１に送信する（ステップＳ３８９）。

勘定系サーバ１５０１は、リサイクルキャッシャ１００３から通番を含む出金完了通知を受信すると（ステップＳ３９１）、通番に対応してステータス「済」を取引管理ＤＢ１５０２に登録する（ステップＳ３９３）。例えば図５２のようなデータが取引管理ＤＢ１５０２に登録されるようになる。さらに、処理結果（正常）をリサイクルキャッシャ１００３に送信する（ステップＳ３９５）。リサイクルキャッシャ１００３は、勘定系サーバ１５０１から処理結果（正常）を受信し（ステップＳ３９７）、検索画面（図５６）を再度表示装置に表示する（ステップＳ３９９）。

このような処理を実施することによって、適切なタイミングで行員が大口出金に係る小束をリサイクルキャッシャ１００３から取り出すことができるようになる。

（２−３）ＡＴＭからの出金指示を行った場合
上で述べた処理では行員側で大口出金を指示しているが、本実施の形態ではＡＴＭ１００２を顧客が操作することによって、大口出金を指示することも可能である。以下図６１乃至図６７を用いて説明する。

ＡＴＭ１００２は、図２５に示すような取引メニューを表示している（ステップＳ４０１）。顧客は、ここでは出金ボタンを押下げ、ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、出金指示を受け付け、カード及び通帳の挿入を顧客に対して促す。そして、顧客はカード及び通帳をＡＴＭ１００２に挿入する。ＡＴＭ１００２の通帳処理部１０３及びカード処理部１０２は、カード及び通帳の挿入を受け付け（ステップＳ４０３）、カード及び通帳の読み取り処理を実施する（ステップＳ４０５）。これによって口座番号のデータを取得する。そして、出金画面を表示装置に表示する（ステップＳ４０７）。例えば図６２に示すような画面が表示される。図６２の例では、口座番号の表示欄と、パスワード及び出金金額の入力欄とが設けられている。顧客は、パスワードの入力欄にパスワードを入力し、出金金額の入力欄に出金金額を入力する。

ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、パスワード及び出金金額の入力を受け付け（ステップＳ４０９）、勘定系ホスト１２００に口座番号、パスワード及び出金金額を含む元帳更新データを送信する（ステップＳ４１１）。勘定系ホスト１２００は、ＡＴＭ１００２から口座番号、パスワード及び出金金額を含む元帳更新データを受信し、元帳更新データを用いて従来と同じ元帳更新処理を実施する。そして処理結果をＡＴＭ１００２に送信する。なお、パスワードが間違っていたり残高が足りない場合に異常と判断され、パスワードが正しく残高が足りている場合には正常と判断される。

ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、勘定系ホスト１２００から処理結果を受信し、勘定系ホスト１２００の処理が正常に終了したか判断する（ステップＳ４１３）。異常であると判断された場合には、エラー表示を表示装置に対して行う（ステップＳ４１５）。そしてステップＳ４０９に戻る。

一方、正常と判断された場合には、出金金額が２００万円を超えるか判断する（ステップＳ４１７）。出金金額が２００万円以下である場合には、従来と同じでＡＴＭ１００２単独で処理できるので、これ以上説明しない（ステップＳ４１９）。出金金額が２００万円を超える場合には、通帳処理部１０３は、出金金額を通帳に記帳する（ステップＳ４２１）。また、ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、図４１に示したような画面を表示装置に表示する（ステップＳ４２３）。ここで、顧客は、必要な金種の束数を入力する。なお、出金金額を超えることになる金種・束数を指定することはできない。ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、金種・束数の入力を受け付ける（ステップＳ４２５）。そして、端子Ｑを介して図６３の処理に移行する。

図６３の処理の説明に移行して、ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、口座番号、取引名（出金）、取引金額、金種・束数及び端末種別情報（ＡＴＭ）を含む出金要求を、勘定系サーバ１５０１に送信する（ステップＳ４２７）。勘定系サーバ１５０１は、口座番号、取引名（出金）、取引金額、金種・束数及び端末種別情報（ＡＴＭ）を含む出金要求を受信し（ステップＳ４２９）、リサイクルキャッシャ１００３に生死監視要求を送信する（ステップＳ４３１）。

リサイクルキャッシャ１００３のＲＣアプリケーション３０３は、生死監視要求を勘定系サーバ１５０１から受信すると、チェック処理を実施する（ステップＳ４３３）。チェック処理では、何らかの異常状態ではないかを確認する。そして、チェック処理の処理結果を勘定系サーバ１５０１に返信する（ステップＳ４３５）。勘定系サーバ１５０１は、リサイクルキャッシャ１００３から処理結果を受信し（ステップＳ４３７）、リサイクルキャッシャ１００３が正常であるか判断する（ステップＳ４３９）。正常である場合には端子Ｒを介して図６５の処理に移行する。一方異常である場合には、エラー通知をＡＴＭ１００２に送信する（ステップＳ４４１）。ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、勘定系サーバ１５０１からエラー通知を受信し、表示装置に表示を行う（ステップＳ４４３）。例えば、図６４に示すような画面を表示する。すなわち、図４１の下部に、「ＲＣ機に異常が発生しています。係員をお呼びください。」というようなメッセージが表示される。顧客は、営業店のロビーにおける係員を呼ぶことになる。

一方、勘定系サーバ１５０１は、通番を発行し、口座番号、取引名（出金）、取引金額、金種・束数及びステータス「未済」を取引管理ＤＢ１５０２に登録する（ステップＳ４４５）。

このようにすれば、リサイクルキャッシャ１００３に異常が発生している場合においても勘定系サーバ１５０１により取引管理ＤＢ３０２に登録されているレコードに応じて、後に適切に出金することができる。

次に、端子Ｒ以降の処理を図６５乃至図６７を用いて説明する。勘定系サーバ１５０１は、稼働可能確認をリサイクルキャッシャ１００９に送信する（ステップＳ４４７）。リサイクルキャッシャ１００３のＲＣアプリケーション３０３は、勘定系サーバ１５０１から稼働可能確認を受信し（ステップＳ４４９）、出金機能について稼働可能確認を行うか、又は出金機能（具体的には小束ユニット３０４、紙幣ユニット３０５、硬貨ユニット３０６）を起動する（ステップＳ４５１）。そして処理結果（正常）を勘定系サーバ１５０１に送信する（ステップＳ４５３）。なお、出金機能が稼働不可能な状態でなければ、処理結果（異常）を返信する場合もある。その場合には、勘定系サーバ１５０１は、ステップＳ４４１及びＳ４４３を実行する。

勘定系サーバ１５０１は、処理結果（正常）をリサイクルキャッシャ１００３から受信すると（ステップＳ４５５）、在高チェック要求をリサイクルキャッシャ１００３に送信する（ステップＳ４５７）。リサイクルキャッシャ１００３のＲＣアプリケーション３０３は、勘定系サーバ１５０１から在高チェック要求を受信し（ステップＳ４５９）、在高管理ＤＢ３０２に対して在高チェックを実施する（ステップＳ４６１）。在高管理ＤＢ３０２は、例えば図４６に示すようなデータを格納している。ＲＣアプリケーション３０３は、在高管理ＤＢ３０２から図４６に示したようなデータを読み出す。そして、在高データとして勘定系サーバ１５０１に送信する（ステップＳ４６３）。

勘定系サーバ１５０１は、リサイクルキャッシャ１００３から在高データを受信すると（ステップＳ４６５）、通番を発行し、当該通番、口座番号、取引名（出金）、原資金額（出金金額）、取引金額（＝原資金額）、金種・束数、ステータス「未済」を取引管理ＤＢ１５０２に登録する（ステップＳ４６７）。

そして、勘定系サーバ１５０１は、出金に係る金種・束数が、在高（金種・束数）で賄うことができるか判断する（ステップＳ４６９）。出金に係る金種・束数が、在高（金種・束数）で賄うことができない場合には、ＡＴＭ１００２にエラー通知を送信する（ステップＳ４７１）。在高は、（現束数−出金予定束数）で判断する。ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、勘定系サーバ１５０１からエラー通知を受信し、表示装置に表示する（ステップＳ４７３）。例えば図６６に示すような画面が表示される。図６６の画面例では、図４１に示した画面の下部に、「ＲＣ機内在高が不足しています。係員をお呼びください。」というメッセージが表示される。顧客は、営業店のロビーにおける係員を呼ぶことになる。一方、出金に係る金種・束数が、在高で賄うことができる場合には、端子Ｓを介して図６７の処理に移行する。

図６７の処理の説明に移行して、勘定系サーバ１５０１は、出金に係る金種・束数を含む出金予定束数登録要求をリサイクルキャッシャ１００３に送信する（ステップＳ４７５）。リサイクルキャッシャ１００３のＲＣアプリケーション３０３は、出金に係る金種・束数を含む出金予定束数登録要求を受信し（ステップＳ４７７）、出金予定束数を更新登録する（ステップＳ４７９）。これによって、例えば、図４８に示すようなデータが在高管理ＤＢ３０２に登録されるようになる。

リサイクルキャッシャ１００３のＲＣアプリケーション３０３は、処理結果（正常）を勘定系サーバ１５０１に送信する（ステップＳ４８１）。勘定系サーバ１５０１は、リサイクルキャッシャ１００３から処理結果（正常）を受信すると（ステップＳ４８３）、ＵＢＴ１００８の端末種別がＵＢＴ取次であるか判断する（ステップＳ４８５）。端末種別がＵＢＴ取次である場合には、端子Ｔを介して図４９のステップＳ３１３に移行する。端末種別がＵＢＴ取次ではない場合には、通番に対応してステータス「依頼中」を取引管理ＤＢ３０２に登録する（ステップＳ４８７）。そして、通番を含む処理結果（正常）をＡＴＭ１００２に送信する（ステップＳ４８９）。

ＡＴＭ１００２のＡＴＭ業務アプリケーション１０１は、勘定系サーバ１５０１から通番を含む処理結果（正常）を受信し（ステップＳ４９１）、処理終了を表示画面に表示すると共に、預かり票印字部１０７により、通番、口座番号などを含む預かり票を印字して出力する（ステップＳ４９３）。なお、カード処理部１０２はカードを排出し、通帳処理部１０３は、通帳を排出する。

顧客は、預かり票を持って取次カウンタ１００７に行き、行員にリサイクルキャッシャ１００３から現金を取ってくるように依頼する。行員は、上で述べたようにリサイクルキャッシャ１００３に対する操作を行って、現金をリサイクルキャッシャ１００３から取り出す。

このように、ＡＴＭ、ＵＢＴ、勘定系サーバなどを連携させて、行員が現金に触る機会を減らすことによって、行員の事務作業を減少させることができ、他の業務にリソースを振り向けることができるようになる。

以上本発明の一実施の形態を説明したが、本発明は、これに限定されるものではない。例えば、営業店における機器の配置などは図１に限定されるものではなく、他の配置を採用するようにしても良い。

また図３乃至図５に示した機能ブロック図は、一例であって必ずしも装置のモジュール及びプログラム・モジュールに対応するものではない。さらに、図２に示したネットワーク構成についてもこれに限定されるものではない。

さらに、上で述べた画面例は全て一例であって、これについても限定されるものではない。取引管理ＤＢ１５０２についても、出金及び入金ではデータを分けて管理するようにしても良い。

また、複数のリサイクルキャッシャが営業店内に設置されている場合には、出金要求元のＵＢＴに最も近いリサイクルキャッシャを特定し、できるだけ即時出金できるようにしてもよい。

リサイクルキャッシャにおけるログＤＢ３０１には、行員や顧客の操作ログが記録され、取引管理ＤＢ１５０１にも取引のレコードが記録されるため、これらのデータを用いて不正を防止することも可能となる。

さらに、取引管理ＤＢ１５０１を例えば営業終了時に確認して、ステータス「済」となっていないような取引がないかチェックすることによって、手続きが途中で中断していないかを確認できる。

また、２００万円を基準にした処理については、２００万円でなくとも良い。ＡＴＭでより多くの金額を一度に取り扱うことができれば、２００万円を超える金額を設定しても良いし、より少ない金額しか取り扱うことができなければ少ない金額が設定される。

また、勘定系サーバ１５０１、ＵＢＴ１００６，１００８及び１０１０等のコンピュータについては、図６８のようなコンピュータ装置であって、メモリ２５０１（記憶装置）とＣＰＵ２５０３（処理装置）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施の形態における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施の形態では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

（付記１）
現金を所定枚数毎に束ねて小束として保持する現金取扱機器を制御する方法であって、
前記現金取扱機器からの小束の出金を要求し且つ端末種別情報を含む出金要求を端末から受信するステップと、
前記現金取扱機器が前記出金要求に係る小束を出金可能であるか判断する第１判断ステップと、
前記出金要求に含まれる前記端末種別情報が前記出金要求の要求元の端末に前記現金取扱機器が隣接配置されていることを表しているか判断する第２判断ステップと、
前記第１及び第２判断ステップにおいて肯定的な判断がなされた場合には、前記現金取扱機器に前記出金要求に係る小束の出金を指示するステップと、
を含む制御方法。

（付記２）
前記第１判断ステップが、
現時点における前記現金取扱機器の小束の在高を確認するステップと、
前記小束の在高によって前記出金要求に応じることができるか判断する在高ステップと、
を含む付記１記載の制御方法。

（付記３）
前記第１判断ステップが、
前記小束の在高によって前記出金要求に応じることができると判断された場合には、前記出金要求に係る出金予定束数を前記現金取扱機器に登録させるステップ
をさらに含む付記２記載の制御方法。

（付記４）
前記在高ステップが、
前記現時点における出金予定束数を考慮して前記小束の在高を把握するステップ
を含む付記３記載の制御方法。

（付記５）
前記出金要求に対応して、当該出金要求の識別情報と前記出金要求に係る小束データと出金が未完であることを表す状態データとを含むレコードを生成して取引管理データベースに登録するステップと、
前記現金取扱機器から前記出金要求の識別情報を含む出金完了が通知されると、前記取引管理データベースにおいて前記出金要求の識別情報に対応する前記状態データを出金完了を表すように変更するステップと、
をさらに含む付記１記載の制御方法。

（付記６）
前記第１判断ステップにおいて否定的な判断がなされた場合には、エラー通知を前記出金要求の要求元の端末に送信するステップ
をさらに含む付記１記載の制御方法。

（付記７）
前記第２判断ステップにおいて否定的な判断がなされた場合には、出金予約完了を前記出金要求の要求元の端末に通知するステップ
をさらに含む付記３記載の制御方法。

（付記８）
前記第２判断ステップにおいて否定的な判断がなされ且つ前記出金要求の要求元の端末が預金者が操作する端末である場合には、当該端末に前記出金要求がなされたことを表す帳票を出力させるステップ
をさらに含む付記１記載の制御方法。

（付記９）
前記現金取扱機器から前記取引管理データベースの検索要求を受信した場合、前記取引管理データベースを管理するサーバにより前記取引管理データベースから該当レコードを抽出し、前記現金取扱機器に送信するステップと、
前記現金取扱機器において、前記取引管理データベースからの抽出該当レコードを基に処理すべき出金要求を特定し、特定された前記出金要求に係る小束を出金するステップと、

前記現金取扱機器において、前記出金に応じて小束の在高データを更新するステップと、
前記現金取扱機器から、特定された前記出金要求の識別情報を含む出金完了を前記サーバに通知するステップと、
をさらに含む付記５記載の制御方法。

（付記１０）
付記１乃至８記載の制御方法をコンピュータに実行させるためのプログラム。

（付記１１）
現金取扱機器において顧客により入金され且つ当該顧客の口座番号を特定することなく計数された現金の金額を、原資金額として口座番号とは別の入金識別情報に対応して取引管理データベースに登録する第１登録ステップと、
前記現金取扱機器とは別の端末において特定された前記顧客の口座番号と前記原資金額以下の取引金額とを用いて、ホスト元帳を更新させるステップと、
前記顧客の口座番号と前記原資金額以下の取引金額とを、前記入金識別情報に対応して前記取引管理データベースに登録する第２登録ステップと、
を含み、コンピュータにより実行される入金管理方法。

（付記１２）
前記原資金額と前記取引金額との差額が０ではないが取引完了が前記端末において指示された場合に、前記差額の金額を前記入金識別情報に対応して前記取引管理データベースに登録するステップと、
現金を出金可能な端末において前記入金識別情報を指定して前記差額の精算を指示された場合、前記現金を出金可能な端末において前記差額を出金するステップと、
前記現金を出金可能な端末において前記差額の出金が完了した場合、前記取引管理データベースにおいて前記入金識別情報に対応する前記差額の金額を０に且つ前記取引金額を前記原資金額と同じ金額に更新するステップと、
をさらに含む付記１１記載の入金管理方法。

（付記１３）
前記別の端末であるＡＴＭにおいて、前記原資金額と前記取引金額との差額が０ではないが差額精算が指示された場合に、前記差額を出金するステップ
をさらに含み、
前記ＡＴＭにおいて前記差額の出金が完了した場合、前記取引金額を前記原資金額と同額として前記第２登録ステップを実行する
付記１１記載の入金管理方法。

（付記１４）
前記第１登録ステップにおいて、前記入金識別情報に対応して前記顧客により入力されたパスワードを前記取引管理データベースに登録し、
前記別の端末であるＡＴＭにおいて、前記入金識別情報と前記パスワードの入力を促し、前記取引管理データベースに登録されている前記入金識別情報と前記パスワードとの対を用いて認証処理を実施するステップ
をさらに含む付記１３記載の入金管理方法。

（付記１５）
現金を所定枚数毎に束ねて小束として保持する現金取扱機器を制御する装置であって、
前記現金取扱機器からの小束の出金を要求し且つ端末種別情報を含む出金要求を端末から受信する手段と、
前記現金取扱機器が前記出金要求に係る小束を出金可能であるか判断する第１判断手段と、
前記出金要求に含まれる前記端末種別情報が前記出金要求の要求元の端末に前記現金取扱機器が隣接配置されていることを表しているか判断する第２判断手段と、
前記第１及び第２判断手段によって肯定的な判断がなされた場合には、前記現金取扱機器に前記出金要求に係る小束の出金を指示する手段と、
を有する制御装置。

（付記１６）
現金を所定枚数毎に束ねて小束として保持する現金取扱機器と、
制御装置と、
端末装置と、
を有し、
前記制御装置は、
前記現金取扱機器からの小束の出金を要求し且つ端末種別情報を含む出金要求を前記端末から受信する手段と、
前記現金取扱機器が前記出金要求に係る小束を出金可能であるか判断する第１判断手段と、
前記出金要求に含まれる前記端末種別情報が前記出金要求の要求元の端末に前記現金取扱機器が隣接配置されていることを表しているか判断する第２判断手段と、
前記第１及び第２判断手段によって肯定的な判断がなされた場合には、前記現金取扱機器に前記出金要求に係る小束の出金を指示する手段と、
を有する現金出金システム。

（付記１７）
顧客により入金された現金を当該顧客の口座番号を特定することなく計数する現金取扱機器と、
前記現金取扱機器とは別の端末と、
取引管理データベースを管理する勘定系サーバと、
を有し、
前記勘定系サーバは、
前記現金取扱機器において特定された入金金額を原資金額として口座番号とは別の入金識別情報に対応して前記取引管理データベースに登録する第１登録手段と、
前記端末において特定された前記顧客の口座番号と前記原資金額以下の取引金額とを用いたホスト元帳更新処理の後に、前記顧客の口座番号と前記原資金額以下の取引金額とを、前記入金識別情報に対応して前記取引管理データベースに登録する第２登録手段と、
を有する入金処理システム。

本発明の実施の形態における銀行の営業店のレイアウト例を示す図である。 本発明の実施の形態における銀行の営業店のシステム構成例を示す図である。 本発明の実施の形態におけるＡＴＭの機能ブロック図である。 本発明の実施の形態におけるＵＢＴの機能ブロック図である。 本発明の実施の形態におけるリサイクルキャッシャの機能ブロック図である。 大口入金の処理フロー（第１部分）を示す図である。 取引管理ＤＢに格納されるデータ例を示す図である。 取引内容確認画面の一例を示す図である。 取引管理ＤＢに格納されるデータ例を示す図である。 受付票の一例を示す図である。 取引ジャーナルの一例を示す図である。 大口入金の処理フロー（第２部分）を示す図である。 原資設定画面の一例を示す図である。 取引管理ＤＢに格納されるデータ例を示す図である。 原資設定画面の一例を示す図である。 入金画面の一例を示す図である。 大口入金の処理フロー（第３部分）を示す図である。 原資設定・解除画面の一例を示す図である。 大口入金の処理フロー（第４部分）を示す図である。 取引管理ＤＢに格納されるデータ例を示す図である。 原資設定・解除画面の一例を示す図である。 大口入金の処理フロー（第５部分）を示す図である。 取引管理ＤＢに格納されるデータ例を示す図である。 大口入金の処理フロー（第６部分）を示す図である。 取引メニュー画面の一例を示す図である。 取引確認画面の一例を示す図である。 取引管理ＤＢに格納されるデータ例を示す図である。 取引確認画面の一例を示す図である。 大口入金の処理フロー（第７部分）を示す図である。 取引管理ＤＢに格納されるデータ例を示す図である。 大口入金の処理フロー（第８部分）を示す図である。 原資設定画面の一例を示す図である。 大口入金の処理フロー（第９部分）を示す図である。 入金画面の一例を示す図である。 入金画面の一例を示す図である。 大口入金の処理フロー（第１０部分）を示す図である。 原資設定・解除画面の一例を示す図である。 大口入金の処理フロー（第１１部分）を示す図である。 大口出金の処理フロー（第１部分）を示す図である。 出金画面の一例を示す図である。 支払内訳画面の一例を示す図である。 支払内訳画面の一例を示す図である。 大口出金の処理フロー（第２部分）を示す図である。 取引管理ＤＢに格納されるデータの一例を示す図である。 大口出金の処理フロー（第３部分）を示す図である。 在高管理ＤＢに格納されるデータの一例を示す図である。 支払内訳画面の一例を示す図である。 在高管理ＤＢに格納されるデータの一例を示す図である。 大口出金の処理フロー（第４部分）を示す図である。 取引管理ＤＢに格納されるデータの一例を示す図である。 在高管理ＤＢに格納されるデータの一例を示す図である。 取引管理ＤＢに格納されるデータの一例を示す図である。 大口出金の処理フロー（第５部分）を示す図である。 大口出金の処理フロー（第６部分）を示す図である。 利用者認証画面の一例を示す図である。 検索画面の一例を示す図である。 取引管理ＤＢに格納されるデータの一例を示す図である。 検索結果画面の一例を示す図である。 取引管理ＤＢに格納されるデータの一例を示す図である。 大口出金の処理フロー（第７部分）を示す図である。 大口出金の処理フロー（第８部分）を示す図である。 出金画面の一例を示す図である。 大口出金の処理フロー（第９部分）を示す図である。 支払内訳画面の一例を示す図である。 大口出金の処理フロー（第１０部分）を示す図である。 支払内訳画面の一例を示す図である。 大口出金の処理フロー（第１１部分）を示す図である。 コンピュータの機能ブロック図である。

符号の説明

１１０１，１１０２ ネットワーク
１２００ 勘定系ホスト
１００３，１００９ リサイクルキャッシャ
１００２，１００５ ＡＴＭ
１００８，１００６，１０１１ ＵＢＴ
１５０１ 勘定系サーバ
１５０２ 取引管理ＤＢ

Claims (5)

1. 現金を所定枚数毎に束ねて小束として保持する現金取扱機器を制御する方法であって、
   前記現金取扱機器からの小束の出金を要求し且つ端末種別情報を含む出金要求を端末から受信するステップと、
   前記現金取扱機器が前記出金要求に係る小束を出金可能であるか判断する第１判断ステップと、
   前記出金要求に含まれる前記端末種別情報が前記出金要求の要求元の端末に前記現金取扱機器が隣接配置されていることを表しているか判断する第２判断ステップと、
   前記第１及び第２判断ステップにおいて肯定的な判断がなされた場合には、前記現金取扱機器に前記出金要求に係る小束の出金を指示するステップと、
   を含む制御方法。
2. 前記第１判断ステップが、
   現時点における前記現金取扱機器の小束の在高を確認するステップと、
   前記小束の在高によって前記出金要求に応じることができるか判断する在高ステップと、
   を含む請求項１記載の制御方法。
3. 前記第１判断ステップにおいて否定的な判断がなされた場合には、エラー通知を前記出金要求の要求元の端末に送信するステップ
   をさらに含む請求項１記載の制御方法。
4. 前記第２判断ステップにおいて否定的な判断がなされ且つ前記出金要求の要求元の端末が預金者が操作する端末である場合には、当該端末に前記出金要求がなされたことを表す帳票を出力させるステップ
   をさらに含む請求項１記載の制御方法。
5. 現金を所定枚数毎に束ねて小束として保持する現金取扱機器を制御する装置であって、
   前記現金取扱機器からの小束の出金を要求し且つ端末種別情報を含む出金要求を端末から受信する手段と、
   前記現金取扱機器が前記出金要求に係る小束を出金可能であるか判断する第１判断手段と、
   前記出金要求に含まれる前記端末種別情報が前記出金要求の要求元の端末に前記現金取扱機器が隣接配置されていることを表しているか判断する第２判断手段と、
   前記第１及び第２判断手段によって肯定的な判断がなされた場合には、前記現金取扱機器に前記出金要求に係る小束の出金を指示する手段と、
   を有する制御装置。

Images