JP3688918B2 - 放送受信装置 - Google Patents
放送受信装置 Download PDFInfo
- Publication number
- JP3688918B2 JP3688918B2 JP36927698A JP36927698A JP3688918B2 JP 3688918 B2 JP3688918 B2 JP 3688918B2 JP 36927698 A JP36927698 A JP 36927698A JP 36927698 A JP36927698 A JP 36927698A JP 3688918 B2 JP3688918 B2 JP 3688918B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- package
- channel
- contract
- contract information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、暗号化（スクランブル）されて放送配信される放送コンテンツを契約内容（期間、視聴チャネル）に応じて復号（デスクランブル）する有料放送サービスのための放送受信装置に関する。
【０００２】
【従来の技術】
ディジタル放送は、通信衛星（ＣＳ）に始まって、ケーブルＴＶ、地上放送へとディジタル化が進むにつれ、一層のサービスの充実が期待されており、これからの放送サービスの主役を務めていくものと思われる。
【０００３】
ディジタル放送の最大の特徴は、情報圧縮技術の導入により、番組の送信に要する周波数の使用効率の向上が図れ、アナログ放送に比較して放送チャネル数の大幅な増加が可能となったことである。さらに、高度な誤り訂正技術が適用できるため、高品質で均質なサービスの提供が可能となる。
【０００４】
放送のディジタル化により、多様な情報形態（映像、音声、文字、データ等）によるマルチメディアサービスの提供が可能となり、そのようなサービスを提供するためのシステムも続々と登場してきている。
【０００５】
このようなシステムで、契約内容に基づいてスクランブルを解く、あるいは復号する有料放送サービスを提供する際、契約期間に即した顧客管理が行えなければならない。契約期間に即した顧客管理とは、例えば、所定の料金の支払いより契約された契約期間内に限って契約チャネルの番組の視聴を可能とするというものである。
【０００６】
また、受信装置にてスクランブルあるいは暗号をとくための鍵情報は、不正視聴を防止する上からも正当な視聴者のみに（契約チャネル、契約期間に即して）しかも確実に提供する必要がある。
【０００７】
これを実現するため、従来は放送受信装置毎にマスター鍵を用意し、受信契約している視聴者に対して受信契約しているチャネルのワークキーのみをマスター鍵で暗号化して送っていた。ここでワークキーはチャネル固有の鍵であり、暗号化されて送られてくる当該チャネルのチャネルキーを復号することができる。チャネルキーはスクランブルされた放送コンテンツをデスクランブルするのに用いられる。
【０００８】
さらに、ワークキーは契約期間（通常１ヶ月）毎に設定され、その期間毎に放送局から送られて来る。このため契約期間毎各契約者に必要十分なワークキーを送らなくてはならない。だが逆に見ればワークキーが更新されることにより確実に契約期間が守られるという長所があった。しかし、このシステムを取る限り１ヶ月毎に全契約者に対してワークキーを放送波で送らなければならす、ＣＳ放送の契約者やチャネルが増加傾向にある今日送信量の観点からはかなり厳しくなりつつある。
【０００９】
さらに、今後進行する多チャネル化の流れとデジタルテレビの普及に伴う契約者数の増大は更に限定受信のために送信すべき情報の増加を招くことになる。
【００１０】
【発明が解決しようとする課題】
以上のように、有料放送のチャネルの増大傾向および契約者の増大傾向により、限定受信のために放送配信すべき情報は増大の一途を辿る傾向にある。しかし、限定受信のために放送配信すべき情報に使用できる帯域には限りがあり、このままだとチャネルの増大および契約者の増大をサポートできないという状態に陥ってしまうことが予想される。
【００１１】
本発明は、上記事情を考慮してなされたもので、有料放送の多チャネル化やその契約者が増大するなどした場合においても同程度の安全性を保ちながら限定受信を実現可能とする放送受信装置を提供することを目的とする。
【００１２】
また、本発明は、有料放送の多チャネル化やその契約者が増大するなどした場合において限定受信の制御のために放送配信すべき情報の量の増大を防ぐことのできる放送受信装置を提供することを目的とする。
【００１３】
【課題を解決するための手段】
本発明は、暗号化されて放送配信されるチャネル毎の契約状態に関する情報を含む契約情報に基づいて、暗号化されて放送配信されるコンテンツ情報の復号を可能とするか不能とするかをチャネル毎に制御する放送受信装置であって、受信された前記暗号化された契約情報を復号する復号手段と、この復号された契約情報内に記述されている対応する放送受信装置を指示する情報に基づいて、該契約情報が自装置に対応するものであるか否かを判断する手段と、自装置に対応するものであると判断された前記契約情報について、該契約情報にて指示すべきチャネルの識別情報の表現形態として、チャネルの識別情報を個別に列挙して指定する第１の表現形態と、複数のチャネルを組にしたパッケージの識別情報を個別に列挙して指定する第２の表現形態とのうちのいずれが用いられているかを、該契約情報に付加された表現形態の種別を示す情報によって判定する手段と、この手段により前記契約情報によりパッケージの識別情報が指定されていると判定された場合に、該契約情報とは別に放送配信される、パッケージの識別情報と、該パッケージに包含される複数のチャネルの識別情報を定義した情報とを含むパッケージ定義情報のうち、該当するものを参照して、前記契約情報により指定されたパッケージに包含される複数のチャネルの識別情報を特定する特定手段と、受信した前記契約情報に含まれるチャネルの識別情報と、受信した前記契約情報に含まれるパッケージの識別情報について前記特定手段により特定されたチャネルの識別情報とに基づいて、前記チャネル毎の制御の内容を定める処理手段とを備えたことを特徴とする。
また、本発明は、暗号化されて放送配信されるチャネル毎の契約状態に関する情報を含む契約情報に基づいて、暗号化されて放送配信されるコンテンツ情報の復号を可能とするか不能とするかをチャネル毎に制御する放送受信装置であって、受信された前記暗号化された契約情報を復号する復号手段と、この復号された契約情報内に記述されている対応する放送受信装置を指示する情報に基づいて、該契約情報が自装置に対応するものであるか否かを判断する手段と、自装置に対応するものであると判断された前記契約情報であってチャネルの識別情報群と複数のチャネルを組にしたパッケージの識別情報群とを予め定められた順番で混載可能なものについて、該契約情報に含まれるチャネルの識別情報の個数を示す情報と、パッケージの識別情報の個数を示す情報とに基づいて、該契約情報に含まれる各々の識別情報が、チャネルの識別情報かパッケージの識別情報かを判定する手段と、この手段により前記契約情報にパッケージの識別情報と判定されたものが存在する場合に、該契約情報とは別に放送配信される、パッケージの識別情報と、該パッケージに包含される複数のチャネルの識別情報を定義した情報とを含むパッケージ定義情報のうち、該当するものを参照して、前記契約情報に含まれるパッケージに包含される複数のチャネルの識別情報を特定する特定手段と、受信した前記契約情報に含まれるチャネルの識別情報と、受信した前記契約情報に含まれるパッケージの識別情報について前記特定手段により特定されたチャネルの識別情報とに基づいて、前記チャネル毎の制御の内容を定める処理手段とを備えたことを特徴とする。
また、本発明は、暗号化されて放送配信されるチャネル毎の契約状態に関する情報を含む契約情報に基づいて、暗号化されて放送配信されるコンテンツ情報の復号を可能とするか不能とするかをチャネル毎に制御する放送受信装置であって、受信された前記暗号化された契約情報を復号する復号手段と、この復号された契約情報内に記述されている対応する放送受信装置を指示する情報に基づいて、該契約情報が自装置に対応するものであるか否かを判断する手段と、自装置に対応するものであると判断された前記契約情報について、該契約情報にて指示すべきチャネルの識別情報の表現形態として、チャネルの識別情報を個別に列挙して指定する第１の表現形態と、複数のチャネルを組にしたパッケージの識別情報を個別に列挙して指定する第２の表現形態とのうちのいずれが用いられているかを、該契約情報に付加された表現形態の種別を示す情報によって判定する手段と、この手段により前記契約情報によりパッケージの識別情報が指定されていると判定された場合に、該契約情報とは別に放送配信される、パッケージの識別情報と、該パッケージに包含される複数のチャネルの識別情報を定義した情報または該パッケージに含まれる別のパッケージの識別情報の少なくとも一方とを含むパッケージ定義情報のうち、該当するものを参照して、前記契約情報により指定されたパッケージに包含される複数のチャネルの識別情報を特定する特定手段と、受信した前記契約情報に含まれるチャネルの識別情報と、受信した前記契約情報に含まれるパッケージの識別情報について前記特定手段により特定されたチャネルの識別情報とに基づいて、前記チャネル毎の制御の内容を定める処理手段とを備え、前記特定手段は、或るパッケージの識別情報から該或るパッケージに包含される全てのチャネルの識別情報を特定するにあたって、参照した或るパッケージ定義情報に他のパッケージの識別子が含まれている場合には、該他のパッケージの識別子に該当する他のパッケージ定義情報を参照して、該他のパッケージに包含されるチャネルの識別情報を特定するとともに、該他のパッケージ定義情報に更に他のパッケージの識別子が含まれているならば、次々と該当するパッケージ定義情報を参照することを繰り返すことによって、全てのチャネルの識別情報を特定することを特徴とする。
また、本発明は、暗号化されて放送配信されるチャネル毎の契約状態に関する情報を含む契約情報に基づいて、暗号化されて放送配信されるコンテンツ情報の復号を可能とするか不能とするかをチャネル毎に制御する放送受信装置であって、受信された前記暗号化された契約情報を復号する復号手段と、この復号された契約情報内に記述されている対応する放送受信装置を指示する情報に基づいて、該契約情報が自装置に対応するものであるか否かを判断する手段と、自装置に対応するものであると判断された前記契約情報であってチャネルの識別情報群と複数のチャネルを組にしたパッケージの識別情報群とを予め定められた順番で混載可能なものについて、該契約情報に含まれるチャネルの識別情報の個数を示す情報と、パッケージの識別情報の個数を示す情報とに基づいて、該契約情報に含まれる各々の識別情報が、チャネルの識別情報かパッケージの識別情報かを判定する手段と、この手段により前記契約情報にパッケージの識別情報と判定されたものが存在する場合に、該契約情報とは別に放送配信される、パッケージの識別情報と、該パッケージに包含される複数のチャネルの識別情報を定義した情報または該パッケージに含まれる別のパッケージの識別情報の少なくとも一方とを含むパッケージ定義情報のうち、該当するものを参照して、前記契約情報に含まれるパッケージに包含される複数のチャネルの識別情報を特定する特定手段と、受信した前記契約情報に含まれるチャネルの識別情報と、受信した前記契約情報に含まれるパッケージの識別情報について前記特定手段により特定されたチャネルの識別情報とに基づいて、前記チャネル毎の制御の内容を定める処理手段とを備え、前記特定手段は、或るパッケージの識別情報から該或るパッケージに包含される全てのチャネルの識別情報を特定するにあたって、参照した或るパッケージ定義情報に他のパッケージの識別子が含まれている場合には、該他のパッケージの識別子に該当する他のパッケージ定義情報を参照して、該他のパッケージに包含されるチャネルの識別情報を特定するとともに、該他のパッケージ定義情報に更に他のパッケージの識別子が含まれているならば、次々と該当するパッケージ定義情報を参照することを繰り返すことによって、全てのチャネルの識別情報を特定することを特徴とする。
【００２４】
なお、放送受信装置に係る発明は対応する放送送信装置に係る発明としても成立し、放送送信装置に係る発明は対応する放送受信装置に係る発明としても成立する。
【００２５】
また、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
【００２６】
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００２７】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００２８】
最初に、語句の定義を行なう。
【００２９】
チャネル毎の契約状態を記述した情報を「チャネル契約情報」と呼ぶ。チャネル契約情報は、限定受信を行なうために放送局側から放送受信装置側に放送される制御情報である。
【００３０】
例えば、各チャネルにチャネル番号を付け、図２のようにチャネル番号に対応したビットが１であるか否かによりチャネルの契約状態を表したビット列が、チャネル契約情報の一形態である。図２では、例えば、第２、第５、第７、第８チャネルが契約済であり、第１、第３、第４、第６チャネルが未契約であることを示すことができる。
【００３１】
図２のように各チャネル毎にその契約の有無を表記した情報を「チャネル展開情報」と呼ぶ。全チャネルでｎチャネルあるならば、チャネル展開情報はｎビットのデータとなる。
【００３２】
なお、本実施形態では、限定受信のために放送すべき情報の削減のために、放送局側から放送受信装置側に放送配信するチャネル契約情報の形態としてチャネル展開情報そのものを使用することはせず、後述するように工夫した形態のチャネル契約情報を使用する。放送受信装置側では、自装置に対応するチャネル契約情報を１または複数受信し、これに基づいて最終的に全チャネルに対応した総合的なチャネル展開情報（これを特に総合チャネル展開情報と呼ぶ）を作成・保持し、これに基づいて限定受信のための制御を行うことになる。
【００３３】
しかして、チャネル契約情報は、各受信装置に固有の「受信装置ＩＤ」と相互にリンクされており、当該チャネル契約情報が適用される受信装置ＩＤを示している。この意味でチャネル契約情報と受信装置ＩＤとは一体のものであり、受信装置ＩＤとチャネル契約情報の組を「契約情報」と呼ぶ。
【００３４】
契約情報の改ざんや、不利な契約情報の不取得（例えば契約解除のために放送配信される契約情報の不受信もしくは廃棄等）を防ぐ目的で、契約情報は、暗号化されて放送配信されるとともに、その暗号化の際に、他の情報とセットにして暗号化される（この結果、それらはセットで放送される）。この契約情報と一緒にして暗号化されるデータセットを「受信契約情報」と呼ぶことにする（もちろん受信契約情報には契約情報も含まれる）。
【００３５】
また、本実施形態では、複数のチャネルを組にしたパッケージという概念を使用する。各パッケージの内容（例えばパッケージに含まれるチャネルの組み合わせ）を定義するための情報を「パッケージ定義情報」と呼ぶ。
【００３６】
パッケージ定義情報は、契約情報と同様、他の情報とセットにして暗号化して放送配信される。このパッケージ定義情報と一緒にして暗号化されるデータセットを「受信パッケージ情報」と呼ぶ。
【００３７】
なお、「契約情報」と「パッケージ定義情報」とを総称して「契約関連情報」と呼ぶ。また、受信契約情報と受信パッケージ情報とを総称して「受信契約関連情報」と呼ぶ。
【００３８】
さらに、暗号化された受信契約情報にデータの識別子など本システムに必要な情報を付加したものを「契約情報パケット」と呼び、暗号化された受信パッケージ情報にデータの識別子など本システムに必要な情報を付加したものを「パッケージ情報パケット」と呼び、「契約情報パケット」と「パッケージ情報パケット」とを総称して「契約関連情報パケット」と呼ぶ。
【００３９】
放送受信装置内部で限定受信の仕組みを実現するためのハードウェアを「課金チップ」と呼ぶ。課金チップは、限定受信のために必要な秘密情報をその内部に含むことになるので、その内部のメモリやハード構成に関して外部から容易に読み出し、書き込み、変更ができないように、一体化したＬＳＩとして構成し、耐タンパ構造を有することを仮定している。
【００４０】
課金チップ内部のメモリには、全受信装置に共通のマスター鍵またはそれを生成する機能が含まれているものとする。マスター鍵は、主に受信契約関連情報（受信契約情報、受信パッケージ情報）を復号するために用いられる。
【００４１】
受信装置ＩＤは、受信装置毎個別に設定され、課金チップ内部の不揮発性メモリの中に記録されているものとする。
【００４２】
（第１の実施形態）
第１の実施形態は、契約者（視聴者）やチャネル数が増加しても、限定受信のために放送配信すべき契約情報の増加を抑えることを可能とするために、２種類以上の形態のチャネル契約情報を適宜用いることにより、該情報を削減可能としたものである。
【００４３】
以下、本実施形態の放送受信装置について説明する。
【００４４】
図１に、本実施形態に係る放送受信装置の構成例を示す。
【００４５】
図１に示されるように、本放送受信装置は、受信部１０１、Ａ／Ｄ変換部１０２、誤り検出／訂正部１０３、チャネル選択部１０４、チャネル選択インタフェース（Ｉ／Ｆ）１０５、課金制御部（課金チップ）１０６を有する。また、課金制御部１０６すなわち課金チップには、フィルター部１０７、デスクランブル部１０８、マスター鍵シード認証部１０９、契約関連情報復号部１１０、マスター鍵生成部１１１、マスター鍵格納部１１２、受信装置ＩＤ格納部１１３、契約情報認証部１１４、パッケージ定義情報認証部１１５、契約情報格納部１１６、チャネルキー格納部１１７、契約判定部１１８、チャネル情報入力部１１９、チャネルキー出力部１２０が作り込まれ、耐タンパー性が付与されている。
【００４６】
本実施形態の放送受信装置で受信されるチャネルは、「通常チャネル」と「契約情報チャネル」に大別することができる。通常チャネルには通常の放送コンテンツ（放送コンテンツパケット）が多重化されて流れている。契約情報チャネルには、主に契約関連情報（契約関連情報パケット）と、それよりは少ない頻度でマスター鍵シード（マスター鍵シードパケット）とが流れている。前述のように「契約関連情報」とは「契約情報」と「パッケージ定義情報」の２つであるが、それらのデータ構造を含む詳細については以下で説明する。
【００４７】
なお、契約情報チャネルでは、各情報はそれが変更されたときにだけ放送されるのではなく、同じ内容の情報が、例えば一定期間、繰り返し放送される。
【００４８】
本実施形態の放送受信装置は、その動作中において、上記のような契約情報チャネルと１つ以上の通常チャネルを常時受信するものである。
【００４９】
本実施形態の放送コンテンツは、図３に示すように、３段の暗号化機構によって保護される。
【００５０】
チャネルキーＫｃｈは、スクランブル（暗号化）された放送コンテンツをデスクランブル（復号）するための鍵であり、短期間で変更される。本実施形態ではチャネルキーはチャネル毎に定められるものとする。また、本実施形態では、チャネルキーは、契約情報やパッケージ定義情報とともに、マスター鍵ＫＭで暗号化されて放送配信されるものとする。すなわち、チャネルキーは契約関連情報パケット（受信契約情報や受信パッケージ情報）に含まれた形で送信されるものとする。
【００５１】
マスター鍵ＫＭは、マスター鍵シードＳＭによって定期的に変更される。すなわち、本実施形態では、課金チップ内部には、全受信装置に共通の、マスター鍵シードからマスター鍵を生成する仕組みが作り込まれているものとする。また、本実施形態では、マスター鍵シードは暗号化されずに放送配信されるものとする。
【００５２】
なお、マスター鍵シードを変更する間隔は、チャネルキーを変更する間隔よりも、かなり長くして構わない。例えば、チャネルキーを数秒毎に変更し、マスター鍵シードを１ヶ月毎に変更するようにしてもよい。
【００５３】
以下では、放送される各種データについて説明する。
【００５４】
まず、放送コンテンツについて説明する。
【００５５】
図４に、放送コンテンツパケットのデータ構造例を示す。
【００５６】
「放送コンテンツ」は、図４に示すように、スクランブルされ、情報識別子、チャネル識別子、チャネルキー識別子をヘッダに持つ固定長パッケージで送信される。
【００５７】
「情報識別子」は、当該パケットが「放送コンテンツパケット」と「契約関連情報パケット」と「マスター鍵シードパケット」のいずれであるかを示す識別子であり、数ビットから数バイトの情報量を有する。図４では、当該パケットが「放送コンテンツパケット」であることを示す識別子が割り当てられる。
【００５８】
「チャネル識別子」は、当該放送コンテンツが対応するチャネルのＩＤを示している。
【００５９】
「チャネルキー識別子」は、当該コンテンツを復号するためのチャネルキーのＩＤを示している。
【００６０】
なお、本実施形態では、チャネル識別子とチャネルキー識別子の組みで、チャネルキーが特定されるものとしているが、チャネルキー識別子のみでチャネルキーが特定されるようにしてもよい。
【００６１】
次に、契約関連情報のうちの契約情報について説明する。
【００６２】
図５に、受信契約情報のデータ構造例を示す。
【００６３】
「契約情報」は、チャネル契約情報とｎ個の受信装置ＩＤの組みとして表現される。ｎが複数である場合、列挙された各受信装置ＩＤを持つｎ個の放送受信装置が、この同じチャネル契約情報を受信することになる。
【００６４】
図５に示すように、契約情報は、放送局側の有する秘密鍵でデジタル署名され、これに署名データがデジタル署名として付加される。そして、デジタル署名を付加した契約情報に、さらに、データ識別子、チャネル識別子、チャネルキー識別子、チャネルキー、ＭＡＣを付加した情報が、受信契約情報となる。
【００６５】
この受信契約情報がマスター鍵ＫＭで暗号化されて送信されることになる。
【００６６】
図５において、「データ識別子」は、当該データが「契約情報」と「パッケージ定義情報」のいずれであるかを識別するための情報である。図５においては、当該データが契約情報であることを示す識別子（パッケージ定義情報とは異なる識別子）が割当てられる。
【００６７】
「チャネルキー」は、放送コンテンツをデスクランブルするための復号鍵である。また、「チャネル識別子」はこのチャネルキーが適用されるチャネルの識別子であり、「チャネルキー識別子」はこのチャネルキー自体の識別子であり、これらは放送コンテンツパケットに含まれるチャネル識別子とチャネルキー識別子に対応付けられる。なお、これらチャネルキーに関する情報は、同じ受信契約情報に含まれる契約情報とは関連性を持たない。
【００６８】
図６に、契約関連情報パケットのデータ構造例を示す。
【００６９】
「契約関連情報」を含む契約関連情報パケットは、図６のように、マスター鍵ＫMで暗号化された契約関連情報（受信契約情報もしくは受信パッケージ情報）に、暗号化されていない情報識別子と暗号化されていないマスター鍵識別子とからなる情報をヘッダとして付加することによって、構成される。
【００７０】
「情報識別子」は、前述と同様で、図６では、当該情報が「契約関連情報」であることを示す識別子が割り当てられる。
【００７１】
「マスター鍵識別子」は、当該契約関連情報を復号するためのマスター鍵のＩＤを示している。
【００７２】
前述のように、契約関連情報パケットには、契約情報（受信契約情報）を含む「契約情報パケット」と、パッケージ定義情報（受信パッケージ情報）を含む「パッケージ情報パケット」とがあり、それらは「データ識別子」で識別されることになる。
【００７３】
ここで、ＭＡＣに関して説明する。
【００７４】
ＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）は、図５において、データ識別子からチャネルキーまでの部分のデータが偽造や送信エラー等によって壊されていないか否かをチェックするためのコードである。ＭＡＣの作成は、例えば、データ識別子からチャネルキーまでの部分のハッシュを取ってそのハッシュ値をチャネルキーを使って暗号化したものをＭＡＣとすることによって可能である。例えば、ハッシュ関数ＳＨＡ１で１６０ビットのハッシュ値を得、その上位６４ビットをチャネルキーでＤＥＳ暗号を使って作成すれば６４ビットのＭＡＣが作成され、ほぼ確実に送信エラーを検出することができる。
【００７５】
ただし、偽造に関してはＭＡＣでは限界がある。なぜならば、特定の受信装置を分解解析して、マスター鍵を検出し、ロジックを解明することができれば、ＭＡＣは作成可能となってしまうからである。そのために、本実施形態では、契約情報の部分にはデジタル署名を別途付加している。
【００７６】
本実施形態で考慮しているデジタル署名とは公開鍵暗号によるもので、署名作成の秘密鍵は放送装置側にのみ存在し、受信装置側に存在する署名検証のための公開鍵から秘密鍵を生成するのが極めて困難であるという性質を持っている。このことは、たとえ受信装置が分解解析されてもデジタル署名の作成が極めて困難なことを意味している。したがって、ＭＡＣは誤り検知、デジタル署名は偽造防止の役割があると考えることができる。
【００７７】
ここで、ＭＡＣの対象範囲がデータ識別子からチャネルキーまでであるのに対し、デジタル署名の範囲をデータ識別子から受信装置ＩＤ列までとしているのは、誤り検出をＭＡＣ、偽造防止をデジタル署名という機能分担以外にも、デジタル署名の生成はＭＡＣの生成に比べると処理時間がかかるという理由がある。デジタル署名を、偽造されて問題になる契約情報の部分にのみかけることによって、突然番組が変更になって、チャネルキーが変更になった場合などデジタル署名を計算し直す必要は生じないため、このような構成は実用上極めて有用である。
【００７８】
次に、契約関連情報のうちのパッケージ定義情報について説明する。
【００７９】
図７に、受信パッケージ情報のデータ構造例を示す。
【００８０】
受信パッケージ情報は、基本的には、前述の受信契約情報の場合と同様である。すなわち、パッケージ定義情報にデータ識別子を付加し、それらに対するデジタル署名を付加し、チャネル識別子とチャネルキー識別子とチャネルキーを付加し、さらに該データ識別子から該チャネルキーまでの範囲を対象としたＭＡＣを付加したデータが、受信パッケージ情報となる。
【００８１】
図７において、「データ識別子」は、当該データがパッケージ定義情報であることを示す情報で、契約情報のデータ識別子と同じデータ長で異なる値を割り当てる。「チャネルキー」、「チャネル識別子」、「チャネルキー識別子」については、前述と同様である。
【００８２】
この受信パッケージ情報がマスター鍵ＫＭで暗号化され、暗号化されていない情報識別子と暗号化されていないマスター鍵識別子とからなる情報がヘッダとして付加されて、送信されることになる。
【００８３】
受信パッケージ情報を載せた契約関連情報パケット（パッケージ情報パケット）のデータ構造については前述した通りである（図６参照）。
【００８４】
なお、パッケージ定義情報の内容の詳細については後述する。
【００８５】
次に、マスター鍵、マスター鍵シードについて説明する。
【００８６】
図８に、マスター鍵シードパケットのデータ構造例を示す。
【００８７】
図８に示されるように、マスター鍵シードに、これに対するデジタル署名が付加され、さらに、それらの範囲を対象としたＭＡＣが付加された情報（マスター鍵シード情報）に、暗号化されていない情報識別子と暗号化されていないマスター鍵識別子とからなる情報がヘッダとして付加されて、送信されることになる。
【００８８】
「情報識別子」は、前述と同様で、図８では、当該情報が「マスター鍵シード」であることを示す識別子が割り当てられる。
【００８９】
マスター鍵ＫＭは、当該マスター鍵シードＳＭによって乱数生成の要領で定期的に変更される。
【００９０】
図８の「マスター鍵識別子」は、当該マスター鍵シードから生成したマスター鍵に割り当てるＩＤを示している。
【００９１】
ところで、本実施形態では、「チャネルキー」は契約関連情報パケット（契約情報パケット、パッケージ情報パケット）によって放送され（例えば各チャネルのチャネルキーが順番に繰り返し放送され）、放送受信装置側では、受信契約関連情報をマスター鍵で復号することによって得られる。得られたチャネルキーは、該パケットに含まれるチャネル識別子とチャネルキー識別子をもとに受信装置内部のチャネルキー格納部１１７に格納される。また、契約情報パケットをマスター鍵で復号した際に、受信契約情報の中には、受信装置ＩＤによってリンクされた放送受信装置宛の「チャネル契約情報」が含まれており、自身の受信装置ＩＤに一致する受信装置ＩＤが含まれている場合には、当該チャネル契約情報は契約情報格納部１１６に記録され、その内容に応じて総合チャネル展開情報が更新されるようになっている。また、パッケージ情報パケットをマスター鍵で復号して得られたパッケージ定義情報も契約情報格納部１１６に記録され、必要に応じて総合チャネル展開情報の更新に使用されるようになっている。放送受信時には、契約情報格納部１１６から契約情報を参照し、当該チャネルが契約済であった場合にのみ上記の手順で取得したチャネルキーをチャネルキー格納部１１７からデスクランブル部１０８に送り、スクランブルされた放送コンテンツをデスクランブルする。このようなシステムを取ることにより、チャネルキーを取得するためには、契約情報やパッケージ定義情報を取得し、それらを当該放送受信装置内での限定受信制御のための総合チャネル展開情報に反映しなければならない必然性が生じ、契約を確実に遵守させることが可能となる。
【００９２】
次に、本実施形態の主目的である、チャネル数が増加した際の契約情報の情報量を削減する方法について説明する。
【００９３】
チャネル数が増加した際、チャネル契約情報をチャネル展開情報そのもので記述すると、２００チャンネルでは２００ビット、１０００チャンネルでは１０００ビットが必要であり、受信装置ＩＤが通常４０ビット程度で足りるのに対し情報量が大きすぎる。また、実際は、契約内容（各受信装置が契約するチャンネルの組み合わせ）の種類は２２００通りも存在しないので、このような情報の大半は無駄であると考えられる。さらに、現行の有料放送システムにおいては、いくつかのチャネルを１つのパッケージにまとめ、パッケージ単位で課金する方式がある。これは、パッケージに含まれる各チャネルを個別に契約するよりも格段に割安であり、普通の契約者はどれかのパッケージを購入し、さらに視聴したいチャネルがあれば数チャネル個別に契約する、というのが普通である。
【００９４】
そこで、本実施形態では、図９および図１０の２種類のチャネル契約情報を使用する。
【００９５】
図９に示すチャネル契約情報は、ＯＮ／ＯＦＦ情報、種別情報、１または複数（図９の例では４個）のチャネルＩＤからなっている。
【００９６】
このようなチャネル契約情報を、「チャネル指定型のチャネル契約情報」と呼ぶ。
【００９７】
「ＯＮ／ＯＦＦ情報」は、チャネルＩＤで指定されるチャネルを契約するのか解約するのかを指定するための情報であり、本実施形態では、契約する場合がＯＮ情報、解約する場合がＯＦＦ情報と定義する。
【００９８】
「種別情報」は、当該チャネル契約情報の種別を示すもので、チャネル契約情報の形態の数（本実施形態では、図９と図１０の２種類）に応じて数ビットから数バイトの情報量を持つ固定長のデータである。図９の場合、種別情報は、チャネル指定型のチャネル契約情報であることを示すものである。
【００９９】
「チャネルＩＤ」は、放送システムにおいて決めているチャネルのＩＤ情報である。例えば、最大１０００チャネルを前提とする場合でも、１０ビットで良い。
【０１００】
このチャネル指定型のチャネル契約情報では、チャネルＩＤのビット数、チャネルＩＤの個数は固定長、固定数であることを前提とする。さらに、ｎ個（ｎは複数）のチャネルＩＤを指定する場合、例えば全てのビットが０であるチャネルＩＤを無効と決めておけば、１〜ｎ−１個の間の任意の個数のチャネルＩＤのみを指定することも可能になる。実際、運用では情報圧縮のため図５のように一つのチャネル契約情報に対して同じ受信契約を行っている受信装置ＩＤを数個付ける必要が生じる。このとき、固定個数（図９の例では４個）の範囲で任意個のＩＤを指定できる方が望ましい。
【０１０１】
一方、図１０に示すチャネル契約情報は、図９に示すチャネルＩＤを指定するタイプのチャネル契約情報とは異なり、パッケージＩＤを指定するタイプのチャネル契約情報である。本チャネル契約情報は、ＯＮ／ＯＦＦ情報、種別情報、１または複数（図１０の例では２個）のパッケージＩＤからなっている。
【０１０２】
このようなチャネル契約情報を、「パッケージ指定型のチャネル契約情報」と呼ぶ。
【０１０３】
ＯＮ／ＯＦＦ情報と種別情報は、前述のチャネル指定型の場合と同様である。図１０の場合、種別情報は、パッケージ指定型のチャネル契約情報であることを示すものである。
【０１０４】
「パッケージＩＤ」は、パッケージを識別するＩＤ情報である。ただし、本実施形態では、そのパッケージにどのようなチャネルが入っているかを示すパッケージの定義情報は、パッケージ定義情報（図６、図７参照）という形で、別途共通に送られる。
【０１０５】
パッケージＩＤのビット数や個数についても、チャネル指定型の場合と同様に、固定長、固定数であることが前提であり、システム毎に定めれば良い。また、同様に、予め無効であるＩＤを定めておき、固定数（図１０の例では２個）の範囲で任意個のパッケージを指定することも可能である。
【０１０６】
図１１に、パッケージ定義情報の構造例を示す。
【０１０７】
「パッケージ定義情報」は、パッケージＩＤとパッケージ展開情報からなっている。パッケージ展開情報は、チャネル展開情報と同様で、図２に示すようなチャネル毎にビットが割り当てられ、パッケージＩＤに対応するパッケージに含まれるチャネルに対応したビットのみ１が立ち、それ以外のビットは０であるようなビット列である。
【０１０８】
本実施形態では、チャネル指定型のチャネル契約情報と、パッケージ指定型のチャネル契約情報およびパッケージ定義情報とを適宜組み合わせて利用することにより、放送すべき契約情報を大幅に削減することができる。これらの情報を受信した放送受信装置側では、最終的にチャネル展開情報（総合チャネル展開情報）の形にして保持することになる。
【０１０９】
以下、本実施形態の受信装置の動作について説明する。
【０１１０】
ここで、図１２に、各種情報とそれらの関連性をまとめて示す。
放送配信されるパケットには、放送コンテンツパケット（放送コンテンツを主な内容とする）、マスター鍵シードパケット（マスター鍵シードを主な内容とする）、契約関連情報パケット（契約関連情報とチャネルキーを主な内容とする）があり、それらは情報識別子により識別される。
契約関連情報パケットには、パッケージ定義情報を搭載するものと、契約情報を搭載するものがあり、それらはデータ識別子により識別される。
契約情報には、チャネル指定型のチャネル契約情報と、パッケージ指定型のチャネル契約情報とがあり、それらは種別情報により識別される。
パッケージ指定型のチャネル契約情報のチャネル構成は、パッケージ定義情報により得られる。
【０１１１】
図１３〜図１８に、本実施形態の放送受信装置の動作手順の一例を示す。
【０１１２】
まず、ユーザの操作によりもしくは予約機能等により自動的に、チャネル選択インターフェース１０５で所望のチャネルが選択されるものとする。チャネル選択インターフェース１０５で選択されているチャネル番号は、チャネル選択部１０４へ伝えられ、またチャネル情報入力部１１９から契約判定部１１８へ伝えられる。
【０１１３】
さて、図１３のステップＳ１において受信部１０１で受信された放送波は、Ａ／Ｄ変換部１０２でＡ／Ｄ変換され（ステップＳ２）、当該放送受信装置内部で処理可能なパケットに再構築され（ステップＳ３）、そして、誤り検出／訂正部１０３で誤り検出／訂正される（ステップＳ４）。
【０１１４】
ここで再構築されたパケットは、放送コンテンツパケット（図４）、契約関連情報パケット（図６）、マスター鍵シードパケット（図８）の３種類のいずれかである。
【０１１５】
誤り検出／訂正された放送波は、チャネル選択部１０４に送られ、チャネル選択インターフェース１０５にて選択されたチャネルに対応する放送コンテンツパケットと、契約情報チャネルの全パケットとが課金制御部１０６に送られる。
【０１１６】
いずれのパケットも先頭に固定長の情報識別子が付いており、フィルター部１０７において情報識別子を参照して当該パケットに対する処理を選択する。すなわち、各種のパケットはフィルター部１０７で分離され、当該パケットが放送コンテンツパケットである場合は（ステップＳ５，Ｓ８）、デスクランブル部１０８へ送られ（ステップＳ９）、当該パケットが契約関連情報パケットである場合には（ステップＳ６）、契約関連情報復号部１１０へ送られ（ステップＳ１０）、当該パケットがマスター鍵シードパケットである場合には（ステップＳ７）、マスター鍵生成部１１１へ送られる（ステップＳ１１〜Ｓ１３）。
【０１１７】
（ｉ）まず、放送コンテンツパケットについて説明する。
【０１１８】
受信したパケットが放送コンテンツパケットである場合、デスクランブル部１０８では、図１４に例示したような手順で処理を行う。
【０１１９】
まず、チャネルキー出力部１２０から、当該放送コンテンツをデスクランブルするためのチャネルキーを取得する（ステップＳ２１）。
【０１２０】
すなわち、図４に示す放送コンテンツパケットに含まれるチャネルＩＤとチャネルキーＩＤとをチャネルキー出力部１２０に対して送信して、チャネルキーの出力を要請する。
【０１２１】
チャネルキー出力部１２０では、この要請を受けて、契約判定部１１８に当該チャネルの受信契約の有無を問い合わせる。契約判定部１１８では、その問い合わせを受けて、契約情報格納部１１６に格納されている総合チャネル展開情報を参照し、当該チャネルの受信契約の有無を判定し（当該チャネルに対応するビットが立っているか否かを判定し）、チャネルキー出力部１２０に回答する。チャネルキー出力部１２０では、当該チャネルの契約が存在する場合には、チャネルキー格納部１１７から当該チャネルＩＤの当該チャネルキーＩＤを持つチャネルキーをデスクランブル部１０８に出力するが、当該チャネルの契約が存在しない場合には、チャネルキーの出力は行わず、例えばＮＵＬＬ信号を出力する。
【０１２２】
デスクランブル部１０８では、チャネルキーが出力された場合にのみ（ステップＳ２２）、放送コンテンツのデスクランブルを行ない（ステップＳ２３）、デスクランブルした放送コンテンツを出力する（ステップＳ２４）。
【０１２３】
（ii）次に、マスター鍵シードパケットについて説明する。
【０１２４】
受信したパケットがマスター鍵シードパケットである場合、マスター鍵生成部１１１は、図１５に例示したような手順で処理を行う。
【０１２５】
まず、マスター鍵生成部１１１では、直前のマスター鍵の生成で使用したマスター鍵シードを参照し、これと当該受信したマスター鍵シードとを比較する。それらが一致した場合には（ステップＳ３１）、その時点で処理を終了する。これは、現在使用しているマスター鍵のもととなったマスター鍵シードと一致している場合には、同じマスター鍵が生成されるだけであるので、無駄な生成を行わないようにするための仕組みである。マスター鍵シードは短い期間で変更する必要のないものではあるが、途中で変更される可能性があるので、放送受信装置の起動時に必ず生成されなければならない。このため、高頻度に送信する必要がある。このような状況において上記のような直前に使用したマスター鍵シードとの比較処理がないと、かなり頻繁に必要のない生成を行わなければならない。
【０１２６】
一方、直前に使用したマスター鍵シードと一致しなかった場合は、マスター鍵シードが偽造されていたり、伝送エラーで不一致が生じたものでないことを、ＭＡＣ、そしてデジタル署名で確認する。この確認はマスター鍵シード認証部１０９が行う。
【０１２７】
デジタル署名は、情報のコンテンツ（この場合はマスター鍵シード・データ）のハッシュ値を情報の送信側（この場合は放送局側）が自分の秘密鍵で暗号化したものである。情報の受信側（この場合は放送受信装置側）は同様にハッシュ値を作成し、デジタル署名を放送局の公開鍵で復号したものと一致することによって、当該情報が偽造されていないことを知るのである。これは公開鍵から秘密鍵を求めるには相当な時間がかかることから、秘密鍵を知る放送局でないと当該情報が作成できないところに根拠をおいている。マスター鍵シードパケットにデジタル署名を付加することにより、マスター鍵シードに伝送誤りがあった場合などに通信障害が起こることを未然に防いでいる。
【０１２８】
マスター鍵シードについて、ＭＡＣが検証され、かつ、デジタル署名が検証された場合（ステップＳ３２）、当該マスター鍵シードからマスター鍵を生成する（ステップＳ３３）。
【０１２９】
マスター鍵の生成は線形合同法などの乱数生成のアルゴリズムを用いて行われるが、そのアルゴリズムおよび生成パラメータは課金チップすなわち課金制御部１０６の中のマスター鍵生成部１１１に非公開で存在している。さらに、全く同じアルゴリズムと生成パラメータが放送装置側にも存在し、このことにより放送局側と受信装置側で同じマスター鍵を共有できる。
【０１３０】
生成されたマスター鍵は、マスター鍵識別子と対応させてマスター鍵格納部１１２に格納する（ステップＳ３４）。また、今回のマスター鍵の生成で使用したマスター鍵シード（今回受信したマスター鍵シード）もマスター鍵格納部１１２に格納する（ステップＳ３５）。
【０１３１】
（iii ）次に、契約関連情報パケットについて説明する。
【０１３２】
受信したパケットが契約関連情報パケットである場合、契約関連情報復号部１１０では、図１６〜図１８に例示したような手順で処理を行う。
【０１３３】
まず、契約関連情報復号部１１０では、図６に示されている契約関連情報パケットからマスター鍵識別子を抽出し、当該マスター鍵識別子のマスター鍵をマスター鍵格納部１１２から取得する（図１６のステップＳ４１）。
【０１３４】
もし、取得に失敗した場合は（ステップＳ４２）、その時点で処理を終了する。
【０１３５】
マスター鍵が取得された場合（ステップＳ４２）、続いて、契約関連情報パケットから暗号化された受信契約関連情報を抽出し、当該マスター鍵で復号する（ステップＳ４３）。
【０１３６】
復号した結果得られる情報は、図５に示す受信契約情報か、図７に示す受信パッケージ情報である。両者の識別は、ＭＳＢ側に書かれたデータ識別子を参照して行う。
【０１３７】
もし、当該受信契約関連情報が受信契約情報であれば（ステップＳ４４）、受信契約情報認証部１１４に送信し、受信パッケージ定義情報であれば（ステップＳ４５）、パッケージ定義情報認証部１１５へ送信する。
【０１３８】
まず、受信契約情報である場合、契約情報認証部１１４へ送られ、ＭＡＣがチェックされる（図１７のステップＳ５１）。ＭＡＣが認証されない場合は、何らかの改ざんか送信エラーが生じていると考えられるので、当該受信契約情報に関する処理を終了する。
【０１３９】
ＭＡＣが認証された場合は、受信契約情報からチャネルキーとチャネル識別子とチャネルキー識別子を抽出し、図１９に示したチャネルキー格納部１１７の当該チャネルＩＤ／チャネル識別子の記録エリアに当該チャネルキーを記録する（ステップＳ５２）。
【０１４０】
また、受信契約情報内の受信装置ＩＤの並びの中に、受信装置ＩＤ格納部１１３に格納されている自身の受信装置ＩＤと同じものがあるかどうかをチェックする（ステップＳ５３）。もし、有ればデジタル署名を検証する（ステップＳ５４）。検証の結果デジタル署名の正当性が明らかになった場合（ステップＳ５５）、当該受信契約情報の中のチャネル契約情報を契約情報格納部１１６へ送信する。
【０１４１】
検証の結果デジタル署名が誤りであった場合には偽造の可能性があるので当該契約情報は棄却して処理を終了する。また、当該契約情報に受信装置ＩＤがない場合には当該チャネル契約情報を反映する必要はないので処理を終了する。
【０１４２】
ここで、契約情報格納部１１６では、チャネル契約情報を取得して、図２０〜図２３に例示する手順に従って、当該チャネル契約情報を、チャネル契約格納部１１６に格納すると同時に、総合チャネル展開情報に反映させる。
【０１４３】
まず、ｆｌａｇ＝０と変数の初期化を行う（図２０のステップＳ７１）。このｆｌａｇ変数は、入力されたチャネル契約情報が既に反映されているか否かを示すもので、メモリを書き換える操作を伴う契約情報の反映処理を最小にすることを目的としている。
【０１４４】
次に、入力されたチャネル契約情報がチャネル指定型か否かをチェックする（ステップＳ７２）。
【０１４５】
チャネル指定型であった場合は、ＯＮ／ＯＦＦ情報を参照して、ＯＮ情報か否かをチェックする（ステップＳ７３）。
【０１４６】
ＯＮ情報である場合は、チャネル契約情報に追加する情報であるので、チャネルＩＤ１から順番に当該チャネルＩＤが有効であるか（例えばＮＵＬＬでないか）をチェックし、有効でなかった場合には次のチャネルＩＤを検索してチャネルＩＤの有効性をチェックする（ステップＳ７４〜Ｓ７６，Ｓ８０）。
【０１４７】
有効であった場合には、当該チャネルＩＤが契約情報格納部１１６にある図２４に示すようなチャネルＩＤ指定契約情報格納エリアを検索し、当該チャネルＩＤが存在するかをチェックする（ステップＳ７７）。
【０１４８】
もし、存在する場合は、チャネル契約情報に含まれる次のチャネルＩＤを検索し、有効性チェックからやり直す（ステップＳ７５〜Ｓ７７，Ｓ８０）。
【０１４９】
存在しない場合は、当該チャネルＩＤを契約情報格納部１１６のチャネルＩＤ指定契約情報格納エリアに書き込んで（ステップＳ７８）、ｆｌａｇ＝１として（ステップＳ７９）、契約情報の変更があったことを示す。
【０１５０】
この処理は、チャネル契約情報に書かれるチャネルＩＤの数ｎ回繰り返される（ステップＳ７５〜Ｓ８０）。図９の例では、４回繰り返される。
【０１５１】
ステップＳ７３のＯＮ情報チェックにおいてＯＮ情報でなかった場合（すなわち、ＯＦＦ情報であった場合）、当該チャネルＩＤが有効である場合の取扱い（削除処理；ステップＳ８１〜Ｓ８７）が上記追加処理と逆になる他は上記と同様である。すなわち、この場合、チャネルＩＤ指定契約情報格納エリアに当該有効なチャネルＩＤが存在するとき、当該チャネルＩＤをチャネルＩＤ指定契約情報格納エリアから削除し、ｆｌａｇ＝１とするが、チャネルＩＤ指定契約情報格納エリアに当該有効チャネルＩＤが存在しない場合は、チャネル契約情報に含まれる次のチャネルＩＤを検索し、有効性のチェックからやり直す。
【０１５２】
また、チャネル契約情報がパッケージ指定型のものである場合は図２１に例示する手順に従って処理（ステップＳ９１〜Ｓ１０５）を行う。ここでの処理はチャネル指定型の場合における処理（ステップＳ７２〜Ｓ８６）と基本的には同様であるので、ここでの詳細な説明は省略する。なお、この場合に、図２４に示すようなチャネルＩＤ指定契約情報格納エリアに対応するものは、図２５に示すようなパッケージＩＤ指定契約情報格納エリアである。
【０１５３】
さて、チャネル指定型のチャネル契約情報に対する追加処理、削除処理、パッケージ指定型のチャネル契約情報に対する追加処理、削除処理の４種類の処理のいずれの場合も、チャネル契約情報に含まれる全てのチャネルＩＤ（チャネル指定型の場合）またはパッケージＩＤ（パッケージ指定型の場合）の検索が終了した段階で、図２２および図２３に例示したような手順で、契約情報格納部１１６のパッケージＩＤ指定契約情報格納エリアとチャネルＩＤ指定契約情報格納エリアに存在する情報を、総合チャネル展開情報格納エリアにある総合チャネル展開情報に反映する。
【０１５４】
ｆｌａｇ＝１であるか否かをチェックし（図２２のステップＳ１１１）、ｆｌａｇ＝１でない場合は、契約情報に変更はないので、処理を終了する。
【０１５５】
ｆｌａｇ＝１である場合は、まずパッケージＩＤ指定契約情報格納エリア（図２５参照）にあるＮＵＬＬでないパッケージＩＤに関して、パッケージ展開情報を順次、契約情報格納部１１６内の総合チャネル展開情報に反映する（ステップＳ１１２，Ｓ１１３，Ｓ１１４，Ｓ１１５，Ｓ１１８，Ｓ１１９）。
【０１５６】
ここで、パッケージ展開情報とは、チャネル展開情報と同様にパッケージに含まれるチャネルに対応するビットが過不足なく立っているビット列である。従って、当該パッケージ展開情報の総合チャネル展開情報への反映はそれぞれのビットの論理和（ＯＲ）を取ったものを新たな総合チャネル展開情報にすることによって行われる。
【０１５７】
なお、パッケージ展開情報は、パッケージＩＤがパッケージＩＤ指定契約情報格納エリアに記録されるまでは存在しない。パッケージ展開情報は別途放送波によってパッケージ定義情報という形で与えられるものであるため、上記反映処理は、パッケージ定義情報を受信するまで待機するか、処理を終了し、当該パッケージ定義情報を受信したときに再開する。いずれの場合も、当該パッケージＩＤのパッケージ定義情報が受信され、それがパッケージＩＤ指定契約情報格納エリアに記録された後、上記反映処理を、継続（待機の場合）または再起動（終了の場合）する（ステップＳ１１６，Ｓ１１７）。待機状態を実現する場合は定期的に上記反映プロセスを繰り返すようにすれば良い。なお、パッケージ定義情報の送信に関しては後述する。
【０１５８】
パッケージＩＤ指定契約情報エリアにあるＮＵＬＬでないパッケージＩＤに関して前記処理が終了したら、次にチャネルＩＤ指定契約情報格納エリア（図２４参照）にあるＮＵＬＬでないチャネルＩＤに関して、以下の総合チャネル展開情報への反映処理を行う。本実施形態の場合、チャネルＩＤはチャネル展開情報でのビット位置を表しているので、総合チャネル展開情報のビット列のチャネルＩＤに示されているビットを立てる（１にする）。上記の処理をチャネルＩＤ指定契約情報格納エリアにあるＮＵＬＬでない全てのチャネルＩＤに関して繰り返して、最新の契約内容が反映された総合チャネル展開情報を得る（図２３のステップＳ１２１〜Ｓ１２４）。
【０１５９】
以上で、受信契約関連情報のうち契約情報の処理の説明を終了する。
【０１６０】
次に、契約関連情報復号部１１０で復号された情報がパッケージ定義情報である場合は（図１６のステップＳ４５）、パッケージ定義情報認証部１１５へ送られ、ＭＡＣがチェックされる（図１８のステップＳ６１）。ＭＡＣが認証されない場合は、何らかの改ざんか送信エラーが生じていると考えられるので当該パッケージ定義情報に関する処理を終了する。
【０１６１】
ＭＡＣが認証された場合は、受信契約情報からチャネルキーとチャネル識別子とチャネルキー識別子を抽出し、図１９に示したチャネルキー格納部１１７の当該チャネルＩＤ／チャネル識別子の記録エリアに当該チャネルキーを記録する（ステップＳ６２）。
【０１６２】
また、パッケージ定義情報のパッケージＩＤを抽出し、契約情報格納部１１６のパッケージＩＤ指定契約情報格納エリアを参照し、当該パッケージＩＤの契約が存在するか否かをチェックする（ステップＳ６３）。
【０１６３】
存在しない場合は、パッケージ定義情報の反映処理を終了する。
【０１６４】
存在する場合は、当該パッケージ定義情報のパッケージ展開情報とパッケージＩＤ指定契約情報格納エリアに存在する当該パッケージＩＤのパッケージ展開情報とを比較する（ステップＳ６４）。
【０１６５】
一致する場合には、処理を終了する。
【０１６６】
一致しない場合には、パッケージＩＤ指定契約情報格納エリアの当該パッケージＩＤのパッケージ展開情報に（図２５参照）、当該パッケージＩＤのパッケージ展開情報を反映し（ステップＳ６５）、契約情報格納部１１６に存在する総合チャネル展開情報を更新する（ステップＳ６６）。
【０１６７】
ここで、具体例を用いて簡単に説明すると、ある放送受信装置（受信装置ＩＤを１とする）において、全８チャンネルのうち、第２チャネル、第５チャネル、第７チャネル（チャネルＩＤをそれぞれ２、５、７とする）の３つのチャネルからなるパッケージ（パッケージＩＤを１とする）の受信契約と、第８チャネル（チャネルＩＤを８とする）の個別の受信契約とを行った場合、チャネルＩＤ“８”と受信装置ＩＤ“１”とＯＮ情報を含むチャネル指定型の契約情報（図９、図５、図６参照）と、パッケージＩＤ“１”と受信装置ＩＤ“１”とＯＮ情報を含むチャネル指定型の契約情報（図１０、図５、図６参照）を受信することになり、チャネルＩＤ“８”とパッケージＩＤ“１”がそれぞれ契約情報格納部１１６のチャネルＩＤ指定契約情報格納エリアとパッケージＩＤ指定契約情報格納エリアに格納される（図２４、図２５参照）。また、パッケージＩＤ“１”とそのパッケージ展開情報“０，１，０，０，１，０，１，０”を含むパッケージ定義情報（図１１、図７、図６参照）を受信し、パッケージ展開情報が契約情報格納部１１６のパッケージＩＤ指定契約情報格納エリアにチャネルＩＤ“８”に対応して格納される（図２５参照）。
【０１６８】
そして、上記のチャネルＩＤ指定契約情報格納エリアのチャネルＩＤと、パッケージＩＤ指定契約情報格納エリアのパッケージ展開情報から、当該受信装置における総合チャネル展開情報“０，１，０，０，１，０，１，１”が定まる。この総合チャネル展開情報は、契約情報格納部１１６の総合チャネル展開情報格納エリアに格納される。
【０１６９】
ここで、当該放送受信装置において、さらに第３チャネル（チャネルＩＤを３とする）の個別の受信契約を追加した場合、チャネルＩＤ“３”と受信装置ＩＤ“１”とＯＮ情報を含むチャネル指定型の契約情報を受信することになり、チャネルＩＤ“３”がチャネルＩＤ指定契約情報格納エリアに追加される。そして、このチャネルＩＤ“３”がチャネル契約情報格納エリアの総合チャネル展開情報に追加され、更新後の総合チャネル展開情報は“０，１，１，０，１，０，１，１”となる。
【０１７０】
以上のような処理を行うことにより、多くの場合、契約情報をビット数の少ないパッケージ情報として送付できるので、多チャネル有料放送の限定受信システムにおいても限定受信のための情報を削減することができる。
【０１７１】
ところで、上記では、取得した全てのチャネルキーをチャネル識別子とともにチャネルキー格納部１１７に格納するものとして説明した。しかし、同時に視聴するチャネルは高々１つであるので、視聴しているチャネルのチャネルキーのみ更新するようにしてもよい。この場合には、例えば、チャネル情報入力部１１９を設け、チャネル選択インターフェース１０５で選択されているチャネル番号をチャネル情報入力部１１９から契約情報認証部１１４とパッケージ定義情報認証部１１５に与え、契約情報認証部１１４やパッケージ定義情報認証部１１５で現在視聴しているチャネル番号を参照し、必要なチャネルキーだけをチャネルキー格納部１１７に格納するようにしてもよい。
【０１７２】
なお、この構成を取った場合、チャネル変更時にはチャネルキー格納部１１７の内部をクリアするのが好ましい。何故なら変更後のチャネルのチャネルキーは変更前のチャネルのチャネルキーとは一般的に異なるので、格納部をクリアしないと変更前のチャネルのチャネルキーが有効になってしまい、意味不明の放送コンテンツが出力されることになるからである。このようにすることによって、チャネル変更時には、チャネルキー格納部１１７をクリアしてチャネル契約情報から新たにチャネルキーを取得しなくてはならないため、デスクランブルまでに処理時間がかかるが、チャネルキー格納部１１７のメモリ容量が少なくて済み、また、チャネル数が増えてもメモリ容量を増やすなどの処置をしなくても良い。
【０１７３】
次に、これまで説明した例よりもさらに情報量を削減可能とした情報形態の他の例について説明する。
【０１７４】
ユーザが受信契約をする際に、所望のチャネルを個別に契約するのではなく、パッケージ契約とチャネル契約を数個組み合わせることが一般的である。このような契約者に対して、先の例では２つ異なる形態のチャネル契約情報を送信するようにしたが、ここでは、チャネル契約情報と受信契約情報のデータ構造を修正して、さらに情報量を削減するようにする。
【０１７５】
まず、ここでは、図２６に例示するように、チャネル契約情報を一つ以上のパッケージＩＤと一つ以上のチャネルＩＤを併記できる構造にする。このため、チャネル契約情報に指定するパッケージＩＤの数、チャネルＩＤの数を記述する領域を設け、以下でそれぞれがいくつ続くかを示す。本例においては、パッケージＩＤの方がチャネルＩＤよりも先行して記述されると定めているので、解析は十分に可能となる。むしろここで問題になるのは、チャネル契約情報が可変長になることである。しかしこの点は受信契約情報を図２７に例示するように修正することで解決する。すなわち、チャネル契約情報の次に固定長で受信装置ＩＤの数を記述する。このことにより、パケット内で以下にいくつの受信装置ＩＤが続くか分かるので、解析が可能となる。
【０１７６】
図２８に、このようなチャネル契約情報を反映させるための処理手順の一例を示す（ステップＳ１３１〜Ｓ１６０）。基本的には先の例と同様であるので、ここでは相違する点を中心に説明する。
【０１７７】
先の例では、チャネル契約情報に含まれるものがパッケージＩＤ、チャネルＩＤのどちらか一方であることが種別情報で分かっていたので、どちらか一方の処理をすれば良かったが、本例では、両方混在し得るため、各々の数ｋ，ｌをチャネル契約情報から抽出し、この数分だけそれぞれの反映処理を行う。それぞれの反映処理は、先の例と同じである。処理は、パッケージＩＤ、チャネルＩＤの順番に行い、終了したならば、図２２および図２３に例示したような手順に従って総合チャネル展開情報への展開を行う。
【０１７８】
（第２の実施形態）
第２の実施形態は、契約者（視聴者）やチャネル数が増加しても、限定受信のために放送配信すべき契約情報の増加を抑えることを可能とするために、２段以上の階層構造を持つチャネル契約情報を適宜用いることにより、該情報を削減可能としたものである。
【０１７９】
なお、本実施形態の放送受信装置の構成・動作は、基本的には第１の実施形態と同様であるので、以下では相違する点もしくは追加する点を中心に説明する。
【０１８０】
第１の実施形態では、パッケージ定義情報の中にはパッケージＩＤに対するパッケージ展開情報を記述するものとしたが、本実施形態では、パッケージ定義情報の中に、パッケージＩＤに対して、その定義を、パッケージＩＤ、チャネルＩＤ、チャネル展開情報を併用して記述可能とする。後述する例では、パッケージＩＤとチャネルＩＤの併記、およびパッケージＩＤとチャネル展開情報の併記の２種類を示している。なお、本実施形態において、パッケージをチャネル展開情報のみで定義した場合における当該チャネル展開情報はすなわちパッケージ展開情報である。
【０１８１】
この方式を使えば、一つ以上のパッケージと一つ以上のチャネルＩＤからなる仮想のパッケージを定義することができ、本来の契約でのパッケージとしては定義されていないようなパッケージを放送装置側で仮想的に定義することが可能となる。パッケージ定義情報は、受信パッケージ情報の形で共通に送信することができるので、放送装置側で契約情報の送信量が最小になるように送信パターンを決めることができ、特に契約者の契約パターンが複雑になった場合には有効である。
【０１８２】
図２９に、本実施形態のパッケージ定義情報の一例を示す。
【０１８３】
このパッケージ定義情報は、パッケージＩＤ、種別情報、仮想フラグ、パッケージＩＤの数、チャネルＩＤの数、「パッケージＩＤの数」に応じた数のパッケージＩＤの組み、「チャネルＩＤの数」に応じた数のチャネルＩＤの組み、から構成される。
【０１８４】
図２９のようなパッケージ定義情報を「１モードＩＤ指定型パッケージ定義情報」と呼ぶ。なお、１モード型とは後述する２モード型と対比するための表現である。
【０１８５】
図２９において、「種別情報」は、以下で説明するような他の形態のパッケージ定義情報と区別するための固定長の識別情報である。
【０１８６】
「仮想フラグ」は、当該パッケージ定義情報が、実際に存在するもの（内部にパッケージＩＤを含まないもの）か、情報量削減のために仮想的に設定されたものであるか、を示す固定長の識別情報である。この仮想フラグは、パッケージをチャネル展開情報（パッケージ展開情報）に展開する際に利用する。
【０１８７】
「パッケージＩＤの数」は、本パッケージ定義情報に含まれるパッケージＩＤの数を示す。
【０１８８】
「チャネルＩＤの数」は、本パッケージ定義情報に含まれるチャネルＩＤの数を示している。
【０１８９】
パッケージＩＤの組みは、本パッケージ情報の先頭に記載されているパッケージＩＤで識別されるパッケージに含まれるパッケージＩＤを示している。
【０１９０】
チャネルＩＤの組みは、本パッケージ情報の先頭に記載されているパッケージＩＤで識別されるパッケージに含まれるチャネルＩＤを示している。
【０１９１】
このように１または複数のパッケージＩＤと１または複数のチャネルＩＤからなる契約を１つのパッケージ定義情報で定義可能にすると、これらの情報を受信パッケージ情報に載せて共通に送信することができるので、パッケージＩＤとチャネルＩＤを個々の契約情報に記述する第１の実施形態と比較して、より送信情報量を削減することが期待できる。
【０１９２】
次に、図３０に、本実施形態の１モード型のパッケージ定義情報の他の例を示す。
【０１９３】
このパッケージ定義情報は、図２９のパッケージ定義情報と比較して、個々のチャネルの指定がＩＤによらず、チャネル展開情報によっているところが特徴である。このパッケージ定義情報を、「１モード展開指定型パッケージ定義情報」と呼ぶ。このパッケージ定義情報は、パッケージ以外の（特定パターンの）個別契約チャネル数が多い場合に有効である。すなわち、個別契約チャネルは、図２９の場合にはチャネルＩＤとして個々に記述するが、図３０の場合にはそれらを一つの展開情報として表現できるからである。
【０１９４】
図３０に示されるように、このパッケージ定義情報は、当該パッケージのパッケージＩＤ、種別情報、仮想フラグ、パッケージＩＤの数、「パッケージＩＤの数」に応じた数のパッケージＩＤ、チャネル展開情報からなる。ここで、図２９のパッケージ定義情報に含まれる情報と同じ名称で記述した情報は、図２９で説明したものと同じ意味を持つ。ここで、チャネルＩＤの数が省略されているのは、このパッケージ情報では個別のチャネルはチャネル展開情報によって表現し、チャネルＩＤによっては表現しないからである。
【０１９５】
次に、図３１に、本実施形態の２モード型のパッケージ定義情報の一例を示す。
【０１９６】
このパッケージ情報は、図２９および図３０の２種類のパッケージ定義情報とは異なり、ＯＮ情報である契約済みのパッケージおよびチャネルの情報を記述するパッケージ定義情報と、ＯＦＦ情報である契約を終了するパッケージおよびチャネルを記述するパッケージ定義情報とを併せて記述したものである。
【０１９７】
この形態のパッケージ定義情報を、「２モード型パッケージ定義情報」と呼ぶ。
【０１９８】
先の２種類のパッケージでは、ＯＮ情報もしくはＯＦＦ情報のどちらか一方しか記述できないので、チャネルの入れ替えが生じるような契約変更時には各ユーザにＯＮ情報とＯＦＦ情報の２種類の契約情報を送信することになる。これに対して、このパッケージ定義情報では、ＯＮ情報とＯＦＦ情報を１つの仮想的なパッケージにまとめることができ、非常に有用である。
【０１９９】
以下、本パッケージ定義情報のデータ構造について説明する。
【０２００】
本パッケージ定義情報は、当該パッケージのパッケージＩＤ、種別情報、ＯＮ情報のパッケージ定義、ＯＦＦ情報のパッケージ定義からなる。ここで、パッケージＩＤは、先の２種類のパッケージ定義情報と同じ長さの固定長の情報である。種別情報は、先の２種類のパッケージ定義情報と共通の固定長の長さを持つ情報であり、当該パッケージ定義情報が２モード型パッケージ定義情報であることを示すものである。
【０２０１】
ＯＮ情報パッケージ定義は、図３２に示すように、仮想フラグ、パッケージＩＤの数、チャネルＩＤの数、「パッケージＩＤの数」に応じた数のパッケージＩＤ、「チャネルＩＤの数」に応じた数のチャネルＩＤからなっているか、または、図３３に示すように、仮想フラグ、パッケージＩＤの数、「パッケージＩＤの数」に応じた数のパッケージＩＤ、チャネル展開情報からなっている。図３２と図３３は、それぞれ、図２９に示した１モードＩＤ指定型、図３０に示した１モード展開型のパッケージ定義情報と対応している。すなわち、ＯＮ情報パッケージ定義は、契約を開始する部分の１モードのパッケージ定義と言える。
【０２０２】
ＯＦＦ情報パッケージ定義は、ＯＮ情報パッケージ定義と同様の構造をしており、解約するパッケージや解約するチャネルを示している。
【０２０３】
なお、ＯＮ情報パッケージ定義とＯＦＦ情報パッケージ定義が、それぞれ、１モードＩＤ指定型での定義で記述されているか、１モード展開指定型で記述されているかは、種別情報に盛り込むものとする。この場合、図３１の種別情報には、２モード型パッケージ定義情報を示すものとして、４種類存在することになる。
【０２０４】
次に、このようなパッケージ情報を受信した際の放送受信装置の動作について説明する。
【０２０５】
ここでは、図３４に例示した構造を持つパッケージ定義情報系列を例に取って具体的に説明する。
【０２０６】
図３４に示すパッケージ定義情報系列において、パッケージＩＤ（０）のパッケージは、仮想パッケージであって、パッケージＩＤ１ （１）とパッケージＩＤ２ （１）とチャネル展開情報１から構成されている。
【０２０７】
パッケージＩＤ１ （１）は、仮想パッケージであって、パッケージＩＤ１ （２）とパッケージＩＤ２ （２）からなっている。これら２つのパッケージＩＤ１ （２）とＩＤ２ （２）は、仮想パッケージではなく、それぞれ、チャネル展開情報で定義される。
【０２０８】
パッケージＩＤ２ （１）は、仮想パッケージであって、パッケージＩＤ３ （２）とチャネルＩＤ１ （２）とチャネルＩＤ２ （２）からなっている。パッケージＩＤ３ （２）は、仮想パッケージではなく、チャネル展開情報で定義される。
【０２０９】
さて、パッケージ定義情報を受信した放送受信装置は、パッケージ定義情報認証部１１５で、図３５に例示したような手順で処理を行う。
【０２１０】
まず、パッケージ定義情報から種別情報を抽出し（ステップＳ１７１）、一時メモリに格納する。その種別によって、当該パッケージ定義情報が、１モード型であるか否かをチェックする（ステップＳ１７２）。
【０２１１】
もし、１モード型であれば、ＯＮ情報パッケージ定義の反映処理を行う（ステップＳ１７３）。
【０２１２】
ここで、ＯＮ情報パッケージ定義とは、当該パッケージに含まれるパッケージＩＤ、チャネルＩＤもしくはチャネル展開情報が新たに追加される情報であることを意味する。すなわち、当該パッケージが契約情報で指定されたことによって、当該パッケージに含まれるパッケージＩＤ、チャネルＩＤやチャネル展開情報によって示されているチャネルが、契約チャネルとして追加されることを意味する。また、ＯＦＦ情報パッケージ定義とは、当該パッケージが契約情報で指定されたことによって、当該パッケージに含まれるパッケージＩＤ、チャネルＩＤやチャネル展開情報によって示されているチャネルが、解約チャネルとして削除されることを意味する。
【０２１３】
一方、パッケージ定義情報が１モード型でない場合は、ＯＮ情報パッケージ定義の反映処理（ステップＳ１７４）、ＯＦＦ情報パッケージ定義の反映処理（ステップＳ１７５）の順で処理を行う。
【０２１４】
次に、ＯＮ情報パッケージ定義の反映処理を詳しく説明する。図３６にその処理手順の一例を示す。
【０２１５】
まず、パッケージ定義情報からパッケージＩＤを抽出し（ステップＳ１８１）、当該パッケージＩＤが契約情報格納部１１６のパッケージＩＤ格納エリアに存在するか否かをチェックする（ステップＳ１８２）。存在しなければ、当該受信装置には当該パッケージＩＤのパッケージでの契約は存在しないので、以下の処理は必要がなく、処理を終了する。
【０２１６】
ここで、本実施形態における契約情報格納部１１６の構造について説明する。
【０２１７】
本実施形態の契約情報格納部１１６は、パッケージＩＤ格納エリア、チャネルＩＤ格納エリア、チャネル展開情報格納エリア、総合チャネル展開情報メモリ（総合チャネル展開情報エリア）からなっている。
【０２１８】
パッケージＩＤ格納エリアは、パッケージＩＤの定義を記録するエリアである。
【０２１９】
チャネルＩＤ格納エリアは、指定されたチャネルＩＤを記録するエリアである。
【０２２０】
チャネル展開情報格納エリアは、指定されたチャネル展開情報を格納するエリアである。
【０２２１】
総合チャネル展開情報メモリは、最終的に反映された総合チャネル展開情報を格納するメモリエリアである。総合チャネル展開情報メモリは、契約判定部１１８が参照する。
【０２２２】
さて、ステップＳ１８２でパッケージＩＤが契約情報格納部１１６のパッケージＩＤ格納エリアに存在する場合、ｎ＝ｍ＝０と初期化し（ステップＳ１８３）、種別情報を抽出して（ステップＳ１８４）、一時メモリに格納する。
【０２２３】
次に、この種別情報から当該パッケージ定義情報がＩＤ指定型であるか否かを判断し（ステップＳ１８５）、ＩＤ指定型である場合は、チャネルＩＤ数ｍを抽出し（ステップＳ１８７）、ｎ個のパッケージＩＤとｍ個のチャネルＩＤを順次一時メモリに格納し（ステップＳ１８７，Ｓ１８８）、総合チャネル展開情報メモリへの反映処理を行う（ステップＳ１９１）。
【０２２４】
ステップＳ１８５でＩＤ指定型でない場合は展開指定型であるので、ｎ個のパッケージＩＤとチャネル展開情報を順次一時メモリに格納し（ステップＳ１９０）、総合チャネル展開情報メモリへの反映処理を行う（ステップＳ１９１）。
【０２２５】
次に、図３７に、上記のパッケージＩＤの格納から総合チャネル展開情報への反映処理までの部分の詳しい処理について、その処理手順の一例を示す（ＩＤ指定型と展開指定型の両方を含んでいる）。
【０２２６】
図３７では、ｎ個のパッケージＩＤを抽出し（ステップＳ２０１〜Ｓ２０４）、ＩＤ指定型のパッケージ定義情報ではｍ個のチャネルＩＤを抽出し（ステップＳ２０５〜Ｓ２０８）、展開指定型のパッケージ定義情報ではチャネル展開情報を抽出し（ステップＳ２０９，Ｓ２１０）、それぞれ一時メモリに記録する。
【０２２７】
その後、パッケージＩＤ格納エリアを参照して、パッケージ定義情報で定義されたパッケージＩＤが未定義であるか否かを定義情報の有無情報でチェックし（ステップＳ２１１）、未定義である場合、契約情報更新処理を行う（ステップＳ２１３）。既に定義されていた場合は、既に存在する定義と一時メモリ上の定義が一致するか否かをチェックし（ステップＳ２１２）、一致しない場合は契約情報更新処理を行い（ステップＳ２１３）、一致する場合は契約情報の更新を行う必要はないので終了する。
【０２２８】
次に、契約情報更新処理の詳細を説明する前に、契約情報格納部１１６内のパッケージＩＤ格納エリアの構造について説明する。
【０２２９】
図３８に、パッケージＩＤ格納エリアの構造の具体例を示す。ここで具体的に記載してある情報は、図３４に示したパッケージ定義情報系列の例に対応するものである。
【０２３０】
図３８に表形式で示している情報は、パッケージＩＤ、定義の有無、仮想フラグ、パッケージＩＤの数、チャネルＩＤの数、チャネル展開情報の有無、定義エリアからなる。
【０２３１】
「パッケージＩＤ」は、次項目以下で定義されるパッケージのＩＤを示している。
【０２３２】
「定義の有無」は、定義を既に受信して反映済みか否かを示す情報であり、例えば、反映済みの場合１、そうでない場合は０となる。
【０２３３】
「仮想フラグ」は、パッケージＩＤによって定義されるパッケージが仮想パッケージであるか否かを示す情報であり、例えば、仮想パッケージである場合１、そうでない場合０となる。これはパッケージ定義情報に含まれる仮想フラグによって決まる。
【０２３４】
「パッケージＩＤの数」、「チャネルＩＤの数」、「チャネル展開情報の有無」も、パッケージ定義情報に含まれる情報から反映される。
【０２３５】
「定義エリア」は、パッケージ定義情報に含まれるパッケージＩＤ、チャネルＩＤ、チャネル展開情報からなっている。
【０２３６】
図３９〜図４１に、契約情報更新処理手順の一例を示す。
【０２３７】
まず、当該パッケージ定義情報が仮想パッケージに対する定義情報であるか否かを仮想フラグを参照して判定する（図３９のステップＳ２２１）。
【０２３８】
仮想パッケージであった場合、パッケージＩＤ格納エリアの当該パッケージＩＤのエリア（以下これを該当エリアという）の仮想フラグに１を記録し（ステップＳ２２２）、そうでない場合は０を記録する（ステップＳ２２３）。
【０２３９】
次に、パッケージＩＤの数ｎを該当エリアのパッケージＩＤの数に記録する（ステップＳ２２４）。
【０２４０】
ここで、当該パッケージ定義情報の種別情報を参照して、ＩＤ指定型のパッケージ定義情報であるか否かを判断し（ステップＳ２２５）、ＩＤ指定型であった場合は、該当エリアのチャネルＩＤの数にチャネルＩＤの数ｍを記録し（ステップＳ２２６）、チャネル展開情報の有無には０を記録する（ステップＳ２２７）。ＩＤ指定型でない場合は、該当エリアのチャネルＩＤの数に０を記録し（ステップＳ２２８）、チャネル展開情報の有無に１を記録する（ステップＳ２２９）。
【０２４１】
次に、当該パッケージ定義情報に含まれているパッケージＩＤを順次該当エリアの定義エリアに記録し、パッケージＩＤ格納エリアのパッケージＩＤの欄に当該パッケージＩＤが記載されているかを判断し、記録されていない場合は記録し、定義の有無以下の情報を全て０に初期化する（ステップＳ２３０〜Ｓ２３５）。この処理は、図３８においてパッケージＩＤ（０）の定義に含まれるパッケージＩＤ１ （１）とパッケージＩＤ２ （１）をパッケージＩＤ（０）の定義エリアに記録されていると同時に、パッケージＩＤの欄にも記録されていることからも理解できる。なお、図３８は以下に述べる処理の結果、最終的に到達したパッケージＩＤ状態を記述している。
【０２４２】
パッケージＩＤの展開が終了した後、処理はチャネルＩＤの展開に進む。このアルゴリズムは図４０のフローチャートに詳しく記述されている。
【０２４３】
当該パッケージ定義情報に含まれるチャネルＩＤを順次定義エリアに記録するとともに、契約情報格納部１１６のチャネルＩＤ格納エリアを検索して当該チャネルＩＤが存在しない場合は記録する（ステップＳ２４１〜Ｓ２４５）。以上の処理の流れは図３４におけるパッケージＩＤ２ （１）の展開を例にとると理解しやすい。図３８ではパッケージＩＤ２ （１）はその定義エリアにおいてパッケージＩＤ３ （２）とチャネルＩＤ１ （２）とチャネルＩＤ２ （２）に展開され、そのうちチャネルＩＤ１ （２）とチャネルＩＤ２ （２）は図４２に示すチャネルＩＤ格納エリアにも記録される。
【０２４４】
チャネルＩＤの展開が終了した後、処理はチャネル定義情報の展開に進む。
【０２４５】
まず、当該パッケージ定義情報がＩＤ指定型か否かをチェックし（ステップＳ２４６）、ＩＤ指定型であった場合は、チャネル展開情報は存在しないので、チャネル定義情報の展開処理は終了する。
【０２４６】
ＩＤ指定型でなかった場合は、該当エリアの定義エリアにチャネル展開情報を記録すると同時に契約情報格納部１１６のチャネル展開情報格納エリアにチャネル展開情報を記録する（ステップＳ２４７，S２４８）。以上の処理の流れは図３４におけるパッケージＩＤ（０）の展開を例にとると理解しやすい。図３８ではパッケージＩＤ（０）はその定義エリアにおいてパッケージＩＤ１ （１）とパッケージＩＤ２ （１）とチャネル展開情報１に展開され、そのうちチャネル展開情報１は図４３に示すように契約情報格納部１１６のチャネル展開情報エリアに記録される。
【０２４７】
また、以上の処理により、仮想でないパッケージ定義情報も展開される。仮想でないパッケージ定義情報も同じフォーマットで仮想フラグで仮想でないことを示して送信される。仮想でないので定義は全てチャネル展開情報（パッケージ展開情報）で行われる。すなわち、形式的には展開指定型のパッケージ定義情報であり、０個のパッケージＩＤと０個のチャネルＩＤと１つのチャネル展開情報で構成されていると考えることができる。
【０２４８】
このようなパッケージ定義情報を受け取った際には前述の処理によって、図３８におけるパッケージＩＤ１ （２）、パッケージＩＤ２ （２）、パッケージＩＤ３ （２）のようにそれぞれチャネル展開情報２、チャネル展開情報３、チャネル展開情報４に展開され、該当エリアの定義エリアに記録されると同時にチャネル展開情報格納エリアにも記録される。
【０２４９】
以上の処理により、契約情報格納部１１６のパッケージＩＤ格納エリア、チャネルＩＤ格納エリア、チャネル展開情報格納エリアのテーブルが完成する。完成したか否かは前述の処理が終了した時点でパッケージＩＤ格納エリアの定義の有無が全て１になっていることをもって検出できる。すなわち、図３８の状態がテーブルが完成した状態であり、もはやパッケージＩＤ格納エリアを参照しなくても、チャネルＩＤ格納エリアとチャネル展開情報格納エリアを参照すれば、新しいチャネル展開情報（当該パッケージのパッケージ展開情報）を作成することができる。
【０２５０】
次に、上記情報の総合チャネル展開情報メモリへの反映のための処理について説明する。
【０２５１】
図４１に、そのアルゴリズムを示す。
【０２５２】
まず、契約情報格納部１１６内のパッケージＩＤ格納エリアに未定義のパッケージＩＤがあるか否かをチェックする（ステップＳ２５１）。ここで、未定義のパッケージがあれば、総合チャネル展開情報メモリへの展開は不可能であるので、当該パッケージ定義情報に関する全ての処理を終了する。
【０２５３】
未定義のパッケージが存在しない場合、新しい総合チャネル展開情報を作成するための仮チャネル展開情報のメモリ領域を確保する（ステップＳ２５２）。
【０２５４】
次に、チャネルＩＤ格納エリアにあるチャネルＩＤを順次仮チャネル展開情報に反映する（ステップＳ２５３）。反映の仕方は仮チャネル展開情報上のチャネルＩＤに対応するビットを１にすれば良い。
【０２５５】
次に、チャネル展開情報格納エリアにあるチャネル展開情報を仮チャネル展開情報に反映する（ステップＳ２５４）。これは仮チャネル展開情報とのビット毎の論理和（ＯＲ）を取ったものを新たな仮チャネル展開情報とすれば良い。
【０２５６】
以上の処理が終了した後、仮チャネル展開情報を総合チャネル展開情報メモリに上書きする（ステップＳ２５５）。
【０２５７】
次に、ＯＦＦ情報パッケージ定義の反映処理について詳しく説明する。
【０２５８】
ＯＦＦ情報パッケージ定義情報の処理は図３５に示したアルゴリズムのうち２モード型の場合に行われるが、図３６、図３７に示した情報抽出部分と、図４１に示した総合チャネル展開情報メモリへの反映に関する部分は同じであるので図３９、図４０に相当する情報抽出と内部メモリへの反映の部分を説明する。
【０２５９】
図４４、図４５に、図３９、図４０に相当するアルゴリズムを示す。
【０２６０】
まず、ｆｌａｇ＝０に初期化する（図４４のステップＳ２６１）。ここで、ｆｌａｇは総合チャネル展開情報メモリへの反映処理を行う必要があるか否かの判定フラグである。
【０２６１】
パッケージＩＤの数をｎとし（ステップＳ２６２）、当該パッケージ定義情報がＩＤ指定型である場合には（ステップＳ２６３）、さらに、ｍにチャネルＩＤの数を代入するとともに（ステップＳ２６４）、チャネル展開情報の有無を管理するフラグを０にする（ステップＳ２６５）。一方、展開指定型の場合は、ｍ＝０と初期化し（ステップＳ２６６）、チャネル展開情報の有無フラグを１にする（ステップＳ２６７）。
【０２６２】
次に、定義に含まれるパッケージＩＤを１つずつ抽出し、当該パッケージがパッケージＩＤ格納エリアに存在するか否かをチェックする（ステップＳ２７０）。もし、存在したら当該パッケージを定義している部分を含めて全て消去し（ステップＳ２７１）、ｆｌａｇ＝１とする（ステップＳ２７２）。存在しなかった場合は何も処理しない。この処理を全てのパッケージＩＤについて行った後（ステップＳ２６９，Ｓ２７３）、チャネルＩＤの処理に移る。
【０２６３】
ＯＦＦ情報のパッケージ定義情報にチャネルＩＤの指定があった場合は、チャネルＩＤ格納エリアのチャネルＩＤばかりでなく、パッケージに含まれる当該チャネル部分およびチャネル展開情報格納エリアに含まれる当該チャネル部分の削除をも意味すると考え、順次パッケージＩＤ格納エリアに当該チャネルＩＤのチャネルがあるかどうかをチェックし（図４５のステップＳ２８３）、ある場合には該当部分の削除を行う（ステップＳ２８４）。ここで言う該当部分とは、パッケージＩＤ格納エリアに含まれるチャネルＩＤや、チャネル展開情報の当該チャネルＩＤに対応するビットである。
【０２６４】
さらに、順次チャネルＩＤ格納エリアを検索し、当該チャネルＩＤが存在するか否かを判断し（ステップＳ２８６）、存在した場合には、それを消去する（ステップＳ２８７）。
【０２６５】
最後に、チャネル展開情報格納エリアのチャネル展開情報をチェックして当該チャネルＩＤに対応する部分のビットが１であるかチェックして１である場合には（ステップＳ２８９）、それを０にする（ステップＳ２９０）。
【０２６６】
以上の処理で、削除が起こった時点でｆｌａｇ＝１とする（ステップＳ２８５，Ｓ２８８，Ｓ２９１）。
【０２６７】
この処理を全てのチャネルＩＤについて行う（ステップＳ２８１，Ｓ２８２，Ｓ２９２）。
【０２６８】
また、ＯＦＦ情報のパッケージ定義情報にチャネル展開情報の指定があった場合も（ステップＳ２９３）、同様に処理を行う（ステップＳ２９５〜Ｓ２９９）。すなわち、パッケージに含まれる当該チャネル展開情報に含まれる部分およびチャネル展開情報格納エリアに含まれるチャネル展開情報のうち、当該チャネル展開情報に含まれる部分の削除をも意味すると考え、順次パッケージＩＤ格納エリアに当該チャネル展開情報に含まれるチャネルがあるかどうかをチェックし、ある場合には該当部分の削除を行う。さらに、順次チャネルＩＤ格納エリアを検索し、当該チャネル展開情報に含まれるチャネルが存在するか否かを判断し、存在した場合には、それを消去する。最後に、チャネル展開情報格納エリアのチャネル展開情報をチェックして当該チャネル展開情報に含まれるチャネル部分のビットが１であるかチェックして１である場合にはそれを０にする。以上の処理で、削除が起こった時点でｆｌａｇ＝１とする。
【０２６９】
以上の処理の後、ｆｌａｇをチェックし（ステップＳ２９４，Ｓ３００）、１であれば、図４１に示すような総合チャネル展開メモリへの反映処理を行う。
【０２７０】
また、本実施形態においては、ＯＮ情報の処理がＯＦＦ情報の処理に先だって行われるが、この逆もまた可能であり、同様の処理で実現可能である。
【０２７１】
このように順番を逆にすることにより、例えば、ある時期有利なパッケージができ、多くの契約者がそのパッケージによる契約に変更したような場合、まずＯＦＦ情報のパッケージ定義情報で全てのチャネルを解約してから、ＯＮ情報で当該パッケージのパッケージＩＤを指定するような仮想パッケージを作ることによって、変更前にどのような契約形態を取っていても同じ仮想パッケージで指定することが可能となる。
【０２７２】
なお、本実施形態においては、１モード型パッケージ定義情報は全てＯＮ情報のパッケージ定義情報として扱ったが、１モード型のＯＦＦ情報パッケージ定義情報も有用である。例えば、受信装置の買い替えなどのため全てのチャネルの契約を解除することが考えられる。この際、当該受信装置が行っている契約状態によって異なる解約のため情報を送らなくてはならないが、１モード型のＯＦＦ情報パッケージ定義情報を利用することにより、例えば、１モード型展開指定型パッケージ定義情報を用い、チャネル展開情報の全てのビットに１を立てた仮想パッケージを定義することにより、当該仮想パッケージのパッケージＩＤで指定された受信装置は（たとえどのような契約状態にあっても）全解約ができる。このように一律の解約ができるため、１モード型のＯＦＦ情報パケット定義情報は有用である。また、これの実現は種別情報に１モード型のＯＦＦ情報の指定コードを設け、処理は２モード型のＯＦＦ情報パケット定義情報と同様にすれば可能である。
【０２７３】
以上により本実施形態のパッケージ定義情報のための受信装置の動作の説明を終了する。
【０２７４】
（第３の実施形態）
第３の実施形態では、これまでの各実施形態態の契約関連情報（契約情報、パッケージ定義情報）を送信するための放送送信装置に関して説明する。
【０２７５】
本実施形態では、第２の実施形態のように仮想パッケージを利用可能とする場合を中心に説明するが、第１の実施形態に対応する放送送信装置も基本的には同様である（仮想パッケージを利用可能とする機能は必要ない）。
【０２７６】
本放送送信装置では、仮想的にパッケージを定義することが可能なパッケージ定義情報と、図９／図１０で示したようなチャネル指定型やパッケージ指定型のような自由性の大きいチャネル契約情報とを採用するので、送信量の最適化を図ることができる。本実施形態では、契約情報の送信量が一定以上削減できる場合、仮想パッケージを構成し、当該仮想パッケージと既存のパッケージを用い、パッケージＩＤとチャネルＩＤやチャネル展開情報を効果的に組み合わせることによって、動的に契約情報を作成し、送信するものである。
【０２７７】
なお、第１の実施形態に対応する放送送信装置の場合も、チャネル指定型やパッケージ指定型を効果的に組み合わせることによって、動的に最適な契約情報を作成し、送信することができる。
【０２７８】
さて、図４６に、本実施形態の放送送信装置の構成例を示す。
【０２７９】
図４６に示されるように、本放送受信装置は、契約内容情報入力部２０１、パッケージ内容情報入力部２０２、契約ユーザ・データベース（ＤＢ）２０３、送信契約情報・データベース（ＤＢ）２０４、パッケージ・データベース（ＤＢ）２０５、契約情報最適配置計算部２０６、契約情報生成部２０７、パッケージ定義情報生成部２０８、デジタル署名生成部２０９、デジタル署名用鍵・データベース（ＤＢ）２１０、契約情報・データベース（ＤＢ）２１１、スケジューリング部２１２、契約情報パケット生成部２１３、チャネルキー・データベース（ＤＢ）２１４、マスター鍵・データベース（ＤＢ）２１５、放送契約情報・データベース（ＤＢ）２１６、放送装置２１７を有する。
【０２８０】
契約ユーザＤＢ２０３には、各契約ユーザ（各受信装置ＩＤ）の情報が例えば図４７のデータ構造で格納されている。すなわち、各レコードは、受信装置ＩＤに対して与えられた契約内容をパッケージＩＤとチャネルＩＤで表しており、パッケージＩＤの数、チャネルＩＤの数、「パッケージＩＤの数」に応じた組数の、パッケージＩＤと当該パッケージＩＤでパッケージ契約した日時を表す変更日時とＯＮ／ＯＦＦ情報との組み、「パッケージＩＤの数」に応じた組数の、チャネルＩＤと当該チャネルＩＤでチャネル契約した日時を表す変更日時とＯＮ／ＯＦＦ情報との組み、からなっている。
【０２８１】
契約ユーザＤＢ２０３には契約内容情報入力部２０１からデータが入力される。
【０２８２】
送信契約情報ＤＢ２０４は、例えば図４８のようなデータ構造をしている。すなわち、参照フラグと受信装置ＩＤの組み、パッケージＩＤの数、チャネルＩＤの数、「パッケージＩＤの数」に応じた組数の、パッケージＩＤと参照フラグとＯＮ／ＯＦＦ情報との組み、「チャネルＩＤの数」に応じた組数の、チャネルＩＤと参照フラグとＯＮ／ＯＦＦ情報との組み、からなっており、契約ユーザＤＢ２０３のデータから一定期間に送信するべき契約情報として抽出される。
【０２８３】
パッケージＤＢ２０５は、例えば図４９のようなデータ構造をしている。すなわち、パッケージＤＢ２０５の各レコードが、パッケージＩＤと参照フラグの組、当該パッケージが仮想パッケージであるかを示す仮想フラグ、パッケージＩＤの数、チャネルＩＤの数、チャネル展開情報の有無、「パッケージＩＤの数」に応じた組数の、パッケージＩＤと参照フラグの組み、「チャネルＩＤの数」に応じた組数の、チャネルＩＤと参照フラグの組み、チャネル展開情報、からなっている。
【０２８４】
ここで、参照フラグとは、当該情報が送信契約情報として作成されたか否かを示すフラグであり、１のときは既に作成済みのことを、０のときはまだ作成されていないことを示している。
【０２８５】
送信契約情報ＤＢ２０４にはパッケージ内容情報入力部２０２からデータが入力される。
【０２８６】
チャネルキーＤＢ２１４の各レコードは、例えば図５０に示すように、当該チャネルキーが適用されるチャネルＩＤ、適用期間、当該チャネルキーの識別子であるチャネルキーＩＤ、チャネルキーからなる。
【０２８７】
マスター鍵ＤＢ２１５の各レコードは、例えば図５１に示すように、当該マスター鍵のＩＤ、当該マスター鍵が適用される適用期間、マスター鍵からなっている。
【０２８８】
デジタル署名用鍵ＤＢ２１０は、例えば図５２に示すような一組の秘密鍵と公開鍵とのペアからなっている。
【０２８９】
次に、本実施形態の放送送信装置における契約情報の作成・送信手順について説明する。
【０２９０】
図５３に、その処理手順の一例を示す。
【０２９１】
本放送送信装置内の契約情報生成部２０７は、内部の時計（またはカウンタ）によって計時することにより、一定の時刻になった時点で、一定期間の契約情報を作成する。
【０２９２】
ここでは簡単のため、毎日午後３時にその翌日放送分の契約情報を作成するものとし、翌日の放送に対応する契約情報は最近２ヶ月間に契約変更があった契約情報であるとした場合を具体例として説明する。
【０２９３】
上記のように例えば午後３時になると、契約情報生成部２０７は、契約情報最適配置計算部２０６に、契約情報の最適配置を行う旨の信号を出す。すると、契約情報最適配置計算部２０６は、契約ユーザＤＢ２０３から最近２ヶ月間に変更のあった情報を抽出し、図４８に示す送信契約情報ＤＢ２０４に登録する（ステップＳ３１１）。ここで、情報の抽出にあたっては、契約ユーザＤＢ２０３の変更日時を参照して、例えば最近２ヶ月間の日付が付いている情報だけを抽出する。すなわち、例えば１ヶ月前に解約したチャネルのチャネルＩＤは出力されても、同じ受信装置ＩＤに対応する３ヶ月前に契約したパッケージＩＤの情報は出力されない。
【０２９４】
上記のような基準で作成された送信契約情報ＤＢ２０４に対して、契約情報送信最適化のための仮想パッケージの定義を行ない（ステップＳ３１２）、パッケージＤＢ２０５へそれを登録する（ステップＳ３１３）。パッケージ定義情報は、パッケージ定義情報生成部２０８によって作成される。
【０２９５】
図５４に、仮想パッケージを定義するための処理手順の一例を示す。
【０２９６】
なおここでは、簡単のため１モード型のチャネル契約情報のみを考えることにし、２モード型のチャネル契約情報による契約情報は作成しないものとする。
【０２９７】
まず、送信契約情報ＤＢ２０４を検索し、仮想パッケージを一切用いない場合の総契約情報送信量を算出する（ステップＳ３２１）。次に、送信契約情報ＤＢ２０４にある全てのレコードを参照して、送信契約情報ＤＢ２０４にある全てのパッケージＩＤとチャネルＩＤの組合せを求め、それぞれに該当する受信装置ＩＤの数を計数する（ステップＳ３２２）。当該計数値の多いものから仮想パッケージにした際の契約情報送信量の削減率を求め削減率が１％以上である組合せを仮想パッケージとして定義し、これをパッケージＤＢ２０５に登録する（ステップＳ３２３）。このようにすることによってむやみに仮想パッケージを定義することによる混乱を避けることができる。
【０２９８】
仮想パッケージの定義をパッケージＤＢ２０５に登録した後、最適なチャネル契約情報に基づいた契約情報を作成する（図５３のステップＳ３１４）。
【０２９９】
図５５に、最適なチャネル契約情報の決定と当該チャネル契約情報に基づいた契約情報の作成手順の一例を示す。
【０３００】
まず、契約情報生成部２０７は、パッケージＤＢ２０５から仮想パッケージに対応したパッケージＩＤの数を算出し、それら仮想パッケージＩＤとその定義を順次抽出し、以下の処理を行う。
【０３０１】
まず、当該仮想パッケージＩＤｉに含まれる契約内容を含む送信契約情報をＯＮ情報／ＯＦＦ情報の別に送信契約情報Ｄ２０４Ｂより抽出する（ステップＳ３３４）。そして、当該パッケージＩＤを指定したチャネル契約情報を含む契約情報をＯＮ情報／ＯＦＦ情報の別に作成し、作成が終了した送信契約情報の項目ｉの参照フラグを１にする（ステップＳ３３５）。これとともに、送信契約情報ＤＢ２０４に含まれる当該レコードの情報の中で当該仮想パッケージの定義に含まれる情報の参照フラグを１にして、当該情報が契約情報として反映されたことを示す（ステップＳ３３６）。
【０３０２】
上記の処理を全ての仮想パッケージＩＤについて行う（ステップＳ３３２，Ｓ３３３，Ｓ３３７）。
【０３０３】
次に、通常のパッケージＩＤの最適な組合せ方の検索に移る（ステップＳ３３８〜Ｓ３４０）。ここで、パッケージ指定型のチャネル情報は２以下のパッケージＩＤからなることを仮定しているので、ＯＮ情報／ＯＦＦ情報の別に送信契約情報ＤＢを検索して、２つ以下のパッケージＩＤの組合せのうちで最も数の多いものから順番に当該パッケージＩＤの組をチャネル契約情報とする契約情報を作成する。ここで、作成が終了した送信契約情報ＤＢレコードの該当部分の参照フラグを１にして、次回以降の契約情報作成の際に参照しないようにする。
【０３０４】
通常のチャネルＩＤの最適な組合せも前記パッケージＩＤの組合せの場合と同様に行う。
【０３０５】
次に、上記の処理で契約情報生成部２０７から契約情報パケット生成部２１３に出力された契約情報を基に契約情報パケットを作成する処理（図５３のステップＳ３１５）について説明する。
【０３０６】
図５６に、その処理手順の一例を示す。
【０３０７】
上記の契約情報が入力されると（ステップＳ３５１）、まず、デジタル署名生成部２０９により、デジタル署名用鍵ＤＢ２１０から秘密鍵を抽出し（ステップＳ３５２）、契約情報にデジタル署名を付ける（ステップＳ３５３）。デジタル署名の作成は、当該契約情報のハッシュを取り、そのハッシュ値を秘密鍵で暗号化するという通常のデジタル署名の作成形態を取る。デジタル署名が付加された契約情報ＤＢ２１１に格納される。今回作成される全ての契約情報は一旦契約情報ＤＢ２１１に格納されるので、契約情報ＤＢ２１１は一定期間（ここでは１日）に繰り返し放送される契約情報を格納しておくデータベースであるといえる。
【０３０８】
上記の契約情報ＤＢ２１１にある契約情報は、放送スケジュールを管理するスケジューリング部２１２の命令で抽出され、契約情報パケット生成部２１３へ送られる。契約情報パケット生成部２１３では、チャネルキーＤＢ２１４からスケジューリング部２１２の定める放送時間に該当するチャネルキーをチャネルＩＤとともに順次抽出し（ステップＳ３５４）、契約情報にデジタル署名を付加した契約情報ＤＢ２１１から抽出したデータに付加し、全体に付加したチャネルキーを用いてＭＡＣを作成し（ステップＳ３５５）、付加して受信契約情報が完成する。さらに、マスター鍵ＤＢ２１５から放送スケジューリング部２１２が定める放送時間に適用するマスター鍵を検索し、検索されたマスター鍵で受信契約情報を暗号化する（ステップＳ３５６）。暗号化された受信契約情報に情報識別子を付加し（ステップＳ３５７）、契約情報パケットが完成し、これを放送契約情報ＤＢ２１６に出力する（ステップＳ３５８）。このようにして、契約情報パケットは、放送契約情報ＤＢ２１６に格納される（図５３のステップＳ３１７）。
【０３０９】
放送装置２１７は、上記の放送契約情報ＤＢ２１６から順次パケットを読み出して放送する（図５３のステップＳ３１８）。
【０３１０】
以上で本実施形態の放送送信装置の契約情報の作成に関する説明を終わる。
【０３１１】
最後に、本実施形態の放送送信装置のバリエーションに関して述べる。
【０３１２】
本放送送信装置は、仮想パッケージを自動的に定義することができる。しかし、最適化アルゴリズムは必ずしも完全なものではなく、場合によっては特異なデータ群によって偏ったパッケージがいくつもできる可能性がある。この意味でもパッケージの定義は自動的でなく、人手によって行うというのも一つの考え方である。このためには、図４６に示した放送送信装置においてパッケージ内容情報入力部２０２から仮想パッケージの入力もできるようにすると良い。これには入力のインターフェースを変更すれば良く、仮想パッケージの定義を自動で行わないためには契約情報最適配置計算部２０６において仮想パッケージの定義を行なう処理を省略すれば良い。
【０３１３】
（第４の実施形態）
第４の実施形態は、同じチャネル契約情報を持つ（もしくは同じチャネル契約情報を送信すべき）複数の契約者の受信装置ＩＤを受信装置ＩＤの特徴によって類別し、圧縮した形で受信契約情報に含めることによって契約者の増加に伴う契約情報の削減を実現するものである。
【０３１４】
本実施形態では、契約者の増加に備えて、契約情報のうち受信装置ＩＤの記述部分に着目し、圧縮する方法を示す。本実施形態においても受信契約情報は、一般に図５のように構成する。ただし、本実施形態において着目すべきところは、受信装置ＩＤの記述部分であるので、簡単のため受信契約情報を図５７のように考える。すなわち、受信装置ＩＤの記述部分を受信装置ＩＤ情報と呼び、受信装置ＩＤ情報の圧縮記述を中心に考える。
【０３１５】
さて、契約者が多くなってきた場合、受信装置ＩＤも多くなる反面、特徴の似ている受信装置ＩＤも増える。このことを携帯電話の電話番号を例にとって説明する。携帯電話の電話番号は、契約者が少ないときには番号同士の間はかなり開いていて類似ＩＤを見つけにくいが契約者が多くなると次第に間が詰まって、最終的には欠番のない状態にまでなるので、類似ＩＤが頻繁に発生する。本実施形態では、このような点に着目し、受信契約者が多くなってきた場合に、同じチャネル契約情報を持つ契約者の受信装置ＩＤを類似したものを組にして圧縮することにより、契約情報を削減しようとするものである。
【０３１６】
（ｉ）まず、受信装置ＩＤの上位ビットが同じものを類似ＩＤとして捉えた例を示す。この場合の受信装置ＩＤ情報は、図５８のように構成することができ、このような受信装置ＩＤを、「上位ＩＤ分離型受信装置ＩＤ情報」と呼ぶ。
【０３１７】
図５８において、「種別情報」は、本受信装置ＩＤ情報が上位ＩＤ分離型であることを示す固定長のデータである。
【０３１８】
「受信装置ＩＤの数（ｎとする）」は、一括して記述する上位ＩＤのビット長を示す固定長のデータである。
【０３１９】
また、以下では、ここで指定されたビット数分の上位ビットのＩＤを「上位ＩＤ」と呼び、ＩＤ＋と記述することにする。また、ＩＤから上位ＩＤを取り除いたものを「下位ＩＤ」と呼び、ＩＤ−と記述することにする。
【０３２０】
「上位ビット長（ｍとする）」の次に上位ビット長だけの上位ＩＤが記述される。そして、先に指定されている受信装置ＩＤの数の分だけ下位ＩＤの列が続く。このようにすることによって、共通の上位ＩＤを省略できるので、契約情報を削減することができる。
【０３２１】
（ii）次に、受信装置ＩＤが連続しているものを類似ＩＤと捉えた例を示す。図５９が連続した受信装置ＩＤを指定する際に有効な受信装置ＩＤ情報の例である。このような受信装置ＩＤ情報を「系列指定型受信装置ＩＤ情報」と呼ぶ。
【０３２２】
図５９において、「種別情報」は、本受信装置ＩＤ情報が系列指定型であることを示す固定長のデータである。
【０３２３】
「受信装置ＩＤの数」は、本受信装置ＩＤ情報に含まれる受信装置ＩＤの数である。
【０３２４】
「形式情報」は、続く受信装置ＩＤの情報が、連続したＩＤを開始ＩＤと終了ＩＤによって指定したものか、単独で指定したものかを示している。ここで、連続したＩＤを開始ＩＤと終了ＩＤで記述するものであったときは、続く２つのＩＤがそれぞれ開始ＩＤ、終了ＩＤにあたる。単独で指定されたものであるときは、１つのＩＤが続き、当該ＩＤが単独で指定されている。
【０３２５】
また、受信装置ＩＤが連続しているものを類似ＩＤと捉えた場合、図６０のように構成する方法もある。これは連続したＩＤを指定するとき、開始ＩＤと終了ＩＤではなく、開始ＩＤと継続数により表現する方式である。継続数に必要なデータ長は、一般に終了ＩＤよりも短いため、さらに情報量を圧縮することができる。
【０３２６】
（iii ）次に、受信装置ＩＤを羅列して指定する型の受信装置ＩＤ情報を示す。これは、図５に例示した受信契約情報における受信装置ＩＤ情報に近いものであり、図６１に示すように羅列指定型であることを示す種別情報と、受信装置ＩＤの数と、受信装置ＩＤ情報の数の分だけの受信装置ＩＤが続く。このような受信装置ＩＤ情報を「羅列指定型受信装置ＩＤ情報」と呼ぶ。
【０３２７】
次に、このような受信装置ＩＤ情報を含む受信契約情報を受信した際の放送受信装置の動作について説明する。
【０３２８】
これらの動作は、図１の契約情報認証部１１４内の動作であり、全体の動作の中では、図１７のフローチャートにおける、受信契約情報は当該受信装置のものか否かを判定する部分（ステップＳ５３）の動作である。従って、本実施形態は、第１、第２、第３の実施形態においても利用できるものであるとともに、本実施形態においても、第１、第２、第３の実施形態と同じ手法が利用でき、各実施形態は互いに独立した発明の関係にある。
【０３２９】
図６２〜図６５に、この場合の処理手順の一例を示す。
【０３３０】
受信装置ＩＤ情報の中から種別情報を抽出し（ステップＳ３６１）、当該受信装置ＩＤ情報が上位ＩＤ分離型か系列指定型か羅列指定型かを判定し（ステップＳ３６２，Ｓ３６３）、それぞれの処理に渡す（ステップＳ３６４〜Ｓ３６６）。
【０３３１】
（ｉ）上位ＩＤ分離型であった場合は、図６３に示すフローチャートにしたがって、受信装置ＩＤの数ｎ、上位ビット数ｍを読み込み（ステップＳ３７１，Ｓ３７２）、続いて、ｍビットの上位ＩＤ（ＩＤ＋）を読み込む（ステップＳ３７３）。
【０３３２】
続いて、ｎ個の下位ＩＤ（ＩＤ−）を順次読み込み、ＩＤ＝ＩＤ＋＋ＩＤ−によって受信ＩＤを復元する（ステップＳ３７５〜Ｓ３７９）。ここでは、演算子＋は結合を意味する。
【０３３３】
復元されて受信装置ＩＤを自装置のＩＤと比較することによって、当該受信装置ＩＤが自装置のものがどうかをチェックする（ステップＳ３７８）。
【０３３４】
ここで、自装置のものであった場合は、照合した旨の出力を行い（ステップＳ３８１）、終了する。
【０３３５】
自装置のものでなかった場合は、次の下位ＩＤを読み込み、同様の操作でチェックする（ステップＳ３７５〜Ｓ３７９）。
【０３３６】
ｎ個の下位ＩＤ全てについてチェックが終了したら（自装置のものがなかったならば）、照合しない旨の出力を行い（ステップＳ３８０）、終了する。
【０３３７】
（ii）系列指定型であった場合は、図６４に示すフローチャートに従って、受信装置ＩＤの数ｎを読み込み（ステップＳ３９１）、全体で受信装置ＩＤの数になるまで続く受信装置ＩＤを読み込む。
【０３３８】
受信装置ＩＤ情報の読み込みについて詳しく説明する。
【０３３９】
最初にｉ＝０とする（ステップＳ３９２）。次に、形式情報を読み込み（ステップＳ３９５）、続く受信装置ＩＤ情報が開始ＩＤと終了ＩＤが指定された系列情報であるか否かを判断する（ステップＳ３９６）。
【０３４０】
系列情報であった場合は、順次開始ＩＤと終了ＩＤを取得して（ステップＳ４０１，Ｓ４０２）、開始ＩＤから終了ＩＤまでの間に自装置ＩＤがあるか否かをチェックする（ステップＳ４０３）。あった場合は、照合した旨の出力をして終了し（ステップＳ４０４）、なかった場合は、開始ＩＤから終了ＩＤの間にある受信装置ＩＤの数ｍを計算し（ステップＳ４０５）、ｉ＝ｉ＋ｍとして（ステップＳ４０６）、ｉがｎとなるまで、次の形式情報と受信装置ＩＤ情報を読み込み、同様の処理を行う（ステップＳ３９３〜Ｓ３９６，Ｓ４０１〜Ｓ４０６）。
【０３４１】
さらに、形式情報によって続く受信装置ＩＤ情報が系列情報でない場合、続く受信装置ＩＤを取得し（ステップＳ３９７）、自装置のＩＤと比較を行う（ステップＳ３９８）。比較の結果、自装置のＩＤと一致した場合は、照合した旨の出力を行い（ステップＳ３９９）、終了する。一致しない場合は、ｉ＝ｉ＋１として（ステップＳ４００）、ｉがｎとなるまで、次の形式情報と受信装置ＩＤ情報を読み込み、同様の処理を行う（ステップＳ３９３〜Ｓ４００）。む。
【０３４２】
ｉがｎとなったとき（自装置のものがなかったならば）、照合しなかった旨の出力をして（ステップＳ３９４）、処理を終了する。
【０３４３】
（iii ）羅列指定型であった場合は、図６５に示すフローチャートに従って、受信装置ＩＤの数ｎを読み込み（ステップＳ４１１）、続くｎ個受信装置ＩＤを順次読み込んで（ステップＳ４１２〜ステップＳ４１４）、自装置ＩＤと比較し（ステップＳ４１５）、一致した場合は、照合した旨の出力を行い（ステップＳ４１８）、終了する。一致しない場合は、ｎ個の受信装置ＩＤを読み込むまで、同様の処理を繰り返す（ステップＳ４１３〜Ｓ４１８）。
【０３４４】
ｉがｎとなったとき（自装置のものがなかったならば）、照合しなかった旨の出力を行い（ステップＳ４１７）、終了する。
【０３４５】
以上で、本実施形態の放送受信装置の動作の説明を終了する。
【０３４６】
なお、受信装置ＩＤ情報は、上記の他にも種々の形態が考えられる。ここでは、他の例として、上位ＩＤ分離型と系列指定型の両方を含む混合型受信装置ＩＤ情報を示す。この場合のデータ形式は、図６６に示す通りで、図５９に示した系列指定型の受信装置ＩＤ情報の形式情報に新たに系列指定型の識別情報（例えば“１１”）を追加し、続いて上位ＩＤ分離指定型の受信装置ＩＤ情報を記述する。この部分以外は、系列指定型の受信装置ＩＤ情報と同じである。さらに、この場合の放送受信装置の動作は、混合型の受信装置ＩＤ情報の構成から、例えば図６２〜図６５に例示した処理手順における上位ＩＤ分離型に対する照合動作と系列指定型に対する照合動作とを組み合わせれば、混合型の受信装置ＩＤ情報の照合を行うことができる。
【０３４７】
次に、本実施形態の契約情報を作成する放送送信装置の構成および動作について説明する。
【０３４８】
ここでは、本実施形態についての説明を簡単にするために、チャネル契約情報は、チャネル展開情報で記述されているものとする。
【０３４９】
図６７に、本実施形態の放送送信装置の構成例を示す。基本的には、第３の実施形態の放送送信装置（図４６）と同様である。ただし、ここでは、チャネル契約情報にチャネル展開情報のみを用いるものとして説明するため、パッケージ情報の関連部分を省いている。もちろん、本実施形態と第１、第２、第３の実施形態を組み合わせて実施することも可能であり、その場合には、図４６と同様の構成になる。
【０３５０】
図６７の例では、放送受信装置は、契約内容情報入力部１２０１、契約ユーザ・データベース（ＤＢ）１２０３、送信契約情報・データベース（ＤＢ）１２０４、契約情報最適配置計算部１２０６、契約情報生成部１２０７、デジタル署名生成部１２０９、デジタル署名用鍵・データベース（ＤＢ）１２１０、契約情報・データベース（ＤＢ）１２１１、スケジューリング部１２１２、契約情報パケット生成部１２１３、チャネルキー・データベース（ＤＢ）１２１４、マスター鍵・データベース（ＤＢ）１２１５、放送契約情報・データベース（ＤＢ）１２１６、放送装置１２１７を含んで構成される。各部分は、基本的には、図４６の対応する部分と同様である。
【０３５１】
契約ユーザＤＢ１２０３のデータ構造は、図６８に示すようであり、受信装置ＩＤと、当該受信装置のチャネル契約情報（チャネル展開情報）と、当該チャネル契約情報の最新変更日時とからなる。
【０３５２】
送信契約情報ＤＢ１２０４のデータ構造は、図６９に示すようであり、受信装置ＩＤと、当該受信装置のチャネル契約情報（チャネル展開情報）と、当該レコードの情報が契約情報として生成されたか否かを示す参照フラグとからなる。
【０３５３】
デジタル署名用鍵ＤＢ１２１０やチャネルキーＤＢ１２１４やマスター鍵ＤＢ１２１５は、第３の実施形態に示した形と同様である。
【０３５４】
次に、本実施形態の放送送信装置における契約情報の作成手順について説明する。
【０３５５】
図７０および図７１に、その処理手順の一例を示す。
【０３５６】
契約情報生成部１２０７は、内部の時計（またはカウンタ）によって計時することにより、一定の時刻になった時点で、一定期間の契約情報を作成する。
【０３５７】
ここでは簡単のために、第３の実施形態と同様、毎日午後３時にその翌日放送分の契約情報を作成するものとし、翌日の放送に対応する契約情報は、最近２ヶ月間に契約変更があった契約情報であるとした場合を具体例として説明する。
【０３５８】
上記のように例えば午後３時になると、午後３時になると、契約情報生成部１２０７は、契約情報最適配置計算部１２０６に、契約情報の最適配置を行う旨の信号を出す。すると、契約情報最適配置計算部１２０６は、契約ユーザＤＢ１２０３から最近２ヶ月間に変更のあった情報を抽出し、図６７に示す送信契約情報ＤＢ１２０４に登録する（ステップＳ４２１）。ここで、情報の抽出にあたっては、契約ユーザＤＢ１２０３の変更日時を参照して、最近２ヶ月間の日付が付いている情報だけを抽出する。すなわち、例えば１ヶ月前に解約したチャネルのチャネルＩＤは出力されても、同じ受信装置ＩＤに対応する３ヶ月前に契約したパッケージＩＤの情報は出力されない。
【０３５９】
上記のような基準で作成された送信契約情報ＤＢ１２０４に対して、同じチャネル契約情報を持つ受信装置ＩＤを検索し、系列指定型、上位ＩＤ指定型、羅列型のいずれかの形式で当該受信装置ＩＤを含む受信装置ＩＤ情報を作成する。
【０３６０】
まず、送信契約情報ＤＢ１２０４を検索し、契約情報を作成していない（すなわち、参照フラグが０の）レコードが存在するかを確認する（ステップＳ４２２）。
【０３６１】
存在しない場合は、全てのレコードに対する契約情報が作成されたことを意味するので、処理を終了する。
【０３６２】
存在する場合は、そのようなレコードのうちで検索の結果最初に出現したレコードのチャネル契約情報を抽出する（ステップＳ４２３）。再び送信契約情報ＤＢ１２０４を検索し、当該チャネル契約情報を持つレコードから受信装置ＩＤを全て抽出する（ステップＳ４２４）。ここで、抽出された受信装置ＩＤは、同じチャネル契約情報を有するため、同一の契約情報を作成することが可能となる。
【０３６３】
次に、抽出された受信装置ＩＤをＩＤの若い順にソートし（ステップＳ４２５）、まず連番の受信装置ＩＤを抽出する（ステップＳ４２６）。抽出された連番の受信装置ＩＤは、系列指定型受信装置ＩＤ情報で表現できるものなので、これらを系列指定型受信装置ＩＤ情報で表現し、契約情報を作成する（ステップＳ４２７）。また、ここで作成された受信装置ＩＤを検索結果から削除するとともに、これを含む送信契約情報ＤＢ１２０４のレコードの参照フラグを１にする。
【０３６４】
次に、上位ＩＤ分離型の作成に進む。ここでは、上位ＩＤ分離型契約情報の作成は、ＩＤを上位と下位に分離した結果、著しい効率化が認められる場合のみ、行うものとする。例えば、受信装置ＩＤが４０ビットあったとして、上位１０ビットを上位ＩＤとし、２１０通りある上位ＩＤを順次検索し（ステップＳ４２８，Ｓ４２９，Ｓ４３２）、同じ上位ＩＤを持つ受信装置ＩＤが３０個以上あった場合のみ（ステップＳ４３０）、上位ＩＤ分離指定型で表現するようにしている（ステップＳ４３１）。このようにすることによって、明らかに非効率であるような同じ上位ＩＤしか持たない場合でも、上位ＩＤ分離指定型にしてしまうという問題を防ぐ。
【０３６５】
なお、上記の例では、受信契約情報の情報量を僅かでも削減しなければならない程には逼迫していない状況を考えて、敢えて基準値３０以上と指定するようにしたものであるが、実際には２つ以上同じ上位ＩＤを持つ場合は上位ＩＤ分離指定型を取ることにより圧縮の効果があるので、帯域の逼迫状況により上記の基準値を柔軟に変化させることが好ましい。また、上位ＩＤのビット数も（ここでは１０にしているが）、抽出された受信装置ＩＤの数により、柔軟に変化させることが望ましい。例えば、受信装置ＩＤの数が大きい場合は、上位ＩＤのビット数を多くし、少ない場合は、上位ビットのビット数を少なくすることにより、より効率的な契約情報の作成ができる。
【０３６６】
もしくは、受信装置ＩＤを小さい順に検索して行き、（固定長の）上位ＩＤ分離型の契約情報に最大限詰め込めるように上位ビットを決定することもできる。これは、検索される受信装置ＩＤの上位ビットの共通部分を求め、１つの契約情報に最大限詰め込めるＩＤの集合とそのときの上位ＩＤビットのビット数から決定できる。このように送信契約情報ＤＢ１２０４の内容によって動的に契約情報を構成し、最も効率のよい構成を自動的に選べることも本実施形態の放送送信装置の特徴である。
【０３６７】
ここで、抽出された受信装置ＩＤを上位分離型受信装置ＩＤ情報で表現し、契約情報を作成する（ステップＳ４３１）。また、ここで作成された受信装置ＩＤを検索結果から削除するとともに、これを含む送信契約情報ＤＢ１２０４のレコードの参照フラグを１にする。
【０３６８】
最後に、残りの受信装置ＩＤについて羅列指定型で契約情報を作成して、当該チャネル契約情報に対する契約情報を終了する（ステップＳ４２８〜Ｓ４３０，Ｓ４３３，Ｓ４３４）。
【０３６９】
この一連の処理を、送信契約情報ＤＢ１２０４の全てのデータの参照フラグが０になるまで（ステップＳ４２２）、繰り返す。
【０３７０】
次に、上記の処理で契約情報生成部１２０７から契約情報を基に契約情報パケットを作成する処理について説明する。
【０３７１】
この場合の処理手順の一例は、図５６と同様である。
【０３７２】
上記の契約情報が入力されると（ステップＳ３５１）、まず、デジタル署名生成部１２０９により、デジタル署名用鍵ＤＢ１２１０から秘密鍵を抽出し（ステップＳ３５２）、契約情報にデジタル署名を付ける（ステップＳ３５３）。デジタル署名の作成は、当該契約情報のハッシュを取り、そのハッシュ値を秘密鍵で暗号化するという通常のデジタル署名の作成形態を取る。デジタル署名が付加された契約情報ＤＢ１２１１に格納される。今回作成される全ての契約情報は一旦契約情報ＤＢ１２１１に格納されるので、契約情報ＤＢ１２１１は一定期間（ここでは１日）に繰り返し放送される契約情報を格納しておくデータベースであるといえる。
【０３７３】
上記の契約情報ＤＢ１２１１にある契約情報は、放送スケジュールを管理するスケジューリング部１２１２の命令で抽出され、契約情報パケット生成部１２１３へ送られる。契約情報パケット生成部１２１３では、チャネルキーＤＢ１２１４からスケジューリング部１２１２の定める放送時間に該当するチャネルキーをチャネルＩＤとともに順次抽出し（ステップＳ３５４）、契約情報にデジタル署名を付加した契約情報ＤＢ１２１１から抽出したデータに付加し、全体に付加したチャネルキーを用いてＭＡＣを作成し（ステップＳ３５５）、付加して受信契約情報が完成する。さらに、マスター鍵ＤＢ１２１５から放送スケジューリング部１２１２が定める放送時間に適用するマスター鍵を検索し、検索されたマスター鍵で受信契約情報を暗号化する（ステップＳ３５６）。暗号化された受信契約情報に情報識別子を付加し（ステップＳ３５７）、契約情報パケットが完成し、これを放送契約情報ＤＢ１２１６に出力する（ステップＳ３５８）。
【０３７４】
放送装置１２１７は、上記の放送契約情報ＤＢ１２１６から順次パケットを読み出して放送する。
【０３７５】
以上で本実施形態の放送送信装置の契約情報の作成に関する説明を終了。
【０３７６】
最後に、本実施形態では、簡単のために、チャネル契約情報をチャネル展開情報として扱ったが、本実施形態は同じチャネル契約情報を持つ受信装置ＩＤの組み合わせについて成り立つので、チャネル契約情報は、第１、第２、第３の実施形態で説明したようなパッケージ指定型であってもチャネル指定型であっても、またそのパッケージが仮想パッケージを含むような階層構造をしていても同様に構成できる。
【０３７７】
よって、第１〜第４の実施形態は独立の技術であり（各実施形態は独立しても適宜組み合わせても実施可能であり）、適宜実施形態を組み合わせそれら実施形態の各利点を生かしてより強力に契約情報の情報量の削減ができるシステムも各実施形態から容易に構築可能である。
【０３７８】
なお、以上の放送送信装置の各機能は、ソフトウェアとしても実現可能である。
【０３７９】
また、各実施形態に係る放送送信装置は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても実施することもできる。
【０３８０】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０３８１】
【発明の効果】
本発明によれば、有料放送の多チャネル化やその契約者が増大するなどした場合において限定受信の制御のために放送配信すべき情報の量の増大を防ぐことができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係る放送受信装置の構成例を示す図
【図２】チャネル展開情報の一例を示す図
【図３】放送コンテンツの暗号化機構について説明するための図
【図４】放送コンテンツパケットのデータ構造例を示す図
【図５】受信契約情報のデータ構造例を示す図
【図６】契約関連情報パケットのデータ構造例を示す図
【図７】受信パッケージ情報のデータ構造例を示す図
【図８】マスター鍵シードパケットのデータ構造例を示す図
【図９】チャネル指定型のチャネル契約情報のデータ構造例を示す図
【図１０】パッケージ指定型のチャネル契約情報のデータ構造例を示す図
【図１１】パッケージ定義情報の構造例を示す図
【図１２】各種情報とそれらの関連性を説明するための図
【図１３】本発明の実施の形態に係る放送受信装置における放送受信からパケットの内容に応じた処理までの全体的な処理手順の一例を示すフローチャート
【図１４】放送コンテンツパケットに対する処理手順の一例を示すフローチャート
【図１５】マスター鍵シードパケットに対する処理手順の一例を示すフローチャート
【図１６】契約関連情報パケットに対する処理手順の一例を示すフローチャート
【図１７】契約関連情報パケットに対する処理手順の一例を示すフローチャート
【図１８】契約関連情報パケットに対する処理手順の一例を示すフローチャート
【図１９】チャネルキーの記録エリアの一例を示す図
【図２０】チャネル契約情報に対する処理手順の一例を示すフローチャート
【図２１】チャネル契約情報に対する処理手順の一例を示すフローチャート
【図２２】チャネル契約情報に対する処理手順の一例を示すフローチャート
【図２３】チャネル契約情報に対する処理手順の一例を示すフローチャート
【図２４】チャネルＩＤ指定契約情報格納エリアの一例を示す図
【図２５】パッケージＩＤ指定契約情報格納エリアの一例を示す図
【図２６】チャネル契約情報の他のデータ構造例を示す図
【図２７】受信契約情報の他のデータ構造例を示す図
【図２８】チャネル契約情報に対する処理手順の他の例を示すフローチャート
【図２９】１モードＩＤ指定型パッケージ定義情報のデータ構造例を示す図
【図３０】１モード展開指定型パッケージ定義情報のデータ構造例を示す図
【図３１】２モード型のパッケージ定義情報のデータ構造例を示す図
【図３２】ＯＮ情報パッケージ定義とＯＦＦ情報パッケージ定義のデータ構造の第１の例を示す図
【図３３】ＯＮ情報パッケージ定義とＯＦＦ情報パッケージ定義のデータ構造例の第２の例を示す図
【図３４】仮想パッケージについて説明するための図
【図３５】各モードのパッケージ定義情報に対する処理手順の一例を示すフローチャート
【図３６】ＯＮ情報パッケージ定義の反映処理の手順の一例を示すフローチャート
【図３７】ＯＮ情報パッケージ定義の反映処理のうちパッケージＩＤの格納から総合チャネル展開情報への反映処理までの部分のより詳しい処理手順の一例を示すフローチャート
【図３８】パッケージＩＤ格納エリアのデータ構造例を示す図
【図３９】契約情報更新処理手順の一例を示すフローチャート
【図４０】契約情報更新処理手順の一例を示すフローチャート
【図４１】契約情報更新処理手順の一例を示すフローチャート
【図４２】チャネルＩＤ格納エリアの一例を示す図
【図４３】チャネル展開情報エリアの一例を示す図
【図４４】契約情報更新処理手順の他の例を示すフローチャート
【図４５】契約情報更新処理手順の他の例を示すフローチャート
【図４６】本発明の実施の形態に係る放送送信装置の構成例を示す図
【図４７】契約ユーザ・データベースのデータ構造例を示す図
【図４８】送信契約情報・データベースのデータ構造例を示す図
【図４９】パッケージ・データベースのデータ構造例を示す図
【図５０】チャネルキー・データベースのデータ構造例を示す図
【図５１】マスター鍵・データベースのデータ構造例を示す図
【図５２】デジタル署名用鍵・データベースのデータ構造例を示す図
【図５３】契約情報の作成・送信手順の一例を示すフローチャート
【図５４】仮想パッケージを定義するための処理手順の一例を示すフローチャート
【図５５】最適なチャネル契約情報の決定と当該チャネル契約情報に基づいた契約情報の作成手順の一例を示すフローチャート
【図５６】契約情報を基に契約情報パケットを作成する処理手順の一例を示すフローチャート
【図５７】受信契約情報のデータ構造例を示す図
【図５８】上位ＩＤ分離型受信装置ＩＤ情報のデータ構造例を示す図
【図５９】系列指定型受信装置ＩＤ情報のデータ構造例を示す図
【図６０】系列指定型受信装置ＩＤ情報のデータ構造例を示す図
【図６１】羅列指定型受信装置ＩＤ情報のデータ構造例を示す図
【図６２】本発明の実施の形態に係る放送受信装置におけるＩＤ情報の種別判断の処理手順の一例を示すフローチャート
【図６３】上位ＩＤ分離型受信装置ＩＤ情報に対する処理手順の一例を示すフローチャート
【図６４】系列指定型受信装置ＩＤ情報に対する処理手順の一例を示すフローチャート
【図６５】羅列指定型受信装置ＩＤ情報に対する処理手順の一例を示すフローチャート
【図６６】混合型受信契約ＩＤ情報のデータ構造例を示す図
【図６７】本発明の実施の形態に係る放送送信装置の構成例を示す図
【図６８】契約ユーザ・データベースのデータ構造例を示す図
【図６９】送信契約情報・データベースのデータ構造例を示す図
【図７０】契約情報の作成・送信手順の一例を示すフローチャート
【図７１】契約情報の作成・送信手順の一例を示すフローチャート
【符号の説明】
１０１…受信部
１０２…Ａ／Ｄ変換部
１０３…誤り検出／訂正部
１０４…チャネル選択部
１０５…チャネル選択Ｉ／Ｆ
１０６…課金制御部
１０７…フィルター部
１０８…デスクランブル部
１０９…マスター鍵シード認証部
１１０…契約関連情報復号部
１１１…マスター鍵生成部
１１２…マスター鍵格納部
１１３…受信装置ＩＤ格納部
１１４…契約情報認証部
１１５…パッケージ定義情報認証部
１１６…契約情報格納部
１１７…チャネルキー格納部
１１８…契約判定部
１１９…チャネル情報入力部
１２０…チャネルキー出力部
２０１，１２０１…契約内容情報入力部
２０２…パッケージ内容情報入力部
２０３，１２０３…契約ユーザ・データベース
２０４，１２０４…送信契約情報・データベース
２０５…パッケージ・データベース
２０６，１２０６…契約情報最適配置計算部
２０７，１２０７…契約情報生成部
２０８…パッケージ定義情報生成部
２０９，１２０９…デジタル署名生成部
２１０，１２１０…デジタル署名用鍵・データベース
２１１，１２１１…契約情報・データベース
２１２，１２１２…スケジューリング部
２１３，１２１３…契約情報パケット生成部
２１４，１２１４…チャネルキー・データベース
２１５，１２１５…マスター鍵・データベース
２１６，１２１６…放送契約情報・データベース
２１７，１２１７…放送装置
【発明の属する技術分野】
本発明は、暗号化（スクランブル）されて放送配信される放送コンテンツを契約内容（期間、視聴チャネル）に応じて復号（デスクランブル）する有料放送サービスのための放送受信装置に関する。
【０００２】
【従来の技術】
ディジタル放送は、通信衛星（ＣＳ）に始まって、ケーブルＴＶ、地上放送へとディジタル化が進むにつれ、一層のサービスの充実が期待されており、これからの放送サービスの主役を務めていくものと思われる。
【０００３】
ディジタル放送の最大の特徴は、情報圧縮技術の導入により、番組の送信に要する周波数の使用効率の向上が図れ、アナログ放送に比較して放送チャネル数の大幅な増加が可能となったことである。さらに、高度な誤り訂正技術が適用できるため、高品質で均質なサービスの提供が可能となる。
【０００４】
放送のディジタル化により、多様な情報形態（映像、音声、文字、データ等）によるマルチメディアサービスの提供が可能となり、そのようなサービスを提供するためのシステムも続々と登場してきている。
【０００５】
このようなシステムで、契約内容に基づいてスクランブルを解く、あるいは復号する有料放送サービスを提供する際、契約期間に即した顧客管理が行えなければならない。契約期間に即した顧客管理とは、例えば、所定の料金の支払いより契約された契約期間内に限って契約チャネルの番組の視聴を可能とするというものである。
【０００６】
また、受信装置にてスクランブルあるいは暗号をとくための鍵情報は、不正視聴を防止する上からも正当な視聴者のみに（契約チャネル、契約期間に即して）しかも確実に提供する必要がある。
【０００７】
これを実現するため、従来は放送受信装置毎にマスター鍵を用意し、受信契約している視聴者に対して受信契約しているチャネルのワークキーのみをマスター鍵で暗号化して送っていた。ここでワークキーはチャネル固有の鍵であり、暗号化されて送られてくる当該チャネルのチャネルキーを復号することができる。チャネルキーはスクランブルされた放送コンテンツをデスクランブルするのに用いられる。
【０００８】
さらに、ワークキーは契約期間（通常１ヶ月）毎に設定され、その期間毎に放送局から送られて来る。このため契約期間毎各契約者に必要十分なワークキーを送らなくてはならない。だが逆に見ればワークキーが更新されることにより確実に契約期間が守られるという長所があった。しかし、このシステムを取る限り１ヶ月毎に全契約者に対してワークキーを放送波で送らなければならす、ＣＳ放送の契約者やチャネルが増加傾向にある今日送信量の観点からはかなり厳しくなりつつある。
【０００９】
さらに、今後進行する多チャネル化の流れとデジタルテレビの普及に伴う契約者数の増大は更に限定受信のために送信すべき情報の増加を招くことになる。
【００１０】
【発明が解決しようとする課題】
以上のように、有料放送のチャネルの増大傾向および契約者の増大傾向により、限定受信のために放送配信すべき情報は増大の一途を辿る傾向にある。しかし、限定受信のために放送配信すべき情報に使用できる帯域には限りがあり、このままだとチャネルの増大および契約者の増大をサポートできないという状態に陥ってしまうことが予想される。
【００１１】
本発明は、上記事情を考慮してなされたもので、有料放送の多チャネル化やその契約者が増大するなどした場合においても同程度の安全性を保ちながら限定受信を実現可能とする放送受信装置を提供することを目的とする。
【００１２】
また、本発明は、有料放送の多チャネル化やその契約者が増大するなどした場合において限定受信の制御のために放送配信すべき情報の量の増大を防ぐことのできる放送受信装置を提供することを目的とする。
【００１３】
【課題を解決するための手段】
本発明は、暗号化されて放送配信されるチャネル毎の契約状態に関する情報を含む契約情報に基づいて、暗号化されて放送配信されるコンテンツ情報の復号を可能とするか不能とするかをチャネル毎に制御する放送受信装置であって、受信された前記暗号化された契約情報を復号する復号手段と、この復号された契約情報内に記述されている対応する放送受信装置を指示する情報に基づいて、該契約情報が自装置に対応するものであるか否かを判断する手段と、自装置に対応するものであると判断された前記契約情報について、該契約情報にて指示すべきチャネルの識別情報の表現形態として、チャネルの識別情報を個別に列挙して指定する第１の表現形態と、複数のチャネルを組にしたパッケージの識別情報を個別に列挙して指定する第２の表現形態とのうちのいずれが用いられているかを、該契約情報に付加された表現形態の種別を示す情報によって判定する手段と、この手段により前記契約情報によりパッケージの識別情報が指定されていると判定された場合に、該契約情報とは別に放送配信される、パッケージの識別情報と、該パッケージに包含される複数のチャネルの識別情報を定義した情報とを含むパッケージ定義情報のうち、該当するものを参照して、前記契約情報により指定されたパッケージに包含される複数のチャネルの識別情報を特定する特定手段と、受信した前記契約情報に含まれるチャネルの識別情報と、受信した前記契約情報に含まれるパッケージの識別情報について前記特定手段により特定されたチャネルの識別情報とに基づいて、前記チャネル毎の制御の内容を定める処理手段とを備えたことを特徴とする。
また、本発明は、暗号化されて放送配信されるチャネル毎の契約状態に関する情報を含む契約情報に基づいて、暗号化されて放送配信されるコンテンツ情報の復号を可能とするか不能とするかをチャネル毎に制御する放送受信装置であって、受信された前記暗号化された契約情報を復号する復号手段と、この復号された契約情報内に記述されている対応する放送受信装置を指示する情報に基づいて、該契約情報が自装置に対応するものであるか否かを判断する手段と、自装置に対応するものであると判断された前記契約情報であってチャネルの識別情報群と複数のチャネルを組にしたパッケージの識別情報群とを予め定められた順番で混載可能なものについて、該契約情報に含まれるチャネルの識別情報の個数を示す情報と、パッケージの識別情報の個数を示す情報とに基づいて、該契約情報に含まれる各々の識別情報が、チャネルの識別情報かパッケージの識別情報かを判定する手段と、この手段により前記契約情報にパッケージの識別情報と判定されたものが存在する場合に、該契約情報とは別に放送配信される、パッケージの識別情報と、該パッケージに包含される複数のチャネルの識別情報を定義した情報とを含むパッケージ定義情報のうち、該当するものを参照して、前記契約情報に含まれるパッケージに包含される複数のチャネルの識別情報を特定する特定手段と、受信した前記契約情報に含まれるチャネルの識別情報と、受信した前記契約情報に含まれるパッケージの識別情報について前記特定手段により特定されたチャネルの識別情報とに基づいて、前記チャネル毎の制御の内容を定める処理手段とを備えたことを特徴とする。
また、本発明は、暗号化されて放送配信されるチャネル毎の契約状態に関する情報を含む契約情報に基づいて、暗号化されて放送配信されるコンテンツ情報の復号を可能とするか不能とするかをチャネル毎に制御する放送受信装置であって、受信された前記暗号化された契約情報を復号する復号手段と、この復号された契約情報内に記述されている対応する放送受信装置を指示する情報に基づいて、該契約情報が自装置に対応するものであるか否かを判断する手段と、自装置に対応するものであると判断された前記契約情報について、該契約情報にて指示すべきチャネルの識別情報の表現形態として、チャネルの識別情報を個別に列挙して指定する第１の表現形態と、複数のチャネルを組にしたパッケージの識別情報を個別に列挙して指定する第２の表現形態とのうちのいずれが用いられているかを、該契約情報に付加された表現形態の種別を示す情報によって判定する手段と、この手段により前記契約情報によりパッケージの識別情報が指定されていると判定された場合に、該契約情報とは別に放送配信される、パッケージの識別情報と、該パッケージに包含される複数のチャネルの識別情報を定義した情報または該パッケージに含まれる別のパッケージの識別情報の少なくとも一方とを含むパッケージ定義情報のうち、該当するものを参照して、前記契約情報により指定されたパッケージに包含される複数のチャネルの識別情報を特定する特定手段と、受信した前記契約情報に含まれるチャネルの識別情報と、受信した前記契約情報に含まれるパッケージの識別情報について前記特定手段により特定されたチャネルの識別情報とに基づいて、前記チャネル毎の制御の内容を定める処理手段とを備え、前記特定手段は、或るパッケージの識別情報から該或るパッケージに包含される全てのチャネルの識別情報を特定するにあたって、参照した或るパッケージ定義情報に他のパッケージの識別子が含まれている場合には、該他のパッケージの識別子に該当する他のパッケージ定義情報を参照して、該他のパッケージに包含されるチャネルの識別情報を特定するとともに、該他のパッケージ定義情報に更に他のパッケージの識別子が含まれているならば、次々と該当するパッケージ定義情報を参照することを繰り返すことによって、全てのチャネルの識別情報を特定することを特徴とする。
また、本発明は、暗号化されて放送配信されるチャネル毎の契約状態に関する情報を含む契約情報に基づいて、暗号化されて放送配信されるコンテンツ情報の復号を可能とするか不能とするかをチャネル毎に制御する放送受信装置であって、受信された前記暗号化された契約情報を復号する復号手段と、この復号された契約情報内に記述されている対応する放送受信装置を指示する情報に基づいて、該契約情報が自装置に対応するものであるか否かを判断する手段と、自装置に対応するものであると判断された前記契約情報であってチャネルの識別情報群と複数のチャネルを組にしたパッケージの識別情報群とを予め定められた順番で混載可能なものについて、該契約情報に含まれるチャネルの識別情報の個数を示す情報と、パッケージの識別情報の個数を示す情報とに基づいて、該契約情報に含まれる各々の識別情報が、チャネルの識別情報かパッケージの識別情報かを判定する手段と、この手段により前記契約情報にパッケージの識別情報と判定されたものが存在する場合に、該契約情報とは別に放送配信される、パッケージの識別情報と、該パッケージに包含される複数のチャネルの識別情報を定義した情報または該パッケージに含まれる別のパッケージの識別情報の少なくとも一方とを含むパッケージ定義情報のうち、該当するものを参照して、前記契約情報に含まれるパッケージに包含される複数のチャネルの識別情報を特定する特定手段と、受信した前記契約情報に含まれるチャネルの識別情報と、受信した前記契約情報に含まれるパッケージの識別情報について前記特定手段により特定されたチャネルの識別情報とに基づいて、前記チャネル毎の制御の内容を定める処理手段とを備え、前記特定手段は、或るパッケージの識別情報から該或るパッケージに包含される全てのチャネルの識別情報を特定するにあたって、参照した或るパッケージ定義情報に他のパッケージの識別子が含まれている場合には、該他のパッケージの識別子に該当する他のパッケージ定義情報を参照して、該他のパッケージに包含されるチャネルの識別情報を特定するとともに、該他のパッケージ定義情報に更に他のパッケージの識別子が含まれているならば、次々と該当するパッケージ定義情報を参照することを繰り返すことによって、全てのチャネルの識別情報を特定することを特徴とする。
【００２４】
なお、放送受信装置に係る発明は対応する放送送信装置に係る発明としても成立し、放送送信装置に係る発明は対応する放送受信装置に係る発明としても成立する。
【００２５】
また、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
【００２６】
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００２７】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００２８】
最初に、語句の定義を行なう。
【００２９】
チャネル毎の契約状態を記述した情報を「チャネル契約情報」と呼ぶ。チャネル契約情報は、限定受信を行なうために放送局側から放送受信装置側に放送される制御情報である。
【００３０】
例えば、各チャネルにチャネル番号を付け、図２のようにチャネル番号に対応したビットが１であるか否かによりチャネルの契約状態を表したビット列が、チャネル契約情報の一形態である。図２では、例えば、第２、第５、第７、第８チャネルが契約済であり、第１、第３、第４、第６チャネルが未契約であることを示すことができる。
【００３１】
図２のように各チャネル毎にその契約の有無を表記した情報を「チャネル展開情報」と呼ぶ。全チャネルでｎチャネルあるならば、チャネル展開情報はｎビットのデータとなる。
【００３２】
なお、本実施形態では、限定受信のために放送すべき情報の削減のために、放送局側から放送受信装置側に放送配信するチャネル契約情報の形態としてチャネル展開情報そのものを使用することはせず、後述するように工夫した形態のチャネル契約情報を使用する。放送受信装置側では、自装置に対応するチャネル契約情報を１または複数受信し、これに基づいて最終的に全チャネルに対応した総合的なチャネル展開情報（これを特に総合チャネル展開情報と呼ぶ）を作成・保持し、これに基づいて限定受信のための制御を行うことになる。
【００３３】
しかして、チャネル契約情報は、各受信装置に固有の「受信装置ＩＤ」と相互にリンクされており、当該チャネル契約情報が適用される受信装置ＩＤを示している。この意味でチャネル契約情報と受信装置ＩＤとは一体のものであり、受信装置ＩＤとチャネル契約情報の組を「契約情報」と呼ぶ。
【００３４】
契約情報の改ざんや、不利な契約情報の不取得（例えば契約解除のために放送配信される契約情報の不受信もしくは廃棄等）を防ぐ目的で、契約情報は、暗号化されて放送配信されるとともに、その暗号化の際に、他の情報とセットにして暗号化される（この結果、それらはセットで放送される）。この契約情報と一緒にして暗号化されるデータセットを「受信契約情報」と呼ぶことにする（もちろん受信契約情報には契約情報も含まれる）。
【００３５】
また、本実施形態では、複数のチャネルを組にしたパッケージという概念を使用する。各パッケージの内容（例えばパッケージに含まれるチャネルの組み合わせ）を定義するための情報を「パッケージ定義情報」と呼ぶ。
【００３６】
パッケージ定義情報は、契約情報と同様、他の情報とセットにして暗号化して放送配信される。このパッケージ定義情報と一緒にして暗号化されるデータセットを「受信パッケージ情報」と呼ぶ。
【００３７】
なお、「契約情報」と「パッケージ定義情報」とを総称して「契約関連情報」と呼ぶ。また、受信契約情報と受信パッケージ情報とを総称して「受信契約関連情報」と呼ぶ。
【００３８】
さらに、暗号化された受信契約情報にデータの識別子など本システムに必要な情報を付加したものを「契約情報パケット」と呼び、暗号化された受信パッケージ情報にデータの識別子など本システムに必要な情報を付加したものを「パッケージ情報パケット」と呼び、「契約情報パケット」と「パッケージ情報パケット」とを総称して「契約関連情報パケット」と呼ぶ。
【００３９】
放送受信装置内部で限定受信の仕組みを実現するためのハードウェアを「課金チップ」と呼ぶ。課金チップは、限定受信のために必要な秘密情報をその内部に含むことになるので、その内部のメモリやハード構成に関して外部から容易に読み出し、書き込み、変更ができないように、一体化したＬＳＩとして構成し、耐タンパ構造を有することを仮定している。
【００４０】
課金チップ内部のメモリには、全受信装置に共通のマスター鍵またはそれを生成する機能が含まれているものとする。マスター鍵は、主に受信契約関連情報（受信契約情報、受信パッケージ情報）を復号するために用いられる。
【００４１】
受信装置ＩＤは、受信装置毎個別に設定され、課金チップ内部の不揮発性メモリの中に記録されているものとする。
【００４２】
（第１の実施形態）
第１の実施形態は、契約者（視聴者）やチャネル数が増加しても、限定受信のために放送配信すべき契約情報の増加を抑えることを可能とするために、２種類以上の形態のチャネル契約情報を適宜用いることにより、該情報を削減可能としたものである。
【００４３】
以下、本実施形態の放送受信装置について説明する。
【００４４】
図１に、本実施形態に係る放送受信装置の構成例を示す。
【００４５】
図１に示されるように、本放送受信装置は、受信部１０１、Ａ／Ｄ変換部１０２、誤り検出／訂正部１０３、チャネル選択部１０４、チャネル選択インタフェース（Ｉ／Ｆ）１０５、課金制御部（課金チップ）１０６を有する。また、課金制御部１０６すなわち課金チップには、フィルター部１０７、デスクランブル部１０８、マスター鍵シード認証部１０９、契約関連情報復号部１１０、マスター鍵生成部１１１、マスター鍵格納部１１２、受信装置ＩＤ格納部１１３、契約情報認証部１１４、パッケージ定義情報認証部１１５、契約情報格納部１１６、チャネルキー格納部１１７、契約判定部１１８、チャネル情報入力部１１９、チャネルキー出力部１２０が作り込まれ、耐タンパー性が付与されている。
【００４６】
本実施形態の放送受信装置で受信されるチャネルは、「通常チャネル」と「契約情報チャネル」に大別することができる。通常チャネルには通常の放送コンテンツ（放送コンテンツパケット）が多重化されて流れている。契約情報チャネルには、主に契約関連情報（契約関連情報パケット）と、それよりは少ない頻度でマスター鍵シード（マスター鍵シードパケット）とが流れている。前述のように「契約関連情報」とは「契約情報」と「パッケージ定義情報」の２つであるが、それらのデータ構造を含む詳細については以下で説明する。
【００４７】
なお、契約情報チャネルでは、各情報はそれが変更されたときにだけ放送されるのではなく、同じ内容の情報が、例えば一定期間、繰り返し放送される。
【００４８】
本実施形態の放送受信装置は、その動作中において、上記のような契約情報チャネルと１つ以上の通常チャネルを常時受信するものである。
【００４９】
本実施形態の放送コンテンツは、図３に示すように、３段の暗号化機構によって保護される。
【００５０】
チャネルキーＫｃｈは、スクランブル（暗号化）された放送コンテンツをデスクランブル（復号）するための鍵であり、短期間で変更される。本実施形態ではチャネルキーはチャネル毎に定められるものとする。また、本実施形態では、チャネルキーは、契約情報やパッケージ定義情報とともに、マスター鍵ＫＭで暗号化されて放送配信されるものとする。すなわち、チャネルキーは契約関連情報パケット（受信契約情報や受信パッケージ情報）に含まれた形で送信されるものとする。
【００５１】
マスター鍵ＫＭは、マスター鍵シードＳＭによって定期的に変更される。すなわち、本実施形態では、課金チップ内部には、全受信装置に共通の、マスター鍵シードからマスター鍵を生成する仕組みが作り込まれているものとする。また、本実施形態では、マスター鍵シードは暗号化されずに放送配信されるものとする。
【００５２】
なお、マスター鍵シードを変更する間隔は、チャネルキーを変更する間隔よりも、かなり長くして構わない。例えば、チャネルキーを数秒毎に変更し、マスター鍵シードを１ヶ月毎に変更するようにしてもよい。
【００５３】
以下では、放送される各種データについて説明する。
【００５４】
まず、放送コンテンツについて説明する。
【００５５】
図４に、放送コンテンツパケットのデータ構造例を示す。
【００５６】
「放送コンテンツ」は、図４に示すように、スクランブルされ、情報識別子、チャネル識別子、チャネルキー識別子をヘッダに持つ固定長パッケージで送信される。
【００５７】
「情報識別子」は、当該パケットが「放送コンテンツパケット」と「契約関連情報パケット」と「マスター鍵シードパケット」のいずれであるかを示す識別子であり、数ビットから数バイトの情報量を有する。図４では、当該パケットが「放送コンテンツパケット」であることを示す識別子が割り当てられる。
【００５８】
「チャネル識別子」は、当該放送コンテンツが対応するチャネルのＩＤを示している。
【００５９】
「チャネルキー識別子」は、当該コンテンツを復号するためのチャネルキーのＩＤを示している。
【００６０】
なお、本実施形態では、チャネル識別子とチャネルキー識別子の組みで、チャネルキーが特定されるものとしているが、チャネルキー識別子のみでチャネルキーが特定されるようにしてもよい。
【００６１】
次に、契約関連情報のうちの契約情報について説明する。
【００６２】
図５に、受信契約情報のデータ構造例を示す。
【００６３】
「契約情報」は、チャネル契約情報とｎ個の受信装置ＩＤの組みとして表現される。ｎが複数である場合、列挙された各受信装置ＩＤを持つｎ個の放送受信装置が、この同じチャネル契約情報を受信することになる。
【００６４】
図５に示すように、契約情報は、放送局側の有する秘密鍵でデジタル署名され、これに署名データがデジタル署名として付加される。そして、デジタル署名を付加した契約情報に、さらに、データ識別子、チャネル識別子、チャネルキー識別子、チャネルキー、ＭＡＣを付加した情報が、受信契約情報となる。
【００６５】
この受信契約情報がマスター鍵ＫＭで暗号化されて送信されることになる。
【００６６】
図５において、「データ識別子」は、当該データが「契約情報」と「パッケージ定義情報」のいずれであるかを識別するための情報である。図５においては、当該データが契約情報であることを示す識別子（パッケージ定義情報とは異なる識別子）が割当てられる。
【００６７】
「チャネルキー」は、放送コンテンツをデスクランブルするための復号鍵である。また、「チャネル識別子」はこのチャネルキーが適用されるチャネルの識別子であり、「チャネルキー識別子」はこのチャネルキー自体の識別子であり、これらは放送コンテンツパケットに含まれるチャネル識別子とチャネルキー識別子に対応付けられる。なお、これらチャネルキーに関する情報は、同じ受信契約情報に含まれる契約情報とは関連性を持たない。
【００６８】
図６に、契約関連情報パケットのデータ構造例を示す。
【００６９】
「契約関連情報」を含む契約関連情報パケットは、図６のように、マスター鍵ＫMで暗号化された契約関連情報（受信契約情報もしくは受信パッケージ情報）に、暗号化されていない情報識別子と暗号化されていないマスター鍵識別子とからなる情報をヘッダとして付加することによって、構成される。
【００７０】
「情報識別子」は、前述と同様で、図６では、当該情報が「契約関連情報」であることを示す識別子が割り当てられる。
【００７１】
「マスター鍵識別子」は、当該契約関連情報を復号するためのマスター鍵のＩＤを示している。
【００７２】
前述のように、契約関連情報パケットには、契約情報（受信契約情報）を含む「契約情報パケット」と、パッケージ定義情報（受信パッケージ情報）を含む「パッケージ情報パケット」とがあり、それらは「データ識別子」で識別されることになる。
【００７３】
ここで、ＭＡＣに関して説明する。
【００７４】
ＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）は、図５において、データ識別子からチャネルキーまでの部分のデータが偽造や送信エラー等によって壊されていないか否かをチェックするためのコードである。ＭＡＣの作成は、例えば、データ識別子からチャネルキーまでの部分のハッシュを取ってそのハッシュ値をチャネルキーを使って暗号化したものをＭＡＣとすることによって可能である。例えば、ハッシュ関数ＳＨＡ１で１６０ビットのハッシュ値を得、その上位６４ビットをチャネルキーでＤＥＳ暗号を使って作成すれば６４ビットのＭＡＣが作成され、ほぼ確実に送信エラーを検出することができる。
【００７５】
ただし、偽造に関してはＭＡＣでは限界がある。なぜならば、特定の受信装置を分解解析して、マスター鍵を検出し、ロジックを解明することができれば、ＭＡＣは作成可能となってしまうからである。そのために、本実施形態では、契約情報の部分にはデジタル署名を別途付加している。
【００７６】
本実施形態で考慮しているデジタル署名とは公開鍵暗号によるもので、署名作成の秘密鍵は放送装置側にのみ存在し、受信装置側に存在する署名検証のための公開鍵から秘密鍵を生成するのが極めて困難であるという性質を持っている。このことは、たとえ受信装置が分解解析されてもデジタル署名の作成が極めて困難なことを意味している。したがって、ＭＡＣは誤り検知、デジタル署名は偽造防止の役割があると考えることができる。
【００７７】
ここで、ＭＡＣの対象範囲がデータ識別子からチャネルキーまでであるのに対し、デジタル署名の範囲をデータ識別子から受信装置ＩＤ列までとしているのは、誤り検出をＭＡＣ、偽造防止をデジタル署名という機能分担以外にも、デジタル署名の生成はＭＡＣの生成に比べると処理時間がかかるという理由がある。デジタル署名を、偽造されて問題になる契約情報の部分にのみかけることによって、突然番組が変更になって、チャネルキーが変更になった場合などデジタル署名を計算し直す必要は生じないため、このような構成は実用上極めて有用である。
【００７８】
次に、契約関連情報のうちのパッケージ定義情報について説明する。
【００７９】
図７に、受信パッケージ情報のデータ構造例を示す。
【００８０】
受信パッケージ情報は、基本的には、前述の受信契約情報の場合と同様である。すなわち、パッケージ定義情報にデータ識別子を付加し、それらに対するデジタル署名を付加し、チャネル識別子とチャネルキー識別子とチャネルキーを付加し、さらに該データ識別子から該チャネルキーまでの範囲を対象としたＭＡＣを付加したデータが、受信パッケージ情報となる。
【００８１】
図７において、「データ識別子」は、当該データがパッケージ定義情報であることを示す情報で、契約情報のデータ識別子と同じデータ長で異なる値を割り当てる。「チャネルキー」、「チャネル識別子」、「チャネルキー識別子」については、前述と同様である。
【００８２】
この受信パッケージ情報がマスター鍵ＫＭで暗号化され、暗号化されていない情報識別子と暗号化されていないマスター鍵識別子とからなる情報がヘッダとして付加されて、送信されることになる。
【００８３】
受信パッケージ情報を載せた契約関連情報パケット（パッケージ情報パケット）のデータ構造については前述した通りである（図６参照）。
【００８４】
なお、パッケージ定義情報の内容の詳細については後述する。
【００８５】
次に、マスター鍵、マスター鍵シードについて説明する。
【００８６】
図８に、マスター鍵シードパケットのデータ構造例を示す。
【００８７】
図８に示されるように、マスター鍵シードに、これに対するデジタル署名が付加され、さらに、それらの範囲を対象としたＭＡＣが付加された情報（マスター鍵シード情報）に、暗号化されていない情報識別子と暗号化されていないマスター鍵識別子とからなる情報がヘッダとして付加されて、送信されることになる。
【００８８】
「情報識別子」は、前述と同様で、図８では、当該情報が「マスター鍵シード」であることを示す識別子が割り当てられる。
【００８９】
マスター鍵ＫＭは、当該マスター鍵シードＳＭによって乱数生成の要領で定期的に変更される。
【００９０】
図８の「マスター鍵識別子」は、当該マスター鍵シードから生成したマスター鍵に割り当てるＩＤを示している。
【００９１】
ところで、本実施形態では、「チャネルキー」は契約関連情報パケット（契約情報パケット、パッケージ情報パケット）によって放送され（例えば各チャネルのチャネルキーが順番に繰り返し放送され）、放送受信装置側では、受信契約関連情報をマスター鍵で復号することによって得られる。得られたチャネルキーは、該パケットに含まれるチャネル識別子とチャネルキー識別子をもとに受信装置内部のチャネルキー格納部１１７に格納される。また、契約情報パケットをマスター鍵で復号した際に、受信契約情報の中には、受信装置ＩＤによってリンクされた放送受信装置宛の「チャネル契約情報」が含まれており、自身の受信装置ＩＤに一致する受信装置ＩＤが含まれている場合には、当該チャネル契約情報は契約情報格納部１１６に記録され、その内容に応じて総合チャネル展開情報が更新されるようになっている。また、パッケージ情報パケットをマスター鍵で復号して得られたパッケージ定義情報も契約情報格納部１１６に記録され、必要に応じて総合チャネル展開情報の更新に使用されるようになっている。放送受信時には、契約情報格納部１１６から契約情報を参照し、当該チャネルが契約済であった場合にのみ上記の手順で取得したチャネルキーをチャネルキー格納部１１７からデスクランブル部１０８に送り、スクランブルされた放送コンテンツをデスクランブルする。このようなシステムを取ることにより、チャネルキーを取得するためには、契約情報やパッケージ定義情報を取得し、それらを当該放送受信装置内での限定受信制御のための総合チャネル展開情報に反映しなければならない必然性が生じ、契約を確実に遵守させることが可能となる。
【００９２】
次に、本実施形態の主目的である、チャネル数が増加した際の契約情報の情報量を削減する方法について説明する。
【００９３】
チャネル数が増加した際、チャネル契約情報をチャネル展開情報そのもので記述すると、２００チャンネルでは２００ビット、１０００チャンネルでは１０００ビットが必要であり、受信装置ＩＤが通常４０ビット程度で足りるのに対し情報量が大きすぎる。また、実際は、契約内容（各受信装置が契約するチャンネルの組み合わせ）の種類は２２００通りも存在しないので、このような情報の大半は無駄であると考えられる。さらに、現行の有料放送システムにおいては、いくつかのチャネルを１つのパッケージにまとめ、パッケージ単位で課金する方式がある。これは、パッケージに含まれる各チャネルを個別に契約するよりも格段に割安であり、普通の契約者はどれかのパッケージを購入し、さらに視聴したいチャネルがあれば数チャネル個別に契約する、というのが普通である。
【００９４】
そこで、本実施形態では、図９および図１０の２種類のチャネル契約情報を使用する。
【００９５】
図９に示すチャネル契約情報は、ＯＮ／ＯＦＦ情報、種別情報、１または複数（図９の例では４個）のチャネルＩＤからなっている。
【００９６】
このようなチャネル契約情報を、「チャネル指定型のチャネル契約情報」と呼ぶ。
【００９７】
「ＯＮ／ＯＦＦ情報」は、チャネルＩＤで指定されるチャネルを契約するのか解約するのかを指定するための情報であり、本実施形態では、契約する場合がＯＮ情報、解約する場合がＯＦＦ情報と定義する。
【００９８】
「種別情報」は、当該チャネル契約情報の種別を示すもので、チャネル契約情報の形態の数（本実施形態では、図９と図１０の２種類）に応じて数ビットから数バイトの情報量を持つ固定長のデータである。図９の場合、種別情報は、チャネル指定型のチャネル契約情報であることを示すものである。
【００９９】
「チャネルＩＤ」は、放送システムにおいて決めているチャネルのＩＤ情報である。例えば、最大１０００チャネルを前提とする場合でも、１０ビットで良い。
【０１００】
このチャネル指定型のチャネル契約情報では、チャネルＩＤのビット数、チャネルＩＤの個数は固定長、固定数であることを前提とする。さらに、ｎ個（ｎは複数）のチャネルＩＤを指定する場合、例えば全てのビットが０であるチャネルＩＤを無効と決めておけば、１〜ｎ−１個の間の任意の個数のチャネルＩＤのみを指定することも可能になる。実際、運用では情報圧縮のため図５のように一つのチャネル契約情報に対して同じ受信契約を行っている受信装置ＩＤを数個付ける必要が生じる。このとき、固定個数（図９の例では４個）の範囲で任意個のＩＤを指定できる方が望ましい。
【０１０１】
一方、図１０に示すチャネル契約情報は、図９に示すチャネルＩＤを指定するタイプのチャネル契約情報とは異なり、パッケージＩＤを指定するタイプのチャネル契約情報である。本チャネル契約情報は、ＯＮ／ＯＦＦ情報、種別情報、１または複数（図１０の例では２個）のパッケージＩＤからなっている。
【０１０２】
このようなチャネル契約情報を、「パッケージ指定型のチャネル契約情報」と呼ぶ。
【０１０３】
ＯＮ／ＯＦＦ情報と種別情報は、前述のチャネル指定型の場合と同様である。図１０の場合、種別情報は、パッケージ指定型のチャネル契約情報であることを示すものである。
【０１０４】
「パッケージＩＤ」は、パッケージを識別するＩＤ情報である。ただし、本実施形態では、そのパッケージにどのようなチャネルが入っているかを示すパッケージの定義情報は、パッケージ定義情報（図６、図７参照）という形で、別途共通に送られる。
【０１０５】
パッケージＩＤのビット数や個数についても、チャネル指定型の場合と同様に、固定長、固定数であることが前提であり、システム毎に定めれば良い。また、同様に、予め無効であるＩＤを定めておき、固定数（図１０の例では２個）の範囲で任意個のパッケージを指定することも可能である。
【０１０６】
図１１に、パッケージ定義情報の構造例を示す。
【０１０７】
「パッケージ定義情報」は、パッケージＩＤとパッケージ展開情報からなっている。パッケージ展開情報は、チャネル展開情報と同様で、図２に示すようなチャネル毎にビットが割り当てられ、パッケージＩＤに対応するパッケージに含まれるチャネルに対応したビットのみ１が立ち、それ以外のビットは０であるようなビット列である。
【０１０８】
本実施形態では、チャネル指定型のチャネル契約情報と、パッケージ指定型のチャネル契約情報およびパッケージ定義情報とを適宜組み合わせて利用することにより、放送すべき契約情報を大幅に削減することができる。これらの情報を受信した放送受信装置側では、最終的にチャネル展開情報（総合チャネル展開情報）の形にして保持することになる。
【０１０９】
以下、本実施形態の受信装置の動作について説明する。
【０１１０】
ここで、図１２に、各種情報とそれらの関連性をまとめて示す。
放送配信されるパケットには、放送コンテンツパケット（放送コンテンツを主な内容とする）、マスター鍵シードパケット（マスター鍵シードを主な内容とする）、契約関連情報パケット（契約関連情報とチャネルキーを主な内容とする）があり、それらは情報識別子により識別される。
契約関連情報パケットには、パッケージ定義情報を搭載するものと、契約情報を搭載するものがあり、それらはデータ識別子により識別される。
契約情報には、チャネル指定型のチャネル契約情報と、パッケージ指定型のチャネル契約情報とがあり、それらは種別情報により識別される。
パッケージ指定型のチャネル契約情報のチャネル構成は、パッケージ定義情報により得られる。
【０１１１】
図１３〜図１８に、本実施形態の放送受信装置の動作手順の一例を示す。
【０１１２】
まず、ユーザの操作によりもしくは予約機能等により自動的に、チャネル選択インターフェース１０５で所望のチャネルが選択されるものとする。チャネル選択インターフェース１０５で選択されているチャネル番号は、チャネル選択部１０４へ伝えられ、またチャネル情報入力部１１９から契約判定部１１８へ伝えられる。
【０１１３】
さて、図１３のステップＳ１において受信部１０１で受信された放送波は、Ａ／Ｄ変換部１０２でＡ／Ｄ変換され（ステップＳ２）、当該放送受信装置内部で処理可能なパケットに再構築され（ステップＳ３）、そして、誤り検出／訂正部１０３で誤り検出／訂正される（ステップＳ４）。
【０１１４】
ここで再構築されたパケットは、放送コンテンツパケット（図４）、契約関連情報パケット（図６）、マスター鍵シードパケット（図８）の３種類のいずれかである。
【０１１５】
誤り検出／訂正された放送波は、チャネル選択部１０４に送られ、チャネル選択インターフェース１０５にて選択されたチャネルに対応する放送コンテンツパケットと、契約情報チャネルの全パケットとが課金制御部１０６に送られる。
【０１１６】
いずれのパケットも先頭に固定長の情報識別子が付いており、フィルター部１０７において情報識別子を参照して当該パケットに対する処理を選択する。すなわち、各種のパケットはフィルター部１０７で分離され、当該パケットが放送コンテンツパケットである場合は（ステップＳ５，Ｓ８）、デスクランブル部１０８へ送られ（ステップＳ９）、当該パケットが契約関連情報パケットである場合には（ステップＳ６）、契約関連情報復号部１１０へ送られ（ステップＳ１０）、当該パケットがマスター鍵シードパケットである場合には（ステップＳ７）、マスター鍵生成部１１１へ送られる（ステップＳ１１〜Ｓ１３）。
【０１１７】
（ｉ）まず、放送コンテンツパケットについて説明する。
【０１１８】
受信したパケットが放送コンテンツパケットである場合、デスクランブル部１０８では、図１４に例示したような手順で処理を行う。
【０１１９】
まず、チャネルキー出力部１２０から、当該放送コンテンツをデスクランブルするためのチャネルキーを取得する（ステップＳ２１）。
【０１２０】
すなわち、図４に示す放送コンテンツパケットに含まれるチャネルＩＤとチャネルキーＩＤとをチャネルキー出力部１２０に対して送信して、チャネルキーの出力を要請する。
【０１２１】
チャネルキー出力部１２０では、この要請を受けて、契約判定部１１８に当該チャネルの受信契約の有無を問い合わせる。契約判定部１１８では、その問い合わせを受けて、契約情報格納部１１６に格納されている総合チャネル展開情報を参照し、当該チャネルの受信契約の有無を判定し（当該チャネルに対応するビットが立っているか否かを判定し）、チャネルキー出力部１２０に回答する。チャネルキー出力部１２０では、当該チャネルの契約が存在する場合には、チャネルキー格納部１１７から当該チャネルＩＤの当該チャネルキーＩＤを持つチャネルキーをデスクランブル部１０８に出力するが、当該チャネルの契約が存在しない場合には、チャネルキーの出力は行わず、例えばＮＵＬＬ信号を出力する。
【０１２２】
デスクランブル部１０８では、チャネルキーが出力された場合にのみ（ステップＳ２２）、放送コンテンツのデスクランブルを行ない（ステップＳ２３）、デスクランブルした放送コンテンツを出力する（ステップＳ２４）。
【０１２３】
（ii）次に、マスター鍵シードパケットについて説明する。
【０１２４】
受信したパケットがマスター鍵シードパケットである場合、マスター鍵生成部１１１は、図１５に例示したような手順で処理を行う。
【０１２５】
まず、マスター鍵生成部１１１では、直前のマスター鍵の生成で使用したマスター鍵シードを参照し、これと当該受信したマスター鍵シードとを比較する。それらが一致した場合には（ステップＳ３１）、その時点で処理を終了する。これは、現在使用しているマスター鍵のもととなったマスター鍵シードと一致している場合には、同じマスター鍵が生成されるだけであるので、無駄な生成を行わないようにするための仕組みである。マスター鍵シードは短い期間で変更する必要のないものではあるが、途中で変更される可能性があるので、放送受信装置の起動時に必ず生成されなければならない。このため、高頻度に送信する必要がある。このような状況において上記のような直前に使用したマスター鍵シードとの比較処理がないと、かなり頻繁に必要のない生成を行わなければならない。
【０１２６】
一方、直前に使用したマスター鍵シードと一致しなかった場合は、マスター鍵シードが偽造されていたり、伝送エラーで不一致が生じたものでないことを、ＭＡＣ、そしてデジタル署名で確認する。この確認はマスター鍵シード認証部１０９が行う。
【０１２７】
デジタル署名は、情報のコンテンツ（この場合はマスター鍵シード・データ）のハッシュ値を情報の送信側（この場合は放送局側）が自分の秘密鍵で暗号化したものである。情報の受信側（この場合は放送受信装置側）は同様にハッシュ値を作成し、デジタル署名を放送局の公開鍵で復号したものと一致することによって、当該情報が偽造されていないことを知るのである。これは公開鍵から秘密鍵を求めるには相当な時間がかかることから、秘密鍵を知る放送局でないと当該情報が作成できないところに根拠をおいている。マスター鍵シードパケットにデジタル署名を付加することにより、マスター鍵シードに伝送誤りがあった場合などに通信障害が起こることを未然に防いでいる。
【０１２８】
マスター鍵シードについて、ＭＡＣが検証され、かつ、デジタル署名が検証された場合（ステップＳ３２）、当該マスター鍵シードからマスター鍵を生成する（ステップＳ３３）。
【０１２９】
マスター鍵の生成は線形合同法などの乱数生成のアルゴリズムを用いて行われるが、そのアルゴリズムおよび生成パラメータは課金チップすなわち課金制御部１０６の中のマスター鍵生成部１１１に非公開で存在している。さらに、全く同じアルゴリズムと生成パラメータが放送装置側にも存在し、このことにより放送局側と受信装置側で同じマスター鍵を共有できる。
【０１３０】
生成されたマスター鍵は、マスター鍵識別子と対応させてマスター鍵格納部１１２に格納する（ステップＳ３４）。また、今回のマスター鍵の生成で使用したマスター鍵シード（今回受信したマスター鍵シード）もマスター鍵格納部１１２に格納する（ステップＳ３５）。
【０１３１】
（iii ）次に、契約関連情報パケットについて説明する。
【０１３２】
受信したパケットが契約関連情報パケットである場合、契約関連情報復号部１１０では、図１６〜図１８に例示したような手順で処理を行う。
【０１３３】
まず、契約関連情報復号部１１０では、図６に示されている契約関連情報パケットからマスター鍵識別子を抽出し、当該マスター鍵識別子のマスター鍵をマスター鍵格納部１１２から取得する（図１６のステップＳ４１）。
【０１３４】
もし、取得に失敗した場合は（ステップＳ４２）、その時点で処理を終了する。
【０１３５】
マスター鍵が取得された場合（ステップＳ４２）、続いて、契約関連情報パケットから暗号化された受信契約関連情報を抽出し、当該マスター鍵で復号する（ステップＳ４３）。
【０１３６】
復号した結果得られる情報は、図５に示す受信契約情報か、図７に示す受信パッケージ情報である。両者の識別は、ＭＳＢ側に書かれたデータ識別子を参照して行う。
【０１３７】
もし、当該受信契約関連情報が受信契約情報であれば（ステップＳ４４）、受信契約情報認証部１１４に送信し、受信パッケージ定義情報であれば（ステップＳ４５）、パッケージ定義情報認証部１１５へ送信する。
【０１３８】
まず、受信契約情報である場合、契約情報認証部１１４へ送られ、ＭＡＣがチェックされる（図１７のステップＳ５１）。ＭＡＣが認証されない場合は、何らかの改ざんか送信エラーが生じていると考えられるので、当該受信契約情報に関する処理を終了する。
【０１３９】
ＭＡＣが認証された場合は、受信契約情報からチャネルキーとチャネル識別子とチャネルキー識別子を抽出し、図１９に示したチャネルキー格納部１１７の当該チャネルＩＤ／チャネル識別子の記録エリアに当該チャネルキーを記録する（ステップＳ５２）。
【０１４０】
また、受信契約情報内の受信装置ＩＤの並びの中に、受信装置ＩＤ格納部１１３に格納されている自身の受信装置ＩＤと同じものがあるかどうかをチェックする（ステップＳ５３）。もし、有ればデジタル署名を検証する（ステップＳ５４）。検証の結果デジタル署名の正当性が明らかになった場合（ステップＳ５５）、当該受信契約情報の中のチャネル契約情報を契約情報格納部１１６へ送信する。
【０１４１】
検証の結果デジタル署名が誤りであった場合には偽造の可能性があるので当該契約情報は棄却して処理を終了する。また、当該契約情報に受信装置ＩＤがない場合には当該チャネル契約情報を反映する必要はないので処理を終了する。
【０１４２】
ここで、契約情報格納部１１６では、チャネル契約情報を取得して、図２０〜図２３に例示する手順に従って、当該チャネル契約情報を、チャネル契約格納部１１６に格納すると同時に、総合チャネル展開情報に反映させる。
【０１４３】
まず、ｆｌａｇ＝０と変数の初期化を行う（図２０のステップＳ７１）。このｆｌａｇ変数は、入力されたチャネル契約情報が既に反映されているか否かを示すもので、メモリを書き換える操作を伴う契約情報の反映処理を最小にすることを目的としている。
【０１４４】
次に、入力されたチャネル契約情報がチャネル指定型か否かをチェックする（ステップＳ７２）。
【０１４５】
チャネル指定型であった場合は、ＯＮ／ＯＦＦ情報を参照して、ＯＮ情報か否かをチェックする（ステップＳ７３）。
【０１４６】
ＯＮ情報である場合は、チャネル契約情報に追加する情報であるので、チャネルＩＤ１から順番に当該チャネルＩＤが有効であるか（例えばＮＵＬＬでないか）をチェックし、有効でなかった場合には次のチャネルＩＤを検索してチャネルＩＤの有効性をチェックする（ステップＳ７４〜Ｓ７６，Ｓ８０）。
【０１４７】
有効であった場合には、当該チャネルＩＤが契約情報格納部１１６にある図２４に示すようなチャネルＩＤ指定契約情報格納エリアを検索し、当該チャネルＩＤが存在するかをチェックする（ステップＳ７７）。
【０１４８】
もし、存在する場合は、チャネル契約情報に含まれる次のチャネルＩＤを検索し、有効性チェックからやり直す（ステップＳ７５〜Ｓ７７，Ｓ８０）。
【０１４９】
存在しない場合は、当該チャネルＩＤを契約情報格納部１１６のチャネルＩＤ指定契約情報格納エリアに書き込んで（ステップＳ７８）、ｆｌａｇ＝１として（ステップＳ７９）、契約情報の変更があったことを示す。
【０１５０】
この処理は、チャネル契約情報に書かれるチャネルＩＤの数ｎ回繰り返される（ステップＳ７５〜Ｓ８０）。図９の例では、４回繰り返される。
【０１５１】
ステップＳ７３のＯＮ情報チェックにおいてＯＮ情報でなかった場合（すなわち、ＯＦＦ情報であった場合）、当該チャネルＩＤが有効である場合の取扱い（削除処理；ステップＳ８１〜Ｓ８７）が上記追加処理と逆になる他は上記と同様である。すなわち、この場合、チャネルＩＤ指定契約情報格納エリアに当該有効なチャネルＩＤが存在するとき、当該チャネルＩＤをチャネルＩＤ指定契約情報格納エリアから削除し、ｆｌａｇ＝１とするが、チャネルＩＤ指定契約情報格納エリアに当該有効チャネルＩＤが存在しない場合は、チャネル契約情報に含まれる次のチャネルＩＤを検索し、有効性のチェックからやり直す。
【０１５２】
また、チャネル契約情報がパッケージ指定型のものである場合は図２１に例示する手順に従って処理（ステップＳ９１〜Ｓ１０５）を行う。ここでの処理はチャネル指定型の場合における処理（ステップＳ７２〜Ｓ８６）と基本的には同様であるので、ここでの詳細な説明は省略する。なお、この場合に、図２４に示すようなチャネルＩＤ指定契約情報格納エリアに対応するものは、図２５に示すようなパッケージＩＤ指定契約情報格納エリアである。
【０１５３】
さて、チャネル指定型のチャネル契約情報に対する追加処理、削除処理、パッケージ指定型のチャネル契約情報に対する追加処理、削除処理の４種類の処理のいずれの場合も、チャネル契約情報に含まれる全てのチャネルＩＤ（チャネル指定型の場合）またはパッケージＩＤ（パッケージ指定型の場合）の検索が終了した段階で、図２２および図２３に例示したような手順で、契約情報格納部１１６のパッケージＩＤ指定契約情報格納エリアとチャネルＩＤ指定契約情報格納エリアに存在する情報を、総合チャネル展開情報格納エリアにある総合チャネル展開情報に反映する。
【０１５４】
ｆｌａｇ＝１であるか否かをチェックし（図２２のステップＳ１１１）、ｆｌａｇ＝１でない場合は、契約情報に変更はないので、処理を終了する。
【０１５５】
ｆｌａｇ＝１である場合は、まずパッケージＩＤ指定契約情報格納エリア（図２５参照）にあるＮＵＬＬでないパッケージＩＤに関して、パッケージ展開情報を順次、契約情報格納部１１６内の総合チャネル展開情報に反映する（ステップＳ１１２，Ｓ１１３，Ｓ１１４，Ｓ１１５，Ｓ１１８，Ｓ１１９）。
【０１５６】
ここで、パッケージ展開情報とは、チャネル展開情報と同様にパッケージに含まれるチャネルに対応するビットが過不足なく立っているビット列である。従って、当該パッケージ展開情報の総合チャネル展開情報への反映はそれぞれのビットの論理和（ＯＲ）を取ったものを新たな総合チャネル展開情報にすることによって行われる。
【０１５７】
なお、パッケージ展開情報は、パッケージＩＤがパッケージＩＤ指定契約情報格納エリアに記録されるまでは存在しない。パッケージ展開情報は別途放送波によってパッケージ定義情報という形で与えられるものであるため、上記反映処理は、パッケージ定義情報を受信するまで待機するか、処理を終了し、当該パッケージ定義情報を受信したときに再開する。いずれの場合も、当該パッケージＩＤのパッケージ定義情報が受信され、それがパッケージＩＤ指定契約情報格納エリアに記録された後、上記反映処理を、継続（待機の場合）または再起動（終了の場合）する（ステップＳ１１６，Ｓ１１７）。待機状態を実現する場合は定期的に上記反映プロセスを繰り返すようにすれば良い。なお、パッケージ定義情報の送信に関しては後述する。
【０１５８】
パッケージＩＤ指定契約情報エリアにあるＮＵＬＬでないパッケージＩＤに関して前記処理が終了したら、次にチャネルＩＤ指定契約情報格納エリア（図２４参照）にあるＮＵＬＬでないチャネルＩＤに関して、以下の総合チャネル展開情報への反映処理を行う。本実施形態の場合、チャネルＩＤはチャネル展開情報でのビット位置を表しているので、総合チャネル展開情報のビット列のチャネルＩＤに示されているビットを立てる（１にする）。上記の処理をチャネルＩＤ指定契約情報格納エリアにあるＮＵＬＬでない全てのチャネルＩＤに関して繰り返して、最新の契約内容が反映された総合チャネル展開情報を得る（図２３のステップＳ１２１〜Ｓ１２４）。
【０１５９】
以上で、受信契約関連情報のうち契約情報の処理の説明を終了する。
【０１６０】
次に、契約関連情報復号部１１０で復号された情報がパッケージ定義情報である場合は（図１６のステップＳ４５）、パッケージ定義情報認証部１１５へ送られ、ＭＡＣがチェックされる（図１８のステップＳ６１）。ＭＡＣが認証されない場合は、何らかの改ざんか送信エラーが生じていると考えられるので当該パッケージ定義情報に関する処理を終了する。
【０１６１】
ＭＡＣが認証された場合は、受信契約情報からチャネルキーとチャネル識別子とチャネルキー識別子を抽出し、図１９に示したチャネルキー格納部１１７の当該チャネルＩＤ／チャネル識別子の記録エリアに当該チャネルキーを記録する（ステップＳ６２）。
【０１６２】
また、パッケージ定義情報のパッケージＩＤを抽出し、契約情報格納部１１６のパッケージＩＤ指定契約情報格納エリアを参照し、当該パッケージＩＤの契約が存在するか否かをチェックする（ステップＳ６３）。
【０１６３】
存在しない場合は、パッケージ定義情報の反映処理を終了する。
【０１６４】
存在する場合は、当該パッケージ定義情報のパッケージ展開情報とパッケージＩＤ指定契約情報格納エリアに存在する当該パッケージＩＤのパッケージ展開情報とを比較する（ステップＳ６４）。
【０１６５】
一致する場合には、処理を終了する。
【０１６６】
一致しない場合には、パッケージＩＤ指定契約情報格納エリアの当該パッケージＩＤのパッケージ展開情報に（図２５参照）、当該パッケージＩＤのパッケージ展開情報を反映し（ステップＳ６５）、契約情報格納部１１６に存在する総合チャネル展開情報を更新する（ステップＳ６６）。
【０１６７】
ここで、具体例を用いて簡単に説明すると、ある放送受信装置（受信装置ＩＤを１とする）において、全８チャンネルのうち、第２チャネル、第５チャネル、第７チャネル（チャネルＩＤをそれぞれ２、５、７とする）の３つのチャネルからなるパッケージ（パッケージＩＤを１とする）の受信契約と、第８チャネル（チャネルＩＤを８とする）の個別の受信契約とを行った場合、チャネルＩＤ“８”と受信装置ＩＤ“１”とＯＮ情報を含むチャネル指定型の契約情報（図９、図５、図６参照）と、パッケージＩＤ“１”と受信装置ＩＤ“１”とＯＮ情報を含むチャネル指定型の契約情報（図１０、図５、図６参照）を受信することになり、チャネルＩＤ“８”とパッケージＩＤ“１”がそれぞれ契約情報格納部１１６のチャネルＩＤ指定契約情報格納エリアとパッケージＩＤ指定契約情報格納エリアに格納される（図２４、図２５参照）。また、パッケージＩＤ“１”とそのパッケージ展開情報“０，１，０，０，１，０，１，０”を含むパッケージ定義情報（図１１、図７、図６参照）を受信し、パッケージ展開情報が契約情報格納部１１６のパッケージＩＤ指定契約情報格納エリアにチャネルＩＤ“８”に対応して格納される（図２５参照）。
【０１６８】
そして、上記のチャネルＩＤ指定契約情報格納エリアのチャネルＩＤと、パッケージＩＤ指定契約情報格納エリアのパッケージ展開情報から、当該受信装置における総合チャネル展開情報“０，１，０，０，１，０，１，１”が定まる。この総合チャネル展開情報は、契約情報格納部１１６の総合チャネル展開情報格納エリアに格納される。
【０１６９】
ここで、当該放送受信装置において、さらに第３チャネル（チャネルＩＤを３とする）の個別の受信契約を追加した場合、チャネルＩＤ“３”と受信装置ＩＤ“１”とＯＮ情報を含むチャネル指定型の契約情報を受信することになり、チャネルＩＤ“３”がチャネルＩＤ指定契約情報格納エリアに追加される。そして、このチャネルＩＤ“３”がチャネル契約情報格納エリアの総合チャネル展開情報に追加され、更新後の総合チャネル展開情報は“０，１，１，０，１，０，１，１”となる。
【０１７０】
以上のような処理を行うことにより、多くの場合、契約情報をビット数の少ないパッケージ情報として送付できるので、多チャネル有料放送の限定受信システムにおいても限定受信のための情報を削減することができる。
【０１７１】
ところで、上記では、取得した全てのチャネルキーをチャネル識別子とともにチャネルキー格納部１１７に格納するものとして説明した。しかし、同時に視聴するチャネルは高々１つであるので、視聴しているチャネルのチャネルキーのみ更新するようにしてもよい。この場合には、例えば、チャネル情報入力部１１９を設け、チャネル選択インターフェース１０５で選択されているチャネル番号をチャネル情報入力部１１９から契約情報認証部１１４とパッケージ定義情報認証部１１５に与え、契約情報認証部１１４やパッケージ定義情報認証部１１５で現在視聴しているチャネル番号を参照し、必要なチャネルキーだけをチャネルキー格納部１１７に格納するようにしてもよい。
【０１７２】
なお、この構成を取った場合、チャネル変更時にはチャネルキー格納部１１７の内部をクリアするのが好ましい。何故なら変更後のチャネルのチャネルキーは変更前のチャネルのチャネルキーとは一般的に異なるので、格納部をクリアしないと変更前のチャネルのチャネルキーが有効になってしまい、意味不明の放送コンテンツが出力されることになるからである。このようにすることによって、チャネル変更時には、チャネルキー格納部１１７をクリアしてチャネル契約情報から新たにチャネルキーを取得しなくてはならないため、デスクランブルまでに処理時間がかかるが、チャネルキー格納部１１７のメモリ容量が少なくて済み、また、チャネル数が増えてもメモリ容量を増やすなどの処置をしなくても良い。
【０１７３】
次に、これまで説明した例よりもさらに情報量を削減可能とした情報形態の他の例について説明する。
【０１７４】
ユーザが受信契約をする際に、所望のチャネルを個別に契約するのではなく、パッケージ契約とチャネル契約を数個組み合わせることが一般的である。このような契約者に対して、先の例では２つ異なる形態のチャネル契約情報を送信するようにしたが、ここでは、チャネル契約情報と受信契約情報のデータ構造を修正して、さらに情報量を削減するようにする。
【０１７５】
まず、ここでは、図２６に例示するように、チャネル契約情報を一つ以上のパッケージＩＤと一つ以上のチャネルＩＤを併記できる構造にする。このため、チャネル契約情報に指定するパッケージＩＤの数、チャネルＩＤの数を記述する領域を設け、以下でそれぞれがいくつ続くかを示す。本例においては、パッケージＩＤの方がチャネルＩＤよりも先行して記述されると定めているので、解析は十分に可能となる。むしろここで問題になるのは、チャネル契約情報が可変長になることである。しかしこの点は受信契約情報を図２７に例示するように修正することで解決する。すなわち、チャネル契約情報の次に固定長で受信装置ＩＤの数を記述する。このことにより、パケット内で以下にいくつの受信装置ＩＤが続くか分かるので、解析が可能となる。
【０１７６】
図２８に、このようなチャネル契約情報を反映させるための処理手順の一例を示す（ステップＳ１３１〜Ｓ１６０）。基本的には先の例と同様であるので、ここでは相違する点を中心に説明する。
【０１７７】
先の例では、チャネル契約情報に含まれるものがパッケージＩＤ、チャネルＩＤのどちらか一方であることが種別情報で分かっていたので、どちらか一方の処理をすれば良かったが、本例では、両方混在し得るため、各々の数ｋ，ｌをチャネル契約情報から抽出し、この数分だけそれぞれの反映処理を行う。それぞれの反映処理は、先の例と同じである。処理は、パッケージＩＤ、チャネルＩＤの順番に行い、終了したならば、図２２および図２３に例示したような手順に従って総合チャネル展開情報への展開を行う。
【０１７８】
（第２の実施形態）
第２の実施形態は、契約者（視聴者）やチャネル数が増加しても、限定受信のために放送配信すべき契約情報の増加を抑えることを可能とするために、２段以上の階層構造を持つチャネル契約情報を適宜用いることにより、該情報を削減可能としたものである。
【０１７９】
なお、本実施形態の放送受信装置の構成・動作は、基本的には第１の実施形態と同様であるので、以下では相違する点もしくは追加する点を中心に説明する。
【０１８０】
第１の実施形態では、パッケージ定義情報の中にはパッケージＩＤに対するパッケージ展開情報を記述するものとしたが、本実施形態では、パッケージ定義情報の中に、パッケージＩＤに対して、その定義を、パッケージＩＤ、チャネルＩＤ、チャネル展開情報を併用して記述可能とする。後述する例では、パッケージＩＤとチャネルＩＤの併記、およびパッケージＩＤとチャネル展開情報の併記の２種類を示している。なお、本実施形態において、パッケージをチャネル展開情報のみで定義した場合における当該チャネル展開情報はすなわちパッケージ展開情報である。
【０１８１】
この方式を使えば、一つ以上のパッケージと一つ以上のチャネルＩＤからなる仮想のパッケージを定義することができ、本来の契約でのパッケージとしては定義されていないようなパッケージを放送装置側で仮想的に定義することが可能となる。パッケージ定義情報は、受信パッケージ情報の形で共通に送信することができるので、放送装置側で契約情報の送信量が最小になるように送信パターンを決めることができ、特に契約者の契約パターンが複雑になった場合には有効である。
【０１８２】
図２９に、本実施形態のパッケージ定義情報の一例を示す。
【０１８３】
このパッケージ定義情報は、パッケージＩＤ、種別情報、仮想フラグ、パッケージＩＤの数、チャネルＩＤの数、「パッケージＩＤの数」に応じた数のパッケージＩＤの組み、「チャネルＩＤの数」に応じた数のチャネルＩＤの組み、から構成される。
【０１８４】
図２９のようなパッケージ定義情報を「１モードＩＤ指定型パッケージ定義情報」と呼ぶ。なお、１モード型とは後述する２モード型と対比するための表現である。
【０１８５】
図２９において、「種別情報」は、以下で説明するような他の形態のパッケージ定義情報と区別するための固定長の識別情報である。
【０１８６】
「仮想フラグ」は、当該パッケージ定義情報が、実際に存在するもの（内部にパッケージＩＤを含まないもの）か、情報量削減のために仮想的に設定されたものであるか、を示す固定長の識別情報である。この仮想フラグは、パッケージをチャネル展開情報（パッケージ展開情報）に展開する際に利用する。
【０１８７】
「パッケージＩＤの数」は、本パッケージ定義情報に含まれるパッケージＩＤの数を示す。
【０１８８】
「チャネルＩＤの数」は、本パッケージ定義情報に含まれるチャネルＩＤの数を示している。
【０１８９】
パッケージＩＤの組みは、本パッケージ情報の先頭に記載されているパッケージＩＤで識別されるパッケージに含まれるパッケージＩＤを示している。
【０１９０】
チャネルＩＤの組みは、本パッケージ情報の先頭に記載されているパッケージＩＤで識別されるパッケージに含まれるチャネルＩＤを示している。
【０１９１】
このように１または複数のパッケージＩＤと１または複数のチャネルＩＤからなる契約を１つのパッケージ定義情報で定義可能にすると、これらの情報を受信パッケージ情報に載せて共通に送信することができるので、パッケージＩＤとチャネルＩＤを個々の契約情報に記述する第１の実施形態と比較して、より送信情報量を削減することが期待できる。
【０１９２】
次に、図３０に、本実施形態の１モード型のパッケージ定義情報の他の例を示す。
【０１９３】
このパッケージ定義情報は、図２９のパッケージ定義情報と比較して、個々のチャネルの指定がＩＤによらず、チャネル展開情報によっているところが特徴である。このパッケージ定義情報を、「１モード展開指定型パッケージ定義情報」と呼ぶ。このパッケージ定義情報は、パッケージ以外の（特定パターンの）個別契約チャネル数が多い場合に有効である。すなわち、個別契約チャネルは、図２９の場合にはチャネルＩＤとして個々に記述するが、図３０の場合にはそれらを一つの展開情報として表現できるからである。
【０１９４】
図３０に示されるように、このパッケージ定義情報は、当該パッケージのパッケージＩＤ、種別情報、仮想フラグ、パッケージＩＤの数、「パッケージＩＤの数」に応じた数のパッケージＩＤ、チャネル展開情報からなる。ここで、図２９のパッケージ定義情報に含まれる情報と同じ名称で記述した情報は、図２９で説明したものと同じ意味を持つ。ここで、チャネルＩＤの数が省略されているのは、このパッケージ情報では個別のチャネルはチャネル展開情報によって表現し、チャネルＩＤによっては表現しないからである。
【０１９５】
次に、図３１に、本実施形態の２モード型のパッケージ定義情報の一例を示す。
【０１９６】
このパッケージ情報は、図２９および図３０の２種類のパッケージ定義情報とは異なり、ＯＮ情報である契約済みのパッケージおよびチャネルの情報を記述するパッケージ定義情報と、ＯＦＦ情報である契約を終了するパッケージおよびチャネルを記述するパッケージ定義情報とを併せて記述したものである。
【０１９７】
この形態のパッケージ定義情報を、「２モード型パッケージ定義情報」と呼ぶ。
【０１９８】
先の２種類のパッケージでは、ＯＮ情報もしくはＯＦＦ情報のどちらか一方しか記述できないので、チャネルの入れ替えが生じるような契約変更時には各ユーザにＯＮ情報とＯＦＦ情報の２種類の契約情報を送信することになる。これに対して、このパッケージ定義情報では、ＯＮ情報とＯＦＦ情報を１つの仮想的なパッケージにまとめることができ、非常に有用である。
【０１９９】
以下、本パッケージ定義情報のデータ構造について説明する。
【０２００】
本パッケージ定義情報は、当該パッケージのパッケージＩＤ、種別情報、ＯＮ情報のパッケージ定義、ＯＦＦ情報のパッケージ定義からなる。ここで、パッケージＩＤは、先の２種類のパッケージ定義情報と同じ長さの固定長の情報である。種別情報は、先の２種類のパッケージ定義情報と共通の固定長の長さを持つ情報であり、当該パッケージ定義情報が２モード型パッケージ定義情報であることを示すものである。
【０２０１】
ＯＮ情報パッケージ定義は、図３２に示すように、仮想フラグ、パッケージＩＤの数、チャネルＩＤの数、「パッケージＩＤの数」に応じた数のパッケージＩＤ、「チャネルＩＤの数」に応じた数のチャネルＩＤからなっているか、または、図３３に示すように、仮想フラグ、パッケージＩＤの数、「パッケージＩＤの数」に応じた数のパッケージＩＤ、チャネル展開情報からなっている。図３２と図３３は、それぞれ、図２９に示した１モードＩＤ指定型、図３０に示した１モード展開型のパッケージ定義情報と対応している。すなわち、ＯＮ情報パッケージ定義は、契約を開始する部分の１モードのパッケージ定義と言える。
【０２０２】
ＯＦＦ情報パッケージ定義は、ＯＮ情報パッケージ定義と同様の構造をしており、解約するパッケージや解約するチャネルを示している。
【０２０３】
なお、ＯＮ情報パッケージ定義とＯＦＦ情報パッケージ定義が、それぞれ、１モードＩＤ指定型での定義で記述されているか、１モード展開指定型で記述されているかは、種別情報に盛り込むものとする。この場合、図３１の種別情報には、２モード型パッケージ定義情報を示すものとして、４種類存在することになる。
【０２０４】
次に、このようなパッケージ情報を受信した際の放送受信装置の動作について説明する。
【０２０５】
ここでは、図３４に例示した構造を持つパッケージ定義情報系列を例に取って具体的に説明する。
【０２０６】
図３４に示すパッケージ定義情報系列において、パッケージＩＤ（０）のパッケージは、仮想パッケージであって、パッケージＩＤ１ （１）とパッケージＩＤ２ （１）とチャネル展開情報１から構成されている。
【０２０７】
パッケージＩＤ１ （１）は、仮想パッケージであって、パッケージＩＤ１ （２）とパッケージＩＤ２ （２）からなっている。これら２つのパッケージＩＤ１ （２）とＩＤ２ （２）は、仮想パッケージではなく、それぞれ、チャネル展開情報で定義される。
【０２０８】
パッケージＩＤ２ （１）は、仮想パッケージであって、パッケージＩＤ３ （２）とチャネルＩＤ１ （２）とチャネルＩＤ２ （２）からなっている。パッケージＩＤ３ （２）は、仮想パッケージではなく、チャネル展開情報で定義される。
【０２０９】
さて、パッケージ定義情報を受信した放送受信装置は、パッケージ定義情報認証部１１５で、図３５に例示したような手順で処理を行う。
【０２１０】
まず、パッケージ定義情報から種別情報を抽出し（ステップＳ１７１）、一時メモリに格納する。その種別によって、当該パッケージ定義情報が、１モード型であるか否かをチェックする（ステップＳ１７２）。
【０２１１】
もし、１モード型であれば、ＯＮ情報パッケージ定義の反映処理を行う（ステップＳ１７３）。
【０２１２】
ここで、ＯＮ情報パッケージ定義とは、当該パッケージに含まれるパッケージＩＤ、チャネルＩＤもしくはチャネル展開情報が新たに追加される情報であることを意味する。すなわち、当該パッケージが契約情報で指定されたことによって、当該パッケージに含まれるパッケージＩＤ、チャネルＩＤやチャネル展開情報によって示されているチャネルが、契約チャネルとして追加されることを意味する。また、ＯＦＦ情報パッケージ定義とは、当該パッケージが契約情報で指定されたことによって、当該パッケージに含まれるパッケージＩＤ、チャネルＩＤやチャネル展開情報によって示されているチャネルが、解約チャネルとして削除されることを意味する。
【０２１３】
一方、パッケージ定義情報が１モード型でない場合は、ＯＮ情報パッケージ定義の反映処理（ステップＳ１７４）、ＯＦＦ情報パッケージ定義の反映処理（ステップＳ１７５）の順で処理を行う。
【０２１４】
次に、ＯＮ情報パッケージ定義の反映処理を詳しく説明する。図３６にその処理手順の一例を示す。
【０２１５】
まず、パッケージ定義情報からパッケージＩＤを抽出し（ステップＳ１８１）、当該パッケージＩＤが契約情報格納部１１６のパッケージＩＤ格納エリアに存在するか否かをチェックする（ステップＳ１８２）。存在しなければ、当該受信装置には当該パッケージＩＤのパッケージでの契約は存在しないので、以下の処理は必要がなく、処理を終了する。
【０２１６】
ここで、本実施形態における契約情報格納部１１６の構造について説明する。
【０２１７】
本実施形態の契約情報格納部１１６は、パッケージＩＤ格納エリア、チャネルＩＤ格納エリア、チャネル展開情報格納エリア、総合チャネル展開情報メモリ（総合チャネル展開情報エリア）からなっている。
【０２１８】
パッケージＩＤ格納エリアは、パッケージＩＤの定義を記録するエリアである。
【０２１９】
チャネルＩＤ格納エリアは、指定されたチャネルＩＤを記録するエリアである。
【０２２０】
チャネル展開情報格納エリアは、指定されたチャネル展開情報を格納するエリアである。
【０２２１】
総合チャネル展開情報メモリは、最終的に反映された総合チャネル展開情報を格納するメモリエリアである。総合チャネル展開情報メモリは、契約判定部１１８が参照する。
【０２２２】
さて、ステップＳ１８２でパッケージＩＤが契約情報格納部１１６のパッケージＩＤ格納エリアに存在する場合、ｎ＝ｍ＝０と初期化し（ステップＳ１８３）、種別情報を抽出して（ステップＳ１８４）、一時メモリに格納する。
【０２２３】
次に、この種別情報から当該パッケージ定義情報がＩＤ指定型であるか否かを判断し（ステップＳ１８５）、ＩＤ指定型である場合は、チャネルＩＤ数ｍを抽出し（ステップＳ１８７）、ｎ個のパッケージＩＤとｍ個のチャネルＩＤを順次一時メモリに格納し（ステップＳ１８７，Ｓ１８８）、総合チャネル展開情報メモリへの反映処理を行う（ステップＳ１９１）。
【０２２４】
ステップＳ１８５でＩＤ指定型でない場合は展開指定型であるので、ｎ個のパッケージＩＤとチャネル展開情報を順次一時メモリに格納し（ステップＳ１９０）、総合チャネル展開情報メモリへの反映処理を行う（ステップＳ１９１）。
【０２２５】
次に、図３７に、上記のパッケージＩＤの格納から総合チャネル展開情報への反映処理までの部分の詳しい処理について、その処理手順の一例を示す（ＩＤ指定型と展開指定型の両方を含んでいる）。
【０２２６】
図３７では、ｎ個のパッケージＩＤを抽出し（ステップＳ２０１〜Ｓ２０４）、ＩＤ指定型のパッケージ定義情報ではｍ個のチャネルＩＤを抽出し（ステップＳ２０５〜Ｓ２０８）、展開指定型のパッケージ定義情報ではチャネル展開情報を抽出し（ステップＳ２０９，Ｓ２１０）、それぞれ一時メモリに記録する。
【０２２７】
その後、パッケージＩＤ格納エリアを参照して、パッケージ定義情報で定義されたパッケージＩＤが未定義であるか否かを定義情報の有無情報でチェックし（ステップＳ２１１）、未定義である場合、契約情報更新処理を行う（ステップＳ２１３）。既に定義されていた場合は、既に存在する定義と一時メモリ上の定義が一致するか否かをチェックし（ステップＳ２１２）、一致しない場合は契約情報更新処理を行い（ステップＳ２１３）、一致する場合は契約情報の更新を行う必要はないので終了する。
【０２２８】
次に、契約情報更新処理の詳細を説明する前に、契約情報格納部１１６内のパッケージＩＤ格納エリアの構造について説明する。
【０２２９】
図３８に、パッケージＩＤ格納エリアの構造の具体例を示す。ここで具体的に記載してある情報は、図３４に示したパッケージ定義情報系列の例に対応するものである。
【０２３０】
図３８に表形式で示している情報は、パッケージＩＤ、定義の有無、仮想フラグ、パッケージＩＤの数、チャネルＩＤの数、チャネル展開情報の有無、定義エリアからなる。
【０２３１】
「パッケージＩＤ」は、次項目以下で定義されるパッケージのＩＤを示している。
【０２３２】
「定義の有無」は、定義を既に受信して反映済みか否かを示す情報であり、例えば、反映済みの場合１、そうでない場合は０となる。
【０２３３】
「仮想フラグ」は、パッケージＩＤによって定義されるパッケージが仮想パッケージであるか否かを示す情報であり、例えば、仮想パッケージである場合１、そうでない場合０となる。これはパッケージ定義情報に含まれる仮想フラグによって決まる。
【０２３４】
「パッケージＩＤの数」、「チャネルＩＤの数」、「チャネル展開情報の有無」も、パッケージ定義情報に含まれる情報から反映される。
【０２３５】
「定義エリア」は、パッケージ定義情報に含まれるパッケージＩＤ、チャネルＩＤ、チャネル展開情報からなっている。
【０２３６】
図３９〜図４１に、契約情報更新処理手順の一例を示す。
【０２３７】
まず、当該パッケージ定義情報が仮想パッケージに対する定義情報であるか否かを仮想フラグを参照して判定する（図３９のステップＳ２２１）。
【０２３８】
仮想パッケージであった場合、パッケージＩＤ格納エリアの当該パッケージＩＤのエリア（以下これを該当エリアという）の仮想フラグに１を記録し（ステップＳ２２２）、そうでない場合は０を記録する（ステップＳ２２３）。
【０２３９】
次に、パッケージＩＤの数ｎを該当エリアのパッケージＩＤの数に記録する（ステップＳ２２４）。
【０２４０】
ここで、当該パッケージ定義情報の種別情報を参照して、ＩＤ指定型のパッケージ定義情報であるか否かを判断し（ステップＳ２２５）、ＩＤ指定型であった場合は、該当エリアのチャネルＩＤの数にチャネルＩＤの数ｍを記録し（ステップＳ２２６）、チャネル展開情報の有無には０を記録する（ステップＳ２２７）。ＩＤ指定型でない場合は、該当エリアのチャネルＩＤの数に０を記録し（ステップＳ２２８）、チャネル展開情報の有無に１を記録する（ステップＳ２２９）。
【０２４１】
次に、当該パッケージ定義情報に含まれているパッケージＩＤを順次該当エリアの定義エリアに記録し、パッケージＩＤ格納エリアのパッケージＩＤの欄に当該パッケージＩＤが記載されているかを判断し、記録されていない場合は記録し、定義の有無以下の情報を全て０に初期化する（ステップＳ２３０〜Ｓ２３５）。この処理は、図３８においてパッケージＩＤ（０）の定義に含まれるパッケージＩＤ１ （１）とパッケージＩＤ２ （１）をパッケージＩＤ（０）の定義エリアに記録されていると同時に、パッケージＩＤの欄にも記録されていることからも理解できる。なお、図３８は以下に述べる処理の結果、最終的に到達したパッケージＩＤ状態を記述している。
【０２４２】
パッケージＩＤの展開が終了した後、処理はチャネルＩＤの展開に進む。このアルゴリズムは図４０のフローチャートに詳しく記述されている。
【０２４３】
当該パッケージ定義情報に含まれるチャネルＩＤを順次定義エリアに記録するとともに、契約情報格納部１１６のチャネルＩＤ格納エリアを検索して当該チャネルＩＤが存在しない場合は記録する（ステップＳ２４１〜Ｓ２４５）。以上の処理の流れは図３４におけるパッケージＩＤ２ （１）の展開を例にとると理解しやすい。図３８ではパッケージＩＤ２ （１）はその定義エリアにおいてパッケージＩＤ３ （２）とチャネルＩＤ１ （２）とチャネルＩＤ２ （２）に展開され、そのうちチャネルＩＤ１ （２）とチャネルＩＤ２ （２）は図４２に示すチャネルＩＤ格納エリアにも記録される。
【０２４４】
チャネルＩＤの展開が終了した後、処理はチャネル定義情報の展開に進む。
【０２４５】
まず、当該パッケージ定義情報がＩＤ指定型か否かをチェックし（ステップＳ２４６）、ＩＤ指定型であった場合は、チャネル展開情報は存在しないので、チャネル定義情報の展開処理は終了する。
【０２４６】
ＩＤ指定型でなかった場合は、該当エリアの定義エリアにチャネル展開情報を記録すると同時に契約情報格納部１１６のチャネル展開情報格納エリアにチャネル展開情報を記録する（ステップＳ２４７，S２４８）。以上の処理の流れは図３４におけるパッケージＩＤ（０）の展開を例にとると理解しやすい。図３８ではパッケージＩＤ（０）はその定義エリアにおいてパッケージＩＤ１ （１）とパッケージＩＤ２ （１）とチャネル展開情報１に展開され、そのうちチャネル展開情報１は図４３に示すように契約情報格納部１１６のチャネル展開情報エリアに記録される。
【０２４７】
また、以上の処理により、仮想でないパッケージ定義情報も展開される。仮想でないパッケージ定義情報も同じフォーマットで仮想フラグで仮想でないことを示して送信される。仮想でないので定義は全てチャネル展開情報（パッケージ展開情報）で行われる。すなわち、形式的には展開指定型のパッケージ定義情報であり、０個のパッケージＩＤと０個のチャネルＩＤと１つのチャネル展開情報で構成されていると考えることができる。
【０２４８】
このようなパッケージ定義情報を受け取った際には前述の処理によって、図３８におけるパッケージＩＤ１ （２）、パッケージＩＤ２ （２）、パッケージＩＤ３ （２）のようにそれぞれチャネル展開情報２、チャネル展開情報３、チャネル展開情報４に展開され、該当エリアの定義エリアに記録されると同時にチャネル展開情報格納エリアにも記録される。
【０２４９】
以上の処理により、契約情報格納部１１６のパッケージＩＤ格納エリア、チャネルＩＤ格納エリア、チャネル展開情報格納エリアのテーブルが完成する。完成したか否かは前述の処理が終了した時点でパッケージＩＤ格納エリアの定義の有無が全て１になっていることをもって検出できる。すなわち、図３８の状態がテーブルが完成した状態であり、もはやパッケージＩＤ格納エリアを参照しなくても、チャネルＩＤ格納エリアとチャネル展開情報格納エリアを参照すれば、新しいチャネル展開情報（当該パッケージのパッケージ展開情報）を作成することができる。
【０２５０】
次に、上記情報の総合チャネル展開情報メモリへの反映のための処理について説明する。
【０２５１】
図４１に、そのアルゴリズムを示す。
【０２５２】
まず、契約情報格納部１１６内のパッケージＩＤ格納エリアに未定義のパッケージＩＤがあるか否かをチェックする（ステップＳ２５１）。ここで、未定義のパッケージがあれば、総合チャネル展開情報メモリへの展開は不可能であるので、当該パッケージ定義情報に関する全ての処理を終了する。
【０２５３】
未定義のパッケージが存在しない場合、新しい総合チャネル展開情報を作成するための仮チャネル展開情報のメモリ領域を確保する（ステップＳ２５２）。
【０２５４】
次に、チャネルＩＤ格納エリアにあるチャネルＩＤを順次仮チャネル展開情報に反映する（ステップＳ２５３）。反映の仕方は仮チャネル展開情報上のチャネルＩＤに対応するビットを１にすれば良い。
【０２５５】
次に、チャネル展開情報格納エリアにあるチャネル展開情報を仮チャネル展開情報に反映する（ステップＳ２５４）。これは仮チャネル展開情報とのビット毎の論理和（ＯＲ）を取ったものを新たな仮チャネル展開情報とすれば良い。
【０２５６】
以上の処理が終了した後、仮チャネル展開情報を総合チャネル展開情報メモリに上書きする（ステップＳ２５５）。
【０２５７】
次に、ＯＦＦ情報パッケージ定義の反映処理について詳しく説明する。
【０２５８】
ＯＦＦ情報パッケージ定義情報の処理は図３５に示したアルゴリズムのうち２モード型の場合に行われるが、図３６、図３７に示した情報抽出部分と、図４１に示した総合チャネル展開情報メモリへの反映に関する部分は同じであるので図３９、図４０に相当する情報抽出と内部メモリへの反映の部分を説明する。
【０２５９】
図４４、図４５に、図３９、図４０に相当するアルゴリズムを示す。
【０２６０】
まず、ｆｌａｇ＝０に初期化する（図４４のステップＳ２６１）。ここで、ｆｌａｇは総合チャネル展開情報メモリへの反映処理を行う必要があるか否かの判定フラグである。
【０２６１】
パッケージＩＤの数をｎとし（ステップＳ２６２）、当該パッケージ定義情報がＩＤ指定型である場合には（ステップＳ２６３）、さらに、ｍにチャネルＩＤの数を代入するとともに（ステップＳ２６４）、チャネル展開情報の有無を管理するフラグを０にする（ステップＳ２６５）。一方、展開指定型の場合は、ｍ＝０と初期化し（ステップＳ２６６）、チャネル展開情報の有無フラグを１にする（ステップＳ２６７）。
【０２６２】
次に、定義に含まれるパッケージＩＤを１つずつ抽出し、当該パッケージがパッケージＩＤ格納エリアに存在するか否かをチェックする（ステップＳ２７０）。もし、存在したら当該パッケージを定義している部分を含めて全て消去し（ステップＳ２７１）、ｆｌａｇ＝１とする（ステップＳ２７２）。存在しなかった場合は何も処理しない。この処理を全てのパッケージＩＤについて行った後（ステップＳ２６９，Ｓ２７３）、チャネルＩＤの処理に移る。
【０２６３】
ＯＦＦ情報のパッケージ定義情報にチャネルＩＤの指定があった場合は、チャネルＩＤ格納エリアのチャネルＩＤばかりでなく、パッケージに含まれる当該チャネル部分およびチャネル展開情報格納エリアに含まれる当該チャネル部分の削除をも意味すると考え、順次パッケージＩＤ格納エリアに当該チャネルＩＤのチャネルがあるかどうかをチェックし（図４５のステップＳ２８３）、ある場合には該当部分の削除を行う（ステップＳ２８４）。ここで言う該当部分とは、パッケージＩＤ格納エリアに含まれるチャネルＩＤや、チャネル展開情報の当該チャネルＩＤに対応するビットである。
【０２６４】
さらに、順次チャネルＩＤ格納エリアを検索し、当該チャネルＩＤが存在するか否かを判断し（ステップＳ２８６）、存在した場合には、それを消去する（ステップＳ２８７）。
【０２６５】
最後に、チャネル展開情報格納エリアのチャネル展開情報をチェックして当該チャネルＩＤに対応する部分のビットが１であるかチェックして１である場合には（ステップＳ２８９）、それを０にする（ステップＳ２９０）。
【０２６６】
以上の処理で、削除が起こった時点でｆｌａｇ＝１とする（ステップＳ２８５，Ｓ２８８，Ｓ２９１）。
【０２６７】
この処理を全てのチャネルＩＤについて行う（ステップＳ２８１，Ｓ２８２，Ｓ２９２）。
【０２６８】
また、ＯＦＦ情報のパッケージ定義情報にチャネル展開情報の指定があった場合も（ステップＳ２９３）、同様に処理を行う（ステップＳ２９５〜Ｓ２９９）。すなわち、パッケージに含まれる当該チャネル展開情報に含まれる部分およびチャネル展開情報格納エリアに含まれるチャネル展開情報のうち、当該チャネル展開情報に含まれる部分の削除をも意味すると考え、順次パッケージＩＤ格納エリアに当該チャネル展開情報に含まれるチャネルがあるかどうかをチェックし、ある場合には該当部分の削除を行う。さらに、順次チャネルＩＤ格納エリアを検索し、当該チャネル展開情報に含まれるチャネルが存在するか否かを判断し、存在した場合には、それを消去する。最後に、チャネル展開情報格納エリアのチャネル展開情報をチェックして当該チャネル展開情報に含まれるチャネル部分のビットが１であるかチェックして１である場合にはそれを０にする。以上の処理で、削除が起こった時点でｆｌａｇ＝１とする。
【０２６９】
以上の処理の後、ｆｌａｇをチェックし（ステップＳ２９４，Ｓ３００）、１であれば、図４１に示すような総合チャネル展開メモリへの反映処理を行う。
【０２７０】
また、本実施形態においては、ＯＮ情報の処理がＯＦＦ情報の処理に先だって行われるが、この逆もまた可能であり、同様の処理で実現可能である。
【０２７１】
このように順番を逆にすることにより、例えば、ある時期有利なパッケージができ、多くの契約者がそのパッケージによる契約に変更したような場合、まずＯＦＦ情報のパッケージ定義情報で全てのチャネルを解約してから、ＯＮ情報で当該パッケージのパッケージＩＤを指定するような仮想パッケージを作ることによって、変更前にどのような契約形態を取っていても同じ仮想パッケージで指定することが可能となる。
【０２７２】
なお、本実施形態においては、１モード型パッケージ定義情報は全てＯＮ情報のパッケージ定義情報として扱ったが、１モード型のＯＦＦ情報パッケージ定義情報も有用である。例えば、受信装置の買い替えなどのため全てのチャネルの契約を解除することが考えられる。この際、当該受信装置が行っている契約状態によって異なる解約のため情報を送らなくてはならないが、１モード型のＯＦＦ情報パッケージ定義情報を利用することにより、例えば、１モード型展開指定型パッケージ定義情報を用い、チャネル展開情報の全てのビットに１を立てた仮想パッケージを定義することにより、当該仮想パッケージのパッケージＩＤで指定された受信装置は（たとえどのような契約状態にあっても）全解約ができる。このように一律の解約ができるため、１モード型のＯＦＦ情報パケット定義情報は有用である。また、これの実現は種別情報に１モード型のＯＦＦ情報の指定コードを設け、処理は２モード型のＯＦＦ情報パケット定義情報と同様にすれば可能である。
【０２７３】
以上により本実施形態のパッケージ定義情報のための受信装置の動作の説明を終了する。
【０２７４】
（第３の実施形態）
第３の実施形態では、これまでの各実施形態態の契約関連情報（契約情報、パッケージ定義情報）を送信するための放送送信装置に関して説明する。
【０２７５】
本実施形態では、第２の実施形態のように仮想パッケージを利用可能とする場合を中心に説明するが、第１の実施形態に対応する放送送信装置も基本的には同様である（仮想パッケージを利用可能とする機能は必要ない）。
【０２７６】
本放送送信装置では、仮想的にパッケージを定義することが可能なパッケージ定義情報と、図９／図１０で示したようなチャネル指定型やパッケージ指定型のような自由性の大きいチャネル契約情報とを採用するので、送信量の最適化を図ることができる。本実施形態では、契約情報の送信量が一定以上削減できる場合、仮想パッケージを構成し、当該仮想パッケージと既存のパッケージを用い、パッケージＩＤとチャネルＩＤやチャネル展開情報を効果的に組み合わせることによって、動的に契約情報を作成し、送信するものである。
【０２７７】
なお、第１の実施形態に対応する放送送信装置の場合も、チャネル指定型やパッケージ指定型を効果的に組み合わせることによって、動的に最適な契約情報を作成し、送信することができる。
【０２７８】
さて、図４６に、本実施形態の放送送信装置の構成例を示す。
【０２７９】
図４６に示されるように、本放送受信装置は、契約内容情報入力部２０１、パッケージ内容情報入力部２０２、契約ユーザ・データベース（ＤＢ）２０３、送信契約情報・データベース（ＤＢ）２０４、パッケージ・データベース（ＤＢ）２０５、契約情報最適配置計算部２０６、契約情報生成部２０７、パッケージ定義情報生成部２０８、デジタル署名生成部２０９、デジタル署名用鍵・データベース（ＤＢ）２１０、契約情報・データベース（ＤＢ）２１１、スケジューリング部２１２、契約情報パケット生成部２１３、チャネルキー・データベース（ＤＢ）２１４、マスター鍵・データベース（ＤＢ）２１５、放送契約情報・データベース（ＤＢ）２１６、放送装置２１７を有する。
【０２８０】
契約ユーザＤＢ２０３には、各契約ユーザ（各受信装置ＩＤ）の情報が例えば図４７のデータ構造で格納されている。すなわち、各レコードは、受信装置ＩＤに対して与えられた契約内容をパッケージＩＤとチャネルＩＤで表しており、パッケージＩＤの数、チャネルＩＤの数、「パッケージＩＤの数」に応じた組数の、パッケージＩＤと当該パッケージＩＤでパッケージ契約した日時を表す変更日時とＯＮ／ＯＦＦ情報との組み、「パッケージＩＤの数」に応じた組数の、チャネルＩＤと当該チャネルＩＤでチャネル契約した日時を表す変更日時とＯＮ／ＯＦＦ情報との組み、からなっている。
【０２８１】
契約ユーザＤＢ２０３には契約内容情報入力部２０１からデータが入力される。
【０２８２】
送信契約情報ＤＢ２０４は、例えば図４８のようなデータ構造をしている。すなわち、参照フラグと受信装置ＩＤの組み、パッケージＩＤの数、チャネルＩＤの数、「パッケージＩＤの数」に応じた組数の、パッケージＩＤと参照フラグとＯＮ／ＯＦＦ情報との組み、「チャネルＩＤの数」に応じた組数の、チャネルＩＤと参照フラグとＯＮ／ＯＦＦ情報との組み、からなっており、契約ユーザＤＢ２０３のデータから一定期間に送信するべき契約情報として抽出される。
【０２８３】
パッケージＤＢ２０５は、例えば図４９のようなデータ構造をしている。すなわち、パッケージＤＢ２０５の各レコードが、パッケージＩＤと参照フラグの組、当該パッケージが仮想パッケージであるかを示す仮想フラグ、パッケージＩＤの数、チャネルＩＤの数、チャネル展開情報の有無、「パッケージＩＤの数」に応じた組数の、パッケージＩＤと参照フラグの組み、「チャネルＩＤの数」に応じた組数の、チャネルＩＤと参照フラグの組み、チャネル展開情報、からなっている。
【０２８４】
ここで、参照フラグとは、当該情報が送信契約情報として作成されたか否かを示すフラグであり、１のときは既に作成済みのことを、０のときはまだ作成されていないことを示している。
【０２８５】
送信契約情報ＤＢ２０４にはパッケージ内容情報入力部２０２からデータが入力される。
【０２８６】
チャネルキーＤＢ２１４の各レコードは、例えば図５０に示すように、当該チャネルキーが適用されるチャネルＩＤ、適用期間、当該チャネルキーの識別子であるチャネルキーＩＤ、チャネルキーからなる。
【０２８７】
マスター鍵ＤＢ２１５の各レコードは、例えば図５１に示すように、当該マスター鍵のＩＤ、当該マスター鍵が適用される適用期間、マスター鍵からなっている。
【０２８８】
デジタル署名用鍵ＤＢ２１０は、例えば図５２に示すような一組の秘密鍵と公開鍵とのペアからなっている。
【０２８９】
次に、本実施形態の放送送信装置における契約情報の作成・送信手順について説明する。
【０２９０】
図５３に、その処理手順の一例を示す。
【０２９１】
本放送送信装置内の契約情報生成部２０７は、内部の時計（またはカウンタ）によって計時することにより、一定の時刻になった時点で、一定期間の契約情報を作成する。
【０２９２】
ここでは簡単のため、毎日午後３時にその翌日放送分の契約情報を作成するものとし、翌日の放送に対応する契約情報は最近２ヶ月間に契約変更があった契約情報であるとした場合を具体例として説明する。
【０２９３】
上記のように例えば午後３時になると、契約情報生成部２０７は、契約情報最適配置計算部２０６に、契約情報の最適配置を行う旨の信号を出す。すると、契約情報最適配置計算部２０６は、契約ユーザＤＢ２０３から最近２ヶ月間に変更のあった情報を抽出し、図４８に示す送信契約情報ＤＢ２０４に登録する（ステップＳ３１１）。ここで、情報の抽出にあたっては、契約ユーザＤＢ２０３の変更日時を参照して、例えば最近２ヶ月間の日付が付いている情報だけを抽出する。すなわち、例えば１ヶ月前に解約したチャネルのチャネルＩＤは出力されても、同じ受信装置ＩＤに対応する３ヶ月前に契約したパッケージＩＤの情報は出力されない。
【０２９４】
上記のような基準で作成された送信契約情報ＤＢ２０４に対して、契約情報送信最適化のための仮想パッケージの定義を行ない（ステップＳ３１２）、パッケージＤＢ２０５へそれを登録する（ステップＳ３１３）。パッケージ定義情報は、パッケージ定義情報生成部２０８によって作成される。
【０２９５】
図５４に、仮想パッケージを定義するための処理手順の一例を示す。
【０２９６】
なおここでは、簡単のため１モード型のチャネル契約情報のみを考えることにし、２モード型のチャネル契約情報による契約情報は作成しないものとする。
【０２９７】
まず、送信契約情報ＤＢ２０４を検索し、仮想パッケージを一切用いない場合の総契約情報送信量を算出する（ステップＳ３２１）。次に、送信契約情報ＤＢ２０４にある全てのレコードを参照して、送信契約情報ＤＢ２０４にある全てのパッケージＩＤとチャネルＩＤの組合せを求め、それぞれに該当する受信装置ＩＤの数を計数する（ステップＳ３２２）。当該計数値の多いものから仮想パッケージにした際の契約情報送信量の削減率を求め削減率が１％以上である組合せを仮想パッケージとして定義し、これをパッケージＤＢ２０５に登録する（ステップＳ３２３）。このようにすることによってむやみに仮想パッケージを定義することによる混乱を避けることができる。
【０２９８】
仮想パッケージの定義をパッケージＤＢ２０５に登録した後、最適なチャネル契約情報に基づいた契約情報を作成する（図５３のステップＳ３１４）。
【０２９９】
図５５に、最適なチャネル契約情報の決定と当該チャネル契約情報に基づいた契約情報の作成手順の一例を示す。
【０３００】
まず、契約情報生成部２０７は、パッケージＤＢ２０５から仮想パッケージに対応したパッケージＩＤの数を算出し、それら仮想パッケージＩＤとその定義を順次抽出し、以下の処理を行う。
【０３０１】
まず、当該仮想パッケージＩＤｉに含まれる契約内容を含む送信契約情報をＯＮ情報／ＯＦＦ情報の別に送信契約情報Ｄ２０４Ｂより抽出する（ステップＳ３３４）。そして、当該パッケージＩＤを指定したチャネル契約情報を含む契約情報をＯＮ情報／ＯＦＦ情報の別に作成し、作成が終了した送信契約情報の項目ｉの参照フラグを１にする（ステップＳ３３５）。これとともに、送信契約情報ＤＢ２０４に含まれる当該レコードの情報の中で当該仮想パッケージの定義に含まれる情報の参照フラグを１にして、当該情報が契約情報として反映されたことを示す（ステップＳ３３６）。
【０３０２】
上記の処理を全ての仮想パッケージＩＤについて行う（ステップＳ３３２，Ｓ３３３，Ｓ３３７）。
【０３０３】
次に、通常のパッケージＩＤの最適な組合せ方の検索に移る（ステップＳ３３８〜Ｓ３４０）。ここで、パッケージ指定型のチャネル情報は２以下のパッケージＩＤからなることを仮定しているので、ＯＮ情報／ＯＦＦ情報の別に送信契約情報ＤＢを検索して、２つ以下のパッケージＩＤの組合せのうちで最も数の多いものから順番に当該パッケージＩＤの組をチャネル契約情報とする契約情報を作成する。ここで、作成が終了した送信契約情報ＤＢレコードの該当部分の参照フラグを１にして、次回以降の契約情報作成の際に参照しないようにする。
【０３０４】
通常のチャネルＩＤの最適な組合せも前記パッケージＩＤの組合せの場合と同様に行う。
【０３０５】
次に、上記の処理で契約情報生成部２０７から契約情報パケット生成部２１３に出力された契約情報を基に契約情報パケットを作成する処理（図５３のステップＳ３１５）について説明する。
【０３０６】
図５６に、その処理手順の一例を示す。
【０３０７】
上記の契約情報が入力されると（ステップＳ３５１）、まず、デジタル署名生成部２０９により、デジタル署名用鍵ＤＢ２１０から秘密鍵を抽出し（ステップＳ３５２）、契約情報にデジタル署名を付ける（ステップＳ３５３）。デジタル署名の作成は、当該契約情報のハッシュを取り、そのハッシュ値を秘密鍵で暗号化するという通常のデジタル署名の作成形態を取る。デジタル署名が付加された契約情報ＤＢ２１１に格納される。今回作成される全ての契約情報は一旦契約情報ＤＢ２１１に格納されるので、契約情報ＤＢ２１１は一定期間（ここでは１日）に繰り返し放送される契約情報を格納しておくデータベースであるといえる。
【０３０８】
上記の契約情報ＤＢ２１１にある契約情報は、放送スケジュールを管理するスケジューリング部２１２の命令で抽出され、契約情報パケット生成部２１３へ送られる。契約情報パケット生成部２１３では、チャネルキーＤＢ２１４からスケジューリング部２１２の定める放送時間に該当するチャネルキーをチャネルＩＤとともに順次抽出し（ステップＳ３５４）、契約情報にデジタル署名を付加した契約情報ＤＢ２１１から抽出したデータに付加し、全体に付加したチャネルキーを用いてＭＡＣを作成し（ステップＳ３５５）、付加して受信契約情報が完成する。さらに、マスター鍵ＤＢ２１５から放送スケジューリング部２１２が定める放送時間に適用するマスター鍵を検索し、検索されたマスター鍵で受信契約情報を暗号化する（ステップＳ３５６）。暗号化された受信契約情報に情報識別子を付加し（ステップＳ３５７）、契約情報パケットが完成し、これを放送契約情報ＤＢ２１６に出力する（ステップＳ３５８）。このようにして、契約情報パケットは、放送契約情報ＤＢ２１６に格納される（図５３のステップＳ３１７）。
【０３０９】
放送装置２１７は、上記の放送契約情報ＤＢ２１６から順次パケットを読み出して放送する（図５３のステップＳ３１８）。
【０３１０】
以上で本実施形態の放送送信装置の契約情報の作成に関する説明を終わる。
【０３１１】
最後に、本実施形態の放送送信装置のバリエーションに関して述べる。
【０３１２】
本放送送信装置は、仮想パッケージを自動的に定義することができる。しかし、最適化アルゴリズムは必ずしも完全なものではなく、場合によっては特異なデータ群によって偏ったパッケージがいくつもできる可能性がある。この意味でもパッケージの定義は自動的でなく、人手によって行うというのも一つの考え方である。このためには、図４６に示した放送送信装置においてパッケージ内容情報入力部２０２から仮想パッケージの入力もできるようにすると良い。これには入力のインターフェースを変更すれば良く、仮想パッケージの定義を自動で行わないためには契約情報最適配置計算部２０６において仮想パッケージの定義を行なう処理を省略すれば良い。
【０３１３】
（第４の実施形態）
第４の実施形態は、同じチャネル契約情報を持つ（もしくは同じチャネル契約情報を送信すべき）複数の契約者の受信装置ＩＤを受信装置ＩＤの特徴によって類別し、圧縮した形で受信契約情報に含めることによって契約者の増加に伴う契約情報の削減を実現するものである。
【０３１４】
本実施形態では、契約者の増加に備えて、契約情報のうち受信装置ＩＤの記述部分に着目し、圧縮する方法を示す。本実施形態においても受信契約情報は、一般に図５のように構成する。ただし、本実施形態において着目すべきところは、受信装置ＩＤの記述部分であるので、簡単のため受信契約情報を図５７のように考える。すなわち、受信装置ＩＤの記述部分を受信装置ＩＤ情報と呼び、受信装置ＩＤ情報の圧縮記述を中心に考える。
【０３１５】
さて、契約者が多くなってきた場合、受信装置ＩＤも多くなる反面、特徴の似ている受信装置ＩＤも増える。このことを携帯電話の電話番号を例にとって説明する。携帯電話の電話番号は、契約者が少ないときには番号同士の間はかなり開いていて類似ＩＤを見つけにくいが契約者が多くなると次第に間が詰まって、最終的には欠番のない状態にまでなるので、類似ＩＤが頻繁に発生する。本実施形態では、このような点に着目し、受信契約者が多くなってきた場合に、同じチャネル契約情報を持つ契約者の受信装置ＩＤを類似したものを組にして圧縮することにより、契約情報を削減しようとするものである。
【０３１６】
（ｉ）まず、受信装置ＩＤの上位ビットが同じものを類似ＩＤとして捉えた例を示す。この場合の受信装置ＩＤ情報は、図５８のように構成することができ、このような受信装置ＩＤを、「上位ＩＤ分離型受信装置ＩＤ情報」と呼ぶ。
【０３１７】
図５８において、「種別情報」は、本受信装置ＩＤ情報が上位ＩＤ分離型であることを示す固定長のデータである。
【０３１８】
「受信装置ＩＤの数（ｎとする）」は、一括して記述する上位ＩＤのビット長を示す固定長のデータである。
【０３１９】
また、以下では、ここで指定されたビット数分の上位ビットのＩＤを「上位ＩＤ」と呼び、ＩＤ＋と記述することにする。また、ＩＤから上位ＩＤを取り除いたものを「下位ＩＤ」と呼び、ＩＤ−と記述することにする。
【０３２０】
「上位ビット長（ｍとする）」の次に上位ビット長だけの上位ＩＤが記述される。そして、先に指定されている受信装置ＩＤの数の分だけ下位ＩＤの列が続く。このようにすることによって、共通の上位ＩＤを省略できるので、契約情報を削減することができる。
【０３２１】
（ii）次に、受信装置ＩＤが連続しているものを類似ＩＤと捉えた例を示す。図５９が連続した受信装置ＩＤを指定する際に有効な受信装置ＩＤ情報の例である。このような受信装置ＩＤ情報を「系列指定型受信装置ＩＤ情報」と呼ぶ。
【０３２２】
図５９において、「種別情報」は、本受信装置ＩＤ情報が系列指定型であることを示す固定長のデータである。
【０３２３】
「受信装置ＩＤの数」は、本受信装置ＩＤ情報に含まれる受信装置ＩＤの数である。
【０３２４】
「形式情報」は、続く受信装置ＩＤの情報が、連続したＩＤを開始ＩＤと終了ＩＤによって指定したものか、単独で指定したものかを示している。ここで、連続したＩＤを開始ＩＤと終了ＩＤで記述するものであったときは、続く２つのＩＤがそれぞれ開始ＩＤ、終了ＩＤにあたる。単独で指定されたものであるときは、１つのＩＤが続き、当該ＩＤが単独で指定されている。
【０３２５】
また、受信装置ＩＤが連続しているものを類似ＩＤと捉えた場合、図６０のように構成する方法もある。これは連続したＩＤを指定するとき、開始ＩＤと終了ＩＤではなく、開始ＩＤと継続数により表現する方式である。継続数に必要なデータ長は、一般に終了ＩＤよりも短いため、さらに情報量を圧縮することができる。
【０３２６】
（iii ）次に、受信装置ＩＤを羅列して指定する型の受信装置ＩＤ情報を示す。これは、図５に例示した受信契約情報における受信装置ＩＤ情報に近いものであり、図６１に示すように羅列指定型であることを示す種別情報と、受信装置ＩＤの数と、受信装置ＩＤ情報の数の分だけの受信装置ＩＤが続く。このような受信装置ＩＤ情報を「羅列指定型受信装置ＩＤ情報」と呼ぶ。
【０３２７】
次に、このような受信装置ＩＤ情報を含む受信契約情報を受信した際の放送受信装置の動作について説明する。
【０３２８】
これらの動作は、図１の契約情報認証部１１４内の動作であり、全体の動作の中では、図１７のフローチャートにおける、受信契約情報は当該受信装置のものか否かを判定する部分（ステップＳ５３）の動作である。従って、本実施形態は、第１、第２、第３の実施形態においても利用できるものであるとともに、本実施形態においても、第１、第２、第３の実施形態と同じ手法が利用でき、各実施形態は互いに独立した発明の関係にある。
【０３２９】
図６２〜図６５に、この場合の処理手順の一例を示す。
【０３３０】
受信装置ＩＤ情報の中から種別情報を抽出し（ステップＳ３６１）、当該受信装置ＩＤ情報が上位ＩＤ分離型か系列指定型か羅列指定型かを判定し（ステップＳ３６２，Ｓ３６３）、それぞれの処理に渡す（ステップＳ３６４〜Ｓ３６６）。
【０３３１】
（ｉ）上位ＩＤ分離型であった場合は、図６３に示すフローチャートにしたがって、受信装置ＩＤの数ｎ、上位ビット数ｍを読み込み（ステップＳ３７１，Ｓ３７２）、続いて、ｍビットの上位ＩＤ（ＩＤ＋）を読み込む（ステップＳ３７３）。
【０３３２】
続いて、ｎ個の下位ＩＤ（ＩＤ−）を順次読み込み、ＩＤ＝ＩＤ＋＋ＩＤ−によって受信ＩＤを復元する（ステップＳ３７５〜Ｓ３７９）。ここでは、演算子＋は結合を意味する。
【０３３３】
復元されて受信装置ＩＤを自装置のＩＤと比較することによって、当該受信装置ＩＤが自装置のものがどうかをチェックする（ステップＳ３７８）。
【０３３４】
ここで、自装置のものであった場合は、照合した旨の出力を行い（ステップＳ３８１）、終了する。
【０３３５】
自装置のものでなかった場合は、次の下位ＩＤを読み込み、同様の操作でチェックする（ステップＳ３７５〜Ｓ３７９）。
【０３３６】
ｎ個の下位ＩＤ全てについてチェックが終了したら（自装置のものがなかったならば）、照合しない旨の出力を行い（ステップＳ３８０）、終了する。
【０３３７】
（ii）系列指定型であった場合は、図６４に示すフローチャートに従って、受信装置ＩＤの数ｎを読み込み（ステップＳ３９１）、全体で受信装置ＩＤの数になるまで続く受信装置ＩＤを読み込む。
【０３３８】
受信装置ＩＤ情報の読み込みについて詳しく説明する。
【０３３９】
最初にｉ＝０とする（ステップＳ３９２）。次に、形式情報を読み込み（ステップＳ３９５）、続く受信装置ＩＤ情報が開始ＩＤと終了ＩＤが指定された系列情報であるか否かを判断する（ステップＳ３９６）。
【０３４０】
系列情報であった場合は、順次開始ＩＤと終了ＩＤを取得して（ステップＳ４０１，Ｓ４０２）、開始ＩＤから終了ＩＤまでの間に自装置ＩＤがあるか否かをチェックする（ステップＳ４０３）。あった場合は、照合した旨の出力をして終了し（ステップＳ４０４）、なかった場合は、開始ＩＤから終了ＩＤの間にある受信装置ＩＤの数ｍを計算し（ステップＳ４０５）、ｉ＝ｉ＋ｍとして（ステップＳ４０６）、ｉがｎとなるまで、次の形式情報と受信装置ＩＤ情報を読み込み、同様の処理を行う（ステップＳ３９３〜Ｓ３９６，Ｓ４０１〜Ｓ４０６）。
【０３４１】
さらに、形式情報によって続く受信装置ＩＤ情報が系列情報でない場合、続く受信装置ＩＤを取得し（ステップＳ３９７）、自装置のＩＤと比較を行う（ステップＳ３９８）。比較の結果、自装置のＩＤと一致した場合は、照合した旨の出力を行い（ステップＳ３９９）、終了する。一致しない場合は、ｉ＝ｉ＋１として（ステップＳ４００）、ｉがｎとなるまで、次の形式情報と受信装置ＩＤ情報を読み込み、同様の処理を行う（ステップＳ３９３〜Ｓ４００）。む。
【０３４２】
ｉがｎとなったとき（自装置のものがなかったならば）、照合しなかった旨の出力をして（ステップＳ３９４）、処理を終了する。
【０３４３】
（iii ）羅列指定型であった場合は、図６５に示すフローチャートに従って、受信装置ＩＤの数ｎを読み込み（ステップＳ４１１）、続くｎ個受信装置ＩＤを順次読み込んで（ステップＳ４１２〜ステップＳ４１４）、自装置ＩＤと比較し（ステップＳ４１５）、一致した場合は、照合した旨の出力を行い（ステップＳ４１８）、終了する。一致しない場合は、ｎ個の受信装置ＩＤを読み込むまで、同様の処理を繰り返す（ステップＳ４１３〜Ｓ４１８）。
【０３４４】
ｉがｎとなったとき（自装置のものがなかったならば）、照合しなかった旨の出力を行い（ステップＳ４１７）、終了する。
【０３４５】
以上で、本実施形態の放送受信装置の動作の説明を終了する。
【０３４６】
なお、受信装置ＩＤ情報は、上記の他にも種々の形態が考えられる。ここでは、他の例として、上位ＩＤ分離型と系列指定型の両方を含む混合型受信装置ＩＤ情報を示す。この場合のデータ形式は、図６６に示す通りで、図５９に示した系列指定型の受信装置ＩＤ情報の形式情報に新たに系列指定型の識別情報（例えば“１１”）を追加し、続いて上位ＩＤ分離指定型の受信装置ＩＤ情報を記述する。この部分以外は、系列指定型の受信装置ＩＤ情報と同じである。さらに、この場合の放送受信装置の動作は、混合型の受信装置ＩＤ情報の構成から、例えば図６２〜図６５に例示した処理手順における上位ＩＤ分離型に対する照合動作と系列指定型に対する照合動作とを組み合わせれば、混合型の受信装置ＩＤ情報の照合を行うことができる。
【０３４７】
次に、本実施形態の契約情報を作成する放送送信装置の構成および動作について説明する。
【０３４８】
ここでは、本実施形態についての説明を簡単にするために、チャネル契約情報は、チャネル展開情報で記述されているものとする。
【０３４９】
図６７に、本実施形態の放送送信装置の構成例を示す。基本的には、第３の実施形態の放送送信装置（図４６）と同様である。ただし、ここでは、チャネル契約情報にチャネル展開情報のみを用いるものとして説明するため、パッケージ情報の関連部分を省いている。もちろん、本実施形態と第１、第２、第３の実施形態を組み合わせて実施することも可能であり、その場合には、図４６と同様の構成になる。
【０３５０】
図６７の例では、放送受信装置は、契約内容情報入力部１２０１、契約ユーザ・データベース（ＤＢ）１２０３、送信契約情報・データベース（ＤＢ）１２０４、契約情報最適配置計算部１２０６、契約情報生成部１２０７、デジタル署名生成部１２０９、デジタル署名用鍵・データベース（ＤＢ）１２１０、契約情報・データベース（ＤＢ）１２１１、スケジューリング部１２１２、契約情報パケット生成部１２１３、チャネルキー・データベース（ＤＢ）１２１４、マスター鍵・データベース（ＤＢ）１２１５、放送契約情報・データベース（ＤＢ）１２１６、放送装置１２１７を含んで構成される。各部分は、基本的には、図４６の対応する部分と同様である。
【０３５１】
契約ユーザＤＢ１２０３のデータ構造は、図６８に示すようであり、受信装置ＩＤと、当該受信装置のチャネル契約情報（チャネル展開情報）と、当該チャネル契約情報の最新変更日時とからなる。
【０３５２】
送信契約情報ＤＢ１２０４のデータ構造は、図６９に示すようであり、受信装置ＩＤと、当該受信装置のチャネル契約情報（チャネル展開情報）と、当該レコードの情報が契約情報として生成されたか否かを示す参照フラグとからなる。
【０３５３】
デジタル署名用鍵ＤＢ１２１０やチャネルキーＤＢ１２１４やマスター鍵ＤＢ１２１５は、第３の実施形態に示した形と同様である。
【０３５４】
次に、本実施形態の放送送信装置における契約情報の作成手順について説明する。
【０３５５】
図７０および図７１に、その処理手順の一例を示す。
【０３５６】
契約情報生成部１２０７は、内部の時計（またはカウンタ）によって計時することにより、一定の時刻になった時点で、一定期間の契約情報を作成する。
【０３５７】
ここでは簡単のために、第３の実施形態と同様、毎日午後３時にその翌日放送分の契約情報を作成するものとし、翌日の放送に対応する契約情報は、最近２ヶ月間に契約変更があった契約情報であるとした場合を具体例として説明する。
【０３５８】
上記のように例えば午後３時になると、午後３時になると、契約情報生成部１２０７は、契約情報最適配置計算部１２０６に、契約情報の最適配置を行う旨の信号を出す。すると、契約情報最適配置計算部１２０６は、契約ユーザＤＢ１２０３から最近２ヶ月間に変更のあった情報を抽出し、図６７に示す送信契約情報ＤＢ１２０４に登録する（ステップＳ４２１）。ここで、情報の抽出にあたっては、契約ユーザＤＢ１２０３の変更日時を参照して、最近２ヶ月間の日付が付いている情報だけを抽出する。すなわち、例えば１ヶ月前に解約したチャネルのチャネルＩＤは出力されても、同じ受信装置ＩＤに対応する３ヶ月前に契約したパッケージＩＤの情報は出力されない。
【０３５９】
上記のような基準で作成された送信契約情報ＤＢ１２０４に対して、同じチャネル契約情報を持つ受信装置ＩＤを検索し、系列指定型、上位ＩＤ指定型、羅列型のいずれかの形式で当該受信装置ＩＤを含む受信装置ＩＤ情報を作成する。
【０３６０】
まず、送信契約情報ＤＢ１２０４を検索し、契約情報を作成していない（すなわち、参照フラグが０の）レコードが存在するかを確認する（ステップＳ４２２）。
【０３６１】
存在しない場合は、全てのレコードに対する契約情報が作成されたことを意味するので、処理を終了する。
【０３６２】
存在する場合は、そのようなレコードのうちで検索の結果最初に出現したレコードのチャネル契約情報を抽出する（ステップＳ４２３）。再び送信契約情報ＤＢ１２０４を検索し、当該チャネル契約情報を持つレコードから受信装置ＩＤを全て抽出する（ステップＳ４２４）。ここで、抽出された受信装置ＩＤは、同じチャネル契約情報を有するため、同一の契約情報を作成することが可能となる。
【０３６３】
次に、抽出された受信装置ＩＤをＩＤの若い順にソートし（ステップＳ４２５）、まず連番の受信装置ＩＤを抽出する（ステップＳ４２６）。抽出された連番の受信装置ＩＤは、系列指定型受信装置ＩＤ情報で表現できるものなので、これらを系列指定型受信装置ＩＤ情報で表現し、契約情報を作成する（ステップＳ４２７）。また、ここで作成された受信装置ＩＤを検索結果から削除するとともに、これを含む送信契約情報ＤＢ１２０４のレコードの参照フラグを１にする。
【０３６４】
次に、上位ＩＤ分離型の作成に進む。ここでは、上位ＩＤ分離型契約情報の作成は、ＩＤを上位と下位に分離した結果、著しい効率化が認められる場合のみ、行うものとする。例えば、受信装置ＩＤが４０ビットあったとして、上位１０ビットを上位ＩＤとし、２１０通りある上位ＩＤを順次検索し（ステップＳ４２８，Ｓ４２９，Ｓ４３２）、同じ上位ＩＤを持つ受信装置ＩＤが３０個以上あった場合のみ（ステップＳ４３０）、上位ＩＤ分離指定型で表現するようにしている（ステップＳ４３１）。このようにすることによって、明らかに非効率であるような同じ上位ＩＤしか持たない場合でも、上位ＩＤ分離指定型にしてしまうという問題を防ぐ。
【０３６５】
なお、上記の例では、受信契約情報の情報量を僅かでも削減しなければならない程には逼迫していない状況を考えて、敢えて基準値３０以上と指定するようにしたものであるが、実際には２つ以上同じ上位ＩＤを持つ場合は上位ＩＤ分離指定型を取ることにより圧縮の効果があるので、帯域の逼迫状況により上記の基準値を柔軟に変化させることが好ましい。また、上位ＩＤのビット数も（ここでは１０にしているが）、抽出された受信装置ＩＤの数により、柔軟に変化させることが望ましい。例えば、受信装置ＩＤの数が大きい場合は、上位ＩＤのビット数を多くし、少ない場合は、上位ビットのビット数を少なくすることにより、より効率的な契約情報の作成ができる。
【０３６６】
もしくは、受信装置ＩＤを小さい順に検索して行き、（固定長の）上位ＩＤ分離型の契約情報に最大限詰め込めるように上位ビットを決定することもできる。これは、検索される受信装置ＩＤの上位ビットの共通部分を求め、１つの契約情報に最大限詰め込めるＩＤの集合とそのときの上位ＩＤビットのビット数から決定できる。このように送信契約情報ＤＢ１２０４の内容によって動的に契約情報を構成し、最も効率のよい構成を自動的に選べることも本実施形態の放送送信装置の特徴である。
【０３６７】
ここで、抽出された受信装置ＩＤを上位分離型受信装置ＩＤ情報で表現し、契約情報を作成する（ステップＳ４３１）。また、ここで作成された受信装置ＩＤを検索結果から削除するとともに、これを含む送信契約情報ＤＢ１２０４のレコードの参照フラグを１にする。
【０３６８】
最後に、残りの受信装置ＩＤについて羅列指定型で契約情報を作成して、当該チャネル契約情報に対する契約情報を終了する（ステップＳ４２８〜Ｓ４３０，Ｓ４３３，Ｓ４３４）。
【０３６９】
この一連の処理を、送信契約情報ＤＢ１２０４の全てのデータの参照フラグが０になるまで（ステップＳ４２２）、繰り返す。
【０３７０】
次に、上記の処理で契約情報生成部１２０７から契約情報を基に契約情報パケットを作成する処理について説明する。
【０３７１】
この場合の処理手順の一例は、図５６と同様である。
【０３７２】
上記の契約情報が入力されると（ステップＳ３５１）、まず、デジタル署名生成部１２０９により、デジタル署名用鍵ＤＢ１２１０から秘密鍵を抽出し（ステップＳ３５２）、契約情報にデジタル署名を付ける（ステップＳ３５３）。デジタル署名の作成は、当該契約情報のハッシュを取り、そのハッシュ値を秘密鍵で暗号化するという通常のデジタル署名の作成形態を取る。デジタル署名が付加された契約情報ＤＢ１２１１に格納される。今回作成される全ての契約情報は一旦契約情報ＤＢ１２１１に格納されるので、契約情報ＤＢ１２１１は一定期間（ここでは１日）に繰り返し放送される契約情報を格納しておくデータベースであるといえる。
【０３７３】
上記の契約情報ＤＢ１２１１にある契約情報は、放送スケジュールを管理するスケジューリング部１２１２の命令で抽出され、契約情報パケット生成部１２１３へ送られる。契約情報パケット生成部１２１３では、チャネルキーＤＢ１２１４からスケジューリング部１２１２の定める放送時間に該当するチャネルキーをチャネルＩＤとともに順次抽出し（ステップＳ３５４）、契約情報にデジタル署名を付加した契約情報ＤＢ１２１１から抽出したデータに付加し、全体に付加したチャネルキーを用いてＭＡＣを作成し（ステップＳ３５５）、付加して受信契約情報が完成する。さらに、マスター鍵ＤＢ１２１５から放送スケジューリング部１２１２が定める放送時間に適用するマスター鍵を検索し、検索されたマスター鍵で受信契約情報を暗号化する（ステップＳ３５６）。暗号化された受信契約情報に情報識別子を付加し（ステップＳ３５７）、契約情報パケットが完成し、これを放送契約情報ＤＢ１２１６に出力する（ステップＳ３５８）。
【０３７４】
放送装置１２１７は、上記の放送契約情報ＤＢ１２１６から順次パケットを読み出して放送する。
【０３７５】
以上で本実施形態の放送送信装置の契約情報の作成に関する説明を終了。
【０３７６】
最後に、本実施形態では、簡単のために、チャネル契約情報をチャネル展開情報として扱ったが、本実施形態は同じチャネル契約情報を持つ受信装置ＩＤの組み合わせについて成り立つので、チャネル契約情報は、第１、第２、第３の実施形態で説明したようなパッケージ指定型であってもチャネル指定型であっても、またそのパッケージが仮想パッケージを含むような階層構造をしていても同様に構成できる。
【０３７７】
よって、第１〜第４の実施形態は独立の技術であり（各実施形態は独立しても適宜組み合わせても実施可能であり）、適宜実施形態を組み合わせそれら実施形態の各利点を生かしてより強力に契約情報の情報量の削減ができるシステムも各実施形態から容易に構築可能である。
【０３７８】
なお、以上の放送送信装置の各機能は、ソフトウェアとしても実現可能である。
【０３７９】
また、各実施形態に係る放送送信装置は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても実施することもできる。
【０３８０】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０３８１】
【発明の効果】
本発明によれば、有料放送の多チャネル化やその契約者が増大するなどした場合において限定受信の制御のために放送配信すべき情報の量の増大を防ぐことができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係る放送受信装置の構成例を示す図
【図２】チャネル展開情報の一例を示す図
【図３】放送コンテンツの暗号化機構について説明するための図
【図４】放送コンテンツパケットのデータ構造例を示す図
【図５】受信契約情報のデータ構造例を示す図
【図６】契約関連情報パケットのデータ構造例を示す図
【図７】受信パッケージ情報のデータ構造例を示す図
【図８】マスター鍵シードパケットのデータ構造例を示す図
【図９】チャネル指定型のチャネル契約情報のデータ構造例を示す図
【図１０】パッケージ指定型のチャネル契約情報のデータ構造例を示す図
【図１１】パッケージ定義情報の構造例を示す図
【図１２】各種情報とそれらの関連性を説明するための図
【図１３】本発明の実施の形態に係る放送受信装置における放送受信からパケットの内容に応じた処理までの全体的な処理手順の一例を示すフローチャート
【図１４】放送コンテンツパケットに対する処理手順の一例を示すフローチャート
【図１５】マスター鍵シードパケットに対する処理手順の一例を示すフローチャート
【図１６】契約関連情報パケットに対する処理手順の一例を示すフローチャート
【図１７】契約関連情報パケットに対する処理手順の一例を示すフローチャート
【図１８】契約関連情報パケットに対する処理手順の一例を示すフローチャート
【図１９】チャネルキーの記録エリアの一例を示す図
【図２０】チャネル契約情報に対する処理手順の一例を示すフローチャート
【図２１】チャネル契約情報に対する処理手順の一例を示すフローチャート
【図２２】チャネル契約情報に対する処理手順の一例を示すフローチャート
【図２３】チャネル契約情報に対する処理手順の一例を示すフローチャート
【図２４】チャネルＩＤ指定契約情報格納エリアの一例を示す図
【図２５】パッケージＩＤ指定契約情報格納エリアの一例を示す図
【図２６】チャネル契約情報の他のデータ構造例を示す図
【図２７】受信契約情報の他のデータ構造例を示す図
【図２８】チャネル契約情報に対する処理手順の他の例を示すフローチャート
【図２９】１モードＩＤ指定型パッケージ定義情報のデータ構造例を示す図
【図３０】１モード展開指定型パッケージ定義情報のデータ構造例を示す図
【図３１】２モード型のパッケージ定義情報のデータ構造例を示す図
【図３２】ＯＮ情報パッケージ定義とＯＦＦ情報パッケージ定義のデータ構造の第１の例を示す図
【図３３】ＯＮ情報パッケージ定義とＯＦＦ情報パッケージ定義のデータ構造例の第２の例を示す図
【図３４】仮想パッケージについて説明するための図
【図３５】各モードのパッケージ定義情報に対する処理手順の一例を示すフローチャート
【図３６】ＯＮ情報パッケージ定義の反映処理の手順の一例を示すフローチャート
【図３７】ＯＮ情報パッケージ定義の反映処理のうちパッケージＩＤの格納から総合チャネル展開情報への反映処理までの部分のより詳しい処理手順の一例を示すフローチャート
【図３８】パッケージＩＤ格納エリアのデータ構造例を示す図
【図３９】契約情報更新処理手順の一例を示すフローチャート
【図４０】契約情報更新処理手順の一例を示すフローチャート
【図４１】契約情報更新処理手順の一例を示すフローチャート
【図４２】チャネルＩＤ格納エリアの一例を示す図
【図４３】チャネル展開情報エリアの一例を示す図
【図４４】契約情報更新処理手順の他の例を示すフローチャート
【図４５】契約情報更新処理手順の他の例を示すフローチャート
【図４６】本発明の実施の形態に係る放送送信装置の構成例を示す図
【図４７】契約ユーザ・データベースのデータ構造例を示す図
【図４８】送信契約情報・データベースのデータ構造例を示す図
【図４９】パッケージ・データベースのデータ構造例を示す図
【図５０】チャネルキー・データベースのデータ構造例を示す図
【図５１】マスター鍵・データベースのデータ構造例を示す図
【図５２】デジタル署名用鍵・データベースのデータ構造例を示す図
【図５３】契約情報の作成・送信手順の一例を示すフローチャート
【図５４】仮想パッケージを定義するための処理手順の一例を示すフローチャート
【図５５】最適なチャネル契約情報の決定と当該チャネル契約情報に基づいた契約情報の作成手順の一例を示すフローチャート
【図５６】契約情報を基に契約情報パケットを作成する処理手順の一例を示すフローチャート
【図５７】受信契約情報のデータ構造例を示す図
【図５８】上位ＩＤ分離型受信装置ＩＤ情報のデータ構造例を示す図
【図５９】系列指定型受信装置ＩＤ情報のデータ構造例を示す図
【図６０】系列指定型受信装置ＩＤ情報のデータ構造例を示す図
【図６１】羅列指定型受信装置ＩＤ情報のデータ構造例を示す図
【図６２】本発明の実施の形態に係る放送受信装置におけるＩＤ情報の種別判断の処理手順の一例を示すフローチャート
【図６３】上位ＩＤ分離型受信装置ＩＤ情報に対する処理手順の一例を示すフローチャート
【図６４】系列指定型受信装置ＩＤ情報に対する処理手順の一例を示すフローチャート
【図６５】羅列指定型受信装置ＩＤ情報に対する処理手順の一例を示すフローチャート
【図６６】混合型受信契約ＩＤ情報のデータ構造例を示す図
【図６７】本発明の実施の形態に係る放送送信装置の構成例を示す図
【図６８】契約ユーザ・データベースのデータ構造例を示す図
【図６９】送信契約情報・データベースのデータ構造例を示す図
【図７０】契約情報の作成・送信手順の一例を示すフローチャート
【図７１】契約情報の作成・送信手順の一例を示すフローチャート
【符号の説明】
１０１…受信部
１０２…Ａ／Ｄ変換部
１０３…誤り検出／訂正部
１０４…チャネル選択部
１０５…チャネル選択Ｉ／Ｆ
１０６…課金制御部
１０７…フィルター部
１０８…デスクランブル部
１０９…マスター鍵シード認証部
１１０…契約関連情報復号部
１１１…マスター鍵生成部
１１２…マスター鍵格納部
１１３…受信装置ＩＤ格納部
１１４…契約情報認証部
１１５…パッケージ定義情報認証部
１１６…契約情報格納部
１１７…チャネルキー格納部
１１８…契約判定部
１１９…チャネル情報入力部
１２０…チャネルキー出力部
２０１，１２０１…契約内容情報入力部
２０２…パッケージ内容情報入力部
２０３，１２０３…契約ユーザ・データベース
２０４，１２０４…送信契約情報・データベース
２０５…パッケージ・データベース
２０６，１２０６…契約情報最適配置計算部
２０７，１２０７…契約情報生成部
２０８…パッケージ定義情報生成部
２０９，１２０９…デジタル署名生成部
２１０，１２１０…デジタル署名用鍵・データベース
２１１，１２１１…契約情報・データベース
２１２，１２１２…スケジューリング部
２１３，１２１３…契約情報パケット生成部
２１４，１２１４…チャネルキー・データベース
２１５，１２１５…マスター鍵・データベース
２１６，１２１６…放送契約情報・データベース
２１７，１２１７…放送装置
Claims (8)
- 暗号化されて放送配信されるチャネル毎の契約状態に関する情報を含む契約情報に基づいて、暗号化されて放送配信されるコンテンツ情報の復号を可能とするか不能とするかをチャネル毎に制御する放送受信装置であって、
受信された前記暗号化された契約情報を復号する復号手段と、
この復号された契約情報内に記述されている対応する放送受信装置を指示する情報に基づいて、該契約情報が自装置に対応するものであるか否かを判断する手段と、
自装置に対応するものであると判断された前記契約情報について、該契約情報にて指示すべきチャネルの識別情報の表現形態として、チャネルの識別情報を個別に列挙して指定する第１の表現形態と、複数のチャネルを組にしたパッケージの識別情報を個別に列挙して指定する第２の表現形態とのうちのいずれが用いられているかを、該契約情報に付加された表現形態の種別を示す情報によって判定する手段と、
この手段により前記契約情報によりパッケージの識別情報が指定されていると判定された場合に、該契約情報とは別に放送配信される、パッケージの識別情報と、該パッケージに包含される複数のチャネルの識別情報を定義した情報とを含むパッケージ定義情報のうち、該当するものを参照して、前記契約情報により指定されたパッケージに包含される複数のチャネルの識別情報を特定する特定手段と、
受信した前記契約情報に含まれるチャネルの識別情報と、受信した前記契約情報に含まれるパッケージの識別情報について前記特定手段により特定されたチャネルの識別情報とに基づいて、前記チャネル毎の制御の内容を定める処理手段とを備えたことを特徴とする放送受信装置。 - 暗号化されて放送配信されるチャネル毎の契約状態に関する情報を含む契約情報に基づいて、暗号化されて放送配信されるコンテンツ情報の復号を可能とするか不能とするかをチャネル毎に制御する放送受信装置であって、
受信された前記暗号化された契約情報を復号する復号手段と、
この復号された契約情報内に記述されている対応する放送受信装置を指示する情報に基づいて、該契約情報が自装置に対応するものであるか否かを判断する手段と、
自装置に対応するものであると判断された前記契約情報であってチャネルの識別情報群と複数のチャネルを組にしたパッケージの識別情報群とを予め定められた順番で混載可能なものについて、該契約情報に含まれるチャネルの識別情報の個数を示す情報と、パッケージの識別情報の個数を示す情報とに基づいて、該契約情報に含まれる各々の識別情報が、チャネルの識別情報かパッケージの識別情報かを判定する手段と、
この手段により前記契約情報にパッケージの識別情報と判定されたものが存在する場合に、該契約情報とは別に放送配信される、パッケージの識別情報と、該パッケージに包含される複数のチャネルの識別情報を定義した情報とを含むパッケージ定義情報のうち、該当するものを参照して、前記契約情報に含まれるパッケージに包含される複数のチャネルの識別情報を特定する特定手段と、
受信した前記契約情報に含まれるチャネルの識別情報と、受信した前記契約情報に含まれるパッケージの識別情報について前記特定手段により特定されたチャネルの識別情報とに基づいて、前記チャネル毎の制御の内容を定める処理手段とを備えたことを特徴とする放送受信装置。 - 暗号化されて放送配信されるチャネル毎の契約状態に関する情報を含む契約情報に基づいて、暗号化されて放送配信されるコンテンツ情報の復号を可能とするか不能とするかをチャネル毎に制御する放送受信装置であって、
受信された前記暗号化された契約情報を復号する復号手段と、
この復号された契約情報内に記述されている対応する放送受信装置を指示する情報に基づいて、該契約情報が自装置に対応するものであるか否かを判断する手段と、
自装置に対応するものであると判断された前記契約情報について、該契約情報にて指示すべきチャネルの識別情報の表現形態として、チャネルの識別情報を個別に列挙して指定する第１の表現形態と、複数のチャネルを組にしたパッケージの識別情報を個別に列挙して指定する第２の表現形態とのうちのいずれが用いられているかを、該契約情報に付加された表現形態の種別を示す情報によって判定する手段と、
この手段により前記契約情報によりパッケージの識別情報が指定されていると判定された場合に、該契約情報とは別に放送配信される、パッケージの識別情報と、該パッケージに包含される複数のチャネルの識別情報を定義した情報または該パッケージに含まれる別のパッケージの識別情報の少なくとも一方とを含むパッケージ定義情報のうち、該当するものを参照して、前記契約情報により指定されたパッケージに包含される複数のチャネルの識別情報を特定する特定手段と、
受信した前記契約情報に含まれるチャネルの識別情報と、受信した前記契約情報に含まれるパッケージの識別情報について前記特定手段により特定されたチャネルの識別情報とに基づいて、前記チャネル毎の制御の内容を定める処理手段とを備え、
前記特定手段は、或るパッケージの識別情報から該或るパッケージに包含される全てのチャネルの識別情報を特定するにあたって、参照した或るパッケージ定義情報に他のパッケージの識別子が含まれている場合には、該他のパッケージの識別子に該当する他のパッケージ定義情報を参照して、該他のパッケージに包含されるチャネルの識別情報を特定するとともに、該他のパッケージ定義情報に更に他のパッケージの識別子が含まれているならば、次々と該当するパッケージ定義情報を参照することを繰り返すことによって、全てのチャネルの識別情報を特定することを特徴とする放送受信装置。 - 暗号化されて放送配信されるチャネル毎の契約状態に関する情報を含む契約情報に基づいて、暗号化されて放送配信されるコンテンツ情報の復号を可能とするか不能とするかをチャネル毎に制御する放送受信装置であって、
受信された前記暗号化された契約情報を復号する復号手段と、
この復号された契約情報内に記述されている対応する放送受信装置を指示する情報に基づいて、該契約情報が自装置に対応するものであるか否かを判断する手段と、
自装置に対応するものであると判断された前記契約情報であってチャネルの識別情報群と複数のチャネルを組にしたパッケージの識別情報群とを予め定められた順番で混載可能なものについて、該契約情報に含まれるチャネルの識別情報の個数を示す情報と、パッケージの識別情報の個数を示す情報とに基づいて、該契約情報に含まれる各々の識別情報が、チャネルの識別情報かパッケージの識別情報かを判定する手段と、
この手段により前記契約情報にパッケージの識別情報と判定されたものが存在する場合に、該契約情報とは別に放送配信される、パッケージの識別情報と、該パッケージに包含される複数のチャネルの識別情報を定義した情報または該パッケージに含まれる別のパッケージの識別情報の少なくとも一方とを含むパッケージ定義情報のうち、該当するものを参照して、前記契約情報に含まれるパッケージに包含される複数のチャネルの識別情報を特定する特定手段と、
受信した前記契約情報に含まれるチャネルの識別情報と、受信した前記契約情報に含まれるパッケージの識別情報について前記特定手段により特定されたチャネルの識別情報とに基づいて、前記チャネル毎の制御の内容を定める処理手段とを備え、
前記特定手段は、或るパッケージの識別情報から該或るパッケージに包含される全てのチャネルの識別情報を特定するにあたって、参照した或るパッケージ定義情報に他のパッケージの識別子が含まれている場合には、該他のパッケージの識別子に該当する他のパッケージ定義情報を参照して、該他のパッケージに包含されるチャネルの識別情報を特定するとともに、該他のパッケージ定義情報に更に他のパッケージの識別子が含まれているならば、次々と該当するパッケージ定義情報を参照することを繰り返すことによって、全てのチャネルの識別情報を特定することを特徴とする放送受信装置。 - 前記契約情報には、受信契約の追加か解除かを示す情報が含まれ、
前記処理手段は、新たに契約情報を受信した場合、該契約情報に前記追加を示す情報が含まれているときは、該契約情報に含まれる追加に係るチャネルの識別情報または該契約情報に含まれる追加に係るパッケージの識別情報から特定されたチャネルの識別情報に係るチャネルについて、それまでコンテンツ情報の復号を不能とする制御を行っていたならば、以降、コンテンツ情報の復号を可能とする制御を行うものとし、該契約情報に前記解除を示す情報が含まれているときは、該契約情報に含まれる解除に係るチャネルの識別情報または該契約情報に含まれる解除に係るパッケージの識別情報から特定されたチャネルの識別情報に係るチャネルについて、それまでコンテンツ情報の復号を可能とする制御を行っていたならば、以降、コンテンツ情報の復号を不能とする制御を行うものとすることを特徴とする請求項１ないし４のいずれか１項に記載の放送受信装置。 - 前記復号手段は、自装置内に記憶されている他の放送受信装置と共通のマスター鍵で、受信した前記暗号化された契約情報を復号することを特徴とする請求項１ないし５のいずれか１項に記載の放送受信装置。
- 前記暗号化されたコンテンツ情報を復号するためのチャネルキーに関する情報は、前記契約情報とともに暗号化されて放送配信されることを特徴とする請求項１ないし６いずれか１項に記載の放送受信装置。
- 前記処理手段は、各チャネル毎に定められた前記制御の内容に基づいて、暗号化されたコンテンツ情報を復号するためのチャネルキーを、暗号化されたコンテンツ情報を復号するための復号手段に送るか否かを制御することを特徴とする請求項１ないし７のいずれか１項に記載の放送受信装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP36927698A JP3688918B2 (ja) | 1998-12-25 | 1998-12-25 | 放送受信装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP36927698A JP3688918B2 (ja) | 1998-12-25 | 1998-12-25 | 放送受信装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000196544A JP2000196544A (ja) | 2000-07-14 |
| JP3688918B2 true JP3688918B2 (ja) | 2005-08-31 |
Family
ID=18494021
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP36927698A Expired - Fee Related JP3688918B2 (ja) | 1998-12-25 | 1998-12-25 | 放送受信装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3688918B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002318750A (ja) * | 2001-04-20 | 2002-10-31 | Sony Corp | 受信確認装置 |
| JP2003087233A (ja) * | 2001-09-10 | 2003-03-20 | Toshiba Corp | デジタル放送システム、装置及びプログラム |
| JP5431623B2 (ja) * | 2011-08-18 | 2014-03-05 | 三洋電機株式会社 | 通信装置 |
| JP6442944B2 (ja) * | 2014-09-12 | 2018-12-26 | ソニー株式会社 | 受信装置、受信方法、送信装置、及び、送信方法 |
-
1998
- 1998-12-25 JP JP36927698A patent/JP3688918B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000196544A (ja) | 2000-07-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8656178B2 (en) | Method, system and program product for modifying content usage conditions during content distribution | |
| JP3891952B2 (ja) | コンテンツ配布中に鍵管理ブロックのサイズを管理する方法、システム、およびプログラム | |
| US6650752B2 (en) | Broadcast reception device and contract management device using common master key in conditional access broadcast system | |
| EP2104051B1 (en) | Data protection system that protects data by encrypting the data | |
| CN100479455C (zh) | 内容使用系统 | |
| EP1280149B1 (en) | Apparatus and method and for protected recording and playback of digital content | |
| DK2408202T3 (en) | Method and device for secure transfer and playback of multimedia content | |
| US20070124252A1 (en) | Reception device, transmission device, security module, and digital right management system | |
| JP3695992B2 (ja) | 放送受信装置及びコンテンツ利用制御方法 | |
| JP2003152698A (ja) | コンテンツ利用制御送信方法、コンテンツ利用制御受信方法およびコンテンツ利用制御送信装置、コンテンツ利用制御受信装置ならびにコンテンツ利用制御送信プログラム、コンテンツ利用制御受信プログラム | |
| CN1581774A (zh) | 对数字内容的访问控制 | |
| BRPI0721588A2 (pt) | unidade de gerenciamento de chave de embaralhamento, unidade de transmissço de informaÇÕes de gerenciamento da chave de embaralhamento, mÉtodo para gerenciamento de saÍda da chave de embaralhamento, programa de gerenciamento de chave de embaralhamento, unidade de gerenciamento de informaÇÕes de licenÇa, unidade de transmissço de informaÇÕes de gerenciamento de licenÇa, mÉtodo para gerenciamento de saÍda de informaÇÕes de licenÇa, e programa de gerenciamento de informaÇÕes de licenÇa | |
| CN1343420A (zh) | 数字本地网络的一种全球拷贝保护系统 | |
| CN1222133C (zh) | 数据传送方法、数据接收方法、数据传送系统 | |
| JP2005057701A (ja) | 情報処理装置、およびコンテンツ情報管理方法、並びにコンピュータ・プログラム | |
| US20040236940A1 (en) | Contents supplying system, method and program | |
| KR20050100596A (ko) | 컨텐츠 재생 장치, 라이센스 발행 서버 및 컨텐츠 재생시스템 | |
| JP2004363724A (ja) | 受信管理装置、放送受信装置、情報配信装置、情報配信方法およびプログラム | |
| CA2588642C (en) | Method and apparatus for secure transfer and playback of multimedia content | |
| JPH088851A (ja) | 情報配布システムおよび情報配布方法 | |
| JP3688918B2 (ja) | 放送受信装置 | |
| US20070288713A1 (en) | Data Recording/Reproducing Device and Method | |
| JP4199472B2 (ja) | 暗号化を施すことによりデータを保護するデータ保護システム | |
| JP2002044071A (ja) | 受信方法 | |
| JP2000196586A (ja) | トランスポ―トストリ―ム処理装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050118 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050322 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050607 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050609 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090617 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |