IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日本電信電話株式会社の特許一覧

特許7563480ユーザインタフェース拡張システム、ユーザインタフェース拡張方法及びユーザインタフェース拡張プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-09-30
(45)【発行日】2024-10-08
(54)【発明の名称】ユーザインタフェース拡張システム、ユーザインタフェース拡張方法及びユーザインタフェース拡張プログラム
(51)【国際特許分類】
   G06F 9/451 20180101AFI20241001BHJP
【FI】
G06F9/451
【請求項の数】 7
(21)【出願番号】P 2022564975
(86)(22)【出願日】2020-11-27
(86)【国際出願番号】 JP2020044397
(87)【国際公開番号】W WO2022113315
(87)【国際公開日】2022-06-02
【審査請求日】2023-03-23
(73)【特許権者】
【識別番号】000004226
【氏名又は名称】日本電信電話株式会社
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】小矢 英毅
(72)【発明者】
【氏名】小宮山 真実
(72)【発明者】
【氏名】片岡 明
(72)【発明者】
【氏名】土川 公雄
【審査官】大倉 崚吾
(56)【参考文献】
【文献】特開2017-072872(JP,A)
【文献】特開2006-350490(JP,A)
【文献】特開2015-035120(JP,A)
【文献】特開2020-074096(JP,A)
【文献】米国特許出願公開第2009/0217182(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 9/451
G06F 3/048-3/04895
(57)【特許請求の範囲】
【請求項1】
第1のアプリケーションのシステムのウィンドウに追加される追加のユーザインタフェース(UI)の表示の基点となる基点UIを、当該第1のアプリケーションのシステムのウィンドウから探索する基点探索部と、
第2のアプリケーションの背景が透明な新たなウィンドウを、前記第1のアプリケーションのシステムのウィンドウと重ねて表示し、当該第2のアプリケーションの透明な背景において、前記基点UIに基づく位置に前記追加のUIを表示する表示制御部であって、前記第2のアプリケーションは、前記第1のアプリケーションから、動作上独立している、表示制御部と
を備えることを特徴とするユーザインタフェース拡張システム。
【請求項2】
前記基点探索部は、アクセシビリティAPIで利用される前記基点UIのプロパティ値又は前記システムのウィンドウのキャプチャ画像に基づいて、前記基点UIを探索する
ことを特徴とする請求項1に記載のユーザインタフェース拡張システム。
【請求項3】
アクセシビリティAPI又は仮想的なキーボード操作を用いて、前記システムのウィンドウの既存のUIと前記追加のUIとの間でデータを流通するデータ流通部をさらに備える
ことを特徴とする請求項1又は2に記載のユーザインタフェース拡張システム。
【請求項4】
前記システムを監視し、前記システムのウィンドウが視認可能に表示されているかに基づいて、前記システムのウィンドウから前記基点UIを探索する第1のタイミングを決定する第1タイミング発生部をさらに備え、
前記基点探索部は、第1タイミング発生部によって決定された第1のタイミングに基づいて、前記基点UIを探索する
ことを特徴とする請求項1~3のうちいずれか1つに記載のユーザインタフェース拡張システム。
【請求項5】
前記システムの変化を監視し、所定のイベントが前記システムのウィンドウで発生したかに基づいて、前記表示制御部によって表示された追加のUIを再表示する第2のタイミングを決定する第2タイミング発生部をさらに備える
ことを特徴とする請求項1~4のうちいずれか1つに記載のユーザインタフェース拡張システム。
【請求項6】
コンピュータが実行するユーザインタフェース拡張方法であって、
第1のアプリケーションのシステムのウィンドウに追加される追加のユーザインタフェース(UI)の表示の基点となる基点UIを、当該第1のアプリケーションのシステムのウィンドウから探索する基点探索工程と、
第2のアプリケーションの背景が透明な新たなウィンドウを、前記第1のアプリケーションのシステムのウィンドウと重ねて表示し、当該第2のアプリケーションの透明な背景において、前記基点UIに基づく位置に前記追加のUIを表示する表示制御工程であって、前記第2のアプリケーションは、前記第1のアプリケーションから、動作上独立している、表示制御工程と
を含むことを特徴とするユーザインタフェース拡張方法。
【請求項7】
第1のアプリケーションのシステムのウィンドウに追加される追加のユーザインタフェース(UI)の表示の基点となる基点UIを、当該第1のアプリケーションのシステムのウィンドウから探索する基点探索手順と、
第2のアプリケーションの背景が透明な新たなウィンドウを、前記第1のアプリケーションのシステムのウィンドウと重ねて表示し、当該第2のアプリケーションの透明な背景において、前記基点UIに基づく位置に前記追加のUIを表示する表示制御手順であって、前記第2のアプリケーションは、前記第1のアプリケーションから、動作上独立している、表示制御手順と
をコンピュータに実行させることを特徴とするユーザインタフェース拡張プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ユーザインタフェース拡張システム、ユーザインタフェース拡張方法及びユーザインタフェース拡張プログラムに関する。
【背景技術】
【0002】
従来、ユーザインタフェース(UI)拡張技術が提案されている。UI拡張技術は、既存システムの画面上に、追加のUIを表示し、システム操作を改善するものである。
【0003】
従来のUI拡張は、Webシステムを対象としている。例えば、従来のUI拡張は、WebシステムのHTTP(Hypertext Transfer Protocol)レスポンスまたはWebブラウザに描画されたDOM(Document Object Model)に対して、プロキシサーバ、ブラウザのアドオンまたはプロセス間通信等の手法を用いる。これにより、従来のUI拡張は、Webシステムに、HTML(Hyper Text Markup Language)やJavaScript(登録商標)を挿入し、それによって、追加のUIの表示を可能にしている。
【先行技術文献】
【特許文献】
【0004】
【文献】特開2018-5344号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、従来のUI拡張では、ユーザインタフェース拡張を広範なシステムに適用することが難しい。例えば、アーキテクチャの制約により、従来のUI拡張は、Webシステムの画面以外の画面に適用できない場合がある。
【0006】
本願は、上記に鑑みてなされたものであって、ユーザインタフェース拡張を広範なシステムに適用することを目的とする。
【課題を解決するための手段】
【0007】
本開示の実施形態に係るユーザインタフェース拡張システムは、システムの画面に追加される追加のユーザインタフェース(UI)の表示の基点となる基点UIを、当該システムの画面から探索する基点探索部と、背景が透明な新たな画面を、前記システムの画面と重ねて表示し、当該新たな画面において、前記基点UIに基づく位置に前記追加のUIを表示する表示制御部とを備える。
【発明の効果】
【0008】
実施形態の一態様によれば、ユーザインタフェース拡張を広範なシステムに適用することができる。
【図面の簡単な説明】
【0009】
図1図1は、従来のUI拡張の一例を示す説明図である。
図2図2は、実装例に係るUI拡張の一例を示す説明図である。
図3A図3Aは、追加のUIの表示制御の一例を示す説明図である。
図3B図3Bは、追加のUIの表示制御の一例を示す説明図である。
図3C図3Cは、追加のUIの表示制御の一例を示す説明図である。
図4図4は、実施形態に係るユーザインタフェース拡張システムの一例を示す図である。
図5図5は、実施形態に係るルール記憶部の一例を示す図である。
図6図6は、追加のUIの表示の基点となる基点UIを探索する基点探索処理の一例を示す説明図である。
図7図7は、追加のUIの表示を制御する表示制御処理の一例を示す説明図である。
図8図8は、既存のUIと追加のUIとの間でデータを流通するデータ流通処理の一例を示す説明図である。
図9A図9Aは、追加のUIを再表示するタイミングを発生させるタイミング発生処理一例を示す説明図である。
図9B図9Bは、追加のUIを再表示するタイミングを発生させるタイミング発生処理一例を示す説明図である。
図10図10は、実施形態に係る端末装置によって実行される、既存システムの画面のUIを拡張するための処理の一例を示すフローチャートである。
図11図11は、実施形態に係る端末装置によって実行される、既存システムを監視するための処理の一例を示すフローチャートである。
図12図12は、実施形態に係る端末装置によって実行される、既存システムの基点UIを探索するための処理の一例を示すフローチャートである。
図13図13は、実施形態に係る端末装置によって実行される、追加のUIの表示を制御するための処理の一例を示すフローチャートである。
図14図14は、実施形態に係る端末装置によって実行される、既存システムの変化を監視するための処理の一例を示すフローチャートである。
図15図15は、実施形態に係る端末装置によって実行される、既存のUIと追加のUIとの間でデータを流通するための処理の一例を示すフローチャートである。
図16図16は、ハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【0010】
以下、本開示の実施形態について、図面を参照しつつ詳細に説明する。なお、この実施形態により本発明が限定されるものではない。1つまたは複数の実施形態の詳細は、以下の説明および図面に記載される。また、複数の実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、以下の1つまたは複数の実施形態において同一の部位には同一の符号を付し、重複する説明は省略する。
【0011】
〔1.概要〕
本節では、本明細書に記載されるいくつかの実装形態の概要について説明する。なお、この概要は、読者の便宜のために提供されるものであって、本発明や、以下の節で説明される実施形態を限定することを意図するものではない。
【0012】
従来、Webシステムを対象としたUI拡張が提案されている。従来のUI拡張は、Webブラウザに描画されたDOMツリーに対し、HTMLを挿入することで、追加のUIを表示する。従来のUI拡張では、既存のUIおよび追加のUIの両方が、同じWebブラウザ上のDOMツリー内に存在する。
【0013】
従来のUI拡張では、Webブラウザ上でDOMを操作するJavaScriptを実行することで、既存のUIと追加のUIとの間でデータを流通することができる。データの流通は、例えば、追加のUIに入力された値を、既存のUIに反映させることを含む。しかしながら、上述したような仕組みにより、従来のUI拡張をWebシステム以外のシステムに適用することは難しい。
【0014】
図1は、従来のUI拡張の一例を示す説明図である。図1の例では、画面10は、Webシステムの画面(例えば、既存の業務システムの画面)である。画面10は、既存のUI11を含む。
【0015】
はじめに、従来のUI拡張は、Webシステムの画面10のDOMツリーに追加のHTMLを挿入することで、追加のUI12を表示する。図1の例では、同じWebブラウザ内に、既存のUI11および追加のUI12が存在する。
【0016】
続いて、従来のUI拡張は、DOMツリーを操作するAPIをJavaScriptで実行することで、既存のUI11と追加のUI12の間で、データを流通する(ステップS12)。既存のUI11および追加のUI12は、同じWebブラウザ内に存在する。このため、従来のUI拡張は、Webブラウザで動作するプログラム(JavaScript)でDOMツリーを操作することで、比較的容易にデータを流通することができる。しかしながら、従来のUI拡張は、DOMツリーを操作するため、従来のUI拡張を、Webシステム以外のシステムに適用することは難しい。
【0017】
そこで、実施形態に係るユーザインタフェース拡張システムは、システムの実装によらずに適用可能なUI拡張を提供する。ユーザインタフェース拡張システムは、既存システムの画面と同じサイズの背景が透明なWebブラウザを、この画面の上部でこの画面とは独立して動作させ、このWebブラウザに、追加のUIを表示する。さらに、ユーザインタフェース拡張システムは、Accessibility APIと、画像処理を使用したキーボードエミュレーションとの併用により、追加のUIから完全に独立している既存のUIと追加のUIとの間で、データを流通する。
【0018】
図2は、実装例に係るUI拡張の一例を示す説明図である。図2の例では、画面10は、Webシステム以外のシステムの画面であってもよいし、Webシステムの画面であってもよい。
【0019】
実装例に係るUI拡張では、ユーザインタフェース拡張システムは、背景が透明な独立したWebブラウザ20に、追加のUIを表示する(ステップS21)。Webブラウザ20は、画面10から完全に独立している。すなわち、Webブラウザ20のプロセスは、画面10のプロセスとは異なる。
【0020】
Webブラウザ以外の様々な実装のシステムに対応するために、ユーザインタフェース拡張システムは、Accessibility APIと仮想的なキーボード操作とを組み合わせて、既存のUIと追加のUIの間でデータを流通する(ステップS22)。
【0021】
既存システムのUIがAccessibility APIを利用できる場合には、ユーザインタフェース拡張システムは、Accessibility APIで、既存システムを操作して、追加のUIの内容を、既存のUIに反映させる。
【0022】
既存システムのUIがAccessibility APIを利用できない場合には、ユーザインタフェース拡張システムは、キーボードのコピーペースト操作を仮想的に実行する。具体的は、ユーザインタフェース拡張システムは、追加のUIの内容をコピーして、その内容を既存のUIにペーストし、それによって、追加のUIの内容を既存のUIに反映させる。
【0023】
これにより、ユーザインタフェース拡張システムは、既存の業務システムを改造せずに、業務システムの操作性を飛躍的に改善し、それによって、業務を効率化することができる。さらに、ユーザインタフェース拡張システムは、Webシステム以外の広範なシステムやサービスへのUI拡張の適用を可能にすることができる。
【0024】
〔2.はじめに〕
今日、様々なシステムが、業務に使用されている。業務の実態は日々変化するため、業務の実態に合わせて業務システムをアップデートすることは、重要なことである。例えば、新規メニューが、サービスに追加されたものとする。この例では、もし、業務システムが新規メニューに対応していなければ、業務システムのユーザは、業務システム上で、新規メニューに関する業務を遂行することができない。
【0025】
そこで、業務システムをタイムリーにアップデートするために、UI拡張技術が提案されている。業務システムのUIを拡張するUI拡張技術は、例えば、上述の特許文献1で詳しく議論されている。UI拡張技術は、業務システムの画面に追加されたUIの表示を制御する。
【0026】
図3A図3Bおよび図3Cは、追加のUIの表示制御の一例を示す説明図である。図3A図3Bおよび図3Cでは、追加のUIが、業務システムの画面等の、既存システムの画面に表示される。また、表示の基点となる基点UIが、追加のUIに対して指定される。基点UIは、既存のWebシステムの画面に存在するUIである。この基点UIが画面に表示された場合に、追加のUIは、基点UIからの相対座標に基づいて、画面に表示される。以下では、「基点のUI」を「基点UI」と表記することがある。
【0027】
従来のUI拡張は、既存システムの画面を構成するDOMツリーの末尾に追加のUIを挿入する。従来のUI拡張は、既存のWebシステムの画面を直接改造することの影響を発生させずに、追加のUIを表示することができる。
【0028】
図3Aの例では、既存システムの画面30は、既存のUI31と、基点のUI32を含む。基点のUI32は、既存システムの画面30上に表示される追加のUI31の表示の基点となるUIである。図3Aに示された矢印は、画面のDOMツリーと、画面の見た目との対応を示す。従来のUI拡張は、WebブラウザにレンダリングされたDOMツリーの末尾に、追加のUIのHTMLを挿入することで、追加のUIを表示する。
【0029】
図3Aの例では、追加のUI33が(テキストボックス)が、従来のUI拡張によって表示される。従来のUI拡張は、既存システムの画面30のDOMに、追加のUI33のHTMLを挿入する。しかしながら、Webシステム以外のシステムは、そもそもDOMツリーを持っていない。このため、UI拡張がWebシステム以外のシステムを対象とする場合に、従来のUI拡張は、DOMツリーに追加のUIのHTMLを挿入する手法によって、システムの画面に追加のUIを表示することができない。
【0030】
図3Bの例では、図3Aの場合と同様に、既存システムの画面30は、既存のUI31と、基点のUI32を含む。また、追加のUI33が、既存システムの画面30に表示されている。
【0031】
従来のUI拡張は、追加のUIを表示するかを判定するために、既存のシステム画面に表示されているUIの中から、基点のUIを指定する。そして、基点のUIが表示されている時に、従来のUI拡張は、対応する追加のUIを表示する制御を行う。
【0032】
図3Bの例では、基点のUI32が、追加のUI31に対応する基点のUIである。基点のUI32が表示されていれば、追加のUI33も表示される。基点のUI32が表示されていなければ、追加のUI33も表示されない。
【0033】
上述したように、従来のUI拡張は、Webシステムを対象としている。従来のUI拡張は、DOMツリーを操作するJavaScriptのAPIを呼び出す(ステップS31)。これにより、従来のUI拡張は、基点のUIが存在するかを確認する(ステップS32)。例えば、従来のUI拡張は、idの情報を元に、「document.getElementById(“text01”)」の実行結果を確認することで、基点のUIが存在するかを、簡易に確認することができる。
【0034】
しかしながら、上述したように、Webシステム以外のシステムは、そもそもDOMツリーを持っていない。このため、UI拡張がWebシステム以外のシステムを対象とする場合に、従来のUI拡張は、DOMツリーを操作するAPIを用いて、基点のUIが存在するかを確認することができない。
【0035】
図3Cの例では、既存システムの画面40は、既存のU41と、既存のU42と、追加のUI43とを含む。従来のUI拡張は、既存システムに表示されているUIと、追加のUIとの間で、データを流通する。例えば、追加したUI(プルダウン)の値が選択された場合に、従来のUI拡張は、選択された値に対応する情報を、既存システムのUI(テキストボックス)に反映させる。これにより、従来のUI拡張は、入力の簡易化等のUIの効率化を実現する。
【0036】
従来のUI拡張では、追加のUIおよび既存のUIの両方が、Webブラウザにレンダリングされた同じDOMツリーの中に存在する。このため、従来のUI拡張は、DOMツリーを操作するJavaScriptのAPIを呼び出すことで、データの流通における以下の2つの処理を、簡易に実現することができる(ステップS41)。
【0037】
第1の処理は、追加のUIに対する操作を、システム画面の既存のUIに反映させることである(ステップS42)。第2の処理は、システム画面の既存のUIの情報を、追加のUIに反映させることである(ステップS43)。
【0038】
例えば、従来のUI拡張が、追加のUIの選択に応じて、既存のUIに値を設定する場合には、従来のUI拡張は、以下のようなJavaScriptを実行する。実行されるJavaScriptは、例えば、「if ($(“#ext01”).val()==“パターン1”){$(“text01”).val(“オプション1”);$(“text02”).val(“オプション2”);}」である。
【0039】
しかしながら、上述したように、Webシステム以外のシステムは、そもそもDOMツリーを持っていない。このため、UI拡張がWebシステム以外のシステムを対象とする場合に、従来のUI拡張は、DOMツリーを操作するAPIを用いて、データを流通することができない。
【0040】
上述のように、従来のUI拡張は、DOMツリーの末尾に追加のUIを挿入する。このため、従来のUI拡張では、Webシステム以外のGUIを有するシステムの画面上に追加のUIを表示することが難しい。
【0041】
Webシステム以外のシステムに適用可能なUI拡張を実現するためには、以下の3つの処理が、様々なGUIの実装を有するシステムに必要とされることが考えられる。第1の処理は、システム画面の上に追加のUIを表示する表示処理である。第2の処理は、基点となるUIを特定する特定処理である。第3の処理は、既存のUIと追加のUIとの間でデータを流通する流通処理である。具体的には、第3の処理は、追加のUIに対する操作を、システム画面の既存のUIに反映させる処理や、システム画面の既存のUIの情報を、追加のUIに反映させる処理を含む。
【0042】
そこで、Webシステム以外のシステムにUI拡張を適用するために、実施形態に係るユーザインタフェース拡張システムは、以下に説明される処理を実行する。
【0043】
実施形態に係るユーザインタフェース拡張システムは、システム画面の上に追加のUIを表示する。ユーザインタフェース拡張システムは、背景が透明なWebブラウザを、システムの画面とは独立に、システムの画面の上部で動作させ、この透明なWebブラウザに、追加のUIを表示する。
【0044】
また、ユーザインタフェース拡張システムは、基点となるUIを特定する。例えば、ユーザインタフェース拡張システムは、システムの実装に応じて、以下の2つの方法で、基点となるUIを特定する。第1の方法は、基点となるUIのプロパティ値を用いたAccessibility APIによるUIの特定である。第2の方法は、基点となるUIのキャプチャ画像を用いたパターンマッチ等の、画像処理によるUIの特定である。
【0045】
さらに、ユーザインタフェース拡張システムは、既存のUIと追加のUIとの間でデータを流通する。例えば、ユーザインタフェース拡張システムは、システムの実装に応じて、以下の2つの方法で、データを流通する。第1の方法では、ユーザインタフェース拡張システムは、Accessibility APIを用いて、既存のUIのプロパティを取得および変更し、それによって、データを流通する。第2の方法では、ユーザインタフェース拡張システムは、キーボードのコピー&ペースト操作により、クリップボードを介してデータを流通する。
【0046】
これにより、ユーザインタフェース拡張システムは、Webシステム以外のシステムにUI拡張を適用することができる。ユーザインタフェース拡張システムは、Webシステム以外のシステムのGUIを有するシステムの画面上に、追加のUIを表示することができる。また、ユーザインタフェース拡張システムは、既存のUIと追加のUIとの間で、データを流通することができる。
【0047】
〔3.ユーザインタフェース拡張システムの構成〕
次に、図4を参照して、実施形態に係るユーザインタフェース拡張システムの構成例について説明する。
【0048】
図4は、実施形態に係るユーザインタフェース拡張システム1の一例を示す図である。図4に示されるように、ユーザインタフェース拡張システム1は、端末装置100と、コンテンツ提供装置200とを含む。図4中では図示していないが、ユーザインタフェース拡張システム1は、複数台の端末装置100や、複数台のコンテンツ提供装置200を含んでもよい。
【0049】
ユーザインタフェース拡張システム1において、端末装置100およびコンテンツ提供装置200は、それぞれネットワークNと有線又は無線により接続される。ネットワークNは、例えば、インターネット、WAN(Wide Area Network)、LAN(Local Area Network)等のネットワークである。ユーザインタフェース拡張システム1の構成要素は、ネットワークNを介して互いに通信を行うことができる。
【0050】
〔3-1.構成要素〕
端末装置100は、ユーザインタフェースを拡張するための処理を実行する情報処理装置である。端末装置100は、クライアント装置を含む、任意のタイプの情報処理装置であってもよい。端末装置100の構成例は、次の節で詳述される。
【0051】
コンテンツ提供装置200は、コンテンツ提供者によって利用される情報処理装置である。コンテンツ提供者は、コンテンツを、端末装置100に提供する。「コンテンツ」という用語は、アプリケーションの画面(すなわち、ウィンドウ)やWebページの内容等の、画面に関する各種情報を包含し得る。コンテンツ提供装置200は、サーバを含む、任意のタイプの情報処理装置であってもよい。
【0052】
〔3-2.端末装置の構成〕
次に、端末装置100の構成例について説明する。
【0053】
図4に示されるように、端末装置100は、通信部110と、入力部120と、出力部130と、既存システム140と、記憶部150と、制御部160とを有する。
【0054】
(通信部110)
通信部110は、例えば、NIC(Network Interface Card)等によって実現される。通信部110は、有線または無線によりネットワーク網と接続される。通信部110は、コンテンツ提供装置200に、ネットワークNを介して、通信可能に接続される。通信部110は、コンテンツ提供装置200との間で、ネットワーク網を介して、情報の送受信を行うことができる。
【0055】
(入力部120)
入力部120は、端末装置100のユーザから各種操作を受け付ける入力装置である。例えば、入力部120は、キーボードやマウスや操作キー等によって実現される。
【0056】
(出力部130)
出力部130は、各種情報を表示するための表示装置である。例えば、出力部130は、液晶ディスプレイ、有機EL(Electro Luminescence)ディスプレイ等によって実現される。なお、端末装置100にタッチパネルが採用される場合には、入力部120と出力部130とは一体化される。
【0057】
(既存システム140)
既存システム140は、業務システムや各種アプリケーション等の既存のソフトウェアである。既存システム140は、コンテンツ提供装置200から、コンテンツを受信する。また、既存システム140は、UIを有する。受信されたコンテンツは、このUIを介して、端末装置100のユーザに提供される。
【0058】
図4の例では、既存システム140は、端末装置100にインストールされたソフトウェアとして示されているが、これに限定されるものではない。既存システム140は、コンテンツ提供装置200にインストールされていてもよい。ただし、既存システム140のUIは、端末装置100に存在するものとする。
【0059】
(記憶部150)
記憶部150は、例えば、RAM(Random Access Memory)、フラッシュメモリ(Flash Memory)等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図4に示されるように、記憶部150は、ルール記憶部151と、クリップボード記憶部152とを有する。
【0060】
(ルール記憶部151)
ルール記憶部151は、システム定義に関するルールを記憶する。ルールは、少なくとも1つのシステム定義を含む。
【0061】
図5は、実施形態に係るルール記憶部151の一例を示す図である。図5に示されるように、ルール記憶部151は、複数のシステム定義を含むルールを記憶する。各システム定義は、システム判定条件、環境設定(監視間隔、監視イベント)および少なくとも1つの追加UI設定(基点定義、表示条件、外観定義、動作定義)を含む。
【0062】
システム判定条件は、例えば、プロセス名(例えば、myapplication.exe)やウィンドウタイトル名(例えば、マイアプリケーション)を含む。
【0063】
環境設定は、既存システムの変化を監視するタイミングを示す監視間隔または既存システムの変化として利用されるイベントの一覧を示す監視イベントのうちの少なくとも1つを含む。例えば、環境設定は、例えば、監視間隔(例えば、5秒)や監視イベント(例えば、マウスホイールイベント、ウィンドウサイズ変更イベント)を含む。
【0064】
追加UI設定は、基点定義、表示条件、外観定義または動作定義を含む。例えば、追加UI設定は、1)追加されるUIが表示される際に基点となる既存システムのUIの情報であるキャプチャ画像またはプロパティ値を含む基点定義、2)追加されるUIが表示される条件を示す表示条件、3)追加されるUIの外観を示す外観定義または4)追加されるUIの振る舞いを示す動作定義のうちの少なくとも1つを含む。
【0065】
(クリップボード記憶部152)
クリップボード記憶部152は、クリップボードを記憶する。クリップボードは、後述するデータ流通部164によって使用される。
【0066】
(制御部160)
制御部160は、コントローラ(controller)であり、例えば、CPU(Central Processing Unit)、MPU(Micro Processing Unit)等のプロセッサによって、端末装置100内部の記憶装置に記憶されている各種プログラム(ユーザインタフェース拡張プログラムの一例に相当)がRAM等を作業領域として実行されることにより実現される。また、制御部160は、例えば、ASIC(Application Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)、GPGPU(General Purpose Graphic Processing Unit)等の集積回路により実現されてもよい。
【0067】
制御部160は、図4に示されるように、第1タイミング発生部161と、基点探索部162と、表示制御部163と、データ流通部164と、第2タイミング発生部165とを有し、以下に説明する情報処理の機能や作用を実現又は実行する。端末装置100の1つまたは複数のプロセッサは、端末装置100の1つまたは複数のメモリに記憶された命令を実行することによって、制御部160内の各制御部の機能を実現することができる。なお、制御部160の内部構成は、図4に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。例えば、表示制御部163は、表示制御部163以外の部に関して後述する情報処理の全部または一部を行ってもよい。
【0068】
一例として、制御部160は、端末装置100にインストールされた第1のアプリケーションとして実装される。この例では、上述の既存システム140は、端末装置100にインストールされた第2のアプリケーションとして実装される。
【0069】
(第1タイミング発生部161)
第1タイミング発生部161は、システムの画面から基点UIを探索するタイミングを決定する。例えば、第1タイミング発生部161は、既存システム140を監視する。そして、第1タイミング発生部161は、既存システム140の画面が視認可能に表示されているかに基づいて、既存システム140の画面から基点UIを探索するタイミングを決定する。このように、第1タイミング発生部161は、基点UIを探索するタイミングを調整する。第1タイミング発生部161は、UI Automationやグローバルフック等の手法を用いて、既存システム140を監視することができる。
【0070】
一例として、第1タイミング発生部161は、ルール記憶部151に記憶されたルールの全てのシステム定義から、システム判定条件と環境設定とを取得する。第1タイミング発生部161は、環境設定の監視間隔の時間が経過するごとに、システム判定条件に一致するシステムのウィンドウが、デスクトップ上に最前面で表示されているかを判定する。ウィンドウが最前面に表示されている場合には、システム定義に含まれる全ての追加UI設定を入力として使用して、基点探索部162を呼び出す。
【0071】
(基点探索部162)
基点探索部162は、システムの画面に追加される追加のUIの表示の基点となる基点UIを、このシステムの画面から探索する。例えば、基点探索部162は、ルール記憶部151に記憶されたルールに保存された追加UI設定を入力として使用する。そして、基点探索部162は、第1タイミング発生部161によって指示されたタイミングで、既存システム140の画面から、基点定義に一致するUI(基点UI)を探索する。
【0072】
一例として、基点探索部162は、第1タイミング発生部161によって指示されたタイミングで呼び出される。プロパティ値が基点定義として設定されている場合には、基点探索部162は、Accessibility APIを用いて、基点定義のプロパティ値が一致するUI(基点UI)を探索する。キャプチャ画像が基点定義として設定されている場合には、基点探索部162は、基点定義のキャプチャ画像と、既存システムの画面の現在の表示を示すキャプチャ画像とを、入力として使用する。そして、基点探索部162は、テンプレートマッチング等の任意の画像処理手法によって、基点定義のキャプチャ画像と一致するUI(基点UI)を探索する。
【0073】
基点UIが見つかり、かつ表示条件が基点定義として設定されている場合には、基点探索部162は、データ流通部164に関して後述する情報処理(値の取得)によって、基点UIから値を取得する。そして、基点探索部162は、基点UIの値が表示条件と一致しているかを判定する。
【0074】
基点探索部162は、判定結果として一致または不一致を返却する。判定結果が一致の場合には、基点探索部162は、基点UIの座標とサイズを、判定結果とともに返却する。加えて、基点探索部162は、第2タイミング発生部165に、基点UIを監視対象として追加する。基点UIが見つからなかった場合には、基点探索部162は、判定結果として不一致を返却する。
【0075】
このように、基点探索部162は、Accessibility APIで利用されるUIのプロパティ値や、システム画面のキャプチャ画像の画像処理の結果に基づいて、追加のUIの表示の対象である基点UIを特定する。
【0076】
図6は、追加のUIの表示の基点となる基点UIを探索する基点探索処理の一例を示す説明図である。基点探索部162は、既存システム(例えば、既存システム140)から、基点となるUIを特定する。
【0077】
UI拡張がWebシステムを対象とする場合には、DOMを操作するJavaScriptのAPIを利用して、基点となるUIを簡易に特定できる。しかしながら、UI拡張が任意のシステムを対象とする場合には、UI拡張は、JavaScriptのAPIのような統一的な仕組みを利用することができない。
【0078】
そこで、基点探索部162は、様々なシステムの実装に対応するために、Accessibly APIと、画像処理の併用によって、基点となるUIを特定する。上述のルール記憶部151に記憶されたルールは、基点を特定するための基点定義を保持する。基点探索部162は、Accessibility APIで基点UIを特定するためのプロパティ値または画像処理によって基点UIを特定するためのキャプチャ画像のうちのいずれかを、この基点定義に設定することができる。
【0079】
図6の例では、処理51は、Accessibility APIで基点UIを特定する処理である。基点探索部162は、システムの実装によっては、Accessibility APIを利用することができる。例えば、Windows(登録商標)のWPF(Windows Presentation Foundation)等の実装では、基点探索部162は、UI Automation等を利用することができる。また、Java(登録商標)のSwing等の実装では、基点探索部162は、Java Access Bridge等を利用することができる。基点探索部162がAccessibility APIを利用することができる場合に、基点探索部162は、システム画面を構成する各UIのプロパティ値を取得することができる。
【0080】
基点探索部162は、ルール記憶部151に記憶されたルールの基点定義に、プロパティ値を設定することができる。この場合、基点探索部162は、Accessibility APIによって、対象の既存システムのUIのプロパティ値を、逐次的に取得することができる。基点探索部162は、基点定義のプロパティ値と一致する取得されたプロパティ値が存在するかを判定することで、基点となるUIを特定することができる。
【0081】
図6の例では、処理52は、画像処理によって基点UIを特定する処理である。システムのUIが独自の実装によって構築されている場合に、基点探索部162は、Accessibility APIを利用できない場合がある。そのような場合でも、基点探索部162は、基点定義として、キャプチャ画像を設定することができる。基点探索部162は、システム画面の現在のキャプチャ画像と、基点定義に設定されたキャプチャ画像とを、テンプレートマッチ等の画像処理によって突合することで、基点となるUIを特定することができる。
【0082】
(表示制御部163)
表示制御部163は、背景が透明な新たな画面を、システムの画面と重ねて表示する。そして、表示制御部163は、この新たな画面において、基点UIに基づく位置に追加のUIを表示する。
【0083】
例えば、表示制御部163は、ルール記憶部151に記憶されたルールに保存された追加UI設定と、基点探索部162の探索結果を、入力として使用する。そして、表示制御部163は、そのウィンドウサイズが既存システム140の画面のウィンドウサイズと一致する背景が透明なWebブラウザを、既存システム140の画面の上部に表示する。さらに、表示制御部163は、外観定義に従って、追加のUIをこのWebブラウザに表示する。
【0084】
一例として、表示制御部163は、基点探索部162によって出力された判定結果、基点UIの座標および基点UIのサイズを、入力として使用する。判定結果が一致である場合は、表示制御部163は、基点UIの座標と、外観定義に設定された相対座標とから、追加のUIの表示位置を計算する。
【0085】
対応する追加のUIが、透明なWebブラウザ上に表示されていない場合には、表示制御部163は、外観定義に設定されたHTML情報に従って、追加のUIを計算された表示位置に新規に表示する。対応する追加のUIが既に表示されている場合には、表示制御部163は、追加のUIの現在の表示位置を、計算された表示位置に修正する。
【0086】
判定結果が不一致であり、かつ対応する追加のUIが透明なWebブラウザ上に既に表示されている場合には、表示制御部163は、該当する追加のUIを非表示にする。
【0087】
透明なWebブラウザにおける透明な領域への操作イベントに関しては、透明なWebブラウザは、追加のUIが表示されていない領域で発生した全ての操作イベントを、透明なWebブラウザの下部に表示された既存のシステムに流通してもよい。例えば、透明なWebブラウザは、追加のUIが表示されていない領域について、全ての操作イベントを一切加工せずに、全ての操作イベントを既存のシステムに流通してもよい。
【0088】
このように、表示制御部163は、システムの画面から独立した、背景が透明なWebブラウザを動作させ、そのWebブラウザに追加のUIを表示する。
【0089】
図7は、追加のUIの表示を制御する表示制御処理の一例を示す説明図である。図7の例では、表示制御部163は、システムの画面60の上に、追加のUIを表示する。システムの画面60は、既存システムの画面である。
【0090】
表示制御部163は、背景が透明なWebブラウザ70を、システムの画面60とは独立に、Webブラウザ70の上部で動作させ、透明なWebブラウザ70に、UI71を表示する。なお、システムの画面60は、WindowsのWPFやJavaのSwing等によって実装されてもよい。端末装置100のユーザがシステムの画面60を正面から見ると、UI71は、従来のUI拡張と同じように、UI71がこの元のシステムの画面60に追加されたように見える。
【0091】
(データ流通部164)
データ流通部164は、システムの画面の既存のUIと、追加のUIとの間でデータを流通する。例えば、データ流通部164は、ルール記憶部151に記憶されたルールに保存された追加UI設定を入力として使用する。そして、データ流通部164は、動作定義に従って、表示制御部163によって透明なWebブラウザに表示された追加のUIと、既存システム140に表示されたUIとの間で、それぞれのUIに入力されたまたは表示されたデータを、双方に流通する。
【0092】
一例として、データ流通部164は、ルール記憶部151に記憶されたルールに保存された、値取得、値設定およびクリック操作のうちの少なくとも1つの動作定義に対応したデータ流通を提供する。
【0093】
例えば、動作定義が値取得である場合に、データ流通部164は、既存システム140のUIに表示されている値を取得する。そして、データ流通部164は、取得された値を、そのまま、表示制御部163によって透明なWebブラウザに表示された追加のUIに反映させる。あるいは、データ流通部164は、取得された値を加工または変換して、その値を追加のUIに反映させる。
【0094】
上述の値取得においては、データ流通部164は、対象とする既存システム(例えば、既存システム140)のUIが、Accessibility APIに対応しているかを判定する。対象とする既存システムのUIがAccessibility APIに対応している場合には、データ流通部164は、Accessibility APIを用いて、既存システムのUIに表示されている値を取得する。対象とする既存システムのUIがAccessibility APIに対応していない場合には、データ流通部164は、既存システムのUIに対してキーボードのコピー操作を行うことで、クリップボード記憶部152に記憶されたクリップボードを介して、既存システムのUIに表示された値を取得する。
【0095】
動作定義が値設定である場合には、データ流通部164は、表示制御部163によって透明なWebブラウザに表示された追加のUIに表示されている値を取得する。そして、データ流通部164は、取得された値を、そのまま既存システム140のUIに反映させる。
【0096】
上述の値設定においては、データ流通部164は、対象とする既存システム(例えば、既存システム140)のUIが、Accessibility APIに対応しているかを判定する。対象とする既存システムのUIがAccessibility APIに対応している場合には、データ流通部164は、Accessibility APIを用いて、既存システムのUIに値を反映させる。対象とする既存システムのUIがAccessibility APIに対応していない場合には、データ流通部164は、既存システムのUIに対してキーボードのペースト操作を行うことで、クリップボード記憶部152に記憶されたクリップボードを介して、既存システムのUIに値を反映させる。
【0097】
動作定義が、クリック操作であり、かつクリック操作が、表示制御部163によって透明なWebブラウザに表示された追加のUIに対してなされた場合に、データ流通部164は、既存システム140のUIに、このクリック操作を反映させる。
【0098】
例えば、データ流通部164は、対象とする既存システム(例えば、既存システム140)のUIが、Accessibility APIに対応しているかを判定する。対象とする既存システムのUIがAccessibility APIに対応している場合には、データ流通部164は、Accessibility APIを用いて、既存システムのUIにクリック操作を反映させる。対象とする既存システムのUIがAccessibility APIに対応していない場合には、データ流通部164は、一時的に透明なWebブラウザ全体を最小化する。そして、データ流通部164は、既存システムのUIが表示されている座標においてクリックイベントを発生させることで、既存システムのUIにクリック操作を反映させる。
【0099】
図8は、既存のUIと追加のUIとの間でデータを流通するデータ流通処理の一例を示す説明図である。図8の例では、データ流通部164が、Accessibility APIや仮想的なキーボード操作を使って、既存のUIと、追加のUIの間でデータを流通する。
【0100】
上述のように、UI拡張がWebシステムを対象とする場合には、同じDOMツリーに、既存のUIだけでなく追加のUIも存在する。このため、DOMを操作するJavaScriptのAPIを利用して、簡易にデータを流通することができる。しかしながら、既存システムの画面がWindowsのWPFやJavaのSwing等によって実装されている場合に、この画面は、DOMツリーを持たない。追加のUIを表示する透明のWebブラウザは、既存システムの画面から完全に独立している。したがって、従来の方法(JavaScriptのAPIを利用する方法)では、既存のUIと、追加のUIの間でデータを流通することが困難である。
【0101】
そこで、データ流通部164は、様々なシステムの実装に対応するために、Accessibly APIと仮想的なキーボード操作との併用によって、既存のUIと追加のUIとの間でのデータの流通を可能にする。
【0102】
Accessibly APIに関しては、データ流通部164がAccessibly APIを利用することができる場合に、データ流通部164は、システムの画面を構成する各UIを操作するAPIを取得する。データ流通部164は、これらのAPI呼び出すことで、UIに対して値を設定したり、UIから値を取得したりすることできる。
【0103】
図8の例では、はじめに、データ流通部164は、透明なWebブラウザに対するJavaScriptのAPIの呼び出しによって、追加のUIの値を取得する(ステップS80A-1)。例えば、データ流通部164は、「$(“ext01”).val()」というメソッドを利用して、簡易に追加のUIの値を取得することができる。
【0104】
次いで、データ流通部164は、Accessibly APIの値を設定するAPIを呼び出して、追加のUIから取得された値を、既存システムのUIに反映させる(ステップS80A-2)。
【0105】
仮想的なキーボード操作に関しては、上述したように、システムのUIが独自の実装によって構築されている場合に、データ流通部164は、Accessibly APIを利用することができない場合もある。そのような場合でも、データ流通部164は、ソフトウェアに、仮想的なキーボード操作により、キーボードのコピーまたはペースト操作を実行させることができる。データ流通部164は、クリップボードを介して、既存のUIと追加のUIの間で、データを流通することができる。
【0106】
図8の例では、はじめに、データ流通部164は、Accessibly APIの場合と同様に、追加のUIの値を取得する(ステップS80B-1)。
【0107】
次いで、データ流通部164は、追加のUIから取得された値を、クリップボードに設定する(ステップS80B-2)。
【0108】
次いで、データ流通部164は、データを流通することが望まれる既存のUIにフォーカスをあてる(ステップS80B-3)。言い換えると、データを流通することが望まれる既存のUIは、端末装置100のユーザがデータを流通したい既存のUIである。
【0109】
次いで、データ流通部164は、ソフトウェアからペーストのキーボード操作を実行する(ステップS80B-4)。すなわち、人間(ユーザ)は、キーボードを操作しない。
【0110】
(第2タイミング発生部165)
第2タイミング発生部165は、所定のイベントがシステムの画面で発生したかに基づいて、表示制御部163によって表示された追加のUIを再表示するタイミングを決定する。例えば、第2タイミング発生部165は、ルール記憶部151に記憶されたルールに保存された環境設定を、入力として使用する。そして、第2タイミング発生部165は、既存システム140の変化を監視し、追加のUIの再表示が必要とされるタイミングを指示する。このように、第2タイミング発生部165は、追加のUIを再表示するタイミングを調整する。第2タイミング発生部165は、UI Automationやグローバルフック等の手法を用いて、既存システム140の変化を監視することができる。
【0111】
より具体的には、環境設定の監視イベントに設定されたイベントが、システム判定条件に一致するシステムのウィンドウから観測された場合には、第2タイミング発生部165は、イベントの種別に合った処理を呼び出す。
【0112】
上述の監視イベントおよび呼び出される処理に関しては、第2タイミング発生部165は、以下の4つの処理のうちの少なくとも1つを実行することができる。
【0113】
第1の処理に関しては、マウスホイールイベントが、対象とするシステム(例えば、既存システム140)のウィンドウ内で発生したとき、第2タイミング発生部165は、対応するシステム定義に含まれる全ての追加UI設定を入力として使用して使用し、基点探索部162を呼び出す。これにより、第2タイミング発生部165は、追加のUIの表示位置を、マウスホイールのスクロールによる基点UIの表示位置の変更に追従させる。
【0114】
第2の処理に関しては、対象とするシステム(例えば、既存システム140)のウィンドウのサイズ変更イベントが発生したとき、第2タイミング発生部165は、対応する透明なWebブラウザのサイズを、このWebブラウザのサイズがシステムのウィンドウのサイズに追従するように、変更する。サイズの変更後に、第2タイミング発生部165は、対応するシステム定義に含まれる全ての追加UI設定を、入力として使用して、基点探索部162を呼び出す。これにより、第2タイミング発生部165は、追加のUIの表示位置を、ウィンドウのサイズ変更による基点UIの表示位置の変更に追従させる。
【0115】
第3の処理に関しては、描画のリロードなどの更新イベントが、対象とするシステム(例えば、既存システム140)のウィンドウ内で発生したとき、第2タイミング発生部165は、対応する透明なWebブラウザに表示されている全ての追加のUIを削除する。追加のUIの削除後に、第2タイミング発生部165は、対応するシステム定義に含まれる全ての追加UI設定を、入力として使用して、基点探索部162を呼び出す。これにより、第2タイミング発生部165は、システムの画面の表示内容の変更に応じて、追加のUIの表示を切り替える。
【0116】
第4の処理に関しては、マウスクリックのイベントまたはフォーカス変更のイベントが、対象とするシステム(例えば、既存システム140)のウィンドウ内で発生したとき、第2タイミング発生部165は、該当するイベントが発生したUIを特定する。該当するUIが基点探索部162によって監視対象として登録された基点UIと合致した場合には、基点UIに対応する基点定義を含む追加UI設定を、入力として使用して、基点探索部162を呼び出す。これにより、第2タイミング発生部165は、基点UIの値の変化に応じて、対応する追加のUIの表示を切り替える。
【0117】
図9Aおよび図9Bは、追加のUIを再表示するタイミングを発生させるタイミング発生処理一例を示す説明図である。
【0118】
上述したように、追加のUIを表示する透明なWebブラウザは、既存システム140の画面から完全に独立している。このため、以下の対応が必要とされる場合がある。なお、従来のユーザインタフェース拡張では、同じDOMツリーに、既存のUIおよび追加のUIが存在する。このため、従来のユーザインタフェース拡張は、以下の対応を考慮することを必要としていない。
【0119】
第1の対応は、基点のUIの値の変化を検知し、追加のUI(独立した透明なWebシステム)へ値の変化を通知することである。第2の対応は、透明なWebシステムに追加されたUIの削除(クリア)したり、再描画のタイミングを指定したりすることである。このような対応のために、制御部160は、第2タイミング発生部165を有する。
【0120】
「ある値が基点のUIに設定されている」という条件は、追加のUIの表示条件として、頻繁に登場する。このような場合、ユーザが基点のUIの値を変更したタイミングで、基点のUIの値をチェックし、値が表示条件と一致するかを判定し、追加のUIの表示を制御することが必要とされる。
【0121】
従来のUI拡張では、UI拡張の対象がWebシステムであった。このため、JavaScriptのイベントリスナーの機能を用いて、観測したいイベントに対してリスナーを登録することで、基点のUIの値の変化の取得を、簡易に実現することができる。しかしながら、実装例に係るUI拡張では、対象とする既存のシステムは、Webシステム以外のシステムも含む。このため、既存のUIのイベントにリスナーを登録することは、容易ではない。
【0122】
そこで、第2タイミング発生部165は、マウスクリックまたはフォーカス変更のイベントが発生したタイミングで、クリックされた既存のUIまたはフォーカスが変更された既存のUIが、基点のUIであるかを判定する。どのようなシステム実装でも、マウスクリックまたはフォーカス変更は、容易に観測されるイベントである。
【0123】
クリックされた既存のUIまたはフォーカスが変更された既存のUIが、基点のUIであると判定された場合に、第2タイミング発生部165は、対応する追加のUIに対して、基点探索部162の処理を呼び出して、対応する追加のUIの表示条件を再度チェックする。これにより、第2タイミング発生部165は、基点UIの値が変更された可能性があるタイミングを、追加のUIに対して通知し、それによって、追加のUIの表示制御を可能にする。このように、第2タイミング発生部165は、マウスクリックやフォーカス変更を監視し、基点UIの値の変更が発生した可能性を通知する。
【0124】
基点UIの値が変更された可能性があるタイミングに関しては、マウスクリックまたはフォーカス変更のイベントが、基点UIの値が変更されたタイミングで、常に発生するわけではない。結果的には、基点UIの値は、変更されていないかもしれない。そのような場合でも、表示条件の再度のチェックにおける不都合は、発生しない。マウスクリックおよびフォーカス変更のイベント以外の他のイベントが、基点UIの値が変更されたタイミングで発生する可能性がある場合には、第2タイミング発生部165は、他のイベントを監視してもよい。他のイベントが発生した場合に、第2タイミング発生部165は、マウスクリックやフォーカス変更の場合と同様に、基点UIの値の変更が発生した可能性を通知してもよい。
【0125】
加えて、Accessibility APIで、基点のUIに対し、値変更などのイベントのリスナーを登録することができる場合には、第2タイミング発生部165は、基点のUIごとに、リスナーを登録することもできる。イベントが発生した時に、第2タイミング発生部165は、対応する追加のUIに対して、基点UIの値が変更されたタイミングを通知することができる。
【0126】
図9Aの例では、基点のUI91および対応する追加のUI92が、既存システムの画面90上に表示されている。追加のUI92の表示条件は、「基点のUIの値が「aaa」である」という条件である。多くの場合、マウスクリックまたはフォーカス変更のイベントが、基点UIの値が変更されたタイミングで発生する。第2タイミング発生部165は、基点のUI91の値が変更されたタイミングで、基点のUI91の値の変化を検知し、追加のUI92を非表示にする。
【0127】
一方、図9Bの例では、第2タイミング発生部165は、透明なWebブラウザに追加されている全てのUIを削除(クリア)し、新たに表示制御を行う。
【0128】
従来のUI拡張では、既存のUIおよび追加のUIは、同じWebブラウザのDOMツリーに表示されている。このため、追加のUIが削除(クリア)または再描画されるタイミングは、自明であった。
【0129】
例えば、追加のUIが表示されているWebページがリロードされた場合には、全DOMツリーは、一度削除されて、新しいDOMツリーが再度読み込まれる。このため、追加のUIも削除(クリア)され、新しいDOMツリーが呼び込まれた後に、必要とされる追加のUIが再描画される。
【0130】
しかしながら、実装例に係るUI拡張では、既存のUIは、追加のUIが表示されている領域から完全に独立している。既存のUIが再度読み込まれたとしても、追加のUIは、そのままでは残ってしまう。なお、監視間隔ごとの表示制御処理によって、非表示または表示の切り替えを行うことは可能である。ただし、追加のUIを読み込みなおすことができない。表示制御処理で追加のUIを非表示にせずに、毎回、新たな追加のUIを読み込み直す(すなわち、追加のUIを削除してからUIを追加すること)ことも可能である。この場合、ユーザが追加のUIに入力した内容が、監視間隔ごとにクリアされてしまい、これは、ユーザインタフェース拡張として、利用に堪えない。
【0131】
そこで、第2タイミング発生部165は、更新(リロード)のイベントを、任意(例えば、既存システムの画面の更新ボタンが押されたときや、タブが切り換えられたとき等)に設定することを可能にする。そして、第2タイミング発生部165は、更新イベントが発生した時に、対応する透明なWebブラウザに追加されている全てのUIを削除(クリア)し、表示制御を新たに行う。これにより、第2タイミング発生部165は、追加のUIの再描画を可能にする。
【0132】
図9Bの例では、基点のUI91および対応する追加のUI92が、既存システムの画面90上に表示されている。この例では、スクロール領域内全体が再描画され、基点のUI91がなくなった。従来のWebシステムを対象としたUI拡張では、追加のUI92は、自動的に削除される。しかしながら、実装例に係るUI拡張では、追加のUI92は、そのままだと残置される。追加のUI92は、どんなに良くても非表示となるだけであり、追加のUI92は、削除(クリア)されない。第2タイミング発生部165は、追加のUI92に対して、新たな表示制御を適用する。新たな表示制御は、図14を参照して以下で詳述される。
【0133】
〔4.UI拡張処理のフロー〕
次に、図10図11図12図13図14および図15を参照して、実施形態に係る端末装置100によるUI拡張処理の手順について説明する。
【0134】
図10は、実施形態に係る端末装置100によって実行される、既存システムの画面のUIを拡張するための処理の一例を示すフローチャートである。
【0135】
図10に示されるように、はじめに、端末装置100の第1タイミング発生部161は、既存システムを監視する(ステップS101)。既存システムの監視は、図11を参照して以下で詳述される。
【0136】
次いで、端末装置100の基点探索部162は、現時点が既存システムの基点UIを探索するタイミングであるかを判定する(ステップS102)。現時点が既存システムの基点UIを探索するタイミングでないと判定された場合に(ステップS102:No)、処理手順は、ステップS101に戻る。
【0137】
現時点が既存システムの基点UIを探索するタイミングであると判定された場合に(ステップS102:Yes)、基点探索部162は、既存システムの基点UIを探索する(ステップS103)。既存システムの基点UIの探索は、図12を参照して以下で詳述される。
【0138】
次いで、端末装置100の表示制御部163は、追加のUIの表示を制御する(ステップS104)。追加のUIの表示の制御は、図13を参照して以下で詳述される。
【0139】
次いで、端末装置100の第2タイミング発生部165は、既存システムの変化を監視する(ステップS105)。既存システムの変化の監視は、図14を参照して以下で詳述される。
【0140】
次いで、基点探索部162は、現時点が追加のUIを再表示するタイミングであるかを判定する(ステップS106)。現時点が追加のUIを再表示するタイミングであると判定された場合に(ステップS106:Yes)、処理手順は、ステップS103に戻る。
【0141】
現時点が追加のUIを再表示するタイミングでないと判定された場合に(ステップS106:No)、端末装置100の第2タイミング発生部165は、既存のUIと追加のUIとの間でデータを流通する(ステップS107)。既存のUIと追加のUIとの間でのデータの流通は、図15を参照して以下で詳述される。
【0142】
なお、図10の例では、端末装置100は、ステップS105およびステップS106の後にステップS107を実行しているが、この順序に限定されるものではない。端末装置100は、既存のUIと追加のUIとの間でのデータの流通の後に、既存システムの変化を監視してもよい。
【0143】
図11は、実施形態に係る端末装置100によって実行される、既存システムを監視するための処理の一例を示すフローチャートである。端末装置100の第1タイミング発生部161は、既存システムの監視を、ルール記憶部151に記憶されたシステム定義ごとに、並列で実行する。
【0144】
図11に示されるように、はじめに、第1タイミング発生部161は、ルール記憶部151に記憶されたシステム定義に基づいて、監視間隔に設定された時間が経過したかを判定する(ステップS201)。監視間隔に設定された時間が経過していないと判定された場合に(ステップS201:No)、第1タイミング発生部161は、再度ステップS201を実行する。
【0145】
監視間隔に設定された時間が経過したと判定された場合に(ステップS201:Yes)、第1タイミング発生部161は、システム判定条件に一致するシステムのウィンドウがデスクトップ上で最前面に表示されているかを判定する(ステップS202)。システム判定条件に一致するシステムのウィンドウがデスクトップ上で最前面に表示されていないと判定された場合に(ステップS202:No)、処理手順は、ステップS201に戻る。
【0146】
システム判定条件に一致するシステムのウィンドウがデスクトップ上で最前面に表示されていると判定された場合に(ステップS202:Yes)、第1タイミング発生部161は、システム定義に含まれる全ての追加UI設定を入力として使用して、基点探索部162を呼び出す(ステップS203)。言い換えると、第1タイミング発生部161は、基点探索部162に、基点UIを探索するよう指示する。これにより、基点探索部162は、現時点が既存システムの基点UIを探索するタイミングであるかを判定することができる。
【0147】
図12は、実施形態に係る端末装置100によって実行される、既存システムの基点UIを探索するための処理の一例を示すフローチャートである。端末装置100の基点探索部162は、既存システムの基点UIの探索を、ルール記憶部151に記憶された追加UI設定ごとに実行する。
【0148】
図12に示されるように、はじめに、基点探索部162は、基点UIの探索の指示があったかを判定する(ステップS301)。基点UIの探索の指示がなかったと判定された場合に(ステップS301:No)、基点探索部162は、既存システムの基点UIを探索するタイミングまで待機する。そして、基点探索部162は、再度ステップS301を実行する。
【0149】
基点UIの探索の指示があったと判定された場合に(ステップS301:Yes)、基点探索部162は、全ての追加UI設定の処理が終わったかを判定する(ステップS302)。全ての追加UI設定の処理が終わったと判定された場合に(ステップS302:Yes)、処理手順は、終了する。
【0150】
全ての追加UI設定の処理が終わってないと判定された場合に(ステップS302:No)、基点探索部162は、ルール記憶部151から、基点定義を取得する(ステップS303)。
【0151】
次いで、基点探索部162は、取得された基点定義に基づいて、基点UIを探索する(ステップS304)。基点探索部162は、基点UIの探索を、基点定義ごとに、並列で実行する。
【0152】
一例では、基点探索部162は、Accessibility APIを用いて、既存システムのUIのプロパティ値を逐次取得し、基点定義のプロパティ値と一致するUI(基点UI)を探索する(ステップS304A-1)。
【0153】
別の例では、基点探索部162は、対象の既存システムのキャプチャ画像を取得する(ステップS304B-1)。次いで、基点探索部162は、既存システムのキャプチャ画像中から、基点定義のキャプチャ画像と一致するUI(基点UI)を探索する(ステップS304B-2)。
【0154】
次いで、基点探索部162は、基点UIが見つかったかを判定する(ステップS305)。基点UIが見つからなかったと判定された場合に(ステップS305:No)、該当する追加UI設定と判定結果(不一致)とを入力として使用して、表示制御部163を呼び出す。そして、基点探索部162は、再度ステップS302を実行する。
【0155】
基点UIが見つかったと判定された場合に(ステップS305:Yes)、基点探索部162は、表示条件があるかを判定する(ステップS307)。
【0156】
表示条件があると判定された場合に(ステップS307:Yes)、基点探索部162は、基点UIの値が表示条件と一致するかを判定する(ステップS308)。言い換えると、基点探索部162が表示条件を取得できた場合に、基点探索部162は、ステップS308を実行する。基点探索部162は、例えば、データ流通部164に関して上述した情報処理(値の取得)によって、基点UIの値を取得することができる。
【0157】
基点UIの値が表示条件と一致すると判定された場合に(ステップS308:Yes)、基点探索部162は、基点UIの座標およびサイズを取得する(ステップS309)。基点UIの値が表示条件と一致しないと判定された場合に(ステップS308:No)、処理手順は、ステップS306に移行する。
【0158】
表示条件がないと判定された場合に(ステップS307:No)、処理手順は、ステップS309に移行する。言い換えると、基点探索部162が表示条件を取得できなかった場合に、基点探索部162は、ステップS309を実行する。
【0159】
次いで、基点探索部162は、第2タイミング発生部165に基点UIを監視対象として追加する(ステップS310)。
【0160】
次いで、基点探索部162は、該当する追加UI設定、判定結果(一致)、基点UIの座標および基点UIのサイズを入力として使用して、表示制御部163を呼び出す(ステップS311)。そして、基点探索部162は、再度ステップS302を実行する。
【0161】
図13は、実施形態に係る端末装置100によって実行される、追加のUIの表示を制御するための処理の一例を示すフローチャートである。端末装置100の表示制御部163は、追加UI設定、基点探索部162の判定結果(一致または不一致)、ならびに基点UIの座標およびサイズに基づいて、追加のUIの表示の制御を実行する。
【0162】
図13に示されるように、はじめに、表示制御部163は、基点UIの値が表示条件と一致するかを判定する(ステップS401)。基点UIの値が表示条件と一致しないと判定された場合に(ステップS401:No)、表示制御部163は、追加のUIが透明なWebブラウザ上に既に表示されているかを判定する(ステップS402)。追加のUIが透明なWebブラウザ上にまだ表示されていないと判定された場合に(ステップS402:No)、処理手順は、終了する。
【0163】
追加のUIが透明なWebブラウザ上に既に表示されていると判定された場合に(ステップS402:Yes)、表示制御部163は、追加のUIを非表示にする(ステップS403)。
【0164】
ステップS401において、基点UIの値が表示条件と一致すると判定された場合に(ステップS401:Yes)、表示制御部163は、追加UI設定の外観定義に設定された相対座標、座標およびサイズから、透明なWebブラウザ上での追加のUIの表示位置を計算する(ステップS404)。
【0165】
次いで、表示制御部163は、追加のUIが透明なWebブラウザ上に既に表示されているかを判定する(ステップS405)。追加のUIが透明なWebブラウザ上に既に表示されていると判定された場合に(ステップS405:Yes)、表示制御部163は、追加のUIの表示位置を計算された表示位置に修正する(ステップS406)。
【0166】
追加のUIが透明なWebブラウザ上にまだ表示されていないと判定された場合に(ステップS405:No)、表示制御部163は、ルール記憶部151に記憶された外観定義に設定されたHTML情報に従って、追加のUIを計算された表示位置に新規に表示する(ステップS407)。
【0167】
図14は、実施形態に係る端末装置100によって実行される、既存システムの変化を監視するための処理の一例を示すフローチャートである。端末装置100の第2タイミング発生部165は、既存システムの変化の監視するステップS500を、ルール記憶部151に記憶されたシステム定義ごとに、並列で実行する。
【0168】
一例では、第2タイミング発生部165は、監視イベントに設定されたイベントが発生したかを判定する(ステップS500A-1)。監視イベントに設定されたイベントが発生しなかったと判定された場合に(ステップS500A-1:No)、第2タイミング発生部165は、再度ステップS500A-1を実行する。
【0169】
監視イベントに設定されたイベントが発生したと判定された場合に(ステップS500A-1:Yes)、第2タイミング発生部165は、イベントに対応した処理を実行する(ステップS500A-2)。そして、第2タイミング発生部165は、再度ステップS500A-1を実行する。
【0170】
別の例では、第2タイミング発生部165は、マウスホイールイベントが発生したかを判定する(ステップS500B-1)。マウスホイールイベントが発生しなかったと判定された場合に(ステップS500B-1:No)、第2タイミング発生部165は、再度ステップS500B-1を実行する。
【0171】
マウスホイールイベントが発生したと判定された場合に(ステップS500B-1:Yes)、第2タイミング発生部165は、システム定義に含まれる全ての追加UI設定を入力として使用して、基点探索部162を呼び出す(ステップS500B-2)。言い換えると、第2タイミング発生部165は、基点探索部162に、基点UIを探索するよう指示する。これにより、基点探索部162は、現時点が追加のUIを再表示するタイミングであるかを判定することができる。そして、第2タイミング発生部165は、再度ステップS500B-1を実行する。
【0172】
さらに別の例では、第2タイミング発生部165は、ウィンドウサイズ変更イベントが発生したかを判定する(ステップS500C-1)。ウィンドウサイズ変更イベントが発生しなかったと判定された場合に(ステップS500C-1:No)、第2タイミング発生部165は、再度ステップS500C-1を実行する。
【0173】
ウィンドウサイズ変更イベントが発生したと判定された場合に(ステップS500C-1:Yes)、第2タイミング発生部165は、対象の既存システムのウィンドウサイズを取得する(ステップS500C-2)。
【0174】
次いで、第2タイミング発生部165は、対応する透明なWebブラウザのサイズを取得されたウィンドウサイズに変更する(ステップS500C-3)。
【0175】
次いで、第2タイミング発生部165は、システム定義に含まれる全ての追加UI設定を入力として使用して、基点探索部162を呼び出す(ステップS500C-4)。その結果、基点探索部162は、現時点が追加のUIを再表示するタイミングであるかを判定することができる。そして、第2タイミング発生部165は、再度ステップS500C-1を実行する。
【0176】
さらに別の例では、第2タイミング発生部165は、更新イベントが発生したかを判定する(ステップS500D-1)。更新イベントが発生しなかったと判定された場合に(ステップS500D-1:No)、第2タイミング発生部165は、再度ステップS500D-1を実行する。
【0177】
更新イベントが発生したと判定された場合に(ステップS500D-1:Yes)、第2タイミング発生部165は、対応する透明なWebブラウザに表示されている追加のUIをすべて削除する(ステップS500D-2)。
【0178】
次いで、第2タイミング発生部165は、システム定義に含まれる全ての追加UI設定を入力として使用して、基点探索部162を呼び出す(ステップS500D-3)。その結果、基点探索部162は、現時点が追加のUIを再表示するタイミングであるかを判定することができる。そして、第2タイミング発生部165は、再度ステップS500D-1を実行する。
【0179】
さらに別の例では、第2タイミング発生部165は、マウスクリックイベントまたはフォーカス変更イベントが発生したかを判定する(ステップS500E-1)。マウスクリックイベントおよびフォーカス変更イベントが発生しなかったと判定された場合に(ステップS500E-1:No)、第2タイミング発生部165は、再度ステップS500E-1を実行する。
【0180】
マウスクリックイベントまたはフォーカス変更イベントが発生したと判定された場合に(ステップS500E-1:Yes)、第2タイミング発生部165は、該当するイベントが発生したUIを特定する(ステップS500E-2)。
【0181】
次いで、第2タイミング発生部165は、特定されたUIが監視対象として登録された基点UIと一致するかを判定する(ステップS500E-3)。特定されたUIが監視対象として登録された基点UIと一致しないと判定された場合に(ステップS500E-3:No)、第2タイミング発生部165は、再度ステップS500E-1を実行する。
【0182】
特定されたUIが監視対象として登録された基点UIと一致すると判定された場合に(ステップS500E-3:Yes)、第2タイミング発生部165は、基点UIに対応する基点定義を含む追加UI設定を入力として使用して、基点探索部162を呼び出す(ステップS500E-4)。その結果、基点探索部162は、現時点が追加のUIを再表示するタイミングであるかを判定することができる。そして、第2タイミング発生部165は、再度ステップS500E-1を実行する。
【0183】
図15は、実施形態に係る端末装置100によって実行される、既存のUIと追加のUIとの間でデータを流通するための処理の一例を示すフローチャートである。端末装置100のデータ流通部164は、既存のUIと追加のUIとの間でデータを流通するステップS600を、ルール記憶部151に記憶された動作定義によって示されるUIの振る舞いごとに、並列で実行する。
【0184】
値の取得に関しては、データ流通部164は、既存システムのUIがAccessibility APIに対応しているかを判定する(ステップS600A-1)。
【0185】
既存システムのUIがAccessibility APIに対応していると判定された場合に(ステップS600A-1:Yes)、データ流通部164は、Accessibility APIを用いて、動作定義で指定された既存システムのUIに表示されている値を取得する(ステップS600A-2)。
【0186】
次いで、データ流通部164は、取得された値を必要に応じて加工して変換し、動作定義で指定された透明なWebブラウザに表示された追加のUIに、取得された値を反映させる(ステップS600A-3)。
【0187】
ステップS600A-1において、既存システムのUIがAccessibility APIに対応していないと判定された場合に(ステップS600A-1:No)、データ流通部164は、動作定義で指定された既存システムのUIにフォーカスをあてる(ステップS600A-4)。
【0188】
次いで、データ流通部164は、キーボードによるコピー操作(例えば、Ctrl-A、Ctrl-C等)をソフトウェアから実行する(ステップS600A-5)。すなわち、人間は、キーボードを操作しない。
【0189】
次いで、データ流通部164は、クリップボード記憶部152から、クリップボードの値を取得する(ステップS600A-6)。そして、データ流通部164は、ステップS600A-3を実行する。
【0190】
値の設定に関しては、データ流通部164は、動作定義で指定された透明なWebブラウザに表示された追加のUIに表示されている値を取得する(ステップS600B-1)。
【0191】
次いで、データ流通部164は、既存システムのUIがAccessibility APIに対応しているかを判定する(ステップS600B-2)。
【0192】
既存システムのUIがAccessibility APIに対応していると判定された場合に(ステップS600B-2:Yes)、データ流通部164は、Accessibility APIを用いて、動作定義で指定された既存システムのUIに、取得された値を反映させる(ステップS600B-3)。
【0193】
既存システムのUIがAccessibility APIに対応していないと判定された場合に(ステップS600B-2:No)、データ流通部164は、動作定義で指定された既存システムのUIにフォーカスをあてる(ステップS600B-4)。
【0194】
次いで、データ流通部164は、クリップボードに取得された値を設定する(ステップS600B-5)。
【0195】
次いで、データ流通部164は、キーボードによるペースト操作(例えば、Ctrl-V等)をソフトウェアから実行する(ステップS600B-6)。すなわち、人間は、キーボードを操作しない。
【0196】
クリック操作に関しては、データ流通部164は、既存システムのUIがAccessibility APIに対応しているかを判定する(ステップS600C-1)。
【0197】
既存システムのUIがAccessibility APIに対応していると判定された場合に(ステップS600C-1:Yes)、データ流通部164は、Accessibility APIを用いて、動作定義で指定された既存システムのUIにクリック操作を反映させる(ステップS600C-2)。
【0198】
既存システムのUIがAccessibility APIに対応していないと判定された場合に(ステップS600C-1:No)、データ流通部164は、一時的に透明なWebブラウザ全体を最小化する(ステップS600C-3)。
【0199】
次いで、データ流通部164は、既存システムのUIが表示されている座標においてクリックイベントを発生させる(ステップS600C-4)。
【0200】
〔5.効果〕
上述してきたように、実施形態に係るユーザインタフェース拡張システム1は、基点探索部162と、表示制御部163とを有する。
【0201】
実施形態に係るユーザインタフェース拡張システム1において、基点探索部162は、システムの画面に追加される追加のユーザインタフェース(UI)の表示の基点となる基点UIを、このシステムの画面から探索する。また、実施形態に係るユーザインタフェース拡張システム1において、表示制御部163は、背景が透明な新たな画面を、システムの画面と重ねて表示し、この新たな画面において、基点UIに基づく位置に追加のUIを表示する。
【0202】
これにより、実施形態に係るユーザインタフェース拡張システム1は、ユーザインタフェース拡張を広範なシステムに適用することができる。
【0203】
また、実施形態に係るユーザインタフェース拡張システム1において、システムから独立した新たな画面を、システムの画面と重ねて表示する。
【0204】
これにより、実施形態に係るユーザインタフェース拡張システム1は、システムの実装によらずに適用可能なユーザインタフェース拡張を提供することができる。
【0205】
また、実施形態に係るユーザインタフェース拡張システム1において、基点探索部162は、アクセシビリティAPIで利用される基点UIのプロパティ値又はシステムの画面のキャプチャ画像に基づいて、基点UIを探索する。
【0206】
これにより、実施形態に係るユーザインタフェース拡張システム1は、DOMツリーを持たないシステムの画面から、基点UIを探索することができる。
【0207】
また、実施形態に係るユーザインタフェース拡張システム1は、アクセシビリティAPI又は仮想的なキーボード操作を用いて、システムの画面の既存のUIと追加のUIとの間でデータを流通するデータ流通部164を有する。
【0208】
これにより、実施形態に係るユーザインタフェース拡張システム1は、DOMツリーを持たないシステムの画面のUIに、追加のUIの内容を反映させることができる。
【0209】
また、実施形態に係るユーザインタフェース拡張システム1は、システムを監視し、システムの画面が視認可能に表示されているかに基づいて、システムの画面から基点UIを探索する第1のタイミングを決定する第1タイミング発生部161を有する。また、実施形態に係るユーザインタフェース拡張システム1において、基点探索部162は、第1タイミング発生部161によって決定された第1のタイミングに基づいて、基点UIを探索する。
【0210】
これにより、実施形態に係るユーザインタフェース拡張システム1は、適切なタイミングで基点UIを探索することができる。
【0211】
また、実施形態に係るユーザインタフェース拡張システム1は、システムの変化を監視し、所定のイベントがシステムの画面で発生したかに基づいて、表示制御部163によって表示された追加のUIを再表示する第2のタイミングを決定する第2タイミング発生部165を有する。
【0212】
これにより、実施形態に係るユーザインタフェース拡張システム1は、適切なタイミングで追加のUIを再表示することができる。
【0213】
〔6.他の実施形態〕
上述の実施形態に係るユーザインタフェース拡張システム1は、上述の実施形態以外にも、種々の異なる形態で実施されてよい。そこで、以下では、上記のユーザインタフェース拡張システム1の他の実施形態について説明する。
【0214】
〔6-1.端末装置によるUI拡張処理の実行主体〕
コンテンツ提供装置200は、上述の実施形態において端末装置100によって実行された処理の一部を実行してもよい。例えば、コンテンツ提供装置200は、第1タイミング発生部161、基点探索部162および第2タイミング発生部165に関して上述した情報処理の全部または一部を行ってもよい。
【0215】
例えば、既存システム140は、コンテンツ提供装置200にインストールされていてもよい。この場合、コンテンツ提供装置200は、第1タイミング発生部161、基点探索部162および第2タイミング発生部165に関して上述した情報処理を行ってもよい。ただし、既存システム140のUIは、端末装置100に存在するものとする。端末装置100は、このUIを介して、表示制御部163およびデータ流通部164に関して上述した情報処理を行うことができる。
【0216】
図4を参照して上述したように、ユーザインタフェース拡張システム1は、端末装置100と、コンテンツ提供装置200とを含む。コンテンツ提供装置200が、第1タイミング発生部161、基点探索部162および第2タイミング発生部165に関して上述した情報処理の一部を分担してもよい。
【0217】
〔7.その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の一部を手動的に行うこともできる。あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
【0218】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【0219】
例えば、図4に示した記憶部150の一部又は全部は、端末装置100によって保持されるのではなく、ストレージサーバ等に保持されてもよい。この場合、端末装置100は、ストレージサーバにアクセスすることで、表示条件等の各種情報を取得する。
【0220】
〔8.ハードウェア構成〕
図16は、ハードウェア構成の一例を示す図である。上述してきた実施形態に係る端末装置100やコンテンツ提供装置200は、例えば図16に示すような構成のコンピュータ1000によって実現される。
【0221】
図16は、プログラムが実行されることにより、端末装置100やコンテンツ提供装置200が実現されるコンピュータの一例を示している。コンピュータ1000は、例えば、メモリ1010、CPU1020を有する。また、コンピュータ1000は、ハードディスクドライブインタフェース1030、ディスクドライブインタフェース1040、シリアルポートインタフェース1050、ビデオアダプタ1060、ネットワークインタフェース1070を有する。これらの各部は、バス1080によって接続される。
【0222】
メモリ1010は、ROM(Read Only Memory)1011及びRAM1012を含む。ROM1011は、例えば、BIOS(Basic Input Output System)等のブートプログラムを記憶する。ハードディスクドライブインタフェース1030は、ハードディスクドライブ1090に接続される。ディスクドライブインタフェース1040は、ディスクドライブ1100に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ1100に挿入される。シリアルポートインタフェース1050は、例えばマウス1110、キーボード1120に接続される。ビデオアダプタ1060は、例えばディスプレイ1130に接続される。
【0223】
ハードディスクドライブ1090は、例えば、OS(Operating System)1091、アプリケーションプログラム1092、プログラムモジュール1093、プログラムデータ1094を記憶する。すなわち、端末装置100やコンテンツ提供装置200の各処理を規定するプログラムは、コンピュータ1000により実行可能なコードが記述されたプログラムモジュール1093として実装される。プログラムモジュール1093は、例えばハードディスクドライブ1090に記憶される。例えば、端末装置100やコンテンツ提供装置200における機能構成と同様の処理を実行するためのプログラムモジュール1093が、ハードディスクドライブ1090に記憶される。なお、ハードディスクドライブ1090は、SSD(Solid State Drive)により代替されてもよい。
【0224】
また、上述した実施の形態の処理で用いられる設定データは、プログラムデータ1094として、例えばメモリ1010やハードディスクドライブ1090に記憶される。そして、CPU1020が、メモリ1010やハードディスクドライブ1090に記憶されたプログラムモジュール1093やプログラムデータ1094を必要に応じてRAM1012に読み出して実行する。
【0225】
なお、プログラムモジュール1093やプログラムデータ1094は、ハードディスクドライブ1090に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ1100等を介してCPU1020によって読み出されてもよい。あるいは、プログラムモジュール1093及びプログラムデータ1094は、ネットワーク(LAN、WAN等)を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール1093及びプログラムデータ1094は、他のコンピュータから、ネットワークインタフェース1070を介してCPU1020によって読み出されてもよい。
【0226】
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、本発明を特定の例に限定するものではない。本明細書に記載された特徴は、発明を実施するための形態の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で実施されることが可能である。
【0227】
また、上述してきた「部(section、module、unit)」は、「手段」や「回路」などに読み替えることができる。例えば、表示制御部は、表示制御手段や表示制御回路に読み替えることができる。
【符号の説明】
【0228】
1 ユーザインタフェース拡張システム
100 端末装置
110 通信部
120 入力部
130 出力部
140 既存システム
150 記憶部
151 ルール記憶部
152 クリップボード記憶部
160 制御部
161 第1タイミング発生部
162 基点探索部
163 表示制御部
164 データ流通部
165 第2タイミング発生部
200 コンテンツ提供装置
図1
図2
図3A
図3B
図3C
図4
図5
図6
図7
図8
図9A
図9B
図10
図11
図12
図13
図14
図15
図16