JP2007305120A - プッシュコンテンツメタデータに対する多層化エンベロープされた方法およびシステム - Google Patents

Abstract

【課題】移動環境における動的コンテンツ配信において、アプリケーションおよびコンテンツプロバイダが、アーキテクチャを変更することなく、追加され得るジェネリック動的コンテンツ配信アーキテクチャを構築するため、コンテンツペイロードに処理知能を追加する方法を提供すること。
【解決手段】少なくとも第一の処理エレメントおよび第二の処理エレメントを有する動的コンテンツ配信アーキテクチャにおいて、コンテンツペイロードに処理知能を追加する方法であって、コンテンツペイロードを備える第一のエンベロープと、該第二の処理エレメント上でランされるように適合した第二の処理エレメントメタデータとを生成するステップと、該第一のエンベロープを含む第二のエンベロープと、該第一の処理エレメント上でランされるように適合した第一の処理エレメントメタデータとを形成するステップとを包含する、方法。
【選択図】図１

Description

本方法およびシステムは、移動環境における動的コンテンツ配信に関する。より具体的には、アプリケーションおよびコンテンツプロバイダが、アーキテクチャを変更することなく、追加され得るジェネリック（ｇｅｎｅｒｉｃ）動的コンテンツ配信アーキテクチャに関する。

移動デバイスまたは移動ユーザ設備（ＵＥ）のユーザは、ユーザが自身の移動デバイスに要求する機能と、ユーザが移動デバイスからデータにアクセスする方法とに関して、ますます洗練されるようになってきている。

動的コンテンツ配信によって、ユーザは、自らデータを探しに行く必要なしに、むしろ、プッシュされた情報またはデータを入手することができる。データの例には、株価、天気の最新情報、交通の最新情報、動的壁紙、広告、アプリケーション、あるいは、ユーザが望む他のデータが含まれ得る。

無線アプリケーションプロトコル（ＷＡＰ）のような移動デバイスの現在の技術は、コンテンツをする能力を有する。しかしながら、ＷＡＰは、無線アプリケーションプロトコルを満足させ、ユーザのサイトを見る能力に適応するために変わらない均一なサイトを提供するために、ウェブサイトを書き換えることを要求する。

他の代替は、ＳＭＳをベースとするプッシュ・アンド・ブロードキャスト（ｐｕｓｈ ａｎｄ ｂｒｏａｄｃａｓｔ）またはセル・ブロードキャスト（ｃｅｌｌ ｂｒｏａｄｃａｓｔ）を含む。ブロードキャストの場合、配信は、特定のユーザまたは特定機器の能力のニーズによってカスタム化され得ない。それゆえ、これらのシステムは、それらのニーズと関連する知能（ｉｎｔｅｌｌｉｇｅｎｃｅ）を一切有しない。移動デバイスに対して、より良き解決策が求められている。

現在のシステムおよび方法は、一般的なアプリケーションおよびコンテンツプロバイダが、アーキテクチャを改変する必要なしに、システムに追加されることを可能にする動的コンテンツ配信アーキテクチャおよびシステムを提供することが好ましい。具体的には、現在のシステムおよび方法は、移動デバイスが、その移動デバイスにアプリケーションが追加され、コンテンツが提供され得る動的アプリケーションプラットホームになることができる。ここで、動的コンテンツ配信システムのアーキテクチャは、機器にインストールされ得るアプリケーションのタイプも、機器が受信するコンテンツのタイプも限定しない。

本出願の一局面において、メタデータは、好ましくは、コンテンツを提供し、このコンテンツと関連して、動的コンテンツ配信アーキテクチャ内の様々な処理エレメントに対するコンテンツに知能を加える。このアーキテクチャは、コンテンツ供給、プッシュプロキシを含むサービス供給、無線ネットワーク、プッシュクライアントおよびクライアントアプリケーションを提供する。

本出願の更なる局面において、メタデータは、好ましくは、プッシュコンテンツメタデータに対する層状の「エンベロープ」されたモデルで提供される。コンテンツは、メタデータでラップされ、プッシュフレームワークの中の各エレメントで、処理するために使用され得る。各連続的な（ｓｕｃｃｅｓｓｉｖｅ）エレメントに対するデータは、層状にされ、それゆえ、処理エレメントは、そのエレメントに対するメタデータのみを抽出することが可能になる。例えば、プッシュプロキシおよびクライアントアプリケーションに向けられるメタデータを含むコンテンツパッケージは、クライアントアプリケーションに対するメタデータの第一のレベル、およびプッシュプロキシに対するメタデータの第二の層を有するコンテンツを含み得る。それゆえ、エンベロープがプッシュプロキシに到達するとき、プッシュプロキシに対するメタデータは、抽出され、コンテンツに適用され、修正されたコンテンツおよびクライアントアプリケーションに対するメタデータは、さらに処理エレメントにパスされる。

本出願の別の局面において、メタデータは、静的メタデータ（本明細書で、またチャネルメタデータとも称される）と動的メタデータ（本明細書で、コンテンツメタデータとも称される）とに分かれ（ｓｐｌｉｔ）得る。静的メタデータは、アプリケーションとコンテンツプロバイダとの双方への登録の際に確立されるのが好ましい。しかしながら、チャネルメタデータは、後に確立され得る。チャネルメタデータは、配信されているコンテンツのタイプに特定である処理ルールと、コンテンツタイプに対するアプリケーションの要求を特定する。

動的メタデータは、パスされる特定のコンテンツと、逆に関連している。

本出願の別の局面において、プラグイン登録モデルが、プッシュフレームワークの中で表現される。ジェネリックプッシュクライアントおよびプッシュプロキシが同定され、そのそれぞれが様々な処理ブロックまたはモジュールを有することで、これらのエレメントは、コンテンツとメタデータとの双方を処理できる。これらのブロックは、コンテンツがパスされているか、メタデータがパスされているか、あるいはコンテンツとメタデータとの双方がパスされているかのいずれかで、処理されるように向けられ得る。

プラグイン登録は、さらにサービスマニフェストおよびアプリケーションマニフェストをパスすることを提供し、コンテンツプロバイダとアプリケーションとの間のチャネルメタデータを確立することができる。具体的には、サービスマニフェストは、コンテンツプロバイダをプッシュフレームワークに登録するために使用され得、アプリケーションマニフェストは、アプリケーションをプッシュフレームワークに登録するために使用され得る。

本出願の別の局面において、シンジゲートされたコンテンツをプッシュする方法が、好ましくは、提供される。この方法によって、データをその優先順位に基づいて、ならびに、データ送信のコスト、接続されているネットワークのタイプ、またはユーザの好みを含むネットワーク因子に基づいて、取り扱うことが可能になる。シンジゲートされたコンテンツに対する随意の混合プッシュ／プルモデルによって、ネットワーク条件が好都合になったとき、プッシュプロキシがコンテンツをプッシュすること、あるいは、ユーザがコンテンツを要求したとき、クライアントがコンテンツをプルすることのいずれかが可能になる。

様々な移動デバイスに適合するために、本出願の更なる局面は、非線形コンテンツ断片化を含むコンテンツに対するコンテンツ断片化を好ましくは提供する。非線形コンテンツ断片化は、コンテンツをメタデータで増加させることを含み、これによって、データが、一度クライアントにパスされると、再構成されることが可能になる。

これらの局面および他の局面が、図面を参照して、より詳細に確認される。

本出願は、それゆえ、好ましくは、少なくとも第一の処理エレメントおよび第二の処理エレメントを有する動的コンテンツ配信アーキテクチャにおいて、コンテンツペイロードに処理知能を追加する方法を提供する。該方法は、コンテンツペイロードを備える第一のエンベロープと、該第二の処理エレメント上でランされるように適合した第二の処理エレメントメタデータとを生成するステップと、該第一のエンベロープを含む第二のエンベロープと、該第一の処理エレメント上でランされるように適合した第一の処理エレメントメタデータとを形成するステップとを包含する。

本出願は、動的コンテンツ配信アーキテクチャに対するコンテンツエンベロープをさらに提供する。該コンテンツエンベロープは、コンテンツペイロードと；該動的コンテンツ配信アーキテクチャ内の第一の処理エレメントに対するコンテンツメタデータであって、該コンテンツ処理メタデータおよびコンテンツペイロードは、第一のエンベロープを形成する、コンテンツメタデータと；該動的コンテンツ配信アーキテクチャ内の第二の処理エレメントに対する第二のコンテンツメタデータであって、該第二のコンテンツ処理メタデータは、該第一のエンベロープとともにネスティングし、第二のエンベロープを形成する、第二のコンテンツメタデータとを備える。

本出願は、動的コンテンツ配信アーキテクチャにおいて、処理エレメントに対するメタデータと、連続処理エレメントに対するメタデータおよびコンテンツとを有するエンベロープを処理する方法とをさらに提供する。該方法は、該処理エレメントに対するメタデータを該エンベロープから抽出するステップと、該メタデータを該連続処理エレメントに対するメタデータおよびコンテンツに用いて、これによって、処理されたネスティングされたエンベロープを生成するステップと、該処理されたネスティングされたエンベロープを該連続処理エレメントの一つに配信するステップとを包含する。

本発明は、さらに、以下の手段を提供する。
（項目１）
少なくとも第一の処理エレメントおよび第二の処理エレメントを有する動的コンテンツ配信アーキテクチャにおいて、コンテンツペイロードに処理知能を追加する方法であって、
コンテンツペイロードを備える第一のエンベロープと、該第二の処理エレメント上でランされるように適合した第二の処理エレメントメタデータとを生成するステップと、
該第一のエンベロープを含む第二のエンベロープと、該第一の処理エレメント上でランされるように適合した第一の処理エレメントメタデータとを形成するステップと
を包含する、方法。
（項目２）
上記第一の処理エレメントメタデータおよび上記第二の処理エレメントメタデータは、上記コンテンツペイロードに特有である、項目１に記載の方法。
（項目３）
上記第一の処理エレメントおよび上記第二の処理エレメントへの上記コンテンツペイロードに対するチャネルに関するメタデータを伝播するステップをさらに包含する、項目１または項目２に記載の方法。
（項目４）
上記コンテンツペイロードに対するチャネルに関するメタデータを用いて、上記第一の処理エレメントおよび上記第二の処理エレメントを供給するステップをさらに包含する、項目１または項目２に記載の方法。
（項目５）
上記少なくとも第一の処理エレメントおよび第二の処理エレメントは、プッシュプロキシ、プッシュクライアント、またはクライアントアプリケーションのいずれかを備える、項目１〜４のいずれか１項に記載の方法。
（項目６）
上記第一の処理エレメントで、上記第一の処理エレメントメタデータを抽出するステップと、
該第一の処理エレメントメタデータを上記第一のエンベロープ上で用いて、処理された第一のエンベロープを生成するステップと、
該処理された第一のエンベロープを上記第二の処理エレメントに配信するステップと
をさらに包含する、項目１〜５のいずれか１項に記載の方法。
（項目７）
上記用いるステップと、配信するステップとの前に、上記チャネルに関するメタデータを上記第一のエンベロープに付与するステップをさらに包含する、項目２または項目３に従属する項目６に記載の方法。
（項目８）
上記第一の処理エレメントで、上記第一のエンベロープにメタデータを追加するステップをさらに包含する、項目１〜７のいずれか１項に記載の方法。
（項目９）
上記生成するステップと、形成するステップとは、コンテンツプロバイダによって実行される、項目１〜８のいずれか１項に記載の方法。
（項目１０）
上記第二のエンベロープと、第三の処理エレメントに対する第三の処理エレメントメタデータとを備える第三のエンベロープを生成するステップをさらに包含する、項目１〜９のいずれか１項に記載の方法。
（項目１１）
上記第一の処理エレメントメタデータは、処理パラメータ、処理ルール、処理ハンドラ、処理ハンドラコード、処理ハンドラリファレンス、処理ハンドラへのリンク、処理ハンドラコードへのリンク、および／または処理ハンドラルールへのリンクのいずれかを備える、項目１〜１０のいずれか１項に記載の方法。
（項目１２）
動的コンテンツ配信アーキテクチャに対するコンテンツエンベロープであって、
コンテンツペイロードと
該動的コンテンツ配信アーキテクチャ内の第一の処理エレメントに対するコンテンツメタデータであって、該コンテンツ処理メタデータおよびコンテンツペイロードは、第一のエンベロープを形成する、コンテンツメタデータと、
該動的コンテンツ配信アーキテクチャ内の第二の処理エレメントに対する第二のコンテンツメタデータであって、該第二のコンテンツ処理メタデータは、該第一のエンベロープとともにネスティングし、第二のエンベロープを形成する、第二のコンテンツメタデータと
を備える、コンテンツエンベロープ。
（項目１３）
上記第一の処理エレメントおよび上記第二の処理エレメントは、プッシュプロキシ、プッシュクライアント、またはクライアントアプリケーションのいずれかを備える、項目１２に記載のコンテンツエンベロープ。
（項目１４）
上記第二の処理エレメントに対する上記第二のコンテンツメタデータは、上記第二の処理エレメントに対する完全な命令を提供するようにアレンジされる、項目１２または項目１３に記載のコンテンツエンベロープ。
（項目１５）
上記第一の処理エレメントに対する上記コンテンツメタデータは、上記第一の処理エレメントに対する完全な命令を提供するようにアレンジされる、項目１２〜１４のいずれか１項に記載のコンテンツエンベロープ。
（項目１６）
コンテンツメタデータは、処理パラメータ、処理ルール、処理ハンドラ、処理ハンドラコード、処理ハンドラリファレンス、処理ハンドラへのリンク、処理ハンドラコードへのリンク、および／または処理ハンドラルールへのリンクのいずれかを備える、項目１２〜１５のいずれか１項に記載のコンテンツエンベロープ。
（項目１７）
動的コンテンツ配信アーキテクチャにおいて、処理エレメントに対するメタデータと、連続処理エレメントに対するメタデータおよびコンテンツとを有するエンベロープを処理する方法であって、
該処理エレメントに対するメタデータを該エンベロープから抽出するステップと、
該メタデータを該連続処理エレメントに対するメタデータおよびコンテンツに用いて、これによって、処理されたネスティングされたエンベロープを生成するステップと、
該処理されたネスティングされたエンベロープを該連続処理エレメントの一つに配信するステップと
を包含する、方法。
（項目１８）
上記連続処理エレメントに対するメタデータおよびコンテンツ上で、上記コンテンツに対するチャネルメタデータを利用するステップをさらに包含する、項目１７に記載の方法。
（項目１９）
上記チャネルメタデータは、上記処理エレメントが上記エンベロープを受信する前に、供給または伝播される、項目１８に記載の方法。
（項目２０）
上記処理エレメントは、プッシュプロキシまたはプッシュクライアントのうちの一つである、項目１７〜１９のいずれか１項に記載の方法。
（項目２１）
上記処理エレメントに対する上記メタデータは、処理パラメータ、処理ルール、処理ハンドラ、処理ハンドラコード、処理ハンドラリファレンス、処理ハンドラへのリンク、処理ハンドラコードへのリンク、および／または処理ハンドラルールへのリンクのいずれかを備える、項目１７〜２０のいずれか１項に方法。
（項目２２）
動的コンテンツ配信アーキテクチャにおいて、処理エレメントに対するメタデータと、連続処理エレメントに対するメタデータおよびコンテンツとを有するエンベロープを処理するシステムであって、
該処理エレメントに対する該メタデータを該エンベロープから抽出する手段と、
該メタデータを該連続処理エレメントに対するメタデータおよびコンテンツに用いて、これによって、処理されたネスティングされたエンベロープを生成する手段と、
該処理されたネスティングされたエンベロープを該連続処理エレメントの一つに配信する手段と
を備える、システム。
（項目２３）
少なくとも第一の処理エレメントおよび第二の処理エレメントを有する動的コンテンツ配信アーキテクチャにおいて、コンテンツペイロードに処理知能を追加するコンピュータプログラム製品であって、項目１〜１１のいずれか１項に記載の方法をインプリメントするために、コンピュータ機器、システムまたは装置によって実行可能なプログラムコード手段を具現化するコンピュータ可読媒体を備える、コンピュータプログラム製品。
（項目２４）
動的コンテンツ配信アーキテクチャにおいて、処理エレメントに対するメタデータと、連続処理エレメントに対するメタデータおよびコンテンツとを有するエンベロープを処理するコンピュータプログラム製品であって、項目１７〜２１のいずれか１項に記載の方法をインプリメントするために、コンピュータ機器、システムまたは装置によって実行可能なプログラムコード手段を具現化するコンピュータ可読媒体を備える、コンピュータプログラム製品。

（摘要）
少なくとも第一の処理エレメントおよび第二の処理エレメントを有する動的コンテンツ配信アーキテクチャにおいて、コンテンツペイロードに処理知能を追加する方法およびシステム。該方法は、コンテンツペイロードを備える第一のエンベロープと、該第二の処理エレメント上でランされるように適合した第二の処理エレメントメタデータとを生成するステップと、該第一のエンベロープを含む第二のエンベロープと、該第一の処理エレメント上でランされるように適合した第一の処理エレメントメタデータとを形成するステップとを包含する。

（好ましい実施形態の説明）
ここで、図１を参照する。クライアントアプリケーションに動的コンテンツを配信するジェネリックなプッシュシステムが示される。図１のシステムは、簡略化されたシステムであり、動的コンテンツ配信アーキテクチャ内にあることを必要とするロジカルコンポーネントを示す。しかしながら、当業者には、他のコンポーネントが存在し得ること、あるいは、様々なコンポーネントが一緒にグループ化され得ることが理解される。

アーキテクチャ１００は、コンテンツプロバイダ１１０を含む。コンテンツプロバイダ１１０は、コンテンツプロバイダ１１０に契約しているユーザに動的コンテンツを提供するようにアレンジされる。実施例は、例えば、本を販売するウェブサイトを含み得る。ユーザは、コンテンツプロバイダ１１０と契約して、特定のジャンルの新刊本のリストを入手し得る。他の実施例は、とりわけ、定期的にユーザへヘッドラインを提供し得るニュースサイト、一日の所定の期間の間、ユーザに最新の交通情報を提供し得る交通サイト、最新の株価または為替レートを提供し得る株式市場サイトを含み得る。

以下に、より詳細に説明されるように、サービスプロバイダのクライアントが、コンテンツプロバイダ１１０からコンテンツを受信できるようにするために、コンテンツプロバイダ１１０は、サービスプロバイダ１２０と契約する。サービスプロバイダ１２０は、プッシュプロキシ１２２を含み、このプッシュプロキシ１２２は、クライアントまたはクライアントアプリケーションに対するプロキシとして機能し、コンテンツプロバイダ１１０にコンテンツを送信する目的地を提供する。

サービスプロバイダ１２０は、移動デバイスに位置するプッシュクライアント１４０と、無線ネットワーク１３０を介して通信する。プッシュクライアント１４０は、以下に、より詳細に説明される。プッシュクライアント１４０は、コンテンツプロバイダ１１０から配信されるコンテンツを受信し、クライアントアプリケーション１５０と、コンテンツを通信し得、そのクライアントアプリケーション１５０は、最終的にコンテンツを消費する。

本明細書において、コンテンツプロバイダ１１０、サービスプロバイダ１２０、プッシュプロキシ１２２、無線ネットワーク１３０、プッシュクライアント１４０、またはクライアントアプリケーション１５０への参照は、図１のアーキテクチャに戻っての参照である。

図２を参照すると、図１のコンポーネントは、単にロジカルコンポーネントであり、必ずしも、個別の物理的コンポーネントではないことが、当業者には理解される。図１は、ジェネリックなアーキテクチャを示し、その中に、１つのコンテンツプロバイダ１１０と、１つのプッシュプロキシ１２２と、１つのプッシュクライアント１４０と、１つのクライアントアプリケーション１５０とが存在する。代替が、図２に示される。

特に、第一の代替アーキテクチャ２１０は、プッシュプロキシ１２２と通信する複数のコンテンツプロバイダ１１０を含む。プッシュプロキシ１２２は、図１のアーキテクチャにおいてのように、無線ネットワーク１３０を介して、プッシュクライアント１４０と通信する。さらに、複数のクライアントアプリケーション１５０は、アーキテクチャ２１０の中に存在する。それゆえ、これは、複数のコンテンツプロバイダ１１０および複数のクライアントアプリケーション１５０を有するＮ−１−１−Ｎシステムである。

図２のアーキテクチャ２２０は、プッシュプロキシ１２２と通信し、それに登録された１つのコンテンツプロバイダ１１０を含む。さらに、プッシュプロキシ１２２は、無線ネットワーク１３０を介して、複数のプッシュクライアント１４０と通信する。各プッシュクライアント１４０は、クライアントアプリケーション１５０と通信する。それゆえ、アーキテクチャ２２０は、クライアントアプリケーション１５０およびプッシュクライアント１４０のロジカルコンポーネントをグループ化し、Ｎ（１−１）−１−１システムである。

図２のアーキテクチャ２３０は、複数のプッシュプロキシ１２２を有し、そのそれぞれは、コンテンツプロバイダ１１０と通信する。プッシュプロキシとコンテンツプロバイダとの各組み合わせ２３２は、無線ネットワーク１３０を介して、ジェネリックなプッシュクライアント１４０と通信し、次いで、このプッシュクライアント１４０は、クライアントアプリケーション１５０と通信する。これは、１−１−Ｎ（１−１）システムである。

図２のアーキテクチャ２４０において、コンテンツプロバイダ１１０およびプッシュプロキシ１２２のグループピング２３２は、無線ネットワーク１３０を介して、ジェネリックなプッシュクライアント１４０とクライアントアプリケーション１５０との組み合わせと通信する。それゆえ、これは、Ｎ（１−１）−Ｎ（１−１）システムである。

当業者によって理解されるように、他の代替も可能である。上記は、様々なロジカルコンポーネントを示し、これらのロジカルコンポーネントは、個別の物理的コンポーネントになり得るし、あるいは、一緒にグループ化され得る。例えば、プッシュクライアントは、アプリケーションに組み込まれ得るし、共有クライアントは、複数のアプリケーションまたは他の代替によって、使用され得る。

ここで、図３を参照する。システムに知能を加えるために、コンテンツは、メタデータと関連している。この場合、メタデータは、処理エレメントによって使用され、コンテンツを操作し得るデータとして定義される。理解されるように、ジェネリックプッシュシステムは、様々なコンテンツプロバイダおよびアプリケーションが、システム内に存在できるようにするために、メタデータを要求する。メタデータは、処理パラメータまたはルール、直接提供される処理ハンドラ、コードまたはリファレンス、あるいは、別の場所にある処理ハンドラ、コードまたはルールへのリンクを含む様々な形式であり得る。

図３から分かるように、コンテンツは、コンテンツプロバイダ１１０からクライアントアプリケーション１５０へと通過し、これは、矢印３１０によって示されている。アーキテクチャ１００の中にある様々なコンポーネントへの命令を提供するメタデータも、また、アーキテクチャ１００の中のコンポーネントの間を、通常はコンテンツに沿って通過し得る。例えば、矢印３２０は、コンテンツプロバイダで生成し、クライアントアプリケーション１５０に到達するまで、配信システムに対して認識されないメタデータを示す。

矢印３３０は、コンテンツプロバイダ１１０によって生成されたメタデータを示す。このメタデータは、プッシュクライアント１４０向けに意図されているので、ジェネリックプッシュクライアント１４０に流れるのみである。

矢印３４０は、サービスプロバイダ１２０によって生成されたメタデータを示す。このメタデータは、プッシュクライアント１４０向けに意図されているので、プッシュプロキシ１２２でコンテンツと最初に関連し、ジェネリックプッシュクライアント１４０で、コンテンツからストリップされる。これが起こり得る場所の例として、請求プランおよび提供されるべきサービスのレベルに関してのユーザとサービスプロバイダとの契約を含み、こうして、サービスプロバイダは、メタデータを用いて、利用可能なサービスを制限し得るし、あるいは拡張されたサービスを提供し得る。

メタデータのフローおよびメタデータの役割は、以下に、より詳細に記載される。

ここで、図４を参照する。図４は、詳細な例示的なプッシュプロキシ４１０を示し、このプッシュプロキシ４１０は、現在のシステムおよび方法と関連して使用され得る。当業者には理解されるように、プッシュプロキシ４１０は、図１および図２からのプッシュプロキシ１２２と同じであり得る。

図４のプッシュプロキシ４１０は、プッシュプロキシ４１０がジェネリックなプッシュ環境で動作することができる様々なエレメントを含む。これによって、プッシュプロキシは、特定のコンテンツプロバイダまたはプッシュクライアントとの相互作用に限定されず、その代わりに、動的な環境に適応し得るので、融通性が向上する。プッシュプロキシ４１０に対して以下に記載されるエレメントは、プッシュプロキシ４１０内に有することが好ましいが、これらのエレメントは網羅的なものではなく、他のエレメントも可能である。さらに、ある種のエレメントは、プッシュプロキシ４１０から除外され得るが、それでも、残りのエレメントで、ジェネリックなプッシュサービスを実行できる。

プッシュプロキシ４１０は、その中に登録されたコンテンツプロバイダ４１２を含む。コンテンツプロバイダ４１２は、コンテンツプロバイダ登録にサービスプロバイダインターフェース（ＳＰＩ）４２０を登録する。以下に、より詳細に記載されるように、この登録において、コンテンツプロバイダ４１２は、確立されるチャネルに対するある種の情報、本明細書ではチャネルメタデータと称するが、これを含むことが望ましい。コンテンツプロバイダ４１２は、図１のコンテンツプロバイダ１１０と同じであり得る。

プッシュプロキシ４１０は、プッシュプロキシサービスを管理するためのサービス管理ブロック４３０を含む。

プッシュプロキシ４１０は、コンテンツと、そのコンテンツと関連するメタデータとの双方を取り扱う様々なモジュールを含む。第一のモジュールは、メッセージブローカ・配信待ち行列４４０であり、これは、コンテンツプロバイダ４１２からのメッセージを消費するｃｏｎｓｕｍｅサブシステムであり、コンテンツ配信待ち行列を管理する。当業者には理解されるように、全てのクライアントアプリケーションに対する全てのコンテンツが、一度に配信され得ないで、配信待ち行列は、コンテンツを順当に配信するために、確立される必要がある。例えば、デバイスは、カバー範囲外であり得て、コンテンツが格納されるべき必要があり得る。

プッシュプロキシ４１０は、フロー制御管理ブロック４４２をさらに含む。フロー制御管理ブロック４４２によって、コンテンツのフローを制御できる。例えば、限られた空間内の移動局は、所定の量の情報を受信できるだけであり得る。この場合、移動デバイスは、図１に示されるようなプッシュクライアント１４０を介して、プッシュプロキシ４１０に、プッシュクライアント１４０へのデータのフローを止めるように求め得る。このフロー制御管理ブロック４４２は、これに対処する。

代替として、移動デバイスは、オフラインであり得る。フロー制御管理ブロック４４２は、コンテンツがプッシュプロキシ４１０によって受信されたままの状態で配信され得ないとき、プッシュクライアント１４０へのデータのフローを中止し、開始する。

プッシュプロキシ４１０の更なるコンポーネントは、プッシュエージェント４４４である。プッシュエージェント４４４は、クライアントにデータを送信する役割を担う。

当業者には理解されるように、ブロック４４０、４４２および４４４は、メッセージ伝達のみを扱い、メタデータ関連とは関係しない。言い換えれば、これらのブロックは、メッセージのコンテンツを取り扱うが、コンテンツと関連するメタデータは一切取り扱わない。

プッシュプロキシ４１０の更なるコンポーネントは、コンテンツメタデータ抽出器・キャッシュブロック４５０である。コンテンツメタデータ抽出器・キャッシュブロック４５０は、エンベロープされた（ｅｎｖｅｌｏｐｅｄ）コンテンツメタデータで動作する。具体的には、以下に、より詳細に記載されるメタデータシステムのエンベロープモデルにおいて、システム内の各ロジカルコンポーネントは、コンテンツ処理と関連するメタデータを有し得る。このメタデータによって、ロジカルコンポーネントは、コンテンツにアクションを実行することができる。このように、各ロジカルコンポーネントは、自身と関連するメタデータを抽出できる必要がある。

コンテンツメタデータ抽出器・キャッシュブロック４５０は、プッシュプロキシ４１０と関連するメタデータを抽出し、このメタデータをキャッシュ化する役割を担う。キャッシュ化機能によって、同じコンテンツプロバイダからの引き続きくるコンテンツエンベロープ内の同一のメタデータをパスする必要がなくなるので、最適化できる。メタデータの抽出およびキャッシュ化は、以下に記載される。

据え置き検索・メッセージストアブロック４５２は、コンテンツまたはそのコンテンツの一部をクライアントアプリケーションに配信することが効率的でないときに、使用される。据え置き検索・メッセージストアブロック４５２は、クライアントに配信されないコンテンツを、そのコンテンツを送信するのが効率的になるまで、あるいは、そのコンテンツがクライアントによって引き出されるまで、格納するために使用され得る。据え置き検索・メッセージストアは、また、補助コンテンツをキャッシュ化するためにも使用され得る。この補助コンテンツは、既に配信されたコンテンツを介するクライアントアプリケーションナビゲーションに依存するクライアントに随意に送信され得るか、あるいは、そのクライアントによって引き出され得る
据え置き検索メッセージストアブロック４５２の目的は、図１９および図２１を参照して、以下に、より良く説明される。一例として、据え置き検索メッセージストアブロック４５２は、ユーザが、ユーザのロケーションの近くにあるレストランなどのロケーション情報をリクエストした場合に使用され得る。コンテンツプロバイダまたはサービスプロバイダは、情報を提供するモデルを有し得る。このとき、広告主は、お金を払って、自分たちの情報をサーチリクエストに追加し得る。したがって、あるロケーションに対するレストラン情報をリクエストしているユーザは、自分がリクエストしている自分のロケーションの近くに、商店、ゴルフコース、体育館または他のサービスに関する情報を有し得る。コンテンツプロバイダは、リクエストされたレストラン情報に追加情報を束ねて、これらの情報をプッシュプロキシ４１０にパスする。

プッシュプロキシ４１０は、提供されたメタデータに基づいて、コンテンツパッケージを生成し、クライアントに送信する。コンテンツパッケージには、クライアントによってリクエストされた情報、およびユーザが関心を有し得る関連情報のダイジェストまたは概要が含まれ得る。概要は、ユーザに送信されるが、据え置き検索・メッセージストアブロック４５２は、コンテンツプロバイダ１１０から受信された実際のデータを格納する。こうして、将来、ユーザが、そのダイジェスト内にある情報に関するより詳細な情報を入手したいと思った場合、この情報は、プッシュプロキシ４１０に既に格納されている。

据え置き検索・メッセージストアブロック４５２に対する代替的な使用は、ユーザが一度にコンテンツ全体を受け入れ得ない場合である。例えば、デバイスにコンテンツ全部を送信することが、実現可能でない場合、あるいは経済的でない場合、コンテンツの一部は、しばらく経つまで、つまり、クライアントによって引き出され得るときまで、あるいは所定のルールが合致して、プッシュされ得るときまで、格納され得る。これらのルールは、満足される所定のネットワークまたはサービス条件により、ネットワークまたはサービス条件によって特定され得る。これについては、以下に、図１９を参照して、より詳細に記載される。

プッシュスケジューラ４５４は、クライアントに対する配信スロットをスケジューリングする。前述のように、一部の状況において、一度にコンテンツの全部をプッシュすることは効率的でないことがあり得る。プッシュスケジューラ４５４は、一部の情報を即座にそして、その残りを所定のスケジュールに従ってプッシュすることを決定し得る。また、プッシュスケジューラ４５４は、コンテンツの性質を用い、そのコンテンツがプッシュされるべきときを決定し得る。特に、一部のコンテンツが高い優先度を有すること、あるいは時間的に限られた満了期限を有することをメタデータが示し得ると、このコンテンツは、即座にプッシュされ得る。それに対し、低い優先度を有するか、あるいは満了期限を有しないことを示されたコンテンツは、後に、データをパスする条件が、より好ましくなったときに、プッシュされ得る。

当業者には理解されるように、ブロック４５０、４５２および４５４は、メッセージのコンテンツと、このメッセージと関連するメタデータとの双方を扱う。

加入・ルールブロック４６０は、配信されている特定のコンテンツを取り扱う上でのサービスおよびモニタルールを受信するために登録されるアプリケーションを追跡（ｔｒａｃｋ）する。コンテンツは、典型的には、クライアントによる加入またはクライアントの代理としての加入に基づいて配信される。例えば、特定のサービスをユーザが欲する場合、そのユーザは、積極的に加入をリクエストし得る。加入は、ユーザの代理としてなされ得る。例えば、ユーザが、サービスの恩恵を受けるために、サービスプロバイダ１２０と契約にサインをした場合である。これは、ユーザが、所定の数の広告を毎日受信することに同意しさえすれば、ユーザが優遇料金で受信する場合を含み得る。この場合、サービスプロバイダ１２０は、クライアントの代理として、広告プロバイダに加入し得る。

アプリケーションが移動デバイス上で消去されるとき、あるいはアプリケーションが加入を登録解除するとき、加入・ルールブロック４６０は、そのユーザを加入中止にし得る。

コンテンツ依存ブロック４６２は、プッシュプロキシ４１０によって使用され、移動デバイスが利用し得るサービスを広告する。したがって、移動デバイスのユーザが、サービスに対する十分な画面または帯域幅あるいはメモリを有しない場合、コンテンツ依存ブロック４６２は、そのサービスの広告をそのユーザに対して阻止し得る。

コンテンツ断片化ブロック４６４は、コンテンツを断片化するために使用される。これが用いられ得るのは、例えば、移動デバイスが、一度にコンテンツの全てを受信できない場合である。コンテンツ断片化ブロック４６４は、コンテンツを様々なコンポーネントに分解するために使用される。これは、据え置き検索・メッセージストア４５２と連携して使用され、まだ配信されていない断片化コンテンツを格納し得る。

コンテンツ満了・置換ブロック４６６は、２つの目的で使用される。第一に、このブロックは、加入をモニタするために使用され得る。各加入には、満了時があり、この満了時に達したときに、加入は終了し得る。

また、コンテンツ満了・置換ブロック４６６は、情報をモニタするためにも使用され得る。ある種のコンテンツには、その情報の有効期限がある。例えば、ラッシュ時の交通をモニタするために使用される交通アプリケーションは、非常に時間依存性がある。何らかの理由で、プッシュプロキシ４１０は、移動デバイスにコンテンツを即座に配信できない場合、このコンテンツは、将来の配信のために、コンテンツストレージ４８０の中に格納される。しかしながら、コンテンツが所定の特定期間内に配信されない場合、このコンテンツは満了し得、全く配信され得ない。

同様に、コンテンツ置換は、情報が更新される状況で扱われる。例えば、株価を受信するクライアントアプリケーションは、最新の株価を欲するのみであり得る。したがって、プッシュプロキシ４１０は、株価をプッシュクライアント１４０に配信できず、引き続く株価がコンテンツプロバイダ１１０から受信される場合、引き続く株価の中にあるメタデータが、以前の株価に置換されて使用されるべきであることを指示し得る。格納された情報の置換は、配信待ち行列に全ての情報を加えるより、コンテンツストレージ４８０内の空間を開放する。

チャネルメタデータ貯蔵庫４７０はチャネルメタデータを格納するために使用される。これについては、以下に、より詳細に記載される。

以上は、本明細書の方法およびシステムで使用され得る例示的なプッシュプロキシ４１０を説明するものである。このプッシュプロキシ４１０は、プッシュプロキシ４１０のブロックおよびエレメントによって、ジェネリックな動的コンテンツ配信システムで使用される。ここで、アプリケーションにおけるコンテンツのタイプおよびコンテンツの取り扱いは、変動し得、事前に決定されない。

ここで、図５を参照する。図５は、本明細書のシステムおよび方法と関連して使用され得るプッシュクライアント５１０を示す。プッシュクライアント５１０は、図１および図２のプッシュクライアント１４０と同じであり得る。

当業者には理解されるように、コンテンツおよびそのコンテンツ処理が事前に決定されていないジェネリックなシステムで用いられることになるプッシュクライアント５１０は、コンテンツと、そのコンテンツと関連するメタデータとの双方に適合して使用され得るブロックまたはモジュールを含むべきである。図５に関して規定されるブロックは、網羅的であることを意図するものではなく、プッシュクライアント５１０内に他のブロックもまた存在し得る。さらに、プッシュクライアント５１０内のブロックは、一部の例において、プッシュクライアント５１０内の他のブロックの機能性を制約することなく、省かれ得る。

プッシュクライアント５１０は、アプリケーションをサービスし、１つ以上のアプリケーション５１２は、プッシュクライアント５１０に登録され得る。アプリケーション登録は、登録用のインターフェースとして、アプリケーションプロバイダインターフェース５１４を使用し、アプリケーションプロバイダインターフェース５１４は、以下により詳細に記載されるように、アプリケーション用のチャネルメタデータを抽出するために、さらに使用され得る。

プッシュクライアント５１０は、プッシュクライアント５１０を統治（ａｄｍｉｎｉｓｔｅｒ）するために使用されるクライアント統治（ａｄｍｉｎｉｓｔｒａｔｉｏｎ）５２０を含む。

図４のプッシュサーバ４１０と同様に、プッシュクライアント５１０は、メッセージ伝達を扱う様々なブロック、メタデータを扱う様々なブロック、およびメッセージ伝達とメタデータとの双方を扱う様々なブロックを含む。

メッセージブローカ・アプリケーション配信待ち行列５４０は、配信用プッシュプロキシ４１０からアプリケーション５１２へのメッセージを扱う。アプリケーション待ち行列は、アプリケーション５１２に対するメッセージの待ち行列である。

フロー制御管理ブロック５４２は、図４のプッシュプロキシ４１０に、コンテンツのプッシュ中止またはコンテンツのプッシュ再開を通知するために使用される。これが使用されるのは、例えば、プッシュクライアント５１０が、プッシュされたコンテンツを受け入れ得るメモリ量が限られているときである。この場合、プッシュコンテンツが消費される前に、プッシュクライアント５１０は、プッシュプロキシ４１０からのコンテンツのフローを止める必要がある。一度、コンテンツが消費されると、フロー制御管理ブロック５４２は、再び、データのフローを開始するために使用され得る。

プッシュクライアント５１０内のプッシュエージェント５４４は、図４のプッシュプロキシ４１０から情報を受信するために使用される。

当業者には理解されるように、メッセージブローカ・アプリケーション待ち行列５４０、フロー制御管理ブロック５４２、およびプッシュエージェント５４４は、メッセージ伝達を独占的に扱い、メタデータを扱わない。

コンテンツメタデータ抽出器・キャッシュブロック５５０は、プッシュクライアント５１０に向かうことになっている動的メタデータを抽出するために使用される。図４のプッシュプロキシ４１０を参照して、以前に述べたように、動的コンテンツ配信アーキテクチャ内の処理エレメントはいずれも、これらの処理エレメントに向かう予定のメタデータを有し得、このメタデータは抽出される必要がある。このように、プッシュクライアント５１０に向かう予定のメタデータは、コンテンツメタデータ抽出器・キャッシュブロック５５０によって抽出される。

さらに、コンテンツメタデータ抽出器・キャッシュブロック５５０は、キャッシュメタデータに適合することが好ましい。第一のコンテンツパッケージと第二のコンテンツパッケージとの間で変化しないプッシュクライアント５１０に対するメタデータは、パスされる必要はない。こうして、このメタデータの抽出を要求しないので、プッシュクライアント５１０での処理時間を節約でき、無線ネットワーク１３０を介してパスされるプッシュクライアント５１０に対するメタデータを要求しないので、ネットワークリソースをさらに節約できる。

据え置き検索マネージャ５５２は、受信されたコンテンツの断片を解析し、コンテンツを正しい方法で一緒に置くために使用される。以下により詳細に記載されるように、データは、線形、あるいは非線形であり得る。データが非線形の場合、データを再構築するために、メタデータが必要とされ、これは、据え置き検索マネージャ５５２によって行われる。据え置き検索マネージャ５５２は、また、プッシュプロキシ５１０の据え置き検索ストア４５２で利用可能な情報のダイジェストを解析するようにも適合され、ユーザによって要求されたとき、コンテンツプルブローカ５５４（以下に記載）を駆動して、この情報を検索する。これは、コンテンツナビゲーションが、コンテンツ構造グラフの所定のブランチに入るとき、あるいは帯域幅またはコスト条件が満足されるとき、予測検索を含む。

コンテンツプルブローカ５５４は、プッシュクライアント５１０がある状況下で、コンテンツを引き出すことができるプッシュ／プルモデルで使用される。このような状況は、図１９を参照して、以下に詳細により記載される。

当業者には理解されるように、コンテンツメタデータ抽出器・キャッシュ５５０、据え置き検索マネージャ５５２およびコンテンツプルブローカ５５４は、メッセージ伝達コンテンツとメタデータとの双方を扱う。

加入管理ブロック５６０は、図４の加入・ルールブロック４６０と同じである。特に、加入管理ブロック５６０は、加入を管理するために使用される。アプリケーションが、移動デバイスから登録解除する場合、あるいは削除される場合、加入管理ブロック５６０は、加入を終了する。加入管理ブロック５６０は、また、加入チャネルが満了するとき、クライアントアプリケーションの代理として、再加入し得る。

更新通知ブロック５６２は、クライアントアプリケーションと協働し、新たなコンテンツがクライアントアプリケーションを待っていることをアプリケーションに通知するために使用される。これは、３つの方法のうちの１つで行われる。
ａ．更新通知ブロック５６２が、アプリケーション５１２に通知し得る第一の方法は、プッシュクライアント５１０が、コンテンツをアプリケーションに直接送信する方法である。
ｂ．更新通知ブロック５６２が、新たなコンテンツのアプリケーション５１２に通知し得る第二の方法は、コンテンツストレージ５８０内にコンテンツを格納し、コンテンツが待っていることを随意にアプリケーション５１２に通知する方法である。この場合の通知は、随意である。具体的には、アプリケーション５１２が、自身に向けられた情報が、特定のメモリブロック内に格納されていることを知っている場合、そのアプリケーションにとって、それが新たなデータを有することを発見するための一つの選択肢は、メモリロケーションを定期的に調査し、そのメモリロケーションに何か書かれていないかを見ることである。代替として、更新通知ブロック５６２は、自身が新たなデータを有することと、おそらく、データが格納されているロケーションとを指示するメッセージをアプリケーションに送信し得る。
ｃ．更新通知５６２が、新たなコンテンツのアプリケーション５１２に通知し得る第三の方法は、コンテンツを内部に格納し、アプリケーションに通知する方法である。このアプリケーションは、次いで、プッシュクライアントに呼びかけて、そのコンテンツを検索する。

コンテンツ依存ブロック５６４は、図４のコンテンツ依存ブロック４６２と同じであり、移動デバイスにサービスを広告するかどうかを判断し得る。

コンテンツ満了・置換ブロック５６６は、図４のコンテンツ置換・満了ブロック４６６と同じである。コンテンツの満了およびコンテンツの置換は、このように、プッシュサーバまたはプッシュプロキシに加えて、プッシュクライアント５１０で扱われ得る。

チャネルメタデータ貯蔵庫５７０は、アプリケーション５１２に対するチャネルメタデータを格納するために使用される。

バックグラウンド更新処理モジュール５７５は、アプリケーション５１２が利用できないとき、更新を実行するために使用される。バックグラウンド更新によって、例えば、アプリケーションストレージ内部のデータをより新しいデータと置換が可能になる。その後、ユーザは、アプリケーションを開始し、アプリケーションによって表示されるデータは、補正され、更新される。

バックグラウンド更新処理モジュール５７５は、処理ルールを用いて、コンテンツをアプリケーションに対して許容可能なフォーマットに翻訳する。このモジュールは、コンテンツストア５８０内のコンテンツを実行し、処理し得る。

一例として、夜間契約者（ｃｏｎｔｒａｃｔｏｒ ｏｖｅｒｎｉｇｈｔ）に対して更新されるタスクリストは、それにプッシュされたタスクを有し得る。タスクアプリケーションは、この間、開始されず、バックグラウンド更新処理モジュール５７５は、タスクアプリケーション用のコンテンツを更新するために使用され得る。これは、拡張マークアップ言語（ＸＭＬ）ファイルを扱うためのコードで行われ得、「ｈａｎｄｌｅｒ．ｅｘｅ」と称されるファイルで、デバイス上に存在し得る。プッシュクライアント５１０上のバックグラウンド更新処理ブロック５７５は、ｈａｎｄｌｅｒ．ｅｘｅをランさせ得、パラメータを有するＸＭＬドキュメントをパスさせる。次いで、ハンドラは、タスクをアプリケーションの内部フォーマットに構築する。

一度、プッシュクライアント５１０のバックグラウンド更新処理ブロック５７５が、アプリケーション内部フォーマットにタスクを構築すると、このブロックは、コンテンツストレージ５８０からのタスクリストに、そのタスクを読み込まれ得、その新しいタスクをリストに添付し得る。次いで、そのブロックは、改変されたバックをコンテンツストレージ５８０に格納する。これは、タスクアプリケーションが、次にプッシュクライアント５１０に接続するときに備えてである。

図５は、それゆえ、ジェネリック動的コンテンツ配信システムにおいて使用され得るプッシュクライアント５１０を示す。ここで、コンテンツおよびコンテンツの処理は、動的であり、事前に決定されていない。図５のプッシュクライアント５１０を参照して上述されたブロックは、システムの動的な性質に適合するように使用される。

図３を参照して示されたように、コンテンツは、メタデータと関連し、コンテンツの処理に対する知能を提供する。本方法およびシステムに従うと、メタデータは、２つのタイプのメタデータに分けられ得る。具体的には、静的（チャネル）メタデータおよび動的（コンテンツ）メタデータである。

コンテンツプロバイダおよびアプリケーションのタイプには無限の可能性があるので、ジェネリックシステムを構築するためには、メタデータは、クリティカルである。特定のタイプのコンテンツを扱う唯一の方法は、メタデータを介してである。

静的メタデータは、特定タイプのコンテンツをいかに処理するかのルールを提供するメタデータである。静的メタデータは、様々な抽象化レベルに分解され得、例えば、コンテンツ自体に関する構造情報を含む。例えば、Ｒｅａｌ−ｔｉｍｅ Ｓｉｍｐｌｅ Ｓｙｎｄｉｃａｔｉｏｎ（ＲＳＳ）ドキュメントは、ＲＳＳ ２．０．ＸＳＤ構造で配信され得、そのコンテンツプロバイダからの全てのコンテンツは、この構造で配信される。

静的メタデータの更なる抽象化レベルは、コンテンツサブタイプに対する処理ルールの提供を含む。これは、アプリケーションに特定的であり得る。したがって、例えば、金融ニュースのアプリケーションは、所定のロケーションに格納された金融ニュースＲＳＳストリームからデータが抽出されるべきことと、そのアプリケーションが情報の着信に関する通知を受けるべきこととを指示する。アプリケーションは、自身に向けられる予定のコンテンツを常に要求し、この方法で取り扱う。

静的メタデータ（本明細書では、チャネルメタデータとも称される）は、アプリケーションとコンテンツプロバイダとの間での加入の間、ずっと留まる。したがって、静的メタデータは、アーキテクチャ内の各エレメントに対して、また、各コンテンツ配信チャネルに対して、一回確立され得る。一つの実施形態において、これは、アプリケーションまたはコンテンツプロバイダの登録時に行われる。

動的メタデータは、コンテンツの特定のピースと関連しているメタデータである。例えば、データの特定のピースと関連する満了情報、または置換ルール、およびデータの特定のピースと関連する情報である（すなわち。ドキュメントＫがドキュメントＬと置換する）。

以上に、図４および図５を参照して示したように、各処理エンティティは、その処理エンティティに向けられる静的メタデータと動的メタデータとの双方を受信し得る。したがって、プッシュプロキシ４１０は、コンテンツメタデータ抽出器・キャッシュ４５０を、動的メタデータを抽出するため用いられ、コンテンツ満了・置換モジュラー４６６は、配信されなかったコンテンツをプッシュプロキシ４１０で受信された新たなコンテンツと置換するために用いられる。

ここで、図６を参照する。図６は、コンテンツメタデータに対する多層エンベロープモデルを示す。

プッシュプロキシ４１０は、プロキシサーバ６１２およびプッシュクライアントエンベロープ６１４に対するコンテンツ処理メタデータを含むプッシュエンベロープ６１０を受信する。プッシュプロキシ４１０は、コンテンツ処理メタデータ６１２を抽出し、このメタデータをプッシュクライアントエンベロープ６１４を処理するために使用する。メタデータ６１２は、プッシュクライアントエンベロープ６１４で何を行うかをプッシュプロキシに記述する。

プッシュクライアントエンベロープ６１４は、コンテンツクライアント５１０にパスされ、そこで、コンテンツエンベロープ６２０と、コンテンツ処理メタデータ６２２とに分解される。コンテンツ処理メタデータ６２２は、コンテンツエンベロープ６２０を処理するために、プッシュクライアント５１０によって使用される。例えば、これは、クライアントアプリケーション１５０が、コンテンツの最新バージョンにのみ関心ある場合、プッシュクライアント５１０に命令して、以前に配信されたコンテンツエンベロープ６２０を最新のエンベロープに置換を実行するために使用され得る。

コンテンツエンベロープ６２０は、クライアントアプリケーション１５０にパスされる。コンテンツエンベロープは、アプリケーション用に対するコンテンツ処理メタデータ６３０、およびクライアントアプリケーション１５０によって消費されることになるコンテンツペイロード６３２を含む。

当業者には理解されるように、図６に従うエンベロープのネスティングは、処理がアーキテクチャの任意の処理エレメントで起こり得て、どのように特定のコンテンツが処理されるかをコンテンツプロバイダ１１０が特定し得るリッチな動的環境を備える。一つの実施形態において、特定のロジカルエレメントに向けられたメタデータは、他の処理エレメントに不透明（ｏｐａｑｕｅ）である。

代替として、サービスプロバイダ１２０は、またプッシュプロキシ４１０で、プッシュクライアント５１０またはクライアントアプリケーション１５０を処理するために、メタデータを追加し得る。

図７を参照すると、この図は、図６のエンベロープモデルと、各処理エレメントがエンベロープとともに行うステップとを示す。図７に示されるように、プッシュプロキシ４１０は、まずプッシュエンベロープ６１０からメタデータを抽出する。これは、ステップ７１０で行われる。

ステップ７１２で、プッシュプロキシ４１０は、メタデータを用いて、プッシュクライアントエンベロープ６１４を処理する。ステップ７１４で、プッシュプロキシ４１０は、プッシュクライアントエンベロープ６１４をプッシュクライアント５１０に配信する。

同様に、プッシュクライアント５１０は、ステップ７２０で、コンテンツ処理メタデータ６２２をプッシュクライアントエンベロープ６１４から抽出する。ステップ７２２において、プッシュクライアント５１０は、コンテンツエンベロープ６２０にコンテンツ処理メタデータ６２２を用いる。ステップ７２４で、プッシュクライアント５１０は、コンテンツエンベロープ６２０をクライアントアプリケーション１５０に配信する。

ステップ７３０で、クライアントアプリケーション１５０は、コンテンツ処理メタデータ６３０を抽出し、ステップ７３２で、コンテンツ処理メタデータ６３０をコンテンツペイロード６３２で用いる。

図８を参照すると、この図は、図７に示された方法に、静的メタデータまたはチャネルメタデータを用いる追加のステップとともに示す。具体的には、ステップ７１０で、メタデータがプッシュエンベロープ６１０から抽出された後、プッシュプロキシ４１０は、次いで、静的チャネルメタデータを用いて、ステップ８１０で、プッシュクライアントエンベロープを処理する。ステップ７１２で、プッシュプロキシ４１０は、次いで、コンテンツ処理動的メタデータ６１２を処理する。プッシュプロキシ４１０は、次いで、ステップ７１４で、プッシュクライアントエンベロープ６１４を配信する。

同様に、プッシュクライアント５１０は、ステップ７２０で、コンテンツ処理メタデータ６２２を抽出する。ステップ８２０において、プッシュクライアント５１０は、次いで、コンテンツエンベロープ６２０でコンテンツ処理メタデータ６２２を用いる。プッシュクライアント５１０は、次いで、ステップ７２２で、動的コンテンツメタデータをコンテンツ処理メタデータ６２２内で使用する。その後、ステップ７２４で、クライアントアプリケーション１５０にコンテンツエンベロープ６２０を配信する。

ステップ７３０で、クライアントアプリケーション１５０は、最初に、コンテンツ処理メタデータ６３０を抽出する。クライアントアプリケーション１５０は、次いで、ステップ８３０で、コンテンツペイロード６３２でチャネルメタデータを用いる。クライアントアプリケーション１５０は、次いで、ステップ７３２で、コンテンツペイロード６３２でコンテンツ処理メタデータ６３０を用いる。

当業者には理解されるように、上記のモデルによって、それゆえ、チャネルに対して適用される静的メタデータと、その特定のコンテンツと関連する動的メタデータと一緒に、その双方を送信すること可能になる。

ここで、図９を参照する。図５から分かるように、プッシュクライアント５１０は、移動デバイス上の複数のターゲットアプリケーション５１２にサービスし得る。アプリケーションが、他のアプリケーションに対するサービスを中断することなく、動的コンテンツ配信フレームワークを登録し得る効率的なランタイム登録メカニズムが、要求される。

図９を参照すると、プッシュクライアント５１０は、３つのアプリケーションを含み、具体的には、アプリケーション９１０、９１２および９１４は、既にプッシュクライアントに登録されている。理解されるように、プラグイン（ｐｌｕｇ ｉｎ）モデルは、重要である。なぜなら、新しいデバイスは、制限のないアプリケーションタイプが、それらのデバイス上にインストールされることを可能にし得るからである。さらに、アプリケーションは、動的にインストールされ、移動デバイスがアプリケーションプラットホームになるように導き得る。なぜなら、デバイスは、アプリケーションプラットホームであり得、デバイスは、新たなアプリケーションを動的に組み込むことが可能であるはずだからである。

図９に示されるように、アプリケーション９１６は、プッシュクライアント５１０に登録したいと欲する。アプリケーション９１６は、アプリケーションマニフェスト９１８を含む。好ましい実施形態において、アプリケーションマニフェスト９１８は、そのアプリケーションに対するチャネルメタデータを提供する。特定的には、アプリケーションマニフェスト９１８は、情報をプッシュクライアント５１０に、そして、究極的には、図１のプッシュプロキシ４１０およびコンテンツプロバイダ１１０に、そのアプリケーションに対する静的メタデータとともに、情報を提供する。この情報には、どのタイプのコンテンツをこのアプリケーションが期待しているか、どのようにコンテンツが配信されるか、アプリケーションに通知が必要かどうか、あるいは、本システムおよび方法に関する分野の当業者にとって明らかであろう他のチャネル情報が含まれ得るが、これらに限定されない。

アプリケーション９１６は、それゆえ、プッシュクライアント５１０に登録され、アプリケーションマニフェスト９１８を提供し、アプリケーション９１６をサービスするためのコンテンツプロバイダにチャネルを確立する。

図１０を参照すると、代替のモデルは、図２のアーキテクチャ２２０に対して記載されたモデルであり得る。具体的には、図１０のモデルにおいて、クライアントアプリケーション１５０は、プッシュクライアント１４０とペアになっている。クライアントアプリケーション１５０／プッシュクライアント１４０のペアは、プッシュコンテナ１０１０を用いて調整される。

アプリケーション１０２０が、プッシュコンテナ１０１０に登録したいと願うとき、クライアント１４０が、プッシュコンテナ１０１０によって、生成されるか、あるいは、クライアント１４０が既に存在する場合は、使用される。さらに、登録において、アプリケーション１０２０は、アプリケーションマニフェスト１０３０をプッシュコンテナ１０１０に提供することによって、チャネルメタデータ（静的データ）をアプリケーション１０２０に対して提供する。

図１０の代替の図が、図１１に示される。具体的には、プッシュコンテナ１１１０が、プッシュクライアントのプールをマネージ／維持する。アプリケーションが、コンテナに登録されるとき、アプリケーションは、専用のプッシュクライアント５１０を得る。単純な場合において、これは、ソケットリスナ１１３０とコンテンツハンドラのペアによって表現され得る。プッシュクライアントは、アプリケーションがコンテナ（およびコンテンツ配信サービス）から登録解除されたとき、プールに戻るか、あるいは、デバイスから削除される。

プッシュコンテナ１１１０は、通信用ソケット１１２０を含む。さらに、プッシュコンテナ１１１０は、特定のソケットに割り当てられたソケットリスナ１１３０およびコンテンツプロセッサ１１４０を含む。

図１１に示されるように、様々なコンテンツプロセッサおよびソケットリスナのペアが、以前に登録されたアプリケーション１５０によって使用される。

新たなアプリケーション１１５０は、プッシュコンテナ１１１０に登録されたいと欲するとき、新たなコンテンツプロセッサ１１２０およびソケットリスナ１１３０は、サービスアプリケーション１０５０に割り当てられる。

それゆえ、上記は、ジェネリックなプッシュフレームワークに対して提供される。このフレームワークにおいて、新しいクライアントアプリケーション１５０は、インプリメントされ得、プッシュクライアント５１０、あるいはプッシュコンテナ１０１０または１１１０に登録され得る。これによって、デバイスが、新たなアプリケーションを動的に組み込みことの可能なアプリケーションプラットホームとなることができる。上記の図９および図１０のアプリケーションマニフェスト１０３０または９１８をパスすることによって、チャネルメタデータの確立が可能になり、これによって、コンテンツが、アプリケーションの要求に従って処理される。

図１２を参照すると、コンテンツプロバイダ１１０は、同様に、プッシュプロキシ４１０に登録される必要がある。図１２に示されるように、プッシュプロキシ４１０は、３つのコンテンツプロバイダ、すなわち、１２１０、１２１２および１２１４を含み、これらは既にプッシュプロキシ４１０に登録されている。コンテンツプロバイダ１２１６は、プッシュプロキシ４１０に登録されたいと願う。

図９に示されるアプリケーション９１６によって提供されたアプリケーションマニフェスト９１８と同様に、プッシュクライアント５１０に登録されるとき、コンテンツプロバイダ１２１６は、サービスマニフェスト１２１８を含み、このサービスマニフェスト１２１８は、コンテンツプロバイダ１２１６が登録するとき、プッシュプロキシ４１０にパスされる。サービスマニフェスト１２１８は、コンテンツプロバイダが提供する情報のタイプに関する情報、この情報を提供する頻度、情報のフォーマット、およびサービスまたはサービスの広告に有用な他の情報を含む。他の情報も可能である。

プッシュプロキシ４１０は、サービスマニフェスト１２１８を用いて、コンテンツプロバイダ１２１６に対するチャネル（静的）メタデータを確立する。

図１３を参照すると、図２のアーキテクチャ２３０によって示される代替の実施形態は、プッシュプロキシ１２２およびコンテンツプロバイダ１１０のペアを幾つか備えたプッシュコンテナを有する。図１２と同様に、様々なアプリケーションが、プッシュコンテナ１３１０に既に登録され得、図１２の例において、アプリケーション１３１２、１３１４および１３１６は、それぞれプッシュプロキシ１３１３、１３１５および１３１７に既に登録されている。

新たなアプリケーション１３２０は、プッシュコンテナ１３１０に登録されたいと欲する。こうして、プッシュコンテナ１３１０は、新たなプロキシ（図示せず）を生成するか、あるいは、コンテンツプロバイダ１３２０と関連する既存のプロキシ（図示せず）を使用する。さらに、コンテンツプロバイダ１３２０は、サービスマニフェスト１３２２を提供し、コンテンツプロバイダ１３２０が提供することになるコンテンツを記述する。これによって、チャネルメタデータの確立が可能になる。

当業者には理解されるように、図９および図１０の実施形態は、プッシュクライアントに対する２つの選択肢を示し、それは、共有アプリケーションであるか、あるいは、アプリケーションごとに専用プッシュクライアントであるかのいずれかである。当業者は、他の実施形態も可能であることを理解する。同様に、図１２および図１３に関して、自身に登録された複数のコンテンツプロバイダを有するプッシュプロキシが示されるか、あるいは、各コンテンツプロバイダ対して専用で、プッシュコンテナに統合されたプッシュプロキシが示される。

図１４を参照すると、コンテンツプロバイダ１１０とクライアントアプリケーション１５０との間のメッセージ伝達が示される。コンテンツプロバイダ１１０は、プッシュプロキシ４１０への登録メッセージを提供する。このメッセージには、プッシュプロキシ４１０にチャネルメタデータを提供するために使用され得るサービスマニフェストを含み得る。これは、ステップ１４１０で行われる。

コンテンツプロバイダ１１０は、また、あるいは代替として、ステップ１４１２で示されるように、チャネルメタデータを引き続くメッセージに提供し得る。

プッシュプロキシ４１０は、次いで、ステップ１４１４で、利用可能なサービスのリスト（サービスカタログ）に、サービスを追加する。

図１４の例における随意のステップは、ステップ１４１６で、プッシュプロキシ４１０に、プッシュクライアント５１０に新たな利用可能なサービスを通知するためである。この通知は、ステップ１４１８で、クライアントアプリケーション１１０に伝播され得る。

当業者には理解されるように、ステップ１４１６および１４１８は随意であり、他の代替には、クライアントアプリケーション１５０が、新たなサービスを閲覧するために、プッシュプロキシ４１０から定期的にサービスカタログをプルすることを含む。

クライアントアプリケーション１５０に対するユーザまたはサービスプロバイダは、アプリケーション１５０がサービスに加入するべきであると決定し、クライアントアプリケーション１５０は、ステップ１４２０で、加入メッセージを送信する。この加入メッセージは、ステップ１４２２で、さらにプッシュプロキシ４１０にパスされる。

一度、プッシュプロキシ４１０が、ステップ１４２２で加入メッセージを受信すると、２つの選択肢が利用可能である。第一の選択肢は、加入するために、メッセージ１４２４をコンテンツプロバイダ１１０に送信し、次いで、ステップ１４２６に戻って、メタデータを含むメッセージエンベロープを受信する。このメタデータは、デバイスまたはデバイスのタイプに特定的であり得る。

代替として、プッシュプロキシ４１０は、ステップ１４２２で、コンテンツプロバイダ１１０によって既に提供され、プッシュプロキシ４１０に格納された情報に基づいて、加入メッセージを受信し得、ステップ１４３０で、プッシュクライアント５１０に返答する。この返答は、ステップ１５３２で、クライアントアプリケーション１５０に伝播される。理解されるように、この返答は、コンテンツプロバイダ１１０に特定的なチャネルメタデータを含み得る。

モデル間の違いは、そのアプリケーションに対するデータを誰がカスタム化するかに依存し得る。理解されるように、コンテンツプロバイダ１１０は、他の処理エレメントと比べて、コンテンツの最良のカスタム化を提供する。しかしながら、また、サービスプロバイダ１２０も、プッシュプロキシ４１０を介して、コンテンツのカスタム化も提供し得る。

さらに、理解されるように、コンテンツの構造は、アプリケーションが要求するデータに依存し得る。例えば、金融でのアプリケーションにおいて、アプリケーションは、株価と為替レートとの双方を欲し得る。以下のＸＭＬ：
＜ＦＩＮ＞
＜ｑｕｏｔｅｓ＞
＜ｑｕｏｔｅ ｔｉｃｋｅｒ＝ＡＢＣ＞
１８．５４
＜／ｑｕｏｔｅ＞
＜ｑｕｏｔｅ ｔｉｃｋｅｒ＝ＸＹＺ＞
１２３．４５
＜／ｑｕｏｔｅ＞
＜／ｑｕｏｔｅｓ＞
＜ｒａｔｅｓ＞
＜ｒａｔｅ ｉｄ＝“ＵＳ−ＣＡＮ”＞
１．１５
＜／ｒａｔｅ＞
＜ｒａｔｅ ｉｄ＝“ＵＳ−ＥＵＲＯ”＞
０．８５
＜／ｒａｔｅ＞
＜／ｒａｔｅｓ＞
＜／ＦＩＮ＞
が使用され得る。

ユーザが、株価のみを欲し、為替レートを欲しない場合、構造は、以下：
＜ＦＩＮ＞
＜ｑｕｏｔｅ ｔｉｃｋｅｒ＝ＡＢＣ＞
１８．５４
＜／ｑｕｏｔｅ＞
＜ｑｕｏｔｅ ｔｉｃｋｅｒ＝ＸＹＺ＞
１２３．４５
＜／ｑｕｏｔｅ＞
＜／ＦＩＮ＞
のように変化し得る。

メタデータは、アプリケーションに、構造にデータはパスされているという情報を提供し得る。

したがって、２つのモデルが存在する。静的データが、登録中に、または登録後に、プッシュプロキシ４１０およびプッシュクライアント５１０に提供され得る。代替として、プッシュプロキシ４１０およびプッシュクライアント５１０に対するメタデータは、事前に用意され得る。すなわち、情報は、アプリケーションがクライアントに登録されるまで、プッシュクライアントまたはプッシュプロキシに格納される。

ここで、図１５を参照する。図１５は、プッシュクライアント５１０にアプリケーションを登録すると生じるロジカルステップを示す。

一度、アプリケーションがプッシュクライアント５１０に登録されると、第一のステップ１５１０は、登録されたアプリケーションを、そのアプリケーションによって要求されるコンテンツタイプと合わせることである。これは、図９に示されるように、アプリケーションマニフェスト９１８から知られている。

第二のステップ１５２０は、アプリケーションに対する環境を設定することである。これらには、アプリケーションに対する格納および配信を随意に含むが、これらに限定されない。例えば、アプリケーションは、送信を所定のデータ量で制限し得る。フロー制御のイベントにおいて、あるいは、アプリケーションまたはクライアントが連絡を取らない場合、プッシュクライアント５１０は、アプリケーションに対するデータを捕らえることと、そして、随意で、データが待っている旨をアプリケーションに通知することとを要求し得る。

第三のステップ１５３０は、プッシュプロキシ４１０にアプリケーション設定を通知することである。これには、例えば、アプリケーションまたはプッシュクライアント５１０に利用可能なストレージを含む。理解されるように、プッシュプロキシ４１０は、プッシュクライアント５１０が格納し得るより多くのデータをプッシュしてはならない。したがって、アプリケーション設定は、パスされるデータの上限を含み得る。図４および図５を参照すると、これは、コンテンツ断片化ブロック４６４を呼び出し、アプリケーションが処理し得るより大きいコンテンツの場合、コンテンツを断片化し得る。また、データが非線形の場合、コンテンツ依存ブロック４６２は、図５のコンテンツ依存ブロック５６４用のメタデータを生成することを要求され得る。これは、コンテンツ依存ブロック５６４が、データを再構成することができるようにするためである。

再び、図１５を参照すると、ステップ１５３０は、また、データ配信に対する優先度を指示し得る。例えば、アプリケーションは、あるタイプのデータを他のタイプのデータに対して優先し得、これらのタイプのデータには、優先度が与えられ得る。こうして、ステップ１５３０は、タイプ「Ａ」のデータが即座に配信されるのに対し、タイプ「Ｂ」のデータが据え置き時間に配信され得る。

ここで、図１６を参照する。コンテンツプロバイダ１１０が、プッシュプロキシ４１０に登録されるとき、様々なステップが実行される。第一のステップ１６１０は、コンテンツ格納および配信に対して要求されたクライアント設定を解析することを含む。これは、コンテンツプロバイダ１１０からのコンテンツを消費できるデバイス上のプッシュクライアント５１０を同定するために、例えば、サービス広告に使用され得る。

第二のステップ１６２０は、とりわけ、プロキシ格納、配信オプション、変換オプションを含むプッシュプロキシが環境を設定することを可能にする。

ステップ１６３０で、プッシュプロキシ４１０は、アプリケーションが既にコンテンツプロバイダ１１０に登録されたかどうかをチェックし得る。このような場合、アプリケーションは、コンテンツと、配信チャネルが確立され、アプリケーションはコンテンツが送信され得る準備ができているという旨で、プッシュプロキシ４１０からコンテンツプロバイダ１１０への通知とを受信する準備ができている。

ステップ１６３０は、例えば、コンテンツプロバイダ１１０がオンラインに来る前に、アプリケーションがデバイスに事前にインストールされる場合に生じ得る。したがって、アプリケーションは、コンテンツプロバイダ１１０が利用可能になるのを待っているか、あるいは、アプリケーションがジェネリックタイプ（例えば、ブラウザまたＲＳＳビューア）で、複数のコンテンツプロバイダからの情報を消費できるかである。代替の設定において、コンテンツプロバイダ１１０は、アプリケーションがインストールされる前に既に利用可能であり、図１５の通知ステップ１５３０は、コンテンツを開始するために使用され得、コンテンツプロバイダ１１０からクライアントアプリケーション１５０へのフローを開始し得る。

図１６を参照して理解されるように、クライアント設定は、所定の情報を含み得る。この情報は、例えば、とりわけ、コンテンツ仕切りに対して使用される利用可能なストレージサイズ、フロー制御に対して使用される待ち行列サイズ、プッシュインターバルを含む配信スケジューリング、クライアントがプロキシから情報を取り出しているかどうか、偽プッシュモードを生成しているか、移動デバイスの画面サイズのようなカスタム化オプションである。

さらに理解されるように、サービスカタログは、異なるクライアントに対して、異なり得る。例えば、あるクライアントは、より多くのデータを利用可能であり得、異なる画面サイズ、または、他の条件を有し得る。これによって、コンテンツプロバイダ１１０に対し、そのクライアントは、この量の情報を扱い得ず、より小さな画面サイズなどを有するデバイスに比べ、より適切なものとなる。したがって、プッシュプロキシ４１０は、特定のクライアントアプリケーションに対するサービスカタログを、これらのクライアントアプリケーションの知識に基づいて生成し得、このクライアントアプリケーション１５０を有するこれらのデバイスのみが、コンテンツプロバイダに関する情報を受信し得る。

さらに理解されるように、一部の場合において、アプリケーションは、ユーザが介入することなく、サービスプロバイダおよびコンテンツプロバイダに基づいてインストールされ得る。例えば、コンテンツプロバイダ１１０は、プッシュプロキシ４１０に登録される場合、移動デバイスのユーザは、所定の情報を受け入れる契約義務を有し得る。したがって、プッシュプロキシ４１０は、アプリケーションをインストールし、アプリケーションをプッシュクライアント５１０にプッシュする準備ができていることをプッシュクライアント５１０を通知し得る。これは、例えば、ユーザが、自分の移動デバイスプランに優遇料金を得るために、所定量の広告を毎月受信することに同意したことを含み得る。コンテンツプロバイダ１１０は、広告プロバイダであり得、プッシュプロキシ４１０は、それゆえ、プッシュクライアント５１０に広告表示アプリケーションをプッシュし得る。このプッシュクライアント５１０は、プッシュクライアント４１０に登録されたアプリケーションインストーラによってサービスされ得、これによって、その処理を完全に駆動するコンテンツプロバイダ１１０およびサービスプロバイダ１２０を有する。

それゆえ、上記は、各アプリケーションまたはコンテンツプロバイダが、アプリケーションマニフェストまたはサービスマニフェストをそれぞれ登録し、提供するところに、プッシュフレームワークにおけるプラグイン登録モデルを提供する。アプリケーションマニフェストまたはサービスマニフェストは、登録中に、または登録に引き続き、プッシュプロキシ４１０およびプッシュクライアント５１０に、チャネルメタデータを確立するために使用される。その後、アプリケーション１５０が登録し、コンテンツプロバイダ１１０が登録するとき、コンテンツは、アプリケーション１５０とコンテンツプロバイダ１１０との間を流れ始め得る。

図４および図５を参照すると、チャネルメタデータは、メタデータ貯蔵庫４７０および５７０に格納される。しかしながら、動的メタデータが繰り返される場合、アーキテクチャ１００内に、様々な処理エレメント上に動的メタデータを格納することは、また有利である。理解されるように、これによって、プッシュプロキシ４１０上での処理の節約となる。なぜなら、現在のメタデータ抽出器４５０は、同じメタデータを何度も抽出する必要がなくなるからである。さらに、コンテンツ満了・置換モジュール４６６または５６６のような様々なモジュールは、パスされるコンテンツの各ピースに対して更新される必要がない。なぜなら、プッシュプロキシ４１０は、大量のプッシュクライアント５１０と協働し得るので、各コンテンツメッセージに対するこの処理の節約は、有意義であり得る。さらに、帯域幅は、コンテンツプロバイダ１１０とプッシュプロキシ４１０との間の固定ラインを介して、あるいは、プッシュプロキシ４１０とプッシュクライアント５１０との間の無線通信機器を介して、メタデータをパスする必要がないことによって、節約され得る。

ここで、図１７を参照する。図１７は、自分の最後のメタデータバージョンが処理エレメントによって格納される場合のランタイムフローの例を示す。

図１７に示されるように、コンテンツプロバイダ１１０は、コンテンツ［Ｃ_１＋Ｍ（ｐ，ｃ，ａ）_１］を含むコンテンツエンベロープを提供する。これは、第一のコンテンツペイロードが、プロキシメタデータ、クライアントメタデータおよびアプリケーションメタデータを含むメタデータに沿って流れることを意味する。これは、ステップ１７１０で送信される。

ステップ１７１２で、プッシュプロキシ４１０は、「Ｍ（Ｐ）_１を使用せよ」という文によって表わされているプロキシメタデータを使用する。さらに、ステップ１７１４で、
クライアントメタデータおよびアプリケーションメタデータを含むこのコンテンツプラスメタデータは、プッシュクライアント５１０にパスされる。

プッシュクライアント５１０は、ステップ１７１６で、クライアントメタデータを使用し、さらに、ステップ１７１８で、コンテンツペイロードをクライアントアプリケーション１５０にパスする。クライアントアプリケーション１５０は、ステップ１７２０で、アプリケーションメタデータを使用し、さらに、コンテンツペイロードを消費する。

ステップ１７２２で、Ｃ_２によって指定される第二のコンテンツペイロードは、第一のコンテンツペイロードと同じメタデータを有する。なぜなら、各処理エレメントは、すなわち、プッシュプロキシ４１０、プッシュクライアント５１０およびクライアントアプリケーション１５０は、コンテンツプロバイダ１１０に対するメタデータをキャッシュ化し、メタデータは、再びパスされる必要がないが、その代わりに、既に、処理エレメント上に常駐している。

その後、ステップ１７２４で、プッシュプロキシ４１０は、プッシュプロキシ４１０に対して以前にキャッシュ化されたメタデータを使用する。同様に、ステップ１７２６および１７２８で、プッシュクライアント５１０は、クライアントメタデータを使用し、クライアントアプリケーション１５０は、アプリケーションメタデータをそれぞれ使用する。ステップ１７２５および１７２７で、コンテンツは、メタデータを使用せずに、パスされる。

ステップ１７４０に示されるように、コンテンツは、プッシュクライアント５１０およびクライアントアプリケーション１５０に対する新たなメタデータを有し得るが、プッシュプロキシ４１０に対する古いメタデータを保存し得る。この場合、ステップ１７４０でパスされるメタデータは、クライアントメタデータおよびアプリケーションメタデータのみを含む。ステップ１７４２で、プッシュプロキシ４１０は、キャッシュ化プロキシメタデータを用いて、ステップ１７４４で、新たなクライアントメタデータおよびアプリケーションメタデータと一緒にコンテンツペイロードをパスする。

ステップ１７４６で、プッシュクライアント５１０は、自身にパスされた新たなクライアントメタデータを用いて、さらに、ステップ１７４８で、コンテンツペイロードおよびアプリケーションメタデータをパスする。

ステップ１７５０で、クライアントアプリケーションは、新たなアプリケーションメタデータを用い、さらにコンテンツペイロードを消費する。

当業者には理解されるように、メタデータが変化すること、メタデータが同じままで留まること、および変化したメタデータのみがそれを必要とする処理エレメントにパスされることに関して、様々な構成が存在し得る。当業者には理解されるように、処理エレメントは、自身が新たなメタデータを受信しない場合、自身が格納したキャッシュ化メタデータに戻り、これをコンテンツペイロード上で用いる。

更なる代替の実施形態において、インクリメントによる変化が、またメタデータになされ得る。例えば、ステップ１７６０で、新たなコンテンツペイロードは、デルタメタデータバージョンとともに、サービスプロキシ４１０にパスされ得る。プロキシメタデータのデルタは、以前にパスされたプロキシメタデータと、コンテンツが処理されるべき現在のメタデータとの間の差を含み得る。プッシュプロキシ４１０は、デルタを有する以前のメタデータを加えて、メタデータを構成し、次いで、ステップ１７６２で、これを用いてコンテンツペイロードを処理する。その後、変化がなかったので、ステップ１７６４で、コンテンツペイロードは、自身によって送信され、ステップ１７６６で、プッシュクライアント５１０は、以前にキャッシュ化されたクライアントメタデータを用いる。

プッシュクライアントは、次いで、ステップ１７６８で、コンテンツペイロードをクライアントアプリケーション１５０にパスし、このクライアントアプリケーション１５０は、ステップ１７７０で、コンテンツペイロード上の以前にキャッシュ化されたロケーションメタデータを用い、次いで、それをコンテンツペイロードで消費する。

インクリメンタルなデータの例は、コンテンツプロバイダが、コンテンツペイロード内の既存のフィールドの中で、３０が抽出され、クライアントアプリケーション１５０に送信されるべきであると、プロキシに告げる状況において使用され得る。引き続くトランザクションで、そのコンテンツペイロードのピースにとって重要である２つの追加フィールドが、コンテンツプロバイダ１１０によって、クライアントアプリケーション１５０にパスされる必要と思われ得る。コンテンツプロバイダは、それゆえ、インクリメンタルな変化を用いて、２つの追加のフィールドを抽出し、それらを以前に抽出された３０フィールドに追加するように、プロキシに告げ得る。デルタ（すなわち、２つの追加フィールド）をパスすることを必要とするだけなので、プッシュプロキシ４１０でメタデータを抽出するための処理時間は、削減され、それによって、処理は最適化される。

さらに理解されるように、メタデータは、様々な形式で到来し得る。メタデータは、ネイティブコード、あるいはＪａｖａ（登録商標）またはＣ＃（登録商標）のようなインタープリタ型コードでコンパイルされ得る。メタデータは、所定のプロパティを使用することを示すまた、データ／プロパティファイルでもあり得る。別の代替の実施形態において、メタデータは、バイナリコンテンツであり得て、例えば、ＸＭＬドキュメント上のＸＳＬＴ変換のような変換であり得る。

上記は、様々なアプリケーションに対して使用され、特定のクライアントアプリケーションにトランスファーされるコンテンツに対して、知能を提供し得る。また、上記は、単に、様々なコンテンツプロバイダが自分のデータを提供するメタデータに単に基づくことで、様々なアプリケーションに対するコンテンツを提供し得るリッチなコンテンツプロバイダに対しても提供され得る。これは、図１８の例によって示され得る。

コンテンツプロバイダ１１０は、例えば、オンライン書店であり得る。アプリケーションは、オンライン書店に登録し得、アプリケーション自らは、特定のジャンルの新刊を知らせて欲しいことをオンライン書店に指示し得る。これは、毎日、または毎週、あるいは毎月ベースで起こり得る。

コンテンツプロバイダ１１０は、例えば、ブックリスト１８１２を有するコンテンツエンベロープ１８１０をプッシュプロキシ４１０に送信し得る。また、コンテンツプロバイダが、変換（ｔｒａｎｓｆｏｒｍ）メタデータ１８１４も送信し得、このメタデータ１８１４は、例えば、自身が受信するアプリケーションに基づいて特定のコンテンツを変換するためのＵＲＬリンクであり得る。

一実施形態において、ブックリスト１８１２は、多数の本発明を含み得、本の著者と概要とを含む各本の記載を含む。ファイルは、例えば、サイズが１００ＫＢであり得る。

プッシュプロキシ４１０は、この大きなファイルを受信し得、サービスされているクライアントアプリケーションに基づいて、その大きなコンテンツファイルにされる必要がある変換を実現し得る。それは、クライアントにより良く適合するために、例えば、クライアントが受信可能であり得る１０キロバイトの情報に適合するためである。プロキシメタデータとしてパスされる変換は、それゆえ、ブックリストを１０ＫＢ修正ドキュメント１８２０に縮小するために、ブックリストに適用され得る。これは、例えば、概要を取り除き、本をランク付けし、上位５０冊のみを含めることによって、あるいは、当業者には明らかな他の変換によって、行われ得る。

一度、変換が完了すれば、修正ドキュメント１８２０は、次いで、プッシュクライアント５１０に送信される。

さらに、図４に示されるような据え置き検索メッセージストア４５２が、変換プロセスで取り除かれた格外のコンテンツを格納するために使用される。

上記の利点は、書店が１つのサイトを有し得、そのクライアントの全てに１つのリストを送り得ることである。様々なクライアントが、移動無線クライアントではないので、１００ＫＢファイルもこれらのクライアントに対して適切であり得る。また、変換データを提供することによって、書店は、書店が全員に送信する１つのリストを有し得る。当業者には理解されるように、ほとんどの現在のウェブ技術は、移動クライアントに対する別個のウェブサイトを要求するが、このことが上記の解決策によって克服される。

上記は、また、シンジゲートされたモデルに結び付き、ここで、図１９を参照する。

当業者には理解されるように、移動デバイスは、ネットワーク条件が大量のデータを受信するのに最適でないとき、大量のデータを受信することを望まないことがあり得る。さらに、ネットワークオペレータは、ネットワークのトラフィックが時間に対して、より均一になるようにするために、帯域幅の利用がピークの間は、大量のデータを送信することを避けたいと望み得る。これは、図１９に示されるように、プッシュ／プルモデルを用いて達成され得る。

図４を参照して以上に記載されたように、コンテンツは、ユーザが現在必要とし得るより多くの情報を含んで、提供され得る。例えば、ユーザが、自分のエリア内のレストランに対するロケーション情報をリクエストする場合、サービスプロバイダは、そのエリア内で利用可能な他のサービスのような広告を追加したいと望み得る。しかしながら、サービスプロバイダは、この追加コンテンツを即座にユーザへプッシュしたいと望まず、その代わりに、その追加コンテンツを示す見出しまたは目次のようなプライマ（ｐｒｉｍｅｒ）を提供したいと望み得る。

他の状況において、コンテンツは、ユーザにとってあまりにも大きくあり得るので、ユーザは、コンテンツの第一部のみを受信し得、そのコンテンツの残りは、据え置き検索メッセージストア４５２に格納される。

その後、格納されたコンテンツは、プッシュプロキシ４１０によって、あるいは自分のプッシュクライアント５１０に対して問われたときのいずれかに、プッシュクライアント５１０にパスされ得る。

プッシュクライアント５１０は、ネットワークのステータスをモニタし得るネットワークステータスモニタ１９１０を含む。プッシュクライアント５１０は、ある種の条件で、格外のデータを受信するのみでありたいと望み得る。例えば、ＷｉＦｉおよびセルラのオプションを有するハイブリッド移動デバイス上で、ＷｉＦｉ接続上のデータを提供する方が安価である。それゆえ、ネットワークステータスモニタ１９１０は、据え置きされたコンテンツを入手する前に、プッシュクライアント５１０がＷｉＦｉネットワークに接続されるまで待ち得る。代替として、ネットワークステータスモニタは、ローミング料金を最低にするために、クライアントが外国のネットワーク内でローミングしているのか。国内のネットワークで接続されているのかをチェックし得る。ネットワークステータスモニタは、また、専用データチャネルがデバイス用に確立されているかどうかをチェックし得る。プッシュクライアント５１０にパスされるべく据え置かれたデータをリクエストする前に、ネットワークステータスモニタ１９１０は、またネットワーク内の様々な他の前提条件をチェックし得ることを当業者は理解する。

無線ネットワーク１３０は、またプッシュクライアント５１０とプッシュプロキシ４１０との一方または双方に、データ配信のコストに関する情報を提供し得る。当業者には理解されるように、様々なピーク時間が、コンテンツ配信に生じる。交通情報の場合、ピーク時間は、人々が職場に行き、帰りする平日の始業および終業であり得る。株価に関しては、ピーク時間は、市場が開いている時間の間であり得る。他のピークも存在する。データトラフィックを平均化するために、ネットワーク内での現在のデータ利用に基づき、異なる料金を課すことが、ネットワークにとって望ましくあり得る。したがって、ピーク時間は、真夜中のような非ピーク時間に比べて、高い料金が課され得る。無線ネットワーク１３０は、それゆえ、プッシュクライアント５１０上の据え置き検索マネージャ５５２およびプッシュプロキシ４１０上のプッシュスケジューラ４５４に、配信コスト通知を提供する。

一つの実施形態において、コンテンツプロバイダ１１０からで、プッシュプロキシ４１０へパスされるデータは、クライアントにとってのその重要度に基づいてランク付けされ得る。ある種の情報は、メタデータを介して即座に配信されるように指定され得る。別の情報は、ネットワークコストが、第一の値（例えば、１メガバイト当たり１０セント）より小さいときに配信されるように指定され得、他のデータは、第二の値（例えば、１メガバイト当たり５セント）より小さいときに配信されるように指定され得る。こうして、スケジューラ４５４は、据え置き検索メッセージストア４５２内に格納されるデータを考慮し、据え置かれたデータをプッシュクライアント５１０のプッシュエージェント５４４にパスするように、プッシュエージェント４４４に命令する。

代替として、据え置き検索マネージャ５５２は、無線ネットワーク１３０から送信されるようなネットワーク状態をモニタし得、データ速度が、所定の速度未満の場合、コンテンツプルブローカ５５４に、据え置き検索メッセージストア４５２からのコンテンツをプルするように頼み得る。

代替として、マネージャ５５２は、ネットワークステータスが、より大量のデータをプルするのに好都合であること、例えば、移動デバイスがＷｉＦｉネットワークに接続されていたかどうかのようなことを確認し得、コンテンツプルブローカに、データを据え置き検索メッセージストア４５２からプルするように頼み得る。

さらに理解されるように、ユーザは、常にコンテンツがプルされるようにリクエストし得る。したがって、ユーザのリクエスト１９４０は、コンテンツプルブローカ５５４をトリガして、据え置き検索メッセージストア４５２からデータをプルするために使用され得る。

プッシュスケジューラ４５４および据え置き検索マネージャ５５２内に格納されたルールは、コンテンツの分類に基づく静的メタデータであり得る。ルールは、また、パスされてきた特定のデータに対する動的メタデータに基づき得る。この場合、コンテンツプロバイダ１１０は、データを分類する。

ここで、図２０を参照する。当業者には理解されるように、データは、線形または非線形の２つの形式の一方であり得る。線形データは、例えば、線形に流れるアレイまたはストリングあるいはコンテンツであり得る。非線形データは、逆に、互いに線形に関係しないデータであり、コンテンツマップまたはリンクに複雑に依存することを含み得る。

線形のコンテンツに対し、断片化は、データを線形進行（ｌｉｎｅａｒ ｐｒｏｇｒｅｓｓｉｏｎ）に基づく様々なコンポーネントに分解する（ｂｒｅａｋ）ことをただ伴うだけである。データは、セグメントに区分され、セグメントは、プッシュクライアント４１０に配信される。図２０に示されるように、断片化プロセッサ２０１０は、コンテンツ２０１２と相互作用し、コンテンツが線形進行とともに解析され（ｐａｒｓｅｄ）得ることを決定する。断片化プロセッサ２０１０は、次いで、データを図２０の例のセグメント２０１４、２０１６、および２０１８に区分し、図２０に示されるように、第二および第三のセグメント２０１６および２０１８をそれぞれパスすることを据え置く間に、第一のセグメント２０１４をパスする。

カーソルマネージメントモジュール２０３０は、配信されたセグメントの跡をつけ、順番に次のセグメントを配信する。

図２１を参照すると、非線形コンテンツは、より賢明な方法で区分される必要がある。さらに、先方で、セグメントを再構成するために、メタデータが要求される。

断片化プロセッサ２１１０は、メタデータベースの解析に基づき、コンテンツを解析する。これらは、論理的に要求される場合、所定のセグメントまたはデータエレメントを一緒に保つことを含む。断片化プロセッサ２１１０は、コンテンツ２１１２を解析し、コンテンツを論理的なルールに基づいて、セグメントに区分する。各セグメントは、コンテンツとメタデータとを含み、例えば、各コンダクタセグメントに対する依存性、マップ、およびナビゲーションルールを含む。

一度区分されると、第一のセグメント２１１４は、プッシュクライアント５１０に送信され、セグメント２１１６および２１１８の残余が、図２１に示されるように据え置かれる。セグメントナビゲーションブロック２１３０は、どのセグメントを次に送信するかを扱う。当業者には理解されるように、セグメント２１１４は、データ部分およびメタデータ部分を含む。セグメント２１１４のメタデータ部分は、断片化プロセッサ２１１０によって加えられるメタデータの層であり、そのコンテンツをどのように再構成するかをコンテンツ依存性モジュール５６４に指示する。第一のセグメント２１１４のデータ部分は、チャネルまたはコンテンツと関連するコンテンツおよびメタデータの双方を含み得る。

セグメントナビゲーションブロック２１３０は、いかにユーザがそのデータを介してトラベルするかを処理するように適応される。例えば、データがツリーフォーマットであり、ユーザがツリーの第一のブランチに下りていくと、セグメントナビゲーションブロック２１３０は、プッシュクライアント４１０に、ユーザがナビゲートしてきたエレメントから到達し得るツリーの他のブランチをパスされ得る。

例えば、ツリーは、会社の構造に沿った従業員名を有する従業員データベースを含み得る。図２１に基づき、ユーザが組織の特定の課の中にナビゲートすると、そのセグメンテーションナビゲーションブロック２１３０は、その課の中のグループに対するグループ断片に転送し得る。次いで、ユーザがその課の特定のグループの中にナビゲートすると、そのセグメンテーションナビゲーションブロック２１３０は、そのグループの中の従業員に対する情報断片をパスし得る。

それゆえ、上記は、データがロジカルコンポーネントに区分されることを要求する。識別子は、全てのタイプおよびコンテンツに割り当てられ、構造的情報は、プライマを有する情報をパスして生成される。

上記は、それゆえ、システムの構造を変化させることなく、アプリケーションおよびコンテンツを追加され得るジェネリックシステムで使用され得る動的コンテンツ配信に対するアーキテクチャを提供する。コンテンツは、そのコンテンツを受信するアプリケーションに適合するように個別仕上げされ得、上記に従って、断片化され得る。

理解されるように、プッシュクライアントおよびクライアントアプリケーションは、任意の移動デバイスに常駐し得る。一つの例示的な移動デバイスは、図２２を参照して以下に記載される。これは、限定することを意味するものでなく、例示的な目的で提供指される。

図２２は、本出願の装置および方法の好ましい実施形態で使用されることの多い移動局を示すブロック図である。移動局２２００は、少なくとも音声およびデータ通信能力を有する双方向通信デバイスであることが好ましい。移動局２２００は、インターネット上の他のコンピュータシステムとの通信能力があることが好ましい。提供される正確な機能性に依存して、この無線機器は、例えば、データメッセージングデバイス、双方向ページャ、データメッセージング能力を有する携帯電話、無線インターネット機器、あるいは、データ通信装置を意味し得る。

移動局２２００は、双方向通信が可能なとき、通常、通信サブシステム２２１１を組み込む。通信サブシステム２２１１は、受信機２２１２、送信機２２１４、１つ以上の（好ましくは内蔵されているか内部の）アンテナエレメント２２１６および２２１８などの関連コンポーネント、局部発振器（ＬＯ）２２１３、デジタル信号プロセッサ（ＤＳＰ）２２２０などの処理モジュールを含む。通信分野の当業者に明らかなように、通信サブシステム２２１１の特定の設計は、その機器が動作するように意図される通信ネットワークに依存する。

ネットワークアクセス要求は、また、ネットワーク２２１９のタイプに依存しても変化する。一部のＣＤＭＡネットワークにおいて、ネットワークアクセスは、移動局２２００の加入者またはユーザに関連する。ＣＤＭＡ移動局は、ＣＤＭＡネットワーク上で動作するために、取り外し可能ユーザ識別モジュール（ＲＵＩＭ）または加入者識別モジュール（ＳＩＭ）カードを要求する。ＳＩＭ／ＲＵＩＭインターフェース２２４４は、通常はカードスロットに似ており、この中に、ディスケットまたはＰＣＭＣＩＡカードのように、ＳＩＭ／ＲＵＩＭカードが挿入および排出され得る。ＳＩＭ／ＲＵＩＭカードは、約６４Ｋのメモリを有し、多数のキー構成２２５１と、ＩＤおよび加入者関連情報のような他の情報２２５３を保持し得る。

要求されるネットワーク登録または活性化手順が完了したとき、移動局２２００は、ネットワーク２２１９を介して、通信信号を送受信し得る。図２２に示されるように、ネットワーク２２１９は、移動デバイスと通信する複数の基地局からなり得る。例えば、ハイブリッドＣＤＭＡ １ｘＥＶＤＯシステムにおいて、ＣＤＭＡ基地局およびＥＶＤＯ基地局は、移動局と通信し、その移動局は同時に両者と接続される。ＥＶＤＯ基地局およびＣＤＭＡ １ｘ基地局は、異なるページングスロットを用いて、移動デバイスと通信する。

通信ネットワーク２２１９を介してアンテナ２２１６によって受信された信号は受信機２２１２へ入力され、受信機２２１２は、信号増幅、周波数下方変換、フィルタリング、チャンネル選択など、および、図２２に示される例のシステムにあるアナログデジタル（Ａ／Ｄ）変換などの一般的な受信機の機能を実行し得る。受信信号のＡ／Ｄ変換によって、ＤＳＰ２２２０において実行される復調および復号化などのより複雑な通信機能が可能になる。同様に、送信されるべき信号は、例えば、ＤＳＰ２２２０による変調および符号化を含む処理がされる。これらのＤＳＰ処理された信号は、デジタルアナログ変換、周波数上方変換、フィルタリング、増幅、アンテナ２２１８を介した通信ネットワーク上への送信のために、送信機２２１４へ入力される。ＤＳＰ２２２０は、通信信号を処理するだけでなく、受信機および送信機の制御を提供する。例えば、受信機２２１２および送信機２２１４における通信信号に付与されるゲインは、ＤＳＰ２２２０内でインプリメントされる自動ゲイン制御アルゴリズムを介して適合するように制御され得る。

移動局２２００は、機器の動作全体を制御するマイクロプロセッサ２２３８を含むことが好ましい。少なくともデータおよび音声通信を含む通信機能は、通信サブシステム２２１１を介して実行される。また、マイクロプロセッサ２２３８は、ディスプレイ２２２２、フラッシュメモリ２２２４、ランダムアクセスメモリ（ＲＡＭ）２２２６、補助入力／出力（Ｉ／Ｏ）サブシステム２２２８、シリアルポート２２３０、２つ以上のキーボードまたはキーパッド２２３２、スピーカ２２３４、マイク２２３６、短距離通信サブシステムのような他の通信サブシステム２２４０、および、一般的に２２４２で示される任意の他のデバイスサブシステムなどの追加デバイスサブシステムと相互作用する。シリアルポート２２３０は、ＵＳＢポート、または当業者には周知の他のポートを含み得る。

図２２に示されるサブシステムの一部は、通信関連の機能を実行するのに対して、他のサブシステムは「常駐の」またはオンデバイス機能を提供し得る。とりわけ、キーボード２２３２およびディスプレイ２２２２などの一部のサブシステムは、例えば、通信ネットワークを介する送信のためのテキストメッセージの入力などの通信関連機能と、計算器またはタスクリストのようなデバイス常駐機能との双方のために用いられ得る。

マイクロプロセッサ２２３８によって用いられるオペレーティングシステムソフトウェアは、フラッシュメモリ２２２４などの持続性ストアに格納されることが好ましい。フラッシュメモリ２２２４は、代替として、読み出し専用メモリ（ＲＯＭ）または同様のストレージエレメント（図示せず）であり得る。オペレーティングシステム、特定のデバイスアプリケーション、またはそのパーツが、ＲＡＭ２２２６などのような揮発性メモリの中に一時的にロードされ得ることは、当業者には理解される。また、受信された通信信号は、ＲＡＭ２２２６にも格納され得る。

図示されるように、フラッシュメモリ２２２４は、コンピュータプログラム２２５８と、プログラムデータストレージ２２５０、２２５２、２２５４および２２５６との双方の異なるエリアの中に分離され得る。これらの異なるストレージタイプは、これら自身のデータストレージ要求のために、各プログラムがフラッシュメモリ２２２４の一部分に割り当てられ得ることを示す。マイクロプロセッサ２２３８は、そのオペレーティングシステム機能に加えて、移動局上でソフトウェアプリケーションの実行を可能にすることが好ましい。例えば、少なくともデータおよび音声の通信アプリケーションを含む基本的な動作を制御する所定のアプリケーションのセットは、通常は製造中に移動局２２００にインストールされる。他のアプリケーションも、引き続き、あるいは動的にインストールされ得る。

好ましいソフトウェアアプリケーションは、移動局のユーザに関連するデータ項目を編成および管理する能力を有する個人情報管理（ＰＩＭ）アプリケーションであり得る。ユーザに関連する項目としては、ｅメール、カレンダーイベント、音声メール、約束、タスク項目などが挙げられるが、これらに限定されない。当然、１つ以上のメモリストアは、移動局において利用可能であり、ＰＩＭデータ項目のストレージを容易にする。このようなＰＩＭアプリケーションは、無線ネットワーク２２１９を介してデータ項目を送受信する能力を有することが好ましい。好ましい実施形態において、ＰＩＭデータ項目は、無線ネットワーク２２１９を介して、ホストコンピュータシステムに格納または関連付けされた移動局ユーザの対応データ項目を用いて、継続的に統合、同期および更新される。更なるアプリケーションは、また、ネットワーク２２１９、補助Ｉ／Ｏサブシステム２２２８、シリアルポート２２３０、短距離通信サブシステム２２４０、または任意の他の適切なサブシステム２２４２を介して移動局２２００上にロードされ得て、マイクロプロセッサ２２３８による実行のためにＲＡＭ２２２６または好ましくは不揮発性ストア（図示せず）内に、ユーザによってインストールされ得る。アプリケーションのインストールにおけるそのような柔軟性は、機器の機能性を高め、オンデバイス機能、通信関連機能、またはその双方の強化を提供し得る。例えば、確実な通信アプリケーションによって、移動局２２００を用いて実行される電子商取引機能および他のそのような金融取引が可能となり得る。

データ通信モードにおいて、テキストメッセージまたはウェブページダウンロードのような受信信号は、通信サブシステム２２１１によって処理され、マイクロプロセッサ２２３８に入力される。マイクロプロセッサ２２３８は、ディスプレイ２２２２または代替として補助Ｉ／Ｏデバイス２２２８への出力のために、受信信号をさらに処理することが好ましい。プッシュクライアント１４０および５１０と同等であり得るプッシュクライアント２２６０は、また、入力も処理し得る。

移動局２２００のユーザは、また、例えば、ディスプレイ２２２２およびおそらく補助Ｉ／Ｏデバイス２２２８と連動するキーボード２２３２を用いてｅメールメッセージのようなデータ項目を構成し得る。キーボード２２３２は、完全な英数字キーボードまたは電話タイプのキーパッドであることが好ましい。このように構成された項目は、通信サブシステム２２１１を介して通信ネットワークに送信され得る。

音声通信のために、移動局２２００の動作全体は、類似している。ただし、受信信号は、好ましくはスピーカ２２３４への出力であり、送信のための信号はマイク２２３６によって生成されるという点は除く。サブシステムを記録する音声メッセージのような代替の音声またはオーディオＩ／Ｏサブシステムは、また移動局２２００においてインプリメントされ得る。音声またはオーディオ信号出力は主にスピーカ２２３４を介して達成されることが好ましいが、ディスプレイ２２２２もまた用いられ得て、例えば、呼び出し人のアイデンティティの表示、音声呼び出しの長さ、他の音声呼び出し関連情報を提供する。

図２２におけるシリアルポート２２３０は、通常、携帯情報端末（ＰＤＡ）タイプの移動局でインプリメントされる。この移動局は、ユーザのデスクトップコンピュータ（図示せず）と同期することが、望ましいことであり得るが、随意の機器コンポーネントである。このようなポート２２３０によって、ユーザは、外部デバイスまたはソフトウェアプリケーションを介して優先度を設定でき、無線通信ネットワーク以外を介して、移動局２２００に情報またはソフトウェアのダウンロードを提供することで、移動局２２００の能力を拡張できる。代替のダウンロード経路は、例えば、直接それゆえ確実で信頼性ある接続を介して、機器に暗号化キーをロードし、それによって確実なデバイス通信を提供するために使用され得る。当業者には理解されるように、シリアルポート２２３０は、移動デバイスをコンピュータに接続して、さらに使用され、モデムとして機能し得る。

短距離通信サブシステムのような他の通信サブシステム２２４０は、更なる随意のコンポーネントであり、移動局２２００と異なるシステムまたはデバイスとの間に通信を提供し得る。このシステムまたはデバイスは、必ずしも同様のデバイスである必要はない。例えば、サブシステム２２４０は、赤外線デバイス、ならびに、関連回路およびコンポーネント、あるいは、Ｂｌｕｅｔｏｏｔｈ^ＴＭ通信モジュールを含み得て、通信に同様に有効化されたシステムおよびデバイスを提供する。

本明細書に記載された実施形態は、本出願の技術のエレメントに対応するエレメントを有する構造、システムまたは方法の例である。この書面による記載によって、当業者は、本出願の技術のエレメントと同様に対応する代替のエレメントを有する実施形態を実施し、使用することが可能となり得る。本出願の技術で意図される範囲は、したがって、本明細書に記載されたような本出願の技術と異ならない他の構造、システムまたは方法を含み、本明細書に記載されたような本出願の技術と実質的でない差を有する他の構造、システムまたは方法をさらに含む。

本特許出願は、図面を参照して、より良く理解される。
動的コンテンツ配信システムに対する基本的なアーキテクチャのブロック図である。 図１の動的コンテンツ配信システムの代替的なアーキテクチャのブロック図である。 コンピュータおよびメタデータフローを示す図１のブロック図である。 本システムおよび方法と関連して使用され得るプッシュプロキシを示すブロック図である。 本システムおよび方法と関連して使用され得るプッシュクライアントを示すブロック図である。 コンテンツおよびメタデータの多層エンベロープモデルを示すブロック図である。 図６のブロック図であり、各エンベロープに対する動的メタデータの処理ステップを示す。 図６のブロック図であり、静的および動的メタデータを用いる処理を追加的に示す。 アプリケーションが単一の共有プッシュクライアントに登録するプロセスを示すブロック図である。 アプリケーションがプッシュクライアントのプールをマネージするプッシュコンテナに登録するプロセスを示すブロック図である。 アプリケーションがコンテンツプロセッサおよびソケットリスナに登録するのを示すブロック図である。 コンテンツプロバイダが単一の共有プッシュプロキシに登録するのを示すブロック図である。 コンテンツプロバイダがプッシュプロキシのプールをマネージするプッシュコンテナに登録するのを示すブロック図である。 コンテンツプロバイダとクライアントアプリケーションとの間での登録メッセージを示すフロー図である。 プッシュクライアントとプッシュプロキシとの間での登録の間における相互動作を示すブロック図である。 プッシュプロキシとコンテンツプロバイダとの間での登録の間における相互動作を示すブロック図である。 コンテンツプロバイダと処理エレメントとの間でのコンテンツおよびメタデータのフローを示すフロー図である。 コンテンツに対する例示的な変換アプリケーションを示すブロック図である。 コンテンツシンジケート化モデルのブロック図である。 線形断片化プロセスのブロック図である。 非線形断片化プロセスのブロック図である。 本方法およびシステムと関連して使用され得る例示的な移動デバイスのブロック図である。

符号の説明

１００ アーキテクチャ
１１０ コンテンツプロバイダ
１２０ サービスプロバイダ
１２２ プッシュプロキシ
１３０ 無線ネットワーク
１４０ プッシュクライアント
１５０ クライアントアプリケーション

Claims (24)

1. 少なくとも第一の処理エレメントおよび第二の処理エレメントを有する動的コンテンツ配信アーキテクチャにおいて、コンテンツペイロードに処理知能を追加する方法であって、
   コンテンツペイロードを備える第一のエンベロープと、該第二の処理エレメント上でランされるように適合した第二の処理エレメントメタデータとを生成するステップと、
   該第一のエンベロープを含む第二のエンベロープと、該第一の処理エレメント上でランされるように適合した第一の処理エレメントメタデータとを形成するステップと
   を包含する、方法。
2. 前記第一の処理エレメントメタデータおよび前記第二の処理エレメントメタデータは、前記コンテンツペイロードに特有である、請求項１に記載の方法。
3. 前記第一の処理エレメントおよび前記第二の処理エレメントへの前記コンテンツペイロードに対するチャネルに関するメタデータを伝播するステップをさらに包含する、請求項１または請求項２に記載の方法。
4. 前記コンテンツペイロードに対するチャネルに関するメタデータを用いて、前記第一の処理エレメントおよび前記第二の処理エレメントを供給するステップをさらに包含する、請求項１または請求項２に記載の方法。
5. 前記少なくとも第一の処理エレメントおよび第二の処理エレメントは、プッシュプロキシ、プッシュクライアント、またはクライアントアプリケーションのいずれかを備える、請求項１〜４のいずれか１項に記載の方法。
6. 前記第一の処理エレメントで、前記第一の処理エレメントメタデータを抽出するステップと、
   該第一の処理エレメントメタデータを前記第一のエンベロープ上で用いて、処理された第一のエンベロープを生成するステップと、
   該処理された第一のエンベロープを前記第二の処理エレメントに配信するステップと
   をさらに包含する、請求項１〜５のいずれか１項に記載の方法。
7. 前記用いるステップと、配信するステップとの前に、前記チャネルに関するメタデータを前記第一のエンベロープに付与するステップをさらに包含する、請求項２または請求項３に従属する請求項６に記載の方法。
8. 前記第一の処理エレメントで、前記第一のエンベロープにメタデータを追加するステップをさらに包含する、請求項１〜７のいずれか１項に記載の方法。
9. 前記生成するステップと、形成するステップとは、コンテンツプロバイダによって実行される、請求項１〜８のいずれか１項に記載の方法。
10. 前記第二のエンベロープと、第三の処理エレメントに対する第三の処理エレメントメタデータとを備える第三のエンベロープを生成するステップをさらに包含する、請求項１〜９のいずれか１項に記載の方法。
11. 前記第一の処理エレメントメタデータは、処理パラメータ、処理ルール、処理ハンドラ、処理ハンドラコード、処理ハンドラリファレンス、処理ハンドラへのリンク、処理ハンドラコードへのリンク、および／または処理ハンドラルールへのリンクのいずれかを備える、請求項１〜１０のいずれか１項に記載の方法。
12. 動的コンテンツ配信アーキテクチャに対するコンテンツエンベロープであって、
    コンテンツペイロードと
    該動的コンテンツ配信アーキテクチャ内の第一の処理エレメントに対するコンテンツメタデータであって、該コンテンツ処理メタデータおよびコンテンツペイロードは、第一のエンベロープを形成する、コンテンツメタデータと、
    該動的コンテンツ配信アーキテクチャ内の第二の処理エレメントに対する第二のコンテンツメタデータであって、該第二のコンテンツ処理メタデータは、該第一のエンベロープとともにネスティングし、第二のエンベロープを形成する、第二のコンテンツメタデータと
    を備える、コンテンツエンベロープ。
13. 前記第一の処理エレメントおよび前記第二の処理エレメントは、プッシュプロキシ、プッシュクライアント、またはクライアントアプリケーションのいずれかを備える、請求項１２に記載のコンテンツエンベロープ。
14. 前記第二の処理エレメントに対する前記第二のコンテンツメタデータは、前記第二の処理エレメントに対する完全な命令を提供するようにアレンジされる、請求項１２または請求項１３に記載のコンテンツエンベロープ。
15. 前記第一の処理エレメントに対する前記コンテンツメタデータは、前記第一の処理エレメントに対する完全な命令を提供するようにアレンジされる、請求項１２〜１４のいずれか１項に記載のコンテンツエンベロープ。
16. コンテンツメタデータは、処理パラメータ、処理ルール、処理ハンドラ、処理ハンドラコード、処理ハンドラリファレンス、処理ハンドラへのリンク、処理ハンドラコードへのリンク、および／または処理ハンドラルールへのリンクのいずれかを備える、請求項１２〜１５のいずれか１項に記載のコンテンツエンベロープ。
17. 動的コンテンツ配信アーキテクチャにおいて、処理エレメントに対するメタデータと、連続処理エレメントに対するメタデータおよびコンテンツとを有するエンベロープを処理する方法であって、
    該処理エレメントに対するメタデータを該エンベロープから抽出するステップと、
    該メタデータを該連続処理エレメントに対するメタデータおよびコンテンツに用いて、これによって、処理されたネスティングされたエンベロープを生成するステップと、
    該処理されたネスティングされたエンベロープを該連続処理エレメントの一つに配信するステップと
    を包含する、方法。
18. 前記連続処理エレメントに対するメタデータおよびコンテンツ上で、前記コンテンツに対するチャネルメタデータを利用するステップをさらに包含する、請求項１７に記載の方法。
19. 前記チャネルメタデータは、前記処理エレメントが前記エンベロープを受信する前に、供給または伝播される、請求項１８に記載の方法。
20. 前記処理エレメントは、プッシュプロキシまたはプッシュクライアントのうちの一つである、請求項１７〜１９のいずれか１項に記載の方法。
21. 前記処理エレメントに対する前記メタデータは、処理パラメータ、処理ルール、処理ハンドラ、処理ハンドラコード、処理ハンドラリファレンス、処理ハンドラへのリンク、処理ハンドラコードへのリンク、および／または処理ハンドラルールへのリンクのいずれかを備える、請求項１７〜２０のいずれか１項に方法。
22. 動的コンテンツ配信アーキテクチャにおいて、処理エレメントに対するメタデータと、連続処理エレメントに対するメタデータおよびコンテンツとを有するエンベロープを処理するシステムであって、
    該処理エレメントに対する該メタデータを該エンベロープから抽出する手段と、
    該メタデータを該連続処理エレメントに対するメタデータおよびコンテンツに用いて、これによって、処理されたネスティングされたエンベロープを生成する手段と、
    該処理されたネスティングされたエンベロープを該連続処理エレメントの一つに配信する手段と
    を備える、システム。
23. 少なくとも第一の処理エレメントおよび第二の処理エレメントを有する動的コンテンツ配信アーキテクチャにおいて、コンテンツペイロードに処理知能を追加するコンピュータプログラム製品であって、請求項１〜１１のいずれか１項に記載の方法をインプリメントするために、コンピュータ機器、システムまたは装置によって実行可能なプログラムコード手段を具現化するコンピュータ可読媒体を備える、コンピュータプログラム製品。
24. 動的コンテンツ配信アーキテクチャにおいて、処理エレメントに対するメタデータと、連続処理エレメントに対するメタデータおよびコンテンツとを有するエンベロープを処理するコンピュータプログラム製品であって、請求項１７〜２１のいずれか１項に記載の方法をインプリメントするために、コンピュータ機器、システムまたは装置によって実行可能なプログラムコード手段を具現化するコンピュータ可読媒体を備える、コンピュータプログラム製品。

Images