JP6817253B2 - 表示制御装置、表示制御方法、および表示制御プログラム - Google Patents

Description

本発明は、表示制御装置、表示制御方法、および表示制御プログラムに関する。

従来、既存システムのアプリケーションに手を加えずに、操作画面上に電子的な付箋紙を貼り付けて、アプリケーションのユーザが必要とする情報を表示するアノテーション技術が知られている（非特許文献１〜５参照）。

「Web Annotation Working Group」、[online]、2014年、W3C Web Annotation Working Group、[2018年4月25日検索]、インターネット＜URL:http://www.w3.org/annotation/＞ 伊藤禎宣, et al.，"SmartCourier: アノテーションを介した適応的情報共有環境"，人工知能学会論文誌 17巻3号(2002)，pp.301-312，2002年 加藤直孝，et al.，"ホームページ上の電子メモを用いた情報共有システムの開発"，石川県工業試験場平成17年度研究報告 55(2005)，2005年 西川健一， et al.，「Webベースの業務システムのユーザインタフェース拡張方式」，信学技報，vol.116，no.124，ICM2016-19，pp.63-68，2016年7月 川端祐人，et al.，「操作画面上に業務ノウハウを直接表示するアノテーション表示・編集技術」，NTT技術ジャーナル 27(7)，pp36-39, 2015年7月

しかしながら、従来のアノテーション技術では、固定的なレイアウトの操作画面にしか対応していなかった。そのため、ＷｅｂページのリロードがなくＤＯＭ(Document Object Model)構造が変化するようなレイアウトの場合には、各業務シーンにおいてアノテーション表示の強制的な自動更新ができず、適切にアノテーション情報が更新されない場合があった。また、アノテーション表示を行う実用的な業務シーンの定義は複雑になるため、プログラミングスキルを有しない一般ユーザが定義を作成することは困難であった。

本発明は、上記に鑑みてなされたものであって、アノテーション表示を行う業務シーンの定義を容易に行い、業務シーンの変化に応じて適切にアノテーション表示を更新することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る表示制御装置は、所定のＷｅｂページのＤＯＭ要素の有無または属性値で表される該ＤＯＭ要素の状態の組み合わせで特定される業務シーンごとに、表示する付加情報を指定するルールを記憶する記憶部と、ＷｅｂページのＤＯＭ要素の状態を監視して、該状態を文脈ボードとして前記記憶部に記憶させる監視部と、前記記憶部に記憶された文脈ボードの状態と合致する前記業務シーンの状態において、前記ルールで指定された前記付加情報を表示する表示制御部と、を備えることを特徴とする。

本発明によれば、アノテーション表示を行う業務シーンの定義を容易に行い、業務シーンの変化に応じて適切にアノテーション表示を更新することができる。

図１は、本実施形態に係る表示制御装置の概略構成を例示する模式図である。 図２は、ルールのデータ構成を説明するための説明図である。 図３は、ルールのデータ構成を説明するための説明図である。 図４は、ルールの実装例を示す図である。 図５は、文脈ボードについて説明するための説明図である。 図６は、文脈ボードについて説明するための説明図である。 図７は、文脈ボードについて説明するための説明図である。 図８は、編集部の処理を説明するための説明図である。 図９は、編集部の処理を説明するための説明図である。 図１０は、編集部の処理を説明するための説明図である。 図１１は、編集部の処理を説明するための説明図である。 図１２は、編集部の処理を説明するための説明図である。 図１３は、表示制御処理手順を例示するフローチャートである。 図１４は、表示制御処理手順を例示するシーケンス図である。 図１５は、表示制御処理手順を例示するシーケンス図である。 図１６は、表示制御処理手順を例示するシーケンス図である。 図１７は、表示制御装置による表示制御処理の実施例を説明するための説明図である。 図１８は、表示制御装置による表示制御処理の実施例を説明するための説明図である。 図１９は、表示制御装置による表示制御処理の実施例を説明するための説明図である。 図２０は、表示制御装置による表示制御処理の実施例を説明するための説明図である。 図２１は、表示制御装置による表示制御処理の実施例を説明するための説明図である。 図２２は、表示制御装置による表示制御処理の実施例を説明するための説明図である。 図２３は、表示制御装置による表示制御処理の実施例を説明するための説明図である。 図２４は、表示制御装置による表示制御処理の実施例を説明するための説明図である。 図２５は、表示制御装置による表示制御処理の実施例を説明するための説明図である。 図２６は、表示制御装置による表示制御処理の実施例を説明するための説明図である。 図２７は、表示制御プログラムを実行するコンピュータを例示する図である。

以下、図面を参照して、本発明の一実施形態を詳細に説明する。なお、この実施形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。

［表示制御装置の構成］
図１は、表示制御装置１０の概略構成を例示する模式図である。図２に例示するように、本実施形態の表示制御装置１０は、ワークステーションやパソコン等の汎用コンピュータで実現され、入力部１１、出力部１２、通信制御部１３、記憶部１４、および制御部１５を備える。

入力部１１は、キーボードやマウス等の入力デバイスを用いて実現され、操作者による入力操作に対応して、制御部１５に対して処理開始などの各種指示情報を入力する。出力部１２は、液晶ディスプレイなどの表示装置、プリンター等の印刷装置、情報通信装置等によって実現される。通信制御部１３は、ＬＡＮ（Local Area Network）やインターネットなどの電気通信回線を介したネットワーク装置等の外部の装置との通信を制御する。

記憶部１４は、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。なお、記憶部１４は、ＬＡＮやインターネット等の電気通信回線を介して制御部１５と通信する構成でもよい。本実施形態において、記憶部１４には、ルール１４ａおよび文脈ボード１４ｂが記憶されている。

ルール１４ａは、所定のＷｅｂページのＤＯＭ要素の有無または属性値で表される該ＤＯＭ要素の状態の組み合わせで特定される業務シーンごとに、表示する付加情報を指定する情報である。すなわち、ルール１４ａは、所定のＷｅｂページのＤＯＭ要素の状態を組み合わせて特定された業務シーンにおいて、所定のＤＯＭ要素の近傍位置に表示する付加情報を指定する情報である。

ここで、本実施形態において、ＤＯＭ要素の状態は、ＤＯＭ要素の有無または属性値で表される。また、業務シーンは、ＤＯＭ要素の状態の組み合わせで特定される。例えば、あるパネル上のテーブル要素に「廃止申込」等の所定のラベルが存在するという業務シーンや、その後さらに、サービスを指定するフィールドに「サービスＡ」等の属性値が入力されたという業務シーン等が特定される。

図２および図３は、ルール１４ａのデータ構成を説明するための説明図である。図３に例示するように、ルール１４ａは、図２に例示するアノテーションルールをノードとするツリー構造で表される。

まず、図２に示すように、ルール１４ａにおけるノードであるアノテーションルールは、画面条件部、ＧＵＩ（Graphical User Interface）条件部、付加情報部、自己ＩＤ、参照ＩＤおよび文脈ＩＤを含む。画面条件部は、ルールの対象となるＷｅｂページを特定する条件を表す。例えば、ＷｅｂページのＵＲＬについて、指定文字列と完全一致、部分一致、あるいは正規表現一致等の条件が設定される。ここには、Ｗｅｂページのタイトルや公開時期等の情報が含められてもよい。

ＧＵＩ条件部は、ルールで指定される付加情報の対象となるＤＯＭ要素の状態を特定する条件を表す。ここには、ＤＯＭ要素を指定するセレクタ（selector）指定に加え、ＤＯＭ要素の属性値が所定値であることを条件として含めることができる。

付加情報部は、ＧＵＩ条件部で特定されたＤＯＭ要素に対して表示する付加情報（以下、アノテーションとも記す。）のプレゼンテーション設定を指定する情報である。例えば、Ｗｅｂページに対応するＤＯＭ要素が存在する場合に、当該ＤＯＭ要素の画面上の近傍位置に付加情報をオーバレイ表示することを指定する。

ここには、アノテーションアイコンやティップスの表示要素や、インタラクション（対話操作）等の表示制御を記述したＪａｖａＳｃｒｉｐｔ（登録商標）コード等が含まれてもよい。インタラクションとは、例えば、ユーザがアノテーションアイコンをマウスクリックした際に、アノテーションティップスを出現させる等のＧＵＩの振る舞いを意味する。

自己ＩＤとは、アノテーションルールを識別する情報である。文脈ＩＤとは、アノテーションルールのＧＵＩ条件部で特定されるＤＯＭ要素を識別する情報である。参照ＩＤとは、図３に示すように、各アノテーションルールをノードとしたツリー構造のルール１４ａを構築する際の親ノードの自己ＩＤを示す。

また、図３に示すように、ルール１４ａは、各アノテーションルール間の親子関係を用いて、多様に分岐する条件を、論理式（ＡＮＤ／ＯＲ）や制約条件（Ｎ項間制約）等の単純な関係を組み合わせて具体化することにより、業務シーン（以下、コンテキストと記す場合もある。）を特定している。

例えば、ルール１４ａにより、あるパネル上のテーブル要素に「廃止申込」等の所定のラベルが存在するパネル上で、サービスを指定するフィールドに「サービスＡ」等の属性値が入力されたという業務シーンが特定される。また、その場合に表示すべき付加情報を指定するルール１４ａを設定することができる。これにより、ルール１４ａは、多様な業務シーンのそれぞれにおいて表示する付加情報を指定することが可能となる。

なお、図３において、アノテーションルールとしては、付加情報部を持つ通常表示ルールと、付加情報部を持たない画面状態ルールと、付加情報部およびＧＵＩ条件部を持たない外部状態ルールとが例示されている。画面状態ルールの付加情報部と、外部状態ルールの付加情報部およびＧＵＩ条件部は網掛けで表記されている。

外部状態ルールとは、ルールの対象となるＷｅｂページのみを特定する条件を表すアノテーションルールである。また、画面状態ルールとは、ルールの対象となるＷｅｂページのＤＯＭ要素の状態のみを特定するアノテーションルールである。

図３において、ルールのツリー構造の葉にあたるアノテーションルールにのみ、付加情報部が設定されている。これにより、ルール１４ａで特定された業務シーンにおいて表示する付加情報が指定されている。

図４は、ルール１４ａの実装例を示す図である。図４において、“conditions”は、条件ルール、すなわち画面状態ルール、外部状態ルール、通常表示ルールの全種を保持している。“windownodes”は、複数の通常表示ルールの付加情報部を保持している。これら情報全体がアノテーションルールに相当する。部分Ａは、画面状態ルール、外部状態ルール等の付加情報部を持たない条件ルールに分類される。すなわち、部分Ａは“annotation”から参照されていない。なお、部分Ａには“selector”指定があることから、具体的には画面状態ルールに相当する。また、部分Ｂは、付加情報部を持つ通常表示ルールに相当する。ここで、“parentids”は他のルールの参照を意味する。これにより条件ルール間のツリー構造が表現されている。

なお、図４において、図２および図３に例示した構成とは、アノテーションルールのうち付加情報部が分離されていること、“parentids”が複数の要素を保持すること、また、ＤＯＭ要素を特定するセレクタ指定が“selector”と“option”とに分離されていることが異なる。その他の点については、図２および図３に例示した構成と同様である。

ルール１４ａは、業務シーンにさらにＷｅｂページの外部の状態を含んでもよい。すなわち、ルール１４ａには、Ｗｅｂページの外部についての所定の属性値を条件として指定するアノテーションルールが含まれてもよい。これにより、後述するように、例えば、Ｗｅｂページの外部から取得した時間が所定の時間になったことを条件とすることにより、スケジュールされた時間にアノテーションを表示することが可能となる。

図１の説明に戻る。文脈ボード１４ｂは、後述するように、ユーザに対して表示しているＷｅｂページのＤＯＭ要素の状態を表す情報であり、後述する監視部としてのルール解釈実行部１５ｃが、記憶部１４に記憶させる。

制御部１５は、ＣＰＵ（Central Processing Unit）等で実現され、メモリに記憶された処理プログラムを実行し、図２に示すように、ターゲット取得部１５ａ、コネクション部１５ｂ、ルール解釈実行部１５ｃ、および編集部１５ｄとして機能する。なお、これらの機能部は、それぞれ、あるいは一部が異なるハードウェアに実装されてもよい。

ターゲット取得部１５ａは、処理対象のＷｅｂページを取得する。具体的には、ターゲット取得部１５ａは、ＰＣ端末のＯＳのＡＰＩからＷｅｂブラウザのＷｅｂページのリストを取得する。すなわち、ターゲット取得部１５ａは、ポーリングによりＷｅｂページのリストを取得して、ルール１４ａを構成する各アノテーションルールの画面条件部に合致するＷｅｂページを特定した場合に、コネクション部１５ｂに通知する。

コネクション部１５ｂは、ターゲット取得部１５ａが特定したＷｅｂページ内に、該当のルール１４ａと後述するルール解釈実行部１５ｃとをインジェクトする。また、ルール解釈実行部１５ｃと制御部１５のその他の機能部であるアノテーションエンジンとの間の通信を制御する。

例えば、ＷｅｂブラウザがＷｉｎｄｏｗｓ（登録商標）上のＩＥ（Internet Explorer、登録商標）である場合において、ＪａｖａＳｃｒｉｐｔからＣ＃への通信には、ＭＳＨＴＭＬを利用して、ＩＥ内のＪａｖａＳｃｒｉｐｔ内の名前空間にＣ＃内のｉｎｔｅｒｆａｃｅを登録すればよい。ＪａｖａＳｃｒｉｐｔからは、Ｃ＃内のｉｎｔｅｒｆａｃｅを、ＪａｖａＳｃｒｉｐｔ関数を呼び出すように実行することができる。

また、Ｃ＃からＪａｖａＳｃｒｉｐｔへの通信においては、Ｃ＃内からはＩＥ内のＪａｖａＳｃｒｉｐｔ関数を呼び出すことができる。この場合には、基本的に非同期通信となるため、処理結果は非同期に、ＪａｖａＳｃｒｉｐｔからのコールバック機能で取得できる。

ルール解釈実行部１５ｃは、Ｗｅｂページに対する監視部として機能する。すなわち、ルール解釈実行部１５ｃは、ＷｅｂページのＤＯＭ要素の状態を監視して、該状態を文脈ボード１４ｂとして記憶部１４に記憶させる。具体的には、ルール解釈実行部１５ｃは、Ｗｅｂページ内に常駐するＪａｖａＳｃｒｉｐｔで実現され、ＷｅｂページのＤＯＭ構造の変化イベントを監視して、文脈ボード１４ｂを更新する。

ここで、図５〜図７は、文脈ボード１４ｂについて説明するための説明図である。まず、図５に例示するように、ルール解釈実行部１５ｃは、文脈ボード１４ｂに、ルール１４ａを構成する各アノテーションルールのＧＵＩ条件部で特定されるＤＯＭ要素のそれぞれについて、その状態を表すオブジェクトを生成する。各オブジェクトは前述の文脈ＩＤで識別される。

文脈ボード１４ｂでは、ＤＯＭ要素の状態は、各アノテーションルールに対する評価結果で表される。ＤＯＭ要素の状態の評価とは、該当のアノテーションルールで特定されている状態と比較することを意味する。すなわち、各アノテーションルールのＧＵＩ条件部で特定されている状態と合致している場合には「Ｔｒｕｅ」、合致していない場合には「Ｆａｌｓｅ」が設定される。

また、ルール解釈実行部１５ｃは、ＷｅｂページのＤＯＭ要素の状態が変化した場合には、このＤＯＭ要素の状態を、該当のアノテーションルールで特定されている状態と比較する評価を行う。そして、ルール解釈実行部１５ｃは、必要な場合には該当のオブジェクトの「Ｔｒｕｅ」または「Ｆａｌｓｅ」の設定値を変更する更新を行う。

なお、ルール１４ａの業務シーンにＷｅｂページの外部の状態が含まれている場合には、制御部１５は、ターゲット取得部１５ａとは別の監視部として、Ｗｅｂページの外部の状態をさらに監視する。すなわち、ルール解釈実行部１５ｃは、ルール１４ａにおいてＷｅｂページの外部の状態に割り当てられる文脈ＩＤを用いて、Ｗｅｂページの外部の状態を表すオブジェクトを文脈ボード１４ｂに生成する。また、ルール解釈実行部１５ｃは、Ｗｅｂページの外部の所定の属性値を条件として指定するアノテーションルールに対する評価結果を設定する。

このように、文脈ボード１４ｂは、ＷｅｂページのＤＯＭ要素の状態の監視に加え、Ｗｅｂページの外部の情報の状態の監視にも利用できる。例えば、図６には、文脈ボード１４ｂの利用例が示されている。図６において、ローカルコンテキストとは、ＷｅｂページのＤＯＭ要素の状態を監視するための文脈ボード１４ｂを意味し、「文脈ボード（ＤＯＭ）」と表記されている。この「文脈ボード（ＤＯＭ）」は、Ｗｅｂページごとに存在する。

また、図６には、グローバルコンテキストとして、Ｗｅｂページの外部の情報の監視に利用される文脈ボード１４ｂが例示されている。例えば、文脈ボード（業務コンテキスト切替）とは、ユーザに明示的に業務を選択させてアノテーションを切り替える場合に用いられる文脈ボード１４ｂを表す。

この場合に、アノテーションエンジンがＧＵＩを用いてユーザによる業務の選択を受け付ける。ルール解釈実行部１５ｃは、ユーザによる業務の選択の状態を表すオブジェクトを文脈ボード（業務コンテキスト切替）に生成し、所定の業務を条件として指定するアノテーションルールに対する評価結果を設定する。なお、文脈ボード（業務コンテキスト切替）は、評価結果が更新される場合に、更新前の評価結果が履歴として永続ファイルに蓄積される。

文脈ボード（利用実績集計）とは、アノテーションの表示実績を集計する場合に用いられる文脈ボード１４ｂを表す。この場合に、ルール解釈実行部１５ｃは、アイコンや付箋紙の表示状態を表すオブジェクトを文脈ボード（利用実績集計）に生成し、表示／非表示を設定する。なお、文脈ボード（利用実績集計）は、表示／非表示が変更される場合に、変更前の設定が履歴として永続ファイルに蓄積される。

文脈ボード（仮想チェック）とは、時系列上で離れた時点の状態に応じてアノテーションを切り替える場合に用いられる文脈ボード１４ｂを表す。例えば、アノテーションエンジンが、チェックボックスつきのアノテーションを仮想チェックシートとして用いて、時系列上で離れた時点の状態を確認済みの旨のユーザの入力を受け付ける。例えば、複数の項目の入力が行われたことを確認済みの旨のユーザの入力を受け付ける。

ルール解釈実行部１５ｃは、仮想チェックシートのチェック項目のチェック状態を表すオブジェクトを文脈ボード（仮想チェック）に生成し、仮想チェックシートの所定のチェック状態を条件として指定するアノテーションルールに対する評価結果を設定する。

文脈ボード（スケジュール）とは、上記した外部のシステムの状態として、例えばＰＣの時刻を監視して、スケジュール登録された時間帯にアノテーションを表示する場合に用いられる文脈ボード１４ｂを表す。この場合に、ルール解釈実行部１５ｃは、ＰＣ内部の時刻を表すオブジェクトを生成し、所定の時刻を条件として指定するアノテーションルールに対する評価結果を設定する。

文脈ボード（非表示チェック）とは、ユーザに対して２回目以降のアノテーション表示を非表示に切り替える場合に用いられる文脈ボード１４ｂを表す。例えば、アノテーションエンジンが、「以後は表示しない」ことを指定するチェックボックスつきのアノテーションを用いて、２回目以降のアノテーションを非表示にするユーザの指示入力を受け付ける。

この場合に、監視部としてのルール解釈実行部１５ｃは、このアノテーションのチェック状態を表すオブジェクトを文脈ボード（非表示チェック）に生成し、チェックボックスがチェック済みであることを条件として指定するアノテーションルールに対する評価結果を設定する。なお、文脈ボード（非表示チェック）は、評価結果が更新される場合に、更新前の評価結果が履歴として永続ファイルに蓄積される。これにより、次回起動時以降もユーザの「以後は表示しない」ことを指示入力したことによる評価結果を継承できる。

図７には、上記した各種の文脈ボード１４ｂを分類したクラス階層図が例示されている。図７に示すように、文脈ボード１４ｂは、ローカルコンテキストとグローバルコンテキストとの２つの抽象クラスに分類される。ローカルコンテキストには、上記したように、文脈ボード（ＤＯＭ）が含まれる。

グローバルコンテキストは、さらに、永続ファイルの有無で分類される。図６に示した例では、永続ファイルが生成される文脈ボード１４ｂである文脈ボード（永続ファイルあり）には、上記したように、文脈ボード（業務コンテキスト切替）、文脈ボード（利用実績集計）、文脈ボード（非表示チェック）が含まれる。また、永続ファイルが生成されない文脈ボード１４ｂである文脈ボード（永続ファイルなし）には、文脈ボード（仮想チェック）、文脈ボード（スケジュール）が含まれる。

なお、これらの文脈ボードは全て、ｕｐｄａｔｅ（ｓｔｒｉｎｇ）、ｒｅａｄ（ｓｔｒｉｎｇ）、ｓｕｂｓｃｒｉｂｅ（ｓｔｒｉｎｇ）の３つのメソッドを持つ。ｕｐｄａｔｅ（ｓｔｒｉｎｇ）とは、文脈ボードへの状態値の書き込み（更新通知あり）を意味する。ｒｅａｄ（ｓｔｒｉｎｇ）とは、文脈ボードからの状態値の読み込みを意味する。ｓｕｂｓｃｒｉｂｅ（ｓｔｒｉｎｇ）とは、文脈ボードの状態値の更新購読を意味する。

グローバルコンテキストの文脈ボードは、多様な機能を具備する様々な種類のモジュールとしての役割を兼ねさせることも可能である。例えば、文脈ボード（スケジュール）は、上記した制御部１５による監視部の役割に依存せず、Ｗｅｂページの外部の状態を自身で監視してもよい。具体的にはＰＣ端末の時刻情報を読み取る機能を、文脈ボード（スケジュール）内部で定期的に呼び出す。また、文脈ボード（永続ファイルあり）は自身が保持する情報を適切なタイミングでファイルに書き込む機能を既に持っている。このように文脈ボードは記憶部１４にありながらも、自律的に自身が担当する情報範囲の監視・永続化などを行うことも可能である。これによって、グローバルコンテキストとして扱う情報範囲を本発明の構成に対して新たに追加しようとする場合に、制御部１５に改造を加えるのではなく、対応する情報範囲の機能を具備した文脈ボードをモジュールとして追加開発するだけですむ、という利点がある。

図１の説明に戻る。ルール解釈実行部１５ｃは、表示制御部として機能する。すなわち、ルール解釈実行部１５ｃは、記憶部１４に記憶された文脈ボード１４ｂの状態と合致するルール１４ａの業務シーンの状態において、ルール１４ａで指定された付加情報を表示する。ここで、ルール解釈実行部１５ｃは、監視するＤＯＭ要素の状態が変化した際に、文脈ボード１４ｂの状態と合致する業務シーンの状態において、ルール１４ａで指定された付加情報を表示する。

具体的には、ルール解釈実行部１５ｃは、文脈ボード１４ｂを参照し、ツリー構造のルール１４ａで親ノードとして連なる各アノテーションルールに対する評価結果が全て「Ｔｒｕｅ」となった際に、ルール１４ａで指定された付加情報を表示する。その場合に、ルール解釈実行部１５ｃは、基本的にツリーの葉に相当するアノテーションルールである通常表示ルールで指定される付加情報を、Ｗｅｂページに表示する。ただし、機能構成上は、通常表示ルールがツリーの枝に位置していても動作は可能である。

なお、ルール解釈実行部１５ｃは、文脈ボード１４ｂと合致する業務シーンにおいて、ルール１４ａで指定された付加情報を表示する処理を、ＤＯＭ要素の状態が変化した際に直ちに行わなくてもよい。例えば、図６を参照して上記したように、時系列上で離れた時点の状態に応じてアノテーションを切り替えたり、２回目以降のアノテーション表示を非表示に切り替えたりすることもできる。

編集部１５ｄは、業務シーンを視覚化したＧＵＩを用いてルール１４ａの作成または編集を行う。ここで、図８〜図１２は、編集部１５ｄの処理を説明するための説明図である。編集部１５ｄは、図８に例示する編集画面を用いて、ユーザによるルール１４ａの作成または編集を受け付ける。図８に示すように、編集画面は、ルール選択パネル、条件設定パネル、ＤＯＭ要素選択パネル、プレビューパネル、およびコンテキスト指定パネル等を含む。

図８において、ユーザがキャプチャボタンを選択すると、編集部１５ｄは、Ｗｅｂページの内部のＤＯＭ構造をキャプチャし、ＤＯＭ要素選択パネルに表示する。

ＤＯＭ要素選択パネルは、各アノテーションルールに関連づけるＤＯＭ要素を指定するために用いられる。ＤＯＭ要素選択パネルでは、例えば、ＤＯＭ要素のｘ．ｙ．ｗ．ｈの矩形図形が表示され、背景に当該ページの画像イメージが表示され、視覚的にＷｅｂページ上の領域とＤＯＭ要素の対応を確認できる。

ユーザは、マウスを用いてＤＯＭ要素を選択することができる。このパネルは、ＩＥの開発者ツール画面と同様の形式でもよい。さらにユーザは、所定の操作を通じてアノテーションルールを作成することができる。このパネル上で作成された複数のアノテーションルールは、ルール選択パネルに追加表示される。

ルール選択パネルには、保存ファイルから編集画面にロードされたアノテーションルールの集合が表示される。このパネルには、リスト形式、テーブル形式あるいは、内部情報に基づいたツリー形式等で表示される。例えば、編集部１５ｄは、画面条件部の内容が同じであるアノテーションルールのグループや、ＧＵＩ条件部の内容が同じであるアノテーションルールのグループをまとめて、グループごとにサブツリー化して表示してもよい。

また、編集部１５ｄは、検索条件の指定を受け付けて、検索条件に適合するアノテーションルールをフィルタ表示してもよい。編集部１５ｄは、さらに優先基準の指定を受け付けて、指定された優先基準に基づく順序でソート表示してもよい。このパネル上で選択されたアノテーションルールは、ＤＯＭ要素選択パネルにおいて強調表示されるとともに、条件設定パネルおよびプレビューパネルに表示もしくは強調表示される。

条件設定パネルは、選択されたアノテーションルールの画面条件部、ＧＵＩ条件部、付加情報部等を編集するために用いられる。また、プレビューパネルには、アノテーションルールの付加情報部に基づいたアノテーション表示を視覚化したプレビュー画像が表示される。

なお、プレビューパネルは、ＤＯＭ要素選択パネルと融合して表示されてもよい。例えば、ＰｏｗｅｒＰｏｉｎｔ（登録商標）等の図形エディタを模して、色、大きさなどのプレゼンテーション設定を、マウスを用いて編集可能にしてもよい。また、対象のＤＯＭ要素からのアイコンや付箋等のアノテーションの相対位置を、マウスを用いた操作で移動可能にしてもよい。

コンテキスト指定パネルには、特殊なＧＵＩ条件の複合条件として構成されるコンテキスト（業務シーン）が表示される。コンテキスト情報は、ファイルを格納・配置するフォルダ階層のメタファにより表示される。例えば、複雑化を避けるようにフォルダを１階層に限定してもよいし、階層的なコンテキストをフォルダ階層としてもよい。

コンテキストとルールとの関連付けは、ファイルをフォルダに格納・配置する操作を模した編集操作で実現される。例えば、ルール選択パネルからノードをドラッグし、コンテキスト指定パネル上の所定のフォルダにドロップする操作により行う。あるいは、キーボードショートカット操作（所謂コピー・アンド・ペースト操作）と同様の操作により行えるようにしてもよい。

ここで、コンテキスト指定パネルでは、コンテキストの種類ごとにタブパネルに分けてもよいし、コンテキストのフォルダ表示を色分けしてもよい。また、コンテキスト指定パネルでは、Ｗｅｂページの外部の状態とルールとの関連付けも可能である。その場合に、編集部１５ｄは、外部の状態の種類に応じて、外部のどのような状態を監視するかを設定してもよい。具体的には、右クリックメニューからサブダイアログウィンドウを開いてその中で設定してもよいし、条件設定パネルにタブパネルを設け、それをユーザが切り替えてその中で設定してもよい。

また、編集部１５ｄは、図３に例示したアノテーションルールの組み合わせからなる複合条件を、１つのサブダイアログウィンドウで設定してもよいし、条件設定パネルに１つのタブパネルを設けて設定してもよい。

コンテキスト指定パネルに作成されたノードは、例えば、ショートカットの修飾が表現されたアイコンで表示される。あるいは、オリジナルとエイリアスとの関係を把握できるように、一方を選択した場合に他方がハイライト表示されるように表示してもよい。

また、オリジナルのノードを、コンテキスト付きを示す小さいフラグの絵等の修飾が表現されたアイコンで表示して、エイリアスが関連付いていることを把握できるようにしてもよい。また、１つのノードが複数のコンテキストに関連付けられる場合に、対応するコンテキストごとにフラグの色を変えたり、バルーンや右クリックにより、関連するコンテキストのリストを表示するようにしたりしてもよい。

このようにして、編集部１５ｄは、ユーザにわかりやすいように、コンテキスト指定パネルでは、ルール選択パネルとは異なる編集メタファでルール１４ａを編集可能としている。

また、編集部１５ｄは、インラインフレームを含むＧＵＩに対するルール１４ａの編集を行うこともできる。この場合に、各インラインフレームがＵＲＬの異なるＷｅｂページとして識別されている。これにより、編集部１５ｄは、ルール解釈実行部１５ｃがそのまま用いることが可能なルール１４ａを作成できる。

ここで、図９には、インラインフレームを含むＧＵＩが例示されている。図９に示す例では、インラインフレームごとに複数のＤＯＭ要素選択パネルに分けて表示される。各パネルにおいて網掛けされた領域は、当該パネルが表示するインラインフレーム以外の他のインラインフレームが背景画像として表示されており、ＤＯＭ要素選択はできないようになっている。複数のパネルは、タブパネルにより重ねた形式で編集ウィンドウ上に表示されてもよい。ユーザが網掛けされたインラインフレームの内部を選択すると、インラインフレーム構成ツリーがトラバースされ、当該タブパネルに切り替わってもよい。

この場合に、例えば、図１０に示したように、タブＡ内のフレーム１は、トップページのＵＲＬ「http://test.test/top.html」とは異なるＵＲＬ「http://test.test/child.html」を持つＷｅｂページとして識別されている。そのため、フレーム１がユーザに選択された場合に、トップページの構造に依存しない独立したＷｅｂページとして、タブＢに表示される。編集部１５ｄは、このようなＧＵＩの編集画面を用いることにより、トップページの構造に依存しないルール１４ａを作成することができる。

編集部１５ｄは、ルール１４ａの対象のＤＯＭ要素が選択された際に、図８に示した条件設定パネルに該ＤＯＭ要素のデフォルト値が表示されるＵＩを用いてもよい。例えば、編集部１５ｄは、図８に示した編集画面の各パネル上で、図１１（ａ）に例示したＵＩを用いる。図１１（ａ）は、アノテーションルールのＧＵＩ条件部を設定するためのＵＩパネルを例示している。

ユーザがルールの対象のＤＯＭ要素の状態を設定する場合に、編集部１５ｄは、図１１（ａ）に示すＵＩパネルを表示して、ユーザの入力を受け付ける。ここで、ユーザがＤＯＭ要素を選択すると、図１１（ａ）に例示するように、このＤＯＭ要素が持つ属性値のデフォルト値が表示される。

また、ＤＯＭ要素タグに応じて、所定の属性について有効／無効のデフォルト値が設定され、無効の属性の入力が受け付けられないようになっている。ユーザは、表示されているデフォルト値をそのまま用いることにより、容易にアノテーションルールのＧＵＩ条件部を設定できる。

なお、図１１（ａ）において、動的属性とは、ユーザ操作により変化する属性値を意味している。また、静的属性とは、動的属性以外の属性を意味している。このようなＵＩパネルのデフォルト値の設定は、図１１（ｂ）に例示した制御に従うＵＩ部品を用いることで実現される。図１１（ｂ）において、有効なＵＩ部品が○で表され、無効なＵＩ部品が×で表されている。

また、編集部１５ｄは、１つのＤＯＭ要素に対して属性値の異なる複数の条件を一括して設定できるＵＩを用いてもよい。例えば、編集部１５ｄは、図８に示した編集画面の各パネル上で、図１２に例示したＵＩを用いる。図１２（ａ）に示したＵＩパネルは、例えば、図１１（ａ）に示したＵＩパネルで「Ｔｅｘｔ」属性を持つ値を指定して「編集」ボタンを選択した場合に表示される。

図１２（ａ）のＧＵＩパネル上で「ＣＳＶファイル指定」を指定するラジオボタンを選択すると、図１２（ｂ）に示すように、属性値とアノテーションメッセージとの複数の組み合わせを一括して指定することができる。

図１２（ｂ）には、例えば「３０２ＥＲ」、「１０２ＥＲ」、「２０１ＥＲ」等の複数のエラーコードに対して、表示する複数のアノテーションメッセージを一括して指定する場合が例示されている。このように、例えば１００通りのエラーコードに対するアノテーションルールの設定を、１００個のアノテーションルールの定義に代えて、１つのアノテーションルールにおいて１００行のＣＳＶデータを用いることにより、高効率に行うことができる。

［表示制御処理］
次に、図１３は、表示制御処理手順を例示するフローチャートである。図１３は、ルール１４ａに基づいてアノテーションを表示する場合の処理手順を例示している。図１３のフローチャートは、例えば、文脈ボード１４ｂの変化があったタイミングで開始される。

まず、ルール解釈実行部１５ｃは、ルール１４ａを構成するアノテーションルールの画面条件部が、対象の文脈ボード１４ｂのＷｅｂページと合致するかの評価を行う（ステップＳ１）。評価の結果、合致しない場合（ステップＳ１，Ｆａｌｓｅ）には、ルール解釈実行部１５ｃは、ステップＳ４に処理を進める。

一方、評価の結果、合致する場合（ステップＳ１，Ｔｒｕｅ）には、ルール解釈実行部１５ｃは、アノテーションルールの参照ＩＤで特定される親ノードのアノテーションルールの文脈ＩＤを参照し、文脈ボード１４ｂにおける、この親ノードの文脈ＩＤの評価結果を確認する（ステップＳ２）。親ノードの文脈ＩＤの評価結果がＦａｌｓｅの場合には、ルール解釈実行部１５ｃは、ステップＳ４に処理を進める。

一方、親ノードの文脈ＩＤの評価結果がＴｒｕｅの場合には、ルール解釈実行部１５ｃは、アノテーションルールのＧＵＩ条件部と、文脈ＩＤのＤＯＭ要素の状態とを比較する評価を行う（ステップＳ３）。

ステップＳ４の処理では、ルール解釈実行部１５ｃは、文脈ＩＤのＤＯＭの状態の評価結果が、文脈ボード１４ｂの評価結果と異なるか否かを確認する。異ならない場合には（ステップＳ４、Ｎｏ）、ルール解釈実行部１５ｃは、一連の表示制御処理を終了させる。一方、異なる場合には（ステップＳ４，Ｙｅｓ）、ルール解釈実行部１５ｃは、文脈ボード１４ｂを更新する（ステップＳ５）。

また、ルール解釈実行部１５ｃは、ルール１４ａの他のアノテーションルールについて、ステップＳ１〜ステップＳ５の処理を実行する。そして、ルール解釈実行部１５ｃは、各アノテーションルールに対する評価結果が全て「Ｔｒｕｅ」となった際に、ルール１４ａで指定されたアノテーションに表示を更新する（ステップＳ６）。これにより、一連の表示制御処理が終了する。

また、図１４〜図１６は、表示制御処理手順を示すシーケンス図である。図１４〜図１６には、文脈ボード１４ｂの監視に関する処理手順が例示されている。まず、図１４には、文脈ボード１４ｂの初期化および終了の処理手順が例示されている。図１４（ａ）に示すように、制御部１５は、常時、Ｗｅｂブラウザとの間でポーリング監視を行っている（ステップＳ１０）。

そして、制御部１５が、新規のＷｅｂページを検知した場合に（ステップＳ１１）、当該Ｗｅｂページのルール１４ａおよびルール解釈実行部１５ｃを送付する（ステップＳ１２、Ｓ１４）。また、制御部１５は、対応する文脈ボード１４ｂを生成・初期化して、文脈ＩＤを割り当てる（ステップＳ１３、Ｓ１５）。その際に、制御部１５は、対応する文脈ボード１４ｂと対応するＷｅｂページのルール解釈実行部１５ｃとを関連付ける。

また、制御部１５は、Ｗｅｂページの消滅を検知した場合には（ステップＳ１６）、対応する文脈ボード１４ｂに対する後処理を行って解放する（ステップＳ１７）。

また、制御部１５は、図１４（ｂ）に示すように、図７に示したグローバルコンテキストに分類される文脈ボードについては、起動時に生成・初期化して、文脈ＩＤを割り当てる（ステップＳ１８）。初期化の際には、制御部１５は、永続化ファイルがあれば読み込む。

また、制御部１５は、終了にともなって、文脈ボードに対する後処理を行って解放する（ステップＳ１９）。後処理の際に、制御部１５は、永続化ファイルがある文脈ボードについては、永続化ファイルに履歴の書き込みを行う。

次に、図１５および図１６には、文脈ボード１４ｂの更新に関する処理手順が例示されている。まず、図１５に示すように、ルール解釈実行部１５ｃは、ＷｅｂページのＤＯＭ構造の変化イベントを監視して、文脈ボード１４ｂを購読することにより、ＤＯＭ要素の状態を監視している（ステップＳ２０）。ルール解釈実行部１５ｃは、ＤＯＭ要素の状態の変化を検出した場合、ＤＯＭ要素の状態を、該当のアノテーションルールで特定されている状態と比較する評価を行う（ステップＳ２１）。

また、ルール解釈実行部１５ｃは、必要な場合には、文脈ボード１４ｂの該当の文脈ＩＤで指定されるオブジェクトの評価結果である「Ｔｒｕｅ」または「Ｆａｌｓｅ」の設定値を変更する更新を行う（ステップＳ２２）。ルール解釈実行部１５ｃは、文脈ボードの更新を行った場合には、更新の通知を行って、文脈ボード１４ｂの最新の状態を読み出す（ステップＳ２３）。

そして、ルール解釈実行部１５ｃは、文脈ボード１４ｂの更新の通知を受信した場合には、図１３に示した表示制御処理を実行し、アノテーション表示を更新する（ステップＳ２４）。

なお、図１６には、図６に一点鎖線で示したように、ルール解釈実行部１５ｃが他の文脈ボード１４ｂを参照する場合が例示されている。図１６の処理は、図１５の処理とは、ステップＳ２５の処理が追加されている点が異なる。その他の点については、図１５の処理と同様であるので、説明を省略する。

ステップＳ２５の処理では、文脈ボードの更新を行った場合には、ルール解釈実行部１５ｃが、監視対象の文脈ＩＤのオブジェクトに対応する他の文脈ボードと関連付けられている他のＷｅｂページのルール解釈実行部１５ｃに、更新を通知する。

更新を通知された他のＷｅｂページのルール解釈実行部１５ｃは、上記と同様に、自身に関連付けされている文脈ボード１４ｂの最新の状態を読み出して、図１３に示した表示制御処理を実行し、アノテーション表示を更新する（ステップＳ２４）。

なお、ルール解釈実行部１５ｃが文脈ＩＤを用いて文脈ボード１４ｂを参照する際に、関連付けられている文脈ボード１４ｂを最優先として、所定の優先度で探索を行って、存在する文脈ボード１４ｂ内の文脈ＩＤを採用すればよい。例えば、まず生成順序の早いグローバルコンテキストから探索を行えばよい。次に、生成時刻の新しいローカルコンテキストから探索を行えばよい。

以上、説明したように、本実施形態の表示制御装置１０では、記憶部１４が、所定のＷｅｂページのＤＯＭ要素の有無または属性値で表される該ＤＯＭ要素の状態の組み合わせで特定される業務シーンごとに、表示する付加情報を指定するルール１４ａを記憶する。また、監視部として、ルール解釈実行部１５ｃが、ＷｅｂページのＤＯＭ要素の状態を監視して、該状態を文脈ボード１４ｂとして記憶部１４に記憶させる。また、表示制御部として、ルール解釈実行部１５ｃが、記憶部１４に記憶された文脈ボード１４ｂの状態と合致する業務シーンの状態において、ルール１４ａで指定された付加情報を表示する。

これにより、表示制御装置１０では、アノテーションの適用対象のＤＯＭ要素の変化に応じて、Ｗｅｂページのリロードがなくてもアノテーションが動的に更新され適切に表示される。また、実用的な業務シーンをカバーする複雑な複合条件を、高い自由度で定義できる。例えば、スケジューリング、業務メニュー、画面状態、非表示指定等を組み合わせて複雑な複合条件を定義できる。また、特に、ウィンドウやタブパネル（Ｗｅｂコンンテント）やインラインフレームが複数存在する場合にも、画面またがりの複合条件を高い自由度で定義できる。

このように、表示制御装置１０では、ＤＯＭ要素の状態を特定するアノテーションルールの単純な関係を組み合わせて詳細な業務シーンを特定できる。ここで、単純な関係とは、例えば、論理式（ＡＮＤ／ＯＲ）や制約条件（Ｎ項間制約）からなる関係、複数画面にまたがった状態集合からなる関係、時間系列の離れた時点の状態集合からなる関係、Ｗｅｂページの外部から取得される状態を含む関係を含む。

また、イベントのフック設定、ハンドラ呼び出し等が共通機能として統一して実装されるため、アノテーション表示の更新の漏れ、遅れ等が発生しない。例えば、対象Ｗｅｂ画面のフレーム構成や読込タイミングに依存した例外処理がユーザ操作によらず自動的に行われる。また、外部システム等のＷｅｂページの外部の状態を文脈ボードのサブクラス分類により追加できるため、アノテーション表示の更新の漏れ、遅れ等が発生しない。例えば、状態更新の影響により文脈ボードを参照しルール１４ａを再評価する処理がユーザ操作によらず自動的に行われる。

このように、表示制御装置１０は、アノテーション表示を行う業務シーンの定義を容易に行い、業務シーンの変化に応じて適切にアノテーション表示を更新することができる。

また、編集部１５ｄが、業務シーンを視覚化したＧＵＩを用いてルール１４ａの作成または編集を行う。例えば、セレクタ指定で利用可能な属性値の編集を行うＧＵＩを提示するため、ユーザが容易にルール１４ａの設定を行える。

特に、編集ＧＵＩをユーザが選択したＤＯＭ要素タグに応じてデフォルト値で初期化するため、ユーザが容易にルール１４ａを設定できる。例えば、ユーザが検索フォーム要素を選択すると、タグが「ＩＮＰＵＴ」、value属性が「×××」等となり、ユーザはそのデフォルト値をそのまま用いてルール１４ａを設定できる。このように、プログラミングスキルを持たない一般ユーザでも、容易に実用的な業務シーンを定義してアノテーション表示を指定することができる。

［実施例］
次に、図１７〜図２６は、表示制御装置１０による表示制御処理の実施例を説明するための説明図である。まず、図１７には、ある業務画面としてＷｅｂページのパネル上のｔａｂｌｅ要素に「解約申込」等の所定のラベルが存在する場合に、アノテーションを表示する場合が例示されている。図１７には、ある業務案件が１つ以上のサブ案件で構成されている場合の業務画面が例示されている。図１７（ａ）には、画面ウィンドウ内のスクロール機能によりユーザに見える領域に３つのサブ案件が表示されている。

オペレータは、この業務画面を用いて、サブ案件のそれぞれの表示を確認し、必要に応じてデータを入力する。そして、図１７（ｂ）に例示する、スクロールの最下段において、コミットを意味する「ＯＫ」ボタンを押下することにより、１つの業務案件の作業が完了する。また、複数種類のサブ案件のうち、例えば、「解約申込」等の慎重な入力を要するサブ案件の入力については、入力データが正しいかを確認するために、他のシステムの別の観点からの業務情報の参照が必要となる場合がある。そこで、図１７（ｃ）に例示するように、他のシステムを参照できる「サービス監視画面を開く」ボタンが左側パネルに提供されている。

ここで、オペレータの習熟度が低く、サブ案件に「解約申込」が含まれていても入力データの確認が不十分なままコミットしてしまうと、業務上の多大な損失が生じるリスクがある。そこで、表示制御装置１０は、図１７（ｄ）に例示するように、サブ案件「解約申込」の入力欄（コンボボックス）の近傍に、コンボボックスの選択状態に応じて、アノテーションを強制的に表示することができる。

また、習熟したオペレータであっても、長いスクロールで多数のサブ案件の作業を行っている間に忘れてしまうリスクもある。そこで、表示制御装置１０は、図１７（ｅ）に例示するように、コンボボックスの選択状態が「解約申込」である箇所が業務画面上に１つ以上存在する場合に、まとめて注意喚起することもできる。図１７（ｅ）には、コミットする際の「ＯＫ」ボタンの近傍に「上位サービス終了日を別途確認してください」とのアノテーションが表示されている。同時に、離れた位置にある「外部システム」ボタンの近傍に、関連する内容の「要注意：上位サービス終了日」とのアノテーションが表示されている。

このように、表示制御装置１０は、利用方法を前提として、強制的にアノテーションを表示することができる。また、表示制御装置１０によるアノテーションの表示の条件や振る舞いは、局所的あるいは個別的ではない。すなわち、表示制御装置１０は、画面上の複数個所、あるいはスクロールで離れた箇所の状態に応じて、大域的かつ複合的に、画面上の複数個所や離れた箇所にアノテーションを表示することができる。つまり、表示制御装置１０は、業務画面の構成や業務作業上の個々の問題等に応じて自由にアノテーションの表示ルールを定義して、高度にアノテーション表示の振る舞いを制御できる。

表示制御装置１０によれば、何も選択されていない初期画面のコンボボックスに対して、オペレータが「解約申込」を選択した場合に、その場ですぐにアノテーションが表示される。また、その後、他の「新規サービスＡ」等に選択を変えた場合には、その場ですぐにアノテーションが消える。また、業務画面のスクロールの最下段のアノテーションは、業務画面上の全ての「解約申込」が存在しなくなった場合にのみ消える。また、「外部システムを開く」ボタンも「解約申込」の有無に連動して消える。このように、表示制御装置１０は、オペレータが選択操作を行った時点で、対象システム画面の状態に応じてアノテーション表示が動的に制御される。

さらに、オペレータがオーダ記録から、過去に投入した申込内容を検索してこの業務画面で閲覧する、という業務シーンでは、当初から「解約申込」が含まれることが想定される。したがって、この業務シーンでは、表示制御装置１０は、オペレータのコンボボックス操作を待たずに、当初から漏れなく必要なアノテーションを表示させることができる。

このように、表示制御装置１０では、ルール１４ａの定義を、ＤＯＭ要素の属性値に応じて自由に記述して、ＧＵＩを用いて編集できる。これにより、特定の操作を契機にするのではなく、多様で多岐にわたるトリガを漏れなく考慮することができる。このように表示制御装置１０によれば、リアルタイム領域においても、対象画面の状態に応じて動的に、アノテーション表示の更新を制御して、オペレータが意識しなくても強制的にアノテーションを表示できる。

また、図１８には、図１７に例示した場合におけるルール１４ａの定義例が例示されている。図１８に示すように、画面状態ルールＢ０の子ノードに当たる通常表示ルールＣ０では、ＧＵＩ条件部に『セレクト要素＆属性「解約申込」』、また付加情報部に『アノテーション「要確認：上位サービス終了日」を表示』が設定されている。

通常表示ルールＣ０には、通常表示ルールＣ１および通常表示ルールＣ２の２つの子ノードが設定され、２つに条件分岐している。通常表示ルールＣ１では、ＧＵＩ条件部に『ボタン要素＆属性「ＯＫ」』、また付加情報部に『アノテーション「上位サービス終了日を別途確認してください」を表示』が設定されている。また、通常表示ルールＣ２では、ＧＵＩ条件部に『ボタン要素＆属性「サービス監視画面を開く」』、また付加情報部に『アノテーション「要確認：上位サービス終了日」を表示』が設定されている。

また、図１８に示すルール１４ａには、外部状態ルールＡ０が追加されている。この外部状態ルールＡ０では、文脈ボード（スケジュール）を参照するための文脈ＩＤが設定されている。これにより、アノテーション表示が例えば「７月１日〜７月３１日」に表示され、それ以外の期間には表示されないようにすることができる。すなわち、外部状態としてＰＣのカレンダー情報を監視する文脈ボード（スケジュール）のサブツリー配下に、上記のオブジェクト群を配置することにより、実現している。

同様に、ルール追加を組み合わせることにより、より複雑な表示制御を定義することができる。例えば、以上の表示制御を、さらにユーザの選択によりＯｎ／Ｏｆｆ切替をしたい場合には、後述する図２１の実施例において「初心者ユーザ用アノテーションを表示する」メニューを配置し、「文脈ボード（業務コンテキスト切替）」を参照するアノテーションルールを追加すればよい。このように、多種多様な制御を組み合わせ、全体として複雑な制御を構成できる。

図１９には、必須項目であるテキストフィールドへの入力が未入力の場合に、必須データである旨のアノテーションメッセージを表示する場合が例示されている。図１９には、２種類以上の業務案件が多数の入力項目で構成され、コンボボックスでどの種類の業務についての処理かを指定する場合が例示されている。業務システムは、開発上の都合で、全ての入力項目が常に編集可能になっているが、業務案件の種類に応じて、入力が必須の項目や編集禁止の項目が運用で細かく指定されている。オペレータは、本来、それらを全て把握して作業を行わなければならない。

通常、業務案件を起票する際には、全ての入力項目は空白である。オペレータは、適切かつ効率よくデータを入力するために、入力が必須である項目を迅速かつ的確に知りたい。表示制御装置１０は、ＧＵＩ要素の状態に応じて、自動的にアノテーションを切り替えるので、コンボボックスを変更した時点で、リアルタイムに必須である旨のアノテーション表示を切り替えることができる。

例えば、図１９（ａ）に示す例では、「サービスＡ」での必須項目と「サービスＢ」での必須項目の集合が異なっている。表示制御装置１０によれば、「サービスＡ」または「サービスＢ」を選択した時点で、あるいは選択を変更した時点で、必須項目の集合パターンが自動的に切り替わる。なお、集合パターンは２つに限定されず、３つ以上にも適用できる。例えば、３つ以上のサービスについても、同様に、必須項目の集合パターンを切り替えることができる。

また、図１９（ｂ）には、過去に入力されたデータをオペレータが変更する場合において、安易に変更されたくない項目を、強制的に「さわるな」とのアノテーションで覆う場合が例示されている。この場合には、オペレータがアノテーションの表示／非表示を操作できないように、ルール１４ａで指定できる。また、アノテーションの背後に存在する入力欄は、マウスのクリックイベントが遮られて編集状態にはならない。

このように、表示制御装置１０によれば、オペレータには、値が見えないだけでなく、変更することもできないようにできる。オペレータが業務上のリスクに自覚がない場合にも、アノテーションが強制的に表示されることにより、リスクを回避することができる。

また、表示制御装置１０は、図１９（ｃ）に示すように、ユーザとの対話性を提供することも可能である。図１９（ｃ）には、入力済みになった項目のアノテーション表示が消える場合が例示されている。図１９（ｃ）では、入力項目１および入力項目２について、入力が済んでいるため「必須」のアノテーションが消えている。これにより、未入力でオペレータの注意喚起が必要な項目への注意が散漫になるのを防止できる。表示制御装置１０では、ＤＯＭ要素のｖａｌｕｅ属性値が空きもしくは“”の場合をルール１４ａで指定することにより、これを実現する。

また、図２０には、図１９に例示した場合におけるルール１４ａの定義例が例示されている。図２０に示すように、画面状態ルールＡ１には、画面状態ルールＤ０および画面状態ルールＥ０の２つの子ノードが設定され、２つに条件分岐している。画面状態ルールＤ０では、ＧＵＩ条件部に『セレクト要素＆属性「サービスＡ」』が設定されている。また画面状態ルールＥ０では、ＧＵＩ条件部に『セレクト要素＆属性「サービスＢ」』が設定されている。

画面状態ルールＤ０には、通常表示ルールＤ１、通常表示ルールＤ２、通常表示ルールＤ３および通常表示ルールＤ４の４つの子ノードが設定され、４つに条件分岐している。通常表示ルールＤ１では、ＧＵＩ条件部に『テキスト要素「入力項目１」＆属性「」（空文字）』、また付加情報部に『アノテーション「必須」を表示』が設定されている。

また、通常表示ルールＤ２では、ＧＵＩ条件部に『テキスト要素「入力項目２」＆属性「」（空文字）』、また付加情報部に『アノテーション「必須」を表示』が設定されている。また、通常表示ルールＤ３では、ＧＵＩ条件部に『テキスト要素「入力項目４」＆属性「」（空文字）』、また付加情報部に『アノテーション「必須」を表示』が設定されている。また、通常表示ルールＤ４では、ＧＵＩ条件部に『テキスト要素「入力項目Ｚ」＆属性「」（空文字）』、また付加情報部に『アノテーション「必須」を表示』が設定されている。

画面状態ルールＥ０には、通常表示ルールＥ１、通常表示ルールＥ２、通常表示ルールＥ３および通常表示ルールＥ４の４つの子ノードが設定され、４つに条件分岐している。通常表示ルールＥ１では、ＧＵＩ条件部に『テキスト要素「入力項目１」＆属性「」（空文字）』、また付加情報部に『アノテーション「必須」を表示』が設定されている。

また、通常表示ルールＥ２では、ＧＵＩ条件部に『テキスト要素「入力項目３」＆属性「」（空文字）』、また付加情報部に『アノテーション「必須」を表示』が設定されている。また、通常表示ルールＥ３では、ＧＵＩ条件部に『テキスト要素「入力項目４」＆属性「」（空文字）』、また付加情報部に『アノテーション「必須」を表示』が設定されている。また、通常表示ルールＥ４では、ＧＵＩ条件部に『テキスト要素「入力項目Ｙ」＆属性「」（空文字）』、また付加情報部に『アノテーション「必須」を表示』が設定されている。

図２１には、ユーザに明示的に業務を選択させてアノテーションを切り替える場合が例示されている。例えば、図２１（ａ）に示すように、表示制御装置１０は、ユーザが「新規」「変更」「削除」等の業務の中から選択する入力を行った場合に、それぞれの業務に応じたアノテーションを表示する。

この場合には、図２１（ｂ）に示すように、制御部１５は、ＧＵＩを用いてユーザによる業務の選択を受け付けて、ユーザによる業務の選択の状態を業務シーンに含めたルール１４ａを作成する。また、ルール解釈実行部１５ｃは、ユーザによる業務の選択の状態を表すオブジェクトを文脈ボード（業務コンテキスト切替）に生成し、所定の業務を条件として指定するアノテーションルールに対する評価結果を設定する。これにより、表示制御装置１０は、ユーザに明示的に業務を選択させてアノテーションを切り替えることが可能となる。

図２２には、アノテーションの表示実績を集計する場合が例示されている。表示制御装置１０は、図２２（ｂ）に例示するように、アイコンや付箋紙の表示状態を検知した場合に、ルール解釈実行部１５ｃは、アイコンや付箋紙の表示状態を表すオブジェクトを文脈ボード（利用実績集計）に生成し、表示／非表示を設定する。表示制御装置１０は、例えば、既読機能や、「ふせんがピン留めされた」、「ふせんが開かれた」等の閲覧操作により明示的に、あるいはふせん表示により暗黙的に、表示状態を検知して集計する。

この場合には、制御部１５は、図２２（ａ）に例示するように、文脈ボード（利用実績集計）を利用して、例えば時刻や付箋内容等をＣＳＶファイルに出力する。集計された利用実績情報は、管理者が、アノテーションコンテンツの効果の定量化や、画面レイアウト変更に対するアンケート等の業務フロー・プロセス改善施策の定量化等に利用できる。

図２３には、時系列上で離れた時点の状態に応じてアノテーションを切り替える場合が例示されている。表示制御装置１０は、例えば、図２３（ａ）に示すように、決定ボタンをチェックボックスつきのアノテーションで隠して、ユーザがチェックを入力した後に決定ボタンの押下を可能とする。

この場合には、制御部１５は、図２３（ｂ）に例示するように、チェックボックスつきのアノテーションを仮想チェックシートとして用いて、複数の項目の入力等、時系列上で離れた時点の状態を確認済みの旨のユーザの入力を受け付ける。また、制御部１５は、仮想チェックシートのチェック項目のチェック状態を業務シーンに含めたルール１４ａを作成する。

そして、ルール解釈実行部１５ｃは、仮想チェックシートのチェック項目のチェック状態を表すオブジェクトを文脈ボード（仮想チェック）に生成し、仮想チェックシートの所定のチェック状態を条件として指定するアノテーションルールに対する評価結果を設定する。これにより、表示制御装置１０は、時系列上で離れた時点の状態に応じてアノテーションを切り替えることが可能となる。

図２４には、スケジュール登録された時間帯にアノテーションを表示する場合が例示されている。表示制御装置１０は、例えば、図２４（ａ）に示すように、月末業務等の定期業務の支援のため、特定日時にアノテーションを表示することができる。例えば、ユーザが離席中であっても、スケジューリングされた時刻に強制的かつ自動的にアノテーションを表示することができる。

この場合には、制御部１５は、図２４（ｂ）に例示するように、ＰＣの時刻が所定の時刻になったことを業務シーンに含めたルール１４ａを作成する。また、ルール解釈実行部１５ｃは、ＰＣ内部の時刻を表すオブジェクトを生成し、所定の時刻を条件として指定するアノテーションルールに対する評価結果を設定する。これにより、表示制御装置１０は、スケジュール登録された時間帯にアノテーションを表示することが可能となる。

図２５には、ユーザに対して２回目以降のアノテーション表示を非表示に切り替える場合が例示されている。表示制御装置１０は、図２５（ａ）に例示するように、ユーザが以後は表示しない」ことを指定するチェックボックスつきのアノテーションを用いて、このユーザに対して２回目以降のアノテーション表示を非表示に切り替えることができる。

この場合に、制御部１５は、「以後は表示しない」ことを指定するチェックボックスつきのアノテーションを用いて、２回目以降のアノテーションを非表示にするユーザの指示入力を受け付ける。また、制御部１５は、このアノテーションのチェックボックスがチェック済みであることを業務シーンに含めたルール１４ａを作成する。

また、図２５（ｂ）に例示するように、ルール解釈実行部１５ｃは、このアノテーションのチェック状態を表すオブジェクトを文脈ボード（非表示チェック）に生成し、チェック済みを条件として指定するアノテーションルールに対する評価結果を設定する。これにより、表示制御装置１０は、ユーザに対する２回目以降のアノテーション表示を、永続的に非表示に切り替えることが可能となる。

図２６は、あるウィンドウに「サーバ負荷逼迫中」のラベルが存在する場合におけるアノテーション表示を例示している。この場合は、システム運用状況をモニタするウィンドウと、別の検索ウィンドウで作業する、という業務シーンに相当する。

この場合に、表示制御装置１０によれば、検索ウィンドウの検索ボタンの横に「使用を控えて下さい」というアノテーションを表示することができる。このように、表示制御装置１０は、システムの運用状況を判定する参照元のウィンドウと判定結果を参照する検索ウィンドウというように、参照元と参照先が異なるウィンドウの間でコンテキストを共有できる。

［プログラム］
上記実施形態に係る表示制御装置１０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。一実施形態として、表示制御装置１０は、パッケージソフトウェアやオンラインソフトウェアとして上記の表示制御処理を実行する表示制御プログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、上記の表示制御プログラムを情報処理装置に実行させることにより、情報処理装置を表示制御装置１０として機能させることができる。ここで言う情報処理装置には、デスクトップ型またはノート型のパーソナルコンピュータが含まれる。また、その他にも、情報処理装置にはスマートフォン、携帯電話機やＰＨＳ（Personal Handyphone System）等の移動体通信端末、さらには、ＰＤＡ（Personal Digital Assistants）等のスレート端末等がその範疇に含まれる。

また、表示制御装置１０は、ユーザが使用する端末装置をクライアントとし、当該クライアントに上記の表示制御処理に関するサービスを提供するサーバ装置として実装することもできる。例えば、表示制御装置１０は、Ｗｅｂページを入力とし、付加情報の表示を出力する表示制御処理サービスを提供するサーバ装置として実装される。この場合、表示制御装置１０は、Ｗｅｂサーバとして実装することとしてもよいし、アウトソーシングによって上記の表示制御処理に関するサービスを提供するクラウドとして実装することとしてもかまわない。以下に、表示制御装置１０と同様の機能を実現する表示制御プログラムを実行するコンピュータの一例を説明する。

図２７は、表示制御プログラムを実行するコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１およびＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１０４１に接続される。ディスクドライブ１０４１には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１０５１およびキーボード１０５２が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１０６１が接続される。

ここで、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。上記実施形態で説明した各情報は、例えばハードディスクドライブ１０３１やメモリ１０１０に記憶される。

また、表示制御プログラムは、例えば、コンピュータ１０００によって実行される指令が記述されたプログラムモジュール１０９３として、ハードディスクドライブ１０３１に記憶される。具体的には、上記実施形態で説明した表示制御装置１０が実行する各処理が記述されたプログラムモジュール１０９３が、ハードディスクドライブ１０３１に記憶される。

また、表示制御プログラムによる情報処理に用いられるデータは、プログラムデータ１０９４として、例えば、ハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。

なお、表示制御プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１０４１等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、表示制御プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

以上、本発明者によってなされた発明を適用した実施形態について説明したが、本実施形態による本発明の開示の一部をなす記述および図面により本発明は限定されることはない。すなわち、本実施形態に基づいて当業者等によりなされる他の実施形態、実施例および運用技術等は全て本発明の範疇に含まれる。

１０ 表示制御装置
１１ 入力部
１２ 出力部
１３ 通信制御部
１４ 記憶部
１４ａ ルール
１４ｂ 文脈ボード
１５ 制御部
１５ａ ターゲット取得部
１５ｂ コネクション部
１５ｃ ルール解釈実行部
１５ｄ 編集部

Claims (8)

1. 所定のＷｅｂページのＤＯＭ要素の有無または属性値で表される該ＤＯＭ要素の状態の組み合わせで特定される業務シーンであって、さらに前記Ｗｅｂページの外部の状態を含んだ業務シーンごとに、表示する付加情報を指定するルールを記憶する記憶部と、
   ＷｅｂページのＤＯＭ要素の状態を監視して、該状態を文脈ボードとして前記記憶部に記憶させる監視部と、
   前記記憶部に記憶された文脈ボードの状態と合致する前記業務シーンの状態において、前記ルールで指定された前記付加情報を表示する表示制御部と、
   を備え、
   前記ルールは、それぞれルールの対象となるＷｅｂページを特定する条件を表す画面条件部を少なくとも含む複数のアノテーションルールをノードとするツリー構造を有し、
   前記文脈ボードは、前記ＷｅｂページのＤＯＭ要素の状態を監視するためのローカルコンテキストと前記Ｗｅｂページの外部の情報の監視するためのグローバルコンテキストからなり、
   前記グローバルコンテキストは、自身が保持する情報を書き込んだ永続ファイルを生成する永続ファイルあり文脈ボード、および永続ファイルを生成しない永続ファイルなし文脈ボードの少なくとも一つを含み、
   前記監視部は、前記Ｗｅｂページの外部の状態をさらに監視して、該状態を前記グローバルコンテキストに含まれる文脈ボードとして前記記憶部に記憶させることを特徴とする表示制御装置。
2. 前記表示制御部は、前記監視部が監視する前記ＤＯＭ要素の状態が変化した際に、前記文脈ボードの状態と合致する前記業務シーンの状態において、前記ルールで指定された前記付加情報を表示することを特徴とする請求項１に記載の表示制御装置。
3. 前記永続ファイルあり文脈ボードは、ユーザに業務を選択させて前記付加情報を切り替える場合に用いられる業務コンテキスト切替文脈ボード、前記付加情報の表示実績を集計する場合に用いられる利用実績集計文脈ボード、および２回目以降の前記付加情報の表示を非表示に切り替える場合に用いられる非表示チェック文脈ボードの少なくとも一つを含み、
   前記永続ファイルなし文脈ボードは、時系列上で離れた時点の状態に応じて前記付加情報を切り替える場合に用いられる仮想チェック文脈ボード、およびスケジュール登録された時間帯に前記付加情報を表示する場合に用いられるスケジュール文脈ボードの少なくとも一つを含むことを特徴とする請求項１に記載の表示制御装置。
4. 前記業務シーンを視覚化したＧＵＩを用いて前記ルールの作成または編集を行う編集部を、さらに備えることを特徴とする請求項１に記載の表示制御装置。
5. 前記編集部は、インラインフレームを含み、各インラインフレームがＵＲＬの異なるＷｅｂページとして識別される前記ＧＵＩを用いることを特徴とする請求項４に記載の表示制御装置。
6. 前記編集部は、前記ルールの対象のＤＯＭ要素が選択された際に、該ＤＯＭ要素のデフォルト値が表示される前記ＧＵＩを用いることを特徴とする請求項４に記載の表示制御装置。
7. 所定のＷｅｂページのＤＯＭ要素の有無または属性値で表される該ＤＯＭ要素の状態の組み合わせで特定される業務シーンであって、さらに前記Ｗｅｂページの外部の状態を含んだ業務シーンごとに、表示する付加情報を指定するルールを記憶する記憶部を備えた表示制御装置において実行される表示制御方法であって、
   ＷｅｂページのＤＯＭ要素の状態を監視して、該状態を文脈ボードとして前記記憶部に記憶させる監視工程と、
   前記記憶部に記憶された文脈ボードの状態と合致する前記業務シーンの状態において、前記ルールで指定された前記付加情報を表示する表示制御工程と、
   を含み、
   前記ルールは、それぞれルールの対象となるＷｅｂページを特定する条件を表す画面条件部を少なくとも含む複数のアノテーションルールをノードとするツリー構造を有し、
   前記文脈ボードは、前記ＷｅｂページのＤＯＭ要素の状態を監視するためのローカルコンテキストと前記Ｗｅｂページの外部の情報の監視するためのグローバルコンテキストからなり、
   前記グローバルコンテキストは、自身が保持する情報を書き込んだ永続ファイルを生成する永続ファイルあり文脈ボード、および永続ファイルを生成しない永続ファイルなし文脈ボードの少なくとも一つを含み、
   前記監視工程では、前記Ｗｅｂページの外部の状態をさらに監視して、該状態を前記グローバルコンテキストに含まれる文脈ボードとして前記記憶部に記憶させることを特徴とする表示制御方法。
8. 所定のＷｅｂページのＤＯＭ要素の有無または属性値で表される該ＤＯＭ要素の状態の組み合わせで特定される業務シーンであって、さらに前記Ｗｅｂページの外部の状態を含んだ業務シーンごとに、表示する付加情報を指定するルールを記憶する記憶部を参照し、
   ＷｅｂページのＤＯＭ要素の状態を監視して、該状態を文脈ボードとして前記記憶部に記憶させる監視ステップと、
   前記記憶部に記憶された文脈ボードの状態と合致する前記業務シーンの状態において、前記ルールで指定された前記付加情報を表示する表示制御ステップと、
   をコンピュータに実行させ、
   前記ルールは、それぞれルールの対象となるＷｅｂページを特定する条件を表す画面条件部を少なくとも含む複数のアノテーションルールをノードとするツリー構造を有し、
   前記文脈ボードは、前記ＷｅｂページのＤＯＭ要素の状態を監視するためのローカルコンテキストと前記Ｗｅｂページの外部の情報の監視するためのグローバルコンテキストからなり、
   前記グローバルコンテキストは、自身が保持する情報を書き込んだ永続ファイルを生成する永続ファイルあり文脈ボード、および永続ファイルを生成しない永続ファイルなし文脈ボードの少なくとも一つを含み、
   前記監視ステップでは、前記Ｗｅｂページの外部の状態をさらに監視して、該状態を前記グローバルコンテキストに含まれる文脈ボードとして前記記憶部に記憶させることを特徴とする表示制御プログラム。

Images