"動的コンテンツ配信インフラストラクチャ非認識コンテンツ消費アプリケーションを実行するプロセッサと、コンテンツ配信クライアントとを備えるモバイル通信デバイスであって、前記コンテンツ配信クライアントは、前記コンテンツ消費アプリケーションに代わってコンテンツ配信サーバからコンテンツを受信するように構成されており、前記プロセッサは、前記コンテンツ消費アプリケーションに関連する登録情報を提供することによって、前記コンテンツ配信クライアントと前記コンテンツ配信サーバとのうちの少なくとも1つに前記コンテンツ消費アプリケーションを登録するように構成されるメディエータをさらに実行する、モバイル通信デバイス。前記コンテンツ消費アプリケーションは、前記コンテンツ配信クライアントおよび前記コンテンツ配信サーバを構成するコンテンツ配信アーキテクチャを認識していない、請求項1に記載のモバイル通信デバイス。前記登録情報は、メタデータにより特定される、請求項1に記載のモバイル通信デバイス。前記メタデータは、前記コンテンツ消費アプリケーションに対するパラメータを含み、前記パラメータは、格納ロケーションと、断片化制限と、サイズ制限と、通知パラメータとのうちの少なくとも1つを含む、請求項3に記載のモバイル通信デバイス。前記メタデータは、チャネルメタデータである、請求項3に記載のモバイル通信デバイス。前記メタデータは、アプリケーションマニフェストである、請求項3に記載のモバイル通信デバイス。前記メディエータは、前記コンテンツ配信クライアントおよび前記コンテンツ配信サーバを構成するコンテンツ配信アーキテクチャのために構成される、請求項1に記載のモバイル通信デバイス。前記メディエータは、専用アプリケーションである、請求項1に記載のモバイル通信デバイス。前記メディエータは、無線アプリケーションメタデータプロビジョニングを用いるメディエータアプリケーションである、請求項1に記載のモバイル通信デバイス。前記メディエータは、レポジトリからアプリケーションメタデータにアクセスするように構成されるメディエータアプリケーションである、請求項1に記載のモバイル通信デバイス。前記メディエータは、前記プロセッサ上で実行するランタイム環境である、請求項1に記載のモバイル通信デバイス。複数のメディエータをさらに含み、前記複数のメディエータの各々は、特定のコンテンツ消費アプリケーションを登録するように構成されている、請求項1に記載のモバイル通信デバイス。前記メディエータは、前記コンテンツ消費アプリケーションをインストールすると、前記モバイル通信デバイスにプッシュされる、請求項1に記載のモバイル通信デバイス。前記メディエータは、前記コンテンツ消費アプリケーションを前記コンテンツ配信クライアントに陽に結び付けることによって、前記コンテンツ配信クライアントと前記コンテンツ配信サーバとのうちの少なくとも1つに前記コンテンツ消費アプリケーションを登録するように構成される、請求項1に記載のモバイル通信デバイス。前記メディエータは、コンテンツタイプに基づいて前記コンテンツ消費アプリケーションを前記コンテンツ配信クライアントに結び付けることによって、前記コンテンツ配信クライアントと前記コンテンツ配信サーバとのうちの少なくとも1つに前記コンテンツ消費アプリケーションを登録するように構成される、請求項1に記載のモバイル通信デバイス。前記コンテンツタイプに基づいて結び付けることは、前記コンテンツ消費アプリケーションにより提供されるコンテンツタイプトークンおよびコンテンツプロバイダにより提供されるさらなるコンテンツタイプトークンをマッチングする、請求項15に記載のモバイル通信デバイス。前記コンテンツタイプに基づいて結び付けることは、強度メトリックを用いて、コンテンツ消費アプリケーションと前記コンテンツプロバイダとの間のマッチングを決定する、請求項16に記載のモバイル通信デバイス。概要本システムおよび方法は、ジェネリックアプリケーションおよびコンテンツプロバイダが、アーキテクチャを改変する必要なしに、システムに追加されることを可能にする動的コンテンツ配信アーキテクチャおよびシステムを提供し得る。具体的には、現在のシステムおよび方法は、モバイルデバイスが、動的アプリケーションプラットホームになることを可能とし、そのモバイルデバイスにアプリケーションが追加され得、コンテンツが提供され得る。ここで、動的コンテンツ配信システムのアーキテクチャは、機器にインストールされ得るアプリケーションのタイプも、機器が受信するコンテンツのタイプも限定しない。本開示の一局面において、メタデータは、コンテンツを提供され、このコンテンツを関連付けて、動的コンテンツ配信アーキテクチャ内の様々な処理エレメントのために、このコンテンツに知能を追加し得る。このアーキテクチャは、コンテンツ供給、プッシュプロキシを含むサービス供給、無線ネットワーク、プッシュクライアントおよびクライアントアプリケーションを提供するロジカルコンポーネントを含み得る。本開示の更なる局面において、メタデータは、プッシュコンテンツメタデータに対する層状のエンベロープされたモデルで提供され得る。コンテンツは、メタデータでラップされ得、そのメタデータは、プッシュフレームワークの中の各エレメントで、処理するために使用され得る。各連続的なsuccessiveエレメントに対するメタデータは、層状にされ得、それによって、処理エレメントは、そのエレメントに対するメタデータのみを抽出することが可能になる。例えば、プッシュプロキシおよびクライアントアプリケーションに向けられるメタデータを含むコンテンツパッケージは、クライアントアプリケーションに対するメタデータの第一のレベル、およびプッシュプロキシに対するメタデータの第二の層を有するコンテンツを含み得る。それゆえ、エンベロープがプッシュプロキシに到達するとき、プッシュプロキシに対するメタデータは、抽出され得、コンテンツに適用され得、修正されたコンテンツおよびクライアントアプリケーションに対するメタデータは、さらなる処理エレメントにパスされる。本開示の別の局面において、メタデータは、静的メタデータ本明細書で、またチャネルメタデータとも称されると動的メタデータ本明細書で、コンテンツメタデータとも称されるとに分かれsplit得る。静的メタデータは、好ましくは、アプリケーションとコンテンツプロバイダとの双方への登録の際に確立され得る。しかしながら、チャネルメタデータは、後に確立され得る。チャネルメタデータは、配信されているコンテンツのタイプに特有である処理ルールと、コンテンツタイプに対するアプリケーション要求を特定し得る。動的メタデータは、パスされる特定のコンテンツと、逆に関連することもあり得る。本開示の別の局面において、プラグインplug-in登録モデルが、プッシュフレームワークの中で表現され得る。ジェネリックプッシュクライアントおよびプッシュプロキシが同定され、そのそれぞれが様々な処理ブロックまたはモジュールを有することで、これらのエレメントは、コンテンツとメタデータとの双方を処理することが可能になる。これらのブロックは、コンテンツがパスされているか、メタデータがパスされているか、あるいはコンテンツとメタデータとの双方がパスされているかのいずれかで、処理されるように向けられ得る。プラグイン登録は、さらにサービスマニフェストおよびアプリケーションマニフェストをパスすることを提供し得、コンテンツプロバイダとアプリケーションとの間のチャネルメタデータを確立することを可能にする。具体的には、サービスマニフェストは、コンテンツプロバイダをプッシュフレームワークに登録するために使用され得、アプリケーションマニフェストは、アプリケーションをプッシュフレームワークに登録するために使用され得る。本開示の別の局面において、シンジゲートされたコンテンツをプッシュする方法が、提供され得る。この方法によって、データをその優先順位に基づいて、ならびに、データ送信のコスト、接続されているネットワークのタイプ、またはユーザの好みを含むネットワーク因子に基づいて、取り扱うことが可能になる。シンジゲートされたコンテンツに対する随意の混合プッシュ/プルモデルによって、ネットワーク条件が好都合になったとき、プッシュプロキシがコンテンツをプッシュすること、あるいは、ネットワーク条件が好都合になったとき、またはユーザがコンテンツを要求したとき、クライアントがコンテンツをプルすることのいずれかが可能になる。様々なモバイルデバイスに適合するために、本開示の更なる局面は、非線形コンテンツ断片化を含むコンテンツに対するコンテンツ断片化を提供し得る。非線形コンテンツ断片化は、コンテンツをメタデータで増加させることを含み得、これによって、データが、一度クライアントにパスされると、再構成されることが可能になる。本開示の更なる局面において、ジェネリックアプリケーションまたはコンテンツプロバイダは、媒介プラグイン登録モデルを用いて、特定のコンテンツ配信エネーブラCDEに接続され得る。媒介プラグイン登録を用いると、メディエータは、専用アプリケーション、無線アプリケーションメタデータプロビジョニングを用いるジェネリックメディエータアプリケーション、あるいは配信フレームワーク認識ランタイム環境のいずれかであり得る。これらの局面および他の局面が、図面を参照して、より詳細に確認される。本出願は、それゆえ、プッシュコンテンツ配信システムにおいて、ジェネリックエレメントをコンテンツ配信アーキテクチャに接続する方法を提供し得る。該方法は、該ジェネリックエレメントと該コンテンツ配信アーキテクチャとの間にメディエータを提供するステップと、該ジェネリックエレメントに対するメタデータを該メディエータで抽出するステップと、該コンテンツ配信アーキテクチャに該ジェネリックエレメントを登録するステップとを包含する。プッシュコンテンツ配信システムにおいて、ジェネリックエレメントをコンテンツ配信アーキテクチャに接続するメディエータであって、該メディエータは、メタデータを抽出する抽出手段と、該ジェネリックエレメントに対する登録情報を、該コンテンツ配信アーキテクチャに提供する登録手段とを備える、メディエータ。本発明は、さらに、以下の手段を提供する。項目1プッシュコンテンツ配信システムにおいて、ジェネリックエレメントをコンテンツ配信アーキテクチャに接続する方法であって、該方法は、該ジェネリックエレメントと該コンテンツ配信アーキテクチャとの間にメディエータを提供するステップと、該ジェネリックエレメントに対するメタデータを該メディエータで抽出するステップと、該コンテンツ配信アーキテクチャに該ジェネリックエレメントを登録するステップとを包含する、方法。項目2上記ジェネリックエレメントは、ジェネリックコンテンツプロバイダである、項目1に記載の方法。項目3上記提供するステップは、外部レポジトリからサービスプロバイダを提供することを包含する、項目1または項目2に記載の方法。項目4上記提供するステップは、サービスプロバイダ上に、ジェネリックメディエータを位置付けるステップと、上記ジェネリックコンテンツプロバイダに対するメタデータを、該メディエータから取得するステップとを包含する、項目2に記載の方法。項目5上記取得するステップは、中央レポジトリまたはコンテンツプロバイダ特定レポジトリからメタデータを得ることを包含する、項目4に記載の方法。項目6上記ジェネリックエレメントは、ジェネリックアプリケーションである、項目1に記載の方法。項目7上記提供するステップは、外部レポジトリからモバイルデバイスを提供することを包含する、項目6に記載の方法。項目8上記外部レポジトリは、ジェネリックレポジトリまたはコンテンツプロバイダ特定レポジトリである、項目3または項目7に記載の方法。項目9上記メディエータは、上記コンテンツ配信アーキテクチャに特有である、項目7または項目8に記載の方法。項目10上記提供するステップは、モバイルデバイス上に、ジェネリックメディエータを位置付けるステップと、該メディエータを用いて、上記ジェネリックコンテンツプロバイダに対するメタデータを取得するステップとを包含する、項目6に記載の方法。項目11上記取得するステップは、中央レポジトリまたはアプリケーション特定レポジトリからメタデータを得ることを包含する、項目6に記載の方法。項目12上記登録するステップは、メタデータを利用する、項目1~項目11のいずれかに記載の方法。項目13上記提供するステップは、ユーザ駆動である、項目1~項目11のいずれかに記載の方法。項目14上記提供するステップは、自動である、項目1~項目11のいずれかに記載の方法。項目15上記提供するステップの前に、コンテンツ配信認識環境を提供するアプリケーションをロードするステップをさらに包含する、項目1~項目14のいずれかに記載の方法。項目16上記ジェネリックエレメントは、コンテンツプロバイダおよびアプリケーションのうちの一つである、項目1~項目15のいずれかに記載の方法。項目17上記登録するステップは、上記コンテンツプロバイダを上記アプリケーションに、陽に結び付ける、項目15に記載の方法。項目18上記登録するステップは、上記コンテンツプロバイダを上記アプリケーションに、陰に結び付ける、項目15に記載の方法。項目19上記陰に結び付けることは、上記アプリケーションによって提供されたコンテンツタイプトークンを、上記コンテンツプロバイダによって提供されたコンテンツタイプトークンと比較する、項目18に記載の方法。項目20上記比較するステップは、上記アプリケーションによって提供された上記コンテンツタイプトークンと、上記コンテンツプロバイダによって提供された上記コンテンツタイプトークンとの間の重なり合うセグメントの数をカウントする、項目19に記載の方法。項目21上記登録するステップは、上記比較するステップからの上記カウントを利用して、アプリケーションをコンテンツプロバイダと結び付けるかどうかを決定する、項目20に記載の方法。項目22上記方法は、上記登録するステップの前に、上記ジェネリックエレメントに対する配信ハンドリング情報を追加するステップと、所定のフォーマットに情報を変換するステップとをさらに包含する、項目1~項目21のいずれかに記載の方法。項目23プッシュコンテンツ配信システムにおいて、ジェネリックエレメントをコンテンツ配信アーキテクチャに接続するメディエータであって、該メディエータは、メタデータを抽出する抽出手段と、該ジェネリックエレメントに対する登録情報を、該コンテンツ配信アーキテクチャに提供する登録手段とを備える、メディエータ項目24上記ジェネリックエレメントは、ジェネリックコンテンツプロバイダである、項目23に記載のメディエータ。項目25上記メディエータは、外部レポジトリからサービスプロバイダ上に提供される、項目23または項目24に記載のメディエータ。項目26上記ジェネリックエレメントは、ジェネリックアプリケーションである、項目23に記載のメディエータ。項目27上記メディエータは、外部レポジトリからモバイルデバイス上に提供される、項目26に記載のメディエータ。項目28上記ジェネリックコンテンツプロバイダに対するメタデータを取得するように適合された通信手段をさらに備える、項目24または項目27に記載のメディエータ。項目29上記登録手段は、メタデータを利用するように適合される、項目23~項目28のいずれかに記載のメディエータ。項目30上記ジェネレータエレメントは、コンテンツプロバイダおよびアプリケーションのうちの一方である、項目23~項目29のいずれかに記載のメディエータ。項目31上記登録手段は、上記コンテンツプロバイダを上記アプリケーションに、陽に結び付けるのに適合される、項目30に記載のメディエータ。項目32上記登録手段は、上記コンテンツプロバイダを上記アプリケーションに、陰に結び付けるのに適合される、項目30に記載のメディエータ。項目33上記陰に結び付ける手段は、上記アプリケーションによって提供された上記コンテンツタイプトークンの中のスキーマを、上記コンテンツプロバイダによって提供された上記コンテンツタイプトークンの中のスキーマと比較するように適合される、項目32に記載のメディエータ。項目34上記陰に結び付ける手段は、上記アプリケーションによって提供されたコンテンツタイプトークンと、上記コンテンツプロバイダによって提供されたコンテンツタイプトークンとの間の重なり合うスキーマの数をカウントするように適合される、項目33に記載のメディエータ。項目35上記登録手段は、上記カウントを利用して、アプリケーションをコンテンツプロバイダと結び付けるかどうかを決定する、項目34に記載のメディエータ。項目36上記ジェネリックエレメントに対する配信ハンドリング情報を追加するように適合された処理手段と、所定のフォーマットに情報を変換するように適合された変換手段とをさらに備える、項目23~項目35のいずれかに記載のメディエータ。摘要プッシュコンテンツ配信システムにおいて、ジェネリックエレメントをコンテンツ配信アーキテクチャに接続するための方法および装置であって、該ジェネリックエレメントと該コンテンツ配信アーキテクチャとの間にメディエータを提供するステップと、該ジェネリックエレメントに対するメタデータを該メディエータで抽出するステップと、該コンテンツ配信アーキテクチャに該ジェネリックエレメントを登録するステップとを包含する、方法および装置。本特許出願は、図面を参照して、より良く理解される。好ましい実施形態の説明ここで、図1を参照する。クライアントアプリケーションに動的コンテンツを配信するジェネリックプッシュシステムが示される。図1のシステムは、簡略化されたシステムであり、動的コンテンツ配信アーキテクチャ内にあることを必要とするロジカルコンポーネントを示す。しかしながら、当業者には、他のコンポーネントが存在し得ること、あるいは、様々なコンポーネントが一緒にグループ化され得ることが理解される。アーキテクチャ100は、コンテンツプロバイダ110を含む。コンテンツプロバイダ110は、コンテンツプロバイダ110に契約しているユーザに動的コンテンツを提供するようにアレンジされる。実施例は、例えば、本を販売するウェブサイトを含み得る。ユーザは、コンテンツプロバイダ110に登録して、特定のジャンルの新刊本のリストを取得し得る。他の実施例は、数ある中で、定期的にユーザへヘッドラインを提供し得るニュースサイト、一日の所定の期間の間、ユーザに最新の交通情報を提供し得る交通サイト、ユーザに最新の株価または為替レートを提供し得る株式市場サイトを含み得る。以下に、より詳細に説明されるように、サービスプロバイダのクライアントが、コンテンツプロバイダ110からコンテンツを受信できるようにするために、コンテンツプロバイダ110は、サービスプロバイダ120に登録する。サービスプロバイダ120は、プッシュプロキシ122を含み、このプッシュプロキシ122は、クライアントまたはクライアントアプリケーションに対するプロキシとして機能し、コンテンツプロバイダ110にコンテンツを送信する目的地を提供する。サービスプロバイダ120は、モバイルデバイスに位置するプッシュクライアント140と、無線ネットワーク130を介して通信する。プッシュクライアント140は、以下に、より詳細に説明される。プッシュクライアント140は、コンテンツプロバイダ110から配信されるコンテンツを受信し、クライアントアプリケーション150と、コンテンツを通信し得、そのクライアントアプリケーション150は、最終的にコンテンツを消費する。本明細書において、コンテンツプロバイダ110、サービスプロバイダ120、プッシュプロキシ122、無線ネットワーク130、プッシュクライアント140、またはクライアントアプリケーション150への参照は、図1のアーキテクチャに戻っての参照である。図2を参照すると、図1のコンポーネントは、単にロジカルコンポーネントであり、必ずしも、個別の物理的コンポーネントである必要がないことは、当業者には理解される。図1は、ジェネリックアーキテクチャを示し、その中に、1つのコンテンツプロバイダ110と、1つのプッシュプロキシ122と、1つのプッシュクライアント140と、1つのクライアントアプリケーション150とが存在する。代替が、図2に示される。特に、第一の代替アーキテクチャ210は、プッシュプロキシ122と通信する複数のコンテンツプロバイダ110を含む。プッシュプロキシ122は、図1のアーキテクチャにおいてのように、無線ネットワーク130を介して、プッシュクライアント140と通信する。さらに、複数のクライアントアプリケーション150は、アーキテクチャ210の中に存在する。それゆえ、これは、複数のコンテンツプロバイダ110および複数のクライアントアプリケーション150を有するN-1-1-Nシステムである。図2のアーキテクチャ220は、プッシュプロキシ122と通信し、それに登録された1つのコンテンツプロバイダ110を含む。さらに、プッシュプロキシ122は、無線ネットワーク130を介して、複数のプッシュクライアント140と通信する。各プッシュクライアント140は、クライアントアプリケーション150と通信する。それゆえ、アーキテクチャ220は、クライアントアプリケーション150およびプッシュクライアント140のロジカルコンポーネントをグループ化し、N1-1-1-1システムである。図2のアーキテクチャ230は、複数のプッシュプロキシ122を有し、そのそれぞれは、コンテンツプロバイダ110と通信する。プッシュプロキシとコンテンツプロバイダとの各組み合わせ232は、無線ネットワーク130を介して、ジェネリックプッシュクライアント140と通信し、次いで、このプッシュクライアント140は、クライアントアプリケーション150と通信する。これは、1-1-N1-1システムである。図2のアーキテクチャ240において、コンテンツプロバイダ110およびプッシュプロキシ122のグループピング232は、無線ネットワーク130を介して、ジェネリックプッシュクライアント140とクライアントアプリケーション150との組み合わせと通信する。それゆえ、これは、N1-1-N1-1システムである。当業者によって理解されるように、他の代替も可能である。上記は、様々なロジカルコンポーネントを示し、これらのロジカルコンポーネントは、個別の物理的コンポーネントになり得るし、あるいは、一緒にグループ化され得る。例えば、プッシュクライアントは、アプリケーションに組み込まれ得るし、共有クライアントは、複数のアプリケーションまたは他の代替によって、使用され得る。ここで、図3を参照する。システムに知能を加えるために、コンテンツは、メタデータと関連している。この場合、メタデータは、処理エレメントによって使用され、コンテンツを操作し得るデータとして定義される。理解されるように、ジェネリックプッシュシステムは、様々なコンテンツプロバイダおよびアプリケーションが、システム内に存在できるようにするために、メタデータを要求する。メタデータは、様々な形式であり得、処理パラメータまたはルール、直接提供される処理ハンドラ、コードまたはリファレンス、あるいは、別の場所にある処理ハンドラ、コードまたはルールへのリンクを含む。図3から分かるように、コンテンツは、コンテンツプロバイダ110からクライアントアプリケーション150へと通過し、これは、矢印310によって示されている。アーキテクチャ100の中にある様々なコンポーネントに命令を提供するメタデータもまた、アーキテクチャ100の中のコンポーネントの間を、通常はコンテンツに沿って通過し得る。例えば、矢印320は、コンテンツプロバイダで生成し、クライアントアプリケーション150に到達するまで、配信システムに対して透過的なメタデータを示す。矢印330は、コンテンツプロバイダ110によって生成されたメタデータを示す。このメタデータは、プッシュクライアント140向けに意図されており、したがって、ジェネリックプッシュクライアント140に流れるのみである。矢印340は、サービスプロバイダ120によって生成されたメタデータを示し、このメタデータは、プッシュクライアント140向けに意図されており、プッシュプロキシ122でコンテンツと最初に関連し、ジェネリックプッシュクライアント140で、コンテンツから取り除かれる。これが起こり得る場所の例として、請求プランおよび提供されるべきサービスのレベルに関してのユーザとサービスプロバイダとの契約を含み、ここに、サービスプロバイダは、メタデータを用いて、利用可能なサービスを制限し得るし、あるいは拡張されたサービスを提供し得る。メタデータのフローおよびメタデータの役割は、以下に、より詳細に記載される。ここで、図4を参照する。図4は、詳細な例示的なプッシュプロキシ410を示し、このプッシュプロキシ410は、現在のシステムおよび方法と関連して使用され得る。当業者には理解されるように、プッシュプロキシ410は、図1および図2からのプッシュプロキシ122と同じであり得る。図4のプッシュプロキシ410は、プッシュプロキシ410がジェネリックプッシュ環境で動作することができる様々なエレメントを含む。これによって、プッシュプロキシは、特定のコンテンツプロバイダまたはプッシュクライアントとの相互作用に限定されず、その代わりに、動的な環境に適応し得るので、融通性が向上する。プッシュプロキシ410に対して以下に記載されるエレメントは、プッシュプロキシ410内に有することが好ましいが、これらのエレメントは網羅的なものではなく、他のエレメントも可能である。さらに、ある種のエレメントは、プッシュプロキシ410から除外され得るが、それでも、残りのエレメントで、ジェネリックプッシュサービスを実行できる。プッシュプロキシ410は、その中に登録されたコンテンツプロバイダ412を含む。コンテンツプロバイダ412は、コンテンツプロバイダ登録にサービスプロバイダインターフェースSPI420を登録する。以下に、より詳細に記載されるように、この登録において、コンテンツプロバイダ412は、確立されるチャネルに対するある種の情報、本明細書ではチャネルメタデータと称するが、これを含むことが望ましい。コンテンツプロバイダ412は、図1のコンテンツプロバイダ110と同じであり得る。プッシュプロキシ410は、プッシュプロキシサービスを統治するadministerためのサービス統治administrationブロック430をさらに含む。プッシュプロキシ410は、コンテンツと、そのコンテンツに関連するメタデータとの双方を取り扱う様々なモジュールを含む。第一のモジュールは、メッセージブローカ配信キュー440であり、これは、コンテンツプロバイダ412からのメッセージを消費するサブシステムであり、コンテンツ配信キューを管理する。当業者には理解されるように、コンテンツを順当に配信するために、全てのクライアントアプリケーションに対する全てのコンテンツは、一度に配信され得ないし、配信キューが、確立される必要がある。例えば、デバイスは、カバー範囲外であり得るし、またコンテンツは、格納されるべき必要があり得る。プッシュプロキシ410は、フロー制御管理ブロック442をさらに含む。フロー制御管理ブロック442によって、コンテンツのフローを制御できる。例えば、限られた空間内のモバイル局は、所定の量の情報を受信できるだけであり得る。この場合、モバイルデバイスは、図1に示されるようなプッシュクライアント140を介して、プッシュプロキシ410に、プッシュクライアント140へのデータのフローを停止するように求め得る。このフロー制御管理ブロック442は、これに対処する。代替として、モバイルデバイスは、オフラインであり得る。フロー制御管理ブロック442は、停止して、コンテンツがプッシュプロキシ410によって受信されたままの状態で配信され得ないとき、プッシュクライアント140へのデータのフローを開始する。プッシュプロキシ410の更なるコンポーネントは、プッシュエージェント444である。プッシュエージェント444は、クライアントにデータを送信する役割を担う。当業者には理解されるように、ブロック440、442および444は、メッセージ伝達のみを扱い、メタデータ関連ではない。言い換えれば、これらのブロックは、メッセージのコンテンツをハンドリングするが、コンテンツと関連するメタデータは一切取り扱わない。プッシュプロキシ410の更なるコンポーネントは、コンテンツメタデータ抽出器キャッシュブロック450である。コンテンツメタデータ抽出器キャッシュブロック450は、エンベロープされたenvelopedコンテンツメタデータ上で動作する。具体的には、以下に、より詳細に記載されるメタデータシステムのエンベロープモデルにおいて、システム内の各ロジカルコンポーネントは、コンテンツ処理と関連するメタデータを有し得る。このメタデータによって、ロジカルコンポーネントは、コンテンツにアクションを実行することができる。このように、各ロジカルコンポーネントは、自身と関連するメタデータを抽出できる必要がある。コンテンツメタデータ抽出器キャッシュブロック450は、プッシュプロキシ410と関連するメタデータを抽出し、このメタデータをキャッシュ化する役割を担う。キャッシュ化機能によって、同じコンテンツプロバイダからの引き続きくるコンテンツエンベロープ内の同一のメタデータをパスする必要がなくなるので、最適化できる。メタデータの抽出およびキャッシュ化は、以下に記載される。据え置き検索メッセージストアブロック452は、コンテンツまたはそのコンテンツの一部をクライアントアプリケーションに配信することが効率的でないときに、使用される。据え置き検索メッセージストアブロック452は、クライアントに配信されないコンテンツを、そのコンテンツを送信するのが効率的になるまで、あるいは、そのコンテンツがクライアントによってプルされるまで、格納するために使用され得る。据え置き検索メッセージストアは、また、補助コンテンツをキャッシュ化するためにも使用され得る。この補助コンテンツは、既に配信されたコンテンツを介するクライアントアプリケーションナビゲーションに依存するクライアントに随意に送信され得るか、あるいは、そのクライアントによって随意にプルされ得る。据え置き検索メッセージストアブロック452の目的は、図19および図21を参照して、以下に、より良く説明される。一例として、据え置き検索メッセージストアブロック452は、ユーザが、ユーザのロケーションの近くにあるレストランなどのロケーション情報をリクエストした場合に使用され得る。コンテンツプロバイダまたはサービスプロバイダは、情報を提供するモデルを有し得る。このとき、広告主は、お金を払って、自分たちの情報をサーチリクエストに追加し得る。したがって、あるロケーションに対するレストラン情報をリクエストしているユーザは、自分がリクエストしている自分のロケーションの近くに、商店、ゴルフコース、体育館または他のサービスに関する情報もまた、有し得る。コンテンツプロバイダは、リクエストされたレストラン情報に追加情報を束ねて、これらの情報をプッシュプロキシ410にパスする。プッシュプロキシ410は、提供されたメタデータに基づいて、コンテンツパッケージを生成し、クライアントに送信する。コンテンツパッケージには、クライアントによってリクエストされた情報、およびユーザが関心を有し得る関連情報のダイジェストまたは概要が含まれ得る。概要は、ユーザに送信されるが、据え置き検索メッセージストアブロック452は、コンテンツプロバイダ110から受信された実際のデータを格納する。こうして、将来、ユーザが、そのダイジェスト内にある情報に関するより詳細な情報を取得したいと思った場合、この情報は、プッシュプロキシ410に既に格納されている。据え置き検索メッセージストアブロック452に対する代替的な使用は、ユーザが一度にコンテンツ全体を受け入れ得ない場合である。例えば、デバイスにコンテンツ全部を送信することが、実現可能でない場合、あるいは経済的でない場合、コンテンツの一部は、後の時間まで、つまり、クライアントによってプルされ得るときまで、あるいは所定のルールが合致して、プッシュされ得るときまで、格納され得る。これらのルールは、満足される所定のネットワークまたはサービス条件により、ネットワークまたはサービス条件によって特定され得る。これについては、以下に、図19を参照して、より詳細に記載される。プッシュスケジューラ454は、クライアントに対する配信スロットをスケジューリングする。前述のように、一部の状況において、一度にコンテンツの全部をプッシュすることは効率的でないことがあり得る。プッシュスケジューラ454は、一部の情報を即座にプッシュして、その残りを所定のスケジュールに従ってプッシュすることを決定し得る。また、プッシュスケジューラ454は、コンテンツの性質を用い、そのコンテンツがプッシュされるべきときを決定し得る。具体的には、一部のコンテンツが高い優先度を有すること、あるいは時間的に限られた満了期限を有することをメタデータが示し得ると、このコンテンツは、即座にプッシュされ得る。それに対し、低い優先度を有するか、あるいは満了期限を有しないことを示されたコンテンツは、後に、データをパスする条件が、より好ましくなるときに、プッシュされ得る。当業者には理解されるように、ブロック450、452および454は、メッセージのコンテンツと、このメッセージと関連するメタデータとの双方を扱う。加入ルールブロック460は、サービスを受信するために登録されるアプリケーションを追跡し、配信されている特定のコンテンツをどのようにハンドリングするかのルールをモニタする。コンテンツは、典型的には、クライアントによる加入またはクライアントの代理としての加入に基づいて配信される。例えば、特定のサービスをユーザが欲する場合、そのユーザは、積極的に加入をリクエストし得る。加入は、ユーザの代理としてなされ得る。例えば、ユーザが、サービスの恩恵を受けるために、サービスプロバイダ120と契約にサインをした場合である。これは、ユーザが、所定の数の広告を毎日受信することに同意しさえすれば、ユーザが優遇料金で受信する場合を含み得る。この場合、サービスプロバイダ120が、クライアントの代理として、広告プロバイダに加入し得る。アプリケーションがモバイルデバイス上で消去されるとき、あるいはアプリケーションが加入を登録解除するとき、加入ルールブロック460は、そのユーザを加入中止にし得る。コンテンツ依存ブロック462は、プッシュプロキシ410によって使用され、モバイルデバイスのユーザが利用し得るサービスを広告する。したがって、モバイルデバイスのユーザが、サービスに対する十分な画面または帯域幅あるいはメモリを有しない場合、コンテンツ依存ブロック462は、そのサービスの広告をそのユーザに対して阻止し得る。コンテンツ断片化ブロック464は、コンテンツを断片化するために使用される。これが用いられ得るのは、例えば、モバイルデバイスが、一度にコンテンツの全てを受信できない場合である。コンテンツ断片化ブロック464は、コンテンツを様々なコンポーネントに分解するために使用される。これは、まだ配信されていない断片化コンテンツを格納するために、据え置き検索メッセージストア452と連携して使用され得る。コンテンツ満了置換ブロック466は、2つの目的で使用される。第一に、このブロックは、加入をモニタするために使用され得る。各加入には、満了時があり、この満了時に達したときに、加入は終了し得る。また、コンテンツ満了置換ブロック466は、情報をモニタするためにも使用され得る。ある種のコンテンツには、その情報の有効期限がある。例えば、ラッシュ時の交通をモニタするために使用される交通アプリケーションは、非常に時間依存性がある。何らかの理由で、プッシュプロキシ410が、モバイルデバイスにコンテンツを即座に配信できない場合、このコンテンツは、将来の配信のために、コンテンツストレージ480の中に格納される。しかしながら、コンテンツが所定の特定期間内に配信されない場合、このコンテンツは満了し得、全く配信され得ない。同様に、コンテンツ置換は、情報が更新される状況で扱われる。例えば、株価を受信するクライアントアプリケーションは、最新の株価を欲するのみであり得る。したがって、プッシュプロキシ410は、株価をプッシュクライアント140に配信できず、引き続く株価がコンテンツプロバイダ110から受信される場合、引き続く株価の中にあるメタデータが、以前の株価に置換されて使用されるべきであることを指示し得る。格納された情報の置換は、配信キューに全ての情報を加えるより、コンテンツストレージ480内の空間を開放する。チャネルメタデータレポジトリ470はチャネルメタデータを格納するために使用される。これについては、以下に、より詳細に記載される。以上は、本明細書における方法およびシステムで使用され得る例示的なプッシュプロキシ410を説明するものである。プッシュプロキシ410のブロックおよびエレメントによって、このプッシュプロキシ410が、ジェネリック動的コンテンツ配信システムで使用されることを可能にする。ここで、コンテンツのタイプおよびアプリケーションでのそのコンテンツのハンドリングは、変動し得、事前に決定されない。ここで、図5を参照する。図5は、本明細書のシステムおよび方法と関連して使用され得るプッシュクライアント510を示す。プッシュクライアント510は、図1および図2のプッシュクライアント140と同じであり得る。当業者には理解されるように、コンテンツおよびそのコンテンツ処理が事前に決定されていないジェネリックシステムで用いられることになるプッシュクライアント510は、コンテンツと、そのコンテンツと関連するメタデータとの双方に適合して使用され得るブロックまたはモジュールを含むべきである。図5に関して規定されるブロックは、網羅的であることを意図するものではなく、プッシュクライアント510内に他のブロックもまた存在し得る。さらに、プッシュクライアント510内のブロックは、一部の例において、プッシュクライアント510内の他のブロックの機能性を制約することなく、省かれ得る。プッシュクライアント510は、アプリケーションをサービスし、1つ以上のアプリケーション512は、プッシュクライアント510に登録され得る。アプリケーション登録は、登録用のインターフェースとして、アプリケーションプロバイダインターフェース514を使用し、アプリケーションプロバイダインターフェース514は、以下により詳細に記載されるように、アプリケーション用のチャネルメタデータを抽出するために、さらに使用され得る。プッシュクライアント510は、プッシュクライアント510を統治するために使用されるクライアント統治520を含む。図4のプッシュサーバ410と同様に、プッシュクライアント510は、メッセージ伝達を扱う様々なブロック、メタデータを扱う様々なブロック、およびメッセージ伝達とメタデータとの双方を扱う様々なブロックを含む。メッセージブローカアプリケーションキュー540は、配信用プッシュプロキシ410からアプリケーション512へのメッセージをハンドリングする。アプリケーションキューは、アプリケーション512に対するメッセージのキューである。フロー制御管理ブロック542は、図4のプッシュプロキシ410に、コンテンツのプッシュ停止またはコンテンツのプッシュ再開を通知するために使用される。これが使用され得るのは、例えば、プッシュクライアント510が、プッシュされたコンテンツを受け入れ得るメモリ量が限られているときである。この場合、プッシュコンテンツが消費される前に、プッシュクライアント510は、プッシュプロキシ410からのコンテンツのフローを停止する必要がある。一度、コンテンツが消費されると、フロー制御管理ブロック542は、再び、データのフローを開始するために使用され得る。プッシュクライアント510内のプッシュエージェント544は、図4のプッシュプロキシ410から情報を受信するために使用される。当業者には理解されるように、メッセージブローカアプリケーションキュー540、フロー制御管理ブロック542、およびプッシュエージェント544は、メッセージ伝達を独占的に扱い、メタデータを扱わない。コンテンツメタデータ抽出器キャッシュブロック550は、プッシュクライアント510に向かうことになっている動的メタデータを抽出するために使用される。図4のプッシュプロキシ410を参照して、以前に述べたように、動的コンテンツ配信アーキテクチャ内の処理エレメントはいずれも、これらの処理エレメントに向かう予定のメタデータを有し得、このメタデータは抽出される必要がある。このように、プッシュクライアント510に向かう予定のメタデータは、コンテンツメタデータ抽出器キャッシュブロック550によって抽出される。さらに、コンテンツメタデータ抽出器キャッシュブロック550は、キャッシュメタデータに適合されることが好ましい。第一のコンテンツパッケージと第二のコンテンツパッケージとの間で変化しないプッシュクライアント510に対するメタデータは、パスされる必要はない。こうして、このメタデータの抽出を要求しないので、プッシュクライアント510での処理時間を節約でき、無線ネットワーク130を介してパスされるプッシュクライアント510に対するメタデータを要求しないので、ネットワークリソースをさらに節約できる。据え置き検索マネージャ552は、受信されるコンテンツの断片を解析し、コンテンツを正しい方法で一緒に置くために使用される。以下により詳細に記載されるように、データは、線形、あるいは非線形のいずれかであり得る。データが非線形の場合、データを再構築するために、メタデータが必要とされ、これは、据え置き検索マネージャ552によって行われる。据え置き検索マネージャ552は、また、プッシュプロキシ510の据え置き検索ストア452で利用可能な情報のダイジェストを解析するようにも適合され、ユーザによって要求されたとき、コンテンツプルブローカ554以下に記載を駆動して、この情報を検索する。これは、コンテンツナビゲーションが、コンテンツ構造グラフの所定のブランチに入るとき、あるいは帯域幅またはコスト条件が満足されるとき、予測検索を含む。コンテンツプルブローカ554は、プッシュクライアント510がある状況の中で、コンテンツをプルすることができるプッシュ/プルモデルで使用される。このような状況は、図19を参照して、以下に、より詳細に記載される。当業者には理解されるように、コンテンツメタデータ抽出器キャッシュ550、据え置き検索マネージャ552、およびコンテンツプルブローカ554は、メッセージ伝達コンテンツとメタデータとの双方を扱う。加入管理ブロック560は、図4の加入ルールブロック460と同じである。特に、加入管理ブロック560は、加入を管理するために使用される。アプリケーションが、モバイルデバイスから登録解除する場合、あるいは削除される場合、加入管理ブロック560は、加入を終了する。加入管理ブロック560は、また、加入チャネルが満了するとき、クライアントアプリケーションの代理として、再加入し得る。更新通知ブロック562は、クライアントアプリケーションと協働し、新たなコンテンツがクライアントアプリケーションを待っていることをアプリケーションに通知するために使用される。これは、以下の3つの方法のうちの1つで行われる。a.更新通知ブロック562が、アプリケーション512に通知し得る第一の方法は、プッシュクライアント510が、コンテンツをアプリケーション512に直接送信する方法である。b.更新通知ブロック562が、新たなコンテンツのアプリケーション512に通知し得る第二の方法は、コンテンツストレージ580内にコンテンツを格納し、コンテンツが待っていることを随意にアプリケーション512に通知する方法である。この場合の通知は、随意である。具体的には、アプリケーション512は、自身に向けられた情報が特定のメモリブロック内に格納されていることを知っている場合、そのアプリケーションにとって、それが新たなデータを有することを発見するための一つの選択肢は、メモリロケーションを定期的にポーリングし、そのメモリロケーションに何か書かれていないかを調べることである。代替として、更新通知ブロック562は、自身が新たなデータを有することと、おそらくは、データが格納されているロケーションとを指示するメッセージをアプリケーション512に送信し得る。c.更新通知562が、新たなコンテンツのアプリケーション512に通知し得る第三の方法は、コンテンツを内部に格納し、アプリケーションに通知する方法である。このアプリケーションは、次いで、プッシュクライアントに呼びかけて、そのコンテンツを検索し得る。コンテンツ依存ブロック564は、図4のコンテンツ依存ブロック462と同じであり、モバイルデバイスにサービスを広告するかどうかを決定し得る。コンテンツ満了置換ブロック566は、図4のコンテンツ置換満了ブロック466と同じである。コンテンツの満了およびコンテンツの置換は、このように、プッシュサーバまたはプッシュプロキシに加えて、プッシュクライアント510でハンドリングされ得る。チャネルメタデータレポジトリ570は、アプリケーション512に対するチャネルメタデータを格納するために使用される。バックグラウンド更新処理モジュール575は、アプリケーション512が利用可能でないとき、更新を実行するために使用される。バックグラウンド更新によって、例えば、アプリケーションストレージ内部のデータをより新しいデータと置換することが可能になる。その後、ユーザが、アプリケーションを開始する際、アプリケーションによって表示されるデータは、補正され、更新される。バックグラウンド更新処理モジュール575は、処理ルールを用いて、コンテンツをアプリケーションに対して許容可能なフォーマットに翻訳する。このモジュールは、コンテンツストア580内のコンテンツを実行し、処理し得る。一例として、夜間契約者contractorovernightに対して更新されるタスクリストは、それにプッシュされたタスクを有し得る。タスクアプリケーションは、この間、開始されず、バックグラウンド更新処理モジュール575は、タスクアプリケーション用のコンテンツを更新するために使用され得る。これは、拡張マークアップ言語XMLファイルをハンドリングするためのコードで行われ得、handler.exeと称されるファイルで、デバイス上に存在し得る。プッシュクライアント510上のバックグラウンド更新処理ブロック575は、handler.exeをランさせ得、パラメータを有するXMLドキュメントをパスさせる。次いで、ハンドラは、タスクをアプリケーションの内部フォーマットに構築する。一度、プッシュクライアント510のバックグラウンド更新処理ブロック575が、アプリケーション内部フォーマットにタスクを構築すると、このブロックは、そのタスクをコンテンツストレージ580からのタスクリストの中に読み込み得、その新しいタスクをリストに添付し得る。次いで、そのブロックは、タスクアプリケーションが、次にプッシュクライアント510に接続するときに備えて、改変されたバックをコンテンツストレージ580に格納し得る。図5は、それゆえ、ジェネリック動的コンテンツ配信システムにおいて使用され得るプッシュクライアント510を示す。ここで、コンテンツと、そのコンテンツの処理とは、動的であり、事前に決定されていない。図5のプッシュクライアント510を参照して上述されたブロックは、システムの動的な性質に適合するように使用される。図3を参照して示されたように、コンテンツは、メタデータと関連し、コンテンツの処理に対する知能を提供する。本方法およびシステムに従うと、メタデータは、2つのタイプのメタデータに分けられ得る。具体的には、静的チャネルメタデータおよび動的コンテンツメタデータである。コンテンツプロバイダおよびアプリケーションのタイプには無限の可能性があるので、ジェネリックシステムを構築するためには、メタデータは、クリティカルである。特定のタイプのコンテンツをハンドリングする唯一の方法は、メタデータを介してである。静的メタデータは、特定タイプのコンテンツをいかに処理するかのルールを提供するメタデータである。静的メタデータは、様々な抽象化レベルに分解され得、例えば、コンテンツ自体に関する構造情報を含む。例えば、Real-timeSimpleSyndicationRSSドキュメントは、RSS2.0.XSD構造で配信され得、そのコンテンツプロバイダからの全てのコンテンツは、この構造で配信される。静的メタデータの更なる抽象化レベルは、コンテンツサブタイプに対する処理ルールの提供を含む。これは、アプリケーション特有であり得る。したがって、例えば、金融ニュースのアプリケーションは、所定のロケーションに格納された金融ニュースRSSストリームからデータが抽出されるべきことと、そのアプリケーションが情報の着信に関して通知されるべきこととを指示する。アプリケーションは、自身に向けられる予定のコンテンツを、この方法で、常にハンドリングするように要求する。静的メタデータ本明細書では、チャネルメタデータとも称されるは、アプリケーションとコンテンツプロバイダとの間での加入の間、ずっと同じ状態のまま留まる。したがって、静的メタデータは、アーキテクチャ内の各エレメントに対して、また、各コンテンツ配信チャネルに対して、一回確立され得る。一つの実施形態において、これは、アプリケーションまたはコンテンツプロバイダの登録時に行われる。動的メタデータは、コンテンツの特定のピースと関連するメタデータである。例えば、データの特定のピースと関連する満了情報、あるいはデータの特定のピースと関連する置換ルールおよび情報であるすなわち。ドキュメントKがドキュメントLと置換する。以上に、図4および図5を参照して示したように、各処理エンティティは、その処理エンティティに向けられる静的メタデータと動的メタデータとの双方を受信し得る。したがって、プッシュプロキシ410は、コンテンツメタデータ抽出器キャッシュ450を用いて、動的メタデータを抽出し、コンテンツ満了置換モジュラー466は、配信されなかったコンテンツをプッシュプロキシ410で受信された新たなコンテンツと置換するために用いられる。ここで、図6を参照する。図6は、コンテンツメタデータに対する多層エンベロープモデルを示す。プッシュプロキシ410は、プロキシサーバ612およびプッシュクライアントエンベロープ614に対するコンテンツ処理メタデータを含むプッシュエンベロープ610を受信する。プッシュプロキシ410は、コンテンツ処理メタデータ612を抽出し、このメタデータを用いて、プッシュクライアントエンベロープ614を処理する。メタデータ612は、プッシュクライアントエンベロープ614で何を行うかをプッシュプロキシに命令するdictate。プッシュクライアントエンベロープ614は、コンテンツクライアント510にパスされ、そこで、コンテンツエンベロープ620と、コンテンツ処理メタデータ622とに分解される。コンテンツ処理メタデータ622は、コンテンツエンベロープ620を処理するために、プッシュクライアント510によって使用される。例えば、これは、クライアントアプリケーション150が、コンテンツの最新バージョンのみに関心ある場合、プッシュクライアント510に命令して、以前に配信されたコンテンツエンベロープ620を最新のエンベロープに置換を実行するために使用され得る。コンテンツエンベロープ620は、クライアントアプリケーション150にパスされる。コンテンツエンベロープ620は、アプリケーションに対するコンテンツ処理メタデータ630、およびクライアントアプリケーション150によって消費されることになるコンテンツペイロード632を含む。当業者には理解されるように、図6に従うエンベロープのネスティングは、処理がアーキテクチャの任意の処理エレメントで起こり得て、どのように特定のコンテンツが処理されるべきかをコンテンツプロバイダ110が特定し得るリッチな動的環境を備える。一つの実施形態において、特定のロジカルエレメントに向けられたメタデータは、他の処理エレメントに不透明opaqueである。代替として、サービスプロバイダ120は、またプッシュプロキシ410で、プッシュクライアント510またはクライアントアプリケーション150を処理するために、メタデータを追加し得る。図7を参照すると、この図は、図6のエンベロープモデルと、各処理エレメントがエンベロープとともに行うステップとを示す。図7に示されるように、プッシュプロキシ410は、まずプッシュエンベロープ610からメタデータを抽出する。これは、ステップ710で行われる。ステップ712で、プッシュプロキシ410は、メタデータを用いて、プッシュクライアントエンベロープ614を処理する。ステップ714で、プッシュプロキシ410は、プッシュクライアントエンベロープ614をプッシュクライアント510に配信する。同様に、プッシュクライアント510は、ステップ720で、コンテンツ処理メタデータ622をプッシュクライアントエンベロープ614から抽出する。ステップ722で、プッシュクライアント510は、コンテンツ処理メタデータ622をコンテンツエンベロープ620上で用いる。ステップ724で、プッシュクライアント510は、コンテンツエンベロープ620をクライアントアプリケーション150に配信する。ステップ730で、クライアントアプリケーション150は、コンテンツ処理メタデータ630を抽出し、ステップ732で、コンテンツ処理メタデータ630をコンテンツペイロード632上で用いる。図8を参照すると、この図は、図7に示された方法に、静的メタデータまたはチャネルメタデータを用いる追加のステップとともに示す。具体的には、ステップ710で、メタデータがプッシュエンベロープ610から抽出された後、プッシュプロキシ410は、次いで、静的チャネルメタデータを用いて、ステップ810で、プッシュクライアントエンベロープを処理する。ステップ712で、プッシュプロキシ410は、次いで、コンテンツ処理動的メタデータ612を処理する。プッシュプロキシ410は、次いで、ステップ714で、プッシュクライアントエンベロープ614を配信する。同様に、プッシュクライアント510は、ステップ720で、コンテンツ処理メタデータ622を抽出する。プッシュクライアント510は、次いで、ステップ820で、チャネルメタデータを、コンテンツエンベロープ620内のコンテンツ上で用いる。プッシュクライアント510は、次いで、ステップ722で、動的コンテンツメタデータをコンテンツ処理メタデータ622内で使用する。その後、ステップ724で、クライアントアプリケーション150にコンテンツエンベロープ620を配信する。ステップ730で、クライアントアプリケーション150は、最初に、コンテンツ処理メタデータ630を抽出する。クライアントアプリケーション150は、次いで、ステップ830で、コンテンツペイロード632上でチャネルメタデータを用いる。クライアントアプリケーション150は、次いで、ステップ732で、コンテンツ処理メタデータ630をコンテンツペイロード632上で用いる。当業者には理解されるように、上記のモデルによって、それゆえ、チャネルに対して適用される静的メタデータと、その特定のコンテンツと関連する動的メタデータと一緒に、その双方が送信されることを可能にする。ここで、図9を参照する。図5から理解されるように、プッシュクライアント510は、モバイルデバイス上の複数のターゲットアプリケーション512をサービスし得る。アプリケーションが、他のアプリケーションに対するサービスを中断することなく、動的コンテンツ配信フレームワークに登録し得る効率的なランタイム登録メカニズムが、要求される。図9を参照すると、プッシュクライアント510は、3つのアプリケーションを含み、具体的には、アプリケーション910、912および914は、既にプッシュクライアントに登録されている。理解されるように、プラグインモデルは、重要である。なぜなら、新しいデバイスは、制限のないアプリケーションタイプが、そのデバイス上にインストールされることを可能にし得るからである。さらに、アプリケーションは、動的にインストールされ、モバイルデバイスがアプリケーションプラットホームになるように導き得る。なぜなら、デバイスは、アプリケーションプラットホームであり得、デバイスは、新たなアプリケーションを動的に組み込むことが可能であるはずだからである。プッシュプロキシ410は、プッシュプロキシサービスを統治するためのサービス統治ブロック430をさらに含む。プッシュプロキシ410は、コンテンツと、そのコンテンツに関連するメタデータとの双方を取り扱う様々なモジュールを含む。第一のモジュールは、メッセージブローカ配信キュー440であり、これは、コンテンツプロバイダ412からのメッセージを消費するサブシステムであり、コンテンツ配信キューを管理する。当業者には理解されるように、コンテンツを順当に配信するために、全てのクライアントアプリケーションに対する全てのコンテンツは、一度に配信され得ないし、配信キューが、確立される必要がある。例えば、デバイスは、カバー範囲外であり得るし、またコンテンツは、格納されるべき必要があり得る。プッシュプロキシ410は、フロー制御管理ブロック442をさらに含む。フロー制御管理ブロック442によって、コンテンツのフローを制御できる。例えば、限られた空間内のモバイル局は、所定の量の情報を受信できるだけであり得る。この場合、モバイルデバイスは、図1に示されるようなプッシュクライアント140を介して、プッシュプロキシ410に、プッシュクライアント140へのデータのフローを停止するように求め得る。このフロー制御管理ブロック442は、これに対処する。代替として、モバイルデバイスは、オフラインであり得る。フロー制御管理ブロック442は、停止して、コンテンツがプッシュプロキシ410によって受信されたままの状態で配信され得ないとき、プッシュクライアント140へのデータのフローを開始する。プッシュプロキシ410の更なるコンポーネントは、プッシュエージェント444である。プッシュエージェント444は、クライアントにデータを送信する役割を担う。当業者には理解されるように、ブロック440、442および444は、メッセージ伝達のみを扱い、メタデータ関連ではない。言い換えれば、これらのブロックは、メッセージのコンテンツをハンドリングするが、コンテンツと関連するメタデータは一切取り扱わない。プッシュプロキシ410の更なるコンポーネントは、コンテンツメタデータ抽出器キャッシュブロック450である。コンテンツメタデータ抽出器キャッシュブロック450は、エンベロープされたコンテンツメタデータ上で動作する。具体的には、以下に、より詳細に記載されるメタデータシステムのエンベロープモデルにおいて、システム内の各ロジカルコンポーネントは、コンテンツ処理と関連するメタデータを有し得る。このメタデータによって、ロジカルコンポーネントは、コンテンツにアクションを実行することができる。このように、各ロジカルコンポーネントは、自身と関連するメタデータを抽出できる必要がある。コンテンツメタデータ抽出器キャッシュブロック450は、プッシュプロキシ410と関連するメタデータを抽出し、このメタデータをキャッシュ化する役割を担う。キャッシュ化機能によって、同じコンテンツプロバイダからの引き続きくるコンテンツエンベロープ内の同一のメタデータをパスする必要がなくなるので、最適化できる。メタデータの抽出およびキャッシュ化は、以下に記載される。据え置き検索メッセージストアブロック452は、コンテンツまたはそのコンテンツの一部をクライアントアプリケーションに配信することが効率的でないときに、使用される。据え置き検索メッセージストアブロック452は、クライアントに配信されないコンテンツを、そのコンテンツを送信するのが効率的になるまで、あるいは、そのコンテンツがクライアントによってプルされるまで、格納するために使用され得る。据え置き検索メッセージストアは、また、補助コンテンツをキャッシュ化するためにも使用され得る。この補助コンテンツは、既に配信されたコンテンツを介するクライアントアプリケーションナビゲーションに依存するクライアントに随意に送信され得るか、あるいは、そのクライアントによって随意にプルされ得る。据え置き検索メッセージストアブロック452の目的は、図19および図21を参照して、以下に、より良く説明される。一例として、据え置き検索メッセージストアブロック452は、ユーザが、ユーザのロケーションの近くにあるレストランなどのロケーション情報をリクエストした場合に使用され得る。コンテンツプロバイダまたはサービスプロバイダは、情報を提供するモデルを有し得る。このとき、広告主は、お金を払って、自分たちの情報をサーチリクエストに追加し得る。したがって、あるロケーションに対するレストラン情報をリクエストしているユーザは、自分がリクエストしている自分のロケーションの近くに、商店、ゴルフコース、体育館または他のサービスに関する情報もまた、有し得る。コンテンツプロバイダは、リクエストされたレストラン情報に追加情報を束ねて、これらの情報をプッシュプロキシ410にパスする。プッシュプロキシ410は、提供されたメタデータに基づいて、コンテンツパッケージを生成し、クライアントに送信する。コンテンツパッケージには、クライアントによってリクエストされた情報、およびユーザが関心を有し得る関連情報のダイジェストまたは概要が含まれ得る。概要は、ユーザに送信されるが、据え置き検索メッセージストアブロック452は、コンテンツプロバイダ110から受信された実際のデータを格納する。こうして、将来、ユーザが、そのダイジェスト内にある情報に関するより詳細な情報を取得したいと思った場合、この情報は、プッシュプロキシ410に既に格納されている。据え置き検索メッセージストアブロック452に対する代替的な使用は、ユーザが一度にコンテンツ全体を受け入れ得ない場合である。例えば、デバイスにコンテンツ全部を送信することが、実現可能でない場合、あるいは経済的でない場合、コンテンツの一部は、後の時間まで、つまり、クライアントによってプルされ得るときまで、あるいは所定のルールが合致して、プッシュされ得るときまで、格納され得る。これらのルールは、満足される所定のネットワークまたはサービス条件により、ネットワークまたはサービス条件によって特定され得る。これについては、以下に、図19を参照して、より詳細に記載される。プッシュスケジューラ454は、クライアントに対する配信スロットをスケジューリングする。前述のように、一部の状況において、一度にコンテンツの全部をプッシュすることは効率的でないことがあり得る。プッシュスケジューラ454は、一部の情報を即座にプッシュして、その残りを所定のスケジュールに従ってプッシュすることを決定し得る。また、プッシュスケジューラ454は、コンテンツの性質を用い、そのコンテンツがプッシュされるべきときを決定し得る。具体的には、一部のコンテンツが高い優先度を有すること、あるいは時間的に限られた満了期限を有することをメタデータが示し得ると、このコンテンツは、即座にプッシュされ得る。それに対し、低い優先度を有するか、あるいは満了期限を有しないことを示されたコンテンツは、後に、データをパスする条件が、より好ましくなるときに、プッシュされ得る。当業者には理解されるように、ブロック450、452および454は、メッセージのコンテンツと、このメッセージと関連するメタデータとの双方を扱う。加入ルールブロック460は、サービスを受信するために登録されるアプリケーションを追跡し、配信されている特定のコンテンツをどのようにハンドリングするかのルールをモニタする。コンテンツは、典型的には、クライアントによる加入またはクライアントの代理としての加入に基づいて配信される。例えば、特定のサービスをユーザが欲する場合、そのユーザは、積極的に加入をリクエストし得る。加入は、ユーザの代理としてなされ得る。例えば、ユーザが、サービスの恩恵を受けるために、サービスプロバイダ120と契約にサインをした場合である。これは、ユーザが、所定の数の広告を毎日受信することに同意しさえすれば、ユーザが優遇料金で受信する場合を含み得る。この場合、サービスプロバイダ120が、クライアントの代理として、広告プロバイダに加入し得る。アプリケーションがモバイルデバイス上で消去されるとき、あるいはアプリケーションが加入を登録解除するとき、加入ルールブロック460は、そのユーザを加入中止にし得る。コンテンツ依存ブロック462は、プッシュプロキシ410によって使用され、モバイルデバイスのユーザが利用し得るサービスを広告する。したがって、モバイルデバイスのユーザが、サービスに対する十分な画面または帯域幅あるいはメモリを有しない場合、コンテンツ依存ブロック462は、そのサービスの広告をそのユーザに対して阻止し得る。コンテンツ断片化ブロック464は、コンテンツを断片化するために使用される。これが用いられ得るのは、例えば、モバイルデバイスが、一度にコンテンツの全てを受信できない場合である。コンテンツ断片化ブロック464は、コンテンツを様々なコンポーネントに分解するために使用される。これは、まだ配信されていない断片化コンテンツを格納するために、据え置き検索メッセージストア452と連携して使用され得る。コンテンツ満了置換ブロック466は、2つの目的で使用される。第一に、このブロックは、加入をモニタするために使用され得る。各加入には、満了時があり、この満了時に達したときに、加入は終了し得る。また、コンテンツ満了置換ブロック466は、情報をモニタするためにも使用され得る。ある種のコンテンツには、その情報の有効期限がある。例えば、ラッシュ時の交通をモニタするために使用される交通アプリケーションは、非常に時間依存性がある。何らかの理由で、プッシュプロキシ410が、モバイルデバイスにコンテンツを即座に配信できない場合、このコンテンツは、将来の配信のために、コンテンツストレージ480の中に格納される。しかしながら、コンテンツが所定の特定期間内に配信されない場合、このコンテンツは満了し得、全く配信され得ない。同様に、コンテンツ置換は、情報が更新される状況で扱われる。例えば、株価を受信するクライアントアプリケーションは、最新の株価を欲するのみであり得る。したがって、プッシュプロキシ410は、株価をプッシュクライアント140に配信できず、引き続く株価がコンテンツプロバイダ110から受信される場合、引き続く株価の中にあるメタデータが、以前の株価に置換されて使用されるべきであることを指示し得る。格納された情報の置換は、配信キューに全ての情報を加えるより、コンテンツストレージ480内の空間を開放する。チャネルメタデータレポジトリ470はチャネルメタデータを格納するために使用される。これについては、以下に、より詳細に記載される。以上は、本明細書における方法およびシステムで使用され得る例示的なプッシュプロキシ410を説明するものである。プッシュプロキシ410のブロックおよびエレメントによって、このプッシュプロキシ410が、ジェネリック動的コンテンツ配信システムで使用されることを可能にする。ここで、コンテンツのタイプおよびアプリケーションでのそのコンテンツのハンドリングは、変動し得、事前に決定されない。ここで、図5を参照する。図5は、本明細書のシステムおよび方法と関連して使用され得るプッシュクライアント510を示す。プッシュクライアント510は、図1および図2のプッシュクライアント140と同じであり得る。当業者には理解されるように、コンテンツおよびそのコンテンツ処理が事前に決定されていないジェネリックシステムで用いられることになるプッシュクライアント510は、コンテンツと、そのコンテンツと関連するメタデータとの双方に適合して使用され得るブロックまたはモジュールを含むべきである。図5に関して規定されるブロックは、網羅的であることを意図するものではなく、プッシュクライアント510内に他のブロックもまた存在し得る。さらに、プッシュクライアント510内のブロックは、一部の例において、プッシュクライアント510内の他のブロックの機能性を制約することなく、省かれ得る。プッシュクライアント510は、アプリケーションをサービスし、1つ以上のアプリケーション512は、プッシュクライアント510に登録され得る。アプリケーション登録は、登録用のインターフェースとして、アプリケーションプロバイダインターフェース514を使用し、アプリケーションプロバイダインターフェース514は、以下により詳細に記載されるように、アプリケーション用のチャネルメタデータを抽出するために、さらに使用され得る。プッシュクライアント510は、プッシュクライアント510を統治するために使用されるクライアント統治520を含む。図4のプッシュサーバ410と同様に、プッシュクライアント510は、メッセージ伝達を扱う様々なブロック、メタデータを扱う様々なブロック、およびメッセージ伝達とメタデータとの双方を扱う様々なブロックを含む。メッセージブローカアプリケーションキュー540は、配信用プッシュプロキシ410からアプリケーション512へのメッセージをハンドリングする。アプリケーションキューは、アプリケーション512に対するメッセージのキューである。フロー制御管理ブロック542は、図4のプッシュプロキシ410に、コンテンツのプッシュ停止またはコンテンツのプッシュ再開を通知するために使用される。これが使用され得るのは、例えば、プッシュクライアント510が、プッシュされたコンテンツを受け入れ得るメモリ量が限られているときである。この場合、プッシュコンテンツが消費される前に、プッシュクライアント510は、プッシュプロキシ410からのコンテンツのフローを停止する必要がある。一度、コンテンツが消費されると、フロー制御管理ブロック542は、再び、データのフローを開始するために使用され得る。プッシュクライアント510内のプッシュエージェント544は、図4のプッシュプロキシ410から情報を受信するために使用される。当業者には理解されるように、メッセージブローカアプリケーションキュー540、フロー制御管理ブロック542、およびプッシュエージェント544は、メッセージ伝達を独占的に扱い、メタデータを扱わない。コンテンツメタデータ抽出器キャッシュブロック550は、プッシュクライアント510に向かうことになっている動的メタデータを抽出するために使用される。図4のプッシュプロキシ410を参照して、以前に述べたように、動的コンテンツ配信アーキテクチャ内の処理エレメントはいずれも、これらの処理エレメントに向かう予定のメタデータを有し得、このメタデータは抽出される必要がある。このように、プッシュクライアント510に向かう予定のメタデータは、コンテンツメタデータ抽出器キャッシュブロック550によって抽出される。さらに、コンテンツメタデータ抽出器キャッシュブロック550は、キャッシュメタデータに適合されることが好ましい。第一のコンテンツパッケージと第二のコンテンツパッケージとの間で変化しないプッシュクライアント510に対するメタデータは、パスされる必要はない。こうして、このメタデータの抽出を要求しないので、プッシュクライアント510での処理時間を節約でき、無線ネットワーク130を介してパスされるプッシュクライアント510に対するメタデータを要求しないので、ネットワークリソースをさらに節約できる。据え置き検索マネージャ552は、受信されるコンテンツの断片を解析し、コンテンツを正しい方法で一緒に置くために使用される。以下により詳細に記載されるように、データは、線形、あるいは非線形のいずれかであり得る。データが非線形の場合、データを再構築するために、メタデータが必要とされ、これは、据え置き検索マネージャ552によって行われる。据え置き検索マネージャ552は、また、プッシュプロキシ510の据え置き検索ストア452で利用可能な情報のダイジェストを解析するようにも適合され、ユーザによって要求されたとき、コンテンツプルブローカ554以下に記載を駆動して、この情報を検索する。これは、コンテンツナビゲーションが、コンテンツ構造グラフの所定のブランチに入るとき、あるいは帯域幅またはコスト条件が満足されるとき、予測検索を含む。コンテンツプルブローカ554は、プッシュクライアント510がある状況の中で、コンテンツをプルすることができるプッシュ/プルモデルで使用される。このような状況は、図19を参照して、以下に、より詳細に記載される。当業者には理解されるように、コンテンツメタデータ抽出器キャッシュ550、据え置き検索マネージャ552、およびコンテンツプルブローカ554は、メッセージ伝達コンテンツとメタデータとの双方を扱う。加入管理ブロック560は、図4の加入ルールブロック460と同じである。特に、加入管理ブロック560は、加入を管理するために使用される。アプリケーションが、モバイルデバイスから登録解除する場合、あるいは削除される場合、加入管理ブロック560は、加入を終了する。加入管理ブロック560は、また、加入チャネルが満了するとき、クライアントアプリケーションの代理として、再加入し得る。更新通知ブロック562は、クライアントアプリケーションと協働し、新たなコンテンツがクライアントアプリケーションを待っていることをアプリケーションに通知するために使用される。これは、以下の3つの方法のうちの1つで行われる。a.更新通知ブロック562が、アプリケーション512に通知し得る第一の方法は、プッシュクライアント510が、コンテンツをアプリケーション512に直接送信する方法である。b.更新通知ブロック562が、新たなコンテンツのアプリケーション512に通知し得る第二の方法は、コンテンツストレージ580内にコンテンツを格納し、コンテンツが待っていることを随意にアプリケーション512に通知する方法である。この場合の通知は、随意である。具体的には、アプリケーション512は、自身に向けられた情報が特定のメモリブロック内に格納されていることを知っている場合、そのアプリケーションにとって、それが新たなデータを有することを発見するための一つの選択肢は、メモリロケーションを定期的にポーリングし、そのメモリロケーションに何か書かれていないかを調べることである。代替として、更新通知ブロック562は、自身が新たなデータを有することと、おそらくは、データが格納されているロケーションとを指示するメッセージをアプリケーション512に送信し得る。c.更新通知562が、新たなコンテンツのアプリケーション512に通知し得る第三の方法は、コンテンツを内部に格納し、アプリケーションに通知する方法である。このアプリケーションは、次いで、プッシュクライアントに呼びかけて、そのコンテンツを検索し得る。コンテンツ依存ブロック564は、図4のコンテンツ依存ブロック462と同じであり、モバイルデバイスにサービスを広告するかどうかを決定し得る。コンテンツ満了置換ブロック566は、図4のコンテンツ置換満了ブロック466と同じである。コンテンツの満了およびコンテンツの置換は、このように、プッシュサーバまたはプッシュプロキシに加えて、プッシュクライアント510でハンドリングされ得る。チャネルメタデータレポジトリ570は、アプリケーション512に対するチャネルメタデータを格納するために使用される。バックグラウンド更新処理モジュール575は、アプリケーション512が利用可能でないとき、更新を実行するために使用される。バックグラウンド更新によって、例えば、アプリケーションストレージ内部のデータをより新しいデータと置換することが可能になる。その後、ユーザが、アプリケーションを開始する際、アプリケーションによって表示されるデータは、補正され、更新される。バックグラウンド更新処理モジュール575は、処理ルールを用いて、コンテンツをアプリケーションに対して許容可能なフォーマットに翻訳する。このモジュールは、コンテンツストア580内のコンテンツを実行し、処理し得る。一例として、夜間契約者に対して更新されるタスクリストは、それにプッシュされたタスクを有し得る。タスクアプリケーションは、この間、開始されず、バックグラウンド更新処理モジュール575は、タスクアプリケーション用のコンテンツを更新するために使用され得る。これは、拡張マークアップ言語XMLファイルをハンドリングするためのコードで行われ得、handler.exeと称されるファイルで、デバイス上に存在し得る。プッシュクライアント510上のバックグラウンド更新処理ブロック575は、handler.exeをランさせ得、パラメータを有するXMLドキュメントをパスさせる。次いで、ハンドラは、タスクをアプリケーションの内部フォーマットに構築する。一度、プッシュクライアント510のバックグラウンド更新処理ブロック575が、アプリケーション内部フォーマットにタスクを構築すると、このブロックは、そのタスクをコンテンツストレージ580からのタスクリストの中に読み込み得、その新しいタスクをリストに添付し得る。次いで、そのブロックは、タスクアプリケーションが、次にプッシュクライアント510に接続するときに備えて、改変されたバックをコンテンツストレージ580に格納し得る。図5は、それゆえ、ジェネリック動的コンテンツ配信システムにおいて使用され得るプッシュクライアント510を示す。ここで、コンテンツと、そのコンテンツの処理とは、動的であり、事前に決定されていない。図5のプッシュクライアント510を参照して上述されたブロックは、システムの動的な性質に適合するように使用される。図3を参照して示されたように、コンテンツは、メタデータと関連し、コンテンツの処理に対する知能を提供する。本方法およびシステムに従うと、メタデータは、2つのタイプのメタデータに分けられ得る。具体的には、静的チャネルメタデータおよび動的コンテンツメタデータである。コンテンツプロバイダおよびアプリケーションのタイプには無限の可能性があるので、ジェネリックシステムを構築するためには、メタデータは、クリティカルである。特定のタイプのコンテンツをハンドリングする唯一の方法は、メタデータを介してである。静的メタデータは、特定タイプのコンテンツをいかに処理するかのルールを提供するメタデータである。静的メタデータは、様々な抽象化レベルに分解され得、例えば、コンテンツ自体に関する構造情報を含む。例えば、Real-timeSimpleSyndicationRSSドキュメントは、RSS2.0.XSD構造で配信され得、そのコンテンツプロバイダからの全てのコンテンツは、この構造で配信される。静的メタデータの更なる抽象化レベルは、コンテンツサブタイプに対する処理ルールの提供を含む。これは、アプリケーション特有であり得る。したがって、例えば、金融ニュースのアプリケーションは、所定のロケーションに格納された金融ニュースRSSストリームからデータが抽出されるべきことと、そのアプリケーションが情報の着信に関して通知されるべきこととを指示する。アプリケーションは、自身に向けられる予定のコンテンツを、この方法で、常にハンドリングするように要求する。静的メタデータ本明細書では、チャネルメタデータとも称されるは、アプリケーションとコンテンツプロバイダとの間での加入の間、ずっと同じ状態のまま留まる。したがって、静的メタデータは、アーキテクチャ内の各エレメントに対して、また、各コンテンツ配信チャネルに対して、一回確立され得る。一つの実施形態において、これは、アプリケーションまたはコンテンツプロバイダの登録時に行われる。動的メタデータは、コンテンツの特定のピースと関連するメタデータである。例えば、データの特定のピースと関連する満了情報、あるいはデータの特定のピースと関連する置換ルールおよび情報であるすなわち。ドキュメントKがドキュメントLと置換する。以上に、図4および図5を参照して示したように、各処理エンティティは、その処理エンティティに向けられる静的メタデータと動的メタデータとの双方を受信し得る。したがって、プッシュプロキシ410は、コンテンツメタデータ抽出器キャッシュ450を用いて、動的メタデータを抽出し、コンテンツ満了置換モジュラー466は、配信されなかったコンテンツをプッシュプロキシ410で受信された新たなコンテンツと置換するために用いられる。ここで、図6を参照する。図6は、コンテンツメタデータに対する多層エンベロープモデルを示す。プッシュプロキシ410は、プロキシサーバ612およびプッシュクライアントエンベロープ614に対するコンテンツ処理メタデータを含むプッシュエンベロープ610を受信する。プッシュプロキシ410は、コンテンツ処理メタデータ612を抽出し、このメタデータを用いて、プッシュクライアントエンベロープ614を処理する。メタデータ612は、プッシュクライアントエンベロープ614で何を行うかをプッシュプロキシに命令する。プッシュクライアントエンベロープ614は、コンテンツクライアント510にパスされ、そこで、コンテンツエンベロープ620と、コンテンツ処理メタデータ622とに分解される。コンテンツ処理メタデータ622は、コンテンツエンベロープ620を処理するために、プッシュクライアント510によって使用される。例えば、これは、クライアントアプリケーション150が、コンテンツの最新バージョンのみに関心ある場合、プッシュクライアント510に命令して、以前に配信されたコンテンツエンベロープ620を最新のエンベロープに置換を実行するために使用され得る。コンテンツエンベロープ620は、クライアントアプリケーション150にパスされる。コンテンツエンベロープ620は、アプリケーションに対するコンテンツ処理メタデータ630、およびクライアントアプリケーション150によって消費されることになるコンテンツペイロード632を含む。当業者には理解されるように、図6に従うエンベロープのネスティングは、処理がアーキテクチャの任意の処理エレメントで起こり得て、どのように特定のコンテンツが処理されるべきかをコンテンツプロバイダ110が特定し得るリッチな動的環境を備える。一つの実施形態において、特定のロジカルエレメントに向けられたメタデータは、他の処理エレメントに不透明である。代替として、サービスプロバイダ120は、またプッシュプロキシ410で、プッシュクライアント510またはクライアントアプリケーション150を処理するために、メタデータを追加し得る。図7を参照すると、この図は、図6のエンベロープモデルと、各処理エレメントがエンベロープとともに行うステップとを示す。図7に示されるように、プッシュプロキシ410は、まずプッシュエンベロープ610からメタデータを抽出する。これは、ステップ710で行われる。ステップ712で、プッシュプロキシ410は、メタデータを用いて、プッシュクライアントエンベロープ614を処理する。ステップ714で、プッシュプロキシ410は、プッシュクライアントエンベロープ614をプッシュクライアント510に配信する。同様に、プッシュクライアント510は、ステップ720で、コンテンツ処理メタデータ622をプッシュクライアントエンベロープ614から抽出する。ステップ722で、プッシュクライアント510は、コンテンツ処理メタデータ622をコンテンツエンベロープ620上で用いる。ステップ724で、プッシュクライアント510は、コンテンツエンベロープ620をクライアントアプリケーション150に配信する。ステップ730で、クライアントアプリケーション150は、コンテンツ処理メタデータ630を抽出し、ステップ732で、コンテンツ処理メタデータ630をコンテンツペイロード632上で用いる。図8を参照すると、この図は、図7に示された方法に、静的メタデータまたはチャネルメタデータを用いる追加のステップとともに示す。具体的には、ステップ710で、メタデータがプッシュエンベロープ610から抽出された後、プッシュプロキシ410は、次いで、静的チャネルメタデータを用いて、ステップ810で、プッシュクライアントエンベロープを処理する。ステップ712で、プッシュプロキシ410は、次いで、コンテンツ処理動的メタデータ612を処理する。プッシュプロキシ410は、次いで、ステップ714で、プッシュクライアントエンベロープ614を配信する。同様に、プッシュクライアント510は、ステップ720で、コンテンツ処理メタデータ622を抽出する。プッシュクライアント510は、次いで、ステップ820で、チャネルメタデータを、コンテンツエンベロープ620内のコンテンツ上で用いる。プッシュクライアント510は、次いで、ステップ722で、動的コンテンツメタデータをコンテンツ処理メタデータ622内で使用する。その後、ステップ724で、クライアントアプリケーション150にコンテンツエンベロープ620を配信する。ステップ730で、クライアントアプリケーション150は、最初に、コンテンツ処理メタデータ630を抽出する。クライアントアプリケーション150は、次いで、ステップ830で、コンテンツペイロード632上でチャネルメタデータを用いる。クライアントアプリケーション150は、次いで、ステップ732で、コンテンツ処理メタデータ630をコンテンツペイロード632上で用いる。当業者には理解されるように、上記のモデルによって、それゆえ、チャネルに対して適用される静的メタデータと、その特定のコンテンツと関連する動的メタデータと一緒に、その双方が送信されることを可能にする。ここで、図9を参照する。図5から理解されるように、プッシュクライアント510は、モバイルデバイス上の複数のターゲットアプリケーション512をサービスし得る。アプリケーションが、他のアプリケーションに対するサービスを中断することなく、動的コンテンツ配信フレームワークに登録し得る効率的なランタイム登録メカニズムが、要求される。図9を参照すると、プッシュクライアント510は、3つのアプリケーションを含み、具体的には、アプリケーション910、912および914は、既にプッシュクライアントに登録されている。理解されるように、プラグインモデルは、重要である。なぜなら、新しいデバイスは、制限のないアプリケーションタイプが、そのデバイス上にインストールされることを可能にし得るからである。さらに、アプリケーションは、動的にインストールされ、モバイルデバイスがアプリケーションプラットホームになるように導き得る。なぜなら、デバイスは、アプリケーションプラットホームであり得、デバイスは、新たなアプリケーションを動的に組み込むことが可能であるはずだからである。図9に示されるように、アプリケーション916は、プッシュクライアント510に登録したいと欲する。アプリケーション916は、アプリケーションマニフェスト918を含む。好ましい実施形態において、アプリケーションマニフェスト918は、そのアプリケーションに対するチャネルメタデータを提供する。具体的には、アプリケーションマニフェスト918は、情報をプッシュクライアント510に提供し、そして、究極的には、図1のプッシュプロキシ410およびコンテンツプロバイダ110に、そのアプリケーションに対する静的メタデータとともに、提供する。この情報には、どのタイプのコンテンツをこのアプリケーションが期待しているか、どのようにコンテンツが配信されるか、アプリケーションに通知が必要かどうか、あるいは、本システムおよび方法に関する分野の当業者にとって明らかであろう他のチャネル情報が含まれ得るが、これらに限定されない。アプリケーション916は、それゆえ、プッシュクライアント510に登録され、アプリケーションマニフェスト918を提供し、アプリケーション916をサービスするために、コンテンツプロバイダにチャネルを確立する。図10を参照すると、代替のモデルは、図2のアーキテクチャ220に対して記載されたモデルであり得る。具体的には、図10のモデルにおいて、クライアントアプリケーション150は、プッシュクライアント140とペアになっている。クライアントアプリケーション150/プッシュクライアント140のペアのそれぞれは、プッシュコンテナ1010を用いて調整される。アプリケーション1020が、プッシュコンテナ1010に登録したいと願うとき、クライアント140が、プッシュコンテナ1010によって生成されるか、あるいは、クライアント140が既に存在する場合は、プッシュコンテナ1010によって使用される。さらに、登録において、アプリケーション1020は、アプリケーションマニフェスト1030をプッシュコンテナ1010に提供することによって、チャネルメタデータ静的データをアプリケーション1020に提供する。図10の代替の図が、図11に示される。具体的には、プッシュコンテナ1110が、プッシュクライアントのプールを管理/維持する。アプリケーションが、コンテナに登録されるとき、アプリケーションは、専用のプッシュクライアント510を獲得する。単純な場合において、プッシュクライアント510は、ソケットリスナ1130とコンテンツハンドラのペアによって表現され得る。アプリケーションがコンテナおよびコンテンツ配信サービスから登録解除されるとき、あるいはデバイスから削除されるとき、プッシュクライアントは、プールに戻る。プッシュコンテナ1110は、通信用ソケット1120を含む。さらに、プッシュコンテナ1110は、特定のソケットに割り当てられたソケットリスナ1130およびコンテンツプロセッサ1140を含む。図11に示されるように、様々なコンテンツプロセッサおよびソケットリスナのペアが、以前に登録されたアプリケーション150によって使用される。新たなアプリケーション1150は、プッシュコンテナ1110に登録されたいと欲するとき、新たなコンテンツプロセッサ1120およびソケットリスナ1130は、サービスアプリケーション1050に割り当てられる。それゆえ、上記は、ジェネリックプッシュフレームワークに対して提供される。このフレームワークにおいて、新しいクライアントアプリケーション150は、インプリメントされ得、プッシュクライアント510、あるいはプッシュコンテナ1010または1110に登録され得る。これによって、デバイスが、新たなアプリケーションを動的に組み込むことの可能なアプリケーションプラットホームとなることができる。上記の図9および図10のアプリケーションマニフェスト1030または918をパスすることによって、チャネルメタデータの確立が可能になり、これによって、コンテンツが、アプリケーションの要求に従って処理されることが可能になる。図12を参照すると、コンテンツプロバイダ110は、同様に、プッシュプロキシ410に登録される必要がある。図12に示されるように、プッシュプロキシ410は、3つのコンテンツプロバイダ、すなわち、1210、1212および1214を含み、これらは既にプッシュプロキシ410に登録されている。コンテンツプロバイダ1216は、プッシュプロキシ410に登録されたいと願う。図9に示されるアプリケーション916によって提供されたアプリケーションマニフェスト918と同様に、プッシュクライアント510に登録するとき、コンテンツプロバイダ1216は、サービスマニフェスト1218を含み、このサービスマニフェスト1218は、コンテンツプロバイダ1216が登録するとき、プッシュプロキシ410にパスされる。サービスマニフェスト1218は、コンテンツプロバイダが提供する情報のタイプに関する情報、この情報を提供する頻度、情報のフォーマット、およびサービスまたはサービスの広告に有用な任意の他の情報を含む。他の情報も可能である。プッシュプロキシ410は、サービスマニフェスト1218を用いて、コンテンツプロバイダ1216に対するチャネル静的メタデータを確立する。図13を参照すると、図2のアーキテクチャ230によって示される代替の実施形態は、プッシュプロキシ122およびコンテンツプロバイダ110のペアを幾つか備えたプッシュコンテナを有する。図12と同様に、様々なアプリケーションが、プッシュコンテナ1310に既に登録され得、図12の例において、アプリケーション1312、1314および1316は、それぞれプッシュプロキシ1313、1315および1317に既に登録されている。新たなアプリケーション1320は、プッシュコンテナ1310に登録されたいと欲する。したがって、プッシュコンテナ1310は、新たなプロキシ図示せずを生成するか、あるいは、コンテンツプロバイダ1320と関連する既存のプロキシ図示せずを使用する。さらに、コンテンツプロバイダ1320は、サービスマニフェスト1322を提供し、コンテンツプロバイダ1320が提供することになるコンテンツを記述する。これによって、チャネルメタデータの確立が可能になる。当業者には理解されるように、図9および図10の実施形態は、プッシュクライアントに対する2つの選択肢を示し、それは、共有アプリケーションであるか、あるいは、アプリケーションごとに専用プッシュクライアントであるかのいずれかである。当業者は、他の実施形態も可能であることを理解する。同様に、図12および図13に関して、自身に登録された複数のコンテンツプロバイダを有するプッシュプロキシが示されるか、あるいは、各コンテンツプロバイダ対して専用で、プッシュコンテナで具現化されたプッシュプロキシが示される。図14を参照すると、コンテンツプロバイダ110とクライアントアプリケーション150との間のメッセージ伝達が示される。コンテンツプロバイダ110は、プッシュプロキシ410への登録メッセージを提供する。このメッセージには、プッシュプロキシ410にチャネルメタデータを提供するために使用され得るサービスマニフェストを含み得る。これは、ステップ1410で行われる。コンテンツプロバイダ110は、また、あるいは代替として、ステップ1412で示されるように、引き続くメッセージの中でチャネルメタデータを提供し得る。プッシュプロキシ410は、次いで、ステップ1414で、利用可能なサービスのリストサービスカタログに、サービスを追加する。図14の例における随意のステップは、ステップ1416で、プッシュプロキシ410が、プッシュクライアント510に新たな利用可能なサービスを通知するためであり、この通知は、ステップ1418で、クライアントアプリケーション110に伝播され得る。当業者には理解されるように、ステップ1416および1418は随意であり、他の代替には、クライアントアプリケーション150が、新たなサービスを閲覧するために、プッシュプロキシ410から定期的にサービスカタログをプルすることを含む。クライアントアプリケーション150に対するユーザまたはサービスプロバイダが、アプリケーション150がサービスに加入するべきであると決定したとき、クライアントアプリケーション150は、ステップ1420で、加入メッセージを送信する。この加入メッセージは、ステップ1422で、さらにプッシュプロキシ410にパスされる。一度、プッシュプロキシ410が、ステップ1422で加入メッセージを受信すると、2つの選択肢が利用可能である。第一の選択肢は、加入するために、メッセージ1424をコンテンツプロバイダ110に送信し、次いで、ステップ1426に戻って、メタデータを含むメッセージエンベロープを受信する。このメタデータは、デバイスまたはデバイスのタイプに特有であり得る。代替として、プッシュプロキシ410は、ステップ1422で、加入メッセージを受信し得、そして、即座に、コンテンツプロバイダ110によって既に提供され、プッシュプロキシ410上に格納された情報に基づいて、ステップ1430で、プッシュクライアント510に返答する。この返答は、ステップ1532で、クライアントアプリケーション150に伝播される。理解されるように、この返答は、コンテンツプロバイダ110に特有のチャネルメタデータを含み得る。モデル間の違いは、そのアプリケーションに対するデータを誰がカスタム化するかに依存し得る。理解されるように、コンテンツプロバイダ110は、他の処理エレメントと比べて、コンテンツの最良のカスタム化を提供する。しかしながら、また、サービスプロバイダ120も、プッシュプロキシ410を介して、コンテンツのカスタム化も提供し得る。さらに、理解されるように、コンテンツの構造は、アプリケーションが要求するデータに依存し得る。例えば、金融でのアプリケーションにおいて、アプリケーションは、株価と為替レートとの双方を欲し得る。以下のXML:<FIN><quotes><quoteticker=ABC>18.54</quote><quoteticker=XYZ>123.45</quote></quotes><rates><rateid=US-CAN>1.15</rate><rateid=US-EURO>0.85</rate></rates></FIN>が使用され得る。ユーザが、株価のみを欲し、為替レートを欲しない場合、構造は、以下:<FIN><quoteticker=ABC>18.54</quote><quoteticker=XYZ>123.45</quote></FIN>のように変化し得る。メタデータは、アプリケーションに、構造にデータはパスされているという情報を提供し得る。したがって、2つのモデルが存在する。静的メタデータが、登録中に、または登録後のいずれかに、プッシュプロキシ410およびプッシュクライアント510に提供され得る。代替として、プッシュプロキシ410およびプッシュクライアント510に対するメタデータは、事前に用意され得る。すなわち、情報は、アプリケーションがクライアントに登録されるまで、プッシュクライアントまたはプッシュプロキシに格納される。ここで、図15を参照する。図15は、プッシュクライアント510にアプリケーションを登録すると生じるロジカルステップを示す。一度、アプリケーションがプッシュクライアント510に登録されると、第一のステップ1510は、登録されたアプリケーションを、そのアプリケーションによって要求されるコンテンツタイプと合わせることである。これは、図9に示されるように、アプリケーションマニフェスト918から既知である。第二のステップ1520は、アプリケーションに対する環境を設定することである。これらには、アプリケーションに対する格納および配信を随意に含むが、これらに限定されない。例えば、アプリケーションは、送信を所定のデータ量で制限し得る。フロー制御のイベントにおいて、あるいは、アプリケーションまたはクライアントと連絡が取れない場合、プッシュクライアント510は、アプリケーションに対するデータをキャッシュすることを要求し得、そして、随意で、データが待っている旨をアプリケーションに通知することを要求し得る。第三のステップ1530は、プッシュプロキシ410にアプリケーション設定を通知することである。これには、例えば、アプリケーションまたはプッシュクライアント510に利用可能なストレージを含む。理解されるように、プッシュプロキシ410は、プッシュクライアント510が格納し得るより多くのデータをプッシュしてはならない。したがって、アプリケーション設定は、パスされるデータの上限を含み得る。図4および図5を参照すると、これは、コンテンツ断片化ブロック464を呼び出し、アプリケーションが処理し得るよりもコンテンツが大きい場合、コンテンツを断片化し得る。また、データが非線形の場合、コンテンツ依存ブロック462は、図5のコンテンツ依存ブロック564用のメタデータを生成することを要求され得る。これは、コンテンツ依存ブロック564が、データを再構成できるようにするためである。再び、図15を参照すると、ステップ1530は、また、データ配信に対する優先度を指示し得る。例えば、アプリケーションは、あるタイプのデータを他のタイプのデータに対して優先し得、これらのタイプのデータには、優先度が与えられ得る。こうして、ステップ1530は、タイプAのデータが即座に配信されるのに対し、タイプBのデータが据え置き時間に配信され得る配信スケジュールを確立するために使用され得る。ここで、図16を参照する。コンテンツプロバイダ110が、プッシュプロキシ410に登録するとき、様々なステップが実行される。第一のステップ1610は、コンテンツ格納および配信に対して要求されたクライアント設定を解析することを含む。これは、コンテンツプロバイダ110からのコンテンツを消費できるデバイス上のプッシュクライアント510を特定するために、例えば、サービス広告に使用され得る。第二のステップ1620は、プッシュプロキシ410が環境を設定することを可能にし、環境は、とりわけ、プロキシ格納、配信オプション、変換オプションを含む。ステップ1630で、プッシュプロキシ410は、アプリケーションが既に登録され、コンテンツプロバイダ110からコンテンツを獲得したかどうかをチェックし得る。このような場合、アプリケーションは、コンテンツと、プッシュプロキシ410からコンテンツプロバイダ110への通知を受信する準備が整うので、配信チャネルが確立され、アプリケーションは、コンテンツを送信し得る準備が整う。ステップ1630は、例えば、コンテンツプロバイダ110がオンラインに来る前に、アプリケーションがデバイスに事前にインストールされる場合に生じ得る。したがって、アプリケーションは、コンテンツプロバイダ110が利用可能になるのを待っているか、あるいは、アプリケーションは、ジェネリックタイプ例えば、ブラウザまたRSSビューアで、複数のコンテンツプロバイダからの情報を消費できるかである。代替の設定において、コンテンツプロバイダ110が、アプリケーションがインストールされる前に既に利用可能である場合、図15の通知ステップ1530は、コンテンツを開始して、コンテンツプロバイダ110からクライアントアプリケーション150へのフローを開始するために使用され得る。図16を参照して理解されるように、クライアント設定は、所定の情報を含み得る。この情報は、例えば、とりわけ、コンテンツパーティションに対して使用される利用可能なストレージサイズ、フロー制御に対して使用されるキューサイズ、プッシュインターバルを含む配信スケジューリング、クライアントがプロキシから情報を取り出しているかどうか、偽プッシュモードを生成しているか、モバイルデバイスの画面サイズのようなカスタム化オプションである。さらに理解されるように、サービスカタログは、異なるクライアントに対して、異なり得る。例えば、あるクライアントは、より多くのデータを利用可能であり得、異なる画面サイズ、または、他の条件を有し得る。これによって、この情報量をハンドリングし得ない、より小さな画面サイズを有するなどのデバイスに比べ、そのクライアントは、コンテンツプロバイダ110に対し、より適切なものとなる。したがって、プッシュプロキシ410は、特定のクライアントアプリケーションに対するサービスカタログを、これらのクライアントアプリケーションの知識に基づいて生成し得、このクライアントアプリケーション150をインストールされたこれらのデバイスのみが、コンテンツプロバイダに関する情報を受信し得る。さらに理解されるように、一部の場合において、アプリケーションは、ユーザが介入することなく、サービスプロバイダおよびコンテンツプロバイダに基づいてインストールされ得る。例えば、コンテンツプロバイダ110は、プッシュプロキシ410に登録する場合、モバイルデバイスのユーザは、所定のアプリケーションを受け入れる契約義務を有し得る。したがって、プッシュプロキシ410は、アプリケーションをインストールし、アプリケーションをプッシュクライアント510にプッシュする準備ができている旨をプッシュクライアント510に通知し得る。これは、例えば、ユーザが、自分のモバイルプランに優遇料金を得るために、所定量の広告を毎月受信することに同意したことを含み得る。コンテンツプロバイダ110は、広告プロバイダであり得、プッシュプロキシ410は、それゆえ、プッシュクライアント510に広告表示アプリケーションをプッシュし得る。このプッシュクライアント510は、プッシュクライアント410に登録されたアプリケーションインストーラによってサービスされ得、これによって、コンテンツプロバイダ110およびサービスプロバイダ120に、その処理を完全に駆動させる。それゆえ、上記は、プッシュフレームワークにおけるプラグイン登録モデルを提供し、プッシュフレームワークでは、各アプリケーションまたはコンテンツプロバイダが、アプリケーションマニフェストまたはサービスマニフェストをそれぞれ登録し、提供する。アプリケーションマニフェストまたはサービスマニフェストは、登録中に、または登録に引き続き、プッシュプロキシ410およびプッシュクライアント510で、チャネルメタデータを確立するために使用される。その後、アプリケーション150が登録し、コンテンツプロバイダ110が登録するとき、コンテンツは、アプリケーション150とコンテンツプロバイダ110との間を流れ始め得る。図4および図5を参照すると、チャネルメタデータは、メタデータレポジトリ470および570に格納される。しかしながら、動的メタデータが繰り返される場合、アーキテクチャ100内に、様々な処理エレメント上に動的メタデータを格納することは、また有利である。理解されるように、これによって、プッシュプロキシ410上での処理の節約となる。なぜなら、現在のメタデータ抽出器450は、同じメタデータを何度も抽出する必要がなくなるからである。さらに、コンテンツ満了置換モジュール466または566のような様々なモジュールは、パスされるコンテンツの各ピースに対して更新される必要がない。なぜなら、プッシュプロキシ410は、大量のプッシュクライアント510と協働し得るので、各コンテンツメッセージに対するこの処理の節約は、有意義であり得る。さらに、帯域幅は、コンテンツプロバイダ110とプッシュプロキシ410との間の固定ラインを介して、あるいは、プッシュプロキシ410とプッシュクライアント510との間の無線を介して、メタデータをパスする必要がないことによって、節約され得る。ここで、図17を参照する。図17は、自分の最後のメタデータバージョンが処理エレメントによって格納される場合のランタイムフローの例を示す。図17に示されるように、コンテンツプロバイダ110は、コンテンツ[C1Mp,c,a1]を含むコンテンツエンベロープを提供する。これは、第一のコンテンツペイロードが、プロキシメタデータ、クライアントメタデータおよびアプリケーションメタデータを含むメタデータともに送信されることを意味する。これは、ステップ1710で送信される。ステップ1712で、プッシュプロキシ410は、Mp1を使用せよという文によって示されるようなプロキシメタデータを使用する。さらに、ステップ1714で、クライアントメタデータおよびアプリケーションメタデータを含むこのコンテンツプラスメタデータは、プッシュクライアント510にパスされる。プッシュクライアント510は、ステップ1716で、クライアントメタデータを使用し、さらに、ステップ1718で、コンテンツペイロードをクライアントアプリケーション150にパスする。クライアントアプリケーション150は、ステップ1720で、アプリケーションメタデータを使用し、さらに、コンテンツペイロードを消費する。ステップ1722に示されるように、C2によって指定される第二のコンテンツペイロードは、第一のコンテンツペイロードと同じメタデータを有する。各処理エレメントは、すなわち、プッシュプロキシ410、プッシュクライアント510およびクライアントアプリケーション150は、コンテンツプロバイダ110に対するメタデータをキャッシュ化するので、メタデータは、再びパスされる必要がないが、その代わりに、既に、処理エレメント上に常駐している。その後、ステップ1724で、プッシュプロキシ410は、プッシュプロキシ410に対して以前にキャッシュ化されたメタデータを使用する。同様に、ステップ1726および1728で、プッシュクライアント510は、クライアントメタデータを使用し、クライアントアプリケーション150は、アプリケーションメタデータをそれぞれ使用する。ステップ1725および1727で、コンテンツは、メタデータを使用せずに、パスされる。ステップ1740に示されるように、コンテンツは、プッシュクライアント510およびクライアントアプリケーション150に対する新たなメタデータを有し得るが、プッシュプロキシ410に対する古いメタデータを保ち得る。この場合、ステップ1740でパスされるメタデータは、クライアントメタデータおよびアプリケーションメタデータのみを含む。ステップ1742で、プッシュプロキシ410は、キャッシュ化プロキシメタデータを用いて、ステップ1744で、新たなクライアントメタデータおよびアプリケーションメタデータとともにコンテンツペイロードをパスする。ステップ1746で、プッシュクライアント510は、自身にパスされた新たなクライアントメタデータを用いて、さらに、ステップ1748で、コンテンツペイロードおよびアプリケーションメタデータをパスする。ステップ1750で、クライアントアプリケーションは、新たなアプリケーションメタデータを用い、さらにコンテンツペイロードを消費する。当業者には理解されるように、メタデータが変化すること、メタデータが同じままで留まること、および変化したメタデータのみがそれを要求する処理エレメントにパスされることに関して、様々な構成が存在し得る。当業者には理解されるように、処理エレメントは、自身が新たなメタデータを受信しない場合、自身が格納したキャッシュ化メタデータに戻り、これをコンテンツペイロード上で用いる。更なる代替の実施形態において、インクリメントによる変化が、またメタデータになされ得る。例えば、ステップ1760で、新たなコンテンツペイロードは、デルタメタデータバージョンとともに、サービスプロキシ410にパスされ得る。プロキシメタデータのデルタは、以前にパスされたプロキシメタデータと、コンテンツが処理されるべき現在のメタデータとの間の差を含み得る。プッシュプロキシ410は、デルタを有する以前のメタデータを加えて、メタデータを構成し、次いで、ステップ1762で、これを用いてコンテンツペイロードを処理する。その後、変化がなかったので、ステップ1764で、コンテンツペイロードは、自身によって送信され、ステップ1766で、プッシュクライアント510は、以前にキャッシュ化されたクライアントメタデータを用いる。プッシュクライアントは、次いで、ステップ1768で、コンテンツペイロードをクライアントアプリケーション150にパスし、クライアントアプリケーション150は、ステップ1770で、コンテンツペイロード上の以前にキャッシュ化されたロケーションメタデータを用い、次いで、クライアントアプリケーション150は、コンテンツペイロードを消費する。インクリメンタルなデータが使用され得る例は、コンテンツプロバイダが、コンテンツペイロード内の既存のフィールドの中で、30が抽出され、クライアントアプリケーション150に送信されるべきであると、プロキシに告げる状況である。引き続くトランザクションで、そのコンテンツペイロードのピースにとって重要である2つの追加フィールドが、コンテンツプロバイダ110によって、クライアントアプリケーション150にパスされる必要があるとみなされ得る。コンテンツプロバイダは、それゆえ、インクリメンタルな変化を用いて、2つの追加フィールドを抽出し、それらを以前に抽出された30のフィールドに追加するように、プロキシに告げ得る。デルタすなわち、2つの追加フィールドをパスすることを必要とするだけなので、プッシュプロキシ410でメタデータを抽出するための処理時間は、削減され、それによって、処理は最適化される。さらに理解されるように、メタデータは、様々な形式で到来し得る。メタデータは、ネイティブコード、あるいはJava登録商標またはC登録商標のようなインタープリタ型コードでコンパイルされ得る。メタデータはまた、所定のプロパティを使用することを示すデータ/プロパティファイルでもあり得る。別の代替の実施形態において、メタデータは、バイナリコンテンツであり得て、例えば、XMLドキュメント上のXSLT変換のような変換であり得る。上記は、様々なアプリケーションに対して使用され、特定のクライアントアプリケーションに変換されるコンテンツに対して、知能を提供し得る。また、上記は、様々なコンテンツプロバイダが自分のデータを提供するメタデータに単に基づくだけで、様々なアプリケーションに対するコンテンツを提供し得るリッチなコンテンツプロバイダに対しても提供され得る。これは、図18の例によって示され得る。コンテンツプロバイダ110は、例えば、オンライン書店であり得る。アプリケーションは、オンライン書店に登録し得、アプリケーションは、特定のジャンルの新刊を知らせて欲しいことをオンライン書店に指示し得る。これは、毎日、または毎週、あるいは毎月ベースで起こり得る。コンテンツプロバイダ110は、例えば、毎週、ブックリスト1812を有するコンテンツエンベロープ1810をプッシュプロキシ410に送信する。また、コンテンツプロバイダが、変換メタデータ1814も送信し得、このメタデータ1814は、例えば、それを受信するアプリケーションに基づいて、特定のコンテンツを変換するためのURLリンクであり得る。一実施形態において、ブックリスト1812は、多数の本と、各本の著者および概要を含むその本の説明とを含む。ファイルは、例えば、サイズが100KBであり得る。プッシュプロキシ410は、この大きなファイルを受信し得、サービスされているクライアントアプリケーションに基づいて、例えば、10キロバイトの情報のみを受信可能であるクライアントにより良く適合するために、その大きなコンテンツファイルになされる必要がある変換を実現し得る。プロキシメタデータとしてパスされる変換は、それゆえ、ブックリストに適用され、ブックリストを10KB修正ドキュメント1820に縮小し得る。これは、例えば、概要を取り除き、本をランク付けし、上位50冊のみを含めることによって、あるいは、当業者には明らかな他の変換によって、行われ得る。一度、変換が完了すれば、修正ドキュメント1820は、次いで、プッシュクライアント510に送信される。さらに、図4に示されるような据え置き検索メッセージストア452が、変換プロセスで取り除かれたエキストラコンテンツを格納するために使用され得る。上記の利点は、書店が1つのサイトを有し得、そのクライアントの全てに1つのリストを送り得ることである。様々なクライアントが、モバイル無線クライアントではないので、100KBファイルもこれらのクライアントに対して適切であり得る。また、変換データを提供することによって、書店は、書店が全員に送信する1つのリストを有すればよい。当業者には理解されるように、ほとんどの現在のウェブ技術は、モバイルクライアントに対して、別個のウェブサイトを要求するが、このことが上記の解決策によって克服される。上記は、また、シンジゲートされたモデルに結び付き、ここで、図19を参照する。当業者には理解されるように、モバイルデバイスは、ネットワーク条件が大量のデータを受信するのに最適でないとき、大量のデータを受信することを望まないことがあり得る。さらに、ネットワークオペレータは、ネットワークのトラフィックが時間に対して、より均一になるようにするために、帯域幅の利用がピークの間は、大量のデータを送信することを避けたいと望み得る。これは、図19に示されるように、プッシュ/プルモデルを用いて達成され得る。図4を参照して以上に記載されたように、コンテンツは、ユーザが現在必要とし得るより多くの情報を含んで、提供され得る。例えば、ユーザが、自分のエリア内のレストランに対するロケーション情報をリクエストする場合、サービスプロバイダは、そのエリア内で利用可能な他のサービスのような広告を追加したいと望み得る。しかしながら、サービスプロバイダは、この追加コンテンツを即座にユーザへプッシュしたいと望まず、その代わりに、その追加コンテンツを示す見出しまたは目次のようなプライマprimerを提供したいと望み得る。他の状況において、コンテンツは、大き過ぎて、ユーザに送れないこともあり得るので、ユーザは、コンテンツの最初の部分のみを受信し得、そのコンテンツの残りは、据え置き検索メッセージストア452に格納される。その後、格納されたコンテンツは、プッシュプロキシ410によって、あるいは自分のプッシュクライアント510に対して問われたときのいずれかに、プッシュクライアント510にパスされ得る。プッシュクライアント510は、ネットワークのステータスをモニタし得るネットワークステータスモニタ1910を含む。プッシュクライアント510は、ある種の条件で、エキストラデータのみを受信したいと望み得る。例えば、WiFiおよびセルラのオプションを有するハイブリッドモバイルデバイス上で、WiFi接続上のデータを提供する方が安価である。したがって、ネットワークステータスモニタ1910は、据え置きされたコンテンツを取得する前に、プッシュクライアント510がWiFiネットワークに接続されるまで待ち得る。代替として、ネットワークステータスモニタは、ローミング料金を最低にするために、クライアントが外国のネットワーク内でローミングしているのか、あるいは国内のネットワークで接続されているのかをチェックし得る。ネットワークステータスモニタはまた、専用データチャネルがデバイスに対して確立されているかどうかを見るために、チェックし得る。プッシュクライアント510にパスされるべく据え置かれたデータをリクエストする前に、ネットワークステータスモニタ1910はまた、ネットワーク内の様々な他の前提条件をチェックし得ることを当業者は理解する。無線ネットワーク130はまた、プッシュクライアント510とプッシュプロキシ410との一方または双方に、データ配信のコストに関する情報を提供し得る。当業者には理解されるように、様々なピーク時間が、コンテンツ配信に対して生じる。交通情報の場合、ピーク時間は、人々が職場に行き、帰りする平日の始業および終業であり得る。株価に関しては、ピーク時間は、市場が開いている時間の間であり得る。他のピークも存在する。データトラフィックを平均化するために、ネットワーク内での現在のデータ利用に基づき、ネットワークが異なる料金を課すことが、望ましいことであり得る。したがって、ピーク時間は、真夜中のような非ピーク時間に比べて、高い料金が課され得る。無線ネットワーク130は、それゆえ、プッシュクライアント510上の据え置き検索マネージャ552、およびプッシュプロキシ410上のプッシュスケジューラ454に、配信コストの通知を提供する。一つの実施形態において、コンテンツプロバイダ110から、プッシュプロキシ410にパスされるデータは、クライアントにとってのその重要度に基づいてランク付けされ得る。ある種の情報は、メタデータを介して即座に配信されるように指定され得る。別の情報は、ネットワークコストが、第一の値例えば、1メガバイト当たり10セント未満のときに、配信されるように指定され得、他のデータは、第二の値例えば、1メガバイト当たり5セント未満に下がったときに、配信されるように指定され得る。こうして、プッシュスケジューラ454は、据え置き検索メッセージストア452内に格納されるデータを考慮し、据え置かれたデータをプッシュクライアント510上のプッシュエージェント544にパスするように、プッシュエージェント444に命令する。代替として、据え置き検索マネージャ552は、無線ネットワーク130から送信されるようなネットワーク状態をモニタし得、データ速度が、所定の速度未満の場合、コンテンツプルブローカ554に、据え置き検索メッセージストア452からのコンテンツをプルするように頼み得る。代替として、据え置き検索マネージャ552は、ネットワークステータスが、より大量のデータをプルするのに好都合であること、例えば、モバイルデバイスがWiFiネットワークに接続されていたかどうかのようなことを確認し得、コンテンツプルブローカ554に、データを据え置き検索メッセージストア452からプルするように頼み得る。さらに理解されるように、ユーザは、常にコンテンツがプルされるようにリクエストし得る。したがって、ユーザのリクエスト1940は、コンテンツプルブローカ554をトリガして、据え置き検索メッセージストア452からデータをプルするために使用され得る。プッシュスケジューラ454および据え置き検索マネージャ552内に格納されたルールは、コンテンツの分類に基づく静的メタデータであり得る。ルールは、また、パスされてきた特定のデータに対する動的メタデータに基づき得る。この場合、コンテンツプロバイダ110は、データを分類する。ここで、図20を参照する。当業者には理解されるように、データは、線形または非線形の2つの形式の一方であり得る。線形データは、例えば、アレイまたはストリングあるいは線形に流れるコンテンツであり得る。非線形データは、逆に、互いに線形に関係しないデータであり、コンテンツマップまたはリンクに複雑に依存することを含み得る。線形のコンテンツに対し、断片化は、データを線形進行linearprogressionに基づく様々なコンポーネントに分解するbreakことに関与するだけである。データは、セグメントに区分され、セグメントは、プッシュクライアント410に配信される。図20に示されるように、断片化プロセッサ2010は、コンテンツ2012と相互作用し、コンテンツが線形進行とともに解析されparsed得ることを決定する。断片化プロセッサ2010は、次いで、データを図20の例のセグメント2014、2016、および2018に区分し、図20に示されるように、第二および第三のセグメント2016および2018をそれぞれパスすることを据え置く間に、第一のセグメント2014をパスする。カーソル管理モジュール2030は、配信されたセグメントの跡をつけ、順番に次のセグメントを配信する。図21を参照すると、非線形コンテンツは、より賢明な方法で区分される必要がある。さらに、他端で、セグメントを再構成するために、メタデータが要求される。断片化プロセッサ2110は、メタデータベースの解析に基づき、コンテンツを解析する。これらは、論理的に要求される場合、所定のセグメントまたはデータエレメントを一緒に保つことを含む。断片化プロセッサ2110は、コンテンツ2112を解析し、コンテンツを論理的なルールに基づいて、セグメントに区分する。各セグメントは、コンテンツとメタデータとを含み、例えば、各セグメントに対する依存性、マップ、およびナビゲーションルールを含む。一度区分されると、第一のセグメント2114は、プッシュクライアント510に送信され、セグメント2116および2118の残余が、図21に示されるように据え置かれる。セグメントナビゲーションブロック2130は、どのセグメントを次に送信するかを扱う。当業者には理解されるように、第一のセグメント2114は、データ部分およびメタデータ部分を含む。第一のセグメント2114のメタデータ部分は、断片化プロセッサ2110によって加えられるメタデータの層であり、そのコンテンツをどのように再構成するかをコンテンツ依存性モジュール564に指示する。第一のセグメント2114のデータ部分は、チャネルまたはコンテンツと関連するコンテンツおよびメタデータの双方を含み得る。セグメントナビゲーションブロック2130は、いかにユーザがそのデータを介して移動するかを処理するように適応される。例えば、データがツリーフォーマットであり、ユーザがツリーの第一のブランチに下りていくと、セグメントナビゲーションブロック2130は、プッシュクライアント410に、ユーザがナビゲートしてきたエレメントから到達し得るツリーの他のブランチをパスし得る。例えば、ツリーは、会社に対して、構造とともに従業員名を有する従業員データベースを含み得る。図21に基づき、ユーザが組織の特定の課の中にナビゲートすると、そのセグメンテーションナビゲーションブロック2130は、その課の中のグループに対するグループ断片に転送し得る。次いで、ユーザがその課の特定のグループの中にナビゲートすると、そのセグメンテーションナビゲーションブロック2130は、そのグループの中の従業員に関する情報断片をパスし得る。それゆえ、上記は、データがロジカルコンポーネントに区分されることを要求する。識別子は、全てのタイプおよびコンテンツに割り当てられ、構造的情報は、プライマを有する情報をパスして生成される。上記は、それゆえ、システムの構造を変化させることなく、アプリケーションおよびコンテンツが追加され得るジェネリックシステムで使用され得る動的コンテンツ配信に対するアーキテクチャを提供する。コンテンツは、そのコンテンツを受信するアプリケーションに適合するように個別仕上げされ得、上記に従って、断片化され得る。以上は、コンテンツプロバイダおよびアプリケーションが、コンテンツ配信環境を認識するジェネリックシステムを提供する一方で、本開示の方法およびシステムの一つの実施形態において、コンテンツプロバイダ、アプリケーション、またはその双方のいずれかが、コンテンツ配信環境を認識しない。ここで、図22を参照する。図22において、コンテンツ配信エネーブラCDE2210は、コンテンツプロバイダ2230とクライアントアプリケーションとの間の動的コンテンツ配信、およびコンテンツプロバイダ2230をアプリケーションに結び付ける能力を促進するように適合される。コンテンツ配信エネーブラ2210は、図1のプッシュフレームワーク100と均等である。コンテンツ配信エネーブラ2210は、プッシュクライアント2212、無線ネットワーク2214、およびプッシュサーバ2216を含む。これらは、それぞれ図1のプッシュクライアント140、無線ネットワーク130、およびサービスプロバイダ120と均等であり得、図1に関連するコンポーネントの説明は、図22の実施形態に適用可能である。図22の実施形態において、コンテンツプロバイダ2230は、ジェネリックコンテンツプロバイダである。換言すれば、コンテンツプロバイダ2230は、異なる配信手段を利用する異なる端末によって使用され、それゆえ、任意の特定のコンテンツ配信アーキテクチャに不可知agnositicである。このようなジェネリック目的のコンテンツプロバイダ2230は、当業者に公知であり、広範な様々なクライアントをサービスする。一部の状況において、モバイルデバイスのユーザは、定期的なブラウジングを介して、コンテンツプロバイダ2230にアクセスする。しかしながら、動的コンテンツ配信のようなより高度なサービスが、ジェネリック目的のコンテンツプロバイダ2230から要求される場合、ジェネリックコンテンツプロバイダ2230を上述されたようなコンテンツ配信アーキテクチャに導くための手段が要求される。コンテンツプロバイダ2230からコンテンツを受信したい任意のアプリケーションが、コンテンツプロバイダ2230に登録するオプションを与えられることを確実にするためには、コンテンツプロバイダ2230は、コンテンツ配信エネーブラ2210に登録されなくてはならない。さらに、コンテンツ配信エネーブラ2210は、ジェネリックコンテンツプロバイダ2230から提供されるコンテンツに関するメタデータ情報を有する必要があり、配信スキーマおよびスケジュールを確立するために、そのコンテンツを処理することの可能なアプリケーションまたはアプリケーションのタイプ、あるいはコンテンツ配信エネーブラ2210およびアプリケーション見通しから必要とされる任意の他の情報を識別する必要がある。コンテンツプロバイダ2230を、図1~図21を参照して上述されたようなコンテンツ配信アーキテクチャの中に導くために、メタデータは、コンテンツプロバイダ2230のために存在することが必要である。同様に、図22に示されるクライアントアプリケーション2240、2245、または2250のようなクライアントアプリケーションは、本明細書で、ジェネリックアプリケーション2255と称されるジェネリッククライアントアプリケーションであり得る。換言すれば、ジェネリックアプリケーション2255は、コンテンツ配信アーキテクチャに不可知であり得る。ジェネリックアプリケーション2255が、コンテンツ配信モデルを意識しないときで、コンテンツ配信モデルを介して動的コンテンツを受信するために、相互作用するように特に設定されていないとき、このようなアプリケーション2255は、独力で、コンテンツ配信エネーブラ2210に登録することができない。これらのアプリケーション2255は、典型的には、コンテンツ配信エネーブラおよび登録インターフェースの知識を有さないので、したがって、図1~図21を参照して記載された上述のモデルにフィットしない。ジェネリックコンテンツプロバイダ2230と同様に、ジェネリックアプリケーション2255に関与することが望ましい。このようなアプリケーションは、モバイルデバイスのユーザに、モバイルデバイス上にロードされたアプリケーションと、一度ロードされたアプリケーションの機能性とに関する選択をより多く提供する。ジェネリックアプリケーション2255のようなアプリケーションに関与するために、本開示は、メディエータ2260を提供する。メディエータ2260の役割は、このメディエータが登録するアプリケーションのメタデータに関する知識、およびアプリケーションを登録するためのメタデータスキーマを含む登録インターフェースに関する知識を有することである。メディエータ2260は、ジェネリックまたはアプリケーション特有のいずれかであり得る。例えば、メディエータ2260は、アプリケーションとともに、アプリケーション開発者によって提供され得る。次いで、例えば、特定のアプリケーションを特定のコンテンツ配信エネーブラに登録するために、アプリケーションがモバイルデバイス上にロードされるとき、メディエータ2260は、ランされる。この場合、メディエータ2260は、アプリケーションに対するメタデータ情報を含む。代替として、ジェネリックメディエータ2260は、モバイルデバイス上に存在し得る。この場合、一度アプリケーション登録が要求されると、例えば、トリガの中でもとりわけ、モバイルデバイス上にロードされたアプリケーションを有することによって、コンテンツ配信エネーブラ2210を有するアプリケーションのユーザリクエスト登録を有することによって、アプリケーション用に向けられたプッシュデータを受信することによって、ジェネリックメディエータ2260は、レポジトリ2280に行き得、アプリケーションに対するメタデータを獲得し得る。理解されるように、一度、アプリケーション2255に対するメタデータがメディエータ2260によって受信されると、次いで、メディエータは、アプリケーションをコンテンツ配信エネーブラ2210と結び付けることを要求される。ここで、図23を参照する。メディエータ2370は、アプリケーション2310と関連するメタデータ2320を、コンテンツ配信エネーブラ2345によって要求されるメタデータスキーム2340にリゾーブしresolveようと試みる。特に、アプリケーション2310は、自身と関連するメタデータを含み、このメタデータは、本明細書では、アプリケーションメタデータ2320と称される。アプリケーションメタデータ2320は、アプリケーション2310が期待している様々なパラメータを含む。例は、ストレージパラメータを含み、とりわけ、到着しつつあるコンテンツが格納される場所、アプリケーションが進んで受け入れるデータの断片化またはサイズ制限を含む。他のパラメータは、例えば、通知パラメータを含み、通知パラメータは、アプリケーションがコンテンツ到着を通知されるべきかどうか、あるいはコンテンツが、キャッシュを用いることによってなど、アプリケーションに直接提供されるべきであるか、もしくはコンテンツが所定のロケーションに格納されるべきであるかを含む。アプリケーションに対して特有の他のメタデータもまた、本開示の範囲の中に入ることは、理解される。図23で、さらに分かるように、コンテンツ配信エネーブラは、自身と関連するメタデータスキームを含み、本明細書では、コンテンツ配信エネーブラメタデータスキーム2340と称される。理解されるように、コンテンツ配信エネーブラメタデータスキーム2340は、コンテンツ配信エネーブラ2345によって必要とされるアプリケーション関連パラメータを処理して、アプリケーション用のコンテンツをハンドリングし、配信することを可能にする。メディエータ2370は、コンテンツ配信エネーブラメタデータデータスキーム2340を用いて、メタデータ2320をリゾーブする。このようなレゾリューションは、アプリケーションメタデータ2320を読み出すステップと、必要とされるパラメータおよび情報を抽出するステップと、配信ハンドリング関連情報をアプリケーションメタデータ2320に追加するステップと、データをアプリケーション2310に対して許容可能なフォーマットに変換するステップと、コンテンツ配信エネーブラ2345を用いて、アプリケーション2310の登録へと進むステップとを含む。配信ハンドリング関連情報を追加することは、デバイスの事前に特定されたパラメータに基づき得るか、あるいはユーザが自分の受信したいと願うデータに関する情報、あるいはその情報をハンドリングすることを特定したいと駆り立てられた場合のように、ユーザ入力を含み得る。同様に、図22のメディエータ2270は、コンテンツプロバイダ2230のメタデータとプッシュサーバ2216に対するメタデータとの間で、同様の機能を実行する。メディエータ2270は、コンテンツプロバイダとコンテンツ配信エネーブラメタデータとの間のパラメータを接続する。メディエータ2260および2270は、それによって、それぞれジェネリックアプリケーションおよびジェネリックコンテンツプロバイダを可能にする。メディエータ2260が上述の機能性を実行して利用可能にさせるためには、様々なオプションが利用可能である。モバイルデバイス上のランタイム環境は、コンテンツ配信認識であるか、コンテンツ配信認識でないかのいずれかである。ランタイム環境が、コンテンツ配信認識である場合、ランタイム環境は、2つの方法のうちの1つで機能し得る。第一の方法において、ランタイム環境は、新たなアプリケーションが、インストールされることが分かり得、ユーザは、コンテンツ配信システムに、あるいはジェネリックアプリケーション2255がコンテンツ配信エネーブラ2210に接続されるべきことを示す他のトリガに、アプリケーションを接続したいと願う。一つの実施形態において、ランタイム環境は、次いで、中央レポジトリからダウンロードされるアプリケーション特定メディエータ2260を開始し得る。メディエータ2260は、様々な時間に、エアを介して提供され得る。様々な時間は、とりわけ、アプリケーションがモバイルデバイスに最初にロードされるとき、ユーザがアプリケーションから動的コンテンツ配信をリクエストするとき、モバイルデバイス上によってサービスされ得るコンテンツが到着するときを含む。アプリケーション特定メディエータ2260は、アプリケーションメディエータのサービスプロバイダが管理するレポジトリから提供され得るか、あるいはアプリケーション開発者または小売業者によって提供されるアプリケーション用のレポジトリの中に、アプリケーション開発者または小売業者によって提供され得る。一度、アプリケーション特定メディエータ2260がダウンロードされると、ランタイム環境は、ダウンロードメディエータ2260を実行し得、これによって、アプリケーションをコンテンツ配信エネーブラに結び付ける。代替として、ランタイム環境自身が、メディエータアプリケーションとして、機能し得る。この場合、この環境は、どのように登録処理を実行するかを知っており、中央レポジトリからアプリケーションに対するメタデータをダウンロードし得る。この時点で、ランタイム環境は、メタデータを用いて、アプリケーションをコンテンツ配信エネーブラ2210に登録し得る。さらなる実施形態において、ランタイム環境は、コンテンツ配信を認識しない場合、ユーザは、ジェネリックアプリケーション登録のために、特別アプリケーションをロードすることを開始する必要がある。特別アプリケーションは、デバイスコンテンツ配信を認識させ、ダウンロードされた特別アプリケーションは、次いで、ジェネリックアプリケーション登録のトリガが発生する場合はいつも、ジェネリックアプリケーションに対するメタデータを見出して、見出したメタデータを用いて、アプリケーションを登録することに進む。したがって、上記は、アプリケーションと、そのアプリケーションと関連するメタデータとをロードして、実行して、結び付けることが、自動であり得るか、あるいはユーザ駆動であり得るかを説明している。換言すれば、ユーザが処理を開始し得るか、あるいはアプリケーションがデバイス上にダウンロードされるときはいつも、処理が自動的になされ得るかである。3つのモデルが開示される。それらは、コンテンツ配信認識ランタイム環境によって、レポジトリからアプリケーション特定メディエータをロードするモデルと、ジェネリックメディエータとして機能するコンテンツ配信ランタイム環境によって、レポジトリからアプリケーションメディエータをロードするモデルと、あるいはコンテンツ配信を認識しないランタイム環境を、コンテンツ配信アーキテクチャを認識する環境にさせる特別アプリケーションを、モバイルデバイス上にロードして、今ではコンテンツ配信を認識するアーキテクチャが、メタデータをダウンロードし得、ジェネリックメディエータとして機能し得るモデルである。さらなる利用可能なオプションは、特定のアプリケーションをインストールしたモバイルデバイスに、登録メタデータまたはメディエータをプッシングすることである。このプッシングは、例えば、アプリケーションレポジトリからアプリケーションをダウンロードすると、そのアプリケーションレポジトリのようなサービスプロバイダまたは第三者エンティティから発生し得る。さらに、ユーザがプッシュクライアント2212をモバイルデバイス上にインストールし、それによって、コンテンツ配信フレームワークを繋げるjoinとき、サービスプロバイダは、そのときに、モバイルデバイス上に既にインストールされたアプリケーションに対して、登録メタデータをプッシュし得る。この場合、アプリケーションのリストは、デバイスによって提供され得る。他のオプションは、本開示を考慮すると、当業者には明らかになる。以上に示されたように、メタデータまたはメディエータアプリケーション自身を得るための中央レポジトリに対する代替は、アプリケーションを有するレポジトリを提供することである。換言すれば、様々なレポジトリは、各アプリケーション開発者のために存在する。次いで、各アプリケーション開発者は、アプリケーションに特有であるメディエータまたはメタデータを提供することが可能である。好ましい実施形態において、メタデータまたはメディエータはまた、利用されるコンテンツ配信アーキテクチャに特有でもあり得る。このように、図22のメディエータ2260または図23のメディエータ2370は、パラメータのマッチングを実行する必要がない。なぜなら、コンテンツ配信エネーブラメタデータ2340とアプリケーションメタデータ2320との間のパラメータは、マッチングするからである。コンテンツプロバイダ2230に対して、調停mediationは、プッシュサーバ2216上で実行され、上記と類似である。換言すれば、プッシュサーバ2216は、特定のコンテンツプロバイダに対するメディエータを獲得し得るか、あるいはコンテンツプロバイダに対するメタデータをゲットし得るジェネリックメディエータを含み得る。仲裁は、コンテンツ配信エネーブラメタデータ2340とコンテンツプロバイダメタデータ図示せずとの間で発生する。以上のことは、陰に結び付けること、および陽に結び付けることを考慮して、さらに拡張され得る。本開示を考慮すると、当業者によって、理解されるように、アプリケーションは、コンテンツプロバイダに結び付けられる。換言すれば、コンテンツプロバイダは、そのコンテンツプロバイダが期待するアプリケーションまたはアプリケーションのタイプが、そのコンテンツプロバイダから提供されるデータをハンドリングするように指示し得る。一つの例において、コンテンツプロバイダは、特定のアプリケーションのみが、そのコンテンツプロバイダからのコンテンツをハンドリングし得るように、特定し得る。コンテンツ配信エネーブラ2210は、次いで、特定のアプリケーションをインストールしたモバイルデバイスに、コンテンツプロバイダが利用可能であることを通知するのみである。そのアプリケーションに対するメタデータおよびパラメータは、コンテンツプロバイダから知られており、アプリケーションをコンテンツプロバイダに結び付けることは、したがって、陽である。上述のコンテンツプロバイダおよびアプリケーションは、ジェネリックであり得る。換言すれば、コンテンツプロバイダおよびアプリケーションは、コンテンツ配信アーキテクチャに不可知であり得る。以上は、それゆえ、コンテンツプロバイダとコンテンツ配信エネーブラ2210との間と、コンテンツ配信エネーブラ2210とアプリケーション2255との間との双方に、メディエータを要求し得る。アプリケーション2255はまた、陽に結び付けることを提供するようにも構成され得る。例えば、アプリケーションは、コンテンツが、コンテンツプロバイダ2230に対する特定のURIから要求されることを特定し得る。アプリケーション2255は、次いで、コンテンツプロバイダ2230より前に、登録される場合、モバイルデバイスは、アプリケーション2255によってリクエストされたコンテンツプロバイダ2230が登録すると、すぐに、通知される。陽に結び付けることに関する関係は、サーバ側で管理される。コンテンツ配信エネーブラ2210は、コンテンツ配信エネーブラ2210に接続されているデバイスおよびアプリケーション2255に関する情報を有し、存在するアプリケーション2255を有するこれらのデバイスに、通知を送信するのみである。代替として、陰の結び付けも起こり得る。例えば、コンテンツプロバイダ2230は、特定のタイプのコンテンツを提供していることを特定し得る。アプリケーション2230が、そのタイプのコンテンツの全て、またはサブセットを処理し得ることを特定する場合、コンテンツプロバイダ2230に対して許容可能であると、考えられ得る。陰に結び付ける状況において、コンテンツプロバイダ2230とアプリケーション2255との双方は、コンテンツタイプトークンをコンテンツ配信エネーブラ2210に提供しなくてはならない。コンテンツ配信エネーブラ2210は、次いで、コンテンツプロバイダのトークンに対するスキームを、アプリケーションに対するトークンとリンクするかどうかをマッチングしなくてはならない。一つの例において、コンテンツプロバイダ2230は、自身がRSSフィードを提供することを示す。アプリケーションは、自身がRSSフィードを処理し得ることを示す場合、マッチングが存在し、陰な結び付けが起こり得る。理解されるように、コンテンツプロバイダは、数多くのタイプのでデータを提供し得、アプリケーションは、これらのタイプのデータの全てを処理できないこともあり得る。さらに、コンテンツプロバイダは、特別化またはカスタム化された情報を提供し得、アプリケーションは、ジェネリック処理を提供するのみであり得る。例えば、株価RSSコンテンツプロバイダは、例えば、株価情報に対する特殊化RSSフィードを提供する場合、ジェネリックRSSフィードビューアアプリケーションは、株価情報に対して、期待されるユーザ体験を提供し得ない。一つの実施形態において、強度メトリックmetricが使用され、アプリケーションがコンテンツプロバイダに結び付けられるべきかどうかを決定し得る。したがって、アプリケーションは、コンテンツプロバイダによって提供されるスキームの任意のものを含まない場合、ゼロの強度が、登録され得、アプリケーションは、コンテンツプロバイダと結び付けられない。強度は、アプリケーション2255によって解釈され得るコンテンツプロバイダ2230によって提供される情報タイプの数に関連し得る。したがって、0からXまでの整数が、強度メトリックであり得、ここで、Xは、任意の整数であり得る。強度メトリックは、アプリケーションをコンテンツプロバイダに結び付けることに関する決定をするために使用され得る。例えば、1の強度が存在した場合、ユーザは、アプリケーションをコンテンツプロバイダに結び付けたいと、願い得、プロンプトが、ユーザに提供され得る。例えば、2の強度が存在した場合、結び付けは、自動的に起こり得る。以上は、例として、意図されるのみで、様々な結び付けのスキームが、インプリメントされ得る。以上の例で、それゆえ、コンテンツプロバイダは、RSS、金融、および株価セグメントを含むコンテンツトークンと、コンテンツトークンRSSを提供されたジェネリックRSSフィードビューアアプリケーションとを提供される場合、強度は、1として、定義される。一方、アプリケーションが、金融情報に対してカスタム化されたRSSビューアとして設計され、RSSおよび金融セグメントを含むコンテンツトークンを提供される場合、強度は、2であり得る。以上の開示を参照して、当業者によって理解されるように、アプリケーションをコンテンツプロバイダに結び付けることは、コンテンツ配信エネーブラ2210アーキテクチャにとって重要なことである。モバイルデバイスは、新たなコンテンツプロバイダが追加されるとき、どのアプリケーションが、そのコンテンツプロバイダの情報を処理し得るかを通知される。さらに、アプリケーションが、コンテンツ配信エネーブラ2210に登録しているとき、アプリケーション2255は、アプリケーションが利用し得るコンテンツプロバイダ2230のリストを提供され得る。アプリケーション2255またはコンテンツプロバイダ2230の全てが、それぞれどのプロバイダ2230またはアプリケーション2255と一緒に使用されることを意図されるかを、陽に提供するわけではないので、アプリケーションをコンテンツプロバイダに、陰に結び付けることが、コンテンツ配信エネーブラ2210によって実行される必要がある。上述の強度メトリックは、使用され得る強度メトリックの単なる一例に過ぎない。さらに、コンテンツタイプトークンに対するスキームもまた、ジェネリックであるが、理解されるように、アプリケーションとコンテンツプロバイダとの双方に対して、共通である必要がある。コンテンツ配信エネーブラ2210は、陰に結び付けるための候補を特定するために、何らかのヒューリスティックスを適用しなくてはならない。さらに、トークンのコンテンツは、コンテンツ配信エネーブラ2210に、不透明であり得、一部の場合において、トークンのスキームもまた、不透明であり得る。例えば、これは、結び付けが、コンテンツタイプの完全なマッチングに対して起こる場合に、存在する。強度メトリックの別の例は、比率であり、この比率は、絶対整数の代わりに、使用され得る。したがって、コンテンツプロバイダ2230が、コンテンツトークン内に3つのセグメント例えば、RSS、金融、株価を提供する場合、ジェネリックRSSビューアアプリケーション例えば、RSSの比率は、1/3であり、金融情報に対する特殊化RSSビューア例えば、RSSおよび金融セグメントの比率は、2/3である。したがって、上記は、ジェネリックアプリケーションおよびジェネリックコンテンツプロバイダをコンテンツ配信エネーブラアーキテクチャに登録することを提供し、さらに、アプリケーションとコンテンツプロバイダに依存して、アプリケーションをコンテンツプロバイダに、陽に、あるいは陰に結び付けることを提供する。理解されるように、プッシュクライアントおよびクライアントアプリケーションは、任意のモバイルデバイスに常駐し得る。一つの例示的なモバイルデバイスは、図24を参照して以下に記載される。これは、限定することを意味するものでなく、例示的な目的で提供される。図24は、本出願の装置および方法の好ましい実施形態で使用されることの多いモバイル局を示すブロック図である。モバイル局2400は、少なくとも音声およびデータ通信能力を有する双方向無線通信デバイスであることが好ましい。モバイル局2400は、インターネット上の他のコンピュータシステムと通信する能力を有することが好ましい。この無線デバイスは、提供される正確な機能性に依存して、例えば、データメッセージングデバイス、双方向ページャ、無線eメールデバイス、データメッセージング能力を有する携帯電話、無線インターネット機器、あるいは、データ通信デバイスと称され得る。モバイル局2400は、双方向通信が可能な場合、通信サブシステム2411を組み込む。通信サブシステム2411は、受信機2412と送信機2414との双方と、1つ以上の関連コンポーネント、例えば、好ましくは内蔵されているか内部のアンテナエレメント2416および2418、局部発振器LO2413、デジタル信号プロセッサDSP2420のような処理モジュールなどを含む。通信分野の当業者に明らかなように、通信サブシステム2411の特定の設計は、そのデバイスが動作するように意図される通信ネットワークに依存する。ネットワークアクセス要求もまた、ネットワーク2419のタイプに依存しても変化する。一部のCDMAネットワークにおいて、ネットワークアクセスは、モバイル局2400の加入者またはユーザに関連する。CDMAモバイル局は、CDMAネットワーク上で動作するために、取り外し可能ユーザ識別モジュールRUIMまたは加入者識別モジュールSIMカードを要求し得る。SIM/RUIMインターフェース2444は、通常はカードスロットに似ており、この中に、ディスケットまたはPCMCIAカードのように、SIM/RUIMカードが挿入および排出され得る。SIM/RUIMカードは、約64Kのメモリを有し得、多数のキー構成2451と、IDおよび加入者関連情報のような他の情報2453を保持し得る。要求されるネットワーク登録または活性化手順が完了したとき、モバイル局2400は、ネットワーク2419を介して、通信信号を送受信し得る。図24に示されるように、ネットワーク2419は、モバイルデバイスと通信する複数の基地局からなり得る。例えば、ハイブリッドCDMA1xEVDOシステムにおいて、CDMA基地局およびEVDO基地局は、モバイル局と通信し、そのモバイル局は同時に両者と接続される。EVDO基地局およびCDMA1x基地局は、異なるページングスロットを用いて、モバイルデバイスと通信する。通信ネットワーク2419を介してアンテナ2416によって受信された信号は受信機2412へ入力され、受信機2412は、信号増幅、周波数下方変換、フィルタリング、チャンネル選択など、および、図24に示される例のシステムにあるアナログデジタルA/D変換などの一般的な受信機の機能を実行し得る。受信信号のA/D変換によって、DSP2420において実行される復調および復号化などのより複雑な通信機能が可能になる。同様に、送信されるべき信号は、例えば、DSP2420による変調および符号化を含む処理がされ、デジタルアナログ変換、周波数上方変換、フィルタリング、増幅、アンテナ2418を介した通信ネットワーク2419上への送信のために、送信機2414へ入力される。DSP2420は、通信信号を処理するだけでなく、受信機および送信機の制御も提供する。例えば、受信機2412および送信機2414における通信信号に付与される利得は、DSP2420内でインプリメントされる自動利得制御アルゴリズムを介して適合するように制御され得る。モバイル局2400は、機器の動作全体を制御するマイクロプロセッサ2438を含むことが好ましい。少なくともデータおよび音声通信を含む通信機能は、通信サブシステム2411を介して実行される。また、マイクロプロセッサ2438は、ディスプレイ2422、フラッシュメモリ2424、ランダムアクセスメモリRAM2426、補助入力/出力I/Oサブシステム2428、シリアルポート2430、2つ以上のキーボードまたはキーパッド2432、スピーカ2434、マイク2436、短距離通信サブシステムのような他の通信サブシステム2440、および、一般的に2442で示される任意の他のデバイスサブシステムなどの追加デバイスサブシステムと相互作用する。シリアルポート2430は、USBポート、または当業者には周知の他のポートを含み得る。図24に示されるサブシステムの一部は、通信関連の機能を実行するのに対して、他のサブシステムは常駐のまたはオンデバイス機能を提供し得る。とりわけ、キーボード2432およびディスプレイ2422などの一部のサブシステムは、例えば、通信ネットワークを介する送信のためのテキストメッセージの入力などの通信関連機能と、計算器またはタスクリストのようなデバイス常駐機能との双方のために用いられ得る。マイクロプロセッサ2438によって用いられるオペレーティングシステムソフトウェアは、フラッシュメモリ2424などの持続性ストアに格納されることが好ましい。フラッシュメモリ2424は、代替として、読み出し専用メモリROMまたは同様のストレージエレメント図示せずであり得る。オペレーティングシステム、特定のデバイスアプリケーション、またはそのパーツが、RAM2426などのような揮発性メモリの中に一時的にロードされ得ることは、当業者には理解される。また、受信された通信信号は、RAM2426の中にも格納され得る。図示されるように、フラッシュメモリ2424は、コンピュータプログラム2458と、プログラムデータストレージ2450、2452、2454および2456との双方の異なるエリアの中に分離され得る。これらの異なるストレージタイプは、これら自身のデータストレージ要求のために、各プログラムがフラッシュメモリ2424の一部分に割り当てられ得ることを示す。マイクロプロセッサ2438は、そのオペレーティングシステム機能に加えて、モバイル局上でソフトウェアプリケーションの実行を可能にすることが好ましい。例えば、少なくともデータおよび音声の通信アプリケーションを含む基本的な動作を制御する所定のアプリケーションのセットは、通常は製造中にモバイル局2400にインストールされる。他のアプリケーションも、引き続き、あるいは動的にインストールされ得る。好ましいソフトウェアアプリケーションは、モバイル局のユーザに関連するデータ項目を編成および管理する能力を有する個人情報管理PIMアプリケーションであり得る。ユーザに関連する項目としては、eメール、カレンダーイベント、音声メール、約束、タスク項目などが挙げられるが、これらに限定されない。当然、1つ以上のメモリストアは、モバイル局上で利用可能であり、PIMデータ項目のストレージを容易にする。このようなPIMアプリケーションは、無線ネットワーク2419を介してデータ項目を送受信する能力を有することが好ましい。好ましい実施形態において、PIMデータ項目は、無線ネットワーク2419を介して、ホストコンピュータシステムに格納または関連付けされたモバイル局ユーザの対応データ項目を用いて、継続的に統合、同期および更新される。更なるアプリケーションは、また、ネットワーク2419、補助I/Oサブシステム2428、シリアルポート2430、短距離通信サブシステム2440、または任意の他の適切なサブシステム2442を介してモバイル局2400上にロードされ得て、マイクロプロセッサ2438による実行のために、RAM2426、または好ましくは不揮発性ストア図示せず内に、ユーザによってインストールされ得る。アプリケーションのインストールにおけるそのような柔軟性は、機器の機能性を高め、オンデバイス機能、通信関連機能、またはその双方の強化を提供し得る。例えば、確実な通信アプリケーションによって、モバイル局2400を用いて実行される電子商取引機能および他のそのような金融取引が可能となり得る。データ通信モードにおいて、テキストメッセージまたはウェブページダウンロードのような受信信号は、通信サブシステム2411によって処理され、マイクロプロセッサ2438に入力される。マイクロプロセッサ2438は、ディスプレイ2422または代替として補助I/Oデバイス2428への出力のために、受信信号をさらに処理することが好ましい。プッシュクライアント140、510、または2212と同等であり得るプッシュクライアント2460は、また、入力も処理し得る。モバイル局2400のユーザは、また、例えば、ディスプレイ2422およびおそらく補助I/Oデバイス2428と連動するキーボード2432を用いてeメールメッセージのようなデータ項目を構成し得る。キーボード2432は、完全な英数字キーボードまたは電話タイプのキーパッドであることが好ましい。このように構成された項目は、通信サブシステム2411を介して通信ネットワーク上に送信され得る。音声通信のために、モバイル局2400の動作全体は、類似している。ただし、受信信号は、好ましくはスピーカ2434への出力であり、送信のための信号はマイク2436によって生成されるという点は除く。代替の音声またはオーディオI/Oサブシステムもまた、例えば、音声メッセージ記録サブシステムなどは、モバイル局2400上でインプリメントされ得る。音声またはオーディオ信号出力は主にスピーカ2434を介して達成されることが好ましいが、ディスプレイ2422もまた用いられて、例えば、呼び出し人のアイデンティティの表示、音声呼び出しの継続時間、他の音声呼び出し関連情報を提供し得る。図24におけるシリアルポート2430は、通常、携帯情報端末PDAタイプのモバイル局でインプリメントされる。このモバイル局は、ユーザのデスクトップコンピュータ図示せずと同期することが、望ましいことであり得るが、随意のデバイスコンポーネントである。このようなポート2430によって、ユーザは、外部デバイスまたはソフトウェアプリケーションを介して優先度を設定でき、無線通信ネットワーク以外を介して、モバイル局2400に情報またはソフトウェアのダウンロードを提供することで、モバイル局2400の能力を拡張できる。代替のダウンロード経路は、例えば、直接それゆえ確実で信頼性ある接続を介して、機器に暗号化キーをロードし、それによって確実なデバイス通信を可能にするために使用され得る。当業者には理解されるように、シリアルポート2430は、モバイルデバイスをコンピュータに接続して、モデムとして機能するために、さらに使用され得る。短距離通信サブシステムのような他の通信サブシステム2440は、更なる随意のコンポーネントであり、モバイル局2400と異なるシステムまたはデバイスとの間に通信を提供し得る。このシステムまたはデバイスは、必ずしも同様のデバイスである必要はない。例えば、サブシステム2440は、赤外線デバイス、ならびに、関連回路およびコンポーネント、あるいは、BluetoothTM通信モジュールを含み得て、通信に同様に有効化されたシステムおよびデバイスを提供する。本明細書に記載された実施形態は、本出願の技術のエレメントに対応するエレメントを有する構造、システムまたは方法の例である。この書面による記載によって、当業者は、本出願の技術のエレメントと同様に対応する代替のエレメントを有する実施形態を実施し、使用することが可能となり得る。本出願の技術で意図される範囲は、したがって、本明細書に記載されたような本出願の技術と異ならない他の構造、システムまたは方法を含み、本明細書に記載されたような本出願の技術と実質的でない差を有する他の構造、システムまたは方法をさらに含む。"