WO2022113315A1 - ユーザインタフェース拡張システム、ユーザインタフェース拡張方法及びユーザインタフェース拡張プログラム - Google Patents

Abstract

ユーザインタフェース拡張システム（１）は、基点探索部（１６２）と、表示制御部（１６３）とを備える。基点探索部（１６２）は、システムの画面に追加される追加のユーザインタフェース（ＵＩ）の表示の基点となる基点ＵＩを、このシステムの画面から探索する。表示制御部（１６３）は、背景が透明な新たな画面を、システムの画面と重ねて表示し、この新たな画面において、基点ＵＩに基づく位置に追加のＵＩを表示する。

Description

ユーザインタフェース拡張システム、ユーザインタフェース拡張方法及びユーザインタフェース拡張プログラム

　本開示は、ユーザインタフェース拡張システム、ユーザインタフェース拡張方法及びユーザインタフェース拡張プログラムに関する。

　従来、ユーザインタフェース（ＵＩ）拡張技術が提案されている。ＵＩ拡張技術は、既存システムの画面上に、追加のＵＩを表示し、システム操作を改善するものである。

　従来のＵＩ拡張は、Ｗｅｂシステムを対象としている。例えば、従来のＵＩ拡張は、ＷｅｂシステムのＨＴＴＰ（Hypertext　Transfer　Protocol）レスポンスまたはＷｅｂブラウザに描画されたＤＯＭ（Document　Object　Model）に対して、プロキシサーバ、ブラウザのアドオンまたはプロセス間通信等の手法を用いる。これにより、従来のＵＩ拡張は、Ｗｅｂシステムに、ＨＴＭＬ（Hyper　Text　Markup　Language）やJavaScript（登録商標）を挿入し、それによって、追加のＵＩの表示を可能にしている。

特開２０１８－５３４４号公報

　しかしながら、従来のＵＩ拡張では、ユーザインタフェース拡張を広範なシステムに適用することが難しい。例えば、アーキテクチャの制約により、従来のＵＩ拡張は、Ｗｅｂシステムの画面以外の画面に適用できない場合がある。

　本願は、上記に鑑みてなされたものであって、ユーザインタフェース拡張を広範なシステムに適用することを目的とする。

　本開示の実施形態に係るユーザインタフェース拡張システムは、システムの画面に追加される追加のユーザインタフェース（ＵＩ）の表示の基点となる基点ＵＩを、当該システムの画面から探索する基点探索部と、背景が透明な新たな画面を、前記システムの画面と重ねて表示し、当該新たな画面において、前記基点ＵＩに基づく位置に前記追加のＵＩを表示する表示制御部とを備える。

　実施形態の一態様によれば、ユーザインタフェース拡張を広範なシステムに適用することができる。

図１は、従来のＵＩ拡張の一例を示す説明図である。 図２は、実装例に係るＵＩ拡張の一例を示す説明図である。 図３Ａは、追加のＵＩの表示制御の一例を示す説明図である。 図３Ｂは、追加のＵＩの表示制御の一例を示す説明図である。 図３Ｃは、追加のＵＩの表示制御の一例を示す説明図である。 図４は、実施形態に係るユーザインタフェース拡張システムの一例を示す図である。 図５は、実施形態に係るルール記憶部の一例を示す図である。 図６は、追加のＵＩの表示の基点となる基点ＵＩを探索する基点探索処理の一例を示す説明図である。 図７は、追加のＵＩの表示を制御する表示制御処理の一例を示す説明図である。 図８は、既存のＵＩと追加のＵＩとの間でデータを流通するデータ流通処理の一例を示す説明図である。 図９Ａは、追加のＵＩを再表示するタイミングを発生させるタイミング発生処理一例を示す説明図である。 図９Ｂは、追加のＵＩを再表示するタイミングを発生させるタイミング発生処理一例を示す説明図である。 図１０は、実施形態に係る端末装置によって実行される、既存システムの画面のＵＩを拡張するための処理の一例を示すフローチャートである。 図１１は、実施形態に係る端末装置によって実行される、既存システムを監視するための処理の一例を示すフローチャートである。 図１２は、実施形態に係る端末装置によって実行される、既存システムの基点ＵＩを探索するための処理の一例を示すフローチャートである。 図１３は、実施形態に係る端末装置によって実行される、追加のＵＩの表示を制御するための処理の一例を示すフローチャートである。 図１４は、実施形態に係る端末装置によって実行される、既存システムの変化を監視するための処理の一例を示すフローチャートである。 図１５は、実施形態に係る端末装置によって実行される、既存のＵＩと追加のＵＩとの間でデータを流通するための処理の一例を示すフローチャートである。 図１６は、ハードウェア構成の一例を示す図である。

　以下、本開示の実施形態について、図面を参照しつつ詳細に説明する。なお、この実施形態により本発明が限定されるものではない。１つまたは複数の実施形態の詳細は、以下の説明および図面に記載される。また、複数の実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、以下の１つまたは複数の実施形態において同一の部位には同一の符号を付し、重複する説明は省略する。

〔１．概要〕
　本節では、本明細書に記載されるいくつかの実装形態の概要について説明する。なお、この概要は、読者の便宜のために提供されるものであって、本発明や、以下の節で説明される実施形態を限定することを意図するものではない。

　従来、Ｗｅｂシステムを対象としたＵＩ拡張が提案されている。従来のＵＩ拡張は、Ｗｅｂブラウザに描画されたＤＯＭツリーに対し、ＨＴＭＬを挿入することで、追加のＵＩを表示する。従来のＵＩ拡張では、既存のＵＩおよび追加のＵＩの両方が、同じＷｅｂブラウザ上のＤＯＭツリー内に存在する。

　従来のＵＩ拡張では、Ｗｅｂブラウザ上でＤＯＭを操作するJavaScriptを実行することで、既存のＵＩと追加のＵＩとの間でデータを流通することができる。データの流通は、例えば、追加のＵＩに入力された値を、既存のＵＩに反映させることを含む。しかしながら、上述したような仕組みにより、従来のＵＩ拡張をＷｅｂシステム以外のシステムに適用することは難しい。

　図１は、従来のＵＩ拡張の一例を示す説明図である。図１の例では、画面１０は、Ｗｅｂシステムの画面（例えば、既存の業務システムの画面）である。画面１０は、既存のＵＩ１１を含む。

　はじめに、従来のＵＩ拡張は、Ｗｅｂシステムの画面１０のＤＯＭツリーに追加のＨＴＭＬを挿入することで、追加のＵＩ１２を表示する。図１の例では、同じＷｅｂブラウザ内に、既存のＵＩ１１および追加のＵＩ１２が存在する。

　続いて、従来のＵＩ拡張は、ＤＯＭツリーを操作するＡＰＩをJavaScriptで実行することで、既存のＵＩ１１と追加のＵＩ１２の間で、データを流通する（ステップＳ１２）。既存のＵＩ１１および追加のＵＩ１２は、同じＷｅｂブラウザ内に存在する。このため、従来のＵＩ拡張は、Ｗｅｂブラウザで動作するプログラム（JavaScript）でＤＯＭツリーを操作することで、比較的容易にデータを流通することができる。しかしながら、従来のＵＩ拡張は、ＤＯＭツリーを操作するため、従来のＵＩ拡張を、Ｗｅｂシステム以外のシステムに適用することは難しい。

　そこで、実施形態に係るユーザインタフェース拡張システムは、システムの実装によらずに適用可能なＵＩ拡張を提供する。ユーザインタフェース拡張システムは、既存システムの画面と同じサイズの背景が透明なＷｅｂブラウザを、この画面の上部でこの画面とは独立して動作させ、このＷｅｂブラウザに、追加のＵＩを表示する。さらに、ユーザインタフェース拡張システムは、Accessibility　ＡＰＩと、画像処理を使用したキーボードエミュレーションとの併用により、追加のＵＩから完全に独立している既存のＵＩと追加のＵＩとの間で、データを流通する。

　図２は、実装例に係るＵＩ拡張の一例を示す説明図である。図２の例では、画面１０は、Ｗｅｂシステム以外のシステムの画面であってもよいし、Ｗｅｂシステムの画面であってもよい。

　実装例に係るＵＩ拡張では、ユーザインタフェース拡張システムは、背景が透明な独立したＷｅｂブラウザ２０に、追加のＵＩを表示する（ステップＳ２１）。Ｗｅｂブラウザ２０は、画面１０から完全に独立している。すなわち、Ｗｅｂブラウザ２０のプロセスは、画面１０のプロセスとは異なる。

　Ｗｅｂブラウザ以外の様々な実装のシステムに対応するために、ユーザインタフェース拡張システムは、Accessibility　ＡＰＩと仮想的なキーボード操作とを組み合わせて、既存のＵＩと追加のＵＩの間でデータを流通する（ステップＳ２２）。

　既存システムのＵＩがAccessibility　ＡＰＩを利用できる場合には、ユーザインタフェース拡張システムは、Accessibility　ＡＰＩで、既存システムを操作して、追加のＵＩの内容を、既存のＵＩに反映させる。

　既存システムのＵＩがAccessibility　ＡＰＩを利用できない場合には、ユーザインタフェース拡張システムは、キーボードのコピーペースト操作を仮想的に実行する。具体的は、ユーザインタフェース拡張システムは、追加のＵＩの内容をコピーして、その内容を既存のＵＩにペーストし、それによって、追加のＵＩの内容を既存のＵＩに反映させる。

　これにより、ユーザインタフェース拡張システムは、既存の業務システムを改造せずに、業務システムの操作性を飛躍的に改善し、それによって、業務を効率化することができる。さらに、ユーザインタフェース拡張システムは、Ｗｅｂシステム以外の広範なシステムやサービスへのＵＩ拡張の適用を可能にすることができる。

〔２．はじめに〕
　今日、様々なシステムが、業務に使用されている。業務の実態は日々変化するため、業務の実態に合わせて業務システムをアップデートすることは、重要なことである。例えば、新規メニューが、サービスに追加されたものとする。この例では、もし、業務システムが新規メニューに対応していなければ、業務システムのユーザは、業務システム上で、新規メニューに関する業務を遂行することができない。

　そこで、業務システムをタイムリーにアップデートするために、ＵＩ拡張技術が提案されている。業務システムのＵＩを拡張するＵＩ拡張技術は、例えば、上述の特許文献１で詳しく議論されている。ＵＩ拡張技術は、業務システムの画面に追加されたＵＩの表示を制御する。

　図３Ａ、図３Ｂおよび図３Ｃは、追加のＵＩの表示制御の一例を示す説明図である。図３Ａ、図３Ｂおよび図３Ｃでは、追加のＵＩが、業務システムの画面等の、既存システムの画面に表示される。また、表示の基点となる基点ＵＩが、追加のＵＩに対して指定される。基点ＵＩは、既存のＷｅｂシステムの画面に存在するＵＩである。この基点ＵＩが画面に表示された場合に、追加のＵＩは、基点ＵＩからの相対座標に基づいて、画面に表示される。以下では、「基点のＵＩ」を「基点ＵＩ」と表記することがある。

　従来のＵＩ拡張は、既存システムの画面を構成するＤＯＭツリーの末尾に追加のＵＩを挿入する。従来のＵＩ拡張は、既存のＷｅｂシステムの画面を直接改造することの影響を発生させずに、追加のＵＩを表示することができる。

　図３Ａの例では、既存システムの画面３０は、既存のＵＩ３１と、基点のＵＩ３２を含む。基点のＵＩ３２は、既存システムの画面３０上に表示される追加のＵＩ３１の表示の基点となるＵＩである。図３Ａに示された矢印は、画面のＤＯＭツリーと、画面の見た目との対応を示す。従来のＵＩ拡張は、ＷｅｂブラウザにレンダリングされたＤＯＭツリーの末尾に、追加のＵＩのＨＴＭＬを挿入することで、追加のＵＩを表示する。

　図３Ａの例では、追加のＵＩ３３が（テキストボックス）が、従来のＵＩ拡張によって表示される。従来のＵＩ拡張は、既存システムの画面３０のＤＯＭに、追加のＵＩ３３のＨＴＭＬを挿入する。しかしながら、Ｗｅｂシステム以外のシステムは、そもそもＤＯＭツリーを持っていない。このため、ＵＩ拡張がＷｅｂシステム以外のシステムを対象とする場合に、従来のＵＩ拡張は、ＤＯＭツリーに追加のＵＩのＨＴＭＬを挿入する手法によって、システムの画面に追加のＵＩを表示することができない。

　図３Ｂの例では、図３Ａの場合と同様に、既存システムの画面３０は、既存のＵＩ３１と、基点のＵＩ３２を含む。また、追加のＵＩ３３が、既存システムの画面３０に表示されている。

　従来のＵＩ拡張は、追加のＵＩを表示するかを判定するために、既存のシステム画面に表示されているＵＩの中から、基点のＵＩを指定する。そして、基点のＵＩが表示されている時に、従来のＵＩ拡張は、対応する追加のＵＩを表示する制御を行う。

　図３Ｂの例では、基点のＵＩ３２が、追加のＵＩ３１に対応する基点のＵＩである。基点のＵＩ３２が表示されていれば、追加のＵＩ３３も表示される。基点のＵＩ３２が表示されていなければ、追加のＵＩ３３も表示されない。

　上述したように、従来のＵＩ拡張は、Ｗｅｂシステムを対象としている。従来のＵＩ拡張は、ＤＯＭツリーを操作するJavaScriptのＡＰＩを呼び出す（ステップＳ３１）。これにより、従来のＵＩ拡張は、基点のＵＩが存在するかを確認する（ステップＳ３２）。例えば、従来のＵＩ拡張は、idの情報を元に、「document.getElementById(“text01”)」の実行結果を確認することで、基点のＵＩが存在するかを、簡易に確認することができる。

　しかしながら、上述したように、Ｗｅｂシステム以外のシステムは、そもそもＤＯＭツリーを持っていない。このため、ＵＩ拡張がＷｅｂシステム以外のシステムを対象とする場合に、従来のＵＩ拡張は、ＤＯＭツリーを操作するＡＰＩを用いて、基点のＵＩが存在するかを確認することができない。

　図３Ｃの例では、既存システムの画面４０は、既存のＵ４１と、既存のＵ４２と、追加のＵＩ４３とを含む。従来のＵＩ拡張は、既存システムに表示されているＵＩと、追加のＵＩとの間で、データを流通する。例えば、追加したＵＩ（プルダウン）の値が選択された場合に、従来のＵＩ拡張は、選択された値に対応する情報を、既存システムのＵＩ（テキストボックス）に反映させる。これにより、従来のＵＩ拡張は、入力の簡易化等のＵＩの効率化を実現する。

　従来のＵＩ拡張では、追加のＵＩおよび既存のＵＩの両方が、Ｗｅｂブラウザにレンダリングされた同じＤＯＭツリーの中に存在する。このため、従来のＵＩ拡張は、ＤＯＭツリーを操作するJavaScriptのＡＰＩを呼び出すことで、データの流通における以下の２つの処理を、簡易に実現することができる（ステップＳ４１）。

　第１の処理は、追加のＵＩに対する操作を、システム画面の既存のＵＩに反映させることである（ステップＳ４２）。第２の処理は、システム画面の既存のＵＩの情報を、追加のＵＩに反映させることである（ステップＳ４３）。

　例えば、従来のＵＩ拡張が、追加のＵＩの選択に応じて、既存のＵＩに値を設定する場合には、従来のＵＩ拡張は、以下のようなJavaScriptを実行する。実行されるJavaScriptは、例えば、「if　($(“#ext01”).val()==“パターン1”)｛$(“text01”).val(“オプション1”);$(“text02”).val(“オプション2”);｝」である。

　しかしながら、上述したように、Ｗｅｂシステム以外のシステムは、そもそもＤＯＭツリーを持っていない。このため、ＵＩ拡張がＷｅｂシステム以外のシステムを対象とする場合に、従来のＵＩ拡張は、ＤＯＭツリーを操作するＡＰＩを用いて、データを流通することができない。

　上述のように、従来のＵＩ拡張は、ＤＯＭツリーの末尾に追加のＵＩを挿入する。このため、従来のＵＩ拡張では、Ｗｅｂシステム以外のＧＵＩを有するシステムの画面上に追加のＵＩを表示することが難しい。

　Ｗｅｂシステム以外のシステムに適用可能なＵＩ拡張を実現するためには、以下の３つの処理が、様々なＧＵＩの実装を有するシステムに必要とされることが考えられる。第１の処理は、システム画面の上に追加のＵＩを表示する表示処理である。第２の処理は、基点となるＵＩを特定する特定処理である。第３の処理は、既存のＵＩと追加のＵＩとの間でデータを流通する流通処理である。具体的には、第３の処理は、追加のＵＩに対する操作を、システム画面の既存のＵＩに反映させる処理や、システム画面の既存のＵＩの情報を、追加のＵＩに反映させる処理を含む。

　そこで、Ｗｅｂシステム以外のシステムにＵＩ拡張を適用するために、実施形態に係るユーザインタフェース拡張システムは、以下に説明される処理を実行する。

　実施形態に係るユーザインタフェース拡張システムは、システム画面の上に追加のＵＩを表示する。ユーザインタフェース拡張システムは、背景が透明なＷｅｂブラウザを、システムの画面とは独立に、システムの画面の上部で動作させ、この透明なＷｅｂブラウザに、追加のＵＩを表示する。

　また、ユーザインタフェース拡張システムは、基点となるＵＩを特定する。例えば、ユーザインタフェース拡張システムは、システムの実装に応じて、以下の２つの方法で、基点となるＵＩを特定する。第１の方法は、基点となるＵＩのプロパティ値を用いたAccessibility　ＡＰＩによるＵＩの特定である。第２の方法は、基点となるＵＩのキャプチャ画像を用いたパターンマッチ等の、画像処理によるＵＩの特定である。

　さらに、ユーザインタフェース拡張システムは、既存のＵＩと追加のＵＩとの間でデータを流通する。例えば、ユーザインタフェース拡張システムは、システムの実装に応じて、以下の２つの方法で、データを流通する。第１の方法では、ユーザインタフェース拡張システムは、Accessibility　ＡＰＩを用いて、既存のＵＩのプロパティを取得および変更し、それによって、データを流通する。第２の方法では、ユーザインタフェース拡張システムは、キーボードのコピー＆ペースト操作により、クリップボードを介してデータを流通する。

　これにより、ユーザインタフェース拡張システムは、Ｗｅｂシステム以外のシステムにＵＩ拡張を適用することができる。ユーザインタフェース拡張システムは、Ｗｅｂシステム以外のシステムのＧＵＩを有するシステムの画面上に、追加のＵＩを表示することができる。また、ユーザインタフェース拡張システムは、既存のＵＩと追加のＵＩとの間で、データを流通することができる。

〔３．ユーザインタフェース拡張システムの構成〕
　次に、図４を参照して、実施形態に係るユーザインタフェース拡張システムの構成例について説明する。

　図４は、実施形態に係るユーザインタフェース拡張システム１の一例を示す図である。図４に示されるように、ユーザインタフェース拡張システム１は、端末装置１００と、コンテンツ提供装置２００とを含む。図４中では図示していないが、ユーザインタフェース拡張システム１は、複数台の端末装置１００や、複数台のコンテンツ提供装置２００を含んでもよい。

　ユーザインタフェース拡張システム１において、端末装置１００およびコンテンツ提供装置２００は、それぞれネットワークＮと有線又は無線により接続される。ネットワークＮは、例えば、インターネット、ＷＡＮ（Wide　Area　Network）、ＬＡＮ（Local　Area　Network）等のネットワークである。ユーザインタフェース拡張システム１の構成要素は、ネットワークＮを介して互いに通信を行うことができる。

〔３－１．構成要素〕
　端末装置１００は、ユーザインタフェースを拡張するための処理を実行する情報処理装置である。端末装置１００は、クライアント装置を含む、任意のタイプの情報処理装置であってもよい。端末装置１００の構成例は、次の節で詳述される。

　コンテンツ提供装置２００は、コンテンツ提供者によって利用される情報処理装置である。コンテンツ提供者は、コンテンツを、端末装置１００に提供する。「コンテンツ」という用語は、アプリケーションの画面（すなわち、ウィンドウ）やＷｅｂページの内容等の、画面に関する各種情報を包含し得る。コンテンツ提供装置２００は、サーバを含む、任意のタイプの情報処理装置であってもよい。

〔３－２．端末装置の構成〕
　次に、端末装置１００の構成例について説明する。

　図４に示されるように、端末装置１００は、通信部１１０と、入力部１２０と、出力部１３０と、既存システム１４０と、記憶部１５０と、制御部１６０とを有する。

（通信部１１０）
　通信部１１０は、例えば、ＮＩＣ（Network　Interface　Card）等によって実現される。通信部１１０は、有線または無線によりネットワーク網と接続される。通信部１１０は、コンテンツ提供装置２００に、ネットワークＮを介して、通信可能に接続される。通信部１１０は、コンテンツ提供装置２００との間で、ネットワーク網を介して、情報の送受信を行うことができる。

（入力部１２０）
　入力部１２０は、端末装置１００のユーザから各種操作を受け付ける入力装置である。例えば、入力部１２０は、キーボードやマウスや操作キー等によって実現される。

（出力部１３０）
　出力部１３０は、各種情報を表示するための表示装置である。例えば、出力部１３０は、液晶ディスプレイ、有機ＥＬ（Electro　Luminescence）ディスプレイ等によって実現される。なお、端末装置１００にタッチパネルが採用される場合には、入力部１２０と出力部１３０とは一体化される。

（既存システム１４０）
　既存システム１４０は、業務システムや各種アプリケーション等の既存のソフトウェアである。既存システム１４０は、コンテンツ提供装置２００から、コンテンツを受信する。また、既存システム１４０は、ＵＩを有する。受信されたコンテンツは、このＵＩを介して、端末装置１００のユーザに提供される。

　図４の例では、既存システム１４０は、端末装置１００にインストールされたソフトウェアとして示されているが、これに限定されるものではない。既存システム１４０は、コンテンツ提供装置２００にインストールされていてもよい。ただし、既存システム１４０のＵＩは、端末装置１００に存在するものとする。

（記憶部１５０）
　記憶部１５０は、例えば、ＲＡＭ（Random　Access　Memory)、フラッシュメモリ（Flash　Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図４に示されるように、記憶部１５０は、ルール記憶部１５１と、クリップボード記憶部１５２とを有する。

（ルール記憶部１５１）
　ルール記憶部１５１は、システム定義に関するルールを記憶する。ルールは、少なくとも１つのシステム定義を含む。

　図５は、実施形態に係るルール記憶部１５１の一例を示す図である。図５に示されるように、ルール記憶部１５１は、複数のシステム定義を含むルールを記憶する。各システム定義は、システム判定条件、環境設定（監視間隔、監視イベント）および少なくとも１つの追加ＵＩ設定（基点定義、表示条件、外観定義、動作定義）を含む。

　システム判定条件は、例えば、プロセス名（例えば、myapplication.exe）やウィンドウタイトル名（例えば、マイアプリケーション）を含む。

　環境設定は、既存システムの変化を監視するタイミングを示す監視間隔または既存システムの変化として利用されるイベントの一覧を示す監視イベントのうちの少なくとも１つを含む。例えば、環境設定は、例えば、監視間隔（例えば、５秒）や監視イベント（例えば、マウスホイールイベント、ウィンドウサイズ変更イベント）を含む。

　追加ＵＩ設定は、基点定義、表示条件、外観定義または動作定義を含む。例えば、追加ＵＩ設定は、１）追加されるＵＩが表示される際に基点となる既存システムのＵＩの情報であるキャプチャ画像またはプロパティ値を含む基点定義、２）追加されるＵＩが表示される条件を示す表示条件、３）追加されるＵＩの外観を示す外観定義または４）追加されるＵＩの振る舞いを示す動作定義のうちの少なくとも１つを含む。

（クリップボード記憶部１５２）
　クリップボード記憶部１５２は、クリップボードを記憶する。クリップボードは、後述するデータ流通部１６４によって使用される。

（制御部１６０）
　制御部１６０は、コントローラ（controller）であり、例えば、ＣＰＵ（Central　Processing　Unit）、ＭＰＵ（Micro　Processing　Unit）等のプロセッサによって、端末装置１００内部の記憶装置に記憶されている各種プログラム（ユーザインタフェース拡張プログラムの一例に相当）がＲＡＭ等を作業領域として実行されることにより実現される。また、制御部１６０は、例えば、ＡＳＩＣ（Application　Specific　Integrated　Circuit）、ＦＰＧＡ（Field　Programmable　Gate　Array）、ＧＰＧＰＵ（General　Purpose　Graphic　Processing　Unit）等の集積回路により実現されてもよい。

　制御部１６０は、図４に示されるように、第１タイミング発生部１６１と、基点探索部１６２と、表示制御部１６３と、データ流通部１６４と、第２タイミング発生部１６５とを有し、以下に説明する情報処理の機能や作用を実現又は実行する。端末装置１００の１つまたは複数のプロセッサは、端末装置１００の１つまたは複数のメモリに記憶された命令を実行することによって、制御部１６０内の各制御部の機能を実現することができる。なお、制御部１６０の内部構成は、図４に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。例えば、表示制御部１６３は、表示制御部１６３以外の部に関して後述する情報処理の全部または一部を行ってもよい。

　一例として、制御部１６０は、端末装置１００にインストールされた第１のアプリケーションとして実装される。この例では、上述の既存システム１４０は、端末装置１００にインストールされた第２のアプリケーションとして実装される。

（第１タイミング発生部１６１）
　第１タイミング発生部１６１は、システムの画面から基点ＵＩを探索するタイミングを決定する。例えば、第１タイミング発生部１６１は、既存システム１４０を監視する。そして、第１タイミング発生部１６１は、既存システム１４０の画面が視認可能に表示されているかに基づいて、既存システム１４０の画面から基点ＵＩを探索するタイミングを決定する。このように、第１タイミング発生部１６１は、基点ＵＩを探索するタイミングを調整する。第１タイミング発生部１６１は、ＵＩ　Automationやグローバルフック等の手法を用いて、既存システム１４０を監視することができる。

　一例として、第１タイミング発生部１６１は、ルール記憶部１５１に記憶されたルールの全てのシステム定義から、システム判定条件と環境設定とを取得する。第１タイミング発生部１６１は、環境設定の監視間隔の時間が経過するごとに、システム判定条件に一致するシステムのウィンドウが、デスクトップ上に最前面で表示されているかを判定する。ウィンドウが最前面に表示されている場合には、システム定義に含まれる全ての追加ＵＩ設定を入力として使用して、基点探索部１６２を呼び出す。

（基点探索部１６２）
　基点探索部１６２は、システムの画面に追加される追加のＵＩの表示の基点となる基点ＵＩを、このシステムの画面から探索する。例えば、基点探索部１６２は、ルール記憶部１５１に記憶されたルールに保存された追加ＵＩ設定を入力として使用する。そして、基点探索部１６２は、第１タイミング発生部１６１によって指示されたタイミングで、既存システム１４０の画面から、基点定義に一致するＵＩ（基点ＵＩ）を探索する。

　一例として、基点探索部１６２は、第１タイミング発生部１６１によって指示されたタイミングで呼び出される。プロパティ値が基点定義として設定されている場合には、基点探索部１６２は、Accessibility　ＡＰＩを用いて、基点定義のプロパティ値が一致するＵＩ（基点ＵＩ)を探索する。キャプチャ画像が基点定義として設定されている場合には、基点探索部１６２は、基点定義のキャプチャ画像と、既存システムの画面の現在の表示を示すキャプチャ画像とを、入力として使用する。そして、基点探索部１６２は、テンプレートマッチング等の任意の画像処理手法によって、基点定義のキャプチャ画像と一致するＵＩ（基点ＵＩ)を探索する。

　基点ＵＩが見つかり、かつ表示条件が基点定義として設定されている場合には、基点探索部１６２は、データ流通部１６４に関して後述する情報処理（値の取得）によって、基点ＵＩから値を取得する。そして、基点探索部１６２は、基点ＵＩの値が表示条件と一致しているかを判定する。

　基点探索部１６２は、判定結果として一致または不一致を返却する。判定結果が一致の場合には、基点探索部１６２は、基点ＵＩの座標とサイズを、判定結果とともに返却する。加えて、基点探索部１６２は、第２タイミング発生部１６５に、基点ＵＩを監視対象として追加する。基点ＵＩが見つからなかった場合には、基点探索部１６２は、判定結果として不一致を返却する。

　このように、基点探索部１６２は、Accessibility　ＡＰＩで利用されるＵＩのプロパティ値や、システム画面のキャプチャ画像の画像処理の結果に基づいて、追加のＵＩの表示の対象である基点ＵＩを特定する。

　図６は、追加のＵＩの表示の基点となる基点ＵＩを探索する基点探索処理の一例を示す説明図である。基点探索部１６２は、既存システム（例えば、既存システム１４０）から、基点となるＵＩを特定する。

　ＵＩ拡張がＷｅｂシステムを対象とする場合には、ＤＯＭを操作するJavaScriptのＡＰＩを利用して、基点となるＵＩを簡易に特定できる。しかしながら、ＵＩ拡張が任意のシステムを対象とする場合には、ＵＩ拡張は、JavaScriptのＡＰＩのような統一的な仕組みを利用することができない。

　そこで、基点探索部１６２は、様々なシステムの実装に対応するために、Accessibly　ＡＰＩと、画像処理の併用によって、基点となるＵＩを特定する。上述のルール記憶部１５１に記憶されたルールは、基点を特定するための基点定義を保持する。基点探索部１６２は、Accessibility　ＡＰＩで基点ＵＩを特定するためのプロパティ値または画像処理によって基点ＵＩを特定するためのキャプチャ画像のうちのいずれかを、この基点定義に設定することができる。

　図６の例では、処理５１は、Accessibility　ＡＰＩで基点ＵＩを特定する処理である。基点探索部１６２は、システムの実装によっては、Accessibility　ＡＰＩを利用することができる。例えば、Windows（登録商標）のＷＰＦ（Windows　Presentation　Foundation）等の実装では、基点探索部１６２は、ＵＩ　Automation等を利用することができる。また、Java（登録商標）のSwing等の実装では、基点探索部１６２は、Java　Access　Bridge等を利用することができる。基点探索部１６２がAccessibility　ＡＰＩを利用することができる場合に、基点探索部１６２は、システム画面を構成する各ＵＩのプロパティ値を取得することができる。

　基点探索部１６２は、ルール記憶部１５１に記憶されたルールの基点定義に、プロパティ値を設定することができる。この場合、基点探索部１６２は、Accessibility　ＡＰＩによって、対象の既存システムのＵＩのプロパティ値を、逐次的に取得することができる。基点探索部１６２は、基点定義のプロパティ値と一致する取得されたプロパティ値が存在するかを判定することで、基点となるＵＩを特定することができる。

　図６の例では、処理５２は、画像処理によって基点ＵＩを特定する処理である。システムのＵＩが独自の実装によって構築されている場合に、基点探索部１６２は、Accessibility　ＡＰＩを利用できない場合がある。そのような場合でも、基点探索部１６２は、基点定義として、キャプチャ画像を設定することができる。基点探索部１６２は、システム画面の現在のキャプチャ画像と、基点定義に設定されたキャプチャ画像とを、テンプレートマッチ等の画像処理によって突合することで、基点となるＵＩを特定することができる。

（表示制御部１６３）
　表示制御部１６３は、背景が透明な新たな画面を、システムの画面と重ねて表示する。そして、表示制御部１６３は、この新たな画面において、基点ＵＩに基づく位置に追加のＵＩを表示する。

　例えば、表示制御部１６３は、ルール記憶部１５１に記憶されたルールに保存された追加ＵＩ設定と、基点探索部１６２の探索結果を、入力として使用する。そして、表示制御部１６３は、そのウィンドウサイズが既存システム１４０の画面のウィンドウサイズと一致する背景が透明なＷｅｂブラウザを、既存システム１４０の画面の上部に表示する。さらに、表示制御部１６３は、外観定義に従って、追加のＵＩをこのＷｅｂブラウザに表示する。

　一例として、表示制御部１６３は、基点探索部１６２によって出力された判定結果、基点ＵＩの座標および基点ＵＩのサイズを、入力として使用する。判定結果が一致である場合は、表示制御部１６３は、基点ＵＩの座標と、外観定義に設定された相対座標とから、追加のＵＩの表示位置を計算する。

　対応する追加のＵＩが、透明なＷｅｂブラウザ上に表示されていない場合には、表示制御部１６３は、外観定義に設定されたＨＴＭＬ情報に従って、追加のＵＩを計算された表示位置に新規に表示する。対応する追加のＵＩが既に表示されている場合には、表示制御部１６３は、追加のＵＩの現在の表示位置を、計算された表示位置に修正する。

　判定結果が不一致であり、かつ対応する追加のＵＩが透明なＷｅｂブラウザ上に既に表示されている場合には、表示制御部１６３は、該当する追加のＵＩを非表示にする。

　透明なＷｅｂブラウザにおける透明な領域への操作イベントに関しては、透明なＷｅｂブラウザは、追加のＵＩが表示されていない領域で発生した全ての操作イベントを、透明なＷｅｂブラウザの下部に表示された既存のシステムに流通してもよい。例えば、透明なＷｅｂブラウザは、追加のＵＩが表示されていない領域について、全ての操作イベントを一切加工せずに、全ての操作イベントを既存のシステムに流通してもよい。

　このように、表示制御部１６３は、システムの画面から独立した、背景が透明なＷｅｂブラウザを動作させ、そのＷｅｂブラウザに追加のＵＩを表示する。

　図７は、追加のＵＩの表示を制御する表示制御処理の一例を示す説明図である。図７の例では、表示制御部１６３は、システムの画面６０の上に、追加のＵＩを表示する。システムの画面６０は、既存システムの画面である。

　表示制御部１６３は、背景が透明なＷｅｂブラウザ７０を、システムの画面６０とは独立に、Ｗｅｂブラウザ７０の上部で動作させ、透明なＷｅｂブラウザ７０に、ＵＩ７１を表示する。なお、システムの画面６０は、WindowsのＷＰＦやJavaのSwing等によって実装されてもよい。端末装置１００のユーザがシステムの画面６０を正面から見ると、ＵＩ７１は、従来のＵＩ拡張と同じように、ＵＩ７１がこの元のシステムの画面６０に追加されたように見える。

（データ流通部１６４）
　データ流通部１６４は、システムの画面の既存のＵＩと、追加のＵＩとの間でデータを流通する。例えば、データ流通部１６４は、ルール記憶部１５１に記憶されたルールに保存された追加ＵＩ設定を入力として使用する。そして、データ流通部１６４は、動作定義に従って、表示制御部１６３によって透明なＷｅｂブラウザに表示された追加のＵＩと、既存システム１４０に表示されたＵＩとの間で、それぞれのＵＩに入力されたまたは表示されたデータを、双方に流通する。

　一例として、データ流通部１６４は、ルール記憶部１５１に記憶されたルールに保存された、値取得、値設定およびクリック操作のうちの少なくとも１つの動作定義に対応したデータ流通を提供する。

　例えば、動作定義が値取得である場合に、データ流通部１６４は、既存システム１４０のＵＩに表示されている値を取得する。そして、データ流通部１６４は、取得された値を、そのまま、表示制御部１６３によって透明なＷｅｂブラウザに表示された追加のＵＩに反映させる。あるいは、データ流通部１６４は、取得された値を加工または変換して、その値を追加のＵＩに反映させる。

　上述の値取得においては、データ流通部１６４は、対象とする既存システム（例えば、既存システム１４０）のＵＩが、Accessibility　ＡＰＩに対応しているかを判定する。対象とする既存システムのＵＩがAccessibility　ＡＰＩに対応している場合には、データ流通部１６４は、Accessibility　APIを用いて、既存システムのＵＩに表示されている値を取得する。対象とする既存システムのＵＩがAccessibility　ＡＰＩに対応していない場合には、データ流通部１６４は、既存システムのＵＩに対してキーボードのコピー操作を行うことで、クリップボード記憶部１５２に記憶されたクリップボードを介して、既存システムのＵＩに表示された値を取得する。

　動作定義が値設定である場合には、データ流通部１６４は、表示制御部１６３によって透明なＷｅｂブラウザに表示された追加のＵＩに表示されている値を取得する。そして、データ流通部１６４は、取得された値を、そのまま既存システム１４０のＵＩに反映させる。

　上述の値設定においては、データ流通部１６４は、対象とする既存システム（例えば、既存システム１４０）のＵＩが、Accessibility　ＡＰＩに対応しているかを判定する。対象とする既存システムのＵＩがAccessibility　ＡＰＩに対応している場合には、データ流通部１６４は、Accessibility　ＡＰＩを用いて、既存システムのＵＩに値を反映させる。対象とする既存システムのＵＩがAccessibility　ＡＰＩに対応していない場合には、データ流通部１６４は、既存システムのＵＩに対してキーボードのペースト操作を行うことで、クリップボード記憶部１５２に記憶されたクリップボードを介して、既存システムのＵＩに値を反映させる。

　動作定義が、クリック操作であり、かつクリック操作が、表示制御部１６３によって透明なＷｅｂブラウザに表示された追加のＵＩに対してなされた場合に、データ流通部１６４は、既存システム１４０のＵＩに、このクリック操作を反映させる。

　例えば、データ流通部１６４は、対象とする既存システム（例えば、既存システム１４０）のＵＩが、Accessibility　ＡＰＩに対応しているかを判定する。対象とする既存システムのＵＩがAccessibility　ＡＰＩに対応している場合には、データ流通部１６４は、Accessibility　ＡＰＩを用いて、既存システムのＵＩにクリック操作を反映させる。対象とする既存システムのＵＩがAccessibility　ＡＰＩに対応していない場合には、データ流通部１６４は、一時的に透明なＷｅｂブラウザ全体を最小化する。そして、データ流通部１６４は、既存システムのＵＩが表示されている座標においてクリックイベントを発生させることで、既存システムのＵＩにクリック操作を反映させる。

　図８は、既存のＵＩと追加のＵＩとの間でデータを流通するデータ流通処理の一例を示す説明図である。図８の例では、データ流通部１６４が、Accessibility　ＡＰＩや仮想的なキーボード操作を使って、既存のＵＩと、追加のＵＩの間でデータを流通する。

　上述のように、ＵＩ拡張がＷｅｂシステムを対象とする場合には、同じＤＯＭツリーに、既存のＵＩだけでなく追加のＵＩも存在する。このため、ＤＯＭを操作するJavaScriptのＡＰＩを利用して、簡易にデータを流通することができる。しかしながら、既存システムの画面がWindowsのＷＰＦやJavaのSwing等によって実装されている場合に、この画面は、ＤＯＭツリーを持たない。追加のＵＩを表示する透明のＷｅｂブラウザは、既存システムの画面から完全に独立している。したがって、従来の方法（JavaScriptのＡＰＩを利用する方法）では、既存のＵＩと、追加のＵＩの間でデータを流通することが困難である。

　そこで、データ流通部１６４は、様々なシステムの実装に対応するために、Accessibly　ＡＰIと仮想的なキーボード操作との併用によって、既存のＵＩと追加のＵＩとの間でのデータの流通を可能にする。

　Accessibly　ＡＰIに関しては、データ流通部１６４がAccessibly　ＡＰIを利用することができる場合に、データ流通部１６４は、システムの画面を構成する各ＵＩを操作するＡＰＩを取得する。データ流通部１６４は、これらのＡＰＩ呼び出すことで、ＵＩに対して値を設定したり、ＵＩから値を取得したりすることできる。

　図８の例では、はじめに、データ流通部１６４は、透明なＷｅｂブラウザに対するJavaScriptのＡＰＩの呼び出しによって、追加のＵＩの値を取得する（ステップＳ８０Ａ－１）。例えば、データ流通部１６４は、「$(“ext01”).val()」というメソッドを利用して、簡易に追加のＵＩの値を取得することができる。

　次いで、データ流通部１６４は、Accessibly　ＡＰIの値を設定するＡＰＩを呼び出して、追加のＵＩから取得された値を、既存システムのＵＩに反映させる（ステップＳ８０Ａ－２）。

　仮想的なキーボード操作に関しては、上述したように、システムのＵＩが独自の実装によって構築されている場合に、データ流通部１６４は、Accessibly　ＡＰIを利用することができない場合もある。そのような場合でも、データ流通部１６４は、ソフトウェアに、仮想的なキーボード操作により、キーボードのコピーまたはペースト操作を実行させることができる。データ流通部１６４は、クリップボードを介して、既存のＵＩと追加のＵＩの間で、データを流通することができる。

　図８の例では、はじめに、データ流通部１６４は、Accessibly　ＡＰIの場合と同様に、追加のＵＩの値を取得する（ステップＳ８０Ｂ－１）。

　次いで、データ流通部１６４は、追加のＵＩから取得された値を、クリップボードに設定する（ステップＳ８０Ｂ－２）。

　次いで、データ流通部１６４は、データを流通することが望まれる既存のＵＩにフォーカスをあてる（ステップＳ８０Ｂ－３）。言い換えると、データを流通することが望まれる既存のＵＩは、端末装置１００のユーザがデータを流通したい既存のＵＩである。

　次いで、データ流通部１６４は、ソフトウェアからペーストのキーボード操作を実行する（ステップＳ８０Ｂ－４）。すなわち、人間（ユーザ）は、キーボードを操作しない。

（第２タイミング発生部１６５）
　第２タイミング発生部１６５は、所定のイベントがシステムの画面で発生したかに基づいて、表示制御部１６３によって表示された追加のＵＩを再表示するタイミングを決定する。例えば、第２タイミング発生部１６５は、ルール記憶部１５１に記憶されたルールに保存された環境設定を、入力として使用する。そして、第２タイミング発生部１６５は、既存システム１４０の変化を監視し、追加のＵＩの再表示が必要とされるタイミングを指示する。このように、第２タイミング発生部１６５は、追加のＵＩを再表示するタイミングを調整する。第２タイミング発生部１６５は、ＵＩ　Automationやグローバルフック等の手法を用いて、既存システム１４０の変化を監視することができる。

　より具体的には、環境設定の監視イベントに設定されたイベントが、システム判定条件に一致するシステムのウィンドウから観測された場合には、第２タイミング発生部１６５は、イベントの種別に合った処理を呼び出す。

　上述の監視イベントおよび呼び出される処理に関しては、第２タイミング発生部１６５は、以下の４つの処理のうちの少なくとも１つを実行することができる。

　第１の処理に関しては、マウスホイールイベントが、対象とするシステム（例えば、既存システム１４０）のウィンドウ内で発生したとき、第２タイミング発生部１６５は、対応するシステム定義に含まれる全ての追加ＵＩ設定を入力として使用して使用し、基点探索部１６２を呼び出す。これにより、第２タイミング発生部１６５は、追加のＵＩの表示位置を、マウスホイールのスクロールによる基点ＵＩの表示位置の変更に追従させる。

　第２の処理に関しては、対象とするシステム（例えば、既存システム１４０）のウィンドウのサイズ変更イベントが発生したとき、第２タイミング発生部１６５は、対応する透明なＷｅｂブラウザのサイズを、このＷｅｂブラウザのサイズがシステムのウィンドウのサイズに追従するように、変更する。サイズの変更後に、第２タイミング発生部１６５は、対応するシステム定義に含まれる全ての追加ＵＩ設定を、入力として使用して、基点探索部１６２を呼び出す。これにより、第２タイミング発生部１６５は、追加のUIの表示位置を、ウィンドウのサイズ変更による基点ＵＩの表示位置の変更に追従させる。

　第３の処理に関しては、描画のリロードなどの更新イベントが、対象とするシステム（例えば、既存システム１４０）のウィンドウ内で発生したとき、第２タイミング発生部１６５は、対応する透明なＷｅｂブラウザに表示されている全ての追加のＵＩを削除する。追加のＵＩの削除後に、第２タイミング発生部１６５は、対応するシステム定義に含まれる全ての追加ＵＩ設定を、入力として使用して、基点探索部１６２を呼び出す。これにより、第２タイミング発生部１６５は、システムの画面の表示内容の変更に応じて、追加のＵＩの表示を切り替える。

　第４の処理に関しては、マウスクリックのイベントまたはフォーカス変更のイベントが、対象とするシステム（例えば、既存システム１４０）のウィンドウ内で発生したとき、第２タイミング発生部１６５は、該当するイベントが発生したＵＩを特定する。該当するＵＩが基点探索部１６２によって監視対象として登録された基点ＵＩと合致した場合には、基点ＵＩに対応する基点定義を含む追加ＵＩ設定を、入力として使用して、基点探索部１６２を呼び出す。これにより、第２タイミング発生部１６５は、基点ＵＩの値の変化に応じて、対応する追加のＵＩの表示を切り替える。

　図９Ａおよび図９Ｂは、追加のＵＩを再表示するタイミングを発生させるタイミング発生処理一例を示す説明図である。

　上述したように、追加のＵＩを表示する透明なＷｅｂブラウザは、既存システム１４０の画面から完全に独立している。このため、以下の対応が必要とされる場合がある。なお、従来のユーザインタフェース拡張では、同じＤＯＭツリーに、既存のＵＩおよび追加のＵＩが存在する。このため、従来のユーザインタフェース拡張は、以下の対応を考慮することを必要としていない。

　第１の対応は、基点のＵＩの値の変化を検知し、追加のＵＩ（独立した透明なＷｅｂシステム）へ値の変化を通知することである。第２の対応は、透明なＷｅｂシステムに追加されたＵＩの削除（クリア）したり、再描画のタイミングを指定したりすることである。このような対応のために、制御部１６０は、第２タイミング発生部１６５を有する。

　「ある値が基点のＵＩに設定されている」という条件は、追加のＵＩの表示条件として、頻繁に登場する。このような場合、ユーザが基点のＵＩの値を変更したタイミングで、基点のＵＩの値をチェックし、値が表示条件と一致するかを判定し、追加のＵＩの表示を制御することが必要とされる。

　従来のＵＩ拡張では、ＵＩ拡張の対象がＷｅｂシステムであった。このため、JavaScriptのイベントリスナーの機能を用いて、観測したいイベントに対してリスナーを登録することで、基点のＵＩの値の変化の取得を、簡易に実現することができる。しかしながら、実装例に係るＵＩ拡張では、対象とする既存のシステムは、Ｗｅｂシステム以外のシステムも含む。このため、既存のＵＩのイベントにリスナーを登録することは、容易ではない。

　そこで、第２タイミング発生部１６５は、マウスクリックまたはフォーカス変更のイベントが発生したタイミングで、クリックされた既存のＵＩまたはフォーカスが変更された既存のＵＩが、基点のＵＩであるかを判定する。どのようなシステム実装でも、マウスクリックまたはフォーカス変更は、容易に観測されるイベントである。

　クリックされた既存のＵＩまたはフォーカスが変更された既存のＵＩが、基点のＵＩであると判定された場合に、第２タイミング発生部１６５は、対応する追加のＵＩに対して、基点探索部１６２の処理を呼び出して、対応する追加のＵＩの表示条件を再度チェックする。これにより、第２タイミング発生部１６５は、基点ＵＩの値が変更された可能性があるタイミングを、追加のＵＩに対して通知し、それによって、追加のＵＩの表示制御を可能にする。このように、第２タイミング発生部１６５は、マウスクリックやフォーカス変更を監視し、基点ＵＩの値の変更が発生した可能性を通知する。

　基点ＵＩの値が変更された可能性があるタイミングに関しては、マウスクリックまたはフォーカス変更のイベントが、基点ＵＩの値が変更されたタイミングで、常に発生するわけではない。結果的には、基点ＵＩの値は、変更されていないかもしれない。そのような場合でも、表示条件の再度のチェックにおける不都合は、発生しない。マウスクリックおよびフォーカス変更のイベント以外の他のイベントが、基点ＵＩの値が変更されたタイミングで発生する可能性がある場合には、第２タイミング発生部１６５は、他のイベントを監視してもよい。他のイベントが発生した場合に、第２タイミング発生部１６５は、マウスクリックやフォーカス変更の場合と同様に、基点ＵＩの値の変更が発生した可能性を通知してもよい。

　加えて、Accessibility　ＡＰＩで、基点のＵＩに対し、値変更などのイベントのリスナーを登録することができる場合には、第２タイミング発生部１６５は、基点のＵＩごとに、リスナーを登録することもできる。イベントが発生した時に、第２タイミング発生部１６５は、対応する追加のＵＩに対して、基点ＵＩの値が変更されたタイミングを通知することができる。

　図９Ａの例では、基点のＵＩ９１および対応する追加のＵＩ９２が、既存システムの画面９０上に表示されている。追加のＵＩ９２の表示条件は、「基点のＵＩの値が「aaa」である」という条件である。多くの場合、マウスクリックまたはフォーカス変更のイベントが、基点ＵＩの値が変更されたタイミングで発生する。第２タイミング発生部１６５は、基点のＵＩ９１の値が変更されたタイミングで、基点のＵＩ９１の値の変化を検知し、追加のＵＩ９２を非表示にする。

　一方、図９Ｂの例では、第２タイミング発生部１６５は、透明なＷｅｂブラウザに追加されている全てのＵＩを削除（クリア）し、新たに表示制御を行う。

　従来のＵＩ拡張では、既存のＵＩおよび追加のＵＩは、同じＷｅｂブラウザのＤＯＭツリーに表示されている。このため、追加のＵＩが削除（クリア）または再描画されるタイミングは、自明であった。

　例えば、追加のＵＩが表示されているＷｅｂページがリロードされた場合には、全ＤＯＭツリーは、一度削除されて、新しいＤＯＭツリーが再度読み込まれる。このため、追加のＵＩも削除（クリア）され、新しいＤＯＭツリーが呼び込まれた後に、必要とされる追加のＵＩが再描画される。

　しかしながら、実装例に係るＵＩ拡張では、既存のＵＩは、追加のＵＩが表示されている領域から完全に独立している。既存のＵＩが再度読み込まれたとしても、追加のＵＩは、そのままでは残ってしまう。なお、監視間隔ごとの表示制御処理によって、非表示または表示の切り替えを行うことは可能である。ただし、追加のＵＩを読み込みなおすことができない。表示制御処理で追加のＵＩを非表示にせずに、毎回、新たな追加のＵＩを読み込み直す（すなわち、追加のＵＩを削除してからＵＩを追加すること）ことも可能である。この場合、ユーザが追加のＵＩに入力した内容が、監視間隔ごとにクリアされてしまい、これは、ユーザインタフェース拡張として、利用に堪えない。

　そこで、第２タイミング発生部１６５は、更新（リロード）のイベントを、任意（例えば、既存システムの画面の更新ボタンが押されたときや、タブが切り換えられたとき等）に設定することを可能にする。そして、第２タイミング発生部１６５は、更新イベントが発生した時に、対応する透明なＷｅｂブラウザに追加されている全てのＵＩを削除（クリア）し、表示制御を新たに行う。これにより、第２タイミング発生部１６５は、追加のＵＩの再描画を可能にする。

　図９Ｂの例では、基点のＵＩ９１および対応する追加のＵＩ９２が、既存システムの画面９０上に表示されている。この例では、スクロール領域内全体が再描画され、基点のＵＩ９１がなくなった。従来のＷｅｂシステムを対象としたＵＩ拡張では、追加のＵＩ９２は、自動的に削除される。しかしながら、実装例に係るＵＩ拡張では、追加のＵＩ９２は、そのままだと残置される。追加のＵＩ９２は、どんなに良くても非表示となるだけであり、追加のＵＩ９２は、削除（クリア）されない。第２タイミング発生部１６５は、追加のＵＩ９２に対して、新たな表示制御を適用する。新たな表示制御は、図１４を参照して以下で詳述される。

〔４．ＵＩ拡張処理のフロー〕
　次に、図１０、図１１、図１２、図１３、図１４および図１５を参照して、実施形態に係る端末装置１００によるＵＩ拡張処理の手順について説明する。

　図１０は、実施形態に係る端末装置１００によって実行される、既存システムの画面のＵＩを拡張するための処理の一例を示すフローチャートである。

　図１０に示されるように、はじめに、端末装置１００の第１タイミング発生部１６１は、既存システムを監視する（ステップＳ１０１）。既存システムの監視は、図１１を参照して以下で詳述される。

　次いで、端末装置１００の基点探索部１６２は、現時点が既存システムの基点ＵＩを探索するタイミングであるかを判定する（ステップＳ１０２）。現時点が既存システムの基点ＵＩを探索するタイミングでないと判定された場合に（ステップＳ１０２：Ｎｏ）、処理手順は、ステップＳ１０１に戻る。

　現時点が既存システムの基点ＵＩを探索するタイミングであると判定された場合に（ステップＳ１０２：Ｙｅｓ）、基点探索部１６２は、既存システムの基点ＵＩを探索する（ステップＳ１０３）。既存システムの基点ＵＩの探索は、図１２を参照して以下で詳述される。

　次いで、端末装置１００の表示制御部１６３は、追加のＵＩの表示を制御する（ステップＳ１０４）。追加のＵＩの表示の制御は、図１３を参照して以下で詳述される。

　次いで、端末装置１００の第２タイミング発生部１６５は、既存システムの変化を監視する（ステップＳ１０５）。既存システムの変化の監視は、図１４を参照して以下で詳述される。

　次いで、基点探索部１６２は、現時点が追加のＵＩを再表示するタイミングであるかを判定する（ステップＳ１０６）。現時点が追加のＵＩを再表示するタイミングであると判定された場合に（ステップＳ１０６：Ｙｅｓ）、処理手順は、ステップＳ１０３に戻る。

　現時点が追加のＵＩを再表示するタイミングでないと判定された場合に（ステップＳ１０６：Ｎｏ）、端末装置１００の第２タイミング発生部１６５は、既存のＵＩと追加のＵＩとの間でデータを流通する（ステップＳ１０７）。既存のＵＩと追加のＵＩとの間でのデータの流通は、図１５を参照して以下で詳述される。

　なお、図１０の例では、端末装置１００は、ステップＳ１０５およびステップＳ１０６の後にステップＳ１０７を実行しているが、この順序に限定されるものではない。端末装置１００は、既存のＵＩと追加のＵＩとの間でのデータの流通の後に、既存システムの変化を監視してもよい。

　図１１は、実施形態に係る端末装置１００によって実行される、既存システムを監視するための処理の一例を示すフローチャートである。端末装置１００の第１タイミング発生部１６１は、既存システムの監視を、ルール記憶部１５１に記憶されたシステム定義ごとに、並列で実行する。

　図１１に示されるように、はじめに、第１タイミング発生部１６１は、ルール記憶部１５１に記憶されたシステム定義に基づいて、監視間隔に設定された時間が経過したかを判定する（ステップＳ２０１）。監視間隔に設定された時間が経過していないと判定された場合に（ステップＳ２０１：Ｎｏ）、第１タイミング発生部１６１は、再度ステップＳ２０１を実行する。

　監視間隔に設定された時間が経過したと判定された場合に（ステップＳ２０１：Ｙｅｓ）、第１タイミング発生部１６１は、システム判定条件に一致するシステムのウィンドウがデスクトップ上で最前面に表示されているかを判定する（ステップＳ２０２）。システム判定条件に一致するシステムのウィンドウがデスクトップ上で最前面に表示されていないと判定された場合に（ステップＳ２０２：Ｎｏ）、処理手順は、ステップＳ２０１に戻る。

　システム判定条件に一致するシステムのウィンドウがデスクトップ上で最前面に表示されていると判定された場合に（ステップＳ２０２：Ｙｅｓ）、第１タイミング発生部１６１は、システム定義に含まれる全ての追加ＵＩ設定を入力として使用して、基点探索部１６２を呼び出す（ステップＳ２０３）。言い換えると、第１タイミング発生部１６１は、基点探索部１６２に、基点ＵＩを探索するよう指示する。これにより、基点探索部１６２は、現時点が既存システムの基点ＵＩを探索するタイミングであるかを判定することができる。

　図１２は、実施形態に係る端末装置１００によって実行される、既存システムの基点ＵＩを探索するための処理の一例を示すフローチャートである。端末装置１００の基点探索部１６２は、既存システムの基点ＵＩの探索を、ルール記憶部１５１に記憶された追加ＵＩ設定ごとに実行する。

　図１２に示されるように、はじめに、基点探索部１６２は、基点ＵＩの探索の指示があったかを判定する（ステップＳ３０１）。基点ＵＩの探索の指示がなかったと判定された場合に（ステップＳ３０１：Ｎｏ）、基点探索部１６２は、既存システムの基点ＵＩを探索するタイミングまで待機する。そして、基点探索部１６２は、再度ステップＳ３０１を実行する。

　基点ＵＩの探索の指示があったと判定された場合に（ステップＳ３０１：Ｙｅｓ）、基点探索部１６２は、全ての追加ＵＩ設定の処理が終わったかを判定する（ステップＳ３０２）。全ての追加ＵＩ設定の処理が終わったと判定された場合に（ステップＳ３０２：Ｙｅｓ）、処理手順は、終了する。

　全ての追加ＵＩ設定の処理が終わってないと判定された場合に（ステップＳ３０２：Ｎｏ）、基点探索部１６２は、ルール記憶部１５１から、基点定義を取得する（ステップＳ３０３）。

　次いで、基点探索部１６２は、取得された基点定義に基づいて、基点ＵＩを探索する（ステップＳ３０４）。基点探索部１６２は、基点ＵＩの探索を、基点定義ごとに、並列で実行する。

　一例では、基点探索部１６２は、Accessibility　ＡＰＩを用いて、既存システムのＵＩのプロパティ値を逐次取得し、基点定義のプロパティ値と一致するＵＩ（基点ＵＩ)を探索する（ステップＳ３０４Ａ－１）。

　別の例では、基点探索部１６２は、対象の既存システムのキャプチャ画像を取得する（ステップＳ３０４Ｂ－１）。次いで、基点探索部１６２は、既存システムのキャプチャ画像中から、基点定義のキャプチャ画像と一致するＵＩ（基点ＵＩ）を探索する（ステップＳ３０４Ｂ－２）。

　次いで、基点探索部１６２は、基点ＵＩが見つかったかを判定する（ステップＳ３０５）。基点ＵＩが見つからなかったと判定された場合に（ステップＳ３０５：Ｎｏ）、該当する追加ＵＩ設定と判定結果（不一致）とを入力として使用して、表示制御部１６３を呼び出す。そして、基点探索部１６２は、再度ステップＳ３０２を実行する。

　基点ＵＩが見つかったと判定された場合に（ステップＳ３０５：Ｙｅｓ）、基点探索部１６２は、表示条件があるかを判定する（ステップＳ３０７）。

　表示条件があると判定された場合に（ステップＳ３０７：Ｙｅｓ）、基点探索部１６２は、基点ＵＩの値が表示条件と一致するかを判定する（ステップＳ３０８）。言い換えると、基点探索部１６２が表示条件を取得できた場合に、基点探索部１６２は、ステップＳ３０８を実行する。基点探索部１６２は、例えば、データ流通部１６４に関して上述した情報処理（値の取得）によって、基点ＵＩの値を取得することができる。

　基点ＵＩの値が表示条件と一致すると判定された場合に（ステップＳ３０８：Ｙｅｓ）、基点探索部１６２は、基点ＵＩの座標およびサイズを取得する（ステップＳ３０９）。基点ＵＩの値が表示条件と一致しないと判定された場合に（ステップＳ３０８：Ｎｏ）、処理手順は、ステップＳ３０６に移行する。

　表示条件がないと判定された場合に（ステップＳ３０７：Ｎｏ）、処理手順は、ステップＳ３０９に移行する。言い換えると、基点探索部１６２が表示条件を取得できなかった場合に、基点探索部１６２は、ステップＳ３０９を実行する。

　次いで、基点探索部１６２は、第２タイミング発生部１６５に基点ＵＩを監視対象として追加する（ステップＳ３１０）。

　次いで、基点探索部１６２は、該当する追加ＵＩ設定、判定結果（一致）、基点ＵＩの座標および基点ＵＩのサイズを入力として使用して、表示制御部１６３を呼び出す（ステップＳ３１１）。そして、基点探索部１６２は、再度ステップＳ３０２を実行する。

　図１３は、実施形態に係る端末装置１００によって実行される、追加のＵＩの表示を制御するための処理の一例を示すフローチャートである。端末装置１００の表示制御部１６３は、追加ＵＩ設定、基点探索部１６２の判定結果（一致または不一致）、ならびに基点ＵＩの座標およびサイズに基づいて、追加のＵＩの表示の制御を実行する。

　図１３に示されるように、はじめに、表示制御部１６３は、基点ＵＩの値が表示条件と一致するかを判定する（ステップＳ４０１）。基点ＵＩの値が表示条件と一致しないと判定された場合に（ステップＳ４０１：Ｎｏ）、表示制御部１６３は、追加のＵＩが透明なＷｅｂブラウザ上に既に表示されているかを判定する（ステップＳ４０２）。追加のＵＩが透明なＷｅｂブラウザ上にまだ表示されていないと判定された場合に（ステップＳ４０２：Ｎｏ）、処理手順は、終了する。

　追加のＵＩが透明なＷｅｂブラウザ上に既に表示されていると判定された場合に（ステップＳ４０２：Ｙｅｓ）、表示制御部１６３は、追加のＵＩを非表示にする（ステップＳ４０３）。

　ステップＳ４０１において、基点ＵＩの値が表示条件と一致すると判定された場合に（ステップＳ４０１：Ｙｅｓ）、表示制御部１６３は、追加ＵＩ設定の外観定義に設定された相対座標、座標およびサイズから、透明なＷｅｂブラウザ上での追加のＵＩの表示位置を計算する（ステップＳ４０４）。

　次いで、表示制御部１６３は、追加のＵＩが透明なＷｅｂブラウザ上に既に表示されているかを判定する（ステップＳ４０５）。追加のＵＩが透明なＷｅｂブラウザ上に既に表示されていると判定された場合に（ステップＳ４０５：Ｙｅｓ）、表示制御部１６３は、追加のＵＩの表示位置を計算された表示位置に修正する（ステップＳ４０６）。

　追加のＵＩが透明なＷｅｂブラウザ上にまだ表示されていないと判定された場合に（ステップＳ４０５：Ｎｏ）、表示制御部１６３は、ルール記憶部１５１に記憶された外観定義に設定されたＨＴＭＬ情報に従って、追加のＵＩを計算された表示位置に新規に表示する（ステップＳ４０７）。

　図１４は、実施形態に係る端末装置１００によって実行される、既存システムの変化を監視するための処理の一例を示すフローチャートである。端末装置１００の第２タイミング発生部１６５は、既存システムの変化の監視するステップＳ５００を、ルール記憶部１５１に記憶されたシステム定義ごとに、並列で実行する。

　一例では、第２タイミング発生部１６５は、監視イベントに設定されたイベントが発生したかを判定する（ステップＳ５００Ａ－１）。監視イベントに設定されたイベントが発生しなかったと判定された場合に（ステップＳ５００Ａ－１：Ｎｏ）、第２タイミング発生部１６５は、再度ステップＳ５００Ａ－１を実行する。

　監視イベントに設定されたイベントが発生したと判定された場合に（ステップＳ５００Ａ－１：Ｙｅｓ）、第２タイミング発生部１６５は、イベントに対応した処理を実行する（ステップＳ５００Ａ－２）。そして、第２タイミング発生部１６５は、再度ステップＳ５００Ａ－１を実行する。

　別の例では、第２タイミング発生部１６５は、マウスホイールイベントが発生したかを判定する（ステップＳ５００Ｂ－１）。マウスホイールイベントが発生しなかったと判定された場合に（ステップＳ５００Ｂ－１：Ｎｏ）、第２タイミング発生部１６５は、再度ステップＳ５００Ｂ－１を実行する。

　マウスホイールイベントが発生したと判定された場合に（ステップＳ５００Ｂ－１：Ｙｅｓ）、第２タイミング発生部１６５は、システム定義に含まれる全ての追加ＵＩ設定を入力として使用して、基点探索部１６２を呼び出す（ステップＳ５００Ｂ－２）。言い換えると、第２タイミング発生部１６５は、基点探索部１６２に、基点ＵＩを探索するよう指示する。これにより、基点探索部１６２は、現時点が追加のＵＩを再表示するタイミングであるかを判定することができる。そして、第２タイミング発生部１６５は、再度ステップＳ５００Ｂ－１を実行する。

　さらに別の例では、第２タイミング発生部１６５は、ウィンドウサイズ変更イベントが発生したかを判定する（ステップＳ５００Ｃ－１）。ウィンドウサイズ変更イベントが発生しなかったと判定された場合に（ステップＳ５００Ｃ－１：Ｎｏ）、第２タイミング発生部１６５は、再度ステップＳ５００Ｃ－１を実行する。

　ウィンドウサイズ変更イベントが発生したと判定された場合に（ステップＳ５００Ｃ－１：Ｙｅｓ）、第２タイミング発生部１６５は、対象の既存システムのウィンドウサイズを取得する（ステップＳ５００Ｃ－２）。

　次いで、第２タイミング発生部１６５は、対応する透明なＷｅｂブラウザのサイズを取得されたウィンドウサイズに変更する（ステップＳ５００Ｃ－３）。

　次いで、第２タイミング発生部１６５は、システム定義に含まれる全ての追加ＵＩ設定を入力として使用して、基点探索部１６２を呼び出す（ステップＳ５００Ｃ－４）。その結果、基点探索部１６２は、現時点が追加のＵＩを再表示するタイミングであるかを判定することができる。そして、第２タイミング発生部１６５は、再度ステップＳ５００Ｃ－１を実行する。

　さらに別の例では、第２タイミング発生部１６５は、更新イベントが発生したかを判定する（ステップＳ５００Ｄ－１）。更新イベントが発生しなかったと判定された場合に（ステップＳ５００Ｄ－１：Ｎｏ）、第２タイミング発生部１６５は、再度ステップＳ５００Ｄ－１を実行する。

　更新イベントが発生したと判定された場合に（ステップＳ５００Ｄ－１：Ｙｅｓ）、第２タイミング発生部１６５は、対応する透明なＷｅｂブラウザに表示されている追加のＵＩをすべて削除する（ステップＳ５００Ｄ－２）。

　次いで、第２タイミング発生部１６５は、システム定義に含まれる全ての追加ＵＩ設定を入力として使用して、基点探索部１６２を呼び出す（ステップＳ５００Ｄ－３）。その結果、基点探索部１６２は、現時点が追加のＵＩを再表示するタイミングであるかを判定することができる。そして、第２タイミング発生部１６５は、再度ステップＳ５００Ｄ－１を実行する。

　さらに別の例では、第２タイミング発生部１６５は、マウスクリックイベントまたはフォーカス変更イベントが発生したかを判定する（ステップＳ５００Ｅ－１）。マウスクリックイベントおよびフォーカス変更イベントが発生しなかったと判定された場合に（ステップＳ５００Ｅ－１：Ｎｏ）、第２タイミング発生部１６５は、再度ステップＳ５００Ｅ－１を実行する。

　マウスクリックイベントまたはフォーカス変更イベントが発生したと判定された場合に（ステップＳ５００Ｅ－１：Ｙｅｓ）、第２タイミング発生部１６５は、該当するイベントが発生したＵＩを特定する（ステップＳ５００Ｅ－２）。

　次いで、第２タイミング発生部１６５は、特定されたＵＩが監視対象として登録された基点ＵＩと一致するかを判定する（ステップＳ５００Ｅ－３）。特定されたＵＩが監視対象として登録された基点ＵＩと一致しないと判定された場合に（ステップＳ５００Ｅ－３：Ｎｏ）、第２タイミング発生部１６５は、再度ステップＳ５００Ｅ－１を実行する。

　特定されたＵＩが監視対象として登録された基点ＵＩと一致すると判定された場合に（ステップＳ５００Ｅ－３：Ｙｅｓ）、第２タイミング発生部１６５は、基点ＵＩに対応する基点定義を含む追加ＵＩ設定を入力として使用して、基点探索部１６２を呼び出す（ステップＳ５００Ｅ－４）。その結果、基点探索部１６２は、現時点が追加のＵＩを再表示するタイミングであるかを判定することができる。そして、第２タイミング発生部１６５は、再度ステップＳ５００Ｅ－１を実行する。

　図１５は、実施形態に係る端末装置１００によって実行される、既存のＵＩと追加のＵＩとの間でデータを流通するための処理の一例を示すフローチャートである。端末装置１００のデータ流通部１６４は、既存のＵＩと追加のＵＩとの間でデータを流通するステップＳ６００を、ルール記憶部１５１に記憶された動作定義によって示されるＵＩの振る舞いごとに、並列で実行する。

　値の取得に関しては、データ流通部１６４は、既存システムのＵＩがAccessibility　ＡＰＩに対応しているかを判定する（ステップＳ６００Ａ－１）。

　既存システムのＵＩがAccessibility　ＡＰＩに対応していると判定された場合に（ステップＳ６００Ａ－１：Ｙｅｓ）、データ流通部１６４は、Accessibility　ＡＰＩを用いて、動作定義で指定された既存システムのＵＩに表示されている値を取得する（ステップＳ６００Ａ－２）。

　次いで、データ流通部１６４は、取得された値を必要に応じて加工して変換し、動作定義で指定された透明なＷｅｂブラウザに表示された追加のＵＩに、取得された値を反映させる（ステップＳ６００Ａ－３）。

　ステップＳ６００Ａ－１において、既存システムのＵＩがAccessibility　ＡＰＩに対応していないと判定された場合に（ステップＳ６００Ａ－１：Ｎｏ）、データ流通部１６４は、動作定義で指定された既存システムのＵＩにフォーカスをあてる（ステップＳ６００Ａ－４）。

　次いで、データ流通部１６４は、キーボードによるコピー操作（例えば、Ctrl-A、Ctrl-C等）をソフトウェアから実行する（ステップＳ６００Ａ－５）。すなわち、人間は、キーボードを操作しない。

　次いで、データ流通部１６４は、クリップボード記憶部１５２から、クリップボードの値を取得する（ステップＳ６００Ａ－６）。そして、データ流通部１６４は、ステップＳ６００Ａ－３を実行する。

　値の設定に関しては、データ流通部１６４は、動作定義で指定された透明なＷｅｂブラウザに表示された追加のＵＩに表示されている値を取得する（ステップＳ６００Ｂ－１）。

　次いで、データ流通部１６４は、既存システムのＵＩがAccessibility　ＡＰＩに対応しているかを判定する（ステップＳ６００Ｂ－２）。

　既存システムのＵＩがAccessibility　ＡＰＩに対応していると判定された場合に（ステップＳ６００Ｂ－２：Ｙｅｓ）、データ流通部１６４は、Accessibility　ＡＰＩを用いて、動作定義で指定された既存システムのＵＩに、取得された値を反映させる（ステップＳ６００Ｂ－３）。

　既存システムのＵＩがAccessibility　ＡＰＩに対応していないと判定された場合に（ステップＳ６００Ｂ－２：Ｎｏ）、データ流通部１６４は、動作定義で指定された既存システムのＵＩにフォーカスをあてる（ステップＳ６００Ｂ－４）。

　次いで、データ流通部１６４は、クリップボードに取得された値を設定する（ステップＳ６００Ｂ－５）。

　次いで、データ流通部１６４は、キーボードによるペースト操作（例えば、Ctrl-V等）をソフトウェアから実行する（ステップＳ６００Ｂ－６）。すなわち、人間は、キーボードを操作しない。

　クリック操作に関しては、データ流通部１６４は、既存システムのＵＩがAccessibility　ＡＰＩに対応しているかを判定する（ステップＳ６００Ｃ－１）。

　既存システムのＵＩがAccessibility　ＡＰＩに対応していると判定された場合に（ステップＳ６００Ｃ－１：Ｙｅｓ）、データ流通部１６４は、Accessibility　ＡＰＩを用いて、動作定義で指定された既存システムのＵＩにクリック操作を反映させる（ステップＳ６００Ｃ－２）。

　既存システムのＵＩがAccessibility　ＡＰＩに対応していないと判定された場合に（ステップＳ６００Ｃ－１：Ｎｏ）、データ流通部１６４は、一時的に透明なＷｅｂブラウザ全体を最小化する（ステップＳ６００Ｃ－３）。

　次いで、データ流通部１６４は、既存システムのＵＩが表示されている座標においてクリックイベントを発生させる（ステップＳ６００Ｃ－４）。　

〔５．効果〕
　上述してきたように、実施形態に係るユーザインタフェース拡張システム１は、基点探索部１６２と、表示制御部１６３とを有する。

　実施形態に係るユーザインタフェース拡張システム１において、基点探索部１６２は、システムの画面に追加される追加のユーザインタフェース（ＵＩ）の表示の基点となる基点ＵＩを、このシステムの画面から探索する。また、実施形態に係るユーザインタフェース拡張システム１において、表示制御部１６３は、背景が透明な新たな画面を、システムの画面と重ねて表示し、この新たな画面において、基点ＵＩに基づく位置に追加のＵＩを表示する。

　これにより、実施形態に係るユーザインタフェース拡張システム１は、ユーザインタフェース拡張を広範なシステムに適用することができる。

　また、実施形態に係るユーザインタフェース拡張システム１において、システムから独立した新たな画面を、システムの画面と重ねて表示する。

　これにより、実施形態に係るユーザインタフェース拡張システム１は、システムの実装によらずに適用可能なユーザインタフェース拡張を提供することができる。

　また、実施形態に係るユーザインタフェース拡張システム１において、基点探索部１６２は、アクセシビリティＡＰＩで利用される基点ＵＩのプロパティ値又はシステムの画面のキャプチャ画像に基づいて、基点ＵＩを探索する。

　これにより、実施形態に係るユーザインタフェース拡張システム１は、ＤＯＭツリーを持たないシステムの画面から、基点ＵＩを探索することができる。

　また、実施形態に係るユーザインタフェース拡張システム１は、アクセシビリティＡＰＩ又は仮想的なキーボード操作を用いて、システムの画面の既存のＵＩと追加のＵＩとの間でデータを流通するデータ流通部１６４を有する。

　これにより、実施形態に係るユーザインタフェース拡張システム１は、ＤＯＭツリーを持たないシステムの画面のＵＩに、追加のＵＩの内容を反映させることができる。

　また、実施形態に係るユーザインタフェース拡張システム１は、システムを監視し、システムの画面が視認可能に表示されているかに基づいて、システムの画面から基点ＵＩを探索する第１のタイミングを決定する第１タイミング発生部１６１を有する。また、実施形態に係るユーザインタフェース拡張システム１において、基点探索部１６２は、第１タイミング発生部１６１によって決定された第１のタイミングに基づいて、基点ＵＩを探索する。

　これにより、実施形態に係るユーザインタフェース拡張システム１は、適切なタイミングで基点ＵＩを探索することができる。

　また、実施形態に係るユーザインタフェース拡張システム１は、システムの変化を監視し、所定のイベントがシステムの画面で発生したかに基づいて、表示制御部１６３によって表示された追加のＵＩを再表示する第２のタイミングを決定する第２タイミング発生部１６５を有する。

　これにより、実施形態に係るユーザインタフェース拡張システム１は、適切なタイミングで追加のＵＩを再表示することができる。

〔６．他の実施形態〕
　上述の実施形態に係るユーザインタフェース拡張システム１は、上述の実施形態以外にも、種々の異なる形態で実施されてよい。そこで、以下では、上記のユーザインタフェース拡張システム１の他の実施形態について説明する。

〔６－１．端末装置によるＵＩ拡張処理の実行主体〕
　コンテンツ提供装置２００は、上述の実施形態において端末装置１００によって実行された処理の一部を実行してもよい。例えば、コンテンツ提供装置２００は、第１タイミング発生部１６１、基点探索部１６２および第２タイミング発生部１６５に関して上述した情報処理の全部または一部を行ってもよい。

　例えば、既存システム１４０は、コンテンツ提供装置２００にインストールされていてもよい。この場合、コンテンツ提供装置２００は、第１タイミング発生部１６１、基点探索部１６２および第２タイミング発生部１６５に関して上述した情報処理を行ってもよい。ただし、既存システム１４０のＵＩは、端末装置１００に存在するものとする。端末装置１００は、このＵＩを介して、表示制御部１６３およびデータ流通部１６４に関して上述した情報処理を行うことができる。

　図４を参照して上述したように、ユーザインタフェース拡張システム１は、端末装置１００と、コンテンツ提供装置２００とを含む。コンテンツ提供装置２００が、第１タイミング発生部１６１、基点探索部１６２および第２タイミング発生部１６５に関して上述した情報処理の一部を分担してもよい。

〔７．その他〕
　また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の一部を手動的に行うこともできる。あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

　また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

　例えば、図４に示した記憶部１５０の一部又は全部は、端末装置１００によって保持されるのではなく、ストレージサーバ等に保持されてもよい。この場合、端末装置１００は、ストレージサーバにアクセスすることで、表示条件等の各種情報を取得する。

〔８．ハードウェア構成〕
　図１６は、ハードウェア構成の一例を示す図である。上述してきた実施形態に係る端末装置１００やコンテンツ提供装置２００は、例えば図１６に示すような構成のコンピュータ１０００によって実現される。

　図１６は、プログラムが実行されることにより、端末装置１００やコンテンツ提供装置２００が実現されるコンピュータの一例を示している。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。

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

　ハードディスクドライブ１０９０は、例えば、ＯＳ（Operating　System）１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、端末装置１００やコンテンツ提供装置２００の各処理を規定するプログラムは、コンピュータ１０００により実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、端末装置１００やコンテンツ提供装置２００における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤ（Solid　State　Drive）により代替されてもよい。

　また、上述した実施の形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。

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

　以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、本発明を特定の例に限定するものではない。本明細書に記載された特徴は、発明を実施するための形態の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で実施されることが可能である。

　また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、表示制御部は、表示制御手段や表示制御回路に読み替えることができる。

　　　１　ユーザインタフェース拡張システム
　１００　端末装置
　１１０　通信部
　１２０　入力部
　１３０　出力部
　１４０　既存システム
　１５０　記憶部
　１５１　ルール記憶部
　１５２　クリップボード記憶部
　１６０　制御部
　１６１　第１タイミング発生部
　１６２　基点探索部
　１６３　表示制御部
　１６４　データ流通部
　１６５　第２タイミング発生部
　２００　コンテンツ提供装置

Claims (8)

1. 　システムの画面に追加される追加のユーザインタフェース（ＵＩ）の表示の基点となる基点ＵＩを、当該システムの画面から探索する基点探索部と、
   　背景が透明な新たな画面を、前記システムの画面と重ねて表示し、当該新たな画面において、前記基点ＵＩに基づく位置に前記追加のＵＩを表示する表示制御部と
   　を備えることを特徴とするユーザインタフェース拡張システム。
2. 　前記表示制御部は、前記システムから独立した前記新たな画面を、前記システムの画面と重ねて表示する
   　ことを特徴とする請求項１に記載のユーザインタフェース拡張システム。
3. 　前記基点探索部は、アクセシビリティＡＰＩで利用される前記基点ＵＩのプロパティ値又は前記システムの画面のキャプチャ画像に基づいて、前記基点ＵＩを探索する
   　ことを特徴とする請求項１又は２に記載のユーザインタフェース拡張システム。
4. 　アクセシビリティＡＰＩ又は仮想的なキーボード操作を用いて、前記システムの画面の既存のＵＩと前記追加のＵＩとの間でデータを流通するデータ流通部をさらに備える
   　ことを特徴とする請求項１～３のうちいずれか１つに記載のユーザインタフェース拡張システム。
5. 　前記システムを監視し、前記システムの画面が視認可能に表示されているかに基づいて、前記システムの画面から前記基点ＵＩを探索する第１のタイミングを決定する第１タイミング発生部をさらに備え、
   　前記基点探索部は、第１タイミング発生部によって決定された第１のタイミングに基づいて、前記基点ＵＩを探索する
   　ことを特徴とする請求項１～４のうちいずれか１つに記載のユーザインタフェース拡張システム。
6. 　前記システムの変化を監視し、所定のイベントが前記システムの画面で発生したかに基づいて、前記表示制御部によって表示された追加のＵＩを再表示する第２のタイミングを決定する第２タイミング発生部をさらに備える
   　ことを特徴とする請求項１～５のうちいずれか１つに記載のユーザインタフェース拡張システム。
7. 　コンピュータが実行するユーザインタフェース拡張方法であって、
   　システムの画面に追加される追加のユーザインタフェース（ＵＩ）の表示の基点となる基点ＵＩを、当該システムの画面から探索する基点探索工程と、
   　背景が透明な新たな画面を、前記システムの画面と重ねて表示し、当該新たな画面において、前記基点ＵＩに基づく位置に前記追加のＵＩを表示する表示制御工程と
   　を含むことを特徴とするユーザインタフェース拡張方法。
8. 　システムの画面に追加される追加のユーザインタフェース（ＵＩ）の表示の基点となる基点ＵＩを、当該システムの画面から探索する基点探索手順と、
   　背景が透明な新たな画面を、前記システムの画面と重ねて表示し、当該新たな画面において、前記基点ＵＩに基づく位置に前記追加のＵＩを表示する表示制御手順と
   　をコンピュータに実行させることを特徴とするユーザインタフェース拡張プログラム。

Images