(57)【要約】複数のセット・トップ・ボックス（ＳＴＢ）またはクライアント・デバイスとアプリケーション・サーバで実行されているすべてのアプリケーションに対応することができる共通通信言語。本発明のＤＡＴＰプロトコルは、プロセッサの稼働率が低くなければならず、また標準的な処理能力の限られているＳＴＢ処理に適している、汎用携帯通信アプリケーション・プログラマ・インターフェイスを提供するメタ言語をカプセル化する。ＤＡＴＰでは、標準的なインターネット通信プロトコルと比較して少ない処理サイクルで済む。ＤＡＴＰを使用すると、ＳＴＢでの通信プロトコル・ハンドラのオーバーヘッドが低減され、すべてのＳＴＢアプリケーションに対して通信プロトコル・ハンドラを共通にすることができる。好ましいＤＡＴＰプロトコルは、ＳＴＢの基本となるオペレーティング・システムとインターフェイスするネイティブ言語で書かれているため、すべてのＳＴＢに移植可能である。ＳＧＷ（ＳＧＷ）はＤＡＴＰサーバとして動作する。ＳＧＷは、ＤＡＴＰメッセージと標準通信プロトコルとの間の変換を行う。ＳＧＷにより、ＤＡＴＰを利用するＳＴＢにあるＳＰクライアントはさまざまな通信プロトコルを使用してサービス・アプリケーションと通信することができる。ここでは標準Ｗｅｂコンテンツをクライアント表示デバイス、例えばテレビに表示するのに適したコンテンツに変換するコンテンツ・コンバータが提示されている。
2004527028.tif 000002
【特許請求の範囲】
【請求項１】
分散コンピュータ・システムに通信機能を実装する方法であって、
クライアント・デバイスにクライアント互換通信トランスポート・プロトコルを提供することを含み、トランスポート・プロトコルはネットワーク・モデルのクライアント・デバイス・データ・リンク層、ネットワーク層、トランスポート層、およびセッション層のうちの少なくとも１つに置かれ、クライアント・デバイスからメッセージを送信し、クライアント・デバイスでメッセージを受信し、メッセージにはアプリケーション・コード、制御、データ、およびオーディオ／視覚的データのうち少なくとも１つを含み、
クライアント・デバイスとサーバとの間でメッセージを送信するためアプリケーション・レベル通信プロトコルを提供することを含み、アプリケーション・レベル通信プロトコルがクライアント互換通信トランスポート・プロトコルの上で実行される方法。
【請求項２】
さらに、
クライアント・デバイス上で利用できるネイティブ・トランスポートとクライアント・デバイス上で利用できるデータ・リンクのうちの少なくとも１つの上で実行されるクライアント互換トランスポート・プロトコルを使用する通信インターフェイスを提供することを含む請求項１に記載の方法。
【請求項３】
さらに、
アプリケーション・レベル通信プロトコルで、クライアントと、サーバと通信しているサービス・プロバイダとの間の通信動作を指定することを含む請求項１に記載の方法。
【請求項４】
さらに、
アプリケーション・レベル通信プロトコルで、クライアントとサーバとの間の通信に対してアプリケーション固有コンテンツをどのようにカプセル化するかを指定することを含む請求項１に記載の方法。
【請求項５】
さらに、
サービス・プラットフォーム用にモジュール式設計を可能にするアプリケーション・レベル通信プロトコル内の複数のドメイン仕様プロトコルを備え、追加ドメイン固有のプロトコル用に新規ＤＴＤを作成することによりドメイン固有プロトコルをアプリケーション・レベル・プロトコルのサブセットとして追加することができる請求項１に記載の方法。
【請求項６】
さらに、
サーバと複数のクライアント・デバイスとの間のトランスポート／サービス・レベル・プロトコル通信を指定することを含む請求項１に記載の方法。
【請求項７】
さらに、
サーバを介して、メッセージをクライアント・デバイスから複数のアプリケーションを含むネットワーク・バックエンド・インフラストラクチャに送る経路を設定することを含む請求項１に記載の方法。
【請求項８】
さらに、
クライアントとサーバとの間のトランスポート・レベル・プロトコルを実装することを含む請求項７に記載の方法。
【請求項９】
さらに、
クライアント・デバイスからメール・サーバにアクセスできるようにすることを含む請求項１に記載の方法。
【請求項１０】
さらに、
アプリケーション・レベル通信プロトコルで登録サービスに複数のサービスの複数のアカウントを登録することと、
クライアント・デバイスと登録サービスに登録されている複数のサービスとの間で複雑なやり取りをできるようにすることを含み、登録サービスはさらにサーバ内の単一の組込み点を含む請求項１に記載の方法。
【請求項１１】
さらに、
登録データベースからクライアント・アカウントのクエリを行い、データを返すことを含む請求項１に記載の方法。
【請求項１２】
さらに、
クライアント・デバイスとアプリケーションとの間の要求と応答の相互作用に対する規則を提供することを含み、この規則がクライアント・デバイスとサーバ内にモジュール化されている請求項１に記載の方法。
【請求項１３】
さらに、
受信契約者クライアントと非受信契約者クライアントとの間の通信を管理するメッセージング・マネージャを備えることを含み、通信には電子メール、チャット、および、インスタント・メッセージが含まれる請求項１に記載の方法。
【請求項１４】
さらに、
電波中継局および電波中継局と通信しているサービス・プロバイダからメッセージをクライアント・デバイスで受信することを含む請求項１に記載の方法。
【請求項１５】
さらに、
サービス・プロバイダからクライアント・デバイスのユーザへの通信を表示することを含む請求項１４に記載の方法。
【請求項１６】
さらに、
サービス・プロバイダとクライアント・デバイス・ユーザとの間で電子商取引を遂行することを含む請求項１５に記載の方法。
【請求項１７】
さらに、
サーバと複数のクライアント・デバイスとの間の通信のためサーバ側に通信スレッドの複数のプールを備えることを含む請求項１に記載の方法。
【請求項１８】
さらに、
アプリケーション・サーバ識別子とアプリケーション・サーバ属性を照合するデータ・ネーム・サービス・テーブルを提供することを含み、アプリケーション・サーバ属性はホスト名、ポート、およびタイプからなり、
セッション識別子とセッションａメッセージ・キューとの照合テーブルを提供することを含み、
セッションａメッセージ・キューにポストされた名前クエリに応答することを含む請求項１に記載の方法。
【請求項１９】
さらに、
放送によるクライアント・デバイスへのメッセージの経路を決定することを含む請求項１に記載の方法。
【請求項２０】
さらに、
クライアント互換通信トランスポート・プロトコル・ヘッダを備えることを含み、ヘッダにはプロトコル・バージョン番号、プロトコル・タイプ、ＳＴＢの実際のエクスポート・タイプ、メッセージ順序番号、サービス識別子、セッション識別子、暗号化フラグ、およびペイロード・データ・サイズが含まれる請求項１に記載の方法。
【請求項２１】
インタラクティブ・テレビ・システムで通信を実現する方法であって、
クライアント・デバイスにクライアント互換通信トランスポート・プロトコルを提供することを含み、トランスポート・プロトコルはネットワーク・モデルのクライアント・デバイス・データ・リンク層、ネットワーク層、トランスポート層、およびセッション層のうちの少なくとも１つに置かれ、クライアント・デバイスからメッセージを送信し、クライアント・デバイスでメッセージを受信し、メッセージにはアプリケーション・コード、制御、データ、およびオーディオ／視覚的データのうち少なくとも１つを含み、
クライアント・デバイスとサーバとの間でメッセージを送信するためアプリケーション・レベル通信プロトコルを提供することを含み、アプリケーション・レベル通信プロトコルがクライアント互換通信トランスポート・プロトコルの上で実行される方法。
【請求項２２】
さらに、
クライアント・デバイス上で利用できるネイティブ・トランスポートとクライアント・デバイス上で利用できるデータ・リンクのうちの少なくとも１つの上で実行されるクライアント互換トランスポート・プロトコルを使用する通信インターフェイスを提供することを含む請求項２１に記載の方法。
【請求項２３】
さらに、
アプリケーション・レベル通信プロトコルで、クライアントと、サーバと通信しているサービス・プロバイダとの間の通信動作を指定することを含む請求項２１に記載の方法。
【請求項２４】
さらに、
アプリケーション・レベル通信プロトコルで、クライアントとサーバとの間の通信に対してアプリケーション固有コンテンツをどのようにカプセル化するかを指定することを含む請求項２１に記載の方法。
【請求項２５】
さらに、
サービス・プラットフォーム用にモジュール式設計を可能にするアプリケーション・レベル通信プロトコル内の複数のドメイン仕様プロトコルを備え、追加ドメイン固有のプロトコル用に新規ＤＴＤを作成することによりドメイン固有プロトコルをアプリケーション・レベル・プロトコルのサブセットとして追加することができる請求項２１に記載の方法。
【請求項２６】
さらに、
サーバと複数のクライアント・デバイスとの間のトランスポート／サービス・レベル・プロトコル通信を指定することを含む請求項２１に記載の方法。
【請求項２７】
さらに、
サーバを介して、メッセージをクライアント・デバイスから複数のアプリケーションを含むネットワーク・バックエンド・インフラストラクチャに送る経路を設定することを含む請求項２１に記載の方法。
【請求項２８】
さらに、
クライアントとサーバとの間のトランスポート・レベル・プロトコルを実装することを含む請求項２７に記載の方法。
【請求項２９】
さらに、
クライアント・デバイスからメール・サーバにアクセスできるようにすることを含む請求項２１に記載の方法。
【請求項３０】
さらに、
アプリケーション・レベル通信プロトコルで登録サービスに複数のサービスの複数のアカウントを登録することと、
クライアント・デバイスと登録サービスに登録されている複数のサービスとの間で複雑なやり取りをできるようにすることを含み、登録サービスはさらにサーバ内の単一の組込み点を含む請求項２１に記載の方法。
【請求項３１】
さらに、
登録データベースからクライアント・アカウントのクエリを行い、データを返すことを含む請求項２１に記載の方法。
【請求項３２】
さらに、
クライアント・デバイスとアプリケーションとの間の要求と応答の相互作用に対する規則を提供することを含み、この規則がクライアント・デバイスとサーバ内にモジュール化されている請求項２１に記載の方法。
【請求項３３】
さらに、
受信契約者クライアントと非受信契約者クライアントとの間の通信を管理するメッセージング・マネージャを備えることを含み、通信には電子メール、チャット、および、インスタント・メッセージが含まれる請求項２１に記載の方法。
【請求項３４】
さらに、
電波中継局および電波中継局と通信しているサービス・プロバイダからメッセージをクライアント・デバイスで受信することを含む請求項２１に記載の方法。
【請求項３５】
さらに、
サービス・プロバイダからクライアント・デバイスのユーザへの通信を表示することを含む請求項３４に記載の方法。
【請求項３６】
さらに、
サービス・プロバイダとクライアント・デバイス・ユーザとの間で電子商取引を遂行することを含む請求項３５に記載の方法。
【請求項３７】
さらに、
サーバと複数のクライアント・デバイスとの間の通信のためサーバ側に通信スレッドの複数のプールを備えることを含む請求項２１に記載の方法。
【請求項３８】
さらに、
アプリケーション・サーバ識別子とアプリケーション・サーバ属性を照合するデータ・ネーム・サービス・テーブルを提供することを含み、アプリケーション・サーバ属性はホスト名、ポート、およびタイプからなり、
セッション識別子とセッションａメッセージ・キューとの照合テーブルを備えることを含み、
セッションａメッセージ・キューにポストされた名前クエリに応答することを含む請求項２１に記載の方法。
【請求項３９】
さらに、
放送によるクライアント・デバイスへのメッセージの経路を決定することを含む請求項２１に記載の方法。
【請求項４０】
さらに、
クライアント互換通信トランスポート・プロトコル・ヘッダを備えることを含み、ヘッダにはプロトコル・バージョン番号、プロトコル・タイプ、ＳＴＢの実際のエクスポート・タイプ、メッセージ順序番号、サービス識別子、セッション識別子、暗号化フラグ、およびペイロード・データ・サイズが含まれる請求項２１に記載の方法。
【請求項４１】
分散コンピュータ・システムによって命令が実行されたときに、
クライアント・デバイスにクライアント互換通信トランスポート・プロトコルを提供し、トランスポート・プロトコルはネットワーク・モデルのクライアント・デバイス・データ・リンク層、ネットワーク層、トランスポート層、およびセッション層のうちの少なくとも１つに置かれ、クライアント・デバイスからメッセージを送信し、クライアント・デバイスでメッセージを受信し、メッセージにはアプリケーション・コード、制御、データ、およびオーディオ／視覚的データのうち少なくとも１つを含み、
クライアント・デバイスとサーバとの間でメッセージを送信するためアプリケーション・レベル通信プロトコルを提供し、アプリケーション・レベル通信プロトコルをクライアント互換通信トランスポート・プロトコルの上で実行させる動作を分散コンピュータ・システムに実行させる命令を格納するコンピュータ読取り可能媒体。
【請求項４２】
さらに、
クライアント・デバイス上で利用できるネイティブ・トランスポートとクライアント・デバイス上で利用できるデータ・リンクのうちの少なくとも１つの上で実行されるクライアント互換トランスポート・プロトコルを使用する通信インターフェイスを提供する動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項４３】
さらに、
アプリケーション・レベル通信プロトコルで、クライアントと、サーバと通信しているサービス・プロバイダとの間の通信動作を指定する動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項４４】
さらに、
アプリケーション・レベル通信プロトコルで、クライアントとサーバとの間の通信に対してアプリケーション固有コンテンツをどのようにカプセル化するかを指定する動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項４５】
さらに、
サービス・プラットフォーム用にモジュール式設計を可能にするアプリケーション・レベル通信プロトコル内の複数のドメイン仕様プロトコルを備え、追加ドメイン固有のプロトコル用に新規ＤＴＤを作成することによりドメイン固有プロトコルをアプリケーション・レベル・プロトコルのサブセットとして追加することができるようにする動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項４６】
さらに、
サーバと複数のクライアント・デバイスとの間のトランスポート／サービス・レベル・プロトコル通信を指定する動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項４７】
さらに、
サーバを介して、メッセージをクライアント・デバイスから複数のアプリケーションを含むネットワーク・バックエンド・インフラストラクチャに送る経路を設定する動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項４８】
さらに、
クライアントとサーバとの間のトランスポート・レベル・プロトコルを実装する動作を分散コンピュータ・システムに実行させる命令を格納する請求項４７に記載の媒体。
【請求項４９】
さらに、
クライアント・デバイスからメール・サーバにアクセスできるようにする動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項５０】
さらに、
アプリケーション・レベル通信プロトコルで登録サービスに複数のサービスの複数のアカウントを登録し、
クライアント・デバイスと登録サービスに登録されている複数のサービスとの間で複雑なやり取りをできるようにし、登録サービスはさらにサーバ内の単一の組込み点を含むようにする動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項５１】
さらに、
登録データベースからクライアント・アカウントのクエリを行い、データを返す動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項５２】
さらに、
クライアント・デバイスとアプリケーションとの間の要求と応答の相互作用に対する、クライアント・デバイスとサーバ内にモジュール化された規則を提供する動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項５３】
さらに、
受信契約者クライアントと非受信契約者クライアントとの間の、電子メール、チャット、および、インスタント・メッセージが含まれる通信を管理するメッセージング・マネージャを提供する動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項５４】
さらに、
電波中継局および電波中継局と通信しているサービス・プロバイダからメッセージをクライアント・デバイスで受信する動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項５５】
さらに、
サービス・プロバイダからクライアント・デバイスのユーザへの通信を表示する動作を分散コンピュータ・システムに実行させる命令を格納する請求項５４に記載の媒体。
【請求項５６】
さらに、
サービス・プロバイダとクライアント・デバイス・ユーザとの間で電子商取引を遂行する動作を分散コンピュータ・システムに実行させる命令を格納する請求項５５に記載の媒体。
【請求項５７】
さらに、
サーバと複数のクライアント・デバイスとの間の通信のためサーバ側に通信スレッドの複数のプールを提供する動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項５８】
さらに、
アプリケーション・サーバ識別子と、ホスト名、ポート、およびタイプを含むアプリケーション・サーバ属性を照合するデータ・ネーム・サービス・テーブルを提供し、
セッション識別子とセッションａメッセージ・キューとの照合テーブルを提供し、
セッションａメッセージ・キューにポストされた名前クエリに応答する動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項５９】
さらに、
放送によるクライアント・デバイスへのメッセージの経路を決定する動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項６０】
さらに、
プロトコル・バージョン番号、プロトタイプ・タイプ、ＳＴＢの実際のエクスポート・タイプ、メッセージ順序番号、サービス識別子、セッション識別子、暗号化フラグ、およびペイロード・データ・サイズが含まれる、クライアント互換通信トランスポート・プロトコル・ヘッダを提供する動作を分散コンピュータ・システムに実行させる命令を格納する請求項４１に記載の媒体。
【請求項６１】
分散コンピューティング・システムの通信用アプリケーション・プログラムとともにコンピュータ上で実行されるコンピュータ読取り可能媒体に実現されているアプリケーション・プログラム・インターフェイス群であって、
クライアント・デバイスにクライアント互換通信トランスポート・プロトコルを提供し、トランスポート・プロトコルはネットワーク・モデルのクライアント・デバイス・データ・リンク層、ネットワーク層、トランスポート層、およびセッション層のうちの少なくとも１つに置かれ、クライアント・デバイスからメッセージを送信し、クライアント・デバイスでメッセージを受信し、メッセージにはアプリケーション・コード、制御、データ、およびオーディオ／視覚的データのうち少なくとも１つが含まれる、アプリケーション・プログラム・インターフェイスと、
クライアント・デバイスとサーバとの間でメッセージを送信するためアプリケーション・レベル通信プロトコルを提供し、アプリケーション・レベル通信プロトコルがクライアント互換通信トランスポート・プロトコルの上で実行される、アプリケーション・プログラム・インターフェイスを含むアプリケーション・プログラム・インターフェイス群。
【請求項６２】
さらに、
クライアント・デバイス上で利用できるネイティブ・トランスポートとクライアント・デバイス上で利用できるデータ・リンクのうちの少なくとも１つの上で実行されるクライアント互換トランスポート・プロトコルを使用する通信インターフェイスを提供するアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項６３】
さらに、
アプリケーション・レベル通信プロトコルで、クライアントと、サーバと通信しているサービス・プロバイダとの間の通信動作を指定するアプリケーション・プログラム・インターフェイス含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項６４】
さらに、
アプリケーション・レベル通信プロトコルで、クライアントとサーバとの間の通信に対してアプリケーション固有コンテンツをどのようにカプセル化するかを指定するアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項６５】
さらに、
サービス・プラットフォーム用にモジュール式設計を可能にするアプリケーション・レベル通信プロトコル内の複数のドメイン仕様プロトコルを備え、追加ドメイン固有のプロトコル用に新規ＤＴＤを作成することによりドメイン固有プロトコルをアプリケーション・レベル・プロトコルのサブセットとして追加することができるようにするアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項６６】
さらに、
サーバと複数のクライアント・デバイスとの間のトランスポート／サービス・レベル・プロトコル通信を指定するアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項６７】
さらに、
サーバを介して、メッセージをクライアント・デバイスから複数のアプリケーションを含むネットワーク・バックエンド・インフラストラクチャに送る経路を設定するアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項６８】
さらに、
クライアントとサーバとの間のトランスポート・レベル・プロトコルを実装するアプリケーション・プログラム・インターフェイスを含む請求項６７に記載のアプリケーション・プログラム・インターフェイス群。
【請求項６９】
さらに、
クライアント・デバイスからメール・サーバにアクセスできるようにするアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項７０】
さらに、
アプリケーション・レベル通信プロトコルで登録サービスに複数のサービスの複数のアカウントを登録し、
クライアント・デバイスと、さらにサーバ内の単一の組込み点を含む登録サービスに登録されている複数のサービスとの間で複雑なやり取りをできるようにするアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項７１】
さらに、
登録データベースからクライアント・アカウントのクエリを行い、データを返すアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項７２】
さらに、
クライアント・デバイスとアプリケーションとの間の要求と応答の相互作用に対する、クライアント・デバイスとサーバ内にモジュール化されている規則を提供するアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項７３】
さらに、
受信契約者クライアントと非受信契約者クライアントとの間の電子メール、チャット、および、インスタント・メッセージを含む通信を管理するメッセージング・マネージャを提供するアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項７４】
さらに、
電波中継局および電波中継局と通信しているサービス・プロバイダからメッセージをクライアント・デバイスで受信するアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項７５】
さらに、
サービス・プロバイダからクライアント・デバイスのユーザへの通信を表示するアプリケーション・プログラム・インターフェイスを含む請求項７４に記載のアプリケーション・プログラム・インターフェイス群。
【請求項７６】
さらに、
サービス・プロバイダとクライアント・デバイス・ユーザとの間の電子商取引を遂行するアプリケーション・プログラム・インターフェイスを含む請求項７５に記載のアプリケーション・プログラム・インターフェイス群。
【請求項７７】
さらに、
サーバと複数のクライアント・デバイスとの間の通信のためサーバ側に通信スレッドの複数のプールを提供するアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項７８】
さらに、
アプリケーション・サーバ識別子と、ホスト名、ポート、およびタイプからなるアプリケーション・サーバ属性を照合するデータ・ネーム・サービス・テーブルを提供し、
セッション識別子とセッションａメッセージ・キューとの照合テーブルを提供し、
セッションａメッセージ・キューにポストされた名前クエリに応答するアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項７９】
さらに、
放送によるクライアント・デバイスへのメッセージの経路を決定するアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項８０】
さらに、
プロトコル・バージョン番号、プロトコル・タイプ、ＳＴＢの実際のエクスポート・タイプ、メッセージ順序番号、サービス識別子、セッション識別子、暗号化フラグ、およびペイロード・データ・サイズが含まれる、クライアント互換通信トランスポート・プロトコル・ヘッダを提供するアプリケーション・プログラム・インターフェイスを含む請求項６１に記載のアプリケーション・プログラム・インターフェイス群。
【請求項８１】
分散コンピュータ・システムで通信を行えるようにする装置であって、
クライアント・デバイスにクライアント互換通信トランスポート・プロトコルを提供し、トランスポート・プロトコルはネットワーク・モデルのクライアント・デバイス・データ・リンク層、ネットワーク層、トランスポート層、およびセッション層のうちの少なくとも１つに置かれ、クライアント・デバイスからメッセージを送信し、クライアント・デバイスでメッセージを受信し、メッセージにはアプリケーション・コード、制御、データ、およびオーディオ／視覚的データのうち少なくとも１つが含まれる、コンピュータ・プログラム・コンポーネントと、
クライアント・デバイスとサーバとの間でメッセージを送信するためアプリケーション・レベル通信プロトコルを提供し、アプリケーション・レベル通信プロトコルがクライアント互換通信トランスポート・プロトコルの上で実行される、コンピュータ・プログラム・コンポーネントを備える装置。
【請求項８２】
さらに、
クライアント・デバイス上で利用できるネイティブ・トランスポートとクライアント・デバイス上で利用できるデータ・リンクのうちの少なくとも１つの上で実行されるクライアント互換トランスポート・プロトコルを使用する通信インターフェイスを提供するコンピュータ・プログラム・コンポーネントを備える請求項８１に記載の装置。
【請求項８３】
さらに、
アプリケーション・レベル通信プロトコルで、クライアントと、サーバと通信しているサービス・プロバイダとの間の通信動作を指定するコンピュータ・プログラム・コンポーネントを備える請求項８１に記載の装置。
【請求項８４】
さらに、
アプリケーション・レベル通信プロトコルで、クライアントとサーバとの間の通信に対してアプリケーション固有コンテンツをどのようにカプセル化するかを指定するコンピュータ・プログラム・コンポーネントを備える請求項８１に記載の装置。
【請求項８５】
さらに、
サービス・プラットフォーム用にモジュール式設計を可能にするアプリケーション・レベル通信プロトコル内の複数のドメイン仕様プロトコルを備え、追加ドメイン固有のプロトコル用に新規ＤＴＤを作成することによりドメイン固有プロトコルをアプリケーション・レベル・プロトコルのサブセットとして追加することができるようにするコンピュータ・プログラム・コンポーネントを備える請求項８１に記載の装置。
【請求項８６】
さらに、
サーバと複数のクライアント・デバイスとの間のトランスポート／サービス・レベル・プロトコル通信を指定するコンピュータ・プログラム・コンポーネントを備える請求項８１に記載の装置。
【請求項８７】
さらに、
サーバを介して、メッセージをクライアント・デバイスから複数のアプリケーションを含むネットワーク・バックエンド・インフラストラクチャに送る経路を設定するコンピュータ・プログラム・コンポーネントを備える請求項８１に記載の装置。
【請求項８８】
さらに、
クライアントとサーバとの間のトランスポート・レベル・プロトコルを実装するコンピュータ・プログラム・コンポーネントを備える請求項８７に記載の装置。
【請求項８９】
さらに、
クライアント・デバイスからメール・サーバにアクセスできるようにするコンピュータ・プログラム・コンポーネントを備える請求項８１に記載の装置。
【請求項９０】
さらに、
アプリケーション・レベル通信プロトコルで登録サービスに複数のサービスの複数のアカウントを登録するコンピュータ・プログラム・コンポーネントと、
クライアント・デバイスと、さらにサーバ内の単一の組込み点を含む登録サービスに登録されている複数のサービスとの間で複雑なやり取りをできるようにするコンピュータ・プログラム・コンポーネントを備える請求項８１に記載の装置。
【請求項９１】
さらに、
登録データベースからクライアント・アカウントのクエリを行い、データを返すコンピュータ・プログラム・コンポーネントを備える請求項８１に記載の装置。
【請求項９２】
さらに、
クライアント・デバイスとアプリケーションとの間の要求と応答の相互作用に対する、クライアント・デバイスとサーバ内にモジュール化されている規則を提供するコンピュータ・プログラム・コンポーネントを備える請求項８１に記載の装置。
【請求項９３】
さらに、
受信契約者クライアントと非受信契約者クライアントとの間の電子メール、チャット、および、インスタント・メッセージを含む通信を管理するメッセージング・マネージャを提供するコンピュータ・プログラム・コンポーネントを備える請求項８１に記載の装置。
【請求項９４】
さらに、
電波中継局および電波中継局と通信しているサービス・プロバイダからメッセージをクライアント・デバイスで受信する機能を備える請求項８１に記載の装置。
【請求項９５】
さらに、
サービス・プロバイダからクライアント・デバイスのユーザへの通信を表示する機能を備える請求項９４に記載の装置。
【請求項９６】
さらに、
サービス・プロバイダとクライアント・デバイス・ユーザとの間で電子商取引を遂行する機能を備える請求項９５に記載の装置。
【請求項９７】
さらに、
サーバと複数のクライアント・デバイスとの間の通信のためサーバ側に通信スレッドの複数のプールを提供するコンピュータ・プログラム・コンポーネントを備える請求項８１に記載の装置。
【請求項９８】
さらに、
アプリケーション・サーバ識別子と、ホスト名、ポート、およびタイプからなるアプリケーション・サーバ属性を照合するデータ・ネーム・サービス・テーブルを提供するコンピュータ・プログラム・コンポーネントと、
セッション識別子とセッションａメッセージ・キューとの照合テーブルを提供するコンピュータ・プログラム・コンポーネントと、
セッションａメッセージ・キューにポストされた名前クエリに応答する機能を備える請求項８１に記載の装置。
【請求項９９】
さらに、
放送によるクライアント・デバイスへのメッセージの経路を決定する機能を備える請求項８１に記載の装置。
【請求項１００】
さらに、
プロトコル・バージョン番号、プロトコル・タイプ、ＳＴＢの実際のエクスポート・タイプ、メッセージ順序番号、サービス識別子、セッション識別子、暗号化フラグ、およびペイロード・データ・サイズが含まれる、クライアント互換通信トランスポート・プロトコル・ヘッダを提供するコンピュータ・プログラム・コンポーネントを備える請求項８１に記載の装置。
【請求項１０１】
インタラクティブ・テレビ・システムで通信できるようにするための装置であって、
クライアント・デバイスからメッセージを送信し、クライアント・デバイスでメッセージを受信するために、ネットワーク・モデルのクライアント・デバイス・データ・リンク層、ネットワーク層、トランスポート層、およびセッション層のうちの少なくとも１つに置かれるクライアント互換通信トランスポート・プロトコルをクライアント・デバイスに提供するコンピュータ・プログラム・コンポーネントと、
クライアント・デバイスとサーバとの間でメッセージを送信するためアプリケーション・レベル通信プロトコルを提供し、アプリケーション・レベル通信プロトコルがクライアント互換通信トランスポート・プロトコルの上で実行される、コンピュータ・プログラム・コンポーネントを備える装置。
【請求項１０２】
さらに、
クライアント・デバイス上で利用できるネイティブ・トランスポートとクライアント・デバイス上で利用できるデータ・リンクのうちの少なくとも１つの上で実行されるクライアント互換トランスポート・プロトコルを使用する通信インターフェイスを提供するコンピュータ・プログラム・コンポーネントを備える請求項１０１に記載の装置。
【請求項１０３】
さらに、
アプリケーション・レベル通信プロトコルで、クライアントと、サーバと通信しているサービス・プロバイダとの間の通信動作を指定するコンピュータ・プログラム・コンポーネントを備える請求項１０１に記載の装置。
【請求項１０４】
さらに、
アプリケーション・レベル通信プロトコルで、クライアントとサーバとの間の通信に対してアプリケーション固有コンテンツをどのようにカプセル化するかを指定するコンピュータ・プログラム・コンポーネントを備える請求項１０１に記載の装置。
【請求項１０５】
さらに、
サービス・プラットフォーム用にモジュール式設計を可能にするアプリケーション・レベル通信プロトコル内の複数のドメイン仕様プロトコルを備え、追加ドメイン固有のプロトコル用に新規ＤＴＤを作成することによりドメイン固有プロトコルをアプリケーション・レベル・プロトコルのサブセットとして追加することができるようにするコンピュータ・プログラム・コンポーネントを備える請求項１０１に記載の装置。
【請求項１０６】
さらに、
サーバと複数のクライアント・デバイスとの間のトランスポート／サービス・レベル・プロトコル通信を指定するコンピュータ・プログラム・コンポーネントを備える請求項１０１に記載の装置。
【請求項１０７】
さらに、
サーバを介して、メッセージをクライアント・デバイスから複数のアプリケーションを含むネットワーク・バックエンド・インフラストラクチャに送る経路を設定するコンピュータ・プログラム・コンポーネントを備える請求項１０１に記載の装置。
【請求項１０８】
さらに、
クライアントとサーバとの間のトランスポート・レベル・プロトコルを実装するコンピュータ・プログラム・コンポーネントを備える請求項１０７に記載の装置。
【請求項１０９】
さらに、
クライアント・デバイスからメール・サーバにアクセスできるようにするコンピュータ・プログラム・コンポーネントを備える請求項１０１に記載の装置。
【請求項１１０】
さらに、
アプリケーション・レベル通信プロトコルで登録サービスに複数のサービスの複数のアカウントを登録するコンピュータ・プログラム・コンポーネントと、
クライアント・デバイスと、さらにサーバ内の単一の組込み点を含む登録サービスに登録されている複数のサービスとの間で複雑なやり取りをできるようにするコンピュータ・プログラム・コンポーネントを備える請求項１０１に記載の装置。
【請求項１１１】
さらに、
登録データベースからクライアント・アカウントのクエリを行い、データを返すコンピュータ・プログラム・コンポーネントを備える請求項１０１に記載の装置。
【請求項１１２】
さらに、
クライアント・デバイスとアプリケーションとの間の要求と応答の相互作用に対する、クライアント・デバイスとサーバ内にモジュール化されている規則を提供するコンピュータ・プログラム・コンポーネントを備える請求項１０１に記載の装置。
【請求項１１３】
さらに、
受信契約者クライアントと非受信契約者クライアントとの間の電子メール、チャット、および、インスタント・メッセージを含む通信を管理するメッセージング・マネージャを提供するコンピュータ・プログラム・コンポーネントを備える請求項１０１に記載の装置。
【請求項１１４】
さらに、
電波中継局および電波中継局と通信しているサービス・プロバイダからメッセージをクライアント・デバイスで受信する機能を備える請求項１０１に記載の装置。
【請求項１１５】
さらに、
サービス・プロバイダからクライアント・デバイスのユーザへの通信を表示する機能を備える請求項１１４に記載の装置。
【請求項１１６】
さらに、
サービス・プロバイダとクライアント・デバイス・ユーザとの間で商取引を遂行する機能を備える請求項１１５に記載の装置。
【請求項１１７】
さらに、
サーバと複数のクライアント・デバイスとの間の通信のためサーバ側に通信スレッドの複数のプールを提供するコンピュータ・プログラム・コンポーネントを備える請求項１０１に記載の装置。
【請求項１１８】
さらに、
アプリケーション・サーバ識別子と、ホスト名、ポート、およびタイプからなるアプリケーション・サーバ属性を照合するデータ・ネーム・サービス・テーブルを提供するコンピュータ・プログラム・コンポーネントと、
セッション識別子とセッションａメッセージ・キューとの照合テーブルを提供するコンピュータ・プログラム・コンポーネントと、
セッションａメッセージ・キューにポストされた名前クエリに応答する機能を備える請求項１０１に記載の装置。
【請求項１１９】
さらに、
放送によるクライアント・デバイスへのメッセージの経路を決定する機能を備える請求項１０１に記載の装置。
【請求項１２０】
さらに、
プロトコル・バージョン番号、プロトコル・タイプ、ＳＴＢの実際のエクスポート・タイプ、メッセージ順序番号、サービス識別子、セッション識別子、暗号化フラグ、およびペイロード・データ・サイズが含まれる、クライアント互換通信トランスポート・プロトコル・ヘッダを提供するコンピュータ・プログラム・コンポーネントを備える請求項１０１に記載の装置。
【発明の詳細な説明】
【著作権表示】
【０００１】
この特許文書の開示の一部に、著作権保護の請求が行われるもの（コード・リスティングおよびメッセージ・リスティング）が含まれる。著作権所有者は、米国特許商標局の書類綴りまたは記録に現れるこの特許文書または特許開示の何人によるそのままの複製にも異議を唱えないが、他のすべての権利を留保する。Ｃｏｐｙｒｉｇｈｔ  ２００１  ＯｐｅｎＴＶ，Ｉｎｃ．
【技術分野】
【０００２】
本発明は、インタラクティブ・テレビジョン・コンテンツ表示の分野に関し、具体的には、たとえばＨＴＭＬページなどのテキスト・マーク・アップ言語からの、たとえばＪａｖａＳｃｒｉｐｔなどのインタープリタ言語を抽出し、かつダウンロードするためそのＪａｖａＳｃｒｉｐｔをサーバでコンパイルすることに関し、さらに放送、インターネット、またはキャッシュによって提供されるコンテンツのインタラクティブ・テレビジョン表示空間内での表示を実行するクライアント・デバイスに関する。
【背景技術】
【０００３】
インタラクティブ・テレビジョン・システムを使用して、視聴者にさまざまなサービスを提供することができる。インタラクティブ・テレビジョン・システムは、通常のビデオ番組ストリーム、インタラクティブ・テレビジョン・アプリケーション、テキストおよびグラフィック・イメージ、ウェブ・ページ、およびその他のタイプの情報を配信することができる。インタラクティブ・テレビジョン・システムは、視聴者の動作または反応を登録することもでき、マーケティング、エンターテイメント、および教育などの目的に使用することができる。ユーザまたは視聴者は、宣伝された製品またはサービスの注文、ゲーム・ショーの参加者との競争、特定の番組に関する特殊化された情報の要求、または情報のページを介するナビゲーションによって、システムと対話することができる。
【０００４】
通常、放送サービス・プロバイダまたはネットワーク・オペレータは、視聴者のテレビジョンへの送信のためにインタラクティブ・テレビジョン信号を生成する。そのインタラクティブ・テレビジョン信号は、アプリケーション・コードまたは制御情報からなるインタラクティブ部分ならびにテレビジョンジョン番組またはその他の情報表示からなるオーディオ／ビデオ部分を含む。放送サービス・プロバイダは、ユーザのテレビジョンに接続された受信器へ送信するために、オーディオ／ビデオ部分とインタラクティブ部分を組み合わせて単一の信号にする。この信号は、一般に、送信の前に圧縮され、ケーブル・テレビジョン（ＣＡＴＶ）回線または直接衛星送信システムなどの通常の放送チャネルを介して放送される。
【０００５】
通常、テレビジョンに接続されたセットトップ・ボックス（ＳＴＢ）によって、テレビジョンのインタラクティブ機能が制御される。ＳＴＢは、放送サービス・プロバイダによって送信された放送信号を受信し、インタラクティブ部分をオーディオ−ビデオ部分から分離し、信号のそれぞれの部分を圧縮解除する。ＳＴＢは、インタラクティブ情報を使用して、たとえば、オーディオ／ビデオ情報がテレビジョンに送られている間にアプリケーションを実行する。ＳＴＢでは、オーディオ／ビデオ情報を、テレビジョンへの情報の送出の前にインタラクティブ・アプリケーションによって生成されたインタラクティブなグラフィックスまたはオーディオと組み合わせることができる。インタラクティブなグラフィックスまたはオーディオによって、追加情報を視聴者に提示することができ、あるいは、視聴者に入力を促すことができる。ＳＴＢによって、モデム接続またはケーブルを介する放送サービス・プロバイダに、視聴者の入力または他の情報を供給することができる。
【０００６】
寄せ集め的な性質に従って、インタラクティブ・テレビジョン・システムは、放送サービス・プロバイダ／ネットワーク・オペレータから情報を受け取るクライアントまたは視聴者が理解できるさまざまな異なる通信プロトコルでコンテンツを提供する。典型的には、クライアントは、限られた処理能力と通信帯域幅しか持たないプロセッサを備えたＳＴＢである。各種コンテンツおよびプロトコルの変換は、通常のＳＴＢプロセッサに備わっている限られた処理能力では対応できない。そこで、クライアント／ＳＴＢプロセッサが容易に認識でき、サービス・プロバイダが使用するさまざまなプロトコルで通信できる単純な通信プロトコルが必要である。また、インタラクティブ・テレビ環境においてアクセス、コンテンツ、およびスケジューリングの適応制御を行うソフトウェアおよびハードウェアのアーキテクチャも必要である。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、上述のインタラクティブ・テレビ環境に必要な機能の問題を解決するものである。本発明は、長い間切実に求められていたＳＴＢプロセッサにより容易に取り扱える単純なコンテンツおよび通信プロトコルの提供に応え、ＳＰおよびサービス・プロバイダとの複雑な通信を可能にする。以下の説明ではクライアント／ＳＴＢの例を使用するが、本発明は、デジタル・アシスタント、携帯電話、ポケット・パーソナル・コンピュータ、または電子信号を受信することができる他の種類の電子デバイスをはじめとするすべてのクライアント・デバイスに適用される。本発明は、サービス・プラットフォーム（ＳＰ）またはサーバ内に配置される。テレビ信号を受信契約者に送るネットワーク・オペレータは、ＳＰを使用し、ビジネス、トランスポート、および通信機能を作成、提供して、サービス・プロバイダとクライアントすなわちＳＴＢ視聴者との間で通信を行うことができる。
【課題を解決するための手段】
【０００８】
インタラクティブ・テレビ環境では、クライアントからＳＰへの間欠的リターン・パスなど、インタラクティブ・テレビに固有の問題に対応し、解決する必要がある。つまり、クライアント・デバイスは、ＳＴＢをオフにした場合のように、通信リンクに常に接続されているわけではないということである。そのため、クライアントからのアクティブなリターン・パスが常にあるわけではない。本発明は、このような間欠的リターン・パス問題を緩和するストア・アンド・フォワード機能を実現する。
【０００９】
帯域幅および処理の制限および通信の複雑さもまた、インタラクティブ・テレビ環境では問題になる。一方、ネットワーク・オペレータは、通常、データおよび番組をクライアントに送信するのに比較的大きな伝送容量（通常、衛星と受信アンテナ）を放送チャネルに持たせている。他方、クライアントのリターン・パスは、通常ＳＴＢシナリオではデータ伝送容量が比較的低く、電話回線はリターン・パスである。リターン・パスがたまたま大きな帯域幅を持つとしても、ＳＴＢ／クライアントは通常、リターン・パスでデータを送信するのに低速なモデムを用いている。これらの課題および他の課題を、本発明で取りあげる。
【００１０】
本発明の他の目的および長所は、以下の詳細な説明を読み、添付図面を参照する時に明白になる。
【００１１】
本発明は、さまざまな修正形態および代替形態を許すが、本発明の特定の実施形態を、図面で例として示し、本明細書で詳細に説明する。しかし、図面およびそれに対する詳細な説明が、開示される特定の形態に本発明を制限することを意図されたものではなく、逆に、本発明が、請求項によって定義される本発明の趣旨および範囲に含まれるすべての修正形態、同等形態、および代替形態を含むことを理解されたい。
【発明を実施するための最良の形態】
【００１２】
本発明のデジタル・テレビ・アプリケーション・プロトコルＤＡＰ／ＤＡＴＰは、サービス・プラットフォーム（ＳＰ）内に配置され、コンテンツ・トランスコーダ、Ｈ２Ｏおよびサービス・ゲートウェイ（ＳＧＷ）と相互作用する。代表的なインタラクティブ・テレビ環境においては、複数のクライアント／受信契約者、典型的には、さまざまな通信プロトコルを使用して複数のネットワーク上でコンテンツを提供する複数のアプリケーション・サーバと通信しなければならないＳＴＢがある。通常、ＳＴＢが備える処理能力は限られており、ＳＴＢプロセッサあるいはＳＴＢスタック内に多数の通信プロトコル・ハンドラを入れるのは望ましくない。したがって、すべてのＳＴＢおよびアプリケーション・サーバに対応できる共通通信インターフェイスが必要である。本発明のＤＡＴＰプロトコルは、処理能力の限られている典型的なＳＴＢに適し、プロセッサの稼働率が低くてもよい汎用携帯通信アプリケーション・プログラマ・インターフェイス（ＡＰＩ）を提供する。ＤＡＴＰは、代表的なインターネット通信プロトコルと比べて処理サイクル数が比較的少ない。ＤＡＴＰを使用すると、ＳＴＢでの通信プロトコル・ハンドラのオーバーヘッドが低減され、すべてのＳＴＢに対して通信プロトコル・ハンドラを共通にすることができる。好ましいＤＡＴＰプロトコルは、ＳＴＢのオペレーティング・システムとインターフェイスするＳＴＢから独立しているバイト・コードであるＯコードで書かれているため、すべてのＳＴＢに移植可能である。
【００１３】
本発明では、ＳＧＷは、ＤＡＴＰサーバとして稼働する。ＳＧＷにより、ＳＴＢにあるＳＰクライアントはＤＡＴＰプロトコルを使用してアプリケーション・サーバに接続することができる。ＨＴＭＬとネイティブ・コードとの間のプロキシ、すなわちＨ２Ｏが用意されているが、これは、この文脈では、ＳＰアプリケーション・サーバとみなすことができる。Ｈ２Ｏは、ＨＴＭＬからＳＰ  Ｏコードへなど、特定のコンテンツ変換を実行する。Ｏコードは、ＳＰ上で実行されている仮想マシンのＳＴＢ独立のバイトコードである。好ましい実施形態では、ＤＡＴＰプロトコル・スタックのＯコード実装がクライアント、通常はＳＴＢ内に存在する。クライアントは、ＤＡＴＰプロトコルを使用してＤＡＴＰサーバ、ＳＧＷと通信する。Ｈ２Ｏプロキシは、ＨＴＭＬからＯコードへなどのコンテンツ変換を実行するＳＧＷの片方の側に存在する。クライアント／ＳＴＢ内のＤＡＴＰスタックのＯコード実装は、通信要求を発行し、ＤＡＴＰプロトコルを使用してＳＧＷと通信する。Ｈ２Ｏによって変換されたコンテンツは、ＳＧＷを通して、コンテンツが表示されるクライアントに渡される。
【００１４】
ＳＧＷは、各個別ＳＴＢを扱い、各関連コンテンツを処理する実行スレッドを作成するＤＡＴＰサーバである。ＳＧＷサーバ・スタックは、ＤＡＴＰプロトコルを使用してクライアント／ＳＴＢと通信する。ＳＧＷはさらに、ＳＴＢと異なるアプリケーション・サーバとの間の通信をＳＴＢが行えるようにするのに必要な適切なプロトコルを用いる。インタラクティブ・テレビ・アプリケーションは通常、よく知られているインターネット・ベースのプロトコル（ＨＴＭＬなど）を使用して、クライアント／ＳＴＢとアプリケーション・サーバとの間の通信を行う。本発明は、ＳＧＷを介したクライアント／ＳＴＢとアプリケーション・サーバとの間の汎用の適切な非対称通信プロトコルを備える。本発明は、クライアント／ＳＴＢで利用可能な最小限の処理およびメモリに適応する。
【００１５】
本発明はデータ圧縮に対して非対称ソリューションを採用している。クライアント／ＳＴＢからネットワーク・オペレータへの双方向経路の帯域幅は比較的小さく、通常の電話回線またはケーブルのリターン・チャネルが低速のモデムに接続されているのがふつうである。したがって、低速モデムで利用可能な帯域幅を上げるには、サーバからクライアント／ＳＴＢにダウンロードするコンテンツを圧縮する。しかし、クライアント／ＳＴＢでは、データ圧縮を実行しない方が好ましい。返されるクライアント／ＳＴＢデータは比較的小さく、データ圧縮を実行しようにも処理能力がないのがふつうであるＳＴＢプロセッサでデータ圧縮をする必要がない。しかし、他の実施形態では、クライアント／ＳＴＢからのデータ圧縮が望ましい場合があり、このような場合には、ＳＧＷ側でデータ圧縮を実行する。データ圧縮は、クライアント／ＳＴＢに関して、データが下流のクライアント／ＳＴＢへ流れるときに圧縮され、ＳＴＢから上流に流れるときには圧縮されないという点で、非対称である。そのため、本発明のアーキテクチャは、通信している両方のエンティティが対称的な能力を持つと仮定している通常のインターネット・ベースのプロトコルと異なり非対称である。
【００１６】
ＳＧＷおよびクライアント／ＳＴＢは、ユーザ識別子ではなくクライアントのセッション識別子を使用してアプリケーション・サーバと通信するので、クライアント・ユーザは匿名ユーザのままでよい。本発明はさらに、クライアントへのマルチキャスト機能も備える。放送帯域幅であり、チューナーがＳＴＢ内にあり、放送メッセージが利用でき、ＳＴＢ内の特定のフィルタ・セットアップにより感知されるときに、放送リンクを介してマルチキャスト・メッセージを複数のクライアントに送信することができる。この場合、ＤＡＴＰは、放送時に特定のエントリからＳＴＢがメッセージを受信するよう要求する。ＳＴＢで放送を受信するのにチューナーを利用できない場合、チューナーなしでメッセージ断片も各ポイントツーポイントの個別リンクでＳＴＢに送信される。ＳＴＢがＬＡＮ上にある場合、メッセージがＳＴＢのＬＡＮ上のよく知られているアドレスに送信される。
【００１７】
本発明はさらに、インターネット・アプリケーションからのｃｏｏｋｉｅを処理するための新規性のある構造と方法も提示し、またＨＴＴＰ要求をＤＡＴＰメッセージ内にカプセル化する「軽量」ＨＴＴＰプロトコルであるＬＨＴＴＰも実装する。ＬＨＴＴＰは、ＤＡＴＰの上で実行されるＨＴＴＰの簡易バージョンである。この新規性のあるＬＨＴＴＰは、ＤＡＴＰの上で実行され、ＴＣＰ／ＩＰ規格の一部を実装したものではない。
【００１８】
ＳＧＷは、ＳＴＢとのリンクつまりソケット接続を確立する。しかし、ユーザ・データグラム・プロトコル（ＵＤＰ）を実装する場合も、ＵＤＰは直接実行されない。ＵＤＰを出力できるＳＴＢでは、本発明はＵＤＰにＤＡＴＰをカプセル化する。ＤＡＴＰカプセル化ＵＤＰはＳＧＷに送信される。ＵＤＰの場合、ＳＧＷのソケットとＳＴＢのソケットは、実際には、ＵＤＰの上のシミュレートされた接続に結合されまとめられる。このシミュレートされた接続を通じて、ＤＡＴＰパケットがＳＴＢからＳＧＷサーバへ、またＳＧＷサーバからＳＴＢへと送信される。
【００１９】
多くのＳＴＢモデムは、データ圧縮機能を持たず、備える処理能力も最低限度であるため、ＳＴＢのデータ圧縮を実行する処理コストに応じる余裕がない。したがって、好ましい実施形態では、非対称データ圧縮機能はＳＴＢ側で実行される。ＳＴＢは、圧縮データを受け取って圧縮解除するが、ＳＴＢはデータ圧縮を実行しない。ただし、データの圧縮解除は、データの圧縮に比べて計算能力をあまり必要としないため、ＳＴＢで圧縮解除を実行するのが好ましい。ＳＴＢはデータ圧縮を実行しない。圧縮されたデータはＳＴＢのＤＡＴＰスタックに送られるが、未圧縮データはＳＴＢからＳＧＷに送られる。ＳＧＷは、ＳＴＢから送られた未圧縮データにデータ圧縮を実行し、ＳＧＷはその圧縮されたデータをアプリケーション・サーバに返す。したがって、好ましいＤＡＴＰ／ＳＧＷ非対称圧縮では、ＳＴＢからＳＧＷを通りアプリケーション・サーバへ向かうリターン・パスの帯域幅が増える。
【００２０】
本発明は、ＳＧＷによる非対称ルーティングを提供する。非対称ルーティングでは、データが放送のため放送ストリームに送られるように帯域幅の一部がＳＧＷに割り当てられる。ＳＧＷは、放送ストリームで、またはＳＧＷとＳＴＢとの間のポイントツーポイント（ＰＴＰ）接続で１つまたは複数のＳＴＢにデータを送信するかどうかを決定することができる。ＳＧＷは、データの量、ＳＴＢへのポイントツーポイント・リンクの速度、および現在の通信リンクの負荷状態に基づいて、放送ストリームかまたはＰＴＰ接続を介するかデータの送信経路を決定する。そこで、データ・セットが大きすぎるので、ポイントツーポイント・リンクでデータ・セットを送信せず、その代わりに放送ストリームを介して送信することをＳＧＷが決めることもできる。受信ストリームまたはポイントツーポイント・リンクに送信する前に、データをＳＧＷで圧縮して、ＳＧＷとリンクまたはストリームとの間のリンクの帯域幅を高くし、ＳＴＢ内のメモリ限界に適応するようにできる。
【００２１】
すべてのＳＴＢスタックのオペレーションに最低限の処理能力が要求されるように設計されているためＤＡＴＰは計算量が少ない。たとえば、ＤＡＴＰ暗号化方式では、Ｒｉｖｅｓｔ、Ｓｈａｍｉｒ、およびＡｌｄｅｒｍａｎ（ＲＳＡ）公開鍵暗号化を使用したときに、サーバから送られてくる鍵に対し、指数演算段階の時間と処理能力が最低限で済むように小さい指数値（３またはそれ以上）を選択する。そのため、大きな計算はＳＧＷサーバに割り当てられ、ＳＴＢすなわちクライアントのプロセッサは最低限の処理能力で済む。同様に、ＳＴＢ内のＤＡＴＰの上にあるＬＨＴＴＰ層では、重い解析や他の大きな処理能力を必要とするオペレーションを実行する必要がない。その代わりに、ＬＨＴＴＰによりＨＴＴＰデータをＤＡＴＰメッセージにカプセル化し、ＨＴＴＰプロトコルへの変換などの大きな計算能力を必要とするＨＴＴＰ機能についてはＳＧＷ側で処理する。
【００２２】
ＤＡＴＰが実行するトランザクションはさらに多い。というよりは、ＤＡＴＰはトランザクション指向のプロトコルではなくメッセージ・ベースのプロトコルだということであり、したがって、ユーザがメッセージをＳＴＢからアプリケーション・サーバに送信しても、アプリケーション・サーバは応答しなくてもよい。つまり、ＳＴＢとサービス・プロバイダのメッセージとの間に１対１の対応関係がない。信頼性のないＤＡＴＰメッセージのクラスを除くすべてのＤＡＴＰが信頼性のあるＤＡＴＰ層を通じて処理される。すべてのＤＡＴＰメッセージには、トランザクションの基盤として使用できる一意の識別子が設定される。
【００２３】
ＤＡＴＰを使用したトランザクション、たとえばＨＴＴＰ要求では、ＳＴＢはＷｅｂページを要求するＤＡＴＰメッセージをＳＧＷに送信する。ＳＧＷは、ＬＨＴＴＰをＨＴＴＰに変換し、Ｈ２Ｏを介してインターネットに送信する。Ｗｅｂページを含む応答がコンテンツを変換するＨ２Ｏを介してインターネットからＳＧＷに返されると、ＳＧＷはＬＨＴＴＰ  ＤＡＴＰメッセージをＳＴＢに送信し、要求されたＷｅｂページのコンテンツをＳＴＢに返す。トランザクションの別の例として、ＳＴＢから送信されるＦｅｔｃｈｍａｉｌがある。Ｆｅｔｃｈｍａｉｌ要求は、ＤＡＴＰメッセージ内にカプセル化される。ＤＡＴＰメッセージのトップでＤＡＭＬが使用される。ＤＡＭＬは、ＸＭＬのドメイン固有のインスタンスである。
【００２４】
そこで、ＳＴＢはＤＡＴＰメッセージをＤＡＭＬ（ＸＭＬ）要求を含むＦｅｔｃｈｍａｉｌに送信する。Ｆｅｔｃｈｍａｉｌは、ＤＡＴＰメッセージを読み込み、メッセージからコンテンツを抽出し、そのコンテンツをアプリケーション・サーバに渡し、そのサーバでトランザクションを処理して、メッセージをＦｅｔｃｈｍａｉｌに返す。次に、Ｆｅｔｃｈｍａｉｌは、要求された内容を含むＤＡＴＰメッセージをＳＴＢに送信する。
【００２５】
ＤＡＴＰは、開放型システム相互接続（ＯＳＩ）モデルにマッピングされるため柔軟性が高い。ＯＳＩモデルは、コンピュータ間通信に７つの層を設定している。この７つの層のそれぞれは、下の層の上に構築される。下から上まで、物理層、データ・リンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、およびアプリケーション層の７つのＯＳＩ層がある。ＤＡＴＰは、ＯＳＩモデルの７つの層のうち４つにまたがっており柔軟性がある。ＤＡＴＰは、ＯＳＩモデルのデータ・リンク層、ネットワーク層、トランスポート層、およびセッション層にまたがる。ＯＳＩモデルでは、ＯＳＩモデルを使用して通信する各コンピュータ・サーバとホストに対称的処理能力を仮定する。つまり、ＯＳＩモデルは対称的通信モデルを実装するということである。この対称的モデルは、処理能力の低いＳＴＢには適していない。ＤＡＴＰは、特にインタラクティブ・テレビ環境に適するように設計されている、「太った」（帯域幅が広く、処理能力が高い）サーバ／やせた（帯域幅が狭く処理能力が低い）クライアント・パラダイムに基づく非対称通信プロトコルを備えている。
【００２６】
ＤＡＴＰは、実質的に、送信されるバイト当たりのオーバーヘッドを最小限まで減らす。ＤＡＴＰプロトコルは、パケット・オーバーヘッドがおおよそ２０バイトとなるようにそれ専用のＤＡＴＰパケット形式を含むバイナリ形式で実装されており、これは、ＴＣＰ／ＩＰ形式のフレーミングで必要なものの半分である。ＤＡＴＰは信頼層を備える。ＤＡＴＰはさらに、「信頼できないＤＡＴＰパケット」も備えており、これで、アクノリッジされず、信頼層を通じて信頼できるものにならないメッセージをＳＴＢに送信する。信頼できないＤＡＴＰパケットは、マルチキャストに使用できる。
【００２７】
ＳＧＷはさらに、ユーザ注文要求にすばやく反応しながら、複数のユーザから送られた多数の注文のピークに応じられるストア・アンド・フォーワード機能も備える。ＳＧＷは、ユーザの注文への応答としてユーザに「注文アクノリッジ」を送信し、注文トランザクションを実際に処理するアプリケーション・サーバに後で送信するためその注文を格納する。後で注文送信することにより、多数の注文を時間をかけて分散させるため、アプリケーション・サーバに一度に送信しなくてよくなる。したがって、帯域幅を効率よく使用できる。ＤＡＴＰはさらに、時間に対する順序番号に基づくスライディング・拒絶ウィンドウを備える。ＤＡＴＰ／ＳＧＷについて、以下で詳述する。
【００２８】
サービス・プラットフォーム
そこで図１を参照すると、本発明が配置されるＳＰがこの図に示されている。ＳＰ  ５０は、コンテンツ変換２０４、トランザクション制御／ビジネス機能１０６、およびトランスポート変換１０８という３つのカテゴリに大まかに分けられるアプリケーションのグループからなる。ＳＰにより、サービス２００はクライアント２１２とやり取り（対話）することができる。サービス２００は、通信リンク１０２を通じてＳＰ  ５０と通信する。次に、ＳＰ  ５０がクライアント２１２と交信する。クライアント２１２はＳＴＢ、デジタル・アシスタント、携帯電話、または通信リンク２１０を通じてＳＰと通信できるその他の通信デバイスとすることができる。コンテンツ変換２０４およびトランスポート変換１０８サービスは、トランスポートおよび通信機能を備え、ビジネス機能サービスはビジネス制御機能を備える。
【００２９】
図２は、サービス・プラットフォーム５０の好ましい実装例を示している。サービス２００は、インターネットまたは他のネットワークまたはネットワーク・オペレータからアクセス可能な通信チャネルを介してショッピング、チャット、およびその他のサービスを提供する。ネットワーク・オペレータは、ＳＰを使用して、これらのサービスにアクセスする。サービス・マネージャ２３８を含むビジネス機能２０６は、カルーセル・マネージャ２５４とやり取りして、サービス２００からコンテンツを取り出す。カルーセルは、ＳＰ  ５０からクライアントへのオーディオ／ビデオ／インタラクティブ・データ放送の反復ストリームを含む。カルーセル・マネージャ２５４、トランザクション・マネージャ２４２、およびサービス・マネージャ２３８は、放送カルーセルにコンテンツを挿入したり、削除したりする操作を制御する。サービス・コンテンツが取り出され、Ｈ２Ｏ  ２４８によりＳＰに適した形式に変換される。Ｈ２Ｏ  ２４８は、コンテンツ変換２０４の可能な一態様である。Ｈ２Ｏは、ＨＴＭＬコンテンツをＳＰ／クライアント読取り可能コンテンツに変換する。変換されたコンテンツは、データ・カルーセルにフォーマットされ、オープン・ストリーマ２５６により多重化され、クライアント２１２に放送される。クライアント２１２は、サービスとやり取りし、必要ならば、ＳＰおよびサービス２００と通信する。ＰＴＰの通信は、ＳＧＷ  ２４６を通る。ＳＧＷ  ２４６は、ＳＴＢ  ＤＡＴＰプロトコルをプラットフォーム・ビジネス・エージェント２２６とＨ２Ｏ  ２４８が期待し、認識するフォームに変換するトランスポート変換を実行する。負荷分散機能２３６は、ビジネス機能２０６、カルーセル・マネージャ２５４、およびＳＧＷ２４６とやり取りし、放送リンク２４１とＰＴＰ通信リンク２１０との間の最適な負荷分散を決定する。ビジネス機能２０６は、プラットフォーム・ビジネス・エージェント２２６とやり取りして、サービス２００とクライアント２１２の間のアクセスおよび情報交換を制御する。
【００３０】
ＳＰは、ネットワーク・オペレータによってのみ、かつネットワーク・オペレータの制御に従って視聴者情報をサービスに送らなければならないようにすることで、オペレータの重要な受信契約者プロファイル・データベースを隠す。受信契約者の識別情報を保護するために、サービスがトランザクション詳細をＳＰに送信するセッションで、抽象化されたユーザ識別子（つまり、セッション識別子）をサービスに送信する。ユーザ識別子はセッション固有のものである。家族が同じＳＴＢを使用する場合のように、クライアントと関連する複数のユーザ識別子がありえる。家族の各メンバおよび家庭ＳＴＢは、ＳＰ視聴者マネージャにより個別に視聴者識別子、カテゴリが割り当てられ、購入／映画要求／視聴習慣／などに関するトランザクションに関して追跡され、プロファイルが作成される。サービスは、セッション識別子を通じてのみクライアントすなわちＳＴＢ識別子を知る。ネットワーク・オペレータのみが、ＳＧＷを使って、セッション識別子を注文の履行に必要な視聴者情報詳細（氏名、住所、出荷情報など）とすることができる。オペレータ側でクレジット・カード集金またはその他のトランザクションの実行を望んでいない場合には、クレジット・カード番号またはその他の情報については例外とすることができる。
【００３１】
本発明を利用することで、ネットワーク・オペレータは視聴者情報データベースへのアクセスを制御し、ネットワーク・オペレータと特権情報（例えば、クレジット・カード番号、視聴者の実際の氏名、家の住所、電話番号、社会保険番号など）にアクセスできる契約を交わしているサービス・プロバイダのみを許可するようにできる。視聴者マネージャ２５２では、クライアント・デバイスに格納されている個人情報およびプロファイル情報にアクセスすることができ、またクライアント・デバイスまたはＳＰは視聴者プロファイルに格納されている視聴結果に基づいてユーザのお好みのコンテンツおよび購入習慣を選択することができる。クライアントまたはＳＰは、クライアント、ＳＧＷ、または他のＳＰコンポーネントによりクライアント・デバイス内でアクティブにされているビジネス・フィルタを介して視聴者プロファイリングに基づきユーザのお好みのコンテンツを選択する。
【００３２】
視聴者マネージャ２５２は、家庭／受信契約者／ＳＴＢ（またはその他のクライアント・デバイス）識別および認証を行うことができ、ＳＧＷおよび親制御機能をサポートする。視聴者マネージャ２５２は、ニックネームおよび／または個人識別番号（ＰＩＮ）、さらにクライアント・デバイス識別番号、トランザクション履歴、視聴者プロファイル、ニックネーム、および個人識別番号から得られる視聴者識別子を使用して単一ＳＴＢでの複数視聴者識別および登録認証をサポートする。視聴者マネージャ２５２は、観察されている累積ＴＶ視聴および購入習慣にリンクされているロギング、生成、および組み合わせ決定を通じて家庭および個人の視聴者プロファイリングを実行する。視聴者マネージャは、ＳＰとＳＴＢとの間の分散データ捕捉および格納をサポートしており、また双方向同期もサポートする。
【００３３】
視聴者マネージャ２５２では、すべてのＳＰアプリケーションの間で分散プロファイルを使用することができ、外部ＳＭＳ／ＣＲＭとの同期処理を行う。視聴者マネージャ２５２では、ＳＴＢまたはその他のクライアント・デバイスへの仮名すなわちニックネーム、フルネームおよびＰＩＮ格納を含む抽象視聴者識別子を使用した単一のＳＴＢすなわちクライアント・デバイスに対する複数の視聴者登録が可能である。ビジネス・エージェント２２６は、サービス・プロバイダと視聴者との間のやり取りを行うためのトランザクション・ビジネス規則を強制する。ネットワーク・オペレータによって定められているビジネス規則に基づき、またサービス・プロバイダとの契約に基づき、ビジネス・エージェント２２６はユーザ情報へのトランザクションおよびサービス・プロバイダによるアクセスを制御する。ビジネス・エージェント２２６は、サービス・プロバイダの契約と抽象セッション識別子に基づいてトランザクション中に聴取情報の補足、追加、置き換え、および削除を行う。
【００３４】
ビジネス・エージェント２２６は、受信契約者クライアントとサービス・プロバイダとの間のセッションを確立する。ビジネス・エージェント２２６は、視聴者情報詳細へのアクセスを制御し、サービス・プロバイダに提示される視聴者情報の取り込み、置き換え、および削除により視聴者情報を操作する。ビジネス・エージェント２２６は、デフォルト値を定め、ユーザ情報へのアクセスを制御する。ビジネス・エージェント２２６はさらに、トランザクション・ロギング、メッセージ・ロギング、負荷／トランザクション監視を実行する。
【００３５】
広告マネージャ２４４は、放送とＰＴＰリンクの両方とのインターフェイスを備え、２つの配信チャネル間の相補的な広告のやり取りを行えるようにする。例えば、放送（プッシュ）広告では、ＳＰＳを介して広告サービスへのＰＴＰ接続がトリガされ、ユーザは製品を購入したり、製品に関係する詳細な情報を取得したりすることができる。また、放送広告をＰＴＰコンテンツに入れて、放送サービスを利用できることをユーザに知らせることもできる（例えば、インフォマーシャル）。
【００３６】
場合によっては、クライアントが情報を要求しなくても、複数の製品または広告セグメントがクライアントにプッシュまたは放送される。クライアントに関連するビジネス・フィルタはＳＴＢに置かれるのが好ましいが、これを使用して、ユーザ・プロファイルに基づき視聴者にぴったりの広告を選択する。例えば、ＳＰは、料理番組のときに視聴者に放送する料理広告のグループをスケジュールすることができる。この広告グループには、イタリア料理、フランス料理、インド料理、およびドイツ料理に料理広告が含まれる。ＳＴＢすなわちクライアントと関連するまたはそこに配置されているビジネス・フィルタは、クライアントに提示する料理広告の種類が選択する。ユーザの好みおよびクライアント・プロファイルに基づき、クライアントまたはＳＰによって設定されたＳＴＢフィルタに応じて、ある視聴者はフランス料理の広告を見ることができるが、他の視聴者はインド料理の広告を見ることができる。
【００３７】
ＳＰは、Ｗｅｂ商取引インフラストラクチャを再利用することができる。ＳＰは、「通常の」ＨＴＭＬテンプレートをＳＰ対応形式で置き換える。ビジネス・エージェントは、ＳＧＷを通じてＳＴＢすなわちクライアントから注文要求を受け取る。ＳＧＷがメッセージをキューに入れると（ピークの管理のため）、一部の注文が遅延を伴ってビジネス・エージェントに届く（どのような形式の確認も必要としない注文であればこの方式を使用するのが好ましい）。ビジネス・エージェントは、視聴者情報を注文に追加する。注文／メッセージに記載されている視聴者情報の量と種類は、サービス／小売り契約に応じてビジネス規則により決められる。
【００３８】
通信はサービスと視聴者／クライアントとの間の交換なので、この情報はトランスポート・ストリーム毎にカルーセルが単一として別々のカルーセルに送信されるか、または既存のアプリケーション・カルーセルにまとめられる。その後、注文処理が進行するが、必要に応じて、ＳＰに備えられている「クレジット・カード精算」機能を使用することができる。確認が小売り業者から送り返されると、注文がリアルタイムでユーザに送り返されるか、電子メールでユーザに送信されるか、またはある種の顧客サービス申込フォームを通じてオンデマンドで入手できる。
【００３９】
ＳＰはさらに、オフライン視聴者識別（ＯＶＩ）を実行し、オンライン視聴者接続を確立することなく視聴者を識別または認証することができる。したがって、接続遅延（例えば、１０〜４０秒）を購入プロセス内の最も適切な場所に設定することができる。さらに、ストア・アンド・フォーワード機能とともに視聴者の識別も行える。ＯＶＩにより、オンとオフを間欠的に繰り返すクライアント・デバイスで注文／オペレーションの通信および完了を行える。
【００４０】
ＳＰで提供されるテレビ商取引サービスを視聴者が利用して、オンラインでなくても、品目を注文フォーム（ショッピング・カート）に追加することができるオフライン注文フォーム機能を備える。ストア・アンド・フォーワード機能は拡張性を高めるために重要である。ストア・アンド・フォーワードは、ピーク外の時間に転送するか、または単純に、トランザクションが開始した後所定の期間に負荷を散らすことができる。完全ストア・アンド・フォーワード・ソリューションが組み込まれており、いつでも任意のチャネルから応答を転送することができる。ストア・アンド・フォーワードは、機能強化された電子商取引、テレビ商取引トランザクションに使用できる。オフライン視聴者認証により、オフライン支払い選択を実行できる。オフライン支払い選択がＳＰに用意されており、購入プロセスを改善し、ストア・アンド・フォーワード機能をテレビ商取引／電子商取引とともに使用できるようになっている。
【００４１】
ＳＰは、状況に応じて標準のＷｅｂトランスポートを使用する、つまり、リアルタイム要求についてはＨＴＴＰを使用し、状況により非同期通信の場合にはＳＭＴＰを使用する（たとえば、業者報告、ストア・アンド・フォーワード）。オンラインになったときでも、ＳＰは短時間だけ接続し、データ（例えば、電子メール）にアクセスし、それからローカルでそのデータを使用することができる。ＳＰは、オペレータ視聴者データベースを保護するため、通常のＷｅｂ  ｃｏｏｋｉｅではなくセッション・ベースの識別子を用意している。ＳＰは、Ｗｅｂ  ｃｏｏｋｉｅの代わりに、ユーザを識別するためにサービスで使用できない、セッションでのみ使用できるセッション・ベースの識別子を備えている。サービス側では、ＳＧＷに視聴者情報を要求しなければならない（そして、ネットワーク・オペレータによって課金されなければならない）。
【００４２】
ＳＰは、オプションにより、視聴者に、いつ接続が行われたを通知し、またオプションにより、接続を維持する視聴者の承認を求めることもできる。ＳＰはさらに、視聴者の画面に「Ｃｏｎｎｅｃｔｉｏｎ  ＯＮ」というステータスを表示する。ＳＰは、効率が高ければＰＴＰ通信の放送用帯域幅を使用する。どの情報を放送に載せ、どの情報をＰＴＰ接続で送るかを決める負荷分散機能が用意されている。負荷分散決定は、データの緊急性、ＰＴＰ伝送リンクに対する放送の配信待ち時間、放送およびＰＴＰ経路に対する比較した負荷、およびデータを受け取る視聴者の数に基づいて行われる。一般に、多数の視聴者に送られるデータは放送で送られ、即座に送る必要のある少量のデータはＰＴＰリンクで送られる。ブロードバンド・チューナーを持たないＳＴＢは、ブロードバンドとともに送出されたＰＴＰメッセージを受信する。
【００４３】
ＳＰは、ＳＴＢおよび／またはクライアントのために視聴者プロファイリングに基づいて放送経路内の情報を選択的に受信するフィルタを備えており、特定のフィルタがＳＴＢ内に設定されている選択された視聴者のみが放送ストリームのコンテンツ（広告、情報、またはＡ／Ｖ番組など）をキャプチャするようになっている。これらのフィルタは、ＳＰの適応および選択的配信の側面を強化するものである。カルーセル・マネージャは、オープン・ストリーマ用のデータ・カルーセルを備えている。カルーセル・マネージャは、データのカルーセルをリアルタイムで管理する。カルーセル・マネージャは、オープン・ストリーマを補完する。カルーセル・マネージャは、サーバ・コンポーネントとＳＴＢクライアントＯＣＯＤライブラリを備える。カルーセル・サーバが、カルーセル・コンテンツへの追加、削除、または他の何らかの変更を行う要求をアプリケーションから受け取る。カルーセル・マネージャは、要求を受け取ると、それを単一トランザクションとして取り扱い、必要なすべてのデータを（通常は、ＨＴＴＰを介して）取得する。カルーセル・マネージャは、必要に応じて新しいカルーセル・インデックスまたはカルーセル・ディレクトリ・ファイルを生成する。カルーセル・マネージャは、更新されたカルーセル・ディレクトリをオープン・ストリーマに公開し、それによりオープン・ストリーマの放送優先度およびトラックを制御する。
【００４４】
オープン・ストリーマは、ネットワーク・オペレータがＳＰアプリケーションおよびデータをその放送網で放送するためのソフトウェア／ハードウェア製品である。オープン・ストリーマを使用することにより、ネットワーク・オペレータＡ／Ｖ番組と同時にＳＰデータおよびアプリケーションを送信することができる。オープン・ストリーマでは、データ・ストリームをリアルタイムで更新し、Ａ／Ｖコンテンツと一致するようにできる。例えば、ネットワーク・オペレータは、スポーツ・イベントのライブ放送とともにインタラクティブ・スポーツ・アプリケーションを放送することができる。オープン・ストリーマは、共通サーバＤＬＬおよび放送ストリーマの２つのコンポーネントを含む。アプリケーション・サーバ（例えば、天候アプリケーション・サーバ）またはＳＰ内のカルーセル・ビルダーは共通サーバＤＬＬを呼び出して、カルーセル・データを放送ストリーマに送信する。放送ストリーマは、次に、アプリケーションとＡ／Ｖデータの多重化（コード／データ比およびビット・レート要件に従って）を実行し、多重化されたそのデータを放送のため放送機器に送信する。
【００４５】
ＤＡＰ／ＤＡＴＰプロトコル方式の概要
本発明を利用すると、ＳＴＢとＳＰと関連するサービス・プロバイダとの間の通信が可能になる。ＤＡＴＰプロトコルは、エンティティがメッセージを他のエンティティに送信するともに配信保証のあるメッセージ・ベースのプロトコルである。ＳＴＢは、メッセージをＳＧＷに送信するときにはいつでも、メッセージがその最終の宛先に到達すると受領メッセージを受け取る（ＳＧＷまたはアプリケーション・サーバ）。アプリケーション・サーバがメッセージを処理すると、ＳＴＢとＳＧＷとのセッションがまだ開いている場合に、応答メッセージをＳＴＢに送信することができる。ＤＡＴＰメッセージ伝送段階の前にＤＡＴＰログイン段階にがあり、その後にＤＡＴＰセッションを確立するために必要なＤＡＴＰログアウト段階がある。ＤＡＴＰはセッション指向のプロトコルである。図９はＤＡＴＰセッションの単純な例を示している。
【００４６】
ＤＡＴＰは、同じＳＴＢトランスポート層接続の上の複数のセッションをサポートする。ＳＴＢクライアントは、ＳＧＷとのセッションが開いている間に、最初のセッションで使用されているのと同じＳＴＢトランスポート・リンク上で新しいセッションを開始するログイン・パケットを送信することができる。ＳＴＢクライアントとＳＧＷ内の両方のＤＡＴＰセッション管理モジュールにより、同じリンク上でさまざまなセッション・メッセージが多重化される。
【００４７】
ＤＡＴＰパケット・コンテンツの概要
ＤＡＴＰプロトコル・パケットは、固定サイズのヘッダ、可変サイズのデータ・ペイロード（ＤＡＭＬメッセージ）、およびトレーラを含む。ヘッダは、プロトコル・バージョン番号、パケット種別（ログイン／ログアウト・ハンドシェーク、Ｐｉｎｇ、データ、アクノリッジなど）、実際のパスポート情報（Ｒａｗ、ＴＣＰ／ＩＰ、ＵＤＰなど）、メッセージ・シーケンス番号（ＳＴＢまたはＳＧによって生成されるＤＡＴＰメッセージ番号）、サービス識別子（データを受信するためのサービスのＩＤ）の要素を含む。サービスＩＤは、ＤＡＴＰプロトコル内で定義されている８ビット識別子である。さらに、セッションＩＤ（セッションＩＤはハンドシェーク時にＳＧＷによって与えられる）、暗号化されたセッション用の暗号化フラグ、およびペイロード・データ・サイズもある。
【００４８】
ペイロード・データには、パケット種別によって、ハンドシェイク・パケット用のログイン／ログアウト情報、アクノリッジ・パケット用のアクノリッジ情報、データ／パケット用のデータ・ペイロードを含めることができる。トレーラには、ＤＡＴＰパケットの少なくとも３２ビットのＣＲＣチェックサムが含まれる。ＤＡＴＰプロトコルのバイト順はビッグ・エンディアンである。
【００４９】
パケット・フィールドの仕様
「プロトコル・バージョン」フィールドは、送信側エンティティによって使用されるバージョンのＤＡＴＰプロトコルである。これは、ＤＡＴＰパケットの最初のバイトである。ＤＡＴＰパケット形式は、ＤＡＴＰプロトコル・バージョン番号によって異なることがある。新しいバージョンのＤＡＴＰプロトコルが指定されている場合、このバージョン番号を繰り上げて、変更を反映させる。２つのエンティティの間のＤＡＴＰ通信では、両方のエンティティで利用できる最高バージョンのＤＡＴＰを使用する。バージョン・ネゴシエーションは、ログイン・プロセスの一部である。
【００５０】
「パケット種別情報」フィールドは、ＤＡＴＰパケットの第２バイトである。これは、どのような種類のＤＡＴＰパケットが送信されているかを示す。「ＳＴＢトランスポート情報」フィールドは、ＤＡＴＰパケットの第３バイトである。これは、ＳＴＢ側で使用するトランスポートに関する情報を提供する。これは、ＳＴＢネイティブ・トランスポート・プロトコル種別を表すフィールドの４つのＭＳＢビットであるＳＴＢ＿ｔｒａｎｓｐｏｒｔ＿ｉｎｆｏ［７．．４］、基本のトランスポートが信頼できものでるかどうかを示すビットであるが、ただしネイティブ・トランスポート・プロトコル種別の値がプロトコルの信頼性を適切に示すことができる場合であっても正しい値に設定されるビットであるＳＴＢ＿ｔｒａｎｓｐｏｒｔ＿ｉｎｆｏ［３］、ネイティブＳＴＢトランスポートのスピード・クラスを示すビットであるＳＴＢ＿ｔｒａｎｓｐｏｒｔ＿ｉｎｆｏ［２．．１］の３つのサブフィールドに分割される。
【００５１】
サービスＩＤは、ＤＡＴＰパケットの第４バイトであり、ＤＡＴＰパケットの宛先（ＳＴＢからＳＧＷへのパケット）または送信（ＳＧＷからＳＴＢへのパケット）ホストのＩＤを示す。「セッションＩＤ」は、ＤＡＴＰパケットの第２クオドレット（ダブル・ワード）である。これは、ＤＡＴＰパケットのセッションＩＤを示す。セッションＩＤ値は、ログイン・プロセスでＳＧＷにより生成される。ログイン・パケットでは、そのセッションＩＤフィールドが０に設定されている。
【００５２】
ＤＡＴＰでは、シーケンス番号はＤＡＴＰパケットの第３クオドレットの先頭ワードである。これは、ＤＡＴＰメッセージのシーケンス番号を示している。この番号は、対応するアクノリッジに送られたパケットからのＤＡＴＰ「トランザクション」を識別する番号である。メッセージ・シーケンス番号は、送信側エンティティにより生成され、ＤＡＴＰ接続の一方の側で送信されたメッセージ間でのみ一意である。つまり、ＳＴＢクライアントからＳＧＷに送信されるＤＡＴＰメッセージとＳＧＷからＳＴＢクライアントに送信されるメッセージは、同じシーケンス番号を持つが、それでも、２つ別々の「トランザクション」に対応する。
【００５３】
ＤＡＴＰでは、データ・サイズはＤＡＴＰパケットの第３クオドレットの第２のダブル・ワードである。これは、パケットのペイロード・データのサイズをバイト単位で示す。解釈により、このサイズは６４ＫＢに制限され、低速モデム・リンク、極端に雑音の多い通信チャネル、限られているＲＡＭメモリ・リソースなどローエンドＳＴＢに対するさまざまな共通要因に対応できる。ＤＡＴＰでは、暗号化フラグはＤＡＴＰパケットの第４クオドレットの先頭バイトである。ＤＡＴＰデータ・ペイロードは、１６バイトの固定サイズ・ヘッダの後の先頭バイトから始まり、ヘッダ・データ・サイズ・フィールドで指定されているデータ・ペイロードのサイズ分まで続く。ＤＡＴＰでは、ＣＲＣはデータ・ペイロードの後の第１クオドレットである。これは、ＤＡＴＰパケット全体（ヘッダを含む）の３２  ＣＲＣチェックサムの値を含む。
【００５４】
ＳＧＷとのＤＡＴＰセッションを開始するログイン・パケットがＳＴＢクライアントによって送信される。これは、ＳＴＢがＳＧＷに自己紹介するログイン・プロセスのネゴシエーションの第１段階を表す。ＳＧＷは、成功の場合にアクノリッジ・パケットでログイン要求に応答する。これは、ＤＡＴＰ接続のネゴシエーション可能属性を決定し、セッションＩＤを新規作成セッションに割り当てる。
【００５５】
ＳＧＷは、失敗の場合にネガティブ・アクノリッジ・パケットでログイン要求に応答する。このパケットはＳＴＢによって送信され、ＳＧＷとのＤＡＴＰセッションが閉じられる。ＳＧＷは、成功の場合にログアウト・アクノリッジ・パケットでログアウト要求に応答する。
【００５６】
ＳＧＷは、失敗の場合にログアウト・ネガティブ・アクノリッジ・パケットでログアウト要求に応答する。失敗の場合として、セッションＩＤが不明であったり、ＣＲＣが正しくない場合などがある。データ・パケットは、ＤＡＴＰ接続のどのエンティティでも送信できる。ＳＴＢクライアント・アプリケーションは、ＤＡＴＰデータ・パケットをアプリケーション・サーバに送信し、アプリケーション・サーバはＳＴＢに返答し、ＳＧＷからクライアントＳＴＢにデータ・パケットを強制的に送信させることができる。データ・パケットを受信したエンティティは、受信に成功した場合、データ・アクノリッジ・パケットで応答する。データ・パケットを受信したエンティティは、受信に成功しなかった場合、データ・ネガティブ・アクノリッジ・パケットで応答する。リモートＤＡＴＰエンティティから受信していない期間が続く場合に、ただし、この期間は設定可能であるとすると、他のリモート・エンティティがＤＡＴＰ  ｐｉｎｇパケットを送信して、応答を待つことによりＤＡＴＰリンクをテストすることができる。ｐｉｎｇパケットを受信したリモート・エンティティは、ｐｉｎｇパケットが正常に受信された場合に、Ｐｉｎｇアクノリッジ・パケットをリモート・ピアに送信しなければならない。ｐｉｎｇパケットを受信したリモート・エンティティは、ｐｉｎｇパケットが正常に受信されなかった場合に、Ｐｉｎｇネガティブ・アクノリッジ・パケットをリモート・ピアに送信しなければならない。失敗の場合としては、セッションＩＤが不明であったり、ＣＲＣが正しくない場合などがある。
【００５７】
図３に、ＤＡＴＰ／ＳＧＷのアーキテクチャが示されている。多数のＳＰとＳＴＢクライアント・アプリケーションに対する一般的ニーズは、ＤＡＴＰアーキクチャでアプリケーションに固有であるという以上にトランスポートに固有のものである。ＤＡＴＰは、暗号化、データ圧縮、ＨＴＴＰルーティング、および後述の他の多数の機能を実行する。ＤＡＴＰアプリケーション・バックエンド・フレームワークのアーキテクチャが図３に示されている。ＤＡＴＰは、Ｏコード・アプリケーション・レベルのストア・アンド・フォーワード機能での軽量ＨＴＴＰ（ＬＨＴＴＰ）、ＳＴＢ識別（ＯｐｅｎＴＶ中央レジストリ［ＯＣＲ］）、および他の多数の機能を備える。これらの機能は、ＤＡＴＰプロトコルの一部としてまたはその上に実装される。
【００５８】
図３に示されているように、ＳＧＷサーバ１０１８はＳＴＢ  １００８とＦｅｔｃｈＭａｉｌサーバ１０２６などのさまざまなアプリケーション・サーバ１０２６、１０２８、１０３０および１０３２との間に堅牢な通信リンクを構築する。ＳＧＷ  １０１８は、ＳＴＢとアプリケーション・サービスとの間で行き来する要求のルートを決定する。ＳＧＷはクライアント／ＳＴＢ  １０１８からＤＡＴＰパケットを受信し、適切なアプリケーション・サーバとコンタクトをとり、ＴＣＰ／ＩＰ接続でデータをアプリケーション・サーバに送信／受信する。ＳＧＷにより、サード・パーティ製サーバまたは、ＦｅｔｃｈＭａｉｌサーバ１０２６などのＳＰ固有のサーバでＳＴＢにメッセージを送信することができる。
【００５９】
図４に示されているように、ＳＴＢ／クライアント・スタック・アーキテクチャは、複数のモジュールだけでなく、アプリケーションとネイティブＳＴＢ／クライアント・トランスポートとの間の、特別な層であるメッセージ・マネージャ１１０４も備える。ＬＨＴＴＰ  ＡＰＩ  １１０６およびストア・アンド・フォーワードＡＰＩ  １１０８などのＳＴＢアプリケーションに対するＡＰＩが用意されている。サーバは、非同期バージョンのＰＡＬ層を使用し、スレッドのプールとプロセス絶縁手法を実装している。
【００６０】
好ましい実施形態では、ＤＡＴＰは大きなメッセージ・サイズに対応する一方で、配信信頼性を保証し、ＳＴＢ内の組み込み環境の制約から生じる複雑なメモリ問題を解決する。ＤＡＴＰメッセージ・サイズを増やすために、大きなメッセージを小さなセクションに分割して、送信、順序変更を行い、再構築されたＤＡＴＰメッセージで配信する。バイナリ・エラー率（ＢＥＲ）１０−64の信頼性のないリンクでは、６４ＫＢのメッセージにエラーが発生する確率はおおよそ７％（メッセージ１４通あたり１通）である。６４ＫＢの転送に２４００ビット／秒のモデムで５分ちょっと要することがわかれば、ＤＡＴＰは、ビット群のうちの１つが破損しているからといってさらに５分かけて同じメッセージを再送することを回避できる。再送を回避するには、ＤＡＴＰの以下の実装ガイドラインに従うのが好ましい。
【００６１】
好ましい実施形態では、大きなメッセージ、つまり６４Ｋｂを超えるメッセージをより小さなＤＡＴＰパケットに断片化する。小さな断片のしきい値を６４Ｋｂ未満とすることができる。各ＤＡＴＰ断片は個別にアクノリッジされる。図８に示されているように、ＤＡＴＰはメッセージ順序番号と、その順序番号を最後に使用した時刻を追跡する。「最近」使用された順序番号のあるＤＡＴＰメッセージは「すでに受信されている」ものとして拒絶される。このポリシーを実装するために、ＤＡＴＰホストは、各順序番号のタイムスタンプとともに最近使用した順序番号のスライディング・ウィンドウを保持する。古い順序番号は、（ｈｏｓｔ＿ｍａｘ＿ｒｅｔｒｙ＋１）＊ｈｏｓｔ＿ｔｉｍｅｏｕｔよりも古い場合にリモート・ホストのウィンドウから削除される。好ましい実施形態では、タイムアウト値はプログラム可能であり、必要な任意の値に設定することができる。
【００６２】
拒絶ウィンドウでは、現在時刻から始まるある時間枠内で受信したパケットの順序番号を追跡する。ＤＡＴＰコア層がパケットを受信すると、その順序番号が拒絶ウィンドウ内で検索される。順序番号がそのウィンドウ内で見つかれば、破棄される、つまり順序番号と関連するパケットまたは断片は無視される。パケットの順序番号がウィンドウ内に見つからない場合、新しい順序番号がウィンドウに追加される。ウィンドウすなわち「拒絶ウィンドウ」は定期的にクリーニングされ、通信リンクで使用された時間に応じてある日付よりも古いパケット番号が除去される。パケット拒絶ウィンドウ・アルゴリズムは、再送／タイムアウト・ベースの信頼できるメッセージ指向トランスポート・プロトコルで頻繁に発生する同一パケットを何回も受信するという事態を効率よく防止することができる。
【００６３】
ＤＡＴＰメッセージはリモート・ホスト・メモリ条件に基づいて送信される。ＤＡＴＰメッセージのアクノリッジされた各パケットには、受信側エンティティの現在のメモリ状態を示すメモリ使用可能フィールドが含まれる。ＤＡＴＰを利用してメッセージをピアに送信する場合、リモート・エンティティはまず、ＤＡＴＰメッセージのサイズが受信側エンティティで利用できるメモリよりも小さいかどうかを調べる。受信側エンティティにメッセージを受け取れる十分なメモリがあれば、ＤＡＴＰメッセージの断片が受信側ホストに送信される。メッセージを受信すると、受信側ホストはメッセージの受信に関するアクノリッジを送る。そうでない場合、送信側ホストは制御パケットを受信側ホストに送信し、リモートまたは受信側ホストのメモリを利用できるかどうかを問い合わせる。メッセージの一部のみを保持する利用可能なメモリに基づく部分的配信も必要に応じて実装できる。この場合、部分的メッセージが完了までキャッシュされている。制御パケットは、リモート・エンティティ内に十分なメモリが確保されるか、メッセージ送信再試行最大回数を超えるまで送信される。最大再試行回数を超え、それでも受信側ホストにメッセージ送信を完了できるだけの十分なメモリがない場合、メッセージ送信は失敗する（部分的メッセージ配信が許可されていない限り）。
【００６４】
ＤＡＴＰプロトコルはメッセージ・ベースのプロトコルであり、エンティティが配信保証とともにメッセージを他のエンティティに送信する。ＳＴＢは、メッセージをサービス・ゲートウェイに送信するときにはいつでも、メッセージがその最終の宛先（サービス・ゲートウェイ自体またはアプリケーション・サーバ）に到達するとアクノリッジ・メッセージを受け取る。アプリケーション・サーバがメッセージを処理すると、ＳＴＢとサービス・ゲートウェイとのＳＴＢセッションがまだ開いている場合に、応答メッセージをＳＴＢに送信することができる。ＤＡＴＰメッセージ伝送段階の前にＤＡＴＰログイン段階があり、その後にＤＡＴＰセッションを確立するために必要なＤＡＴＰログアウト段階がある。ＤＡＴＰを通じて送信されるメッセージは、独立に送信され、アクノリッジされる高々ＭＴＵ（Ｍｅｄｉｕｍ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｕｎｉｔ）バイトのＤＡＴＰパケットに断片化されることに留意されたい。そこで、ＤＡＴＰメッセージは、ＤＡＴＰエンティティにより物理的に管理可能な大きさにできる。図９は、ＤＡＴＰセッションの単純な例を示している。
【００６５】
ＤＡＴＰは、同じＳＴＢトランスポート層接続の上の複数のセッションをサポートする。ＳＴＢクライアントは、サービス・ゲートウェイとのセッションが開いている間に、最初のセッションで使用しているのとまったく同じＳＴＢトランスポート・リンク上で新しいセッションを開始するログイン・パケットを送信することができる。ＳＴＢクライアントとサービス・ゲートウェイ内の両方のＤＡＴＰセッション管理モジュールが、同じリンク上でさまざまなセッション・メッセージを多重化する役割を持つ。
【００６６】
大きなＤＡＴＰメッセージ送信をサポートするために、ＤＡＴＰはパケット断片化／再構築方式を利用する。大きなメッセージが高々ＭＴＵサイズの小さなＤＡＴＰパケットに断片化される。各ホストは、ＭＴＵサイズが設定され、各ＤＡＴＰエンティティには異なるＭＴＵサイズを設定できる。ＤＡＴＰメッセージの各断片（ＤＡＴＰパケット）は個別にアクノリッジされる。
【００６７】
「最近」使用されたシーケンス番号のあるＤＡＴＰメッセージは拒絶され、「同一断片の繰り返し受信」タイプの競合条件が回避される。このポリシーを実現するために、ＤＡＴＰホストは、ウィンドウ内の各エントリのタイムスタンプとともに最近使用した（シーケンス番号、断片ＩＤ）のスライディング・ウィンドウを保持する。古い（シーケンス番号、断片ＩＤ）エントリは、（ｈｏｓｔ＿ｍａｘ＿ｒｅｔｒｙ＋１）＊ｈｏｓｔ＿ｔｉｍｅｏｕｔよりも古い場合にＤＡＴＰホストのウィンドウから削除される。
【００６８】
デフォルトのＤＡＴＰ断片サイズ（つまり、ＭＴＵサイズ）は４ＫＢに制限されており、メモリ断片化が問題になる制約されたＳＴＢ環境に対応できる。断片サイズは、アプリケーション側で、最大６４ＫＢまで増やすことができる。
【００６９】
ＤＡＴＰは、ＤＡＴＰメッセージ１つあたり最大６５５３６個の断片をサポートする。これにより、理論上最大メッセージ・サイズを４Ｇとすることができる。ＤＡＴＰメッセージの最初の断片は、断片が新しいメッセージの最初の断片であり、その断片識別（ＩＤ）フィールドがこのＤＡＴＰメッセージを構成する断片の数に設定されていることを示すマーカーとなっている。不完全なＤＡＴＰメッセージは、（ｈｏｓｔ＿ｍａｘ＿ｒｅｔｒｙ＋１）＊ｈｏｓｔ＿ｔｉｍｅｏｕｔ経過後にリモート・エンティティにより破棄されなければならない。
【００７０】
ＤＡＴＰは、アプリケーションが機密性の高いデータをそれぞれのアプリケーション・サーバに送り返せる暗号化機能を備える。トランスポート・レベルに暗号化を実装することで、ＳＴＢすなわちクライアントの処理能力の低い環境で暗号化を実装するという問題に対処している。そのため、慎重に設計された暗号化方式と好ましいＤＡＴＰセキュアＡＰＩにより暗号化に取り組んでいる。セキュリティ／暗号化はセッション・レベルで実装される。アプリケーションでは、ＤＡＴＰセキュアＡＰＩを使用してセキュア・セッションを開く。ＤＡＴＰ暗号化パラメータについては、セッション・ログイン時にネゴシエーションが行われる。セキュア・セッション・ネゴシエーションには少なくとも、標準ＤＡＴＰログイン段階と鍵ネゴシエーション段階の２つの段階が用意される。
【００７１】
以下では鍵ネゴシエーション段階の主要ステップについて簡単に説明する。ＤＡＴＰサーバは、公開鍵ｓｅｒｖｅｒ＿ｅｐｋをクライアントすなわちＳＴＢに送信する。ＤＡＴＰは、Ｒｉｖｅｓｔ、Ｓｈａｍｉｒ、およびＡｄｌｅｍａｎ（公開鍵暗号化技術）ＲＳＡ（他のものも使用できる）を使用するのが好ましい。ＤＡＴＰでは、ｅ＝３以上となるようにＲＳＡ指数ｓｅｒｖｅｒ＿ｅｐｋ＝（ｅ，ｎ）を選択し、確実なセキュリティ・レベル（セキュリティはｎによって決まる）が維持されるようにする。ＲＳＡでメッセージを暗号化するために、ＳＴＢで（ｍe）ｍｏｄ  ｎを計算する必要がある。「ｅ」が小さいと累乗段階が小さくなり、暗号化されたメッセージを高速に実行できる。ＳＴＢすなわちクライアントは、その乱数発生器をシステム時間とＯコード層（例：現在のビデオ・フレームなど）に用意されているランダム・ソースで初期化する。ＳＴＢ／クライアントは、ＳＴＢ／クライアント秘密鍵（ｓｔｂ＿ｓｋ）を選択する。ＳＴＢは、ＲＳＡを使って、秘密鍵ｓｔｂ＿ｓｋをｓｅｒｖｅｒ＿ｅｐｋで暗号化する。ＳＴＢは、暗号化された秘密鍵ｓｔｂ＿ｓｋをＤＡＴＰサーバに送信する。ＤＡＴＰサーバは、暗号化されているｓｔｂ＿ｓｋをその秘密鍵ｓｅｒｖｅｒ＿ｄｐｋで暗号解読する。
【００７２】
ＤＡＴＰサーバ（例えばＳＧＷ）は、乱数発生器を初期化し、サーバ秘密鍵ｓｅｒｖｅｒ＿ｓｋを選択する。ＤＡＴＰサーバ（例えばＳＧＷ）は、秘密鍵暗号化方式を使用してｓｔｂ＿ｓｋでｓｅｒｖｅｒ＿ｓｋを暗号化する。ＤＡＴＰサーバは、暗号化されたｓｅｒｖｅｒ＿ｓｋをＤＡＴＰサーバに送信する。ＳＴＢは、暗号化されているｓｅｒｖｅｒ＿ｓｋをその秘密鍵ｓｔｂ＿ｓｋで解読する。鍵の交換が正常に行われると、互いの秘密鍵を使用してＤＡＴＰを介して２つのエンティティの間で秘密暗号化データを交換することができる。好ましい実施形態では、ＤＡＴＰサーバ認証ステップをプロトコルに追加し、鍵交換方式を強化し、「マン・イン・ザミドル」攻撃から防御することができる。したがって、ＤＡＴＰスタックに署名し、認証証明証を管理する機能がＤＡＴＰプロトコルに用意されている。
【００７３】
ＳＧＷとの通信時間を短縮するために、サーバの公開鍵をスタック内に埋め込んで、ＳＴＢ秘密鍵の暗号化をオフラインで実行できるようにすることが好ましい。これにより、ＤＡＴＰサーバがＳＴＢすなわちクライアントにより使用されるサーバ公開鍵を知っている必要があるため、新しい鍵管理問題が生じることになる。セキュア・セッションで送信されるメッセージは、断片レベルで暗号化するのが好ましい。したがって、ＤＡＴＰメッセージの個々の断片が独立に暗号化されるということである。
【００７４】
ＤＡＴＰセキュアＡＰＩが用意されており、これにより、セキュアＤＡＴＰセッションで暗号化されていないメッセージを送信し、ＳＰアプリケーション側では、セキュア・セッションで送信された非機密データを暗号化しないことによりＣＰＵサイクルを節約することができる。この方法は、Ｍｏｔｏｒｏｌａ  ＤＣＴ  ２０００などの処理能力が限られているクライアントすなわちＳＴＢの場合に役立つ。
【００７５】
セキュア・セッションがＤＡＴＰサーバとＤＡＴＰクライアントすなわちＳＴＢとの間で確立されると、クライアント／ＳＴＢによってアプリケーション・サーバに送信されたメッセージは、最初にＤＡＴＰサーバ（例えばＳＧＷ）内で解読され、その後セキュア・ソケット層（ＳＳＬ）接続を使用してアプリケーション・サーバに転送される。暗号化層は、Ｏコード開発者だけでなくアプリケーション・サーバ開発者からも利用できる暗号化ライブラリに基づいている。このライブラリはアプリケーションから使用し、アプリケーション・レベルで暗号化を管理することができる。この機能は、銀行業務などの重要アプリケーションにおけるセキュリティのため実行されるエンドツーエンドの暗号化を管理する場合に役立つ。
【００７６】
ほとんどのＳＴＢおよびクライアントで利用可能とされているような低速な（２４００〜３３６００ｂｐｓ）リンク上でのデータ圧縮が用意されており、回線の全スループットを高めるために圧縮データを送信することが望ましい。場合によっては、モデム・データ圧縮がＯＳＩリンク・レベルで利用できることもある。上位プロトコルには、ペイロードを圧縮しても目立った利益があるわけではない。多数のクライアント／ＳＴＢモデムはリンク・レベルでの圧縮機能を持たず、したがって、上位プロトコルに圧縮機能を設ける。本発明はＤＡＴＰサーバ・レベルのデータ圧縮機能を提示する。
【００７７】
ＳＴＢすなわちクライアントのプロセッサがほとんどの圧縮アルゴリズムで必要としている効率のよいパターン探索（またはその他のＣＰＵを酷使するオペレーション）を実行する能力を欠いているという問題がある。しかし、圧縮解除は比較的容易なタスクであり、圧縮解除ＡＰＩがＯコード・レベルでクライアント／ＳＴＢに用意されている。これらの考慮事項に基づいて、ＤＡＴＰの圧縮サポートは非対称的である、つまり、ＤＡＴＰサーバからＳＴＢすなわちクライアントへのダウンリンクのみを標準ＳＰ圧縮ツールを使用して圧縮するのが好ましい。
【００７８】
圧縮されたＤＡＴＰパケットは、ペイロード・データが圧縮されていることを示す「データ圧縮済み」フラグをパケット・ヘッダ内に立てる。パケット・ヘッダは圧縮されない。圧縮および圧縮解除では、標準装備のＳＰ圧縮および圧縮解除ツールおよびＡＰＩを使用する。ＤＡＴＰパケット・サイズは、圧縮されたペイロードのサイズを示す。ペイロードの圧縮解除されたサイズは、ペイロードの圧縮ヘッダ内に示される。ＤＡＴＰメッセージの圧縮は、断片レベルで実行される。ＤＡＴＰメッセージの各ＤＡＴＰパケットは個別に圧縮される。これは、ＤＡＴＰメッセージ断片が受信時に必ずしも連続して格納されるわけではないため好ましく、したがって、ＤＡＴＰは各断片を別々に圧縮解除することが好ましい。各ＤＡＴＰ断片は独立に圧縮されるため、独立の圧縮解除が可能である。ＤＡＴＰ  ＳＴＢスタックとＤＡＴＰアプリケーション・サーバＡＰＩでは、ダウンリンクでのデータ圧縮を禁止または有効にできる。この機能により、アプリケーション・サーバは、高速な放送チャンネルを使用してクライアントまたはＳＴＢに大量のデータを転送することと、ＳＰ帯域幅全体を節約する放送チャンネルを通じてクライアントまたはＳＴＢの集まりにマルチキャスト・データを送信することという少なくとも２つの重要な機能を備えることができる。
【００７９】
ＤＡＴＰサーバは、設定可能な数の放送ストリームを管理するオープン・ストリーマ・アプリケーション・サーバ・モジュールを備える。これらのストリームを使用して、大量のデータ・チャンクだけでなくマルチキャスト・データをクライアントおよび／またはＳＴＢに送信する。マルチキャスト機能は、放送でルーティングを行う重要な機能として用意されており、それは、アプリケーション・サーバ側で各ＳＴＢを個別に扱わずにＳＴＢのグループにデータを送信することができるためである。ＤＡＴＰのマルチキャスト・サポートでは、信頼できないＤＡＴＰパケットが送られる。ＳＰは、セッション識別子のマルチキャスト・グループのリストを保持し、ブロードキャスト・チューナーが利用できないＳＴＢすなわちクライアントが多数のマルチキャスト・グループのメンバである場合を扱う。
【００８０】
ＤＡＴＰネーム・サービス（ＤＮＳ）は、アプリケーション・サーバ名とサービス識別子との間のマッピングを定めるものである。よく知られているサービスではサービス識別子を予約しているが、多数のユーザ定義サービス識別子が利用でき、さまざまなアプリケーションで使用することができる。ＳＴＢまたはＯコード・アプリケーションへのサービス識別子のハードコーディングを避けるために、アプリケーション側で名前レゾリューション段階の後に名前でサービスを参照する機能を備える。この方法でアプリケーションは、ＳＧＷ設定ファイルにあまり依存しなくなる。
【００８１】
ＤＮＳ機能をＤＡＴＰクライアントに提供する方法について以下に説明する。ＤＮＳは、ＤＡＴＰプロトコルの観点からは別のサービスとみなされる。特定のサービス識別子がＤＮＳサービス用に予約されている。ＤＮＳサービスのホストはＳＧＷ内にあるか、またはＳＰまたはＳＴＢまたは他のクライアントの別のところにあってもよい。ＤＡＴＰクライアントは、アプリケーション・サーバの名前を解決するための単純なＡＰＩを備えている。主呼び出し（ｄａｔｐ＿ｇｅｔ＿ａｓｉｄ＿ｂｙ＿ｎａｍｅ（ａｓ＿ｎａｍｅ））が要求番号を同期して返すのが好ましい。非同期通知は、成功した場合には、アプリケーション・サーバ識別子を含む名前レゾリューションのステータスを返す。パフォーマンスを著しく損なうことのない同時実行の名前レゾリューションも可能である。ユーザは、それぞれの要求にタグ付けされている要求識別子に基づいてネーム・サーバ通知をディスパッチすることができる。アプリケーション・サーバの名前パラメータを現在のＤＮＳ設定ファイルに追加する。異なるサービス識別子に対して同じ名前を使用しない。冗長性をもたらすか、または拡張性問題に対処するために、１つのサービス識別子について複数のマシンを登録することができる。
【００８２】
好ましい実装では、ＤＮＳは定義しなければならないディレクトリ・サービスのインスタンスとみなされる。ＤＮＳ要求パケット形式は、クエリ種別（クエリの種類を示す（例えばＤＮＳクエリに対しては０））、クエリ・タグ（ディレクトリ・サービス応答と照合するユーザ提供タグ）、クエリ・データ（クエリー・オペレーションを実行するために使用するデータ（通常は、ＤＮＳのサービスの名前））の各フィールドを含む。ＤＮＳ応答パケット形式は、応答種別（応答の種類を示す（ＤＮＳ  ｒｅｓｏｌｖｅ  ＯＫには０））、応答タグ（その応答を生成したクエリ・タグと同じ）、および応答データ（クエリの応答データ（通常は、ＤＮＳのサービスのＩＤ）の各フィールドを含む。
【００８３】
ＤＡＴＰの他の実施形態では、すべてのＤＡＴＰクライアントがモデム・ラックの背後にあると想定され、接続されているクライアント毎に、モデム・ラック・ターミナル・サーバがＳＧＷとの専用ＴＣＰ／ＩＰ接続を開き、所定のＳＴＢから受け取ったものをこのＴＣＰ接続に転送する。ＴＣＰ／ＩＰがサポートされていないが、ユーザ・データグラム・プロトコル（ＵＤＰ）がサポートされている古い世代のケーブル・ボックスで配備が可能な場合、ＤＡＴＰサーバ（例えば、ＳＧＷ）はＵＤＰポート上で着信を待つことができる。ＵＤＰは以下のようにサポートされている。サーバでは、ＵＤＰ接続を取り扱うように新しいｄａｔｐ＿ｓｏｃｋｅｔ＿ｌｉｓｔｅｎｅｒクラスが作成される。ソケット・タイプ抽象層が作成され、ＵＤＰソケット（ＰＡＬ＿ｕｄｐ＿ｓｏｃｋｅｔ）に対応できるようになる。
【００８４】
ＵＤＰ接続は、次のように処理される。ＵＤＰ＿ｌｉｓｔｅｎｅｒは、新しい接続要求ダイアグラムを読み込んで、新しいＡＬ＿ｕｄｐ＿ｓｏｃｋｅｔを作成する。ＵＤＰ＿ｌｉｓｔｎｅｒは接続に応答し、新規作成されたＰＡＬ＿ｕｄｐ＿ｓｏｃｋｅｔを使用してそのダイアグラムを送信する。ＵＤＰ＿ｌｉｓｔｅｎｅｒは、新しいセッション・マネージャ・スレッドを作成し、新規作成ＰＡＬ＿ｕｄｐ＿ｓｏｃｋｅｔを属性として渡す。新しいセッション・マネージャは、提供されているＰＡＬ＿ｕｄｐ＿ｓｏｃｋｅｔとともにｐａｌ＿ｕｄｐ＿ｓｏｃｋｅｔ＿ｓｅｎｄを使用してＤＡＴＰクライアントと直接交信する。データグラムのリモート・アドレスを指定する必要はないことに留意されたい。接続要求に応答している間にＵＤＰ＿ｌｉｓｔｅｎｅｒによりすでに設定されている。
【００８５】
クライアント側では、すでに指定されているｓｔｂ＿ｔｒａｎｓｐｏｒｔ  ＡＰＩをターゲットのＳＴＢすなわちクライアントで利用できる何らかのＵＤＰ  ＡＰＩに実装するＵＤＰ  ｓｔｂ＿ｔｒａｎｓｐｏｒｔモジュールが作成される。このＵＤＰ  ｓｔｂ＿ｔｒａｎｓｐｏｒｔは、ＳＧＷ  ＵＤＰリスナー・ポートに接続要求データグラムを送信し、ＳＴＢトランスポート・リンクが稼働していることをＤＡＴＰコアに通知する前にＳＧＷから応答を受け取るまで待機する。後のデータグラムは、ＳＧＷからの接続要求応答で指定されたポートを使用して送信される。
【００８６】
Ｗｅｂサーバをフロントエンドとして使用する標準アプリケーション・サーバとのＳＧＷ用のインターフェイスを提供するためＨＴＴＰルーティングが用意される。この場合、ＤＡＴＰは、アプリケーション・サーバ開発者に提供される標準ＤＡＴＰアプリケーション・サーバＡＰＩを使用せず、その代わりに、ＨＴＴＰ  ＰＯＳＴ（ＨＴＴＰＰ）メカニズムを使用してＤＡＴＰメッセージをＷｅｂサーバのフロントエンドに転送することによりこれらのアプリケーション・サーバと直接インターフェイスする。この方式では、クライアントおよび／またはＳＴＢアプリケーションは、ＨＴＴＰサーバと交信していることを意識しないＤＡＴＰ  ＡＰＩを使用する。
【００８７】
ＨＴＴＰＰをサポートするために、ＤＡＴＰアプリケーション・サーバ・タイプが設けられている。このタイプのサーバはすべて、ポストＵＲＬを指定するためにネーム・サーバ設定ファイル内に特別なエントリを設ける。アプリケーション・サーバの通信モジュールでは、ターゲットのサーバ・タイプに応じてＨＴＴＰサーバにＤＡＴＰメッセージをポストすることができる。このモジュールは、アプリケーション・サーバ（ＡＳ）通信マネージャと２つのＡＳデータ送信側に分けるのが好ましい。一方のＡＳデータ送信側がデータをＤＡＴＰ  ＡＳ  ＡＰＩ互換アプリケーション・サーバに送信し、他方の送信側がデータをＨＴＴＰベースのアプリケーション・サーバに送信する。ＨＴＴＰサーバから受信したＨＴＴＰ  ｃｏｏｋｉｅは、ＳＧＷに格納され、必要に応じてＨＴＴＰサーバに再送される。セキュアＤＡＴＰセッションで受信したＤＡＴＰメッセージは、ＨＴＴＰＳを使用してＨＴＴＰサーバに転送される。ＳＧＷがＳＰインタラクティブ・サービスへのアクセスを制御し、接続されているクライアントのＩＤに対しアプリケーション・サーバからアクセスするための手段を提供するため、ＤＡＴＰログインおよびログアウトはアノニマスでないのが好ましい。
【００８８】
ＤＡＴＰの一部としてのＳＴＢすなわちクライアント識別について以下で詳述する。ＤＡＴＰスタックには、ＳＴＢすなわちクライアント依存の固有ハードウェア識別子（ＨＩＤ）が含まれる。ＳＴＢの場合、このハードウェア識別子はＳＴＢ／ネットワーク依存のＳＴＢトランスポート層から取得する。ＨＩＤ形式は可変長文字列である。指定されたネットワークのＨＩＤは、ＨＩＤリストに格納される。ネットワーク・オペレータは、ＳＰを介し、ＡＰＩを使用して顧客データベースからＨＩＤリストを更新する。直接ネットワーク・オペレータ受信契約者データベースとインターフェイスできない場合には、ＳＰは構造のないふつうのファイルから受信契約者情報（ＨＩＤを含む）をインポートする。
【００８９】
ＤＡＴＰセッションを確立するために、ＳＴＢすなわちクライアントＤＡＴＰスタックは、ＤＡＴＰログイン・パケット内にＨＩＤを格納する。ＳＧＷは、中央リポジトリを使ってＨＩＤが有効なものかどうかを確認する。中央リポジトリがＨＩＤをクリアすると、ＳＴＢスタックへのアクセスが許可される。ＨＩＤにより、ＳＧＷは接続されているＳＴＢすなわちクライアントのＩＤを判別することができる。ＨＴＴＰ  ｃｏｏｋｉｅの場合のように、ＨＩＤはリモートＳＴＢすなわちクライアントに対し「強い」認証を行わない。したがって、リモート・ユーザの正式な認証は、リモート・ピアのより厳格な認証を必要とするアプリケーション側により実行される。
【００９０】
ＤＡＴＰでは、リモートＨＴＴＰサーバとやり取りすることができるようにするＨＴＴＰ機能のＬＨＴＴＰをＯコード・アプリケーション開発者から利用できるようにしている。ＬＨＴＴＰは、Ｗｅｂ風のＨＴＴＰベースのアプリケーションを開発することを目的として用意されている。ＬＨＴＴＰは、現行のＨ２Ｏ戦略を補完するものであり、クライアント、ネットワーク・オペレータ、およびサービスの間の裏チャネル通信に使用するＯＳ独立の簡素化されたＨＴＴＰインターフェイスを備えている。ＬＨＴＴＰインターフェイスは、ＤＡＴＰスタックに基づいており、ＨＴＴＰ要求をＤＡＴＰメッセージにカプセル化している。特別なＤＡＴＰサービス識別子がこのサービス識別子で受信されるＬＨＴＴＰ層とＤＡＴＰメッセージに割り当てられ、ＳＧＷ内の特定のＬＨＴＴＰデータ送信側を使用して宛先ＨＴＴＰサーバへのルートが設定される。
【００９１】
ＧＥＴおよびＰＯＳＴコマンドを含む、限られた数のＨＴＴＰコマンドをサポートするのが好ましい。追加ＨＴＴＰコマンドをＬＨＴＴＰに追加することもできる。ＬＨＴＴＰ要求は、ＳＧＷで標準ＨＴＴＰ要求に変換される。ＨＴＴＰ要求は、ＳＧＷがＬＨＴＴＰクライアントの代わりに生成する。ｃｏｏｋｉｅがＬＨＴＴＰクライアントに転送される。ＳＧＷは、ｃｏｏｋｉｅをキャッシュし、セッションＩＤ変換テーブルへのｃｏｏｋｉｅを保持する。ＤＮＳ応答ＨＩＤでは、この変換テーブルを使用してＨＴＴＰサーバからの要求を解決する。ＨＴＴＰサーバは、ＨＩＤを使用して、中央レジストリ・サーバからユーザ情報を抽出するのが好ましい。ＬＨＴＴＰはさらに、セキュアＡＰＩ、ＬＨＴＴＰＳを備えている。このＡＰＩは、ＤＡＴＰ暗号化層に基づく。ＬＨＴＴＰＳ要求は、ＳＧＷでＨＴＴＰＳ要求に自動的に変換される。
【００９２】
ＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）ルーティングつまり電子メールによる単純なメッセージ転送がＳＧＷとアプリケーション・サーバとの間のインターフェイスに用意されている。このインターフェイスは、アプリケーションがＤＡＴＰメッセージをＳＭＴＰベースのアプリケーション・サーバに送信するリアルタイムでないトランザクションに使用することができ、またこれらのメッセージは電子メールによりターゲットのアプリケーション・サーバに転送される。
【００９３】
ＳＭＴＰルーティングをサポートするために、ＤＡＴＰアプリケーション・サーバ・タイプがＳＭＴＰアプリケーション・サーバ用に作成される。このタイプのサーバは、ネーム・サーバの設定ファイルに特別なエントリを持ち、これにより、電子メール・アドレスだけでなく転送されたメッセージの電子メール件名も指定する。アプリケーション・サーバの通信モジュールは、ターゲットのサーバ・タイプに応じてＳＭＴＰベースのアプリケーション・サーバにＤＡＴＰメッセージをポストする。ＳＭＴＰアプリケーション・サーバのデータ送信側モジュールを用意して、このタイプのトランザクションをサポートする。ＳＭＴＰアプリケーション・サーバに送信されたＤＡＴＰメッセージは、ＭＩＭＥ（多目的インターネット・メール拡張仕様）でエンコードされた電子メールに添付される。メッセージの最初の部分には、送信者のハードウェア識別子と転送されるメッセージのＤＡＴＰメッセージＩＤが含まれる。メッセージの第２の部分には、ＭＩＭＥエンコードされたＤＡＴＰメッセージが含まれる。
【００９４】
ＳＭＴＰアプリケーション・サーバに送信されたＤＡＴＰメッセージに対して、そのメッセージがセッション・マネージャによってデコードされ、電子メールでターゲットのアプリケーション・サーバに送信できる準備が整うとアクノリッジが送られる。ＳＧＷがターゲットのアプリケーション・サーバにＤＡＴＰメッセージの電子メール配信を試みると、その後、ＳＭＴＰ関連のエラーが発生することがある。ＤＡＴＰ暗号化層を使用して送信されるメッセージは、最終ホストに暗号解読された状態で転送される。ＳＭＴＰで安全にＤＡＴＰメッセージを送るためＰＧＰ暗号化もサポートされている。
【００９５】
ＤＡＴＰストア・アンド・フォーワードサービスは、非リアルタイム・メッセージを特定のアプリケーション・サーバに送信するアプリケーション用の機能を備えている。ストア・アンド・フォーワード・ライブラリがＤＡＴＰに実装されている。アプリケーションでは、このストア・アンド・フォーワード・モジュールを使用し、要求条件に応じて、異なるタイミング制約でメッセージを送信する。タイミング制約条件は、「できる限り早く」、「指定時刻」、「指定出来事、イベント、またはメッセージ」から、「ランダムな期間経過後」を含む「接続したときに必ず」までさまざまである。
【００９６】
ストア・アンド・フォワード・モジュールは、未配信のＤＡＴＰメッセージを一部の特定の属性（タイムスタンプ、タイミング制約条件、ターゲットＡＳ識別子など）とともにファイル・システムに格納する。ファイル・システムの格納経路は、少なくともコンパイル時に設定可能であり、特定のネットワークに対応させることができる。指定されたＤＡＴＰストア・アンド・フォワード対応アプリケーションが実行されている間に転送されないメッセージは、他のストア・アンド・フォワード対応アプリケーションが実行開始しない限り転送されない。ストア・アンド・フォワード・モジュールでは、転送されたＤＡＴＰメッセージの内容は変更されない。メッセージは、ターゲットのアプリケーション・サーバに変更を加えることなく転送される。
【００９７】
図４には、複数のモジュールを含むクライアント・スタックのＤＡＴＰアーキテクチャが示されている。線１１２１の下のモジュールは、ネイティブ・クライアント・コードで書かれているが、線１１２１の上のモジュールはＯコードで書かれている。軽量ＨＴＴＰモジュール１１０６は、軽量ＨＴＴＰ機能をＯコード・アプリケーションに提供する。これは、ＤＡＴＰ  ＡＰＩの上側に設けられている。ストア・アンド・フォーワードモジュール１１０８は、ストア・アンド・フォーワード機能をＯコード・アプリケーションに提供する。これは、ＤＡＴＰ  ＡＰＩの上側に設けられている。ＤＮＳモジュール１１１０は、ＤＡＴＰメッセージ・マネージャ・モジュール１１０４を使用して、ＤＡＴＰ名前レゾリューション・サービスを提供する。ＤＡＴＰメッセージ・マネージャ・モジュール１１０４はＤＡＴＰのフロントエンドを提供している。ＤＡＴＰメッセージ関連のＡＰＩ呼び出しはすべて、ＤＡＴＰメッセージ・マネージャ・モジュールを通る。このモジュールは、メッセージを複数のＤＡＴＰパケットに分けて、ＤＡＴＰパケットをメッセージに再構築する。ＤＡＴＰトランスポート・コア・モジュール１１０２は、ＤＡＴＰセッションを管理し、ＤＡＴＰパケットの送受信、放送からのＤＡＴＰモジュール受信の管理を行う。ＤＡＴＰセキュア・トランスポート拡張モジュール１１２０は、セキュアＤＡＴＰセッションを処理する。ＤＡＴＰパケット・ライブラリ１１３４は、ＤＡＴＰパケット形式仕様に基づきＤＡＴＰ  ＳＴＢトランスポート・モジュール１１３２との間のＤＡＴＰパケットの読み込み（解析）および書き込み（作成）を行う機能を提供する。完全なＤＡＴＰパケットを読み込んだ後、このモジュールは、ＤＡＴＰトランスポート・コアに解析済みＤＡＴＰパケットを通知する。
【００９８】
ＤＡＴＰ放送ライブラリ１１２６は、ＤＡＴＰトランスポート・コア１１０２仕様に基づいて選択されているＳＰストリームで着信を監視し、指定されたＳＴＢすなわちクライアントを対象とするモジュールを待ち、ＤＡＴＰトランスポート・コア１１０２に解析済みＤＡＴＰモジュールを通知する。ＤＡＴＰ  ＳＴＢトランスポート・モジュール１１３２は、ＤＡＴＰホスト上で利用可能なネイティブ・トランスポートまたはデータ・リンクの上にリンク・レベル・パケット・インターフェイスを備える。イベント・ループ・スタブ１１１６は、ＤＡＴＰポータビリティ層で仕様が定められているメッセージＡＰＩのスタブ・バージョンを備える。このスタブは、共通ライブラリ・イベント・ループに基づく。ポータビリティ層１１１４の役割は、メッセージ・ディスパッチ・メカニズム、暗号化ＡＰＩなどアプリケーションに左右される問題からＤＡＴＰスタックを抽出するというものである。暗号ライブラリ・スタブ１１１８は、ＤＡＴＰポータビリティ層で仕様が定められている暗号ＡＰＩのスタブ・バージョンである。このスタブは、共通ライブラリ暗号パッケージに基づく。モジュール・ライブラリ・スタブ１１２４は、ＤＡＴＰポータビリティ層で仕様が定められているマルチトラック・モジュール・ダウンロードＡＰＩのスタブ・バージョンである。このスタブは、共通ライブラリのマルチトラック・モジュール・ダウンロード・パッケージに基づく。
【００９９】
図６に示されているＤＡＴＰはデジタルＴＶアプリケーション・プロトコル（ＤＡＰ）のサブセットである。ＤＡＰ／ＤＡＴＰは、図６に示されている。ＤＡＰは、ＳＰアプリケーションとＳＧＷとの間の裏チャネル通信を標準化するのに使用される。すべてのＳＰ対応ＳＴＢがＴＣＰ／ＩＰスタック拡張を備えているわけではないので、ＤＡＴＰおよびＳＧＷがＳＰアプリケーションに汎用仮想トランスポート・メカニズムを提供する。さらに、ＳＴＢの一部はそれ専用のスタックを実行するか、または通信スタックをまったく備えていない。
【０１００】
ＤＡＰは、単純な軽量アプリケーション・プロトコル・スイートである。ＤＡＰの主な目的は、ローエンドのＳＴＢでＰＯＰ３、ＳＭＴＰ、インターネット・メッセージ・アクセス・プロトコル（ＩＭＡＰ）などの既存のアプリケーション・プロトコルを利用する単純でかつ効果的な手段を提供することである。ＳＴＢは多くの場合、低容量処理リソースおよび／または専用通信プロトコルを持つ。ＤＡＰは、アプリケーション・プロバイダからの通信の複雑さを抽出し、そして、既存のネットワーク・インフラストラクチャを今日のアプリケーション標準に利用するように設計されている。
【０１０１】
図６に示されているように、ＤＡＰはＤＡＭＬ  １６１０−デジタルＴＶアプリケーション・メタ言語およびＤＡＴＰ  １６２０−デジタルＴＶアプリケーション・トランスポート・プロトコルの２つの部分に分けられる。ＤＡＭＬ  １６１０は、多くのＳＰアプリケーションを対象とするメタ言語である。各ＳＰアプリケーションにはＤＡＭＬのそれ専用のドメインがある。クライアント・アプリケーションは、ＤＡＭＬドメイン内にカプセル化されているメッセージへの応答および要求を行う。これらの要求メッセージは、アプリケーション・サーバにより、既存のアプリケーションにあった、ＳＭＴＰやＩＭＡＰなどの適切なプロトコルに変換される。
【０１０２】
ＤＡＴＰ  １６２０は、ＴＣＰ／ＩＰまたは他の知られているプロトコルが利用できないときに低帯域幅のアプリケーション用に設計された軽量で単純なトランスポート・プロトコルである。ＤＡＴＰは、現在のＳＴＢにおける既存の通信プロトコルとインターフェイスするように設計されている。ＤＡＰは、ＤＡＴＰ、ＤＡＭＬ−Ｍａｉｌ（メール用ＸＭＬドメイン）、ＤＡＭＬ−Ｒｅｇｉ（アカウント登録用ＸＭＬドメイン）、およびＤＡＭＬ−Ａｃｃｔ（ＳＰ  ＶＭＳ／ＡＭＳシステムへのアクセス用のＸＭＬドメイン）からなる。
【０１０３】
通常のＳＴＢは、シン(thin)・クライアント・アーキテクチャに基づいている、つまり、最小限の処理能力を持つ。今日のＳＴＢによって提供されるサービスは、多くの場合、ローエンドの「ダム(dumb)」アプリケーションである。メール、チャット、およびインターネット・ブラウザなどのリソースを大量に消費する今日のアプリケーションは、より強力な処理手段を必要としている。現在のＳＴＢでは、このタイプの処理能力を備えることはできず、したがって、ローエンドの軽量アプリケーション・プロトコルが必要である。ＤＡＰは、アプリケーション開発者にクライアント／サーバ・ネットワークの複雑さが見えないように隠す／抽象化できるくらい十分に単純である。
【０１０４】
ＤＡＰは、モジュール式で、柔軟性があり、今日新たに登場するソフトウェア・アーキテクチャに適応できる。Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ（Ｏｂｊｅｃｔ  Ｍａｎａｇｅｍｅｎｔ  Ｇｒｏｕｐ）（ＣＯＲＢＡ）ベース・モデルまたはＣｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｍｏｄｕｌｅ（ＣＯＭ）／Ｄｉｓｔｒｉｂｕｔｅｄ  Ｃｏｍｐｏｎｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｕｌｅ（ＤＣＯＭ）モデルのいずれかがある。ＤＡＰは、既存のサード・パーティ製のレガシー・システムに対応し、組み込むことができる十分な柔軟性を持つ。ＤＡＰは、各種のオープンの専用プロトコルとのインターフェイスを備える。これらのプロトコルは、ＰＣが主クライアント、例えば、ＩＭＡＰまたはＰＯＰ３サービスであるサービス・システムに存在している。ＤＡＰでは、ＳＰミドル・ウェア・テクノロジを利用している。ＤＡＰサーバ・ウェアは、ＤＡＰプロトコルを既存のアプリケーション固有プロトコルに変換する。
【０１０５】
ＤＡＰおよびそのサブセットＤＡＭＬ１６１０は、軽量で、ローエンド帯域幅の機密性の高いＳＴＢをサポートできるように設計されている。ＤＡＭＬタグは、４文字以内であるのが好ましく、できれば、２または３文字に制限する。ＤＡＭＬは、バイナリＸＭＬを組み込み、ＤＡＭＬタグを使いやすくしている。ＤＡＰは、ＳＴＢとサービス・サブシステム上で実行されているアプリケーション間の通信プロトコルとして使用される。ＤＡＴＰ  １６２０は、通信ハンドシェーク、ルーティング、およびトランスポート固有認証を制御するが、ＤＡＭＬはアプリケーション固有の要求条件を管理する。ＤＡＭＬ要求と応答は、既存の通信プロトコル、例えば、ＴＣＰ、ＵＤＰ、ＤＡＴＰ、または専用通信プロトコルを使用してＳＴＢクライアントとサービス・プロバイダとの間でやり取りされる。
【０１０６】
ＤＡＰプロトコルおよびそのサブセットであるＤＡＭＬは、セッション指向または「セッションレス」プロトコル・スイートである。ＤＡＭＬドメインは、アプリケーションによって決まる。ＤＡＰプロトコルの新しいドメインは、新しいタイプのアプリケーションに使用できる。新しいＤＡＰドメインを追加しても、既存のＤＡＰドメインへの影響はほとんどない。したがって、ＤＡＰは、既存のサービスに影響を与えずにサービスを追加するネットワーク・オペレータ向けの独自のかつ簡素化されたＳＰを提供する。各ＤＡＭＬドメインは、単純な人間可読タグまたは暗号短縮タグのいずれかをベースとし、パフォーマンスが重要な要因である場合にパケット・サイズを縮小することによりプロトコルのパフォーマンスを高めることができる。
【０１０７】
ＤＡＰアーキテクチャにおけるＤＡＭＬの役割の概要を述べる。ＤＡＭＬは、インタラクティブ・テレビ・サービス用の通信動作および通信データを指定するために使用されるアプリケーション・レベルの通信プロトコルである。サービス・レベル通信プロトコルは、トランスポート・レベル・プロトコルの上位である。これは、クライアント／サーバ通信についてアプリケーション固有のコンテンツをカプセル化する方法を定義する。
【０１０８】
ＤＡＭＬは、ＳＰのモジュール式設計に対応できるドメイン固有のプロトコルの集合体である。例えば、ＤＡＭＬ−ＭａｉｌはＤＡＰのサブセットである。ＤＡＭＬ−Ｍａｉｌは、メール・ドメイン固有のプロトコルである。新しいＤＴＤを作成するだけで、新しいドメイン固有のプロトコルをＤＡＰのサブセットとして追加できる。ＤＡＰにより、ＤＡＰメッセージの送受信による通信動作を指定する。アプリケーション固有データは、ＸＭＬ形式でカプセル化される。各ＸＭＬアプリケーション・ドメインの構文で、アプリケーション・サーバが実行するアクションを指定する。これにより、ＳＭＴＰサービスおよびＩＭＡＰサービスなどの既存のインフラストラクチャとインターフェイスするために今日のＳＴＢで利用できる非常に軽量で簡素なプロトコルを設計できる。
【０１０９】
ＤＡＴＰは、ＳＧＷと複数のＳＴＢすなわちクライアントとの間の通信プラットフォームを実装するトランスポート／サービス・レベルのプロトコルである。ＤＡＭＬは、ＤＡＴＰパケット内にカプセル化される。一般に、サービス・レベル・プロトコルは、搬送プロトコルの上位であるが、ＤＡＴＰはサービス・レベル、データ・リンク・レベル、またはトランスポート・レベルのいずれかの標準的なネットワーク・モデルに入れられるという点でユニークである。このため、ＤＡＴＰは非常に柔軟性が高い。ＤＡＴＰは、ＴＣＰ、ＵＤＰ、Ｘ．２５、ロー・ソケット、またはその他のプロトコルなどの基礎となる搬送プロトコルとインターフェイスする。
【０１１０】
ＳＧＷは、ローエンドＳＴＢがネットワーク・バックエンド・インフラストラクチャに接続するためのルーティングおよびＳＧＷ技術を備える。ＳＧＷでは、ＳＴＢ／クライアントとＳＧＷとの間のトランスポート・レベルのプロトコル、例えば、ロー・ソケット上のシーケンシャル・ストリーム・プロトコルをサポートする。ＤＡＭＬではこの機能を利用する。
【０１１１】
ＤＡＭＬ−ＭａｉｌはＤＡＰプロトコルのサブセットである。ＤＡＭＬ−Ｍａｉｌは、メール・ドメイン固有のプロトコルである。このプロトコルは、ＳＴＢとＩＭＡＰ、ＰＯＰ３、およびＳＭＴＰサービスとリンクするために使用される。ＤＡＭＬ−Ｒｅｇｉは、複数のサービスについてアカウントを登録するための汎用の方法の仕様を定めるＤＡＰサービス・ドメイン・プロトコルである。ＤＡＭＬ−Ｒｅｇｉは、ＳＴＢと登録サーバとの間の単純なプロトコルである。これにより、ＳＴＢと各種のアプリケーション・システムとの間の複雑なやり取りが、単一の統合点のみ、つまり登録サーバで行うことができる。
【０１１２】
ＤＡＭＬ−Ａｃｃｔは、ＳＰ  ＶＭＳ／ＡＭＳデータベースと通信するＤＡＰサービス・ドメイン・プロトコルである。ＤＡＭＬ−Ａｃｃｔを使用することで、ＳＴＢ／クライアントはＶＭＳ／ＡＭＳシステムからのユーザ固有データについてクエリを実行し、返すことができる。すべてのＤＡＭＬドメインは、ＸＭＬ文書型定義（ＤＴＤ）構文を使用して定義される。ＤＴＤでは、メッセージ構文を記述するが、要求と応答の交換用のロジックについて記述しない。ＸＭＬは、１ブロック分のテキストのマークアップを定義する際に使用する。特定のＤＡＭＬ要求と応答は互いに関連する相互作用である。この相互作用の規則はＳＴＢとアプリケーション・サーバ・コンポーネントとにモジュール化される。
【０１１３】
メッセージング・マネージャは、ユーザ間の各種のメッセージ通信および外部者（ネットワーク・サービス受信契約者でない人たち）との各種のメッセージ通信を扱う。例えば、これにより、ユーザは電子メールの送受信、他の非受信契約者とのチャット、および非受信契約者からのインスタント・メッセージの受信を行える。メッセージング・マネージャの電子メール部分には、ＩＭＡＰ、ＰＯＰ３、および適切なメール・ホスト・サーバ用のその他のＷｅｂメール・メッセージなどのインターネット・ベースの電子メール・サーバに接続されているＦｅｔｃｈｍａｉｌコンポーネントが含まれる。
【０１１４】
ＦｅｔｃｈｍａｉｌはすべてのＳＰサーバ・サイドのメール管理を行う。Ｆｅｔｃｈｍａｉｌは、ＤＡＰメッセージを適切なメール・ホスト・サーバ用のＩＭＡＰ、ＰＯＰ３、またはＷｅｂメール・メッセージに変換する。ＳＧＷは、ＤＡＰメール・メッセージを処理のため「Ｆｅｔｃｈｍａｉｌ」に送る。Ｆｅｔｃｈｍａｉｌは、要求に対する適切な応答で返答する。Ｆｅｔｃｈｍａｉｌは、ＩＭＡＰサーバとインターフェイスする。電子メール・アプリケーションはＳＰによって提供される。すべてのＳＰアプリケーションは、ＳＧＷによって提供される電子メール・サービスを介して電子メールを「送る」ことができる。
【０１１５】
チャット・サーバなどとのチャットＳＰサービス・インターフェイスには、チャット・サーバが含まれる。チャット・サービスにアクセスするには、専用チャット・アプリケーションを使用するが、ＳＰチャット・クライアントＤＬＬを使って任意のＳＰからもアクセスできる。チャットとプログラム・リストとのインターフェイスを実現するために、チャット・ルームを放送番組で動的に作成することができる。アプリケーションおよびその他のサービスは、ＳＰ「アラート」サービスを使用して、ＳＴＢ常駐ミニ・アプリケーションをトリガすることができる。アラートでは、オープン・ストリーマのＳＰ  ＯＭＭ拡張および機能を利用する。電子メール・サービスでは、アラート・トリガを使用して、視聴者に着信メッセージを通知する。
【０１１６】
図１０は、ＤＡＴＰ接続の状態マシンを示している。この状態マシンは、ＳＴＢクライアント側からＤＡＴＰセッション接続状態マシンの動作を説明するものである。セッションは、データ・パケットをＳＧＷに送信する前に接続状態になっていなければならず、またクライアントからログアウト要求があったら、切断されなければならない。図１１は、メッセージ送信状態を示している。この状態マシンは、ＤＡＴＰエンティティがＤＡＴＰデータ・パケットを他のＤＡＴＰエンティティにどのように送信するかを説明している。図１２は、メッセージ受信状態マシンを示している。この状態マシンは、ＤＡＴＰエンティティがＤＡＴＰデータ・パケットを他のＤＡＴＰエンティティからどのように受信するかを説明している。図１３は、存続状態マシンを示している。この状態マシンは、ＤＡＴＰエンティティがｐｉｎｇパケットを使用して、他のエンティティへのＤＡＴＰリンクがまだ接続中であることを確認する方法を示している。リンクが停止していることがわかると、ログアウト動作が始まる。
【０１１７】
ＳＧＷ
図５では、ＳＧＷに、ＤＡＴＰ機能をサポートする複数のモジュールが組み込まれている。ＳＧＷアーキテクチャは、スレッドのプールを備えるマルチプロセス・ベースのアーキテクチャである。サーバ全体が、非同期バージョンのプラットフォーム抽象層（ＰＡＬ）で実行される。ＰＡＬでは、メッセージ・キュー・プロセスを実行する。ＰＡＬは、メッセージ受渡手法を使用して通信を行う。ＳＧＷでは、図５に示されているように、３種類のプロセッサを使用する。
【０１１８】
図５に示されているように、アプリケーション・サーバまたはサービスは、ドメイン固有のＤＡＰプロトコルを使用してＳＧＷを通じて複数のクライアント／ＳＴＢと通信する。場合によっては、クライアント／ＳＴＢはアプリケーション・サービスに直接接続できる。例えば、ＳＴＢとネットワークとの間のトランスポート・プロトコルがＴＣＰ／ＩＰの場合、ＳＴＢはＴＣＰ／ＩＰ対応であり、ＳＧＷによって提供される複雑な共通サービスを実行する必要はなく、ＴＣＰ／ＩＰを介してサービスと直接通信するクライアント／ＳＴＢを通じてネットワークの高速性能を改善できる。
【０１１９】
図７では、ＤＡＴＰサーバ、ＳＧＷの主プロセスは、上述の主ＤＡＴＰサーバ・プロセスである。ＳＧＷは、複数の重要モジュールのホストとなる。ＴＣＰソケット・リスナー・モジュール１２０４は、ＤＡＴＰ  ＴＣＰ監視ポートで接続を待ち、その接続を受け付け、新規接続を処理する新しいセッション・マネージャの作成を要求する単純なＴＣＰソケット・リスナー・スレッドである。ＵＤＰソケット・リスナー１２０２は、ＵＤＰ接続のよく知られているポートで待機する。接続要求を受け取ると、ＵＤＰソケット・リスナー１２０２は新しいソケットを作成して、接続要求アクノリッジをリモート・ホストに送信する。その後、ＵＤＰソケット・リスナー１２０２は接続を処理する新しいセッション・マネージャの作成を要求する。
【０１２０】
セッション・マネージャ・モニタ１２０６モジュールはメイン・スレッドの一部である。このコンポーネントの主要な役割は、セッション・マネージャ（ＳＭ）プロセッサ１２１４分布（負荷に基づいてＳＭプロセッサを作成、削除する）を監視し、セッション・マネージャ作成要求を最も使われていないＳＭプロセッサ１２１５に転送する。各ＳＭプロセッサ（０〜ｎ）１２１５は、ＤＡＴＰ、ＨＴＴＰＰ、ＬＨＴＴＰ、およびＳＭＴＰ用にＤＡＴＰアプリケーション・サーバ通信モジュール（ＡＳＣＭ）１２１７および独立のアプリケーション・サーバ・データ・センダー（ＡＳＤＳ）を備える。
【０１２１】
ＤＮＳネーム・サーバ１２１２スレッドは、アプリケーション・サーバ識別子とその属性（ホスト名、ポート、タイプなど）との間の照合テーブルだけでなく、セッション識別子とセッション・マネージャ・メッセージ・キュー識別子との間の照合テーブルも保持する。ネーム・サーバ・モジュールＤＮＳは、メッセージ・キューにポストされた名前レゾリューションクエリに応答する。アプリケーション・サーバのソケット・リスナー／スレッド１２０８は、メッセージ・ポスト要求がアプリケーション・サーバから入ってくるのを待つ役割を持つ。その後、ネーム・サーバ１２１２は、ポスト要求セッション識別子に基づいてポスト要求をターゲットのセッション・マネージャに転送する。
【０１２２】
セッション・マネージャのプロセッサ・プロセス１２１４、１２１６は、セッション・マネージャ・スレッド１２１５のプールのホストとなる。新しいセッション・マネージャ・スレッドが、セッション・マネージャのモニタ１２０６からセッション・マネージャのプロセッサ・スレッドへの要求に基づいて作成される。セッション・マネージャ・プロセッサ１２１４、１２１６のスレッドは、セッション・マネージャ・プロセッサ１２１４、１２１６から要求を受け取り、ＳＭモニタからの要求に基づいてセッション・マネージャを作成または削除し、要求の結果をセッション・マネージャ・プロセッサに通知する。セッション・マネージャ・スレッド１２１５は、ＤＡＴＰセッションを管理し、ＳＴＢすなわちクライアントからＤＡＴＰメッセージをアプリケーション・サーバに、アプリケーション・サーバからＳＴＢすなわちクライアントに転送する。ＳＴＢすなわちクライアント毎に１つのスレッドがある。これらのスレッドでは、複数の重要モジュールを使用してＤＡＴＰセッションを処理する（パケット・ライブラリ、アプリケーション・サーバ通信モジュール、ＤＡＴＰアプリケーション・サーバ・データ・センダー、ＨＴＴＰＰアプリケーション・サーバ・データ・センダー、ＬＨＴＴＰアプリケーション・サーバ・データ・センダー、およびＳＭＴＰアプリケーション・サーバ・データ・センダー）。
【０１２３】
放送マネージャ・プロセス１２１０は、放送によるＤＡＴＰルーティングの主要コンポーネントである。このプロセスは、ＤＡＴＰサーバ・カルーセルを管理するオープン・ストリーマ・アプリケーション・サーバである。放送マネージャ・プロセスは、ＤＡＴＰサーバの他のコンポーネントから受信した要求に応じて動的にこれらのカルーセルを更新する。
【０１２４】
ＳＰおよびＳＧＷは、当業ではよく知られており、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓから市販されているメモリ、モニタ、ＧＵＩ、マウス、キーボード、およびプロセッサを備えるＳｕｎ  Ｓｏｌａｒｉｓ  ７データ処理システムでサポートされている。ＳＧＷは、ＵＮＩＸ（登録商標）デーモンとして実行され、設定には設定ファイルを使用し、コマンド・ラインから起動する。ネットワーク上でＳＧＷとＳＴＢ／クライアントとの間に接続が確立されると、ＴＣＰ／ＩＰにより他のサービス間のすべての通信が処理される。異なるトランスポート・プロトコルを処理するほかに、ＳＧＷではさらに、ＳＧＷの設定に応じて別のサービス・サブシステムへのメッセージのルートを設定する。
【０１２５】
ＳＧＷは、アプリケーション・サーバの入口点でその機能を実行する。このため、ネットワークおよびメッセージング機能がＳＧＷ上で分離されているので、機能の設定／追加は簡単である。したがって、サービス・サブシステムがコア・アプリケーション機能で動作する負担から解放され、ネットワークの接続の問題はＳＧＷに任される。また、特定の機能を分離して別のホストに割り当てる、例えば、ＳＧＷを使用して電子メール・メッセージ配信と受信（ＦｅｔｃｈＭａｉｌサーバ）をネットワーク・ルーティングとセキュリティから分離することにより、拡張性を高めることができる。
【０１２６】
ＳＧＷは、単一サーバ上で同時接続を数百回実行できる規模である。ＳＧＷは、ＳＧＷのホストになるプロセッサの処理能力に応じて、処理できる設定接続数を増やすことができる。この限界は、主要ＩＳＰに対して１つのＰＯＰ（Point Of Presence）当たりのモデム数（通常、数百）に基づく。ＳＧＷが１つの中心点に配置されたＷＡＮアーキテクチャの場合、ハードウェア・ネットワーク・アドレス変換（ＮＡＴ）ベースの負荷分散デバイスが負荷分散のため複数のＳＧＷを並列に接続するように設けられている。
【０１２７】
コンテンツ変換−Ｈ２Ｏ
以下に、Ｈ２Ｏアーキテクチャおよびサンプル・トランザクションの論理図を使用してＨ２Ｏプロキシ環境の概要を示す。ＵＲＩの要求は別のＨ２Ｏコンポーネント、例えば、ＳＴＢ／ＳＧＷおよびカルーセルから届く。以下の文脈では、要求を発行するＳＴＢ／ＳＧＷに関する重点事項の概要を述べるが、情報の一般的流れは同じままである。
【０１２８】
視聴者は、ＴＶ  Ｗｅｂページとやり取りすることを選択し、ＳＴＢからＨ２Ｏシステムに要求を発行し、応答を待つ。ＳＴＢ要求はＳＧＷに送信されるが、その際に、トランスポート・プロトコルとしてＤＡＴＰメッセージ内にカプセル化されている軽量ＨＴＴＰ要求（ＬＨＴＴＰ）を使用する。要求されたオブジェクトは、同じチャネルとプロトコルを使用して返される。ＳＧＷが、ＴＣＰ／ＩＰでＬＨＴＴＰプロトコルを標準ＨＴＴＰに変換し、要求をＷｅｂキャッシュに発行する。
【０１２９】
コンパイルド・オブジェクトキャッシュ（ＣＯＣ）は、内部ディスク領域を使用して、取り扱い対象の要求を処理する（オブジェクトの存続時間を考慮して発見的手法に従う）。その役割は、Ｈ２Ｏプロキシにクエリを実行せずに、すべての静的オブジェクト（クエリのない標準にＵＲＬ、ポスト形式なし）を処理し、処理負荷を軽減することである。このアーキテクチャでは、ＣＯＣはコンパイル済みオブジェクト（Ｈ２Ｏモジュール）のみを格納する。ＣＯＣマシンはＩ／Ｏ駆動方式である。
【０１３０】
図１４を参照すると、Ｈ２Ｏプロキシ２４８は、異なるＨ２Ｏコンパイラ（またはフィルタ）を実行するための拡張可能な環境を備えている。これは、ＨＴＴＰ要求および応答を「オンザフライ」で処理し、したがってＨ２Ｏプロキシマシンはプロセス駆動方式である。Ｈ２Ｏ  ＨＴＭＬコンパイラ１４２０は、ＨＴＭＬからＳＰへのリソース・コンパイルを受け持つ。描画するＴＶレイアウト１４２２を計算するために、このコンポーネントは、組み込まれているイメージのサイズに基づき自動的にＨＴＴＰ要求を発行する。このコンパイラは、クライアント表示デバイス、たとえばテレビに合わせて、Ｗｅｂベースのイメージを再配列する。
【０１３１】
ＭＰＥＧコンパイラ１４２６は、通常のＷｅｂイメージ形式からＳＰ  Ｈ２Ｏ  ＭＰＥＧリソースに変換する操作を受け持つ。ソース形式としては、ＪＰＥＧおよびＧＩＦがあり、ＰＮＧも含むことがある。ＵＲＬを通じて引数を受け渡すことで、変換プロセスを駆動することができる。ＰＩＸＭＡＰコンパイラは、通常のＷｅｂイメージ形式からＳＰ  Ｈ２Ｏリソースに変換する操作を受け持つ。ソース形式としては、ＧＩＦがあり、ＰＮＧも含むことがある。
【０１３２】
リクエスト・パッチャ１４２４は、他のシステムから届いたデータ（例えば、クレジット・カード番号など）を組み込む要求または応答を完了または修正する役割を持つ。これは、外部プロセスまたはデータベースと通信して、顧客情報をフェッチする。ＳＰコンポーネントは、ユーザ情報の中央リポジトリを備える。リクエスト・パッチャは、このコンポーネントと通信して、要求／応答をパッチするために必要なデータを取得する。
【０１３３】
ノットコンパイルド・オブジェクト・キャッシュ１４３０は、内部ディスク領域を使用して、取り扱い対象の要求を処理する（オブジェクトの存続時間を考慮して発見的手法に従う）。キャッシュされたオブジェクトは、静的ＨＴＭＬ、ＧＩＦイメージ、ＪＰＥＧイメージ、および標準のすべてのＷｅｂ形式ファイルを含む。その役割は、インターネットにクエリを実行せずに、すべての静的オブジェクト（クエリなし標準ＵＲＬ、ポストされない形式）を処理し、オブジェクトを取得する待ち時間を短縮し、ある種のフォルトトレラント能力をシステムに与えることである。顧客のＷｅｂサイトはＨ２Ｏシステムを通じてパブリッシュするＷｅｂサイトを保持する。
【０１３４】
図１５は、すでにキャッシュされている静的ページの要求を示している。ＳＴＢユーザが、ＨＴＭＬページ１５２０をロードする要求を発行する。この要求は、ＤＡＴＰ上でＬＨＴＴＰを使用してＳＧＷ  ２４８に送られる。ＳＧＷは、ＴＣＰ／ＩＰでこの要求をＨＴＴＰに変換し、それをコンパイルド・オブジェクトキャッシュ１４１０に転送する（１５２２）。コンパイルド・オブジェクトキャッシュ１４１０では、要求された（モジュールにコンパイルされた）ＨＴＭＬページを内部ハードディスク領域に格納するが、ただしオブジェクトの存続時間が期限切れになり、コンパイルド・オブジェクトキャッシュで、コンパイル済みＨＴＭＬページで要求を処理する場合である。ＴＣＰ／ＩＰでＨＴＴＰを使用してＨＴＴＰ応答１４２４をＳＧＷに送信する。ＳＧＷは、ＴＣＰ／ＩＰ上のＨＴＴＰからプロトコルをＤＡＴＰ上のＬＨＴＴＰに変換する。ＳＴＢは要求されたページ１５２６（コンパイル済み）をメモリ内にロードし、解釈できるようにＨ２Ｏブラウザ・エンジンに渡す。Ｈ２Ｏブラウザ・エンジンは、変換オプション（ｍｐｅｇまたはｐｉｘｍａｐ、幅、高さなど）で、テレビの画面に描画するために必要なイメージをＵＲＬで取得するようＳＧＷに要求する（１５２８）。ＳＧＷは、ＨＴＴＰ要求１５３０をコンパイルド・オブジェクトキャッシュに送信する。コンパイルド・オブジェクトキャッシュでは、要求された（モジュールにコンパイルされた）イメージを内部ハードディスク領域に格納するが、オブジェクトの存続時間は期限切れになっておらず、コンパイルド・オブジェクトキャッシュ１５３２および１５３４はコンパイル済みイメージとともに要求を処理する。このシナリオでは、Ｈ２Ｏプロキシは要求を免れており、他の要求を処理することができる。
【０１３５】
図１６に示されているように、ＳＴＢ  ２１２ユーザは、ＨＴＭＬページ（ｈｏｍｅ．ａｓｐ）をロードする要求１６１０を発行し、要求ヘッダのホストおよびユーザ情報フィールドに、［ＳＴＢモデル＋ＳＴＢシリアル番号］およびユーザの［アクセス・カードＩＤ］が保持される。この要求１６１０は、ＤＡＴＰ上でＬＨＴＴＰを使用してＳＧＷに送られる。ＳＧＷは、ＴＣＰ／ＩＰでこの要求をＨＴＴＰに変換し、それをコンパイルド・オブジェクトキャッシュに転送する（１６１２）。要求されたオブジェクトは、Ｗｅｂキャッシュのディスク領域では利用できない。その後、Ｗｅｂキャッシュは、要求１６１４をＨ２Ｏプロキシに転送する。Ｈ２Ｏプロキシはユーザの名前を返す（１６２０）ようＳＰに求める（１６１６）（ａｍａｚｏｎ．ｃｏｍサービスの場合）。Ｈ２Ｏプロキシは、要求にユーザの名前のパッチを当て、この要求１６２２を「ノットコンパイルド・オブジェクトキャッシュ」に発行する。「ノットコンパイルド・オブジェクトキャッシュ」は、ディスク領域内に要求されたＨＴＭＬページを保持せず、要求１６２４をターゲットのＷｅｂサーバ、ここではａｍａｚｏｎ．ｃｏｍに発行する。ターゲットのＷｅｂサーバは、ユーザ情報があればＨＴＭＬページを計算し、それ１６２６を「ノットコンパイルド・オブジェクトキャッシュ」に返す。「ノットコンパイルド・オブジェクトキャッシュ」はＨＴＭＬページ１６２８をＨ２Ｏプロキシに返す。
【０１３６】
Ｈ２Ｏプロキシは、ＨＴＴＰ要求１６３０を「ノットコンパイルド・オブジェクト・キャッシュ」に送り、レイアウト計算に必要なイメージ１６３２、１６３４、１６３６（ｇｉｆ、：ｊｐｅｇなど）を取得する。Ｈ２Ｏプロキシは、ＨＴＭＬページをコンパイルし、レイアウトを計算し、埋め込まれているイメージのＵＲＬをパッチし、その結果のＯｐｅｎＴＶリソース１６４６（ＳＰリソースＭＩＭＥタイプ付きで）を「コンパイルド・オブジェクト・キャッシュ」に送り返す。コンパイルド・オブジェクト・キャッシュでは、オブジェクトをその内部ディスク領域に格納し、コンパイルドＨＴＭＬ１６４８ページをＳＧＷに送り返す。ＳＧＷは、ＤＡＴＰでこの応答をＬＨＴＴＰに変換し、それをＳＴＢに送り返す（１６５０）。ＳＴＢは要求されたオブジェクトをメモリ内にロードし、解釈できるようにＨ２Ｏブラウザ・エンジンに渡す。
【０１３７】
Ｈ２Ｏブラウザ・エンジンは、要求１６５２をＳＧＷに発行し、（パッチが当てられたｕｒｌを通じて、ここでは、ｌｏｇｏ．ｇｉｆ  ｕｒｌはｐｉｘｍａｐリソース形式のディレクティブを含む）描画に必要なイメージｐｉｘ／ｌｏｇｏ．ｇｉｆを取得する。ＳＧＷは、ＴＣＰ／ＩＰで要求１６５２をＨＴＴＰに変換し、それをコンパイルド・オブジェクト・キャッシュに転送する。「コンパイルド・オブジェクト・キャッシュ」にはすでに、ユーザがすでにこのイメージを前回に要求していたため、正しいリソース形式で要求されたｇｉｆイメージがあり、このイメージは直接ＳＧＷに返される（１６５４）。ＳＧＷは、ＤＡＴＰで応答をＬＨＴＴＰに変換し、それをＳＴＢに送り返す（１６５６）。Ｈ２Ｏブラウザ・エンジンは、要求１６５８をＳＧＷに発行し、描画に必要なイメージｍｐｇ／ｂａｎｎｅｒ．ｊｐｇを取得する。「コンパイルド・オブジェクト・キャッシュ」は、ディスク領域内に要求されたイメージを保持せず、したがって、要求１６６０をＨ２Ｏプロキシに発行する。Ｈ２Ｏプロキシは、ＨＴＴＰ要求１６６２を「ノットコンパイルド・オブジェクト・キャッシュ」に送り、／ｂａｎｎｅｒ．ｊｐｇイメージを取得する。
【０１３８】
「ノットコンパイルド・オブジェクト・キャッシュ」はイメージをキャッシュに保持し、それ１６６４を即座にＨ２Ｏプロキシに返す。Ｈ２Ｏプロキシは、ｕｒｌで与えられたパラメータ（ｍｐｇ形式、幅、高さなど）を使用してイメージを変換し、その結果をコンパイルド・オブジェクト・キャッシュ１６６８に返す。コンパイルド・オブジェクト・キャッシュでは、オブジェクトをその内部ディスク領域に格納し、変換されたｍｐｅｇイメージをＳＧＷに送り返す（１６６８）。ＳＧＷは、ＤＡＴＰで応答をＬＨＴＴＰに変換し、それをＳＴＢに送り返す（１６７０）。ＳＴＢが、ＨＴＭＬページを画面に描画する。
【０１３９】
Ｈ２Ｏプロキシ・コンポーネントは、他のＨ２Ｏコンポーネントまたはコンパイラに、堅牢で拡張可能なアーキテクチャおよび「コンパイラ」設定用のインターフェイスを提供する。提供される他のサービスとしては、エラーのログ機能、定義済みイベントに関する管理者へのアラート機能、「コンパイラ」のデバッグ・トレース機能がある。提供されるＨ２Ｏプロキシ環境とＡＰＩから、コンパイラはＨＴＴＰ要求および応答に対しオンザフライで「パッチ」を当て、最終的に、そのために外部データベース、ファイル、またはプロセスにアクセスする。コンパイラは、特定のＨＴＴＰヘッダ（ＳＴＢ識別子、アクセス・カード識別子．．．）の削除、特定のＨＴＴＰヘッダ（ユーザ名、クレジット・カード番号．．．）の追加、ＨＴＭＬ  Ｆｏｒｍフィールドの着信ポスト要求（Ｖｉｓａカード番号．．．）への追加、文字列置換（＄ＵＩＤ＄−＞ユーザ識別子）を実行することで、ＨＴＴＰ要求にパッチを当て、コンパイラがＨＴＴＰリソース応答においてＷｅｂオブジェクト形式およびｍｉｍｅタイプを「オンザフライ」で変換し、ＨＴＴＰ要求を自動的に発行し、その引き換えに応答オブジェクトを取得する。
【０１４０】
図１７に示されているように、好ましい実施形態では、Ｈ２Ｏプロキシは内蔵しているソフトウェア（Ｗｅｂプロキシ、ファイヤウォール、Ｗｅｂサーバ、またはその他のもの．．．）の拡張を開発することにより実装される。このホスト・ソフトウェアは、Ｈ２Ｏスレッド機能およびＨ２Ｏタスクのスケジュール機能だけでなく、Ｈ２Ｏ「コンパイラ」およびパッチング・コンポーネントの実装に必要な機能もいくつか備える。
【０１４１】
用意されているＡＰＩを使用し、プロキシ・ホスト・ソフトウェアにより一組のＡＰＩ（Ｈ２ＯプロキシＡＰＩ）を提供し、Ｈ２Ｏプロキシ・ホスト・ソフトウェア・サービスに欠けているＨ２Ｏコンパイラで必要な機能を実装し、Ｈ２Ｏプロキシ・ホスト・ソフトウェアから利用できるサービス用に上位の抽象レベルを提供する。リクエスト・パッチャ１４２４コンポーネントが、ＨＴＭＬページに対する着信ＨＴＴＰ要求を読み込み、他のプロセスまたはファイルまたはデータベースの情報で補う。ＨＴＭＬ２ＲＥＳコンパイラ１４２０は、返されたＨＴＭＬページをＳＰリソース・ファイルにコンパイルし、ＨＴＴＰ応答ヘッダのｍｉｍｅタイプを新しい形式、Ｍｉｍｅ−Ｔｙｐｅ：ｔｅｘｔ／ｏｔｖｒｅｓに合わせて変更する。
【０１４２】
ＧＩＦ２ＰＩＸコンパイラ１４２２は、返されたＧＩＦイメージをＳＰリソース・ファイルに変換し、ＨＴＴＰ応答ヘッダのｍｉｍｅタイプを新しい形式、Ｍｉｍｅ−Ｔｙｐｅ：ｉｍａｇｅ／ｏｔｖｐｉｘに合わせて変更する。２ＭＰＥＧコンパイラ１４２６は、返されたＧＩＦまたはＪＰＥＧイメージをＳＰリソース・ファイルに変換し、ＨＴＴＰ応答ヘッダのｍｉｍｅタイプを新しい形式、Ｍｉｍｅ−Ｔｙｐｅ：ｉｍａｇｅ／ｏｔｖｍｐｇに合わせて変更する。図１８には、ＨＴＭＬページ・シーケンス図の動的要求が示されている。オブジェクト・キャッシュは、シーケンス図には表示されず、このやり取りでは「受動的」コンポーネントである。ユーザＳＴＢ２１２が、ＨＴＴＰ要求を通じてページ（ｈｏｍｅ．ａｓｐ）の要求１８１０を発行する。リクエスト・パッチャ１４２４は、外部プロセス／ファイル／データベース／ｕｒｌ  １８１２、１８１４にアクセスして、ユーザ名を取得し、要求にパッチを当て、それをＨＴＭＬ２ＲＥＳコンパイラに送る（１８１６）。ＨＴＭＬ２ＲＥＳコンパイラは、要求１８１８をターゲットのＷｅｂサイト（ａｍａｚｏｎ．ｃｏｍ）に送る。Ｗｅｂサイトでは、その要求を計算し、その結果のＨＴＭＬページをＨＴＭＬ２ＲＥＳコンパイラに送り返す（１８２０）。ＨＴＭＬ２ＲＥＳコンパイラは、ファイルを解析して、イメージ・リンクＵＲＬを取得し、要求１８２２をＷｅｂサイト発行して、イメージ・ファイル（ｌｏｇｏ．ｇｉｆ、ｂａｎｎｅｒ．ｊｐｇ）を取得する（１８２４）。ＨＴＭＬ２ＲＥＳコンパイラでは、そのページのＴＶレイアウトを計算し、ＳＰリソース・ファイルにコンパイルし、ＳＴＢに送り返す（１８３０）。ＳＴＢが、ＨＴＭＬページをテレビに描画する。
【０１４３】
図１９には、イメージ・ファイルの要求、シーケンス図が示されている。ユーザＳＴＢにロードされるＨＴＭＬページには、画面に描画するイメージが必要である。これは、イメージ用のＨＴＴＰ要求１９１０（ＵＲＬ埋め込み変換オプション）を２ＭＰＧコンパイラに発行する。２ＭＰＧコンパイラは、ターゲット・サイト（ａｍａｚｏｎ．ｃｏｍ）にイメージ１９１２を要求する。ターゲット・サイトがｂａｎｎｅｒ．ｊｐｇイメージ・ファイル１９１４を２ＭＰＧコンパイラに返す。２ＭＰＧコンパイラが、ＵＲＬで指定されたオプションを使用して、ｂａｎｎｅｒ．ｊｐｇファイルを変換し、ｉｍａｇｅ／ｏｔｖｍｐｇ  ｍｉｍｅタイプ付きでＳＴＢに結果１９１６を返す。ＳＴＢが、イメージを画面に描画する。
【０１４４】
識別された異なるＨ２Ｏコンパイラが、クラスからＨ２Ｏコンパイラを継承し、そのクラスの異なる純然たる仮想エントリ・ポイントを実装する。要求／応答バッファの割り当ておよび解放を行うメモリ機能がコンパイラに与えられる。割り当てられたバッファのサイズがＦｒｅｅＢｕｆｆｅｒ機能に送られるため、異なる方式を使用してバッファを解放することができる（特定のサイズに関して、バッファをメモリ内にマッピングされたテンポラリ・ファイルとして実装することもできるが、サイズが小さい場合は、メモリ・バッファとして実装するのが好ましい）。
【０１４５】
完全ＨＴＴＰ要求／応答を含むバッファがＥｘｅｃｕｔｅ機能に渡され、コンパイラは、要求ヘッダ、ｍｉｍｅ−ｔｙｐｅを解析し、適切な処置を講じる。このバッファは読み取り専用であることが好ましい。バッファは、コンパイラまたはその他の後の機能により拡大できるように書き込み可能とすることもできる。Ｅｘｅｃｕｔｅ機能によって返されるバッファには有効なＨＴＴＰ要求／応答が格納され、メモリはＨ２Ｏプロキシにより、適切なＦｒｅｅＢｕｆｆｅｒ機能を使用して解放し、与えられたＡｌｌｏｃＢｕｆｆｅｒ機能により割り当てる必要がある。コンパイラ実装者がＨ２Ｏプロキシ環境内からデバッグ・トレースを実行できるようにデバッグ・メンバが用意されている。
【０１４６】
パラメータ機能を使用して、パラメータの名前を取得し、パラメータの現在値（文字列）を取得し、パラメータの新しい値を設定し、パラメータ・セットの確認を行う。イメージをフェッチするＨＴＭＬコンパイラ用にＵＲＬ機能が用意されている。これらの機能は、他のコンパイラでも使用でき、これにより、特別なサービスを必要に応じてコンポーネントに提供することができる。
【０１４７】
例えば、１００万個のＳＴＢがあり、平均２０，０００人のユーザが接続されているネットワークでは、ＳＧＷおよび「コンパイルド・オブジェクト・キャッシュ」に対し毎秒２，０００回のＨＴＭＬページ要求が発生する（要求されたページの一部がブロードバンドからでない限り）。これらのページが静的でなければならず、また「コンパイルド・オブジェクト・キャッシュ」から即座に提供されなければならないと仮定すると、Ｈ２Ｏプロキシでは、毎秒２００件の要求に応じなければならない。標準的なＨＴＭＬページに１０個のイメージが埋め込まれ、１０個のうち８個がＪＰＥＧであると仮定すると、Ｈ２Ｏプロキシは１０個の送出する要求を着信要求毎に発行する。「ノットコンパイルド・オブジェクト・キャッシュ」では毎秒２，０００件の要求に応じられる。
【０１４８】
可能であればＭＰＧ変換をあらかじめ実行しておくことが好ましい。Ｗｅｂクローラー(crawler)は、この問題を利用し、ＨＴＭＬページとイメージを夜間に要求して、あらかじめ変換しておくことができる。そこでコンパイラは、Ｈ２Ｏとやり取りする。Ｈ２Ｏ  ２４８は、ＳＰ内に用意される、インターネット・コンテンツ開発者がＳＰ上で実行されるネットワーク・オペレータ向けのインタラクティブ・テレビ、アプリケーション、およびサービスを製作できるようにする、好ましいクライアント／サーバ・ソリューションである。そこで、Ｈ２Ｏを利用すると、インターネット上の才能とコンテンツを集めた大きなプールを拡大一途のインタラクティブ・テレビ・アプリケーションの世界市場で活用することができる。Ｈ２Ｏサーバが、インターネット・コンテンツ（ＨＴＭＬページ、ＥＣＭＡスクリプト、およびＨＴＭＬページ書式設定）をＳＰアセットに変換する。Ｈ２ＯクライアントであるＨ２ＯＣが、それらのアセットを描画し、クライアントとやり取りする。テレビ商取引／電子商取引事例のシナリオでは、Ｈ２Ｏを使用することで、テレビ商取引／電子商取引の店舗が既存のＷｅｂツールを使用して、ショッピング・サービスを構築し、標準のＷｅｂプロトコルを使用することにより好ましいＳＰ（オペレータ）とのインターフェイスを作成することができる。そこで、本発明では、知られている方法を用いて使い勝手のよいＡＰＩを提供する。
【０１４９】
Ｈ２Ｏは、ＳＧＷと、ＷｅｂコンテンツをＳＰコンテンツに変換するための放送ツールへのプロキシとして機能する。そのため、Ｗｅｂサイト開発者は、現在のＨＴＴＰサーバおよびアプリケーション・サーバを使用して、インタラクティブ・テレビ・コンテンツを安価に製作することができる。好ましい実施形態では、Ｈ２Ｏは、ＨＴＭＬ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、およびインターネット・グラフィックスを変換するが、他の知られているまたは開発されているインターネットまたはその他のコンテンツまたはプロトコルもＨ２Ｏのプロキシ機能に追加することができる。Ｈ２Ｏを使用すると、ＳＰはブラウザ完全対応でないＳＴＢにＷｅｂページを表示し、オリジナルのユーザ・インターフェースを作成することができる。Ｈ２Ｏでは、ＳＰはＨＴＭＬのみを使用する商取引エンジンと接続することができる。Ｈ２Ｏは、ＨＴＭＬページ、ＪＰＧ画像、ｗａｖオーディオ・ファイルなどの現在または将来のブロードバンドおよびＷｅｂコンテンツすべてをＳＰリソースに変換する役目を持つ。
【０１５０】
Ｈ２Ｏのサーバ・サイドであるＨ２ＯＳはＨＴＴＰプロキシである。他の目的については、ダイナミック・リンク・ライブラリ（ＤＬＬ）またはバッチ・ツールとしてパッケージ化することができる。Ｈ２Ｏのクライアント・サイドであるＨ２ＯＣはＳＴＢ  Ｏコード・アプリケーションである。Ｈ２ＯＣは、ＳＧＷライブラリやカルーセル・ロード・ライブラリなどの他のＳＰクライアント・コンポーネントの上に構築される。Ｈ２Ｏでは、ＵＲＬを使用して、ドキュメントおよびサービスを取り扱うことができる。Ｈ２Ｏではさらに、放送およびオンライン環境で追跡することもできる。Ｈ２ＯＳは、ＨＴＴＰプロキシ機能を備えている。ＳＰアプリケーションは、Ｈ２Ｏを通じてドキュメントを要求し、その後、Ｈ２Ｏはそのドキュメントを取り出し、解析して、コンパイルし、要求側に返す。このＨ２Ｏ機能により、オンラインおよび放送の異なる用途に同じエンジンを使用できるため、拡張性が高く、Ｈ２Ｏを自由自在に使用することができる。解析は、ドキュメントの型によって異なり、解析にはＨＴＭＬ解析、ＧＩＦ画像、またはＪＰＥＧ画像などがある。拡張可能にするために、Ｈ２Ｏでは、「プラグイン」方式をとることができ、新しいサード・パーティ製のフィルタを実行することができる。
【０１５１】
Ｈ２Ｏでは、異なる言語を使用してスクリプトを作成できる。すべてのＳＰサーバ・コンポーネントで、監視機能周辺、特に異なるプロセスをリモートで管理する機能を標準化するのが好ましい。基本機能の処理にはＳＮＭＰを使用する（「プロセスＯＫ」、および主要な問題に対するトラップ）。ステータス検査用にコマンド・ライン・インタプリタをソケットで利用できるようにする。パラメータを設定して、リモート管理を行えるようにし、ＷｅｂスクリプトでＷｅｂとインターフェイスできるようにする。好ましい実施形態では、標準化された警告およびエラー・ログを用意する。
【０１５２】
ＨＴＭＬ／ＪＳでは、サーバ側でコンテキストを処理する際に、Ｗｅｂのページ同士で情報の共有を行うことができない。放送モードでは、この方式だと不足である。本発明では、好ましくは、グローバルな永続的オブジェクトが利用できる、つまり新規ページを開始してもクリアされない放送モードを実現する。永続的オブジェクトは、ページ間のコンテキストを保持する。ＳＰによって提供される他のベース・オブジェクトも、遷移後永続的にされる（例えば、局制御、ＯＳＤ）。インターフェイス定義言語を使用してガジェットを定義することで、新規ガジェットの作成、ガジェットの修正を行うことができ、またコンパイラを修正せずにメソッドの追加も可能になる。
【０１５３】
Ｈ２Ｏカルーセル機能を使用すると、カタログのリアルタイム更新、更新時のカタログ一貫性維持、安全なトランザクション・モデルの構築を行える。Ｈ２Ｏカルーセルにより、単一ページ、または単一トランザクションでのページ・セット全体の更新を行える。カルーセル管理機能では、カルーセル・インデックスまたはディレクトリの管理を行える。インデックスには、カルーセルのデータにアクセスし、フェッチするための情報が格納される。つまり、指定されたページでは、カルーセル管理に、必要なすべてのモジュールのリストが含まれ、Ｈ２ＯＣはプロセスを円滑に進めるため必要なすべてのモジュールを一度に要求する。
【０１５４】
カルーセルは、データ圧縮、ページ上のメタ・データ（例えば、ページ相対優先度、ページ送信頻度）、ページ追跡（基本ストリーム）などの機能を備える。カルーセル・クライアントはＳＴＢ  ＯＣＯＤライブラリであり、リソースのロードを取り扱う。カルーセル・クライアントは、リソースの動的変化、つまり新規リソース、リソース削除、およびリソース変更を管理する。動的リソース管理により、このライブラリのクライアント（Ｈ２ＯＣ）は動的コンテンツを提示できる。カルーセル・クライアントでは、メモリ割り当て、リソースのプリフェッチおよびキャッシュ、モジュールの圧縮解除を管理する。カルーセル・クライアントは、サブインデックス／ディレクトリを管理し、リソースの「ツリー」ではなくリソースの「セット」を管理するため、アセットの共有が容易になる。リソースの単一ツリーのサブセットを別々のプロセスに割り当てて、共有リソースを有効にすることができる。
【０１５５】
Ｈ２Ｏでは、共有モジュールで、テレビのトリガ・パフォーマンスおよび帯域幅、例えば、共有リソースを監視する。Ｈ２Ｏは帯域幅利用度を最適化する。Ｈ２Ｏは、データの入札ボリュームのマルチトラック、マルチプライオリティ、および管理の機能を持つ。Ｈ２Ｏは、モジュール・レベルで、リアルタイムのプリフェッチおよびキャッシングを実行する。Ｈ２Ｏは圧縮モジュールをサポートする。Ｈ２Ｏでは、矢印キーと直接キーによるナビゲーション（例えば、数字または色）をサポートしており、国際言語（中国語）、ページ上のメタ・データ（例えば、ページ相対優先度、送信頻度）、およびページ追跡（基本ストリーム）を扱える。グローバルＧＵＩは共有される、つまり、直接キー・リンクが用意されており、任意の情報ページを他のすべてのページから共有できる。
【０１５６】
Ｈ２Ｏでは、ページと下位ページを管理し、ページが大きすぎて１画面に収まりきらずスクロールしなければならない場合を処理する。Ｈ２Ｏでは、ＨＴＭＬを使用して、オンライン、ポイントツーポイント、および放送のコンテンツを表示できる。Ｈ２Ｏにより、放送およびオンライン・コンポーネントを混ぜたページを製作できる。例えば、オンライン・サーバからのページであるが、背景が放送される場合である。Ｈ２Ｏでは、ＳＴＢのコンテンツをマージすることができる。例えば、銀行アプリケーションは、視聴者の最近２０件のクレジット・カード・トランザクションをサーバから送信しながら、ＨＴＭＬページを放送することができる。ＪａｖａＳｃｒｉｐｔ機能でサーバに何らかのＸＭＬを要求し（ＨＴＴＰのように）、結果とＤＯＭ機能を使ってテーブルにその結果をパッチとして当てるのが好ましい。
【０１５７】
視聴者の認証を安全に行えるようにセキュリティ対策を施すことが好ましく、これは、Ｈ２ＯではなくＳＧＷで実行する。しかし、Ｈ２Ｏは、それと別の認証機能を備えることもできる。Ｈ２Ｏはさらに、暗号化されたデータを（例えば、クレジット・カード番号の送信で）ＳＴＢからオンライン・サーバに送信する。一部のサービスについては、ＨＴＭＬからＳＰへの変換近くのセキュリティ・プロキシに通すのが適切である。ＳＰでは、プロキシからサービス・プロバイダまでＨＴＴＰＳを利用し、ＳＴＢからプロキシまではＯＣＯＤライブラリのようなＳＳＬを使用することができる。他の場合（例えば、銀行）では、端から端までセキュリティ対策を講じ、その場合、Ｈ２Ｏは通常、変換を実行しない。このシナリオは、Ｈ２Ｏを通じて変換を行うことなくＳＴＢが処理できるデータ用に取っておくのが好ましい。それとは別に、ＳＧＷまたはＳＴＢで暗号化を実行することもできる。
【０１５８】
本発明は、好ましい実施形態のインタラクティブ・テレビについて説明されているが、本発明は、サーバとクライアント・デバイスを含む分散コンピュータ・システムで実現することもできる。他の実施形態では、本発明は、現在知られている、あるいは知られていない、ＲＯＭ、ＲＡＭ、ＣＤ  ＲＯＭ、フラッシュ、またはその他のコンピュータ読取り可能媒体などのコンピュータ読取り可能媒体上の一組の命令として実装され、分散コンピュータ・システムによりこれらの命令が実行されると分散コンピュータ・システムが本発明の方法を実行する。
【０１５９】
本発明の好ましい実施形態は上の発明により示されているが、例を示すことのみを目的としており、請求項で定義されている本発明の範囲を制限する意図はない。
【図面の簡単な説明】
【０１６０】
【図１】本発明が配置されるサービス・プラットフォームの好ましい実施形態を示す高水準アーキテクチャ図である。
【図２】本発明が配置されるサービス・プラットフォームのアーキテクチャを示す図である。
【図３】本発明の好ましいアプリケーション・バックエンド・フレームワークの一実施例を示す図である。
【図４】本発明の好ましいＤＡＴＰ  ＳＴＢスタック・アーキテクチャの一実施例を示す図である。
【図５】アプリケーション・サーバとＳＧＷとの間の裏チャネル通信を標準化するために使用されるデジタルＴＶアプリケーション・プロトコル（ＤＡＰ）のサブセットとしての本発明のサービス・ゲートウェイ（ＳＧＷ）、デジタルＴＶアプリケーション・トランスポート・プロトコル（ＤＡＴＰ）を示す図である。
【図６】ＤＡＰのサブセットとしてのＤＡＭＬおよびＤＡＴＰを示す図である。
【図７】本発明のＳＧＷの好ましいアーキテクチャの一実施例を示す図である。
【図８】本発明のスライディング・拒絶ウィンドウを示す図である。
【図９】ＳＴＢとアプリケーション・サーバとの間のＤＡＴＰセッション例を示す図である。
【図１０】ＤＡＴＰの状態マシンを示す図である。
【図１１】ＤＡＴＰの状態マシンを示す図である。
【図１２】ＤＡＴＰの状態マシンを示す図である。
【図１３】ＤＡＴＰの状態マシンを示す図である。
【図１４】コンテンツ変換のアーキテクチャＨ２Ｏを示す図である。
【図１５】クライアント／ＳＴＢ、ＳＧＷ、Ｈ２Ｏ、およびアプリケーション・サービス・プロバイダの間のメッセージ・シナリオを示す図である。
【図１６】クライアント／ＳＴＢ、ＳＧＷ、Ｈ２Ｏ、およびアプリケーション・サービス・プロバイダの間のメッセージ・シナリオを示す図である。
【図１７】クライアント／ＳＴＢ、ＳＧＷ、Ｈ２Ｏ、およびアプリケーション・サービス・プロバイダの間のメッセージ・シナリオを示す図である。
【図１８】クライアント／ＳＴＢ、ＳＧＷ、Ｈ２Ｏ、およびアプリケーション・サービス・プロバイダの間のメッセージ・シナリオを示す図である。
【図１９】クライアント／ＳＴＢ、ＳＧＷ、Ｈ２Ｏ、およびアプリケーション・サービス・プロバイダの間のメッセージ・シナリオを示す図である。
【図１】
2004527028.tif 000003
【図２】
2004527028.tif 000004
【図３】
2004527028.tif 000005
【図４】
2004527028.tif 000006
【図５】
2004527028.tif 000007
【図６】
2004527028.tif 000008
【図７】
2004527028.tif 000009
【図８】
2004527028.tif 000010
【図９】
2004527028.tif 000011
【図１０】
2004527028.tif 000012
【図１１】
2004527028.tif 000013
【図１２】
2004527028.tif 000014
【図１３】
2004527028.tif 000015
【図１４】
2004527028.tif 000016
【図１５】
2004527028.tif 000017
【図１６】
2004527028.tif 000018
【図１７】
2004527028.tif 000019
【図１８】
2004527028.tif 000020
【図１９】
2004527028.tif 000021
【国際公開パンフレット】
2004527028.tif 000022
2004527028.tif 000023
2004527028.tif 000024
2004527028.tif 000025
2004527028.tif 000026
2004527028.tif 000027
2004527028.tif 000028
2004527028.tif 000029
2004527028.tif 000030
2004527028.tif 000031
2004527028.tif 000032
2004527028.tif 000033
2004527028.tif 000034
2004527028.tif 000035
2004527028.tif 000036
2004527028.tif 000037
2004527028.tif 000038
2004527028.tif 000039
2004527028.tif 000040
2004527028.tif 000041
2004527028.tif 000042
2004527028.tif 000043
2004527028.tif 000044
2004527028.tif 000045
2004527028.tif 000046
2004527028.tif 000047
2004527028.tif 000048
2004527028.tif 000049
2004527028.tif 000050
2004527028.tif 000051
2004527028.tif 000052
2004527028.tif 000053
2004527028.tif 000054
2004527028.tif 000055
2004527028.tif 000056
2004527028.tif 000057
2004527028.tif 000058
2004527028.tif 000059
2004527028.tif 000060
2004527028.tif 000061
2004527028.tif 000062
2004527028.tif 000063
2004527028.tif 000064
2004527028.tif 000065
2004527028.tif 000066
2004527028.tif 000067
2004527028.tif 000068
2004527028.tif 000069
2004527028.tif 000070
2004527028.tif 000071
2004527028.tif 000072
2004527028.tif 000073
2004527028.tif 000074
2004527028.tif 000075
2004527028.tif 000076
2004527028.tif 000077
2004527028.tif 000078
2004527028.tif 000079
2004527028.tif 000080
2004527028.tif 000081
2004527028.tif 000082
2004527028.tif 000083
2004527028.tif 000084
2004527028.tif 000085
2004527028.tif 000086
2004527028.tif 000087
2004527028.tif 000088
2004527028.tif 000089
2004527028.tif 000090
2004527028.tif 000091
2004527028.tif 000092
2004527028.tif 000093
2004527028.tif 000094
2004527028.tif 000095
2004527028.tif 000096
2004527028.tif 000097
2004527028.tif 000098
2004527028.tif 000099
2004527028.tif 000100
2004527028.tif 000101
2004527028.tif 000102
2004527028.tif 000103
2004527028.tif 000104
2004527028.tif 000105
2004527028.tif 000106
2004527028.tif 000107
2004527028.tif 000108
【国際公開パンフレット（コレクトバージョン）】
2004527028.tif 000109
2004527028.tif 000110
【手続補正書】
【提出日】平成15年6月23日(2003.6.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
インタラクティブ・テレビ・システムで通信を実現する方法であって、
リモート・クライアント・デバイス（２１２）から届き、ユーザ識別子を含む、リモート・アプリケーション・サーバ（２００）宛の第１のメッセージをサービス・プラットフォーム（５０）で受信することと、
受信したユーザ識別子をセッション識別子にマッピングすることと、
第１のメッセージに対応する第２のメッセージをリモート・アプリケーション・サーバに伝達することを含み、
第２のメッセージにセッション識別子が含まれ、ユーザ識別子が含まれていない方法。
【請求項２】
さらにセッション識別子をユーザ識別子に解決することを含み、サービス・プラットフォームのみが、対応するユーザ識別子にセッション識別子を解決するように構成されている請求項１に記載の方法。
【請求項３】
サービス・プラットフォームがさらにユーザ情報を格納するように構成されている受信契約者プロファイル・データベースを備え、さらに
サービス・プラットフォーム内で、データベースへのアクセス要求を示すメッセージを受信することと、
サービス・プラットフォーム内で定められている規則に基づき要求されたアクセスを許可または却下することを含み、
前記規則で、メッセージの発信元であるアプリケーションの特定のアクセス権を指定する請求項２に記載の方法。
【請求項４】
さらに前記メッセージに対応するユーザ識別子を使用して前記データベースにアクセスすることを含む請求項３に記載の方法。
【請求項５】
さらに前記アプリケーション・サーバを発信元とする前記メッセージを検出することへの応答として、前記メッセージに含まれているセッション識別子をユーザ識別子にマッピングすることを含む請求項４に記載の方法。
【請求項６】
前記規則がサービス・プラットフォームのオペレータとアプリケーション・サーバのオペレータとの間の事業契約に対応する請求項５に記載の方法。
【請求項７】
さらにクライアント・デバイスのトランスポート・プロトコルをアプリケーション・サーバのトランスポート・プロトコルと互換性のある形式に変換すること含む請求項５に記載の方法。
【請求項８】
さらに、
アプリケーション・サーバから受信したコンテンツをクライアント・デバイスと互換性のある形式に変換することと、
クライアント・デバイスから受信したコンテンツをアプリケーション・サーバと互換性のある形式に変換することを含む請求項７に記載の方法。
【請求項９】
インタラクティブ・テレビ・システムで通信しやすくする装置であって、
リモート・クライアント・デバイス（２１２）との通信のため結合されている第１の通信リンクと、リモート・アプリケーション・サーバ（２００）との通信のため結合されている第２の通信リンクと、クライアント・デバイスからユーザ識別子を含む第１のメッセージを受信するように結合されているサービス・プラットフォーム（５０）を備え、前記のサービス・プラットフォームが、受信したユーザ識別子をセッション識別子にマッピングし、第１のメッセージに対応する第２のメッセージをリモート・アプリケーション・サーバに伝達するように構成されており、第２のメッセージにセッション識別子が含まれ、ユーザ識別子が含まれていない装置。
【請求項１０】
サービス・プラットフォームのみがユーザ識別子にセッション識別子を解決するように構成されている請求項９に記載の装置。
【請求項１１】
サービス・プラットフォームがさらにユーザ情報を格納するように構成されている受信契約者プロファイル・データベースを備える請求項１０に記載の装置。
【請求項１２】
サービス・プラットフォームがさらに、
データベースへのアクセス要求を示すメッセージを受信し、
サービス・プラットフォーム内で定められている規則に基づき要求されたアクセスを許可または却下するように構成されたトランザクション制御メカニズム（１０６、２２６）を備え、
前記規則で、メッセージの発信元であるアプリケーションの特定のアクセス権を指定する請求項１１に記載の装置。
【請求項１３】
前記サービス・プラットフォームがさらに、前記メッセージに対応するユーザ識別子を使用して前記データベースにアクセスするように構成されている請求項１２に記載の装置。
【請求項１４】
アプリケーション・サーバを発信元とする前記メッセージを検出することへの応答として、前記サービス・プラットフォームがさらに、前記メッセージに含まれているセッション識別子をユーザ識別子にマッピングするように構成されている請求項１３に記載の装置。
【請求項１５】
前記規則がサービス・プラットフォームのオペレータとアプリケーション・サーバのオペレータとの間の事業契約に対応する請求項１２に記載の装置。
【請求項１６】
前記サービス・プラットフォームがさらに、クライアント・デバイスのトランスポート・プロトコルをアプリケーション・サーバのトランスポート・プロトコルと互換性のある形式に変換するように構成されているトランスポート変換メカニズム（１０８、２４６）を備える請求項１２に記載の装置。
【請求項１７】
前記サービス・プラットフォームがさらに、
アプリケーション・サーバから受信したコンテンツをクライアント・デバイスと互換性のある形式に変換し、
クライアント・デバイスから受信したコンテンツをアプリケーション・サーバと互換性のある形式に変換するように構成されたコンテンツ制御メカニズム（２０４、２４８）を備える請求項１６に記載の装置。
【請求項１８】
クライアント・デバイスが、ネットワーク・モデルのクライアント・デバイス・データ・リンク、ネットワーク、トランスポート、およびセッション層のうちの少なくとも１つの層に置かれている通信トランスポート・プロトコルを備え、そのクライアント・デバイスはさらに、クライアント互換通信トランスポート・プロトコルで実行されるアプリケーション・レベル通信プロトコルを備える請求項９に記載の装置。
【請求項１９】
アプリケーション・レベル通信プロトコルが、追加されたドメイン固有プロトコルの新しいＸＭＬ文書型定義を作成することによりアプリケーション・レベル・プロトコルのサブセットとしてドメイン固有のプロトコルの追加を可能にするように構成されている請求項１８に記載の装置。
【請求項２０】
サービス・プラットフォームが、放送チャネルおよびポイントツーポイント・チャネルを介してクライアント・デバイスと通信するように構成されている請求項９に記載の装置。
【請求項２１】
分散コンピュータ・システムによって命令が実行されたときに、
ユーザ識別子を含む、リモート・アプリケーション・サーバ（２００）宛の第１のメッセージをクライアント・デバイス（２１２）から伝達すること、
受信したユーザ識別子をセッション識別子にマッピングし、および
第１のメッセージに対応し、セッション識別子が含まれるがユーザ識別子は含まれていない第２のメッセージを伝達するリモート・サービス・プラットフォーム（５０）で第１のメッセージを受信すること、並びに
リモート・アプリケーション・サーバ（２００）で第２のメッセージを受信すること
を分散コンピュータ・システムに実行させる命令を格納するコンピュータ読取り可能媒体。
【請求項２２】
前記命令が実行されたときに、サービス・プラットフォームをセッション識別子をユーザ識別子に解決させるようにさらに構成し、サービス・プラットフォームのみが、対応するユーザ識別子にセッション識別子を解決するように構成される請求項２１に記載のコンピュータ読取り可能媒体。
【請求項２３】
サービス・プラットフォームがさらにユーザ情報を格納するように構成されている受信契約者プロファイル・データベースを備え、前記命令が実行されたときに、サービス・プラットフォームが
データベースへのアクセス要求を示すメッセージを受信し、
サービス・プラットフォーム内で定められている規則に基づき要求されたアクセスを許可または却下するようにさらに構成され、
前記規則で、メッセージの発信元であるアプリケーションの特定のアクセス権を指定する請求項２２に記載のコンピュータ読取り可能媒体。
【請求項２４】
前記命令が実行されたときに、サービス・プラットフォームが前記メッセージに対応するユーザ識別子を使用して前記データベースにアクセスするように、さらに構成される請求項２３に記載のコンピュータ読取り可能媒体。
【請求項２５】
前記命令が実行されたときに、アプリケーション・サーバを発信元とする前記メッセージを検出することへの応答として、サービス・プラットフォームが前記メッセージに含まれているセッション識別子をユーザ識別子にマッピングするように、さらに構成される請求項２４に記載のコンピュータ読取り可能媒体。
【請求項２６】
前記規則がサービス・プラットフォームのオペレータとアプリケーション・サーバのオペレータとの間の事業契約に対応する請求項２５に記載のコンピュータ読取り可能媒体。
【請求項２７】
前記命令が実行されたときに、サービス・プラットフォームがクライアント・デバイスのトランスポート・プロトコルをアプリケーション・サーバのトランスポート・プロトコルと互換性のある形式に変換するように、さらに構成される請求項２５に記載のコンピュータ読取り可能媒体。
【請求項２８】
前記命令が実行されたときに、サービス・プラットフォームが、
アプリケーション・サーバから受信したコンテンツをクライアント・デバイスと互換性のある形式に変換し、
クライアント・デバイスから受信したコンテンツをアプリケーション・サーバと互換性のある形式に変換するように、さらに構成される請求項２７に記載のコンピュータ読取り可能媒体。
【国際調査報告】
2004527028.tif 000111
2004527028.tif 000112
2004527028.tif 000113