(57)【特許請求の範囲】
【請求項１】
入力装置と、前記入力装置に接続されたプロセッサと、前記プロセッサに接続された記憶装置と、前記プロセッサに接続された出力装置と、を備える文書処理装置であって、
前記記憶装置は、活字文字の特徴量を示す情報を含む活字文字認識用辞書、手書き文字の特徴量を示す情報を含む手書き文字認識用辞書、並びに、複数の文字、前記複数の文字間の接続、及び前記接続の起こりやすさを示すスコアを含む文字列パターン辞書を保持し、
前記プロセッサは、
前記入力装置を介して入力された手書き文字列及び活字文字列を含む画像データを取得し、
前記活字文字認識用辞書を用いて前記活字文字列を認識し、
前記活字文字列の認識結果として取得した文字列及びその文字列に含まれる文字間の接続が既に前記文字列パターン辞書に登録されている場合、前記登録されている文字間の接続に関する前記スコアの値を増加させ、前記活字文字列の認識結果として取得した文字列及びその文字列に含まれる文字間の接続が前記文字列パターン辞書に登録されていない場合、前記活字文字列の認識結果として取得した文字列に含まれる文字、それらの文字間の接続及びその接続の起こりやすさを示すスコアを新たに前記文字列パターン辞書に登録し、
前記手書き文字認識用辞書及び前記文字列パターン辞書を用いて前記手書き文字列を認識し、
前記出力装置を介して前記手書き文字列の認識結果を出力することを特徴とする文書処理装置。
【請求項２】
前記プロセッサは、
前記手書き文字認識用辞書に基づいて、前記手書き文字列の認識結果の候補として複数の文字列を生成し、
前記生成された複数の文字列から、前記文字列パターン辞書に含まれる文字列を検索し、
前記検索によって取得した文字列を、前記手書き文字列の認識結果として取得することを特徴とする請求項１に記載の文書処理装置。
【請求項３】
前記記憶装置は、同一と判定される複数の文字又は文字列を対応付ける置換辞書をさらに保持し、
前記プロセッサは、前記置換辞書に基づいて、前記活字文字列の認識結果として取得した文字列に含まれる文字又は文字列を、それと同一と判定される文字又は文字列に置き換えた文字列を生成し、前記生成された文字列を前記文字列パターン辞書として前記記憶装置に格納することを特徴とする請求項１又は２に記載の文書処理装置。
【請求項４】
入力装置と、前記入力装置に接続されたプロセッサと、前記プロセッサに接続された記憶装置と、前記プロセッサに接続された出力装置と、を備える装置が実行する文書処理方法であって、
前記記憶装置は、活字文字の特徴量を示す情報を含む活字文字認識用辞書、手書き文字の特徴量を示す情報を含む手書き文字認識用辞書、並びに、複数の文字、前記複数の文字間の接続、及び前記接続の起こりやすさを示すスコアを含む文字列パターン辞書を保持し、
前記文書処理方法は、
前記プロセッサが、前記入力装置を介して入力された手書き文字列及び活字文字列を含む画像データを取得する第１手順と、
前記プロセッサが、前記活字文字認識用辞書を用いて前記活字文字列を認識する第２手順と、
前記プロセッサが、前記活字文字列の認識結果として取得した文字列及びその文字列に含まれる文字間の接続が既に前記文字列パターン辞書に登録されている場合、前記登録されている文字間の接続に関する前記スコアの値を増加させ、前記活字文字列の認識結果として取得した文字列及びその文字列に含まれる文字間の接続が前記文字列パターン辞書に登録されていない場合、前記活字文字列の認識結果として取得した文字列に含まれる文字、それらの文字間の接続及びその接続の起こりやすさを示すスコアを新たに前記文字列パターン辞書に登録する第３手順と、
前記プロセッサが、前記手書き文字認識用辞書及び前記文字列パターン辞書を用いて前記手書き文字列を認識する第４手順と、
前記プロセッサが、前記出力装置を介して前記手書き文字列の認識結果を出力する第５手順と、を含むことを特徴とする文書処理方法。
【請求項５】
前記第４手順は、
前記プロセッサが、前記手書き文字認識用辞書に基づいて、前記手書き文字列の認識結果の候補として複数の文字列を生成する手順と、
前記プロセッサが、前記生成された複数の文字列から、前記文字列パターン辞書に含まれる文字列を検索する手順と、
前記プロセッサが、前記検索によって取得した文字列を、前記手書き文字列の認識結果として取得する手順と、を含むことを特徴とする請求項４に記載の文書処理方法。
【請求項６】
前記記憶装置は、同一と判定される複数の文字又は文字列を対応付ける置換辞書をさらに保持し、
前記文書処理方法は、さらに、前記プロセッサが、前記置換辞書に基づいて、前記活字文字列の認識結果として取得した文字列に含まれる文字又は文字列を、それと同一と判定される文字又は文字列に置き換えた文字列を生成する手順を含み、
前記第３手順は、前記生成された文字列を前記文字列パターン辞書として前記記憶装置に格納する手順を含むことを特徴とする請求項４又は５に記載の文書処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文字認識技術に関し、特に、活字文字を認識した結果を利用して手書き文字を認識する技術に関する。
【背景技術】
【０００２】
手書き文字及び活字文字を光学的に読み取り、これを文字データに変換して利用する文字認識技術が開示されている。
【０００３】
例えば特許文献１には、難解な文字又は判読不能な文字を含む文字列を正確かつ効率的に読み取る技術が開示されている。
【０００４】
特許文献２には、タイプミス又は語の転置等に起因する表記ゆれを含むテキストから、辞書に登録された文字列を抽出する技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−２６５７５８号公報
【特許文献２】特開２００７−２５８３４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
文字認識技術には種々の用途があるが、その一例として、官庁又は企業等における窓口業務が挙げられる。例えば、申請者が手書きした種々の申請書類を自動的に文字データに変換することによって、窓口業務を効率化することができる。しかし、活字文字の認識精度と比較すると、手書き文字の認識精度が著しく低いことが従来の文字認識技術の問題であった。また、一般に窓口では種々の書類が処理されるが、書類の種類ごとにフォーマットが異なる場合、読み取るべき手書き文字が書かれている位置も種類ごとに異なり、このことが原因で手書き文字の認識に失敗する場合もある。
【０００７】
さらに、このような申請書類を受け付ける際に、申請者の本人確認が要求される場合がある。例えば、申請者が手書きした申請書類と、申請者が持参した本人確認書類（例えば自動車運転免許証等）とが照合され、両者の記載内容が一致すると判定された場合に申請書類が受理される。このような照合作業も文字認識技術を用いて自動化することができれば、窓口業務が大幅に効率化されるとともに、窓口のオペレータによる不正な処理も防止することができる。
【０００８】
しかし、このような本人確認を自動化する場合、上記のような手書き文字の認識精度の問題に加えて、文字の種類の相違が原因で本人確認に失敗するという問題がある。本人確認書類に記載された活字文字は、その書類を作成したシステムにおいて使用できるものに限定される。このため、本人確認書類に記載された活字文字の字体が、申請者が手書きした文字の字体と異なる場合がある。このような相違は、典型的には漢字の異体字が使用される場合に発生するが、その他の場合にも発生し得る。例えば、本人確認書類がパスポートであり、申請書類には漢字の記入が要求される場合、漢字の手書き文字とローマ字の活字文字とが照合される。これらの場合には、文字認識そのものが成功したとしても、本人確認は失敗することになる。
【０００９】
本発明は上記のような問題点に鑑みてなされたものであり、文字認識の精度を改善するとともに、文字の種類の相違に起因する本人確認の失敗を防止することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の代表的な一例を示せば次の通りである。すなわち、入力装置と、前記入力装置に接続されたプロセッサと、前記プロセッサに接続された記憶装置と、前記プロセッサに接続された出力装置と、を備える文書処理装置であって、前記記憶装置は、活字文字の特徴量を示す情報を含む活字文字認識用辞書、手書き文字の特徴量を示す情報を含む手書き文字認識用辞書、並びに、複数の文字、前記複数の文字間の接続、及び前記接続の起こりやすさを示すスコアを含む文字列パターン辞書を保持し、前記プロセッサは、前記入力装置を介して入力された手書き文字列及び活字文字列を含む画像データを取得し、前記活字文字認識用辞書を用いて前記活字文字列を認識し、前記活字文字列の認識結果として取得した文字列及びその文字列に含まれる文字間の接続が既に前記文字列パターン辞書に登録されている場合、前記登録されている文字間の接続に関する前記スコアの値を増加させ、前記活字文字列の認識結果として取得した文字列及びその文字列に含まれる文字間の接続が前記文字列パターン辞書に登録されていない場合、前記活字文字列の認識結果として取得した文字列に含まれる文字、それらの文字間の接続及びその接続の起こりやすさを示すスコアを新たに前記文字列パターン辞書に登録し、前記手書き文字認識用辞書及び前記文字列パターン辞書を用いて前記手書き文字列を認識し、前記出力装置を介して前記手書き文字列の認識結果を出力することを特徴とする。
【発明の効果】
【００１１】
本発明の一実施形態によれば、手書き文字の認識精度を改善することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態の窓口受付システムの構成を示すブロック図である。
【図２】本発明の実施形態の窓口受付システムによって読み取られた画像の説明図である。
【図３】従来のＯＣＲ装置による窓口業務効率化のための文字認識処理のフローチャートである。
【図４】本発明の実施形態の窓口受付システムが実行する文字認識処理のフローチャートである。
【図５】本発明の実施形態の項目名辞書の説明図である。
【図６】本発明の実施形態のデータ文字列パターン辞書の説明図である。
【図７】本発明の実施形態の窓口受付システムが実行するデータ文字列パターン辞書の動的追加処理のフローチャートである。
【図８】本発明の実施形態の窓口受付システムが実行する、データ文字列パターン辞書を予め保持しない場合の手書き文字認識処理のフローチャートである。
【図９】本発明の実施形態の窓口受付システムが実行する、データ文字列パターン辞書を予め保持しない場合の手書き文字認識処理の別の例を示すフローチャートである。
【発明を実施するための形態】
【００１３】
以下、図面を用いて本発明の実施の形態を説明する。
【００１４】
図１は、本発明の実施形態の窓口受付システムの構成を示すブロック図である。
【００１５】
本実施形態の窓口受付システム１０は、窓口業務を支援するために、文字認識を利用して文書処理を行う計算機であり、例えば、入力装置１１、表示装置１２、ＣＰＵ（Central Processing Unit）１３、印刷装置１４、ワークエリア１５及び情報保持手段１６を備える。
【００１６】
入力装置１１は、入力装置１１０及び画像入力装置１１１を含む。入力装置１１０は、ユーザによる指示等の入力を受け付ける装置であり、例えばキーボード、マウス又はタッチパネル等であってもよい。画像入力装置１１１は、手書き文字及び活字文字等が記載された書面を光学的に読み取ってそれらを画像データに変換する、いわゆるイメージスキャナである。
【００１７】
表示装置１２は、ユーザに種々の文字及び画像等の情報を出力する装置であり、例えば液晶ディスプレイのような画像表示装置であってもよい。
【００１８】
ＣＰＵ１３は、ワークエリア１５に格納されたプログラムを実行することによって種々の機能を実現する処理装置である。以下に説明される各プログラムの処理は、実際にはＣＰＵ１３が実行する。
【００１９】
印刷装置１４は、ユーザに提供する種々の情報を必要に応じて印刷する。
【００２０】
ワークエリア１５は、ＣＰＵ１３によって実行されるプログラム等が格納される記憶領域である。本実施形態のワークエリア１５には、ＯＳ（Operating System）１５１、通信プログラム１５２、文書処理プログラム１５３及び文字認識プログラム１５４が格納される。ワークエリア１５にはさらに他のプログラムが格納されてもよいし、それらのプログラムをＣＰＵ１３が実行するときに参照されるデータが格納されてもよいし、ＣＰＵ１３が実行した処理の結果が格納されてもよい。これらのプログラムに基づく処理については後述する。
【００２１】
情報保持手段１６は、ＣＰＵ１３が各プログラムに基づいて種々の処理を実行するために参照する情報を格納する。本実施形態の情報保持手段１６には、活字文字認識用辞書１６１、手書き文字認識用辞書１６２、外字・ローマ字辞書１６３、配置知識辞書１６４、項目名辞書１６５及びデータ文字列パターン辞書１６６が格納される。
【００２２】
活字文字認識用辞書１６１は、活字文字の特徴量を示す情報を含み、窓口受付システム１０が活字文字認識を実行する際に参照される。手書き文字認識用辞書１６２は、手書き文字の特徴量を示す情報を含み、窓口受付システム手書き文字認識を実行する際に参照される。これらの辞書は、従来の文字認識において使用されるものと同様のものであってよい。
【００２３】
外字・ローマ字辞書１６３には、窓口受付システム１０が同一と判定する文字の範囲を示す情報が格納される。例えば、特定の漢字の異体字がその漢字の代わりに慣用される場合であって、窓口受付システム１０がそれらを同一の文字と判定することが許容される場合、それらを対応付ける情報が外字・ローマ字辞書１６３に格納される。さらに、漢字とその漢字に対応するローマ字表記とを対応付ける情報が外字・ローマ字辞書１６３に格納されてもよい。外字・ローマ字辞書１６３及びそれを用いた処理の例については後述する（図９参照）。
【００２４】
配置知識辞書１６４、項目名辞書１６５及びデータ文字列パターン辞書１６６については後述する（図４参照）。なお、後述するように、窓口受付システム１０がデータ文字列パターン辞書１６６を予め保持しない場合もある。
【００２５】
情報保持手段１６にはさらに他の情報が格納されてもよいが、本実施形態では説明を省略する。
【００２６】
ワークエリア１５及び情報保持手段１６は、窓口受付システム１０に実装された記憶装置に相当する。典型的には、ワークエリア１５がＤＲＡＭ（Dynamic Random Access Memory）のような高速かつ揮発性の記憶装置であり、情報保持手段１６がＨＤＤ（Hard Disk Drive）又はフラッシュメモリのような大容量かつ不揮発性の記憶装置であるが、その他の種類の記憶装置であってもよい。各プログラムは、情報保持手段１６に格納され、ＣＰＵ１３によって実行されるときにワークエリア１５にコピーされてもよい。また、情報保持手段１６に格納された辞書の少なくとも一部が、必要に応じて一時的にワークエリア１５にコピーされてもよい。
【００２７】
窓口受付システム１０は、さらに、通信ネットワーク１９を介して一つ以上のファイルサーバ２１と接続されてもよい。各ファイルサーバ２１は、通信ネットワーク１９に接続された計算機であり、そのハードウエア構成は窓口受付システム１０と同様であってもよい。
【００２８】
図１には、窓口受付システム１０が一つの計算機によって実現される例を示したが、窓口受付システム１０と同様の機能が複数の計算機によって実現されてもよい。例えば、活字文字認識用辞書１６１等の各種の辞書が情報保持手段１６に格納される代わりにいずれかのファイルサーバ２１に格納されてもよい。あるいは、例えば、画像入力装置１１１が一つ又は複数のファイルサーバ２１に設けられ、その画像入力装置１１１が後述する申請書及び本人確認書類を読み取ってもよい。その場合、ファイルサーバ２１によって読み取られた画像データが通信ネットワーク１９を介して窓口受付システム１０に送信される。上記の場合、入力装置１１は、通信ネットワーク１９に接続された通信装置を含んでもよい。通信ネットワーク１９を介した通信は、通信プログラム１５２によって制御される。
【００２９】
図２は、本発明の実施形態の窓口受付システム１０によって読み取られた画像の説明図である。
【００３０】
窓口受付システム１０は、画像入力装置１１１を用いて申請書及びその申請書を受け付けるために必要な本人確認書類を光学的に読み取り、それによって得られた画像データをワークエリア１５又は情報保持手段１６に格納する。このような読み取りはどのような手順で実行されてもよいが、典型的には、それらの書類が１枚の画像に含まれるように読み取られる。図２には、一例として、住民票を取得するための申請書２１１及び運転免許証２１２（すなわち本人確認書類）が読み取られた場合の画像２００を示す。
【００３１】
申請書２１１には、申請者の住所、氏名及び生年月日等が手書きされる。以下、申請書２１１の氏名欄２０１（図２の「氏名欄１」）に手書きされた氏名の文字の認識を例として説明するが、本実施形態は他の欄に記載された手書き文字についても適用することができ、また、手書き文字を含む書類であれば、申請書以外の書類にも適用することができる。図２の例では、氏名として手書き文字列「日崎太郎」が記載されている。
【００３２】
運転免許証２１２には、免許を受けた者の住所、氏名及び生年月日等が活字で記載されている。以下の説明では、氏名欄２０２（図２の「氏名欄２」）に記載された氏名の活字文字が使用される。なお、運転免許証は本人確認書類の一例であり、それ以外の書類（例えばパスポート又は健康保険証等）が本人確認書類として使用されてもよい。図２の例では、氏名として活字文字列「日埼太郎」が記載されている。
【００３３】
図３は、従来のＯＣＲ（光学式文字読取）装置による窓口業務効率化のための文字認識処理のフローチャートである。
【００３４】
例えば図２の申請書２１１の画像が入力されると（ステップ３０１）、従来のＯＣＲ装置（図示省略）は、入力された画像における氏名欄２０１の位置を判定し（ステップ３０２）、氏名欄２０１に記載された手書き文字を認識する（ステップ３０３）。
【００３５】
一方、例えば図２の運転免許証２１２の画像が入力されると（ステップ３１１）、従来のＯＣＲ装置は、入力された画像における氏名欄２０２の位置を判定し（ステップ３１２）、氏名欄２０２に記載された活字文字を認識する（ステップ３１３）。活字文字認識処理（ステップ３０１〜３０３）及び手書き文字認識処理（ステップ３１１〜３１２）は、一つのＯＣＲ装置によって実行されてもよいし、それぞれ別のＯＣＲ装置によって実行されてもよい。
【００３６】
その後、従来のＯＣＲ装置は、ステップ３０３における認識結果と、ステップ３１３における認識結果とを照合し（ステップ３０４）、両者が一致するか否かを判定する（ステップ３０５）。両者が一致する場合、本人確認に成功したため、申請書は受理され、申請書に基づく申請処理が実行される。この申請処理は従来と同様であるため説明を省略する。一方、両者が一致しない場合、文字認識による本人確認に失敗したため、別の方法による本人確認（例えば窓口オペレータの人手による本人確認等）が実行される。
【００３７】
上記のステップ３１２における氏名欄の判定は、例えば次のように行われる。ＯＣＲ装置は、予め、配置知識辞書、項目名辞書及びデータ文字列パターン辞書を保持する。これらは、本発明の実施形態の配置知識辞書１６４、項目名辞書１６５及びデータ文字列パターン辞書１６６と同様のものであってよい。ＯＣＲ装置は、項目名辞書に基づいて本人確認書類上の文字列の項目名（例えば「氏名」のような項目名を示す文字列）らしさを判定し、データ文字列パターン辞書１６６に基づいて本人確認書類上の文字列の項目値（例えば「田中」のような氏名を示す文字列）らしさを判定し、項目名らしいと判定された文字列と、項目値らしいと判定された文字列との位置関係が配置知識辞書に登録された位置関係と一致する場合に、その領域を氏名欄２０２として抽出する。
【００３８】
しかし、この方法によれば、予めデータ文字列パターン辞書に登録されていない氏名が入力されたことによって氏名欄２０２の抽出に失敗する場合がある。氏名欄２０２及び２０１の抽出にいずれも成功したとしても、記載された氏名がデータ文字列パターン辞書に登録されていなければ、その後の文字認識に失敗する可能性が高い。
【００３９】
また、現在の文字認識技術による活字文字の認識精度は実用上十分な程度に高いが、それと比較して手書き文字認識の精度は著しく低い。このため、本来は正しいはずの申請書及び本人確認書類が入力され（すなわち氏名欄２０１と氏名欄２０２に同じ氏名が記載され）、かつ、記載された氏名が辞書に登録されていた場合であっても、ステップ３０５において両者が一致しないと判定される頻度が高くなる。
【００４０】
上記のようにＯＣＲ装置による本人確認の失敗が多発すれば、オペレータの作業負担が十分に軽減されず、したがって、窓口業務を十分に効率化することができない。
【００４１】
図４は、本発明の実施形態の窓口受付システム１０が実行する文字認識処理のフローチャートである。
【００４２】
最初に、窓口受付システム１０の画像入力装置１１１を用いて申請書及び本人確認書類が入力される（ステップ４０１）。例えば、申請書２１１及び運転免許証２１２（すなわち本人確認書類）が画像入力装置１１１によって読み取られ、図２に示す画像２００が取得される。
【００４３】
次に、窓口受付システム１０は、本人確認書類の項目領域を抽出する（ステップ４０２）。項目領域とは、住所、氏名又は生年月日等の項目の値が記載された領域である。ここでは氏名の認識を例として説明するため、少なくとも氏名欄２０２が項目領域として抽出される。この抽出は、情報保持手段１６に保持された配置知識辞書１６４及び項目名辞書１６５に基づいて行われる。
【００４４】
項目名辞書１６５には、各項目領域に対応して表示される項目名が格納される。例えば、運転免許証２１２の氏名欄２０２の近傍には、項目名として「氏名」の文字が表示されている。この表示は、氏名欄２０２の位置を特定するための標識（ラベル）として使用される。この場合、項目名辞書１６５には、「氏名」の文字列が格納される。
【００４５】
本人確認書類として運転免許証以外の書類が使用されてもよく、それらの書類では、氏名欄の項目名として「氏名」以外の文字列、例えば「Ｎａｍｅ」等が表示される場合もある。また、後述するように、項目名辞書１６５は、申請書における項目領域（例えば申請書２１１の氏名欄２０１）の位置を特定するためにも使用される。申請書に項目名として表示される文字列は、本人確認書類のそれと異なる場合がある。例えば、申請書に「お名前」の文字列が印刷され、その近傍に申請者の氏名を手書きする領域が確保されている場合がある。また、窓口受付システム１０が複数の種類の申請書を処理する場合があり、申請書の種類によって項目名として表示される文字列が異なる場合もある。このため、項目名辞書１６５には、氏名欄の項目名として、「氏名」以外の文字列、例えば「お名前」及び「Ｎａｍｅ」等がさらに格納されてもよい。
【００４６】
氏名欄２０２以外の項目領域についても、項目名の文字列が、各項目領域について一つ以上格納される。項目名辞書１６５の一例については図５を参照して後述する。
【００４７】
配置知識辞書１６４には、各項目領域の配置を示す情報、より具体的には、各項目名の表示と、各項目名に対応する項目領域との位置関係を重み付けする情報が格納される。例えば、運転免許証２１２に表示された項目名「氏名」の右側の所定の範囲が氏名欄２０２である。この場合、配置知識辞書１６４には、文字列「氏名」の表示と氏名欄２０２との位置関係を示す情報が格納される。上記の項目名辞書１６５の場合と同様、配置知識辞書１６４にも、種々の本人確認書類及び種々の申請書における項目名の表示と項目領域との位置関係を示す情報が格納される。
【００４８】
窓口受付システム１０は、これらの辞書に基づいて、氏名欄２０２等の項目領域を抽出する。例えば、窓口受付システム１０は、項目名辞書１６５に基づいて本人確認書類上の文字列の項目名らしさを判定し、項目名らしいと判定された文字列との位置関係が配置知識辞書１６４に登録された位置関係と一致する領域を項目領域として抽出する。
【００４９】
次に、窓口受付システム１０は、ステップ４０２において抽出された項目領域に記載された住所、氏名及び生年月日等の活字文字を認識する（ステップ４０３）。この手順は従来の文字認識と同様であるため、詳細な説明は省略する。
【００５０】
次に、窓口受付システム１０は、ステップ４０３における活字文字の認識結果を用いて、手書き文字認識用の候補文字列パターン辞書を作成する（ステップ４０４）。窓口受付システム１０は、予めデータ文字列パターン辞書１６６を保持していない場合には、作成された候補文字列パターン辞書をデータ文字列パターン辞書１６６として使用し、予めデータ文字列パターン辞書１６６を保持していた場合には、作成された候補文字列パターン辞書を用いてデータ文字列パターン辞書１６６を更新する。これらの処理については後述する（図７及び図８等参照）。
【００５１】
次に、窓口受付システム１０は、申請書において手書き文字が記載された項目領域を抽出する（ステップ４０５）。ここで抽出される項目領域は、申請書における住所、氏名又は生年月日等が記載された領域であり、申請者による手書き文字が記載されている。この抽出は、ステップ４０２における抽出と同様に、配置知識辞書１６４及び項目名辞書１６５を参照して行われる。
【００５２】
次に、窓口受付システム１０は、ステップ４０５において抽出された項目領域に記載された住所、氏名及び生年月日等の手書き文字を認識する（ステップ４０６）。この手順は、ステップ４０４において更新又は作成されたデータ文字列パターン辞書１６６を参照する点を除いて従来の文字認識と同様であるため、その詳細な説明は省略する。すなわち、辞書の参照方法及びそれに基づく文字認識の方法は従来と同様である。
【００５３】
次に、窓口受付システム１０は、認識した結果を出力して（ステップ４０７）、処理を終了する。例えば、窓口受付システム１０は、氏名欄２０１の文字認識（ステップ４０３）によって得られた文字列そのものを表示装置１２に表示してもよいし、その文字列と、氏名欄２０２の文字認識（ステップ４０６）によって得られた文字列とが一致するか否かを判定し、その結果を表示装置１２に表示してもよい。具体的には、例えば、両者が一致しないと判定された場合、本人確認に失敗したことを示すアラートを表示装置１２に表示してもよい。
【００５４】
なお、以上の処理は、詳細には、窓口受付システム１０のＣＰＵ１３がワークエリア１５内のプログラムに従って実行する。例えば、ステップ４０２、４０４及び４０５が文書処理プログラム１５３に従って実行され、ステップ４０３及び４０６が文字認識プログラムに従って実行される。
【００５５】
図５は、本発明の実施形態の項目名辞書１６５の説明図である。
【００５６】
項目名辞書１６５は、本人確認書類及び申請書の項目名の文字列を定義する情報を含む。例えば、図５に示す項目名辞書１６５は、「Ｓｕｒｎａｍｅ」５０１、「氏名」５０２、「住所」５０３、「お名前」５０４及び「ご住所」５０５を含む。「Ｓｕｒｎａｍｅ」５０１は、本人確認書類がパスポートである場合の、氏名（姓）が記載された項目領域のラベルの例である。「氏名」５０２は、本人確認書類が運転免許証である場合の、氏名が記載された項目領域のラベルの例である。「住所」５０３は、本人確認書類が運転免許証である場合の、住所が記載された項目領域のラベルの例である。「お名前」５０４は、申請書における、氏名が手書きされる項目領域のラベルの例である。「ご住所」５０５は、申請書における、住所が手書きされる項目領域のラベルの例である。
【００５７】
図６は、本発明の実施形態のデータ文字列パターン辞書１６６の説明図である。
【００５８】
データ文字列パターン辞書１６６は、情報保持手段１６に格納され、必要に応じてその一部又は全部がワークエリア１５にロードされてもよい。
【００５９】
データ文字列パターン辞書１６６には、手書き文字列に含まれる可能性がある文字列が登録される。例えば、氏名の文字列の認識に使用されるデータ文字列パターン辞書１６６には、氏名として使用される可能性がある文字列、例えば、姓として使用される文字列＜ＮＡＭＥ１＞として「田中」、「鈴木」、「佐藤」及び「山田」等が、名として使用される文字列＜ＮＡＭＥ２＞として「一郎」、「太郎」、「花子」及び「よし子」等が登録される。さらに、上記の姓の文字列＜ＮＡＭＥ１＞と、その後に続く名の文字列＜ＮＡＭＥ２＞とからなる文字列＜Ｎ４００＞が登録される。
【００６０】
同様に、例えば住所の文字列の認識に使用されるデータ文字列パターン辞書１６６には、全国の地名の文字列等が登録される。
【００６１】
後述するように、データ文字列パターン辞書１６６は、必要に応じてワークエリア１５にロードされる。本実施形態では、同一の文字を重複して保持することを避けるため、ロードされたデータ文字列パターン辞書１６６はグラフ形式で表現される。すなわち、データ文字列パターン辞書１６６に登録された各文字がノードとして、文字と文字との接続がエッジとして表現される。例えば、姓の文字列「田中」がデータ文字列パターン辞書１６６に登録されている場合、この文字列は、文字「田」に対応するノード、文字「中」に対応するノード、及びそれらを接続するエッジによって表現される。
【００６２】
図６では省略されているが、データ文字列パターン辞書１６６は、文字と文字とが接続される可能性を示す情報を含む。この情報は、例えば、エッジに与えられるスコアであり、例えば新聞の書面等、実際に流通しているテキスト等から予め抽出される。
【００６３】
スコアは、各エッジに対応する文字の接続の起こりやすさ（言い換えると尤もらしさ）を示す重みである。本実施形態において、スコアの値が大きいほど、そのスコアが与えられたエッジに対応する文字の接続が起こりやすいことを示し、スコアの値が「０」であることは、そのエッジに対応する文字の接続が起こり得ないことを示す。
【００６４】
例えば、データ文字列パターン辞書１６６に登録されているように、文字列「田中」及び「鈴木」のような文字列は出現し得るが、文字列「田鈴」は出現し得ない場合、文字「田」と「中」とを接続するエッジ及び「鈴」と「木」とを接続するエッジには、スコアとして「０」より大きい値が与えられ、文字「田」と「鈴」とを接続するエッジには、スコアとして「０」が与えられる。後述するように、これらのスコアに基づいて、最も尤もらしい文字列が手書き文字認識結果として取得される。
【００６５】
なお、本実施形態において、ある二つの文字を接続するエッジが辞書に登録されていないことは、そのエッジを介して接続された文字列が登録されていないことを意味する。また、そのエッジが登録されていないことは、そのエッジが登録され、かつ、それのスコアが０であることと等価である。
【００６６】
上記のような辞書の構造及びそれを用いた文字認識方法は従来と同様であってよい。また、上記のようなスコアの決定方法は一例であり、スコアと接続の起こりやすさとが対応するように決定される限り、上記とは異なる規則に従ってスコアが決定されてもよい。
【００６７】
ただし、例えば氏名の文字列が登録されたデータ文字列パターン辞書１６６に、入力される可能性のある全ての氏名の文字列（すなわち文字及び文字間の接続）が登録されているとは限らない。従来のように、予め用意されたデータ文字列パターン辞書１６６のみを使用して文字認識を行う場合、その辞書に登録されていない氏名が入力されたときの認識精度は著しく低くなる。このようなことを防ぐためには新たな文字列の追加登録などを行うことも考えられるが、その場合、メンテナンスのコストが上昇する。
【００６８】
本実施形態では、メンテナンスのコストを上昇させずに手書き文字の認識精度を改善するために、本人確認書類に記載された活字文字の認識結果がデータ文字列パターン辞書１６６に追加される。以下、その具体的な手順を説明する。
【００６９】
図７は、本発明の実施形態の窓口受付システム１０が実行するデータ文字列パターン辞書の動的追加処理のフローチャートである。
【００７０】
図７に示す処理は、図４のステップ４０４において実行される。ここでは、例として、申請書２１１の氏名欄２０１に氏名の手書き文字列「渡邊太朗」が記載され、運転免許証２１２の氏名欄２０２に氏名の活字文字列「渡邊太朗」が記載されている場合について説明する。
【００７１】
最初に、窓口受付システム１０は、予め定義されたデータ文字列パターン辞書７０１をワークエリア１５にロードする。これは、図４のステップ４０３が実行される前のデータ文字列パターン辞書１６６に相当する。図６を参照して説明したように、ロードされたデータ文字列パターン辞書７０１は、グラフ形式で表現される。その具体例については後述する。
【００７２】
次に、窓口受付システム１０は、図４のステップ４０３における活字文字の認識結果を取得し、それをデータ文字列パターン辞書７０１に追加登録する。
【００７３】
ここで、図７に示すデータ文字列パターン辞書７０１の例を説明する。ロードされた時点のデータ文字列パターン辞書７０１には「渡」（文字７２１Ａ）、「辺」（文字７２１Ｂ）、「太」（文字７２１Ｃ）、「朗」（文字７２１Ｄ）、「井」（文字７２１Ｅ）及び「次」（文字７２１Ｆ）がノードとして登録され、さらに、「渡」と「辺」、「辺」と「太」、「太」と「朗」、「渡」と「井」、「井」と「太」、「辺」と「次」、及び「次」と「朗」を接続する、スコアが０より大きいエッジが含まれる。これは、「渡辺太朗」、「渡辺次朗」及び「渡井太朗」の文字列が登録されていることを意味する。
【００７４】
一方、図７の例では、ステップ４０３の認識結果として、氏名の文字列「渡邊太朗」が取得される。このような文字列はデータ文字列パターン辞書７０１に登録されていないため、手書き文字として「渡邊太朗」が入力された場合、その認識は（正しい手書き文字が入力されたとしても）失敗する可能性が高い。このため、窓口受付システム１０は、ステップ４０３において取得された文字列「渡邊太朗」をデータ文字列パターン辞書７０１に追加する。具体的には、窓口受付システム１０は、「邊」（文字７１２）をノードとして追加し、さらに、「渡」と「邊」とを接続するエッジ７１３Ａ、及び、「邊」と「太」とを接続するエッジ７１３Ｂを追加し、それらのエッジのスコアとして０より大きい値を登録する。
【００７５】
一方、ステップ４０３で取得された文字列が既にデータ文字列パターン辞書１６６に登録されている場合もある。例えば、「渡邊太朗」が取得された場合、これに含まれる文字列「太朗」に対応するエッジ、すなわち「太」と「朗」とを接続するエッジ７１３Ｃは、既に登録されている。この場合、窓口受付システム１０は、エッジ７１３Ｃのスコアを増加させる。
【００７６】
なお、このようにして新たに追加されたエッジのスコアの値及び既存のスコアの増分は、０より大きい限り、任意に決定することができるが、スコアの値が大きいほど、そのエッジに対応する文字列が認識結果として取得され易くなる。例えば、「渡邊太朗」に対応するエッジのスコアが大きいほど、手書き文字列「渡邊太朗」が「渡邊太朗」として認識されないという誤りが発生する可能性は低くなる。したがって、このような誤りを減らすために、ステップ４０３において取得された文字列に対応するエッジのスコアがそれ以外のエッジのスコアより大きくなるように、スコアの値を決定してもよい。ただし、「渡邊太朗」に対応するエッジのスコアが大きいほど、「渡邊太朗」以外の手書き文字列が「渡邊太朗」として認識されるという誤りが発生する可能性は高くなる。
【００７７】
窓口受付システム１０は、上記のようにして情報が追加されたデータ文字列パターン辞書７０２を用いて、手書き文字の認識を行う（ステップ７３２）。データ文字列パターン辞書７０２は、図４のステップ４０３が実行された後のデータ文字列パターン辞書１６６に相当し、ステップ７３２は図４のステップ４０６に相当する。この文字認識は従来と同様の方法によって実行できるため、その詳細な説明は省略するが、概要を説明すれば次の通りである。
【００７８】
窓口受付システム１０は、まず、手書き文字認識用辞書１６２に基づいて、入力された手書き文字列を含む画像から、それを構成する各文字を切り出す。通常は、切り出された文字として複数の候補が挙げられる。例えば、手書き文字列「渡邊」を含む画像が入力された場合、そこから「渡」及び「邊」を切り出すこともできるが、「三」、「度」及び「邊」を切り出すこともできる。このような「渡邊」及び「三度邊」のような複数の候補が、文字切り出し・識別仮説ネット７４１として作成される。文字切り出し・識別仮説ネット７４１のエッジ（例えば、「渡」と「邊」とを接続するエッジ、「三」と「度」とを接続するエッジ及び「度」と「邊」とを接続するエッジ）についても、切り出す位置の尤もらしさ及び切り出された画像パターンの文字らしさ等に応じたスコアが算出される。
【００７９】
そして、窓口受付システム１０は、情報が追加されたデータ文字列パターン辞書７０２のグラフによって手書き文字の文字切り出し・識別仮説ネット７４１を検索する（ステップ７３２）。この検索は、例えばＤＰ（Dynamic Programming）マッチングのような、公知の手法によって行うことができる。
【００８０】
例えば、文字切り出し・識別仮説ネット７４１には文字列「三度邊」が含まれるが、この文字列はデータ文字列パターン辞書７０２に登録されていないため、検索結果としては取得されない。一方、文字列「渡邊」はデータ文字列パターン辞書７０２に登録されているため、検索結果として取得される可能性がある。窓口受付システム１０は、文字切り出し・識別仮説ネット７４１のエッジに与えられたスコアと、データ文字列パターン辞書７０２のエッジに与えられたスコアとに基づいて、文字列「渡邊太朗」が最も尤もらしいと判定した場合、この文字列を手書き文字の認識結果として出力する（ステップ７３３）。このとき、手書き文字列の認識結果と活字文字列の認識結果とが一致するか否かを示す情報を出力してもよい。
【００８１】
このように、図７に示した方法によれば、予め用意されたデータ文字列パターン辞書に、活字文字の認識結果から作成された辞書情報が追加され、その辞書が文字認識に使用される。活字文字の認識結果として得られた文字列がデータ文字列パターン辞書に登録されていなかった場合には、その文字列を新たに登録することによって、入力された手書き文字列が活字文字列と同一の文字列として認識されやすくなる。一方、活字文字の認識結果として得られた文字列がデータ文字列パターン辞書に既に登録されていた場合には、その文字列に対応するスコアを増加させることによって、入力された手書き文字列が活字文字列と同一の文字列として認識されやすくなる。このように、手書き文字の認識精度が向上するため、本人確認に失敗する頻度も減少し、これによって窓口業務の効率が改善するとともに、窓口オペレータによる不正な処理も防止される。
【００８２】
上記の例では、予め用意されたデータ文字列パターン辞書１６６に、活字文字の認識結果に基づく情報が追加されたが、データ文字列パターン辞書１６６が予め用意されていない場合にも、手書き文字の認識を活字文字の認識と連携して行うことによって、手書き文字の認識精度を改善することができる。以下、これについて説明する。
【００８３】
図８は、本発明の実施形態の窓口受付システム１０が実行する、データ文字列パターン辞書を予め保持しない場合の手書き文字認識処理のフローチャートである。
【００８４】
ここでは、例として、手書き文字列及び活字文字列として「桜井太郎」が入力された場合について説明する。
【００８５】
窓口受付システム１０に入力される入力画像８０１は、申請書８０２及び本人確認書類８０３の画像データを含む。申請書８０２は手書きされた氏名の文字列「桜井太郎」を含み、本人確認書類８０３は活字の文字列「桜井太郎」を含む。これらはそれぞれ図２の申請書２１１及び運転免許証２１２に相当する。
【００８６】
図８では省略されているが、窓口受付システム１０は、図４のステップ４０５と同様の方法によって、氏名の手書き文字列が記載された項目領域を抽出する。そして、窓口受付システム１０は、抽出された項目領域に記載された手書き文字列「桜井太郎」について、図７と同様の方法によって文字切り出し・識別仮説ネット８１１を作成する。図８では、例えば、文字列「桜井」のほかに文字列「木女井」等が、手書き文字の認識結果の候補として抽出される。
【００８７】
一方、窓口受付システム１０は、図４のステップ４０２と同様の方法によって、氏名の活字文字列が記載された項目領域を抽出する。そして、窓口受付システム１０は、図４のステップ４０３と同様の方法によって、抽出された項目領域に記載された活字文字列の認識を実行し、その結果として、活字文字列から得られた認識候補の文字列「桜井太郎」８１２を取得する。図８の例では窓口受付システム１０がデータ文字列パターン辞書１６６を予め保持していないため、ここで取得された文字列「桜井太郎」８１２が、次のステップにおいてデータ文字列パターン辞書１６６として参照される。
【００８８】
なお、上記の二つのステップが実行される順序は任意であり、両者が並行して実行されてもよい。
【００８９】
次に、窓口受付システム１０は、活字文字列の認識結果を用いて、文字切り出し・識別仮説ネットを検索する（ステップ８１３）。図８の例では、活字文字列の認識結果「桜井太郎」に対応するパスが文字切り出し・識別仮説ネット８１１に存在し、文字切り出し・識別仮説ネットから抽出された文字列のスコアの合計値が所定の値より大きい場合に、窓口受付システム１０は、「桜井太郎」を手書き文字の認識結果として出力する（ステップ８１４）。このとき、手書き文字列の認識結果と活字文字列の認識結果とが一致するか否かを示す情報を出力してもよい。一方、活字文字列の認識結果に相当するパスが文字切り出し・識別仮説ネットに存在しない場合、窓口受付システム１０は、手書き文字の認識に失敗したことを示す情報を出力してもよい。
【００９０】
上記の検索は、図７におけるステップ７３２と同様に実行される。例えば、活字文字列から抽出された「桜井太郎」に対応するパスに含まれる各エッジに０より大きいスコアが与えられ、文字切り出し・識別仮説ネットから抽出された文字列のスコアの合計値が所定の値より大きい場合にその文字列（例えば「桜井太郎」）を認識結果として出力してもよい。
【００９１】
なお、上記の文字切り出し・識別仮説ネット８１１の作成及びステップ８１３は、図４のステップ４０６に相当し、認識候補の文字列８１２の取得及びそれに対応するエッジのコストの決定は、図４のステップ４０４に相当する。
【００９２】
このように、活字文字の認識結果を用いることによって、予め用意された辞書を用いずに手書き文字の認識精度を改善することができる。
【００９３】
なお、図８を参照して説明した文字認識は、図７の処理において、活字文字認識の結果として得られた文字列（図７の例では「渡邊太朗」）に対応するパスに含まれるエッジ以外の全てのエッジのスコアを０にすることと等価である。言い換えると、図８の例では、活字文字の認識結果のみをデータ文字列パターン辞書として用いて手書き文字認識が実行されるのに対して、図７の例では、活字文字の認識結果と、予め用意された辞書とを組み合わせた情報をデータ文字列パターン辞書として用いて手書き文字認識が実行される。
【００９４】
ここまでに示した例では、本人確認の際に、入力された手書き文字列と活字文字列とが同一であることが求められる。しかし、実際には、完全な同一性が求められない場合もある。その典型的な例は、漢字の異体字による表記ゆれを許容する場合である。
【００９５】
本人確認書類に記載される漢字は、その書類を作成したシステムにおいて使用可能なものに限られる。このため、氏名の漢字が当該システムにおいて使用できないもの（いわゆる外字）である場合には、氏名の漢字がそれに対応する異体字で置き換えられて本人確認書類に表示され、その結果、実際の氏名の漢字と本人確認書類に記載された漢字とが異なることになる。
【００９６】
このような表記ゆれは、異体字が略字として慣用される場合にも発生する。例えば、本来の表記が「渡邊」であるのに、それを筆記するときには略字として「渡辺」を使用する場合などがこれに該当する。システムのポリシーによっては、このような表記ゆれを許容し、本人確認の際に文字列の完全同一を求めない場合もあり得る。
【００９７】
完全な同一性が求められない場合の別の例は、手書き文字列と活字文字列の文字種類が異なる場合である。例えば、本人確認書類としてパスポートが使用され、申請書には漢字を手書きする場合、手書きされた漢字の文字列と、パスポートに印刷されたローマ字の文字列とが照合される。この場合、表記された文字そのものが一致することは要求されないが、漢字の読みとローマ字の読みが一致することは要求される。
【００９８】
上記のような場合、外字・ローマ字辞書１６３が文字認識に使用される。以下、このような場合の文字認識について説明する。
【００９９】
図９は、本発明の実施形態の窓口受付システム１０が実行する、データ文字列パターン辞書を予め保持しない場合の手書き文字認識処理の別の例を示すフローチャートである。
【０１００】
ここでは、図８と同様にデータ文字列パターン辞書１６６が予め用意されていない場合において、本人確認書類には図８と同様に活字文字列「桜井太郎」が記載されているが、申請書には手書き文字列「櫻井太郎」が記載されている例を示す。「桜」と「櫻」は、相互に置き換えて慣用される異体字である。以下、図９に示す処理のうち、図８と同様の部分については詳細な説明を省略する。
【０１０１】
図９に示す入力画像９０１は、申請書９０２及び本人確認書類９０３の画像データを含む。申請書９０２は手書きされた氏名の文字列「櫻井太郎」を含み、本人確認書類９０３は図８の例と同様に活字の文字列「桜井太郎」を含む。これらはそれぞれ図２の申請書２１１及び運転免許証２１２に相当する。
【０１０２】
窓口受付システム１０は、手書き文字列「櫻井太郎」について、図８と同様の方法によって文字切り出し・識別仮説ネット９１１を作成する。図９では、例えば、文字列「櫻井」のほかに文字列「木女井」等が抽出される。
【０１０３】
さらに、窓口受付システム１０は、認識候補の文字列「桜井太郎」９１２を取得する。これは、図８の例における認識候補の文字列８１２の取得と同様である。
【０１０４】
次に、窓口受付システム１０は、取得された認識候補の文字列９１２を対象として、外字・ローマ字辞書１６３に基づいて、外字による展開を実行する（ステップ９２１）。外字・ローマ字辞書１６３には、同一であると判定することが許容される（言い換えると、置換することが許容される）複数の文字又は複数の文字列を相互に対応付ける情報が含まれる。例えば、「桜」と「櫻」とが同一であると判定することが許容される場合、外字・ローマ字辞書１６３は、「桜」と「櫻」と対応付ける情報を含む。その結果、認識候補の文字列として、「桜井太郎」の「桜」を、それに対応付けられた文字「櫻」によって置き換えた文字列「櫻井太郎」が追加される。
【０１０５】
そして、窓口受付システム１０は、展開された活字文字列の認識結果の文字列９２２を用いて、文字切り出し・識別仮説ネット９１１を検索する（ステップ９１３）。図９の例では、認識結果の文字列９２２に文字列「桜井太郎」及び「櫻井太郎」が含まれるが、これらのうち「櫻井太郎」に対応するパスが文字切り出し・識別仮説ネット９１１に存在するため、窓口受付システム１０は、「櫻井太郎」を手書き文字の認識結果として出力する（ステップ９１４）。このとき、手書き文字列の認識結果と活字文字列の認識結果とが一致するか否かを示す情報を出力してもよい。
【０１０６】
一方、活字文字列の認識結果の文字列９２２に含まれるいずれの文字列に相当するパスも文字切り出し・識別仮説ネットに存在しない場合、窓口受付システム１０は、手書き文字の認識に失敗したことを示す情報を出力してもよい。
【０１０７】
申請書に手書き文字が記載され、本人確認書類にローマ字等が記載された場合も、上記と同様の処理が行われる。これについて、本人確認書類９０３がパスポートである場合を例として説明する。
【０１０８】
この例において、本人確認書類９０３には、氏名として活字文字列「Ｓａｋｕｒａｉ  Ｔａｒｏ」（図示省略）が記載され、外字・ローマ字辞書１６３に文字列「Ｓａｋｕｒａｉ  Ｔａｒｏ」と「櫻井太郎」とを対応付ける情報が含まれる。この場合、ステップ９２１の結果、文字列「Ｓａｋｕｒａｉ  Ｔａｒｏ」（図示省略）と「櫻井太郎」とを含む活字文字列の認識結果の文字列９２２が取得される。窓口受付システム１０は、上記と同様に、文字列９２２に含まれる「櫻井太郎」を用いて文字切り出し・識別仮説ネット９１１を検索し、「櫻井太郎」を手書き文字の認識結果として出力する（ステップ９１４）。
【０１０９】
このような外字・ローマ字辞書１６３を用いた展開は、図７に示す処理に適用することもできる。
【０１１０】
例えば、図７の例において、本人確認書類に氏名の活字文字列として「渡辺太朗」が記載され、外字・ローマ字辞書１６３に文字「辺」と「邊」とを対応付ける情報が含まれる場合、窓口受付システム１０は、文字列「渡辺太朗」及びその「辺」を「邊」によって置き換えた文字列「渡邊太朗」とをデータ文字列パターン辞書７０１に追加する。「渡邊太朗」の追加は図７を参照して既に説明した通りである。一方、「渡辺太朗」は既にデータ文字列パターン辞書７０１に登録されているため、窓口受付システム１０は、「渡辺太朗」に対応するパスに含まれるエッジのスコアを増加させる。「渡辺太朗」がデータ文字列パターン辞書７０１に登録されていない場合には、「渡邊太朗」と同様にデータ文字列パターン辞書７０１に追加される。
【０１１１】
上記のように外字・ローマ字辞書１６３を使用することによって、文字の表記ゆれ又は文字種類の相違に起因する本人確認の失敗を防止することができる。なお、上記のような漢字の異体字及びローマ字による置換は一例であり、それ以外の文字による置換が許容される場合にも、外字・ローマ字辞書１６３と同様の辞書（すなわち相互に置換可能な文字又は文字列を対応付ける情報）を用いて、上記と同様の処理を実行することができる。
【０１１２】
なお、本実施形態は官庁又は企業における窓口業務を例として説明したが、本発明は、手書き文字とそれに対応する活字文字とが入力される業務であれば、窓口業務以外の業務に適用することもできる。
【符号の説明】
【０１１３】
１０  窓口受付システム
１１、１１０  入力装置
１１１  画像入力装置
１２  表示装置
１３  ＣＰＵ
１４  印刷装置
１５  ワークエリア
１５１  ＯＳ
１５２  通信プログラム
１５３  文書処理プログラム
１５４  文字認識プログラム
１６  情報保持手段
１６１  活字文字認識用辞書
１６２  手書き文字認識用辞書
１６３  外字・ローマ字辞書
１６４  配置知識辞書
１６５  項目名辞書
１６６  データ文字列パターン辞書
１９  通信ネットワーク
２１  ファイルサーバ
【図１】
0005669041.tif 000002
【図２】
0005669041.tif 000003
【図３】
0005669041.tif 000004
【図４】
0005669041.tif 000005
【図５】
0005669041.tif 000006
【図６】
0005669041.tif 000007
【図７】
0005669041.tif 000008
【図８】
0005669041.tif 000009
【図９】
0005669041.tif 000010