JP5200095B2 - ユーザインタフェース生成装置 - Google Patents

Description

関連出願の相互参照

本出願は、２００８年２月２７日に出願された日本国特許出願２００８−４５７２６号、および２００８年３月２８日に出願された日本国特許出願２００８−８８２４８号の優先権を主張するものであり、これらの先の出願の開示全体をここに参照のために取り込む。

本発明は、ユーザインタフェース生成装置に関し、特に、携帯端末のユーザインタフェースを生成するユーザインタフェース生成装置に関するものである。

関連技術

携帯電話に代表される携帯端末のユーザインタフェース（以下、適宜「ＵＩ」と略記する）は、ユーザが携帯端末を操作する際の操作性を大きく左右する。そのため、携帯端末のＵＩは、ユーザが携帯端末を購入する際の決め手となる重要な要素の１つになっている。

近年、携帯端末は著しく多機能化し、それに伴いアニメーションや３Ｄの表現などを利用した表現力豊かなＵＩを備える携帯端末も多い。また、ユーザの嗜好に合わせてＵＩをカスタマイズできる携帯端末もあり、このような携帯端末は、ユーザにとっての利便性を著しく向上させている。

従来の携帯端末は、各メーカ間および各機種間でＵＩのデザインや操作方法が異なるのが一般的であった。すなわち、ＵＩは各端末機器に固有のものであり、端末ごとに機種依存性の高いＵＩを備えるものがほとんどであった。そのため、端末の開発を行う際に、他の端末のプログラムコードを再利用する場合、そのプログラムコードに対して必要なＵＩ部分の変更は膨大になる。したがって、ある端末のプログラムコードを他の端末に移植するのは困難であった。

そこで、最近では、ＸＭＬ（Extensible Markup Language）をベースにしたＵＩが導入されつつある。記述方式が共通化されたＸＭＬファイルを用いてＵＩを表現することによって、プログラムコードの再利用が容易になり、他の機種へのＵＩの移植も可能になる。したがって、例えば、異なるメーカの異なる端末機種間でも同じＵＩを使用することができるなど、各端末からＵＩのみを独立させるように扱うことも可能になる。

このような、ＸＭＬをベースにしたＵＩのうち代表的なものとして、ＴＡＴ社（http://www.tat.se/）が開発したＵＩ Ｆｏｕｎｄａｔｉｏｎや、Ａｃｒｏｄｅａ社（http://www.acrodea.co.jp/）が開発したＶＩＶＩＤ ＵＩや、Ｑｕａｌｃｏｍｍ社（http://www.qualcomm.co.jp/）が開発したＵＩ Ｏｎｅなどを挙げることができる。

また、近年の携帯端末は、端末本体の多機能化および高性能化に伴い、同時に複数のタスクを並行して実行できるマルチタスク処理に対応したＯＳ（オペレーティングシステム）を実装したものが増えている。さらに、並行して同時に処理する複数のタスクにそれぞれ固有の表示領域（ウィンドウ）を割り当てて、出力画面の表示を多重化するマルチウィンドウ機能に対応した携帯端末も普及しつつある。

ところで、例えば特開２００１−３６６５２号公報には、赤外線通信部を備える携帯電話端末を用いて、赤外線通信により複数の外部機器を遠隔操作（制御）できるようにした技術が開示されている。この特開２００１−３６６５２号公報に記載の携帯電話端末は、外部機器との通信を行う外部制御部を備えている。この携帯電話端末は、外部の機器を遠隔制御するための外部機器制御情報を、電話回線などを介して取得したり、または外部機器から受信するなどして記憶し、この外部機器制御情報に基づいて外部機器を遠隔制御することができる。すなわち、内蔵のアプリケーションプログラム（以下、単に「アプリケーション」という）を変更することで、通常は携帯電話として使用する端末本体を、複数の外部機器を遠隔操作するリモートコントロール（以下、単に「リモコン」という）端末として用いることができる。

上記特開２００１−３６６５２号公報に開示されている携帯電話端末によると、各外部機器に対応するそれぞれの外部機器制御情報に基づいて、１台の携帯電話端末で複数の外部機器を遠隔操作できる。したがって、複数の外部機器のそれぞれについて個別のリモコン端末を複数使い分ける煩雑な操作が必要なく、ユーザにとっての利便性を高めることができる。

このような、遠隔制御する複数の外部機器を切り替えるリモコン機能を、上述したマルチタスク処理が可能な携帯端末にて実現すれば、各リモコンのアプリケーションをいちいち一旦終了させて次のリモコンのアプリケーションを起動させる必要はない。すなわち、複数のアプリケーションを１つの端末で同時に起動させて、その中から、使いたい任意のリモコンのアプリケーションに適時切り替えて使用できる。

しかしながら、複数のアプリケーションを頻繁に切り替えて使用する場合には、その切り替え操作は煩雑なものとなる。

そこで、携帯端末に上述したマルチウィンドウの機能を組み合わせれば、複数のウィンドウに、複数のアプリケーションを操作するＵＩをそれぞれ再現することも可能になる。このようにすれば、複数のアプリケーションを切り替えて使用するのではなく、１画面上で同時に使用できる。

例えば、図１４（Ａ）に示すような、テレビのリモコン端末単独であれば、図１４（Ｂ）に示すように、例えばタッチパネル２００を備える携帯端末１００上に、テレビリモコンアプリケーションのＵＩを、その操作性を維持したまま再現できる。また、図１４（Ｃ）に示すような、エアコンディショナーのリモコン端末単独の場合も同様に、図１４（Ｄ）のように、タッチパネル２００を備える携帯端末１００上に、エアコンディショナーリモコンアプリケーションのＵＩを、その操作性を維持したまま再現できる。さらに、それぞれのアプリケーションのＵＩを、ＸＭＬをベースとして記述すれば、他メーカの端末などにアプリケーションを移植しても、ＵＩを記述したＸＭＬのファイルを加工するだけでほとんど同じＵＩを容易に再現できる。

しかしながら、上述の例において、テレビの視聴中にエアコンディショナーの操作を行う場合、テレビもエアコンディショナーも頻繁な操作を要するため、両者のアプリケーションを、マルチタスクおよびマルチウィンドウの機能を用いて、表示部の表示領域を分割して同時に表示したとする。この場合、各アプリケーションは単独で使用することを想定したＵＩしか備えていないため、各ＵＩをそのまま同時表示すると、図１５（Ａ）〜（Ｄ）に示すような状態になる。

図１５（Ａ）〜（Ｄ）は、マルチタスクおよびマルチウィンドウの機能を実装した携帯端末１００で２つのアプリケーションのＵＩを同時表示した様子を示す図である。図に示す例においては、タッチパネル２００の表示部の表示を上下に分割した各ウィンドウ内で、それぞれのＵＩをそのまま再現したため、各ＵＩとも一部しか表示されていない。画面上に表示しきれない部分でも操作ができるように、各ウィンドウの右端にはスクロールバーを備えている。

例えば図１５（Ａ）に示す状態で、テレビの音量を調節したい場合には、ユーザは、テレビリモコンＵＩのウィンドウのスクロールバーを移動して、図１５（Ｂ）に示すようにテレビリモコンＵＩの表示範囲を移動させなくてはならない。同様に、例えば図１５（Ｃ）に示す状態で、エアコンディショナーの温度を調節したい場合、ユーザは、エアコンディショナーリモコンＵＩのウィンドウのスクロールバーを移動して、図１５（Ｄ）に示すようにエアコンディショナーリモコンＵＩの表示範囲を移動させなくてはならない。さらに、マルチウィンドウで複数のアプリケーションを起動する場合、ＵＩを重畳表示する際は、まず入力するウィンドウを選択してアクティブにしてから入力操作を開始しなくてはならない。

特に、携帯端末の場合は、端末本体が非常に小さく設計されるため、タッチパネルで構成するＵＩの場合も物理的なキーで構成するＵＩの場合も、ＵＩとして利用できる領域は極めて制限されている。したがって、リモコンなどのアプリケーションのＵＩを構成する操作部は、もともと最小に近い大きさで設計されるのが一般的である。そのため、複数のアプリケーションのＵＩを同時表示する際に、各ＵＩをそれぞれ全体的に縮小して同時に表示するのは現実的ではない。

このように一画面用にデザインされたＵＩをマルチウィンドウで表示した場合、その操作性は悪化してしまう。

したがって、かかる事情に鑑みてなされた本発明の目的は、複数のアプリケーションプログラムのユーザインタフェースを同時に実現し、かつ各ユーザインタフェースの操作性を維持できるユーザインタフェース生成装置を提供することにある。

上記目的を達成する第１の観点に係るユーザインタフェース生成装置の発明は、
アプリケーションプログラムに基づいて各種の機能を実現するアプリケーションプログラム実行部と、
前記アプリケーションプログラムに基づく所定の機能の実行を前記アプリケーションプログラム実行部に指示するためのユーザインタフェースを生成するユーザインタフェース生成部と、
前記ユーザインタフェース生成部により生成されるユーザインタフェースを表示する表示部と、
前記ユーザインタフェースの構成要素であるユーザインタフェースオブジェクトを定義するユーザインタフェースオブジェクト定義情報を含むユーザインタフェース定義ファイルを格納する記憶部と、を備え、
前記ユーザインタフェース生成部は、複数の前記ユーザインタフェースの生成が指示された場合、当該指示された複数のユーザインタフェースの各々に対応して前記記憶部に格納されたユーザインタフェース定義ファイルに含まれるユーザインタフェースオブジェクト定義情報を、前記表示部において当該ユーザインタフェースを表示する所定の表示領域に応じて取捨選択し、選択されたユーザインタフェースオブジェクト定義情報に基づいて合成ユーザインタフェースを生成するユーザインタフェース合成処理を行うことを特徴とするものである。

第２の観点に係る発明は、第１の観点に係るユーザインタフェース生成装置において、
前記ユーザインタフェースオブジェクト定義情報は、該ユーザインタフェースオブジェクトと、該ユーザインタフェースオブジェクトを含むユーザインタフェースに含まれる他のユーザインタフェースオブジェクトとの関係を示すユーザインタフェースオブジェクト属性情報を含み、
前記ユーザインタフェース生成部は、複数の前記ユーザインタフェースの生成が指示された場合、前記表示領域と、前記ユーザインタフェースオブジェクト属性情報とに基づき、前記所定のユーザインタフェースオブジェクト定義情報を取捨選択することを特徴とするものである。

第３の観点に係る発明は、第２の観点に係るユーザインタフェース生成装置において、
前記ユーザインタフェースオブジェクト定義情報は、当該ユーザインタフェースを構成する各ユーザインタフェースオブジェクトが有効か無効かを示すユーザインタフェースオブジェクト属性情報をさらに含み、
前記ユーザインタフェース生成部は、複数の前記ユーザインタフェースの生成が指示された場合、前記表示領域と、前記ユーザインタフェースオブジェクト属性情報とに基づき、前記所定のユーザインタフェースオブジェクト定義情報を取捨選択することを特徴とするものである。

第４の観点に係る発明は、第２または第３の観点に係るユーザインタフェース生成装置において、
前記ユーザインタフェースオブジェクト定義情報は、当該ユーザインタフェースオブジェクトに対するイベント発生時に実行すべき動作内容を示すアクション情報を含み、
該アクション情報は、他のユーザインタフェースオブジェクト定義情報に含まれる前記ユーザインタフェースオブジェクト属性情報の変更に関する情報を含み、
前記ユーザインタフェース生成部は、前記合成ユーザインタフェースにおいて前記イベントが発生し、当該イベントの発生を受け付けたユーザインタフェースオブジェクトのユーザインタフェースオブジェクト定義情報に含まれるアクション情報に基づいて前記ユーザインタフェースオブジェクト属性情報が変更された場合、当該変更されたユーザインタフェースオブジェクト属性情報に基づいてユーザインタフェース合成処理を行い新たな合成ユーザインタフェースを生成することを特徴とするものである。

第５の観点に係る発明は、第１の観点から第３の観点のいずれか１つの観点に係るユーザインタフェース生成装置において、
前記ユーザインタフェース定義ファイルは、該ユーザインタフェース定義ファイルに基づいて生成されるユーザインタフェースを識別する識別情報を含み、
前記ユーザインタフェース生成部は、選択されたユーザインタフェースオブジェクト定義情報を前記識別情報に基づいて加工することを特徴とするものである。

第１実施の形態に係るユーザインタフェース生成装置の概略構成を示すブロック図である。 第１実施の形態に係るユーザインタフェースオブジェクト属性情報である優先度を示す情報を説明する図である。 第１実施の形態によるユーザインタフェース生成部の処理全体を説明するフローチャートである。 図３のユーザインタフェース合成処理についてさらに説明するフローチャートである。 図３のユーザインタフェース生成処理についてさらに説明するフローチャートである。 第１実施の形態において２つのユーザインタフェースを合成した例を示す図である。 第２実施の形態に係るユーザインタフェースオブジェクト属性情報であるユーザインタフェース識別情報を利用したユーザインタフェースの合成を説明する図である。 第２実施の形態によるユーザインタフェース合成処理について説明するフローチャートである。 第２実施の形態において２つのユーザインタフェースを合成した例を示す図である。 第３実施の形態に係るユーザインタフェースオブジェクト属性情報であるユーザインタフェースオブジェクトの有効／無効を示す情報を利用したユーザインタフェースの合成を説明する図である。 第３実施の形態によるユーザインタフェース合成処理について説明するフローチャートである。 第３実施の形態においてユーザインタフェースを更新した例を示す図である。 第３実施の形態においてユーザインタフェースを更新する際の属性情報を説明する図である。 従来のリモートコントロール端末を携帯端末のユーザインタフェースで再現した状態を示す図である。 従来の携帯端末にて２つのユーザインタフェースを合成した例を示す図である。

符号の説明

１ ユーザインタフェース生成装置
１０ 制御部
１２ アプリケーションプログラム実行部
１４ ユーザインタフェース取得部
１６ ユーザインタフェース生成部
１８ ユーザインタフェース合成処理部
２０ タッチパネル
２２ 入力部
２４ 表示部
３０ 無線通信部
４０ 赤外線通信部
５０ 記憶部
５２ アプリケーションプログラム記憶領域
５４ ユーザインタフェース定義ファイル記憶領域
５６ 個別ユーザインタフェースリソース記憶領域
５８ 共通ユーザインタフェースリソース記憶領域

以下、本発明の各実施の形態について、図面を参照して説明する。以下の各実施の形態では、本発明のユーザインタフェース（以下、「ＵＩ」と記す）生成装置の一例として、各種外部機器の遠隔制御が可能なリモコン機能を実装した携帯電話を想定して説明する。しかしながら、本発明のＵＩ生成装置は携帯電話に限定されるものではなく、例えばノートパソコンやＰＤＡなどの任意の携帯端末などに適用することが可能である。また、本発明の実装を必要とする装置であれば、携帯端末にも限定されることはない。なお、本発明は、複数のＵＩを同時に使用できるように合成することを主目的とするものであり、各ＵＩにより指示を受けるアプリケーションはリモコン機能に限定されるものではなく、任意の各種アプリケーションに適用することができる。

（第１実施の形態）
図１は、本発明の第１実施の形態に係るＵＩ生成装置である携帯電話の概略構成を示すブロック図である。

携帯電話１は、全体を制御する制御部１０と、ユーザからの入力を受け付けると共に、各アプリケーションに応じて入力結果などの表示を行うタッチパネル２０とを備えている。タッチパネル２０は、ユーザからの入力を受け付けるマトリクススイッチなどで構成した入力部２２を、液晶ディスプレイなどで構成した表示部２４の前面に重畳させて構成する。表示部２４は、アプリケーションプログラムに関する表示をする他、ユーザの操作入力を受け付けるＵＩをＵＩ表示領域に描画して表示する。

また、携帯電話１は、図示しない基地局と音声通話および電子メールのデータなど各種情報を送受信する無線通信部３０と、図示しない各種外部機器と赤外線により通信を行う赤外線通信部４０とを備えている。無線通信部３０を用いて、携帯電話１は、インターネットや無線等を介して端末外部と各種データの送受信を行う。

さらに、携帯電話１は、入力された情報および各種アプリケーション等を記憶したり、ワークメモリなどとしても機能する記憶部５０を有する。記憶部５０は、アプリケーション記憶領域５２と、ＵＩ定義ファイル記憶領域５４と、個別ＵＩリソース記憶領域５６と、共通ＵＩリソース記憶領域５８とを含む。アプリケーション記憶領域５２には、各種のアプリケーションを記憶する。ＵＩ定義ファイル記憶領域５４には、各ＵＩ全体を生成する際の一連の生成ルールを定義するＵＩ定義ファイルを記憶する。また、個別ＵＩリソース記憶領域５６は、各アプリケーション固有のＵＩの生成に使用する画像データや文字列（テキスト）データなどの個別ＵＩリソースを記憶する。共通ＵＩリソース記憶領域５８は、各アプリケーション固有の個別ＵＩリソース以外の、端末にて用いられるＵＩが共有して使用する画像データやフォントのデータなどの共通ＵＩリソースを記憶する。実際にＵＩを生成する際には、個別ＵＩリソース記憶領域５６および共通ＵＩリソース記憶領域５８に記憶された画像データおよびテキストデータなどを、タッチパネル２０の表示部２４に表示する。

なお、制御部１０は、アプリケーション実行部１２と、ＵＩ取得部１４と、ＵＩ生成部１６とを含んでいる。アプリケーション実行部１２は、記憶部５０のアプリケーション記憶領域５２に保存された各種アプリケーションを実行すると共に、当該実行に関する制御を行う。また、アプリケーション実行部１２は、アプリケーション記憶領域５２に保存された各種アプリケーションに対応するＵＩへの入力に基づいて、当該入力に対応する各種アプリケーションの機能を実行する。ＵＩ取得部１４は、無線通信部３０を介して端末の外部にあるリソース（画像データ等）およびＵＩ定義ファイル（ＸＭＬファイルなど）を取得する。ＵＩ生成部１６は、ＵＩ定義ファイルに対してパース処理（パーシング）およびＤＯＭ(Document Object Model)化処理などを行い、実際に使用するＵＩを生成する。なお、ＵＩ生成部１６は、ＸＭＬの形式で記述されたＵＩの情報をＸＭＬエンジンによって解釈し、ＵＩ定義ファイルに基づいて生成されたＵＩをタッチパネル２０の表示部２４に表示する。

さらに、ＵＩ生成部１６は、ＵＩ合成処理部１８を含んでいる。ＵＩ合成処理部１８は、複数のＵＩを合成するよう指示されると、指定された複数のＵＩ定義ファイルに従ってＵＩの合成を行う。

次に、本実施の形態にてＵＩ定義ファイル記憶領域５４に記憶するＵＩ定義ファイルについて、さらに説明する。

記憶部５０のＵＩ定義ファイル記憶領域５４には、アプリケーション記憶領域５２に記憶された各アプリケーションが実行される際に必要なＵＩの、当該アプリケーションに対応した各仕様および動作などを定義するＵＩ定義ファイルが記憶される。異なるアプリケーションで同じＵＩを使う状況も考えられるが、ここでは説明の便宜のため、異なるアプリケーションに対してそれぞれ異なるＵＩを用いる場合を想定し、各アプリケーションにそれぞれ対応した各ＵＩ定義ファイルを保存している場合について説明する。例えば、図示しない外部機器であるテレビ受像機を携帯電話１にて遠隔制御するテレビリモコンアプリケーションに対応して、テレビリモコンＵＩ定義ファイルをＵＩ定義ファイル記憶領域５４に記憶する。同様に、図示しない外部機器のエアコンディショナーを携帯電話１にて遠隔制御するエアコンディショナーリモコンアプリケーションに対応して、エアコンディショナーリモコンＵＩ定義ファイルをＵＩ定義ファイル記憶領域５４に記憶する。

本実施の形態では、ＵＩ定義ファイルを記述する言語の例として、ＸＭＬ言語をベースにしたＵＩＭＬ(User Interface Markup Language)の形式に従って説明する。このＵＩＭＬファイル形式で記述される定義に従って、ＵＩ生成部１６は、携帯電話１のタッチパネル２０の表示部２４にＵＩを表示し、アプリケーション実行部１２は、ユーザによる入力部２２に対する入力に応じた処理を行う。

本実施の形態によるＵＩ定義ファイルには、表示部２４に描画するＵＩオブジェクトを定義するＵＩオブジェクト定義情報を含ませる。ＵＩオブジェクト定義情報は、表示部２４に表示するＵＩを構成する要素であるキーまたはボタンなどのＵＩオブジェクトを描画するための画像およびテキストを定義する情報、およびそのＵＩオブジェクトに入力がされた際の（実際にはＵＩオブジェクトに対応する入力部２２の部位に入力がされた際の）動作を定義する情報である。

本実施の形態では、ＵＩオブジェクトの位置に対応する入力部２２に入力がされた際の動作を定義する情報として、ＵＩオブジェクト定義情報に、各ＵＩオブジェクトに対するイベント発生時に各アプリケーション実行部が実行すべき動作内容を示すアクション情報を含める。例えば、テレビリモコンＵＩの「電源」のＵＩオブジェクトの位置に対応する入力部２２に入力のイベントが発生した場合、テレビリモコンアプリケーションに対して、外部機器のテレビの電源をＯＮまたはＯＦＦにする赤外線信号を発信する指示を出すようアクション情報で定義する。

さらに、ＵＩオブジェクト定義情報には、複数のＵＩを合成する際に用いる各ＵＩオブジェクトに関する情報であるＵＩオブジェクト属性情報を含ませる。本実施の形態においては、ＵＩオブジェクト属性情報として、各ＵＩオブジェクトと他のＵＩオブジェクトとの関係に基づいて、複数のＵＩを合成する際に各オブジェクトが表示される優先度を予め定義する。

図２は、本実施の形態に係るＵＩオブジェクト属性情報である優先度を示す情報を説明する図である。

図２（Ａ）は、携帯電話１において、テレビリモコンアプリケーションのみを起動し、テレビリモコンＵＩ定義ファイルに基づいて、テレビリモコンＵＩをタッチパネル２０に表示した様子を示している。図中では、タッチパネル２０上のＵＩ表示領域を各ＵＩオブジェクトの属性情報に対応する小領域に概念的に分割した様子を一点鎖線によって表し、各小領域に対応する各ＵＩオブジェクト属性情報を図の右側に列記してある。また、複数のＵＩオブジェクトをまとめて１つのＵＩとして扱うことの定義（ＵＩ識別情報）をinterfaceのタグを付して示し、“TV1_interface”という値から、これがＴＶ１のリモコンのＵＩであることが特定できる。なお、図２（Ａ）に示す例では、ＴＶ１のリモコンのＵＩによって、ＴＶ１として識別されるテレビ受像機の遠隔操作（制御）を行うことができる。

本実施の形態では、ＵＩオブジェクト属性情報として、上述した各小領域のＵＩオブジェクトについての優先度を、priorityの値として予め定義する。図２の例では、priorityの値がゼロのＵＩオブジェクトは必須のオブジェクトとし、priorityの値が１のＵＩオブジェクトは重要なオブジェクトとし、それ以降はpriorityの値が増大するほど優先度が低いＵＩオブジェクトであることを意味する。すなわち、例えば図２（Ａ）の小領域（１）に示す「電源」のキーは必須のキーであるため、priorityの値をゼロとする。また、小領域（２）および（３）のチャンネル選局キー、ならびに小領域（４）および（５）の音量上下キーは重要なキーであるためpriorityの値は１とする。しかしながら、小領域（６）のテンキーは、小領域（２）および（３）のチャンネル選局キーで代替できるため、priorityの値を３とし、優先度を低く設定する。

同様に、図２（Ｂ）は、エアコンディショナーリモコンＵＩのみをタッチパネル２０に表示した様子を示す。エアコンディショナーリモコンＵＩでは、例えば小領域（１）に示す「設定温度」の表示は必須であり、小領域（２）に示す「電源」のキーは必須のキーであるため、priorityの値をゼロとする。また、小領域（３）および（４）の温度上下選局キーは重要なキーであるためpriorityの値は１とする。しかしながら、小領域（５）および（６）の風向＋−キーは他のキーに比べ重要でないためpriorityの値は５とする。さらに、小領域（７）のモードキーおよび小領域（８）のメニューキーは、使用頻度がさほど多くないためpriorityの値を２に設定する。なお、これら複数のオブジェクトがまとまった１つのエアコンディショナー１のリモコンのＵＩであることが特定できるよう、interfaceのタグの値は“AIR1_interface”とする。図２（Ｂ）に示す例では、このリモコンのＵＩによって、ＡＩＲ１として識別されるエアコンディショナーの遠隔操作（制御）を行うことができる。

このように、本実施の形態では、各ＵＩオブジェクトと他のＵＩオブジェクトとの関係に基づいて定義された優先度情報（priorityの値）を、ＵＩオブジェクト属性情報として、各ＵＩ定義ファイルのＵＩオブジェクト定義情報に予め含ませる。

次に、図３〜５のフローチャートを参照しながら、本実施の形態による複数のアプリケーションのＵＩを合成する際の動作について説明する。

図３は、本実施の形態による、ＵＩ生成部１６の処理全体を説明するフローチャートである。まず、ユーザからの入力部２２への操作入力などに基づいてＵＩを生成する処理が開始すると、ＵＩを提供するアプリケーションからＵＩ定義ファイル（ＸＭＬファイル）が指定される（ステップＳ１１）。このＵＩ生成の処理のきっかけとなる動作は、ＵＩを用いるアプリケーションを起動する際のユーザの操作、またはユーザが既にアプリケーションを実行中に、ＵＩを用いる他のアプリケーションをさらに起動する際のユーザの操作などが想定される。

次に、ＵＩ生成部１６は、指定されたＵＩ定義ファイルの数が１つか複数かを判定する（ステップＳ１２）。指定ファイル数が１つと判定された場合、ＵＩ生成部１６は、アプリケーションが複数のＵＩの合成を要求していないと判断し、指定された１つのＵＩ定義ファイルに対してＸＭＬパース処理（ステップＳ１３）およびＤＯＭ化処理（ステップＳ１４）を行う。

このように、指定されたＵＩ定義ファイルが１つの場合には、それ以降の処理は従来式のＵＩを生成する処理と同じになる。すなわち、パース処理およびＤＯＭ化処理を行ったＵＩ定義ファイルに基づいて、ＵＩ生成部１６は、ＵＩを生成する処理を行う（ステップＳ１５）。なお、ステップＳ１５のＵＩ生成処理については後述する。次に、ＵＩ生成処理により生成されたＸＭＬファイルのＵＩに基づいて、アプリケーション実行部１２は、タッチパネル２０の表示部２４のＵＩ表示領域にＵＩを表示する処理を行う（ステップＳ１６）。

以上の処理により、携帯電話１は、単一のアプリケーションの実行に伴い、単一のＵＩを表示部２４に表示できる。例えば、テレビリモコンのアプリケーションの起動によりテレビリモコン用のＵＩ定義ファイルが指定された場合には、前述の図２（Ａ）に示すようなＵＩの表示になる。また、エアコンディショナーリモコンのアプリケーションの起動によりエアコンディショナーリモコン用のＵＩ定義ファイルが指定された場合には、図２（Ｂ）に示すようなＵＩの表示になる。

一方、ステップＳ１２にて、指定されたファイル数が複数の場合、ＵＩ生成部１６は、アプリケーションが複数のＵＩの合成を要求していると判断し、複数の各ＸＭＬファイルについてＸＭＬパース処理（ステップＳ１７）およびＤＯＭ化処理（ステップＳ１８）を行う。ステップＳ１９にて、ＵＩ生成部１６は、上記パース処理およびＤＯＭ化処理が全てのＵＩ定義ファイルについて完了したか否かを判定し、まだ完了していない場合にはステップＳ１７に戻る。

ステップＳ１９で全てのＵＩ定義ファイルについてパース処理およびＤＯＭ化処理が完了したら、ＵＩ合成処理部１８は、パース処理およびＤＯＭ化処理が完了した複数のＵＩを合成する処理を行う（ステップＳ２０）。なお、ステップＳ２０のＵＩ合成処理についても後述する。

この後、ステップＳ２０にて合成した合成ＵＩ定義ファイルに基づいて、ＵＩ生成部１６は、合成ＵＩを生成する処理を行う（ステップＳ１５）。次に、アプリケーション実行部１２は、生成された合成ＵＩをタッチパネル２０の表示部２４のＵＩ表示領域に表示する処理を行い（ステップＳ１６）、ＵＩ生成の全体的な処理を終了する。

次に、図４のフローチャートを参照しながら、図３のステップＳ２０のＵＩ合成処理についてさらに説明する。

ＵＩ合成処理が開始されると、ＵＩ合成処理部１８は、パース処理およびＤＯＭ化処理が完了した複数のＵＩのＤＯＭノードについて、各ＤＯＭノードを構成するＵＩオブジェクトを全て抽出して、各ＵＩオブジェクトの属性情報を解析する（ステップＳ３１）。本実施の形態では、各ＵＩオブジェクトの属性情報として、各ＵＩオブジェクトの優先度情報（priority）を解析する。

次に、ＵＩ合成処理部１８は、解析した優先度情報の優先度が最上位（priority=”0”）、つまり表示が必須であるＵＩオブジェクトを全て抽出し（ステップＳ３２）、当該抽出したＵＩオブジェクトを用いて、仮のレイアウト処理を行う（ステップＳ３３）。この仮のレイアウト処理は、実際には表示部２４にＵＩオブジェクトを表示せずに、ＵＩ合成処理部１８内の演算処理により、表示が必須のＵＩオブジェクトを仮レイアウトとして配列する。

仮のレイアウト処理が完了したら、ＵＩ合成処理部１８は、当該仮レイアウトしたＵＩオブジェクトを配列したＵＩ全体の表示が、表示部２４内でＵＩを表示するための領域であるＵＩ表示領域に収まるか否か判定する（ステップＳ３４）。この判定の結果、ＵＩの表示がＵＩ表示領域に収まらないと判定された場合、この複数のＵＩは合成ＵＩとして表示できないため、ＵＩ合成処理部１８は、当該複数のＵＩの合成処理が失敗した旨を表示部２４に表示し（ステップＳ３５）、ＵＩ合成処理を終了する。これは、必須のオブジェクトさえも表示できないほど、同一画面上に多数のＵＩを合成しようとした場合の措置である。

ステップＳ３４にて、仮レイアウトした必須ＵＩオブジェクトを配列したＵＩ全体の表示が表示部２４内のＵＩ表示領域に収まると判定された場合、ＵＩ合成処理部１８は、これらの優先度が最上位の（表示が必須の）ＵＩオブジェクトを採用することを確定する（ステップＳ３６）。

次に、ＵＩ合成処理部１８は、解析された優先度の情報に基づいて、優先度が次に高いＵＩオブジェクトを全て抽出する（ステップＳ３７）。例えば、今まで抽出して処理したのがpriority=”0”のＵＩオブジェクトであれば、次はpriority=”1”のＵＩオブジェクトを抽出する。さらに、ＵＩ合成処理部１８は、抽出したＵＩオブジェクトと、ステップＳ３６で確定した優先度が最上位のＵＩオブジェクトとを合わせて仮のレイアウト処理を行う（ステップＳ３８）。この仮レイアウト処理が完了したら、ＵＩ合成処理部１８は、当該仮レイアウトしたＵＩオブジェクトの表示が表示部２４のＵＩ表示領域に収まるか否か判定する（ステップＳ３９）。

ステップＳ３９の判定の結果、仮レイアウトしたＵＩオブジェクトの表示が表示部２４のＵＩ表示領域に収まると判定された場合、ＵＩ合成処理部１８は、これらのＵＩオブジェクトの採用を確定する（ステップＳ４０）。

この後、ＵＩ合成処理部１８は、まだ優先度情報の解析が終了していないＵＩオブジェクトの残りがゼロになったか否か判定する（ステップＳ４１）。優先度情報の解析がまだ終了していないＵＩオブジェクトの残りがゼロでない、つまりまだ未解析のＵＩオブジェクトが残っている場合には、ステップＳ３７に戻る。このようにして、ＵＩ表示領域が許す限り、またＵＩオブジェクトが存在する限り、優先度の高い順にＵＩオブジェクトの選出と確定を繰り返す。

ステップＳ４１にて、優先度情報が未解析のＵＩオブジェクトの残りがゼロになった、つまり未解析のＵＩオブジェクトがもう残っていない場合は、ＵＩ合成処理部１８は、その時点での合成ＵＩオブジェクトの仮レイアウトを正式なレイアウトとして確定する（ステップＳ４２）。この後は、確定したレイアウトのＵＩオブジェクトを１つのＤＯＭノードとして集約し（ステップＳ４３）、ＵＩ合成処理を終了する。

なお、ステップ３９にて、仮レイアウトしたＵＩオブジェクトの表示が表示部２４のＵＩ表示領域に収まらない場合には、ＵＩ合成処理部１８は、この時点で抽出されている各ＵＩオブジェクトの中から所定の条件に基づいて取捨選択してから（ステップＳ４４）、ステップＳ４２に移行する。この所定の条件とは、優先度が同等のＵＩオブジェクトが複数存在し、それら全てがＵＩ表示領域に収まらない場合に備え、各ＵＩオブジェクト同士の関連性、またはＵＩオブジェクトの表示サイズ等に関連付けて、適宜、取捨選択の条件を予め定義しておく。

次に、図５のフローチャートを参照しながら、図３のステップＳ１５のＵＩ生成処理についてさらに説明する。

図５に示すＵＩ生成処理の開始時点では、指定された１つのＵＩ定義ファイルに基づくＵＩ、または複数のＵＩ定義ファイルに基づく合成ＵＩのどちらかが、１つのＤＯＭドキュメント（またはＤＯＭノード）になっている。まず、ＵＩ生成部１６は、ＤＯＭドキュメントに対して表示関連の解析を行う（ステップＳ５１）。これは、ＵＩＭＬ形式で記述されたＵＩ定義ファイルでは、structureタグやstyleタグを付された属性などを解析する。次に、ＵＩ生成部１６は、ＤＯＭドキュメントの動作関連について解析を行う（ステップＳ５２）。これは、ＵＩＭＬ形式で記述されたＵＩ定義ファイルでは、behaviorタグを付された属性などを解析する。

次に、ＵＩ生成部１６は、ＤＯＭドキュメントに含まれる表現を、各端末に依存する表現に変換する処理を行う（ステップＳ５３）。さらに、ＵＩ生成部１６は、ステップＳ５３の変換処理の結果に基づいて、使用するＵＩオブジェクトのリソースを選定して各属性（プロパティ）を設定する（ステップＳ５４）。この際に必要なＵＩオブジェクトのリソースは、個別ＵＩリソースとして個別ＵＩリソース記憶領域５６に、または共通ＵＩリソースとして共通ＵＩリソース記憶領域５８に記憶されている。この後、ＵＩ生成部１６は、各ＵＩオブジェクトを含むＵＩのプロット処理を行う（ステップＳ５５）。これによりＵＩの生成処理は終了し、この後は図３のステップＳ１６に移行して、ＵＩの表示処理を行う。

以上のようにすることで、例えば図２（Ａ）に示すテレビリモコンＵＩと、図２（Ｂ）に示すエアコンディショナーリモコンＵＩとの２つのＵＩを合成すると、図６に示すような合成ＵＩが生成される。図６に示す合成ＵＩは、タッチパネル２０を上下２つの領域に分割して、上半分にテレビリモコンＵＩのＵＩオブジェクトを、また下半分にエアコンディショナーリモコンＵＩのＵＩオブジェクトを配置している。ここでは、テレビリモコンＵＩについてはpriorityが”0”から”1”までのＵＩオブジェクトを抽出して、エアコンディショナーリモコンＵＩについてはpriorityが”0”のＵＩオブジェクトのみを抽出してＵＩを合成している。このように、本実施の形態では、２つのＸＭＬファイルを解析して、優先度の高いＵＩオブジェクトのみを自動配置して複数のＵＩを合成する。これによりユーザは複数のアプリケーションまたは当該アプリケーションに基づくＵＩを切り替えることなく、複数のＵＩを同時に利用することができる。

（第２実施の形態）
次に、本発明の第２実施の形態に係るＵＩ生成装置によるＵＩ合成処理について説明する。本実施の形態では、上述した第１実施の形態において、ＵＩオブジェクト定義情報に含まれる、複数のＵＩを合成する際に用いる各ＵＩオブジェクトに関する情報であるＵＩオブジェクト属性情報を変更する。

上述した第１実施の形態では、ＵＩオブジェクト属性情報として、各ＵＩオブジェクトと他のＵＩオブジェクトとの関係に基づいて、複数のＵＩを合成する際に各オブジェクトが表示される優先度を予め定義した。本実施の形態では、第１実施の形態のＵＩオブジェクト属性情報と合わせて、ＵＩオブジェクトを構成要素とするＵＩの識別情報を定義する。

図７は、本実施の形態に係るＵＩ識別情報を利用したＵＩの合成を説明する図である。本実施の形態では、図７の右側に示すように、図２で説明したＵＩオブジェクト定義情報の他に、各ＵＩオブジェクトに付すべきテキスト情報(text)をＵＩオブジェクト属性情報として付加する。また、ＵＩ識別情報(Interface id)に、当該ＵＩを示すテキスト情報(particular_name)を付加する。

このＵＩを示すテキスト情報(particular_name)は、ＸＭＬ形式で記述されたＵＩ定義情報において、必要に応じてＵＩオブジェクトなどに表示することで当該ＵＩオブジェクトが属するＵＩを特定することのできる名称などを、テキストやアイコンへのリンクなどで記述した情報である。例えば、図７の右側にてＵＩ識別情報(Interface id)に、破線で囲んで示したparticular_name=”テレビ１”というＵＩを示すテキスト情報を付加し、（１）〜（６）の一連のＵＩオブジェクトが「テレビ１」のＵＩを構成するものであることを示す。同じく、破線で囲んで示したparticular_name=”○製エアコンディショナー”というＵＩを示すテキスト情報を付加し、（１）〜（８）の一連のＵＩオブジェクトが「○製エアコンディショナー」のＵＩを構成することを示す。また、各テキスト情報(text)は、ＵＩオブジェクトを表示部２４に表示する際に、必要に応じて当該ＵＩオブジェクトの表示の上または近傍などに付すことのできる名称などをテキストで記述した情報である。

これらのＵＩを示すテキスト情報を利用することで、複数のＵＩを合成する際に、合成ＵＩとして表示されたキーやボタンなどが、どのＵＩに属するものなのかを容易に判別できる。

次に、図８のフローチャートを参照しながら、本実施の形態による、図３におけるステップＳ２０のＵＩ合成処理について説明する。図８に示す本実施の形態によるＵＩ合成処理は、図４で説明した第１実施の形態のステップＳ４２にてＵＩオブジェクトのレイアウトを確定した後に、ＵＩを示すテキスト情報などによるＵＩ加工処理（ステップＳ７１）を追加したものである。

ステップＳ７１のＵＩを示すテキスト情報などによるＵＩ加工処理では、例えば、複数のＵＩを合成するにあたり、各ＵＩオブジェクトの属性情報を解析した際に、複数のＵＩの間で、同じ文言のテキスト情報(text)を有するＵＩオブジェクトがあるか否かを判定する。異なるＵＩの間で同じテキスト情報のＵＩオブジェクトがある場合、そのままで合成ＵＩを生成すると、ユーザは、同じテキスト情報を有する複数のＵＩオブジェクトがそれぞれどのＵＩに属するＵＩオブジェクトなのか判別し難くなる。したがって、異なるＵＩの間で同じテキスト情報のＵＩオブジェクトがある場合、ＵＩ合成処理部１８は、当該ＵＩオブジェクト上またはその周辺にＵＩ識別情報の各テキストを付す。

例えば、図７に示す例では、テレビリモコンＵＩとエアコンディショナーリモコンＵＩとの合成ＵＩを生成したが、２つのＵＩの各ＵＩオブジェクトについてテキスト情報を解析すると、どちらのＵＩにおいても”電源”の同じテキスト情報が存在する。その他には、どちらのＵＩにおいても存在する同じテキスト情報はない。したがって、この”電源”のＵＩオブジェクトを表示する際には、そのそばに当該ＵＩオブジェクトが属するＵＩのＵＩ識別情報に付加されているテキスト情報(particular_name)も付す。

このようにすれば、図７左側に示すような合成ＵＩが生成される。図６で説明した合成ＵＩでは、「電源」のＵＩオブジェクトには、単に「電源」のみが表示されるため、ユーザは、何のＵＩの電源なのか一見して判別し難い。しかしながら、図７に示す合成ＵＩでは、ユーザは、各電源のＵＩオブジェクトがそれぞれ何のＵＩに属するＵＩオブジェクトなのか一見して判別できる。

本実施の形態の変形例として、同じテキストのＵＩオブジェクト上またはその付近にＵＩ識別情報に付加されているテキストを付す以外に、種々の態様が考えられる。例えば、図９（Ａ）に示すように、ＵＩ表示領域を、各ＵＩのＵＩ識別情報に基づいて、ＵＩごとに区分けの描画または色分けなどにより分割表示し、分割した各表示領域内の邪魔にならない箇所に、ＵＩ識別情報に付加されている各テキストを表示してもよい。

また、図９（Ｂ）に示すように、各ＵＩオブジェクトのテキスト情報に同じものがあるか否かに関わらず、全てのＵＩオブジェクト上またはその周辺に、ＵＩ識別情報に付加されている各テキストを付してもよい。

さらに、図９（Ａ）の変形例として、図９（Ｃ）に示すように、分割した各ＵＩ表示領域内に、ＵＩ識別情報のテキストの代わりに各ＵＩを示すアイコンなどを表示してもよい。一般的に、ＵＩ識別情報は、ＸＭＬ形式で記述された文書内のテキストの記述に対して付すため、表示する文字列が画像のリソースで定義されている場合など、各ＵＩオブジェクトにテキストを付すのが困難な場合、図９（Ｃ）に示すような態様が好適である。

（第３実施の形態）
次に、本発明の第３実施の形態に係るＵＩ生成装置によるＵＩ合成処理について説明する。本実施の形態では、上述した第２実施の形態と同様に、ＵＩオブジェクト定義情報に含まれる、複数のＵＩを合成する際に用いる各ＵＩオブジェクトに関する情報であるＵＩオブジェクト属性情報を変更する。

本実施の形態では、第２実施の形態にて定義したＵＩオブジェクト属性情報に代えて、または第２実施の形態のＵＩオブジェクト属性情報と合わせて、合成ＵＩを構成する各ＵＩオブジェクトを有効または無効にする情報をＵＩオブジェクト定義情報に含める。

図１０は、本実施の形態に係るＵＩオブジェクト属性情報である各ＵＩオブジェクトを有効または無効にする情報を利用したＵＩの合成を説明する図である。本実施の形態では、図１０の右側に示すように、図７で説明したＵＩオブジェクト定義情報に、さらに合成ＵＩを構成する各ＵＩオブジェクトの有効／無効の情報(com_effect)をＵＩオブジェクト属性情報として付加する。

この各ＵＩオブジェクトの有効／無効の情報(com_effect)は、値が”YES”になっている場合、当該ＵＩオブジェクトは「有効」として扱い、また値が”NO”になっている場合、当該ＵＩオブジェクトは「無効」として扱う。この情報が有効になっているＵＩオブジェクトは、ＵＩ合成の際に表示部２４のＵＩ表示領域に表示して、当該表示に対応する部位にて入力部２２への入力を受け付ける。一方、この情報が無効になっているＵＩオブジェクトは、ＵＩ合成の際に表示部２４のＵＩ表示領域に表示せず、入力部２２への入力も受け付けない。

例えば、図１０（Ａ）に示す例では、テレビ１のリモコンＵＩを構成する（１）〜（７）のＵＩオブジェクトのうち、ＵＩオブジェクトの有効／無効の情報(com_effect)が有効(”YES”)なのは、（１）の「電源ＯＮ」のＵＩオブジェクトのみである。したがって、ＵＩ表示領域には、テレビリモコンＵＩを構成する各ＵＩオブジェクトのうち、電源ＯＮのキーのみを表示する。また、エアコンディショナーリモコンＵＩを構成する（１）〜（９）のＵＩオブジェクトのうち、ＵＩオブジェクトの有効／無効の情報(com_effect)が有効(”YES”)なのは、（２）の「電源ＯＮ」のＵＩオブジェクトのみである。したがって、ＵＩ表示領域には、エアコンディショナーリモコンＵＩを構成するＵＩオブジェクトのうち、電源ＯＮのキーのみを表示する。

また、本実施の形態では、第１実施の形態で説明したＵＩオブジェクト定義情報に含まれるアクション情報に、各ＵＩオブジェクトに対するイベント発生時にアプリケーション実行部１２が実行すべき動作として、各ＵＩオブジェクトの有効／無効を変更（更新）する情報を含める。このアクション情報に基づいて、アプリケーション実行部１２は、所定のＵＩオブジェクトに対するイベント発生に応じて、所定のＵＩオブジェクトの有効／無効の情報(com_effect)を、有効から無効(“YES”から”NO”)へ、または無効から有効(”NO”から“YES”)へと更新できる。

次に、図１１のフローチャートを参照しながら、本実施の形態による、図３のステップＳ２０のＵＩ合成処理について説明する。図１１に示す本実施の形態によるＵＩ合成処理は、図８で説明した第２実施の形態において、ステップＳ３１でＵＩオブジェクトを抽出して属性情報を解析した後に、有効と解析されたＵＩオブジェクトのみを抽出する処理（ステップＳ９１）を追加したものである。

図１１のＵＩ合成処理が開始されると、ＵＩ合成処理部１８は、パース処理およびＤＯＭ化処理が完了した複数のＵＩのＤＯＭノードについて、各ＤＯＭノードを構成するＵＩオブジェクトを全て抽出して、各ＵＩオブジェクトの属性情報を解析する（ステップＳ３１）。本実施の形態では、各ＵＩオブジェクトの属性情報として、第１および第２実施の形態で用いた各ＵＩオブジェクトの優先度情報(priority)を解析する。さらに、各ＵＩオブジェクトの有効／無効の情報(com_effect)を解析し、有効（値が”YES”）と判断されたＵＩオブジェクトのみを対象ＵＩオブジェクトとして全て抽出する（ステップＳ９１）。

この後は、対象ＵＩオブジェクトとして抽出した有効なＵＩオブジェクトについて、第１および第２実施の形態で説明したステップＳ３２以降の処理を続行することで、合成ＵＩを生成することができる。

本実施の形態では、生成された合成ＵＩを表示部２４のＵＩ表示領域に表示した後、所定のＵＩオブジェクトに対応する入力部２２に対して操作入力のイベントが発生した場合、発生したイベントに応じて合成ＵＩを更新する。すなわち、イベントが発生したら、アプリケーション実行部１２は、ＵＩオブジェクト定義情報に含まれるアクション情報に基づいて、所定のＵＩオブジェクトの有効／無効の情報を更新すると共に、図１１に示したＵＩ合成処理を再び行い、合成ＵＩを更新する。

例えば、図１０（Ａ）に示す状態で、エアコンディショナーリモコンＵＩの「電源ＯＮ」のＵＩオブジェクトに対して操作入力のイベントが発生すると、まず、アプリケーション実行部１２は、外部機器のエアコンディショナーの電源をＯＮにする赤外線信号を発信するよう指示を出す。さらに、アプリケーション実行部１２は、アクション情報に基づいて、図１０（Ａ）のエアコンディショナーリモコンＵＩのＵＩオブジェクト「電源ＯＮ」の属性であるcom_effectの値を“YES”から”NO”に変更すると共に、所定の他のＵＩオブジェクトのcom_effectの値も変更する。

図１０（Ｂ）は、イベント発生後にアクション情報に基づいて、ＵＩオブジェクトの属性であるcom_effectの値が変更された後の状態を示す図である。図１０（Ａ）と比べて、図１０（Ｂ）の右側に示すように、エアコンディショナーリモコンＵＩの属性com_effectの値のうち、一点鎖線で囲んだものの値が、有効から無効または無効から有効に変化している。このように所定のＵＩオブジェクトの有効／無効の情報を変更すると共に、ＵＩ合成処理を再び行うと、図１０（Ｂ）の左側に示すように、有効なＵＩオブジェクトを含む合成ＵＩに更新される。

このように処理を行うことで、例えば図１０（Ａ）に示すように、各ＵＩとも、電源ＯＮにする前は必要のないＵＩオブジェクトは表示しないようにできるため、限られたＵＩ表示領域を有効に利用できる。さらに、例えば図１０（Ａ）のエアコンディショナーリモコンＵＩにて電源ＯＮのオブジェクトに入力があると、図１０（Ｂ）に示すように、電源をＯＮにした後に必要なＵＩオブジェクトが展開される。このように、ユーザの入力に基づいて、ＵＩ表示領域に表示されるＵＩが動的に変化するため、必要なＵＩオブジェクトを必要な時だけ表示できる。

また、このようにイベント発生ごとに合成ＵＩを更新する際に、有効なＵＩオブジェクトについて、第１実施の形態で説明した優先度(priority)の属性に基づく解析も行うため、表示される各ＵＩオブジェクトは、その優先度に応じて順次動的に変化する。

例えば、図１２（Ａ）に示す状態で、テレビリモコンＵＩのＵＩオブジェクト「電源ＯＮ」に入力があった場合について説明する。「電源ＯＮ」への入力のイベント発生により、アプリケーション実行部１２は、テレビリモコンＵＩを構成する所定のＵＩオブジェクトの有効／無効の情報を更新するため、優先度の高いものはＵＩ表示領域に表示されるようになる。しかしながら、図１２（Ａ）に示す状態では、ＵＩ表示領域にこれ以上のＵＩオブジェクトを表示する領域がない。そのため、合成ＵＩの更新時には、ＵＩ合成処理部１８は、各ＵＩオブジェクトの優先度の属性情報に基づいて、優先度の低いＵＩオブジェクトは採用せずに合成ＵＩを生成する。

このようにＵＩを更新（合成）することで、図１２（Ｂ）に示すように、テレビリモコンＵＩにてテレビの電源をＯＮにすることにより、重要なテレビリモコンＵＩのＵＩオブジェクトが表示される。一方、エアコンディショナーリモコンＵＩにおいては、更新の際に重要度の低いＵＩオブジェクトが表示されなくなり、ＵＩ表示領域を一層有効に活用した合成ＵＩを提供できる。

また、ＵＩオブジェクトの中には、例えば音量を操作するＵＩオブジェクトのように、「音量＋（増加）」または「音量−（減少）」の一方のみでは使い勝手が悪く、両方のＵＩオブジェクトが揃って初めて意味をなすものがある。したがって、本実施の形態では、上述したように合成ＵＩを更新することでＵＩ表示領域の構成を順次変更する際、対になるべき２つのＵＩオブジェクトは、採用するか否かを対として決定する。

具体的には、図１３に示すように、ＵＩオブジェクト定義情報に、複数のＵＩオブジェクトが対であることを示す属性(relate_ID)をＵＩオブジェクト属性情報としてさらに付加し、その属性の値によって対であるＵＩオブジェクトを定義する。図１３に示す例では、テレビリモコンＵＩにおいては、（２）の「選局＋」および（３）の「選局−」のＵＩオブジェクトが対であることを属性(relate_ID)により示し、その属性の値を”select_1”として定義している。また、（４）「音量＋」および（５）「音量−」のＵＩオブジェクトも対であることを属性(relate_ID)により示し、その属性の値を”volume_1”として定義している。なお、図１３に示す属性情報においては、各ＵＩオブジェクトの有効／無効の属性(com_effect)は省略してある。

同様に、エアコンディショナーリモコンＵＩにおいては、（３）「温度＋」および（４）「温度−」のＵＩオブジェクトが対であることを属性(relate_ID)により示し、その属性の値を”set_1”として定義している。また、（５）「風向＋」および（６）「風向−」のＵＩオブジェクトも対であることを属性(relate_ID)により示し、その属性の値を”wind_1”として定義している。

このようにＵＩオブジェクト属性情報を設定し、合成ＵＩを更新する場合、優先度(priority)や有効／無効(com_effect)の属性に基づく解析を行う際に、ＵＩオブジェクトを対として扱う属性(relate_ID)も解析する。対として扱う属性(relate_ID)の付加されたＵＩオブジェクトは、その値に基づいて、採用または不採用を対として決定する。

このように処理することで、例えば同じ優先度(priority)のＵＩオブジェクトが多数存在する場合でも、対になるべき２つのＵＩオブジェクトは、常に、対として表示および消去が行われる。図１３に示す例では、エアコンディショナーリモコンＵＩにおいて、優先度の高い(priority=”1”)「温度＋」および「温度−」のＵＩオブジェクトは対として採用され、優先度の低い(priority=”5”)「風向＋」および「風向−」のＵＩオブジェクトは対として不採用になる。したがって、合成ＵＩを更新した際に、例えば、「音量＋」のＵＩオブジェクトのみが表示されて「音量−」は表示されないという不都合は生じない。

なお、本発明は、上述した実施の形態にのみ限定されるものではなく、幾多の変更または変形が可能である。例えば、第３実施の形態においては、ＵＩオブジェクト属性情報(relate_ID)を用いることで、対になるべき２つのＵＩオブジェクトは、対として採用するか否かを決定したが、このようにグループ化するＵＩオブジェクトは２つに限定されず、３つ以上にもできる。

また、上述した各実施の形態の携帯電話１は、赤外線通信部４０により赤外線通信をすることで外部機器を遠隔制御したが、外部機器との通信は赤外線通信に限らず、例えばＢｌｕｅｔｏｏｔｈ（登録商標）や無線ＬＡＮなどの近距離無線通信を採用してもよい。

上述の各実施の形態では、ＵＩオブジェクト属性情報は、ＵＩオブジェクト定義情報に含まれるものとして説明したが、必ずしもＵＩオブジェクト定義情報に含まれていなくても良い。例えば、記憶部５０のＵＩオブジェクト定義情報が格納されている領域とは別の領域に、ＵＩオブジェクト属性情報を、対応するＵＩオブジェクト定義情報と関連付けて格納しても良い。

また、ＵＩオブジェクト属性情報は、その内容が固定された状態で定義されていなくても良い。すなわち、例えば、制御部１０は、ＵＩの使用履歴などに基づいて、ＵＩオブジェクト属性情報の内容を変更しても良い。

さらに、ＵＩオブジェクト属性情報は、予め定義されていなくても良い。すなわち、例えば、制御部１０は、記憶部５０に格納されたＵＩ定義ファイルを解析し、当該ＵＩ定義ファイルに含まれるＵＩオブジェクト定義情報の内容やＵＩオブジェクト定義情報同士の関連性、当該ＵＩの使用履歴などに基づいて、ＵＩオブジェクト属性情報を生成しても良い。

さらに、上記各実施の形態では、ＵＩ生成処理を開始するきっかけとして、ＵＩを用いるアプリケーションを起動するユーザ操作や、すでに何らかのアプリケーションが実行中であるときに、ＵＩを用いる他のアプリケーションを起動するユーザ操作などを例として説明したが、ＵＩ生成処理を開始するきっかけの動作はこれらに限定されるものではない。

例えば、上記各実施の形態において、ＵＩ生成装置である携帯電話１は、無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈなどの近距離無線通信やＲＦタグリーダなどにより、当該ＵＩ生成装置周辺に存在する外部機器に関する情報を取得し、取得した情報に基づいてＵＩを生成するように構成しても良い。つまり、携帯電話１は、携帯電話１周辺にある外部機器の存在を検知することにより、その外部機器に関連するＵＩ（当該外部機器を操作するリモコンアプリケーション用ＵＩなど）を、ユーザ操作に依存せずに自動で生成する。

また、上記各実施の形態において、ＵＩ生成装置である携帯電話１は、ＧＰＳなどにより取得した位置情報や時間情報に基づいて、生成するＵＩを選択するよう構成しても良い。つまり、携帯電話１は、現在位置の変化や予め設定されたスケジュールなどに基づいて、その時その場所で必要なＵＩを自動で生成する。

さらに、上述した各実施の形態では、各アプリケーションに対応したＵＩのＵＩ定義ファイルが予めＵＩ定義ファイル記憶領域５４に記憶された場合について説明したが、必要なＵＩ定義ファイルを適宜外部から取得するようにもできる。すなわち、ＵＩを生成する際に、記憶部５０に必要なＵＩ定義ファイルが記憶されていない場合には、携帯電話１の通信手段を介して必要なＵＩ定義ファイルをダウンロードして得るようにしても良い。

この場合、図３のステップＳ１１にて、ＵＩを提供するアプリケーションからＵＩ定義ファイルが指定された際、必要なＵＩ定義ファイルがＵＩ定義ファイル記憶領域５４に存在するか否か判定する。必要なＵＩ定義ファイルがＵＩ定義ファイル記憶領域５４に存在しない場合、制御部１０のＵＩ取得部１４は、無線通信部３０を介して、図示しない外部機器または外部サーバなどから、必要なＵＩ定義ファイルを取得する。

上述した各実施の形態では、タッチパネルを備える携帯端末でＵＩを合成処理する場合について説明した。しかしながら、本発明のＵＩ合成処理においては、タッチパネルは必須の要素ではない。本発明は、例えば機械式のキーを多数備える入力部や、任意のポインティングデバイスなどを有する端末の場合など、ＵＩを合成して使用することが想定される任意の入力部を備える端末に適用できる。

なお、上述した各実施の形態で用いるＵＩ定義ファイルの一例として、以下にＸＭＬをベースとしたＵＩＭＬ形式のファイルの例を示す。本発明による各ＵＩオブジェクト属性情報を付加した箇所には下線を付してある。また、本例において、ＵＩオブジェクトは<template>タグにより定義されており、したがって<template>〜</template>の間の記載がＵＩオブジェクト定義情報に相当する。

まず、テレビリモコンＵＩを構成するＵＩ定義ファイルとして、TV1_interface.uimlのファイルの例を示す。

次に、エアコンディショナーリモコンＵＩを構成するＵＩ定義ファイルとして、AIR1_interface.uimlのファイルの例を示す。

さらに、第３実施の形態において図１０で説明した、エアコンディショナーリモコンＵＩを構成するＵＩオブジェクトの有効／無効の属性が変更される際のＵＩ定義ファイルとして、AIR2_interface.uimlのファイルの例を一部抜粋して示す。

本発明によれば、複数のＵＩを合成し、各ＵＩに対応するアプリケーションの操作に際し重要なＵＩオブジェクトを自動的に選定して所定のＵＩ表示領域に収まる１つの合成ＵＩを生成できる。したがって、複数のＵＩを切り替えることなく同時に使用することができる。さらに、マルチウィンドウの場合の様に表示領域（ウィンドウ）を選択する操作や、表示領域内にてスクロールバーを移動させる操作が必要ないため、ユーザの操作負荷を大幅に軽減できる。

Claims (5)

1. アプリケーションプログラムに基づいて各種の機能を実現するアプリケーションプログラム実行部と、
   前記アプリケーションプログラムに基づく所定の機能の実行を前記アプリケーションプログラム実行部に指示するためのユーザインタフェースを生成するユーザインタフェース生成部と、
   前記ユーザインタフェース生成部により生成されるユーザインタフェースを表示する表示部と、
   前記ユーザインタフェースの構成要素であるユーザインタフェースオブジェクトを定義するユーザインタフェースオブジェクト定義情報を含むユーザインタフェース定義ファイルを格納する記憶部と、を備え、
   前記ユーザインタフェース生成部は、複数の前記ユーザインタフェースの生成が指示された場合、当該指示された複数のユーザインタフェースの各々に対応して前記記憶部に格納されたユーザインタフェース定義ファイルに含まれるユーザインタフェースオブジェクト定義情報を、前記表示部において当該ユーザインタフェースを表示する所定の表示領域に応じて取捨選択し、選択されたユーザインタフェースオブジェクト定義情報に基づいて合成ユーザインタフェースを生成するユーザインタフェース合成処理を行うことを特徴とするユーザインタフェース生成装置。
2. 前記ユーザインタフェースオブジェクト定義情報は、該ユーザインタフェースオブジェクトと、該ユーザインタフェースオブジェクトを含むユーザインタフェースに含まれる他のユーザインタフェースオブジェクトとの関係を示すユーザインタフェースオブジェクト属性情報を含み、
   前記ユーザインタフェース生成部は、複数の前記ユーザインタフェースの生成が指示された場合、前記表示領域と、前記ユーザインタフェースオブジェクト属性情報とに基づき、前記所定のユーザインタフェースオブジェクト定義情報を取捨選択することを特徴とする、請求項１に記載のユーザインタフェース生成装置。
3. 前記ユーザインタフェースオブジェクト定義情報は、当該ユーザインタフェースを構成する各ユーザインタフェースオブジェクトが有効か無効かを示すユーザインタフェースオブジェクト属性情報をさらに含み、
   前記ユーザインタフェース生成部は、複数の前記ユーザインタフェースの生成が指示された場合、前記表示領域と、前記ユーザインタフェースオブジェクト属性情報とに基づき、前記所定のユーザインタフェースオブジェクト定義情報を取捨選択することを特徴とする、請求項２に記載のユーザインタフェース生成装置。
4. 前記ユーザインタフェースオブジェクト定義情報は、当該ユーザインタフェースオブジェクトに対するイベント発生時に実行すべき動作内容を示すアクション情報を含み、
   該アクション情報は、他のユーザインタフェースオブジェクト定義情報に含まれる前記ユーザインタフェースオブジェクト属性情報の変更に関する情報を含み、
   前記ユーザインタフェース生成部は、前記合成ユーザインタフェースにおいて前記イベントが発生し、当該イベントの発生を受け付けたユーザインタフェースオブジェクトのユーザインタフェースオブジェクト定義情報に含まれるアクション情報に基づいて前記ユーザインタフェースオブジェクト属性情報が変更された場合、当該変更されたユーザインタフェースオブジェクト属性情報に基づいてユーザインタフェース合成処理を行い新たな合成ユーザインタフェースを生成することを特徴とする、請求項２または３に記載のユーザインタフェース生成装置。
5. 前記ユーザインタフェース定義ファイルは、該ユーザインタフェース定義ファイルに基づいて生成されるユーザインタフェースを識別する識別情報を含み、
   前記ユーザインタフェース生成部は、選択されたユーザインタフェースオブジェクト定義情報を前記識別情報に基づいて加工することを特徴とする、請求項１〜３のいずれか１項に記載のユーザインタフェース生成装置。

Images