(57)【要約】      （修正有）【課題】モバイル機器に適した、フォームに自動的に入力する方法および装置を提供する。【解決手段】フォームに含まれる各入力フィールドに対してオブジェクトを生成するために、ウェブベースのフォームを解析するパーサーと、チェックする条件と、前記条件を満たしていることが判明した場合に導かれる結論とを含んだルールを評価するルール評価モジュールと、前記ルールの評価に基づいて、あるユーザデータベースから取得し、セマンティックな意味によって特定された値を用いて、前記フォームを自動入力するユーザデータ入力モジュールとを備え、対応する１つ以上のルールを満たしていることが判明した入力フィールドについてのそれぞれのセマンティックな意味に対し、あるセマンティックな意味について満たしたルールに対応するスコアを結合し、結合されたスコアが最も高い、該入力フィールドに対するセマンティックな意味を選択する装置。【選択図】図２
2007183916.tif 000002
【特許請求の範囲】
【請求項１】
モバイル機器においてウェブベースのフォームを自動入力するための装置であって、
前記フォームに含まれる各入力フィールドに対してオブジェクトを生成するために、ウェブベースのフォームを解析するパーサーであって、前記オブジェクトは、前記入力フィールドまたはその近傍を表現または定義する１つ以上のパラメータを表し、前記入力フィールドを表現したものである、パーサーと、
チェックする条件と、前記条件を満たしていることが判明した場合に導かれる結論とを含んだルールを評価するルール評価モジュールであって、
前記評価は、あるルールをあるオブジェクトと比較することにより実行されるものであり、
前記ルールは、
前記条件として、前記入力フィールドについての１つ以上のパラメータが個別の値を含んでいるかまたは取る、該入力フィールドを表現したものと、
前記結論として、該入力フィールドに関する個別のセマンティックな意味と、
該入力フィールドに対して、該入力フィールドを表現するオブジェクトとルールとを比較することにより該ルールを評価する際に、前記条件を満たしていることが判明した場合に前記結論が真である確率を示す個々のスコアと
を含むものである、ルール評価モジュールと、
前記ルールの評価に基づいて、あるユーザデータベースから取得し、前記セマンティックな意味によって特定された値を用いて、前記フォーム内のある入力フィールドを入力することにより前記フォームを自動入力するユーザデータ入力モジュールとを備え、
前記ルール評価モジュールは、前記ウェブベースのフォーム内の各入力フィールドに対し、前記入力フィールドに対応する、オブジェクトで表現したものと複数のルールとを比較することにより、あるルールリポジトリに保存されている前記ルールを評価するものであり、
対応する１つ以上のルールを満たしていることが判明した前記入力フィールドについてのそれぞれのセマンティックな意味に対し、結合されたスコアを得るためにあるセマンティックな意味について満たしたルールに対応するスコアを結合し、結合されたスコアが最も高い、該入力フィールドに対するセマンティックな意味を選択するものである
装置。
【請求項２】
前記パーサーは更に、自動入力するフォーム内の全ての入力フィールドを表現するオブジェクト構造を生成するものであって、前記オブジェクト構造は、前記入力フィールドのそれぞれに対して１つのオブジェクトを含むものである、請求項１に記載の装置。
【請求項３】
前記オブジェクト構造は、前記オブジェクトを含んだあるリストを含むものであって、各オブジェクトは、対応する入力フィールドを表現したものと、該オブジェクトに先行するオブジェクトおよび該オブジェクトの後続のオブジェクトについてのリファレンスとを含むものである、請求項２に記載の装置。
【請求項４】
前記モバイル機器で稼動するウェブブラウザと、入力するフォームを保持するウェブサーバとの間の仲介として機能するプロキシとして構成される請求項１〜３のいずれか一項に記載の装置。
【請求項５】
前記パラメータは、前記オブジェクトにより表現される前記入力フィールドを定義または表現するものであり、
前記ルールは、
前記フォームが前記モバイル機器に表示される際に、前記入力フィールドの隣に表示されるラベルと、
前記ウェブベースのフォームのソースコード内にある、前記入力フィールドについての内部的な名称と
のうちの１つ以上を含むものである、
請求項１〜４のいずれか一項に記載の装置。
【請求項６】
複数のユーザがアクセス可能なプロキシサーバとして構成されている請求項１〜５のいずれか一項に記載の装置。
【請求項７】
前記ルールは、前記パラメータに加えて、前記入力フィールドに関する前記パラメータのロケーションの指示を含むものである、請求項１〜６のいずれか一項に記載の装置。
【請求項８】
ある入力フィールドに関するあるパラメータの前記ロケーションの指示は、
現在の入力フィールドに先行する入力フィールドと、
現在の入力フィールドと、
現在の入力フィールドの後続の入力フィールドと
のうちの１つ以上を指示するものである、請求項７に記載の装置。
【請求項９】
１００％の確率を示すスコアが割り当てられたルールを満たしていることが判明した場合に、それ以上ルールを評価せず、該入力フィールドを入力するために該ルールに対応するセマンティックな意味が選択される、請求項１〜８のいずれか一項に記載の装置。
【請求項１０】
ルールは通常ルールまたは優先ルールに分類されるものであり、
あるセマンティックな意味についての合計スコアを導く際、優先ルールのスコアに対しては、より大きな重み付けが行われるものである、
請求項１〜９のいずれか一項に記載の装置。
【請求項１１】
前記パーサーおよび前記ルール評価モジュールは、前記モバイル機器とは別のある変換サーバ上に配置されるものであり、
前記変換サーバは、前記モバイル機器が、対応するユーザデータを前記ウェブベースのフォームに入力することを可能にする、前記ルール評価の結果としての識別子を前記モバイル機器に転送するものである、
請求項１〜１０のいずれか一項に記載の装置。
【請求項１２】
前記装置により前記ルール評価に基づいて前記フォームに自動入力されたデータをユーザが修正することを可能にするユーザインタフェースと、
ユーザによって提示されたデータの修正または確認に基づいてルールリポジトリ内のルールを更新する更新モジュールと
を更に備える請求項１〜１１のいずれか一項に記載の装置。
【請求項１３】
前記更新モジュールは、
前記ユーザの入力によって修正がなされた結論に関するルールのスコアを減少させるモジュールと、
前記ユーザにより修正がなされなかった結論に関するルールのスコアを増加させるモジュールと、
前記ユーザの修正に対応するルールがまだ存在していない場合に新たなルールを格納するモジュールと
のうちの１つ以上を備えるものである、請求項１２に記載の装置。
【請求項１４】
前記装置に格納されているルールリポジトリをローカルに更新するモジュールと、
遠隔のサーバ上にあるルールリポジトリを更新するモジュールと、
あるサーバから新しいルールセットをダウンロードすることにより、ローカルなルールリポジトリを更新するモジュールと
のうちの１つ以上を更に備える請求項１〜１３のいずれか一項に記載の装置。
【請求項１５】
モバイル機器またはコンピュータのブラウザに組み込まれている請求項１〜１４のいずれか一項に記載の装置。
【請求項１６】
請求項１〜１５のいずれか一項に記載の装置と組み合わせて使用可能な、一連のルールを自動的に生成する装置であって、
ある入力フィールドが取りうるセマンティックな意味について、該入力フィールドまたはその近傍を表現または定義するパラメータが取りうる値のリストが格納されており、
入力フィールドに関してウェブベースのフォームを解析し、入力フィールドごとにオブジェクトを生成するモジュールであって、前記オブジェクトは、該入力フィールドまたはその近傍を表現または定義する１つ以上のパラメータを表し、該入力フィールドを表現したものである、モジュールと、
オブジェクトごとに、該オブジェクトと値のリストとを比較するモジュールであって、あるパラメータが前記値の１つと適合した場合に、条件のパラメータとしての該値と、結論としての、前記リストによって定められた該値に対応するセマンティックな意味とを含むプレルールを生成するためのモジュールと、
適合が発見されるたびに、対応するプレルールが既に生成されているかどうかをチェックし、既に生成されていれば、該プレルールに対応するカウンタをインクリメントするモジュールと、
同じセマンティックな意味に対応する、生成されたプレルールの各スコアを決定するために各カウンタを評価することにより、前記プレルールを評価するモジュールと
を備える装置。
【請求項１７】
モバイル機器においてウェブベースのフォームを自動入力するための方法であって、
前記フォームに含まれる各入力フィールドに対してオブジェクトを生成するために、ウェブベースのフォームを解析するステップであって、前記オブジェクトは、前記入力フィールドまたはその近傍を表現または定義する１つ以上のパラメータを表し、前記入力フィールドを表現したものである、ステップと、
チェックする条件と、前記条件を満たしていることが判明した場合に導かれる結論とを含んだルールを評価するステップであって、
前記評価は、あるルールをあるオブジェクトと比較することにより実行されるものであり、
前記ルールは、
前記条件として、前記入力フィールドについての１つ以上のパラメータが個別の値を含んでいるかまたは取る、該入力フィールドを表現したものと、
前記結論として、該入力フィールドに関する個別のセマンティックな意味と、
該入力フィールドに対して、該入力フィールドを表現するオブジェクトとルールとを比較することにより該ルールを評価する際に、前記条件を満たしていることが判明した場合に前記結論が真である確率を示す個々のスコアと
を含むものである、ステップと、
前記ルールの評価に基づいて、あるユーザデータベースから取得し、前記セマンティックな意味によって特定された値を用いて、前記フォーム内のある入力フィールドを入力することにより前記フォームを自動入力するステップとを含み、
前記評価するステップは、前記ウェブベースのフォーム内の各入力フィールドに対し、前記入力フィールドに対応する、オブジェクトで表現したものとあるルールリポジトリに保存されている複数のルールとを比較することにより、前記ルールを評価することを含むものであり、
対応する１つ以上のルールを満たしていることが判明した前記入力フィールドについてのそれぞれのセマンティックな意味に対し、結合されたスコアを得るためにあるセマンティックな意味について満たしたルールに対応するスコアを結合し、結合されたスコアが最も高い、該入力フィールドに関するするセマンティックな意味を選択するものである
方法。
【請求項１８】
請求項２〜１６のいずれか一項に記載の特徴を更に有する請求項１７に記載の方法。
【請求項１９】
請求項１〜１６のいずれか一項に記載の装置と組み合わせて使用可能な、一連のルールを自動的に生成する方法であって、
ある入力フィールドが取りうるセマンティックな意味について、該入力フィールドまたはその近傍を表現または定義するパラメータが取りうる値のリストを格納し、
入力フィールドに関してウェブベースのフォームを解析し、入力フィールドごとにオブジェクトを生成するステップであって、前記オブジェクトは、前記入力フィールドまたはその近傍を表現または定義する１つ以上のパラメータを表し、前記入力フィールドを表現したものである、ステップと、
オブジェクトごとに、該オブジェクトと前記取りうる値のリストとを比較し、あるパラメータが前記値の１つと適合した場合に、条件のパラメータとしての、前記値と、結論としての、前記リストにより定められた前記値に対応するセマンティックな意味とを含むプレルールを生成するステップと、
適合が発見されるたびに、対応するプレルールが既に生成されているかどうかをチェックし、既に生成されていれば、該プレルールに対応するカウンタをインクリメントするステップと、
生成された、同じセマンティックな意味に対応するプレルールを、それぞれのスコアを決定するためのそれぞれのカウンタを評価することにより評価するステップと
を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、モバイル機器においてフォームを自動入力する方法および装置に関し、基礎とする技術（例えば、（Ｘ）ＨＴＭＬ、ｃＨＴＭＬ、ＷＭＬなど）が何であれ、ウェブベースのサービス（例えば、ｉモード、ＷＡＰ）に特に適する。
【背景技術】
【０００２】
デスクトップＰＣとモバイル機器とでは、テキスト入力のしやすさに大きな違いがある。モバイル機器の場合、キーベースおよびスタイラスベースといった、異なる２つのテキスト入力に大きく分けることができる。これらの方法に加えて、予測入力も使用することができる。テキストの入力速度は、通常、１分あたりのワード数（ｗｐｍ）で測定する。従来のキーボードを使用する場合、熟練したタッチタイピストは通常平均７２ｗｐｍで入力することができる。モバイル機器でのテキスト入力は、以下の表からわかるように速度は相対的に低い。
【表１】
2007183916.tif 000003
【発明の開示】
【発明が解決しようとする課題】
【０００３】
モバイルサービスを利用する際、ユーザは頻繁に氏名またはアドレスなどのフォームデータを手入力する必要がある。しかし、モバイル機器にはフルサイズのキーボードがなく、または少なくとも、使いにくい小さなサイズのキーボードがあるだけなので、このような手入力は煩わしいことがよくある。さらに、モバイル機器の計算リソースは、標準的なスタンドアロンＰＣと比較して限られている。そこで、本発明の目的は、特にモバイル機器に適した、フォームに自動的に入力する方法および装置を提供することにある。
【課題を解決するための手段】
【０００４】
１つの実施形態によれば、モバイル機器においてウェブベースのフォームを自動入力するための装置であって、前記フォームに含まれる各入力フィールドに対してオブジェクトを生成するために、ウェブベースのフォームを解析するパーサーであって、前記オブジェクトは、前記入力フィールドまたはその近傍を表現または定義する１つ以上のパラメータを表し、前記入力フィールドを表現したものである、パーサーと、チェックする条件と、前記条件を満たしていることが判明した場合に導かれる結論とを含んだルールを評価するルール評価モジュールであって、前記評価は、あるルールをあるオブジェクトと比較することにより実行されるものであり、前記ルールは、前記条件として、前記入力フィールドについての１つ以上のパラメータが個別の値を含んでいるかまたは取る、該入力フィールドを表現したものと、前記結論として、該入力フィールドに関する個別のセマンティックな意味と、該入力フィールドに対して、該入力フィールドを表現するオブジェクトとルールとを比較することにより該ルールを評価する際に、前記条件を満たしていることが判明した場合に前記結論が真である確率を示す個々のスコアとを含むものである、ルール評価モジュールと、前記ルールの評価に基づいて、あるユーザデータベースから取得し、前記セマンティックな意味によって特定された値を用いて、前記フォーム内のある入力フィールドを入力することにより前記フォームを自動入力するユーザデータ入力モジュールとを備え、前記ルール評価モジュールは、前記ウェブベースのフォーム内の各入力フィールドに対し、前記入力フィールドに対応する、オブジェクトで表現したものと複数のルールとを比較することにより、あるルールリポジトリに保存されている前記ルールを評価するものであり、対応する１つ以上のルールを満たしていることが判明した前記入力フィールドについてのそれぞれのセマンティックな意味に対し、結合されたスコアを得るためにあるセマンティックな意味について満たしたルールに対応するスコアを結合し、結合されたスコアが最も高い、該入力フィールドに対するセマンティックな意味を選択するものである装置が提供される。
【０００５】
前記パーサーは、各入力フィールドを比較的シンプルに表現したオブジェクトを生成する。この表現は、その形式および構造において所定の一連のルールに対応する。ルール内でパラメータが取る個別の値が、そのオブジェクト内でこのパラメータが取る値と一致するかどうかをチェックすることにより、これらルールをそのオブジェクトと比較することができる。一致していることが判明した場合にはルールの条件を満たし、その条件に対応する（決まった）結論、すなわちその入力フィールドがこのルールに対応するセマンティックな意味を有するということが導き出される。さらに、ルールはその結論が実際に真であるかどうかを示す決まったスコアを含んでいる。
【０００６】
（決まった）結論および（決まった）スコアにより、モバイル機器のリソースが制限されている場合であっても、ルールを評価することは比較的容易なものとなる。さらに、各ルールにスコアを割り当て、満たすことが判明したルールのスコアを結合することは、正確な評価結果を得つつルールを評価する効率的な方法である。１つのセマンティックな意味に複数のルールが与えられているため、あるセマンティックな意味に対応する個別のルールに割り当てられたスコアを結合することにより、ルールの評価に基づいてより精度の高い結果を得ることができる。フォーム入力の際、結合された最も高いスコアを有するセマンティックな意味を選択する。
【０００７】
１つの実施形態によれば、前記パーサーは更に、自動入力されるフォーム内の全ての入力フィールドを表現しており、前記入力フィールドごとに１つのオブジェクトを含んだオブジェクト構造を生成する。
【０００８】
オブジェクト構造は、自動入力されるフォーム内の全ての入力フィールドについての全体的な表現を提供する。この表現は、どのユーザデータをそのフォームに入力すべきかを定めるために関連のある、フォームについての情報に関係しているだけである。
【０００９】
１つの実施形態によれば、オブジェクト構造は、オブジェクトを含むリストを含んでいる。各オブジェクトは、それぞれ対応する入力フィールドを表現したものであり、その入力フィールドに先行するオブジェクトと後続のオブジェクトとに対するリファレンス（例えばポインタ）を含む。
【００１０】
１つの実施形態によれば、最も高いスコアを第１候補に選ぶことも可能であるが、他の低いスコアは、ユーザがフォームをクリックしたときに併せて表示できる追加候補になり得る（インターネットエクスプローラのようなブラウザのオートコンプリート機能に類似）。追加候補の確率は、例えば確率に応じた色で区別することまたは確率に応じた順序で候補を並べることによって、ユーザに示すことができる。
【００１１】
１つの実施形態によれば、前記装置は、モバイル機器で実行されるウェブブラウザとフォームを入力するウェブサーバとの間の仲介として機能するプロキシとして構成される。
【００１２】
ローカルなプロキシアーキテクチャは、決まったスコアを個々のルールに割り当てることによって遂行される複雑ではないアルゴリズムと組み合わせて、特にモバイル機器に適したフォーム入力自動装置を実現する。これは、複数のユーザから同時に送信された複数のリクエストを処理しなければならないサーバに実装されたプロキシにも適している。
【００１３】
プロキシは、要求に応じてモバイル機器にインストールすることができるか、または事前にインストールしておくことができる。これは、モバイル機器で実行されるウェブブラウザ（ｉモード、ＷＡＰ、または（Ｘ）ＨＴＭＬなど）とウェブサーバとの間の全ての通信を仲介する。その際、データ入力フィールドの特性を解析し、モバイル機器に保存されたユーザデータを入力する。
【００１４】
１つの実施形態によれば、プロキシまたはその機能はブラウザの一部に組み込むこともできる。
【００１５】
ローカルなプロキシアーキテクチャは、既存のモバイル機器とウェブベースのサービスとに適用することができる。プロキシは、モバイル機器で実行されるウェブブラウザとサーバ側のウェブページとの間の仲介として機能する。プロキシは事前にインストールするか、またはプラグインアプリケーションとしてダウンロードすることができるので、従来技術（例えばＨＴＭＬ、ＸＨＴＭＬ、ｃＨＴＭＬ、ＷＭＬ／ＷＡＰ）に基づいた既存のモバイルサービス（例えばｉモード）で使われる全てのフォームは、何ら変更を加えることなく入力できる。
【００１６】
１つの実施形態によれば、フォーム入力に使用する全てのユーザデータは、モバイル機器に保存され、ゲートウェイまたはサービスプロバイダのサーバに分散して保存されることはない。プロキシによって入力されるフォームは、そのフォームがサーバに返却または送信される前に、入力データを確認することができるユーザに対してモバイル機器に表示される。ユーザが様々な方法で入力をチェックするのを手助けするために、確率も表示することができる（３０％未満の確率で入力されるフォームは、赤で表示される）。
【００１７】
１つの実施形態によれば、ルールに割り当てられており結論が真である確率を示す所定のスコアは、既存のウェブベースのフォームのような、既存のウェブページコンテンツの解析に基づいている。
【００１８】
１つの実施形態によれば、前記パラメータは、前記オブジェクトによって表されている前記入力フィールドを定義または表現する。前記ルールは、前記フォームがモバイル機器に表示されるときに前記入力フィールドの隣に表示されるラベルと、前記ウェブベースのフォームのソースコードにおける前記入力フィールドの内部的なネーミングの１つ以上を含んでいる。
【００１９】
ラベルは、ある入力フィールドの周囲または近傍を記述または表現する。１つの実施形態では、ラベルはブラウザによって表示されている、入力フィールドの直前にある文字列である。これは、入力フィールドのラベルがそのセマンティックな意味と相互に関連しているという事実を反映している。
【００２０】
同様に、入力フィールドのソースコードにおける内部的なネーミングも、その入力フィールドについてのセマンティックな意味とほぼ相互に関連しており、それゆえ、ルールについての条件に対するパラメータとして選ぶことができる。
【００２１】
１つの実施形態によれば、前記装置は、複数のユーザへのアクセスを可能にするプロキシサーバとして構成される。
【００２２】
これにより、複数のユーザは前記装置を利用することが可能である。本発明の装置は、複数のユーザがフォーム自動入力機能を利用することができるように、例えばポータルサーバの１つの要素またはインターネット回線における任意の中間ノードもしくは終端ノードに実装することができる。
【００２３】
１つの実施形態によれば、前記ルールは、前記パラメータに加えて、前記入力フィールドについてのパラメータのロケーションの表現も含む。これにより、入力フィールド自体が位置するエリアだけでなく、その周囲のエリアも利用することができるようになる。
【００２４】
１つの実施形態によれば、ある入力フィールドに関するパラメータのロケーションについての前記表現は、現在の入力フィールドに先行する入力フィールドと、現在の入力フィールドと、現在の入力フィールドの後続の入力フィールドとのうちの１つ以上を示す。
【００２５】
これにより、現在の入力フィールド自体が位置するエリアだけでなく、例えばその入力フィールドに先行する入力フィールドまたは後続の入力フィールドといった周囲のエリアと、前記パラメータがこれらのロケーションでとる値とを利用することが可能である。
【００２６】
１つの実施形態によれば、１００％の確率を示すスコアが割り当てられたルールが、現在評価している入力フィールドに対して満たされていることが判明した場合には、それ以上ルールを評価することはなく、その１００％の確率を示すスコアが割り当てられたルールに対応するセマンティックな意味が、当該入力フィールドを入力するために選ばれる。これにより、複数のルールの評価が途中で打ち切られて全体的な手順が短くなるので、ルールを評価するのに必要な計算能力は大きく減少する場合がある。
【００２７】
１つの実施形態によれば、ルールは通常ルールまたは優先ルールに分類され、あるセマンティックな意味に対する総スコアを導く際に、優先ルールのスコアをより重視する。
【００２８】
優先ルールと通常ルールとの区別は、全てのルールに（既存のウェブページの統計的な解析から導出された、真である確率に加えて）同じ重み付けを行う訳ではないという事実を考慮に入れている。例えば、入力フィールド自体に関係するルールは、先行する入力フィールドまたは後続の入力フィールドに関連するルールに比べて、より信頼性が高いものとなる。
【００２９】
ある具体的な形態によれば、ルール評価プロセスの打ち切りは、１００％の確率に対応するスコアを有するルールが満たされている場合に、優先ルールに対してのみ行われる。これにより、あるルールが単なる通常ルールであるために、誤って真であると判定することで打ち切りが早まる確率が減少する。
【００３０】
１つの実施形態によれば、前記パーサーおよび前記ルール評価モジュールは、前記モバイル機器とは離れた変換サーバに置かれる。前記変換サーバは、前記ルール評価の結果として前記モバイル機器が前記ウェブベースのフォームに対応するユーザデータを入力することを可能にする識別子を前記モバイル機器に転送する。
【００３１】
これによりモバイル機器側に必要なリソースが減少する。この場合でも、全てのユーザデータはプライバシーを保護するためにモバイル機器に保存できる。
【００３２】
１つの実施形態によれば、前記装置は、前記ルール評価に基づいて前記装置により前記フォームに自動的に入力されたデータをユーザが再編集することを可能にするユーザインタフェースと、ユーザによって示されたデータの修正または確認に基づいて、ルールリポジトリ内にあるルールを更新するための更新モジュールとを更に備える。
【００３３】
ユーザインタフェースは、フィールドの自動入力の結果が間違っている場合に修正するため、ユーザが編集することを可能にする。さらに、ルールを動的に更新することによって、ルールリポジトリおよびこのルールリポジトリに格納されたルールの質を継続して改善することができる。それにより、例えば傾向の変化によるフォームの標準のスタイルの変更を考慮することが可能である。
【００３４】
モバイル機器におけるルールの更新は、２つの方法で実行可能である。１つ目の方法によれば、ローカルなルールリポジトリは、既に言及したようにユーザ入力に基づいて更新することができる。２つ目の方法によれば、（例えばサーバ上にある）主要なルールリポジトリが存在する。そこに保存されたルールは、既に述べたように個々の電話機上のユーザ入力に基づいて更新することができる。このように更新されたルールは、その後他のモバイル機器のルールリポジトリを最新化するためにそのモバイル機器にダウンロードすることができる。
【００３５】
１つの実施形態によれば、前記更新モジュールは、結論がユーザ入力によって修正されたルールのスコアを減少させるモジュールと、結論がユーザによって変更されなかったルールのスコアを増加させるモジュールと、前記ユーザ修正に対応するルールがまだ存在しない場合に新しいルールを格納するためのモジュールとのうちの１つ以上を備える。
【００３６】
これにより、ユーザが行う修正に基づいて既存のルールの確率を修正するのみならず、新しいルールをデータベースに取り入れることも可能となる。ユーザは、入力フィールドに対してフォーム入力装置が提示したデータを置き換えるために、モバイル機器上に異なる概念名で保存されているユーザデータを入力する場合がある。このように修正がなされたことにより、ルールのスコアが減少することがあり得る。他方、フォーム入力装置により提示されたものを修正しないこと（つまり「確認」）は、このルールのスコアの増加をもたらす場合がある。さらに、対応するルールが生成されていない一部のデータをユーザが入力する場合（入力されたユーザデータを含む結論が全く存在しないか、または入力されたユーザデータがまだモバイル機器に保存されていないため）、このようなルールが新しく生成され、保存することができる。これは、入力されたユーザデータが一部の概念名でモバイル機器にまだ保存されていない場合にも、実行される場合がある。このとき、ユーザは、概念名の入力を求められる場合があるか、またはソースコード内の入力フィールドのラベルもしくはタグを概念名として使用することができる。後者であれば、余計なユーザ入力を避けることができる。
【００３７】
１つの実施形態によれば、本発明の実施形態の１つに基づく自動入力するための装置と組み合わせて使用可能な、一連のルールを自動的に生成する装置であって、ある入力フィールドが取りうるセマンティックな意味について、該入力フィールドまたはその近傍を表現または定義するパラメータが取りうる値のリストが格納されており、入力フィールドに関してウェブベースのフォームを解析し、入力フィールドごとにオブジェクトを生成するモジュールであって、前記オブジェクトは、該入力フィールドまたはその近傍を表現または定義する１つ以上のパラメータを表し、該入力フィールドを表現したものである、モジュールと、オブジェクトごとに、該オブジェクトと値のリストとを比較するモジュールであって、あるパラメータが前記値の１つと適合した場合に、条件のパラメータとしての該値と、結論としての、前記リストによって定められた該値に対応するセマンティックな意味とを含むプレルールを生成するためのモジュールと、適合が発見されるたびに、対応するプレルールが既に生成されているかどうかをチェックし、既に生成されていれば、該プレルールに対応するカウンタをインクリメントするモジュールと、同じセマンティックな意味に対応する、生成されたプレルールの各スコアを決定するために各カウンタを評価することにより、前記プレルールを評価するモジュールとを備える装置が提供される。
【００３８】
これにより、多数の既存のウェブベースのフォームを評価して統計的に見て代表的なものとなるルールリポジトリを生成することによって、自動的な方法でルールを生成することができる。
【発明を実施するための最良の形態】
【００３９】
以下、添付図面を参照して本発明の典型的な実施形態を説明する。
【００４０】
しかしながら、本発明の実施形態を詳細に説明する前に、まず、Ｔ．Ｃｈｕｓｈｏ、Ｋ．Ｆｕｊｉｗａｒａ、Ｋ．Ｍｉｎａｍｉｔａｎｉ、「Ａｕｔｏｍａｔｉｃ  Ｆｉｌｌｉｎｇ  ｉｎ  ａ  Ｆｏｒｍ  ｂｙ  ａｎ  Ａｇｅｎｔ  ｆｏｒ  Ｗｅｂ  Ａｐｐｌｉｃａｔｉｏｎｓ」、Ａｓｉａ−Ｐａｃｉｆｉｃ  Ｓｏｆｔｗａｒｅ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｃｏｎｆｅｒｅｎｃｅ  ２００２、ＩＥＥＥ  Ｃｏｍｐｕｔｅｒ  Ｓｏｃｉｅｔｙ、２００２、ｐ．２３９−２４７に記載されているウェブベースサービスのためのフォーム自動入力アルゴリズムの動きについて説明する。
【００４１】
Ｃｈｕｓｈｏのアルゴリズムは、複数の概念名（Ｃｏｎｃｅｐｔ  Ｎａｍｅｓ）を同時に考慮した、比較的複雑なルールを使用する。ここで、概念名とは、アルゴリズムにおける個人情報の内部的なネーミングのことである。例えば、アルゴリズムは、個人のファーストネームを扱うため、内部的にＦｉｒｓｔＮａｍｅを使用する。つまり、概念名は、フォームを入力するために使用できるデータに関するセマンティック（ｓｅｍａｎｔｉｃ）な意味を特定するラベルである。
【００４２】
Ｃｈｕｓｈｏらによれば、ある入力フィールドの状況、すなわち４つのサイド（解析する入力フィールドの左、右、上、下）と、これらのロケーションにおけるそれぞれの値と、取るべきアクションとから構成される決まったルールが存在する。どのアクション（例えばファーストネームの選択）が入力フィールドに最もよく適合するかをチェックするため、Ｃｈｕｓｈｏのアルゴリズムは、あらゆる単一のルールについてのあらゆる単一のサイド（左、右、上、下）をチェックし、サイドごとに各アクション（選択される様々な概念名）の相対的な頻度を決定する。これは、個々のルールに対して複数の概念名を同時に考慮する必要があることを意味する。最後に、そのアルゴリズムは最も確実性の高いアクションを取る。これは、このアルゴリズムが、フォームと利用可能なルールとを調べながらあるアクション（すなわち、フォームを入力するために使用する概念名）の確実性を決定し、４つのサイドに基づいてあらゆる単一のルールに関するあらゆる単一の部分（あらゆる概念名）の確実性を決定するということを意味する。
【００４３】
本発明の実施形態に基づくフォーム入力方法において、ルールは、値（文字列、数字など）と、解析している入力フィールドについてのロケーションとから構成される。ルールが満たされるということは、そのルールによって定められた、入力フィールドに関するロケーションに、そのルールによって定められた値が存在するということを意味する。ルールが満たされると、このルールに対応する、フォームの該入力フィールドを入力するために使用する所定の概念名が得られる。あらゆるルールは、フォーム自動入力のための多くのオンラインで利用可能なフォームの評価に基づいた、それ自体の所定の確率（実際にこの入力フィールドがこのルールに対応する概念名で入力されるべき確率）も更に含んでいる。これは、あらゆるルールに対して確実性または確率が事前に定められており、入力フィールドチェックの際に計算する必要がなく、このためモバイル機器においてＣＰＵ時間が節約できるということを意味する。フォームフィラー（ｆｏｒｍ  ｆｉｌｌｅｒ）は、該入力フィールドにどのルールが適合するかをチェックしさえすればよい。
【００４４】
１つの実施形態によれば、入力フィールドに適合するルールの確率を合計することにより、個々のルールは比較的シンプルなものとすることができるものの、後ほど詳しく述べるように、複雑なルールが動的に生成される可能性がある。
【００４５】
１つの実施形態によれば、１つの入力フィールドに関して６つのサイドまたはロケーションを考慮する。上、下および現在の入力フィールドのラベルおよびネーム属性は、ＨＴＭＬソースコードから抽出される。そのラベルに対し、入力フィールドの直前に見出された最後のテキストが選択される。
【００４６】
図１に示されている、本発明の実施形態に基づくアーキテクチャの基本コンセプトは、モバイル機器上のインターネットブラウザとリクエストされたウェブページを提供するウェブサーバとの間で仲介として機能するプロキシである。
【００４７】
プロキシは、３つの基本コンポーネント、すなわちフォームフィラー、ユーザデータおよびルールから構成され、ウェブブラウザとウェブサーバとを仲介するためにモバイル機器に組み込まれている。プロキシは、モバイル機器に事前にインストールしておくことができるか、またはプラグアンドプレイ方式で動作するサードパーティのアプリケーションとしてダウンロードすることができる。ユーザデータは、ユーザがモバイル機器のユーザインタフェースを通して入力することができるか、モバイル機器自体または差し込まれているＳＩＭもしくはＵＳＩＭ上のユーザプロファイルから取得できるか、またはユーザが入力したフォームのデータをモニタして収集することにより蓄積される。ルールは事前にインストールしておくことができるか、または必要に応じてダウンロードすることができる。ルールサーバは、フォーム入力ルールを格納かつ提供する外部コンポーネントである。携帯電話機上のプロキシは、このルールサーバを使用してローカルのルールセットを最新の状態に保ち、ルールリポジトリの更新に関してルールサーバをサポートする。
【００４８】
ウェブサーバからモバイル機器へダウンロードまたは返却された全てのウェブページ（例えばＨＴＭＬ、ＸＨＴＭＬ、ｃＨＴＭＬ（ｉモード）、ＷＭＬまたはＷＡＰ）は、プロキシを経由する。このためプロキシは、ウェブブラウザとウェブサーバ上のウェブページとの間の仲介として機能する。ウェブページがフォームを含んでいる場合、フォーム入力コンポーネントは、利用可能なユーザデータとそのフォーム環境に最も良く適合するルールとに基づいて、フォームに入力するためのアクションを起こす。このようにして、プロキシは実際のウェブページにアクセスするためのインタフェースを提供する。このようなプロキシは、あらゆる既存のウェブブラウザに一切変更を加えることなく適用および接続ができるという利点を有する。
【００４９】
ユーザデータは、フォームにそのユーザデータを入力するために、適合したルールに基づいてフォームフィラーにより使用される。ユーザデータ（例えばフルネーム、ファーストネーム、住所所在地１、クレジットカード番号など）の管理および保存については、ここでは詳しく説明しない。なぜなら、これらのデータをどのように構造化するかに関して多くの研究成果が既にあるからである。さらに、本発明の実施形態の動作を説明する上で、個別のセマンティックな意味を有するユーザデータの個々の部分が、フォームに入力するために特定および取得できる限り、ユーザデータがどのように格納および編成されるかについては重要ではない。このため、例えばユーザデータを格納するデータ構造において、対応するユーザデータを特定するために、ユーザのファーストネームに対してＦｉｒｓｔＮａｍｅといったいくつかの概念名を定義しなければならない。次に概念名は、入力フィールドに入力するユーザデータにマッピングされる。
【００５０】
フォーム入力ルールを生成するため、ウェブページに存在するフォームを解析することができる。この解析をどのように実行するかについては後ほど詳しく述べる。この解析を実行する際に、要求された概念名とフォーム内の入力フィールドの配置とに関して多くの類似点が存在することがわかる。このため、ＦｉｒｓｔＮａｍｅというラベル付けをされた入力フィールドにユーザのファーストネームを入力する確率は極めて高い。ここで、ユーザのファーストネームから成るユーザデータは、例えば概念名（すなわち、対応するユーザデータの内部的なラベリング）であるＦｉｒｓｔＮａｍｅ、またはユーザのファーストネームに対する概念名として用いる他の何らかの識別子に対応しているということに注意しなければならない。
【００５１】
さらに、入力フィールドのコンテキストも重要となる。ここで、コンテキストとは、実際の入力フィールドが（例えば、ＨＴＭＬ記述または他の「ソースコード」による記述により）どのように定義されているか、そしてその入力フィールドの周辺にどのようなテキストまたは他のフォーム要素が存在しているかを意味する。例えば、あるフォーム内でファーストネームの後にラストネームが要求される確率が存在する。
【００５２】
図１に示されているルールサーバは、一連のルール（ルールセット）を格納している。最初に用いるルールセットは、例えば既存のウェブページの解析により生成することができる。初期状態のルールセットは、手動で生成することができるか、または後述するように自動的もしくは半自動的に生成することができる。さらに、後述する本発明の１つの実施形態によれば、初期状態のルールセットは、ユーザがフォーム入力プロキシを利用することにより更新することができる。
【００５３】
ルールは、チェックする条件と、その条件が満たされていることが判明した場合に導かれる結論とを規定するものと見なすことができる。あるパラメータ、例えば入力フォームを定義するＨＴＭＬドキュメント内のある部分が、ある値をとらなければならない条件をルールの条件として定めることができる。このようなパラメータは例えば、入力フィールドのラベルである。入力フィールドのラベルは例えば、ブラウザ上の入力フィールドの直前に表示されている文字列である。別のパラメータとしては、入力フォームのソースコード記述内の入力フィールドに関するネーム属性がある。
【００５４】
ルールの結論は、条件を満たしていることが判明した場合に入力フィールドに挿入される値とすることができる。以下、この結論のことをしばしば概念名と呼ぶ。概念名とは、事前に定められたあるユーザデータ、例えばファーストネーム、姓、生年月日、年齢など
を特定するものである。概念名は、あるタイプのユーザデータに対する識別子である。
【００５５】
従って、ルールを一般的に表現すると以下のようになる。
パラメータ値−概念名
【００５６】
このようなルールは、特定の入力フィールドに適用することができる。これは、ルールが適用される入力フィールドに対して、入力フォーム内の該フィールドのパラメータがそのルールで定められているパラメータ値をとるかどうかをチェックすることができるということを意味する。定められたパラメータ値がとられている場合は、条件に合致し、結論を導くことができる。これは、このようにしてチェックされた入力フィールドが、そのルールで定められた概念名により特定されるユーザデータを用いて入力されるべきであることをルールが示したということである。
【００５７】
既に言及したように、１つの実施形態において、ルールを生成するために異なるパラメータ、例えば入力フィールドのラベルおよびネーム属性を使用することができる。さらに、これらのパラメータはそのルールが適用される入力フィールドに関連するとは限らないが、そのルールが適用される入力フィールドと比較して異なる入力フィールド（例えば、前（上）または後（下）にある入力フィールド）のパラメータに関連する場合がある。これにより、ある実施形態に基づいてルールのパラメータとすることができる以下の６つのパラメータが得られる。
【００５８】
上部ラベル（Ｕｐｐｅｒ  ＬＡＢＥＬ）：  １つ上の入力フィールドの直前にあるテキスト。
上部ネーム属性値（Ｕｐｐｅｒ  ＮＡＭＥ＿ＡＴＴＲＩＢＵＴＥ＿ＶＡＬＵＥ）：  １つ上の入力フィールドのネーム属性値。
カレントラベル（Ｃｕｒｒｅｎｔ  ＬＡＢＥＬ）：  現在の入力フィールド（そのルールが適用される現在の入力フィールド）の直前にあるテキスト。
カレントネーム属性値（ＣＵＲＲＥＮＴ  ＮＡＭＥ＿ＡＴＴＲＩＢＵＴＥ＿ＶＡＬＵＥ）：  現在の入力フィールドのネーム属性値。
下部ラベル（Ｌｏｗｅｒ  ＬＡＢＥＬ）：  １つ下の入力フィールドの直前にあるテキスト。
下部ネーム属性値（Ｌｏｗｅｒ  ＮＡＭＥ＿ＡＴＴＲＩＢＵＴＥ＿ＶＡＬＵＥ）：  １つ下の入力フィールドのネーム属性値。
【００５９】
上部とは、ＨＴＭＬドキュメントにおいて、ルールを適用する現在の入力フィールドの直前にある入力フィールドのことである。下部とは、ＨＴＭＬドキュメントにおいて、ルールを適用する現在の入力フィールドの直後にある入力フィールドのことである。本例においてルールは、パラメータに加えて現在チェックされている入力フィールド（そのルールが適用される入力フィールド）に関するパラメータのロケーションを指し示すものも含んでいることがわかる。
【００６０】
１つの実施形態として、各ルールは、条件が満たされている場合に結論が真となる尤度を示すスコアを更に割当てる。このスコアは、１つの実施形態においては、結論が正しいものとなる尤度とすることができる。この尤度は、既にある入力フォームの統計的な評価に基づいて導き出すことができる。これは、後述するように更に動的に更新することができる。
【００６１】
１つの実施形態として、ルールリポジトリは、以下のシンタックスまたはスキーマに従うルールを格納するものである。
パラメータ（Ｐａｒａｍｅｔｅｒ）｜オペレータ（Ｏｐｅｒａｔｏｒ）｜値（Ｖａｌｕｅ）｜概念名（ＣｏｎｃｅｐｔＮａｍｅ）｜スコア（Ｓｃｏｒｅ）。
ここで、
ポジション（Ｐｏｓｉｔｉｏｎ）＝｛上部ラベル（ＵＰＰＥＲ＿ＬＡＢＥＬ）、上部ネーム属性値（ＵＰＰＥＲ＿ＮＡＭＥ＿ＡＴＴＲＩＢＵＴＥ＿ＶＡＬＵＥ）、カレントラベル（ＣＵＲＲＥＮＴ＿ＬＡＢＥＬ）、カレントネーム属性値（ＣＵＲＲＥＮＴ＿ＮＡＭＥ＿ＡＴＴＲＩＢＵＴＥ＿ＶＡＬＵＥ）、下部ラベル（ＬＯＷＥＲ＿ＬＡＢＥＬ）、下部ネーム属性値（ＬＯＷＥＲ＿ＮＡＭＥ＿ＡＴＴＲＩＢＵＴＥ＿ＶＡＬＵＥ）｝。
オペレータ（Ｏｐｅｒａｔｏｒ）＝｛含む（ＣＯＮＴＡＩＮＳ）、等しい（ＥＱＵＡＬＳ）｝。
値（Ｖａｌｕｅ）＝任意の文字列、例えば、ラベルタグ、フォーム直前の文字列、フォームのネーム属性、つまりパラメータがとる値。
概念名（Ｃｏｎｃｅｐｔ  Ｎａｍｅ）＝（フォームに入力するために使用する）ユーザデータの要素、例えばファーストネーム（ＦｉｒｓｔＮａｍｅ）など。
確率（Ｐｒｏｂａｂｉｌｉｔｙ）＝尤度を表す０から１００までの数。
【００６２】
＜パラメータ｜オペレータ｜値＞という部分は、ルールの条件を構成する。
【００６３】
パラメータと値との関係が、オペレータにより定義されているものである場合、その条件は満たされるということになる。そして、このルールが適用されている入力フィールドにこの概念名が入力されなければならないという結論が、スコアで表される確率とともに導き出される。
【００６４】
言い換えると、上で定義したルールは以下の要素から成る。
ａ）チェックする条件（すなわち、解析する入力フィールドに関するロケーションに、ある値が存在するか）である。この条件は、ルールの中で、パラメータ｜オペレータ｜値という部分によって表されている。値は、ある変数がとる値とすることができる。変数は例えば、フォームに含まれていて入力フィールドにラベル付けをするラベルとすることができるか、またはフォームのソースコード内で入力フィールドの名前を実際に表すラベルとすることができる。この種のラベルは、上述した文字列であるネーム属性値である。
ｂ）このルールに特有の概念名、およびこのルールに対応する概念名がフォームへの入力に使用されるユーザデータを特定する確率
【００６５】
以下に、ルールのいくつかの例を、それらの意味に対応する説明とともに列挙する。
・カレントネーム属性値（ＣＵＲＲＥＮＴ＿ＮＡＭＥ＿ＡＴＴＲＩＢＵＴＥ＿ＶＡＬＵＥ）｜含む（ＣＯＮＴＡＩＮＳ）｜ｆｉｒｓｔｎａｍｅ｜ＦｉｒｓｔＮａｍｅ｜１００。
現在の入力フィールドのネーム属性（ＣＯＮＣＥＰＴ＿ＶＡＬＵＥ）が、ｆｉｒｓｔｎａｍｅを含む（ＣＯＮＴＡＩＮＳ）場合、入力フィールドにユーザのファーストネーム（ＦｉｒｓｔＮａｍｅ）が入力される確率は１００％である。
・上部ネーム属性値（ＵＰＰＥＲ＿ＮＡＭＥ＿ＡＴＴＲＩＢＵＴＥ＿ＶＡＬＵＥ）｜含む（ＣＯＮＴＡＩＮＳ）｜ｆｉｒｓｔｎａｍｅ｜ＬａｓｔＮａｍｅ｜８１。
現在の入力フィールドの１つ上にある入力フィールドのネーム属性（ＵＰＰＥＲ＿ＣＯＮＣＥＰＴ＿ＶＡＬＵＥ）が、ｆｉｒｓｔｎａｍｅを含む（ＣＯＮＴＡＩＮＳ）場合、現在の入力フィールドにユーザのラストネーム（ＬａｓｔＮａｍｅ）が入力される確率は８１％である。
・カレントラベル（ＣＵＲＲＥＮＴ＿ＬＡＢＥＬ）｜含む（ＣＯＮＴＡＩＮＳ）｜ａｄｄｒｅｓｓ｜ＡｄｄｒｅｓｓＳｔｒｅｅｔ１｜４６。
入力フィールドの左側にある文字列（ＬＥＦＴ）が、住所（ａｄｄｒｅｓｓ）を含む（ＣＯＮＴＡＩＮＳ）場合、入力フィールドにユーザの住所１（ＡｄｄｒｅｓｓＳｔｒｅｅｔ１）が入力される確率は４６％である。
【００６６】
以下、他のルールより優先度が高い優先ルールを利用する実施形態について説明する。優先ルール、いわゆる上位ルールは、現在の入力フィールドそれ自体の記述の解析に基づいている。したがって、入力フィールドのネーム属性とその左側にある文字列が解析される。本実施形態では以下の２種類の優先ルールを導入する。
【００６７】
１つ目は、現在の入力フィールドについて、１００％の確率を有するカレントラベルまたはカレントネーム属性に関するルールが見つかった場合、これらが即座に選択される。言い換えると、１００％の確率を持つルールを満たすことが判明した場合、他のルールをチェックする必要がなく、フォームを入力するためにこのルールで割当てられている概念名が選択される。
【００６８】
２つ目は、１００％未満の確率を有するカレントラベルまたはカレントネーム属性についてのルールが、見つかったその他のルールよりも上位にランクされる。これは、カレントラベルまたはカレントネーム属性についてのルールに対し、他のルールと比べてより高いスコアが割当てられるということを意味する。このスコアは、フォームを入力するために選択される概念名についての最終的な決定にルールが影響を与える影響力を表す。
詳しくは後述するが、同じ概念名が割当てられた個々のルールのスコアは結合する（例えば合計する）ことができ、その結果、（異なるルールを使用して）他の概念名に対して導き出されたスコアと比較可能な、対応する概念名に対する合計スコアが得られる。これらスコアに基づいて、フォームに入力するためにどの概念名が選ぶべきかの決定をすることができる。スコアは、以下において概念ポイント（Ｃｏｎｃｅｐｔ  Ｐｏｉｎｔｓ）とも呼ぶ。なぜならば、これはこのルールで割当てられたある概念名のスコアを表しているからである。
【００６９】
１つの実施形態では、現在の入力フィールドに加えて上部および下部の入力フィールドも解析される。例えばファーストネームの後にラストネームが要求されるある確率が存在する。
【００７０】
図３は、一般的な（例えば、ホテルの部屋を予約するための）フォームとそれに対応するＨＴＭＬコードを示している。矢印は、アルゴリズムによって解析される６つのポジションを示している。これらポジションは、ＨＴＭＬコード内の太字で表されている値を指している。各フィールド（カレント、上部および下部）のラベルおよびネーム属性値（ｎａｍｅ＝“・・・”）が解析される。
【００７１】
図示されている例では、以下のようなものが存在する。
上部ラベル：Ｆｉｒｓｔ  Ｎａｍｅ
上部ネーム属性値：ｆｉｒｓｔｎａｍｅ
カレントラベル：Ｌａｓｔ  Ｎａｍｅ
カレントネーム属性値：ｌａｓｔｎａｍｅ
下部ラベル：Ａｄｄｒｅｓｓ
下部ネーム属性値：ａｄｄｒｅｓｓ１
【００７２】
ここで、ラベルは、ｈｔｍｌ要素＜ｌａｂｅｌ／＞を指しているのではなく、入力フィールドがどのようにマークされているか（＜ｄｉｖ＞、＜ｐ＞、＜ｓｐａｎ＞・・・）に関係なく仮にマークされていなくても、その入力フィールドの直前にある最後のテキストを指している。つまり、フォームを表示するブラウザによって表示されている場合の、入力フィールドの直前にあるテキスト文字列である。
【００７３】
一般的に、このフォーム入力アーキテクチャおよびアルゴリズムは、あらゆる様々な言語に使用することができる。このため、当該言語に対して最初に用いる一連のルールを規定するために既存の当該言語のフォームを解析しなければならない。
【００７４】
フォームを解析して入力するため、携帯電話機上のインターネットブラウザとリクエストされたウェブページとの間の仲介として機能するプロキシを使用する。従って、プロキシの構成はブラウザ内で設定され、携帯電話機のブラウザはプラグインにより拡張される。これにより、ブラウザのあらゆるリクエストは最初にプロキシに送信され、プロキシはこのリクエストを対応するウェブページに転送する。次に、ウェブサーバ（リクエストされたウェブページ）の対応する応答はプロキシに配信され、プロキシはＨＴＭＬページを解析し、フォームの入力を試み、その結果をウェブブラウザに送る。
【００７５】
プロキシは、フォーム入力のための「フォームフィラー」と呼ばれるコンポーネントを含む。フォーム入力モジュールは、以下に説明するアルゴリズムまたは手順を実行するコンピュータプログラムにより実行することができる。
【００７６】
第１に、ユーザデータとフォーム入力ルールは、それぞれ携帯電話機の記憶装置およびルールサーバからロードされる。ルールのダウンロードは常に必要というわけではない。新しいルールがルールサーバに存在する場合、または携帯電話機にルールが全く存在しない場合にルールがダウンロードされ、それ以外の場合には携帯電話機に記憶されているルールが使用される。
【００７７】
第２に、ブラウザはプロキシを通してウェブページをリクエストする。
【００７８】
第３に、プロキシはダウンロードされたウェブページを解析し、あらゆる入力フィールドをチェックすることにより、対応するオブジェクト構造を生成する。このプロセスは図４に示されている。ステップ４１０では、解析により入力フィールドが発見され、対応するオブジェクト、「形式」または「構造」が生成される。オブジェクトは、入力フィールドを表現したものであり、対応するルールを評価するための、入力フィールドについての関連のあるパラメータを表現するスキーマに従うものである。１つの実施形態によれば、関連のある２つのパラメータは、ブラウザによってスクリーン上に表示されている入力フィールドのラベルと、ソースコードの中で定義されている入力フィールド定義である。入力するフォーム内に発見された入力フィールドごとに、これら２つのパラメータ、すなわち表示されている入力フィールドの「ラベル」と当該フォームのソースコード内の入力フィールド定義とを含むオブジェクトが生成される。これによって、パーサーにより発見された入力フィールドごとに、（ラベル、入力フィールド定義）という形式を有するオブジェクトが得られる。入力フィールド定義は、ソースコードで定義されている入力フィールドの属性名を含み、更に入力フィールドのタイプと、入力するフォームのソースコード内にある所定の値も含む。解析されたフォームの中に、例えば、＜ｉｎｐｕｔ  ｔｙｐｅ＝“ｔｅｘｔ”  ｎａｍｅ＝“ｆｉｒｓｔｎａｍｅ”  ｖａｌｕｅ＝“”／＞といった入力フィールドが含まれている場合、生成されるオブジェクトは、（ラベル、入力フィールド定義（タイプ、属性名、値））という要素を含む。ここで変数「ラベル」は、ブラウザ上に表示されている入力フィールドの直前にあるテキスト文字列である。ソースコードの中に＜／ｌａｂｅｌ＞のようなテキスト文字列が定義されているような場合、このテキスト文字列は、図４のステップ４１０においてオブジェクトを生成するときにラベルとして使用することができる。このように具体的に定義された「ラベル」がない場合は、表示されている入力フィールドの直前にあるテキスト文字列がオブジェクトを生成するための「ラベル」として使用される。本例では、入力フィールドのタイプは「ｔｅｘｔ」であり、ソースコードの中のその属性名は「ｆｉｒｓｔｎａｍｅ」であり、その値は「ｎｕｌｌ」であるので、入力フィールド定義は、（ｔｅｘｔ，ｆｉｒｓｔｎａｍｅ，ｎｕｌｌ）という形式をとる。パーサーが、入力フィールドに対して、表示されている入力フィールドの直前にあるテキスト文字列としてラベル「ＦｉｒｓｔＮａｍｅ」を見つけたとすると、得られるオブジェクトは、（ＦｉｒｓｔＮａｍｅ：，ｉｎｐｕｔ−ｆｉｅｌｄ−ｄｅｆｉｎｉｔｉｏｎ（ｔｅｘｔ，ｆｉｒｓｔｎａｍｅ，ｎｕｌｌ））という形式をとることになる。
【００７９】
このオブジェクトは、入力フィールドについての情報を表している。入力するフォーム内の入力フィールドごとにこのようなオブジェクトが生成される。１つの実施形態によれば、これらの個々のオブジェクトに基づいてオブジェクト構造が生成される。新しく生成された各オブジェクトは、図４のステップ４２０に示されているように、このオブジェクト構造に登録される。新しく生成されたオブジェクトがこのオブジェクト構造に登録されると、手順はステップ４１０の更なる解析に進む。さらに新しい入力フィールドが見つかった場合、それについてもこのオブジェクト構造に登録される。更なる要素（入力フィールド）が見つからない場合には手順を終了する。
【００８０】
このようにして生成されたオブジェクト構造は、１つの実施形態において、以下に概略的に示されている、解析プロセスの間に生成された個々のオブジェクトのリストを含んでいる。
object 1(label, input-field-definition)
object 2(label, input-field-definition)
・
・
・
object n(label, input-field-definition)
【００８１】
このようなオブジェクト構造は、あるスキーマに基づいて入力フィールドを表現すること、すなわち入力フィールドのラベルと入力フィールド定義により、入力するフォームを表現したものである。従って、入力フィールドを表現するオブジェクトは、構成についての情報と、入力フィールドの意味に関するある程度の情報を表している。情報の表現は、ブラウザによってスクリーン上に表示されているラベルについての情報と、ソースコード内の例えばフィールドの属性名といった入力フィールド定義についての情報とを含む。従って、オブジェクトは入力フィールドを表現したものと見なすことができる。解析プロセスの結果、入力すべきフォーム内の各入力フィールドに関するオブジェクトを含んだオブジェクト構造ができる。
【００８２】
１つの実施形態として、オブジェクト構造内のオブジェクトは、オブジェクト構造内で先行するオブジェクトと、オブジェクト構造内の後続のオブジェクトとのリファレンスを更に含む。このリファレンスは、例えばポインタという形をとることができる。ある入力フィールドについてのルールを評価する際に、そのルールのパラメータが、現在評価されている入力フィールドに実際には属していないものの、先行する入力フィールドまたは後続の入力フィールドに属しているときに、これは役立つ。
【００８３】
このオブジェクト構造は、このようして表現された入力フィールドが同じスキーマに従う所定のルールに基づいているどうかをチェックするために使用することができる。ルールをオブジェクト構造内のオブジェクトまたはオブジェクトの組み合わせと比較すること、言い換えるとそのルール内の所定のパラメータがオブジェクト内の対応する値と適合するかどうかをチェックすることにより、そのルールを評価することができる。
【００８４】
オブジェクトのパラメータは、「ラベル」と入力フィールド定義である。あるルールは、「ラベル」パラメータに対する所定の値から成り、別のルールは、入力フィールド定義パラメータに対する所定の値から成る。ルール内の所定のパラメータに加えて、チェックされている入力フィールドに関して定義されたこのようなパラメータの「ロケーション」もルールの中で定めることができる。ルール内で定義されているパラメータは例えば、先行する入力フィールドと、現在の入力フィールドと、後続の入力フィールドとに関連する場合がある。１つのルールは例えば、このルールによってチェックされる入力フィールドに先行する入力フィールドについての「ラベル」パラメータの値を定めることができる。このように定義されたパラメータが、先行する入力フィールドに関するラベルである「Ｆｉｒｓｔ  Ｎａｍｅ」であると仮定すると、フォーム内のｎ番目の入力フィールドに対するルールの評価は、先行する（ｎ−１番目の）入力フィールドのラベルが「Ｆｉｒｓｔ  Ｎａｍｅ」であるかどうかをチェックするということを意味する。これは、そのルールを上述したオブジェクト構造内の（ｎ−１番目）のオブジェクトと比較することによって実行できる。同様に、（ｎ＋１）番目の入力フィールドに対してルールを評価する場合、オブジェクト構造内のｎ番目のオブジェクトと比較される。
【００８５】
ルール内のパラメータの値（ルールごとに予め定められたもの、本例では「ラベル」に対して「ファーストネーム」）と、オブジェクト構造内の対応するオブジェクトにある対応するパラメータの値とが一致（つまり適合）する場合、そのルールは満たされたと判断する。
【００８６】
このようにして、チェック対象の入力フィールドに関して異なるロケーションにある異なるパラメータ（例えばパラメータ「ラベル」および「入力フィールド定義」）に対してルールを定義することができる。チェックする入力フィールドに先行する入力フィールドと、チェックする入力フィールドと、チェックする入力フィールドの後続の入力フィールドとに対して、パラメータ「ラベル」および「入力フィールド定義」がチェックされるとすれば、これは６つの基本的なルールスキーマをもたらす。
【００８７】
これらルールスキーマのそれぞれに対して、複数のルールを定義することができる。この場合のルールは、このスキーマに従うステートメントまたは「フォーム」である。ここでパラメータは、オブジェクト構造のオブジェクト内でこれらのパラメータがとる値と比較可能な所定の値をとる。このようにしてルール評価を実行することが可能である。
【００８８】
既に言及したこの６つの基本スキーマは単なる例示であって、他のパラメータやパラメータの他のロケーションもルールを定義するために使用することができる。
【００８９】
第４に、入力フィールドが評価される。これについてはこのプロセスが示されている図５を参照して説明する。ステップ５１０において入力フィールドを探す手順が実行される。このステップは、オブジェクト構造を調べることにより実行することができる。なぜなら、このオブジェクト構造は各入力フィールドのオブジェクトを含んでいるからである。オブジェクト構造が見つかると、これは実際に入力フィールドが見つかったことを意味する。続いてステップ５２０において、全てのルールがチェックされ、それによりチェックされた入力フィールドが自動入力可能かどうかを評価する。可能であれば、入力フィールドを入力する。その後、入力フィールドが見つからなくなるまで、次のフィールドを探し、チェックする。ステップ５２０において、入力フィールドに適合する可能性のある全てのルールが選択され、評価される。これについては図６に関連して後で述べる。たいていの場合、入力フィールドに適合する２つ以上のルールが存在する。これは、既に言及した６つの基本スキーマの場合、１つの入力フィールドに対してこの入力フィールドに適合する一部または６つ全てのスキーマに対してルールが存在することを意味する。全てのルールは、ある概念名の値がいかなる頻度（パーセンテージ）で特定のロケーションに見つかるか（言い換えると、このルールに属する結論が正しいと思われる尤度）を表す確率を含む。一例を挙げると、「左側はアドレスを含む」というルールは、様々な確率で住所または電子メールアドレスのような様々な概念名に適合する。ある意味において、ルールが真である尤度は、このルールに含まれている「スコア」であり、そのスコアはルールが真である尤度を表している。
【００９０】
ある入力フィールドに対してあるルールが満たされていることが判明した場合、このルールの確率は、別のスコア（以下、概念ポイントと呼ぶ）に変換される。この変換は、いくつかの特徴、すなわちルールに割り当てられた確率値とそのルールのタイプ（通常ルールか優先ルールか）とを考慮に入れることができる。これは図６に示されている。図中、チェックステップ６００は、通常ルールと尤度１００％を持つ優先ルールとを区別してステップ６１０に進む。
【００９１】
入力フィールドのチェックの際に、ステップ６１０において当該ルールが１００％未満の確率の通常ルールであることがわかった場合、図６のステップ６３０に示されているように、ある概念名に対して見つかった（例えば、このフィールドはアドレスストリートという概念名に適合する）全ての概念ポイントが合計される。ステップ６２０において、チェックされたルールが、まだ概念ポイントが全く累積していない概念名に対応することがわかった場合には、ステップ６４０において、この新しい概念名に対して概念ポイントを累積するための概念ポイントカウンタが生成される。このようにして、対応するルールが満たされていることが判明した全ての概念名に対して、対応する概念ポイントカウンタは概念ポイントを累積する。チェックの最後に、このアルゴリズムは見つかった異なる概念名の間で概念ポイントを比較し、概念ポイントが最も高い概念名が選択される。
【００９２】
１つの実施形態では、異なった取り扱いがなされる２つのタイプの優先ルールが存在する。第１のタイプの優先ルールは、尤度１００％を持つルールである。このルールのパラメータは、現在チェックされている入力フィールドに関連する（かつ先行または後続の入力フィールドには関連しない）。第２のタイプの優先ルールは、１００％未満の尤度を持つルールである。しかし、このルールのパラメータも現在チェックされている入力フィールドに関連する（かつ先行または後続の入力フィールドには関連しない）。このような実施形態では、ルールのパラメータは、一般に入力フィールドのラベルと入力フィールドのソースコード属性である。優先ルールの場合、処理速度を高めるために適用されるとともにモバイル機器の限られたリソース能力を利用する次の２つのケースに分けられる。
【００９３】
１つ目は、１００％の確率を有した、（現在の入力フィールドに関連する）カレントラベルまたはカレントネーム属性に対するルールが、現在の入力フィールドについて満たされていることがわかった場合に、入力フィールドに入力するための概念名を選択するために即座に選ばれる。これは、図６のステップ６６０に示されている。
【００９４】
２つ目は、１００％未満の確率を有した、（現在の入力フィールドに関連する）カレントラベルまたはカレントネーム属性に対するルールが、見つかったその他のルール（つまり、パラメータが、現在チェックされている入力フィールドには関連しないルール）より上位にランクされる。これは、図６のステップ６５０に示されているように、適合することが判明したこのようなルールから導き出された概念ポイントが、その他の（通常の）ルールよりも大きいことを意味する。
【００９５】
既に言及したように、図５は、全ての入力フィールドがフォーム入力アルゴリズムによって解析されることを示している。入力フィールドが見つかった場合、それが入力可能かどうかチェックされる。このチェック手順は、図６に示されており、以下詳しく説明する。
【００９６】
概念名Ｘについてのルールが見出された場合（ステップ６００）、次の２つの可能性が存在する。
【００９７】
１つ目は、確率１００％の優先ルールである。このとき、その入力フィールドに対してそのルールの概念名が即座に選ばれる（ステップ６６０）。１つの実施形態における優先ルールとしては、パラメータが現在チェックされている入力フィールドに関連するルールだけである。
【００９８】
２つ目としては、上記以外の場合にルールの処理を続ける。
ステップ６２０の概念ポイントの管理において、「Ｘ」（結果としてそのルールに属する概念名）は、既存の（ルールの評価により既に一定量の概念ポイントがもたらされている）概念名であるかどうか、または新しい概念名（これまでに適合が全くないもの）であるかどうかがチェックされる。
（ｉ）概念名が存在する場合、概念ポイントが合計される（ステップ６３０）、または、
（ｉｉ）概念名が新しいとき、その新しい概念名Ｘに対する概念ポイントが保存される（ステップ６４０）。
前述したように、概念ポイントを導き出す場合に優先ルールの確率に対してより大きな重み付けを与えることで、確率を概念ポイントへ変換することは、通常ルールと優先ルールとで異なる。全てのルールをチェックした場合、または１００％の確率の優先ルールが全く見つからなかった場合、フィールドには概念ポイントが最も高い概念名に対応するユーザデータが入力される。
【００９９】
第５に、入力済みのウェブページをブラウザに配信する。
【０１００】
第６に、（オプションとして）ユーザが入力済みのフィールドをどのように変更（手作業で編集）するか、またはフォーム自動入力によって提案された入力をどのように確認するかをチェックする。
【０１０１】
第７に、（オプションとして）ルールを更新するか、または新しいルールを生成する。
【０１０２】
以下、ルールの生成および更新の実施形態を説明する。
【０１０３】
既存のフォームの評価に基づいて、所定の一連のルールを生成することができる。ルールサーバにより、モバイル機器はルールリポジトリに格納されたルールセットをダウンロードできる。ダウンロードされたルールは、モバイル機器に保存される。ユーザは、ルールリポジトリから一連の新たなルールをダウンロードすることによってルールを更新することができる。
【０１０４】
より良い質のルールを実現するため、１つの実施形態として、ユーザのアクションに応じてルールを更新する手順が実行される。モバイル機器におけるフォーム入力は、以下の方法でできる。
１つ目は、モバイル機器に行わせることである。ユーザがフォームフィラーによって入力された値を変更するとき、プロキシはローカルに保存されたルールを認識し更新する。
２つ目は、ルールサーバに行わせることである。
変更がルールサーバに送られ、ルールサーバ上のルールを更新する。
【０１０５】
２つ目の選択は、ルールサーバがルールの管理、解析および更新を実行するためのより高いパフォーマンスを有するという利点がある。もう１つの利点は、サーバで行うことによってグローバルなルールセットを拡張し改善することが、ユーザにとって有益であるということである。このようにして、ルールは全てのユーザとの対話によって最適化されるとともに、新たなユーザはその最適化されたルールセットから開始することができる。
【０１０６】
以下、図７を参照してルール変更プロセスの１つの実施形態について説明する。本例では、「アドレス」というラベルを例にして説明する。
【０１０７】
第１に、ユーザは、自動入力されたフォームの値を概念名Ｘの値に変更する（ステップ７００）。
例えば、ウェブページ内に、アドレスというラベルを有する入力フィールドがあるとする。一連のルールに基づいて、その入力フィールドにはユーザの住所が入力されている。しかし、ユーザはその値を変更し、電子メールアドレスを入力する。
【０１０８】
第２に、ユーザのアクションに基づいてルールを生成する（ステップ７１０）。
そのポジションに条件値ｂが存在する場合、概念名＝Ｘである。
例えば、アルゴリズムはこの変更を認識し、「ラベルがアドレスを含んでいる場合、概念名は電子メールアドレスに等しい」というルールを生成する。
【０１０９】
第３に、新しいルールを保存する（ステップ７２０）か、または既存のルールを編集もしくは自動的に修正する（ステップ７３０）。
第３−１．このようなルールが既に存在する場合、その確率を変更する。
例えば、「ラベルがアドレスを含んでいる場合、概念名は電子メールアドレスに等しい」というルールが既に存在しているので、このルールの確率を増加させる。
第３−２．そのルールが新しい場合、それを保存するだけである。
例えば、そのルールはルールセットに保存される。
【０１１０】
第４に、生成されたルールと比較して概念名だけ異なっている全てのルールの確率を減少させる（ステップ７４０）。
そのポジションに条件値ｂが存在する場合、概念名はＸではない。
例えば、「左側がアドレスを含んでいる場合、概念名は電子メールアドレスではない」という全てのルールの確率を減少させる。
【０１１１】
次に、図１を参照しながら説明したアーキテクチャ案の拡張に関係した実施形態について説明する。このアーキテクチャは、図８に概略的に示されている。これは、リクエストされたフォームをモバイル機器に送る前に事前に処理する変換サーバを含んでいる。ユーザデータは、ローカルでのみ入力するため、モバイル機器に保存されたままである。
【０１１２】
基本的なアイデアは、モバイル機器とウェブサーバとの間に外部の変換サーバを置くことである。携帯電話機にインストールされたプロキシは、このサーバのアドレスを認識しており、全てのウェブページリクエストを転送する。変換サーバはウェブページをダウンロードし、モバイル機器のプロキシに送るためによりシンプルなバージョンに変換する。変換とは、（ｉ）ウェブサイトが解析され、オブジェクト構造が生成される（図４を参照して既に説明した）、（ｉｉ）入力フィールドに関してルールのチェックが実行される（図５および図６を参照して説明した）、（ｉｉｉ）全ての入力フィールドに対してプレースホルダ値が加えられる、ということである。これは、図９に概略的に示されている。これらプレースホルダ値は、モバイル機器が具体的なユーザの個人データを入力するために使用する概念名である。
【０１１３】
図８に戻り、変換サーバのアーキテクチャを説明する。これは、ルールインスペクタ、ＨＴＭＬパーサーおよびルールとから構成されている。このルールは、図１に関連して説明した実施形態にあるように携帯電話機のプロキシに保存されているのではなく、変換サーバに保存されている。この場合のモバイル機器のプロキシは、オブジェクト生成または実際のルールチェックは行わずにユーザデータフィラーを通じてユーザデータを入力するためにＨＴＭＬパーサーをサポートするだけである。
【０１１４】
一部のタスクを外部の変換サーバにアウトソーシングすると、いくつかの利点が得られる。このアプローチの利点の一つは、フォーム入力において最も処理電力を必要とする部分（パーサーを通じたオブジェクト生成とルールインスペクタ）が変換サーバに移されているということである。これによりモバイル機器におけるフォームフィラーの処理時間が短縮する。というのは、プロキシは、概念名をユーザプロファイル（ユーザデータ）に対応する具体的な値で置き換えるだけよいからである。変換後のＨＴＭＬドキュメントに対する単純な解析作業と、プレースホルダ値を具体的なユーザデータで置き換えることにより、この置換を行うことができる。
【０１１５】
このアーキテクチャは、ユーザデータをモバイル機器でローカルに取り扱うことによって個人情報も保護する。
【０１１６】
ルールは、モバイル機器には保存されていない。これによりモバイル機器のメモリが節約できるだけでなく、（図７に関連して説明したように）ルールの拡張または修正をより容易に行うことができる。
【０１１７】
変換サーバをアーキテクチャに含めることで、モバイル機器のフォーム入力の効率を大きく上げる。なぜなら、処理電力の大部分を必要とし、処理時間の大部分を占めるルールチェックがサーバで行われるからである。
【０１１８】
次に、フォームを自動的に入力するための手順と関連して使用する、最初に用いる一連のルールの生成に関係する実施形態について説明する。
【０１１９】
フォーム自動入力は、既に提供されている基本的な一連のルールから開始する。これら基本的なルールは、フォームを含んだ大量のウェブページを最初に解析することにより生成することができる。代表的な一連のルールを生成するため、十分な量のウェブフォームを使用する必要がある。
【０１２０】
このような大量のフォームを見つけるため、ウェブフォームを見つけ出すための、例えばグーグルといった検索エンジンに様々な検索式を入力することができる。次に、検索結果に含まれているウェブフォームを自動的にダウンロードするために（例えばＷｇｅｔといった）ダウンロードソフトウェアを使用できる。
【０１２１】
実行されるプロセスは、二段階になっている。第１の部分は手作業で実行する必要があり、第２の部分は完全に自動化できる。
【０１２２】
最初に、ウェブフォームを調べ、それらの入力フィールドの意味を見つけ出す必要がある。最初にルールを生成するため、ウェブフォーム内の各入力フィールドの概念名を見つけ出す必要がある。この作業は、ダウンロードされたウェブフォームを解析し、各概念名について対応するネーム属性のリストを生成することによって行うことができる。ネーム属性とは、入力フィールドがＨＴＭＬソースコード内でどのように参照されているかを示すＨＴＭＬソースコードの一部である。例えば、「ファーストネーム」という（ユーザデータの中のユーザのファーストネームを特定する）概念名に対するリストは、「ｆｉｒｓｔｎａｍｅ」、「ｎａｍｅ」および「ｇｉｖｅｎ  ｎａｍｅ」といったネーム属性を含む。このプロセスにより、最終的に概念名ごとのリストが得られる。各リストは利用可能なネーム属性またはラベルを含んでいる。次のステップにおいて、このようなリストは、自動的にルールを生成する際に入力フィールドをその概念名と比較するために必要となる。
【０１２３】
次に、自動化されたルール生成プロセスについて説明する。１つの実施形態では、２つのステップから成る。これは、（本発明の実施形態に関連して説明した他の手順のように）コンピュータプログラム、例えばＪａｖａ（登録商標）で記述されたプログラムによって実行することができる。
【０１２４】
最初のステップにおいて、ウェブフォームを単純化したバージョンが生成される。この手順について図１０を参照しながら概略的に説明する。まず、全てのウェブページが最初に解析され（ステップ１０００）、テキストファイルに変換される（ステップ１０１０）。変換されたテキストファイルにおいて、フォームの各入力フィールドは、後でルール生成にも関連する、その入力フィールドについて関連のある部分またはパラメータを表すシンプルなフォーマットまたはパターンによって表されている。このようなフォーマット、パターンまたはテンプレートは、次のような形をとることができる。ただし、このスキーマに適合せずそれゆえ入力フィールドに関連がないものと見なされた、フォーム内の全ての他の部分は無視される。すなわち、
Label, input(NameAttribute, length, type, value)
【０１２５】
ここでラベルは、ウェブフォームの解析の際に、ソースコード内で入力フィールドの直前に見出されるテキスト文字列である。これは、入力フィールドのラベルとしてどのデータを挿入するべきかをユーザに示すために、ブラウザが表示する文字列である。他方、ネーム属性、長さ、タイプおよび値は、フォームのＨＴＭＬソースコード内で定義された入力フィールドの現在の属性である。ここで、値は、ユーザの入力により上書きされるまで入力フィールドの内容としてブラウザにより表示される入力フィールドの所定の値である。通常、この値は、ウェブフォームに「あなたの電子メールアドレスをここに入力して下さい」というようなテキストで既に入力されているときを除けば、ヌルである。
【０１２６】
次に入力フィールドの一例を紹介する。これは、単純化したバージョンのフォームを生成するためのプロセスによって生成されたテキストファイル内に次のような形で現れる。すなわち、
FirstName, input(FName, 30, text, please enter your first name)
【０１２７】
解析に関する第２の部分は、既に説明したステップで生成されたテキストファイルと、既に説明したようにサンプルのウェブページを手作業で調べた結果として生成された概念名に対応する属性を含んだリスト（以後、概念名リストと呼ぶ）とを使ってルールを生成するステップで構成されている。この手順を図１１および図１２のフローチャートを参照して概略的に説明する。
【０１２８】
最初に図１２を参照する。既に言及したように、テキストファイルはサンプルの入力フォームごとに生成されており（ステップ１２３０）、その結果テキストファイルのサンプル１２４０が得られる。さらに、既に説明したように手作業で概念名リストを生成する（ステップ１２００）ことによって、概念名（後でルールの結論を形成する用語）が入力フォームのソースコードで表された、概念名ごとにネーム属性のリストを含んだリスト１２２０が生成される。後で詳細に説明する方法により、これら２つのリストを比較することによって、基本的なルールセット１２６０を自動生成できる（ステップ１２５０）。このため、概念名リスト１２１０に含まれているネーム属性は、入力フォームの入力フィールドを表すテキストのリスト１２３０内のネーム属性と比較される。適合が見つかった場合、これはリスト１２３０内のネーム属性は、そのネーム属性が属するリスト１２１０内の対応する概念名を表していることを意味する。これは、この対応が、ネーム属性と、結論として概念名とを有するルールを生成するための条件として実際に使用できることを意味する。ネーム属性だけが使用されるのではなく、２つのリストを比較したときに適合が見出されたその入力フィールドに属するラベルも使用する場合、条件としてそのラベルと、結論としてその概念名とを有する更なるルールを生成できる。
【０１２９】
以下、ルール生成の一実施形態について図１１を参照しながら詳細に説明する。
【０１３０】
テキストファイル内の各入力フィールドをそれぞれ表現したもののネーム属性は、概念名リスト内のネーム属性と比較される（ステップ１１１０）。このとき入力フィールドの表現と適合する概念名が見出される可能性がある。適合が見つかった場合、これはルールを生成するために使用される。
【０１３１】
概念名（または対応するネーム属性）がテキストファイル内の入力フィールドの表現に見出されたとき、１つ以上のプレルールまたは「暫定ルール」がその入力フィールドから生成される（ステップ１１１０）。１つの実施形態として、１つの入力フィールドに対して２個〜６個のプレルールが生成できる。このルールは、結論ではなく条件が異なっており、その結論は適合が見つかった概念名である。条件は、適合が見つかった際に行われていた比較の対象である入力フィールドの属性名であるか、またはこのフィールドのラベルである。代わりに、適合が見つかったフィールドに先行するフィールドまたは後続のフィールドのラベルまたはネーム属性を使用して、ルールを生成することもできる。この場合には、ルールは、そのルールに使用されているラベルまたはネーム属性のパラメータ値に加えて、入力フィールドに関するパラメータのロケーションの表現（カレントフィールド、先行するフィールド、後続のフィールド）を条件の中に含んでいなくてはならない。これら３つのロケーションと、パラメータとしてラベルおよびネーム属性とに基づいて最大で６個のプレルールを、１つの入力フィールドに対する２つのリストの比較に基づいて生成することができる。
【０１３２】
このようして生成されたプレルールは、以前の実施形態に関連して既に説明したようにルール自体から成る。すなわち、条件（ここでは条件として入力フィールドのラベルまたはネーム属性（可能ならロケーションの表現も）と、ルールの結論である概念名）である。しかしながら、割り当てられた固定の確率はまだなく、その代わりにプレルールの発生頻度を考慮またはカウントするカウンタを有する。
【０１３３】
以下、このようなプレルール（ロケーションの表現はない）の一例を紹介する。
「入力フィールドのラベルがネームである場合、概念名はファーストネームであり、カウンタ＝８である」
【０１３４】
次に、生成されたプレルールは、同じ条件と同じ結論、すなわちラベルについての同じパラメータ値と同じ概念名とを有するプレルールが、既に存在しているかをチェックする（ステップ１１２０）。該当する場合、このプレルールに対応するカウンタを増加させる（ステップ１１３０）。このようなプレルールがまだ生成されていない場合は、生成される（ステップ１１４０）。
【０１３５】
このようにして、あるパターン（すなわち条件としてのパラメータ値と、結論としての概念名との組み合わせ）が含まれているかどうかをチェックすることにより、入力フォームの大量のサンプルを自動的に解析できる。続いて、このようなパターンごとに対応するルールが生成される。入力フォームの統計的に代表となるサンプルを解析することにより、このように生成されたルールは、どの概念名がどの条件でどういった確率で見つかるかについての重要な情報を含んでいる。
【０１３６】
これは、全てのテキストファイルを解析した後に、概念名が異なることを除けば条件が同じプレルールが存在することを意味する。これらのプレルールは、確率を求めるために全て合計される（ステップ１１００）。例えば、概念名が異なることを除けば前記ルールと条件が同じプレルールは、以下のようになる。
「入力フィールドのラベルがネームである場合、概念名はラストネームであり、カウンタ＝２である」
【０１３７】
同じ条件に適合するプレルールが他に見つからなければ、各ルールの確率を求めるためにカウンタを互いに比較する。既に言及した例では、条件が同じプレルールは（ファーストネームのカウンタとラストネームのカウンタとを加えた）１０回見つかっている。これは、概念名がファーストネームである確率は８０％（１０回のうち８回）であることと、概念名がラストネームである確率は２０％（１０回のうち２回）であることとを意味する（ステップ１１６０）。このように導き出された確率を個々のルールに割り当てることにより、既に説明したようにこれらの確率を含む最終的なルールが生成される（ステップ１１７０）。
【０１３８】
１つの実施形態として、確率についての閾値パラメータが存在する。ルールの確率がある閾値未満である場合このルールはスキップされ、基本的なルールセットには含まれない。構成されたプロトタイプの場合、閾値は８％に設定した。これにより最終的に１４４個のルールから成る基本的な一連のルールが得られる。
【０１３９】
１つの実施形態として、基本的なルールから始めないことも可能であるということに注意しなければならない。というのは、ルールは、上述の形態に関連して既に説明したようにフォームフィラーを使用してルールリポジトリを更新することにより自動的に生成できるからである。しかしながら、所定の一連のルールから始めれば、ユーザは開始直後からより良いフォーム自動入力結果を得ることができる。
【０１４０】
当業者にとって変更可能な、典型的な実施形態を用いて、本発明を詳しく説明してきたことに言及しておかなくてはならない。例えば、フォーム入力モジュールをプロキシの代わりにブラウザまたは携帯電話機自体のコンポーネントとして実装することが可能である。さらに、フォーム自動入力モジュールは、インターネットなどのコンピュータネットワークを通じてモバイル機器または場合によってはスタンドアロンコンピュータによってアクセスできるポータルに実装することができる。または、受容性を改善し、この特徴を利用するためのハードルを最低限に抑えるため、フォーム入力は、ユーザがダウンロードする時間を節約するために携帯電話機のデフォルト機能として実装することができる。さらに、ウェブフォームにアクセスするときにこの機能をダウンロードすることを考慮する必要がなくなる。
【０１４１】
当業者であれば、上述した実施形態およびそれらのコンポーネント、プロセスまたはモジュールは、ハードウェア、ソフトウェアまたはそれらの組み合わせによって実現できることは理解されよう。特に、上記説明した手順を実行するモジュールは、コンピュータ、携帯電話機、スマートフォン、スタンドアロンＰＣ、ＰＤＡなどの他の任意の計算機で実行できる１つ以上のコンピュータプログラムによって実現可能である。
【図面の簡単な説明】
【０１４２】
【図１】本発明の実施の一形態による装置の構成図である。
【図２】本発明の別の実施形態による装置の構成図である。
【図３】入力フォームとそのＨＴＭＬ表現を示した図である。
【図４】本発明の一実施形態による手順を示す図である。
【図５】本発明の別の実施形態による手順を示す図である。
【図６】本発明の別の実施形態による手順を示す図である。
【図７】本発明の別の実施形態による手順を示す図である。
【図８】本発明の別の実施形態による装置の構成図である。
【図９】本発明の別の実施形態によるオペレーションを示した図である。
【図１０】本発明の別の実施形態による手順を示す図である。
【図１１】本発明の別の実施形態による手順を示す図である。
【図１２】本発明の別の実施形態による手順を示す図である。
【図１】
2007183916.tif 000004
【図２】
2007183916.tif 000005
【図３】
2007183916.tif 000006
【図４】
2007183916.tif 000007
【図５】
2007183916.tif 000008
【図６】
2007183916.tif 000009
【図７】
2007183916.tif 000010
【図８】
2007183916.tif 000011
【図９】
2007183916.tif 000012
【図１０】
2007183916.tif 000013
【図１１】
2007183916.tif 000014
【図１２】
2007183916.tif 000015
【外国語明細書】
2007183916.tif 000016
2007183916.tif 000017
2007183916.tif 000018
2007183916.tif 000019
2007183916.tif 000020
2007183916.tif 000021
2007183916.tif 000022
2007183916.tif 000023
2007183916.tif 000024
2007183916.tif 000025
2007183916.tif 000026
2007183916.tif 000027
2007183916.tif 000028
2007183916.tif 000029
2007183916.tif 000030
2007183916.tif 000031
2007183916.tif 000032
2007183916.tif 000033
2007183916.tif 000034
2007183916.tif 000035
2007183916.tif 000036
2007183916.tif 000037
2007183916.tif 000038
2007183916.tif 000039
2007183916.tif 000040
2007183916.tif 000041
2007183916.tif 000042
2007183916.tif 000043
2007183916.tif 000044
2007183916.tif 000045
2007183916.tif 000046
2007183916.tif 000047
2007183916.tif 000048
2007183916.tif 000049
2007183916.tif 000050
2007183916.tif 000051
2007183916.tif 000052
2007183916.tif 000053
2007183916.tif 000054
2007183916.tif 000055
2007183916.tif 000056
2007183916.tif 000057
2007183916.tif 000058
2007183916.tif 000059
2007183916.tif 000060
2007183916.tif 000061
2007183916.tif 000062
2007183916.tif 000063