(57)【要約】本発明は、フォームベースのデータ入力システムに入力されるデータを解釈する方法であって、特定のフォームフィールドに入力されたデータを、その情報内容を決定することができるように解読するステップであって、情報内容が一貫性のある機械可読形式である、ステップ、を含んでおり、データの解読が、情報内容の１つの以上の可能な値を決定するステップを含んでおり、事前定義されている特定の可能な結果に、正しいことの相対的に高い確率が与えられており、事前定義されている可能な結果が、特定のフォームフィールドのコンテキストに依存する、方法、を提供する。
2006503353.tif 000002
【特許請求の範囲】
【請求項１】
フォームベースのデータ入力システムに入力されるデータを解釈する方法であって、
特定のフォームフィールドに入力されたデータを、その情報内容を決定することができるように解読するステップであって、前記情報内容が一貫性のある機械可読形式である、前記ステップ、
を含んでおり、データの前記解読が、情報内容の１つ以上の可能な値を決定するステップを含んでおり、事前定義されている特定の可能な結果には、相対的に高い確率の正確さが与えられており、前記事前定義されている可能な結果が、前記特定のフォームフィールドのコンテキストに依存する、方法。
【請求項２】
データの前記解読が、前記データ入力と同時に（オンラインで）実行される、請求項１に記載の方法。
【請求項３】
データの前記解読が、前記データ入力後のある時点に（オフラインで）実行される、請求項１に記載の方法。
【請求項４】
前記データ入力が、手書き文字とスピーチのいずれか一方又は両方によって行われる、請求項１〜３のいずれか１項に記載の方法。
【請求項５】
前記特定のフォームフィールドに、解読後の可能なデータの事前定義されているディクショナリが関連付けられており、前記ディクショナリが前記解読プロセスを制約する目的で使用される、請求項１〜４のいずれか１項に記載の方法。
【請求項６】
前記ディクショナリ内の特定のエントリに、正しく解読されたデータであることの高い確率が割り当てられている、請求項５に記載の方法。
【請求項７】
前記フィールドが名前フィールドであり、前記事前定義されているディクショナリが、選択される名前に対応する性別の情報を含んでいる、請求項５又は６のいずれかに記載の方法。
【請求項８】
前記フィールドが、階層的に編成されているサブフィールドを有する住所フィールドであり、サブフィールド内の解読された入力を、別のサブフィールド内の入力を制約する目的に使用することができる、請求項５又は６のいずれかに記載の方法。
【請求項９】
前記フィールドが電話番号フィールドであり、前記フィールドが、有効なデータは数字のみを含んでいるデータのみであるように制約される、請求項５又は６のいずれかに記載の方法。
【請求項１０】
前記フィールドがクレジットカード番号であり、有効なデータは一定の数の数値を含んでいるデータのみであり、前記数値をチェックサムの使用によって更に確認することができる、請求項１〜９のいずれか１項に記載の方法。
【請求項１１】
前記フィールドが、
郵便番号、国、日付、電子メールアドレス、及び/又は言語、を含むセットからなる、請求項１〜１０のいずれか１項に記載の方法。
【請求項１２】
前記システムが、標準化されているファイル形式であるＨＴＭＬ、ＸＭＬ、ＰＤＦ、及びＸＦｏｒｍｓのうちの１つを使用して実施されている、請求項１〜１１のいずれか１項に記載の方法。
【請求項１３】
カスタムの確認プログラムが前記フィールドに関連付けられており、前記カスタムの確認プログラムが、可能な値に対して実行される、請求項１〜１２のいずれか１項に記載の方法。
【請求項１４】
前記カスタムの確認プログラムがＪａｖａＳｃｒｉｐｔプログラムである、請求項１３に記載の方法。
【請求項１５】
フィールドマスクが前記フィールドに関連付けられており、前記フィールドマスクは、可能な値が事前定義されている文字列パターンに一致するかを調べる、請求項１〜１４のいずれか１項に記載の方法。
【請求項１６】
可能な値が、以前に認識された応答を使用して、選択肢リスト又は組み合わせリストから導かれる、請求項１〜１５のいずれか１項に記載の方法。
【発明の詳細な説明】
【発明の分野】
【０００１】
本発明は、フォームベースのデータ入力システムに入力されたデータを解釈するプロセスにおける認識精度を高める方法に関する。
【発明の背景】
【０００２】
多くの様々なシステムでは、ユーザに１つ以上の手段を通じて対話を行ってデータを提供するように要求する。オンラインシステムとしては、インターネットのＷｅｂページ上に見られるシステムが挙げられ、オフラインシステムとしては、手書きフォームの作成システムが挙げられ、後者のシステムでは、手書きのフォームが後から適切な機器によってスキャンされて解釈される。それ以外のオンラインシステムとしては、音声認識システムが挙げられ、このシステムでは、ユーザは特定のプロンプトに応えて話すように指示される。
【０００３】
自然言語システムとしても知られているこのようなデータ入力システムの問題としては、様々なユーザが一貫性のない様式で、話す、書く、或いはデータを入力することによる、ノイズとあいまい性とが挙げられる。
【関連出願】
【０００４】
本発明に関連する様々な方法、システム、及び装置は、本発明の出願人又は譲渡人によって出願されている以下の係属中の出願に開示されている。これらの係属中の出願すべての開示は、本文書に参考とすることにより組み込まれる。
【０００５】
２００２年１０月５日：オーストラリア仮特許出願第２００２９５２２５９号「方法及び装置（ＮＰＴ０１９）」
２００２年１０月１５日：ＰＣＴ／ＡＵ０２／０１３９１，ＰＣＴ／ＡＵ０２／０１３９２，ＰＣＴ／ＡＵ０２／０１３９３，ＰＣＴ／ＡＵ０２／０１３９４，ＰＣＴ／ＡＵ０２／０１３９５
２００１年１１月２６日：ＰＣＴ／ＡＵ０１／０１５２７，ＰＣＴ／ＡＵ０１／０１５２８，ＰＣＴ／ＡＵ０１／０１５２９，ＰＣＴ／ＡＵ０１／０１５３０，ＰＣＴ／ＡＵ０１／０１５３１
２００１年１０月１１日：ＰＣＴ／ＡＵ０１／０１２７４
２００１年８月１４日：ＰＣＴ／ＡＵ０１／００９９６
２０００年１１月２７日：ＰＣＴ／ＡＵ００／０１４４２，ＰＣＴ／ＡＵ００／０１４４４，ＰＣＴ／ＡＵ００／０１４４６，ＰＣＴ／ＡＵ００／０１４４５，ＰＣＴ／ＡＵ００／０１４５０，ＰＣＴ／ＡＵ００／０１４５３，ＰＣＴ／ＡＵ００／０１４４８，ＰＣＴ／ＡＵ００／０１４４７，ＰＣＴ／ＡＵ００／０１４５９，ＰＣＴ／ＡＵ００／０１４５１，ＰＣＴ／ＡＵ００／０１４５４，ＰＣＴ／ＡＵ００／０１４５２，ＰＣＴ／ＡＵ００／０１４４３，ＰＣＴ／ＡＵ００／０１４５５，ＰＣＴ／ＡＵ００／０１４５６，ＰＣＴ／ＡＵ００／０１４５７，ＰＣＴ／ＡＵ００／０１４５８，ＰＣＴ／ＡＵ００／０１４４９
２０００年１０月２０日：ＰＣＴ／ＡＵ００／０１２７３，ＰＣＴ／ＡＵ００／０１２７９，ＰＣＴ／ＡＵ００／０１２８８，ＰＣＴ／ＡＵ００／０１２８２，ＰＣＴ／ＡＵ００／０１２７６，ＰＣＴ／ＡＵ００／０１２８０，ＰＣＴ／ＡＵ００／０１２７４，ＰＣＴ／ＡＵ００／０１２８９，ＰＣＴ／ＡＵ００／０１２７５，ＰＣＴ／ＡＵＯＯ／０１２７７，ＰＣＴ／ＡＵ００／０１２８６，ＰＣＴ／ＡＵ００／０１２８１，ＰＣＴ／ＡＵ００／０１２７８，ＰＣＴ／ＡＵ００／０１２８７，ＰＣＴ／ＡＵ００／０１２８５，ＰＣＴ／ＡＵ００／０１２８４，ＰＣＴ／ＡＵ００／０１２８３
２０００年９月１５日：ＰＣＴ／ＡＵ００／０１１０８，ＰＣＴ／ＡＵ００／０１１１０，ＰＣＴ／ＡＵ００／０１１１１
２０００年６月３０日：ＰＣＴ／ＡＵ００／００７６２，ＰＣＴ／ＡＵ００／００７６３，ＰＣＴ／ＡＵ００／００７６１，ＰＣＴ／ＡＵ００／００７６０，ＰＣＴ／ＡＵ００／００７５９，ＰＣＴ／ＡＵ００／００７５８，ＰＣＴ／ＡＵＯＯ／００７６４，ＰＣＴ／ＡＵＯＯ／００７６５，ＰＣＴ／ＡＵ００／００７６６，ＰＣＴ／ＡＵＯＯ／００７６７，ＰＣＴ／ＡＵ００／００７６８，ＰＣＴ／ＡＵ００／００７７３，ＰＣＴ／ＡＵ００／００７７４，ＰＣＴ／ＡＵ００／００７７５，ＰＣＴ／ＡＵ００／００７７６，ＰＣＴ／ＡＵ００／００７７７，ＰＣＴ／ＡＵ００／００７７０，ＰＣＴ／ＡＵ００／００７６９，ＰＣＴ／ＡＵ００／００７７１，ＰＣＴ／ＡＵ００／００７７２，ＰＣＴ／ＡＵＯＯ／００７５４，ＰＣＴ／ＡＵ００／００７５５，ＰＣＴ／ＡＵ００／００７５６，ＰＣＴ／ＡＵ００／００７５７
２０００年５月２４日：ＰＣＴ／ＡＵ００／００５１８，ＰＣＴ／ＡＵ００／００５１９，ＰＣＴ／ＡＵ００／００５２０，ＰＣＴ／ＡＵＯＯ／００５２１，ＰＣＴ／ＡＵ００／００５２２，ＰＣＴ／ＡＵＯＯ／００５２３，ＰＣＴ／ＡＵＯＯ／００５２４，ＰＣＴ／ＡＵ００／００５２５，ＰＣＴ／ＡＵ００／００５２６，ＰＣＴ／ＡＵ００／００５２７，ＰＣＴ／ＡＵＯＯ／００５２８，ＰＣＴ／ＡＵ００／００５２９，ＰＣＴ／ＡＵ００／００５３０，ＰＣＴ／ＡＵ００／００５３１，ＰＣＴ／ＡＵ００／００５３２，ＰＣＴ／ＡＵ００／００５３３，ＰＣＴ／ＡＵ００／００５３４，ＰＣＴ／ＡＵ００／００５３５，ＰＣＴ／ＡＵ００／００５３６，ＰＣＴ／ＡＵ００／００５３７，ＰＣＴ／ＡＵ００／００５３８，ＰＣＴ／ＡＵ００／００５３９，ＰＣＴ／ＡＵ００／００５４０，ＰＣＴ／ＡＵ００／００５４１，ＰＣＴ／ＡＵ００／００５４２，ＰＣＴ／ＡＵ００／００５４３，ＰＣＴ／ＡＵ００／００５４４，ＰＣＴ／ＡＵ００／００５４５，ＰＣＴ／ＡＵ００／００５４７，ＰＣＴ／ＡＵ００／００５４６，ＰＣＴ／ＡＵ００／００５５４，ＰＣＴ／ＡＵ００／００５５６，ＰＣＴ／ＡＵ００／００５５７，ＰＣＴ／ＡＵ００／００５５８，ＰＣＴ／ＡＵ００／００５５９，ＰＣＴ／ＡＵ００／００５６０，ＰＣＴ／ＡＵ００／００５６１，ＰＣＴ／ＡＵ００／００５６２，ＰＣＴ／ＡＵ００／００５６３，ＰＣＴ／ＡＵ００／００５６４，ＰＣＴ／ＡＵ００／００５６５，ＰＣＴ／ＡＵ００／００５６６，ＰＣＴ／ＡＵ００／００５６７，ＰＣＴ／ＡＵ００／００５６８，ＰＣＴ／ＡＵ００／００５６９，ＰＣＴ／ＡＵ００／００５７０，ＰＣＴ／ＡＵ００／００５７１，ＰＣＴ／ＡＵ００／００５７２，ＰＣＴ／ＡＵ００／００５７３，ＰＣＴ／ＡＵ００／００５７４，ＰＣＴ／ＡＵ００／００５７５，ＰＣＴ／ＡＵ００／００５７６，ＰＣＴ／ＡＵ００／００５７７，ＰＣＴ／ＡＵ００／００５７８，ＰＣＴ／ＡＵ００／００５７９，ＰＣＴ／ＡＵ００／００５８１，ＰＣＴ／ＡＵ００／００５８０，ＰＣＴ／ＡＵ００／００５８２，ＰＣＴ／ＡＵ００／００５８７，ＰＣＴ／ＡＵ００／００５８８，ＰＣＴ／ＡＵ００／００５８９，ＰＣＴ／ＡＵ００／００５８３，ＰＣＴ／ＡＵ００／００５９３，ＰＣＴ／ＡＵ００／００５９０，ＰＣＴ／ＡＵ００／００５９１，ＰＣＴ／ＡＵ００／００５９２，ＰＣＴ／ＡＵ００／００５９４，ＰＣＴ／ＡＵ００／００５９５，ＰＣＴ／ＡＵ００／０５０９６，ＰＣＴ／ＡＵ００／００５９７，ＰＣＴ／ＡＵ００／００５９８，ＰＣＴ／ＡＵ００／００５１６，ＰＣＴ／ＡＵ００／００５１７，ＰＣＴ／ＡＵ００／００５１１
【関連技術の説明】
【０００６】
米国特許第５，２３７，６２８号明細書には、機械によって印刷されたフィールド識別子の位置を特定することによってデジタルイメージ内のフォームフィールドの位置を特定することを目的として、手で書かれた文字ではなく機械によって印刷された文字を認識することのできる光学的認識システムが説明されている。フィールドが識別されると、オフライン手書き文字認識機能を使用して各フィールド内の個々の文字が認識される。
【０００７】
米国特許第５，４５５，８７２号明細書には、フォーム内の特定のフィールドに対して使用するのに最適なタイプの分類器（例：制約された手書き、制約されない手書き、制約されない筆記体）を選択することができる、フィールドベースの認識システムが開示されている。このシステムでは、適応的な重み付けシステム（ａｄａｐｔｉｖｅ  ｗｅｉｇｈｔｉｎｇ  ｓｙｓｔｅｍ）と信頼値とを使用して、使用するのに最良の分類器が決定される。
【０００８】
米国特許第５，２３５，６５４号明細書には、文字認識プロセッサによるフォーム定義機能が組み込まれているシステムが開示されている。
【０００９】
ＳｉｂｅｒＳｙｔｅｍｓ社は、人工知能技術を使用するフォーム定義言語を利用して、フォーム上に現れる様々なフィールドタイプを推測する製品を提供している。
【発明の概要】
【００１０】
広い形式においては、本発明は、フォームベースのデータ入力システムに入力されるデータを解釈する方法であって、特定のフォームフィールドに入力されたデータを、その情報内容を決定することができるように解読するステップであって、情報内容が一貫性のある機械可読形式である、ステップ、を含んでおり、データの解読が、情報内容の１つの以上の可能な値を決定するステップを含んでおり、事前定義されている特定の可能な結果に、正しいことの相対的に高い確率が与えられており、事前定義されている可能な結果が、特定のフォームフィールドのコンテキストに依存する、方法、を提供する。
【００１１】
データの解読は、書かれたデータ又は音声データに対して実行されることが好ましい。
【００１２】
解読は、オンラインで実行することができ、この場合には、解読はデータ入力と同時に行われ、又は、オフラインで実行することができ、この場合には、解読はデータ入力後のある時点で行われる。
【００１３】
好ましくは、特定のフォームフィールドには、解読後の可能なデータの事前定義されているディクショナリが関連付けられており、このディクショナリは、特定の解読がディクショナリに含まれている必要があるように、又は、少なくとも、ディクショナリに含まれている特定の確率である必要があるように、解読プロセスを制約する目的に使用することができる。
【００１４】
特定の可能な解読に、正しいことの高い確率を与えることができることが好ましい。この一例は、名前フィールドであり、名前フィールドでは、ＳｍｉｔｈはＳｍｉｔｈｆｉｅｌｄよりも正しい解読である可能性が高い。
【００１５】
本発明の実施形態は、入力されたデータを、データが入力されているフィールドのコンテキストに基づいて解読することによって、自然言語システムにおいてデータ入力の高い精度の認識を達成することができるという利点を提供する。
【００１６】
本発明について深く理解し、本発明を実施する方法を理解することができるように、添付されている図面を参照しながら本発明について一例を通じて以下に説明する。
【詳細な説明】
【００１７】
好ましい実施形態においては、本発明は、Ｎｅｔｐａｇｅネットワーク化コンピュータシステムと一緒に動作するように構成されており、このシステムについては、当社の係属中の出願、特に、ＰＣＴ出願である国際公開第０２４２９８９号「感知装置（Ｓｅｎｓｉｎｇ  Ｄｅｖｉｃｅ）」（出願日：２００２年５月３０日）、ＰＣＴ出願である国際公開第０２４２８９４号「対話型プリンタ（Ｉｎｔｅｒａｃｔｉｖｅ  Ｐｒｉｎｔｅｒ）」（出願日：２００２年５月３０日）、ＰＣＴ出願である国際公開第０２１４０７５号「インビジブルインクを使用するインタフェース表面プリンタ（Ｉｎｔｅｒｆａｃｅ  Ｓｕｒｆａｃｅ  Ｐｒｉｎｔｅｒ  Ｕｓｉｎｇ  Ｉｎｖｉｓｉｂｌｅ  Ｉｎｋ）」（出願日：２００２年２月２１日）、ＰＣＴ出願である国際公開第０２４２９５０号「ネットワークコンピュータシステムと対話する装置（Ａｐｐａｒａｔｕｓ  Ｆｏｒ  Ｉｎｔｅｒａｃｔｉｏｎ  Ｗｉｔｈ  Ａ  Ｎｅｔｗｏｒｋ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ）」（出願日：２００２年５月３０日）、ＰＣＴ出願である国際公開第０３０３４２７６号「手書き特徴形状合成を使用するデジタルインクデータベースの探索（Ｄｉｇｉｔａｌ  Ｉｎｋ  Ｄａｔａｂａｓｅ  Ｓｅａｒｃｈｉｎｇ  Ｕｓｉｎｇ  Ｈａｎｄｗｒｉｔｉｎｇ  Ｆｅａｔｕｒｅ  Ｓｙｎｔｈｅｓｉｓ）」（出願日：２００３年４月２４日）、に詳細に説明してある。ただし、すべての実施形態が、基本システムに関連する、これらの出願に説明されている固有の細部及び拡張部分のすべて、若しくは大部分を具体化しているとは限らない。しかしながら、本発明の好ましい実施形態及び側面が機能するコンテキストを理解することを助ける目的で、システムは最も完全な形式において説明してある。
【００１８】
簡潔にまとめると、Ｎｅｔｐａｇｅシステムの好ましい形態では、見えないように符号化されているペーパーのページと光学的イメージングペンとを利用することによって、オンライン情報へのペーパーベースの対話型インタフェースが提供される。Ｎｅｔｐａｇｅシステムによって生成される各ページは、一意に識別され、ネットワークサーバに格納され、ユーザがＮｅｔｐａｇｅペンを使用して行うペーパーとの対話すべてが取り込まれ、解釈され、格納される。デジタル印刷技術によって、Ｎｅｔｐａｇｅドキュメントのオンデマンド印刷が容易になり、これにより対話型アプリケーションを開発することが可能である。Ｎｅｔｐａｇｅプリンタと、Ｎｅｔｐａｇｅペンと、ネットワークインフラストラクチャとにより、従来のスクリーンベースのアプリケーション及びオンラインパブリッシングサービスとに代わるペーパーベースの代替アプリケーション及びサービスが提供され、ハイパーテキストナビゲーションやフォーム入力などのユーザインタフェース機能がサポートされる。
【００１９】
一般には、発行者又はアプリケーションプロバイダからのドキュメントがブロードバンド接続を介してプリンタによって受信され、このドキュメントは、赤外線タグの見えないパターンによって印刷されており、各タグはページ上の自身の位置と一意のページ識別子とを符合化する。ユーザがページに書き込むと、イメージングペンがこれらのタグを解読し、ペンの動きをデジタルインクに変換する。デジタルインクは無線チャネルを通じて中継基地局に伝送された後、ネットワークに送られて処理及び格納される。システムは、格納されているページの記述を使用してデジタルインクを解釈し、アプリケーションと対話することによって要求されたアクションを実行する。
【００２０】
アプリケーションは、ドキュメントを発行することによってユーザにコンテンツを提供し、ユーザによって送信されたデジタルインク対話を処理する。一般には、アプリケーションは、ユーザ入力に応えて１つ以上の対話型ページを生成し、これらのページがネットワークに伝送されて格納及びレンダリングされ、最終的にユーザへの出力として印刷される。Ｎｅｔｐａｇｅシステムでは、ドキュメントの発行、レンダリング、及び配信や、認証型トランザクション及び安全な支払、手書き文字認識及びデジタルインク探索のほか、バイオメトリクス技術を使用したユーザ確認（例：署名照合）のサービスを提供することによって、高度なアプリケーションを開発することができる。
【００２１】
本発明の実施形態は、オンライン又はオフラインのいずれかの状況において、自然言語の入力データを解読するように動作する。このような入力データは、手書きのワード又は話された単語の形式か、それ以外の制約されていない入力形式をとることができる。
【００２２】
本明細書の説明においては、「オンライン」は、入力データがリアルタイムで、すなわちデータの入力と同時に解読されるシステムを意味する。言い換えれば、解読プロセスは、書かれた文字を構成する様々なストロークの軌跡など、動的な情報を用いて機能することができる。代表的なオンラインシステムはインターネットのＷｅｂページであり、Ｗｅｂページにおける入力は、例えばスタイラスと適切なグラフィックスタブレットとを用いて入力される手書き文字の形式で受け入れられる。
【００２３】
本明細書の説明においては、「オフライン」は、入力データは記録されるが解読は後の時点まで行われないシステムを意味する。言い換えれば、解読は、書かれた文字のビットマップイメージなど、静的な入力表現を用いて機能することができるのみである。代表的なオフラインシステムは、手書きフォームデータ取り込みシステムであり、このシステムでは、ユーザは手書きと通常のペンとを使用してフォームを完成させ、後の時点において、完成したフォームがスキャン及び処理されて、フォーム内に符号化されているデータが取り出される。
【００２４】
上述したように、自然言語入力システムを使用することには、システム設計者にとって多数の問題が存在する。字体（ｗｒｉｔｉｎｇ  ｓｔｙｌｅｓ）は、個人間の違いのみならず、たとえ同一人物であっても場面や筆記用具が変わることによって大幅に異なる。同様に、アクセント、イントネーション、方言、及び声のピッチも様々なものが存在し、これらのそれぞれが原因で、異なる話し手からの音声入力を区別することが難しくなる。
【００２５】
本発明の実施形態は、様々な自然言語データ入力システムにおける認識精度を高める方法を提供する。精度の向上は、特定のフィールドに入力されたデータとして可能性のあるデータのセットを、フィールド自体の特定の属性に基づいて制約することによって達成される。１つの実施形態においては、制約を絶対的なものとすることができ、すなわち、フィールドに入力されるデータは、そのフィールドに関連付けられている定義済みデータセットに含まれていなければならない。
【００２６】
別の実施形態においては、制約を部分的なものとすることができ、すなわち、定義済みデータセットに含まれているデータ入力には大きな重み付けが与えられる。この場合、データ入力が解読され、重み付けの高い結果のリストに含まれていないことが判明した場合であっても依然として受け入れられるが、前の実施形態においては、このような結果は無視される。
【００２７】
フォームベースのデータ入力システムにおいては、フォームには、それぞれがデータ入力を受け取ることができる１つ以上のフィールドが含まれている。以下の説明では、便宜上、手書き入力を受け取るようにされているシステムを主として通じて本発明の実施形態を説明しているが、当業者には、スピーチなど別の形式のデータ入力についても、本発明の実施形態の恩恵を享受できることが理解されるであろう。
【００２８】
図１は、２つの個別のフィールド１１０，１２０から名前情報を取り込むように意図されている代表的なフォーム１００を示している。「名」というラベルを持つフィールド１１０は、ユーザが自分の名前を指定する入力を取り込む目的で設けられている。「姓」というラベルを持つ第２のフィールド１２０は、ユーザが自分の名字を指定する入力を取り込む目的で設けられている。
【００２９】
最初の場合においては、関連付けられている処理システムは、オンライン又はオフラインのいずれにおいても、入力データを解読し、フィールドラベル「姓」に暗黙的な情報に基づいて、可能性の高い結果に制約することができる。処理システムには一般的な姓のデータベースが設けられており、手書き入力を解読するときに、解読した入力の可能な値のうち、一般的な姓のデータベースに属している値に大きな重み付けが与えられる。一例として、あるユーザの名前が「Ｇｒｅｇ」であるとする。しかしながら、このユーザの筆跡では、名前が「Ｇｒｅｙ」のように見える。
【００３０】
図３ａは、ユーザがフォームフィールドに自分の名前を書いたときのグラフィック表現を示している。図３ｂは、同じユーザが語「Ｇｒｅｙ」を書いたときの状態を示している。これら２つの表現は非常に似ており、「Ｇｒｅｇ」の最後の文字「ｇ」の上部が「Ｇｒｅｙ」の「ｙ」と比較して閉じていることのみが異なっていることに気づく。
【００３１】
書かれた入力を処理システムが解読して解釈しようとするとき、「Ｇｒｅｇ」にはより大きな重み付けが与えられ、なぜなら「Ｇｒｅｇ」の方が有効な名前である可能性がずっと高いためである。この場合、「Ｇｒｅｙ」は、受け入れ可能なワードのディクショナリに見つかるワードあるが、一般的な名前のリストにはおそらくは含まれていない。このようにして、一般的な名前をそれ以外の有効なワードよりも優先させることによってデータを制約することにより、正しい結果が得られる。別の場合として、２つ以上の結果の可能性が高く、そのすべてが制約リストに現れている場合には、データを再入力するようにユーザに指示するか、又は、有望な結果のリストからの可能性の高い結果のうち正しいものを選ぶためのオプションをユーザに提示することができる。
【００３２】
これと同じプロセスは、様々なフォームに見られる様々なフィールドの場合に適合させることができる。以下の模範的なリストは、すべてを網羅しているわけではないが、いくつかのフィールドと、与えられた入力から正しい結果を生成する可能性を高める目的で解読プロセスに適用することのできる種類の制約とを詳しく示している。当然ながら、通常の技能を有する者には、各種のフィールドには、フィールドの特定の特性に従ってコンテキストに基づく制約を適用できることが理解されるであろう。
フィールドラベル文字列  コンテキスト処理
名、名前、など：一般的な名前の大規模なリストは、公的に広く利用可能であり、これを認識時の処理制約を定義するディクショナリとして使用することができる。これらのリストは、国勢調査に基づいていることが多く、対応する先験的な確率が含まれており、「Ｊｏｈｎ」や「Ｄａｖｉｄ」などの一般的な名前をより頻繁に合致させることができる。書き手の性別を示す追加情報がフォームその他から得られる場合、男性と女性の個別のリストを使用して認識精度を更に高めることができる。
【００３３】
認識時には、一般的ではない珍しいスペルの名前についても正しく認識させることができるように、ディクショナリにないワード（すなわち名前のディクショナリに含まれていない名前）も受け入れさせることができる。このことは、ディクショナリによる解読と、名前に通常含まれている文字の並びの先験的な確率に関する情報が含まれている確率的文法モデル（文字Ｎ−ｇｒａｍなど）とを組み合わせることによって行うことができる。
姓、名字、など：上記のフィールドに似ているが、姓のディクショナリを使用する。西欧の名前の場合、人口の中の姓のばらつきが一般的にずっと大きく、ディクショナリにないワードの確率は名前の認識の場合より高いはずである。
住所：ほとんどの住所は規則的なパターンに従う（例：居住番号（ｄｗｅｌｌｉｎｇ  ｎｕｍｂｅｒ）の後にストリート名とストリートタイプ）。認識システムは、解読時に、例えば正規表現のマッチングを使用することによって、又は、認識の進行に伴って有効な文字セット（すなわち、数字のみ、文字のみ、「／」を許可する、許可しない、など）を変化させることによって、このパターンを利用することができる。
【００３４】
これに加えて、住所のいくつかの要素、例えばストリートのタイプ（「Ｓｔｒｅｅｔ」、「Ｒｏａｄ」、「Ｐｌａｃｅ」、「Ａｖｅｎｕｅ」、「Ｃｒｅｓｃｅｎｔ」、「Ｓｑｕａｒｅ」、「Ｈｉｌｌ」など）又はストリート名（「Ｍａｉｎ」、「Ｃｈｕｒｃｈ」、「Ｎｏｒｔｈ」、「Ｈｉｇｈ」などの一般的なストリート名）を、ディクショナリを利用して解読することができる。
郊外地域、町、など：郊外地域と町の完全なリストは、ほとんどの地域では公に自由に利用できる。この情報は、州又は郵便番号の情報（利用可能な場合）など他の情報と一緒に使用して、認識の候補を更に減らすことができる。
【００３５】
例を挙げると、居住国が例えばオーストラリアであることがすでに確定している場合、次の階層区分である州又はテリトリーとして可能性のある値はわずかに７つである。そのフィールドが解読されると、その州／テリトリー内の郊外地域又は町の更なるディクショナリを使用して、可能な結果を制限することができる。
州：国／地域が既知である場合、州のリストが利用できる。各州には、ある人がその州の出身である可能性に対応する先験的確率を与えることができる（すなわち人口の多い大きな州には高い先験的確率を与えることができる）。郵便番号が既知であれば、更なる制約を使用することができる。
電話番号：電話番号は、認識時に使用することのできる一定のパターン（例：「（＃＃）＃＃＃＃−＃＃＃＃」）に従う。更に、電話番号の有効な文字セットは数字のみに制約され、認識の候補が更に制限される。
郵便番号：特定の国の中の郵便番号は、一般的には特定のパターンに従う。以下に例を示す。オーストラリアでは、郵便番号は必ず４桁であり、アメリカでは５桁である。イギリスでは、１つ以上の文字のあとに２つ以上の数字が続き、そのあとに再び１つ以上の文字が続く組み合わせである。対応する州と郊外地域の情報が利用できる場合、解読の更なる制約が利用できる。
国、地域、など：可能性のある国／地域のラベルの完全なリストは公に利用可能である。
誕生日、生年月日、その他の日付：書かれる日付は一般的には一定のパターンに従い、数字のみから成る、又は数字と区切り文字（「−」、「／」など）とから成る制約された文字セットを持つ。
電子メール、Ｅメール、電子メールアドレス、など：電子メールアドレスは特定のパターンに従い、適切な仕様の文字セットを持つ。電子メールアドレスのマッチングに使用することのできる正規表現の例は、「／＾（［ａ−ｚＡ−Ｚ０−９＿|．|−］）＋|＠（（［ａ−ｚＡ−Ｚ０−９|−］）＋．）＋（［ａ−ｚＡ−Ｚ０−９］）＋＄／」である。
【００３６】
これに加えて、（例えばＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ  Ｍｅｓｓａｇｉｎｇ  ＡＰＩ（ＭＡＰＩ）を使用して）ユーザの電子メールの連絡先情報が利用できる場合、電子メールアドレスのリストを認識時にディクショナリとして使用することができる。同様に、代表的な電子メールドメイン名（例：「ｈｏｔｍａｉｌ．ｃｏｍ」、「ｙａｈｏｏ．ｃｏｍ」、「ｅｍａｉｌ．ｃｏｍ」など）を、認識をガイドするためのディクショナリエントリとして使用することができる。
クレジットカード、クレジットカード番号、など：クレジットカード番号は特定の形式（例：「＃＃＃＃−＃＃＃＃−＃＃＃＃−＃＃＃＃」）であり、制約された文字セットを持つ。更に、確認規則（例：チェックデジット検査）がしばしば存在し、これも認識時に使用することができる。例えば、クレジットカード番号の認識において可能性が同じである２つの結果がある場合、正しい結果を選択するうえでチェックデジット確認が役立つことがある。
言語／ロケール：世界中で話されている言語のリストは自由に利用することができ、現在では多数のＷｅｂフォームによって使用されている。特定の書き手の言語がわかれば、それを使用して他のタイプの入力の処理を向上させることができる。この例として、テキスト認識用の、言語ごとの異なるディクショナリ（例：英語、ドイツ語、フランス語など）を使用する、有効な認識文字セットを変更する（例：いくつかの西ヨーロッパ言語によって使用されるアクセント付き文字が許可される）、日付の認識の形式が変更する、を挙げることができる。
【００３７】
公に利用できるディクショナリ又は所有権が保持されているディクショナリを使用することに加えて、特定のフィールドラベルについて、以降のデータ入力をガイド及び制約する目的で、以前に認識された応答を使用して時間の経過に伴ってラベルのディクショナリを蓄積していくことができる。このようにすると、本発明の実施形態を採用しているシステムは、動作を継続して解読プロセスの可能性の高い結果を「学習」していくにつれて、その認識能力を高めることができる。このようにすると、例えば、時間と共に該当回数が増していく名前に、高い先験的重み付けを与えることができる。
【００３８】
ほとんどのフォーム定義形式では、テキストフィールド、選択肢リストフィールド、組み合わせフィールド（すなわちテキスト入力と選択肢リストとを組み合わせたフィールド）、署名フィールド、チェックボックス、ボタンなど、多数のフィールドタイプがサポートされる。フィールドタイプは、予測される入力データのタイプをある程度示す（例えばテキスト入力フィールドはテキスト入力を示す）。データタイプを明示的に定義することができるドキュメント形式の場合（例：ＸＭＬ／ＸＦｏｒｍｓ）、認識システムはこの情報を使用して認識プロセスを制約することができる。
【００３９】
フォームには、フィールドタイプ以外にも、各フィールドに入力すべきデータのタイプに関する情報がしばしば含まれている。この情報は、通常、特定のフィールドに関連付けられている属性に含まれている。この一例は、一般にはリスト入力フィールドに関連付けられている一連の選択肢文字列である。これらの文字列は、ユーザがその中から選択を行う必要があるオプションを表しており、認識時にディクショナリ要素として使用することができる。同様に、組み合わせフィールドの認識では、選択肢文字列のディクショナリを文字文法と組み合わせて使用して、オプションリストにリストされている以外のワードを認識することができる。
【００４０】
標準的な入力フィールドには、認識手順において役立てることのできる属性も含まれていることがある。例えば、いくつかのタイプの入力フィールドは、入力する値が数値でなければならないことを示すフラグを有し、このことは、認識される文字セットには数字が含まれているのみであるべきことを認識システムに知らせる。入力フィールドには、マスク属性が含まれていることもあり、マスク属性は、指定されているパターンに入力が合致しなければならないことを示す文字列である（例えば「＃＃＃＃ＡＡ」は、「２００２ＣＹ」など、４個の数字の後に２つの大文字アルファベットを入力することを要求している）。このマスクを使用することにより、文字列内の各位置における有効な認識文字セットを制約して認識精度を高めることができる。
【００４１】
多くのフォームでは確認パラメータが指定され、これを使用して認識プロセスをガイドすることができる。例えば、数値入力フィールドでは、最小値と最大値とが指定されることがあり、これらを使用して認識結果を制約することができる。別のフィールドには、ユーザがフィールドに値を入力したときに実行される確認プログラムコード（例：ＪａｖａＳｃｒｉｐｔ）が含まれていることがある。このコードは、個々の認識結果のそれぞれをパラメータとして複数回実行することができ、これによって、候補結果のうち確認の必要条件に一致しない候補を破棄することができる。
【００４２】
認識プロセスを向上させる目的でフォームフィールドの標準的な属性を使用することに加えて、カスタム属性を使用して、認識に固有な情報をフィールドに追加することができる。この情報は、フォームへの入力が認識システムを使用して処理される場合に用いられるのみである。従って、カスタム属性は無視されるため、フォームは必要とされている場所で通常どおりに使用することができる（例えば、キーボードを使用してＷｅｂブラウザを通じてのデータ入力）。しかしながら、認識が必要である場合、カスタムパラメータを使用して認識結果を向上させることができる。
【００４３】
カスタムフィールド属性の例として、文字セットの定義（フィールドに有効な文字のセットが明示的に定義されている）と、正規表現とが挙げられる。文字列の間隔空けをガイドするための視覚的な手がかりを使用してフィールドが表示又は印刷されている場合（例えば各ボックスに１文字を入れなくてはならないフォーム上のボックス群）、手書き認識における文字分割段階（ｃｈａｒａｃｔｅｒ  ｓｅｇｍｅｎｔａｔｉｏｎ  ｓｔａｇｅ）を支援するためのカスタム属性として、そのガイドのパラメータをフィールドに関連付けることができる。例えば、枠の長方形の座標と、入力に文字ボックスを使用するフィールド内の行数及び列数を指定することによって、認識システムに各文字の予測位置を知らせて、認識の精度を高めることができる。
【００４４】
コンテキスト処理と言語モデリングに関する情報をカスタム属性の中に符号化することもできる。いくつかの手書き認識システムでは、手書きテキストの認識を支援する目的で言語モデルの組み合わせ（例：ｎ−ｇｒａｍ文字モデル、標準ディクショナリ、ユーザに固有なディクショナリ）を使用する。これらのモデルは、通常、指定されたモデルのそれぞれを使用したときに入力ワードが正しく解読される可能性を示す一連の重み付けを使用して組み合わされる。しかしながら、予測される入力に応じて重み付けをカスタマイズすることができれば、最も正確な結果が得られる。フィールドのカスタム属性として言語モデルの重みを含めることによって、フォームごとに、或いはフィールドごとにモデルの重みを調整することで、より正確な認識を達成することができる。
【００４５】
認識手順の制御性を高めることができるように、手書き認識手順が完了した後に候補結果のそれぞれに対して実行され、最も適切な結果を選択できるようにする、カスタムの確認プログラムコード（例：ＪａｖａＳｃｒｉｐｔ）を、フィールドに関連付けることができる。しかしながら、ブール確認関数（すなわち文字列が有効か無効かのいずれか）を使用するのではなく、文字列が入力された確率を示す信頼値を関数が戻すことができる。この確率を文字分類手順の結果と組み合わせることにより、最も可能性の高い認識結果を選択することができる。このようにすると、解読結果に関連付けられる信頼値がたとえ低くても、他のチェックによってその結果が有効な応答であることが確認される場合、その結果をシステムに受け入れさせることができる。単純なブール方式では、有効な入力が無視される結果となることがある。
【００４６】
この方式の１つの改良は、システムが各文字を認識するときに認識器によって呼び出される言語モデル確率関数を定義することである。これによって、認識システムは、可能性の低い、又は無効な認識文字列を認識手順の早期に除外することができ、長いテキスト文字列を効率的に認識することができる。認識手順においては、認識される文字の様々な組み合わせを考慮することによって多数の候補結果が生成される。一般には、各文字位置に対して多数の候補文字が存在し、従って、たとえそれほど長くないテキストであっても、多数の候補が存在する。この結果として、認識システムは、一般的には、各文字位置におけるｎ個（ｎは一般には１０〜１００）の最良の候補が考慮されるようにビーム探索手法を使用する。従って、各位置におけるｎ個の最も可能性の高い結果が格納され、残りは破棄される。
【００４７】
しかしながら、各ステップにおいてｎ個の最良の結果を選択するためには、認識手順が完了した後ではなく各ステップにおいて言語モデルからの確認が必要であり、そうでないと、スコアは高いが言語モデルによっては不可能な又は可能性が低いと定義される文字列が保持される一方で、有効であるがスコアの低いモデルが破棄されることがある。この結果、改良後の言語モデル関数は、部分文字列の確率を計算して戻すことができる必要があり、その場合、認識器は、各ステップにおいて文字分類の確率と部分文字列の確率とを組み合わせて、ｎ個の最も確率の高い文字列を選択することができる。この柔軟な手法では、ディクショナリ及び文字のマルコフモデルなど、ほぼあらゆる言語モデルを実施することができる。
【００４８】
以下では、ＨＴＭＬ、ＸＦｏｒｍｓ、ＰＤＦ（Ａｄｏｂｅ社のＰｏｒｔａｂｌｅ  Ｄｏｃｕｍｅｎｔ  Ｆｏｒｍａｔ）など一般に使用されている様々なフォーム定義形式の場合について、データを取り出す方法を説明する。
【００４９】
ＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ  Ｍａｒｋ−ｕｐ  Ｌａｎｇｕａｇｅ）は、ＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）ブラウザに表示するように意図されているテキスト及びグラフィックのページの書式を定義する目的に使用される、マークアップ記号の標準セットである。ＨＴＭＬは、Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）によって公式に推奨されており、Ｗ３Ｃの「ＨＴＭＬ  ４．０１  Ｓｐｅｃｉｆｉｃａｔｉｏｎ」（１９９９年１２月２４日）に定義されている。ＸＨＴＭＬは、ＨＴＭＬをＸＭＬアプリケーションとして再定義したものであり、ＨＴＭＬに非常に似ており、Ｗ３Ｃの「ＸＨＴＭＬ  １．０  Ｔｈｅ  Ｅｘｔｅｎｓｉｂｌｅ  ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（第２版）」（２００２年８月１日）に定義されている。同様に、ＳＧＭＬは、ＩＳＯの「ＩＳＯ  ８８７９  Ｉｎｆｏｒｍａｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ  −  Ｔｅｘｔ  ａｎｄ  ｏｆｆｉｃｅ  ｓｙｓｔｅｍｓ−Ｓｔａｎｄａｒｄ  Ｇｅｎｅｒａｌｉｓｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＳＧＭＬ）」（１９８６年）に定義されている。
【００５０】
以下に、フォームのＨＴＭＬコードの一例を示す（このコードによってブラウザ内に生成される出力の例が図１に示してある）。
【００５１】
＜ｈｔｍｌ＞
＜ｆｏｒｍ  ＡＣＴＩＯＮ＝"ｃｇｉ−ｂｉｎ／ｆｏｒｍ．ｅｘｅ"ＭＥＴＨＯＤ＝ｐｏｓｔ＞
＜ｐ＞＜ｂ＞Ｐｌｅａｓｅ  Ｅｎｔｅｒ  Ｙｏｕｒ  Ｎａｍｅ＜／ｂ＞＜／ｐ＞
＜ｐ＞Ｆｉｒｓｔ  Ｎａｍｅ：＜ＩＮＰＵＴ  ＴＹＰＥ＝"ＴＥＸＴ"ＮＡＭＥ＝"ＦｉｒｓｔＮａｍｅ"
ＣＵＳＴＯＭ＝"Ｈｅｌｌｏ"＞＜／ｐ＞
＜ｐ＞Ｌａｓｔ  Ｎａｍｅ：＜ＩＮＰＵＴ  ＴＹＰＥ＝"ＴＥＸＴ"
ＮＡＭＥ＝"ＬａｓｔＮａｍｅ"＞＜／ｐ＞
＜ｐ＞＜ＩＮＰＵＴ  ＴＹＰＥ＝"ＳＵＢＭＩＴ"ＮＡＭＥ＝"Ｓｕｂｍｉｔ"＞＜／ｐ＞
＜／ｆｏｒｍ＞
＜／ｈｔｍｌ＞
通常、入力フィールドに関連付けられているフィールドラベルは、ＨＴＭＬドキュメントのソースから容易に導くことができる。一般的には、フィールドラベルは、（上に示したように）入力フィールドの定義の直前に通常のテキストとして現れる。別の状況では、レンダリングされたドキュメントのレイアウトを分析することで、どのテキストラベルがどの入力フィールドに対応するかを決定することができる（例えば、フォームのレイアウトにテーブルが使用されているとき）。更に、多くの入力要素に関連付けられている「名前」属性には、フィールドタイプを決定することのできるテキストが含まれていることがある。
【００５２】
標準ＨＴＭＬには、認識システムにおいて参考情報として有効に使用することのできる多数の属性が含まれている。以下にいくつかの例を挙げる。
【００５３】
・    ＩＮＰＵＴ要素の「最大長さ」属性。認識されるテキストの長さを限定する目的に使用することができる。
【００５４】
・    一連の有効な入力文字列を表す、ＳＥＬＥＣＴ要素に関連付けられているＯＰＴＩＯＮ要素（認識時にディクショナリエントリとして使用することができる）。
【００５５】
・    文字の間隔空けのガイドを定義する目的で使用されることがある、ＴＥＸＴＡＲＥＡ要素における「行」属性と「列」属性（例：各文字が個別のボックスに書き込まれる必要のあるボックス型入力）。
【００５６】
これらに加えて、カスタム属性をＨＴＭＬフィールド要素に容易に追加することができ（例：ＣＵＳＴＯＭ＝"Ｈｅｌｌｏ"）、なぜなら、ページを処理するブラウザ及びその他のシステムでは、未知の属性は必ず無視されるためである。このようにすると、フォーム設計者は、認識システムによって使用されるのみでありブラウザによって問題なく無視されるカスタム要素を、ＨＴＭＬソースコードに追加することができる。
【００５７】
ＸＦＯＲＭＳは、Ｗ３Ｃによって定義された標準のフォーム定義言語であり、「ＸＦｏｒｍｓ  １．０」Ｗ３Ｃ  Ｗｏｒｋｉｎｇ  ｄｒａｆｔ（２００２年８月２１日）に記載されている。ＸＦｏｒｍｓ標準は、ＨＴＭＬフォームの後継として開発されたものであり、デスクトップコンピュータ、携帯型デバイス、情報機器、更には紙において同じフォームが機能できるようにすることによって、デバイスに依存しないフォーム処理が導入される。これを達成するため、ＸＦｏｒｍｓでは、ＨＴＭＬとは違い、データ定義がプレゼンテーションとは別に保持される。ＸＦｏｒｍｓコードの例を以下に示す。このコードによってブラウザ内に生成される出力の例が図２に示してある。
【００５８】
＜ｘｆｏｒｍ＞
＜ｓｕｂｍｉｔＩｎｆｏ  ａｃｔｉｏｎ＝"ｆｏｒｍ．ｅｘｅ"ｍｅｔｈｏｄ＝"ｐｏｓｔ"／＞
＜／ｘｆｏｒｍ＞
＜ｉｎｐｕｔ  ｘｆｏｒｍ＝"ｐａｙｍｅｎｔ"ｒｅｆ＝"ｃｃ"＞
＜ｃａｐｔｉｏｎ＞Ｃｒｅｄｉｔ  Ｃａｒｄ  Ｎｕｍｂｅｒ＜／ｃａｐｔｉｏｎ＞
＜／ｉｎｐｕｔ＞＜ｉｎｐｕｔ  ｘｆｏｒｍ＝"ｐａｙｍｅｎｔ"ｒｅｆ＝"ｅｘｐ"＞
＜ｃａｐｔｉｏｎ＞Ｅｘｐｉｒａｔｉｏｎ  Ｄａｔｅ＜／ｃａｐｔｉｏｎ＞
＜／ｉｎｐｕｔ＞＜ｓｕｂｍｉｔ  ｘｆｏｒｍ＝"ｐａｙｍｅｎｔ"＞
＜ｃａｐｔｉｏｎ＞Ｓｕｂｍｉｔ＜／ｃａｐｔｉｏｎ＞
＜／ｓｕｂｍｉｔ＞
ＨＴＭＬの場合と同じように、入力フィールド定義の中のキャプション要素を調べることによって、フィールドラベルをＸＦｏｒｍｓコードから導くことができる。これに加えて、ＸＦｏｒｍｓでは、リスト選択要素「＜ｓｅｌｅｃｔＯｎｅ＞」、「＜ｓｅｌｅｃｔＭａｎｙ＞」や対応する「＜ｉｔｅｍ＞」要素など、ＨＴＭＬについて前述したものに似た入力フィールド要素がサポートされており、これらは認識処理時にディクショナリエントリとして使用することができる。
【００５９】
ＸＦｏｒｍｓ仕様には、日付、通貨、番号、文字列、時刻、ＵＲＩタイプなど、フィールド入力の一連のデータタイプが含まれている。この情報は、認識精度を高める目的で認識システムによって使用することができる。同様に、ＸＦｏｒｍｓ仕様には、データ属性（例：通貨、小数位、整数）と確認属性（最小値、最大値、パターン、範囲）とが含まれており、これらを使用して認識結果を更に高めることができる。
【００６０】
ＰＤＦ（Ｐｏｒｔａｂｌｅ  Ｄｏｃｕｍｅｎｔ  Ｆｏｒｍａｔ）は、Ａｄｏｂｅ社によって定義されたドキュメント形式であり、インターネットベースでドキュメントを配布するときの事実上の標準になっている。最近、Ａｄｏｂｅ社は、オンラインで使用するための形式を定義することができる対話型要素を追加した。
【００６１】
ＨＴＭＬやＸＦｏｒｍｓと同様に、ＰＤＦのフォーム要素は、要素の挙動を定義する固有のタイプ（例：テキスト、署名、コンボボックス、リストボックス）を持ち、これを手書き認識システムのガイドとして使用することができる。ＰＤＦのフォーム要素にはフィールド名（例：「／Ｔ（ＦｉｒｓｔＮａｍｅ）」）も含まれており、フィールド名には、フィールドに入力されるデータのタイプを示す有用なラベルが含まれていることがある。リストフィールドと組み合わせフィールドには、有効な選択肢文字列を定義する一連のオプション（「／Ｏｐｔ［（Ｏｐｔｉｏｎｌ）（Ｏｐｔｉｏｎ２）］」）が含まれている。
それ以外のフィールド属性としては、形式指定子（例：番号、パーセント、日付、時刻、郵便番号、電話番号、社会保障番号など）と、データがフィールドに入力されたときに実行されるＪａｖａＳｃｒｉｐｔ確認コードとが挙げられる。カスタム属性も、上述したようにフィールド定義に容易に組み込むことができる（「／ＣＵＳＴＯＭ＿ＡＴＴＲＩＢＵＴＥ（ＨｅｌｌｏＷｏｒｌｄ）」）。
【００６２】
本発明の実施形態は、プログラムされて調整された適切なマイクロプロセッサを使用して実施することができる。このようなマイクロプロセッサは、文字認識環境において動作するように特に設計されているカスタムシステムの一部を形成することができ、又は、デスクトップＰＣなど、他の一般的なタスクを実行することもできる汎用コンピュータとすることができる。
【００６３】
上記の説明に照らして、通常の技術を有する者には、本発明の範囲内で様々な変更を行うことができることが明らかであろう。
【００６４】
本発明は、明示的に又はその一般化が本明細書に開示されている新規の特徴、又は特徴の組み合わせを、それらが請求項に記載されている本発明に関連するか否か、又は、取り扱われている問題の一部又はすべてを緩和するか否かに関係なく、包含する。
【図面の簡単な説明】
【００６５】
【図１】２つの入力フィールドを持つ代表的なフォームを示している。
【図２】別の２つの入力フィールドを持つ別の代表的なフォームを示している。
【図３ａ】似ているが異なる手書きサンプルを示している。
【図３ｂ】似ているが異なる手書きサンプルを示している。
【図１】
2006503353.tif 000003
【図２】
2006503353.tif 000004
2006503353.tif 000005
【手続補正書】
【提出日】平成16年9月10日(2004.9.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
電子フォームベースのデータ入力システムに入力されるデータを解釈する方法であって、
可動入力装置から動きデータを受信するステップであって、前記動きデータは電子フォームの特定のフィールドに関連付けられている、前記ステップと、
少なくともひとつの手書きアルゴリズムを動きデータに適用することによって、動きデータにおける情報内容の一つ以上の可変部分を決定するステップと、
電子フォームの特定のフィールドに関連付けられている少なくともひとつのパラメータを利用することによって、情報内容の好適な可変部分を決定するステップと、
を含む方法。
【請求項２】
電子フォームベースのデータ入力システムに入力されるデータを解釈する方法であって、
可動入力装置から動きデータを受信するステップであって、前記動きデータは電子フォームの特定のフィールドに関連付けられている、前記ステップと、  
電子フォームの特定のフィールドに関連付けられている少なくともひとつのパラメータを利用することによって、動きデータにおける情報内容の可変部分のタイプを制限するステップと、
少なくともひとつの手書きアルゴリズムを動きデータに適用することによって、情報内容の可変部分の制限されたタイプから、動きデータにおける情報内容の好適な可変部分を決定するステップと、
を含む方法。
【請求項３】
情報内容の好適な可変部分を決定するステップは、情報内容の可変部分のそれぞれに割り当てられている確率値を利用する、請求項１又は２のいずれか１項に記載の方法。
【請求項４】
情報内容の好適な可変部分を決定するステップは、動きデータを受信するステップと同時に実行される、請求項１又は２のいずれか１項に記載の方法。
【請求項５】
前記可動入力装置は、ペンのような装置である、請求項１〜４のいずれか１項に記載の方法。
【請求項６】
情報内容の可変部分を決定するステップは、動きデータ内に含まれるストローク情報を利用する、請求項１〜５のいずれか１項に記載の方法。
【請求項７】
前記電子フォームの特定のフィールドに、情報内容の可変部分の事前定義されているディクショナリが関連付けられており、前記ディクショナリが情報内容の好適な可変部分を決定する目的で使用される、請求項１〜６のいずれか１項に記載の方法。
【請求項８】
前記ディクショナリ内の特定のエントリに、情報内容の好適な可変部分になる高い確率が割り当てられている、請求項７に記載の方法。
【請求項９】
前記電子フォームの特定のフィールドが名前フィールドであり、前記ディクショナリが、選択される名前に対応する性別の情報を含んでいる、請求項７又は８のいずれかに記載の方法。
【請求項１０】
前記電子フォームの特定のフィールドが、階層的に編成されているサブフィールドを有する住所フィールドであり、サブフィールド内の情報内容の好適な可変部分を、別のサブフィールド内の情報内容の可変部分を制約する目的に使用することができる、１〜１０のいずれか１項に記載の方法。
【請求項１１】
前記電子フォームの特定のフィールドが電話番号フィールドであり、前記情報内容の可変部分は数字のみを含むように制約される、請求項１〜１０のいずれか１項に記載の方法。
【請求項１２】
前記電子フォームの特定のフィールドがクレジットカード番号であり、前記情報内容の可変部分は一定の数の数値のみを含むように制約され、前記数値をチェックサムの使用によって更に確認することができる、請求項１〜１１のいずれか１項に記載の方法。
【請求項１３】
前記電子フォームの特定のフィールドが、郵便番号、国、日付、電子メールアドレス、及び/又は言語、を含むセットからなる、請求項１〜１２のいずれか１項に記載の方法。
【請求項１４】
前記電子フォームが、標準化されているファイル形式であるＨＴＭＬ、ＸＭＬ、ＰＤＦ、及びＸＦｏｒｍｓのうちの１つを使用して実施されている、請求項１〜１３のいずれか１項に記載の方法。
【請求項１５】
カスタムの確認プログラムが前記電子フォームの特定のフィールドに関連付けられており、前記カスタムの確認プログラムが、前記情報内容の特定の可変部分の決定に基づいて実行される、請求項１〜１４のいずれか１項に記載の方法。
【請求項１６】
前記カスタムの確認プログラムがＪａｖａＳｃｒｉｐｔプログラムである、請求項１５に記載の方法。
【請求項１７】
フィールドマスクが前記電子フォームの特定のフィールドに関連付けられており、前記フィールドマスクは、前記情報内容の可変部分が事前定義されている文字列パターンに一致するかを調べるのに用いられる、請求項１〜１６のいずれか１項に記載の方法。
【請求項１８】
前記情報内容の可変部分が、以前に決定された好適な可変部分を使用して、選択肢リスト又は組み合わせリストから導かれる、請求項１〜１７のいずれか１項に記載の方法。
【請求項１９】
前記電子フォームが、コード化されたマーキングを提供する紙ベースのインタフェースである、請求項１〜１８のいずれか１項に記載の方法。
【請求項２０】
前記コード化されたマーキングは、赤外マーキングのパターンである、請求項１〜１９のいずれか１項に記載の方法。
【請求項２１】
前記可動入力装置は、光学イメージペンである、請求項１〜２０のいずれか１項に記載の方法。
【請求項２２】
各電子フォームは、独特に識別され、ネットワーク上に格納される、請求項１〜２１のいずれか１項に記載の方法。
【請求項２３】
ユーザが電子フォームベースのデータ入力システムに情報内容を入力できる方法であって、
ユーザに電子フォームを提供するステップであって、電子フォームはそこの中または上に、電子フォームの特定のフィールドおよび電子フォームの少なくとも一つの参照ポイントを示すコード化されたデータを配置させる、前記ステップと、
ユーザによって操作され、コンピュータシステムにおいて、感知デバイスから、電子フォームの識別および電子フォームに対する感知デバイスの少なくとも一つの位置および動きに関して示しているデータを受信するステップと、
電子フォームの特定のフィールドに関連付けられている少なくともひとつのパラメータを利用することによって、前記示しているデータからの情報内容の好適な可変部分を決定するステップと、
を含み、
前記感知センサは、
（ａ）感知センサが電子フォームに対して動作位置に配置された際に、コード化されたデータの少なくとも幾つかのイメージを取り込むように構成されたイメージセンサと、
（ｂ）（ｉ）ひとつ以上の取り込みイメージからコード化されたデータの少なくとも幾つかを識別し、
（ｉｉ）コード化されたデータの少なくとも幾つかを解読し、
（ｉｉｉ）解読されたコード化データの少なくとも幾つかを用いて、前記示しているデータを生成する、
ように構成されたプロセッサと、
を備えている、
前記方法。
【請求項２４】
前記電子フォームの特定のフィールドは、少なくとも一つの電子フォームのゾーンに関連付けられていて、方法は、コンピュータシステム内および少なくとも一つのゾーンから、少なくとも一つのパラメータを識別するステップを含む、請求項２３に記載の方法。
【国際調査報告】
2006503353.tif 000006
2006503353.tif 000007
2006503353.tif 000008