(57)【要約】      （修正有） 【課題】オペレータが正しいデータを誤修正することを防止する。【解決手段】帳票に記入された項目情報を入力するための第１の入力部と、前記帳票に記入された項目情報を入力するための第２の入力部とを備えた帳票情報入力端末において、前記第１の入力部と第２の入力部によって入力された項目情報とを比較する比較部を備え、一致した場合に項目情報を確定したものとして扱う。【選択図】 図１
2005352652.tif 000002
【特許請求の範囲】
【請求項１】
帳票に記入された項目情報を入力するための第１の入力部と、
前記帳票に記入された項目情報を入力するための第２の入力部とを備えた帳票情報入力端末において、
前記第１の入力部と第２の入力部によって入力された項目情報とを比較する比較部を備え、
一致した場合に項目情報を確定したものとして扱う帳票情報入力端末。
【請求項２】
前記第１の入力部とは前記項目情報をオペレータの入力操作によって取得するものであり、
前記第２の入力部とは前記項目情報を文字認識によって取得するものであり、
帳票の画像を取得する画像取得部を備え、
前記第１の入力部は入力された項目情報を表示するための表示画面を備え、
一致しなかった項目情報と一致した項目情報とを前記表示画面に識別可能に表示するとともに、項目情報が一致した入力フィールドへの再入力を受け付けない請求項１に記載の帳票情報入力端末。
【請求項３】
前記第１の入力部とは口座情報を文字認識によって取得するものであり、
前記第２の入力部とは口座情報を通帳が有する記録部に記録された情報を読み取ることによって取得するものであり、
前記比較部は前記入力部によって入力された第１の口座情報と前記情報取得部によって取得された第２の口座情報とを比較し、
口座情報が一致した場合に口座情報の変更を受け付けない請求項１に記載の帳票情報入力端末。
【請求項４】
当該帳票入力における１回目の比較に用いた前記第１の入力部による項目情報と第２の入力部による項目情報とを保存する記憶部を有し、
前記比較部は当該帳票入力における２回目以降の比較において、新たに入力された項目情報が前記保存した第１の入力部による項目情報と第２の入力部による項目情報のいずれかと一致すれば一致したものとして扱う、請求項１または２に記載の帳票情報入力端末。
【請求項５】
当該帳票入力における１回目の比較に用いた前記第１の入力部による項目情報と第２の入力部による項目情報とを保存する記憶部を有し、
前記比較部は当該帳票入力における２回目以降の比較において、新たに入力された項目情報と前記保存した第１の入力部による項目情報と第２の入力部による項目情報のいずれとも一致しない場合当該取引を無効とする、請求項１または２のいずれかに記載の帳票情報入力端末。
【請求項６】
比較を行なう項目をあらかじめ指定するための比較対象情報を備え、
前記比較部は、前記比較対照情報を参照して比較対照である項目情報のみの比較を行い、
比較対照外である項目情報と比較対照の項目情報とを前記表示画面に区別可能に表示する請求項１、２、４、５のいずれかに記載の帳票情報入力端末。
【請求項７】
前記入力部は、当該帳票入力における２回目以降の入力において、前記表示画面に、２回目以降の入力である旨の表示を行なう請求項１、２、４、５，６のいずれかに記載の帳票情報入力端末。
【請求項８】
前記帳票は金融機関で使用する取引伝票であり、前記帳票情報入力端末とは金融機関の営業店窓口に設置される営業店窓口端末である、請求項１〜７のいずれかに記載の帳票情報入力端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、金融営業店窓口端末等における、オペレータ入力内容、伝票等のＯＣＲ文字認識結果、及び通帳やカード媒体等からの情報のべリファイ処理方法等に関するものである。
【背景技術】
【０００２】
金融営業店窓口等において、顧客が口座の新規開設や、預金の引出し、有価証券の預け入れ等の取引を行う際、顧客は取引に応じた伝票に必要事項を記入し、記入した伝票と通帳及び取引にかかわる有価証券等を窓口のオペレータに提出する。オペレータはネットワーク接続された窓口端末を操作し、顧客記入した伝票等の記載内容を入力する。または、記入した伝票等の内容を窓口端末に接続された画像読取装置から入力し窓口端末に搭載された文字認識機能により顧客が伝票に記入した内容を自動的に入力する。窓口端末はオペレータの入力内容に従い取引情報を電文としてホストシステムへ送信し、ホストシステムは取引結果を窓口端末へ返信する。窓口端末は受信内容により、接続された印字装置に対し通帳や伝票等の印字を指示する。印字装置は必要な印字処理を行い、取引内容を記録する。オペレータは印字済みの通帳および取引に関わる有価証券等を顧客に渡す。
上記取引において、オペレータの誤操作や文字認識の誤り等により発生した入力誤りは、顧客やオペレータの目視によるベリファイや営業店窓口閉店後の精査等により発見されるが、目視によるベリファイは見落とし等の発生があり、営業店閉店後の精査におけるベリファイにて誤りが発見された場合は訂正取引等が発生する。訂正取引は金融機関、顧客双方に手間がかかり、金融機関の信頼等に影響する。そのため、ベリファイを取引時に行なうことによって誤りの発見を取引時点で発見できるようにすることが窓口端末における重要な機能要件になる。そのための方法として、伝票に記載された項目を手入力するとともに、その項目をＯＣＲによって文字認識する。それによって得られた手入力された項目データと文字認識結果のベリファイを行なう。このとき、前記ベリファイによって誤りを発見した場合に、誤りの箇所をオペレータが特定しやすいように表示する。誤りである旨が表示された場合、オペレータは誤りが表示された箇所の修正入力を行なう。修正入力された項目データは再度文字認識結果と比較される。（例えば、特許文献１参照）。
【特許文献１】特開平５−２７４４６７
【発明の開示】
【発明が解決しようとする課題】
【０００３】
このとき、文字認識結果に誤認識または認識不可であった文字が含まれていた場合、オペレータが正しい文字を入力しても常に誤りと表示されつづける。このためオペレータは、正しい文字を入力したことを目視で確認した後、入力データを確定する操作を行なわなければならない。従来同様に目視に頼るため、誤りが発生する可能性があった。また誤りである旨が表示されて続けているにもかかわらず、正しく入力されていることを確認しなければならず、オペレータの負担になっていた。
また、既に正常となった項目も修正入力が可能なので、誤って異なる項目を修正してしまい、二重に修正を行なわなければならなくなってしまうことがあった。
このため、入力対象の項目に対して２つの方法で入力したデータを比較し、効率よく正否を判断して処理を行なう営業店端末が必要であった。なお、比較対象となるデータは誤りを含む可能性が少ないものが望ましいことは言うまでもない。
【課題を解決するための手段】
【０００４】
本発明の帳票情報入力端末は以下の構成を備える。
＜構成１＞
帳票に記入された項目情報を入力するための第１の入力部と、前記帳票に記入された項目情報を入力するための第２の入力部とを備えた帳票情報入力端末において、前記第１の入力部と第２の入力部によって入力された項目情報とを比較する比較部を備え、一致した場合に項目情報を確定したものとして扱う。
＜構成２＞
前記構成１において、前記第１の入力部とは前記項目情報をオペレータの入力操作によって取得するものであり、
前記第２の入力部とは前記項目情報を文字認識によって取得するものであり、帳票の画像を取得する画像取得部を備え、前記第１の入力部は入力された項目情報を表示するための表示画面を備え、一致しなかった項目情報と一致した項目情報とを前記表示画面に識別可能に表示するとともに、項目情報が一致した入力フィールドへの再入力を受け付けない。
＜構成３＞
前記構成１において、前記第１の入力部とは口座情報を文字認識によって取得するものであり、前記第２の入力部とは口座情報を通帳が有する記録部に記録された情報を読み取ることによって取得するものであり、前記比較部は前記入力部によって入力された第１の口座情報と前記情報取得部によって取得された第2の口座情報とを比較し、口座情報が一致した場合に口座情報の変更を受け付けない。
＜構成４＞  
前記構成１または２において、当該帳票入力における１回目の比較に用いた前記第１の入力部による項目情報と第２の入力部による項目情報とを保存する記憶部を有し、前記比較部は当該帳票入力における２回目以降の比較において、新たに入力された項目情報が前記保存した第１の入力部による項目情報と第２の入力部による項目情報のいずれかと一致すれば一致したものとして扱う。
＜構成５＞
前記構成１、２、４のいずれかにおいて、当該帳票入力における１回目の比較に用いた前記第１の入力部による項目情報と第２の入力部による項目情報とを保存する記憶部を有し、
前記比較部は当該帳票入力における２回目以降の比較において、新たに入力された項目情報と前記保存した第１の入力部による項目情報と第２の入力部による項目情報のいずれとも一致しない場合当該取引を無効とする。
＜構成６＞
構成１、２、４、５のいずれかにおいて、比較を行なう項目をあらかじめ指定するための比較対象情報を備え、前記比較部は、前記比較対照情報を参照して比較対照である項目情報のみの比較を行い、比較対照外である項目情報と比較対照の項目情報とを前記表示画面に区別可能に表示する。
＜構成７＞
構成１、２、４、５，６のいずれかにおいて、前記入力部は、当該帳票入力における２回目以降の入力において、前記表示画面に、２回目以降の入力である旨の表示を行なう。
＜構成８＞
請求項１〜７のいずれかにおいて、前記帳票は金融機関で使用する取引伝票であり、前記帳票情報入力端末とは金融機関の営業店窓口に設置される営業店窓口端末である。
【発明の効果】
【０００５】
入力対象の項目に対して２つの方法で入力したデータを比較し、効率よく正否を判断して処理を行なうことが出来る。
【発明を実施するための最良の形態】
【０００６】
以下、順に説明する。
【実施例１】
【０００７】
＜実施例１の構成＞
図１はこの発明の第１の実施例を示す装置の構成図である。金融営業店窓口端末１（以下、窓口端末１）は、金融機関の営業店の窓口において行なわれる取引を処理するための機能が備わったコンピューターである。本実施例においては、制御部１１と文字認識部１５と比較部１６と記憶部１７とを備え、またスキャナ１８と、入力部１２とが接続されている。なお、その他営業店窓口にて行なわれる処理を行う際に一般的に使われる構成が備わっているが図１においては省略している。更に、窓口端末１は、ネットワーク３を介してホスト２に接続されている。窓口端末１は後述する方法で金融機関の取引に用いる伝票４の情報を入力し、ホスト２に送信することによって、取引を成立させる。
【０００８】
伝票４は、金融取引に必要な情報を記入するための帳票である。金融取引に必要な情報とは、例えば、金融機関コード、店番、科目番号、口座番号、取引種別、金額、顧客氏名カナ等である。ここで図２に基づいて伝票４の例を説明する。図２に示す伝票４は、金融機関の営業店窓口において顧客が出金取引を行なうためのものである。伝票４は各取引毎に用意され、それぞれの取引に必要な項目の記入エリア４０３が設けられている。この例では出金取引に必要な項目として、口座を開設している店番号、口座番号、口座種別、出金金額、口座名義人を記入させることとしているが、この他の項目が存在していても構わない。記入エリア４０３は、本図においては点線で表現されている。文字認識を行なう場合、文字のみ画像として取得されればよく、枠の画像は不要であるので、一般に記入エリア４０３はスキャナで取得されない色にて印刷される。また、伝票４にはその伝票４の種別をしめすタイトル４０１が設けられる。また、それぞれの伝票４には識別のための独立したシートＩＤ４０２が付与されている。シートＩＤ４０２は伝票４の決まった場所に印字されている。伝票４をＯＣＲによって処理する場合は、シートＩＤ４０２の読取によって帳票の特定を行なって、それぞれの帳票に対応した文字認識処理を行なう。このため、シートＩＤ４０２の字には通常ＯＣＲ文字が用いられる。
顧客は、希望する取引に対応する伝票４の記入エリア４０３に前記の情報を記入し、営業店窓口のオペレータに提示する。オペレータは窓口端末１を用いて前記の情報の入力を行なう。伝票４は多くの場合シートＩＤ毎に固定の形式をもつ定型の帳票であり、本発明においても定型の帳票であることを前提として説明する。
【０００９】
窓口端末１が備える構成について図１に基づきさらに説明する。
【００１０】
制御部１１は窓口端末１の各機能の動作やデータの受け渡し等を制御するためのものであり、ＣＰＵ、オペレーティングシステム、ミドルウェア、アプリケーション等が適宜組み合わされてなる。
【００１１】
入力部１２は、ディスプレイ１３とキーボード１４からなり、更にはディスプレイ１３に表示される入力画面５も含まれる。ディスプレイ１３とはＣＲＴ、ＬＣＤ、プラズマディスプレイ等であるが、その他の同様な表示機能を持つものであっても良い。
【００１２】
キーボード１４とは一般的なＪＩＳキーボード１４等であっても良いし、画面上に表示されたソフトキーボードであってもよい。その他文字を入力するための機能を持つものならばいかなるものを使用しても良い。
【００１３】
入力画面５は、前記伝票４に記載された項目データをオペレータが入力するためのものである。入力画面５の構成については、後述する。前記入力部１２によって入力された項目データを入力項目データと呼ぶ。
【００１４】
スキャナ１８は、窓口端末１に接続され、伝票４等の画像を取得するためのものであり、フラットベッドスキャナ、スタンド型スキャナ、デジタルカメラ、ビデオカメラ等であるが、その他の同様な画像取得機能を持つものであっても良い。
【００１５】
文字認識部１５は、伝票４等の画像を認識するためのものであり、ＯＣＲ機能を持つハードウェア、もしくはプログラムである。伝票４の画像を受け取って、伝票４のシートＩＤ４０２により伝票４の種類を識別するとともに、伝票４上の記入エリア４０３毎に記載された文字を認識して、データ化する。本発明においては、文字認識によって得た項目のデータを認識項目データと呼ぶ。認識すべき項目は、通常シートＩＤ毎にあらかじめ設定され、フォーマット情報として記憶される。文字認識の際、文字認識部１５は前記フォーマット情報を参照して、シートＩＤ４０２の認識および記入エリア４０３の認識を行なう。その際文字認識部１５は、記入エリア４０３の認識結果データを出力するとともに、記入エリア４０３の部分イメージを切出す。前記記入エリアを認識しして出力された認識結果データを認識項目データと呼ぶ。認識項目データと前記部分イメージは入力画面５に表示するために記憶部１７に記憶される。
【００１６】
記憶部１７は、窓口端末１の動作に必要な情報を記憶しておくものであるが、本実施例においては特に前記入力項目データ、前記認識項目データおよび部分イメージを１つの取引の間記憶しておく機能を有する。記憶部１７にはコンピュータのＲＡＭ等の書換え可能な内部記憶装置や、ハードディスク、ＭＯ、ＤＶＤ−ＲＡＭ等の外部記憶装置が使用可能である。
【００１７】
比較部１６は、入力項目データと認識項目データとの比較を行なうものであり、本実施例においてはプログラムによって実現することを想定している。また本発明において比較処理をベリファイと呼ぶ。入力項目データと認識項目データとのベリファイは、それぞれ対応する項目同士で行なう。即ち、口座番号に対する入力項目データであれば、口座番号に対する認識項目データによってベリファイを行なう。各項目ごとの入力項目データと認識項目データの対応付けは、直接プログラミングするか対応テーブルを用意する等一般的な手法で実現されるのでここでは詳述しない。
【００１８】
次に図３に基づいて入力画面５について説明する。
【００１９】
入力画面５には画面タイトル５１が表示される。画面タイトル５１は、取引の種別と、この入力がベリファイ入力であるか、ベリファイ修正入力であるかが表示されるようになっている。ベリファイ入力と、ベリファイ修正入力については後述する。この例においては、この画面が出金取引であり、ベリファイ入力中であることが表示されている。
【００２０】
また入力画面５には、入力用イメージ５２、入力フィールド５３が配置される。図においては、入力用イメージ５２は口座番号の入力用イメージ５２ａと金額用の入力用イメージ５２ｂが、入力フィールド５３は口座番号の入力フィールド５３ａと金額用の入力フィールド５３ｂを記載しているが、もちろんこれら以外の項目が含まれていても構わない。入力用イメージ５２は、伝票４の記入エリア４０３の部分イメージを表示する。即ち、入力フィールド５３には入力すべき項目データとして顧客の記入した文字が表示されている。オペレータは入力用イメージ５２を見ながら、入力フィールド５３に項目データを入力する。入力されたデータは入力項目データとして記憶部１７に記憶される。
【００２１】
ここでベリファイ入力、ベリファイ修正入力について説明する。ベリファイ入力とは、前記ベリファイによって入力誤りを検出する入力処理であり、ベリファイ修正入力とは前記ベリファイ入力時に入力誤りが検出された場合に行なう、再入力処理である。それぞれについては、以下の動作の説明において詳細を説明する。なお、現在の画面がベリファイ入力であるかベリファイ修正入力であるかどうかは、画面下部に設けられたモード表示部５４にも表示されるようになっている。ベリファイ入力で誤りが検出されなかった場合は、ベリファイ修正入力は行なわれない。
【００２２】
＜実施例１の動作＞
ここで、図４に基づいて顧客が窓口に提示した伝票４のデータを窓口端末１から入力し、ベリファイを経てデータを確定するまでの処理の流れについて、説明を行なう。
【００２３】
Ｓ００１：顧客が記入した伝票４を受け取ると、オペレータは窓口端末１を操作して、伝票４に対応する取引種別を選択する。ここでは図２に示す伝票４を受け取ったものとする。オペレータは出金を選択する。なお、この例では出金としたが、入金や振込等、伝票４を用いて窓口において行なう取引であればいかなる取引であっても良い。
【００２４】
Ｓ００２：次にオペレータはスキャナ１８に伝票４をセットした後、窓口端末１を操作して、伝票４の画像の取得を指示する。これにより、スキャナ１８が動作して伝票４の画像を取得する。
【００２５】
Ｓ００３：取得した伝票４の画像は文字認識部１５に渡される。文字認識部１５はシートＩＤ４０２の認識を行なって伝票４の種類を特定し、対応するフォーマット情報を呼び出して項目ごとの文字認識を行い、認識項目データを作成するとともに、記入エリア４０３の部分イメージを切出す。ここでは、口座番号を「１２３４５６７」と認識すべきところ、最後の文字が認識不可となり「１２３４５６？」と認識されてしまったものとする。金額については、正常に認識されたものとする。認識項目データと部分イメージは記憶部１７に記憶される。なお、認識項目データは、本実施例においてはベリファイの用途のみに用いられ、入力画面等に表示されることはない。
【００２６】
Ｓ００４：ディスプレイ１３に取引種別に応じた入力画面５が表示される。ここでは図６（ａ）のような出金取引のベリファイ入力画面が表示される。なお、図では便宜上既に項目データが入力された状態を示しているが、初期状態では入力フィールド５３は何も入力されていない。
【００２７】
Ｓ００５：オペレータは入力用イメージ５２を見ながらデータ入力を行なう。ここでは、金額、口座番号とも正しく入力されている。
【００２８】
Ｓ００６：オペレータは図示しない確定キーを押下する。これによって、窓口端末１は入力操作が終了しベリファイを実行すべきことを知ることが出来る。
【００２９】
Ｓ００７：比較部１６は前記入力項目データおよび認識項目データのベリファイを開始する。図６（ａ）にこの例における認識項目データと入力項目データを示す。この例において、文字認識は前述の通り口座番号が「１２３４５６？」と認識されている。このため、ベリファイの結果は、入力項目データと認識項目データが口座番号については不一致であること、金額については一致となる。比較部１６は、口座番号がベリファイＮＧになった旨と金額がベリファイＯＫになった旨とを記憶部１７に記憶する。
【００３０】
Ｓ００８：入力画面５は、記憶部１７を参照して画面上に表示する項目についてベリファイＯＫであったか、ベリファイＮＧであったかを調べる。ベリファイＮＧの項目があった場合、図６（ｂ）のようなベリファイ修正入力の画面に切り替わる。ベリファイ修正入力画面はベリファイ入力画面と同一の入力項目を持つ。ベリファイＯＫであった項目の入力フィールド５３については確定扱いとし、誤って修正されないように入力を受け付けないようロックする。このとき、ベリファイＯＫのフィールドは入力ロックされていることを示すために、グレー表示等目立たない表示にすることもできる。ベリファイＮＧであった項目の入力フィールド５３については修正入力をさせるためロックは行なわず、図６（ｂ）のように入力フィールド５３の背景色を変える等して強調表示を行なう。なお、図では便宜上すでに修正入力がされた状態になっているが、ベリファイ修正入力の初期状態では、ベリファイＮＧの入力フィールド５３はクリアされる。
すべての項目がベリファイＯＫであれば、修正入力の必要が無いので、以下の処理は行なわず、入力データを確定させる。
【００３１】
Ｓ００９：オペレータは、ベリファイ入力時と同様に、入力用イメージ５２を見ながらデータの修正入力を行なう。ここでは、金額はすでに確定状態であるので、口座番号の修正入力のみを行なう。ここでは、今回も正しく「１２３４５６７」と修正入力されたものとする。修正入力が済むとオペレータは同様に確定キーを押下する。
【００３２】
Ｓ０１０：比較部１６は、２回目のベリファイを開始する。具体的な比較方法については、後述する。比較部１６は、前回記憶部１７に記憶した各項目ごとのベリファイ結果を更新する。
【００３３】
Ｓ０１１：制御部１１は、Ｓ０１０にて更新されたベリファイ結果を参照し、ベリファイＮＧの項目が残っていれば、当該取引をキャンセルする。すべてベリファイＯＫであれば、入力データを確定させる。入力データが確定された場合、取引が続行され、ホスト２に取引データが送付される。
【００３４】
ここで、Ｓ０１０に述べた２回目のベリファイの内容を図５に基づいて説明する。
【００３５】
Ｓ１０１：比較部１６は２回目のベリファイを開始する。２回目のベリファイでは、１回目のベリファイでＮＧとなった項目について、順次、今回入力された修正入力項目データと、１回目の入力であるところの入力項目データと認識項目データとのベリファイを行なう。図６（ｂ）にこの例におけるそれぞれのデータを示す。
【００３６】
Ｓ１０２：修正入力項目データと、記憶部１７に記憶されている１回目の入力項目データを比較する。
【００３７】
Ｓ１０３：Ｓ１０２で不一致の場合は、修正入力項目データと、記憶部１７に記憶されている認識項目データの比較を行なう。
【００３８】
Ｓ１０４：Ｓ１０２またはＳ１０３で一致した場合、本ステップが実行される。即ち、修正入力された項目データが、１回目の入力項目データか認識項目データのいずれかと一致すれば一致したものと見なす。これにより、入力ミスであった場合は２回目の入力で認識項目データと一致することによりベリファイＯＫとなる。また認識項目データが記入と異なっていた場合も、１回目の入力項目データと、修正入力された項目データとが一致することにより、すなわち同じデータが２回入力されたことをもって、ベリファイＯＫとなる。ベリファイ結果は記憶部１７に記憶される。
【００３９】
図６（ｂ）の例では、１回目の入力項目データと修正入力された項目データの双方が「１２３４５６７」であったことにより、ベリファイＯＫとなる。
【００４０】
なお、図７は認識項目データが正常で、１回目の入力にミスがあった場合の例である。図７（ａ）においてオペレータは口座番号を「１２３４５６７」と入力すべきところ誤って「２３４５６７８」と入力している。このため図７（ｂ）のベリファイ修正入力が行なわれ、修正入力では正しく入力している。このため、修正入力項目データと認識項目データが一致するので、ベリファイＯＫとなっている。
【００４１】
Ｓ１０５：修正入力されたデータが、１回目の入力項目データと認識項目データのいずれとも一致しなかった場合は、ベリファイＮＧとする。ベリファイ結果は記憶部１７に記憶される。
【００４２】
Ｓ１０６：１回目にベリファイＮＧとなったすべての項目についてベリファイが完了したら処理を抜ける。ベリファイ未完了の項目が残っていれば、次の項目についてＳ１０２以降の処理を繰り返す。
【００４３】
Ｓ１０７：２回目のベリファイを終了する。
【００４４】
このように、手入力したデータと文字認識したデータによってベリファイを行なう窓口端末１において、ベリファイが一致した場合に確定したデータとして扱うことにより、正常なデータご修正してしまうことを防ぐことが出来る。かつ２回目以降のベリファイの対象に文字認識結果のみでなく１回目の手入力データを用いたことにより、文字認識結果が誤っていた場合であっても同じデータが２回入力されたことを以ってベリファイ一致とすることができる。これらによって、伝票４のデータ入力の効率が向上する。
【００４５】
なお、上記の例において、ベリファイ修正入力にてベリファイＮＧとなった場合取引キャンセルすることとしているが、２回以上のベリファイ修正入力を行なわせても構わない。その場合、ベリファイ対象のデータとして、前回の修正入力データを記憶部１７に記憶して用いるようにすれば、１回目の入力項目データと認識項目データの双方に誤りがあった場合でも救済することができる。
【００４６】
なお、上記の例において、最初にオペレータが業務を選択するとしたが、オペレータは業務を選択せず、Ｓ００３にて認識したシートＩＤを用いて業務を特定することも可能である。
【００４７】
なお、上記の例では入力画面５上のすべての項目をベリファイ対象としているが、ベリファイ対象とするのは重要なデータのみとしたい場合も考えられる。この場合、当該入力画面５のベリファイ対象の項目を指定したベリファイ対象情報を記憶部１７に保持し、比較部１６はベリファイ対象情報を参照して指定されている項目のみをベリファイするようにすればよい。また、入力画面５はベリファイ修正入力時にベリファイ対象情報を参照して、比較対象である入力フィールド５３と比較対象でない入力フィールド５３とを識別可能に表示すれば入力しやすい。また、比較対象でないフィールドについてはベリファイ修正入力の際には入力を受け付けないようロックすれば誤修正を防ぐことができる。
【実施例２】
【００４８】
＜実施例２の構成＞
実施例１はベリファイ用のデータとして文字認識結果を用いるものであったため、文字認識結果自体が誤っている場合の対応が必要であった。これに対し、通帳やカード等に記録されている電子化済みのデータを用いれば、より確実なベリファイが行なえる。実施例２においては、通帳やカードから取得できる項目については文字認識によるデータを入力データとし、通帳やカードから取得するデータがベリファイ用のデータとしてベリファイ処理を行なう。
【００４９】
図８はこの発明の第２の実施例を示す構成図である。主な構成は第１の実施例と同様である。同じ構成については説明を省略する。図８において、追加されている構成は通帳伝票プリンタ１９と、通帳伝票プリンタ１９に内蔵されているＭＳリーダ・ライタ２０と、通帳伝票プリンタ１９に内蔵されているページマーク読取部２１である。
【００５０】
通帳伝票プリンタ１９は、窓口にて顧客から受け取った通帳と、伝票４をセットして取引処理を行なうことが出来るものであり、通帳と伝票４に対して印字を行なったり、情報を取得したりする機能を有している。
【００５１】
ＭＳリーダ・ライタ２０は、通帳のＭＳ（磁気ストライプ）に対して読取り・書き込みを行なうことができる。通帳のＭＳには、口座番号等の口座情報や通帳の普通口座、総合口座等の種別が記録されており、ＭＳリーダ・ライタ２０を用いて、その通帳の口座情報や通帳の種別を取得することが可能となっている。
【００５２】
ページマーク読取部２１は通帳の各ページに印刷されているページマークを読み取るためのものである。ページマークによって現在開いているページが分かる。総合口座の通帳の場合は普通預金のページと定期預金のページが分かれており、現在開いているページが分かれば普通預金のページが開かれているのか、定期預金のページが開かれているのかが分かる。すなわち、通帳の何ページから何ページまでが普通預金であり、何ページから何ページまでが定期預金であるかの情報を保持しておけば、ページ番号から普通預金／定期預金の区別を行なうことが出来る。
【００５３】
＜実施例２の動作＞
ここで、図９に基づいて顧客が窓口に提示した伝票４のデータを窓口端末１から入力し、ベリファイを経てデータを確定するまでの処理の流れについて、説明を行なう。
【００５４】
Ｓ２０１：顧客が記入した伝票４および通帳を受け取ると、オペレータは窓口端末１を操作して、伝票４に対応する取引種別を選択する。ここでは図２に示す伝票４を受け取ったものとする。オペレータは出金を選択する。なお、この例では出金としたが、入金等、伝票４および通帳を用いて窓口において行なう取引であればいかなる取引であっても良い。
【００５５】
Ｓ２０２：次にオペレータはスキャナ１８に伝票４をセットした後、窓口端末１を操作して、伝票４の画像の取得を指示する。これにより、スキャナ１８が動作して伝票４の画像を取得する。
【００５６】
Ｓ２０３：取得した伝票４の画像は文字認識部１５に渡される、第１の実施例と同様にして認識される。第１の実施例と同様に、認識項目データと部分イメージは記憶部１７に記憶される。
【００５７】
Ｓ２０４：伝票４上の口座種別の欄に普通預金が選択されているので、オペレータは受け取った通帳の最後に記帳されている普通預金のページを開いて通帳伝票プリンタ１９に挿入する。
【００５８】
Ｓ２０５：通帳伝票プリンタ１９は、通帳が挿入されたことを検知して、通帳のＭＳに記録された口座情報や通帳の種別を読み取り、窓口端末１に通知する。口座情報には、店番、口座番号等が含まれている。窓口端末１は、通知された口座情報や通帳の種別をを通帳口座情報として記憶部１７に記憶する。さらに通帳伝票プリンタ１９は開かれたページのページマークを読み取ることによってページ番号を取得し、窓口端末１に通知する。窓口端末１は、通帳が総合口座の通帳である場合、通知されたページ番号を元に開かれているページが普通預金のページであるか定期預金のページであるかを特定し、通帳口座種別を特定する。通帳口座種別は記憶部１７に記憶される。
【００５９】
Ｓ２０６： 比較部１６は、認識項目データのうち口座番号と、前記通帳口座情報のうち口座番号とを比較する。また、認識項目データのうち口座種別と、前記ページ番号を元に特定した通帳口座種別を比較する。これらの比較結果は記憶部１７に記憶される。
【００６０】
Ｓ２０７:前記比較結果において、口座種別が一致している場合は口座種別をベリファイＯＫとして確定し、次の処理に進む。
【００６１】
Ｓ２０８：口座種別が一致していない場合は、通帳の誤挿入があったと判断する。その場合、ディスプレイ１３に通帳の誤挿入があった旨をエラー表示し、通帳を排出する。オペレータは通帳を確認し、正しいページを開いて再セットする。再セットされた帳票は前述と同様の方法で口座情報およびページ情報が取得される。一致すれば口座種別をベリファイＯＫとして確定し、次の処理へ進む。一致しなければ再度同じエラー表示を行なう。これによって、帳票の誤挿入を事前に検出して、印字等を行なう前に通知できるため、訂正等の手間を省くことができる。
【００６２】
Ｓ２０９：前記比較結果において、口座番号が一致した場合は口座番号をベリファイＯＫとして確定し、次の種類へ進む。
【００６３】
Ｓ２１０：口座番号および口座種別が確定状態であるため、それ以外の項目が入力できる状態となったベリファイ入力画面を表示する。図１０（ａ）は、その場合の入力画面５の例である。図１０（ａ）において、第１実施例の説明で用いた図に加え、口座種別の入力用イメージ５２ｃと口座種別の入力フィールド５３ｃが追加されている。入力用イメージ５２ｃには口座種別のマーク箇所のイメージが表示される。この例では、口座種別の入力用イメージにより「普通」にマークがされていることが分かる。入力フィールド５３ｃには前述の処理により確定された口座種別として「普通」が表示されている。また、口座番号についても前述の処理により確定された内容として「１２３４５６７」が表示されている。口座種別および口座番号は既に確定されているので、入力ロックされている。このとき、入力ロックされていることを示すために、グレー表示等目立たない表示にすることもできる。この例では金額のみ未確定の状態であり、入力フィールド５３ｂは、入力を受けるために空欄となる。また、図１０（ａ）のように、入力を受け付けることを示すために背景色を変える等して強調表示を行なうこともできる。
【００６４】
Ｓ２１１：口座種別が確定状態であるため、それ以外の項目が入力できる状態となったベリファイ入力画面を表示する。図１０（ｂ）は、その場合の入力画面５の例である。図の構成は図１０（ａ）と同じである。この例では、入力フィールド５３ｃには前述の処理により確定された口座種別として「普通」が表示されている。口座種別は既に確定されているので、入力ロックされている。このとき、入力ロックされていることを示すために、グレー表示等目立たない表示にすることもできる。口座番号および金額は未確定の状態であり、入力フィールド５３ｂおよび５３ｃは、入力を受けるために空欄となる。また、図１０（ｂ）のように、入力を受け付けることを示すために背景色を変える等して強調表示を行なうこともできる。
【００６５】
Ｓ２１２：表示されたベリファイ入力画面で、ベリファイ入力を行なう。
【００６６】
このように、実施例１のベリファイ入力の前に、文字認識によって入力した口座情報と、通帳から読み取った口座情報によってベリファイを行なうので、口座情報についてはより確度の高いベリファイが行なえ、より効率的にデータを確定することが可能となる。また、通帳のページ番号から特定した口座種別と、文字認識によって取得した口座種別によってベリファイを行なうので総合口座の通帳のミスセットを検出することもでき、取引が進んでからミスに気づくことが無くなり、効率的に取引を行なうことができる。
【００６７】
なお、本実施例において伝票の入力に文字認識を使用したが、伝票に記載された情報の入力を行なえる手段であればよく、実施例１と同様に手入力による入力を行なっても構わない。
【００６８】
なお、上記の例において、最初にオペレータが業務を選択するとしたが、オペレータは業務を選択せず、Ｓ００３にて認識したシートＩＤを用いて業務を特定することも可能である。
【００６９】
なお、本実施例において通帳を用いるとしたが、口座番号のベリファイのみを行なう場合は、キャッシュカードを用いても良い。この場合、窓口端末１にさらにカードリーダ・ライタを備えればよい。
【００７０】
なお、本実施例においてスキャナ１８および通帳伝票プリンタ１９は外付けのものとして説明しているが、窓口端末１の筐体に内蔵していても構わない。その場合の処理は本実施例と何ら変わりなく行なうことができる。
【００７１】
また、上記の第１第２の実施例において金融機関の営業店窓口端末を用いて説明したが、何らかの帳票について２つの入力方法によって入力を行ないそれぞれの入力内容を比較するものであれば、上記の処理が適用可能であることは言うまでもない。
【図面の簡単な説明】
【００７２】
【図１】実施例１の構成
【図２】伝票
【図３】入力画面
【図４】実施例１の処理フロー
【図５】実施例１の２回目のベリファイの処理フロー
【図６】実施例１の入力画面の遷移
【図７】実施例１の入力画面の遷移
【図８】実施例２の構成
【図９】実施例２の処理フロー
【図１０】実施例２の入力画面
【符号の説明】
【００７３】
１  金融営業店窓口端末
２  ホスト
３  ネットワーク
４  伝票
５  入力画面
１１  制御部
１２  入力部
１４  キーボード
１４  ソフトキーボード
１５  文字認識部
１６  比較部
１７  記憶部
１８  スキャナ
１９  通帳伝票プリンタ
２０  ＭＳリーダ・ライタ
２１  ページマーク読取部
５２  入力用イメージ
５３  入力フィールド
【図１】
2005352652.tif 000003
【図２】
2005352652.tif 000004
【図３】
2005352652.tif 000005
【図４】
2005352652.tif 000006
【図５】
2005352652.tif 000007
【図６】
2005352652.tif 000008
【図７】
2005352652.tif 000009
【図８】
2005352652.tif 000010
【図９】
2005352652.tif 000011
【図１０】
2005352652.tif 000012