JP2010170415A - 動作変更装置と情報処理システム及び方法とプログラム - Google Patents

Abstract

【課題】複数ページの画面遷移を含むページにまたがる動作の変更を、アプリケーションの変更無しに実現可能にする装置を提供する。
【解決手段】ＷＥＢアプリケーションにリクエストを送る際に、プロキシ部がそのレスポンスに動作変更部、行動記録部を動作させるための制御スクリプトを埋め込む。制御スクリプトは、アプリケーション定義管理部で管理されている画面構造定義とユーザー操作定義を基に、アプリケーションの構造を画面の構造、ユーザ操作手順のパターン、画面の遷移グラフによって特徴付け、アプリケーション履歴記憶部に保存する。動作変更部は、アプリケーション定義管理部に蓄積された画面構造、操作履歴、画面のグラフ構造のデータから、動作変更ルール管理部で管理されている適合する動作変更ルールし、動作変更ルールが見つかった場合には動作変更ルールに記述された動作変更内容を実行し、ユーザの操作を変更する。
【選択図】図１

Description

本発明は、情報処理装システムに関し、特に、アプリケーションの部分識別による動作変更を行う装置、方法、プログラムに関する。

多くの企業や組織で多数の情報や機能を持ったＷＥＢアプリケーションが多数存在している。また、ユーザのニーズに合わせるために、システムインテグレーションやマッシュアップにより、一部の画面の構造が異なるＷＥＢアプリケーションが、多数開発されている。画面は変わりやすく、画面の変更に応じた、ＷＥＢアプリケーションに対する動作を変更することは難しい。

この問題に対して、画面の変更に対応するための技術として、ユーザインタフェースの構造変化に対応するための技術がある。

この種の技術として、１画面の構造変化を推定する技術が複数提案されている。例えば特許文献１には、特徴ベクトルに基づいて構造化文書を特徴づける構造要素を選択し、選択した構造要素から検索された構造化文書間で類似する構造要素である類似部分構造の検索を行う技術が開示されている。

一方、構造による類似ではなく、リンクの度合いに応じて類似文書を見つける技術等も複数提案されている。例えば特許文献２では、ユーザのアクセス履歴を利用して、サイト候補を絞り込むことにより、類似ウェブページを検出する探索方法が開示されている。

また、文字列の一致やパターンマッチにより、部分構造のパターンマッチを行う技術も知られている。ＷＥＢアプリケーションの特定部分に対する動作を変更するために、アクセス制限やレイアウト変更が行われる。

特許文献３には、ＨＴＭＬ（ＨｉｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）データとビジネスコンポーネントにより処理可能なデータ構造であるデータセットとの双方向の変換ルールを用意しておき、ＷｅｂブラウザはＨＴＭＬ画面に対してユーザが入力したテキストデータをタグ要素の内容として含むＨＴＴＰ（ＨｉｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）リクエストを生成しアプリケーションサーバーに引き渡す。アプリケーションサーバーはＨＴＴＰリクエスト内のタグ要素の内容を変換ルールに従って処理対象データセットに変換する。ＪＳＰ（Ｊａｖａ Ｓｅｒｖｅｒ Ｐａｇｅｓ（サンマイクロシステムズ社の登録商標））はビジネスコンポーネントの処理結果を格納した処理結果データセットを基に変換ルールに従ってリクエスト元のクライアントにレスポンスとして引き渡すＨＴＭＬデータを生成する。

特許文献４には、サーバー側で動的に生成されるオブジェクトやウェブページをも対象に含み、ウェブアプリケーションを生成し、システムの変更や再構成を支援する装置、方法として、分類処理部により、ウェブアプリケーションを実行することによって取得される静的なＨＴＭＬコンテンツの構成を解析し分類し、この分類結果を用いて、テンプレート抽出部により、ウェブアプリケーションにおける動的なＨＴＭＬコンテンツのテンプレートを抽出し、分類処理部の分類結果と、静的なＨＴＭＬコンテンツを取得する際に得られるアクセス情報とに基づいて、遷移抽出部により、処理対象であるウェブアプリケーションの遷移情報を抽出し、抽出されたテンプレートと遷移情報とに基づいて、モデル生成部により、ウェブアプリケーションのモデルを生成するＨＴＭＬ文書をレンダリングして画像を生成する構成が開示されている。特許文献５には、Ｗｅｂを利用したアプリケーションは様々な形態で利用されているが、アプリケーションの生産性が問題となっており、向上させるための手法としてロジックとデータ定義と画面定義と分け、例えば、ＪａｖａＢｅａｎｓ（サンマイクロシステムズ社の登録商標）とＪＳＰ（ＪａｖａＳｅｒｖｅｒ
Ｐａｇｅｓ（サンマイクロシステムズ社の登録商標））タグを用いて、画面定義内に特殊タグを埋め込むことが行われているが、この技術では、画面定義とデータ定義が相互に依存しているので、再利用生の高いアプリケーションの作成が難しい。そこで、アプリケーション開発の生産性を向上させたアプリケーション実行装置として、画面定義とロジック定義との間に、画面依存の画面変数と、画面非依存のアプリケーション変数を設けることで、既存のアプリケーションにおける画面定義の変更を容易とする構成が開示されている。

特願２００８−８４１９２号公報 特開２００３−８５２０２号公報 特開２００４−２４６４０１号公報 特開２００５−４４２８号公報 特開２００５−２２８１８４号公報

以下に本発明による分析を与える。

複数の画面から構成されるＷＥＢアプリケーションにおいて、ＷＥＢアプリケーション中の一部の画面の構造変化がある場合、画面構造のパターンマッチングにより動作変更する要素を指定する技術では、類似構造が追加された場合に、間違った要素がマッチングしてしまうケースが存在し、部分識別を正しく行うことができない、という問題がある。すなわち、画面の類似判定を行うために、画面構造にマッチするパターンを緩めれば緩めるほど、画面変化には強くなるが、画面の部分を識別する精度が下がる。

そのため、画面の一部の部分への構造変化に対し当該部分への動作変更を実現しようとする場合に、動作変更をするべきでない要素を誤って適合判定（動作変更に適合と判定）してしまう可能性があり、その要素に対して誤った動作変更をしてしまう可能性がある。

本発明の目的は、複数ページの画面遷移を含むＷＥＢアプリケーションのページにまたがる動作の変更を、ＷＥＢアプリケーションの変更無しに実現可能とする装置、システム、方法、プログラムを提供することにある。

本願で開示される発明は、上記課題を解決するため概略以下の構成とされる。

本発明によれば、ＷＥＢアプリケーションの画面構造を定義する画面構造情報と、ユーザ操作を定義するユーザ操作定義情報と、ＷＥＢアプリケーションの動作変更のルールとを記憶する手段と、ＷＥＢアプリケーションの画面の操作と、前記画面構造情報による前記画面構造の定義、前記ユーザ操作定義情報によるユーザ操作の定義に従って、前記ＷＥＢアプリケーションの動作変更ルールの適用条件を判定し、ＷＥＢアプリケーションの動作変更を実行する装置、方法、プログラムが提供される。

本発明によれば、複数ページの画面遷移を含むＷＥＢアプリケーションのページにまたがる動作の変更を、ＷＥＢアプリケーションの変更無しに実現可能としている。

本発明の第１の実施例の構成を示す図である。 本発明の第１の実施例における画面構造定義の一例を示す図である。 （Ａ）、（Ｂ）は本発明の第１の実施例におけるユーザー操作定義の一例を示す図である。 本発明の第１の実施例におけるアプリケーション履歴記憶部のデータ構造の一例を示す図である。 本発明の第１の実施例におけるアプリケーション動作変更ルールの一例を示す図である。 本発明の第１の実施例における動作変更定義の一例を示す図である。 本発明の第１の実施例における動作変更手順のフローチャートである。 本発明の第１の実施例におけるプロキシ処理手順のフローチャートである。 本発明の第１の実施例における動作変更判定手順のフローチャートである。 本発明の第２の実施例の構成を示す図である。 発明の第２の実施例におけるアプリケーション履歴記憶部の一例を示す図である。 本発明の第２の実施例におけるユーザー操作定義の一例を示す図である。 本発明の第２の実施例における動作変更手順を示す図である。 本発明の第２の実施例における動作変更ルールの絞込み手順を示す図である。 本発明の第３の実施例の構成を示す図である。 本発明の第２の実施例における動作変更ルールの一例を示す図である。 本発明の第４の実施例の構成を示す図である。 本発明の第４の実施例における動作変更の手順の一例を示すである。 本発明の第５の実施例の構成を示す図である。 本発明の実施例１の全体の構成を示す図である。 ＷＥＢアプリケーション１の構成（画面遷移）の一例を示す図である。 実施例１の画面構造定義Ａの一例を示す図である。 実施例１の画面構造定義Ｂの一例を示す図である。 実施例１の画面構造定義Ｃの一例を示す図である。 実施例１の画面構造定義Ｄの一例を示す図である。 実施例１のユーザ操作定義Ａの一例を示す図である。 実施例１のユーザ操作定義Ｂの一例を示す図である。 実施例１のユーザ操作定義Ｃの一例を示す図である。 実施例１のユーザ操作定義Ｄの一例を示す図である。 実施例１のアプリケーション履歴記憶部のデータの一例を示す図である。 実施例１のアプリケーション動作変更ルールの一例を示す図である。 実施例１のアプリケーション動作変更ルールの一例を示す図である。 実施例１のアプリケーション動作変更を説明する図である。 実施例１の動作変更内容定義を示す図である。

次に、本発明を実施するための形態について図面を参照して詳細に説明する。

本発明は、複数画面から構成されるＷＥＢアプリケーションの部分識別により動作変更を行う装置やシステムに適用して好適とされる。本発明を実施するための一形態に係るシステムにおいては、図１を参照すると、ユーザ（クライアント部）がＷＥＢアプリケーションに対してリクエストを送り、プロキシ部（１５０）が、ＷＥＢアプリケーションからレスポンスを受け取る際に、そのレスポンスに、行動記録部（１３０）及び動作変更部（１２０）を、ＷＥＢブラウザ（１００）が解釈可能な形式の制御スクリプトで埋め込む。

制御スクリプトは、ＷＥＢブラウザ（１００）によって解釈され、ユーザが操作を実行する際に、行動記録部（１３０）が、ＷＥＢアプリケーションの構造を、
・画面の構造、
・ユーザ操作手順のパターン、及び
・画面の遷移グラフによって
特徴付け、アプリケーション履歴記憶部（１４０）に保存する。

動作変更部（１２０）は、アプリケーション履歴記憶部（１４０）に蓄積された、
・画面構造、
・ユーザ操作履歴、
・画面構造の遷移グラフ、
のデータに基き、動作変更ルール管理部（１６０）に記憶管理されている動作変更ルールの中から、適合する動作変更ルールを探し出す。

動作変更部（１２０）は、適合するＷＥＢアプリケーションの動作変更ルールが見つかった場合に、ＷＥＢアプリケーションの動作変更ルールに記述されている動作変更内容を実行し、ユーザのＷＥＢアプリケーションの操作時の動作を変更する。

本発明においては、
・動作変更を行う要素の画面構造のパターン、
・画面の操作手順の可能性のパターン、
・画面遷移のパターンを組み合わせたＷＥＢアプリケーションの部分識別ルールとユーザの操作・ページ遷移履歴、
によって、動作変更の対象となるＷＥＢアプリケーションの一部分を特定することで、一画面の構造に依存しない形で、ＷＥＢアプリケーションの動作変更を行う。

このため、本発明によれば、ＷＥＢアプリケーションの一画面の構造が変化した場合でも、動作変更対象として間違った要素を識別することなく、ＷＥＢアプリケーションの部分を識別できる。

また、本発明においては、
・辿った画面構造の遷移履歴、
・画面及び画面をまたがった操作手順の履歴、
・辿った画面の個々の画面の周辺の画面の構造及び画面間のつながりを表した画面の遷移グラフ構造の履歴、
とＷＥＢアプリケーションの動作制限パターンを照らし合わせることで、段階的にＷＥＢアプリケーションの部分構造の絞込みを行える。

本発明によれば、ＷＥＢアプリケーションの一部分（部分構造）を段階的に絞込む。ＷＥＢアプリケーションの一部分の特定を段階的に行うことで、該特定を正確に行うことができる。

さらに、プロキシ部（１５０）に制御スクリプトを埋め込む埋め込み部（１５２）が、ＷＥＢアプリケーションの画面をプロキシして、ＷＥＢアプリケーションにスクリプトを埋め込み、そのスクリプトで、
・ユーザ操作の記録、
・画面構造、
・画面構造グラフの解析、
を行う。

このため、複数の画面から構成されるＷＥＢアプリケーションの一部分のみを、
・ユーザの操作手順、
・画面構造
に応じて、ＷＥＢアプリケーションを変更することなく、それ（ＷＥＢアプリケーション）に対するユーザ操作を変更することができる。

本発明によれば、過去の履歴によるＷＥＢアプリケーション構造だけでなく、動作変更候補の要素を操作した後の、先の画面構造、画面構造グラフを調べることで、ＷＥＢアプリケーションの部分識別の精度を高めることが出来る。

このため、動作を変更する要素の先の画面構造が変わっている場合でも、ＷＥＢアプリケーションの一部分を識別し、動作を変更することができる。以下、具体的な実施例に即して説明する。

＜第１の実施例＞
図１は、本発明の第１の実施例（実施例１）の装置構成を示す図である。図１を参照すると、本発明の第１の実施例の装置は、動作変更部１２０、行動記録部１３０、アプリケーション履歴記憶部１４０、プロキシ部１５０、動作変更ルール管理部１６０、アプリケーション定義管理部１７０を備えている。

動作変更部１２０は、ユーザの操作を変更する動作変更手段１２１と、ユーザ操作に対する動作変更の必要性を判定する動作変更必要性判定手段１２２とを備える。

行動記録部１３０は、ユーザが操作している画面の画面構造を記録する画面構造記録手段１３１と、ユーザの画面に対する操作を記録する操作記録手段１３２とを備える。動作変更部１２０と行動記録部１３０はクライアント部１１０に設けられている。

アプリケーション履歴記憶部１４０は、行動記録部１３０による、ＷＥＢアプリケーションの操作の履歴を記録する。

プロキシ部１５０は、クライアント部１１０からのリクエストに対して、ＷＥＢアプリケーションをプロキシし、実際のＷＥＢアプリケーション１７５と通信を行う通信処理部１５１と、動作変更部１２０及び行動記録部１３０を生成するための制御スクリプト埋め込み部１５２を備える。

動作変更ルール管理部１６０は、動作変更部１２０によるＷＥＢアプリケーションの動作変更ルールを管理する。

アプリケーション定義管理部１７０は、動作変更部１２０で参照されるＷＥＢアプリケーションの定義の管理を行う。アプリケーション定義管理部１７０は、画面構造定義１７１とユーザ操作定義１７２を備えている。

ＷＥＢブラウザ１００はユーザの操作に対してイベントを発行する機構を持つ。

クライアント部１１０は、ＷＥＢブラウザ１００がイベントを通知して結果を待つ形で、ＷＥＢブラウザ１００に接続される。

動作変更部１２０の動作変更必要性判定手段１２２は、アプリケーション履歴記憶部１４０と動作変更ルール管理部１６０で管理される動作変更ルールとを照らし合わせ、アプリケーション履歴記憶部１４０の各行の画面構造定義ＩＤと、動作変更ルールの各行の画面構造ＩＤが全て一致するか、また、アプリケーション履歴記憶部１４０の各行の操作、操作対象及び値が、動作変更ルールの各行の操作ＩＤで規定された操作にパターンマッチするかを判定することで、ＷＥＢアプリケーションの動作変更が必要か否かを判定する。

動作変更手段１２１は、動作変更必要性判定手段１２２により判定された必要な動作変更ルールに基づき、識別されたＷＥＢアプリケーションの動作変更対象部分に対し、ユーザ操作の動作を変更する。

行動記録部１３０の画面構造記録手段１３１は、ユーザがＷＥＢアプリケーション１７５にプロキシ部１５０を介してアクセスした場合に、ＷＥＢアプリケーション１７５がアプリケーション定義管理部１７０の画面構造定義１７１で管理されている画面構造のうちどの画面構造に対応するのかを識別する。画面構造記録手段１３１で識別され画面構造名は、ユーザが操作を行う際に、操作記録手段１３２によって、アプリケーション履歴記憶部１４０に記憶される。

操作記録手段１３２は、
・ユーザの操作と、
・操作対象の要素のパスと、
・操作する要素が入力可能な要素・選択可能な要素の場合には、その値と、
をアプリケーション履歴記憶部１４０に記録する。

操作記録手段１３２が実行されるときに、画面構造定義ＩＤが記録されていない場合であり、かつ、その操作の前の操作でＷＥＢアプリケーションの画面の遷移が発生していない場合には、アプリケーション履歴記憶部１４０の前の行の画面構造定義ＩＤを、現在の画面の画面構造ＩＤとして、アプリケーション履歴記憶部１４０に記憶する。

プロキシ部１５０の制御スクリプト埋め込み部１５２は、ＷＥＢアプリケーション１７５のリクエストをプロキシし、レスポンスにＷＥＢブラウザ１００で解釈されるスクリプトを埋め込む。

制御スクリプト埋め込み部１５２は、動作変更スクリプト埋め込み手段、部分識別スクリプト埋め込み手段を、ＷＥＢブラウザ１００が解釈・実行可能な状態で、埋め込む。

図４は、アプリケーション履歴記憶部１４０に記憶されるデータのデータ構造である。図４に示すように、アプリケーション履歴記憶部１４０に記憶されるデータ構造は、
・画面構造定義ＩＤ、
・操作、
・操作対象、
・値（無しも可）
を１エントリとして含み、各エントリはＩＤ（番号）１、２、３・・・に関連付けられて格納される。

図１を参照すると、アプリケーション定義管理部１７０は、
画面に含まれる要素のパターンを定義した画面構造定義１７１と、
画面でどのような操作がどのような手順で実行可能かを定義するユーザ操作定義１７２と、
を管理する。

図２は、アプリケーション定義管理部１７０に登録されている画面構造定義１７１の一例を示す図である。図２を参照すると、画面構造定義１７１は、
・当該画面に含まれる要素のパターン（画面要素パターン）と、
・該要素の周囲（周辺）の構造パターンと、
の集合により定義される。

画面要素パターンは、画面構造定義１７１一つにつき複数定義することが可能である。画面に含まれる要素パターンに対して、複数の画面要素の周囲の構造パターンを定義することができる。

図２に示すように、
・画面に含まれる要素のパターンと、
・該要素パターンの周辺要素のパターン
のリストが記述される。画面に含まれる要素のパターン等の記述方法は、ＸＰＡＴＨ、ＸＱＵＥＲＹなどの記述が用いられる。ただし、本発明において、要素パターンの記述は、特定のパターン記述に限定されるものでないことは勿論である。

図３（Ａ）、図３（Ｂ）は、アプリケーション定義管理部１７０に登録されている、画面のユーザ操作定義１７２を例示する図である。画面のユーザ操作定義１７２には、その画面で可能な操作のリストが記述されており、画面構造定義でどのような操作がどのような手順で実行可能であるかを定義するものであり、図３に示すように、ユーザ操作定義１７２は、
・操作を識別する操作ＩＤ、
・操作名、
・実際の操作、
・当該操作における操作対象の要素のパターン、
・操作対象が入力、選択ができる場合にはその入力値や選択値、
を含む。

図３に示した画面のユーザ操作定義１７２の例では、操作ＩＤは例えばＡ１、Ａ２、Ａ３・・・の順、これらの操作ＩＤに対応する操作名は例えばＯＫクロック、セレクトボックス選択、キャンセルクリック、・・・、これらの操作ＩＤＡ１、Ａ２、Ａ３・・・に対応する実際の操作は例えばクリック、選択、クリック、・・・とされる。操作対象の要素のパターンは、図２の画面要素パターンに対応し、操作ＩＤＡ１、Ａ２、Ａ３・・・に対応する操作対象の要素のパターンは、／Ａ／Ｂ／Ｃ、／Ｂ／Ｃ、／Ａ／Ｂ／Ｃ／Ｄ等とされる。画面のユーザ操作定義１７２は、画面構造ＩＤ毎に定義される。

図３（Ａ）の画面構造ＩＤ＝Ａでは、操作Ａ１、Ａ２、Ａ３の順で操作手順が定義されている。一方、図３（Ｂ）の画面構造ＩＤ＝Ａの例では、操作Ａ２、Ａ１、Ａ３の順で操作手順が定義されている。この場合、画面構造ＩＤ＝Ａにおいて、操作Ａ１（ＯＫクリック）、Ａ２（セレクトボックス選択）とは可逆である（どちらの操作が先に行われてもよい）。

図５は、動作変更ルール管理部１６０に登録されている動作変更のルールの例を示す図である。図５を参照すると、動作変更ルール管理部１６０で記憶管理される動作変更のルールは、
・操作ＩＤ、
・動作変更対象、
・操作実行前変更、
・動作変更ＩＤ
の各欄を備えている。動作変更ルール管理部１６０において、動作変更のルールは、操作ＩＤ、動作変更対象か否か、動作変更のルールの識別子である動作変更ＩＤを複数組み合わせたリストで管理される。

図６は、動作変更ルールで参照される動作変更を行うスクリプトを含む変更内容を含んだ動作変更内容定義を示す図である。図６を参照すると、動作変更内容定義は、
・動作変更ＩＤ、
・動作変更名、
・動作変更内容スクリプト
を備えている。図６の例では、動作変更ＩＤ＝１につて、動作変更名はクリック禁止であり、動作変更内容スクリプトは、＜要素のクリック禁止スクリプト＞からなる。動作変更ＩＤ＝２につて、動作変更名はクリック要素の色変更であり、動作変更内容スクリプトは、＜クリックした要素の色を変えるスクリプト＞からなる。

このような構成とすることにより、
・画面遷移の履歴と、
・各遷移で辿る画面の画面構造の履歴、及び、
・各画面での操作の可能性を、
ＷＥＢアプリケーションの操作履歴として、ＷＥＢアプリケーション履歴部１４０に記録しておくことで、画面の構造のパターンを緩く設定していても、操作や画面遷移の履歴によってＷＥＢアプリケーションの対象部分を識別することができる。

このため、複数のＷＥＢアプリケーションの画面遷移によって構成されている場合において、該ＷＥＢアプリケーション中の画面の部分を識別することができ、結果として、ＷＥＢアプリケーションに対するユーザの操作に対して、動作の変更を行うことができる。

図７は、本実施例における動作変更動作の処理手順を示すフローチャートである。図１及び図７を参照して、本実施例における動作変更動作を以下に説明する。ユーザは、予めアプリケーション定義管理部１７０で管理する画面構造定義１７１及びユーザ操作定義１７２を作成し、アプリケーション定義管理部１７０に登録する。

（リクエスト待ち）
通信処理部１５１は通信リクエストの受信を待つ（Ｓ１０）。

通信処理部１５１がメッセージを受信すると、プロキシ手順の手続きを実行する（Ｓ１１）。

（プロキシ処理）
図８は、図７のプロキシ処理Ｓ１０の手順を示すフローチャートである。図１及び図８を参照して、プロキシ処理Ｓ１０を説明する。プロキシ手順では、
ステップＳ１１でリクエストを受け付け、
ステップＳ１２でＷＥＢアプリケーションにリクエストを同期で送信する。

プロキシ部１５０の通信処理部１５１は、ＷＥＢアプリケーションのレスポンスが戻ってきたら、ステップＳ１３において、制御スクリプト埋め込み部１５２に対してスクリプト埋め込み処理を依頼する。

制御スクリプト埋め込み部１５２は、ＷＥＢアプリケーションの該レスポンスに対して、動作変更手段１２１、部分識別手段（画面の部分を識別する手段）、画面構造記録手段１３１、画面遷移履歴記録手段２００のスクリプトを埋め込む。

ステップＳ１４において、プロキシ部１５０の通信処理部１５１は、レスポンスをＷＥＢブラウザ１００に返す。

（構造記録）
ステップＳ２０において、画面構造記録手段１３１は、当該レスポンスがＷＥＢブラウザ１００によって評価された後、画面構造定義１７１の画面要素パターンに記述されたパターンが、当該レスポンス中に存在するか否か判定する。

画面構造定義１７１の画面要素パターンに記述されたパターンが、当該レスポンス中に存在している場合には、画面構造定義１７１の該画面要素パターンの周辺構造パターン（図２参照）に記述されたパターンの要素が、画面要素の周りに存在するか否かを判定する。

画面構造記録手段１３１は、画面構造定義１７１に記述された画面要素パターンのリストが全て存在すると判定され、かつ、画面構造ＩＤに対応するユーザ操作定義１７２で定義された操作がその画面で可能な場合に、画面構造定義１７１の画面構造定義ＩＤを、アプリケーション履歴記憶部１４０の画面構造定義ＩＤに記録する。ただし、画面のユーザ操作定義１７２で定義された操作が実行可能であるか否かの確認は必須ではなく、該確認は行わなくてもよい。

（ユーザ操作待ち）
図７のステップＳ３０において、動作変更部１２０は、ＷＥＢブラウザ１００がイベントを発行するのを待つ。

（操作記録）
ユーザ操作によりＷＥＢブラウザ１００がイベントを発行した場合、ステップＳ４０において、操作記録手段１３２は、アプリケーション履歴記憶部１４０に、画面構造定義ＩＤに対応させて、操作、操作対象の要素のパスを記憶する。

また、操作記録手段１３２は、ユーザの操作と操作対象の要素のパスと操作する要素が入力可能な要素・選択可能な要素である場合には、その値をアプリケーション履歴記憶部１４０に画面構造定義ＩＤに対応させて記録する（図４のアプリケーション履歴記憶部１４０のデータ構造参照）。

操作記録手段１３２が実行されるときに、画面構造定義ＩＤが記録されていない場合であり、かつ、その操作の前の操作でＷＥＢアプリケーション遷移が発生していない場合には、前の行の画面構造定義ＩＤを、現在の画面の画面構造ＩＤとして、アプリケーション履歴記憶部１４０に記憶する。

操作記録手段１３２で記録している間は、ユーザの実際の操作を行わせる前に記録を行う。

（動作変更判定）
ステップＳ５０で、動作変更必要性判定手段１２２は、ユーザが操作しようとした要素に対して動作変更が必要であるか否かを判定する。

図９は、動作変更必要性判定手段１２２の動作変更判定処理の手順を示すフローチャートである。図９及び図１を参照して、動作変更判定処理を説明する。

ステップＳ５１において、動作変更必要性判定手段１２２は、アプリケーション履歴記憶部１４０から取得する現在データ行が設定されていないことから、現在データ行を、アプリケーション履歴記憶部の先頭行に設定する。

次にステップＳ５２において、動作変更必要性判定手段１２２は、アプリケーション履歴記憶部１４０のデータを用いて動作変更ルールの絞込みを行う。

ステップＳ５２では、全動作変更ルールの現在行が設定されていないため、現在行を先頭行に設定する。

ステップＳ５２では、動作変更必要性判定手段１２２は、アプリケーション履歴記憶部１４０に記憶されたユーザの操作データから、動作変更ルールの絞込みを行う。動作変更必要性判定手段１２２は、アプリケーション履歴記憶部１４０の現在データ行から、画面構造定義１７１のＩＤ、操作、操作対象、値のデータを取得する。また、動作変更必要性判定手段１２２は、ユーザ操作定義１７２の中から、画面構造ＩＤが一致するユーザ操作定義１７２を取得する。

アプリケーション履歴記憶部１４０から取得した、画面構造定義ＩＤ、操作、操作対象、値にパターンマッチするユーザ操作定義１７２中の操作ＩＤ（図４の第１欄のＩＤ）を取得する。

アプリケーション動作変更候補リスト中のアプリケーション動作変更候補ルールの現在行の操作ＩＤとアプリケーション履歴記憶部１４０の現在行の操作に対応する操作ＩＤが一致するアプリケーション動作変更ルールを絞込み、アプリケーション動作変更候補リストとする。以上の処理がステップＳ５２で行われる。

ステップＳ５３において、動作変更必要性判定手段１２２は、アプリケーション動作変更ルール候補リストが空か否かを調べる。アプリケーション動作変更ルール候補リストが空の場合には、ステップＳ５４で動作変更は不要であると判定し、動作変更判定手順を終了する。

一方、アプリケーション動作変更ルール候補リストが空でない場合には、ステップＳ５５に進み、動作変更ルールが最終行であり、かつ、変更対象であるか否かを調べる。ステップＳ５５の判定結果がＹＥＳの場合には、ステップＳ５６に分岐し、動作変更は必要であると判定し、終了する。

ステップＳ５５の判定結果がＮＯの場合には、ステップＳ５７に分岐し、動作変更が不要であると判定し、動作変更判定手順を終了する。

（動作変更）
再び図７を参照して、ステップＳ６０では、ステップＳ５０の動作変更必要性判定手段１２２による判定処理の結果に基づき、処理が分岐する。

ステップＳ６０で動作変更が必要であると判定された場合、ステップＳ７０に分岐し、ユーザ操作を実行する前の動作変更が必要かを判定する。

ステップＳ７０で操作前の変更が必要な場合には、ステップＳ８０に分岐し、動作変更手段１２１は、操作の前の事前にＷ動作変更を行い、ステップＳ９０で、ユーザ操作の実行を行う。

一方、ステップＳ７０で操作前変更が必要でない場合には、ステップＳ８１に分岐し、ユーザ操作の実行を行った後、ステップＳ９１において、動作変更手段１２１により、ＷＥＢアプリケーションの動作変更を行う。

ステップＳ８０の動作変更において、動作変更手段１２１は、アプリケーション動作変更ルールのうち、現在ユーザが操作しようとしている要素パターンの行の、動作変更ルールＩＤで指定されたスクリプトを実行する。

具外的には、動作変更定義（図６参照）に記述された、動作変更内容スクリプトを画面に追加し、ＷＥＢブラウザ１００で評価させて実行を行い、動作変更処理を実行する。

動作変更の内容の実行指示を、ＷＥＢブラウザ１００上で行い、実際の動作変更は、クライアントとサーバー間で通信して、動作変更を行うようにしてもよい。

ただし、ステップＳ９０におけるユーザ操作の実行とは、ＷＥＢブラウザ１００がユーザ操作によるイベントにより発生した処理を継続するものであり、動作変更装置が実行するものではない。

ステップＳ９０のユーザ操作の実行の後に、プロキシ部１５０は、画面遷移が発生するか否かによって、ステップＳ００に進むか、ステップＳ３０に進むかを決定する。

ステップＳ３０に進んだ場合、動作変更装置は、ユーザ操作によるブラウザからイベントが発行されるのを待つ。

＜第２の実施例＞
次に本発明の第２の実施例について説明する。図１０は、本発明の第２の実施例の構成を示す図である。本発明の第２の実施例では、画面の先の画面構造と画面のリンク構造と、ユーザ操作時に遷移が発生するか否かを判定することで、適用する動作変更のルールの絞込みの手法を変える。

図１０を参照すると、本発明の第２の実施例においては、図１の前記第１の実施例の構成に加え、
・画面遷移が発生する場合、画面遷移が発生したか否かを記録する画面遷移履歴記録手段２００と、
・操作画面から辿れる画面の画面構造を記録する画面構造グラフ記録手段２０１と、
が行動記録部１３０内に設けられている。

画面遷移履歴記録手段２００は、画面遷移が発生した場合に、画面遷移が発生したか否かをアプリケーション履歴記憶部１４０に記録する。

画面構造グラフ記録手段２０１は、操作する前の、現在操作をしようとしている画面から、遷移が可能な画面を辿り、操作する画面からの画面構造グラフを記録する。これら情報は、アプリケーション履歴記憶部１４０に記録される。

図１１は、本発明の第２の実施例におけるアプリケーション履歴記憶部１４０のデータ構造の一例を示す図である。図１１を参照すると、アプリケーション履歴記憶部１４０は、一エントリあたり、
・画面構造定義ＩＤ、
・操作、
・操作対象、
・値、
・画面構造グラフ、
・遷移の有無の情報
を含む。各エントリが番号１、２、３・・・に関連付けて格納される。図１１を参照すると、本実施例においてアプリケーション履歴記憶部１４０は、図４のデータ構造に対して、画面構造グラフ、画面遷移の有無の情報が追加されている。

図１２は、本発明の第２の実施例におけるアプリケーション定義管理部１７０のユーザ操作定義１７２の一例を示す図である。図１２を参照すると、本実施例において、ユーザ操作定義１７２には、図３（Ａ）、（Ｂ）の前記第１の実施例の構成に加え、
・ある操作の操作対象画面からの画面構造グラフ（操作前画面からの画面構造グラフ）と、
・画面の遷移が発生するか否かを示す遷移発生フィールドが追加されている。

本発明の第２の実施例の動作を説明する。図１３は、本発明の第２の実施例における動作変更の手順を示す図である。以下、図１０、図１３を参照して、本発明の第２の実施例の動作を説明する。

本発明の第２の実施例では、図７に示した前記第１の実施例の手順に加え、プロキシ処理（ステップＳ１０）の直後に、ステップＳ２００において、画面構造グラフ記録手段２０１により、画面構造グラフの記録を行う。

また、ステップＳ４０のユーザ操作記録の後に、ステップＳ２０１で、画面遷移履歴記録手段２００は、画面遷移が発生するか否かを推測し、アプリケーション履歴記憶部１４０に記録する。

ステップＳ２００では、画面構造グラフ記録手段２０１は、操作する前の現在操作をしようとしている画面から、遷移が可能な画面を取得する。

つづいて、画面構造グラフ記録手段２０１は、取得した画面（遷移が可能な画面）の画面構造と、アプリケーション定義管理部１７０で管理された画面構造定義１７１とを照合し、画面構造定義１７１に記述された要素のパターンが存在する画面構造定義１７１を選択し、適合した画面構造定義ＩＤを、その画面（現在操作をしようとしている画面）の画面構造ＩＤとする。

画面構造グラフ記録手段２０１は、当該画面（現在操作をしようとしている画面）から辿れる画面を辿り、画面の繋がりを画面構造ＩＤのリンクとして表現し、それを画面構造グラフとして、アプリケーション履歴記憶部１４０に記憶する。画面を辿るグラフの深さは何段階であってもよく、辿る画面の階層の深さは指定できるものとする。また、画面のリンクを辿る過程では、その画面の画面構造定義１７１で定義されている要素パターンが存在するか否かを判定する。

また、画面で操作可能なユーザの操作が、ユーザの操作定義１７２に記述された操作パターンと一致するか否かを判定する。

ステップＳ２０１で、動作変更必要性判定手段１２２は、ユーザ操作によって画面遷移が発生するかをユーザ操作記録によって記録した操作と操作の対象要素、操作対象の要素の要素に記述された属性の値から判定する。

画面遷移が発生すると推測した場合には、ステップＳ２０１で、画面遷移履歴記録手段２００は、画面遷移を、アプリケーション履歴記憶部１４０の遷移フィールドに記憶する。画面遷移履歴記録手段２００は、遷移する場合には１、遷移しない場合には０をアプリケーション履歴記憶部１４０に記録する。

図１４は、本発明の第２の実施例における動作変更必要性判定手段１２２による動作変更ルールの絞込み手順を示す流れ図である。図１４を参照すると、本実施例は、動作変更ルールの現在行設定ステップ（Ｓ５２１）、操作による動作変更ルールの絞込み（Ｓ５２２）と、画面構造グラフによるアプリケーション動作変更ルールの絞りこみ（Ｓ２１０）と、ステップＳ２１１のユーザ操作による遷移の有無によるアプリケーション動作変更ルールの絞りこみ（Ｓ２１１）と備え、図９の動作変更ルールの絞込み（Ｓ５２）に対して、ステップＳ２１０、Ｓ２１１が追加されている。なお、動作変更ルールの現在行設定ステップ（Ｓ５２１）、操作による動作変更ルールの絞込み（Ｓ５２２）は、図９の動作変更ルールの絞込み（Ｓ５２）を展開した詳細手順に対応する。

図１４のステップＳ２１０では、アプリケーション履歴記憶部１４０に記憶された画面構造グラフと、ＷＥＢアプリケーションの動作候補リストの動作変更ルールの現在行の画面構造グラフがパターン一致するものを、動作変更ルールのリストとして絞り込み、パターン一致するものを、動作変更ルール候補のリストとする。

ステップＳ２１１では、アプリケーション履歴記憶部１４０に記憶された遷移フィールドの値によって、遷移が発生するか否かを確認し、ＷＥＢアプリケーションの動作変更ルールの現在行の遷移の値と一致しているかによって、動作変更ルールのリストを絞り込み、一致しているものを動作変更のルールとする。

これにより、過去の履歴情報だけではなく、画面を操作する後の画面構造、画面のリンク構造、画面遷移の有無によって、動作変更方法を変えることが可能となる。

＜第３の実施例＞
次に、本発明の第３の実施例について説明する。図１５は、本発明の第３の実施例の構成を示す図である。前記第２の実施例においては、動作変更手段１２１は、クライアントサイドで動作をしていたが、本発明の第３の実施例においては、それに加え、サーバーと（不図示）通信し、サーバー側で動作変更を行うサーバー部動作変更手段３０１を備える。クライアント部１１０の動作変更手段１２１とサーバー部動作変更手段３０１の通信方式は、様々なものが考えられるが、好適な例として、例えばＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストによる呼び出しである。

クライアント部１１０の動作変更手段１２１は、サーバー部動作変更手段３０１にリクエストを送り、サーバー側の処理が終わった後に、そのレスポンスを用いて、動作変更を行うようにしてもよい。

図１６は、本発明の第３の実施例の動作変更内容定義の例を示す図である。サーバー部動作変更手段３０１は、クライアント部１１０の動作変更手段１２１と通信することで、実際の動作変更をサーバー上で行う。サーバーにおいて、動作変更内容定義に記述されたサーバー動作変更スクリプトでは、外部ツール３０２と連携してもよい。

サーバー部動作変更手段３０１としては、様々なものが考えられるが、例えばユーザがフォームに入力した値をメールで送信する等の処理を、サーバー側の動作変更処理で行ってもよい。

本実施例では、クライアント部１１０で動作変更を行った後に、サーバー部動作変更手段３０１と通信する点が、前記第２の実施例と相違している。クライアント部の動作変更手段１２１は、動作変更が必要になるときに、サーバー部動作変更手段３０１に対して、送信するデータとして、画面に含まれるＨＴＭＬ、ＨＴＭＬのフォームへの入力値などを送信する。

サーバー部動作変更手段３０１は、動作変更ルール管理部１６０から、動作変更ルールのサーバー動作変更スクリプトを取得し、その処理を実行する。これにより、動作変更をサーバー側の処理によっても行うことができる。またクライアントの動作変更部とサーバーの動作変更部で通知することで、クライアントの操作内容に応じて、サーバーの動作変更部で動作を変更することが可能となる。

＜第４の実施例＞
次に、本発明の第４の実施例について説明する。図１７は、本発明の第４の実施例の構成を示す図である。本発明の第４の本実施例では、前記各実施例において、プロキシ部１５０で行っていた処理の一部又は全てをブラウザ（Ｗｅｂブラウザ）の拡張として実現するものである。

前記第２の実施例では、プロキシ部１５０が制御スクリプトを埋め込み、動作変更部１２０、行動記録部１３０の各手段を、クライアントからのレスポンスに埋め込んでおり、プロキシされたＷＥＢアプリケーションをこれらの手段で制御を行っていた。

本実施例では、動作変更部１２０と行動記録部１３０を、ブラウザの拡張機能またはブラウザの制御ツールとして実現する。動作変更部１２０、行動記録部１３０が、直接、ブラウザの操作を記録し、動作変更部１２０は、直接、ブラウザの操作を監視し、ブラウザの動作変更を変更する。

図１８は、本発明の第４の実施例の動作の手順を表すフローチャートである。図１７、図１８を参照して、本発明の第４の実施例の動作を説明する。前記第２の実施例では、図１３のフローチャートに示したように、プロキシ処理（ステップＳ１０）が存在していたが、本実施例では、プロキシ処理手順は存在しない。

また動作変更部１２０、行動記録部１３０の各手段がブラウザ拡張として動作するため、ユーザ操作記録、動作変更判定、動作変更、画面遷移記録などのステップでは、各手段がブラウザにより評価されて実行される代わりに、ブラウザの拡張として動作する。

ブラウザの拡張ツールは、ブラウザからのイベントを受け取り、そのイベントに応じて動作をする。これにより、ＷＥＢアプリケーションをプロキシすることなく、ユーザはＷＥＢアプリケーションを、直接、操作することができる。そして、その操作に対して動作の変更を行うことが可能となる。

＜第５の実施例＞
次に、本発明の第５の実施例について説明する。図１９は、本発明の第５の実施例の構成を示す図である。前記第２の実施例では、図１０に示したように、行動記録部１３０の画面構造記録手段１３１、画面構造グラフ記録手段２０１、画面遷移履歴記録手段２００が、プロキシ部１５０の制御スクリプト埋め込み部１５２に埋め込まれ、クライアント部１１０において表示されるタイミングで解釈され、実行可能な状態になっていた。

本実施例では、図１０における画面構造記録手段１３１、画面構造グラフ記録手段２０１、画面遷移履歴記録手段２００を、プロキシ部１５０に配置し、各手段をサーバー側で実行する。すなわち、本実施例においては、図１９に示すように、プロキシ部１５０に、サーバー行動記録部６００を備え、サーバー行動記録部６００は、画面構造記録手段６０１、画面構造グラフ記録手段６０２、画面遷移履歴記録手段６０３を備えている。一方、クライアント部１１０の行動記録部１３０は、操作記録手段１３２のみを備える。

サーバー行動記録部６００における画面構造記録手段６０１、画面構造グラフ記録手段６０２、画面遷移履歴記録手段６０３の各手段は、サーバー側で実行される点が相違する以外、その動作は、前記第２の実施例と変わらない。また、前記第２の実施例と同様に、サーバー行動記録部６００における各手段で保存するデータは、アプリケーション履歴記憶部１４０に保存を行う。

図２０は、本実施例の動作変更装置を用いたＷＥＢシステムの構成を示す図である。図２０に示すように、このＷＥＢシステムは、ＷＥＢアプリケーションの動作変更部１２０、行動記録部１３０、アプリケーション履歴記憶部１４０、プロキシ部１５０、動作変更ルール管理部１６０、アプリケーション定義管理部１７０を備えている。

ＷＥＢアプリケーションの動作変更部１２０は、ユーザの操作を変更する動作変更手段１２１と、ユーザ操作に対する動作変更の必要性を判定する動作変更必要性判定手段１２２と、を備えている。

行動記録部１３０は、ユーザが操作している画面の画面構造を記録する画面構造記録手段１３１、ユーザの画面に対する操作を記録する操作記録手段１３２と、を備えている。

アプリケーション履歴記憶部１４０は、行動記録部１３０によるＷＥＢアプリケーションの操作の履歴を記録する。

プロキシ部１５０は、クライアント部１１０からのリクエストに対してＷＥＢアプリケーションをプロキシし実際のＷＥＢアプリケーションと通信を行う通信処理部１５１と、動作変更部１２０及び行動記録部１３０を生成するための制御スクリプト埋め込み部１５２を備えている。

動作変更ルール管理部１６０は、動作変更手段１２１による動作変更のルールを管理する。

アプリケーション定義管理部１７０は、動作変更装置で参照されるＷＥＢアプリケーションの定義の管理を行う。

図２２、図２３、図２４、図２５は、アプリケーション定義管理部１７０に登録されている画面構造定義１７１における画面Ａ、Ｂ、Ｃ、Ｄを示す図である。画面要素パターンと、該画面要素パターンの周辺構造パターンを含む。

図２６、図２７、図２８、図２９は、画面構造ＩＤ＝Ａ、Ｂ、Ｃ、Ｄにおける、アプリケーション定義管理部１７０に登録されているユーザ操作定義１７２をそれぞれ示す図である。

図２６の操作ＩＤ＝Ａ１は、図２２の画面Ａ（画面構造ＩＤ＝Ａ）において、操作ＩＤがＡ１の操作は、操作名が「Ｊ１にテキスト入力」、操作は「入力」、操作対象の要素パターンは「／／ｉｎｐｕｔ［＠ｎａｍｅ＝“Ｊ”］」、操作前画面からの画面構造グラフは「Ａ→Ｂ」、遷移発生は「０」（＝「遷移無し」）であり、操作ＩＤ＝Ａ２は、操作名が「Ｐクリック」、操作は「クリック」、操作対象の要素パターンは「／／ｉｎｐｕｔ［＠ｔｙｐｅ＝“ｓｕｂｍｉｔ”］」、操作前画面からの画面構造グラフは「Ａ→Ｂ」、遷移発生は「１」（＝「遷移有り」）である。

図２７の操作ＩＤ＝Ｂ１は、図２３の画面Ｂ（画面構造ＩＤ＝Ｂ）において、操作名が「リンククリック」、操作は「クリック」、操作対象の要素パターンは「／／ａ」、操作前画面からの画面構造グラフは「Ｂ→Ｃ Ｂ→Ｄ」、遷移発生は「１」（＝「遷移有り」）であり、操作ＩＤ＝Ｂ２は、操作名が「Ｑクリック」、操作は「クリック」、操作対象の要素パターンは「／／ｉｎｐｕｔ［＠ｔｙｐｅ＝“ｓｕｂｍｉｔ”］」、操作前画面からの画面構造グラフは「Ｂ→Ｃ Ｂ→Ｄ」、遷移発生は「１」（＝「遷移有り」）である。

図２８の操作ＩＤ＝Ｃ１は、図２４の画面Ｃ（画面構造ＩＤ＝Ｃ）において、操作名が「Ｒクリック」、操作は「クリック」、操作対象の要素パターンは「／／ａ［ｔｅｘｔ（）＝’リンク（Ｍ）’］」、遷移発生は「１」（＝「遷移有り」）である。

図２９は、図２５の画面Ｄ（画面構造ＩＤ＝Ｄ）のユーザ操作定義１７２であるが、画面Ｄは出力画面であり、ユーザの入力操作等は行われない（入力欄は表示されない）。

図３０は、ＷＥＢアプリケーション１をユーザが操作したときのアプリケーション履歴記憶部１４０のデータの一例を示す図である。

図３１は、動作変更ルール管理部１６０に登録されているアプリケーション動作変更ルールの一例を示す図である。操作ＩＤ＝Ａ１、Ａ２は動作変更対象とはされず、操作ＩＤ＝Ｂ２は動作変更対象とされ、操作実行前に動作変更が行われ（図１３のＳ７０の判定ではＹＥＳ）、動作変更ＩＤは１とする。

図３２は、動作変更ルール管理部１６０に登録されているアプリケーション動作変更ルールの別の例を示す図である。操作手順は、操作ＩＤ＝Ａ２、Ａ１、Ｂ２の順で行われることになるが、この場合、操作Ｂ２は図３１とは異なり、動作変更対象とされていない。図３３は、操作手順による動作制限を模式的に示す図である。操作手順がＡ１、Ａ２、Ｂ２の場合、Ｂ２は動作制限対象とはならず、動作変更が行われる。一方、操作手順がＡ２、Ａ１、Ｂ２の場合、Ｂ２は動作制限対象とされ、動作変更は行なわれない。

図３４は、動作変更ルール管理部１６０に登録されている動作変更内容定義である。操作ＩＤ＝Ａ１、Ａ２は動作変更対象ではない。操作ＩＤ＝Ｂ２は動作変更対象であり、操作実行前に動作変更が行われ、動作変更＝１である。

図２１は、ＷＥＢアプリケーションの動作を表す説明図である。ＷＥＢアプリケーション１は、画面Ａ、画面Ｂ、画面Ｃ、画面Ｄの４ページにまたがるＷＥＢアプリケーションである。画面Ａ、画面Ｂ、画面Ｃ、画面Ｄの画面構造定義１７１は、図２２乃至図２５にそれぞれ示されており、ユーザ操作定義１７２は図２６乃至図２９にそれぞれ示されている。

画面Ａは、
／ｈｔｍｌ／ｂｏｄｙ／ｆｏｒｍ／ｉｎｐｕｔ［＠ｎａｍｅ＝“Ｊ”］のパスにあるテキストボックスＪと、
／ｈｔｍｌ／ｂｏｄｙ／ｆｏｒｍ／ｉｎｐｕｔ［＠ｔｙｐｅ＝“ｓｕｂｍｉｔ”］のパスにあるボタンＰと、
が配置されており、Ｐボタンを押す（図２６の操作ＩＤ＝Ａ２のＰクリック）と、画面Ｂに遷移する。

画面Ｂは、リンクＫとボタンＱが配置されており、リンクＫを押すと（図２７の操作ＩＤ＝Ｂ１のリンククリック）、画面Ｄに遷移し、ボタンＱを押すと（図２７の操作ＩＤ＝Ｂ２のＱクリック）、画面Ｃに遷移する。

画面Ｃは、リンクＬとボタンＲが配置されており、リンクＬを押しても遷移はしない。

画面Ｄは、「Ｈｅｌｌｏ」と書かれたテキストが存在している。

次に、図２０に示した本実施例の動作について、図１３のフローチャートを参照して説明する。

（リクエスト待ち、プロキシ処理１回目）
ユーザが、ＷＥＢブラウザが画面Ａにアクセスし、ＷＥＢブラウザがＷＥＢアプリケーション１にリクエストを送る。

通信処理部１５１がリクエストを受信し（ステップＳ１０）、ＷＥＢアプリケーション１にアクセス要求を送る。

通信処理部１５１は、ＷＥＢアプリケーション１からレスポンスを受け取る。制御スクリプト埋め込み部１５２は、そのレスポンスに、行動記録部１３０及び動作変更部１２０を、ＷＥＢブラウザ１００が解釈可能な形式のＪａｖａＳｃｒｉｐｔ（サンマイクロシステムズ社の登録商標）を埋め込む。（Ｓ１０）。

（画面構造記録１回目）
ＷＥＢブラウザ１００がレンダリングエンジンにより、レスポンスを表示するときに、画面構造記録手段１３１のＪａｖａＳｃｒｉｐｔ（サンマイクロシステムズ社の登録商標）が実行され、画面構造記録手段１３１は、アプリケーション定義管理部１７０で管理される画面構造定義Ａ、Ｂ、Ｃ、Ｄの画面構造定義の中から画面構造が一致するものを探す。

ステップＳ２０では、画面Ａの画面構造を記録する。画面構造定義Ａ（図２２）には、画面構造定義Ａの要素パターンの１行目は、
／／ｉｎｐｕｔ［＠ｎａｍｅ＝“Ｊ”］
のパスがある。

これは、画面Ａの
／ｈｔｍｌ／ｂｏｄｙ／ｆｏｒｍ／ｉｎｐｕｔ［＠ｎａｍｅ＝“Ｊ”］
のパスにあるテキストボックスＪとマッチする。

また、画面構造定義Ａの１行目の画面要素パターンの周辺構造のパターンであり、
．．／＊／ｉｎｐｕｔ［＠ｔｙｐｅ＝“ｓｕｂｍｉｔ”］は、
／ｈｔｍｌ／ｂｏｄｙ／ｆｏｒｍ／ｉｎｐｕｔ［＠ｔｙｐｅ＝“ｓｕｂｍｉｔ”］
のパスにあるボタンＰにマッチし、このパターンにマッチする要素が存在するといえる。

画面構造定義Ａの２番目の行については、画面要素パターン
／／ｉｎｐｕｔ［＠ｔｙｐｅ＝“ｓｕｂｍｉｔ”
は、画面Ａの
／ｈｔｍｌ／ｂｏｄｙ／ｆｏｒｍ／ｉｎｐｕｔ［＠ｔｙｐｅ＝“ｓｕｂｍｉｔ”］
にマッチする。

また、画面構造定義Ａ（図２２）における画面要素パターンの周辺構造パターンの
．．／＊／ｉｎｐｕｔ［＠ｎａｍｅ＝“Ｊ”］
として、画面Ａの
／ｈｔｍｌ／ｂｏｄｙ／ｆｏｒｍ／ｉｎｐｕｔ［＠ｎａｍｅ＝“Ｊ”］がマッチし、その要素が存在する。

従って、画面構造定義Ａは、画面Ａの画面構造定義の候補となる。

同様にして、画面構造定義Ｂ、Ｃ、Ｄについても、全行を、画面Ａについてマッチングを行う。画面構造定義Ｂは、１行目のパターン画面要素パターンと、画面要素パターンの周辺構造パターンがマッチしないため、画面構造定義候補とならない。

画面構造定義Ｃ、Ｄについても、同様に、画面構造定義パターンがマッチしない行が存在するため、候補とはならない。従って、画面Ａの画面構造定義ＩＤはＡとなる。

画面構造記録手段１３１は、図３０に示すように、アプリケーション履歴記憶部１４０の画面構造定義ＩＤカラムの現在行に「Ａ」を記録する。

（画面構造グラフ記録１回目）
画面Ａから辿れる先（遷移可能な画面）として、画面構造定義Ａに記載された要素に遷移先の画面が存在するかを調べる。

／ｈｔｍｌ／ｂｏｄｙ／ｆｏｒｍ／ｉｎｐｕｔ［＠ｔｙｐｅ＝“ｓｕｂｍｉｔ”］
のパスに一致する要素は、ｉｎｐｕｔ要素であり、かつ、ＰＯＳＴするもの（ＰＯＳＴのｓｕｂｍｉｔ処理）であることから、画面遷移する可能性があり、その画面を予め取得する。

画面Ｂのリクエストを取得し、アプリケーション定義管理部に定義されている画面構造定義の中からマッチする画面構造定義を検索する。

ステップＳ２０のステップで示したように、画面構造定義の各行を探索すると、ＰＯＳＴして、画面遷移が発生した後の画面の画面構造定義はＢのみにマッチすることがわかる。

本実施例において、画面構造グラフを辿る階層を１階層とすると、画面Ａの画面構造グラフは、Ａ−＞Ｂとなり、画面構造グラフ記録手段２０１は、図３０に示すように、アプリケーション履歴記憶部１４０の画面構造グラフのカラムの１行目に「Ａ−＞Ｂ」を記憶する（ユーザ操作待ち、ユーザ操作記録１回目）。

続いて、ユーザが画面ＡのテキストボックスＪに、「東京駅」を発行し、ブラウザがクライアント部１１０にイベントを発行する。

クライアント部１１０は、イベントを受け取り、行動記録部１３０は、アプリケーション履歴記憶部１４０の
操作に、「入力」、
操作対象として、
／／ｉｎｐｕｔ［＠ｎａｍｅ＝“Ｊ”］、
値として、
「東京駅」
を記録する。

（画面遷移発生記録１回目）
続いて、画面遷移発生記録のステップでは、画面遷移が発生するかを推定するが、テキストボックスであるため、遷移は発生しないと推定し、アプリケーション履歴記憶部１４０に０と記憶する（図１１参照）。

（動作変更必要性判定１回目）
動作変更判定手順のステップＳ５１（図９参照）では、続いて動作変更必要性判定手段１２２は、アプリケーション履歴記憶部から取得するデータカーソル行を最終行に設定する。現在記録されている行は、図３０のＩＤ１の行のみである。

（動作変更ルール絞り込み）
動作変更判定手順のステップＳ５２（図９参照）では、動作変更必要性判定手段１２２は、動作変更ルールをアプリケーション履歴記憶部１４０のデータを用いて絞り込む。

（動作変更ルールの現在行設定）
動作変更ルールの絞込み手順のステップＳ５２１（図１４）では、動作変更ルールの現在行が設定されていないので、動作変更ルール群の現在行として先頭行を設定する。ここでは、図３１のＡ１の行が先頭行であり、これを現在行として設定する。

（操作による動作変更ルールの絞込み）
動作変更ルールの絞込み手順のステップＳ５２２（図１４）では、アプリケーション履歴記憶部に記憶された操作から動作変更ルールの絞込みを行う。現在、アプリケーション履歴記憶部の現在行には、画面構造定義ＩＤとして「Ａ」、操作として「入力」、操作対象として、
／／ｉｎｐｕｔ［＠ｎａｍｅ＝“Ｊ”］、
値として、
「東京駅」
が記憶されている。

まず、取得した、画面構造定義ＩＤ、操作、操作対象の値が、ユーザ操作定義Ａ、Ｂ、Ｃ、Ｄ、Ｅの定義のどの操作ＩＤの行にマッチするかを調べる。

一致する行は、ユーザ操作定義Ａの操作ＩＤがＡ１のみの行である。Ａ１を含む動作変更ルールを探すと図３１の動作変更ルールが動作変更対象候補リストとなる。

（画面構造グラフによる動作変更ルールの絞込み）
動作変更ルールの絞込み手順のステップＳ２１０（図１４参照）では、アプリケーション履歴記憶部１４０の現在行に記憶された画面構造グラフの値によって、動作変更ルールの絞込みを行う。これにより、図３１の動作変更ルールは動作変更ルール候補である。

（遷移による動作変更ルールの絞込み）
動作変更ルールの絞込み手順のステップＳ２１１（図１４参照）では、ユーザの遷移の有無がＷＥＢアプリケーション履歴部の現在行と動作変更ルールの現在行とで一致するかを調べ、現在行はであるため一致している。従って、図３１の動作変更ルールは動作変更ルール候補である。

（動作変更リストが空か否かの判定）
ステップＳ５３（図９参照）では、アプリケーション動作変更候補リストが空ではないので、図９のステップＳ５５に進む。

ステップＳ５５（図９参照）では、現在の候補リストの中の動作変更ルールの現在行は全て最終行ではないので、ステップＳ５７に進み、動作変更不要であるとする。これにより、動作変更判定手順は終了する。

ステップＳ６０（図１３参照）では、動作変更が不要であるため、ステップＳ１００に進む。

ステップＳ１００（図１３参照）では、アプリケーション履歴記憶部１４０の現在行の遷移のカラムの値は０であるため、遷移は発生しない。従って、ステップＳ３０（図１３参照）に進む。

（ユーザ操作記録２回目）
ユーザは続いて、画面ＡのＰボタンを押す。ＷＥＢブラウザはイベントを発行し、そのイベントを、動作変更装置のクライアント部１１０が受け取り、操作記録手段１３２が動作し、操作記録手段１３２は、アプリケーション履歴記憶部１４０に新たな行を追加する。

画面遷移は発生していないので、画面識別ＩＤはＡとして、アプリケーション履歴記憶部１４０に記憶する。操作記録については、先ほどテキストボックスＪに入力の操作時の説明と同様の手順の処理を行う。

行動記録部１３０は、アプリケーション履歴記憶部１４０の操作に「クリック」、操作対象として、
／／ｉｎｐｕｔ［＠ｔｙｐｅ＝“ｓｕｂｍｉｔ”］、
値は
「なし」
を記録する。

（画面遷移記録２回目）
画面ＡのボタンＰをクリックしたときに、遷移が発生するかどうかを、対象要素を見て調べると、ｔｙｐｅ属性がｓｕｂｍｉｔのｉｎｐｕｔ要素をクリックしていることから、遷移すると判断し、アプリケーション履歴記憶部１４０の遷移カラムの値に「１」を記録する（図１１参照）。

（動作変更判定２回目）
ステップＳ５０（図１３参照）で、動作変更判定を最初の１回目と同様に行うと、動作変更ルールが対象候補となる。

ステップＳ６０（図１３参照）では、動作変更は不要であるため、ステップＳ１００（図１３参照）に進む。
ステップＳ１００では、アプリケーション履歴記憶部１４０の遷移カラムの値から遷移が発生するため（ＹＥＳ分岐）、ステップＳ００に進む。

（プロキシ処理２回目）
このステップについては、前回と同一のステップである。

（画面構造記録２回目）
ＷＥＢブラウザ１００がレンダリングエンジンによりレスポンスを表示するときに、画面構造記録手段１３１のＪａｖａＳｃｒｉｐｔ（サンマイクロシステムズ社の登録商標）が実行され、画面構造記録手段１３１は、アプリケーション定義管理部１７０で管理される画面構造定義Ａ、Ｂ、Ｃ、Ｄの画面構造定義の中から、画面構造が一致するものを探し、その定義の画面構造定義ＩＤを、アプリケーション履歴記憶部１４０の画面構造定義ＩＤに記憶する。

画面構造定義Ｂには、画面構造定義Ｂの１行目の
／／ｉｎｐｕｔ［＠ｔｙｐｅ＝“ｓｕｂｍｉｔ”］
は、ボタンＰにマッチし、画面要素パターンの周辺構造パターンとして指定されたリンクＫが存在する。

また、画面構造定義２行目の
／／ａ［ｔｅｘｔ（）＝“リンク（Ｋ）”］
として、画面ＢのリンクＫが存在する。従って画面構造定義Ｂは、全行が現在の画面構造にマッチする。その他の画面構造定義はマッチしない。従って、アプリケーション履歴記憶部１４０の画面構造定義ＩＤに、画面Ｂの画面構造定義ＩＤとして、Ｂを記録する。

（画面構造グラフ記録２回目）
画面Ｂから辿れる先として、画面構造定義Ｂに記載された要素に遷移先の画面が存在するかを調べる。

／ｈｔｍｌ／ｂｏｄｙ／ｆｏｒｍ／ｉｎｐｕｔ［＠ｔｙｐｅ＝“ｓｕｂｍｉｔ”］
のパスに一致する要素は、ｉｎｐｕｔ（入力）要素で、かつ、ＰＯＳＴ（ポスト）するものであることから、遷移する可能性があり、その画面を予め取得する。

すなわち、画面Ｃを取得し、アプリケーション定義管理部に定義されている画面構造定義の中からマッチする画面構造定義を検索する。

また、ステップＳ２０のステップで示したように画面構造定義の各行を探索すると、ＰＯＳＴして、画面遷移が発生した後の画面の画面構造定義はＣのみにマッチすることがわかる。

また、同様に、
／／ａ［ｔｅｘｔ（）＝“リンク（Ｋ）”］
に該当する要素も予め画面を取得する。

その結果、画面Ｄにリクエストを送り、そのレスポンスを取得し、画面構造を解析すると画面構造定義はＤとなる。

本実施例の説明では、グラフをたどる階層を１階層とすると、画面Ｂの画面構造グラフは、
Ｂ−＞Ｃ、Ｂ−＞Ｄ
となり、画面構造グラフ記録手段２０１は、図３０に示すようにアプリケーション履歴記憶部１４０の画面構造グラフのカラムの３行目に
「Ｂ−＞Ｃ、Ｂ−＞Ｄ」
を記憶する（図１１参照）。

（ユーザ操作待ち３回目、ユーザ操作記録３回目）
ユーザは画面Ｂで、ボタンＱをクリックする。ＷＥＢブラウザはイベントを発行し、そのイベントを動作変更装置のクライアント部１１０が受け取り、操作記録手段１３２が動作する。

操作記録手段１３２は、画面構造記録時に、アプリケーション履歴記憶部１４０の新規行が追加されているので、その行にユーザ操作を記録する。

図３０の第３行目に示すように、
操作として「クリック」、
操作対象として
／／ｉｎｐｕｔ［＠ｔｙｐｅ＝“ｓｕｂｍｉｔ”］
が設定される。

（画面遷移記録３回目）
ボタンＱをクリックしたときに、画面遷移が発生するかどうかを、対象要素を見て調べると、ｔｙｐｅ属性がｓｕｂｍｉｔのｉｎｐｕｔ要素をクリックしていることから、画面遷移すると判断し、アプリケーション履歴記憶部１４０の遷移カラムの値に「１」を記録する。

（動作変更必要性判定３回目）
動作変更判定手順のステップＳ５１（図９参照）において、続いて、動作変更必要性判定手段１２２は、アプリケーション履歴記憶部１４０の現在行を次の行に変更する。アプリケーション履歴記憶部１４０の３行目、ＩＤが３の行（図１１参照）が現在行となる。

（動作変更ルールの絞り込み）
ステップＳ５２において、動作変更必要性判定手段１２２は、動作変更ルールをアプリケーション履歴記憶部１４０のデータを用いて絞り込む。

（動作変更ルールの現在行の設定）
ステップＳ５２１において、動作変更ルールの現在行が設定されていて、次の行が存在する場合には現在行を次の行に設定する。これにより、操作ＩＤがＢ２の行が現在行となる。

（操作による動作変更ルールの絞込み）
ステップＳ５２２(図１４参照)において、アプリケーション履歴記憶部１４０に記憶された操作から動作変更ルールの絞込みを行う。

現在、アプリケーション履歴記憶部１４０の現在行には、
画面構造定義ＩＤとして「Ｂ」、
操作として「クリック」、
操作対象として
／／ｉｎｐｕｔ［＠ｔｙｐｅ＝“ｓｕｂｍｉｔ”］、
値は「なし」
という行が記憶されている。

まず、取得した画面構造定義ＩＤ、操作、操作対象の値が、ユーザ操作定義Ａ、Ｂ、Ｃ、Ｄ、Ｅの定義のどの操作ＩＤの行にマッチするかを調べる。

一致する行は、ユーザ操作定義Ｂの操作ＩＤのＢ２のみがマッチする。Ｂ２を含む動作変更ルールを探すと、図３１の動作変更ルールが動作変更対象候補リストとなる。

（画面構造グラフによる動作変更ルールの絞込み）
ステップＳ２１０（図１４参照）において、アプリケーション履歴記憶部１４０の現在行に記憶された画面構造グラフの値によって、動作変更ルールの絞込みを行う。アプリケーション履歴記憶部１４０の画面構造グラフには、「Ｂ→Ｃ、Ｂ→Ｄ」が記録されており、動作変更ルールの操作ＩＤのＢ２、すなわち、図２７に示すようにユーザ操作定義Ｂの操作ＩＤのＢ２の、操作前画面からの画面構造グラフの値に一致するため、図３１の動作変更ルールは、動作変更ルール候補である。

（遷移による動作変更ルールの絞込み）
ステップＳ２１１（図１４参照）において、ユーザの遷移の有無がアプリケーション履歴記憶部１４０の現在行と動作変更ルールの現在行とで一致するかを調べ、現在行はであるため一致している。

従って、図３１の動作変更ルールは、動作変更ルール候補である。以上で、動作変更ルールの絞込み手順は終了する。

ステップＳ５３（図９参照）において、アプリケーション動作変更が空ではないので、Ｓ５５に進む動作変更ルール行が最終行でかつ動作変更対象であるので、動作変更が必要であると判定する。これで動作変更判定手順は終了する。

ステップＳ６０（図１３参照）において、動作変更が必要であると判定され、ステップＳ７０（図１３参照）に進み、ステップＳ７０では動作変更ルールの現在行が操作前動作変更のカラムの値が１であるので、操作前変更を実行する。従って、ステップＳ８０（図１３参照）では動作変更ルールの現在行の動作変更ＩＤ１の動作変更ルールを実行する。

動作変更ＩＤ１の動作変更内容定義は、図３４に示すように、アラートを出力するスクリプトである。これを実行時に評価し「動作変更」というアラートを出力する。

ステップＳ１００（図１３参照）では、アプリケーション履歴記憶部１４０の現在行では、画面遷移が発生すると記録されているので、ステップＳ００（図１３参照）に進む。このようにして、適用対象のＷＥＢアプリケーション候補を絞り込み、適合した動作変更ルールを実行し、ユーザ操作の動作変更を行う。

本発明によれば、複数のページから構成される既存のＷＥＢアプリケーションを変更せずに、ＷＥＢアプリケーションの一部に対する操作を変更する、といったことに利用できる。

なお、上記の特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

１００ ＷＥＢブラウザ
１１０ クライアント部
１２０ 動作変更部
１２１ 動作変更手段
１２２ 動作変更必要性判定手段
１３０ 行動記録部
１３１ 画面構造記録手段
１３２ 操作記録手段
１４０ アプリケーション履歴記憶部
１５０ プロキシ部
１５１ 通信処理部
１５２ 制御スクリプト埋め込み部
１６０ 動作変更ルール管理部
１７０ アプリケーション定義管理部
１７１ 画面構造定義
１７２ ユーザ操作定義
１７５ ＷＥＢアプリケーション
２００ 画面遷移履歴記録手段
２０１ 画面構造グラフ記録手段
３０１ サーバー部動作変更手段
６００ サーバー行動記録部
６０１ 画面構造記録手段
６０２ 画面構造グラフ記録手段
６０３ 画面遷移履歴記録手段

Claims (28)

1. ＷＥＢアプリケーションの画面構造を定義する画面構造情報と、
   ユーザ操作を定義するユーザ操作定義情報と、
   ＷＥＢアプリケーションの動作変更のルールと、
   を記憶する手段と、
   ＷＥＢアプリケーションの画面の操作と、前記画面構造情報による前記画面構造の定義と、前記ユーザ操作定義情報によるユーザ操作の定義とに従って、ＷＥＢアプリケーションの動作変更ルールの適用条件を判定し、判定結果に応じて、ＷＥＢアプリケーションの動作変更を実行する手段と、
   を備えている、ことを特徴とする動作変更装置。
2. 前記画面構造情報が、前記画面構造の識別情報に関連付けて、画面内の要素パターンと、前記要素パターンの周辺構造のパターンとを対応付けて含み、
   前記ユーザ操作定義情報は、前記画面構造の定義において、どのような操作がどのような手順で実行可能であるかを定義するものであり、前記画面構造の識別情報に関連付けて、操作識別情報と、前記操作識別情報に対応する操作名、操作の内容、操作対象の画面内の要素パターンを含み、
   前記動作変更のルールが、操作手順の時系列にしたがって、前記操作識別情報に対応して動作変更対象であるか否か、操作実行前に、ＷＥＢアプリケーションの動作を変更するか否かの情報を含む、ことを特徴とする請求項１記載の動作変更装置。
3. ＷＥＢアプリケーションの画面構造を、画面に含まれる要素のパターンにより識別する手段と、
   ＷＥＢアプリケーションの画面構造の遷移履歴を記録する手段と、
   ＷＥＢアプリケーションに関して識別されたＷＥＢアプリケーションの画面構造に対する操作履歴を記録する手段と、
   ユーザがＷＥＢアプリケーションの画面の要素を操作したときに、前記画面の画面構造の遷移履歴と、ＷＥＢアプリケーションの各画面における操作履歴とに基づき、前記動作変更ルールを照合し、ユーザの操作に対して適用する動作変更のルールを決定する手段と、
   前記決定された動作変更ルールに基づき、ユーザによるＷＥＢアプリケーションの操作時の前記ＷＥＢアプリケーションの動作変更を行う手段と、
   を備えた、ことを特徴とする請求項１又は２記載の動作変更装置。
4. 画面の遷移が発生したときに、前記画面から辿ることのできる画面の画面構造を識別し、画面構造の遷移グラフを記録する手段を備え、
   前記動作変更のルールを決定する手段において、辿った画面構造の遷移グラフに基づき、動作変更ルールを決定する、ことを特徴とする請求項３に記載の動作変更装置。
5. ユーザがＷＥＢアプリケーションの画面の要素を操作するときに、画面の遷移が発生するか否かを判定し、画面遷移の発生の有無を、前記操作の情報とともに、時系列に記録する手段と、
   画面遷移の発生の有無の記録に応じて、画面の操作に対して適用する動作変更ルールを決定する手段と、
   を備えた、ことを特徴とする請求項３又は４に記載の動作変更装置。
6. 前記動作変更を行う手段が、クライアント上で動作し、
   前記クライアントは、ＷＥＢブラウザからのイベント発行により動作し、前記クライアント側でユーザ操作に対するＷＥＢアプリケーションの動作変更を行う動作変更部を備えている、ことを特徴とする請求項３乃至５のいずれか１項に記載の動作変更装置。
7. クライアントの動作変更部と通信をすることで動作をするサーバの動作変更部と、
   前記クライアントおよび前記サーバでの動作変更内容が記述された動作変更定義を保持するアプリケーション定義管理部と、
   ユーザが画面操作時の動作の変更を前記クライアント上又は前記サーバ上で行うように制御する手段と、をさらに備え、
   前記クライアントの動作変更部は、前記サーバの動作変更部の実行結果に対応して、ＷＥＢアプリケーションの動作変更を行う、ことを特徴とする請求項３乃至６のいずれか１項に記載の動作変更装置。
8. 前記画面構造を記録する手段と、
   前記画面遷移を記録する手段と、
   画面間の繋がりを記述した画面構造の遷移グラフを記録する手段と、
   を備えたプロキシ部を備え、
   ユーザ操作に応じて、画面構造、画面遷移、画面構造の遷移グラフを記憶するアプリケーション履歴記憶部をさらに備えている、ことを特徴とする請求項３乃至７のいずれか１項に記載の動作変更装置。
9. 前記プロキシ部が、ＷＥＢブラウザからのＷＥＢアプリケーションに対するリクエストに対するレスポンスに対して、前記ＷＥＢブラウザが実行可能なスクリプトを埋め込むことで、ＷＥＢアプリケーションの動作変更、画面構造の記録、画面遷移の履歴の記録、画面操作の記録、動作変更の必要性の判定を、クライアントで行えるようにしてなる、ことを特徴とする請求項８に記載の動作変更装置。
10. ユーザ端末がリクエストを送ったＷＥＢアプリケーションのレスポンスに、ユーザの操作を変更する動作変更部と、ユーザが操作している画面の画面構造とユーザの画面に対する操作とを記録する行動記録部を動作させるための制御スクリプトを埋め込むプロキシ部を備え、
    前記制御スクリプトは、ＷＥＢブラウザによって解釈され、
    クライアントにて、ユーザが操作を実行する際に、前記行動記録部がＷＥＢアプリケーションの構造を、
    ＷＥＢアプリケーションの画面構造、
    ユーザ操作手順のパターン、及び
    ＷＥＢアプリケーションの画面構造の遷移グラフ
    の情報のうち少なくとも１つによって特徴付けて該情報をアプリケーション履歴記憶部に保存し、
    前記動作変更部は、前記アプリケーション履歴記憶部に蓄積された、画面構造、ユーザ操作手順のパターン、画面構造の遷移グラフの情報の少なくとも１つから、動作変更ルール管理部に記憶管理されている、ＷＥＢアプリケーションの動作変更ルールの中から、適合する動作変更ルールを探し出し、
    前記動作変更ルールは、操作手順の時系列にしたがって、動作変更対象であるか否かの情報を含み、
    前記動作変更部は、ＷＥＢアプリケーションの動作変更ルールが見つかった場合に、前記動作変更ルールに記述された動作変更内容を実行し、ユーザによるＷＥＢアプリケーションの操作時の動作を変更する、ことを特徴とする動作変更装置。
11. ＷＥＢアプリケーションの画面構造を定義する画面構造情報と、
    ユーザ操作を定義するユーザ操作定義情報と、
    ＷＥＢアプリケーションの動作変更のルールと、
    を記憶部に記憶しておき、
    ＷＥＢアプリケーションの画面の操作と、前記画面構造情報による画面構造の定義、前記ユーザ操作定義情報によるユーザ操作の定義とに従って、ＷＥＢアプリケーションの動作変更ルールの適用条件を判定し、
    判定結果に応じて、ＷＥＢアプリケーションの動作変更を実行する、
    ことを特徴とする動作変更方法。
12. 前記画面構造情報が、前記画面構造の識別情報に関連付けて、画面内の要素パターンと、前記要素パターンの周辺構造のパターンとを対応付けて含み、
    前記ユーザ操作定義情報が、前記画面構造の定義において、どのような操作がどのような手順で実行可能であるかを定義するものであり、前記画面構造の識別情報に関連付けて、操作識別情報と、前記操作識別情報に対応する操作名、操作の内容、操作対象の画面内の要素パターンを含み、
    前記動作変更のルールが、操作手順の時系列にしたがって、前記操作識別情報に対応して動作変更対象であるか否か、操作実行前に動作を変更するか否かの情報を含む、ことを特徴とする請求項１１記載の動作変更方法。
13. ＷＥＢアプリケーションの画面構造を、画面に含まれる要素のパターンにより識別し、
    ＷＥＢアプリケーションの画面構造の遷移履歴を記録し、
    ＷＥＢアプリケーションに関して識別されたＷＥＢアプリケーションの画面構造に対する操作履歴を記録し、
    ユーザがＷＥＢアプリケーションの画面の要素を操作したときに、前記画面の画面構造の遷移履歴と、ＷＥＢアプリケーションの各画面における操作履歴とに基づき、前記動作変更ルールを照合し、ユーザの操作に対して適用するＷＥＢアプリケーションの動作変更のルールを決定し、
    前記決定されたＷＥＢアプリケーションの動作変更ルールに基づき、ユーザによるＷＥＢアプリケーションの操作時の前記ＷＥＢアプリケーションの動作変更を行う、ことを特徴とする請求項１１又は１２記載の動作変更方法。
14. 画面の遷移が発生したときに、前記画面から辿ることのできる画面の画面構造を識別し、画面構造の遷移グラフを記憶部に記録し、
    前記動作変更のルールを決定するにあたり、辿った画面構造の遷移グラフに基づき、前記動作変更ルールを決定する、ことを特徴とする請求項１３に記載の動作変更方法。
15. ユーザがＷＥＢアプリケーションの画面の要素を操作するときに画面遷移が発生するか否かを判定し、画面遷移の発生の有無を操作とともに時系列に記憶部に記録し、
    画面遷移の発生の有無の記録に応じて、画面の操作に対して適用する動作変更ルールを決定する、ことを特徴とする請求項１３又は１４に記載の動作変更方法。
16. 前記動作変更をクライアントで行い、
    前記クライアントはＷＥＢブラウザからのイベント発行により動作をすることで、前記クライアントでユーザ操作の動作変更を行う、ことを特徴とする請求項１３乃至１５のいずれか１項に記載の動作変更方法。
17. クライアントの動作変更部と通信をすることでサーバの動作変更部で動作し、
    前記クライアントおよび前記サーバでの動作変更内容が記述された動作変更定義を保持し、
    ユーザが画面操作時の動作の変更をクライアント上又はサーバ上で行うように制御すし、
    前記クライアントの動作変更部は、前記サーバの動作変更部の実行結果に対応して、ＷＥＢアプリケーションの動作変更を行う、ことを特徴とする、請求項１３乃至１６のいずれか１項に記載の動作変更方法。
18. プロキシ部が、
    前記画面構造を記録し、
    前記画面遷移を記録し、
    画面間の繋がりを記述した画面構造の遷移グラフを記録し、
    ユーザ操作に応じて、画面構造、画面遷移、画面構造の遷移グラフを記憶する、ことを特徴とする請求項１３乃至１７のいずれか１項に記載の動作変更方法。
19. 前記プロキシ部が、ＷＥＢブラウザからのＷＥＢアプリケーションに対するリクエストに対するレスポンスに対して、前記ＷＥＢブラウザが実行可能なスクリプトを埋め込むことで、動作変更、画面構造の記録、画面遷移の履歴の記録、画面操作の記録、動作変更の必要性の判定を、クライアントで行えるようにしてなる、ことを特徴とする請求項１８に記載の動作変更方法。
20. ユーザ端末がＷＥＢアプリケーションのリクエストを送り、
    プロキシ部は、ＷＥＢアプリケーションのレスポンスに、ユーザの操作を変更する動作変更部と、ユーザが操作している画面の画面構造とユーザの画面に対する操作とを記録する行動記録部を動作させるための制御スクリプトを埋め込み、
    前記制御スクリプトは、ＷＥＢブラウザによって解釈され、
    クライアントにて、ユーザが操作を実行する際に、前記行動記録部がＷＥＢアプリケーションの構造を、
    ＷＥＢアプリケーションの画面の構造、
    ユーザ操作手順のパターン、及び
    ＷＥＢアプリケーションの画面構造の遷移グラフの
    情報の少なくとも１つによって特徴付けアプリケーション履歴記憶部に保存し、
    前記動作変更部は、前記アプリケーション履歴記憶部に蓄積された、画面構造、ユーザ操作履歴、画面構造の遷移グラフの情報の少なくとも１つから、動作変更ルール管理部に記憶管理されている適合するＷＥＢアプリケーションの動作変更ルールを探し出し、
    前記動作変更ルールは、操作手順の時系列にしたがって、動作変更対象であるか否かの情報を含み、
    前記動作変更部は、ＷＥＢアプリケーションの前記動作変更ルールが見つかった場合に、前記動作変更ルールに記述された動作変更内容を実行し、ユーザによるＷＥＢアプリケーションの操作時の動作を変更する、動作変更方法。
21. ＷＥＢアプリケーションの画面構造を定義する画面構造情報と、
    ユーザ操作を定義するユーザ操作定義情報と、
    ＷＥＢアプリケーションの動作変更のルールと、
    を記憶部に記憶する処理と、
    ＷＥＢアプリケーションの画面の操作と、前記画面構造情報による前記画面構造の定義、前記ユーザ操作定義情報によるユーザ操作定義とに従って、ＷＥＢアプリケーションの動作変更ルールの適用条件を判定する処理と、
    前記判定結果に応じて、ＷＥＢアプリケーションの動作変更を実行する処理と、
    をコンピュータに実行させるプログラム。
22. 前記画面構造情報が、前記画面構造の識別情報に関連付けて、画面内の要素パターンと、前記要素パターンの周辺構造のパターンとを対応付けて含み、
    前記ユーザ操作定義情報が、前記画面構造の定義において、どのような操作がどのような手順で実行可能であるかを定義するものであり、前記画面構造の識別情報に関連付けて、操作識別情報と、前記操作識別情報に対応する操作名、操作の内容、操作対象の画面内の要素パターンを含み、
    前記動作変更のルールが、操作手順の時系列にしたがって、前記操作識別情報に対応して動作変更対象であるか否か、操作実行前に動作を変更するか否かの情報を含む、請求項２１記載のプログラム。
23. ＷＥＢアプリケーションの画面構造を、画面に含まれる要素のパターンにより識別する処理と、
    ＷＥＢアプリケーションの画面構造の遷移履歴を記録する処理と、
    ＷＥＢアプリケーションに関して識別されたＷＥＢアプリケーションの画面構造に対する操作履歴を記録する処理と、
    ユーザがＷＥＢアプリケーションの画面の要素を操作したときに、前記画面の画面構造の遷移履歴と、ＷＥＢアプリケーションの各画面における操作履歴に基づき、前記動作変更ルールを照合し、ユーザの操作に対して適用する動作変更のルールを決定する処理と、
    前記決定された動作変更ルールに基づき、ユーザによるＷＥＢアプリケーション操作時の前記ＷＥＢアプリケーションの動作変更を行う処理と、
    を前記コンピュータに実行させる請求項２２記載のプログラム。
24. 画面の遷移が発生したときに、前記画面から辿ることのできる画面の画面構造を識別し、画面構造の遷移グラフを記憶部に記録する処理と、
    前記ＷＥＢアプリケーション動作変更のルールを決定するにあたり、辿った画面の遷移グラフに基づき、前記動作変更ルールを決定する処理と、
    を前記コンピュータに実行させる請求項２３記載のプログラム。
25. ユーザがＷＥＢアプリケーション画面の要素を操作するときに画面遷移が発生するか否かを判定し、画面遷移発生の有無を、前記操作とともに時系列に記憶部に記録する処理と、
    画面遷移の発生の有無の記録に応じて、画面の操作に対して適用する動作変更ルールを決定するする処理と、
    を前記コンピュータに実行させる請求項２３又は２４記載のプログラム。
26. 前記動作変更をクライアント側で行い、前記クライアントはＷＥＢブラウザからのイベント発行により動作をすることで、前記クライアントでユーザ操作の動作変更を行う処理を、前記コンピュータに実行させる請求項２３乃至２５のいずれか１項に記載のプログラム。
27. プロキシ部が、前記画面構造を記録し、
    前記画面遷移を記録し、
    画面間の繋がりを記述した画面構造の遷移グラフを記録し、
    ユーザ操作に応じて、画面構造、画面遷移、画面構造の遷移グラフを記憶する処理を前記コンピュータに実行させる請求項２３乃至２６のいずれか１項に記載のプログラム。
28. 前記プロキシ部が、ＷＥＢブラウザからのＷＥＢアプリケーションに対するリクエストに対するレスポンスに対して、前記ＷＥＢブラウザが実行可能なスクリプトを埋め込むことで、ＷＥＢアプリケーションの動作変更、画面構造の記録、画面遷移の履歴の記録、画面操作の記録、動作変更の必要性の判定を、クライアントで行えるようにする処理を前記コンピュータに実行させる請求項２７に記載のプログラム。

Images