JP4996940B2 - 帳票認識装置およびそのプログラム - Google Patents

Description

本発明は，帳票画像の処理技術に係り，特に帳票上の記載情報の属性の理解と文字認識の技術に関する。

従来の帳票ＯＣＲ（Optical Character Reader）における帳票認識方式では，あらかじめ読取り位置が決められている定型帳票を認識対象としているものが多かった。このような帳票に対する従来技術として，「フォーマットジェネレータ」がある（例えば、非特許文献１参照）。この技術では，読取り対象の文字の記入位置を0.1mm単位で厳密に指定している。既存のＯＣＲには，フォーマットジェネレータと同様の書式情報を採用している機種が多い。

一方，給与支払報告書やレセプトのように，同じ種類の帳票でも１枚ごとに罫線の本数や枠の位置や大きさなどが微妙に異なる帳票に対しては，上記の方式では認識できない。このような帳票に対しては，例えば特許文献1に示すように，枠の位置やサイズは異なるものの，項目間の配置関係がほぼ一定であることを利用し，あらかじめ登録された枠構造と帳票画像から解析した枠構造とを照合することにより，読取り領域を特定する方式がある（特許文献１）。

より自由度が高い帳票としては登記済通知書などがある。この種の帳票は，同じ種類の帳票であれば項目名はほぼ同じであるものの，一枚ごとに帳票の枠の大きさや数が異なる。場合によっては，項目間の配置も異なる場合がある。このような帳票に対して，まず表構造を解析し，枠内の文字を認識して項目名が記載されている枠を検出し，その右や下の枠が読取り対象のデータ領域であると判断して認識するという方式がある（特許文献２）。特許文献２の方式では，項目名の文字列と，項目名枠とデータ枠の対応付けをあらかじめ定義しておく必要がある。

さらに，項目名の文字列からデータを検出する従来手法としては，特許文献３がある。特許文献3の方式では，「入荷−個数」，「入荷−金額」，「出荷−個数」「出荷−金額」など，階層関係がある項目をもつデータや，2次元の表構造のデータを対象としている。この方式では，項目名間の配置関係などをあらかじめ定義しておくことにより認識を可能にしている。

特開２００４−１３９４８４号公報 特開平９−３１９８２４号公報 特開２００５−２７５８３０号公報 「日立ＯＣＲソリューションＩｍａｇｉｎｇ ＯＣＲ」カタログ、株式会社日立製作所、２００５年１２月版、Ｐ５〜６

上述の認識対象としての帳票の特徴を纏めると次のようになる。
（１）「氏名」と「名前」のように，同じ属性であるにもかかわらず，属性を表す項目名の文字列が帳票ごとに異なる。
（２）階層関係や2次元関係も含めて，項目名の文字列とデータの文字列との位置関係が不明である。
（３）一つの枠内に複数の属性のデータが記載されている。
（４）項目名とデータの文字列が枠で囲まれていない。
（５）複数の項目のデータが一組（レコード）となっており，それらのデータが繰返し記載されている。
（６）データが記載されている領域内に，読取りに不必要な別の文字列が含まれている。例えば，金額欄に「円」の文字が記載されている場合である。

このような帳票に対して非特許文献１の方式で対応する場合，全ての帳票の書式情報を作成した上で，入力された帳票ごとにどの書式情報を適用するかを識別しなければならない。数百〜数千種の帳票を扱うような状況では，書式情報作成のコストと識別の精度の観点から，この方式を適用することは現実的ではない。

また，特許文献１の方式についても，項目(属性)間の配置が同じであることが前提条件となっているので，上記のような非定型帳票には適用できない。

特許文献２の方式は，非定型帳票の一部に対応可能であるものの，属性を表す項目名枠とデータ枠の位置関係と，項目名の文字列をあらかじめ定義しておく必要があるため，上記（１）〜（６）の課題に対応できない。

特許文献３の方式は，項目名の階層関係や2次元関係を解析できるという特長があるものの，特許文献２と同様に上記（１）〜（６）の課題に対応できない。さらに，階層関係や2次元表の関係はあらかじめ定義しておかなければならないため，例えば2次元表の行と列が入れ替わった場合などには対応できない。

さらに，従来手法では枠同士の配置関係に基づいてデータの項目名を認識しているため，上記（３）や（４）の記載形式を持つ帳票を認識することはできない。

本発明の目的は，同じ種類の帳票にもかかわらず，枠の大きさや位置および項目の順序などの書式が異なる帳票に対して，帳票ごとに読取り項目の位置を定義することなくデータを認識するため，データの属性を自動的に解析することが可能な帳票認識装置、及びそのプログラムを提供することにある。

上記の目的を達成するため，本発明においては，認識辞書及び項目名単語辞書を記憶する記憶部と，帳票画像の認識処理を行う処理部とからなる帳票認識装置であって，処理部は，帳票画像中の文字列が含まれる領域を検出し，検出された領域内の文字列を検出し，検出された文字列の文字を，認識辞書を用いて認識し，文字列の文字認識結果と項目名単語辞書中の項目名単語とを照合し，項目名単語照合に成功した文字列を項目名が記載された文字列（以下，項目名文字列と表記）と，項目名単語照合に成功しなかった文字列をデータが記載された文字列（以下，データ文字列と表記）と判定し，この項目名文字列とデータ文字列との配置関係からデータと項目名を対応付けし，データ文字列の属性を判定する構成とする。

すなわち，帳票画像中の文字を認識する帳票認識用プログラムであって，帳票認識装置の処理部において，帳票画像の中で文字列が含まれる領域を検出するステップと，領域内の文字列を検出するステップと，検出された文字列の文字を認識するステップと，文字列の文字認識結果と項目名単語とを照合するステップと，項目名単語照合に成功した文字列を項目名文字列と判定するステップと，項目名単語照合に成功しなかった文字列をデータ文字列と判定するステップと，この項目名文字列とデータ文字列との配置関係からデータと項目名を対応付けし，項目名に相当する属性を判定するステップを実行する構成としたものである。

類似しているが書式が異なる帳票に対して，厳密な定義なしで認識することができる。項目名の文字列を登録するだけで，帳票内のデータの属性を解析しながら認識することができる。

以下，図に示す実施例により本発明をさらに詳細に説明する。なお，これにより本発明が限定されるものではない。具体的な処理の内容を説明する前に，本発明の概略について説明する。

本発明においては，書式の自由度が高い帳票において，データの記載位置の事前定義なしにデータの文字列を認識することである。このために，記載されたデータの属性を自動的に理解することが必要であり、本実施例では，データの記載位置ではなく，データの属性を表す項目名の単語を事前に辞書登録しておく。この辞書の項目名単語と帳票内の文字列とを照合することにより，項目名文字列を検出する。一方，項目名の単語辞書と照合できなかった文字列はデータ文字列であるとみなす。さらに，項目名文字列とデータ文字列との配置関係を解析することにより，データ文字列と項目名文字列との対応関係を認識する。対応付けられた項目名の属性が，データ文字列の属性である。

具体的には，下記の順序により，項目名文字列同士，および項目名文字列とデータ文字列との配置関係を解析して，データ文字列の属性を認識する。

（１）従来の方式は枠を基準と考えており，項目名が記載された枠とデータが記載された枠との配置関係を解析している。これに対し，本方式では文字列を基準として処理を行う。具体的には，項目名文字列とデータ文字列との配置関係を解析することにより，同一枠内に複数の項目が記載されている場合や，枠がない場合にも対応できる。

（２）抽出された文字列を認識し項目名の単語と照合する。照合に成功した文字列は項目名の文字列とし，照合に失敗した文字列はデータの文字列であると判定する。判定された項目名文字列とデータ文字列との配置関係を解析することにより，データ文字列の属性を認識する。

（３）従来の方式では，項目名とデータの配置関係や，項目名の階層関係，および項目名の2次元関係を定義していたのに対し，本方式では（２）に示したように項目名の単語のみから階層関係や2次元関係も含めたデータの属性を認識する。

（４）複数の項目名とデータの組の並びから，一纏りとなっているデータの組（レコード）を検出する。
これらの処理の一部もしくは全てを実行することにより，本発明では、認識率の高い帳票認識を実現できる。

図２は，本発明の第一の実施例である帳票認識装置のハードウェア構成の一例である。図１において，１０はコマンドやコードデータなどを入力するための入力部である入力装置，２０は処理対象の帳票画像を入力するための画像入力部である画像入力装置，３０は文字列の検出や文字の認識およびデータ文字列の属性付けを行う帳票認識部，４０は本実施例における帳票認識用の辞書であり，文字認識辞書や項目名単語辞書を格納する，５０は認識結果を表示する表示部である表示装置である。なお，２０の画像入力装置の代わりに６０の画像データベース（ＤＢ）から帳票画像を入力してもよい。認識辞書４０と画像ＤＢ６０は、図示されない記憶部に記憶されている。

なお，帳票認識部３０は通常，中央処理部（Central Processing Unit，ＣＰＵ）で構成され，この帳票認識部としてのＣＰＵ３０が，以下で詳述する本実施例の帳票認識プログラムの処理を実行することになる。なお，ＣＰＵが実行する帳票認識プログラムは，通常，図示されていない記憶部に記憶されているが，可搬型記憶媒体やネットワークなどを介して外部から記憶部に導入して記憶することも可能であることは言うまでもない。

以下，第一の実施例における処理の詳細について図を用いて説明する。図１は，第一の実施例の帳票処理装置３０による帳票処理の概略を示すフロー図である。この処理は先に述べたように，通常はＣＰＵにおけるプログラム処理として実行される。以下同様である。

まず，ステップ１１０において，入力された帳票画像から文字列が含まれる領域を検出する。以下，この領域を文字列領域と定義する。この文字列領域は，表形式の帳票の場合は個々の枠（セル）に相当する。表形式でない帳票や表外の文字列の場合には，文字列そのもの，もしくは文字列を分けるための空白を仮想的に罫線とみなして構成される枠に相当する。

次に，ステップ１２０において，各文字列領域内の文字列を検出する。ステップ１１０と１２０の具体例としては，例えば、特開平１１−５３４６６号公報に詳述されている方式を利用することが可能である。行抽出の一実施例については，領域内の隣接する連結成分（黒画素が連続している塊）を横方向もしくは縦方向に統合していくことにより，横方向の文字行もしくは縦方向の文字行を抽出することが可能である。

ステップ１３０では，文字認識辞書１８０を利用して、文字列内の個々の文字を認識する。
ステップ１４０では，ステップ１３０の文字認識結果と項目名単語辞書１８０に登録されている項目名の単語とを照合する。１３０と１４０の処理の一実施例としては，例えば、特開２００４−１７１３１６号公報記載の方式を利用することが可能である。

ステップ１５０では，ステップ１４０にて単語照合が成功した文字列を項目名文字列と判定する。
ステップ１６０では，ステップ１４０にて単語照合に失敗した文字列をデータ文字列と判定する。単語照合に失敗したため，文字認識結果はステップ１３０の結果をそのまま利用する。ただし，文字認識の誤りなどによる単語照合の失敗の可能性もあるため，データ文字列の候補と判定し，データ文字列か否かは後段の処理に基づいて判定してもよい。

ステップ１７０では，項目名文字列とデータ文字列との配置関係から，各文字列の属性を判定する。属性認識の詳細については，項目名とデータの配置関係ごとに，図６から図１２を用いて詳細に説明する。

図３と図４は同じ種類にもかかわらず，枠の大きさや項目名等の書式が異なる帳票の例である。図３の帳票には，項目名として「銀行名」，「支店名」，「口座番号」，「氏名」，「金額」が記載されている。図４の帳票には，項目名として「銀行」，「支店」，「口座No.」，「名前」，「金額」が記載されている。

図５は，図３と図４の帳票に対応した項目名単語辞書１９０に格納されているデータの例である。記載文字が異なる項目名単語が登録されており，同じ属性の項目名単語には同じ属性IDが付与されている。例えば，「銀行名」と「銀行」は属性IDが「１」となっている。登録する項目名単語は，処理対象の帳票を観察して，同じ属性で異なる表記の単語を選択する。なお，本実施例では項目名として記載された文字列全てを登録したが，項目名の一部だけを登録してもよい。これは登録する単語数を削減する効果がある。例えば，「銀行」だけを登録することにより，「銀行名」を登録しなくても単語照合が成功する。また，属性IDについては番号で記載したが，文字列でもよい。

以下，図６から図１２を用いて，図１のステップ１７０の文字列属性解析について説明する。まず，ステップ１７０の概略の処理フローを図６に，図６内の詳細の処理フローを図７と図８を用いて説明する。

図６は図１のステップ１７０の文字列属性解析の処理フローを説明する図である。まず，ステップ６００の項目名文字列間階層関係解析を行う。これは，図１のステップ１５０にて単語照合の結果検出された項目名文字列のみを対象とする。これらの文字列間の配置関係を解析して項目名文字列間の階層関係を解析する。この処理の詳細については，図７のフロー図と図８の枠配置例にて説明する。

ステップ６１０の縦方向項目名−データ関係解析は，項目名文字列の下側にデータ文字列が存在する場合に，項目名文字列とデータ文字列の関係を解析し，データ文字列の属性を検出する処理である。この処理の詳細については，図９のフロー図と図１０の枠配置例にて説明する。

ステップ６２０の横方向項目名−データ関係解析は，項目名文字列の右側にデータ文字列が存在する場合に，項目名文字列とデータ文字列の関係を解析し，データ文字列の属性を検出する処理である。この処理はステップ６１０の処理を横方向に変更して実現できる。

ステップ６３０の繰返し関係解析は，縦方向や横方向に同じ属性のデータ文字列が並んでいる場合に，データの繰返し構造を解析する処理である。この処理の詳細については，図１１を用いて説明する。

なお，図６にはステップ６００，６１０，６２０，６３０の４種類の解析処理を記載しているが，用途に応じて一部の処理を省略してもよい。また，後で図１３や図１４を用いて説明する処理等を追加してもよい。

図７は，図６のステップ６００の項目名文字列間階層関係解析の処理フローを説明する図である。まず，ステップ７００において，項目名文字列領域を一つずつ解析対象とする。次に，ステップ７１０において，項目名文字列領域の下側に別の項目名文字列領域が存在するか否かを判定する。存在する場合には，ステップ７００における判定対象の項目名文字列領域の左右端と，項目名文字列領域の下側の項目名文字列領域の左右端とが一致するか否かをステップ７２０にて判定する。一致する場合には，ステップ７３０において，下側の項目名文字列領域の高さが等しいか否かを判定する。ステップ７２０と７３０の処理については，図８を用いて具体的に後述する。高さが等しければ，ステップ７４０において，上側の項目名文字列領域を上位階層に，下側の項目名文字列領域を下位階層として属性の階層関係を設定する。これらの処理が終了するか，ステップ７１０から７３０の判定を満足しない場合は，ステップ７５０にて次の項目名文字列領域に処理対象を移動し，ステップ７００へ戻る。

図８は，図７のステップ７２０と７３０において，上下の項目文字列領域に階層関係があると判定される例である。ステップ７００と７１０において，項目名文字列１を含む枠を処理対象の項目文字列領域（８００）とする。ステップ７２０と７３０において，項目名文字列２１を含む枠と項目名文字列２２を含む枠の２つが，下側の判定対象の項目名文字行領域（８１０，８２０）とすると，上側の項目名文字列領域８１０の左端と，下側の項目名文字列領域８１０の左端が一致しており，同様に項目名文字列領域８１０と項目名文字列領域８２０の右端とも一致しており，ステップ７２０の条件を満たしている。さらに，下側の２つの項目名文字列領域８１０と８２０の枠の高さが一致しており，ステップ７３０の条件を満たしている。したがって，項目名文字列１の下位階層の項目が，項目名文字列２１と項目名文字列２２と判定できる。

図９は，図６のステップ６１０の縦方向項目名−データ関係解析の処理フローを説明する図である。まず，ステップ９００において，項目名文字列領域を一つずつ解析対象とする。次に，ステップ９１０において，項目名文字列領域の下側にデータ文字列領域が存在するか否かを判定する。存在する場合には，ステップ９００における判定対象の項目名文字列領域の左右端と，下側のデータ文字列領域の左右端とが一致するか否かをステップ９２０にて判定する。ステップ９２０の処理については，図１０を用いて具体的に後述する。ステップ９２０の条件を満たす場合には，ステップ９３０において，下側のデータ文字列領域内の文字列の属性は，上側の項目名文字列領域の文字列の属性であると判断する。これらの処理が終了するか，ステップ９１０と９２０の判定を満足しない場合は，ステップ９４０にて次の項目名文字列領域に処理対象を移動し，ステップ９００へ戻る。なお，図６のステップ６２０の横方向項目名−データ関係解析については，この処理の解析方向を横方向に変更して実現できる。

図１０は，図９のステップ９２０において，上下の文字列領域に項目名−データの関係があると判定される例である。図１０(a)の例は，項目名枠の直下にデータ枠が存在する場合である。項目名文字列を含む枠を処理対象の項目文字列領域（１０００）とし，ステップ９２０おいてデータ文字列を含む枠１０１０をデータ文字行領域とすると，上側の項目名文字列領域１０００の左端と，下側のデータ文字列領域１０１０の両端が一致している。したがって，１０１０内の文字列の属性は，１０００内の文字列の属性と判定できる。図３の例では，データ「AAA」の属性が銀行名（図５の属性IDが「1」）と判定できる。

図１０(b)の例は，項目名枠の直下に複数のデータ枠が存在する場合である。項目名文字列を含む枠を処理対象の項目文字列領域（１０２０）とし，ステップ９２０においてデータ文字列１，２，３を含む枠を処理対象のデータ文字列領域（１０３０，１０４０，１０５０）とすると，上側の項目名文字列領域１０２０の左端と，下側のデータ文字列領域１０３０の左端が一致しており，同様に項目名文字列領域１０２０とデータ文字列領域１０５０の右端とも一致しており，ステップ９２０の条件を満たしている。さらに，１０３０，１０４０，１０５０は隣接しており，枠の高さが一致しているという判定条件を加えてもよい。この結果，１０３０，１０４０，１０５０内の文字列の属性は，１０２０内の文字列の属性と判断できる。図４の例では，「（空白）」と「５」，「０００」の３個の枠内のデータの属性が金額（図５の属性IDが「５」）と判定できる。

図１１は，図６のステップ６３０の繰返し構造解析を説明するための図である。図１１において，図９の処理により，項目名文字列１を含む枠である項目名文字列領域（１１００）と，データ文字列１１を含む枠であるデータ文字列領域（１１１０）との配置関係を解析することにより，データ文字列１１の属性は項目名文字列１の属性であると判定できる。さらに，データ文字列領域１１１０の下側に同じ幅のデータ文字列領域１１２０が存在する場合，１１２０内のデータ文字列１２の属性も項目名文字列１の属性であると判定する。上記の処理を項目名文字列２と３についても実行し，それぞれの項目でのデータ文字列領域の繰返し関係を求める。さらに，データ文字列１１，データ文字列２１，データ文字列３１を含む各データ文字列領域は，高さが同じで隣接しているか否かの判定を行う。図１１では判定を満たすため，これらのデータを一組（１レコード）と判定する。データ文字列１２，データ文字列２２，データ文字列３２についても同様に，一組と判定する。

図１２は，図３の帳票に対して図５の項目名単語辞書を用いて図１の処理を実行した結果の例である。データ「AAA」の属性は上側に存在している「銀行名」であり，その属性IDは「１」である。横方向の属性は存在しない。また，「AAA」，「aaa」，「00000000」，「○○○」，「2000」の５個のデータは一組と判定されてレコード番号「１」と判定されている。同様に，銀行名「BBB」の行のデータはレコード番号「２」と認識されている。また，図３の最下行のデータ「12000」は，縦方向と横方向の「項目名−データ関係解析」（６１０，６２０）を実行することにより，縦方向の属性が「金額」で横方向の属性が「合計」の２次元関係であることがわかる。なお，項目名に階層関係がある場合には，階層情報も付加して出力してもよい。このように，各データの属性を認識することにより，書式が異なる帳票であっても，属性に基づいた同一のデータベースに認識結果を格納することができる。

なお，図１２のデータ欄は，データの文字認識結果だけでなく，文字列座標や文字列の部分画像としてもよい。これは，文字認識ではデータを全て正しく認識することができないため，データの入力にはOCRを用いずデータが記載された領域の属性のみを認識するという利用形式である。この場合，データの入力は人間がパンチ入力を行うなどの作業に利用することができる。

図１３は，図１のステップ１７０の文字列属性解析において，同じ枠内に複数の項目が存在する場合の解析の例である。図６のフローにこの処理を追加してもよい。特許文献３などの従来の項目名とデータの対応付け方法では，枠を属性付けの基本単位としているため，図４の「銀行」「支店」のように同一枠内に複数の項目が含まれている場合には，各データ文字列の属性付けができない。本方式では，図６のステップ６１０やステップ６２０の解析の結果，項目名文字列領域内に複数の項目名文字列が存在し，データ文字列領域内にも複数のデータ文字列が存在する場合には，個々のデータ文字列に対応した別々の属性を割り当てる。図１３の場合，「データ文字列１」の属性は「項目名文字列１」の属性となり，「データ文字列２」の属性は「項目名文字列２」の属性となる。対応付けの基準は，枠内の相対位置を用いることができる。図１３の例では，枠内の上にある文字列同士，下にある文字列同士を対応付けする。この配置関係については，左右の配置や，枠内の何行目かなどの判断基準を利用することも可能である。

図１４は，図１のステップ１７０の文字列属性解析において，同じ枠内に項目名文字列とデータ文字列の両方が存在する場合の解析の例である。図６のフローにこの処理を追加してもよい。特許文献３などの従来の項目名とデータの対応付け方法では，枠を属性付けの基本単位としているため，この例でもデータの属性付けができない。この場合，項目名文字列を含む枠と隣接したデータ文字列領域が存在せず，同一枠内にデータ文字列が存在する場合には，項目名文字列とデータ文字列の対応付けをする。また，同一枠内だけでなく，枠外の複数の文字列間にもこの対応付けをすることができる。

さらに，同一文字列内の一部のみが項目名単語との照合に成功した場合に，文字列を照合に成功した部分とそれ以外に分割し，上記の対応付けをすることもできる。

図１５は，第一の実施例の認識結果の表示の一実施例である。この例では，オペレータに見せたくない属性のデータを非表示にしている。図１５は図３の帳票において氏名欄のデータを非表示にしている例である。この機能により，パンチ入力や認識結果の確認をするオペレータは，個人情報を見ることなく，必要なデータのみを見ることが可能になる。

図１６は，第一の実施例の認識結果の表示の一実施例である。この例では，特定の属性のデータのみを一覧表示した例である。図１６は，帳票１は図３の帳票を帳票２は図４の帳票を対象にして，銀行名の属性のデータのみを表示している例である。なお，データの表示は認識結果でも，その文字列の部分画像でもよい。また，この例では複数の帳票のデータを一覧表示しているが，１枚の帳票のデータのみを表示してもよい。また，複数の属性のデータを表示してもよい。

図１７は，他の実施例であるプレ印刷文字認識方法を説明する図である。本実施例では，図１の項目名単語辞書１９０に，「円」等のプレ印刷文字も登録しておく。ステップ１４０の項目名文字列照合にてプレ印刷単語と照合が成功した場合には，ステップ１５０にてこの文字列はプレ印刷と判定する。その結果，ステップ１７０の文字列属性解析において，「円」の文字列は金額の属性を持つプレ印刷であると判定できる。この処理により，プレ印刷文字をデータであると誤認識することがなくなるという効果がある。

第一の実施例における帳票認識処理のフローを示す図。 第一の実施例に関わる帳票認識装置の概略構成を示すブロック図。 第一の実施例における処理対象帳票の一例を示す図。 第一の実施例における処理対象帳票の一例を示す図。 第一の実施例における項目名単語辞書の一例を示す図。 第一の実施例の文字列属性解析処理フローの一例を示す図。 第一の実施例の図６の項目名文字列間階層関係解析処理フローの一例を示す図。 第一の実施例における項目名文字列間階層関係解析処理の対象の例を示す図。 第一の実施例の図６の縦方向項目名−データ関係解析処理フローの一例を示す図。 第一の実施例における縦方向項目名−データ関係解析処理の対象の例を示す図。 第一の実施例における繰返し関係解析処理の対象の例を示す図。 第一の実施例における図３と図４の帳票の認識結果の一例を示す図。 同一枠内に複数の項目が記載されている一例を示す図。 同一枠内に項目名の文字列とデータの文字列が両方とも記載されている例を示す図。 第一の実施例における特定項目を非表示にする例を示す図。 第一の実施例における特定属性のデータのみを一覧表示にする例を示す図。 他の実施例における同一枠内にプレ印刷の文字列とデータの文字列が両方とも記載されている例を示す図。

符号の説明

１０…入力装置，２０…画像入力装置，３０…帳票認識部（ＣＰＵ），４０…認識辞書，５０…表示装置，６０…画像ＤＢ，１８０…文字認識辞書，１９０…項目名単語辞書，８００，８１０，８２０，１０００，１０２０，１１００…項目名文字列，１０１０，１１１０，１１２０…データ文字列。

Claims (7)

1. 認識辞書及び項目名単語辞書を記憶する記憶部と，帳票画像の認識処理を行う処理部とからなる帳票認識装置であって，
   前記処理部は，
   前記帳票画像中の，文字列が含まれる領域を検出し，
   検出された前記領域内の文字列を検出し，
   検出された前記文字列の文字を、前記認識辞書を用いて認識し，
   前記文字列の文字認識結果と前記項目名単語辞書中の項目名単語とを照合し，
   項目名単語照合に成功した前記文字列を項目名文字列と，項目名単語照合に成功しなかった文字列をデータ文字列と判定し，
   前記項目名文字列と前記データ文字列の縦方向，或いは横方向の配置関係に基づいて，前記データ文字列のデータと項目名を対応付け，
   前記項目名文字列と前記データ文字列の縦方向の配置関係に基づいて前記対応付けを行った場合，横方向に繰り返された前記データ文字列が含まれる領域の隣接関係と高さ情報とに基づいて，該複数の繰り返された領域に含まれるデータ文字列を一組の情報として扱い，
   前記項目名文字列と前記データ文字列の横方向の配置関係に基づいて前記対応付けを行った場合，縦方向に繰り返された前記データ文字列が含まれる領域の隣接関係と高さ情報とに基づいて，該複数の繰り返された領域に含まれるデータ文字列を一組の情報として扱う
   ことを特徴とする帳票認識装置。
2. 請求項１記載の帳票認識装置であって，
   前記処理部は，
   前記項目名文字列と前記データ文字列との配置関係から前記データと項目名を対応付けして，前記項目名に相当する属性を判定する際，前記項目名文字列の配置から前記項目名の属性間の階層関係を解析する
   帳票認識装置。
3. 請求項１記載の帳票認識装置であって，
   前記項目名文字列と前記データ文字列との配置関係から前記データと項目名を対応付けして，前記項目名に相当する属性を判定する際，
   同一の前記領域内に複数の属性の前記データ文字列が存在する場合に，当該領域内の前記項目名文字列の配置と前記データ文字列の配置を対応付けすることにより，個々の前記データ文字列の属性を解析する
   帳票認識装置。
4. 請求項１記載の帳票認識装置であって，
   前記項目名文字列と前記データ文字列との配置関係から前記データと項目名を対応付けして，前記項目名に相当する属性を判定する際，
   同一の前記領域内に前記項目名文字列と前記データ文字列の両方が存在する場合に，両者の属性が同じであると判定する
   帳票認識装置。
5. 請求項１記載の帳票認識装置であって，
   前記項目名文字列と前記データ文字列との配置関係から前記データと項目名を対応付けして，前記項目名に相当する属性を判定する際，
   項目名単語辞書に項目名単語とプレ印刷単語を格納することにより，プレ印刷文字が記載されている文字列を判定する
   帳票認識装置。
6. 認識辞書及び項目名単語辞書を記憶する記憶部と、帳票画像の認識処理を行う処理部とからなる帳票認識装置で実行される帳票認識用プログラムであって，
   前記処理部で，
   帳票画像中の文字列が含まれる領域を検出するステップと，
   前記領域内の文字列を検出するステップと，
   検出された前記文字列の文字を認識するステップと，
   文字列の文字認識結果と前記記憶部に記憶された項目名単語とを照合するステップと，
   項目名単語照合に成功した文字列を項目名文字列と判定するステップと，
   項目名単語照合に成功しなかった文字列をデータ文字列と判定するステップと，
   前記項目名文字列と前記データ文字列の縦方向，或いは横方向の配置関係に基づいて，前記データ文字列のデータと項目名を対応付けするステップを含み，
   前記項目名文字列と前記データ文字列の縦方向の配置関係に基づいて前記対応付けを行った場合，横方向に繰り返された前記データ文字列が含まれる領域の隣接関係と高さ情報とに基づいて，該複数の繰り返された領域に含まれるデータ文字列を一組の情報として扱い，
   前記項目名文字列と前記データ文字列の横方向の配置関係に基づいて前記対応付けを行った場合，縦方向に繰り返された前記データ文字列が含まれる領域の隣接関係と高さ情報とに基づいて，該複数の繰り返された領域に含まれるデータ文字列を一組の情報として扱う
   ことを特徴とする帳票認識用プログラム。
7. 請求項６記載の帳票認識用プログラムであって，
   前記属性を判定するステップにおいて，
   前記項目名文字列の配置から前記項目名の属性間の階層関係を解析するステップを備える
   帳票認識用プログラム。

Images