JP5282324B2 - ユーザーインターフェースデータのためのデータコンテナ - Google Patents

Description

この発明はデータコンテナに関し、特に移動通信ネットワークに使用する移動装置のためのユーザーインターフェースコンテンツデータに使用するデータコンテナに関する。

モバイルネットワークオペレーターおよびコンテンツプロバイダーのための成長領域の１つは、着信音、壁紙、および携帯電話および装置のための他のマルチメディアコンテンツである。独自の必要性を満たすために、装置の概観をカスタム化および変更するためのユーザーの必要性とブランド目的のための装置ユーザーインターフェースのいくつかの観点に対して制御を維持するためにモバイルネットワークの必要性と装置製造業者の必要性との間に対立がある。所望の柔軟性とカスタム化を提供するのに必要な高度なソフトウエアも、典型的な移動装置の制限された処理能力およびデータ記憶容量と対立している。

この発明はこれらの問題を緩和しようとする。

発明の概要

この発明の第１の観点によれば、装置へのユーザーインターフェースを提供するための方法が提供される。この方法はａ）コンテナを作成するステップを含む。コンテナは、ユーザーインターフェースのための実行可能なコードと、ユーザーインターフェースに使用する１つ以上のコンテンツリソースと、単一のコンテンツリソースまたは複数のコンテンツリソースの各々に関連するメタデータとを備え、実行可能なコード、単一のコンテンツリソースまたは複数のコンテンツリソースの各々、およびメタデータはコンテナ内の順番に並べられたオブジェクトとして記憶される。また、前記方法は、ｂ）前記コンテナを１つ以上の装置に送信することと、ｃ）単一の装置または複数の装置の各々におけるコンテナのコンテンツを抽出することと、
ｄ）コードを実行して装置のためのユーザーインターフェースを発生することとを備える。

この発明の第２の観点によれば、上述した方法を実行するためのコンピューター実行可能なコードを備えたデータキャリアが提供される。

この発明の第３の観点によれば、１つ以上の装置へのユーザーインターフェースを提供するためのサーバーが提供される。サーバーは、データコンテナを受信するための記憶装置手段と、ユーザーインターフェースのための実行可能なコードを備えたデータコンテナで使用する際にデータコンテナを編集可能にする編集手段であって、使用時にデータコンテナは、ユーザーインターフェースで使用する１つ以上のコンテンツリソースと、単一のコンテンツリソースまたは複数のコンテンツリソースの各々に関連するメタデータとを備え、実行可能なコード、単一のコンテンツリソースまたは複数のコンテンツリソースの各々およびメタデータは、データコンテナ内の順番に並べられたオブジェクトとして記憶される、手段と、およびデータコンテナを１つ以上の装置に送信する送信手段とを備える。

この発明の第４の観点によれば、ユーザーインターフェースを装置にインストールする方法が提供される。この方法は、ａ）装置において、通信ネットワークを介してコンテナを受信することを含む。コンテナは、ユーザーインターフェースのための実行可能なコードと、ユーザーインターフェースに使用するための１つ以上のコンテンツリソースと、コンテンツリソースまたは各コンテンツリソースに関連するメタデータを備える。コンテンツデータまたは各コンテンツデータとメタデータは、コンテナ内の順番に並べられたオブジェクトとして記憶される。また、前記方法は、ｂ）装置においてコンテナの内容を抽出することと、ｃ）コードを抽出して装置のためのユーザーインターフェースを発生することとを備える。

この発明の第５の観点によれば、上述した方法を実行するためのコンピューターが実行可能なコードを備えたデータキャリアが提供される。

この発明の第６の観点によれば、ディスプレイ、ユーザーインターフェース、記憶装置手段、処理手段および通信インターフェースを備えた装置が提供される。装置は、使用時に、通信インターフェースを介して通信ネットワークからデータコンテナを受信するように構成され、データコンテナを記憶装置手段に記憶するように構成され、処理手段を用いてデータコンテナを処理し、データコンテナの内容を抽出するように構成される。データコンテナは、ユーザーインターフェースのための実行可能なコードと、ユーザーインターフェースに使用するための１つ以上のコンテンツリソースと、単一のコンテンツリソースまたは複数のコンテンツリソースの各々に関連するメタデータを含む。実行可能なコード、単一のコンテンツリソースまたは複数のコンテンツリソースの各々は、データコンテナ内の順番に並べられたオブジェクトとして記憶される。また、前記装置は、データコンテナの抽出された内容に従ってユーザーインターフェースを形成し、装置ディスプレイ内のユーザーインターフェースを表示するように構成される。

この発明は実例としてのみそして添付された図面について記載されるであろう。図１はこの発明を組み込んだシステムの概略の描写を示す。システムは、サーバー１００、コンテンツツールセット２００、移動装置３００、動作サポートシステム（ＯＳＳｓ）７００、コンテンツフィード５００およびユーザーインターフェースソース６００を備える。使用時において、サーバー１００はコンテンツデータおよびＵＩデータを移動装置３００、３０１に通信する。移動装置３３０、３０１の各々はソフトウエアパケッージを備えている。サーバー１００はＯＳＳｓ７００とインターフェースする。ＯＳＳｓは、モバイルネットワーク、例えば請求書作成、アカウント管理を動作するために一般的に使用されるＯＳＳｓである。サーバー１００はさらにコンテンツツールセット２００とインターフェースする。コンテンツツールセットはＵＩソース６００、６０１からデータを受信する。そして、サーバーがパッケージ化されたＵＩデータを、移動装置３００名に備えられたソフトウエアパッケージ４００に送信することができるようにＵＩデータをパッケージ化する。サーバーは複数のコンテンツフィードからデータを受信し、このデータは、このデータがソフトウエアパッケージ４００に送信することができるようにまたは移動装置３００がソフトウエアパッケージを用いたデータをアクセスすることができるように処理されパッケージ化される。

システムは３つの別個の領域に分割されるとして思い描くことができる。オペレーター領域５０はモバイルネットワークオペレーター（ＭＮＯ）により操作されるシステムおよび機器を備える。ユーザー領域６０は複数の移動装置を備え、第三者領域７０は、多数の異なるエンティティにより制御されるまたは動作されてもよいコンテンツフィードおよびＵＩフィードを備える。

図２はサーバー１００の構造と動作を非常に詳細に描写する。サーバー１００はパブリッシングコンポーネント(publishing component)１１０およびコンテンツサーバーコンポーネント１５０を備える。パブリッシングコンポーネントはデータベース１１１、インポートキュー(import queue)１１２、コンテンツツールセットインターフェース１１３、ユーザーインターフェースおよびカタログ１１５を備える。動作において、パブリッシングコンポーネントはコンテンツツールインターフェースにいてコンテンツツールからコンテンツを受信する。コンテンツは１つ以上のトリグ(Trigs)および１つ以上のトリグレット(Triglets)を備えた小包２１０ａ、２１０ｂ、・・・（下記参照）の形態で提示される。トリグは携帯電話のような移動装置のためのユーザーインターフェースであり、トリグレットはトリグを拡張または変更するために使用することができるデータファイルである。小包が１つ以上のトリグを備えているなら、トリグの１つはマスタートリグであってよく、そのマスタートリグから他のトリグが導き出される。

パブリッシングコンポーネントユーザーインターフェース１１４は、小包をデータベース１１１に取り込むために使用することができる。このプロセスは各トリグおよびトリグレットへのリファレンス(reference)を取り込みキューにロードさせる。取り込みキューは複数のパーセル２１０ａ、２１０ｂへのリファレンスを備えていてもよい。小包のコンテンツはユーザーインターフェースを用いて調べてもよいし、小包のコンテンツはカタログに渡すことができる。ＭＮＯはいくつかのパブリッシング領域を有していてもよい。例えば、多数の国または領域内の各ターゲットサーバーのためのパブリッシングドメインを有していてもよい。各領域は他の領域から分離して処理され、生の環境および上演できる環境の両方においてコンテンツサーバーにオブジェクトがどのようにパブリッシュされるかを記載する独自のパブリッシングスキームを有する。パブリッシングコンポーネントＧＵＩは各領域にいくつかの異なる視野を提供し、オペーレーターがコンテンツのパブリッシングを完全に管理することを可能にする。カタログはカタログに記憶されたトリグへのリファレンスを備え、更新チャネルおよびフィードチャネルは種々の領域へコンテンツを転送するために使用される。領域ごとに、オペレーターはパブリッシングコンポーネントＧＵＩを用いて領域構造を構築し、カタログからのトリグを各領域ノードに割り当てる。トリグを効率的に選択する際に、オペレーターを支援するために、関連するアイテムのみが示されるようにフィルターがカタログ内に設けられる。

トリグは領域内のいくつかのノードに割り当ててもよい。いずれの場合にも、ターゲットサーバー上のトリグのパッケージングは、トリグをアクセスするであろうハンドセットに応じて、異なる、例えば、ＳＩＳまたはＣＡＢファイル必要があるかもしれない。パッケージングはパブリッシングコンポーネントＧＵＩを用いて制御することができる。

コンテンツの配信を制御するために更新チャネルは、トリグにより参照されてもよい。更新チャネルは、トリグレット更新パッケージを備える関連する領域上のリソースへのリンクであるＵＲＬを備える。ＵＲＬはあらかじめ定義された間隔で獲得することができる。そしてＨＴＴＰ ＧＥＴ関数はパッケージをアクセスするために使用される（他のトランスポートスキーム、例えば、ＳｙｎｃＭＬまたはＳＭＳまたは小さな更新のためのセルブロードキャストを使用してもよいことは容易に理解されるであろう）。トリグレットパッケージはどのようにトリグを変更することができるか、例えばトリグにより使用される１つ以上の画像またはテキストファイルを交換することを記載する。パブリッシングコンポーネントＧＵＩは、オペレーターが、領域のために存在する更新チャネル、更新チャネル上の各トリグレットに関連するＵＲＬｓ、および領域のための更新チャネルを有したトリグレットの関連性を定義し制御することを可能にする。各トリグレットは更新チャネルに関連しているので、オペレーターは、更新がパブリッシュされなければならない日にちと時間を入力してもよく、スケジュールを設定可能にする。

コンテンツフィードは更新チャネルに類似している。この更新チャネルに対して、コンテンツ更新は定期的ベースで自動的に発生される。コンテンツフィードは、ＵＲＬをポーリングし、更新パケットを検索し、それをトリグに適用することによりアクセスされる。満足している材料はＵＲＬの獲得によりアクセスされる。しかしながら、手動で構築されたトリグレット更新と、自動的に生成されたコンテンツの異なる性質のために、更新チャネルとコンテンツフィードは別個に管理される。この場合も先と同様に、ＳｙｎｃＭＬまたはＯＭＡ−ＤＭ(Open Mobile Alliance Device Management)のような他のトランスポートスキームを使用してもよい。

コンテンツサーバーコンポーネント１５０は、ウエブサーバーの標準の実施であり、そのようなものとしてスケーリングモデルは良く理解される。サーバーの能力は、ベンチマーク条件の下でウエブサーバーが処理することができる同時セッションの数を示す「ＳＰＥＣｗｅｂ９９」を用いて評価することができる。パブリッシュされたＳＰＥＣｗｅｂ９９数は４０４から２１、０００の範囲にわたり、典型的な商業的なウエブサーバーは、５，０００のオーダーでＳＰＥＣｗｅｂ９９数を有する。１時間あたりの更新コンテンツを備えた１ｍ加入者のための典型的な配置シナリオは、わずか１，１１２のＳＰＥＣｗｅｂ９９のレーティングを備えたウエブサーバーを必要とする。成功した配置は、さらなるサーバーが、拡張可能であり、故障に対して高度に回復力があるインフラストラクチャを作成可能にすることにより提供することができるサービスの使用を増大させる。

接続は、移動局からＷＡＰゲートウエイを解してサーバーに作られてもよい。この場合、ウエブサーバーセッションは移動電話とウエブサーバーとの間よりも、ＷＡＰゲートウエイとウエブサーバーとの間に存在する。ＷＡＰゲートウエイを介して、ファイルに対する要求が成されるとき、ウエブサーバーがウエブサーバーからのファイルをＷＡＰゲートウエイに転送するのにかかる間だけウエブサーバーを備えたセッションが持続する。すなわち、接続帯域幅は非常に高く、待ち時間は極めて低いであろうからセッションは極めて短い。

あるいは、直接接続を携帯電話とウエブサーバーとの間で確立してもよい。この場合、ウエブサーバーがデータを電話にダウンロードするのにかかる間、ウエブサーバーはセッションをオープンにしておく必要があるであろう。

コンテンツサーバーコンポーネントにより配信される２つのタイプのコンテンツがある。典型的に１００ＫＢのオーダーのトリグと、典型的に１ＫＢのオーダーの通常更新するトリグレットである。トリグダウンロードにより作られるトラフィックは既存のコンテンツダウンロードにより発生されるトラフィックに非常に類似している。従って、関連問題は良く理解される。規則的なトリグレットの更新はＭＮＯのトラフィックモデル内の新しい特徴であるが、更新の小さなサイズ、それは典型的には、１データパケット内に適合するが、このために、トラフィックは依然として典型的なウエブサーバーにより処理することができることを示すことが可能である。

図３は、移動装置３００のためのソフトウエア４００の概略の描写を示す。移動装置３００は、マークアップ言語レンダラー(renderer)４１０、更新マネージャー４２０、ネットワーク通信エージェント４２５、リソースマネージャー４３０、仮想ファイルシステム４３５、アクターマネージャー(actor manager)４４０、複数のアクター４４５ａ、４４５・・・ネイティブＵＩレンダラー(native UI renderer)４５０、サポートマネージャー４６０、トリグマネージャー４６５およびマークアップ言語パーサー４７０を備える。

ソフトウエアは、ＴｒｉｇＭＬを用いて動作することが好ましい。このソフトウエアは、ＸＭＬアプリケーションであり、マークアップ言語レンダラー４１０は移動装置３００上のディスプレイのためにＴｒｉｇＸＭＬをレンダリングする。マークアップ言語レンダラーはまたＴｒｉｇＭＬパーサーを用いて、ＴｒｉｇＭＬリソースを解析し、装置スクリーン上にコンテンツを表示し、ハンドセット上のコンテンツの交換とビューイング(viewing)を制御する。ネイティブＵＩレンダラーは、ＴｒｉｇＭＬの使用なしに表示することができるＵＩコンポーネントを表示するとともに、エラーメッセージを表示するために使用される。

ソフトウエア４００は装置固有の方法で供給され、インストールされる。例えば、Ｎｏｋｉａシリーズ６０装置の場合、ソフトウエアはＳＩＳファイルを用いてインストールされる。同様にしてＭＳスマートフォーン装置の場合、ソフトウエアはＣＡＢファイルを用いてインストールされる。同様に、ソフトウエアアップグレードは装置固有の方法で処理される。ソフトウエアは、ビルトインコンテンツのみをレンダリングする内蔵型のアプリケーションとしてより制限されたフォーマットで供給されてもよい。すなわち、ソフトウエアには、ビルトイントリグが供給されるが、さらなるトリグは後で追加することはできない。供給されたトリグは、無線でアップグレードしてもよい。

トリグマネージャー４６５は、リソースマネージャー４３０およびマークアップ言語レンダラーへのインターフェースを提供する。それは、一般にトリグ管理に対して責任がある。これは以下のものを含む。使用中におけるトリグの持続性知識、現在のトリグを変更すること、開始時におけるトリグの選択、コラプトトリグ(corrupt trig)のためのフォールバック(fall back）としてさらなるトリグの選択、インストールされたトリグのセットを維持すること、どこで特定のトリグがリソースマネージャーにインストールされるかを識別し、トリグの更新チャネル定義を読み、適切に更新マネージャーを構築すること。

リソースマネージャーは、装置上の持続的記憶装置の中小概念を提供する。すなわち、ファイルを実ファイルとして記憶し、またはデータベースに記録する。リソースマネージャーは、マークアップ言語レンダラーおよび更新マネージャーへのファイルシステムインターフェースを提供する。それは、ファイルパスロジックを処理すること、実リソースファイルとアクター属性とを区別すること、トリグに関連するパスを絶対パス上にマッピングすること、トリグマネージャーとインターフェースし、変更インターフェースを更新マネージャーに供給することに対して責任がある。

更新マネージャーはトリグおよびトリグレットの受信およびアプリケーションを処理する。更新マネージャーはレンダラーおよびトリグマネージャーにインターフェースを提供し、以下のものに対して責任がある。レンダラーにより命令されたとき手動更新の開始、トリグマネージャーによりそのように構成されたとき自動更新チャネルを制御して実施すること、手動更新の進捗状況を表示し、ネットワーク接続および／または装置電力の予期しない損失に続いて更新を回復すること。更新パケットフォーマットはＸＭＬスキームのバイナリシリアライゼーションとして定義してもよい。

ＸＭＬは、更新パケットフォーマット並びにＴｒｉｇＭＬコンテンツを定義するために使用される便利なデータフォーマッティング言語である。帯域幅と記憶効率の理由のために、テキストＸＭＬは、バイナリ表示にシリアライズされる。更新パケットとＴｒｉｇＭＬフラグメントの両方は、同じコンポーネント、すなわち、ＭＡＲＫ−ＵＰ ＬＡＮＧＵＡＧＥ ＰＡＲＳＥＲパーサーにより解析される。ソフトウエア内のＸＭＬの任意のさらなる使用はバイナリＸＭＬ符号化を使用しなければならず、それゆえパーサーを再使用しなければならない。

アクターマネージャー４４０はソフトウエア内に存在するアクター４４５のセットの世話をする。アクターマネージャー４４０は、コンテンツがイベントをアクターに送信しているときレンダラーにより使用される。また、アクターマネージャー４４０は、属性値が変更されたことを通知したいアクターによりおよびイベントを発したいアクターにより使用される（下記参照）。

ソフトウエアは、何人のまたどんな種類のアクターが含まれているかに応じてより多くの可能性を備えて、最小２つのスレッドを実行するマルチスレッドアプリケーションを備える。ソフトウエアはたいていは、メインスレッドと呼ばれる１つのスレッドで実行する。メインスレッドは、他のコンポーネントと同期的に通信するレンダラーを実行するために使用される。アクターは常にレンダラーに対して同期インターフェースを有する。アクターがその機能性のためにさらなるスレッドを必要とするなら、スレッド間通信を管理することはアクターの責任である。多くのアクターがスレッド間通信を必要とする場合に不必要なコードの重複を回避するためにライトメッセージングフレームワーク(a light messaging framework)が使用されることは望ましい。

メインスレッドに加えて、更新マネージャーはネットワークスレッドを実行する。ネットワークスレッドは、更新パケットをダウンロードするために使用され、メインスレッドから分離され、パケットが到着するまで影響を及ぼされないでレンダラーが継続することを可能にする。更新マネージャーは、更新パケット内で定義された変化を適用するとき、更新マネージャーがレンダラーとリソースマネージャーと同期的に通信するようにスレッド間メッセージングを処理する責任がある。

ソフトウエア４００は、装置に固有の方法で移動装置に供給される。１つ以上のトリグをインストレーションの一部として供給することができる。例えば、圧縮されていない更新パケットとして記憶することができる。開始時に、パケットは拡張することができ、ファイルシステムにインストールすることができる。

アクター４４５は、属性値を発行し、イベントを処理して、放出するコンポーネントである。アクターはレンダラーと同期的に通信する。アクターが非同期の動作を必要とするなら、レンダラーのメインスレッド外部のスレッドを管理し、通信することはアクターの責任である。

アクター属性はファイルリファレンスとして読んでもよい。属性は４つのタイプの１つである。単一の単純な値、単純な値のベクトル；各フィールドが単純な値を有するフィールドの単一構造；または構造のベクトル。属性は、多くのオブジェクト指向プログラミング言語に類似するオブジェクト．メンバー表記法を用いた式により参照されてもよい。

ファイルとして必要なとき、属性は、／ａｔｔｒｓフォルダーを介してアクセスされる。

アクターには、アクターに＜ｔｈｒｏｗ＞エレメントを有したイベントを送信することによりメッセージを送ることができる。アクターにより発行されたイベントは、コンテントイベントとしてコンテントツリーに配給することができる。これらはエレメントＩｄまたは’ｔｏｐ’を標的にすることができる。アクターへのインターフェースはアクターインターフェース定義ファイルにより定義される。これは、属性、タイプ、フィールド名、イベント入力およびパラメーター、およびイベント出力を定義するＸＭＬドキュメントである。アクターのセットはソフトウエアの構築時に設定可能である。付録Ａは、関連する機能または変数とともに使用してもよいいくつかのアクターの例示リストを与える。

更新は、新しいトリグ（新しいまたは交代ＵＩ）またはトリグレット（既存のトリグへの変更）を備え、ソフトウエアファイルシステムへの変更とみなしてもよい。更新マネージャーは、パケットを読むことによりファイルシステムにおいてどんなニーズが変更されるべきかを決定される必要がある。更新パケットは、ＨＴＴＰを用いて、または装置に固有のパケットフォーマットに包まれた、またはソフトウエア自体のインストレーションによりあらかじめ提供された他の適切なトランスポート機構を用いてソフトウエア４００により無線でダウンロードしてもよい。

考慮すべき他の故障モードがある。ＨＴＴＰ−ＧＥＴを開始できないなら、またはＨＴＴＰエラー応答コードを経験するなら、更新におけるこの試みは放棄され、再試行戦略を用いて、後日新しい更新の試みが始められる。ＨＴＴＰ応答がネットワーク信号の損失によって中断される場合、どんなテンポラリファイルも削除される。また、再試行戦略が使用され後日更新の試みが再開始される。更新ペイロードサイズが大きすぎて装置に適合しないかもしれないことを更新ヘッダーが示しているなら、または、更新がソフトウエアの互換性のないバージョンを必要とするなら、または更新がすでに装置上に常駐しているなら、ヘッダーデータファイルは削除され、更新の試みおよび任意のその後の再試行がキャンセルされる。

コンテンツフォーマットは、ソフトウエアを実施するすべてのプラットフォームにわたって共通である。コンテンツコンパイラーは、装置のファイルシステムに書くことができる無線の更新パケットに、生のリソースの集合（テキストＴｒｉｇＭＬ、ＰＮＧイメージ、テキストストリング定義）を変換するためのコンテンツオーサリングツール(content authoring tool)である。

ＴｒｉｇＭＬフラグメントはテキストＴｒｉｇＭＬを含んでいるファイルである。また、これらのフラグメント内のリソースリファレンスは仮想ファイルパスである。これらの仮想ファイルパスの実ファイルパスへのマッピングはTrigDefinitionファイルにより定義される。このファイルはまたトリグの他の特性を定義する。トリグレットをコンパイルするために使用されるとき、このファイルはまた、どのようにして入力TrigML/PNG/Textリソースを、トリグの仮想ファイルシステムの変更上にマッピングするかを定義する。

ＰＮＧおよびテキストリソースの場合、トリグ定義ファイルは、ホストファイルシステム上の実ファイルのリストを指し、リソースは出力にコピーされる。

ＴｒｉｇＭＬは、属性値の代わりに一定の変数を使用することができる。一定の変数は、＜include＞パラメーター、例えば$background_colourとして同じシンタックスを用いてアクセスされる。定数は、トリグにおいてグローバル変数として取り扱われ、予約されたフォルダー、constants/において定義される。constants/フォルダー内のファイル内に含まれる可変の定義はそれらの値の直接置換を用いてコンパイル時に解決してもよい。代替の実施形態において、constants/における可変の定義は、グローバル変数としてコンパイルされ、ソフトウエアによりコンテンツパース時に解決される。これは、その定数ファイルの１つまたはすべての簡単な交換によりトリグが更新されることを可能にする。

移動装置のユーザーインターフェースを成功裏に提供するために、マークアップ言語は以下の性質を持たなければならない。簡潔なページ定義を持つこと、一致したレイアウトルールを持つこと、コンパクトなレンダラーにおいて実施可能であること、複数のレイヤリング(layering)および任意のオーバーラップするコンテンツを供給すること、イベントモデルを組み込むこと、ＵＩのページ間で変更しなければならないディスプレイの領域のみの塗りなおしを必要とすること、特性値、受信イベントおよび送信イベントを読むためにプラットフォームへのフックを含むこと、拡張可能であること、および図形的に柔軟であること。ＴｒｉｇＭＬはこれらの特徴を提供し、所望の機能性を提供するエレメントと属性の概説は、２００４年２月１９日に出願された同時係属出願ＧＢ０４０３７０９．９に記載されている。

ＵＩｓを再ブランド化するコストおよび更新の連続したストリームを製造するコストは最小であることが望ましい。これは創造的プロセスからユーザーへのデータの送信までの情報の効率的な流れを提供することにより可能となる。

小包と呼ばれたコンテナは、第三者の関与のためのＵＩｓ、ＵＩ更新、およびテンプレートのために使用される。更新、小包と呼ばれたコンテナは、最新版および３番目のパーティー関与用テンプレートに使用される。小包は、第三者がブランド化されたＵＩｓと更新を製造し、試験し、配給するのに必要なすべての情報を含む。

図４は、コンテンツツールセットの概略描写を示す。コンテンツツールセットは、スクリプト記述環境２２０、試験およびシミュレーション環境２３０およびメインテナンス環境２４０を備える。小包プロセスは５つの処理段階を備える。

１） スクリプト記述環境２２０は、１つ以上のＵＩｓのためのテンプレートと、そのテンプレートに基づいてＵＩｓのための更新戦略を設計するための手段を提供する。

２）メインテナンス環境２４０は、コンテンツプロバイダーにアウトソーシングすることができる良く制御され、案内された環境において迅速なＵＩと更新生産を提供する。

３） メインテナンス環境２４０「プリフライト(pre-flight)」機能性は、配置アドミニストレーターがＵＩｓと、ＵＩｓが第三者から受信する更新をチェックして同調することを可能にする。

４） パブリッシングコンポーネント１１０は、新しいリリースのステージング(staging)を含む配置ポイントにおいてＵＩｓと更新の管理を提供する。

５） パブリッシングコンポーネント１１０は生のコンテンツフィードからの更新の自動発生を可能にする。

典型的なプロジェクトにおいて、小包はスクリプト記述環境２２０内で作られる。小包は、同じ「特色」であるが異なる「外観」を組み込んだテンプレートから再ブランド化されたＵＩｓを作るためのコンテンツプロバイダー；周期的なまたはユーザー選択された変化をＵＩコンテンツに供給する、テンプレートからの更新を作るコンテンツプロバイダー；または周期的なベースで新しいサービスを促進するテンプレートから更新を作成する広告代理店のために作られる。

すべてのこれらの使用ケースの場合、メインテナンス環境２４０は、小包を取り込んで、コンテンツを再ブランド化し再構成し、パブリッシングコンポーネント１１０に提出するために新しい小包を作るために使用される。ＵＩテンプレートの設計において、以下の問題は考慮されるべきである。ＵＩのどの部分を再ブランド化することができるか；ＵＩのどの特徴を再ブランド化または遠隔的に再構成する必要があるか；コンテンツのどの部分は更新してもよいか；ＵＩが再ブランド化されるならユーザーは使用時にコンテンツフィードを選択することができるか。スクリプト記述環境２２０はこれらの戦略が定義されることを可能にし、メインテナンス環境２４０が各環境の各インスタンスの実施者として機能することを可能にする。

スクリプト記述環境２２０の主機能は以下のものを含んでいてもよい。

・メニュー構造とページマップを定義する。

・ブランド化するコンテンツが入れられるフレームワークを定義する。

・更新可能なＵＩの部分を定義する。

・再ブランド化のために交換可能である更新の部分を定義する。

・エディターを支援するために対話型プレビューを提供する。

・各ＵＩレイヤのグラフコードビューを提供する。

・対話型プレビューおよびコードビューへのリソースのドラッグアンドドロップを可能にする。

・特定の再ブランド化のためにテンプレートをエクスポートしまたは構成タスクを更新する。

・ＵＩｓをシミュレートしハンドセットシミュレーター上で更新する。

・ＵＩｓを構築し、実装置上で試験するために更新する。

・開発を支援するために拡張されたデバッギングツールを提供する。

さらに、メインテナンス環境２４０の目的は、スキンと更新の再ブランド化およびメインテナンスのために設計者とアドミニストレーターのＵＩを提供することである、主機能には以下のものが含まれる。

・ＵＩテンプレートを再ブランド化すること
・新しいコンテンツで更新を占有する
・更新を介してＵＩメニューエントリーを管理する
・さらなる言語のためにＵＩｓを変換し更新する
・更なる装置のためにストリングとコンテンツを目的とする
・ハンドセットシミュレーター上に配置されるＵＩｓのシミュレーション
・実装置の再ブランド化されたＵＩ上で試験するためのＵＩｓと更新の構築
小包は、テンプレートＵＩまたは編集のための更新を備えたスクリプト記述環境２２０により発生される。編集が完了すると、小包は、コンテンツサーバーに発行するためにメインテナンス環境２４０にデスパッチする準備のために「アウトボックス」にセーブされる。以下の「小包」機能が提供される。メインテナンス環境２４０は小包内に保持されるリソースを編集／交換するために使用することができる。小包は、移動装置上でＵＩまたはＵＩ更新の性能を試験するためにシミュレーション環境にエクスポートすることができる。

エクスプローラーはユーザーがこれらのカテゴリにアクセスするために設けられる。ユーザーは可視としてマークされた任意のＵＩｓまたは更新、またはＵＩ内のリソースまたは「交換可能」としてマークされたＵＩまたは更新を変更することができる。セーブされると、「可視」オブジェクトのサムネイルは、メインテナンス環境内の同定使用のためにおよび他のサービスのために、小包内にセーブされる。

小包エントリーは適切なエディターを起動するためにダブルクリックしてもよい。（例えば、イメージリソースはイメージエディタを起動するであろう）。すべてのリソースは、メインテナンス環境に挿入され、メインテナンス環境内の適切なコンテキスト内に表示されるテキスト記述／ノートを有していてもよい。メニューエントリーのリストは、特別なリソースタイプとして処理される。各エントリーは、リソースの独自のサブカタログを表す。（例えば、タイトル、ヘルプストリング、イメージ、ロールオーバーイメージ、ＵＲＬおよびリングトーンプレビュー）。

多くの異なるＵＩｓを共通ベースから導き出すことができる。典型的に共通ベースは、インターフェース自体のほとんどを実施するであろう。共通ベースから導き出されたトリグは、ブランド化のような共通ベース上の小さな変化を実施するであろう。トリグレットはトリグから導き出すことができる。トリグレットは、トリグレットが選択する親トリグからの任意のリソースに優先することができる（任意でトリグレットはその固有のリソースを導入してもよい）。ここでの「リソース」はまた、ＴｒｉｇＭＬを指す。従ってトリグの行動およびレイアウトは、トリグレットが単一の画像またはテキストを交換するのと同程度の容易さでトリグレットにより変更することができることに留意する必要がある。

小包は、１つ以上のベーストリグ（すなわち、任意の他のトリグから導き出されないトリグ）、ベーストリグから導き出された１つ以上の多重トリグ、任意のトリグから導き出された複数のトリグレット、他のトリグレットから導き出された複数のトリグレットを備えていてもよい。

小包フォーマットは、順番に並べられたオブジェクトとしてすべてのこの情報を記憶する不透明なバイナリフォーマットである。小包は、イメージ、テキスト、ＵＲＬｓ、更新チャネル、リングトーンファイル、壁紙、ネイティブアプリケーション等のような多数のリソースを備えていてもよい。各リソースは、どのようにしてリソースを見て、編集して、削除するかに関するパーミッション情報を含む。各リソースはさらにそのリソースに関連するドキュメンテーションおよびインストラクションのようなメタ情報を含む。各小包ツールは関連する役割を仮定するかまたは特別な役割としてユーザーがログインすることを要求する。

開発途上にあるトリグの性質は、多数の人々および／または人々のグループが、トリグの最終的な設計および実施に寄与することに関与することができる。さらに、これらの人々のスキルセットは、非常に簡単化され制御されたスキームを用いてトリグへの無意識の損傷のリスクを最小にすることを要求する。合理的に複雑なトリグのための典型的な開発ワークフローは次のものを含むことができる：
・ＵＩ設計者は、オリジナルＵＩ構造を作る。

この設計は、このＵＩの最初のバージョンを作るためにメインテナンス環境を用いて構築してもよい。

・グラフィックデザイナーは最終グラフィックスを作成し、設計にそれらを加える。

・オリジナルの設計において識別されたダイナミックコンテンツのために取っておくＵＩのエリアは、具体化する必要がある。

ダイナミックな更新のためのグラフィックスはグラフィックデザイナーによって終了する必要がある。次に、ＵＩの擬人化エリアは設計されており実施される。これは多数の第三者のコンテンツプロバイダーにより処理されるかもしれない。

小包は、上述のワークフローを支援する。なぜなら、小包は単一ファイル内に全体のプロジェクトを含み、これは、全体のプロジェクトがチームの一人のメンバーから次にわたすのを容易にさせる。小包は、変更される必要があるリソース上にコメントと命令を加えることにより、および何が変更できるかを制限するために他のリソースの設定により開発の次のステージのために再度目的にされることができる。より複雑なワークフローは、小包を分岐可能にすることにより、および別個の開発を小包の各フォークに起こることを可能にすることによりサポートすることができる。マージツールは個々の変化を単一の小包に結合することを可能にする。小包は、Ｐｙｔｈｏｎプログラミング言語のためにピクルスモジュールを用いて実施してもよい。

小包は、ディスプレイサイズ、ＲＡＭ容量のような異なる能力を有する移動装置のためのトリグおよび／またはトリグレットを開発するために使用されてもよい。これを単純化するために、多数のヒエラルキー、およびヒエラルキー内で分類されるデータリソースまたはＴｒｉｇＭＬエレメントを定義してもよい。トリグまたはトリグレットが小包からコンパイルされると、ほとんどの適切なリソースまたはＴｒｉｇＭＬエレメントは、選択することができ、特定の装置のためにコンパイルすることができる。

図５は、この発明の一実施形態に従ってユーザーインターフェースを備える装置８００の概略描画を示す。装置は、ユーザーインターフェース８１５を表示するディスプレイ８１０と、ユーザーがユーザーインターフェース８１５と相互作用するのを可能にするユーザーインターフェース手段８２０とを備える。プロセッサー８３０は、１つ以上の記憶装置手段８４０内に記憶されるソフトウエアを実行する。また、他の装置および／または通信ネットワークとの通信を可能にするために１つ以上の無線通信インターフェース８５０を備えていてもよい。１つ以上のバッテリー８６０を受け入れて装置に電力を供給してもよい。装置はまた電力を受信するためのインターフェースと通信ケーブルを備えていてもよい。

これらのコンポーネントとインターフェースの性質は、装置の性質に依存するだろう。モバイルまたは携帯電話のハンドセット内にそのようなユーザーインターフェースを実施することができることは理解されるだろう。しかし、また、それは、デジタルカメラ、個人のデジタル形成体、デジタル音楽プレーヤー、ＧＰＳナビゲーター、ポータブルゲームコンソールなどのような他の携帯機器に適用可能である。更に、それは、また、ラップトップまたはデスクトップコンピューターのようなユーザーインターフェースを含む他のデバイスに適用可能である。

ユーザーインターフェース手段は複数のボタンを備える。例えば、数字または英数字のキーボード、またはタッチスクリーンまたは類似のものである。電力が失われる場合、記憶データが失われないように、１つ以上の記憶デバイスが、メモリカードのような不揮発性メモリの形式を含んでいてもよい。ＲＯＭストレージ手段は更新するか変わることを必要としないデータを記憶するために提供されてもよい。より速い応答時間が頻繁にアクセスされたデータのキャッシングをサポートするように、あるＲＡＭは一時記憶領域に供給されてもよい。また、装置はユーザーが脱着可能なメモリカードを受け入れてもよい。そして任意でハードディスクドライブを記憶装置手段として使用してもよい。使用される記憶装置手段は、装置サイズ、電力消費、要求される記憶装置などのボリュームの異なる必要条件の平衡を保つことにより決定されるだろう。

そのような装置は、仮想的に任意の無線通信ネットワークとともに実施してもよい。例えば、第二世代のデジタル携帯電話ネットワーク（すなわち、ＧＳＭ、Ｄ−ＡＭＰＳ）、いわゆる２．５Ｇネットワーク（すなわち、ＧＰＲＳ、ＨＳＣＳＤ、ＥＤＧＥ）、第三世代ＷＣＤＭＡまたはＣＤＭＡ−２０００ネットワーク、およびこれらおよび類似のものの改良品および派生物である。ビルディングとキャンパス内では、（無線または光学システムに基づくかどうかに関わらず）Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩｒＤａまたは無線ＬＡＮも使用してもよい。ＵＳＢおよび／またはＦｉｒｅＷｉｒｅ連結性は、他の装置とのデータ同期および／またはバッテリーの充電のために供給されてもよい。方法を実施するためのコンピューターソフトウエアおよび／または上述した装置を構成するためのコンピューターソフトウエアはフロッピー（登録商標）ディスク、ＣＤ−ＲＯＭｓ、ＤＶＤｓ、不揮発性メモリカード等のようなデータキャリア上に設けてもよい。

この出願は２００４年２月１９日に出願された英国特許出願番号０４０３７０９．９の利益を請求する。その出願の内容は参照することにより本明細書に組み込まれる。

図１は、この発明を組み込んだシステムの概要の描写を示す。 図２はサーバーの構造および動作を非常に詳細に描写する。 図３はモバイルデバイスのためのソフトウエア４００の概要の描写を示す。 図４はコンテンツツールセットの概略の描写を示す。 図５はこの発明の一実施形態に従うユーザーインターフェースを備えた装置の概略の描写を示す。

Claims (6)

1. ユーザーインターフェースを移動装置に供給する方法において、
   ａ）コンテナを作るステップであって、前記コンテナは、ユーザーインターフェースのための実行可能なコードと、前記ユーザーインターフェースに使用するための１つ以上のコンテンツリソースと、および前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々に関連するドキュメンテーションとインストラクションを具備するメタデータとを備え、前記実行可能なコードと、前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々と前記メタデータは前記コンテナ内に順番に並べられたオブジェクトとして記憶される、ステップと、
   ｂ）前記コンテナを１つ以上の移動装置に送信するステップと、
   ｃ）前記単一の移動装置または複数の移動装置の各々において、前記コンテナのコンテンツを抽出するステップと、
   ｄ）前記コードを実行して前記移動装置のためのユーザーインターフェースを発生するステップと、
   を備え、
   前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々に関連する前記メタデータは、１つ以上の階層制の分類に関連し、前記階層制の分類（複数の場合もある）は移動装置の能力に関連し、
   前記メタデータは、ステップａ）の期間に、前記実行可能なコードおよび／または前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々への許可されていないアクセスを防止するために、前記実行可能なコードおよび／または前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々へのアクセスを決定するデータをさらに備え、
   ステップａ）の期間に前記実行可能なコードおよび／またはコンテンツリソースが変更されるなら、前記メタデータはそれに従って更新される、
   方法。
2. ｅ）前記コンテナのコンテンツを、移動装置への送信のためのフォーマットに処理するステップをさらに有し、ステップｅ）はステップａ）の後であって、ステップｂ）の前に実行される、請求項１に記載の方法。
3. １つ以上の移動装置にユーザーインターフェースを供給するためのサーバーにおいて、
   データコンテナを受信するための記憶装置手段と、
   前記データコンテナが編集されることを可能にする編集手段であって、使用時に前記データコンテナは、ユーザーインターフェースのための実行可能なコードと、前記ユーザーインターフェースに使用するための１つ以上のコンテンツリソースと、および前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々に関連するドキュメンテーションとインストラクションを具備するメタデータとを備え、前記実行可能なコード、前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々および前記メタデータは、前記データコンテナ内で順番に並べられたオブジェクトとして記憶される、手段と、
   データコンテナを１つ以上の装置に送信するための手段と、
   を備え、
   前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々に関連する前記メタデータは、１つ以上の階層制の分類に関連し、前記階層制の分類（複数の場合もある）は移動装置の能力に関連し、
   前記メタデータは、前記編集の期間に、前記実行可能なコードおよび／または前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々への許可されていないアクセスを防止するために、前記実行可能なコードおよび／または前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々へのアクセスを決定するデータをさらに備え、
   前記編集手段は、前記編集の期間に前記実行可能なコードおよび／またはコンテンツリソースが変更されるなら、それに従って前記メタデータを更新
   する、サーバー。
4. 前記サーバーはさらに使用時に、データコンテナを１つ以上の移動装置に送信する前にデータコンテナを処理するように構成された処理手段をさらに備えた、請求項３に記載のサーバー。
5. 装置にユーザーインターフェースをインストールする方法において、
   ａ）移動装置において、通信ネットワークを介してコンテナを受信するステップであって、前記コンテナは、ユーザーインターフェースのための実行可能なコードと、前記ユーザーインターフェースに使用するための１つ以上のコンテンツリソースと、前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々に関連するドキュメンテーションとインストラクションを具備するメタデータとを備え、前記実行可能なコード、前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々、および前記メタデータは、前記コンテナ内において順番に並べられたオブジェクトとして記憶される、ステップと、
   ｂ）前記移動装置において、前記コンテナのコンテンツを抽出するステップと、
   ｃ）前記コードを実行して前記装置のためのユーザーインターフェースを発生するステップと、
   を備え、
   前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々に関連する前記メタデータは、１つ以上の階層制の分類に関連し、前記階層制の分類（複数の場合もある）は移動装置の能力に関連し、
   ステップｂ）の期間に、前記メタデータは、前記実行可能なコードおよび／または前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々へのアクセスを制御するために、前記実行可能なコードおよび／または前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々へのアクセスを決定するデータを備え、
   前記アクセス決定メタデータは、前記通信ネットワークからの制御データを受信することに応答して更新することができる、方法。
6. ディスプレイ、ユーザーインターフェース、記憶装置手段、処理手段、および通信インターフェースを備えた移動装置において、
   前記移動装置は使用時に、
   前記通信インターフェースを介して通信ネットワークからデータコンテナを受信し、
   前記データコンテナを前記記憶装置手段に記憶し、
   前記処理手段を用いて前記データコンテナを処理し、前記データコンテナのコンテンツを抽出することであって、前記データコンテナは、ユーザーインターフェースのための実行可能なコードと、前記ユーザーインターフェースに使用するための１つ以上のコンテンツリソースと、および前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々に関連するメタデータとを備え、前記実行可能なコード、前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々、および前記メタデータは、前記データコンテナ内において順番に並べられたオブジェクトとして記憶されることと、
   前記データコンテナの前記抽出されたコンテンツに従ってユーザーインターフェースを形成し、
   前記ユーザーインターフェースを前記装置のディスプレイに表示するように構成され、
   前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々に関連する前記メタデータは、１つ以上の階層制の分類に関連し、前記階層制の分類（複数の場合もある）は移動装置の能力に関連し、
   前記記憶装置手段に記憶された前記メタデータは、前記実行可能なコードおよび／または前記単一のコンテンツリソースまたは複数のコンテンツリソースの各々へのアクセスを制御するために、前記実行可能なコードおよび／または前記単一のコンテンツリソースまたは複数のコンテンツリソースへのアクセスを決定するデータを備え、
   前記装置は、さらに、使用時に、前記通信インタフェースを介して前記通信ネットワークから制御コマンドを受信するように構成され、前記制御コマンドは、前記コードおよび／またはコンテンツリソース（複数の場合もある）へのアクセスを決定するメタデータを更新する、移動装置。

Images