JP2007535025A - バーチャル・ファイル・システム - Google Patents

Abstract

【課題】バーチャル・ファイル・システム。
【解決手段】バーチャル・ファイル・システムが、説明され、これは、１つのルートを経由してアクセスされるように、コンテント・ファイルのようなリアル・データ・リソース及びバーチャル・データ・リソース、例えば、データベース内部のフィールド又はマークアップ言語エレメントによって決定される状態、の両者をイネーブルする。
【選択図】図３

Description

本発明は、バーチャル・ファイル・システムに係り、そして特に移動体通信ネットワークで使用するための移動デバイスのためのバーチャル・ファイル・システムに関する。

移動体ネットワーク・オペレータ及びコンテント・プロバイダに関する成長分野の１つは、移動電話機及び移動デバイスのための呼出音（ringtones）、壁紙、及びその他のマルチメディア・コンテントの供給である。印象付ける目的（branding purpose）でデバイス・ユーザ・インターフェースのある種の態様を通して制御を維持するために移動体ネットワーク・オペレータ及びデバイス製造者のニーズと、ユーザ自身のニーズに合わせるためにそれらのデバイスの外観をカスタマイズするため及び変更するためのユーザのニーズとの間に対立がある。所望の自由度及びカスタマイゼーションを与えるために必要とされる高性能なソフトウェアは、同様に、一般的な移動デバイスの限られた処理能力及びデータ記憶容量と対立する。本発明は、これらの問題を軽減することを得ようとしている。

［発明のサマリー］
本発明の第１の態様によれば、複数のデータ・リソースを記憶するための記憶手段、該記憶手段中に記憶された該複数のデータ・リソースを体系化するためのファイル・システム、及び該複数のデータ・リソースにユーザ・アクセスを提供するためのユーザ・インターフェースを具備するデバイスが提供され、ここにおいて、該ファイル・システムは、直接アドレス可能なデータ・リソースを備える１又はそれより多くのロケーション及び間接的にアドレス可能なデータ・リソースを備える１又はそれより多くのロケーションを備える１又はそれより多くのロケーションを具備し、該間接的にアドレス可能なデータ・リソースはデータ・プロバイダを経由してアドレス可能であり、使用時に該ユーザ・インターフェースから直接アドレス可能なデータ・リソース及び間接的にアドレス可能なデータ・リソースの両者に１つのインターフェースを与えるために構成される。

該直接アドレス可能なデータ・リソースは、使用時に、該ユーザ・インターフェース内に表示されるデータ・コンテント・ファイルを具備できる。該間接的にアドレス可能なデータ・リソースは、データベースを具備でき、そして使用時に、１又はそれより多くの問い合わせの結果が該ユーザ・インターフェース内に表示される。さらに、該間接的にアドレス可能なデータ・リソースは、マークアップ言語エレメントを具備し、そして使用時に、該マークアップ言語エレメントはレンダされ（rendered：解釈され）、そして該関係する結果が該ユーザ・インターフェース内に表示される。

本発明の第２の態様によれば、デバイスのファイル・システム内部に複数のデータ・リソースを記憶するための方法が提供され、該方法は：１つの直接アドレス可能なデータ・リソースを具備する１又はそれより多くのロケーションを定義すること；間接的にアドレス可能なデータ・リソースを具備する１又はそれより多くのロケーションを定義すること、該間接的にアドレス可能なデータ・リソースはデータ・プロバイダを経由してアクセス可能である；ここにおいて、ファイル・システムは、該ユーザ・インターフェースから該直接アドレス可能なデータ・リソース及び該間接的にアドレス可能なデータ・リソース・アクセスの両者をアクセスするために１つのインターフェースを与える、ステップを具備する。

本発明の第３の態様によれば、上記の（複数の）方法を実行するためのコンピュータ実行可能なコードを具備するデータ・キャリアが、提供される。

［詳細な説明］
本発明は、説明のためにのみ及び添付した図面に関してここに記述され、ここでは、図１は、本発明を組み込んでいるシステムの概略図を示す。本システムは、サーバ１００、コンテント・ツールセット２００、移動デバイス３００、動作上のサポート・システム（ＯＳＳｓ：operational support systems）７００、コンテント・フィーダ５００及びユーザ・インターフェース（ＵＩ：user interface）ソース６００を具備する。使用において、サーバ１００は、移動デバイス３００，３０１，．．．にコンテント・データ及びＵＩデータを伝達し、移動デバイスの各々は、ソフトウェア・パッケージ４００を具備する。サーバ１００は、ＯＳＳ７００を用いてインターフェースし、移動体ネットワークを動作させるために普通に使用されるＯＳＳ、例えば、請求書発行、アカウント管理、等、を用いてインターフェースする。サーバ１００は、コンテント・ツールセット２００を用いてさらにインターフェースし：コンテント・ツールセットは、複数のＵＩソース６００，６０１，．．．からデータを受け取り、そしてＵＩデータをパッケージにする。その結果、サーバは、移動デバイス３００の内部に備えられたソフトウェア・パッケージ４００にパッケージされたＵＩデータを送信できる。サーバは、複数のコンテント・フィーダからデータを受け取り、そしてこのデータは、処理されそしてパッケージされ、その結果、データは、ソフトウェア・パッケージ４００に送られることができる、若しくは移動デバイス３００がソフトウェア・パッケージ４００を使用してデータをアクセスできる。

システムは、３個の別々のドメインに分割されているとして認識されることができ：オペレータ・ドメイン５０は、移動体ネットワーク・オペレータ（ＭＮＯ：mobile network operator）によって管理されるシステム及び設備を備え；ユーザ・ドメイン６０は、複数の移動デバイスを備え；そしてサード・パーティ・ドメイン７０は、多数の異なるエンティティによって制御される又は管理されることができるコンテント・フィード及びＵＩフィードを備える。

図２は、サーバ１００の構造及び動作を非常に詳細に図示する。サーバ１００は、パブリッシング・コンポーネント１１０及びコンテント・サーバ・コンポーネント１５０を具備する。パブリッシング・コンポーネントは、データベース１１１、インポート・キュー１１２、コンテント・ツールセット・インターフェース１１３、ユーザ・インターフェース１１４及びカタログ１１５を備える。動作の際に、パブリッシング・コンポーネントは、コンテント・ツールセット・インターフェースにおいてコンテント・ツールセットからコンテントを受け取る。コンテントは、１又はそれより多くのＴｒｉｇ及び１又はそれより多くのＴｒｉｇｌｅｔを備えるパーセル２１０ａ，２１０ｂ，．．．（下記参照）の形式で与えられる。トリグ（trig）は、携帯電話機のような、移動デバイスに対するユーザ・インターフェースであり、そしてトリグレット（triglet）は、トリグを拡張するため又は変更するために使用されることができるデータ・ファイルである。もしパーセルが１又はそれより多くのトリグを備えるのであれば、Ｔｒｉｇの１つは、マスタ・トリグであることがあり、それから別のＴｒｉｇが導き出される。

パブリッシング・コンポーネント・ユーザ・インターフェース１１４は、データベース１１１の中にパーセルをインポートするために使用されることができ、そしてこの処理は、インポート・キュー１１４の中にロードされようとしている各トリグ及びトリグレットに参照符号を生じさせる。インポート・キューは、複数のパーセル２１０ａ，２１０ｂ，．．．に対する参照符号を備えることができる。パーセルのコンテントは、ユーザ・インターフェースを使用して検査されることができ、そしてパーセルのコンテントは、カタログに渡されることができる。

図３は、移動デバイス３００のためのソフトウェア４００の概略図を示し、ソフトウェア４００は、マークアップ言語レンダラ（renderer：描画機）４１０、更新マネージャ４２０、ネットワーク通信エージェント４２５、リソース・マネージャ４３０、バーチャル・ファイル・システム４３５、アクタ（actor）・マネージャ４４０、複数のアクタ４４５ａ，４４５，．．．，ネーティブＵＩレンダラ４５０、サポート・マネージャ４６０、トリグ・マネージャ４６５、及びマークアップ言語パーサ４７０を備える。

ソフトウェアがＴｒｉｇＭＬを使用して管理することが好ましく、ＴｒｉｇＭＬは、ＸＭＬアプリケーションであり、そしてそのマークアップ言語レンダラ４１０は、移動デバイス３００に表示するためのＴｒｉｇＸＭＬコードをレンダする（render：解釈する）。マークアップ言語レンダラは、しかも、ＴｒｉｇＭＬリソースを解析するためにＴｒｉｇＭＬ Ｐａｒｓｅｒも使用し、デバイス画面上にコンテントを表示し、そして手持ち機器上のコンテントの交換及び見ることを制御する。ネーティブＵＩレンダラは、ＴｒｉｇＭＬを使用しないで表示されることができるＵＩコンポーネントを表示するために、そしてエラー・メッセージを表示するために使用される。

ソフトウェア４００は、固有の方式でデバイスに与えられそしてインストールされる。例えば、ノキア・シリーズ（Nokia Series）６０デバイスに対して、ソフトウェアは、ＳＩＳファイルを使用してインストールされる、ところが、ＭＳスマートフォン（Smartphone）デバイスに対して、ソフトウェアは、ＣＡＢファイルを使用してインストールされる。同様に、ソフトウェアのアップグレードは、デバイスに固有の方式で取り扱われる。ソフトウェアは、自身に組み込まれたコンテントだけをレンダする組み込み型のアプリケーションとして、より限られたフォーマットで供給されることがある：すなわち、ソフトウェアは、組み込みトリグで供給されるが、追加のトリグは後で追加されることができない。供給されたトリグは、無線を介してアップグレードされることができる。

トリグ・マネージャ４６５は、リソース・マネージャ４３０及びマークアップ言語レンダラへのインターフェースを与える。これは、一般にトリグ管理に対して責任がある。これは、下記のように終わる：使用中のトリグの知識を保存すること、現在のトリグを変更すること、始動時にトリグの選択、破壊トリグの代替としてさらなるトリグの選択、インストールされたトリグのセットを維持管理すること、リソース・マネージャのどの場所に特定のトリグがインストールされたかを識別すること、及びトリグの更新チャネル定義を読み出すことそして更新マネージャを適切に構成すること。

リソース・マネージャは、デバイス上の永続的な記憶の分離（abstraction）を与える、すなわち、リアル・ファイルとして、又はデータベース中にレコードとしてファイルを記憶する。リソース・マネージャは、マークアップ言語レンダラ及び更新マネージャへのファイル・システム・インターフェースを与える。これは、ファイル・パス論理を取り扱うこと、リアル・リソース・ファイルとアクタ属性との間を識別すること、絶対パス上にトリグ相対パスをマッピングすること、トリグ・マネージャをインターフェースすること、そして更新マネージャに修正インターフェースを与えること、に対して責任がある。

Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｒ（リソース・マネージャ）は、同様に、特に、電源の停電のような予測されない中断があっても、永続性の記憶装置に記憶されたリソースの完全性を補償する責任がある。Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｒは、現在使用されているトリグの知識を持たない。（Ｕｐｄａｔｅ Ｍａｎａｇｅｒ（更新マネージャ）及び別のスレッド（thread）からのＲｅｎｄｅｒｅｒ（レンダラ）の両者によって使用されことができるので）そのインターフェースは、スレッド・セーフ（thread safe）である。

Ｕｐｄａｔｅ Ｍａｎａｇｅｒは、Ｔｒｉｇ及びＴｒｉｇｌｅｔの受領及びアプリケーションを取り扱う。Ｕｐｄａｔｅ Ｍａｎａｇｅｒは、Ｒｅｎｄｅｒｅｒ及びトリグＭａｎａｇｅｒへのインターフェースを与え、そして：Ｒｅｎｄｅｒｅｒによって指示された時に手動更新の開始；トリグ・マネージャによって自動更新に設定された時に自動更新チャネルを制御すること及び実行すること；手動更新の進行を指示しそして予期しないネットワーク接続の切断及び／又はデバイス電源の停電に続くＵｐｄａｔｅ（更新）を回復させること、に対して責任がある。更新パケット・フォーマットは、ＸＭＬスキームをバイナリの順番に配列させることとして定義されることができる。

Ｓｕｐｐｏｒｔ Ｍａｎａｇｅｒ（サポート・マネージャ）は、その他のコンポーネントに対するインターフェースを与え、イベント又はエラーの発生を報告する。エラーの重大性に応じて、Ｓｕｐｐｏｒｔ Ｍａｎａｇｅｒは、イベントをログする及び／又はエラー・メッセージ・ポップアップを表示する。

ＸＭＬは、ＴｒｉｇＭＬコンテントと同様に更新パケット・フォーマットを定義するために使用される便利なデータ・フォーマッティング言語である。バンド幅及び記憶効率の理由で、テキストＸＭＬは、バイナリ表記に順番に配列される。更新パケット及びＴｒｉｇＭＬフラグメントの両者は、同じコンポーネント、マークアップ言語パーサによって解析される。ソフトウェアにおけるＸＭＬのいずれかのさらなる使用は、バイナリＸＭＬエンコーディングを使用しなければならず、そしてしたがってパーサを再使用する。

Ａｃｔｏｒ Ｍａｎａｇｅｒ（アクタ・マネージャ）４４０は、ソフトウェア中に存在するアクタ４４５のセットを管理する。これは、コンテントがアクタにイベントを送っている時にレンダラによって；属性値が変更されたことを通知しようと望んでいるアクタによって；そしてイベントを発行しようと望んでいるアクタ（下記参照）によって、使用される。

ソフトウェアは、どれだけの数のアクタがそしてどのような種類のアクタが含まれているかに依存して可能な限り多く、最小２つのスレッド（thread）をランさせる多重スレッド化されたアプリケーションを備えられる。ソフトウェアは、主スレッドと呼ばれる１つのスレッドにおいて多くの場合ランする。主スレッドは、その他のコンポーネントと同期的に通信するレンダラをランさせるために使用される。アクタは、常にレンダラへの同期的インターフェースを有する。もし、アクタが自身の機能性のために追加のスレッドを必要とするのであれば、スレッド間通信を管理することは、Ａｃｔｏｒの責任である。複数のアクタがスレッド間通信を必要とする場合に軽いメッセージング・フレームワークが不必要なコード重複を回避するために使用されることが、好ましい。

主スレッドに加えて、更新マネージャは、ネットワーク・スレッドをランさせる。ネットワーク・スレッドは、更新パケットをダウンロードするために使用され、そしてパケットが到着するまでレンダラが影響されずに継続することを可能にするために主スレッドから分離される。Ｕｐｄａｔｅ Ｍａｎａｇｅｒは、スレッド間メッセージングを取り扱う責任があり、その結果、Ｕｐｄａｔｅ Ｐａｃｋｅｔ（更新パケット）中に規定された変更を適用する際に、Ｕｐｄａｔｅ ＭａｎａｇｅｒはＲｅｎｄｅｒｅｒ及びＲｅｓｏｕｒｃｅ Ｍａｎａｇｅｒと同期して通信する。

ソフトウェアのメモリ割当て方針（strategy）は、プラットフォームに特有である。ＭＩＤＰプラットフォーム上では、ソフトウェアは、全ての自身のメモリ要求のためにシステム・ヒープ（system heap）及びガーベッジ・コレクタ（garbage collector）を単に使用する。動作においてガーベッジ・コレクションが予測可能でありそして予期されない一時停止の影響を受けないようにするためのアテンプトにおいてコンテント交換イベントが発生する時はいつでも、ガーベッジ・コレクションは、強制的に行われる。どんなメモリ割当ても失敗するであろうことが仮定され、その場合には、ソフトウェアは、オブジェクトに対する全ての自身の参照符号を消去し、ガーベッジ・コレクションを行い、そして、ソフトウェアが既に良好にスタート・アップされそして最初のページをレンダしていることを仮定して−再始動する。

Ｃ＋＋ベースのプラットフォーム上では、事前割当てとオンデマンド方式の割当てとの混ぜ合せられたものは、システム・ヒープから行われる。スタート・アップのために必要な全てのメモリは、スタート・アップの間にオンデマンド方式で割り当てられ、ここでのいずれかの不具合はソフトウェアの（可能であるならばメッセージとともに）終了を生じさせる。良好なスタート・アップに引き続いて、コンテント・ドキュメント・モデルをレンダするために必要なメモリは、事前に割り当てられる。提供されるコンテントは、規定された制限より少なく使用するように作られ（author）、これはレンダすることを保証されている。付加的な使用は、ソフトウェアの高速動作のために必要な種々のキャッシュのためにＲＡＭから形成される。メモリの状態が低い場合には、これらのキャッシュは、ソフトウェアからの遅いレンダリング性能に結果としてなるように解放される。

ソフトウェアの通常の動作を中断させるに十分な程度に重大なエラーは、結果としてポップアップ・ダイアログ・ボックスになる必要がある。ダイアログ・ボックスは、少数の国際化されたエラー・メッセージの１つを含む（これらのストリングの国際化された版は、デバイス上に直接関係する言語を設定することによって決定されるように、表示するエラー・ストリングの版とともに構成時にソフトウェア中にコンパイルされることができる）。メッセージの数を最小に保つために、少数の一般的な問題だけが扱われる。

サポート状況を考慮して、エラー・ダイアログは、しかも、４−ディジット（１６−ビット）の１６進法ストリングとしてエラー・コードを表示する。各エラー・コードは、ソフトウェアについての問題の本質を決定するためにサポート・スタッフによって使用されることができる説明テキストに関係付けられる。ソフトウェア中で生じそしてその動作を停止するほど重要でないエラーは、Ｓｕｐｐｏｒｔ Ｍａｎａｇｅｒコンポーネントによってログされることができる。Ｓｕｐｐｏｒｔ Ｍａｎａｇｅｒは、ユーザが固有のキー・シーケンスをタイプすることによって問い合わせられることができる。Ｓｕｐｐｏｒｔ Ｍａｎａｇｅｒは、しかも、ＨＴＴＰ ＧＥＴ又はＰＯＳＴ法を介してサーバにそのエラー・ログを供給できる。

Ｒｅｎｄｅｒｅｒは、キーを押すことに関する情報を受け取る。キーに対して構成時に何の動作も設定されていないのであれば、現在の注目しているエレメント（element）にＴｒｉｇＭＬコンテント・イベントとして送られる。コンテント・イベントは、その後、ＴｒｉｇＭＬの通常のイベント処理論理によって定義されるように取り扱われる。

例えば、キーが下に押された場合に、‘ｋｅｙｐｒｅｓｓ’イベントは、それらの直接関係するキーに対するパラメータ・セットとともにＲｅｎｄｅｒｅｒに配信される。キーが解放されると、‘！ｋｅｙｐｒｅｓｓ’イベントが、Ｒｅｎｄｅｒｅｒに配信される。キーが長い時間にわたって押し下げられたままである場合に、‘ｌｏｎｇｋｅｙｐｒｅｓｓ’イベントが、レンダラに配信される。解放されると、‘！ｌｏｎｇｋｅｙｐｒｅｓｓ’及び‘！ｋｅｙｐｒｅｓｓ’イベントの両者が、Ｒｅｎｄｅｒｅｒに配信される。

ソフトウェアが開始される時はいつでも、ソフトウェアは、下記のアクションを実行する：
・中断されたＵｐｄａｔｅ処理を確認し、そして継続する；
・ファイル・システム中に（事前に供給されたか又はある別の手段によってファイル・システムにインストールされたかのいずれかで）常駐するＵｐｄａｔｅを確認し、そして処理する；
・既知である場合に、（最後にランざれたトリグであろう）現在のトリグを開始する；
・現在のトリグが設定されていない場合に、‘デフォルト’トリグとしてフラグを付けられているトリグが、開始されることができる。

・デフォルト・トリグが存在しないと、名前のアルファベット順で最初の有効なトリグが選択される。

トリグは、定義されたリソース名、ｓｔａｒｔ−ｕｐ／ｄｅｆａｕｌｔ、をローディングすることによって開始される。ｓｔａｒｔ−ｕｐ／ｄｅｆａｕｌｔに定義されたＴｒｉｇＭＬは、コンテント・ルート・ノードに対する新たなコンテントとして解析される。

トリグが、そのインストールに引き続いてソフトウェアによってランされる最初の時に、トリグは、リソース名ｓｔａｒｔｕｐ／ｆｉｒｓｔｔｉｍｅをローディングすることによって開始される。ソフトウェアは、トリグがランされているか否かをそのトリグに関する最上位のフォルダ中に置かれたファイルの中に記録できる。移動デバイスによって使用されるプラットフォームに応じて、ソフトウェアの自動スタート・アップは、構成時設定オプションとして設定されることができる。その上、自動−スタートに引き続くバックグラウンド中にソフトウェアを置くことも、同様に、構成時設定オプションであり得る。

ランチャ（launcher）は、アプリケーション・アイコンとしてユーザに見られることがあり、そしてそれを選択することが、そのランチャによって指定されたトリグ（このトリグは、ランチャ・アイコン及び／又はランチャ名によって指示されることができる）を有するソフトウェアを開始する。トリグを開始するためにランチャを使用する時に、‘ｅｎｔｒｙ ｐｏｉｎｔ’パラメータを指定することが可能である。パラメータは、‘ｓｔａｒｔ−ｕｐ’フォルダ中に見つけられたファイルのリソース名である。そのトリグが以前に全くランされていないのであれば、このファイルは使用されない、その場合には、‘ｆｉｒｓｔｔｉｍｅ’と呼ばれるファイルが、その代わりに使用される。

ソフトウェアは、デバイス上のバーチャル・ファイル・システム中に記憶されたコンテント・リソース・ファイルを使用する。ファイル・システムは、古典的なファイル・システムのように与えられることがないのでバーチャルとして説明されるが、複数のリソースに対する全ての参照符号は、フォルダ及びファイルの階層的なシステム中にあたかも記憶されているようなファイル・パスである。

ファイル・システムの配列に関する詳細は、下記の付表Ａ中に与えられる。その上、ソフトウェアは、下記の情報のあるもの又は全てを記憶する；使用統計値；アクティブなユーザ数；ＴｒｉｇＭａｎａｇｅｒ状態；ＴｒｉｇＭＬフラグメント及び更新チャネル定義（バイナリＸＭＬとして順番に配列される）；ＰＮＧイメージ；平易なテキスト、ＵＴＦ−８ ＯＴＡとしてエンコードされそしてその後エンコーディングに特有のプラットフォーム中に記憶される；リソースに特有なその他のプラットフォーム、例えば、呼出音ファイル、バックグランド・イメージ、等。

ファイル・システム中のファイルは、アクタ属性値が変更された時、又はファイルがトリグレットによって置き換えられた時のどちらかで、変更されることができる。／ａｔｔｒｓディレクトリ中のファイルが変更された時、Ｒｅｎｄｅｒｅｒは、直ちに通知されそしてコンテント・ツリーの直接関係するブランチが更新され、リフレッシュされる。イメージ及びテキスト・リソースが変更された時、Ｒｅｎｄｅｒｅｒは、あたかも影響を受けたリソースが、直ちに再ロードされるかのうように振舞う（全体のコンテント・ツリー又は影響を受けたブランチだけのいずれかがリフレッシュされる）。ＴｒｉｇＭＬフラグメントが変更された時に、Ｒｅｎｄｅｒｅｒは、あたかも通知されなかったかのように振舞い、そしてその現在のコンテント、おそらく古いコンテントを表示し続ける。これは、＜ｉｎｃｌｕｄｅ＞エレメント及び現在のコンテントの＜ｌｏａｄ＞履歴を保持することをソフトウェアが必要とすることを回避する。

ソフトウェア４００は、デバイスに特有の方法で移動デバイスに供給される。１又はそれより多くのＴｒｉｇは、例えば、未圧縮の更新パケットとして記憶されたインストールの一部分として供給される。スタート・アップ時に、パケットは、ファイル・システムに拡張されることができそしてインストールされることができる。

Ａｃｔｏｒ４４５は、属性値を発行し、そしてイベントを取り扱いそして放出するコンポーネントである。Ａｃｔｏｒは、同期してＲｅｎｄｅｒｅｒと通信する。アクタが非同期的な振舞いを必要とするのであれば、Ｒｅｎｄｅｒｅｒの主スレッド外部のスレッドを管理しそして通信することは、アクタの責任である。

アクタ属性は、ファイル参照符号として読み出されることができる。属性は、４つのタイプの１つであり：１個の簡単な値；簡単な値のベクトル；フィールドの１つの構造、各フィールドは簡単な値を有する；又は構造のベクトルである。属性は、多くのオブジェクトを指向したプログラミング言語に類似のオブジェクト・メンバー表記を使用する表示によって参照されることができる：
<image res=”signallevels/protocol.signalstrength”/>
ファイルとして必要とされる場合に、属性は、／ａｔｔｒｓフォルダを介してアクセスされる。

<text res=”/attr/network/name”>
Ａｃｔｏｒは、＜ｔｈｒｏｗ＞エレメントを有するイベントにそれを送ることによってメッセージを送ることができる。アクタによって発行されたイベントは、コンテント・イベントとしてコンテント・ツリーに配信されることができる：これらは、エレメントＩｄ又は‘ｔｏｐ’に向けられることができる。アクタへのインターフェースは、Ａｃｔｏｒ Ｉｎｔｅｒｆａｃｅ Ｄｅｆｉｎｉｔｉｏｎ（アクタ・インターフェース定義）ファイルによって意義される。これは、ＸＭＬドキュメントであり、属性、タイプ、フィールド名、入力イベント及びパラメータ、並びに出力イベントを定義する。アクタのセットは、ソフトウェアの構成時に設定可能である。付表Ｂは、関係する関数又は変数とともに使用されることができる複数のアクタの具体例のリスティングを与える。

大部分の移動デバイスに共通する制限の１つは、ディスプレイ画面が極めて小さいことであり、そしてメニューが表示されるときにメニュー項目の全てを同時に画面上に表示できるとは限らないことである。従来のアプローチは、メモリ中に全てのメニュー項目を、関係するアイコン又はグラフィックスとともにロードする傾向があり、そしてそれからユーザがメニューを上又は下にスクロールするにつれて適切にそれらを表示する。

メモリ中にロードされるメニュー項目の数を同時に画面上に表示されることが可能な項目の数の制限する技術が提供される。ユーザがメニューを端から端までスクロールする場合に、もはや表示されない（複数の）項目は破棄され、そして現在表示されている（複数の）項目がメモリ中にロードされる。

好ましくは、これは、ＴｒｉｇＭＬ中の＜ｇｒｉｄｄａｔａ＞エレメントを使用することによって与えられることができ、データがファイル・システム中のフォルダに記憶される複数のデータのリスト・ビューを定義し、そしてリストの体裁は、各項目に対して同じ構造を有する。＜ｇｒｉｄｄａｔａ＞エレメントは、‘ｒｅｐｅａｔ−ｏｖｅｒ’属性を備え、これはデータがその中に置かれることができるフォルダを指定する。＜ｇｒｉｄｄａｔａ＞の１個の子エレメントは、リスト中の各項目の体裁に関するテンプレートである。

テンプレートは、特殊シンボル、例えば、イタレータ（iterator）を参照するための‘＄＄’を使用する。これは、テンプレートが例示される各回毎に変更されるテンプレート変数であり：例えば
<griddata repeatover=”news/headlines”>
<text re=”news/headlines/$$/title.text”/>
</griddata>
ここで、フォルダｎｅｗｓ／ｈｅａｄｌｉｎｅ／は、下記を含む：
0/title.text
1/title.text
2/title.text
3/title.text
これは、４項目のリストを表示するはずであり、それぞれが‘ｎｅｗｓ／ｈｅａｄｌｉｎｅｓ／＄＄’フォルダ中の‘ｔｉｔｌｅ．ｔｅｘｔ’リソースを指している単純な＜ｔｅｘｔ＞エレメントによって記述される。＜ｇｒｉｄｄａｔａ＞エレメントが有する表示のための容量よりソース・データがより多くの項目をその中に有する場合、＜ｇｒｉｄｄａｔａ＞エレメントは、表示されることが可能なそれらの項目を表示するだけである。ユーザがリスト全体をスクロールする場合に、＜ｇｒｉｄｄａｔａ＞エレメントは、それにしたがって‘ｄａｔａ−ｗｉｎｄｏｗ’を移動させる。この技術の利点は、現在の表示によって必要とされるリソースだけを実際にメモリ中にロードすることであり、これは、メモリの利用を削減し、そして項目のリストをレンダするための時間の量を削減する。

類似のスキームは、リストがそこに表示される順番を規定するために使用されることができる。‘ｒｅｐｅａｔ−ｏｖｅｒ’属性の目的物がフォルダの代わりにファイルであるならば、ファイルは、イタレーションに使用するためにリソース名のリストを含むと仮定されることができる。例えば、
<griddata repeatover=”football/league”>
<text res=”football/teams/$$/name.text”/>
</griddata>
ここで、ファイルｆｏｏｔｂａｌｌ／ｌｅａｇｕｅは、下記を含む：
Manchester
Arsenal
Chelsea
フォルダｆｏｏｔｂａｌｌ／ｔｅａｍｓは、下記を含む：
Manchester/name.text
Arsenal/name.text
Chelsea/name.text
そして、各ｎａｍｅ．ｔｅｘｔは、チーム名を保有するテキスト・ファイルである。これの結果は、チームに関係するテスト・ファイルが決められた順番でデバイス・ディスプレイの決められた領域の中で表示されるはずであることである。

ソフトウェアは、バーチャル・ファイル・システム４３５を利用する、これは、従来のファイル・システムがデータの別の形式を組み込みことを可能にし、その結果、バーチャル・ファイル・システムの任意の部分に記憶されたデータが普通の方法でアクセスされることができる。そのようなバーチャル・ファイル・システムの中に統合されることができる従来型でないデータ記憶装置の例は、データベースの内部に記憶されたデータ又はさらに加えられたソフトウェア・コンポーネントによってデマンドがあり次第発生されるデータを含む。

例えば、従来の移動デバイスでは、電池の強度、信号強度、新たなテキスト・メッセージ、等に関する情報は、使用するために示され、そしてこの情報は、一般的にオペレーティング・システムが直接関係するハードウェア・エンティティ又はソフトウェア・エンティティにコールを送り、及び受け取った回答をインタープリットしそしてそれを表示するＵＩにコールを送ることによって得られる。

この情報は、＜ｐｈｏｎｅｓｔａｔｕｓ＞（又は＜ｓｉｇｎａｌｓｔｒｅｎｇｔｈ＞）のようなＴｒｉｇＭＬタグ（下記参照）を使用するＵＩに表示されることができる。このタグをレンダすることは、直接関係するハードウェア・エンティティ又はソフトウェア・エンティティに解放されようとしているリスニング問い合わせを生じさせる。状態の変更が生じるのであれば、ＵＩレンダラは通知され、そしてＵＩレンダラは、状態の変更をユーザに伝達するために直接関係するアイコン又はグラフィックをロードする。ユーザがＵＩ内部のビューを変更するのであれば、タグは、取り消され、そしてリスニング問合せは、終了される。このアプローチは、タグが使用されている時にだけ、リスニング問合せがアクティブであるので、リソース効率がさらに良い。

バーチャル・ファイル・システムは、１つのルートを備え、それはコンテント・ファイル（例えば、テキスト、グラフィックス、ビデオ、オーディオ、等）のような直接アドレス可能なデータ・リソース及びＴｒｉｇＭＬタグ又はデータベース内部に記憶されたデータのような間接的にアドレス可能なデータ・リソースの両者を包含する。これは、ユーザ・インターフェースを経由して一元化されたビューを有するユーザを与える。このユーザ・インターフェースは、ユーザがバーチャル・ファイル・システム内部に保有された別のタイプのデータをアクセスすることを可能にする。別のデータ・タイプがこのようにしてユーザに示されている一方で、データは、効率的なデータ格納及びデータ検索を可能にする方法で今まで通り記憶されることができる。

商業的な理由のために、移動デバイスの画面上に表示されるユーザ・インターフェースを介してＭＮＯｓ及び／又はコンテント・プロバイダがある種の制御を有することができることが望ましい。ユーザが自分のデバイスの外観を変更するためにトリグレット又は新たなトリグをダウンロードすること、そして同様に、使用時にトリグ又はトリグレットによって決定される表示された画像に対してさらなる変更を行うことを認めるある程度の自由度があることも同様に重要である。

この問題は、複数のレベルの各々がＵＩの１又はそれより多くのエンティティを備える複数の階層面からＵＩが形成されることを考慮することによって扱われることができる。ＭＮＯ、デバイス製造者、トリグ・プロバイダ及びデバイス・ユーザに階層を指定することによって、必要なレベルの認可を提供することが可能である。

図５は、４つの階層面４０５ａ−ｄの概略図を示し：面４０５ａは、ＭＮＯによって定義されたＵＩエレメントを備え；面４０５ｂは、デバイス製造者によって定義されたＵＩエレメントを備え；面４０５ｃは、トリグによって定義されたＵＩエレメントを備え；面４０５ｄは、ユーザによって定義されたＵＩエレメントを備える。面４０５ａは、階層体系中で最も高い位置を有し、そして面４０５ｄは、階層体系中で最も低い位置を有する。例えば、面４０５ａ中のｍｎｏ−ｌｏｇｏエレメントは、デバイスのディスプレイ画面上で使用されるグラフィック・エレメント及び自分の位置を定義する。それが階層体系の最も高い面にあるので、それは常に現れ、そしてｍｎｏ＿ｌｏｇｏによって使用される画素を使用しようとするより低い階層のエレメント中のいずれかのその他のＵＩエレメントに対して優先権を持つ。面４０５ｄは、ｂａｃｋｇｒｏｕｎｄｃｏｌｏｕｒ（背景カラー）エレメントを備え、これは、その他の面のいずれの中にも定義されず、そしてそれゆえｂａｃｋｇｒｏｕｎｄｃｏｌｏｕｒ中で規定された色は、ＵＩ中で使用される。

面４０５ｃは、ウィンドウのタイトル中で使用されるテキストに関する属性を定義するｗｉｎｄｏｗｔｉｌｅ．ｔｘｔエレメントを備える。これは、テキスト属性を定義するためにいずれかの面４０５ａ又は４０５ｄにｗｉｎｄｏｗｔｉｌｅ．ｔｘｔエレメントを追加することによって、又はＵＩレンダラがいずれの後続のｗｉｎｄｏｗｔｉｌｅ．ｔｘｔエレメントも無視するように指示するためにいずれかの面４０５ａ又は４０５ｂにｗｉｎｄｏｗｔｉｌｅ．ｔｘｔ＿ｄｅｌｅｔｅｄエレメントを追加することによって上書きされることができる。

ユーザは、ＵＩ内部に表示されるコンテントを制御するためにソフトウェア３００内部の優先順位を設定できる。例えば、複数のフットボール・チームに関係するコンテントは、
/demoUI/football/team_xxxx/team_menu.pnp
に類似の形式を有するパスを用いてサーバ上に記憶されることができる。ここで、ｔｅａｍ＿ｘｘｘｘ変数は、チームのリスト（ｍａｎｕ，ｃｈｅｌ，ｌｅｅｄ，ｍａｎｃ，等）からユーザによって選択され、そして選択されたチームに関係するコンテントをＵＩが表示するようにパス中に挿入される。ｔｅａｍ＿ｘｘｘｘ変数の変更は、それに応じて表示されるコンテントを変更させる。優先順位の選択が、ローカル記憶装置に記憶されているコンテントから選択することとは反対に、遠隔サーバ上に記憶されたコンテントから選択されるコンテントの表示を制御することに注意する。

このアプローチは、次の形式の要請を送るために好ましい、
http： //t1.trigenix.com/triglets/football/triglet&pn=”0776655443322”
この場合のように、サーバは、表示されようとしているコンテントを識別するためにデータベース問い合わせを実行する必要があり、そしてこれは要請されたコンテントを提供するためにサーバから必要とされるリソースを著しく増加させるためである。

その技術によってある種の結果が実現されることが可能な別の１つの公知の技術は、次の形式の要請を送ることである：
http; //t1.trigenix.com/triglets/football/triglet&fc=’ManU’
しかし、このアプローチの不都合なことは、新たなチームが追加される各回毎に、サーバ論理が新たなチームを含むために更新されなければならないことである。対照的に、この方法は、コンテントが新しい位置でサーバに追加されることを必要とする、これは、より簡単な処理でありそしてそれを実行するためにより少ないリソースしか必要としない。

更新は、新たなトリグ（新たなＵＩ又は交換ＵＩ）又はトリグレット（既存のトリグに対する変更）を備え、そしてソフトウェア・ファイル・システムへの変更のように見られることができる。Ｕｐｄａｔｅ Ｍａｎａｇｅｒは、パケットを読むことによってファイル・システムの変更に何が必要であるかを決定する。Ｕｐｄａｔｅ Ｐａｃｋｅｔは、ＨＴＴＰを使用するソフトウェア４００によって無線を介して若しくはデバイスに固有のパッケージ・フォーマットに収納された又はソフトウェア自身のインストールで事前に与えられた別の好適なトランスポート機構を介してダウンロードされることができる。

更新は、複数の手段によってトリガされることができ、これは下記を含む；
・スタート・アップの際に中断されたＵｐｄａｔｅ（更新）処理をチェックするソフトウェア、
・スタート・アップの際にプレ−インストールされたＵｐｄａｔｅ Ｐａｃｋｅｔをチェックするソフトウェア、
・Ｕｐｄａｔｅ Ｃｈａｎｎｅｌ（更新チャネル）によって設定されたような自動的なもの、
・ユーザが起動するもの、
・特別なＳＭＳを受信するデバイス。

更新をアンパックするためそしてインストールするために使用するアルゴリズムは、デバイスに特有である。しかしながら、アルゴリズムが予期しない中断（例えば、停電）から安全であることが重要であり、その結果、破壊又は再生不可能な状態が起きないことが、ファイル・システムにおいて達せられる。これは、２つのスレッド（ネットワーク・スレッド及びレンダラ・スレッド）を使用して実現されることができ、そのスレッドは、最短の可能な時間の長さの間レンダラ・スレッドを中断するように、ネットワーク・スレッドによって実行される可能な限り多くの更新処理を行うゴールを有する。

ＴｒｉｇＭＬフラグメントは、内部にテキストＴｒｉｇＭＬ及びリソース参照符号を包含するファイルであり、これらのフラグメントは、バーチャル・ファイル・パスである。これらのバーチャル・ファイル・パスのリアル・ファイル・パスへのマッピングは、ＴｒｉｇＤｅｆｉｎｉｔｉｏｎ（トリグ定義）ファイルによって定義される。このファイルは、同様に、トリグの別の特性も定義する。トリグレットをコンパイルするために使用される場合は、このファイルは、同様に、入力ＴｒｉｇＭＬ／ＰＮＧ／Ｔｅｘｔリソースが、トリグのバーチャル・ファイル・システムの変形上にどのようにしてマッピングするかも定義する。ＰＮＧ及びテキストＲｅｓｏｕｒｃｅに関して、トリグＤｅｆｉｎｉｔｉｏｎファイルは、ホスト・ファイル・システム上のリアル・ファイルのリストを指し示し、そしてリソースは、出力にコピーされる。

ＴｒｉｇＭＬは、属性値の代わりに恒常的な変数（constant variables）を使用できる。恒常的な変数は、＜ｉｎｃｌｕｄｅ＞パラメータ、例えば、＄ｂａｃｋｇｒｏｕｎｄ＿ｃｏｌｏｕｒ、のような同じシンタックスを用いてアクセスされる。定数は、トリグ中でグローバルな変数として扱われ、そして予備のフォルダ、ｃｏｎｓｔａｎｔｓ／、中で定義される。ｃｏｎｓｔａｎｔｓ／フォルダ中のファイル内に包含される変数の定義は、それらの値の直接置換を用いるコンパイル時に分解されることができる。あるいは、ｃｏｎｓｔａｎｔｓ／中の変数の定義は、グローバル変数としてコンパイルされ、そしてソフトウェアによってコンテント解析時に分解される。これは、トリグがその定数ファイルの１つ又は全ての単純な置き換えによって更新されることを可能にする。

Ｓｙｓｔｅｍ Ｓｔｒｉｎｇ Ｄｉｃｔｉｏｎａｒｙ（システム・ストリング辞書）は、全ての良く知られたストリング、すなわち、保存された用語、に対して使用される整数値を規定する。これらは、複数のタイプ：ＴｒｉｇＭＬエレメント及び属性名（‘ｇｒｏｕｐ’，‘ｒｅｓ’，‘ｌａｙｅｒ’，‘ｉｍａｇｅ’，‘ｘ’）、ＴｒｉｇＭＬ属性値（例えば、‘ｌｅｆｔ’，‘ａｃｔｉｖａｔｅ’，‘ｆｏｃｕｓ’）及び共通リソース・パス（例えば、‘ａｔｔｒ’，‘ｓｔａｒｔ−ｕｐ’，‘ｄｅｆａｕｌｔ’）を含む。入力として、Ｓｔｒｉｎｇ Ｄｉｃｔｉｏｎａｒｙは、オプションである。トリグがコンパイルされる最初の時に、トリグは、Ｓｔｒｉｎｇ Ｄｉｃｔｉｏｎａｒｙを持たない。この最初のコンパイルは、Ｓｔｒｉｎｇ Ｄｉｃｔｉｏｎａｒｙを創成し、これは、そしてそのトリグの全てのその後のコンパイルに使用される。トリグレットのコンパイルは、トリグレットが変更しているトリグによって使用される全てのストリング・マッピングを定義するＳｔｒｉｎｇ Ｄｉｃｔｉｏｎａｒｙを持つ必要がある。

移動デバイスのユーザ・インターフェースを良好にレンダするために、マークアップ言語は、下記の特性を持つ必要がある：簡潔なページ定義、首尾一貫したレイアウト・ルール、コンパクト・レンダラにおいて実行可能であること、複数の階層化及び任意の重複するコンテントを提供すること、イベント・モデル、ＵＩの複数のページ間で変更しなければならないディスプレイの領域だけを塗り直す必要があること、イベントを受け取りそしてイベントを送るプロバティ値を読み込むためのプラットフォームへのフックを含むこと、拡張可能であること、そしてグラフィカルに順応性があることである。ＴｒｉｇＭＬは、これらの特徴を提供し、そして２００４年２月１９日に出願した我々の同時係属中の出願ＧＢ０４０３７０９，９は、所望の機能性を与えるエレメント及び属性の全体像を与える。

ＵＩの印象を変えること（re-branding）のコスト及び更新情報の継続的なストリームを生成することのコストが最小であることが望ましい。これは、創生的な処理からユーザへのデータの送信までを通して情報の効率的なフローを提供することによって実行可能にされる。

パーセル（parcel）と呼ばれるコンテナは、複数のＵＩに対して、ＵＩ更新情報に対して、そしてサード・パーティを含むことに関するテンプレートに対して使用される。パーセルは、サード・パーティが、所有者を示されたＵＩ及び更新情報を生成し、試験し、そして配信するために必要な全ての情報を包含する。図４は、コンテント・ツールセット２００の概略図を示し、これは、スクリプティング環境２２０、テスト及びシミュレーション環境２３０、及び保守管理環境２４０を備える。

パーセル処理は、下記の５つの処理ステージを備える：
１）スクリプティング環境２２０は、１又はそれより多くのＵＩに対するテンプレートを設計し、そしてそのテンプレートに基づいてＵＩに対する更新方針を設計するための手段を提供する。

２）保守管理環境２４０は、コンテント・プロバイダに外注されることができるよく制御された環境及び管理された（guided）環境で迅速なＵＩ生成及び更新生成を提供する。

３）保守管理環境２４０‘プレ−フライト（pre-flight）’機能は、展開管理者（deployment administrator）がサード・パーティから受け取るＵＩ及び更新情報を検査し、正しく調整することを可能にする。

４）パブリッシング・コンポーネント１１０は、新しいリリースのステージングを含む展開点におけるＵＩ及び更新情報の管理を提供する。

５）パブリッシング・コンポーネント１１０は、ライブ・コンテント番組（feeds）から更新情報の自動生成を可能にする。

典型的なプロジェクトでは、パーセルは、下記のためにスクリプティング環境２２０の内部で創生される：コンテント・プロバイダは同じ‘ｆｅｅｌ（感覚）’であるが異なる‘ｌｏｏｋ（外観）’を組み込んでいるテンプレートから印象を変えたＵＩを創生する；コンテント・プロバイダはＵＩコンテントに周期的な変化又はユーザが選択した変化を与えるテンプレートから更新情報を創生する；又はａｄ代理人は定期的なベースで新たなサービスを促進するテンプレートから更新情報を創生する。

これらの使用ケースの全てに対して、保守管理環境２４０は、パーセルをインポートするため、コンテントの印象を変えそして変更するため、及びパブリッシング・コンポーネント１１０に提出するために新たなパーセルを創生するために使用される。ＵＩテンプレートに設計において、以下の問題が考慮されるべきである：ＵＩのどの部分が印象を変えられるか；ＵＩのどの機能が印象を変えるときに又はリモートで変更される必要があるか；ＵＩコンテントのどの部分が更新されるか；及びＵＩが印象を変えられた場合に、ユーザは使用時にコンテント供給を選択できるか。スクリプティング環境２２０は、これらの方針が規定されることを認め、そして各方針の各事例のインプリメンタ（implementer）として保守管理環境２４０をイネーブルする。

パーセルは、編集するための更新又はテンプレートＵＩを備えるスクリプティング環境２２０によって発生される。一旦、編集が終了すると、パーセルは、コンテント・サーバに発行するために保守管理環境２４０にディスパッチする準備を整えるように‘ｏｕｔｂｏｘ’にセーブされる。下記の‘ｐａｒｃｅｌ’機能が与えられる。保守管理環境２４０は、パーセル内部に保有された編集／交換リソースに使用されることができる。パーセルは、シミュレーション環境にエクスポートされることができ、ＵＩの性能又は移動デバイス上のＵＩ更新を試験する。

複数の異なるＵＩは、共通ベースから導き出されることができる。一般的に、共通ベースは、大部分のインターフェースそれ自身を与えるはずであり、それから導き出されたＴｒｉｇは、イメージを与えるような、それに小さな変動を与えるはずである。Ｔｒｉｇｌｅｔは、Ｔｒｉｇから導き出されることができ、そしてそれは、（オプションとして自分自身のリソースを導入できるように）それが選択する親Ｔｒｉｇより任意のリソースを優先できる。ここでは“リソース”は、同様にＴｒｉｇＭＬも呼び、それで、Ｔｒｉｇの挙動及びレイアウトは、Ｔｒｉｇｌｅｔが１つのイメージ又はテキストの一部を置き換えることと全く同じように容易に、Ｔｒｉｇｌｅｔによって変形されることができる。

Ｐａｒｃｅｌは、１又はそれより多くの基本Ｔｒｉｇ（すなわち、いずれかの別のトリグから導き出されていないＴｒｉｇ）、基本Ｔｒｉｇから導き出された１又はそれより多くの複数のＴｒｉｇ、いずれかのトリグから導き出された複数のトリグレット及び別のトリグレットから導き出された複数のトリグレットを備える。

パーセル・フォーマットは、順番に並べられたオブジェクトとしてこの情報の全てを記憶する不明瞭な（opaque）バイナリ・フォーマットである。パーセルは、画像、テキスト、ＵＲＬ、更新チャネル、呼出音ファイル、壁紙、ネイティブ・アプリケーション、等のような多数のリソースを備えることができる。各リソースは、リソースをどのように見て、編集し、又は消去するかについての許可情報を包含する。各リソースは、その上、そのリソースに直接的に関係する命令及びドキュメンテーションのようなメタ（meta：超越）情報も包含する。各Ｐａｒｃｅｌツールは、直接的に関係する役割を仮定するか、又はユーザが特定の役割としてログインすることを必要とするかのいずれかである。

図６は、本発明の１実施形態にしたがったユーザ・インターフェースを具備するデバイス８００の概略図を示す。デバイスは、ユーザ・インターフェース８１５を表示するディスプレイ８１０、及びユーザ・インターフェース手段８２０、これはユーザがユーザ・インターフェース８１５と情報交換することをイネーブルする、を具備する。プロセッサ８３０は、１又はそれより多くの記憶手段８４０内部に記憶されているソフトウェアを実行し、そして１又はそれより多くのワイアレス通信インターフェース８５０与えられることができ、別のデバイス及び／又は通信ネットワークとの通信をイネーブルする。１又はそれより多くの電池８６０は、デバイスに電力を供給でき、デバイスは、しかも電力受け取るためのインターフェース及び／又は通信ケーブルへのインターフェースを備えられる。

これらのコンポーネント及びインターフェースの特質は、デバイスの特質に依存する。そのようなインターフェースが携帯電話受信機又はセルラ電話受信機の内部に与えられることができるが、これは同様に、ディジタル・カメラ、ディジタル電子手帳、ディジタル音楽プレーヤ、ＧＰＳナビゲータ、携帯ゲーム機、等のようなその他の携帯デバイスにも適用可能であることが理解される。その上、これは同様に、ラップトップ・コンピュータ又はデスクトップ・コンピュータのような、ユーザ・インターフェースを備えるその他のデバイスにも適用可能である。

ユーザ・インターフェース手段は、数字キーボード又は英数字キーボードのような複数のボタン、若しくはタッチ・スクリーン又は類似のものを具備できる。１又はそれより多くの記憶装置は、メモリ・カードのような不揮発性メモリの形式を備えることができ、その結果、もし、停電しても記憶されたデータが失われない。ＲＯＭ記憶手段は、更新すること又は変更することが必要ないデータを記憶するために与えられることができる。ある種のＲＡＭは、高速の応答時間が頻繁にアクセスされるデータのキャッシングを助けるように一時的な記憶のために与えられることができる。デバイスは、同様に、ユーザが脱着可能なメモリ・カードを受け入れることができ、そしてオプションのハード・ディスク駆動装置が記憶手段として使用されることができる。使用される記憶手段は、デバイスの大きさ、電力消費量、必要な記憶容量、等の異なる要求をバランスさせることによって決定される。

そのようなデバイスは、仮想的にいずれかのワイアレス通信ネットワーク、例えば、第２世代ディジタル移動電話ネットワーク（すなわち、ＧＳＭ、Ｄ−ＡＭＰＳ）、いわゆる２．５Ｇネットワーク（すなわち、ＧＰＲＳ、ＨＳＣＳＤ、ＥＤＧＥ）、第３世代ＷＣＤＭＡネットワーク又はＣＤＭＡ−２０００ネットワーク、そしてこれらのネットワーク及び類似のネットワークの改善されたもの及び派生物、とともに与えられることができる。ビルディング及びキャンパスの内部で、その他の技術、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩｒＤａ又はワイアレスＬＡＮ（無線又は光システムに基づいているかに拘らず）が、同様に使用されることができる。ＵＳＢ接続性及び／又はファイアワイア（FireWire）接続性は、別のデバイスとデータ同期化のために及び／又は電池充電のために与えられることができる。

上に説明されたように、方法を実行するためのコンピュータ・ソフトウェア及び／又はデバイスを構成するためのコンピュータ・ソフトウェアは、フロッピ（登録商標）ディスク、ＣＤ−ＲＯＭ、ＤＶＤ、不揮発性メモリ・カード、等のようなデータ・キャリアで与えられる。

本出願は、英国特許出願番号第０４０３７７０９．９号、２００４年２月１９日出願、に優先権を主張し、その内容は、引用によって本明細書中に組み込まれている。

［付表Ａ］
先導符‘／’で始まるファイル・パスに関して：

先導符‘／’のないファイル・パスは、現在のトリグに関係するものとして取り扱われる、すなわち、各トリグは、１つのフォルダ中に階層ルートされた自分自身のフォルダ中に記憶される。

［付表Ｂ］

図１は、本発明を組み込んでいるシステムの概略図を示す。 図２は、サーバ１００の構造及び動作を非常に詳細に図示する。 図３は、移動デバイス３００のためのソフトウェア４００の概略図を示す。 図４は、コンテント・ツールセット２００の概略図を示す。 図５は、４つの階層面の概略図を示す。 図６は、本発明の１実施形態にしたがったユーザ・インターフェースを具備するデバイス８００の概略図を示す。

符号の説明

１００…サーバ，１１０…パブリッシング・コンポーネント，１１１…データベース，１１２…インポート・キュー，１１３…コンテント・ツールセット・インターフェース，１１４…ユーザ・インターフェース１１４，１１５…カタログ，１５０…コンテント・サーバ・コンポーネント，２００…コンテント・ツールセット，２１０…パーセル，２２０…スクリプティング環境，２３０…シミュレーション環境，２４０…保守管理環境，３００…移動デバイス，４１０…マークアップ言語レンダラ，４２０…更新マネージャ，４２５…ネットワーク通信エージェント，４３０…リソース・マネージャ，４３５…バーチャル・ファイル・システム，４４０…アクタ・マネージャ，４４５…アクタ，４５０…ネーティブＵＩレンダラ，４５５…，４６０…サポート・マネージャ，４６５…トリグ・マネージャ，４７０…マークアップ言語パーサ，５００…コンテント・フィーダ，７００…オペレーションのサポート」・システム，８００…デバイス，８１０…ディスプレイ，８１５…ユーザ・インターフェース，８２０…ユーザ・インターフェース手段，８３０…プロセッサ，８４０…記憶手段，８５０…ワイアレス通信インターフェース，８６０…電池。

Claims (9)

1. 複数のデータ・リソースを記憶するための記憶手段、該記憶手段中に記憶された該複数のデータ・リソースを体系化するためのファイル・システム、及び該複数のデータ・リソースにユーザ・アクセスを提供するためのユーザ・インターフェースを具備するデバイスであって、ここにおいて、該ファイル・システムは、直接アドレス可能なデータ・リソースを備える１又はそれより多くのロケーション及び間接的にアドレス可能なデータ・リソースを備える１又はそれより多くのロケーションを具備し、該間接的にアドレス可能なデータ・リソースはデータ・プロバイダを経由してアドレス可能であり、該ファイル・システムは使用時に該ユーザ・インターフェースから直接アドレス可能なデータ・リソース及び間接的にアドレス可能なデータ・リソースの両者に１つのインターフェースを与えるために構成される。
2. 請求項１にしたがったデバイス、ここにおいて、該直接アドレス可能なデータ・リソースは、使用時に、該ユーザ・インターフェース内に表示されるデータ・コンテント・ファイルを具備する。
3. 請求項１若しくは２にしたがったデバイス、ここにおいて、該間接的にアドレス可能なデータ・リソースは、データベースを具備し、そして使用時に、１又はそれより多くの問い合わせの結果が該ユーザ・インターフェース内に表示される。
4. 請求項１若しくは２にしたがったデバイス、ここにおいて、該間接的にアドレス可能なデータ・リソースは、マークアップ言語エレメントを具備し、そして使用時に、該マークアップ言語エレメントはレンダされ、そして関係する結果が該ユーザ・インターフェース内に表示される。
5. デバイスのファイル・システム内部に複数のデータ・リソースを記憶するための方法であって、該方法は下記のステップを具備する：
   １つの直接アドレス可能なデータ・リソースを具備する１又はそれより多くのロケーションを定義すること；
   間接的にアドレス可能なデータ・リソースを具備する１又はそれより多くのロケーションを定義すること、該間接的にアドレス可能なデータ・リソースはデータ・プロバイダを経由してアクセス可能である；
   ここにおいて、ファイル・システムは、該ユーザ・インターフェースから該直接アドレス可能なデータ・リソース及び該間接的にアドレス可能なデータ・リソース・アクセスの両者をアクセスするために１つのインターフェースを与える。
6. 請求項５にしたがった方法、ここにおいて、該方法は、該データ・リソースのコンテントが該ユーザ・インターフェース内に表示されるように、直接アドレス可能なデータ・リソースをアクセスするさらなるステップを具備する。
7. 請求項５にしたがった方法、ここにおいて、該方法は、間接的にアドレス可能なデータ・リソースをアクセスするさらなるステップを具備し、該データ・リソースはデータベース問い合わせの（複数の）結果が該ユーザ・インターフェース内に表示されるようにデータベースを具備する。
8. 請求項５にしたがった方法、ここにおいて、該方法は、間接的にアドレス可能なデータ・リソースをアクセスするさらなるステップを具備し、該データ・リソースはマークアップ言語エレメントがレンダされそして関係する結果が該ユーザ・インターフェース内に表示されるようにマークアップ言語エレメントを具備する。
9. 請求項５ないし８のいずれかの方法を実行するためのコンピュータ実行可能なコードを具備するデータ・キャリア。

Images