(57)【特許請求の範囲】
【請求項１】
ビットストリームの表現を含むファイルの検索を容易にする方法であって、
前記ビットストリームからのデータを検索及び抽出するのに利用される少なくとも１つのレコードであって、前記ビットストリームの表現を含むファイルにおける各データオフセットを前記ビットストリームにおける対応するタイムオフセットにマッピングする少なくとも１つのレコードを有するテーブルを生成するステップと、
前記テーブルを使用して前記ビットストリームの表現における所望のデータ部分を特定するステップと、
少なくとも１つのさらなるレコードからの条件付アクセス情報を利用して前記ビットストリームの表現における前記所望のデータ部分を復号化するステップと、
を有し、
前記テーブルの少なくとも１つのレコードは、前記ビットストリームに含まれる少なくとも１つのオーディオビジュアルプログラムへのアクセスを制御するのに利用される少なくとも１つのテレビ制御コマンドと条件付アクセス情報とを有する少なくとも１つのさらなるレコードにマッピングされ、
前記ビットストリームと前記条件付アクセス情報とは、前記ビットストリームと前記条件付アクセス情報との格納時に同期され、
前記ビットストリームは、ビットストリームデータの他の部分とは独立にオーディオビジュアルデータ部分を再生成するのに利用される少なくとも１つのキーフレームと、前記キーフレームにより表現される前記オーディオビジュアルデータ部分からの変化を前記ビットストリームデータにマッピングするため構成される少なくとも１つのデルタフレームとを有する方法。
【請求項２】
前記テーブルは、前記ビットストリームの表現の前記ファイルへの記録中に自動生成される、請求項１記載の方法。
【請求項３】
前記少なくとも１つのさらなるレコードは、さらなるテーブルに格納される、請求項１記載の方法。
【請求項４】
前記少なくとも１つのさらなるレコードは、ユーザのコマンドにより挿入される、請求項３記載の方法。
【請求項５】
前記テーブルにおける少なくとも１つのレコードは、ユーザのコマンドにより前記少なくとも１つのさらなるレコードにマッピングされる、請求項１記載の方法。
【請求項６】
前記ファイルは、符号化され、
前記少なくとも１つのレコードは、前記符号化されたファイルにおけるデータオフセットを前記ビットストリームにおける対応するタイムオフセットにマッピングする、請求項１記載の方法。
【請求項７】
前記ビットストリームの特性に応じて、少なくとも１つのレコードが挿入される、請求項１記載の方法。
【請求項８】
ユーザのコマンドにより、少なくとも１つのレコードが挿入される、請求項１記載の方法。
【請求項９】
少なくとも１つのレコードが、自動挿入される、請求項１記載の方法。
【請求項１０】
前記ビットストリームの表現を含むファイルに前記テーブルを格納するステップをさらに有する、請求項１記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ビットストリーム、特に音声及び／または視覚（視聴覚）ビットストリームのレコーディング、処理、記憶、及びプレイバックに関する。３つの全般的な態様が説明される。
【０００２】
第1に、このように記録されたビットストリーム中の点の指標付けが、特に特定的な点の編集に関して、及びこのような記録されたビットストリームの動作の性能における規則正しく間隔をあけて配置される位置決め点の使用に関して説明される。
【０００３】
第２に、このような記録されたビットストリームに関する条件付きアクセス情報の同期が説明される。
【０００４】
第３に、このような記録されたビットストリームでの動作の制御のためのコマンドセットが説明される。
【０００５】
本発明は、ファイルの探索を容易にする方法、ファイルを探索する方法、テーブル、ビットストリームの表現及びテーブルを備えるファイル、記憶手段、ハードディスクビデオレコーダ、受信機／デコーダ、及び放送システムに係わる。
【０００６】
発明は、記録されたビットストリーム、特に可変ビット・レートビットストリーム、及び特に受信機／デコーダの制御下で記録される番組からのデータの定位及び検索に、特定的にではあるが、排他的にではなく応用される。
【０００７】
データのこのようなレコーディング及び検索は、特に、内容がここに参照して組み込まれているＣａｎａｌ＋  Ｔｅｃｈｎｏｌｏｇｉｅｓ  Ｓｏｃｉｅｔｅ  Ａｎｏｎｙｍｅの名のもとに国際特許出願番号第ＰＣＴ／ＩＢ０１／０１８４５号に説明されている。
【０００８】
本発明は、ビットストリーム中の位置を評価するための装置、ビットストリームを操作するための装置、ビットストリーム中の位置を評価する方法、ビットストリームを操作する方法、受信機／デコーダ、このような装置を組み込む放送システム、コンピュータプログラム製品、コンピュータ読み取り可能媒体、及び前記コンピュータプログラム製品を具現する信号にも係わる。
【０００９】
発明は、デジタルビットストリームの処理に、特定的にではあるが、排他的にではなく応用される。本発明は、ビットストリーム操作の記録段階でさらに特定的に使用される。
【００１０】
発明は、音声／視覚ビットストリームの転送を制御するためのコマンド、このようなコマンドを組み込むコマンドセット、オペレーティングシステム、受信機／デコーダ、コンピュータプログラム製品、コンピュータ読み取り可能媒体、このようなコンピュータプログラム製品を具体的に具現する信号、音声／画像データを処理するための装置、音声／視覚処理装置、放送システム、及び音声／視覚ビットストリームの再生を制御する方法にも係わる。
【００１１】
発明は、デジタルテレビ用の受信機／デコーダ内の機能性を提供することに、特定的にではあるが、排他的にではなく応用される。
【００１２】
デジタルテレビシステムは、アナログ形式よりむしろデジタル形式での視聴者にテレビジョンチャネルを伝送する。デジタルチャネルは、送信機終端でデジタルデータストリームに符号化され、デジタル受信機／デコーダを使用して受信機終端で復号される。対話性を可能とするために、テレビジョンチャネルを送達する同じ媒体、あるいは電話リンクなどの別の媒体のどちらかを介してアップリンクが提供されてよい。デジタル音声、ソフトウェアデータ及び対話型データなどの追加の種類のデータが一斉送信できる、あるいは一斉送信もされている。ここに使用されるように、用語「デジタルテレビシステム」は、例えば、任意の衛星システム、地上システム、ケーブルシステム及び他のシステムを含む。
【００１３】
ここに使用されるような用語「受信機／デコーダ」は、好ましくはＭＰＥＧフォーマットで、なんらかの他の手段により一斉送信または伝送されてよい、テレビ信号及び／または無線信号などの、符号化済みの、または符号化されていないかのどちらかの信号を受信するための受信機を意味してよい。用語は、受信された信号を復号するためのデコーダも意味してよい。このような受信機／デコーダの実施形態は、例えば、物理的に別個の受信機と組み合わされて機能するデコーダ、またはウェブブラウザ、ビデオレコーダまたはテレビなどの追加機能を含むこのようなデコーダなどの「セットトップボックス」で、受信された信号を復号するための、受信機と一体化されたデコーダを含んでよい。
【００１４】
用語ＭＰＥＧは、国際標準化機構作業グループ「エムペグ（動画専門家グループ）」により開発されたデータ伝送規格、及び特にではあるが、排他的にではなく、デジタルテレビ用途向けに開発され、文書ＩＳＯ  １３８１８−１、ＩＳＯ１３８１８−２、ＩＳＯ  １３８１８−３及びＩＳＯ  １３８１８−４に述べられているＭＰＥＧ−２規格を指す。本特許出願の文脈においては、用語は、デジタルデータ伝送の分野に適用できるＭＰＥＧフォーマットのすべての変形、修正または展開したものを含む。
【００１５】
【従来の技術】
可変ビット・レートビットストリームなどのビットストリームの表現を含むファイルの生成、記憶、伝送及び処理は、デジタル技術の分野では周知である。しかしながら、例えば、関連付けられたビットストリーム中の特定のタイムオフセットに対応する、このようなファイルの所望される部分の位置を、特にこのようなファイルを復号または復元しないで突き止めることは困難且つ非効率である場合がある。
【００１６】
既知のシステムでは、例えば、ビットストリーム中のある特定のタイムオフセットに対応するデータを求めてファイルを探索することは、一般的には、ビットストリームが一定のビットレートを有すると仮定することによって反復して行われる。ビットストリームが一定のビットレートを有するという仮定は概してやや粗雑であり、このような方法でのファイルの検索は時間がかかり、非効率的であり、実際には、ファイルまたは関連付けられるビットストリーム中の指定された点の場所に依存するプロセスを不可能に、あるいは困難且つ非効率にすることがある。このようなプロセスは、例えば、ファイル内の点を早送り、巻き戻し、読み飛ばし、ブックマークを付けること、ファイルの部分に対するアクセスを制御するか、あるいはファイルまたはビットストリームの特徴をタイムオフセットまたはデータオフセットの関数として分析することであってよい。
【００１７】
ＤＶＤは、章の始まりに相当するＤＶＤファイル中の点に対応するデータオフセットを含む別々のファイルを含むことがある。しかしながら、通常、ＤＶＤファイルの中には限られた数の章、その結果限られた数の基準点があり、このような基準点は、一般的にはタイムオフセットのマッピングを対象にしていない。このようなデータオフセットファイルは、章の始まり以外、ファイル内での特定の点の検索にはほとんど役立たない。
【００１８】
【発明が解決しようとする課題】
本発明は、前記従来の技術が遭遇した問題点を改善しようとしている。
【００１９】
したがって、ビットストリームの表現を含むファイル内のそれぞれのデータオフセットを、ビットストリーム中の対応するタイムオフセットにマッピングする少なくとも１つのレコードを備えるテーブルが提供される。
【００２０】
このようにして、ビットストリーム中のある特定のタイムオフセットに対応するファイル内のデータは、迅速に且つ効率的にアクセスされてよい。
【００２１】
【課題を解決するための手段】
ここに使用されるように、用語「ビットストリーム」は、好ましくは、例えば、時間的に配列される一連のビットを備えるデータを意味する。用語ビットストリームは、用語データストリームと交替に使用される。ビットストリームは、音声／画像データを備えてよい、またはこのような音声／画像データを表現してよい、あるいはそれはテレテキスト情報、字幕、その他の種類のテキスト情報、数値情報、またはコンピュータプログラムを含むコンピュータデータを備えてよい、または表してよい。
【００２２】
デジタルテレビ伝送及び衛星テレビ伝送は、一般的には、音声／画像データまたはこのようなデータの表現を備える少なくとも１つのビットストリームを備える。しかしながら、コンピュータデバイス、プロセッサ、Ａ／Ｄ変換器、テレビ、ＨＤＶＲ、あるいはハードディスク、テープ、コンピュータ記憶装置、ＣＤ、またはＤＶＤなどの記憶装置などのデジタルデバイスの中、あるいは間で伝送されるデータは、ビットストリーム、またはビットストリームの表現を備えてよい。
【００２３】
タイムオフセットは、例えばビットストリームの始まりなどの定められた点からのビットストリーム中のある特定の点の時間でのオフセットであってよい。ファイル内のデータオフセットは、例えば、ファイルの始まりなどの定められた位置に関するメモリ内の位置であってよい。ビットストリームがメモリ内の一連のビットを備えるファイルとして記憶される場合には、データオフセットは、例えば、ファイルの始まりからのビット数であってよい。
【００２４】
ここで使用されるように、用語「テーブル」は、好ましくは、少なくとも１つのデータポイントを備えるデータを意味する。テーブルは、このような少なくとも１つのデータポイントを同種または異種の他のデータポイントに、直接的または間接的にマッピングしてよい。テーブルは、データベース、スプレッドシート、または例えば、ハードディスク、フロッピーディスク、ＣＤ、ＤＶＤ、または光記憶装置などの例えば電子データ記憶装置内に記憶されるファイル、あるいは例えばプリントアウトなどの非電子記憶装置の形を取ってよい。ここに使用されるような用語「テーブル」は、このような１つまたは複数のデータポイントを生成するためのアルゴリズムまたはプロセスも意味してよい。
【００２５】
好ましくは、テーブルは、ビットストリームの表現を含むファイル内のそれぞれ少なくとも１つのデータオフセットを表す少なくとも１つのデータポイント、及びビットストリーム内の対応する少なくとも１つのタイムオフセットを表す少なくとも１つのデータポイントを備える。このようにして、テーブルは、それぞれのデータオフセットを対応するタイムオフセットに直接的にマッピングしてよく、該それぞれのデータオフセット及び／または該対応するタイムオフセットの値は迅速に且つ効率的に得られてよい。
【００２６】
代わりに、テーブルは、ビットストリームの表現を含むファイル内のそれぞれ少なくとも１つのデータオフセットを表す少なくとも１つのデータポイントを備えてよく、テーブルは、該それぞれの少なくとも１つのデータオフセットを、追加のテーブル内のエントリにマッピングしてよく、該追加テーブル内のこのエントリは、該ビットストリーム中の対応する少なくとも１つのタイムオフセットであってよい、あるいは該ビットストリーム中の対応する少なくとも１つのタイムオフセットにマッピングしてよい。
【００２７】
代わりに、テーブルは、ビットストリーム中のそれぞれの少なくとも１つのタイムオフセットを表す少なくとも１つのデータポイントを備えてよく、テーブルは、該それぞれの少なくとも１つのタイムオフセットを追加のテーブル内のエントリにマッピングしてよく、該追加テーブル内のこのエントリは、ビットストリームの表現を含むファイル内の対応する少なくとも１つのデータオフセットであってよい、あるいはビットストリームの表現を含むファイル内の対応する少なくとも１つのデータオフセットにマッピングしてよい。
【００２８】
特に、音声／画像データは、1つのフレームまたは一連のフレームを表すビットストリームの形を取ってよい。このようなビットストリームは、このようなフレーム内のピクセルまたは点を表す一連のビットを備えてよい。フィルムまたは動画のその他のシーケンスは一連のコマを備えてよく、各コマが別の画像を表してよい。関連付けられる音声情報、及び条件付アクセスまたは権利付与情報などの事実上他の情報もこのようなビットストリームに含まれてよい。
【００２９】
好ましくは、該少なくとも１つのそれぞれのデータオフセット及び／または該少なくとも１つのそれぞれのタイムオフセットの値は、ビットストリームの特徴及び／またはビットストリームの表現に従って選ばれる。
【００３０】
好ましくは、ビットストリームは、可変ビット・レートビットストリームである。
【００３１】
このようにして、ビットストリーム内のある特定のタイムオフセットに対応するファイル内のデータは、たとえファイル全体でのデータオフセットとビットストリーム全体でのタイムオフセットの間に直線関係がないにしても迅速に、且つ効率的にアクセスされてよい。
【００３２】
ここに使用されるように、用語「可変ビット・レートビットストリーム」は、好ましくは、時間または場所などのパラメータとともに変化してよく、パラメータの特定の値または値の範囲でのデータのある部分を表すビットの数が、該パラメータの別の値または値の範囲でのデータの別の部分を表すビット数に対して異なってよいデータを表す一連のビットを備えるビットストリームを意味する。
【００３３】
したがって、例えば、ビットストリームが画像コマを表す一連のビットを備え、この画像のある部分、例えば前景オブジェクトを表すために必要とされるビット数が該画像の別の部分、例えば無地の背景を表すために必要とされるビット数より多い場合には、ビットストリームは可変ビット・レートビットストリームであってよく、該ビットストリーム中の、つまりこのようなビットストリームの表現を含むファイル内のデータオフセットは、該画像コマ自体の空間オフセットとともに線形に変化しない可能性がある。
【００３４】
例えば、時間的に配列された一連のビットを備えるビットストリームにおいて、ビットレートは、該ビットストリーム中の単位時間あたりのビット数であってよく、及び可変ビット・レートビットストリームは、単位時間あたりのビット数がタイムオフセットとともに変化してよいビットストリームであってよい。
【００３５】
ビットストリームが、一連の周期的に間隔をあけて配置される時間変化する画像コマ、例えばフィルムを表す一連のビットを備え、あるコマを表すために必要なビットの数が別のコマを表すために必要なビット数未満である場合には、ビットストリームは可変ビット・レートビットストリームであってよく、ビットストリームの表現を含むファイル内のデータオフセットは、ビットストリーム中、つまりフィルム自体の中のタイムオフセットとともに線形に変化しない可能性がある。
【００３６】
このような可変ビット・レートビットストリームは、ＨＤＶＲ、あるいは実際には、セットトップボックスに含まれるか、セットトップボックスと関連付けられる任意のビデオデバイスまたは音声デバイス、あるいはコンピュータ、プロセッサ、またはハードディスクなどの大量記憶装置、つまりＤＶＤに伝送されるか、それに記憶されるか、あるいはそれによって生成されるデータなどの圧縮された、または符号化されたデジタルデータ（またはこのようなデータの表現）を備えてよい。このような可変ビット・レートビットストリームは、ＤＶＢ−ＣＳ、ＤＥＳ、３ＤＥＳを含むさまざまな暗号化または符号化アルゴリズムによって保護されているＭＰＥＧ−２、ＭＰＥＧ−４、ＭＰ３を含む多岐に渡る圧縮フォーマットのデータを含み、画像及びまたは音声データ、テレテキスト情報、字幕、他の種類のテキスト情報、スーパーインポーズデータ、コンピュータデータ、またはこのようなデータの表現を含んでよい。
【００３７】
ここに使用されるように、用語「暗号にする」、「符号化する」、及び「暗号化する」は、好ましくは交互に使用されると理解されなければならない。同様に、用語「解読する」、「復号する」及び「平文に直す」は、好ましくは交互に使用されると理解されなければならない。
【００３８】
事実上、前述されたものを含む、すべてではないが、多くの業界規格の圧縮または暗号化フォーマットのデータを含むビットストリームは、元来、可変速度サービスを有してよい。
【００３９】
例えば、多くの圧縮フォーマットは、時間帯ごとに独立したデータセットを生成するよりむしろ、ある時間帯から別の時間帯へ基準データに変化をマッピングする技法を使用する。特に、ＭＰＥＧデータは、ビットストリーム中のデータの他の部分とは無関係に、例えば映画の中の1コマなどの、データ、特に視聴覚データの一部分を生成し直すために使用できるキーフレーム、及び関連付けられるキーフレームから変化をマッピングするデルタフレームを含む。ビットストリーム中のキーフレームと関連付けられるビットレートは、通常、デルタフレームと関連付けられるビットレートより速くなるだろう。
【００４０】
ここに使用されるような用語「キーフレーム」は、好ましくは、データの他の部分と無関係に、データのそれぞれの追加部分を再生するために独立して使用できるデータのある部分を意味する。一般的には、データの該それぞれの追加部分は視聴覚データであり、キーフレームは一般的にはビットストリーム中に含まれてよい。
【００４１】
キーフレームは、例えば、映画の中のある特定の場面など、画面上に表示するためにイメージデータを生成し直すために独立して使用されてよい。
【００４２】
用語「キーフレーム」は、ここに使用されるように、好ましくは、データの別の部分に従って、データのそれぞれの追加部分を生成し直すために使用できるデータの部分を意味する用語「デルタフレーム」と対照されてよい。一般的には、データの前記別の部分はキーフレームであり、デルタフレームがこのキーフレームから変化をマッピングする。
【００４３】
例えば、映画は、画面上に連続して表示される一連のイメージを備えてよい。１つのイメージを表すデータはキーフレームの形を取ってよく、該イメージはデータの他の部分とは無関係に該キーフレームから生成し直されてよい。
【００４４】
その後のイメージを表すデータはデルタフレームの形を取ってよく、これらのイメージは、キーフレームに従って該デルタフレームから生成し直されてよい。一般的には、デルタフレームは、キーフレームデータによって表されるイメージから、イメージ内の変化をマッピングするだろう。ビットストリームは、先行するキーフレームから変化をマッピングする一連のデルタフレームと時間内にインタリーブされる一連のキーフレームを備えてよい。
【００４５】
ＭＰＥＧ−２プロトコルの元では、ビデオデータは、両方とも前記のこの用語の使用に従ってデルタフレームとして分類できるフレーム間（ｉｎｔｅｒｆｒａｍｅｓ）（Ｐフレーム）及び双方向フレーム（Ｂフレーム）とインタリーブされるフレーム内（ｉｎｔｒａｆｒａｍｅｓ）（Ｉフレーム）として知られる一連のキーフレームを備える。フレーム間（Ｐフレーム）は先行するフレームから変化をマッピングするが、Ｂフレームは先行するフレームと続くフレームのどちらかまたは両方から変化をマッピングする。Ｐフレーム及びＢフレームのＩフレームとのインタリーブは、エンコーダに依存し、定期的である必要はない。
【００４６】
ファイルが符号化される場合に、好ましくは該少なくとも１つのレコードが、符号化されたファイル内のデータオフセットをビットストリーム中の対応するタイムオフセットにマッピングする。
【００４７】
したがって、ある特定のタイムオフセットでのデータ、つまり対応するデータオフセットを求めるファイルの探索は、該ファイルを復号する必要なく可能にされ、このようにして機密保護手段を維持し、データに対するアクセスの効率を高める。
【００４８】
このような符号化されたファイルは、例えばＭＰＥＧ−２及びＤＶＢ−ＣＳまたはＭＰ３及び３ＤＥＳなどの、例えば圧縮プロセスと暗号化プロセスの任意の組み合わせの対象となるファイルを含んでよい。
【００４９】
好ましくは、テーブルは少なくとも３つのレコードを備え、タイムオフセットは周期的である。
【００５０】
したがって、ビットストリーム中に時間で周期的に間隔をあけて配置される点は、迅速に且つ効率的にアクセスされてよく、読み飛ばし、早送り、及び巻き戻しなどの時間に依存するプロセスの迅速で円滑、及び効率的な動作を可能にする。
【００５１】
周期的なタイムオフセットは、章などのビットストリームの特定な部分に、あるいは少なくとも１つの期間があるビットストリーム全体を通して位置してよい。
【００５２】
好ましくは、タイムオフセットの期間は変えられる。したがって、検索、早送り、巻き戻し、または読み飛ばしなどのプロセスの速度は変えられてよい。
【００５３】
期間は、ビットストリーム、つまりビットストリームの部分を通して変わってよく、時間につれて変わってよい。周期性はユーザによって変えられてよいか、あるいは例えばユーザの動作に、またはビットストリームの特性に、またはビットストリームで表される視聴覚データなどのデータの特性に反応して自動的に変えられてよい。一般的には、期間はある特定的なファイルトラック、つまり番組を通して同じままとなるだろう。
【００５４】
例えば、ある特定のビットストリームが映画の表現を備える場合には、位置決め点は、例えば、映画の中のアクションシーケンスに関連付けられてよい、高いビットレートでビットストリームの部分に対応してテーブル内に挿入されてよい。代わりに、テーブルは更新されてよく、例えば点は、ビットストリームのある特定の部分に対応して、ユーザが、例えば早送り、休止または巻き戻しなどのビットストリームのその部分に対応する多数の動作を実行する場合に自動的に挿入されてよい。このようなタイムオフセットは、ユーザの要求で挿入されてもよい。
【００５５】
さらに、タイムオフセット及びデータオフセットは、章の始まりまたは最後などのファイルまたは関連付けられるビットストリームの中の他の好ましい点に対応してよい。
【００５６】
好ましくは、タイムオフセットの期間は、ビットストリームの特性に適合するように選ばれ、好ましくは０．５秒、１秒、２秒または１０秒である。
【００５７】
例えばＭＰＥＧ−２ビットストリームのケースでは、キーフレームは、２Ｈｚという周波数で発生してよいため、位置決め点の時間オフセットが０．５秒という期間で選ばれると、位置決め点はキーフレームに一致してよい。同様に、キーフレームがビットストリームの中で発生する周波数が変わると、位置決め点のタイムオフセットの期間は、位置決め点及びキーフレームが一致するように変わることがある。
【００５８】
タイムオフセットの期間は、ビットストリームの他の特性に適合するように選ぶこともできる。
【００５９】
さらに、タイムオフセットの期間は、ビットストリームの記憶されている表現の特性に従って、及び好ましくは暗号期間のサイズに従って選ばれてよい。
【００６０】
好ましくは、ビットストリームは、視聴覚データのそれぞれの少なくとも１つの部分を生成し直すために独立して使用できるビットストリームデータの少なくとも１つの部分を備え、該少なくとも１つのレコードのタイムオフセットは、ビットストリームデータの該それぞれの少なくとも１つの部分に一致する。
【００６１】
データのこのような部分は、例えばＭＰＥＧビットストリーム中のキーフレームであってよい、及びまたは例えば背景イメージ、またはオーバレイイメージを表してよい。データのこのような部分は、直接的に且つ即座にアクセスされてよく、音声／画像データの代表的な出力は、ビットストリームを通してさまざまな点で速やかに得られてよい。
【００６２】
好ましくは、ビットストリームデータの該少なくとも１つの部分は、キーフレームを備える。
【００６３】
好ましくは、ビットストリームはＭＰＥＧデータを備え、ビットストリームデータの該少なくとも１つの部分はフレーム内を備える。
【００６４】
好ましくは、ビットストリームは、ビットストリームデータの該少なくとも１つの部分とともに視聴覚データの一部を生成し直すために使用できるビットストリームデータの少なくとも１つの追加部分を備え、好ましくはビットストリームデータの該少なくとも１つの追加部分はデルタフレームを備える。
【００６５】
したがって、早送り、巻き戻し及び読み飛ばしなどのプロセスの円滑で速やか、且つ効率的な動作を可能にすることができる。キーフレームの位置を突き止める速度が加速されてよいので、及びデルタフレームなどのデータの依存する部分を処理する必要はない、あるいはデータの限られた数のこのような依存する部分だけが処理される必要がある場合があるので、これらの動作の潜在的な最大速度もこのようにして加速されてよい。
【００６６】
もしかしたら、ビットストリームの表現が符号化され、好ましくはテーブル内の該少なくとも１つのレコードが復号データにマッピングされるかもしれない。
【００６７】
このような復号データは、それぞれがビットストリームの符号化された表現のそれぞれの部分を復号するように適応される復号データの複数の断片を備えてよい。
【００６８】
好ましくは、テーブルは、それぞれがビットストリームの表現を含むファイル内のそれぞれのデータオフセットを、該ビットストリーム中の対応するタイムオフセットにマッピングする複数のレコードを備えてよく、各レコードは、ビットストリームの符号化された表現のそれぞれの部分を復号するためにそれぞれの復号データにマッピングされてよい。
【００６９】
さらに、ビットストリームの表現は、復号データにマッピングするデータの少なくとも１つの断片を備えてよい、及び／または復号データを備えてよい。
【００７０】
好ましくは、ビットストリームの記憶されている表現を復号する上で、ビットストリーム自体の該記憶されている表現内のデータに対し、及び／またはここに記述されるようなテーブルの中に記憶される、またはそれによってマッピングされるデータに対し参照がなされてよい。
【００７１】
このような復号データは、キーワードまたは制御ワードであってよく、それ自体符号化されてよく、追加のキーが復号されることを必要としてよい。条件付きアクセスまたはコンテンツ管理情報を含む多様な符号化データは、符号化され、記憶されてよい。条件付きアクセス情報とコンテンツ管理情報の符号化、復号及び記憶、及びデータ、特にビットストリームデータの記憶と検索における条件付きアクセス情報とコンテンツ管理情報の使用は、内容が参照してここに組み込まれ、任意の部分がここに説明されている任意の特徴または特徴の組み合わせとの適切な組み合わせで結合されてよい国際（ＰＣＴ）特許出願番号第ＰＣＴ／ＩＢ０１／０１８４５号に詳細に説明されている。
【００７２】
好ましくは、テーブルは、ファイル内のビットストリームの表現のレコーディング中に自動的に生成される。
【００７３】
したがって、ビットストリームのレコーディングが完了した後には記録されたビットストリームの追加処理は必要なく、レコーディングが中断または終了されたとしてもＨＤＶＲ索引表は所定の位置にある。
【００７４】
好ましくは、テーブル内の少なくとも１つのレコードがそれぞれの少なくとも１つの追加レコードにマッピングされ、好ましくは前記少なくとも１つの追加レコードは条件付きアクセス情報またはコンテンツ管理情報を備える。
【００７５】
復号データは、このような追加レコードを備えてよい、あるいはこのような追加レコードに含まれてよい。
【００７６】
コンテンツ管理情報または条件付きアクセス情報は、例えば、制御ワード（ＣＷ），またはＣＭＭ、ＥＣＭ、ＥＭＭ、ＵＲＭ、あるいはデータオフセットまたはタイムオフセットのある特定の値または値の範囲に位置するデータと関連付けられてよい関連情報であってよい。一般的には、ビットストリームはタイムセグメント、つまり（タイムオフセットの範囲を包含する）暗号期間に分割されてよく、該追加レコードは１つの特定の暗号期間または複数の暗号期間と関連付けられてよい。該追加レコードは、例えば章と、あるいは全体としてのファイルと、または特定のユーザまたはユーザグループと関連付けられてもよい。データへのアクセスは、特定のデータオフセットまたはタイムオフセットに対応する記憶されている関連情報を読み取ることによって速やかに且つ効率的に可能とされてよい。データに対するこのような速やかなアクセスは、早送り、巻き戻しまたは読み飛ばしなどのプロセスという点で特に重要であってよい。
【００７７】
特に、該追加レコードは、１つのＣＭＭまたは複数のＣＭＭを備えてよい。
【００７８】
テーブル内の点がある暗号期間の始まりに一致しないファイル内のデータオフセットにマッピングする場合には、ＨＤＶＲは、通常、ＣＭＭ、またはこのようなＣＭＭに対するポインタ、またはその点にあるデータを復号するために必要な他のコンテンツ管理または条件付きアクセスの情報にアクセスできないだろう。ＨＤＶＲは、一般的には、データの復号を開始するためにこのような情報の次のセット、またはこのような情報に対するポインタを見つけ出すために、ファイルを通して順方向にまたは逆方向に連続して読み取らなければならないだろう。テーブル内の少なくとも１つのレコードを少なくとも１つの追加レコードにマッピングすることによって、レコードによって索引が付けられるファイル内の点に適用可能な条件付きアクセスまたはコンテンツ管理の情報を提供することができ、この点からのデータは、このような情報を見つけ出すために最初にファイルを読み通す必要なく即座に復号できる。この特徴は、例えば、早送りまたは巻き戻しなどの一定のトリックモード動作の実行において、ファイル内の数多くの点でデータが連続して且つ速やかに読み取られる必要がある場合に特に有利である。
【００７９】
該追加レコードは、例えば、画面上に表示できるだろうコメント、またはテレビ制御コマンドなどのコマンドを備えてよい。代わりに、データは親制御機構に関係するだろう。このような親制御機構は特定の章に向けられてよいが、暗号期間及び複数の暗号期間、及びファイルのユーザにより定義される部分に向けられてもよい。
【００８０】
追加レコードは、レコードのテーブル内、または別個のファイルまたはテーブル内に記憶されてよいか、あるいはレコードのテーブル及びまたは関連情報は、例えばヘッダにファイルとともに記憶されてよい。
【００８１】
好ましくは、前記少なくとも１つの追加レコードは追加テーブルに記憶される。
【００８２】
このような追加テーブル内のエントリは、データオフセットをタイムオフセットにマッピングするテーブル内のエントリに容易にマッピングされてよい。
【００８３】
好ましくは、前記少なくとも１つの追加レコードは、ユーザの命令時に挿入される。
【００８４】
このようにして、ユーザは、番組またはビットストリームの特性に関する情報を追加、または実際には削除してよい。例えば、ユーザは、アクセスの制御を希望する録画された映画の中の特定の場面を選択してよく、このようなアクセスは親制御機構を起動するレコードの追加または修正によって制御できるだろう。
【００８５】
好ましくは、テーブル内の前記少なくとも１つのレコードは、ユーザの命令時に該それぞれの少なくとも１つの追加レコードにマッピングされる。
【００８６】
このようにして、ユーザは、どのレコードがどの追加レコードと関連付けられるのかを制御できる。
【００８７】
好ましくは、ファイルは符号化され、該少なくとも１つのレコードが、符号化されたファイル内のデータオフセットをビットストリーム中の対応する時間オフセットにマッピングする。
【００８８】
好ましくは、少なくとも１つのレコードは、ビットストリームの特性に従って挿入される。
【００８９】
好ましくは、少なくとも１つのレコードは、ユーザの命令時に挿入される。
【００９０】
このようにして、ファイル内の点は、アクセスの容易さのためにブックマークが付けられてよい。
【００９１】
レコードは、番組を見ている間またはファイルを読んでいる間に、「進行中に」ユーザによって挿入されるか、あるいは実際には削除または修正されてよいか、あるいはビットストリームを通してユーザによって指定される間隔に対応する点でファイル内に挿入されてよい。
【００９２】
好ましくは、少なくとも１つのレコードは、それぞれのデータオフセットを表す第１データポイント、及び対応するタイムオフセットを表す第２データポイントを備える。
【００９３】
好ましくは、少なくとも１つのレコードは、自動的に挿入される。
【００９４】
このようにして、ユーザは、直接的または間接的に、ファイルまたはビットストリームを全体として、または部分的に見直す必要なく、重要なビットストリームの特定な部分にブックマークを付けてよい。例えば、ユーザは、映画を見る必要なく、ビットストリームの表現を含むファイルに表現が記憶される映画の部分にブックマークを付けてよい。
【００９５】
特定的な型のデータ、または例えばビットストリーム内でのデータ対時間の割合が（例えば、映画の中のアクションシーケンスに、または爆発または落雷などのきわめて対照的なイメージを含む映画の中の場面に相当してよい）一定の範囲内にあるビットストリームの部分は、位置を突き止められ、ブックマークを付けられてよい。
【００９６】
好ましくは、テーブルは、ビットストリームの表現とともにファイルの中に記憶するために適応される。
【００９７】
このようにして、ファイル及び関連付けられるテーブルは、容易に、例えば記憶、処理またはともに伝送されてよい。例えば、テーブルは、放送センタで作成され、ファイルとともに伝送されてよく、このようにしてＨＤＶＲまたは他のデバイスが、テーブル自体を作成する能力を必要とせずに、テーブルを読み取り、その中に含まれている情報を使用することができる。また、放送局は、ファイル及び関連付けられるテーブルに対する集中制御を保持してよい。
【００９８】
テーブルは、ＨＤＶＲで、あるいはセットトップボックス内に含まれる、またはセットトップボックスと関連付けられる任意のデバイス内で、あるいはデジタルデータを読み取るように適応された任意のデバイス内で作成、及びまたは記憶されてもよい。
【００９９】
発明の関連する態様においては、前述されたようにテーブルを作成することを備える、ビットストリームの表現を含むファイルの探索を容易にする方法が提供される。
【０１００】
特に、ビットストリームの表現を含むファイル内のそれぞれのデータオフセットを、該ビットストリーム内の対応するタイムオフセットにマッピングする少なくとも１つのレコードを備えるテーブルを生成することを備える、ビットストリームの表現を含むファイルの探索を容易にする方法が提供される。
【０１０１】
好ましくは、該少なくとも１つのそれぞれのデータオフセット及び／または該少なくとも１つのそれぞれのタイムオフセットの値は、ビットストリームの特性及び／またはビットストリームの表現に従って選ばれる。
【０１０２】
前述されたように、ビットストリームは、好ましくは可変ビット・レートビットストリームである。
【０１０３】
好ましくは、テーブルは、少なくとも３つのレコードを備え、タイムオフセットは周期的である。
【０１０４】
タイムオフセットが周期的である場合には、その期間は、好ましくはビットストリームの特性に適合するように選ばれ、好ましくは０．５秒、１、２秒、または１０秒である。
【０１０５】
好ましくは、タイムオフセットの期間は、ビットストリームの記憶されている表現の特性に従って、及び好ましくは暗号期間のサイズに従って選ばれる。
【０１０６】
好ましくは、ビットストリームは、視聴覚データのそれぞれ少なくとも１つの部分を生成し直すために独立して使用できるビットストリームデータの少なくとも１つの部分を備え、該少なくとも１つのレコードのタイムオフセットは、ビットストリームデータの部分のそれぞれの少なくとも１つに一致する。ビットストリームデータの該少なくとも１つの部分は、ビットストリームが例えばＭＰＥＧデータを備える場合には、フレーム内などのキーフレームを備えるだろう。
【０１０７】
前述されたように、好ましくは、ビットストリームは、ビットストリームデータの該少なくとも１つの部分とともに視聴覚データの一部を生成し直すために使用できるビットストリームの少なくとも１つの追加部分を備え、ビットストリームデータの該少なくとも１つの追加部分は、デルタフレームを備えてよい。
【０１０８】
好ましくは、テーブルは、ファイル内のビットストリームの表現のレコーディング中に自動的に作成される。
【０１０９】
ビットストリームの表現は符号化されてよく、好ましくはテーブル内の該少なくとも１つのレコードが復号データにマッピングされる。
【０１１０】
好ましくは、復号データは、それぞれが、ビットストリームの符号化された表現のそれぞれの部分を復号するように適応される、復号データの複数の断片を備える。
【０１１１】
好ましくは、テーブルは、それぞれがビットストリームの表現を含むファイル内のそれぞれのデータオフセットを、該ビットストリーム中の対応するタイムオフセットにマッピングする複数のレコードを備え、各レコードは、ビットストリームの符号化された表現のそれぞれの部分を復号するためにそれぞれの復号データにマッピングされてよい。
【０１１２】
好ましくは、ビットストリームの表現は、復号データにマッピングするデータの少なくとも１つの断片を備える。復号データは、少なくとも１つの追加レコードを備えてよいか、あるいは少なくとも１つの追加レコードに含まれてよく、好ましくは前記少なくとも１つの追加レコードは、条件付きアクセス情報またはコンテンツ管理情報を備えてよい。
【０１１３】
再び、テーブル内の少なくとも１つのレコードが、それぞれの少なくとも１つの追加レコードにマッピングされてよく、好ましくは前記少なくとも１つの追加レコードは条件アクセス情報またはコンテンツ管理情報を備える。
【０１１４】
好ましくは、前記少なくとも１つの追加レコードは、追加テーブルに記憶される。
【０１１５】
前述されたように、前記少なくとも１つの追加レコードは、ユーザの命令時に挿入される。
【０１１６】
好ましくは、テーブル内の該少なくとも１つのレコードは、ユーザの命令時に、該それぞれの少なくとも１つの追加レコードにマッピングされる。
【０１１７】
好ましくは、ファイルは符号化され、該少なくとも１つのレコードは、ビットストリーム内の対応するタイムオフセットに、符号化されたファイル内のデータオフセットをマッピングする。
【０１１８】
好ましくは、少なくとも１つのレコードが、ビットストリームの特性に従って挿入される。
【０１１９】
好ましくは、少なくとも１つのレコードが、ユーザの命令で挿入される。
【０１２０】
好ましくは、少なくとも１つのレコードは、それぞれのデータオフセットを表す第１データポイント、及び対応するタイムオフセットを表す第２データポイントを備える。
【０１２１】
好ましくは、少なくとも１つのレコードが自動的に挿入される。
【０１２２】
好ましくは、テーブルは、ビットストリームの表現を含むファイルに記憶される。
【０１２３】
追加の態様においては、ファイル内の位置にジャンプするステップと、例えば、データの所望される部分が見つけられるまでこの位置からデータを読み取るステップとを備える、データの所望される部分を求めてビットストリームの表現を含むファイルを探索する方法が提供される。
【０１２４】
これは、例えば所望される点に達するまでビット単位でファイルの中を進む代替方法より、ファイル内のある特定の点を見つけるためのさらに効率的な方法を提供できる。
【０１２５】
好ましくは、データを読み取るステップは、データの所望される部分が見つけられるまで読み取ること、及び／または固定量のデータを読み取ること、及び／または固定時間帯を表すデータの量を読み取ること、及び／またはデータのある特定の断片が読み取られるまでデータを読み取ることとを備える。
【０１２６】
再び、ビットストリームは、可変ビット・レートビットストリームである。
【０１２７】
このようにして、ファイル内の特定の点は、例えば、ファイル内のデータオフセットとビットストリーム中のタイムオフセットの間に線形関係がないとしても、所望される点に達するまでビット単位でファイルの中を進む方法を使用するよりさらに効率的に見つけることができる。
【０１２８】
好ましくは、データの所望される部分は、データの追加部分を生成し直すために独立して使用できるビットストリームデータを表す。
【０１２９】
データの追加部分は、例えば視聴覚データであってよく、所望される部分は、キーフレームであってよい。
【０１３０】
好ましくは、ファイル内の位置にジャンプするステップは、ここに説明されるようなテーブルからレコードを読み取ることと、該レコード内で指定されるデータオフセットにジャンプすることを備える。
【０１３１】
好ましくは、ファイル内の位置にジャンプするステップは、ここに説明されるようなテーブルからレコードを読み取ることと、該レコード内で指定されるデータオフセットにジャンプすることを備え、少なくとも１つの追加レコードがデータを読み取るステップに使用される。
【０１３２】
該少なくとも１つの追加レコードは、条件付きアクセス情報、またはコンテンツ管理情報であってよく、特に１つのまたは複数のＣＭＭであってよい。該追加レコードは、ファイル内のデータを復号するために使用されてよい。
【０１３３】
好ましくは、レコード内のデータオフセットは、ファイル内の所望される位置に対応する。
【０１３４】
このようにして、所望される点は、ファイル内の所望される点の位置を突き止める前に、追加のデータを読み取る必要なく、ファイル内のデータオフセットに相当するファイル内の点にジャンプすることによって見つけ出すことができる。
【０１３５】
好ましくは、データを読み取るステップは、データを復号することを備える。さらに、データを読み取るステップは、前述されたようにテーブルからレコードを読み取ることと、復号データを使用してデータを復号することを備えてよい。
【０１３６】
追加の態様において、ここに説明されるような方法を使用してデータのそれぞれの所望される部分を探索することを備える、データの複数の所望される部分に対するビットストリームの表現を含むファイルを探索する方法が提供される。
【０１３７】
このようにして、ファイル内の一連の所望される点は、迅速に且つ効率的に位置を突き止めることができ、これらの点にあるデータを読み取ることができる。
【０１３８】
好ましくは、データの所望される部分は、時間的に周期的に間隔をあけて配置されるビットストリームの部分を表す。
【０１３９】
このようにして、時間的に均等に間隔をあけて配置されるビットストリームの部分は、迅速に且つ効率的に位置を突き止め、読み取ることができ、記憶されているビットストリームでの早送りまたは巻き戻しなどのトリックモード動作の迅速且つ効率的な実行を可能にしてよい。
【０１４０】
好ましくは、データの所望される部分は、早送り動作または巻き戻し動作を達成するために使用される。
【０１４１】
一般的には、関連付けられるＣＭＭを使用してデータの所望される部分の位置が突き止められ、読み取られ、結果的に生じるデータ、通常は、視聴覚データは、ディスプレイ装置に出力されてよい。
【０１４２】
好ましくは、データの所望される部分によって表されるビットストリームデータの部分間の時間帯は、指定された早送り速度または巻き戻し速度を達成するために選ばれる。
【０１４３】
好ましくは、データの所望される部分によって表されるビットストリームデータの部分間の時間帯は、方法を実施するために使用される手段の特性に従って選ばれる。
【０１４４】
データが、位置を突き止められ、読み取られ、ディスプレイ装置とともにＨＤＶＲなどの手段によって表示されてよい最大速度は、このような手段の特性に依存し、ハードウェア特性またはソフトウェア特性のどちらかに依存してよい。指定される先送り速度または巻き戻し速度は、例えば、記憶されているファイル内の一定の割合のデータがプレイバックされる場合に持続できるにすぎない可能性がある。例えば、ファイル内のすべてのデータを通常の速度より速くプレイバックすることは可能でないことがある。他方、プレイバックされるデータの割合の制限が厳しすぎると、例えば画質が劣化することがある。
【０１４５】
好ましくは、特性は、ファイルからのデータの検索または処理の最大持続可能速度である。
【０１４６】
ビットストリームデータの部分間の時間帯を変えることによって、ファイルからのデータの検索または処理の最大持続可能速度が、手段の指定された特性について得ることができる。したがって、例えば、最適の画質が、指定された早送り速度または巻き戻し速度について得られてよい。
【０１４７】
好ましくは、特性は、読み取り／書き込みハードディスクアクセス時間、またはパージングデマルチプレクサ帯域幅、またはオペレーティングシステムのスケジューリング精度である。
【０１４８】
好ましくは、指定される早送り速度または巻き戻し速度は、ユーザの命令時に変えられる。
【０１４９】
発明の追加の態様においては、前述されたような方法を使用してデータの所望される部分を探索することと、データの所望される部分を検索することを備える、ビットストリームの表現を含むファイルからデータの少なくとも１つの所望される部分を検索する方法が提供される。
【０１５０】
好ましくは、該方法は、前述に従って方法を使用してデータのそれぞれの所望される部分を探索することと、データのそれぞれの所望される部分をその結果として検索することを備える、ファイルからデータの複数の所望される部分を検索するための方法である。
【０１５１】
発明の別の態様においては、前述されたような方法を使用してビットストリームの表現を含むファイルから少なくとも１つの所望される部分を検索することと、データの該少なくとも１つの所望される部分を出力することとを備える、データを出力する方法が提供される。
【０１５２】
発明のまだ追加の態様においては、前述されるような方法を使用してデータの複数の所望される部分を検索することと、その結果としてデータのそれぞれの所望される部分を出力することを備える、データを出力する方法が提供される。
【０１５３】
好ましくは、データの複数の所望される部分のそれぞれは、ビットストリームデータのそれぞれの部分を表し、ビットストリームデータの該それぞれの部分は、時間的に周期的に間隔をあけて配置される、及び／または同じ持続時間を有する。
【０１５４】
発明の別の態様は、前述されたようにデータを出力することを備える、早送り動作または巻き戻し動作を達成する方法を提供する。
【０１５５】
発明の追加の態様においては、ビットストリームの表現及びここに説明されるようなテーブルを備えるファイルが提供される。
【０１５６】
発明は、ビットストリーム内のタイムオフセットをファイル内のデータオフセットにマッピングする索引を備える索引表も提供する。
【０１５７】
まだ追加の態様においては、ここに説明されるようなテーブルの作成のためのプロセッサ、及びビットストリームの特性の分析、及びこの分析に従うこのようなテーブル中へのレコードの挿入のためのプロセッサが提供される。
【０１５８】
ここに説明されるようなテーブルの記憶のための記憶手段も提供され、好ましくは、該記憶手段は、ビットストリームの表現を含むファイルの記憶のために適応される。
【０１５９】
ここに記述されるような記憶手段を備え、好ましくはさらにここに説明されるようなプロセッサを備えるハードディスクビデオレコーダ、及びこのようなハードディスクビデオレコーダを備える受信機／デコーダも提供される。好ましくは、このような受信機／デコーダを組み込む放送システムも提供される。
【０１６０】
追加の態様においては、ここに説明されるようなハードディスクビデオレコーダと通信するように適応される受信機／デコーダが提供され、このような受信機／デコーダを組み込む放送システムが提供される。
【０１６１】
発明は、さらに、ここに説明される方法のどれかを実施するため、及び／またはここに説明される装置特徴のどれかを具体化するためのコンピュータプログラム及びコンピュータプログラム製品、及びここに説明される方法のどれかを実施するため、及び／またはここに説明される装置特徴のどれかを具体化するためのプログラムをその上に記憶しているコンピュータ読み取り可能媒体を提供する。
【０１６２】
発明は、ここに説明される方法のどれかを実施するため、及び／またはここに説明される装置機能のどれかを具体化するためのコンピュータプログラム及び／またはコンピュータプログラム製品を具体的に具現する信号、このような信号を伝送する方法、及びここに説明される方法のどれかを実施するため、及び／またはここに説明される装置機能のどれかを具体化するためのコンピュータプログラムをサポートするオペレーティングシステムを有するコンピュータ製品も提供する。
【０１６３】
既知のシステムの追加の態様の考慮を始めると、いくつかの既知のシステムは、ハードディスクで受信されたスクランブルされたビットストリーム（つまり、符号化されたデジタルテレビ信号）を記録することができる。１つのこのようなシステムにおいて、ビットストリームは、それを記録したときの圧縮され、スクランブルされた形式で保持されるが、その結果レコーディングは（定期的に置換される）活用キーの持続期間だけ有効である。この問題を克服する１つの技法は、本来、ビットストリームから、それが記録される前にエンタイトルメント制御メッセージ（ＥＣＭ）を抽出すること、従来通りにＥＣＭを平文に直すこと、ＥＣＭを（各加入者に固有の）内部活用キーで暗号化し直すこと、及び（つねにビットストリームをスクランブルするために使用される制御ワードを改変しないで）ＥＣＭをその元の位置のビットストリームの中に入れ直すことから成り立っている。これは、機密保護を高めるという所望される効果を有するが、それは、特に、非常に計算上集約的である、ビットストリーム内での各ＥＣＭの位置が正確に突き止められることを要求するため、実現するのは複雑である。
【０１６４】
本発明は、前記及び他の従来の技術における問題も改善しようとする。
【０１６５】
したがって、発明の追加の態様において、位置を推定するための手段を備える、ビットストリーム内の位置を評価するための方法が提供される。
【０１６６】
例えば、位置を、それを正確に突き止める代わりに推定することにより、位置を評価するプロセスはさらに容易になる。
【０１６７】
位置は、好ましくは、ビットストリーム中の、ＭＰＥＧテーブルなどのデータパケットの空間的な位置である。それは、代わりに、例えば秒で測定されるビットストリーム内の時間的な位置であってよい。好ましくは、装置は、リアルタイムに処理されているビットストリームに関して動作するように適応されるが、それは静的及び／またはランダムアクセスビットストリームに関して動作するように適応されてもよい。さらに、ビットストリームは、好ましくは（ＭＰＥＧフォーマットなどの）パケット化された、及び／または音声／画像データを含む。
【０１６８】
ここに使用されるような用語「音声／画像」は、好ましくは、音声または画像どちらかの内容、あるいは２つの組み合わせを意味する。受信機／デコーダによって受信される放送信号という文脈では、用語は、字幕、テレテキスト、同期及びテレビ番組を構成する音声構成要素とビデオ構成要素に密接に関係して伝送される他のデータを包含してよい。
【０１６９】
位置を推定する手段は、好ましくは、ビットストリーム中の既知の位置に従って位置を推定するように適応される。既知の位置は、例えば、ビットストリームのさまざまな部分の間での遷移だろう。推定がビットストリーム中の既知の位置に依存しているため、推定をさらに正確に行うことができる。
【０１７０】
好ましい実施形態においては、装置は、さらに、複数の代替策から既知の位置を選択するための手段を備える。これは、プロセスの選択性を高めることによって、推定をさらに精緻化できる。
【０１７１】
結果的に、既知の位置を選択するための手段は、好ましくは、評価される位置に対するその近接さに従って既知の位置を選択するように適応される。
【０１７２】
したがって、推定される位置はそれ自体容易に決定できない、あるいはまったく正確に決定できないが、推定される位置にそれほど近くない他の既知の位置に優先して、推定される位置に近い既知の位置を突き止めることは可能である場合がある。これが、位置が推定される精度を、ビットストリーム中の少なくとも１つの既知の位置に従ってさらに適切に制限できるようにする。
【０１７３】
既知の位置を選択するための手段は、評価される位置に最も近い２つの既知の位置の１つを整然と選択するように適応されてよい。これは、さらに、推定の精度を高めることができる。特に、既知の位置は、推定される位置の前または後ろのどちらかの最も近い位置であるように選ばれる。どちらかの場合には、これは、位置の推定をビットストリーム中でそれぞれ通常後方に、または通常前方にどちらかで偏向させることがある。代わりに、既知の位置は、推定値の通常の偏向を生じさせないことがある、どちらかの方向での最も近い位置であるように選ばれてよい。
【０１７４】
さらに、既知の位置を選択するための手段は、ビットストリームの第1部分と第２部分の間のビットストリーム内の遷移として既知の位置を選択するように適応されてよい。このような第1部分と第２部分は、例えば、直接メモリアクセス（ＤＭＡ）データ転送で転送されるビットストリームのセグメントであるだろう。
【０１７５】
これは、既知の位置を突き止めるときに、ビットストリームの既存の分割を利用することによって推定をさらに効率的にすることがある。ビットストリームの区分の内の１つは、推定される位置を含むことがある。
【０１７６】
好ましくは、位置を推定するための手段は、位置を既知の位置からの偏位として推定し、それによって時間−変位の影響を考慮に入れることを可能にするように適応されてよい。該偏位はゼロであってよく、その場合、推定される位置は既知の位置に等しいか、あるいはそれは正または負であってよい。
【０１７７】
さらに、位置を推定するための手段は、バッファサイズに従って位置を推定するように適応されてよい。好ましくは、位置は、とりわけ、既知の位置にバッファサイズを追加することによって推定される。バッファサイズ（好ましくは、最大サイズとして定められるか、あるいは代わりに予想されるサイズまたは正確なサイズ）は、例えばＦＩＦＯなどのビットストリームを移すために使用されるバッファに関係してよい。バッファサイズに従って位置を推定することによって、事実上、このようなバッファの使用から生じる不確実性及び／または遅延を考慮に入れることができる。
【０１７８】
代わりに、またはさらに、位置を推定するための手段は、機密保護パラメータに従って位置を推定するように適応されてよい。特に、位置は、とりわけ、既知の位置に機密保護パラメータを追加することによって推定されてよい。機密保護パラメータは、負または正であってよく、好ましくは推定値が臨界値を超えるか、あるいは臨界値範囲内に留まるかのどちらかであり、代わりにまたはさらに、単一の補正係数の中に（考えられるタイミング誤差、ソフトウェア遅延、未知のパケットサイズ等の）推定値に影響を及ぼす複数の不確実性または偏向を要約できることを確実にするために「安全係数」として利用される。
【０１７９】
好ましい実施形態においては、装置は、さらに、ビットストリームを記憶するための手段を備えてよい。この記憶するための手段は、好ましくは、ビットストリームを記憶させるための制御装置を備えるが、代わりにまたはさらに、ハードディスクなどの対応する記憶装置を備えてよい。これが、装置の汎用性を高めることができる。
【０１８０】
この場合、装置は、さらに、ビットストリームとは別個にビットストリームと関連付けられるデータを記憶するための手段を備えてよい。ビットストリームに関連付けられるデータは、好ましくは、推定位置、推定位置に対応するデータ、及び推定位置に対応するデータを記憶されるビットストリームと同期できるようにする情報の内の少なくとも１つを備える。ビットストリームとは別個に、ビットストリームと関連付けられるデータを記憶するための手段は、好ましくは条件付きアクセスデータを記憶するように適応される。
【０１８１】
この重要な機能は、条件付きアクセスデータを受信するための手段、条件付きアクセスデータをビットストリームと同期させるための手段、及びビットストリームを記憶するための手段を備える、ビットストリームを操作するための装置を提供する発明の関係する態様に関しても備えられる。
【０１８２】
条件付アクセスデータをビットストリームと同期させることによって、ビットストリーム自体の中での条件付きアクセスデータに対する依存を削減できる。
【０１８３】
前述されたように、装置は、好ましくは、さらに、ビットストリームとは別個に条件付きアクセスデータを記憶するための手段を備える。しかしながら、装置は、代わりに、例えば、多重化するか、あるいはそれ以外の場合ビットストリームの中にデータを挿入し直すことによって、ビットストリームの中に条件付きアクセスデータを記憶するための手段を備えてよい。前者の場合、条件付きアクセスデータは、記憶されるビットストリームも含むファイルの別個の部分に含まれてよいか、あるいはそれは別個のファイルまたは別の記憶装置媒体内に記憶されてよい。
【０１８４】
これが、例えば、（対応するビットストリームに関して）通常さらに少量の条件付アクセスデータに対するさらに高速なアクセスを可能にすることによって、条件付きアクセスデータを管理する効率を改善できる。
【０１８５】
同期させるための手段は、好ましくは、条件付きアクセスデータとビットストリーム内の対応する位置の間に基準を作成するように適応される。さらに好ましくは、装置は、条件付きアクセスデータ及び／またはビットストリームとの、あるいは条件付きアクセスデータ及び／またはビットストリームに近接する該またはそれぞれの基準を記憶するための手段をさらに備える。これが、条件付きアクセスデータをビットストリームと同期させるタスクを容易にできる。
【０１８６】
装置は、さらに、例えば、ビットストリームの再生の間に、条件付きアクセスデータに対するアクセスをさらに容易にできる、テーブルに基準を記憶するための手段を備えてよい。
【０１８７】
同期させるための手段は、安全値の範囲から参照される位置（つまり、条件付きアクセスデータと対応する位置の間の基準での「対応する位置」）を選択するように適応される。
【０１８８】
安全値の範囲は、好ましくは、条件付きアクセスデータに対応するビットストリーム中の実際の位置を備え、これが、条件付きアクセスデータ（またはそのコピー）が実際に伝送されるビットストリーム中の位置である。
【０１８９】
同期させるための手段が参照される位置を、それが、条件付きアクセスデータが対応するビットストリームの部分に含まれるように選択するように適応される場合、同期させる手段は、好ましくは、さらに、参照される位置を、それが、条件付きアクセスデータが対応する暗号期間に含まれるように選択するように適応される。
【０１９０】
条件付きアクセスデータが対応する暗号期間との参照される位置のこの整合が、ビットストリームと条件付きアクセスデータ間の同期の質を改善できる。
【０１９１】
好ましくは、同期させるための手段は、受信手段による条件付きアクセスデータの受信を簡略化するイベントに従って、参照される位置を選択するように適応される。これが、ビットストリームと条件付きアクセスデータをなおさらに密接に同期させることを可能にする。
【０１９２】
前述されたように、装置は、さらに、ビットストリーム中の位置を推定するための手段を備えてよいが、参照される位置は、推定位置に従って選択される。
【０１９３】
好まれるように、装置が好ましくは、さらに、複数の離散セグメント内のビットストリームを転送するための手段を備える場合、位置を推定するための手段は、好ましくは、該セグメントの１つの最後に従って位置を推定するように適応され、さらに、装置は、好ましくはさらに少なくとも１つのセグメントのサイズを事前に決定するための手段を備える。これは、該少なくとも１つのセグメントのサイズの変動が、推定値自体及び推定プロセスの安定性に直接的にまたは間接的に影響を及ぼすことがあるため、推定プロセスの柔軟性を高めることができる。
【０１９４】
それは代わりにセグメントのサイズを検出することを伴ってよいが、事前決定は、好ましくは、セグメントのサイズを設定することを伴う。おそらく、システム性能、ＦＩＦＯ、及びハードディスクサイズなどの要因に応じて、各セグメントは、例えば、1ビットほど小さく、１００Ｍｂほど大きいまたはなおさらに大きくなるだろう。しかしながら、効率のために、典型的なＭＰＥＧ音声／画像ビットストリームにとっては、約1Ｍｂと、例えば６ＭＢの間の値が適切であってよい。転送するための手段は、例えば、直接メモリアクセス（ＤＭＡ）制御装置、大容量記憶装置、ＦＩＦＯ及び／またはＦＩＦＯマネージャ等であってよい。
【０１９５】
発明の関係する態様において、複数の離散セグメントの中のビットストリームを転送するための手段、及びセグメントの１つのプロパティに従ってビットストリーム中の位置を推定するための手段を備える、ビットストリームを操作するための装置が提供される。
【０１９６】
このようなプロパティは、例えば、セグメントサイズであるだろう。
【０１９７】
前述されたように、好ましくは、位置を推定するための手段は、ビットストリーム中の、ＥＣＭなどの条件付きアクセスデータの部分を推定するように適応される。やはり前述されたように、装置は、好ましくは、さらに、注記されるように推定の柔軟性を高めることができるセグメントのサイズを事前に決定するための手段を備える。
【０１９８】
サイズを事前に決定するための手段は、理想的には、位置に関連付けられるビットストリームの部分未満に同等なサイズを事前に決定するように適応される。このような部分は、所定数の暗号期間であってよく、その場合、暗号期間の数は整数である必要はなく、実際には、例えば、ＦＩＦＯバッファの影響を考慮に入れるために自然数よりわずかに少なくてよい。これが、推定の安全性を確実にできる。
【０１９９】
サイズを事前に決定するための手段は、やはりまたは代わりに、ビットストリームの特性に従ってサイズを事前に決定するように適応されてよい。ビットストリームの特性に従ってセグメントのサイズを決定することにより、例えば、推定値の精度に影響を及ぼすことのあるビットストリームに関係する係数を考慮に入れることができる。
【０２００】
さらに、サイズを事前に決定するための手段は、ビットストリームのビットレートに従ってサイズを事前に決定するように適応されてよい。好ましくは、このビット速度は、問題のセグメント、または好ましくは位置を含むビットストリームの他の部分について計算されてよい平均ビットレートである。
【０２０１】
サイズを事前に決定するための手段が、一定のサイズを事前に決定するように適応される場合、サイズを事前に決定するための手段は、さらに静的フィルタを備えてよい。他方、サイズを事前に決定するための手段が、可変サイズを事前に決定するように適応される場合、サイズを事前に決定するための手段は、好ましくは動的フィルタを備える。
【０２０２】
両方の種類のフィルタは、入力として、好ましくはビットストリームの少なくとも１つの特性を受け入れ、出力として所望されるセグメントサイズを生成する。事実上、好ましくは、ビットストリームの一連の特性に対応して、数多くのフィルタ係数が使用される。このような特性は、前述されただろう。フィルタは、例えばデジタル信号プロセッサ（ＤＳＰ）、コプロセッサ、またはメインプロセッサの制御下で、ソフトウェア内で実現できる。ここに使用されるような用語「フィルタ」は、好ましくは、少なくとも１つの入力を少なくとも１つの出力に変換するためのプロセスまたは装置を意味する。このようなフィルタは、変数がフィルタ入力である数式の積として見ることができるだろう。
【０２０３】
さらに、サイズを事前に決定するための手段は、高速動的フィルタ、慣性動的フィルタ、及びハイブリッド動的フィルタの少なくとも１つを備えてよい。該高速フィルタ及び慣性フィルタは、それぞれ、相対的に少ない入力値を有する、及び相対的に多くの入力値を有するという点で特徴付けられる。ハイブリッドフィルタは、高速フィルタと慣性フィルタ両方の特性を有することを特徴としてよく、好ましくは事実上高速フィルタと慣性フィルタの組み合わせであり、総合的なフィルタ出力は、ある特定の入力が増加しているのか、あるいは減少しているのかなどの特定の制約に従って、これら２つのサブフィルタのある特定の１つの出力として選択される。
【０２０４】
位置を推定するための手段は、少なくとも１つの過去の推定値の誤差を考慮に入れるように適応されてよい。このような誤差は、例えば、推定位置と実際位置の間で機能的に観察される時間差であるだろう。これが、推定値を経時的に精緻化できるようにする。
【０２０５】
装置は、さらに、ビットストリームの少なくとも１つの特性に従って位置を推定するための手段を備えてよい。例えば、特にビットストリームに関してさらに多くの情報が入手できる場合に、これはさらに正確な推定値を生じさせることがある。
【０２０６】
この重要な機能も独自に提供される。したがって、発明の関係する態様においては、ビットストリームの少なくとも１つの特性に従って位置を推定するための手段を備える、ビットストリーム内の位置を評価するための装置が提供される。
【０２０７】
該、またはそれぞれの特性は、好ましくは、ビットストリームのビットレート、ビットストリーム内の相対位置、及びビットストリームの部分間で経過する時間の少なくとも１つである。
【０２０８】
装置は、さらに、位置の発生と位置に関係するイベントの発生の間の分離の約数を推定するための手段を備える。このような分離の約数は、例えば、後述される時間△ｔであろう。これは、さらに優れた推定を行うためのさらに多くの情報を提供できる。
【０２０９】
ビットストリーム中の位置を推定するための手段は、好ましくは、ビットストリーム中の位置に近いビットストリームのビットレートの推定値とともに、分離の約数を組み込むように適応される。これは、さらに推定プロセスを精緻化できる。
【０２１０】
分離の約数を推定するための手段は、好ましくは、位置の発生と処理動作の最後の間の分離を測定するように適応される。該処理動作は、好ましくは、ビットストリーム中の位置に関連付けられるデータの処理に関係する。
【０２１１】
発明の追加の関係する態様において、前述されたように、（多様な態様のどれかに）装置を組み込む受信機／デコーダが提供される。
【０２１２】
まだ追加の態様においては、位置を推定することを備える、ビットストリーム中の位置を評価する方法も提供される。
【０２１３】
発明の別の態様においては、条件付きアクセスデータを受信することと、条件付きアクセスデータをビットストリームと同期させることと、ビットストリームを記憶することとを備える、ビットストリームを操作する方法が提供される。
【０２１４】
発明の追加の態様においては、複数の離散セグメント内のビットストリームを転送することと、セグメントの１つのプロパティに従ってビットストリーム中の位置を推定することとを備える、ビットストリームを操作する方法が提供される。
【０２１５】
発明のまだ追加の態様においては、ビットストリームの少なくとも１つの特性に従って位置を推定することを備える、ビットストリームの中の位置を評価する方法が提供される。
【０２１６】
発明の別の態様においては、前述されたように、放送センタ及び受信機／デコーダを備える放送システムが提供される。
【０２１７】
発明の追加の態様においては、前述されたように方法を実施するように適応されるコンピュータプログラム製品が提供される。
【０２１８】
発明のまだ追加の態様においては、前述されたようにコンピュータプログラム製品をその上に記憶しているコンピュータ読み取り可能媒体が提供される。
【０２１９】
発明の別の態様においては、前述されたようにコンピュータプログラム製品を具体的に具現する信号が提供される。
【０２２０】
発明は、ここに説明される方法のどれかを実施するため、及び／またはここに説明さらえる装置機能のどれかを実施するためのコンピュータプログラム及びコンピュータプログラム製品、及びここに説明される方法のどれかを実施するため、及び／またはここに説明される装置機能のどれかを具体化するためのプログラムをその上に記憶しているコンピュータ読み取り可能媒体も提供する。
【０２２１】
発明は、ここに説明される方法のどれかを実施するため、及び／またはここに説明される装置機能のどれかを具体化するためのコンピュータプログラムを具現するための信号、このような信号を伝送する方法、及びここに説明される方法のどれかを実施するため、及び／またはここに説明される装置機能のどれかを具体化するためのコンピュータプログラムをサポートするオペレーティングシステムを有するコンピュータ製品も提供する。
【０２２２】
追加の従来の技術の考慮を始めると、ビデオカセットレコーダ及びオーディカセットレコーダも遍在するようになり、家庭環境と専門環境の両方で応用されている。しかしながら、それらのおもな欠点は、データ信号がテープ上に記録されるため、連続的にだけアクセスできるという点である。テープは、そのセクションが読み飛ばされなければならない場合、あるいはレコーディングのある特定の部分にアクセスするためには高速で巻き取られなければならない。これは、相対的にゆっくりとした手順である。さらに、家庭用の用途で最も一般的に見られる特に安価な型の多くのテープレコーダは、（スローモーションまたは加速されたモーションエフェクトのために）それが録音された速度以外の速度でレコーディングを、あるいはディスプレイのかなりの歪みなくレコーディングの単一の凍結されたコマを再生することはできない。
【０２２３】
高容量大容量データ記憶装置、及び特にハードディスクドライブは、現在では、特にこのような信号がＭＰＥＧなどの効率的な圧縮アルゴリズムを使用して符号化されるときに、それらがかなりの量のデジタル的に符号化されたビデオ信号及び／または音声信号を記憶できるほど大きな記憶装置容量を有している。デバイスに記憶されるデータの指定された断片は、少なくとも人間のオペレータの観点からは、元来瞬時にアクセスできる。このような装置の可用性が、信号がこのような大容量記憶装置に記憶されるビデオ信号及び／または音声信号を記録、再生するための装置の開発につながってきた。
【０２２４】
このような大量記憶装置を使用するビデオ及び／または音声プレイバック装置の実現は、従来のテープをベースにしたビデオレコーダ及び／またはオーディオレコーダよりはるかに大きな操作上の柔軟性をユーザに提供する可能性を有し、従来のテープレコーダの能力を超える一連の能力を有するビデオ及び／または音声プレイバック製品を提供する機会を開発者に与える。開発者が、このようなプレイバック装置によって提供されるこれらの機能を使用利用することができる手段を提供することが、本発明の追加の目的である。
【０２２５】
したがって、発明の追加の態様においては、音声／画像ビットストリームの転送を制御するためのコマンドが提供され、そこでは転送速度はパラメータとして表される。
【０２２６】
転送は、好ましくは、大容量記憶装置から（ＭＰＥＧデコーダ及び／またはビデオ出力装置などの）オーディオビジュアルプレイバック装置への音声／画像データの再生である。代わりに（及び排他的にではなく）、転送は、例えば生放送（または他の）信号ソースから大容量記憶装置への音声／画像データのレコーディングであってよい。
【０２２７】
コマンドのパラメータを介して転送速度を設定できることにより、数多くの異なる効果を同じコマンドに対する呼び出しで達成することができる。このようなコマンドは、例えば、仮想（または実）ビデオレコーダまたは他のランダムアクセス記憶装置または順次アクセス記憶装置の動作を制御するために使用できるだろう。後述されるｓｅｔ＿ｓｐｅｅｄ（）コマンドは、おもに音声／画像データの再生に適用されるこのようなコマンドの例である。
【０２２８】
ここに使用されるような用語「コマンド」は、好ましくはメモリ内の電気的な衝撃の形、または例えば適切なデータキャリヤ上でのルーチンのレコーディングなどのさらに恒久的な形を取る、指定された関数を実施するように設定されたソフトウェアルーチンの物理的な現れを好ましくは意味する。好ましくは、ルーチンの該現れはプロセッサによって即座に実行可能であり、例えばオブジェクトコードとして記憶される。用語は、ルーチンを実行するために物理的に具現される命令の形を取るか、あるいはルーチンを実行させるように設計される――遠隔手続き呼び出し（ＲＰＣ）などの――実際の信号としてこのようなルーチンの実際の呼び出しに及ぶように拡大されてもよい。
【０２２９】
速度は、正、ゼロ及び／または負であってよい。転送が再生である場合に、速度が正であると、再生は、好ましくは通常のプレイバック、スロープレイバック、早送り、及び停止／休止の１つだろう。代わりに、速度が負であると、再生は、早巻き戻しとスロー巻き戻しの１つだろう。したがってこのような速度の変化を可能とすることによって、コマンドによって提供される柔軟性を高めることができる。
【０２３０】
速度の範囲がハードウェアまたは他の考慮事項により制限される場合、最大速度は好ましくは通常の転送速度の２倍、５倍、１０倍、５０倍、１００倍または５００倍の同等物である。同様に、最小速度は、通常の転送速度（０以上という最小値は、再生のケースでストリームを「巻き戻す」可能性を妨げ、レコーディングのケースで、０以下の最小値は音声／画像ビットストリームを逆に記憶する可能性を開く）の１倍、０倍、−１倍、−２倍、−５倍、−１０倍、−５０倍、−１００倍または−５００倍の同等物であってよい。速度の範囲は、連続範囲であってよく、おそらくハードウェアの制限を考慮に入れ、例えばさまざまな転送速度、または例えば速度の離散集合の間での円滑な遷移を可能にする。コマンドのパラメータは、事実上、コマンドの実行中、またはその後に、適宜に、速度の離散集合の１つに変換される任意の速度であってよい。
【０２３１】
速度は、好ましくは、（再生のケースでの通常のプレイバック速度などの）通常の転送速度の倍数によってパラメータに関係付けられる。手続きは、例えばビットストリームの再生のための対応するビットレートを計算する必要がない可能性があるため、これにより、コマンドを呼び出す手続きを大幅に簡略化できる。レコーディングのケースでは、パラメータは、例えば、所望されるフレームレート（それが通常のフレームレートより低い場合には、コマンドは、記憶されているビットストリームからフレームを適切な速度で廃棄させるだろう）を指定してよい。
【０２３２】
例えば、速度が通常の転送速度によって乗算されるパラメータに等しいと、１というパラメータは通常の転送速度に同等となり、０というパラメータは転送を休止させる結果となり、１より大きいパラメータは、例えば、さらに低い品質／速度での（再生のケースでは）早送りまたは（レコーディングケースでは）レコーディングに相当するだろう。代わりに、速度とパラメータ間にさらに複雑な関係がある場合があり、それによって定数値が、例えば速度またはパラメータのどちらかから差し引かれるだろう。
【０２３３】
好ましくは、転送が発生する位置は、パラメータとして表される。これが、音声／画像ビットストリームの転送で追加の柔軟性を可能にする。転送が音声／画像データの再生である場合には、転送が発生する位置は、好ましくは音声／画像データの中への偏位であり、他のデータ倍数を考慮して、時間帯、またはデータのフレームを考慮して最も近いビット、バイトに設定されてよいか、あるいはそれ以外の場合またはさらに番組またはトラック番号という点で指定されてよい。それ以外の場合、例えば、レコーディングケースでは、位置は大容量記憶装置上の位置を基準にする場合があり、レコーディングが開始するまたは続行する位置を設定する。
【０２３４】
この重要な特徴も独立して提供される。したがって、発明の追加の態様においては、音声／画像ビットストリームの転送を制御するためのコマンドが提供され、そこでは転送が発生する位置はパラメータとして表される。後述されるｓｅｔ＿ｐｏｓｔ（）ルーチンは、このような関数の例である。
【０２３５】
再生が発生する位置を指定するパラメータは、呼び出しルーチンを、時間をビットストリーム内のデータオフセットに関係付ける計算から解放できる時間の基準に関係付けられてよい。
【０２３６】
代わりに、再生が発生する位置を指定するパラメータがビットストリーム内のオフセット（または例えば大容量記憶装置上の場所）に関係付けられる場合、コマンドは、より簡略に実現することができ、メモリの保存を引き起こし、実行の速度を加速する。
【０２３７】
発明の別の態様においては、前述されたように少なくとも１つのコマンドを備える、コマンドセットが提供される。これは、前述されたコマンドのどれかをビルディングブロックとして使用することにより、広範囲のさらに特殊化したコマンドを容易に実現できるようにする。
【０２３８】
この重要な特徴も独立して提供され、したがって再生が発生する位置をパラメータとして表させるコマンド、及び転送速度をパラメータとして表させるコマンドを備える、音声／画像ビットストリームの転送を制御するためのコマンドセットも提供される。
【０２３９】
発明の追加の関係する態様においては、音声／画像ビットストリームの転送を制御するためのコマンドが提供され、該コマンドは前述されたように少なくとも１つのコマンドを呼び出すように適応される。
【０２４０】
コマンドは、音声／画像ビットストリームの転送に関係する状態に従ってさまざまな追加のコマンドを選択的に呼び出すように適応されてよい。このような状態は、例えば、転送が休止されたかどうか（言い換えると、転送速度がゼロであったかどうか）であるだろう。この場合、コマンドは、例えば、転送が休止されると、１つの追加のコマンドを、及び転送が進行しているときには、異なる追加コマンドを呼び出すことができるだろう。
【０２４１】
それらは前述された状態の一定の値を考慮に入れる必要なく作成できるだろうため、これは、追加コマンドを簡略化できるようにする。
【０２４２】
代わりにまたはさらに、コマンドは、通常の転送速度に同等なパラメータで、前述されたように（好ましくは転送速度を設定するための）コマンドを呼び出し、音声／画像ビットストリーム内の位置に同等なパラメータで、前述されたように（好ましくは再生の位置を設定するための）コマンドを呼び出すように適応されてよい。好ましくは、このようなコマンドは、音声／画像ビットストリーム内でプレイバックを開始するように適応され、それ自体、「プレイ」コマンドまたは「シークアンドプレイ」コマンドに対応してよい、あるいは「プレイ」コマンドまたは「シークアンドプレイ」コマンドによって呼び出されてよい。また、このようなコマンドは、好ましくは、呼び出されたコマンドの一方または両方の少なくとも１つのパラメータと同じフォーマットの少なくとも１つのパラメータを有する。
【０２４３】
コマンドは、ゼロ速度に同等なパラメータで、前述されたように（好ましくは転送速度を設定するための）コマンドを呼び出すように適応されてよい。コマンドは、好ましくは、音声／画像ビットストリームのプレイバックを停止または休止するように適応され、それ自体、「休止」コマンドまたは「停止」コマンドに対応してよい、あるいは「休止」コマンドまたは「停止」コマンドによって呼び出されてよい。呼び出されたコマンドは、音声／画像ビットストリームのディスプレイも中止させてよい。
【０２４４】
コマンドは、代わりに、通常より大きいプレイバック速度に同等なパラメータで、前述されたように（好ましくは転送速度を設定するための）コマンドを呼び出すように適応されてよい。好ましくは、コマンドは、音声／画像ビットストリームを早送りするように適応され、それ自体、「早送り」コマンドに対応してよい、あるいは「早送り」コマンドによって呼び出されてよい。さらに、コマンドは、例えば、「早送り」ボタンが長く押されるほど、より速くビットストリームを再生させるための別のパラメータで、コマンドをさらに呼び出すように適応されてよい。
【０２４５】
コマンドは、通常より小さい転送速度に同等なパラメータで、前述されたように（好ましくは転送速度を設定するための）コマンドを呼び出すように適応されてよい。このコマンドは、スローモーションで音声／画像ビットストリームを再生するように適応され、それ自体、「スローモーション」コマンドに対応してよい、あるいは「スローモーション」コマンドによって呼び出されてよい。
【０２４６】
コマンドは、代わりにまたはさらに、負のプレイバック速度に同等なパラメータで、前述されたように（好ましくは転送速度を設定するための）コマンドを呼び出すように適応されてよい。好ましくは、このコマンドは、音声／画像ビットストリームを逆に再生するように適応され、それ自体「巻き戻し」コマンドに対応してよい、あるいは「巻き戻し」コマンドによって呼び出されてよい。
【０２４７】
さらに、コマンドは、通常のプレイバック速度に同等なパラメータで、前述されたように（好ましくは転送速度を設定するための）コマンドを呼び出すように適応されてよい。好ましくは、このコマンドは、音声／画像ビットストリームのプレイバックを再開するように適応され、それ自体「再生」コマンド、「休止」コマンド、または「休止解除」コマンドに対応してよい、あるいは「再生」コマンド、「休止」コマンド、または「休止解除」コマンドによって呼び出されてよい。
【０２４８】
コマンドは、場所に同等なパラメータで、前述されたように（好ましくは再生の位置を設定するための）コマンドを呼び出すように適応されてよい。好ましくは、このコマンドは、音声／画像ビットストリーム内の場所にジャンプするように適応され、それ自体、「次章アップ」コマンド、「前章」コマンド、「プレイ」コマンド、「次索引」コマンド、または「前索引」コマンドに対応してよい、あるいは次章アップ」コマンド、「前章」コマンド、「プレイ」コマンド、「次索引」コマンド、または「前索引」コマンドによって呼び出されてよい。
【０２４９】
コマンドは、該音声／画像ビットストリームまたは追加音声／画像ビットストリームを記憶させるように適応されてよい。このようにして、柔軟性は、ビットストリームを再生するためのコマンドを、該ビットストリームまたは追加ビットストリームを記憶する（好ましくは記録する）能力と結合することによって達成できる。
【０２５０】
発明の関係するにおいては、音声／画像ビットストリームの転送を制御するためのコマンドが提供され、該コマンドは、（特に、追加コマンドを呼び出すコマンドを含む）前述されたように少なくとも１つのコマンドを呼び出すように適応される。
【０２５１】
最高３つのレベルの抽象以上を提供するにも関わらず、これは、追加の計算上の簡略さという優位点を提供するために、これは本発明に従っていることが分かった。
【０２５２】
特に、コマンドがユーザが選択可能な音声／画像制御動作に対応する場合、コマンドの各層は、それ自体相対的に簡略であり、上及び下の層と相対的に簡略なインタフェースを有するが、単一の高レベルユーザ（または他の）要求に応えて複雑な低レベルのアクションを発生させる。
【０２５３】
発明の追加態様においては、ここに説明されるようなコマンドを制御基準に比較することと、コマンドが該制御基準に一致するかどうかに従って追加コマンドを生成することと、コマンドが該制御基準に一致しない場合に追加コマンドを生成することとを備える、音声／画像ビットストリームの転送を制御する方法が提供される。
【０２５４】
好ましくは、コマンドは、前述されたように生成される追加コマンドである。
【０２５５】
したがって、無効なまたは所望されていないコマンドあるいはコマンドのシーケンスは、修正されてよいか、あるいはデフォルトコマンドがそれらの代わりに置換されてよい。
【０２５６】
好ましくは、該追加コマンドは制御基準に比較されてから、該追加コマンドは、それが制御基準に一致するかどうかに従って修正される。
【０２５７】
該追加コマンドと制御基準の比較、及び該追加コマンドの修正は、繰り返しの最大数まで、または制御基準に一致する追加コマンドが生成されるまで無期限に繰り返されてよい。
【０２５８】
好ましくは、制御基準は、音声／画像ビットストリームの転送の、好ましくはコマンドの受信時に発生する転送の特性に依存している。
【０２５９】
したがって、音声／画像ビットストリームの転送に対するさらに大きな制御は、コマンドのシーケンスの受信時、あるいは音声／画像ビットストリームの転送の現在の特性に相対的である動作を指定するコマンドの受信時に得られてよい。
【０２６０】
例えば、コマンド一定のシーケンスまたは許されていいないまたは望ましくないビットストリームでの動作は、検出され、置換されてよい。
【０２６１】
例えば、ビットストリーム中の点にジャンプしてから、早送りすることは許されておらず、早送りするためのコマンドは、それがビットストリーム中の点にジャンプするためのコマンドの直後に受信されると、再生するためのコマンドで置き換えられてよい。
【０２６２】
他のコマンドは、音声／画像ビットストリームの転送の現在の特性に関連してよい。例えば、コマンドは、現在位置を基準にした位置まで前方へジャンプすることを指定してよい。このコマンドの容認可能性は、コマンド自体及び現在位置の両方に依存してよい。
【０２６３】
好ましくは、音声／画像ビットストリームの転送の特性は、転送速度及びまたはビットストリーム中の位置である。
【０２６４】
好ましくは、制御基準は、条件付きアクセス及びまたは親制御データに依存している。
【０２６５】
発明の追加態様においては、転送速度を設定するためのコマンドを呼び出すことと、パラメータとして転送速度をコマンドに渡すことを備える、音声／画像ビットストリームの転送を制御する方法が提供される。
【０２６６】
発明の別の態様においては、再生が発生する位置を設定するためのコマンドを呼び出すことと、該位置をパラメータとして渡すことを備える、音声／画像ビットストリームの転送を制御する方法が提供される。
【０２６７】
発明の追加の関係する態様においては、前述されたような少なくとも１つのコマンドを備え、好ましくは、ここに説明されるように方法を実施するように適応されるオペレーティングシステムが提供される。
【０２６８】
発明の別の態様においては、前述されたような少なくとも１つのコマンドを備え、好ましくは、ここに説明されるように方法を実施するように適応される受信機／デコーダが提供される。
【０２６９】
発明のまだ追加の態様においては、前述されたように少なくとも１つのコマンドを呼び出すように適応される受信機／デコーダが提供される。
【０２７０】
発明の別の態様においては、前述されるような少なくとも１つのコマンドを備える、コンピュータプログラム製品が提供される。
【０２７１】
発明の追加の態様においては、前述されるようなコンピュータプログラム製品を備える、コンピュータ読み取り可能媒体が提供される。
【０２７２】
発明の別の態様においては、前述されたようにコンピュータプログラム製品を具体的に具現する信号が提供される。
【０２７３】
発明の追加態様においては、音声／画像データを受信するための（入力などの）手段、音声／画像データを出力するための（出力などの）手段、及び前述されたように少なくとも１つのコマンドを実行するための、及び／または前述されたように方法を実施するための（プロセッサ及び関連付けられるメモリなどの）手段を備える、音声／画像データを処理するための装置が提供される。
【０２７４】
発明の関連する態様においては、入力、出力、及びプロセッサと関連付けられるメモリを備える、音声／画像データを処理するための装置が提供され、該プロセッサは、前述されたように少なくとも１つのコマンドを実行するように適応され、及び／またはここに説明されるように方法を実施するように適応される。
【０２７５】
発明の別の態様においては、前述されたような装置を備える、音声／画像処理装置が提供される。
【０２７６】
発明の別の態様においては、前述されたような受信機／デコーダを備える、放送システムが提供される。
【０２７７】
発明の別の態様においては、ビットストリーム中のタイムオフセットをファイル内のデータオフセットにマッピングする索引を備える索引表が提供される。
【０２７８】
好ましくは、索引表は、ここに説明されるようなテーブルである。
【０２７９】
発明の追加態様においては、ユーザ入力に応えてクライアントからコマンドを受信するように適応されるハードディスクビデオレコーダ（ＨＤＶＲ）が提供される。このようなコマンドは、ある特定の番組の録画を開始するためのコマンドであってよい。該クライアントは、例えば、パーソナルビデオレコーダ（ＰＶＲ）アプリケーションであってよい。
【０２８０】
好ましくは、ＨＤＶＲは、並列でサービスデバイス及び記憶装置、好ましくはファイルシステムライブラリと対話する。好ましくは、このような対話は記録されるまたはプレイバックされるビットストリームを処理する受信機／デコーダの部分をセットアップし、同期させ、及び／またはハードディスク上の適切な場所で録画動作またはプレイバック動作を調整する。
【０２８１】
好ましくは、ハードディスクビデオレコーダ（ＨＤＶＲ）は、さらに、特定の番組の録画を開始するためのコマンドを受信するように適応される。
【０２８２】
ハードディスクビデオレコーダ（ＨＤＶＲ）は、デバイス、好ましくはサービスデバイスと対話する、及び／またはファイルシステムライブラリと対話するように適応されてよい。
【０２８３】
好ましくは、ハードディスクビデオレコーダ（ＨＤＶＲ）は、サービスデバイス及び／またはファイルシステムライブラリと対話するために、追加コマンドを送信または受信するように適応されてよい。
【０２８４】
コマンドまたは該追加コマンドは、追加コマンドの生成を引き起こしてよい。
【０２８５】
好ましくは、コマンドまたは該追加コマンドは、ここに説明されるようなコマンドである。
【０２８６】
発明は、添付図面を参照して、実質的にここに説明されるような方法及び／または装置まで拡大する。
【０２８７】
発明のある態様における任意の特徴は、適切な組み合わせで発明の他の態様に適用されてよい。特に、方法態様は、装置態様に適用されてよく、装置態様は方法態様に適用されてよい。
【０２８８】
さらに、ハードウェア内で実現される機能は、一般的にはソフトウェア内で実現されてよく、逆の場合も同じであってよい。ソフトウェア機能及びハードウェア機能に対する参照は、この点で相応して構築されなければならない
【発明の実施の形態】
本発明の好ましい機能は、ここで、添付図面を参照して純粋に一例として説明されるだろう。
【０２８９】
システム概要
デジタルテレビシステム５００の概観は、図１に示されている。後述されるように、システム５００は、すべて後述されるように、放送センタ１０００、受信機／デコーダ２０００、該受信機／デコーダのフトウェア／ハードウェアアーキテクチャ３０００、対話型システム４０００、及び条件付きアクセスシステム５０００を備える。
【０２９０】
システム５０００は、圧縮されたデジタル信号を伝送するために既知のＭＰＥＧ−２圧縮システムを使用するおもに従来のデジタルテレビシステム５０２を含む。さらに詳細には、放送センタ１０００内のＭＰＥＧ−２圧縮機１０１０は、デジタル信号ストリーム（一般的には、ビデオ信号のストリーム）を受信する。圧縮機１０１０は、マルチプレクサ及びスクランブラ１０３０にリンケージ１０２０によって連結される。
【０２９１】
マルチプレクサ１０３０は、複数の追加の入力信号を受信し、トランスポートストリームをアセンブルし、言うまでもなく通信リンクを含む多岐に渡る形式を取ることができるリンケージ１０２２を介して放送センタの送信機１０１０に圧縮されたデジタル信号を伝送する。送信機５１０は、衛星トランスポンダ５２０に向かってアップリンク５１４を介して電磁信号を伝送し、そこで信号は電子的に処理され、従来はエンドユーザによって所有または賃借りされる放物面反射器の形を取る地球受信機５１２に概念上のダウンリンク５１６を介して一斉送信される。言うまでもなく、地上放送、ケーブル伝送、組み合わされた衛星／ケーブルリンク、電話網等のデータの伝送のための他のトランスポートチャネルも考えられる。
【０２９２】
受信機５１２によって受信された信号は、エンドユーザによって所有または借りられており、エンドユーザのテレビセット１００００に接続されている統合型受信機／デコーダ２０００に伝送される。該受信機／デコーダ２０００は、圧縮されたＭＰＥＧ−２信号をテレビセット１００００用のテレビ信号に復号する。別個の受信機／デコーダが図１に図示されているが、該受信機／デコーダは、統合型デジタルテレビの一部であってもよい。ここに使用されるように、用語「受信機／デコーダ」は、セットトップボックスなどの別個の受信機／デコーダ、及び受信機／デコーダがそこに統合されたテレビを含む。
【０２９３】
受信機／デコーダ２０００内には、視聴覚データ及び他のデータを記憶できるハードディスク２１００が備えられる。これが、受信機／デコーダによって受信される番組用の高度なレコーディング機構及びプレイバック機構を与え、電子番組表データなどの大量の他の種類のデータも受信機／デコーダに記憶できるようにする。
【０２９４】
受信機／デコーダ内のコンテンツ管理保護システム（ＣＭＰＳ）２３００（図示されていない）は、ハードディスク（または他の記憶装置）でのデータのレコーディング及びプレイバックを安全に且つ柔軟に制御する能力を提供する。
【０２９５】
多重チャネルシステムにおいては、マルチプレクサ１０３０が数多くの並列ソースから受信される音声情報とビデオ情報を処理し、対応する数のチャネルに沿って情報を一斉送信するために送信機５１０と対話する。視聴覚情報に加えて、メッセージまたはアプリケーションまたは他の種類のデジタルデータが、伝送されたデジタル音声情報及びビデオ情報とインタレースされるこれらのチャネルのいくつかまたはすべてに導入されてよい。
【０２９６】
対話型システム４０００は、マルチプレクサ１０３０及び受信機／デコーダ２０００に接続され、部分的には放送センタ内に、部分的には受信機／デコーダ内に位置する。それが、エンドユーザが、バックチャネル５７０を介して多様なアプリケーションと対話できるようにする。該バックチャネルは、例えば、公衆加入電話網（ＰＳＴＮ）チャネル（例えば、モデム化されたバックチャネル）または帯域外（ＯＯＢ）チャネルであってよい。
【０２９７】
やはりマルチプレクサ１０３０及び受信機／デコーダ２０００に接続され、再び部分的に放送センタ内に、部分的に受信機／デコーダ内に位置する条件付きアクセスシステム５０００によって、エンドユーザは、１社または複数の放送供給者からのデジタルテレビ放送にアクセスできる。商業的なオファー（つまり、放送供給者によって販売される１つまたは複数のテレビ番組）に関係するメッセージを解読できるスマートカードを受信機／デコーダ２０００の中に差し込むことができる。受信機／デコーダ２０００及びスマートカードを使用し、エンドユーザは加入モードまたは有料視聴モードのどちらかで商業的なオファーを購入してよい。一般的には、これは、対話型システム４０００によって使用されるバックチャネル５７０を使用して達成される。
【０２９８】
前述されたように、システムによって伝送される番組は、マルチプレクサ１０３０でスクランブルされ、指定される伝送に適用される条件及び暗号化キーは、アクセス制御システム５０００によって決定される。このようにしてスクランブルされたデータを伝送することは、有料テレビの分野ではよく知られている。一般的には、スクランブルされたデータは、該データの逆スクランブルのための制御ワードとともに伝送され、該制御ワード自体が、いわゆる活用キーによって暗号化され、暗号化された形で伝送される。
【０２９９】
それから、スクランブルされたデータ及び暗号化された制御ワードが、暗号化された制御ワードを解読し、その後で伝送されたデータを逆スクランブルするために、受信機／デコーダ内に差し込まれたスマートカード上に記憶される活用キーの同等物にアクセスする受信機／デコーダ２０００によって受信される。会費を納付し終わった加入者は、例えば、放送月次ＥＭＭ（エンタイトルメント管理メッセージ）の中で、伝送の視聴を可能にするために暗号化された制御ワードを解読するのに必要な活用キーを受信するだろう。
【０３００】
図２は、圧縮されたデジタル信号用の放送媒体としてケーブルネットワークを活用するデジタルテレビシステム５０４の代替実施形態を描く。この図中、類似する部分は類似する番号で示される。
【０３０１】
衛星トランスポンダ及び伝送局と受信局は、ケーブルネットワーク５５０によって置き換えられる。さらに、この特定の実施形態においては、受信機／デコーダ２０００と対話型システム４０００と条件付アクセスシステム５０００間のモデム化されたバックチャネルが削除され、それぞれケーブルネットワーク５５０と条件付きアクセスシステム５０００と対話型システム４０００の間のリンケージ５５４、５５６によって置き換えられる。受信機／デコーダ２０００は、このようにして、それが放送センタからデータを受信するにつれて、同じリンクを介してデータを送受できるようにするケーブルモデムまたは他の手段を活用して、ケーブルネットワーク５５０を介して他のシステムと通信する。
【０３０２】
ケーブルネットワーク５５０は、専用接続、インターネット、市内ケーブル分散ネットワーク、無線接続、あるいは前記の任意の組み合わせなどの広域ネットワーク（ＷＡＮ）の任意の形式を取ってよい。本実施形態においては、ハイブリッドファイバ同軸（ＨＦＣ）ネットワークが使用される。受信機／デコーダ２０００とテレビシステムの他の構成要素間の多様な通信の手段が取り替え可能であることが認識される。
【０３０３】
条件付きアクセスシステム
図３に関して、概観では、条件付きアクセスシステム５０００は、加入者許可システム（ＳＡＳ）５２００を含む。該ＳＡＳ５２００は、１つまたは複数の加入者管理システム（ＳＭＳ）１１００に、放送供給者ごとに１つのＳＭＳ、ＴＣＰ−ＩＰリンクまたは他の種類のリンクであってよいリンク１０４４によって接続される。代わりに、１つのＳＭＳは、２つの商業事業者の間で共用できるか、あるいは一人の事業者が２つのＳＭＳを使用できる等だろう。
【０３０４】
「マザー」スマートカード５１１０を活用する暗号化装置５１００の形を取る第１暗号化装置は、リンケージ１０４２によってＳＡＳに接続される。やはりマザースマートカード５１１２を活用する暗号化装置５１０２の形を取る第２暗号化装置は、リンケージ１０４０によってマルチプレクサ１０３０に接続される。受信機／デコーダ２０００は、「ドーター」スマートカード５５００を受け入れる。受信機／デコーダは、通信サーバ１２００及びモデム化されたバックチャネル５７０を介してＳＡＳ５２００に直接的に接続される。ＳＡＳは、特に、依頼に応じて加入権をドータ−スマートカードに送信する。
【０３０５】
好ましい実施形態の変型において、インターネットケーブル接続は、ＰＳＴＮ５７０及び通信サーバ１２００を補足するか、置き換えるかのどちらかである。
【０３０６】
スマートカードは、１つまたは複数の商業的な事業者からの機密情報を含む。「マザー」スマートカードは、さまざまな種類のメッセージを暗号化し、「ドータ−」スマートカードは、それらがそうする権利を有する場合には該メッセージを平文に直す。
【０３０７】
図３に関して、放送センタにおいて、デジタルビデオ信号は、ＭＰＥＧ−２圧縮機１０１０を使用して最初に圧縮される（またはビットレート減速される）。それから、この圧縮された信号は、他の圧縮データなどの他のデータと多重化されるために、マルチプレクサとスクランブラ１０３０に伝送される。
【０３０８】
スクランブラは、スクランブルプロセスで使用され、マルチプレクサ１０３０内のＭＰＥＧ−２ストリームに含まれる制御ワードを生成する。該制御ワードは内部で生成され、エンドユーザの統合型受信機／デコーダ２０００が番組を逆スクランブルできるようにする。
【０３０９】
番組がどのように商品化されているのかを示すアクセス基準も、ＭＰＥＧ−２ストリームに追加される。番組は数多くの「加入」モードの１つ及び／または数多くの「有料視聴」（ＰＰＶ）モードまたはイベントの１つで商品化されてよい。加入モードでは、エンドユーザは１つまたは複数の商業的なオファー、つまり「ブーケ」に加入し、このようにしてそれらのブーケの内側のあらゆるチャネルを見る権利を得る。有料視聴モードでは、エンドユーザは、自分が希望するとおりにイベントを購入する能力を備える。
【０３１０】
制御ワードとアクセス基準の両方とも、エンタイトルメント制御メッセージ（ＥＣＭ）を構築するために使用される。これは、１つのスクランブルされた番組について送信されるメッセージである。該メッセージは、（番組の逆スクランブルに対処する）制御ワード及び放送プログラムのアクセス基準を含む。アクセス基準及び制御ワードは、リンケージ１０４０を介して第２暗号化装置５１０２に伝送される。この装置では、ＥＣＭが生成、暗号化、及びマルチプレクサとスクランブラ１０３０に伝送される。
【０３１１】
データストリーム中で放送供給者によって一斉送信される各サービスは、数多くの別個の成分を備える。例えば、テレビ番組は、ビデオ成分、音声成分、字幕成分等を含む。これらの成分のそれぞれが、個別にスクランブルされ、それ以降の放送のために暗号化される。サービスのそれぞれのスクランブルされた成分という点で、別個のＥＣＭが必要とされる。
【０３１２】
マルチプレクサ１０３０は、暗号化されたＥＭＭを備える電気信号をＳＡＳ５２００から、暗号化されたＥＣＭを第２暗号化装置５１０２から、及び圧縮された番組を圧縮機１０１０から受信する。マルチプレクサ１０３０は、番組をスクランブルし、スクランブルされた番組、暗号化されたＥＭＭ及び暗号化されたＥＣＭを電気信号として、例えば図１に図示されるような衛星システム、または他の放送システムであってよい放送システム６００に伝送する。受信機／デコーダ２０００は、暗号化されたＥＭＭ及び暗号化されたＥＣＭを用いてスクランブルされた番組を得るために信号を多重分離する。
【０３１３】
受信機／デコーダは、放送信号を受信し、ＭＰＥＧ−２データストリームを抽出する。番組がスクランブルされている場合、受信機／デコーダ２０００はＭＰＥＧ−２ストリームから対応するＥＣＭを抽出し、エンドユーザの「ドータ−」スマートカード５５００にＥＣＭを渡す。これが、受信機／デコーダ２０００のハウジングの中に差し込まれる。ドータ−スマートカード５５００は、エンドユーザがＥＣＭを「平文に直す」及び番組にアクセスする権利を有するかどうかを制御する。有さない場合には、番組を逆スクランブルできない旨を示すために、否定的なステータスが受信機／デコーダ２０００に渡される。エンドユーザが実際に権利を有する場合には、ＥＣＭは平文に直され、制御ワードが抽出される。それから、デコーダ２０００は、この制御ワードを使用して番組を逆スクランブルする。ＭＰＥＧ−２ストリームは復元され、テレビセット１００００への前方への伝送のためにビデオ信号に変換される。
【０３１４】
番組がスクランブルされていない場合、ＥＣＭはＭＰＥＧ−２ストリームとともに伝送されておらず、受信機／デコーダ２０００はデータを復元し、テレビセット１００００への伝送のために、信号をビデオ信号に変換する。
【０３１５】
加入者管理システム（ＳＭＳ）１１００は、特にエンドユーザファイル、（料金表と広告などの）商業的なオファー、加入、ＰＰＶ詳細、及びエンドユーザ消費と許可に関するデータのすべてを管理するデータベース１１５０を含む。ＳＭＳは、ＳＡＳから物理的に遠い可能性がある。
【０３１６】
ＳＭＳ１１００は、エンドユーザに伝送されるエンタイトルメント管理メッセージ（ＥＭＭ）に対する修正またはその作成を暗示するメッセージをＳＡＳ５２００に伝送する。ＳＭＳ１１００は、ＥＭＭに対する修正またはＥＭＭの作成を暗示しないが、（製品注文時にエンドユーザに与えられる許可に、またはエンドユーザが請求を受ける額に関する）エンドユーザの状態の変化だけを暗示するメッセージもＳＡＳ５２００に伝送する。ＳＡＳ５２００は、ＳＭＳ１１００に（一般的には、電話のかけ直し情報、または料金請求書作成発行情報などの情報を要求する）メッセージも送信し、その結果２者の間の通信が双方向であることは明らかであろう。
【０３１７】
受信機／デコーダ
図４を参照すると、受信機／デコーダ２０００の多様な要素が、ここで機能ブロックに関して説明されるだろう。
【０３１８】
例えば、デジタルセットトップボックス（ＤＳＴＢ）であってよい受信機／デコーダ２０００は、両方とも関連付けられたメモリ要素（図示されていない）を有し、コプロセッサバス２００６によって接合されている中央ホストコンピュータ２００２及びデジタルＴＶコプロセッサ２００４を備える。該コプロセッサ２００４は、ＵＳＢインタフェース２００７、直列インタフェース２０７２、並列インタフェース（図示されていない）、（図１のモデムバックチャネル５７０に接続される）モデム２０７４、及びデコーダのフロントパネル２０５４上のスイッチ接点から入力データを受信するように適応される。
【０３１９】
受信機／デコーダは、さらに、赤外線リモートコントローラ２０８０（及びオプションでブルーツースがイネーブルされたデバイスなどの他の無線周辺機器２０８２）から入力を受信するように適応され、それぞれ銀行スマートカードと加入スマートカード２０６０、２０６２を読み取るように適応された２台のスマートカード読取装置２０５０、２０５２も所有する。加入スマートカード読取装置２０５２は、必要な制御ワードをデマルチプレクサ／デスクランブラ／リマルチプレクサ（装置２０１０に与え、暗号化された放送信号を逆スクランブルできるようにするために、差し込まれた加入カード２０６２及び条件付きアクセス装置（図示されていない）と係合する。デコーダは、復調器／デスクランブラ装置２０１０によってフィルタリングされ、多重分離される前に、衛星伝送を受信し、復調するために、従来のチューナ２０１６及び復調器２０１２も含む。特に、第２チャネルを第１と並行して受信し、復号できるようにするために、第２チューナ２０１８及び第２復調器２０１４も備えられる。
【０３２０】
ハードディスク２１００も備えられ、受信機／デコーダによって受信され、生成される番組及びアプリケーションデータの記憶を可能にする。２台のチューナ２０１６、２０１８、２台の復調器２０１２、２０１４、デスクラブラ／デマルチプレクサ／再マルチプレクサ２０１０及びデータでコーダ２０２４と音声デコーダ０２６とともに、高度なレコーディング及びプレイバック機能が提供され、追加の番組が見られている間の１つまたは複数の番組の同時録画、及びすべて並行して発生する、ハードディスクに対する及びハードディスクからの、ディスプレイ装置に対する及びディスプレイ装置へのより一般的な転送、及び／または入力と出力を可能にする。
【０３２１】
受信機／デコーダ内の音声出力２０３８及びビデオ出力２０４０は、それぞれＰＣＭミキサー２０３０と音声ＤＡＣ２０３４、ＭＰＥＧビデオデコーダ２０２８、グラフィックエンジン２０３２、及びＰＡＬ／ＳＥＣＡＭ２０３６によって供給される。言うまでもなく、代替出力または相補的な出力が提供されてよい。
【０３２２】
この説明で使用されるように、好ましくは、アプリケーションは、好ましくは受信機／デコーダ２００００の高水準機能を制御するためのコンピュータコードの部分である。例えば、エンドユーザがリモートコントローラ２０８０のフォーカスをテレビセット（図示されていない）の画面上で見られるボタンオブジェクトの上に配置し、妥当性検査キーを押すと、該ボタンに関連付けられる命令シーケンスが実行される。アプリケーション及び関連付けられるミドルウェアは、ホストプロセッサ２００２によって実行され、遠隔手続き呼び出し（ＲＰＣ）は、必要に応じて及び必要時に、コプロセッサバス２００６を横切ってデジタルＴＶコプロセッサ２００４に対して行われる。
【０３２３】
対話型アプリケーションは、メニューを提案し、エンドユーザの要求でコマンドを実行し、アプリケーションの目的に関係するデータを提供する。アプリケーションは常駐アプリケーション、つまり受信機／デコーダ２０００のＲＯＭ（またはＦＬＡＳＨまたは他の不揮発性メモリ）に記憶されてよいか、あるいは受信機／デコーダ２０００のＲＡＭ、ＦＬＡＳＨメモリ、またはハードディスクに一斉送信され、ダウンロードされてよい。
【０３２４】
アプリケーションは、受信機／デコーダ２０００内のメモリ場所に記憶され、リソースファイルとして表される。リソースファイルは、グラフィックオブジェクト記述装置ファイル、変数ブロック装置ファイル、命令シーケンスファイル、アプリケーションファイル、及びデータファイルを備える。
【０３２５】
受信機／デコーダは、少なくとも１つのＲＡＭボリューム、ＦＬＡＳＨボリューム及び少なくとも１つのＲＯＭボリュームにも分割されるメモリ（図示されていない）を含むが、この物理的な編成は論理的な編成とは異なる。メモリは、さらに、多様なインタフェースと関連付けられたメモリボリュームに分割されてよい。ある観点からは、メモリは、ハードウェアの一部と見なすことができる。別の観点からは、メモリは、ハードウェアから離れて図示されるシステム全体をサポートするまたは含むと見なすことができる。
【０３２６】
受信機／デコーダのアーキテクチャ
図５に関して、受信機／デコーダのソフトウェア／ハードウェアアーキテクチャ３０００は、ソフトウェアが任意の受信機／デコーダ内で、及び任意のオペレーティングシステムを用いて実現できるように編成された５つのソフトウェア層を含む。多様なソフトウェア層は、アプリケーション層３１００、アプリケーションプログラミングインタフェース（ＡＰＩ）層３３００、仮想機械層３５００、（多くの場合、単に「デバイス層」に省略される）デバイスインタフェース層３７００、及びシステムソフトウェア／ハードウェア層３９００である。
【０３２７】
アプリケーション層３１００は、受信機／デコーダ内に常駐するか、あるいは受信機／デコーダにダウンロードされるかのどちらかであるアプリケーション３１２０を包含する。それらは、例えば、Ｊａｖａ、ＨＴＭＬ、ＭＨＥＧ−５または他の言語で作成されたカスタマによって使用される対話型アプリケーションであってよいか、あるいはそれらは例えばこのような対話型アプリケーションを実行するためなど他の目的のために受信機／デコーダによって使用されるアプリケーションであってよい。この層は、仮想機械層によって提供される開放アプリケーションプログラミングインタフェース（ＡＰＩ）の集合に基づいている。このシステムは、アプリケーションを、受信機／デコーダ内のハードディスク、フラッシュメモリまたはＲＡＭメモリに、進行中に、またはオンデマンドでダウンロードできるようにする。アプリケーションコードは、Ｄａｔａ  ＳｔｏｒａｇｅＭｅｄｉａ  Ｃｏｍｍａｎｄ  ａｎｄ  Ｃｏｎｔｒｏｌ（データ記憶媒体コマンドと制御）、Ｎｅｔｗｏｒｋ  Ｆｉｌｅ  Ｓｅｒｖｅｒ（ネットワークファイルサーバ）（ＮＦＳ）などのプロトコルまたは他のプロトコルを使用して圧縮済みフォーマットまたは未圧縮フォーマットで伝送できる。
【０３２８】
ＡＰＩ層３３００は、対話型アプリケーションの開発に高水準ユーティリティを提供する。それは、高水準ＡＰＩを構成する複数のパッケージを含む。パッケージは、対話型アプありケーションを実行するために必要なすべての機能性を提供する。パッケージは、アプリケーションによってアクセス可能である。
【０３２９】
好ましい実施形態においては、ＡＰＩは、Ｊａｖａ、ＰａｎＴａｌｋまたはこのような類似するプログラミング言語で作成されたアプリケーション向けに適応される。さらに、それは、ＨＴＭＬ及びＭＨＥＧ−５などの他のフォーマットの解釈を助長できる。これらの機能に加えて、それは、要件が支配するように切り離し可能且つ拡張可能である他のパッケージ及びサービスモジュールも含む。
【０３３０】
仮想機械層３５００は、言語インタプリタ及び多様なモジュールとシステムから構成される。カーネル３６５０（図示されていない）によって管理されるこの層は、受信機／デコーダ内の対話型アプリケーションを受信し、実行するために必要なすべてから成り立っている。
【０３３１】
デバイスインタフェース層３７００は、（通常、ここではただ「デバイス」と呼ばれる）デバイスマネージャ及びソフトウェアデバイスを含む。デバイスは、外部イベント及び物理インタフェースの管理に必要な論理的なリソースから成り立っているソフトウェアモジュールである。デバイスマネージャの制御下のデバイスインタフェース層は、ドライバとアプリケーション間の通信チャネルを管理し、機能強化されたエラー除外チェックを提供する。管理された（ハードウェア）デバイスのいくつかの例は、以下のとおりである。つまり、カード読取装置３７２２（図示されていない）、モデム３７３０（図示されていない）、ネットワーク３７３２（図示されていない）、ＰＣＭＣＩＡ（パーソナルコンピュータメモリカード国際協会）、ＬＥＤディスプレイ等である。ＡＰＩ層は前記からデバイスを制御するため、プログラマは、直接的にこの層に対処する必要はない。
【０３３２】
システムソフトウェア／ハードウェア層３９００は、受信機／デコーダのメーカによって提供される。システムのモジュール方式のため、及び（イベントスケジューリング及びメモリ管理などの）より高いレベルのオペレーティングシステムによって供給されるサービスが仮想機械及びカーネルの一部であるため、より高いレベルの層は特定のリアルタイムオペレーティングシステム（ＲＴＯＳ）に、または特定のプロセッサに結び付いていない。
【０３３３】
一般的には、ときおりデバイスインタフェース層３７００及び／またはＡＰＩ３３００と組み合わされる仮想機械層３５００は、受信機／デコーダの「ミドルウェア」と呼ばれる。
【０３３４】
図６に関して、（アプリケーション層３１００、ＡＰＩ層３３００及び仮想機械層３５００を備える）図５の上半分に対応する受信機／デコーダ３０００のソフトウェアアーキテクチャが、ここでさらに詳細に説明されるだろう。
【０３３５】
対話型アプリケーションは、例えば、電子番組表、テレバンキングアプリケーション及びゲームなどの製品とサービスを得るためにユーザが対話するアプリケーションである。
【０３３６】
アプリケーション層３１００には、アプリケーションマネージャ３１１０に加えて、２種類のアプリケーションがある。それらがＡＰＩ３３００に準拠する限り、いつでも追加できるウェブブラウザ３１３０などの対話型アプリケーションがあり、対話型アプリケーションを管理、サポートする常駐アプリケーションがある。常駐アプリケーションは、実質的には恒久的であり、以下を含む。
【０３３７】
・ブート。ブートアプリケーション３１４２は、受信機／デコーダが電源投入されると起動される最初のアプリケーションである。ブートアプリケーションは、最初にアプリケーションマネージャ３１１０を起動してから、メモリマネージャ３５４４及びイベントマネージャ３５４６などの仮想機械で「マネージャ」ソフトウェアモジュールを起動する。
【０３３８】
・アプリケーションマネージャ。アプリケーションマネージャ３１１０は、受信機／デコーダ内で実行される対話型アプリケーションを管理する。すなわち、それはイベントを起動し、停止し、一時停止し、再開し、処理し、アプリケーション間の通信に対処する。それは、複数のアプリケーションを同時に実行できるようにするため、それらの間でのリソースの割り当てに関与する。このアプリケーションは、ユーザに対して完全にトランスペアレントである。
【０３３９】
・セットアップ。セットアップアプリケーション３１４４の目的は、おもに初めてそれが使用されるときに、受信機／デコーダを構成することである。それは、テレビチャネルについての走査、日付と時刻の設定、ユーザ優先順位の設定等のアクションを実行する。ただし、セットアップアプリケーションは、受信機／デコーダ構成を変更するためにユーザによって任意の時点で使用することができる。
【０３４０】
・ザッピング。ザッピングアプリケーション３１４６は、プログラムアップキー、プログラムダウンキー、及び数値キーを使用してチャネルを変更するために使用される。例えば、バナー（パイロット）アプリケーションを通して別の形のザッピングが使用されるとき、ザッピングアプリケーションは停止される。
【０３４１】
・コールバック。コールバックアプリケーション３１４８は、受信機／デコーダメモリ内に記憶される多様なパラメータの値を抽出し、これらの値をモデム化されたバックチャネル１０７０（図示されていない）を介して、または他の手段によって商業事業者に戻すために使用される。
【０３４２】
アプリケーション層３１００での他のアプリケーションは、番組表アプリケーション３１３２、有料視聴アプリケーション３１３４、バナー（パイロット）アプリケーション３１３６、ホームバンキングアプリケーション３１３８、ソフトウェアダウンロードアプリケーション３１４０、及びＰＶＲ（パーソナルビデオレコーダ）アプリケーション３１５４（以下を参照すること）を含む。
【０３４３】
前記に注記されたように、アプリケーションプログラミングインタフェース（ＡＰＩ）層３３００は、複数のパッケージを含む。これらは、例えば、仮想機械の基本的な機能にアクセスするために使用される基本システムパッケージ３３１０、ＤＡＶＩＣパッケージ３３２０、及びおもなソフトウェアベンダに固有のソフトウェアアーキテクチャの機能にアクセスするために使用される独自に開発したパッケージ３３３０を含む。
【０３４４】
さらに詳細に考えられると、仮想機械３５００は、以下を含む。
【０３４５】
・言語インタプリタ３５１０。さまざまなインタプリタが、読み取られるアプリケーションの種類に準拠するためにインストールできる。これらは、Ｊａｖａインタプリタ３５１２、ＰａｎＴａｌｋインタプリタ３５１４、ＨＴＭＬインタプリタ３５１６、ＭＨＥＧ−５インタプリタ３５１８及び他を含む。
【０３４６】
・サービス情報（ＳＩ）エンジン。ＳＩエンジン３５４０は、共通のデジタルビデオ一斉送信（ＤＶＢ）またはプログラムシステム情報プロトコル（ＰＳＩＰ）テーブルをロード、監視し、それらをキャッシュの中に入れる。それは、それらの中に含まれるデータを必要とするアプリケーションによるこれらのテーブルへのアクセスを可能にする。
【０３４７】
・スケジューラ３５４２。このモジュールは、それぞれのスレッドが独自のイベント待ち行列を有する、予防マルチスレッドスケジューリングに対処する。
【０３４８】
・メモリマネージャ３５４４。このモジュールはメモリに対するアクセスを管理する。それは、必要時にメモリ内のデータを自動的に圧縮し、自動ゴミ収集を実行する。
【０３４９】
・イベントマネージャ３５４６。このモジュールは、イベントを優先順位に従ってトリガできるようにする。それはタイマ及びイベントグラビングを管理し、アプリケーションがイベントを互いに送信できるようにする。
【０３５０】
・動的リンカ３５４８。このモジュールは、ネイティブＪａｖａ関数から発生するアドレスの解決を可能にし、ダウンロードされるＪａｖａクラスからのネイティブメソッドをＲＡＭの中にロードし、ＲＯＭに向かってダウンロードされたネイティブコードからの呼び出しを解決する。
【０３５１】
・グラフィックシステム３５５０。このシステムはオブジェクト指向であり、最適化されている。それは、多言語サポート付きのベクトルフォントエンジンだけではなく、グラフィックウィンドウ及びオブジェクト管理も含む。
【０３５２】
・クラスマネージャ３５５２。このモジュールはクラスをロードし、あらゆるクラス参照問題を解決する。
【０３５３】
・ファイルシステム３５５４。このモジュールはコンパクトであり、複数のＲＯＭ、フラッシュ、ＲＡＭ、およびＤＳＭＣＣボリューム付きの階層ファイルシステムを管理するために最適化される。フラッシュ完全性は、あらゆる事件に対して保証される。
【０３５４】
・機密保護マネージャ３５５６。このオジュールはアプリケーションを認証し、機密事項を扱うメモリ及びセットトップボックスの他のゾーンに対するアプリケーションのアクセスを制御する。
【０３５５】
・ダウンローダ３５５８。このモジュールは、遠隔ＤＳＭＣＣ回転トレーから、またはＮＦＳプロトコルを通した自動データロードを使用し、ダウンロードされるファイルは常駐ファイルと同様にアクセスされる。メモリの片付け、圧縮、及び認証も提供される。
【０３５６】
さらに、ＤＡＶＩＣリソース通知モデルが、クライアントリソースが効率的に管理されるようにサポートされる。
【０３５７】
カーネル３６５０は、仮想機械３５００及びデバイスインタフェース層３７００（図示されていない）内で実行している多様な異なるプロセスを管理する。効率及び信頼性の理由から、カーネルは、オペレーティングシステム用のＰＯＳＩＸ規格の関連する部分を実現する。
【０３５８】
カーネルの制御下、（Ｊａｖａ及びＰｅｎｔａｌｋアプリケーションを実行している）仮想機械は、大容量記憶サーバ３８５０（図示されていない）などの、オペレーティングシステムの他の「サーバ」要素とは別個の独自のスレッドの中で実行する。システム呼び出しでパラメータとしてスレッドＩＤを渡すことを要求するなどの対応する規約も、アプリケーション３１２０がマルチスレッド環境によって益を得ることができるようにするためにＡＰＩ層３３００内で作成される。
【０３５９】
複数のスレッドを提供することによって、より多くの安定性を達成できる。例えば、仮想機械３５００が、クラッシュを経験するまたはデバイスにアクセスを試みるアプリケーションによって長時間ブロックされるなど、なんらかの理由で動作するのを中止する場合に、ハードディスクサーバなどのシステムの他のスピードが重視される部分は動作し続けることができる。
【０３６０】
仮想機械３５００及びカーネル３６５０だけではなく、ハードディスクビデオレコーダ（ＨＤＶＲ）モジュール３８５０も、ハードディスクまたは他の取り付けられている大容量記憶構成要素の記録機能及びプレイバック機能を処理するために提供される。サーバは、記録を処理する２つの別々のスレッド３８５４、３８５６を備え、１つのスレッド３８５８はプレイバックを処理するためであり、ファイルシステムライブラリ３８５２は大容量記憶構成要素と接続するためである。
【０３６１】
ハードディスクビデオレコーダ（ＨＤＶＲ）３８５０内のスレッド３８５４、３８５６、３８５８の適切な１つが、例えば「録画」ボタンを押すユーザに応えて、パーソナルビデオレコーダ（ＰＶＲ）アプリケーション３１５４などのクライアントから、（ある特定の番組の録画を開始するためのコマンドなどの）コマンドを受信する。
【０３６２】
同様に、問題のスレッドは、それから、録画またはプレイバックされるビットストリームを処理する受信機／デコーダの部分をセットアップし、同期させるために（図７に図示されている）サービスデバイス３７３６と対話する。平行して、スレッドは、ハードディスク２２１０（図示されていない）上の適切な場所での記録またはプレイバックを調整するために、ファイルシステムライブラリ３８５２とも対話する。
【０３６３】
それから、ファイルシステムライブラリ３８５２は、どのサブトランスポートストリーム（ＳＴＳ）を（ＦＩＦＯバッファを介して）転送するのか、及びどのハードディスクターゲットにストリームが記憶されなければならないのかを大容量記憶装置３７２８に告げるコマンドを、（やはり図７に図示される）大容量記憶装置３７２８に送信する。ハードディスク及び汎用ファイル管理でのクラスタの割り当ては、ファイルシステムライブラリ３８５２によって実施され、大容量記憶装置自体はさらに低いレベルの動作に関与する。
【０３６４】
前述されたサービスデバイス３７３６は、それが受信機／デコーダの物理的な構成要素に関係しないという点でデバイスの中で他とは異なる。それは、代わりに、単一の「インスタンス」の中に、チューナ、デマルチプレクサ、リマルチプレクサ、及び受信機／デコーダ内のハードディスクデバイスの多様な集合を集める高レベルインタフェースを提供し、さらに高いレベルのプロセスを多様なサブデバイスを調整する難事から解放する。
【０３６５】
図７に関して、（デバイスインタフェース層３７００及びシステムソフトウェア及びハードウェア層３９００を備える）図５の下半分に対応する受信機／デコーダ３０００のソフトウェアアーキテクチャが、ここでさらに詳細に説明されるだろう。
【０３６６】
デバイス層の中に提供される追加デバイスは、条件付きアクセスデバイス３７２０、図４の２つの（またはおそらく３つ以上の）チューナ２０１６、２０１８に対応するチューナデバイス３７２４、ビデオデバイス３７３４、Ｉ／Ｏポートデバイス３７２６、及び前述されたサービスデバイス３７３６と大容量記憶装置３７２８を含む。
【０３６７】
大きく見ると、デバイスは、論理インタフェースを定義すると見なすことができ、その結果、２つの異なるデバイスが、1つの共通した物理ポートに結合されてよい。一定のデバイスはそれら自体の間で通信してよく、すべてのデバイスもカーネル３６５０の制御下で動作する。
【０３６８】
任意のデバイスのサービスを使用する前に、（アプリケーション命令シーケンスなどの）製品は「クライアント」つまり、デバイスまたはデバイスマネージャ３７１０への論理的なアクセス方法として宣言されなければならない。マネージャは、クライアントに、デバイスに対するすべてのアクセスで参照されるクライアント番号を与える。デバイスは、複数のクライアントを有することができ、クライアントの数が、デバイスごとにデバイスの種類に応じて指定されている。クライアントは、プロシージャ「Ｄｅｖｉｃｅ：Ｏｐｅｎ  Ｃｈａｎｎｅｌ（デバイス：チャネル開放）によってデバイスに導入される。このプロシージャが、クライアントにクライアント番号を割り当てる。クライアントは、プロシージャ「Ｄｅｖｉｃｅ：Ｃｌｏｓｅ  Ｃｈａｎｎｅｌ（デバイス：チャネル閉鎖）によって、デバイスマネージャ３７１０クライアントリストから取り出すことができる。
【０３６９】
デバイスマネージャ３７１０によって提供されるデバイスに対するアクセスは、同期または非同期のどちらかである。同期アクセスの場合、プロシージャ「Ｄｅｖｉｃ：Ｃａｌｌ（デバイス：呼び出し）」が使用される。これは、ただちに入手できるデータ、または所望される応答を待機することを含まない機能性にアクセスする手段である。非同期アクセスの場合、プロシージャ「Ｄｅｖｉｃｅ：Ｉ／Ｏ（デバイス：Ｉ／Ｏ）」が使用される。これは、多重送信システムを見つけるためにチューナ周波数を走査する、またはＭＰＥＧストリームからテーブルを取り戻すなどの応答を待機することを含むデータにアクセスする手段である。要求された結果が入手可能であると、イベントはその到着を信号で知らせるためにエンジンの待ち行列に入れられる。追加プロシージャ「Ｄｅｖｉｃｅ：Ｅｖｅｎｔ（デバイス：イベント）」は、予期されないイベントを管理する手段を提供する。
【０３７０】
受信機／デコーダの第２実施形態においては、受信機／デコーダのアーキテクチャの下半分が、図８に図示される層に置き替えられる。
【０３７１】
この実施形態では、拡張デバイス層インタフェース（ＥＤＬＩ）３６００が、仮想機械３５００（図示さていない）とデバイスインタフェース層３７００の間に提供され、抽象デバイスインタフェース３８００がデバイスインタフェース層３７００とシステムソフトウェア／ハードウェア層３９００の間に提供される。それ以外の場合、類似する部分は類似する参照番号で示される。
【０３７２】
拡張デバイス層インタフェース（ＥＤＬＩ）３６００は、仮想機械３５００とデバイスインタフェース層３７００間に専用インタフェースを提供し、通常、デバイスインタフェース層にマルチスレッドサポートを提供する。ＥＤＬＩの機能は、（デバイスインタフェース層はそれ自体マルチスレッドをサポートする必要がないため）ミドルウェアの適切なスレッドに非同期イベントを送ることと、スレッド間でメッセージを送ることを含む。
【０３７３】
抽象デバイスインタフェース３８００は、システムソフトウェア／ハードウェア層３９００内のデバイスインタフェース層３７００とデバイスドライバ３９１０間に追加のインタフェースを提供する。このようなインタフェースを提供することによって、大きく、複雑なデバイス層３７００を、さらに大いにハードウェアと無関係にすることができる。
【０３７４】
コンテンツ管理保護システム（ＣＭＰＳ）
図９に関して、前述されたコンテンツ管理保護システム（ＣＭＰＳ）２３００が、放送センタ１０００と受信機／デコーダ２０００の間で分散される。ＣＭＰＳの受信機／デコーダ構成要素は、関連付けられているスマートカード読取装置付きのスマートカードの形で提供されるが、好ましい実施形態の変形では、単にソフトウェアで、またはハードウェアの他の形で実現される。ＣＭＰＳは、許可されたユーザだけが、事前に定められた使用規則に従ってコンテンツを記録、プレイバックできることを保証することができる。
【０３７５】
コンテンツ管理保護システムの重要な部分は、指定される番組または伝送に関係するコンテンツ管理情報を含み、このような番組または伝送の前に伝送される特殊な使用規則メッセージ（ＵＲＭ）である。基本的に、使用規則メッセージは、コンテンツのプレイバック及び複製に対する使用制約を課し、番組内の別個の「章」などのコンテンツの特定的な部分だけに、または全体としてのコンテンツに向けることができる。典型的な使用規則は、ビデオ録画、早送り、記録がプレイバックできる回数、及び使用可能な複製モードに対する制限を含む。さらに詳細に後述されるだろう別の重要な特徴は、指定される番組に関係するＵＲＭが、（さまざまな場所から、さまざまなときに）対応するコンテンツまたは条件付きアクセス情報とは無関係に送信されてよいという点である。
【０３７６】
メッセージの第２クラス、つまりＣＭＰＳエンタイトルメント管理メッセージ（ＣＭＰＳ  ＥＭＭ、またはＣＭＰ＿ＥＭＭ）は、アクセス権をＣＭＰＳに伝送するために提供される。ＣＭＰＳ  ＥＭＭは、他の場所で参照される、条件付きアクセスエンタイトルメントメッセージ（ＥＭＭ、つまいＣＡＳ＿ＥＭＭ）に同等であるが、伝送されるアクセス権は、「従来の」ＥＭＭでの場合のように、放送番組データよりむしろ番組データのローカル記憶に関係する。
【０３７７】
図９に示される好ましい実施形態においては、マルチプレクサ及びスクランブラ１０３０が、ＣＭＰＳ  ＥＭＭ５６１４及びＵＲＭ  ５６１２を受信し、解読されたコンテンツ（番組データ）８１０を含むビットストリームでそれらを多重化し、放送システム６００を介して、結果として生じるスクランブルされたコンテンツ８００を一斉送信する。それから、受信機／デコーダはスクランブルされたコンテンツ８００を受信し、ＣＭＰＳ  ＥＭＭ及びＵＲＭを削除し、ＣＭＰＳ２３００及び条件付きアクセスシステム５０００に適宜に渡す。
【０３７８】
ＵＲＭは、好ましい実施形態の変形においてはＥＣＭ活用キーと同じであるＵＲＭ活用キーで暗号化される。ＵＲＭ活用キーの同等物は、ＵＲＭを平文に直すことができるようにするために、受信機／デコーダＣＭＰＳスマートカード（図示されていない）の中に維持される。
【０３７９】
前述されたように、受信機／デコーダを使用してユーザが記録及び／またはプレイバックできるようにするアクセス権は、ＣＭＰＳエンタイトルメント管理メッセージ（ＣＭＰＳ  ＥＭＭまたはＣＭＰ＿ＥＭＭ）の形で提供される。ＣＭＰＳ  ＥＭＭは、従来のＥＭＭと同じ構造を有することがあるが、一般的にはよりキー指向型である―ＣＭＰ＿ＥＭＭは、一般的には、コンテンツまたはサービスと関連付けられるキーを埋め込む。記録されたコンテンツをプレイバックする権利は、1回限りの支払い（衝動買い）または加入と交換に与えられる。多様なレベルのアクセス権も、任意のコンテンツに関して与えることができ、それによりユーザは、例えば、コンテンツを一度再生するための権利と交換に第1料金を支払うか、あるいは無制限な再生と交換に第２のさらに高い料金を支払うことができるだろう。ＣＭＰ＿ＥＭＭは、一般的には受信機／デコーダＣＭＰＳスマートカードに記憶されるが、例えば条件付きアクセススマートカードの中などの他の場所に記憶されてよい。
【０３８０】
好ましい実施形態においては、記録を再生する権利は、記録が行われてから（「有料視聴」モデル）、あるいは記録の前に（「加入」モデル）のどちらかに得ることができる。前者のケースでは、コンテンツを記録した後、ユーザは条件付きアクセスシステムに、自分がコンテンツをプレイバックする権利を得ることを希望する旨を指示する。指示が加入管理システムによって認められると、その後、適切なＣＭＰＳエンタイトルメント管理メッセージ（「ＣＭＰ＿ＥＭＭ」）が、双方向リンクを介して受信機／デコーダに伝送される。
【０３８１】
ＣＭＰＳシステムにより提供される多くの優位点の１つは、番組を記録し、プレイバックするためのアクセス権が、従来のシステムでのように、単に番組を見るためのアクセス権とはまったく関係がないという点である。したがって、人は番組を見ることはできるがそれを記録、プレイバックできない状況を有することがあり、逆に、人は番組を見ることはできないが、人はそれを記録し、必要な権利を得てから、それをプレイバックできるだろう。
【０３８２】
特に図１０に図示されるインターネット分散モデル特有の好ましい実施形態の変形においては、スクランブルされたコンテンツ（「ＣＯＮＴＥＮＴ（コンテンツ）＊」）、ＣＭＰＳ  ＥＭＭ（「ＣＭＰ＿ＥＭＭ」）及びＵＲＭ（「ＵＲＭ」）は、すべて、第１関係者１２００、第２関係者１２０２及び第３関係者１２０４から、受信機／デコーダ２０００に独自に送達される。第１関係者、第２関係者、または第３関係者は、例えば、マルチアクセスポータル（ＭＡＰ）であってよく、スクランブルされたコンテンツ１３００、ＣＭＰＳ  ＥＭＭ５６１４及びＵＲＭ５６１２が送達されてよい。一般的には、番組プロバイダ（第２関係者１２０２）は、マルチプレクサ／スクランブラに番組コンテンツ（「ＣＯＮＴＥＮＴ」（コンテンツ））を送信し、スクランブルされたコンテンツ１３００（ＣＯＮＴＥＮＴ＊（コンテンツ））が生成されてから、通常通りに受信機／デコーダ２０００に伝送される。
【０３８３】
図１１に関して、受信機／デコーダ２０００でのＣＭＰＳのインプリメンテーションがここで説明されるだろう。
【０３８４】
ＣＭＰＳサーバモジュール２２００は、受信機／デコーダミドルウェア内で提供され、ＣＭＰＳサーバＡＰＩ、ＣＭＰＳコア及びリンク層を備える。ＣＭＰＳサーバモジュール２２００は、ＣＭＰＳライブラリ３３６２と接続し、ＨＤＶＲ制御装置３３５０と間接的に接続する。ＣＭＰＳサーバモジュール２２００も、ＭＬＯＡＤデバイス３４３８、（条件付きアクセススマートカードを収容する）ＬＣＡＲＤデバイス３４４０、及び（ＣＭＰＳスマートカードを収容する）ＲＣＡＲＤデバイス３４４２と接続する。
【０３８５】
動作中、番組データストリームの中で受信されるＥＣＭ５６０２は、ＭＬＯＡＤデバイスによって隔離されてから、ＣＭＰＳリンク層によって条件付きアクセススマートカードに送られる。次に、ＥＣＭから引き出される制御ワード５６００が、（好ましくは番組データストリーム中でも受信されるが、他のルートを介して受信されてよい）対応するＵＲＭ５６１２及びＣＭＰＳ  ＥＭＭ５６１４とともに、ＣＭＰＳスマートカードに送られる。それから、ＣＭＰＳスマートカードは、その後、追加処理のためにＣＭＰＳコアに渡されるコンテンツ管理メッセージ５６１０（ＣＭＭ）を形成するために、データの３つのアイテムを結合し、暗号化する。適切な要求に応えて、ＣＭＭは、次に、それらが対応するコンテンツデータとともにディスク上に記憶できるように、ＨＤＶＲ制御装置３３５０に渡される。
【０３８６】
図１２に描かれているコンテンツをディスクに記録するプロセスにおいて、各ＥＣＭ５６０２が、条件付きアクセススマートカード内の記述段階５５５０に渡され、それは汎用活用キーＫＧ５６０６を使用して平文に直される。平文に直された制御ワード５６００は、次に、ＣＭＰＳスマートカード内の暗号化段階２２０２に渡り、それは対応するＵＲＭ５６１２とＣＭＰＳ  ＥＭＭ５６１４を含むコンテンツ管理メッセージ（ＣＭＭ）の中に結合されてから、ローカル活用キーＫＬ５６０８を使用して全体として暗号化し直される。それから、ＣＭＭは、別個のファイル２１１２から、改変されていないスクランブルされたコンテンツをハードディスク２１００に記憶するために使用されるファイル２１１０に記憶される。
【０３８７】
図１３に描かれているコンテンツをディスクからプレイバックする逆プロセスにおいては、スクランブルされたコンテンツ１３００がハードディスク２１００上のファイル２１１０から読み取られ、デスクランブラ２０１０に送り込まれる。平行して、ＣＭＭは別個のファイル２１１２から読み取られ、ＣＭＰＳスマートカードの暗号解読段階２２０２に送り込まれる。ＣＭＭはローカル活用キー５６０８で平文に直されてから、ＵＲＭ５６１２、ＣＭＰＳ  ＥＭＭ５６１４及び制御ワード５６００に分割される。ＣＭＰＳモジュールが、ユーザが（ＵＲＭ及びＣＭＰＳ  ＥＭＭに基づいて）資料を見る権利があると判断すると、制御ワード５６００が、コンテンツを逆スクランブルできるようにするために適切な時間にデスクランブラ２０１０に送信される。
【０３８８】
インターネットフォーマット
可変ビット・レートビットストリーム伝送
好ましい実施形態により受信、処理及び記憶される伝送は、ビットストリームの形を取り、記録されたビットストリームからのデータの検索及び処理は部分的にこのようなビットストリームの特性に依存する。特に可変ビット・レートビットストリームの記録を含むファイルのこのようなレコーディングと処理、及びこのようなファイルに関係する暗号化情報の同期、記憶及び検索における、レコードのテーブル、特に特定の実施形態でのＨＤＶＲとＵＳＥＲ索引の使用は、後述される。この時点で、可変ビット・レートビットストリームの一般的な特性が簡略に説明される。
【０３８９】
図１４は、衛星ＴＶ伝送のビットレート対時間のグラフである。
【０３９０】
多様な実施形態では、図１４に描かれているものに類似する可変ビット・レートビットストリームが、コンピュータデバイス、プロセッサ、Ａ／Ｄ変換器、テレビ、ＨＤＶＲ、または例えばハードディスク、テープ、コンピュータ記憶装置、ＣＤＳまたはＤＶＳなどの記憶装置の中または間で伝送、記憶される。このような可変ビット・レートビットストリームは、ＤＶＢ−ＣＳ、ＤＥＳ、３ＤＥＳを含むさまざまな暗号にするアルゴリズムによって保護されるＭＰＥＧ−２、ＭＰＥＧ−４、ＭＰ３を含む多岐に渡る圧縮フォーマットのデータを含み、ビデオ及びまたは音声データ、テレテキスト情報、字幕、他の種類のテキスト情報、コンピュータデータ、またはこのようなデータの表現を含む。
【０３９１】
図１５は、時間の関数としてのＭＰＥＧ−２データストリームの図であり、フレーム内（Ｉ−フレーム）４５００と４５０２として知られているキーフレーム及び例えば４５１０でのＢ−フレ―ム、及び例えばビットストリーム内の４５１２でのＰ−フレームの形を取るデルタフレームの位置を概略して示す。キーフレームは、音声／画像データの一部を再生するために独自に使用することができるが、デルタフレームは他のフレームから変更をマッピングし、このような他のフレームに依存してのみ視聴覚データの一部を再生するために使用できる。フレーム間（Ｐ−フレーム）は、先行するフレームから変更をマッピングするが、Ｂ−フレームは先行するフレームまたは後続のフレームのどちらか、あるいは先行するフレームと後続のフレームの両方からの変更をマッピングする。ＭＰＥＧ−２データストリームでは、キーフレームは、通常２Ｈｚという周波数で伝送される。
【０３９２】
受信時、ビットストリームは、それが使い切られない（ｐｌａｙｅｄ  ｏｕｔ）、あるいは記憶されずにただちに再送されない限り、通常、データ記憶装置内でデータファイルとして記憶される。ビットストリーム６００２内のタイムオフセットとデータファイル内のデータオフセットの対応を含むデータファイルが、図１６と図１７に図示される。
【０３９３】
ここで、好ましい実施形態の３つの一般的な態様に関して追加の詳細が提供される。
【０３９４】
・記憶されているビットストリームの検索及び処理における索引表の作成及び使用
・ビットストリーム中の位置の推定、及び条件付きアクセス情報のビットストリームとの同期
・ビットストリームの転送を制御するためのコマンドセット
記憶されているビットストリームの検索及び処理における索引表の作成及び使用で開始し、ＨＤＶＲによって記憶されるファイルの形式で記憶されているビットストリームの構造及びコンテンツが、最初に調べられる。
【０３９５】
ＨＤＶＲファイルの構造
記憶されているデータの構造をさらに詳細に見ると、ＨＤＶＲファイルは、（以下でｈｄｖｒ＿ｍａｎａｇｅｍｅｎｔ＿ｄａｔａと呼ばれる）管理データと（以下でｈｄｖｒ＿ｃｏｎｔｅｎｔ＿ｄａｔａと呼ばれる）コンテンツデータの両方を備える。管理データ及びコンテンツデータは、同じファイルの別々の部分として、あるいは別々のファイルとしてのどちらかでＨＤＶＲに記憶される。
【０３９６】
ｈｄｖｒ＿ｃｏｎｔｅｎｔ＿ｄａｔａは、さらに詳細に後述される記憶済みトランスポートストリーム（ＳＴＳ）を備える。しかしながら、最初に、ｈｄｖｒ＿ｍａｎａｇｅｍｅｎｔ＿ｄａｔａが、さらに詳しく調べられる。
【０３９７】
ｈｄｖｒ＿ｍａｎａｇｅｍｅｎｔ＿ｄａｔａは、前述されたように（一般的には専用二次元テーブルの形を取る）ＣＭＭを備え、一般的には以下のテーブルも備える。
【０３９８】
・索引表
・章テーブル
・私用ＰＭＴテーブル
・親制御データテーブル
・最大値テーブル
・一般情報テーブル
最大値テーブルは、最大値テーブル自体及び一般情報テーブルを除いて、ＨＤＶＲテーブルのすべての記憶構造の指定を可能にする。
【０３９９】
好ましい実施形態においては、ＨＤＶＲ管理データは、つねに以下を備える。
【０４００】
・第１に、一般情報テーブル
・第２に、最大値テーブル
・第３に、私用ＰＭＴテーブル、章テーブルなどの他のＨＤＶＲテーブル
ｈｄｖｒ＿ｆｉｌｅ．ｍａｎａｇｅｍｅｎｔ＿ｄａｔａの基本部分ごとに、それぞれがファイル内のジャンプ及び実行される動作を要約する書き込み関数及びプレイ関数がある。
【０４０１】
前記テーブルのそれぞれがさらに詳細に後述されるが、最初に索引表の構造及びコンテンツ、及び記憶されたコンテンツで動作を実行する際のその使用がさらに詳しく調べられる。
【０４０２】
ＨＤＶＲ索引表及び記録されたビットストリームでＨＤＶＲにより実行される動作
ここでは、ＨＤＶＲ索引とＵＳＥＲ索引を備えるＨＤＶＲ索引表、及びＨＤＶＲ索引表を使用して記録されたビットストリームでＨＤＶＲによって実行される動作に関して追加の詳細が提供される。
【０４０３】
ＨＤＶＲ索引表は、ビットストリーム中の（暗号期間に分けられる、秒単位の）少なくとも１つのタイムオフセットとビットストリームの表現を含むＳＴＳ内の少なくとも１つのファイルオフセットの間のマッピングを可能にする。一般的には、ビットストリームは、前述されたように可変ビット・レートビットストリームである。
【０４０４】
ＨＤＶＲ索引表中の索引はＣＭＭ索引とは別個であり、それらと関連付けられるＣＭＭつまり暗号期間番号、秒単位の時間、及びファイルオフセット番号を有する。ファイルオフセット番号を知っていると、ＨＤＶＲ索引表は、ビットレートの変化に伴い失敗する二分アルゴリズムを使用しておそらく時間がかかるバイナリ探索を必要としなくても、秒単位の時間または暗号期間に関してファイルオフセット位置を調べるために使用できる。時間の変化は、サンプル間の時間である。
【０４０５】
例えば、ファイル内の点、つまり対応するビットストリームの探索などの記録されたコンテンツの処理、及びはや送り、巻き戻し、読み飛ばしなどの「トリックモード」動作は、ＨＤＶＲ索引表に記憶されるＨＤＶＲ索引とＵＳＥＲ索引を利用する。一般的には、ＨＤＶＲ索引はＨＤＶＲにより自動的に挿入され、ＵＳＥＲ索引はユーザの命令時に挿入される。
【０４０６】
前述されたように、好ましい実施形態においては、ＨＤＶＲ索引表は、ＨＤＶＲファイルのｈｄｖｒ＿ｆｉｌｅ＿ｍａｎａｇｅｍｅｎｔ＿ｄａｔａ部分に記憶される。このような好ましい実施形態の変形においては、ＨＤＶＲ索引表は別個のファイルの中に、またはＨＤＶＲファイルの中の他の場所に記憶される。
【０４０７】
前述されたように、多様な他のデータは、好ましい実施形態のＨＤＶＲファイルのｈｄｖｒ＿ｆｉｌｅ＿ｍａｎａｇｅｍｅｎｔ＿ｄａｔａ部分に記憶される。特に、条件付アクセス情報は、ｈｄｖｒ＿ｆｉｌｅ＿ｍａｎａｇｅｍｅｎｔ＿ｄａｔａ内にＣＭＭテーブルとして記憶され、索引表の中のエントリはＣＭＭテーブルの中のエントリにマッピングされ、その結果、ＨＤＶＲ索引とＵＳＥＲ索引で索引が付けられるＨＤＶＲファイル内の点におけるデータは、ＣＭＭテーブル中の対応するエントリを使用して復号されてよい。
【０４０８】
好ましい実施形態においては、ＨＤＶＲ索引表は、番組の記録中に自動的にＨＤＶＲによって作成される。代わりに、ＨＤＶＲ索引表、または追加のこのようなテーブルが、番組のレコーディングの後の命令時に作成される。
【０４０９】
ＨＤＶＲ索引
ＨＤＶＲ索引は、ＨＤＶＲによって定期的な間隔で配置され、（内部暗号化のケースでは）記録されるファイル内のプレイエントリ点として使用される。それらはプレイ位置決めの粒度に一致する。したがって、記録されるファイルまたは番組に対応するＣＭＭファミリごとに、各ＨＤＶＲ索引は少なくとも１つの当てはまるＣＭＭを指し、ファイル内のその位置はブロック番号（ファイル粒度）により特定される。
【０４１０】
複数の記録されたコンテンツに関係する複数の商業的なオファーのケースでは、１つのエントリ点ごとに複数のＣＭＭセットがあってよい。例えば、ユーザは、ＳＴＳに記憶されるが、別のＣＭＭセットで暗号にされる関係音声データを含む特殊言語バージョンについて支払うことができる。したがって、この例では、索引エントリ点ごとに、少なくとも２つのＣＭＭが必要とされるだろう。
【０４１１】
好ましい実施形態においては、ＨＤＶＲ索引が作成され、番組のレコーディング中にリアルタイムで記憶される。記録はわずかＭａｘＨｄｖｒＩｎｄｅｘＮｕｍｂｅｒ索引を備える。
【０４１２】
ＨＤＶＲ索引は、通常、ビットストリーム中の周期的なタイムオフセットに配置される。好ましい実施形態においては、ビットストリームはＭＰＥＧ−２プロトコルに従って圧縮されるデータを備え、このプロトコルに従って、フレーム内として知られるキーフレームは、ビットストリーム中で０．５秒おきに位置する。前述されたように、このようなキーフレームは、例えばフィルムの中の１コマなどの視聴覚データの一部を、ビットストリーム中の他の部分とは関係なく再生するために使用される。このような実施形態でのＨＤＶＲ索引は、０．５秒という期間で分散されるタイムオフセットを有し、索引は各キーフレームの始まりに一致する。
【０４１３】
好ましい実施形態の変形においては、ＨＤＶＲ索引は、異なる期間のタイムオフセットで配置され、いくつかの変形においては、このような期間は、ユーザの命令時と、ＨＤＶＲにより自動的にの両方で変えられる。
【０４１４】
ＵＳＥＲ索引
ＵＳＥＲ索引は、クライアントによって配置され、やはりプレイエントリ点である。前述されたように、プレイ粒度はＨＤＶＲ索引であり、好ましい実施形態においては、ユーザ索引はこれらのＨＤＶＲ索引に基づいている。ＨＤＶＲ索引を使用して、ＣＭＭファミリごとにＵＳＥＲ索引に当てはまるＣＭＭを取り戻すのが簡単である。
【０４１５】
ＵＳＥＲ索引は、番組の記録または記録された番組のプレイバックのときに設定される。特定の実施形態においては、このようなＵＳＥＲ索引の数は限られ、記録は、わずかＭａｘＵｓｅｒＩｎｄｅｘＮｕｍｂｅｒ索引を備える。
【０４１６】
他の実施形態においては、ビットストリームは多岐に渡る他の圧縮フォーマットのデータを備えてよいが、好ましい実施形態においては、ビットストリームは、ＭＰＥＧ−２、ＭＰＥＧ−４、またはＭＰ３データを備える。
【０４１７】
ＨＤＶＲ索引及びＵＳＥＲ索引を使用するビットストリーム動作
ＨＤＶＲ索引及びＵＳＥＲ索引は、ＳＴＳで多岐に渡る動作を実行するために使用される。
【０４１８】
探索
例えば、図１８に描かれているように、ＨＤＶＲ索引とＵＳＥＲ索引は、例えば、対応するビットストリーム中の好ましいタイムオフセットに対応するＨＤＶＲファイル６３００内の好ましい点を見つけるために使用される。好ましい点６３１４までのファイル内の最も近い点６３１０、またはさらに一般的には、最も近い先行する点６３１２が、ＨＤＶＲによって、ＨＤＶＲ索引とＵＳＥＲ索引の索引表６３１６内に位置し、ファイルは、好ましい点を見つけるために、ＨＤＶＲによってこの点から探索される。一般的には、探索は、好ましい点が見つけられるまで、（例えば、ＣＭＭテーブル内の対応するエントリを使用して）索引が付けられた点から前方へデータを復号し、読み取ることによって実行される。いくつかの変形では、索引が付けられた点は好ましい点に対応し、このような変形においては、探索は、単に適切な索引が付けられた点までジャンプすることによって実行される。
【０４１９】
代替実施形態においては、探索の主題である好ましい点が２つのＨＤＶＲ索引またはＵＳＥＲ索引により参照されるファイル内の点の間に収まる場合、ファイルは２つの索引が付けられた点の間の中間の点から探索される。この中間点は、２つの索引が付けられた点の間の線形補間によって配置される。このような実施形態の変形においては、中間点は、他のデータ保管技法を使用することによって、あるいは索引が付けられた点を、多項式関数または指数関数、あるいは三次スプライン関数などの代替関数に固定することによって配置される。このような変形では、好ましい点に隣接する２つの索引が付けられた点に加えて、追加の索引が付けられた点が、中間点の位置を突き止めるために使用される。
【０４２０】
トリックモード動作
好ましい実施形態においては、ＨＤＶＲ索引は、ビットストリーム中の時間で周期的に間隔をあけて置かれる点に一致する。早送りと巻き戻しなどの「トリックモード」動作は、このようなビットストリーム中の時間で周期的に間隔をあけて置かれる点に対応するファイル内のデータを、ＨＤＶＲ索引を使用して位置を突き止め、復号し、表示することによって、ＨＤＶＲにより実行される。
【０４２１】
例えば、巻き戻しまたは早送りの速度は、好ましい実施形態において、記憶されているビットストリームがプレイバックされる速度を変えることによって変えられる。一般的には、ビットストリームのすべてのデータが、巻き戻し動作または早送り動作中にプレイバックされるのではなく、むしろ通常はビットストリーム中の時間で等しく間隔をあけて配置される選択された部分がプレイバックされる。データがファイルから読み取られる速度は、プレイバックされるビットストリーム中のデータの割合を変えることによって特定の巻き戻しまたは早送りの速度について変えることができる。好ましい実施形態においては、巻き戻しまたは早送りの速度は、ユーザの命令時に変えられる。
【０４２２】
例証として、早送り動作が図１９に描かれている。ＨＤＶＲは、ビットストリーム中の時間６４００、６４０４、６４０８、及び６４１２の等しく間隔があけられた点に対応するファイル内の点にあるデータを、ＨＤＶＲ索引を使用して位置を突き止め、復号し、表示する。やはりＨＤＶＲ索引に対応する点６４０２、６４０６、及び６４１０は、省略される。実施形態の変形においては、ＨＤＶＲは、選択された点６４００、６４０４、６４０８及び６４１２が復号、表示される速度を変えることによって、及び選択される点を変えることによって、巻き戻しまたは早送りの速度を変える。
【０４２３】
好ましい実施形態においては、ビットストリームがＭＰＥＧビットストリームである場合、ＨＤＶＲ索引は、データの他の部分には関係なく、特に音声／画像データの部分の再生するために使用できるキーフレーム（ＭＰＥＧ−２のケースではＩフレーム）の始まりにマッピングする。図１８をこれらの変形に適用すると、キーフレームの場所は、ＨＦＶＲ索引の場所６３１２の少なくともいくつかに一致する。早送り及び巻き戻しは、等しく間隔をあけて置かれる時間間隔で位置するファイルの中にキーフレームを、あるいはＨＤＶＲ索引を調べることによって対応するビットストリームにオフセットを配置することによって迅速に実行される。
【０４２４】
好ましい実施形態の変形において、ＨＤＶＲ索引、またはＵＳＥＲ索引は、必ずしもキーフレームに直接にマッピングしない。図２０に描かれているように、索引は、ビットストリーム中のタイムオフセット６５００、６５０４、６５０６、６５１０、６５１２、６５１６、６５１８、及び６５２２、及びビットストリームの表現を含むファイル内の対応するデータオフセットを参照する。キーフレームは、ビットストリーム中のタイムオフセット６５０２、６５０８、６５１４、及び６５２０に位置（し、これらのキーフレームの表現はファイル内の対応するデータオフセットに位置）するが、索引はこれらのタイムオフセットを参照しない。
【０４２５】
図２０は、このような実施形態の早送り動作も描く。ＨＤＶＲは、ビットストリーム中の点６５００、６５０６、６５１２及び６５１８に対応するファイル内の点の位置を、索引を使用して突き止める。ＨＤＶＲ索引によっても参照される点６５０４、６５１０、６５１６、及び６５２２は省略される。６５００に対応するファイル内の点の位置を突き止めると、ＨＤＶＲは、ＣＭＭテーブルから適切なＣＭＭを使用して、この点でファイル内のデータを復号してから、それがビットストリーム中の６５０２にあるキーフレームを表すデータの位置を突き止めるまで、ファイル内の以下のデータを復号するために進む。それから、キーフレームは、ＨＤＶＲにリンクされるディスプレイ装置によって表示される。ＨＤＶＲは、６５０６、６５１２、及び６５１８に対応するファイル内の点の位置を突き止めるために、及び６５０８、６５１４、及び６５２０にあるキーを表すデータの位置を突き止めるために進む。これらのキーフレームは、順にディスプレイ装置上に表示される。
【０４２６】
追加の変形において、索引は、暗号期間の始まりに一致する、ビットストリーム中の点、及びファイル内の対応する点を参照する。
【０４２７】
追加実施形態においては、ビットストリームの表現は、ＤＶＤ上に記憶される表現のデータオフセットに、ビットストリーム中のデータオフセットをマッピングする索引の表とともにＤＶＤに記憶される。ＨＤＶＲ実施形態でのように、索引は、ビットストリーム中の時間で周期的に間隔をあけて置かれる点に対応する。この実施形態の変形においては、ＵＳＥＲ索引は索引の表に記憶される。索引の表は、ＤＶＤプレーヤによって、あるいはＤＶＤを読み取るように適応される任意のデバイスによって読み取られる。
【０４２８】
ハードウェア特性に依存するトリックモード動作の実行
早送りまたは巻き戻しなどの特定のトリックモード動作の最大動作速度は、システムハードウェアによってサポートされる最大フレームレートに依存し、特に、読み取り／書き込みハードディスクアクセス時間、解析デマルチプレクサ帯域幅、及びオペレーティングシステムスケジューリング精度に依存する。
【０４２９】
好ましい実施形態においては、ＨＤＶＲは、ハードウェア品質での変動にも関わらず、特定のハードウェアによって許される最大フレームレートを推定し、索引表で点を選択し、その後、このような最大フレームレートに従って、及び要求された早送り速度または巻き戻し速度に従って、ＳＴＳからこれらの点に対応するフレームを抽出することによって、例えばｘ１／１２８とｘ１２８の間などの許容範囲内の早送りまたは巻き戻しの速度をサポートする。一般的には、最大フレームレートは、読み取り／書き込みハードディスクアクセス時間、解析デマルチプレクサ帯域幅、またはオペレーティングシステムスケジューリング精度によって求められる。
【０４３０】
したがって、図１９を参照し直すと、ある特定のフレームレートをサポートできる指定特性のハードウェアについて、及び指定される巻き戻しまたは早送り速度について、ＨＤＶＲは、ビットストリーム中の時間６４００、６４０４、６４０８、及び６４１２で等しく間隔をあけて置かれる点に対応するファイル内の点にあるデータを、ＨＤＶＲ索引を使用して位置を突き止め、復号し、表示する。やはりＨＤＶＲ索引に対応する点６４０２、６４０６、及び６４１０は省略される。しかしながら、ハードウェアがより小さいフレームレートだけをサポートできる変形（図示されていない）においては、点６４００と６４２にあるデータだけが、位置を突き止められ、復号され、表示され、データポイント６４０４、６４０２、６４０６、６４０８及び６４１０は省略される。巻き戻しまたは早送りの円滑さは第２のケースで低下してよいが、ビットストリーム中の点６４００と６４１２の間でデータを表示するためにかかる時間は同じであるため、巻き戻しまたは早送りの速度は両方のケースで同じである。
【０４３１】
好ましい実施形態においては、プロセッサは、システムハードウェアの特性にアクセスし、最大フレームレートを動的に計算する。このような実施形態の変形においては、プロセッサは、許される最大フレームレートを計算する際に記憶されるビットストリームの特性にもアクセスする。
【０４３２】
代わりに、システムハードウェアの特性、及び許される最大フレームレートは、ＨＤＶＲで事前に記憶される。追加の変形においては、データが早送り動作または巻き戻し動作中にファイルから読み取られる速度は変わらず、いくつかのこのような変形ではすべてのこのようなデータが読み取られる。
【０４３３】
ビットストリーム特性に依存する索引表の自動作成
好ましい実施形態において、ＵＳＥＲ索引とＨＤＶＲ索引などの索引は、プロセッサによるビットストリームデータの特性の分析に依存して自動的に作成または削除される。例えば、１つの変形において、ＨＤＶＲに含まれるこのようなプロセッサは、ビットレートが値の特定の範囲内である、ビットストリームの部分に対応する索引を作成する。このような値は、ユーザによって定義されるアルゴリズムの動作によって設定できる。
【０４３４】
例証として、図２１に描かれているように、１つの変形においては、索引は、ユーザによって設定された、ある特定の値６６００を超えてビットレートが上昇する点で作成される。これらの点で開始するビットストリームの部分は、例えば、フィルムの中のアクションシーケンスに対応してよい。追加の変形においては、プロセッサはプログラムで制御でき、ビットストリームデータの特性の分析に対する依存性は変えることができる。
【０４３５】
追加の変形においては、プロセッサはユーザアクションを分析し、この分析に依存して、ＵＳＥＲ索引とＨＤＶＲ索引を含む索引を作成または削除する。プロセッサはプログラムで制御でき、この依存性は変えることができる。このような依存性の一例においては、さらに多くの索引が、ユーザが多数のアクションを実行しているビットストリーム中の点に対応して作成される。
【０４３６】
追加の変形においては、データは、ユーザの命令時にテーブルに、または関連付けられるテーブルまたはファイルに挿入され、このデータは、特定のデータオフセットまたはＵＳＥＲ索引、またはＨＤＶＲ索引によって参照される、関連付けられるタイムオフセットと関連付けられる。このようなデータは、画面上に表示されるコメント、及びテレビ制御コマンドなどのコマンドを含み、特に、親の制御機構を起動、または停止するデータを含む。このような親制御機構は、一般的には特定の章に向けられるが、一定の変形においては、それは暗号期間及び複数の暗号期間、及びファイルのユーザによって定義される部分にも向けられる。いくつかのこのような変形においては、ユーザは、アクセスを制御することを希望する記録されたフィルム内の特定の場面を選択できる。
【０４３７】
出力データ
一般的には、例えば、前述されたように、ＣＭＭテーブルを使用してなど、ＨＤＶＲ索引及びＵＳＥＲ索引を使用して、ＨＤＶＲファイル内に配置されるデータが、それがＭＰＥＧなどの圧縮プロトコルの対象となり、ディスプレイ装置、通常テレビ画面に出力される場合には、復号され、復元される。しかしながら、一定の実施形態においては、このようなデータは、復号または復元されて、あるいは復号または復元されずに、大容量記憶装置に、またはプロセッサに出力することもできる。
【０４３８】
追加の詳細は、ここで索引表の構造と作成、及び暗号化されたコンテンツをプレイバックする際の索引表の使用に関して提供される。
【０４３９】
ＨＤＶＲ索引とＵＳＥＲ索引は、前述されたように、索引表、Ｉｎｄｅｘ＿Ｔａｂｌｅ（）と呼ばれる同じテーブルの中にいっしょに記憶される。
【０４４０】
索引表のＨＤＶＲ部分は、時間的に周期的に連続するＨＤＶＲ索引記述子の一次元アレイである。
【０４４１】
各ＨＤＶＲ索引記述子は、以下の情報を含む。
【０４４２】
・ＨＤＶＲ索引位置を定めるＨＤＶＲファイルのコンテンツ部分Ｈｄｖｒ＿ｆｉｌｅ＿ｃｏｎｔｅｎｔ＿ｄａｔａ内の（ブロックの数単位の）ファイルオフセット（ＨｄｖｒＩｎｄｅｘＡｄｄｒｅｓｓ［１．．．ＭａｘＨｄｖｒＩｎｄｅｘＮｕｍｂｅｒ］）。ＳＴＳはブロックに分割され、ファイルオフセットによって指されるＳＴＳ部分は、ＨＤＶＲ索引記述子アレイの中へのＨＤＶＲ索引位置に比例する（ＳＴＳの始まりから測定される）時間日付に対応する。ｎ番目の索引は、ＳＴＳの開始以来経過したｎｘＨｄｖｒ＿ｔｉｍｅ＿ｓｔａｍｐ秒に対応する点までマッピングする。
【０４４３】
・どのＣＭＭ記述子（ＣＭＭ＿Ｉｄ）が、特定のＨＤＶＲ索引によって指されるＳＴＳの部分を解読するために必要とされるのかを定めるＣＭＭファミリ索引（ＨｄｖｒＩｎｄｅｘＣＭＭ［１．．．ＭａｘＨｄｖｒＩｎｄｅｘＮｕｍｂｅｒ］［１．．．ＣｏｍｐｏｎｅｎｔＮｕｍｂｅｒ］）のアレイ。ＣｏｍｐｏｎｅｎｔＮｕｍｂｅｒ構成要素（ビデオ、音声、テレテキスト）のそれぞれについて、対応するＣＭＭ＿ｔａｂｌｅのＣＭＭ＿ｉｄに対する参照が、索引ごとに指定され、それ以後の読み取り中のトリックモードを容易にする。
【０４４４】
・ＨＤＶＲ索引が属する章識別子、及び
・ＨＤＶＲ索引によって指されるＳＴＳ部分を正しく多重分離するために私用される私用ＰＭＴ識別子（ＨｄｖｒＩｎｄｅｘＰＭＴＶｅｒｓｉｏｎ［１．．．ＭａｘＨｖｄｒＩｎｄｅｘＮｕｍｂｅｒ］
最大サイズＭａｘＵｓｅｒＩｎｄｅｘＮｕｍｂｅｒの索引表のＵＳＥＲ索引部分は、ＵＳＥＲ索引記述子の一次元アレイである。ＵＳＥＲ索引が時間で並べ替えられていないことに注意する。それぞれのＵＳＥＲ索引（ＵｓｅｒＩｎｄｅｘ［１．．．ＭａｘＵｓｅｒＩｎｄｅｘＮｕｍｂｅｒ］は、事実上、特定のＳＴＳプレイエントリ点に対応する、特定のＨＤＶＲ索引に対する参照である。各ＵＳＥＲ索引は、以下の情報を含む。
【０４４５】
・ＵＳＥＲ索引がイネーブルされるのか、またはディスエーブルされるのかを定義するステータス、及び
・ユーザがブックマークを付ける（ＳＴＳの始まりとして基点を解釈する）ことを希望した時間−日付に対応するＨＤＶＲ索引参照（ＨｄｖｒＩｎｄｅｘ＿Ｉｄ）。該当するステータスがイネーブルされるときに、この情報が関連することに注意する。
【０４４６】
索引表の作成
索引表は、２つの段階で構築される。
【０４４７】
・ＨＤＶＲ索引表は、ファイルの記録時にｈｄｖｒ＿ｒｅｃｏｒｄｅｒによって計算される。
【０４４８】
・ユーザ索引表は、最初の記録後、空である。ユーザ索引を挿入するためにコマンドがｈｄｖｒ＿ｐｌａｙｅｒに送信されるのは、読み取り中だけである？。
【０４４９】
ｈｄｖｒ＿ｒｅｃｏｒｄｅｒによるＨｄｖｒ索引表の作成
Ｈｄｖｒ索引表は、ディスクを読み取るたびに計算され、更新される。
【０４５０】
・索引点、ＨｄｖｒＩｎｄｅｘＡｄｄｒｅｓｓ［ｎ］の計算の原則は、図２２に描かれるように、索引点の２つの読み取り値の間の線形補間に基づく。
【０４５１】
・対応するＣＭＭ、ＣｏｍｐｏｎｅｎｔＮｕｍｂｅｒ  ＣＭＭ＿Ｉｄは、それら自体、各読み取り時に計算される。各ＣＭＭ＿ｔａｂｌｅを綿密に調べる際に、人は現在の索引の位置ＨｄｖｒＩｎｄｅｘＡｄｄｒｅｓｓを各テーブルのＣＭＭ＿ｉｄによって特定される最後のＣＭＭのＢｌｏｃｋＮｕｍｂｅｒｓの位置と比較する。２つのケースが考えられる。
【０４５２】
・索引が実際に最後のＣＭＭの索引であることを意味するＨｄｖｒＩｎｄｅｘＡｄｄｒｅｓｓ＞ＢｌｏｃｋＮｕｍｂｅｒ［ＣＭＭ＿ｎｕｍｂｅｒ］であり、そのケースでは、ＨｄｖｒＩｎｅｘＣＭＭ＝ＣＭＭ＿ｎｕｍｂｅｒである。
【０４５３】
・あるいは、ＢｌｏｃｋＮｕｍｂｅｒ［ＣＭＭ＿ｉｄ］＜ＨｄｖｒＩｎｄｅｘＡｄｄｒｅｓｓ＜ＢｌｏｃｋＮｕｍｂｅｒ［ＣＭＭ＿Ｉｄ＋１］となるようにＣＭＭ＿ｔａｂｌｅの中にＣＭＭ＿ｉｄが存在し、そのケースではＨｄｖｒＩｎｄｅｘＣＭＭ＝ＣＭＭ＿ｉｄである。
【０４５４】
ファイルのサイズが単調に増加する関数であると、索引の補間が、つねに、いつでも書き込みポインタの後ろの位置を示すことに注意する。
【０４５５】
・ＨｄｖｒＩｎｄｅｘＰＭＴＶｅｒｓｉｏｎは、ＰＭＴテーブルが修正されるたびにその値を増分するカウンタである。この数はＰＩＤｓ／Ｃｏｍｐｏｎｅｎｔｓをリンクする全情報をともにリンクする構造を指す。値は索引ごとに更新される。
【０４５６】
ｈｄｖｒ＿ｐｌａｙｅｒによるユーザ索引表の作成
ユーザ索引表は、ファイルの読み取り時に記入される。ユーザは、アプリケーションを介して索引コマンドの挿入を送信し、関連付けられる索引点、ＵｓｅｒＩｎｄｅｘを適切に配置することはＨＤＶＲの責任になる。ユーザからアプリケーションへ、ＨＤＶＲへの反応時間を考慮すると、人は、Ｈｄｖｒ  Ｉｎｄｅｘサブテーブル内のエントリからそれを計算することを決定することによって索引の位置決めを簡略化できる。これは、索引点（ＨｄｖｒＩｎｄｅｘＴｉｍｅＳｔａｍｐ）の時間スペーシングが十分に小さい（１秒または１.５秒）であるときに正当化される。Ｈｄｖｒは、ＨｄｖｒＩｎｄｅｘＴｉｍｅＳｔａｍｐの最も近い倍数への索引の挿入の送信の時刻／日付を四捨五入してから、対応するＨｄｖｒ索引点、ＨｄｖｒＩｎｄｅｘ＿Ｉｄのアイデンティティを示すＵｓｅｒＩｎｄｅｘフィールドを満たす。
【０４５７】
索引表の使用
索引表の役割は、局所的な暗号解読に関する情報だけではなく、ファイルを読み取るためのエントリ点、ＨｄｖｒＩｎｄｅｘＡｄｄｒｅｓｓも提供することである。
【０４５８】
２つの方法が存在する。
【０４５９】
・索引表だけの使用
・記録中に挿入される索引表とセクションの共同使用、つまりさらに詳細に後述されるようなＥｖｔ＿Ｃａｓ＿Ｅｃｍ（１．．．ＣｏｍｐｏｎｅｎｔＮｕｍｂｅｒ）
索引表だけの使用
ファイルの読み取り時に索引表だけを使用することは、実現するのが非常に簡単である。この運転モードはトリックモード、つまりファイル内でのジャンプを必要とする早送り、または巻き戻しでは必須である。加えて、速度ｘ１の通常の読み取りモードでのその性能を試すことが有利である場合がある。
【０４６０】
使用の一例を示すために、毎秒１つずつ、９００の索引を含む長さが１５分のファイルを使用する以下のシナリオを取る。５分目から速度ｘ１で前方に読み取るために、コマンドが送信される。次に、以下の関数がＨＤＶＲによって実行される。
【０４６１】
・３００番目の索引、ｈｆｍｄでのＨｄｖｒＩｎｄｅｘに対する探索
・その索引ＨｄｖｒＩｎｄｅｘＡｄｄｒｅｓｓ［３００］に記憶されるアドレスを読み取り、現在位置、ｃｕｒ＿ｐｏｓを更新する。
【０４６２】
・その索引点、ＨｄｖｒＩｎｄｅｘＣＭＭ［３００］［１．．．ＣｏｍｐｏｎｅｎｔＮｕｍｂｅｒ］に対応するＣＭＭを読み取り、現在のＣＭＭ、ｃｕｒ＿ＣＭＭ［１．．．ＣｏｐｏｎｅｎｔＮｕｍｂｅｒ］を更新する。
【０４６３】
・要すれば、適切なＨｄｖｒＩｎｄｅｘＣｍｍ［３００−ｎ．．．３００＋ｎ］［１．．．ＣｏｍｐｏｎｅｎｔＮｕｍｂｅｒ］をロードすることを見越して表を構築または更新する。
【０４６４】
次に、ＨＤＶＲ＿ＵＳＥＲは、現在のＣＭＭ、ｃｕｒ＿ＣＭＭ［］の識別子をＣＭＰＳに送信し、制御ワードを回収し、構成要素を逆スクランブルする。
【０４６５】
ファイル、１秒の読み取りに相当するＨｄｖｒＩｎｄｅｘＡｄｄｒｅｓｓ［３０１］−ＨｄｖｒＩｎｄｅｘＡｄｄｒｅｓｓ［３００］ブロック内で前方に読み取る要求が続く。
【０４６６】
Ｅｖｔ＿Ｗｒｉｔｅ＿Ｆｉｆｏ＿Ｃｏｍｐｌｅｔｅｄの時点で、先行するコマンドが３０１番目のＨｄｖｒＩｎｄｅｘに対して繰り返される。
【０４６７】
この解決策の優位点は、逆スクランブルプロセスの、及び索引表内でのナビゲーション同期にある。ＣＷの非同期修正はない。
【０４６８】
重要な落とし穴は、ＣＭＭ位置のこの演算による二重予想である。
【０４６９】
・記録時の恒久的な体制での最大持続時間ｃｒｙｐｔｏｐｅｒｉｏｄ／ｓｅｃｕｒｉｔｙ＿ｃｏｅｆｆｉｃｉｅｎｔ秒の、及び重大な遷移体制での暗号期間秒の第１の過大評価
・記録時のＨｄｖｒＩｎｄｅｘＴｉｍｅＳｔａｍｐの最大持続時間の第２の過大評価
ＣＭＭが２暗号期間に適用することを知っていると、約１秒というこの最後の概算は、速度ｘ１の読み取りモードでのデータの逆スクランブルを混乱させてはならない。トリックモードにあるのでなおさら、この解決策は実行不可能になる。
【０４７０】
記録時に挿入される索引表とセクションの共同使用
ファイルの記録時に、暗号期間ごとに、及び構成要素ごとに、読み取り時にＭｌｏａｄデバイスによってフィルタリングされ、人がｈｆｍｄに含まれるものだけではなく、ＳＴＳのＣＷの変化に関する情報も得ることができるようにするセクションが挿入される。
【０４７１】
残念なことに、記録時のＣＭＭ＿ｔａｂｌｅ内のＣＭＭ位置の概算のため、ＳＴＳストリームＥｖｔ＿ＣＡＳ＿Ｅｃｍ（１．．．ＣｏｍｐｏｎｅｎｔＮｕｍｂｅｒ）のＣＭＭ情報と、ｈｆｍｄ、ＨｄｖｒＩｎｅｘＣＭＭ［１．．．ＨｄｖｒＩｎｄｅｘＮｕｍｂｅｒ］［１．．．ＣｏｍｐｏｎｅｎｔＮｕｍｂｅｒ］に含まれる情報の間に可変不一致がある。この不一致を理解するために、図２３に描かれるように、ＣＷ（ｎ−）からＣＷ（ｎ）までのｎ番目の遷移を考える。
【０４７２】
ｃｕｒ＿ＣＭＭを変更するために、挿入されたセクションを使用して読み取りを実行する。
【０４７３】
索引１から、
・ｃｕｒ＿ＣＭＭ、つまりＨｄｖｒＩｎｄｅｘＣＭＭ［ｉ］＝ＣＭＭ＿１ｄ（ｎ）を更新する。
【０４７４】
・索引ｉ＋１まで読み取る。
【０４７５】
・ｉとｉ＋１の間にはセクションはない
ｃｕｒ＿ＣＭＭとＨｄｖｒＩｎｄｅｘＣＭＭ［＋１］の比較
・同じ値
・索引ｉ＋２までを読み取る。
【０４７６】
１／ＳＴＳのレベルでのＣＷの変更
２／事前に挿入されたセクション上のＭｌｏａｄがＥｖｔ＿Ｔｏｐ＿Ｅｃｍを生成する。
【０４７７】
３／ＣＭＭ＿Ｉｄ（ｎ＋１）になるｃｕｒ＿ＣＭＭの増加
・ｃｕｒ＿ＣＭＭ＝ＣＭＭ＿ｌｄ（ｎ＋１）とＨｄｖｒＩｎｄｅｘＣｍｍ［ｉ＋２］Ｃ
ＭＭ＿Ｉｄ（ｎ）の比較
・注意、ｈｆｍｄの値は１つの索引によって遅らされる。
【０４７８】
・索引ｉ＋３まで読み取る
・ｉ＋２とｉ＋３の間にセクションはない。
【０４７９】
・ｃｕｒ＿ＣＭＭ＝ＣＭＭ＿Ｉｄ（ｎ＋１）とＨｄｖｒＩｎｄｅｘＣＭＭ［ｉ＋３］＝ＣＭＭ＿Ｉｄ（ｎ＋１）の比較
・同じ値
・索引のｒｅｔａｒｄａｌが有効にされる。
【０４８０】
読み取りは、ときおり索引のｒｅｔａｒｄａｌを生じさせるが、この問題は補償できる。
【０４８１】
逆に、アプリケーションが索引ｉ＋２からの読み取りを要求すると、セクションと索引を組み合わせて使用した結果、悲惨であることが判明することがある。
【０４８２】
・ｃｕｒ＿ＣＭＭ、つまりＨｄｖｒＩｎｄｅｘＣＭＭ［ｉ＋２］＝ＣＭＭ＿Ｉｄ（ｎ）を更新する。
【０４８３】
・索引ｉ＋３まで読み取る。
【０４８４】
・ｉ＋２とｉ＋３の間にセクションはない。
【０４８５】
・ｃｕｒ＿ＣＭＭ＿Ｉｄ（ｎ）とＨｄｖｒＩｎｄｅｘＣＭＭ［ｉ＋３］＝ＣＭＭ＿Ｉｄ（ｎ＋１）の比較
不思議なことに、ｈｆｍｄの値は先んじて索引までである。したがって、人は挿入されたセクションを見逃した。
【０４８６】
２つのケースが現れる。
【０４８７】
・人は、ｃｕｒ＿ＣＭＭを信頼し、遅れたＥｃｍ（危険）を保つ。
【０４８８】
・人はＨｄｖｒＩｎｄｅｘＣＭＭ［ｉ＋３］、このケースでは挿入されたセクションの使用を信頼する。
【０４８９】
結論として、ファイル内の位置は、ブロック内の位置が過大評価されるｈｆｍｄを介して作成されるため、記録されたファイルのプレイバック中に挿入されたセクションを使用するのは問題が多い。したがって、２種類の相容れない同期情報をまとめることは危険であり、誤りの元である。
【０４９０】
・（ＨｄｖｒＩｎｄｅｘまたはＣＭＭ＿Ｔａｂｌｅ内の）ｈｆｍｄでの位置の情報
・ＳＴＳで挿入されるセクション
以下の場合に、同期の適性が十分である索引表の固有の同期の根拠を決定的に選ぶことはさらに筋が通っているだろう。
【０４９１】
・Ｅｃｍ位置の推定のプロセスが有効である（さらに詳しく後述されるように、ハイブリッドフィルタ）場合、
・ＣＷ遷移の位置についてＨｄｖｒＩｎｄｅｘＴｉｍｅＳｔａｍｐが十分に小さい場合（つまり、＜Ｃｒｙｐｔｏｐｅｒｉｏｄ＝Ｅｃｍ回復時間）
ＣＭＭの同期に関するさらに詳しい説明、及びビットストリーム位置の推定が、以下に示される。
【０４９２】
ＨＤＶＲファイルの構造
ＨＤＶＲファイルの構造の説明に戻ると、前述されたように、それらは管理データ（例えば、ｈｄｖｒ＿ｆｉｌｅ．ｍａｎａｇｅｍｅｎｔ＿ｄａｔａ）及びコンテンツデータ（例えば、ｈｄｖｒ＿ｆｉｌｅ．ｃｏｎｔｅｎｔ＿ｄａｔａ）を備える。
【０４９３】
好ましい実施形態においては、ｈｄｖｒ＿ｆｉｌｅ＿ｍａｎａｇｅｍｅｎｔ＿ｄａｔａ（）は、ＨＤＶＲファイルに割り当てられるｎ個の第１クラスタに含まれ、ｈｄｖｒ＿Ｆｉｌｅ＿ｃｏｎｔｅｎｔ＿ｄａｔａ（）は続くクラスタで開始する。
【０４９４】
ファイルへのアクセスを簡略化するために、管理データには第１ファイル記述子、及び記憶済みトランスポートストリーム（ＳＴＳ）には第２ファイル記述子がある。
【０４９５】
ＨＤＶＲファイルの管理部分に含まれる他のテーブル
ｈｄｖｒ＿ｆｉｌｅ＿ｍａｎａｇｅｍｅｎｔ＿ｄａｔａ（）を構成し、前記に一覧表示された多様なテーブルが、ここにさらに詳しく説明される。
【０４９６】
ＣＭＭテーブル
ＣＭＰＳによって提供されるＣＭＭ情報は、専用の二次元テーブル内のＨＤＶＲサーバによって記憶される。ＣＭＭテーブルの各要素は、２つの座標に従って記憶される。
【０４９７】
第１に、ＣＭＭ記述子が属する特定のＣＭＭファミリを指すＣＭＭテーブル識別子
第２に、特定のＣＭＭファミリ内のＣＭＭ記述子の特定のＣＭＭ索引を指すＣＭＭ識別子
ＣＭＭテーブルの各要素は、ＣＭＭ記述子として分類され、以下の情報を含む。
【０４９８】
・ＨＤＶＲがこのＣＭＭファイルオフセットから次のＣＭＭファイルオフセットまでＳＴＴを解読できるようにするＨＤＶＲファイルコンテンツデータに関係するＣＭＭ位置のブロック内のファイルオフセット
・この特定のＣＭＭを参照するための第１ＨＤＶＲ索引（これは、ＨＤＶＲ索引表とＣＭＭの間の相互参照である）
・ＣＭＰＳによって定義されるようなＣＭＭ構造
章テーブル
章の概念は、ＤＶＤの概念に類似している。特定の実施形態においては、記録は、つねに少なくとも１つの章を含む。章はプレイエントリポイントでもあり、章はＨＤＶＲ索引にリンクされている。それらの特性（以下を参照すること）だけではなく章開始マーカも、記録段階時に、ＣＭＰＳによって提供されるＣＭＭによって運ばれる。記録は、最大数のＭａｘＣｈａｐｔｅｒＮｕｍｂｅｒ章を備える。
【０４９９】
章は、章の最大数、ＭａｘＣｈａｐｔｅｒＮｕｍｂｅｒを含む、Ｃｈａｐｔｅｒ＿Ｔａｂｌｅ（）と呼ばれる単一のテーブルの中にともに記憶される。
【０５００】
章情報は、２つの別個のソースから生じる。
【０５０１】
・第１に、ＨＤＶＲ章テーブルから
・第２に、章情報は、放送局からの記録の間に提供され、ＨＤＶＲがＣＭＭ章制御と定義するものを保持する特殊ＣＭＭの中に要約される。追加の変形においては、このＣＭＭ章制御は、既存のＭＰＰＶに類似した様式で視聴権を保持する。
【０５０２】
同じ構造の中に章記述子に関係するすべての情報を集めるために、特殊ＣＭＭに対する参照が、ＣＭＭ章制御の座標として各章記述子の中に挿入される。
【０５０３】
章テーブルは、ＨＤＶＲ章記述子の一次元アレイである。各章記述子は、以下の情報を含む。
【０５０４】
・（ＳＴＳの始まりとして基点を解釈し）章によってブックマークが付けられる時間−日付に相当するＨＤＶＲ索引基準（ＨｄｖｒＩｎｄｅｘ＿Ｉｄ）
・章持続時間
・休止、早送り、早巻き戻し等などのトリックモードごとに、特定のトリックモードがイネーブルされているのか、あるいはディスエーブルされているのかを指定するトリックモードビットマップ。このトリックモードは、章全体に適切である。
【０５０５】
・特定のＨＤＶＲアルゴリズムに従って親制御データ構造と比較され、章が、例えば、ユーザのＰＩＮコード及び現在の章の道徳的なコンテンツに従って、視聴可能かどうかを定める制御視聴ワード。
【０５０６】
・特殊ＣＭＭ座標（前述されたように、いわゆるＣＭＭ章制御）
私用ＰＭＴテーブル
私用ＰＭＴ（番組マップテーブル）は、記録された、あるいはまもなく記録されるサービスの構成要素の活用に必要な情報の在庫調べをするＨＤＶＲに属するＰＭＴである。それは、一方が（構成要素の内容について知っている）クライアントによって提供され、他方が（構成要素ごとにアクティブな条件付きアクセス（ＣＡ）ＰＩＤを知っている）ＣＭＰＳによって提供される２つの擬似テーブルを備える。
【０５０７】
記録中、記録されるサービス計画を修正することができる。したがって、記録に適用可能な１つまたは複数の私用ＰＭＴがある。ＳＴＳに挿入される１つのＭＰＥＧセクションは、記録されるサービス計画の各進展を記す。さらに、ＨＤＶＲは、記録されるビットストリーム中の最高３つの他のＭＰＥＧセクションを挿入する。
【０５０８】
適用可能な私用ＰＭＴの数は、ＭａｘＰｒｉｖａｔｅＰＭＴＮｕｍｂｅｒに制限される。
【０５０９】
それらは、最大私用ＰＭＴ、ＭａｘＰｒｉｖａｔｅＰｍｔＮｕｍｂｅｒの在庫を調べるＰｒｉｖａｔｅ＿Ｐｍｔ＿Ｔａｂｌｅ（）と呼ばれるテーブルの中にいっしょに集められ、それぞれが構成要素ＭａｘＣｏｍｐｏｎｅｎｔＮｕｍｂｅｒの在庫を調べる。
【０５１０】
私用ＰＭＴテーブルは、私用ＰＭＴ記述子の一次元アレイである。ＨＤＶＲ私用ＰＭＴ記述子は、共通ＭＰＥＧ−２によって定義されるＰＭＴのＨＤＶＲによって定められる実施形態である（追加の情報については、ＩＳＯ／ＩＥＣ  １３８１８を参照すること）。
【０５１１】
以下の情報は、ＨＤＶＲ私用ＰＭＴを作成するためのＰＭＴのようなＩＳＯに追加／削除される。
【０５１２】
・ＨＤＶＲ使用のＰＩＤ情報。事実上、ＨＤＶＲは、ＳＴＳを得るために、独自のＰＩＤのいくつかをオリジナルＴＳの中に挿入する。
【０５１３】
・記録されていない構成要素に関係するＰＩＤ情報は、ＳＴＳを得るためにオリジナルＴＳから削除される。ＣＡ態様はＣＭＰＳによって管理され、ＨＤＶＲは直接的にＣＡコンテンツに対処しないため、構成要素ごとにＣＡ＿ＰＩＤ情報（ＣＡは、この文脈では条件付きアクセスの略語である）が削除される。
【０５１４】
・構成要素ごとに、ＨＤＶＲが暗号化されたＳＴＳをプレイバックできるようにするために、なんらかのＣＭＭ情報が追加される。したがって、構成要素が依存するＣＭＭファミリが指定される。
【０５１５】
・ＨＤＶＲ内部使用、ＣＭＭ章制御が属するＣＭＭファミリが指定される。
【０５１６】
・現在の使用ＰＭＴ記述子が適切であるＨＤＶＲファイルコンテンツデータに関係する私用ＰＭＴ記述子位置のブロック内のファイルオフセット。
【０５１７】
・その基点が、現在の私用ＰＭＴ記述子が適切であるＳＴＳの始まりである時間−日付に対応するＨＤＶＲ索引基準
権利及び親制御データテーブル
権利は、番組の再生に関連付けられる許可に関する情報を一まとめにし、いったん番組が記録されると、すべて供給される。
【０５１８】
この情報は、Ｐａｒｅｎｔａｌ＿Ｃｏｎｔｒｏｌ＿Ｄａｔａ（）と呼ばれる単一テーブルにいっしょに記憶される。
【０５１９】
親制御データ構造は、視聴権利制御に章の粒度を与える。それは、２つの異なるプロセスに従って、章セクションまたはファイル全体へのアクセスを許すまたは禁じるためにＨＤＶＲサーバによって使用される。
【０５２０】
・親制御データＰＩＮコードと、ＰＶＲ制御（ＰＶＲは、ビデオ録画機能性の高水準エンドユーザＡＰＩであるパーソナルビデオレコーダの略語である）などの外部制御を含むユーザ独自のＰＩＮコードレベルの比較。アクセス制御は、ＨＤＶＲトラックファイル全体に適している。
【０５２１】
・ＨＤＶＲ章テーブルの章ごとの親の称制御ワードを関連付ける）特定の親制御テーブル間の比較。特定の実施形態においては、それは視聴制御機構をイネーブルまたはディスエーブルする。視聴制御がある特定の章についてイネーブルされる場合には、ＨＤＶＲサーバはグローバルな親視聴制御ワードを関係する章視聴制御ワードに比較し、関係する章が開始する前に休止モードにオートマトンを強制する等の内部ＨＤＶＲアルゴリズムに従ってＨＤＶＲオートマトンプレーヤ状態を固定する。
【０５２２】
一定の実施形態においては、ＨＤＶＲは、親制御データに対する自由な書き込み／読み取りアクセスを提供し、このような実施形態においては、ＨＤＶＲは、親制御機構の効率に対して責任を負うことはできない。
【０５２３】
最大値テーブル
管理データ構造を動的にするために、テーブルのそれぞれの最大サイズがＨＤＶＲファイルのヘッダに提供される。このテーブルは、Ｍａｘ＿Ｖａｌｕｅ（）と呼ばれる。
【０５２４】
最大値の役割とは、ＨＤＶＲファイル管理データの動的構造を担うことである。したがって、一般情報基本構造を除き、前記に宣言されたＨＤＶＲ構造ごとに、最大値構造はそのオフセット及び長さをＨＤＶＲファイル管理データの中に指定する。これは、互換性の問題なく内部フォーマットを拡張するための容易な機構を提供する。したがって、例えば、旧いＨＤＶＲサーバは、ファイヤワイヤバスを介して２つの異なるＳＴＢの間でエクスポートされるＨＤＶＲファイルのケースで、より新しいＨＤＶＲファイルトラックを読み取ることができる。
【０５２５】
一般性及び一般情報テーブル
一般性は、記録された番組に関する一般情報を一まとめにする。それらは、Ｇｅｎｅｒａｌ＿Ｉｎｆｏｒｍａｔｉｏｎ（）と呼ばれるテーブルに記憶される。
【０５２６】
一般情報は、以下の一覧（ａｔ  ａ  ｓｉｇｈｔ）情報を含む。
【０５２７】
・ＣＭＰ私用情報、いわゆるＣＭＰＳファイル識別子。個の情報がＣＭＰＳ読取専用モードであり、ＨＤＶＲサーバＡＰＩを通過しないことに注意する。
【０５２８】
・カレントＨＤＶＲファイルトラックを作成するＨＤＶＲサーババージョン番号
・あるＨＤＶＲ索引から次のＨＤＶＲ索引まで経過したデルタ時間。それは、ＨＤＶＲ索引サンプリング期間として見ることもできる。
【０５２９】
・ＨＤＶＲファイルトラックの総持続時間
・ブロック単位の総ＳＴＳサイズ
・現在の許容タイムシフト深度。ナル値が、例えばファイル記録の共通ケースにおける無限タイムシフト深度と見なされることに注意する。
【０５３０】
・そのＨｄｖｒファイル管理データオフセット及びその長さごとに指定されるクライアント私用ゾーンの定義。ＨＤＶＲサーバＡＰＩがこの専用ゾーンに読み取り／書き込みアクセスを提供しないことに注意する。クライアントゾーン入力／出力動作はクライアントの責任である。
【０５３１】
・さまざまな以下の許容状態からの記録モード
・ユーザ瞬間記録用の即時モード
・例えば、商業的なオファーをアップロードするための放送局の特別使用用のプッシュモード
・1回限りの区別された記録のためのプログラミングされたモード
・定期的な区切られた記録のための定期的なプログラミングされたモード
・タイムシフトモード
・並行ファイルアクセスを回避するために、現在ＨＤＶＲファイルトラックを再生中のＨＤＶＲサーバがある場合には、ＨＤＶＲプレーヤサーバ識別子
・並行ファイルアクセスを回避するために、現在ＨＤＶＲファイルトラックを記録中のＨＤＶＲサーバがある場合には、ＨＤＶＲレコーダサーバ識別子
ＨＤＶＲ管理データの記憶
ｈｄｖｒ＿ｆｉｌｅ．ｍａｎａｇｅｍｅｎｔ＿ｄａｔａの場合、ＣＭＭテーブル（ＣｍｍＴａｂ）は大きなテーブル（数メガバイト）であり、それを充填することは、一斉送信特性及び記録される番組の持続時間に依存する。ＣｍｍＴａｂがディスク上で不必要に空間を占有するのを回避するために、テーブルは、最大値（ＣｍｍＭａｘＮｕｍｂｅｒ）でディスク上に作成されるのではなく、徐々に記録中に作成される。他方、（内部暗号化のケースでの）さまざまなＣｍｍＴａｂを達成するためのオフセットは、ＣｍｍＭａｘＮｕｍｂｅｒ値を考慮に入れる。
【０５３２】
したがって、図２４に関して、人は、穴から構成されるｈｄｖｒ＿ｆｉｌｅ．ｍａｎａｇｅｍｅｎｔ＿ｄａｔａをディスク上に得る。
【０５３３】
図２４は、ファイルがその有効ディスク割り当てサイズより優れた仮想サイズを有することを可能にするＧＦＳライブラリの特殊機能性を描く。例えば、ＨＤＶＲファイル管理データは、２０時間という総ＨＤＶＲトラック持続時間の完全な管理を提供できる仮想サイズを有する。しかしながら、一般的には、ＨＤＶＲトラックの長さは２時間または３時間にすぎない。ＧＦＳライブラリ穴あきファイル特徴に機能に従って、ＨＤＶＲファイル管理データの仮想サイズは、完全に割り当てられていない。つまり、いくつかの割り当てられていないクラスタがｈｄｖｒ＿ｆｉｌｅ．ｍａｎａｇｅｍｅｎｔ＿ｄａｔａオフセット範囲内に提示される。
【０５３４】
ＨＤＶＲコンテンツデータ――記憶済みトランスポートストリーム
ＨＤＶＲによって記憶される管理データの説明を離れ、記憶済みコンテンツの構造に関する説明に戻ると、ＳＴＳ（記憶済みトランスポートストリーム）がここにさらに詳細に説明される。
【０５３５】
ＳＴＳは、ＨＤＶＲによって記録されるビットネームに与えられる名前であり、以下のデータから構成される。
【０５３６】
・記録されるサービスの再生可能なデータ（クライアントの選択）
・ビデオデータの１つまたは複数のセット
・音声データの１つまたは複数のセット
・字幕の１つまたは複数のセット
・テレテキスト情報
・ＨＤＶＲによって挿入されるデータ
ＨＤＶＲによって挿入されるデータは、ＭＰＥＧセクションの形を取り、他のところでＨＤＶＲ＿＜ｓｅｃｔｉｏｎ＿ｎａｍｅ＞＿ＳＥＣＴＩＯＮと呼ばれる。
【０５３７】
ＨＤＶＲ＿ＮＥＷ＿ＰＭＴ＿ＳＥＣＴＩＯＮは、各記録済みサービス計画の変更を記すために挿入される。
【０５３８】
ＳＴＳの中にはＭａｘＰｒｉｖａｔｅＰｍｔＮｕｍｂｅｒ−１  ＨＤＶＲ＿ＮＥＷ＿ＰＭＴ＿ＳＥＣＴＩＯＮセクションの最大がある。
【０５３９】
ＨＤＶＲ＿ＴＩＭＥ＿ＴＡＧ＿ＳＥＣＴＩＯＮセクションは、ＳＴＳの再生中に経過した時間の表示を提供するために定期的に挿入される。このセクションは、オプションである。
【０５４０】
ＨＤＶＲ＿ＣＡＳ＿ＥＣＭ＿ＳＥＣＴＩＯＮセクションは、再生可能データ（ＤＶＢ−ＣＳ）の内部暗号化のケースだけで使用され、暗号期間の始まりを記すために挿入される。
【０５４１】
ＨＤＶＲ＿ＣＡＳ＿ＥＣＭ＿ＳＥＣＴＩＯＮは、ＳＴＳの再生中に、関連付けられた再生可能構成要素のためのＣＷの変更のシグナリング、したがってデスクランブラ内で新しい組を適用することを可能にする。
【０５４２】
記録サービスのために区別可能なＥＣＭ  ＰＩＤを？？数多くの異なるＨＤＶＲ＿ＣＡＳ＿ＥＣＭ＿ＳＥＣＴＩＯＮセクションがある。したがって、ＨＤＶＲ＿ＣＡＳ＿ＥＣＭ＿ＳＥＣＴＩＯＮセクションタイプは、各ＣＭＭファミリと関連付けられている。
【０５４３】
データのレコーディング
最後に、ＨＤＶＲによるコンテンツのレコーディングのプロセスに関していくつかの追加の詳細が提供され、内部暗号化と外部の暗号化のケースが調べられる。
【０５４４】
図２５は、ＨＤＶＲ制御装置と大容量記憶装置間のデータの流れを描く。大容量記憶装置に移動する、及び大容量記憶装置から生じるデータは、さまざまなサイズであってよい、ＦＩＦＯ（先入れ先出し）メモリを介して伝送される。
【０５４５】
レコーディングは、ＭａｘＣｍｍＮｕｍｂｅｒ  ＣＭＭの最大を備える。返されるＣＭＭは、暗号化された部分及び別の明瞭な部分を含み、後者だけがＨＤＶＲによって直接的に利用可能である。つまり、それはＣＭＭに関連付けられるＳＴＳ部分に対するナビゲーションと制限の制約を与える。
【０５４６】
ファイルの粒度はブロックであるため、ＣＭＭはそれ自体を連続ブロックの集合体に適用する。ＳＴＳ内でのＣＭＭの適用の開始点は、ブロック番号によって特定される。
【０５４７】
内部暗号化
内部暗号化の場合、再生可能なデータは、デマルチプレクサ２３０を離れると暗号化されたままとなり、修正なしで記録され、その結果、再生可能なデータの暗号解読は再生時に行われる。暗号解読キーは１つまたは複数のＥＣＭ  ＰＩＤで運ばれるＥＣＭを使用して一斉送信され、１暗号期間有効である。暗号期間の変更は一斉送信内に信号で知らされる。暗号解読キーは、ＣＭＰＳサーバのサービスを使用することによって、新暗号期間ごとにＨＤＶＲサーバによって回収される。
【０５４８】
内部暗号化の場合、ＭａｘＣｍｍＮｕｍｂｅｒ制限内での記録の持続期間のための暗号期間と同じ数のＣＭＭがある。つまり、暗号化は時間的であると言われる。
【０５４９】
とりわけ、各ＣＭＭは、１つまたは複数の再生可能な構成要素の１暗号期間の再生中に平文に直すことを可能にする（ＣＷ：制御ワードと呼ばれる）1組のキーを運ぶ。ＣＷは、ＣＭＭの暗号化されたゾーン内で見つけられ、ＨＤＶＲによって直接的に利用可能ではない。ＣＭＰＳに利用可能なＣＷを要求することは必要ではない。
【０５５０】
この種の暗号化の場合、再生可能な構成要素の１つまたはいくつか、あるいはすべてにも適用可能なサービスとしてＥＣＭがある場合がある。結果的に、ＣＭＭはＣＭＭファミリごとに一まとめにされ、この数はＥＣＭ  ＰＩＤファミリの数――すなわち、番組マップテーブル（ＰＭＴ）の中で参照される別個のＥＣＭＰＩＤによって決定される。これらのファミリのそれぞれに対し、例えば、関連付けられる、従属する暗号化された構成要素がある。
【０５５１】
ＥＣＭ  ＰＩＤ  Ｘは、再生可能なビデオ構成要素のためのキー組を一斉送信する。
【０５５２】
ＥＣＭ  ＰＩＤ  Ｘは、再生可能な音声構成要素のためのキー組を一斉送信する。
【０５５３】
ＥＣＭ  ＰＩＤ  Ｙは、再生可能なテレテキスト構成要素のためのキー組を一斉送信する。
【０５５４】
ＥＣＭ  ＰＩＤ  Ｚは、再生可能な字幕構成要素のためのキー組を一斉送信する。
【０５５５】
この例の場合、３つのＣＭＭファミリがある。対応表が、再生可能なデータとＣＭＭファミリの間の関連付けを定義する。サービス計画の変更のケースでは、新しい対応表が定義されるだろう。つまり、新しいＥＣＭ  ＰＩＤのために、新しいＣＭＭファミリが作成されるだろう。この暗号化の場合、考えられるＣＭＭファミリの数は、ＨＤＶＲサーバで記録できる再生可能な構成要素の数に等しくなるだろう。
【０５５６】
外部暗号化
外部暗号化の場合、再生可能なデータは、デマルチプレクサ２３０を離れると、自由であり、このデータの暗号化はディスクでの書き込み時に行われ、暗号解読は再生時に行われる。適用される平文に直すキーは、ＣＭＰＳによって決定され、ＣＭＰＳサーバのサービスを使用することによってＨＤＶＲサーバによって回収される。
【０５５７】
外部暗号化の場合、ＭａｘＣｍｍＮｕｍｂｅｒ制限内の記録に適用可能なキーがあるのと同じ数のＣＭＭがある場合がある。これらのＣＭＭの記録上での割り当ては、ＨＤＶＲの責任である。暗号化は、空間的であると言われる。
【０５５８】
各ＣＭＭは、記録サービスのすべての再生可能な構成要素の暗号化と暗号解読を可能にする（これ以降ＣＫと呼ばれる）キーを運ぶ。ＣＫはＣＭＭの暗号化されたゾーンで見つけられ、ＨＤＶＲによって直接的に利用できない。ＣＭＰＳに利用可能なキーを要求することが必要となるだろう。
【０５５９】
この種の暗号化の場合、つねにただ１つのＣＭＭファミリがある。
【０５６０】
ＣＭＭファミリは、ＭａｘＣｍｍＮｕｍｂｅｒ  ＣＭＭの最大を含むＣｍｍ＿Ｔａｂｌｅ（）と呼ばれるテーブルの中に一まとめにされる。
【０５６１】
ここで、ビットストリームの記録及びプレイバック手順が、さらに詳しく説明されるだろう。記録手順は、後のプレイバックプロセスのために制御ワードが同期されるだろう美とストリーム中の位置の概算を含む。概算は、この記録技法が、機密保護及び最小処理と記憶の優位点を与えることができるようにするために必要とされる。
【０５６２】
好ましい実施形態の第２の一般的な態様を参照すると、ビットストリーム中の位置の概算及び条件付きアクセス情報のビットストリームとの同期が、ここにさらに詳細に説明される。
【０５６３】
ＣＭＭ同期
ビットストリーム同期
スクランブルされたビットストリームを記録することに関連付けられるいくつかの問題点とその解決策を説明する前に、このようなビットストリームの構造が、ここで図２６に関して説明されるだろう。
【０５６４】
図２６では、（放送センタから受信機／デコーダで受信されるものなどの）スクランブルされたＭＰＥＧビットストリーム１３００が描かれている。図示されるようなビットストリームは、それぞれが対応する制御ワードでスクランブルされる、連続する暗号期間８０００、８００２、８００４に分割される。ビットストリーム１３００は、暗号化済みエンタイトルメント制御メッセージ（ＥＣＭ）８０１０、８０１２、８１１４も含む。
【０５６５】
システムにある程度の冗長性（したがって耐障害性）を与えるために、各ＥＣＭは、事実上、１つが現在の暗号期間用、そして１つが続く暗号期間用である２つの制御ワードを含む。したがって、ＣＭ８０１０は、暗号期間ＣＰ７  ８０００とＣＰ８  ８００２の両方を逆スクランブルするための制御ワードを含む。同様に、ＥＣＭ８０１２は、暗号期間ＣＰ８  ８００２とＣＰ９  ８００４の両方を逆スクランブルするために必要な制御ワードを含む。事実上、ＥＣＭは、ユーザがチャネルを変更したり（「ザッピング」）、一時的な障害がＥＣＭの第1セットの受信を妨げる場合にシステムの続行される円滑な動作を確実にするために、周期的に再送される。簡単にするために、それぞれのこのようなシリーズの第１ＥＣＭだけが図示される。
【０５６６】
条件付きアクセススマートカード５５００は、典型的には、各ＥＣＭを平文に直すのに数秒を要するが、各暗号期間は相対的に長い（好ましい実施形態では１０秒）ため、通常、（放送センタから衛星を介して受信されるコンテンツなどの）ライブコンテンツを受信し、復号するケースでのタイミングにまつわる問題はない。
【０５６７】
（受信されたデジタルテレビ放送などの）音声／画像ビットストリームをハードディスクに記録し、その後プレイバックするケースでは、一般的には、記録に関係する条件アクセスデータが、記録の時間制限を克服するために（言い換えると、入信ＥＣＭを暗号化するために使用される時間変化するグローバル暗号化キーＫＧに対する依存性を取り除くために）、記憶前、記憶中、あるいは記憶後に操作されなければならないだろうため、タイミングはより問題となる。
【０５６８】
（音声／画像ビットストリームの形を取る）スクランブルされたコンテンツ８００を関連付けられたＥＣＭと同期させることが有利であることが判明し、その結果、制御ワード５６００は、コンテンツ８００を逆スクランブルできるようにするために、正しい時間にデスクランブラに送り込むことができる。さらに精密には、音声／画像ビットストリーム及び（前記に注記されたように、好ましくは、オリジナルＥＣＭの形を取る）条件付きアクセスデータを、音声／画像ビットストリーム及び条件付きアクセスデータを記憶するときに同期させることが役に立つことが分かった。同期プロセスは、好ましい実施形態においては、ＨＤＶＲ３８５０によって実行される。代わりに、同期プロセスはＣＭＰＳシステム２３００によって実行される。
【０５６９】
同期プロセス中、条件付きアクセスデータとビットストリーム中の対応する位置の間で参照がなされる。一般的には、この参照は、データの２つの部分の形を取る。つまり、条件付きアクセスデータ（ＥＣＭ）に対応するＣＭＭの識別子とビットストリーム中の対応するファイル書き込みポインタ（ＦＷＰ）である。好ましい実施形態では、このような参照は、記憶されたビットストリームも含むファイルの前述された管理データ部分２１１２内のテーブルに記憶され、その結果それはプレイバック中に容易にアクセスできる。
【０５７０】
同期は、それが到達するときの各ＥＣＭの位置を評価し、このような位置を記憶し、制御ワードがデスクランブラに送達されなければならないタイミングのための基礎として、プレイバック中に記憶された位置を再ロードすることにより引き起こすことができる。ビットストリーム中の正確に最も近いビットまたはバイトまでのこのような位置の評価は、ときおり非効率的であることがある。
【０５７１】
記憶されたビットストリーム中でのＥＣＭの位置の正確な判定に関するいくつかの問題点は、ここで、ビットストリームがデマルチプレクサからリマルチプレクサの中に、それからＦＩＦＯを介してハードディスク内の記憶装置の中に送り込まれる現在のシステムの文脈で考えられるだろう。
【０５７２】
ＥＣＭなどのデータは、同期プロセスの制御がさらに容易に管理される上位ソフトウェア層の半自動的に動作しているＭＬＯＡＤデバイスによってデマルチプレクサの出力から抽出される。中断待ち時間及び他の類似した考慮事項のため、ＥＣＭのＭＬＯＡＤデバイスからの受信は、正確に計時できない。さらに、ＥＣＭの受信は、通常、（ＥＣＭが「新規」なのか、あるいは再送にすぎないのかに関するチェックを含む）一定のチェックが行われた後に条件付きアクセススマートカードによって生成されるＥＶＴ＿ＣＡＳ＿ＥＣＭイベント８４００（図示されていない）によって肯定応答されるにすぎない。このイベントは、ここでは△ｔと呼ばれるタイムオフセットによりＥＣＭ自体の実際の受信に立ち遅れ、△ｔに対応するデータ量は、ビットストリームの優勢なビットレートに応じて変化するだろう。△ｔの主題には後に戻るだろう。
【０５７３】
考慮しなければならない１つの問題点は、ＦＩＦＯバッファが動的に調整可能なサイズを有し、予測不可能な要因に応じて空といっぱいの間で変化する可能性があるという点である。追加の問題点――後に戻る――は、受信機／デコーダの要約されたアーキテクチャに従って、データは、ファイル書き込みポインタ（ＦＷＰ）が（おそらく、一度に２メガバイトのデータの）各セグメントの書き込みの前後にだけ決定可能であるように、分割できないセグメントでハードディスクに記憶されるという点である。つまり、「カレント」ＦＷＰは、任意のときに（例えばＥＶＴ＿ＣＡＳ＿ＥＣＭが達するときに）読み取ることはできない。
【０５７４】
最終結果は、ＥＣＭ位置の正確な決定が、ビットストリームの、それが到達するとき、及び／または（相対的に非効率的であることがある）システム内での多様なバッファ及びファイルポインタの状態に関する詳細な知識としての追加の分析を必要とすることがあるという点である。
【０５７５】
ビットストリーム中の位置の概算
前記に簡略に説明されたように、各ＥＣＭは、ある特定の１０秒の暗号期間に関係し、次の暗号期間の制御ワードも含み、ＥＣＭの位置を評価するための別の解決策に対するなんらかの見通し、すなわち位置の（決定よりむしろ）概算を提供する。
【０５７６】
位置を概算する多様な手段が見つけられ、これらの内のいくつかが後述されるだろう。より効率的な手段の１つは、ビットストリームを、最悪のケースの推定値――相対的に迅速に計算される――が、つねに「安全」な答えを生み出すように操作することを含み、つねにより複雑な概算方法に優先して使用することができる。「安全」なによって、タイミングを制御するための前記の推定された位置を使用する記憶されたビットストリームの再構築の間に、制御ワードが、それぞれ、適切な２つの暗号期間時間ウィンドウの間にデスクランブラに送達され、このようにして逆スクランブル動作が正しく動作することが示唆される。対照的に、制御ワードが誤った暗号期間中に送達されると、デスクランブラは記憶されたビットストリームを逆スクランブルすることができず、ユーザにとってのピクチャ及び／または音の損失が生じるだろう。
【０５７７】
ビットストリーム中の条件付きアクセスデータ（またはさらに言えば、特定の字幕、音声、ビデオ、アプリケーションまたは他のデータなどの他の適切なデータ）の位置を推定するためのこの前述された手段が、ここで図２７に関して説明されるだろう。
【０５７８】
図２７では、セグメントＳ２１、Ｓ２２、Ｓ２３等が、ビットストリーム（データオフセットスケールを有すると図示される――タイムスケールが使用されると、変化するビットストリームのために、後述されるように、セグメントサイズは歪められ、一様でなくなるだろう）に関して示される。やはり図示されているのは、同等なファイル書き込みポインタ（ＦＷＰ）値、及び優勢な暗号期間ＣＰ１２、ＣＰ１３、ＣＰ１４である。ビットストリーム中のＥＣＭ５６０２の実際の位置は、時間△ｔ後に発生するＥＶＴ＿ＣＡＳ＿ＥＣＭイベント８４００でのように、図示される。セグメントの境界は、ＥＣＭ５６０２及びＥＶＴ＿ＣＡＳ＿ＥＣＭイベント８４００のどちらかの側に破線として図示される。最後に、対応する推定される位置（ＦＷＰｅｓｔ）は、ＥＣＭ５６０２を含むセグメントの最後の右側に図示される。
【０５７９】
特定のセグメントの最後（したがって、次のセグメントの始まり）は、カレントセグメント書き込み動作が完了した旨を示すために大容量記憶装置によって生成されるＥＶＴ＿ＦＩＦＯ＿ＷＲＩＴＥ＿ＣＯＭＰＬＥＴＥＤイベントの受信によってほぼ瞬時に（ｎｅａｒ−ｉｎｓｔａｎｔａｎｅｏｕｓｌｙ）（一定の実施形態ではおもに概算を担当する）ＣＭＰＳシステムに信号で知らされる。この点で、カレントＦＷＰは、ちょうど使用されたセグメントサイズが加えられた過去のＦＷＰに等しいと想定できる。
【０５８０】
好ましい実施形態においては、ＣＭＰＳよりむしろＨＶＤＲが、ＥＶＴ＿ＣＡＳ＿ＥＣＭイベントがＣＭＰＳによって受信された直後に送信される、ＥＶＴ＿ＣＡＳ＿ＥＣＭイベントから引き出されるＥＶＴ＿ＣＡＳ＿ＣＭＭイベントを使用して位置を推定する。したがって、推定値は直接的にＥＶＴ＿ＣＡＳ＿ＥＣＭイベントに基づいていない。事実上、多くの実際の状況では、ＥＶＴ＿ＣＡＳ＿ＥＣＭイベントと対応するＥＶＴ＿ＣＡＳ＿ＣＭＭイベントの間の時間遅延は相対的に小さく、無視することができる。
【０５８１】
概算は、（ＥＣＭ５６０２の受信はそれ自体大局的に通知されないため、特に大部分の受信されたＥＣＭは、それからその後条件付きアクセスシステムにより廃棄される再送にすぎないため）ＥＣＴ＿ＣＡＳ＿ＥＣＭイベント８４００が落下するセグメントを決定してから、以下の公式に従って位置の推定値を採取することを備える。
【０５８２】
【数１】
0004257084.tif 000002
ここではＥ（  ）は予想演算子であり、ｓｉｚｅ＿ｓｅｇｍｅｎｔ（ｎ）は各セグメントのサイズであり（この図では、例えば、ｓｉｚｅ＿ｓｅｇｍｅｎｔ（２２）＝２メガバイトであり、すべての過去のセグメントサイズの合計は３０メガバイトである）、ｓｉｚｅ＿ｆｉｆｏは、（注記されたように変化することがある）ＦＩＦＯ内のデータの量であり、推定値が過大評価である（以下を参照）ことを確実にするために、システム内での追加の待ち時間及びタイミング問題について調整する（典型的には０と１メガバイトの間である）ｋは「機密保護パラメータ」である。
【０５８３】
前記式の中の予想項Ｅ（  ）は、少なくとも、ｓｉｚｅ＿ｆｉｆｏパラメータを正確に求めることができないという事実に取り組んでいる。一般的には、指定された最大割り当てＦＩＦＯサイズｆｓ（例えば）について、Ｅ（ｓｉｚｅ＿ｆｉｆｏ）は、（前記例では、０．２Ｍｂという最大ＦＩＦＯサイズを暗示する）１／２ｆｓと解釈される。さらに詳しく後述されるように、ｓｉｚｅ＿ｓｅｇｍｅｎｔの選択は、結果として生じる推定値を「安全」であるが効率的に保つために微調整できる。
【０５８４】
図２７に示される例では、Ｅ（ｓｉｚｅ＿ｆｉｆｏ）は０．５Ｍｂとして解釈され、ｋは０に等しく、Σｓｉｚｅ＿ｓｅｇｍｅｎｔ項は３２Ｍｂに等しく、前記公式が適用されると、３２．ｂＭｂというＦＷＰｅｓｔをもたらす。
【０５８５】
前記公式の基礎となるのは、ＥＣＭの二重制御ワード冗長性のために、ＥＣＭの推定位置が、それが関連付けられる暗号期間の直後の暗号期間に含まれるかどうかは関係ないという理解である。しかしながら、推定位置がそれを超える暗号期間、あるいは正しい暗号期間の直前の暗号期間に含まれる場合には、概算は失敗するだろう。
【０５８６】
図２７では、例えば、セグメントＳ２２の書き込みの間、暗号期間ＣＰ１２に関して送信されるＥＣＭによって引き起こされるＥＶＴ＿ＣＡＳ＿ＥＣＭイベント８４００と暗号期間ＣＰ１３に関して送信されるＥＣＭによって引き起こされるＥＶＴ＿ＣＡＳ＿ＥＣＭイベント８４００を区別することは不可能である。ＣＰ１２  ＥＣＭをＣＰ１３  ＥＣＭとして不正確に名付けることは重大ではなく、ＣＰ１３  ＥＣＭをＣＰ１２  ＥＣＭと不正確に名付けることは致命的であるため、過大評価の必要性を認識することができる。
【０５８７】
セグメントサイズが大きくなると、同じセグメント書き込み動作中に２つのＥＶＴ＿ＣＡＳ＿ＥＣＭイベント８４００、及び２セットの制御ワードを受信する可能性が存在するため、最大セグメントサイズが、（ＦＩＦＯサイズパラメータのサイズより小さい）暗号期間としてのサイズを超えることができないことも理解されなければならない。前述された多様なシステム制約（及び、デバイス間通信の非同期性質を含むその他）のために、対応するＥＣＭが受信された順序について曖昧さがあり、誤った制御ワードが誤った暗号期間に適用されることにつながるため、これも致命的である。
【０５８８】
前記を念頭に、極端なケースでの概算ルーチンの堅牢性が、図２８と図２９に関してここにさらに説明されるだろう。
【０５８９】
図２８では、入信するＥＣＭ５６０２、結果として生じるＥＶＴ＿ＣＡＳ＿ＥＣＭ８４００及びＥＣＭの推定位置（ＦＷＰｅｓｔ）が図示される。これは、ＥＶＴ＿ＣＡＳ＿ＥＣＭイベント８４００が、セグメントＳ２２の最後で、ＥＶＴ＿ＦＩＦＯ＿ＷＲＩＴＥ＿ＣＯＭＰＬＥＴＥＤイベントの直前に受信される１つの極端なケースを表す。結果として生じる推定値（事実上、３２．５Ｍｂ）は、ここでは、（△ｔに同等なデータサイズが加えられる０．５Ｍｂという距離にある）ＥＣＭ５６０２に最接近し、このケースでは正しい暗号期間（ＣＰ１３）に含まれる。
【０５９０】
図２９では、ＥＣＭ５６０２及び結果として生じるＥＶＴ＿ＣＡＳ＿ＥＣＭ８４００は、ビットストリーム中でさらに前方に少し図示され、ＥＶＴ＿ＣＡＳ＿ＥＣＭ８４００は、次のセグメントＳ２３内で発生する。結果として生じる推定値（事実上、３４．５Ｍｂ）は、ここでは、（△ｔに同等なデータサイズが加えられる２．５Ｍｂという距離にある）ＥＣＭ５６０２から最も遠く、正しい暗号期間（ＣＰ１３）の後の暗号期間（ＣＰ１４）に含まれる。
【０５９１】
他の例は、暗号期間とセグメントの異なる相対的な位置で構築することができるが、前記公式を用いて（及び結合されたセグメントと、暗号期間のサイズを超えないＦＩＦＯサイズを用いて）推定位置が、つねに正しい暗号期間、あるいは続く暗号期間に含まれる（両方のケースで、結果は許容できる）ことが認められる。
【０５９２】
前述されたように、好ましい実施形態においては、概算プロセスは、ＥＶＴ＿ＣＡＳ＿ＥＣＭイベントから引き出されるＥＶＴ＿ＣＡＳ＿ＣＭＭイベントに基づいている。事実上、多くの実際的な状況では、ＥＶＴ＿ＣＡＳ＿ＥＣＭイベントと対応するＥＶＴ＿ＣＡＳ＿ＣＭＭイベントの間の時間遅延は相対的に小さく、無視することができる。
【０５９３】
同期及び概算の下にある構造
（特に図１２と図１３に関して）前述された同期及び概算の方法の基礎となる多様な構造は、図３０と図３１に関してさらに詳細に説明されるだろう。
【０５９４】
図３０では、スクランブルされたビットストリーム８００が、デマルチプレクサ／リマルチプレクサ／デスクランブラ２０１０を通過すると図示され（ここでは、そのリマルチプレクサされている容量にあると図示され）、（ＦＩＦＯデバイス３７４４―図示されていない―によって動作される）ＦＩＦＯ８０２０が（大容量記憶装置３７２８によって動作される）ハードディスク２１００内のファイル部分２１１０内に記憶される途中である。ＭＬＯＡＤデバイス３４３８は、ＥＣＭ５６０２、及びＵＲＭ５６１２とＣＭＰＳ＿ＥＭＭ５６１４を抽出し、これらをそれぞれ条件付きアクセスシステム５０００とＣＭＰＳ２３００に転送する。条件付きアクセスシステム５０００内の条件付きアクセス暗号解読エンジン８５００によって平文に直される制御ワード５６００は、ＥＶＴ＿ＣＡＳ＿ＥＣＭイベント８４００の一斉送信に伴なわれ、ＣＭＰＳ２３００に送信される。前述されたように、制御ワード（冗長性のためにＣＭＭあたり２つ）、ＵＲＭ５６１２とＣＭＰＳ＿ＥＭＭ５６１４は、ＣＭＰＳ暗号解読エンジン８５５０によって結合され、暗号化されてから、関連するファイルの管理データ部分２１１２での記憶のために、ＨＤＶＲ３８５０及び大容量記憶装置３７２８を介してハードディスク２１００に送信される。ＥＶＴ＿ＦＩＦＯ＿ＷＲＴＥ＿ＣＯＭＰＬＥＴＥＤイベント８４１０は、セグメント書き込み動作が完了すると定期的に一斉送信され（好ましい実施形態においてはＨＤＶＲ３８５０によって、あるいは代わりに直接的にＣＭＰＳ２３００によって受信され）る。ＥＶＴ＿ＣＡＳ＿ＣＭＭイベント８５５２は、ＣＭＰＳ２３００からＨＤＶＲ３８５０に送信される。前述されたように、ＥＶＴ＿ＣＡＳ＿ＣＭＭイベント８５５２は、好ましい実施形態における概算の基礎として使用される。
【０５９５】
図３１では、デマルチプレクサ／ｒｅｍｕｌｔｉｐｌｅｘｅｒ／デスクランブラ２０１０が、ＣＭＰＳ２３００内のＣＭＰＳ暗号解読エンジン８５６０によって生成される制御ワード５６００で、部分２１１０からスクランブルされたビットストリーム８００を逆スクランブルすることによって所望される解読されたビットストリーム８１０を生成する。前述された暗号解読エンジン８５６０は、大容量記憶装置３７２８を介してハードディスク２１００内の関連するファイルの管理データ部分２１１２から検索されるＣＭＭによって送られ、ＣＭＰＳ２３００による追加の処理のために、ＵＲＭ５６１２とＣＭＰＳ＿ＥＭＭ５６１４も生成する。
【０５９６】
セグメントサイズ
他の検討材料に戻ると、暗号期間がタイムドメイン内だけで所定のサイズを有し、その対応するデータサイズはビットストリームのビットレートに伴ない変化することが注記される。追加の検討材料は、毎秒生成されるＥＶＴ＿ＦＩＦＯ＿ＷＲＩＴＥ＿ＣＯＭＰＬＥＴＥＤイベントが多いほど、多くの処理能力が不必要に使い果たされるため、特に、暗号期間の予想サイズを基準にして「安全」な（言い換えると、小さな）セグメントサイズが非効率的であるという点である。
【０５９７】
最適セグメントサイズが、ここでさらに詳細に考えられる。
【０５９８】
セグメント内の少量のデータは、暗号期間あたり多くのセグメントを作成できるようにする。これは、さらに正確な測定値を可能とする可能性があるが、暗号期間あたり多すぎるイベントを有するリスクを生じさせ、計算効率の悪化につながることがある。
【０５９９】
セグメント内の中くらいの量のデータは、大きなセグメントと小さなセグメントの妥協案を提供する。これは、考えられるセグメントサイズの範囲を含み、最適なサイズはこの範囲から選ばれなければならない。
【０６００】
セグメント内の大量のデータは、暗号期間あたり少なすぎる、多すぎるセグメントを作成する。これは、より少ないセグメントエンドイベントのためより必要とされる処理がより少なくなるという優位点を有するが、大きすぎるセグメントは、セグメントの書き込み中に、（潜在的に致命的に）複数のＥＶＴ＿ＣＡＳ＿ＥＣＭイベントを受信させることになる。
【０６０１】
要約すると、最小セグメントは最も正確な推定値を生じさせるが、小さなセグメントを使用するにはさらに多くの処理が必要となるため、低速である。ビットストリームは、推定値を可能な限り正確に保ちながら、処理を最小に保つために可能な限り大きいセグメントに分割される。この目的のため、一般的には、多様な中型のセグメントが、速度と精度の有効な妥協案として好まれる。
【０６０２】
セグメントサイズの前記検討材料を考えると、システムの追加の重要な態様は、ＥＣＭ位置の「安全」な推定値を保持しつつ、効率を最大限にする（または、言い換えるとセグメントサイズを最大限にする）ための適切なセグメントサイズの決定に関係する。
【０６０３】
適切なセグメントサイズの決定は、ビットレートなどのビットストリームの認められる特定にフィルタを適用することによって行われる。このフィルタリングは、概算の場合のように、ＣＭＰＳ２３００によって実行される。大部分のケースでのフィルタリングは、ビットレートの大きな変動に対する概算手順の感受性を削減するのに役立つ。
【０６０４】
ビットストリームの位置をハードディスクに記憶するために使用されるセグメントサイズを最適化するためのフィルタ及びその他の手段の使用は、ここでさらに詳しく説明されるだろう。
【０６０５】
セグメントサイズの最適化
一般的にはセグメントサイズの決定を補助するためにビットストリームの少なくとも１つの特性を活用してセグメントサイズを最適化するためには、多数の方法が使用できる。
【０６０６】
好ましい実施形態においては、入力がビットストリームの平均ビットレートの測定値であり、出力がセグメントサイズである動的フィルタが使用される。しかしながら、一般的には、ここでは２つのおもな種類のフィルタが考えられる。つまり静的フィルタと動的フィルタである。それらの相対的な長所の説明だけではなく、これらのフィルタの実現もここで説明されるだろう。
【０６０７】
まず最初に、静的フィルタが説明されるだろう。
【０６０８】
静的フィルタの重要な特性は、セグメントのサイズが可能な限り一定に近いという点である。動的フィルタのケースでのように、最適セグメントサイズを決定するために、ビットストリームの処理が必要とされないため、静的フィルタは動的フィルタより容易に利用されるが、それらはビットレートの大きな変動によりうまく対処しない。しかしながら、静的フィルタは、暗号期間あたり多すぎるイベントを生成する傾向があり、ビットストリームの操作を悪化させ、理論上の制度を即座に減少させる。
【０６０９】
この一定のセグメントサイズの選択に影響を及ぼす制約は、以下を含む。
【０６１０】
セグメントのサイズは、（バッファに入れられるデータも考慮に入れ）長さで暗号期間を超えてはならない。
【０６１１】
Ｓｉｚｅ＿Ｓｅｇｍｅｎｔ（Ｍｂ）＜ビットレート（Ｍｂ／秒）  ｘ  暗号期間（秒）  −  ＦＩＦＯＳｉｚｅ（Ｍｂ）
転送（セグメントサイズ）の最大サイズは、制限される。
【０６１２】
Ｓｉｚｅ＿Ｓｅｇｍｅｎｔ（Ｍｂ）＜３２（Ｍｂ）
前記パラメータに関する以下の仮定は、不当ではない。
【０６１３】
１暗号期間は少なくとも６秒である。
【０６１４】
ビットレートは、少なくとも毎秒１Ｍｂである。
【０６１５】
ＦＩＦＯＳｉｚｅは、３２Ｍｂ未満または３２Ｍｂに等しい（典型的には２Ｍｂ）。
【０６１６】
これらの前記仮定は、以下の結果を出す。
【０６１７】
Ｓｉｚｅ＿Ｓｅｇｍｅｎｔ（Ｍｂ）＜６（Ｍｂ）−  ＦＩＦＯＳｉｚｅ（Ｍｂ）
（結果的にＦＩＦＯＳｉｚｅ＜＜６である。）
したがって、２Ｍｂという典型的なＦＩＦＯＳｉｚｅの場合、セグメントサイズは４Ｍｂである。
【０６１８】
動的フィルタがここで説明されるだろう。
【０６１９】
動的フィルタは、ビットレートに対処するためにセグメントのサイズを調整する。高いビットレートは短い持続時間のセグメントを有し、逆の場合も同じである。しかしながら、動的フィルタは、少ない大きなセグメントと多くの小さなセグメントの間で妥協しなければならない。ビットレートが低い、あるいは一定である場合、セグメントが大きくなり、ビットストリームの記録と同期に必要な解像度を依然として与えるが、暗号期間あたりに生成するイベントは少なくなる可能性がある。ビットレートが高いまたは大幅に変化する場合、最も正確な測定値を与えるためには最小のセグメントが必要とされるが暗号期間あたり多くのイベントを生成し、このようにしてビットストリーム操作を劣化させる。動的フィルタの目的とは、ビットストリームに考えられる最大セグメントを作成することである。
【０６２０】
動的フィルタは、セグメントサイズを、（以下で「セグメント書き込み時間」と呼ばれる）暗号期間の分数として表される時間の同等物に制限しようとする。セグメント書き込み時間を定める係数は、「機密保護係数」と呼ばれる整数であり、その結果、
【０６２１】
【数２】
0004257084.tif 000003
である。
【０６２２】
高速フィルタ、慣性フィルタ、及びハイブリッドフィルタという３種類の異なった動的フィルタがある。好ましい実施形態においては、ハイブリッド動的フィルタが使用されるが、好ましい実施形態の変形においては、他の種類の静的フィルタ及び動的フィルタが使用される。
【０６２３】
高速道的フィルタは、次のセグメントのサイズを決定するために、前のセグメントの書き込み時間を考慮に入れる。最初に、高速フィルタは、前のセグメントを書き込むのに要した時間を計算してから（ｔｉｍｅ＿ｓｅｇｍｅｎｔ（ｎ−１）−ｔｉｍｅ＿ｓｅｇｍｅｎｔ（ｎ−２））、（要した時間で除算されたセグメントのサイズに等しい）対応する平均ビットレートを計算する。セグメントのサイズ（ｎ）、つまりｓｉｚｅ＿ｓｅｇｍｅｎｔ（ｎ）は、公式により出される。
【０６２４】
【数３】
0004257084.tif 000004
Ｔｉｍｅ＿ｓｅｇｍｅｎｔ（ｎ）は、（セグメントの持続時間よりむしろ）そのセグメント（ｎ）のイベントの受信絶対時刻である。
【０６２５】
釣り合って（すなわち、一定のビットレートを用いると）、フィルタは実際のビットレートに関係なく、暗号期間あたりの書き込みの回数をｓｅｃｕｒｉｔｙ＿ｃｏｅｆｆｉｃｉｅｎｔに与える。低ビットレートのケースでは、セグメントのサイズの制限値は、静的なフィルタのケースの制限値と同じである。つまり、ｓｉｚｅ＿ｓｅｇｍｅｎｔ＝４Ｍｂである。
【０６２６】
前記公式を使用し、一定のビットレートで高速動的フィルタを使用する例証として、暗号
期間の値が１０秒で固定され、４という機密保護係数が選ばれると、セグメントイベントは２．５秒おきに発生する。一定のビットレートのケースでは、システムは、前記に定められた制限に向かって収束する。
【０６２７】
動的フィルタに対する重要な制約は、以下のとおりである。
【０６２８】
ｔｉｍｅ＿ｓｅｇｍｅｎｔ（ｎ）−ｔｉｍｅ＿ｓｅｇｍｅｎｔ（ｎ−１）＜１暗号期間
セグメント境界で、平均的なビットストリーム（１暗号期間／ｓｅｃｕｒｉｔｙ＿ｃｏｅｆｆｉｃｉｅｎｔで平均される）が、前述された機密保護係数関係性を超えないことが推論できる。フィルタの安定性は、以下であるならばこのケースで保証される。
【０６２９】
【数４】
0004257084.tif 000005
この例から、ビットレート動的が、以下の関係性により機密保護係数にリンクされることが分かる。
【０６３０】
【数５】
0004257084.tif 000006
ビットストリーム変動中にフィルタの「堅牢性」パラメータを定める機密保護係数値は、試験条件下での本物のＭＰＥＧ−２フロー検査により求められる。これは、機密保護パラメータ及び制限が確立されるように、フィルタの制御値を得るためである。
【０６３１】
第２の種類の動的フィルタは、慣性マルチレベルフィルタである。
【０６３２】
このフィルタの原理は、それが可変ビット・レートビットストリームのビットレートを、過去のセグメントのビットレートを使用して推定するという点で、高速道的フィルタの原理と同じである。しかしながら、概算プロセスはさらに大きなメモリを与えられる（すなわち、実質的には、それはさらに多くのフィルタ係数を有する）。ここでは、平均ビットレートは、セグメント書き込み動作の過去のｓｅｃｕｒｉｔｙ＿ｃｏｅｆｆｉｃｉｅｎｔ数の平均ビットレートの全体的な平均と解釈される。このフィルタの概算は、第１レベルフィルタの慣性より高い慣性を有し、それはビットストリームのピークに対してはより敏感でない可能性があるが、それがさらに安定することを可能にする。慣性フィルタは、それがセグメント（ｎ）のサイズを得るために、セグメント（ｎ−ｓｅｃｕｒｉｔｙ＿ｃｏｅｆｆｉｃｉｅｎｔ）からセグメント（ｎ−１）までの書き込み時間値を使用するという点で、高速フィルタに類似している。
【０６３３】
フィルタの公式は、以下のとおりである（幾何学的形）。
【０６３４】
【数６】
0004257084.tif 000007
（算術的形）
【０６３５】
【数７】
0004257084.tif 000008
動的フィルタの一定のビットレートの制限値は、静的フィルタの制限値と同一であり、動的制限を含む値は、高速フィルタの値に対する性能という点で同等であり、唯一の相違点は、高速フィルタの場合の暗号期間／ｓｅｃｕｒｉｔｙ＿ｃｏｅｆｆｉｃｉｅｎｔというメモリよりむしろ１暗号期間のメモリを有する（ｓｅｃｕｒｉｔｙ＿ｃｏｅｆｆｉｃｉｅｎｔレベルの）慣性フィルタの応答時間である。
【０６３６】
慣性フィルタのこの慣性は、特に、非常に高いピークの削減（およびしたがってそれらのピークに対する感受性の現象の可能性）、すなわち、ｓｅｃｕｒｉｔｙ＿ｃｏｅｆｆｉｃｉｅｎｔが可能にするより高い動的のピークを可能にする。静的フィルタは、メモリフィルタの慣性はこの人為的な影響とともに他の値を排除してよいが、ピークが抹消される場合に最適値を達成する。
【０６３７】
第３の種類の動的フィルタは、ハイブリッドヒステリシスフィルタである。
【０６３８】
前述された２つの動的フィルタ（高速動的フィルタと慣性マルチレベル動的フィルタ）は、さらに優れた性能を示すフィルタを示すために結合される。結果として生じるハイブリッドフィルタは、２つのフィルタの最善の特性を結合する。高速フィルタは突然のビットレート低下のケースで必要な優れた応答時間を有するが、それがセグメント内で局所化されたピークを特定すると、それは平均化プロセスで含まれる大きな値のために、次のセグメントのサイズを過大評価することがある。他方、慣性フィルタは、ビットレートピークを減衰できるが、その反応時間は、連続する低下があるときに有効性を制限する。
【０６３９】
ハイブリッドフィルタは、高速フィルタと慣性フィルタを結合し、あらゆる局所化されたピークを減衰するために、上昇するビットストリーム前方で慣性フィルタの柔軟性を、及び低ビットレートビットストリームに向かう高ビットレートビットストリームの遷移を補償するために、減少するビットストリーム前方での高速フィルタの反応性を保つことによって、ヒステリシス影響（つまり、ビットレートの上昇する前方と減少する前方の差異）に対処する。
【０６４０】
フィルタの動作は、ここに説明されるだろう典型的なビットストリームのシミュレーションを使用して調査された。
【０６４１】
ビットレートシミュレーション
さまざまなビットレートパターンが、前述された４つのフィルタ、つまり静的フィルタ、高速動的フィルタ、慣性動的フィルタ、及びハイブリッド動的フィルタを使用して、図３２から図３９で調査される。
【０６４２】
シミュレーションの目的は、それらの安定した動作ゾーンの中から（つまり、一定したビットレートではない）フィルタの動作を観察することである。これを達成するために、正弦波的に変化するビットレート（図３２は、静的フィルタの結果を示し、図３３は高速フィルタ用であり、図３４は慣性フィルタ用であり、図３５はハイブリッドフィルタ用である）、階段関数ビットレート（図３６はハイブリッドフィルタ専用である）、三角関数ビットレート（図３７はハイブリッドフィルタ専用である）、頂冠関数ビットレート（図３８はハイブリッドフィルタ専用である）及び単一ピークビットレート（図３９はハイブリッドフィルタ専用である）を含むさまざまな入力ビット速度関数が調査される。
【０６４３】
図のそれぞれのセットでは、「ａ」と示される図が経時的なビットストリームを示し、「ｂ」と示される図がいくつかのセグメントでの結果として生じる書き込み時間を示す。
【０６４４】
図３２から図３９の各セットで「ａ」と示される図は、セグメント間の遷移を示す垂直線を有する。例えば、図３２ａ（静的フィルタケース）から分かるように、一定のセグメントサイズは高ビットレートで―約３秒、約１６秒、約２８秒、及び約４１秒でのセグメント遷移の同時縦揺れに反映される―短い時間、及び低ビットレートで―約９秒、約２２秒、約３５秒及び約４７秒での大きな（時間）セグメント幅によって反映される―相対的に長い時間を要する。前述されたように、目的は、（計算効率を犠牲にして不必要な精度の度合いを生じさせる）セグメントのこのような縦揺れを回避する―言い換えると、高ビットレートでより大きなセグメントを目指すことである。
【０６４５】
図の各セットで「ｂ」と示される図は、それぞれ、暗号記号持続時間（このケースでは６秒）に同等である「クラッシュ線」８６００を示す。前記に注記されたように、この持続時間を超える書き込み時間は、（複数のＥＣＭがセグメントの書き込み中に到達することがあるため）概算を失敗させることがある。動的フィルタ（図３３から図３９の場合）、動的フィルタが収束する書き込み時間を示す秒水平線がある。
【０６４６】
前述されたように、図３２から図３５は、５０秒続く正弦波的に変化するビットレートシミュレーションに関係する。このケースでは、各暗号期間は６秒続き、４という機密保護係数が選ばれる。
【０６４７】
静的フィルタ、高速フィルタ及び動的フィルタは、それぞれ１００セグメント、３３セグメント及び２８セグメントを作成する（一般的には、セグメントが少ないほど、フィルタはよくなる）。セグメント書き込み時間は、すべて、クラッシュ線の下にあると観察され（すなわち、長さで暗号期間未満である）、フィルタの動作に観察された不安定性はない。
【０６４８】
このテストでは、ハイブリッドフィルタは３つの動的フィルタの最良の補正を提供するため、他のビットレートシミュレーションの結果はこのフィルタだけに集中する。不安定性に対する傾向は、図３５ｂに図示されるように上昇する前方で減衰する８７００、及び減少する前方で増加した反応性８７５０によって描かれている、増加と減少の間のヒステリシス現象によって補正される。
【０６４９】
前述されたように、図３６は、５０秒続く階段関数ビットレートシミュレーションに関する。このケースでは、各暗号期間は６秒続き、４という機密係数が選ばれる。ビットストリームのビットレートは２５秒間、毎秒１Ｍｂであり、それから次の２５秒間毎秒８Ｍｂとなり、２つの異なる一定のビットレートの間で階段を作成する。このシミュレーションの目的は、典型的な最小ビットレートの周辺でのフィルタの動作を調査することである。
【０６５０】
動的フィルタ（高速、慣性及びハイブリッド）は、最小フローで静的フィルタと同じ特性を有する。しかしながら、それらは暗号期間／ｓｅｃｕｒｉｔｙ＿ｃｏｅｆｆｉｃｉｅｎｔの限界に向かって収束する。毎秒８Ｍｂという最大ビットレート限度が決定される。
【０６５１】
前述されたように、図３７は、５０秒続く三角ビットレートシミュレーションに関係する。このケースでは、各暗号期間は６秒続き、４という機密保護係数が選ばれる。このシミュレーションの目的は、上昇してから減少するビットレートに直面するときのフィルタのそれぞれの動作を観察することである。
【０６５２】
ハイブリッドフィルタは、三角ビットレート関数の上昇部分８８５０での慣性フィルタの上昇した反応時間を、三角ビットレートの減少部分８９００の間の高速フィルタの強い反応性と結合する。
【０６５３】
前述されたように、図３８は、５０秒続く頂冠関数ビットレートシミュレーションに関係する。このケースでは、各暗号期間は６秒続き、４という機密保護係数が選ばれる。ビットレートは、毎秒２Ｍｂという基底上の毎秒８Ｍｂという「頂冠」から成り立っている。最大限度が、ハイブリッドフィルタを、毎秒８Ｍｂでの伝送速度平坦部で確定されたビットレートとなることができるようにする。
【０６５４】
前述されたように、図３９は、雑音の要素も組み込む５０秒続く単一ピークビットレートシミュレーションに関する。このケースでは、前述されたように、各暗号速度は６秒続き、４という機密保護係数が選ばれる。ビットレートは、弱い平均雑音値、毎秒約２Ｍｂを有し、それは、毎秒１８Ｍｂで２秒間、非常に局所化されたビットレートのピークを示す。目的は、ビットレートを推定するときに変則的なビットレートを補償するために、その補正容量を上回る強いビットレートピークを減衰するためのハイブリッドフィルタの容量を示すことである。
【０６５５】
ハイブリッドフィルタは、その量のデータに必要とされるセグメントの数を過小評価することによって大きなデータを補償し、このようにしてビットレート概算手順におけるデータピークの影響を減衰する。
【０６５６】
概算の追加の方法
前述されたように、記憶されたビットストリーム中のＥＣＭの位置を推定する追加の方法が認識される。例えば、平均ビットレート、またはビットストリーム中の点の間に経過した時間などの（例えば、前述されたようなある特定のセグメントの最後からのオフセットとして推定値を形成するのとは対照的に）ビットストリームの特性に依存する推定値を形成する、方法の１つのセットが実現できる。
【０６５７】
１つのこのような方法が、ここで説明されるだろう。
【０６５８】
以下の方法は、さらに、前記とは対照的に、ＥＶＴ＿ＣＡＳ＿ＥＣＭが受信されるときに（ただし、ＥＣＭ自体が受信されるときではなく）ファイル書き込みポインタ（ＦＷＰ）を確立できると仮定する。
【０６５９】
したがってビットストリーム中のＥＣＭの位置は、４つのステップで推定できる。
【０６６０】
１．ビットストリーム中でのＥＣＭの受信と、対応する制御ワード（「△ｔ」）の到着を信号で知らせるイベントの間のタイムオフセットに関して、概算が行われる。
【０６６１】
２．この時間期間中の平均ビットレートが推定される。
【０６６２】
３．この時間期間に対応するデータの量「△ｄ」は、△ｔとビットレートの積として計算される。
【０６６３】
４．次に、ビットレートの中でのＥＣＭの位置（「ｄ」）が、前記で発見されたデータオフセット（「△ｄ」）を差し引いた現在位置（ＦＷＰ）として計算される。
【０６６４】
これらのステップは、（△ｔを推定する）第１ステップで開始し、さらに詳しく後述されるだろう。
【０６６５】
一般的には、制御ワードを平文に直すためにかかる時間はほぼ一定（およそ数秒）であるため、△ｔの値は、本来推定されるよりむしろ仮定される。しかしながら、可能な場合、少なくとも１つの過去の推定値の誤差が測定され、将来の推定値を補正するために使用できる。言うまでもなく△ｔを推定するために、他の手段が提供されてよい。
【０６６６】
（平均ビットレートを推定する）第２ステップが、ここでさらに詳しく説明されるだろう。
【０６６７】
簡単にするために、平均ビットレートは、連続するＥＶＴ＿ＣＡＳ＿ＥＣＭイベント（持続時間のほぼ１暗号期間）の間の期間全体に関して、または好ましくは、セグメントの長さなどのさらに短い期間に関して計算されてよい。それぞれのケースでは、ビットレートは、総時間で除算される総データオフセットとして計算される。
【０６６８】
（データオフセットを計算する）第３ステップが、ここでさらに詳しく説明されるだろう。
【０６６９】
ビットレートと△ｔ推定値の積が△ｄ、ＥＣＭの受信以来経過したデータの推定量を示す。
【０６７０】
△ｄ（Ｍｂ）＝ビットレート（毎秒Ｍｂ）ｘ  △ｔ（秒）
（ＥＣＭの位置を推定する）第４ステップが、ここでさらに詳しく説明されるだろう。
【０６７１】
ＥＣＭの受信から推定データオフセットを知っている場合、ＥＣＭの位置ｄは、カレントファイル書き込み位置（ＦＷＰ）から△ｄを差し引くことによって推定できる。
【０６７２】
ｄ＝ＦＷＰ−△ｄ
言うまでもなく、前述されたように、ビットストリーム中でのＥＣＭの位置を推定する他の方法を実現することができ、言うまでもなく前述された推定する方法は、特に任意の特定のときに入手できる、異なる情報を考慮に入れるために、マイナーな変動を受けてよい。
【０６７３】
前述された多様な関数の実現及びハードウェアとソフトウェア間でのそれらの分散に関する正確な詳細は実施者の選択の問題であり、詳しく説明されないだろう。しかしながら、受信機／デコーダで必要とされる動作を実行できる専用集積回路が市販されている、あるいは容易に設計でき、これらがハードウェア加速装置のための基礎として使用できる、あるいはより好ましくは、必要とされる多様な動作を実現し、それによりソフトウェアを実行するために必要とされる処理能力を削減するために専用のハードウェア加速装置を作成するために改良できることが注記される。ただし、必要とされる動作は、十分な処理能力が使用できる場合にソフトウェアで実現されてよい。
【０６７４】
モジュール及び他の構成要素は、オプションの好ましい特徴とともに、各構成要素により提供される特徴及び機能という点で説明されてきた。与えられる情報及び提供される仕様により、これらの特徴の実際の実現及び正確な詳細は実施者に委ねられる。一例に、一定のモジュールが、好ましくはＣプログラミング言語で作成され、好ましくはアプリケーションを実行するために使用されるプロセッサ上で実行するためにコンパイルされるソフトウェアで実現できるだろう。ただし、いくつかの構成要素は別のプロセッサ上で実行されてよく、いくつかのまたはすべての構成要素は専用ハードウェアにより実現されてよい。
【０６７５】
前記のモジュール及び構成要素は単に例証的であり、発明は多岐に渡る方法で実現されてよく、特に、いくつかの構成要素は、類似する機能を実行する他と結合されてよいか、あるいはいくつかは簡略化された実現では省略されてよい。機能のそれぞれのハードウェアとソフトウェアの実現は、構成要素間と単一構成要素内の両方で自由に混合されてよい。
【０６７６】
ハードウェア、コンピュータソフトウェア等により実行される機能は、電気信号と類似する信号に対して、または電気信号と類似する信号を使用して実行されることは容易に理解されるだろう。ソフトウェア実現はＲＯＭに記憶されてよいか、あるいはＦＬＡＳＨ内でパッチされてよい。
【０６７７】
好ましい実施形態の第３の一般的な態様を見ると、ビットストリームの転送を制御するためのコマンドセットがここでさらに詳細に説明される。
【０６７８】
コマンドセット
前述されたパーソナルビデオレコーダアプリケーション（これからは「ＰＶＲ」と呼ばれる）３１５４は、ユーザが、ハードディスク２１００などの大容量記憶装置に、音声及び／または画像データ（おもに受信機／デコーダに一斉送信された番組）を記録できるようにし、このような音声／画像データをプレイバックすることもできるようにするパーソナルビデオレコーダシステム（「ＰＶＲ」システム）の一部である。データは、（好ましい実施形態ではＭＰＥＧ−２フォーマットの）連続して並べられたデータとして記憶され、本来、ＰＶＲは、ユーザにこのデータまたは類似するデータにアクセスするためのさまざまな方法を与える（実際には、根本的にはここに後述されるのと同じ原則を使用して、純粋に音声コンテンツを記録し、プレイバックするための対応するアプリケーションも提供される）。
【０６７９】
図４０に関して、ＰＶＲシステムが、ここにさらに詳しく説明されるだろう。ハードディスク２１００（または他の大容量記憶装置）は、ＦＩＦＯ及びメモリバス（図示されていない）を介してデマルチプレクサ／デスクランブラ／リマルチプレクサ２１００とＭＰＥＧデコーダ２０２８の両方に接続され、その結果、音声／画像データは（チューナと復調器―図示されていない−によって出力される）ライブ放送信号入力、受信機／デコーダメモリ（図示されていない）、（接続されているテレビ上での表示のため、図示されていない）ＭＰＥＧデコーダ、及びハードディスク２１００の間で自由に送ることができる。
【０６８０】
言及されたハードウェア構成要素は、ソフトウェアデバイス（図示されていない）によって、特に大容量記憶装置３７２８及び（間接的に）サービスデバイス３７３６によって制御される。同様に、大容量記憶装置及びサービスデバイスは、２つの記録スレッド３８５４、３８５６、プレイバックスレッド３８５８、及び共用ファイリングシステムライブラリ（「ＦＳライブラリ」）３８５２を備える、ハードディスクビデオレコーダ（ＨＤＶＲ）モジュール３８５０によって制御される。最後に、ＰＶＲアプリケーション３１５４が、プログラムインタフェース７０００を介してＨＤＶＲモジュールにコマンドを発光する。
【０６８１】
図４０で分かるように、ＰＶＲシステムは、複数の層に分割され、本来コマンドのチェーンの上部に常駐するＰＶＲアプリケーションが、ファイルポインタを記録し、管理するためにハードディスク上で空間を割り当てるなどの低レベルの検討材料をまったく無視することができる効果がある。さらに詳しく後述されるように、ＰＶＲシステム内のインタフェースの注意深い設計によって、ＰＶＲアプリケーション３１５４が下にあるＨＤＶＲモジュール３８５０に送信する指示は、記憶されている番組での指定位置でプレイバックを開始する、及び番組をコマごとに通過するなどの、ＰＶＲによって実行される一種の自明の動作に密接に対応する。
【０６８２】
ＰＶＲ３１５４とＨＤＶＲモジュール３８５０間のインタフェース７０００は、それが、それぞれが典型的なユーザ動作に相当する複数の異なるコマンドを実行する場合には、より単純なアプリケーションを開発できるようにするが、記録スレッドとプレイバックスレッド３８５４、３８５６、３８５８の間のインタフェース７００２は、対照的に、最小のコマンドセットを実現し、特に、下にあるＦＳライブラリの効率を高めることができるようにするデータ（再生速度を設定するためのコマンドと、再生位置を設定するためのコマンド）の再生に２つのコマンドだけを提供する。ＦＳライブラリとデバイス間、及びデバイスとハードウェアの間の追加のインタフェースは、追加レベルの抽象を可能にする。
【０６８３】
（ＰＶルーチンを備える）コマンドの第１の一番上の層７０１０、（記録スレッド及びプレイバックスレッド３８５４、３８５６、３８５８内のルーチンを備える）コマンドの第２のミッドレンジ層、（ＦＳライブラリルーチンを備える）コマンドの第３層７０１４、及びオートマタ７０１６を備えるコマンドの第４の一番下の層を含む、後述されるだろう４つのレベルのコマンド。前述されたように、いう前も無く、コマンドの追加の層は、これらの４つの層の下、及びおそらく上に存在するが、これらは前述されたとおりである。
【０６８４】
ＰＶＲシステムのプレイバック態様の基礎となるのは、「現在再生位置」及び「現在再生速度」（他のところでは、それぞれ単に「現在位置」及び「現在速度」と呼ばれる）の概念である。これらの２つの値は、ハードディスク２１００上に記憶される番組及び／または他のデータのプレイバックを制御するために、ハードウェア（ハードディスク、デマルチプレクサ、リマルチプレクサ、ＭＰＥＧ−２デコーダ、及び／またはＦＩＦＯシステム）によって解釈され、さらに詳しく後述されるように、制御ソフトウェアの多様な部分によって改変できる。ＰＶＲシステムの記録態様という点では、「現在記録位置」の概念は既知であるが、対照的に、「現在記録速度」は無意味である。
【０６８５】
ＨＤＶＲプレイバックスレッド３８５８に関係するインタフェースの態様だけがここで検討されることが注記されなければならないが、読者は、ここに説明される一般原則が、記録スレッド３８５４、３８５６、及びそれらのそれぞれのインタフェースにも適用できることを理解するだろう。
【０６８６】
図４１に関して、概して、ＰＶＲアプリケーション３１５４（「ＨＤＶＲプレイバックルーチン」）が使用できるＨＤＶＲプレイバックスレッド３８５８（第２コマンド層７０１２）内の６つのコマンドが、図示される。つまり、ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（）７０４０ルーチン、ｓｅｅｋ＿ｓｌｏｗ＿ｐｌａｙ（）７０４２ルーチン、ｓｅｅｋ＿ｎｏｒｍａｌ＿ｐｌａｙ（）７０４４ルーチン、ｓｅｅｋ＿ｆａｓｔ＿ｐｌａｙ（）７０４６ルーチン、ｓｉｎｇｌｅ＿ｐｌａｙ（）７０４８ルーチン及びｐａｕｓｅ（）７０５０ルーチンである。同様に、ＦＳライブラリ３１５２（第３コマンド層７０１４）は、２つのコマンド（「ＦＳライブラリルーチン」）、つまりｓｅｔ＿ｐｏｓ（）７０３０ルーチンとｓｅｔ＿ｓｐｅｅｄ（）７０３２ルーチンを提供する。ＰＶＲアプリケーション３１５４も図示されており（第１コマンド層７０１０）、その構成機能は後述され、ＦＳライブラリ３８５２の下には、ｓｅｔ＿ｓｐｅｅｄ（）ルーチンとｓｅｔ＿ｐｏｓ（）ルーチンが通信する（サービスデバイス及び大容量記憶装置などの）多様なデバイスが図示されている。図中の矢印は、各オブジェクトまたはルーチンによって典型的に行われる関数呼び出しを示す。
【０６８７】
ｓｅｔ＿ｐｏｓ（）７０３０ルーチンとｓｅｔ＿ｓｐｅｅｄ（）７０３２ルーチンを備える第３コマンド層７０１４が、最初に説明されるだろう。
【０６８８】
ｓｅｔ＿ｐｏｓ（）ルーチンとｓｅｔ＿ｓｐｅｅｄ（）ルーチンは、ＨＤＶＲプレイバックスレッド３８５８によって提供される６つのルーチン７０４０、７０４２、７０４４、７０４６、７０４８及び７０５０を含む典型的なプレイバック動作の任意の組み合わせが、現在の再生速度または現在の再生位置のどちらかを設定する自明のコマンドのシーケンスまで引き出せるだろうという発見に続いて提供された。
【０６８９】
ｓｅｔ＿ｐｏｓ（）ルーチンは、ストリーム内の再生の現在位置をパラメータとして指定される位置に設定する。好ましい実施形態においては、パラメータは記憶されるストリームの始まりからのセンチセカンド単位のタイムオフセットであるが、好ましい実施形態の変形では、異なる単位が使用される。追加の変形では、パラメータは、記憶されるストリームの始まりからのバイトオフセット（または他の空間オフセット）を指定する。下記に注記されるように、この後者の変形はより効率的であるが、一定の難事を呈する。
【０６９０】
同様に、ｓｅｔ＿ｐｏｓ（）コマンドは、関連するバイトオフセットを含むコマンドを、大容量記憶装置３７２８などの下位のデバイス（複数の場合がある）に送る。多くの種類の符号化されたビデオまたは音声ストリームにおいて（及び、特にＭＰＥＧ−２において）の起点からのバイトオフセットが、その起点からのタイムオフセットに対して一定の線形関係を有さないことを認識することは、この段階では重要である。したがって、好ましい実施形態においては、タイムオフセットと空間オフセットの間では変換が内部的に必要とされる。これは、タイムオフセットをバイトオフセットにマッピングするテーブルを使用して指定された時間的な解像度まで達成し、次に所望されるフレームを見つけるためにＭＰＥＧ２データの短い長さを走査、復号することによって精緻化することができる。追加変形においては、ｓｅｔ＿ｐｏｓ（）コマンドのパラメータは、バイトオフセットの前述されたテーブルの中への索引である。
【０６９１】
性能の理由から、ｓｅｔ＿ｐｏｓ（）コマンドが呼び出されるたびに、それは指定された位置までジャンプし、次にその位置の後で第１Ｉ−フレーム（または同等な独立した――依存とは対照的な――ＭＰＥＧ以外のフォーマットのフレーム）を見つけ、表示するために前方に走査する。Ｉ−フレームは一般的には０.５秒ごとに発生するため、この動作は、（後述される）いくつかのアプリケーションではわずかな「ぎくしゃく」を生じさせる。しかしながら、好ましい実施形態の変形においては、ｓｅｔ＿ｐｏｓ（）コマンドは、ＭＰＥＧデコーダに、それが過去のＩ−フレームを見つけるまで後方に走査させてから、再び（補間されたフレームなどのＩ−ではないフレームである場合がある）所望される位置まで前方に走査させる。より低速であるが、この後者の動作は、（デコーダが十分に進められている場合には）一般的により円滑なプレイバックを生じさせる。
【０６９２】
ｓｅｔ＿ｓｐｅｅｄ（）ルーチンは、ストリームが処理される速度を、パラメータとして指定される速度に設定する。再び、バイトオフセットと時間の間の非線形関係を念頭に入れると、速度は通常のプレイバック速度の倍数として指定される（つまり、１を超えるパラメータは、早送りに同等であり、１未満のパラメータはスロープレイに同等である）。０というパラメータを渡すと、再生を休止する効果があり、負のパラメータはストリームを巻き戻すことに同等である。好ましい実施形態の変形においては、パラメータは、１秒あたりのコマ数（例えば、通常のプレイバックの場合３０）、またはコマ間の秒（例えば、通常のプレイバックの場合、１秒あたりのコマ数の逆数、１／３０）などの異なる単位で指定される。一定のビットレートのビデオソースの場合、あるいはビットレートの変動が無視することができる指定された目的のためである状況（例えば、早送りまたは巻き戻しの高速で）では、速度もビットレートという点で指定されてよい。
【０６９３】
（例えば、ＭＰＥＧ２などの）視聴覚及び／または他の種類のデータに使用されるいくつかの符号化方法の性質は、それが、指定された点から開始し、一方向で信号を通って前進することによる以外読み取ることができず、そのためビデオ信号中の時間の点は復号が進行するにつれて進むほどである。言い換えると、それは逆方向に復号できない。これは、特に、トランスポートパケットの集合体の形でＭＰＥＧ２フォーマットで符号化されるビデオ番組に当てはまる。これは、転送速度とは無関係である。データを時間逆転方法で再生するためには、複数の短い読み取り動作が、ストリーム中の連続して先行する点で実行され、毎回信号フレームを入手してから信号フレームを出力し、時間が逆転したビデオ信号の印象を与える。
【０６９４】
オートマタ
コマンドの第４層は、ナビゲーション関数及びナビゲーション状態間の遷移を確証するオートマトンを実現する。
【０６９５】
好ましい実施形態において第４層７０１６によって実現されるオートマトンは、テーブルに図示されるようなナビゲーション関数のリンクを確証する。
【０６９６】
オートマトンのための動作
【０６９７】
【表１】
0004257084.tif 000009
オートマトンの状態
テーブル中で使用される文字ａとｂは、再生、遅送りまたは巻き戻し、あるいは早送りまあは巻き戻しのいずれかの速度を表す。
【０６９８】
左側の欄の記号はコマンド受信時のオートマトンの状態を表し、上の行の記号はオートマトンに送信されたコマンドを表し、テーブル内の項目は、コマンド実行後のオートマトンの対応する状態を表す。
【０６９９】
したがって、例えば、初期のオートマトン状態が速度ａでの早送りであり、章を前方へジャンプのコマンドが受信される場合、システムは、新しい章を通って早送りし続けるよりむしろ、１章前方へジャンプしてから、通常の速度で再生するだろう。
【０７００】
第４コマンド層は、第３コマンド層からｓｅｔ＿ｐｏｓｉｔｉｏｎコマンドとｓｅｔ＿ｓｐｅｅｄコマンドを受信し、システムの現在の状態を考慮し、コマンドが許容された状態への遷移を生じさせることを確証する。コマンドが許容された状態への遷移を生じさせると、コマンドは実行のために渡される。
【０７０１】
第４コマンド層によって受信されるコマンドが、オートマトンによって許容されない状態への遷移を生じさせる場合には、最も簡略なケースでは、第４コマンド層がコマンドを無視させるだろう。
【０７０２】
しかしながら、好ましい実施形態においては、及び一定のコマンド及びシステムの状態の場合、第４コマンド層により受信されるコマンドが、コマンドを無視させるよりむしろ、オートマトンにより許容されない状態への遷移を生じさせる場合には、第４コマンド層がｓｅｔ＿ｐｏｓｉｔｉｏｎコマンドまたはｓｅｔ＿ｓｐｅｅｄコマンドのどちらかを改変してから、この新しいコマンドが有効な状態への遷移を生じさせるかどうかをチェックする。生じさせる場合、新しいコマンドが実行のために渡され、生じさせない場合には、コマンドは再び改変される。コマンドの修正が後に続く、コマンドを確証しようとするこの再帰的な試みは、有効な状態への遷移を生じさせるだろうコマンドが生成されるまで進行する。
【０７０３】
したがって、例えば、特定の実施形態においては、早送り動作中にファイル内の新しい位置にジャンプすることは許されていない。
【０７０４】
当初、早送り動作中、システムの状態は、現在のｓｅｔ＿ｐｏｓｉｔｉｏｎ、Ｘ、及びｓｅｔ＿ｓｐｅｅｄ、Ｖコマンドの状態を記録し、これらの状態が変更したのか（フラグ値＝１）あるいは同じままなのか（フラグ値＝０）の通知を出す、以下のテーブルにより表されてよい。
【０７０５】
【表２】
0004257084.tif 000010
新しい位置にジャンプするコマンドを受信すると、テーブルは変更する。
【０７０６】
【表３】
0004257084.tif 000011
第４コマンド層は、この遷移が許されるかどうかをチェックし、次にこのケースでは遷移は許されていないため、有効な遷移が発見されるまで、ｓｅｔ＿ｓｐｅｅｄ状態を改変させる。
【０７０７】
【表４】
0004257084.tif 000012
フラグは、前記テーブルに示されるようにゼロにリセットされ、コマンドは実行され、システムは新しい位置から通常の速度でコンテンツを最後まで再生する。
【０７０８】
好ましい実施形態においては、第４コマンド層は親制御及び条件付きアクセス機構にリンクされる。状態は、部分的に、親制御または条件付きアクセスパラメータに応じてオートマトンによって許可または禁止される。
【０７０９】
したがって、例えば、それは、広告を含むファイル内の特定の章を通って早送りする、または巻き戻す、あるいはユーザがこのようなコンテンツを視聴する許可を有さない場合には、アダルトコンテンツを含む特定の章にジャンプすることは許されていない。
【０７１０】
第４コマンド層が親制御機構にリンクされる実施形態の動作の一例が後述される。
【０７１１】
システムの状態は、再び、現在のｓｅｔ＿ｐｏｓｉｔｉｏｎ、Ｘ、及びｓｅｔ＿ｓｐｅｅｄ、Ｖコマンドの状態を記録し、これらの状態が変化した（フラグ値＝１）のか、あるいは同じままであるのか（フラグ値＝０）を通知するテーブルによって表される。
【０７１２】
【表５】
0004257084.tif 000013
それから、ｓｅｔ＿ｐｏｓコマンドが受信される。
【０７１３】
【表６】
0004257084.tif 000014
このコマンドは、ユーザが視聴する許可を有していない章への位置のジャンプに相当する。したがって、第４コマンド層は、ｓｅｔ＿ｐｏｓｉｔｉｏｎを修正させ、これらのコマンドにより表される遷移が許されるかどうかをチェックする。
【０７１４】
【表７】
0004257084.tif 000015
コマンドは、再びユーザが視聴する許可を有していない後の章までの位置のジャンプに相当する。したがって、第１コマンド層は、ｓｅｔ＿ｐｏｓｉｔｉｏｎを再び修正させ、これらのコマンドにより表される遷移が許されるかどうかを再チェックする。このケースでは、遷移は許され、フラグがゼロにリセットされ、コマンドは実行のために渡され、システムは最初に要求された章より後の章からコンテンツを再生する。
【０７１５】
【表８】
0004257084.tif 000016
コマンドの第２層７０１２の説明を始める前に、（最上コマンド層７１００内の）ＰＶＲアプリケーションの機能性を具体化する高レベルＰＶＲルーチンが、ここで簡略に説明されるだろう。明快さのため、低レベルルーチンとの混同を回避するために、ＰＶＲ内の各ルーチン（「ＰＶＲ」ルーチン）には、典型的には従来のビデオレコーダに関して遭遇するものに密接に関係する記号が指定され、記号はテーブルの中に下記に一覧表示される。
【０７１６】
【表９】
0004257084.tif 000017
一般的には、前記ＰＶＲアプリケーション機能のそれぞれは、ユーザがリモートコントローラの単一のボタンを押す、あるいは画面上のメニューで単一オプションを選択することによって呼び出される。このようにして、それらは、（（前述されたｓｅｔ＿ｓｐｅｅｄ（）コマンドとｓｅｔ＿ｐｏｓ（）コマンドなどのソフトウェアの観点から自明のコマンドとは別個の）ユーザの観点から自明のコマンドに対応する。言うまでもなく、前記に一覧表示された機能の追加機能または代替機能を認識することができる。特に、前記は例えばミュージックトラックなどに対応する索引付きの音声プレーヤとして使用するために適応できるだろう。
【０７１７】
依然として図４１を参照すると、第２コマンド層７０１２内のＨＤＶＲプレイバックスレッド３８５８によって提供される６つのコマンドが、ここで説明されるだろう。
【０７１８】
前述されたように、ＨＤＶＲスレッド３８５８内の６つのコマンドは、４つの「ｓｅｅｋ＿ｐｌａｙ」動作、つまりｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（）７０１０、ｓｅｅｋ＿ｓｌｏｗ＿ｐｌａｙ（）７０１２、ｓｅｅｋ＿ｎｏｒｍａｌ＿ｐｌａｙ（）７０１４、及びｓｅｅｋ＿ｆａｓｔ＿ｐｌａｙ（）７０１６を備える。これらの基本的な動作に加えて、２つの他の初歩的な動作、つまりｓｉｎｇｌｅ＿ｐｌａｙ（）７０１８とｐａｕｓｅ（）７０２０がある。これらの動作はともに前述されたｓｅｔ＿ｐｏｓ（）７０３０ルーチンとｓｅｔ＿ｓｐｅｅｄ（）７０３２ルーチンの機能性を、ＰＶＲアプリケーション３１５４及び類似するアプリケーションにとってさらに有効であるさらに高いレベルのルーチンに要約する。これらのルーチンは、ここで、さらに詳細に説明されるだろう。
【０７１９】
シーク−プレイ動作のそれぞれは、データストリーム中の現在の読み取りポインタの位置を設定してから、所望される効果を達成するために、ｓｅｔ＿ｐｏｓ７０３０ルーチンとｓｅｔ＿ｓｐｅｅｄ７０３２ルーチンの両方を利用するプロセスで、複数のモードの１つでそのポインタから前方にストリームを再生し続ける。好ましい実施形態においては、６つのルーチンのパラメータは、下にあるｓｅｔ＿ｐｏｓ（）ルーチンとｓｅｔ＿ｓｐｅｅｄルーチンのパラメータに同等である（すなわち、それぞれセンチセカンドタイムオフセットと通常の再生速度の倍数）。しかしながら、好ましい実施形態の変形においては、（例えば、それぞれバイトオフセット及びフレーム間遅延などの）さまざまなパラメータが、６つのルーチン７０１０、７０１２、７０１４、７０１６、７０１８、７０２０について指定されてよく、パラメータの必要な変換は、ｓｅｔ＿ｐｏｓ（）ルーチン及び／またはｓｅｔ＿ｓｐｅｅｄ（）ルーチンが呼び出される前に、ルーチン内で行われる。
【０７２０】
これらのルーチンのそれぞれの動作が、ここで説明されるだろう。
【０７２１】
・ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（）は、現在の再生オフセットを、ルーチンのパラメータとして指定されるオフセットに設定してから、プレイバックが休止されたままである間に、そのオフセットから（またはそのオフセットに可能な限り近くの）単一フレームを再生する。それは、プレイバックが休止された（休止）ときに、ストリーム内の１（前の索引、次の索引、前の章、次の章）を改変するＰＶＲルーチンによって使用される。
【０７２２】
・ｓｅｅｋ＿ｎｏｒｍａｌ＿ｐｌａｙ（）は、現在の再生オフセットを、ルーチンのパラメータとして指定されるオフセットに設定してから、その点から前方にデータスｓトリームのコンテンツを再生し、通常の速度でストリームを通って進む。それは、ストリーム内の位置（前の索引、次の索引、前の章、次の章）を改変するＰＶＲルーチンによる（ＰＶＲ再生ルーチン［再生］によって活性化されるような）通常のプレイバックの間に使用される。
【０７２３】
・ｓｅｅｋ＿ｆａｓｔ＿ｐｌａｙ（）は、現在の再生オフセットを、ルーチンのパラメータとして指定されるオフセットに設定してから、その点から前方にデータストリームのコンテンツを再生し、通常の速度より速くストリームを通って進む。それは、ストリーム内の位置（前の索引、次の索引、前の章、次の章）を改変するＰＶＲルーチンによる早送り再生（早送り）の間に使用される。
【０７２４】
・ｓｅｅｋ＿ｓｌｏｗ＿ｐｌａｙ（）は、現在の再生オフセットをルーチンのパラメータとして指定されるオフセットに設定してから、その点から前方にデータストリームのコンテンツを再生し、通常の速度より遅くストリームを通って進む。それは、ストリーム内の位置（前の索引、次の索引、前の章、次の章）を改変するＰＶＲルーチンによる遅送り再生の間に使用される。
【０７２５】
・ｓｉｎｇｌｅ＿ｐｌａｙ（）は、ルーチン休止（休止）がすでに呼び出されているときに、ストリーム内でコマごとに前進するルーチンによって使用される。それは、後述されるようにいくつかの引き出されたルーチンでも使用される。
【０７２６】
・ｐａｕｓｅ（）は、ＰＶＲ休止ルーチン（休止）によって使用される。それは、ストリームを現在のフレームで中断させる。ＨＤＶＲモジュールは、それ自体、直接的にディスプレイ装置を制御しないのでこのようなｓｔｏｐ（）ルーチンはない。サービスデバイス３７３６、ビデオデバイス３７３４、及びＦＩＦＯデバイス３７４４などのＨＤＶＲモジュールの外部の機構は、前記に詳しく説明されたように、ビデオ出力を実際に制御するために使用される。
【０７２７】
好ましい実施形態の変形においては、ｓｅｅｋ＿ｆａｓｔ＿ｐｌａｙ（）ルーチン、ｓｅｅｋ＿ｓｌｏｗ＿ｐｌａｙ（）ルーチン、及びｓｅｅｋ＿ｎｏｒｍａｌ＿ｐｌａｙ（）ルーチンの少なくとも２つが、オフセットと速度の両方をパラメータとして取る単一のｓｅｅｋ＿ｐｌａｙ（）ルーチンによって置換される。これらのパラメータの考えられる置換は、ｓｅｔ＿ｐｏｓ（）ルーチンとｓｅｔ＿ｓｐｅｅｄ（）ルーチンに関して前述されるとおりである。
【０７２８】
好ましい実施形態においては、前記に注記されたように、異なるＨＤＶＲプレイバックルーチンが、現在のプレイバック状態（休止、通常、遅送りまたは早送り）に応じＴＰＶＲルーチンによって呼び出される。これは、有利なことに、ＨＤＶＲプレイバックルーチンを簡略化できるようにし、その結果、それらは（休止または再生、早送り、巻き戻し、遅送り等の）プレイバックの１つのモードと対処しさえすればよい。しかしながら、好ましい実施形態の変形においては、ＨＤＶＲプレイバックルーチンは、任意の再生モードで動作できる。
【０７２９】
同時に、下にあるｓｅｔ＿ｐｏｓ（）ルーチンとｓｔ＿ｓｐｅｅｄ（）ルーチンは、ＰＶＲルーチンと同様に、再生モードとは無関係である。ＨＤＶＲプレイバックルーチンとは対照的に、ＦＳライブラリは構造でより簡略であるが、プレイバックモードのすべての偶然性と対処するために、潜在的にさらに複雑なコード化を必要とする。
【０７３０】
導関数
幅広い範囲の導関数を、前述されたコマンドの３つの層７０１０、７０１２、７０１４の任意の組み合わせを使用して実現できる。以下は、このような関数の例を表す。これらの例では、前述された現在の再生位置は、「ｃｕｒ＿ｐｏｓ」と呼ばれる。
【０７３１】
前述されたように、真に時間が逆転された方向でデータストリームを通って再生することは、通常、ＭＰＥＧ−２データに対しては可能ではなく、そうでなければせいぜい困難である。したがって、前述されたように、時間が逆転された再生は、データストリームを通って逆方向にジャンプし、ジャンプするたびに、単一のフレームを得るためにデータストリームの短いセグメントを復号し、それぞれのこのようなフレームを表示することによってエミュレートされる。
【０７３２】
ストリーム中の（「巻き戻し」方向での）逆方向への移動を含むすべてのこのような動作は、標準再生動作から引き出される。これらの動作の説明は、データストリームが水平線で表され、それぞれの垂直矢印がストリーム中の特定の点の再生を表す図４２から図４７に描かれている。通常の再生中、ストリームは図の左から右の方向で再生される。
【０７３３】
さらに、以下から分かるように、「ｓｅｅｋ＿ｐｌａｙ」ルーチンを使用する多くのルーチンを、代わりにｓｉｎｇｌｅ＿ｐｌａｙ（）ルーチンだけから引き出すことができる。
【０７３４】
前方方向での高速再現早送り
この動作は、以下のシーケンスで具体化されてよい。
【０７３５】
ｐａｕｓｅ（）
ｓｅｅｋ＿ｆａｓｔ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
図４２は、（図示されるように、定期的なＩ−フレームを備える）ＭＰＥＧデータに対するｓｅｅｋ＿ｆａｓｔ＿ｐｌａｙ（）ルーチンの動作を描く。分かるように、音声／画像データは、（例えば、通常のプレイバック速度の８倍から１２倍の間の最大に復号ハードウェアによって制限される）高い速度で前方に走査され、画像はリフレッシュ速度で定期的に表示される。表示されるフォーマットは、ＭＰＥＧデコーダが画像リフレッシュのためにその時点でどこに到達したのかに応じて、Ｉ−フレームと非Ｉ−フレームの混合体である。
【０７３６】
前記に注記されたように、ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（）関数と関係する関数のさらにコンパクトな実施形態の１つは、タイムオフセットの代わりに、音声／画像ファイル内の実際のデータオフセットのパラメータを取る。
【０７３７】
非常に速い前進が必要とされるケースでは、及びＭＰＥＧ−２デコーダがこうすることができるすべての追加のケースでは、ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（）ルーチンの前述されたデータオフセットバージョンを使用して早送り関数を達成するために、短いルーチンが構築できる。この短いルーチンは、図４３に関して以下に示される。
【０７３８】
ｐａｕｓｅ（）
ｐｌａｙ＿ｔｉｍｅ中のループ
ｃｕｒ＿ｐｏｓ＋ｃｏｎｓｔａｎｔ＿ｄａｔａ＿ｏｆｆｓｅｔ
ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）／／音声／画像ファイル内のｃｕｒ＿ｐｏｓデータオフセットでのフレームを表示
ｐａｕｓｅ＿ｔｉｍｅ中に休止    ／／  次のリフレッシュを待機
ＥｎｄＬｏｏｐ
この方法は、ストリーム内で間隔をあけて置かれる前方ジャンプの技法を使用する。ｐｌａｙ＿ｔｉｍｅの値は、コマンド早送りがアクティブなままとなる持続時間に相当する。値ｐａｕｓｅ＿ｔｉｍｅを調整し、ビデオ表示を修正することも可能である。
【０７３９】
ジャンプごとのオフセット（前記コード内の「オフセット」）は、音声／画像データの平均ビットレートの倍数として計算することができ、その結果、例えば、平均ビットレートの３倍のオフセットは、通常の再生速度の約３倍の再現速度を生じさせるだろう。しかしながら、図４３から分かるように、音声／画像データのビットレートは、典型的には、時間に関して（確かにＭＰＥデータに対して）一定ではないため、一定のデータ増分は、フレームの一様ではないプレイバックを生じさせる。
【０７４０】
それにも関わらず、この後者の方法を使用して、早送りするのにかかる時間は、再現速度に関係なくほぼ一定であり、その結果再現速度は、（通常の再生速度の１２８倍など）任意に高くすることができ、それ以外に場合、早送り動作中に容易に変えることができる。また、すべてのデータを走査する必要があるわけではないため、この例のデータを通して走査するにはより少ない時間が費やされることも観察できる。
【０７４１】
最後に類似するが、ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（）ルーチンの「タイムオフセット」バージョンを使用して、さらに高度な早送り動作を達成でき（それにより、現在の再現位置は音声／画像データの中にタイムオフセットとして指定され）る。
【０７４２】
ｐａｕｓｅ（）
ｐｌａｙ＿ｔｉｍｅ中のループ
ｃｕｒ＿ｐｏｓ＋ｃｏｎｓｔａｎｔ＿ｄａｔａ＿ｏｆｆｓｅｔ
ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（ｃｕｒ−ｐｏｓ）
ｐａｕｓｅ＿ｔｉｍｅ中のループ
ＥｎｄＬｏｏｐ
このコードの動作は、図４４に描かれている。この例では、ｃｏｎｓｔａｎｔ＿ｔｉｍｅ＿ｏｆｆｓｅｔ（及び、タイムオフセットをデータオフセットにマッピングする、及び逆もまた同様の前述されたテーブルの粒度）は、Ｉ−フレーム間の期間の倍数となるように選ばれる。復号するのに要する時間がより一様であり、表示されるフレームが時間という点で等しく間隔をあけて置かれ、より円滑な早送り動作を生じさせることが分かる。ｓｅｔ＿ｐｏｓ（）ルーチンに対する、それが、Ｉ−以外のフレームを復号できるように前述されていたＩ−フレーム以外のフレームにジャンプできるようにするための（前述された）修正を用いて、事実上、Ｉ−フレーム期間の倍数以外の早送り速度を使用できる。
【０７４３】
タイムオフセットフィールドとデータオフセットフィールドの両方を含む索引表（「ｉｎｄｅｘ＿ｔａｂｌｅ」）を使用して、タイムオフセット（「ｔｉｍｅ＿ｏｆｆｓｅｔ」）と適切なデータオフセット（「ｄａｔａ＿ｏｆｆｓｅｔ」）の変換を実行するために必要とされる擬似コードの例は、以下のとおりである。
【０７４４】
索引＝０
（ｉｎｄｅｘ＿ｔａｂｌｅ［ｉｎｄｅｘ］ｔｉｍｅ＿ｏｆｆｓｅｔ＜ｔｉｍｅ＿ｏｆｆｓｅｔ）
｛    索引＋＋    ｝
ｄａｔａ＿ｏｆｆｓｅｔ＝ｉｎｄｅｘ＿ｔａｂｌｅ［ｉｎｄｅｘ］ｄａｔａ＿ｏｆｆｓｅｔ
言うまでもなく、前記コードは、ここに詳説される適切なルーチンのどれかで実現できる。索引表を使用するように適応される前記の早送りルーチンのわずかな変形は、以下のとおりである。
【０７４５】
ｐａｕｓｅ（）
ｃｕｒ＿ｉｎｄｅｘＧｅｔＣｕｒＩｎｄｅｘ（ｃｕｒ＿ｐｏｓ）／／前記に詳説された方法を使用して現在の索引を見つける
ｐｌａｙ＿ｔｉｍｅ中のループ
ｃｕｒ＿ｐｏｓ＝ｉｎｄｅｘ＿ｔａｂｌｅ［ｃｕｒ＿ｉｎｄｅｘ］ｄａｔａ＿ｏｆｆｓｅｔ
ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
ｃｕｒ＿ｉｎｄｅｘ＋＝ｎ／／ｎというさらに高い値が、さらに高速な有効再現速度を示す。
【０７４６】
ｐａｕｓｅ＿ｔｉｍｅ中の休止
ＥｎｄＬｏｏｐ
逆方向での高速再現早巻き戻し
（タイムではなく）データオフセットを使用する基本（且つ高速）巻き戻し関数は、（早送りについて前記の類似する例に基づき、図４５に描かれている）以下のとおりである。
【０７４７】
ｐａｕｓｅ（）
ｐｌａｙ＿ｔｉｍｅ中のループ
ｃｕｒ＿ｐｏｓ−＝ｃｏｎｓｔａｎｔ＿ｄａｔａ＿ｏｆｆｓｅｔ
ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）／／データオフセットをパラメータとして使用するｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙルーチンのバージョン
ｐａｕｓｅ＿ｔｉｍｅ中の休止
ＥｎｄＬｏｏｐ
前記のように、再現されたビデオの速度は、（パラメータｐａｕｓｅ＿ｔｉｍｅを変えることで）遅延の持続時間を調整し、パラメータｃｏｎｓｔａｎｔ＿ｄａｔａ＿ｏｆｆｓｅｔを調整することでストリーム内の変位を変えることによって制御することができる。
【０７４８】
再び、フレーム間の距離は一定ではなく、逆方向に一様にではなく進行することが分かる。この例及び以下の例では、逆方向へのジャンプが、少なくとも１つのＩ−フレームに及ぶほど十分に大きくなるように注意を払わなければならない（それ以外の場合、同じＩ−フレームを無限に表示するループに入るだろう）。
【０７４９】
データオフセットよりむしろタイムオフセットを使用する、さらに高度なバージョンは、図４６に図示されている。これは、以下のように行われてよく、図４５に描かれている。
【０７５０】
ｐａｕｓｅ（）
ｐｌａｙ＿ｔｉｍｅ中のループ
ｃｕｒ＿ｐｏｓ−＝ｃｏｎｓｔａｎｔ＿ｔｉｍｅ＿ｏｆｆｓｅｔ
ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）／／タイムオフセットを使用するｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（）ルーチンのバージョン
ｐａｕｓｅ＿ｔｉｍｅ中の休止
ＥｎｄＬｏｏｐ
前記のように、例えば、通常の再生速度の１倍から１２８倍の範囲内の再現速度の変動を可能にすることが適切であってよい。
【０７５１】
前方方向での低速再現＞
図４７に描かれるように、この機能は、以下のコードにいよって具体化できる。
【０７５２】
ｐａｕｓｅ（）
ｓｅｅｋ＿ｓｌｏｗ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
図４７に図示されるように、ｓｅｅｋ＿ｓｌｏｗ＿ｐｌａｙ（）コマンドの効果は、（プレイバック速度に応じて、複数の画面リフレッシュ速度については、それらの一定またはすべてを表示することを除き）通常より低速で音声／画像データを通って走査し、通常通りにフレームのすべてを表示することである。
【０７５３】
ｓｉｎｇｌｅ＿ｐｌａｙ（）コマンドを使用する遅送りコマンドの代替実施形態は、図４８に関して以下のとおりである。
【０７５４】
休止
ｐｌａｙ＿ｔｉｍｅ中のループ
ｓｉｎｇｌｅ＿ｐｌａｙ（）
ｐａｕｓｅ  ｄｕｒｉｎｇ  ｐａｕｓｅ＿ｔｉｍｅ
ＥｎｄＬｏｏｐ
前記に注記されたように、（ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（）ルーチンと対照的に）ｓｉｎｇｌｅ＿ｐｌａｙ（）ルーチンは、（非Ｉフレームを含む）１フレームごとに音声／画像ストリームを前進させる。ルーチンは、再現の速度（または、さらに一般的には、他のところに記述されるように、転送速度）がｐａｕｓｅ＿ｔｉｍｅ変数を改変することにより、容易にカスタマイズできるという点で、前記に示されたｓｅｅｋ＿ｓｌｏｗ＿ｐｌａｙ（）変形とは異なる。
【０７５５】
ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（）コマンドを使用するが、遅送り能力を達成するための追加ルーチンは以下のとおりである。
【０７５６】
休止
ｐｌａｙ＿ｔｉｍｅ中のループ
ｃｕｒ＿ｐｏｓ−ｃｏｎｓｔａｎｔ＿ｔｉｍｅ＿ｏｆｆｓｅｔ
ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
ｐａｕｓｅ＿ｔｉｍｅ中の休止
ＥｎｄＬｏｏｐ
このコードは、ｐａｕｓｅ＿ｔｉｍｅとｃｏｎｓｔａｎｔ＿ｔｉｍｅ＿ｏｆｆｓｅｔが、通常のプレイバック速度より遅い速度での早送りを達成するために選ばれる点を除き、早送りするために使用されるルーチンの１つと同じである。このルーチンは、ｓｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（）ルーチンが、Ｉ−フレームだけではなく、非Ｉ−フレームにもジャンプするように適応され（例えば、０．５秒から１／３０秒などの通常のリフレッシュ速度に時間粒度を削減す）るときにさらに有効である。
【０７５７】
逆方向での低速再現＜
低速再現を達成するためには、巻き戻し関数（早巻き戻し）のようであるが、（負の）再現速度が通常のプレイバック速度のおおきさより小さくなるように選ばれるｐａｕｓｅ＿ｔｉｍｅとｃｕｒｒｅｎｔ＿ｔｉｍｅ＿ｏｆｆｓｅｔの値を用いる。典型的なコード断片は以下のとおりである。
【０７５８】
ｐａｕｓｅ（）
ｐｌａｙ＿ｔｉｍｅ中のループ
ｃｕｒ＿ｐｏｓ−＝ｃｕｒｒｅｎｔ＿ｔｉｍｅ＿ｏｆｆｓｅｔ
ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
ｐａｕｓｅ＿ｔｉｍｅ中の休止
ＥｎｄＬｏｏｐ
再び、ｃｕｒｒｅｎｔ＿ｔｉｍｅ＿ｏｆｆｓｅｔパラメータとｐａｕｓｅ＿ｔｉｍｅパラメータは変えられてよく、Ｉ−フレームだけではなく、非Ｉ−フレームにもジャンプできるｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ（）ルーチンのアージョンでさらに優れた結果が達成されるだろう。
【０７５９】
複合関数
コマンドの３つの層７０１０、７０１２、７０１４（及びさらに特定すると低い方の層７０１２、７１０４）は、任意の複雑性の関数を実行する追加コマンドを構築するために使用できる。以下の例は、前述されたコマンド層（「基本コマンド」）の力を描く。
【０７６０】
例１：アクションのシーケンス：再生、次の章、休止、休止、遅送り、再生 基本関数を考慮して表され、この関数は以下のシーケンスによって実現できる。
【０７６１】
ｓｅｅｋ＿ｎｏｒｍａｌ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
ｃｕｒ＿ｐｏｓ＝ｃｈａｐｔｅｒ＿ｔａｂｌｅ［ｎｅｘｔ＿ｃｈａｐｔｅｒ］ｔｉｍｅ＿ｏｆｆｓｅｔ
ｓｅｅｋ＿ｎｏｒｍａｌ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
ｐａｕｓｅ（）
ｓｉｎｇｌｅ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
ｓｅｅｋ＿ｓｌｏｗ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
ｓｅｅｋ＿ｎｏｒｍａｌ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
例２：アクションのシーケンス：再生、早送り、休止、再生、前の章
基本関数を考慮して表され、この関数は以下のシーケンスによって実現できる。
【０７６２】
ｓｅｅｋ＿ｎｏｒｍａｌ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
ｃｕｒ＿ｐｏｓ＝ｕｓｅｒ＿ｔａｂｌｅ［ｎｅｘｔ＿ｕｓｅｒ＿ｉｎｄｅｘ］ｔｉｍｅ＿ｏｆｆｓｅｔ
ｓｅｅｋ＿ｎｏｒｍａｌ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
ｐａｕｓｅ（）
ｓｅｅｋ＿ｎｏｒｍａｌ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
ｃｕｒ＿ｐｏｓ＝ｃｈａｐｔｅｒ＿ｔａｂｌｅ［ｐｒｅｖｉｏｕｓ＿ｃｈａｐｔｅｒ］ｔｉｍｅ＿ｏｆｆｓｅｔ
ｓｅｅｋ＿ｎｏｒｍａｌ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
例３：アクションのシーケンス：再生、次の章、再生、早巻き戻し、遅送り、休止
基本関数を考慮して表され、この関数は以下のシーケンスによって実現できる。
【０７６３】
ｓｅｅｋ＿ｎｏｒｍａｌ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
ｃｕｒ＿ｐｏｓ＝ｃｈａｐｔｅｒ＿ｔａｂｌｅ［ｎｅｘｔ＿ｃｈａｐｔｅｒ］ｔｉｍｅ＿ｏｆｆｓｅｔ
ｓｅｅｋ＿ｎｏｒｍａｌ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
ｐａｕｓｅ（）
Ｌｏｏｐ  ｄｕｒｉｎｇ  ｐｌａｙ＿ｔｉｍｅ
ｃｕｒ＿ｐｏｓ−＝ｃｕｒｒｅｎｔ＿ｔｉｍｅ＿ｏｆｆｓｅｔ
ｓｅｅｋ＿ｓｉｎｇｌｅ＿ｐｌａｙ＿（ｃｕｒ＿ｐｏｓ）
ｐａｕｓｅ  ｄｕｒｉｎｇ  ｐａｕｓｅ＿ｔｉｍｅ
ＥｎｄＬｏｏｐ
ｓｅｅｋ＿ｓｌｏｗ＿ｐｌａｙ（ｃｕｒ＿ｐｏｓ）
ｐａｕｓｅ（）
前記から認められるように、コマンドセットの３つの層７０１０、７０１２、７０１４のそれぞれは高い方及び低い方のソフトウェア層に柔軟であるが簡略なインタフェースを提供し、さらに高いレベルの機能性を提供するために他のルーチンの中に容易に組み込むことができる。
【０７６４】
前述されたシステムは、再現よりむしろ記録プロセスなどの一般的な変換を制御するように適応することもできる。したがって、記録の例については、ｓｅｔ＿ｐｏｓ（）ッコマンドは、記録が起こる位置を設定し、ｓｅｔ＿ｓｐｅｅｄ（）コマンドは（いくつかの実施形態では、例えば、さらに低いフレーム速度または通常はさらに低い品質での記録を可能とするために、通常以外の記録速度に設定できる）記録速度を設定する。さらに、記録及び再現プロセスは、タイムシフト機能性を提供するために結合できる。
【０７６５】
特定の実施形態の一定の態様の簡略な要約がここに示される。
【０７６６】
データストリームまたはビットストリームは、記録されなければならない伝送の一部を表してよい。該データストリームまたはビットストリームは、複数のＥＣＭを含む。ＥＣＭは、それが汎用活用キーＫＧに同等物を使用して平文に直され、制御ワード（ＣＷ）が抽出される暗号解読段階に渡される。制御ワードは、制御ワードがローカル活用キー（ＫＬ）を使用して暗号化される暗号化段階に渡される。結果として生じる制御管理メッセージ（ＣＭＭ）は、次にヘッダ内、つまりファイルの管理データ部分での記憶のために大容量記憶装置に渡される。ビットストリームも大容量記憶装置に渡され、ファイルのコンテンツ部分に記憶される。ヘッダは、データストリームまたはビットストリーム中のタイムオフセットを、ファイル内のデータオフセットにマッピングする索引を備える索引表も含む。好ましい実施形態の追加変形においては、データストリームまたはビットストリーム、及び複数の生成されたＣＭＭは、別々のファイルに記憶される。
【０７６７】
さらに、事前に記録された大容量記憶装置フォーマットが認識され、それによりコンテンツは、デバイスの相対的に安価な読取専用部分に記憶され、制御情報は相対的に高価な読み取り／書き込み部分に記憶されるだろう―制御情報の更新性は、動的ＣＭＭを使用する他のところに記述される好ましい実施形態の変形のために必要とされる。
【０７６８】
代替実施形態がここで説明される。
【０７６９】
再び、データストリームまたはビットストリームは、記録されなければならない伝送の一部を表してよい。該データストリームまたはビットストリームは、複数のＥＣＭを含む。ＥＣＭは、それが、汎用活用キーＫＧの同等物を使用して平文に直され、制御ワード（ＣＷ）が抽出される暗号解読段階に渡される。制御ワードは、制御ワード、使用規則データ（ＵＲＭ）、及びアクセス権（ＣＭＰ＿ＥＭＭ）――後者はオプションである――が、ローカル活用キー（ＫＬ）を使用して暗号化される暗号化段階に渡される。結果として生じる制御管理メッセージ（ＣＭＭ）は、次にファイルのヘッダ、つまり管理データ部分に記憶するために大容量記憶装置に渡される。データストリームまたはビットストリームも、大容量記憶装置に渡され、ファイルのコンテンツ部分に記憶される。ヘッダは、データストリームまたはビットストリーム中のタイムオフセットを、ファイル内のデータオフセットにマッピングする索引を備える索引表も含む。好ましい実施形態の追加変形においては、ＣＭＭ及びデータストリームまたはビットストリームは、別々のファイルに記憶される。
【０７７０】
番組を記録するときに続けられる手順及びＣＭＰＳ／ＨＤＶＲインタフェースに関して生じる問題点が、ここで説明されるだろう。
【０７７１】
番組を記録するとき、ＨＤＶＲは、構造がおもに２つの部分、つまり管理データ（例えば、ｈｄｖｒ＿ｆｉｌｅ．ｍａｎａｇｅｍｅｎｔ＿ｄａｔａ）及びコンテンツ自体（例えば、ｈｄｖｒ＿ｆｉｌｅ．ｃｏｎｔｅｎｔ＿ｄａｔａ）であるファイルを作成する。
【０７７２】
ファイルの第１部分は、関連付けられる解読キー（言い換えれば制御キー）だけではなく、コンテンツの使用規則も含むＣＭＰＳによって生成、処理される（とりわけ）ローカルメッセージ（コンテンツ管理メッセージ――ＣＭＭ）に相当する。第１部分は、ビットストリーム中のタイムオフセットをファイル内のデータオフセットにマッピングする索引を備える索引表も備える。
【０７７３】
第２部分は、指定された番組（ビデオ、音声、字幕等）の多様な構成要素に対応する部分トランスポートストリーム（ｐＴＳ）から構成され、共通のスクランブルフォーマットＤＶＢ＿ＣＳで、放送として、スクランブルされたままである。好ましい実施形態の変形においては、管理データ及びコンｈｄｖｒ＿ｆｉｌｅ．ｍａｎａｇｅｍｅｎｔ＿ｄａｔａ部分も、ビットストリーム中のタイムオフセットを、ファイル内のデータオフセットにマッピングする索引を備える索引表を備える。ＨＤＶＲによって自動的に挿入されるＨＤＶＲ索引、及びユーザの命令時に挿入されるユーザ索引の２種類の索引が、索引表に含まれる。
【０７７４】
ＨＤＶＲ索引は、ビットストリーム中の定期的なタイムオフセットに対応する間隔でＨＤＶＲによって配置され、記録されたファイル内のプレイエントリ点として使用される。好ましい実施形態においては、ＨＤＶＲ索引は、番組の記録中自動的にＨＤＶＲによって作成される。
【０７７５】
ユーザサックインもプレイエントリ点であり、番組の記録の時点で、あるいは記録された番組のプレイバック中にユーザによって設定される。
【０７７６】
索引表は、適切なＣＭＭに書くＨＤＶＲ索引及びユーザ索引をマッピングするポインタも備え、記憶されたビットストリームの、ＨＤＶＲ索引及びユーザ索引によって索引付けられる点での暗号解読を可能にする。
【０７７７】
例えば、ファイル内の点、または対応するビットストリームを探索する記録されるコンテンツの処理、及び早送り、巻き戻し、及び読み飛ばしなどの「トリックモード」動作は、索引表に記憶されるＨＤＶＲ索引及びユーザ索引を利用する。
【０７７８】
前述された多様な関数の実現、及びハードウェアとソフトウェア間でのそれらの分散の詳細な説明は、実施者の選択の問題であり、詳しく説明されないだろう。しかしながら、受信機／デコーダで必要とされる動作を実行できる専用集積回路が市販されている、あるいは容易に設計でき、これらがハードウェア加速装置のための基礎として使用できる、あるいはより好ましくは、必要とされる多様な動作を実現し、それによりソフトウェアを実行するために必要とされる処理能力を削減するために専用のハードウェア加速装置を作成するために改良できることが注記される。ただし、必要とされる動作は、十分な処理能力が使用できる場合にソフトウェアで実現されてよい。
【０７７９】
モジュール及び他の構成要素は、オプションの好ましい特徴とともに、各構成要素により提供される特徴及び機能という点で説明されてきた。与えられる情報及び提供される仕様により、これらの特徴の実際の実現及び正確な詳細は実施者に委ねられる。一例に、一定のモジュールが、好ましくはＣプログラミング言語で作成され、好ましくはアプリケーションを実行するために使用されるプロセッサ上で実行するためにコンパイルされるソフトウェアで実現できるだろう。ただし、いくつかの構成要素は別のプロセッサ上で実行されてよく、いくつかのまたはすべての構成要素は専用ハードウェアにより実現されてよい。
【０７８０】
前記のモジュール及び構成要素は単に例証的であり、発明は多岐に渡る方法で実現されてよく、特に、いくつかの構成要素は、類似する機能を実行する他と結合されてよいか、あるいはいくつかは簡略化された実現では省略されてよい。機能のそれぞれのハードウェアとソフトウェアの実現は、構成要素間と単一構成要素内の両方で自由に混合されてよい。
【０７８１】
ハードウェア、コンピュータソフトウェア等により実行される機能は、電気信号と類似する信号に対して、または電気信号と類似する信号を使用して実行されることは容易に理解されるだろう。ソフトウェア実現はＲＯＭに記憶されてよいか、あるいはＦＬＡＳＨ内でパッチされてよい。
【０７８２】
本発明が、純粋に例証として説明されてきたこと、及び詳細の修正を本発明の範囲内で行うことができることが理解されるだろう。
【０７８３】
説明、及び（該当する場合には）請求項及び図面中に開示されるそれぞれの特徴は、独立して、あるいは任意の適切な組み合わせで提供されてよい。
【０７８４】
請求項に出現する参照番号は、例証としてのみであり、請求項の範囲に対する制限的な影響を有さないものとする。
【０７８５】
【発明の効果】
したがって、ビットストリームの表現を含むファイル内のそれぞれのデータオフセットを、ビットストリーム中の対応するタイムオフセットにマッピングする少なくとも１つのレコードを備えるテーブルが提供される。
【図面の簡単な説明】
【図１】図１は衛星デジタルテレビシステムの概観である。
【図２】図２はケーブルデジタルテレビシステムの概観である。
【図３】図３はハイエンドがさらに詳細に図示されている、全体的なシステム図である。
【図４】図４は受信機／デコーダの構成要素アーキテクチャの概略図である。
【図５】図５は受信機／デコーダのソフトウェアアーキテクチャの図である。
【図６】図６は図５の上半分をさらに詳細に図示する図である。
【図７】図７は図５の下半分をさらに詳細に図示する図である。
【図８】図８は図５の下半分の代替実施形態を示す図である。
【図９】図９はコンテンツ管理保護システムの概観である。
【図１０】図１０はコンテンツ管理保護システムの代替装置である。
【図１１】図１１はコンテンツ管理保護システムのソフトウェアアーキテクチャの説明図である。
【図１２】図１２は大容量記憶装置に対する暗号化されたコンテンツの記録の説明図である。
【図１３】図１３は大容量記憶装置からの暗号化されたコンテンツのプレイバックの説明図である。
【図１４】図１４は可変ビット・レートビットストリームのビットレート対時間のグラフである。
【図１５】図１５は時間の関数としてのＭＰＥＧ−２ビットストリームの概略説明図である。
【図１６】図１６は可変ビット・レートビットストリームの表現を含むファイルの、対応するビットストリームタイムオフセットとともに、データオフセットの表現である。
【図１７】図１７はビットストリーム内の点と、該ビットストリームの表現を備えるファイル内の点の間の対応を示す概略図である。
【図１８】図１８はＨＤＶＲサックインを使用するファイル内の点の探索を描く概略図である。
【図１９】図１９はビットストリーム内の周期的に間隔をあけて配置される点の間での読みとばしを備える早送り動作を描く概略図である。
【図２０】図２０はビットストリーム中の周期的に間隔をあけて配置される点の間の読み飛ばし、及びこれらの周期的に間隔をあけて配置される点に最も近い続くキーフレームの位置を突き止めることを備える、早送り動作を描く概略図である。
【図２１】図２１は選択された値を超えるビットストリームの部分を示す、可変ビット・レートビットストリームのビットレート対時間のグラフである。
【図２２】図２２は録画時のＨＤＶＲ索引点の補間の説明図である。
【図２３】図２３はＨＤＶＲ索引情報と挿入されたＥＣＭセクションの間の不一致の説明図である。
【図２４】図２４はＨｆｍｄセクションを含む、ファイルの部分の概略図である。
【図２５】図２５は好ましい実施形態でのＣＭＰＳとＨＤＶＲ間のデータの流れの概要である。
【図２６】図２６は典型的なビットストリームの構造の説明図である。
【図２７】図２７はここに説明されるような推定プロセスを示す図である。
【図２８】図２８は推定プロセスを示す追加の図である。
【図２９】図２９は推定プロセスを示すまだ追加の図である。
【図３０】図３０はビットストリームレコーディングプロセスの概略図である。
【図３１】図３１はビットストリームプレイバックプロセスの概略図である。
【図３２】図３２は高速フィルタを使用する正弦波ビットストリームのフィルタリングの説明図である。
【図３３】図３３は慣性フィルタを使用する正弦波ビットストリームのフィルタリングの説明図である。
【図３４】図３４はハイブリッドフィルタを使用する正弦波ビットストリームのフィルタリングの説明図である。
【図３５】図３５は静的フィルタを使用する正弦波ビットストリームのフィルタリングの説明図である。
【図３６】図３６はハイブリッドフィルタを使用する一定ビットレートビットストリームのフィルタリングの説明図である。
【図３７】図３７はハイブリッドフィルタを使用する三角ビットストリームのフィルタリングの説明図である。
【図３８】図３８はハイブリッドフィルタを使用する頂冠ビットストリームのフィルタリングの説明図である。
【図３９】図３９はハイブリッドフィルタを使用するビットストリーム中のピークのフィルタリングの説明図である。
【図４０】図４０はパーソナルビデオレコーダシステムの概略図である。
【図４１】図４１はパーソナルビデオレコーダシステム向けのコマンドの３層の概略図である。
【図４２】図４２は従来の早送り動作の説明図である。
【図４３】図４３は第１代替早送り動作の説明図である。
【図４４】図４４は追加の早送り動作の説明図である。
【図４５】図４５は第１巻き戻し動作の説明図である。
【図４６】図４６は追加の巻き戻し動作の説明図である。
【図４７】図４７はスロープレイ動作の説明図である。
【図４８】図４８は代替スロープレイ動作の説明図である。
【符号の説明】
２０１６／２０１８  チューナ
２０１２／２０１４  復調器
２０１０  デスクランブラ／デマルチプレクサ／リマルチプレクサ
２０２４  データデコーダ
２０２６  音声デコーダ
２０３０  ＰＣＭミキシング
２０３４  音声ＤＡＣ
２０３８  ＭＰＥＧビデオデコーダ
２０３２  グラフィックエンジン
２０４０  ＰＡＬ／ＳＥＣＯＭエンコーダ
２０５４  フロントパネル
２０３８  音声出力
２０４０  ビデオ出力
２００２  ホストＣＰＵ＋メモリ
２０７２  シリアル
２０７４  モデム
２１００  ハードディスク
２０５０  バンキングカード読取装置
２０５２  スマートカード読取装置
２０６０  バンキングカード
２０６２  スマートカード
２００４  デジタルＴＶコプロセッサ＋メモリ
２０８０  リモートコントローラ
２０８２  無線周辺装置
３１２０  アプリケーション
３１１０  アプリケーションマネージャ
３５００  仮想機械
３７００  デバイス層
３９００  システムソフトウェア／ハードウェア
３１３０  ウェブブラウザ
３１３２  番組表
３１３４  有料視聴
３１３６  バナー（パイロット）
３１３８  ホームバンキング
３１４０  ソフトウェアダウンロード
３１２０  その他
３１４２  ブート
３１４４  セットアップ
３１４６  ザッピング
３１４８  コールバック
３１１０  アプリケーションマネージャ
３３１０  基本システムパッケージ
３３２０  ＤＡＶＩＣパッケージ
３３３０  メーカ独自のパッケージ
３５１０  仮想機械
３５４０  ＳＩエンジン
３５４２  スケジューラ
３５４４  メモリマネージャ
３５４６  イベントマネージャ
３５４８  動的リンカ
３５５０  グラフィックシステム
３５５２  クラスマネージャ
３５５４  ファイルシステム
３５５６  機密保護マネージャ
３５５８  ダウンローダ
３８５２  ファイルシステムライブラリ
３６５０  カーネル
３８５０  再生＃１
３７１０  デバイスマネージャ
３７２０  条件付きアクセスデバイス
３７２２  カード読取装置デバイス
３７２４  チューナデバイス
３７２６  Ｉ／Ｏポートデバイス
３７２８  大容量記憶装置
３７３０  モデムデバイス
３７３２  ネットワークデバイス
３７３４  ビデオデバイス
３８３６  サービスデバイス
３９００  デバイスドライバ
３９１０  デバイスドライバ
３９２０  リアルタイムオペレーティングシステム
３６５０  カーネル
３６００  拡張デバイス層インタフェース
３７１０  デバイスマネージャ
３７２０  条件付きアクセスデバイス
３７２２  カード読取装置デバイス
３７２４  チューナデバイス
３７２６  Ｉ／Ｏポートデバイス
３７２８  大容量記憶装置
３７３０  モデムデバイス
３７３２  ネットワークデバイス
３７３４  ビデオデバイス
３７３６  サービスデバイス
３６５０  カーネル
３８００  抽象デバイスインタフェース
３９１０  デバイスドライバ
３９２０  リアルタイムオペレーティングシステム
【図１】
0004257084.tif 000018
【図２】
0004257084.tif 000019
【図３】
0004257084.tif 000020
【図４】
0004257084.tif 000021
【図５】
0004257084.tif 000022
【図６】
0004257084.tif 000023
【図７】
0004257084.tif 000024
【図８】
0004257084.tif 000025
【図９】
0004257084.tif 000026
【図１０】
0004257084.tif 000027
【図１１】
0004257084.tif 000028
【図１２】
0004257084.tif 000029
【図１３】
0004257084.tif 000030
【図１４】
0004257084.tif 000031
【図１５】
0004257084.tif 000032
【図１６】
0004257084.tif 000033
【図１７】
0004257084.tif 000034
【図１８】
0004257084.tif 000035
【図１９】
0004257084.tif 000036
【図２０】
0004257084.tif 000037
【図２１】
0004257084.tif 000038
【図２２】
0004257084.tif 000039
【図２３】
0004257084.tif 000040
【図２４】
0004257084.tif 000041
【図２５】
0004257084.tif 000042
【図２６】
0004257084.tif 000043
【図２７】
0004257084.tif 000044
【図２８】
0004257084.tif 000045
【図２９】
0004257084.tif 000046
【図３０】
0004257084.tif 000047
【図３１】
0004257084.tif 000048
【図３２】
0004257084.tif 000049
【図３３】
0004257084.tif 000050
【図３４】
0004257084.tif 000051
【図３５】
0004257084.tif 000052
【図３６】
0004257084.tif 000053
【図３７】
0004257084.tif 000054
【図３８】
0004257084.tif 000055
【図３９】
0004257084.tif 000056
【図４０】
0004257084.tif 000057
【図４１】
0004257084.tif 000058
【図４２】
0004257084.tif 000059
【図４３】
0004257084.tif 000060
【図４４】
0004257084.tif 000061
【図４５】
0004257084.tif 000062
【図４６】
0004257084.tif 000063
【図４７】
0004257084.tif 000064
【図４８】
0004257084.tif 000065