JP2008077634A - モバイル機器におけるフォーム自動記入方法および装置 - Google Patents

モバイル機器におけるフォーム自動記入方法および装置 Download PDF

Info

Publication number
JP2008077634A
JP2008077634A JP2007191332A JP2007191332A JP2008077634A JP 2008077634 A JP2008077634 A JP 2008077634A JP 2007191332 A JP2007191332 A JP 2007191332A JP 2007191332 A JP2007191332 A JP 2007191332A JP 2008077634 A JP2008077634 A JP 2008077634A
Authority
JP
Japan
Prior art keywords
group
input
rule
input field
name
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007191332A
Other languages
English (en)
Other versions
JP4724158B2 (ja
Inventor
Chie Noda
チエ・ノダ
Fatih Coskun
ファティ・コスクン
Luca Alexander De
アレクサンダー・デ・ルーカ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Docomo Inc
Original Assignee
NTT Docomo Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NTT Docomo Inc filed Critical NTT Docomo Inc
Publication of JP2008077634A publication Critical patent/JP2008077634A/ja
Application granted granted Critical
Publication of JP4724158B2 publication Critical patent/JP4724158B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00Handling natural language data
    • G06F40/10Text processing
    • G06F40/166Editing, e.g. inserting or deleting
    • G06F40/174Form filling; Merging

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Artificial Intelligence (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Position Input By Displaying (AREA)
  • Document Processing Apparatus (AREA)
  • User Interface Of Digital Computer (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)
  • Machine Translation (AREA)

Abstract

【課題】 日本語ウェブサイトの複雑な入力フォームにも対応するモバイル機器用の自動フォーム記入装置を提供する。
【解決手段】 パーサーはフォームを解析して入力フィールドのグループを検出し、このグループのオブジェクトを生成する。グループルール検査モジュールは、ルールリポジトリ内のグループルールを前記オブジェクトと照合することによって前記グループに対応するグループ概念名を特定し、それにより前記グループの入力フィールドに対応する内部概念名の集合を特定する。内部ルール検査モジュールは、ルールリポジトリ内の内部ルールを前記オブジェクトと照合することによって、前記1セットの内部概念名によって前記グループに属する入力フィールドが記入される順序を特定する。記入モジュールは、前記グループに属する入力フィールドを前記内部概念名に対応する値を用いて前記順序に従って自動記入する。
【選択図】 図6

Description

本発明は、特にモバイル機器において、入力フォームを自動記入するための方法および装置に関する。
フォーム自動記入技術に関しては、ある手法が欧州特許出願第05109753.3号明細書に提案されている。本願実施形態はこの欧州特許出願と関連しており、しかも「概念名(concept name)」および「ルール(rule)」などの類似の手法を一部利用するため、この欧州特許出願の手法について、以下、手短に説明する。
欧州特許出願第05109753.3号明細書で提案されたフォーム記入方法では、ルールは、値(value)(例えば文字列、数字など)と、解析中の入力フィールドに関するその位置(その入力フィールドとの位置関係)とから成る。ルールが満たされるということは、そのルールによって定められた解析中の入力フィールドに関する位置にそのルールによって定められた値が見つかるということを意味する。ルールが満たされると、このルールに対応しフォームの当該入力フィールドに記入するために使用される所定の概念名(Concept Name)が結果としてもたらされる。あらゆるルールは、自動フォーム記入のための多量のオンラインで利用可能なフォームの評価に基づいて、それ自身の所定の確率(入力フィールドがこのルールに対応する概念名(Concept Name)によって実際に記入される確率)も更に含む。このことは、あらゆるルールの確率またはスコアが事前に定められ、入力フィールドチェックの際に計算される必要がないこと、そして、このためモバイル機器においてCPU時間が節約されることを意味する。フォームフィラー(form filler)はどのルールが議論している入力フィールドにフィットするかをチェックしさえすればよい。
チェック結果に基づいて、フォームフィラー(form filler)はマッチしたルールに従ってユーザデータを使用し、フォームにそのユーザデータを記入する。斯かる目的のため、例えばユーザデータを格納するデータ構造において、ユーザのファーストネーム(first name)に対するFirstNameのようないくつかの概念名(concept names)が、対応するユーザデータを特定するために定義されなければならない。概念名(concept names)は入力フィールドに記入するためのユーザデータと対応付けるために使用される。詳細については、これらの開示内容のすべてが引用することによって本発明の一部をなすものとする欧州特許出願第05109753.3号明細書を参照されたい。
フォーム記入ルールを生成するため、ウェブページ上の既存のフォームを解析することができる。同じく詳細については、開示内容のすべてが引用することによって本発明の一部をなすものとする欧州特許出願第05109753.3号明細書を参照されたい。
しかしながら、斯かる解析を実行すると、要求された概念名(concept names)とフォーム内おける入力フィールドの配置との間に多くの類似点が存在することがわかる。このため、ファーストネーム(FirstName)としてラベルされた入力フィールドにユーザデータのファーストネーム(first name)が記入される確率は極めて高い。単なる所見としてここでは、ユーザのファーストネーム(first name)から成るユーザデータは例えば概念名(すなわち、対応するユーザデータの内部的なラベリング)であるFirstNameまたはユーザのファーストネーム(first name)の概念名(concept name)として使用される何か他の識別子に対応する場合があるということに言及しておきたい。
さらに、入力フィールドのコンテクスト(context)も重要になり得る。コンテクストとはここでは、この具体的な入力フィールドがどのように定義されているか(例えば、HTML記述または他の「ソースコード」記述によって)、そしてその入力フィールドの周りにどのテキストまたは他のフォーム要素が存在しているかを意味している。例えば、1つのフォームの中でファーストネーム(first name)の後にラストネーム(last name)が要求される確率がある一定程度存在する。
ルールの集合を、図1に示すような自動フォーム記入装置に保存することができる。
ここで言うところのルールは、チェックされるべき条件(condition)と、その条件が満たされることがわかった場合に引き出される結論(conclusion)とを規定するものと見なすことができる。ルールの条件は、ある特定のパラメータ、例えば入力フォームを指定するHTML文書のある特定の部分が、その条件が満たされていると見なすべき場合にはある特定の値をとらなければならない、ということを定めるものでよい。斯かるパラメータは例えば、入力フィールドのラベル(label)である場合がある。入力フィールドのラベル(label)とは例えば、ブラウザ上の入力フィールドの直前に表示されるテキスト文字列である。別のパラメータとしては入力フォームのソースコード表現における入力フィールドの名前属性あるいはName属性(NameAttribute)が挙げられる。
ルールの結論は、条件が満たされることがわかった場合に入力フィールドに挿入されるべき値(value)である場合がある。以下の記述では、この結論のことをしばしば概念名(concept name)と呼ぶ。概念名とは、特定の事前に定められたユーザデータ、例えば名(first name)、姓(surname)、誕生日、年齢など、を識別するものと理解されるべきものである。ある特定の概念名(ConceptName)は1つの特定のタイプのユーザデータに対する識別子である。
以上の説明から、ルールの一般的な表現は次のようなものである。
パラメータ値(Parameter value)−概念名(ConceptName)
斯かるルールはある特定の入力フィールドに適用することができる。このことはルールが適用されるこの入力フィールドに対して入力フォームにおけるこのフィールドのパラメータがそのルールに定められたパラメータ値をとっているかどうかがチェックされることを意味する。定められたパラメータ値がとられている場合、条件がマッチし、結論を引き出すことが可能である。これが意味するところは、このようにしてチェックされた入力フィールドはそのルールに定められた概念名(ConceptName)により識別されるユーザデータを使用して記入されるべきことをそのルールが示した、という点である。
既に言及したように、1つの実施形態として、ルールを生成するために異なるパラメータ、例えば入力フィールドのラベルとその名前属性(NameAttribute)が使用されることがある。さらに、これらのパラメータはそのルールが適用される入力フィールドに関係している必要はないが、そのルールが適用される入力フィールドと比べて(例えば1つ前(上)または1つ後(下)にある入力フィールドといった)異なる入力フィールドのパラメータに関係している場合がある。このことは1つの実施形態としてルールのパラメータになり得る次のような6つのパラメータをもたらす。
Upper LABEL:1つ上の入力フィールドの前の最後のテキスト
Upper NAME_ATTRIBUTE_VALUE:1つ上の入力フィールドの名前属性の値
Current LABEL:現在の入力フィールド(そのルールが適用される実際の入力フィールド)の前の最後のテキスト
CURRENT NAME_ATTRIBUTE_VALUE:現在の入力フィールドの名前属性の値
Lower LABEL:1つ下の入力フィールドの前の最後のテキスト
Lower NAME_ATTRIBUTE_VALUE:1つ下の入力フィールドの名前属性の値
Upperとはルールが適用される現在の入力フィールドより前にHTML文書の中に最後に見出される1つ前の入力フィールドを指す。Lowerとはルールが適用される現在の入力フィールドより後にHTML文書の中に最初に見出される1つ後の入力フィールドを指す。本例では、ルールはパラメータに加えて現在チェックされている入力フィールド(そのルールが適用される入力フィールド)に関するそのパラメータの位置表示を含むことがわかる。
1つの実施形態として、各ルールは、条件が満たされた場合にその結論が実際に起こる尤度(likelihood)を示すスコアを更に割り当てている。このスコアは1つの実施形態では実際に、結論が正しい尤度である場合がある。尤度は既存の入力フォームの統計的評価から導き出されることがある。それは後述されるように更に動的に更新される場合がある。
1つの実施形態として、ルールリポジトリ(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)=尤度を表す0から100までの数字
<パラメータ(Parameter)|オペレータ(Operator)|値(Value)>部分はルールの条件を構成する。
パラメータ(Parameter)が、オペレータ(Operator)が規定する値(Value)と関係がある場合、その条件は満たされる。そして、このルールが適用されている入力フィールドに概念名(concept name)yが記入されなければならないという確率(Probability)をスコア(Score)により示して結論が引き出されることがある。
言い換えると、上で定義したルールは以下の要素から成る。
a)チェックされる条件(すなわち、解析されている入力フィールドに関するある特定の位置に、ある特定の値が存在している)。この条件はルールの中ではパラメータ(Parameter)|オペレータ(Operator)|値(Value)部分によって表される。値(Value)はある特定の変数が採る値を指す場合がある。変数は例えば、フォームに含まれており入力フィールドをラベルするラベル(label)である場合がある、あるいはそれ(変数)はフォームのソースコードの中で入力フィールドの名前を実際に指すラベル(label)である場合がある。この種のラベルは既に上で示した文字列で言えばNAME_ATTRIBUTE_VALUEである。
b)このルールに特有の概念名(concept name)およびこのルールに対応する概念名(concept name)がフォームへの記入に使用されるユーザデータを識別する確率(probability)
次にルールのいくつかの例をそれらの意味の説明と一緒に列挙する。
−CURRENT_NAME_ATTRIBUTE_VALUE|CONTAINS|firstname|ファーストネーム(FirstName)|100
入力フィールドの名前属性(CONCEPT_VALUE)がfirstnameを含む(CONTAINS)場合、入力フィールドにユーザのファーストネーム(FirstName)が記入されるべき確率は100%である。
−UPPER_NAME_ATTRIBUTE_VALUE|CONTAINS|firstname|ラストネーム(LastName)|81
現在の入力フィールドの1つ上にある入力フィールドの名前属性(UPPER_CONCEPT_VALUE)がfirstnameを含む(CONTAINS)場合、現在の入力フィールドにユーザのラストネーム(LastName)が記入されるべき確率は81%である。
−CURRENT_LABEL|CONTAINS|住所(address)|住所1(AddressStreet1)|46
入力フィールドの左側(LEFT)にある文字列が住所(address)を含む(CONTAINS)場合、入力フィールドにユーザの住所1(AddressStreet1)が記入されるべき確率は46%である。
欧州特許出願第05109753.3号明細書はこのような手法に基づく入力フォームの自動記入方法および装置を提案している。詳細についてはこの欧州特許出願明細書を参照されたい。また、これらの開示内容のすべてが引用することによって本発明の一部をなすものとする。
欧州特許出願第05109753.3号明細書の発明では、ダウンロードされたウェブページが構文解析され、あらゆる入力フィールドをチェックすることによって、対応するオブジェクト構造(object structure)が生成される。次にこのオブジェクト構造は、ある特定のルールが満たされるかどうかを、例えばルールのパターンとオブジェクト構造のパターンを比較することによってチェックするのに使用される。マッチが見つかれば、そのルールは満たされていると見なされる。詳細については欧州特許出願第05109753.3号明細書を参照されたい。
欧州特許出願第05109753.3号明細書に開示された手法は自動フォーム記入に使用することができる。しかしながら、実際の経験が示すように、各ルールに唯1つの条件では、特に日本語のウェブサイトにおいて、フォームに関連するより複雑なコンテンツを表すには不十分である。こうしたことは1つの概念名(concept name)に対する入力フィールドが2つ以上の入力フィールドに分割される場合および/または関連しているラベルが単一の場所に置かれない場合にしばしば起こる。
ユーザデータの入力フィールドを含む日本語の複数のウェブページの解析を通じて、先の欧州特許出願第05109753.3号明細書で定義されたルール構文(rule syntax)は時として十分でないことが分かった。日本語のウェブページの複雑さは次のいくつかの理由によって生じる。最初に、同じ意味を表す多くの表現が存在する、または、同じ表現でも意味が異なる場合もある。個人名(name)がその典型的な例である。図2に日本語のウェブサイトを解析すると見つかる可能性のある、フルネームに対する異なる表現、すなわちラベル(labels)、を示す。図中、左上から右下にかけて、「名前」、「お名前」、「なまえ」、「おなまえ」、「氏名」、「ご氏名」、「漢字氏名」、「カタカナ氏名」、「ローマ字氏名」、「姓名」、「セイメイ」、「宿泊代表者のお名前」は、全て個人名(name)を意味する。個人名(name)に対するラベルの1つである「名前」はある特定のコンテクストではファーストネームのみを表すのに使用される。
別の複雑さは、例えば『漢字』、『ひらがな』、および『カタカナ』の他に、『半角』(8ビット文字コード)と『全角』(16ビット文字コード)といった、異なる文字集合が存在する事実から来る。16ビット文字コードは主に漢字とひらがなに使用される。しかし16ビット文字コードは英数字にも割り当てられている。『カタカナ』は16ビット文字コードと8ビット文字コードの両方で表すことができる。図3にラストネーム(姓)およびファーストネーム(名)に異なる文字の入力を要求するウェブページ入力フォームの典型例を示す。ラベルである『お名前』と『おなまえ』は入力に使用する文字種(前者は漢字、後者はひらがな)を指定する。右側のラベル『(全角)』は(漢字とひらがなが16ビットでのみ表すことができるとしても)16ビット文字で記入しなければならないことを示す。異なるポジションにある複数のラベルとして与えられた全ての情報を組み合わせることで、自動フォーム記入方法は、フォームに記入すべき情報は最初の行では16ビット文字の漢字の『姓』(ラストネーム)および『名』(ファーストネーム)、次の行では16ビット文字のひらがなの『姓』および『名』であるという判断に到達すべきである。
要求される情報が2つ以上の入力フィールドに分割されることはよく起こることである。誕生日の記入が求められる場合、図4に示すように、年、月、日をそれぞれ記入するための3つの入力フィールドが存在する場合がある。最初のラベル『生年月日』は3つの入力フィールドの全てに適用される。各入力フィールドの右手にある各ラベルはそれぞれ、年、月、および日を意味する。考慮しなければならない別のポイントは一部のラベルがこのように入力フィールドの後に配置されることである。
特に日本語における、記入すべきウェブフォームの複雑さの解析から、入力フィールドにどの情報を記入すべきかの判断の基礎をそれらのラベルに置く自動フォーム記入方法は、
(i)1つのラベルだけでなく、ターゲットとする入力フィールドに関連する追加のラベルも、
(ii)左側ラベルに加えて右側ラベルも、
(iii)ラベルの語義上の意味および関連性も、
考慮すべきであるという結論に到達することができる。
一般的なウェブフォームを解析すれば、ほとんどのケースで、フィールドに正確な情報を記入する際に記入すべきフィールドから一般的には最大3つのラベルが重要になり得ることが見出される。例えば、図5において強調表示された左から2番目の入力フィールドがターゲットのとき、考慮すべきラベルは、ターゲットを基準にして最初の左ラベル『名』、3番目の左ラベル『お名前』、そして最初の右ラベル『(全角)』である。しかしながら、2番目の左ラベル『姓』はこの2番目のフィールドには適用できず、最初の入力フィールドにのみ適用可能である。これはある特定の入力フィールドを記入するためにどの概念名(concept name)を使用すべきかの判断の基礎となるルールはラベルの背後にある語義上の意味(semantic meanings)を考えてそれらが適正な情報を与えるか否かを判断する必要があることを意味する。これらのルールは語義に関してAND条件を表す場合がある。斯かるルールは入力フィールドのラベルの内容とそれらのポジションを規定するものである。斯かるルールに与えられた規定が入力フィールドとマッチすれば、これはこのルールに対応する概念名(concept name)がその入力フィールドを記入するために使用されるべきであることを意味する。図5の例では、最初の左ラベルが『名』、3番目の左ラベルが『お名前』、そして最初の右ラベルが『(全角)』であれば、概念名(concept name)は漢字のファーストネーム(first name)である。しかしながら、既に言及したように、漢字は本来8ビット文字コードではなく16ビット文字コードでのみ表すことができる。従って最初の右ラベル『(全角)』は冗長情報であり、わざわざ明記する必要はない。それゆえ、この場合の十分かつより適切なルールは、最初の左ラベルが『名』であり、かつ、3番目の左ラベルが『お名前』である場合には、概念名(concept name)は漢字のファーストネームとする、という形になる。
次に、図5に与えたようなフォームを記入するために適用することができるルールの構造について説明する。このルール構造は欧州特許出願第05109753.3号明細書において記述された構造と類似している。ルールは基本的に(日英併記の形で)、ポジション(Position)|条件(Condition)|値(Value)という構造から成る。ポジション(Position)は1つ以上のラベルの位置表示を意味し、条件(Condition)は当該ポジション(Position)に位置するラベルがどの値をとるかを示す。「概念名(concept name)」はこのルールから引き出される結論、すなわち当該条件が満たされた場合に当該フォームに記入すべき概念名(concept name)である。
ファーストネーム(名)とラストネーム(姓)から成る個人名の場合のように、互いに何らかの関係がある記入すべき入力フィールドが2つ以上存在するという事実を考慮するため、AND条件を使用して複数のルールを組み合わせることを考えることができる。
斯かるルールに対し、新たなルール構文(rules syntax)を次のように定義することができる。
(AND条件)+|=概念名(concept name)|確率(Probability)
ここで『(AND条件)+』は1つ以上の条件が存在すること意味する。
このAND条件のフォーマットは次のようなものである。
ポジション(Position)|条件(Condition)|値(Value)
それぞれにおいて、
・ポジション(Position)={L1、L2、L3、R1、R2、R3、
UPPER_LABEL、LOWER_LABEL、CURRENT_NAME_ATTRIBUTE、
UPPER_NAME_ATTRIBUTE、LOWER_NAME_ATTRIBUTE}
・条件(Condition)={CONTAINS、EQUALS}
この新たな構文(syntax)はAND関係によって単に複数の条件を組み合わせるだけであることが見て取れる。L1、L2、L3はそれぞれ、最初の左ラベル(ターゲットとする入力フィールドから左側にある最も近いラベル)、2番目の左ラベル(ターゲットとする入力フィールドから左側にある2番目に近いラベル)、3番目の左ラベルを示すことは言及しておきたい。R1、R2、R3は入力フィールドの右側のラベルに関して同じ意味を持つ。図5の例では、L1、L2、およびL3で示されたポジションが図5で強調表示された入力フィールドに関係する場合、L1は名、L2は姓、L3はお名前、ということになる。ルールにおける位置表示が関係するフィールドのポジションは実際にはそのルールを適用する入力フィールド(本例では図5で強調表示された入力フィールド)のポジションである。
以上の説明を踏まえて、図5に示したような強調表示された入力フィールドに対するルールは次のような形を採ることができる。
L1|EQUALS|名|L3|CONTAINS|名前|R1|CONTAINS|全角|=FirstNameKanji|85、
または、
L1|EQUALS|名|L3|CONTAINS|名前|=FirstNameKanji|80
FirstNameKanjiは漢字の名(ファーストネーム)を意味する概念名(concept name)である。
例示として、数字「85」および「80」(パーセントまたは何か他の尺度)は見つかった概念名(concept name)が正しい概念名である確率を示す。各ルールには確率のある決まった値が割り当てられる。さらに、「確率(%)」の代わりに、確率の指標となるスコア(数値)が使用される場合もある。
一部のルールによる入力フィールドへの記入の仕方についての知識を反映させて斯かるルールを生成するには、既存のフォームに使用される入力フィールドの中に共通のテキスト文字列(または「パターン」)が特定されることが必要とされる。しかしながら、日本語のウェブサイト、特に入力フィールドのラベルの中に、ルールで使用される共通のテキスト文字列を見出すことは、英語の場合よりも難しい。これは図2との関連で述べたように同じ意味に対して複数の表現が存在するためである。同じ概念名(concept name)に対する異なるルールの中に共通のテキスト部分文字列を見出すことができる場合、それらのルールはその部分文字列を使用することによって1つに併合し、より高い確率(例えば併合されたルールの累積確率)を設定することができる。このようしてルールは改善される余地が大いにある。
上述したようにラベルのAND条件に基づく拡張されたルール構文は全ての所与の条件が満たされる場合に有用である。しかしながら、それでも確率またはスコアに指標される発生率がより高いルールを見つけることはできない。
そこで本発明の課題は、このような場合にもより効率的に対処することができる異なるアプローチを提供することにある。
本発明は、上記課題を解決するため、モバイル機器上においてウェブベースのフォームを自動記入するための装置(フォーム自動記入装置)を提供する。本装置は、
ウェブベースのフォームを解析して、入力フィールドグループを検出するとともに、この入力フィールドグループを、このグループに属する入力フィールドの近傍(neighbourhood)を記述または画定する1つ以上のパラメータによって表現するオブジェクトを生成する入力グループ認識モジュール(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)とを具備する。
フォームの記入を、グループを検出し、グループ概念名を認識し、次いで前記検出されたグループ概念名に対して内部概念名の対応する順序を特定するといった具合に手続きを分離することで、検出された入力グループ内にある複数のラベルの情報を利用した、改善された認識結果が得られる。
本装置において、1つの態様として、グループルールは、
前記入力フィールドグループに属する入力フィールドの前記近傍内に現れる複数のパラメータを含んでおり、前記複数のパラメータは前記グループルールが満たされる場合には前記入力フィールドグループに属する入力フィールドの前記近傍内に存在する必要がある。
本装置において、1つの態様として、内部ルールは、
前記入力フィールドグループに属する入力フィールドの前記近傍内に現れるパラメータの順序、または、
前記入力フィールドグループに属する入力フィールドの数を含む。
本装置において、1つの態様として、前記入力グループ認識モジュールは、
開始境界と終了境界をチェックして、入力グループをこれらの境界内に存在するウェブベースのフォームの要素として決定するためのモジュールを含む。
本装置において、1つの態様として、前記境界は、
新たなラインタグ(line tag)またはテーブルタグ(table tag)、
テーブルの行の始点を指定するタグ、
テーブルの行の終点を指定するタグ、
行の上部境界を指定する座標値、
行の下部境界を指定する座標値、
行の右側境界を指定する座標値、
行の左側境界を指定する座標値、
の少なくとも1つ以上で画定される。
本装置において、1つの態様として、前記入力グループ認識モジュールは、
複数の入力グループ候補をそれらの1つ以上の候補が1つの拡張された入力グループに組み合わせられるかどうかに関して評価するためのモジュールを含み、このモジュールは、
入力グループ候補が1つ以上のグループルールと部分的にマッチするかどうかをチェックし、
部分的なマッチが検出された場合には、今度は他の入力グループ候補について、部分的なマッチが見つかった前記グループルールの他の部分との部分的にマッチするかどうかをチェックし、
斯かるチェックを、あるグループルールが前記部分的なマッチによって累積的に全面的にマッチするまで、更なる入力グループ候補について繰り返し、
斯かる全面的なマッチに到達した場合には、斯かる全面的なマッチに寄与した候補の入力グループを単一の拡張された入力グループに組み合わせるためのモジュールを含む。
本装置において、1つの態様として、前記候補の入力グループは単一の入力フィールドのみから成る。
本装置において、1つの態様として、前記入力グループ認識モジュールは、
入力フォームの要素の座標を決定するためのレアウト・インタプリタ・モジュール(layout interpreter module)と、
入力フォームの要素の座標を考慮する1つ以上のレイアウトルールに基づいてどの要素が入力グループを形成するために組み合わされるべきかを判定するレイアウト・ルール・モジュール(layout rule module)とを含む。
本装置において、1つの態様として、前記レイアウト・ルール・モジュールは、水平方向および/または垂直方向における要素の位置に対する1つ以上の閾値を前記判定の基礎として、それらの要素が入力グループに組み合わされるべきかどうかを決定する。
本装置において、1つの態様として、入力グループの要素は水平方向の座標境界に基づいて決定され、
垂直方向の座標に基づいて入力グループのある要素が複数の入力グループに対するラベルになることが判った場合、これらの複数の入力グループは1つの拡張された入力グループに組み合わされる。
本装置において、1つの態様として、前記グループルールは、前記グループルールに規定された複数の区別できるラベルを含むことが満たされるよう入力グループに対して要求する形をとり、前記複数のラベルは前記入力グループの任意の位置に存在して構わないものである。
本装置において、1つの態様として、グループルールおよび/または内部ルールはそれぞれの関連するスコアを含み、
スコアが100%未満の確率を示す複数のルールが入力グループとマッチする場合には、異なる概念名のコンセプトポイントが個別に足し上げられ、最高のスコアを有する概念名が選択される。
本装置において、1つの態様として、入力グループはオブジェクト構造(object structure)によって表現され、グループルールの評価はそのグループルールが前記入力グループに対応するオブジェクト構造とマッチするかどうかをチェックすることにある。
本発明は、上記課題を解決するため、モバイル機器上においてウェブベースのフォームを自動記入するための方法(フォーム自動記入方法)も提供する。本方法は、
ウェブベースのフォームを解析して、入力フィールドグループを検出するとともに、この入力フィールドグループを、このグループに属する入力フィールドの近傍を記述または画定する1つ以上のパラメータによって表現するオブジェクトを生成する入力グループ認識ステップと、
チェックされる条件とそれに対応する引き出される結論とを各ルールが含む複数のルールを含み、複数のグループルールと複数の内部ルールとを含むルールリポジトリであって、前記複数のグループルールにおいては、ルールが満たされることが判った場合に引き出される結論は、前記入力フィールドグループの区別できる語義上の意味に対応し、前記入力フィールドグループに属するフィールドに記入される値として内部概念名の集合を特定するグループ概念名であり、前記複数の内部ルールにおいては、各内部ルールがチェックされる条件とそれに対応する引き出される結論とを含み、その結論は、前記入力フィールドグループに属している入力フィールドに記入するために内部概念名が使用される順序に対応するものとなる、ルールリポジトリを提供するステップと、
前記グループルールを前記入力フィールドグループを表現する前記オブジェクトと照合することによって前記グループルールを評価して、前記入力フィールドグループに対応するグループ概念名を特定し、それにより前記入力フィールドグループに属する入力フィールドに記入するために使用されるべき内部概念名の集合を特定するグループルール検査ステップと、
前記内部ルールを前記入力フィールドグループを表現する前記オブジェクトと照合することによって前記内部ルールを評価して、前記グループルール検査ステップにより特定された前記グループ概念名に対応する前記内部概念名の集合によって、前記入力フィールドグループに属する入力フィールドが記入されるべき順序を特定する内部ルール検査ステップと、
前記入力フィールドグループに属する入力フィールドを、前記内部概念名に対応する値を用いて前記内部ルール検査ステップで決定された順序に従って自動記入するユーザデータ記入ステップとから構成される。
本方法は、1つの態様として、上記いずれかの態様の装置によって実行される方法ステップを更に含む。
本発明は、コンピュータ上で実行されるときにこのコンピュータが上記いずれかの態様の装置によって実行される方法ステップを実行することを可能にするコンピュータプログラムも提供する。
複数の入力フィールドが一緒になって、例えばファーストネーム(名)およびラストネーム(姓)から成る個人名(name)、あるいは、日、月および年から成る生年月日(birthday)といった、1つのグループを成す特定の情報を形成するタスクから説明を始めることにする。ここではグループを成す密接に関連する斯かる「複数の入力フィールド」に対するルールを見つける必要がある。
テーブル内の同じライン(line)または行(row、横列)に存在するラベルと入力フィールドだけを考えてよい。その目的のため、入力フォームのソースコードを参照することができる。例えば、HTMLソースでは、テーブル内のライン(line)は<BR>タグで区切られた1つの文字列として定義され、テーブル内の行(row)は<TR>タグ(htmlにおいてテーブル行の始点を指定する)で始まり</TR>タグ(htmlにおいてテーブル行の終点を指定する)で終わる1つの文字列として定義されることがある。
一般に、入力フィールドのグルーピングと関連情報の識別は、ソースコードの中に異なるレベルで見つかる場合がある位置情報(location information)を検出することによって実行することができる。単純なケースでは、ライン(line)は、新しいラインを開始する例えば<BR>タグ、またはテーブル内の行を指定する例えば<TR>タグで終わる1つの文字列として指定されることがある。もっと複雑なケースでは、座標情報が使用できる。
実施の一形態によれば、図6に示されたフォーム記入装置(form filling apparatus)が提供される。このフォーム記入装置には入力フォームが供給される。入力フォームは最初に受信された後、構文解析モジュール(parsing module)によって処理される。構文解析モジュールは、入力フィールドのグループ(各グループには後でいわゆるグループルールが適用される)を識別するタスクを実行する。入力フィールドの各グループは、1つの共通の総称的入力データ(以下、グループ概念名(group concept name)と呼ぶ)に一緒に属する入力フィールドを含む。各グループ概念名は、1つのグループに属する個別のフィールドを記入するために使用される内部概念名(inner concept names)の集合に対応する。グループ概念名は1例としては例えば「個人名(name)」(この場合の個別のフィールドはファーストネームとラストネーム)である。別の例としては、年、月および日といった個別の内部概念名から成る、「生年月日(birthday)」または「カード有効期限」が挙げられる。
パーサー(parser)によるグループの特定は、おおよその場所内にある、例えば既に言及したように<BR>によって区切られた、または<TR>タグと</TR>タグで挟まれたhtmlソース内にある、入力フォーム内にある入力フィールドを特定することによって実行されることがある。
入力フィールドのグループがパーサーによって特定され、対応するオブジェクト構造が生成されると、そのグループ(またはそのグループを表現する対応するオブジェクト構造)はグループルール検査モジュール(group rule inspecting module)に送られる。このグループルール検査モジュールはルールリポジトリにすでに記憶されている複数のグループルールを評価する。グループルールをパーサーによって特定された入力グループと照合する試みによって、グループ概念名(group concept name)が特定される。これは完全なマッチと100%の確率を与えるグループルールによって行われることがあるか、あるいは、マッチはするがより確からしさが低い(lower certainty)いくつかのグループルールが評価されることがあるとともに、以前の実施形態におけるようにそれらの累積スコアが決定されることがある。グループルールを評価した結果、区別できる語義上の意味によってグループを特定し、それに対応する事前に割り当てられた、そのグループに属する入力フィールドに後で記入するために使用される区別できる内部概念名(inner concept names)の集合を有する、「グループ概念名(group concept name)」が得られる。
グループ概念名が特定されると、その結果は図6に示す内部ルール検査モジュール(inner rule inspecting module)に送られる。この内部ルール検査モジュールは、グループ概念名に対応する内部概念名がそのグループに属する入力フィールドに記入するために使用されるべき順序を特定するタスクを実行する。これはいわゆる内部ルール(特定されたグループ概念名の内部ルール)を評価することによって実行される。それらの内部ルールはそれらを評価することによって内部概念名を使用して入力フィールドに記入するための順序について決定するための基礎として利用できるものである。この評価が実行されると、記入モジュールは次に、選択されたグループ概念名に属する内部概念名の値としてユーザのために記憶されている実際の値を参照し、これらの値を用いて、マッチが見つかった内部グループルールによって指定された順序でそのグループの入力フィールドに記入することによって、入力フォームへの実際の記入を行う。実施の一形態によれば、(ルールを次々にチェックするときに)最初のマッチを与える内部ルールが選択される。この場合、内部ルールにそれらの順序で優先順位を付けることが可能である。
本アプローチをグループ概念名を使用していない欧州特許出願第05109753.3号明細書の実施形態と比較して説明すると、概念名(グループ概念を使用しない以前のアプローチで述べた)はコンテクストの上でグループを成す1つの集合として一緒にグループ化される。というのは、こうしてグループ化された概念名は、共通の「グループ概念(group concept)」によって、従って「グループ概念名(group concept name)」によって代表させることができるからである。グループ概念名は故に、グループを成す区別できる概念名の集合を表す一種の「一般化された」概念名である。斯かるグループに属する個別の概念名は「内部概念名(inner concept names)」と呼ぶことができる。それに対し、グループ全体を表す概念名はグループ概念名と呼ぶことができる。グループ概念名は例えば内部概念名として「日」、「月」および「年」を有する「生年月日」の場合がある。グループ概念名の別の例としては、関連する内部概念名として「ファーストネーム(FirstName)」と「ラストネーム(LastName)」を有することがあるグループ概念名「個人名(Name)」の場合がある。
前述したように、本実施形態は2つ以上の入力フィールドから成る入力グループの検出に基づく。例えば、同じテーブルラインに存在する入力フィールドは1つの入力グループとみなすことができる。HTMLウェブページにおいて、しばしばテーブルタグは入力フィールドに語義的に関連するラベルを配置するために使用される。テーブルタグを検出することにより、入力グループが検出できる。テーブルタグを使用していないウェブページにも有効に働くもっと高度な技法として、あとでより詳しく説明するように、ラベルおよび入力フィールドが同じラインに配置されており、入力グループと見なされるかどうかを判断するために、座標情報が使用できる。入力グループが検出されたら、次の2つのステップ、すなわち、(i)入力グループに対する概念名を決定するステップと、(ii)選択されたグループに対する各入力フィールドの概念名を決定するステップを有するアルゴリズムが実行される。ステップ(i)では、実施の一形態によれば、入力グループにおけるラベルの外観が考察されるだけである。ステップ(ii)では、ラベルの順序またはグループ内にある入力フィールドの数が考慮される。
以前の実施形態と比べると、概念名の特定は3つの個別ステップ、つまり、入力グループを検出するステップ、入力グループに対する全体の概念名を特定するステップ、各入力フィールドの各概念名を特定するステップ、に分離される。このおかげで、より高い確率のルールを定義し、それによりシンプルな方法でより可能性の高いユーザデータがもたらされる。
次に、実施の更なる形態をより詳しく説明する。既に言及したように、1群の入力フィールド全体を考慮する入力グループルール(input Group rules)が導入される。入力グループ(input group)のシンプルな認識法として、テーブルの中のTR要素に使用される<TR>タグと</TR>タグをそれぞれ入力グループの始点と終点と見なすことができ、入力グループはそれが少なくとも1つの入力フィールドを含む場合に考える。日本語の自動フォーム記入の1つの実施形態では、入力グループの認識に、現在の入力グループの終点と(少なくとも1つの入力フィールドが存在する場合に限り)次の可能な入力グループの始点として</TR>タグのみが使用される。これは例えばテーブルの中にいくつかの部分テーブルが存在するなどの複雑な形で<TR>タグと</TR>タグがかなり頻繁に利用されるからである。こうした場合、<TR>タグを入力グループの始点と見なせば、一部の情報が見失われる。もちろん、入れ子になっているテーブルタグを扱えば認識が向上する可能性がある。しかしながら、後述するように、入力グループの他のもっと高度な認識技術も使用されることがある。
図3および図4に示した例に戻って説明を続ける。各ラインは1つの入力グループと見なすことができる。第1のステップとして、漢字個人名(NAME Kanji)、ひらがな個人名(Name Hiragana)、または生年月日(Birthday)のグループといった、グループの概念名を考えることにする。第2のステップとして、ラベルの順序に基づいて、例えば漢字個人名グループ(Name Kanji group)ではファーストネーム(First Name)またはラストネーム(Last Name)といった、どういった概念名が各入力フィールドに適用されるかが解析される。以下の2つのルールが導入される。
(i)入力グループに対する概念名を指定するための入力グループルール(Input Group rule)
(ii)選択されたグループに対する各入力フィールドの概念名を指定するための内部ルール(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)xを選択する確率(Probability)はy%である。
ルールの「確率(Probability)」または「スコア(Score)」は選択的でよく、ルールは実施の一形態ではスコアを一切含まないこともある。確率(Probability)の値(value)はヌル(null)の場合がある。
ルールは入力グループのパラメータに対する条件を指定する。「パラメータ」はここでは入力フィールドのラベルまたは入力グループ内部の任意のラベルである。
・Condition={CONTAINS、EQUALS}
CONTAINSは入力グループ内部の少なくとも1つのラベルが所与の値を含むことを意味する。
EQUALSは入力グループ内部の少なくとも1つのラベルが所与の値に等しいことを意味する。
・Group concept name=2つ以上の入力フィールドのグループに適用される、グループの概念名
・Probability=0から100までの値(確率)
グループルールは一般的に2つ以上の条件、すなわちAND条件、を有する。n個の条件が付いたルールは次のように表される。
Input_Group|Condition_1|Value_1|...|Input_Group|Condition_n|Value_n|=Group concept name|[Probability]
これは斯かるグループルールが満たされるためにはそのグループはグループ内のどこかに値1乃至n(Value_1~n)のラベルを含まないといけないことを意味する。
次に上記構文に基づくルールのもっと具体的な例を与える。本例では、先に導入した(AND条件)(「累積的条件(cumulative conditions)」とも称される)が入力グループルールに適用される。
・INPUT_GROUP|CONTAINS|名前|INNPUT_GROUP|CONTAINS|ふりがな
|=namehiragana_group|l00
入力グループINPUT GROUPのラベルが「名前」と「ふりがな」を含む場合にはNameHiragana_group(ひらがな個人名を意味するグループ概念名)を選択する確率は100%である。
・INPUT_GROUP|CONTAINS|名前|INNPUT_GROUP|CONTAINS|カタカナ
|=namekatakana_group|l00
入力グループINPUT GROUPが「名前」と「カタカナ」を含む場合にはNameKatakana_group(カタカナ個人名を意味するグループ概念名)を選択する確率は100%である。
上記ルールの中には位置表示が一切存在しないことに注意したい。これは、グループルールはラベルの位置を指定せずに実際のラベル(ラベルの「テキスト文字列」)を指定すること、そしてそれらのラベルはルールが満たされていると見なされる場合にはグループ内に存在しなければならないことを意味する。この要件は位置情報がルールの中に指定された以前の(背景技術で述べた)実施形態で述べたルールよりも緩いことは明らかである。このようにして、複数の入力フィールドを有するグループに対するルールを設計することはラベルの位置を考えなければならない態様と比べてより簡単なものになる。
しかしながら、要件は位置情報を省略することで以前の実施形態と比べて緩和されているのに対し、斯かるルールにおける要件は、ルールが、累積的に存在しなければならい2つ以上のパラメータ(ラベル)を規定するという意味で、より厳しいものとなっている。
一方、入力グループを(それらの境界により、従ってそれらの要素を検出することにより)適切に認識することにより、マッチするグループルールが存在するような関係のある情報を入力グループの要素が含むという蓋然性が、ラベルの位置をルールと照合するために要求した以前のアプローチと比べて、より高くなる。本実施形態では、要素の位置は、それが認識されたグループに属する限りは、問題にならない。
当業者にとっては斯かる手法はグループが単一の入力フィールドしか持たない場合にも適用可能であることは明白なものとなる。この場合、入力グループの要素はその入力グループを画定する境界内に存在する要素であり、このとき、位置に無関係なグループルールのチェックが既に述べたようにその条件が満たされるグループルールを見つけるために実行できる。あるグループルールがベストマッチ(およびその結果選択された対応するグループ概念名)を与えるものとして選択されたら、次に内部ルールがチェックされる。グループに単一の入力フィールドしか属していない場合、これは実施の一形態として内部概念名の値がその単一の入力フィールドに記入すべき単一の値に所定のスキームに従って併合されるという効果を持つ。
同じグループ概念名に属し、全ての満たされたルールのスコアを足し上げることで、グループの最も高い確率の概念名をもたらす前述した実施形態と同じアルゴリズムを適用することが可能である。一方、所与のグループに対して100%の確率のルールが見つかる場合、それはストレートに適用される。それ以外の場合、マッチするルールに従って各概念名のスコアが累積され、全ての適用可能なルールを解析した後に累積スコアの最も高いグループ概念名が選択される。
確率値がヌル(null)の場合、最初に選択されたルールが適用されることがある。従って同じグループ概念名に対するルールの順序は優先順位を表す場合がある。
上述した手法による入力グループの認識に基づいて、最も適切なグループ概念名を特定するためにグループルールがチェックされる。
グループ概念名を選択した後、各入力フィールドに適用される概念名を指定するために内部ルール(Inner rules)が適用される。実施の一形態によれば、2つのタイプの内部ルールが存在する。
(1)具体的な内部ルール
具体的な内部ルールは、グループ内に出現したラベルの順序と、それに応じた概念名のリストを指定する。入力フィールドは概念名の順序で記入される。ルール構文は次のように指定することができる。
Label_1|Label_2|...|Label_n
=>concept name_1|concept name_2|...|concept name_n
入力グループのラベルがLabel_1、Label_2、...、Label_nの順序で現れる場合には、n個の入力フィールドはconcept name_1、concept name_2、...、concept name_nの順序で記入するものとする。
次に、Name Hiragana_groupに対する2つの例を示す。
・姓|名=>Last Name Hiragana、First Name Hiragana
入力フィールドのラベルが姓(last name)と名(first name)の順序で現れる場合、2つの入力フィールドは概念名Last Name HiraganaとFirst Name Hiraganaで記入される。
・氏|名=>Last Name Hiragana、First Name Hiragana
入力フィールドのラベルが氏(last name)と名(first name)の順序で現れる場合には、2つの入力フィールドは概念名Last Name HiraganaとFirst Name Hiraganaで記入するものとする。
(2)数値的ルール
数値的ルールは入力グループにおける入力フィールドの数に基づいてラベルを考慮することなく規定する。数値的ルールは入力グループにいくつの入力フィールドnが存在するかを決定するだけである。そのルールは次のようなものである。
n=>concept name_1、concept name_2、...、concept name_n
グループ内にn個の入力フィールドが存在する場合、それらはconcept name_1、concept name_2、...、concept name_nの順序で記入される。
次にTelephone_group(電話番号を意味するグループ概念名)の2つの例を示す。
・1=>Tel1+‘−’+Tel2+‘−’+Tel3
グループ内に唯1つの入力フィールドしか存在しない場合、そのフィールドはTel1−Tel2−Tel3で記入される。
・3=>Tel1、Tel2、Tel3
グループ内に3つの入力フィールドが存在する場合、それらのフィールドはそれぞれTel1、Tel2、Tel3の順序で記入される。
実施の一形態によれば、フォームフィラー(From Filler)は次の3ステップ、すなわち入力グループ検出ステップ(入力グループの要素を決定する)、入力グループ認識ステップ(グループ概念名を決定する)、および内部ルール検出ステップ(入力フィールドを内部概念名で記入する際の入力順序の検出に対応する)、を実行する働きをする。図7に本発明の実施の一形態による入力グループ認識・記入に関する状態図を示す。以下、この状態図をより詳しく説明する。
(1)入力グループ検出(グループの解析)
HTMLパーサーはダウンロードされたウェブページを解析し、2つ以上の入力フィールドを含む場合がある各入力グループごとに1つのオブジェクト構造を生成する。入力グループを検出するシンプルな方法はテーブル要素を使用することである。拡張された入力グループ(enhanced input group)の検出は、ラベルおよび入力フィールドの正確な位置や、ラベル間の語義的な関連性などを用いることによって行われることがある。これについては詳しく後述する。さて、生成されたオブジェクト構造は入力グループ内の全ての入力フィールドとそれらのラベルを含む。実施の一形態によれば、これはグループの境界内に含まれる全てのテキスト文字列を含むことがある。入力グループ検出はパーサーとは別個のモジュールによって実行されることがある。このモジュールは、パーサーからの結果を利用して、一緒になって1つの入力グループを形成すべきフィールドを特定するとともに、その入力グループのオブジェクト構造(その入力グループに属するラベルまたは任意のテキスト文字列を含む)を形成する。このオブジェクト構造のおかげでルールを、この構造と照らし合わせてそれらのルールが満たされるかどうかをチェックする試みができる。このとき結果として生じるオブジェクト構造はグループルールと照合してグループルールが満たされるかどうかをチェックすることが試みられるものである。さらに、後で説明するように、内部ルールをこのオブジェクト構造に基づいてチェックすることも可能でなければならない。その目的のためのオブジェクト構造は入力グループに属する要素の1つの表現であり、それは、規定された構造の中に、ルールをこの構造と照合する試みによってルールチェックを実行するこができるようにするための必要な情報を含む。
(2)入力グループ認識(グループルールのチェック)
グループルールインスペクタ(Group Rule Inspector)は所与のオブジェクト構造に適用可能なグループルールを探索する。確率が100%のルールが見つかった場合には、その対応するグループ概念名が選択される。確率が100%未満のルールが見つかった場合には、各グループ概念名ごとにコンセプトポイント(concept points)が足し上げられる。グループルールのチェックは1つずつ試みられ、マッチした場合は、グループルールのスコアに応じてポイントが加算される。最後に、最高のコンセプトポイントスコアを持つ概念名グループが選択される。
(3)内部ルール検出(内部ルールのチェック)
ユーザデータフィラー(User Data Filler)は選択された概念名グループの内部ルールに従って入力フィールドをユーザデータで記入する。それはラベルの順序に基づいて各入力フィールドに適用可能な概念名を決定する。それは具体的な内部ルールに指定されるラベルの順序を検出する。電話番号、ファックス番号、および郵便番号の場合、数値的ルールを用いることによって、入力フィールドの数に基づいて全ての情報が連結または分離されるかどうかを検出することが可能である。内部ルールもマッチが見つかるまで1つずつ試みられ、その結果に基づいて入力グループが記入される。
グループが唯1つの入力フィールドから成る特殊なケースでは、対応する入力フィールドはこのグループに属する内部概念名に属する値によって記入される。グループ概念名が「生年月日」で、内部概念名が年、月および日の場合、1つしかない単一の入力フィールドは複数の内部概念名の値を単一のテキスト文字列に組み合わせることによって記入される。
作業(1)乃至(3)はそれぞれグループ検出モジュールによって特定された各入力グループごとに全ての入力グループがチェックし終わるまで実行される。
実施の一形態によれば、入力グループ認識は境界(始点と終点)の検出から成り、境界内のあらゆるもの(境界内に存在する入力フィールドだけでなく入力フィールドのラベルおよび任意のテキスト文字列も含む)が、対応する入力グループに属するものと考えられる。前述したように、例えばHTMLソースコードの中の<TR>および</TR>タグがこの目的ために使用されることがある。また、斯かるタグ内に存在するあらゆるものが、対応する入力グループに属するものと見なされる。検出された入力グループ(またはオブジェクト構造によるその表現)に対して、正しいグループ概念名を決定するためにそれが1つ以上のグループルールとマッチするかどうかがチェックされる。
座標に基づいて入力グループとその要素を認識するための別のアプローチについては後述する。しかしながら、特定の境界内に存在するコンテンツを決定することに基づくグループの認識は複数の入力フィールドがこれらの境界内に存在しなければならないことを必ずしも意味しないことは理解されよう。それ故、既に言及したタグなどのような境界メカニズムまたは後述する座標に基づいて検出される「グループ」は複数の入力フィールドを含むだけでなく、単一の入力フィールドだけを含んでも良い。
既に言及したように、実施の一形態によれば、グループ認識に使用される境界内に存在するあらゆるテキスト文字列(またはラベル)は入力グループに属するものと見なされる。
次に、本発明の実施形態による、入力グループの可能な強化された認識技術について説明する。第1の認識技術は入力グループを併合または拡張することに基づく。
拡張された入力グループ(extended input groups)は、テーブルタグを検出するだけではなく、入力グループ同士の間の語義上の関連性も考慮することによって特定することができる。これは拡張された入力グループの認識に入力グループルールを使用することによって遂行できる。このための認識アルゴリズムは次のステップを含むことがある。
(1)ある1つの候補の入力グループを例えばテーブルタグを解析することによって検出する。
(2)入力グループルールを調べる。
(2−1)この候補の入力グループに部分的にマッチするルールが存在する場合、この候補の入力グループを出発点として使用し、部分的にマッチしたグループルールを適用することによって、拡張された入力グループの構築を開始する。
(2−2)それ以外の場合、この入力グループを削除する。
(3)(2−1)の場合、次の候補の入力グループが上記ルールの他の部分とマッチするかどうかをチェックする。
(4)以下の条件の1つが満たされるまで繰り返す。
(4−1)あるグループルールの全体が(部分的なマッチの累積によって)全面的にマッチする。このとき、(全面的なマッチに寄与した)候補の入力グループのグループが、拡張された入力グループと見なされる。
(4−2)候補の入力グループのどのグループによってもグループルールに全面的にマッチしない。このとき入力グループを削除する。
上記のアルゴリズムは候補の入力グループが単一の入力フィールドしか含まない場合にも適用できることは理解されよう。言い換えると、このアルゴリズムは入力グループに組み合わされるべき入力フィールド(それらは最終的にグループルールとの全面的なマッチに寄与するため)と、これが当てはまらないものについてはグループ概念名ではなく個別の概念名のみが探索されるべき個別の入力フィールドとして取り扱われるべき入力フィールドを実際に特定するために使用されることがある。
従ってこのアルゴリズムは入力としてパーサーが入力フォームを構文解析することによって見出された(単一の入力フィールドのみを含む場合がある)個々の候補グループを使用することができる。それにも基づいて、このアルゴリズムは、候補の入力グループの組み合わせによって、拡張された入力グループを検出することができる。
次にこのアルゴリズムを以下の例を用いてより詳しく説明する。
以下のテーブルに示すようなウェブページのテーブルレイアウトを考える。このテーブルは3行を含む。各行は1つの入力フィールドとそれ自身のラベルを含む。下のテーブルには、このグループに対する全体のラベルと見なされるラベル、すなわち「住所(Address)」が存在する。
Figure 2008077634
次のような入力グループルールが存在すると考える。
INPUT_GROUP|contains|番地(Street)|INPUT_GROUP|contains|市町村(City)|
INPUT_GROUP|contains|国(Country)|=address_group
入力グループを認識するステップ(1)により、最初のラインが入力グループであると考えられる。それに対するルールは全く存在しないが、それが上記ルール(INPUT_GROUP|contains|番地(Street)...)に部分的にマッチするため、アルゴリズムは拡張された入力グループの構築を開始する。次の2つのグループに関しても、ルールの一部(国(Country)および市町村(City))がマッチする。それゆえ、このアルゴリズムはテーブルブロック全体を単一の拡張された入力グループと見なす。
テーブルタグを使用することによる入力グループ検出のための前述した技法はhtml構文解析の非常に早い段階で適用されるが、しかしそれらはテーブルレイアウトのないウェブサイトには機能しない。それゆえ、以下、HTML要素の座標を使用することによってあらゆるウェブサイトに機能するやや高度な技術について説明する。テーブルタグベースの認識とは対照的に、その技術はウェブサイトのレイアウト解釈を必要とする。
図8にHTML要素(すなわちラベルおよび入力フィールド)の座標を取り出すための機能ブロック図を示す。レイアウトインタプリタ(layout interpreter)は、HTMLパーサー(HTML parser)からオブジェクト構造と、スタイルシートパーサー(style sheet parser)からスタイル定義(style definitions)を取り出し、続いて座標を含む拡張されたオブジェクト構造を生成するコア(core)コンポーネントである。こうして得られた座標に基づいて、どの入力フィールドが入力グループに属するかに関する決定を実行することができる。
これは1つ以上のレイアウトルールをチェックしてどの要素が入力グループに組み合わされるべきかを決定するレイアウトルールモジュール(layout rule module)によって実行されることがある。
例えば、同じラインにある入力グループをラベルおよび入力フィールドの座標を用いて認識するために以下のような計算を適用することができる。入力フィールドおよびラベルのグループを形成するため、上部ラインと下部ラインからのそれらの距離に対する閾値を考慮に入れてエリアが画定されるものとする。図9において、1番目の入力フィールドは座標(x,y1)を有し、2番目の入力フィールドは座標(x,y2)を有し、そして1番目の入力フィールドの高さはhであると仮定する。このとき、上部入力フィールドと下部入力フィールドとの間の垂直方向の距離を計算することができる。本例では、1番目の入力フィールドと2番目の入力フィールドとの間の距離は次のようになる。
d=y2−(y1+h)
2番目の入力グループエリアの上部境界のy座標は次式で与えられる。
y=y1+h+d/2
このエリア(y=0とy=y1+h+d/2の間)内の座標を有するすべてのラベル(任意のテキスト文字列)および入力フィールドは1つの入力グループと見なすことができる。同様にして、他の全ての境界が計算できる。与えられた公式は一例に過ぎないことに留意されたい。エリアを検出するための閾値の定義に応じて、様々な公式を適用することができる。ここに示した技法はラインを見つけるために使用されるが、列(columns)にも適用できる。さらに、このアイデアは前述した候補の入力グループを組み合わせる技法と一緒にして使用することができる。
次に、図10を参照して、グループ認識機能を実現するための別の手法を使用する実施の更なる形態について説明する。
本実施形態では、拡張された入力グループを検出するために垂直方向と水平方向の座標情報を使用することができる。最初のステップとして、垂直方向の座標を使用して、同じラインにある入力フィールドとラベルのグループを、上部ラインおよび下部ラインからのそれらの距離の閾値を考慮に入れて検出する。第2のステップとして、水平方向の座標を使用して、拡張されたグループを検出する。図10では、各ynは垂直方向の座標によって定義される。各xnも水平方向の座標によって定義できる。1−3(1乃至3)ラインに限れば、ラベル1−1だけがx1<x<x2に位置しているため、ラベル1−1は1乃至3ラインの全体のラベルになり得る。しかしながら4ラインにもx1<x<x2に位置するラベル4−1が存在する。従って、1−3ラインの入力フィールドおよびラベルを含むグループは拡張された入力グループ(extended input group)と見なすことができる。
複数の入力グループを1つの拡張された入力グループに組み合わせるアイデアは、拡張された入力グループは全ての入力グループに適用される代表ラベルを有するという仮定に基づいている。与えられた例では、最初の列(column)にある代表ラベルが実際に最初のラインに出現し、この列に別の新たなラベルが現れるまでその最初のラインより下の全ての他のラインに有効である。この論法に基づいて、少なくとも1つのラインを1つの拡張された入力グループに組み合わせることができる。
当業者にとっては変更が可能な例示的な実施形態を使ってこれまで本発明を詳しく説明してきたことについては言及しておかなくてはならない。例えば、フォーム記入モジュールをプロキシとしての代わりにブラウザまたは携帯電話機それ自体のコンポーネントとして実装することは可能であろう。さらに、自動フォーム記入モジュールはモバイル機器によってまたはときによってはインタネットなどのコンピュータネットワークを通じてスタンドアロン・コンピュータによってアクセスされることがあるポータル(portal)に実装される場合がある。あるいは、受け入れを改善し、この特徴を利用するためのハードルを最低限に抑えるため、フォーム記入はユーザがそれをダウンロードする時間を節約するために携帯電話機のデフォルト機能として実装される場合がある。さらに、ウェブフォームにアクセスするときにこの機能をダウンロードすることを考える必要がなくなる。
当業者であれば、上述した実施形態およびそれらのコンポーネント、プロセスまたはモジュールはハードウェアまたはソフトウェアまたはそれらの組み合わせによって実現できることは理解されよう。特に、上記記述において説明された手続作業を実行する働きをするモジュールはコンピュータ上または携帯電話機、スマートフォン、スタンドアロンPC、PDAなどの他の任意の計算機器上で実行される1つ以上のコンピュータプログラムによって実現可能である。
本発明の実施の一形態による装置の概略構成図である。 異なる入力フォーム(または異なるウェブサイト)における『個人名(Name)』の入力フィールドに対する基本的に同じ意味を有する複数の異なる表現を列挙した図である。 本発明の実施形態に関連して使用されることがある入力フィールドを示す図である。 本発明の実施形態に関連して使用されることがある入力フィールドを示す図である。 本発明の実施形態に関連して使用されることがある入力フィールドを示す図である。 本発明の実施の一形態による装置の概略構成図である。 本発明の実施の一形態による装置の状態図である。 本発明の実施の一形態による装置の入力グループ認識モジュールの概略構成図である。 本発明の実施の一形態による装置の入力グループ認識モジュールの機能を説明するための図である。 本発明の実施の更なる形態による装置の入力グループ認識モジュールの機能を説明するための図である。

Claims (16)

  1. モバイル機器上においてウェブベースのフォームを自動記入するための装置であって、
    ウェブベースのフォームを解析して、入力フィールドグループを検出するとともに、この入力フィールドグループを、このグループに属する入力フィールドの近傍を記述または画定する1つ以上のパラメータによって表現するオブジェクトを生成する入力グループ認識モジュールと、
    チェックされる条件とそれに対応する引き出される結論とを各ルールが含む複数のルールを含み、複数のグループルールと複数の内部ルールとを含むルールリポジトリであって、前記複数のグループルールにおいては、ルールが満たされることが判った場合に引き出される結論は、前記入力フィールドグループの区別できる語義上の意味に対応し、前記入力フィールドグループに属するフィールドに記入される値として内部概念名の集合を特定するグループ概念名であり、前記複数の内部ルールにおいては、各ルールがチェックされる条件とそれに対応する引き出される結論とを含み、その結論は、前記入力フィールドグループに属している入力フィールドに記入するために内部概念名が使用される順序に対応するものとなる、ルールリポジトリと、
    前記グループルールを前記入力フィールドグループを表現する前記オブジェクトと照合することによって前記グループルールを評価して、前記入力フィールドグループに対応するグループ概念名を特定し、それにより前記入力フィールドグループに属する入力フィールドに記入するために使用されるべき内部概念名の集合を特定するグループルール検査モジュールと、
    前記内部ルールを前記入力フィールドグループを表現する前記オブジェクトと照合することによって前記内部ルールを評価して、前記グループルール検査モジュールにより特定された前記グループ概念名に対応する前記内部概念名の集合によって、前記入力フィールドグループに属する入力フィールドが記入されるべき順序を特定する内部ルール検査モジュールと、
    前記入力フィールドグループに属する入力フィールドを、前記内部概念名に対応する値を用いて前記内部ルール検査モジュールが決定した順序に従って自動記入するためのユーザデータ記入モジュールと
    を具備するフォーム自動記入装置。
  2. グループルールは、前記入力フィールドグループに属する入力フィールドの前記近傍内に現れる複数のパラメータを含んでおり、前記複数のパラメータは、前記グループルールが満たされる場合には前記入力フィールドグループに属する入力フィールドの前記近傍内に存在する必要があるものである、請求項1に記載のフォーム自動記入装置。
  3. 内部ルールは、
    前記入力フィールドグループに属する入力フィールドの前記近傍内に現れるパラメータの順序、または、
    前記入力フィールドグループに属する入力フィールドの数
    を含む、請求項1または2に記載のフォーム自動記入装置。
  4. 前記入力グループ認識モジュールは、
    開始境界と終了境界をチェックして、入力グループをこれらの境界内に存在するウェブベースのフォームの要素として決定するためのモジュールを含む、請求項1乃至3のいずれか1項に記載のフォーム自動記入装置。
  5. 前記境界は、
    新たなラインタグまたはテーブルタグ、
    テーブルの行の始点を指定するタグ、
    テーブルの行の終点を指定するタグ、
    行の上部境界を指定する座標値、
    行の下部境界を指定する座標値、
    行の右側境界を指定する座標値、
    行の左側境界を指定する座標値、
    の少なくとも1つ以上で画定される、請求項4に記載のフォーム自動記入装置。
  6. 前記入力グループ認識モジュールは、
    複数の入力グループ候補をそれらの1つ以上の候補が1つの拡張された入力グループに組み合わせられるかどうかに関して評価するためのモジュールを含み、このモジュールは、
    入力グループ候補が1つ以上のグループルールと部分的にマッチするかどうかをチェックし、
    部分的なマッチが検出された場合には、今度は他の入力グループ候補について、部分的なマッチが見つかったグループルールの他の部分とが部分的にマッチするかどうかをチェックし、
    斯かるチェックを、あるグループルールが前記部分的なマッチによって累積的に全面的にマッチするまで、更なる入力グループ候補について繰り返し、
    斯かる全面的なマッチに到達した場合には、斯かる全面的なマッチに寄与した候補の入力グループを単一の拡張された入力グループに組み合わせるためのモジュールを含む、請求項1乃至5のいずれか1項に記載のフォーム自動記入装置。
  7. 前記候補の入力グループが単一の入力フィールドのみから成る請求項1乃至6のいずれか1項に記載のフォーム自動記入装置。
  8. 前記入力グループ認識モジュールは、
    入力フォームの要素の座標を決定するためのレアウト・インタプリタ・モジュールと、
    入力フォームの要素の座標を考慮する1つ以上のレイアウトルールに基づいてどの要素が入力グループを形成するために組み合わされるべきかを判定するレイアウト・ルール・モジュールとを含む、請求項1乃至7のいずれか1項に記載のフォーム自動記入装置。
  9. 前記レイアウト・ルール・モジュールは、水平方向および/または垂直方向における要素の位置に対する1つ以上の閾値を前記判定の基礎として、それらの要素が入力グループに組み合わされるべきかどうかを決定する、請求項8に記載のフォーム自動記入装置。
  10. 入力グループの要素は水平方向の座標境界に基づいて決定され、
    垂直方向の座標に基づいて入力グループのある要素が複数の入力グループに対するラベルになることが判った場合、これらの複数の入力グループは1つの拡張された入力グループに組み合わされる、請求項1乃至9のいずれか1項に記載のフォーム自動記入装置。
  11. 前記グループルールは、前記グループルールに規定された複数の区別できるラベルを含むことが満たされるよう入力グループに対して要求する形をとり、前記複数のラベルは前記入力グループの任意の位置に存在して構わないものである、請求項1乃至9のいずれか1項に記載のフォーム自動記入装置。
  12. グループルールおよび/または内部ルールはそれぞれの関連するスコアを含み、
    スコアが100%未満の確率を示す複数のルールが入力グループとマッチする場合には、異なる概念名のコンセプトポイントが個別に足し上げられ、最高のスコアを有する概念名が選択される、請求項1乃至11のいずれか1項に記載のフォーム自動記入装置。
  13. 入力グループはオブジェクト構造によって表現され、グループルールの評価はそのグループルールが前記入力グループに対応するオブジェクト構造とマッチするかどうかをチェックすることにある、請求項1乃至12のいずれか1項に記載のフォーム自動記入装置。
  14. モバイル機器上においてウェブベースのフォームを自動記入するための方法であって、
    ウェブベースのフォームを解析して、入力フィールドグループを検出するとともに、この入力フィールドグループを、このグループに属する入力フィールドの近傍を記述または画定する1つ以上のパラメータによって表現するオブジェクトを生成する入力グループ認識ステップと、
    チェックされる条件とそれに対応する引き出される結論とを各ルールが含む複数のルールを含み、複数のグループルールと複数の内部ルールとを含むルールリポジトリであって、前記複数のグループルールにおいては、ルールが満たされることが判った場合に引き出される結論は、前記入力フィールドグループの区別できる語義上の意味に対応し、前記入力フィールドグループに属するフィールドに記入される値として内部概念名の集合を特定するグループ概念名であり、前記複数の内部ルールにおいては、各ルールがチェックされる条件とそれに対応する引き出される結論とを含み、その結論は、前記入力フィールドグループに属している入力フィールドに記入するために内部概念名が使用される順序に対応するものとなる、ルールリポジトリを提供するステップと、
    前記グループルールを前記入力フィールドグループを表現する前記オブジェクトと照合することによって前記グループルールを評価して、前記入力フィールドグループに対応するグループ概念名を特定し、それにより前記入力フィールドグループに属する入力フィールドに記入するために使用されるべき内部概念名の集合を特定するグループルール検査ステップと、
    前記内部ルールを前記入力フィールドグループを表現する前記オブジェクトと照合することによって前記内部ルールを評価して、前記グループルール検査ステップにより特定された前記グループ概念名に対応する前記内部概念名の集合によって、前記入力フィールドグループに属する入力フィールドが記入されるべき順序を特定する内部ルール検査ステップと、
    前記入力フィールドグループに属する入力フィールドを、前記内部概念名に対応する値を用いて前記内部ルール検査ステップで決定された順序に従って自動記入するユーザデータ記入ステップと
    から構成されるフォーム自動記入方法。
  15. 請求項1乃至13のいずれか1項に記載された装置によって実行される方法ステップを更に含む請求項14に記載のフォーム自動記入方法。
  16. コンピュータ上で実行されるときにこのコンピュータが請求項1乃至13のいずれか1項に記載された装置によって実行される方法ステップを実行することを可能にするコンピュータプログラム。
JP2007191332A 2006-07-24 2007-07-23 モバイル機器におけるフォーム自動記入方法および装置 Expired - Fee Related JP4724158B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP06117765.5 2006-07-24
EP06117765A EP1887478A1 (en) 2006-07-24 2006-07-24 Apparatus for automatic form filling on mobile devices

Publications (2)

Publication Number Publication Date
JP2008077634A true JP2008077634A (ja) 2008-04-03
JP4724158B2 JP4724158B2 (ja) 2011-07-13

Family

ID=37607059

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007191332A Expired - Fee Related JP4724158B2 (ja) 2006-07-24 2007-07-23 モバイル機器におけるフォーム自動記入方法および装置

Country Status (2)

Country Link
EP (1) EP1887478A1 (ja)
JP (1) JP4724158B2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009282745A (ja) * 2008-05-22 2009-12-03 Internatl Business Mach Corp <Ibm> ウェブページの入力項目への入力を支援する方法、コンピュータ・プログラム及び端末
JP2013200843A (ja) * 2012-03-26 2013-10-03 Fujitsu Ltd 入力支援プログラム、入力支援装置、及び入力支援方法

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9026899B2 (en) * 2012-07-13 2015-05-05 Sap Se User interface including field explorer listing available fields for population
US9785627B2 (en) 2014-01-23 2017-10-10 Xerox Corporation Automated form fill-in via form retrieval
EP3271837A4 (en) * 2015-03-17 2018-08-01 VM-Robot, Inc. Web browsing robot system and method
US9582230B1 (en) 2015-10-09 2017-02-28 Xerox Corporation Method and system for automated form document fill-in via image processing

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004501426A (ja) * 2000-04-28 2004-01-15 アメリカ オンライン インコーポレーティッド インターネット対話を自動化するための記録済みデータを実行する方法およびシステム
JP2004062446A (ja) * 2002-07-26 2004-02-26 Ibm Japan Ltd 情報収集システム、アプリケーションサーバ、情報収集方法、およびプログラム
JP2004513419A (ja) * 2000-10-13 2004-04-30 アメリカ オンライン インコーポレイテッド インターネットのやりとりを自動化する方法及びシステム
JP2005327260A (ja) * 2004-05-12 2005-11-24 Microsoft Corp インテリジェントな自動記入システム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6088700A (en) * 1999-08-06 2000-07-11 Larsen; Kenneth N. Automated forms completion for global information network applications
US20020062342A1 (en) * 2000-11-22 2002-05-23 Sidles Charles S. Method and system for completing forms on wide area networks such as the internet

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004501426A (ja) * 2000-04-28 2004-01-15 アメリカ オンライン インコーポレーティッド インターネット対話を自動化するための記録済みデータを実行する方法およびシステム
US20040068693A1 (en) * 2000-04-28 2004-04-08 Jai Rawat Client side form filler that populates form fields based on analyzing visible field labels and visible display format hints without previous examination or mapping of the form
JP2004513419A (ja) * 2000-10-13 2004-04-30 アメリカ オンライン インコーポレイテッド インターネットのやりとりを自動化する方法及びシステム
JP2004062446A (ja) * 2002-07-26 2004-02-26 Ibm Japan Ltd 情報収集システム、アプリケーションサーバ、情報収集方法、およびプログラム
JP2005327260A (ja) * 2004-05-12 2005-11-24 Microsoft Corp インテリジェントな自動記入システム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009282745A (ja) * 2008-05-22 2009-12-03 Internatl Business Mach Corp <Ibm> ウェブページの入力項目への入力を支援する方法、コンピュータ・プログラム及び端末
US10095675B2 (en) 2008-05-22 2018-10-09 International Business Machines Corporation Inputting data to a web page
US11222169B2 (en) 2008-05-22 2022-01-11 International Business Machines Corporation Inputting data to a web page
JP2013200843A (ja) * 2012-03-26 2013-10-03 Fujitsu Ltd 入力支援プログラム、入力支援装置、及び入力支援方法

Also Published As

Publication number Publication date
JP4724158B2 (ja) 2011-07-13
EP1887478A1 (en) 2008-02-13

Similar Documents

Publication Publication Date Title
US7958444B2 (en) Visualizing document annotations in the context of the source document
US9208185B2 (en) Indexing and search query processing
US8667004B2 (en) Providing suggestions during formation of a search query
US8005819B2 (en) Indexing and searching product identifiers
US8254681B1 (en) Display of document image optimized for reading
CN100550016C (zh) 基于可视间隙的文档分割
JP4427500B2 (ja) 意味解析装置、意味解析方法および意味解析プログラム
US8433704B2 (en) Local item extraction
US20080263032A1 (en) Unstructured and semistructured document processing and searching
JP4724158B2 (ja) モバイル機器におけるフォーム自動記入方法および装置
US20020198859A1 (en) Method and system for providing web links
JPH11110416A (ja) データベースからドキュメントを検索するための方法および装置
US10140297B2 (en) Supplementing search results with information of interest
CN110716991B (zh) 基于电子书的实体关联信息的展示方法及电子设备
JP4865526B2 (ja) データマイニングシステム、データマイニング方法及びデータ検索システム
EP1745396A1 (en) Document information mining tool
CN112818200A (zh) 基于静态网站的数据爬取及事件分析方法及系统
KR100901134B1 (ko) 형태소 분석과 소스코드 분석을 통한 추천 태그 표시시스템
Shao et al. Webevo: taming web application evolution via detecting semantic structure changes
CN112230989B (zh) 网页频道导航栏提取方法、系统、电子设备及存储介质
CN115270723A (zh) Pdf文档拆分方法、装置、设备及存储介质
US11461407B1 (en) System, method, and computer program product for tokenizing document citations
CN116362223B (zh) 一种网页文章标题和正文的自动识别方法及装置
JP4106889B2 (ja) 情報検索システム
JP3166995B2 (ja) コメント付与方法及び文書処理装置

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100914

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110401

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110408

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140415

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees