項目判定システムおよび項目判定プログラム
【課題】複数の文字列の各々の項目種別を的確に判定する技術を提供する。
【解決手段】レコード抽出部１２により複数のレコードからなるリスト情報から一のレコードが抽出され、文字列分割部１３により前記レコードが各々の文字列に分割され、文字情報取得部１４により前記分割された文字列の文字情報が取得される。項目種別判定部１５は、前記文字列から特定文字列を特定し、前記レコードにおいて当該特定文字列に隣接する文字列である隣接文字列を当該特定文字列に関連する関連文字列として特定する。その後、項目種別判定部１５は、当該特定文字列の文字情報と当該関連文字列の文字情報とに基づき当該特定文字列と当該関連文字列の項目種別を判定する。
【解決手段】レコード抽出部１２により複数のレコードからなるリスト情報から一のレコードが抽出され、文字列分割部１３により前記レコードが各々の文字列に分割され、文字情報取得部１４により前記分割された文字列の文字情報が取得される。項目種別判定部１５は、前記文字列から特定文字列を特定し、前記レコードにおいて当該特定文字列に隣接する文字列である隣接文字列を当該特定文字列に関連する関連文字列として特定する。その後、項目種別判定部１５は、当該特定文字列の文字情報と当該関連文字列の文字情報とに基づき当該特定文字列と当該関連文字列の項目種別を判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、レコードを構成する複数の文字列の各々の項目種別を判定する項目判定技術に関する。
【背景技術】
【０００２】
従来、帳票や紙媒体に出力された表（以下、表等と称する）をデジタル画像として読み取り、ＯＣＲ（Optical Character Recognition）技術を用いて文字データ化する処理が行われている。このような場合には、この文字データを有効に活用するためには、各々の文字データがいかなる項目のデータであるかが判定されなければならない。そのため、表等から取得した文字データの項目種別を判定する技術に関する様々な検討が行われている。例えば、文書画像に対して文字認識を行い、文字認識結果から抽出すべき項目名に該当する文字列を抽出し、文書画像において項目名に該当する文字列の近傍位置からその項目名に対応する項目値の文字列を抽出し、その項目値の文字列を項目名と対応付ける技術がある（特許文献１参照）。この技術では、項目名の近傍に存在する文字列をその項目名に対応する項目値であるとして取得することにより、項目名と項目値の関連付けを行うことができる。
【０００３】
【特許文献１】特開２００７−２３３９１３号公報（段落番号０００９、図４）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１の技術では、文書画像内に項目名の存在が必須であり、項目名が存在しない場合には、項目名と項目値とを関連付けることはできない。
【０００５】
本発明の課題は、上記実状に鑑み、複数の文字列の各々の項目種別を的確に判定する技術を提供することである。
【課題を解決するための手段】
【０００６】
前記課題を解決するために、本発明の項目判定システムは、レコードを構成する複数の文字列の各々の項目種別を判定する項目判定システムにおいて、複数のレコードからなるリスト情報から前記レコードを取得するレコード抽出部と、前記レコードを各々の文字列に分割する文字列分割部と、前記分割された文字列の文字情報を取得する文字情報取得部と、前記文字列から特定文字列を特定し、前記レコードにおいて当該特定文字列に隣接する文字列である隣接文字列を当該特定文字列に関連する関連文字列として特定すると共に、当該特定文字列の文字情報と当該関連文字列の文字情報とに基づき当該特定文字列と当該関連文字列の項目種別を判定する項目種別判定部と、を備えている。
【０００７】
この構成では、レコードから取得された文字列から特定文字列を特定し、前記レコード中において特定文字列と隣接する隣接文字列が特定文字列と関連のある関連文字列として特定され、特定文字列の文字情報と関連文字列の文字情報とに基づき、各々の項目種別が判定される。通常、レコード中では、関連のある項目は隣接して配置されることが多い。そのため、項目種別を判定するに際して、特定文字列の文字情報と特定文字列に関連する関連文字列の文字情報を用いることにより、特定文字列の文字情報のみに基づいて項目種別を判定する場合に比べ、精度の高い項目種別の判定を行うことができる。
【０００８】
また、本発明の項目判定システムの好適な実施形態の一つでは、特定の項目種別に対応する文字情報と当該特定の項目種別に関連する関連項目種別に対応する文字情報とを関連付けて記録する判定基準記録部を備え、前記項目種別判定部は、前記特定文字列の文字情報と関連文字列の文字情報に基づき前記判定基準記録部から前記特定の項目種別と前記関連項目種別とを検索し、当該検索結果に応じて当該特定文字列の項目種別と当該関連文字列の項目種別とを判定する。
【０００９】
さらに、特定の項目種別の文字列と関連項目種別の文字列とは相互に変換が可能な場合がある。例えば、“氏名”と“氏名かな”や“郵便番号”と“住所”である。このような場合には、変換された文字列に基づき関連文字列を特定すると、項目種別の判定精度を向上させることができる。そのため、本発明の項目判定システムの好適な実施形態の一つでは、前記文字情報は、前記文字列を変換することにより得られる変換情報を含み、前記項目種別判定部は、前記特定文字列と前記隣接文字列の前記変換情報とに基づき前記文字列と前記隣接文字列とが関連する文字列であると特定する。
【００１０】
上述した本発明による項目判定システムの技術的特徴は、同様の項目判定プログラムにも適用可能である。例えば、レコードを構成する複数の文字列の各々の項目種別を判定する項目判定システムのための項目判定プログラムにおいて、複数のレコードからなるリスト情報から前記レコードを取得する機能と、前記レコードを各々の文字列に分割する機能と、前記分割された文字列の文字情報を取得する機能と、前記文字列から特定文字列を特定し、前記レコードにおいて当該特定文字列に隣接する文字列である隣接文字列を当該特定文字列に関連する関連文字列として特定すると共に、当該特定文字列の文字情報と当該関連文字列の文字情報とに基づき当該特定文字列と当該関連文字列の項目種別を判定する項目種別判定機能と、をコンピュータに実現する。当然ながら、このような項目判定プログラムも上述した項目判定システムで述べた作用効果を得ることができ、さらに上述した付加的技術を組み込むことも可能である。
【発明を実施するための最良の形態】
【００１１】
〔第１実施形態〕
以下、図面を用いて本発明の第１実施形態を説明する。本実施形態における本発明の項目判定システムは、汎用コンピュータでなる端末Ｃにより構成されており、ディスプレイや入力機器（キーボード、マウス等）を備えている。
【００１２】
図１は、本発明の項目判定システムを構成する端末Ｃの機能ブロック図を示している。端末Ｃは、リスト情報Ｌを取得するリスト情報取得部１１、リスト情報取得部１１により取得されたリスト情報Ｌから一のレコードを抽出するレコード抽出部１２、レコード抽出部１２により抽出されたレコードを文字列に分割する文字列分割部１３、文字列分割部１３により分割された各々の文字列の文字情報を取得する文字情報取得部１４、文字情報取得部１４により取得された文字情報に基づき文字列の項目種別を判定する項目種別判定部１５、項目種別判定部１５により判定された項目種別に基づき文字列と項目種別とを関連付けた統合情報を生成する統合情報生成部１６、項目種別の判定基準を記録する判定基準記録部２２を備えている。
【００１３】
通常、リスト情報取得部１１、レコード抽出部１２、文字列分割部１３、文字情報取得部１４、項目種別判定部１５、統合情報生成部１６は、その処理を実行する手段（プログラムやモジュール等）がハードウェアに読み込まれることでその処理が実行されるが、これらをハードウェアとの組み合わせにより構成しても良いし、ロジック等を組み合わせたハードウェアのみで構成しても構わない。
【００１４】
なお、図４に示すように、本発明におけるリスト情報Ｌとは、１以上のレコードＲの集合であり、レコードＲとは複数の文字列Ｓにより構成された情報である。例えば、リスト情報Ｌが住所録の場合には、各人の住所データ群がレコードＲであり、各レコードＲは住所データ群を構成する住所、氏名、電話番号等を表す文字列Ｓから構成されている。以下の説明では、リスト情報Ｌを住所録として説明するが、当然ながら、本発明は、他の情報に対しても適用可能である。
【００１５】
リスト情報取得部１１は、リスト情報Ｌを取得する。元々の情報が、紙等に印字された印刷媒体の場合には、スキャナ等によりデジタル画像データが取得され、公知のＯＣＲにより、文字データとしてのリスト情報Ｌが取得される。また、元々の情報が電子データの場合には、そのままの電子データをリスト情報Ｌとして取得する。前者の場合には、ＯＣＲの有する罫線認識機能により罫線位置が認識され、罫線位置に対応する文字として“，”が用いられる。すなわち、“，”が文字列Ｓに対するセパレータとして使用される。例えば、図２に示す住所録からは、図４に示すような“青空 太郎，あおぞら たろう，532-0003，大阪府・・・１−２，おおさかふ・・・１−２，06-6123-4567\n大空 花子，おおぞら はなこ，100-8915，東京都・・・３−４，とうきょうと・・・３−４，03-3456-7890\n・・・”がリスト情報Ｌとして取得される。なお、同一行の認識文字の最後に“\n”（改行文字）を付加しており、この改行文字はレコードＲのデリミタとして用いられる。取得したリスト情報Ｌは、レコード抽出部１２に送られる。なお、本実施形態では、上述のセパレータを用いるが、これに限定されるものではなく、タブ文字や所定の組み合わせ文字列等、本発明の目的を達する限りにおいて他の文字等を用いることができる。
【００１６】
レコード抽出部１２は、リスト情報取得部１１により取得されたリスト情報Ｌから一のレコードＲを抽出する。上述のように、リスト情報ＬがＯＣＲを用いて取得された場合には、各々のレコードＲは改行文字により区切られているため、レコード抽出部１２はリスト情報Ｌの先頭もしくは改行文字の次の文字から改行文字までを一のレコードとして抽出する。また、リスト情報Ｌが電子データとして取得された場合には、電子データには様々なフォーマットが存在するため、その電子データのフォーマットに従いレコードＲを抽出する。例えば、電子データがＣＳＶ（Comma-Separated Values）形式の場合には、上述同様、リスト情報Ｌの先頭もしくは改行文字の次の文字から改行文字までを一のレコードとして抽出する。抽出したレコードＲは、文字列分割部１３に送られる。
【００１７】
文字列分割部１３は、レコード抽出部１２により抽出された一のレコードＲをセパレータに基づき各々の文字列Ｓに分割する。このとき、各々の文字列Ｓには、レコードＲ中における文字列Ｓの位置を表す項目情報が付加される。
【００１８】
文字情報取得部１４は、公知の手法により、各々の文字列Ｓの文字情報を取得する。なお、本実施形態における文字情報とは、漢字、かな、数字、英字等の文字種別を用いる。この場合には、文字種別毎に文字コードの範囲が特定できるため、文字コードに基づき文字種別を取得することができる。文字情報取得部１４は、文字列Ｓ、文字列Ｓの項目情報および文字列Ｓの文字情報を項目種別判定部１５に送る。
【００１９】
項目種別判定部１５は、文字情報取得部１４から取得した文字列Ｓから特定文字列を特定し、レコードＲ中においてその特定文字列に隣接する文字列（以下、隣接文字列と称する）を特定文字列に関連する関連文字列として特定する。さらに、特定文字列の文字情報、関連文字列の文字情報および判定基準記録部２２に記録されている判定基準に基づき、特定文字列および関連文字列の項目種別を判定する。判定結果は、文字列Ｓと共に統合情報生成部１６に送られる。
【００２０】
統合情報生成部１６は、文字列Ｓとその項目種別に基づき統合情報を生成する。統合情報とは、文字列Ｓとその文字列の項目種別が関連付けられた情報の総称である。
【００２１】
以下、図３のフローチャートを用いて本発明の項目判定システムの処理の流れを説明する。なお、本実施形態では、図２に示す住所録の項目種別を判定するものとし、項目種別は、氏名、氏名ふりがな、郵便番号、住所、住所ふりがな、電話番号とする。
【００２２】
まず、リスト情報取得部１１は、リスト情報Ｌを取得する（＃０１）。図２の住所録が紙に印字されているとすると、操作者は、スキャナ（図示せず）に住所録が印字された用紙を載置した後、端末Ｃを操作し、デジタル画像データを取得する。取得されたデジタル画像データは、公知のＯＣＲ技術により文字データに変換される。このとき、ＯＣＲの機能により、図２の住所録中に存在する罫線が認識され、認識結果中では文字データ“，”として表される（図４上段参照）。なお、この“，”は以降の処理において、文字列Ｓのセパレータとして利用される。また、同一行に存在する文字の認識結果である文字データの後ろには改行文字“\n”が挿入される。このようにして取得されたリスト情報Ｌは、レコード抽出部１２に送られる。
【００２３】
リスト情報Ｌを取得したレコード抽出部１２は、リスト情報Ｌの構造に基づき、一のレコードＲを抽出する（＃０２）。本実施形態では、上述の処理により、改行文字“\n”がレコードＲのデリミタとして機能している。したがって、レコード抽出部１２は、リスト情報Ｌの先頭もしくは前回のレコードＲの抽出処理後の残りのデータの先頭から改行文字“\n”までをレコードＲとして抽出する。具体的には、１回目のレコード抽出では、“青空 太郎，あおぞら たろう，532-0003，大阪府・・・１−２，おおさかふ・・・１−２，06-6123-4567”が抽出され、２回目のレコードでは“大空 花子，おおぞら はなこ，100-8915，東京都・・・３−４，とうきょうと・・・３−４，03-3456-7890”が抽出される（図４の中段参照）。このようにして抽出された一のレコードＲは、文字列分割部１３に送られる。
【００２４】
文字列分割部１３は、レコード抽出部１２から取得したレコードＲを文字列Ｓに分割する（＃０３）。上述したように、本実施形態では、“，”が文字列Ｓのセパレータとして用いられているため、文字列分割部１３は、セパレータ“，”に基づきレコードＲを文字列Ｓに分割する（図４の下段参照）。このとき、文字列分割部１３は、分割した文字列Ｓに対して、項目情報を付加する。本実施形態における項目情報とは、文字列ＳがレコードＲ中において何番目に位置するかを表す情報であり、例えば、文字列“青空 太郎”の項目情報は１、文字列“03-3456-7890”の項目情報は６となる。このようにして得られた文字列Ｓおよび項目情報は、文字情報取得部１４に送られる。なお、以下の説明では、項目情報ｉを持つ文字列Ｓを文字列Ｓi（ｉ＝１，２，・・・，６）と表記する。１番目のレコードＲに対する処理ループでは、Ｓ1＝“青空 太郎”、Ｓ2＝“あおぞら たろう”、Ｓ3＝“532-0003”、Ｓ4＝“大阪府・・・１−２”、Ｓ5＝“おおさかふ・・・１−２”、Ｓ6＝“06-6123-4567”となる。
【００２５】
文字列分割部１３から文字列Ｓiおよびそれらの項目情報を取得した文字情報取得部１４は、公知の手法により、各々の文字列Ｓiの文字情報を取得し（＃０４）、文字列Ｓiおよび項目情報と共に項目種別判定部１５に送る。なお、本実施形態では、文字情報として文字種別を用い、文字列Ｓiの文字情報をＩiとすると、上述の例では、Ｉ1＝“漢字”、Ｉ2＝“かな”、Ｉ3＝“数字”、Ｉ4＝“漢字＋数字”、Ｉ5＝“かな＋数字”、Ｉ6＝“数字”となる。
【００２６】
項目種別判定部１５では、まず一の文字列Ｓを特定文字列として特定する（＃０５）。本実施形態では、未処理の文字列Ｓのうち最も小さな項目情報を持つ文字列Ｓを特定文字列とする。すなわち、最初の処理ループでは、文字列Ｓ1＝“青空 太郎”が特定文字列として特定される。
【００２７】
次に、項目種別判定部１５は、隣接文字列を特定文字列に関連する文字列Ｓ（以下、関連文字列と称する）として特定する（＃０６）。上述の例では、文字列Ｓ2＝“あおぞら たろう”が関連文字列として特定される。なお、本実施形態では、隣接とは、完全に隣り合うことを指すが、所定間隔離れている場合にも隣接として扱って構わない。
【００２８】
さらに、項目種別判定部１５は、特定文字列の文字情報、関連文字列の文字情報および判定基準記録部２２に記録されている判定基準に基づき、特定文字列の項目種別および関連文字列の項目種別を判定する（＃０７）。判定基準記録部２２には、特定の項目種別に対応する文字情報とその特定の項目種別に関連する項目種別（以下、関連項目種別と称する）に対応する文字情報とが記録されている。ここで、関連とは、特定の項目種別の文字列と関連項目種別の文字列とがレコードＲ中において隣接する可能性が高い関係を言う。例えば、氏名と氏名ふりがな、郵便番号と住所等の関係である。ここで、判定基準記録部２２に図５に示す判定基準が記録されているとする。上述の例では、特定文字列の文字情報が“漢字”、関連文字列の文字情報が“かな”として取得されているため、これらの文字情報を用いて判定基準を検索すると、第１文字情報が“漢字”、第２文字情報が“かな”である判定基準として、“氏名”−“氏名ふりがな”の関係が検索される。したがって、特定文字列の項目種別は“氏名”、関連文字列の項目種別は“氏名かな”と判定される。
【００２９】
次に、項目種別判定部１５は、未処理の文字列Ｓが存在するか否かを判定する（＃０８）。未処理の文字列が存在する場合（＃０８のYes分岐）には、次の特定文字列の特定を行う（＃０５）。上述の例の場合には、文字列Ｓ1およびＳ2の項目種別の判定が終了しているため、特定文字列として文字列Ｓ3、関連文字列として文字列Ｓ4が特定される（＃０６、＃０７）。この場合の文字情報Ｉ3およびＩ4は、それぞれ“数字”および“漢字＋数字”であり、特定文字列および関連文字列の項目種別は、それぞれ“郵便番号”および“住所”と判定される。
【００３０】
上述の処理は、未処理の文字列Ｓが存在しなくなるまで（＃０８のNo分岐）繰り返される。なお、上述の処理では、特定文字列とも関連文字列とも特定されていない文字列を次の特定文字列としたが、全ての文字列Ｓが必ず一度は特定文字列として特定されるような構成としても構わない。これらの処理により、文字列Ｓ1からＳ5までの項目種別が“氏名”、“氏名かな”、“郵便番号”、“住所”、“住所かな”として特定される。特定された項目種別は、文字列Ｓと共に統合情報生成部１６に送られる。
【００３１】
一のレコードＲに対しての項目判定処理が完了すると、未処理のレコードＲが存在するか否かが判定され（＃０９）、未処理レコードＲが存在する場合（＃０９のYes分岐）には、次のレコードＲが取得される（＃０２）。上述の例では、レコードＲとして“大空 花子，おおぞら はなこ，987-6543，東京都・・・３−４，とうきょうと・・・３−４，03-3456-7890”が取得され、上述の処理が実行される。
【００３２】
一方、全てのレコードＲの処理が完了すると（＃０９のNo分岐）、統合情報生成部１６は統合情報を生成する。
【００３３】
〔第２実施形態〕
次に、本発明による項目判定システムの第２実施形態を説明する。図６は、本実施形態における機能ブロック図であり、文字情報の定義を記録する文字情報記録部２１を備えている点で第１実施形態と異なっている。
【００３４】
本実施形態における文字情報記録部２１には、文字情報の定義として文字種別条件情報が記録されており、文字情報取得部１４は、文字種別条件情報に基づき文字列Ｓの文字情報を取得する。本実施形態における文字種別条件情報とは、上述の文字種別をさらに細分化するための条件である。例えば、人名漢字の文字コードが文字種別条件情報として記録されており、公知の手法により、文字列Ｓの文字の文字情報（文字種別）が漢字として取得された際に、さらに文字種別条件情報に基づき、人名漢字か否かの情報を文字情報に含めることができる。なお、文字種別の細分化は、人名漢字に限定されるものではなく、漢字を漢数字等に、その他・外国語を英語、フランス語、韓国語、ロシア語、アラビア語等の各言語文字や記号を数学記号、音楽記号（♯、♭等）、情報通信関連文字（＠等）等に細分化することもでる。
【００３５】
次に、本実施形態の処理の流れを説明するが、第１実施形態と同様の処理の説明は省略する。まず、＃０１から＃０３までの処理により一のレコードＲが取得され、文字列Ｓiに分割される。
【００３６】
文字列Ｓiは、文字情報取得部１４に送られ、第１実施形態と同様に、公知の方法により文字種別が判定され、文字情報として取得される。さらに、文字情報取得部１４は、文字情報記録部２１に記録されている文字種別条件情報に基づき、詳細な文字種別を判定し、文字情報に付加する（＃０４）。例えば、文字列Ｓ1＝“青空 太郎”は、人名漢字“郎”を含んでいるため、文字列Ｓ1の文字情報は、“人名漢字を含む漢字”として取得される。このようにして取得された文字情報は、文字列Ｓiと共に項目種別判定部１５に送られる。
【００３７】
文字列Ｓiと文字情報を取得した項目種別判定部１５は、判定基準記録部２２に記録されている判定基準に基づき、各文字列Ｓiの項目種別を判定する（＃０５〜＃０７）。上述のように、本実施形態における文字情報は、第１実施形態における文字情報に比べて細分化されている。したがって、本実施形態で用いる判定基準の文字情報も細分化されている。例えば、図５の１番目の判定基準は、第１文字情報が“漢字”に代えて“人名漢字を含む漢字”となる。このとき、特定文字列としてＳ1＝“青空 太郎”、関連文字列としてＳ2＝“あおぞら たろう”が特定されているとすると、上述のようにＳ1の文字情報は“人名漢字を含む漢字”であり、Ｓ2の文字情報は“かな”であるため、これらの文字種別は、“氏名”と“氏名かな”であると判定される。
【００３８】
本実施形態では、第１実施形態に比べて細分化した文字種別を文字情報として用い、細分化した文字種別に応じた判定基準を用いることにより、より的確に文字種別を判定することができる。
【００３９】
〔第３実施形態〕
次に、図面を用いて本発明による項目判定システムの第３実施形態を説明する。本実施形態における機能ブロック図は、第１実施形態と同様であるため、詳細な説明は省略する。なお、本実施形態における文字情報は、文字数であり、判定基準記録部２２には、図７に示すような判定基準が記録されている。
【００４０】
次に、図３のフローチャートを用いて、本実施形態における処理の流れを説明するが、第１実施形態と同様の処理の説明は省略する。
【００４１】
まず、＃０１から＃０３までの処理により一のレコードＲが取得され、文字列Ｓiに分割される。１回目の処理ループの場合のレコードＲは“青空 太郎，あおぞら たろう，532-0003，大阪府・・・１−２，おおさかふ・・・１−２，06-6123-4567”であり、分割された文字列は、Ｓ1＝“青空 太郎”、Ｓ2＝“あおぞら たろう”、Ｓ3＝“532-0003”、Ｓ4＝“大阪府・・・１−２”、Ｓ5＝“おおさかふ・・・１−２”、Ｓ6＝“06-6123-4567”である。
【００４２】
文字列分割部１３から上述の文字列を取得した文字情報取得部１４は、各々の文字列の文字情報を取得する（＃０４）。上述したように、本実施形態では文字情報として文字数を用いる。そのため、文字情報取得部１４は、公知の方法により各文字列Ｓiの文字数を計数する。このとき、空白やハイフン等の記号は計数されない。上述の例では、Ｉ1＝４、Ｉ2＝７、Ｉ3＝７、Ｉ4＝１５、Ｉ5＝２７、Ｉ6＝１０となる。なお、本実施形態では、空白やハイフン等の記号は計数しないが、計数する構成としてもよく、その場合には、判定基準を適切に修正しておけばよい。
【００４３】
次に、＃０５および＃０６の処理により、特定文字列としてＳ1＝“青空 太郎”、関連文字列としてＳ2＝“あおぞら たろう”が特定される。さらに、項目種別判定部１５は、特定文字列の文字情報Ｉ1＝４および関連文字列の文字情報Ｉ1＝７に基づき、判定基準記録部２２を検索することにより、第１行目の判定基準を取得する。したがって、文字列Ｓ1＝“青空 太郎”の項目種別は“氏名”、文字列Ｓ2＝“あおぞら たろう”の項目種別は“氏名かな”と判定される（＃０７）。
【００４４】
未処理文字列が存在する場合（＃０８のYes分岐）には、処理は＃０５に戻り、上述の処理が行われ、特定文字列がＳ3＝“532-0003”、関連文字列がＳ4＝“大阪府・・・１−２”と特定された際には、文字列Ｓ3＝“532-0003”の項目種別は“郵便番号”、文字列Ｓ4＝“大阪府・・・１−２”の項目種別は“住所”と判定される。
【００４５】
全文字列Ｓの処理が完了すると（＃０８のNo分岐）、未処理レコードの有無が判定され（＃０９）、未処理レコードが存在する場合（＃０９のYes分岐）には、処理が＃０２に戻り、上述の処理が繰り返される。
【００４６】
〔第４実施形態〕
次に、本発明による項目判定システムの第４実施形態を説明する。本実施形態における機能部は第２実施形態と同様であるが、文字情報が変換情報である点において第２実施形態と異なっている。なお、本実施形態における変換情報とは、所定の変換ルールに基づき変換された文字列とそのときの変換種別の対であり、文字情報記録部２１には所定の変換ルールが記録されている。本実施例では、図８に示すような、漢字−かな、住所−郵便番号、住所−電話番号の相互の変換ルールを用いているが、他の変換ルールを用いても構わず、判定する項目種別により適宜変更可能である。また、本実施形態における隣接とは、レコードＲにおいて完全に隣り合う場合だけでなく、所定範囲離れている場合も含んでいる。
【００４７】
以下に、図３のフローチャートに基づいて本実施形態における処理の流れを説明する。１回目の処理ループでは、＃０１から＃０３までの処理により、Ｓ1＝“青空 太郎”、Ｓ2＝“あおぞら たろう”、Ｓ3＝“532-0003”、Ｓ4＝“大阪府・・・１−２”、Ｓ5＝“おおさかふ・・・１−２”、Ｓ6＝“06-6123-4567”が得られる。
【００４８】
文字情報取得部１４は、文字情報記録部２１に記録されている所定の変換ルールに基づき、各々の文字列Ｓiの文字情報を取得する。例えば、文字列Ｓ1＝“青空 太郎”の場合には、被変換文字列を“青空”および“太郎”として、図８の変換ルールを検索すると、変換文字列“あおぞら”および“たろう”が得られ、そのときの変換種別は“氏名→氏名かな”である。したがって、文字列Ｓ1の文字情報Ｉ1は、変換文字列と変換種別の対［“あおぞら たろう”，“氏名→氏名かな”］として得られる。同様に、文字列Ｓ4＝“大阪府・・・１−２”の場合には、“532-0003”および“おおさかふ・・・１−２”が文字情報として取得され、そのときの変換種別はそれぞれ“住所→郵便番号”、“住所→住所かな”である。なお、文字列Ｓ4のように、複数の変換文字列が得られる場合には、得られた変換文字列の集合を文字情報とし、以下の説明では“｛”および“｝”により集合を表す。なお、文字情報記録部２１を用いずに、文字変換ソフトウェアを用いて被変換文字列を変換し、その変換結果に基づき、変換種別を取得する構成としても構わない。
【００４９】
上述の処理により取得された文字情報Ｉ1＝［“あおぞら たろう”，“氏名→氏名かな”］、Ｉ2＝［“青空 太郎”，“氏名かな→氏名”］、Ｉ3＝［“大阪府・・・”，“郵便番号→住所”］、Ｉ4＝｛［“532-0003”，“住所→郵便番号”］，［“おおさかふ・・・１−２”，“住所→住所かな”］｝、Ｉ5＝［“大阪府・・・１−２”，“住所かな→住所”］、Ｉ6＝［“大阪府”，“電話番号→住所”］は、項目情報判定部１４に送られる。
【００５０】
上述の文字情報Ｉiを取得した項目種別判定部１５は、特定文字列を特定し（＃０５）、特定文字列と隣接文字列の文字情報に基づき関連文字列を特定する（＃０６）。具体的には、特定文字列の項目情報との差が所定範囲以内の項目情報を持つ隣接文字列のうち、特定文字列と一致する変換情報（文字情報）を持つものが関連文字列として特定される。なお、関連文字の特定は、一致する場合だけでなく、変換情報が含まれる場合や所定の文字数以上が一致する等を条件として行っても構わない。
【００５１】
なお、文字情報が集合の場合には、集合の各要素に対して比較が行われる。また、関連文字列を特定する際に、特定文字列の変換情報（文字情報）と隣接文字列とを比較しても構わない。
【００５２】
その後、項目種別判定部１５は、特定文字列の文字情報と関連文字列の文字情報とに基づき、特定文字列および関連文字列の項目種別を判定する（＃０７）。具体的には、特定文字列の文字情報の変換文字列と、関連文字列が比較され、一致する場合には、その文字情報の変換種別に基づき特定文字列の項目種別と関連文字列の項目種別が判定される。例えば、特定文字列がＳ1＝“青空 太郎”、関連文字列がＳ2＝“あおぞら たろう”として特定された場合には、文字情報Ｉ1の変換文字列“あおぞら たろう”と関連文字列Ｓ2とが比較され、これらは一致する。このとき、文字情報Ｉ1の変換種別“氏名→氏名かな”に基づき、文字列Ｓ1の項目種別は“氏名”、文字列Ｓ2の項目種別は“氏名かな”として判定される。
【００５３】
未処理文字列が存在する場合（＃０８のYes分岐）には、処理は＃０５に戻り、上述の処理が行われる。全文字列Ｓに対する処理が完了すると、各々の文字列Ｓiの項目種別はそれぞれ、“氏名”、“氏名かな”、“郵便番号”、“住所”、“住所かな”、“電話番号”と判定される。
【００５４】
全文字列Ｓの処理が完了すると（＃０８のNo分岐）、未処理レコードの有無が判定され（＃０９）、未処理レコードが存在する場合（＃０９のYes分岐）には、処理が＃０２に戻り、上述の処理が繰り返される。
【００５５】
〔第５実施形態〕
次に、図面を用いて本発明による項目判定システムの第５実施形態を説明する。図９は本実施形態における機能ブロックであり、項目種別判定部１５が、さらに、項目種別を予測する項目種別予測部１５ａおよび、予測結果判定部１５ｂを備えている点において第２実施形態と異なっている。以下の説明では、第２実施形態と同様の機能部の説明は省略する。
【００５６】
また、本実施形態の判定基準記録部２２には、図１０の第１判定基準および図１１に示す第２判定基準が記録されている。第１判定基準は、項目種別予測部１５ａが文字情報に基づき項目種別を予測するために用いる判定基準であり、第２判定基準は、予測結果判定部１５ｂが、項目種別予測部１５ａによる予測の適否を判定するための基準である。
【００５７】
項目種別予測部１５ａは、特定文字列の文字情報、関連文字列の文字情報および第１判定基準に基づき、特定文字列の項目種別と関連文字列の項目種別の予測を行う。なお、本実施形態では文字情報として、文字種別および文字数の対を用いているが、これに限定されるものではなく、上述した文字情報の一つ又はそれらの任意の組み合わせ、および他の文字情報を用いても構わない。
【００５８】
予測結果判定部１５ｂは、文字情報および第２判定基準に基づき、項目種別予測部１５ａにより予測された項目種別の適否を判定する。なお、項目種別予測部１５ａによる項目種別の予測は、一の文字列に対して複数の項目種別を予測する構成としてもよく、この場合には、予測結果判定部１５ｂが、一の項目種別を判定結果とする。
【００５９】
以下に、本実施形態における処理の流れを説明する。全体の処理の流れは、図３に示した処理の流れと同様であり、図３における＃０７の項目種別判定処理が異なっているため、図１２のフローチャートを用いて、項目種別判定処理の流れを説明する。
【００６０】
項目種別判定部１５は、文字列分割部１３により分割された文字列Ｓiおよび文字情報取得部１４により取得された文字情報Ｉiを取得する。例えば、文字列Ｓ1＝“青空 太郎”、Ｓ2＝“あおぞら たろう”、Ｓ3＝“532-0003”、Ｓ4＝“大阪府・・・１−２”、Ｓ5＝“おおさかふ・・・１−２”、Ｓ6＝“06-6123-4567”、文字情報Ｉ1＝［“漢字”，４］、Ｉ2＝［“かな”，７］、Ｉ3＝［“数字”，７］、Ｉ4＝［“漢字＋数字”，１５］、Ｉ5＝［“かな＋数字”，２７］、Ｉ6＝［“数字”，１０］が取得される。また、項目種別判定部１５は、特定文字列と関連文字列を特定し、これらを項目種別予測部１５ａに送る。例えば、特定文字列として文字列Ｓ1＝“青空 太郎”、関連文字列として文字列Ｓ2＝“あおぞら たろう”およびこれらの文字情報Ｉ1、Ｉ2が、項目種別予測部１５ａに渡される。
【００６１】
特定文字列および関連文字列を取得した項目種別予測部１５ａは、特定文字列の文字情報および関連文字列の文字情報に基づき、第１判定基準を検索する（＃２１）。具体的には、第１文字情報と特定文字列の文字情報とが一致し、第２文字情報と関連文字列の文字情報とが一致する判定基準を検索する。該当する判定基準が検索されない場合（＃２２のNo分岐）には、処理は＃０５に戻り、新たな特定文字列が特定される。なお、判定基準が検索されない場合に、その旨を記録または管理者へ通知しても構わない。
【００６２】
一方、判定基準が検索された場合（＃２２のYes分岐）には、予測結果が予測結果判定部１５ｂに送られる。上述の例では、特定文字列の文字種別（文字情報）が“漢字”、関連文字列の文字種別（文字情報）が“かな”であるため、［“氏名”，“氏名かな”］、［“住所”，“住所かな”］の２組の項目種別が検索される。したがって、特定文字列の項目種別は“氏名”もしくは“住所”、関連文字列の項目種別は“氏名かな”もしくは“住所かな”と予測される（＃２３）。
【００６３】
予測結果を取得した予測結果判定部１５ｂは、項目種別予測部１５ａの予測結果に基づき、第２判定基準から対応する判定基準を抽出し、文字列Ｓiもしくは文字情報Ｉiがその判定基準を充足するか否かが判定される（＃２４、＃２５）。上述の例では、特定文字列の項目種別は、“氏名”もしくは“住所”と予測されているため、予測結果判定部１５ｂは、第２判定基準から項目種別が“氏名”もしくは“住所”である判定基準を検索する。この場合には、判定基準“６文字以下”および“１０文字以上２０文字以下”が検索される。予測結果判定部１５ｂは、この検索された判定基準と、特定文字列の文字数（文字情報）である“４”とを比較すると、判定基準“６文字以下”を充足する（＃２４のYes分岐）ため、特定文字列の項目種別は“氏名”であると判定する。
【００６４】
また、関連文字列の項目種別は、“氏名かな”もしくは“住所かな”と予測されているが、特定文字列の項目種別は“氏名”であると判定されているため、予測結果判定部１５ｂは、第２判定基準から項目種別が“氏名かな”である判定基準を検索する。この場合には、判定基準“５文字以上”が検索される。予測結果判定部１５ｂは、この判定基準と関連文字列の文字数（文字情報）である“７”とを比較すると、判定基準を充足する（＃２５のYes分岐）ため、関連文字列の項目種別は“氏名かな”であると判定する。
【００６５】
したがって、特定文字列の項目種別は“氏名”、関連文字列の項目種別は“氏名かな”として確定される。
【００６６】
一方、特定文字列または特定文字列の文字情報が検索された判定基準を充足しない場合（＃２４のNo分岐）もしくは関連文字列または関連文字列の文字情報が検索された判定基準を充足しない場合（＃２５のNo分岐）には、項目種別予測部１５ａの予測は棄却される（＃２７）。このとき、予測が棄却された旨の情報を記録又は管理者へ通知する構成としても構わない。
【００６７】
上述の説明では、第２判定基準の充足を判定する際に、文字列Ｓiの文字情報を用いていたが、判定基準により文字列Ｓiを用いることも可能である。例えば、郵便番号の場合には、数字の前に“〒”（郵便マーク）が記載されている場合があるため、文字列Ｓiにこの郵便マークが含まれているか否かを判定基準とすることができる。
【００６８】
〔第６実施形態〕
次に、図面を用いて本発明による項目判定システムの第６実施形態を説明する。図１３は本実施形態における機能ブロックであり、予測結果判定部１５ｂに代えて文字列を所定の変換ルールに基づき変換する文字列変換部１５ｃを備えている点において第５実施形態と異なっている。なお、本実施形態の文字情報記録部２１には、図８の変換ルールが記録されている。
【００６９】
文字列変換部１５ｃは、文字列を項目種別予測部１５ａの予測結果に応じた項目種別の文字列に変換する。文字列の変換に際して、文字列変換部１５ｃは、文字情報記録部２１の変換ルールを用いる。
【００７０】
以下に、本実施形態における処理の流れを説明する。全体の処理の流れは、図３に示した処理の流れと同様であり、図３における＃０７の項目種別判定処理が異なっているため、図１４のフローチャートを用いて、項目種別判定処理の流れを説明する。また、＃３１から＃３３の処理は＃２１から＃２３の処理と同様であるので、説明は省略する。
【００７１】
まず、特定文字列がＳ１＝“青空 太郎”、関連文字列がＳ２＝“あおぞら たろう”として特定された場合には、特定文字列の項目種別は“氏名”もしくは“住所”、関連文字列の項目種別は“氏名かな”もしくは“住所かな”と予測される（＃３１〜＃３３）。特定文字列、関連文字列およびこれらに対する予測結果が文字列変換部１５ｃに送られる。
【００７２】
文字列変換部１５ｃは、まず特定文字列に対する予測結果に基づき、特定文字列を変換し（＃３４）、項目種別判定部１５は、変換された文字列と関連文字列とを比較することにより、項目種別を仮判定する（＃３５）。また、文字列変換部１５ｃは、関連文字列に対する予測結果に基づき、関連文字列を変換し（＃３６）、項目種別判定部１５は、変換された文字列と特定文字列とを比較することにより、項目種別を仮判定する（＃３７）。最後に、項目種別判定部１５は、２つの仮判定のうち、一致する結果を最終的な項目種別の判定結果とする（＃３８）。なお、仮判定の結果が一致しない場合には、その旨を記録又は管理者へ通知する構成としても構わない。
【００７３】
上述の例では、特定文字列の項目種別は“氏名”もしくは“住所”と予測されているため、文字列変換部１５ｃは、文字情報記録部２１から対応するルールとして、“氏名”から“氏名かな”への変換ルールを取得し、その変換ルールにしたがい特定文字列を変換することにより、文字列“あおぞら たろう”を取得する。この変換された文字列は関連文字列と一致するため、特定文字列の項目種別は“氏名”、関連文字列の項目種別は“氏名かな”であると仮判定される。なお、特定文字列を住所とした場合の変換ルールは存在しないため、特定文字列の項目種別は“住所”ではないと判定される。
【００７４】
次に、文字列変換部１５ｃは、関連文字列に対しても上述と同様の処理を行うと、変換された文字列として“青空 太郎”が取得され、特定文字列と一致するため、関連文字列の項目種別は“氏名かな”、特定文字列の項目種別は“氏名”と仮判定される。したがって、２つの仮判定結果が一致するため、特定文字列の項目種別は“氏名”、関連文字列の項目種別は“氏名かな”と判定される。
【００７５】
〔別実施形態〕
（１）上述の判定基準として正規表現を用いることも可能である。例えば、住所の判定基準として、“/.*[都道府県].*[市区郡].*/”を用いることができる。この例では、任意に文字列の後に“都道府県”のいずれかの文字があり、その後に任意の文字列があり、さらに“市区郡”のいずれかの文字と任意の文字列が後続する文字列を表している。このような正規表現を用いることにより、判定基準の表現に柔軟性が増し、好適である。なお、正規表現は、上述の実施形態の判定基準に代えてまたは共に用いても構わない。
【００７６】
（２）上述の第２実施形態では、文字情報記録部２１に文字コードに基づく文字種別条件情報を記録しておき、文字情報取得部１４は、文字種別条件情報に基づき各々の文字に対する細分化した各文字種別を取得したが、図１５に示す文字種別条件情報を用いて文字列Ｓに対しての細分化した文字種別を取得することもできる。例えば、文字列Ｓ＝“大阪府大阪市・・・”であれば、文字数が３０文字以内であり、正規表現“/.*[都道府県].*[市区郡].*/”にマッチするため、文字列Ｓの文字種別は住所漢字として取得される。なお、本実施形態の場合には、図５の判定基準において、文字情報（文字種別）が文字種別条件情報における文字種別に置換された判定基準が用いられる。
【００７７】
（３）上述の実施形態では、スタンドアロン型により本発明の項目判定システムを構築していたが、クライアント−サーバ型等、他の構成を用いることも可能である。クライアント−サーバ型の場合には、各機能部の配置形態は種々可能である。例えば、リスト情報取得部１１以外の機能部をサーバに配置する、リスト情報取得部１１およびレコード取得部１２以外の機能部をサーバに設置する等、サーバやネットワークの負荷等に応じて適宜変更可能である。また、統合情報として、表形式の電子データ等を用いた場合には、その電子データはサーバから端末Ｃに送信される。
【図面の簡単な説明】
【００７８】
【図１】本発明による項目判定システムの第１実施形態における機能ブロック図
【図２】本発明による項目判定システムで用いられる住所録の例
【図３】本発明による項目判定システムの第１実施形態の処理の流れを表すフローチャート
【図４】本発明による項目判定システムの実施形態におけるリスト情報からレコードへの分割およびレコードから文字列への分割を模式的に表す図
【図５】本発明による項目判定システムの第１実施形態における判定基準の例
【図６】本発明による項目判定システムの第２実施形態における機能ブロック図
【図７】本発明による項目判定システムの第３実施形態における判定基準の例
【図８】本発明による項目判定システムの第４実施形態における変換ルールの例
【図９】本発明による項目判定システムの第５実施形態における機能ブロック図
【図１０】本発明による項目判定システムの第５実施形態における第１判定基準の例
【図１１】本発明による項目判定システムの第５実施形態における第２判定基準の例
【図１２】本発明による項目判定システムの第５実施形態の処理の流れを表すフローチャート
【図１３】本発明による項目判定システムの第６実施形態における機能ブロック図
【図１４】本発明による項目判定システムの第６実施形態の処理の流れを表すフローチャート
【図１５】本発明による項目判定システムの別実施形態における文字種別条件情報の例
【符号の説明】
【００７９】
Ｃ：端末
１１：リスト情報取得部
１２：レコード抽出部
１３：文字列分割部
１４：文字情報取得部
１５：項目種別判定部
１６：統合情報生成部
２１：文字情報記録部
２２：判定基準記録部
【技術分野】
【０００１】
本発明は、レコードを構成する複数の文字列の各々の項目種別を判定する項目判定技術に関する。
【背景技術】
【０００２】
従来、帳票や紙媒体に出力された表（以下、表等と称する）をデジタル画像として読み取り、ＯＣＲ（Optical Character Recognition）技術を用いて文字データ化する処理が行われている。このような場合には、この文字データを有効に活用するためには、各々の文字データがいかなる項目のデータであるかが判定されなければならない。そのため、表等から取得した文字データの項目種別を判定する技術に関する様々な検討が行われている。例えば、文書画像に対して文字認識を行い、文字認識結果から抽出すべき項目名に該当する文字列を抽出し、文書画像において項目名に該当する文字列の近傍位置からその項目名に対応する項目値の文字列を抽出し、その項目値の文字列を項目名と対応付ける技術がある（特許文献１参照）。この技術では、項目名の近傍に存在する文字列をその項目名に対応する項目値であるとして取得することにより、項目名と項目値の関連付けを行うことができる。
【０００３】
【特許文献１】特開２００７−２３３９１３号公報（段落番号０００９、図４）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１の技術では、文書画像内に項目名の存在が必須であり、項目名が存在しない場合には、項目名と項目値とを関連付けることはできない。
【０００５】
本発明の課題は、上記実状に鑑み、複数の文字列の各々の項目種別を的確に判定する技術を提供することである。
【課題を解決するための手段】
【０００６】
前記課題を解決するために、本発明の項目判定システムは、レコードを構成する複数の文字列の各々の項目種別を判定する項目判定システムにおいて、複数のレコードからなるリスト情報から前記レコードを取得するレコード抽出部と、前記レコードを各々の文字列に分割する文字列分割部と、前記分割された文字列の文字情報を取得する文字情報取得部と、前記文字列から特定文字列を特定し、前記レコードにおいて当該特定文字列に隣接する文字列である隣接文字列を当該特定文字列に関連する関連文字列として特定すると共に、当該特定文字列の文字情報と当該関連文字列の文字情報とに基づき当該特定文字列と当該関連文字列の項目種別を判定する項目種別判定部と、を備えている。
【０００７】
この構成では、レコードから取得された文字列から特定文字列を特定し、前記レコード中において特定文字列と隣接する隣接文字列が特定文字列と関連のある関連文字列として特定され、特定文字列の文字情報と関連文字列の文字情報とに基づき、各々の項目種別が判定される。通常、レコード中では、関連のある項目は隣接して配置されることが多い。そのため、項目種別を判定するに際して、特定文字列の文字情報と特定文字列に関連する関連文字列の文字情報を用いることにより、特定文字列の文字情報のみに基づいて項目種別を判定する場合に比べ、精度の高い項目種別の判定を行うことができる。
【０００８】
また、本発明の項目判定システムの好適な実施形態の一つでは、特定の項目種別に対応する文字情報と当該特定の項目種別に関連する関連項目種別に対応する文字情報とを関連付けて記録する判定基準記録部を備え、前記項目種別判定部は、前記特定文字列の文字情報と関連文字列の文字情報に基づき前記判定基準記録部から前記特定の項目種別と前記関連項目種別とを検索し、当該検索結果に応じて当該特定文字列の項目種別と当該関連文字列の項目種別とを判定する。
【０００９】
さらに、特定の項目種別の文字列と関連項目種別の文字列とは相互に変換が可能な場合がある。例えば、“氏名”と“氏名かな”や“郵便番号”と“住所”である。このような場合には、変換された文字列に基づき関連文字列を特定すると、項目種別の判定精度を向上させることができる。そのため、本発明の項目判定システムの好適な実施形態の一つでは、前記文字情報は、前記文字列を変換することにより得られる変換情報を含み、前記項目種別判定部は、前記特定文字列と前記隣接文字列の前記変換情報とに基づき前記文字列と前記隣接文字列とが関連する文字列であると特定する。
【００１０】
上述した本発明による項目判定システムの技術的特徴は、同様の項目判定プログラムにも適用可能である。例えば、レコードを構成する複数の文字列の各々の項目種別を判定する項目判定システムのための項目判定プログラムにおいて、複数のレコードからなるリスト情報から前記レコードを取得する機能と、前記レコードを各々の文字列に分割する機能と、前記分割された文字列の文字情報を取得する機能と、前記文字列から特定文字列を特定し、前記レコードにおいて当該特定文字列に隣接する文字列である隣接文字列を当該特定文字列に関連する関連文字列として特定すると共に、当該特定文字列の文字情報と当該関連文字列の文字情報とに基づき当該特定文字列と当該関連文字列の項目種別を判定する項目種別判定機能と、をコンピュータに実現する。当然ながら、このような項目判定プログラムも上述した項目判定システムで述べた作用効果を得ることができ、さらに上述した付加的技術を組み込むことも可能である。
【発明を実施するための最良の形態】
【００１１】
〔第１実施形態〕
以下、図面を用いて本発明の第１実施形態を説明する。本実施形態における本発明の項目判定システムは、汎用コンピュータでなる端末Ｃにより構成されており、ディスプレイや入力機器（キーボード、マウス等）を備えている。
【００１２】
図１は、本発明の項目判定システムを構成する端末Ｃの機能ブロック図を示している。端末Ｃは、リスト情報Ｌを取得するリスト情報取得部１１、リスト情報取得部１１により取得されたリスト情報Ｌから一のレコードを抽出するレコード抽出部１２、レコード抽出部１２により抽出されたレコードを文字列に分割する文字列分割部１３、文字列分割部１３により分割された各々の文字列の文字情報を取得する文字情報取得部１４、文字情報取得部１４により取得された文字情報に基づき文字列の項目種別を判定する項目種別判定部１５、項目種別判定部１５により判定された項目種別に基づき文字列と項目種別とを関連付けた統合情報を生成する統合情報生成部１６、項目種別の判定基準を記録する判定基準記録部２２を備えている。
【００１３】
通常、リスト情報取得部１１、レコード抽出部１２、文字列分割部１３、文字情報取得部１４、項目種別判定部１５、統合情報生成部１６は、その処理を実行する手段（プログラムやモジュール等）がハードウェアに読み込まれることでその処理が実行されるが、これらをハードウェアとの組み合わせにより構成しても良いし、ロジック等を組み合わせたハードウェアのみで構成しても構わない。
【００１４】
なお、図４に示すように、本発明におけるリスト情報Ｌとは、１以上のレコードＲの集合であり、レコードＲとは複数の文字列Ｓにより構成された情報である。例えば、リスト情報Ｌが住所録の場合には、各人の住所データ群がレコードＲであり、各レコードＲは住所データ群を構成する住所、氏名、電話番号等を表す文字列Ｓから構成されている。以下の説明では、リスト情報Ｌを住所録として説明するが、当然ながら、本発明は、他の情報に対しても適用可能である。
【００１５】
リスト情報取得部１１は、リスト情報Ｌを取得する。元々の情報が、紙等に印字された印刷媒体の場合には、スキャナ等によりデジタル画像データが取得され、公知のＯＣＲにより、文字データとしてのリスト情報Ｌが取得される。また、元々の情報が電子データの場合には、そのままの電子データをリスト情報Ｌとして取得する。前者の場合には、ＯＣＲの有する罫線認識機能により罫線位置が認識され、罫線位置に対応する文字として“，”が用いられる。すなわち、“，”が文字列Ｓに対するセパレータとして使用される。例えば、図２に示す住所録からは、図４に示すような“青空 太郎，あおぞら たろう，532-0003，大阪府・・・１−２，おおさかふ・・・１−２，06-6123-4567\n大空 花子，おおぞら はなこ，100-8915，東京都・・・３−４，とうきょうと・・・３−４，03-3456-7890\n・・・”がリスト情報Ｌとして取得される。なお、同一行の認識文字の最後に“\n”（改行文字）を付加しており、この改行文字はレコードＲのデリミタとして用いられる。取得したリスト情報Ｌは、レコード抽出部１２に送られる。なお、本実施形態では、上述のセパレータを用いるが、これに限定されるものではなく、タブ文字や所定の組み合わせ文字列等、本発明の目的を達する限りにおいて他の文字等を用いることができる。
【００１６】
レコード抽出部１２は、リスト情報取得部１１により取得されたリスト情報Ｌから一のレコードＲを抽出する。上述のように、リスト情報ＬがＯＣＲを用いて取得された場合には、各々のレコードＲは改行文字により区切られているため、レコード抽出部１２はリスト情報Ｌの先頭もしくは改行文字の次の文字から改行文字までを一のレコードとして抽出する。また、リスト情報Ｌが電子データとして取得された場合には、電子データには様々なフォーマットが存在するため、その電子データのフォーマットに従いレコードＲを抽出する。例えば、電子データがＣＳＶ（Comma-Separated Values）形式の場合には、上述同様、リスト情報Ｌの先頭もしくは改行文字の次の文字から改行文字までを一のレコードとして抽出する。抽出したレコードＲは、文字列分割部１３に送られる。
【００１７】
文字列分割部１３は、レコード抽出部１２により抽出された一のレコードＲをセパレータに基づき各々の文字列Ｓに分割する。このとき、各々の文字列Ｓには、レコードＲ中における文字列Ｓの位置を表す項目情報が付加される。
【００１８】
文字情報取得部１４は、公知の手法により、各々の文字列Ｓの文字情報を取得する。なお、本実施形態における文字情報とは、漢字、かな、数字、英字等の文字種別を用いる。この場合には、文字種別毎に文字コードの範囲が特定できるため、文字コードに基づき文字種別を取得することができる。文字情報取得部１４は、文字列Ｓ、文字列Ｓの項目情報および文字列Ｓの文字情報を項目種別判定部１５に送る。
【００１９】
項目種別判定部１５は、文字情報取得部１４から取得した文字列Ｓから特定文字列を特定し、レコードＲ中においてその特定文字列に隣接する文字列（以下、隣接文字列と称する）を特定文字列に関連する関連文字列として特定する。さらに、特定文字列の文字情報、関連文字列の文字情報および判定基準記録部２２に記録されている判定基準に基づき、特定文字列および関連文字列の項目種別を判定する。判定結果は、文字列Ｓと共に統合情報生成部１６に送られる。
【００２０】
統合情報生成部１６は、文字列Ｓとその項目種別に基づき統合情報を生成する。統合情報とは、文字列Ｓとその文字列の項目種別が関連付けられた情報の総称である。
【００２１】
以下、図３のフローチャートを用いて本発明の項目判定システムの処理の流れを説明する。なお、本実施形態では、図２に示す住所録の項目種別を判定するものとし、項目種別は、氏名、氏名ふりがな、郵便番号、住所、住所ふりがな、電話番号とする。
【００２２】
まず、リスト情報取得部１１は、リスト情報Ｌを取得する（＃０１）。図２の住所録が紙に印字されているとすると、操作者は、スキャナ（図示せず）に住所録が印字された用紙を載置した後、端末Ｃを操作し、デジタル画像データを取得する。取得されたデジタル画像データは、公知のＯＣＲ技術により文字データに変換される。このとき、ＯＣＲの機能により、図２の住所録中に存在する罫線が認識され、認識結果中では文字データ“，”として表される（図４上段参照）。なお、この“，”は以降の処理において、文字列Ｓのセパレータとして利用される。また、同一行に存在する文字の認識結果である文字データの後ろには改行文字“\n”が挿入される。このようにして取得されたリスト情報Ｌは、レコード抽出部１２に送られる。
【００２３】
リスト情報Ｌを取得したレコード抽出部１２は、リスト情報Ｌの構造に基づき、一のレコードＲを抽出する（＃０２）。本実施形態では、上述の処理により、改行文字“\n”がレコードＲのデリミタとして機能している。したがって、レコード抽出部１２は、リスト情報Ｌの先頭もしくは前回のレコードＲの抽出処理後の残りのデータの先頭から改行文字“\n”までをレコードＲとして抽出する。具体的には、１回目のレコード抽出では、“青空 太郎，あおぞら たろう，532-0003，大阪府・・・１−２，おおさかふ・・・１−２，06-6123-4567”が抽出され、２回目のレコードでは“大空 花子，おおぞら はなこ，100-8915，東京都・・・３−４，とうきょうと・・・３−４，03-3456-7890”が抽出される（図４の中段参照）。このようにして抽出された一のレコードＲは、文字列分割部１３に送られる。
【００２４】
文字列分割部１３は、レコード抽出部１２から取得したレコードＲを文字列Ｓに分割する（＃０３）。上述したように、本実施形態では、“，”が文字列Ｓのセパレータとして用いられているため、文字列分割部１３は、セパレータ“，”に基づきレコードＲを文字列Ｓに分割する（図４の下段参照）。このとき、文字列分割部１３は、分割した文字列Ｓに対して、項目情報を付加する。本実施形態における項目情報とは、文字列ＳがレコードＲ中において何番目に位置するかを表す情報であり、例えば、文字列“青空 太郎”の項目情報は１、文字列“03-3456-7890”の項目情報は６となる。このようにして得られた文字列Ｓおよび項目情報は、文字情報取得部１４に送られる。なお、以下の説明では、項目情報ｉを持つ文字列Ｓを文字列Ｓi（ｉ＝１，２，・・・，６）と表記する。１番目のレコードＲに対する処理ループでは、Ｓ1＝“青空 太郎”、Ｓ2＝“あおぞら たろう”、Ｓ3＝“532-0003”、Ｓ4＝“大阪府・・・１−２”、Ｓ5＝“おおさかふ・・・１−２”、Ｓ6＝“06-6123-4567”となる。
【００２５】
文字列分割部１３から文字列Ｓiおよびそれらの項目情報を取得した文字情報取得部１４は、公知の手法により、各々の文字列Ｓiの文字情報を取得し（＃０４）、文字列Ｓiおよび項目情報と共に項目種別判定部１５に送る。なお、本実施形態では、文字情報として文字種別を用い、文字列Ｓiの文字情報をＩiとすると、上述の例では、Ｉ1＝“漢字”、Ｉ2＝“かな”、Ｉ3＝“数字”、Ｉ4＝“漢字＋数字”、Ｉ5＝“かな＋数字”、Ｉ6＝“数字”となる。
【００２６】
項目種別判定部１５では、まず一の文字列Ｓを特定文字列として特定する（＃０５）。本実施形態では、未処理の文字列Ｓのうち最も小さな項目情報を持つ文字列Ｓを特定文字列とする。すなわち、最初の処理ループでは、文字列Ｓ1＝“青空 太郎”が特定文字列として特定される。
【００２７】
次に、項目種別判定部１５は、隣接文字列を特定文字列に関連する文字列Ｓ（以下、関連文字列と称する）として特定する（＃０６）。上述の例では、文字列Ｓ2＝“あおぞら たろう”が関連文字列として特定される。なお、本実施形態では、隣接とは、完全に隣り合うことを指すが、所定間隔離れている場合にも隣接として扱って構わない。
【００２８】
さらに、項目種別判定部１５は、特定文字列の文字情報、関連文字列の文字情報および判定基準記録部２２に記録されている判定基準に基づき、特定文字列の項目種別および関連文字列の項目種別を判定する（＃０７）。判定基準記録部２２には、特定の項目種別に対応する文字情報とその特定の項目種別に関連する項目種別（以下、関連項目種別と称する）に対応する文字情報とが記録されている。ここで、関連とは、特定の項目種別の文字列と関連項目種別の文字列とがレコードＲ中において隣接する可能性が高い関係を言う。例えば、氏名と氏名ふりがな、郵便番号と住所等の関係である。ここで、判定基準記録部２２に図５に示す判定基準が記録されているとする。上述の例では、特定文字列の文字情報が“漢字”、関連文字列の文字情報が“かな”として取得されているため、これらの文字情報を用いて判定基準を検索すると、第１文字情報が“漢字”、第２文字情報が“かな”である判定基準として、“氏名”−“氏名ふりがな”の関係が検索される。したがって、特定文字列の項目種別は“氏名”、関連文字列の項目種別は“氏名かな”と判定される。
【００２９】
次に、項目種別判定部１５は、未処理の文字列Ｓが存在するか否かを判定する（＃０８）。未処理の文字列が存在する場合（＃０８のYes分岐）には、次の特定文字列の特定を行う（＃０５）。上述の例の場合には、文字列Ｓ1およびＳ2の項目種別の判定が終了しているため、特定文字列として文字列Ｓ3、関連文字列として文字列Ｓ4が特定される（＃０６、＃０７）。この場合の文字情報Ｉ3およびＩ4は、それぞれ“数字”および“漢字＋数字”であり、特定文字列および関連文字列の項目種別は、それぞれ“郵便番号”および“住所”と判定される。
【００３０】
上述の処理は、未処理の文字列Ｓが存在しなくなるまで（＃０８のNo分岐）繰り返される。なお、上述の処理では、特定文字列とも関連文字列とも特定されていない文字列を次の特定文字列としたが、全ての文字列Ｓが必ず一度は特定文字列として特定されるような構成としても構わない。これらの処理により、文字列Ｓ1からＳ5までの項目種別が“氏名”、“氏名かな”、“郵便番号”、“住所”、“住所かな”として特定される。特定された項目種別は、文字列Ｓと共に統合情報生成部１６に送られる。
【００３１】
一のレコードＲに対しての項目判定処理が完了すると、未処理のレコードＲが存在するか否かが判定され（＃０９）、未処理レコードＲが存在する場合（＃０９のYes分岐）には、次のレコードＲが取得される（＃０２）。上述の例では、レコードＲとして“大空 花子，おおぞら はなこ，987-6543，東京都・・・３−４，とうきょうと・・・３−４，03-3456-7890”が取得され、上述の処理が実行される。
【００３２】
一方、全てのレコードＲの処理が完了すると（＃０９のNo分岐）、統合情報生成部１６は統合情報を生成する。
【００３３】
〔第２実施形態〕
次に、本発明による項目判定システムの第２実施形態を説明する。図６は、本実施形態における機能ブロック図であり、文字情報の定義を記録する文字情報記録部２１を備えている点で第１実施形態と異なっている。
【００３４】
本実施形態における文字情報記録部２１には、文字情報の定義として文字種別条件情報が記録されており、文字情報取得部１４は、文字種別条件情報に基づき文字列Ｓの文字情報を取得する。本実施形態における文字種別条件情報とは、上述の文字種別をさらに細分化するための条件である。例えば、人名漢字の文字コードが文字種別条件情報として記録されており、公知の手法により、文字列Ｓの文字の文字情報（文字種別）が漢字として取得された際に、さらに文字種別条件情報に基づき、人名漢字か否かの情報を文字情報に含めることができる。なお、文字種別の細分化は、人名漢字に限定されるものではなく、漢字を漢数字等に、その他・外国語を英語、フランス語、韓国語、ロシア語、アラビア語等の各言語文字や記号を数学記号、音楽記号（♯、♭等）、情報通信関連文字（＠等）等に細分化することもでる。
【００３５】
次に、本実施形態の処理の流れを説明するが、第１実施形態と同様の処理の説明は省略する。まず、＃０１から＃０３までの処理により一のレコードＲが取得され、文字列Ｓiに分割される。
【００３６】
文字列Ｓiは、文字情報取得部１４に送られ、第１実施形態と同様に、公知の方法により文字種別が判定され、文字情報として取得される。さらに、文字情報取得部１４は、文字情報記録部２１に記録されている文字種別条件情報に基づき、詳細な文字種別を判定し、文字情報に付加する（＃０４）。例えば、文字列Ｓ1＝“青空 太郎”は、人名漢字“郎”を含んでいるため、文字列Ｓ1の文字情報は、“人名漢字を含む漢字”として取得される。このようにして取得された文字情報は、文字列Ｓiと共に項目種別判定部１５に送られる。
【００３７】
文字列Ｓiと文字情報を取得した項目種別判定部１５は、判定基準記録部２２に記録されている判定基準に基づき、各文字列Ｓiの項目種別を判定する（＃０５〜＃０７）。上述のように、本実施形態における文字情報は、第１実施形態における文字情報に比べて細分化されている。したがって、本実施形態で用いる判定基準の文字情報も細分化されている。例えば、図５の１番目の判定基準は、第１文字情報が“漢字”に代えて“人名漢字を含む漢字”となる。このとき、特定文字列としてＳ1＝“青空 太郎”、関連文字列としてＳ2＝“あおぞら たろう”が特定されているとすると、上述のようにＳ1の文字情報は“人名漢字を含む漢字”であり、Ｓ2の文字情報は“かな”であるため、これらの文字種別は、“氏名”と“氏名かな”であると判定される。
【００３８】
本実施形態では、第１実施形態に比べて細分化した文字種別を文字情報として用い、細分化した文字種別に応じた判定基準を用いることにより、より的確に文字種別を判定することができる。
【００３９】
〔第３実施形態〕
次に、図面を用いて本発明による項目判定システムの第３実施形態を説明する。本実施形態における機能ブロック図は、第１実施形態と同様であるため、詳細な説明は省略する。なお、本実施形態における文字情報は、文字数であり、判定基準記録部２２には、図７に示すような判定基準が記録されている。
【００４０】
次に、図３のフローチャートを用いて、本実施形態における処理の流れを説明するが、第１実施形態と同様の処理の説明は省略する。
【００４１】
まず、＃０１から＃０３までの処理により一のレコードＲが取得され、文字列Ｓiに分割される。１回目の処理ループの場合のレコードＲは“青空 太郎，あおぞら たろう，532-0003，大阪府・・・１−２，おおさかふ・・・１−２，06-6123-4567”であり、分割された文字列は、Ｓ1＝“青空 太郎”、Ｓ2＝“あおぞら たろう”、Ｓ3＝“532-0003”、Ｓ4＝“大阪府・・・１−２”、Ｓ5＝“おおさかふ・・・１−２”、Ｓ6＝“06-6123-4567”である。
【００４２】
文字列分割部１３から上述の文字列を取得した文字情報取得部１４は、各々の文字列の文字情報を取得する（＃０４）。上述したように、本実施形態では文字情報として文字数を用いる。そのため、文字情報取得部１４は、公知の方法により各文字列Ｓiの文字数を計数する。このとき、空白やハイフン等の記号は計数されない。上述の例では、Ｉ1＝４、Ｉ2＝７、Ｉ3＝７、Ｉ4＝１５、Ｉ5＝２７、Ｉ6＝１０となる。なお、本実施形態では、空白やハイフン等の記号は計数しないが、計数する構成としてもよく、その場合には、判定基準を適切に修正しておけばよい。
【００４３】
次に、＃０５および＃０６の処理により、特定文字列としてＳ1＝“青空 太郎”、関連文字列としてＳ2＝“あおぞら たろう”が特定される。さらに、項目種別判定部１５は、特定文字列の文字情報Ｉ1＝４および関連文字列の文字情報Ｉ1＝７に基づき、判定基準記録部２２を検索することにより、第１行目の判定基準を取得する。したがって、文字列Ｓ1＝“青空 太郎”の項目種別は“氏名”、文字列Ｓ2＝“あおぞら たろう”の項目種別は“氏名かな”と判定される（＃０７）。
【００４４】
未処理文字列が存在する場合（＃０８のYes分岐）には、処理は＃０５に戻り、上述の処理が行われ、特定文字列がＳ3＝“532-0003”、関連文字列がＳ4＝“大阪府・・・１−２”と特定された際には、文字列Ｓ3＝“532-0003”の項目種別は“郵便番号”、文字列Ｓ4＝“大阪府・・・１−２”の項目種別は“住所”と判定される。
【００４５】
全文字列Ｓの処理が完了すると（＃０８のNo分岐）、未処理レコードの有無が判定され（＃０９）、未処理レコードが存在する場合（＃０９のYes分岐）には、処理が＃０２に戻り、上述の処理が繰り返される。
【００４６】
〔第４実施形態〕
次に、本発明による項目判定システムの第４実施形態を説明する。本実施形態における機能部は第２実施形態と同様であるが、文字情報が変換情報である点において第２実施形態と異なっている。なお、本実施形態における変換情報とは、所定の変換ルールに基づき変換された文字列とそのときの変換種別の対であり、文字情報記録部２１には所定の変換ルールが記録されている。本実施例では、図８に示すような、漢字−かな、住所−郵便番号、住所−電話番号の相互の変換ルールを用いているが、他の変換ルールを用いても構わず、判定する項目種別により適宜変更可能である。また、本実施形態における隣接とは、レコードＲにおいて完全に隣り合う場合だけでなく、所定範囲離れている場合も含んでいる。
【００４７】
以下に、図３のフローチャートに基づいて本実施形態における処理の流れを説明する。１回目の処理ループでは、＃０１から＃０３までの処理により、Ｓ1＝“青空 太郎”、Ｓ2＝“あおぞら たろう”、Ｓ3＝“532-0003”、Ｓ4＝“大阪府・・・１−２”、Ｓ5＝“おおさかふ・・・１−２”、Ｓ6＝“06-6123-4567”が得られる。
【００４８】
文字情報取得部１４は、文字情報記録部２１に記録されている所定の変換ルールに基づき、各々の文字列Ｓiの文字情報を取得する。例えば、文字列Ｓ1＝“青空 太郎”の場合には、被変換文字列を“青空”および“太郎”として、図８の変換ルールを検索すると、変換文字列“あおぞら”および“たろう”が得られ、そのときの変換種別は“氏名→氏名かな”である。したがって、文字列Ｓ1の文字情報Ｉ1は、変換文字列と変換種別の対［“あおぞら たろう”，“氏名→氏名かな”］として得られる。同様に、文字列Ｓ4＝“大阪府・・・１−２”の場合には、“532-0003”および“おおさかふ・・・１−２”が文字情報として取得され、そのときの変換種別はそれぞれ“住所→郵便番号”、“住所→住所かな”である。なお、文字列Ｓ4のように、複数の変換文字列が得られる場合には、得られた変換文字列の集合を文字情報とし、以下の説明では“｛”および“｝”により集合を表す。なお、文字情報記録部２１を用いずに、文字変換ソフトウェアを用いて被変換文字列を変換し、その変換結果に基づき、変換種別を取得する構成としても構わない。
【００４９】
上述の処理により取得された文字情報Ｉ1＝［“あおぞら たろう”，“氏名→氏名かな”］、Ｉ2＝［“青空 太郎”，“氏名かな→氏名”］、Ｉ3＝［“大阪府・・・”，“郵便番号→住所”］、Ｉ4＝｛［“532-0003”，“住所→郵便番号”］，［“おおさかふ・・・１−２”，“住所→住所かな”］｝、Ｉ5＝［“大阪府・・・１−２”，“住所かな→住所”］、Ｉ6＝［“大阪府”，“電話番号→住所”］は、項目情報判定部１４に送られる。
【００５０】
上述の文字情報Ｉiを取得した項目種別判定部１５は、特定文字列を特定し（＃０５）、特定文字列と隣接文字列の文字情報に基づき関連文字列を特定する（＃０６）。具体的には、特定文字列の項目情報との差が所定範囲以内の項目情報を持つ隣接文字列のうち、特定文字列と一致する変換情報（文字情報）を持つものが関連文字列として特定される。なお、関連文字の特定は、一致する場合だけでなく、変換情報が含まれる場合や所定の文字数以上が一致する等を条件として行っても構わない。
【００５１】
なお、文字情報が集合の場合には、集合の各要素に対して比較が行われる。また、関連文字列を特定する際に、特定文字列の変換情報（文字情報）と隣接文字列とを比較しても構わない。
【００５２】
その後、項目種別判定部１５は、特定文字列の文字情報と関連文字列の文字情報とに基づき、特定文字列および関連文字列の項目種別を判定する（＃０７）。具体的には、特定文字列の文字情報の変換文字列と、関連文字列が比較され、一致する場合には、その文字情報の変換種別に基づき特定文字列の項目種別と関連文字列の項目種別が判定される。例えば、特定文字列がＳ1＝“青空 太郎”、関連文字列がＳ2＝“あおぞら たろう”として特定された場合には、文字情報Ｉ1の変換文字列“あおぞら たろう”と関連文字列Ｓ2とが比較され、これらは一致する。このとき、文字情報Ｉ1の変換種別“氏名→氏名かな”に基づき、文字列Ｓ1の項目種別は“氏名”、文字列Ｓ2の項目種別は“氏名かな”として判定される。
【００５３】
未処理文字列が存在する場合（＃０８のYes分岐）には、処理は＃０５に戻り、上述の処理が行われる。全文字列Ｓに対する処理が完了すると、各々の文字列Ｓiの項目種別はそれぞれ、“氏名”、“氏名かな”、“郵便番号”、“住所”、“住所かな”、“電話番号”と判定される。
【００５４】
全文字列Ｓの処理が完了すると（＃０８のNo分岐）、未処理レコードの有無が判定され（＃０９）、未処理レコードが存在する場合（＃０９のYes分岐）には、処理が＃０２に戻り、上述の処理が繰り返される。
【００５５】
〔第５実施形態〕
次に、図面を用いて本発明による項目判定システムの第５実施形態を説明する。図９は本実施形態における機能ブロックであり、項目種別判定部１５が、さらに、項目種別を予測する項目種別予測部１５ａおよび、予測結果判定部１５ｂを備えている点において第２実施形態と異なっている。以下の説明では、第２実施形態と同様の機能部の説明は省略する。
【００５６】
また、本実施形態の判定基準記録部２２には、図１０の第１判定基準および図１１に示す第２判定基準が記録されている。第１判定基準は、項目種別予測部１５ａが文字情報に基づき項目種別を予測するために用いる判定基準であり、第２判定基準は、予測結果判定部１５ｂが、項目種別予測部１５ａによる予測の適否を判定するための基準である。
【００５７】
項目種別予測部１５ａは、特定文字列の文字情報、関連文字列の文字情報および第１判定基準に基づき、特定文字列の項目種別と関連文字列の項目種別の予測を行う。なお、本実施形態では文字情報として、文字種別および文字数の対を用いているが、これに限定されるものではなく、上述した文字情報の一つ又はそれらの任意の組み合わせ、および他の文字情報を用いても構わない。
【００５８】
予測結果判定部１５ｂは、文字情報および第２判定基準に基づき、項目種別予測部１５ａにより予測された項目種別の適否を判定する。なお、項目種別予測部１５ａによる項目種別の予測は、一の文字列に対して複数の項目種別を予測する構成としてもよく、この場合には、予測結果判定部１５ｂが、一の項目種別を判定結果とする。
【００５９】
以下に、本実施形態における処理の流れを説明する。全体の処理の流れは、図３に示した処理の流れと同様であり、図３における＃０７の項目種別判定処理が異なっているため、図１２のフローチャートを用いて、項目種別判定処理の流れを説明する。
【００６０】
項目種別判定部１５は、文字列分割部１３により分割された文字列Ｓiおよび文字情報取得部１４により取得された文字情報Ｉiを取得する。例えば、文字列Ｓ1＝“青空 太郎”、Ｓ2＝“あおぞら たろう”、Ｓ3＝“532-0003”、Ｓ4＝“大阪府・・・１−２”、Ｓ5＝“おおさかふ・・・１−２”、Ｓ6＝“06-6123-4567”、文字情報Ｉ1＝［“漢字”，４］、Ｉ2＝［“かな”，７］、Ｉ3＝［“数字”，７］、Ｉ4＝［“漢字＋数字”，１５］、Ｉ5＝［“かな＋数字”，２７］、Ｉ6＝［“数字”，１０］が取得される。また、項目種別判定部１５は、特定文字列と関連文字列を特定し、これらを項目種別予測部１５ａに送る。例えば、特定文字列として文字列Ｓ1＝“青空 太郎”、関連文字列として文字列Ｓ2＝“あおぞら たろう”およびこれらの文字情報Ｉ1、Ｉ2が、項目種別予測部１５ａに渡される。
【００６１】
特定文字列および関連文字列を取得した項目種別予測部１５ａは、特定文字列の文字情報および関連文字列の文字情報に基づき、第１判定基準を検索する（＃２１）。具体的には、第１文字情報と特定文字列の文字情報とが一致し、第２文字情報と関連文字列の文字情報とが一致する判定基準を検索する。該当する判定基準が検索されない場合（＃２２のNo分岐）には、処理は＃０５に戻り、新たな特定文字列が特定される。なお、判定基準が検索されない場合に、その旨を記録または管理者へ通知しても構わない。
【００６２】
一方、判定基準が検索された場合（＃２２のYes分岐）には、予測結果が予測結果判定部１５ｂに送られる。上述の例では、特定文字列の文字種別（文字情報）が“漢字”、関連文字列の文字種別（文字情報）が“かな”であるため、［“氏名”，“氏名かな”］、［“住所”，“住所かな”］の２組の項目種別が検索される。したがって、特定文字列の項目種別は“氏名”もしくは“住所”、関連文字列の項目種別は“氏名かな”もしくは“住所かな”と予測される（＃２３）。
【００６３】
予測結果を取得した予測結果判定部１５ｂは、項目種別予測部１５ａの予測結果に基づき、第２判定基準から対応する判定基準を抽出し、文字列Ｓiもしくは文字情報Ｉiがその判定基準を充足するか否かが判定される（＃２４、＃２５）。上述の例では、特定文字列の項目種別は、“氏名”もしくは“住所”と予測されているため、予測結果判定部１５ｂは、第２判定基準から項目種別が“氏名”もしくは“住所”である判定基準を検索する。この場合には、判定基準“６文字以下”および“１０文字以上２０文字以下”が検索される。予測結果判定部１５ｂは、この検索された判定基準と、特定文字列の文字数（文字情報）である“４”とを比較すると、判定基準“６文字以下”を充足する（＃２４のYes分岐）ため、特定文字列の項目種別は“氏名”であると判定する。
【００６４】
また、関連文字列の項目種別は、“氏名かな”もしくは“住所かな”と予測されているが、特定文字列の項目種別は“氏名”であると判定されているため、予測結果判定部１５ｂは、第２判定基準から項目種別が“氏名かな”である判定基準を検索する。この場合には、判定基準“５文字以上”が検索される。予測結果判定部１５ｂは、この判定基準と関連文字列の文字数（文字情報）である“７”とを比較すると、判定基準を充足する（＃２５のYes分岐）ため、関連文字列の項目種別は“氏名かな”であると判定する。
【００６５】
したがって、特定文字列の項目種別は“氏名”、関連文字列の項目種別は“氏名かな”として確定される。
【００６６】
一方、特定文字列または特定文字列の文字情報が検索された判定基準を充足しない場合（＃２４のNo分岐）もしくは関連文字列または関連文字列の文字情報が検索された判定基準を充足しない場合（＃２５のNo分岐）には、項目種別予測部１５ａの予測は棄却される（＃２７）。このとき、予測が棄却された旨の情報を記録又は管理者へ通知する構成としても構わない。
【００６７】
上述の説明では、第２判定基準の充足を判定する際に、文字列Ｓiの文字情報を用いていたが、判定基準により文字列Ｓiを用いることも可能である。例えば、郵便番号の場合には、数字の前に“〒”（郵便マーク）が記載されている場合があるため、文字列Ｓiにこの郵便マークが含まれているか否かを判定基準とすることができる。
【００６８】
〔第６実施形態〕
次に、図面を用いて本発明による項目判定システムの第６実施形態を説明する。図１３は本実施形態における機能ブロックであり、予測結果判定部１５ｂに代えて文字列を所定の変換ルールに基づき変換する文字列変換部１５ｃを備えている点において第５実施形態と異なっている。なお、本実施形態の文字情報記録部２１には、図８の変換ルールが記録されている。
【００６９】
文字列変換部１５ｃは、文字列を項目種別予測部１５ａの予測結果に応じた項目種別の文字列に変換する。文字列の変換に際して、文字列変換部１５ｃは、文字情報記録部２１の変換ルールを用いる。
【００７０】
以下に、本実施形態における処理の流れを説明する。全体の処理の流れは、図３に示した処理の流れと同様であり、図３における＃０７の項目種別判定処理が異なっているため、図１４のフローチャートを用いて、項目種別判定処理の流れを説明する。また、＃３１から＃３３の処理は＃２１から＃２３の処理と同様であるので、説明は省略する。
【００７１】
まず、特定文字列がＳ１＝“青空 太郎”、関連文字列がＳ２＝“あおぞら たろう”として特定された場合には、特定文字列の項目種別は“氏名”もしくは“住所”、関連文字列の項目種別は“氏名かな”もしくは“住所かな”と予測される（＃３１〜＃３３）。特定文字列、関連文字列およびこれらに対する予測結果が文字列変換部１５ｃに送られる。
【００７２】
文字列変換部１５ｃは、まず特定文字列に対する予測結果に基づき、特定文字列を変換し（＃３４）、項目種別判定部１５は、変換された文字列と関連文字列とを比較することにより、項目種別を仮判定する（＃３５）。また、文字列変換部１５ｃは、関連文字列に対する予測結果に基づき、関連文字列を変換し（＃３６）、項目種別判定部１５は、変換された文字列と特定文字列とを比較することにより、項目種別を仮判定する（＃３７）。最後に、項目種別判定部１５は、２つの仮判定のうち、一致する結果を最終的な項目種別の判定結果とする（＃３８）。なお、仮判定の結果が一致しない場合には、その旨を記録又は管理者へ通知する構成としても構わない。
【００７３】
上述の例では、特定文字列の項目種別は“氏名”もしくは“住所”と予測されているため、文字列変換部１５ｃは、文字情報記録部２１から対応するルールとして、“氏名”から“氏名かな”への変換ルールを取得し、その変換ルールにしたがい特定文字列を変換することにより、文字列“あおぞら たろう”を取得する。この変換された文字列は関連文字列と一致するため、特定文字列の項目種別は“氏名”、関連文字列の項目種別は“氏名かな”であると仮判定される。なお、特定文字列を住所とした場合の変換ルールは存在しないため、特定文字列の項目種別は“住所”ではないと判定される。
【００７４】
次に、文字列変換部１５ｃは、関連文字列に対しても上述と同様の処理を行うと、変換された文字列として“青空 太郎”が取得され、特定文字列と一致するため、関連文字列の項目種別は“氏名かな”、特定文字列の項目種別は“氏名”と仮判定される。したがって、２つの仮判定結果が一致するため、特定文字列の項目種別は“氏名”、関連文字列の項目種別は“氏名かな”と判定される。
【００７５】
〔別実施形態〕
（１）上述の判定基準として正規表現を用いることも可能である。例えば、住所の判定基準として、“/.*[都道府県].*[市区郡].*/”を用いることができる。この例では、任意に文字列の後に“都道府県”のいずれかの文字があり、その後に任意の文字列があり、さらに“市区郡”のいずれかの文字と任意の文字列が後続する文字列を表している。このような正規表現を用いることにより、判定基準の表現に柔軟性が増し、好適である。なお、正規表現は、上述の実施形態の判定基準に代えてまたは共に用いても構わない。
【００７６】
（２）上述の第２実施形態では、文字情報記録部２１に文字コードに基づく文字種別条件情報を記録しておき、文字情報取得部１４は、文字種別条件情報に基づき各々の文字に対する細分化した各文字種別を取得したが、図１５に示す文字種別条件情報を用いて文字列Ｓに対しての細分化した文字種別を取得することもできる。例えば、文字列Ｓ＝“大阪府大阪市・・・”であれば、文字数が３０文字以内であり、正規表現“/.*[都道府県].*[市区郡].*/”にマッチするため、文字列Ｓの文字種別は住所漢字として取得される。なお、本実施形態の場合には、図５の判定基準において、文字情報（文字種別）が文字種別条件情報における文字種別に置換された判定基準が用いられる。
【００７７】
（３）上述の実施形態では、スタンドアロン型により本発明の項目判定システムを構築していたが、クライアント−サーバ型等、他の構成を用いることも可能である。クライアント−サーバ型の場合には、各機能部の配置形態は種々可能である。例えば、リスト情報取得部１１以外の機能部をサーバに配置する、リスト情報取得部１１およびレコード取得部１２以外の機能部をサーバに設置する等、サーバやネットワークの負荷等に応じて適宜変更可能である。また、統合情報として、表形式の電子データ等を用いた場合には、その電子データはサーバから端末Ｃに送信される。
【図面の簡単な説明】
【００７８】
【図１】本発明による項目判定システムの第１実施形態における機能ブロック図
【図２】本発明による項目判定システムで用いられる住所録の例
【図３】本発明による項目判定システムの第１実施形態の処理の流れを表すフローチャート
【図４】本発明による項目判定システムの実施形態におけるリスト情報からレコードへの分割およびレコードから文字列への分割を模式的に表す図
【図５】本発明による項目判定システムの第１実施形態における判定基準の例
【図６】本発明による項目判定システムの第２実施形態における機能ブロック図
【図７】本発明による項目判定システムの第３実施形態における判定基準の例
【図８】本発明による項目判定システムの第４実施形態における変換ルールの例
【図９】本発明による項目判定システムの第５実施形態における機能ブロック図
【図１０】本発明による項目判定システムの第５実施形態における第１判定基準の例
【図１１】本発明による項目判定システムの第５実施形態における第２判定基準の例
【図１２】本発明による項目判定システムの第５実施形態の処理の流れを表すフローチャート
【図１３】本発明による項目判定システムの第６実施形態における機能ブロック図
【図１４】本発明による項目判定システムの第６実施形態の処理の流れを表すフローチャート
【図１５】本発明による項目判定システムの別実施形態における文字種別条件情報の例
【符号の説明】
【００７９】
Ｃ：端末
１１：リスト情報取得部
１２：レコード抽出部
１３：文字列分割部
１４：文字情報取得部
１５：項目種別判定部
１６：統合情報生成部
２１：文字情報記録部
２２：判定基準記録部
【特許請求の範囲】
【請求項１】
レコードを構成する複数の文字列の各々の項目種別を判定する項目判定システムにおいて、
複数のレコードからなるリスト情報から前記レコードを取得するレコード抽出部と、
前記レコードを各々の文字列に分割する文字列分割部と、
前記分割された文字列の文字情報を取得する文字情報取得部と、
前記文字列から特定文字列を特定し、前記レコードにおいて当該特定文字列に隣接する文字列である隣接文字列を当該特定文字列に関連する関連文字列として特定すると共に、当該特定文字列の文字情報と当該関連文字列の文字情報とに基づき当該特定文字列と当該関連文字列の項目種別を判定する項目種別判定部と、を備えたことを特徴とする項目判定システム。
【請求項２】
特定の項目種別に対応する文字情報と当該特定の項目種別に関連する関連項目種別に対応する文字情報とを関連付けて記録する判定基準記録部を備え、
前記項目種別判定部は、前記特定文字列の文字情報と関連文字列の文字情報に基づき前記判定基準記録部から前記特定の項目種別と前記関連項目種別とを検索し、当該検索結果に応じて当該特定文字列の項目種別と当該関連文字列の項目種別とを判定することを特徴とする請求項１記載の項目判定システム。
【請求項３】
前記文字情報は、前記文字列を変換することにより得られる変換情報を含み、
前記項目種別判定部は、前記特定文字列と前記隣接文字列の前記変換情報とに基づき前記文字列と前記隣接文字列とが関連する文字列であると特定することを特徴とする請求項１記載の項目判定システム。
【請求項４】
レコードを構成する複数の文字列の各々の項目種別を判定する項目判定システムのための項目判定プログラムにおいて、
複数のレコードからなるリスト情報から前記レコードを取得する機能と、
前記レコードを各々の文字列に分割する機能と、
前記分割された文字列の文字情報を取得する機能と、
前記文字列から特定文字列を特定し、前記レコードにおいて当該特定文字列に隣接する文字列である隣接文字列を当該特定文字列に関連する関連文字列として特定すると共に、当該特定文字列の文字情報と当該関連文字列の文字情報とに基づき当該特定文字列と当該関連文字列の項目種別を判定する項目種別判定機能と、をコンピュータに実現させる項目判定プログラム。
【請求項１】
レコードを構成する複数の文字列の各々の項目種別を判定する項目判定システムにおいて、
複数のレコードからなるリスト情報から前記レコードを取得するレコード抽出部と、
前記レコードを各々の文字列に分割する文字列分割部と、
前記分割された文字列の文字情報を取得する文字情報取得部と、
前記文字列から特定文字列を特定し、前記レコードにおいて当該特定文字列に隣接する文字列である隣接文字列を当該特定文字列に関連する関連文字列として特定すると共に、当該特定文字列の文字情報と当該関連文字列の文字情報とに基づき当該特定文字列と当該関連文字列の項目種別を判定する項目種別判定部と、を備えたことを特徴とする項目判定システム。
【請求項２】
特定の項目種別に対応する文字情報と当該特定の項目種別に関連する関連項目種別に対応する文字情報とを関連付けて記録する判定基準記録部を備え、
前記項目種別判定部は、前記特定文字列の文字情報と関連文字列の文字情報に基づき前記判定基準記録部から前記特定の項目種別と前記関連項目種別とを検索し、当該検索結果に応じて当該特定文字列の項目種別と当該関連文字列の項目種別とを判定することを特徴とする請求項１記載の項目判定システム。
【請求項３】
前記文字情報は、前記文字列を変換することにより得られる変換情報を含み、
前記項目種別判定部は、前記特定文字列と前記隣接文字列の前記変換情報とに基づき前記文字列と前記隣接文字列とが関連する文字列であると特定することを特徴とする請求項１記載の項目判定システム。
【請求項４】
レコードを構成する複数の文字列の各々の項目種別を判定する項目判定システムのための項目判定プログラムにおいて、
複数のレコードからなるリスト情報から前記レコードを取得する機能と、
前記レコードを各々の文字列に分割する機能と、
前記分割された文字列の文字情報を取得する機能と、
前記文字列から特定文字列を特定し、前記レコードにおいて当該特定文字列に隣接する文字列である隣接文字列を当該特定文字列に関連する関連文字列として特定すると共に、当該特定文字列の文字情報と当該関連文字列の文字情報とに基づき当該特定文字列と当該関連文字列の項目種別を判定する項目種別判定機能と、をコンピュータに実現させる項目判定プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１０−３０００（Ｐ２０１０−３０００Ａ）
【公開日】平成２２年１月７日（２０１０．１．７）
【国際特許分類】
【出願番号】特願２００８−１５９４１９（Ｐ２００８−１５９４１９）
【出願日】平成２０年６月１８日（２００８．６．１８）
【特許番号】特許第４２６６２４０号（Ｐ４２６６２４０）
【特許公報発行日】平成２１年５月２０日（２００９．５．２０）
【出願人】（５９９１０８２４２）Ｓｋｙ株式会社 (257)
【Ｆターム（参考）】
【公開日】平成２２年１月７日（２０１０．１．７）
【国際特許分類】
【出願日】平成２０年６月１８日（２００８．６．１８）
【特許番号】特許第４２６６２４０号（Ｐ４２６６２４０）
【特許公報発行日】平成２１年５月２０日（２００９．５．２０）
【出願人】（５９９１０８２４２）Ｓｋｙ株式会社 (257)
【Ｆターム（参考）】
[ Back to top ]