デジタルコンテンツ受信機及びデジタルコンテンツ受信方法
【課題】ＩＥＥＥ１３９４ネットワーク上で柔軟性の高い分散型ＡＶネットワーク環境を実現するデジタルコンテンツ受信機及びデジタルコンテンツ受信方法を提供する。
【解決手段】 スクランブルされたデジタルコンテンツ信号を受信手段で受信し、ＩＥＥＥ１３９４ネットワークに接続される限定受信サブユニットにおいて、上記受信されたスクランブルデジタルコンテンツ信号をデスクランブルして、デジタルコンテンツ信号を生成しローカルスクランブルして、ローカルスクランブルデジタルコンテンツ信号を生成する。上記受信手段において、上記ローカルスクランブルデジタルコンテンツ信号をローカルデスクランブルして、デジタルコンテンツ信号を生成する。上記限定受信サブユニットは、同時に複数の個別のストリーム又はサービスをデスクランブルする。
【解決手段】 スクランブルされたデジタルコンテンツ信号を受信手段で受信し、ＩＥＥＥ１３９４ネットワークに接続される限定受信サブユニットにおいて、上記受信されたスクランブルデジタルコンテンツ信号をデスクランブルして、デジタルコンテンツ信号を生成しローカルスクランブルして、ローカルスクランブルデジタルコンテンツ信号を生成する。上記受信手段において、上記ローカルスクランブルデジタルコンテンツ信号をローカルデスクランブルして、デジタルコンテンツ信号を生成する。上記限定受信サブユニットは、同時に複数の個別のストリーム又はサービスをデスクランブルする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続された限定受信モジュール（conditional access module）及び限定受信モジュールをネットワーク上で実現する方法に関する。詳しくは、本発明は、ＩＥＥＥ１３９４ネットワークに限定受信サブユニット（conditional access subunit）を提供するデジタルコンテンツ受信機及びデジタルコンテンツ受信方法に関する。
【背景技術】
【０００２】
デジタルマルチメディアの進歩、特にデジタルテレビジョンの進歩に伴い、限定受信モジュール（conditional access module）が提案されている。デジタルビデオ信号処理の分野では、ビデオ信号はコード化され、受信機においてビデオ信号を再生するためには特別な処理が必要である。特に、デスクランブル（スクランブル解除）処理を実行するとともに、デジタルテレビジョン受像機におけるその他の限定受信機能を提供する限定受信モジュールが提案されている。限定受信モジュールは、限定受信を実現するとともに、ホスト受信機から分離された信号のデコード処理を実行し、これにより、汎用デジタルテレビジョン受像機は、異なる限定受信モジュールを用いて異なる限定受信を行うことができる。
【０００３】
限定受信モジュールとテレビジョン受像機との間の通信を実現するための共通インタフェースが提案され、ＣＥＮＥＬＥＣ（限定受信及びその他のデジタルビデオ放送デコーダアプリケーションのための共通インタフェース仕様書ＥＮ５０２１１（EN50221 Common Interface Specification for Conditional Access and other Digital Video Broadcasting Decoder Applications））により標準化されている。この標準共通インタフェースは、様々な仮想チャンネルが時分割多重化されたトランスポートストリームインタフェースと、様々な追加的コマンドデータが送信されるコマンドインタフェースとを定義している。したがって、この共通インタフェースにより、限定受信モジュールは、デジタルテレビジョン受像機、あるいは実際にはその他のあらゆるデジタルビデオ機器に接続することができる。
【０００４】
本発明の基礎的背景として、オーディオ機器及びビデオ機器を含むデジタルマルチメディア機器のローカルネットワーク上で限定受信モジュールを実現し、ネットワーク上の全ての機器に限定受信モジュールの機能を利用できる技術が求められている。
【０００５】
様々なデジタルビデオ機器をローカルネットワークに接続する標準技術が提案されている。例えば、ＩＥＥＥ１３９４規格（１９９５年版）は、高速シリアルバス用のＩＥＥＥ標準技術として知られている。ＩＥＥＥ１３９４規格（１９９５年版）は、様々な民生用デジタルオーディオ／ビジュアル機器を相互接続する、ＩＥＥＥ１３９４シリアルバスと呼ばれるバスを提供する。
【０００６】
ＩＥＥＥ１３９４仕様書では、物理的リンクコネクタ、電気的信号及びシリアルバスを自己環境設定でき、オーディオ信号、ビデオ信号及び制御情報を効率的に搬送できるリンクプロトコルとトランザクションプロトコルのセットを定義している。さらに、ＩＥＥＥ１３９４シリアルバス上の設備内の異なるアイテム間でＭＰＥＧデータを搬送し、制御機構を提供する更なるプロトコルのセットが定義されている。これらのプロトコルは、「ＩＥＣ６１８８３民生用電子オーディオ／ビデオ機器のためのデジタルインタフェース（Digital Interface for Consumer Electronic Audio/Video Equipment(IEC61833)）」仕様書に定義されている。
【０００７】
ＩＥＣ１６８３３仕様書に基づき、幾つかのコマンドプロトコルが使用できる。ＩＥＥＥ１３９４取引協会（IEEE1394 trade association）により発表されたオーディオ／ビデオ制御デジタルインタフェースコマンドセット文書（AV/C Digital Interface Command Set Document）において、オーディオ／ビデオ制御コマンドトランザクション（audio/video control command transaction：以下、ＡＶ／Ｃ−ＣＴＳという。）が定義されている（１９９７年３月２６日、ＩＥＥＥ１３９４取引協会オーディオ／ビデオワーキンググループ発行、オーディオ／ビデオ制御デジタルインタフェースコマンドセットバーション２．０Ｄ（AV/C Digital Interface Command Set Version 2.0D））。ＡＶ／Ｃ−ＣＴＳは、民生用Ａ／Ｖ機器及び業務用Ａ／Ｖ機器のためのコマンドセットを定義している。ＡＶ／Ｃ−ＣＴＳコマンドは、ＩＥＣ６１８８３により定義されているファンクションコントロールプロトコル（function control protocol：以下、ＦＰＣという。）のパケットフォーマットにより搬送される。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開平０９−３２６８１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、ＩＥＥＥ１３９４ネットワーク上で柔軟性の高い分散型ＡＶネットワーク環境を実現するデジタルコンテンツ受信機及びデジタルコンテンツ受信方法を提供することである。
【課題を解決するための手段】
【００１０】
本発明は、デジタルコンテンツ受信機であって、スクランブルされたデジタルコンテンツ信号を受信する受信手段と、上記受信手段により受信された上記スクランブルされたデジタルコンテンツ信号を限定受信サブユニットに出力するとともに、該限定受信サブユニットからローカルスクランブルデジタルコンテンツ信号を入力するインタフェース手段と、上記限定受信サブユニットから入力された上記ローカルスクランブルデジタルコンテンツ信号をローカルデスクランブルして、デジタルコンテンツ信号を生成するローカルデスクランブル手段とを備え、上記限定受信サブユニットから入力されるローカルスクランブルデジタルコンテンツ信号は、該限定受信サブユニットにおいて、上記受信されたスクランブルされたデジタルコンテンツ信号をデスクランブルし、更に、ローカルスクランブルした信号であり、上記限定受信サブユニットは、同時に複数の個別のストリーム又はサービスをデスクランブルすることを特徴とする。
【００１１】
また、本発明に係るデジタルコンテンツ受信機は、当該デジタルコンテンツ受信機が認証されたときだけ、上記ローカルスクランブルデジタルコンテンツ信号をローカルデスクランブルするものとすることができる。
【００１２】
さらに、本発明に係るデジタルコンテンツ受信機において、上記限定受信サブユニットは、該限定受信サブユニット内に格納されている権限管理メッセージを更新するのに十分な期間、上記受信手段から上記スクランブルされたデジタルコンテンツ信号を受信するものとすることができる。
【００１３】
本発明は、デジタルコンテンツ受信方法であって、スクランブルされたデジタルコンテンツ信号を受信手段で受信するステップと、上記受信されたスクランブルされたデジタルコンテンツ信号を限定受信サブユニットに出力するステップと、上記限定受信サブユニットにおいて、上記スクランブルされたデジタルコンテンツ信号をデスクランブルして、デジタルコンテンツ信号を生成し、該生成されたデジタルコンテンツ信号をローカルスクランブルして、ローカルスクランブルデジタルコンテンツ信号を生成するステップと、上記限定受信サブユニットからローカルスクランブルデジタルコンテンツ信号を上記受信手段に入力するステップと、上記受信手段において、上記入力されたローカルスクランブルデジタルコンテンツ信号をローカルデスクランブルして、デジタルコンテンツ信号を生成するステップとを有し、上記限定受信サブユニットから入力されるローカルスクランブルデジタルコンテンツ信号は、該限定受信サブユニットにおいて、上記受信されたスクランブルされたデジタルコンテンツ信号をデスクランブルし、更に、ローカルスクランブルした信号であり、上記限定受信サブユニットにおいて、同時に複数の個別のストリーム又はサービスをデスクランブルすることを特徴とする。
【発明の効果】
【００１４】
本発明によれば、限定受信サブユニットにより同時に複数の個別のストリーム又はサービスをデスクランブルすることにより、柔軟性の高い分散型ＡＶネットワーク環境を実現することができる。
【図面の簡単な説明】
【００１５】
【図１】Ｆｉｇ．１は、ＣＡサブユニットを示す図である。
【図２】Ｆｉｇ．２は、ＣＡサブユニットの論理的接続を示す図である。
【図３】Ｆｉｇ．３は、ＣＡサブユニット識別子記述子を示す図である。
【図４】Ｆｉｇ．４は、Ｆｉｇ．３に示す記述子とともに用いる方式の仕様を示す図である。
【図５】Ｆｉｇ．５（ａ）は、ＣＡ状態記述子を示す図である。
【図６】Ｆｉｇ．５（ｂ）は、ＣＡサブユニット状態領域情報ブロックを示す図である。
【図７】Ｆｉｇ．５（ｃ）は、供給源プラグ状態領域情報ブロックを示す図である。
【図８】Ｆｉｇ．５（ｄ）は、プラグ状態情報ブロックを示す図である。
【図９】Ｆｉｇ．６は、ＣＡサブユニットコマンドを示す図である。
【図１０】Ｆｉｇ．７（ａ）は、ＣＡイネーブル制御コマンドを示す図である。
【図１１】Ｆｉｇ．７（ｂ）は、Ｆｉｇ．７（ａ）に示す放送方式固有のデータを詳細に示す図である。
【図１２】Ｆｉｇ．７（ｃ）は、Ｆｉｇ．７（ｂ）に示すエレメンタリＰＩＤの定義を示す図である。
【図１３】Ｆｉｇ．８（ａ）は、ＣＡイネーブル応答を示す図である。
【図１４】Ｆｉｇ．８（ｂ）は、Ｆｉｇ．８（ａ）に示す放送方式固有のデータを詳細に示す図である。
【図１５】Ｆｉｇ．９は、状態又は通知コマンドのデータ構造を示す図である。
【図１６】Ｆｉｇ．１０は、状態又は通知応答のデータ構造を示す図である。
【図１７】Ｆｉｇ．１１（ａ）は、ＣＡ権限コマンドを示す図である。
【図１８】Ｆｉｇ．１１（ｂ）は、Ｆｉｇ．１１（ａ）に示す放送方式固有のデータを詳細に示す図である。
【図１９】Ｆｉｇ．１２（ａ）は、ＣＡ権限応答を示す図である。
【図２０】Ｆｉｇ．１２（ｂ）は、Ｆｉｇ．１２（ａ）に示す放送方式固有のデータを詳細に示す図である。
【図２１】Ｆｉｇ．１３は、セキュリティ制御コマンドを示す図である。
【図２２】Ｆｉｇ．１４は、コントローラとＣＡサブユニットとの間のコマンドの交換を説明する図である。
【図２３】Ｆｉｇ．１５は、ネットワーク限定受信モジュールに接続された衛星放送ＩＲＤを示す図である。
【発明を実施するための形態】
【００１６】
本発明は、以下の詳細な説明により、より明瞭に理解される。以下の説明では、添付の図面を用いるが、ここで説明する実施の形態は、例示的なものである。
【００１７】
複数の放送業者からのスクランブルされた放送サービスにアクセスするデジタルテレビジョン受像機（digital television receiver：以下、ＤＴＶという。）には、限定受信（conditional access：以下、ＣＡともいう。）システムが必要となる。すなわち、ＤＴＶに接続可能なモジュール内にＣＡシステムを実現するためのプロトコルを定義することにより、ＤＴＶは、サービスにアクセスすることができる。このソリューションは、例えば、単一の受像機に接続されたＰＣカードの形式で実現できる。しかしながら、ネットワーク化された限定受信モジュール（networked conditional access module：以下、ＮＣＡＭという。）の実現が望まれている。ＮＣＡＭの主な要求は、以下のとおりである。
・フォームファクタ（form factor）の柔軟性
・アクセスの柔軟性、例えばピアツーピア通信（peer to peer communication）
・ロケーションの柔軟性
【００１８】
本発明は、ＮＣＡＭを実現するために必要な追加的なＡＶ／Ｃサブユニットのフォーマットを提案する。このＮＣＡＭ用のＡＶ／Ｃモデルは、ＩＥＥＥ１３９４規格（１９９５年版）に準拠するデジタルネットワークにおいて使用できるように設計されたＣＡシステムを提供する。
【００１９】
ＮＣＡＭの目的は、限定受信機能を提供することである。ＮＣＡＭは、選択されたサービスをデスクランブルするためのリソースの論理的集合体（logical collection）を使用する。ＮＣＡＭに必要なリソースは、例えばＤＴＶ内等の１つのロケーションに存在していてもよく、あるいはインホームデジタルネットワーク（in home digital network：以下、ＩＨＤＮという。）等のネットワークにおいて分散されていてもよい。
【００２０】
ＮＣＡＭは、既存のサブユニットと追加的サブユニット（additional subunit）の両方を利用する。ＮＣＡＭが利用する既存のサブユニットは、以下のとおりである。
【００２１】
・チューナサブユニット
・パネルサブユニット
ＩＥＥＥ１３９４ネットワーク上でＮＣＡＭを実現するために、限定受信モジュールのためのＡＶ／Ｃサブユニットを定義する。限定受信サブユニット（以下、ＣＡサブユニットという。）は、デスクランブラの中心的な機能を担う。ＣＡサブユニットは、スクランブルされたストリームを受信し、それらをデスクランブルし、デスクランブルされたストリームを出力する。ＣＡサブユニットは、ＩＥＥＥ１３９４ネットワークを介して、非同期コマンドにより他の必要なサブユニットと通信を行う。
【００２２】
チューナサブユニット（tuner subunit）は、データ源として用いられ、パネルサブユニット（panel subunit）は、ユーザに情報を提供し、及びユーザに情報を入力させるために用いられる。ＣＡサブユニットは、デスクランブル機能を有し、スマートカードやモデムサブユニットを利用できる。
【００２３】
ＮＣＡＭが機能するために必要なリソースは、単一のモジュール内に個別に（privately）実現することもできる。また、製造業者がスマートカードによりＮＣＡＭを実現する場合、モデム機能とＮＣＡＭの専用機能とを統合することができる。このような場合、ＮＣＡＭはＣＡサブユニットのみから構成され、他の機器のチューナサブユニット及びパネルサブユニットを利用することとなる。安全性の観点からは、ＮＣＡＭを独立したスマートカードにより実現することが望ましい。スマートカードが、例えばデータカード又は電子通貨（electronic cash）等の他のアプリケーションとしても使用される場合でも、そのようなスマートカードにＣＡサブユニットを含ませることもできる。
【００２４】
ＮＣＡＭは、分散されたリソースに亘って実現することもできる。この場合、ＣＡサブユニットは、デジタルネットワークの各所に分散された他のオブジェクトが実装するサブユニットと連携して機能することとなる。
【００２５】
デスクランブルするサービスに応じて、全てのリソース又はリソースの一部が必要となる。サービスを認証するために挿入されるスマートカードを用いた単純なシステムでは、モデムは必要なく、ユーザにカードの挿入を促すための単純な表示装置を設ければよい。このとき、ユーザとの相互作用（インタラクション）は必ずしも必要ではない。より複雑なシステム、例えばペイパービュー（pay per view：以下、ＰＰＶという。）では、選択可能なサービスをユーザに提示し、ユーザによる選択操作を実現するための全てのリソースが必要となる。すなわち、必要なサブユニットの全てが設けられていない場合は、ＮＣＡＭの機能は制限される。
【００２６】
Ｆｉｇ．１は、基本的なＣＡサブユニット２の構造を示す図である。このＣＡサブユニット２は、スタンドアロン機器（stand alone device）であってもよく、他の機器に組み込まれたものであってもよい。
【００２７】
ＣＡサブユニット供給先プラグ（CA subunit destination plug）４は、ＣＡサブユニット２への入力信号が入力される。この入力信号のフォーマットは、ＣＡサブユニット２によりサポートされている方式に準拠するものである。ＣＡサブユニット供給先プラグ４は、シリアルバス（１３９４）入力プラグに直接接続してもよく、あるいは、例えばチューナサブユニット等の他の適切なサブユニットの供給源プラグに接続してもよい。
【００２８】
ＣＡサブユニット供給源プラグ（CA subunit source plug）６からは、ＣＡサブユニット２の出力信号が出力される。この出力信号のフォーマットは、ＣＡサブユニット２によりサポートされている方式に準拠するものである。ＣＡサブユニット供給源プラグ６は、シリアルバス出力プラグに直接接続してもよく、あるいは、他の適切なサブユニットの供給先プラグに接続してもよい。
【００２９】
単一の供給源及び供給先プラグを実装するＣＡサブユニットは、ＣＡ方式がソースマテリアルと互換性を有する場合、単一のデータ源から供給される１つのアイソクロノスチャンネルにおける１つ以上のサービスをデスクランブルする能力を有する。
【００３０】
ＣＡサブユニットのハードウェア能力に応じて、ＣＡサブユニットには、複数の供給先プラグ及び供給源プラグを設けることができる。供給先プラグと供給源プラグの数は一致する。このように構成されたＣＡサブユニットによれば、同時に複数の個別のストリーム又はサービスをデスクランブルすることができる。このモデルにより柔軟性の高い分散型ＡＶネットワーク環境を実現できる。
【００３１】
換言すれば、ＣＡサブユニットは、ネットワーク上の１つ以上の他のサブユニットから異なるストリームを受信し、これらのストリームをデスクランブルし、必要に応じて１つ以上の他のサブユニットに送ることができる。ここで、制約の要素となるのは、原理的には伝送帯域幅のみである。
【００３２】
ＣＡサブユニット供給先プラグと、シリアルバス入力プラグ又は他のサブユニットの接続は、CONNECTコマンドを用いて手動で確立される。この接続は、ＣＡコマンドを送信する以前に確立される。ＣＡサブユニットがスタンドアロンモードで動作している場合、供給先プラグ及び供給源プラグは、シリアルバスの入力プラグ及び出力プラグに持続的に接続される。
【００３３】
ＣＡサブユニットが既にロックされた接続先を有し、さらに追加的な接続が要求された場合、その要求に対する応答として、REJECTED（拒絶）が返される。接続が永続性を有する場合、矛盾を生じるコマンドに対する応答として、NOT IMPLEMENTED（実行されない）が返される。
【００３４】
CONNECTコマンドは、ＣＡサブユニットを他のサブユニット又はバス出力プラグに接続するために使用される。
【００３５】
ＣＡサブユニットの現在の接続状態は、CONNECT状態、又はCONNECTIONS状態コマンドにより報告される。この状態には永続的な接続も含まれる。コントローラは、CONNECT状態又はCONNECTIONS状態コマンドの応答におけるpermフラグを検査することにより、接続が永続的なものであるか否かを判定することができる。
【００３６】
ＣＡサブユニットと他のサブユニットとの接続は、実行形態に応じて決定される。ＣＡサブユニットと他のサブユニットとの接続を許可することが論理的であるか否かについては、実行時（implementation time）において判定される。
【００３７】
ＣＡサブユニットは、受信機に組み込んでもよい。ここで受信機とは、チューナサブユニットを備えるものでもよく、スタンドアロン機器であってもよい。Ｆｉｇ．２は、ＣＡサブユニット２を受信機８内に組み込んだ状態を示す。受信機８は、スタンドアロン機器であり、アンテナ入力プラグはなくてもよい（シリアルバス入力プラグのみでもよく、外部入力プラグを設けてもよい）。
【００３８】
以下の表は、受信機ユニットとＣＡサブユニットプラグ間の接続の様々な組み合わせ、各組み合わせが有効であるか無効であるかを示す表である。接続が無効な場合、NOT IMPLEMENTEDが返される。
【００３９】
【表１】
【００４０】
CONNECTコマンドを発生する場合、ロックビットを用いて、第三者（third parties）により接続が切断されないように保証する。
【００４１】
ＣＡサブユニットは、トランスポートストリームの全体及びトランスポートストリームの一部の両方を取り扱うことができる。データ源側にとって、バスの帯域幅を節減するために、デスクランブルするサービスの要素を含むパーシャルトランスポートストリーム（partial transport stream）を生成する方が有利である。この場合パーシャルトランスポートストリームが生成され、及び権限管理メッセージ（entitlement management message：以下、ＥＭＭという。）がトランスポートストリームに組み込まれる。すなわち、データ源側が部分的トランスポートストリームにＥＭＭを組み込む。このような場合、データにＥＭＭが組み込まれていなければ、ＣＡサブユニットは、所望のサービスをデスクランブルすることができない。
【００４２】
ＣＡシステムは、許可されていない（unauthorised）放送マテリアルへのアクセスを禁止する機能を有する。マテリアルが一旦デスクランブルされた後も、ＩＨＤＮ上を伝送する際に、マテリアルを保護することができる。特に、ＣＡサブユニットは、供給先プラグ及び供給源プラグの両方において、適切なコピー防止システムを実装することができる。
【００４３】
ＣＡサブユニットにはサブユニット識別子が与えられる。各特定のＣＡサブユニットに対し、サブユニット識別子は、そのＣＡサブユニットによりサポートされる放送方式及びＣＡ方式の特徴を記述する。１つの特定のＣＡサブユニットにより、複数の放送方式及びＣＡ方式をサポートすることもできる。この情報を用いて、ネットワーク内の他のサブユニット、特にコントローラは、各サブユニットがどのように使用されているかを知ることができる。
【００４４】
Ｆｉｇ．３は、サブユニット識別子記述子（subunit identifier descriptor）に含まれる。サブユニット固有の情報を示す図である。
【００４５】
CA_subunit_dependent_info_fields_lengthフィールドは、サブユニット固有の情報における非情報ブロックフィールドのバイト数を特定するフィールであり、この具体例において、非情報ブロックフィールドは、system_specification[n-1]フィールドである。
【００４６】
ネットワーク内のコントローラは、好ましくは、このフィールドに続く任意の数の情報ブロックを検出することができ、これにより、ＣＡサブユニット固有の情報は、将来拡張することができる。コントローラは、CA_subunit_dependent_lengthフィールドと、CA_subunit_dependent_info_fields_lengthとを比較することにより、情報ブロックが存在するか否かを容易に判定することができる。この判定は、以下の式が真であるか否かに基づいて行われる。CA_subunit_dependent_length＞CA_subunit_dependent_info_fields_length＋２（このとき、データ構造は情報ブロックを有する。）CA_subunit_versionフィールドは、ＣＡサブユニットが準拠するＣＡサブユニットコマンド仕様書のバージョン番号を示すフィールドである。上位４ビットは、主バージョン番号（major version number）を示し、下位４ビットは、副バージョン番号（minor version number）を示す。
【００４７】
【表２】
【００４８】
number_of_systemsフィールドは、このＣＡサブユニットにより幾つの放送方式がサポートされているかを示すフィールドである。
【００４９】
systemt_specificationフィールドは、各放送方式を記述するフィールドであり、その詳細をＦｉｇ．４に示す。
【００５０】
system_idフィールドは、ＣＡサブユニットがサポートする放送方式を示すフィールドである。現在、以下の放送方式が定義されている。
【００５１】
【表３】
【００５２】
implementation_profile_idフィールドは、このsystem_idフィールド用のＣＡサブユニットのプロファイルＩＤを特定するフィールドである。ＣＡサブユニットは、サポートする各放送方式毎に異なるプロファイルを有することができる。すなわち、サポートする方式毎にそれぞれ１つのプロファイルを設けることができる。
【００５３】
以下のプロファイルが定義されている。
【００５４】
【表４】
【００５５】
number_of_CA_system_idsフィールドは、ＣＡサブユニットが互換性を有するＣＡ方式の数を示す。
【００５６】
CA_system_idフィールドは、特定のＣＡ方式を識別するフィールドである。CA_system_idの値は、方式より決定され、デジタルビデオ放送（digital video broadcasting：以下、ＤＶＢという。）の場合、ＤＶＢ方式における番組配列情報の仕様書ｐｒＥＴＳ３００４６８（pr ETS 300468 Specification for Service Information(SI)）に定義されている。CA_system_id_lengthフィールドは、CA_system_idフィールドのバイト長を定義するフィールドである。
【００５７】
各ＣＡサブユニットについて、ＣＡ状態記述子（CA status descriptor）が設けられる
。ＣＡ状態記述子は、ＣＡサブユニットと、ＣＡサブユニットの各供給源プラグにおける情報とに関する情報を格納する。このデータ構造に格納されるデータは、動的であり、ＣＡサブユニットにより継続的に更新される。コントローラは、このデータ構造を検査して、ＣＡサブユニット及びその供給源プラグの動作状態を判定する。
【００５８】
Ｆｉｇ．５（ａ）は、ＣＡ状態記述子の汎用フォーマットを示す図である。
【００５９】
descriptor_lengthフィールドは、descriptor_lengthフィールドを除く、ＣＡサブユニットのＣＡ状態記述子のバイト数を示すフィールドである。
【００６０】
Ｆｉｇ．５（ｂ）は、ＣＡサブユニット状態領域情報ブロック（CA subunit status area info block）を示す図であり、Ｆｉｇ．５（ｃ）は、供給源プラグ領域情報ブロック（source plug status area info block）を示す図である。
【００６１】
汎用のＣＡサブユニット状態領域情報ブロックは、特定の供給先プラグ又は供給源プラグに限定されない、ＣＡサブユニットに関する状態情報を格納する。
【００６２】
compound_lengthフィールドは、この情報ブロックの残りのバイト数（有効に定義された最後のフィールドより後に設けられた全ての入れ子にされた情報ブロック（nested information block）を含む）を特定するフィールドである。
【００６３】
primary_field_lengthフィールドは、残りのフィールドのバイト数を示すフィールドである。
【００６４】
available_bandwidth_upperフィールド及びavailable_bandwidth_lowerフィールドは、同時に読み出されるものであり、ＣＡサブユニットが利用可能な帯域幅の容量を示すフィールドである。available_bandwidth_upperフィールドは、利用可能な帯域幅をＭｂｐｓ単位で示した場合の整数部分を示し、available_bandwidth_lowerは、利用可能な帯域幅をＭｂｐｓ単位で示した場合の小数部分を示す。
【００６５】
例えば、ＣＡサブユニットが３４．８Ｍｂｐｓの帯域幅を利用できる場合、available_bandwidth_upperフィールド及びavailable_bandwidth_lowerフィールドには、以下の値が格納される。
【００６６】
available_bandwidth_upper＝００ ２２16
available_bandwidth_lower＝０８１６
available_bandwidth_upperフィールドの値０Ｆ ＦＦ１６及びavailable_bandwidth_lowerフィールドの値ＦＦ１６は、予備の値であり、この値は、ＣＡサブユニットが利用可能な帯域幅の容量を判定できな場合に用いられる。
【００６７】
これにより、チューナサブユニット等の機器は、ＣＡサブユニットが更なるサービスをデスクランブルするのに十分な余分の能力を備えているか否かを判定することができる。ＣＡサブユニットが複数のデータ源からの複数のサービスを同時にデスクランブルする能力を備えている場合、destination_plug_statusフィールドとともに、available_bandwidthフィールドが読み出され、これにより、コントローラは、ＣＡサブユニットに更なるデータ源を接続することができるか否かを判定することができる。
【００６８】
Ｆｉｇ．５（ｃ）に示すソースプラグ状態領域情報ブロックにおいて、number_of_source_plugフィールドは、特定のサブユニットにおけるデータ源プラグの数を特定するフィールドであり、したがって、この情報ブロック内に入れ子にされたplug_status_info_blocksの構造の数を示すフィールドである。
【００６９】
これらの構造は、順番に配置され、互いに内部に入れ子にされていない。多くのＣＡサブユニットは、供給源プラグを１つしか備えていない。
【００７０】
Ｆｉｇ．５（ｄ）に示すplug_status_info_block(x)フィールドは、各供給源プラグの状態情報を格納するフィールドである。供給源プラグが報告すべき状態情報を現在有していない場合であっても、ＣＡサブユニットにおける各供給源プラグ毎に、このようなデータ構造が１つ設けられている。各plug_status_info_block(x)フィールドは、図に示すように、２つの汎用領域に分割されている。
【００７１】
source_plugフィールドは、実際の供給源プラグの数を示すフィールドである。
【００７２】
destination_plugフィールドは、このsource_plugフィールドに関連する供給先プラグの数を示すフィールドである。
【００７３】
statusフィールドは、以下の表に示すように、source_plugの現在の状態を示すフィールドである。
【００７４】
【表５】
【００７５】
値１０１６は、ＣＡサブユニットが正しく機能し、要求されたサービスをデスクランブルした状態で出力していることを示す。一方、値２０１６は、ＣＡサブユニットが選択されたサービスをデスクランブルできると応答しているにもかかわらず、現在、デスクランブルされたサービスが供給源プラグから出力されていない場合に使用される。
【００７６】
ＣＡサブユニット状態記述子は、ＣＡサブユニットの種類に固有の記述子であり、以下の種類値を有する。
【００７７】
【表６】
【００７８】
ＣＡサブユニットは、１つのＣＡ状態記述子しか備えていないので、descriptor_type_specific_referenceフィールドは存在しない。
【００７９】
ＣＡサブユニットモデルは、オブジェクトリストを有していない。
【００８０】
Ｆｉｇ．６は、ＣＡサブユニットコマンドを示す図である。
【００８１】
ＣＡイネーブル（CA Enable）
ＣＡイネーブルコマンドは、ＣＡサブユニットに対し、どのサービスをデスクランブルすべきかを指示するコマンドである。このコマンドは、放送方式毎に固有のコマンドである。Ｆｉｇ．７（ａ）は、ＣＡイネーブル制御コマンドを示す図であり、Ｆｉｇ．７（ｂ2）は、放送方式固有のデータを示す図であり、Ｆｉｇ．７（ｃ）は、エレメンタリパケット識別子（elementary packet identifier：以下、エレメンタリＰＩＤという。）を示す図である。
【００８２】
system_idフィールドは、後続するコマンドがどの放送方式に関連するものであるかを示すフィールドである。以下の方式が現在定義されている。
【００８３】
【表７】
【００８４】
broadcast_system_specific_dataフィールドは、使用されている方式に固有のオペランドを格納するフィールドである。
【００８５】
ＤＶＢ方式の場合、Ｆｉｇ．７（ｂ）に示すオペランドは、デスクランブルするサービスを完全に特定する。サービスの各コンポーネントのＰＩＤ（パケット識別子）が識別される。
【００８６】
コントローラの構成要素となるサブユニットの１つがチューナサブユニットである場合、コントローラは、個別に利用可能なservice_id及びＰＩＤ値を有する。一方、コントローラが他の適切な受信機器を利用する場合、コントローラは、受信機器内のチューナのサービス及びコンポーネント記述子を検査しなくてはならない。さらに、コントローラは、所望のサービスのコンポーネントのＰＩＤを定義しなくてはならない。
【００８７】
デスクランブルする各サービスについて、独立したCA_ENEBLEコマンドが送信される。動作フィールドは、ＣＡサブユニットに格納されている選択されたサービスのリストを更新するために用いられる。以下の値が定義されている。
【００８８】
【表８】
【００８９】
動作が「追加（add）」に設定されている場合、デスクランブルするために選択されたリストにサービスが追加される。「更新（update）」は、選択されたサービスを何らかの形で修正する必要がある場合に使用される。リスト管理コマンドは、プログラムレベルでのみ動作するので、既存のサービスのエレメンタリストリームレベル（elementary stream level）におけるいかなる変化も、完全なエレメンタリストリームリストの再送信と共に、更新コマンドにより知らせなければはならない。「削除（remove）」は、リストから１つのサービスを削除する場合に用い、「全削除（remove_all）」は、全てのサービスのデスクランブルが必要でなくなった場合に用いられる。
【００９０】
service_idフィールドは、program_map_PIDを適用できるサービスを特定するフィールドである。
【００９１】
number_of_elementary_PID_definitionフィールドは、後続するelementary_PIDフィールドの数を示すフィールドである。
【００９２】
各elementary_PIDフィールドは、Ｆｉｇ．７（ｃ）に示す例に対応している。
【００９３】
stream_typeフィールドは、elementary_PIDフィールドにより値が特定されたＰＩＤを有するパケットにより搬送されているサービス要素の種類を識別するフィールドである。この値は、動画の汎用符号化及び関連する音声システム、ＩＳＰ／ＩＥＣ１３８１８−１（ISP/IEC 13818-1 Generic Coding of Moving Picture and Associated Audio System）における表２〜表２９において定義されている。
【００９４】
elementary_PIDフィールドは、関連するサービス要素を搬送するトランスポートストリームパケットのＰＩＤを特定するフィールドである。
【００９５】
ＣＡイネーブル制御コマンドを受信すると、ＣＡサブユニットは、Ｆｉｇ．８（ａ）に示すような応答を、Ｆｉｇ．８（ｂ）に示すような放送方式固有のデータと共に生成する。
【００９６】
オペランドは、ＣＡイネーブル制御コマンドの場合と同様の意味を有しており、応答フォーマットは、追加的な状態オペランドを有する制御コマンドと同様のものである。
【００９７】
動作が「追加」又は「更新」であり、ＣＡイネーブルコマンドが有効に送信された場合、応答は受理（ACCEPTED）となる。また、応答として返される状態（status）は、以下の値をとる。状態の値は、動作を反映している。
【００９８】
【表９】
【００９９】
追加又は送信コマンドが有効に送信された場合、応答はデスクランブル中（descrambling）となる。一方、理論的にデスクランブルは可能であるが、デスクランブルを実行する前にある条件を満たす必要がある場合がある。この場合、条件によりスクランブル可能であることを示すscrambling possible under conditionsメッセージが返される。条件の応答には、購入ダイアログ（purchase dialogue）と技術ダイアログ（technical dialog）の２種類がある。この２つのダイアログには、マンマシンインタフェース（man machine interface（ＭＭＩ））を介したユーザによる相互作用（インタラクション）が必要である。
【０１００】
購入ダイアログは、例えば、ユーザがペイパービューサービスを要求した場合などに必要である。ここで、ユーザは視聴を開始する前に、サービスの料金を確認することができる。
【０１０１】
技術ダイアログは、ＣＡサブユニットがサービスをデスクランブルできるか否かを判定する前に、技術的課題を解決しなくてはならない場合に必要である。これは、例えば、ユーザがスマートカードを挿入しなくてはならない場合等に用いられる。
【０１０２】
CA_ENABLEコマンドの送信に失敗した場合、応答フレームは、拒絶を示すコードREJECTEDを返す。発生したエラーの種類を示すために、状態フィールドは、以下の値をとる。状態の値は動作を反映している。
【０１０３】
【表１０】
【０１０４】
ＣＡイネーブルコマンドは、状態（STATUS）及び通知（NOTIFY）といったコマンドタイプ（ctype）によって送信することができる。Ｆｉｇ．６では、これらをそれぞれ「Ｓ」及び「Ｎ」で示している。状態コマンド及び通知コマンドフレームは、制御コマンドと同様のフレームを有している。このコマンドは、ＣＡサブユニットが選択されたサービスをデスクランブルする能力を有しているか否かを判定するために使用される。Ｆｉｇ．９は、ＤＶＢ方式固有のオペランド用の放送方式固有のデータを示す図である。各フィールドは、制御コマンドと同様のものである。
【０１０５】
ＣＡイネーブル状態及び通知コマンドに対する応答において、ＣＡサブユニットは、応答情報を生成する。Ｆｉｇ．１０もＤＶＢ方式固有のオペランド用の放送方式固有のデータを示す図である。
【０１０６】
各フィールドは、状態フィールドを除いて、コマンド応答（COMMAND response）と同様である。状態フィールドは、以下の値をとる。削除動作は、状態コマンド又は通知コマンドに対しては無効である。
【０１０７】
【表１１】
【０１０８】
ＣＡ権限（CA Entitlement）
ＣＡ権限コマンド（CA entitlement command）は、電子番組ガイド（electronic program guide：以下、ＥＰＧという。）のアプリケーションに使用される。すなわち、ＣＡ権限コマンドは、ＥＰＧにおけるサービスに対して、ユーザがどのような権限を有しているかを判定するための情報をＣＡサブユニットに応答させるコマンドである。例えば、ＥＰＧを表示する場合、ＣＡサブユニットに対し、どの番組をデスクランブルすることができるかを応答させておけば、ＥＰＧにおいて、ユーザが視聴可能な番組を示すことができる。このコマンドは、状態（STATUS）及び通知（NOTIFY）といったコマンドタイプ（ctype）によって用いることができる。このコマンドは、ＥＰＧ及びＣＡアプリケーションについて、同一のあるいは連携する供給者が権限情報を付与するための個別の方式を開発することを妨げるものではない。このコマンドは、個別のＥＰＧによりＣＡモジュールに対する問い合わせを行うために使用することができる。
【０１０９】
Ｆｉｇ．１１（ａ）は、ＣＡ権限コマンドを示す図であり、Ｆｉｇ．１１（ｂ）は、ＤＶＢ方式用の放送方式固有のデータを示す図である。
【０１１０】
システムＩＤフィールドは、ＣＡイネーブルコマンドの場合と同様の意味を有している。
【０１１１】
オペランドnetwork_id、original_network_id、transport_stream_id、service_id、event_idは、権限に関する問い合わせが行われているサービスを特定するためのものである。イベントＩＤは、番組配列情報（service information）における他のロケーション識別子によって完全に修飾される。
【０１１２】
ＣＡ権限コマンドに応答して、ＣＡサブユニットは、Ｆｉｇ．１２（ａ）に示すような応答情報を、Ｆｉｇ．１２（ｂ）に示すＤＶＢ方式用の放送方式固有のデータとともに発行する。
【０１１３】
オペランドnetwork_id、original_network_id、transport_stream_id、service_id、event_idは、コマンドと同様である。entitlement_statusフィールドは、ユーザが選択されたサービスを享受する権限を有しているか否かを示すフィールドである。
【０１１４】
【表１２】
【０１１５】
セキュリティ（Security）
ＣＡサブユニットの概念は、汎用受信機が複数のＣＡ方式によって動作できるようにするものであるが、サービスプロバイダは、特定のＣＡサブユニットを特定の統合受信機デコーダ（integrated receiver decoder：以下、ＩＲＤという。）に連携させることを望む場合もある。この場合、ＣＡサブユニットとＩＲＤとの間にアクセス権を設定し（authentication：以下、このようなアクセス権の設定を認証という。）、各機器が正規の相手のみと有効に動作するようにする。
【０１１６】
Ｆｉｇ．１３は、セキュリティコマンド（SECURITY command）の構造を示す図である。このセキュリティコマンドは、各アプリケーションが固有に定義するものであり、放送方式からは独立している。認証プロトコルは、ＩＲＤとＣＡサブユニットが互いに制御コードを交換し、相手方の機器が正当な権限を有する正規の機器であることを確認し、安全性を確保する処理を行う。認証プロトコルは、これらの機器間で、２つの既知のキーを転送するといった単純な処理でもよく、あるいは、例えば公開キープロトコルに基づくより複雑なキーの交換を行う処理であってもよい。
【０１１７】
categoryフィールドは、これに続くcategory dependentフィールドにおいて使用される認証及びキー交換プロトコルを定義するフィールドである。
【０１１８】
実施例（Implementation）
以下、ＣＡサブユニットの実施例及びこのＣＡサブユニットを用いて行われる処理について説明する。
【０１１９】
ＮＣＡＭは、ネットワークに接続されるＣＡシステムを実現するために必要な機能を提供するサブユニットの論理的な集合体である。ＣＡサブユニットは、ＣＡシステムの中心的存在（core）であり、マテリアルの供給、デスクランブルが必要なマテリアルの格納、ユーザ及び外部世界との通信等の処理は、他のサブユニットに行わせる。したがって、ＣＡサブユニットは、チューナサブユニット及びパネルサブユニットと連携しなくてはならない。
【０１２０】
ＮＣＡＭは、最小限の構成として、チューナサブユニット、ＣＡサブユニット及びパネルサブユニットのみにより実現することができる。さらに、ＣＡシステムは、リソース、例えばモデム及び／又はスマートカードリーダを要求してもよく、これらは同一のユニットの一部を構成する場合、これらに個別にアクセスすることができる。
【０１２１】
スクランブルされたトランスポートストリームをデコードする処理について、Ｆｉｇ．１４を参照して説明する。以下の説明では、チューナサブユニットをスクランブルされたトランスポートストリームの供給源と考える。このトランスポートストリームは、適切なフロントエンド回路を介して供給された地上波放送であってもよく、直接ＤＭＵＸからＤＶＣＲ等の他のデータ供給源を介して供給された信号であってもよい。ユーザは、チャンネルを選択するための操作を行い、チューナサブユニットは、トランスポートストリームがスクランブルされていることを検出する。
【０１２２】
コントローラは、トランスポートストリームからのCA_System_idフィールドとＣＡサブユニットのCA_system_idフィールドとに基づいて、どのＣＡサブユニットを使用するかに関する知的予測（intelligent prediction）を行うことができる。例えば、Ｆｉｇ．１５に示す具体例では、衛星放送ＩＲＤは、ＩＥＥＥ１３９４シリアルバスを介してＣＡサブユニットに接続されている。
【０１２３】
コントローラは、ＣＡサブユニットにスクランブルされたサービスを供給するために、チューナサブユニットとＣＡサブユニットとの間のアイソクロノスチャンネルを確立する。さらに、データを格納するための機器とＣＡサブユニットとの間の第２のチャンネルを確立する。この機器は、スクランブルされたソースマテリアルを供給した機器と同一の機器であってもよく、異なる機器であってもよい。ここで、トランスポートストリームのデスクランブル処理において、例えば５Ｃコピー防止方式（5C Copy Protection System）又はその他の適切なコピー防止機構を用いて、不正なコピーを防止することもできる。
【０１２４】
コントローラは、ＣＡサブユニットにCA_ENABLEコマンドを送信し、デスクランブルしてほしい１つ以上のサービスを知らせる。ＣＡサブユニットは、CA_ENABLEコマンドを受信し、選択されたサービスをデスクランブルする能力を自らが有しているか否かを判定する。この処理には、ユーザに対するダイアログを設定し、ユーザがサービス享受のための料金を支払う意志があるか否かを確認する処理、又はユーザに対し料金支払いのためのカードの挿入又は暗証番号の入力を促す処理を含む。
【０１２５】
ユーザダイアログの後、ＣＡサブユニットが選択されたサービスをデスクランブルできる状態になった場合、ＣＡサブユニットは、内部の状態レジスタを更新し、デスクランブルしたデータの出力を開始する。
【０１２６】
各コマンドが応答を必要とするというＡＶ／Ｃコマンドの性質に起因して、元のCA_ENABLEコマンドに対して、ユーザダイアログ又は技術ダイアログが必要であるためにREJECTED応答が返された場合、そのダイアログにより問題が解決されても、コントローラはその結果を知ることができない。そこで、CA_ENABLEコマンドがダイアログの理由で拒絶された場合、コントローラは、NOTIFYコマンドを送信し、ＣＡサブユニットの状態が変化したことをＣＡサブユニットに報告させる必要がある。
【０１２７】
ＥＭＭ処理（EMM handling）
ＤＴＶ受信機の実施例の幾つかにおいて、ＣＡモジュールは、ＤＴＶがスタンバイ状態又は電源オン状態にあるときに、ＥＭＭを受信することができる。これにより、ＣＡモジュールは、ユーザが有している権限を継続的に更新することができる。
【０１２８】
ネットワーク環境において、ＣＡサブユニットにＥＭＭパケットを処理させるためには、ＴＳをＣＡサブユニットに送らなければならない。したがって、ＣＡサブユニットの電源がオフ状態のままの場合、又はＴＳがＣＡサブユニットに一定期間接続されなかった場合、ＣＡサブユニットに格納されている権限情報は、旧いものとなってしまう。したがって、ＣＡサブユニットは、周期的にチューナサブユニットに接続し、ＴＳを要求し、ＥＭＭを更新する必要がある。この処理は、ユーザの邪魔にならないように行うべきである。コントローラは、ユーザが特定のサービスを視聴している間、チャンネルを変更するような処理は行わない。
【０１２９】
チューナサブユニットがない場合
チューナサブユニットを備えるネットワークにおいて、ＣＡサブユニットの使用は、チューナサブユニットが設けられたユニット及びＣＡサブユニットが設けられたユニットの外部にコントローラが存在する場合に、特に有効である。これにより、コントローラは、チューナサブユニットが受信する能力を有するサービスを検出し、ＣＡサブユニットに、これらのサービスの幾つかをデスクランブルするように指示することができる。
【０１３０】
チューナサブユニットが存在しないネットワークにおいて、ＣＡサブユニットを用いる場合もある。この場合、ＣＡサブユニットを利用するためには、コントローラは、データ源となるユニット内に設ける必要がある。コントローラは、このユニット内でトランスポートストリームを個別に検査し、デスクランブルすべきサービスの要素のＰＩＤを判定する。ここでも、デスクランブルする要素のＰＩＤにＥＭＭが含まれている必要がある。
【技術分野】
【０００１】
本発明は、ネットワークに接続された限定受信モジュール（conditional access module）及び限定受信モジュールをネットワーク上で実現する方法に関する。詳しくは、本発明は、ＩＥＥＥ１３９４ネットワークに限定受信サブユニット（conditional access subunit）を提供するデジタルコンテンツ受信機及びデジタルコンテンツ受信方法に関する。
【背景技術】
【０００２】
デジタルマルチメディアの進歩、特にデジタルテレビジョンの進歩に伴い、限定受信モジュール（conditional access module）が提案されている。デジタルビデオ信号処理の分野では、ビデオ信号はコード化され、受信機においてビデオ信号を再生するためには特別な処理が必要である。特に、デスクランブル（スクランブル解除）処理を実行するとともに、デジタルテレビジョン受像機におけるその他の限定受信機能を提供する限定受信モジュールが提案されている。限定受信モジュールは、限定受信を実現するとともに、ホスト受信機から分離された信号のデコード処理を実行し、これにより、汎用デジタルテレビジョン受像機は、異なる限定受信モジュールを用いて異なる限定受信を行うことができる。
【０００３】
限定受信モジュールとテレビジョン受像機との間の通信を実現するための共通インタフェースが提案され、ＣＥＮＥＬＥＣ（限定受信及びその他のデジタルビデオ放送デコーダアプリケーションのための共通インタフェース仕様書ＥＮ５０２１１（EN50221 Common Interface Specification for Conditional Access and other Digital Video Broadcasting Decoder Applications））により標準化されている。この標準共通インタフェースは、様々な仮想チャンネルが時分割多重化されたトランスポートストリームインタフェースと、様々な追加的コマンドデータが送信されるコマンドインタフェースとを定義している。したがって、この共通インタフェースにより、限定受信モジュールは、デジタルテレビジョン受像機、あるいは実際にはその他のあらゆるデジタルビデオ機器に接続することができる。
【０００４】
本発明の基礎的背景として、オーディオ機器及びビデオ機器を含むデジタルマルチメディア機器のローカルネットワーク上で限定受信モジュールを実現し、ネットワーク上の全ての機器に限定受信モジュールの機能を利用できる技術が求められている。
【０００５】
様々なデジタルビデオ機器をローカルネットワークに接続する標準技術が提案されている。例えば、ＩＥＥＥ１３９４規格（１９９５年版）は、高速シリアルバス用のＩＥＥＥ標準技術として知られている。ＩＥＥＥ１３９４規格（１９９５年版）は、様々な民生用デジタルオーディオ／ビジュアル機器を相互接続する、ＩＥＥＥ１３９４シリアルバスと呼ばれるバスを提供する。
【０００６】
ＩＥＥＥ１３９４仕様書では、物理的リンクコネクタ、電気的信号及びシリアルバスを自己環境設定でき、オーディオ信号、ビデオ信号及び制御情報を効率的に搬送できるリンクプロトコルとトランザクションプロトコルのセットを定義している。さらに、ＩＥＥＥ１３９４シリアルバス上の設備内の異なるアイテム間でＭＰＥＧデータを搬送し、制御機構を提供する更なるプロトコルのセットが定義されている。これらのプロトコルは、「ＩＥＣ６１８８３民生用電子オーディオ／ビデオ機器のためのデジタルインタフェース（Digital Interface for Consumer Electronic Audio/Video Equipment(IEC61833)）」仕様書に定義されている。
【０００７】
ＩＥＣ１６８３３仕様書に基づき、幾つかのコマンドプロトコルが使用できる。ＩＥＥＥ１３９４取引協会（IEEE1394 trade association）により発表されたオーディオ／ビデオ制御デジタルインタフェースコマンドセット文書（AV/C Digital Interface Command Set Document）において、オーディオ／ビデオ制御コマンドトランザクション（audio/video control command transaction：以下、ＡＶ／Ｃ−ＣＴＳという。）が定義されている（１９９７年３月２６日、ＩＥＥＥ１３９４取引協会オーディオ／ビデオワーキンググループ発行、オーディオ／ビデオ制御デジタルインタフェースコマンドセットバーション２．０Ｄ（AV/C Digital Interface Command Set Version 2.0D））。ＡＶ／Ｃ−ＣＴＳは、民生用Ａ／Ｖ機器及び業務用Ａ／Ｖ機器のためのコマンドセットを定義している。ＡＶ／Ｃ−ＣＴＳコマンドは、ＩＥＣ６１８８３により定義されているファンクションコントロールプロトコル（function control protocol：以下、ＦＰＣという。）のパケットフォーマットにより搬送される。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開平０９−３２６８１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、ＩＥＥＥ１３９４ネットワーク上で柔軟性の高い分散型ＡＶネットワーク環境を実現するデジタルコンテンツ受信機及びデジタルコンテンツ受信方法を提供することである。
【課題を解決するための手段】
【００１０】
本発明は、デジタルコンテンツ受信機であって、スクランブルされたデジタルコンテンツ信号を受信する受信手段と、上記受信手段により受信された上記スクランブルされたデジタルコンテンツ信号を限定受信サブユニットに出力するとともに、該限定受信サブユニットからローカルスクランブルデジタルコンテンツ信号を入力するインタフェース手段と、上記限定受信サブユニットから入力された上記ローカルスクランブルデジタルコンテンツ信号をローカルデスクランブルして、デジタルコンテンツ信号を生成するローカルデスクランブル手段とを備え、上記限定受信サブユニットから入力されるローカルスクランブルデジタルコンテンツ信号は、該限定受信サブユニットにおいて、上記受信されたスクランブルされたデジタルコンテンツ信号をデスクランブルし、更に、ローカルスクランブルした信号であり、上記限定受信サブユニットは、同時に複数の個別のストリーム又はサービスをデスクランブルすることを特徴とする。
【００１１】
また、本発明に係るデジタルコンテンツ受信機は、当該デジタルコンテンツ受信機が認証されたときだけ、上記ローカルスクランブルデジタルコンテンツ信号をローカルデスクランブルするものとすることができる。
【００１２】
さらに、本発明に係るデジタルコンテンツ受信機において、上記限定受信サブユニットは、該限定受信サブユニット内に格納されている権限管理メッセージを更新するのに十分な期間、上記受信手段から上記スクランブルされたデジタルコンテンツ信号を受信するものとすることができる。
【００１３】
本発明は、デジタルコンテンツ受信方法であって、スクランブルされたデジタルコンテンツ信号を受信手段で受信するステップと、上記受信されたスクランブルされたデジタルコンテンツ信号を限定受信サブユニットに出力するステップと、上記限定受信サブユニットにおいて、上記スクランブルされたデジタルコンテンツ信号をデスクランブルして、デジタルコンテンツ信号を生成し、該生成されたデジタルコンテンツ信号をローカルスクランブルして、ローカルスクランブルデジタルコンテンツ信号を生成するステップと、上記限定受信サブユニットからローカルスクランブルデジタルコンテンツ信号を上記受信手段に入力するステップと、上記受信手段において、上記入力されたローカルスクランブルデジタルコンテンツ信号をローカルデスクランブルして、デジタルコンテンツ信号を生成するステップとを有し、上記限定受信サブユニットから入力されるローカルスクランブルデジタルコンテンツ信号は、該限定受信サブユニットにおいて、上記受信されたスクランブルされたデジタルコンテンツ信号をデスクランブルし、更に、ローカルスクランブルした信号であり、上記限定受信サブユニットにおいて、同時に複数の個別のストリーム又はサービスをデスクランブルすることを特徴とする。
【発明の効果】
【００１４】
本発明によれば、限定受信サブユニットにより同時に複数の個別のストリーム又はサービスをデスクランブルすることにより、柔軟性の高い分散型ＡＶネットワーク環境を実現することができる。
【図面の簡単な説明】
【００１５】
【図１】Ｆｉｇ．１は、ＣＡサブユニットを示す図である。
【図２】Ｆｉｇ．２は、ＣＡサブユニットの論理的接続を示す図である。
【図３】Ｆｉｇ．３は、ＣＡサブユニット識別子記述子を示す図である。
【図４】Ｆｉｇ．４は、Ｆｉｇ．３に示す記述子とともに用いる方式の仕様を示す図である。
【図５】Ｆｉｇ．５（ａ）は、ＣＡ状態記述子を示す図である。
【図６】Ｆｉｇ．５（ｂ）は、ＣＡサブユニット状態領域情報ブロックを示す図である。
【図７】Ｆｉｇ．５（ｃ）は、供給源プラグ状態領域情報ブロックを示す図である。
【図８】Ｆｉｇ．５（ｄ）は、プラグ状態情報ブロックを示す図である。
【図９】Ｆｉｇ．６は、ＣＡサブユニットコマンドを示す図である。
【図１０】Ｆｉｇ．７（ａ）は、ＣＡイネーブル制御コマンドを示す図である。
【図１１】Ｆｉｇ．７（ｂ）は、Ｆｉｇ．７（ａ）に示す放送方式固有のデータを詳細に示す図である。
【図１２】Ｆｉｇ．７（ｃ）は、Ｆｉｇ．７（ｂ）に示すエレメンタリＰＩＤの定義を示す図である。
【図１３】Ｆｉｇ．８（ａ）は、ＣＡイネーブル応答を示す図である。
【図１４】Ｆｉｇ．８（ｂ）は、Ｆｉｇ．８（ａ）に示す放送方式固有のデータを詳細に示す図である。
【図１５】Ｆｉｇ．９は、状態又は通知コマンドのデータ構造を示す図である。
【図１６】Ｆｉｇ．１０は、状態又は通知応答のデータ構造を示す図である。
【図１７】Ｆｉｇ．１１（ａ）は、ＣＡ権限コマンドを示す図である。
【図１８】Ｆｉｇ．１１（ｂ）は、Ｆｉｇ．１１（ａ）に示す放送方式固有のデータを詳細に示す図である。
【図１９】Ｆｉｇ．１２（ａ）は、ＣＡ権限応答を示す図である。
【図２０】Ｆｉｇ．１２（ｂ）は、Ｆｉｇ．１２（ａ）に示す放送方式固有のデータを詳細に示す図である。
【図２１】Ｆｉｇ．１３は、セキュリティ制御コマンドを示す図である。
【図２２】Ｆｉｇ．１４は、コントローラとＣＡサブユニットとの間のコマンドの交換を説明する図である。
【図２３】Ｆｉｇ．１５は、ネットワーク限定受信モジュールに接続された衛星放送ＩＲＤを示す図である。
【発明を実施するための形態】
【００１６】
本発明は、以下の詳細な説明により、より明瞭に理解される。以下の説明では、添付の図面を用いるが、ここで説明する実施の形態は、例示的なものである。
【００１７】
複数の放送業者からのスクランブルされた放送サービスにアクセスするデジタルテレビジョン受像機（digital television receiver：以下、ＤＴＶという。）には、限定受信（conditional access：以下、ＣＡともいう。）システムが必要となる。すなわち、ＤＴＶに接続可能なモジュール内にＣＡシステムを実現するためのプロトコルを定義することにより、ＤＴＶは、サービスにアクセスすることができる。このソリューションは、例えば、単一の受像機に接続されたＰＣカードの形式で実現できる。しかしながら、ネットワーク化された限定受信モジュール（networked conditional access module：以下、ＮＣＡＭという。）の実現が望まれている。ＮＣＡＭの主な要求は、以下のとおりである。
・フォームファクタ（form factor）の柔軟性
・アクセスの柔軟性、例えばピアツーピア通信（peer to peer communication）
・ロケーションの柔軟性
【００１８】
本発明は、ＮＣＡＭを実現するために必要な追加的なＡＶ／Ｃサブユニットのフォーマットを提案する。このＮＣＡＭ用のＡＶ／Ｃモデルは、ＩＥＥＥ１３９４規格（１９９５年版）に準拠するデジタルネットワークにおいて使用できるように設計されたＣＡシステムを提供する。
【００１９】
ＮＣＡＭの目的は、限定受信機能を提供することである。ＮＣＡＭは、選択されたサービスをデスクランブルするためのリソースの論理的集合体（logical collection）を使用する。ＮＣＡＭに必要なリソースは、例えばＤＴＶ内等の１つのロケーションに存在していてもよく、あるいはインホームデジタルネットワーク（in home digital network：以下、ＩＨＤＮという。）等のネットワークにおいて分散されていてもよい。
【００２０】
ＮＣＡＭは、既存のサブユニットと追加的サブユニット（additional subunit）の両方を利用する。ＮＣＡＭが利用する既存のサブユニットは、以下のとおりである。
【００２１】
・チューナサブユニット
・パネルサブユニット
ＩＥＥＥ１３９４ネットワーク上でＮＣＡＭを実現するために、限定受信モジュールのためのＡＶ／Ｃサブユニットを定義する。限定受信サブユニット（以下、ＣＡサブユニットという。）は、デスクランブラの中心的な機能を担う。ＣＡサブユニットは、スクランブルされたストリームを受信し、それらをデスクランブルし、デスクランブルされたストリームを出力する。ＣＡサブユニットは、ＩＥＥＥ１３９４ネットワークを介して、非同期コマンドにより他の必要なサブユニットと通信を行う。
【００２２】
チューナサブユニット（tuner subunit）は、データ源として用いられ、パネルサブユニット（panel subunit）は、ユーザに情報を提供し、及びユーザに情報を入力させるために用いられる。ＣＡサブユニットは、デスクランブル機能を有し、スマートカードやモデムサブユニットを利用できる。
【００２３】
ＮＣＡＭが機能するために必要なリソースは、単一のモジュール内に個別に（privately）実現することもできる。また、製造業者がスマートカードによりＮＣＡＭを実現する場合、モデム機能とＮＣＡＭの専用機能とを統合することができる。このような場合、ＮＣＡＭはＣＡサブユニットのみから構成され、他の機器のチューナサブユニット及びパネルサブユニットを利用することとなる。安全性の観点からは、ＮＣＡＭを独立したスマートカードにより実現することが望ましい。スマートカードが、例えばデータカード又は電子通貨（electronic cash）等の他のアプリケーションとしても使用される場合でも、そのようなスマートカードにＣＡサブユニットを含ませることもできる。
【００２４】
ＮＣＡＭは、分散されたリソースに亘って実現することもできる。この場合、ＣＡサブユニットは、デジタルネットワークの各所に分散された他のオブジェクトが実装するサブユニットと連携して機能することとなる。
【００２５】
デスクランブルするサービスに応じて、全てのリソース又はリソースの一部が必要となる。サービスを認証するために挿入されるスマートカードを用いた単純なシステムでは、モデムは必要なく、ユーザにカードの挿入を促すための単純な表示装置を設ければよい。このとき、ユーザとの相互作用（インタラクション）は必ずしも必要ではない。より複雑なシステム、例えばペイパービュー（pay per view：以下、ＰＰＶという。）では、選択可能なサービスをユーザに提示し、ユーザによる選択操作を実現するための全てのリソースが必要となる。すなわち、必要なサブユニットの全てが設けられていない場合は、ＮＣＡＭの機能は制限される。
【００２６】
Ｆｉｇ．１は、基本的なＣＡサブユニット２の構造を示す図である。このＣＡサブユニット２は、スタンドアロン機器（stand alone device）であってもよく、他の機器に組み込まれたものであってもよい。
【００２７】
ＣＡサブユニット供給先プラグ（CA subunit destination plug）４は、ＣＡサブユニット２への入力信号が入力される。この入力信号のフォーマットは、ＣＡサブユニット２によりサポートされている方式に準拠するものである。ＣＡサブユニット供給先プラグ４は、シリアルバス（１３９４）入力プラグに直接接続してもよく、あるいは、例えばチューナサブユニット等の他の適切なサブユニットの供給源プラグに接続してもよい。
【００２８】
ＣＡサブユニット供給源プラグ（CA subunit source plug）６からは、ＣＡサブユニット２の出力信号が出力される。この出力信号のフォーマットは、ＣＡサブユニット２によりサポートされている方式に準拠するものである。ＣＡサブユニット供給源プラグ６は、シリアルバス出力プラグに直接接続してもよく、あるいは、他の適切なサブユニットの供給先プラグに接続してもよい。
【００２９】
単一の供給源及び供給先プラグを実装するＣＡサブユニットは、ＣＡ方式がソースマテリアルと互換性を有する場合、単一のデータ源から供給される１つのアイソクロノスチャンネルにおける１つ以上のサービスをデスクランブルする能力を有する。
【００３０】
ＣＡサブユニットのハードウェア能力に応じて、ＣＡサブユニットには、複数の供給先プラグ及び供給源プラグを設けることができる。供給先プラグと供給源プラグの数は一致する。このように構成されたＣＡサブユニットによれば、同時に複数の個別のストリーム又はサービスをデスクランブルすることができる。このモデルにより柔軟性の高い分散型ＡＶネットワーク環境を実現できる。
【００３１】
換言すれば、ＣＡサブユニットは、ネットワーク上の１つ以上の他のサブユニットから異なるストリームを受信し、これらのストリームをデスクランブルし、必要に応じて１つ以上の他のサブユニットに送ることができる。ここで、制約の要素となるのは、原理的には伝送帯域幅のみである。
【００３２】
ＣＡサブユニット供給先プラグと、シリアルバス入力プラグ又は他のサブユニットの接続は、CONNECTコマンドを用いて手動で確立される。この接続は、ＣＡコマンドを送信する以前に確立される。ＣＡサブユニットがスタンドアロンモードで動作している場合、供給先プラグ及び供給源プラグは、シリアルバスの入力プラグ及び出力プラグに持続的に接続される。
【００３３】
ＣＡサブユニットが既にロックされた接続先を有し、さらに追加的な接続が要求された場合、その要求に対する応答として、REJECTED（拒絶）が返される。接続が永続性を有する場合、矛盾を生じるコマンドに対する応答として、NOT IMPLEMENTED（実行されない）が返される。
【００３４】
CONNECTコマンドは、ＣＡサブユニットを他のサブユニット又はバス出力プラグに接続するために使用される。
【００３５】
ＣＡサブユニットの現在の接続状態は、CONNECT状態、又はCONNECTIONS状態コマンドにより報告される。この状態には永続的な接続も含まれる。コントローラは、CONNECT状態又はCONNECTIONS状態コマンドの応答におけるpermフラグを検査することにより、接続が永続的なものであるか否かを判定することができる。
【００３６】
ＣＡサブユニットと他のサブユニットとの接続は、実行形態に応じて決定される。ＣＡサブユニットと他のサブユニットとの接続を許可することが論理的であるか否かについては、実行時（implementation time）において判定される。
【００３７】
ＣＡサブユニットは、受信機に組み込んでもよい。ここで受信機とは、チューナサブユニットを備えるものでもよく、スタンドアロン機器であってもよい。Ｆｉｇ．２は、ＣＡサブユニット２を受信機８内に組み込んだ状態を示す。受信機８は、スタンドアロン機器であり、アンテナ入力プラグはなくてもよい（シリアルバス入力プラグのみでもよく、外部入力プラグを設けてもよい）。
【００３８】
以下の表は、受信機ユニットとＣＡサブユニットプラグ間の接続の様々な組み合わせ、各組み合わせが有効であるか無効であるかを示す表である。接続が無効な場合、NOT IMPLEMENTEDが返される。
【００３９】
【表１】
【００４０】
CONNECTコマンドを発生する場合、ロックビットを用いて、第三者（third parties）により接続が切断されないように保証する。
【００４１】
ＣＡサブユニットは、トランスポートストリームの全体及びトランスポートストリームの一部の両方を取り扱うことができる。データ源側にとって、バスの帯域幅を節減するために、デスクランブルするサービスの要素を含むパーシャルトランスポートストリーム（partial transport stream）を生成する方が有利である。この場合パーシャルトランスポートストリームが生成され、及び権限管理メッセージ（entitlement management message：以下、ＥＭＭという。）がトランスポートストリームに組み込まれる。すなわち、データ源側が部分的トランスポートストリームにＥＭＭを組み込む。このような場合、データにＥＭＭが組み込まれていなければ、ＣＡサブユニットは、所望のサービスをデスクランブルすることができない。
【００４２】
ＣＡシステムは、許可されていない（unauthorised）放送マテリアルへのアクセスを禁止する機能を有する。マテリアルが一旦デスクランブルされた後も、ＩＨＤＮ上を伝送する際に、マテリアルを保護することができる。特に、ＣＡサブユニットは、供給先プラグ及び供給源プラグの両方において、適切なコピー防止システムを実装することができる。
【００４３】
ＣＡサブユニットにはサブユニット識別子が与えられる。各特定のＣＡサブユニットに対し、サブユニット識別子は、そのＣＡサブユニットによりサポートされる放送方式及びＣＡ方式の特徴を記述する。１つの特定のＣＡサブユニットにより、複数の放送方式及びＣＡ方式をサポートすることもできる。この情報を用いて、ネットワーク内の他のサブユニット、特にコントローラは、各サブユニットがどのように使用されているかを知ることができる。
【００４４】
Ｆｉｇ．３は、サブユニット識別子記述子（subunit identifier descriptor）に含まれる。サブユニット固有の情報を示す図である。
【００４５】
CA_subunit_dependent_info_fields_lengthフィールドは、サブユニット固有の情報における非情報ブロックフィールドのバイト数を特定するフィールであり、この具体例において、非情報ブロックフィールドは、system_specification[n-1]フィールドである。
【００４６】
ネットワーク内のコントローラは、好ましくは、このフィールドに続く任意の数の情報ブロックを検出することができ、これにより、ＣＡサブユニット固有の情報は、将来拡張することができる。コントローラは、CA_subunit_dependent_lengthフィールドと、CA_subunit_dependent_info_fields_lengthとを比較することにより、情報ブロックが存在するか否かを容易に判定することができる。この判定は、以下の式が真であるか否かに基づいて行われる。CA_subunit_dependent_length＞CA_subunit_dependent_info_fields_length＋２（このとき、データ構造は情報ブロックを有する。）CA_subunit_versionフィールドは、ＣＡサブユニットが準拠するＣＡサブユニットコマンド仕様書のバージョン番号を示すフィールドである。上位４ビットは、主バージョン番号（major version number）を示し、下位４ビットは、副バージョン番号（minor version number）を示す。
【００４７】
【表２】
【００４８】
number_of_systemsフィールドは、このＣＡサブユニットにより幾つの放送方式がサポートされているかを示すフィールドである。
【００４９】
systemt_specificationフィールドは、各放送方式を記述するフィールドであり、その詳細をＦｉｇ．４に示す。
【００５０】
system_idフィールドは、ＣＡサブユニットがサポートする放送方式を示すフィールドである。現在、以下の放送方式が定義されている。
【００５１】
【表３】
【００５２】
implementation_profile_idフィールドは、このsystem_idフィールド用のＣＡサブユニットのプロファイルＩＤを特定するフィールドである。ＣＡサブユニットは、サポートする各放送方式毎に異なるプロファイルを有することができる。すなわち、サポートする方式毎にそれぞれ１つのプロファイルを設けることができる。
【００５３】
以下のプロファイルが定義されている。
【００５４】
【表４】
【００５５】
number_of_CA_system_idsフィールドは、ＣＡサブユニットが互換性を有するＣＡ方式の数を示す。
【００５６】
CA_system_idフィールドは、特定のＣＡ方式を識別するフィールドである。CA_system_idの値は、方式より決定され、デジタルビデオ放送（digital video broadcasting：以下、ＤＶＢという。）の場合、ＤＶＢ方式における番組配列情報の仕様書ｐｒＥＴＳ３００４６８（pr ETS 300468 Specification for Service Information(SI)）に定義されている。CA_system_id_lengthフィールドは、CA_system_idフィールドのバイト長を定義するフィールドである。
【００５７】
各ＣＡサブユニットについて、ＣＡ状態記述子（CA status descriptor）が設けられる
。ＣＡ状態記述子は、ＣＡサブユニットと、ＣＡサブユニットの各供給源プラグにおける情報とに関する情報を格納する。このデータ構造に格納されるデータは、動的であり、ＣＡサブユニットにより継続的に更新される。コントローラは、このデータ構造を検査して、ＣＡサブユニット及びその供給源プラグの動作状態を判定する。
【００５８】
Ｆｉｇ．５（ａ）は、ＣＡ状態記述子の汎用フォーマットを示す図である。
【００５９】
descriptor_lengthフィールドは、descriptor_lengthフィールドを除く、ＣＡサブユニットのＣＡ状態記述子のバイト数を示すフィールドである。
【００６０】
Ｆｉｇ．５（ｂ）は、ＣＡサブユニット状態領域情報ブロック（CA subunit status area info block）を示す図であり、Ｆｉｇ．５（ｃ）は、供給源プラグ領域情報ブロック（source plug status area info block）を示す図である。
【００６１】
汎用のＣＡサブユニット状態領域情報ブロックは、特定の供給先プラグ又は供給源プラグに限定されない、ＣＡサブユニットに関する状態情報を格納する。
【００６２】
compound_lengthフィールドは、この情報ブロックの残りのバイト数（有効に定義された最後のフィールドより後に設けられた全ての入れ子にされた情報ブロック（nested information block）を含む）を特定するフィールドである。
【００６３】
primary_field_lengthフィールドは、残りのフィールドのバイト数を示すフィールドである。
【００６４】
available_bandwidth_upperフィールド及びavailable_bandwidth_lowerフィールドは、同時に読み出されるものであり、ＣＡサブユニットが利用可能な帯域幅の容量を示すフィールドである。available_bandwidth_upperフィールドは、利用可能な帯域幅をＭｂｐｓ単位で示した場合の整数部分を示し、available_bandwidth_lowerは、利用可能な帯域幅をＭｂｐｓ単位で示した場合の小数部分を示す。
【００６５】
例えば、ＣＡサブユニットが３４．８Ｍｂｐｓの帯域幅を利用できる場合、available_bandwidth_upperフィールド及びavailable_bandwidth_lowerフィールドには、以下の値が格納される。
【００６６】
available_bandwidth_upper＝００ ２２16
available_bandwidth_lower＝０８１６
available_bandwidth_upperフィールドの値０Ｆ ＦＦ１６及びavailable_bandwidth_lowerフィールドの値ＦＦ１６は、予備の値であり、この値は、ＣＡサブユニットが利用可能な帯域幅の容量を判定できな場合に用いられる。
【００６７】
これにより、チューナサブユニット等の機器は、ＣＡサブユニットが更なるサービスをデスクランブルするのに十分な余分の能力を備えているか否かを判定することができる。ＣＡサブユニットが複数のデータ源からの複数のサービスを同時にデスクランブルする能力を備えている場合、destination_plug_statusフィールドとともに、available_bandwidthフィールドが読み出され、これにより、コントローラは、ＣＡサブユニットに更なるデータ源を接続することができるか否かを判定することができる。
【００６８】
Ｆｉｇ．５（ｃ）に示すソースプラグ状態領域情報ブロックにおいて、number_of_source_plugフィールドは、特定のサブユニットにおけるデータ源プラグの数を特定するフィールドであり、したがって、この情報ブロック内に入れ子にされたplug_status_info_blocksの構造の数を示すフィールドである。
【００６９】
これらの構造は、順番に配置され、互いに内部に入れ子にされていない。多くのＣＡサブユニットは、供給源プラグを１つしか備えていない。
【００７０】
Ｆｉｇ．５（ｄ）に示すplug_status_info_block(x)フィールドは、各供給源プラグの状態情報を格納するフィールドである。供給源プラグが報告すべき状態情報を現在有していない場合であっても、ＣＡサブユニットにおける各供給源プラグ毎に、このようなデータ構造が１つ設けられている。各plug_status_info_block(x)フィールドは、図に示すように、２つの汎用領域に分割されている。
【００７１】
source_plugフィールドは、実際の供給源プラグの数を示すフィールドである。
【００７２】
destination_plugフィールドは、このsource_plugフィールドに関連する供給先プラグの数を示すフィールドである。
【００７３】
statusフィールドは、以下の表に示すように、source_plugの現在の状態を示すフィールドである。
【００７４】
【表５】
【００７５】
値１０１６は、ＣＡサブユニットが正しく機能し、要求されたサービスをデスクランブルした状態で出力していることを示す。一方、値２０１６は、ＣＡサブユニットが選択されたサービスをデスクランブルできると応答しているにもかかわらず、現在、デスクランブルされたサービスが供給源プラグから出力されていない場合に使用される。
【００７６】
ＣＡサブユニット状態記述子は、ＣＡサブユニットの種類に固有の記述子であり、以下の種類値を有する。
【００７７】
【表６】
【００７８】
ＣＡサブユニットは、１つのＣＡ状態記述子しか備えていないので、descriptor_type_specific_referenceフィールドは存在しない。
【００７９】
ＣＡサブユニットモデルは、オブジェクトリストを有していない。
【００８０】
Ｆｉｇ．６は、ＣＡサブユニットコマンドを示す図である。
【００８１】
ＣＡイネーブル（CA Enable）
ＣＡイネーブルコマンドは、ＣＡサブユニットに対し、どのサービスをデスクランブルすべきかを指示するコマンドである。このコマンドは、放送方式毎に固有のコマンドである。Ｆｉｇ．７（ａ）は、ＣＡイネーブル制御コマンドを示す図であり、Ｆｉｇ．７（ｂ2）は、放送方式固有のデータを示す図であり、Ｆｉｇ．７（ｃ）は、エレメンタリパケット識別子（elementary packet identifier：以下、エレメンタリＰＩＤという。）を示す図である。
【００８２】
system_idフィールドは、後続するコマンドがどの放送方式に関連するものであるかを示すフィールドである。以下の方式が現在定義されている。
【００８３】
【表７】
【００８４】
broadcast_system_specific_dataフィールドは、使用されている方式に固有のオペランドを格納するフィールドである。
【００８５】
ＤＶＢ方式の場合、Ｆｉｇ．７（ｂ）に示すオペランドは、デスクランブルするサービスを完全に特定する。サービスの各コンポーネントのＰＩＤ（パケット識別子）が識別される。
【００８６】
コントローラの構成要素となるサブユニットの１つがチューナサブユニットである場合、コントローラは、個別に利用可能なservice_id及びＰＩＤ値を有する。一方、コントローラが他の適切な受信機器を利用する場合、コントローラは、受信機器内のチューナのサービス及びコンポーネント記述子を検査しなくてはならない。さらに、コントローラは、所望のサービスのコンポーネントのＰＩＤを定義しなくてはならない。
【００８７】
デスクランブルする各サービスについて、独立したCA_ENEBLEコマンドが送信される。動作フィールドは、ＣＡサブユニットに格納されている選択されたサービスのリストを更新するために用いられる。以下の値が定義されている。
【００８８】
【表８】
【００８９】
動作が「追加（add）」に設定されている場合、デスクランブルするために選択されたリストにサービスが追加される。「更新（update）」は、選択されたサービスを何らかの形で修正する必要がある場合に使用される。リスト管理コマンドは、プログラムレベルでのみ動作するので、既存のサービスのエレメンタリストリームレベル（elementary stream level）におけるいかなる変化も、完全なエレメンタリストリームリストの再送信と共に、更新コマンドにより知らせなければはならない。「削除（remove）」は、リストから１つのサービスを削除する場合に用い、「全削除（remove_all）」は、全てのサービスのデスクランブルが必要でなくなった場合に用いられる。
【００９０】
service_idフィールドは、program_map_PIDを適用できるサービスを特定するフィールドである。
【００９１】
number_of_elementary_PID_definitionフィールドは、後続するelementary_PIDフィールドの数を示すフィールドである。
【００９２】
各elementary_PIDフィールドは、Ｆｉｇ．７（ｃ）に示す例に対応している。
【００９３】
stream_typeフィールドは、elementary_PIDフィールドにより値が特定されたＰＩＤを有するパケットにより搬送されているサービス要素の種類を識別するフィールドである。この値は、動画の汎用符号化及び関連する音声システム、ＩＳＰ／ＩＥＣ１３８１８−１（ISP/IEC 13818-1 Generic Coding of Moving Picture and Associated Audio System）における表２〜表２９において定義されている。
【００９４】
elementary_PIDフィールドは、関連するサービス要素を搬送するトランスポートストリームパケットのＰＩＤを特定するフィールドである。
【００９５】
ＣＡイネーブル制御コマンドを受信すると、ＣＡサブユニットは、Ｆｉｇ．８（ａ）に示すような応答を、Ｆｉｇ．８（ｂ）に示すような放送方式固有のデータと共に生成する。
【００９６】
オペランドは、ＣＡイネーブル制御コマンドの場合と同様の意味を有しており、応答フォーマットは、追加的な状態オペランドを有する制御コマンドと同様のものである。
【００９７】
動作が「追加」又は「更新」であり、ＣＡイネーブルコマンドが有効に送信された場合、応答は受理（ACCEPTED）となる。また、応答として返される状態（status）は、以下の値をとる。状態の値は、動作を反映している。
【００９８】
【表９】
【００９９】
追加又は送信コマンドが有効に送信された場合、応答はデスクランブル中（descrambling）となる。一方、理論的にデスクランブルは可能であるが、デスクランブルを実行する前にある条件を満たす必要がある場合がある。この場合、条件によりスクランブル可能であることを示すscrambling possible under conditionsメッセージが返される。条件の応答には、購入ダイアログ（purchase dialogue）と技術ダイアログ（technical dialog）の２種類がある。この２つのダイアログには、マンマシンインタフェース（man machine interface（ＭＭＩ））を介したユーザによる相互作用（インタラクション）が必要である。
【０１００】
購入ダイアログは、例えば、ユーザがペイパービューサービスを要求した場合などに必要である。ここで、ユーザは視聴を開始する前に、サービスの料金を確認することができる。
【０１０１】
技術ダイアログは、ＣＡサブユニットがサービスをデスクランブルできるか否かを判定する前に、技術的課題を解決しなくてはならない場合に必要である。これは、例えば、ユーザがスマートカードを挿入しなくてはならない場合等に用いられる。
【０１０２】
CA_ENABLEコマンドの送信に失敗した場合、応答フレームは、拒絶を示すコードREJECTEDを返す。発生したエラーの種類を示すために、状態フィールドは、以下の値をとる。状態の値は動作を反映している。
【０１０３】
【表１０】
【０１０４】
ＣＡイネーブルコマンドは、状態（STATUS）及び通知（NOTIFY）といったコマンドタイプ（ctype）によって送信することができる。Ｆｉｇ．６では、これらをそれぞれ「Ｓ」及び「Ｎ」で示している。状態コマンド及び通知コマンドフレームは、制御コマンドと同様のフレームを有している。このコマンドは、ＣＡサブユニットが選択されたサービスをデスクランブルする能力を有しているか否かを判定するために使用される。Ｆｉｇ．９は、ＤＶＢ方式固有のオペランド用の放送方式固有のデータを示す図である。各フィールドは、制御コマンドと同様のものである。
【０１０５】
ＣＡイネーブル状態及び通知コマンドに対する応答において、ＣＡサブユニットは、応答情報を生成する。Ｆｉｇ．１０もＤＶＢ方式固有のオペランド用の放送方式固有のデータを示す図である。
【０１０６】
各フィールドは、状態フィールドを除いて、コマンド応答（COMMAND response）と同様である。状態フィールドは、以下の値をとる。削除動作は、状態コマンド又は通知コマンドに対しては無効である。
【０１０７】
【表１１】
【０１０８】
ＣＡ権限（CA Entitlement）
ＣＡ権限コマンド（CA entitlement command）は、電子番組ガイド（electronic program guide：以下、ＥＰＧという。）のアプリケーションに使用される。すなわち、ＣＡ権限コマンドは、ＥＰＧにおけるサービスに対して、ユーザがどのような権限を有しているかを判定するための情報をＣＡサブユニットに応答させるコマンドである。例えば、ＥＰＧを表示する場合、ＣＡサブユニットに対し、どの番組をデスクランブルすることができるかを応答させておけば、ＥＰＧにおいて、ユーザが視聴可能な番組を示すことができる。このコマンドは、状態（STATUS）及び通知（NOTIFY）といったコマンドタイプ（ctype）によって用いることができる。このコマンドは、ＥＰＧ及びＣＡアプリケーションについて、同一のあるいは連携する供給者が権限情報を付与するための個別の方式を開発することを妨げるものではない。このコマンドは、個別のＥＰＧによりＣＡモジュールに対する問い合わせを行うために使用することができる。
【０１０９】
Ｆｉｇ．１１（ａ）は、ＣＡ権限コマンドを示す図であり、Ｆｉｇ．１１（ｂ）は、ＤＶＢ方式用の放送方式固有のデータを示す図である。
【０１１０】
システムＩＤフィールドは、ＣＡイネーブルコマンドの場合と同様の意味を有している。
【０１１１】
オペランドnetwork_id、original_network_id、transport_stream_id、service_id、event_idは、権限に関する問い合わせが行われているサービスを特定するためのものである。イベントＩＤは、番組配列情報（service information）における他のロケーション識別子によって完全に修飾される。
【０１１２】
ＣＡ権限コマンドに応答して、ＣＡサブユニットは、Ｆｉｇ．１２（ａ）に示すような応答情報を、Ｆｉｇ．１２（ｂ）に示すＤＶＢ方式用の放送方式固有のデータとともに発行する。
【０１１３】
オペランドnetwork_id、original_network_id、transport_stream_id、service_id、event_idは、コマンドと同様である。entitlement_statusフィールドは、ユーザが選択されたサービスを享受する権限を有しているか否かを示すフィールドである。
【０１１４】
【表１２】
【０１１５】
セキュリティ（Security）
ＣＡサブユニットの概念は、汎用受信機が複数のＣＡ方式によって動作できるようにするものであるが、サービスプロバイダは、特定のＣＡサブユニットを特定の統合受信機デコーダ（integrated receiver decoder：以下、ＩＲＤという。）に連携させることを望む場合もある。この場合、ＣＡサブユニットとＩＲＤとの間にアクセス権を設定し（authentication：以下、このようなアクセス権の設定を認証という。）、各機器が正規の相手のみと有効に動作するようにする。
【０１１６】
Ｆｉｇ．１３は、セキュリティコマンド（SECURITY command）の構造を示す図である。このセキュリティコマンドは、各アプリケーションが固有に定義するものであり、放送方式からは独立している。認証プロトコルは、ＩＲＤとＣＡサブユニットが互いに制御コードを交換し、相手方の機器が正当な権限を有する正規の機器であることを確認し、安全性を確保する処理を行う。認証プロトコルは、これらの機器間で、２つの既知のキーを転送するといった単純な処理でもよく、あるいは、例えば公開キープロトコルに基づくより複雑なキーの交換を行う処理であってもよい。
【０１１７】
categoryフィールドは、これに続くcategory dependentフィールドにおいて使用される認証及びキー交換プロトコルを定義するフィールドである。
【０１１８】
実施例（Implementation）
以下、ＣＡサブユニットの実施例及びこのＣＡサブユニットを用いて行われる処理について説明する。
【０１１９】
ＮＣＡＭは、ネットワークに接続されるＣＡシステムを実現するために必要な機能を提供するサブユニットの論理的な集合体である。ＣＡサブユニットは、ＣＡシステムの中心的存在（core）であり、マテリアルの供給、デスクランブルが必要なマテリアルの格納、ユーザ及び外部世界との通信等の処理は、他のサブユニットに行わせる。したがって、ＣＡサブユニットは、チューナサブユニット及びパネルサブユニットと連携しなくてはならない。
【０１２０】
ＮＣＡＭは、最小限の構成として、チューナサブユニット、ＣＡサブユニット及びパネルサブユニットのみにより実現することができる。さらに、ＣＡシステムは、リソース、例えばモデム及び／又はスマートカードリーダを要求してもよく、これらは同一のユニットの一部を構成する場合、これらに個別にアクセスすることができる。
【０１２１】
スクランブルされたトランスポートストリームをデコードする処理について、Ｆｉｇ．１４を参照して説明する。以下の説明では、チューナサブユニットをスクランブルされたトランスポートストリームの供給源と考える。このトランスポートストリームは、適切なフロントエンド回路を介して供給された地上波放送であってもよく、直接ＤＭＵＸからＤＶＣＲ等の他のデータ供給源を介して供給された信号であってもよい。ユーザは、チャンネルを選択するための操作を行い、チューナサブユニットは、トランスポートストリームがスクランブルされていることを検出する。
【０１２２】
コントローラは、トランスポートストリームからのCA_System_idフィールドとＣＡサブユニットのCA_system_idフィールドとに基づいて、どのＣＡサブユニットを使用するかに関する知的予測（intelligent prediction）を行うことができる。例えば、Ｆｉｇ．１５に示す具体例では、衛星放送ＩＲＤは、ＩＥＥＥ１３９４シリアルバスを介してＣＡサブユニットに接続されている。
【０１２３】
コントローラは、ＣＡサブユニットにスクランブルされたサービスを供給するために、チューナサブユニットとＣＡサブユニットとの間のアイソクロノスチャンネルを確立する。さらに、データを格納するための機器とＣＡサブユニットとの間の第２のチャンネルを確立する。この機器は、スクランブルされたソースマテリアルを供給した機器と同一の機器であってもよく、異なる機器であってもよい。ここで、トランスポートストリームのデスクランブル処理において、例えば５Ｃコピー防止方式（5C Copy Protection System）又はその他の適切なコピー防止機構を用いて、不正なコピーを防止することもできる。
【０１２４】
コントローラは、ＣＡサブユニットにCA_ENABLEコマンドを送信し、デスクランブルしてほしい１つ以上のサービスを知らせる。ＣＡサブユニットは、CA_ENABLEコマンドを受信し、選択されたサービスをデスクランブルする能力を自らが有しているか否かを判定する。この処理には、ユーザに対するダイアログを設定し、ユーザがサービス享受のための料金を支払う意志があるか否かを確認する処理、又はユーザに対し料金支払いのためのカードの挿入又は暗証番号の入力を促す処理を含む。
【０１２５】
ユーザダイアログの後、ＣＡサブユニットが選択されたサービスをデスクランブルできる状態になった場合、ＣＡサブユニットは、内部の状態レジスタを更新し、デスクランブルしたデータの出力を開始する。
【０１２６】
各コマンドが応答を必要とするというＡＶ／Ｃコマンドの性質に起因して、元のCA_ENABLEコマンドに対して、ユーザダイアログ又は技術ダイアログが必要であるためにREJECTED応答が返された場合、そのダイアログにより問題が解決されても、コントローラはその結果を知ることができない。そこで、CA_ENABLEコマンドがダイアログの理由で拒絶された場合、コントローラは、NOTIFYコマンドを送信し、ＣＡサブユニットの状態が変化したことをＣＡサブユニットに報告させる必要がある。
【０１２７】
ＥＭＭ処理（EMM handling）
ＤＴＶ受信機の実施例の幾つかにおいて、ＣＡモジュールは、ＤＴＶがスタンバイ状態又は電源オン状態にあるときに、ＥＭＭを受信することができる。これにより、ＣＡモジュールは、ユーザが有している権限を継続的に更新することができる。
【０１２８】
ネットワーク環境において、ＣＡサブユニットにＥＭＭパケットを処理させるためには、ＴＳをＣＡサブユニットに送らなければならない。したがって、ＣＡサブユニットの電源がオフ状態のままの場合、又はＴＳがＣＡサブユニットに一定期間接続されなかった場合、ＣＡサブユニットに格納されている権限情報は、旧いものとなってしまう。したがって、ＣＡサブユニットは、周期的にチューナサブユニットに接続し、ＴＳを要求し、ＥＭＭを更新する必要がある。この処理は、ユーザの邪魔にならないように行うべきである。コントローラは、ユーザが特定のサービスを視聴している間、チャンネルを変更するような処理は行わない。
【０１２９】
チューナサブユニットがない場合
チューナサブユニットを備えるネットワークにおいて、ＣＡサブユニットの使用は、チューナサブユニットが設けられたユニット及びＣＡサブユニットが設けられたユニットの外部にコントローラが存在する場合に、特に有効である。これにより、コントローラは、チューナサブユニットが受信する能力を有するサービスを検出し、ＣＡサブユニットに、これらのサービスの幾つかをデスクランブルするように指示することができる。
【０１３０】
チューナサブユニットが存在しないネットワークにおいて、ＣＡサブユニットを用いる場合もある。この場合、ＣＡサブユニットを利用するためには、コントローラは、データ源となるユニット内に設ける必要がある。コントローラは、このユニット内でトランスポートストリームを個別に検査し、デスクランブルすべきサービスの要素のＰＩＤを判定する。ここでも、デスクランブルする要素のＰＩＤにＥＭＭが含まれている必要がある。
【特許請求の範囲】
【請求項１】
スクランブルされたデジタルコンテンツ信号を受信する受信手段と、
上記受信手段により受信された上記スクランブルされたデジタルコンテンツ信号を限定受信サブユニットに出力するとともに、該限定受信サブユニットからローカルスクランブルデジタルコンテンツ信号を入力するインタフェース手段と、
上記限定受信サブユニットから入力された上記ローカルスクランブルデジタルコンテンツ信号をローカルデスクランブルして、デジタルコンテンツ信号を生成するローカルデスクランブル手段とを備え、
上記限定受信サブユニットから入力されるローカルスクランブルデジタルコンテンツ信号は、該限定受信サブユニットにおいて、上記受信されたスクランブルされたデジタルコンテンツ信号をデスクランブルし、更に、ローカルスクランブルした信号であり、
上記限定受信サブユニットは、同時に複数の個別のストリーム又はサービスをデスクランブルすることを特徴とするデジタルコンテンツ受信機。
【請求項２】
当該デジタルコンテンツ受信機が認証されたときだけ、上記ローカルスクランブルデジタルコンテンツ信号をローカルデスクランブルすることを特徴とする請求項１記載のデジタルコンテンツ受信機。
【請求項３】
上記限定受信サブユニットは、該限定受信サブユニット内に格納されている権限管理メッセージを更新するのに十分な期間、上記受信手段から上記スクランブルされたデジタルコンテンツ信号を受信することを特徴とする請求項１記載のデジタルコンテンツ受信機。
【請求項４】
スクランブルされたデジタルコンテンツ信号を受信手段で受信するステップと、
上記受信されたスクランブルされたデジタルコンテンツ信号を限定受信サブユニットに出力するステップと、
上記限定受信サブユニットにおいて、上記スクランブルされたデジタルコンテンツ信号をデスクランブルして、デジタルコンテンツ信号を生成し、該生成されたデジタルコンテンツ信号をローカルスクランブルして、ローカルスクランブルデジタルコンテンツ信号を生成するステップと、
上記限定受信サブユニットからローカルスクランブルデジタルコンテンツ信号を上記受信手段に入力するステップと、
上記受信手段において、上記入力されたローカルスクランブルデジタルコンテンツ信号をローカルデスクランブルして、デジタルコンテンツ信号を生成するステップと
を有し、
上記限定受信サブユニットから入力されるローカルスクランブルデジタルコンテンツ信号は、該限定受信サブユニットにおいて、上記受信されたスクランブルされたデジタルコンテンツ信号をデスクランブルし、更に、ローカルスクランブルした信号であり、
上記限定受信サブユニットにおいて、同時に複数の個別のストリーム又はサービスをデスクランブルすることを特徴とするデジタルコンテンツ受信方法。
【請求項１】
スクランブルされたデジタルコンテンツ信号を受信する受信手段と、
上記受信手段により受信された上記スクランブルされたデジタルコンテンツ信号を限定受信サブユニットに出力するとともに、該限定受信サブユニットからローカルスクランブルデジタルコンテンツ信号を入力するインタフェース手段と、
上記限定受信サブユニットから入力された上記ローカルスクランブルデジタルコンテンツ信号をローカルデスクランブルして、デジタルコンテンツ信号を生成するローカルデスクランブル手段とを備え、
上記限定受信サブユニットから入力されるローカルスクランブルデジタルコンテンツ信号は、該限定受信サブユニットにおいて、上記受信されたスクランブルされたデジタルコンテンツ信号をデスクランブルし、更に、ローカルスクランブルした信号であり、
上記限定受信サブユニットは、同時に複数の個別のストリーム又はサービスをデスクランブルすることを特徴とするデジタルコンテンツ受信機。
【請求項２】
当該デジタルコンテンツ受信機が認証されたときだけ、上記ローカルスクランブルデジタルコンテンツ信号をローカルデスクランブルすることを特徴とする請求項１記載のデジタルコンテンツ受信機。
【請求項３】
上記限定受信サブユニットは、該限定受信サブユニット内に格納されている権限管理メッセージを更新するのに十分な期間、上記受信手段から上記スクランブルされたデジタルコンテンツ信号を受信することを特徴とする請求項１記載のデジタルコンテンツ受信機。
【請求項４】
スクランブルされたデジタルコンテンツ信号を受信手段で受信するステップと、
上記受信されたスクランブルされたデジタルコンテンツ信号を限定受信サブユニットに出力するステップと、
上記限定受信サブユニットにおいて、上記スクランブルされたデジタルコンテンツ信号をデスクランブルして、デジタルコンテンツ信号を生成し、該生成されたデジタルコンテンツ信号をローカルスクランブルして、ローカルスクランブルデジタルコンテンツ信号を生成するステップと、
上記限定受信サブユニットからローカルスクランブルデジタルコンテンツ信号を上記受信手段に入力するステップと、
上記受信手段において、上記入力されたローカルスクランブルデジタルコンテンツ信号をローカルデスクランブルして、デジタルコンテンツ信号を生成するステップと
を有し、
上記限定受信サブユニットから入力されるローカルスクランブルデジタルコンテンツ信号は、該限定受信サブユニットにおいて、上記受信されたスクランブルされたデジタルコンテンツ信号をデスクランブルし、更に、ローカルスクランブルした信号であり、
上記限定受信サブユニットにおいて、同時に複数の個別のストリーム又はサービスをデスクランブルすることを特徴とするデジタルコンテンツ受信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２０１３−５５６８０（Ｐ２０１３−５５６８０Ａ）
【公開日】平成２５年３月２１日（２０１３．３．２１）
【国際特許分類】
【出願番号】特願２０１２−２３８６９６（Ｐ２０１２−２３８６９６）
【出願日】平成２４年１０月３０日（２０１２．１０．３０）
【分割の表示】特願２００９−２９９１８５（Ｐ２００９−２９９１８５）の分割
【原出願日】平成１１年５月５日（１９９９．５．５）
【出願人】（５９３０８１４０８）ソニー ヨーロッパ リミテッド (93)
【Ｆターム（参考）】
【公開日】平成２５年３月２１日（２０１３．３．２１）
【国際特許分類】
【出願日】平成２４年１０月３０日（２０１２．１０．３０）
【分割の表示】特願２００９−２９９１８５（Ｐ２００９−２９９１８５）の分割
【原出願日】平成１１年５月５日（１９９９．５．５）
【出願人】（５９３０８１４０８）ソニー ヨーロッパ リミテッド (93)
【Ｆターム（参考）】
[ Back to top ]