JP2012155728A - デバイスにコンテンツを供給する方法 - Google Patents

Abstract

【課題】デバイスへのユーザインターフェース用のコンテンツデータを受信する方法を提供する。
【解決手段】デバイスが、通信インターフェースから、ユーザインターフェース用のコンテンツデータを受信することと、前記デバイスが、前記受信したコンテンツデータを処理して、前記デバイスのためのユーザインターフェースを形成することとの各ステップを含み、前記コンテンツデータは、例えば、更新版の位置や、更新版がアクセスされる頻度など、コンテンツデータに対する更新版がどのようにして配信されるのかを決定するメタデータを備えており、前記方法は更に、前記デバイスが、コンテンツデータメタデータに従って、通信インターフェースを介してコンテンツデータ更新版にアクセスするステップを更に含む。
【選択図】図５

Description

本発明は、デバイスにコンテンツを供給する方法に関し、特に、モバイル通信ネットワークを使用して、モバイルデバイスにコンテンツを供給する方法に関する。

モバイルネットワークオペレータ及びコンテンツプロバイダの成長領域のうちの１つは、着メロ（登録商標）、壁紙、その他携帯電話及びモバイルデバイスのためのマルチメディアコンテンツの提供である。自身のニーズに適合させるために、モバイルネットワークオペレータとデバイス製造者とが、ブランド付けの目的のために、デバイスユーザインターフェースのいくつかの局面に対する制御を保持するニーズと、ユーザが、それらデバイスの外観をカスタマイズし変更するニーズとの間で緊迫している。所望の柔軟性及びカスタマイゼーションを提供するのに必要な精巧なソフトウェアもまた、典型的なモバイルデバイスの制限された処理能力及びデータ記憶容量で緊迫している。本発明は、これらの問題を緩和しようと努力する。

本発明の第１の局面によれば、デバイスへのユーザインターフェース用のコンテンツデータを受信する方法が提供される。この方法は、前記デバイスが、通信インターフェースから、ユーザインターフェース用のコンテンツデータを受信することと、前記デバイスが、前記受信したコンテンツデータを処理して、前記デバイスのためのユーザインターフェースを形成することとの各ステップを含み、前記コンテンツデータはメタデータを備えており、前記方法は更に、前記デバイスが、コンテンツデータメタデータに従って、通信インターフェースを介してコンテンツデータ更新版にアクセスするステップを更に含む。

本発明の別の局面によれば、上記方法を実行するためのコンピューター実行可能なコードを含むデータ記憶媒体が提供される。

本発明の第３の局面によれば、ユーザインターフェースと、前記ユーザインターフェースを表示するための表示手段と、前記ユーザインターフェースにおいて使用されるコンテンツデータを受信するための通信インターフェースと、受信したコンテンツデータを処理して、前記ユーザインターフェースを形成する処理手段とを備えたデバイスが提供される。ここで、前記コンテンツデータは、メタデータを含み、前記デバイスは、コンテンツデータメタデータに従って、前記通信インターフェースを経由してコンテンツデータ更新版にアクセスするように構成されている。

図１は、本発明を組み込んだシステムの概要図を示す。 図２は、サーバ１００の構造および動作をより詳細に示す。 図３は、モバイルデバイス用のソフトウェアの概要を示す。 図４は、コンテンツツールセット２００の概要を示す。 図５は、本発明の実施例に従ったユーザインターフェースを含むデバイスの概要を示す。

本発明は、添付図面に関連して、例示することのみによって説明されている。ここでは、図１が、本発明を組み込んだシステムの概要を示している。本システムは、サーバ１００、コンテンツツールセット２００、モバイルデバイス３００、オペレーショナルサポートシステム（ＯＳＳ）７００、コンテンツフィード５００、及びユーザインターフェース（ＵＩ）ソース６００を備えている。使用時には、サーバ１００は、モバイルデバイス３００，３０１・・・にコンテンツデータ及びＵＩデータを通信する。モバイルデバイスの各々は、ソフトウェアパッケージ４００を含む。サーバ１００は、ＯＳＳ７００とインターフェースする。ここで、ＯＳＳは、例えば課金、アカウント管理等のようにモバイルネットワークを操作するために従来から使用されている。サーバ１００は、更に、コンテンツツールセット２００とインターフェースする。コンテンツツールセットは、ＵＩソース６００、６０１・・・からデータを受信し、ＵＩデータをパッケージする。これによって、モバイルデバイス３００内に含まれたソフトウェアパッケージ４００に、パッケージ化されたＵＩデータを送信できるようにする。サーバは、複数個のコンテンツフィードからデータを受信する。このデータは処理され、パッケージ化される。これによって、データが、ソフトウェアパッケージ４００へ送信されるようになるか、モバイルデバイス３００が、このソフトウェアパッケージ４００を用いてデータにアクセスすることができる。

このシステムは、３つの個別のドメインに分割されていると考えることができる。オペレータドメイン５０は、モバイルネットワークオペレータ（ＭＮＯ）によって操作されるシステムおよび設備を含む。ユーザドメイン６０は、複数個のモバイルデバイスを含む。また、サードパーティドメイン７０は、多くの異なるエンティティによって制御又は操作されうるＵＩフィード及びコンテンツフィードを含む。

図２は、サーバ１００の構造及び動作をより詳細に示している。サーバ１００は、公開コンポーネント１１０と、コンテンツサーバコンポーネント１５０とを含む。公開コンポーネントは、データベース１１１、インポートキュー１１２、コンテンツツールセットインターフェース１１３、ユーザインターフェース１１４、及びカタログ１１５を含む。動作時に、公開コンポーネントは、コンテンツツールセットインターフェースにおいて、コンテンツツールセットからコンテンツを受信する。コンテンツは、一つ又は複数のＴｒｉｇ、及び一つ又は複数のＴｒｉｇｌｅｔを含むパーセル（ｐａｒｃｅｌ）２１０Ａ、２１０Ｂ・・・（下記参照）の形式で示される。Ｔｒｉｇは、携帯電話のようなモバイルデバイス用のユーザインターフェースであり、Ｔｒｉｇｌｅｔは、Ｔｒｉｇを拡張又は変更するために使用することができるデータファイルである。パーセルが、１より多いＴｒｉｇを含む場合、Ｔｒｉｇのうちの１つは、他のＴｒｉｇが導出されるマスタＴｒｉｇかもしれない。公開コンポーネントユーザインターフェース１１４は、データベース１１１へパーセルをインポートするために使用することができる。また、このプロセスは、各Ｔｒｉｇ及びＴｒｉｇｌｅｔへのリファレンスを、インポートキュー１１４にロードさせる。インポートキュー１１４は、複数のパーセル２１０ａ，２１０ｂ・・・へのリファレンスを含むかもしれない。パーセルのコンテンツは、ユーザインターフェースを使用して調べられるかもしれない。また、パーセルのコンテンツはカタログに渡すことができる。

ＭＮＯは、例えば、多くの国々あるいは地域における各目標サーバに対して一つのように、幾つかの公開ドメインを持っているかもしれない。各ドメインはそれぞれ、他のドメインから分離して扱われ、目下及び計画中の両方のステージング環境にあるコンテンツサーバ上にオブジェクトをどのようにして公開するかを説明するそれ自身の公開スキームがある。公開コンポーネントＧＵＩは、各ドメインにいくつかの異なる見方を与える。これによって、オペレーターは、コンテンツの公開を完全に管理できるようになる。カタログは、カタログに格納されたＴｒｉｇへの参照と、様々なドメインへコンテンツを転送するために使用されるフィードチャネル及び更新チャネルとを含む。各ドメインについて、オペレーターは、ドメイン構造を設定し、かつカタログから各ドメインノードにＴｒｉｇを割り付けるために、公開コンポーネントＧＵＩを使用する。オペレーターがＴｒｉｇを効率的に選択するのを援助するために、関連する項目だけが示されるように、カタログ内にフィルタが提供される。

Ｔｒｉｇは、ドメイン内のいくつかのノードに割り付けられるかもしれない。それぞれの場合、目標サーバ上のＴｒｉｇのパッケージングは、例えばＳＩＳかＣＡＢファイルのように、Ｔｒｉｇにアクセスする送受話器に依存して異なる必要があるかもしれない。このパッケージングは、公開コンポーネントＧＵＩを使用して制御することができる。

コンテンツの配信を制御するために、更新チャネルがＴｒｉｇによって参照されるかもしれない。更新チャネルは、Ｔｒｉｇｌｅｔ更新パッケージを含む関連するドメイン上のリソースへのリンクであるＵＲＬを含む。このＵＲＬは、再定義された間隔で獲得することができる。また、ＨＴＴＰ ＧＥＴ機能が、パッケージにアクセスするために使用される。（例えば、ＳｙｎｃＭＬ又はＳＭＳ又は小規模の更新のためにブロードキャストされたセルのように、その他の転送スキームが使用されうることが容易に認識されるだろう。）Ｔｒｉｇｌｅｔ更新パッケージは、例えば、Ｔｒｉｇによって使用されるテキストファイル又は一つ以上の画像を交換することのように、どのようにＴｒｉｇを変更できるかを説明する。オペレーターは、公開コンポーネントＧＵＩによって、ドメインのために存在する更新チャネル、更新チャネル上の各Ｔｒｉｇｌｅｔに関連したＵＲＬ、及びドメインのための更新チャネルを備えたＴｒｉｇｌｅｔの関連性を定義し制御することができる。Ｔｒｉｇｌｅｔがそれぞれ更新チャネルに関係しているので、オペレーターは、更新版が公開されるべき日付および時間を入力してもよい。これによって、スケジュールが設定される。

コンテンツフィードは、ＵＲＬを獲得し、更新パケットを検索し、Ｔｒｉｇにそれを適用することによりアクセスされる。しかしながら、マニュアルで構築されたＴｒｉｇｌｅｔ更新版と、自動生成されたコンテンツとの異なる性質のために、更新チャネルと、コンテンツフィードとは別々に管理される。また、例えば、ＳｙｎｃＭＬ又はＯＭＡ−ＤＭ（Open Mobile Alliance Device Management）のような、その他の転送スキームが使用されるかもしれない。

オペレーターは、どのコンテンツフィードが、各ドメイン、及び例えばＵＲＬのように、コンテンツがポストされるプラットフォーム特有の位置識別子内で利用可能であるべきかを定義することができる。オペレーターは、公開コンポーネントＧＵＩ内の個別のスクリーンを使用して、コンテンツフィード自体を定義する。この段階における全てのドメイン公開スキーム情報は、データベース内に保持される。

既存の目下のドメインが変更されることになっている場合、公開コンポーネントは、目下のドメイン構造のコピー上で作動し、例えばｔＴｒｉｇの除去又は追加のようなドメインへ行なわれる変更を定義する。公開スキームに割り付けられた個々のＴｒｉｇ又はＴｒｉｇｌｅｔは、それらが元々インポートされたパーセルを参照する。これによって、公開コンポーネントは、それらを後にコンパイルすることができる（下記参照）。

代替実施例では、更新パケットは、異なる手法でアクセスすることができる。インターフェースがデータベース１１１に提供される。これによって、インターフェースは、コンテンツ更新版を要求するために、デバイスによって獲得されるようになる。データベースは、関連するコンテンツ更新パケットの位置のための入力を保持する。これは、その後、デバイスに返される。デバイスは、次に、適切なＵＲＬを獲得することによって、コンテンツ更新パケットにアクセスすることができる。コンテンツが端末へ最初に発行され、システムにある種の自動化を与える場合、更新版の位置を識別することはもはや必要ではないので、この代替アプローチは、コンテンツフィードの管理および動作を著しく単純化する。データベースが更新される限り、全てのデバイスに変更を通知する必要は無いので、コンテンツ更新版が必要に応じて位置決め（更に再位置決め）されるかもしれない。

オペレーターは、例えば、拒否された項目及び変更点のみ、マークされた変更点があるか又は変更点がない最終提案構造（承認済み及び／又は未決定の項目）、及びオリジナル構造（すなわち、現在動作中である）のような開発中のドメイン上の異なるビューを選択することができる。公開コンポーネントＧＵＩは、ドメインへまだ割り付けられていない更新チャネル又はコンテンツフィードを参照するＴｒｉｇ又はＴｒｉｇｌｅｔが含まれている場合には、ドメインスキームが公開されることを阻止する。一旦公開スキームがテストされる準備ができれば、それはテストのためにドメインのステージングサーバに公開される。

この公開要求は、サーバによって処理され、コンパイルされていない全てのＴｒｉｇとＴｒｉｇｌｅｔ（承認済及び未決定のものの両方）をコンパイルすることと、未決定及び承認済みの両方の提案された全ての変更をステージングサーバにエクスポートすることとを含む（これは、新たなＴｒｉｇ、既存のＴｒｉｇに対する更新版、公開のためのＴｒｉｇｌｅｔ遅れ（テスト日に従う）、及びＴｒｉｇとＴｒｉｇｌｅｔとノードとの削除を含む。）。編集段階において何らかの失敗があれば、どの項目も公開されないだろう。公開し続けることを可能にするために、不快な項目は却下されるか、修正されねばならない。ＭＮＯのステージングサーバでは、ドメインはモバイルデバイスを使用してテストすることができる。そのテストに合格する各項目は、公開コンポーネントＧＵＩを用いて「承認済み」と印付けることができる。テストに合格しない項目は「却下」というように印付けることができる。修正されたＴｒｉｇ／Ｔｒｉｇｌｅｔは、公開コンポーネントへインポートされ、ドメインへ再提示され、次に、上述したようなステージングサーバに公開される。全ての項目が承認され、ドメインが目下の環境へ公開する準備ができるまで、このプロセスは継続する。更に、ドメインのステージングエリアでは、スケジュールされた更新版をテストすることができるように、時間の経過を模擬することが可能である。いくつかのＭＮＯはステージングサーバ機能を必要としないかもしれない。したがって、ドメインスキームが設定された時、公開されるべき全ての項目が、承認されたものとして印付けられ、もって、オペレーターは、目下の公開に直接進むことができる。

公開コンポーネントＧＵＩは、目下の領域及びステージング領域の両方のために、ドメインの各々の見方を提供する。この観点から、コンテンツフィードの自動公開と、各更新チャネル上でのＴｒｉｇｌｅｔのスケジュールされた公開との開始及び停止が可能である。

テストを終えると、ドメインは、承認済みとして印付けられたドメイン変更のみが公開される点を除けば、上述したものに類似したプロセスを用いて、サーバの目下のエリアに公開されるかもしれない。公開スキームを設定する場合、個々のＴｒｉｇ及びＴｒｉｇｌｅｔを公開する日付および時間が設定されるかもしれない。ドメインが公開の準備ができていることを要求するとすぐに、公開コンポーネントは、項目に関連した公開の日付又は時間が未来であっても、全てのＴｒｉｇ及びＴｒｉｇｌｅｔがコンパイルされることを保証する。目標ドメインエリアにディスパッチされる準備ができるまで、将来に日付された項目は、公開コンポーネントデータベースに残る。スケジュールされた公開プロセスは、設定された間隔で、各目標ドメインエリアを取得し、ディスパッチＡＰＩを経由して適切なドメイン目標へ公開する期限になった、あるいは期限を過ぎたあらゆるスケジュールされた項目をディスパッチする。

コンテンツフィードは、例えばウェブスクラッピング、ＲＳＳニュースフィード等の外部ソースから抽出されている動的なコンテンツを用いて、規則的な間隔で更新される。動的コンテンツは、単純なニュースティッカーテキスト（ヘッドライン及びＵＲＬ）かもしれないが、コンテンツツールボックスを使用して交換されるかもしれないより複雑なタイプのオブジェクトをも含むかもしれない。コンテンツフィードプロセスは、更新ファイルへこのコンテンツをフォーマットし、次に、フィード制御に返す。

フィード制御は、更新ファイル及びコンテンツフィードに関連したＴｒｉｇｌｅｔパーセルテンプレートをコンパイラへ渡すコンパイルＴｒｉｇプロセスを含む。コンパイラは、Ｔｒｉｇｌｅｔパーセル内のリソースを抽出し、コンパイルされたＴｒｉｇｌｅｔを、公開可能なフィード制御へ返す（上記参照）。

各Ｔｒｉｇ又はＴｒｉｇｌｅｔがコンパイルされるために、コンパイラは、次の情報を必要とする。Ｔｒｉｇ／Ｔｒｉｇｌｅｔがインポート又は作成されるオリジナルのパーセル。作成されるＴｒｉｇ／Ｔｒｉｇｌｅｔ更新パッケージのリスト。作成されるファイルのタイプ。更新チャネルおよびコンテンツフィードのためのＵＲＬマップ。コンパイラは、各パーセル内の個別のＴｒｉｇ及びＴｒｉｇｌｅｔ内の更新チャネル（及びコンテンツフィード）によって参照付けられたＵＲＬを更新するためにＵＲＬマップを使用する。ディスパッチＡＰＩは、ＭＮＯのサーバにコンテンツをディスパッチするために使用される。参照ＦＴＰモデルは、ＡＰＩにサービスし、コンテンツサーバへファイルを転送するために実装された。しかしながら、ＡＰＩメカニズムによって、積分器は、例えば、自分のコンテンツ管理システムのＡＰＩへの入力として公開コンポーネント出力を使用し、もし要求されればカスタムロジックを加えることによって、自分のコンテンツディスパッチメカニズムを実装することができる。

公開コンポーネントは、公開コンポーネントＧＵＩ、及び業界標準ＡＰＩ（ＪＭＸ）を経由してアクセス可能な従来のＯＳＳ機能をサポートする。これによって、ＳＩは、標準的な統合ツールを用いて、公開コンポーネントを、ＭＮＯのＯＳＳ環境に統合することが可能となる。これは、重要な公開コンポーネットイベントと全てのインポート及び公開された項目と、外部スクリプトで言及されたあらゆる変化に対する電算機処理監査、メインテインエラー／警告ログ、システムアラーム、健康チェック報告書等のロギングを含む。公開コンポーネントに関係のある全てのデータは、例えばＯｒａｃｌｅのようなデータベース内に格納され、バックアップ及び修復機能が、ＯＳＳ環境と統合された標準的なデータベースプロセスによってサポートされている。動作について、公開コンポーネントは、オペレーティングＪ２ＥＥ環境と、例えばＯｒａｃｌｅのようなインストールされたデータベースのインスタンスとを必要とする。公開コンポーネントのインストールは、インストール処理が成功し、コンポーネントが全て正しく起動したことを示すプロセスによって有効とされる。

コンテンツサーバコンポーネント１５０は、ウェブサーバの標準的な実装であるので、スケーリングモデルは良く知られている。サーバの機能は、ウェブサーバがベンチマーク条件の下で取り扱うことができる同時セッション番号を示す「ＳＰＥＣｗｅｂ９９」番号を使用して評価することができる。公開のＳＰＥＣｗｅｂ９９番号は、５，０００の順序のＳＰＥＣｗｅｂ９９番号を持つ典型的な商用ウェブサーバで４０４〜２１，０００に及ぶ。１時間毎に更新されるコンテンツを持った１００万人からなる加入者の典型的な展開シナリオは、１，１１２のＳＰＥＣｗｅｂ９９格付けを備えたウェブサーバのみを要求する。成功した展開は、故障に対してスケーラブルかつ高い回復力を備えうるインフラストラクチャーを追加サーバが作成可能とすることによって提供できる増加されたサービス利用に結びつくだろう。

接続は、モバイルデバイスからサーバへとＷＡＰゲートウェイ経由でなされうる。この場合、ウェブサーバセッションは、携帯電話とウェブサーバとの間ではなく、ＷＡＰゲートウェイとウェブサーバとの間に存在する。ＷＡＰゲートウェイ経由で、ファイルに対する要求がなされる場合、ウェブサーバからＷＡＰゲートウェイへファイルを転送するために必要な時間だけ、ウェブサーバとのセッションは続く。つまり、接続帯域幅が非常に高くなるので、セッションは非常に短く、待ち時間は極端に短い。

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

コンテンツサーバコンポーネントによって配信されるコンテンツには２つのタイプがある。すなわち、一般に１００ＫＢのオーダを持つＴｒｉｇと、一般に１ＫＢのオーダを持つＴｒｉｇｌｅｔである。Ｔｒｉｇダウンロードによって作成されたトラフィックは、既存のコンテンツダウンロードによって生成されたトラッフィックに非常に似ている。従って、関連する問題は、よく知られている。規則的なＴｒｉｇｌｅｔ更新版のダウンロードは、ＭＮＯのトラフィックモデルにおける新しい特徴であるが、一般に更新版は、１つのデータパケット内にフィットするような小さなサイズであるので、典型的なウェブサーバによってトラフィックを取り扱えることを示すことが可能である。

Ｔｒｉｇｌｅｔダウンロードの場合、一般には、１ＫＢを転送するために１つのデータパケットのみが要求される。ＧＰＲＳネットワークによる往復待ち時間を２秒と仮定すると、ウェブサーバは、約４秒間、一般的なセッションをオープンに保持する必要があるだろう。毎時間更新するコンテンツを備えた電話にＴｒｉｇを持つ１００万人の加入者のシナリオの場合、これは、ウェブサーバ上への毎秒２７８回のヒット、および１，１１２の同時セッションを意味する。前述した通り、この数は、典型的なウェブサーバの機能内で適切である。

図３は、モバイルデバイス３００用のソフトウェア４００の概要を示す。ソフトウェア４００は、マークアップ言語レンダラ４１０、更新マネージャ４２０、ネットワーク通信エージェント４２５、リソースマネージャ４３０、仮想ファイルシステム４３５、アクタ（ａｃｔｏｒ）マネージャ４４０、複数のアクタ４４５ａ、４４５・・、在来の（ｎａｔｉｖｅ）ＵＩレンダラ４５０、サポートマネージャ４６０、Ｔｒｉｇマネージャ４６５、及びマークアップ言語パーサ４７０を含む。

このソフトウェアはＴｒｉｇＭＬを用いて動作するかもしれない。ＴｒｉｇＭＬは、ＸＭＬアプリケーションであり、マークアップ言語レンダラ４１０は、モバイルデバイス３００上のディスプレイのためにＴｒｉｇＸＭＬコードを返す。ＴｒｉｇＭＬは、２００４年２月１９日に出願された同時係属中の英国特許出願ＧＢ０４０３７０９．９に記載されている。その内容は、参照によってここに組込まれる。

マークアップ言語レンダラはまた、ＴｒｉｇＭＬリソース、デバイススクリーン上のディスプレイコンテンツ、送受話器上のコンテンツの置換と観察との制御及び解析のためにＴｒｉｇＭＬパーサを用いる。在来のＵＩレンダラは、ＴｒｉｇＭＬを用いることなく表示可能なＵＩコンポーネントを表示するとともに、エラーメッセージを表示するために使用される。

ソフトウェア４００は、デバイス特有の手法で準備されインストールされる。同様に、ソフトウェア最新版が、デバイス特定の手法で取り扱われる。このソフトウェアは、ビルトインコンテンツのみを返す内蔵式アプリケーションのように、より制限されたフォーマットで供給される。つまり、このソフトウェアは、ビルトインされたＴｒｉｇを用いて供給されるが、追加のＴｒｉｇを後に追加することができない。供給されたＴｒｉｇは、無線によってアップグレードされるかもしれない。

リソースマネージャは、デバイス上の持続的な記憶装置の抽出を提供する、つまりデータベース内のレコード、又は実際のファイルとしてこのファイルを格納する。リソースマネージャは、マークアップ言語レンダラ及び更新マネージャに、ファイルシステムインターフェースを提示する。それは、パスロジックを取り扱い、実際のリソースファイルとアクタ属性とを識別し、Ｔｒｉｇ関連パスを絶対パスにマップし、Ｔｒｉｇマネージャとインターフェースし、変更インターフェースを更新マネージャに提供することに責任を持つ。

更新マネージャは、ＴｒｉｇとＴｒｉｇｌｅｔの受け取り、及び応用を取り扱う。更新マネージャは、レンダラおよびＴｒｉｇマネージャにインターフェースを提示し、以下に責任を持つ。すなわち、レンダラによって指示された場合におけるマニュアル更新の開始と、Ｔｒｉｇマネージャによって設定された場合、自動的な更新チャネルの制御及び実施と、マニュアル更新の進行の表示及び、ネットワーク接続及び／又はデバイス電力の予期しない喪失後の更新の回復とである。更新パケットフォーマットは、ＸＭＬスキーマの２進法の連続として定義されうる。

サポートマネージャは、他のコンポーネントが、イベント又はエラーの発生を報告するためのインターフェースを提供する。エラーの厳しさによって、サポートマネージャは、イベントを記録し、及び／又はエラーメッセージポップアップを上げる。アクタマネージャ４４０は、ソフトウェアに存在するアクタ４４５の集合を世話する。それは、コンテンツがアクタへイベントを送っている場合、レンダラによって使用される。アクタは、属性値が変わったことを通知することを希望し、イベントを出力することを希望している（以下参照）。

ソフトウェア４００は、デバイス特定の方法でモバイルデバイスに供給される。例えば、圧縮されていない更新パケットとして格納された一つ又は複数のＴｒｉｇが、インストールの一部として供給される。起動時においては、パケットが展開され、ファイルシステムにインストールすることができる。

アクタ４４５は、属性値を公開し、イベントを扱い、発行するコンポーネントである。

アクタは、レンダラと同期して通信する。アクタが非同期的な振る舞いを必要とすれば、レンダラの主要なスレッドの外部にあるスレッドを管理し、それと通信することはアクタの責任である。

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

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

アクタは、それに＜ｔｈｒｏｗ＞要素を備えたイベントを送ることによりメッセージを送ることができる。アクタによって発行されたイベントは、コンテンツイベントとしてコンテンツツリーに配信することができる。これらは要素Ｉｄ又は「ｔｏｐ」において目標とされうる。アクタへのインターフェースは、アクタインターフェース定義ファイルによって定義される。これは、属性、タイプ、フィールド名、イベントインとパラメータ、及びイベントアウトを定義するＸＭＬドキュメントであるアクタの集合は、ソフトウェアのための構築時間において構成可能である。付録Ａは、関連する機能あるいは変数とともに使用されるかもしれない幾つかのアクタの典型的なリストを与える。

更新は、新たなＴｒｉｇ（新しいか置換ＵＩ）あるいはＴｒｉｇｌｅｔ（既存のＴｒｉｇへの変更）を含み、ソフトウェアファイルシステムへの変更と見なされるかもしれない。更新マネージャは、パケットを読むことによって、ファイルシステムの中で何が変更を必要としているのかを決める。更新パケットは、ＨＴＴＰを用いて、ソフトウェア４００によってか、デバイス特有のパッケージフォーマット内にラップされたか、又はそのソフトウェア自身のインストールに予め供給されたその他の適切な伝送メカニズムによって無線を介してダウンロードされる。

更新は、以下を含む多くの手段によって引き起こされる。・ソフトウェアが、起動時において中断された更新処理をチェックすること。・ソフトウェアが、起動時において予めインストールされた更新パケットをチェックすること。・更新チャンネルによって設定されたように自動的に。・ユーザによる始動。・デバイスが、特別なＳＭＳを受信すること。

ＯＴＡを送った更新版は、ソフトウェアによって開始されたＨＴＴＰ−ＧＥＴ要求を用いて取得することができる。このＧＥＴ要求は、更新版に関連したＵＲＬに向けられる。ＨＴＴＰ応答のボディは、更新パケットフォーマットの中でデータを搬送するバイナリファイルである。データ受信は、レンダラスレッドに個別のスレッド内で取り扱われる。バックグラウンド更新（自動的に開始される）は、ユーザがＵＩをナビゲートし続けることを可能にする。フォアグラウンド更新（マニュアルで開始される）は、レンダラスレッドが、進行バーを表示し、キャンセル命令を聞き取ることを可能にする。

Ｔｒｉｇは、更新チャンネルを定義する。更新チャネルは、更新のための問い合わせのためのＵＲＬと、多くの関連する特性、すなわち、自動又はマニュアル更新、故障のイベントにおけるリトライ方針とタイミングスキームとを含んでいる。動作している場合のみ、ソフトウェアは自動更新を開始するかもしれない。

起動時に、更新イベントが予定されているのであれば、ソフトウェアは、更新を始める前にある時間待機するであろう。これは、更新を直ちに始めることにより必要とされるあらゆる起動遅延を先送りするためであり、これによって、ユーザにより速い起動を与えるだろう。更新チャネルは、例えば、＜チャネル＞タグを含んでいるファイル内のＴｒｉｇのコンフィグ／チャネルフォルダーのように、Ｔｒｉｇ内の良く知られた位置内に定義されるかもしれない。

更新版を解き、インストールするために使用されるアルゴリズムは、デバイス特有である。しかしながら、アルゴリズムが、ファイルシステム内において損傷又は回復不能の状態に達することのないように、予期しない妨害（例えば、電力喪失）から安全であることは重要である。これは、可能な限り短い時間でレンダラスレッドを中断させることができるように、ネットワークスレッドによって実行されるのに可能な限りの多く更新処理を持つという目標を持つ２つのスレッド（ネットワークスレッドとレンダラスレッド）を用いることによって達成される。

他に考慮すべき故障モードがある。ＨＴＴＰ−ＧＥＴを始めることができないか、ＨＴＴＰエラー応答コードを満足する場合、更新版においてこの試みは破棄される。そして、後日、新たな更新試行を開始するためにリトライ方針が使用される。ＨＴＴＰ応答がネットワーク信号の喪失によって中断される場合、任意のテンポラリファイルが削除され、後日、更新試行を再開するためにこのリトライ方針が使用される。更新ペイロードサイズが大きすぎて、デバイスに適合できないことを更新ヘッダが示す場合、更新版がソフトウェアの非互換性のバージョンを要求する場合、あるいは更新版がデバイス上で既に存在する場合、ヘッダーデータファイルは削除され、更新試行及び任意の後の再試行もキャンセルされる。

コンテンツフォーマットは、ソフトウェアを実装する全てのプラットフォームにわたって共通である。コンテンツコンパイラは、生のリソース（テキストＴｒｉｇＭＬ、ＰＮＧイメージ、テキスト文字列定義）の集合を、デバイスのファイルシステムへ書き込むことができる無線による更新パケットに変換するためのコンテンツオーサリングツールである。

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

パーセルと称されるコンテナは、サードパーティ用のテンプレート、ＵＩ更新、及びＵＩのために使用される。パーセルは、サードパーティが、ブランド付けされたＵＩ及び更新版を生産し、テストし、配信するために必要な全ての情報を含んでいる。図４は、コンテンツツールセット２００の概要図を示す。これは、スクリプト環境２２０と、テスト及びシミュレーション環境２３０と、メンテナンス環境２４０とを含む。

パーセルプロセスは、以下の５つのプロセス段階を含む。１）スクリプト環境２２０が、テンプレートに基づいて、１つ又は複数のＵＩのためのテンプレートと、そのテンプレートに基づいたＵＩのための更新方針とを設計する手段を提供する。２）メンテナンス環境２４０が、コンテンツプロバイダに外部委託可能な良く制御されガイドされた環境中の迅速なＵＩ及び更新生産に備える。３）メンテナンス環境２４０「プレフライト行」機能が、サードパーティから受け取ったＵＩ及び更新版を展開管理者がチェックし、調整することを可能にする。４）公開コンポーネント１１０が、新製品のステージングを含む展開ポイントにおいて、ＵＩと更新版の管理を提供する。５）公開コンポーネント１１０が、目下のコンテンツフィードからの更新版の自動生成を可能にする。

典型的な計画では、パーセルは次のもののためにスクリプト環境２２０内で作成される。すなわち、同じ「感覚」であるが、異なる「外見」を組み込んで、再びブランド付けされたＵＩをテンプレートから作成するコンテンツプロバイダ。周期的、又はユーザ選択されたバリエーションをＵＩコンテンツに提供する更新版を、テンプレートから作成するコンテンツプロバイダ。周期的ベースで新しいサービスを促進し、テンプレートから更新版を作成する広告代理店。

これら全ての用途のために、メンテナンス環境２４０は、パーセルをインポートし、コンテンスを再びブランド付けして再構成し、公開コンポーネント１１０への再提示のための新しいパーセルを作成するために使用される。ＵＩテンプレートの設計では、以下の問題が考慮されるべきである。ＵＩのどの部分が、再ブランド付け可能であるのか。ＵＩのどの特徴が、再ブランド付けにおいて、あるいは遠隔から再構成される必要があるのか。ＵＩコンテンツのどの部分が更新されて良いのか。そして、ＵＩが再ブランド付けされると、ユーザは、使用中のコンテンツフィードを選択することができる。スクリプト環境２２０は、これらの方針が定義されることを可能にし、各方針の各インスタンスの実装者としてメンテナンス環境２４０を可能にする。

パーセルフォーマットは、連続したオブジェクトとしてこの情報をすべて格納する解しがたいバイナリフォーマットである。パーセルは、イメージ、テキスト、ＵＲＬ、更新チャネル、着メロファイル、壁紙、在来のアプリケーション等のような多くのリソースを含むかもしれない。リソースはそれぞれ、リソースをどのように閲覧し、編集し、削除するかに関する許可情報を含んでいる。更に、各リソースは、そのリソースに適切なドキュメンテーションおよび命令のようなメタ情報を含んでいる。各パーセルツールは、それぞれ適切な役割を引き受けるか、あるいは特定の役割としてログインすることをユーザに要求する。

図５は、本発明の実施例に従ったユーザインターフェースを含むデバイス８００の概要図を示す。デバイスは、ユーザインターフェース８１５を表示するディスプレイ８１０と、ユーザが、ユーザインターフェース８１５と相互作用することを可能にするユーザインターフェース手段８２０とを含む。プロセッサ８３０は、他のデバイス及び／又は通信ネットワークとの通信を可能にするために、１つ又は複数の記憶手段８４０内に格納され、１つ又は複数の無線通信インターフェース８５０に供給されるかもしれないソフトウェアを実行する。１つ又は複数のバッテリー８６０が、デバイスに電力を供給するために認められるかもしれない。それは、電力を受け取るためのインターフェース及び／又は通信ケーブルを含むかもしれない。

これらのコンポーネントとインターフェースの性質は、デバイスの性質に依存するだろう。モバイル又は携帯電話の送受話器内にそのようなユーザインターフェースを実装することができるが、また、例えばディジタルカメラ、パーソナルディジタルオーガナイザ、デジタル音楽プレーヤ、ＧＰＳナビゲータ、ポータブルゲームコンソール等の他のポータブル機器にも適用可能であることが理解されるであろう。更に、ラップトップ又はデスクトップコンピュータのように、ユーザインターフェースを備えたその他のデバイスにも適用可能である。

ユーザインターフェース手段は、数字あるいは英数字キーボードのような複数個のボタン、あるいはタッチスクリーンやそれに類似したものを含むかもしれない。電力喪失時に、格納されたデータが失われないように、１つ又は複数の記憶装置が、メモリカードのような不揮発性のメモリの形式を含むかもしれない。ＲＯＭ記憶手段は、更新又は変更を必要としないデータを格納するために提供されうる。より速い応答時間は、頻繁にアクセスされるデータのキャッシュをサポートするので、ＲＡＭが一時記憶域として供給されるかもしれない。また、端末は、ユーザ除去可能なメモリカードを受け入れるかもしれない。また、オプションとして、ハードディスクドライブが、記憶手段として使用されうる。使用される記憶手段は、デバイスサイズ、電力消費量、要求される記憶ボリューム等の異なる要件の釣り合いから決定されるだろう。

そのようなデバイスは、例えば第二世代デジタル携帯電話ネットワーク（すなわち、ＧＳＭ（登録商標），Ｄ−ＡＭＰＳ）、いわゆる２．５Ｇネットワーク（すなわちＧＰＲＳ、ＨＳＣＳＤ、ＥＤＧＥ）、第三世代ＷＣＤＭＡ又はＣＤＭＡ−２０００ネットワーク、及びこれらに類似のネットワークの改良及び派生のような実質的にあらゆる無線通信ネットワークと連携して実装されうる。建物やキャンパス内では、例えばＢｌｕｅｔｏｏｔｈ（登録商標）、ＩｒＤａ、又は無線ＬＡＮ（無線または光学システムであろうと）のような他の技術も使用されうる。ＵＳＢ及び／又はＦｉｒｅＷｉｒｅ接続は、他のデバイスとのデータ同期、及び／又はバッテリー充電のために供給される。

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

本出願は、その内容が、参照によってここに組込まれている２００４年２月１９日に出願された英国特許出願ＧＢ０４０３７０９．９の利益を要求する。

Claims (14)

1. デバイスへのユーザインターフェース用のコンテンツデータを受信する方法であって、
   前記デバイスが、通信インターフェースから、ユーザインターフェース用のコンテンツデータを受信することと、
   前記デバイスが、前記受信したコンテンツデータを処理して、前記デバイスのためのユーザインターフェースを形成することとの各ステップを含み、
   前記コンテンツデータは、メタデータを含み、前記方法は更に、前記デバイスが、前記メタデータに従って、前記通信インターフェースを経由してコンテンツデータ更新版にアクセスするステップを含む方法。
2. 請求項１に記載の方法において、前記メタデータは、コンテンツデータ更新版のためのアドレスを含み、前記デバイスは、前記アドレスに位置された前記コンテンツデータ更新版にアクセスする方法。
3. 請求項１に記載の方法において、前記メタデータは、第１のアドレスを含み、前記デバイスは、第２のアドレスを得るために第１のアドレスに問い合わせを行い、前記デバイスは、前記第２のアドレスに位置している前記コンテンツデータ更新版にアクセスする方法。
4. 請求項３に記載の方法において、前記第１のアドレスは、データベースの場所を突き止め、前記データベースは、複数のコンテンツデータ更新版のためのアドレスを含む方法。
5. 請求項１乃至４のうち何れか１項に記載の方法において、前記メタデータは、前記デバイスがコンテンツデータ更新版にアクセスする頻度を決定するデータを含む方法。
6. 請求項１乃至５のうち何れか１項に記載の方法において、前記メタデータは、前記デバイスをコンテンツデータ更新版にアクセスさせるイベントを定義するデータを含む方法。
7. 請求項１乃至６のうち何れか１項に記載の方法において、前記デバイスによってアクセスされたコンテンツデータ更新版は、前記通信インターフェースを経由して受信され、前記デバイスによって処理され、前記デバイスユーザインターフェースを更新するために使用される方法。
8. 請求項１乃至７のうちの何れか１項に記載の方法を実行するためのコンピューター実行可能なコードを含むデータ記憶媒体。
9. デバイスであって、
   ユーザインターフェースと、
   前記ユーザインターフェースを表示するための表示手段と、
   前記ユーザインターフェース内で使用されるコンテンツデータを受信するための通信インターフェースと、
   受信したコンテンツデータを処理し、前記ユーザインターフェースを形成する処理手段とを備え、
   前記コンテンツデータは、メタデータを含み、前記デバイスは、前記メタデータに従って前記通信インターフェースを経由してコンテンツデータ更新版にアクセスするように構成されたデバイス。
10. 請求項９に記載のデバイスにおいて、前記メタデータ内に含まれたアドレスにおいて、コンテンツデータ更新版にアクセスするように構成されたデバイス。
11. 請求項９に記載のデバイスにおいて、前記デバイスは、前記メタデータ内に含まれたアドレスを問い合わせるように構成され、前記問い合わせの結果は、コンテンツデータ更新版を識別する第２のアドレスであるデバイス。
12. 請求項９乃至１１のうち何れか１項に記載のデバイスにおいて、前記メタデータは、予め定めた頻度で、コンテンツデータ更新版にアクセスするように前記デバイスを設定するデータを含むデバイス。
13. 請求項９乃至１１のうち何れか１項に記載のデバイスにおいて、前記メタデータは、あらかじめ定義されたイベントに応じてコンテンツデータ更新版にアクセスするように前記デバイスを設定するデータを含むデバイス。
14. 請求項９乃至１３のうち何れか１項に記載のデバイスにおいて、前記通信インターフェースを経由してコンテンツデータ更新版を受信し、前記受信したコンテンツデータ更新版を処理し、前記デバイスユーザインターフェースを更新するように更に構成されたデバイス。

Images