(57)【要約】【課題】携帯電話のビジネスユーザや職業ユーザ向けアプリケーションの多くに対して不足した技術を補う。【解決手段】文書内の情報解釈方法および情報解釈システムを提供する。これらは、遠隔源から受信した文書の画像を保存し、キャラクタのブロックからなる多数の集合に前記画像を変換するシステムを備える。各ブロックの起こり得る意味を示すタグが、当該各ブロックに割り当てられる。少なくともブロックの幾つかは、それに関連付けられたスコアを有し、このスコアは、ブロック内におけるキャラクタがオリジナル画像内のキャラクタを正確にあらわす確率を示している。前記システムは、インターネット越しに遠隔情報をアクセスすることにより決定される所定のブロックに関連付けられたスコアに基づき、多数の集合から一つの集合を選択する。別な態様では、カメラ付きの携帯手持ちデバイスから、メッセージの形態で受信される情報処理方法を提供し、このメッセージは、文書の画像をあらわすデータと、前記文書の種類の識別子とを含む。好ましくは、本方法は画像の画質向上と、情報認識と、識別された文書の種類に基づき選択された分析とを提供する。システムの出力は、例えば電子メールのように、好ましくはユーザによって特定されたフォームで、当該ユーザに提供される。【選択図】図１
2008546058.tif 000002
【特許請求の範囲】
【請求項１】
遠隔源からの文書の画像を受信し、
キャラクタからなるテキストとして前記画像を表わし、前記キャラクタの少なくとも幾つかは代替バージョンを有していて、その代替バージョンは関連する信頼確率を備えており、
トークンとして前記テキストを表わし、このトークンはキャラクタの集合からなり、異なるキャラクタのバージョンに対して異なるトークンが定義され、
トークンをトークン化されたものに結合し、それぞれのトークン化されたものはトークンの集合からなり、種々のバージョンを備えたキャラクタに対して、一つのバージョンだけがトークン化されたものに含まれ、
一乃至複数のタグをこれらのトークンに割り当て、前記タグはそれに対応するトークンの可能性のある意味を示しており、対応するタグの正確さの確率を示すスコア値を割り当て、
多数のトークン化されたものを取得するのに、予め決められた文法に基づき前記トークン化されたもののそれぞれを構文解析し、関連付けされたスコアを有する一つのタグだけが、辞書および文法双方のマッチングに基づき、それぞれのトークンに割り当てられ、
前記文法の順守と全てのトークンのスコアに基づき、それぞれのトークン化されたものに総計のスコアを割り当て、
多数のタグ付きのトークン化されたものから最終的なトークン化されたものを取得するのに、成功したものを測定基準として、前記総計のスコアを用いて、タグ付きのトークン化されたものの一つを選択することを特徴とする文書内の情報解釈方法。
【請求項２】
前記文書に表される情報が、限られた数の識別可能な語義構造からなり、前記語義構造のサブ集合は一回だけ存在し、唯一の意味を有することを特徴とする請求項１記載の方法。
【請求項３】
前記タグとスコアを割り当てるステップは、前記トークン化されたもののトークンをフィルタリングするステップを含むことを特徴とする請求項１記載の方法。
【請求項４】
前記フィルタリングのステップは、辞書内のトークンを検索するステップを含み、前記辞書はタグと、そのタグ割り当てが正確であるとの確率をあらわすスコアの両方を含んでいることを特徴とする請求項３記載の方法。
【請求項５】
前記フィルタリングのステップは、前記文書内で予期される共通のワードとして所定のトークンを識別し、この共通のワードに関係する位置に基づき、隣のワードにタグを割り当てるステップを含むことを特徴とする請求項３記載の方法。
【請求項６】
前記構文解析のステップは、文書内のどこでも開始するようになっており、文法規則の状況を満足するのに、前方および後方の両方における検索を含むことを特徴とする請求項１記載の方法。
【請求項７】
前記最終的なトークン化されたものをデータ構造に変換するステップをさらに含み、前記タグは前記データ構造の配置フィールドを特定し、前記トークンはそうしたフィールドにデータを提供することを特徴とする請求項１記載の方法。
【請求項８】
どの文法と辞書のセットが前記文書を処理するのに用いられるべきなのかを指示するフラグを受信することを特徴とする請求項１記載の方法。
【請求項９】
前記選択のステップは、多数のトークン化されたものから外部データに所定のトークン化されたものの第１の部分を提供することからなり、それにより前記第１の部分にマッチングするレコードを探し出すことを特徴とする請求項１記載の方法。
【請求項１０】
前記レコード内において情報を有する前記所定のトークン化されたものの第２の部分間で、マッチが存在するか否かを決定するステップをさらに備えたことを特徴とする請求項９記載の方法。
【請求項１１】
前記マッチが存在するならば、前記最終的なトークン化されたものとして、前記所定のトークン化されたもののスコアを増加させるステップをさらに備えたことを特徴とする請求項１０記載の方法。
【請求項１２】
前記第２の部分に対し部分的なマッチが発見されたならば、前記所定のトークン化されたものの第２の部分を補正するステップをさらに備えたことを特徴とする請求項１０記載の方法。
【請求項１３】
前記トークン化されたものの一つを選択するステップは、前記第１の部分にマッチングする第１のページを見つけるために、多数のトークン化されたものの集合から所定のトークン化されたものの第１の部分を利用して、インターネットのウェブサイトを検索するステップをさらに備えたことを特徴とする請求項１記載の方法。
【請求項１４】
前記ページ内において情報を有する前記所定のトークン化されたものの第２の部分間で、マッチが存在するか否かを決定するステップをさらに備えたことを特徴とする請求項１３記載の方法。
【請求項１５】
マッチした箇所のページ数に基づき、前記最終的なトークン化されたものとして、前記所定のトークン化されたものを選択する確率を増加させるステップをさらに備えたことを特徴とする請求項１４記載の方法。
【請求項１６】
前記最終的なトークン化されたものと前記タグが正しいとの可能性について、この可能性の測定を決定し、もし当該測定が不十分ならば、マニュアル処理のために文書と文書の画像を提供するステップをさらに備えたことを特徴とする請求項１記載の方法。
【請求項１７】
遠隔源からの文書の画像を受信し、
キャラクタのブロックからなる多数の集合に前記画像を変換し、前記各集合における前記ブロックは、その起こり得る意味を示すタグが割り当てられ、少なくとも前記ブロックの幾つかは、それに関連付けられたスコアを有し、このスコアは、ブロック内におけるキャラクタが前記画像内のキャラクタを正確にあらわす確率を示しており、
前記ブロックの少なくとも幾つかと関連付けられたスコアと、インターネット越しに遠隔情報をアクセスする結果として提供された情報とに基づき、前記多数の集合から一つの最終的な集合を選択する各ステップからなることを特徴とする文書内の情報解釈方法。
【請求項１８】
前記画像を変換するステップは、前記画像をキャラクタからなるテキストに変換するステップからなり、キャラクタの少なくとも幾つかは代替バージョンを有していて、その代替バージョンは信頼確率が割り当てられることを特徴とする請求項１７記載の方法。
【請求項１９】
前記変換ステップによって提供された代替バージョンに基づき、キャラクタのグループ集合を形成し、一乃至複数のタグを各集合に割り当てるステップをさらに備えたことを特徴とする請求項１８記載の方法。
【請求項２０】
所定のタグのスコアを取り去るか或いは減少させ、ブロック毎に最高のスコアのタグを一つだけを残すために、予め決められた文法に基づいて、前記ブロックの各集合を構文解析するステップをさらに備えたことを特徴とする請求項１９記載の方法。
【請求項２１】
前記構文解析のステップは、文書内のどこでも開始するようになっており、文法規則の状況を満足するのに、前方および後方の両方における検索を含むことを特徴とする請求項１７記載の方法。
【請求項２２】
前記一つの最終的な集合を選択するステップは、
多数の集合から一つの集合における第１の一乃至複数のブロックを外部データベースに提供し、それにより前記一乃至複数のブロックとマッチングするレコードを見つけ出し、このブロックに前記マッチの結果としてのスコアを割り当てるステップをさらに備えたことを特徴とする請求項１７記載の方法。
【請求項２３】
前記レコード内において情報を有する前記集合の第２の一乃至複数のブロック間で、マッチが存在するか否かを決定するステップをさらに備えたことを特徴とする請求項２２記載の方法。
【請求項２４】
前記マッチが存在するならば、前記最終的な集合として、前記集合のスコアを増加させるステップをさらに備えたことを特徴とする請求項２３記載の方法。
【請求項２５】
前記第２の一乃至複数のブロックに対し正確なマッチが発見されなければ、前記第２の一乃至複数のブロックを補正するステップをさらに備えたことを特徴とする請求項２４記載の方法。
【請求項２６】
前記一つの最終的な集合を選択するステップは、
多数の集合から一つの集合における第１の一乃至複数のブロックを用いて、インターネットのウェブサイトを検索し、それにより前記第１の一乃至複数のブロックとマッチングするページを見つけ出すステップをさらに備えたことを特徴とする請求項１７記載の方法。
【請求項２７】
前記ページ内において情報を有する前記集合の第２の一乃至複数のブロック間で、マッチが存在するか否かを決定するステップをさらに備えたことを特徴とする請求項２６記載の方法。
【請求項２８】
マッチした箇所のページ数に基づき、前記最終的な集合として、前記集合を選択する確率を増加させるステップをさらに備えたことを特徴とする請求項２７記載の方法。
【請求項２９】
遠隔源から受信した文書の画像を保存する記憶体と、
キャラクタのブロックからなる多数の集合に前記画像を変換し、その意味を示すタグを有し、少なくとも前記ブロックの幾つかは、それに関連付けられたスコアを有し、このスコアは、ブロック内におけるキャラクタが前記画像を正確にあらわす確率を示すソフトウェアと、
ブロックの少なくとも幾つかと関連付けられたスコアと、インターネット越しに遠隔情報をアクセスする結果として提供された情報とに基づき、前記多数の集合から一つの最終的な集合を選択するソフトウェアと、からなることを特徴とする文書内の情報解釈システム。
【請求項３０】
前記変換するソフトウェアは、キャラクタのグループ集合を形成し、一乃至複数のタグを各集合に割り当てるソフトウェアからなることを特徴とする請求項２９記載のシステム。
【請求項３１】
所定のタグを取り去って、ブロック毎にタグを一つだけを残すために、予め決められた文法に基づいて、ブロックの各集合を構文解析するソフトウェアをさらに備えたことを特徴とする請求項３０記載のシステム。
【請求項３２】
前記構文解析のソフトウェアは、文書内のどこでも構文解析するようになっており、文法規則の状況を満足するのに、前方および後方の両方における検索する手段を含むことを特徴とする請求項２９記載のシステム。
【請求項３３】
前記一つの最終的な集合を選択するソフトウェアは、
多数の集合から所定の集合における第１の一乃至複数のブロックを外部データベースに提供し、それにより前記一乃至複数のブロックとマッチングするレコードを見つけ出すソフトウェアをさらに備えたことを特徴とする請求項２９記載のシステム。
【請求項３４】
前記レコード内において情報を有する前記所定の集合から、第２の一乃至複数のブロック間で、マッチが存在するか否かを決定するソフトウェアをさらに備えたことを特徴とする請求項３３記載のシステム。
【請求項３５】
前記マッチが存在するならば、前記最終的な集合として、前記所定の集合を選択する確率を増加させるソフトウェアをさらに備えたことを特徴とする請求項３４記載のシステム。
【請求項３６】
前記一つの最終的な集合を選択するソフトウェアは、
多数の集合から所定の集合における第１の一乃至複数のブロックを用いて、インターネットのウェブサイトを検索し、それにより前記第１の一乃至複数のブロックとマッチングするページを見つけ出すソフトウェアをさらに備えたことを特徴とする請求項２９記載のシステム。
【請求項３７】
前記ページ内において情報を有する前記所定の集合の第２の一乃至複数のブロック間で、マッチが存在するか否かを決定するソフトウェアをさらに備えたことを特徴とする請求項３６記載のシステム。
【請求項３８】
マッチした箇所のページ数に基づき、前記最終的な集合として、前記所定の集合をのスコアを増加させるソフトウェアをさらに備えたことを特徴とする請求項３７記載のシステム。
【請求項３９】
（１）前記最終的なトークン化されたものと前記タグが正しいとの可能性について、この可能性の測定を決定し、
（２）もし当該測定が不十分ならば、マニュアル処理のために文書と文書の画像を提供するソフトウェアをさらに備えたことを特徴とする請求項２９記載のシステム。
【請求項４０】
取得されるべき情報の種類を選択するための性能をユーザに提供し、
前記ユーザにより識別された情報を取得し、この情報を取得するステップは、前記選択した情報の種類に応じて調整され、
前処理された情報を取得するために情報を前処理し、この情報を前処理するステップは、前記選択した情報の種類に応じて調整され、
前記情報の種類を識別するデータを含むメッセージに後処理を行なうのに、前記前処理された情報をサーバに提供する各ステップからなることを特徴とするカメラ付き携帯手持ちデバイスを利用した情報取得方法。
【請求項４１】
前記情報の種類は、名刺，レシート，フォーム，印刷済文書，手書き情報，ホワイトボード，およびグラフィック関連マークからなるグループから選択されることを特徴とする請求項４０の方法。
【請求項４２】
前記情報を前処理するステップは、前記取得した情報から、背景情報を取り去るステップをさらに含むことを特徴とする請求項４０の方法。
【請求項４３】
前記手持ちデバイスはフラッシュを備え、前記情報を取得するステップは、取得されるべき情報の前記種類に基づいて、フラッシュを調整するステップを含むことを特徴とする請求項４０の方法。
【請求項４４】
前記情報の取得が成功したことの確認を、ユーザから受取るステップをさらに備えたことを特徴とする請求項４０の方法。
【請求項４５】
ホワイトボードを取得するのに、連続する画像を取得するステップをさらに備えたことを特徴とする請求項４０の方法。
【請求項４６】
前記手持ちデバイスは携帯電話であることを特徴とする請求項４０の方法。
【請求項４７】
前記前処理情報を圧縮するステップをさらに備え、当該ステップで後処理のために前記サーバに提供される前記前処理情報が予め圧縮されることを特徴とする請求項４０の方法。
【請求項４８】
前記圧縮するステップは、前記選択された情報の種類に応じて調整されることを特徴とする請求項４７の方法。
【請求項４９】
前記前処理された情報をサーバに提供するステップにおいて、前記メッセージは、前記手持ちデバイスの性能を識別する情報をさらに含むことを特徴とする請求項４０の方法。
【請求項５０】
前記手持ちデバイスは、カメラおよび無線インターネットの各性能を有する携帯電話であることを特徴とする請求項４０の方法。
【請求項５１】
前記情報を取得するステップは、カメラで写真を撮影するステップを含むことを特徴とする請求項４０の方法。
【請求項５２】
前記情報を取得するステップは、別なデバイスとの無線接続越しに、他のデバイスからの画像を受信するステップを含むことを特徴とする請求項４０の方法。
【請求項５３】
カメラを含む携帯手持ちデバイスから、文書の画像をあらわすデータおよび文書の種類の識別子を含むメッセージを受信し、
前記データおよびそれに関連する識別子を保存し、
画質向上した画像を取得するために、前記識別子に基づいて画像の画質向上を行ない、
非画像フォーマットにて前記画像をあらわすデータを取得するために、前記画質向上した画像で情報を認識し、前記識別子に従って認識技術が決定され、
特定の文書に対し、前記データ内の情報の意味を取得するために、非画像フォーマットにて前記画像をあらわすデータの少なくとも幾つかを分析し、前記意味に従って前記データの各部を保存し、
前記識別子に従ってフォーマットされた情報を有する識別子の値に依存して、前記認識するステップおよび前記分析するステップのうち、一つの結果を含んだ出力メッセージを生成し、
前記メッセージをユーザに提供する各ステップからなることを特徴とする情報処理方法。
【請求項５４】
前記メッセージを受信するステップは、
データの種類を選択して、その種類の前記識別子を保存するステップと、前記識別子に基づき前記カメラを調整するステップと、前記識別子に基づき前記データを前処理するステップを行なうことで取得されることを特徴とする請求項５３記載の方法。
【請求項５５】
前記メッセージを受信するステップは予め圧縮され、さらに前記識別子の値に基づいて、圧縮されたデータを復元するステップをさらに備えたことを特徴とする請求項５３記載の方法。
【請求項５６】
前記情報を認識するステップは、その情報のキャラクタ認識動作を行なうステップを含むことを特徴とする請求項５３記載の方法。
【請求項５７】
前記情報を認識するステップは、その情報の手書きテキスト認識を行なうステップを含むことを特徴とする請求項５３記載の方法。
【請求項５８】
前記データの少なくとも幾つかを分析するステップは、トークン化ステップと、初期分類ステップと、構文解析ステップと、最良の適合を選択するステップとを含むことを特徴とする請求項５３記載の方法。
【請求項５９】
前記データの少なくとも幾つかは、前記識別子に基づいて選択された辞書および文法規則の利用を含むことを特徴とする請求項５３記載の方法。
【請求項６０】
前記画像の画質向上を行なうステップは、暗さと明るさの階調度を補正するステップを含むことを特徴とする請求項５３記載の方法。
【請求項６１】
前記画像の画質向上を行なうステップは、背景ノイズを除去するステップを含むことを特徴とする請求項５３記載の方法。
【請求項６２】
前記画像の画質向上を行なうステップは、背景と前景のセグメンテーションを行なうステップを含むことを特徴とする請求項５３記載の方法。
【請求項６３】
前記手持ちデバイスは携帯電話であることを特徴とする請求項５３記載の方法。
【請求項６４】
前記受信したメッセージは、前記手持ちデバイスの性能をあらわすデータを含むことを特徴とする請求項５３記載の方法。
【請求項６５】
前記受信したメッセージは、前記ユーザへの前記出力メッセージの配信モードをあらわすデータを含むことを特徴とする請求項５３記載の方法。
【請求項６６】
前記メッセージをユーザに提供するステップは、前記ユーザに電子メールを送信するステップを含むことを特徴とする請求項５３記載の方法。
【請求項６７】
前記メッセージをユーザに提供するステップは、前記ユーザにファックスを送信するステップを含むことを特徴とする請求項５３記載の方法。
【請求項６８】
カメラと、
フラッシュと、
情報の種類を選択するための性能をユーザに提供するソフトウェアを含んでおり、この情報は手持ちデバイスによって取得されるユーザインターフェースソフトウェアと、
前記ユーザによって選択された情報の種類に基づき、前記ユーザによって識別された情報の取得を調整するソフトウェアと、
前処理された情報を取得するために情報を前処理するもので、前記選択した情報の種類に基づいて調整を行なう手段と、
後処理のために前記前処理された情報をサーバに提供するもので、前記前処理された情報は、前記情報の種類を識別するデータを含むメッセージの形態である手段と、からなることを特徴とする情報取得用携帯手持ちデバイス。
【請求項６９】
前記メッセージは、前記携帯手持ちデバイスの性能を識別するデータを含むことを特徴とする請求項６８記載のデバイス。
【請求項７０】
カメラ，および情報の種類をユーザが選択できるように設定されたユーザインターフェースを含み、前記情報の種類はメニューから取得されるもので、前記カメラは前記選択された情報を取得するのに適合され、前記取得した情報を前処理し、この取得した情報を任意に圧縮するのに設定されたソフトウェアを含む携帯手持ちデバイスと、
前記手持ちデバイスと通信を行なう後処理サーバを含む一乃至複数のサーバを備え、それにより前処理された情報が前記後処理サーバに伝送され、この後処理サーバは、前記前処理された情報を予め決められたフォーマットを有する後処理された情報に変換するように構成されるネットワークと、
前記後処理された情報を、前記予め決められたフォーマットでユーザに伝送する手段と、からなることを特徴とする情報を取得および処理するネットワークシステム。
【請求項７１】
前記携帯手持ちデバイスは携帯電話からなり、前記情報は前記カメラを用いてディジタル画像として取得できるビジネス関連情報からなり、このビジネス関連情報は、当該ビジネス関連情報の様々な種類をリストするメニューを備えていることを特徴とする請求項７０記載のデバイス。
【請求項７２】
メニューの入力としてリストされる前記ビジネス関連情報は、名刺，レシート，フォーム，印刷済文書，手書き情報，ホワイトボード，およびグラフィック関連マークを含むことを特徴とする請求項７１記載のデバイス。
【請求項７３】
前記メニューにおけるそれぞれの入力に対してサブメニューをさらに備え、このサブメニューは、前記ビジネス関連情報を送信し、および前記ビジネス関連情報を保存するものの少なくとも一つに対するオプションを、ユーザに提供するものであることを特徴とする請求項７１記載のデバイス。
【請求項７４】
前記予め決められたフォーマットは電子メールの形態であり、この電子メールは前記ユーザと関連付けられたメールサーバに配信されるものであることを特徴とする請求項７１記載のデバイス。
【請求項７５】
前記携帯デバイスと関連付けられた前記ソフトウェアは、前記ユーザによって識別された前記情報を、当該ユーザによって選択された前記情報の種類に基づいて、どのように取得するのかを調整するように設定され、前記選択された情報の種類に基づいて、前記情報の前処理で調整を行なうソフトウェアを利用して、前処理された情報を取得するために、前記情報が処理されることを特徴とする請求項７０記載のデバイス。
【発明の詳細な説明】
【背景技術】
【０００１】
カメラ組み込み型の携帯（セル方式）電話はよく知られており、広く用いられている。こうした電話は写真を撮影して、その写真を電話に記憶することが可能である。その後で当該写真は、電話技術を介した公知の画像データ伝送技術を用いて、ユーザの電子メールにおけるメールボックスに、添付ファイルとして送信することができる。さらには、様々なアプリケーションをサポートできる比較的強力なプロセッサと、それに関連する電子技術を、携帯電話に含めることも知られている。
【発明の開示】
【発明が解決しようとする課題】
【０００２】
しかし、写真の保存および伝送を除いて、携帯電話−カメラ−電子メールの組合せが、各アプリケーションに対して今まで有効に利用されてはいなかった。例えば、名刺，テキスト文書，書式，手書きメモ、および他のビジネス文書，技術的文書，若しくは専門的文書を取得し、文書の本質と整合する都合の良い形式（フォーマット）で、それらの取得したものをユーザに提供することが望まれている。また例えば、名刺を捕捉するのに携帯電話を用い、ユーザ自身の電子化されたソフトウェア“contact organizer”への入力に好適なインタープリタ型データとして、この捕捉した名刺をユーザに提供することが望まれている。同様に、文書を取得し、その文書を認識されるテキストとしてユーザに提供したり、或いは手書きメモを取得し、その手書きメモをテキスト文書としてユーザに提供したりすることも有用であると思われる。
【０００３】
光学文字認識（ＯＣＲ）や、手書き認識（ＩＣＲ）を行なうことで、名刺を保存する技術は存在するものの、こうした技術が携帯電話の画像アプリケーションと有効に組み合わされてはいなかった。それらを扱う職業者は、自身のオフィスから離れて相当な時間を費やすので、職業者の大部分が手軽にアクセスできる通信ツールが携帯電話となる。したがって、カメラ付きの携帯電話を、職業者やビジネスマンのニーズに適合させることが大切である。例えば職業者は、自身の携帯電話を用いて会議で受取った名刺を捕捉し、その捕捉した名刺をインタープリタ型の書式で、自身の電子メールアカウントに転送することが、極めて有用であると分かるであろう。同様に、オフィス外のミーティングで生成したメモを、ミーティング後直ぐにテキストとして、ユーザ自身の電子メールにおけるメールボックスに伝送することが、有用であると思われる。
【０００４】
このように、多くの技術的コンポーネントに有用性があるにも拘らず、携帯電話のビジネスユーザや職業ユーザ向けアプリケーションの多くに対して、今なお技術が不足している。こうしたユーザは、ここでは一般的に文書若しくは専門的情報として引用される各種の情報について、特殊な処理が必要であると思われる。
【発明を実施するための最良の形態】
【０００５】
最初に図１を参照するが、この図１は、本発明の一実施例に基づいて、データを取得して処理するためのシステム１００と関連したコンピュータアーキテクチャ（構造）を示す概略図である。当該システム１００と、それに関連した処理方法は、システム以外の関連した方法と同様に、一つのサービスとであるとして考え、ここで引用され得る。図示したシステム１００は、本実施例によれば携帯電話である手持ち通信デバイス１１０を含んでいる。携帯電話１１０は、標準の通信ソフトウェアなどと同様に、既存のコンポーネントである例えばプロセッサやそれと同類のものを含んでいる。ここでの携帯電話１１０は、カメラ１２０を含む種類のものであって、このカメラ１２０は画像の捕捉と保存を可能にする。カメラ１２０が携帯電話への利用に意図された種類のもので、そのために極小サイズの撮影体であるならば、かなり多数の様々な種類の撮影体をカメラ１２０とすることができる。携帯電話１１０の一部となるカメラ１２０を有することで、携帯電話１１０は、カメラ１２０を用いて捕捉された各画像を処理するための、追加のソフトウェアを備えている。
【０００６】
さらに、後ほどより詳細に記述するが、携帯電話１１０は予め選択された情報（例えば、専門的情報）を処理するソフトウェアを含むものの、それは典型的な従来のカメラ付き携帯電話のように、別な方法で構築される。携帯電話１１０は、“contact organizer”や個人的な演算機能を含めて、こうした電話において習慣的に利用可能な、様々な別に知られている特徴を任意に含めることができる。
【０００７】
携帯電話１１０は、セルラーネットワーク１３と通じており、同様にインターネットネットワーク（インターネット）１４０とも通じている。システム１００はさらに、当該システム１００によって提供されたサービスと関連した後処理サーバ１５０を含んでおり、この後処理サーバ１５０は、携帯電話１１０によって伝送される予め選択された情報（例えば、専門的情報）を、インターネット１４０越しに受取るように意図されている。後処理サーバ１５０は、受取った情報をより望ましい形式に変換し、次のその結果をインターネット１４０越しにユーザのメールサーバ１６０に伝送する。その代わりに、或いは前記結果をメールサーバ１６０に伝送することと組み合わせて、当該結果がファクシミリを経由してユーザに送信され、若しくは図示したシステム１００と関連したコンピュータに保存される。例えば、ユーザの保有するコンピュータ（携帯電話１１０と同じものであってもよい）１７０は、当技術分野で周知のように、予め選択された情報（専門的情報）にアクセスできる。当技術分野で周知となるサーバや他の技術は、特定の実施形態に限定されるものではなく、様々な公知の、そして後で開発される実施例を含んでもよい。例えばサーバは、当業者によって理解される区分されまたは他に適切なアーキテクチャを有していてもよい。
【０００８】
図２は、本実施例におけるシステム１００が、予め選択された情報を捕捉して、その後で当該情報を処理することに関し、どのように動作するのかという一つの見地を示すフローチャートである。以下により詳しく記述するように、ここでは単なる説明としての目的で、前記予め選択された情報が専門的情報であるとして説明される。但し、予め選択された情報が以下に記述する専門的情報に限定される訳ではなく、代わりにここで記述される手法により、ユーザが捕捉および処理しようと望むあらゆる種類の情報とすることができる。
【０００９】
ステップ２００では、携帯電話１１０のカメラ１２０を用いて、ディジタル画像の形態で専門的情報が取得される。当該専門的情報が、ある種類のテキストまたは画像や、別なある種類の関連マーク（indicia）の形態である場合、対象物にカメラ１２０をフォーカシングし、その後で携帯電話１１０のボタンまたは同様のものを押動して、その情報の捕捉を開始することで、当該情報を取得できる。ステップ２１０では、前記取得した専門的情報が好ましくは適切に前処理され、そして好ましくは圧縮される。ステップ２２０では、かなり多数の様々な通信ツールを用いて、前記取得した専門的情報が後処理サーバ１５０（図１参照）に送出される。例えば、通信プロトコルと従来の技術を用いて、この取得した専門的情報を、電子メールの添付ファイルとして、後処理サーバ１５０に送出できる。ステップ２３０で示されるように、後処理サーバ１５０は、受取った専門的情報を、こうした情報と整合する望ましい形式に変換する。その後ステップ２４０では、かなり多数の様々な通信技術を介して、処理済の情報がユーザに送出されるが、これは電子メールを経由して処理済の情報を送出することを含んでおり、若しくはファクシミリのようにユーザに処理済の情報を配信したり、内部で処理済の情報を保存したりすることもできる。正しくフォーマットされた専門的情報は、次いで上述したような個人の電子メールアカウントまたは別なもので、ユーザに利用可能となる。
【００１０】
好ましくは、携帯電話１１０のユーザインターフェース（例えば、図１のキーパッド若しくは同様のもの１１２）は、専門的情報の取得を可能にする選択体または手段を備えている。これは携帯電話１１０のユーザインターフェース上で、インターフェース１１２若しくは同様のものの一部として、ボタンの形態とすることができる。当該手段１１２が選択されると、ユーザは図３Ａに示すメニュー２６０が与えられる。やがて理解されるように、メニュー２６０は手持ちデバイス（携帯電話１１０）と関係する表示部に表示される。このメニュー２６０はスクロール可能なメニューで、様々な種類の予め選択された情報を示しており、ここではユーザが取得可能なビジネス情報が示されている。説明のために、メニュー２６０は後続の入力すなわちカテゴリーを含んでおり、その全てはユーザにより取得および処理可能な様々なビジネス情報となっている。メニュー２６０は、（ａ）名刺２６２，（ｂ）レシート２６４，（ｃ）テキスト文書２６６，（ｄ）例えば手書きの文書や絵などのメモ２６８，（ｅ）ユーザ自身の手書きメモ２７０，（ｆ）ホワイトボード２７２，（ｇ）フォーム（書式）２７４，および（ｈ）特定されないあらゆる画像のための入力を含んでいる。このメニュー２６０は、上述した情報の部分集合（subset）を含んでもよく、或いは別な情報を認識してもよい。したがって上記入力は、実際には単なる例に過ぎない。またデフォルト設定が、オペレーティングソフトウェアに予め選択され、組み込まれてもよい。勿論、ユーザによってデフォルト設定を変更することができる。ユーザによって選択された専門的情報の種類に基づいて、専門的情報のより効果的な取得と前処理のための調整を、携帯電話１１０が実行する。すなわち、仮にユーザがメニュー２６０の名刺２６２を選択すると、携帯電話１１０のプロセッサは、捕捉した画像が高品質になる調整を行なわせるために、特別な画像コマンド若しくは同様のものを、カメラ１２０に提供できる。その結果、名刺２６２の画像を取得した時のカメラ１２０の最適な条件は、手書きの全てについて判読が可能で、より正確に処理できるようにするために、ユーザ自身の手書きメモ２７０の画像を取得するための最適な条件（細かな詳細を取得するのに、さらに高度な解像度を必要とするかもしれない）と、異なる場合があり得る。
【００１１】
好ましくは図３Ｂに示すように、ユーザは追加のサブメニュー３００が提供され、これにより、ユーザによって選択および取得された上述の専門的情報をどこに送り、またどのように保存するのかを指示する選択肢（オプション）を、ユーザが保有する。例えば、前記メニュー入力２６２〜２７６のそれぞれは、サブメニュー３００を含むことができるが、このサブメニュー３００は、各メニュー入力２６２〜２７６に対し同一若しくは異なっている。サブメニュー３００は、選択された情報を強調表示し、その後でボタンをクリック若しくはマウスタイプのツールを利用して、サブメニュー３００をナビゲートするような標準のメニュープロトコルを用いて、アクセスすることができる。図３Ｂに示す例では、サブメニュー３００が電子メール配信オプション（アイコンまたは入力３０２），ファクシミリ配信オプション（アイコンまたは入力３０４），および保存箇所オプション（アイコンまたは入力３０４）この場合も、サブメニュー３００の一部として、デフォルト設定を予め選択してよい。例えばデフォルトは、選択され取得された専門的情報が、添付ファイルとして電子メールに配信される、とすることができる。
【００１２】
一実施例では、図４の処理フローチャートに示すように、前記専門的情報を後処理サーバ１５０（図１参照）で完全に処理することができる。ステップ３１０において、ユーザは所得する専門的情報（予め選択した情報）のオプションを選択し、ステップ３２０において、ユーザは例えば図３ａのメニュー２６０を利用して、取得および処理されるべき専門的情報の種類を選択する。選択された文書の種類（例えば、名刺２６２）と、サブメニュー３００で選択されるような、その文書の送り先とに基づき、システム１００はそれに対応する取得フラグ（ＣＦ）を生成して保存する。続いてステップ３３０に記載のように、より適切な取得状態を得るために、カメラ１２０の設定が、前記ＣＦの値に基づき調整される。
【００１３】
特に名刺や、レシートや、文書や、フォームや、メモのために、前記取得の動作が次のように進行する。カメラ１２０の露光時間が、通常の写真の露光時間よりも短い期間に設定されると共に、カメラ１２０のフラッシュは消灯される。好ましくは、当該露光時間は、焦点距離のおおよそ半分となる。３５ｍｍレンズのカメラ１２０であれば、露光時間は１／７０秒以下となる。但し、この露光時間は、画像ノイズによっても拘束される。例えば許容可能なノイズレベルで、カメラのＩＳＯを４００に設定すると、１／１００秒の露光時間を用いるのが好ましい。こうした設定は、通常のカメラでの設定よりもノイズを多く生成する可能性があるが、後処理がある程度のノイズ除去を提供し、またＯＣＲは、初期のＣＣＤノイズである当該ノイズに対し、さほど高い感度ではない。
【００１４】
ホワイトボードでは、露光設定が変更なくそのままにされ、フラッシュが点灯する。ホワイトボードが連続する写真やディジタル画像と共に、任意に捕捉されることにも注目すべきである。したがって、取得フラグ（ＣＦ）が選択したホワイトボードを特定するならば、ユーザが文書捕捉モードと画像の取得を終了する「脱出（escape）」若しくは同様のコマンドを入力するまで、当該ユーザは文書捕捉モードにて画像の撮影／捕捉を継続する。さらに携帯電話１１０のユーザインターフェースは、ホワイトボードの各写真が撮影されるべきオーダ（指令）を特定する選択肢（例えば、左から右，上から下など）を備えることができる。
【００１５】
前記文書画像は、その後ステップ３４０で取得（撮影）され、ステップ３５０に示すように、現時点で取得した携帯電話の画像／写真として、ユーザは視認可能な画像が提供される。言い換えると、携帯電話１１０の一部をなす画面に、取得した画像が表示され、そこでユーザが画像の結果に満足しなければ、ユーザはステップ３４０での取得画像へ簡単に戻ることができる。これは、取得した画像の品質に満足し、処理を続けたいと思うか否かを、ユーザに尋ねるソフトウェアの一部として、連続するポップアップのウィンドウ，メニュー若しくはそれと同様のものを単に組み込むことで実行可能である。例えば、「はい（yes）」と「いいえ（No）」の各ボックスを有するウィンドウを表示することで、ユーザは画像取得の処理を繰り返すか、或いは次のステップを続けるかを示すこれらのボックスを切替え、またはその一つを強調表示することができる。
【００１６】
取得画像の品質にユーザが満足すると、その後３５０で示される次のステップにおいて、携帯電話１１０で生成された通常の電子メールテキストをさらに含めることができる電子メールメッセージのように、取得した画像が適切なフォームで後処理サーバ１５０（図１参照）に送出される。この電子メールメッセージには、前記文書の種類を特定する取得フラグ（ＣＦ）と、文書の配置がさらに含まれる。さらに、後処理サーバ１５０から他のインターフェース（例えば、ファクシミリ機器など）に、前記画像を送ることもできる。
【００１７】
ここでは、現システム１００の様々なコンポーネントへのアクセスを有しない携帯電話１１０を有する一ユーザが、代わりにシステム１００へのアクセスを有するユーザの携帯電話１１０に向けて、無線接続越しに前記取得した画像を送出でき、それによりサービスが提供されることにも注目すべきである。その後、ここに明記されるように、カメラ１２０で画像を取得するステップ３４０が省略されることを除いて、当該画像は処理される。こうした利用の本質において、画像の取得は異なる用途毎に予め行なわれており、また、無線インターフェースを通じての移動携帯用デバイス（携帯電話１１０）で取得した画像を受取ることにより、現ユーザは単にその取得した画像が与えられる。
【００１８】
図５で説明する別な実施例において、携帯電話のソフトウェアは、文書種類に基づくカメラ設定調整と、画像の前処理と、画像の圧縮とを提供する。この別な実施例では、初期の各ステップ、すなわち図４におけるステップ３１０，ステップ３２０，ステップ３３０が、この図４を参照して記述した前記実施例と同じものとなっている。
【００１９】
カメラの設定が完了した後で、幾つかまたはより多くの（例えば３つ）文書や画像化対象物の画像／写真が撮影される。その後、取得した画像の結果が、図５に示すようなフラグＣＦに基づいて前処理される。とりわけステップ４００やステップ４１０では、名刺，ビジネスフォーム，メモ，および／またはレシートの画像が、次の各手順を利用して前処理される。最初に、取得した３つの画像のそれぞれについて、文書の確認とタグ付けが行なわれる。公知の技術を用いて、周囲フィールドが取り去られ、セグメンテーションの手順（背景，前景）が実行される。続いて、当技術分野で知られている画像技術を用いて、最小限のモーションブラーを施した画像が選択される。この選択した画像において、フレーム境界とほぼ平行に画像が向かうように、当技術分野で知られているデスキュー（deskew：反歪曲）動作が実行される。次いで、公知の技術を利用し、樽形歪曲を除去することで、前記画像が補正される。特に、デスキュー動作はホワイトボードに対して行なわれるが、樽形歪曲の除去は必要としない。最後に、あらゆる利用可能な種類の画像からノイズが除去される。このノイズレベルは記録され、ユーザが画像の品質に満足しなければ、それに応じて画像取得の設定が調整される。画像前処理と関連して引用される画像処理の各手順は、例えばウィリアム  ケー  プラット（William K Pratt）氏による「ディジタルイメージプロセッシング（Digital Image Processing）」第３版を参照して、当技術分野で知られているが、ここではその全てを引用して組み込まれているので、これらの手順をより詳細には記述しない。
【００２０】
選択された取得画像は、ここで前処理がなされ、通常はステップ４２０とステップ４３０で示すように、圧縮ソフトウェアに制御が移行する。圧縮の間、名刺，レシート，一般のテキスト文書，またはビジネスフォームの取得画像が、最初に単なるグレースケールのデータに変換される。すなわち、全ての色情報は周知の技術を利用して無視されることになる。その後、前記取得した画像は、印刷済テキストに公的な圧縮アルゴリズム（例えば、データ圧縮会議議事録  ＩＥＥＥコンピュータ学会プレス  ５５３頁「無損失なＪＢＩＧ２コーディングパフォーマンス（Lossless JBIG2 Coding Performance）」を参照）を利用して圧縮されるが、ここではその全てを引用して組み込まれている。
【００２１】
メモ画像のための圧縮ステップ４２０とステップ４３０は、その圧縮アルゴリズムが、手書きテキスト（例えば、キャラクテル社（Charactell Ltd.）によって開発された商業的に入手可能なソフトウェアを参照）に対して最適にされることを除いては、上述した各ステップと類似している。ユーザの手書きメモ用の圧縮プログラムは、当技術分野で知られているような、特定のユーザに向けたものとすることができる。ホワイトボードと一般の画像は、通常のＪＰＥＧアルゴリズムで圧縮することができる。最後に、様々な従来のインターフェースを経由して、取得フラグ値を有する圧縮画像が後処理サーバ１５０に送出される。
【００２２】
さらに別な実施例において、前記システムは様々な機能を有する携帯電話１１０を含んでもよく、それにより携帯電話１１０の中には、取得した画像を正しく前処理および／または圧縮するのに必要な幾つか若しくは全てのステップについて、これを実行できないものもある。こうした場合、ユーザ自身の携帯電話１１０のハードウェアおよび／またはソフトウェアのバージョンを確認するために、取得フラグ（ＣＦ）は追加のフィールドを備えることができる。結果的に、（もしあれば）電話１１０で行なわれる前処理および圧縮について、サーバが情報を受取るので、特別な入力の携帯電話１１０に対して、前処理を調整することができる。
【００２３】
システム１００の後処理サーバ部１５０が、図６において図式的に説明される。これは、当従来技術で知られている一般的なサーバ技術を利用して、一乃至複数のシステムとして実行可能である。図６において円で示されるソフトウェアモジュールは、オペレーティングシステムと、サーバに選択される特別なアーキテクチャに依存して、公知の技術を利用して実行することができる。モジュールは処理の過程で個別のステップを実行し、また個々のシステムとして分離できることから、そのようなものとして各ソフトウェアモジュールは「サーバ」として引用され、図６にて表わされている。サーバとして引用される各ソフトウェアモジュールは、一つの処理若しくは各処理の集合であってもよく、これは与えられたコンピュータのオペレーティングシステムにおけるプロセス間通信機構を利用して伝達される。選択されたアーキテクチャに基づき、後処理サーバのソフトウェアが、ネットワーク越しに通信を行なう幾つかの物理的コンピュータに存在してもよい。当業者により理解されるような様々な手法で、後処理サーバ１５０におけるソフトウェア−ハードウェアのアーキテクチャを実装してもよい。
【００２４】
上述のように、携帯電話１１０からのメッセージは、好ましくはセルラーインターネット１３０およびインターネットネットワーク１４０越しに、サーバシステムに提供される。（また、ファックスプロトコルや他の知られた技術を利用して配信してもよい。）例えば、前記メッセージをサービスプロバイダの電子メールアドレスに送出することができる。このメッセージは、ユーザによって挿入されたテキストメッセージと、上述したような電話で処理および圧縮された文書の画像と、文書の種類を特定するフラグＣＦと、好ましくは電話の性能およびユーザへの情報配信モードとにより構成される。さらにメッセージは、電子メールメッセージに通例として含まれるあらゆる他の情報と同じく、ユーザを識別する情報（例えば、ユーザ電話のインターネット識別子や、別なユーザの独自な識別子）や、公開されたサービスに対し有用であると思われる別な情報（例えば、通信サービスプロバイダの識別子）を含むのが好ましい。
【００２５】
送出されたメッセージは、ＳＭＴＰサーバ５００で受取られる。このＳＭＴＰサーバ５００は、一般的には従来の電子メールサーバであり、インターネット１４０を経由して受信したメッセージの受取りと、蓄積保存と、検索と、送出を行なう。ソフトウェアモジュール（メールサーバ）５１０は、新たな電子メールの到着を待つＳＭＴＰサーバ５００をポーリングするものである。このポーリングは、当業者により理解されるように、システムのトラフィックとその処理能力に基づき、選択された予め決められた時間間隔で行なうことができる。例えば５分毎に、ポーリングを行なってもよい。前記時間間隔はトラフィック統計に基づいて調整することもでき、または動的に調整することができる。ソフトウェアモジュール／ソフトウェア５１０は、ポーリングの期間中に受取った新たな電子メール（メッセージ）を確認して、これをダウンロードする。当該ソフトウェア５１０は、画像の添付を有するこうしたメッセージを保存するのに、慣習として構築されたデータベースを維持する。
【００２６】
加えて、メールサーバ５１０は、受信した電子メールと、その中に提供されるユーザ情報とを認証する。関連する情報が、電子メールから抽出される。この関連情報は、同封の画像，フラグＣＦ，および例えば電子メールアドレスや、電話番号や、別な慣例的な識別子などのユーザ識別子（ＩＤ）を含む。仮に、必要な情報の何れかが失われている場合には、そうした電子メールが破棄され、可能であればエラーを示すメッセージが送り手に戻される。ある実施例では、エラーメッセージに応答して、電子メールが電話で自動的に再送される。
【００２７】
次に、受取ったユーザ識別子が認証される。システム１００のユーザは、好ましくはシステム１００のプロバイダとアカウントを維持しており、後処理サーバ１５０は、慣例的なオンラインサービスと連携して、アカウント情報を保存する。こうしたアカウント情報は、ユーザの嗜好と同様に、例えばユーザ自身の連絡情報および支払い情報を含んでもよい。
【００２８】
ユーザがシステム１００の正当なユーザとして証明され、信用のある状態であれば、ここに記述したような処理が継続する。さもなければ、正当ではないユーザを示すメッセージが戻され、受取った情報が削除されると共に、こうした正当ではないユーザと連絡する処理が終了する。
【００２９】
正当なユーザと正しく認証されたメッセージに対して、システム１００と関連するサービスの共有データベースに入力が行なわれる。この入力は、現在の日付および時間によってインデックス付けがなされ、メッセージのテキスト，フラグＣＦ，画像，ユーザに関する情報，および更なる処理に有用な、電子メールと共に供給されるあらゆる他の情報を含んでいる。その後メッセージは、その共有データベースへの入力と共にソフトウェア５２０に確認される。ソフトウェア５２０は、受取った情報の処理を調整するもので、キューイングサーバ５２０として引用される。キューイングサーバ５２０は、適切なシーケンス内において、正確なソフトウェアモジュールを呼び出すための処理およびスケジューリングソフトウェアの下で、それぞれのサブミッションを確認するキューイングデータベースを含んでいる。キューイングサーバ５２０のようなソフトウェアは、例えば１９９７年１月にプレンティスホールプレス（Prentice Hall Press）で発表された、アムジャッド  ウマル（Amjad Umar）氏による「オブジェクト指向のクライアント／サーバインターネット環境（Object-Oriented Client/Server Internet Environments）」を参照することで技術的に知られており、ここではその全てを引用して組み込まれている。
【００３０】
前記システムにおける他のソフトウェアモジュールは、ソフトウェア５２０にて対応するキューをポーリングし、対応する処理のステップに備えて、メッセージを検索してもよい。これは技術的に知られているように、順序付けられた処理のスケジューリングを実行し、必要な動作の正確なシーケンスを追跡する。仮に他のソフトウェアモジュールが、動作の一つから生じたエラー指示を受取ると、通常は定められたメッセージの処理を終了し、ユーザとシステム管理者にエラーの識別を戻し、破棄された情報に対する通常のクリーンアップシーケンスを含めて、所定のメッセージの処理シーケンスを終了する。
【００３１】
スケジューリングシーケンスが所定のメッセージに到達すると、ソフトウェア５２０は、処理シーケンスまたは所定のメッセージが次であるソフトウェアに処理されるべき次のメッセージデータベース入力の情報を提供する。ソフトウェアモジュールがその動作を完了した後、当該ソフトウェアモジュールは、所定のメッセージ用に作成したデータベース入力で処理された情報を保存し、所定の処理ステップが成功完了したキューイングサーバ５２０に信号を伝える。（上述したように、成功せずに完了した場合には、処理が終了する。）動作が成功して完了した後、メッセージの識別子は次の動作が利用できるのを待って、キューに入れられる。次のソフトウェアモジュールが利用できるようになると、キューイングサーバ５２０は、前段の処理結果における位置の識別を含めて、処理されるべきメッセージの識別を行なう。以下、一つの処理に対する処理シーケンスを記述するが、上述のように多数のメッセージがスケジュールされることに注目すべきである。さらに、そうでない場合に示す以外は、各ステップに対して、情報出力が主として保存され、その後にキューイングサーバ５２０によって次のステップに対しスケジュールされたソフトウェアモジュールが、情報出力を検索する。
【００３２】
最初にキューイングサーバ５２０は、復元サーバ５３０として引用されるソフトウェアモジュール５３０が利用できるメッセージ情報を作成する。上述したように、携帯電話１１０によって提供された画像は、伝送帯域幅を節約するのに圧縮されている。こうした通常の圧縮技術における識別は、前記ＣＦ値に基づいて行なわれる。復元サーバ５３０は、そこで対応する復元動作を実行し、結果を保存して、キューイングサーバ５２０に所定のメッセージの復元が成功した旨を信号で送り出すか、逆にエラーが発生した旨を信号で送り出す。本実施例において、携帯電話１１０で圧縮を行なわない場合は、この動作が省略される。
【００３３】
また当該ステップは、圧縮性能を有しない携帯電話１１０で画像が取得されたことをＣＦ値が示していたり、或いは携帯電話１１０で圧縮を必要としないビジネス情報を、画像が含んでいたりした場合にも、省略される。
【００３４】
その後、メッセージ識別子は、キューイングサーバ５２０からフィルタサーバのソフトウェアモジュール５４０に提供される。但し例外が一般画像であり、これは更なる処理を必要とせず、そのため配信サーバのソフトウェアモジュール５５０に提供される。実施例の中には、画像を圧縮し送り出す前に処理することが、電話動作に関係して記述されている（図５およびそれに伴う記述を参照）。幾つかの実施例では、電話ソフトウェアのアーキテクチャを簡素化するために、そうした処理若しくは割り当てをフィルタサーバ５４０が実行する。加えて画像は、既に電話で前処理されたものでさえも、様々な技術を用いてさらに画質が向上し、それにより幾つかの異なるフィルタ化画像（幾つかのオリジナル画像のバージョン）が取得される。フィルタサーバ５４０における画像の画質向上処理ステップは、取得フラグＣＦの値に依存するが、この取得フラグＣＦは、電話で行なわれた処理のレベルと、好ましい後処理のアルゴリズムを符号化する。
【００３５】
例えば、前処理機能を有しない携帯電話１１０で所得した名刺，レシート，一般文書，および手書きメモは、次の各ステップで処理することができる。
１．取得した画像を８ビットのグレースケール画像に変換する。
２．技術的に知られている大津（Otsu）法のようなセグメンテーションアルゴリズムを適用して、画像の暗い背景から明るい領域を分離する。
３．多数の収縮−膨張フィルタを適用して、ペッパーノイズ（pepper noise）を除去し、文書の外縁を滑らかにする。
４．黒の境界領域（border area）を探し出し、ボードマスキング（board masking）画像を形成する。
５．前記画像をマスキングして、本質的に関連性のあるものだけからなる画像を取得する。
【００３６】
前処理機能を有する携帯電話１１０で所得した名刺，レシート，一般文書，および手書きメモは、次の各ステップで処理することができる。
１．暗さと明るさの階調度（gradient）を補正する。
２．背景と前景のセグメンテーションを行なう。
３．背景のノイズ除去を行なう。
【００３７】
電話が前処理機能を有するか否かに拘らず、ホワイトボードの画像に対して、次の各ステップで処理を行なうことができる。
１．暗さと明るさの階調度（gradient）を補正する。
２．背景と前景のセグメンテーションを行なう。
３．背景のコントラストを検出する。
４．平均的な背景レベルの近傍で、信号を滑らかにする。
５．白背景の近傍にある各ピクセル（画素）の飽和を抑制する。
【００３８】
上述した個々のステップは技術的に知られており、上記引用したウィリアム  ケー  プラット（William K Pratt）氏の参考文献が参照され、ここではその全てを引用して組み込まれている。
【００３９】
フィルタリングは、各画像で何回も行なわれ、それにより動作が完了すると、オリジナルで受信した画像のみならず、何回かフィルタ処理された画像も出力となる。この情報は中心に保存され、キューイングサーバ５２０に制御が戻る。
【００４０】
次に、一般画像やホワイトボードを除き、各画像は認識サーバ５６０として引用されるソフトウェアモジュール５６０で処理される。一般画像やホワイトボードは、更なる処理を必要としないので、配信サーバのソフトウェア５５０に供給される。さらに、ユーザがファックスでの配信を指定した場合、更なる処理は必要としないので、全文書に対して配信サーバのソフトウェア５５０にその制御が転送される。さらにファックス配信の場合には、ある文書に対して一つの結果画像だけを、次のステージに保持すべきである。
【００４１】
他のソフトウェアモジュラと同様に、ソフトウェアモジュール５６０は、周期的にキューイングサーバ５２０をポーリングすると共に、新しいデータを監視する。それぞれの新規メッセージに対して、ソフトウェアモジュール５６０はＣＦフラグと一致する動作を実行する。前述のフィルタリングのステップで生成された多数の画像のそれぞれに対して、フィルタ処理されたデータをコピーし、ＯＣＲ若しくはＩＣＲの何れかを行なう。名刺，レシート，およびテキスト文書のような、印刷済のテキスト画像に対する動作はＯＣＲであり、これは周知のＯＣＲ技術を用いて行なわれる。手書き画像に対する動作はＩＣＲであり、これも技術的に知られている。フォームに対しては、これらの技術を組み合わせたものを用いてもよい。特に手書き認識に対しては、ユーザ固有のデータが、好ましくはユーザアカウントと関連付けてシステムに保存されるべきである。本サービスでの当該情報を維持するユーザに対して、ユーザ固有のデータが検索され、ソフトウェア（認識サーバ）５６０に提供される。
【００４２】
種々の文書の種類に対して、認識サーバ５６０での処理が終了する。実施例の中には、一般テキスト文書や、手書き文書や、フォームに対して、更なる処理を必要としないものもある。こうした文書に対し、システム１００は、ＯＣＲまたはＩＣＲ結果の品質を指示する測定基準を分析し、最も高品質で、その後に共有データベースに保存される複製結果の一つを除き、全ての複製結果を破棄する。名刺およびレシートに対しては、多数のＯＣＲ出力が後続の処理のためになおも保持される。その後、このメッセージのために制御がキューイングサーバ５２０に戻る。キューイングサーバ５２０はＣＦフラグをチェックして、所定の文書種類が追加の処理を必要とするか否かを決定する。この文書のクラシフィケーション（分類）に基づいて、配信サーバソフトウェアモジュール５５０若しくは分類サーバソフトウェア５７０の何れかに、制御が引き継がれる。
【００４３】
例えば、名刺，フォームおよびレシートに対して、分類サーバは受取ったメッセージに対するシステム動作における次のステップとなる。分類サーバ５７０は、例えば名刺について、人名や会社名，電話番号および電子メールアドレスを分離したり、レシートの施設名や支払額を分離したりすることで、印刷された情報を解釈するために、認識サーバ５６０の結果を分析する。この解釈は、全ての複製バージョンに対し行なわれる。解釈された情報の結果は、この解釈処理の品質を指示する測定基準と同様に、解釈されたデータの意味に対応するフィールドに整理される。その後、最も高い品質結果を有するレコードだけが保持され、供給データベースに保存される。
【００４４】
分類サーバ５７０の処理フローは、図７に示す情報ルートである。この情報ルートは複数の段階すなわちステップからなり、各ステップはそれ自体で入力および出力を有する。図７で説明されるような処理フローは、自然言語認識および文法における技術で知られた各ステップからなり、これはベンジャミン−カミングス出版株式会社（Benjamin-Cummings Publishing Co., Inc.）が１９９５年に刊行したジェームス  アレン（James Allen）氏による「自然言語の理解（Natural Language Understanding）」や、アディソン−ウェズレイ  ロングマン社（Addison-Wesley Longman, Inc）が１９８５年に刊行したアルフレッド  ヴィー．アホー（Alfred V.Aho）氏，ラヴィ  セスィー（Ravi Sethi）氏，ジェフリー  ディー．ウルマン（Jeffery D.Ullman）氏による「コンパイラ（Compilers）」が参照され、ここではそれらの両方を引用して組み込まれている。
【００４５】
より特別には、名刺に対して、情報ルートの各段階が次のように論じられる。ステップ６００はトークン化（tokenization）のステップである。この段階すなわちステップ６００は、ＯＣＲキャラクタを入力として取得し、トークン化したセット（集合）を出力として生成する。トークン（token）とは、単一の構成要素（entity）として操作され得るキャラクタのセットである。トークン化は、ＯＣＲエンジンにより決定された全ての正当なキャラクタ代替物を利用して、トークンの可能な結合を全て示している。
【００４６】
ステップ６１０は初期分類ステップである。この段階すなわちステップ６１０では、分類の情報ルートが、トークン化したセットを入力として取得し、トークン化したタグ付きのセットを出力として生成する。このタグは、名前プレフィックス（name prefix）や、市や、州や、ウェブアドレスの一部のように、可能性のあるトークンの解釈である。トークンが表わせるものを決定するのに、様々な経験則をトークンに付与することができる。この段階での各トークンは、複数のタグを有していてもよい。例えば、辞書検索，郵便番号および電話番号の識別，特定の識別子の位置検索および他の関係するフィルタリングにより、タグを割り当ててもよい。
【００４７】
ステップ６２０は、構文解析のステップである。この段階すなわちステップ６２０では、前記初期分類ステップで、それぞれのトークンが潜在的に複数のタグを有しそうな箇所で生成されるトークン化されたものを取得し、それぞれのトークンが単一のタグだけを有する箇所で出力を生成する。トークンに構造的な文法規則を与えると共に、意味をなすストリームを探し出すことで、前記タグが除去される。
【００４８】
ステップ６３０は、「最良の適合（best fit）」を選び出すステップである。当該段階は、各構造分析の出力を取得して、「最良」の一つを抽出する。この段階すなわちステップ６３０では、前の段階で与えられ、構文的に解析されたトークンが、望ましい項目に変換される（例えば、名前，住所，会社，仕事のタイトル，仕事用電話，携帯電話など）。
【００４９】
ステップ６４０は、データ無効とコンテンツ生成である。この段階では、出力がさらに検証され、エラーの幾つかは、公知のデータスクラビング（無効）技術を用いて修正することができる。例えば、文字の場合は調整でき、エラーの文字列は削除でき、名前および住所は標準化でき、スペルエラーは修正できる。スクラビングの後に、ユーザの好みに応じてテンプレートが用いられ、望ましい形式で出力を生成する。
【００５０】
前記分類サーバ５７０は、ＯＣＲ認識キャラクタを入力として、入力画像のそれぞれに対するキャラクタのセットを受取る。その動作は、名刺の処理と関係して、個々で記述される。同様の技術は、例えばレシートのような、他の構文的な構造の文書に対しても利用できる。名刺に対しては、分類サーバ５７０の出力がコンタクトレコードとなる。従って、ここでの処理の目標は、人や会社の名前や、住所や、電話や、電子メールおよび同様のもののような、名刺に通例存在するデータを認識することにある。
【００５１】
一般に分類サーバ５７０は、人工知能と文法の処理の分野で知られている技術を用いて、ＯＣＲスキャンにより生成されたテキストをできる限り正確に解釈する。
【００５２】
しかし、名刺は高度に構造化されたテキスト文書の分類例を表わしており、このテキスト文書に対して、前記解釈の正確さがかなり改善することも有り得る。この分類の構造部について、２つの特徴的な特性がある。（１）分類の構成部毎に通常は存在する予め定義された言語構造のセットがある。（２）これらの構造のなかには、当該分類の構造部毎に一回だけ存在するものがある（その一方で、別な構造が一回を越えて出現したり、さらに別な構造が出現し、または出現しない場合もある）。以下に記述される分類アルゴリズムは、上述した特性を大いに利用する。
【００５３】
以下、分類情報ルートにおける各段階をより詳しく説明する。しかし最初は、文書の内容（コンテンツ）を定義する要素と、その構造を分析するのに用いる手段が導入される。
【００５４】
意味のある文書の基本部分はトークンである。トークンは、単一の入力として操作され得るキャラクタのセットである。トークンは、零乃至一以上のタグ（すなわち、識別子）を、トークンに割り当てた状態にすることができる。タグは、これを付加し、除去し、そして問い合わせることが可能である。タグは、所定の処理ステップで認識されるトークンの意味を識別する。トークンは、英字，英数字，数字の何れでもよく、デリミタ（区切り文字）を含んでもよい。デリミタは、タグを決定する特別な意味を有するものでもよい。
【００５５】
（例えば、名刺上での）文書に現れるトークン（すなわち、テキストの構成要素）の各群を評価するのに、文法が用いられる。文法は、名前，唯一の識別子（すなわちタグ），重み信頼度（スコア）修飾子，および構文のような、幾つかの異なる構成要素から作り出される。ここでの構文は、一連のトークンを評価するのに用いる規則を、テキストで表わしたものである。構文を作り上げる各要素は、リテラル（定数），トークン，およびグループ（groups）を含む。
【００５６】
リテラルは、単一の引用符内に囲まれたテキストで表わされる固定した文字列である。リテラル要素の例としては、‘＠’，‘www’を含む。
【００５７】
トークンは、名詞に存在する可能性のある情報の種類を用いて分類される。例えば、市，会社，電子メール，および電話番号に対して、以下のものが提供される。
市（CITY）：  市の名前
会社（COMPANY）：  会社名
会社の種類（COMPANY_CLASS）：  ”Inc.”，”Corp”，”LLC”のような会社の修飾子
電子メール（EMAIL）：  電子メールのアドレス部分
電子メール標識（EMAIL_MARKER）：  ”email”のような電子メール欄の識別子
電話（PHONE_GROUP_11）：  １１桁の電話番号
電話タイプ  代替（PHONE_TYPE_ALT）：  ”ALT”のような代替の電話番号識別子
電話タイプ  ＦＡＸ（PHONE_TYPE_FAX）：  ”FAX”のようなファックス番号識別子
電話タイプ  メイン（PHONE_TYPE_MAIN）：  ”phone”，”main”，”direct”のような主要な番号の識別子
電話タイプ  モバイル（PHONE_TYPE_MOBILE）：”mobile”，”cell”のような携帯電話の識別子
電話タイプ  ページャ（PHONE_TYPE_PAGER）：”pager”のようなページャ番号の識別子
これらに加えて、２つの特別な場合のトークンがある。その一つは、トークンを分離するデリミタである。もう一つは”NewLine”であり、これは名刺上のテキストの復帰改行を示すトークンを識別するものである。
【００５８】
グループは、連続する要素を表わす一乃至複数の要素からなる。グループ内の各要素は順番に評価され、この評価されたデータ内のトークンと連続的にマッチ（一致）させなければならない。
【００５９】
文法は、終端と非終端との組合せを用いて表現される規則を伴って、標準的な文法の表記法を利用して定義することができる。このような表現は、文法処理の技術において標準化される。
【００６０】
例えば、あるタイプを定義の開始で宣言することができ、後にコロンが続き、さらにグループ文法（group grammar）の構成部分が続いている。このタイプは、グループ名を表わし、後にコロン（‘：’）が続く単一のワードであり、そこでグループが割り当てられる。次のものは、標準の表記法を用いたタイプで宣言されたグループ定義の３つの例を示している。
（CITY：CITY）
（COMPANY：COMPANY COMPANY_CLASS）
（PHONE_MAIN：PHONE_TYPE_MAIN PHONE_GROUP_11）
構文の要素は修飾子を有することができ、この修飾子は、前記要素を繰り返すことができる回数を記述している。一要素に付き、一つの修飾子だけが許容される。修飾子は、影響を及ぼす要素の直後に出現する。各修飾子は次のようなものを含む。
【００６１】
｛x,y｝は、要素が現れる可能性のある最小および最大の回数を意味し、ｘは要素が現れる可能性のある最小回数を示す数値であり、ｙは要素が現れる可能性のある最大回数を示す数値である。
【００６２】
｛x｝は、要素が現れる可能性のある特定の回数（これは、機能的に｛x,x｝と等価である。）を意味し、ｘは要素が現れる可能性のある回数を示す数値である。
【００６３】
｛x,｝は、要素が現れる可能性のある最小の回数（これは、機能的に｛x,∞｝と等価である。）を意味し、ｘは要素が現れる可能性のある最小回数を示す数値である。
【００６４】
｛,x｝は、要素が現れる可能性のある最大の回数（これは、機能的に｛0,∞｝と等価である。）を意味し、ｘは要素が現れる可能性のある最大回数を示す数値である。
【００６５】
*−前記要素が、０回以上（これは、機能的に｛0,∞｝および｛0,｝の両方と等価である。）現れる可能性がある。
【００６６】
+−前記要素が、１回以上（これは、機能的に｛1,∞｝および｛1,｝の両方と等価である。）現れる可能性がある。
【００６７】
?−前記要素が、０回または１回（これは、機能的に｛0,1｝と等価である。）現れる可能性がある。
【００６８】
図６で説明した特定の段階における議論に戻ると、分類情報ラインの段階１は、ＯＣＲキャラクタセットの数を入力として取得し、各入力のキャラクタセットに対して１セットのトークン化されたセットを、出力として生成する。トークン化は固有のトークンセットを表わすもので、ＯＣＲエンジンにより決定された全ての正当なキャラクタ代替物を利用して、キャラクタの可能な組合せを全て示している。
【００６９】
商業的に利用可能なＯＣＲにおいて知られているように、ＯＣＲ出力は信頼値を含むと共に、認証ストリームの各「位置」（キャラクタ）に対し順に交代する。この段階で処理されたそれぞれのキャラクタは、次の特性が割り当てられる。（ａ）Value−キャラクタそのもの；（ｂ）CharacterConfidence−正確なキャラクタである信用の度合い；（ｃ）WordConfidence−そのキャラクタが所定のワードである信用の度合い；（ｄ）OcrCharacter−当該キャラクタに対するＯＣＲ出力；（ｄ）CharacterType−キャラクタのタイプ（種類）；（ｄ）Alterenate−当該キャラクタの代替となるキャラクタ
本実施例において、それぞれの認識されたキャラクタは、例えば最大で３つの代替の「推測（guesses）」を有するものと推測される。空白と復帰改行は、個別のキャラクタとしてではなく、リーディング（leading）またはフォローイング（following）キャラクタの特性として符号化される。「最良」の推測は、常に連続する代替体の最初に提示される。
【００７０】
したがって、トークン化を構築する処理は、それぞれのキャラクタを考慮し、連続する各デリミタ間のキャラクタを結合してトークンを生成することによって行なわれる。デリミタは、”！”および”＃”（これらは、頻繁に英数字のＯＣＲ代替体を有する）のみを除外した非英数字のキャラクタである。代替のキャラクタが存在する箇所で、それらのキャラクタが代替のトークンを引き起こし、異なるトークン化に含有される。このように、トークンの順序付けられた集合体からなる多数のトークン化が生成され、そうしたトークン化のそれぞれが固有のものとなる。
【００７１】
当業者ならば、文書の処理が、ここに記述されるように、各トークンからなるトークン化として表わされ、別な各実施例で用いられることを理解すべきで、当該処理は、文書をキャラクタまたはシンボルのブロックに細かく分割し、こうしたブロックやセットの持つ意味を確認する一般的なアプローチを用いる。
【００７２】
分類情報ラインの段階２は、トークン化のグループを入力として取得し、トークン化の「タグ付けされた」セットを出力として生成する。このタグは、文法マッチングに関係なく、それぞれのトークンについて可能性のある意味を予測するものである。各トークンは、タグ辞書との一致が存在（COMPANY，COMPANY_CLASS）する全てのタグが割り当てられ、各タグは、意味的にトークンに適用されそうなトークン自体の意味を識別する。最も可能性のある意味的な表現の一つが、後で選択されることになる。各タグは処理プロセスによって割り当てられ、それぞれのタグは、入力および出力としてのトークン化を、割り当てられた関連するタグを有するデータ構造へ搬送する。
【００７３】
分類サブシステムは、辞書を用いてワードでの検索を行なう。こうした辞書は、辞書検索の結果に基づいて、タグを割り当てる処理に用いられる。辞書タイプは、入力文書から抽出されるべき全てのデータタイプの一部である。辞書タイプの例として、次のようなものがある。
【００７４】
【表１】
2008546058.tif 000003
【００７５】
図８に関連して、より具体的にフィルタリングを説明する。辞書フィルタ７０１は、個人や会社の名前のような種々の知られた辞書で、トークンの検索を行なう。仮にマッチしたものが見つかれば、対応するタグがトークンに加えられる。さらに、辞書入力は、それに関連付けられた確率と結び付くスコアを含んでおり、このスコアもトークンに加えられる。この確率は、例えばトークンの一つのキャラクタが、辞書入力と異なる場合のように、辞書マッチが部分的であった場合には減少する。
【００７６】
領域デリミタフィルタ７０２は、改行若しくは空白の大群の何れかを表わすトークンを識別するものである。
【００７７】
電話番号フィルタ７０５は、スペースおよびデリミタを有する１０および１１桁長のシーケンスをタグ付けするものである。当該電話番号フィルタ７０５は、内線番号となり得る英数字のトークンもタグ付けする。
【００７８】
名前フィルタ７０６は、辞書内の名前として識別されたトークンの同一行にある各トークンに、タグを割り当てるものである。前記同一行でさらに離れて配置されるトークンに対しては、確率が減少する。当該フィルタはさらに、潜在的な名前のプリフィックス（prefix：接頭語），サフィックス（suffix：接尾語），および名前の次に共通して見つけ出される別な属性を探し、隣のトークンにタグを割り当てる。
【００７９】
会社フィルタ７０７は、辞書内の会社名として識別されたトークンの同一行にある各トークンに、タグを割り当てるものである。当該フィルタはさらに、会社名の次に共通して見つけ出される潜在的な会社の指示子（例えば、LLC，Inc.，LLP.）を探し、隣のトークンに会社名のタグを割り当てる。
【００８０】
仕事タイトルフィルタ７０８は、タイトルを用いた共通ワードに対する辞書マッチを通して、トークンがジョブタイトルであるかどうかを決定するものである。そして、同一行にある隣のトークンに、ジョブタイトルのタグを割り当てる。所在地アドレスフィルタ７０９は、所在地番号としての数字および英数字トークンをタグ付けするものであり、同一行において先行してアドレスに関連付けられたタグと、潜在的な所在地名として、タグ英字，数字およびデリミタのトークンとを強化するために、見つけ出された所在地サフィックスを利用すると共に、タグの隣に対する「アドレス部分」（例えば、スイートやビルディングなど）を利用する。
【００８１】
電子メールアドレスフィルタ７１０は、文書の終了部分から開始して、電子メールアドレスのサフィックスを探すものである。このフィルタはさらに、それぞれ連続するトークンの値とタイプを用いて、信頼度（スコア）を変更する重み付けを行なう。
【００８２】
ウェブアドレスフィルタ７１１は、文書から開始して、ウェブメールアドレスのサフィックスを探すものである。このフィルタはさらに、それぞれ連続するトークンの値とタイプを用いて、信頼度を変更する重み付けを行なう。
【００８３】
州フィルタ７１２は、あらゆる「部分的フレーズ」の辞書マッチを取除き、文字の状態に基づく州の略称の信頼度レベルを変更するものである。
【００８４】
上述したタグ付け動作の結果として、大部分のトークンは、意味のある一乃至複数のタグに割り当てられる。段階３は、最も高いスコアを有するものが、構造上の意味をなすものでもあるような、文法ルールに従ってタグ選択を順序付けることで、非常に多くのトークン化を減少させることに、その責任がある。したがって、段階３の構文解析エンジンは、それぞれのトークンが潜在的に幾つかのタグを有する可能性のある箇所で、段階２におけるトークン化されたものを入力として受取り、それぞれのトークンが単一のタグだけを有する箇所で多数の出力を生成し、各出力は集計スコアを備えている。
【００８５】
各タグは、本明細書内において先に説明したように、構文上の文法規則を当てはめることにより、構文的に意味をなすストリームを探し出すトークンに選別される。ここでは、それぞれ個々のトークン化されたものが、多数の構文的に有効な出力をもたらし、出力のそれぞれが異なる集計スコアを有することに注目すべきである。
【００８６】
前述のように、統語構造の構文解析は技術的に知られている。一実施例において、本段階は、構文的に有効なトークンのシーケンスを見つけ出すために、解析木の縦型検索を利用した構文解析ツールを採用する。それぞれのタグは、全ての文法マッチが見つけ出されるまで再帰的にチェックされる。文法マッチは、例えばアドレス構造に対する規則のような、予め決められた規則とマッチするトークン化の一部分である。
【００８７】
文法を評価する時、従来のアプローチは、正確なトークンセットのシーケンスを命令（mandate）する予め記述されたパスを有することにあり、当該トークンは、成功したマッチを有するのに、そうした命令（order）で見つけ出されなければならない。知られていないトークンの命令に起因して、あらゆるトークンが、実際にはトークンセットの開始でのものであると仮定すれば、成功したトークンシーケンスを記述する解析木セットを、文法から作り出すのが好ましい。すなわち、特定のトークンセットを取得できる潜在的な経路に基づいて、解析木セットを構築するために、文法が事前に構文解析される。
【００８８】
本アプローチを用いて、構文解析は文書内のどこでも開始することができ、また文法規則の状況を満足するのに、前方および後方の両方における検索を含むことができる。しかし、他の構造解析技術は技術的に知られており、文書を構造解析するのに用いられていることに注目すべきである。
【００８９】
多くの場合、多数の文法が異なる手法で同一のトークンを評価する。文法の重複を解決するために、各文法は初期の信頼度を有すると共に、構文解析結果からの各トークンも信頼度を有する。これらを結合して、マッチングの結果が総信頼度量を有し、この総信頼度量は、正しい結果の確率を表わしている。
【００９０】
分類の段階４は、段階３からのトークン化されたものに対する多数の文法マッチを入力として受取り、正確なタグで最もありそうな正確なラベル付けを行なった状況で、前記トークン化を決定する。
【００９１】
図９〜図１１は、当該段階で行なわれる処理を説明するものである。ここで注目すべきは、処理を行なうべきカードの全トークン化されたものに対して、当該処理が繰り返されるということである。最初のステップ８００では、段階３での構文解析中に取得できる各トークンの信頼レベルと、任意の幾つかの追加情報とに基づいて、トークン化されたものの各文法マッチに対する信頼スコアを、システムが算出する。次にステップ８０１では、当該トークン化のための文法マッチを、他の文法マッチと比較して、重複するマッチを取除く。この処理の間に、信頼スコアの低い重複した文法マッチが破棄される。次に、必要不可欠な全情報が、それに対応する文法マッチを有することを示すために、選択された文法マッチが検証される（ステップ８０３）。例えば名刺においては、電話番号に対する文法マッチが存在しなければならない。必要不可欠な文法マッチが見つからないトークン化されたものは、可能性がある結果セットから破棄され、そうしたトークン化に対する処理が終了する。
【００９２】
それとは別に、ステップ８０３に対する制御を進行し、そこでシステムは、残っている文法マッチと関連付けた信頼レベルに基づいて、前記トークン化に対する総合的な信頼レベルを算出する。次のステップ８０４では、トークン化の信頼度が、予め決められた閾値と比較される。仮に信頼度が十分高ければ、このトークン化に対する処理が終了する。
【００９３】
信頼度のスコア化が完了した後、図１０におけるデータベースの処理に制御が進行し、前記信頼度スコアを変更するために、データベースの検索を行なう。例えば、電子メールアドレスに現れるドメイン名に対して、会社名を比較してもよい。当該会社名とそれに関連するドメイン名との間がマッチ（一致）すれば、スコアは増加することになる。仮に、データベースの検索後に、スコアが十分に改善されていなければ（ステップ８０６を参照）、インターネット検索の助けを伴ってトークン化を処理する。その後で、所定のトークン化に対する当該処理が終了する。
【００９４】
図１０を参照すると、ステップ９００において、システムに保存される内部データベースで、当該システムが特定の文法マッチをチェックする。もしマッチが見つかれば、当該マッチに対するレコードが検索され、ステップ９０３に制御が進行する。そうでない場合は、ステップ９０２に制御が進行し、現システムに関係のない構成要素で管理され、且つインターネット上でアクセス可能な外部データベースに対して、当該文法マッチがチェックされる。もし、そうした外部データベース内にマッチが見つかれば、レコードが検索され、ステップ９０３に制御が進行する。
【００９５】
ステップ９０３では、前記検索したレコードが、同一のトークン化されたものから、一乃至複数のさらなる文法チェックを含むかどうかをチェックし、それにより解釈が恐らく正しいことを指示する。例えば、もしレコードが会社名に基づき検索され、アドレスの文法マッチも、そのレコードに保存された一つにマッチするならば、解釈が正しいと結論を下すことができる。そしてこの場合は、ステップ９０７に制御が進行し、成功一致したマッチに基づいて、総合的なトークン化の信頼度が増加し、その処理が終了する。もし、成功一致したマッチがなければ、ステップ９０５に処理が進み、第２の文法マッチで部分的なマッチを試みる。ステップ９０６では、こうした部分的なマッチによって、第２の文法マッチをデータベースレコードに基づき補正し、総合的なトークン化のレベルを増加させる。
【００９６】
図１１を参照すると、ステップ１０１０ではシステムが文法マッチの一つ、例えば名前を求めてインターネットを検索し、少なくとも一つのページが見つかれば、ステップ１０１１に制御が進行する。このステップでは、同一のトークン化されたものから別な文法マッチでのマッチを目的として、前記一つの発見されたページが検索される。ステップ１０１２では、別な（第２の）文法マッチでの前記マッチ数をシステムが計算し、もしそうしたマッチ数が０よりも大きい１以上であれば（ステップ１０１３）、ステップ１０１４に制御が進行する。このステップでは、情報が正確に解釈されたとの見込みを大多数のマッチが表わしていることから、ステップ１０１２で決定したマッチ数に基づき、トークン化の信頼レベルが増加する。
【００９７】
図１２を参照すると、この時点では、トークン化の全てが処理され、一定の信頼度レベルが割り当てられている。ステップ１１０１では、最高の信頼レベルを有するトークン化されたものをシステムが識別する。もし、当該信頼レベルが予め設定した閾値よりも高ければ（ステップ１１０２）、本段階での処理は終了し、ユーザに情報が抽出される段階５にシステムが進行する。そうでない場合は、制御がステップ１１０２に移行し、そこで最終的な前記信頼レベルが第２の閾値と比較される。もし、この信頼レベルが第２の閾値よりも高ければ（ステップ１１０３）、文書はマニュアル処理に送り出される（ステップ１１０４を参照）。より特別には、文書の画像とそのＯＣＲの表現が、人間オペレータに与えられる。当該オペレータは視覚的に情報を解釈し、その後で解釈した文書をシステムに戻す。
【００９８】
分類段階５−抽出およびクリーンアップ
段階５において、「最高」の文法マッチ結果を有するトークン化されたものから、名刺でータを抽出するために、システムは先に取得した情報を利用する。ここでは、次の処理が行なわれる。
−文法マッチの結果から、カードのフィールドデータを抽出する。
−例えば電話番号は数字、名前はキャラクタ（文字）だけであることを確実にするように、幾つかのデータスクラビングを行なう。注意点：電話番号において「ｌ」は「１」でなければならない、と最終的にいうのがこの段階であるから、以前からのＯＣＲの「あいまいさ」によって、これらを違うものとすることができる。
−ブイカード（vCard）のような保存および配信に適したフォーマットで、コンタクトレコードを生成する。
−上手く生成したブイカードから抽出される情報で、内部データベースを更新する。
【００９９】
分類サーバでの修理中に、文法，辞書，および他の関連規則が、（例えば、名刺とレシートを区別するための）ＣＦフラグの値に基づき選び出される。レシートに対しての文法や辞書は異なるが、前記各ステップのシーケンスは上述したものと同じであり、ここでは繰り返さない。
【０１００】
サーバでの最終的な処理ステップは、配信サーバ５５０として引用されるソフトウェア５５０により提供される。当該ステップは、結果として得られた情報をパッケージングし、これをユーザの電子メールアカウントに送出することに関与するもので、当該情報は、本サービスにおけるユーザアカウントと関連付けられたユーザデータベースに保存される。ユーザへのメッセージは、（ユーザによって書き込まれた）オリジナルのテキストメッセージと同様に、上述したような処理済の文書を含んでいる。仮に、ユーザがこの情報を後処理サーバ１５０に保存するために選択すると、ユーザアカウントと関連付けて当該情報が保存される。ユーザは後処理サーバ１５０にログオンし、前記保存した情報を検索する機能を有する。さらに前述したように、ユーザは公開されたサービスから、ファックス出力を受取ることもできる。ファックス番号をユーザアカウントと関連付けて記憶してもよく、さもなければセットアップ処理の一部として、様々な番号を電話から提供してもよい。図４で記述したように、ユーザインターフェースでファックス番号を入力することができる。仮に入力すると、この番号はＣＦフラグの一部となり、ユーザ用に保存されたデフォルト番号に優先する。仮に、ファックスが任意に選択された場合には、従来知られているように、配信サーバ５５０がファックスで処理結果を送信する。
【０１０１】
本発明は、ここに記述された特定の実施例によって、その範囲に限定されるものではない。実際は、ここに記述されたものに加えて、本発明の様々な改良変更が、上述した記述と添付の各図面から、当業者において明確になるであろう。こうした改良変更は、添付の各請求項の範囲に含まれることを意図している。次の各請求項によってその範囲が定義される本発明の教示を逸脱することなく、他の多数の実施例を確実に着想できる。
【図面の簡単な説明】
【０１０２】
【図１】本発明の一実施例に基づいて、データ取得および処理システムと関連したコンピュータアーキテクチャを示す概略図である。
【図２】図１のシステムにおける例示的な動作ステップを示すフローチャートである。
【図３Ａ】一実施例に基づくユーザーインターフェースメニューの概略図であり、当該ユーザーインターフェースメニューは、図１のシステムと関連した手持ちデバイスを用いてアクセスされる。
【図３Ｂ】図１のユーザーインターフェースメニューにおけるサブメニューの概略図である。
【図４】一実施例に基づき、ソフトウェアコンポーネントの処理順序を示すフローチャートであり、当該ソフトウェアコンポーネントは、図１のシステムとそれ自体が関連付けられ、それにより提供されるサービスをサポートする手持ちデバイスと関係する。
【図５】別な実施例に基づき、ソフトウェアコンポーネントの処理順序を示すフローチャートであり、当該ソフトウェアコンポーネントは、図１のシステムとそれ自体が関連付けられ、それにより提供されるサービスをサポートする手持ちデバイスと関係する。
【図６】一実施例に基づき、システムの後処理サーバにおけるコンポーネントを示す概略図である。
【図７】図６におけるポスト処理サーバの一部をなす分類ソフトウェアの処理順序を示すフローチャートである。
【図８】本発明のシステムに用いられる初期分類フィルタを示す概略図である。
【図９】本発明のシステムに基づいて、一つのトークン化に対する例示的処理を示すフローチャートである。
【図１０】本発明のシステムに基づいて、例示的なデータベース処理の推移を示すフローチャートである。
【図１１】本発明のシステムに基づいて、一つの文法マッチをインターネットで検索する処理を示すフローチャートである。
【図１２】本発明のシステムに基づいて、処理が行なわれた全てのトークン化に対し、一定レベルの信頼を割り当てる処理を示すフローチャートである。
【図１】
2008546058.tif 000004
【図２】
2008546058.tif 000005
【図３Ａ】
2008546058.tif 000006
【図３Ｂ】
2008546058.tif 000007
【図４】
2008546058.tif 000008
【図５】
2008546058.tif 000009
【図６】
2008546058.tif 000010
【図７】
2008546058.tif 000011
【図８】
2008546058.tif 000012
【図９】
2008546058.tif 000013
【図１０】
2008546058.tif 000014
【図１１】
2008546058.tif 000015
【図１２】
2008546058.tif 000016
【国際調査報告】
2008546058.tif 000017