| 【発明の名称】 |
異種装置プラットフォーム間を移動するプラットフォーム特定型のグラフィカルユーザインターフェイスのウィジェットの変換 |
| 【発明者】 |
【氏名】ウオング，ホイ リー キャンディー
【氏名】チュー，ハオーファ
【氏名】カタギリ マサジ
【氏名】ソング，ユー
【氏名】クラカケ ショウジ
|
| 【要約】 |
【課題】異種装置プラットフォームの表示画面のサイズに適合させるために、GUIウィジェットを変換すること。
【解決手段】SGUIシステムは、プラットフォーム独立型のプレゼンテーションモデルを含む。プラットフォーム独立型のプレゼンテーションモデルは、プラットフォーム独立型のGUIウィジェットを含んでいる。プラットフォーム独立型のGUIウィジェットは、異種装置プラットフォーム上にあるアプリケーションGUIが使用するプラットフォーム特定型のプレゼンテーションを生成するため、変換ルールにより選択的に変換されてもよい。選択されたプラットフォーム独立型のGUIウィジェットに、優先順位が適用可能な変換ルールが設定されてもよい。最も高い優先順位の変換ルールが、選択されたプラットフォーム独立型のGUIウィジェットの変換用に適用されてもよい。 |
【特許請求の範囲】
【請求項１】 異種装置プラットフォーム間を移動するグラフィカルユーザインターフェイスのウィジェットを変換する方法において、(a)プラットフォーム独立型のプレゼンテーションモデル内において変換されるプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットを特定する過程と、(b)前記特定されたプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットに適用される複数の変換ルールに優先順位を設定する過程と、(c)最も高い優先順位の変換ルールを用いて、前記特定されたプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットを変換する過程とを有することを特徴とする方法。
【請求項２】 前記(a)過程は、拡張性のあるグラフィカルユーザインターフェイスコンポーネント単体、および拡張性のあるグラフィカルユーザインターフェイスコンポーネント複合のうちの１つとして、前記プラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットを特定する過程を有することを特徴とする請求項１に記載の方法。
【請求項３】 前記(a)過程は、前記特定されたプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットに適用可能な変換ルールを検索する過程を有することを特徴とする請求項１に記載の方法。
【請求項４】 前記拡張性のあるグラフィカルユーザインターフェイスコンポーネント複合は、更に複数の拡張性のあるグラフィカルユーザインターフェイスコンポーネント単体を有し、前記(a)過程は更に、拡張性のあるグラフィカルユーザインターフェイス・コアコンポーネント及び拡張性のあるグラフィカルユーザインターフェイスオプションコンポーネントとして、前記拡張性のあるグラフィカルユーザインターフェイスコンポーネント複合に含まれている前記拡張性のあるグラフィカルユーザインターフェイスコンポーネント単体を特定する過程と、前記拡張性のあるグラフィカルユーザインターフェイスオプションコンポーネント上、それから前記拡張性のあるグラフィカルユーザインターフェイス・コアコンポーネント上で(b)過程と(c)過程とを実行する過程とを有することを特徴とする請求項２に記載の方法。
【請求項５】 前記(b)過程は、前記変換ルールに優先順位を設定するために、前記変換ルールを、複数タイプ中の１つのタイプにカテゴリー化する過程を有し、前記複数タイプは「１から１タイプへの変換ルール」、「１から複数タイプへの変換ルール」、「複数の同クラスから１タイプへの変換ルール」、及び「複数から複数タイプへの変換ルール」の中の１つのタイプを有していることを特徴とする請求項１に記載の方法。
【請求項６】 前記(b)過程は、前記特定されたプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットと互換性のある変換されたプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットを作成する前記変換ルールを選別することを特徴とする請求項１に記載の方法。
【請求項７】 前記(b)過程は、スペース縮小パラメータ、及び前記特定されたプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットの関数として、前記変換ルールを選別する過程を有し、前記スペース縮小パラメータは、幅縮小率、高さ縮小率、そして大きさ縮小率の中の１つを有していることを特徴とする請求項１に記載の方法。
【請求項８】 前記(b)過程は、前記変換ルールをタイプの関数として優先順位を設定する過程と、サポートされてない変換を削除する前記変換ルールを選別する過程と、スペース縮小パラメータの関数として、前記変換ルールに優先順位を設定する過程とを有することを特徴とする請求項１に記載の方法。
【請求項９】 前記変換されたプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットを、プラットフォーム特定型のプレゼンテーション内にあるプラットフォーム特定型のウィジェットへマッピングする(d)過程を更に有することを特徴とする請求項１に記載の方法。
【請求項１０】 異種装置プラットフォーム間を移動するグラフィカルユーザインターフェイスのウィジェットを変換する方法において、(a)コアあるいはオプショナルとして、拡張性のあるグラフィカルユーザインターフェイスコンポーネント複合に含まれている複数の拡張性のあるグラフィカルユーザインターフェイスコンポーネント単体をカテゴリー化する過程と、(b)前記拡張性のあるグラフィカルユーザインターフェイスコンポーネント単体に適用可能な変換ルールを特定する過程と、(c)前記特定された変換ルールに優先順位を設定する過程と、(d)優先順位の高い適用可能な変換ルールで、選択的に前記拡張性のあるグラフィカルユーザインターフェイスコンポーネント単体を変換するする過程とを有することを特徴とする方法。
【請求項１１】 前記(a)過程は、前記各々の拡張性のあるグラフィカルユーザインターフェイスコンポーネント単体に関連している重要プロパティに基づき、コア及びオプショナルの１つとしてカテゴリを選択することを特徴とする請求項１０に記載の方法。
【請求項１２】 前記(b)過程は、前記拡張性のあるグラフィカルユーザインターフェイスコンポーネント単体によりサポートされていない入力方法で、変換された拡張性のあるグラフィカルユーザインターフェイスコンポーネントを作成する変換ルールを削除することを特徴とする請求項１０に記載の方法。
【請求項１３】 前記(c)過程は、変換ルールのタイプに優先順位を設定し、前記変換ルールのタイプは、「１から１タイプへの変換ルール」、「１から複数タイプへの変換ルール」、「複数の同クラスから１タイプへの変換ルール」、及び「複数から複数タイプへの変換ルール」の中の１つのタイプを有していることを特徴とする請求項１０に記載の方法。
【請求項１４】 前記変換ルールが適用されると、前記(c)過程は前記各々の拡張性のあるグラフィカルユーザインターフェイスコンポーネント単体のサイズ縮小機能として優先順位を設定することを特徴とする請求項１０に記載の方法。
【請求項１５】 前記(d)過程は、前記拡張性のあるグラフィカルユーザインターフェイスコンポーネント単体の実行状態を、前記変換された拡張性のあるグラフィカルユーザインターフェイスコンポーネントの実行状態に変換し、前記実行状態は、外観、状態変化及びデータの中の１つを少なくとも含んでいることを特徴とする請求項１０に記載の方法。
【請求項１６】 前記(d)過程は、前記拡張性のあるグラフィカルユーザインターフェイスコンポーネント単体のイベント処理メカニズムを、前記変換された拡張性のあるグラフィカルユーザインターフェイスコンポーネントの前記イベント処理メカニズムへマッピングすることを特徴とする請求項１０に記載の方法。
【請求項１７】 最初にオプショナルとしてカテゴリー化された前記拡張性のあるグラフィカルユーザインターフェイスコンポーネント単体上で前記(b)過程、前記(c)過程、及び前記(d)過程を実行し、次にカテゴリー化された前記拡張性のあるグラフィカルユーザインターフェイス・コアコンポーネント単体上で前記(b)過程、前記(c)過程、及び前記(d)過程を実行することを特徴とする請求項１０に記載の方法。
【請求項１８】 異種装置プラットフォーム間を移動するグラフィカルユーザインターフェイスのウィジェットを変換する方法において、(a)コンテナノードが複数の第１コンポーネントノードに関連しているプラットフォーム独立型のプレゼンテーションモデルを形成する過程と、(b)各々の第１コンポーネントノードにより表されている複数のプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットを、少なくとも１つの第２コンポーネントノードにより表されている少なくとも１つの異なるプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットに変換する過程と、(c)前記コンテナノードと前記第１コンテナノード間における既存の論理関係を置き換える新しい論理関係を作成するため、前記第２コンポーネントノードを前記コンテナノードにリンクされる過程とを有することを特徴とする方法。
【請求項１９】 前記プラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットが異なるクラスの一部分であるとき(異なるクラスに属しているとき)、少なくとも１つの前記異なるプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットを生成するため、前記(b)過程は、複数の同クラスから１タイプへの変換ルールと複数から複数タイプへの変換ルールの中の少なくとも１つを適用することを特徴とする請求項１８に記載の方法。
【請求項２０】 前記プラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットが同じクラスの一部分であるとき(同じクラスに属しているとき)、単一の異なるプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットを生成するため、前記(b)過程は、複数の同クラスから１タイプへの変換ルールを適用することを特徴とする請求項１８に記載の方法。
【請求項２１】 前記(c)過程は、前記プラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットを変換するため、フォーム記入関係を適用することを特徴とする請求項１８に記載の方法。
【請求項２２】 前記少なくとも１つの異なるグラフィカルユーザインターフェイスのウィジェットの実行状態として、前記(c)過程は、前記プラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットを適用することを特徴とする請求項１８に記載の方法。
【請求項２３】 異種装置プラットフォーム間を移動するグラフィカルユーザインターフェイスのウィジェットを変換する拡張性のあるグラフィカルユーザインターフェイスシステムにおいて、プラットフォーム独立型のプレゼンテーションモデル内で変換されるプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットを特定するサーバを有し、前期サーバは前記特定されたプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットに適用可能な複数の変換ルールに優先順位を設定し、かつ最も高い優先順位の変換ルールを有している前記特定されたプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットを変換することを特徴とする拡張性のあるグラフィカルユーザインターフェイスシステム。
【請求項２４】 前記変換ルールの優先順位は、ルールの種類、互換性のない変換結果を削除する変換ルールの選別、及び変換に関連しているスペース縮小パラメータの中の少なくとも１つに基づいて、決定されることを特徴とする請求項２３に記載の拡張性のあるグラフィカルユーザインターフェイスシステム。
【請求項２５】 前記サーバは、前記特定されたプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットのイベント処理を変換することを特徴とする請求項２３に記載の拡張性のあるグラフィカルユーザインターフェイスシステム。
【請求項２６】 前記サーバは、前記変換及び特定されたプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットからマップされるプラットフォーム特定型のグラフィカルユーザインターフェイスのウィジェットを含む異種装置プラットフォーム用のプラットフォーム特定型のプレゼンテーションを生成することを特徴とする請求項２３に記載の拡張性のあるグラフィカルユーザインターフェイスシステム。
【請求項２７】 前記サーバは変換モジュール、及び拡張性のあるグラフィカルユーザインターフェイスライブラリを有し、変換を実行するため、前記変換モジュールは前記拡張性のあるグラフィカルユーザインターフェイスライブラリと協同して動作することを特徴とする請求項２３に記載の拡張性のあるグラフィカルユーザインターフェイスシステム。
【請求項２８】 前記特定されたプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットは、複数の拡張性のあるグラフィカルユーザインターフェイスコンポーネント単体を含む拡張性のあるグラフィカルユーザインターフェイスコンポーネント複合であり、そして前記サーバは、グラフィカルユーザインターフェイス・コアコンポーネント、及びグラフィカルユーザインターフェイス・オプショナルコンポーネントとしてカテゴリー化された前記拡張性のあるグラフィカルユーザインターフェイスコンポーネント単体の変換を実行することを特徴とする請求項２３に記載の拡張性のあるグラフィカルユーザインターフェイスシステム。
【請求項２９】 前記サーバは、前記変換及び特定されたプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットを、前記プラットフォーム独立型のモデルにおける他のプラットフォーム独立型のグラフィカルユーザインターフェイスのウィジェットへリンクさせることを特徴とする請求項２３に記載の拡張性のあるグラフィカルユーザインターフェイスシステム。
|
【発明の詳細な説明】【０００１】
【発明の属する技術分野】本発明は、グラフィカルユーザインターフェイス(GUI)に関し、特に、異種装置プラットフォーム間を移動するプラットフォーム特定型のGUIウィジェットの変換に関する。
【０００２】
【従来の技術】パソコン、個人情報端末(PDA)、無線電話、そしてページャーなどの個人向けの電子装置(携帯装置)が、ここ近年流行している。これらの携帯装置は、無線や有線ネットワークを利用した通信を行なえるので、モバイルコンピューティングを可能にしている。ネットワークは、これらの携帯装置に、情報ソースおよび他の類似の装置への接続を提供している。一般的に、ネットワークはインターネット上での通信も含んでいる。
【０００３】モバイルコンピューティング装置は、ある型のユーザインターフェイス(UI)を持っている。ある装置のユーザインターフェイスの特性は、その装置の処理能力とハードウェアによる。例えば無線電話には、限られた処理能力、及び限られたグラフィックとユーザインターフェイス能力しか有していない小さなグラフィカルユーザインターフェイス（GUI）しか与えられていない。逆に、ノートパソコンには、相対的に拡張性のあるグラフィック能力とユーザインターフェイス能力、そして処理能力が与えられている。携帯装置の人気が高まるに連れて、アプリケーションのメインプラットフォームは、デスクトップ型パソコンから携帯装置へとシフトすると思われる。
【０００４】
【発明が解決しようとする課題】携帯装置のアプリケーションの開発が困難な1つの理由は、携帯装置の異質性である。多種多様なディスプレイのサイズ、解像度、コマンドの入力方法、そしてGUIライブラリがあるため、アプリケーションの開発者は、各装置プラットフォームのグラフィカルユーザインターフェイス(GUI)用に、アプリケーションを再設計及び再実装する必要がある。たくさんの異なる携帯装置が利用され、または市場に参入しているので、再設計と再実装に、たくさんの労働力と生産コストを要する努力が現在もなされている。
【０００５】１つの解決策は、モデルベース技術による開発である。１つの例が、ユーザインターフェイスモデリングである。一般的に、ユーザインターフェイスモデリングは、プラットフォームモデル、プレゼンテーションモデル、そしてタスクモデルを含む。プラットフォームモデルでは、サポートされる装置用のユーザインターフェイスを形成する操作機能が示される。プレゼンテーションモデルでは、サポートされる装置に関連したユーザインターフェイスの外観に関する階層、及び様式の選択と配置が示される。タスクモデルでは、サポートされる装置のユーザが実行するタスクが示される。この技術を使用することにより、特定の装置用のインターフェイスの生成のため、異なるモデル間におけるマッピングが開発されると思われる。
【０００６】モデルベース型アプローチの実装は、モデルを実装するためのハイレベル言語の開発を含んでいる。さらに開発者は、装置をサポートするためにモデルの重要な部分を設定し、かつ特定する。ハイレベル言語は非常に複雑なので、モデルベース型アプローチを実行する前に、開発者は、実行メカニズムの知識とハイレベル言語を共に学ぶ必要がある。さらにモデルベース型アプローチは、開発者が作った異なるモデルに基づくコードを作成する。装置のユーザインターフェイス要求においては小さな差異でも、２つの似たタイプの装置用に生成されたコードにおいては大きな差異になることもある。従って開発者に求められるプログラミング技能のレベルは、とても重要になってくる。
【０００７】
【課題を解決するための手段】本発明では、ノンモデルベース型の拡張性のあるグラフィカルユーザインターフェイス（SGUI）システムを開示している。SGUIシステムにより、拡張性のあるアプリケーションは、複数の異種装置プラットフォーム上において動作することが可能となる。拡張性のあるアプリケーションは、アプリケーション・グラフィカルユーザインターフェイス（GUI）を含んでもよい。アプリケーションGUIは、拡張性のあるアプリケーションが動作している異種装置プラットフォームの中の１つのユーザインターフェイスで動くSGUIシステムに適合していてもよい。アプリケーション開発者は、モデルベース型のアプローチの複雑さを伴わない異種装置プラットフォーム内において、ユーザインターフェイス機能から独立している複数のアプリケーションGUIを設定してもよい。さらに異種装置プラットフォームに関連しているユーザインターフェイスとGUIライブラリの複雑さも、SGUIシステムを利用しているアプリケーション開発者により解消されることが可能になる。
【０００８】SGUIシステムは、拡張性のあるGUIライブラリ、カスタマイズモジュール、そしてレンダーマネージャモジュールを有している。カスタマイズモジュールは、タスクマネージャモジュールと変換マネージャモジュールを有している。拡張性のあるアプリケーションが起動、または異種装置プラットフォーム（ここでは、ターゲット装置プラットフォーム）へ移ると、アプリケーションGUIの中間表現が、拡張性のあるアプリケーションによりインスタンス化される。その中間表現は、階層的な構造において、少なくとも１つの論理パネルと、少なくとも１つの拡張性のあるグラフィカルユーザインターフェイス（SGUI）コンポーネントの表示を含むことが可能な装置プラットフォーム独立型の論理構造形式におけるプラットフォーム独立型のプレゼンテーションモデルである。中間表現内におけるノードは、論理パネルを表すコンテナノードと、SGUIコンポーネントを表すコンポーネントノードを含んでもよい。
【０００９】中間表現は、アプリケーションGUIのアプリケーション開発者により特定されたプロパティ、及びターゲット装置プラットフォームの機能に基づいたカスタマイズモジュールによりカスタマイズされたものであってもよい。中間表現のカスタマイズにより、プラットフォーム独立型のプレゼンテーションモデルは、プラットフォームの特定表示を表している特定のプラットフォーム依存型の論理構造へと変換する。
【００１０】プラットフォーム特定型のプレゼンテーションの開発中において、カスタマイズモジュールを用いた変換カスタマイズを実行してもよい。変換は、プラットフォーム独立型のプレゼンテーションモデルのノードに関連するプラットフォーム独立型のGUIウィジェットの選択的な処理を含む。プラットフォーム独立型のGUIウィジェットは、SGUIコンポーネント単体、またはSGUIコンポーネント複合であってもよい。プラットフォーム独立型のGUIウィジェットへマップするプラットフォーム特定型のGUIにより、プラットフォーム特定型のプレゼンテーションのページのサイズがターゲット装置プラットフォームの表示画面を超えたとき、特定のプラットフォーム独立型のGUIウィジェットの変換が起きてもよい。
【００１１】変換の原因となったプラットフォーム独立型のGUIウィジェットに基づいて、適切な変換ルールが特定されてもよい。適切な変換ルールは、変換ルールの種類に応じてカテゴリー化されてもよい。またカテゴリー化の後、変換ルールに優先順位が設定されてもよい。最も高い優先順位の変換ルールは、変換をトリガしたプラットフォーム独立型のGUIウィジェットに適用されてもよい。
【００１２】変換の原因となったプラットフォーム独立型のGUIウィジェットがSGUIコンポーネント複合であったとき、SGUIコンポーネント複合内のSGUIコンポーネント単体は、各々のSGUIコンポーネント単体用に特定された重要プロパティに基づいて、SGUIコンポーネント単体に最初にSGUIコアコンポーネント、及びSGUIオプショナルコンポーネントとしてカテゴリー化される。各々のSGUIコンポーネント単体に対し、変換ルールに優先順位を設定してもよい。最も高い優先順位の変換ルールは、各々のSGUIコンポーネント単体に適用されてもよい。
【００１３】プラットフォーム独立型のGUIウィジェットの変換により、１つあるいはそれ以上の異なるプラットフォーム独立型のGUIウィジェットに変換する複数のプラットフォーム独立型のGUIウィジェットが作成されてもよい。プラットフォーム独立型のプレゼンテーションモデル内において、コンテナノードは、各々がプラットフォーム独立型のGUIウィジェットを表している複数の第１コンポーネントノードに関連してもよい。もしコンテナノードにより、ページのサイズがターゲット装置プラットフォームの表示画面より大きくなったら、コンポーネントノードにより表されるプラットフォーム独立型のGUIウィジェットが、第２コンポーネントノードに関連している１つ、あるいはそれ以上の異なるプラットフォーム独立型のGUIウィジェットに変換されてもよい。第２コンポーネントノードは、論理関係を第１コンポーネントノードと置き換えるために、プラットフォーム独立型のプレゼンテーションモデルにリンクされてもよい。
【００１４】SGUIシステムの魅力的な特徴は、変換ルールをタイプ別にカテゴリー化することである。変換ルールは、「１から１タイプへの変換ルール」、「１から複数タイプへの変換ルール」、「複数の同クラスから１タイプへの変換ルール」、及び「複数から複数タイプへの変換ルール」の中の１つにカテゴリー化が可能である。「１から複数タイプへの変換ルール」、「複数の同クラスから１タイプへの変換ルール」、及び「複数から複数タイプへの変換ルール」の変換ルールがノードに適用されるとき、リンクが実行されてもよい。
【００１５】SGUIシステムの別の魅力的な特徴は、特定された変換ルールに優先順位を設定することである。優先順位設定の一環として、変換ルールは「複数から複数タイプへの変換ルール」としてカテゴリー化され、カテゴリー化された変換ルールには最も低い優先順位が設定されてもよい。またサポートされていない変換を削除するため、変換ルールは選別されてもよい。さらに、変換されたプラットフォーム独立型のGUIウィジェットにおけるスペース縮小に基づき、変換ルールに優先順位が設定されてもよい。そして最も高い順位の変換ルールが、プラットフォーム独立型のGUIウィジェットを変換するために、選択されてもよい。
【００１６】SGUIシステムの別の魅力的な特徴は、SGUIコンポーネント複合を含んでいることである。変換ルールは、SGUIコンポーネント複合内において、最初にオプショナルとしてカテゴリー化されたSGUIコンポーネント単体に変換される。もしSGUIコンポーネント複合が、表示画面のページに適合しない場合、SGUIコンポーネント複合が表示画面のページに適合するまで、SGUIコアコンポーネントは変換を続ける【００１７】
【発明の実施の形態】本発明における他の特徴と利点は、図面と以下の詳細な説明で明らかにされる。好ましい実施形態の以上の説明は、ただの一例に過ぎず、本発明の範囲を定義する特許請求の範囲を制限するものではない。
【００１８】本発明の好ましい実施形態において、異なる複数の装置プラットフォーム上で動作することのできる拡張性のあるアプリケーションと共に使う拡張性のあるグラフィカルユーザインターフェイス(SGUI)アーキテクチャを説明する。拡張性のあるアプリケーションは、異種装置プラットフォームに対応付けられた多種のユーザインターフェイスと共に動作するように、SGUIシステムにより動的に適合されてもよい。SGUIシステムを使用することにより、拡張性のあるアプリケーションを、その拡張性のあるアプリケーションが動作することになる異種装置プラットフォームから独立したユーザインターフェイス機能を有するように設計できる。拡張性のあるアプリケーションの開発者は、SGUIシステムの使用をしなければ、種々の異種装置プラットフォームへのユーザインターフェイスを作成する時に、多くの複雑なプログラム作成が必要になるが、SGUIシステムを使用すると、これらを避けることができる。さらに、SGUIシステムは、モデルベース型の技術のようなモデル構造がなくても、異種装置プラットフォームで動作する。このようなわけで、アプリケーション開発者によるプログラミングは比較的簡単であり、モデル構築、及び/またはモデル操作技術は必要でない。
【００１９】拡張性のあるアプリケーションには、異なるプラットフォーム装置上で動作することのできるアプリケーションが含まれる。拡張性のあるアプリケーションのほとんどは、異種装置プラットフォームの表示画面用のプレゼンテーションを生成する機能を有している。プレゼンテーションは、視覚的な素材からなる１ページまたはそれ以上のページ（またはプレゼンテーション単位）を含んでもよい。視覚的な素材は、異種装置プラットフォームのユーザのために、表示画面上に配置されてもよい。拡張性のあるアプリケーションは、アプリケーションGUIでプレゼンテーションを生成してもよい。アプリケーションGUIは、拡張性のあるグラフィカル・ユーザインターフェイス・アプリケーションのコンポーネントである。
【００２０】異種装置プラットフォームは、表示機能と拡張性のあるアプリケーションを動作させる機能を兼ね備えた装置であってもよい。典型的な異種装置プラットフォームは、無線電話、ポケットPC、個人情報端末(PDA)、ぺージャー、デスクトップコンピュータ、ノートブックコンピュータ、車載コンピュータ、または拡張性のあるアプリケーションを実行する機能のある表示画面を兼ね備えた有線/無線装置を含んでもよい。また異種装置プラットフォームは、例えばWindows NT（登録商標）、Windows 2000（登録商標）、Linux（登録商標）、Solaris（登録商標）、MacOS（登録商標）、Palm（登録商標）、Windows CE（登録商標）、独自のオペレーティングシステム、またはその他の装置に機能性を提供するオペレーティングシステムを含んでもよい。オペレーティングシステムは、拡張性のあるアプリケーションを起動させたりサポートするための機能を提供してもよい。
【００２１】異種装置プラットフォームは、拡張性のあるアプリケーションを動作させたり、機能を提供するハードウェアまたはソフトウェアを含んでいてもよい。例えば、メモリのような記憶手段を含んでいてもよい。記憶手段は、例えば、オペレーティングシステム、拡張性のあるアプリケーション、および装置プラットフォームに関する他の情報を記憶してもよい。さらに、異種装置プラットフォームは、ユーザインターフェイスを含んでもよい。ユーザインターフェイスは、例えば、表示装置、キーボード、マウスに似たポインティングデバイス、タッチスクリーン、キーパッド、オーディオ機能、または異種装置プラットフォームのユーザ用のインターフェイスを提供する手段を含んでもよい。
【００２２】異種装置プラットフォームの機能は、多岐に異なっていてもよい。ここで言う機能とは、異種装置プラットフォームと拡張性のあるアプリケーションの動作に影響を与えるハードウェア的な特徴と装置機能のことである。つまり、例えば、装置プラットフォームのタイプ（例：無線電話、PDA,ラップトップPC等）、利用可能なユーザインターフェイスライブラリ、表示画面のサイズと解像度である。さらに、代表的な機能として、表示画面に関するユーザインターフェイス、計算処理容量、メモリのサイズ、プラットフォームの使用、または装置プラットフォームのユーザインターフェイスと動作に影響するその他のパラメータが挙げられる。
【００２３】本発明の好ましい実施形態において、異種装置プラットフォームは、Java（登録商標）の技術で作られた拡張性のあるアプリケーションを実行する移動装置である。Java（登録商標）の技術は、Java（登録商標）VM(Virtual Machine;バーチャルマシン)上で動くJava（登録商標）プログラミング言語を有している。Java（登録商標）VMは、多種に渡る装置プラットフォーム上に移植されてもよい。典型的なJava（登録商標）技術の実装は、ノートPCの装置プラットフォーム上で動くJava（登録商標）VM、ポケットPCの装置プラットフォーム上にあるパーソナルJava（登録商標）VM、無線電話の装置プラットフォーム上で動くJava（登録商標）KVMである。他の実施形態においては、他のプログラミング言語/技術、および他の装置プラットフォームが、SGUIシステムで使用される。他のプログラミング言語/技術とは、C言語、C++言語、マイクロソフトのＣシャープ言語、及び/または他の技術である。
【００２４】SGUIシステムは、拡張性のあるアプリケーションに対応付けられたアプリケーションGUIの中間表現をインスタンス化させる。中間表現と同様にアプリケーションGUIは、非装置に特定したもの（例えば、装置プラットフォームから独立しているもの）であるが、装置プラットフォームと適合性がある方が好ましい。プラットフォーム独立型のプレゼンテーションモデルにおける中間表現のインスタンスの作成は、拡張性のあるアプリケーションのアプリケーションGUIに基づいてもよい。中間表現は、拡張性のあるアプリケーションにより生成されるプレゼンテーション用の論理構造を提供してもよい。この論理構造を、異種装置プラットフォーム用にカスタマイズして、SGUIシステムによるプラットフォーム特定型のプレゼンテーションを作成してもよい。カスタマイズは、プレゼンテーションを表示させる異種装置プラットフォームの機能と、アプリケーションGUI内で特定されたプロパティに基づいてもよい。SGUIシステムによるカスタマイズは、装置プラットフォーム用のグラフィカルユーザインターフェイスの開発において共通な３つの問題を提起している。即ちそれらは、表示画面サイズ、入力方法、及びユーザインターフェイスライブラリである。
【００２５】・表示画面サイズ拡張性のあるアプリケーションは、複数の異種装置プラットフォーム上で動作することができる。よって、拡張性のあるアプリケーションを開発しているアプリケーションプログラマは、表示画面用に特定なサイズを採り上げる必要はない。例えば、ドコモ 503ｉ無線電話は120×130画素の表示画面を兼ね備え、コンパックのIPAQポケットPCは320×240画素の表示画面を兼ね備え、典型的なノートPCは、1024×768画素の表示画面を兼ね備えている。表示画面のサイズは、表示画面上におけるプレゼンテーションのページを形成しているコンポーネントのレイアウトや、視覚的なプレゼンテーションの品質に影響を及ぼすこともある。
【００２６】ページを形成するコンポーネントを、グラフィカルユーザインターフェイス（GUI）コンポーネントと呼んでもよい。GUIコンポーネントは、表示画面の状況に応じて、固定およびアニメ化が可能であり、及び/またはインタラクティブであるプレゼンテーションの表示機能である。GUIコンポーネントの典型例は、グラフィカルラベル、グラフィカルボタン、グラフィカルチェックボックス、グラフィカルテキストフィールド、グラフィカルテキストエリア、グラフィカルリスト/テーブル、グラフィカルバックグラウンド、データ入力フィールド、プルダウンメニュー、及び/または表示画面上に表示する機能を兼ね備えているものである。GUIコンポーネントは、固有の識別子と一緒にGUIライブラリに保存されてもよい。この識別子により、例えば、既に述べられているアプリケーションGUIは、GUIコンポーネントでプレゼンテーションを作る。
【００２７】プレゼンテーションは、表示画面のサイズの関数として、複数ページに細かく分割されてもよい。例えば、ノートブックPCのような相対的に大きな表示画面は、大きなサイズ、及び/またはたくさんの量のGUIコンポーネントを含んだ大きなページを表示することができる。一方、例えば、無線電話のような小さな画面は、かなりコンパクトなGUIコンポーネントを持った小さなページのみ表示することができる。さらに、小さなページは、表示画面上において、一度にほんの少しのGUIコンポーネントしか表示できない。
【００２８】SGUIシステムは、異種装置プラットフォームの表示画面を最大限に埋めるために用いることもできる。中間表現を用いることにより、SGUIシステムは、ダイナミックなレイアウトとアプリケーションGUIのグラフィカルユーザインターフェイス（GUI）変換を提供できる。このようにアプリケーションGUIは、拡張性のあるアプリケーションが動いている異種装置プラットフォームの表示画面に拡大縮小されてもよい。
【００２９】・入力方法異種装置プラットフォームは、また拡張性のあるアプリケーションとアプリケーションGUIに対応付けられている異なる入力方法を兼ね備えていてもよい。例えば入力方法として、無線電話はキーパッド、ポケットPCは手書き入力用のペン、ノートブックPCはキーボード、及び/またはマウスのようなポインティングデバイスを利用する。従って、拡張性のあるアプリケーションのアプリケーション開発者は、対応しているアプリケーションGUI用特定の入力方法を採用しなくてもよい。
【００３０】SGUIシステムは、異種装置プラットフォームに対応できる装置プラットフォーム独立型のGUIイベントを提供する。GUIイベントは、ページ上の視覚的な素材内における状態の変化である。ユーザが、異種装置プラットフォームのユーザインターフェイスと対話することにより、GUIイベントを引き起こされることもある。SGUIシステムにより、装置プラットフォーム特定のGUIイベントを、装置プラットフォーム独立のGUIイベントに、動的に変換される。このように、SGUIシステムを利用している拡張性のあるアプリケーションは、異種装置プラットフォームのユーザインターフェイスと適合性があり、かつ異種装置プラットフォームのユーザインターフェイスから独立しているGUIイベント機能を持つように設計される。
【００３１】・ユーザインターフェイスライブラリ異種装置プラットフォームは、また異なるアプリケーションプログラムインターフェイス（API）をサポートしてもよい。APIは、広範囲にわたる機能を提供する出来合いのソフトウェアコンポーネントの集まりの１つである。例えば、Java（登録商標）技術は、Java（登録商標）プリケーションプログラムインターフェイス（API）を持っている。Java（登録商標）（API）は、Java（登録商標）型プログラム内で実装される標準的な機能を提供するソフトウェアコンポーネントの集まりである。
【００３２】Java（登録商標）プラットフォームは、「一度書いたらどこでも動く（WriteOnce, Run Anywhere; WORA）」を主張しているが、移動装置環境で開発しているJava（登録商標）アプリケーションにとって、これは当てはまらないこともある。例えば無線電話で、Java（登録商標）プログラミング言語は、Java（登録商標） 2 Micro Edition(J2ME)であってもよい。基本的にJ2MEのデザインは、柔軟性と分断に基づいている。柔軟性を成し遂げるため、J2MEは装置プラットフォーム特定型のAPIを設定している。装置プラットフォーム特定型のAPIは、プロファイルとして言及される。J2MEアプリケーションは、特定の装置プラットフォームで動くように書かれているので、異なるプロファイルは分断してしまう。例えば、ドコモ503ｉの無線電話はJ2ME DoJa APIとして言及されるJava（登録商標）プロファイルをサポートしてもよい。同様に、ポケットPCはPersonal Java（登録商標） AWT APIを、ノートブックパソコンはJava（登録商標）2 Standard Edition(J2SE) SWING APIをサポートしてもよい。
【００３３】APIは、異種装置プラットフォームによって、異なるGUIライブラリをサポートしてもよい。例えば、PDAは、対応しているGUIライブラリ内において、より多くのタッチスクリーン関連のGUIコンポーネントを兼ね備えていてもよい。一方、例えば無線電話は、対応しているGUIライブラリ内において、指示関連のGUIコンポーネントしか兼ね備えていてなくてもよい。既に知られている通り、GUIライブラリは、プレゼンテーションを作成するためにアクセス可能な既成のGUIコンポーネントを編集したものである。
【００３４】１つの実施形態のSGUIシステムは、異種装置プラットフォームと適合性があり、かつその上でサポートされる装置プラットフォーム独立型APIを提供する。装置プラットフォーム独立型のAPIは、異種装置プラットフォームに対応付けられている異なるGUIライブラリへ、ブリッジング（橋渡し）機能を提供する。したがって、SGUIシステムを利用しているアプリケーション開発者は、異種装置プラットフォーム用のプラットフォーム特定型のGUIプレゼンテーションを開発するため、異なるGUIライブラリに精通している必要はない。
【００３５】SGUIシステムの典型的な動作例は、拡張性のあるアプリケーションがある装置プラットフォームから別の装置プラットフォームへマイグレーションすることである。拡張性のあるアプリケーションのマイグレーションは、ソース（供給元）装置プラットフォームからターゲット装置プラットフォームへ、動作中の拡張性のあるアプリケーションのインスタンスのマイグレーションを含んでいる。例えば、会社でマウスやキーボードを使い、ラップトップPCで、Eメールに関連している拡張性のあるアプリケーションを操作しているユーザを考えてください。ここで仕事の完了前に、ユーザは会社を出る必要がある。この時にユーザは、まだアクティブな拡張性のあるアプリケーションを、ラップトップPC（ソース（供給元）装置プラットフォーム）からPDA(ターゲット（目的）装置プラットフォーム)へと動かすことにより、Eメール作業機能を続行できる。ラップトップPCの表示画面はPDAより大きいので、アプリケーションのプレゼンテーションは、SGUIシステムによりPDAの表示画面に適合される。これに伴い、ラップトップPCのマウスやキーボードで動いていたユーザインターフェイス機能もまた、SGUIシステムにより、PDA上にあるタッチスクリーンのユーザインターフェイス機能に適合されてもよい。SGUIシステムは、ソースおよびターゲット装置プラットフォームから独立しているユーザインターフェイスの拡張性のあるアプリケーションの移動性を提供する。このように拡張性のあるアプリケーションは、SGUIシステムを使いながら動作する時にだけ必要であり、特に２つの装置プラットフォーム上で動作する時に必要なわけではない。
【００３６】図１は、拡張性のあるグラフィカルユーザインターフェイス(SGUI)システム１０のある実施形態のブロック図である。SGUIシステム１０は、拡張性のあるGUIライブラリモジュール１２、カスタマイズモジュール１４、そしてレンダーマネージャモジュール１６を持っている。図に描かれた実施形態は、本発明の理解を助けるためのものであり、これらの装置は個々に独立したものではなく、同図より少ないまたは多い装置が、SGUIシステム１０を説明している様々な実施形態で利用されてもよい。
【００３７】拡張性のあるGUIライブラリモジュール１２は、拡張性のあるアプリケーションの開発中において、アプリケーションの開発者が使用するツールであってもよい。さらに、拡張性のあるGUIライブラリモジュール１２は、SGUIシステム１０による中間表現と共に使用するため、GUIコンポーネントのライブラリを提供してもよい。ある実施形態において、装置プラットフォーム独立型APIは、拡張性のあるアプリケーションの開発中において使用されてもよい。また中間表現を作るため、装置プラットフォーム独立型APIは、装置プラットフォーム独立型のアプリケーションGUI内に、アプリケーション開発者により実装されてもよい。したがって、装置プラットフォーム独立型のアプリケーションGUIを使用して中間表現のインスタンス化には、拡張性のあるGUIライブラリモジュール１２内において、装置プラットフォーム独立型のAPIを実行することが含まれる。中間表現のインスタンス化は、中間表現は装置プラットフォーム独立型のプレゼンテーションモデルということを表している図１において、「装置独立型中間表現」となっている。
【００３８】一般的に、拡張性のあるGUIライブラリモジュール１２は、Java（登録商標）アブストラクト ウインドウ ツールキット(AWT)のようなGUIライブラリの他のフォームに似ている。本発明の好ましい実施形態において、拡張性のあるGUIライブラリモジュール１２は、Java（登録商標）のアプリケーションGUIに似たスタイルで作られている。従って、Java（登録商標）技術に詳しいアプリケーションプログラマが、装置プラットフォーム特定型APIを利用する現存の装置プラットフォーム特定型のアプリケーションGUIを、SGUIシステム１０内において、装置プラットフォーム独立型のAPIを利用する装置プラットフォーム独立型のアプリケーションGUIに変換する要求は少なくなる。
【００３９】カスタマイズモジュール１４は、ターゲット装置プラットフォームの装置独立の中間表現をカスタマイズするために動作する。「ターゲット装置プラットフォーム」と言う語は、拡張性のあるアプリケーションがディスプレイ用のプレゼンテーションを生成する、異種装置プラットフォームを特定する。ターゲット装置プラットフォームとして、拡張性のあるアプリケーションが特定された装置プラットフォーム上を動作している間に、プレゼンテーションは生成されてもよい。さらに拡張性のあるアプリケーションが、ソースからマイグレーションの目的である装置プラットフォーム(ターゲット装置プラットフォーム)へマイグレーションする時、プレゼンテーションが生成されてもよい。ある実施形態におけるカスタマイズモジュール１４は、タスクマネージャモジュール１８と変換マネージャモジュール２０を持っている。
【００４０】ある実施形態におけるタスクマネージャモジュール１８は、ターゲット装置プラットフォームの機能に基づいて装置独立型の中間表現の機能を取り除いてもよい。その中間表現は、タスクマネージャモジュール１８によりタスクが取り除かれたことを表している「取り除かれた中間表現」と図１に示されている。ある実施形態において、拡張性のあるアプリケーションは、ターゲット装置プラットフォームの機能を特定し、そしてその機能をタスクマネージャモジュール１８へ提供する。またある実施形態において、タスクマネージャモジュール１８は、ターゲット装置プラットフォームの機能を特定することができる。
【００４１】中間表現から取り除かれたタスクは、ターゲット装置プラットフォームに適合しない拡張性のあるアプリケーションの代表的な機能/能力を持っていてもよい。例えば、ラップトップパソコンは、電話のテンキー機能に関連しているタスクは使わない。同様に、利用できる能力に制約があるため、ターゲット装置プラットフォーム上に全てのタスクを表示することは望ましくないともいえる。例えば、多量のテキストデータを入力するのに、無線電話のテンキーを使うのは面倒くさい上、時間もかかる。だからタスクマネージャモジュール１８は、無線電話にとっては面倒である編集機能に関連したタスクを取り除いてもよい。ある実施形態において、タスクマネージャは、ターゲット装置プラットフォームの機能、及び/または中間表現内におけるアプリケーション開発者により特定された他のプロパティに応じて、タスクを取り除いてもよい。
【００４２】変換マネージャモジュール２０は、中間表現を装置プラットフォーム依存型のプレゼンテーションに変換するように動く。装置プラットフォーム依存型のプレゼンテーションは、ターゲット装置プラットフォーム内で、特定のユーザインターフェイスに適合してもよい。中間表現の変換は、タスクマネージャモジュール１８が不要なタスクを取り除くことにより始まる。中間表現の変換には、ターゲット装置プラットフォームの機能ベースの中間表現、中間表現の論理構造、及び/またはアプリケーションGUIが特定したプロパティを動的に変更することが含まれる。以下における変換マネージャモジュール２０による変換において、中間表現は装置プラットフォーム依存型の中間表現であり、この装置プラットフォーム依存型の中間表現は、プラットフォーム特定のプレゼンテーション方式における特定のある異種装置プラットフォーム(ターゲット装置プラットフォーム)に対するカスタマイズを示すために「装置依存型中間表現」として図１に表されている。
【００４３】レンダーマネージャモジュール１６は、ターゲット装置プラットフォームの表示画面上にプレゼンテーションを表示するようにしてもよい。レンダーマネージャモジュール１６は、カスタマイズモジュール１４による中間表現のカスタマイズを行う。レンダーマネージャモジュール１６は、装置プラットフォーム依存型の中間表現から、プレゼンテーションを取り出してもよい。さらにレンダーマネージャモジュール１６は、ターゲット装置プラットフォームの表示画面上にプレゼンテーションを表示するために、拡張性のあるGUIライブラリモジュール１２を利用してもよい。
【００４４】レンダーマネージャモジュール１６の動作は、プレゼンテーションを取り出すため、装置プラットフォーム依存型の中間表現をトラバースすることを含む。装置プラットフォーム依存型の中間表現は、ターゲット装置プラットフォームに依存している装置プラットフォーム用にカスタマイズされたアプリケーションGUIの符号化表示である。このように、レンダーマネージャモジュール１６により取り出されたプレゼンテーションは、ターゲット装置プラットフォームの表示画面上に写っている装置依存型のアプリケーションGUIを表示する。
【００４５】SGUIシステム１０の好ましい実施形態において、SGUIシステム１０は、ターゲット装置プラットフォームに対しアプリケーションGUIの継ぎ目のないスケーリングを提供するため、拡張性のあるアプリケーションと連動して動いてもよい。アプリケーション開発者は、アプリケーションGUIから装置プラットフォーム独立型の中間表現を作るためのツールとして、拡張性のあるGUIライブラリモジュール１２を使うことができる。図１に示すように、SGUIシステム１０の稼動中、アプリケーションGUIは、拡張性のあるGUIライブラリモジュール１２を使う装置プラットフォーム独立型の中間表現をインスタンス化してもよい。カスタマイズモジュール１４は、拡張性のあるアプリケーションが動いているターゲット装置プラットフォームに基づく装置プラットフォーム依存型の中間表現に対し、中間表現をカスタマイズしてもよい。レンダーマネージャモジュール１６は、ターゲット装置プラットフォームのユーザインターフェイス用にカスタマイズされたプレゼンテーションを取り出すため、装置プラットフォーム依存型の中間表現を使用してもよい。そしてプレゼンテーションは、レンダーマネージャモジュール１６により、ターゲット装置プラットフォームの表示画面上に表示されてもよい。
【００４６】図１に表されているモジュールのより細かな詳細について説明する。
【００４７】図２は、拡張性のあるGUIライブラリモジュール１２の１実施形態のより詳細なブロック図である。ある実施形態の拡張性のあるGUIライブラリモジュール１２は、拡張性のあるGUIコンポーネントライブラリモジュール２２、中間表現モジュール２４（IR）、そして拡張性のあるGUIイベント変換モジュール２６を有している。他の実施形態において、これより少ないまたは多いモジュールにより、拡張性のあるGUIライブラリモジュール１２の機能を表してもよい。拡張性のあるGUIコンポーネントライブラリモジュール２２は、有名なGUIコンポーネントライブラリに共通している点がいくつかある。GUIコンポーネントライブラリモジュール２２のある実施形態において、GUIコンポーネントライブラリモジュール２２は、複数の拡張性のあるグラフィックユーザインターフェイス(SGUI)コンポーネントと装置プラットフォーム独立型のAPIを有している。既に述べたように、装置プラットフォーム独立型のAPIは、異種装置プラットフォームと適合性があり、そして装置独立型のアプリケーションGUIを作るために利用できる。
【００４８】SGUIコンポーネントは、ライブラリ内におけるグラフィカルユーザインターフェイスコンポーネントである。SGUIコンポーネントは、SGUIシステムで動作可能な異種装置プラットフォームによりサポートされる装置独立型のグラフィカルユーザインターフェイスコンポーネントとして描かれている。さらにSGUIコンポーネントは、グラフィカルユーザインターフェイスコンポーネントが、異種装置プラットフォーム用にカスタマイズ可能なことを表すために用いられてもよい。またSGUIコンポーネントは、SGUIコンポーネント複合として言及されてもよい。ここでSGUIコンポーネント複合は、関連のある機能を提供するためにグループ化された複数のSGUIコンポーネント単体である。
【００４９】装置独立型のアプリケーションGUIは、SGUIコンポーネントの表示を含む装置独立型の中間表現のインスタンスを作るのに使われてもよい。しかしながらディスプレイ用のプレゼンテーションを作る前に、中間表現は、装置プラットフォーム依存型の中間表現が表示可能になるように、変換（またはカスタマイズ）されてもよい。
【００５０】好ましい実施形態において、GUIコンポーネントライブラリモジュール２２は、Java（登録商標） SWINGに似ている。これにより、Java（登録商標）スイングに明るいアプリケーション開発者は、拡張性のあるGUIコンポーネントライブラリモジュール２２を容易に学ぶことができる。ある実施形態において、Java（登録商標）スイングとSGUIコンポーネントの類似点は、共に接頭辞がSだということである。つまり、この実施形態でJava（登録商標）SWINGの接頭辞は、Java（登録商標）SWINGのJではなく、Sなのである。
【００５１】一般的に、クロスプラットフォームGUIライブラリを作るために、４つの有名な技術がある。それら４つの技術とは「Least Common Denominator (LCD)」,「Superset Emulation」,「 Direct API Emulation」and 「Layering/Wrapper」である。LCD技術は、全てのGUIライブラリに共通の特徴を持っている。Superset Emulation技術は、全てのGUIライブラリ用のGUIコンポーネントのスーパーセットを提供できる。ダイレクトAPIエミュレーションの技術は、直接的に、あるGUIライブラリの装置特定型APIを別のGUIライブラリの装置特定型APIへマッピングできる。レイヤリング/ラッパー技術は、GUIライブラリへマッピングする、アブストラクトなGUIライブラリを提供する。
【００５２】SGUIシステムのある実施形態において、ダイレクトAPIエミュレーションとラッパー技術のコンビネーションが実装される。他の実施形態において、他の技術との組み合わせが使われてもよい。しかしながら、LCD技術の利用は、SGUIコンポーネントの利用を制限することもある。さらに、SGUIシステムがサポートするGUIライブラリの数が増えた時、スーパーセットエミュレーションの利用は、拡張性を制限することもある。
【００５３】ダイレクトAPIエミュレーションとラッパー技術の組み合わせが、拡張性のあるGUIコンポーネントライブラリモジュール２２により実装されてもよい。拡張性のあるGUIコンポーネントライブラリモジュール２２は、他のGUIライブラリへマッピングされてもよい。ある実施形態において、拡張性のあるGUIコンポーネントライブラリモジュール２２は、装置特定のGUIライブラリへマッピングされてもよい。装置特定のGUIライブラリは、例えば、Java（登録商標）スイング、Java（登録商標）AWT、及び/またはJava（登録商標）Dojaを有していてもよい。他の実施形態において、拡張性のあるGUIコンポーネントライブラリモジュール２２は、非装置特定のライブラリを有している増設された/異なるライブラリへマッピングされてもよい。
【００５４】拡張性のあるGUIコンポーネントライブラリモジュール２２内でのマッピングにおいて、SGUIコンポーネントを、他のライブラリ内にある装置特定のGUIコンポーネントへマッピングする。このマッピングは、対応する装置特定のGUIコンポーネントが装置特定のGUIライブラリ内において利用可能な場所で実行されてもよい。もし装置特定のGUIライブラリが利用できないとき、SGUIコンポーネントは、装置特定のGUIライブラリ内において、装置特定のGUIコンポーネント複合へマッピングされてもよい。ある実施形態において、マッピングは定着してない。したがって、この実施形態において、アプリケーション開発者は、拡張性のあるGUIコンポーネントライブラリモジュール２２内においてSGUIコンポーネントのマッピングを変えたり/加えたりすることにより、デフォルトマッピングを無視してもよい。
【００５５】再び図２に戻るが、中間表現(IR)モジュール２４は、中間表現を作るためにアプリケーションGUIが使用する装置独立型APIを有している、いかなるアプリケーションでもよい。中間表現は、拡張性のあるGUIコンポーネントライブラリモジュール２２を利用する装置独立型アプリケーションGUIを表している。好ましい実施形態において、中間表現は木構造のような構造を有しているので、だから中間表現は中間表現(IR)ツリー(木)と呼ばれてもよい。他の実施形態において、例えば、アウトライン構造、マトリックス構造、または他の論理ベースの構造を、中間表現を表すために用いてもよい。
【００５６】IRツリーは、SGUIコンポーネントが配置されているかもしれない論理構造を提供する。SGUIコンポーネントは、IRツリー内の簡単な中間表現内に装置プラットフォーム独立型のアプリケーションGUIを入れることにより、配置されてもよい。アプリケーションGUIは装置プラットフォーム独立型なので、IRツリーは拡張性のあるアプリケーションによりサポートされる、すべての可能なSGUIコンポーネントを含んでいてもよい。SGUIコンポーネントは、装置プラットフォーム独立型のプレゼンテーションへ簡単な変換を提供するように配置されてもよい。さらに詳細は後で述べるが、レイアウト構造、レイアウトの制約、そして制約を示すその他のプロパティは、IRツリーの論理構造内において特定されてもよい。さらに、IRツリーは、Java（登録商標）のアプリケーションGUI開発との類似を永続させるため、Java（登録商標）技術の階層的なコンテナ概念を取り入れることが望ましい。
【００５７】図３は、IRツリー４０の構成例を示すブロック図である。IRツリー４０は、階層型構造内にある相互に連結した複数のノードを持っている。図の階層構造は、数ある構造の中における１つの例に過ぎない。好ましい実施形態において、IRツリー４０は、少なくとも１つのコンポーネントノード４２と１つのコンテナノード４４を持っている。他の実施形態において、その他のカテゴリーを持つノードが、アプリケーションGUIを表すように特定されてもよい。
【００５８】ある実施形態のコンポーネントノード４２は、個々のSGUIコンポーネントを表している。コンポーネントノード４２より下の位置には他のノードがこれ以上無いので、コンポーネントノード４２は、IRツリー４０の「葉」と見なしてもよい。ある実施形態のコンテナノード４４は、IRツリー４０内における論理パネルを表している。論理パネルは、装置プラットフォームの表示画面に表示するためIRツリー４０から作られたプレゼンテーションのページ内で、異なるセクション、または異なるパネルを表している。例えば、Eメールに関するアプリケーション内において、コンテナノード４４は、ユーザが受け取った全てのEメールを表示するウインドウを表すことができる。
【００５９】図に示す通り、コンテナノード４４は、下位の位置に自身と連結しているコンポーネントノード４２、及び/または他のコンテナノード４４を持っていてもよい。IRツリー４０の下位に位置しているノードは、上位の関連論理パネルにより表されるセクションの一部またはパネルである、関連サブ論理パネル及び関連SGUIコンポーネントを表している。例えば、Eメールを表示するウインドウにおいて、下位にあるコンテナノード４４は、ウインドウ内で記述的なヘッダーを提供してもよいし、そして接続先のコンポーネントノード４２は、受信したメールを分類する機能を提供してもよい。
【００６０】図３のIRツリー４０における例で、最も高い位置にあるルートコンテナノード４４ａは、全体的なプレゼンテーションを表してもよい。その他のコンテナノード４４は、プレゼンテーション内で異なる論理パネルを表しているので、ルートコンテナノード４４ａの階層的な子供と考えてよい。コンテナノード４４ｃ、４４ｄ、４４ｅ、４４ｇ、そして４４ｈは、ルートコンテナノード４４ａの一番下位のコンテナノードであると言える。逆に言えば、コンテナノード４４ｂ、４４ｃ、４４ｄは、ルートコンテナノード４４ａの直系の階層的な子供である。さらに図にあるように、いくつかのコンテナノード４４の階層的な子供達はコンポーネントノード４２である。例えば、コンテナノード４４ｃ、４４ｄの子供は、それぞれコンポーネントノード４２ｇ、４２ｈとコンポーネントノード４２ｊ、４２ｋである。
【００６１】またIRツリー４０は、拡張性のあるアプリケーションのタスク構造でもよい。タスク構造は、拡張性のあるアプリケーションが実行するタスクに関連するSGUIコンポーネントをグループ化することにより、表示されてもよい。タスクという言葉は、装置プラットフォームのユーザが、拡張性のあるアプリケーションで実行できる機能を特定している。機能は、拡張性のあるアプリケーションと装置プラットフォームに依存している。例えば、無線電話機(装置プラットフォーム)におけるEメール機能(拡張性のあるアプリケーション)は、タッチスクリーンを使いながらEメールを見ること、削除すること、そして作成することができる機能を有している。したがって、ユーザの指示を示し、かつ受け入れるSGUIコンポーネントは、機能別にグループ化される。
【００６２】タスク構造は、特定のタスク(機能)に関するSGUIコンポーネント(コンポーネントノード４２)を、論理パネル(コンテナノード４４)内にグループ化する。コンテナノード４４内によるグルーピングにより、装置プラットフォームのディスプレイ上におけるSGUIコンポーネントの対応するグループが表すタスクを表示することができる。例えば、図３において、タスク４６はコンテナノード４４ｅ、そしてその階層的な子供であるコンポーネントノード４２ａと４２ｂである。一方、タスクは、複数のコンテナノード４４と、それに対応するコンポーネントノード４２である。
【００６３】ある実施形態において、SGUIコンポーネントのグルーピングにより、アプリケーションGUIがタスクの優先度を示している制約を提供するためのプロパティを特定する。プロパティは、対応するコンテナノード４４に対し、タスクの優先順位を添付してもよい。例えば、タスクの優先順位は、特定の装置プラットフォームに適しているタスクを特定しても良いし、異種装置プラットフォームにおける別のタスクを特定しても良いし、及び/または、タスク及び/または拡張性のあるアプリケーションが動いている装置プラットフォームに関連する情報を特定しても良い。
【００６４】既に述べたように、アプリケーション開発者は、その開発中に、拡張性のあるアプリケーション内で、IRツリー４０を作ってもよい。コンテナノードとコンポーネントノードの階層構造を特定する他に、アプリケーション開発者は、IRツリー４０の論理構造、及び/またはIRツリー４０のレイアウトパラメータに影響する制約を提供するプロパティを特定してもよい。プロパティは、コンポーネントノード４２(SGUIコンポーネント)、コンテナノード４４(論理パネル)、及び/またはIRツリー４０に対し、特定されてもよい。IRツリー４０のインスタンスは、特定のプロパティを含んでもよいし、また特定のプロパティベースで作られてもよい。好ましい実施形態において、プロパティの特定化は、アプリケーションGUI内において起こってもよい。また他の実施形態において、プロパティの特定化は、ターゲット装置プラットフォーム内、または他の関連ある装置またはアプリケーション内の拡張性のあるアプリケーションにおいて起こり得る。
【００６５】IRツリー４０は、プレゼンテーションのページ内(プレゼンテーション部)において、アプリケーションGUIのレイアウトを表してもよい。ある実施形態において、IRツリー４０内の相互関連のパターンによりレイアウトストラクチャは、直系の階層的子供ノードにより、高い水準の論理パネル用に特定されてもよい。アプリケーション開発者は、アプリケーションGUIで、コンポーネントノード４２とコンテナノード４４用のレイアウト構造を示しているプロパティを特定してもよい。プロパティは、論理パネル(コンテナノード４４)とコンテナノード４４の階層的な子供であるSGUIコンポーネント(コンポーネントノード４２)の位置を特定してもよい。例えば、コンポーネントノード４２ａにおけるレイアウト構造は、コンテナノード４４ｅが表す論理パネルの右上において、SGUIコンポーネントの位置を特定してもよい。同様に、コンポーネントノード４２ｂは、コンテナノード４４ｅが表す論理パネルの左上において、対応するSGUIコンポーネントの位置を示しているレイアウト構造を含んでいてもよい。コンテナノード４４ｅも、コンテナノード４４ｂにより表される論理パネルのセンターにおいて、対応する論理パネルの位置を特定するレイアウト構造を含んでいてもよい。
【００６６】さらに、図３のIRツリー４０の例において、プレゼンテーションのページ４８は、コンテナノード４４とコンポーネントノード４２の階層的に関連のあるグループから形成されていてもよい。図の例において、ページ４８はコンテナノード４４ｂで形成されている。ページ４８は、コンテナノード４４ｂ以下の関連のある階層レベルが課したレイアウト構造に起因してもよい。具体的に説明すると、４４ｆ内におけるコンテナノード４４ｇ、４４ｈ、そして４４ｂ内における４４ｅ、４４ｆの特定化と同様に、対応するコンテナノード４４ｅ、４４ｇ、４４ｈ内におけるコンポーネントノード４２ａ、４２ｂ、４２ｃ、４２ｄ、４２ｅ、４２ｆのレイアウト構造を特定するプロパティが、ページ４８を作ることもできる。他の実施形態において、他のレイアウト構造の特定化に関連するIRツリー４０における他のノードの階層構造は、ページのフォーメーション(形成)に起因してもよい。
【００６７】ターゲット装置プラットフォーム用のプレゼンテーションのページの生成時、SGUIシステムは、提案されているレイアウト構造に従ってもよい。しかしながら、ある実施形態において、例えば、ターゲット装置プラットフォームの表示画面を最大限に利用することに高い優先順位が設定されている場合において、提案されたレイアウト構造に従うことを無視してもよい。
【００６８】IRツリー４０の装置独立型プラットフォームが有する性質のせいで、アプリケーションGUIが生成されたときに、異種装置プラットフォーム内における多様な機能は、レイアウト構造の特定化を難しくする。例えば、許容されるページの最大のサイズは、ターゲット装置プラットフォームの表示画面のサイズに依存しており、開発時間を特定するのは難しい。さらに、開発時間においては、SGUIコンポーネントの実際サイズはわからない。SGUIコンポーネントは、ターゲット装置プラットフォームの機能に基づき、多種あるサイズの中から１つのSGUIコンポーネントに変換するので、SGUIコンポーネントの実際サイズはわからない。
【００６９】ある実施形態において、アプリケーション開発者は、プレゼンテーション内において配置されたSGUIコンポーネントに関するSGUIコンポーネントのサイズを予測することは可能である。仮に、その予測が正確(SGUIコンポーネントの変換後のサイズに近い)なら、ターゲット装置プラットフォームの表示画面内のレイアウトにおけるSGUコンポーネント間の大きな「穴」は、避けることができる。また別の実施形態において、SGUIシステムは、いわゆる「穴」を避けるために、同じコンテナノード４４(論理パネル)内で、SGUIコンポーネントに似たサイズを保存するように努める。また他の実施形態において、自動レイアウト生成のためのフォーム、ターゲット装置プラットフォーム用レイアウトのアプリケーション開発者によるカスタマイズ、及び/またはSGUIコンポーネントのサイズの多様性を指定するための技術により、多様なレイアウト構造は指定される。
【００７０】タスクの優先順位とレイアウト構造を示すプロパティの特定化に加えて、アプリケーション開発者は、IRツリー４０の論理構造、及び/またはIRツリー４０のレイアウトパラメータに影響する制約を提供するプロパティを特定してもよい。ある実施形態において、コンテナノード４４のレイアウト優先順位に関連しているプロパティが特定される。本実施形態のプロパティは、コンテナノード４４がページ上に配置されるオーダを特定する。最も高いレイアウト優先順位のコンテナノード４４は、表示画面内で最初のページに位置し、かつ対応するコンポーネントノード４２により特定されるSGUIコンポーネントを保持してもよい。例えば、装置プラットフォームのユーザのために、あるタスクを易しくしたいというアプリケーション開発者は、対応するパネル(コンテナノード４４)に、高いレイアウト優先順位を設定する。
【００７１】他の実施形態において、レイアウトの制約を特定するプロパティは、コンポーネントノード４２に含まれてもよい。レイアウトの制約は、同ページに互いに隣接して配置される２つまたはそれ以上のSGUIコンポーネントを条件として指定してもよい。例えば、イエスを示している選択可能なボタンとノーを示している選択可能なボタンは、ボタンが隣接していることを条件として指定するレイアウトの制約を含んでもよい。
【００７２】同様に他の実施形態で、プロパティは、コンテナノード４４内のレイアウトグループを特定してもよい。レイアウトグループは、コンテナノード４４内のノードが、レイアウト構造内で別ページに配置されるかどうかを条件として指定することもできる。ある実施形態において、直系の階層的な子供としてコンポーネントノード４２を持っている全てのコンテナノード４４は、レイアウトグループに特定されない限り分割できない。同様に、直系の階層的な子供としてコンポーネントノード４２を持っていない本実施形態の全てのコンテナノード４４は分割可能である。
【００７３】別の実施形態において、プロパティはコンテナノード４４のラベルを特定できる機能を持っている。ラベルは、論理パネルに対応付けられてもよいし、ページ間を移動するプレゼンテーション内において、ナビゲーションバー/またはメニューを作成してもよい。他の実施形態においてプロパティは、他の仕様や、論理コンディション、及び/またはコンポーネントノード４２、コンテナノード４４及び/またはIRツリー４０に関連する付加機能を特定するのに利用されてもよい。
【００７４】再び図２に戻り、拡張性のあるGUIイベント変換モジュール２６は、ターゲット装置プラットフォームのユーザインターフェイスにより生成されるGUIイベントを変換する技術(方法)であってもよい。ある実施形態において、拡張性のあるGUIイベント変換モジュール２６は、装置独立型のGUIイベントAPIを持っている。装置独立型のGUIイベントAPIは、拡張性のあるアプリケーションに対するイベントを処理する。前にも述べたがGUIイベントは、表示画面上のSGUIコンポーネント内の状態の変化を表しているが、これはユーザが対応する装置プラットフォームに関連しているユーザインターフェイスと対話するためである。
【００７５】先行技術では、GUIイベントは、装置特定型アプリケーションGUIアプリケーションプログラムインターフェイス(API)により定義されている。装置特定型GUI APIは、GUIイベントを生成する、特定装置の入出力方法に接続されているGUIイベントを定義する。拡張性のあるGUIイベント変換モジュール２６は、異種装置プラットフォーム用のGUIイベントを変換するのに使われる。また拡張性のあるGUIイベント変換モジュール２６は、異なる複数の入力方法で動作が可能な装置独立型のGUIイベント変換機を有している。
【００７６】ある実施形態において、GUIイベント変換機は、アクションと呼ばれる抽象的なイベントを定義する。アクションは入力方法から独立している。例えば、ボタンとして動作するGUIコンポーネントに対応付けられたアクションは、装置プラットフォームに依存しているラップトップコンピュータのマウスクリック、ポケットコンピュータのスタイラス・タップ、または携帯電話のソフトキーから生成されてもよい。拡張性のあるアプリケーションは、GUIイベント変換機のGUIイベントを表すアクションにより提供されてもよい。このように、GUIイベントを生成する入力方法は、拡張性のあるアプリケーションに対し、無関係なものであってもよい。
【００７７】拡張性のあるGUIイベント変換モジュール２６は、プラットフォーム独立型のアクションの拡張性のあるユーザインターフェイスライブラリを持っている。拡張性のあるユーザインターフェイスライブラリは、拡張性のあるGUIコンポーネントライブラリ２２、または異なるライブラリに含まれていてもよい。ある実施形態において、拡張性のあるGUIイベント変換モジュール２６は、装置プラットフォーム独立型のGUIイベントAPIに基づいた論理マッピングを含んでいてもよい。拡張性のあるアプリケーションの開発者は、装置プラットフォーム特定型のGUIイベントと同等のプラットフォーム独立型のアクションの間で、論理マッピング用の装置プラットフォーム独立型のAPIを利用してもよい。このようにプラットフォーム独立型のアクションは、対応する装置プラットフォーム特定型のGUIイベントの結果として、拡張性のあるアプリケーションへと配信されてもよい。
【００７８】いくつかの拡張性のあるアプリケーションにおいて、装置プラットフォームの制約のために、プラットフォーム特定型のGUIイベントとプラットフォーム独立型のアクション間におけるマッピングは不可能かもしれない。例えば、ユーザがマップ・イメージにおける特定のポイントをクリックするとき、拡張性のあるアプリケーションは、拡大または縮小できるインターラクティブマップを有していてもよい。パソコンサイドでは、装置プラットフォーム特定型のマウスイベントは、マウスがクリックされた特定の位置を把握する。しかしながら、無線電話において、ユーザインターフェイスとして位置決め入力装置は含まれなくてもよい。このように、無線電話における同等のプラットフォーム独立型のアクションは、マップされることはない。この場合、拡張性のあるGUIイベント変換モジュール２６のライブラリは、別段の定めがなければプラットフォーム独立型アクションが表す、プラットフォーム特定入力方法用の装置プラットフォーム依存型アクションを有していてもよい。これに伴い、アプリケーションGUIは、制約を伴うターゲット装置プラットフォーム用のアプリケーションGUIをカスタマイズするプロパティを持っていてもよい。ある実施形態において、一般的に装置プラットフォーム特定型GUIイベントは拡張性がないため、拡張性のあるアプリケーションの主要な機能を実装するのに装置プラットフォーム独立型のアクションを用いなくてもよい。本実施形態において、装置プラットフォーム依存型のアクションは、主要な機能に対する付加拡張機能として用いられてもよい。
【００７９】図４は、変換マネージャモジュール２０のより詳細なブロック図における１つの実施形態である。変換マネージャモジュール２０は、変換ルールモジュール５０、サイズ変換コンポーネントモジュール５２、代替コンポーネントモジュール５４、GUI変換ルールモジュール単体５６、GUI変換ルールモジュール複合５８、ダイナミックレイアウトモジュール６０、スタイルガイドモジュール６２とSGUIコンポーネントリストモジュール６４から成っている。他の実施形態において、変換マネージャモジュール２０内での機能は、本実施形態で使用されているモジュールより少ない、または多い数のモジュールで表される。
【００８０】変換ルールモジュール５０は、IRツリーを動的に作るために、拡張性のあるGUIコンポーネントライブラリモジュール２２(図２)を利用してもよい。IRツリーの構造は、対応するプレゼンテーションのページにあるIRツリー内に表されるSGUIコンポーネントと、変換ルールで選択的に変換するSGUIコンポーネントから成っている。
【００８１】変換ルールモジュール５０は、IRツリー４０(図３)におけるSGUIコンポーネントを変換するのに使われる複数の変換ルールから成っている。ある実施形態において、変換ルールモジュール５０は、変換ルールの２つのカテゴリを表しているサイズ変換コンポーネントモジュール５２と、代替コンポーネントモジュール５４から成っている。サイズ変換コンポーネントモジュール５２は、ターゲット装置プラットフォームの表示画面のサイズをベースにSGUIコンポーネントのサイズを調整するルールを提供できる。代替コンポーネントモジュール５４は、IRツリー内におけるアプリケーションGUIを表すSGUIコンポーネントと置き換えに、代替のSGUIコンポーネントを特定できる。
【００８２】ある実施形態の代替コンポーネントモジュール５４は、代替のSGUIコンポーネントに対する２つのカテゴリのルールを表しているGUI変換ルールモジュール単体５６と、GUI変換ルールモジュール複合５８から成っている。GUI変換ルールモジュール単体５６は、SGUIコンポーネントをターゲット装置プラットフォームに特定するSGUIコンポーネントに変換するルールを提供する。
【００８３】図５は、第１SGUIコンポーネント７０がターゲット装置プラットフォームに特定する第２SGUIコンポーネント７２に、変換ルールで変換する例を示している。ターゲット装置プラットフォームの機能、ターゲット装置プラットフォームのタイプ、ターゲット装置プラットフォームのユーザインターフェイス、拡張性のあるアプリケーションの機能、及び/またはSGUIコンポーネントのディスプレイに関するパラメータをベースに、SGUIコンポーネントはターゲット装置プラットフォームに特定すると考えてよい。
【００８４】図の例では、第１SGUIコンポーネント７０は、ユーザにより選択される「高」、「中」、「低」、いわゆる優先度の選択リストを表している。同様に、第２SGUIコンポーネント７２は、優先度の選択ボタンを表している。仮に、第１SGUIコンポーネント７０とターゲット装置プラットフォーム用のコンポーネントノード４２(図３)を含んでいるIRツリー４０(図３)はPDAだとした場合、GUI変換ルールモジュール単体５６(図４)は、第１SGUIコンポーネント７０を第２SGUIコンポーネント７２に変換する変換ルールを提供してもよい（矢印７４）。
【００８５】PDAの表示画面におけるサイズの限定、PDAで利用可能なユーザインターフェイス、またはPDAや拡張性のあるアプリケーションに関連性のある理由により、本実施例における第２SGUIコンポーネント７２は特定のものと考えられてもよい。この図における例は、SGUIコンポーネントに適用可能な数ある変換ルールの一例にすぎない。
【００８６】図４に再び戻り、GUI変換ルールモジュール複合５８は、SGUIコンポーネント複合が、ターゲット装置プラットフォームに特定するSGUIコンポーネントに変換する変換ルールを提供する。前にも述べた通り、SGUIコンポーネント複合は、IRツリー(図３)におけるコンテナノード４４(図３)および対応するコンポーネントノード４２(図３)により表されてもよい。
【００８７】図６は、第１SGUIコンポーネント複合７６が、ターゲット装置プラットフォームに特定している第２SGUIコンポーネント複合７８へ変換する変換例を示している。
【００８８】図の例によると、第１SGUIコンポーネント複合７６は、複数のデータエントリ８０、優先度セレクション８２、そして好みセレクション８４から成っている。第２SGUIコンポーネント複合７８は、ピックリスト８６と単一のデータエントリ８８から成っている。図５における例と同様、矢印９０で示されているように、第１SGUIコンポーネント複合７６を第２SGUIコンポーネント複合７８に変換するのに、GUI変換ルールモジュール複合５８から利用可能な変換ルールを用いてもよい。
【００８９】図４に戻るが、ダイナミックレイアウトモジュール６０は、装置プラットフォーム依存型のプレゼンテーションを表すIRツリーを構成してもよい。ダイナミックな構成とは、プレゼンテーションのページのIRツリーが表すSGUIコンポーネントの配置と、選択的にSGUIコンポーネントが変換することを含んでいる。ある実施形態において、レイアウト構造やアプリケーションGUIが特定する他の制約に従い、IRツリーにより表されるSGUIコンポーネントがページ上にあってもよい。さらに、ダイナミックレイアウトモジュール６０は、適合性を確認するために、プレゼンテーションとターゲット装置プラットフォームの機能とを比べてもよい。例えば、制約に関する機能は、プレゼンテーションのページサイズでもよい。ダイナミックレイアウトモジュール６０が構成するページのサイズは、プレゼンテーションを表示するターゲット装置プラットフォームの表示画面サイズを超えてはいけない。制約に関する他の機能例は、SGUIコンポーネントの最小の視覚サイズ、またはターゲット装置プラットフォームに関する他の機能である。
【００９０】ダイナミックレイアウトモジュール６０は、変換ルールを選択＆適用する。そしてSGUIコンポーネントを機能あるいは制約に従う形に変換するため、変換ルールモジュール５０から利用可能な変換ルールを適用する。例えば表示画面のサイズの制約を満たすため、ダイナミックレイアウトモジュール６０は、もっとコンパクトなプレゼンテーションを作るために、変換ルールをIRツリー内のSGUIコンポーネントに適用してもよい。変換ルールの選択は、拡張性のあるアプリケーション、ターゲット装置プラットフォームの表示画面サイズ、装置プラットフォームのユーザインターフェイス機能、及び/またはディスプレイ、及びターゲット装置プラットフォームとの相互作用に関するパラメータにより、決められてもよい。
【００９１】ある実施形態において、ダイナミックレイアウトモジュール６０は、その機能や制約をベースにプレゼンテーション用のページを生成してもよい。また別の実施形態において、変換ルールの適用により、ターゲット装置プラットフォームに特定する様々な構成のページセットが生成される。ページセットとは、予想される装置プラットフォーム依存型プレゼンテーションの一部分である。予想されるプレゼンテーション内で開発されたページをベースに、ダイナミックレイアウトモジュール６０は、最も望ましい装置プラットフォーム依存型のプレゼンテーションを得るために、ページセット内から選択的にページを利用してもよい。ダイナミックレイアウトモジュール６０の望ましい機能とは、ページ数の最少化、アプリケーションGUIが特定するプロパティに従うこと、それぞれのページ用の表示画面を最大に利用すること、及び/またはプレゼンテーション、ターゲット装置プラットフォーム及び/または拡張性のあるアプリケーションに関連しているその他の特徴である。
【００９２】さらに図４に示されているように、本実施形態のダイナミックレイアウトモジュール６０は、スタイルガイドモジュール６２とSGUIコンポーネントリストモジュール６４から成り立っている。また他の実施形態において、少ないまたは多い数のモジュールが、機能を表すため、ダイナミックレイアウトモジュール６０内で特定されてもよい。
【００９３】スタイルガイドモジュール６２は、少なくとも１つのプリケーション用のスタイルガイドパラメータセットをSGUIコンポーネントに提供してもよい。スタイルガイドパラメータは、プレゼンテーション内において変わらない外観を提供するため、SGUIコンポーネントの視覚的な外観を標準化してもよい。典型的なスタイルガイドパラメータは、フォントサイズ、コンポネント間におけるスペース、色彩などから成っている。ある実施形態において、スタイルガイドパラメータの1セットは、全ての装置プラットフォームに使われている。また別の実施形態において、スタイルガイドパラメータのセットは、１つまたはそれ以上のターゲット装置プラットフォームに対応付けられていてもよい。
【００９４】SGUIコンポーネントリストモジュール６４は、予想されるSGUIコンポーネントのリストを編集する。予想されるSGUIコンポーネントのリストは、IRツリー内にあるSGUIコンポーネントの変換から生じるSGUIコンポーネントを表してもよい。ダイナミックレイアウトモジュール６０は、リスト作成のため、変換ルールをIRツリー内にあるSGUIコンポーネントに適用してもよい。ある実施形態において、SGUIコンポーネントリストモジュール６４が、リスト内のSGUIコンポーネントのサイズに応じて、SGUIコンポーネントのリストを編集してもよい。
【００９５】ダイナミックレイアウトモジュール６０は、SGUIコンポーネントのリスト作成のため、変換ルールモジュール５０から選択的に適切な変換ルールを適用してもよい。ある実施形態において、適切な変換ルールの選択のために、ダイナミックレイアウトモジュール６０はルールに基づいた技術（方法）を用いてもよい。その技術（方法）においては、２つの前提条件に基づいた選択的な変換ルールが適用可能である。最初の前提条件とは、変換するSGUIコンポーネントの特徴を考慮することである。第２の前提条件とは、プレゼンテーション用のターゲット装置プラットフォームの機能を考慮することである。
【００９６】前提条件に加えて、ある実施形態では、ダイナミックレイアウトモジュール６０のランキングから、適切な変換ルールを選択してもよい。変換ルールのランキングは、変換ルールを適用した結果に基づいてもよい。例えばどのくらいの確率で変換ルールが、異なる拡張性のあるアプリケーション用に適正な変換を実現するかということに基づき、ランキングが決まるということである。よって、かつ高い確率で変換が成功する変換ルールはランキングが高く、逆にある特定の拡張性のあるアプリケーション用にしか特定されていない変換ルールはランキングが低い。例えば、(少ない数の選択可能なアイテムにおける)選択ボタン(図５参照)に対する選択リストの変換は、世界的な規模で拡張性のあるアプリケーションにおいて適用可能なので、高いランキングが指定されてもよい。
【００９７】SGUIコンポーネントリストの生成に続いて、ダイナミックレイアウトモジュール６０は、プレゼンテーションにおける使用目的でリストからSGUIコンポーネントを選択してもよい。ある実施形態において、最大サイズの表示画面に基づき、SGUIコンポーネントが選択される。また他の実施形態において、ターゲット装置プラットフォームの機能や拡張性のあるアプリケーションの機能、及び/またはその他条件が、選択過程において用いられてもよい。SGUIコンポーネントはリストから選択され、プレゼンテーションを表すページ上に配置されてもよい。リストから選択されたSGUIコンポーネントは、リストを作るのに用いられたSGUIコンポーネントを置き換えてもよい。SGUIコンポーネントの置き換えにより、装置プラットフォーム独立型のSGUIコンポーネントは、効果的にターゲット装置プラットフォームに特定するSGUIコンポーネントに変換される。
【００９８】ある実施形態において、各々のページは、表示画面の最大のサイズと比較されてもよい。この実施形態において、ページを構成するSGUIコンポーネントを縮小するか、または拡大する必要性があるかどうかにより、ダイナミックレイアウトモジュール６０は、リストから大きな、または小さなサイズのSGUIコンポーネントを選択してもよい。ある実施形態において、SGUIコンポーネントに対応するリスト内に、似たサイズのSGUIコンポーネントがある場合におけるSGUIコンポーネントの選択は、リスト内でSGUIコンポーネントを作るのに用いられる変換ルール(既に紹介済み)のランキングに基づいてもよい。
【００９９】本発明の好ましい実施形態において、ダイナミックレイアウトモジュール６０は、プレゼンテーションに対応しているページを作るために、IRツリーを通して繰り返し処理を行ってもよい。ある実施形態において、ダイナミックレイアウトモジュール６０によるプロセスは、IRツリーの最も低い階層レベルから高いレベルに向けて処理を行う。ページを満たすために、ダイナミックレイアウトモジュール６０は、論理パネルをプレゼンテーションのページに付け加えてもよい。ページが満たされてないときは、兄弟ノードあるいは高いレベルにあるノードからの階層的に関連のある論理パネルが、ページに付け加えられてもよい。例えば、図３によれば、コンテナノード４４ｈ、４４ｆ、そして４４ｅが、ページ４８を作るために、コンテナノード４４ｇに付け加えられてもよい。これとは逆にページがはみ出したときは、表示画面のサイズに合わせるために、ページ内においてSGUIコンポーネントの変換を実行してもよい。
【０１００】ページがおおむね満たされたとき、プレゼンテーション用の新しいページが作られる。おおむね満たされたページとは、利用可能なSGUIコンポーネントで、ターゲット装置プラットフォームの表示画面を最大化することである。ある実施形態において、おおむね満たされたページとは、およそ９５％から１００％の割合で、ターゲット装置プラットフォームの表示画面を満たしていることである。レイアウト構造、他の条件として指定されてる制約、及び/またはSGUIコンポーネントは表示画面が完全に満たされることを防ぐが、おおむね満たされたページ内では、現条件のもとで満たされている部分を最大限に活用する。
【０１０１】図７は、図３のIRツリー４０を参照しながら、図４の変換マネージャモジュール２０のある実施形態の動作を示しているブロック図である。変換マネージャモジュール２０の動作がブロック１００で始まる。変換マネージャモジュール２０は、好ましくは、以下においてIRツリー４０をインスタンス化し、そして取り除くことにより発生する。IRツリー４０において、最も高いレイアウト優先度を持ち、かつ最も低いレベルにあるコンテナノード４４が特定される。(ブロック１０２)低いレベルにあるコンテナノードは、SGUIコンポーネント(コンポーネントノード４２)を表す階層的な子供ノードである。図３におけるIRツリー４０の例では、コンテナノード４４ｃ、４４ｄ、４４ｅ、４４ｇ、そして４４ｈが、最も低いレベルにあるコンテナノードである。レイアウトの優先度は、アプリケーションGUIのプロパティにより特定される。ここでは動作を説明する目的上、図３のコンテナノード４４ｇが、最も高いレイアウト優先度を持っているとする。
【０１０２】スタイルガイドモジュール６２は、特定のコンテナノード４４(コンテナノード４４ｇ)に関連しているSGUIコンポーネント(コンポーネントノード４２ｃと４２ｄ)に対し、ターゲット装置プラットフォームに対応するスタイルガイドパラメータセットを適用する。（ブロック１０４）SGUIコンポーネントは、IRツリー４０のレイアウト構造とアプリケーションGUIに条件として指定される制約に従い、プレゼンテーションのページ上に配置される。(ブロック１０６)そして、ページのサイズが決定する。（ブロック１０８）その後、表示画面からページのサイズがはみ出したかどうかが決まる。（ブロック１１０）ページのサイズが、ターゲット装置プラットフォームの表示画面のサイズより大きければ、ページはターゲット装置プラットフォームの表示画面からはみ出していることになる。
【０１０３】図８のブロック１１４において、ページがはみ出していたら、適切な変換ルールが選択され、ダイナミックレイアウトモジュール６０により、そのルールがSGUIコンポーネントに適用される。予想されるSGUIコンポーネントのリストが作成され、サイズに従いながらSGUIコンポーネントリストモジュール６４と共に編集される。(ブロック１１６)例えば、サイズ縮小の必要がある等の条件をベースにしたリストから、SGUIコンポーネントは特定される。(ブロック１１８)そして、リスト内にある１つ以上のSGUIコンポーネントが特定されたかどうかを決定する。(ブロック１２０)もしノーなら、特定されたSGUIコンポーネントが選択される。(ブロック１２２)その後、選択されたSGUIコンポーネントが、ページ(ブロック１０６)内で以前に表示された対応するSGUIコンポーネントと交換され(ブロック１２４)、動作は図７のブロック１０４に戻る。もし複数のSGUIコンポーネントが特定されたら、最も高いランクの変換ルールから作られたSGUIコンポーネントが選択され(ブロック１２５)、動作はブロック１２４に進む。
【０１０４】図９に戻り、ブロック１１０(図７)においてページがはみ出していない場合、ページが満たされていないことが決定される。（図９：ブロック１２６）ページのサイズがターゲット装置プラットフォームの表示画面のサイズより小さい時、ページは満たされていないという事になる。もしページが満たされないと決定した時、まだページ上に配置されていない兄弟ノード(図３のコンテナノード４４ｈ)の特定作業が行われる。(ブロック１２８)もし兄弟ノードが配置されていない場合、最も高い優先度を持つ特定された兄弟ノードが選択され(ブロック１４４)、そして選択されたノードの処理を始めるため、動作は図７のブロック１０４に戻る。もし兄弟ノードが既に配置されているなら（または存在しないなら）、次に高い階層レベル(図３のコンテナノード４４ｆ)からの関連ノードが特定される。(ブロック１３０)【０１０５】ルートコンテナノード(コンテナノード４４ａ)かどうかを判断するのに、次に高い階層レベルからのノードが確認される。(ブロック１３２)もしイエスなら、まだページ上に置かれていない付加的で最も低いレベルのコンテナノードの有無を調べるためにIRツリーを確認する。(ブロック１３４)もしそのような最も低いレベルのコンテナノードが存在するなら、最も低いレベルにありかつ次に高い優先度を持っている別のコンテナノード４４(図３)を特定するため、動作はブロック１０２(図７)へ戻る。もしそのような最も低いレベルのコンテナノードが存在しないなら動作は終わる。(ブロック１３６)【０１０６】ブロック１３２に戻り、次に高い階層レベルにおけるノード(図３のコンテナノード４４ｆ)がルートコンテナノード(コンテナノード４４ａ)でない場合、ノードがページ内に以前に配置されたかどうかを決める。（ブロック１３８）ノードが以前に配置されていないなら、ノード処理を始めるために、動作はブロック１０４(図７)へ戻る。ノードが以前に配置されているなら、次の高い階層レベルにあるノードの兄弟ノード(図３のコンテナノード４４ｅ)が配置されていないかどうかを判定する。(ブロック１４０)もし兄弟ノードがページ内で既に配置されているなら（または存在しないなら）、動作はブロック１３４へ戻る。兄弟ノードが配置されていないなら、最も高いレイアウト優先度を持っている兄弟ノードが選択され(ブロック１４２)、選択されたノードの処理を始めるため、動作はブロック１０４(図７)へ戻る。
【０１０７】ブロック１２６へ戻り、ページが満たされていないとは言えない場合、ページはおおむね満たされていると見なされる。(ブロック１４６)残りのSGUIコンポーネントを配置するために、新しいページが割り当てられ(ブロック１４８)、動作はブロック１３４へ戻る。
【０１０８】別の実施形態において、ページが満たされたと判断されると、リストからの代替SGUIコンポーネントを用いることにより、同ページにおける付加的な変化の生成のための追加的な動作が実行されてもよい。追加的な動作に続いて、ダイナミックレイアウトモジュール６０は、既に前述した通り、最も望ましい装置プラットフォーム依存型のプレゼンテーションを選択してもよい。
【０１０９】通信システム内におけるSGUIシステムの利用例が説明される。図１０は、装置プラットフォーム２０２、変換サーバ２０４、そしてプラットフォーム２０２、変換サーバ２０４とネットワーク２０８を介して通信しているライブラリサーバ２０６を有している、通信システム２００の実施例を示している。装置プラットフォーム２０２は、既に述べられている異種装置プラットフォームでもよい。変換サーバ２０４およびライブラリサーバ２０６は、ネットワーク２０８内において、サーバ機能を実行するいかなる装置であってもよい。ある実施形態において、動作システムを含む１つまたはそれ以上のサーバコンピュータは、変換サーバ２０４およびライブラリサーバ２０６として動作する。動作システムの例として、Microsoft （登録商標）、Windows NT（登録商標）、UNIX（登録商標）、またはサーバ機能をサポートできる他の動作システムが挙げられる。サーバ２０４、２０６は、データを保存し、データにアクセスする機能や、SGUIシステムの一部分などのアプリケーションを実行する機能を有していてもよい。ネットワーク２０８は、インターネット、公衆または専用イントラネット、イクストラネット、及び/または無線、光フャイバ、及び/または有線通信を介し、データ送信や指令が可能なネットワーク構成の形式などであってもよい。
【０１１０】通信システム２００内において、SGUIシステムは動作可能である。ある実施形態において、拡張性のあるアプリケーション２１０は、装置プラットフォーム２０２上において動作してもよい。さらに、拡張性のあるGUIライブラリモジュール１２とレンダーマネージャモジュール１６は、装置プラットフォーム２０２上において動作してもよい。さらに、この実施形態では、タスクマネージャモジュール１８と変換マネージャモジュール２０は、変換サーバ２０４上のカスタマイズモジュール１４内で動作してもよい。既に前実施形態で説明されている拡張性のあるアプリケーション２１０、拡張性のあるGUIライブラリモジュール１２、カスタマイズモジュール１４、そしてレンダーマネージャモジュール１６は、本実施形態においても同様の働きをする。
【０１１１】他の実施形態において、SGUIシステムにおける異なる機能、及び拡張性のあるアプリケーションは、異種装置プラットフォームとサーバ間において配信されてもよい。例えば、各動作をサポートするのに十分な能力があるところで、SGUIシステムと拡張性のあるアプリケーション２１０は、装置プラットフォーム２０２上を動作可能となる。また別の例において、SGUIシステムと拡張性のあるアプリケーション２１０の一部分は装置プラットフォーム２０２上において動作可能であり、またSGUIシステムと拡張性のあるアプリケーション２１０のその他の部分は、その他の装置プラットフォーム上で動作可能である。また別の例においてSGUIシステムの大部分は、サーバ上またはその他類似の装置上で動作可能であり、そしてSGUIシステムの不可欠な部分だけが、装置プラットフォーム２０２上において動作可能であってもよい。
【０１１２】ある実施形態において、拡張性のあるGUIライブラリモジュール１２における拡張性のあるGUIコンポーネントライブラリ２２全体(図２)は、装置プラットフォーム２０２に保存されてもよい。この実施形態において、変換サーバ２０４は、ネットワーク２０８経由で、拡張性のあるGUIコンポーネントライブラリへアクセスしてもよい。既に説明されているが、変換マネージャモジュール２０は、GUIコンポーネントの変換中に、拡張性のあるGUIコンポーネントライブラリ、へアクセスしてもよい。
【０１１３】別の実施形態において、拡張性のあるGUIコンポーネントライブラリ２２のサブセットと共に、拡張性のあるGUIライブラリモジュール１２の一部分は、装置プラットフォーム２０２に保存されてもよい。拡張性のあるGUIコンポーネントライブラリ２２の保存については、そのサブセットに限られているが、その理由は、例えば、装置プラットフォーム２０２の限られた保存機能、情報検索の増加、及び/または装置プラットフォーム２０２及び/または拡張性のあるアプリケーション２１０の動作に関する理由である。拡張性のあるGUIコンポーネントライブラリ２２のサブセットは、装置プラットフォーム２０２により頻繁に用いられるSGUIコンポーネントを含んでいてもよい。この実施形態では、拡張性のあるGUIコンポーネントライブラリ２２全体(図２)と共に、拡張性のあるGUIライブラリモジュール１２の一部分がライブラリサーバ２０６に保存され、そして必要があれば、装置プラットフォーム２０２によりネットワーク２０８を介してアクセスされる。またカスタマイズモジュール１４は、装置プラットフォーム２０２内の拡張性のあるGUIコンポーネントライブラリ２２のサブセット、及び/またはライブラリサーバ２０６内の拡張性のあるGUIコンポーネントライブラリ２２全体へアクセスしてもよい。別の実施形態において、変換サーバ２０４は、装置プラットフォーム２０２からの、または変換サーバ２０４自身からのアクセスに備え、拡張性のあるGUIコンポーネントライブラリ２２を保存してもよい。
【０１１４】また別の実施形態において、変換サーバ２０４は、GUIライブラリモジュール１２の一部分を持っていてもよい。例えば装置プラットフォーム２０２の制限された処理能力、装置プラットフォーム２０２のリソースを保存する要求、そしてSGUIシステムの動作に関するその他の理由により、GUIライブラリモジュール１２の一部分は、変換サーバ２０４内に保存されてもよい。ある実施形態において、中間表現モジュール２４(図２)の一部分は、変換サーバ２０４に含まれていてもよい。変換サーバ２０４に含まれている中間表現モジュールの一部分は、モバイルコードをベースにしたIRツリーのインスタンスを作るために動作してもよい。この実施形態においてモバイルコードは、拡張性のあるアプリケーション２１０のアプリケーションGUIから、ネットワーク２０８を介して、変換サーバ２０４へ送信されてもよい。中間表現モジュールの一部分は、アプリケーションGUIを表すIRツリーのインスタンスを作るために、モバイルコードを実行してもよい。
【０１１５】図１１は、図１０を参照しながら説明されたSGUIシステムのある実施形態における動作を説明したブロック図である。拡張性のあるアプリケーション２１０がターゲット装置プラットフォーム(装置プラットフォーム２０２)へマイグレーション、またはターゲット装置プラットフォームから起動したとき、動作は始まる（ブロック２５０）。拡張性のあるアプリケーション２１０は、IRツリーのインスタンスがターゲット装置プラットフォーム上において作成されるかどうかを判断する。（ブロック２５２）もしイエスなら、IRツリーのインスタンスを作るために、拡張性のあるアプリケーション２１０内のアプリケーションGUIは、GUIライブラリモジュール１２に関連して利用される。(ブロック２５４)アプリケーションGUIを表しているIRツリーは、変換サーバ２０４に送信されてもよい。(ブロック２５６)もしIRツリーのインスタンスがターゲット装置プラットフォーム上において作成されないなら、モバイルコードが変換サーバ２０４に送信される。(ブロック２５８)アプリケーションGUIを表しているIRツリーのインスタンスを作るために、変換サーバ２０４はモバイルコードを実行する。(ブロック２６０)既に説明済みだが、IRツリーは装置プラットフォーム独立型で、そしてアプリケーションGUIに特定されているプロパティを含んでいる。
【０１１６】ブロック２６４において、ターゲット装置プラットフォームの機能が、変換サーバ２０４に送信される。ターゲット装置プラットフォームの機能として、タスクマネージャモジュール１８は、IRツリーから不必要な論理パネル及び/またはSGUIコンポーネントを削除する。(ブロック２６６)変換マネージャモジュール２０は、タスクマネージャモジュール１８からIRツリーを受け取り、IRツリーの変換を始める。（ブロック２６８）IRツリーの変換は、IRツリーにおいて表されているSGUIコンポーネントの構成を含む。装置プラットフォーム依存型のプレゼンテーションのレイアウトを作るため、IRツリーは変換される。
【０１１７】再び図１２に戻るが、変換の後、装置依存型IRツリーはターゲット装置プラットフォームに送信される。（ブロック２７０）レンダーマネージャモジュール１６は装置依存型IRツリーを通過して、SGUIコンポーネントのインスタンス化を開始する。(ブロック２７２)レンダーマネージャモジュール１６は、SGUIコンポーネントがターゲット装置プラットフォーム内において拡張性のあるGUIコンポーネントライブラリ２２に保存されているかどうかを判断する。(ブロック２７４)もしイエスなら、レンダーマネージャモジュール１６は、装置プラットフォーム２０２の表示画面上に、カスタマイズされたアプリケーションGUIを表示することを指示する。(ブロック２７６)SGUIコンポーネントが、ターゲット装置プラットフォーム２０２内における拡張性のあるGUIコンポーネントライブラリ２２内に保存されていないなら、レンダーマネージャモジュール１６は、ライブラリサーバ２０６から装置プラットフォーム２０２へSGUIコンポーネントを動的にダウンロードする。(ブロック２７８)そして、レンダーマネージャモジュール１６は、装置プラットフォーム２０２の表示画面上に、装置依存型アプリケーションGUIの表示を指示する。(ブロック２７６)【０１１８】GUIのマイグレーションのイベント前に、ユーザに対して利用可能な技術的特徴を提供する他、SGUIシステム１０は、第１異種装置プラットフォームから第２異種装置プラットフォームへマイグレーションするGUIアプリケーションの実行状態を保存することができる。ここでいう実行状態とは、SGUIコンポーネントに影響を与えている拡張性のあるアプリケーションのエンドユーザがもたらした変化を指している。この変化はSGUIコンポーネントの変数（外観の変化、データエントリー、状態変化）を含んでもよい。図１３は、第１異種装置プラットフォーム３０２、第２異種装置プラットフォーム３０４、そしてサーバコンピュータ３０６を有しているSGUIシステム１０の実施形態により動作している通信システムのブロック図である。他の例において、本実施形態とは異なる数のプラットフォーム、及びサーバが利用可能なのはいうまでもない。
【０１１９】第１異種装置プラットフォーム３０２、第２異種装置プラットフォーム３０４は、前に説明された、いかなる異種装置プラットフォームであってもよいし、かつ各々はレンダーマネージャモジュール１６を有してもよい。サーバコンピュータ３０６はコンピュータ装置に類似のものであってよいし、また拡張性のあるGUIライブラリ１２やカスタマイズモジュール１４内にあるタスクマネージャモジュール１８及び変換マネージャモジュール２０を有していてもよい。他の例においてモジュールは、コンピュータ装置の処理能力、ネットワーク２０８の構成、プロバイダーの優先度などの様々な変化に応じながら、通信システム内にある装置へと別々に配信されてもよい。第１異種装置プラットフォーム３０２＆第２異種装置プラットフォーム３０４とサーバ３０６間における通信は、ネットワーク２０８を介してもよい。
【０１２０】前にも説明した通り、装置プラットフォーム独立型(PI)の中間表現は、拡張性のあるアプリケーションを開発の一部分として開発される。プラットフォーム独立型の中間表現は、プラットフォーム独立型の中間モデル形式で保存されてもよい。プラットフォーム独立型の中間モデルは、サーバ３０６、第１異種装置プラットフォーム３０２、第２異種装置プラットフォーム３０４あるいはネットワーク２０８と通信しているその他の装置内で保存されてもよい。
【０１２１】本実施形態において、装置プラットフォーム独立型の中間表現は、最大の表示画面と最も大規模なユーザインターフェイスメカニズムを有している装置プラットフォームに基づいて特定されてもよい。ここでアプリケーション開発者は、拡張性のあるアプリケーションは最大の表示画面と最も大規模なユーザインターフェイスメカニズムで動作していることが予測できる。例えば、装置プラットフォーム独立型の中間表現は、大きな表示画面と複数のユーザインターフェイス（例：タッチスクリーン、マウス、キーボードなど）を持つラップトップコンピュータの動作に基づいて特定されてもよい。従って、プラットフォーム独立型のプレゼンテーションモデルから生成されたプラットフォーム特定型のプレゼンテーションは、プラットフォーム独立型のプレゼンテーションモデルと同サイズ、あるいはそれより小さいものであってもよい。
【０１２２】図１４は、IRツリー４０及び対応するGUIプレゼンテーション４０４形式における拡張性のあるサーチアイテムアプリケーション用のプラットフォーム独立型のプレゼンテーションモデルである。前に説明済みだが、ルートノード４４ａはIRツリー４０上に位置し、かつGUIプレゼンテーションを表してもよい。ルートノード４４ａの子供ノードは、コンテナノードあるいは拡張性のあるアプリケーションのエンドユーザに対して利用可能な異なるタスクを表しているタスクノードである。コンポーネントノード、個々のSGUIコンポーネント及びSGUIコンポーネント複合を表している「葉ノード」が広がるまで、コンテナノード４４は、さらにサブタスクノード、サブのサブタスクノード等に分割可能な論理パネルであってもよい。
【０１２３】図１４の例において、「アイテムタスクのサーチ」として特定されているコンテナノード４４ｍは、「タスクのサーチ」として特定されている第１タスクノード４４ｎ、「結果タスクの分類」として特定されている第２タスクノード４４ｐ、および「結果タスクの表示」として特定されている第３タスクノード４４ｑを有している。タスクノード４４ｎ,４４ｐ,４４ｑの各々は論理パネルを表しており、かつコンポーネントノードを有している。図の例においてコンポーネントノードは、IRツリー４０のプラットフォーム独立型のプレゼンテーションモデルから生成されたJ2SE Swing GUIのようなGUIプレゼンテーション４０４内に描かれている。従ってGUIプレゼンテーション４０４を形成するために、IRツリー４０のSGUIコンポーネントは、J2SE Swingにおけるプラットフォーム特定型のGUIコンポーネントへマッピングする。
【０１２４】「タスクのサーチ」として特定されたコンテナノード４４ｎは、３つのサブタスクノード(コンポーネントノード)に分割される論理パネルを表してもよい。ここで３つのサブタスクノードとは、SGUIコンポーネントあるいはSGUIコンポーネント複合である。３つのサブタスクノードは次のように表されている。
1.「アイテムの検索」(バーチャルラベル４０８)として表されている第１コンポーネントノード２.「サーチ」(バーチャルボタン４１０)として表されている第２コンポーネントノード３.バーチャルテキスト領域４１２として表されている第３コンポーネントノード。
拡張性のあるアプリケーションのエンドユーザが選択可能な分類優先タスクと表示選択タスクを提供するために、第２コンテナノード４４ｐ＆第３コンテナノード４４ｑと関連しているSGUIコンポーネント及び/またはSGUIコンポーネント複合も同様に、GUIプレゼンテーション４０４内にあるプラットフォーム特定のGUIコンポーネントにより表される。
【０１２５】プラットフォーム独立型のプレゼンテーションモデル内において、SGUIコンポーネント及びSGUIコンポーネント複合は、プラットフォーム独立(PI)ウィジェット、あるいはプラットフォーム独立型のGUIウィジェットと見なしてもよい。SGUIコンポーネント及びSGUIコンポーネント複合は、プラットフォーム特定のプレゼンテーションにおけるプラットフォーム特定(PS)のウィジェットにより表される。プラットフォーム特定型のウィジェットを有するSGUIコンポーネントおよびSGUIコンポーネント複合は、事前に決められたマッピングに基づいている。ここでのマッピングは、拡張性のあるGUIコンポーネントライブラリモジュール２２と他のライブラリにおける装置特定のGUIコンポーネント間のことである。事前に決められたマッピングは、プラットフォーム特定のプレゼンテーション内にあるプラットフォーム特定型のウィジェットを、プラットフォーム独立型のプレゼンテーションモデル内の(プラットフォーム独立型のウィジェットに対応している) SGUIコンポーネント、およびSGUIコンポーネント複合に対応づける。
【０１２６】前にも説明した通り、プロパティはIRツリー４０のタスクノード内に含まれてもよい。ここでプロパティは、少なくとも１つのタスクノード用の詳細なレイアウトプロパティ、少なくとも１つのタスク優先プロパティ、少なくとも１つの優先プロパティ、そして１つ以上の対応するタスクノードに関連する少なくとも１つの分割可能なプロパティのことである。タスクノード用の詳細なレイアウトプロパティは、例えばページ内でプラットフォーム独立型のウィジェットの位置を提供する、レイアウトを制御するJava（登録商標）Gridbag に似ている。タスク優先プロパティはブール(Boolean)機能の配列として実装され、その配列は特定の異種装置プラットフォームを表し、及び/または、タスクが特定のプラットフォームに適しているかどうかを示す。優先プロパティは、プラットフォーム独立型のウィジェット所望のレイアウト結果を表すための整数（インテジャ）として実装される。分割可能なプロパティは、プラットフォーム独立型のウィジェットが複数ページのプレゼンテーションに拡散可能なことを表すブール機能として実装される。
【０１２７】ある実施形態において、各々のタスクノードは、対応するタスクノードの重要性を示している、少なくとも１つの重要プロパティを含んでもよい。重要プロパティは、タスクノードにより表されているプラットフォーム独立型のウィジェットが、コアあるいはオプションかということを示すブール機能として実装される。
【０１２８】コアプラットフォーム独立型のウィジェットは、よく使われるプラットフォーム独立型のウィジェット、あるいは拡張性のあるアプリケーション内において主要なタスクを実行するプラットフォーム独立型のウィジェットとして定義されてもよい。残りのプラットフォーム独立型のウィジェットは、オプショナルのプラットフォーム独立型のウィジェットとして定義されてもよい。例えば、図１４における「サーチアイテムタスク」コンテナノード４４ｍは、前に説明した通り、３つの階層的なサブタスク(コンテナノード４４ｎ,４４ｐ,４４ｑ)を持っている。サーチアイテム実行のため、拡張性のあるアプリケーションのエンドユーザはバーチャルテキスト領域４１２にアイテム名を入力し、そしてサーチ処理を始める為にバーチャルボタン４１０を起動してもよい。しかしながら本例において、分類優先タスクと表示選択タスクはサーチ結果を表示するための付加的な機能なので、エンドユーザは両タスクを特定させる必要はない。このように、サーチタスク(コンテナノード４４ｎ)と関連のあるプラットフォーム独立型のウィジェットはコアとして特定され、そして結果分類タスク(コンテナノード４４ｐ)、および結果表示タスク(コンテナノード４４ｑ)と関連のあるプラットフォーム独立型のウィジェットはアプリケーション開発者によるオプションと特定されてもよい。
【０１２９】再び図１３に戻り、中間表現におけるアプリケーション開発者により特定されたプロパティは、タスクマネージャ１８と変換マネージャモジュール２０により利用されてもよい。GUIのマイグレーション中において、変換マネージャモジュール２０はタスク優先プロパティを利用し、タスクマネージャ１８は残りのプロパティを利用してもよい。
【０１３０】図１５は、第１異種装置プラットフォーム３０２から第２異種装置プラットフォーム３０４へ、GUIアプリケーションの実行状態がマイグレーションするプロセスを表しているフロー図である。同図のGUIアプリケーションのマイグレーションにおいて、プラットフォーム特定型のプレゼンテーションは、以前カスタマイズモジュール１４におけるプラットフォーム独立型のプレゼンテーションモデルから生成され、そして第１異種装置プラットフォーム３０２へ提供されていた。第１異種装置プラットフォーム３０２は、プラットフォーム特定型のプレゼンテーションに基づき、対応する表示画面上に対話式の表示を提供してもよい。
【０１３１】第１プラットフォーム３０２上に表示される、プラットフォーム特定型のプレゼンテーション内のプラットフォーム特定型のウィジェットの実行状態がシリアル化された時、動作は始まる。(ブロック５０２)プラットフォーム特定型のウィジェットのシリアル化された実行状態と共に、マイグレーションのターゲット装置として第２異種装置プラットフォーム３０４を特定するマイグレーション要求は、ネットワーク２０８経由でサーバ３０６へ伝達される。(ブロック５０４)プラットフォーム独立型のプレゼンテーションモデルに含まれているプラットフォーム独立型のウィジェットは、第１プラットフォーム３０２が提供するプラットフォーム特定型のウィジェットの実行状態により更新される。（ブロック５０６）プラットフォーム独立型のプレゼンテーションモデルのコピーが作られる。（ブロック５０８）
【０１３２】サーバ３０６は、第２異種装置プラットフォーム３０４のGUI能力を調査し、そして表示画面サイズ、ユーザ入力メカニズム等のユーザインターフェイス関連の能力を確認する。（ブロック５１０）タスクマネージャ１８はタスク優先プロパティを利用し、プラットフォーム独立型のプレゼンテーションモデルのコピーから不必要なタスクノードを除去し、そして第２異種装置プラットフォーム３０４用にプラットフォーム特定型のプレゼンテーションの生成を始める。（ブロック５１２）
【０１３３】変換マネージャモジュール２０はプラットフォーム独立型のプレゼンテーションモデルのコピーからノードを選択し、ノードに関連するプラットフォーム独立型のウィジェットを、第２異種装置プラットフォーム３０４用に、プラットフォーム特定型のウィジェットへマップする。（ブロック５１４）プラットフォーム特定型のウィジェットは、プラットフォーム特定型のプレゼンテーションのページ上に配置される。（ブロック５１６）ここでページサイズが、第２異種装置プラットフォーム３０４の表示画面より大きいかどうかを判定する。（ブロック５１８）もしページサイズが大きすぎて表示画面に適さない場合、変換マネージャモジュール２０は、プラットフォーム独立型のプレゼンテーションモデルのコピーからプラットフォーム独立型のウィジェットをカスタマイズし、１あるいはそれ以上のページを表示画面５２０へと適合させる。（ブロック５２０）カスタマイズされたプラットフォーム独立型のウィジェットは、プラットフォーム特定型のプレゼンテーション用のプラットフォーム特定型のウィジェットへマップされる。（ブロック５２２）プラットフォーム独立型のプレゼンテーションモデルにおけるプラットフォーム独立型のウィジェットの実行状態が、プラットフォーム特定型のプレゼンテーション用のプラットフォーム特定型のウィジェットの実行状態へ適用される。（ブロック５２３）
【０１３４】プラットフォーム独立型のプレゼンテーションモデル内において、未処理のノードがないかどうかを判定する。（ブロック５２４）もしイエスなら動作はブロック５１４へ戻り、別ノードを選択し、対応するプラットフォーム特定型のウィジェットをページ等へ追加し、そしてプラットフォーム特定型のプレゼンテーションの生成を続ける。もしノーなら、プラットフォーム特定型のプレゼンテーションにより利用されるプラットフォーム特定型のプレゼンテーションの生成されたページ、プラットフォーム独立型のプレゼンテーションモデルの最終コピー、および拡張性のあるGUIライブラリ１２の一部分を第２異種装置プラットフォーム３０４へ送信する。（ブロック５２６）もしページが表示画面に適していたら（ブロック５１８）、動作はそのままブロック５２４へと進み、未処理のノードがないかどうかを判定する。第２異種装置プラットフォーム３０４のレンダーマネージャモジュール５１６は、送信されたプラットフォーム特定型のプレゼンテーション上、プラットフォーム独立型のプレゼンテーションモデルの最終コピー上、および拡張性のあるGUIライブラリ１２の一部分を使っている表示画面上にプレゼンテーションを表示する。
【０１３５】ページに適したプラットフォーム特定型のプレゼンテーションの生成中におけるカスタマイズは、ウィジェットのレイアウトカスタマイズとウィジェットの変換カスタマイズを含んでいてもよい。このようなカスタマイズは、次における要件に基づいている。（１）アプリケーション開発者が特定した最低限の指示により、比較的高品質のプレゼンテーションを生成する。（２）プレゼンテーション生成の遅れを最小限にするため、カスタマイズを比較的シンプルにする。（３）プラットフォーム特定型のプレゼンテーション全体のページを見るため、表示画面上においてスクロールを避ける。
【０１３６】前にも設明した通り、レイアウトカスタマイズは、IRツリーにおける各々のノード処理、およびページ内において関連のあるプラットフォーム特定型のウィジェットを配置することを含んでもよい。またレイアウトカスタマイズ中におけるプラットフォーム特定型のウィジェットの配置において、ページを最適化して、ターゲット装置異種プラットフォームの表示画面に適合させる変換を実行してもよい。プラットフォーム特定型のウィジェットの最初のレイアウトは、アプリケーション開発者が特定するノードに関連したプラットフォーム特定型のウィジェットのレイアウトプロパティに基づいてもよい。レイアウトプロパティは、レイアウトを制御するJava（登録商標）Gridbagに類似のものであってよいし、かつページ上で対応するプラットフォーム特定型のウィジェットの相対的な位置を示すものであってもよい。もしページサイズがターゲット異種装置プラットフォームの表示画面に適合していないなら、プラットフォーム独立型のウィジェットをカスタマイズすることにより、プラットフォーム特定型のウィジェットのレイアウトは更にカスタマイズされる。
【０１３７】更にレイアウトカスタマイズは、フローレイアウトマネージャを使いながら、ページ内にあるプラットフォーム独立型のウィジェットを再配置再配置してもよい。フローレイアウトマネージャを使うプラットフォーム独立型のウィジェットの再配置においては、例えば、プラットフォーム独立型のウィジェットを一列ではなく、一列以上に配置すること等を含めてもよい。再配置されたプラットフォーム独立型のウィジェットは、プレゼンテーションのページが表示画面のサイズを超えるプラットフォーム特定型のウィジェットに対応する、プラットフォーム独立型のウィジェットであってもよい。一方、物理的な空間や優先度などのクライテリアは、動的な再配置用に、ページ内のプラットフォーム特定型のウィジェットに対応している、どのプラットフォーム独立型のウィジェットを選択するかを決定してもよい。
【０１３８】フローレイアウトマネージャは、変換マネージャモジュール２０により起動されてもよいし、あるいは変換マネージャモジュール２０の一部分であってもよい。フローレイアウトマネージャは、Java FlowLayoutである。さらに、分割可能なプロパティとしてアプリケーション開発者に特定され、かつSGUIコンポーネント複合であるプラットフォーム独立型のウィジェットは、SGUIコンポーネント単体に分割されてもよい。SGUIコンポーネント単体がマップされるプラットフォーム特定型のウィジェットは、SGUIコンポーネント単体あるいはその他のプロパティに関連する優先プロパティに基づきながら、プレゼンテーションの複数のページ間において分配されてもよい。分割されたSGUIコンポーネント単体のレイアウトは、フローレイアウトマネージャで実行されてもよい。ここでSGUIコンポーネント複合は、アプリケーション開発者により、非分割として特定されてもよい。以下におけるカスタマイズにおいて、プレゼンテーションのページが表示画面に適さない場合、変換カスタマイズを起動してもよい。
【０１３９】変換カスタマイズは、変換ルールのアプリケーションを含んでいてもよい。変換ルールは、ターゲット異種装置プラットフォームの表示画面に適合させるため、ページ内におけるプラットフォーム特定型ウィジェットの適切なサイズ変換実現の為に適用されてもよい。変換カスタマイズの目的は、プレゼンテーションのページサイズを縮小し、異種装置プラットフォームの表示画面内に丁度適合させることにより、スクロールの使用を避けることである。
【０１４０】変換カスタマイズ中において、変換マネージャモジュール２０は、どのプラットフォーム独立型のウィジェットが変換され、そしてどのようにプラットフォーム独立型のウィジェットが変換されるかを決定してもよい。どのプラットフォーム独立型のウィジェットを変換するかの決定は、変換可能で、かつ変換ルーツをトリガするプラットフォーム独立型のウィジェットを特定する事に基づいてよい。変換ルールをトリガするプラットフォーム独立型のウィジェットは、プレゼンテーションのページサイズが表示画面のサイズを超えてしまう原因となるプラットフォーム特定型のウィジェットへマップする、非分割なSGUIコンポーネント単体、あるいは非分割なSGUIコンポーネント複合であってもよい。
【０１４１】プラットフォーム独立型のウィジェットがどのように変換するかは、特定されたウィジェットに基づいている。プラットフォーム独立型のウィジェットがSGUIコンポーネント単体な場合、変換ルールがそのSGUIコンポーネント単体に適用されてもよい。しかしながら、プラットフォーム独立型のウィジェットがSGUIコンポーネント複合である場合、SGUIコンポーネント複合内にあるSGUIコンポーネント単体の各々は、SGUIコアコンポーネントとSGUIオプショナルコンポーネントとしてカテゴリー化される。SGUIコンポーネント複合内にあるSGUIコンポーネント単体のカテゴリー化は、プレゼンテーションモデルのタスクにおいて、アプリケーション開発者が特定する重要プロパティに基づいてもよい。
【０１４２】プラットフォーム独立型のウィジェットを、よりコンパクトなウィジェットにする変換はGUIの有用性を劣化させるかもしれないので、変換ルールはSGUIオプショナルコンポーネントに適用される。もし重要プロパティによるSGUIオプショナルコンポーネントが特定されていない場合、あるいはページをターゲット異種装置プラットフォームへ適合させるためSGUIオプショナルコンポーネントのサイズを縮小することが適切でない場合、変換ルールはSGUIコアコンポーネントへ適用されてもよい。
【０１４３】また変換マネージャモジュール２０は、複数のルールの中から最も適した変換ルールを決定することにより、プラットフォーム独立型のウィジェット(SGUIコンポーネント単体)を変換してもよい。ここで言う適切な変換ルールとは、対応するプラットフォーム特定型のウィジェットのサイズを変換し、表示画面のサイズに適合させることである。変換ルールは、次の４つのタイプにカテゴリー化されてもよい。（１）「１から１タイプへの変換ルール」（２）「１から複数タイプへの変換ルール」（３）「複数の同クラスから１タイプへの変換ルール」（４）「複数から複数タイプへの変換ルール」
【０１４４】「１対１タイプへの変換ルール」とは、プラットフォーム独立型のウィジェット(SGUIコンポーネント単体)を別のプラットフォーム独立型のウィジェット(SGUIコンポーネント単体)に変換することである。例を挙げると、図５における第１SGUIコンポーネント７０は、１から１タイプの変換ルールにより、第２SGUIコンポーネント７２であるドロップダウンボックスに変換される。「１から複数タイプへの変換ルール」とは、プラットフォーム独立型のウィジェット(SGUIコンポーネント単体)を複数のプラットフォーム独立型のウィジェット（各々のSGUIコンポーネント単体）へ変換することである。例を挙げると、データテーブルを表している単一のプラットフォーム独立型のウィジェットが、複数のデータリストを表している単一のプラットフォーム独立型のウィジェット、あるいは複数のデータリストを表している単一のプラットフォーム独立型のウィジェットに変換されてもよい。
【０１４５】「複数の同クラスから１タイプへの変換ルール」とは、同じクラスに属する複数のプラットフォーム独立型のウィジェット(各々のSGUIコンポーネント単体)を、プラットフォーム独立型のウィジェット(SGUIコンポーネント単体)に変換することである。例を挙げると、同じクラスにあり、かつラジオボタンを表している複数の単一のプラットフォーム独立型のウィジェットは、リストあるいはドロップダウンボックスを表している単一のプラットフォーム独立型のウィジェットに変換されてもよい。同様に、テキスト領域あるいはラベルを表している、いくつかの単一のプラットフォーム独立型のウィジェットは、各々１つのテキスト領域、あるいはドロップダウンボックスを表している単一のプラットフォーム独立型のウィジェットに変換されてもよい。
【０１４６】「複数から複数タイプへの変換ルール」とは、異なるクラスに属する複数のプラットフォーム独立型のウィジェットを、別の対応する複数のプラットフォーム独立型のウィジェットに変換することである。各々の複数から複数タイプへの変換ルールは、「１つ以上の複数の同クラスから１タイプへの変換ルール」、及びフォーム記入関係のような、異なるプラットフォーム独立型のウィジェット間における対応関係を含んでいてもよい。
【０１４７】フォーム記入とは、拡張性のあるアプリケーションのエンドユーザが入力したデータをプラットフォーム特定型のウィジェット形式で表すことを可能にする、プラットフォーム独立型のウィジェット間における関係を示している。言い換えれば、第１プラットフォーム特定型のプレゼンテーションにあるプラットフォーム特定型のウィジェットの状態を、第２プラットフォーム特定型のプレゼンテーションへ変換されたプラットフォーム特定型のウィジェットと同様の状態にすることである。プラットフォーム独立型のウィジェット間における関係は、開発者、知識ベース型システム、実験、あるいはプラットフォーム独立型のウィジェットと変換されたプラットフォーム独立型のウィジェット間において関係を作るその他のメカニズムにより、プラットフォーム独立型のプレゼンテーションモデルにおいて提供可能である。
【０１４８】例えば、図６にあるデータエントリ８０にあるラベル(例：「アイテム名」、「ブランド名」)はピックリスト８６に変換され、そして対応するデータエントリ領域は、拡張性のある「複数の同クラスから１タイプへの変換ルール」を利用している単一のデータエントリ８８へと変換される。これら２つの変換は、プラットフォーム独立型のプレゼンテーションモデル、およびプラットフォーム特定型モデルにおけるフォーム記入関係にリンクさせてもよい。
【０１４９】変換マネージャモジュール２０により、「複数の同クラスから１タイプへの変換ルール」、および「複数から複数タイプへの変換ルール」で変換されたプラットフォーム独立型のウィジェットを、他のプラットフォーム独立型のウィジェットへリンクさせてもよい。リンクは、プレゼンテーション内の２つ以上のプラットフォーム特定型のウィジェット間における動作関係（例：図１４のバーチャルボタン４１０とバーチャルテキスト領域４１２間における動作関係）に関連している。第１プラットフォーム特定型のウィジェットと第２プラットフォーム特定型のウィジェット間におけるリンクは、第１プラットフォーム特定型のウィジェットの状態を変化させることになり、かつ第２プラットフォーム特定型のウィジェットの状態を変化させることになる。プラットフォーム特定型のウィジェット間におけるリンクは、プラットフォーム独立型のプレゼンテーションモデルにおいて、対応する第１＆第２プラットフォーム独立型のウィジェットのリンクにより提供されてもよい。
【０１５０】変換ルールが採用されると、オリジナルプラットフォーム独立型のウィジェットの実行状態は別のフォームで表されてもよい。異なる変換ルールが特定のプラットフォームの制約に基づきオリジナルプラットフォーム独立型のウィジェットに対して適用可能なので、プラットフォーム特定型のウィジェットの実行状態が変換可能となる。オリジナルプラットフォーム独立型のウィジェットの実行状態は、プラットフォーム独立型のプレゼンテーションモデルに保存されてもよい。つまり、変換されたプラットフォーム独立型のウィジェットの実行状態は、オリジナルプラットフォーム独立型のウィジェットの実行状態へとマップされてもよい。
【０１５１】変換されたプラットフォーム独立型のウィジェットは、対応するプラットフォーム特定型のウィジェットとしてターゲット装置の表示画面上に表示される、変換ルールにより選択された装置独立型のウィジェットであってもよい。オリジナルプラットフォーム独立型のウィジェットは、表示画面上に表示される、開発者が選んだ装置独立型のウィジェットである。オリジナルプラットフォーム独立型のウィジェットは、プラットフォーム独立型のプレゼンテーションモデルに接続されてもよい。同様に、変換が成功したとき、変換されたプラットフォーム独立型のウィジェットもプラットフォーム独立型のプレゼンテーションモデルに接続されてもよい。上記の両接続は、コンポーネントノード形式で表現されてもよい。ここで各々のコンポーネントノードは、少なくとも１つのプラットフォーム独立型のウィジェットを表している。
【０１５２】実行状態の変換をするため、プラットフォーム独立型のプレゼンテーションモデルは、オリジナルプラットフォーム独立型のウィジェット及び変換されたプラットフォーム独立型のウィジェット両方のインスタンスを含んでいてもよい。GUIのマイグレーションの実行時間次第で、オリジナルプラットフォーム独立型のウィジェットだけのインスタンス、あるいは変換されたプラットフォーム独立型のウィジェットだけのインスタンスが、同時にアクティブ状態になってもよい。
【０１５３】図１６は、変換されたプラットフォーム独立型のウィジェットの接続、及びアクティブ状態における変換されたプラットフォーム独立型のウィジェットの変化を表しているプラットフォーム独立型のプレゼンテーションモデル５３０の例である。図のプラットフォーム独立型のプレゼンテーションモデル５３０は、コンテナノード５３２、及び関連性のある複数のオリジナルコンポーネントノード５３４を有している。コンテナノード５３２は、論理パネルであるプラットフォーム独立型のウィジェットを表してもよい。また各々のオリジナルコンポーネントノード５３４、及び関連のあるプラットフォーム独立型のウィジェットは、パネル内のラジオボタン(RB)である、プラットフォーム独立型のウィジェットを表してもよい。
【０１５４】プラットフォーム独立型のプレゼンテーションモデルのコピー５３６による、プラットフォーム特定型のプレゼンテーションの生成中において、矢印５３７で示されている変換が起こり得る。プラットフォーム独立型のウィジェットへマップされるプラットフォーム特定型のウィジェット(コンテナノード５３２)が大きいため、ターゲット異種装置の表示画面上に配置できない時、この変換は起こる。例えば、コンテナノード５３２を変えずに、ラジオボタン(オリジナルコンポーネントノード５３４)を表している全てのプラットフォーム独立型のウィジェットを、変換されたコンポーネントノード５３８(コンボボックス：CB)へ変換してもよい。コンボボックスは、ラジオボタンと類似の機能を提供する小さなプラットフォーム独立型のウィジェットであってもよい。
【０１５５】変換されたコンポーネントノード５３８は、変換されたウィジェットを保存、あるいは表すためのプラットフォーム独立型のプレゼンテーションモデルのコピー５３６において作られた新しいコンポーネントノードであってもよい。以下の変換において、変換されたコンポーネントノード５３８は、「変換された子供ノード」としてコンテナノード５３２にリンクされることにより、新しい論理関係を形成してもよい。新しい論理関係がアクティブになることにより、コンテナノード５３２とオリジナルコンポーネントノード５３４間における既存の論理関係と置き換えられてもよい。変換された子供ノード(変換されたコンポーネントノード５３８)は、コンテナノード５３２を特有の子供ノードとしてもよい。
【０１５６】コンテナノード５３２とオリジナルコンポーネントノード５３４間における前の論理関係は、図１６において点線で表されている、プラットフォーム独立型のプレゼンテーションモデルのコピー５３６の論理参照として保存されてもよい。しかしながらオリジナルコンポーネントノード５３４は、開発者が明確に特定していない限り、コンテナノード５３２の子供ノードである必要はない。このようにIRツリーのレイアウト構造において、オリジナルコンポーネントノード５３４は含まれないことになる。またこの論理関係は、あるプラットフォーム特定型のプレゼンテーションから別のプラットフォーム特定型のプレゼンテーションへの実行状態のマイグレーション、及びイベント処理をサポートするのに保存されてもよい。
【０１５７】最も最適な変換ルールを選択するため、ルールには種類に応じて優先順位が設定されていく。「複数から複数タイプへの変換ルール」は大幅に全体のプレゼンテーションを変え、そしてGUIの有用性を劣化させるので、「複数から複数タイプへの変換ルール」には、最も低い優先度が割り当てられてもよい。その他の変換ルールの優先度を決定するに当たって、変換マネージャモジュール２０が各ルールを選択してもよい。
【０１５８】各変換ルールの選別機能により、オリジナルプラットフォーム独立型のウィジェットが有する機能、あるいはその他パラメータと適合性のない、変換されたプラットフォーム独立型のウィジェットを作成する変換ルールを削除してもよい。適合性のない機能には、オリジナルプラットフォーム独立型のウィジェットが、変換されたオリジナルプラットフォーム独立型のウィジェットによりサポートされていない入力メカニズムを要求する、変換ルールが含まれている。例えば、アプリケーション開発者が、アクション実行のためにマウスインイベント(例：マウスの矢印がボタンを指しているとき(クリックではない))に対応しているJ2MEDoJaボタンへ、プラットフォーム独立型のウィジェット用のマッピングを特定するとする。しかしながら、ソフトキーはマウスインイベントをサポートしないので、変換カスタマイズの間、ボタンはソフトキーに変換されることはない。このように、当該プラットフォーム独立型のウィジェット用に、かつ当該変換をサポートする変換ルールは、選別機能により削除されてもよい。
【０１５９】変換マネージャモジュール２０は、一連のスペース縮小パラメータに基づき、変換ルールに優先順位を付けてもよい。スペース縮小パラメータの優先順位とは、変換に基づくプラットフォーム独立型のウィジェットのサイズ、及び/または変換ルールをプラットフォーム独立型のウィジェットに適用することから生じるサイズ縮小量に基づいてもよい。プラットフォーム独立型のプレゼンテーションにあるプラットフォーム独立型のウィジェットにおけるスペース縮小とは、対応するプラットフォーム独立型のウィジェットにおけるスペース縮小により特定される。
【０１６０】最小のスペース縮小を提供する変換ルールには、最も高い優先順位が与えられてもよい。あまりコンパクトでない対応するプラットフォーム特定型のウィジェットは、コンパクトなプラットフォーム特定型のウィジェットより高いGUIの有用性を持っているので、最も高い優先順位は最小のスペース縮小を提供する変換ルールに与えられてもよい。スペース縮小パラメータは、プラットフォーム独立型のウィジェットの幅縮小率、高さ縮小率、そして大きさ縮小率を含んでいてもよい。
【０１６１】変換ルールをトリガさせるプラットフォーム独立型のウィジェットの状態に基づいて、スペース縮小パラメータの優先順位は変更されてもよい。例えばプラットフォーム独立型のウィジェット用の変換ルールが、幅があって、かつ対応するプラットフォーム独立型のウィジェットによりトリガされると、幅縮小率が最も重要なパラメータとして特定されてもよい。次に高さ縮小率が２番目に重要なパラメータとして特定された場合、大きさ縮小率は無視されてもよい。同様に変換ルールが、高すぎるプラットフォーム特定型のウィジェットによりトリガされると、高さ縮小率が最も重要なパラメータとして特定され、次に幅縮小率が２番目に重要なパラメータとして特定されるので、大きさ縮小率は無視されてもよい。また変換ルールが、幅と高さが両方あり過ぎるプラットフォーム特定型のウィジェットによりトリガされると、大きさ縮小率が最も重要なパラメータとして特定され、残りのパラメータ(幅と高さ縮小率)は無視されてもよい。
【０１６２】変換ルールをタイプ化するカテゴライゼーション、選別、およびスペース縮小を実行することにより、各々に対し優先順位が付けられてもよい。また、タイプ化のカテゴライゼーション、選別、またはスペース縮小だけを利用することにより、優先順位が付けられてもよい。さらに、タイプ化のカテゴライゼーション、選別、またはスペース縮小のいかなる組み合わせや順番などを利用することにより、優先順位が付けられてもよい。
【０１６３】異種装置プラットフォームがJava技術を用いて拡張性のあるアプリケーションを実行することに関し、変換ルールはJavaクラスで特定されてもよい。各々の変換ルールは、１つのJavaクラスで表される。クラスの詳細に関して、実行状態及びイベント処理の変換が、プラットフォーム独立型のウィジェット用のアプリケーション開発者によって特定されてもよい。
【０１６４】例えば図６のような変換を実施する、Javaを用いて作成される変換ルールの例を以下に示す。
プライベートクラスのフォーム記入の変換/＊プラットフォーム特定型のウィジェット変換＊/・新しいプラットフォーム独立型のウィジェット(ドロップダウンボックス(DD１))の構成・バーチャルな「アイテム名」、「ブランド名」等、ラベルのプロパティ(例：フォントサイズ)をDD１へコピー・バーチャルテキスト領域(TF１)の構成・バーチャルな「アイテム名」、「ブランド名」等、テキスト領域のプロパティをTF１へコピー/＊実行状態の変換＊/・オリジナルのバーチャルラベルとテキスト領域のペア例を、以下のJavaハッシュテーブルに記録：
・拡張性のある選択イベントのリスナー(イベントライブラリからの)をDD１へ追加、そしてアクションを特定。よってエンドユーザがアイテムをDD１ (例：アイテム名) から選択すると、それに対応する物(例：ボトル水)がハッシュテーブルから選択される。
・その物をTF１上に表示する。
/＊イベント処理の変換＊/・エンドユーザがエンターキー、あるいは相当のキーをヒットした時、「アイテム名」、あるいは「ブランド名」等、テキスト領域にある物が自動的に更新されることをアプリケーション開発者は特定する。
・マイグレーション後に、エンターキーイベントが受信されたら、TF１上に、例えば「コーラ」のような物を入力する。
・例えば「アイテム名」のような、今選択されたアイテムをDD1上に入力する。
・ハッシュテーブル上において、選択されたアイテムのタイトルを検索し、そしてそれに対応するアイテム（物）を更新する。
・イベントの出所として入力された「アイテム名」、及び新しい物として入力された「コーラ」を用いてイベントを作成する。
・オリジナルの状態と変換された状態を同期化させるため、イベントをオリジナルのバーチャル「アイテム名」テキスト領域へ送信。
【０１６５】図１７は、図１３と図１４を参照して説明されるレイアウトカスタマイズのプロセス、及び変換カスタマイズのプロセスの実施形態を表すフロー図である。動作はIRツリーのルートノード４４ａを現在ノードに設定することから始まる。(ブロック５４０)現在ノードの未処理である直接子供ノードがあるかどうかを判定する。(ブロック５４２)イエスなら、最も高い優先順位の未処理の直接子供ノードが現在ノードへ設定され(ブロック５４４)、処理はブロック５４２へ戻る。もし未処理の直接子供ノードがないなら、現在ノードはルートノード４４ａであるかどうかを判定する。(ブロック５４６)もしイエスなら、プラットフォーム特定型のプレゼンテーション、プラットフォーム独立型のプレゼンテーション、及び拡張性のあるGUIライブラリ１２の関連性のある部分が、ターゲット異種装置プラットフォームへ送信される。(ブロック５４８)【０１６６】もし現在ノードがルートノード４４ａでない場合、プラットフォーム特定型のプレゼンテーションモデル内で現在ノードと関連のあるサブノードで表されているプラットフォーム特定型のウィジェットが、アプリケーション開発者によって特定されているプロパティに基づいて、ページ上に配置されてもよい。(ブロック５５０)プロパティは、ページ上でプラットフォーム特定型のウィジェットの位置を示すため、レイアウトを制御するJava Gridbag に類似であってもよい。ページのサイズが算出される。(ブロック５５２)ページのサイズが、ターゲット表示画面のサイズと比較される。(ブロック５５４)もしページが、ターゲット表示画面内に適合するなら、現在ノードに関連しているプラットフォーム独立型のウィジェットが、プラットフォーム独立型のプレゼンテーションモデルのコピー内に保存される。(ブロック５５６)処理済みの現在ノードがマークされ（ブロック５５８）、別の現在ノードを選択するために、動作はブロック５４０へ戻る。一方ページのサイズが、ターゲット表示画面より大きいのなら(ブロック５５４)、フローレイアウトマネージャを使っているプラットフォーム独立型のウィジェットを再配置することにより、プラットフォーム特定型のウィジェットはページ内で動的に再配置される。(ブロック５６０)【０１６７】図１８に進み、ページのサイズが、再びターゲット表示画面のサイズと比較される（ブロック５６２）。もしページがターゲット表示画面に適合するのなら、動作はブロック５５６へと戻り、プラットフォーム特定型のプレゼンテーションのコピー内においてプラットフォーム独立型のウィジェットを保存する。もしページがまだターゲット表示画面のサイズより大きいのなら、現在ノード(プラットフォーム独立型のウィジェット)、あるいは他の関連するノードが分割可能かどうかを判定する（ブロック５６４）。ブロック５６６でイエスと判定されたなら、少なくとも第２ページがインスタンス化される。プレゼンテーションがページに適合するまで、特定された分割ノードに関連しているプラットフォーム特定型のウィジェットが、フローマネージャを使うことにより第１ページと少なくとも第２ページの間で分配される（ブロック５６８）。プラットフォーム独立型のウィジェットが、プラットフォーム独立型のプレゼンテーションのコピー内において保存される。（ブロック５６９）処理済みの現在ノードがマークされ（ブロック５７０）、別の現在ノードを選択するために、動作はブロック５４０へ戻る。
【０１６８】関連のあるサブノード、あるいは現在ノードのいずれもが分割できない場合（ブロック５６４）、現在ノードと関連のある変換可能なプラットフォーム独立型のウィジェットが特定される。(ブロック５７４)プラットフォーム独立型のウィジェットが、SGUIコンポーネントであるかどうかの判定が実行される。(ブロック５７６)もしプラットフォーム独立型のウィジェットがSGUIコンポーネントであるなら、複合ウィジェット内にあるSGUIコンポーネント単体は、重要プロパティに基づいたSGUIコアコンポーネント、及びSGUIオプショナルコンポーネントとして、カテゴリー化される。(ブロック５７８)【０１６９】図１９に進み、SGUIオプショナルコンポーネントが全て処理されたかどうかを判定する。（ブロック５８０）もしノーなら、次の未処理のSGUIオプショナルコンポーネントが選択される。（ブロック５８２）適用可能な全ての変換ルールが、選択された全てのSGUIコンポーネント用に検索される。（ブロック５８４）検索された変換ルールが、４つある変換ルールの中の１つとして特定される。（ブロック５８６）「複数から複数タイプへの変換ルール」に対し、最も低い優先順位が付けられる。(ブロック５８８)残り３つの変換ルールについては選別され、不適合なルールが除去される。（ブロック５９０）残り３つの変換ルールに関して、変換されたSGUIコンポーネントの予想されるスペース縮小量が算出される。（ブロック５９２）
【０１７０】図２０に進み、スペース縮小量に基づいて、残りの変換ルールに対しても優先順位が付けられる。（ブロック５９４）最も高い優先順位(最も少ないスペース縮小)を持つ変換ルールが、SGUIコンポーネントに適用される。（ブロック５９６）変換されたSGUIコンポーネントが、プラットフォーム特定型のウィジェットへマップされる。（ブロック５９８）プラットフォーム特定型のウィジェットが、フローレイアウトマネージャにより、ページ内に配置される。（ブロック５９９）ここでページが、ターゲット異種装置プラットフォームの表示画面より大きいかどうかを判断する。（ブロック６００）もしノーなら、動作は図１７のブロック５５６に戻り、プラットフォーム独立型のプレゼンテーションモデル等のコピー内に、現在ノードと関連したプラットフォーム独立型のウィジェットを保存する。もしページがまだ大きすぎるのなら、プラットフォーム独立型のウィジェットに内の全てのSGUIコンポーネントが処理されたかどうかを判定する。（ブロック６０２）もしノーなら、動作は図１９のブロック５８０へ戻る。もしプラットフォーム独立型のウィジェットにおける全てのSGUIコンポーネントが処理されているのなら、対応するプラットフォーム独立型のウィジェット用のノードが、処理されたものとしてマークされる。（ブロック６０４）現在ノードと関連している全ての変換可能なプラットフォーム独立型のウィジェットが、処理されたどうかを判定する。(ブロック６０６)もしノーなら、動作は図１８のブロック５７４に戻り、その他の変換可能なプラットフォーム独立型のウィジェットを特定する。もし現在ノードと関連している全� | |