(57)【要約】      （修正有）【課題】携帯電話およびＰＤＡｓのような通信装置での、増大するサイズと分解能のディスプレイスクリーンの内蔵に対応し、またこれらの装置の処理能力における制限にかんがみて、装置の使用を容易にする魅力的なユーザーインターフェースをユーザーに提供するとともにユーザー入力に対する高速な応答を提供する。【解決手段】複数のアクターとアクターに関連する複数の属性により定義されるユーザーインターフェースが提供される。レンダラーはアクターの属性に従ってユーザーインターフェースを描写するために使用される。例えば、キーの押下に応答したアクター属性の変化はユーザーインターフェースを更新させる。【選択図】図３
2011248909.tif 000002
【特許請求の範囲】
【請求項１】
装置のためのユーザーインターフェースをレンダリングする方法において、
複数のアクターを供給するステップであって、複数のアクターの各々は、ユーザーインターフェースエレメントに関連し、それぞれのアクターを定義する１つ以上の属性を備えるステップと、
複数のアクターの１つ以上から１つ以上の属性を受信するためにレンダラーを供給するステップと、および
受信した属性に従ってユーザーインターフェースをレンダリングするステップと、
を備えた方法。
【請求項２】
アクター属性が更新されるなら、前記更新は、前記レンダラーにより受信され、前記ユーザーインターフェースはそれに従って更新される、請求項１の方法。
【請求項３】
アクター属性はユーザー更新に応答して更新される、請求項２の方法。
【請求項４】
属性の前記更新は、ユーザーインターフェースエレメントのフォーマッティングを変化させる、請求項２の方法。
【請求項５】
属性の前記更新は、ユーザーインターフェースエレメントを前記ユーザーインターフェース内で移動させる、請求項２の方法。
【請求項６】
前記アクター属性は、マークアップ言語を備え、前記レンダラーは、マークアップ言語レンダラーである、請求項１乃至５のいずれかの方法。
【請求項７】
請求項１乃至６のいずれかの方法を実行するためのコンピューター実行可能コードを備えたデータキャリア。
【請求項８】
１つ以上のユーザーインターフェースエレメントを備えたユーザーインターフェースと、
各々がユーザーインターフェースエレメントに関連し、１つ以上の属性を備えた複数のアクターと、
使用時に前記複数のアクターの１つ以上と関連する属性を解釈し、それに従って前記ユーザーインターフェースを描画するように構成されたレンダラーと、
を備えた装置。
【請求項９】
前記装置は、さらに前記ユーザーインターフェースを表示するための表示手段を備える、請求項８の装置。
【請求項１０】
前記装置は、さらに前記ユーザーインターフェースのレンダリングに使用するためのさらなるアクターを受信するための通信インターフェースを備えた、請求項９の装置。
【請求項１１】
前記装置はさらに、前記複数のアクターを記憶するように構成された記憶装置手段を備えた、請求項８乃至１０のいずれかの方法。
【請求項１２】
前記装置は、前記レンダラーを動作するように構成された処理手段をさらに備えた、請求項８乃至１１のいずれかの方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はレンダリングユーザーインターフェースに関し、特に通信装置のためのユーザーインターフェースをレンダリングすることに関する。
【背景技術】
【０００２】
例えば、携帯電話およびＰＤＡｓのような通信装置は、増大するサイズと分解能のディスプレイスクリーンを内蔵する。これらの装置の処理能力における制限にかんがみて、装置の使用を容易にする魅力的なユーザーインターフェースをユーザーに提供するとともにユーザー入力に対する高速な応答を提供することが望ましい。自動車電話のようないくつかの装置の場合、ユーザーインターフェースを更新するためのコンテンツがユーザーに配置することができるように、ユーザーおよび／またはネットワークオペレータにより敏速にかつ容易に更新することができるユーザーインターフェースを提供することに大きな関心がある。既知のアプローチは、必要な柔軟性を欠くかまたは深刻かつ望ましくない処理能力のレベルを要求する傾向がある。
【発明の概要】
【０００３】
この発明の第１の観点によれば、装置のためのユーザーインターフェースを描画する方法が提供される。この方法は複数のアクター(actor)を供給するステップを備える。複数のアクターの各々は、ユーザーインターフェースエレメントに関連し、それぞれのアクターを定義する１つ以上の属性を備える。また、この方法は、１つ以上の複数のアクターから１つ以上の属性を受信するためにレンダラーを供給するステップと、受信した属性に従ってユーザーインターフェースを描画するステップとを備える。
【０００４】
この発明の第２の観点によれば、上述の方法を実行するためのコンピューター実行可能なコードを備えたデータキャリアが提供される。
【０００５】
この発明の第３の観点によれば、以下を備えた装置が提供される。１つ以上のユーザーインターフェースエレメントを備えたユーザーインターフェースと、複数のアクターであって、複数のアクターの各々はユーザーインターフェースエレメントに関連し、１つ以上の属性を備える複数のアクターと、使用時に、１つ以上の複数のアクターに関連する属性を解釈し、それに従ってユーザーインターフェースを描画するレンダラーとを備える。
【図面の簡単な説明】
【０００６】
【図１】図１はこの発明を内蔵するシステムの概略の描画を示す。
【図２】図２はサーバー１００の構造と動作をより非常に詳細に描画する。
【図３】図３は移動装置３００のためのソフトウエア４００の概略描画を示す。
【図４】図４はコンテンツツールセット２００の概略描画を示す。
【図５】図５は、この発明の一実施形態に従うユーザーインターフェースを備えた装置の概略描画を示す。
【発明を実施するための形態】
【０００７】
この発明は実例としてのみおよび添付された図面に対して記載されるであろう。図面において、図１は、サーバー１００、コンテンツツール２００、移動装置３００、動作サポートシステム７００、コンテンツフィード５００およびユーザーインターフェース（ＵＩ）ソース６００を備えたシステムの概略描画を示す。使用時に、サーバーは、コンテンツデータおよびデータを移動装置３００、３０１．．．に通信する。移動装置の各々は、ソフトウエアパッケージ４００を備えている。サーバー１００はＯＳＳｓ７００とインターフェースする。ＯＳＳｓは、例えば、請求書作成、アカウント管理等の移動ネットワークを動作させるために通常使用されるＯＳＳｓである。サーバー１００はさらにコンテンツツールセット２００とインターフェースする。コンテンツツールセットはＵＩソース６００、６０１、．．．からデータを受信し、サーバーが、移動装置３００内に構成されたソフトウエアパッケージ４００にパッケージ化されたＵＩデータを送信することができるようにＵＩデータをパッケージ化する。サーバーは、複数のコンテンツフィードからデータを受信する。このデータは、ソフトウエアパッケージに送信することができるように、または移動装置３００がソフトウエアパッケージ４００を用いてデータをアクセスすることができるように、処理されパッケージ化される。
【０００８】
システムは、３つの分離された領域に分割されるものとして考えることができる。
【０００９】
オペレーター領域５０は、移動ネットワークオペレーター（ＭＮＯ）により動作されるシステムおよび装置を備える。ユーザー領域は複数の移動装置を備える。第三者領域７０は、多数の異なるエンティティにより制御され動作されてもよいコンテンツフィードとＵＩフィードを備える。
【００１０】
図２は、サーバー１００の構造と動作をより詳細に描画する。サーバー１００は、パブリッシングコンポーネント１１０およびコンテンツサーバーコンポーネント１５０を備える。パブリッシングコンポーネントは、データベース１１１、インポートキュー１１２、コンテンツツールセットインターフェース１１３、ユーザーインターフェース１１４およびカタログ１１５を備える。動作において、パブリッシングコンポーネントは、コンテンツツールセットインターフェースにおいてコンテンツツールセットからコンテンツを受信する。コンテンツは１つ以上のトリグ(Trigs)および１つ以上のトリグレット(Triglets)を備えたパーセル２１０ａ、２１０ｂ等（下記参照）の形態で提示される。トリグは携帯電話のような移動装置のためのユーザーインターフェースであり、トリグレットは、トリグを拡張または変更するために使用することができるデータファイルである。パーセルが２以上のトリグを備えているなら、トリグの一方はマスタートリグであってもよい。このマスタートリグから他のトリグが導き出される。
【００１１】
図３は移動装置３００のためのソフトウエア４００の概略描画を示す。移動装置３００は、マークアップ言語レンダラー４１０、更新マネージャー４３０、仮想ファイルシステム４３５、アクターマネージャー４４０、複数のアクター４４５ａ、４４５、．．．、ネイティブＵＩレンダラー４５０、サポートマネージャー４６０、トリグマネージャー４６５およびマークアップ言語パーサー４７０を備える。
【００１２】
ソフトウエアは、ＸＭＬアプリケーションであるＴｒｉｇＭＬを用いて動作してもよい。また、マークアップ言語レンダラー４１０は、移動装置３００上に表示するためにＴｒｉｇＸＭＬコードを描画する。また、マークアップ言語レンダラー４１０は、ＴｒｉｇＭＬパーサーを用いてＴｒｉｇＭＬリソースを解析し、コンテンツを装置スクリーン上に表示し、ハンドセット上のコンテンツの交換とビューイング(viewing)を制御する。ネイティブＵＩレンダラーは、ＴｒｉｇＭＬの使用なしに表示することができるＵＩコンポーネントを表示するためにおよびエラーメッセージを表示するために使用される。
【００１３】
ソフトウエア４００は、装置の固有の方法で提供されインストールされる。同様に、ソフトウエアアップグレードは装置に固有の方法で処理される。ソフトウエアは、内蔵のコンテンツのみを描画する内蔵型のアプリケーションとしてより制限されたフォーマットで提供されてもよい。すなわち、ソフトウエアは、内蔵のトリグで提供されるが後でさらなるトリグを追加することはできない。供給されたトリグは、無線を介してアップグレードされてもよい。
【００１４】
トリグマネージャー４６５は、リソースマネージャー４３０およびマークアップ言語レンダラーへのインターフェースを提供する。トリグマネージャーは一般にトリグ管理に対して責任がある。これは以下のものを含む。使用中にトリグの知識を主張する。現在のトリグを変更する。開始時にトリグの選択をする。信頼できないトリグのための代替システムとしてさらなるトリグを選択する。インストールされたトリグのセットを管理する。どこで特定のトリグがリソースマネージャーにインストールされるかを識別する。トリグの更新チャネル定義を読む。適切に更新マネージャーを構成する。
【００１５】
リソースマネージャーは、装置上の固定記憶装置の抽象概念を提供する。すなわち、ファイルを実ファイルとして記憶することまたはデータベースのレコードとして記憶することである。リソースマネージャーは、マークアップ言語レンダラーおよび更新マネージャーにファイルシステムインターフェースを提供する。
【００１６】
リソースマネージャーは、ファイルパスロジックの処理、実リソースファイルとアクター属性との間の区別、絶対パス上へのトリグ相対パスのマッピング、トリグマネージャーとのインターフェース、および更新マネージャーに変更インターフェースを供給することに対して責任がある。また、リソースマネージャーは、固定記憶装置に記憶されるリソースのインテグリティを保証する、特に、装置電力の損失のような予測できない中断に直面して、インテグリティを保証する責任がある。リソースマネージャーは、現在使用されているトリグの知識を持たない。そのインターフェースは、更新マネージャーおよび異なるスレッドからのレンダラーの両方により使用されてもよいので、そのインターフェースはスレッドが安全である。
【００１７】
更新マネージャーは、トリグおよびトリグレットの受信とアプリケーションを取り扱う。更新マネージャーはレンダラーおよびトリグマネージャーにインターフェースを提供し、以下のことに対して責任がある。レンダラーにより命令されたとき手動更新を開始すること。トリグマネージャーによりそのように構成されるとき、自動更新チャネルを制御し実施すること。手動更新の進捗状況を表示し、ネットワーク接続および／または装置電力の予測しない損失に続いて更新を回復することである。更新パケットフォーマットは、ＸＭＬスキームのバイナリシリアライゼーションとして定義されてもよい。
【００１８】
サポートマネージャーは、イベントまたはエラーの発生を報告するために他のコンポーネントのためのインターフェースを供給する。エラーの重大性に応じて、サポートマネージャーはイベントのログをとりおよび／またはエラーメッセージポップアップを示す。
【００１９】
ＸＭＬは、更新パケットフォーマット並びにＴｒｉｇＭＬコンテンツを定義するために使用される便宜的なデータフォーマット化言語である。帯域幅と記憶効率の理由により、テキストＸＭＬはバイナリ表示にシリアライズされる。更新パケットおよびＴｒｉｇＭＬフラグメントは、同じコンポーネント、すなわちマークアップ言語パーサーにより解析される。ソフトウエアにおいて、任意のさらなるＸＭＬの使用は、バイナリＸＭＬ符号化を使用しなければならず、それゆえ、パーサーを再使用しなければならない。
【００２０】
アクターマネージャー４４０は、ソフトウエア内に存在するアクター４４５のセットの面倒を見る。
【００２１】
アクターマネージャーは以下のものによって使用される。コンテンツがアクターにイベントを送信しているときレンダラーにより使用される。また、属性値が変更されたことを通知したいアクターによって、およびイベント（下記参照）を発信したいアクターによって使用される。
【００２２】
ソフトウエアは、最小２つのスレッドを実行するマルチスレッドアプリケーションを備えていてもよい。いくつのおよびどんな種類のアクターが含まれるかに応じてより多くのスレッドが可能である。ソフトウエアはほとんどの場合、メインスレッドと呼ばれる１つのスレッドで実行する。メインスレッドは、他のコンポーネントと同期的に通信するレンダラーを実行するために使用される。アクターは常にレンダラーに対する同期インターフェースを有する。アクターがその機能性のためにさらなるスレッドを要求するなら、アクターがスレッド間通信を管理する責任がある。多くのアクターがスレッド間通信を要求する場合に不必要なコード重複を回避するために、軽いメッセージングフレームワークを使用してもよい。単一のスレッド化されたオペレーションを用いてソフトウエアを実施することも可能であることは理解されるであろう。
【００２３】
メインスレッドに加えて、更新マネージャーはネットワークスレッドを実行する。ネットワークスレッドは、更新パケットをダウンロードするために使用され、パケットが到着するまで、レンダラーが影響されないことを継続可能にするためにメインスレッドから分離される。更新パケットにおいて定義された変更を適用するとき、更新マネージャーがレンダラーおよびリソースマネージャーと同期的に通信するように、更新マネージャーはスレッド間メッセージングを処理する責任がある。
【００２４】
ソフトウエアのメモリ割り当て戦略はプラットホーム固有である。ＭＩＤＰプラットホーム上では、システムは、すべてのそのメモリ要求に対してシステムヒープ(system heap）およびガーベッジコレクターを単に使用する。
【００２５】
ガーベッジコレクションを予測可能なものに維持しようとしておよびオペレーションにおいて予測されない中断に影響を受けないようにしようとしてコンテンツ交換イベントが生じるときはいつもガーベッジコレクションは強制される。任意のメモリ割り当ては失敗するかもしれないと仮定する。その場合に、ソフトウエアはすでに成功裏に開始され、最初のページを提供したと仮定して、ソフトウエアは、オブジェクト、ガーベッジコレクトおよびリスタートに対するすべての参照を削除するであろう。
【００２６】
Ｃ＋＋に基づいたプラットホーム上で、プリアロケーションおよびオンデマンドアロケーションの混合物は、システムヒープから作られるであろう。起動のために必要な全てのメモリは、起動期間中のオンデマンドで割り当てられる。ここでの任意の失敗は、（可能であれば）ソフトウエアのメッセージを生じる。成功した起動に続いて、コンテンツドキュメントモデルを提供するのに必要なメモリがあらかじめ割り当てられる。コンテンツが定義された限界未満で使用するために作成されるなら、コンテンツは提供されるために保証される。さらなる使用は、ソフトウエアの動作に必要な種々のキャッシュのためにＲＡＭで作られる。メモリ条件が低い場合に、これらのキャッシュは、リリースされソフトウエアからの遅いレンダリング性能を生じる。
【００２７】
ソフトウエアの通常の動作を中断させるのに十分厳しいエラーは、ポップアップダイアログボックスを生じなければならない。ダイアログボックスは、少数の国際化されたエラーメッセージの１つを含む（これらのストリングの国際化されたバージョンは、構築時にソフトウエアにコンパイルされてもよい。表示されるエラーストリングのバージョンは、装置上の関連する言語設定により決定される）。メッセージの数を最小に維持するために、ほんの少数の包括的問題がカバーされる。サポート状況を考慮に入れるために、エラーダイアログは、また、４桁（１６ビット）の１６進ストリングとしてエラーコードを表示する。各エラーコードは、ソフトウエアで問題の性質を決定するためにサポートスタッフにより使用することができる記述テキストに関連する。ソフトウエアにおいて生じるエラーであってその動作を中止するのに十分厳しくないエラーは、サポートマネージャーコンポーネントによりログが取られる。サポートマネージャーは、特殊なキーシーケンスをタイプするユーザーにより問い合わせを行うことができる。また、サポートマネージャーはそのエラーログをＨＴＴＰ  ＧＥＴまたはＰＯＳＴ方法を介してサーバーに供給することができる。
【００２８】
レンダラーはキー押下に関する情報を受信する。キーのために構築時に構成される行動がないなら、行動はＴｒｉｇＭＬコンテンツイベントとして現在のフォーカスエレメントに送信される。次に、コンテンツイベントは、ＴｒｉｇＭＬの通常イベント処理ロジックにより定義されるように処理される。
【００２９】
例えば、キーが押下されるなら、「キー押下」イベントは、関連するキーに設定されるパラメーターとともにレンダラーに供給される。キーがリリースされると、「！キー押下」イベントがレンダラーに供給される。キーが拡張された期間押下されるなら、「長いキー押下」イベントがレンダラーに供給される。リリースすると、「！長いキー押下」と「！キー押下」イベントはレンダラーに供給される。
【００３０】
ソフトウエアが開始されるときはいつも、ソフトウエアは以下の行動を実行する。
【００３１】
中断された更新処理をチェックし、継続する。（ある他の手段によりファイルシステムにあらかじめ供給されるまたはインストールされる）ファイルシステム内に存在する更新をチェックし、処理する。知られているなら、（最後の実行トリグであってもよい）現在のトリグを開始する。現在のトリグが設定されていないなら、「デフォルト」トリグとしてフラッグが立てられたトリグは、開始することができる。デフォルトトリグの存在に失敗すると、名前の英字順による最初の有効なトリグは選択されるであろう。
【００３２】
トリグは、定義されたリソース名、開始／デフォルトをロードすることにより開始される。開始／デフォルトにおいて定義されたＴｒｉｇＭＬは、コンテンツルートノードのための新しいコンテンツとして解析される。
【００３３】
最初に、インストールに続いてソフトウエアによりトリグが実行されるときに、トリグは、開始／最初の名前というリソース名をローディングすることにより開始される。ソフトウエアは、そのトリグのための上位レベルのフォルダー内に位置されるファイル内で実行されたか否かを記録してもよい。移動装置に使用されるプラットホームに応じて、ソフトウエアの自動起動は、構築時間構成オプションとして設定してもよい。自動開始に続いて、ソフトウエアをバックグラウンドにセットすることはまた構築時間構成オプションであってもよい。
【００３４】
アプリケーションアイコンとしてランチャーがユーザーに現れてもよい。アプリケーションアイコンを選択すると、そのランチャーにより指定されたトリグを有したソフトウエアを開始する（このトリグは、ランチャーアイコンおよび／または名前により示してもよい）。トリグを開始するためにランチャーを使用すると、「エントリポイント」パラメーターを指定することが可能である。パラメーターは、「開始フォルダー」内で発見されたファイルのリソース名である。トリグが以前に実行されていないならこのファイルは使用されない。この場合、「最初の時間」と呼ばれるファイルがそのかわりに使用される。
【００３５】
ソフトウエアは、装置上の仮想ファイルシステムに記憶されたコンテンツリソースファイルを使用する。ファイルシステムは、古典的なファイルシステムとして実施されないかもしれないので、ファイルシステムは仮想として記載される。しかしながら、リソースへのすべてのリファレンスは、あたかもフォルダーおよびファイルの階層制システムに記憶されたかのようにファイルパスである。
【００３６】
この発明の一実施形態のためのファイルシステムの構成に関する詳細は、以下の付録Ａで与えられる。さらにソフトウエアは、以下の情報のいくつかまたはすべてを記憶する。
【００３７】
使用統計値；アクティブユーザーカウント；ＴｒｉｇＭａｎａｇｅｒ状態；ＴｒｉｇＭＬフラグメント＆更新チャネル定義（バイナリＸＭＬとして順番に並べられる）ＰＮＧイメージ；ＵＴＦ−８  ＯＴＡとして符号化されプラットホーム固有の符号化に記憶される平文；他のプラットホーム固有のリソース、例えば、リングトーンファイル、バックグラウンドイメージ等。
【００３８】
アクター属性値が変化するときまたはファイルがトリグレットにより交換されるとき、ファイルシステム内のファイルは変更することができる。／ａｔｔｒｓディレクトリー内のファイルが変化するとき、レンダラーは迅速に通知され、コンテンツツリーの関連するブランチは更新されリフレッシュされる。イメージおよびテキストリソースが変更されると、レンダラーは、影響されたリソースが迅速にリロードされるかのように行動する（全体のコンテンツツリーまたはちょうど影響されたブランチがリフレッシュされてもよい）。ＴｒｉｇＭＬフラグメントが変更されると、レンダラーは、あたかも通知されておらず、現在の、おそらく、期限を経過したコンテンツを表示し続けるように動作する。これは、現在のコンテンツの＜include＞エレメントと<load>ヒストリーを主張する必要があるソフトウエアを回避することである。
【００３９】
ソフトウエア４００は、装置固有の方法で移動装置に供給される。１つ以上のトリグは、インストレーションの一部として供給することができる。例えば、圧縮されていない更新パケットとして記憶することができる。開始時に、パケットは、ファイルシステムに拡張し、インストールすることができる。
【００４０】
アクター４４５は、属性値を発行し、処理してイベントを発行するコンポーネントである。アクターは、レンダラーと同期的に通信する。アクターが非同期の動作を必要とするなら、レンダラーのメインスレッド外部のスレッドを管理して通信することはアクターの責任である。
【００４１】
アクター属性はファイルリファレンスとして読んでもよい。
【００４２】
属性は４つのタイプの１つである。単一の簡単な値；単純な値のベクトル；フィールドの単一の構造であって、各フィールドは簡単な値を有する；または構造のベクトルである。属性は、多くのオブジェクト指向プログラミング言語に類似するオブジェクト．メンバー表記を用いた式により参照されてもよい。
【００４３】
<image res="signallevels/{protocol.siginalstrength}"/>
ファイルとして必要であるとき、属性は、／ａｔｔｒｓフォルダーを介してアクセスされる。
【００４４】
<text res="/attr/network/name">
アクターは、＜ｔｈｒｏｗ＞エレメントを有したイベントをアクターに送ることによりメッセージを受け取ることができる。アクターにより発行されるイベントは、コンテンツイベントとしてコンテンツツリーに供給することができる。これらは、エレメントＩｄまたは「トップ」を目標とすることができる。アクターへのインターフェースは、アクターインターフェース定義ファイルにより定義される。これは、属性、タイプ、ファイル名、イベント入力およびパラメーター、およびイベント出力を定義するＸＭＬドキュメントである。アクターのセットは、ソフトウエアの構築時に構成可能である。付録Ｂは、関連する機能または変数と一緒に使用してもよいいくつかのアクターの例示リストを与える。
【００４５】
更新は新しいトリグ（新しいまたは交換ＵＩ）またはトリグレット（既存のトリグへの変更）を備え、ソフトウエアファイルシステムへの変更とみなされてもよい。更新マネージャーは、パケットを読むことによりファイルシステムにおいて変更する必要があるものを決定しなければならない。更新パケットは、ＨＴＴＰ、または装置固有のパッケージフォーマットでラップされたまたはソフトウエア自体のインストレーションであらかじめ供給された他の適切なトランスポート機構を用いて、ソフトウエア４００により無線でダウンロードしてもよい。
【００４６】
更新は多数の手段によりトリガーされてもよい。多数の手段は以下を含む。
【００４７】
・開始時に中断された更新処理をチェックするソフトウエア
・開始時にあらかじめインストールされた更新パケットをチェックするソフトウエア
・更新チャネルにより構成される自動的に
・ユーザー開始
・特別なＳＭＳを受信する装置
移動装置のユーザーインターフェースを成功裏に提供するためにマークアップ言語は以下の品質を有さなければならない。すなわち、簡潔なページ定義、一貫したレイアウト規則、コンパクトなレンダラーで実施可能である、複数のレイヤリングおよび任意のオーバーラッピングコンテンツ、イベントモデル、ＵＩのページ間で変更しなければならないディスプレイの領域のみの塗りなおしを必要とする、特性値受信イベントおよび送信イベントを読むためのプラットホームへのフックを含む、拡張可能であり、および図形的に柔軟性があるである。ＴｒｉｇＭＬはこれらの特徴を提供する。また、付録Ｃは、所望の機能性を提供する要素および属性の概観を提示する。
【００４８】
ＵＩｓを再ブランド化し、更新の連続的なストリームを生成するコストは最小であることが好ましい。これは、クリエイティブプロセス(creative process)からユーザーへのデータの送信までの情報の効率的な流れを供給することにより可能となる。
【００４９】
小包と呼ばれるコンテナは、第三者の関与のためのＵＩｓ、ＵＩ更新、およびテンプレートのために使用される。小包は、第三者がブランド化されたＵＩｓおよび更新を生成し、試験し、供給するのに必要なすべての情報を含む。図４は、スクリプト記述環境２２０、試験およびシミュレーション環境２３０、およびメインテナンス環境２４０を備えたコンテンツツールセット２００の概略描写を示す。
【００５０】
小包プロセスは５つの処理ステージを備える。
【００５１】
１）  スクリプト記述環境２２０は、１つ以上のＵＩｓのためのテンプレートおよびそのテンプレートに基づいてＵＩｓのための更新戦略を設計するための手段を供給する。
【００５２】
２）メインテナンス環境２４０は、コンテンツプロバイダーにアウトソーシングできるよく制御されたおよび案内された環境において迅速なＵＩと更新生成を供給する。
【００５３】
３）メインテナンス環境２４０「プリフライト(pre-flight)」機能性は、配置アドミニストレーターが、第三者から受信するＵＩｓおよび更新をチェックして同調することを可能にする。  
４）  パブリッシングコンポーネント１１０は、新しいリリースのステージング(staging)を含む配置ポイントにおいてＵＩｓの管理と更新を提供する。
【００５４】
５）  パブリッシングコンポーネント１１０は生のコンテンツフィードからの更新の自動発生を可能にする。
【００５５】
多くの異なるＵＩｓは共通ベースから導き出すことができる。典型的に、共通ベースはほとんどのインターフェース自体を実施するであろう。そしてそれから導き出されるトリグは、それにブランド化のような小さな変更を実施するであろう。トリグレットはトリグから導き出すことができる。そして、トリグレットは、トリグレットが選択する親のトリグからのリソースのいずれかを優先させることができる（状況に応じてトリグレットは、トリグレットの独自のリソースを導入してもよい）。ここでの「リソース」は、またＴｒｉｇＭＬを指し、従ってトリグの行動およびレイアウトは、トリグレットが単一のイメージまたはテキストの一部を交換するのと同じ容易さでトリグレットにより変更することができる。
【００５６】
小包は、１つ以上のトリグ（すなわち、任意の他のトリグから導き出されないトリグ）、ベーストリグから導き出される１つ以上の複数のトリグ、トリグのいずれかから導き出される複数のトリグレット、および他のトリグレットから導き出される複数のトリグレットを備えていてもよい。
【００５７】
図５はこの発明の一実施形態に従うユーザーインターフェースを備える装置８００の概略描画を示す。この装置は、ユーザーインターフェース８１５を表示するディスプレイ８１０と、ユーザーがユーザーインタフェース８１５と相互に作用することを可能にするユーザーインターフェース手段８２０を備える。プロセッサー８３０は、１つ以上の記憶手段８４０内に記憶されるソフトウエアを実行し、他の装置および／または通信ネットワークと通信を可能にするために１つ以上の無線通信インターフェース８５０を設けてもよい。装置に電力を供給するために、１つ以上のバッテリー８６０を受け入れてもよい。また、装置は、電力および／または通信ケーブルを受け入れるためのインターフェースを備えていてもよい。
【００５８】
これらのコンポーネントとインターフェースの性質は、装置の性質に依存するであろう。そのようなユーザーインターフェースは、モバイルまたは携帯電話ハンドセット内で実施することができるが、デジタルカメラ、パーソナルデジタルミュージックプレイヤー、ＧＰＳナビゲーター、ポータブルゲームコンソール等のような他のポータブル装置にも適用可能であることは理解されるであろう。更に、それは、また、ラップトップまたはデスクトップコンピューターのようなユーザーインターフェースを含む他の装置に適用可能である。
【００５９】
ユーザーインターフェース手段は、数字または英数字キーパッドまたはタッチスクリーンまたは類似のもののような複数のボタンを備えていてもよい。１つ以上の記憶装置は、電力が失われたとしても記憶されたデータが失われないように、メモリカードのような、不揮発性メモリの形態を備えていてもよい。更新または変更を必要としないデータを記憶するためにＲＯＭ記憶手段を備えてもよい。頻繁にアクセスされるデータをキャッシングするのをサポートする高速応答時間として一次記憶のためにいくつかのＲＡＭを設けてもよい。また、装置は、ユーザーが脱着可能なメモリカードを受け入れてもよく、状況に応じてハードディスクドライブを記憶手段として使用してもよい。使用される記憶手段は、装置サイズ、電力消費、必要とされる記憶装置のボリューム等の異なる要件をバランスすることにより決定されるであろう。
【００６０】
そのような装置は、仮想的に任意の無線通信ネットワークとともに実施してもよい。例えば、第２世代デジタル携帯電話ネットワーク（すなわち、ＧＳＭ(登録商標）、Ｄ−ＡＭＰＳ）、いわゆる２．５Ｇネットワーク（すなわち、ＧＰＲＳ、ＨＳＣＳＤ、ＥＤＧＥ）、第三世代ＷＣＤＭＡまたはＣＤＭＡ−２０００ネットワークおよびこれらおよび類似のものに対する改良と派生物である。ビルディングとキャンパス内では、（無線または光学システムに基づくかどうかに関わらず）Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩｒＤａまたは無線ＬＡＮも使用してもよい。ＵＳＢおよび／またはＦｉｒｅＷｉｒｅ連結性は、他の装置とのデータ同期および／またはバッテリーの充電のために供給されてもよい。
【００６１】
方法を実施するためのコンピューターソフトウエアおよび／または上述した装置を構成するためのコンピューターソフトウエアはフロッピー（登録商標）ディスク、ＣＤ−ＲＯＭｓ、ＤＶＤｓ、不揮発性メモリカード等のようなデータキャリア上に設けてもよい。
【００６２】
この出願は２００４年２月１９日に出願された英国特許出願番号０４０３７．９の利益を請求する。その出願の内容は参照することにより本明細書に組み込まれる。
【００６３】
【表１−１】
2011248909.tif 000003
【表１−２】
2011248909.tif 000004
【表２−１】
2011248909.tif 000005
【表２−２】
2011248909.tif 000006
【表３−１】
2011248909.tif 000007
【表３−２】
2011248909.tif 000008
【表３−３】
2011248909.tif 000009
【表３−４】
2011248909.tif 000010
【表３−５】
2011248909.tif 000011
【表３−６】
2011248909.tif 000012
【表３−７】
2011248909.tif 000013
【表３−８】
2011248909.tif 000014
【表３−９】
2011248909.tif 000015
【表３−１０】
2011248909.tif 000016
【表３−１１】
2011248909.tif 000017
【表３−１２】
2011248909.tif 000018
【表３−１３】
2011248909.tif 000019
【表３−１４】
2011248909.tif 000020
【表３−１５】
2011248909.tif 000021
【表３−１６】
2011248909.tif 000022
【表３−１７】
2011248909.tif 000023
【表３−１８】
2011248909.tif 000024
【表３−１９】
2011248909.tif 000025
【表３−２０】
2011248909.tif 000026
【表３−２１】
2011248909.tif 000027
【表３−２２】
2011248909.tif 000028
【表３−２３】
2011248909.tif 000029
【表３−２４】
2011248909.tif 000030
【図１】
2011248909.tif 000031
【図２】
2011248909.tif 000032
【図３】
2011248909.tif 000033
【図４】
2011248909.tif 000034
【図５】
2011248909.tif 000035
【手続補正書】
【提出日】平成23年8月1日(2011.8.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
装置に関するユーザインタフェースをレンダリングする方法において、
複数のアクタを供給するステップと、ここにおいて、前記複数のアクターの各々は、それぞれのユーザインタフェースエレメントに関連し、前記それぞれのアクターの外観と機能性を定義する１つ以上の属性を備え、前記アクタ属性の各々はマークアップ言語を備える、
前記複数のアクタの１つまたは複数から１つまたは複数の属性を受信するためのレンダラを供給するステップと、
前記受信したアクタ属性に従って単独で前記ユーザインタフェースをレンダリングするステップと、
を備え、
属性値が変化すると、前記レンダラに通知され、それに従って前記ユーザインターフェースはリフレッシュされる、方法。
【請求項２】
アクタ属性が更新されるなら、前記更新は前記レンダラにより受信され、前記ユーザインタフェースはそれに従って更新される、請求項１の方法。
【請求項３】
前記アクタ属性はユーザ更新に応答して更新される、請求項２の方法。
【請求項４】
前記属性の更新はユーザインタフェースエレメントのフォーマッティングを変化させる、請求項２の方法。
【請求項５】
前記属性の更新は、ユーザインタフェースエレメントを前記ユーザインタフェース内で移動させる、請求項２の方法。
【請求項６】
前記レンダラはマークアップ言語レンダラである、請求項１乃至５のいずれかの方法。
【請求項７】
請求項１乃至６のいずれかの方法を実行するためのコンピュータ実行可能コードを備えたデータキャリア。
【請求項８】
ユーザインタフェースを備えた装置であって、前記ユーザインタフェースは、
１つまたは複数のユーザインタフェースエレメントと、
複数のアクタと、ここにおいて、前記複数のアクタの各々はそれぞれのユーザインタフェースエレメントに関連し、前記それぞれの外観と機能性を定義する１つ以上の属性を備え、前記アクター属性の各々はマークアップ言語を備える、
レンダラと、ここにおいて、前記レンダラは使用時に前記複数のアクタの１つまたは複数に関連した属性を解釈し、前記アクタ属性に従って単独で前記ユーザインタフェースをレンダするように構成される、
を具備し、
属性値が変化すると、前記レンダラに通知され、それに従って前記ユーザインタフェースはリフレッシュされる、装置。
【請求項９】
前記装置は、前記ユーザインタフェースを表示するための表示手段をさらに備えた、請求項８の装置。
【請求項１０】
前記装置は、前記ユーザインタフェースのレンダリングに使用するためにさらなるアクタを受信するための通信インタフェースをさらに備えた、請求項８または９の装置。
【請求項１１】
前記装置は、前記複数のアクタを記憶するように構成された記憶装置手段をさらに備えた、請求項８乃至１０のいずれかの装置。
【請求項１２】
前記装置は、前記レンダラを動作させるように構成された処理手段をさらに備えた、請求項８乃至１１のいずれかの装置。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００６２
【補正方法】変更
【補正の内容】
【００６２】
この出願は２００４年２月１９日に出願された英国特許出願番号０４０３７．９の利益を請求する。その出願の内容は参照することにより本明細書に組み込まれる。
以下に他の実施形態を示す。
［１］装置のためのユーザーインターフェースをレンダリングする方法において、
複数のアクターを供給するステップであって、複数のアクターの各々は、ユーザーインターフェースエレメントに関連し、それぞれのアクターを定義する１つ以上の属性を備えるステップと、
複数のアクターの１つ以上から１つ以上の属性を受信するためにレンダラーを供給するステップと、および
受信した属性に従ってユーザーインターフェースをレンダリングするステップと、
を備えた方法。
［２］アクター属性が更新されるなら、前記更新は、前記レンダラーにより受信され、前記ユーザーインターフェースはそれに従って更新される［１］の方法。
［３］アクター属性はユーザー更新に応答して更新される［２］の方法。
［４］属性の前記更新は、ユーザーインターフェースエレメントのフォーマッティングを変化させる［２］の方法。
［５］属性の前記更新は、ユーザーインターフェースエレメントを前記ユーザーインターフェース内で移動させる［２］の方法。
［６］前記アクター属性は、マークアップ言語を備え、前記レンダラーは、マークアップ言語レンダラーである［１］乃至［５］のいずれかの方法。
［７］［１］乃至［６］のいずれかの方法を実行するためのコンピューター実行可能コードを備えたデータキャリア。
［８］１つ以上のユーザーインターフェースエレメントを備えたユーザーインターフェースと、
各々がユーザーインターフェースエレメントに関連し、１つ以上の属性を備えた複数のアクターと、
使用時に前記複数のアクターの１つ以上と関連する属性を解釈し、それに従って前記ユーザーインターフェースを描画するように構成されたレンダラーと、
を備えた装置。
［９］前記装置は、さらに前記ユーザーインターフェースを表示するための表示手段を備える［８］の装置。
［１０］前記装置は、さらに前記ユーザーインターフェースのレンダリングに使用するためのさらなるアクターを受信するための通信インターフェースを備えた［９］の装置。
［１１］前記装置はさらに、前記複数のアクターを記憶するように構成された記憶装置手段を備えた［８］乃至［１０］のいずれかの方法。
［１２］前記装置は、前記レンダラーを動作するように構成された処理手段をさらに備えた［８］乃至［１１］のいずれかの方法。
【外国語明細書】
2011248909000001.pdf