(57)【要約】【課題】  ＡＴＭなどを介した取引であって、複数の取引を一括して行う場合に、複数の伝票類を使用する際の効率的な処理を行うことを課題とする。特に、複数の伝票類が混在しても、取引の有効性を確認することをその目的とする。【解決手段】  取引端末に投入された伝票類の種別を認識し、認識結果に応じたそれぞれの有効性のチェックを行うものであり、その結果に応じて警告を出力する。また、本発明には、代行者の端末(行員端末)により操作が行われている場合でも、取引希望者が操作する端末(取引端末)からの警告に対する回答を受け付けるように制御することも含まれる。  さらに、認識結果に応じたそれぞれの有効性チェックの後に、過去の取引パターンと比較して、その結果に応じて警告を出力することも本発明に含まれる。なお、この際も上述のように、取引希望者の端末からの警告に対する回答を受け付けるように制御してもよい。【選択図】  図１
2011034524.tif 000002
【特許請求の範囲】
【請求項１】
複数の取引を支援するための取引支援方法において、
前記取引を希望する取引希望者が利用する取引端末の操作について、前記取引に関する行員が利用する行員端末に引き継ぐ制御を当該行員端末からの要求に応じて、前記取引端末および前記行員端末に接続されたサーバ装置が実行可能であって、
前記取引端末が、前記取引希望者から複数の伝票類を受け付け、
前記取引端末が、前記複数の伝票類それぞれの認識データを検知し、
前記取引端末が、前記サーバ装置に、前記認識データを送信し、
前記サーバ装置が、前記認識データを用いて、前記複数の伝票類それぞれの種別を特定し、
前記サーバ装置が、特定された種別ごとのチェック処理をそれぞれ実行し、
前記サーバ装置が、前記チェック処理の結果に応じて警告情報を出力することを特徴とする取引支援方法。
【請求項２】
請求項１に記載の取引支援方法において、
前記サーバ装置は、前記行員端末に引き継ぐ制御を実行した場合であっても、前記警告情報を、前記取引端末に出力することを特徴とする取引支援方法。
【請求項３】
請求項１または２のいずれかに記載の取引支援方法において、
前記複数の伝票類は、前記取引に使用される小切手、手形、伝票および通帳のうち少なくとも1種類が含まれることを特徴とする取引支援方法。
【請求項４】
請求項１乃至３のいずれかに記載の取引支援方法において、
前記サーバ装置は、前記取引希望者の過去の取引パターンを記憶しておき、
前記サーバ装置は、前記チェック処理の後に、前記取引パターンと前記取引の内容を比較し、当該比較の結果に応じて、警告情報を出力することを特徴とする取引支援方法。
【請求項５】
請求項４に記載の取引支援方法において、
前記サーバ装置は、前記比較の結果に応じた警告情報を、前記行員端末に引き継ぐ制御を実行した場合であっても、前記取引端末に出力することを特徴とする取引支援方法。
【請求項６】
複数の取引を支援するための取引支援システムであって、前記取引を希望する取引希望者が利用する取引端末と、前記取引に関する行員が利用する行員端末と、前記取引端末および前記行員端末に接続されたサーバ装置からなる取引支援システムにおいて、
前記取引端末の操作について、前記行員端末に引き継ぐ制御を当該行員端末からの要求に応じて、前記サーバ装置が実行可能であって、
前記取引端末が、前記取引希望者から複数の伝票類を受け付け、
前記取引端末が、前記複数の伝票類それぞれの認識データを検知し、
前記取引端末が、前記サーバ装置に、前記認識データを送信し、
前記サーバ装置が、前記認識データを用いて、前記複数の伝票類それぞれの種別を特定し、
前記サーバ装置が、特定された種別ごとのチェック処理をそれぞれ実行し、
前記サーバ装置が、前記チェック処理の結果に応じて警告情報を出力することを特徴とする取引支援システム。
【請求項７】
請求項６に記載の取引支援システムにおいて、
前記サーバ装置は、前記行員端末に引き継ぐ制御を実行した場合であっても、前記警告情報を、前記取引端末に出力することを特徴とする取引支援システム。
【請求項８】
請求項６または７のいずれかに記載の取引支援システムにおいて、
前記複数の伝票類は、前記取引に使用される小切手、手形、伝票および通帳のうち少なくとも1種類が含まれることを特徴とする取引支援システム。
【請求項９】
請求項６乃至８のいずれかに記載の取引支援システムにおいて、
前記サーバ装置は、前記取引希望者の過去の取引パターンを記憶しておき、
前記サーバ装置は、前記チェック処理の後に、前記取引パターンと前記取引の内容を比較し、当該比較の結果に応じて、警告情報を出力することを特徴とする取引支援システム。
【請求項１０】
請求項９に記載の取引支援システムにおいて、
前記サーバ装置は、前記比較の結果に応じた警告情報を、前記行員端末に引き継ぐ制御を実行した場合であっても、前記取引端末に出力することを特徴とする取引支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＡＴＭなどの取引装置、取引端末を介して、伝票等を用いた取引を支援する技術に関する。その中でも特に、複数の取引をまとめて行う取引に関する。
【背景技術】
【０００２】
現在、企業などの法人における取引では、伝票を銀行に持参し、ＡＴＭなどで振込みなどの取引処理を行うことがなされている。この場合、法人においては取引数が多数にわたること多いため、複数の取引をまとめて行うことがなされている。このため、複数の取引を効率的に処理するために、その有効性を確認するための技術が、特許文献１に開示されている。特許文献１では、複数の取引が記載された伝票から、無効の取引を判別し、これを処理の対象から除外することで、オペレータ等の負荷を軽減することが開示されている。
【０００３】
また、取引の支援においては、他者の端末(装置)に対する操作を引き継ぐことが考えられる。この操作の支援についての技術が特許文献２に記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平６−５２２０５号公報
【特許文献２】特開２００２−２４７２０４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、取引の場合、伝票だけでなく小切手、手形や通帳など様々な書類等(伝票類)が投入されることがなされている。この点について、特許文献１では考慮されていないため、複数の書類が混在した場合への対応ができない、との課題が生じる。また、特許文献２には、以下の課題が生じる。そもそも取引端末においては、画面を遷移させて入力を促すようになっていることが多い。例えば、最初の画面で取引の種別を選択させ、選択後に次画面に遷移し、金額を入力させ、入力後さらに次画面に遷移して振込み先を指定させるようになっていることが多い。このような取引端末において、特許文献２の技術を適用した場合、どこまで入力が終わっているか、それまで入力されたデータに問題がないかなどの確認が困難であった。つまり、特許文献２の技術においては、００１３段落にあるように単に「処理の連続性を維持して前記処理番号の続きから処理を続行できるようにする」程度の記載しかないため、次画面が表示される。例えば、顧客が取引種別まで入力された場合、いきなり金額入力の画面が表示される。この場合、行員は取引の内容を知ることができないため、入力(処理)引き継ぐ(代行する)ことができない。したがって、顧客に対する取引の支援が非常に困難になる、との課題が生じる。
【０００６】
またさらに、取引の有効性を判断するためには、過去の取引との整合性も考慮する必要があるが、特許文献１ではこの点が考慮されていない。
【０００７】
以上のように、本発明では、複数の伝票類が混在しても、取引の有効性を確認することをその目的とする。特に、本発明は、行員などが処理を行員端末等に引き継いだ場合に好適な技術を提供するものである。
【課題を解決するための手段】
【０００８】
上記の課題を解決するために、本発明では、取引端末に投入された伝票類の種別を認識し、認識結果に応じたそれぞれの有効性のチェックを行うものであり、その結果に応じて警告を出力する。また、本発明には、代行者の端末(行員端末)により操作が行われている場合でも、取引希望者が操作する端末(取引端末)からの警告に対する回答を受け付けるように制御することも含まれる。
【０００９】
さらに、認識結果に応じたそれぞれの有効性チェックの後に、過去の取引パターンと比較して、その結果に応じて警告を出力することも本発明に含まれる。なお、この際も上述のように、取引希望者の端末からの警告に対する回答を受け付けるように制御してもよい。
【発明の効果】
【００１０】
本発明によれば、複数の伝票類が混在しても、取引の有効性を確認することが可能になる。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態のシステム構成図。
【図２】本発明の一実施形態における取引端末４０の処理の流れを示すフローチャート。
【図３】図２のステップ４１２「現金読取処理」の詳細を示すフローチャート。
【図４】図２のステップ４２２「伝票類読取処理」の詳細を示すフローチャート。
【図５】図２のステップ１１０「サーバチェック処理」の詳細を示すフローチャート。
【図６】本発明の一実施形態における業務サーバ１０の取引履歴取得プログラム１１３の処理を示すフローチャート。
【図７】本発明の一実施形態における業務サーバ１０の小切手の有効性プログラム１１４の処理を示すフローチャート。
【図８】本発明の一実施形態における業務サーバ１０の手形の有効性プログラム１１１の処理を示すフローチャート。
【図９】本発明の一実施形態における業務サーバ１０の伝票の重複チェックプログラム１１７の処理を示すフローチャート。
【図１０】図２のステップ４２２の伝票類読取処理において伝票類を読み込ませるこのときの取引端末４０の画面表示例を示す図。
【図１１】法人一括取引の「読取結果確認」画面を示す図。
【図１２】図２の警告ステップ４０１における警告確認画面を示す図。
【図１３】行員呼び出しボタンが押された場合の行員端末３０の一覧表示画面を示す図。
【図１４】行員端末３０で取引の補助を行う操作を行った際の行員に対する指示画面を示す図。
【図１５】取引端末４０に表示される行員の操作待ち画面を示す図。
【図１６】図２のステップ４０１で、取引端末４０に表示される警告画面を示す図。
【図１７】図２のステップ４０３で、取引端末４０に表示される取引内容の確認画面を示す図。
【図１８】図２のステップ４０３で、取引端末４０に表示される取引内訳画面を示す図。
【発明を実施するための形態】
【００１２】
以下、本発明の一実施形態を、銀行の営業店における法人向けの取引業務へ展開した場合を例に、図面を用いて説明する。
【００１３】
図１は、本実施形態のシステム構成図である。複数の営業店毎もしくは銀行毎に設置された業務アプリケーションサーバ１０とアドホック連携サーバ２０が互いに接続されている。そして、アドホック連携サーバ２０が、営業店の行員が利用する行員端末３０やＡＴＭなどの利用者(顧客)が取引に利用する取引端末４０と接続されている。そして、業務アプリケーションサーバ１０の法人取引受付アプリケーション１１や画面コンテンツ１２に従って、かつ、アドホック連携サーバ２０がそれらの処理を仲介および他の処理を規定することで、行員端末３０や取引端末４０に、取引に関する処理を実行させる。アドホック連携サーバ２０は、本実施形態での行員端末３０が取引端末４０の操作を補助する機能を実現している。すなわち、業務サーバ１０の各プログラムや画面コンテンツ１２に従って、かつ、アドホック連携サーバ２０がそれらの処理を仲介および他の処理を規定することで、行員端末３０や取引端末４０に、取引に関する処理を実行させる。ここで、アドホック連携サーバ２０においては、アドホック連携機能２１により、本実施形態での行員端末が取引端末の入力を引き継ぐことを実現している。
【００１４】
ここで、法人向けの取引は次のように行われることを想定している。まず、法人取引の利用者が銀行営業店に持ち込んだ伝票類などの現物を現金・伝票類一括読取装置５０が読み取り、読み取ったデータを取引端末４０にデータを送る。取引端末４０は画像認識処理などの技術を使用して認識データを作成し、認識データを業務サーバ１０に送り、業務サーバ１０上の法人取引受付アプリケーション１１が認識データをチェックして取引データを作成する。作成した取引データを、利用者が取引端末４０にて確認し、法人取引の受付が終了する。
【００１５】
なお、行員端末３０および取引端末４０はそれぞれ１つずつしか図示していないが、営業店内に複数あってもよい。特に、取引端末４０は複数備えていることが多い。図では、現金・伝票類一括読取装置５０は取引端末４０に接続されているが、ネットワークに接続することにより、複数台の取引端末４０が一台の現金・伝票類一括読取装置５０を共有する形態であってもよい。また、各装置は、それぞれいわゆる情報処理装置として実現され、プログラムや他装置からの指令に応じて処理装置(部)が演算することで各処理を実現するものである。
【００１６】
以降、上述したシステムを利用して、利用者が取引端末４０で、法人向けの取引を行う場合の処理について、説明する。
【００１７】
図２は、取引端末４０の処理の流れを示した図である。ここで、上述のように、業務サーバ１０の各プログラムや画面コンテンツ１２に従って、かつ、アドホック連携サーバ２０がそれらの処理を仲介および他の処理を規定することで、この処理を実行する。まず、ステップ４２１の現金読取処理において、利用者（取引希望者）から投入された取引に必要な現金を読み込む。また、ステップ４２２の伝票類読取処理において伝票類を読み込む。このときの取引端末４０の画面表示例を図１０に示す。ここで、取引端末４０から読取結果が送信された業務サーバ１０では、伝票類のチェックを行い、その結果、取引端末４０ではステップ４０１において図１２に示すような警告を表示し、ステップ４０２において利用者が警告に基づいて伝票を訂正するか否かの判断を行う。つまり、訂正すると利用者から入力された場合にはステップ４３に進んで訂正伝票を作成した後にステップ４０３に進み、訂正しないと入力された場合にはそのままステップ４０３に進む。なお、図１０の後に、法人一括取引の「読取結果確認」画面として、図１１に示す画面を取引端末４０に表示する。ステップ４０３において図１７に示すような取引確認画面を表示して取引内容の確認画面を表示し、その確認結果の入力を受け付け、訂正の有無と訂正がある場合は訂正データをサーバ１１０に送り、ステップ４０５において訂正内容の印字処理を行い、ステップ５２において現金・伝票一括読取装置５０が印字を行い、取引の受付が終了する。その後、認証を行うなどして取引へと進む。このとき、ステップ５２では、訂正内容が分かる明細をレシート等に印字して利用者に渡し、読取った伝票類と訂正データを銀行が保管する方法や、読み取った伝票に訂正したことが分かる印を印字して利用者に返却する方法などが考えられる。
【００１８】
図３は、取引端末４０の現金読取処理４２１の処理の流れを示した図である。現金読取処理４２１において、まずステップ４２１１にて現金の取り使いがあるか否かを確認するための画面を表示する。現金を取り扱うと入力された場合にはステップ４２１２に進み、現金・伝票類一括読取装置５０に現金読取を依頼し、ステップ５１にて現金・伝票類一括読取装置５０は現金を読取り、ステップ４２１３にて読取データを受け取り、ステップ４２１４にて現金金額の確認を表示して利用者の確認ボタン押下を待ち、確認ボタン押下が得られたら終了する。ステップ４２１１にて現金取扱がないと入力された場合には終了する。
【００１９】
図４は、取引端末４０の伝票類読取処理４２２の処理の流れを示した図である。伝票類読取処理４２２は開始するとステップ４２２１にて現金・伝票類一括読取装置５０に現物読取を依頼し、ステップ５１にて現金・伝票類一括読取装置５０は伝票類を読取り、ステップ４２２１にて現金・伝票類一括読取装置５０から読取データを受け取り、処理待ちキューに入れる。次のステップ４２２３では処理待ちキューから読取データを取り出し、イメージ処理を行い、伝票類認識技術を用いて伝票類の種別を識別し、種別毎に必要な項目が埋められたデータを作成する。このとき、各伝票類の処理をまとめて行うのではなく、一枚（もしくは一種類）分のデータ毎に処理待ちキューへの入力と取り出しが並行して行われる。次のステップ４２２４では伝票類一枚分の認識データを業務サーバ１０に送り、ステップ１１０にてチェック処理を行う。ステップ４２２５にて読み取りが終了したか否かを判断し、読み取りが終了している場合にはステップ４２２２に戻って次の一枚分のデータを読み込む。読み取りが終了している場合にはステップ４２２６に進み、認識データを全て送信したことをサーバ５０に送り、ステップ４２２７にて読取結果を表示して終了する。
【００２０】
図５は、サーバチェック処理１１０の処理の流れを示した図である。ステップ１１０１にて取引端末４０のステップ４２２４から伝票類一枚分の認識データを受信すると、ステップ１１０２において種別毎に振分処理を行う。種別が小切手の場合はステップ１１４に進み、ステップ１１４において図７に示す小切手の有効性チェックを行い、ステップ１１０４にて警告案件データを作成し、ステップ１１０１に戻る。種別が手形の場合は、ステップ１１１に進み、ステップ１１１において図８に示す手形の有効性チェックを行い、ステップ１１０４にて警告案件データを作成し、ステップ１１０１に戻る。種別が伝票の場合はステップ１１７に進み、ステップ１１７において図９に示す伝票の重複チェックを行い、ステップ１１０４にて警告案件データを作成し、ステップ１１０１に戻る。種別が通帳の場合はステップ１１３に進み、ステップ１１３において図６に示す顧客の口座番号から取引履歴を取得する処理を行い、ステップ１１０４にて警告案件データを作成し、ステップ１１０１に戻る。取引端末４０のステップ４２２６からデータ終了が送られてきた場合にはステップ１１０３に進み、ステップ１１０４にて作成した警告案件データを取引端末４０に送信し、取引端末４０では図２に示すステップ４０１からステップ４０４の処理が行われ、取引端末４０から訂正データが送り返されてくる。次にステップ１１０５において入出金額の相殺を行い、取引データを作成する。更に，ステップ１１０６において、ステップ１１３にて入手した取引履歴から過去の取引パターンと比較し、入出金の金額が大きく異なっている場合や相手先の口座が新規の場合など、過去の取引と異なるパターンが検出された場合にはステップ１１０７においてステップ１１０３と同様に警告案件を取引端末４０に送り、訂正データを受け取る。最後に、ステップ１１０８において訂正があれば訂正を反映した取引データを作成し、サーバチェック処理１１０を終了する。このようにして、大量の伝票を扱うために起こりやすい伝票の作成間違い候補を検出し、利用者に提示することができるようになる。例えば、図１６に示すように、同一の口座による入出金が重複している伝票がある場合や、入出金が逆の取引が混在している伝票がある場合に警告を表示し、その場で伝票を破棄することや、複数の伝票を一つにまとめることができ、また、手形や小切手の換金と相手先口座への振込等の取引を相殺し、口座毎への入出金をまとめることができ、まとめた結果を図１７に示すような形で画面に表示し、利用者はこの画面にて取引内容を確認することができる。「内訳」をクリックすると図１８に示すように、口座毎の詳細な取引内訳を確認することが可能である。また、取引端末４０ではデータを読み込んだ順にイメージ処理・認識処理を行い、認識後のデータを業務サーバ１０に送信する処理を繰り返し、業務サーバでは受信したデータの取引パターンのチェック処理を順次行う方式により、従来は行員が手動で行っていた取引パターンのチェック処理をサーバ処理によって行うことが可能となり、取引データの受付処理をすばやく行うことができるという効果が生まれる。
【００２１】
図６は、種別が通帳の場合に、顧客の口座番号から取引履歴を取得するプログラム１１３の処理の流れを示した図である。まず、ステップ１１３１にて認識デーから口座番号を取り出し、ステップ１１３２において１冊目の通帳か否かの判断を行う。一冊目の通帳であった場合はステップ１１３４に進み、口座情報サーバ７０から口座番号をキーに顧客番号を取得し、次にステップ１１３５に進んで顧客情報サーバ７０から口座番号をキーに口座一覧を取得し、ステップ１１３６に進んで顧客情報サーバ７０から顧客番号をキーに過去の取引情報を取得し、「顧客番号」「口座番号」「過去の取引情報」を保持しておき、処理を終了する。ステップ１１３２において1冊目の通帳ではないと判断した場合にはステップ１１３３に進み、口座番号が取得済みの口座番号と一致しているか否かを判断する。一致している場合には、すでに過去の取引情報が入手できていると判断して処理を終了する。ステップ１１３３にて口座番号が一致しない場合は、別の顧客として管理されている可能性があるため、ステップ１１３４からステップ１１３７を再度行い、別の顧客として管理されている過去の取引情報も保持し、処理を終了する。
【００２２】
図７は、小切手の有効性をチェックするプログラム１１４の処理の流れを示した図である。処理を開始すると、ステップ１１４１にて認識データから「支店名」「金額」「振出日」「振出人」「署名」「印影」の各項目（データ）を抽出し、以下のステップで各項目の有効性をチェックしていく。まず、ステップ１１４２にて取扱可能な「支店名」か否かのチェックを行い、取扱いができない場合はステップ１１４３にて「支店名」ＮＧと判断する。ステップ１１４２にて取扱可能と判断した場合にはステップ１１４４に進み、支払い可能な「振出日」か否かの判断を行い、支払い不可能であればステップ１１４５に進み、「振出日」ＮＧと判断する。ステップ１１４４にて支払い可能と判断した場合にはステップ１１４６に進み、印鑑サーバ９０から振出人をキーに「署名」「印影」を取得し、ステップ１１４７にて照合を行う。照合結果によりステップ１１４８にて振分けを行い、照合されなかった場合はステップ１１４９にて「照合」ＮＧと判断し、照合された場合にはステップ１１５０に進み、「振出人」の当座残高をホスト６０に照会する。ステップ１１５１において残高と「金額」の比較を行い、「金額」≦残高の場合には出金が可能と判断してステップ１１５３にて小切手の有効性は問題なしと判断し、残高不足の場合にはステップ１１５２にて「残高」ＮＧと判断する。ステップ１１４３、１１４５、１１４９、１１５２の判断により、ステップ１１５４では小切手が有効でないと判断し、処理を終了する。
【００２３】
図８は、手形の有効性をチェックするプログラム１１１の処理の流れを示した図である。処理を開始すると、ステップ１１１１にて認識データから「手形番号」「手形受取人」「支払い場所」「支払期日」「振出日」「振出人」「印影」「金額」を取り出し、ステップ１１１２にて「支払い場所」「支払期日」「振出日」の記載事項が有効か否かを判断し、有効でない記載事項があった場合にはステップ１１１３にて「記載事項」ＮＧと判断し、ステップ１１２５に進む。なお、有効でない記載事項は、予め格納されている各情報と比較して判断してもよいし、取引端末４０の設置位置や現在日時などと比較して判断してもよい。記載事項が有効であった場合にはステップ１１１４に進み、手形信用情報サーバ８０に「手形番号」を照会し、ステップ１１１５事故手形かどうかの判断を行う。事故手形であった場合にはステップ１１１６に進み、「事故手形」であると判断してステップ１１２５に進み、事故手形でない場合にはステップ１１１７に進み、「振出人」をキーに印鑑サーバ９０から印影を取得し、ステップ１１１８にて照合を行う。ステップ１１１９にて照合されたか否かの判断を行い、照合されない場合はステップ１１２０にて「照合」ＮＧと判断し、ステップ１１２５に進む。照合された場合はステップ１１２１に進み、ホスト６０に「振出人」の当座残高を照会し、「金額」≦残高の場合はステップ１１２４にて手形は有効であると判断する。残高不足の場合はステップ１１２３にて「残高」ＮＧと判断し、ステップ１１２５に進む。ステップ１１２５では手形は有効でないと判断して処理を終了する。
【００２４】
図９は、伝票の重複チェックプログラム１１７の処理の流れを示した図である。処理を開始すると、まず、ステップ１１７１にて認識データから「伝票種別」「相手口座」「取引口座」「金額」を取り出し、ステップ１１７２にて複数枚の伝票の読み取り結果を「取引口座」「相手口座」「伝票種別」「金額」でソーティングしたリストを作成・更新する。次に、ステップ１１７３にてリスト内に取引口座」「相手口座」「伝票種別」が同じ内容のものがあるか否かの判断を行い、同じ内容のものがある場合にはステップ１１７４にて二重伝票の可能性があると判断し、ステップ１１７５に進む。同じ内容のものがない場合にはステップ１１７５に進む。更に、ステップ１１７５にて、リスト内に「伝票種別」が同じで「取引口座」「相手口座」が逆の内容のものがあるか否かの判断を行い、同じものがある場合にはステップ１１７６にて重複伝票の可能性があると判断し、処理を終了する。「取引口座」「相手口座」「伝票種別」「金額」でソーティングしたリストを作成するのは、対象とするデータの前後のデータと比較することによりステップ１１７３およびステップ１１７５の判断を行うことが可能なためである。
【００２５】
このようにして、読み取ったデータの取引パターンをシステムがチェックし、取引データを作成することにより、大量の伝票類を処理する法人の取引の効率を向上することができるようになる。
【００２６】
ここまでは、処理時間の短縮を目的として、取引端末とサーバとで伝票類を並行処理する方法について述べたが、ホストへの接続を減らすことを目的として、次に示す処理手順に変更することも考えられる。
【００２７】
大量の伝票類を処理するため、例えば相手先から小切手で支払われた金額と同額の振込を同じ相手先に対して行うようなケースが考えられる。このような場合は資金の移動が相殺されるため、小切手の相手先口座の残高を確認する必要はなくなり、図７のステップ１１５０以降の処理を行う必要がなくなる。そこで、相手先口座の残高確認処理を図５ステップ１１０５または１１０６の後ろに移動させ、ホストへの接続を最後の確認に行うように変更してもよい。また、図４に示す伝票類読取処理においては、読み込んだ伝票類のイメージ処理と認識データ作成を一枚毎に行い、サーバに送信しているが、まず、伝票類の種別の認識処理のみを先に行い、振込や振替などの伝票の認識データ作成を優先的に行ってサーバに送信し、小切手と手形の認識データを後からサーバに送るようにし、サーバでは伝票の相殺処理のみを先に行っておき、小切手と手形の残高チェックを行う前に、伝票と相殺されるデータがあるかどうかを確認し、相殺後のデータを用いて相手先口座からの出金額を確認し、出金が必要な場合にのみ、残高確認処理を行うように変更してもよい。
【００２８】
以上、利用者が単独で取引端末を操作する使い方を説明したが、実際の取引においては、行員の補助が必要となる場面も想定される。取引端末４０と行員端末３０とが連携して取引操作を行う技術については、取引端末４０の操作補助を行員端末３０から行うものを用いればよく、上述した業務サーバ１０やアドホック連携サーバ２０を介してこの機能を達成してもよい。すなわち、業務サーバ１０の各プログラムや画面コンテンツ１２に従って、かつ、アドホック連携サーバ２０がそれらの処理を仲介および他の処理を規定することで、行員端末３０や取引端末４０に、取引に関する処理を実行させる。例えば、図７および図８においては小切手・手形の署名・印鑑の印影を行っているが、システムにより照合されない場合は行員の人手による照合が行われる。
【００２９】
図１２に示すように、手形の印影がシステムにより照合されなかった場合、取引端末４０に警告確認画面が表示され、「行員呼出」を行うよう、指示が表示される。そこで、利用者は「行員呼出」ボタンを押下して行員を呼び出すことを想定しているが、利用者が行員を呼び出すのではなく、システムが自動的に行員を呼び出すアラームを発生することも可能である。行員呼出ボタンが押下されると、図１３に示すように行員端末３０に行員呼出アラームと、アラームの発生原因となる取引端末の状況が表示される。そこで、行員はそのアラームを選択し、取引の補助を行う操作を行うと、図１４に示すように行員端末３０には行員に対する指示が表示される。このとき、行員を呼び出した取引端末４０の画面は、アドホック連携サーバ２０の機能により、図１５に示すように、行員の操作待ちの画面に自動的に遷移する。行員は行員端末３０に印影を表示して照合を行い、照合結果を入力する。行員端末３０による照合処理が終了すると、取引端末４０の画面は照合結果が反映された画面に遷移し、取引操作を再開することが可能となる。
【符号の説明】
【００３０】
１０・・・業務サーバ、２０・・・アドホック連携サーバ、３０・・・行員端末、４０・・・取引端末、５０・・・現金・伝票類一括読取装置、６０・・・ホスト、７０・・・顧客情報サーバ、８０・・・手形信用情報サーバ、９０・・・印鑑サーバ
【図１】
2011034524.tif 000003
【図２】
2011034524.tif 000004
【図３】
2011034524.tif 000005
【図４】
2011034524.tif 000006
【図５】
2011034524.tif 000007
【図６】
2011034524.tif 000008
【図７】
2011034524.tif 000009
【図８】
2011034524.tif 000010
【図９】
2011034524.tif 000011
【図１０】
2011034524.tif 000012
【図１１】
2011034524.tif 000013
【図１２】
2011034524.tif 000014
【図１３】
2011034524.tif 000015
【図１４】
2011034524.tif 000016
【図１５】
2011034524.tif 000017
【図１６】
2011034524.tif 000018
【図１７】
2011034524.tif 000019
【図１８】
2011034524.tif 000020