JP7473007B2 - 表示制御システム、表示制御方法及び表示制御プログラム - Google Patents

Description

本開示は、表示制御システム、表示制御方法及び表示制御プログラムに関する。

Ｗｅｂシステムは、様々な業務を対象に開発されている。業務の実態に合わせてＷｅｂシステムの画面をアップデートすることは、業務にとって重要なことである。しかしながら、画面の改造は、多大なコストを必要とする場合がある。また、画面の改造は、Ｗｅｂシステムに予期しない影響を与える場合がある。そこで、画面を直接改造することなく、画面を業務の変化に対応させるために、ＵＩ拡張技術が提案されている。

ＵＩ拡張技術は、既存のＷｅｂシステムの画面を直接改造することなく、追加のＵＩを表示するものである。ＵＩ拡張技術では、追加のＵＩによる既存のＷｅｂシステムへの影響を軽減するために、追加のＵＩは、既存のＷｅｂシステムの画面を構成するＤＯＭ（Document Object Model）ツリーの末尾に挿入される。

追加のＵＩがＤＯＭツリーの末尾に挿入された場合に、表示の基点となる基点ＵＩ（User Interface）が、追加のＵＩに対して指定される。基点ＵＩは、既存のＷｅｂシステムの画面に存在するＵＩである。この基点ＵＩが画面に表示された場合に、追加のＵＩは、基点ＵＩからの相対座標に基づいて、画面に表示される。

上述したような追加のＵＩの表示を制御する手法は、追加のＵＩの複雑な表示および非表示や、追加のＵＩの表示位置の制御を必要とする場合がある。例えば、このような手法では、追加のＵＩを、Ｗｅｂシステムの画面に存在するＵＩのスクロールに追従させるために、スクロール領域を有するＵＩが、画面のＤＯＭツリーの中から探索される場合がある。スクロール領域を有するＵＩは、追加のＵＩの表示制御に使用されるＵＩの一例である。

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

しかしながら、追加のＵＩの表示を制御する既存の手法では、追加のＵＩの表示制御に使用されるＵＩの探索を効率よく行えない場合がある。

例えば、既存の手法では、追加のＵＩの表示制御に使用されるＵＩの全探索が、画面のＤＯＭツリーのルートから実行される。しかしながら、ＤＯＭツリーの構造が巨大である、またはＤＯＭツリーの変更規模が大きい場合に、ＵＩの探索は、長い時間を要する場合がある。最悪の場合、Ｗｅｂシステムが、フリーズする。

本願は、上記に鑑みてなされたものであって、追加のＵＩの表示制御に使用されるＵＩの探索を効率よく行うことを目的とする。

本開示の実施形態に係る表示制御システムは、追加のＵＩが挿入された画面のＤＯＭツリーを取得する取得部と、前記追加のＵＩの表示に関する表示条件に基づいて、前記ＤＯＭツリーにおいて、前記追加のＵＩの表示の基点となる基点ＵＩから、前記追加のＵＩの表示制御に使用されるＵＩを探索する探索部と、前記探索部によって探索されたＵＩに対して、前記表示条件に応じたイベントを登録する登録部とを備える。

実施形態の一態様によれば、追加のＵＩの表示制御に使用されるＵＩの探索を効率よく行うことができる。

図１は、ＵＩ拡張の一例を示す説明図である。 図２は、典型的なＵＩ探索の一例を示す説明図である。 図３は、実装例に係るＵＩ探索の一例を示す説明図である。 図４Ａは、追加のＵＩの表示制御の一例を示す説明図である。 図４Ｂは、追加のＵＩの表示制御の一例を示す説明図である。 図４Ｃは、追加のＵＩの表示制御の一例を示す説明図である。 図５は、実施形態に係る表示制御システムの一例を示す図である。 図６は、実施形態に係る端末装置によって実行される、追加のＵＩが挿入されたことを検知するための処理の一例を示すフローチャートである。 図７は、典型的なＵＩ探索の一例を示す説明図である。 図８は、実装例に係るＵＩ探索の一例を示す説明図である。 図９は、記憶部に保持される情報の一例を示す説明図である。 図１０Ａは、追加のＵＩの表示制御に使用されるＵＩを探索する探索処理の一例を示す説明図である。 図１０Ｂは、追加のＵＩの表示制御に使用されるＵＩを探索する探索処理の一例を示す説明図である。 図１１Ａは、追加のＵＩの表示制御に使用されるＵＩを探索する探索処理の一例を示す説明図である。 図１１Ｂは、追加のＵＩの表示制御に使用されるＵＩを探索する探索処理の一例を示す説明図である。 図１２Ａは、追加のＵＩの表示制御に使用されるＵＩを探索する探索処理の一例を示す説明図である。 図１２Ｂは、追加のＵＩの表示制御に使用されるＵＩを探索する探索処理の一例を示す説明図である。 図１３は、実施形態に係る端末装置によって実行される、表示条件に応じたイベント処理の一例を示すフローチャートである。 図１４は、イベント発生時の画面表示の一例を示す説明図である。 図１５は、実施形態に係る端末装置によって実行される、表示条件に応じたイベント処理の一例を示すフローチャートである。 図１６は、イベント発生時の画面表示の一例を示す説明図である。 図１７は、実施形態に係る端末装置によって実行される、表示条件に応じたイベント処理の一例を示すフローチャートである。 図１８は、イベント発生時の画面表示の一例を示す説明図である。 図１９は、実施形態に係る端末装置によって実行される、追加のＵＩの表示制御に使用されるＵＩを探索するための処理の一例を示すフローチャートである。 図２０は、ハードウェア構成の一例を示す図である。

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

以下では、「追加のＵＩ」を「追加ＵＩ」と表記することがある。また、「既存のＵＩ」が、「既存ＵＩ」と表記されることがある。

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

従来、様々なＵＩ拡張技術が提案されている。ＵＩ拡張技術の１つは、既存のシステム画面を構成するＤＯＭツリーの末尾に追加のＵＩを挿入するＷｅｂ機能拡張技術である。Ｗｅｂ機能拡張技術は、既存のＷｅｂシステムの画面を直接改造することの影響を発生させずに、追加のＵＩを表示することができる。

図１は、ＵＩ拡張の一例を示す説明図である。図１の例では、Ｗｅｂシステムの画面のＤＯＭツリー１０は、既存のＷｅｂシステムの画面のＤＯＭツリー１１および追加のＵＩのＤＯＭツリー１２を含む。図１に示された矢印は、画面のＤＯＭツリー１０と、画面の見た目との対応を示す。

Ｗｅｂ機能拡張技術では、基点のＵＩが、追加のＵＩに対して指定される。基点のＵＩは、既存のＷｅｂシステムに存在するＵＩである。基点となるＵＩがＷｅｂシステムの画面に表示されている場合に、追加のＵＩは、基点となるＵＩからの相対座標で表示される。階層的に追加のＵＩの親となる既存のＵＩが変化する場合に、追加のＵＩの表示制御が、既存のＵＩの変化に応じて必要とされる場合がある。

例えば、Ｗｅｂ機能拡張技術では、表示態様の変化を伴う既存のＵＩが、追加のＵＩの表示制御のために探索される。表示態様の変化を伴う既存のＵＩは、例えば、スクロール領域を持つ既存のＵＩである。図１の例では、追加ＵＩ（１）は、既存ＵＩ（２）の子として実際は存在しない。このため、もし、追加のＵＩの表示制御が行われなければ、追加ＵＩ（１）は、既存ＵＩ（２）のスクロールに追従しない。

そこで、Ｗｅｂ機能拡張技術では、表示態様の変化を伴う既存のＵＩが、探索される。このような既存のＵＩは、追加のＵＩの基点として設定されたＵＩの親階層に存在し、表示態様の変化を伴うＵＩである。例えば、探索される既存のＵＩは、スクロール領域を持つ既存のＵＩである。

図２は、典型的なＵＩ探索の一例を示す説明図である。典型的なＵＩ探索では、ＤＯＭツリー１０の動的な変化に対応するために、表示制御に使用されるＵＩは、ルートから全探索されている。このため、典型的なＵＩ探索の計算量は、膨大であり、親のスクロールの変化にしか対応してない。

図２の例では、スクロール領域を持つ既存のＵＩは、既存ＵＩ（１）の配下にないが、既存ＵＩ（３）や既存ＵＩ（４）も、探索されてしまう。このように、典型的なＵＩ探索では、無駄な探索が発生する。また、ツリーの変化が大きい場合に、ＵＩの探索に要する計算量が増大する。最悪の場合、既存のシステムが固まる。

そこで、追加のＵＩが挿入された場合に、実装例に係る表示制御システムは、追加のＵＩの表示制御に使用される複数のＵＩを、基点となるＵＩを基点として探索する。これにより、表示制御システムは、計算量の小さい効率的なＵＩの特定を可能にする。

図３は、実装例に係るＵＩ探索の一例を示す説明図である。表示制御システムは、ＤＯＭツリー１０の親に向かって、基点となるＵＩから、既存のＵＩを探索する。探索対象となる既存のＵＩは、スクロール領域を持つ既存のＵＩ等の、表示態様の変化を伴う既存のＵＩである。表示態様の変化は、透過度、サイズ、z-index等の変化であってもよい。

表示制御システムは、基点となるＵＩからルートに向かってＵＩを探索し、探索されたキー（基点となるＵＩまたは既存のＵＩ）とバリュー（表示条件）とのセットを、記憶領域に格納する。表示制御システムが記憶領域に既に記憶されているキーとバリューのセットを見つけた場合に、表示制御システムは、以降のＵＩの探索をスキップする。このように、表示制御システムは、記憶領域に記憶されているキーとバリューのセットに基づいて、不要な探索をスキップすることができる。そして、表示制御システムは、表示条件に応じた表示制御処理を、既存のＵＩのイベントに対して登録する。

これにより、表示制御システムは、ＵＩ探索の計算量を削減し、ＵＩの表示を高速化することができる。また、表示制御システムは、追加のＵＩに設定された表示条件（例えば、親のスクロールに追従、親の透過度に追従）に合わせて、追加のＵＩの表示制御を、柔軟に行うこともできる。

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

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

図４Ａ、図４Ｂおよび図４Ｃは、追加のＵＩの表示制御の一例を示す説明図である。図４Ａ、図４Ｂおよび図４Ｃの例では、追加のＵＩが、既存システムの画面２０に挿入される。既存システムの画面２０は、ＵＩ２１を含む。ＵＩ２１は、ＵＩ２２を含む。図４Ａに示された矢印は、画面２０のＤＯＭと、画面２０の見た目との対応を示す。

図４Ａの例では、追加のＵＩが、ＵＩ２２を基点としてＵＩ２２の下方に挿入される。例えば、WebMakeupなどの手法では、ＵＩ２３が、画面２０のＤＯＭツリーの途中に挿入される。ただし、既存のＤＯＭツリーの階層構造が壊れるため、このことが、システムに影響を与える可能性がある。そこで、特許文献１の手法は、ＵＩ２３を、画面２０のＤＯＭツリーの末尾に挿入することで、システムへの影響を軽減している。実施形態に係る表示制御システムは、後者の手法に関連するものである。

図４Ｂの例では、「annotation」というラベルが、追加のＵＩ（例えば、ＵＩ２３、ＵＩ２４）として初期表示される。そして、スクロールのイベントが、ＵＩ２１で発生する。WebMakeupなどの手法では、追加のＵＩは、自動的にスクロールされる。しかしながら、特許文献１の手法では、追加のＵＩはそのままではスクロールされないため、特許文献１の手法は、ＵＩ２２がスクロールされたことを検知し、追加のＵＩの表示位置を更新することを必要とする。

図４Ｃの例では、追加のＵＩは、追加のＵＩの表示位置の制御によって、ＵＩ２１で発生したスクロールのイベントに追従する。WebMakeupなどの手法では、追加のＵＩがスクロール領域外にあると、追加のＵＩが、自動的に非表示となる。しかしながら、特許文献１の手法では、そのままでは追加のＵＩは表示されたままとなるため、特許文献１の手法は、ＵＩ２２がスクロールされたことを検知し、基点となるＵＩが表示領域外にあることを判定する非表示処理を必要とする。

上述したように、特許文献１の手法等の、ＵＩ拡張の手法は、追加のＵＩの表示制御を必要とする場合がある。例えば、表示制御は、既存のシステムに存在するスクロール領域を持つＵＩに対して、スクロールのイベントを検知する。このような表示制御を実現するために、既存の手法は、スクロール領域を持つＵＩを探索する。より具体的には、既存の手法は、ＤＯＭツリーが更新されたタイミングで、スクロール領域を持つＵＩを、ＤＯＭツリーのルートから全探索している。そして、既存の手法は、探索されたＵＩに対して、スクロール時の追加のＵＩの表示更新処理を登録するイベント登録処理を行っている。

このように、ＵＩ拡張の手法は、既存のＵＩがスクロール等の変化を伴う場合に、階層的に追加のＵＩの親となる既存のＵＩの変化に合わせて、追加のＵＩの表示制御を行うことを必要とする場合がある。上述のように、既存の手法は、既存のＵＩの変化に対応するために、表示制御に使用される既存のＵＩを、ＤＯＭツリーのルートから全探索している。しかしながら、ＤＯＭツリーが大規模な場合には、ＵＩ探索の計算量が増加し、表示が遅延する場合がある。

そこで、実施形態に係る表示制御システムは、スクロール領域を持つＵＩ等の、追加のＵＩの表示制御に使用される既存のＵＩを、効率的に探索する。これにより、表示制御システムは、ＤＯＭツリーが大規模な場合であっても、表示の遅延を抑えることができる。

〔３．表示制御システムの構成〕
次に、図５を参照して、実施形態に係る表示制御システムの構成例について説明する。

図５は、実施形態に係る表示制御システム１の一例を示す図である。図５に示されるように、表示制御システム１は、端末装置１００と、コンテンツ提供装置２００とを含む。図５中では図示していないが、表示制御システム１は、複数台の端末装置１００や、複数台のコンテンツ提供装置２００を含んでもよい。

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

〔３－１．構成要素〕
端末装置１００は、追加のＵＩの表示制御に使用されるＵＩを探索するための処理を実行する情報処理装置である。端末装置１００は、クライアント装置を含む、任意のタイプの情報処理装置であってもよい。端末装置１００の構成例は、次の節で詳述される。

コンテンツ提供装置２００は、コンテンツ提供者によって利用される情報処理装置である。コンテンツ提供者は、システムの画面等のコンテンツを、端末装置１００に提供する。コンテンツ提供装置２００は、コンテンツに、追加のＵＩを挿入することができる。コンテンツ提供装置２００は、サーバを含む、任意のタイプの情報処理装置であってもよい。

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

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

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

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

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

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

（表示条件記憶部１４１）
表示条件記憶部１４１は、既存のＵＩを探索するために使用される表示条件を記憶する。表示条件記憶部１４１は、後述する探索部１５４によって決定された表示条件を記憶する。表示条件記憶部１４１は、後述する探索部１５４によって探索された既存のＵＩのキャッシュを、表示条件として記憶する。

（イベント処理コード記憶部１４２）
イベント処理コード記憶部１４２は、追加のＵＩの表示制御に使用されるイベント処理コードを記憶する。イベント処理コード記憶部１４２は、後述する登録部１５５によって登録されたイベント処理コードを記憶する。

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

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

（受信部１５１）
受信部１５１は、コンテンツ提供装置２００から、システムの画面等のコンテンツを受信する。受信部１５１は、受信されたコンテンツを、記憶部１４０に格納してもよい。

（検知部１５２）
検知部１５２は、追加のＵＩが挿入されたことを検知する。例えば、検知部１５２は、受信部１５１によって受信されたコンテンツを解析し、追加のＵＩがコンテンツに挿入されたことを検知する。

例えば、検知部１５２は、追加のＵＩが、システム画面に、システムとは独立したソフトウェアから挿入されたことを検知する。コンテンツ提供装置２００が、このソフトウェアを実装してもよい。検知部１５２は、システム画面のＤＯＭが変更されたことを検知する。

図６は、実施形態に係る端末装置１００によって実行される、追加のＵＩが挿入されたことを検知するための処理の一例を示すフローチャートである。

端末装置１００の検知部１５２は、既存システム画面が変更された、または追加のＵＩが挿入されたかを判定する（ステップＳ１０１）。

既存システム画面が変更されておらず、かつ追加のＵＩが挿入されていないと判定された場合に（ステップＳ１０１：Ｎｏ）、検知部１５２は、記憶部１４０のデータを削除する（ステップＳ１０２）。既存システム画面が変更された、または追加のＵＩが挿入されたと判定された場合に（ステップＳ１０１：Ｙｅｓ）、後述する探索部１５４が、追加のＵＩの表示制御に使用されるＵＩを探索する（ステップＳ１０３）。その後、検知部１５２は、次の変更まで待機する。

（取得部１５３）
取得部１５３は、システムの画面等のコンテンツのＤＯＭツリーを取得する。例えば、取得部１５３は、検知部１５２が追加のＵＩが画面に挿入されたことを検知した場合に、システムの画面のＤＯＭツリーを取得する。

（探索部１５４）
探索部１５４は、追加のＵＩの表示制御に使用されるＵＩを探索する。例えば、システムの画面のＤＯＭツリーから、追加のＵＩの表示制御に使用される既存のＵＩを探索する。既存のＵＩは、システムの画面に存在するＵＩである。この既存のＵＩは、システムの画面に追加されたＵＩの表示制御に使用される。

以下でより詳細に説明されるように、探索部１５４は、追加のＵＩの表示に関する表示条件に基づいて、追加のＵＩが挿入された画面のＤＯＭツリーにおいて、既存のＵＩを探索する。例えば、表示条件は、ＤＯＭツリーにおいて基点ＵＩより上位に位置するＵＩのスクロール、透明度及びサイズ変更のうちの少なくとも１つに関する条件である。言い換えると、追加のＵＩの表示に関する１つまたは複数の表示条件は、１）ＤＯＭツリーにおいて基点ＵＩより上位に位置するＵＩのスクロールに関する条件、２）このＵＩの透明度に関する条件、および３）このＵＩのサイズ変更に関する条件のうちの少なくとも１つを含み得る。表示条件は、１）の条件、２）の条件、３）の条件、またはこれらの任意の組み合わせであってもよい。なお、表示条件は、これらの条件に限定されるものではない。１つまたは複数の表示条件は、これらの条件以外の条件（例えば、z-indexに関する条件）を含んでもよい。

ＵＩの探索の入力は、１）取得部１５３によって取得されたＤＯＭツリー、２）追加のＵＩの表示の基点となる既存のＵＩ（基点ＵＩと呼ばれる）、および３）追加のＵＩに設定された表示条件である。探索部１５４は、追加のＵＩの表示制御に使用される既存のＵＩを、検知部１５２によって検知された追加のＵＩの表示制御に関する情報として探索する。

図７は、典型的なＵＩ探索の一例を示す説明図である。図７の例では、システム画面のＤＯＭツリーは、既存システム画面のＤＯＭツリー３１および追加ＵＩのＤＯＭツリー３２を含む。典型的なＵＩ探索は、既存システム画面のＤＯＭツリーを、システム画面ルートから全探索する。

図７の例では、典型的なＵＩ探索は、スクロール領域を持つ既存ＵＩについての全探索を実行する。基点ＵＩがスクロール領域を持つ既存ＵＩの配下にある場合に、この既存ＵＩをキーとして使用して、表示条件を記憶装置に格納する。

しかしながら、典型的なＵＩ探索は、無駄な探索を実行する場合があり、探索効率が悪い。例えば、基点ＵＩがスクロール領域を持つ既存ＵＩの配下にない場合に、この既存ＵＩの探索は、不要な探索である。このように、基点ＵＩが既存ＵＩの配下に存在しない場合に、この既存ＵＩは、追加ＵＩの表示制御処理とは無関係である。したがって、この既存ＵＩの探索は、本来不要である。

図８は、実装例に係るＵＩ探索の一例を示す説明図である。上述の典型的なＵＩ探索の場合と同様に、システム画面のＤＯＭツリーは、既存システム画面のＤＯＭツリー３１および追加ＵＩのＤＯＭツリー３２を含む。実装例に係るＵＩ探索は、システム画面ルートからではなく、基点ＵＩから、追加ＵＩの表示制御処理に関係する既存ＵＩを探索する。

実装例に係るＵＩ探索は、表示制御処理に関係する既存ＵＩを、基点ＵＩから親に向かって探索する。実装例に係るＵＩ探索では、探索部１５４は、１）システム画面ルート、２）同じ条件の基点ＵＩ、または３）同じ条件で探索済みの既存ＵＩを発見した場合に、探索部１５４は、探索を終了する。

探索部１５４は、１）、２）および３）の処理を、全ての基点ＵＩから実行する。そして、既存ＵＩをキーとして使用して、表示制御処理に対応する表示条件を、記憶部１４０に格納する。これにより、探索部１５４は、追加ＵＩの表示制御処理とは無関係である既存ＵＩの探索をなくすことができ、それによって、探索効率を向上させることができる。

図９は、記憶部１４０に保持される情報の一例を示す説明図である。探索部１５４は、表示条件を、記憶部１４０内の表示条件記憶部１４１に格納する。表示条件４３は、表示条件記憶部１４１に格納される表示条件の一例である。探索部１５４は、表示条件４３によって示されるように、１つのキーに対して、複数の条件を登録することができる。

図９の例では、システム画面のＤＯＭツリーは、既存システム画面のＤＯＭツリー４１および追加ＵＩのＤＯＭツリー４２を含む。既存システム画面のＤＯＭツリー４１は、複数の基点ＵＩおよび複数の既存ＵＩを含む。追加ＵＩのＤＯＭツリー４２は、追加ＵＩ（１）および追加ＵＩ（２）を含む。

複数の既存ＵＩのうちの既存ＵＩ（１）は、スクロール領域を持つ。また、透過度が、既存ＵＩ（１）に設定されている。複数の既存ＵＩのうちの既存ＵＩ（２）は、スクロール領域を持つ。

複数の基点ＵＩのうちの基点ＵＩ－Ａは、追加ＵＩ（１）および追加ＵＩ（２）から基点ＵＩに設定されている。追加ＵＩ（１）に設定された条件は、親のスクロールに追従することである。一方、追加ＵＩ（２）に設定された条件は、親の透過度に追従することである。

探索部１５４は、追加ＵＩに設定された条件に対応する既存ＵＩを、基点ＵＩから探索する。そして、探索部１５４は、探索された基点ＵＩをキーとして使用して、表示条件を表示条件記憶部１４１に格納する。

図１０Ａおよび図１０Ｂは、追加のＵＩの表示制御に使用されるＵＩを探索する探索処理の一例を示す説明図である。図１０Ａおよび図１０Ｂの例では、追加ＵＩの条件が、同じである。追加ＵＩ（１）に設定された表示条件は、追加ＵＩ（２）に設定された表示条件と同じである。探索部１５４は、表示条件に対応するＵＩを、基点ＵＩからシステム画面のルートに向かって探索する。そして、探索部１５４は、既に探索され、同じ条件を有する既存ＵＩを、スキップする。

図１０Ａおよび図１０Ｂの例では、システム画面５１は、既存ＵＩ（１）を含む。既存ＵＩ（１）は、既存ＵＩ（２）および既存ＵＩ（４）を含む。既存ＵＩ（２）は、既存ＵＩ（３）、基点ＵＩ（２）および追加ＵＩ（２）を含む。既存ＵＩ（３）は、基点ＵＩ（１）および追加ＵＩ（１）を含む。

図１０Ａおよび図１０Ｂの例では、既存ＵＩ（１）、既存ＵＩ（２）および既存ＵＩ（３）は、スクロール領域を持つ。一方、既存ＵＩ（４）は、スクロール領域を持たない。

図１０Ａを参照すると、はじめに、探索部１５４は、追加ＵＩ（１）が既存システム画面に追加されたことを検知する（ステップＳ１１）。追加ＵＩ（１）に設定された条件は、親のスクロールに追従することである。追加ＵＩのＤＯＭツリーは、既存システム画面のＤＯＭツリーの末尾に挿入される。

次いで、探索部１５４は、既存システム画面のＤＯＭツリーを取得する（ステップＳ１２）。

次いで、探索部１５４は、追加ＵＩ（１）の基点ＵＩを取得する（ステップＳ１３）。図１０Ａの例では、探索部１５４は、基点ＵＩ（１）を取得する。図１０Ａの例では、探索部１５４は、記憶部（例えば、記憶部１４０内の表示条件記憶部１４１）に、基点ＵＩ（１）をキーとして使用して、追加ＵＩ（１）に設定された条件を格納する。

次いで、探索部１５４は、スクロール領域を持つＵＩを、システム画面ルートに向かって探索する（ステップＳ１４）。図１０Ａの例では、基点ＵＩ（１）からシステム画面ルートまでの経路は、既存ＵＩ（１）、既存ＵＩ（２）および既存ＵＩ（３）を含む。これらの既存ＵＩは、スクロール領域を持つ。このため、探索部１５４は、既存ＵＩ（１）、既存ＵＩ（２）および既存ＵＩ（３）をキーとして使用して、「スクロール領域を持つ」という条件を、記憶部に格納する。図１０Ａの例では、記憶部は、表示条件５２を記憶する。

図１０Ｂを参照すると、図１０ＡのステップＳ１４の後に、探索部１５４は、追加ＵＩ（２）が既存システム画面に追加されたことを検知する（ステップＳ１５）。追加ＵＩ（２）に設定された条件は、親のスクロールに追従することである。

次いで、探索部１５４は、追加ＵＩ（２）の基点ＵＩを取得する（ステップＳ１６）。図１０Ｂの例では、探索部１５４は、基点ＵＩ（２）を取得する。

次いで、探索部１５４は、既存システム画面のＤＯＭツリーを取得する（ステップＳ１７）。

その後、探索部１５４は、スクロール領域を持つＵＩを、システム画面ルートに向かって探索する。探索開始時の記憶部は、表示条件５２を記憶する。図１０Ｂの例では、既存ＵＩ（２）が、基点ＵＩ（２）の親に位置する。記憶部に同じ条件を含む既存ＵＩ（２）が登録されているので、探索部１５４は、以降の探索を終了する（ステップＳ１８）。

図１１Ａおよび図１１Ｂは、追加のＵＩの表示制御に使用されるＵＩを探索する探索処理の一例を示す説明図である。図１１Ａおよび図１１Ｂの例では、追加ＵＩの条件が同じであり、複数の基点が親子関係にある。同じ条件で探索された基点ＵＩが親にある場合に、探索部１５４は、以降の探索をスキップする。

図１１Ａおよび図１１Ｂの例では、システム画面５３は、既存ＵＩ（１）を含む。既存ＵＩ（１）は、既存ＵＩ（２）および既存ＵＩ（４）を含む。既存ＵＩ（２）は、基点ＵＩ（１）、既存ＵＩ（３）および追加ＵＩ（１）を含む。基点ＵＩ（１）は、基点ＵＩ（２）および追加ＵＩ（２）を含む。

図１１Ａおよび図１１Ｂの例では、既存ＵＩ（１）および既存ＵＩ（２）、ならびに基点ＵＩ（１）は、スクロール領域を持つ。一方、既存ＵＩ（４）は、スクロール領域を持たない。

図１１Ａを参照すると、はじめに、探索部１５４は、追加ＵＩ（１）が既存システム画面に追加されたことを検知する（ステップＳ２１）。追加ＵＩ（１）に設定された条件は、親のスクロールに追従することである。

次いで、探索部１５４は、既存システム画面のＤＯＭツリーを取得する（ステップＳ２２）。

次いで、探索部１５４は、追加ＵＩ（１）の基点ＵＩを取得する（ステップＳ２３）。図１１Ａの例では、探索部１５４は、基点ＵＩ（１）を取得する。図１１Ａの例では、探索部１５４は、記憶部（例えば、記憶部１４０内の表示条件記憶部１４１）に、基点ＵＩ（１）をキーとして使用して、追加ＵＩ（１）に設定された条件を格納する。

次いで、探索部１５４は、スクロール領域を持つＵＩを、システム画面ルートに向かって探索する（ステップＳ２４）。図１１Ａの例では、基点ＵＩ（１）からシステム画面ルートまでの経路は、既存ＵＩ（１）および既存ＵＩ（２）を含む。これらの既存ＵＩは、スクロール領域を持つ。このため、探索部１５４は、既存ＵＩ（１）および既存ＵＩ（２）をキーとして使用して、「スクロール領域を持つ」という条件を、記憶部に格納する。図１１Ａの例では、記憶部は、表示条件５４を記憶する。

図１１Ｂを参照すると、図１１ＡのステップＳ２４の後に、探索部１５４は、追加ＵＩ（２）が既存システム画面に追加されたことを検知する（ステップＳ２５）。追加ＵＩ（２）に設定された条件は、親のスクロールに追従することである。

次いで、探索部１５４は、追加ＵＩ（２）の基点ＵＩを取得する（ステップＳ２６）。図１１Ｂの例では、探索部１５４は、基点ＵＩ（２）を取得する。

次いで、探索部１５４は、既存システム画面のＤＯＭツリーを取得する（ステップＳ２７）。

その後、探索部１５４は、スクロール領域を持つＵＩを、システム画面ルートに向かって探索する。探索開始時の記憶部は、表示条件５４を記憶する。図１１Ｂの例では、基点ＵＩ（１）が、基点ＵＩ（２）の親に位置する。記憶部に同じ条件を含む基点ＵＩ（１）が登録されているので、探索部１５４は、以降の探索を終了する（ステップＳ２８）。

図１２Ａおよび図１２Ｂは、追加のＵＩの表示制御に使用されるＵＩを探索する探索処理の一例を示す説明図である。図１２Ａおよび図１２Ｂの例では、追加ＵＩに複数の条件がある。

図１２Ａおよび図１２Ｂの例では、システム画面５５は、既存ＵＩ（１）を含む。既存ＵＩ（１）は、既存ＵＩ（２）および既存ＵＩ（４）を含む。既存ＵＩ（２）は、既存ＵＩ（３）、基点ＵＩ（２）および追加ＵＩ（２）を含む。既存ＵＩ（３）は、基点ＵＩ（１）および追加ＵＩ（１）を含む。

図１２Ａおよび図１２Ｂの例では、既存ＵＩ（１）、既存ＵＩ（２）および既存ＵＩ（３）は、スクロール領域を持つ。また、既存ＵＩ（３）は、透明度を持つ。一方、既存ＵＩ（４）は、スクロール領域を持たない。

図１２Ａを参照すると、はじめに、探索部１５４は、追加ＵＩ（１）が既存システム画面に追加されたことを検知する（ステップＳ３１）。追加ＵＩ（１）に設定された条件は、親のスクロールに追従することおよび親の透明度に追従することである。

次いで、探索部１５４は、既存システム画面のＤＯＭツリーを取得する（ステップＳ３２）。

次いで、探索部１５４は、追加ＵＩ（１）の基点ＵＩを取得する（ステップＳ３３）。図１２Ａの例では、探索部１５４は、基点ＵＩ（１）を取得する。図１２Ａの例では、探索部１５４は、記憶部（例えば、記憶部１４０内の表示条件記憶部１４１）に、基点ＵＩ（１）をキーとして使用して、追加ＵＩ（１）に設定された条件を格納する。

次いで、探索部１５４は、スクロール領域を持つＵＩを、システム画面ルートに向かって探索する（ステップＳ３４）。図１２Ａの例では、基点ＵＩ（１）からシステム画面ルートまでの経路は、既存ＵＩ（３）、既存ＵＩ（２）および既存ＵＩ（１）を含む。これらの既存ＵＩは、スクロール領域や透明度を持つ。このため、探索部１５４は、既存ＵＩ（１）、既存ＵＩ（２）および既存ＵＩ（３）をキーとして使用して、「スクロール領域を持つ」という条件や「透明度を持つ」という条件を、記憶部に格納する。図１２Ａの例では、記憶部は、表示条件５６を記憶する。

図１２Ｂを参照すると、図１２ＡのステップＳ３４の後に、探索部１５４は、追加ＵＩ（２）が既存システム画面に追加されたことを検知する（ステップＳ３５）。追加ＵＩ（２）に設定された条件は、親のスクロールに追従することである。

次いで、探索部１５４は、追加ＵＩ（２）の基点ＵＩを取得する（ステップＳ３６）。図１２Ｂの例では、探索部１５４は、基点ＵＩ（２）を取得する。

次いで、探索部１５４は、既存システム画面のＤＯＭツリーを取得する（ステップＳ３７）。

その後、探索部１５４は、スクロール領域を持つＵＩを、システム画面ルートに向かって探索する。探索開始時の記憶部は、表示条件５６を記憶する。図１２Ｂの例では、既存ＵＩ（２）が、基点ＵＩ（２）の親に位置する。記憶部に同じ条件を含む既存ＵＩ（２）が登録されているので、探索部１５４は、以降の探索を終了する（ステップＳ３８）。

（登録部１５５）
登録部１５５は、探索部１５４によって探索されたＵＩに対して、追加のＵＩの表示制御に使用されるイベント処理を登録する。登録部１５５は、既存のＵＩの表示条件に応じたイベントを登録する。登録部１５５は、追加のＵＩの表示制御に使用されるイベント処理コードを、イベント処理コード記憶部１４２に格納してもよい。

（表示部１５６）
表示部１５６は、例えば、ＣＰＵやＭＰＵ等によって、上述のイベント処理コードがＲＡＭを作業領域として実行されることにより実現される。例えば、上述のイベント処理コードは、表示条件に応じたイベント処理手順を、端末装置１００に実行させる。この場合、表示部１５６は、イベント処理手順により実現される。

図１３は、実施形態に係る端末装置１００によって実行される、表示条件に応じたイベント処理の一例を示すフローチャートである。図１３の例では、表示条件は、スクロールへの追従である。スクロールが既存ＵＩで発生した場合に、追加のＵＩが、このスクロールに追従し、追加のＵＩの表示位置が、修正される。

はじめに、表示部１５６は、スクロールのイベントが発生したことを検知する（ステップＳ２０１）。イベントが短時間で連続で発生した場合には、表示部１５６は、最後に発生したイベントまで待機する（ステップＳ２０２）。

次いで、表示部１５６は、スクロールが発生した既存ＵＩのＤＯＭツリーの配下にある基点ＵＩの中から、対応する追加ＵＩで、表示条件（すなわち、スクロールへの追従）の基点ＵＩを抽出する（ステップＳ２０３）。

次いで、表示部１５６は、抽出された全ての基点ＵＩの処理が完了したかを判定する（ステップＳ２０４）。

抽出された全ての基点ＵＩの処理が完了していないと判定された場合に（ステップＳ２０４：Ｎｏ）、表示部１５６は、基点ＵＩが表示領域内に存在するかを判定する（ステップＳ２０５）。

基点ＵＩが表示領域内に存在しないと判定された場合に（ステップＳ２０５：Ｎｏ）、表示部１５６は、基点ＵＩに対応する追加ＵＩを非表示にする（ステップＳ２０６）。そして、表示部１５６は、再度ステップＳ２０４を実行する。

基点ＵＩが表示領域内に存在すると判定された場合に（ステップＳ２０５：Ｙｅｓ）、表示部１５６は、基点ＵＩに対応する追加ＵＩの表示位置を、既存ＵＩのスクロール量だけ修正し、追加ＵＩを表示する（ステップＳ２０７）。そして、表示部１５６は、再度ステップＳ２０４を実行する。

ステップＳ２０４において、抽出された全ての基点ＵＩの処理が完了したと判定された場合に（ステップＳ２０４：Ｙｅｓ）、表示条件に応じたイベント処理は、終了する。

図１４は、イベント発生時の画面表示の一例を示す説明図である。図１３の場合と同様に、図１４の例では、表示条件は、スクロールへの追従である。追加ＵＩが、画面６１に挿入されている。また、基点ＵＩが、追加ＵＩに設定されている。画面６１のＤＯＭツリーでは、基点ＵＩが、既存ＵＩ（１）および既存ＵＩ（２）の配下にある。

図１４の例では、図１３を参照して上述したイベント処理が、登録部１５５によって登録されている。スクロールが発生した場合に、システム画面は、画面６１から画面６２に変化する。追加ＵＩの表示位置は、画面６２において示されるように、イベント処理に従って、修正される。このため、イベント処理は、追加ＵＩが置き去りにされるのを防止することができる。

図１５は、実施形態に係る端末装置１００によって実行される、表示条件に応じたイベント処理の一例を示すフローチャートである。図１５の例では、表示条件は、透過度への追従である。透過度の変化が既存ＵＩで発生した場合に、追加のＵＩが、この透過度の変化に追従し、追加のＵＩの表示が、修正される。

はじめに、表示部１５６は、透過度の変化のイベントが発生したことを検知する（ステップＳ３０１）。イベントが短時間で連続で発生した場合には、表示部１５６は、最後に発生したイベントまで待機する（ステップＳ３０２）。

次いで、表示部１５６は、透過度の変化が発生した既存ＵＩのＤＯＭツリーの配下にある基点ＵＩの中から、対応する追加ＵＩで、表示条件（すなわち、透過度への追従）の基点ＵＩを抽出する（ステップＳ３０３）。

ステップＳ３０４、ステップＳ３０５およびステップＳ３０６は、図１３のステップＳ２０４、ステップＳ２０５およびステップＳ２０６と同様である。ここでは、重複する説明は、省略される。

基点ＵＩが表示領域内に存在すると判定された場合に（ステップＳ３０５：Ｙｅｓ）、表示部１５６は、基点ＵＩに対応する追加ＵＩの透過度の値を、既存ＵＩの透過度の値に修正し、追加ＵＩを表示する（ステップＳ３０７）。そして、表示部１５６は、再度ステップＳ３０４を実行する。

ステップＳ３０４において、抽出された全ての基点ＵＩの処理が完了したと判定された場合に（ステップＳ３０４：Ｙｅｓ）、表示条件に応じたイベント処理は、終了する。

図１６は、イベント発生時の画面表示の一例を示す説明図である。図１５の場合と同様に、図１６の例では、表示条件は、透過度への追従である。追加ＵＩが、画面６３に挿入されている。また、基点ＵＩが、追加ＵＩに設定されている。画面６３のＤＯＭツリーでは、基点ＵＩが、既存ＵＩ（１）および既存ＵＩ（２）の配下にある。また、既存ＵＩ（３）も、既存ＵＩ（１）および既存ＵＩ（２）の配下にある。

図１６の例では、図１５を参照して上述したイベント処理が、登録部１５５によって登録されている。既存ＵＩ（２）の透過度が変化した場合に、既存ＵＩ（３）および基点ＵＩの色も、変化する。もし、イベント処理が登録されていなければ、追加ＵＩの周辺の既存ＵＩ（３）の色は、既存ＵＩ（２）の透過度によって変化するが、追加ＵＩの色が、変化しない。このような場合、追加ＵＩは、浮いて表示されてしまう。イベント処理が登録されている場合には、システム画面は、画面６３から画面６４に変化する。イベント処理が適用され、追加ＵＩは、自然に表示される。このため、イベント処理は、追加ＵＩがシステム画面で浮いてしまうのを防止することができる。

図１７は、実施形態に係る端末装置１００によって実行される、表示条件に応じたイベント処理の一例を示すフローチャートである。図１７の例では、表示条件は、サイズ変更への追従である。サイズ変更が既存ＵＩで発生した場合に、追加のＵＩが、このサイズ変更に追従し、追加のＵＩの表示が、修正される。

はじめに、表示部１５６は、サイズ変更のイベントが発生したことを検知する（ステップＳ４０１）。イベントが短時間で連続で発生した場合には、表示部１５６は、最後に発生したイベントまで待機する（ステップＳ４０２）。

次いで、表示部１５６は、サイズ変更が発生した既存ＵＩのＤＯＭツリーの配下にある基点ＵＩの中から、対応する追加ＵＩで、表示条件（すなわち、サイズ変更への追従）の基点ＵＩを抽出する（ステップＳ４０３）。

ステップＳ４０４、ステップＳ４０５およびステップＳ４０６は、図１３のステップＳ２０４、ステップＳ２０５およびステップＳ２０６と同様である。ここでは、重複する説明は、省略される。

基点ＵＩが表示領域内に存在すると判定された場合に（ステップＳ４０５：Ｙｅｓ）、表示部１５６は、基点ＵＩに対応する追加ＵＩを表示する（ステップＳ４０７）。そして、表示部１５６は、再度ステップＳ４０４を実行する。

ステップＳ４０４において、抽出された全ての基点ＵＩの処理が完了したと判定された場合に（ステップＳ４０４：Ｙｅｓ）、表示条件に応じたイベント処理は、終了する。

図１８は、イベント発生時の画面表示の一例を示す説明図である。図１７の場合と同様に、図１８の例では、表示条件は、サイズ変更への追従である。追加ＵＩが、画面６５に挿入されている。また、基点ＵＩが、追加ＵＩに設定されている。画面６５のＤＯＭツリーでは、基点ＵＩが、既存ＵＩ（１）および既存ＵＩ（２）の配下にある。

図１８の例では、図１７を参照して上述したイベント処理が、登録部１５５によって登録されている。既存ＵＩ（２）のサイズが変更された場合に、システム画面は、画面６５から画面６６に変化する。図１８の例では、基点ＵＩが、表示領域外にある。追加ＵＩは、画面６５において示されるように、イベント処理に従って、非表示に設定される。

〔４．探索処理のフロー〕
次に、図１９を参照して、実施形態に係る端末装置１００による探索処理の手順について説明する。

図１９は、実施形態に係る端末装置１００によって実行される、追加のＵＩの表示制御に使用されるＵＩを探索するための処理の一例を示すフローチャートである。

図１９に示されるように、はじめに、端末装置１００の取得部１５３は、追加されたＵＩの条件を取得する（ステップＳ５０１）。より具体的には、取得部１５３は、追加されたＵＩ（すなわち、上述の追加のＵＩ）の表示条件を取得する。

次いで、取得部１５３は、既存システム画面のＤＯＭツリーを取得して返却（return）する（ステップＳ５０２）。

次いで、端末装置１００の探索部１５４は、既存システム画面のＤＯＭツリーから、追加されたＵＩに設定された基点ＵＩを取得する（ステップＳ５０３）。上述のように、基点ＵＩは、追加されたＵＩの表示の基点となるＵＩである。

次いで、探索部１５４は、記憶部１４０に、基点ＵＩをキーとして、追加されたＵＩの条件を追加保存する（ステップＳ５０４）。より具体的には、探索部１５４は、基点ＵＩをキーとして使用して、追加されたＵＩの表示条件を、表示条件記憶部１４１に格納する。

次いで、探索部１５４は、基点ＵＩを現在のＵＩに設定する（ステップＳ５０５）。言い換えると、探索部１５４は、基点ＵＩを、探索点に設定する。上述のように、基点ＵＩは、探索起点に相当する。

次いで、探索部１５４は、現在のＵＩの親に位置する既存ＵＩを取得する（ステップＳ５０６）。

次いで、探索部１５４は、取得された既存ＵＩがシステム画面ルートであるかを判定する（ステップＳ５０７）。取得された既存ＵＩがシステム画面ルートであると判定された場合に（ステップＳ５０７：Ｙｅｓ）、追加のＵＩの表示制御に使用されるＵＩを探索するための処理は、終了する。

取得された既存ＵＩがシステム画面ルートでないと判定された場合に（ステップＳ５０７：Ｎｏ）、探索部１５４は、既存ＵＩが記憶部１４０に存在するかを判定する（ステップＳ５０８）。より具体的には、探索部１５４は、既存ＵＩが表示条件記憶部１４１に、キーとして記憶されているかを判定する。

既存ＵＩが記憶部１４０に存在すると判定された場合に（ステップＳ５０８：Ｙｅｓ）、探索部１５４は、記憶部１４０から、既存ＵＩをキーとして、条件の一覧を取得する（ステップＳ５０９）。条件の一覧は、例えば、「スクロール領域を持つ」、「透明度が設定されている」等の表示条件である。

次いで、探索部１５４は、追加されたＵＩの条件が取得された条件の一覧に含まれるかを判定する（ステップＳ５１０）。

追加されたＵＩの条件が取得された条件の一覧に含まれないと判定された場合に（ステップＳ５１０：Ｎｏ）、探索部１５４は、既存ＵＩが追加された条件に一致するかを判定する（ステップＳ５１１）。一例として、追加されたＵＩの条件が「親のスクロールに追従」である場合に、探索部１５４は、既存ＵＩがスクロール領域を持つかを判定する。

ステップＳ５０８において、既存ＵＩが記憶部１４０に存在しないと判定された場合に（ステップＳ５０８：Ｎｏ）、追加のＵＩの表示制御に使用されるＵＩを探索するための処理は、ステップＳ５１１に移行する。

既存ＵＩが追加された条件に一致すると判定された場合に（ステップＳ５１１：Ｙｅｓ）、探索部１５４は、記憶部１４０に、既存ＵＩをキーとして、追加されたＵＩの条件を追加保存する（ステップＳ５１２）。一例として、追加されたＵＩの条件が「親のスクロールに追従」であり、既存ＵＩがスクロール領域を持つ場合に、探索部１５４は、この既存ＵＩに関連付けられた「スクロール領域を持つ」という表示条件を、表示条件記憶部１４１に格納する。

次いで、端末装置１００の登録部１５５は、既存ＵＩに対して条件に応じたイベントを登録する（ステップＳ５１３）。図５を参照して上述したように、例えば、登録部１５５は、既存ＵＩのイベント（例えば、スクロール）に対して、追加されたＵＩの表示制御に使用されるイベント処理を登録する。例えば、登録部１５５は、特定のイベント（例えば、スクロール）が発生した場合のイベント処理のコードを、イベント処理コード記憶部１４２に格納する。

次いで、端末装置１００の探索部１５４は、既存ＵＩを現在のＵＩに設定する（ステップＳ５１４）。そして、探索部１５４は、再度ステップＳ５０６を実行する。

ステップＳ５１０において、追加されたＵＩの条件が取得された条件の一覧に含まれると判定された場合に（ステップＳ５１０：Ｙｅｓ）、追加のＵＩの表示制御に使用されるＵＩを探索するための処理は、終了する。

〔５．効果〕
上述してきたように、実施形態に係る表示制御システム１は、取得部１５３と、探索部１５４とを有する。

実施形態に係る表示制御システム１において、取得部１５３は、追加のＵＩが挿入された画面のＤＯＭツリーを取得する。また、実施形態に係る表示制御システム１において、探索部１５４は、追加のＵＩの表示に関する表示条件に基づいて、ＤＯＭツリーにおいて、追加のＵＩの表示の基点となる基点ＵＩから、追加のＵＩの表示制御に使用されるＵＩを探索する。

これにより、実施形態に係る表示制御システム１は、追加のＵＩの表示制御に使用されるＵＩの探索を効率よく行うことができる。

また、実施形態に係る表示制御システム１において、探索部１５４は、追加のＵＩの表示制御に使用されるＵＩを、基点ＵＩから、ＤＯＭツリーのルートに向かって再帰的に探索し、基点ＵＩをキーとして使用して、表示条件を、所定の記憶装置（例えば、表示条件記憶部１４１）に格納し、探索されたＵＩをキーとして使用して、表示条件を、この所定の記憶装置に格納する。

これにより、実施形態に係る表示制御システム１は、ＵＩ拡張において使用される、追加のＵＩの表示制御に使用される既存のＵＩ探索に関して、無駄な探索を大幅に削減し、効率的な探索を実現することができる。

また、実施形態に係る表示制御システム１において、取得部１５３は、他の追加のＵＩが、追加のＵＩに加えて挿入された画面のＤＯＭツリーを取得する。また、実施形態に係る表示制御システム１において、探索部１５４は、他の追加のＵＩの表示に関する表示条件が、所定の記憶装置（例えば、表示条件記憶部１４１）に記憶された表示条件と一致する場合に、他の追加の表示制御に使用されるＵＩの探索を終了する。

これにより、実施形態に係る表示制御システム１は、追加のＵＩの表示を高速化し、画面にＵＩ拡張を適用する際の負荷を軽減することができる。

また、実施形態に係る表示制御システム１において、追加のＵＩの表示に関する表示条件は、ＤＯＭツリーにおいて基点ＵＩより上位に位置するＵＩのスクロール、透明度及びサイズ変更のうちの少なくとも１つに関する条件である。

これにより、実施形態に係る表示制御システム１は、透過度、サイズ変更またはz-index等の、表示制御の対象でなかった親要素の表示状況に合わせて、追加のＵＩの表示を制御することができる。このため、表示制御システム１は、追加のＵＩを、より自然に既存のシステムに表示することができる。

また、実施形態に係る表示制御システム１は、追加のＵＩが画面に挿入されたことを検知する検知部１５２を有する。また、実施形態に係る表示制御システム１において、取得部１５３は、検知部１５２が追加のＵＩが画面に挿入されたことを検知した場合に、画面のＤＯＭツリーを取得する。

これにより、実施形態に係る表示制御システム１は、ＵＩが動的に追加された場合でも、追加のＵＩの表示制御を行うことができる。

〔６．他の実施形態〕
上述の実施形態に係る表示制御システム１は、上述の実施形態以外にも、種々の異なる形態で実施されてよい。そこで、以下では、上記の表示制御システム１の他の実施形態について説明する。

〔６－１．端末装置による表示制御処理の実行主体〕
コンテンツ提供装置２００は、上述の実施形態において端末装置１００によって実行された処理の全部または一部を実行してもよい。例えば、コンテンツ提供装置２００は、受信部１５１、検知部１５２、取得部１５３、探索部１５４、登録部１５５に関して上述した情報処理の全部または一部を行ってもよい。

一例として、コンテンツ提供装置２００は、他のコンテンツ提供装置から、コンテンツを受信してもよい。そして、コンテンツ提供装置２００は、受信されたコンテンツを使用して、検知部１５２、取得部１５３、探索部１５４、登録部１５５に関して上述した情報処理を行ってもよい。

コンテンツ提供装置２００は、上述のイベント処理コードを生成し、生成されたイベント処理コードとともに、コンテンツを端末装置１００に提供してもよい。この場合、端末装置１００、コンテンツ提供装置２００から提供されたコンテンツとイベント処理コードに基づいて、表示部１５６に関して上述した情報処理を行ってもよい。

図５を参照して上述したように、表示制御システム１は、端末装置１００と、コンテンツ提供装置２００とを含む。コンテンツ提供装置２００が、受信部１５１、検知部１５２、取得部１５３、探索部１５４、登録部１５５に関して上述した情報処理の一部を分担してもよい。

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

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

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

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

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

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

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

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

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

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

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

１ 表示制御システム
１００ 端末装置
１１０ 通信部
１２０ 入力部
１３０ 出力部
１４０ 記憶部
１４１ 表示条件記憶部
１４２ イベント処理コード記憶部
１５０ 制御部
１５１ 受信部
１５２ 検知部
１５３ 取得部
１５４ 探索部
１５５ 登録部
１５６ 表示部
２００ コンテンツ提供装置

Claims (7)

1. 追加のＵＩが挿入された画面のＤＯＭツリーを取得する取得部と、
   前記追加のＵＩの表示に関する表示条件に基づいて、前記ＤＯＭツリーにおいて、前記追加のＵＩの表示の基点となる基点ＵＩから、前記追加のＵＩの表示制御に使用されるＵＩを探索する探索部と
   を備えることを特徴とする表示制御システム。
2. 前記探索部は、前記追加のＵＩの表示制御に使用されるＵＩを、前記基点ＵＩから、前記ＤＯＭツリーのルートに向かって再帰的に探索し、前記基点ＵＩをキーとして使用して、前記表示条件を、所定の記憶装置に格納し、探索されたＵＩをキーとして使用して、前記表示条件を、当該所定の記憶装置に格納する
   ことを特徴とする請求項１に記載の表示制御システム。
3. 前記取得部は、他の追加のＵＩが、前記追加のＵＩに加えて挿入された前記画面の前記ＤＯＭツリーを取得し、
   前記探索部は、前記他の追加のＵＩの表示に関する表示条件が、前記所定の記憶装置に記憶された表示条件と一致する場合に、前記他の追加の表示制御に使用されるＵＩの探索を終了する
   ことを特徴とする請求項２に記載の表示制御システム。
4. 前記追加のＵＩの表示に関する表示条件は、前記ＤＯＭツリーにおいて前記基点ＵＩより上位に位置するＵＩのスクロール、透明度及びサイズ変更のうちの少なくとも１つに関する条件である
   ことを特徴とする請求項１～３のうちいずれか１つに記載の表示制御システム。
5. 前記追加のＵＩが前記画面に挿入されたことを検知する検知部をさらに備え、
   前記取得部は、前記検知部が前記追加のＵＩが前記画面に挿入されたことを検知した場合に、前記画面のＤＯＭツリーを取得する
   ことを特徴とする請求項１～４のうちいずれか１つに記載の表示制御システム。
6. コンピュータが実行する表示制御方法であって、
   追加のＵＩが挿入された画面のＤＯＭツリーを取得する取得工程と、
   前記追加のＵＩの表示に関する表示条件に基づいて、前記ＤＯＭツリーにおいて、前記追加のＵＩの表示の基点となる基点ＵＩから、前記追加のＵＩの表示制御に使用されるＵＩを探索する探索工程と
   を含むことを特徴とする表示制御方法。
7. 追加のＵＩが挿入された画面のＤＯＭツリーを取得する取得手順と、
   前記追加のＵＩの表示に関する表示条件に基づいて、前記ＤＯＭツリーにおいて、前記追加のＵＩの表示の基点となる基点ＵＩから、前記追加のＵＩの表示制御に使用されるＵＩを探索する探索手順と
   をコンピュータに実行させることを特徴とする表示制御プログラム。

Images