JP6014870B2 - ストリーミング・メディア・コンテンツのリアルタイム・トランスマックス変換の方法およびシステム - Google Patents

Description

後述の実施形態は、ストリーミング・メディアの分野に関し、特に、ビデオおよびオーディオ・コンテンツのリアルタイムまたはオンデマンド・ストリーミングに関する。

「オーバー・ザ・トップ」（ＯＴＴ）マルチメディア・サービスの市場はますます複雑になっている。多数のコンテンツ製作者がＯＴＴビデオ・コンテンツに対していわゆる３スクリーン手法を採用している（たとえば、テレビジョン、インターネット、モバイル・デバイスなど）。デバイス製造業者はストリーミング機能をそれぞれの製品に直接組み込んでいる。従来の業者は市場シェアの獲得または保持に努めており、一方、新しい業者が市場に参入している。

これらの様々なサービスに関して新しい規格が出現している。しかし、一般に容認されている共通要素として、ＨＴＴＰベースのアダプティブ・ストリーミングが使用されている。ＨＴＴＰすなわちハイパーテキストト・ランスファ・プロトコルはワールドワイド・ウェブ（ＷＷＷ）上の広く使用されている規格である。ＨＴＴＰが普及しているので様々なデバイス上、特に様々なネットワーク環境においてＨＴＴＰを使用するのが適切である。したがって、ＨＴＴＰを利用するＨＴＴＰベースのアダプティブ・ストリーミングは、エンド・ユーザの容認される体感品質（ＱｏＥ）を確保し、一方、任意のネットワーク上の任意のデバイス上で同じコンテンツを見る能力を実現するための適切な方法とみなされている。

マルチメディア（たとえば、ビデオおよびオーディオ）コンテンツに関する現在のＨＴＴＰベースのいくつかのアダプティブ・ストリーミング・ソリューションは、デバイスが、帯域幅が動的に変化する環境にあるときでも、良好なＱｏＥを実現する。特に、多くのアダプティブ・ストリーミング・ソリューションは現在、一般に、現在の帯域幅環境に応じて実現することのできる同じコンテンツを符号化した複数のコンテンツまたは同じコンテンツを選択的にスケーリング可能に符号化したコンテンツを使用している。

しかし、様々なストリーミング・ソリューションの各々は一般に、コンテンツ・フォーマッティング、クライアント検索プロトコルおよび再生プロトコル、ならびにビットレートを選択するための関連するアルゴリズムに対して異なる手法を使用する。基本的なコンテンツ符号化フォーマットのような共通要素が存在することもあるが、これらの手法は直接的な互換性を有さないことがある。さらに、ストリーミング・コンテンツを実現するために使用されるネットワーク・アーキテクチャ（たとえば、サーバ、デバイス、ソフトウェア）が異なることがある。

複数の競合する規格が存在すると仮定すると、コンテンツ製作者は、互いに互換性を有さない１つまたは複数の規格を使用しサポートすることを選択するという問題に直面する。たとえば、Ａｐｐｌｅ ｉＰｈｏｎｅ（登録商標）、ｉＰｏｄ（登録商標）、およびｉＰａｄ（登録商標）などのデバイスはＡｐｐｌｅストリーミング・ソリューションしかサポートしない。しかし、ＡｐｐｌｅソリューションがＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）ベースのデバイスによって直接サポートされることはない。逆に、Ｍｉｃｒｏｓｏｆｔスムース・ストリーミング手法がＡｐｐｌｅデバイス上で直接サポートされることはない。この問題は、コンテンツ製作者が、Ｇｏｏｇｌｅ ＡＮＤＲＯＩＤ（登録商標）オペレーティング・システムに基づくデバイスなどの他のデバイスをサポートする
ことを望むときにさらに深刻化する。

様々な機関がＨＴＴＰベースのアダプティブ・ストリーミングの規格を開発しているが、これらの規格の各々は結局、規格の対象となる用途に応じた特定の特異性を有する。たとえば、ＭＰＥＧはＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ
ｏｖｅｒ ＨＴＴＰ）を開発しており、３ＧＰＰは３ＧＰＰ自体の手法を定義しており、Ｗ３Ｃはメディア・フラグメントを開発している。

この環境を考えると、コンテンツ製作者は、様々な規格およびデバイスのすべてをサポートするかまたはいくつかの組み合わせをサポートしないでおくリスクをとらなければならない。

メディア・コンテンツを送受信することができる例示的なネットワークを示す図。 従来技術のストリーミング・システムを示す図。 別の従来技術のストリーミング・システムを示す図。 いくつかの実施形態による簡略化されたストリーミング・システムを示す図。 例示的なストリーミング・システムの一部である中間サーバの例示的な簡略化されたシステム・ブロック図。 図５のシステムの簡略化されたコール・フローを示す図。 時間軸上の例示的なビデオ・フラグメント・マッピングおよびオーディオ・フラグメント・マッピングを示す図。 中間サーバのセッション管理モジュールによって使用できる例示的な状態図。 図５の中間サーバに関する例示的な詳細なコール・フローを示す図。 初期マニフェスト要求を容認するための例示的なコール・フローを示す図。 拒絶された初期マニフェスト要求に関する例示的なコール・フローを示す図。 無効なオリジン・サーバ・アドレスを含む初期マニフェスト要求に関する例示的なコール・フローを示す図。 有効なフラグメント要求に関する例示的なコール・フローを示す図。 無効なフラグメント要求に関する例示的なコール・フローを示す図。 無効なセッション識別子（ＵＵＩＤ）を含むコンテンツ・フラグメント要求に関する例示的なコール・フローを示す図。

第１の広義の態様では、ストリーミング・メディア・コンテンツ・アイテムをオリジン・サーバからクライアント・デバイスに配信するためのシステムであって、オリジン・サーバがストリーミング・メディア・コンテンツ用の配信元コンテナ・フォーマットおよび配信元配信フォーマットを有し、ストリーミング・メディア・コンテンツが配信元符号化フォーマットで符号化された第１の複数のコンテンツ・フラグメントを備えるシステムにおいて、クライアント配信フォーマットを使用してストリーミング・メディア・コンテンツ・アイテムの少なくとも要求される部分に関するクライアント要求をクライアントから受信し、クライアント要求がクライアント配信フォーマットであると判定し、クライアント要求に対応する中間要求を配信元配信フォーマットで生成するように構成されたマッピング・モジュールと、中間要求をサーバに送信し、ストリーミング・メディア・コンテンツ・アイテムの要求される部分に対応する第１の複数のコンテンツ・フラグメントのサブ
セットを受信するように構成された中間クライアント・モジュールであって、サブセットが、配信元配信フォーマットを使用してオリジン・サーバから配信元コンテナ・フォーマットで受信される中間クライアント・モジュールと、サブセットを配信元コンテナ・フォーマットからアンパックし、サブセットをクライアント・コンテナ・フォーマットにパックするように構成されたコンテナ変換モジュールであって、クライアント・コンテナ・フォーマットでパックされたサブセット中のコンテンツ・フラグメントが配信元符号化フォーマットで符号化されたままであるコンテナ変換モジュールと、クライアント配信フォーマットを使用してストリーミング・メディア・コンテンツ・アイテムをクライアント・コンテナ・フォーマットでクライアントに送信するように構成された中間サーバ・モジュールとを備えるシステムが提供される。

場合によっては、コンテナ変換モジュールは、第１の複数のコンテンツ・フラグメントを第２の複数のコンテンツ・フラグメントにリアセンブルすることによってストリーミング・メディア・コンテンツ・アイテムをクライアント・コンテナ・フォーマットにパックし、第２の複数のコンテンツ・フラグメントは第１の複数のコンテンツ・フラグメントとは異なる持続時間を有する。

場合によっては、マッピング・モジュールは、所定の配信フォーマットを使用して１つまたは複数の要求を送信し、応答が首尾よく受信されたかどうかを判定することによって、オリジン・サーバが配信元配信フォーマットで送信するように構成されていると判定してもよい。マッピング・モジュールは、クライアント要求を複数の所定の要求パターンと比較することによってクライアント要求がクライアント配信フォーマットであると判定してもよい。

中間サーバは、クライアント要求が受信されたときにストリーミング・セッションを開始するように構成されたセッション管理モジュールをさらに備えてもよい。
セッション管理モジュールは、クライアントからのフラグメント要求を監視することによってストリーミング・セッションに関するクライアントのセッション状態を判定するようにさらに構成されてもよい。

別の広義の態様では、ストリーミング・メディア・コンテンツ・アイテムをオリジン・サーバからクライアントに配信する方法であって、オリジン・サーバがストリーミング・メディア・コンテンツ用の配信元コンテナ・フォーマットおよび配信元配信フォーマットを有し、ストリーミング・メディア・コンテンツが配信元符号化フォーマットで符号化された第１の複数のコンテンツ・フラグメントを備える方法において、クライアント配信フォーマットを使用してストリーミング・メディア・コンテンツ・アイテムの少なくとも要求される部分に関するクライアント要求をクライアントから受信することと、クライアント要求がクライアント配信フォーマットであると判定することと、クライアント要求に対応する中間要求を生成することであって、配信元要求が配信元配信フォーマットであることと、中間要求をサーバに送信することと、ストリーミング・メディア・コンテンツ・アイテムの要求される部分に対応する第１の複数のコンテンツ・フラグメントのサブセットを受信することであって、サブセットが、配信元配信フォーマットを使用してオリジン・サーバから配信元コンテナ・フォーマットで受信されることと、サブセットを配信元コンテナ・フォーマットからアンパックし、サブセットをクライアント・コンテナ・フォーマットにパックすることであって、クライアント・コンテナ・フォーマットでパックされたサブセット中のコンテンツ・フラグメントが配信元符号化フォーマットで符号化されたままであることと、クライアント配信フォーマットを使用してストリーミング・メディア・コンテンツ・アイテムをクライアント・コンテナ・フォーマットでクライアントに送信することとを含む方法が提供される。

パッキングは、第１の複数のコンテンツ・フラグメントを第２の複数のコンテンツ・フラグメントにリアセンブルすることによって実行されてもよく、第２の複数のコンテンツ・フラグメントは第１の複数のコンテンツ・フラグメントとは異なる持続時間を有する。

この方法は、所定の配信フォーマットを使用して１つまたは複数の要求を送信し、応答が首尾よく受信されたかどうかを判定することによって、オリジン・サーバが配信元配信フォーマットで送信するように構成されていると判定することをさらに含んでもよい。

この方法は、クライアント要求を複数の所定の要求パターンと比較することによってクライアント要求がクライアント配信フォーマットであると判定することをさらに含んでもよい。

この方法は、クライアント要求が受信されたときにストリーミング・セッションを開始することをさらに含んでもよい。
この方法は、クライアントからのフラグメント要求を監視することによってストリーミング・セッションに関するクライアントのセッション状態を判定することをさらに含んでもよい。

別の広義の態様では、ストリーミング・メディア・コンテンツ・アイテムをオリジン・サーバからクライアント・デバイスに配信するためのシステムであって、オリジン・サーバがストリーミング・メディア・コンテンツ用の配信元コンテナ・フォーマットおよび配信元配信フォーマットを有し、ストリーミング・メディア・コンテンツが配信元符号化フォーマットで符号化された第１の複数のコンテンツ・フラグメントを備えるシステムにおいて、ストリーミング・メディア・コンテンツ・アイテムの少なくとも要求される部分に関する少なくとも１つのクライアント要求をクライアントから受信し、少なくとも１つのクライアント要求に対応する中間要求を生成するように構成されたマッピング・モジュールと、少なくとも１つのクライアント要求が受信されたときにストリーミング・セッションを開始するように構成されたセッション管理モジュールであって、少なくとも１つのクライアント要求を監視することによってストリーミング・セッションに関するクライアントのセッション状態を判定するようにさらに構成されたセッション管理モジュールと、中間要求をサーバに送信し、ストリーミング・メディア・コンテンツ・アイテムの要求される部分に対応する第１の複数のコンテンツ・フラグメントのサブセットを受信するように構成された中間クライアント・モジュールと、ストリーミング・メディア・コンテンツ・アイテムをクライアントに送信するように構成された中間サーバ・モジュールとを備えるシステムが提供される。

オリジン・サーバは、ストリーミング・メディア・コンテンツ用の配信元コンテナ・フォーマットおよび配信元配信フォーマットを有してもよく、マッピング・モジュールは、クライアント配信フォーマットを使用してクライアント要求を受信し、クライアント要求がクライアント配信フォーマットであると判定するように構成されてもよく、中間要求は配信元配信フォーマットであってもよく、第１の複数のコンテンツ・フラグメントのサブセットは、配信元配信フォーマットを使用してオリジン・サーバから配信元コンテナ・フォーマットで受信されてもよく、システムは、配信元コンテナ・フォーマットからサブセットをアンパックし、サブセットをクライアント・コンテナ・フォーマットにパックするように構成されたコンテナ変換モジュールをさらに備えてもよく、クライアント・コンテナ・フォーマットでパックされたサブセット中のコンテンツ・フラグメントは配信元符号化フォーマットで符号化されたままであってもよく、中間サーバ・モジュールは、クライアント配信フォーマットを使用してストリーミング・メディア・コンテンツ・アイテムをクライアント・コンテナ・フォーマットでクライアントに送信するように構成されてもよい。

セッション管理モジュールは、すべてのオープン・クライアント・セッションの状態を特定するようにさらに構成されてもよい。セッション管理モジュールは、所定のタイムアウト期間の後でセッション状態をイナクティブとマークするようにさらに構成されてもよい。セッション管理モジュールは、クライアント・セッションに関連するさらなるフラグメント要求が受信されたときにセッション状態をアクティブとマークするようにさらに構成されてもよい。

少なくとも１つのクライアント要求は複数のクライアント要求を含んでもよく、セッション状態は、複数のクライアント要求のタイミングに基づいて判定されてもよい。
タイミングが、複数のクライアント要求が順序を外れたフラグメントを求める要求であることを示し得るとき、シーク動作が決定されてもよい。タイミングが、実際の経過時間が複数のクライアント要求において要求されたフラグメントの再生時間を超えていることを示し得るとき、トリック再生動作が決定されてもよい。

別の広義の態様では、ストリーミング・メディアコンテンツ・アイテムをオリジン・サーバからクライアント・デバイスに配信するための方法であって、オリジン・サーバがストリーミング・メディア・コンテンツ用の配信元コンテナ・フォーマットおよび配信元配信フォーマットを有し、ストリーミング・メディア・コンテンツが配信元符号化フォーマットで符号化された第１の複数のコンテンツ・フラグメントを備える方法において、ストリーミング・メディア・コンテンツ・アイテムの少なくとも要求される部分に関する少なくとも１つのクライアント要求をクライアントから受信することと、少なくとも１つのクライアント要求に対応する中間要求を生成することと、少なくとも１つのクライアント要求が受信されたときにストリーミング・セッションを開始することと、少なくとも１つのクライアント要求を監視することによってストリーミング・セッションに関するクライアントのセッション状態を判定することと、中間要求をサーバに送信することと、ストリーミング・メディア・コンテンツ・アイテムの要求される部分に対応する第１の複数のコンテンツ・フラグメントのサブセットを受信することと、ストリーミング・メディア・コンテンツ・アイテムをクライアントに送信することとを含む方法が提供される。

オリジン・サーバは、ストリーミング・メディア・コンテンツ用の配信元コンテナ・フォーマットおよび配信元配信フォーマットを有してもよく、クライアント要求は、クライアント配信フォーマットを使用して受信されてもよく、中間要求は配信元配信フォーマットであってもよく、第１の複数のコンテンツ・フラグメントのサブセットは、配信元配信フォーマットを使用してオリジン・サーバから配信元コンテナ・フォーマットで受信されてもよく、この方法は、配信元コンテナ・フォーマットからサブセットをアンパックし、サブセットをクライアント・コンテナ・フォーマットにパックすることをさらに含んでもよく、クライアント・コンテナ・フォーマットでパックされたサブセット中のコンテンツ・フラグメントは配信元符号化フォーマットで符号化されたままであってもよく、ストリーミング・メディア・コンテンツ・アイテムは、クライアント配信フォーマットを使用してクライアント・コンテナ・フォーマットでクライアントに送信されてもよい。

この方法は、すべてのオープン・クライアント・セッションの状態を特定することをさらに含んでもよい。この方法は、所定のタイムアウト期間の後でセッション状態をイナクティブとマークすることをさらに含んでもよい。この方法は、クライアント・セッションに関連するさらなるフラグメント要求が受信されたときにセッション状態をアクティブとマークすることをさらに含んでもよい。

少なくとも１つのクライアント要求は複数のクライアント要求を含んでもよく、セッション状態は、複数のクライアント要求のタイミングに基づいて判定されてもよい。
タイミングが、複数のクライアント要求が順序を外れたフラグメントを求める要求であることを示し得るとき、シーク動作が決定されてもよい。タイミングが、実際の経過時間が複数のクライアント要求において要求されたフラグメントの再生時間を超えていることを示し得るとき、トリック再生動作が決定されてもよい。

本明細書で説明する実施形態のさらなる態様および利点は、以下の説明を添付の図面と一緒に理解することによって明らかになろう。
本明細書で説明するシステムおよび方法の実施形態をよりよく理解し、それらのシステムおよび方法をどのように実施し得るかをより明確に示すために、例として添付の図面を参照する。

図を単純にかつ明確にするために、図示の各要素が必ずしも縮尺通りに描かれているわけではないことが諒解されよう。たとえば、図を明確にするためにいくつかの要素の寸法は他の要素に対して誇張されている。さらに、参照符号は対応する要素または類似した要素を示すために必要に応じて各図間で繰り返されることがある。

本明細書で説明する例示的な実施形態を完全に理解できるように多数の特定の詳細が記載されることが諒解されよう。しかし、当業者には、本明細書で説明する実施形態がこれらの特定の詳細なしに実施できることが理解されよう。他の例では、本明細書で説明する実施形態を曖昧にすることのないように公知の方法、手順、および構成要素については詳細に説明していない。

本明細書で説明する方法、システム、およびデバイスの実施形態は、ハードウェアで実装されても、またはソフトウェアで実装されても、またはその両方の組み合わせで実装されてもよい。しかし、これらの実施形態は、少なくとも１つのプロセッサと、データ記憶システム（揮発性メモリおよび不揮発性メモリならびに／または記憶要素を含む）と、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスとをそれぞれ備えるプログラム可能なコンピュータ上で実行されるコンピュータ・プログラムで実装されることが好ましい。たとえば、プログラム可能なコンピュータは制限なしにネットワーク・サーバであってもよい。本明細書で説明する機能を実行し出力情報を生成するために入力データにプログラム・コードが適用される。出力情報は周知の方法で１つまたは複数の出力デバイスに適用される。

各プログラムは、コンピュータ・システムと通信するために高レベルの手続き型プログラミング言語および／もしくはスクリプト言語またはオブジェクト指向プログラミング言語および／もしくはスクリプト言語で実装されることが好ましい。しかし、プログラムは必要に応じてアセンブリ言語または機械言語で実装されてもよい。いずれの場合も、言語はコンパイラ型言語であってもまたはインタープリタ型言語であってもよい。そのような各コンピュータ・プログラムは、汎用または専用のプログラム可能なコンピュータによって読み取り可能な記憶媒体またはデバイス（たとえば、ＲＯＭまたは光ディスク）上に記憶され、記憶媒体またはデバイスが本明細書で説明する手順を実行するためにコンピュータによって読み取られたときにコンピュータを構成し動作させることが好ましい。本発明のシステムは、コンピュータ・プログラムを備えて構成される非一時的コンピュータ可読記憶媒体として実装されるとみなされてもよく、そのように構成された記憶媒体は、コンピュータを特定または所定の状態で動作させ、本明細書で説明する機能を実行させる。

さらに、記載の実施形態の方法、システム、およびデバイスは、１つまたは複数のプロセッサに対するコンピュータが使用可能な命令を保持する物理的な非一時的コンピュータ可読媒体を備えるコンピュータ・プログラム製品で配布することができる。媒体は、１つまたは複数のディスケット、コンパクト・ディスク、テープ、チップ、磁気記憶媒体また
は電子記憶媒体などを含む様々な形態で設けられてもよい。コンピュータが使用可能な命令はコンパイルされたコードおよびコンパイルされていないコードを含む様々な形態であってもよい。

現在、ＨＴＴＰベースのアダプティブ・ストリーミングには様々な異なる規格がある。テーブル１は５つの例示的な規格の様々な特性を記載している。

テーブル１に示すように、これらの規格の各々がＨＴＴＰをトランスポート・プロトコルとして使用し、各規格がＭＰＥＧ−４ ＡＶＣ（すなわち、Ｈ．２６４）規格をビデオ・コーデック（すなわち、符号化フォーマット）として使用してもよい。しかし、これらの共通要素を除いて、例示された規格はファイル・フォーマット方式および配信方式（すなわち、配信フォーマット）の点で著しく異なる。この実施形態を他のトランスポート・プロトコルおよびビデオ・コーデックとともに使用できることが諒解されよう。

コンテンツ製作者の観点からは、複数のプレーヤに同じコンテンツを配信すると、より多くのデバイスおよび規格がサポートされるので徐々に複雑さが増していく。有利なことに、各規格はＨ．２６４の同じ符号化フォーマット（ＭＰＥＧ−４ ＡＶＣ）をサポートすることができるので、コンテンツ製作者はサポートすべきビットレートごとに１度コンテンツを符号化するだけでよい。しかし、様々なコンテナ・フォーマットをサポートするにはコンテンツ・ファイルを複数回再作成し記憶する必要がある。特に、コンテンツ・ファイルが作成されるとき、符号化されたビデオ・コンテンツおよびオーディオ・コンテンツは一般に、特定のプレーヤまたは規格に適切なフォーマットに「マックス処理」される。

さらに、様々なフォーマットの各々のコンテンツをそれぞれの配信フォーマットを理解する特定のサーバによって配信する必要がある場合がある。

次にテーブル２を参照すると、例示的な１０分のビデオの３つの主要な配信フォーマットをサポートすることのストレージに対する影響が示されている。各配信フォーマットはオーバヘッドのわずかな差を有することがあるが、この例では説明を単純にするためにオーバヘッドは同じであると仮定した。

テーブル２を見ると分かるように、すべての３つのソリューションの間で符号化フォーマットは同一であってよいにもかかわらず、サポートされる規格ごとに異なる配信フォーマットが使用され、場合によってはこれに伴ってコンテナ・フォーマットが異なるので、必要なストレージ空間は事実上３倍になる。たとえば、Ａｐｐｌｅフラグメントは持続時間が１０秒に過ぎず、したがって、より多くのファイルが存在する。したがって、さらなるサポートされる各配信フォーマットによって、必要なストレージ空間が付随的に増大することがある。これによって、コンテンツ配信ネットワークの各端部に配置されたオリジン・サーバとキャッシング・サーバとの間でコンテンツを配信するための帯域幅コストが増大することもある。

上記に示した例示的な規格は一般に、コンテンツを時間的に揃えられたメディア・フラグメントにグループ分けする同じ基本的手法を、コンテンツを検索するためにどのフラグメントを再生すべきかを判定するインテリジェント・クライアントと一緒に使用する。しかし、コンテンツを検索するのに使用される実際の手法および配信フォーマットは規格ごとに異なる。

Ａｄｏｂｅ規格およびＭｉｃｒｏｓｏｆｔ規格によって使用される手法において、モデルは独自のＵＲＬ要求を発するクライアントに基づく。独自のＵＲＬ要求は、その要求を解釈し、要求されたコンテンツを含む適切なファイルから適切なデータを検索するサーバ・モジュールによって受信される。

サーバ・モジュールは、Ｍｉｃｒｏｓｏｆｔ ＩＩＳまたはＡｐａｃｈｅなどの既存のＨＴＴＰサーバにプラグインされてもよい。したがって、コンテンツ製作者が様々な配信フォーマットの各々を使用してコンテンツを各デバイスに配信することを望む場合、コンテンツ製作者は、様々なプラグインの各々を実行する異なるサーバを動作させることが必要になることがある。同様に、コンテンツ製作者は、サポートされる規格ごとに異なるネットワーク・インフラストラクチャを、複数のオーバレイ・ネットワークを管理するすべての関連するコストとともにサポートすることが必要になる場合がある。

様々なサーバ手法に加えて、個々のクライアント手法の各々が、所望のビットレートと、ネットワーク条件の変化に応答してビットレートをいつ調整すべきかとを選択するため
の各手法自体の特定のアルゴリズムと一緒に開発されている。これらのクライアントの各々は様々な条件において異なるように動作するように調整されてもよい。

この結果、各規格は、これらのクライアント・アルゴリズムにリンクされたコンテンツ作成のための関連する「ベスト・プラクティス」を有する。たとえば、Ｍｉｃｒｏｓｏｆｔは２秒〜５秒のフラグメント持続時間を使用することを推奨し、一方、Ａｐｐｌｅは１０秒のフラグメント持続時間を使用することを推奨している。Ａｄｏｂｅは目標とする展開に応じて複数の推奨持続時間を有する。

この複雑さに加えて、符号化フォーマットにおけるコーデック・プロファイルの問題がある。特に、特定のデバイスはＨ．２６４（ＭＰＥＧ−４ ＡＶＣ）コーデック規格によって定義されるプロファイルのサブセットしかサポートしないことがある。これらのプロファイルの選択およびサポートはコンテンツ製作者に委ねられることがある。その結果、コンテンツ製作者は単に、クライアント・デバイスおよびプレーヤ・タイプごとにコンテンツを再符号化しマックス処理することがあり、処理、記憶、およびコンテンツ管理の問題がさらに深刻化する。

トランスコーディングの概念は、メディア・ファイルまたはメディア・ストリームをあるコーデックから別のコーデックに再符号化する工程として理解される。関連する概念として、メディア・ファイルまたはメディア・ストリームの符号化パラメータを変更し、同じコーデックを使用して１つまたは複数の出力符号化ファイルまたは出力符号化ストリームを様々なビットレート（通常ソース・コンテンツよりも低いビットレート）で作成する工程であり得るトランスレーティングがある。

全復号工程および全再符号化工程と比較して計算要件を低減させる特定のトランスレーティング技法が開発されている。これらのトランスレーティング技法は主として、体感品質を向上させることを目的として、ビデオ・ストリームがネットワーク条件に基づいてクライアントに配信されるときにビデオ・ストリームのビットレートを変化させるのを可能にする方法として開発されている。そのような技法は配信元の符号化工程の間に下される決定（たとえば、動きベクトル情報の再使用など）を利用することができる。しかし、これらの技法のいくつかは、再符号化工程における様々な量子化パラメータのみをサポートし、一方、空間解像度の変更などの他のより柔軟な変更を可能にしない場合があるという点で制限されることがある。最近のＨＴＴＰベースのアダプティブ・ストリーミング手法では純粋なトランスレーティング手法の要件が低減している。

トランスコーディングおよびトランスレーティングに対して、本明細書では、コンテナ・フォーマットを特定のクライアントまたはプレーヤの要件を満たすように変更し、一方、基本的なコンテンツをその配信元の符号化形態に保持することを含むトランスマックス変換工程について説明する。トランスマックス変換を実行するための計算要件は、トランスレーティングまたはトランスコーディングの計算要件よりも数桁低くなり得る。これは、トランスマックス変換ではビデオ圧縮（コーデック）レベルでのコンテンツの処理を省略することができるからである。

現在すべてが通常Ｈ．２６４コーデックをサポートしているＨＴＴＰベースのアダプティブ・ストリーミング・ソリューション、およびそれに伴う低計算要件では、１組のコンテンツ・ファイルを使用して、さらなるトランスコーディングまたはトランスレーティングなしに、一般に使用されている様々なＨＴＴＰベースのアダプティブ・ストリーミング手法のうちの任意の手法をサポートするのを可能にするためにトランスマックス変換を使用することができる。

実際には、トランスマックス変換は、配信元の配信フォーマットにかかわらず既存のコンテンツを得て、適切な１組のファイル（たとえば、マニフェストおよびコンテンツ・フラグメント）を動的に作成し、クライアントの所望の配信フォーマットを使用して特定のクライアントに配信することができる１組のサービスを含んでもよい。

コンテンツ・デリバリ・ネットワーク（ＣＤＮ）では、トランスマックス変換モジュールが配置されているかぎりトランスマックス変換を「オンザフライ」または「オンデマンド」で実行してもよい。場合によっては、トランスマックス変換モジュールがオリジン・サーバ（すなわち、配信元コンテンツ・サーバ）の近くに配置されてもよい。他の場合には、トランスマックス変換モジュールがネットワーク内の他の場所（たとえば、クラウド内）に存在してもよい。最後に、場合によっては、トランスマックス変換モジュールがＣＤＮのエッジ・ノードまたはその近くに配置されてもよい。エッジ・ノードでオンザフライ・トランスマックス変換を実行することに伴うさらなる利点があり得る。

通常、汎用ウェブ・サーバのステートレス性によって、ＣＤＮのエッジ・ノードで提供することのできるサービスの性質が限定される。すなわち、汎用ウェブ・サーバは特定のクライアントからの各要求を追跡する能力が欠如しており、各要求を特定のコンテンツ・アイテムを求める過去または将来の要求に関連付けることがある。このようにストリーミング・セッションの状態を追跡する能力の欠如によってセッション特有のサービスを提供する能力が限定される。

本明細書では、特定のエンド・ユーザからの特定のコンテンツを求める要求を識別された特定のクライアント・ストリーミング・セッションにリンクすることのできるステートフル・セッション・モデルについて説明する。

いくつかの実施形態では、（たとえば、一意のセッション識別子を含む）各セッションに特有のコンテンツ・マニフェスト・ファイルを作成し、したがって、マニフェストまたはフラグメントのいずれかを求めるすべての将来の要求を同じセッションの一部として識別できるようにすることによって、このステートフル・セッション追跡を実現してもよい。セッションを識別し追跡する能力は、高いビットレート（たとえば、より高品質のストリーム）を異なる価格帯における顧客に制限すること、または加入タイプもしくは支払いタイプに基づいて再生時間を制限することなどの、さらなるサービスおよび展開モデルを迅速に処理するのを可能にする。この能力は、いくつかのパラメータに基づき得るポリシーを使用することによって実現されてもよい。

ポリシーはセッションごとに適用されてもよい。レート限定などのセッションごとのポリシーは、ユーザ・グループ（たとえば、ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍのすべてのユーザ）用の最大総帯域幅を割り当てる能力を利用することができる。個々の各ユーザのレート・シェイピングを行うことによって、このグループの利用可能な帯域幅をすべての同時ユーザ間に平等に分配することができる。時間制限またはダウンロード量などのポリシーは、セッションごとに適用されてもよい。さらに、ユーザはプレーヤ・タイプ、対象ＵＲＬ、ネットワーク・タイプなどのセッション・コンテキストに基づいてグループ分けされてもよい。

セッション追跡とオンザフライ・トランスマックス変換を組み合わせると、特定のクライアント・デバイスまたはプレーヤに特有であり得、かつクライアントの好ましい配信フォーマットを使用し得るマニフェストおよびコンテンツ・フラグメントを作成するのが可能になる。したがって、各セッションは一意であり得、その特定のセッションに最適化された異なるＱｏＥを実現する。

本明細書では、セッション追跡またはトランスマックス変換、あるいはその両方を使用することができる全逆トランスレーティング・プロキシシステムについて説明する。このシステムは既存のアダプティブ・ストリーミング環境にシームレスに組み込むことができる。特に、このシステムでは、配信元のコンテンツが特定の配信フォーマットであることは必要とされない。システムは、クライアントまたはサーバのいずれによって使用される特定の配信フォーマットにもかかわらず、クライアントからの各要求を配信元コンテンツ・サーバによってサポートされる配信フォーマットにトランスマックス変換または「変換」し、かつ配信元コンテンツ・サーバからの各要求をクライアントによってサポートされる配信フォーマットに（および、その反対の形に）トランスマックス変換または「変換」することができる。たとえば、コンテンツ製作者によって設置されたオリジン・サーバがＭｉｃｒｏｓｏｆｔスムース・ストリーミング配信フォーマットを使用する場合、システムは、要求側クライアントによって使用される配信フォーマットにはかかわらずにネイティブ・スムース・ストリーミング・プロトコルを使用して要求されたコンテンツを検索することができる。逆に、システムは要求されたコンテンツをクライアントによって使用される配信フォーマットにトランスマックス変換してもよい。したがって、コンテンツ製作者は、エンコーダ、コンテンツ管理システム、およびオリジン・サーバにおけるコンテンツ製作者の既存の投資のすべてを保持し利用することができる。多くのコンテンツ製作者にサービスを提供するＣＤＮの場合、場合によっては様々なストリーミング規格の各々を報告する必要がある複数のパラレル・エッジ・ノードの代わりにこのシステムが設置されてもよい。

次に図１を参照すると、ストリーミング・メディア・プレゼンテーションを送受信するための例示的なシステム１００が示されている。システム１００は、ネットワーク１１０と、１つまたは複数のオリジン・サーバ１２０および１２０’と、サーバ側プロキシ・サーバ１３０と、中間プロキシ・サーバ１５０と、１つまたは複数のエッジ・サーバ１６０および１６０’と、１つまたは複数のクライアント・デバイス１９０および１９０’とを備える。

ネットワーク１１０は、インターネットなどの１つまたは複数の専用網および公衆網で構成されたデータ・ネットワークであってもよい。
オリジン・サーバ１２０は、オーディオ・ファイルおよびビデオ・ファイルなどのメディア・コンテンツをＭＰＥＧ−４ ＡＶＣフォーマットで記憶するためのデータ・ストレージと、ＨＴＴＰベースのアダプティブ・ストリーミング・プロトコルを使用してメディア・コンテンツを提供するように構成されたメモリおよびプロセッサとを備えたネットワーク・サーバであってもよい。１実施形態において、オリジン・サーバ１２０は、Ｍｉｃｒｏｓｏｆｔスムース・ストリーミング配信フォーマットを使用してメディア・コンテンツを提供するように構成されてもよい。他の実施形態では、オリジン・サーバ１２０は、ＡｄｏｂｅまたはＡｐｐｌｅによって開発された配信フォーマットなどの別の配信フォーマットを使用してメディア・コンテンツを提供するように構成されてもよい。

オリジン・サーバ１２０’は一般に、オリジン・サーバ１２０とは異なる配信フォーマットをＨＴＴＰベースのアダプティブ・ストリーミングに使用し得ることを除いてオリジン・サーバ１２０に類似していてもよい。

エッジ・サーバ１６０は、メディア・コンテンツをキャッシュするためのデータ・ストレージと、本明細書で説明するような逆トランスレーティング・プロキシ・サービスおよびトランスマックス変換サービスを提供するように構成されたメモリおよびプロセッサとを備えるネットワーク・サーバまたは装置であってもよい。各エッジ・サーバ１６０は、地理的にまたはネットワークに関して（すなわち、比較的少ないネットワーク・ホップ内で）１つまたは複数のクライアント・デバイス１９０および１９０’に概ね近接して配置
されてもよい。

サーバ側プロキシ・サーバ１３０および中間プロキシ・サーバ１５０は、ネットワーク上の異なる位置に存在し得ることを除いて、エッジ・サーバ１６０に概ね類似していてもよい。たとえば、サーバ側プロキシ・サーバ１３０はオリジン・サーバ１２０の近くに位置してもよく、中間プロキシ・サーバ１５０はネットワーク１１０内（たとえば、「クラウド」内）に位置してもよい。

クライアント・デバイス１９０および１９０’は、パーソナル・コンピュータ、タブレット・コンピュータ、スマートフォン、ネットワーク対応テレビジョン、またはメディア・プレーヤなどのネットワーク対応マルチメディア再生デバイスであってもよい。各クライアント・デバイス１９０または１９０’は一般に、ストリーミング（たとえば、ＨＴＴＰベースのアダプティブ・ストリーミング）配信フォーマットを使用してネットワークを介してメディア・コンテンツを検索し、コンテンツをユーザに対して再生できるように復号するように構成し得るメモリおよびプロセッサを備える。クライアント・デバイス１９０’は、クライアント・デバイス１９０とは異なる配信フォーマットを使用するように構成され得ることを除いてクライアント・デバイス１９０に概ね類似していてもよい。

たとえば、１実施形態において、クライアント・デバイス１９０は、Ｍｉｃｒｏｓｏｆｔスムース・ストリーミング配信フォーマットを使用してメディア・コンテンツを検索するように構成されてもよい。他の実施形態では、クライアント・デバイス１９０は、ＡｄｏｂｅまたはＡｐｐｌｅによって開発された配信フォーマットなどの別の配信フォーマットを使用してメディア・コンテンツを検索するように構成されてもよい。

次に図２を参照すると、従来技術のストリーミング・システム２００が示されている。ストリーミング・システム２００は、オリジン・サーバ２２０と、クライアント・デバイス２９０と、キャッシング・サーバ２４０とを備える。オリジン・サーバ２２０は、オリジン・サーバ１２０に概ね類似していてもよい。同様に、クライアント・デバイス２９０は、クライアント・デバイス１９０または１９０’に概ね類似していてもよい。

キャッシング・サーバ２４０は、リバース・プロキシ・サービスを提供するように構成されたデータ・ストレージ、メモリ、およびプロセッサを備えるリバース・プロキシまたはキャッシング・サーバであってもよい。一般に、リバース・プロキシはクライアント・デバイス２９０などのクライアントから要求を受信するためのＨＴＴＰサーバを備える。リバース・プロキシは、オリジン・サーバ２２０などの上流側サーバに要求を送信するためのＨＴＴＰクライアントも備える。要求応答が受信されると、リバース・プロキシは応答データをクライアント・デバイス２９０に転送し、場合によっては応答データをローカルにキャッシュしてもよい。後で、リバース・プロキシが（たとえば、同じコンテンツを求める）別の同一の要求を受信した場合、リバース・プロキシはローカルにキャッシュされた応答データで直ちに応答することができる。したがって、リバース・プロキシは、場合によってはオリジン・サーバ２２０と直接通信する多数のクライアントにサービスを提供する負担を軽減することができる。

ストリーミング・システム２００において、オリジン・サーバ２２０、キャッシング・サーバ２４０、およびクライアント・デバイス２９０の各々は、「プロトコルＸ」と示された同じストリーミング配信フォーマットを使用して通信する。プロトコルＸは、周知のＨＴＴＰベースのアダプティブ・ストリーミング配信フォーマットのいずれかであってもよい。

次に図３を参照すると、オリジン・サーバ３２０と、キャッシング・サーバ３４０と、
クライアント・デバイス３９０とを備える別のストリーミング・システム３００が示されている。ストリーミング・システム３００の各要素はストリーミング・システム２００における対応する要素に概ね類似している。しかし、オリジン・サーバ３２０はプロトコルＸ配信フォーマットを使用して通信するように構成されるが、キャッシング・サーバ３４０とクライアント・デバイス３９０はどちらも異なる「プロトコルＹ」配信フォーマットのみを使用して通信するように構成される。

したがって、クライアント・デバイス３９０がクライアント配信フォーマットの要求をオリジン・サーバ３２０に（直接またはキャッシング・サーバ３４０を介して）送信することを試みると、配信フォーマットが認識されないのでオリジン・サーバ３２０はエラーで応答することがある。

次に図４を参照すると、簡略化された例示的なストリーミング・システム４００が示されている。ストリーミング・システム４００は、それぞれオリジン・サーバ３２０およびクライアント・デバイス３９０に概ね類似しているオリジン・サーバ４２０とクライアント・デバイス４９０とを備える。ストリーミング・システム４００は中間サーバ４６０をさらに備える。

中間サーバ４６０は、本明細書で説明するような逆トランスレーティング・プロキシ・サービスを提供するように構成されたデータ・ストレージ・デバイス、メモリ、およびプロセッサを備えてもよい。

図示のように、クライアント・デバイスはコンテンツ要求を生成し、プロトコルＹ（すなわち、クライアント配信フォーマット）を使用してその要求を中間サーバ４６０に送信する。中間サーバ４６０は、コンテンツ要求の配信フォーマットを識別し、プロトコルＹ配信フォーマットを使用してコンテンツ要求をオリジン・サーバ４２０に転送することを試みる。中間サーバ４６０は、オリジン・サーバ４２０がクライアント配信フォーマットをサポートしないと判定した場合、コンテンツ要求をオリジン・サーバ４２０によってサポートされる別の配信フォーマット（たとえば、プロトコルＸ）に変換する。

中間サーバ４６０は次いで、要求された応答コンテンツをオリジン・サーバ４２０から検索し、応答コンテンツをクライアント・デバイス４９０に配信できるようにクライアント配信フォーマットに変換し直すことができる。

したがって、オリジン・サーバ４２０とクライアント４９０はどちらも、そのそれぞれのサポートされる配信フォーマットを使用して通信することができる。さらに、いくつかの実施形態において、中間サーバ４６０は、検索されたコンテンツを配信元配信フォーマット、またはクライアント配信フォーマット、またはその両方で記憶（たとえば、キャッシュ）してもよく、それによって、後でさらに別の配信フォーマットを使用して着信し得る別の要求に応答してこのコンテンツを配信することができる。

リバース・プロキシは、ＨＴＴＰサービスのコンテキストで広く設置されており、したがって、要求を容認して適切なホスト（たとえば、オリジン・サーバ）に転送するための技術はよく理解されている。しかし、周知のリバース・プロキシは一般に、クライアント・デバイスから受信された同じ要求ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を転送するに過ぎない。

これに対して、中間サーバ４６０は、オリジン・サーバによってサポートされる配信フォーマット、および本明細書で説明するいくつかの他の因子に基づいて、受信される要求ＵＲＬを変更してもよい。

受信される要求ＵＲＬ（すなわち、クライアント要求ＵＲＬ）は一般に、３つの基本的なコンポーネント、すなわち、ＵＲＬ内のオリジン・サーバのホスト名を表す「ドメイン」、特定のリソースを識別するためにオリジン・サーバによって使用されるディレクトリ構造またはパス構造を表す「ロケーション」と、マニフェストまたはコンテンツ・フラグメントなどの、特定のリソースを識別する要求されたＵＲＬの部分を表すメディア識別子を含む。

たとえば、Ａｐｐｌｅ配信フォーマットを使用するクライアントによるマニフェスト要求の場合、クライアント要求ＵＲＬは「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ＡＢＲ／ｖｉｄｅｏ１／ＢＢＢ．ｍ３ｕ８」であってもよい。したがって、ドメインは「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」であり、パスは「／ＡＢＲ／ｖｉｄｅｏ１／」であり、メディア識別子は「ＢＢＢ．ｍ３ｕ８」である。

少なくともいくつかの実施形態において、ＵＲＬのドメイン・コンポーネントおよびパス・コンポーネントは変更されないままであってもよい。しかし、メディア識別子はオリジン・サーバによってサポートされる配信フォーマット（すなわち、配信元配信フォーマット）の要件に応じて変更されてもよい。

Ａｐｐｌｅ配信フォーマットの上記の例において、オリジン・サーバがＭｉｃｒｏｓｏｆｔスムース・ストリーミング配信フォーマットしかサポートしない場合、メディア識別子は「ＢＢＢ．ｍ３ｕ８」から「ＢＢＢ．ｉｓｍ／Ｍａｎｉｆｅｓｔ」に変更される。ドメインおよびパスは元のままであってもよい。

次に図５を参照すると、ストリーミング・システム５００の一部である中間サーバ５６０の例示的な簡略化されたシステム・ブロック図が示されている。ストリーミング・システム５００は、ストリーミング・システム４００に概ね類似している。同様に、各オリジン・サーバ５２０およびクライアント・デバイス５９０はそれぞれ、オリジン・サーバ４２０およびクライアント・デバイス４９０に概ね類似してもよい。

中間サーバ５６０は概念上、データ・プレーン、コントロール・プレーン、およびマネジメント・プレーンを含む３つのプレーンとして構成される。
ＨＴＴＰサーバ５６６（中間サーバ・モジュールとも呼ばれることもある）はクライアント・デバイス５９０から（たとえば、クライアント要求ＵＲＬを含む）ＨＴＴＰ要求を受信し、受信された要求をコンテンツ・ジェネレータ５６４に転送するように構成されてもよい。ＨＴＴＰサーバ５６６は、コンテンツ・ジェネレータ５６４から受信されたときに、ＨＴＴＰ要求に対応する応答データを配信するように構成されてもよい。

ＨＴＴＰサーバ５６６は、各ＨＴＴＰ要求の初期妥当性検査を実行し、たとえば、要求をＨＴＴＰプロトコルに適合させてもよい。一般に、ＨＴＴＰサーバ５６６は、高性能を実現し、多数の同時接続を可能にするように最適化されてもよい。

ＨＴＴＰクライアント５６２（中間クライアント・モジュールと呼ばれることもある）は、コンテンツ・ジェネレータ５６４からＨＴＴＰ要求を受信し、要求を適切なオリジン・サーバ５２０に転送するように構成されてもよい。同様に、ＨＴＴＰクライアント５６２は、ＨＴＴＰ要求に応答して応答データが各オリジン・サーバ５２０から受信されたときに応答データをコンテンツ・ジェネレータ５６４に配信するように構成されてもよい。一般に、ＨＴＴＰクライアント５６２は、高性能（たとえば、高スループット）を実現するように最適化されてもよい。

コンテンツ・ジェネレータ５６４は、ある構成要素（たとえば、ＨＴＴＰサーバ５６６、ＨＴＴＰクライアント５６２、コントロール・プレーン）から別の構成要素に要求を移動し、他の構成要素の各々間で要求同士をリンクするように構成されてもよい。さらに、コンテンツ・ジェネレータ５６４は要求を解析して要求を最もうまく実現するにはどうすればよいかを判定する。

たとえば、コンテンツ・ジェネレータ５６４は、プロトコルＸ配信フォーマットを使用する要求の宛先がプロトコルＹ配信フォーマットを使用するオリジン・サーバであることを特定し、したがって、この要求を実現するにはプロトコルＹ−Ｘトランスマクサが必要であると判定してもよい。

さらに、コンテンツ・ジェネレータ５６４はポリシーおよびクライアント・セッション情報をコントロール・プレーン（またはマネジメント・プレーン）から検索してクライアント要求を実現すべきかどうかまたはクライアント要求をどのように実現すればよいかを判定してもよい。

マネジメント・プレーンはポリシーを記憶するためのポリシー・モジュール５７０と、構成設定を記憶するための構成モジュール５７２と、システムに関する統計を記憶し追跡するための統計追跡モジュール５７４と、ログを記憶するためのログ・モジュール５７６と、システム・イベントを追跡するためのイベント・モジュール５７８とを備えてもよい。

コンテンツ・ジェネレータ５６４は、要求および応答のあるアダプティブ・ストリーミング配信フォーマットから別のアダプティブ・ストリーミング配信フォーマットへの変換を担当する１つまたは複数のトランスマクサ５６５を備えてもよい。各トランスマクサ５６５は、イングレス配信フォーマットとエグレス配信フォーマットの両方に特有であってもよい。たとえば、Ｍｉｃｒｏｓｏｆｔスムース・ストリーミング−ＡｐｐｌｅトランスマクサはＭｉｃｒｏｓｏｆｔスムース・ストリーミング−Ａｄｏｂｅトランスマクサとは異なる可能性が高い。

各トランスマクサ５６５はクライアント要求を解析して、クライアント要求が有効な要求である（たとえば、配信フォーマット要件に適合している）かどうかを判定すること、要求がマニフェストを求める要求かそれともコンテンツ・フラグメントを求める要求かを判定することなどを行うように構成されてもよい。

クライアント要求が複数のオリジン・サーバ要求を実現することを求める場合、適切なトランスマクサ５６５が、クライアント要求を実現するのにどのオリジン・サーバ要求が必要であるかを判定し、対応する要求を生成して転送してもよい。

トランスマクサ５６５は、マニフェスト要求およびコンテンツ・フラグメント要求とマニフェスト応答およびコンテンツ・フラグメント応答との両方を配信元配信フォーマットとクライアント配信フォーマットとの間で変換してもよい。

いくつかの実施形態において、トランスマクサ５６５は２つ以上のモジュールで構成される。第１のモジュール、すなわちマッピング・モジュールは、マニフェスト・サービスおよびプロトコル・サービスを提供することができ、一方、第２のモジュール、すなわち、コンテナ変換モジュールはフラグメント再パッケージング・サービスを提供する。再パッケージングは２つの機能、すなわち、抽出（たとえば、配信元フラグメントからサンプルを取り出す工程）およびパッキング（たとえば、サンプルをクライアントにフラグメント配信できるように新しいコンテナ・フォーマットにする工程）を含む。

コントロール・プレーンは主としてセッション管理モジュール５６８を備えてもよい。セッション管理モジュール５６８はクライアント・デバイス５９０によって開始されたクライアント・セッションを管理し、セッションベースのポリシー情報または構成情報をコンテンツ・ジェネレータ５６４に供給する働きをする。したがって、セッション管理モジュール５６８は様々なマネジメント・プレーン・コンポーネントと対話することができる。さらに、セッション管理モジュール５６８は、セッション管理モジュール５６８とコンテンツ・ジェネレータ５６４との対話に基づいてクライアント・セッション情報を作成し、読み取り、更新してもよい。

セッション管理モジュール５６８は、抽出工程に必要な関連する情報およびコンテキストを含み得るアクティブなクライアント・セッション・テーブルを維持してもよい。
セッション管理モジュール５６８は、コンテンツ・ジェネレータ５６４と協働してクライアント・セッション・データを高速に参照することができる。

いくつかの実施形態において、セッション管理モジュール５６８は、構成されたポリシーのテーブルを維持すること、（たとえば、クライアント属性、ドメイン属性、およびコンテンツ属性に基づいて）ポリシーを決定してクライアントに割り当てること、ならびに統計収集および報告を含み得るポリシー管理機能を実行してもよい。

統計収集および報告は、クライアント・セッション更新情報をロギング・サーバまたはデータベースに送り、セッションがいつ確立され無効化されたかを記録することを含んでもよい。

次に図６を参照すると、図５のシステムに関する簡略化されたコール・フローが示されている。
変換工程に固有の問題の１つは、ストリーミング・セッションの開始時には中間サーバの情報が限定されることである。マニフェスト要求が初めてクライアント・デバイスから受信されたときには、配信元配信フォーマットがクライアント要求ＵＲＬから容易に明らかにならないことがある。たとえば、オリジン・サーバがマニフェスト要求を実現するのに使用することのできる複数の配信元配信フォーマットをサポートすることがある。したがって、中間サーバ５６０はクライアント配信フォーマットから配信元配信フォーマットへの適切な変換を判定しなければならない。適切な変換が特定された後、中間サーバは配信元マニフェストを検索し、クライアント・マニフェストを生成してもよい。場合によっては、中間サーバは要求ＵＲＬに対応する配信元配信フォーマットを記憶し、その要求ＵＲＬに関する将来のマニフェスト要求およびコンテンツ・フラグメント要求を迅速に処理するのを可能にしてもよい。

クライアント要求が初めて受信されるとき、コンテンツ・ジェネレータ５６４はその要求が初期マニフェスト要求であるかどうかを特定することを試みてもよい。たとえば、コンテンツ・ジェネレータ５６４は要求ＵＲＬを調べ、あらかじめコンテンツ・ジェネレータ５６４によって生成されたかまたは使用されており、セッションがすでに存在することを示す一意の識別子（たとえば、ＵＵＩＤ）を含むかどうかを判定し、要求は初期マニフェスト要求ではないと判定することができる。

より一般的にすべての種類のクライアント要求に関して、コンテンツ・ジェネレータ５６４は、ＨＴＴＰ要求のＵＲＬを解析し、どの配信フォーマットが使用されているかを示す特定のシグナチャがＵＲＬに含まれているかどうかと、要求に対処するにはどのトランスマクサ５６５を使用すべきかとを判定してもよい。各配信フォーマットは、そのマニフェスト要求フォーマットの中に一意の特定のシグナチャを有する。たとえば、Ｍｉｃｒｏ
ｓｏｆｔスムース・ストリーミング配信フォーマットは、「ＸＸＸＸＸ．ｉｓｍ／Ｍａｎｉｆｅｓｔ」の形をしたＵＲＬのメディア識別子コンポーネントを有する。ここで、ＸＸＸＸＸはメディア・アセットの名称である。別の例において、Ａｄｏｂｅ配信フォーマットは．ｆ４ｍというファイル拡張子を使用してマニフェストを表す。同様に、Ａｐｐｌｅ配信フォーマットは．ｍ３ｕ８というファイル拡張子を使用してマニフェストを表す。したがって、いくつかの実施形態において、コンテンツ・ジェネレータ５６４は、要求がマニフェストに対応するかどうかを判定するうえで要求ＵＲＬのメディア識別子コンポーネントを使用するだけでよい。

マニフェスト・ファイルは一般に、マルチメディア・アイテムを構成するコンテンツ・フラグメントのインデックスを提示し、利用可能なストリーミング・オプションに関するメタデータを提示するために使用される。たとえば、マニフェスト・ファイルは、配信フォーマット・タイプ、配信フォーマット・バージョン、タイムスケール、コンテンツ持続時間、フラグメント持続時間、フラグメント符号化パラメータ（たとえば、ビットレート、コーデック、サイズ）、フラグメントＵＲＬまたはＵＲＬテンプレート、およびその他のデータを指定してもよい。

したがって、マニフェストは、クライアント・デバイスがサポートされる様々なビットレート、ビデオおよびオーディオがどのように符号化されているか、クライアントは特定のフラグメントを求める要求をどのように生成すればよいかを判定するのに十分な情報をクライアント・デバイスに提示する。

例示的なＭｉｃｒｏｓｏｆｔスムース・ストリーミング・マニフェスト・ファイルを以下に示す。

Ｍｉｃｒｏｓｏｆｔスムース・ストリーミング配信フォーマットに対して、Ａｐｐｌｅ
ＨＬＳ配信フォーマットは、初期マニフェストがさらに低いレベルのマニフェストを指す多層マニフェスト手法を使用する。初期マニフェストを以下に示す。

上記の３０００００ｋｂｐｓストリームについてのより低いレベルのマニフェストを以下に示す。

これに対して、Ａｄｏｂｅ配信フォーマットは、フラグメント番号と、マニフェスト内に符号化され圧縮された「ブートストラップ」と呼ばれるフィールド内のフラグメント番号に関連するタイムラインとを特定する。Ａｄｏｂｅマニフェストの例を以下に示す。

配信フォーマット・タイプごとのマニフェスト・ファイル・フォーマットが著しく異なることが諒解されよう。この結果、要求ＵＲＬタイプも異なる。したがって、配信フォーマット・タイプは通常、要求ＵＲＬのパターンマッチングを行うことによって判定され得る。パターンマッチングを使用すると、将来、新しい配信フォーマット・タイプおよび配信フォーマット・バージョンが開発されたときに、更新済みのパターンマッチ定義によって中間サーバ５６０を容易に更新することができる。

再び図６を参照すると分かるように、６０５において、クライアント・デバイス５９０は（マニフェスト要求ＵＲＬを含む）クライアント要求を中間サーバ５６０に送信する。コンテンツ・ジェネレータ５６４はマニフェスト要求ＵＲＬを特定し、要求を適切なトランスマクサ５６５に渡す。

オリジン・サーバ５２０が中間サーバ５６０によって知られている場合、トランスマクサ５６５は直ちにオリジン・サーバ５２０の適切なマニフェスト要求ＵＲＬを生成し、その要求を６１０において送信してもよい。

オリジン・サーバ５２０が知られていない場合、トランスマクサ５６５は、１度に１つのマニフェスト要求ＵＲＬを生成してオリジン・サーバ５２０に転送することによって、オリジン・サーバ５２０によってサポートされる配信フォーマット・タイプを特定することを試みてもよい。オリジン・サーバ５２０が生成された特定のＵＲＬを拒絶した（たとえば、ＨＴＴＰ４０４エラー応答が返された）場合、トランスマクサ５６５は応答が首尾よく受信されるまでこの工程を繰り返してもよい。この反復的な工程は、トランスマクサ
５６５が考えられるすべての知られたマニフェスト要求ＵＲＬが試されたときに停止されてもよい。

各トランスマクサ５６５はマニフェスト構成パターンを指定する独自の構成ファイルを有してもよい。１実施形態において、構成パターンは、以下でテーブル３に示すようにタグ値対を使用して指定されてもよい。

したがって、ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｖｉｄｅｏ＿ｓｔｏｒａｇｅ／ｓｕｐｅｒｖｉｄｅｏ．ｍ３ｕ８という例示的な要求ＵＲＬの場合、［ＢＡＳＥ＿ＵＲＬ］は「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｖｉｄｅｏ＿ｓｔｏｒａｇｅ」であり、［ＤＯＭＡＩＮ＿ＵＲＬ］は「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ」であり、［ＬＯＣＡＴＩＯＮ＿ＵＲＬ］は「ｖｉｄｅｏ＿ｓｔｏｒａｇｅ」であり、［ＭＥＤＩＡ＿ＵＲＬ］は「ｓｕｐｅｒｖｉｄｅｏ」であり、［ＥＸＴ＿ＵＲＬ］は「ｍ３ｕ８」である。

トランスマクサ５６５のマッピング・モジュールは、サポートされる各配信フォーマットに特有のあらかじめ指定されたテンプレート・パターンに適切な値を挿入することによって、オリジン・サーバに転送できるマニフェスト要求ＵＲＬを生成してもよい。各オリジン・サーバはわずかに異なる形態を有するので、特定のプロトコル・タイプ内でも、トランスマクサが反復することのできるあらかじめ指定された複数のテンプレート・パターンがあり得る。

たとえば、Ａｐｐｌｅ配信フォーマットをサポートするオリジン・サーバは、わずかに異なる実施形態をマニフェスト要求ＵＲＬの形で有してもよい。したがって、あらかじめ指定されたテンプレート・パターンには以下のテンプレート・パターンが含まれてもよい。

Ａｐｐｌｅ配信フォーマットとその他の配信フォーマットの両方について様々な追加のパターンがあらかじめ指定されてもよいことが諒解されよう。

一例として、Ａｐｐｌｅ配信フォーマットを使用してオリジン・サーバ宛てに送られるＭｉｃｒｏｓｏｆｔスムース・ストリーミング配信フォーマットのクライアント要求について検討する。要求ＵＲＬは、「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｖｏｄ／ｓｕｐｅｒｖｉｄｅｏ．ｉｓｍ／Ｍａｎｉｆｅｓｔ」の形をとることがある。この例では［Ｂ
ＡＳＥ＿ＵＲＬ］は「ｅｘａｍｐｌｅ．ｃｏｍ／」であり、［ＬＯＣＡＴＩＯＮ＿ＵＲＬ］は「ｖｏｄ／」であり、［ＭＥＤＩＡ＿ＵＲＬ］は「ｓｕｐｅｒｖｉｄｅｏ」である。

したがって、「ｈｔｔｐ：／／［ＢＡＳＥ＿ＵＲＬ］／［ＬＯＣＡＴＩＯＮ＿ＵＲＬ］［ＭＥＤＩＡ＿ＵＲＬ］．ｍ３ｕ８」のオリジン・サーバに関するあらかじめ指定されたパターンに基づいて、このオリジン・サーバに関する生成される要求ＵＲＬは「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｖｏｄ／ｓｕｐｅｒｖｉｄｅｏ．ｍ３ｕ８」になる。

６１０において要求ＵＲＬが生成され送信され、６１５においてマニフェストを含む応答が首尾よく受信されると、トランスマクサ５６５のマッピング・モジュールは、受信されたマニフェストをオリジン・サーバによって使用されるプロトコルからクライアント・デバイスによって使用されるプロトコルに変換してもよい。

この段階において、セッション管理モジュール５６８は、クライアント・デバイス５９０およびオリジン・サーバ５２０に関連するストリーミング・セッションを特定するために、クライアント・デバイス５９０のために作成されるマニフェストに挿入される一意の識別子を生成してもよい。

いくつかの実施形態において、一意の識別子は、要求ＵＲＬテンプレートに一意のセッション識別子（ＵＵＩＤ）を含めるようにマニフェストに挿入されてもよい。したがって、クライアント・デバイス５９０がコンテンツ・フラグメントを求める要求をさらに発すると、中間サーバ５６０はその要求が特定のセッションに関連付けられていると特定することができる。一意の識別子はどのトランスマクサ５６５を使用すべきかを判定するのに使用されてもよい。

挿入される識別子の厳密な位置はマニフェスト・タイプに応じて異なることがある。たとえば、特定のクライアントの場合、要求ＵＲＬテンプレートにおいてＵＲＬの端部にパラメータ・ストリングが含まれることがある。他のクライアントの場合、要求ＵＲＬテンプレートの［ＬＯＣＡＴＩＯＮ＿ＵＲＬ］要素にパラメータが挿入されることがある。

上記に指摘したように、各種類のマニフェストは、追加のマニフェストまたはコンテンツ・フラグメントのいずれかを求める将来の要求を提出するにはどのようにすればよいかをクライアントに説明する情報を、中断なしの再生を実現するためのタイミング情報（たとえば、フラグメント持続時間、ビットレートなど）とともに供給する。したがって、各マニフェスト・タイプは、異なる形でフォーマットされ得る同様の情報を含む。

プロトコルごとのフラグメント・サイズおよびフラグメント構造が異なる可能性があるので、特定のクライアント要求を実現するにはオリジン・サーバから複数のコンテンツ・フラグメントを検索することが必要になることがある。たとえば、いくつかのプロトコルでは、各フラグメントに単一のメディア・タイプしか含まれない（たとえば、ビデオのみまたはオーディオのみ）。したがって、オーディオビジュアル・コンテンツの再生を実現するにはビデオ・フラグメントとオーディオ・フラグメントの両方を検索する必要がある。しかし、いくつかの他のプロトコルでは、ビデオ・コンテンツとオーディオ・コンテンツの両方が単一のフラグメントとして多重化され、したがって、再生を実現するのに単一のフラグメントしか必要とされないことがある。

次に図７を参照すると、時間軸上の例示的なビデオ・フラグメント・マッピングおよびオーディオ・フラグメント・マッピングが示されている。コンテンツ・アイテム７１０は、各々の持続時間が５秒である４つのビデオ・フラグメントと各々の持続時間が４秒である５つのオーディオ・フラグメントとで構成される。これに対して、コンテンツ・アイテ
ム７５０は、各々の持続時間が５秒である４つのコンテンツ・フラグメントで構成され、各コンテンツ・フラグメントはインターリーブされたビデオ・データおよびオーディオ・データを含む。

様々なメディア・タイプがそれぞれの別個のフラグメント（たとえば、オーディオおよびビデオ）に分離されるとき、各フラグメントが同じ持続時間を有さないことがあることが諒解されよう。しかし、インターリーブ・フォーマットでは、コンテンツ・アイテムの一定の持続時間分のすべてのビデオおよびオーディオ・サンプルが単一の特定のフラグメントに含まれると考えられ得る。

したがって、トランスマクサ・マッピング・モジュールは、分離モデルを表すマニフェストとインターリーブ・モデルを表すマニフェストとの間で変換を行うときに、対象マニフェスト内の様々なコンテンツ・フラグメントのタイミングおよび持続時間を表すにはどうすればよいかを判定することが必要になることがある。

いくつかの実施形態において、ビデオ・フラグメントは一次タイミング・ソースとして選択されてもよい。したがって、トランスマックス変換が分離ソースからインターリーブ・ソースへの変換であるとき、インターリーブ・フラグメントの持続時間は分離ソース内のビデオ・フラグメントの持続時間に基づく。逆に、トランスマックス変換がインターリーブ・ソースから分離ソースへの変換であるとき、インターリーブ・フラグメントの持続時間をビデオ・フラグメントとオーディオ・フラグメントの両方に使用してもよい。

フラグメント要求のクライアント配信フォーマットから配信元配信フォーマットへの変換においてトランスマクサ５６５のマッピング・モジュールを助けるために、クライアントのために初期マニフェストが作成されるときに各セッションの１つまたは複数のセッション・フラグメント・マッピング・テーブルが作成されてもよい。上述のように、各フラグメントはコンテンツ・アイテム（メディア・アセット）内の特定のタイム・スパンを表し、クライアントに供給されるマニフェストは、特定のタイム・スパンごとにフラグメント要求を作成するにはどうすればよいかを表す。

セッション・フラグメント・マッピング・テーブルは、配信元マニフェストから得たフラグメントのタイムラインおよびクライアント・マニフェスト内のフラグメントの対応するタイムラインを含んでもよい。セッション・フラグメント・マッピング・テーブルの例示的な対が以下のテーブル５Ａおよびテーブル５Ｂに示されている。したがって、マッピング・モジュールは、クライアント・デバイスからの要求を実現するにはオリジン・サーバからどのフラグメントを要求すべきかを判定してもよい。

さらに、トランスマクサ５６５のマッピング・モジュールは、配信元フラグメントの持続時間に基づく必要のない、異なる長さのフラグメント持続時間を選択してクライアントへの配信を行ってもよい。たとえば、クライアント・マニフェストは持続時間が１０秒のフラグメントを定義してもよく、一方、配信元マニフェストは持続時間が２秒のフラグメントを含んでもよい。マッピング・モジュールは、セッション・フラグメント・マッピング・テーブルを使用し、それによって、単一のクライアント・フラグメント要求を実現するには５つの配信元フラグメントを検索する必要があると判定することができる。

必要なコンテンツ・フラグメントが特定され検索された後、トランスマクサ５６５のコンテナ変換モジュールによってコンテナ・フォーマットを変換する工程を実行してもよい。フラグメント・コンテナの変換は概念上、抽出とパッキングの２つの部分に分割されてもよい。

抽出については、オリジン・サーバから検索されたフラグメントを配信元コンテナ・フォーマットから１組のメディア記述子（すなわち、コンテナ内のすべてのサンプルに適用
されるパラメータ）ならびにオーディオおよびビデオの生サンプルならびにそれらに関連するタイミング（ＰＴＳおよびＤＴＳ）に「デマックス処理」することができる。パッキングについては、抽出されたデータを対象コンテナ・フォーマットに容易に「マックス処理」することができる汎用データ構造に配置することができる。

メディア記述子の例を以下のテーブル６〜テーブル８に示す。

様々なストリーミング・プロトコルおよび配信フォーマット各々がコンテンツ・フラグメントに関する特定のコンテナ・フォーマットをサポートする。たとえば、Ｍｉｃｒｏｓｏｆｔスムース・ストリーミング・コンテナ・フォーマットは、フラグメントが「ＭＯＯＦ」（ムービー・フラグメント）に含まれるＩＳＯ．ｍｐ４フォーマットに基づく。ＡｄｏｂｅもＩＳＯ．ｍｐ４フォーマットに基づくコンテナ・フォーマットを使用するが、サンプルがＩＳＯフォーマットに対する独自の追加事項に基づく追加の情報を有することをさらに指定する。ＡｐｐｌｅはＭＰＥＧ−２トランスポート・ストリーム・コンテナ・フ
ォーマットを使用する。したがって、各トランスマクサ５６５は、クライアントの要件および配信元コンテナ・フォーマット（したがって、配信フォーマット）を満たすために、抽出およびパッキングを行うのに必要なコンテナの種類に適合されたコンテナ変換モジュールを有する。

この説明の全体にわたってオーディオ・コンテンツおよびビデオ・コンテンツが参照されるが、同じく同様に処理することができる他の種類のコンテンツ（たとえば、クローズド・キャプション、サブタイトル）があることが諒解されよう。

再び図６を参照すると、６２０において、クライアント・デバイス５９０はクライアント・マニフェストを受信し、どのコンテンツ・フラグメントを検索すべきかを判定する。６２５において、クライアント・デバイス５９０はクライアント・フラグメント要求を送信する。クライアント・フラグメント要求は、６４０においてオリジン・サーバ５２０に送信される配信元フラグメント要求を配信元配信フォーマットで生成するようにトランスマクサ５６５のマッピング・モジュールによって処理される。いくつかの実施形態において、クライアント・フラグメント要求は、本明細書で説明するように複数の配信元フラグメント要求に対応し得る。同様に、単一の配信元フラグメント要求が複数のクライアント要求に対応し得る。

６４５において、オリジン・サーバ５２０は要求されたコンテンツ・フラグメントをトランスマクサ５６５に送信する。トランスマクサ５６５のコンテナ変換モジュールは、コンテンツ・フラグメントを配信元配信フォーマットからクライアント配信フォーマットに変換する。変換は、本明細書で説明するようにコンテンツのトランスマックス変換および再パッケージングを伴ってもよい。

６６０において、中間サーバ５６０は、クライアント配信フォーマットを使用して、要求されたコンテンツ・フラグメントをクライアント・デバイス５９０に送信する。
ＨＴＴＰプロトコルおよび関連するＨＴＴＰベースのアダプティブ・ストリーミング・プロトコルのステートレス性に起因して、ＨＴＴＰプロトコルには任意の単一のセッションの厳密な状態を知るための固有の能力がない。たとえば、クライアントがセッションを中止したかどうかまたは場合によってはセッションを終了した（たとえば、ウェブ・ブラウザ・ウィンドウを閉じた）かどうかを示すクライアントからサーバへのメッセージ送信はない。どちらの場合も、クライアントは単にさらなるデータを要求することを停止する。これによって、セッションがいつ終了したかを特定するうえで問題が生じる。

場合によっては、クライアントはほぼ無期限に中止状態になることがあり、したがって、セッションがいつ永久的に終了したかを特定するうえで信頼できる特定のイベントはない。中間サーバは不定数のクライアント・セッションを永遠にアクティブ状態に維持することができないので、終了したセッションまたは「無効な」セッションを特定してストレージ・リソースおよびメモリ・リソースを新しいセッションに再使用できるようにする方法がなければならない。

１実施形態において、セッション管理モジュール５６８はすべてのオープン・クライアント・セッションの状態を特定するテーブルを管理する。セッション管理モジュール５６８は、所定の期間の後すべてのアクティブ・セッションを周期的に「タイムアウト」させ、各セッションをタイムアウト状態とマークしてもよい。現在タイムアウト状態であるセッションが、次の周期的なタイムアウト・イベントの前にさらなるフラグメント要求を発行した場合、そのセッションを再び「アクティブ」とマークしてもよい。逆に、セッションがすでにタイムアウト状態にあり、再び「タイムアウト」イベントが生じるまでにさらなるフラグメント要求を発行していない場合、そのセッションをイナクティビティ・キュ
ーに移動させ、削除候補とマークしてもよい。イナクティビティ・キューは先入れ先出し（ＦＩＦＯ）手法に基づいてもよく、したがって、最も長い間イナクティブであるセッションが最初に削除されるセッションである。しかし、削除候補であるセッションは、中間サーバ１６０が、セッション・リソースが尽きたと判定するまで削除されなくてもよい。

「タイムアウト」または「イナクティブ」とマークされた任意のセッションは、そのセッションが削除される前にそのセッションに関連するさらなるフラグメント要求が受信された場合に再び「アクティブ」とマークされてもよい。

次に図８を参照すると、クライアント・セッションの状態を表すために中間サーバのセッション管理モジュールによって使用することのできる例示的な状態図が示されている。
８１０においてクライアント・マニフェスト要求が受信された場合、クライアント・セッションが開始され初期化中とマークされる。その後、そのセッションに関連するさらなるフラグメント要求またはマニフェスト要求が受信された場合、８２０においてセッション状態はアクティブとマークされる。さらなる要求が受信されない場合、そのセッションは８３０においてタイムアウトとマークされる。

８３０および８４０において、周期的な工程によって初期化状態およびアクティブ状態にあるすべてのセッションの状態がタイムアウトに変更される。しかし、（８５０において）あるセッションに関連してさらなるフラグメント要求が受信された場合、その関連するセッションを再びアクティブとマークしてもよい。

８６０において、周期的な工程によってタイムアウト状態にあるすべてのセッションの状態が削除候補に変更される。しかし、（８７０において）あるセッションに関連してさらなるフラグメント要求が受信された場合、その関連するセッションを再びアクティブとマークしてもよい。

８８０において、中間サーバ５６０が、新しいセッションを有効にするためにセッション・リソース（たとえば、メモリ）が必要であると判定し、かつ削除候補とマークされた古いセッションがない場合、削除候補である既存のセッションを削除してもよい。

いくつかの実施形態において、中間サーバ５６０は１つまたは複数のフラグメント要求のタイミングを使用してクライアント・ストリーミング・セッションのクライアント・セッション状態を判定してもよい。たとえば、要求されたフラグメントが実際に経過したよりも長い時間だけ分離されたタイムコードを有するかまたは各フラグメントが順序を外れて検索されたことをフラグメント要求タイミングが示す場合、中間サーバ５６０は、クライアントがシーク動作を実行したと推論してもよい。

同様に、タイミングが、実際の経過時間が１つまたは複数のフラグメント要求の再生時間を超えていることを示す場合、中間サーバ５６０はトリック再生動作が実行されていると推論してもよい。一般に、トリック再生動作は、通常のフレームレート以外のフレームレートでコンテンツが再生される動作である。トリック再生動作の例には「ポーズ」イベント、「早送り」イベント、「巻き戻し」イベント、「スロー・モーション」イベントなどが含まれる。

次に図９を参照すると、図５の中間サーバの例示的な詳細なコール・フローが示されている。
コール・フロー９００は概して、中間サーバ５６０などの中間サーバの構成要素同士の間の例示的なメッセージ・フローを示す。いくつかの実施形態において、基本モデルは、各構成要素が互いに通信するのに要求／応答モデルを使用し、したがって、「ブロックさ
れ」応答を待つ状態にならないという点で非ブロック型であってもよい。

いくつかの実施形態において、コンテンツ・ジェネレータ５６４は、これらの構成要素間にリンクを維持するように構成されてもよく、一方、セッション管理モジュール５６８は全体的な接続状態およびポリシーを管理するように構成されてもよい。

図９に示すように、２つの一次エンドツーエンド・メッセージ・フローがある。第１のメッセージ・フローはマニフェスト情報を求める初期要求に続いて生じる。第２のメッセージ・フローはさらなるマニフェストまたはメディア・フラグメントを求める要求に続いて生じる。

メッセージ・フローは９０５から開始し、クライアントからクライアント配信フォーマットを使用してＨＴＴＰ ＧＥＴ要求が発行される。９１０において、コンテンツ・ジェネレータ５６４は、クライアント配信フォーマットに基づいて要求をどのトランスマクサ５６５が対処すべきかを判定し、要求を適切なトランスマクサのマッピング・モジュールに渡す。９１２において適切なトランスマクサが見つからない場合、メッセージ・フローが進行し、９４５においてエラー・メッセージが発行されてもよい。適切なトランスマクサが見つかった場合、メッセージ・フローは９１５に進む。

９１５において、トランスマクサは、ＨＴＴＰ要求が初期マニフェストを求める要求またはそれ以後の要求であるかどうかを判定する。要求が初期要求である場合、フローは９２０に進み、本明細書で説明するように一意の識別子およびセッション・コンテキスト（たとえば、状態情報）が作成され、次いでフローは９３５に進む。

要求が初期要求ではない場合、一意の識別子がＨＴＴＰ要求から抽出され、９２５においてセッション状態情報を検索するために使用される。
９３０において、トランスマクサは、要求がマニフェストを求める要求であると判定する。要求がマニフェストを求める要求である場合、フローは９３５に進み、次いで、マニフェストを求める要求が、配信元配信フォーマットを使用してマッピング・モジュールによって生成され（たとえば、マニフェストを求める中間要求）、オリジン・サーバに送信される。

９４０において、トランスマクサは、要求に対する応答が首尾よく受信されたかどうかを判定する。エラーが受信された場合、トランスマクサは、９４５においてクライアント・デバイスにエラー・メッセージを配信すべきであると特定し、９５０においてエラー・メッセージを対応するＨＴＴＰ ＲＥＳＰＯＮＳＥメッセージで送信する。

マニフェストが首尾よく受信された場合、トランスマクサのコンテナ変換モジュールは、９９０において本明細書で説明するようにマニフェストを変換し、９９５においてトランスマックス変換されたマニフェストをクライアント・デバイスに配信すべきであると特定する。トランスマックス変換されたマニフェストは、９９９において対応するＨＴＴＰ
ＲＥＳＰＯＮＳＥメッセージで送信される。

９３０において、トランスマクサが、要求がマニフェストを求める要求ではないと判定した場合、フローは９５５に進んで要求をオリジン・サーバ・プロトコルにトランスマックス変換し、それによってコンテンツ・フラグメントを求める中間要求を生成し、１つまたは複数のコンテンツ・フラグメントを求める中間要求をオリジン・サーバに送信する。

９６０において、トランスマクサは、要求に対する応答が首尾よく受信されたかどうかを判定する。エラーが受信された場合、トランスマクサは、９８０においてクライアント
・デバイスにエラー・メッセージを配信すべきであると特定し、９８５においてエラー・メッセージを対応するＨＴＴＰ ＲＥＳＰＯＮＳＥメッセージで送信する。

コンテンツ・フラグメントが首尾よく受信された場合、トランスマクサのコンテナ変換モジュールは、９６５において、たとえば配信元コンテナ・フォーマットからフラグメントをアンパックすることによって、１つまたは複数のフラグメントを変換し、９７０においてトランスマックス変換された１つまたは複数のコンテンツ・フラグメントをクライアント・デバイスに配信すべきであると特定する。トランスマックス変換された１つまたは複数のコンテンツ・フラグメントは、クライアント・コンテナ・フォーマットにパックされ（一方では、配信元符号化フォーマットのままであり）、９７５において、クライアント配信フォーマットを使用して対応するＨＴＴＰ ＲＥＳＰＯＮＳＥメッセージで送信される。

パッキングは、コンテンツ・フラグメントをリアセンブルすることによって複数のフラグメントをクライアント・コンテナ・フォーマットにパックすることを含んでもよく、たとえば、配信元コンテナ・フォーマットおよびクライアント・コンテナ・フォーマットによって、いくつかのフラグメントを備えるそれぞれに異なる長さのセグメントが得られる。

次に図１０を参照すると、初期マニフェスト要求を容認するための例示的なコール・フロー１０００が示されている。
コール・フロー１０００は１００１から開始し、ＨＴＴＰサーバ５６６がマニフェストを求めるＨＴＴＰ ＧＥＴ要求をクライアント・デバイス５９０から受信する。

１００２において、ＨＴＴＰサーバ５６６は、要求の妥当性を検査し、要求が有効である場合、要求メッセージを要求されたＵＲＬと一緒にコンテンツ・ジェネレータ５６４に転送する。転送された要求メッセージは、要求識別子、要求ＵＲＬ、クライアント・デバイスＩＰアドレス、クライアント識別子（たとえば、クッキー）、ユーザ・エージェント、クライアントＴＣＰポート、および要求の時間などのメッセージ詳細を含んでもよい。

１００３において、コンテンツ・ジェネレータ５６４、たとえば、トランスマクサ５６５のマッピング・モジュールは、要求が初期マニフェスト要求を求める要求であると判定し、セッション管理モジュール５６８に通知する。この通知は、要求識別子、コンテンツ・ジェネレータ５６４によって生成されたセッション・コンテキスト識別子、タイムスタンプ、クライアント・プロトコル・タイプ、クライアントＩＰアドレス、および要求ＵＲＬなどの詳細を含んでもよい。

セッション管理モジュール５６８は、１００４において、セッションを許容できるかどうか（たとえば、十分なリソースが利用可能であるかどうか、クライアントが許可されているかどうかなど）を判定し、許可メッセージをコンテンツ・ジェネレータ５６４に送る。許可メッセージは、要求識別子、コンテンツ・ジェネレータ５６４によって生成されたセッション・コンテキスト識別子、セッション管理モジュール５６８によって生成されたセッションの一意の識別子（ＵＵＩＤ）、応答コード、オリジン・サーバ・プロトコルに対応する識別子、要求を作成する際にトランスマクサ５６５のマッピング・モジュールが使用を試みる要求パターンのリストを含んでもよい。

１００５において、トランスマクサ５６５のマッピング・モジュールは、配信元プロトコルを使用して適切な要求を作成し、要求識別子と１つまたは複数の要求ＵＲＬとを含む生成された要求をＨＴＴＰクライアント５６２に転送する。要求識別子を使用して応答をトランスマクサ５６５と相関させてもよい。

１００６において、ＨＴＴＰクライアント５６２は、オリジン・サーバ５２０の適切なＩＰアドレスを判定し、ＨＴＴＰ ＧＥＴメッセージを、配信元マニフェストを求める生成された要求と一緒に送信する。

１００７において、オリジン・サーバ５２０は、配信元配信フォーマットの要求された配信元マニフェスト・ファイルで応答する。
ＨＴＴＰクライアント５６２は、１００８において、要求されたマニフェストをコンテンツ・ジェネレータ５６４に送信または転送する。応答は、要求識別子、１つまたは複数の要求ＵＲＬ、および各要求に対応するステータス・コードを含んでもよい。

１００９において、コンテンツ・ジェネレータ５６４（および適切なトランスマクサのコンテナ変換モジュール）は、配信元配信フォーマットで受信されたマニフェスト・ファイルからクライアント配信フォーマットのクライアント・マニフェスト・ファイルを生成し、クライアント・マニフェストをＨＴＴＰサーバ５６６に転送する。

最後に、１０１０において、ＨＴＴＰサーバ５６６はクライアント・マニフェストをクライアント・デバイス５９０に送信する。
次に図１１を参照すると、拒絶された初期マニフェスト要求に関する例示的なコール・フロー１１００が示されている。

コール・フロー１１００は１１０１から開始し、ＨＴＴＰサーバ５６６はマニフェストを求めるＨＴＴＰ ＧＥＴ要求をクライアント・デバイス５９０から受信する。この要求はクライアント配信フォーマットである。

１１０２において、ＨＴＴＰサーバ５６６は要求の妥当性を検査し、要求が有効である場合、要求メッセージを要求されたＵＲＬと一緒にコンテンツ・ジェネレータ５６４に転送する。

１１０３において、コンテンツ・ジェネレータ５６４は、要求が初期マニフェスト要求を求める要求であると判定し、セッション管理モジュール５６８に通知する。
セッション管理モジュール５６８は、１１０４において、セッションを許容できない（たとえば、十分なリソースが利用可能でない、クライアントが許可されていないなど）と判定し、非許可メッセージをコンテンツ・ジェネレータ５６４に送る。

１１０５において、コンテンツ・ジェネレータ５６４は拒絶メッセージ（たとえば、ＨＴＴＰエラー・メッセージ）を作成し、メッセージをＨＴＴＰサーバ５６６に転送する。
最後に１１０６において、ＨＴＴＰサーバ５６６は拒絶メッセージをクライアント・デバイス５９０に送信する。

次に図１２を参照すると、無効なオリジン・サーバ・アドレスを含む初期マニフェスト要求に関する例示的なコール・フロー１２００が示されている。
コール・フロー１２００は１２０１から開始し、ＨＴＴＰサーバ５６６はマニフェストを求めるＨＴＴＰ ＧＥＴ要求をクライアント・デバイス５９０から受信する。この要求はクライアント配信フォーマットである。

１２０２において、ＨＴＴＰサーバ５６６は要求の妥当性を検査し、要求が有効である場合、要求メッセージを要求されたＵＲＬと一緒にコンテンツ・ジェネレータ５６４に転送する。

１２０３において、コンテンツ・ジェネレータ５６４は、要求が初期マニフェスト要求を求める要求であると判定し、セッション管理モジュール５６８に通知する。
セッション管理モジュール５６８は、１２０４において、セッションを許容できるかどうか（たとえば、十分なリソースが利用可能であるかどうか、クライアントが許可されているかどうかなど）判定し、許可メッセージをコンテンツ・ジェネレータ５６４に送る。

１２０５において、コンテンツ・ジェネレータ５６４は、配信元プロトコルを使用して適切な要求を作成し、生成された要求をＨＴＴＰクライアント５６２に転送する。
１２０６において、ＨＴＴＰクライアント５６２は、（たとえば、要求が無効なオリジン・サーバ・アドレスを含むことを理由として）オリジン・サーバ５２０に接続できないと判定し、エラー・メッセージを、オリジン・サーバに接続できないことを示すステータスと一緒にコンテンツ・ジェネレータ５６４に送る。

１２０７において、コンテンツ・ジェネレータ５６４は、クライアント・セッションを削除すべきであると判定し、削除メッセージをセッション管理モジュール５６８に送り、したがって、セッション・リソースを回収することができる。

１２０８において、コンテンツ・ジェネレータ５６４は、エラー・メッセージを適切なＨＴＴＰエラー・コードと一緒にＨＴＴＰサーバ５６６に送る。
最後に１２０９において、ＨＴＴＰサーバ５６６はエラー・メッセージをクライアント・デバイス５９０に送信する。

次に図１３を参照すると、有効なフラグメント要求に関する例示的なコール・フロー１３００が示されている。
コール・フロー１３００は１３０１から開始し、ＨＴＴＰサーバ５６６はコンテンツ・フラグメントを求めるＨＴＴＰ ＧＥＴ要求をクライアント・デバイス５９０から受信する。

１３０２において、ＨＴＴＰサーバ５６６は要求の妥当性を検査し、要求が有効である場合、要求メッセージを要求されたＵＲＬと一緒にコンテンツ・ジェネレータ５６４に転送する。

１３０３において、コンテンツ・ジェネレータ５６４は、要求がコンテンツ・フラグメントを求める要求であると判定し、一意のセッションＩＤを抽出し、要求に含まれる一意のセッション識別子をセッション管理モジュール５６８に通知する。

セッション管理モジュール５６８は、１３０４において、セッションを特定し、セッションの詳細（たとえば、ポリシー、状態など）を含むメッセージをコンテンツ・ジェネレータ５６４に送る。

１３０５において、コンテンツ・ジェネレータ５６４は、配信元プロトコルを使用して適切な要求を作成し、生成された要求をＨＴＴＰクライアント５６２に転送する。
１３０６において、ＨＴＴＰクライアント５６２は、オリジン・サーバ５２０の適切なＩＰアドレスを判定し、ＨＴＴＰ ＧＥＴメッセージを、要求されたコンテンツ・フラグメントを求める生成された要求と一緒に送信する。

１３０７において、オリジン・サーバ５２０は要求されたコンテンツ・フラグメントで応答する。
ＨＴＴＰクライアント５６２は、１３０８において、要求されたコンテンツ・フラグメントをコンテンツ・ジェネレータ５６４に送信または転送する。

１３０９において、コンテンツ・ジェネレータ５６４（および適切なトランスマクサ）は、コンテンツ・フラグメントに関する情報（たとえば、バイト数など）をセッション管理モジュール５６８に送信する。送信される情報には、セッションの一意のセッション識別子（ＵＵＩＤ）、このフラグメントに関して送られるバイト数、送られるコンテンツ・フラグメントの持続時間、送られるコンテンツ・フラグメントのビットレート、およびコンテンツ・アイテム中の位置（たとえば、現在のコンテンツ・フラグメントが表すビデオの開始からの秒数）を含めてもよい。

１３１０において、コンテンツ・ジェネレータ５６４（および適切なトランスマクサ）は、受信されたコンテンツ・フラグメントを配信元プロトコルからクライアント・プロトコルにトランスマックス変換し、トランスマックス変換されたコンテンツ・フラグメントをＨＴＴＰサーバ５６６に転送する。

最後に１３１１において、ＨＴＴＰサーバ５６６は、トランスマックス変換されたコンテンツ・フラグメントをクライアント・デバイス５９０に送信する。
次に図１４を参照すると、無効なフラグメント要求に関する例示的なコール・フロー１４００が示されている。

コール・フロー１４００は１４０１から開始し、ＨＴＴＰサーバ５６６は、コンテンツ・フラグメントを求めるＨＴＴＰ ＧＥＴ要求をクライアント・デバイス５９０から受信する。

１４０２において、ＨＴＴＰサーバ５６６は、要求の妥当性を検査し、要求が有効である場合、要求メッセージを要求されたＵＲＬと一緒にコンテンツ・ジェネレータ５６４に転送する。

１４０３において、コンテンツ・ジェネレータ５６４は、要求が無効なフラグメント要求であると判定し、拒絶メッセージを適切なＨＴＴＰエラー・コードと一緒にＨＴＴＰサーバに送る。

最後に１４０４において、ＨＴＴＰサーバ５６６は、拒絶メッセージをクライアント・デバイス５９０に送信する。
次に図１５を参照すると、無効なセッション識別子（ＵＵＩＤ）を含むコンテンツ・フラグメント要求に関する例示的なコール・フロー１５００が示されている。

コール・フロー１５００は１５０１から開始し、ＨＴＴＰサーバ５６６はコンテンツ・フラグメントを求めるＨＴＴＰ ＧＥＴ要求をクライアント・デバイス５９０から受信する。

１５０２において、ＨＴＴＰサーバ５６６は要求の妥当性を検査し、要求が有効である場合、要求メッセージを要求されたＵＲＬと一緒にコンテンツ・ジェネレータ５６４に転送する。

１５０３において、コンテンツ・ジェネレータ５６４は、要求がコンテンツ・フラグメントを求める要求であると判定し、要求に含まれる一意のセッション識別子をセッション管理モジュール５６８に通知する。

セッション管理モジュール５６８は、１５０４において、一意の識別子に対応するセッションの特定を試み、そのセッションが存在しない場合、エラー・メッセージ（たとえば
、セッションが見つからない）をコンテンツ・ジェネレータ５６４に送る。

１５０５において、コンテンツ・ジェネレータ５６４は、エラー・メッセージ（たとえば、ＨＴＴＰエラー・メッセージ）を作成し、このメッセージをＨＴＴＰサーバ５６６に転送する。

最後に１５０６において、ＨＴＴＰサーバ５６６は、エラー・メッセージをクライアント・デバイス５９０に送信する。
本明細書で説明するように、逆トランスレーティング・プロキシ手法は様々なアダプティブ・ストリーミング・プロトコルの変換を「要求ごとに」かつ「オンザフライ」で行うのを可能にする。したがって、この手法は、コンテンツをフラグメント要求ごとにトランスマックス変換し、一方、追加のコンテンツ・フラグメントが実際に要求されるまでそのようなコンテンツ・フラグメントをトランスマックス変換することを不要にするように最適化されている。さらなる能力には、ＱｏＥを最適化するようにセッション・コンテキストに基づいて応答を動的に定義することが含まれる。たとえば、特定のクライアントの帯域幅を限定するようにポリシーが設定されており、クライアントがより高いビットレートを要求している場合、中間サーバは帯域幅ポリシーに整合するフラグメントのみを検索してもよい。

本明細書で説明する例示的な実施形態を完全に理解できるように多数の特定の詳細が記載されることが諒解されよう。しかし、当業者には、本明細書で説明する実施形態がこれらの特定の詳細なしに実施できることが理解されよう。他の例では、本明細書で説明する実施形態を曖昧にすることのないように公知の方法、手順、および構成要素については詳細に説明していない。したがって、上述の内容は本発明を例示するものでありかつ非制限的なものであり、当業者には、添付の特許請求の範囲に定義されるような本発明の範囲から逸脱せずに他の変形および修正を施せることが理解されよう。

Claims (24)

1. ストリーミング・メディア・コンテンツ・アイテムをオリジン・サーバからクライアント・デバイスに配信するためのシステムであって、該オリジン・サーバが該ストリーミング・メディア・コンテンツ用の配信元コンテナ・フォーマットと配信元配信フォーマットとを有し、該ストリーミング・メディア・コンテンツが配信元符号化フォーマットで符号化された第１の複数のコンテンツ・フラグメントからなるシステムにおいて、
   前記オリジン・サーバおよび前記クライアント・デバイスと通信するように接続され、１つ以上のプロセッサを備える中間サーバを備え、前記プロセッサは、
   ａ）クライアント配信フォーマットを使用して該ストリーミング・メディア・コンテンツ・アイテムの少なくとも要求される部分に関するクライアント要求をクライアント・デバイスから受信し、該クライアント要求がクライアント配信フォーマットであると判定し、該クライアント要求に対応する中間要求を該配信元配信フォーマットで生成するように構成されたマッピング・モジュールと、
   ｂ）該中間要求をサーバに送信し、該ストリーミング・メディア・コンテンツ・アイテムの該要求される部分に対応する該第１の複数のコンテンツ・フラグメントのサブセットを受信するように構成された中間クライアント・モジュールであって、該サブセットが、該配信元配信フォーマットを使用して該オリジン・サーバから該配信元コンテナ・フォーマットで受信される中間クライアント・モジュールと、
   ｃ）該サブセットを該配信元コンテナ・フォーマットからアンパックし、該サブセットをクライアント・コンテナ・フォーマットにパックするように構成されたコンテナ変換モジュールであって、該クライアント・コンテナ・フォーマットでパックされた該サブセット中の該コンテンツ・フラグメントは該配信元符号化フォーマットで符号化されたままであるコンテナ変換モジュールと、
   ｄ）該クライアント配信フォーマットを使用して該ストリーミング・メディア・コンテンツ・アイテムを該クライアント・コンテナ・フォーマットで該クライアント・デバイスに送信するように構成された中間サーバ・モジュールと、
   ｅ）前記クライアント要求が受信されたときにストリーミング・セッションを開始するように構成されたセッション管理モジュールと、を提供するように構成されており、
   前記プロセッサは、前記クライアント・デバイスからのフラグメント要求を監視することによって前記ストリーミング・セッションに関する前記クライアント・デバイスのセッ
   ション状態を判定するようにさらに構成されており、前記クライアント要求を複数のオープン・クライアント・セッションのうちの１つに関連付けるべく、前記複数のオープン・クライアント・セッションの各々について、対応するクライアント・セッション状態情報を記憶するようにさらに構成されている、システム。
2. 前記コンテナ変換モジュールは、前記第１の複数のコンテンツ・フラグメントを第２の複数のコンテンツ・フラグメントにリアセンブルすることによって前記ストリーミング・メディア・コンテンツ・アイテムを前記クライアント・コンテナ・フォーマットにパックし、該第２の複数のコンテンツ・フラグメントは前記第１の複数のコンテンツ・フラグメントとは異なる持続時間を有する、請求項１に記載のシステム。
3. 前記マッピング・モジュールは、所定の配信フォーマットを使用して１つまたは複数の要求を送信し、応答が首尾よく受信されたかどうかを判定することによって、前記オリジン・サーバが前記配信元配信フォーマットで送信するように構成されていると判定する、請求項１または２に記載のシステム。
4. 前記マッピング・モジュールは、前記クライアント要求を複数の所定の要求パターンと比較することによって前記クライアント要求が前記クライアント配信フォーマットであると判定する、請求項１乃至３のいずれか一項に記載のシステム。
5. ストリーミング・メディア・コンテンツ・アイテムをオリジン・サーバからクライアント・デバイスに配信する方法であって、該オリジン・サーバが該ストリーミング・メディア・コンテンツ用の配信元コンテナ・フォーマットおよび配信元配信フォーマットを有し、該ストリーミング・メディア・コンテンツが配信元符号化フォーマットで符号化された第１の複数のコンテンツ・フラグメントからなる方法において、
   ａ）クライアント配信フォーマットを使用して該ストリーミング・メディア・コンテンツ・アイテムの少なくとも要求される部分に関するクライアント要求を該クライアント・デバイスから受信する工程と、
   ｂ）該クライアント要求が該クライアント配信フォーマットであると判定する工程と、
   ｃ）該クライアント要求に対応する中間要求を生成する工程であって、配信元要求が該配信元配信フォーマットである、前記工程と、
   ｄ）該中間要求を該サーバに送信する工程と、
   ｅ）該ストリーミング・メディア・コンテンツ・アイテムの該要求される部分に対応する該第１の複数のコンテンツ・フラグメントのサブセットを受信する工程であって、該サブセットが、該配信元配信フォーマットを使用して該オリジン・サーバから該配信元コンテナ・フォーマットで受信される、前記工程と、
   ｆ）該サブセットを該配信元コンテナ・フォーマットからアンパックし、該サブセットをクライアント・コンテナ・フォーマットにパックする工程であって、該クライアント・コンテナ・フォーマットでパックされた該サブセット中の該コンテンツ・フラグメントは該配信元符号化フォーマットで符号化されたままである、前記工程と、
   ｇ）前記クライアント要求が受信されたときにストリーミング・セッションを開始し、
   前記クライアント・デバイスからのフラグメント要求を監視することによって前記ストリーミング・セッションに関する前記クライアント・デバイスのセッション状態を判定し、
   前記クライアント要求を複数のオープン・クライアント・セッションのうちの１つに関連付けるべく、前記複数のオープン・クライアント・セッションの各々について、対応するクライアント・セッション状態情報を記憶する工程と、
   ｈ）該クライアント配信フォーマットを使用して該ストリーミング・メディア・コンテンツ・アイテムを該クライアント・コンテナ・フォーマットで該クライアント・デバイスに送信する工程と、を備える方法。
6. 前記パックする工程は、前記第１の複数のコンテンツ・フラグメントを第２の複数のコンテンツ・フラグメントにリアセンブルすることによって実行され、該第２の複数のコンテンツ・フラグメントは前記第１の複数のコンテンツ・フラグメントとは異なる持続時間を有する、請求項５に記載の方法。
7. 所定の配信フォーマットを使用して１つまたは複数の要求を送信し、応答が首尾よく受信されたかどうかを判定することによって、前記オリジン・サーバが前記配信元配信フォーマットで送信するように構成されていると判定する工程をさらに備える、請求項５または６に記載の方法。
8. 前記クライアント要求を複数の所定の要求パターンと比較することによって前記クライアント要求が前記クライアント配信フォーマットであると判定する工程をさらに備える、請求項５乃至７のいずれか一項に記載の方法。
9. ストリーミング・メディア・コンテンツ・アイテムをオリジン・サーバからクライアント・デバイスに配信するためのシステムであって、該オリジン・サーバが該ストリーミング・メディア・コンテンツ用の配信元コンテナ・フォーマットおよび配信元配信フォーマットを有し、該ストリーミング・メディア・コンテンツが配信元符号化フォーマットで符号化された第１の複数のコンテンツ・フラグメントからなるシステムにおいて、
   ａ）該ストリーミング・メディア・コンテンツ・アイテムの少なくとも要求される部分に関する少なくとも１つのクライアント要求をクライアント・デバイスから受信し、該少なくとも１つのクライアント要求に対応する中間要求を生成するように構成されたマッピング・モジュールと、
   ｂ）該少なくとも１つのクライアント要求が受信されたときにストリーミング・セッションを開始するように構成されたセッション管理モジュールであって、該少なくとも１つのクライアント要求を監視することによって該ストリーミング・セッションに関する該クライアント・デバイスのセッション状態を判定するようにさらに構成されており、前記少なくとも１つのクライアント要求を複数のオープン・クライアント・セッションのうちの１つに関連付けるべく、前記複数のオープン・クライアント・セッションの各々について、対応するクライアント・セッション状態情報を記憶するようにさらに構成されたセッション管理モジュールと、
   ｃ）該中間要求を該サーバに送信し、該ストリーミング・メディア・コンテンツ・アイテムの該要求される部分に対応する該第１の複数のコンテンツ・フラグメントのサブセットを受信するように構成された中間クライアント・モジュールと、
   ｄ）前記配信元コンテナ・フォーマットから前記サブセットをアンパックし、前記サブセットをクライアント・コンテナ・フォーマットにパックするように構成されたコンテナ変換モジュールであって、該クライアント・コンテナ・フォーマットでパックされた前記サブセット中の前記コンテンツ・フラグメントは前記配信元符号化フォーマットで符号化されたままである、コンテナ変換モジュールと、
   ｅ）該ストリーミング・メディア・コンテンツ・アイテムを該クライアント・デバイスに送信するように構成された中間サーバ・モジュールと、を備えるシステム。
10. 前記マッピング・モジュールは、クライアント配信フォーマットを使用して前記クライアント要求を受信し、前記クライアント要求が前記クライアント配信フォーマットであると判定するように構成され、前記中間要求は前記配信元配信フォーマットであり、前記第１の複数のコンテンツ・フラグメントの前記サブセットは、前記配信元配信フォーマットを使用して前記オリジン・サーバから前記配信元コンテナ・フォーマットで受信され、前記中間サーバ・モジュールは、該クライアント配信フォーマットを使用して前記ストリーミング・メディア・コンテンツ・アイテムを該クライアント・コンテナ・フォーマットで
    前記クライアント・デバイスに送信するように構成される、請求項９に記載のシステム。
11. 前記セッション管理モジュールは、すべてのオープン・クライアント・セッションの状態を特定するようにさらに構成される、請求項９または１０に記載のシステム。
12. 前記セッション管理モジュールは、所定のタイムアウト期間の後で前記セッション状態をイナクティブとマークするようにさらに構成される、請求項９乃至１１のいずれか一項に記載のシステム。
13. 前記セッション管理モジュールは、前記オープン・クライアント・セッションに関連するさらなるフラグメント要求が受信されたときに前記セッション状態をアクティブとマークするようにさらに構成される、請求項１２に記載のシステム。
14. 前記少なくとも１つのクライアント要求は複数のクライアント要求からなり、前記セッション状態は、該複数のクライアント要求のタイミングに基づいて判定される、請求項９乃至１３のいずれか一項に記載のシステム。
15. 前記タイミングが、前記複数のクライアント要求が順序を外れたフラグメントを求める要求であることを示すとき、シーク動作が決定される、請求項１４に記載のシステム。
16. 前記タイミングが、実際の経過時間が前記複数のクライアント要求において要求されたフラグメントの再生時間を超えていることを示すとき、トリック再生動作が決定される、請求項１４に記載のシステム。
17. ストリーミング・メディア・コンテンツ・アイテムをオリジン・サーバからクライアント・デバイスに配信するための方法であって、該オリジン・サーバが該ストリーミング・メディア・コンテンツ用の配信元コンテナ・フォーマットおよび配信元配信フォーマットを有し、該ストリーミング・メディア・コンテンツが配信元符号化フォーマットで符号化された第１の複数のコンテンツ・フラグメントからなる方法において、
    ａ）該ストリーミング・メディア・コンテンツ・アイテムの少なくとも要求される部分に関する少なくとも１つのクライアント要求をクライアント・デバイスから受信する工程と、
    ｂ）該少なくとも１つのクライアント要求に対応する中間要求を生成する工程と、
    ｃ）該少なくとも１つのクライアント要求が受信されたときにストリーミング・セッションを開始する工程と、
    ｄ）該少なくとも１つのクライアント要求を監視することによって該ストリーミング・セッションに関する該クライアント・デバイスのセッション状態を判定する工程と、
    ｅ）該中間要求を該サーバに送信する工程と、
    ｆ）該ストリーミング・メディア・コンテンツ・アイテムの該要求される部分に対応する該第１の複数のコンテンツ・フラグメントのサブセットを受信する工程と、
    ｇ）前記配信元コンテナ・フォーマットから前記サブセットをアンパックし、前記サブセットをクライアント・コンテナ・フォーマットにパックする工程であって、該クライアント・コンテナ・フォーマットでパックされた前記サブセット中の前記コンテンツ・フラグメントは前記配信元符号化フォーマットで符号化されたままである、工程と、
    
    ｈ）前記クライアント要求が受信されたときにストリーミング・セッションを開始し、
    前記クライアント・デバイスからのフラグメント要求を監視することによって前記ストリーミング・セッションに関する前記クライアント・デバイスのセッション状態を判定し、
    前記クライアント要求を複数のオープン・クライアント・セッションのうちの１つ
    に関連付けるべく、前記複数のオープン・クライアント・セッションの各々について、対応するクライアント・セッション状態情報を記憶する工程と、
    ｉ）該ストリーミング・メディア・コンテンツ・アイテムを該クライアント・デバイスに送信する工程と、を備える方法。
18. 前記クライアント要求は、クライアント配信フォーマットを使用して受信され、前記中間要求は前記配信元配信フォーマットであり、前記第１の複数のコンテンツ・フラグメントの前記サブセットは、前記配信元配信フォーマットを使用して前記オリジン・サーバから前記配信元コンテナ・フォーマットで受信され、前記ストリーミング・メディア・コンテンツ・アイテムは、該クライアント配信フォーマットを使用して該クライアント・コンテナ・フォーマットで前記クライアント・デバイスに送信される、請求項１７に記載の方法。
19. すべてのオープン・クライアント・セッションの状態を特定する工程をさらに備える、請求項１７または１８に記載の方法。
20. 所定のタイムアウト期間の後で前記セッション状態をイナクティブとマークする工程をさらに備える、請求項１７乃至１９のいずれか一項に記載の方法。
21. 前記オープン・クライアント・セッションに関連するさらなるフラグメント要求が受信されたときに前記セッション状態をアクティブとマークする工程をさらに備える、請求項２０に記載の方法。
22. 前記少なくとも１つのクライアント要求は複数のクライアント要求からなり、前記セッション状態は、該複数のクライアント要求のタイミングに基づいて判定される、請求項１７乃至２１のいずれか一項に記載の方法。
23. 前記タイミングが、前記複数のクライアント要求が順序を外れたフラグメントを求める要求であることを示すとき、シーク動作が決定される、請求項２２に記載の方法。
24. 前記タイミングが、実際の経過時間が前記複数のクライアント要求において要求されたフラグメントの再生時間を超えていることを示すとき、トリック再生動作が決定される、請求項２２に記載の方法。

Images