(57)【要約】【課題】手書きの書類の文字を情報の機密性を保持しながら必要な処理を進めることができる手書き文字入力処理システムを提供すること。【解決手段】手書き文字入力処理システムは、クライアント２のイメージスキャナから入力された用紙のワンシートデータをパーツデータに分割しさらに第１〜３の鍵で暗号化する。データセンタ１はこのデータを第２の鍵で一部を復号化して管理し、エントリーコンピュータ３で第３の鍵で復号化させて表示する。オペレータは目視で文字認識しキー入力で文字データファイルを生成して第４の鍵で暗号化しクライアントに返す。クライアントは第１、２、４の鍵で復号化する。このため、処理の段階に合わせて部分、部分を多段階的に暗号化・復号化して情報の機密性を保持しながら必要な処理を進めることができる。【選択図】図１
2008269227.tif 000002
【特許請求の範囲】
【請求項１】
複数の入力端末と管理コンピュータと複数の処理端末とからなり、任意の入力端末に接続されたイメージスキャナからイメージデータが入力された用紙を、管理コンピュータを介していずれかの処理端末でその一部を表示し、当該処理端末の操作者に目視で文字を認識させて入力させた文字データを前記管理コンピュータを介して前記任意の入力端末から文字データとして出力する手書き文字入力処理システムであって、
前記入力端末は、
前記イメージスキャナにより文字が記載された用紙のイメージデータを読取る用紙スキャン手段と、
読取ったイメージデータの予め文字が記載される位置として特定された複数の文字領域からそれぞれイメージデータを切出すとともに、そのイメージの属性を示す固有のファイル名を付与する切出し手段と、
切出したイメージファイルのファイル名を所定の文字列に分割し、当該分割した文字列をそれぞれを異なる鍵を用いて暗号化するファイル名暗号化手段と、
ファイル名が暗号化されたイメージファイルを管理コンピュータに送信するイメージファイル送信手段とを備えたことを特徴とする手書き文字入力処理システム。
【請求項２】
前記ファイル名暗号化手段において、暗号化された暗号文は、制御コードを含まない文字コードからなる文字セットによることを特徴とする請求項１に記載の手書き文字入力処理システム。
【請求項３】
前記切出し手段において、イメージの属性を示す固有のファイル名には、入力された複数の用紙のうちのいずれの用紙から切出されたかを示す文字列である用紙特定ＩＤコードを含む文字列を含み、
前記ファイル名暗号化手段において暗号化に用いる鍵は、当該用紙特定ＩＤコードを含む文字列の暗号化に用いる第１の鍵と、それ以外の文字列を暗号化する第２の鍵を含むことを特徴とする請求項１又は請求項２に記載の手書き文字入力処理システム。
【請求項４】
前記用紙特定ＩＤコードを含む文字列には、そのイメージデータがいずれの文字領域から切出されたかを示すパーツＩＤコードをさらに含むことを特徴とする請求項３に記載の手書き文字入力処理システム。
【請求項５】
前記第１の鍵を前記入力端末に接続された可搬型記憶媒体に記憶するとともに、当該入力端末の記憶媒体から第１の鍵の記憶を消去することを特徴とする請求項３又は請求項４に記載の手書き文字入力処理システム。
【請求項６】
前記可搬型記憶媒体は、ＵＳＢメモリであることを特徴とする請求項５に記載の手書き文字入力処理システム。
【請求項７】
前記入力端末は、
前記イメージファイルのうち切出したイメージデータの部分を第３の鍵により暗号化するイメージデータ暗号化手段をさらに備えたことを特徴とする請求項１乃至請求項６のいずれか１項に記載の手書き文字入力処理システム。
【請求項８】
請求項１乃至請求項７のいずれか１項に記載の手書き文字入力処理システムにおいて、
前記入力端末は、
前記ファイル名が暗号化された複数のイメージファイルを逐次入力端末の記憶手段のフォルダに蓄積する蓄積手段と、
当該フォルダに蓄積された複数のイメージファイルのタイムスタンプを共通化した後に順序を並べ直す再ソート手段と、
再ソートされたイメージファイルを前記管理コンピュータに送信するイメージファイル送信手段とを備えたことを特徴とする手書き文字入力処理システム。
【請求項９】
請求項７に記載の手書き文字入力処理システムにおいて、
前記処理端末は、
管理コンピュータからイメージファイルを受信する受信手段と、
受信したイメージファイルのイメージデータのみを第３の鍵で復号化して揮発性記憶媒体のみに記憶する復号化手段と、
復号化したイメージデータを表示する表示手段と、
表示されたイメージに対応してオペレータからの文字入力を受け付けて文字データとして記憶する文字入力手段と、
当該文字入力手段から入力された文字データに対応するイメージデータを消去する消去手段と、
入力された文字データを第４の鍵で暗号化するとともに、前記受信したイメージファイルのファイル名と同じファイル名を付与した文字ファイルを生成する文字ファイル生成手段とを備えたことを特徴とする手書き文字入力処理システム。
【請求項１０】
請求項３乃至請求項６のいずれか１項に記載の手書き文字入力処理システムにおいて、
前記管理コンピュータは、
前記入力端末から送信されたイメージファイルを受信するとともに、前記第２の鍵でファイル名の一部を復号化して記憶するイメージファイルデータベースを備え、
処理端末からの読取り処理の要求であるジョブ要求のあった処理端末を識別する処理端末コード若しくは操作者を識別する操作者コードを、処理依頼したイメージファイルのファイル名とともに記憶して、いずれのイメージファイルをいずれの処理端末若しくは操作者に処理依頼したかを記憶する処理依頼履歴ファイルを備え、
前記イメージファイルを受信する未処理データ受信手段と、
前記処理端末のいずれかからの処理端末コード若しくは操作者コードとともに送信されたジョブ要求により、
前記処理依頼履歴ファイルを参照して当該処理端末若しくは操作者に既に送信したイメージファイルを排除する重複排除手段と、
イメージファイルを前記イメージファイルデータベースからファイル名に含まれた属性を示す文字列を参照して所定の基準に従って選択する選択手段と
により処理依頼すべきイメージファイルを選択して依頼する未処理データ処理依頼手段を備えたことを特徴とする手書き文字入力処理システム。
【請求項１１】
前記未処理データ処理依頼手段において、イメージファイルを処理依頼する所定の基準は、前記ジョブ要求に含まれる文字入力制限のタイプを基準の一つとすることを特徴とする請求項１０に記載の手書き文字入力処理システム。
【請求項１２】
前記管理コンピュータは、
前記処理端末から送信された文字ファイルを受信する文字ファイルデータベースと、
当該処理端末から文字ファイルが送信されたときに、各処理端末から受信した文字ファイルのファイル名を参照して、管理コンピュータが初めて受信したファイル名である場合には、当該文字データを処理端末コード若しくは操作者コードとともに記憶するベリファイリストを生成し、
同一文字ファイルに係る文字データを比較して、一致する文字データの一致数が所定数以上となった場合に、入力された文字データを有効なデータとして送信ファイルに記憶するとともに、
当該文字データに係る処理端末若しくは操作者をオペレータデータベースに記録するベリファイ手段を備えたことを特徴とする請求項１乃至請求項１１のいずれか１項に記載の手書き文字入力処理システム。
【請求項１３】
請求項１２に記載の手書き文字入力処理システムにおいて、
前記管理コンピュータは、前記ベリファイ手段において、文字データが暗号化されている場合でも文字データの比較は復号化することなく暗号化された文字データ同士を比較することを特徴とする手書き文字入力処理システム。
【請求項１４】
請求項１２又は請求項１３に記載の手書き文字入力処理システムにおいて、前記ベリファイ手段の所定数は３であり、
前記ベリファイリストは、ペアフラグを備え、
いずれかの処理端末若しくは操作者から文字データが送信されたときに、
該当するファイル名のベリファイリストがない場合には、ベリファイリストを生成し、
該当するファイル名のベリファイリストが存在し、かつ同一の文字データがある場合に、前記ペアフラグが立っていない場合にはその文字データ及び一致する文字データにそれぞれペアフラグを立て、
該当するファイル名のベリファイリストが存在し、かつ同一の文字データがある場合に、前記ペアフラグが立っている場合には、当該入力された文字データ及びペアフラグが立てられた文字データを有効とすることを特徴とする手書き文字入力処理システム。
【請求項１５】
請求項１２乃至請求項１４のいずれか１項に記載の手書き文字入力処理システムにおいて、
前記ベリファイ手段において、入力された文字ファイルと同一ファイル名のイメージファイルの処理依頼数が所定の限度数に達したときには、前記ベリファイ手段のベリファイ処理を中止することを特徴とする手書き文字入力処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、手書き文字入力処理システムに係り、詳しくは、データの部分、部分をそれぞれ処理に合わせて多段階的に暗号化・復号化して情報の機密性を保持しながら必要な処理を進めることができる手書き文字入力処理システムに関する。
【０００２】
特に、個人情報保護法等による規制が厳しい個人情報を扱う、例えば、手書きによる契約書・申込書などのいわゆるデータエントリー業務で、依頼主以外には個人情報を個人情報として利用できる形ではまったく開示することなく、かつ、必要最小限の開示でデータエントリー業務を円滑に処理することを可能とする手書き文字入力処理システムに関するものである。
【背景技術】
【０００３】
従来よりＯＣＲ（Optical Character Reader）で手書き文字を自動認識する方法があり、その認識率も高まっている。そのため、郵便番号による郵便物の自動仕分けやアンケートの集計など広く用いられ、人的負担を著しく軽減している。
【０００４】
だが、契約書などの重要書類においては誤りがあった場合の影響が大きく誤認識が許されない。そのため、このような重要書類の場合には最終的には人間の目で一つひとつ確認して、コンピュータにデータとして手入力する手書き文字入力処理システムによる作業が現に行なわれている。この作業は単純ではあるが極めて煩雑でかつ誤りが許されない作業であり、人の肉眼による認識が必須であるため大きな人的負担が要求された。
【０００５】
一方、契約書などは通常その法人や個人の個人情報が含まれており、特にわが国では個人情報の保護を目的として個人情報保護法が平成１７年４月から施行されている。このような状況では個人情報を第三者に開示できなくなり、データエントリー（手書き文字入力処理）を安易に第三者に外注することもできない。
【０００６】
そこで、特許文献１に示すようなものが提案されている。まず、ファクシミリで送信された為替処理に関するイメージデータを中央制御装置によって特定の個人情報として把握できない程度に分割し、それぞれに対応する修正装置に配信されて文字認識が行われる。そして、それぞれ別の修正操作員による確認・修正処理が行われる。修正済みの文字認識結果は中央制御装置に送信され、この中央制御装置で統合され元の帳票に対応する帳票データが生成される。この発明では、元の帳票を分割してそれぞれに対応する修正装置に配信されて文字認識が行われるため、特定の個人情報として把握できない状態で処理することができる。
【特許文献１】特開２００２−７４２６３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記ファクシミリ文字読取システムでは、定型・単一の振込依頼書のイメージデータを複数の領域に分割する分割処理部と、修正結果を統合して元の振込依頼書の認識結果を生成する統合処理部の存在の開示はあるものの、実際にどのようにして分割、統合するかその構成は明らかにされていない。多数の人間により多数の帳票を処理する場合、元の帳票を分割したイメージデータは、どの帳票のデータなのかわからなければ、文字認識後に元の帳票データに統合できない。結局、いくら分割したところで容易に統合されて個人情報が流出してしまうことになる。
【０００８】
もちろん、データを暗号化してしまえば、情報の漏洩はなくても、帳票の読取り自体ができない。
本発明は、依頼先から依頼された機密が保持されるべき個人情報に関する用紙の手書き文字を多数の人間により処理する場合に、データを部分、部分でそれぞれ処理に合わせて多段階的に暗号化・復号化して情報の機密性を保持しながら処理を進めることができる手書き文字入力処理システムを提供する。
【０００９】
特に、個人情報保護法等による規制が厳しい個人情報、例えば、手書きによる契約書・申込書などの文字のデータエントリー業務において、依頼主以外には個人情報を個人情報として利用できる形ではまったく開示することがない。かつ、データの入力、ベリファイ等の一連の作業を受託した企業はもちろん、管理しにくい社外の外注先でも安全に処理することを担保する。
【００１０】
併せて、個人情報を依頼主社内においても、暗号の鍵を可視化された状態で物理的に確実な方法で簡易に管理できる手書き文字入力処理システムを提供することも目的とする。
【課題を解決するための手段】
【００１１】
上記課題を解決するため、請求項１に記載の手書き文字入力処理システムでは、複数の入力端末と管理コンピュータと複数の処理端末とからなり、任意の入力端末に接続されたイメージスキャナからイメージデータが入力された用紙を、管理コンピュータを介していずれかの処理端末でその一部を表示し、当該処理端末の操作者に目視で文字を認識させて入力させた文字データを前記管理コンピュータを介して前記任意の入力端末から文字データとして出力する手書き文字入力処理システムであって、前記入力端末は、前記イメージスキャナにより文字が記載された用紙のイメージデータを読取る用紙スキャン手段と、読取ったイメージデータの予め文字が記載される位置として特定された複数の文字領域からそれぞれイメージデータを切出すとともに、そのイメージの属性を示す固有のファイル名を付与する切出し手段と、切出したイメージファイルのファイル名を所定の文字列に分割し、当該分割した文字列をそれぞれを異なる鍵を用いて暗号化するファイル名暗号化手段と、ファイル名が暗号化されたイメージファイルを管理コンピュータに送信するイメージファイル送信手段とを備えたことを要旨とする。
【００１２】
この発明によれば、１枚の用紙から切出されたイメージファイルは、イメージの属性を示すファイル名が所定の文字列に分割されて暗号化されるため、処理の段階に応じ多段階的に暗号化・復号化して情報の機密性を保持しながら処理を進めることができる。
【００１３】
請求項２に記載の発明では、請求項１に記載の手書き文字入力処理システムにおいて、前記ファイル名暗号化手段において、暗号化された暗号文は、制御コードを含まない文字コードからなる文字セットによることを要旨とする。
【００１４】
この発明によれば、暗号文に制御コードを含まないようにしたため、ファイル名を制御コードにしたために由来する不本意なトラブルを回避することができる。
請求項３に記載の発明では、請求項１又は請求項２に記載の手書き文字入力処理システムにおいて、前記切出し手段において、イメージの属性を示す固有のファイル名には、入力された複数の用紙のうちのいずれの用紙から切出されたかを示す文字列である用紙特定ＩＤコードを含む文字列を含み、前記ファイル名暗号化手段において暗号化に用いる鍵は、当該用紙特定ＩＤコードを含む文字列の暗号化に用いる第１の鍵と、それ以外の文字列を暗号化する第２の鍵を含むことを要旨とする。
【００１５】
この発明によれば、第１の鍵により暗号化した用紙の復元に必須の文字列部分は、第２の鍵で暗号化される入力端末を識別する部分とは、処理段階に応じてそれぞれ別個に暗号化復号化ができるため、適切な暗号化復号化ができる。
【００１６】
請求項４に記載の発明では、請求項３に記載の手書き文字入力処理システムにおいて、前記用紙特定ＩＤコードを含む文字列には、そのイメージデータがいずれの文字領域から切出されたかを示すパーツＩＤコードをさらに含むことを要旨とする。
【００１７】
この発明によれば、用紙特定ＩＤコードとパーツＩＤコードによる文字列が暗号化されるため、常にその暗号文が異なったものとなるため、セキュリティーが向上する。
請求項５に記載された発明では、請求項３又は請求項４に記載の手書き文字入力処理システムにおいて、前記第１の鍵を前記入力端末に接続された可搬型記憶媒体に記憶するとともに、当該入力端末の記憶媒体から第１の鍵の記憶を消去することを要旨とする。
【００１８】
この発明によれば、元データから分離された形で第１の鍵が可搬型記憶媒体のみに残されるため、鍵が可視化され、鍵のみを管理すればよいので管理が容易になる。
なお、ここで可搬型記憶媒体とは、入力端末から分離できる可搬型記憶媒体を含み、例えばＵＳＢメモリ、ＳＤカード、フラッシュメモリ、スマートメモリなどのＥＥＰＲＯＭによる記憶媒体、ハードディスクドライブによる記憶媒体、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ、フレキシブルディスクなどをも含む。
【００１９】
請求項６に記載の発明では、請求項５に記載の手書き文字入力処理システムにおいて、前記可搬型記憶媒体は、ＵＳＢメモリであることを要旨とする。
この発明によれば、ＵＳＢメモリであれば、記憶媒体がコンパクトであり、且つパスワードによりセキュリティーをさらに高めることもでき、また自動的に処理を行なうプログラムを記憶することもできる。
【００２０】
請求項７に記載の発明では、請求項１乃至請求項６のいずれか１項に記載の手書き文字入力処理システムにおいて、前記入力端末は、前記イメージファイルのうち切出したイメージデータの部分を第３の鍵により暗号化するイメージデータ暗号化手段をさらに備えたことを要旨とする。
【００２１】
この発明によれば、イメージデータを暗号化したことで、管理コンピュータに、処理に不必要なデータの内容を開示することがない。
請求項８に記載の発明では、請求項１乃至請求項７のいずれか１項に記載の手書き文字入力処理システムにおいて、前記入力端末は、前記ファイル名が暗号化された複数のイメージファイルを逐次入力端末の記憶手段のフォルダに蓄積する蓄積手段と、当該フォルダに蓄積された複数のイメージファイルのタイムスタンプを共通化した後に順序を並べ直す再ソート手段と、再ソートされたイメージファイルを前記管理コンピュータに送信するイメージファイル送信手段とを備えたことを要旨とする。
【００２２】
この発明によれば、タイムスタンプによる時間情報からファイル生成の時系列の関係が分かり切出し前の用紙を推測される可能性がなくなり、より高いセキュリティーを確保できる。
【００２３】
請求項９に記載の発明では、請求項７に記載の手書き文字入力処理システムにおいて、前記処理端末は、管理コンピュータからイメージファイルを受信する受信手段と、受信したイメージファイルのイメージデータのみを第３の鍵で復号化して揮発性記憶媒体のみに記憶する復号化手段と、復号化したイメージデータを表示する表示手段と、表示されたイメージに対応してオペレータからの文字入力を受け付けて文字データとして記憶する文字入力手段と、当該文字入力手段から入力された文字データに対応するイメージデータを消去する消去手段と、入力された文字データを第４の鍵で暗号化するとともに、前記受信したイメージファイルのファイル名と同じファイル名を付与した文字ファイルを生成する文字ファイル生成手段とを備えたことを要旨とする。
【００２４】
この発明によれば、イメージファイルに係るイメージは必要最小限復号化され、記録としても残らない。また文字データも直ちに暗号化されるため、処理端末外はもちろん、処理端末自体においてもセキュリティーが保たれる。
【００２５】
請求項１０に記載の発明では、請求項３乃至請求項６のいずれか１項に記載の手書き文字入力処理システムにおいて、前記管理コンピュータは、前記入力端末から送信されたイメージファイルを受信するとともに、前記第２の鍵でファイル名の一部を復号化して記憶するイメージファイルデータベースを備え、処理端末からの読取り処理の要求であるジョブ要求のあった処理端末を識別する処理端末コード若しくは操作者を識別する操作者コードを、処理依頼したイメージファイルのファイル名とともに記憶して、いずれのイメージファイルをいずれの処理端末若しくは操作者に処理依頼したかを記憶する処理依頼履歴ファイルを備え、前記イメージファイルを受信する未処理データ受信手段と、前記処理端末のいずれかからの処理端末コード若しくは操作者コードとともに送信されたジョブ要求により、前記処理依頼履歴ファイルを参照して当該処理端末若しくは操作者に既に送信したイメージファイルを排除する重複排除手段と、イメージファイルを前記イメージファイルデータベースからファイル名に含まれた属性を示す文字列を参照して所定の基準に従って選択する選択手段とにより処理依頼すべきイメージファイルを選択して依頼する未処理データ処理依頼手段を備えたことを要旨とする。
【００２６】
この発明によれば、処理を異なる操作者に適切に依頼することで、より信頼度の高い客観的なデータを得ることができる。
請求項１１に記載の発明では、請求項１０に記載の手書き文字入力処理システムにおいて、前記未処理データ処理依頼手段において、イメージファイルを処理依頼する所定の基準は、前記ジョブ要求に含まれる文字入力制限のタイプを基準の一つとすることを要旨とする。
【００２７】
この発明によれば、文字入力の制限、例えば、年齢や〒番号のように文字をアラビア数字のみに制限したり、アルファベットのみに制限，若しくはカタカナ、漢字など文字の難易度などに分けて、オペレータの処理をスキル・知識のレベルに合わせた適切な処理とすることが可能となる。
【００２８】
請求項１２に記載の発明では、請求項１乃至請求項１１のいずれか１項に記載の手書き文字入力処理システムにおいて、前記管理コンピュータは、前記処理端末から送信された文字ファイルを受信する文字ファイルデータベースと、当該処理端末から文字ファイルが送信されたときに、各処理端末から受信した文字ファイルのファイル名を参照して、管理コンピュータが初めて受信したファイル名である場合には、当該文字データを処理端末コード若しくは操作者コードとともに記憶するベリファイリストを生成し、同一文字ファイルに係る文字データを比較して、一致する文字データの一致数が所定数以上となった場合に、入力された文字データを有効なデータとして送信ファイルに記憶するとともに、当該文字データに係る処理端末若しくは操作者をオペレータデータベースに記録するベリファイ手段を備えたことを要旨とする。
【００２９】
この発明によれば、ベリファイ手段を備えることで、データの信頼性を自動的に判定してデータの信頼性を高めることができる。
請求項１３に記載の発明では、請求項１２に記載の手書き文字入力処理システムにおいて、前記管理コンピュータは、前記ベリファイ手段において、文字データが暗号化されている場合でも文字データの比較は復号化することなく暗号化された文字データ同士を比較することを要旨とする。
【００３０】
この発明によれば、管理コンピュータにおいては、イメージデータの段階でも、文字データの段階でも一切内容を開示することなく、ベリファイ処理まで行なうことができるため、極めて高いセキュリティーを確保できる。
【００３１】
請求項１４に記載の発明では、請求項１２又は請求項１３に記載の手書き文字入力処理システムにおいて、前記ベリファイ手段の所定数は３であり、前記ベリファイリストは、ペアフラグを備え、いずれかの処理端末若しくは操作者から文字ファイルが送信されたときに、該当するファイル名のベリファイリストがない場合には、ベリファイリストを生成し、該当するファイル名のベリファイリストが存在し、かつ同一の文字データがある場合に、前記ペアフラグが立っていない場合にはその文字データ及び一致する文字データにそれぞれペアフラグを立て、該当するファイル名のベリファイリストが存在し、かつ同一の文字データがある場合に、前記ペアフラグが立っている場合には、当該入力された文字データ及びペアフラグが立てられた文字データを有効とすることを要旨とする。
【００３２】
請求項１５に記載の発明では、請求項１２乃至請求項１４のいずれか１項に記載の手書き文字入力処理システムにおいて、前記ベリファイ手段において、入力された文字ファイルと同一ファイル名のイメージファイルの処理依頼数が所定の限度数に達したときには、前記ベリファイ手段のベリファイ処理を中止することを要旨とする。
【００３３】
この発明によれば、難読の場合は、無理に有効なデータとしないようにして、データの信頼性を高めることができる。
【発明の効果】
【００３４】
本発明の手書き文字入力処理システムによれば、依頼先から依頼された機密が保持されるべき個人情報に関する書類の手書き文字を多数の人間により処理する場合に、データを部分、部分でそれぞれ処理に合わせて多段階的に暗号化・復号化して情報の機密性を保持しながら処理を進めることができる。
【発明を実施するための最良の形態】
【００３５】
（第１の実施形態）
以下、本発明を具体化した手書き文字入力処理システムの一実施形態を図１〜図２５にしたがって説明する。
【００３６】
（発明の概略）
まず、詳細な説明に先立ち本発明に係る手書き文字入力処理システム（以下、「本システム」と略記することがある。）についての概略を説明する。図１は、本システムの全体の構成を示す。本システムは、多数の手書き文字の用紙Ｓをコンピュータ処理可能なディジタルデータとするためのシステムである。
【００３７】
このシステムを構成するハードウエアとしては、まず、処理を依頼したい企業で手書き用紙のイメージデータ（例えば、ＪＰＥＧデータ、本願で「イメージデータ」という場合は、「イメージファイル」のうちの、「ファイル名」を除くコンテンツとしてのイメージ自体を構成するデータをいう。）の入力をイメージスキャナを介して行なう入力端末である複数のクライアント２がインターネット４に接続される。また、入力されたイメージデータをオペレータ（操作者）が目視して実際にコンピュータ処理可能なディジタルデータである文字データ（例えば、テキストデータ、本願で「文字データ」という場合は、「文字ファイル」のうちの、「ファイル名」を除くコンテンツとしての文字自体を構成するデータをいう。）としてキー入力する処理端末としての複数のエントリーコンピュータ３もインターネット４に接続される。
【００３８】
そして、インターネット４を介してクライアント２、エントリーコンピュータ３を管理する管理コンピュータであるデータセンタ１もまたインターネット４に接続されている。
このようなハードウエアの構成において、次のような手順で処理がなされる。まず、いずれかのクライアント２のイメージスキャナ２６（図２参照）から用紙Ｓのイメージデータ（ワンシートデータ）が入力される。すると直ちに文字領域ＣＡ（パーツデータ）が抽出され、切り出された元の用紙Ｓを特定する用紙特定ＩＤ（ここで、本願で単に「ＩＤ」というときは、付されたものを特定する唯一ユニークな文字列からなる「ＩＤコード（identification code ）」をいう。他のＩＤも同様である。）を含む属性がファイル名として記録される。それぞれのイメージファイル（パーツデータ）は第１の鍵で用紙特定ＩＤを含むファイル名の文字列が、第２の鍵でその他のファイル名の文字列が、第３の鍵でイメージデータ（コンテンツ）がそれぞれ暗号化される。この暗号化されたイメージファイルは、データセンタ１で第２の鍵で一部が復号化され、復号化された属性情報からもっとも適当なエントリーコンピュータ３が選択される。そしてこの選択されたエントリーコンピュータ３に再びファイル名が第２の鍵で暗号化されて処理が依頼される。エントリーコンピュータ３の表示装置３３で第３の鍵によりその文字領域ＣＡが表示される。当該エントリーコンピュータ３の操作者により目視で文字が認識されて入力装置３４であるキーボードから入力される。この文字データを直ちに第４の鍵で暗号化するとデータセンタ１を介してイメージデータが入力されたクライアント２に納品される。クライアント２では、第１の鍵、第２の鍵から入力された用紙Ｓを復元し、第４の鍵で文字データとして出力するものである。
【００３９】
なお、第１の鍵は、暗号化された後、ＵＳＢメモリ２８（図２参照）に記憶されるとともに、クライアント２の端末からは消去される。そして、ＵＳＢメモリ２８は、この端末から物理的に分離され、例えば金庫のような場所に保管される。用紙Ｓの復元はこのＵＳＢメモリ２８のみに記憶された用紙特定ＩＤがなければ不可能である。つまり、ディジタルデータである第１の鍵をＵＳＢメモリ２８という有体物として管理することで第１の鍵を可視化して管理を容易かつ確実にすることができる。このことで、初めてクライアント２の管理者は安心して処理を社外で行わせることが可能となる。
【００４０】
このように本発明では、依頼先から依頼された機密が保持されるべき個人情報に関する用紙の手書き文字を多数の人間により処理する場合に、データを部分、部分でそれぞれの処理に合わせて多段階的に暗号化・復号化して情報の機密性を保持しながら処理を進めることができる。
【００４１】
次に、本手書き文字入力処理システムの詳しい構成を説明する。
（全体構成）
図１に示すように、クライアント２はインターネット４を介してデータセンタ１と接続されている。また、データセンタ１は、インターネット４を介してハブ（HUB ）によりエントリーセンタ３７内に設置されたエントリーコンピュータ３と接続される。また、エントリーセンタ３７に限らず、ＳＯＨＯ（Small Office Home Office）１，ＳＯＨＯ２…に設置された単体のエントリーコンピュータ３などであってもよい。ここでは、エントリーセンタ３７を中心に説明する。
【００４２】
本システムの基本的な構成は、データセンタ１をサーバコンピュータとし、クライアント２及びエントリーコンピュータ３をクライアントとしたサーバクライアントシステムとして構築されている。それぞれは、ＴＣＰ／ＩＰのプロトコルでＨＴＴＰ（Hyper Text Transfer Protocol）やＦＴＰ（File Transfer Protocol）により送受信できるように構成されている。但し、クライアント２には、クライアントアプリケーションプログラム（以下、「ＣＡＰ」と略記することがある。）、データセンタ１には、サーバアプリケーションプログラム（以下、「ＳＡＰ」と略記することがある。）、エントリーコンピュータ３には、エントリーアプリケーションプログラム（以下、「ＥＡＰ」と略記することがある。）と呼ばれる専用のプログラムがインストールされているが、これらは後に詳述する。
（クライアント）
クライアント２は、多量の用紙Ｓを紙での情報として処理する必要がある企業のコンピュータ端末である。この用紙Ｓは、例えば、損害保険や生命保険の申込み用紙、ローンの申込み用紙、各種の契約書など、本人の意思確認を裏付ける意味から自筆での記入が要求されるものが例に挙げられる。
【００４３】
図２に示すようにクライアント２は、ＣＰＵ（Central Processing Unit ）２１と、インターネット４と接続するゲートウェイ２２、液晶ディスプレイなどからなる表示装置２３、キーボードなどからなる入力装置２４を備える。また、ＨＤＤ（Hard Disk Drive ）などからなる記憶手段である記憶装置２５、用紙を光学的に読取るイメージスキャナ２６、外部装置等とのインタフェイスであるＵＳＢ（Universal Serial Bus）２７と、ここに接続された可搬型記憶媒体であるＵＳＢメモリ２８を備える。
【００４４】
記憶装置２５は、下記のような各種のプラグラムやデータを記憶する。
プログラムファイル２５ｄには、図３に示すようにクライアントアプリケーションプログラム（ＣＡＰ）を構成するプログラムが記憶されている。具体的には、１つにはＣＰＵ２１を用紙スキャン手段として機能させワンシートデータを生成する用紙読込み制御プログラムを含む。また、ＣＰＵ２１を切出し手段として機能させ、パーツデータを生成する座標切出しプログラムを含む。さらに、ＣＰＵ２１をファイル名暗号化手段・イメージデータ暗号化手段として機能させるパーツデータ暗号化・復号化プログラムを含む。また、圧縮解凍プログラム（アーカイバ、例えばＺＩＰ（PKWare社の登録商標）など）を含む。そして、ＣＰＵ２１をイメージファイル送信手段として機能させるＦＴＰのファイル転送プログラムを含む。そして、上記プログラムをＣＡＤとして統括的に管理するシステムのＯＳ（Operation System）などのプログラムを記憶する。
【００４５】
プレーンフォルダ（Plain Folder）２５ａは、用紙Ｓ全体のイメージファイル（以下適宜「ワンシートデータ」という。）を暗号化しない平文でそのまま記憶する。ワンシートデータは、用紙読込み制御プログラムの例えばＴＷＡＩＮ（Tool Without An Interesting Name）による所定の手順でイメージスキャナ２６を制御して、用紙ＳをスキャンしたスキャンデータをJPEG形式の平画像のままプレーンフォルダ２５ａに記憶したものである。また、用紙読込み制御プログラムにより用紙スキャン入力に併せて、スキャンする用紙Ｓの属性をキーボードやマウスで入力させ、この「クライアントＩＤ，支店ＩＤ，部署ＩＤ、用紙ＩＤ、用紙特定ＩＤ」からなるファイル名が付与される。
【００４６】
このプレーンフォルダ２５ａに記憶されたスキャンデータ（ワンシートデータ）は、例えば３００dpi の解像度の「法定書類保存記録ファイル」のオリジナルデータとして、法定の要件を満たしたペーパーレスシステムとして活用できる。また、手書き文字のデータ化の後に疑義があった場合の照合用のオリジナルデータとして用いることができる。ただし、このステップは任意であり、省略してもよい。
【００４７】
サイファフォルダ２５ｂは、ＣＰＵ２１が読取ったワンシートデータから、座標切出しプログラムにより文字領域ＣＡをパーツデータとして抜出されリネームし、パーツデータ暗号化プログラムにより、暗号化されたものが記憶される。
【００４８】
設定フォルダ２５ｃは、入力する用紙の種類、大きさやパーツデータとして切出す文字の座標など、クライアント２での初期設定のデータが予め記憶されている。
文字ファイル受信フォルダ２５ｅは、データセンタ１から送信された文字ファイルを受信したものが文字データが復号化されて記憶されている。
（データセンタ１）
データセンタ１は、図４に示すようにＣＰＵ１１と、インターネット４と接続するゲートウェイ１２と、液晶ディスプレイなどからなる表示装置１３、キーボードなどからなる入力装置１４、ＨＤＤなどからなる記憶手段である記憶装置１５を備える。
【００４９】
記憶装置１５は、下記のような各種のプラグラムやデータを記憶する。
図５に示すように、プログラムファイル１５ａは、サーバアプリケーションプログラム（ＳＡＰ）を構成するプログラムが記憶されている。まず、圧縮解凍プログラムを含む。また、ＣＰＵ１１を未処理データ受信手段として機能させて入力データをデータベースに登録するデータベース管理プログラムを含む。さらに、ＣＰＵ１１を重複排除手段、選択手段、未処理データ処理依頼手段として機能させて未処理データの処理依頼をする未処理データ処理依頼プログラムも含む。さらに、ＣＰＵ１１をベリファイ手段として機能させるベリファイプログラムも含む。また、パーツデータのファイル名の復号化・暗号化を行う暗号化復号化プログラムを含む。さらに、ＦＴＰによるファイル転送プログラムを含む。そして、上記プログラムをＳＡＰとして統合的に管理するサーバシステムのＯＳ（Operation System）などのプログラムを記憶する。
【００５０】
図６に示す、クライアントＤＢ（データベース）１５ｂは、各クライアントの企業情報や認証情報、処理件数、課金金額等が統合的に記憶された関係データベースである。
オペレータＤＢ１５ｃは、各エントリーコンピュータ３を操作しているオペレータ（操作者）毎に、オペレータを管理する個人情報や認証情報、処理件数、評価、支払い額等が統合的に記憶された関係データベースである。
【００５１】
イメージファイルＤＢ１５ｄは、各クライアント２から送信された未処理のパーツデータのイメージファイルをフォルダ毎に記憶して管理している。
依頼人数ファイル１５ｅは、未処理のイメージファイルを何人のエントリーコンピュータ３のオペレータに処理依頼が可能かを示す情報を記憶する。
【００５２】
処理依頼履歴ファイル１５ｆ（図２２）は、どのエントリーコンピュータ３のオペレータにどのファイル名の未処理のイメージフィルを依頼したかの履歴が記録されている。
ベリファイリスト１５ｇは、エントリーコンピュータ３で処理されたいずれの文字データが有効か判定するために、ファイル名、オペレータＩＤ、文字データ、ペアフラグ、有効フラグが記憶されている。
【００５３】
難読リスト１５ｈは、ベリファイができなかったイメージファイルについて記憶するフォルダである。
文字ファイルＤＢ（データベース）１５ｉは、エントリーコンピュータ３から送信されたベリファイ前の文字ファイルがフォルダ毎に記憶されている。
【００５４】
送信フォルダ１５ｊは、ベリファイが完了して有効とされた文字ファイルが所定のクライアント２に送信するためフォルダに蓄積して記憶される。
（エントリーセンタ）
エントリーセンタ３７には多数のエントリーコンピュータ３がハブ３６によりＬＡＮ接続されている。但し、実際の処理は、このうちのいずれか１台により処理される。各エントリーコンピュータ３はＣＰＵ３１により処理を行う。ゲートウェイ３２は、図示しないルータ、ファイヤウォールを含み、データセンタ１とインターネット４を介していずれかのエントリーコンピュータ３が特定されて通信するためのインタフェイスである。
【００５５】
また、パーツデータのイメージを表示する液晶ディスプレイなどからなる表示装置３３、文字データを打ち込むためのキーボードなどからなる入力装置３４、ＨＤＤなどからなる記憶手段である記憶装置３５を備える。
【００５６】
図７に示すように、記憶装置３５のプログラムファイル３５ａには、エントリーコンピュータ３として機能させるためのエントリーアプリケーションプログラム（ＥＡＰ）が記憶されている。このＥＡＰは、圧縮、解凍を行う圧縮解凍プログラムを含む。また、ＣＰＵ３１を、受信手段、表示手段、文字入力手段、文字ファイル生成手段、消去手段として機能させてデータセンタにジョブ要求をしてイメージデータの取得・表示、文字データの入力を行うイメージ表示・文字入力プログラムを含む。また、ＣＰＵ３１をイメージファイルの復号化手段、文字データの暗号化手段として機能させて、イメージファイルの復号化・文字データの暗号化を行う暗号化復号化プログラムを含む。さらにＦＴＰによるファイル転送プログラムを含む。そして、上記プログラムをＥＡＰとして統括的に管理するクライアントコンピュータとしてのＯＳ（Operation System）のプログラムを記憶する。
【００５７】
また、図９に示す記憶装置３５にはその他図示しないデータの処理・記憶のためのプログラム、記憶領域を備える。
（本手書き文字入力システムの処理の手順）
次に、以上のように構成された手書き文字入力処理システムの処理について説明する。
【００５８】
図８は、本システムの代表的な処理の手順をフローチャートで示したものであり、このフローチャートに沿って、本システムのメインルーチンを説明する。
（クライアント登録Ｓ１）
まず、最初にデータセンタ１でクライアント登録をする（Ｓ１）。図９は、クライアント登録（Ｓ１）の手順を詳細に示すフローチャートである。クライアント登録（Ｓ１）は、最初にいずれかのクライアント２（この段階では正確には「クライアント２になるべき端末」であるが、ここでは便宜上「クライアント２」という。）がウエブ上のデータセンタ１にアクセスし、データセンタ１は、所定の情報を登録する（Ｓ１０１）。具体的には、クライアント２は、ウエブブラウザにより所定のＵＲＬ（あるいはＩＰアドレス）のデータセンタ１にアクセスする。データセンタ１はＣＧＩにより、https のプロトコルで新規クライアントからの情報（名称、支店名、部署名のほか、郵便番号、住所、電話番号、電子メールアドレス、クライアント端末のＩＰアドレス、MAC アドレス、担当者等ＩＤ、パスワード）を受信する。これらのデータは、データセンタ１のクライアントＤＢ１５ｂに登録される。
【００５９】
そして、クライアント２に図３に示すクライアントアプリケーションプログラム（ＣＡＰ）をダウンロードして、クライアント２のプログラムファイル２５ｄにインストールさせる（Ｓ１０２）。つぎに、クライアント２ではＣＡＰのＯＳにより初期設定を行い、その内容をクライアント２の設定フォルダ２５ｃに記憶する（Ｓ１０３）。設定フォルダ２５ｃに記憶された設定は、クライアント２の起動時に自動的に読み込まれてＣＡＰの初期設定がなされる。
【００６０】
データセンタ１では、このクライアント２からの初期設定の完了通知を認証し、認証後、登録されたクライアントの企業、支店、部署、担当者に対して、それぞれクライアントＩＤ、支店ＩＤ、部署ＩＤ、担当者ＩＤを付与する。以上で個人ＩＤの登録が完了する（Ｓ１０４）。
【００６１】
（クライアントデータ入力処理Ｓ２）
データセンタ１でのクライアント登録が終わると図８のクライアントデータ入力処理Ｓ２が可能となる。クライアント２で処理したい用紙Ｓが発生したらクライアントデータ入力処理を行なう（Ｓ２）。図１０に、クライアントデータ入力処理（Ｓ２）の手順を詳細に示す。
【００６２】
＜入力用紙設定＞クライアントデータ入力処理（Ｓ２）では、まず、が行われる。ここでは、図２に示すイメージスキャナ２６から入力する用紙Ｓの大きさ、例えば、Ａ４サイズなどが決定される。キー入力しても良いし、イメージスキャナ２６から自動検出して入力してもよい。
【００６３】
次に、入力される用紙Ｓが１枚サンプルとしてスキャン入力され、クライアントアプリケーションプログラム（ＣＡＰ）（図３）の座標切り出しプログラムは、その画像を表示装置２３に表示する。
【００６４】
ここで、図１１は、表示装置２３に表示された用紙Ｓの一例を示す。この用紙Ｓには、氏名を手書きする文字領域ＣＡ１、住所を手書きする文字領域ＣＡ２、電話番号を手書きする文字領域ＣＡ３等が存在する。文字領域を登録するには画面上に表示された座標（ｘ１，ｙ１）の位置をマウスでクリックし、そのまま座標（ｘ２、ｙ２）の位置までドラッグしてリリースする。そうして、この文字領域に図示しない画面で項目名を、例えば「氏名」とキー入力する。同様に、文字領域ＣＡ２、ＣＡ３もそれぞれ範囲を指定して、項目名を「住所」「電話番号」のようにキー入力する。ＣＡＰは、このように入力された座標と名称を記憶する。この際、それぞれ文字領域ＣＡ１〜ＣＡ３には、それぞれパーツＩＤコードが「０００１」「０００２」「０００３」のように付与される。また、文字領域に入力制限を付加することもできる。例えば、電話番号には、数字、ハイフン、括弧以外の文字が入力されたら、エラーとする。例示されたもの以外でも、「フリガナ」では、カタカナ及び特定の記号以外の入力はエラーとする。この入力制限は、後に行う文字入力時に入力制限を行うため、「制限コード」が付与される。また、後述するジョブ要求の場合の依頼するイメージファイルの選択時にも文字種が参照される。
【００６５】
また、用紙に「申込み用紙」のように名称をつけて登録しておく。この名称は、ＣＡＰから例えば８桁の文字列からなる固有の用紙ＩＤが付与される。次回、同じ用紙を入力する場合は、ＣＡＰは、入力用紙設定（Ｓ２０１）において、登録済み候補として表示して選択するだけで入力用紙設定（Ｓ２０１）ができるようにする。以上で入力用紙設定（Ｓ２０１）が完了する。
【００６６】
＜用紙スキャン＞続いて、入力する用紙Ｓをイメージスキャナ２６のオートシートフィーダＡＳＦ（図示略）にセットして、ＣＡＰの用紙読込み制御プログラムにより連続して用紙をスキャンして読み込ませる（Ｓ２０２）。
【００６７】
＜ワンシートデータ作成＞このようにして読み込まれた用紙Ｓは、それぞれＪＰＥＧ形式のワンシートデータが作成される（Ｓ２０３）。これらのワンシートデータには、それぞれ固有の文字列によるファイル名が付される。このファイル名は、図２５に示すように、クライアントＩＤ，支店ＩＤ，部署ＩＤに加え、用紙Ｓの種類を特定する用紙ＩＤ、用紙Ｓを一枚一枚を特定する用紙特定ＩＤが属性としてファイル名に反映される。これらのＩＤは、それぞれ所定文字数、例えば各８文字分が与えられ、一連の文字列としてファイル名とされる。なお、各ＩＤは、コード化されているので、文字列を見ただけではいずれのクライアントの書類であるかは、データセンタなどが所有しているテーブルがない限り判別はできない。  このワンシートデータは、クライアント２のプレーンフォルダ２５ａに記憶される。
【００６８】
＜パーツデータ作成＞続いて、ＣＡＰは、座標切り出しプログラムを起動して、予め入力用紙設定で設定された文字領域ＣＡの座標に従ってイメージデータを切出し、ファイル名をリネームする。このリネームは、先に付されたファイル名に、さらに項目名を示すコードであるパーツＩＤが付加される。パーツＩＤは、項目名をコード化した物であるが、この実施例ではさらにこの項目の文字入力制限の情報をコード化して制限コードとして付与するようにしている。したがって、この制限コードを見れば、例えば電話番号のように数字のみの入力を認めるような入力制限の情報がファイル名を見ただけで判別できることになる。このパーツＩＤと制限コードは、図２５に示すように用紙ＩＤと用紙特定ＩＤの間に、制限コード、パーツＩＤの順に配列される（図２５参照）。このようにしてＪＰＥＧ形式のパーツデータのイメージファイルが作成される（Ｓ２０４）。
【００６９】
＜イメージデータの第３の鍵による暗号化＞続いて、ＣＡＰのパーツデータ暗号化・復号化プログラムが起動されて、パーツデータのファイル名はそのままで、イメージデータ（ＪＰＥＧ画像）が暗号化される（Ｓ２０５）。暗号化には、例えば、ＤＥＳ（Data Encryption Standard）がある。また、ＡＥＳ（Advanced Encryption Standard）、３−ＤＥＳ、ＭＩＳＴＹ１、ＩＤＥＡ（International Data Encryption Algorithm ）、ＦＥＡＬ（Fast data Encipherment ALgorithm）などの秘密鍵（共有鍵）を用いた方法が採用できる。ここで用いる暗号化の鍵を以下「第３の鍵」という。
【００７０】
＜ファイル名の第１の鍵による暗号化＞次に、ファイル名の第１の鍵による暗号化を行う（Ｓ２０６）。ファイル名は、前述のようにパーツデータの属性、すなわち用紙Ｓの出所、用紙Ｓの種類を特定する用紙ＩＤの他、その用紙Ｓの一枚一枚を特定する用紙特定ＩＤ、入力が制限される文字を示す制限コード、どの項目（文字領域ＣＡ）のデータであるかを特定するパーツＩＤが含まれている（図２５参照）。仮に、エントリーコンピュータ３のオペレータに悪意があり、入力に使ったイメージファイルを収集してこの用紙特定ＩＤとパーツＩＤを解析すれば、元の用紙Ｓの全体が復元できることになる。
【００７１】
一方、ファイル名のすべてを暗号化すればこの用紙特定ＩＤもわからないので、当然元の用紙Ｓは復元できない。しかし、データセンタ１でパーツデータのイメージファイルの文字入力の処理や、クライアント２への電子納品の場合に、クライアントもわからなければ識別ができず、例えば、データセンタ１でクライアント２からの受信時に別途識別する文字列を付加するなどきわめて管理が煩雑になってしまう。
【００７２】
そこで、本発明では、ファイル名に属性を示す文字列を、用紙特定ＩＤを含む文字列の部分（この例では、用紙特定ＩＤとパーツＩＤのみ）と、その他の文字列の部分に分割して、それぞれ異なる鍵により暗号化する。この場合、用紙特定ＩＤの文字列を暗号化する鍵を「第１の鍵」、それ以外の文字列を暗号化する鍵を「第２の鍵」と呼ぶ。
【００７３】
暗号化前のファイル名は、所定数の文字列になっており、それぞれ、クライアントＩＤ、支店ＩＤ、部署ＩＤ、用紙ＩＤ、制限コード、パーツＩＤ、用紙特定ＩＤの順に連続した文字列となっている。暗号化に当たっては、この文字列の所定の文字数の部分を分割することで、第１の鍵で暗号化する部分と、第２の鍵で暗号化する部分を特定する。第１の鍵で暗号化される文字列が特定されたら、その部分は一旦バイナリデータに変換し、例えばＤＥＳにより第１の鍵で暗号化される。
【００７４】
また、この暗号化において、元の文字列をバイナリデータとし、このバイナリデータを暗号化して再び文字列に置き換えたとき、制御コード、例えば「\ 」「/ 」「: 」「* 」「? 」「" 」「< 」「> 」「| 」などを含む可能性がある。これらの制御コードはファイル名には使えないため、暗号化した場合にこれらの制御コードとなった場合は、さらに制御コードではない文字コードに振り替える処理を行う。このような振替で制御コードがファイル名となる不都合を回避している。つまり制御コードを含まない文字コードからなる文字セットにより暗号化したファイル名が付される。もちろん、復号化の場合もいったん振り替えた文字コードを元の制御コードの文字コードに戻してバイナリデータとして復号化する処理を行う。
【００７５】
＜ファイル名の第２の鍵による暗号化＞第１の鍵による暗号化が終了したら、第２の鍵による暗号化を行う（Ｓ２０７）。手順は、暗号化する対象の文字列が異なるだけで、第１の鍵で暗号化を行うＳ２０６と同様の手順である。なお、第２の鍵により暗号化される文字列は、すべて同じ鍵を用いず、さらに分割してもよい。つまり第２の鍵は複数存在してもよい。
【００７６】
このように、クライアント２の内部で、データをファイル名とイメージデータに分け、さらにファイル名を分割して暗号化をする。そのため、データを部分、部分でそれぞれ処理に合わせて多段階的に暗号化・復号化して情報の機密性を保持しながら処理を進めることができる。特に、本実施形態のように個人情報保護法等による規制が厳しい個人情報、例えば、手書きによる契約書・申込書などの文字のデータエントリー業務では、クライアント２以外には個人情報を個人情報として利用できる形ではまったく開示することない。かつ、データの入力、ベリファイ等の一連の作業を受託した企業の社内はもちろん社外の外注先でも安全に処理することを可能とするものである。
【００７７】
＜書込み＞以上のように、暗号化を行ったイメージファイルは、サイファフォルダ２５ｂに書き込まれ記憶される（Ｓ２０８）。すべての読取り処理が終了までは（Ｓ２０９；ＮＯ）、Ｓ２０２〜Ｓ２０８の手順が繰り返され、すべての読取り処理が終了したら（Ｓ２０９；ＹＥＳ）、クライアントデータ入力処理（Ｓ２）を終了する。
【００７８】
続いて、図８に示すようにクライアント２では、データセンタ１へデータ送信する（Ｓ３）。
（クライアントからデータセンタへのデータ送信Ｓ３）図１２は、データ送信の手順を詳細に示すフローチャートである。まず、サイファフォルダに記憶されるイメージファイルを任意の処理単位で１つのフォルダに入れる。
【００７９】
＜タイムスタンプリセット＞ところで、本システムのクライアントのＯＳでは、ファイルを作成するとその属性を示すデータが自動的に付与される。そのうち、ファイルの作成日を記録したデータであるタイムスタンプ（time stamp）がある。このタイムスタンプは通常は有用であるが、本システムにおいては、フォルダの中のイメージファイルをその作成時間から時系列にまとめ、パーツデータ同士の関係を解析して書類の内容を復元することを有効に防止するため、イメージファイル作成の時間を記録するものである。具体的には、タイムスタンプの日付はそのまま、時刻をゼロにリセットする（Ｓ３０１）。
【００８０】
＜再ソート＞続いて、ＣＰＵ２１は、再ソート手段として機能し、イメージファイルを名前の順に再ソートする（Ｓ３０２）。このときファイル名は暗号化されているので、ランダムな文字列となっている。その文字列の順にソートされることで、順序がランダムなものとなり、元の順序はわからなくなる。そのため、他のパーツデータとの紐付けができなくなり、元の用紙Ｓの復元は不可能となる。
【００８１】
そして、このフォルダは、ＣＡＰの圧縮解凍プログラムで圧縮され、パスワードがかけられる（Ｓ３０３）。
そして、ＣＡＰのファイル転送プログラムによりデータセンタ１にアクセスして認証を要求し（Ｓ３０４）、相互に認証ができたらデータ送信される（Ｓ３０５）。
【００８２】
（データセンタでのデータ処理Ｓ４）続いて、図８のデータセンタ１におけるデータ処理（Ｓ４）について説明する。図１３は、データセンタ１でのデータ処理（Ｓ４）の手順を詳細に示したフローチャートである。図８、Ｓ３に示す手順でデータを受信する（Ｓ４０１）。このときデータセンタ１では、図５に示すサーバアプリケーションプログラム（ＳＡＰ）の圧縮解凍プログラムでフォルダを解凍して展開するとともに、受信したイメージファイルを暗号化複合化プログラムにより第２の鍵によりイメージファイルのファイル名の一部を復号化する。そして、イメージファイルＤＢ１５ｄに記憶する。ここで図１９は、イメージファイルＤＢ１５ｄの復号化前の記憶内容を概念的に示す図である。ここに記憶されたイメージファイルのファイル名は、一部復号化され図２５；Ｓ４０１に示すにようにクライアントＩＤ、支店Ｄ、部署ＩＤ、用紙ＩＤ、制限コードが平文で記憶され、パーツＩＤ、用紙特定ＩＤは暗号化されたままになる。そして、ジョブ要求に応じて制限コードが参照され、オペレータの条件、例えば数字のみの入力、漢字仮名交じり文の入力、英文の入力などの条件にあったイメージファイルが抽出されることになる。
【００８３】
続いて、データセンタ１は、いずれかのエントリーコンピュータ３から手書き文字読取り処理の要求であるジョブ要求を待つ。
いずれかのエントリーコンピュータ３からジョブ要求があったときは（Ｓ４０２）、まず、オペレータＤＢを参照してエントリーコンピュータ３の認証を行う（Ｓ４０３）。認証ができた場合は、送信するデータを選択する（Ｓ４０４）。
【００８４】
＜送信データ選択＞ここで、図１４は、送信データの選択（Ｓ４０４）の手順をさらに詳細に示すフローチャートである。
まず、ジョブ要求に応じて、イメージファイルＤＢ１５ｄから手書き文字入力処理が未処理のイメージファイルを選択するステップを実行する。このときは、所定の基準、例えば先入先出の原則で、もっとも早く記憶されたデータ等が選択されて抽出される（Ｓ４０４１）。
【００８５】
データセンタ１には、いずれのイメージファイルをいずれのオペレータに処理依頼したかを記憶する処理依頼履歴ファイル１５ｆを備えている。ここで、図２２は、処理依頼履歴ファイル１５ｆを概念的に示す図である。この処理依頼履歴ファイル１５ｆには、同一のファイル名のイメージファイルについて、いずれのオペレータに依頼したか、そのオペレータを示すオペレータＩＤが記憶されている。また、処理が終了したものには、回収フラグが立てられている。そして、ジョブ要求は、オペレータＩＤとともにされるので、この処理依頼履歴ファイル１５ｆを参照して、抽出したイメージファイルがすでにジョブ要求のあったオペレータに処理を依頼したイメージファイルであるか否かを判断する。そして、すでに処理を依頼したことがあるイメージファイルであれば処理依頼を中止し、別のイメージファイルを抽出する。一方、いまだ処理を依頼していないイメージファイルであれば処理を依頼する。重複排除手段であるＣＰＵは、このような手順によりオペレータ（操作者）のダブりのチェックである重複排除のステップを実行する（Ｓ４０４２）。
【００８６】
続いて処理依頼可能人数チェックを行う（Ｓ４０４３）。図２１は依頼人数ファイル１５ｅの内容を概念的に示した図である。ここで、依頼人数ｆは、新たにそのファイル名の処理を依頼が可能な人数の上限を示す。この上限を超えた人数に処理を依頼するとベリファイに必要のないオペレータに無駄な依頼をする可能性がある。依頼人数ファイル１５ｅは、ベリファイ処理のために、同一のファイル名のイメージファイルに対して複数のオペレータに処理を依頼するが、ベリファイが完了したあとの不必要になる処理の依頼は無駄となる。そこで、ベリファイで有効とされる一致数をここでは、「３」とする。もし、まったく処理が依頼されていないイメージファイルは、同時に３人に処理を依頼して、３人が一致すればベリファイが完了するが、この場合は処理に無駄がない。したがって、依頼人数ｆ＝３（人）となる。一方、１人でも処理が依頼されていれば、依頼人数ｆ＝２（人）となる。さらにベリファイリスト１５ｇにペアフラグが立っているときには、あと１人で有効な文字データが決定される可能性があるので、依頼人数ｆ＝１（人）である。もちろん、有効とされる文字データが確定した後は新たに処理を依頼することはないため、新たに処理を依頼できる依頼人数ｆ＝０（人）である。図２１では、依頼人数をｆで示している。
【００８７】
つまり、ジョブ要求があった場合に、依頼人数ファイルが依頼人数ｆ＝０（人）の場合には新たな処理の依頼はできないということになるので、そのイメージファイルは削除され、別のイメージファイルを再度選択する。
【００８８】
そして、Ｓ４０４２，Ｓ４０４３のチェックが完了したものは、要求があったオペレータのエントリーコンピュータ３に処理を依頼するとともに処理依頼履歴ファイル１５ｆに処理依頼の履歴を記憶する（Ｓ４０４４）。以上で送信データ選択の手順（Ｓ４０４）を終了する。
【００８９】
（データセンタからエントリーセンタへデータ送信Ｓ５）図８のフローチャートに戻り、送信データ選択の手順（Ｓ４０４）が完了したら、データセンタでのデータ処理（Ｓ４）は完了し該当するオペレータのエントリーコンピュータ３に該当するイメージファイルを送信する（Ｓ５）。このときデータセンタ１では、第２の鍵でファイル名を再び暗号化する（図２５、Ｓ５参照）。エントリーコンピュータ３では、既に選択されたファイル名が送信され、処理を進めるに当り、その属性を知る必要がないからである。
【００９０】
なお、ここでは、イメージファイルの１つ１つを判断しているが、処理単位は、フォルダにまとめられた複数のイメージファイル単位で判断してもよいことはいうまでもない。
（エントリーセンタでの処理Ｓ６）続いて、図８に示すようにエントリーセンタ３７でデータ処理を行う（Ｓ６）。ここで、図１５はエントリーセンタ３７におけるデータ処理に手順を詳細に示すフローチャートである。エントリーセンタ３７でジョブ要求をしたオペレータのエントリーコンピュータ３がデータを受信すると（Ｓ６０１）、図７に示すエントリーアプリケーションプログラム（ＥＡＰ）の圧縮解凍プログラムでファイルを解凍する。続いて暗号化復号化プログラムで第３の鍵を用いてイメージファイルのイメージデータが図２５；Ｓ６０２に示すようにエントリーコンピュータ３内の図示しないＲＡＭ（揮発性記憶媒体）上で復号化される（Ｓ６０２）。この第３の鍵はデータセンタ１であっても持っていない鍵であり、このイメージファイルのイメージはデータセンタ１では見ることができないようになっている。この復号化されたイメージが起動した表示・文字入力プログラムにより表示装置にパーツデータの画像として表示される（Ｓ６０３）。そして、エントリーコンピュータ３は、オペレータが画像を目視して、文字を判読して入力装置３４であるキーボードから入力されるのを待つ（Ｓ６０４、Ｓ６０５；ＮＯ）。文字が入力されＥＮＴＥＲキーが押下されたら入力が完了したとして（Ｓ６０５；ＹＥＳ）、入力されたテキストデータをそのとき画面に表示されていたイメージファイルのファイル名と同じ名前で生成する（Ｓ６０６）。このときイメージファイルのファイル名は暗号化されているが、このテキストファイルも暗号化された文字列のままファイル名とする（図２５；Ｓ６０６）。そして、画面に表示されていたイメージファイルはメモリ上から完全に消去され（Ｓ６０７）、エントリーコンピュータ３には、イメージファイルはバックアップを含め残らない。
【００９１】
次に、暗号化復号化プログラムで、テキストデータのテキスト部分が図２５；Ｓ６０８に示すように第４の鍵で暗号化される（Ｓ６０８）。暗号化されたテキストデータは、フォルダにまとめられて圧縮解凍プログラムで圧縮されてファイル転送プログラムでデータセンタ１にＦＴＰで送信される。送信後、メモリ上のテキストデータは消去される（Ｓ６１０）。つまり、エントリーコンピュータ３には、処理時に一時的に記憶されたデータは、処理がすむとイメージデータもテキストデータもバックアップやバッファメモリを含め完全に消去されてセキュリティーを高めている。
【００９２】
（エントリーセンタからデータセンタへのデータ送信Ｓ７）図８のフローチャートおいて、エントリーセンタ３７からデータセンタ１にデータが送信されると（Ｓ７）、データセンタ１ではベリファイ、課金、支払い処理などのデータ処理が行われる（Ｓ８）。
【００９３】
（データセンタでの処理Ｓ８）ここで、図１６はデータセンタ１でのデータ処理の手順（Ｓ８）を詳細に示すフローチャートである。まず、エントリーコンピュータ３から文字ファイルを受信したら文字ファイルＤＢ１５ｉ（図２０）にフォルダごとに記憶する（Ｓ８０１）。続いて処理依頼履歴ファイル１５ｆの回収フラグを更新する（Ｓ８０２）。次にベリファイ処理を行う（Ｓ８０３）。
【００９４】
＜ベリファイ処理＞ベリファイ処理は、入力された文字データを多数決の原則で、先に所定数揃った文字データを正しい文字と推定する方法である。本実施形態では、先に「３つ」揃った場合に有効なデータとする。
【００９５】
ここで、図１７は、ベリファイ処理（Ｓ８０３）の手順を詳細に示すフローチャートである。データセンタ１では、文字ファイルを受信するとＳＡＰのベリファイプログラムが呼び出され、受信した文字ファイルと同一のファイル名のベリファイリストがあるか、検索する（Ｓ８０３１）。
【００９６】
ベリファイリスト１５ｇは、図２３に示すように１つのファイル名について１つのベリファイリスト１５ｇが作成される。そして、オペレータＩＤとともに受信した履歴が記録され、それぞれの文字データ（暗号テキスト）が比較される。そして、新たに入力された文字ファイルの文字データが、それまでに記録された文字ファイルの文字データと一致したときには、その文字データの文字ファイルにペアフラグが立てられる。また、一致した文字データの文字ファイルに既にペアフラグが立てられているときには、その文字データは同じものが３つ揃ったことになるので、その文字データが有効な文字データとなる。
【００９７】
受信した文字ファイルと同一のファイル名のベリファイリストがないときは（Ｓ８０３２；ＮＯ）、新たにベリファイリスト１５ｇを作成するとともに、（Ｓ８０３３）、最大一致数Ｓ＝１であるので、依頼人数ｆ＝２に設定する（Ｓ８０３５）。
【００９８】
一方、受信した文字ファイルと同一のファイル名のベリファイリスト１５ｇがあるとき（Ｓ８０３２；ＹＥＳ）、さらに一致する文字データ（暗号テキストデータ）があるかどうか判断する（Ｓ８０３４）。一致する文字データがない場合は（Ｓ８０３６；ＮＯ）、最大一致数Ｓ＝１であるので、依頼人数ｆ＝２に設定する（Ｓ８０３５）。
【００９９】
受信した文字ファイルと同一のファイル名のベリファイリスト１５ｇがあるとき（Ｓ８０３２；ＹＥＳ）、さらに一致する文字データ（暗号テキストデータ）があるかどうか判断する（Ｓ８０３４）。一致する文字データがあるとき（Ｓ８０３６；ＹＥＳ）、該当するベリファイリストの文字ファイルにペアフラグが立っているかどうか判断する（Ｓ８０３７）。もし、ペアフラグが立っていないとき（Ｓ８０３８；ＮＯ）、受信した文字データと同一の文字データの文字ファイルにペアフラグを立てる（Ｓ８０３９）。そのときは、最大一致数Ｓ＝２であり、依頼人数ｆ＝１として設定する（Ｓ８０４０）。
【０１００】
一方、ペアフラグが立っているかどうか判断して（Ｓ８０３７）、ペアフラグが立っているとき（Ｓ８０３８；ＹＥＳ）、同じ３つの文字データが揃ったことになるので、受信した文字ファイルとペアフラグの立てられている文字ファイルを有効なデータとして有効フラグを立てる（Ｓ８０４１）。そして、依頼人数ファイル１５ｅの該当するファイル名を削除する（Ｓ８０４２）。
【０１０１】
図１６のフローチャートで、ベリファイ処理（Ｓ８０３）が終了し、有効なデータがあった場合は（Ｓ８０４；ＹＥＳ）、イメージファイルＤＢ１５ｄから該当するイメージファイルを消去する（Ｓ８０５）。また、ベリファイリスト１５ｇを参照してオペレータＤＢ１５ｃに有効な文字データを送信したオペレータを記録し、その文字データを送信フォルダ１５ｊに記憶する（Ｓ８０６）。その後ベリファイリスト１５ｇを消去する（Ｓ８０７）。また、文字ファイルのファイル名を第２の鍵で一部復号化してデータを送るクライアント２を確認して記憶し、その後、すべてを再び暗号化する（図２５；Ｓ８０７参照）。以上の処理が完了したら、所定の処理単位のフォルダでクライアントに送信する（Ｓ８０８）。
【０１０２】
ベリファイ処理（Ｓ８０３）で、有効なデータがない場合は（Ｓ８０４；ＮＯ）、規定回数処理依頼をしたか判断する（Ｓ８０９）。この規定回数は例えば１０回とする。この規定回数を超えて有効な文字データがない場合は、判読結果が分散しているため、回数を重ねて無理をして有効な文字データを選択しても、データの信頼性としては低いものといえる。したがって、規定回数処理依頼した場合は（Ｓ８０９；ＹＥＳ）、判読が困難な文字として、イメージファイルＤＢ１５ｄのイメージファイルを消去して、難読リスト１５ｈ（図２４参照）に移し、スキルの高いオペレータにより再読させるか、クライアントにそのまま返送し判断を仰ぐようにする（Ｓ８１０）。また、依頼人数ファイル１５ｅ、処理依頼履歴ファイル１５ｆ、ベリファイリスト１５ｇの該当するファイル名のデータを消去する（Ｓ８１１）。
【０１０３】
また、有効データがなく（Ｓ８０４；ＮＯ）、規定回数処理依頼していない場合は（Ｓ８０９；ＮＯ）、依頼人数ファイル１５ｅの依頼人数ｆの値に従い、その人数分の処理依頼をオペレータからアクセスがあった場合に、重複しないオペレータに処理依頼を出す（Ｓ８１２）。
【０１０４】
（電子納品Ｓ９）図８に示すデータセンタ１でのデータ処理が終了すると（Ｓ８）、データセンタ１からクライアント２へ電子納品が行われる（Ｓ９）。
（データ再生Ｓ１０）電子納品が行われたクライアント２では、データ再生（Ｓ１０）の手順が実行される。図１８はデータ再生の手順（Ｓ１０）を詳細に示すフローチャートである。まず、データを受信する（Ｓ１００１）。圧縮されたフォルダは、ＦＴＰで転送されるため、まず解凍されるが、この解凍されたフォルダの中のデータは、ファイル名は、すべて暗号化されている（図２５；Ｓ８０７）。
【０１０５】
そこで、第１の鍵、第２の鍵を用いてファイル名の復号化を行う（Ｓ１００２）。これで、図２５；Ｓ１００２に示すように、用紙Ｓの用紙特定ＩＤ、パーツＩＤを含むすべての部分が平文となり、このデータを使えば元の用紙Ｓの再現が可能となる。
【０１０６】
続いて暗号化されたテキストデータ（文字データ）の部分が第４の鍵により復号化され図２５；Ｓ１００２に示すように平文のテキストデータとなる（Ｓ１００３）。
そして、復号化された用紙特定ＩＤ、パーツＩＤにより用紙Ｓ毎にデータがソートされ復元される（Ｓ１００４）。そして、所定のデータ形式、例えばＣＳＶ形式に変換されて記憶される（Ｓ１００５）。
【０１０７】
（本システム全体におけるデータの流れ）
次に、上記のような手順で手書き文字入力処理システムにおいて処理が行われるが、このときのデータの変遷を図２５に沿って説明する。
【０１０８】
まず、図１０のＳ２０３で作成されたワンシートデータでは、ファイル名は用紙Ｓの発生したクライアントＩＤ、支店ＩＤ、部署ＩＤと、用紙ＩＤ（用紙Ｓの種類を特定するＩＤ）、用紙特定ＩＤ（個別の用紙Ｓを特定するＩＤ）が所定の文字数、例えば８文字ずつで並べられて全体で１つのファイル名となっている。そしてＪＰＥＧ形式のイメージデータはそのまま平画像（暗号化していない画像）となっている。
【０１０９】
したがって、このＪＰＥＧ形式のイメージファイルであるワンシートデータは、用紙特定ＩＤを含むファイル名で一義的に特定される。
次に、Ｓ２０４で作成されたパーツデータでは、上記ワンシートデータから、「名前」、「住所」、「電話番号」等の項目の文字領域ＣＡの画像が切出される。そして、ワンシートデータのファイル名にさらにパーツＩＤ（切出した項目名を一義的に特定するＩＤコード）の文字列が例えば８文字分追加されたファイル名となっている。したがって、上記用紙特定ＩＤとパーツＩＤを組合せることで、切出したイメージが一義的に特定される。また、その項目の文字種・文字数などの入力制限がコード化された制限コードもファイル名に追加される。
【０１１０】
続いて、Ｓ２０５でイメージ画像が第３の鍵で暗号化される。
そして、Ｓ２０６では、第１の鍵で、ファイル名のうち、「用紙特定ＩＤ、パーツＩＤ」の文字列のみが暗号化される。
【０１１１】
つぎに、Ｓ２０７では、第２の鍵で、ファイル名のうち、残った「クライアントＩＤ、支店ＩＤ、部署ＩＤと、用紙ＩＤ、制限コード」の文字列が暗号化される。この段階で、ファイル名、画像データのすべてが暗号化されている。この状態でフォルダに入れて、１回の処理単位に合わせて適当な数のイメージファイルが送信される。
【０１１２】
本実施形態では、このままで暗号化されておりインターネット上を送信する場合でもセキュリティーが保たれるため、送信の便宜を考え全体を例えば圧縮解凍プログラムにより圧縮してもよいがパスワードによる保護や送信路をＶＰＮ（Virtual Private Network ）とする保護は必要がない。
【０１１３】
次に、図１３のＳ４０１で第２の鍵で、ファイル名の一部が復号化される。これは、用紙ＩＤやパーツＩＤを参照して、適切なイメージファイルを適切なオペレータに処理させるためである。一方、用紙特定ＩＤの部分は、処理に必要がないこと、用紙Ｓの復元の手がかりになることから、暗号化されたままである。
【０１１４】
続いて、図８、Ｓ５でデータセンタ１からエントリーコンピュータ３に送信するときには、再び第２の鍵でファイル名を暗号化する。
エントリーコンピュータ３に送信されたイメージファイルは図１５、Ｓ６０２で画像のみが復号化される。この復号化された画像は揮発性メモリであるエントリーコンピュータのＲＡＭにのみ記憶され、バッファやバックアップを含めＨＤＤやＥＥＰＲＯＭ等の不揮発性の記憶媒体に記憶されることはない。そして、このイメージファイルは、Ｓ６０６で、文字データがキー入力され、同じファイル名（つまり暗号文のファイル名）の平文の文字データ（テキストデータ）を有するテキストファイルが生成させると、交代に消去される。そして、生成されたテキストファイルは、Ｓ６０８でテキストデータの部分が第４の鍵で暗号化される。
【０１１５】
Ｓ６０９では、この状態のまま、つまり完全に暗号化された状態でエントリーコンピュータ３からデータセンタ１へ送信される。
図１６のＳ８０１でこのテキストファイルを受信し、Ｓ８０３でベリファイ処理が行われるが、このときもテキストデータは暗号のまま照合される。データセンタ１での処理が終了すると、Ｓ８０８で一旦第２の鍵でファイル名を復号化して、クライアントＩＤを確認し、送信先を確かめるとともに、処理に対する課金の記録などをして、再び第２の鍵でファイル名を暗号化する。そして、クライアント２に完全に暗号化された状態でインターネット４を通じて送信する。
【０１１６】
図１８のＳ１００１でデータセンタ１からのデータを受信したクライアント２は、Ｓ１００２で第１の鍵、第１の鍵でファイル名を完全に復号化し、Ｓ１００３で第４の鍵でテキストデータも復号化する。あとは、用紙特定ＩＤとパーツＩＤにより元の用紙Ｓのデータを再現する。
（実施形態の効果）
本実施形態の手書き文字入力処理システムは、以上説明したような構成を備えるため、以下のような効果がある。
【０１１７】
（１）たとえインターネット４のようなオープンな通信回線を用いたり、多数のオペレータに処理を依頼したりしても、１枚の用紙Ｓから切出されたイメージファイルは、イメージの属性を示すファイル名が所定の文字列に分割されて暗号化されるため、処理の段階に応じ多段階的に暗号化・復号化して情報の機密性を保持しながら処理を進めることができる。
【０１１８】
（２）  なお、暗号文に制御コードを含まないようにしたため、ファイル名を制御コードにしたために由来する不本意なトラブルを回避することができる。
（３）  ファイル名のうち第１の鍵により暗号化した用紙の復元に必須の文字列部分は、第１の鍵がクライアントから消去されるとともに可搬型記憶媒体のみに残されるため、鍵が可視化され、物理的に金庫に保管する等管理が容易になる。
【０１１９】
（４）  特に、可搬型記憶媒体がＵＳＢメモリであるので、記憶媒体がコンパクトであり、且つパスワードによりセキュリティーをさらに高めることもでき、また自動的に処理を行なうプログラムを記憶することもできる。
【０１２０】
（５）  イメージデータを暗号化したことで、データセンタ１に、処理に不必要なデータの内容を開示することがない。
（６）  タイムスタンプによる時間情報からフォルダに入ったファイルの生成の時系列の関係を推測される可能性がなくなり、より高いセキュリティーを確保できる。
【０１２１】
（７）  イメージファイルに係るイメージはキー入力のための画面表示に必要最小限に復号化され、記録としても残らない。また文字データも直ちに暗号化されるため、エントリーコンピュータ３外はもちろん、エントリーコンピュータ３自体においてもセキュリティーが保たれる。
【０１２２】
（８）  同じデータを、異なった複数のオペレータに入力させることで、より信頼度の高い客観的なデータを得ることができる。
（９）  例えば、文字を数字、カタカナ、漢字など文字の難易度などに合わせ、処理をスキル・知識のレベルに合わせた適切な処理が可能となる。
【０１２３】
（１０）  ベリファイ手段を備えることで、システム外からのチェックをすることなく自律的にデータの信頼性を高めることができる。
（１１）  データセンタ１においては、イメージデータの段階でも、文字データの段階でも一切内容を開示することなく、ベリファイ処理まで行なうことができるため、極めて高いセキュリティーを確保できる。
【０１２４】
（１２）  ベリファイ手段において、所定数を３とし、ベリファイリストにペアフラグを備えた構成としたため、簡単なアルゴリズムで本実施形態に適したベリファイができる。
【０１２５】
（１３）  一定の処理依頼で読めない場合は、難読リストに記憶しておくことで、難読の場合は、無理に有効なデータとしないようにして、データの信頼性を高めるとともに人的資源のムダを排除することができる。
【０１２６】
なお、上記実施形態は以下のように変更してもよい。
○  上記実施形態のハードウエア、フローチャートで示す手順は、代表的な手段、方法を例示として示すものであり、本発明がこのフローチャートに限定されないことはもちろんである。したがって、具体的手段、手順の順序等の差があっても、特許請求の範囲を逸脱しない限りは、変更し追加し省略して実施できる。
【０１２７】
○  上記実施形態では、第１の鍵で、用紙特定ＩＤとパーツＩＤとを暗号化しているが、用紙特定ＩＤのみを暗号化してもよい。但し、この場合は、同じ用紙特定ＩＤでは、同じ暗号文となるため、用紙特定ＩＤに、乱数や疑似乱数などの文字列を加えて暗号化することが好ましい。このようにすれば、同じ用紙特定ＩＤであっても、異なる暗号文のファイル名となり、同じ用紙特定ＩＤであっても、そのファイル名でソートしてもフォルダから抽出できなくなる。
【０１２８】
○  クライアント２において、第１の鍵で同じように暗号化したあと、第１の鍵で暗号化した部分を含めてファイル名全体を暗号化してもよい。
○  また、データセンタ１では、送信データ選択（Ｓ４０４）のため、第２の鍵で復号化したあと、エントリーセンタ３７に送信する前に再度暗号化しているが、この暗号化を省略してファイル名を一部平文のまま送信してもよい。そのようにしても、第１の鍵で暗号化している部分がわからない限り書類の復元はできないからである。また、暗号化していなくても、本実施形態ではコード化されているため、データセンタ１に記憶されたテーブルデータがない限りクライアントは判別できないからである。
【０１２９】
○  同様に、一部が復号化されたイメージデータのファイル名を文字入力処理したエントリーコンピュータ３では、ファイル名をそのまま暗号化しないで、文字ファイルをデータセンタ１に送るようにしてもよい。
【０１３０】
○  なお、ファイル名は、コード化された名称には限らず、そのままの会社名などとしてもよい。特殊なテーブルデータがなくても処理できるからである。この場合、暗号化が望ましい。
【０１３１】
○  本実施形態でイメージファイルの１つ１つを処理するように説明しているものもあるが、処理単位は、フォルダにまとめられた複数のイメージファイル単位で処理してもよいことはいうまでもない。
【０１３２】
○  エントリーコンピュータ３では、第４の鍵を用いず、公開鍵である第５の鍵で文字データを暗号化して、クライアント２で、第５の鍵と対応する秘密鍵である第６の鍵により復号化するようにしてもよい。特に、エントリーコンピュータ３をＳＯＨＯ等の分散したオペレータによる場合の鍵の管理負担が軽減する。
【０１３３】
○  図１に示す実施形態では、インターネット上にデータセンタ１とエントリーセンタ３７がそれぞれ分離して、エントリーセンタ３７にはハブ３６で多数のエントリーコンピュータ３がＬＡＮ接続されているが、データセンタ１をエントリーセンタ３７に配置してＬＡＮ接続するようにしてもよい。このように配置することで、データセンタ１とエントリーセンタ３７との間をインターネット４に代え、クローズドなＬＡＮ接続とすることで、データ転送時のセキュリティーを高めることができる。
【０１３４】
○  図１に示す実施形態において、エントリーセンタ３７にデータセンタ１の機能を分散するコンピュータを更に追加する構成としてもよい。この場合、データセンタ１の場所のコンピュータは、単にエントリーセンタ３７にあるデータセンタの機能を持つコンピュータに転送するようなものであってもよい。
【０１３５】
○  逆に、図１のデータセンタ１にエントリーコンピュータ３を配置する構成でもよい。
○  また、インターネット４に代えて、公衆電話回線、専用回線等通信可能であればそれらに置換えることができる。
【０１３６】
○  画像データ形式は、ＪＰＥＧ形式を例にしたが、ＴＩＦ，ＧＩＦ等データは形式に限定されない。また、文字データ形式もテキスト形式に限らず、各種ワードプロセッサ、テキストエディタ等形式に限定されない。
【０１３７】
○  上記実施形態では、エントリーコンピュータ３（処理端末）の識別はオペレータＩＤ（操作者コード）により行っているが、各オペレータが専用のエントリーコンピュータ３を用いていれば、オペレータＩＤに代えてエントリーコンピュータ３のＩＤ（処理端末コード）で認証や操作者の特定をしてもよい。
【０１３８】
○  上記実施形態では、エントリーコンピュータ３では、パーツデータが表示され、これを目視して新たに文字を入力するが、クライアント２においてパーツデータを切出すときに、この部分を周知のＯＣＲ（Optical Character Reader）プログラムで文字を認識し、このデータ（「ＯＣＲデータ」という。）をパーツデータと併せて、エントリーコンピュータに送信して予め、文字入力のウインドウに表示させて、これを修正する形で文字データの入力を行ってもよい。
【０１３９】
このＯＣＲデータは、パーツデータと同様の方法で暗号化、復号化をすることができるのはもちろんである。このように構成することで、入力の効率を高めることができる。
次に、上記実施形態及び別例から把握できる技術的思想について、それらの効果とともに以下に追記する。
【０１４０】
［付記１］
複数の入力端末と管理コンピュータと複数の処理端末とからなり、任意の入力端末に接続されたイメージスキャナからイメージデータが入力された用紙を、管理コンピュータを介していずれかの処理端末でその一部を表示し、当該処理端末の操作者に目視で文字を認識させて入力させた文字データを前記管理コンピュータを介して前記任意の入力端末から文字データとして出力する手書き文字入力処理システムにおいて、前記入力端末は、前記イメージスキャナにより文字が記載された用紙のイメージデータを読取る用紙スキャンのステップと、読取ったイメージデータの予め文字が記載される位置として特定された複数の文字領域からそれぞれイメージデータを切出すとともに、そのイメージの属性を示す固有のファイル名を付与する切出しのステップと、切出したイメージファイルのファイル名を所定の文字列に分割し、当該分割した文字列のそれぞれを異なる鍵を用いて暗号化するファイル名暗号化のステップと、ファイル名が暗号化されたイメージファイルを管理コンピュータに送信するイメージファイル送信のステップとを実行させることを特徴とする手書き文字入力処理方法。
【０１４１】
［付記２］
複数の入力端末と管理コンピュータと複数の処理端末とからなり、任意の入力端末に接続されたイメージスキャナからイメージデータが入力された用紙を、管理コンピュータを介していずれかの処理端末でその一部を表示し、当該処理端末の操作者に目視で文字を認識させて入力させた文字データを前記管理コンピュータを介して前記任意の入力端末から文字データとして出力する手書き文字入力処理システムであって、前記入力端末を、前記イメージスキャナにより文字が記載された用紙のイメージデータを読取る用紙スキャン手段と、読取ったイメージデータの予め文字が記載される位置として特定された複数の文字領域からそれぞれイメージデータを切出すとともに、そのイメージの属性を示す固有のファイル名を付与する切出し手段と、切出したイメージファイルのファイル名を所定の文字列に分割し、当該分割した文字列のそれぞれを異なる鍵を用いて暗号化するファイル名暗号化手段と、ファイル名が暗号化されたイメージファイルを管理コンピュータに送信するイメージファイル送信手段として機能させることを特徴とする手書き文字入力処理プログラム。
【図面の簡単な説明】
【０１４２】
【図１】本実施形態の手書き文字入力処理システムの全体を示す図。
【図２】クライアントの構成を示す図。
【図３】クライアントアプリケーションプログラム（ＣＡＰ）の構成を示す図。
【図４】データセンタの構成を示す図。
【図５】サーバアプリケーションプログラム（ＳＡＰ）の構成を示す図。
【図６】エントリーセンタの構成を示す図。
【図７】エントリーアプリケーションプログラム（ＥＡＰ）の構成を示す図。
【図８】本実施形態の手書き文字入力処理方法の手順を示すフローチャート。
【図９】クライアント登録の手順を示すフローチャート。
【図１０】クライアントデータ入力処理の手順を示すフローチャート。
【図１１】用紙の文字領域を示す模式図。
【図１２】クライアントからデータセンタへデータ通信の手順を示すフローチャート。
【図１３】データセンタでデータ処理の手順を示すフローチャート。
【図１４】送信データ選択の手順を示すフローチャート。
【図１５】エントリーセンタでデータ処理の手順を示すフローチャート。
【図１６】データセンタでデータ処理の手順を示すフローチャート。
【図１７】ベリファイ処理の手順を示すフローチャート。
【図１８】データ再生の手順を示すフローチャート。
【図１９】イメージファイルＤＢの記憶内容を概念的に示す図。
【図２０】文字ファイルＤＢの記憶内容を概念的に示す図。
【図２１】依頼人数ファイルの記憶内容を概念的に示す図。
【図２２】処理依頼履歴ファイルの記憶内容を概念的に示す図。
【図２３】ベリファイリストの記憶内容を概念的に示す図。
【図２４】難読リストの記憶内容を概念的に示す図。
【図２５】本実施形態の手書き文字入力処理方法の手順におけるデータの変遷を示す表。
【符号の説明】
【０１４３】
１…データセンタ（管理コンピュータ）、２…クライアント（入力端末）、３…エントリーコンピュータ（処理端末）、４…インターネット、１１…ＣＰＵ（未処理データ受信手段、重複排除手段、選択手段、未処理データ処理依頼手段、ベリファイ手段）、１５…記憶装置、１５ａ…プログラムファイル、１５ｂ…クライアントＤＢ（データベース）、１５ｃ…オペレータＤＢ（データベース）、１５ｄ…イメージファイルＤＢ（データベース）、１５ｅ…依頼人数ファイル、１５ｆ…処理依頼履歴ファイル、１５ｇ…ベリファイリスト、１５ｈ…難読リスト、１５ｉ…文字ファイルＤＢ（データベース）、１５ｊ…送信フォルダ（送信ファイル）、２１…ＣＰＵ（用紙スキャン手段、切出し手段、ファイル名暗号化手段、イメージファイル送信手段、イメージデータ暗号化手段、蓄積手段、再ソート手段、）、２５…記憶装置、２５ａ…プレーンフォルダ、２５ｂ…サイファフォルダ、２５ｃ…設定フォルダ、２５ｄ…プログラムフォルダ、２５ｅ…受信フォルダ、２６…イメージスキャナ、２８…ＵＳＢメモリ（可搬型記憶媒体）、３１…ＣＰＵ（受信手段、復号化手段、表示手段、文字入力手段、消去手段、文字ファイル生成手段）、３３…表示装置、３５…記憶装置、３５ａ…プログラムファイル、ＣＡ（ＣＡ１〜ＣＡ３）…文字領域、ＣＡＰ…クライアントアプリケーションプログラム、ＳＡＰ…サーバアプリケーションプログラム、ＥＡＰ…エントリーアプリケーションプログラム、Ｓ…用紙。
【図１】
2008269227.tif 000003
【図２】
2008269227.tif 000004
【図３】
2008269227.tif 000005
【図４】
2008269227.tif 000006
【図５】
2008269227.tif 000007
【図６】
2008269227.tif 000008
【図７】
2008269227.tif 000009
【図８】
2008269227.tif 000010
【図９】
2008269227.tif 000011
【図１０】
2008269227.tif 000012
【図１１】
2008269227.tif 000013
【図１２】
2008269227.tif 000014
【図１３】
2008269227.tif 000015
【図１４】
2008269227.tif 000016
【図１５】
2008269227.tif 000017
【図１６】
2008269227.tif 000018
【図１７】
2008269227.tif 000019
【図１８】
2008269227.tif 000020
【図１９】
2008269227.tif 000021
【図２０】
2008269227.tif 000022
【図２１】
2008269227.tif 000023
【図２２】
2008269227.tif 000024
【図２３】
2008269227.tif 000025
【図２４】
2008269227.tif 000026
【図２５】
2008269227.tif 000027