(57)【要約】  暗号化されたデータ・ストリームと対応する解読用データの供給を適切に調整すること。本発明は、その中で暗号化されたデータ・ストリームの各要素を解読するために暗号化されたメッセージが供給され、かつ各解読メッセージは多数の解読要素から構成されており、かつ解読用メッセージあたりの解読要素の数を検出するための検出ユニットと、検出された数に基づいてセグメントのシーケンスに関連する解読用メッセージを供給する位置を決定するための決定ユニットとを備えることを特徴とする、暗号化されたデータ・ストリームを処理するための装置に関する。
2008539640.tif 000002
【特許請求の範囲】
【請求項１】
暗号化されたデータ・ストリームを処理するための装置であって、解読用メッセージが、暗号化された前記データ・ストリームの各セグメントを解読するために提供され、かつ各解読用メッセージが、多数の解読要素から構成されていて、かつ前記装置は、解読用メッセージあたりの解読要素の数を検出するための検出ユニットと、前記検出された数に基づき、セグメントのシーケンスに関連して解読メッセージを提供するための位置を決定する決定ユニットとを備えることを特徴とする、前記データ・ストリーム処理装置。
【請求項２】
前記解読用メッセージが、資格制御メッセージ(Entitlement Control Message)であり、前記解読要素が制御ワード(Control Word)である、請求項１に記載の装置。
【請求項３】
特定のセグメントに対応する解読用メッセージが、特定のセグメントに先行して提供される、請求項１に記載の装置。
【請求項４】
解読メッセージあたりの解読要素の前記検出された数が２である場合は、前記決定ユニットが、解読メッセージを提供するために対応するセグメントに直接先行して提供するように構成されている、請求項１に記載の装置。
【請求項５】
解読メッセージあたりの解読要素の前記検出された数が１である場合は、前記決定ユニットが、1セグメント先行して解読メッセージを提供するように構成されている、請求項１に記載の装置。
【請求項６】
別のファイルに前記解読用メッセージを保存するように構成されたストレージ・ユニットを備えた、請求項１に記載の装置。
【請求項７】
前記ファイルが、対応する前期セグメントに対する前記解読用メッセージの各々の役割を示す、請求項６に記載の装置。
【請求項８】
解読用メッセージに割り当てられた2つの解読要素を保存するための2つのレジスタを備え、かつ、同時に、前記2つのレジスタのうちの1つだけがそこに保存されているデータを上書きすることができる、請求項４に記載の装置。
【請求項９】
解読要素を保存するための2つのレジスタを備え、かつ、同時に、前記2つのレジスタのうちの1つだけがそこに保存されているデータを上書きすることができる、請求項５に記載の装置。
【請求項１０】
暗号化された前記データ・ストリームから最初に提供された解読用メッセージを取り除くように構成されている制御ユニットを備えた、請求項１に記載の装置。
【請求項１１】
ビデオ・データまたはオーディオ・データの暗号化されたデータ・ストリームを処理するように構成されている、請求項１に記載の装置。
【請求項１２】
デジタル・データの暗号化されたデータ・ストリームを処理するように構成されている、請求項１に記載の装置。
【請求項１３】
解読された前記データ・ストリームを再生するための再生ユニットを備えた、請求項１に記載の装置。
【請求項１４】
トリックプレー再生モードでの再生のために前記データ・ストリームを処理する生成ユニットを備えた、請求項１に記載の装置。
【請求項１５】
前記トリックプレー再生モードが、高速前方再生モード、高速後方再生モード、スローモーション再生モード、フリーズフレーム再生モード、インスタント・リプレイ再生モード、および逆方向再生モードから構成される前記グループの1つである、請求項１４に記載の装置。
【請求項１６】
暗号化されたMPEG2データ・ストリームを処理するように構成されている、請求項１に記載の装置。
【請求項１７】
デジタル・ビデオ録画装置、ネットワーク対応装置、条件付きアクセス・システム、ポータブル・オーディオ・プレーヤ、ポータブル・ビデオ・プレーヤ、携帯電話機、DVDプレーヤ、CDプレーヤ、ハードディスク・ベースのメディア・プレーヤ、インターネット・ラジオ・デバイス、パブリック・エンタテイメント装置、およびMP3プレーヤ等から構成されるグループの少なくとも1つとして実現されている、請求項１に記載の装置。
【請求項１８】
暗号化されたデータ・ストリームを処理する方法であって、暗号化された前記データ・ストリームの各セグメントを解読するために、暗号化された解読用メッセージが提供され、かつ各解読用メッセージは多数の解読要素を備えており、かつ前記方法は、解読用メッセージあたりの解読要素の数を検出する手順と、前記検出された数に基づいて前記セグメントの前記シーケンスに関連して前記解読用メッセージを提供するための位置を決定する手順とを備えた、暗号化されたデータ・ストリームの処理方法。
【請求項１９】
その中で暗号化されたデータ・ストリームを処理するコンピュータ・プログラムが実行される、コンピュータで読み出し可能なメディアであって、かつ、前記暗号化されたデータ・ストリームの各セグメントを解読するために解読メッセージが提供され、かつ多数の解読要素から構成される各解読メッセージが保存されていて、コンピュータ・プログラムがプロセッサによって実行される時、以下の手順、すなわち、解読用メッセージあたりの解読要素の数を検出する手順と、前記検出された数に基づいて前記セグメントの前記シーケンスに関連して前記解読用メッセージを提供するための位置を決定する手順とを制御または実行するように構成されている、コンピュータで読み出し可能なメディア。
【請求項２０】
暗号化されたデータ・ストリームを処理するプログラム要素であって、かつ暗号化されたデータ・ストリームの各セグメントを解読するために解読メッセージが提供され、かつ各解読メッセージは多数の解読要素から構成されていて、プログラム要素がプロセッサによって実行される時、以下の手順、すなわち、解読用メッセージあたりの解読要素の数を検出する手順と、前記検出された数に基づいて前記セグメントの前記シーケンスに関連して前記解読用メッセージを提供するための位置を決定する手順とを制御または実行ように構成されている、暗号化されたデータ・ストリームを処理するプログラム要素。
【請求項２１】
暗号化されたデータ・ストリームを処理する装置であって、かつ前記暗号化されたデータ・ストリームの各セグメントを解読するために解読用メッセージが提供され、かつ、前記装置は、トリックプレー再生モードから通常プレー再生モードへの切り替えを検出する検出ユニットと、トリックプレー再生モードから通常プレー再生モードへの切り替え時に再生の過度な中断を避けるために解読メッセージを処理する方法を決定する決定ユニットとを備えた、暗号化されたデータ・ストリームの処理装置。
【請求項２２】
前記決定ユニットが、前記トリックプレー再生モードの前の最後の解読用メッセージと、前記通常プレー再生モードにおける最初の解読用メッセージとに基づいて前記通常プレー再生モードでの最初の解読用メッセージが変更されるべきか否かを決定するように構成されている、請求項２１に記載の装置。
【請求項２３】
前記決定ユニットが、前記トリックプレー再生モードの前の最後の解読用メッセージと、前記通常プレー再生モードにおける最初の解読用メッセージとの比較結果に基づいて、前記通常プレー再生モードでの最初の解読用メッセージが変更されるべきか否かを決定するように構成されている、請求項２１に記載の装置。
【請求項２４】
前記決定ユニットが、予め決められていた閾値時間を超えても解読用メッセージが前記データ・ストリーム内に存在しなかった場合に、前記通常プレー再生モードで最初に遭遇した解読用メッセージが解読用メッセージ・プロセッサに送られるべきであることを決定するように構成されている、請求項２１に記載の装置。
【請求項２５】
前記決定ユニットが、前記トリックプレー再生モードの前の最後の解読用メッセージと前記通常プレー再生モードにおける最初の解読用メッセージが、同じ解読用メッセージ・タイプに関係するという比較結果が得られた時に、前記通常プレー再生モードでの最初の解読用メッセージが変更されるべきであると決定するように構成されている、請求項２３に記載の装置。
【請求項２６】
前記決定ユニットが、前記トリックプレー再生モードから前記通常プレー再生モードへの切り替えが検出された時に、トリックプレー再生モードにおいてデータ・ストリームの最後に、前記通常プレー再生モードにおける最初の解読用メッセージのコピーであるが、記憶されたタイプとは反対の解読用メッセージ・タイプを持つ最後の解読用メッセージを追加するように構成されている、請求項２１に記載の装置。
【請求項２７】
前記決定ユニットが、前記トリックプレー再生モードにおけるデータ・ストリーム内に少なくとも1つの解読用メッセージを追加するように構成されている、請求項２１に記載の装置。
【請求項２８】
前記決定ユニットが、前記トリックプレー再生モードにおけるデータ・ストリーム内の、独創的に暗号化された、イントラ・コーデッド・フレームから解読用メッセージをコピーするように構成されている、請求項２７に記載の装置。
【請求項２９】
前記決定ユニットが、前記トリックプレー再生モードにおけるデータ・ストリーム内に、前記トリックプレー再生モード内のデータ・ストリームを発生させるために使用される解読用メッセージを挿入するように構成されている、請求項２７の前記装置。
【請求項３０】
ビデオ・データまたはオーディオ・データの暗号化されたデータ・ストリームを処理するように構成されている、請求項２１に記載の装置。
【請求項３１】
デジタル・データの暗号化されたデータ・ストリームを処理するように構成されている、請求項２１に記載の装置。
【請求項３２】
前記解読されたデータ・ストリームを再生するための再生ユニットを備える、請求項２１に記載の装置。
【請求項３３】
前記トリックプレー再生モードが、高速前方再生モード、高速後方再生モード、スローモーション再生モード、フリーズフレーム再生モード、インスタント・リプレイ再生モード、および逆方向再生モードから構成されるグループの1つである、請求項２１に記載の装置。
【請求項３４】
暗号化されたMPEG2データ・ストリームを処理するように構成されている、請求項２１に記載の装置。
【請求項３５】
デジタル・ビデオ録画装置、ネットワーク対応装置、条件付きアクセス・システム、ポータブル・オーディオ・プレーヤ、ポータブル・ビデオ・プレーヤ、携帯電話機、DVDプレーヤ、CDプレーヤ、ハードディスク・ベースのメディア・プレーヤ、インターネット・ラジオ・デバイス、パブリック・エンタテイメント装置、およびMP3プレーヤから構成されるグループの少なくとも1つとして実現されている、請求項２１に記載の装置。
【請求項３６】
暗号化されたデータ・ストリームを処理する方法であって、かつ前記暗号化されたデータ・ストリームの各セグメントを解読するために解読用メッセージが提供され、かつ、前記方法は、トリックプレー再生モードから通常プレー再生モードへの切り替えを検出する手順と、トリックプレー再生モードから通常プレー再生モードへの切り替え時に再生の過度な中断を避けるために前記解読メッセージを処理する方法を決定する手順とを備えた、暗号化されたデータ・ストリームの処理方法。
【請求項３７】
その中で暗号化されたデータ・ストリームを処理するコンピュータ・プログラムが実行される、コンピュータで読み出し可能なメディアであって、かつ、前記暗号化されたデータ・ストリームの各セグメントを解読するために解読メッセージが提供され、かつ暗号化されたデータ・ストリームが保存されていて、コンピュータ・プログラムがプロセッサによって実行される時、以下の手順、すなわち、前記トリックプレー再生モードから通常プレー再生モードへの切り替えを検出する手順と、トリックプレー再生モードから前記通常プレー再生モードへの切り替え時に再生の過度な中断を避けるために前記解読メッセージを処理する方法を決定する手順とを制御または実行するように構成されている、コンピュータで読み出し可能なメディア。
【請求項３８】
暗号化されたデータ・ストリームを処理するプログラム要素であって、かつ前記暗号化されたデータ・ストリームの各セグメントを解読するために解読メッセージが提供され、プログラム要素が、プロセッサによって実行される時、以下の手順、すなわち、トリックプレー再生モードから通常プレー再生モードへの切り替えを検出する手順と、前記トリックプレー再生モードから前記通常プレー再生モードへの切り替え時に再生の過度な中断を避けるために前記解読メッセージを処理する方法を決定する手順とを制御または実行するように構成されている、暗号化されたデータ・ストリームを処理するプログラム要素。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、暗号化されたデータ・ストリームを処理するための装置に関する。また、本発明は、暗号化されたデータ・ストリームを処理する方法に関する。さらに、本発明は、プログラム要素に関する。さらにまた、本発明は、コンピュータで読み出しが可能なメディアにに関する。
【背景技術】
【０００２】
電子エンタテイメント装置は、ますますその重要性を高めている。特に、ハードディスク・ベースのオーディオ/ビデオ・プレーヤやその他のエンタテイメント機器を購入するユーザーが増えて来ている。
【０００３】
オーディオ/ビデオ・プレーヤの分野ではストレージ・スペースの削減が重要な課題であるため、オーディオおよびビデオ・データは圧縮して保存されたり、セキュリティ上の理由から暗号化されて保存されるケースが増えている。
【０００４】
MPEG2は、動画や関連するオーディオ・データを符号化するための標準規格の1つであり、GOP ("Group Of Pictures")構造と呼ばれる特殊な順番で配列されるフレームデータからビデオ・ストリームを生成するプログラムである。MPEG2ビデオ・ビットストリームは、画像を符号化した一連のデータ・フレームから構成される。画像の符号化方式には3つの方法がある。すなわち、イントラ・コーデッド符号化(I画像)、前方予測符号化(P画像)、および双方向予測符号化(B画像)の3つである。イントラ・コーデッド・フレーム (Iフレーム)は個々の画像に関連し、それに対応するデータを含んでいる。前方予測フレーム(Pフレーム)は先行するIフレームまたはPフレームの情報を必要とする。双方向予測フレーム(Bフレーム)は先行のまたは後続のIフレームまたはPフレームの情報に依存する。
【０００５】
メディア再生装置において、メディア・コンテントが通常の速度で再生される通常再生モードから、メディア・コンテントが通常の速度ではない速度で再生される、たとえば速度を上げて（早送り再生）再生されるトリックプレー再生モードに切り替える機能は興味深い機能である。
【０００６】
WO03/107666A1は、ストリームの連続したセグメントを解読するために必要な制御ワード(Control Word)が供給される、暗号化されたデータ・ストリーム上のトリックプレーを開示している。
【０００７】
メディア・コンテント・プロバイダが異なれば、ビデオ・コンテントの暗号化ために使用するフォーマットや、暗号化されたビデオ・コンテントを解読するために必要な解読用データのフォーマットが異なる可能性がある。従って、暗号化されたビデオ・コンテントのセグメントを提供すること、および暗号化された解読データを提供し、解読することの調整、特に通常再生とトリックプレーとの間の遷移時の調整は難しい可能性がある。
【特許文献１】WO03/107666 A1
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明の目的は、暗号化されたデータ・ストリームと対応する解読用データの供給を適切に調整することである。
【課題を解決するための手段】
【０００９】
上記の目的を達成するために、本発明では、暗号化されたデータ・ストリームを処理する装置、暗号化されたデータ・ストリームを処理する方法、プログラム要素、およびコンピュータで読み出すことができるメディアが、それぞれ独立した請求項により提供される。
【発明を実施するための最良の形態】
【００１０】
以下、実施例を参照しながら本発明の詳細な説明を行うが、本発明は必ずしもこの実施例に限定されることはない。
【実施例１】
【００１１】
本発明の典型的な実施例によれば、暗号化されたデータ・ストリームを処理する装置であって、かつ、前記暗号化されたデータ・ストリームの各セグメントを解読するために解読用メッセージが提供され、かつ、各解読用メッセージは多数の解読要素を備えており、かつ、前記装置は、解読用メッセージあたりの解読要素の数を検出する検出ユニットと、検出された数に基づいてセグメントのシーケンスに関連して解読用メッセージを供給する位置を決定する決定ユニットとを備えた、暗号化されたデータ・ストリームの処理装置が提供される。
【００１２】
本発明の別の典型的な実施例によれば、暗号化されたデータ・ストリームを処理する方法であって、かつ、暗号化されたデータ・ストリームの各セグメントを解読するために、解読用メッセージが提供され、かつ、各解読用メッセージは多数の解読要素を備えており、かつ、前記方法は、解読用メッセージあたりの解読要素の数を検出する手順と、検出された数に基づいてセグメントのシーケンスに関連して解読用メッセージを提供する位置を決定する手順とを備えた、暗号化されたデータ・ストリームの処理方法が提供される。
【００１３】
本発明のさらに別の典型的な実施例によれば、暗号化されたデータ・ストリームを処理する装置であって、かつ前記暗号化されたデータ・ストリームの各セグメントを解読するために解読用メッセージが提供され、かつ、前記装置は、トリックプレー再生モードから通常プレー再生モードへの切り替えを検出する検出ユニットと、トリックプレー再生モードから通常プレー再生モードへの切り替え時に再生の過度な中断を避けるために解読メッセージを処理する方法を決定する決定ユニットとを備えた、暗号化されたデータ・ストリームの処理装置が提供される。
【００１４】
さらに、本発明のまた別の典型的な実施例によれば、暗号化されたデータ・ストリームを処理する方法であって、かつ前記暗号化されたデータ・ストリームの各セグメントを解読するために解読用メッセージが提供され、かつ、前記方法は、トリックプレー再生モードから通常プレー再生モードへの切り替えを検出する手順と、トリックプレー再生モードから通常プレー再生モードへの切り替え時に再生の過度な中断を避けるために前記解読メッセージを処理する方法を決定する手順とを備えた、暗号化されたデータ・ストリームの処理方法が提供される。
【００１５】
さらに、本発明の別の典型的な実施例によれば、その中にコンピュータ・プログラムが保存され、このコンピュータ・プログラムはプロセッサによって実行される時、
上述の方法のいずれかを制御または実行するように構成されている、コンピュータで読み出し可能なメディアが提供される。
【００１６】
さらに、本発明のまた別の典型的な実施例によれば、プログラム要素がプロセッサによって実行される時、上述の方法のいずれかを制御または実行するように構成されている、プログラム要素が提供される。
【００１７】
本発明によるデータ処理は、コンピュータ・プログラム、すなわちソフトウェアによって、または、１つまたはそれ以上の特別な電子的最適化回路、すなわちハードウェアによって、または、ハイブリッド形式、すなわちソフトウェア要素とハードウェア要素の組み合わせによって実現することができる。
【００１８】
本発明の特徴は、特に暗号化されたコンテント、および暗号化されたコンテントを解読するために必要な対応する解読用データ（任意に暗号化されることもある）が、解読用メッセージ、特に資格制御メッセージ(Entitlement Control Message:ECM)の巧みな管理と取り扱いとによって適切に同期化することができるという利点があることである。データ・ストリームに特別な解読用メッセージを挿入または供給するのに適切な位置または時間を選ぶことにより、解読用メッセージおよび／または暗号化されたデータ・ストリームを解読するための十分かつ正しい情報が必要な時間内に提供されることが保証される。特に、解読用メッセージ（たとえばECM）に含まれる解読要素の数（たとえば制御ワード(Control Words)）は同期性を良くするための重要な情報を含むことがある。この方法をとることにより、解読データはかなり早期に提供されるようになり、どの再生モードでも（たとえば通常プレー再生モードまたはトリックプレー再生モード）データ・ストリームの再生を長時間の再生中断を生ずることなく連続的に実行できることが保証されるようになる。特に、トリックプレーから通常プレーへの移行時には、データ・ストリームと一緒に提供される解読情報を適切に抽出し、選択し、および／または処理し、遷移領域における解読の中断時間をなくすか最小化するために正確かつタイムリーな解読を可能とすることは重要な利点である。
【００１９】
本発明の1つの局面によれば、解読用メッセージ（たとえばECM）に含まれる解読要素の数（たとえば制御ワード(Control Words)）を、解読用メッセージの供給タイミングをコントロールするための基準として使用することができる。この場合、この検出された数は、データ・ストリームを形成している一連のセグメントのどの位置に解読用メッセージを挿入すべきかを決定するための基本情報として使用される。解読用メッセージあたりの解読要素の数、たとえば1または2、に基づいて、対応する解読用メッセージを先行して、または先行せずに、たとえば1セグメント先行して、または0セグメント先行して、提供することが適切であることがある。この位置を適切に選ぶことにより、コンテント・データおよび解読データを提供する際の同期を改善する、または最適化することが可能となる。
【００２０】
従って、本発明の典型的な実施例によれば、資格制御メッセージ(Entitlement Control Message)を処理する方法、特に高速前方再生モード（トリックプレー再生モードの1つの例として）で処理する方法が提供される。そのような高速前方トリックプレー再生モードの場合、ECMと制御ワードCWはそれぞれ、ある期間内のCWの量に依存して（たとえば1つまたは2つ）、特別の期間先行して（特に現在の期間、または1期間先行して）提供される。また、ECMを（一時的に）バッファする、および／またはファイルする、および／または（永久的に）保存することも可能である。
【００２１】
トリックプレー・ストリームを作成するには、データ・ブロックを解読器に供給するのが適切であろう。そのような解読器はデータ・ブロックを解読するために、暗号化のプロセスで用いられた制御ワードCWを必要とする。これらの制御ワードCWも暗号化し、資格制御メッセージECM内に保存することができる。トリックプレー再生モードの再生速度には、解読用メッセージ解読器（たとえばスマートカード）の処理能力の上限から決められる絶対的な上限が存在する。通常再生モードの場合、制御ワードCWの寿命は10秒程度であり、トリックプレー再生モードではトリックプレー再生速度で圧縮される。
【００２２】
本発明の一実施例によれば、暗号化されたビデオ・ストリームのトリックプレー・ストリームを生成する方法が提供される。ビデオ・データ・ストリームの連続したセグメントを解読するためには、少なくとも1つの制御ワードCWが必要であり、この制御ワードは資格制御メッセージECMに含まれて供給され、この資格制御メッセージECMは解読されるべきビデオ・データ・ストリーム連続したセグメントに先行して供給される。この方法は、ECMあたり1つか、またはそれ以上の制御ワードCWを検出する手順から成っている。続いて、解読のために、資格制御メッセージECMが制御ワードCWを2つ持っている場合は現在の資格制御メッセージECMが提供され、資格制御メッセージECMが制御ワードCWを1つしか持っていない場合は1期間先行して資格制御メッセージECMが提供される。任意ではあるが、元々提供されている資格制御メッセージECMは暗号化されたビデオ・データ・ストリームから除去することができる。結果として、トリックプレー再生モード、特に高速前方トリックプレー再生モードが改善され、正しい実行が可能となる。
【００２３】
ECMが、トリックプレー再生のために適切な瞬間に利用可能となるために、ECMを別のファイルに保存しておくことができる。このファイルの中で、ECMがどの期間に属するべきかを指示することが可能である。
【００２４】
本発明によるシステムの典型的な応用分野として、デジタル・ビデオ録画装置（ハードディスク複合体、DVD+RW等）、ネットワーク対応装置、あるいは条件付きアクセス・システム等が挙げられる。
【００２５】
本発明の典型的な実施例によるシステムは、特別なECMの事前注意に対応している。これらの事前注意が、多くの場合、高速トリックプレー再生において利点となることが判明している。この件に関連した改善のための考察から、そのような事前注意の改善がトリックプレー、特に高速前方トリックプレー再生を正しく実行するために適切であることが示されている。
【００２６】
本発明の別の局面によれば、トリックプレー再生モードから通常再生モードへの移行時の、解読用メッセージと再生されるべきコンテントとの適切な同期は、これら2つの再生モード間の切り替えを検出することによって達成することができる。そのような切り替えが生じた時、決定ユニットが、解読用メッセージを適切に解析し、それらの提供をコントロールし、および／または適切な解読用メッセージを選択することによって切り替えに伴う再生の中断をなくすか、少なくとも大幅に短縮することを保証する。特に、トリックプレー再生モードのスタート前に送られた最後の解読用メッセージと、トリックプレー再生モードの終了後に送られた最初の解読用メッセージが解析されか、またはこれに関連して比較される。特に、開始された通常再生モードにおいて最初の解読用メッセージの抽出または処理が必要であるか否かが決定される。このようにして、トリックプレー再生モードから通常再生モードへの移行の品質が改善され、切り替えに伴う好ましくない影響が抑圧される。従って、平文のトリックプレー・ストリームから暗号化された通常プレー・ストリームへの切り替え時に、正しい解読動作が可能な限り速やかに開始されることが保証される。言い換えれば、必要かつ正しいECMが、切り替え後、可能な限り速やかに解読される。
【００２７】
従属請求項を参照しながら、以下、本発明の別の典型的な実施例について説明しよう。
【００２８】
次に、解読用メッセージあたりの解読用要素の数を検出する、暗号化されたデータ・ストリームを処理する装置の典型的な実施例について説明する。これらの実施例もまた暗号化されたデータ・ストリームを処理する方法、コンピュータで読み出し可能なメディア、およびプログラム要素のために適用可能である。
【００２９】
解読用メッセージは、資格制御メッセージ(Entitlement Control Message)であることもあり、解読用要素は制御ワード(Control Words)であることもある。従って、そのような装置は、MPEG2ビデオ・データ処理装置として実現することが可能である。
【００３０】
本発明の別の典型的な実施例によれば、特定のセグメントに対応する解読用メッセージが、特定のセグメントに先行して提供される。特定のセグメントの開始前の丁度良いタイミングで解読用メッセージを提供することにより、コンテント・データの対応するセグメントが再生される前に解読用メッセージ自体が解読されることが保証される。そのような再生は、解読された解読用メッセージを用いて対応するセグメント（の一部）の解読を完了することを要求する。
【００３１】
この装置の決定ユニットは、解読用メッセージあたりの解読要素の数が2である場合、解読用メッセージをゼロ・セグメント先行して提供するように構成される。言い換えれば、解読用メッセージは、対応するセグメントに基本的には直接先行して提供される。従って、データ・ストリームの対応する期間に対するECMの中に2つのCWが提供される時、ECMは前もって距離をおいて送られる必要がない。たとえば、特定のセグメントまたは期間に対して、この期間およびそれに続く期間のために共通の解読用メッセージの中で解読要素を提供することが可能である。次の期間では、この期間のための解読要素が再び提供され、これに加えて次の期間のための対応する解読要素が提供される。この仕組みにより、異なった期間に関連するデータを再生する時に長時間の中断を避けることができるように、必要な時間内にすべての解読要素(制御ワード)を提供することが可能となる。
【００３２】
しかし、解読用メッセージあたりの解読要素の検出された数が1である場合は、装置の決定ユニットは1セグメント先行して解読用メッセージを提供するように構成される。これによりコンテントと解読データとの適切な同期が保証される。
【００３３】
この装置はさらに、別のファイルに解読用メッセージを保存するように構成されたストレージ・ユニットを備えることができる。このファイルは対応するセグメントに対する解読用メッセージの割り当てを指示することができる。対応するセグメントに割り当てられた解読用メッセージを別のファイルに保存することにより、解読データを必要な時に保管したり、取り出したりすることが容易に可能である。
【００３４】
特に、単一の解読用メッセージの2つの解読要素を保存するために2つのレジスタが提供され、かつ、この2つのレジスタのうち1つだけが同時にそこに保存されているデータを上書きすることができる。言い換えれば、解読器は2つのタイプの解読要素が定義されるように、2つのレジスタ、1つは「奇数(odd)」の、他の１つは「偶数(even)」の解読要素を保存するレジスタを含んでいる。「奇数(odd)」と「偶数(even)」はストリーム内の2つの連続した解読要素を区別するための表現法である。2つのレジスタのうち1つが偶数番目の解読要素を、他の1つが奇数番目の解読要素を保存する。解読の後、解読要素は解読器内の対応するレジスタに書き込まれ、それまでに保存されていた値は上書きされる。但し、新しい数値で書き変えられるのは現在活性化されていないレジスタのみである。
【００３５】
この装置は、特にまだ必要なレジスタ内の解読要素が上書きされるのを防ぐために、暗号化されたデータ・ストリームから最初に提供された解読用メッセージを除去するように構成された制御ユニットを備えることもできる。この装置は、ビデオまたはオーディオ・データの暗号化されたデータ・ストリームを処理するように構成されることも可能である。しかし、そのようなメディア・コンテントは、本発明による構成で処理される唯一のデータ・タイプではない。トリックプレー再生および類似のアプリケーションは、ビデオ処理と（純粋な）オーディオ処理の両方にとって問題となる可能性がある。
【００３６】
この装置はさらに、デジタル・データの暗号化されたデータ・ストリームを処理するように構成することも可能である。
【００３７】
さらに、この装置は解読されたデータ・ストリームを再生するための再生ユニットを備えることも可能である。そのような再生ユニットは、オーディオ・データとビジュアル・データの両方を人間が認識できるような形で再生するためのスピーカー、またはイヤホン、および／または視覚的表示装置を備える。
【００３８】
この装置はさらに、トリックプレー再生モードで再生するために解読されたデータ・ストリームを処理するための生成ユニットを備えることも可能である。トリックプレー再生モードで再生するためにデータ・ストリームを生成するように構成された、そのようなトリックプレー生成ユニットは、たとえば装置のボタン、キーパッド、またはリモコン等のユーザー・インタフェースで対応するオプションを選択することによって調整することができる。ユーザーによって選択されるトリックプレー再生モードは、高速前方再生モード、高速後方再生モード、スローモーション再生モード、フリーズフレーム再生モード、インスタント・リプレイ再生モード、および逆方向再生モードから成るグループの中の1つである。トリックプレーの場合、出力のために使用されるのは（たとえば、ビジュアル表示、および／または音響出力として）連続したデータの一部のみである。表示可能な信号を生成するための他のデータ(Iフレーム)とは独立に、データ・ストリーム内のすべてのデータ（Pフレーム、Bフレーム）が使用できる訳ではないため、独立で使用可能なデータ(Iフレーム)の情報が重要になる。
【００３９】
本発明によるこの装置は、暗号化されたMPEG2データ・ストリームを処置するように構成することができる。MPEG2はMPEG (Moving Pictures Experts Group)によって合意されたオーディオおよびビデオの符号化規格のグループの名称であり、ISO/IEC 13818国際標準として公開されている。たとえば、MPEG2はデジタル衛星TVおよびケーブルTVを始めとした放送用オーディオおよびビデオ信号を符号化するために用いられているだけでなく、DVD録画用としても使用されている。
【００４０】
本発明によるこの装置は、デジタル・ビデオ録画装置、ネットワーク対応装置、条件付きアクセス・システム、ポータブル・オーディオ・プレーヤ、ポータブル・ビデオ・プレーヤ、携帯電話機、DVDプレーヤ、CDプレーヤ、ハードディスク・ベースのメディア・プレーヤ、インターネット・ラジオ・デバイス、パブリック・エンタテイメント装置、およびMP3プレーヤ等から構成されるグループの少なくとも1つとして実現することができるが、これらのアプリケーションは典型的な実現例に過ぎない。
【００４１】
次に、トリックプレー再生モードから通常プレー再生モードへの切り替えの検出に基づいて暗号化されたデータ・ストリームを処理するための装置の典型的な実施例について説明する。これらの実施例は、暗号化されたデータ・ストリームを処理する方法、コンピュータで読み出し可能なメディア、およびプログラム要素等に適用することができる。
【００４２】
この装置においては、トリックプレー再生モードの前の最後の解読用メッセージと、通常再生モードの最初の解読用メッセージとに基づいて、通常再生モードにおける最初の解読用メッセージが変更されるべきか否かを決定するために決定ユニットが使用される。トリックプレー再生モードの前の最後の解読用メッセージと、トリックプレー再生モードの最初の解読用メッセージの組み合わせが、長時間の再生中断を伴わない適切な処理を保証するために、これらの解読用メッセージがどの方法で使用されるべきかを確実に決定するために必要な情報を含んでいる。特別な場合に、この解析は、そこに含まれている解読要素がトリックプレーと通常プレーとの間の時間的ギャップを短縮するために確実に使用されるように、通常再生モードで最初の解読用メッセージが変更されるべきか否かという疑問に導かれることがある。
【００４３】
より特別な場合には、この決定ユニットはトリックプレー再生モードの前の最後の解読用メッセージと、トリックプレー再生モードの最初の解読用メッセージとの比較結果に基づいて、通常プレー再生モードでの最初の解読用メッセージが変更されるべきか否かを決定するように構成することができる。そのような比較結果、特に解読用メッセージのタイプの比較によって、トリックプレー再生モードから通常再生モードへの移行の品質が改善される。トリックプレー再生モードの前の最後の解読用メッセージと、トリックプレー再生モードの最初の解読用メッセージとの比較結果によって、再生モードの切り替えが生じた時の再生中断の時間を見積もることができる。適切な対策をとることにより、この再生中断期間を短縮することが可能である。通常再生モードでの最初の解読用メッセージを処理する（特にそれを解読し、使用する）必要性の有無が、そのような再生中断時間を短縮するか、またはなくするために使用される。
【００４４】
この決定ユニットは、予め決められていた時間間隔の閾値（たとえば数秒）を超えても解読用メッセージが前記データ・ストリーム内に存在しなかった場合に、システムが、通常プレー再生モードの最初の解読用メッセージが解読用メッセージ・プロセッサに送られる動作状態に入れられることを決定するように構成することができる。言い換えれば、特にトリックプレーから通常プレーへの過度な切り替えを避けるために、ECMにタイムアウト機能を導入することができる。
【００４５】
さらに、別の方法として、この決定ユニットは、トリックプレー再生モードの前の最後の解読用メッセージと通常プレー再生モード（トリックプレー再生モードの後の）における最初の解読用メッセージの解読用メッセージ・タイプが同じであるという結果が得られた時に、前記通常プレー再生モードでの最初の解読用メッセージが変更されるべきであると決定するように構成することができる。この実施例によれば、システムは通常プレー・ストリームの最初のECMを使用するように強制される。通常プレーへの切り替えが発生した時、記憶されているトリックプレーへの切り替え前の最後のECMのタイプが通常プレー・ストリームにおける最初のECMのタイプと比較される。それらが同じであった場合、通常プレー・ストリームにおける最初のECMのタイプは、このECMがスマートカードで処理されることが保証される方法で訂正される。
【００４６】
さらに、また別の方法として、この決定ユニットは、前記トリックプレー再生モードから前記通常プレー再生モードへの切り替えが検出された時に、トリックプレー再生モードにおいてデータ・ストリームの最後に、前記通常プレー再生モードにおける最初の解読用メッセージのコピーであるが、記憶されたタイプとは反対の解読用メッセージ・タイプを持つ最後の解読用メッセージを追加するように構成することができる。この実施例によれば、切り替えコマンドを受け取った瞬間にトリックプレー・ストリームの最後にECMが追加される。このECMファイルから、通常プレーの最初のECMが何であるかを知ることができる。次に、このECMは、特に記憶されていたタイプとは反対のタイプを持つECMが、トリックプレー・ストリームの最後に挿入される。さらに、別の方法として、この決定ユニットはトリックプレー・再生モードのデータ・ストリームの中に少なくとも1つの解読用メッセージを追加するように構成することができる。特に、この実施例による決定ユニットは、トリックプレー再生モードでのデータ・ストリーム内の最初に暗号化されたイントラ・コーデッド・フレームから解読用メッセージをコピーするように構成することができる。このようにして、ECMはトリックプレー発生器によってトリックプレー・ストリームに挿入される。受信器による平文のトリックプレー・ストリームの処理は必ずしも必要ではないが、この方法をとることによってどちらか一方の処理が邪魔されることはない。一方、ECMストリームに進行を維持することによってECMの中断を防止することができる。
【００４７】
やはり前記実施例を参照しながら説明すると、この決定ユニットは、トリックプレー再生モードでのデータ・ストリーム内の最初に暗号化されたイントラ・コーデッド・フレームから解読用メッセージをコピーするように構成することができる。さらに、別の方法として、トリックプレー再生モードでのデータ・ストリーム内にデータ・ストリームを生成するために使用される解読用メッセージをトリックプレー再生モードのデータ・ストリームに挿入するように構成することができる。言い換えれば、最初のオプションは、単純にトリックプレー・ストリームにコピーされる、最初に暗号化されたIフレーム内に存在するECMを埋め込むことに関連している。第二のオプションはトリックプレーの発生のために用いられるECMを挿入することである。
【００４８】
上で定義された局面、および本発明のさらなる局面は、以下に説明される実施例から明らかである。
【実施例２】
【００４９】
図面内の説明図は概略的である。異なった図において、同様の、または同一の要素には同じ参照記号が付加されている。
【００５０】
以下、図１から図１３までを参照しながら、本発明の典型的実施例による送信ストリームに対するトリックプレーの実行における異なった局面について説明する。
【００５１】
特に、部分的に、または全部が暗号化されているか、または暗号化されていないMPEG2上でトリックプレーを実行するいくつかの可能性について説明する。以下の説明は、MPEG2送信ストリーム・フォーマットに特定した方法を対象とするが、本発明はこのフォーマットには限定されない。
【００５２】
実験は、実際にはいわゆるタイムスタンプつきの送信ストリームつきの拡張フォーマットを用いて行われた。この拡張フォーマットは、送信ストリーム・パケットの到着時間がその中に記録されている4バイトのヘッダーが、そのすべての先頭に付加されている送信ストリーム・パケットを備えている。この到着時間は、パケットの先頭バイトが記録装置で受信された時点でプログラム・クロック・リファレンス(PCR)のタイムベースの値から求めることができる。これはストリームのタイミング情報を保存する適切な方法であり、その結果としてストリームの再生を比較的簡単なプロセスとすることができる。
【００５３】
再生中の１つの問題は、MPEG2デコーダのバッファがオーバーランしたり、アンダーフロー（下位桁あふれ）したりしないように保証することである。入力ストリームがデコーダ・バッファ・モデルに適合しているなら、相対的タイミングの復元によって出力ストリームの適合も保証される。ここで説明されているトリックプレー法のいくつかはタイムスタンプには依存しないため、タイムスタンプがあってもなくても送信ストリーム上で等しく良好に機能する。
【００５４】
図1は、188バイトの全長104を持ち、４バイトの長さ105を持つタイムスタンプ101と、184バイトの長さを持つパケット・ペイロード103とから成るタイムスタンプつきの送信ストリーム・パケット100を示している。
【００５５】
以下、記録された送信ストリームからMPEG/DVB(Digital Video Broadcasting)に適合するトリックプレー・ストリームを生成する可能性の概略を説明する。また、以下の説明は、完全に平文であり、従ってデータのどのビットの操作も可能なストリームから、完全に暗号化され（たとえばDVB系に従って暗号化された）、その結果アクセスして操作できるのはヘッダーといくつかのテーブルのみであるストリームまで、記録されたストリームの全範囲をカバーすることを意図している。本発明は、トリックプレー・ストリームを発生するために操作される必要があるデータのみが平文であるような、上記の両極端の間に入るソリューションにも対応している。
【００５６】
MPEG/DVB送信ストリームのためのトリックプレーを生成する場合、コンテントが少なくとも部分的に暗号化される時に問題が生ずることがある。通常のアプローチである基本的なストリーム・レベルまで降りること、あるいは解読の前に任意のパケット化された基本的ストリームにアクセスすることさえ出来ないかも知れない。これはまた、画像のフレームを見出すことが出来ないことを意味している。公知のトリックプレー・エンジンは、この情報アクセスし、処理することができる必要がある。
【００５７】
この説明のフレームの中で使われている「ECM」という言葉は、「Entitlement Control Message」、すなわち「資格制御メッセージ」を表している。このメッセージは特に、秘密のプロバイダ固有の情報、とりわけ、MPEGストリームを解読するために必要な暗号化された制御ワードCW(Control Words)を含む場合がある。通常、制御ワードは時間にして10〜20秒続く。ECMは送信ストリーム内のパケットに埋め込まれる。
【００５８】
この説明のフレームの中で使われている「keys」という言葉は、特にスマートカードに保存され、送信ストリームに埋め込まれている「Entitlement Management Message」すなわち「資格管理メッセージ(EMM)」を用いてスマートカードに送信される。これらのキーはECM内に存在する制御ワードCWを解読するためにスマートカードによって使用される。そのようなキーの典型的な有効期間は1カ月である。
【００５９】
この説明のフレームの中で使われている「Control Words (CW)」という言葉は、特に実際のコンテントを解読するために必要な解読情報を示している。「制御ワード」はスマートカードによって解読され、解読コアのメモリに保存される。
【００６０】
以下、平文ストリーム（暗号化されていないストリーム）上のトリックプレーに関連するいくつかの局面について説明する。
【００６１】
たとえMPEG2ストリームが暗号化されない（すなわち、平文の場合）としても、トリックプレーは重要である。簡単なソリューションは高速前方再生モードのためにデコーダにデータをより速く出力するだけであるが、MPEGはそのヘッダー部にタイミングに関連した情報を持っているため、これは適当な高速前方再生モードを得るための期待値を用いては実行できない。それに加えて、高速前方再生を行うこの方法は表示速度よりも高速なフレーム・レートを与えるため、どのフレームを落とすべきかを決定することは難しい。
【００６２】
さらに、そのようなストリームはMPEG2規格に適合した送信ストリームではない。これは、デコーダがストレージ装置内にあれば受け入れ可能であるが、信号が標準のデジタル・インタフェースによって転送される場合は問題が発生する可能性がある。さらにまた、ビットレートはチェーン全体で劇的に増加する可能性がある。通常プレー・ストリームが衛星放送に由来する単一プログラムのタイムスタンプつき送信ストリームである場合、通常プレーにおけるデコーダへのビットレートは40 Mbps程度となり、パケットはお互いの間にギャップを持つ不規則な位置に配列される（部分的送信ストリーム）。このストリームがトリックプレー因子を用いて圧縮される場合、ビットレートは3倍のトリックプレー速度に対して120 Mbps程度となる可能性がある。ハードディスク・ドライブの必要な持続的バンド幅もトリックプレー因子とともに増加する可能性がある。
【００６３】
従って、正しい量のフレームを送り続けることは適切ではあるが、高い圧縮率を達成するためにビデオの一時的冗長度を利用する、MPEGのようなビデオ符号化テクニックを用いる場合には問題が発生する。フレームはもはや独立にはデコードされなくなるからである。
【００６４】
画像グループ(GOP: Groups Of Pictures)が複数集まった構成を図2に示す。
【００６５】
特に、図2はIフレーム201とPフレーム202のシーケンスを持つ、いくつかのMPEG2 GOP構成から成るストリーム200を示している。GOPのサイズは参照値203で表されている。この図では、GOPのサイズ203は12フレームに設定されており、Iフレーム201とPフレーム202のみが示されている。
【００６６】
MPEGの場合、GOP構造は、最初のフレームのみが他のフレームとは独立に符号化される場合に使用される。これがいわゆる「イントラ・コーデッド・フレーム」またはIフレーム201である。予測フレームまたはPフレーム202は、単方向予測を用いて符号化される。これは、図2で矢印で示されているように、以前のIフレーム201またはPフレーム202にのみ依存することを意味している。
【００６７】
そのようなGOP構造は、典型的には、12または16フレーム(201,202)を持っている。前方2倍速のトリックプレー速度が望ましいと仮定されている。従って、たとえば、どの第二フレームもスキップされなければならない。これは、デコード中は再構成された以前のフレームへの依存性があるために、圧縮されたドメイン内では不可能である。従って、単にいくつかの圧縮されたフレームを落とし、タイミング情報を固定することは他に選択の余地がない。
【００６８】
これに代わる方法として、ストリーム全体を最初にデコードし、次にすべての第二フレームをスキップし、最後に残りのフレームを再び符号化するという方法がある。しかし、これはトリックプレー回路またはソフトウェアに受け入れ難い複雑さをもたらす可能性がある。従って、最善のケースでは、他のフレームがそれに依存しない、いくつかのフレームをGOPからスキップすることができる。GOPのサイズが12フレームでトリックプレーの速度が2倍の例では、最後の6つのPフレームのみがスキップされる。この場合、表示された画像は「飛び」がちとなり、短い期間の通常速度の画像が得られた後、突然の画像の飛びが見られるようになる。特に、比較的高速のトリックプレーでは、これは視聴者に通常のトリックプレーとは異なった感じを与え、不快感を生じさせる。
【００６９】
画像グループ(GOP)を複数含む別のストリーム構成を図３に示す。
【００７０】
図３は特に、Iフレーム201、Pフレーム202、およびBフレーム301のシーケンスから成るMPEG2 GOP構成を示している。
【００７１】
図３に示すように、双方向予測フレーム、つまりBフレーム301をも含むGOP構成を使用することができる。この例では12フレームのGOPサイズが選ばれている。Bフレーム301は双方向予測を用いて符号化されている。つまり、それらは曲線矢印204でいくつかのBフレーム301に対して表示されているように、前、および次のIフレームまたはPフレームに依存することを意味している。圧縮されたフレームの送信順序は、それらが表示される順序と同じではない可能性がある。
【００７２】
Bフレーム301(表示される順序)をデコードするためには、Bフレームの前と後の両方の参照フレームが必要である。デコーダに要求されるバッファのサイズを最小化するために、圧縮されたフレームの順番が変更される。そのため、送信時には、参照フレームを最初に持ってくる。送信のために順番が変更されたストリームも図３の下側に示す。順番の変更は直線矢印302で示されている。Bフレーム301を含むストリームは、すべてのBフレーム301がスキップされた場合に良好な画像与えることができる。この例の場合、これは3倍速の高速前方再生トリックプレーを可能とする。
【００７３】
ストリームがどんな構成となっていても、ここまで説明した来たソリューションは、高速前方再生モード・トリックプレーの受け入れ可能な形を与えることができる。逆方向に対しては、フレームは時間内に順序変更が完了されなければならないが、MPEGが高い圧縮率を達成するために連続したフレーム間の一時的な相関を使用するという事実に基づいて、フレームがデコードされるべき順序は固定される。従って、順方向ではGOPが最初にデコードされなければならない。デコーダに送られるGOPの順番は逆にすることができ、より高速な逆方向トリックプレーの速度のためにGOPをスキップすることができる。上述したように、PフレームまたはBフレームをスキップすることによってGOPを減らすこともこの場合には可能である。いずれにせよ、それは順方向再生と後方ジャンプのシーケンスとして表示される結果となる。従って、トリックプレーのフレームはデコードされたGOPから選択され、順番が逆にされ、その後そのフレームは再度符号化されなければならない。次に、その前のGOPが取り込まれ、処理され、またその次のGOPが…と繰り返される。可能ではあるが、そのような処理手順の複雑さは大きくなるであろう。
【００７４】
これまでの考察から得られた結論は、Iフレームは独立にデコードすることがｄきるため、トリックプレーの発生においてはIフレームのみを用いることが適切なソリューションであるということである。結果として、トリックプレーの発生は特に逆方向の場合により簡単になる可能性がある。さらに、Iフレームのみの使用により、既にトリックプレーの速度を3分の1または4分の1に低下させることが可能となっている。現実的に低速なトリックプレーの場合、上述の技術よりさらに複雑なテクニックを導入することが可能である。
【００７５】
以下、CPI（Characteristic Point Information）ファイル（特定ポイントの情報ファイル）に関連するいくつかの局面について説明する。
【００７６】
ストリーム内のIフレームを検出するためには、ストリームを解析し、フレーム・ヘッダーを見つけ出すことが必要である。Iフレームがスタートする位置の特定は録画の実行中か、または録画が完了した後のオフライン時か、または事実上はオフラインだが録画終了後ごく僅かな時間の準オンライン状態の期間に行われる。Iフレーム
の最後は、次のPフレームまたはBフレームのスタートを検出することで知ることができる。この方法で得られたメタ・データは、特定ポイントの情報ファイル、つまりCPIファイルと表記される別の、しかし連動したファイルに保存される。このファイルは、送信ストリーム中の各Iフレームのスタート位置と実質的な終了位置とを示すポインタを含んでいる。個々の録画はそれ自身のCPIファイルを持っている。
【００７７】
特定ポイントの情報(CPI)ファイル400の構成を図４に示す。
【００７８】
図４には、CPIファイル400とは別に、それに保存される情報401も示されている。CPIファイル400はその他のデータも含んでいるが、ここでは議論しない。
【００７９】
CPIファイル400からのデータを用いて、ストリーム内の任意のIフレーム201のスタート位置にジャンプすることができる。CPIファイル400がIフレームの終了位置の情報を含んでいるなら、Iフレーム201の完全な情報が得られるため、送信ファイルから読み出すべきデータの量を正確に知ることができる。何らかの理由からIフレームの終了位置が分からない場合は、Iフレーム201全体の情報を読み出すことを保証するために、GOP全体または少なくともGOPのデータの大部分を読み出す必要がある。測定結果から、Iフレームのデータの量はGOPのデータ全体の40%以上となり得ることが分かっている。
【００８０】
得られたIフレーム201の情報を用いて、MPEG-2送信ストリーム・フォーマットに適合した新しいトリックプレー・ストリームが構成される。必要なことは、MPEGデコーダに対するバッファの問題が生じないような方法で、トリックプレー・ストリームのためのフレームが正しく再多重化されることである。これは簡単なソリューションであるように見えるが、以下で明らかになるようにそれほど簡単なソリューションではない。
【００８１】
次に、トリックプレー・ストリームの構成方法に関するいくつかの局面について説明する。
【００８２】
Iフレーム201がどのパケット位置でスタートしているか、また、Iフレーム201がどこで終了しているかを記述しているCPIファイルの助けにより、オリジナルのストリームからすべてのIフレーム201にアクセスすることが可能である。しかし、以下の説明から明らかになるように、適切に選ばれたIフレーム201をIフレーム201の1つの大きなストリームに連結させることだけでは正しいMPEGストリームを構成できない。
【００８３】
考えなければならない第一のポイントは、トリックプレー・ストリームのビットレートである。たとえば、オリジナルのストリームの平均ビットレートが4Mbps、GOPサイズ203が12フレームであるとしよう。ビットレートは実際の放送ストリームを測定することによって抽出することができる。トリックプレー・ストリームが、各々が1フレーム時間で表示され、トリックプレー・ストリームのリフレッシュ・レートが通常プレーのそれに等しくなるような、Iフレーム201のみで構成されると仮定する。Iフレーム201のデータはGOPデータの40%以上を占めることがあり得ることを思い出して欲しい。この数値は、平均値が25%程度の測定結果に基づくものである。従って、データの平均25%が時間軸上で12分の1に圧縮されなければならず、これにより3倍のビットレートが要求されることになる。このため、トリックプレーの平均ビットレートは12Mbpsとなり、そのピーク値は20Mbps程度になる。この単純な例は。ビットレートの影響とその原因に対するある程度の感触を提供することを意図している。
【００８４】
実際、Iフレーム201のサイズは既知であるか、または測定から得ることができる。従って、Iフレーム201のみのトリックプレー・ストリームのビットレートは、時間の関数として正確に、かつ容易に計算で求めることができる。トリックプレーのビットレートは、通常プレーのビットレートの2〜3倍高くなり、時にはMPEG2規格で許されるビットレートよりも高くなることもある。これが中程度のビットレートのストリームでの例であること、および高いビットレートのストリームに確実に遭遇するであろうことを考慮に入れれば、ある形のビットレート低減対策が適用されなければならないことは明らかである。たとえば、トリックプレーのビットレートが通常プレーのビットレートと同程度であることである。これは特に、ストリームがデジタル・インタフェースを介してデコーダに送られる場合に重要である。トリックプレーに起因する、インタフェースからのバンド幅への要求条件が追加されることは避けなければならない。第一のオプションはIフレーム201のサイズを抑えることである。しかし、これは暗号化されたストリームに対するトリックプレーに関係して、複雑性と制約条件を追加することになり、得策とは言えない。
【００８５】
特別なアプリケーションに対しては適切なオプションとして、各Iフレーム201を数回表示させることによってトリックプレー画像のリフレッシュ・レートを下げる方法がある。これによってビットレートを低くすることができる。これは、いわゆる空のPフレーム202をIフレーム201の間に追加することで実行することができる。そのような空のPフレーム202は実際に空なのではなく、デコーダに前のフレームを繰り返すように命令するデータを含んでいる。これは僅かながらビットコストを上げるが、Iフレーム201のビットコストに比べれば無視できるほど小さい。実験結果から、IPPやIPPPのようなトリックプレーGOP構造はトリックプレーの画像品質にとって受け入れ可能であり、高速なトリックプレーでは有利にさえなることが知られている。結果として得られたトリックプレーのビットレートは、通常プレーのビットレートと同じオーダーである。また、これらの構造はストレージ装置から要求されるバンド幅の維持条件を低減する可能性があることにも注意する必要がある。
【００８６】
以下、タイミング問題とストリームの構築に関連するいくつかの局面について説明する。
【００８７】
トリックプレー・システム500の概略図を図５に示す。
【００８８】
トリックプレー・システム500は、録画ユニット501、Iフレーム選択ユニット502、トリックプレー発生ブロック503、およびMPEG2デコーダ504を備える。トリックプレー発生ブロック503は、解析ユニット505、追加ユニット506、パケタイザ・ユニット507、テーブル・メモリ・ユニット508、およびマルチプレクサ509を含む。
【００８９】
録画ユニット501は、Iフレーム選択ユニットに平文の(暗号化されない)MPEG2データ510を提供する。マルチプレクサ509は、MPEG2デコーダ504にMPEG2 DVB適合の送信ストリーム511を提供する。
【００９０】
Iフレーム選択ユニット502はストレージ装置501から特定のIフレーム201を読み出す。どのIフレーム201が選択されるかは、以下で述べるようにトリックプレーの速度に依存する。読み出されたIフレーム201は、次にデコーディング(復号)とレンダリング(解釈)のためにMPEG-2デコーダ504に送られる、MPEG-2/DVB適合トリックプレー・ストリームを構築するために使用される。
【００９１】
トリックプレー・ストリーム内のIフレーム・パケットの位置は、オリジナルの送信ストリームの相対的タイミングと組み合わせることはできない。トリックプレーにおいては、時間軸は速度要因を用いて圧縮され、さらに逆方向トリックプレーのために逆転される。従って、タイムスタンプつきのオリジナルの送信ストリームのタイムスタンプは、トリックプレーの発生には適合していない可能性がある。
【００９２】
さらに、オリジナルのPCRタイムベースは、トリックプレーのためには妨害となる可能性がある。まず第一に、そのPCRが、選択されたIフレーム201の中で利用できるという保証はない。しかし、もっと重要なことは、PCRタイムベースの周波数が変えられることである。MPEG2の仕様によれば、この周波数は27MHzを中心として30ppm以内に入っていなければならない。オリジナルのPCRタイムベースはこの要求条件を満たしているが、トリックプレーのために使用された場合、トリックプレーの速度要因が掛け算されて周波数が上昇する逆方向トリックプレーの場合、これは、間違った方向でのタイムベース動作につながることさえある。従って、古いPCRタイムベースは取り除かれ、新しいタイムベースがトリックプレー・ストリームに追加されなければならない。
【００９３】
最後に、Iフレーム201は、通常、いつフレームのデコードを開始し(デコーディング・タイムスタンプ、DTS)、いつそれをプレゼントするか、たとえば表示するか（プレゼンテーション・タイムスタンプ、PTS）をデコーダ504に知らせる2つのタイムスタンプを含んでいる。デコーディングとプレゼンテーションはDTSとPTSが、ストリーム内のPCRを用いてデコーダ504で再構築されたPCRタイムベースと等しい時に開始される。たとえば2つのIフレーム201のPTS値間の距離は、ディスプレイ時間における公称距離に相当する。トリックプレーにおいては、この時間間隔は速度要因で圧縮される。トリックプレーでは、新しいPCRタイムベースが使用されるため、またDTSとPTSに対する距離はもはや正しくないため、Iフレーム201のオリジナルのDTSとPTSは置き換えられなければならない。
【００９４】
上述の複雑性を解決するため、Iフレーム201は最初に解析ユニット505で基本的なストリームに変換される。次に基本的ストリーム・レベルに空のP触れ無202が追加される。得られたトリックプレーのGOPはPESパケットにマッピングされ、送信ストリーム・パケットにパケット化される。次に、PAT、PMTのような訂正されたテーブルが追加される。この段階で、DTSおよびPTSと一緒に新しいPCRタイムベースが含まれる。トリックプレー・ストリームが通常プレーに対して用いられたのと同じ出力回路によって処理されるように、PCRタイムベースと組み合わされた4バイトのタイムスタンプが送信ストリーム・パケットの先頭に追加される。
【００９５】
以下、トリックプレーの速度に関連するいくつかの局面について説明する。
【００９６】
これに関連して、最初に固定トリックプレーについて議論する。
【００９７】
既に説明したように、IPPのようなトリックプレーGOP構造は、Iフレーム201の後ろに2つの空のPフレーム202が続いている場合に使用される。オリジナルのGOPが12フレームのサイズを持っていること、およびすべてのオリジナルのIフレーム201がトリックプレーのために使用されることが仮定される。これは、通常プレー・ストリーム内のIフレーム201が12フレームの距離を持っており、かつ、通常プレー・ストリーム内の同じIフレーム201が3フレームの距離を持っていることを意味している。このことから、トリックプレーの速度は12/3=4倍となる。フレーム内のオリジナルのGOPのサイズ203をG、フレーム内のトリックプレーGOPサイズをT、およびトリックプレーの速度要因をNbで表すとすれば、トリックプレーの速度は一般に次の式で与えられる。
【数１】
2008539640.tif 000003
【００９８】
このNbは基本速度(basic speed)とも呼ばれる。オリジナルのストリームからIフレーム201をスキップすることにより、より高い速度が実現される。各第二のIフレームがとられるとすれば、トリックプレーの速度は2倍になり、各第三のIフレームがとられるとすれば、トリックプレーの速度は3倍になり、以下同様である。言い換えれば、オリジナルのストリームの使用されるIフレーム間の距離は2、3であり、以下同様である。この距離は常に整数値である。トリックプレー発生のために用いられるIフレーム
間の距離をDとすれば（D=1は各Iフレームが用いられることを意味する）、トリックプレーの速度要因Nは一般に次式で与えられる。
【数２】
2008539640.tif 000004
【００９９】
これは、基本速度の整数倍の速度がすべて実現可能であり、受け入れ可能な一連の速度が実現されることを意味している。Dは、逆方向トリックプレーの場合は負であり、D=0は静止画像となることに注意されたい。また、GOPのサイズTが大きくなるほど基本速度は遅くなることにも注意されたい。たとえば、IPPPはIPPよりも細かい速度セットにつながる。
【０１００】
以下、図６を参照しながら、トリックプレーにおける時間の圧縮について説明する。
【０１０１】
図６はT=3 (IPP)およびG=12の場合を示している。D=2の場合、24フレームのオリジナルの表示時間は3フレームのトリックプレー表示時間に圧縮され、N=8となる。ここで示された例においては基本速度は整数であるが、基本速度が必ずしも整数になるとは限らない。G=16、T=3の場合、基本速度は16/3 = 5+1/3となり、整数倍のトリックプレー速度とはならない。従って、GOPサイズが16の場合にはIPPP構造（T=4）の方が適しており、4倍の基本速度が得られる。最も一般的な12や16のGOPサイズに適合する単一トリックプレー構造が望ましい場合は、IPPPを選ぶことができる。
【０１０２】
二番目に、任意のトリックプレー速度について議論する。
【０１０３】
上で説明した方法に基づく一連のトリックプレーで満足が行く場合と、満足が行かない場合とがある。G=16、T=3の場合、おそらく整数のトリックプレー速度要因を選ぶ人が多いだろう。G=12、T=4の場合でさえ、たとえば7x(７倍)のように、セット内で利用できない速度を選ぶ人がいるかも知れない。ここで、トリックプレー速度の式を、Dを計算できるように書き変えると次式が得られる。
【数３】
2008539640.tif 000005
【０１０４】
G=12、T=4、N=7の上記の例を用いると、D = 2+1/3という結果が得られる。Iフレーム201の固定数だけスキップする代わりに、どのIフレーム201が要求された速度に最もよく適合しているかの判断に基づいて次のIフレーム201を選ぶ適合スキッピング・アルゴリズムを用いることも可能である。最もよく適合するIフレーム201を選ぶためには、距離Dを持つ次の理想的なポイントIpが計算され、かつ、この理想的なポイントに最も近いIフレーム201の1つが選ばれてトリックプレーGOPを構成する。最後の理想的ポイントをDだけ増やし、以下の手順で再度計算することによって次の理想的ポイントが計算される。
【０１０５】
非整数の距離でのトリックプレーを示す図７から分かるように、Iフレーム201を選ぶための3つの可能性がある。
A. 理想のポイントに最も近いIフレーム；I=round(Ip)
B. 理想のポイントの前の最後のIフレーム；I=int(Ip)
C. 理想のポイントの後ろの最初のIフレーム；I=int(Ip)+1
【０１０６】
図７から明らかなように実際の距離は、2つの発生点間の比がDの端数に依存し、int(D)とint(D)+1の間で平均距離がDに等しくなるように変化する。これはトリックプレーの平均速度はNに等しいこと、しかし実際に使用されるフレームは理想的なフレームに対して小さなジッターを持っていることを意味している。これに関していくつかの実験が行われ、トリックプレーの速度は部分的に変化するが、これは視覚的に邪魔にはならないことが分かった。このジッターは通常は気がつかない程度であり、特にトリックプレーの速度が速い場合はほとんど気にならない。図７から、方法A、B、Cのいずれを選んでも基本的な違いはないことも明らかである。
【０１０７】
この方法では、トリックプレーの速度Nは整数である必要はなく、基本速度Nb以上の任意の数値をとることができる。また、この最低速度以下の速度を選ぶことも可能であるが、その場合は、実効的なトリックプレーGOPのサイズTが2倍になるか、または速度を3分の1またはそれ以下に低下させるため、画像のリフレッシュ速度が部分的に遅くなる可能性がある。これは、アルゴリズムが同じIフレーム201を何度も選ぶことになり、トリックプレーGOPが反復されることによる。
【０１０８】
図８は、N=2/3 Nbと等価であるD=2/3の例を示す。ここで、Iフレーム201を選ぶために丸め関数(round function)が用いられており、フレーム2とフレーム4が2回選ばれていることが分かる。
【０１０９】
いずれにせよ、説明された方法はトリックプレー速度を連続的に変化させることができる。逆方向トリックプレーの場合は、Nに負の値を選べばよい。図７の例では、これは単純に矢印700が別の方向を指していることを意味している。説明された方法は、既に説明された固定トリックプレーのセットを含み、特に丸め関数が用いられた場合には、それらは同じ品質を持つ。従って、このセクションで説明された柔軟な方法は、どんな速度が選択されても常に採用されるべきであると言っても差し支えがないであろう。
【０１１０】
以下、トリックプレー画像のリフレッシュ速度に関連するいくつかの局面について説明する。
【０１１１】
リフレッシュ速度(refresh rate)という言葉は、特に、それを使って新しい画像が表示される周波数を指すものとする。リフレッシュ速度はトリックプレー速度には依存しないが、Tの選択に影響するためここで簡単に議論する。オリジナルの画像のリフレッシュ速度(25Hzまたは30Hz)をRで表すとすれば、トリックプレー画像のリフレッシュ速度(Rt)は次式で与えられる。
【数４】
2008539640.tif 000006
【０１１２】
トリックプレーGOP構造(T=3)またはIPPP(T=4)では、フレッシュ速度Rtはヨーロッパではそれぞれ8+1/3および6+1/4となり、米国ではそれぞれ10Hzおよび7+1/2Hzとなる。トリックプレー画像の品質に対する判断は主観的な問題が入ってくるが、実験結果から、これらのリフレッシュ速度は低速でも受け入れ可能であり、高速では有利でさえあるという明白なヒントが得られている。
【０１１３】
以下、暗号化されたストリーム環境に関連するいくつかの局面について説明する。
【０１１４】
以下、暗号化されたストリーム上のトリックプレーを説明する上での基礎として、暗号化された送信ストリームに関する情報についても説明する。
【０１１５】
図９は、以下で説明される条件つきアクセス・システム900を示す。
【０１１６】
条件つきアクセス・システム900においては、コンテント901がコンテント暗号化ユニット902に供給される。コンテント暗号化ユニット902は、コンテント901を暗号化した後、コンテント解読ユニット904に暗号化されたコンテント903を供給する。
【０１１７】
コンテント暗号化ユニット902とECM生成ユニット907には、制御ワード906が供給される。ECM生成ユニット907は、ECMを生成し、同じものをスマートカード905のECM復号ユニット908に供給する。ECM復号ユニット908は、ECMから、暗号化されたコンテント903を解読するために必要であり、コンテント解読ユニット904に供給される制御ワードCWを生成する。
【０１１８】
さらに、権限キー910がECM生成ユニット907とKMM生成ユニット911に供給される。なお、後者はKMMを生成し、同じものをスマートカード905のKMM復号ユニット912に供給する。KMM復号ユニット912は出力信号をECM復号ユニット908に供給する。
【０１１９】
さらに、グループ・キー914が、KMM生成ユニット911と、ユーザー・キー918も供給されるGKM生成ユニット915に供給される。GKM生成ユニット915は、GKM信号を生成し、同じものをスマートカード905上の、ユーザー・キー917も供給されるGKM復号ユニット916に供給する。
【０１２０】
さらに、「資格」919が、EMM信号を生成し、同じものをEMM復号ユニット921に供給するEMM生成ユニット920に供給される。スマートカード905上のEMM復号ユニット921は、ECM復号ユニット908に対応する制御情報を供給する資格リスト・ユニット913と組み合わされる。
【０１２１】
ここで、ECMはEntitelment Control Message（資格制御メッセージ）、KMMはKey Management Message（キー管理メッセージ）、GKMはGroup Key Message（グループキー・メッセージ）、EMMはEntitlement Management Message（資格管理メッセージ）の略語である。
【０１２２】
多くの場合、コンテント・プロバイダやサービス・プロバイダは条件つきアクセス(CA)システムによってあるコンテント・アイテムへのアクセスをコントロールしたいと考えている。
【０１２３】
これを行うために、放送されるコンテント901は、CAシステム900のコントロールの元で暗号化される。受信側では、コンテントが復号化され、アクセスがCAシステム900によって許可されるかどうかが判定される前に解読される。
【０１２４】
CAシステム900は、重構造の階層構成を使用している(図９参照)。CAシステム900は、コンテントの解読用キー（制御ワード906, 909）をECM(Entitlement  Control Message: 資格制御メッセージ)と呼ばれている暗号化されたメッセージの形でサーバーからクライアントへ送信する。ECMは、権限キー(AK)910を用いて暗号化されている。セキュリティ上の理由から、CAサーバー900は、KMM(Key Management Message：キー管理メッセージ)を発行することにより権限キー910を更新する。KMMは実際にはEMM(Entitlement Management Message：資格管理メッセージ)の特別なタイプであるが、明確にするためにKMMという言葉が用いられている。KMMもまた、あるキー（たとえば、やはりEMMの特別なタイプであるGKM(Group Key Message：グループキー・メッセージ)を送ることによって更新されるグループキー(GK)914でもよい）を用いて暗号化される。次にGKMは、スマートカード905に埋め込まれた固定のユニークなキーでありプロバイダのCAシステムのみが知っているユーザー・キー(UK)917、918を用いて暗号化される。権限キーとグループキーは受信側のスマートカード905に保存される。
【０１２５】
資格919（たとえば視聴権）はEMM（資格管理メッセージ）の形で各ユーザーに送られ、安全な装置（たとえばスマートカード905）に局所的に保存される。資格919は特別なプログラムで検証される。資格リスト913が、視聴申し込みのタイプに依存してプログラムのグループへのアクセス権を与える。資格制御メッセージECMは、資格919がその特定のプログラムに適用可能である場合に、スマートカード905によって処理され、キー(制御ワードCW)を再生する。資格管理メッセージEMMはキー管理メッセージKMMと同じ重構造の階層構成（図９では示されていない）に従属している。
【０１２６】
MPEG2システムにおいては、暗号化されたコンテント、ECMおよびEMM（KMMやGKMタイプも含む）はすべて単一のMPEG2送信ストリームに多重化される。
【０１２７】
上記の説明は、CAシステム900の一般的な見方である。デジタル・ビデオ放送においては、暗号化アルゴリズム、奇数/偶数制御ワード構造、ECMとEMMのグローバルな構成、およびそれらに関連した事項のみが定義される。CAシステム900の詳細構造、およびECMとEMMのペイロードが符号化され、使用される方法はプロバイダ固有のものである。スマートカードもまたプロバイダ固有のものである。しかし、実験結果から、多くのプロバイダが基本的には図９の一般的な見方に従っていることが分かった。
【０１２８】
以下、DVBの暗号化および解読の方法について議論する。
【０１２９】
適用される暗号および解読のアルゴリズムはDVB標準化機構によって定義されている。原理的には、2つの暗号化の可能性、すなわちPESレベル暗号化とTSレベル暗号化が定義されている。しかし、実際には主にTSレベル暗号化が使用されている。送信ストリーム・パケットの暗号化と解読は、パケット・ベースで行われる。このことは、暗号および解読のアルゴリズムは新しい送信ストリーム・パケットが受信される度に再スタートされることを意味している。従って、パケットは、個別に暗号化され、解読されることになる。送信ストリームの中では、あるストリーム部分は暗号化され（たとえば、オーディオ/ビデオ）、他の部分は暗号化されない（たとえば、表）ため、暗号化されたパケットと平文の(暗号化されていない）パケットが混在している。1つのストリーム部分（たとえばビデオ）の中でさえも、暗号化されたパケットと平文のパケットが混在している。
【０１３０】
以下、図１０を参照しながら、暗号化されたDVB送信ストリーム・パケットについて説明する。
【０１３１】
このストリーム・パケット1000は、188バイトの長さ1001を持ち、3つの部分から構成される。パケット・ヘッダー1002は4バイトのサイズ1003を持つ。ストリーム・パケットには、パケット・ヘッダー1002に続いて、適合フィールド1004が含まれる。その後に、暗号化されたDVBパケット・ペイロード1005が続いている。
【０１３２】
図１１は、図１０の送信ストリーム・パケット・ヘッダー1002の詳細構造を示す。
【０１３３】
送信ストリーム・パケット・ヘッダー1002は、同期ユニット(SYNC)1010、パケット内の送信エラーを表示する送信エラー・インジケータ1011、引き続くペイロード1005内のPESパケットの可能なスタートを特別に表示するペイロード・ユニット・スタート・インジケータ(PLUSI)1012、送信の優先順位を表示する送信優先順位ユニット(TPI)1017、パッケージの任務を決定するために用いられるパケット識別子(PID)1013、送信ストリーム・パケットの解読に必要な制御ワードCWを選択するために用いられる送信スクランブル・コントロール(SCB)1014、適合フィールド・コントロール(AFLD)、および連続性カウンタ(CC)1016を備えている。図１０と図１１は、暗号化され、以下に示す異なった部分を備えたMPEG2送信ストリーム・パケットを示している。
−  パケット識別子(PID)番号、適合フィールドの存在、スクランブル・コントロール・ビット、等の重要な情報を得るために用いられる、平文のパケット・ヘッダー1002。
−  これはPCRのような重要なタイミング情報を含む、やはり平文の適合フィールド1001。
−  DVBアルゴリズムを用いて暗号化された実際の番組のコンテントを含むDVBパケット・ペイロード1005。
【０１３４】
放送された番組を解読するのに必要な正しいCWを選択するためには、送信ストリーム・パケット・ヘッダーを解析する必要がある。このヘッダーの構成を図１１に示す。放送番組を解読するための重要なフィールドがスクランブル・コントロール・ビット(SCB)フィールド1014である。このSCBフィールド1014は、解読器が放送番組を解読するためにどの制御ワードCWを使用しなければならないかを指示する。さらに、このフィールドはパケットのペイロードが暗号化されているか、平文であるかも表示する。このSCBは時間とともに、またパケット毎に変化するため、新しい送信ストリーム・パケットを受け取る度に解析されなければならない。
【０１３５】
以下、完全に暗号化されたストリーム上のトリックプレーに関連するいくつかの局面について説明する。
【０１３６】
これが興味ある話題であることの理由は、平文のトリックプレーと完全に暗号化されたストリームのトリックプレーが、可能性の範囲の両極端にあたるからである。もう1つの理由は、完全に暗号化されたストリームを記録することが必要となる可能性があるアプリケーションが存在するからである。従って、完全に暗号化されたストリーム上でトリックプレーを実行するための技術を理解しておくことが有効であろう。基本原理は、ストレージ装置から十分大きなデータのブロックを読み出し、それを解読し、ブロック内のIフレームを選択し、それを用いてトリックプレー・ストリームを構築することである。
【０１３７】
そのようなシステム1200を図１２に示す。
【０１３８】
図１２は、完全に暗号化されたストリーム上でのトリックプレーの基本原理を示している。この目的のために、ハードディスク1201に保存されたデータが送信ストリームとして解読器1203に供給される。さらに、ハードディスク1201は、スマートカード1204にECMを供給する。マスターカード1204は、このECMから制御ワードCWを生成し、同じものを解読器1203に送る。
【０１３９】
解読器1203は、この制御ワードを用いて暗号化された送信ストリーム1202を解読し、解読されたデータをIフレーム検出器とフィルター1205に送る。データはそこから空のPフレーム挿入ユニット1206に送られ、さらにセットトップボックス1207に送られる。そして最後にデータがテレビ1208に供給される。
【０１４０】
以下、録画が何を含むかという質問に関連するいくつかの局面について説明する。
【０１４１】
単一チャンネルを録画する際に、録画情報には後でそのチャンネルの録画を再生するために必要なすべてのデータを含ませておかなければならない。単にある中継器上にすべての情報を記録させるという手段をとることも可能であるが、この方法は録画しようとする番組を再生するのに必要な情報よりかなり多くの情報を記録することになる。これはバンド幅とストレージ空間の両方で無駄を生ずることを意味する。従ってその代わりとして、実際に必要なパケットのみを記録する方法があればよい。このことは、PAT(Program Association Table、番組関連テーブル)、CAT(Conditional Access Table、条件つきアクセス・テーブル)のようなMPEG2に不可欠なパケットのすべて、および、明らかに各番組についてビデオおよびオーディオ・パケットと同時にどのパケットが番組に属しているかを記述するPMT(Parogram Map Table、番組マップ・テーブル)をも記録することを意味する。さらに、このCAT/PMTは、ストリームの解読に必要なCAパケット(ECM)を記述することも可能である。解読の後、録画が平文で行われない場合でも、これらのECMパケットは同様に記録されなければならない。
【０１４２】
録画されたデータが、完全な多重化からのすべてのパケットを含んでいない場合、その録画データはいわゆる部分的送信ストリーム1300となる（図１３参照）。さらに、図１３は完全な送信ストリーム1301も示している。DVBの規格は、部分的送信ストリーム1300が再生される場合、NIT(Network Information Table、ネットワーク情報テーブル)、BAT(Bouquet Association Table、ブーケ関連テーブル)等のようなすべての正常なDVB必須テーブルが除去されることを要求している。これらのテーブルの代わりに、部分的ストリームにはSIT(Selection Information Table、選択情報テーブル)とDIT(Discontinuity Information Table、不連続情報テーブル)が挿入されなければならない。
【０１４３】
以下、図１４から図３２までを参照しながら、本発明の典型的実施例に基づき、暗号化されたデータ・ストリームの処理が可能なシステムについて説明する。
【０１４４】
ここで、以下に説明するシステムが、図１から図１３までを参照しながら説明したシステムのフレーム、およびそれらの任意のシステムとの組み合わせで実現可能であることを強調しておく。
【０１４５】
以下、資格制御メッセージECMの処理に関連するいくつかの局面について説明する。
【０１４６】
トリックプレー中に次のブロックにジャンプするということは、ストリームの中でジャンプして戻ることを意味する。以下、中程度の速度では、これが逆方向トリックプレーの場合だけでなく順方向トリックプレーの場合にも当てはまることを説明する。その後で、前方ジャンプによる順方向トリックプレーの状況と、後方ジャンプによる逆方向トリックプレーの状況とについて説明する。
【０１４７】
データが解読されなければならないという事実に起因して、特殊な問題が発生する可能性がある。データ通信のために条件つきアクセス・システムが設計されることがある。通常プレーにおいては、送信されたストリームはオリジナルのタイミングで再構築される。しかし、トリックプレーは、タイミングが変更されていることにより、暗号メタ・データの処理のために難しい問題を解決する必要がある。すなわち、データはトリックプレーにより時間上で圧縮されるが、スマートカードの遅延時間は一定のまま残されるということである。
【０１４８】
トリックプレー・ストリームを生成するために、データ・ブロックは解読器を通される。この解読器は、データ・ブロックを解読するために暗号化プロセスで使用された制御ワードCWを必要とする。これらの制御ワードも暗号化され、ECMに保存される。通常のセットトップボックス(STB)では、これらのECMが同調される番組データの一部となる。条件つきアクセス・モジュールはECMを抽出し、スマートカードに送る。カードがこれらのECMを解読する権利または資格を持っている場合、ECMから解読された制御ワードを受け取ることができる。制御ワードは通常、比較的短い寿命、たとえば10秒程度の寿命しか持っていない。制御ワードの寿命は送信ストリーム・パケット・ヘッダー内のスクランブル・コントロール・ビット(SCB)で表示される。制御ワードが変わった場合、次の制御ワードが使用されねければならない。SCBの変化または切り替えの位置は、図１４の垂直線と参照番号1402で示されている。
【０１４９】
図１４内の下側のストリームで示されているストリーム・タイプIでは、1つの資格制御メッセージECMあたり2つの制御ワードが供給されている。
【０１５０】
一方、図１４内の上側のストリームで示されているストリーム・タイプIIでは、1つの資格制御メッセージECMあたり制御ワードが1つだけ供給されている。
【０１５１】
図１４は、参照番号1403で表される、順番に配列され期間またはセグメントA、B、Cから構成される2つのデータ・ストリーム1400と1401を示している。図１４の上側のストリームのシナリオでは、対応するECMあたり1つの制御ワードが供給されている。これとは対照的に、ストリーム1401では、各ECMは2つの制御ワード、すなわち現在の期間またはECMに関係する制御ワードと、それに続く期間またはECMの制御ワードとが供給されている。従って、後者の場合は制御ワードの供給に関してある冗長性がある。
【０１５２】
短い寿命の間に、解読情報のアイテムは、そのような制御ワードの寿命期間の途中でそのようなチャンネルにチューニングすることが次の制御ワードを待っていることを意味しないように、数回にわたって送信される。条件つきアクセス・モジュールは、スマートカードのプロセッサはかなり低速であるため、プロセッサカードへのトラフィックを減少させるか最小化するために、検出した最初のユニークなECMをスマートカードに送るだけである。
【０１５３】
これは、暗号化されたストリーム上のトリックプレーに速度制限があることを示している。まず、スマートカードの処理能力の限界速度からくる暗黙の速度上限が存在する。トリックプレーにおいては、10秒間という制御ワードの寿命はトリックプレーの速度要因で圧縮される。ECMをスマートカードに送信する周波数は速度要因が掛けられて高くなるということもできる。ECMのスマートカードへの送信と、解読された制御ワードの受信には、0.5秒程度かかる。各制御ワードの寿命が10秒程度であるとすれば、トリックプレーの最高速度は20倍に制限される。しかし、この20倍に達するためには、ECMが正しい時間に送信または供給されることが要求される。逆方向では、それらはある逆の順序で送られなければならない。このことは、オリジナルのストリームにおける位置にのみ依存することは出来ないことを意味している。制御ワードがECMに詰め込まれる方法は、プロバイダ固有であり、かつ、特に図１４に示されているストリームのタイプIおよびタイプIIによって異なる。
【０１５４】
CW Aは、期間Aを暗号化するために用いられたCWを、また、CW Bは期間Bを暗号化するために用いられたCWを表しており、以下同様である。水平方向は送信時間軸である。ECM Aは期間Aの大部分を占めるECMであることを表している。この場合、ECM Aは現在の期間AのためのCWと、次の期間Bのストリーム・タイプIのためのCWを保持することが分かる。一般に、ECMは少なくとも現在の期間のためのCWを保持し、さらに次の期間のためのCWを保持することもできる。ザッピングのために、これはおそらくすべてのまたは多くのプロバイダに真実であると思われる。
【０１５５】
以下、前方トリックプレーに関連するいくつかの局面について説明する。
【０１５６】
次に、いくつかのIフレームをスキップするとかなり高速な早送りが可能となることを説明する。トリックプレーにおいては、データ、および、それゆえにSCB期間が速度要因に等しい量だけ圧縮される。特別なことは行われないこと、およびストリーム内に埋め込まれたオリジナルのECMを使用するためにSTBに残されることが仮定される。ストリーム・タイプIの場合、この仮定は圧縮されたSCBの期間がスマートカードの遅延時間よりも長い限り、たとえば、ECM Bが期間CのためのCWを保持するため(図１４参照)、問題は生じない。従って、期間Bの全体が、ビデオ・データの解読のために期間Cのスタート時に利用可能となっているべきCW Cの解読のために利用可能である。これは結果として、SCB期間のスマートカード遅延に対する比に等しい最高のトリックプレー速度、たとえば20倍の速度を達成する可能性がある。しかし、ストリーム・タイプIIの場合はCW CがECM B内に存在しないため、この方法はストリーム・タイプIIでは成功しない。
【０１５７】
処理を継続する前に、解読器と解読器が制御ワードCWを処理する方法についてさらに多くの情報が提供される。解読器は、2つのレジスタ、1つは「奇数(odd)」の、他の１つは「偶数(even)」の制御ワードCWを保存するレジスタを含んでいる。奇数と偶数はCWの値自体が偶数か奇数かを表すものではない。この用語は特にストリーム内の連続した2つのCWを区別するために用いられている。どちらのCWがパケットの解読に用いられるべきかは、パケット・ヘッダー内のSCBで示される。そのため、ストリームを暗号化するために用いられたCWは偶数と奇数が交互に入れ替わる。図１４では、たとえば、CW AとCW Cは奇数、CW BとCW Dは偶数である。スマートカードによる解読の後、CWは解読器内の対応するレジスタに書き込まれ、図１５に示されるようにそれまでの値が書き変えられる。
【０１５８】
図１５は、2つのレジスタ1501と1502が、それぞれ偶数のCW（レジスタ1501）と奇数のCW（レジスタ1502）を含んでいることを示している。さらに、スマートカードがECMからCWを取り出し、解読するために必要な時間であるスマートカードの遅延時間1500も図１５に示されている。
【０１５９】
ストリーム・タイプIの場合、各ECMは2つのCWを保持しており、その結果として両方のレジスタ1501、1502ともECMの解読の後、書き変えられる。レジスタ1501と1502のどちらかがアクティブなら他方はアクティブでない。どちらがアクティブとなるかは、SCBによって決まる。この例の場合、SCBは、期間Bの間は偶数のレジスタ1501がアクティブであることを示している。アクティブなレジスタは、その特定の期間の残り部分の解読するために依然として必要であるため、それが既に保持しているものと同じCWで上書きされるだけである。従って、アクティブでないレジスタのみが新しい値で上書きされる。
【０１６０】
トリックプレーにおける期間Bを詳しく見て見よう。ECMがこの期間の最初にスマートカードに送られ、その瞬間にSCBの切り替え1402が交叉すると仮定しよう。この時、どのECMがスマートカードに送られるだろうか？
【０１６１】
このECMは、期間Cの開始時に使用されるように、スマートカードによってタイムリーに解読されることを保証するためにCW Cを保持していなければならない。
【０１６２】
ECMは解読器でのCWの正しい利用を妨げることなくCW Bを保持することもできる。
【０１６３】
再度図１４を見ると、期間Bの開始時に、ストリーム・タイプIの場合は、これはECM B送り、ストリーム・タイプIIの場合はECM Cを送ることを意味していることが分かる。一般に、ECMが2つのCWを保持している場合は現在のECMが送られ、ECMがCWを1つだけ保持している場合は1期間先行してECMが送られる。しかし、ECMを1期間先行して送るということは埋め込まれたECMとは矛盾することになるため、そのような場合、後者はストリームから取り除かれなければならない。より一般的なアプローチの場合、オリジナルのECMは、トリックプレー生成回路またはソフトウェアによってストリームから常に取り除かれるという方法が選ばれる。データ・ブロックを読み出し、ストリームの前方にジャンプしてECMを送る典型的な方法を図１６に示す。
【０１６４】
図１６は、高速前方再生モードにおけるECMの処理方法を示す。
【０１６５】
SCBの切り替え1402で分離された複数の連続した期間1403において、複数のデータ・ブロック1600が再生され、異なったデータ・ブロックの間で切り替え1601が生じている。
【０１６６】
ストリーム・タイプIの場合、期間AとBの間の境界でECM Bが送られる。ストリーム・タイプIIの場合は、期間AとBの間の境界でECM Cが送られる。さらに、ストリーム・タイプIによれば、期間BとCの間の境界でECM Cが送られる。ストリーム・タイプIIの場合は、期間BとCの間の境界でECM Dが送られる。
【０１６７】
ECMが正しい瞬間にトリックプレーのために利用できるために、ECMを別のファイルに保存することができる。このファイルの中で、ECMがどの期間に（記録されたストリームのどの部分に）所属するかを指示することもできる。MPEGストリーム・ファイル内のパケットは番号がつけられている。ある期間の最初のパケットの番号（SCB切り替え1402）は、この同じ期間1403に対するECMと並んで保存される。ECMファイルはストリームの録画中に生成される。
【０１６８】
図３２にECMファイルの例を示す。
【０１６９】
ECMファイルは、録画中に生成されるファイルである。ビデオ・データを解読するために必要な制御ワードCWを含むECMパケットが、ストリームの中に配置される。各ECMがある期間、たとえば10秒間の間使用され、この期間（たとえば10秒間）中に数回（繰り返して）送信される。ECMファイルはそのような期間の最初の新しいECMを記録する。ECMデータは、いくつかのメタ・データとともにこのファイルに書き込まれる。まず第一に、ECMデータに対してシリアル番号（1から始まる）が与えられる。ECMファイルは、2番目のフィールドにSCBの切り替え位置を含んでいる。これは、コンテントを正しく解読するためにこのECMを使用することができる最初のパケットを示している。3番目のフィールドには、このSCBの切り替え時間内の位置が記録される。これら3つのフィールドの後に、ECMパケット・データ自体が続く。図３２では、ECMパケット・データの最初のバイトのみが示されている。ECM間の違いはペイロード部分にあり、ここでは見ることができない。
【０１７０】
ECMファイルに保存されているSCBの切り替え位置情報を用いれば、切り替えがジャンプ中に生じたとしてもSCBの切り替えが発生したことを検出するのは容易である。正しいECMを送るためには、ECMが制御ワードCWを1つ含んでいるか、2つ含んでいるかを知る必要がある。原理的には、これはプロバイダ固有の情報であり、秘密であるため、未知の情報である。しかし、これは実験的にECMを様々な時間に送りてディスプレイ上の結果を観察することにより簡単に知ることができる。これに代わる、ストレージ装置自身内で実行するために特に適した方法は以下の通りである。SCBの切り替えの瞬間に、スマートカードに1つのECMを送り、ストリームを解読し、次に来る2つの期間でPESヘッダーをチェックする。GOPあたり1つのPESヘッダーがあるとすれば、各期間内に20個程度のPESヘッダーが存在する。PESヘッダーの位置は、パケットの平文のヘッダー内のPLUSIビットがその存在を示すため、容易に検出することができる。正しいPESヘッダーが最初の期間内に（スマートカードの遅延時間の後）見つかれば、ECMは制御ワードCWを1つ含んでいる。また、ECMヘッダーが第二の期間内に見つかれば、ECMは制御ワードCWを2つ含んでいることになる。
【０１７１】
そのような状況を図１７に示す。
【０１７２】
図１７は、制御ワードCWが1つ検出された場合と、2つ検出された場合とを示している。図から分かるように、暗号化されたコンテント1700の異なった期間1403が提供される。スマートカードの遅延時間1500があるために、ECM Aは対応する制御ワードCWを生成するように解読される。暗号化されたコンテント1700を解読することによって、解読されたコンテント1701が生成される。図１７には、PESヘッダー1702も、期間A（左側）内のPESヘッダーAと期間B（右側）内のPESヘッダーBで示されている。
【０１７３】
図１７でCWが1つの場合の期間Bの領域1703は、データが間違ったキーで解読され、従って混乱していることを示している。これのチェックは録画中に行うことができ、そのような場合はたとえば20秒から30秒かかる。チェックはオフラインでも可能である。オフラインでは、PLUSIで示される2つのパケットをチェックするだけでよいため、非常に迅速にチェックできる。適切なPESヘッダーが利用できない、ありそうもない事態の場合は、その代わりに画像のヘッダーを利用することも可能である。実際には、どんな既知の情報でも検出のために使用することができる。いずれにせよ、ECMファイルには1つまたは2つの制御ワードCWが保存される。
【０１７４】
これまで、ストリーム内のジャンプは最大1つのSCBの切り替えにまたがると仮定して来た。1つ以上の切り替えにまたがる場合は、今までに説明された方法を変更する必要がある。そのような場合は、ECMを送るための新しい方法が必要になる。図１８はこの状況を示している。
【０１７５】
2つのSCB切り替えにまたがるジャンプの場合を図１８に示す。
【０１７６】
図１８の方法によれば、ストリーム・タイプIでは、ECM Aが期間Aの初めに送られる。ストリーム・タイプIIでは、期間Aの初めにECM Bが送られる。さらに、ストリーム・タイプIでは、ECM Cが期間Bの初めに送られ、トリーム・タイプIIでは、期間Bの初めにECM Dが送られる。
【０１７７】
第一に、次のジャンプがSCB切り替え1402を1つ超えるか、2つ超えるかを知るために先読みが行われる。これは、ECMがスマートカードに送られる際に、次のジャンプに続くデータを解読するためのCWを含むECMを選択するために必要である。しかし、2つのSCBジャンプの後のデータは、ジャンプの前のデータと同じCWタイプ（偶数または奇数）で暗号化される。ジャンプ後に必要なCWを含むECMを送ることによって、解読器内のアクティブなレジスタが自動的に異なった値で書き変えられ、現在の期間内のデータが失われてしまう。そのため、この方法はうまく行かず、2つのSCB切り替えを超えるジャンプは不可能である。
【０１７８】
これはトリックプレーの最高速度に対する制限要因にもなる。ジャンプのサイズが1SCB期間の最大であると仮定すると、たとえば10秒間のオリジナルの時間は1トリックプレーGOPの表示時間に圧縮される。IPPPの場合、これはヨーロッパでは160msに等しい。これはおよそ60倍のトリックプレー速度要因にあたる。1はジャンピング時間ではなく固定されたパケットの数であるため、最大のジャンプ・サイズはたとえば5秒間に相当する。依然として、スマートカードの遅延時間、言い換えればスループットはトリックプレーの速度を制限する主な要因である。
【０１７９】
以下、逆方向トリックプレーに関連するいくつかの局面について説明する。
【０１８０】
逆方向トリックプレーにおいては、ストリーム・ファイル内で後方ジャンプが行われる。あるフレームに属するデータは前方再生モードで読み出されるが、後方再生が行われる場合は、読み出される画像はそのストリーム内の以前の画像である。
【０１８１】
データが読み出され、ジャンプする様子を図１９に示す。
【０１８２】
図１９は、時点1900でECM Aが送られ、時点1901でECM Bが送られることを示している。
【０１８３】
特別なECMの問題については既に前方再生トリックプレーに関して議論されている。以下では、後方再生の場合に生ずる問題について議論する。
【０１８４】
図１９を見れば次のことが分かる。
・  ある期間からのデータを解読するためのCWは、この期間に入る前に既に解読器の中に存在していなければならない。
・  前の通常プレー期間（次のトリックプレー期間）は、常に後方ジャンプ中に始まっている。
・  CW Bを保持しているECMは、スマートカードの遅延時間に考えられる最高のトリックプレー速度を可能とするために、期間Cに入る時に送られなければならない。
・  次にこのECMは、期間Cの引き続く解読プロセスを妨げることなくCW Cを保持することもできる（解読器内のCW CはCW Cで上書きされる）。
【０１８５】
従って、一般的に、逆方向で期間に入る時、以前の通常プレー期間のCWを保持し、我々が入ったばかりの期間のCWを保持するECMが送られる。
【０１８６】
図１４から、期間Cが逆方向に入った時、ストリーム・タイプIの場合も、ストリーム・タイプIIの場合も、ECM Bがスマートカードに送られなければならないことが分かる。一般に、ECMは入った期間の前の期間から送られなければならない。再び図１９から、SCBの切り替え1402は1回以上交叉することができること、および逆方向で2回、期間に入ることもできることが分かる。これらのどの場合にECMが送られるべきかを判断するために、期間Cに入った時に何が起きるかを考える必要がある。
・  期間Cに初めて入った場合、期間Dまで伸びるデータのブロックが読み出される。このブロックを解読するためにはCW CとＣＷ Ｄの両方が解読器にレジスタの中に既に存在していなければならない。初めて期間Cに入った瞬間こそがこの場合である。
・  期間Cに初めて入った瞬間にECM Bが送られると仮定すれば、スマートカードの遅延時間の後、CW Bが解読器内のCW Dを上書きする。この遅延時間がデータのブロックを読み出し、解読するために必要な時間より短い場合は、このブロックの最後の部分が正しく解読されないだろう。
・  しかし、2回目に期間Cに入った時は、期間Cと期間Dの間の境界を越えて伸びているデータ・ブロックは既に解読されているため、CW Dはもう必要でなくなっている。従って、CW Bはこの瞬間には安全にCW Dを上書きすることができる。この瞬間にECM Bを送ることは正しいソリューションである。
特定の期間に1度のみならず2度目にも入ろうとしていることは簡単に検知することができる。パケット内のブロックサイズ、そこへジャンプされるストリーム・ファイル内の位置、およびECMファイル内に保存される時のSCBの切り替え1402の位置が分かる。ジャンプ目標からSCBの切り替え1402までの距離がブロックサイズよりも小さい場合、その期間に2度目に入ることになる。
【０１８７】
従って、一般的には、ECMは、期間への最後のジャンプの開始時に送られる。これは、たった今入った期間の前の期間のECMである。この様子が図１９に示されている。ジャンプの前と後のブロックの最後の間に2つの期間の境界が位置している場合に、このECMが送られるということも可能である。これにより、期間に2度入るかどうかを検知する必要がなくなり、期間内でのジャンプのためにECMの挿入をスキップすることが可能になる。
【０１８８】
以下、中程度の速度のトリックプレーに関連するいくつかの局面について説明する。
【０１８９】
図１６は、前方再生のための理想的な状況、つまり引き続くデータ・ブロックが重なり合っていない状況を示している。しかし、トリックプレーの速度が中程度である場合、すなわち、どのIフレームもスキップされない場合、かつ通常プレーのストリームが解読されてIフレームの位置が不明である場合は、ある重なり合いが生ずることがある。
【０１９０】
図２０がこの状態を示している。
【０１９１】
図２０は、特に、時点2000でストリーム・タイプIの場合にECM Cが送られ、ストリーム・タイプIIの場合にECM Dが送られること、および時点2001でストリーム・タイプIの場合にECM Bが送られ、ストリーム・タイプIIの場合にECM Cが送られることを示している。
【０１９２】
ECMがSCBの切り替え1402の交叉時に送られることは既に説明した。後方再生時には、特定の切り替え1402がトリックプレーの方向に2回交叉することができる。全く同じ理由から、ECMは切り替え1402が最後に交叉する時に送られなければならない。ここでも、これは容易に検知することができる。再び、後方へのジャンプが行われている場合にそこから得られる、ジャンプ目標間のブロックサイズと距離を知ることができる。そうであって、既知のSCB切り替え1402の位置が、そのような後方ジャンプ中に交叉している場合、このSCB切り替え1402は再度交叉する。一般に前方トリックプレーの場合、ECMは期間1403に最後に入った時に送られる。言い換えれば、SCBの切り替え1402が次のジャンプ目標の後に位置していない限り、ECMは新しい期間に入った時に送られる。
【０１９３】
次に、ECMを送ることに関連するいくつかの局面について説明する。
【０１９４】
ECMの処理に関するこれまでの議論において、ECMがマスターカードに送られなければならないと説明した。ここでは、平文のトリックプレー・ストリームが、完全に暗号化された通常プレー・ストリームからどのようにして組み立てられるかについて説明する。MPEG適合のトリックプレー・ストリームは平文であるため、それ自体にはECMは必要がないが、ストリームを組み立てるためにECMが必要となる。解読器を含めて、トリックプレーの生成はストレージ装置の機能の一部である。この装置の中にスマートカードも存在している場合、ECMを送ることは文字通りであり、ECMはスマートカードのインタフェース・フォーマットに変換された後、適切なタイミングでスマートカードに送られる。しかし、理論上、スマートカードへのコマンドがプロバイダ固有の秘密のものであるため、このフォーマットは不明であることが多い。そのため、ECMはスマートカードが接続されているセキュリティ装置に送られる必要がある。ストレージ装置自体の中にスマートカードが含まれていない場合は、外部のスマートカード、たとえばSTB内のスマートカードとの安全なコミュニケーションが確立されなければならない。
【０１９５】
しかし、より一般的なアプローチという理由から、平文のIフレームを抽出するために条件つきアクセス・モジュール（解読器を含む）に送られる送信ストリーム・ブロック内に必要なECMを埋め込むという別のオプションが好まれる可能性がある。埋め込まれたオリジナルのECMは、このストリームから取り除くことができる。ある時点でECMを送ることは、解読器へのストリーム内のそのポイントにECMが挿入されなければならないことを意味している。これらのECMは、通常の放送信号と同様に定期的に繰り返されることも可能であるが、これは実際には必要ではなく、従ってトリックプレーの生成を複雑化するものとなる。
【０１９６】
以下、通常プレーとトリックプレーの間の切り替えに関連するいくつかの局面について説明する。
【０１９７】
通常プレーとトリックプレーの間の切り替えは、再生動作にいくつかの特別な影響を与える。実際の挙動は、制御ワードCWの利用可能性、従ってECM（資格制御メッセージ）の取り扱いと処理の方法に依存して変化する。
【０１９８】
次に図２１を参照しながら、トリックプレー・システム2100について説明する。
【０１９９】
トリックプレー・システム2100は、ストレージ装置2103、トリックプレー発生器2101、および受信器2102を含んでいる。ストレージ装置2103は、送信ストリーム2105として解読ユニット2106とトリックプレー発生器2101のスイッチユニット2108に供給され、再生されるべきデータを保存する。スイッチユニット2108は、通常プレー・モード(NP)とトリックプレー・モード(TP)の間を切り替える。望みのトリックプレーの速度に加えて、通常プレーまたはトリックプレーのどちらを選ぶかという情報が制御ユニット2109を通して選択的に入力される。この情報は制御ユニット2109からストレージ装置2103に供給される。制御ユニット2109は、ユーザー・インタフェースを通してユーザーによって制御される。
【０２００】
さらに、制御ユニット2109は、入力されたデータまたはコマンドをトリックプレー・ストリーム構成ユニット2107、およびECMメモリ・ユニット2112に供給する。ストレージ装置2103は送信ストリームを解読ユニット2106とスイッチユニット2108に送信するだけでなく、ECMファイル2104に保存されているECMデータをECMメモリ・ユニット2112にも供給する。ECMメモリ・ユニット2112は、制御ユニット2109からパラメータを受け取るのに加えて、トリックプレー・ストリーム構成ユニット2107とスマートカード・インタフェース・ユニット2111にECMデータを供給する。さらに、スマートカード・インタフェース・ユニット2111は、スマートカード2110と通信するように適応させられる。スマートカード2110は、制御ワードCWを生成し、制御ワードをスマートカード・インタフェース2111を通して解読ユニット2106に供給する。
【０２０１】
通常プレー・モードにおける、スイッチユニット2108のスイッチの位置を図２１に示す。この動作モードでは、送信ストリーム2105は受信ユニット2112に直接供給される。しかし、トリックプレー・モードが選択された時、スイッチは他の位置に移動し、その結果、送信ストリーム2105が、トリックプレー・データを受信器2102に、特に受信器2102の解読ユニット2113および受信器2102のECM抽出ユニット2116に供給するトリックプレー・ストリーム構成ユニット2107によって処理されるようになる。
【０２０２】
ECM抽出ユニット2116は、スマートカード2118と通信で結合されているスマートカード・インタフェース2117にECMを供給する。ECMに応じて、スマートカード・インタフェース2117は解読ユニット2113に解読情報として制御ワードCWを供給する。解読ユニット2113を通過した後、データはデコーダ/レンダラー・ユニット2114に渡され、さらにそこからデータ2115がディスプレイ・ユニット（図では表示されていない）に送られる。
【０２０３】
図２１に示されるように、特に考慮すべき2つの局面がある。第一は通常プレーとトリックプレーの間で切り替えられる信号を解読し、デコードし、表示する受信器2102に与える影響である。第二はトリックプレー発生器2101に関連する切り替えの影響である。
【０２０４】
以下、受信器2102について説明する。ここで説明されるテクニックにより生成されたトリックプレー・ストリームは平文のストリームである。この場合、受信器2102内ではトリックプレー・ストリームの解読は不要であり、MPEGの復号化はトリックプレーへの切り替え後、即座にスタートすることができる。
【０２０５】
以下、トリックプレー発生器2101について説明する。トリックプレー発生器2101は平文のIフレームを選択し、それからトリックプレー・ストリームを構築するためにストリームを解読する。このプロセスは、トリックプレーへの切り替え後、出来るだけ早くスタートさせる必要がある。とりわけ、ECMあたりの制御ワードCWの数がこれに影響する。この情報は、それが連続的なトリックプレーの発生のためにも必要であるため、既知のものと見なされる（たとえば、CPIファイルから得られる。図４と対応する説明を参照のこと）。
【０２０６】
以下、トリックプレーから通常プレーへの切り替えの特別なシナリオについて説明する。
【０２０７】
ここでは、トリックプレーから通常プレーへの切り替え時に生ずる特別な影響について説明する。ここで再び、トリックプレー発生器2101と受信器2102とは別ものとして取り扱われる。
【０２０８】
通常プレーへの切り替え時には、トリックプレー発生器2101は単純にその動作を停止する。そのため、このトリックプレー発生器に関連した特別な対処策は不要である。しかし、この後で説明されるように、トリックプレー発生器2101は特にこのポイントでいくつかの特別な行動をとることによって受信器2102内での切り替えの影響を改善することが可能である。
【０２０９】
暗号化された通常プレー・ストリームに切り替わる時、いくつかの特別な影響が受信器2102に発生する。2つの状態、すなわち受信器2102とトリックプレー発生器2102によって、個々の解読器が使用される場合と、1つの共通の解読器が使用される場合の2つを区別することは適切なことであろう。
【０２１０】
次に、個々の解読器を使用する場合のシナリオについて説明する。
【０２１１】
この状況は、受信器2102とトリックプレー発生器2101が、デジタル・バスを介して接続されている別々のボックス内にある場合に発生するが、この構成は両方とも同じボックス内にある時でも使用可能である（図２１）。以下、切り替えの問題といくつかのソリューションについて説明する。
【０２１２】
平文のトリックプレーから暗号化された通常プレー・ストリームへの切り替え時は、できるだけ早く正しい解読が開始する必要がある。平文のトリックプレー中はECMストリームが中断されるという事実により、ユーザーが再び通常プレーのビデオを見ることができるまでにはしばらく時間がかかる。この状況が、4倍の前方トリックプレー速度の場合に対して図２２に示されている。
【０２１３】
図２２は、AがテーブルID 0x80のECMを持つ期間に関連し、BがテーブルID 0x81のECMを持つ期間に関連する期間AおよびBの連続を示している。上側の列2200はブロックAとBのシーケンスを示す。また下側の列2201はトリックプレー部分2203を挟む2つの通常プレー部分2202を持つブロックAとBのシーケンスを示す。
【０２１４】
通常プレーへの切り替え後最初のECMはそのストリームから抽出できず、処理のためにスマートカードへ送られる。同じECMが繰り返して送られ、テーブルIDの0x80から0x81へ、またはその逆への切り替えは新しいECMへの変更があったことを示している。スマートカードへのトラフィックを制限するために、テーブルIDから検知された新しいシリーズの最初のECMのみがスマートカードに渡されるようにする。トリックプレー2203への切り替え前の最後に抽出されたECMと、通常プレー2202へ戻った後のストリーム内の最初のECMとが同じタイプ（どちらも0x80または0x81）であった場合、最初のECMは抽出および処理されない。
【０２１５】
図２２では、トリックプレーの前の最後のECMとトリックプレーの後の最初のECMが両方とも0x81のテーブルIDを持つBタイプである。追加の方策がない場合は、タイプが異なる（例の場合はA）次のECMに遭遇するまで待つことが要求されるが、この待ち時間はたとえば10秒間とかなり長い。この期間中は、正しい解読が行われないため、通常プレー・ストリーム2202のMPEG復号と画像表示も行われない。
【０２１６】
以下、上述の問題に対して考えられる4つのソリューションについて説明する。
【０２１７】
ソリューション1
トリックプレー2203から通常プレー2202への切り替え時間が長くなりすぎるのを防ぐ方法がある。第一のオプションは、受信STB内にECMに対するタイムアウト機能を導入することである。通常の状態では、ECM同士が大体800ms以上離れることはほとんどない。ストリーム内に数秒間にわたってECMが存在しなかった場合に、STBを最初に遭遇したECMをスマートカードに送る状態とすることができる。これにより、平文のトリックプレーの後に検出された最初のECMが処理されることが保証される。ストリーム・タイプIIの場合、スマートカードがビジーの時に遅延時間がさらに加わることがある。そのような場合、スマートカードがしばらくの間占有され、次のECMのタイムリーな処理が妨げられることになる。
【０２１８】
ソリューション2
トリックプレー発生器を含むストレージ装置に、通常プレー・ストリーム2202の最初のECMの使用を強制させることも可能である。
【０２１９】
この状況を図２３に示す。
【０２２０】
トリックプレー（たとえば高速前方再生）に切り替える前の最後のECMのタイプ(0x80または0x81)が記憶される。再び通常プレー2202に切り替える時、この最後のECMタイプが、通常プレー・ストリーム2202内の最初のECMのタイプと比較される。同じである場合は、通常プレー・ストリーム2202内の最初のECMのテーブルIDが別の値に変更され、受信器によってスマートカードに送られることを確実にする。矢印2300はテーブルIDが変更されることを示している。追加される切り替え遅延は上記のソリューション1と同じである。
【０２２１】
ソリューション3
この場合は、トリックプレー発生器が、切り替えコマンドが受信された瞬間にトリックプレー・ストリーム（たとえば高速前方再生）の最後にECMを追加する。トリックプレー発生器は、ECMファイルから、通常プレー・ストリーム2202の最初のECMが何であるかを知ることができる。次にこのECMを、記憶されたものと反対のテーブルIDは除いて、トリックプレー・ストリーム2203の最後に挿入する。
【０２２２】
図２４では、通常プレー・ストリーム2202の最初の部分のECMがタイプBであり、トリックプレーの前の最後に記憶されたECMのタイプもBである。そのため、トリックプレー・ストリーム2203の直後の通常プレー・ストリーム2202を解読するために必要なECMはECMファイルから取り出され、Aに変更されたテーブルIDは除いてトリックプレー・ストリーム2203の最後に挿入される。これにより、このECMが切り替えの瞬間の前にスマートカードに送られることが保証される。トリックプレー発生器は、スマートカードの遅延を補償するために、実際に通常プレー2202に切り替える0.5秒から1.0秒間、このECMの後に静止画像を挿入することができる。説明した例は高速前方再生の例であるが、このソリューションは高速後方再生の場合にも適用することができる。
【０２２３】
ソリューション4
4番目のオプションは、トリックプレー発生器によってECMをトリックプレー・ストリームの中に挿入させる方法である。受信器によるトリックプレー・データの処理は不要であるが、この方法が処理を妨げることもない。一方、ECMストリームを流したままにすることによりECMの中断が起きないようにすることができる。
【０２２４】
しかし、トリックプレー・ストリームに挿入されるべきECMはどれなのだろうか？第一の可能性は、トリックプレーにコピーされたばかりのオリジナルの暗号化されたIフレーム内に埋め込まれているECMである。これらのECMは順方向トリックプレーのために適切である。逆方向では、単なるECMの逆のシーケンスではないため、奇妙な影響が生ずる。Iフレームの期間中は、ECMは通常の順方向の順番であるが、Iフレームは逆の順番となっているからである。そのため、テーブルIDの切り替えを通して行ったり来たりを繰り返すことになり、スマートカードとのECMトラフィックが増加する。最大のトリックプレー速度では、スマートカードはこのトラフィックを処理できなくなる。その結果、通常プレーへの切り替え時に、必ず受信器内の解読器の状態を確定できるとは限らない。
【０２２５】
より論理的な可能性は、トリックプレー発生器がトリックプレーの生成のために用いられるECMを挿入することである。実際、それらはトリックプレー発生器の解読器へのストリーム内に既に挿入されている。そのため、それらを構築されたトリックプレー・ストリーム内に残したままにすることによって、この状況が生成される。それでは、通常プレーへの切り替え時に何が起きるだろうか？再び、順方向と逆方向との違いを認識する必要がある。
【０２２６】
次に、高速前方再生から通常プレーへの移行について議論する。
【０２２７】
高速前方再生から通常プレーへの移行の様子を図２５に示す。
【０２２８】
図２５は、高速前方トリックプレー・モード2500から通常プレー・モード2501への移行を示している（連続したデータ・ブロック2500間のジャンプが矢印2502で示されている）。特に図２５は、時点2504でECM C（CW CとCW D）がストリーム・タイプIのために送られ、ECM D（CW D）がストリーム・タイプIIのために送られること、および時点2505でECM D（CW DとCW E）がストリーム・タイプIのために送られ、ECM E（CW E）がストリーム・タイプIIのために送られることを示している。
【０２２９】
連続した順方向トリックプレーの間ECMを送ることは、解読器が現在の期間のためのCWを常に保持していることを意味する。次の期間に対するCWを保持するECMは、現在の期間に入る時に既にスマートカードへ送られている。このCWは、切り替えの瞬間にはまだスマートカード内にあるが、現在の期間の終了前に確実に利用される。通常プレーへの切り替え後に遭遇する最初のECMはトリックプレー・ストリーム内の最後のECMとは異なることもあれば、同じものであることもあるテーブルIDを持っている。これは制御ワードCWが1つか2つかに依存する。また、これはECMがスマートカードで処理されるか否かには無関係である。それは、どちらの場合でも解読器のレジスタの内容は変更されないからである。そのため、現在の期間のどこに切り替えポイントがあろうとも、受信器内の解読器は常に現在の期間のCWを保持しており、次の期間のCWはこの期間に入る前に必ず利用可能となる。従って、受信器内での通常プレー・ストリームの正しい解読は通常プレーへの切り替え後直ちに開始され、中断されることはない。
【０２３０】
次に、逆方向再生から通常プレーへの移行について議論する。
【０２３１】
逆方向再生から通常プレーへの移行の様子を図２６に示す。
【０２３２】
図２６は、逆方向トリックプレー・モードから通常プレー・モード2501への移行を示している（連続したデータ・ブロック2500間のジャンプが矢印2502で示されている）。特に図２６は、時点2600でECM Bが送られること、および時点2601でECM Cが送られることを示している。ストリーム・タイプIおよびストリーム・タイプに対する詳細は図２６内のテーブルから見ることができる。
【０２３３】
この場合、次の通常プレー期間のCWは、切り替えの瞬間には決して利用可能となっていない。受信器内の解読器は現在および次のトリックプレー期間のためのCWを保持しているが、これらは現在および前の通常プレー期間である。移行2503は現在の期間Cの中間のどこかで生ずると仮定しよう。移行の瞬間の前にSTBによって受信された最後のECMは、前の通常プレー期間のECM Bである。以降後に受信される最初のECMは、現在の期間のECM Cである。それは大体100ms以内に遭遇するだろう。このECMは前のECM Bとは異なるテーブルIDを持っているため、それはそのままスマートカードに送られ、処理される。そのため、正しい解読が直ちに開始される。しかし、この解読は、切り替えポイントが期間の終わりに近い場合は中断されることがある。
【０２３４】
ストリーム・タイプIは、期間の終わりにECMに1秒間に近いギャップを生ずることがある。この期間内の切り替えは、どのECMにも遭遇しないこと、およびECM Dが最後のトリックプレーECMの後の最初の通常プレーECM(ECM B)であることを意味している。ECM BとECM Dは同じテーブルIDを持っているため、ECM Dは処理されず、通常プレー・ストリームは全期間を通して中断されることがない。従って、そこへジャンプされる通常プレーのポイントは、少なくとも期間の最後、ECM内のギャップの前でなければならない。その切り替えポイントが期間の最後の1秒ないにある場合は、通常プレー・ストリーム内で少しだけジャンプして戻ることが適切である。ストリーム・タイプIIに対する影響はほとんど同じである。
【０２３５】
この場合、期間の最後の600msの間に、たとえばECM Dが送られる。そのため、この期間内で切り替えるということは、ここでもECM Cが失われて上記と同じ影響を与えることを意味している。実際、どちらの場合でも同じテクニックが適用可能である。
【０２３６】
上記の場合、考慮すべき局面がもう１つある。上述のように、現在の期間内で残っている通常プレー時間は、この期間のECMのアクセスを許可しなければならない。しかし、さらにこのECMが処理されることも保証する必要がある。しかし、特に高速のトリックプレーの場合は、スマートカードはまだECM Bの処理でビジー状態であることもあり得る。このビジーな期間中は、入ってくるECMをスマートカードに送ることができないため、ECMが廃棄される。それらが後での処理のためにバッファされるという保証はない。スマートカードが依然としてビジーである時間は、トリックプレーの速度と期間内の切り替えポイントの位置に依存する。しかし、どの場合でも、スマートカードの遅延時間を超えることはない。そのため、この遅延時間は上で議論した1秒のインターバルに追加される。一般に、通常プレーの開始点は逆方向再生から通常プレーへの切り替え時の、現在の期間の終了前、およそ2秒程度のポイントに位置づけられなければならない。
【０２３７】
以下、切り替え遅延に関連するいくつかの局面について説明する。
【０２３８】
通常プレー・ストリームのスタート時には、解読によって追加される切り替え遅延が導入される。上記ソリューション1および2の場合、この遅延時間は通常プレー・ストリーム内で最初にECMに遭遇するまでの時間とスマートカードの遅延時間の合計に等しい。
【０２３９】
ソリューション3の場合、静止画像の表示によって補償されるスマートカード遅延時間に等しいだけである。
【０２４０】
ソリューション4は、正しく実行されれば、切り替え遅延時間が導入されることはないが、逆方向再生から通常プレーに切り替えられた時に通常プレーのスタート位置に若干のずれが生ずる。
【０２４１】
次に、MPEGに関係した切り替えのさらなる最適化について説明する。
【０２４２】
できるだけ迅速に画像をスクリーン上に表示させるために、MPEG符号化に関連したある効果を利用する方法がある。通常プレー・ストリームの解読が即座に開始できると仮定すると、MPEGデコーダの最速の応答のためにはGOPの最初にジャンプするのが適切である。IフレームとPフレームから成るストリームの場合、復号化はGOPの最初のフレームであるIフレームからスタートし、このIフレームを参照するPフレームを用いて継続される。ストリームの中にBフレームも存在する場合には、送信されたストリーム内のフレームの順番の変更による問題が発生する（図３参照）。ストリームの中で遭遇する最初のBフレームは、最初に復号化されたIフレームでスタートしたディスプレイGOPに所属していない。実際には、それらは前のGOPに所属しており、このIフレームを参照しないだけでなく前に送られたPフレームも参照しない。このPフレームは、送られたGOPのスタート時点でリプレーがスタートする時に利用可能となっていない。これはこれらのBフレームの復号化のミスにつながり、通常プレー・ストリームのスタート時に画像の乱れを生ずる。実際、Bフレームを含んで送信されたMPEGストリームに対しては、理想的なエントリ・ポイントが存在しない。利用可能な最善のポイントはやはりIフレームの最初である。平文のストリームの場合は、IフレームとPフレームの間に位置する最初のBフレームを除去することによって通常プレー・ストリームの最初の部分をきれいにすることが可能である。しかしこれは、Bフレームがどこに位置しているかが分からない暗号化されたストリームの場合は不可能である。
【０２４３】
ストリーム・レベルでの移行をできるだけ連続的に行わせるためには、トリックプレー・データ・ブロックの読み出し、および関連するトリックプレーGOPの発生と送信は通常プレー・ストリームへのジャンプの前に終了していなければならない。このGOPがどこから始まるのかは、特に暗号化されたストリームの場合は不明である。しかし、場合によっては、トリックプレー発生器が最適な方法でそのジャンプ目標を決定することができる。GOPのスタート位置が不明の場合、MPEGに関する最適化はいかなる方法でも不可能である。一方、GOPのスタート位置をCPIファイルから知ることが出来る場合は、それらを可能性があるジャンプ目標として使用することができる。通常プレーをスタートさせる論理的なポイントは、切り替えコマンドが受信される前の最後のトリックプレーのジャンプ目標か、またはこのコマンドの後の最初の目標のいずれかである。
【０２４４】
上記ソリューション1および2の場合、通常プレー・ストリームの正しい解読をエントリ・ポイントで即座に開始することはできない。最初に、通常プレー・ストリーム自身のECMが抽出され、処理されなければならない。これは、トリックプレーのジャンプ目標が使用できないことを意味している。従って、一般的には、これらのソリューションは好まれない。
【０２４５】
ソリューション3は通常プレー・ストリームのスタートにつながるECMを常時送り続け、スマートカードの遅延時間だけ待ち合わせる。これは通常プレー・ストリームのスタート・ポイントとして任意のジャンプ目標を選ぶことができることを意味している。通常プレー・ストリームの正しい解読はこのポイントで即座に開始される。
【０２４６】
ソリューション4は解読の観点から見れば最小の切り替え遅延時間となっている。この場合、通常プレーは切り替えコマンドの前の最後のトリックプレー・ジャンプ目標でスタートさせるべきではない。何故なら、これはある状況では問題につながるからである。
【０２４７】
ここで、図２７のように、切り替えコマンドが受信された瞬間に、期間Bと期間Cの境界上に位置するデータ・ブロックの最後が到着すると仮定しよう。
【０２４８】
図２７は、高速前方トリックプレー・モード2500から通常プレー・モード2501への移行2503を示している（連続したデータ・ブロック2500間のジャンプが矢印2502で示されている）。特に図２７は、時点2700でECM D（CW D）がストリーム・タイプIIの場合に送られ、ECM D（CW D）がストリーム・タイプIIのために送られること、または時点2505でECM C（CW CとCW D）がストリーム・タイプIの場合に送られることを示している。
【０２４９】
CW Bを上書きするECMは、期間Cの初めのどこかの、SCBの切り替え1402が交叉した時点で既にスマートカードに送られている。期間B内にあるこれと同じブロックのスタートである最後のジャンプ目標からの通常プレー2501のスタートは、CW Bがもはや利用できなくなっているため、間違った解読につながる。一方、通常プレーが切り替えコマンド後の最初のジャンプ目標でスタートする場合は、この問題は発生しない。
【０２５０】
この例では、通常プレーのスタート・ポイント2503は期間C内に位置しており、これはCW Bが既に必要なくなっていることを意味している。そのため、ソリューション4の場合は、通常プレーは切り替えコマンド後の最初のジャンプ目標でスタートすることができる。
【０２５１】
逆方向再生から通常プレーへの切り替え時にも、ECMに関連するいくつかの問題が起こり得る。しかし、そのソリューションは同じであり、通常プレーは切り替えコマンド後の最初のジャンプ目標で開始される。既に議論したように、通常プレーのスタート・ポイントは、この場合には期間の終わりの部分に置かれるべきではない。予想される通常プレーのスタート・ポイントが期間の終わりに近すぎる場合は、特に次の2つの操作が考えられる。
・ ストリーム内のいくぶん早い時期で通常プレーのスタート・ポイントを選択する。このポイントはCPIファイルがあれば、その中の情報に基づいている。
・ 次のジャンプ目標がもはや期間の最後の部分に存在しなくなるまでトリックプレーを継続させる。次にスタート・ポイントと同じ目標を用いて通常プレーに切り替える。
【０２５２】
図２８にトリックプレー2502から通常プレー2501への最適化された切り替え方法を示す。
【０２５３】
図２８は、トリックプレー・モード2500から通常プレー・モード2501への移行を示している（連続したデータ・ブロック2500間のジャンプが矢印2502で示されている）。特に図２８は、時点2800でECM Cが送られ、時点2801でECM Bが送られ、時点2802でストリーム・タイプIIの場合はECM Dが送られるか、またはストリーム・タイプIの場合はECM Cが（CW E）が送られること、および時点2803でストリーム・タイプIIの場合はECM Eが送られるか、またはストリーム・タイプIの場合はECM Dが送られることを示している。
【０２５４】
図２８は、以下のように解読とMPEGの影響を考慮に入れて最適化された、トリックプレーから通常プレーへの切り替えの様子を示している。
・ 切り替えコマンドの受信時に、まず現在のトリックプレーGOPを終了させる。
・ 必要なら、逆方向トリックプレーを、次のジャンプ目標が期間の最後にある禁止期間の外に出るまで継続させる。
・ 次のトリックプレーのジャンプ目標で通常プレーをスタートさせる。
MPEGに関連して切り替えの最適化を行った結果として、切り替えの瞬間でのMPEGストリームの不連続性が大幅に低減される。第一の不連続性はPCRとDTS/PTSの中に見られる。これらの不連続性は、通常プレーからトリックプレーへの切り替え時には避けることができるが、トリックプレーにおいて圧縮された時間軸のために、通常プレーに戻す時には避けることができなくなっている。他の不連続性は連続性カウンタに見られる。実際のデコーダはこれらの不連続性のすべてに反応する。どの場合にも、できる限りこれらの不連続性が信号としてデコーダに伝えられることが望ましい。トリックプレー発生器とデコーダが同じボックスの中に入っていれば、これはかなり簡単であるが、そうでない場合はMPEG標準によって提供される可能性が用いられる。
【０２５５】
トリックプレーと通常プレー間の切り替え時に、ストリームに含まれるサービス情報(SI: Service Information)テーブルに関連する問題が生ずることもある。少なくともいくつかのテーブルが複数のパケットに分離されることは比較的頻繁に起きる。これはテーブルが部分的に受信または処理される時を切り替えることができることをも意味している。必須のテーブルPAT(Program Association Table)、CAT(Conditional Access Table)およびPMT(Program Map Table)はトリックプレー・エンジンによって生成され、トリックプレー・ストリームに埋め込まれる。その他のテーブルは、トリックプレー中は送信されない。
【０２５６】
トリックプレーへの切り替え時の不連続性は、トリックプレー・エンジンと通常プレー間の同期によってある程度避けることができる。通常プレーに戻る時は、トリックプレー・エンジンは不連続性がないことを保証することができない。PAT/CAT/PMTテーブルはトリックプレーGOPの中では完全である。トリックプレーGOPは通常プレーへの切り替えの前に完成しているため、トリックプレー・ストリームの終わりの時点で不完全なテーブルは存在しない。しかし、テーブルに関係して通常プレー・ストリーム内のどこにジャンプすべきかは不明である。そのため、切り替え後最初に遭遇したテーブルのパケットはテーブルの最後の部分しか含んでいないかも知れない。STBがこれにどう反応するかは分からないが、実際には、テーブルの解析のためにはテーブル・ヘッダーが必要であるため、そのようなパケットは放棄される。従って、上記の説明のように働くなら、実際的な問題はないであろう。
【０２５７】
実際には、PAT/CAT/PMT以外のすべてのテーブルは録画される部分的送信ストリーム(PTS)から除去されるべきであり、かつ、該当するすべてのSIデータを含むSIT（選択情報テーブル）とDIT（不連続情報テーブル）が挿入されなければならない。DITは切り替えのポイントで挿入され、不連続性の存在を信号で伝える。部分的TSを受け入れるボックスはそれが存在する時はDITの意味を理解していなければならない。DVBの規格では、部分的ビット・ストリームの不連続が発生した時は常に、PID 0x001E (DIT)に属する2つの送信ストリーム・パケットが送信ポイントで直接的に挿入され、かつその間には他のパケットは存在しないことが要求されている。最初のパケットは、"1"にセットされた不連続性フラグで満たされた184バイトの適合フィールドを持っている（独立の送信/ストレージ・ステージに導入された移行の連続に対するMPEG-2連続性計数制約条件との適合性を保証するために）。これらの送信パケットの2番目は"DIT"を含んでいる必要があり、かつ、"1"にセットされたそのようなフラグは持っていない。
【０２５８】
次に、共通の解読器を持った実施例について説明する。
【０２５９】
受信器およびトリックプレー発生器による共通の解読器の使用は、受信器とトリックプレー発生器が1つのボックスの中で結合されている場合に対応する。この解読器は、トリックプレー中はトリックプレー発生器によって、そして通常プレー時には受信器によって使用されるだけであるため共有違反は生じない。
【０２６０】
図２９は共通の解読器2106を用いたシステム2900を示す。ここではほとんどの構成要素が、図２１のシステム2100の対応する機能要素と同じ参照番号が付与されている。しかし、共通の解読器2106を持つシステム2900ではスイッチ2901が追加されている。
【０２６１】
切り替えの観点から、1つの共通解読器2106に対する状況は、同期化された2つの個別の解読器に対する状況と同じである。これは実は、2つの個別の解読器に対して以前に説明したソリューション4の場合である。ソリューション2と3も使用できるかも知れないが、共通解読器2106の場合は、トリックプレー中はECMトラフィックが中断されることはない。そのため、記録されたテーブルIDは、最後の通常プレーECMのそれではなく、特定のECMが切り替わる前に解読器に送られた最後のECMからのテーブルでなければならない。スマートカードがビジーであるとことによる問題は、切り替えの瞬間を選ぶことによって回避することができる。従って、2つの解読器について説明したことのほとんどがここでもあてはまる。
【０２６２】
以下、図３０を参照しながら、本発明の典型的な実施例による、暗号化されたデータ・ストリーム3001を処理するための装置3000について説明する。
【０２６３】
暗号化メッセージ、つまりECMは、暗号化されたデータ・ストリーム3001の各期間1403を暗号化するために供給されるが、各ECMは解読要素としての制御ワードCWを多数含んでいる。
【０２６４】
装置3000は、ECMあたりの制御ワードCWの数を検出するための検出ユニット3002を備えている。この数は、ストリーム・タイプIの場合は2であり、ストリーム・タイプIIの場合は１である。暗号化されたデータ・ストリーム3001は検出ユニット3002に入力される。
【０２６５】
装置3000はさらに、検出された数に基づいて、期間1403のシーケンスにECMを供給する位置を決定するための決定ユニット3003をも備えている。この目的のために、ECMあたりの制御ワードCWの数を検出して符号化した検出ユニット3002の出力が決定ユニット3003に供給される。さらに、決定ユニット3003には、暗号化されたデータ・ストリーム3001が入力され、決定ユニットはCWに従って、ECMを適切な位置に配置または挿入するために暗号化されたデータ・ストリームを一部変更する。
【０２６６】
（オリジナルの、または一部変更された）暗号化されたデータ・ストリームは、暗号化されたデータ・ストリームを解読する生成ユニット3004に入力されるか、または、再生ユニット3005上でトリックプレーを実行させるために、暗号化されたデータ・ストリーム3001からトリックプレー・ストリームを生成する。
【０２６７】
検出ユニット3002が、特定の期間1403に対応するECMが制御ワードCWを2つ含んでいる（ストリーム・タイプI）ことを検知した時、決定ユニット3003はゼロ・セグメント先行してECMを供給する。一方、検出ユニット3002が、ECMの制御ワードの数が1つであることを検知した時（ストリーム・タイプII）、決定ユニット3003は１セグメント先行してECMを供給する。
【０２６８】
以下、図３１を参照しながら、本発明の別の典型的な実施例による、暗号化されたデータ・ストリーム3101を処理するための装置3100について説明する。
【０２６９】
再び、暗号化メッセージであるECMが、暗号化されたデータ・ストリーム3101の各期間1403を解読するために供給される。
【０２７０】
装置3100は、トリックプレー再生モード（たとえば高速前方再生モード）から通常プレー再生モードへの切り替えを検出するための検出ユニット3102を備えている。ユーザーは、ユーザー・インタフェース3103を操作することによって、たとえば対応するボタンを押すことによってスイッチを動作させることができる。
【０２７１】
そのようなイベントにおいて、検出ユニット3102はこの情報を決定ユニット3104と生成ユニット3105に送る。
【０２７２】
決定ユニット3104は、トリックプレー再生モードの前の最後のECMと、通常プレー再生モード内の最初のECMの比較結果に基づいて、通常プレー再生モードの最初のECMがスマートカードに送られることを保証するように適応する。決定ユニット3104は、それによって暗号化されたデータ・ストリーム3101を一部変更する。
【０２７３】
さらに、生成ユニット3105は再生ユニット3106によって再生されるべきトリックプレー再生ストリームまたは通常プレー再生ストリームを選択的に生成することができる。この目的のために、生成ユニット3105は、暗号化されたデータ・ストリーム3101が供給され、かつ検出ユニット3102および/または決定ユニット3104から制御情報を受け取る。
【０２７４】
決定ユニット3104は、トリックプレー生成モードから通常プレー・モードへの切り替え時に再生の過剰な中断を回避するために、通常プレー再生モードにおける最初のECMが処理されるべきかどうかを決定するように適応される。
【０２７５】
用語「comprising（備える）」は他の要素またはステップを除外するものではないこと、および「a」または「an」は複数を除外しないことに注意する必要がある。また、異なった実施例に関連して説明される要素は組み合わされる。
【０２７６】
請求項内の参照記号は、請求項の目的を制限するものと解釈すべきでないことにも注意する必要がある。
【図面の簡単な説明】
【０２７７】
以下、実施例を参照しながら本発明の詳細な説明を行うが、本発明は必ずしもこの実施例に限定されることはない。
【図１】タイムスタンプつきの送信ストリーム・パケットを示す。
【図２】イントラ・コーデッド・フレームと前方予測フレームを持つMPEG2グループ画像の構成を示す。
【図３】イントラ・コーデッド・フレーム、前方予測フレーム、および双方向予測フレームを持つMPEG2グループ画像の構成を示す。
【図４】特定ポイントの情報ファイルと保存されたストリーム・コンテントの構成を示す。
【図５】平文ストリーム上でのトリックプレーのシステムを示す。
【図６】トリックプレーにおける時間圧縮を示す。
【図７】非整数の距離でのトリックプレーを示す。
【図８】低速トリックプレーを示す。
【図９】一般的な条件つきアクセス・システムの構成を示す。
【図１０】デジタル・ビデオ放送の暗号化された送信ストリーム・パケットを示す。
【図１１】図１０のデジタル・ビデオ放送の暗号化された送信ストリーム・パケットの送信ストリーム・パケット・ヘッダーを示す。
【図１２】完全に暗号化されたストリーム上でトリックプレーの実行を可能とするシステムを示す。
【図１３】完全な送信ストリームと部分的な送信ストリームを示す。
【図１４】ストリーム・タイプI、およびストリーム・タイプIIに対する資格制御メッセージECMを示す。
【図１５】解読器への書き込み制御ワードCWを示す。
【図１６】高速前方再生モードにおけるECMの取り扱いを示す。
【図１７】1つまたは2つの制御ワードの検出を示す。
【図１８】2つのスクランブル制御ビットの切り替えにまたがるジャンプを示す。
【図１９】高速前方トリックプレー再生モードにおけるECMの取り扱いを示す。
【図２０】中速前方トリックプレー再生モードにおけるECMの取り扱いを示す。
【図２１】本発明の典型的実施例によるトリックプレー発生器と受信器の構成を示す。
【図２２】トリックプレー再生中のECMの中断を示す。
【図２３】最初の通常プレーECMのテーブルIDの変更を示す。
【図２４】トリックプレーの最後にECMが追加された状態を示す。
【図２５】高速前方トリックプレー・モードから通常プレー・モードへの切り替えを示す。
【図２６】逆方向トリックプレー・モードからから通常プレー・モードへの切り替えを示す。
【図２７】高速前方再生モードから通常プレー・モードへの切り替えを示す。
【図２８】トリックプレー・モードから通常プレー・モードへのの最適化された切り替えを示す。
【図２９】トリックプレー発生器および受信器のための一般的な解読器の構成を示す。
【図３０】本発明の典型的実施例による、暗号化されたデータ・ストリームを処理するための装置の構成を示す。
【図３１】本発明の別の典型的実施例による、暗号化されたデータ・ストリームを処理するための別の装置の構成を示す。
【図３２】ECMファイルの例を示す。
【符号の説明】
【０２７８】
100  送信ストリーム・パケット
101  タイムスタンプ
102  トリックプレー発生器
103   パケット・ペイロード
104  188バイトの全長
105  ４バイトの長さ
201  Iフレーム
202  Pフレーム
203  GOPサイズ
204  曲線矢印
301  Bフレーム
302  直線矢印
400  CPIファイル
401  保存される情報
500  トリックプレー・システム
501   録画ユニット
502   Iフレーム選択ユニット
503   トリックプレー発生ブロック
504   MPEG2デコーダ
505   解析ユニット
506   追加ユニット
507   パケタイザ・ユニット
508   テーブル・メモリ・ユニット
509   マルチプレクサ
510   MPEG2データ
511   MPEG2 DVB適合の送信ストリーム
700  矢印
900  条件つきアクセス・システム
901  放送されるコンテント
902  コンテント暗号化ユニット
903  暗号化されたコンテント
904  コンテント解読ユニット
905  スマートカード
906  制御ワード
907  ECM生成ユニット
908  ECM復号ユニット
909  制御ワード
910  権限キー(AK)
911  KMM生成ユニット
912  KMM復号ユニット
913  資格リスト・ユニット
914  グループ・キー
915  GKM生成ユニット
916  GKM復号ユニット
917  ユーザー・キー
918  ユーザー・キー
919  資格
920  EMM生成ユニット
921  EMM復号ユニット
1000  ストリーム・パケット
1001  バイトの長さ
1002  パケット・ヘッダー
1003  4バイトのサイズ
1004  適合フィールド
1005  DVBパケット・ペイロード
1010  同期ユニット(SYNC)
1011  送信エラー・インジケータ
1012  ペイロード・ユニット・スタート・インジケータ(PLUSI)
1013  パケット識別子(PID)
1014  送信スクランブル・コントロール(SCB)
1015  適合フィールド・コントロール
1016  連続性カウンタ(CC)
1017  送信優先順位ユニット(TPI)
1200  トリックプレー構築システム
1201  ハードディスク
1202  送信ストリーム
1203  解読器
1204  スマートカード
1205  フィルター
1206  Pフレーム挿入ユニット
1207  セットトップボックス
1208  テレビ
1300  部分的送信ストリーム
1301  完全な送信ストリーム
1400  データ・ストリーム
1401  データ・ストリーム
1402  切り替え
1403  期間
1500  スマートカードの遅延時間
1501,1502  レジスタ
1600  データ・ブロック
1601  切り替え
1700  暗号化されたコンテント
1701  解読されたコンテント
1702  PESヘッダー
1703  期間Bの領域
1900  ECM Aが送られる時点
1901  ECM Bが送られる時点
2000  ECM Cが送られる時点（ストリーム・タイプIの場合）、ECM Dが送られる時点（ストリーム・タイプIIの場合）、
2001  ECM Bが送られる時点（ストリーム・タイプIの場合）、ECM Cが送られる時点（ストリーム・タイプIIの場合）、
2100  トリックプレー・システム
2101  トリックプレー発生器
2102  受信器
2103  ストレージ装置
2104  ECMファイル
2105  送信ストリーム
2106  解読器
2107  トリックプレー・ストリーム構成ユニット
2108  スイッチユニット
2109  制御ユニット
2110  スマートカード
2111  スマートカード・インタフェース
2112  受信ユニット
2113  解読ユニット
2114  デコーダ/レンダラー・ユニット
2115  データ
2116   ECM抽出ユニット
2117  スマートカード・インタフェース
2118  スマートカード
2200,2201  ブロックAとBのシーケンス
2202  通常プレー部分
2203  トリックプレー部分
2300  テーブルIDが変更されることを示す矢印
2500  高速前方トリックプレー・モード
2501  通常プレー・モード
2502  連続したデータ・ブロック間のジャンプ
2503  トリックプレーから通常プレーへの移行
2504  ECM C（CW CとCW D）がストリーム・タイプIのために送られ、ECM D（CW D）がストリーム・タイプIIのために送られる時点
2505  ECM D（CW DとCW E）がストリーム・タイプIのために送られ、ECM E（CW E）がストリーム・タイプIIのために送られる時点
2600  ECM Bが送られる時点
2601  ECM Cが送られる時点
2700  ECM D（CW D）がストリーム・タイプIIの場合に送られるか、またはECM C（CW CとCW D）がストリーム・タイプIの場合に送られる時点
2800  ECM Cが送られる時点
2801  ECM Bが送られる時点
2802  ストリーム・タイプIIの場合はECM Dが送られるか、またはストリーム・タイプIの場合はECM Cが（CW E）が送られる時点
2803  ストリーム・タイプIIの場合はECM Eが送られるか、またはストリーム・タイプIの場合はECM Dが送られる時点
2900  共通の解読器を用いたシステム
2901  スイッチ
3000  暗号化されたデータ・ストリームを処理するための装置
3001  暗号化されたデータ・ストリーム
3002  検出ユニット
3003  決定ユニット
3004  生成ユニット
3005  再生ユニット
3100  暗号化されたデータ・ストリームを処理するための装置
3101  暗号化されたデータ・ストリーム
3102  検出ユニット
3103  ユーザー・インタフェース
3104  決定ユニット
3105  生成ユニット
3106  再生ユニット
【図１】
2008539640.tif 000007
【図２】
2008539640.tif 000008
【図３】
2008539640.tif 000009
【図４】
2008539640.tif 000010
【図５】
2008539640.tif 000011
【図６】
2008539640.tif 000012
【図７】
2008539640.tif 000013
【図８】
2008539640.tif 000014
【図９】
2008539640.tif 000015
【図１０】
2008539640.tif 000016
【図１１】
2008539640.tif 000017
【図１２】
2008539640.tif 000018
【図１３】
2008539640.tif 000019
【図１４】
2008539640.tif 000020
【図１５】
2008539640.tif 000021
【図１６】
2008539640.tif 000022
【図１７】
2008539640.tif 000023
【図１８】
2008539640.tif 000024
【図１９】
2008539640.tif 000025
【図２０】
2008539640.tif 000026
【図２１】
2008539640.tif 000027
【図２２】
2008539640.tif 000028
【図２３】
2008539640.tif 000029
【図２４】
2008539640.tif 000030
【図２５】
2008539640.tif 000031
【図２６】
2008539640.tif 000032
【図２７】
2008539640.tif 000033
【図２８】
2008539640.tif 000034
【図２９】
2008539640.tif 000035
【図３０】
2008539640.tif 000036
【図３１】
2008539640.tif 000037
【図３２】
2008539640.tif 000038
【国際調査報告】
2008539640.tif 000039
2008539640.tif 000040
2008539640.tif 000041
2008539640.tif 000042
2008539640.tif 000043