特許 5715669 ネットワークにおけるストリーミングデータコンテンツ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5715669

(24)【登録日】2015年3月20日

(45)【発行日】2015年5月13日

(54)【発明の名称】ネットワークにおけるストリーミングデータコンテンツ

(51)【国際特許分類】

   G06F 13/00 20060101AFI20150423BHJP

【ＦＩ】

   G06F13/00 353A

【請求項の数】8

【全頁数】27

(21)【出願番号】特願2013-212207(P2013-212207)

(22)【出願日】2013年10月9日

(62)【分割の表示】特願2010-518265(P2010-518265)の分割

【原出願日】2008年7月2日

(65)【公開番号】特開2014-53024(P2014-53024A)

(43)【公開日】2014年3月20日

【審査請求日】2013年10月10日

(31)【優先権主張番号】11/828,226

(32)【優先日】2007年7月25日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】504441048

【氏名又は名称】シリコン イメージ，インコーポレイテッド

(74)【代理人】

【識別番号】100110928

【弁理士】

【氏名又は名称】速水 進治

(74)【代理人】

【識別番号】100127236

【弁理士】

【氏名又は名称】天城 聡

(74)【代理人】

【識別番号】100149696

【弁理士】

【氏名又は名称】田中 俊夫

(72)【発明者】

【氏名】シュミット ブライアン ケイ

(72)【発明者】

【氏名】ハンコ ジェイムズ ジー

(72)【発明者】

【氏名】ノースカット ジェイ デュエイン

【審査官】 田上 隆一

(56)【参考文献】

【文献】 特開２００６−３３２９４３（ＪＰ，Ａ）

【文献】 国際公開第２００６／０９５７４２（ＷＯ，Ａ１）

【文献】 特開２００１−１０３４４４（ＪＰ，Ａ）

【文献】 国際公開第２００７／０１１７６６（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

ストリーミングデータコンテンツをつなぎ合わせるための方法であって、
ネットワーク内の第１のデバイスから当該ネットワーク内の第２のデバイスまでデータ・ストリームを伝送する要求を受信する処理であって、前記要求は前記第２のデバイスから送信されて前記第１のデバイスによって受信され、前記データ・ストリームのデータコンテンツは、データ・プロトコルに従いコード化されており、かつ暗号プロトコルに従い暗号化されており、前記データ・ストリームが複数のデータ塊を含む当該処理と、
前記データ・ストリームを解読しかつ少なくとも一部を復号化する処理と、
前記データコンテンツの連続的なセクションを、前記連続的なセクションが前記データ塊内で開始し、終了し、又は含まれているかをあらわすため、前記データ・ストリームに関する要約情報内のデータ塊にインデックスビットを割り当てることにより決定する処理と、
前記連続的なセクションが前記データ塊内で開始し、終了し、又は含まれているかをあらわすため、前記データ・ストリームに関する要約情報内のデータ塊にインデックスビットを割り当てる処理と、
前記ネットワークに関するプロトコルに従い、前記データ・ストリームの各データ塊を再び暗号化する処理と、
前記データ・ストリームの各データ塊に関する前記要約情報をデータパケットのヘッダーに付ける処理と、
暗号化されコード化された形式の前記データコンテンツを含む前記ネットワーク上のデータ・ストリームを前記第１のデバイスから前記第２のデバイスまで伝送する処理と、
前記第２のデバイスで前記データ・ストリームを受信する処理と、
前記データ・ストリームを解読又は復号化することなく、前記第２のデバイスにより前記受信したデータ・ストリームを前記要約情報に基づき操作する処理であって、前記データ・ストリームの操作は、前記要約情報に基づき前記データコンテンツのタイミングメモリ順序を変えることを含む当該処理と、
が実行される方法。

【請求項2】

データをストリーミングするための方法であって、
ネットワーク内の第１のデバイスから当該ネットワーク内の第２のデバイスまでデータ・ストリームを伝送する要求を受信する処理であって、前記要求は前記第２のデバイスから送信されて前記第１のデバイスによって受信され、前記データ・ストリームのデータコンテンツは、データ・プロトコルに従いコード化されており、かつ暗号プロトコルに従い暗号化されており、前記データ・ストリームが複数のデータ塊を含み、各データ塊は前記データ・プロトコルに従い１以上のブロックを含む当該処理と、
前記データ・ストリームを解読しかつ少なくとも一部を復号化する処理と、
前記データ・ストリームに関する要約情報における各データ塊内のブロックの番号及びサイズを割り当てる処理と、
前記ネットワークに関するプロトコルに従い、前記データ・ストリームの各データ塊を再暗号化する処理と、
前記データ・ストリームの各データ塊に関する前記要約情報をデータパケットのヘッダーに付ける処理と、
暗号化されコード化された形式の前記データコンテンツを含む前記ネットワーク上のデータ・ストリームを前記第１のデバイスから前記第２のデバイスまで伝送する処理と、
前記第２のデバイスで前記データ・ストリームを受信する処理と、
前記データ・ストリームを解読又は復号化することなく、前記受信したデータ・ストリームを前記第２のデバイスによって前記要約情報に基づき操作する処理であって、前記データ・ストリームの操作は、前記要約情報に基づき前記データコンテンツのタイミング又は順序を変えることを含む当該処理と、
が実行される方法。

【請求項3】

前記第１のデバイスによって、前記各データ塊内の１以上のブロックの各々に関するブロックキャプチャータイムスタンプを割り当てる処理を更に含む、請求項２に記載の方法。

【請求項4】

前記第１のデバイスによって、前記各データ塊内の１以上のブロックの各々に関して、ペイロードのブロックがヌルデータを含むかどうかをあらわすヌル・ペイロードフラグを割り当てる処理を更に含む、請求項２に記載の方法。

【請求項5】

デバイス間でデータをストリームするシステムであって、
(1)データ・ストリームを生成するように構成された第１のデバイスを備え、前記データ・ストリームに関するデータコンテンツは暗号化及びコード化され、
前記第１のデバイスによって前記データ・ストリームを生成することは、
(a)前記データコンテンツを解読し、及び前記データコンテンツの少なくとも一部を復号化し、
(b)前記データ・ストリームに関する要約情報の少なくとも一部を得るため、前記解読され復号化されたデータコンテンツを評価することであって、前記要約情報は、前記データコンテンツのためのシーケンス情報を提供するシーケンス番号、及び前記データ・ストリームに関係のあるデータコンテンツのためのタイミング情報を提供するタイムスタンプ値を含むこと、
(c)前記要約情報を前記データ・ストリームに追加すること、
を含み、更に、
(2)前記第１のデバイスから、暗号化されコード化された形式の前記データコンテンツを含む前記データ・ストリームを受信するように構成された第２のデバイスを備え、
前記第２のデバイスは、前記データ・ストリームを解読又は復号化することなく、前記受信したデータ・ストリームを操作し、当該データ・ストリームの操作は、前記要約情報に基づき前記データコンテンツのタイミング又は順序を変えることを含む、
ことを特徴とするシステム。

【請求項6】

前記第２のデバイスは、前記データ・ストリームのデータコンテンツ、又は、前記データコンテンツの暗号化若しくはコーディングを認識していない、請求項５に記載のシステム。

【請求項7】

前記データ・ストリームの操作は、前記要約情報に基づき、前記データ・ストリーム内の第１のポイントから第２のポイントまでジャンプすることを更に含む、請求項５に記載のシステム。

【請求項8】

前記第２のデバイスは、前記データ・ストリームの配信に関し、前記第１のデバイスに対してフィードバックを提供する、請求項５に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、一般的にはネットワーク分野に関連しており、かつ、より具体的には、ネットワークにおけるデータコンテンツのストリーミング方法及び装置に関連する。

【発明の概要】

【発明が解決しようとする課題】

【0002】

個人向け電子的エンターテイメントの選択肢が増加するにつれて、データを共有し、便利さを高め、各々の要素を一層十分に活用できるようにするために、ネットワークにおいて種々のメディアデバイスを互いに接続することについての動機付けが益々増大している。例えば、家庭内にある幾つかのデバイスを、互いに接続できるようにすることが考えられる。そのような環境では、オーディオ、ビデオ、ゲーム、その他の用途のためのデジタル・メディアコンテンツをストリーミングさせる複数の潜在的なソース及びユーザが存在する。

【0003】

エンターテイメント・ネットワークを確立するために、複数のデバイスを互いにネットワークに統合するための従来のコンピュータネットワーク構築モデルを使用することが可能である。そのような環境では、メディアデータのストリーミングは、可能性としては、既知のデータ伝送プロトコルを使用して、サーバーと他のネットワークに接続されたデバイスとの間で伝送されることになる。

【0004】

しかしながら、従来のネットワーク構築は、一般に、ネットワークのデバイスにとってコンピュータ作動のために高度の電力を必要とするものである。更に、伝送プロトコルは、一般に、伝送されるデータに関する高いレベルの知識を必要とする。メディアデータのストリーミングには、異なる目的及びデバイスのために広範囲にわたり、種々フォーマットが現存する。フォーマットは、より古いフォーマットが新しい機能性の提供や新しいデバイス技術の支援を意図した、より新しいプロトコルと置換され、もしくは補足されるので、激増している。その結果、デバイスからなるネットワークは、エンターテイメント・ネットワーク内の各デバイスに対して比較的洗練されたインターフェース技術やコンピュータ動作を要求することとなり、メディア技術における急速な変化に対して脆弱になる。

【課題を解決するための手段】

【0005】

ネットワークにおいてデータコンテンツをストリーミングするための方法及び装置が提供される。

【0006】

本発明の第１の側面では、装置は、ネットワーク上にデータ・ストリームを生成するためのネットワーク・ユニットを含むことができ、この場合、データ・ストリームの生成は、データの要約情報の生成を含む。この装置は又、生成されたデータ・ストリームを送信するための送信器を含むことができる。

【0007】

本発明の第２の側面では、装置は、第２の装置からデータのストリームを受け取るための受信器を含むことができ、この場合、データはコード化され、かつ該データに関する要約情報を含む。装置は、さらに、データに関する要約情報に少なくとも部分的に基づいてデータのストリームを扱うためのネットワーク・ユニットを含むことができる。

【0008】

本発明の第３の側面では、ネットワークは、該ネットワーク上でデータのストリームを生成する最初のネットワーク・デバイスを含むことができ、その場合、データはデータ・プロトコルに従ってコード化される。データ・ストリームの生成は、少なくとも部分的にデータを解読すること、該データを評価して該データに関する要約情報を得ること、及び該データに要約情報を挿入することを含む。このネットワークはさらに、第１のネットワーク・デバイスからデータ・ストリームを受け取る第２のネットワーク・デバイスを含むことができる。

【0009】

本発明の実施形態は、添付図面の図の中に、限定ではなく例として図解されており、そこでは同じ参照数字は同様の要素を表している。

【図面の簡単な説明】

【0010】

【図1】エンターテイメント・ネットワークの実施形態の図である。

【図2】ネットワークにおけるネットワークデバイス間の接続の実施形態を示す図である。

【図3】ネットワークにおける移送のためにデータの準備を行う実施形態の図である。

【図4】データの要約ヘッダの実施形態の図である。

【図5】データのために提供されるヘッダの実施形態の図である。

【図6】ネットワークにおけるストリーム・データを移送する方法の実施形態の図である。

【図7】データのストリーミングを要約する方法の実施形態の図である。

【図8】ネットワークデバイスの実施形態の図である。

【発明を実施するための形態】

【0011】

本発明の実施形態は、一般に、メディアコンテンツのストリーミングに向けられている。

【0012】

ここに使用される「エンターテイメント・ネットワーク」は、デバイス間でデジタル・メディアコンテンツ（音楽、オーディオ/ビデオ、ゲーム、写真その他のものを含む）を伝えるための相互接続ネットワークを意味する。エンターテイメント・ネットワークは、家庭におけるネットワーク、仕事におけるエンターテイメント・ネットワーク、その他いろいろな娯楽デバイスのネットワークなど、個人向けエンターテイメント・ネットワークを含むことができる。そのようなネットワークにおいて、デジタル・テレビ・チューナ、ケーブル・セット・トップ・ボックス、ビデオ格納サーバーその他のソースデバイスのようなある種のネットワークデバイスは、メディアコンテンツのソースとなることができる。デジタル・テレビ、ホームシアター・システム、オーディオ・システム、ゲーム・システムその他のデバイスのような他のデバイスは、メディアコンテンツを表示したり、使用したりすることができる。さらに、ビデオ・オーディオ格納サーバーのようなある種のデバイスは、メディアコンテンツを格納し、又は伝送するように意図されたものとすることができる。ある種のデバイスは複数のメディア機能を遂行することができる。一部の実施形態では、複数のネットワークデバイスを、単一のローカル・エリア・ネットワーク上に共同して設置することができる。他の実施形態では、ネットワークデバイスは、複数のローカル・エリア・ネットワーク間に通すことなどにより、複数のネットワーク・セグメントにまたがらせることができる。エンターテイメント・ネットワークは、複数のデータ符号化及び暗号化方法を含むことができる。

【0013】

一部の実施形態では、ネットワークは、データを解読又は復号化せずにデータの伝送、格納及び操作が可能になるように、データ・ストリームをカプセル化する。一部の実施形態では、ネットワークは、実際のコンテンツ、符号化あるいは暗号化についての知識を何ら必要とせずに、ネットワーク動作のために、データコンテンツを要約するデータのデジタル・パケット・コンテナ・フォーマットを利用する。ここで使用される要約とは、データを要約し、特徴づけ、そして識別することを含む。

【0014】

広範囲に種々異なるデバイスがエンターテイメント・ネットワーク上に存在する可能性があるため、広範囲に種々異なるメディア・フォーマットが使用されている。しかしながら、従来の動作においては、すべてのデバイスがデジタル・メディア・コンテンツを搬送し、又は格納できるようにするためには、各々のデバイスは、いずれも、すべての使用可能なフォーマットを理解できることが要求され、あるいは、任意にフォーマットされたコンテンツの不透明な送信及び格納が可能になるように、データ・コンテナのフォーマットが必要になる。一部の実施形態では、ネットワークは、すべてのフォーマットについての知識を要求することなく、かつ完全に不透明なコンテナ・フォーマットを利用することを要求せずに、データの伝送を可能にする。加えて、伝送されるメディア・コンテンツは、暗号化されていてもよい。一部の実施形態では、コンテナ・フォーマットは、そのようなデータを扱うすべてのデバイスが、データの暗号解読を必要とせずに、データコンテンツの操作を可能にする情報を含むものとして実装される。

【0015】

一部の実施形態では、既存のネットワーク・プロトコルが、デジタルデータの伝送に利用される。デジタルメディアで構成されたペイロードを搬送するのに適した様々なネットワーク・プロトコルが存在する。一例として、ＲＴＰ（リアルタイム・トランスファー・プロトコル）は、オーディオ、ビデオその他のメディアデータを伝送するために利用することができる。ＲＴＰは、種々異なるメディアフォーマットに対するカプセル化を含んでおり、かつ、ＵＤＰ（ユーザ・データグラム・プロトコル）を介して直接搬送するか、あるいは、もし余分なユーザレベルのパケット化がＴＣＰ内で用いられる場合には、ＴＣＰ（伝送制御プロトコル）内でカプセル化することができる。

【0016】

しかしながら、移送のためにＲＴＰを直接利用するためには、幾つかのデバイスにとって、すべてのフォーマット・タイプを理解することが要求されることになるが、それは、エンターテイメント・ネットワークのようなネットワークにおいては、困難もしくは非実用的である。一例において、ビデオ記憶サーバーが「トリック・プレー」サポート（例えば、早送り、巻き戻し及び同様の操作を含む。）を備えることが望まれている場合、そのことは、従来システムにおけるデータフォーマットについての知識を要求するものとなるであろう。この例においては、ビデオ記憶サーバーがＲＴＰによりカプセル化されたストリームを格納のために受け取る場合には、該サーバーは、ストリーム・データ位置にストリームの到達時間を関連づけるための指標を生成することを要望することができる。この時間ベースの指標に作成には、該記憶サーバーは、インデックスポイントを決定するためにすべてのメディアフォーマットの少なくとも一部を復号化することが、一般に要求されることになる。ネットワークで使用が可能な大半のフォーマットでは、この操作は実際の動作において非実用的である。さらに、暗号化されたメディア・コンテンツを解読するには、前記ビデオ記憶サーバーは、暗号化のサポート及び全データにアクセスする必要なキーが必要になるであろう。記憶サーバーは、通常は信託デバイスではないので、これは困難である。

【0017】

一部の実施形態では、要約フォーマットはメディアデータ内で実行される。一部の実施形態では、ネットワーク・フォーマットをサポートするネットワーク構成エンティティのいずれも、コンテンツフォーマット、データのコード化あるいはデータ暗号化のための知識を要求されることなしに、データの共通伝送体として機能するために、要約フォーマットを利用することができる。一部の実施形態では、データ要約は、これに限るものではないが広く用いられているＲＴＰを含む、既存のプロトコルの拡張によって実行される。一部の実施形態では、データ要約は、共通伝送体ネットワークデバイスの設計を単純化をすることができ、例えば記憶デバイスのように、メディア・コンテンツを解釈する必要のないものとすることができ、かつ、単一のプロトコル及びパケット・フォーマットを、すべての形式のデータのために使用できるようになるので、ネットワークデバイスのためのストリーミングエンジンのモジュール化を可能にすることができる。データにアドレスするためには、ストリームに関係する幾つかのメタデータが要求されることになる。一部の実施形態では、データから求められる情報を抽出するためのこの要求は、データ送信デバイスのみが負担させられることになる。

【0018】

一部の実施形態では、共通伝送体デバイスが、要約情報をもつデータ・ストリームを受取り、データ・ストリームの再送信のためのデータ・ストリームのタイミングを再び生成し、再送信のために、あらゆる圧縮ヌル・データ・パケットも解凍し、早送り、巻戻し、データ・ストリーム内でのジャンピング、送り及び戻りにおける送信速度を早くしたり、遅くしたりすること、並びにデータ分割のような、送信におけるトリック・プレー作動を提供し、データの解読を行わずにデータ・ストリームを再送信するように動作することができる。

【0019】

ネットワーク通信では、デジタルメディアの発生器（これは、例えばデジタル・テレビ・チューナあるいはデジタル・カメラとすることができる）及びユーザすなわちデータの受信者（これは、例えばデジタル・テレビとすることができる）が、メディアのコード化について理解し合意すること、コンテンツを暗号化し、あるいは解読するための権利を持つことが従来から要求されている。一部の実施形態では、データの発生器は、コンテンツに関するある要約情報を得るためにデータコンテンツを解読し、部分的にデコードすることができる。 一部の実施形態では、発生器は、データの特性を反映するようにメディア要約フォーマットでコード化され暗号化されたメディア・コンテンツをカプセル化することができる。一部の実施形態では、受信者デバイスは、合意がないか、あるいはメディアのコード化についての知識及びデータを解読もしくは暗号化する権利のないまま、メディア要約を使用してメディアデータを受信し伝送することができる。

【0020】

一部の実施形態では、要約ヘッダに示される要約フォーマットは、データ・ストリームとしてパッケージされるあらゆるメディアコード化を含むものとされる。伝送されるデータは、いずれも、そのコーディングに反映されるようにすることができる。例えば、写真データは、１つのフレームによるビデオ・ストリームと解釈され、したがって、ビデオ・ストリーム・データとして伝送することができる。一部の実施形態では、要約ヘッダは、例えばネットワークデバイス・インタフェースにワンチップによる解決をもたらす、といった、低コスト、低資源のネットワークデバイスの実施を可能とする手法を提供する。対照的に、従来のホームネットワーク・スキームは、例えばパーソナルコンピュータを含むか、あるいはネットワークデバイス中に複数の顧客ＡＳＩＣｓあるいは共有プロセッサを含む、というように、高い資源環境を要するように設計されている。

【0021】

一部の実施形態では、要約ヘッダは移送プロトコルによって提供されるヘッダの拡張として実施することができる。例えば、要約ヘッダは、ＲＴＰヘッダの拡張として実施することができる。

【0022】

一部の実施形態では、デジタルメディアは、ＵＤＰ／ＩＰ（この場合、プロトコルの信頼性は、データが到着したこと又はデータが無傷であることを確認するための備えがあるか否かを重視する。）のような信頼性の低いデータグラム・プロトコルによって伝達されるものとすることができる。何らかの時間制限の下でメディアデータを送らなければならないので、信頼できる送信に対する必要性は、時間依存性であり、コンテンツに特有のものである。この理由のために、メディアデータは、信頼性の低いプロトコル上で有効に伝送することができる。これらのプロトコルは、典型的にはローカル・エリア・ネットワーク上で作動することができる。ブリッジを使用することにより、プロトコルは複数のローカル・エリア・ネットワークにまたがるようにすることができる。メディアデータ・ストリームは、一般に、時間が重要なコンポーネントを含むものであるので、データの保証された配信は必要ではない（古いデータが有用でないので）。さらに、保証されたデータ配信は、許容できる制限を越えてパケットを遅らせることによってネットワークに停滞が生じることになれば、サービスの全体的な品質を低下させることになる。

【0023】

一部の実施形態では、要約ヘッダは、データコンテンツと関係する様々な情報を提供する。この情報は、ネットワークデバイスがストリーム・コンテンツを理解せずにストリームを管理もしくは操作することを可能にするために、ストリームに関する一定の詳細条項を提供するように構成された、データとは独立の一組の注釈群を形成する。該ヘッダに含まれた注釈のいくつかのものは、コンテンツ自体に固有の、例えばコンテンツ形式のフラグ及びストリームに対応したタイムスタンプのような静止情報を表わす。

【0024】

要約についての情報を得るには、ある程度の分析とストリーム・コンテンツの理解を必要とする。一例では、ＭＰＥＧ形式ストリームにおける特定セクションのストリーム関連タイムスタンプを抽出するために、いずれかのデバイスが、ＭＰＥＧデータの部分的な符号解読を行って、到達時点のタイムスタンプを決定する。一部の実施形態では、この機能は、ネットワークの入口のデバイスに制限されており、それらは放送チューナーやインターネットゲートウエイのようなネットワーク上にコンテンツの進入を認めるデバイスである。入口デバイスは更に、あらゆる外部のコンテンツ保護機構も管理するであろう。そして、一部の実施形態では、記憶デバイスのようなネットワーク内の他のデバイスは、大量のコンテンツ形式について、部分的に又は完全に符号解読をサポートする必要なしに、かつ、保護されたコンテンツを解読する必要なしに、ストリームを取り扱うことができる。一部の実施形態では、入口デバイスは、外部条件つきのアクセススキームでデータ保護されたコンテンツを受け、該コンテンツを解読し、コンテンツを解析し、これに注釈を付して要約情報を形成し、ネットワーク保護計画にしたがってペイロードのコンテンツを暗号化し、またネットワークの中に該データを広める。

【0025】

一部の実施形態では、データ・コンテンツがバッファされる場合、例えば記憶デバイスにバッファされる場合には、常に要約情報が保存される。要約情報を形成する注釈は、元のタイムベースによりストリームの再伝送を終わらせることができるようにし、かつ、ストリームにおける参照時間が付されたポイントにジャンプするか、又はトリック・プレー・モードを利用することを可能にする。

【0026】

一部の実施形態では、要約ヘッダ内のコンテンツ形式及びモード・フラグを物理的ネットワーク層において利用して、送信のためのパケット優先事項を割り当てることができる。確立された優先順位は、特定の実施によって変更することができる。可能な一例においては、次の相対的な優先順位を用いることができる。（最も高い優先度から最も低い順に）:（ａ）保護キーが埋め込まれたコンテンツ、（ｂ）オーディオ・データ、（ｃ）第１次キーのビデオ・フレーム・データ、（ｄ）第２次キーのビデオ・フレーム・データ、（ｅ）キーのないビデオ・フレーム・データ、（ｆ）ヌル・データ、及び（ｇ）帯域幅予約データ。

【0027】

図１は、エンターテイメント・ネットワークの実施形態の説明図である。この図において、エンターテイメント・ネットワーク・システム１００は、ネットワークへの互換性のあるあらゆるメディアデバイスと接続することができる。この接続は、エンターテイメント・ネットワーク１０５への接続として示されている。一部の実施形態では、デバイスは、中央ネットワーク・サーバーのないネットワークとして作動する。メディア・データ・ストリームは、接続されているあらゆるデバイスとの間でもエンターテイメント・ネットワークを通じて伝送することができる。さらに、デバイスは、ネットワークを通じて遠隔制御することができる。該デバイスは、同軸ケーブル、イーサネット・ケーブル及びファイヤーワイヤー（Ｆｉｒｅｗｉｒｅ）、及びワイファイ（Ｗｉ−Ｆｉ）を含む既知のコネクタのいずれか、或いは、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ）その他の無線技術を経由する無線接続を含む、接続プロトコルにより、ネットワークに接続することができる。

【0028】

一部の実施形態では、デバイスは、如何なるメディアソース又は受取人を含むこともできる。図１では、オフィス１１０が、ゲートウェイ１２２を通るネットワーク１０５へのインターネット接続１２０を形成する。インターネットから受信するデータは、どのようなストリーミングメディアソースでも含むことができ、これらには、購入されたオーディオ・ファイル(例えばダウンロードされた音楽ファイル）、ビデオファイル（例えば映画、ＴＶ、その他）、及びコンピューターゲームを含まれるが、それらに限定されるものではない。オフィス１１０は又、モニタ１２６を利用し、他の機能のほかに、特定のメディアストリームを表示したり、特定のコンピューターゲームを作動させることができるパーソナルコンピュータ１２４に接続することができる。

【0029】

エンターテイメント・ネットワークは又、例えばテレビ１３２にデータを供給するためのセットトップ・ボックス１３０を含む寝室１１２内のデバイスと接続することができる。さらに、寝室（あるいは任意の他のスペース）は、メディア記憶ユニット１２８を含むことができる。このメディア記憶ユニット１２８は、ネットワーク１０５に接続されたいずれかのソースからデータを受け取ることができ、かつ、ネットワーク１０５に接続されたいずれかのデータ受取人にデータを提供することもできる。メディア記憶ユニット１２８は、ネットワークのためのいずれかの形式のメディアストリーム・データを含むことができる。

【0030】

このシステムは、更に、居間１１４での受信、例えばケーブル又はファイバーシステム１３４からの入力、或いは衛星放送受信アンテナネットワーク１３６からの入力を受信することができる。そのようなソースからのメディア入力は、ネットワーク１０５と第２のテレビ１４０に接続されたセット・トップ・ボックス１３８に供給することができる。また、居間にあるテレビ１４０でディスプレイするために、ビデオゲーム・ユニット１４２をネットワーク１０５に接続することもできる。他にも、ネットワーク接続されたデバイスを備えた部屋を幾つ設けてもよく、例えば台所にネットワーク１０５接続された第３のテレビ１４４置くことができる。また、他のネットワークデバイスを設けることもでき、限定する意味ではないが、家の至る所に置かれたスピーカーを含むステレオ・オーディオ・システムを備えることができる。

【0031】

さらに、どのような数であっても、携帯型個人用電子機器を前記ネットワークに接続することができる。これらのデバイスは、ケーブルによって、あるいは無線信号によって接続することができ、これにはブルートゥース（Ｂｌｕｅｔｏｏｔｈ）、ワイファイ（Ｗｉ−Ｆｉ）、赤外線あるいは他の同様の無線通信プロトコルが含まれるが、これに限定されるものではない。個々のそのようなプロトコルは、ワイファイのベース・ステーションのようなネットワーク（それは図１の中で示されない）へのインタフェースを必要とする場合がある。そのような携帯型個人用電子機器としては、デジタル・カメラ１４６、携帯電話１４８、個人的な音楽デバイス１５０あるいはビデオカメラ１５２がある。さらに、自動車がネットワークのすぐ近くにある場合（家のガレージの中にある場合のように）には、自動車１５４の可動システムを、ネットワーク１０５に接続することができる。携帯型個人用電子機器は、ネットワークの範囲内に位置する場合には、例えば自動的に、ネットワークに接続するように構成することができる。接続された状態では、デバイスはネットワークを通じてデータを得ることができ、ネットワークにデータを提供することができるが、この動作には、デバイスへの自動更新あるいはダウンロードを含むことができる。一例では、ユーザは、あらゆる可動電子機器に蓄えられたデータに、ネットワークを通じてアクセスでき、例えばセットトップ・ボックス１３８を介して、居間のテレビ１４０の上のデジタル・カメラ１４６に格納された写真にアクセスすることができる。

【0032】

ネットワークに接続された複数のデバイスは機能が異なるので、ネットワークを通じて伝送されるデータは、既知のビデオ・プロトコル及びオーディオ・プロトコルといった様々なデータ・プロトコルを含むことになる。一例では、メディア記憶ユニット１２８が複数の異なるメディアプロトコルのデータを入手し、格納し、かつ提供することを要求されることとなる。

【0033】

図２は、ネットワークにおけるネットワークデバイス間の接続についての実施形態の説明図である。この説明図では、第１のネットワークデバイス２０５（デバイス１）は、エンターテイメント・ネットワークを含むネットワークを介して、第２のネットワークデバイス２１５（デバイス２）に接続されている。（前記ネットワークの残り部は図２では示さないが、例えば図１の中で示されたもののような各デバイスを含むものとすることができる。)各ネットワークデバイスは、ネットワークの中でデバイスの作動を可能にするためにネットワークインターフェイス（第１のデバイス２０５のためのネットワークインターフェイス２１０及び第２のデバイス２１５のためのネットワークインターフェイス２２０）を含むことができる。

【0034】

この説明図では、第１のデバイス２０５はデータ・ストリーム２２５のソースであり、また、第２のデバイス２１５は該データ・ストリームの受取人とすることができる。例えば、第１のデバイス２０５に対してデータ・ストリーム２２５を第２のデバイス２１５に供給するように要求することができる。しかしながら、ネットワークデバイスはどのような形式のメディアデバイスであってもよいので、データ・ストリーム２２５は多くのデータ・プロトコルのうちの１つによってコード化されることになり、また、いずれかの暗号方法によって暗号化されている可能性がある。第２のデバイス２１５は、データ・ストリーム２２５を復号化もしくは解読する能力を持たないものとすることができるし、データ・ストリームに含まれるデータにアクセスする権利を持たないものとすることもできる。

【0035】

一部の実施形態では、データ・ストリームは、コンテンツフォーマット、コード化あるいは暗号化についての知識なしで第２のデバイス２１５がデータ・ストリーム２２５のデータを運ぶことができるように、データ要約フォーマット２３０によってカプセル化される。一部の実施形態では、データ要約フォーマットは、そのようなデータにアクセスせずに、ストリーム内のデータを運び、取り扱うために必要とされる情報を提供する要約ヘッダの形態で実施することができる。

【0036】

一部の実施形態では、第２のデバイス２１５は第１のデバイス２０５にメディアデータの到着に関する低レベルのフィード・バック２３５を供給するように形成することができる。例えば、データが到着しないか、乱れて到着する場合には、第２のデバイス２１５は否定的な応答（ＮＡＫ信号）を送り、第１のデバイス２０５が、欠落したデータエレメントを例えば再送できるようにすることができる。別の例においては、データが到着した場合、第２のデバイス２１５は第１のデバイス２０５に肯定的な確認（ＡＣＫ信号）を供給するように構成することができる。

【0037】

図３は、ネットワークにおける移送データの準備についての説明図である。例えば、移送を必要とするデータは、第１の形３０５で始まる。データは、データ・パケットとして移送されるようにするために、ネットワーク内でデータの配信のために使用される移送プロトコルに従い、データの塊３１５へ分割することができる。

【0038】

一部の実施形態では、データの準備は、さらにデータ要約フォーマットによってデータをカプセル化することを含むことができる。一部の実施形態では、カプセル化は、データ塊３２５のデータにデータ・パケット・ヘッダ３２０を利用する。ヘッダは、デバイス２２１５に対して、コンテンツフォーマット、コード化あるいは暗号化についての知識なしに、データ・ストリーム内でデータを運ぶ共通伝送体として作動できるようにする。

【0039】

一部の実施形態では、データ塊のためのヘッダ３２０が２つの部分、すなわち、

【0040】

（ａ）移送プロトコルのために必要とされる情報を含む移送プロトコル・ヘッダ３３０（ＲＴＰヘッダのような）、

【0041】

（ｂ）データコンテンツに関する情報を何一つ提供せずに、データ（・ストリーム）２２５に関する情報を提供するために加えられた要約ヘッダ３３５、
を含むものとすることができる。一部の実施形態では、ネットワークデバイスは、データを復号化又は解読をせずにデータ３２５を運び、取り扱うために要約ヘッダを利用することができる。要約ヘッダは移送プロトコル・ヘッダの一部分、あるいは拡張とすることができる。

【0042】

ネットワーク内でデジタル・コンテンツを伝送するために、該コンテンツは、一般的に、適切な移送プロトコルによるネットワーク配信にふさわしいデータの「塊」に分解される。例えば、特定のデータコード化フォーマットがＭＰＥＧ移送ストリームであり、トランスポート・プロトコルがＵＤＰ／ＩＰであれば、基本的なイーサネットフレームは、最大７つの１８８バイトの移送ストリームセルがＵＤＰペイロードの中にカプセル化されるのを可能にするであろう。この特定の例では、変数サイズの塊が許容される。一部の実施形態では、個々のそのようなデータ塊については、該塊のコンテンツについて記述するために、次のフィールドを要約ヘッダに含まれることができる。

【0043】

（ａ）データ塊のサイズ − サイズを反映するためにフィールドが備えられる。しかしながら、サイズはパケット長で表されるため、要約ヘッダには必要とされない場合がある。

【0044】

（ｂ）モード及びコンテンツフラグ − モード・フラグ・フィールドは、特定のモード情報を提供するものであり、これには、暗号化、帯域幅予約、データの渋滞、トリック・プレー・モード、接合モード及び特定のデータ・オペレーションが存在することの情報を含むが、これらに限定されるものではない。１つの可能な例では、モード標識は、通常作動（トリックプレーがない）、データが完全なトリックプレー（データに関する接合モードがない場合―ストリームの送信速度を速めたり、遅くしたりすることが可能）、及びデータが一部しかないトリック・プレー（接合モードが可能―データの全部を利用することが実用的でない場合にストリーム内で、スキップを可能とする）に関するモードを示すことができる。一部の実施形態では、受信デバイスは、トリック・プレー・モードに基づいた復号化操作を自動的に適合することができる。コンテンツフラグ・フィールドは、塊内で送られるデータの形式を示すために使用することができる。この形式には、オーディオ・データ、スタート／終了／継続する／重要なビデオフレーム・データはない、スタート／終了／継続する／予測されたビデオフレーム・データはない、及び暗号データ（キー情報のような）などについての標識を含むことができるが、これに限定されない。データの共通伝送体の役割をする中間のネットワーク・デバイスは、この情報を使用して、塊データの内容を検査することなく、ストリーム伝送（主要なビデオフレームデータ及びビデオフレームと予測されたデータがあとに続いた、暗号文及びオーディオデータのようなものに優先権を割り当てる。)を優先させることができる。一部の実施形態においては、そのような情報がタイムスタンプ情報と組み合わされている場合には、記憶サーバーが、入信するストリームのための時間指標を作成し、暗号情報及びキーフレーム時間ポイントを含む時間指標を備えたローリングキーを有する暗号化コンテンツに対しても、トリック・プレー・サポートを可能にすることができる。

【0045】

（ｃ）ヌルデータ粒度とヌルデータビットマップ − ヌルデータ粒度とヌルデータビットマップ情報は、データの共通伝送体が効率的な方法でデータ・ストリームをバッファリングすることを可能にする。メディアストリームは、通常は、メディアデータ内に点在したヌルデータを含んでいる。例えば、デジタルテレビ放送は、無効のＭＰＥＧ移送ストリーム・パケットを含んでいることが多い。一部の実施形態では、ビデオ記憶サーバーはこれらのパケットを省略し、集積スペースを保存することができる。この方法では、ヌルデータ粒度情報は、塊内において測定されるデータのヌルセクションの固定サイズを示すものであり、ヌルデータ・ビットマップは、該塊のどのセクションがヌルデータを含むかを示すものである。ある例では、要約フォーマットを使用してＭＰＥＧ移送ストリームをカプセル化するように動作するソースが、１８８バイト（移送ストリーム・セルのサイズ）に塊のサイズを設定し、ヌルデータ・ビットマップ・フィールドが、どのセルがヌルデータを含んでいるかを示すことになる。そして、記憶デバイスあるいはバッファー（例えばブリッジデバイス）を備えた他のネットワーク構成体が、ヌルデータを含むフォーマットを理解することを必要とせずに、データ塊を圧縮し、解凍することができる。

【0046】

（ｄ）暗号化クッキー − 一部の実施形態では、暗号化要素（あるいは「クッキー」）を設けることができる。この暗号化要素は、暗号化されたストリームが乱れたりあるいは時間シフトしたりして送信されるのを可能にし、レシーバーが修正済のストリームを適切に解読することを可能にするために使用することができる。一般に、メディアストリームは、ブロック暗号を用いて暗号化することができ、この場合のブロック暗号は、暗号化されるか、もしくは解読されるデータの各ブロックのシーケンス番号を要求する。一部の実施形態では、暗号化要素はシーケンス番号を伝送することができ、それは、典型的には、ネットワーク・プロトコル・ヘッダにおけるシーケンス番号に由来するものである。メディアストリームを通じて時間シフト又はスキップが行われる場合には、このネットワーク・プロトコル・シーケンス番号は、中間のデバイスに保存されないので、これらは使用可能ではないものとなる。一部の実施形態では、要約ヘッダに暗号化要素を含ませることによって、暗号化されたデータコンテンツが、データ・ストリームを表示することのない構成体にキーを渡す必要なしに、ネットワークを介して伝送されるのを可能にすることができる。

【0047】

（ｅ）ストリーム関連タイムスタンプ − 一部の実施形態では、要約ヘッダは、データ・ストリームに関するタイミングを反映するタイムスタンプを含むことができる。フィールドは、ペイ・ロード・コンテンツの最初のバイトが到達した時間に基づくものとすることができる。タイムスタンプは、その後、データ・ストリームのためのタイミング過程内で使用することができる。

【0048】

図４は、データのための要約ヘッダの実施形態の説明図である。この説明図では、図３に示されたように、データ・ヘッダが、移送プロトコル・ヘッダ３３０及び要約ヘッダ３３５を含むことができる。一部の実施形態では、要約ヘッダは、データと適切な過程を要約するために様々なデータ・フィールドを含むことができる。

【0049】

一部の実施形態では、フィールドは、データ塊のためのサイズ・フィールド４０５（それらはデータ・パケットのサイズによって暗示されるかもしれない）、現時点の操作モードに関する情報を提供するためのモード・フラグ４１０、データ塊４１５におけるヌルデータ・サイズと場所に関するフィールド、データについて記述するコンテンツフラグ４２０、暗号化されたデータの使用にシーケンス番号を供給する暗号化要素４２５、ストリームに関するタイムスタンプ４３０、及び他のフィールド４３５を含むことができるが、これに限定されるものではない。構成されたこれらのフィールドは、すべての実装において備えられないようにすることもできる。

【0050】

図５は、データのために備えられるヘッダの実施形態の説明図である。一部の実施形態では、図５に示されるように、ネットワーク・データ・パケットは共通のＲＴＰヘッダ・フォーマットを共有することができる。ＲＴＰヘッダ・フィールドは、いずれも、ＲＦＣ（リクエスト・フォー・コメント）３３５０の中で指定されるＲＴＰプロトコルのフォーマット及び解釈に従っている。この説明図では、すべての多バイトフィールドが、適切な場合には含まれることになるヘッダ・フィールドの特定値と共に、ネットワーク・バイトの順に従って表わされている。一部の実施形態では、データ・ストリームがリアルタイムで送られる場合には、データ・パケットは、ＵＤＰ／ＩＰプロトコル・パケット内でカプセル化される。パケットは、パケットが複数のＵＤＰ／ＩＰパケットにわたって分割されないように、基礎となるリンク層（例えばイーサネット）の最長ペイロードより小さいサイズであることが要求される。リアルタイムという制約がない時（例えば、あるデバイスから他のデバイスへ１つのコンテンツを伝送するような場合）には、あたかもＵＤＰ／ＩＰプロトコルを使用してストリームが伝えられたかのようにして、現実にはＴＣＰ／ＩＰプロトコルを用いてＲＴＰのカプセル化がなされる。一部の実施形態では、データ・パケットがトランスポートのより低いネットワーク層に配信される場合、例えばペイロード・コンテンツに基づいて割り当てるパケット・レベルの優先度などのように、パケットをどのように送信するかを示す補足的情報を、ヘッダ・フィールドから得ることができる。

【0051】

図５及びこの図についての以下の説明は、ヘッダの特定の指定場所に位置する、特定のサイズの、特定のフィールドについて説明するものであり、本発明の実施形態は、これら特定の実施に限定されるものではない。一部の実施形態では、ヘッダは、次のフィールドを含んでいる:

【0052】

移送プロトコル（ＲＴＰ）ヘッダ５０２。

【0053】

バージョン（Ｖ）５０４−該ヘッダの最初の２ビットがバージョン・フィールドを形成する。例えば、現在のＲＴＰバージョンは２である。

【0054】

調整（Ｐ）ビット５０６−ＲＴＰヘッダの第３のビットが、将来の使用のために保存される調整ビットであり、これは、０である。

【0055】

拡張（Ｘ）ビット５０８−ＲＴＰヘッダの第４のビットが、アプリケーション特有の拡張が共通ＲＴＰヘッダに付加されるかどうか示す。一例において、要約ヘッダは、各ＲＴＰパケットのペイロードにおける固定サイズのプロファイル拡張として送られることができる。この例においては、可変長さ及び可変位置のＲＴＰヘッダ拡張は使用されず、従ってこのビットは０である。

【0056】

寄与するソース数（ＣＣ）５１０−このフィールド（４ビットを含む）は符号のない整数として解釈される。それは、ＲＴＰヘッダに続くＲＴＰプロトコルによって定義される、寄与ソース数を表わしている。ネットワークが、寄与ソースのコンセプトをもっていない場合には、このフィールドは０である。

【0057】

マーカ（Ｍ）ビット５１２−ＲＴＰヘッダの第９のビットは、ストリーム・データ内での重要な出来事に関するマーカを表わす。該マーカ・ビットの解釈は、ＲＴＰペイロード内で送られるコンテンツのプロファイルに依存する。例えば、オーディオ／ビデオ・データについては、ソース資料を切り替えた場合、あるいはストリームの異なるポイントにジャンプしている場合のように、タイムスタンプが不連続である時には、このビットは１にセットされる。この値は、送信器によってダイナミックに生成される。

【0058】

ペイロード・タイプ５１４−この７ビットのフィールドは符号のない整数として解釈される。ペイロード・フィールドは、ペイロード・コンテンツの形式及びフォーマットを示す。ＲＦＣ３５５１では、RTPオーディオ/ビデオプロファイルに対するペイロード・タイプの値が定義される。いくつかの固定で周知の値が、共通のメディアコード化のフォーマットとして使用され、これは、ＲＴＰの開発当時から現存したものである。その後のバージョンにおけるＲＴＰ仕様では、９６から１２７までの値の範囲がペイロード・フォーマットのためにダイナミックに割り当てられるように予約されると規定している。特別のＲＴＰセッションのためにペイロード形式を協議し、ダイナミック・レンジからペイロード・タイプの値を割り当てるために、外部メカニズムやサイドチャンネルが使用されると予想される。一部の実施形態では、ネットワーク・プロトコルは、ダイナミック・レンジからのペイロード形式の静的割り当てを使用しており、したがって、この仕様は、サイドチャンネルを表わすものである。例えば、動的な値の範囲へのペイロード形式の割り当ては表１に概説されているようにすることができる。

【0059】

表１−セッション・マネージャー・イベント・コード値

【0060】

作動においては、受信側は、該受信側が理解しないペイロード形式を無視する。ペイロード形式の値は静的であり、メディア・コンテンツと共に保存される。

【0061】

シーケンス番号５１６−ネットワーク・バイトオーダにおけるこの１６ビットのフィールドは、符号のない整数として解釈される。このフィールドは、送信されたＲＴＰパケットのシーケンス番号を表わす。該フィールドは、メディアそれ自体の固有の順序にかかわらず、送られた各パケットごとに１だけ歩進される。従って、データ・ストリーム内でスキップ（前向きにジャンプするか巻き戻す場合のように）する場合、シーケンス番号は、各パケットごとに１だけ歩進されるので、ストリーム・データ・シーケンスが大きく変わることとなる。フィールドの初期値は任意であり、送信器によってダイナミックに生成されるようにすることができる。

【0062】

タイムスタンプの送信５１８−ネットワークのバイト順におけるこの３２ビットのフィールドは、符号のない整数として解釈される。このフィールドは、送信器の９０ｋＨｚの基準クロックに従って、パケットの第１のバイトが送信される時点を表わす。別の実施形態では、より高い精度を実現するために、２７ＭＨｚクロックといった異なるクロックを使用することができる。フィールドの初期値は任意である。受信側は、名目上のパケットレート及びストリーム帯域幅を決定し、プッシュ・モデルによってタイミングを回復するために、送信時のタイムスタンプ値を使用することができる。この値は、送信器によってダイナミックに生成される。一部の実施形態では、フィールドを置き換えることができるが、これは非標準のＲＴＰの履行を提供することになる。一部の実施形態では、タイムスタンプ・データを提供するために、フィールドにヘッダ拡張を付加することができる。

【0063】

同期ソース５２０−ネットワーク・バイトオーダにおけるこの３２ビットのフィールドは、メディアストリームのソースを表わす。一部の実施形態では、ネットワーク・プロトコルが、ペイロードのソースのＩＰアドレスを表わすＩＰｖ４ネットワーク・アドレスとしてこのフィールドを解釈する。この値は、送信器によってダイナミックに生成される。

【0064】

要約ヘッダ５２２：

【0065】

要約プロトコル・バージョン５２４、５２６−一部の実施形態では、要約プロトコルは、時間にわたって展開することができ、その結果、プロトコルの異なるバージョンを識別するためにフィールド（８ビットとして示される）を使用することができるようになる。一例においては、ビット０から３は、バージョンのマイナー番号を形成し、ビット４から７は、バージョンのメジャー番号を形成する。例えば、現在のメジャー番号は１であり、現在のマイナー番号は０（それらはバージョン１．０として解釈することができる）である。バージョン値は、送信器によってダイナミックに生成されるようにすることができる。

【0066】

モードフラグ５２８−フィールド（８ビットとして図中に示される）は、ストリーム配信に関連付けられた現在のモードに関する情報を表明するフラグのビットマップを表わす。例えば、特別のビット位置のうちの１の値は、関連するフラグに対する肯定的な値を示すことができ、その一方で、０の値は否定的な値を示すことができる。ある可能な履行では、このフィールドのためのビット割り当ては、テーブル２中で概説されるようにすることができる。モード・フラグ値は、送信器によってダイナミックに生成される。

【0067】

表２−ストリーム・モード・セッティングのためのフラグビット位置

【0068】

ブロック・サイズ５３０−ブロック・サイズ・フィールド（８ビットのフィールドとしてここに示される）は、符号のない整数として解釈される。このブロック・サイズ・フィールドは、ペイロードにおけるメディアデータのブロックのサイズを表わす。メディア・ストリームの受信機でバッファ管理を容易にするために、保存される必要のないセクションであるヌルデータを含むペイロードのセクションは、マークされる。このフィールドは、そのようなセクションのサイズを示す。例えば、ＭＰＥＧ移送ストリームは１８８バイトのセルに分解され、それらのうちの幾つかはヌルセルとしてマークされ、単に帯域幅パディングとして役立つようにすることができる。これらのセルを格納する必要はない。従って、ヌル・ブロック・サイズ・フィールドは、ＭＰＥＧ−ＴＳセルのサイズに固定され、それは１８８バイトである。この値は静的であり、メディア・コンテンツと共に保存される。

【0069】

ブロックカウント５３２−ブロック数フィールド（８ビットのフィールドとしてここに示される)は、符号のない整数として解釈される。それは、ペイロードにおけるメディアデータのブロックの数を表わす。各ブロックは、ブロック・サイズ・フィールド５３０のペイロードによって示されたサイズである。一例において、１パケットの中に１６以下のブロックがあることが要求される。ブロック数にブロック・サイズを掛けて、ヘッダ（ＲＴＰの１２バイト及び要約の８８バイト)のバイトを加えると、ペイロードの合計サイズを算出できる。この例においては、ペイロード・サイズ値は、１４７２バイトのようなＵＤＰのための最大値に制限される。一部の実施形態では、ブロックカウント値は静的で、メディア・コンテンツと共に保存される。

【0070】

コンテンツフラグ５３４−このフィールド（１６ビットのフィールドとして示される）は、ペイロード・コンテンツに関する情報を示すためのフラグのビットマップを表わす。特定ビット位置のうちの１値は、関連するフラグに対する肯定的な値を示し、０値は否定的な値を示している。このフィールドのためのビット割り当ては表３中に概説されたものすることができる。このフィールド値は、静的であり、メディア・コンテンツと共に保存される。

【0071】

表３−ストリームコンテンツ属性のフラグビット位置

【0072】

この例において、３つの指標データ・フィールドが、メディア・コンテンツ内のインデックスポイントの指示として役立つ。インデックスデータは比較的安定したランダムなアクセスポイントを作るメディアコンテンツの隣接する部分を意味しており、したがって、トリック・プレー・モードにおいて、ストリーム内でジャンプして互いに接合することができるメディアデータである。この説明図では、８つの可能な値があり、それらのうちの５つは独特のものである。すべての指標ビットに対する０の値は、内蔵の復号及びディスプレイに適していないもの、例えばＭＰＥＧ Ｂフレームのメディアデータを示す。他の４つの独特な値は、指標データのセクションの始まり、指標データのセクションの内部、指標データのセクションの終了、及び、指標データのセクションの終了を示すもので、その後に同じパケットにおける指標データの新しいセクションの始まりが続く。例えば、１つのＭＰＥＧ Ｉ−フレームの第１のバイトを含むパケットは、指標データの始まりを示しており、第１のビットに対する１の値、第２のビットに対する０あるいは１(かまわない)の値、及び第３のビットに対する０の値を持つものとなる。Ｉ−フレームデータを含む次のパケットは内部の指標データを示しており、第１のビット・セットに０を持ち、第２のビット・セットに１を持ち、第３のビット・セットに０を持つものとなる。Ｉ−フレームの最後のバイトを含むパケットは、指標セクションの終了を示しており、最初の２つのビット・セットに０を持ち、第３のビット・セットに１を持つものとなる。

【0073】

ヌル・ペイロード・ベクトル５３６−この説明図では、ヌル・ペイロード・ベクトル（１６ビットのフィールドとして示される）は、ヌル・データを含むペイロードのセクションがどれであるかを示すフラグのベクトルとして解釈される。各ビットはペイロード（そのサイズはブロック・サイズ・フィールド５３０によって示される）のブロックが、ヌル・データを含んでいるかどうかの指示を表わす。ビット０は、ペイロードの第１のブロックを表し、ビット１は次のブロックを表し、以下同様である。ビットが１に固定される場合、それはペイロードの対応するブロックが格納される必要のない無効のデータを含むことを示す。この例においては、フィールド値は静的で、メディア・コンテンツと共に保存される。

【0074】

この説明図では、空としてマークされたブロックは、受信側によって無視され、解釈されない。これは、ヌル・ブロックを格納せずに、コンテンツを暗号化し、バッファーすることができるからである。この場合、パケットは解読に先立って拡張されることになり、その後、それは、ヌル・ブロックのためのランダムデータを形成する。

【0075】

ディスプレイ・レート５３８−この説明図では、ネットワーク・バイトの順における表示速度（１６ビットのフィールドとして例証された）は、ストリームの表示速度を表わし、それは、解読レートに通常のストリームレートを乗じたもの、例えば通常速度の１．５倍である。一例では、レートは符号付きの固定小数点式の値として指定される。ビット８−１５は大きさを形成し、ビット０−７は断片的な構成要素を形成する。正の数は順方向を示すが、他方、負の数は反対の方向を示す。この例では、フィールド値は、１の通常の表示速度に適用される乗数を意味する。例えば、１６進数値０ｘ０１８０は、１の大きさの値及び０．５の小数部の値を表わし、それは、希望の表示速度が通常速度の１．５倍で順方向であることを示す。０ｘ０１００（つまり通常速度）以外のあらゆる値は、ストリームがトリック・プレー・モードであることを示し、受信側は、その解読ユニットと表示ユニットを対応する値だけ調節しなければならない。トリック・プレー・モードの変化は、このフィールドの値の変化によって示される。この例において、表示速度はダイナミックに生成される。

【0076】

フィールド５４０は、保存フィールドとして示されており、それは、将来他の目的に使用することができる。

【0077】

ストリームに対するタイムスタンプ５４２−このフィールド（３２ビットのフィールドとしてここに示される)は符号のない整数として解釈される。該フィールドは、ペイロード・コンテンツの第１バイトの到達時間を表す。二方向に予測されたビデオフレームが使用されるようなケースとして、例えばＭＰＥＧ Ｂフレームのような場合は、この値は単調に増加している必要はない。一つの実施では、タイムスタンプは、メディアコンテンツに関連付けられたストリーム・クロックに基づいて割り当てることができる。このフィールド値は、静的であり、メディア・コンテンツと共に保存される。このフィールドは、ストリーム・データにおけるバイト位置に対する時間オフセットを図にするために使用することができ、その後、それはストリームを通じて時間ベースのジャンプを可能にする。

【0078】

暗号カウンタ値５４４−このフィールド（６４ビットのフィールドとして示される）は、データ・ストリームの中でカプセル化されるメディア・コンテンツを暗号化するのに使用されるキーインデックス値の一部分を形成するカウンタ値を表わす。該フィールド値は、全ストリームに亘って独特のものであることが要求されており、その値は一定であり、ペイロード・コンテンツに関係付けられたままである。一部の実施形態では、この値は復号化と表示のためにメディア・コンテンツを解読するのに利用される。このフィールド値は静的であり、メディア・コンテンツと共に保存されている。

【0079】

ブロック・キャプチャ・タイムスタンプ・リスト５４６−５５０ − この実装においては、入口デバイスがメディアストリームを捕捉し、ネットワークを介してそれを配信するときに、表示装置の捕捉タイミングは、正確な復号化のために適切なタイミング回復が確実になるように再び生成される。ストリームが格納され、後で再生される場合、あるいは帯域幅を縮小するためにストリームの一部分が入口でドロップされる場合、例えば、高帯域幅のマルチ・プログラム移送ストリームを単一のプログラム移送ストリームにスケールダウンする場合のような場合には、この動作は特に重要である。

【0080】

一例では、ペイロードのそれぞれのストリームデータ・ブロックについて、入口デバイスにて９０ＫＨz基準クロックに従った捕捉タイムスタンプが要約ヘッダに付加される。この例においては、各タイムスタンプは３２ビット幅で、ネットワーク・バイトの順に送信される。示されるように、ヘッダは、許可されたブロックの最大数の捕捉タイムスタンプをパケット内に保持するために、１６スロットを含んでいる。このリストは、ペイロードにおける実際のブロックの数にかかわらず固定である。ペイロードにおけるブロックの数が１６より少ない場合には、受信側は未使用のタイムスタンプをすべて無視する。この実装では、ブロック捕捉タイムスタンプの値は静的であり、メディア・コンテンツと共に保存される。

【0081】

一部の実施形態では、データソースのストリーミング・アプリケーションは、意図したデータ受信側から、到着あるいはデータ脱落パケットに関する低レベルのフィード・バックを受け取ることができる。一部の実施形態では、このデータソースは、この低レベルのフィード・バックを使用して、エラー回復メカニズムを選ぶことができる。一部の実施形態では、低レベルのフィード・バックの使用は、システムがエンターテイメント・ネットワーク上に存在するネットワークデバイスを複雑にせずに、データ配信問題を処理することを可能にする。

【0082】

一部の実施形態では、低レベルのフィード・バックを行なうために要約ヘッダを使用することができるシーケンス番号を含んでいる。例えば、意図したデータ受信デバイスがシーケンス外パケットを検知するか、与えられたストリームのために期待された時間フレーム内に予期されたパケットを受け取らない場合には、受信デバイスは送信デバイスにフィード・バックとして否定応答（ＮＡＫ）を送信することができる。ＮＡＫのためのチャンネルは異なるものとすることができるし、また信頼できるプロトコルあるいは信頼性の低いプロトコル（ＵＤＰのような）のいずれかを利用することができる。ＮＡＫを受け取るとき、パケットがまだ利用可能な場合には、送信デバイスは再度そのパケットを送ることができる。一部の実施形態では、送信デバイスは、この目的のための再伝送バッファーをもつことができる。送信されたパケットは、それらの優先度(それは、要約ヘッダ・フラグによるパケット形式に基づくことができる)、及びそのような再送信が意味を持つ時間の長さに応じて、バッファーに格納することができる。特定のバッファー管理計画は、アプリケーションに応じて定められることになる。一部の実施形態では、パケットが到着するときに肯定的な認識（ＡＣＫ）が提供されるようにして、効率的な手法で再伝送バッファーから項目を立ち退かせるために使用することができる。しかしながら、肯定的な認識の提供には、フィード・バックのコスト増大を伴うことになる。

【0083】

一部の実施形態では、送信デバイスがＮＡＫを使用して、オーバロードの状態を示すものとなる、長期間のデータ渋滞を検知することができる。オーバロードの状態がこのように検知されると、送信デバイスは、渋滞を処理するためにストリームを帯域幅縮小バージョンに切り換えるように、適切な処置を講ずるか、あるいはストリームを完全に止めることができるが、それは、他の稼動中のストリームを高い品質の状態に維持することを可能にする。送信器は、例えばＴＣＰフレンドリーな速度制御（ＴＦＲＣ）のように、どんな既知の渋滞検出アルゴリズムも利用してもよい。

【0084】

図６は、ネットワーク内におけるストリーミング・データの移送プロセスの実施形態に関する説明図である。一部の実施形態では、要求は、最初のデバイスから第２のデバイス６０５までデータ・ストリームの配信のためになされる。この要求は、ネットワーク内で、第1のデバイスによって、あるいは別のデバイスによってなされることができ、それは例えば個人のエンターテイメント・ネットワークとすることができる。最初のデバイスは、ネットワーク６１０のためにストリーミング・データ・コンテンツを準備する。その過程は、各データ塊に、もった移送プロトコル・ヘッダと要約ヘッダを共に挿入することなどによって、コンテンツを要約することを含んでいる。この過程は、図７に記述された要素を含むことができる。その後、データ・パケットは、最初のデバイスから第２のデバイス６１５に送られる。

【0085】

一部の実施形態では、フィード・バックは、データの移送に関連して行うことができる。予期されたデータ・パケットが受信されない６２０か、乱れて受信された場合６２５に、否定応答（ＮＡＫ）６３０が、受信デバイスから第１のデバイスに送られる。データコンテンツ配信にとって適切な場合には、該第１のデバイスは、バッファー６３２から欠落したパケットを再び送ることができる。パケットが適切なシーケンス６２５を受信６２０した場合には、第２のデバイスは任意に第１のデバイスへ肯定認識（ＡＣＫ）を送ることができ、それによって第１のデバイスはバッファーから受信パケットを取り除くことができる。さらに、ＡＣＫの送信によって、最初のデバイスは、第２デバイスが事実としてデータ・ストリームを受け取り、ストリームのすべてのパケットに欠落がないと判断することができる。受信パケットにとって、第２のデバイスがデータのユーザ（かつ中間のデバイスではない）６４０である場合、該デバイスは、データ・パケットを解読し、かつ復号化することができる。第２のデバイスがデータのユーザでない場合には、パケットは解読又は復号化なし６５０で、通過させられる。いずれの場合にも、その後、データを表示するか将来の使用に備えてデータを蓄えるといった、意図した作動が、データ・パケット６５５について行なわれる。

【0086】

図７はストリーミング・データを要約する方法の実施形態の説明図である。一部の実施形態では、データ・ストリームは、要約情報７００を得るために、少なくとも一部が解読及び復号化されるようにすることができる。該データ・ストリームは、移送プロトコルによって求められるデータ塊に分割７０５される。要約ヘッダのための情報が、データ塊のために決定される。この方法は、暗号化、帯域幅予約、渋滞、トリック・プレー使用、接合及び他のモード７１５を含むオペレーションのモードを決定することを含むことができる。このプロセスは、更にヌル・ブロック・サイズ及びヌル・ブロックの場所の判定７２０を含むことができる。コンテンツ情報が求められ７２５るが、このコンテンツ情報は、指標データ、オーディオ・データ、イメージ・データ、キーフレームを備えた、あるいはキーフレームのないビデオ・データ、接合データ、グラフィックス、メタデータ、暗号手法、及び他のコンテンツ情報の存在を含むことができる。データが暗号化されている場合７３０に、シーケンス番号を提供するために、暗号カウンタ値を含むことができ、データのためにストリーム関連タイムスタンプを確立することができる。要約情報を確立したまま、移送プロトコル・ヘッダ及び要約ヘッダを各データ・チャックに付けること７４０ができ、また、図６において行われたように、データを移送することができる。

【0087】

図８は、ネットワークデバイスの実施形態の説明図である。この説明図では、ネットワークデバイス８０５は、例えばエンターテイメント・ネットワークのようなネットワークにおける如何なるデバイスであってもよく、図１に示した各デバイスを含むことができるが、これに限定されるものではない。例えば、ネットワークデバイスは、テレビ、セットトップ・ボックス、記憶ユニット、ゲーム・コンソールその他のメディアデバイスとすることができる。一部の実施形態では、ネットワークデバイス８０５は、ネットワーク機能を提供するために形成されたネットワーク・ユニット８１０を含むことができる。このネットワーク機能は、メディアデータ・ストリームの生成、伝送、格納及び受け取りを含むが、しかし、これらに制限されない。ネットワーク・ユニット９１０は、埋め込み型システムとして実装することができる。ネットワーク・ユニット８１０は、チップ上の単一システム（ＳｏＣ：システム・オン・ア・チップ）として、あるいは複数のコンポーネントとして実装することができる。

【0088】

一部の実施形態では、ネットワーク・ユニット８１０は、データ処理プロセッサを含んでいる。データ処理は、データ・ストリームの生成、データ・ストリームの移送[e-mail]又は格納のための動作、用途に応じたデータ・ストリームの解読及び復号化を含むことができる。ネットワークデバイスは又、ＤＲＡＭ（ダイナミック・ランダム・アクセス・メモリ）８２０あるいは他の同様のメモリ及びフラッシュ・メモリ８２５あるいは他の不揮発性メモリーのような、ネットワーク・オペレーションをサポートするメモリを含むことができる。

【0089】

ネットワークデバイス８０５は、さらに、送信器８３０、及び／又は受信器８４０をそれぞれ含むことができ、これらは、ネットワークインターフェイス８５５によって、それぞれネットワークへのデータの送信あるいはネットワークからのデータの受信を行う。送信器８３０又は受信器８４０は、例えばイーサネット・ケーブル８５０を含む有線の伝送ケーブル、あるいは無線ユニットに接続することができる。有線の伝送ケーブルは、さらにデータ伝送のために使用できる同軸ケーブル、電力線あるいは他のケーブルあるいはワイヤを含むことができる。送信器８３０又は受信器８４０は、例えばデータ送信用ライン８３５又はデータ受信用ライン８４５のような１あるいはそれ以上のラインにより、データ伝送及び制御信号のためにネットワーク・ユニット８１０と結合することができる。追加の接続をさらに設けることができる。ネットワークデバイス８０５は、さらに、ここで示されないデバイスのメディアオペレーションのために、多数のコンポーネントを含むことができる。

【0090】

上記の説明では、説明の目的のために、本発明の完全な理解を提供するために、多くの具体的な詳細が述べられている。しかしながら、当業者にとって、これら具体的な詳細のうちのいくつかを省いても、本発明を実施できることは明らかであろう。他の例においては、既知の構造及びデバイスがブロック図の形で示されている。図示されたコンポーネントの間に中間の構造をもつようにすることができる。ここに記載され、或いは示されたコンポーネントは、図示されず、或いは説明されなかった追加の入力又は出力を持つことができる。図示された要素又はコンポーネントもまた、任意のフィールドの再整理あるいはフィールド・サイズの修正を含む、異なる配置あるいは順序で配列することができる。

【0091】

本発明は、様々な方法を含むことができる。本発明の方法はハードウェア・コンポーネントによって行なうことができるし、或いは、マシン実行可能な命令として具体化することができる。そして、それらは、その方法を遂行する命令によりプログラムされた汎用プロセッサ、又は特殊目的プロセッサ、或いはその命令をプログラム化した論理回路を形成するのに用いることができる。代替的に、その方法はハードウェアとソフトウェアの組合せによって行なうことができる。

【0092】

本発明の各部分は、計算機プログラム製品として提供することができる。その製品は、計算機プログラム命令を格納したコンピュータ読み取り可能な媒体を含むものとすることができ、それらは、本発明による方法を実行できるようにコンピュータ(あるいは他の電子機器)をプログラムするために使用することができる。マシン読み取り可能な媒体としては、フロッピー・ディスク、光ディスクＣＤ−ＲＯＭ（コンパクト・ディスクを使った読み出し専用メモリー）及び光磁気ディスク、ＲＯＭ（読み出し専用メモリー）及びＲＡＭ（ランダム・アクセス・メモリー）、並びに、ＥＰＲＯＭ（消去可能なプログラマブル読み出し専用メモリー）及びＥＥＰＲＯＭ（電子消去可能なプログラマブル読み出し専用メモリー）、磁石、あるいは光カード、フラッシュ・メモリ、あるいは他のタイプのメディア/電子命令を格納するのにふさわしいマシン読み取り可能な媒体を含むことができるが、これに制限されるものではない。さらに、本発明はまた、計算機プログラム製品としてダウンロードされるようにすることができ、そこでは、プログラムは遠隔コンピュータから要求するコンピュータまで伝送されるようにすることができる。

【0093】

この方法の多くは、その最も基本的なフォームで記述されるが、本発明の基本的な範囲から逸脱することなく、この方法に別の方法を付加したり、この方法のいずれかから削除したりすることができ、記述されたメッセージのいずれに対しても、情報を加えたり、削除したりすることができる。多くの更なる修正及び適応が可能なことは、当業者にとって明らかであろう。
特定の実施形態は、本発明を制限するものではなく、それを例示するために提供されているものである。本発明の範囲は、上記した特定の例によって決定されるべきではなく、以下の特許請求の範囲によってのみ決定される。

【0094】

要素「Ａ」が要素「Ｂ」と結合される、と言われる場合には、要素Ａは、直接要素Ｂと結合されるか、又は間接的に例えば要素Ｃを介して結合されるものである。本明細書又は特許請求の範囲が、コンポーネント、特徴、構造、プロセス、又は特性Ａが、コンポーネント、特徴、構造、プロセス、又は特性Ｂに「させる」と述べるとき、それは、「Ａ」が少なくとも部分的に「Ｂ」の原因であるが、「Ｂ」の原因となるのを助ける他の少なくとも１つのコンポーネント、特徴、構造、プロセス、又は特性が存在することができることを意味する。もし明細書が、コンポーネント、特徴、構造、プロセス、或いは特性が、「〜と言うことができる」、「かもしれない」、又は「できる」が含まれている表現を用いる場合には、その特定のコンポーネント、特徴、構造、プロセス、又は特性は、含まれている必要はない。もし明細書又は特許請求の範囲が「a」か「an」の要素を示す場合には、これは、説明された要素が１つしかないことを意味するものではない。

【0095】

実施形態は、発明の実装か実例である。明細書における「実施形態」、「１つの実施形態」、「一部の実施形態」あるいは「他の実施形態」についての言及は、具体的な特徴、構造又は実施形態に関して説明された特性が、少なくとも一部の実施形態に含まれることを意味するが、しかし必ずしもすべての実施形態に必要ではない。「実施形態」、「１つの実施形態」又は「一部の実施形態」が種々の形で使用されている場合には。これらは、必ずしも、同じ実施形態のすべてに言及するとは限らない。本発明の例示的な実施例についての前述の説明では、開示を合理化し、様々な創造性のある側面の１つ又はそれ以上についての理解を助ける目的で、単一の実施形態、図又はその説明の中で、発明の様々な特徴が時には一まとめにされている。しかし、この開示方法は、特許請求の範囲に記載された発明が、各請求項において明示的に記載されたものより多くの特徴を必要とする意図を反映するものと解釈されるべきではない。むしろ、以下の請求項が反映するように、発明としての側面は、単一の先に開示された実施形態のすべての特徴より少ないものを要件取り付けする。従って、その請求項は、ここに明示的にこの記載の中に組み入れられており、各請求項は、本発明の個別の形態として自立するものである。

【符号の説明】

【0096】

１００ エンターテイメント・ネットワーク・システム
１０５ エンターテイメント・ネットワーク
１１０ オフィス
１１２ 寝室
１１４ リビングルーム
１１６ 台所
１２０ インターネット
１２２ ゲートウェイ
１２４ パーソナルコンピュータ
１２６ モニタ
１２８ メディア記憶ユニット
１３０ セットトップ・ボックス
１３２ テレビ
１３４ ケーブル又は光ケーブルシステム
１３６ 衛星放送受信アンテナネットワーク
１３８ セットトップ・ボックス
１４０ 第２テレビ
１４２ ビデオゲーム・ユニット
１４４ 第３テレビ
１４６ デジタル・カメラ
１４８ 携帯電話
１５０ 個人的な音楽デバイス
１５２ ビデオカメラ
１５４ 自動車
２０５ デバイス１
２１０ ネットワーク・インターフェース
２１５ デバイス２
２２０ ネットワーク・インターフェース
２２５ データ・ストリーム
２３０ データ要約フォーマット
２３５ 低レベルフィード・バック
３０５ 原データ
３１０ データ
３１５ データ塊（チャンク）
３２０ ヘッダ
３２５ データ
３３０ トランスポート・プロトコル・ヘッダ
３３５ 要約ヘッダ
４０５ サイズ
４１０ モード・フラッグ
４１５ ゼロ・データのサイズと位置
４２０ コンテンツ・フラッグ
４２５ 暗号カウンタ
４３０ タイムスタンプ
４３５ その他
５０２ トランスポート・プロトコル・（ＲＴＰ）・ヘッダ
５０４ バージョン （Ｖ）
５０６ パディング （Ｐ） ビット
５０８ 拡張 （Ｘ） ビット
５１０ ソース・カウント（ＣＣ）
５１２ マーカ （Ｍ） ビット
５１４ ペイロード・タイプ
５１６ シーケンス・ナンバー
５１８ Ｔｘタイムスタンプ
５２０ シンクロナイゼーション・ソース
５２２ 要約ヘッダ
５２４ マイナー
５２６ メジャー
５２８ モード・フラッグ
５３０ ブロック・サイズ
５３２ ブロック・カウント
５３４ コンテンツ・フラッグ
５３６ ゼロ・ペイロード・ベクトル
５３８ ディスプレイ・レート
５４０ フィールド
５４２ ストリームの相対的タイムスタンプ
５４４ 暗号カウンタ値−６４ｂｉｔ
５４６ ブロック０ タイムスタンプの取得
５４８ ブロック１ タイムスタンプの取得
５５０ ブロック１５ タイムスタンプの取得
６０５ 第２デバイス
６１０ 個人のエンターテイメント・ネットワーク
６１５ 第２デバイス
６２０ パケットを受け取ったかどうか？
６２５ シーケンス内のパケットかどうか？
６３０ ＮＡＫ
６３２ バッファ
６３５ ＡＣＫ
６４５ データパケット
６５０ 復号化
６５５ データ・パケット
７００ 要約情報
７０５ トランスポート・プロトコル
７１０ 要約ヘッダ
７１５ 他のモード
７２０ ヌル・ブロック
７２５ コンテンツ情報
７３０ 暗号化
７３５ タイムスタンプ
７４０ データ塊
８０５ ネットワーク・デバイス
８１０ ネットワーク・ユニット
８１５ プロセッサ
８２０ ＤＲＡＭ
８２５ フラッシュ・メモリ
８３０ Ｔｘ
８４０ Ｒｘ
８５０ イーサネット

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図1】