JPWO2009066762A1 - ユーザインタフェース認識装置及びユーザインタフェース認識方法 - Google Patents

Abstract

検索ルール生成部（２５０２）は、ユーザインタフェースを構成する部品群及び部品群の位置関係を示すユーザインタフェース情報と、部品群の中で検索対象とする部品を示す検索対象部品情報と、ユーザインタフェースの構造を定義する構造定義情報とに基づいて、検索対象とする部品を検索するための検索ルールを予め生成する。部品検索部（２５０３）は、新たなユーザインタフェース情報が入力されたときに、予め生成しておいた検索ルールを用いて、新たなユーザインタフェース情報に示される部品群の中から検索対象とする部品を検索する。これにより、構造が不明確でかつ変化するユーザインタフェースについて、正しく部品を特定できるようになる。

Description

本発明は、主にアプリケーションが出力するユーザインタフェースの構造を認識するユーザインタフェース認識システムに関し、特にユーザインタフェースの表示が変化した場合にも構造を認識できるユーザインタフェース認識装置及びユーザインタフェース認識方法に関する。

従来、ワールドワイドウェブ（World Wide Web、以下ＷＷＷ）やデスクトップで動作するプログラムなどのアプリケーション（Application：以下ＡＰという）は、当初からそのＡＰのプログラムに作りこまれたグラフィカルユーザインタフェース（Graphical User Interface：以下ＧＵＩという）によって、ユーザに直接的に操作されてきた。

しかしながらこのようなＡＰの開発者によって作りこまれたＧＵＩは、必ずしも利用者（ユーザ）に適した形にはなっていない。例えば利用者によるＡＰの操作を記録しユーザの行動を分析したいような場合でも、ＡＰのＧＵＩは必ずしも利用者のＧＵＩの操作記録をログとして出力する機能を備えるとは限らない。また、利用者の趣味、嗜好や利用環境の違いなどにより、利用者がＧＵＩの画面のレイアウトを変更したり、ＡＰの操作の自動化を望む場合でも、ＡＰが必ずしもこのような変更や自動化の機能を備えるとは限らない。これはＡＰ開発者がこのような全ての要求を考慮し、全ての機能を作りこむことは非常に大きな開発コストを必要とするため、現実的ではない事による。

このような問題に対処するために、ＡＰ自身のプログラムには修正を加えずに、ＡＰが出力したＧＵＩに対して、外部プログラムがＧＵＩの内容を認識し制御を加えることで、前記のような機能を追加する事がしばしば行われている。ＡＰが出力したＧＵＩは多くの場合、ボタンやテキストといった基本的なＧＵＩ部品と、それらのレイアウト情報しか持っていないため、例えばどのボタンが押されたかといったログの記録や、ＡＰの操作の自動化のためにユーザに代わり特定のボタンを押すというイベントを発行するためには、前記のような外部プログラムは、レイアウト情報から各ＧＵＩ部品を一意に識別するような処理を行う。例えば、ＷＷＷアプリからの情報の抽出やＷＷＷアプリの自動操作などをユーザが行おうとした場合、ユーザは、要素部品とそのレイアウト情報のみを持つＨＴＭＬのみを用いてユーザインタフェース（User Interface：以下ＵＩという）を認識し、文字列や入力フォームなどの要素部品の意味を推定する。なお、本明細書においては、このような処理をＵＩの認識と呼ぶ。

ＡＰが出力したＵＩを認識する技術としては以下のものがある。
例えば、文献１（特開２００４−２４０７５９号）では、ＵＩの操作ログ取得のために、文字認識や画像認識、部品の階層構造の取得によってＵＩの認識を実現する手法を開示している。
また、文献２（特開２００１−３０６３５８号）では、ＧＵＩのテストのために、ＧＵＩの論理構造を記録し、保存した論理構造間の比較結果を用いてテスト結果の判定やテスト実行可否判断などを実現する手法を開示している。
また、生成されたＵＩの認識ではないが、文献３（特表２００７−５１１８１４号）では、紙などに書かれたＵＩのイメージ画を認識してＵＩプログラムを生成する手法を開示している。

しかしながら、上述したＵＩを認識する技術では、構造が不明確でかつ変化するＵＩを、正しく部品を特定できるように認識することは困難であるという問題がある。

一般にＵＩのレイアウトは様々な要因で変化する。例えば、ＵＩの内容は同じでも、オペレーティングシステムの種類、ＷＷＷであればＷＷＷブラウザの種類、コンピュータの表示装置の画面サイズ、ウィンドウシステムで使用される場合はそのアプリケーションのウィンドウサイズなど、アプリケーションを使用する環境が変化するとレイアウトも変わってしまう場合がある。また、例えば、何らかの検索を行った結果を表示するＷＷＷページなど、動的に変化するコンテンツを表示するＵＩの場合、例えば検索結果のヒット数など、コンテンツによってレイアウトが変わってしまう場合がある。また、ＡＰのプログラム自身のバージョンアップなど、ＡＰの変化によってもレイアウトが変わってしまう場合がある。

このうち、同じ内容の表示レイアウトが環境によって変化するものは、文献１や文献２で開示されているように、部品の親子関係などＧＵＩ部品間の論理的な構造を抽出し、この情報に基づいてＵＩを認識することで対応することが出来る。特にＷＷＷでは元々ＵＩはハイパーテキストマークアップランゲージ（Hyper Text Markup Language：以下ＨＴＭＬという）という構造化文書によって出力されているため、このＨＴＭＬを分析すれば、ＨＴＭＬを解釈し、表示を行う環境に依存せずにＵＩを認識することが出来る。

しかしながら、ＵＩに含まれるコンテンツや元のＡＰ自身が変化した場合、前記の論理的な構造自身が変化してしまうため、単なる論理構造の抽出のみでは、ＵＩを正しく認識することは出来ない。

また、文献４（特開２００４−３１８４６０号）では、変化するＵＩの触感制御を実現する手法を開示しているが、これはＡＰがＵＩの構造情報を提供する前提であり、そのような情報を出力しないＡＰには適用できない。

本発明は、上記事情に鑑みてなされたものであり、コンテンツやＡＰによるＵＩの変化があっても、正しくＵＩを認識することが出来るユーザインタフェース認識装置及びユーザインタフェース認識方法を提供することを目的とする。

このような目的を達成するために、本発明のユーザインタフェース認識装置は、ユーザインタフェースを構成する部品群及び部品群の位置関係を示すユーザインタフェース情報と、部品群の中で検索対象とする部品を示す検索対象部品情報と、ユーザインタフェースの構造を定義する構造定義情報とに基づいて、検索対象とする部品を検索するための検索ルールを生成する検索ルール生成部と、新たなユーザインタフェース情報が入力されたときに、検索ルール生成部により生成された検索ルールを用いて、新たなユーザインタフェース情報に示される部品群の中から検索対象とする部品を検索する部品検索部と、部品検索部による検索結果を出力する出力部とを備える。

また、本発明のユーザインタフェース認識方法は、ユーザインタフェースを構成する部品群及び部品群の位置関係を示すユーザインタフェース情報と、部品群の中で検索対象とする部品を示す検索対象部品情報と、ユーザインタフェースの構造を定義する構造定義情報とに基づいて、検索対象とする部品を検索するための検索ルールを生成するステップと、新たなユーザインタフェース情報が入力されたときに、検索ルールを用いて、新たなユーザインタフェース情報に示される部品群の中から検索対象とする部品を検索するステップと、検索結果を出力するステップとを備える。

本発明によれば、ＡＰのコンテンツ変化に伴うＵＩの変化に対応したＵＩ部品の特定が可能となる。その理由は、本発明では、コンテンツ変化に伴うＵＩの変化を構造定義情報として認識し、これを用いて部品の検索ルールを作成することで、コンテンツ変化に伴う構造の変化を考慮した検索を行えるからである。

図１は、本発明の第一の実施形態の構成を示すブロック図である。 図２は、本発明の第一の実施形態の動作を示す流れ図である。 図３は、本発明の第二の実施形態の構成を示すブロック図である。 図４は、本発明の第二の実施形態の動作を示す流れ図である。 図５は、本発明の第二の実施形態の動作における、改変後検索ルール生成の動作を示す流れ図である。 図６は、本発明の第三の実施形態の構成を示すブロック図である。 図７は、本発明の第三の実施形態の動作を示す流れ図である。 図８は、本発明の第四の実施形態の構成を示すブロック図である。 図９は、本発明の第四の実施形態の動作を示す流れ図である。 図１０は、本発明の第四の実施形態の動作における、木構造情報変換の動作を示す流れ図である。 図１１は、本発明の具体例１の構成を示すプロック図である。 図１２は、本発明の具体例１の出力ＵＩのイメージ図である。 図１３は、本発明の具体例１の出力ＵＩの木構造情報のイメージ図である。 図１４は、本発明の具体例１の入力サンプルのイメージ図である。 図１５は、本発明の具体例１の構造定義情報のイメージ図である。 図１６は、本発明の具体例１の出力ＵＩとその構造定義情報のイメージ図である。 図１７は、本発明の具体例１の出力ＵＩのイメージ図である。 図１８は、本発明の具体例１の出力ＵＩのイメージ図である。 図１９は、本発明の具体例１の新構造定義情報のイメージ図である。 図２０は、本発明の具体例１の構造定義情報の対応関係のイメージ図である。 図２１は、本発明の具体例２の構成を示すプロック図である。 図２２は、本発明の具体例２の出力ＵＩのイメージ図である。 図２３は、本発明の具体例２の木構造情報のイメージ図である。 図２４は、本発明の具体例２の木構造情報のイメージ図である。 図２５は、本発明の他の実施形態の構成を示すブロック図である。

以下、本発明を実施するための最良の形態について添付図面を参照して詳細に説明する。

〔第一の実施の形態〕
まず、本発明のＵＩ認識装置の第一の実施の形態について、要点を説明する。
本発明のＵＩ認識装置の第一の実施の形態では、まずＵＩからＧＵＩ部品と部品間の関係（レイアウト）を抽出し、包含関係や位置関係を反映した木構造情報として表現する。情報の表現方法の好適な例は、エクステンシブルマークアップランゲージ（eXtensible Markup Language：以下ＸＭＬという）のデータモデルである。ＵＩが元々ＡＰからＨＴＭＬやＸＭＬの形式で出力される場合には、この文書をそのまま使用する事ができる。

その上で、ＵＩ認識を行う事前準備段階として、ＵＩ認識装置に対して、幾つかのＵＩの表示サンプルと、表示サンプルの中で特定したい部品とを入力する。これを分析することで、木構造情報で変化する可能性のある部分を、その変化の仕方の範囲と共に推測する。逆にＧＵＩ部品の中での例えばテキストの表示を行う部分など本来内容が変化する能力がありながら、実際には一切変化しない固定的な部分も推測する。この推測結果を用いて、木構造情報の構造定義情報を作成する。また同時に表示サンプル中で特定したい部品を検索するための検索ルールを、この構造定義情報を用いて、ＵＩの変化があっても矛盾が生じないよう作成する。こうして得られたＵＩの構造定義情報と部品の検索ルールを保存しておく。

実際にＵＩの認識を行う場合、まずＵＩを木構造情報で表現し、これに対して検索ルールを適用することで、特定したい部品を見つけ、これを出力する。

次に、本発明のＵＩ認識装置の第一の実施の形態の構成について、図１を参照して詳細に説明する。図１は、本発明のＵＩ認識装置の第一の実施の形態の構成を示すブロック図である。

図１を参照すると、本発明のＵＩ認識装置の第一の実施の形態は、ＡＰが出力するＵＩに関する情報（ＵＩ情報）を取得し、取得したＵＩ情報に基づいて、木構造情報を生成するＵＩ情報収集部１０１と、木構造情報と検索対象部品リストを記録するＵＩ情報保存部１０３と、ＵＩ情報保存部１０３に保存された木構造情報及び検索対象部品リストに基づいて、構造定義情報と検索ルールリストを生成するＵＩ構造推定部１０２と、生成された構造定義情報と検索ルールリストを保存するＵＩ構造定義情報保存部１０４と、木構造情報に検索ルールを適用して該当部品を得る部品検索部１０５と、検索名と検索ルール適用結果を合わせて出力する部品出力部１０６とからなる。

上記各部について以下に説明する。
ＵＩ情報収集部１０１は、ＡＰが出力するＵＩに関する情報（ＵＩ情報）を取得する。ＵＩ情報とは、ＵＩを構成する部品群を示す情報と、それら部品群の位置関係（レイアウト）を示す情報とを含む。そして、ＵＩ情報収集部１０１は、取得したＵＩ情報に基づいて、ＵＩを木構造で表現した木構造情報を生成する。また、ＵＩ情報収集部１０１は、事前準備段階である場合、ＵＩを構成する部品群の中で検索対象となる部品（特定対象となる部品）を示す情報（検索対象部品情報）と、その部品の検索名（識別子）を示す情報とを合わせて、検索対象部品リストとして取得する。ＵＩ情報収集部１０１は、事前準備段階である場合、生成した木構造情報と、検索対象部品リストとをＵＩ構造推定部１０２に出力する。一方、ＵＩ認識段階である場合、ＵＩ情報収集部１０１は、生成した木構造情報を部品検索部１０５に出力する。

ＵＩ構造推定部１０２は、ＵＩ情報収集部１０１から渡された、木構造情報と、検索対象部品リストとをＵＩ情報保存部１０３に保存する。そして、ＵＩ構造推定部１０２は、構造定義推定が指示されると、ＵＩ情報保存部１０３に保存した木構造情報に基づいて、ユーザインタフェースの構造を定義する構造定義情報を生成する。また、ＵＩ構造推定部１０２は、生成した構造定義情報と、ＵＩ情報保存部１０３に保存した木構造情報及び検索対象部品リストとに基づいて、検索ルールリストを生成する。検索ルールリストは、検索名と検索ルールの組からなる。検索ルールリストは、構造定義情報に基づくことにより、ＵＩに変化があっても矛盾が生じないように作成される。ＵＩ構造推定部１０２は、生成した構造定義情報及び検索ルールリストを、ＵＩ構造定義情報保存部１０４に出力する。

ＵＩ構造定義情報保存部１０４は、ＵＩ構造推定部１０２から渡された構造定義情報及び検索ルールリストを保存し、部品検索部１０５に渡す。

部品検索部１０５は、ＵＩ構造情報保存部１０４から取得した検索ルールを、ＵＩ情報収集部１０１から取得した木構造情報に適用し、適用結果の部品を検索ルールの検索名と合わせて部品出力部１０６に出力する。

部品出力部１０６は、検索名と検索結果のセットを、ＵＩ認識を利用したいＡＰの拡張装置に出力する。

次に、本発明のＵＩ認識装置の第一の実施の形態の動作について、図２を参照して詳細に説明する。図２は、本発明のＵＩ認識装置の第一の実施の形態の動作を表すフローチャートである。

ＵＩ認識装置は、まずＳ２０１で、ＡＰが出力するＵＩの表示サンプル（ＵＩ情報）、ＵＩを構成する部品群の中で検索対象となる部品（検索対象部品）及びその部品の検索名を示す情報の入力を待つ。それらの情報が入力されると、Ｓ２１１で、ＵＩ情報収集部１０１は、表示サンプルに基づいて木構造情報を生成する。また、ＵＩ情報収集部１０１は、検索対象部品と、その検索名とを関連付け、検索対象部品リストとして取得する。そして、ＵＩ情報収集部１０１は、生成した木構造情報と、取得した検索対象部品リストとをＵＩ構造推定部１０２へ出力する。Ｓ２１２で、ＵＩ構造推定部１０２は、木構造情報及び検索対象部品リストをＵＩ情報保存部１０３に保存する。

次にＳ２１０で、表示サンプルの入力が終了したら、Ｓ２２０で、ＵＩ構造推定部１０２は、ＵＩ情報保存部１０３に保存されている木構造情報を用いて構造定義情報を生成する。そして、Ｓ２２１で、ＵＩ構造推定部１０２は、生成した構造定義情報と、木構造情報と、検索対象部品リストとに基づいて、検索ルールリストを生成する。Ｓ２２２で、ＵＩ構造推定部１０２は、検索ルールリストをＵＩ構造定義情報保存部１０４に保存する。

次にＳ２３０で、認識を行うＵＩ情報を待つ。ＵＩ情報が入力されると、Ｓ２４０で、ＵＩ情報収集部１０１は、ＵＩ情報に基づいて木構造情報を生成して部品検索部１０５に出力する。部品検索部１０５は、Ｓ２５０で、検索ルールリストに検索ルールがあれば取り出し、Ｓ２５１で、木構造情報に適用して部品を検索する。そして、部品検索部１０５は、検索した部品とその検索名をセットにして部品出力部１０６に出力して、次の検索ルールを取り出す。

Ｓ２５２で、全ての検索ルールの適用が終了したら、Ｓ２６０で、部品出力部１０６は、検索名と検索結果部品のリストを拡張装置に出力し、Ｓ２３０で、ＵＩ情報待ちに戻る。

以上説明したように、本発明のＵＩ認識装置の第一の実施の形態によれば、ＡＰのコンテンツ変化に伴うＵＩの変化に対応したＵＩ部品の特定が可能となる。その理由は、ＵＩ認識装置がコンテンツ変化に伴うＵＩの変化を構造定義情報として認識し、これを用いて部品の検索ルールを作成することで、コンテンツ変化に伴う構造の変化を考慮した検索を行えるからである。

〔第二の実施の形態〕
まず、本発明のＵＩ認識装置の第二の実施の形態について、要点を説明する。
本発明のＵＩ認識装置の第二の実施の形態では、第一の実施の形態に加え、アプリケーションが改変されてＵＩの構造が変化した時に、事前準備として、改変後のＵＩの表示サンプルから構造定義情報を生成することに加え、改変前後の構造情報の差分の計算を行って改変前の部品が改変後にどこに移動したかを検出する。そして、この検出結果と改変前の検索ルールを用いて、改変後のＵＩに対する検索ルールを生成し、改変後の構造情報と検索ルールを保存する事を行う。

実際にＵＩの認識を行う場合、この改変後の検索ルールを用いて特定したい部品を見つける。

次に、本発明のＵＩ認識装置の第二の実施の形態の構成について、図３を参照して詳細に説明する。図３は、本発明のＵＩ認識装置の第二の実施の形態の構成を示すブロック図である。なお、以下の説明において、第一の実施の形態と共通する項目は同じ符号を用いるとともに、その説明は省略する。

第二の実施の形態では、図３に示すように、第一の実施の形態の構成に加え、二つの構造定義情報の差分を計算する構造差分計算部３０１を持つ。また、ＵＩ構造定義情報保存部３０２は、新たに新構造定義情報と新検索ルールリストを持つ。

次に、本発明のＵＩ認識装置の第二の実施の形態の動作について、図４、５を参照して詳細に説明する。図４、５は、本発明のＵＩ認識装置の第二の実施の形態の動作を表すフローチャートである。なお、以下の説明において、第一の実施の形態と共通する項目は同じ符号を用いるとともに、その説明は省略する。

第二の実施の形態では、図４に示すように、ＵＩ入力を待つ前にＳ４０１でＡＰ改変が行われたかを確認し、改変が行われた場合、Ｓ４０２で、改変後の検索ルール生成を行う。

図５は、図４のＳ４０２の改変後検索ルール生成の動作の詳細を表すフローチャートである。Ｓ２０１,Ｓ２１０,Ｓ２１１,Ｓ２１２,Ｓ２２０で改変後のＵＩの表示サンプルから構造定義情報を生成するところまでは、上記第一の実施の形態で説明した、改変前の処理と同じである。ここで、生成された、ＵＩ改変後の構造定義情報は、Ｓ５０１で一旦新構造定義情報としてＵＩ構造定義情報保存部３０２に保存される。

次に、構造差分計算部は、Ｓ５１０で、構造定義情報（ＵＩ改変前の構造定義情報）と新構造定義情報（ＵＩ改変後の構造定義情報）とを比較して、改変前の部品が改変後のどの部品に対応するかを調べ、Ｓ５１１でこの対応関係と検索ルールリストから、改変後のＵＩから部品を取り出すための新検索ルールリストを生成し、Ｓ５１２で新検索ルールリストとしてＵＩ構造定義情報保存部３０２に保存し、最後にＳ５２０で新たに生成された新構造定義情報と新検索ルールリストをそれぞれ構造定義情報と検索ルールリストにコピーする。

これにより、ＡＰ改変が行われてＵＩ構造が大きく変化した場合でも、新ＵＩに対応した部品の検索ルールを生成し、引き続きＵＩの認識を行う事が出来る。

以上説明したように、本発明のＵＩ認識装置の第二の実施の形態によれば、ＡＰ自身が改変されＵＩの構造が大きく変化した場合にも、表示サンプルの入力のみで改変前と同様なＵＩ部品の特定が可能となる。その理由は、ＡＰ改変前後のＵＩの構造定義間の差分計算を行い部品の対応関係を検出することで、ＡＰ改変前に指定されていた部品を、ＡＰ改変後で検索するルールを構築できるからである。

〔第三の実施の形態〕
まず、本発明のＵＩ認識装置の第三の実施の形態について、要点を説明する。
本発明のＵＩ認識装置の第三の実施の形態では、第一の実施の形態に加えて、実際にＵＩの認識を行う時に、ＵＩの木構造情報と、予め作成しておいた構造定義情報とが矛盾していないかを検証する。矛盾が無ければ通常通り部品検索を行うが、検証に失敗した場合、認識は行わずに認識失敗を出力する。

次に、本発明のＵＩ認識装置の第三の実施の形態の構成について、図６を参照して詳細に説明する。図６は、本発明のＵＩ認識装置の第三の実施の形態の構成を示すブロック図である。なお、以下の説明において、第一の実施の形態と共通する項目は同じ符号を用いるとともに、その説明は省略する。

第三の実施の形態では、図６に示すように、第一の実施の形態の構成に加え、ＵＩ認識時に入力されたＵＩが、ＵＩ構造定義情報保存部に保存されている構造定義情報と矛盾していないかを検証するＵＩ構造検証部６０１を持つ。

次に、本発明のＵＩ認識装置の第三の実施の形態の動作について、図７を参照して詳細に説明する。図７は、本発明のＵＩ認識装置の第三の実施の形態の動作を表すフローチャートである。なお、以下の説明において、第一の実施の形態と共通する項目は同じ符号を用いるとともに、その説明は省略する。

第三の実施の形態では、図７に示すように、Ｓ２４０で木構造情報を生成した後、Ｓ７０１で木構造情報が構造定義情報と矛盾していないかを検証し、Ｓ７０２で検証に成功した場合のみＳ２５０からの検索ルールの適用を行い、検証に失敗した場合、Ｓ７０３で認識失敗という結果を出力し、Ｓ２３０で次のＵＩ入力待ちとなる。

これにより、ＵＩの表示サンプルからは構造定義を完全に推定できなかった場合に、誤った構造定義の推定に基づいた検索ルールを適用し部品を誤認識する事を回避することが出来る。

以上説明したように、本発明のＵＩ認識装置の第三の実施の形態によれば、ＵＩの表示サンプルからは構造定義を完全に推定できなかった場合に、誤った構造定義の推定に基づいた検索ルールを適用し部品を誤認識する事を回避することが出来る。その理由は、ＵＩの木構造情報が事前に作成した構造定義情報に合致するかを検証することで、構造定義情報及びそれから作られる検索ルールが、認識しようとしているＵＩでも有効であるかを識別できるからである。

〔第四の実施の形態〕
まず、本発明のＵＩ認識装置の第四の実施の形態について、要点を説明する。
本発明のＵＩ認識装置の第四の実施の形態では、第一の実施の形態に加えて、ＵＩの木構造情報を詳細化あるいは簡略化する構造変更ルールを持ち、ＵＩの木構造情報を別の木構造情報に変換して、変換された木構造情報を構造の推定や部品の検索に用いる。

次に、本発明のＵＩ認識装置の第四の実施の形態の構成について、図８を参照して詳細に説明する。図８は、本発明のＵＩ認識装置の第四の実施の形態の構成を示すブロック図である。なお、以下の説明において、第一の実施の形態と共通する項目は同じ符号を用いるとともに、その説明は省略する。

第四の実施の形態では、図８に示すように、第一の実施の形態の構成に加え、ＵＩ情報収集部１０１が出力する木構造情報を別の木構造情報に変換するためのＵＩ構造変換部８０１と、構造変換ルールを保存する構造変換ルール保存部８０２を持つ。

次に、本発明のＵＩ認識装置の第四の実施の形態の動作について、図９、１０を参照して詳細に説明する。図９、１０は、本発明のＵＩ認識装置の第四の実施の形態の動作を表すフローチャートである。なお、以下の説明において、第一の実施の形態と共通する項目は同じ符号を用いるとともに、その説明は省略する。

第四の実施の形態では、図９に示すように、Ｓ２１１とＳ２４０でそれぞれ木構造情報を生成した後、Ｓ９０１とＳ９０２で木構造情報変換処理を行い、変換された結果を構造定義の推定や検索に用いる。

図１０は、図９に示すＳ９０１とＳ９０２の木構造情報変換処理の動作の詳細を表すフローチャートである。ＵＩ構造変換部８０１は、Ｓ１００１で構造変換ルール保存部８０２に保存された構造変換ルールを調べ、未適用のものがあればＳ１００２でルールを順次適用し変換を行う。２つ目以降に適用されるルールは、その前の変換ルール適用結果に対してルールを適用する。全ての構造変換ルールが適用されたらＳ１００３で結果を出力する。

これにより、ＨＴＭＬなどタグなど構造情報がコンテンツの意味を適切に表現していなかったり、オペレーティングシステム（Operating System：以下ＯＳという）のＧＵＩ部品を直接用いるＡＰから取得したＵＩ情報などで構造情報が欠落してフラットな構造しか見えないような場合、典型的なＵＩの生成ルールを判別するヒューリスティックなルールを用意し、これを適用することで、より構造定義の推定や部品の検索を容易に実現可能になる。

以上説明したように、本発明のＵＩ認識装置の第四の実施の形態によれば、ＨＴＭＬなどタグなど構造情報がコンテンツの意味を適切に表現していなかったり、ＯＳのＧＵＩ部品を直接用いたＡＰから取得したＵＩ情報などで構造情報が欠落してフラットな構造しか見えないような場合、典型的なＵＩの生成ルールを判別するヒューリスティックなルールを用意し、これを適用することで、より構造定義の推定や部品の検索を容易に実現可能になる。その理由は、ＵＩの木構造情報を変換するルールを保存し適用することが可能であるからである。

以上、本発明の第一〜第四の実施の形態についてそれぞれ説明したが、各実施の形態を任意に組み合わせるようにしてもよい。

次に、本発明のＵＩ認識装置を用いた具体例について説明する。具体例として、本発明のＵＩ認識装置を情報抽出装置に用いた場合について以下に説明する。

〔具体例１〕
図１１は、本発明のＵＩ認識装置を用いた情報抽出装置の構成図である。
情報抽出装置１１０１は、本発明のＵＩ認識装置１１０２と、自動制御部１１０３と、抽出情報保存部１１０４、管理部１１０５を持ち、ＵＩ情報収集部１０１とＡＰ自動制御部１１０３はＷｅｂブラウザ１１１０に接続されている。Ｗｅｂブラウザは複数の個人住所情報を保存するＷＷＷアプリケーションである住所録ＡＰ１１１１に接続されている。

住所録ＡＰ１１１１はＵＩとしてＨＴＭＬを出力する。

ＵＩの部品とレイアウト情報はブラウザによってドキュメントオブジェクトモデル（Document Object Model：以下ＤＯＭという）として解析済みのＨＴＭＬの形でＵＩ情報収集部に入力され、木構造情報の形式はこのＤＯＭ形式をそのまま用いる。

部品を検索するための検索ルールは、エックスエムエルパスランゲージ（以下Xpathという）で表現する。

構造定義情報は、ＨＴＭＬ中に出現する要素や属性などのノードについて、固定的に常に出現するノードと、毎回値が変化するノードと、出現回数が変化するノードに分類する形で表現する。

図１２は、住所録ＡＰ１１１１がブラウザに出力するＵＩであるＨＴＭＬのイメージ図である。なお本図は説明のために簡略化しており必ずしも正しいＨＴＭＬではないが、この事は本発明に影響を与えるもので無い事は容易に理解できるだろう。

住所録ＡＰ１１１１はこのようなＵＩで住所情報を表示し、”Next”のリンクをクリックすると次の人の情報を表示する。住所情報は、住所、氏名、電話番号、会社名で構成され、電話番号は任意の数持つことが出来る。

図１３は、図１２のＨＴＭＬのＤＯＭ形式表現のイメージ図である。
情報抽出装置１１０１は、ＡＰ自動制御部１１０３を用いて自動的に”Next”のリンクをクリックして次々と保存されている住所情報を表示する共に、氏名と会社名の情報を抽出して抽出情報保存部１１０４に保存する。

これを実現するために、自動制御装置は、”Next”に相当するリンク（<A>タグ）と、氏名と会社名の値の記載されている要素値のノード（図１３の四角で囲ったノード）をＵＩ部品として特定しなければならない。

〈動作例１〉
次に、本発明のＵＩ認識装置を用いた情報抽出装置の動作の一例について説明する。

まず事前準備として、管理部１１０５はＷｅｂブラウザでＵＩのサンプルを表示し、そのサンプル画面と、その画面上で特定したい部品と、その検索名をＵＩ情報収集部１０１に入力する。

図１４は、入力する３つの表示サンプルとそれぞれで特定したい３つの部品とその検索名である。

ここで検索名は、氏名は”名前”、会社名は”社名”、Nextのリンクは”次”という検索名を用いる。

まずＵＩ構造推定部１０２は、入力されたＨＴＭＬのＤＯＭ表現を木構造情報に変換するが、この場合ＤＯＭ表現が既に木構造情報であるためそのまま出力する。

次にＵＩ構造推定部１０２は、表示サンプルの木構造情報１,２,３とそれぞれの検索対象部品リスト１,２,３の情報をＵＩ情報保存部１０３に保存する。

３つのサンプルが全て入力し終わると、管理部１１０５はＵＩ構造推定部１０２にサンプル入力の終了を通知する。

通知を受けたＵＩ構造推定部１０２は、まずＵＩ情報保存部１０３に保存されている木構造情報１,２,３を分析し、固定的に常に出現するノードと、毎回値が変化するノードと、出現回数が変化するノードを推測する。

図１５は、分析結果で得られる構造定義情報のイメージ図である。ＨＴＭＬに出現するタグ名や要素値などがそのまま表記されている部分は固定的に出現するノードを、’＊’と表記されている部分は毎回値が変化するノードを、’＾Ｎ’と表記されている部分は出現回数が変化する部分を示している。

次にＵＩ構造推定部１０２は、検索対象部品リストを用いて、構造定義情報の中で検索しなければならない対象を調べる。この場合、図１５の四角で囲ったノードがそれぞれ検索対象となるノードとその検索名であることが分かるため、次にこれらの検索対象ノードを特定するためのXPath式を生成する。

一般に、ある木構造情報の中で、特定のノードを指定するXPath検索式は複数導出しうる。

本発明ではXPath式の導出方法は特に規定しないが、本具体例１としては、以下の３つのルールを用いて導出する。
［ルール１］
木構造情報の根から該当ノードにいたるパスを兄弟ノード間の位置とともに指定する。
例えば、図１５で”次”に該当する’A’タグのノードを指定するXPath式は、”/ＨＴＭＬ/A[１]”と記載できる。これは、ＨＴＭＬタグの中にあるAタグの中で２番目に出現するタグ、という意味である。
［ルール２］
該当ノードの子ノードの中で、該当ノードを一意に特定可能なノードの存在を条件として指定する。
例えば、図１５で”次”に該当する’A’タグのノードを指定するXPath式は、”//A[./text（）=Next]”と記載できる。これは、任意の場所に現れる 'A’タグの中で、特に要素値が’Next’であるもの、という意味である。
［ルール３］
該当ノードの共通の先祖を持つノードの中で、該当ノードを一意に特定可能なノードの存在を条件として指定する。
例えば、図１５で”名前”に該当する要素値のノードを指定するXPath式は、”//text（）[../../TD[１]/text（）=氏名]”と記載できる。これは、任意の場所に現れる要素値の中で、特に２つ親のノード（TRタグ）の中の１番目に出現するTDタグの要素値が’氏名’であるもの、という意味である。

これらのルールは全てが必ずしも導出できるとは限らない。例えば”社名”に該当するノードは、（１）を用いて”/ＨＴＭＬ/Table/TR[４]/TD/text（）”と表現することはできない。これはTRタグの兄弟間での位置が、電話番号の数によって変わってしまうため、必ずしも４番目にはならないからである。

このためＵＩ構造推定部１０２は、これらのルールによってXPathの導出を試み、その中で正しく対象ノードを一意に特定できるXPathの一つを検索式として採用する。この結果、’名前’、’社名’、’次’のそれぞれの検索式は "/ＨＴＭＬ/Table/TR[２]/TD[２]/text（）”、”//text（）[../../TD[１]/text（）=会社名]”、”/ＨＴＭＬ/A[１]”となる。

ＵＩ構造推定部１０２は、前記構造情報と検索名とXPath式のリストをＵＩ構造定義情報保存部３０２の構造定義情報と検索ルールリストにそれぞれに保存する。

次に実際のＵＩ認識を行う。
住所録ＡＰ１１１１が図１６のＨＴＭＬを出力した場合、ＵＩ情報収集部１０１はＷｅｂブラウザ１１１０からそのＤＯＭ表現を取得し、これをＵＩ構造検証部６０１に渡す。

ＵＩ構造検証部６０１は、与えられたＨＴＭＬのＤＯＭ表現とＵＩ構造定義情報保存部３０２に保存されている構造定義情報を比較し、矛盾が無いかをチェックし、問題ないためＨＴＭＬのＤＯＭ表現を部品検索部１０５に渡す。

部品検索部１０５は、ＵＩ構造定義情報保存部３０２に保存されている検索ルールリストを取り出し、検索ルールである３つのXPath式を適用して’名前’、’社名’、’次’のそれぞれに該当するノードを特定し、部品出力部１０６を通してＡＰ自動制御部１１０３に検索名と該当ノードを通知する。

ＡＰ自動制御部１１０３は、’名前’と’社名’に該当する要素値を抽出情報保存部１１０４に保存し、次にＷｅｂブラウザに対して’次’に該当するリンクをクリックしたイベントを送り、次ページを保存する。

〈動作例２〉
次に、図１７のサンプルには無かった二つの住所を持ったＨＴＭＬが出力された場合の動作を説明する。

この場合、ＵＩ情報収集部の動作までは図１６の例と同じだが、ＵＩ構造検証部６０１での比較で住所を二つ持つと言う矛盾が発見されるため、検証に失敗する。

この結果認識に失敗した旨がＡＰ自動制御部１１０３に通知され、その結果情報抽出処理は中断される。

もし検証を行わずに検索式を適用した場合、名前に該当する部分に本来住所である’茨城’の文字列が該当してしまうため、誤った結果が抽出されることになる。

このような中断が発生した場合、情報抽出装置の利用者は、図１７も含むサンプルを与えなおすことで、正しい検索ルールを作り直すことが出来る。

〈動作例３〉 次に、住所録ＡＰ １１１１が改変され、出力されるＵＩが図１８のように変わった場合の動作を説明する。

この改変では、管理される住所情報自体に変化は無いが、タイトル、Nextボタンの位置、項目名の太文字などが変更されている。

ここでは、まず新しいＵＩのサンプルのＤＯＭ構造のみを幾つか入力し、新ＵＩの構造定義情報を新構造定義情報としてＵＩ構造定義情報保存部３０２に保存する。サンプル及び新構造定義情報の生成方法は、先に述べた方法と類似であるため説明を省略する。検索対象のリストは入力しない。

図１９は生成された新構造定義情報のイメージ図である。
次に元の構造定義情報（図１５）と新構造定義情報（図１９）を比較し、差分計算としてノードの対応関係を計算する。

差分計算の手法としては、ＸＭＬの差分計算手法で、特にそれぞれに含まれるノードの類似度を計算し、元の構造定義情報のノードに最も類似する新構造定義情報のノードを対応すると見なす方式が使用できる。

本具体例１では、新旧の全てのノードの組み合わせに対して、ノード自身が同じ（タグ名、要素値などが一致）か、ノードの子孫ノードが類似しているか、ノードの祖先ノードが類似しているか、とった基準で類似度を計算するものとする。

この結果、特に元構造定義情報で検索対象だったノードに対する新構造定義情報の対応ノードは図２０のように計算できる。

これにより各検索名に対して検索しなければならない新構造定義情報におけるノードが特定できるため、次に各対象ノードを特定するためのXPath式を生成する。この生成方法は前述と同様である。

この結果、’名前’、’社名’、’次’のそれぞれの改変後のＵＩに対する検索式は "/ＨＴＭＬ/Table[２]/TR[２]/TD[２]/text（）”、”//text（）[../../TD[１]/B/text（）=会社名]”、”/ＨＴＭＬ/Table[１]/TR/TD[２]/A[１]”となり、これが新検索ルールリストとなってＵＩ構造定義情報保存部３０２に保存される。

最後に導出された新構造定義情報と新検索式ルールリストの内容が構造定義情報と検索ルールリストに設定され、以後の認識ではこの新しい検索式が用いられることになる。

〔具体例２〕
具体例２は、上記具体例１と同様に、本発明のＵＩ認識装置を情報抽出装置に用いた場合であるが、さらにＵＩ構造変換部８０１と構造変換ルール８０２を持つ。

また、本具体例２では、住所録ＡＰ ２１１１はＨＴＭＬではなく、ＯＳのＧＵＩ部品を用いたＵＩを生成し、ＵＩ情報収集部はＯＳ２１１０に接続されてＯＳ経由でＧＵＩ部品への参照のリストとその画面上でのレイアウト情報を得る。

構造変換ルール保存部には以下の２つの構造変換ルールが保存されている。
［ルール１］
画面上で同じ高さで左右に並ぶ部品があった場合、それらの部品群を包含する行コンテナ部品があると仮定し、親ノードとして行コンテナノードを追加する。
［ルール２］
画面上で同じ幅で上下に並ぶ部品があった場合、それらの部品群を包含する列コンテナ部品があると仮定し、親ノードとして列コンテナノードを追加する。

図２２は、住所録ＡＰ ２１１１が出力するＵＩのイメージ図である。
一つのウィンドウの上に、Nextや終了のボタン部品と、住所、氏名、電話、会社、東京都、佐藤、０３-..、日本電気といったテキスト部品が配置されている。

部品の間に包含関係や親子関係などは存在しない。

図２３は、ＵＩ情報収集部が出力する木構造情報のイメージ図である。本具体例２では、より左側にある部品を部品の兄弟関係の先頭に持っていくように並べている。

この木構造情報のままでは、部品間の関係が単純な前後関係しか存在しないため、構造情報の推定や検索対象部品を一意に特定できるようなXPath式を導出することが困難である。

図２３の木構造情報がＵＩ構造変換部８０１に渡されると、ＵＩ構造変換部８０１は構造変換ルール保存部 ８０２ に保存されている２つの構造変換ルールを適用し、その結果、図２４の木構造情報が出力される。この木構造情報は、上記具体例１の説明で使用したＨＴＭＬに近い構造であり、検索対象部品を一意に特定できるようなXPath式を導出することが可能である。よってＵＩ構造変換部８０１から出力された木構造情報を、ＵＩ構造収集部が出力した木構造情報の代わりに構造定義情報の計算や検索式の適用に使用することで、単純な部品間の関係しか持たないＵＩであっても、対象となる部品を正しく検索することが可能となる。

多くのＵＩでは、部品はバラバラに配置されるのではなく、人間が理解しやすいよう、典型的な配置パターンを組み合わせる形で構成されているため、このような典型的な部品の配置パターンを発見し、パターンを表現するコンテナノードを、パターンを構成する部品群の親ノードとして追加するような構造変換ルールを用意する事で、本具体例２で述べたような効果を得る事が可能となる。

以上、本発明の実施の形態及びその具体例について説明したが、上記説明に限定されるものではなく、その要旨を逸脱しない範囲において種々の変形が可能である。

例えば、上述した制御動作は、ハードウェア、または、ソフトウェア、あるいは、両者の複合構成によって実行することも可能である。

なお、ソフトウェアによる処理を実行する場合には、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれているコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。

例えば、プログラムは、記録媒体としてのハードディスクやＲＯＭ（Read Only Memory）に予め記録しておくことが可能である。あるいは、プログラムは、ＣＤ−ＲＯＭ（Compact DiＳc Read Only Memory），ＭＯ（Magneto optical）ディスク，ＤＶＤ（Digital VerＳatile DiＳc）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的、あるいは、永続的に格納（記録）しておくことが可能である。

このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することが可能である。

なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送したり、ＬＡＮ（Local Area Network）、インターネットといったネットワークを介して、コンピュータに有線で転送したりし、コンピュータでは、転送されてきたプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることが可能である。

また、上述した制御動作に従って時系列的に実行されるのみならず、処理を実行する装置の処理能力、あるいは、必要に応じて並列的にあるいは個別に実行するように構築することも可能である。

なお、図２５に示すように、本発明の実施形態であるＵＩ認識装置２５０１は、少なくとも、検索ルール生成部２５０２と、部品検索部２５０３と、出力部２５０４とを備えていればよい。

検索ルール生成部２５０２は、ＵＩを構成する部品群及び部品群の位置関係を示すＵＩ情報と、部品群の中で検索対象とする部品を示す検索対象部品情報と、ＵＩの構造を定義する構造定義情報とに基づいて、検索対象とする部品を検索するための検索ルールを生成する機能を有する。この検索ルール生成部２５０２は、図１におけるＵＩ情報収集部１０１、ＵＩ構造推定部１０２、ＵＩ情報保存部１０３と、ＵＩ構造定義情報保存部１０４の各機能を有していてもよい。

部品検索部２５０３は、新たなＵＩ情報が入力されたときに、検索ルール生成部２５０１により生成された検索ルールを用いて、新たなＵＩ情報に示される部品群の中から検索対象とする部品を検索する。この部品検索部２５０３は、図１における部品検索部１０５の機能を有していてもよい。

出力部２５０４は、部品検索部２５０３による検索結果を出力する。この出力部２５０４は、図１における部品出力部１０６の機能を有していてもよい。

本発明は、ＡＰが出力するＵＩを認識し、ＵＩを通したＡＰの自動制御や情報の抽出、ユーザのＵＩ操作、ＵＩの自動テストの実現といった用途に適用できる。

この出願は、２００７年１１月２１日に出願された日本出願特願２００７−３０２２０９号を基礎とする優先権を主張し、その開示のすべてをここに取り込む。

Claims (18)

1. ユーザインタフェースを構成する部品群及び前記部品群の位置関係を示すユーザインタフェース情報と、前記部品群の中で検索対象とする部品を示す検索対象部品情報と、前記ユーザインタフェースの構造を定義する構造定義情報とに基づいて、前記検索対象とする部品を検索するための検索ルールを生成する検索ルール生成部と、
   新たなユーザインタフェース情報が入力されたときに、前記検索ルール生成部により予め生成された前記検索ルールを用いて、前記新たなユーザインタフェース情報に示される部品群の中から前記検索対象とする部品を検索する部品検索部と、
   前記部品検索部による検索結果を出力する出力部と
   を備えるユーザインタフェース認識装置。
2. 前記検索ルール生成部は、
   前記ユーザインタフェース情報を取得し、前記ユーザインタフェース情報に基づいて木構造情報を生成する機能と、前記検索対象部品情報を取得する機能とを備える情報収集部と、
   前記情報収集部により生成された前記木構造情報に基づいて前記構造定義情報を生成する機能と、前記木構造情報、前記構造定義情報及び前記検索対象部品情報に基づいて前記検索ルールを生成する機能とを備えた構造推定部と、
   前記構造推定部により生成された前記構造定義情報及び前記検索ルールを保存する構造定義情報保存部とを備え、
   前記部品検索部は、前記構造定義情報保存部に保存された前記検索ルールを前記木構造情報に適用して前記検索対象とする部品を検索する
   請求項１記載のユーザインタフェース認識装置。
3. 前記情報収集部が前記新たなユーザインタフェース情報を取得したとき、
   前記情報収集部は、前記新たなユーザインタフェース情報に基づいて新たな木構造情報を生成し、
   前記部品検索部は、前記構造定義情報保存部に保存されている前記検索ルールを用いて、前記新たな木構造情報から前記検索対象とする部品を検索する
   請求項３記載のユーザインタフェース認識装置。
4. 二つの構造定義情報間の対応関係を計算する構造差分計算部をさらに備え、
   前記ユーザインタフェースの構造が改変されたとき、
   前記構造推定部は、改変後のユーザインタフェースの構造定義情報を生成し、
   前記構造差分計算部は、前記構造定義情報保存部に保存されている前記構造定義情報と、前記構造推定部により新たに生成された前記改変後のユーザインタフェースの構造定義情報との対応関係を計算して、前記改変後のユーザインタフェースから前記検索対象とする部品を検索するための新たな検索ルールを生成する
   請求項３記載のユーザインタフェース認識装置。
5. 前記情報収集部により生成された前記新たな木構造情報と、前記構造定義情報保存部に保存されている前記構造定義情報とを比較し、双方の情報が示す構造に矛盾が無いかを検証する構造検証部をさらに備え、
   前記構造検証部は、前記部品検索部による検索が行われる前に検証を行う
   請求項３記載のユーザインタフェース認識装置。
6. 前記情報収集部から出力された前記木構造情報及び前記新たな木構造情報を、変換ルールにしたがって、それぞれ別の木構造情報に変換する構造変換部と、
   前記構造変換部により使用される変換ルールを保存する構造変換ルール保存部と
   をさらに備え、
   前記構造推定部及び前記部品検索部の少なくとも１つは、前記構造変換部により変換された前記別の木構造情報を使用する
   請求項３に記載のユーザインタフェース認識装置。
7. ユーザインタフェースを構成する部品群及び前記部品群の位置関係を示すユーザインタフェース情報と、前記部品群の中で検索対象とする部品を示す検索対象部品情報と、前記ユーザインタフェースの構造を定義する構造定義情報とに基づいて、前記検索対象とする部品を検索するための検索ルールを生成するステップと、
   新たなユーザインタフェース情報が入力されたときに、予め生成された前記検索ルールを用いて、前記新たなユーザインタフェース情報に示される部品群の中から前記検索対象とする部品を検索するステップと、
   検索結果を出力するステップと
   を備えるユーザインタフェース認識方法。
8. 前記検索ルールを生成するステップは、
   前記ユーザインタフェース情報を取得するステップと、
   前記ユーザインタフェース情報に基づいて木構造情報を生成するステップと、
   前記検索対象部品情報を取得するステップと、
   前記木構造情報に基づいて前記構造定義情報を生成するステップと、
   前記木構造情報、前記構造定義情報及び前記検索対象部品情報に基づいて前記検索ルールを作成するステップと、
   前記構造定義情報及び前記検索ルールを保存するステップと
   を備える請求項７記載のユーザインタフェース認識方法。
9. 前記新たなユーザインタフェース情報を取得するステップと、
   前記新たなユーザインタフェース情報に基づいて新たな木構造情報を生成するステップとをさらに備え、
   検索するステップは、保存されている前記検索ルールを、前記新たな木構造情報に適用するステップを備える
   請求項８記載のユーザインタフェース認識方法。
10. 前記ユーザインタフェースの構造が改変されたとき、改変後のユーザインタフェースの構造定義情報を生成するステップと、
    保存されている前記構造定義情報と、前記改変後のユーザインタフェースの構造定義情報との対応関係を計算するステップと、
    対応関係の計算結果を用いて、前記改変後のユーザインタフェースから前記検索対象とする部品を検索するための新たな検索ルールを生成するステップと
    をさらに備える請求項９記載のユーザインタフェース認識方法。
11. 検索するステップの前に、前記新たな木構造情報と、保存されている前記構造定義情報とを比較し、双方の情報が示す構造に矛盾が無いかを検証するステップ
    をさらに備える請求項９記載のユーザインタフェース認識方法。
12. 前記木構造情報及び前記新たな木構造情報を、変換ルールを用いて、それぞれ別の木構造情報に変換するステップをさらに備え、
    前記構造定義情報を生成するステップ、前記検索ルールを作成するステップ及び検索するステップのうち少なくとも１は、前記別の木構造情報を使用するステップを備える
    請求項９記載のユーザインタフェース認識方法。
13. ユーザインタフェースを構成する部品群及び前記部品群の位置関係を示すユーザインタフェース情報と、前記部品群の中で検索対象とする部品を示す検索対象部品情報と、前記ユーザインタフェースの構造を定義する構造定義情報とに基づいて、前記検索対象とする部品を検索するための検索ルールを生成する処理と、
    新たなユーザインタフェース情報が入力されたときに、予め生成された前記検索ルールを用いて、前記新たなユーザインタフェース情報に示される部品群の中から前記検索対象とする部品を検索する処理と、
    検索結果を出力する処理と
    をコンピュータに実行させるプログラム。
14. 前記検索ルールを生成する処理として、
    前記ユーザインタフェース情報を取得する処理と、
    前記ユーザインタフェース情報に基づいて木構造情報を生成する処理と、
    前記検索対象部品情報を取得する処理と、
    前記木構造情報に基づいて前記構造定義情報を生成する処理と、
    前記木構造情報、前記構造定義情報及び前記検索対象部品情報に基づいて前記検索ルールを作成する処理と、
    前記構造定義情報及び前記検索ルールを保存する処理と
    をコンピュータに実行させる請求項１３記載のプログラム。
15. 前記新たなユーザインタフェース情報を取得する処理と、
    前記新たなユーザインタフェース情報に基づいて新たな木構造情報を生成する処理とをさらにコンピュータに実行させ、
    検索する処理の中で、保存されている前記検索ルールを、前記新たな木構造情報に適用する処理をコンピュータに実行させる請求項１４記載のプログラム。
16. 前記ユーザインタフェースの構造が改変されたとき、改変後のユーザインタフェースの構造定義情報を生成する処理と、
    保存されている前記構造定義情報と、前記改変後のユーザインタフェースの構造定義情報との対応関係を計算する処理と、
    対応関係の計算結果を用いて、前記改変後のユーザインタフェースから前記検索対象とする部品を検索するための新たな検索ルールを生成する処理と
    をさらにコンピュータに実行させる請求項１５記載のプログラム。
17. 検索する処理の前に、前記新たな木構造情報と、保存されている前記構造定義情報とを比較し、双方の情報が示す構造に矛盾が無いかを検証する処理
    をさらにコンピュータに実行させる請求項１５記載のプログラム。
18. 前記木構造情報及び前記新たな木構造情報を、変換ルールを用いて、それぞれ別の木構造情報に変換する処理をさらにコンピュータに実行させ、
    前記構造定義情報を生成する処理、前記検索ルールを作成する処理及び検索する処理のうち少なくとも１の処理の中で、前記別の木構造情報を使用する処理をコンピュータに実行させる請求項１５記載のプログラム。

Images