JP2005267129A - 文字画像テキスト化システム - Google Patents

Abstract

【課題】
キーボードによる日本語入力ができない人がインターネットを用いたメール送信や掲示板投稿のためのテキスト入力をプライバシー保護とセキュリティを確保しつつ実現する。
【解決手段】
上記課題を解決するために、文書上に記載された文字情報をデジタル画像データに変換し、該デジタル画像データから、オペレータを介して文字情報をテキスト化するシステムにおいて、一つのテキスト化対象フィールド画像を複数に分割する手段と、それぞれの分割されたフィールドの各分割画像を複数のオペレータに配信する手段と、各オペレータは配信された該分割画像を参照して、画像に含まれる文字情報に対応するテキストを入力する手段と、を備えることを特徴とする文字画像テキスト化システムを提供する。
【選択図】 図１

Description

本発明は、インターネットを用いた掲示板又はメールを配信するネットワークシステムに関し、特にＯＣＲ又は人手により文字を入力してテキストにするテキスト化システムに関するものである。

インターネットの普及により、ＷＥＢサイトで掲示板サービスを提供したり、利用者同士のメール配信サービスが盛んに行われている。これらのサービスに対し、キーボードを操作できる人にとっては、物理的な制約を超えて多くの人とのコミュニケーションや情報収集を実現することが可能である。しかし、キーボードの操作が苦手な所謂デジタルデバイドの問題を抱える人にとっては、そのサービスの利用には敷居が高く、サービスがなかなか普及していないのが現状である。

一方、キーボードの操作が苦手な人のために、機械による音声認識や適当な帳票に文字を記入してＯＣＲ（Optical Character Reader、光学文字読取装置）によって文字コードに変換する入力補助が考えられる。しかし、現在の認識精度を考えると、実用的には人間の目視確認が不可欠である。この目視確認と誤認識修正をキーパンチャが行うという方法が考えられる。しかし、メールなど個人のプライバシーを優先したい内容は、例え、キーパンチャとは言え、受信者以外の他人には知られたくないものであり、利用する側にとっては抵抗感がある。

特許文献１では、振込依頼書等の記入項目に対する目視確認のセキュリティ確保という観点から、以下の方法を提示している。ファクシミリ装置で読み取られた帳票のイメージデータは、分割手段によって「口座番号」や「住所」といった複数の領域の部分イメージに分割され、修正手段によってその部分イメージの文字認識が行われて認識結果と部分イメージが表示される。操作員によって確認・修正処理が行われた部分イメージの認識結果は、統合手段によって統合されて元の帳票に対応する帳票データが生成される。

特開２００２−７４２６３号公報

しかし、上記手法を送付メールのテキスト化に適用しようとした場合、入力対象フィールドはタイトルやメッセージとなる。タイトルとメッセージを別々のオペレータに開示したところで、メッセージの内容がオペレータに開示されてしまい、メールの送信者にとっては内容を全てオペレータに把握されることに等しいと感じる。

本発明では、特に、入力対象の文章に関するプライバシーやセキュリティを確保しつつ、オペレータの目視確認と修正が可能になる方法を提供することを目的としている。

また、掲示板投稿やメール送信には一般にテキストである文字コードが使用される。しかし、活字フォントではあじけないとか、人の手書きの温かみが伝わらないなどの問題点があり、手紙と同様に手書き文字をそのまま掲示、あるいは、送信したいというニーズに応えるシステムを提供することを目的とする。

上記課題の少なくとも一部又は全部を解決するため、本発明は、文書上に記載された文字情報のうち、一つのフィールド画像データを分割し、異なる複数のオペレータ端末に配信する手段を有する。また、分割に当たって、それぞれの一部を重複させる手段を有する。また文字に電話番号等が含まれているとき、その一部を入れ換える手段を有する。またオペレータ端末にて確認又は修正されたテキストデータの不一致判定、統合手段を有する。

本発明によれば、キーボードによる日本語入力が困難な人であっても、インターネットを利用したメール送信や掲示板投稿が可能になる。一方、同時にオペレータによる目視確認の際にメール本文の画像とテキストを複数に分割してそれぞれを別々のオペレータに配信することにより、入力ミスの低減とメール本文の内容に関するプライバシー保護とセキュリティ確保というニーズを実現することが可能になる。

また、メール送信者は縦書きに書いた帳票を、目視確認するオペレータは横書きで見るという具合に、それぞれの好みに応じてタイトルやメッセージのテキストに関して縦書きと横書きを選択することが可能になる。

また、手書き手紙の感覚と同じように本人自筆の温かみを残したまま、メール送信や掲示板投稿が可能になる。もちろん、プライバシー保護とセキュリティ確保を実現することが可能になる。

以下、本発明のテキスト化システム及びその方法について説明する。

本発明の第１の実施形態を図１から図１７を用いて説明する。
図１は、本実施形態に係るシステム全体の概略を示す構成図である。複数の各家庭１０１（図では一家庭）では、メール送信又は掲示板に掲載するためのテキスト入力用の帳票１０２を送信するＦＡＸ装置１０３、テキスト入力された結果やメールなどのインターネット情報を見る端末１０４がネットワーク１０５で接続されており、それらが、広域ネットワーク１０６を介してプロバイダセンタ１０７につながっている。家庭の操作者はテキスト入力用の帳票１０２に記入内容を書き込んだ後、ＦＡＸ装置１０３にてその帳票を読み取り、その読み取った帳票画像データをセンタ１０７に送信する。

センタ１０７はメール配信や掲示板サービスを行うＷＥＢサーバ１０８、各家庭から送付された帳票画像（画像データ）を格納して、帳票画像をＯＣＲで文字認識し、その結果を格納する画像／文字認識サーバ（単に認識サーバとも言う）１０９、文字認識結果の目視確認と修正を行う確認・修正端末群１１０、この装置１１０で確認した結果を再検証する再確認・修正端末１１１がＬＡＮ１１２を介して接続されている。なお、確認・修正端末１１０、再確認・修正端末１１１はオペレータが操作する端末であることからオペレータ端末とも言い、ＣＰＵ、メモリ、ディスク、表示部、入力部等を備えている。

図２は画像／文字認識サーバ１０９の構成を説明する図である。各部を統合して制御する中央演算装置２０１、ＦＡＸ画像やＯＣＲの文字認識結果等を送受信するための通信制御部２０２、メモリ２０３、ＦＡＸ画像やＯＣＲの文字認識結果等を格納する画像・認識結果データベース２０８がバス２０９を介して相互に接続されている。メモリ２０３には各家庭から送付された帳票画像を読み取り、その帳票の種類を識別する帳票識別モジュール２０４、帳票の読取対象フィールドの文字を認識して文字コードに変換したり、１文字ごとに文字画像を切出す文字認識モジュール２０５、オペレータによる目視確認用に文字認識した結果と帳票画像を分割する認識結果・画像分割モジュール２０６、認識結果・画像分割モジュール２０６の出力をオペレータに配信した後、目視確認と修正結果を統合する確認修正結果統合モジュール２０７からなる。文字認識モジュール２０５には、文字形状を識別して文字コードに変換するための文字識別辞書や、文字形状の識別結果を表記ルールや地名データベースを用いて修正するための知識処理辞書が含まれる。これら各モジュールはソフトウェア上のプログラムに相当し、各機能別に分けているが１つのプログラムで構成しても良い。またこれら各モジュールは中央演算装置２０１を構成するＣＰＵのハードによってその機能が処理、制御されることは言うまでもない。勿論、プログラムをハードにて構成することも可能であり、これらを包含するものとして、モジュール、制御部又は単に手段と言う。

図３を中心に用いて、メールを送信する場合における装置やシステムの動作を説明する。細枠で囲われた処理は図１の各家庭１０１において、太枠で囲われた処理はプロバイダセンタ１０７においてそれぞれ処理されることを示す。
任意の家庭１０１にいる操作者はメール送信用帳票１０２に手書きで文字を記入する（ステップ３０１）。この記入されたメール送信用帳票の例を図８に示す。８０１は帳票の種類を判別するための識別番号であり、例えば「１２０２１」は「メール送信用帳票」、「１２０２２」は「掲示板投稿用帳票」等、帳票の種類と一対一に対応付けられた番号を示し、センタ１０７にて認識される。８０２から８０５はメッセージに含まれる本人情報に関わる記述を示すチェックマークであり、例えば、８０２の「メールアドレス有」にチェックがあれば、メッセージ中にメールアドレスが含まれていることを示す。登録番号８０６はメール送信者の登録番号であり、サービスプロバイダがメール送信者を管理するための管理番号である。登録者名８０７はメール送信者のペンネームを示す。シート番号８０８は、メッセージが長くなり複数の帳票に分けて書く場合のシート番号を示し、図では１枚のシートであることを示す。８０９は送信したいメールのタイトルであり、８１０は送信したいメールのメッセージ（本文）である。

ステップ３０２では、ＦＡＸ装置１０３を用いてステップ３０１で記入した帳票（図８）を読み取らせ、装置１０３はその読み取った帳票を帳票画像データに変換してプロバイダセンタ１０７に送信する。プロバイダセンタ１０７はＦＡＸ装置１０３より送信される画像データを、通信制御部２０２を介して受信し、画像／文字認識サーバ１０９にこの帳票画像を格納する。そして、プロバイダセンタ１０７の画像／文字認識サーバ１０９において、各家庭から送信された帳票画像に対してＯＣＲとオペレータによる目視確認と修正によりタイトルやメッセージをテキスト化する（ステップ３０３）。図２、図４を用いてステップ３０３の詳細処理を説明する。

上述した家庭１０１のＦＡＸ装置１０３より送信された画像データは画像／文字認識サーバ１０９の画像・認識ＤＢ２０８に記憶され、その帳票画像をこの画像・認識結果ＤＢ２０８から読み出す（ステップ４０１）。そしてこの読み出した帳票画像に対してＯＣＲ処理（ステップ４０２）を行うが、その詳細処理について図５，８を用いて説明する。なお、上述したように各処理は中央演算装置２０１のＣＰＵ等から処理、制御される。

ステップ５０１では、メモリ２０３の帳票識別モジュール２０４を用いて、読み出した帳票画像を読み出す、具体的には、図８の帳票識別番号８０１を読み取り、帳票画像の種類を識別する。また帳票上に含まれる符号８０２から８０５のチェックマークを認識してメールのメッセージ８１０中にそれぞれの本人特定情報が含まれるかの情報を抽出する（ステップ５０２）。続いて、符合８０６から８１０のそれぞれのフィールド（フィールド画像データとも言う）に対して、帳票の記入文字枠のレイアウト情報を基に１文字毎に文字画像を切り出すと共にその座標情報を格納する（ステップ５０３）。

ステップ５０３で切り出された文字に対して、文字の種類又は文字コードを特定するために、文字の形状を格納した文字識別辞書５０６を参照しながら文字識別処理を行う（ステップ５０４）。また切り出された文字画像のうち電話番号等に対しては、電話番号やメールアドレスの表記ルール又は全国に存在する住所データベースの情報を格納した知識処理辞書５０７を参照しながら、ステップ５０４で出力された文字識別処理結果がより尤もらしい文字列になるように文字識別処理結果の修正を行う（ステップ５０５）。

以上ステップ５０１から５０７の処理によりステップ４０２の帳票画像に対するＯＣＲ処理が実行され、１文字毎に切り出した文字枠の座標情報、文字認識されたテキストを含む認識結果テーブルが得られる。認識結果テーブルの例を図２７に示す。

本テーブルは図８の帳票に記載されたメッセージ８１０の一部の画像データと、それに対するテキストデータとを記憶、管理するために必要であり、一文字分、すなわち、メッセージ８１０を切り分ける（罫線）枠単位でその結果を記憶する。図２７の認識結果テーブルの符号２７０１は１文字枠を切り出した画像データを示し、符号２７０２から２７０５はそれぞれ１文字枠の左上Ｘ座標，左上Ｙ座標，右下Ｘ座標，右下Ｙ座標を示し、符号２７０６は文字認識結果のテキストデータ（テキストコードとも言う）を示す。ここのＸ座標、Ｙ座標は或る原点を基準とした座標値を示し、例えば、メッセージ８１０内の「会」に着目すると、その左上Ｘ座標’２０３’、左上Ｙ座標’５９’、右下Ｘ座標’２４９’、右下Ｙ座標’９９’という値を示している。

以上のＯＣＲ処理（ステップ４０２）した帳票の識別結果を用いて、帳票はメール送信用か、掲示板用かを判断する（ステップ４０３）。この判断から送付帳票がメール送信用であればステップ４０４へ、掲示板用であればステップ４０５に分岐させる。図８の帳票例にもあるように、帳票種としては「メール送信帳票」を示しているので、ここではステップ４０４に進む。このステップ４０４では、図１の確認・修正端末群１１０を用いて、メール用認識結果の目視確認・修正処理を行う。

図６を用いてステップ４０４の詳細を説明する。図６において太枠はオペレータによる処理、細枠は画像／文字認識サーバによる処理を示している。
最初に確認・修正端末群１１０、すなわちオペレータ端末に図８の帳票のタイトル８０９、メッセージ８１０の目視確認修正用の画像データと、ステップ４０２（詳細は図５）にてＯＣＲ認識処理をした結果（図２７のテキストデータ２７０６参照）を配信する。このとき、単に画像、テキストデータを配信するのではなく、帳票画像における画像データと、そのＯＣＲ認識結果の分割・切出し処理を行う（ステップ６０１）。つまり、特に図８のメッセージ８１０に含まれる画像データ、およびそのテキストデータはプライベート的な要素であり、一台のオペレータ端末に配信され、その内容が表示されると、一人のオペレータにその内容が把握されてしまい好ましくない。そこでこのようなメッセージ８１０（一つの閉じた意味を持たせることが可能な最小単位のデータ、連続したキャラクタデータ、又は１文字単位の枠ではなく、メッセージ枠に囲まれたデータとも言う）のフィールドを予め決められた分割処理にて分割し、複数のオペレータ端末に配信する。

図９を用いて画像データとＯＣＲ認識結果の分割処理（手段）、方法を説明する。図９は各オペレータＡ〜Ｄに配信される目視確認・修正用の画像とＯＣＲ認識結果のテキストを示す。原理を説明するために、図ではメッセージ８１０の画像とＯＣＲ結果を仮想的に１行に並べた上で、それぞれに配信する画像の位置を揃えて示している。もちろん、オペレータ端末も４台あることを想定している。

本例では目視確認・修正対象が５文字、あるいは、１０文字である場合を示す。オペレータＡには、メッセージの文字行画像９０１と対応するＯＣＲ結果９０２が配信され、同様にオペレータＢには、文字行画像９０３とＯＣＲ結果９０４がという具合である。図に示すように、各オペレータには文章の一部を他のオペレータに配信する分とずらして配信され、一人のオペレータが文書全体を把握することができないようになっている。このように、メッセージ８１０に含まれる画像データ及びそのＯＣＲ認識結果（テキストデータ）を分割処理するとき、或る部分で完全に分割するのではなく、第１の画像・認識結果と第２の画像・認識結果とが重複した状態で（完全重複ではなく一部重複）、分割処理するのも特徴の一つである。これを重複分割処理（手段）とも言う。

また、図９の文字行画像の網掛け部分、例えばオペレータＣの’会’’場’’不’’明’の４画像データは、目視確認・修正対象ではない。しかし、オペレータが確認・修正し易いように前後の一部の文字をオペレータ端末にて表示するために配信される画像部分である。これは、文脈に依存して文章に含まれる各文字の種類が決定される性質を考慮している。例えば、ＯＣＲ認識結果として大文字英字の”Ｏ”と句点”。”が出てきた時に、その前に「です」という文字があれば句点の方が正しいことが分り、オペレータは判断し易い。このように、各オペレータ端末に配信される分割画像、認識結果の関係として、認識結果より分割画像データを広く、多く表示する点も特徴がある。つまり、分割テキストデータ以上の分割画像データを表示し、更に、確認部分とそうでない部分とに分けて表示している。

上述したように、オペレータによる目視確認・修正のミスを防ぐため、本例では各オペレータに目視確認対象画像とテキストが一部重複して配信されている（重複分割処理）。これにより、各オペレータから回収したテキストを互いにマッチングさせて一致しているかどうかを判定し、不一致の場合は再度別のオペレータによって確認・修正してオペレータによる修正ミスを防ぐことができる。

この図９の説明は図８のメッセージ８１０に含まれる一般的な文章における分割処理についてであるが、同メッセージ中には電話番号や住所、氏名、メールアドレスといった、本人を特定するための手掛かりになる情報も含まれており、特にセキュリティに注意して扱う必要がある。そのため、これらの情報はオペレータに分からないようにしたい。一方、電話番号などを含むこれらの情報は、画像を任意の位置で分割されると目視確認や修正がやりづらく、全体が見られた方が処理し易い。この相矛盾する要求を満たす方法を、図１０を用いて電話番号を例に画像とＯＣＲ認識結果を複数のオペレータ端末に配信する方法について説明する。

今、図５のステップ５０５の知識処理において、電話番号の表記ルールが格納された知識処理辞書５０７と文字識別結果をマッチングさせるため、電話番号が記載されている場所を特定できる。また図８の帳票においてメールアドレス有りのチェックマーク８０２が付いている場合は、それを補助情報としてＯＣＲ結果があいまいな場合でも、より積極的にメール記載部分を抽出できる。図１０の電話番号部分の画像１００１と対応するテキスト１００２が元のＯＣＲ結果として得られる。そして、オペレータＡ（第１オペレータ端末）に対しては矢印で示した”３４”と”◇○”部分の画像とテキストを入れ換えたデータを、オペレータＢ（第２オペレータ端末）には”１２”と”◇○”部分の画像とテキストを入れ換えたデータをそれぞれ配信する。入れ換える部分はシステムが適当に設定し、オペレータはどの部分が入れ換えられたかは分からないため、配信された電話番号を見てもメール送信者の書いた番号を特定することはできない。これを入換処理とも言う。

一方、システム側（サーバ）は電話番号の桁のどこを入れ換えたかを把握しているので、それぞれのオペレータ端末から回収した確認・修正結果のテキストをマッチングさせて一致するかどうかを調べることにより、電話番号の修正ミスを防ぐことができる。不一致の場合は、上述したように再度別の確認修正端末１１１のオペレータによって確認・修正を行う。電話番号のように１文字の間違いが致命的になるような文字列に対しては、複数オペレータの処理結果の比較は重要である。このように、任意の文字を入れ換えることによりセキュリティを確保しつつ、オペレータの修正ミスを防ぐことができる。

以上、画像及び認識データの分割処理について詳述したが、次に、図６のステップ６０２では、ステップ６０１で生成したオペレータ配信用画像とＯＣＲ結果のテキストを各オペレータ端末に配信する。各オペレータ端末は配信された画像とＯＣＲテキストをその表示部に表示し、オペレータはその表示データ見比べて確認し、また必要に応じて入力部によりテキストを修正する（ステップ６０３）。図１１にオペレータの修正画面の例を示す。１１０１と１１０２は、それぞれ図９で説明した分割された文字行画像とＯＣＲテキストを示す。オペレータは文字行画像１１０１とＯＣＲテキスト１１０２を見比べて、必要に応じて１１０２の文字コードを修正する。図の例では句点が大文字英字の“Ｏ”と誤認識しているので、この部分を句点に修正する必要がある。一通り確認・修正が終われば、完了・送信ボタン１１０３を押して結果を画像／文字認識サーバ１０９に返送する。

画像／文字認識サーバ１０９は各オペレータ端末より送信されるデータ（画像、修正データ含む）、即ち確認修正結果を受信し（ステップ６０４）、各オペレータ端末に重複して配信された目視確認修正結果を統合して全体のテキストを生成する。そしてオペレータ端末から回収したテキストで不一致部分を抽出する（ステップ６０５）。このステップ６０５における統合処理、不一致抽出処理において、不一致テキストがあるかどうかを判定し（ステップ６０６）、あればステップ６０７に処理を移行し、なければ処理を終了する。

ステップ６０７では、不一致データを含む分割画像とＯＣＲテキストを再確認・修正端末群１１１を操作するオペレータに再度配信する。本端末を修正オペレータ端末ともいう。そしてこの修正オペレータ端末は受信した分割画像データとテキストデータとを表示部に表示し、一方オペレータはステップ６０３と同様に再度ＯＣＲテキストの目視確認と修正を行う（ステップ６０８）。続いて、修正オペレータ端末はその修正されたデータをサーバに送信し、画像／文字認識サーバ１０９がその確認修正結果（データ）を受信する（ステップ６０９）。そして、このステップ６０９で受信したＯＣＲテキストの目視確認結果を再統合し、ステップ６０５で検出した不一致部分を修正して最終的な全体のタイトルあるいはメッセージを生成する（ステップ６１０）。この再統合処理は、例えば最初に目視確認した結果と今回の確認結果との多数決を用いる、または今回の確認結果を優先するなど、適切な方法により実行するのが望ましい。

以上のステップ６０１から６１０の処理により、ステップ４０４のメール用帳票に対するＯＣＲテキストの目視確認・修正が行われ、ステップ４０１から４０４の処理によりステップ３０３のメール送信用帳票に対するテキスト化処理が完了する。

続いて、ステップ３０４では、テキスト化した図８の「メール送信帳票」のデータを図１のＷＥＢ／メールサーバ１０８にアップロードする。それと共に、メールやＦＡＸ等の通信手段を用いて、各家庭１０１の帳票送信者の端末１０４に対してテキスト化してアップロードが完了したことを通知する。通知を受けた送信者は、端末１０４等を使用してＷＥＢ／メールサーバ１０８にログインして、自分が意図したテキストになっているかを確認し、修正が必要な場合は修正箇所をマークしてプロバイダに通知する（ステップ３０５）。

図１２に確認・修正箇所をマークする画面の一例を示す。この画面は家庭１０１の端末１０４に表示される。登録番号１２０１、登録者１２０２は、それぞれ図８の８０６、８０７に該当するテキストである。「メッセージ参照」ボタン１２０３は、例えば掲示板に投稿された記事に返信する場合や受信したメールに返信する場合のオリジナルの記事やメールを参照するためのボタン（入力部、以下同じ）である。タイトル１２０４、メッセージ１２０５は、それぞれ図８の８０９、８１０をテキスト化したデータを示す。本図にあるように、図８の帳票の画像に対応している。１２０６は画面に表示されたメールを送信するためのボタンであり、１２０７はメッセージなどを修正したい場合、修正箇所をマークするためのボタンである。１２１０は修正マークを示した例であり、ボタン１２０７を押して、マウスで修正したい箇所をなぞると１２１０のように修正したい箇所がマーク付けされる。１２０８は修正マークを付けたテキストの修正をプロバイダに依頼するボタンである。１２０９は処理を終了するための終了ボタンである。

この図１２の画面に表示された内容で図１２の送信ボタン１２０６を押すと、そのテキストデータ化された内容にてメールを送信する（ステップ３０６）。このように、ステップ３０１から３０６の処理により、利用者は帳票の画像を送信し、それをサーバ側にてＯＣＲ認識処理、修正処理などにてテキスト化し、そのテキスト化された顧客を確認することで、利用者が最初に書いた手書き帳票によるメール送信が可能になる。

次に、図３を用いて掲示板に記事を投稿する場合における装置やシステムの動作を説明する。なお、上述したメール送信帳票と同様な処理については適宜省略する。
家庭にいる操作者はＷＥＢ掲示板投稿用帳票に手書きで文字を記入する（ステップ３０１）。記入されたメール送信用帳票の例を図１３に示す。１３０１は掲示板投稿用帳票であることを識別するための識別番号である。１３０２は投稿する掲示板の種類を示す掲示板番号である。１３０３は掲示版番号に対応する掲示板の名称であり、掲示板番号の入力間違いを防ぐために記入する。シート番号１３０４は、メッセージが長くなり複数の帳票に分けて書く場合のシート番号を示す。１３０５、１３０６それぞれは投稿したい記事のタイトルとメッセージである。

続いて、ＦＡＸ装置１０３を用いてステップ３０１で記入した帳票画像をプロバイダセンタ１０７に送信し（ステップ３０２）、帳票画像は画像／文字認識サーバ１０９に格納される。プロバイダセンタ１０７の画像／文字認識サーバ１０９において、各家庭から送信された帳票画像に対してＯＣＲとオペレータによる目視確認と修正によりテキスト化する（ステップ３０３）。このステップ３０３の詳細処理は上述と略同様で図４に示され、帳票画像をテキスト化する。特に、ステップ４０３では帳票識別で得られた帳票識別番号により帳票がメール送信用か掲示板投稿用かを判別するが、図１３のとおり、帳票は「掲示板送信帳票」であり、その種類は１３０１により識別されるのでステップ４０５に進む。

ステップ４０５では、確認・修正端末群１１０を用いて、掲示板投稿用認識結果の目視確認・修正処理を行う。この詳細処理は図７に示すが、図６の各処理と比較しても明らかなように、帳票画像データ・認識結果の分割処理（ステップ６０１）が省略されている。掲示板投稿の場合、投稿時には不特定多数のアクセス者に参照されるので、上述のメール送信と異なりタイトルやメッセージのプライバシーをオペレータから保護する必要性が低い。そのため、図６のステップ６０１のようにプライバシーとセキュリティ保護のための画像とＯＣＲ認識結果の分割配信は必要ないので、図７ではそれに該当する処理がない。

配信用画像データと、ＯＣＲ結果のテキストデータを各オペレータに配信する（ステップ７０１）。メール送信時と異なりタイトルやメッセージを分割する必要が無いので、各オペレータには分割せずに全体を配信する。各オペレータは配信された画像とＯＣＲテキストを見比べて、必要に応じてテキストを修正する（ステップ７０２）。図１４にオペレータ端末に表示される修正画面の一例を示す。メッセージ画像１４０１とＯＣＲテキスト１４０２を見比べて、必要に応じて１４０２の文字コードを修正する。一通り確認・修正が終われば、完了・送信ボタン１４０３を押して結果を画像／文字認識サーバ１０９に返送する。そして、画像／文字認識サーバ１０９は、各オペレータの確認修正結果を受信し（ステップ７０３）、各オペレータに重複して配信された目視確認修正結果を統合して（ステップ７０４）、全体のタイトルあるいはメッセージを生成すると共に、重複配信部分で不一致テキストがあるかどうかを判定する（ステップ７０５）。不一致が無ければ処理は終了し、あればステップ７０６に処理を移行し、不一致データを含む分割画像とＯＣＲテキストを再確認・修正端末群１１１を操作するオペレータに再度配信する。続いて、オペレータはステップ７０２と同様に再度ＯＣＲテキストの目視確認と修正を行い（ステップ７０７）、各オペレータの確認修正結果を画像／文字認識サーバ１０９が受信する（ステップ７０８）。受信したＯＣＲテキストの目視確認結果を再統合し（ステップ７０９）、ステップ７０４で検出した不一致部分を修正して最終的な全体のタイトルあるいはメッセージを生成する。このステップ７０１から７０９の処理により、ステップ４０４の掲示板投稿用帳票に対するＯＣＲテキストの目視確認・修正が行われ、ステップ４０１から４０４の処理により掲示板投稿用帳票に対するテキスト化３０３の処理が完了する。

ステップ３０４では、テキスト化したメールのデータをＷＥＢ／メールサーバ１０８にアップロードする。それと共に、メールやＦＡＸ等の通信手段を用いて、各家庭１０１の帳票送信者に対してテキスト化してアップロードが完了したことを通知する。ステップ３０５では、通知を受けた送信者がＷＥＢ／メールサーバ１０８にログインして、自分が意図したテキストになっているかを確認し、修正が必要な場合は修正箇所をマークしてプロバイダに通知する。図１５に確認・修正箇所をマークする画面の例を示す。勿論、利用者の端末１０４に表示される。掲示番号１５０１、掲示板名１５０２は、それぞれ図１３の１３０２、１３０３に該当するテキストである。「掲示板参照」ボタン１５０３は、例えば掲示板に直接投稿したり、投稿された記事に返信投稿する場合の元の記事を参照するためのボタンである。タイトル１５０４、メッセージ１５０５は、それぞれ図１３の１３０５、１３０６をテキスト化したデータを示す。１５０６は画面に表示された記事を投稿するためのボタンであり、１５０７はメッセージなどを修正したい場合、修正箇所をマークするためのボタンである。１５０８は修正マークを付けたテキストの修正をプロバイダに依頼するボタンである。１５０９は処理を終了するための終了ボタンである。

ステップ３０６では、画面に表示された内容で図１５の送信ボタン１５０６を押して記事を投稿する。掲示板に投稿された記事の一覧を表示した例を図１６に示す。１６０１は掲示板の名称を示し、図１５の１５０２に相当する。１６０２は投稿された記事のデータを示す各コラムの内容を表示している。１６０３から１６０４は投稿された記事の一覧データを示しており、特に符号１６０３の内容は図１５の記事に該当するデータを示している。１６０３をクリックすると図１７に示すような投稿記事の内容が表示される。１７０１は掲示板の名称を示し、図１５の１５０２に相当する。１７０２は投稿した記事の内容である。１７０３は投稿された記事に対する返信投稿するためのボタンであり、１７０４、１７０５はそれぞれ現在参照している記事の前、あるいは、後の投稿記事を参照するためのボタンである。以上のステップ３０１から３０６の処理により手書き帳票による掲示板への記事投稿が可能になる。

次に、この掲示板投稿の例を用いて縦書き帳票を用いた実施例を説明する。手書き帳票を用いて投稿する場合、人によっては縦書きの方が書きやすいという投稿者も存在する。一方、コンピュータの操作になれたオペレータにとっては縦書きよりも横書きの方が作業しやすいことが多い。これを両立するためには、送信帳票は縦書きであるが、オペレータの目視確認と修正時には横書きに変換されている必要がある。本実施例を図３、図５、図７、図１４、図１８を用いて説明する。

前述した掲示板投稿処理の場合と大きく異なるのは、（１）図３のステップ３０１で記入する帳票のレイアウト、（２）ステップ３０３のＯＣＲによる文字認識時の文字の切り出し処理又は方法、（３）オペレータに配信する画像とテキストの生成処理又は方法である。以下では上記３つの異なる部分のみを説明する。

縦書きの場合の帳票レイアウト例を図１８に示す。１８０１は掲示板投稿用の縦書き帳票であることを識別するための識別番号である。１８０２、１８０３、１８０４はそれぞれ図１３の横書き帳票にもある１３０２、１３０３、１３０４と同様に、掲示板番号、掲示板名称、シート番号を示す。１８０５、１８０６はそれぞれ投稿したい記事のタイトルとメッセージであり図示するように縦書きになっている。

図３のステップ３０３の詳細を説明した図４のステップ４０２、さらにステップ４０２の詳細を説明した図５のステップ５０３において縦書き文字に対するＯＣＲによる文字認識時の文字切り出し処理が実行される。ステップ５０１における帳票識別により縦書きの帳票であることを判断し、その情報に基づいて一マスごとに書かれた文字画像を縦方向に切り出す。

オペレータに配信する画像とテキストの生成は、図７のステップ７０１で実行される。１文字ごとに切り出された文字画像と対応するテキストを横方向に並べ替える処理を実行し、各オペレータに配信する。これにより横書き帳票の場合と同様に図１４のような横書き画像が端末に表示される。よって、オペレータは縦書きを意識することなく目視確認と修正を行うことができる。以上のような修正を加える事で、掲示板投稿者は縦書きに文字を書き、オペレータは横書きに表示で目視確認ができ、両者のニーズを満足することが可能になる。

次に、帳票に記載された文字を１文字ごとに切り出して文字画像として配信する他の実施例を図１、図２、図８、図１９から図２５を用いて説明する。本実施例においては、利用者の記入した帳票画像をメール又は掲示板にて使用する場合でも、それをテキスト表示するのではなく、記入した画像を生かした状態で帳票画像を編集処理し、画像としてメール送信又は掲示板掲載を行うことを特徴とする。なお、メール送信の場合を例に説明するが掲示板投稿にも適用できることは言うまでもない。各家庭１０１から送信された帳票は図８（又は図１３，１８）に示されるようなテキストに変換する帳票レイアウトと同じレイアウトを使用可能である。

図１９を用いて、メールを送信する場合における装置やシステムの動作を説明する。細枠で囲われた処理は図１の各家庭１０１において、太枠で囲われた処理はプロバイダセンタ１０７においてそれぞれ処理されることを示す。ステップ１９０１、ステップ１９０２では上述のステップ３０１、３０２と同様に家庭にいる操作者がメール送信用帳票（図８参照）に手書きで文字を記入して、ＦＡＸ装置１０３を用いてプロバイダセンタ１０７に送信する。プロバイダセンタ１０７の画像／文字認識サーバ１０９において、各家庭から送信された帳票画像に対して文字画像切出処理やＯＣＲ認識処理等を実行し、更に、オペレータによる目視確認と修正によりタイトルとメッセージの文字画像を１文字ずつ切り出してインデックス付けする。また、ＯＣＲ処理により、切り出された各文字画像に文字コードと文字コードを参照して得られるレイアウト上の禁則処理コードを付与する（ステップ１９０３）。このステップ１９０３に関して図２０を用いて詳細処理を説明する。

図２の画像・認識結果ＤＢ２０８から受信した帳票画像を読み出す（ステップ２００１）。そして読み出した帳票画像に対して次の画像処理を行う（ステップ２００２）。第１に、読み出した帳票画像に対して文字画像切出処理を実行する。図８のメッセージ８１０のフィールドはそれ自体で１つの画像であり、これを１文字毎に切り分ける処理である。第２に、１文字毎に切り出された画像に対してインデックス付けを行うインデックス付加処理を実行する。インデックスは文字枠の座標情報を基に１文字毎に画像を切り出し、文章を構成する文字が並ぶ順番にインデックスを画像に付与する。第３に、各切り出された文字画像に対するＯＣＲ処理により文字コードを付与する。上述で説明したテキスト化処理に該当するものである。第４に、文字コードを参照して、文章のレイアウト上の禁則処理に関するコードを付与する。この禁則処理に関するコードとは、例えば句読点等文字行の先頭に現れるのが適切でない文字コードに対して、文末に来るようにその文字コードに対応する文字画像のレイアウトを調整するためのコードである。本実施例では句読点に対して「Ｒ」のコードを付与している。これら第１〜４画像処理の各画像処理（ステップ２００２）で出力されるテーブルを図２１に示す。図２１において、２１０１は切り出した文字画像に対応するインデックステーブルを表し、２１０２は１文字毎に切り出された文字画像を示す。２１０３は文字画像に対応する文字コード、２１０４は禁則処理コードである。

ここで、第２画像処理のインデックス処理を説明する。プロバイダ１０７側にて受信する例えばメッセージ８１０（図８参照）はそれ自体では一塊の画像データである。これを第１画像処理にて各文字単位で切り出すが、その際、何の処理も施さないと復元時に画像の順番が入れ換えられる等して、本来の文章の意味をなさなくなってしまう。また利用者に画像処理後の編集された画像を送信する際、後述する文章区切れでの「改行」、個々の文字画像の「縮小又は拡大」にも対応するために、本インデックス付加処理が有効である。
第３画像処理のＯＣＲ処理（又は認識処理、文字コード付加処理、テキスト化処理）について説明する。上述したとおり、本実施例では利用者が記載した文字画像通りのものを利用者に送信し、メール送信又は掲示板掲載においても、その画像（認識後のテキストではなく）を使用する。しかし、図８のメッセージ８１０には通常の平仮名、漢字以外にも、電話番号、メールアドレス等のような文字画像も含まれる。そこでこのような文字画像（平仮名等と区別するため特殊文字と表現する）においては、この特殊文字の前の文章から改行された方が、一層この特殊文字を際立たせることができる。これにより利用者から第３者へのメール送信又は掲示板掲載において、その特殊文字が重要であることを伝えることができる。例えば、図８のように原文字画像が「メールアドレ（改行）スｘｘ＿ｙｙ＠…」となっているとき、アドレスの部分を図５のステップ５０４等にて特別に認識することで、後述の図２４のように「メールアドレス（改行）ｘｘ＿ｙｙ＠…」との適切な画像表示をすることである。またアドレス部分のみ（英数字）の画像を拡大したり等の後処理も可能となる。
第４画像処理の禁則処理を説明する。上述したように、句読点等、文字行の先頭にこないようにする処理であり、例えば、図８の原文字画像は「…公民館です（改行）。ご不明な場合は…」となっており、「。」が２行目の先頭行にある。この「。」を禁則処理して図２４のように「…公民館です。（改行）ご不明な場合は…」と適切な処理を施すことができる。

以上のように、種々の画像処理を行い、ステップ２００３では、ＯＣＲ処理した帳票の帳票種識別結果を用いて、送付帳票がメール送信用であればステップ２００４へ、掲示板用であればステップ２００５に分岐させるための判別処理を行う。今の場合はメール送信帳票を前提としているので、ステップ２００４に進む。このステップ２００４では、確認・修正端末群１１０を用いて、メール用文字画像切り出し結果の目視確認・修正処理を行う。図２２を用いてステップ２００４の詳細を説明する。図において太枠はオペレータによる処理、細枠は画像／文字認識サーバ１０９による処理を示している。ＯＣＲ結果のテキスト修正の場合と異なり、オペレータ修正における文字画像の１画素２画素の違いは人間の見た目には大きな影響を与えない。よって、図６の場合と異なり、複数のオペレータ修正結果の不一致判定とその結果に基づく処理は削除されている。

ステップ２２０１では、確認・修正端末群１１０に対して、図８のメールタイトル８０９とメッセージ８１０の目視確認修正用の参照画像（原帳票画像）と、１文字毎の文字画像切出結果（上記画像処理後の編集帳票画像）を配信するために、上述と同様に帳票画像における画像データ・文字画像切出結果の分割・切出し処理を行う。そして、生成したオペレータ配信用画像を各オペレータに配信する（ステップ２２０２）。

各オペレータは端末１１０に配信された帳票の参照用画像と１文字毎に切り出された文字画像を見比べて、必要に応じて文字画像を修正する。図２３にオペレータの修正画面の例を示す。２３０１と２３０２は、それぞれ分割された参照用文字行画像と１文字毎に切り出された文字画像を示す。オペレータは参照用文字行画像２３０１と切り出された文字画像２３０２を見比べて、必要に応じて２３０２の文字画像を修正する。一通り確認・修正が終われば、完了・送信ボタン２３０３を押して結果を画像／文字認識サーバ１０９に返送する。この修正の必要性として、文字パターンが文字枠に接触して文字画像として正しく切り出せない場合があるためである。さらに図２３には図示していないが、図２１のＯＣＲ認識結果２１０３を同一画面に表示してオペレータが修正するのが望ましい。この修正の必要性としては、原画像には句読点などとして「。」が記載されていたものを、ＯＣＲ認識処理にて「０」（ゼロ）と認識してしまう場合があるためである。（ゼロ）と認識されると句点として解釈されないため、文頭にこないようなレイアウトの禁則処理を正しく実行できない。これを回避するため、オペレータによる文字コードの修正作業が必要になる。

続いて、各オペレータの確認修正結果を画像／文字認識サーバ１０９が受信し（ステップ２２０４）、各オペレータから配信された目視確認修正結果を統合して全体のタイトルあるいはメッセージを生成する（ステップ２２０５）。さらに，図２１におけるテーブル２１０４の禁則コードを修正された文字コードに合わせて再度付与し直す（ステップ２２０６）。これらステップ２２０１から２２０６の処理により、ステップ２２０４のメール用帳票に対する文字切出し画像の目視確認・修正が行われる。

以上説明した図１９のステップ１９０３詳細処理が終了すると、画像処理後の編集帳票画像データ、つまり切り出したメールの文字画像データをＷＥＢ／メールサーバ１０８にアップロードする（ステップ１９０４）。それと共に、メールやＦＡＸ等の通信手段を用いて、各家庭１０１の帳票送信者に対して文字画像を切り出してアップロードが完了したことを通知する。そして、通知を受けた送信者がＷＥＢ／メールサーバ１０８にログインして、自分が意図したテキストになっているかを確認し（ステップ１９０５）、修正が必要な場合は修正箇所をマークしてプロバイダに通知する。図２４は利用者側の端末１０４に表示される内容で、確認・修正箇所をマークする画面の例を示す。登録番号２４０１から２４０３は図１２の１２０１から１２０３と同じ内容を示す。タイトル２４０４、メッセージ２４０５は、それぞれ図８の８０９、８１０を１文字毎に画像を切り出したデータを示す。２４０６から２４０９は図１２と同じである。２４１０は図１２と同様に修正マークを示した例である。上述したとおり、文字画像に付与された禁則処理コードを用いたレイアウト調整により図８の帳票レイアウトと異なり、読点「。」の画像データが文末に配置、また「メールアドレス」の単語全体が１行になるように文字画像データが配置し直されている。そして、画面に表示された内容で図２４の送信ボタン２４０６を押してメールを送信する（ステップ１９０６）。以上のステップ１９０１から１９０６の処理により１文字毎に切り出した文字画像によるメール送信が可能になる。

次に、掲示板に関する処理を説明する。１文字毎に切り出された文字画像によるメッセージは上記メール送信の一例と同様である。メール送信処理の場合と異なるのは図２０におけるステップ２００５の処理に分岐すること、および、図１９におけるステップ１９０５である。このステップ２００５の処理はメールの場合と同様に図２２の手順に従い確認修正処理を行う。メールの場合と異なる処理はステップ２２０３であり、オペレータが操作する画面の例は図２５のようになる。２５０５がテキストの代わりに切り出された文字画像になっているだけで、他は図１５と同じである。なお、ステップ１９０５では、掲示板投稿者が操作する画面のタイトル・メッセージが図１５のテキストの代わりに図２６の２６０４、２６０５に示すように切り出された文字画像に変わることである。これら処理により１文字毎に切り出された文字画像による掲示板への記事投稿が可能になる。

以上説明したとおり、本実施例では帳票はＦＡＸによる送信を例に説明したが、スキャナで読み取った画像を、インターネットを介してプロバイダに送信してもよい。本装置を画像読取装置又はイメージ読取装置とも言う。また、センタにある目視確認・修正端末はセキュリティ対策を施した上、ネットワークを介してセンタ外の別の場所に設置してもよい。さらに、実施例ではＷＥＢサーバと画像／文字認識サーバを分けて説明したが、両者を統合して１台で実現してもよい。合わせて単にサーバとも言う。

図1において確認・修正端末１１０と再確認・修正端末１１１は実施例の説明では分けたが、これらを統合し、最初に確認・修正したオペレータとは別のオペレータによる再確認・修正を行ってもよい。さらに、実施例ではオペレータ確認・修正のミスを防ぐために重複配信（又は重複分割）の例を説明したが、重要度が低い帳票種の場合は画像とＯＣＲ結果を重複がないように分割して配信してもよい。本処理は、帳票種の識別結果に応じて決定するのが望ましい。また、上記実施例ではＯＣＲによる帳票画像のテキスト化を用いた説明を行ったが、ＯＣＲを介さずに直接オペレータによるテキスト化入力を行ってもよい。

文字テキスト化システムの全体システム構成図を示す。 画像／文字認識サーバ１０９の構成図である。 全体の処理の流れを説明するフロー図である。 図３における帳票画像のテキスト化処理３０３の詳細を説明する図である。 図４におけるＯＣＲ処理４０２の詳細を説明する図である。 図４におけるメール用認識結果確認修正処理４０４の詳細を説明する図である。 図４における掲示板用認識結果確認修正処理４０５の詳細を説明する図である。 各家庭からプロバイダに送付するメール送信用の帳票を説明する図である。 各オペレータに配信されるメール送信用帳票のメッセージ画像・ＯＣＲ結果の分割方法を説明する図である。 各オペレータに配信されるメール送信用帳票のメッセージ画像中の電話番号部分データを生成する処理を説明する図である。 メール送信用帳票のＯＣＲ結果を各オペレータが目視確認・修正するための確認・修正画面を説明する図である。 メールの送信者が送信するメールの内容を確認・修正依頼・送信するための画面を説明する図である。 各家庭からプロバイダに送付する掲示板投稿用の帳票を説明する図である。 掲示板投稿用帳票の文字認識結果を各オペレータが確認・修正するための確認・修正画面を説明する図である。 掲示板投稿者が投稿する掲示板投稿の内容を確認・投稿するための確認・投稿画面を説明する図である。 掲示板の表示例を説明する図である。 掲示板投稿者が投稿した掲示板の内容を説明する図である。 各家庭からプロバイダに送付する掲示板投稿用の縦書き帳票を説明する図である。 文字画像を使用した画像処理全体の流れを説明する図である。 図１９における帳票画像の文字画像切出し処理１９０３の詳細を説明する図である。 文字画像データへの処理を説明するテーブル図である。 図２０におけるメール用画像切出結果の確認修正処理２００４の詳細を説明する図である。 オペレータ端末に表示される確認・修正画面を説明する図である。 利用者端末に表示される画面の一例を示す図である。 掲示板投稿用帳票に応用したときのオペレータ端末に表示される確認・修正画面を説明する図である。 掲示板投稿者が表示、確認する確認・投稿画面を説明する図である。 認識結果テーブルの一例を示す図。

符号の説明

１０１…各家庭、１０２…テキスト入力用の帳票、１０３…ＦＡＸ装置、１０４…インターネット情報を見るための端末、１０５…家庭内ネットワーク、１０６…広域ネットワーク、１０７…プロバイダセンタ、１０８…ＷＥＢサーバ、１０９…画像／文字認識サーバ、１１０…確認・修正端末群、１１１…再確認・修正端末群、１１２…ＬＡＮ

Claims (10)

1. 文書上に記載された文字情報を画像データに変換し、該画像データをテキスト化するシステムにおいて、
   連続したキャラクタデータからなる一つのフィールド画像データと、該フィールド画像を認識したテキストデータとを複数に分割する手段と、
   分割された各分割画像データ及び該分割画像データに対応する各分割テキストデータとを異なる複数のオペレータ端末に配信する手段と、
   前記オペレータ端末は配信された前記分割画像データ及び分割テキストデータとを対に表示する手段と、表示された前記分割テキストデータに修正入力する手段とを有する
   ことを特徴とする文字画像テキスト化システム。
2. 請求項１記載の文字画像テキスト化システムにおいて、分割される前の前記フィールド画像データは、タイトル又はメッセージを含むことを特徴とする文字画像テキスト化システム。
3. 請求項２記載の文字画像テキスト化システムにおいて、前記メッセージに電話番号又はメールアドレス等が含まれていたとき、予め決められた手順に従ってその一部を入れ換えて前記分割画像データを生成する入換手段を有することを特徴とする文字画像テキスト化システム。
4. 請求項１記載の文字画像テキスト化システムにおいて、前記フィールド画像を分割するとき、第１分割画像データと第２分割画像データとのそれぞれの一部を重複させて分割する重複分割手段を有することを特徴とする文字画像テキスト化システム。
5. 請求項１記載の文字画像テキスト化システムにおいて、前記複数のオペレータ端末から送信される複数の分割テキストデータの一致不一致を抽出する手段を有することを特徴とする文字画像テキスト化システム。
6. 請求項１記載の文字画像テキスト化システムにおいて、前記複数のオペレータ端末から送信される複数の分割テキストデータを統合する手段を有することを特徴とする文字画像テキスト化システム。
7. 請求項１記載の文字画像テキスト化システムにおいて、前記フィールド画像データが縦書きに記載された文章のとき、横書きの画像データに変換する手段を有することを特徴とする文字画像テキスト化システム。
8. 請求項１記載の文字画像テキスト化システムにおいて、前記オペレータ端末は、前記分割テキストデータ以上の前記分割画像データを表示すると共に、前記分割画像データを確認部分とそうでない部分とに分けて表示する手段を有することを特徴とする文字画像テキスト化システム。
9. 帳票に記載された文字画像データをテキスト化するシステムにおいて、
   連続文字の一塊のフィールド画像データを、文字単位で区分する区分手段と、
   前記区分された文字を認識する認識手段と、
   区分した画像の順番を規定するインデックス処理手段と、
   任意の画像に対して禁則処理を実行する禁則処理手段とを有する
   ことを特徴とする文字画像テキスト化システム。
10. 前記認識手段及び前記禁則処理手段の処理結果に応じて、前記フィールド画像データの所望の位置に改行処理を施すことを特徴とする請求項９記載の文字画像テキスト化システム。
    

Images