(57)【要約】【課題】  日本語ウェブサイトの複雑な入力フォームにも対応するモバイル機器用の自動フォーム記入装置を提供する。【解決手段】  パーサーはフォームを解析して入力フィールドのグループを検出し、このグループのオブジェクトを生成する。グループルール検査モジュールは、ルールリポジトリ内のグループルールを前記オブジェクトと照合することによって前記グループに対応するグループ概念名を特定し、それにより前記グループの入力フィールドに対応する内部概念名の集合を特定する。内部ルール検査モジュールは、ルールリポジトリ内の内部ルールを前記オブジェクトと照合することによって、前記１セットの内部概念名によって前記グループに属する入力フィールドが記入される順序を特定する。記入モジュールは、前記グループに属する入力フィールドを前記内部概念名に対応する値を用いて前記順序に従って自動記入する。【選択図】  図６
2008077634.tif 000002
【特許請求の範囲】
【請求項１】
モバイル機器上においてウェブベースのフォームを自動記入するための装置であって、
ウェブベースのフォームを解析して、入力フィールドグループを検出するとともに、この入力フィールドグループを、このグループに属する入力フィールドの近傍を記述または画定する１つ以上のパラメータによって表現するオブジェクトを生成する入力グループ認識モジュールと、
チェックされる条件とそれに対応する引き出される結論とを各ルールが含む複数のルールを含み、複数のグループルールと複数の内部ルールとを含むルールリポジトリであって、前記複数のグループルールにおいては、ルールが満たされることが判った場合に引き出される結論は、前記入力フィールドグループの区別できる語義上の意味に対応し、前記入力フィールドグループに属するフィールドに記入される値として内部概念名の集合を特定するグループ概念名であり、前記複数の内部ルールにおいては、各ルールがチェックされる条件とそれに対応する引き出される結論とを含み、その結論は、前記入力フィールドグループに属している入力フィールドに記入するために内部概念名が使用される順序に対応するものとなる、ルールリポジトリと、
前記グループルールを前記入力フィールドグループを表現する前記オブジェクトと照合することによって前記グループルールを評価して、前記入力フィールドグループに対応するグループ概念名を特定し、それにより前記入力フィールドグループに属する入力フィールドに記入するために使用されるべき内部概念名の集合を特定するグループルール検査モジュールと、
前記内部ルールを前記入力フィールドグループを表現する前記オブジェクトと照合することによって前記内部ルールを評価して、前記グループルール検査モジュールにより特定された前記グループ概念名に対応する前記内部概念名の集合によって、前記入力フィールドグループに属する入力フィールドが記入されるべき順序を特定する内部ルール検査モジュールと、
前記入力フィールドグループに属する入力フィールドを、前記内部概念名に対応する値を用いて前記内部ルール検査モジュールが決定した順序に従って自動記入するためのユーザデータ記入モジュールと
を具備するフォーム自動記入装置。
【請求項２】
グループルールは、前記入力フィールドグループに属する入力フィールドの前記近傍内に現れる複数のパラメータを含んでおり、前記複数のパラメータは、前記グループルールが満たされる場合には前記入力フィールドグループに属する入力フィールドの前記近傍内に存在する必要があるものである、請求項１に記載のフォーム自動記入装置。
【請求項３】
内部ルールは、
前記入力フィールドグループに属する入力フィールドの前記近傍内に現れるパラメータの順序、または、
前記入力フィールドグループに属する入力フィールドの数
を含む、請求項１または２に記載のフォーム自動記入装置。
【請求項４】
前記入力グループ認識モジュールは、
開始境界と終了境界をチェックして、入力グループをこれらの境界内に存在するウェブベースのフォームの要素として決定するためのモジュールを含む、請求項１乃至３のいずれか１項に記載のフォーム自動記入装置。
【請求項５】
前記境界は、
新たなラインタグまたはテーブルタグ、
テーブルの行の始点を指定するタグ、
テーブルの行の終点を指定するタグ、
行の上部境界を指定する座標値、
行の下部境界を指定する座標値、
行の右側境界を指定する座標値、
行の左側境界を指定する座標値、
の少なくとも１つ以上で画定される、請求項４に記載のフォーム自動記入装置。
【請求項６】
前記入力グループ認識モジュールは、
複数の入力グループ候補をそれらの１つ以上の候補が１つの拡張された入力グループに組み合わせられるかどうかに関して評価するためのモジュールを含み、このモジュールは、
入力グループ候補が１つ以上のグループルールと部分的にマッチするかどうかをチェックし、
部分的なマッチが検出された場合には、今度は他の入力グループ候補について、部分的なマッチが見つかったグループルールの他の部分とが部分的にマッチするかどうかをチェックし、
斯かるチェックを、あるグループルールが前記部分的なマッチによって累積的に全面的にマッチするまで、更なる入力グループ候補について繰り返し、
斯かる全面的なマッチに到達した場合には、斯かる全面的なマッチに寄与した候補の入力グループを単一の拡張された入力グループに組み合わせるためのモジュールを含む、請求項１乃至５のいずれか１項に記載のフォーム自動記入装置。
【請求項７】
前記候補の入力グループが単一の入力フィールドのみから成る請求項１乃至６のいずれか１項に記載のフォーム自動記入装置。
【請求項８】
前記入力グループ認識モジュールは、
入力フォームの要素の座標を決定するためのレアウト・インタプリタ・モジュールと、
入力フォームの要素の座標を考慮する１つ以上のレイアウトルールに基づいてどの要素が入力グループを形成するために組み合わされるべきかを判定するレイアウト・ルール・モジュールとを含む、請求項１乃至７のいずれか１項に記載のフォーム自動記入装置。
【請求項９】
前記レイアウト・ルール・モジュールは、水平方向および／または垂直方向における要素の位置に対する１つ以上の閾値を前記判定の基礎として、それらの要素が入力グループに組み合わされるべきかどうかを決定する、請求項８に記載のフォーム自動記入装置。
【請求項１０】
入力グループの要素は水平方向の座標境界に基づいて決定され、
垂直方向の座標に基づいて入力グループのある要素が複数の入力グループに対するラベルになることが判った場合、これらの複数の入力グループは１つの拡張された入力グループに組み合わされる、請求項１乃至９のいずれか１項に記載のフォーム自動記入装置。
【請求項１１】
前記グループルールは、前記グループルールに規定された複数の区別できるラベルを含むことが満たされるよう入力グループに対して要求する形をとり、前記複数のラベルは前記入力グループの任意の位置に存在して構わないものである、請求項１乃至９のいずれか１項に記載のフォーム自動記入装置。
【請求項１２】
グループルールおよび／または内部ルールはそれぞれの関連するスコアを含み、
スコアが１００％未満の確率を示す複数のルールが入力グループとマッチする場合には、異なる概念名のコンセプトポイントが個別に足し上げられ、最高のスコアを有する概念名が選択される、請求項１乃至１１のいずれか１項に記載のフォーム自動記入装置。
【請求項１３】
入力グループはオブジェクト構造によって表現され、グループルールの評価はそのグループルールが前記入力グループに対応するオブジェクト構造とマッチするかどうかをチェックすることにある、請求項１乃至１２のいずれか１項に記載のフォーム自動記入装置。
【請求項１４】
モバイル機器上においてウェブベースのフォームを自動記入するための方法であって、
ウェブベースのフォームを解析して、入力フィールドグループを検出するとともに、この入力フィールドグループを、このグループに属する入力フィールドの近傍を記述または画定する１つ以上のパラメータによって表現するオブジェクトを生成する入力グループ認識ステップと、
チェックされる条件とそれに対応する引き出される結論とを各ルールが含む複数のルールを含み、複数のグループルールと複数の内部ルールとを含むルールリポジトリであって、前記複数のグループルールにおいては、ルールが満たされることが判った場合に引き出される結論は、前記入力フィールドグループの区別できる語義上の意味に対応し、前記入力フィールドグループに属するフィールドに記入される値として内部概念名の集合を特定するグループ概念名であり、前記複数の内部ルールにおいては、各ルールがチェックされる条件とそれに対応する引き出される結論とを含み、その結論は、前記入力フィールドグループに属している入力フィールドに記入するために内部概念名が使用される順序に対応するものとなる、ルールリポジトリを提供するステップと、
前記グループルールを前記入力フィールドグループを表現する前記オブジェクトと照合することによって前記グループルールを評価して、前記入力フィールドグループに対応するグループ概念名を特定し、それにより前記入力フィールドグループに属する入力フィールドに記入するために使用されるべき内部概念名の集合を特定するグループルール検査ステップと、
前記内部ルールを前記入力フィールドグループを表現する前記オブジェクトと照合することによって前記内部ルールを評価して、前記グループルール検査ステップにより特定された前記グループ概念名に対応する前記内部概念名の集合によって、前記入力フィールドグループに属する入力フィールドが記入されるべき順序を特定する内部ルール検査ステップと、
前記入力フィールドグループに属する入力フィールドを、前記内部概念名に対応する値を用いて前記内部ルール検査ステップで決定された順序に従って自動記入するユーザデータ記入ステップと
から構成されるフォーム自動記入方法。
【請求項１５】
請求項１乃至１３のいずれか１項に記載された装置によって実行される方法ステップを更に含む請求項１４に記載のフォーム自動記入方法。
【請求項１６】
コンピュータ上で実行されるときにこのコンピュータが請求項１乃至１３のいずれか１項に記載された装置によって実行される方法ステップを実行することを可能にするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、特にモバイル機器において、入力フォームを自動記入するための方法および装置に関する。
【背景技術】
【０００２】
フォーム自動記入技術に関しては、ある手法が欧州特許出願第０５１０９７５３．３号明細書に提案されている。本願実施形態はこの欧州特許出願と関連しており、しかも「概念名（concept name）」および「ルール（rule）」などの類似の手法を一部利用するため、この欧州特許出願の手法について、以下、手短に説明する。
【０００３】
欧州特許出願第０５１０９７５３．３号明細書で提案されたフォーム記入方法では、ルールは、値（value）（例えば文字列、数字など）と、解析中の入力フィールドに関するその位置（その入力フィールドとの位置関係）とから成る。ルールが満たされるということは、そのルールによって定められた解析中の入力フィールドに関する位置にそのルールによって定められた値が見つかるということを意味する。ルールが満たされると、このルールに対応しフォームの当該入力フィールドに記入するために使用される所定の概念名（Concept Name）が結果としてもたらされる。あらゆるルールは、自動フォーム記入のための多量のオンラインで利用可能なフォームの評価に基づいて、それ自身の所定の確率（入力フィールドがこのルールに対応する概念名（Concept Name）によって実際に記入される確率）も更に含む。このことは、あらゆるルールの確率またはスコアが事前に定められ、入力フィールドチェックの際に計算される必要がないこと、そして、このためモバイル機器においてＣＰＵ時間が節約されることを意味する。フォームフィラー（form filler）はどのルールが議論している入力フィールドにフィットするかをチェックしさえすればよい。
【０００４】
チェック結果に基づいて、フォームフィラー（form filler）はマッチしたルールに従ってユーザデータを使用し、フォームにそのユーザデータを記入する。斯かる目的のため、例えばユーザデータを格納するデータ構造において、ユーザのファーストネーム（first name）に対するFirstNameのようないくつかの概念名（concept names）が、対応するユーザデータを特定するために定義されなければならない。概念名（concept names）は入力フィールドに記入するためのユーザデータと対応付けるために使用される。詳細については、これらの開示内容のすべてが引用することによって本発明の一部をなすものとする欧州特許出願第０５１０９７５３．３号明細書を参照されたい。
【０００５】
フォーム記入ルールを生成するため、ウェブページ上の既存のフォームを解析することができる。同じく詳細については、開示内容のすべてが引用することによって本発明の一部をなすものとする欧州特許出願第０５１０９７５３．３号明細書を参照されたい。
【０００６】
しかしながら、斯かる解析を実行すると、要求された概念名（concept names）とフォーム内おける入力フィールドの配置との間に多くの類似点が存在することがわかる。このため、ファーストネーム（FirstName）としてラベルされた入力フィールドにユーザデータのファーストネーム（first name）が記入される確率は極めて高い。単なる所見としてここでは、ユーザのファーストネーム（first name）から成るユーザデータは例えば概念名（すなわち、対応するユーザデータの内部的なラベリング）であるFirstNameまたはユーザのファーストネーム（first name）の概念名（concept name）として使用される何か他の識別子に対応する場合があるということに言及しておきたい。
【０００７】
さらに、入力フィールドのコンテクスト（context）も重要になり得る。コンテクストとはここでは、この具体的な入力フィールドがどのように定義されているか（例えば、ＨＴＭＬ記述または他の「ソースコード」記述によって）、そしてその入力フィールドの周りにどのテキストまたは他のフォーム要素が存在しているかを意味している。例えば、１つのフォームの中でファーストネーム（first name）の後にラストネーム（last name）が要求される確率がある一定程度存在する。
【０００８】
ルールの集合を、図１に示すような自動フォーム記入装置に保存することができる。
【０００９】
ここで言うところのルールは、チェックされるべき条件（condition）と、その条件が満たされることがわかった場合に引き出される結論（conclusion）とを規定するものと見なすことができる。ルールの条件は、ある特定のパラメータ、例えば入力フォームを指定するＨＴＭＬ文書のある特定の部分が、その条件が満たされていると見なすべき場合にはある特定の値をとらなければならない、ということを定めるものでよい。斯かるパラメータは例えば、入力フィールドのラベル（label）である場合がある。入力フィールドのラベル（label）とは例えば、ブラウザ上の入力フィールドの直前に表示されるテキスト文字列である。別のパラメータとしては入力フォームのソースコード表現における入力フィールドの名前属性あるいはName属性（NameAttribute）が挙げられる。
【００１０】
ルールの結論は、条件が満たされることがわかった場合に入力フィールドに挿入されるべき値（value）である場合がある。以下の記述では、この結論のことをしばしば概念名（concept name）と呼ぶ。概念名とは、特定の事前に定められたユーザデータ、例えば名（first name）、姓（surname）、誕生日、年齢など、を識別するものと理解されるべきものである。ある特定の概念名（ConceptName）は１つの特定のタイプのユーザデータに対する識別子である。
【００１１】
以上の説明から、ルールの一般的な表現は次のようなものである。
【００１２】
パラメータ値（Parameter value）−概念名（ConceptName）
斯かるルールはある特定の入力フィールドに適用することができる。このことはルールが適用されるこの入力フィールドに対して入力フォームにおけるこのフィールドのパラメータがそのルールに定められたパラメータ値をとっているかどうかがチェックされることを意味する。定められたパラメータ値がとられている場合、条件がマッチし、結論を引き出すことが可能である。これが意味するところは、このようにしてチェックされた入力フィールドはそのルールに定められた概念名（ConceptName）により識別されるユーザデータを使用して記入されるべきことをそのルールが示した、という点である。
【００１３】
既に言及したように、１つの実施形態として、ルールを生成するために異なるパラメータ、例えば入力フィールドのラベルとその名前属性（NameAttribute）が使用されることがある。さらに、これらのパラメータはそのルールが適用される入力フィールドに関係している必要はないが、そのルールが適用される入力フィールドと比べて（例えば１つ前（上）または１つ後（下）にある入力フィールドといった）異なる入力フィールドのパラメータに関係している場合がある。このことは１つの実施形態としてルールのパラメータになり得る次のような６つのパラメータをもたらす。
Upper LABEL：１つ上の入力フィールドの前の最後のテキスト
Upper NAME_ATTRIBUTE_VALUE：１つ上の入力フィールドの名前属性の値
Current LABEL：現在の入力フィールド（そのルールが適用される実際の入力フィールド）の前の最後のテキスト
CURRENT NAME_ATTRIBUTE_VALUE：現在の入力フィールドの名前属性の値
Lower LABEL：１つ下の入力フィールドの前の最後のテキスト
Lower NAME_ATTRIBUTE_VALUE：１つ下の入力フィールドの名前属性の値
【００１４】
Upperとはルールが適用される現在の入力フィールドより前にＨＴＭＬ文書の中に最後に見出される１つ前の入力フィールドを指す。Lowerとはルールが適用される現在の入力フィールドより後にＨＴＭＬ文書の中に最初に見出される１つ後の入力フィールドを指す。本例では、ルールはパラメータに加えて現在チェックされている入力フィールド（そのルールが適用される入力フィールド）に関するそのパラメータの位置表示を含むことがわかる。
【００１５】
１つの実施形態として、各ルールは、条件が満たされた場合にその結論が実際に起こる尤度（likelihood）を示すスコアを更に割り当てている。このスコアは１つの実施形態では実際に、結論が正しい尤度である場合がある。尤度は既存の入力フォームの統計的評価から導き出されることがある。それは後述されるように更に動的に更新される場合がある。
【００１６】
１つの実施形態として、ルールリポジトリ（rule repository）は以下の構文（syntax）またはスキーマ（schema）に従うルールを格納するものである。
パラメータ（Parameter）｜オペレータ（Operator）｜値（Value）｜概念名（ConceptName）｜スコア（Score）
ここで、
パラメータ（Parameter）＝｛UPPER_LABEL、UPPER_NAME_ATTRIBUTE_VALUE、CURRENT_LABEL、CURRENT_NAME_ATTRIBUTE_VALUE、LOWER_LABEL、LOWER_NAME_ATTRIBUTE_VALUE｝
オペレータ（Operator）＝｛CONTAINS、EQUALS｝
値（Value）＝任意の文字列、例えば、ラベルタグ、フォーム直前の文字列、フォームの名前属性、言い換えるとパラメータがとる値
概念名（Concept Name）＝ユーザデータ（フォームに記入するために使用される）の要素、例えばFirstNameなど
確率（Probability）＝尤度を表す０から１００までの数字
＜パラメータ（Parameter）｜オペレータ（Operator）｜値（Value）＞部分はルールの条件を構成する。
【００１７】
パラメータ（Parameter）が、オペレータ（Operator）が規定する値（Value）と関係がある場合、その条件は満たされる。そして、このルールが適用されている入力フィールドに概念名（concept name）yが記入されなければならないという確率（Probability）をスコア（Score）により示して結論が引き出されることがある。
【００１８】
言い換えると、上で定義したルールは以下の要素から成る。
ａ）チェックされる条件（すなわち、解析されている入力フィールドに関するある特定の位置に、ある特定の値が存在している）。この条件はルールの中ではパラメータ（Parameter）｜オペレータ（Operator）｜値（Value）部分によって表される。値（Value）はある特定の変数が採る値を指す場合がある。変数は例えば、フォームに含まれており入力フィールドをラベルするラベル（label）である場合がある、あるいはそれ（変数）はフォームのソースコードの中で入力フィールドの名前を実際に指すラベル（label）である場合がある。この種のラベルは既に上で示した文字列で言えばNAME_ATTRIBUTE_VALUEである。
ｂ）このルールに特有の概念名（concept name）およびこのルールに対応する概念名（concept name）がフォームへの記入に使用されるユーザデータを識別する確率（probability）
【００１９】
次にルールのいくつかの例をそれらの意味の説明と一緒に列挙する。
−CURRENT_NAME_ATTRIBUTE_VALUE｜CONTAINS｜firstname｜ファーストネーム（FirstName）｜１００
入力フィールドの名前属性（CONCEPT_VALUE）がfirstnameを含む（CONTAINS）場合、入力フィールドにユーザのファーストネーム（FirstName）が記入されるべき確率は１００％である。
−UPPER_NAME_ATTRIBUTE_VALUE｜CONTAINS｜firstname｜ラストネーム（LastName）｜８１
現在の入力フィールドの１つ上にある入力フィールドの名前属性（UPPER_CONCEPT_VALUE）がfirstnameを含む（CONTAINS）場合、現在の入力フィールドにユーザのラストネーム（LastName）が記入されるべき確率は８１％である。
−CURRENT_LABEL｜CONTAINS｜住所（address）｜住所１（AddressStreet1）｜４６
入力フィールドの左側（LEFT）にある文字列が住所（address）を含む（CONTAINS）場合、入力フィールドにユーザの住所１（AddressStreet1）が記入されるべき確率は４６％である。
【００２０】
欧州特許出願第０５１０９７５３．３号明細書はこのような手法に基づく入力フォームの自動記入方法および装置を提案している。詳細についてはこの欧州特許出願明細書を参照されたい。また、これらの開示内容のすべてが引用することによって本発明の一部をなすものとする。
【００２１】
欧州特許出願第０５１０９７５３．３号明細書の発明では、ダウンロードされたウェブページが構文解析され、あらゆる入力フィールドをチェックすることによって、対応するオブジェクト構造（object structure）が生成される。次にこのオブジェクト構造は、ある特定のルールが満たされるかどうかを、例えばルールのパターンとオブジェクト構造のパターンを比較することによってチェックするのに使用される。マッチが見つかれば、そのルールは満たされていると見なされる。詳細については欧州特許出願第０５１０９７５３．３号明細書を参照されたい。
【００２２】
欧州特許出願第０５１０９７５３．３号明細書に開示された手法は自動フォーム記入に使用することができる。しかしながら、実際の経験が示すように、各ルールに唯１つの条件では、特に日本語のウェブサイトにおいて、フォームに関連するより複雑なコンテンツを表すには不十分である。こうしたことは１つの概念名（concept name）に対する入力フィールドが２つ以上の入力フィールドに分割される場合および／または関連しているラベルが単一の場所に置かれない場合にしばしば起こる。
【００２３】
ユーザデータの入力フィールドを含む日本語の複数のウェブページの解析を通じて、先の欧州特許出願第０５１０９７５３．３号明細書で定義されたルール構文（rule syntax）は時として十分でないことが分かった。日本語のウェブページの複雑さは次のいくつかの理由によって生じる。最初に、同じ意味を表す多くの表現が存在する、または、同じ表現でも意味が異なる場合もある。個人名（name）がその典型的な例である。図２に日本語のウェブサイトを解析すると見つかる可能性のある、フルネームに対する異なる表現、すなわちラベル（labels）、を示す。図中、左上から右下にかけて、「名前」、「お名前」、「なまえ」、「おなまえ」、「氏名」、「ご氏名」、「漢字氏名」、「カタカナ氏名」、「ローマ字氏名」、「姓名」、「セイメイ」、「宿泊代表者のお名前」は、全て個人名（name）を意味する。個人名（name）に対するラベルの１つである「名前」はある特定のコンテクストではファーストネームのみを表すのに使用される。
【００２４】
別の複雑さは、例えば『漢字』、『ひらがな』、および『カタカナ』の他に、『半角』（８ビット文字コード）と『全角』（１６ビット文字コード）といった、異なる文字集合が存在する事実から来る。１６ビット文字コードは主に漢字とひらがなに使用される。しかし１６ビット文字コードは英数字にも割り当てられている。『カタカナ』は１６ビット文字コードと８ビット文字コードの両方で表すことができる。図３にラストネーム（姓）およびファーストネーム（名）に異なる文字の入力を要求するウェブページ入力フォームの典型例を示す。ラベルである『お名前』と『おなまえ』は入力に使用する文字種（前者は漢字、後者はひらがな）を指定する。右側のラベル『（全角）』は（漢字とひらがなが１６ビットでのみ表すことができるとしても）１６ビット文字で記入しなければならないことを示す。異なるポジションにある複数のラベルとして与えられた全ての情報を組み合わせることで、自動フォーム記入方法は、フォームに記入すべき情報は最初の行では１６ビット文字の漢字の『姓』（ラストネーム）および『名』（ファーストネーム）、次の行では１６ビット文字のひらがなの『姓』および『名』であるという判断に到達すべきである。
【００２５】
要求される情報が２つ以上の入力フィールドに分割されることはよく起こることである。誕生日の記入が求められる場合、図４に示すように、年、月、日をそれぞれ記入するための３つの入力フィールドが存在する場合がある。最初のラベル『生年月日』は３つの入力フィールドの全てに適用される。各入力フィールドの右手にある各ラベルはそれぞれ、年、月、および日を意味する。考慮しなければならない別のポイントは一部のラベルがこのように入力フィールドの後に配置されることである。
【００２６】
特に日本語における、記入すべきウェブフォームの複雑さの解析から、入力フィールドにどの情報を記入すべきかの判断の基礎をそれらのラベルに置く自動フォーム記入方法は、
（ｉ）１つのラベルだけでなく、ターゲットとする入力フィールドに関連する追加のラベルも、
（ｉｉ）左側ラベルに加えて右側ラベルも、
（ｉｉｉ）ラベルの語義上の意味および関連性も、
考慮すべきであるという結論に到達することができる。
【００２７】
一般的なウェブフォームを解析すれば、ほとんどのケースで、フィールドに正確な情報を記入する際に記入すべきフィールドから一般的には最大３つのラベルが重要になり得ることが見出される。例えば、図５において強調表示された左から２番目の入力フィールドがターゲットのとき、考慮すべきラベルは、ターゲットを基準にして最初の左ラベル『名』、３番目の左ラベル『お名前』、そして最初の右ラベル『（全角）』である。しかしながら、２番目の左ラベル『姓』はこの２番目のフィールドには適用できず、最初の入力フィールドにのみ適用可能である。これはある特定の入力フィールドを記入するためにどの概念名（concept name）を使用すべきかの判断の基礎となるルールはラベルの背後にある語義上の意味（semantic meanings）を考えてそれらが適正な情報を与えるか否かを判断する必要があることを意味する。これらのルールは語義に関してＡＮＤ条件を表す場合がある。斯かるルールは入力フィールドのラベルの内容とそれらのポジションを規定するものである。斯かるルールに与えられた規定が入力フィールドとマッチすれば、これはこのルールに対応する概念名（concept name）がその入力フィールドを記入するために使用されるべきであることを意味する。図５の例では、最初の左ラベルが『名』、３番目の左ラベルが『お名前』、そして最初の右ラベルが『（全角）』であれば、概念名（concept name）は漢字のファーストネーム（first name）である。しかしながら、既に言及したように、漢字は本来８ビット文字コードではなく１６ビット文字コードでのみ表すことができる。従って最初の右ラベル『（全角）』は冗長情報であり、わざわざ明記する必要はない。それゆえ、この場合の十分かつより適切なルールは、最初の左ラベルが『名』であり、かつ、３番目の左ラベルが『お名前』である場合には、概念名（concept name）は漢字のファーストネームとする、という形になる。
【００２８】
次に、図５に与えたようなフォームを記入するために適用することができるルールの構造について説明する。このルール構造は欧州特許出願第０５１０９７５３．３号明細書において記述された構造と類似している。ルールは基本的に（日英併記の形で）、ポジション（Position）｜条件（Condition）｜値（Value）という構造から成る。ポジション（Position）は１つ以上のラベルの位置表示を意味し、条件（Condition）は当該ポジション（Position）に位置するラベルがどの値をとるかを示す。「概念名（concept name）」はこのルールから引き出される結論、すなわち当該条件が満たされた場合に当該フォームに記入すべき概念名（concept name）である。
【００２９】
ファーストネーム（名）とラストネーム（姓）から成る個人名の場合のように、互いに何らかの関係がある記入すべき入力フィールドが２つ以上存在するという事実を考慮するため、ＡＮＤ条件を使用して複数のルールを組み合わせることを考えることができる。
【００３０】
斯かるルールに対し、新たなルール構文（rules syntax）を次のように定義することができる。
（ＡＮＤ条件）＋｜＝概念名（concept name）｜確率（Probability）
ここで『（ＡＮＤ条件）＋』は１つ以上の条件が存在すること意味する。
このＡＮＤ条件のフォーマットは次のようなものである。
ポジション（Position）｜条件（Condition）｜値（Value）
それぞれにおいて、
・ポジション（Position）＝｛Ｌ１、Ｌ２、Ｌ３、Ｒ１、Ｒ２、Ｒ３、
UPPER_LABEL、LOWER_LABEL、CURRENT_NAME_ATTRIBUTE、
UPPER_NAME_ATTRIBUTE、LOWER_NAME_ATTRIBUTE｝
・条件（Condition）＝｛CONTAINS、EQUALS｝
【００３１】
この新たな構文（syntax）はＡＮＤ関係によって単に複数の条件を組み合わせるだけであることが見て取れる。Ｌ１、Ｌ２、Ｌ３はそれぞれ、最初の左ラベル（ターゲットとする入力フィールドから左側にある最も近いラベル）、２番目の左ラベル（ターゲットとする入力フィールドから左側にある２番目に近いラベル）、３番目の左ラベルを示すことは言及しておきたい。Ｒ１、Ｒ２、Ｒ３は入力フィールドの右側のラベルに関して同じ意味を持つ。図５の例では、Ｌ１、Ｌ２、およびＬ３で示されたポジションが図５で強調表示された入力フィールドに関係する場合、Ｌ１は名、Ｌ２は姓、Ｌ３はお名前、ということになる。ルールにおける位置表示が関係するフィールドのポジションは実際にはそのルールを適用する入力フィールド（本例では図５で強調表示された入力フィールド）のポジションである。
【００３２】
以上の説明を踏まえて、図５に示したような強調表示された入力フィールドに対するルールは次のような形を採ることができる。
Ｌ１｜EQUALS｜名｜Ｌ３｜CONTAINS｜名前｜Ｒ１｜CONTAINS｜全角｜＝FirstNameKanji｜８５、
または、
Ｌ１｜EQUALS｜名｜Ｌ３｜CONTAINS｜名前｜＝FirstNameKanji｜８０
FirstNameKanjiは漢字の名（ファーストネーム）を意味する概念名（concept name）である。
【００３３】
例示として、数字「８５」および「８０」（パーセントまたは何か他の尺度）は見つかった概念名（concept name）が正しい概念名である確率を示す。各ルールには確率のある決まった値が割り当てられる。さらに、「確率（％）」の代わりに、確率の指標となるスコア（数値）が使用される場合もある。
【００３４】
一部のルールによる入力フィールドへの記入の仕方についての知識を反映させて斯かるルールを生成するには、既存のフォームに使用される入力フィールドの中に共通のテキスト文字列（または「パターン」）が特定されることが必要とされる。しかしながら、日本語のウェブサイト、特に入力フィールドのラベルの中に、ルールで使用される共通のテキスト文字列を見出すことは、英語の場合よりも難しい。これは図２との関連で述べたように同じ意味に対して複数の表現が存在するためである。同じ概念名（concept name）に対する異なるルールの中に共通のテキスト部分文字列を見出すことができる場合、それらのルールはその部分文字列を使用することによって１つに併合し、より高い確率（例えば併合されたルールの累積確率）を設定することができる。このようしてルールは改善される余地が大いにある。
【００３５】
上述したようにラベルのＡＮＤ条件に基づく拡張されたルール構文は全ての所与の条件が満たされる場合に有用である。しかしながら、それでも確率またはスコアに指標される発生率がより高いルールを見つけることはできない。
【発明の開示】
【発明が解決しようとする課題】
【００３６】
そこで本発明の課題は、このような場合にもより効率的に対処することができる異なるアプローチを提供することにある。
【課題を解決するための手段】
【００３７】
本発明は、上記課題を解決するため、モバイル機器上においてウェブベースのフォームを自動記入するための装置（フォーム自動記入装置）を提供する。本装置は、
ウェブベースのフォームを解析して、入力フィールドグループを検出するとともに、この入力フィールドグループを、このグループに属する入力フィールドの近傍（neighbourhood）を記述または画定する１つ以上のパラメータによって表現するオブジェクトを生成する入力グループ認識モジュール（input group recognition module）と、
チェックされる条件とそれに対応する引き出される結論とを各ルールが含む複数のルールを含み、複数のグループルール（group rules）と複数の内部ルール（inner rules）とを含むルールリポジトリ（rule repository）であって、前記複数のグループルールにおいては、ルールが満たされることが判った場合に引き出される結論は、前記入力フィールドグループの区別できる語義上の意味に対応し、前記入力フィールドグループに属するフィールドに記入される値として内部概念名（inner concept names）の集合を特定するグループ概念名（group concept name）であり、前記複数の内部ルールにおいては、各内部ルールがチェックされる条件とそれに対応する引き出される結論とを含み、その結論は、前記入力フィールドグループに属している入力フィールドに記入するために内部概念名が使用される順序に対応するものとなる、ルールリポジトリと、
前記グループルールを前記入力フィールドグループを表現する前記オブジェクトと照合することによって前記グループルールを評価して、前記入力フィールドグループに対応するグループ概念名を特定し、それにより前記入力フィールドグループに属する入力フィールドに記入するために使用されるべき内部概念名の集合を特定するグループルール検査モジュール（group rule inspecting module）と、
前記内部ルールを前記入力フィールドグループを表現する前記オブジェクトと照合することによって前記内部ルールを評価して、前記グループルール検査モジュールにより特定された前記グループ概念名に対応する前記内部概念名の集合によって、前記入力フィールドグループに属する入力フィールドが記入されるべき順序を特定する内部ルール検査モジュール（inner rule inspecting module）と、
前記入力フィールドグループに属する入力フィールドを前記内部概念名に対応する値を用いて前記内部ルール検査モジュールが決定した順序に従って自動記入するためのユーザデータ記入モジュール（user data filling module）とを具備する。
【００３８】
フォームの記入を、グループを検出し、グループ概念名を認識し、次いで前記検出されたグループ概念名に対して内部概念名の対応する順序を特定するといった具合に手続きを分離することで、検出された入力グループ内にある複数のラベルの情報を利用した、改善された認識結果が得られる。
【００３９】
本装置において、１つの態様として、グループルールは、
前記入力フィールドグループに属する入力フィールドの前記近傍内に現れる複数のパラメータを含んでおり、前記複数のパラメータは前記グループルールが満たされる場合には前記入力フィールドグループに属する入力フィールドの前記近傍内に存在する必要がある。
【００４０】
本装置において、１つの態様として、内部ルールは、
前記入力フィールドグループに属する入力フィールドの前記近傍内に現れるパラメータの順序、または、
前記入力フィールドグループに属する入力フィールドの数を含む。
【００４１】
本装置において、１つの態様として、前記入力グループ認識モジュールは、
開始境界と終了境界をチェックして、入力グループをこれらの境界内に存在するウェブベースのフォームの要素として決定するためのモジュールを含む。
【００４２】
本装置において、１つの態様として、前記境界は、
新たなラインタグ（line tag）またはテーブルタグ（table tag）、
テーブルの行の始点を指定するタグ、
テーブルの行の終点を指定するタグ、
行の上部境界を指定する座標値、
行の下部境界を指定する座標値、
行の右側境界を指定する座標値、
行の左側境界を指定する座標値、
の少なくとも１つ以上で画定される。
【００４３】
本装置において、１つの態様として、前記入力グループ認識モジュールは、
複数の入力グループ候補をそれらの１つ以上の候補が１つの拡張された入力グループに組み合わせられるかどうかに関して評価するためのモジュールを含み、このモジュールは、
入力グループ候補が１つ以上のグループルールと部分的にマッチするかどうかをチェックし、
部分的なマッチが検出された場合には、今度は他の入力グループ候補について、部分的なマッチが見つかった前記グループルールの他の部分との部分的にマッチするかどうかをチェックし、
斯かるチェックを、あるグループルールが前記部分的なマッチによって累積的に全面的にマッチするまで、更なる入力グループ候補について繰り返し、
斯かる全面的なマッチに到達した場合には、斯かる全面的なマッチに寄与した候補の入力グループを単一の拡張された入力グループに組み合わせるためのモジュールを含む。
【００４４】
本装置において、１つの態様として、前記候補の入力グループは単一の入力フィールドのみから成る。
【００４５】
本装置において、１つの態様として、前記入力グループ認識モジュールは、
入力フォームの要素の座標を決定するためのレアウト・インタプリタ・モジュール（layout interpreter module）と、
入力フォームの要素の座標を考慮する１つ以上のレイアウトルールに基づいてどの要素が入力グループを形成するために組み合わされるべきかを判定するレイアウト・ルール・モジュール（layout rule module）とを含む。
【００４６】
本装置において、１つの態様として、前記レイアウト・ルール・モジュールは、水平方向および／または垂直方向における要素の位置に対する１つ以上の閾値を前記判定の基礎として、それらの要素が入力グループに組み合わされるべきかどうかを決定する。
【００４７】
本装置において、１つの態様として、入力グループの要素は水平方向の座標境界に基づいて決定され、
垂直方向の座標に基づいて入力グループのある要素が複数の入力グループに対するラベルになることが判った場合、これらの複数の入力グループは１つの拡張された入力グループに組み合わされる。
【００４８】
本装置において、１つの態様として、前記グループルールは、前記グループルールに規定された複数の区別できるラベルを含むことが満たされるよう入力グループに対して要求する形をとり、前記複数のラベルは前記入力グループの任意の位置に存在して構わないものである。
【００４９】
本装置において、１つの態様として、グループルールおよび／または内部ルールはそれぞれの関連するスコアを含み、
スコアが１００％未満の確率を示す複数のルールが入力グループとマッチする場合には、異なる概念名のコンセプトポイントが個別に足し上げられ、最高のスコアを有する概念名が選択される。
【００５０】
本装置において、１つの態様として、入力グループはオブジェクト構造（object structure）によって表現され、グループルールの評価はそのグループルールが前記入力グループに対応するオブジェクト構造とマッチするかどうかをチェックすることにある。
【００５１】
本発明は、上記課題を解決するため、モバイル機器上においてウェブベースのフォームを自動記入するための方法（フォーム自動記入方法）も提供する。本方法は、
ウェブベースのフォームを解析して、入力フィールドグループを検出するとともに、この入力フィールドグループを、このグループに属する入力フィールドの近傍を記述または画定する１つ以上のパラメータによって表現するオブジェクトを生成する入力グループ認識ステップと、
チェックされる条件とそれに対応する引き出される結論とを各ルールが含む複数のルールを含み、複数のグループルールと複数の内部ルールとを含むルールリポジトリであって、前記複数のグループルールにおいては、ルールが満たされることが判った場合に引き出される結論は、前記入力フィールドグループの区別できる語義上の意味に対応し、前記入力フィールドグループに属するフィールドに記入される値として内部概念名の集合を特定するグループ概念名であり、前記複数の内部ルールにおいては、各内部ルールがチェックされる条件とそれに対応する引き出される結論とを含み、その結論は、前記入力フィールドグループに属している入力フィールドに記入するために内部概念名が使用される順序に対応するものとなる、ルールリポジトリを提供するステップと、
前記グループルールを前記入力フィールドグループを表現する前記オブジェクトと照合することによって前記グループルールを評価して、前記入力フィールドグループに対応するグループ概念名を特定し、それにより前記入力フィールドグループに属する入力フィールドに記入するために使用されるべき内部概念名の集合を特定するグループルール検査ステップと、
前記内部ルールを前記入力フィールドグループを表現する前記オブジェクトと照合することによって前記内部ルールを評価して、前記グループルール検査ステップにより特定された前記グループ概念名に対応する前記内部概念名の集合によって、前記入力フィールドグループに属する入力フィールドが記入されるべき順序を特定する内部ルール検査ステップと、
前記入力フィールドグループに属する入力フィールドを、前記内部概念名に対応する値を用いて前記内部ルール検査ステップで決定された順序に従って自動記入するユーザデータ記入ステップとから構成される。
【００５２】
本方法は、１つの態様として、上記いずれかの態様の装置によって実行される方法ステップを更に含む。
【００５３】
本発明は、コンピュータ上で実行されるときにこのコンピュータが上記いずれかの態様の装置によって実行される方法ステップを実行することを可能にするコンピュータプログラムも提供する。
【発明を実施するための最良の形態】
【００５４】
複数の入力フィールドが一緒になって、例えばファーストネーム（名）およびラストネーム（姓）から成る個人名（name）、あるいは、日、月および年から成る生年月日（birthday）といった、１つのグループを成す特定の情報を形成するタスクから説明を始めることにする。ここではグループを成す密接に関連する斯かる「複数の入力フィールド」に対するルールを見つける必要がある。
【００５５】
テーブル内の同じライン（line）または行（row、横列）に存在するラベルと入力フィールドだけを考えてよい。その目的のため、入力フォームのソースコードを参照することができる。例えば、ＨＴＭＬソースでは、テーブル内のライン（line）は＜ＢＲ＞タグで区切られた１つの文字列として定義され、テーブル内の行（row）は＜ＴＲ＞タグ（ｈｔｍｌにおいてテーブル行の始点を指定する）で始まり＜／ＴＲ＞タグ（ｈｔｍｌにおいてテーブル行の終点を指定する）で終わる１つの文字列として定義されることがある。
【００５６】
一般に、入力フィールドのグルーピングと関連情報の識別は、ソースコードの中に異なるレベルで見つかる場合がある位置情報（location information）を検出することによって実行することができる。単純なケースでは、ライン（line）は、新しいラインを開始する例えば＜ＢＲ＞タグ、またはテーブル内の行を指定する例えば＜ＴＲ＞タグで終わる１つの文字列として指定されることがある。もっと複雑なケースでは、座標情報が使用できる。
【００５７】
実施の一形態によれば、図６に示されたフォーム記入装置（form filling apparatus）が提供される。このフォーム記入装置には入力フォームが供給される。入力フォームは最初に受信された後、構文解析モジュール（parsing module）によって処理される。構文解析モジュールは、入力フィールドのグループ（各グループには後でいわゆるグループルールが適用される）を識別するタスクを実行する。入力フィールドの各グループは、１つの共通の総称的入力データ（以下、グループ概念名（group concept name）と呼ぶ）に一緒に属する入力フィールドを含む。各グループ概念名は、１つのグループに属する個別のフィールドを記入するために使用される内部概念名（inner concept names）の集合に対応する。グループ概念名は１例としては例えば「個人名（name）」（この場合の個別のフィールドはファーストネームとラストネーム）である。別の例としては、年、月および日といった個別の内部概念名から成る、「生年月日（birthday）」または「カード有効期限」が挙げられる。
【００５８】
パーサー（parser）によるグループの特定は、おおよその場所内にある、例えば既に言及したように＜ＢＲ＞によって区切られた、または＜ＴＲ＞タグと＜／ＴＲ＞タグで挟まれたｈｔｍｌソース内にある、入力フォーム内にある入力フィールドを特定することによって実行されることがある。
【００５９】
入力フィールドのグループがパーサーによって特定され、対応するオブジェクト構造が生成されると、そのグループ（またはそのグループを表現する対応するオブジェクト構造）はグループルール検査モジュール（group rule inspecting module）に送られる。このグループルール検査モジュールはルールリポジトリにすでに記憶されている複数のグループルールを評価する。グループルールをパーサーによって特定された入力グループと照合する試みによって、グループ概念名（group concept name）が特定される。これは完全なマッチと１００％の確率を与えるグループルールによって行われることがあるか、あるいは、マッチはするがより確からしさが低い（lower certainty）いくつかのグループルールが評価されることがあるとともに、以前の実施形態におけるようにそれらの累積スコアが決定されることがある。グループルールを評価した結果、区別できる語義上の意味によってグループを特定し、それに対応する事前に割り当てられた、そのグループに属する入力フィールドに後で記入するために使用される区別できる内部概念名（inner concept names）の集合を有する、「グループ概念名（group concept name）」が得られる。
【００６０】
グループ概念名が特定されると、その結果は図６に示す内部ルール検査モジュール（inner rule inspecting module）に送られる。この内部ルール検査モジュールは、グループ概念名に対応する内部概念名がそのグループに属する入力フィールドに記入するために使用されるべき順序を特定するタスクを実行する。これはいわゆる内部ルール（特定されたグループ概念名の内部ルール）を評価することによって実行される。それらの内部ルールはそれらを評価することによって内部概念名を使用して入力フィールドに記入するための順序について決定するための基礎として利用できるものである。この評価が実行されると、記入モジュールは次に、選択されたグループ概念名に属する内部概念名の値としてユーザのために記憶されている実際の値を参照し、これらの値を用いて、マッチが見つかった内部グループルールによって指定された順序でそのグループの入力フィールドに記入することによって、入力フォームへの実際の記入を行う。実施の一形態によれば、（ルールを次々にチェックするときに）最初のマッチを与える内部ルールが選択される。この場合、内部ルールにそれらの順序で優先順位を付けることが可能である。
【００６１】
本アプローチをグループ概念名を使用していない欧州特許出願第０５１０９７５３．３号明細書の実施形態と比較して説明すると、概念名（グループ概念を使用しない以前のアプローチで述べた）はコンテクストの上でグループを成す１つの集合として一緒にグループ化される。というのは、こうしてグループ化された概念名は、共通の「グループ概念（group concept）」によって、従って「グループ概念名（group concept name）」によって代表させることができるからである。グループ概念名は故に、グループを成す区別できる概念名の集合を表す一種の「一般化された」概念名である。斯かるグループに属する個別の概念名は「内部概念名（inner concept names）」と呼ぶことができる。それに対し、グループ全体を表す概念名はグループ概念名と呼ぶことができる。グループ概念名は例えば内部概念名として「日」、「月」および「年」を有する「生年月日」の場合がある。グループ概念名の別の例としては、関連する内部概念名として「ファーストネーム（FirstName）」と「ラストネーム（LastName）」を有することがあるグループ概念名「個人名（Name）」の場合がある。
【００６２】
前述したように、本実施形態は２つ以上の入力フィールドから成る入力グループの検出に基づく。例えば、同じテーブルラインに存在する入力フィールドは１つの入力グループとみなすことができる。ＨＴＭＬウェブページにおいて、しばしばテーブルタグは入力フィールドに語義的に関連するラベルを配置するために使用される。テーブルタグを検出することにより、入力グループが検出できる。テーブルタグを使用していないウェブページにも有効に働くもっと高度な技法として、あとでより詳しく説明するように、ラベルおよび入力フィールドが同じラインに配置されており、入力グループと見なされるかどうかを判断するために、座標情報が使用できる。入力グループが検出されたら、次の２つのステップ、すなわち、（ｉ）入力グループに対する概念名を決定するステップと、（ｉｉ）選択されたグループに対する各入力フィールドの概念名を決定するステップを有するアルゴリズムが実行される。ステップ（ｉ）では、実施の一形態によれば、入力グループにおけるラベルの外観が考察されるだけである。ステップ（ｉｉ）では、ラベルの順序またはグループ内にある入力フィールドの数が考慮される。
【００６３】
以前の実施形態と比べると、概念名の特定は３つの個別ステップ、つまり、入力グループを検出するステップ、入力グループに対する全体の概念名を特定するステップ、各入力フィールドの各概念名を特定するステップ、に分離される。このおかげで、より高い確率のルールを定義し、それによりシンプルな方法でより可能性の高いユーザデータがもたらされる。
【００６４】
次に、実施の更なる形態をより詳しく説明する。既に言及したように、１群の入力フィールド全体を考慮する入力グループルール（input Group rules）が導入される。入力グループ（input group）のシンプルな認識法として、テーブルの中のＴＲ要素に使用される＜ＴＲ＞タグと＜／ＴＲ＞タグをそれぞれ入力グループの始点と終点と見なすことができ、入力グループはそれが少なくとも１つの入力フィールドを含む場合に考える。日本語の自動フォーム記入の１つの実施形態では、入力グループの認識に、現在の入力グループの終点と（少なくとも１つの入力フィールドが存在する場合に限り）次の可能な入力グループの始点として＜／ＴＲ＞タグのみが使用される。これは例えばテーブルの中にいくつかの部分テーブルが存在するなどの複雑な形で＜ＴＲ＞タグと＜／ＴＲ＞タグがかなり頻繁に利用されるからである。こうした場合、＜ＴＲ＞タグを入力グループの始点と見なせば、一部の情報が見失われる。もちろん、入れ子になっているテーブルタグを扱えば認識が向上する可能性がある。しかしながら、後述するように、入力グループの他のもっと高度な認識技術も使用されることがある。
【００６５】
図３および図４に示した例に戻って説明を続ける。各ラインは１つの入力グループと見なすことができる。第１のステップとして、漢字個人名（NAME Kanji）、ひらがな個人名（Name Hiragana）、または生年月日（Birthday）のグループといった、グループの概念名を考えることにする。第２のステップとして、ラベルの順序に基づいて、例えば漢字個人名グループ（Name Kanji group）ではファーストネーム（First Name）またはラストネーム（Last Name）といった、どういった概念名が各入力フィールドに適用されるかが解析される。以下の２つのルールが導入される。
（ｉ）入力グループに対する概念名を指定するための入力グループルール（Input Group rule）
（ｉｉ）選択されたグループに対する各入力フィールドの概念名を指定するための内部ルール（Inner rule）
実施の一形態によれば、入力グループルール（Input Group rules）はラベルのみを扱い、入力フィールドのname属性は扱わないことに留意したい。
【００６６】
次に、入力グループに使用されるルール構文（rule syntax）とアルゴリズムの例を説明する。入力グループルール（input Group rules）に対する構文は次のようなものである。
Input_Group｜Condition｜Value｜＝Group concept name｜［Probability］
【００６７】
平文ではこのルールは次のように読むことができる。入力グループInput Groupのラベルが『条件（Condition）』で『値（Value）』を有する場合、グループ概念名（Group concept name）ｘを選択する確率（Probability）はｙ％である。
【００６８】
ルールの「確率（Probability）」または「スコア（Score）」は選択的でよく、ルールは実施の一形態ではスコアを一切含まないこともある。確率（Probability）の値（value）はヌル（null）の場合がある。
【００６９】
ルールは入力グループのパラメータに対する条件を指定する。「パラメータ」はここでは入力フィールドのラベルまたは入力グループ内部の任意のラベルである。
・Condition＝｛CONTAINS、EQUALS｝
CONTAINSは入力グループ内部の少なくとも１つのラベルが所与の値を含むことを意味する。
EQUALSは入力グループ内部の少なくとも１つのラベルが所与の値に等しいことを意味する。
・Group concept name＝２つ以上の入力フィールドのグループに適用される、グループの概念名
・Probability＝０から１００までの値（確率）
【００７０】
グループルールは一般的に２つ以上の条件、すなわちＡＮＤ条件、を有する。ｎ個の条件が付いたルールは次のように表される。
Input_Group｜Condition_1｜Value_1｜．．．｜Input_Group｜Condition_n｜Value_n｜＝Group concept name｜［Probability］
【００７１】
これは斯かるグループルールが満たされるためにはそのグループはグループ内のどこかに値１乃至ｎ（Value_1~n）のラベルを含まないといけないことを意味する。
【００７２】
次に上記構文に基づくルールのもっと具体的な例を与える。本例では、先に導入した（ＡＮＤ条件）（「累積的条件（cumulative conditions）」とも称される）が入力グループルールに適用される。
・INPUT_GROUP｜CONTAINS｜名前｜INNPUT_GROUP｜CONTAINS｜ふりがな
｜＝namehiragana_group｜ｌ００
入力グループINPUT GROUPのラベルが「名前」と「ふりがな」を含む場合にはNameHiragana_group（ひらがな個人名を意味するグループ概念名）を選択する確率は１００％である。
・INPUT_GROUP｜CONTAINS｜名前｜INNPUT_GROUP｜CONTAINS｜カタカナ
｜＝namekatakana_group｜ｌ００
入力グループINPUT GROUPが「名前」と「カタカナ」を含む場合にはNameKatakana_group（カタカナ個人名を意味するグループ概念名）を選択する確率は１００％である。
【００７３】
上記ルールの中には位置表示が一切存在しないことに注意したい。これは、グループルールはラベルの位置を指定せずに実際のラベル（ラベルの「テキスト文字列」）を指定すること、そしてそれらのラベルはルールが満たされていると見なされる場合にはグループ内に存在しなければならないことを意味する。この要件は位置情報がルールの中に指定された以前の（背景技術で述べた）実施形態で述べたルールよりも緩いことは明らかである。このようにして、複数の入力フィールドを有するグループに対するルールを設計することはラベルの位置を考えなければならない態様と比べてより簡単なものになる。
【００７４】
しかしながら、要件は位置情報を省略することで以前の実施形態と比べて緩和されているのに対し、斯かるルールにおける要件は、ルールが、累積的に存在しなければならい２つ以上のパラメータ（ラベル）を規定するという意味で、より厳しいものとなっている。
【００７５】
一方、入力グループを（それらの境界により、従ってそれらの要素を検出することにより）適切に認識することにより、マッチするグループルールが存在するような関係のある情報を入力グループの要素が含むという蓋然性が、ラベルの位置をルールと照合するために要求した以前のアプローチと比べて、より高くなる。本実施形態では、要素の位置は、それが認識されたグループに属する限りは、問題にならない。
【００７６】
当業者にとっては斯かる手法はグループが単一の入力フィールドしか持たない場合にも適用可能であることは明白なものとなる。この場合、入力グループの要素はその入力グループを画定する境界内に存在する要素であり、このとき、位置に無関係なグループルールのチェックが既に述べたようにその条件が満たされるグループルールを見つけるために実行できる。あるグループルールがベストマッチ（およびその結果選択された対応するグループ概念名）を与えるものとして選択されたら、次に内部ルールがチェックされる。グループに単一の入力フィールドしか属していない場合、これは実施の一形態として内部概念名の値がその単一の入力フィールドに記入すべき単一の値に所定のスキームに従って併合されるという効果を持つ。
【００７７】
同じグループ概念名に属し、全ての満たされたルールのスコアを足し上げることで、グループの最も高い確率の概念名をもたらす前述した実施形態と同じアルゴリズムを適用することが可能である。一方、所与のグループに対して１００％の確率のルールが見つかる場合、それはストレートに適用される。それ以外の場合、マッチするルールに従って各概念名のスコアが累積され、全ての適用可能なルールを解析した後に累積スコアの最も高いグループ概念名が選択される。
【００７８】
確率値がヌル（null）の場合、最初に選択されたルールが適用されることがある。従って同じグループ概念名に対するルールの順序は優先順位を表す場合がある。
【００７９】
上述した手法による入力グループの認識に基づいて、最も適切なグループ概念名を特定するためにグループルールがチェックされる。
【００８０】
グループ概念名を選択した後、各入力フィールドに適用される概念名を指定するために内部ルール（Inner rules）が適用される。実施の一形態によれば、２つのタイプの内部ルールが存在する。
【００８１】
（１）具体的な内部ルール
具体的な内部ルールは、グループ内に出現したラベルの順序と、それに応じた概念名のリストを指定する。入力フィールドは概念名の順序で記入される。ルール構文は次のように指定することができる。
Label_1｜Label_2｜．．．｜Label_n
＝＞concept name_1｜concept name_2｜．．．｜concept name_n
入力グループのラベルがLabel_1、Label_2、．．．、Label_nの順序で現れる場合には、ｎ個の入力フィールドはconcept name_1、concept name_2、．．．、concept name_nの順序で記入するものとする。
【００８２】
次に、Name Hiragana_groupに対する２つの例を示す。
・姓｜名＝＞Last Name Hiragana、First Name Hiragana
入力フィールドのラベルが姓（last name）と名（first name）の順序で現れる場合、２つの入力フィールドは概念名Last Name HiraganaとFirst Name Hiraganaで記入される。
・氏｜名＝＞Last Name Hiragana、First Name Hiragana
入力フィールドのラベルが氏（last name）と名（first name）の順序で現れる場合には、２つの入力フィールドは概念名Last Name HiraganaとFirst Name Hiraganaで記入するものとする。
【００８３】
（２）数値的ルール
数値的ルールは入力グループにおける入力フィールドの数に基づいてラベルを考慮することなく規定する。数値的ルールは入力グループにいくつの入力フィールドｎが存在するかを決定するだけである。そのルールは次のようなものである。
ｎ＝＞concept name_1、concept name_2、...、concept name_n
グループ内にｎ個の入力フィールドが存在する場合、それらはconcept name_1、concept name_2、．．．、concept name_nの順序で記入される。
【００８４】
次にTelephone_group（電話番号を意味するグループ概念名）の２つの例を示す。
・１＝＞Ｔｅｌ１＋‘−’＋Ｔｅｌ２＋‘−’＋Ｔｅｌ３
グループ内に唯１つの入力フィールドしか存在しない場合、そのフィールドはＴｅｌ１−Ｔｅｌ２−Ｔｅｌ３で記入される。
・３＝＞Ｔｅｌ１、Ｔｅｌ２、Ｔｅｌ３
グループ内に３つの入力フィールドが存在する場合、それらのフィールドはそれぞれＴｅｌ１、Ｔｅｌ２、Ｔｅｌ３の順序で記入される。
【００８５】
実施の一形態によれば、フォームフィラー（From Filler）は次の３ステップ、すなわち入力グループ検出ステップ（入力グループの要素を決定する）、入力グループ認識ステップ（グループ概念名を決定する）、および内部ルール検出ステップ（入力フィールドを内部概念名で記入する際の入力順序の検出に対応する）、を実行する働きをする。図７に本発明の実施の一形態による入力グループ認識・記入に関する状態図を示す。以下、この状態図をより詳しく説明する。
【００８６】
（１）入力グループ検出（グループの解析）
ＨＴＭＬパーサーはダウンロードされたウェブページを解析し、２つ以上の入力フィールドを含む場合がある各入力グループごとに１つのオブジェクト構造を生成する。入力グループを検出するシンプルな方法はテーブル要素を使用することである。拡張された入力グループ（enhanced input group）の検出は、ラベルおよび入力フィールドの正確な位置や、ラベル間の語義的な関連性などを用いることによって行われることがある。これについては詳しく後述する。さて、生成されたオブジェクト構造は入力グループ内の全ての入力フィールドとそれらのラベルを含む。実施の一形態によれば、これはグループの境界内に含まれる全てのテキスト文字列を含むことがある。入力グループ検出はパーサーとは別個のモジュールによって実行されることがある。このモジュールは、パーサーからの結果を利用して、一緒になって１つの入力グループを形成すべきフィールドを特定するとともに、その入力グループのオブジェクト構造（その入力グループに属するラベルまたは任意のテキスト文字列を含む）を形成する。このオブジェクト構造のおかげでルールを、この構造と照らし合わせてそれらのルールが満たされるかどうかをチェックする試みができる。このとき結果として生じるオブジェクト構造はグループルールと照合してグループルールが満たされるかどうかをチェックすることが試みられるものである。さらに、後で説明するように、内部ルールをこのオブジェクト構造に基づいてチェックすることも可能でなければならない。その目的のためのオブジェクト構造は入力グループに属する要素の１つの表現であり、それは、規定された構造の中に、ルールをこの構造と照合する試みによってルールチェックを実行するこができるようにするための必要な情報を含む。
【００８７】
（２）入力グループ認識（グループルールのチェック）
グループルールインスペクタ（Group Rule Inspector）は所与のオブジェクト構造に適用可能なグループルールを探索する。確率が１００％のルールが見つかった場合には、その対応するグループ概念名が選択される。確率が１００％未満のルールが見つかった場合には、各グループ概念名ごとにコンセプトポイント（concept points）が足し上げられる。グループルールのチェックは１つずつ試みられ、マッチした場合は、グループルールのスコアに応じてポイントが加算される。最後に、最高のコンセプトポイントスコアを持つ概念名グループが選択される。
【００８８】
（３）内部ルール検出（内部ルールのチェック）
ユーザデータフィラー（User Data Filler）は選択された概念名グループの内部ルールに従って入力フィールドをユーザデータで記入する。それはラベルの順序に基づいて各入力フィールドに適用可能な概念名を決定する。それは具体的な内部ルールに指定されるラベルの順序を検出する。電話番号、ファックス番号、および郵便番号の場合、数値的ルールを用いることによって、入力フィールドの数に基づいて全ての情報が連結または分離されるかどうかを検出することが可能である。内部ルールもマッチが見つかるまで１つずつ試みられ、その結果に基づいて入力グループが記入される。
【００８９】
グループが唯１つの入力フィールドから成る特殊なケースでは、対応する入力フィールドはこのグループに属する内部概念名に属する値によって記入される。グループ概念名が「生年月日」で、内部概念名が年、月および日の場合、１つしかない単一の入力フィールドは複数の内部概念名の値を単一のテキスト文字列に組み合わせることによって記入される。
【００９０】
作業（１）乃至（３）はそれぞれグループ検出モジュールによって特定された各入力グループごとに全ての入力グループがチェックし終わるまで実行される。
【００９１】
実施の一形態によれば、入力グループ認識は境界（始点と終点）の検出から成り、境界内のあらゆるもの（境界内に存在する入力フィールドだけでなく入力フィールドのラベルおよび任意のテキスト文字列も含む）が、対応する入力グループに属するものと考えられる。前述したように、例えばＨＴＭＬソースコードの中の＜ＴＲ＞および＜／ＴＲ＞タグがこの目的ために使用されることがある。また、斯かるタグ内に存在するあらゆるものが、対応する入力グループに属するものと見なされる。検出された入力グループ（またはオブジェクト構造によるその表現）に対して、正しいグループ概念名を決定するためにそれが１つ以上のグループルールとマッチするかどうかがチェックされる。
【００９２】
座標に基づいて入力グループとその要素を認識するための別のアプローチについては後述する。しかしながら、特定の境界内に存在するコンテンツを決定することに基づくグループの認識は複数の入力フィールドがこれらの境界内に存在しなければならないことを必ずしも意味しないことは理解されよう。それ故、既に言及したタグなどのような境界メカニズムまたは後述する座標に基づいて検出される「グループ」は複数の入力フィールドを含むだけでなく、単一の入力フィールドだけを含んでも良い。
【００９３】
既に言及したように、実施の一形態によれば、グループ認識に使用される境界内に存在するあらゆるテキスト文字列（またはラベル）は入力グループに属するものと見なされる。
【００９４】
次に、本発明の実施形態による、入力グループの可能な強化された認識技術について説明する。第１の認識技術は入力グループを併合または拡張することに基づく。
【００９５】
拡張された入力グループ（extended input groups）は、テーブルタグを検出するだけではなく、入力グループ同士の間の語義上の関連性も考慮することによって特定することができる。これは拡張された入力グループの認識に入力グループルールを使用することによって遂行できる。このための認識アルゴリズムは次のステップを含むことがある。
（１）ある１つの候補の入力グループを例えばテーブルタグを解析することによって検出する。
（２）入力グループルールを調べる。
（２−１）この候補の入力グループに部分的にマッチするルールが存在する場合、この候補の入力グループを出発点として使用し、部分的にマッチしたグループルールを適用することによって、拡張された入力グループの構築を開始する。
（２−２）それ以外の場合、この入力グループを削除する。
（３）（２−１）の場合、次の候補の入力グループが上記ルールの他の部分とマッチするかどうかをチェックする。
（４）以下の条件の１つが満たされるまで繰り返す。
（４−１）あるグループルールの全体が（部分的なマッチの累積によって）全面的にマッチする。このとき、（全面的なマッチに寄与した）候補の入力グループのグループが、拡張された入力グループと見なされる。
（４−２）候補の入力グループのどのグループによってもグループルールに全面的にマッチしない。このとき入力グループを削除する。
【００９６】
上記のアルゴリズムは候補の入力グループが単一の入力フィールドしか含まない場合にも適用できることは理解されよう。言い換えると、このアルゴリズムは入力グループに組み合わされるべき入力フィールド（それらは最終的にグループルールとの全面的なマッチに寄与するため）と、これが当てはまらないものについてはグループ概念名ではなく個別の概念名のみが探索されるべき個別の入力フィールドとして取り扱われるべき入力フィールドを実際に特定するために使用されることがある。
【００９７】
従ってこのアルゴリズムは入力としてパーサーが入力フォームを構文解析することによって見出された（単一の入力フィールドのみを含む場合がある）個々の候補グループを使用することができる。それにも基づいて、このアルゴリズムは、候補の入力グループの組み合わせによって、拡張された入力グループを検出することができる。
【００９８】
次にこのアルゴリズムを以下の例を用いてより詳しく説明する。
【００９９】
以下のテーブルに示すようなウェブページのテーブルレイアウトを考える。このテーブルは３行を含む。各行は１つの入力フィールドとそれ自身のラベルを含む。下のテーブルには、このグループに対する全体のラベルと見なされるラベル、すなわち「住所（Address）」が存在する。
【０１００】
【表１】
2008077634.tif 000003
【０１０１】
次のような入力グループルールが存在すると考える。
INPUT_GROUP|contains|番地（Street）|INPUT_GROUP|contains|市町村（City）|
INPUT_GROUP|contains|国（Country）|=address_group
【０１０２】
入力グループを認識するステップ（１）により、最初のラインが入力グループであると考えられる。それに対するルールは全く存在しないが、それが上記ルール（INPUT_GROUP|contains|番地（Street）...）に部分的にマッチするため、アルゴリズムは拡張された入力グループの構築を開始する。次の２つのグループに関しても、ルールの一部（国（Country）および市町村（City））がマッチする。それゆえ、このアルゴリズムはテーブルブロック全体を単一の拡張された入力グループと見なす。
【０１０３】
テーブルタグを使用することによる入力グループ検出のための前述した技法はｈｔｍｌ構文解析の非常に早い段階で適用されるが、しかしそれらはテーブルレイアウトのないウェブサイトには機能しない。それゆえ、以下、ＨＴＭＬ要素の座標を使用することによってあらゆるウェブサイトに機能するやや高度な技術について説明する。テーブルタグベースの認識とは対照的に、その技術はウェブサイトのレイアウト解釈を必要とする。
【０１０４】
図８にＨＴＭＬ要素（すなわちラベルおよび入力フィールド）の座標を取り出すための機能ブロック図を示す。レイアウトインタプリタ（layout interpreter）は、ＨＴＭＬパーサー（HTML parser）からオブジェクト構造と、スタイルシートパーサー（style sheet parser）からスタイル定義（style definitions）を取り出し、続いて座標を含む拡張されたオブジェクト構造を生成するコア（core）コンポーネントである。こうして得られた座標に基づいて、どの入力フィールドが入力グループに属するかに関する決定を実行することができる。
【０１０５】
これは１つ以上のレイアウトルールをチェックしてどの要素が入力グループに組み合わされるべきかを決定するレイアウトルールモジュール（layout rule module）によって実行されることがある。
【０１０６】
例えば、同じラインにある入力グループをラベルおよび入力フィールドの座標を用いて認識するために以下のような計算を適用することができる。入力フィールドおよびラベルのグループを形成するため、上部ラインと下部ラインからのそれらの距離に対する閾値を考慮に入れてエリアが画定されるものとする。図９において、１番目の入力フィールドは座標（ｘ，ｙ１）を有し、２番目の入力フィールドは座標（ｘ，ｙ２）を有し、そして１番目の入力フィールドの高さはｈであると仮定する。このとき、上部入力フィールドと下部入力フィールドとの間の垂直方向の距離を計算することができる。本例では、１番目の入力フィールドと２番目の入力フィールドとの間の距離は次のようになる。
ｄ＝ｙ２−（ｙ１＋ｈ）
２番目の入力グループエリアの上部境界のｙ座標は次式で与えられる。
ｙ＝ｙ１＋ｈ＋ｄ／２
【０１０７】
このエリア（ｙ＝０とｙ＝ｙ１＋ｈ＋ｄ／２の間）内の座標を有するすべてのラベル（任意のテキスト文字列）および入力フィールドは１つの入力グループと見なすことができる。同様にして、他の全ての境界が計算できる。与えられた公式は一例に過ぎないことに留意されたい。エリアを検出するための閾値の定義に応じて、様々な公式を適用することができる。ここに示した技法はラインを見つけるために使用されるが、列（columns）にも適用できる。さらに、このアイデアは前述した候補の入力グループを組み合わせる技法と一緒にして使用することができる。
【０１０８】
次に、図１０を参照して、グループ認識機能を実現するための別の手法を使用する実施の更なる形態について説明する。
【０１０９】
本実施形態では、拡張された入力グループを検出するために垂直方向と水平方向の座標情報を使用することができる。最初のステップとして、垂直方向の座標を使用して、同じラインにある入力フィールドとラベルのグループを、上部ラインおよび下部ラインからのそれらの距離の閾値を考慮に入れて検出する。第２のステップとして、水平方向の座標を使用して、拡張されたグループを検出する。図１０では、各ｙｎは垂直方向の座標によって定義される。各ｘｎも水平方向の座標によって定義できる。１−３（１乃至３）ラインに限れば、ラベル１−１だけがｘ１＜ｘ＜ｘ２に位置しているため、ラベル１−１は１乃至３ラインの全体のラベルになり得る。しかしながら４ラインにもｘ１＜ｘ＜ｘ２に位置するラベル４−１が存在する。従って、１−３ラインの入力フィールドおよびラベルを含むグループは拡張された入力グループ（extended input group）と見なすことができる。
【０１１０】
複数の入力グループを１つの拡張された入力グループに組み合わせるアイデアは、拡張された入力グループは全ての入力グループに適用される代表ラベルを有するという仮定に基づいている。与えられた例では、最初の列（column）にある代表ラベルが実際に最初のラインに出現し、この列に別の新たなラベルが現れるまでその最初のラインより下の全ての他のラインに有効である。この論法に基づいて、少なくとも１つのラインを１つの拡張された入力グループに組み合わせることができる。
【０１１１】
当業者にとっては変更が可能な例示的な実施形態を使ってこれまで本発明を詳しく説明してきたことについては言及しておかなくてはならない。例えば、フォーム記入モジュールをプロキシとしての代わりにブラウザまたは携帯電話機それ自体のコンポーネントとして実装することは可能であろう。さらに、自動フォーム記入モジュールはモバイル機器によってまたはときによってはインタネットなどのコンピュータネットワークを通じてスタンドアロン・コンピュータによってアクセスされることがあるポータル（portal）に実装される場合がある。あるいは、受け入れを改善し、この特徴を利用するためのハードルを最低限に抑えるため、フォーム記入はユーザがそれをダウンロードする時間を節約するために携帯電話機のデフォルト機能として実装される場合がある。さらに、ウェブフォームにアクセスするときにこの機能をダウンロードすることを考える必要がなくなる。
【０１１２】
当業者であれば、上述した実施形態およびそれらのコンポーネント、プロセスまたはモジュールはハードウェアまたはソフトウェアまたはそれらの組み合わせによって実現できることは理解されよう。特に、上記記述において説明された手続作業を実行する働きをするモジュールはコンピュータ上または携帯電話機、スマートフォン、スタンドアロンＰＣ、ＰＤＡなどの他の任意の計算機器上で実行される１つ以上のコンピュータプログラムによって実現可能である。
【図面の簡単な説明】
【０１１３】
【図１】本発明の実施の一形態による装置の概略構成図である。
【図２】異なる入力フォーム（または異なるウェブサイト）における『個人名（Name）』の入力フィールドに対する基本的に同じ意味を有する複数の異なる表現を列挙した図である。
【図３】本発明の実施形態に関連して使用されることがある入力フィールドを示す図である。
【図４】本発明の実施形態に関連して使用されることがある入力フィールドを示す図である。
【図５】本発明の実施形態に関連して使用されることがある入力フィールドを示す図である。
【図６】本発明の実施の一形態による装置の概略構成図である。
【図７】本発明の実施の一形態による装置の状態図である。
【図８】本発明の実施の一形態による装置の入力グループ認識モジュールの概略構成図である。
【図９】本発明の実施の一形態による装置の入力グループ認識モジュールの機能を説明するための図である。
【図１０】本発明の実施の更なる形態による装置の入力グループ認識モジュールの機能を説明するための図である。
【図１】
2008077634.tif 000004
【図２】
2008077634.tif 000005
【図３】
2008077634.tif 000006
【図４】
2008077634.tif 000007
【図５】
2008077634.tif 000008
【図６】
2008077634.tif 000009
【図７】
2008077634.tif 000010
【図８】
2008077634.tif 000011
【図９】
2008077634.tif 000012
【図１０】
2008077634.tif 000013
【外国語明細書】
2008077634.tif 000014
2008077634.tif 000015
2008077634.tif 000016
2008077634.tif 000017
2008077634.tif 000018
2008077634.tif 000019
2008077634.tif 000020
2008077634.tif 000021
2008077634.tif 000022
2008077634.tif 000023
2008077634.tif 000024
2008077634.tif 000025
2008077634.tif 000026
2008077634.tif 000027
2008077634.tif 000028
2008077634.tif 000029
2008077634.tif 000030
2008077634.tif 000031
2008077634.tif 000032
2008077634.tif 000033
2008077634.tif 000034
2008077634.tif 000035
2008077634.tif 000036
2008077634.tif 000037
2008077634.tif 000038
2008077634.tif 000039
2008077634.tif 000040
2008077634.tif 000041
2008077634.tif 000042
2008077634.tif 000043
2008077634.tif 000044
2008077634.tif 000045
2008077634.tif 000046
2008077634.tif 000047
2008077634.tif 000048
2008077634.tif 000049
2008077634.tif 000050
2008077634.tif 000051
2008077634.tif 000052
2008077634.tif 000053
2008077634.tif 000054
2008077634.tif 000055