JP2011100490A

JP2011100490A - プッシュコンテンツ配信システムを用いるクライアントアプリケーションおよびコンテンツプロバイダの媒介プラグイン登録

Info

Publication number: JP2011100490A
Application number: JP2011023135A
Authority: JP
Inventors: Michael Shenfield; シェンフィールドマイケル
Original assignee: Research in Motion Ltd
Current assignee: BlackBerry Ltd
Priority date: 2006-09-07
Filing date: 2011-02-04
Publication date: 2011-05-19
Anticipated expiration: 2027-09-04
Also published as: MX2007010864A; ATE416558T1; BRPI0703509A; KR100977502B1; EP1898597A1; HK1110457A1; TW200820703A; CN101141479A; AU2007211960A1; EP1898597B1; CA2600190C; SG140563A1; JP2008065825A; TWI357248B; JP4681588B2; AU2007211960B2; CA2600190A1; DE602006004049D1; KR20080023195A; JP5061249B2

Abstract

【課題】プッシュコンテンツ配信システムにおいて、ジェネリックエレメントをコンテンツ配信アーキテクチャに接続する方法を提供すること。
【解決手段】プッシュコンテンツ配信システムにおいて、ジェネリックエレメント２２３０、２２５５をコンテンツ配信アーキテクチャに接続する方法であって、該方法は、該ジェネリックエレメント２２３０、２２５５と該コンテンツ配信アーキテクチャとの間にメディエータ２２６０、２２７０を提供するステップと、該ジェネリックエレメント２２３０、２２５５に対するメタデータを該メディエータ２２６０、２２７０で抽出するステップと、該コンテンツ配信アーキテクチャに該ジェネリックエレメント２２３０、２２５５を登録するステップとを包含する、方法。
【選択図】図２２

Description

本開示は、一般的に、モバイル環境における動的コンテンツ配信に関し、より具体的には、ジェネリック（ｇｅｎｅｒｉｃ）アプリケーションまたはジェネリックコンテンツプロバイダを利用する動的コンテンツ配信に関する。

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

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

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

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

動的コンテンツ配信において、ジェネリックプッシュクライアントは、デバイス上の複数のターゲットアプリケーションをサービスする。同様に、プッシュプロキシは、複数のコンテンツプロバイダにサービスを提供する。効率的なランタイム登録メカニズムを提供することは、不可欠であり、そのランタイム登録メカニズムにおいて、アプリケーションおよびコンテンツプロバイダが、他のアプリケーションまたはコンテンツプロバイダに対するサービスを中断することなく、動的なコンテンツ配信のフレームワークに登録し得る。しばしば、クライアントアプリケーションまたはコンテンツプロバイダは、ジェネリックであり、特定のコンテンツ配信システムの固有の知識（ｉｎｔｒｉｎｓｉｃｋｎｏｗｌｅｄｇｅ）を有さない。

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

本開示の一局面において、メタデータは、コンテンツを提供され、このコンテンツを関連付けて、動的コンテンツ配信アーキテクチャ内の様々な処理エレメントのために、このコンテンツに知能を追加し得る。このアーキテクチャは、コンテンツ供給、プッシュプロキシを含むサービス供給、無線ネットワーク、プッシュクライアントおよびクライアントアプリケーションを提供するロジカルコンポーネントを含み得る。

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

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

動的メタデータは、パスされる特定のコンテンツと、逆に関連することもあり得る。

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

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

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

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

本開示の更なる局面において、ジェネリックアプリケーションまたはコンテンツプロバイダは、媒介プラグイン登録モデルを用いて、特定のコンテンツ配信エネーブラ（ＣＤＥ）に接続され得る。媒介プラグイン登録を用いると、メディエータは、専用アプリケーション、無線アプリケーションメタデータプロビジョニングを用いるジェネリックメディエータアプリケーション、あるいは配信フレームワーク認識ランタイム環境のいずれかであり得る。

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

本出願は、それゆえ、プッシュコンテンツ配信システムにおいて、ジェネリックエレメントをコンテンツ配信アーキテクチャに接続する方法を提供し得る。該方法は、該ジェネリックエレメントと該コンテンツ配信アーキテクチャとの間にメディエータを提供するステップと、該ジェネリックエレメントに対するメタデータを該メディエータで抽出するステップと、該コンテンツ配信アーキテクチャに該ジェネリックエレメントを登録するステップとを包含する。

プッシュコンテンツ配信システムにおいて、ジェネリックエレメントをコンテンツ配信アーキテクチャに接続するメディエータであって、該メディエータは、メタデータを抽出する抽出手段と、該ジェネリックエレメントに対する登録情報を、該コンテンツ配信アーキテクチャに提供する登録手段とを備える、メディエータ。

本発明は、さらに、以下の手段を提供する。

（項目１）
プッシュコンテンツ配信システムにおいて、ジェネリックエレメントをコンテンツ配信アーキテクチャに接続する方法であって、該方法は、
該ジェネリックエレメントと該コンテンツ配信アーキテクチャとの間にメディエータを提供するステップと、
該ジェネリックエレメントに対するメタデータを該メディエータで抽出するステップと、
該コンテンツ配信アーキテクチャに該ジェネリックエレメントを登録するステップと
を包含する、方法。

（項目２）
上記ジェネリックエレメントは、ジェネリックコンテンツプロバイダである、項目１に記載の方法。

（項目３）
上記提供するステップは、外部レポジトリからサービスプロバイダを提供することを包含する、項目１または項目２に記載の方法。

（項目４）
上記提供するステップは、
サービスプロバイダ上に、ジェネリックメディエータを位置付けるステップと、
上記ジェネリックコンテンツプロバイダに対するメタデータを、該メディエータから取得するステップと
を包含する、項目２に記載の方法。

（項目５）
上記取得するステップは、中央レポジトリまたはコンテンツプロバイダ特定レポジトリからメタデータを得ることを包含する、項目４に記載の方法。

（項目６）
上記ジェネリックエレメントは、ジェネリックアプリケーションである、項目１に記載の方法。

（項目７）
上記提供するステップは、外部レポジトリからモバイルデバイスを提供することを包含する、項目６に記載の方法。

（項目８）
上記外部レポジトリは、ジェネリックレポジトリまたはコンテンツプロバイダ特定レポジトリである、項目３または項目７に記載の方法。

（項目９）
上記メディエータは、上記コンテンツ配信アーキテクチャに特有である、項目７または項目８に記載の方法。

（項目１０）
上記提供するステップは、
モバイルデバイス上に、ジェネリックメディエータを位置付けるステップと、
該メディエータを用いて、上記ジェネリックコンテンツプロバイダに対するメタデータを取得するステップと
を包含する、項目６に記載の方法。

（項目１１）
上記取得するステップは、中央レポジトリまたはアプリケーション特定レポジトリからメタデータを得ることを包含する、項目６に記載の方法。

（項目１２）
上記登録するステップは、メタデータを利用する、項目１〜項目１１のいずれかに記載の方法。

（項目１３）
上記提供するステップは、ユーザ駆動である、項目１〜項目１１のいずれかに記載の方法。

（項目１４）
上記提供するステップは、自動である、項目１〜項目１１のいずれかに記載の方法。

（項目１５）
上記提供するステップの前に、コンテンツ配信認識環境を提供するアプリケーションをロードするステップをさらに包含する、項目１〜項目１４のいずれかに記載の方法。

（項目１６）
上記ジェネリックエレメントは、コンテンツプロバイダおよびアプリケーションのうちの一つである、項目１〜項目１５のいずれかに記載の方法。

（項目１７）
上記登録するステップは、上記コンテンツプロバイダを上記アプリケーションに、陽に結び付ける、項目１５に記載の方法。

（項目１８）
上記登録するステップは、上記コンテンツプロバイダを上記アプリケーションに、陰に結び付ける、項目１５に記載の方法。

（項目１９）
上記陰に結び付けることは、上記アプリケーションによって提供されたコンテンツタイプトークンを、上記コンテンツプロバイダによって提供されたコンテンツタイプトークンと比較する、項目１８に記載の方法。

（項目２０）
上記比較するステップは、上記アプリケーションによって提供された上記コンテンツタイプトークンと、上記コンテンツプロバイダによって提供された上記コンテンツタイプトークンとの間の重なり合うセグメントの数をカウントする、項目１９に記載の方法。

（項目２１）
上記登録するステップは、上記比較するステップからの上記カウントを利用して、アプリケーションをコンテンツプロバイダと結び付けるかどうかを決定する、項目２０に記載の方法。

（項目２２）
上記方法は、上記登録するステップの前に、
上記ジェネリックエレメントに対する配信ハンドリング情報を追加するステップと、
所定のフォーマットに情報を変換するステップと
をさらに包含する、項目１〜項目２１のいずれかに記載の方法。

（項目２３）
プッシュコンテンツ配信システムにおいて、ジェネリックエレメントをコンテンツ配信アーキテクチャに接続するメディエータであって、該メディエータは、
メタデータを抽出する抽出手段と、
該ジェネリックエレメントに対する登録情報を、該コンテンツ配信アーキテクチャに提供する登録手段と
を備える、メディエータ
（項目２４）
上記ジェネリックエレメントは、ジェネリックコンテンツプロバイダである、項目２３に記載のメディエータ。

（項目２５）
上記メディエータは、外部レポジトリからサービスプロバイダ上に提供される、項目２３または項目２４に記載のメディエータ。

（項目２６）
上記ジェネリックエレメントは、ジェネリックアプリケーションである、項目２３に記載のメディエータ。

（項目２７）
上記メディエータは、外部レポジトリからモバイルデバイス上に提供される、項目２６に記載のメディエータ。

（項目２８）
上記ジェネリックコンテンツプロバイダに対するメタデータを取得するように適合された通信手段をさらに備える、項目２４または項目２７に記載のメディエータ。

（項目２９）
上記登録手段は、メタデータを利用するように適合される、項目２３〜項目２８のいずれかに記載のメディエータ。

（項目３０）
上記ジェネレータエレメントは、コンテンツプロバイダおよびアプリケーションのうちの一方である、項目２３〜項目２９のいずれかに記載のメディエータ。

（項目３１）
上記登録手段は、上記コンテンツプロバイダを上記アプリケーションに、陽に結び付けるのに適合される、項目３０に記載のメディエータ。

（項目３２）
上記登録手段は、上記コンテンツプロバイダを上記アプリケーションに、陰に結び付けるのに適合される、項目３０に記載のメディエータ。

（項目３３）
上記陰に結び付ける手段は、上記アプリケーションによって提供された上記コンテンツタイプトークンの中のスキーマを、上記コンテンツプロバイダによって提供された上記コンテンツタイプトークンの中のスキーマと比較するように適合される、項目３２に記載のメディエータ。

（項目３４）
上記陰に結び付ける手段は、上記アプリケーションによって提供されたコンテンツタイプトークンと、上記コンテンツプロバイダによって提供されたコンテンツタイプトークンとの間の重なり合うスキーマの数をカウントするように適合される、項目３３に記載のメディエータ。

（項目３５）
上記登録手段は、上記カウントを利用して、アプリケーションをコンテンツプロバイダと結び付けるかどうかを決定する、項目３４に記載のメディエータ。

（項目３６）
上記ジェネリックエレメントに対する配信ハンドリング情報を追加するように適合された処理手段と、
所定のフォーマットに情報を変換するように適合された変換手段と
をさらに備える、項目２３〜項目３５のいずれかに記載のメディエータ。（摘要）
プッシュコンテンツ配信システムにおいて、ジェネリックエレメントをコンテンツ配信アーキテクチャに接続するための方法および装置であって、該ジェネリックエレメントと該コンテンツ配信アーキテクチャとの間にメディエータを提供するステップと、該ジェネリックエレメントに対するメタデータを該メディエータで抽出するステップと、該コンテンツ配信アーキテクチャに該ジェネリックエレメントを登録するステップとを包含する、方法および装置。

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

本特許出願は、図面を参照して、より良く理解される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プッシュプロキシ４１０は、プッシュプロキシサービスを統治する（ａｄｍｉｎｉｓｔｅｒ）ためのサービス統治（ａｄｍｉｎｉｓｔｒａｔｉｏｎ）ブロック４３０をさらに含む。

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

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

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

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

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

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

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

据え置き検索メッセージストアブロック４５２は、コンテンツまたはそのコンテンツの一部をクライアントアプリケーションに配信することが効率的でないときに、使用される。据え置き検索メッセージストアブロック４５２は、クライアントに配信されないコンテンツを、そのコンテンツを送信するのが効率的になるまで、あるいは、そのコンテンツがクライアントによってプルされるまで、格納するために使用され得る。据え置き検索メッセージストアは、また、補助コンテンツをキャッシュ化するためにも使用され得る。この補助コンテンツは、既に配信されたコンテンツを介するクライアントアプリケーションナビゲーションに依存するクライアントに随意に送信され得るか、あるいは、そのクライアントによって随意にプルされ得る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プッシュクライアント５１０は、プッシュクライアント５１０を統治するために使用されるクライアント統治５２０を含む。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プッシュプロキシ４１０は、プロキシサーバ６１２およびプッシュクライアントエンベロープ６１４に対するコンテンツ処理メタデータを含むプッシュエンベロープ６１０を受信する。プッシュプロキシ４１０は、コンテンツ処理メタデータ６１２を抽出し、このメタデータを用いて、プッシュクライアントエンベロープ６１４を処理する。メタデータ６１２は、プッシュクライアントエンベロープ６１４で何を行うかをプッシュプロキシに命令する（ｄｉｃｔａｔｅ）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プッシュプロキシ４１０は、プッシュプロキシサービスを統治するためのサービス統治ブロック４３０をさらに含む。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上は、コンテンツプロバイダおよびアプリケーションが、コンテンツ配信環境を認識するジェネリックシステムを提供する一方で、本開示の方法およびシステムの一つの実施形態において、コンテンツプロバイダ、アプリケーション、またはその双方のいずれかが、コンテンツ配信環境を認識しない。ここで、図２２を参照する。図２２において、コンテンツ配信エネーブラ（ＣＤＥ）２２１０は、コンテンツプロバイダ２２３０とクライアントアプリケーションとの間の動的コンテンツ配信、およびコンテンツプロバイダ２２３０をアプリケーションに結び付ける能力を促進するように適合される。コンテンツ配信エネーブラ２２１０は、図１のプッシュフレームワーク１００と均等である。

コンテンツ配信エネーブラ２２１０は、プッシュクライアント２２１２、無線ネットワーク２２１４、およびプッシュサーバ２２１６を含む。これらは、それぞれ図１のプッシュクライアント１４０、無線ネットワーク１３０、およびサービスプロバイダ１２０と均等であり得、図１に関連するコンポーネントの説明は、図２２の実施形態に適用可能である。

図２２の実施形態において、コンテンツプロバイダ２２３０は、ジェネリックコンテンツプロバイダである。換言すれば、コンテンツプロバイダ２２３０は、異なる配信手段を利用する異なる端末によって使用され、それゆえ、任意の特定のコンテンツ配信アーキテクチャに不可知（ａｇｎｏｓｉｔｉｃ）である。このようなジェネリック目的のコンテンツプロバイダ２２３０は、当業者に公知であり、広範な様々なクライアントをサービスする。

一部の状況において、モバイルデバイスのユーザは、定期的なブラウジングを介して、コンテンツプロバイダ２２３０にアクセスする。しかしながら、動的コンテンツ配信のようなより高度なサービスが、ジェネリック目的のコンテンツプロバイダ２２３０から要求される場合、ジェネリックコンテンツプロバイダ２２３０を上述されたようなコンテンツ配信アーキテクチャに導くための手段が要求される。コンテンツプロバイダ２２３０からコンテンツを受信したい任意のアプリケーションが、コンテンツプロバイダ２２３０に登録するオプションを与えられることを確実にするためには、コンテンツプロバイダ２２３０は、コンテンツ配信エネーブラ２２１０に登録されなくてはならない。さらに、コンテンツ配信エネーブラ２２１０は、ジェネリックコンテンツプロバイダ２２３０から提供されるコンテンツに関するメタデータ情報を有する必要があり、配信スキーマおよびスケジュールを確立するために、そのコンテンツを処理することの可能なアプリケーションまたはアプリケーションのタイプ、あるいはコンテンツ配信エネーブラ２２１０およびアプリケーション見通しから必要とされる任意の他の情報を識別する必要がある。

コンテンツプロバイダ２２３０を、図１〜図２１を参照して上述されたようなコンテンツ配信アーキテクチャの中に導くために、メタデータは、コンテンツプロバイダ２２３０のために存在することが必要である。

同様に、図２２に示されるクライアントアプリケーション２２４０、２２４５、または２２５０のようなクライアントアプリケーションは、本明細書で、ジェネリックアプリケーション２２５５と称されるジェネリッククライアントアプリケーションであり得る。換言すれば、ジェネリックアプリケーション２２５５は、コンテンツ配信アーキテクチャに不可知であり得る。

ジェネリックアプリケーション２２５５が、コンテンツ配信モデルを意識しないときで、コンテンツ配信モデルを介して動的コンテンツを受信するために、相互作用するように特に設定されていないとき、このようなアプリケーション２２５５は、独力で、コンテンツ配信エネーブラ２２１０に登録することができない。これらのアプリケーション２２５５は、典型的には、コンテンツ配信エネーブラおよび登録インターフェースの知識を有さないので、したがって、図１〜図２１を参照して記載された上述のモデルにフィットしない。

ジェネリックコンテンツプロバイダ２２３０と同様に、ジェネリックアプリケーション２２５５に関与することが望ましい。このようなアプリケーションは、モバイルデバイスのユーザに、モバイルデバイス上にロードされたアプリケーションと、一度ロードされたアプリケーションの機能性とに関する選択をより多く提供する。

ジェネリックアプリケーション２２５５のようなアプリケーションに関与するために、本開示は、メディエータ２２６０を提供する。メディエータ２２６０の役割は、このメディエータが登録するアプリケーションのメタデータに関する知識、およびアプリケーションを登録するためのメタデータスキーマを含む登録インターフェースに関する知識を有することである。

メディエータ２２６０は、ジェネリックまたはアプリケーション特有のいずれかであり得る。例えば、メディエータ２２６０は、アプリケーションとともに、アプリケーション開発者によって提供され得る。次いで、例えば、特定のアプリケーションを特定のコンテンツ配信エネーブラに登録するために、アプリケーションがモバイルデバイス上にロードされるとき、メディエータ２２６０は、ランされる。この場合、メディエータ２２６０は、アプリケーションに対するメタデータ情報を含む。

代替として、ジェネリックメディエータ２２６０は、モバイルデバイス上に存在し得る。この場合、一度アプリケーション登録が要求されると、例えば、トリガの中でもとりわけ、モバイルデバイス上にロードされたアプリケーションを有することによって、コンテンツ配信エネーブラ２２１０を有するアプリケーションのユーザリクエスト登録を有することによって、アプリケーション用に向けられたプッシュデータを受信することによって、ジェネリックメディエータ２２６０は、レポジトリ２２８０に行き得、アプリケーションに対するメタデータを獲得し得る。

理解されるように、一度、アプリケーション２２５５に対するメタデータがメディエータ２２６０によって受信されると、次いで、メディエータは、アプリケーションをコンテンツ配信エネーブラ２２１０と結び付けることを要求される。

ここで、図２３を参照する。メディエータ２３７０は、アプリケーション２３１０と関連するメタデータ２３２０を、コンテンツ配信エネーブラ２３４５によって要求されるメタデータスキーム２３４０にリゾーブし（ｒｅｓｏｌｖｅ）ようと試みる。特に、アプリケーション２３１０は、自身と関連するメタデータを含み、このメタデータは、本明細書では、アプリケーションメタデータ２３２０と称される。アプリケーションメタデータ２３２０は、アプリケーション２３１０が期待している様々なパラメータを含む。例は、ストレージパラメータを含み、とりわけ、到着しつつあるコンテンツが格納される場所、アプリケーションが進んで受け入れるデータの断片化またはサイズ制限を含む。他のパラメータは、例えば、通知パラメータを含み、通知パラメータは、アプリケーションがコンテンツ到着を通知されるべきかどうか、あるいはコンテンツが、キャッシュを用いることによってなど、アプリケーションに直接提供されるべきであるか、もしくはコンテンツが所定のロケーションに格納されるべきであるかを含む。アプリケーションに対して特有の他のメタデータもまた、本開示の範囲の中に入ることは、理解される。

図２３で、さらに分かるように、コンテンツ配信エネーブラは、自身と関連するメタデータスキームを含み、本明細書では、コンテンツ配信エネーブラメタデータスキーム２３４０と称される。理解されるように、コンテンツ配信エネーブラメタデータスキーム２３４０は、コンテンツ配信エネーブラ２３４５によって必要とされるアプリケーション関連パラメータを処理して、アプリケーション用のコンテンツをハンドリングし、配信することを可能にする。

メディエータ２３７０は、コンテンツ配信エネーブラメタデータデータスキーム２３４０を用いて、メタデータ２３２０をリゾーブする。このようなレゾリューションは、アプリケーションメタデータ２３２０を読み出すステップと、必要とされるパラメータおよび情報を抽出するステップと、配信ハンドリング関連情報をアプリケーションメタデータ２３２０に追加するステップと、データをアプリケーション２３１０に対して許容可能なフォーマットに変換するステップと、コンテンツ配信エネーブラ２３４５を用いて、アプリケーション２３１０の登録へと進むステップとを含む。配信ハンドリング関連情報を追加することは、デバイスの事前に特定されたパラメータに基づき得るか、あるいはユーザが自分の受信したいと願うデータに関する情報、あるいはその情報をハンドリングすることを特定したいと駆り立てられた場合のように、ユーザ入力を含み得る。

同様に、図２２のメディエータ２２７０は、コンテンツプロバイダ２２３０のメタデータとプッシュサーバ２２１６に対するメタデータとの間で、同様の機能を実行する。メディエータ２２７０は、コンテンツプロバイダとコンテンツ配信エネーブラメタデータとの間のパラメータを接続する。

メディエータ２２６０および２２７０は、それによって、それぞれジェネリックアプリケーションおよびジェネリックコンテンツプロバイダを可能にする。メディエータ２２６０が上述の機能性を実行して利用可能にさせるためには、様々なオプションが利用可能である。

モバイルデバイス上のランタイム環境は、コンテンツ配信認識であるか、コンテンツ配信認識でないかのいずれかである。ランタイム環境が、コンテンツ配信認識である場合、ランタイム環境は、２つの方法のうちの１つで機能し得る。第一の方法において、ランタイム環境は、新たなアプリケーションが、インストールされることが分かり得、ユーザは、コンテンツ配信システムに、あるいはジェネリックアプリケーション２２５５がコンテンツ配信エネーブラ２２１０に接続されるべきことを示す他のトリガに、アプリケーションを接続したいと願う。

一つの実施形態において、ランタイム環境は、次いで、中央レポジトリからダウンロードされるアプリケーション特定メディエータ２２６０を開始し得る。メディエータ２２６０は、様々な時間に、エアを介して提供され得る。様々な時間は、とりわけ、アプリケーションがモバイルデバイスに最初にロードされるとき、ユーザがアプリケーションから動的コンテンツ配信をリクエストするとき、モバイルデバイス上によってサービスされ得るコンテンツが到着するときを含む。アプリケーション特定メディエータ２２６０は、アプリケーションメディエータのサービスプロバイダが管理するレポジトリから提供され得るか、あるいはアプリケーション開発者または小売業者によって提供されるアプリケーション用のレポジトリの中に、アプリケーション開発者または小売業者によって提供され得る。

一度、アプリケーション特定メディエータ２２６０がダウンロードされると、ランタイム環境は、ダウンロードメディエータ２２６０を実行し得、これによって、アプリケーションをコンテンツ配信エネーブラに結び付ける。

代替として、ランタイム環境自身が、メディエータアプリケーションとして、機能し得る。この場合、この環境は、どのように登録処理を実行するかを知っており、中央レポジトリからアプリケーションに対するメタデータをダウンロードし得る。この時点で、ランタイム環境は、メタデータを用いて、アプリケーションをコンテンツ配信エネーブラ２２１０に登録し得る。

さらなる実施形態において、ランタイム環境は、コンテンツ配信を認識しない場合、ユーザは、ジェネリックアプリケーション登録のために、特別アプリケーションをロードすることを開始する必要がある。特別アプリケーションは、デバイスコンテンツ配信を認識させ、ダウンロードされた特別アプリケーションは、次いで、ジェネリックアプリケーション登録のトリガが発生する場合はいつも、ジェネリックアプリケーションに対するメタデータを見出して、見出したメタデータを用いて、アプリケーションを登録することに進む。

したがって、上記は、アプリケーションと、そのアプリケーションと関連するメタデータとをロードして、実行して、結び付けることが、自動であり得るか、あるいはユーザ駆動であり得るかを説明している。換言すれば、ユーザが処理を開始し得るか、あるいはアプリケーションがデバイス上にダウンロードされるときはいつも、処理が自動的になされ得るかである。３つのモデルが開示される。それらは、コンテンツ配信認識ランタイム環境によって、レポジトリからアプリケーション特定メディエータをロードするモデルと、ジェネリックメディエータとして機能するコンテンツ配信ランタイム環境によって、レポジトリからアプリケーションメディエータをロードするモデルと、あるいはコンテンツ配信を認識しないランタイム環境を、コンテンツ配信アーキテクチャを認識する環境にさせる特別アプリケーションを、モバイルデバイス上にロードして、今ではコンテンツ配信を認識するアーキテクチャが、メタデータをダウンロードし得、ジェネリックメディエータとして機能し得るモデルである。

さらなる利用可能なオプションは、特定のアプリケーションをインストールしたモバイルデバイスに、登録メタデータまたはメディエータをプッシングすることである。このプッシングは、例えば、アプリケーションレポジトリからアプリケーションをダウンロードすると、そのアプリケーションレポジトリのようなサービスプロバイダまたは第三者エンティティから発生し得る。さらに、ユーザがプッシュクライアント２２１２をモバイルデバイス上にインストールし、それによって、コンテンツ配信フレームワークを繋げる（ｊｏｉｎ）とき、サービスプロバイダは、そのときに、モバイルデバイス上に既にインストールされたアプリケーションに対して、登録メタデータをプッシュし得る。この場合、アプリケーションのリストは、デバイスによって提供され得る。他のオプションは、本開示を考慮すると、当業者には明らかになる。

以上に示されたように、メタデータまたはメディエータアプリケーション自身を得るための中央レポジトリに対する代替は、アプリケーションを有するレポジトリを提供することである。換言すれば、様々なレポジトリは、各アプリケーション開発者のために存在する。次いで、各アプリケーション開発者は、アプリケーションに特有であるメディエータまたはメタデータを提供することが可能である。好ましい実施形態において、メタデータまたはメディエータはまた、利用されるコンテンツ配信アーキテクチャに特有でもあり得る。このように、図２２のメディエータ２２６０または図２３のメディエータ２３７０は、パラメータのマッチングを実行する必要がない。なぜなら、コンテンツ配信エネーブラメタデータ２３４０とアプリケーションメタデータ２３２０との間のパラメータは、マッチングするからである。

コンテンツプロバイダ２２３０に対して、調停（ｍｅｄｉａｔｉｏｎ）は、プッシュサーバ２２１６上で実行され、上記と類似である。換言すれば、プッシュサーバ２２１６は、特定のコンテンツプロバイダに対するメディエータを獲得し得るか、あるいはコンテンツプロバイダに対するメタデータをゲットし得るジェネリックメディエータを含み得る。仲裁は、コンテンツ配信エネーブラメタデータ２３４０とコンテンツプロバイダメタデータ（図示せず）との間で発生する。

以上のことは、陰に結び付けること、および陽に結び付けることを考慮して、さらに拡張され得る。本開示を考慮すると、当業者によって、理解されるように、アプリケーションは、コンテンツプロバイダに結び付けられる。換言すれば、コンテンツプロバイダは、そのコンテンツプロバイダが期待するアプリケーションまたはアプリケーションのタイプが、そのコンテンツプロバイダから提供されるデータをハンドリングするように指示し得る。

一つの例において、コンテンツプロバイダは、特定のアプリケーションのみが、そのコンテンツプロバイダからのコンテンツをハンドリングし得るように、特定し得る。コンテンツ配信エネーブラ２２１０は、次いで、特定のアプリケーションをインストールしたモバイルデバイスに、コンテンツプロバイダが利用可能であることを通知するのみである。そのアプリケーションに対するメタデータおよびパラメータは、コンテンツプロバイダから知られており、アプリケーションをコンテンツプロバイダに結び付けることは、したがって、陽である。

上述のコンテンツプロバイダおよびアプリケーションは、ジェネリックであり得る。換言すれば、コンテンツプロバイダおよびアプリケーションは、コンテンツ配信アーキテクチャに不可知であり得る。以上は、それゆえ、コンテンツプロバイダとコンテンツ配信エネーブラ２２１０との間と、コンテンツ配信エネーブラ２２１０とアプリケーション２２５５との間との双方に、メディエータを要求し得る。

アプリケーション２２５５はまた、陽に結び付けることを提供するようにも構成され得る。例えば、アプリケーションは、コンテンツが、コンテンツプロバイダ２２３０に対する特定のＵＲＩから要求されることを特定し得る。アプリケーション２２５５は、次いで、コンテンツプロバイダ２２３０より前に、登録される場合、モバイルデバイスは、アプリケーション２２５５によってリクエストされたコンテンツプロバイダ２２３０が登録すると、すぐに、通知される。

陽に結び付けることに関する関係は、サーバ側で管理される。コンテンツ配信エネーブラ２２１０は、コンテンツ配信エネーブラ２２１０に接続されているデバイスおよびアプリケーション２２５５に関する情報を有し、存在するアプリケーション２２５５を有するこれらのデバイスに、通知を送信するのみである。

代替として、陰の結び付けも起こり得る。例えば、コンテンツプロバイダ２２３０は、特定のタイプのコンテンツを提供していることを特定し得る。アプリケーション２２３０が、そのタイプのコンテンツの全て、またはサブセットを処理し得ることを特定する場合、コンテンツプロバイダ２２３０に対して許容可能であると、考えられ得る。

陰に結び付ける状況において、コンテンツプロバイダ２２３０とアプリケーション２２５５との双方は、コンテンツタイプトークンをコンテンツ配信エネーブラ２２１０に提供しなくてはならない。コンテンツ配信エネーブラ２２１０は、次いで、コンテンツプロバイダのトークンに対するスキームを、アプリケーションに対するトークンとリンクするかどうかをマッチングしなくてはならない。

一つの例において、コンテンツプロバイダ２２３０は、自身がＲＳＳフィードを提供することを示す。アプリケーションは、自身がＲＳＳフィードを処理し得ることを示す場合、マッチングが存在し、陰な結び付けが起こり得る。

理解されるように、コンテンツプロバイダは、数多くのタイプのでデータを提供し得、アプリケーションは、これらのタイプのデータの全てを処理できないこともあり得る。さらに、コンテンツプロバイダは、特別化またはカスタム化された情報を提供し得、アプリケーションは、ジェネリック処理を提供するのみであり得る。例えば、株価ＲＳＳコンテンツプロバイダは、例えば、株価情報に対する特殊化ＲＳＳフィードを提供する場合、ジェネリックＲＳＳフィードビューアアプリケーションは、株価情報に対して、期待されるユーザ体験を提供し得ない。

一つの実施形態において、強度メトリック（ｍｅｔｒｉｃ）が使用され、アプリケーションがコンテンツプロバイダに結び付けられるべきかどうかを決定し得る。したがって、アプリケーションは、コンテンツプロバイダによって提供されるスキームの任意のものを含まない場合、ゼロの強度が、登録され得、アプリケーションは、コンテンツプロバイダと結び付けられない。

強度は、アプリケーション２２５５によって解釈され得るコンテンツプロバイダ２２３０によって提供される情報タイプの数に関連し得る。したがって、０からＸまでの整数が、強度メトリックであり得、ここで、Ｘは、任意の整数であり得る。

強度メトリックは、アプリケーションをコンテンツプロバイダに結び付けることに関する決定をするために使用され得る。例えば、１の強度が存在した場合、ユーザは、アプリケーションをコンテンツプロバイダに結び付けたいと、願い得、プロンプトが、ユーザに提供され得る。例えば、２の強度が存在した場合、結び付けは、自動的に起こり得る。以上は、例として、意図されるのみで、様々な結び付けのスキームが、インプリメントされ得る。

以上の例で、それゆえ、コンテンツプロバイダは、「ＲＳＳ」、「金融」、および「株価」セグメントを含むコンテンツトークンと、コンテンツトークン「ＲＳＳ」を提供されたジェネリックＲＳＳフィードビューアアプリケーションとを提供される場合、強度は、１として、定義される。一方、アプリケーションが、金融情報に対してカスタム化されたＲＳＳビューアとして設計され、「ＲＳＳ」および「金融」セグメントを含むコンテンツトークンを提供される場合、強度は、２であり得る。

以上の開示を参照して、当業者によって理解されるように、アプリケーションをコンテンツプロバイダに結び付けることは、コンテンツ配信エネーブラ２２１０アーキテクチャにとって重要なことである。モバイルデバイスは、新たなコンテンツプロバイダが追加されるとき、どのアプリケーションが、そのコンテンツプロバイダの情報を処理し得るかを通知される。さらに、アプリケーションが、コンテンツ配信エネーブラ２２１０に登録しているとき、アプリケーション２２５５は、アプリケーションが利用し得るコンテンツプロバイダ２２３０のリストを提供され得る。アプリケーション２２５５またはコンテンツプロバイダ２２３０の全てが、それぞれどのプロバイダ２２３０またはアプリケーション２２５５と一緒に使用されることを意図されるかを、陽に提供するわけではないので、アプリケーションをコンテンツプロバイダに、陰に結び付けることが、コンテンツ配信エネーブラ２２１０によって実行される必要がある。

上述の強度メトリックは、使用され得る強度メトリックの単なる一例に過ぎない。さらに、コンテンツタイプトークンに対するスキームもまた、ジェネリックであるが、理解されるように、アプリケーションとコンテンツプロバイダとの双方に対して、共通である必要がある。コンテンツ配信エネーブラ２２１０は、陰に結び付けるための候補を特定するために、何らかのヒューリスティックスを適用しなくてはならない。さらに、トークンのコンテンツは、コンテンツ配信エネーブラ２２１０に、不透明であり得、一部の場合において、トークンのスキームもまた、不透明であり得る。例えば、これは、結び付けが、コンテンツタイプの完全なマッチングに対して起こる場合に、存在する。

強度メトリックの別の例は、比率であり、この比率は、絶対整数の代わりに、使用され得る。したがって、コンテンツプロバイダ２２３０が、コンテンツトークン内に３つのセグメント（例えば、「ＲＳＳ」、「金融」、「株価」）を提供する場合、ジェネリックＲＳＳビューアアプリケーション（例えば、「ＲＳＳ」）の比率は、１／３であり、金融情報に対する特殊化ＲＳＳビューア（例えば、「ＲＳＳ」および「金融」セグメント）の比率は、２／３である。

したがって、上記は、ジェネリックアプリケーションおよびジェネリックコンテンツプロバイダをコンテンツ配信エネーブラアーキテクチャに登録することを提供し、さらに、アプリケーションとコンテンツプロバイダに依存して、アプリケーションをコンテンツプロバイダに、陽に、あるいは陰に結び付けることを提供する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１００アーキテクチャ
１１０、２２３０コンテンツプロバイダ
１２０サービスプロバイダ
１２２プッシュプロキシ
１３０無線ネットワーク
１４０、２２１２、２３４８プッシュクライアント
１５０、２２４０、２２４５、２２５０クライアントアプリケーション
２２１０、２３４５コンテンツ配信エネーブラ
２２１６プッシュサーバ
２２５５ジェネリックアプリケーション
２２６０、２２７０メディエータ
２２８０レポジトリ
２３１０アプリケーション

Claims

動的コンテンツ配信インフラストラクチャ非認識コンテンツ消費アプリケーションを実行するプロセッサと、コンテンツ配信クライアントとを備えるモバイル通信デバイスであって、前記コンテンツ配信クライアントは、前記コンテンツ消費アプリケーションに代わってコンテンツ配信サーバからコンテンツを受信するように構成されており、
前記プロセッサは、前記コンテンツ消費アプリケーションに関連する登録情報を提供することによって、前記コンテンツ配信クライアントと前記コンテンツ配信サーバとのうちの少なくとも１つに前記コンテンツ消費アプリケーションを登録するように構成されるメディエータをさらに実行する、モバイル通信デバイス。
前記コンテンツ消費アプリケーションは、前記コンテンツ配信クライアントおよび前記コンテンツ配信サーバを構成するコンテンツ配信アーキテクチャを認識していない、請求項１に記載のモバイル通信デバイス。
前記登録情報は、メタデータにより特定される、請求項１に記載のモバイル通信デバイス。
前記メタデータは、前記コンテンツ消費アプリケーションに対するパラメータを含み、前記パラメータは、格納ロケーションと、断片化制限と、サイズ制限と、通知パラメータとのうちの少なくとも１つを含む、請求項３に記載のモバイル通信デバイス。
前記メタデータは、チャネルメタデータである、請求項３に記載のモバイル通信デバイス。
前記メタデータは、アプリケーションマニフェストである、請求項３に記載のモバイル通信デバイス。
前記メディエータは、前記コンテンツ配信クライアントおよび前記コンテンツ配信サーバを構成するコンテンツ配信アーキテクチャのために構成される、請求項１に記載のモバイル通信デバイス。
前記メディエータは、専用アプリケーションである、請求項１に記載のモバイル通信デバイス。
前記メディエータは、無線アプリケーションメタデータプロビジョニングを用いるメディエータアプリケーションである、請求項１に記載のモバイル通信デバイス。
前記メディエータは、レポジトリからアプリケーションメタデータにアクセスするように構成されるメディエータアプリケーションである、請求項１に記載のモバイル通信デバイス。
前記メディエータは、前記プロセッサ上で実行するランタイム環境である、請求項１に記載のモバイル通信デバイス。
複数のメディエータをさらに含み、前記複数のメディエータの各々は、特定のコンテンツ消費アプリケーションを登録するように構成されている、請求項１に記載のモバイル通信デバイス。
前記メディエータは、前記コンテンツ消費アプリケーションをインストールすると、前記モバイル通信デバイスにプッシュされる、請求項１に記載のモバイル通信デバイス。
前記メディエータは、前記コンテンツ消費アプリケーションを前記コンテンツ配信クライアントに陽に結び付けることによって、前記コンテンツ配信クライアントと前記コンテンツ配信サーバとのうちの少なくとも１つに前記コンテンツ消費アプリケーションを登録するように構成される、請求項１に記載のモバイル通信デバイス。
前記メディエータは、コンテンツタイプに基づいて前記コンテンツ消費アプリケーションを前記コンテンツ配信クライアントに結び付けることによって、前記コンテンツ配信クライアントと前記コンテンツ配信サーバとのうちの少なくとも１つに前記コンテンツ消費アプリケーションを登録するように構成される、請求項１に記載のモバイル通信デバイス。
前記コンテンツタイプに基づいて結び付けることは、前記コンテンツ消費アプリケーションにより提供されるコンテンツタイプトークンおよびコンテンツプロバイダにより提供されるさらなるコンテンツタイプトークンをマッチングする、請求項１５に記載のモバイル通信デバイス。
前記コンテンツタイプに基づいて結び付けることは、強度メトリックを用いて、コンテンツ消費アプリケーションと前記コンテンツプロバイダとの間のマッチングを決定する、請求項１６に記載のモバイル通信デバイス。