JP4580871B2 - パケット送信装置 - Google Patents

Description

本発明は、ＩＥＥＥ８０２．３などのイーサネット（登録商標）（有線ＬＡＮ）やＩＥＥＥ８０２．１１などの無線ＬＡＮなどを用いて、暗号化されたＡＶストリームをＩＰパケット化して高品質に送信するパケット送信装置に関する。

近年の通信技術の発展に伴い、効率よくパケットを伝送する様々な技術が提案されている（例えば、特許文献１参照）。その一つとして、従来、一般家庭において、部屋内でデジタル放送チューナやＤＶＨＳ方式ビデオレコーダー間をＩＥＥＥ １３９４方式デジタルインターフェースで接続し、ＩＥＣ ６１８８３−４で規定されたＭＰＥＧ−ＴＳ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ／Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）信号の伝送が行われている。ここで、放送コンテンツにコピーワンジェネレーション（Ｃｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎ）などコンテンツ保護がかかっている場合、コンテンツを不正コピーから保護するため、コンテンツを暗号化して伝送している。この様にデジタル放送を受信・選局して得られたＭＰＥＧ−ＴＳなどのＡＶデータを暗号化して伝送する方式の一例として、ＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）方式が規定されている。ＤＴＣＰは、ＩＥＥＥ１３９４やＵＳＢなどの伝送メディア上のコンテンツ保護技術である。ＤＴＣＰ方式は、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｃｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）で規格化された方式であり、 ＨＹＰＥＲＬＩＮＫ"ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ" ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ、 ＨＹＰＥＲＬＩＮＫ "ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｄｔｃｐ＃ｔｕｔ．ｐｄｆ" ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｄｔｃｐ＃ｔｕｔ．ｐｄｆ、ＨＹＰＥＲＬＩＮＫ "ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｗｐ＃ｓｐｅｃ．ｐｄｆ" ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｗｐ＃ｓｐｅｃ．ｐｄｆや、書籍「ＩＥＥＥ１３９４、ＡＶ機器への応用」、高田信司監修、日刊工業新聞社、「第８章、コピープロテクション」、１３３〜１４９ページで説明されている。

ＭＰＥＧ−ＴＳについて説明する。トランスポートストリームはトランスポートパケット（ＴＳ ｐａｃｋｅｔ）が複数個集まったものである。ＴＳ ｐａｃｋｅｔは１８８ｂｙｔｅの固定長パケットで、その長さはＡＴＭのセル長との整合性およびリードソロモン符号などの誤り訂正符号化を行なう場合の適用性を考慮して決定されている。ＴＳ ｐａｃｋｅｔは４ｂｙｔｅ固定長のパケットヘッダと可変長のアダプテーションフィールド（ａｄａｐｔａｔｉｏｎ ｆｉｅｌｄ）およびペイロード（ｐａｙｌｏａｄ）で構成される。パケットヘッダにはＰＩＤ（パケット識別子）や各種のフラグが定義されている。このＰＩＤによりＴＳ ｐａｃｋｅｔの種類を識別する。ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄとｐａｙｌｏａｄは、片方のみが存在する場合と両方が存在する場合があり、その有無はパケットヘッダ内のフラグ（ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄ＿ｃｏｎｔｒｏｌ）により識別できる。ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄは、ＰＣＲ（Ｐｒｏｇｒａｍ＿Ｃｌｏｃｋ＿Ｒｅｆｅｒｅｎｃｅ）等の情報伝送およびＴＳ ｐａｃｋｅｔを１８８ｂｙｔｅ固定長にするためのＴＳ ｐａｃｋｅｔ内でのスタッフィング機能を持つ。また、ＰＣＲは２７ＭＨｚのタイムスタンプで、符号化した時の基準時間を復号器のＳＴＣで再現するためにＰＣＲの値が参照される。ＭＰＥＧ−２のＴＳでは復号器のＳＴＣ（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）はＰＣＲによるＰＬＬ同期機能を持つ。このＰＬＬ同期の動作を安定させるためにＰＣＲの送信間隔は最大０．１ｍｓである。映像や音声などの個別ストリームが収められたＭＰＥＧのＰＥＳパケットは同じＰＩＤ番号を持つ複数のＴＳ ｐａｃｋｅｔのｐａｙｌｏａｄに分割して伝送する。また、ＰＥＳパケットの先頭は、ＴＳ ｐａｃｋｅｔの先頭から開始するように構成される。トランスポートストリームは複数のプログラムを伝送することができるため、ストリームに含まれているプログラムとそのプログラムを構成している映像や音声ストリームなどのプログラムの要素との関係を表すテーブル情報が用いられる。このテーブル情報はＰＳＩ（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）と呼ばれ、ＰＡＴ （Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅ）、ＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）などのテーブルを用いる。ＰＡＴ、ＰＭＴなどのＰＳＩはセクションと呼ばれる単位でＴＳ ｐａｃｋｅｔの中のｐａｙｌｏａｄに配置されて伝送される。ＰＡＴにはプログラム番号に対応したＰＭＴのＰＩＤなどが指定されており、ＰＭＴには対応するプログラムに含まれる映像、音声、付加データおよびＰＣＲのＰＩＤが記述されるため、ＰＡＴとＰＭＴを参照することにより、ストリームの中から目的のプログラムを構成するＴＳ ｐａｃｋｅｔだけを取り出すことができる。ＴＳに関する参考文献としては、例えば、ＣＱ出版社、ＴＥＣＨ Ｉ Ｖｏ．４、「画像＆音声圧縮技術のすべて（インターネット／ディジタルテレビ、モバイル通信時代の必須技術）」、監修、藤原洋、第６章、「画像や音声を多重化するＭＰＥＧシステム」があり、同書にて解説されている。

ＰＳＩやＳＩに関する論理的な階層構造、処理手順の例、選局処理の例に関して、「ディジタル放送受信機における選局技術」、三宅他、三洋電機技報、ＶＯＬ．３６、ＪＵＮＥ ２００４、第７４号、３１ページから４４ページにて解説されている。

また、デジタル放送で使用されるアクセス制御方式に関し、スクランブル、関連情報の仕様及びそれに関わる受信機仕様については、ＡＲＩＢ規格、ＡＲＩＢ ＳＴＤ−Ｂ２５において規定されており、その運用については、ＡＲＩＢ技術資料、ＡＲＩＢ ＴＲ−Ｂ１４およびＡＲＩＢ ＴＲ−Ｂ１５において規定されている。

図１（ａ）は、ＤＴＣＰ方式を用いたＭＰＥＧ―ＴＳのＩＥＥＥ１３９４での伝送の一例である。ＤＴＣＰ方式では、送信側（パケット送信機器）をソース１８０１、受信側（パケット受信機器）をシンク１８０２と呼び、暗号化したＭＰＥＧ−ＴＳなどのコンテンツをソース１８０１からネットワーク１８０３を介して、シンク１８０２へ伝送している。図１（ｂ）に、補足情報として、ソース機器およびシンク機器の例を併記する。

図２は、ＤＴＣＰ方式における従来のパケット通信部の概略を説明する図であり、ここでは、図１のソース１８０１が備えるパケット送信部およびシンク１８０２が備えるパケット受信部の両方がパケット送受信部として示されている。まず、ＤＴＣＰ方式に準拠した認証と鍵交換（Ａｕｔｈｅｎｔｉｆｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ、ＡＫＥと略する）が行なわれる。ＡＫＥ部１９０１に対して、その認証と鍵交換の設定情報が入力され、この情報がパケット化部１９０２に伝達され、パケット化部１９０２において規定のヘッダが付加されたパケット化が行われ、ネットワーク１９０７に出力される。ここで、パケット化部１９０２は、送信条件設定部１９０３により決定された送信パラメータにより、入力データのパケット化および送信を行なう。受信側では、ネットワーク１９０７より入力する信号がパケット受信部１９０４でパケットヘッダなどの識別によりフィルタリングされ、ＡＫＥ部１９０１に入力される。これにより送信側（ソース）のＡＫＥ部と、受信側（シンク）のＡＫＥ部がネットワーク１８０３および１９０７を介してお互いにメッセージの通信ができる。すなわち、ＤＴＣＰ方式の手順に従い、認証と鍵交換を実行する。

送信側（ソース）と、受信側（シンク）で認証と鍵交換が成立すれば、次に、ＡＶデータの伝送を行なう。ソースでは、ＭＰＥＧ−ＴＳ信号を暗号化部１９０５に入力して、ＭＰＥＧ−ＴＳ信号を暗号化した後、この暗号化されたＭＰＥＧ−ＴＳ信号をパケット化部１９０２に入力し、ネットワーク１９０７に出力する。シンクでは、ネットワーク１９０７より入力する信号がパケット受信部１９０４でパケットヘッダなどの識別によりフィルタリングされ、復号部１９０６に入力され、復号されＭＰＥＧ−ＴＳ信号が出力される。

次に、図３を用いて上記手順を補足説明する。図３において、ソースとシンク間はＩＥＥＥ１３９４で接続されている。まず、ソース側でコンテンツの送信要求が発生する。そして、ソースからシンクへ暗号化されたコンテンツおよびコンテンツの保護モード情報が送信される。シンクは、コンテンツのコピー保護情報の解析を行い、完全認証もしくは制限付き認証のどちらの認証方式を用いるかを決定し、認証要求をソースに送る。ソースとシンクはＤＴＣＰ所定の処理により認証鍵の共有を図る。そして、ソースは認証鍵を用いて交換鍵を暗号化してシンクに送り、シンクで交換鍵が復号される。ソースでは暗号鍵を時間的に変化させるために、時間的に変化するシード情報を生成し、シンクに送信する。ソースでは、交換鍵とシード情報より暗号化鍵を生成して、ＭＰＥＧ−ＴＳをこの暗号化鍵を用いて暗号化部で暗号化してシンクに送信する。シンクはシード情報を受信し交換鍵とシード情報より復号鍵を復元する。シンクではこの復号鍵を用いて暗号化されたＭＰＥＧ−ＴＳ信号を復号する。

図４は、図１においてＭＰＥＧ−ＴＳ信号を伝送する場合のＩＥＥＥ１３９４アイソクロナスパケットの一例である。このパケットは、４バイト（３２ビット）のヘッダ、４バイト（３２ビット）のヘッダＣＲＣ、２２４バイトのデータフィールド、４バイト（３２ニット）のトレイラによって構成されている。暗号化されて伝送されるのは２２４バイトのデータフィールドを構成するＣＩＰヘッダとＴＳ信号のうち、ＴＳ信号のみで、他のデータは暗号化されない。ここで、ＤＴＣＰ方式固有の情報は、コピー保護情報である２ビットのＥＭＩ（Ｅｎｃｒｉｐｔｉｏｎ Ｍｏｄｅ Ｉｎｄｉｃａｔｏｒ）、およびシード情報のＬＳＢビットであるＯ／Ｅ（Ｏｄｄ／Ｅｖｅｎ）であり、これらは上記３２ビットのヘッダ内に存在するため暗号化されずに伝送される。

しかしながら、上記従来の技術では、以下のような問題点を有している。従来のＤＴＣＰ方式はＩＥＥＥ１３９４において、アイソクロナスパケットを用いて伝送するためＭＰＥＧ−ＴＳ信号のリアルタイム伝送ができるが、インターネットの標準プロトコルであるＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ）を用いて、イーサネット（登録商標）（ＩＥＥＥ８０２．３）、無線ＬＡＮ（ＩＥＥＥ８０２．１１）や、その他のＩＰパケットを伝送可能なネットワークで伝送ができないという大きな問題点がある。

すなわち、ＩＰを介して論理的に接続されたパケット送信機器とパケット受信機器の間を、地上波／ＢＳデジタル放送やサーバ型放送などデジタル著作権保護対応のコンテンツを著作権保護しつつ伝送できないという大きな問題点がある。

また、ライブ放送の伝送において、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を用いる場合、ＨＴＴＰリクエストの度に、前記暗号化に関して付加するヘッダ長や伝送コンテンツ長を受信側で計算する必要があり、受信側の処理が重いという課題がある。

さらに、ハードディスクなどに蓄積されたコンテンツを早送り、巻き戻し、スロー再生などの特殊再生を簡単に実現することが困難であるという問題点がある。

さらに、ハードディスクや光ディスクなどに蓄積された異なる蓄積フォーマットのコンテンツを共通の方法で簡単に、早送り、巻き戻し、スロー再生などの特殊再生することが困難であるという問題点がある。なお、ネットワーク経由ではなくローカル（機器本体）での操作に関しては、一例として、Ｂｌｕ−ｒａｙディスク方式の本体（）での特殊再生などに関して、松下テクニカルジャーナル、２００４年１０月、３４ページから３８ページ、「Ｂｒｕ−ｒａｙ Ｄｉｓｋ Ｒｅｗｒｉｔａｂｌｅ Ｆｏｒｍａｔ（２） 〜論理規格、著作権保護規格〜」において特殊再生のためのＥＰ＿ｍａｐデータ構造などが解説されている。

特に、家庭内においては、放送等によって取得したデジタル著作権保護対応のコンテンツをデジタルＴＶやホームサーバ等が家庭内に設置された様々な機器に配信する必要がある。したがって、家庭内においては、コンテンツの著作権を保護しつつ、様々なメーカーの機器間でのコンテンツ転送を可能にするために、広く普及したＩＰパケットでＤＴＣＰ方式に対応したコンテンツの配信、つまり、ＤＴＣＰ−ＩＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔｓ Ｐｒｏｔｅｃｔｉｏｎ ｏｖｅｒ ＩＰ）を実現する必要がある。
特開２０００−５９４６３号公報

そこで、本発明は、ＤＴＣＰ等のコンテンツ保護技術で保護されたコンテンツをＨＴＴＰプロトコルやＲＴＰプロトコルなどを利用してＩＰパケット等の広く普及したパケットで送信することが可能なパケット送信装置を提供することを目的とする。

上記目的を達成するために、本発明に係るパケット送信装置は、パケット受信装置にパケットデータを送信するパケット送信装置であって、ＡＶデータが入力される端子を示す入力端子情報、前記ＡＶデータのデータフォーマットを示すデータフォーマット情報及び前記ＡＶデータの属性を示す属性情報を含むＡＶデータ情報を取得するＡＶデータ情報取得手段と、前記ＡＶデータ及び非ＡＶデータの入力を受け付けるデータ入力手段と、前記非ＡＶデータまたは前記ＡＶデータより、前記ＡＶデータの課金情報、再生制御情報及びコピー制御情報の少なくとも１つの情報を抽出し、抽出した情報から、前記ＡＶデータを送信する際の条件となる暗号化モードを示す暗号化モード情報を生成する送信条件設定管理手段と、前記入力端子情報、前記データフォーマット情報及び前記属性情報を組み合わせて決定される送信条件に基づいて、前記データ入力手段より入力された前記ＡＶデータを暗号化し、暗号化された前記ＡＶデータに対して前記暗号化モード情報に基づく暗号化情報ヘッダを付加することによって暗号化データを生成する暗号化データ生成手段と、前記暗号化データ生成手段により生成された暗号化データに対して、パケットヘッダを付加
することによってパケットを生成するパケット化手段と、前記パケット受信装置との間で認証処理を行う認証手段と、前記入力端子情報、前記属性情報及び前記パケット受信装置より指定される送信モードを示す情報の少なくとも１つを用いて、前記パケット送信装置と前記パケット受信装置の間での前記ＡＶデータの伝送プロトコルを決定する伝送プロトコル決定手段と、前記認証手段によって前記パケット受信装置との認証処理が完了した後に、前記伝送プロトコル決定手段によって決定された伝送プロトコルに従って、前記パケット化手段によって生成された、暗号化データを含むパケットを前記パケット受信装置に伝送する伝送手段とを備えることを特徴とする。

より具体的には、本願第１の発明は、ＡＶデータと非ＡＶデータとをそれぞれ入力するデータ入力手段と、前記データ入力手段の出力を入力し、規定の送受信条件により「暗号化または暗号化情報ヘッダ付加の実行を行う」暗号化データ生成手段と、パケットヘッダ付加手段とを具備するパケット送受信手段において、前記暗号化データ生成手段は認証手段と暗号化手段と暗号化情報ヘッダ付加手段を具備し、前記規定の送受信条件により前記暗号化手段において暗号化を実行するかしないか、および、前記暗号化情報ヘッダ付加手段において暗号化情報ヘッダ付加を行うか行わないかを制御する手段とを具備する。これにより、ＭＰＥＧ−ＴＳ信号などのＡＶストリームを外部から与えられる一定規則による送信条件に従い暗号化モードを決め、さらに暗号化情報ヘッダを付加することを決めることにより、パケット送受信機器間での信号の互換性を確保しながら、ＨＴＴＰプロトコルやＲＴＰプロトコルなどを利用しながらＡＶストリームの秘匿性を保つことが可能となる。

本願第２の発明は、第１の発明における認証手段において、認証を実行するモードは、外部より入力される制御情報により決定する。たとえば、外部より入力される制御情報として、コンテンツ毎にアクセス位置を指定するＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を与え、そのＵＲＩの形式により認証モードを決定する。たとえば、ＵＲＩがＱｕｅｒｙにより拡張されている場合は、認証が必要であり、そのＱｕｅｒｙ情報より認証用のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ポート番号を与えることが可能となる。これにより、認証実行モードを、外部より入力される制御情報により決定することが可能となる。

本願第３の発明は、第１の発明における暗号化データ生成手段において、外部から与えられる規定の送信条件としてそのＡＶストリームのコピー制御情報（ＣＣＩ；Ｃｏｐｙ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）に従うことを特徴とし、暗号化モードと暗号化情報ヘッダ付加を決定する。これにより、ＭＰＥＧ−ＴＳ信号などのＡＶストリームをそのコピー制御情報に従い暗号化モードを決め、暗号化情報ヘッダを付加した後、パケット化して伝送するので、ＡＶコンテンツの著作権者が設定したコピー制御モードを継承してパケットの伝送がなされる。すなわち、一定規則による処理を行うため、ＡＶコンテンツの著作権保護を図りつつ、パケット送受信機器間での信号の互換性を確保することが可能となる。

本願第４の発明は、第１の発明において、ＡＶデータと非ＡＶデータとをそれぞれのデータバッファに入力し、２つのバッファの出力は優先制御して前記パケットヘッダ付加手段に出力する。たとえば、非ＡＶデータがそのデータバッファでオーバーフローしない様に制御しながら、ＡＶデータをそのデータバッファから優先して出力する。これにより、ＡＶデータと非ＡＶデータの内、重要性の高いデータを優先して送信することが可能となる。

本願第５の発明は、第１の発明において、ＡＶデータを構成するデータブロックにタイムスタンプを付加し、１つ以上のタイムスタンプ付データブロックをまとめてＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）パケットのペイロード部またはＨＴＴＰパケットのペイロード部にマッピングする。たとえば、ＡＶデータがＭＰＥＧ−ＴＳの場合、各ＴＳパケットにタイムスタンプを付加し、複数のタイムスタンプ付ＴＳパケットをまとめてＲＴＰまたはＨＴＴＰ上にマッピングする。たとえば、各ＴＳパケットに付加するタイムスタンプのクロックはＭＰＥＧのシステムクロック周波数を用いることができる。ＴＳパケットに付加されたタイムスタンプより、ＭＰＥＧ−ＴＳのネットワーク伝送によりＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）に付加した伝送ジッターを除去して、受信側でのＭＰＥＧシステムクロックの再生を行うことが可能となる。

本願第６の発明は、第１の発明において、ＡＶデータのパケット化は、受信側からの制御により、ＲＴＰまたはＨＴＴＰで行うことを切替え制御すること。たとえば、ＡＶデータのパケット化は、受信側のＡＶデータ出力がディスプレイ充てに出力される場合は遅延の小さいＲＴＰを用い、受信側のＡＶデータ出力が記録メディアに蓄積される場合は再送によりパケット落ちを低減するＨＴＴＰを用いる。このように、切替え制御することにより受信側でディスプレイに出力する場合は低遅延でのＡＶコンテンツの伝送が可能となり、また、受信側で蓄積する場合はパケットロスによる信号欠落が補償された高品質なＡＶコンテンツの伝送が可能となる。

また、本願第７の発明は、課金処理などを含むＲＭＰ（Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ ＆ Ｐｒｏｔｅｃｔｉｏｎ）などのデジタル著作権対応のＡＶデータおよび非ＡＶデータとをそれぞれ入力するデータ入力手段と、前記データ入力手段の出力を入力し、入力されるデジタル著作権規定より暗号化伝送モードを選択できる手段を具備する。すなわち、「暗号化または暗号化情報ヘッダ付加の実行を行う」暗号化データ生成手段と、パケットヘッダ付加手段とを具備するパケット送受信手段において、前記暗号化データ生成手段は認証手段と暗号化手段と暗号化情報ヘッダ付加手段を具備し、前記規定の送受信条件により前記暗号化手段において暗号化を実行するかしないか、および、前記暗号化情報ヘッダ付加手段において暗号化情報ヘッダ付加を行うか行わないかを制御する手段とを具備する。

これにより、課金処理などを含むＲＭＰ情報などデジタル著作権対応のＭＰＥＧ−ＴＳ信号などのＡＶストリームを外部から与えられる一定規則による送信条件に従い暗号化モードを決め、さらに暗号化情報ヘッダを付加することを決めることにより、パケット送受信機器間での信号の互換性を確保しながら、ＡＶストリームの秘匿性を保つことが可能となる。

本願第８の発明は、第７の発明において、ライブで放送されているコンテンツをＨＴＴＰのチャンク伝送方式で伝送することにより、前記暗号化に関して付加するヘッダ長や伝送コンテンツ長ＨＴＴＰリクエストの度に、受信側（クライアント）で計算する必要がなくなり、受信側の処理を軽くすることができる。

本願第９の発明は、第７の発明において、ハードディスクなどに蓄積されたコンテンツをＨＴＴＰのレンジリクエストを用いて伝送することにより、早送り、巻き戻し、スロー再生などの特殊再生を簡単に実現することができる。

さらに、本願第１０の発明は、第９の発明において、ハードディスクや光ディスクなどに蓄積された異なる蓄積フォーマットのコンテンツの異なるＩ、Ｐ、Ｂピクチャのバイト位置情報、時刻情報より、共通フォーマットとしてのＩ、Ｐ、Ｂピクチャフレーム位置情報を生成することにより、高品質なスロー再生、早送り、巻き戻しなどの特殊再生を容易に実現することが可能となる。

なお、本発明は、このようなパケット送信装置として実現できるだけでなく、パケット送信方法として実現したり、パケット送信装置のためのプログラムとして実現したり、そのプログラムを記録したコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体としても実現できる。

本願第１の発明によれば、外部から与えられる一定規則によりＡＶコンテンツの送信の暗号化モードを決めることができる。さらに、暗号化情報ヘッダを付加ルールを決めることができるため、パケット送受信機器間でのＡＶストリームの秘匿性を保ちながら信号の互換性を確保することが可能となる。

本願第２の発明によれば、第１の発明における認証手段において、認証実行モードを外部入力の制御情報より決定する。たとえば、外部より入力される制御情報として、コンテンツ毎にアクセス位置を指定するＵＲＩを与え、そのＵＲＩの形式により認証モードを決定することができる。一例として、ＵＲＩがＱｕｅｒｙ形式により拡張されている場合には認証が必要という情報と、同時に、そのＱｕｅｒｙ情報より認証用のＴＣＰポート番号の情報を与えることが可能となる。これにより、認証実行モードを、外部より入力される制御情報により決定することが可能となる。

本願第３の発明によれば、第１の発明における暗号化データ生成手段において、外部から与えられる規定の送信条件としてそのＡＶストリームのコピー制御情報に従うことを特徴とし、暗号化モードと暗号化情報ヘッダ付加を決定する。これにより、ＭＰＥＧ−ＴＳ信号などのＡＶストリームをそのコピー制御情報に従い暗号化モードを決め、暗号化情報ヘッダを付加した後、パケット化して伝送するので、ＡＶコンテンツの著作権者が設定したコピー制御モードを継承してパケットの伝送がなされる。すなわち、一定規則による処理を行うため、ＡＶコンテンツの著作権保護を図りつつ、パケット送受信機器間での信号の互換性を確保することが可能となる。

本願第４の発明によれば、第１の発明において、ＡＶデータと非ＡＶデータとをそれぞれのデータバッファに入力し、２つのバッファの出力は優先制御して前記パケットヘッダ付加手段に出力する。たとえば、非ＡＶデータがそのデータバッファでオーバーフローしない様に制御しながら、ＡＶデータをそのデータバッファから優先して出力する。これにより、ＡＶデータと非ＡＶデータの内、重要性の高いデータを優先して送信することが可能となる。

本願第５の発明によれば、第１の発明において、ＡＶデータを構成するデータブロックにタイムスタンプを付加し、１つ以上のタイムスタンプ付データブロックをまとめてＲＴＰパケットのペイロード部またはＨＴＴＰパケットのペイロード部にマッピングする。たとえば、ＡＶデータがＭＰＥＧ−ＴＳの場合、各ＴＳパケットにタイムスタンプを付加し、複数のタイムスタンプ付ＴＳパケットをまとめてＲＴＰまたはＨＴＴＰ上にマッピングする。たとえば、各ＴＳパケットに付加するタイムスタンプのクロックはＭＰＥＧのシステムクロック周波数を用いることができる。ＴＳパケットに付加されたタイムスタンプより、ＭＰＥＧ−ＴＳのネットワーク伝送によりＰＣＲに付加した伝送ジッターを除去して、受信側でのＭＰＥＧシステムクロックの再生を行うことが可能となる。

本願第６の発明によれば、第１の発明において、ＡＶデータのパケット化は、受信側からの制御により、ＲＴＰまたはＨＴＴＰで行うことを切替え制御すること。たとえば、ＡＶデータのパケット化は、受信側のＡＶデータ出力がディスプレイ充てに出力される場合は遅延の小さいＲＴＰを用い、受信側のＡＶデータ出力が記録メディアに蓄積される場合は再送によりパケット落ちを低減するＨＴＴＰを用いる。このように、切替え制御することにより受信側でディスプレイに出力する場合は低遅延でのＡＶコンテンツの伝送が可能となり、また、受信側で蓄積する場合はパケットロスによる信号欠落が補償された高品質なＡＶコンテンツの伝送が可能となる。

また、上記発明によれば、ネットワークを用いたＡＶコンテンツの伝送に関して、ネットワーク上でのデータ盗聴を防止し、安全性の高いデータ伝送を実現する。これにより、伝送路にインターネットなど公衆網を使用した場合においても、リアルタイム伝送される優先データ（ＡＶデータコンテンツ）の盗聴、漏洩を防止することができる。また、インターネット等で伝送されるＡＶデータの販売、課金が可能となり、安全性の高いＢ−Ｂ（Ｂｕｓｉｎｅｓｓ ｔｏ Ｂｕｓｉｎｅｓｓ）、Ｂ−Ｃ（Ｂｕｓｉｎｅｓｓ ｔｏ Ｃｏｎｓｕｍｅｒ）のコンテンツ販売流通が可能となる。

また、上記発明によれば、ＡＶコンテンツをハードウェアで伝送処理する場合にも、一般のデータパケットは従来通りＣＰＵを用いてソフトウェア処理を行える。よって、ソフトウェアの追加により管理情報や制御情報などデータを一般データとして伝送させることができる。これらのデータ量は優先データであるＡＶデータに比べて非常に少ないので、マイコンなど安価なマイクロプロセッサで実現可能となり低コストなシステムを実現することができる。なお、高負荷かつ高伝送レート優先パケットのプロトコル処理にも高価なＣＰＵや大規模メモリを必要としないので、これらの点からも低コストで高機能な装置を提供できる。

また、本願第７の発明によれば、地上波放送、衛星放送、ＣＡＴＶやインターネット経由で受信するデジタル放送信号より検出、抽出できるＡＶコンテンツの属性情報を送信端末と受信端末間でＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）−ＡＶやＨＴＴＰなどのデータ交換プロトコルを用いて伝送することにより、送信端末と受信端末間でのＡＶコンテンツを送信する場合の暗号化モード、コンテンツ属性情報の伝送方法を決めることができる。さらに、暗号化情報ヘッダの付加ルールを決められるため、パケット送受信機器間でのＡＶストリームの秘匿性を保ちながら信号の互換性を確保することが可能となる。ＵＰｎＰやＵＰｎＰ−ＡＶの標準仕様は、ｈｔｔｐ：／／ｕｐｎｐ．ｏｒｇで公開されている。ｈｔｔｐ：／／ｕｐｎｐ．ｏｒｇにおいて、例えば、「ＭｅｄｉａＳｅｒｖｅｒ Ｖ １．０ ａｎｄ ＭｅｄｉａＲｅｎｄｅｒｅｒ Ｖ １．０」に関して、「ＭｅｄｉａＳｅｒｖｅｒ Ｖ １．０」、「ＭｅｄｉａＲｅｎｄｅｒｅｒ Ｖ １．０」、「ＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ Ｖ １．０」、「ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙ Ｖ １．０」、「ＲｅｎｄｅｒｉｎｇＣｏｎｔｒｏｌ Ｖ １．０」、「ＡＶＴｒａｎｓｐｏｒｔ Ｖ １．０」、「ＵＰｎＰ（登録商標） ＡＶ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｖ ．８３」などの仕様書が公開されている。

また、ネットワークを用いたＡＶコンテンツの伝送に関して、ネットワーク上でのデータ盗聴を防止し、安全性の高いデータ伝送を実現する。これにより、伝送路にインターネットなど公衆網を使用した場合においても、リアルタイム伝送される優先データ（ＡＶデータコンテンツ）の盗聴、漏洩を防止することができる。また、インターネット等で伝送されるＡＶデータの販売、課金が可能となり、安全性の高いＢ−Ｂ、Ｂ−Ｃのコンテンツ販売流通が可能となる。

また、ＡＶコンテンツをハードウェアで伝送処理する場合にも、一般のデータパケットは従来通りＣＰＵを用いてソフトウェア処理を行える。よって、ソフトウェアの追加により管理情報や制御情報などデータを一般データとして伝送させることができる。これらのデータ量は優先データであるＡＶデータに比べて非常に少ないので、マイコンなど安価なマイクロプロセッサで実現可能となり低コストなシステムを実現することができる。なお、高負荷かつ高伝送レート優先パケットのプロトコル処理にも高価なＣＰＵや大規模メモリを必要としないので、これらの点からも低コストで高機能な装置を提供できる。

また、サーバ型放送のＲＭＰで用いる課金情報などを含むＲＭＰＩ（Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ ＆ Ｐｒｏｔｅｃｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ）で視聴あるいはコピー制限されたコンテンツをＲＭＰに対応していないクライアントにＣＮＭ（Ｃｏｐｙ Ｎｏ Ｍｏｒｅ）やＣＮ（Ｃｏｐｙ Ｎｅｖｅｒ）で見せることができ、サーバ型放送の普及を加速することができる。

本願第８の発明によれば、ライブで放送されているコンテンツをＨＴＴＰのチャンク伝送方式で伝送することにより、前記暗号化に関して付加するヘッダ長や伝送コンテンツ長ＨＴＴＰリクエストの度に、受信側（クライアント）で計算する必要がなくなり、受信側の処理を軽くできる。

本願第９の発明によれば、ハードディスクなどに蓄積されたコンテンツをＨＴＴＰのレンジリクエストを用いて伝送することにより、早送り、巻き戻し、スロー再生などの特殊再生を簡単に実現できる。

さらに、本願第１０の発明は、第９の発明において、ハードディスクや光ディスクなどに蓄積された異なる蓄積フォーマットのコンテンツの異なるＩフレーム位置情報より、共通のＩフレーム位置情報を生成することにより、簡単に、早送り、巻き戻し、スロー再生などの特殊再生が実現される。

以下、本発明の実施の形態について、図面を用いて詳細に説明する。
最初に本発明の位置付けを明確にするために適用される通信システム例の概略について説明する。

図５は本発明を適用する通信システムの一例である。この通信システムは、パケットを送信するパケット送信機器１０１と、パケットのルーティングを行うルータ１０２と、パケットを受信するパケット受信機器１０３とから構成される。パケット送信機器１０１およびパケット受信機器１０３は、本発明に係る装置である。パケット送信機器１０１には、送受信条件の設定情報、認証と鍵交換の設定情報、入力ストリーム（ＭＰＥＧ−ＴＳなどコンテンツ）が入力され、図６に示されるように、以下の手順１から３に基づき、ルータ１０２との間で通信を行う。

＜手順１＞送受信パラメータの設定を行なう。
（手順１−１）パケット送受信機器のＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス、ＩＰアドレス、ＴＣＰ／ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）ポート番号等を設定。
（手順１−２）送信信号の種別、帯域を設定。ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）エージェントとして動作するパケット送信機器１０１とパケット受信機器１０３、ＱｏＳマネージャとして動作するルータ１０２との間でＩＥＥＥ８０２．１Ｑ（ＶＬＡＮ；Ｖｉｒｔｕａｌ ＬＡＮ）規格を用いたネットワークの運用に関する設定を実施。
（手順１−３）優先度の設定（ＩＥＥＥ８０２．１Ｑ／ｐによる運用）

＜手順２＞認証と鍵交換：
（手順２−１）認証と鍵交換を行なう。たとえば、ＤＴＣＰ方式を用いることもできる。

＜手順３＞ストリーム伝送：
（手順３−１）パケット送信機器とパケット受信機器間での暗号化されたストリームコンテンツ（ＭＰＥＧ−ＴＳ）を伝送する。

なお、コンテンツの入力信号としてＭＰＥＧ１／２／４などにおけるＭＰＥＧ−ＴＳ，ＭＰＥＧ−ＰＳ（Ｐｒｏｇｒａｍ Ｓｔｒｅａｍ）、ＭＰＥＧ−ＥＳ（Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）、ＭＰＥＧ−ＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ Ｅｌｅｍｅｎｔａｒｔｙ Ｓｔｒｅａｍ）などがある。

ここでは、例ではＭＰＥＧ−ＴＳを使用しているが、これに限らず本発明で用いる入力コンテンツの適用範囲としては、ＭＰＥＧ１／２／４などＭＰＥＧ−ＴＳストリーム（ＩＳＯ／ＩＥＣ１３８１８）、ＤＶ（ＩＥＣ６１８３４、ＩＥＣ６１８８３）、ＳＭＰＴＥ（Ｓｏｃｉｅｔｙ ｏｆ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ ＆ Ｔｅｌｅｖｉｓｉｏｎ Ｅｎｇｉｎｅｅｒｓ） ３１４Ｍ（ＤＶ−ｂａｓｅｄ）、ＳＭＰＴＥ２５９Ｍ（ＳＤＩ）、ＳＭＰＴＥ３０５Ｍ（ＳＤＴＩ）、ＳＭＰＴＥ２９２Ｍ（ＨＤ−ＳＤＩ）、ＩＳＯ／ＩＥＣ Ｈ．２６４等で規格化されているストリ−ム、さらには、一般的なＡＶコンテンツも適用可能である。

さらに、本発明で用いる入力データの適用範囲として、データのファイル転送にも適用可能である。ファイル転送の場合、送受信端末の処理能力と送受信端末間の伝播遅延時間の関係により、データ転送速度がコンテンツストリームの通常再生データレートよりも大きくなるなどの条件化において、リアルタイムより高速のコンテンツ伝送も可能である。

次に、上記手順２の認証と鍵交換に関して補足説明する。図７において、パケット送信機器１０１とパケット受信機器１０３間はＩＰネットワークにより接続されている。まず、パケット送信機器１０１からパケット受信機器１０３へコンテンツのコピー保護情報を含んだコンテンツの保護モード情報が送信される。

パケット受信機器１０３は、コンテンツのコピー保護情報の解析を行い、使用する認証方式を決定して認証要求をパケット送信機器１０１に送る。

これらの処理を通してパケット送信機器１０１とパケット受信機器１０３は認証鍵を共有する。

次に、パケット送信機器１０１は認証鍵を用いて交換鍵を暗号化してパケット受信機器１０３に送り、パケット受信機器１０３で交換鍵が復号される。

パケット送信機器１０１では暗号鍵を時間的に変化させるために、時間的に変化する鍵変更情報を生成し、パケット受信機器１０３に送信する。

パケット送信機器１０１では、交換鍵と鍵変更情報より暗号化鍵を生成して、ＭＰＥＧ−ＴＳをこの暗号化鍵を用いて暗号化部で暗号化してパケット受信機器１０３に送信する。

パケット受信機器１０３は受信した鍵変更情報を交換鍵より復号鍵を復元する。パケット受信機器１０３ではこの復号鍵を用いて暗号化されたＭＰＥＧ−ＴＳ信号を復号する。

図８は、本方式をイーサネット（登録商標）によるＬＡＮを備える２階建ての家庭に適用した場合の一例である。この家庭は、１階に設置されたルータ３０３を含むネットワークシステム３０１と、２階に設置されたスイッチングハブ３０４を含むネットワークシステム３０２を備える。ネットワーク３０５は、ルータ３０３とスイッチングハブ３０４を接続するイーサネット（登録商標）ネットワークである。家庭内の全てのイーサネット（登録商標）ネットワークの帯域は１００Ｍｂｐｓである。

１階の１階のネットワークシステム３０１の構成として、ルータ３０３には、テレビ（ＴＶ）、パソコン（ＰＣ）、ＤＶＤレコーダが１００Ｍｂｐｓのイ−サネットで接続され、また、エアコン、冷蔵庫がＥＣＨＯＮＥＴで接続されている。

また、２階では、スイッチングハブ３０４にテレビ（ＴＶ）、パソコン（ＰＣ）、ＤＶＤレコーダが１００Ｍｂｐｓのイ−サネットで接続され、また、エアコンがＥＣＨＯＮＥＴで接続されている。なお、ＥＣＨＯＮＥＴは「エコーネットコンソーシアム」（ＨＹＰＥＲＬＩＮＫ "ｈｔｔｐ：／／ｗｗｗ．ｅｃｈｏｎｅｔ．ｇｒ．ｊｐ／" ｈｔｔｐ：／／ｗｗｗ．ｅｃｈｏｎｅｔ．ｇｒ．ｊｐ／）で開発されている伝送方式である。

なお、この家庭において、例えば、デジタル著作権保護の対象となるコンテンツを放送で受信し、家庭内の各機器（エアコン、ＤＶＤ、ＰＣ、冷蔵庫）にＩＰパケットで配信するＴＶが本発明のパケット送信機器１０１に相当し、各機器がパケット受信機器１０３に相当する。

図８において、パソコン（ＰＣ）、ＤＶＤレコーダ、ルータ３０３およびスイッチングハブ３０４は、ＩＥＥＥ８０２．１Ｑ（ＶＬＡＮ）に対応している。すなわち、ルータ３０３およびスイッチングハブ３０４において、各ポートのデータレートが全て同じ（例えば１００Ｍｂｐｓ）場合、特定ポートへ出力されるデータ帯域の合計がそのポートの伝送レートの規格値または実力値を超えない限り、入力ポートへ入力されたデータはルータ（あるいは、スイッチングハブ）内部で失われず全て出力ポートに出力される。

スイッチングハブでは、たとえば８個の入力ポートにデータが同時に入力されても、それぞれのデータの出力ポートが異なっていれば、それぞれのデータはハブ内部のバッファで競合しないでスイッチングされて出力ポートより出力されるため、入力データはパケット落ちすることなく全て出力ポートに出力される。

図８において、家庭内の全てのイーサネット（登録商標）の帯域が１００Ｍｂｐｓであるため、１階と２階間のネットワーク３０５の帯域も１００Ｍｂｐｓである。１階と２階の複数の機器間で複数のデータが流れる場合、各データに対する帯域制限がない場合、このネットワーク３０５上を流れるデータのデータレート合計が１００Ｍｂｐｓを超える可能性があり、ＭＰＥＧ−ＴＳの映像アプリなどリアルタイム伝送が必要なストリームが途切れる可能性がある。この場合、リアルタイム伝送が必要なストリームが途切れない様にするには、伝送データに対して優先制御が必要である。

このような問題は、端末だけでなく、ルータやスイッチングハブにおいて、後述するストリーム伝送やファイル転送の速度制限機構などを導入することにより解決できる。

たとえば、ＭＰＥＧ−ＴＳストリームの伝送優先度をファイル転送データの伝送優先度よりも高くすると、１階と２階のＰＣ間でのファイル転送をバックグラウンドで行いながら、同時に、１階および２階のＤＶＤレコーダ、ＰＣ，ＴＶの間でＭＰＥＧ−ＴＳを暗号化して、ＨＴＴＰプロトコルやＲＴＰプロトコルなどを利用してリアルタイムで伝送することが可能となる。

なお、ＨＴＴＰプロトコル（ＩＥＴＦ規格、ＲＦＣ２６１６、ＲＦＣ１９４５）の概要、構成、動作に関しては、たとえば、「連載：インターネット・プロトコル詳説（１）、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）〜前編」、ＷＥＢ資料、ｈｔｔｐ：／／ｗｗｗ．ａｔｍａｒｋｉｔ．ｃｏ．ｊｐ／ｆｎｅｔｗｏｒｋ／ｒｅｎｓａｉ／ｎｅｔｐｒｏ０１／ｎｅｔｐｒｏ０１．ｈｔｍｌで解説されている。

前述したルータ３０３、またはスイッチングハブ３０４における伝送速度制限機構は、データ流入制御により実現できる。すなわち、ルータ（あるいは、スイッチングハブ）の入力データキューにおいて優先度の高いデータと低いデータを比較して、優先度の高いデータを優先して出力することにより実現できる。この優先制御方式に用いるバッファ制御ルールとしては、ラウンドロビン方式、流体フェアスケジューリング方式、重み付けフェアスケジューリング方式自己同期フェアスケジューリング方式ＷＦＦＱ方式、仮想時計スケジューリング方式、クラス別スケジューリング方式などがある。これらのスケジューリング方式に関する情報は、戸田巌著、「ネットワークＱｏＳ技術」、平成１３年５月２５日（第１版）、オーム社刊の第１２章などに記述されている。

（実施の形態１）
まず、本発明の実施の形態１について説明する。図９は、本実施の形態におけるパケット送受信部４０１の構成を示すブロック図である。このパケット送受信部４０１は、図５に示されたパケット送信機器１０１が備えるパケット送信部とルータ１０２が備えるパケット受信部とを同時に示した仮想的な機能ブロックであるし、パケットの送受信機能を備える１台のパケット送受信部を示す機能ブロック図でもあり得る（以下、全ての実施の形態におけるパケット送受信部について同じ）。

このパケット送受信部４０１は、ＡＫＥを用いた暗号化によるパケット送受信を行う装置であり、ＡＫＥ部４０２、パケット化部４０３、送信条件設定管理部４０４、パケット受信部４０５、暗号化データ生成部４０６、暗号化データ復号部４０７、受信条件設定管理部４０８、フレーム化部４０９およびフレーム受信部４１０を備える。以下、伝送手順に従って、各構成要素の機能を説明する。

送信条件設定管理部４０４は、ＡＶデータ（送信データ）が入力される端子を示す入力端子情報、ＡＶデータのデータフォーマットを示すデータフォーマット情報及びＡＶデータの属性を示す属性情報を含むＡＶデータ情報、具体的には、送信データの種別、送信先アドレスやポート番号の情報、送信に用いるパス情報（ルーティング情報）、送信データの帯域、送信データの送信優先度などの送信条件の設定情報と、送信部（ローカル）と受信部（リモート）における機器の管理制御データと、受信状況を送信側にフィードバックするためのデータを取得し、パケット化部４０３やフレーム化部４０９におけるヘッダやペイロードデータなどの生成を制御（パラメータの設定等を）する。

なお、パケット送受信部４０１におけるＡＶデータ（送信データ）が入力される端子を示す入力端子情報とは、例えば取り扱う信号がＡＶデータがＭＰＥＧ−ＴＳ信号の場合、（１）デジタル放送の入力端子（日本の場合、地上デジタル放送、ＢＳデジタル放送、１１０度広帯域ＣＳデジタル放送に対応するＲＦ入力端子がある）、（２）ＩＥＥＥ１３９４ Ｄ−Ｉ／Ｆ、（３）ＵＳＢ−Ｉ／Ｆ、（４）ＩＰ−Ｉ／Ｆ（Ｅｔｈｅｒｎｅｔ（登録商標）や無線ＬＡＮの区別）、（５）アナログ映像音声入力（この場合は、パケット送受信部４０１内で入力されたアナログ映像音声をＭＰＥＧ−ＴＳ信号に変換する）などがある。なお、デジタル放送に関しては、映像情報メディア学会誌、Ｖｏｌ．５８、Ｎｏ．５、ｐｐ．６０４〜ｐｐ．６５４において解説記事がある。

また、パケット送受信部４０１におけるＡＶデータのデータフォーマットを示すデータフォーマット情報とは、例えば取り扱う信号がＡＶデータがＭＰＥＧ−ＴＳ信号の場合、ＭＰＥＧ−ＴＳのＭＩＭＥ−Ｔｙｐｅやメディアフォーマットを表わす。たとえば、送信手段（サーバ）や受信手段（クライアント）が取り扱う静止画メディア、音楽メディア、動画メディアに対して、それぞれのメディアフォーマットを定める。静止画のメディアフォーマットとしては、ＪＰＥＧ、ＰＮＧ、ＧＩＦ、ＴＩＦＦなどがある。また、音楽のメディアフォーマットとしては、リニアＰＣＭ、ＡＡＣ、ＡＣ３、ＡＴＲＡＣ３ｐｌｕｓ、ＭＰ３、ＷＭＡなどがある。また、動画（映像）のメディアフォーマットとしては、ＭＰＥＧ２、ＭＰＥＧ１、ＭＰＥＧ４、ＷＭＶなどがある。これらは、たとえば、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ； ホームページはｗｗｗ．ｄｌｎａ．ｏｒｇ）でも同様に規定されている。ＤＬＮＡのｖｅｒｓｉｏｎ１．０では、サーバ（コンテンツの送信側、ＤＴＣＰではソース）をＤＭＳ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｓｅｒｖｅｒ）、クライアント（コンテンツの受信側、ＤＴＣＰではシンク）をＤＭＰ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｐｌａｙｅｒ）と呼んでいる。ＤＭＳはＵＰｎＰ−ＡＶのＭｅｄｉａＳｅｒｖｅｒ（ＭＳ）とＣｏｎｔｒｏｌＰｏｉｎｔ（ＣＰ）により構成され、ＤＭＰはＵＰｎＰ−ＡＶのＭｅｄｉａＲｅｎｄｅｒｅｒ（ＭＲ）とＣｏｎｔｒｏｌＰｏｉｎｔ（ＣＰ）により構成される。ＵＰｎＰ−ＡＶのＭＳ，ＭＲ、ＣＰについては、ＵＰｎＰのホームページ、ｗｗｗ／ｕｐｎｐ．ｏｒｇに記載されている。

映像メディアフォーマットの場合、（１）解像度の区別（ＳＤ、ＨＤ）、（２）ＴＶ方式の区別（アナログではＮＴＳＣ、ＰＡＬ，ＳＥＣＡＭ，デジタルでは米国ＡＴＳＣ、欧州ＤＶＢ、日本のＩＳＤＢなどＡＲＩＢ規格に基づく放送方式）、（３）タイムスタンプ形式などの付加情報の有無、などを追加パラメータとして持つ。なお、たとえば映像の場合、ＭＰＥＧ−ＰＳでもＭＰＥＧ−ＴＳに対してもＭＩＭＥ−Ｔｙｐｅは"ｍｐｅｇ／ｖｉｄｅｏ"であるので、上記の付加情報を用いることにより、よりきめ細かい映像メディアの取り扱い、制御が可能となる。

デジタル放送に関するＡＲＩＢ規格の概要は、たとえば、松下テクニカルジャーナル２００４年２月、Ｖｏｌ．５０、Ｎｏ．１、７ページから１２ページで解説されている。

また、パケット送受信部４０１におけるＡＶデータの属性を示す属性情報とは、例えば取り扱う信号がＡＶデータが日本における地上デジタル放送システムで放送局より放送され、家庭等の受信機で選局されたＭＰＥＧ−ＴＳ信号（正確には、ＡＲＩＢ標準規格、ＡＲＩＢ ＳＴＤ Ｂ２１、第９章において、シリアルインタフェースの入出力トランスポートストリームとして規定されているパーシャルトランスポート信号）の場合、その属性情報としては、放送局よりＰＳＩ／ＳＩ情報として送信される、チャンネル名（放送局名）、チャンネル番号、番組名、番組のジャンル、スケジュールされた放送開始時間、スケジュールされた放送終了時間、番組内容に関する情報、番組の解像度、パレンタルなどの視聴制限情報、コピー制御情報、視聴料金などがある。ＰＳＩに関しては、ＡＲＩＢ技術資料、ＡＲＩＢ ＴＲ−Ｂ１４やＡＲＩＢ ＴＲ−Ｂ１５にて規定されている。

ＡＫＥ部４０２は、認証部４１３と暗号化鍵交換部４１４を具備する。このＡＫＥ部４０２は、認証と鍵交換に関する設定情報（ＡＫＥ設定情報）を取得し、このＡＫＥ設定情報に関連した情報、たとえば、コピー保護情報と暗号化鍵変更情報をパケット化部４０３に出力する。

パケット化部４０３（４０３ａ）は、送信条件設定管理部４０４から送られてくる送信パラメータに従って、ＡＫＥ部４０２から送られてくるＡＫＥ設定情報に関連した情報をＴＣＰ／ＩＰのヘッダとして付加し、フレーム化部４０９に送る。

フレーム化部４０９は、送信条件設定管理部４０４から送られてくる送信パラメータに従って、パケット化部４０３からのＩＰパケットに対してさらにＭＡＣヘッダを付加することで、イーサネット（登録商標）フレームに変換し、送信フレームとしてネットワークに出力する。

受信側では、フレーム受信部４１０は、ネットワークより入力される信号（フレーム）に対して、ＭＡＣヘッダを元にフィルタリングして受信し、ＩＰパケットとしてパケット受信部４０５に渡す。

パケット受信部４０５（４０５ａ）は、フレーム受信部４１０から送られてくるＩＰパケットに対して、ＩＰパケットヘッダなどの識別によりフィルタリングを行い、ＡＫＥ部４０２に出力する。これにより、送信側のＡＫＥ部と、受信側のＡＫＥ部がネットワークを介して接続されるので、通信プロトコルを介してお互いにメッセージの交換ができる。すなわち、ＡＫＥ部の設定手順に従い、認証と鍵交換が行われる。

送信側と、受信側で認証と鍵交換が成立すれば、暗号化したＡＶデータを送信する。
送信側では、ＭＰＥＧ−ＴＳ信号が暗号化データ生成部４０６に入力され、暗号化データ生成部４０６内の暗号化部４１１は、ＭＰＥＧ−ＴＳ信号を暗号化する。続いて、暗号化情報ヘッダ付加部４１２は、ＡＫＥ部４０２から送られてくる前述したＥＭＩおよびシード情報（シード情報のすべてのビット、または、Ｏ／Ｅなど一部のビット）などのＡＫＥ情報を暗号化情報ヘッダとして付加し、パケット化部４０３に出力する。パケット化部４０３は、暗号化データ生成部４０６からのデータに対して、送信条件設定管理部４０４からの送信条件などのパラメータを用いて、ＴＣＰ／ＩＰのヘッダを付加し、フレーム化部４０９に送る。フレーム化部４０９は、パケット化部４０３からのＩＰパケットに対して、８０２．１Ｑ（ＶＬＡＮ）方式を用いてＭＡＣヘッダを付加することでイーサネット（登録商標）フレームに変換し、送信フレームとしてネットワークに出力する。ここで、ＭＡＣヘッダ内のＴＣＩ（Ｔａｇ Ｃｏｎｔｒｏａｌ Ｉｎｆｏｒｍａｉｔｉｏｎ）内のＰｒｉｏｒｉｔｙ（ユーザ優先度）を高く設定することにより、ネットワーク伝送の優先度を一般のデータよりも高くすることができる。

受信側では、ネットワークより入力される信号がフレーム受信部４１０でＭＡＣヘッダを元にフィルタリングされ、ＩＰパケットとしてパケット受信部４０５に入力される。パケット受信部４０５でパケットヘッダなどの識別によりフィルタリングされ、暗号化データ復号部４０７に入力され、暗号化データ復号部４０７にて暗号化情報ヘッダの除去と暗号の復号化が行われ、復号されたＭＰＥＧ−ＴＳ信号が出力される。

なお、送信条件設定管理部４０４には、受信条件設定管理部４０８を介して、受信状況を送信側にフィードバックするためのデータが入力され、送信条件設定管理部４０４において、ＩＰパケットのパケット化部４０３およびイーサネット（登録商標）フレームのフレーム化部４０９で生成するヘッダおよびペイロードデータが設定される。

次に、図１０のプロトコルスタックを用いて上記手順を補足説明する。図１０に示された送信側において、まず送信側から受信側へ暗号化されたコンテンツおよびコンテンツの保護モード情報が送信される。受信側は、コンテンツのコピー保護情報の解析を行い、認証方式を決定し、認証要求をパケット送信機器に送る。次に、乱数を発生させ、この乱数を所定の関数に入力し、交換鍵を作成する。交換鍵の情報を所定の関数に入力し、認証鍵を生成する。受信側でも所定の処理により認証鍵の共有を図る。なお、ここで用いる暗号化情報としては、たとえば、送信側の独自情報（機器ＩＤ、機器の認証情報、マックアドレスなど）、秘密鍵、公開鍵、外部から与えられた情報などを１つ以上組み合わせて生成した情報であり、ＤＥＳ方式やＡＥＳ方式など暗号化強度の強い暗号化方式を用いることにより強固な暗号化が可能である。そして、送信側は認証鍵を用いて交換鍵を暗号化して受信側に送り、受信側で交換鍵が復号される。また、交換鍵と初期鍵更新情報を所定の関数に入力し、暗号化鍵を生成する。なお、送信側では暗号鍵を時間的に変化させるために、時間的に変化する鍵更新情報を生成し、受信側に送信する。コンテンツであるＭＰＥＧ−ＴＳは暗号化鍵により暗号化される。そして暗号化されたＭＰＥＧ−ＴＳは、ＡＶデータとしてＴＣＰ（またはＵＤＰ）パケットのペイロードとしてＴＣＰパケットが生成される。さらにこのＴＣＰパケットはＩＰパケットのデータペイロードとして使用され、ＩＰパケットが生成される。さらにこのＩＰパケットはＭＡＣフレームのペイロードデータとして使用され、イーサネット（登録商標）ＭＡＣフレームが生成される。なお、ＭＡＣとしてはイーサネット（登録商標）であるＩＥＥＥ８０２．３だけでなく、無線ＬＡＮ規格のＩＥＥＥ８０２．１１のＭＡＣにも適用できる。

さて、イーサネット（登録商標）ＭＡＣフレームは、イーサネット（登録商標）上を送信側から受信側へ伝送される。受信側で所定の手順に従って復号鍵を生成する。そして、受信したイーサネット（登録商標）ＭＡＣフレームからＩＰパケットがフィルタリングされる。さらにＩＰパケットからＴＣＰ（またはＵＤＰ）パケットが抜き出される。そして、ＴＣＰ（またはＵＤＰ）パケットからＡＶデータが抜き出され、交換鍵と鍵変更情報より復元された復号鍵により、ＭＰＥＧ−ＴＳ（コンテンツ）が復号され出力される。

以上のように、本実施の形態によれば、ＭＰＥＧ−ＴＳ信号などのＡＶストリームをパケット送信機器で暗号化して、ＩＰパケットをネットワークにより伝送し、パケット受信機器で元の信号に復号することが可能である。

なお、図８において、スイッチングハブを用いたネットワークトポロジーを工夫することにより、ストリーム伝送とファイル転送を共存させることができる。たとえば、１階と２階の間のネットワーク３０５の帯域を、従来の技術で説明した１００Ｍｂｐｓから１Ｇｂｐｓに拡張することによって、１階と２階のＰＣ間でのファイル転送をバックグラウンドで行いながら、同時に、１階および２階のＤＶＤレコーダ、ＰＣ、ＴＶの間でＭＰＥＧ−ＴＳを暗号化してリアルタイムで伝送することができる。たとえば、市販されている１００Ｍｂｐｓのポートを８つ、１Ｇｂｐｓのポートを１つ持ったスイッチングハブを用い、１階と２階を結ぶネットワーク３０５に１Ｇｂｐｓのポートを接続し、残りの８ｃｈの１００ＭｂｐｓのポートにＴＶなどのＡＶ機器を接続する。１００Ｍｂｐｓのポートは８つなので、８つのポートのデータがそれぞれ最大１００Ｍｂｐｓで入力されて１Ｇｂｐｓのポートに出力されたとしても、１００Ｍｂｐｓ×８ｃｈ＝８００Ｍｂｐｓと１Ｇｂｐｓより小さいため、８つのポートから入力されたデータはスイッチングハブ内部で失われず全て１Ｇｂｐｓのポートに出力される。よって、１階で発生したデータは全て２階に伝送することが可能である。また、逆に２階で発生したデータも全て１階に伝送することが可能である。以上のように、スイッチングハブを用いる場合、ネットワークトポロジーを工夫することによりストリーム伝送とファイル転送を共存させることができる。

（実施の形態２）
次に、本発明の実施の形態２について説明する。図１１は、本実施の形態におけるパケット送受信部４０１ａの構成を示すブロック図である。図１１においては、認証モード決定部６０１以外は、図９に示されたパケット送受信部４０１と同様の構成である。よって以下では新規な部分について説明する。

図１１において、ＡＫＥ部４０２に対してＡＫＥ設定情報として、認証用のＴＣＰのポート番号が、本図に示されるように、管理制御データとして、送信条件設定管理部４０４に入力される。ここで、認証用のＴＣＰポート情報は、コンテンツ毎または放送チャネル毎にアクセス位置を指定するＵＲＩ、または、Ｑｕｅｒｙにより拡張されたＵＲＩ情報とにより与える。このとき、ＵＲＩについて、主データ部にコンテンツのＵＲＩ情報、Ｑｕｅｒｙ部にそのコンテンツの認証情報をマッピングする。これにより、もし、Ｑｕｅｒｙ部がなければそのコンテンツの伝送には認証が不必要であり、Ｑｕｅｒｙ部が存在すればそのコンテンツの伝送には認証が必要である様にモード設定することができる。ＵＲＩとＱｕｅｒｙの例は、例えば下記の形式で与えることができる。

＜ｓｅｒｖｉｃｅ＞：／／＜ｈｏｓｔ＞：＜ｐｏｒｔ＞／＜ｐａｔｈ＞／
＜ｆｉｌｅｎａｍｅ＞．＜ｅｘｔ＞？ＡＫＥＰＯＲＴ＝＜ｐｏｒｔ２＞
ここで、＜ｈｏｓｔ＞：＜ｐｏｒｔ＞／＜ｐａｔｈ＞／＜ｆｉｌｅｎａｍｅ＞．＜ｅｘｔ＞はＡＶコンテンツのＵＲＩとファイル名称を表しており、？以下のＱｕｅｒｙ部における＜ｐｏｒｔ２＞は認証用ポート番号を表している。ただし、認証用ポートのＩＰアドレスはＡＶコンテンツのＩＰアドレスと同じ場合である。

送信側はこのＵＲＩとＱｕｅｒｙで認証の実行モード情報を受信側に与える。受信側はＷＥＢブラウザやＵＰｎＰ−ＡＶのＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ ｓｅｒｖｉｃｅ）を用いて、上記のＵＲＩとＱｕｅｒｙ情報を受け取り、認証モード決定部６０１が認証モードを決定することができる。その他の動作は、実施の形態１と同様である。

（実施の形態３）
次に、本発明の実施の形態３について説明する。図１２は、本実施の形態におけるパケット送受信部４０１ｂの構成を示すブロック図である。図１２においては、送信条件設定管理部４０４に入力されるＡＶデータの入力ソース情報（放送、蓄積）以外は、図１１に示される実施の形態２のパケット送受信部４０１ａと同様の構成である。よって以下では新規な部分について説明する。

送信条件設定管理部４０４は、入力されたＡＶデータの入力ソース情報（放送、蓄積）に対して、必要データを抽出され、暗号化データ生成部４０６に出力される。そして、暗号化データ生成部４０６内の暗号化情報ヘッダ付加部４１２は、送信条件設定管理部４０４から送られてきた必要データを、以下の様に、暗号化情報ヘッダとして付加する。

送信条件設定管理部４０４に入力されるＡＶデータの入力ソース情報（放送、蓄積）としては、たとえば次のケースが考えられる。
（ケース１）ＡＶデータがコピーフリーコンテンツを放送する放送チャネルで受信されるコンテンツである場合。この様な放送チャネルの例としては、たとえば、アナログ放送であるＶＨＦ、ＵＨＦ、またはＢＳアナログ放送の放送チャネルがある。
（ケース２）ＡＶデータが一定期間でもコピーフリーでないコンテンツを放送する放送チャネルで受信されるコンテンツの場合。この様な放送チャネルの例としては、たとえば、ＢＳデジタル放送の有料チャネルやＣＡＴＶ放送による有料チャネルがある。この一定期間でもコピーフリーでないコンテンツを放送する放送チャネルのコピー制御情報は、コピーネバー、コピーワンジェネレーション、およびＥＰＮ（Ｅｎｃｒｙｐｔｉｏｎ Ｐｌｕｓ Ｎｏｎ−ａｓｓｅｔｉｏｎ）フラグ付きコピーフリーが放送内容により時々刻々と切り替わるのが特徴である。

ここで、一定期間でもコピーフリーでないコンテンツを放送する放送チャネルの受信は、放送の配信を行う事業者との間での認証部により正当な受信装置または受信ユーザであることを認証された場合に行われるように制御できる。この認証の例としては、日本のデジタル衛星放送のＢ−ＣＡＳ（ＢＳ−Ｃｏｎｄｉｔｉｏｎａｌ Ａｃｃｅｓｓ Ｓｙｓｔｅｍｓ）カード、または米国のＣＡＴＶ放送で使用されるＰＯＤカードなどのセキュリティモジュールによる認証が考えられる。

また、暗号化情報ヘッダの付加制御は、たとえば以下の様に行なう。すなわち、コピーフリーコンテンツを放送する放送チャネルを受信した場合には付加しない。また、一定期間でもコピーフリーでないコンテンツを放送する放送チャネルを受信した場合には付加する。さらに、ＡＶデータが蓄積メディアよりコピーフリータイトルのコンテンツを再生した場合には付加しない。そして、ＡＶデータが蓄積メディアよりコピーフリーでないタイトルのコンテンツを再生した場合には付加する。

以上のように、暗号化情報ヘッダの付加制御を行うことにより、著作権者が設定したＡＶコンテンツのＣＣＩ（コピー制御情報）をネットワーク伝送においても継承して伝えていくことができる。さらに、送信側と受信側で暗号化情報ヘッダの付加制御のルールを揃えることにより異機種間での動作互換性を確保することができる。

（実施の形態４）
次に、本発明の実施の形態４について説明する。図１３は、本実施の形態におけるパケット送受信部４０１ｃの構成を示すブロック図である。図１３においては、送信キュー制御部８０１、第１キュー８０２、および第２キュー８０３以外は、図９に示された実施の形態１のパケット送受信部４０１と同様の構成である、よって以下では新規な部分について説明する。

ＡＫＥ部４０２に対してＡＫＥ設定情報が入力され、このＡＫＥ設定情報に関連した情報（たとえば、コピー保護情報と暗号化鍵変更情報）、および、送信データの種別、送信先アドレスやポート番号の情報、送信に用いるパス情報（ルーティング情報）、送信データの帯域、送信データの送信優先度などの送信条件の設定情報と、送信部（ローカル）と受信部（リモート）における機器の管理制御データと、受信状況を送信側にフィードバックするためのデータが、送信条件設定管理部４０４からパケット化部４０３に入力され、パケット化部４０３においてＴＣＰ／ＩＰ処理が行われ、第１キュー８０２に入力される。また、送信側ではＭＰＥＧ−ＴＳ信号が暗号化データ生成部４０６に入力され、暗号化データ生成部４０６においてＭＰＥＧ−ＴＳ信号が暗号化された後、この暗号化されたＭＰＥＧ−ＴＳ信号がパケット化部４０３に入力され、パケット化部４０３においてＴＣＰ／ＩＰ処理が行われ、第２キュー８０３に入力される。

送信キュー制御部８０１は、第１キュー８０２と第２キュー８０３にデータが存在する場合、どちらのデータを優先して出力するかの制御を行なう。通常状態では、一般データよりもＭＰＥＧ−ＴＳなどのコンテンツデータを優先制御して出力する。たとえば、パケット送受信機器間でＭＰＥＧ−ＴＳを低レイテンシ（低遅延）で伝送する場合には、ＭＰＥＧ−ＴＳ用バッファも小さくなるため、オーバーフローが発生しやすい。送信側でＭＰＥＧ−ＴＳバッファがオーバーフローしそうになった場合、あるいは、受信側からフィードバックされた情報を参照して受信側のＭＰＥＧ−ＴＳのバッファがアンダーフローしそうになったことが判明した場合には、ＭＰＥＧ−ＴＳデータを優先出力する様に第２キュー８０３の優先度を更に適応的に上げることにより、これらバッファ破綻を回避できる。

ただし、受信側機器（リモート機器）の再生、停止などの機器制御応答をより速くするには、第１キュー８０２の優先度を適応的に上げればよいが、これでは前述したＭＰＥＧ−ＴＳバッファのオーバーフローまたはアンダーフローが発生する可能性がある。

バッファのオーバーフローやアンダーフローを避け、かつ、受信側機器（リモート機器）の再生、停止などの機器制御応答をより速くする別の方法として、機器制御用パケットだけは、第１キュー８０２および第２キュー８０３キューを経由せずに、直接、フレーム化部４０９に出力することにより、迅速な制御応答が実現される。あるいは、機器制御用パケットに対して第３キューを新たに用意する方法により、迅速な制御応答が実現される。なお、受信側の動作は実施の形態１と同様である。

（実施の形態５）
次に、本発明の実施の形態５について説明する。図１４は、本実施の形態におけるパケット送受信部４０１ｄの構成を示すブロック図である。図１４においては、パケット化部４０３内の第１パケット化部９０１および第２パケット化部９０２、パケット受信部４０５内の第１パケット受信部９０３および第２パケット受信部９０４以外は図１３に示された実施の形態４のパケット送受信部４０１ｃと同様の構成である。よって以下では新規な部分について説明する。

図１４において、ＡＫＥ部４０２に対してＡＫＥ設定情報が入力され、このＡＫＥ設定情報に関連した情報（たとえば、コピー保護情報と暗号化鍵変更情報）、および、送信データの種別、送信先アドレスやポート番号の情報、送信に用いるパス情報（ルーティング情報）、送信データの帯域、送信データの送信優先度などの送信条件の設定情報と、送信部（ローカル）と受信部（リモート）における機器の管理制御データと、受信状況を送信側にフィードバックするためのデータが、第１パケット化部９０１に入力され、パケット化部９０１においてプロセッサを用いたソフトウェア処理でＴＣＰ／ＩＰ処理がなされ、第１キュー８０２に入力される。

送信側ではＭＰＥＧ−ＴＳ信号が暗号化データ生成部４０６に入力され、暗号化データ生成部４０６においてＭＰＥＧ−ＴＳ信号に暗号化された後、この暗号化されたＭＰＥＧ−ＴＳ信号がパケット化部４０３に入力され、ハードウェア処理によりＵＤＰ／ＩＰの処理をされ、第２キュー８０３に入力される。

送信キュー制御部８０１は、第１キュー８０２と第２キュー８０３の双方にデータが存在する場合、前述の実施の形態２と同様に、２つのキューからのデータ出力に関して優先制御を行なう。

さて、受信側では、ネットワークより入力される信号がフレーム受信部４１０でＭＡＣヘッダを元にＩＰパケットがフィルタリングされる。ここでは、上記第１パケット化部９０１から出力されたＩＰパケットが第１パケット受信部９０３に入力され、上記第２パケット化部９０２から出力されたＩＰパケットがおよび第２パケット受信部９０４に入力される。第１パケット受信部９０３では、プロセッサを用いたソフトウェア処理でＴＣＰ／ＩＰの受信処理が行われ、ＡＫＥ部４０２または受信条件設定管理部４０８に出力される。また、第２パケット受信部９０４では、ハードウェア処理によりＵＤＰ／ＩＰの受信処理が行われ、暗号化データ復号部４０７に入力され、暗号化データ復号部４０７において暗号が復号され、ＭＰＥＧ−ＴＳが出力される。

次に、図１５のプロトコルスタックを用い、上記手順を補足説明する。図１５においては、ＭＰＥＧ−ＴＳなどＡＶデータのトランスミッション層がＵＤＰである以外は、図１０に示されるプロトコルスタックと同様である、よって以下では新規な部分について説明する。図１５に示された送信側において、コンテンツであるＭＰＥＧ−ＴＳは暗号化鍵Ｋｃにより暗号化される。そして暗号化されたＭＰＥＧ−ＴＳは、前述したＥＭＩおよびシード情報とともにＡＶデータとして、ハードウェアによりＵＤＰパケットのペイロードとしてＵＤＰパケットが生成される。さらにこのＵＤＰパケットはＩＰパケットのデータペイロードとして使用され、ＩＰパケットが生成される。

なお、送信側から受信側へのＥＭＩおよびシード情報の伝送方法としては、たとえば、専用の別パケットを生成して伝送することも可能であり、これによって、暗号鍵復元がさらに困難となり、コンテンツの盗聴、漏洩がより困難化される。また、インターネットなどの公衆網において、リアルタイムに伝送されるＡＶデータの暗号化パラメータを変化させたり、別パケットで送ると、コンテンツの盗聴、漏洩をより困難にすることができる。管理制御データに関しては、図１０の例と同様に、ソフトウェア処理によりＴＣＰパケットが生成され、ＩＰパケット化される。

さて、イーサネット（登録商標）ＭＡＣフレームは、イーサネット（登録商標）上を送信側から受信側へ伝送される。受信側で所定の手順に従って復号鍵を生成する。そして、受信したイーサネット（登録商標）ＭＡＣフレームからＩＰパケットがフィルタリングされる。さらにＩＰパケットからＵＤＰパケットが抜き出され、ＵＤＰパケットからＡＶデータが抜き出され、交換鍵とシード情報より復元された復号鍵Ｋｃにより、ＭＰＥＧ−ＴＳ（コンテンツ）が復号され出力される。

図１６は、ＭＰＥＧ−ＴＳをＩＰパケット化、さらにイーサネット（登録商標）フレーム化して伝送する場合のパケット形式の一例を示す。１８８バイトのＭＰＥＧ−ＴＳに６バイトのタイムコード（ＴＣ）を付加して１９４バイトの単位を作る。ＴＣは４２ビットのタイムスタンプと６ビットのベースクロックＩＤ（ＢＣＩＤ）により構成される。ＢＣＩＤによりタイムスタンプの周波数情報を表すことができる。たとえば、（ケース１）ＢＣＩＤが０ｘ００の場合は、タイムスタンプの周波数情報はない、（ケース２）ＢＣＩＤが０ｘ０１の場合は、タイムスタンプの周波数情報としては２７ＭＨｚ（ＭＰＥＧ２のシステムクロック周波数）である、（ケース３）また、ＢＣＩＤが０ｘ０２の場合は、タイムスタンプの周波数情報としては９０ｋＨｚ（ＭＰＥＧ１で使用されるクロック周波数）である、（ケース４）ＢＣＩＤが０ｘ０３の場合は、タイムスタンプの周波数情報としては２４．５７６ＭＨｚ（ＩＥＥＥ１３９４で使用されるクロック周波数）である。（ケース５）ＢＣＩＤが０ｘ０４の場合は、タイムスタンプの周波数情報としては１００ＭＨｚ（イーサネット（登録商標）で使用される周波数）である、という様にＢＣＩＤでタイムスタンプの周波数情報を表すことができる。１９４バイト単位のデータを２つあわせて暗号化して、更に１４バイトの暗号化情報ヘッダと合わせてＲＴＰのペイロードとする。ここで、暗号化情報ヘッダは、４ビットのＥＭＩと、６４ビットのシード情報と１２ビットのＲｅｓｅａｒｖｅｄ Ｄａｔａにより構成される。ＲＴＰパケットはＵＤＰおよびＩＰによりパケット化された後、イーサネット（登録商標）フレーム化される。イーサネット（登録商標）ヘッダとしては、図１６に示される様に、標準的なイーサネット（登録商標）ヘッダとＩＥＥＥ８０２．１Ｑ（ＶＬＡＮ）により拡張されたイーサネット（登録商標）ヘッダの両方をサポートする。なお、ＩＥＥＥ８０２．１Ｑ（ＶＬＡＮ）により拡張されたイーサネット（登録商標）ヘッダにおけるＴＣＩフィールドの中の３ビットのＰｒｉｏｒｉｔｙフラグにより、イーサネット（登録商標）フレームの優先度を設定することができる。

以上により、パケット送受信機器間でＭＰＥＧ−ＴＳ信号を暗号化してリアルタイム伝送が可能となるだけでなく、第２パケット化部９０２がハードウェアで構成されているため、本質的にソフトウェア処理に起因する送信パケットの送り残しや受信パケットの取りこぼしが発生しない。これにより、全ての優先データパケットが完全に送信され、リアルタイム性の保証された高品質映像の伝送が可能となる。また、一般データは一時的にバッファ部に蓄積され、優先データ伝送が優先して行なわれる中で間欠的に伝送される。また、データ量の小さい第１パケット化部９０１はマイコンなど安価なプロセッサで処理できる。

さらに、ハードウェア処理により、受信処理においても、イーサネット（登録商標）フレームを受信して、ＯＳＩ参照モデルにおける３層のＩＰヘッダ、４層のＵＤＰヘッダを同時に検査することもできる。ＭＰＥＧ−ＴＳパケットと一般データパケットを分離し、ＭＰＥＧ−ＴＳパケットの処理をハードウェアで行うことにより、受信フレームの取りこぼしが発生せず、リアルタイム性が保証された高品質な受信ができる。

パケットの送信タイミング、あるいは、２つの送信データキューからのデータ送信割合を、ソフトウェアではなく、ハードウェアで制御するとクロック単位で完全な送出制御が可能である。これにより全ての優先パケットが完全に送信され、リアルタイム性の保証された高品質の伝送が可能となる。また、出力パケットのシェイピングもクロック単位で正確に行われるため、初段のルータ、またはスイッチングハブでのパケット廃棄の発生確率が非常に少ない高品質な通信が可能となる。

ここで、本実施の形態における第１の変形例について説明する。図１７は、その変形例におけるパケット送受信部４０１ｅの構成を示すブロック図であり、ＡＫＥ部にＤＴＣＰ方式を用いた場合の一例である。また、図１８（ａ）は、パケット化部４０３内の第１パケット化部９０１および第２パケット化部９０２、図１８（ｂ）は、パケット受信部４０５内の第１パケット受信部９０３および第２パケット受信部９０４におけるパケット処理についての説明図である。

図１７に示されるように、ＡＫＥ部４０２内のＤＴＣＰ情報生成部１２０１、ＡＫＥコマンド受信処理部１２０２、ＡＫＥコマンド送信処理部１２０３、交換鍵生成部１２０４、暗号化鍵生成部１２０５、暗号鍵変更情報生成部１２０６および復号鍵生成部１２０７以外は図１４に示される実施の形態５のパケット送受信部４０１ｄと同様の構成である、よって以下では新規な部分について説明する。

このパケット送受信部４０１ｅは、図１９のフローチャートに示されるように、以下のステップでＤＴＣＰ方式により暗号化コンテンツの伝送を行なう。
（ステップＳ１１）コピー制御情報がＤＴＣＰ情報生成部１２０１に入力される。
（ステップＳ１２）まず、ソース側でコンテンツの送信要求を発生させ、ＤＴＣＰ情報生成部１２０１より、コンテンツの保護モード情報（ＥＭＩ情報）が第１パケット化部９０１に出力され、パケット化部９０１でパケット化された後、シンクに送信される。
（ステップＳ１３）そして、受信側（シンク）では、第１パケット受信部９０３よりＡＫＥコマンド受信処理部１２０２にコンテンツのコピー保護情報が入力されると、ＡＫＥコマンド受信処理部１２０２は、そのコピー保護情報の解析を行い、完全認証もしくは制限付き認証のどちらの認証方式を用いるかを決定し、ＡＫＥコマンド送信処理部１２０３を通じて認証要求をソースに送る。
（ステップＳ１４）ソースとシンク間でＤＴＣＰ所定の処理が行なわれ、認証鍵が共有される。
（ステップＳ１５）次に、ソースでは、ＡＫＥ送信処理部１２０３は、認証鍵を用いて交換鍵を暗号化し、第１パケット化部９０１を経由してシンクに送る。シンクでは、ＡＫＥコマンド受信処理部１２０２から与えられる情報により、交換鍵生成部１２０４において交換鍵が復号される。
（ステップＳ１６）ソースでは、暗号鍵を時間的に変化させるために、暗号化鍵生成部１２０５において、時間的に変化するシード情報（Ｏ／Ｅ）が生成され、ＤＴＣＰ情報生成部１２０１および第１パケット化部９０１を経由してシンクに送信される。
（ステップＳ１７）ソースでは、暗号化鍵生成部１２０５において交換鍵とシード情報より暗号化鍵が生成され、暗号化データ生成部４０６でＭＰＥＧ−ＴＳが暗号化され、第２パケット化部９０２に出力される。
（ステップＳ１８）シンクでは、暗号鍵変更情報生成部１２０６は、第１パケット受信部９０３よりシード情報を受信し、復号鍵生成部１２０７は、このシード情報と交換鍵生成部１２０４の情報より、復号鍵を復元する。
（ステップＳ１９）シンクでは、この復号鍵を用いて暗号化データ復号部４０７において、暗号化されたＭＰＥＧ−ＴＳ信号が復号される。

図１８（ａ）に示されるように、第１パケット化部９０１では、入力データは、ＲＴＣＰまたはＲＴＳＰ、ＴＣＰまたはＵＤＰ、さらにＩＰによる処理がなされ、出力される。なお、ＲＴＣＰ（ｒｆｃ１８８９）は、ネットワークの実効帯域幅や遅延時間などを受信装置より送信装置に送り、送信装置は報告された通信状態に合わせてＲＴＰで送信するデータの品質を調整して送信することもできる。また、ＲＴＳＰ（ｒｆｃ２３２６）は、再生、停止、早送り、などの制御コマンドを送ることもでき、ＡＶファイルよりデータをダウンロードしながらコンテンツを再生することが可能である。また、第２パケット化部９０２では、入力データは、ＲＴＰ、ＵＤＰ、そしてＩＰでそれぞれ処理され、ＩＰパケットが出力される。

一方、図１８（ｂ）に示されるように、第１パケット受信部９０３では、受信データは、フィルタリングなどＩＰ受信処理、ＴＣＰまたはＵＤＰの受信処理、さらに、ＲＴＣＰまたはＲＴＳＰによる受信処理がなされ、データが出力される。また、第２パケット受信部９０４では、受信データは、フィルタリングなどＩＰ受信処理、ＵＤＰの受信処理、さらに、ＲＴＰの受信処理がなされ、データが出力される。

以上により、パケット送受信機器間でＭＰＥＧ−ＴＳ信号をＤＴＣＰ方式により暗号化してリアルタイム伝送が可能となるだけでなく、第２パケット化部９０２がハードウェアで構成されているため、本質的にソフトウェア処理に起因する送信パケットの送り残しや受信パケットの取りこぼしが発生しない。また、データ量の小さい第１パケット化部９０１はマイコンなど安価なプロセッサで処理できる。

続いて、本実施の形態における第２の変形例について説明する。この変形例に係るパケット送受信部の基本的な構成は、図１７に示された第１の変形例と同様である。ただし、図２０に示されるように、パケット化部４０３ａ（より厳密には、パケット化部９０２ａ）と、パケット受信部４０５ａ（より厳密には、パケット受信部９０４ａ）が第１と変形例と異なる。つまり、図２０に示されるように、図２０（ａ）の第２パケット化部９０２ａ、および図２０（ｂ）の第２パケット受信部９０４ａ以外は図１８に示された第１の変形例と同様の構成である、よって以下では新規な部分について説明する。

第２パケット化部９０２ａは、内部で入力データにエラー訂正処理を行ない、ＲＴＰ、ＵＤＰ、そしてＩＰでそれぞれ処理してＩＰパケットを出力する。

また、第２パケット受信部９０４ａは、内部でフィルタリングなどＩＰ受信処理、ＵＤＰの受信処理、ＲＴＰの受信処理、さらにエラー訂正復号処理を行い、エラー訂正されたデータを出力する。

図２１は、第２の変形例におけるプロトコルスタックの説明図であり、送信側では、ＡＶデータはエラー訂正符号が付加され（ＥＣＣエンコード）、ＵＤＰに渡される。また、受信側では、ＵＤＰ処理よりデータを受け取り、エラー訂正後に上位層にＡＶデータとして渡される。

ここで、エラー訂正処理の例を図２２および図２３を使用して説明する。図２２は、エラー訂正方式がリードソロモン方式の場合の訂正処理を説明する図であり、図２３は、エラー訂正方式がパリティの場合の訂正処理を説明する図である。ＭＰＥＧ−ＴＳを２つ単位でエラー訂正インターリーブマトリックスに入力する。なお、各行にはシーケンス番号を２バイト使用する。そして、図２２および図２３に示されるように、たとえば前述した１０バイトのＤＴＣＰ情報（ＥＭＩ情報４ビット、シード情報６４ビット、その他１２ビット）を用い、さらに、ＲＴＰヘッダ、ＵＤＰヘッダ、ＩＰヘッダ、イーサネット（登録商標）ヘッダを付加してイーサネット（登録商標）フレームが構成される。

以上により、パケット送受信機器間でＭＰＥＧ−ＴＳ信号をＤＴＣＰ方式により暗号化し、さらにエラー訂正符号を付加しリアルタイム伝送が可能となる。さらに、第２パケット化部９０２がハードウェアで構成されているため、本質的にソフトウェア処理に起因する送信パケットの送り残しや受信パケットの取りこぼしが発生しない。また、データ量の小さい第１パケット化部９０１はマイコンなど安価なプロセッサで処理できる。

（実施の形態６）
次に、本発明の実施の形態６について説明する。図２４は、本実施の形態におけるパケット送受信部４０１ｆの構成を示すブロック図である。図２４においては、パケット化部４０３ｂ（より厳密には、第２パケット化部９０２ｂ）およびパケット受信部４０５ｂ（より厳密には、第２パケット受信部９０４ｂ）以外は、図１７に示されたパケット送受信部４０１ｅの構成と同様である。よって以下では新規な部分について説明する。

図２５は、本実施の形態におけるプロトコルスタックの説明図である。送信側では、ＡＶデータにエラー訂正符号を付加し（ＥＣＣエンコード）、ＵＤＰに渡す場合と、ＨＴＴＰ経由でＴＣＰに渡す場合とがある。ここで、ＡＶデータをＲＴＰに渡すかＨＴＴＰに渡すかは、受信側からの制御により、ＲＴＰまたはＨＴＴＰで行うことを切替え制御する。たとえば、ＡＶデータのパケット化は、受信側のＡＶデータ出力がディスプレイ充てに出力される場合は遅延の小さいＲＴＰを用い、受信側のＡＶデータ出力が記録メディアに蓄積される場合は再送によりパケット落ちを低減するＨＴＴＰを用いる。このように、切替え制御することにより受信側でディスプレイに出力する場合は低遅延でのＡＶコンテンツの伝送が可能となり、また、受信側で蓄積する場合はパケットロスによる信号欠落が補償された高品質なＡＶコンテンツの伝送が可能となる。なお、図２５において、受信側のプロトコル処理は、送信側と逆の手順で処理される。

ここで、本実施の形態の第１および第２の変形例に係るパケット送受信部４０１ｇおよびパケット送受信部４０１ｈの構成を示すブロック図を、それぞれ、図２６および図２７に示す。これらは、それぞれ、ＭＰＥＧ−ＴＳなどＡＶコンテンツの受信機能、または送信機能を省いた構成であり、その他は本実施の形態におけるパケット送受信部４０１ｆと同じ構成である。このようなパケット送受信部４０１ｇおよびパケット送受信部４０１ｈは、送信または受信のみの機器に対して適用可能であり、低コスト化が図れる。

（実施の形態７）
次に、本発明の実施の形態７について説明する。図２８は、本実施の形態におけるパケット送受信部２４０１の構成を示すブロック図である。このパケット送受信部２４０１は、入力ＡＶコンテンツをその関連メタ情報が持つ送信条件に従って暗号化、関連メタ情報の付加、パケット化を行う装置であり、ＴＳストリーム識別部２４０２、送信条件設定管理部２４０３、ＤＲＭ（Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ）設定管理部２４０４、ＡＫＥ部２４０５、パケット化部２４０６、送信キュー制御部２４０７、フレーム化部２４０８、フレーム受信部２４０９、パケット受信部２４１０、ＤＲＭコンテンツ購入決済部２４１１、コンテンツバッファ２４１３、暗号化部２４１４、暗号化情報ヘッダ付加部２４１５、ＨＴＴＰ／ＲＴＰヘッダ付加部２４１６、条件設定部２４１７および復号化部２４１８から構成される。

ここで、送信条件設定管理部２４０３には、送信の対象となるＡＶデータが入力される端子を示す入力端子情報、ＡＶデータのデータフォーマットを示すデータフォーマット情報及びＡＶデータの属性を示す属性情報を含むＡＶデータ情報、具体的には、送信データのフォーマット種別、送信先アドレスやポート番号などの送信情報、送信に用いるパス情報（ルーティング情報）、送信データの帯域、送信データの送信優先度などの送信条件の設定情報、送信部（ローカル）と受信部（リモート）における機器の管理制御データと、受信状況を送信側にフィードバックするためのデータが入力される。

コンテンツは、その選択に関して、蓄積メディアに蓄積されたコンテンツ毎または放送チャネル毎にＱｕｅｒｙにより拡張されたＵＲＩ情報で与える。ここで、ＵＲＩについて、主データ部にコンテンツのＵＲＩ情報、Ｑｕｅｒｙ部にそのコンテンツの認証情報をマッピングする。これにより、もし、Ｑｕｅｒｙ部がなければそのコンテンツの伝送には認証が不必要であり、Ｑｕｅｒｙ部が存在すればそのコンテンツの伝送には認証が必要である様にモード設定することができる。ＵＲＩとＱｕｅｒｙの例は、例えば下記の形式で与えることができる。

＜ｓｅｒｖｉｃｅ＞：／／＜ｈｏｓｔ＞：＜ｐｏｒｔ＞／＜ｐａｔｈ＞／＜ｆｉｌｅｎａｍｅ＞．＜ｅｘｔ＞？ＡＫＥＰＯＲＴ＝＜ｐｏｒｔ２＞
ここで、＜ｈｏｓｔ＞：＜ｐｏｒｔ＞／＜ｐａｔｈ＞／＜ｆｉｌｅｎａｍｅ＞．＜ｅｘｔ＞はＡＶコンテンツのＵＲＩとファイル名称を表しており、以下のＱｕｅｒｙ部における＜ｐｏｒｔ２＞は認証用ポート番号を表わす。ここで、一般に認証サーバとコンテンツ提供サーバが同一であれば、認証用ポートのＩＰアドレスはＡＶコンテンツのＩＰアドレスと同じであるが、認証サーバとコンテンツ提供サーバが異なる場合には認証用ポートのＩＰアドレスはＡＶコンテンツのＩＰアドレスと異なる。送信側はこれら、ＵＲＩとＱｕｅｒｙで認証の実行モード情報を受信側に与える。受信側はＷＥＢブラウザやＵＰｎＰ−ＡＶのＣＤＳを用いて、上記のＵＲＩとＱｕｅｒｙ情報を受け取り、認証モードを決定することができる。

また、ＤＲＭ設定管理部２４０４は、送信条件設定管理部２４０３またはＴＳストリーム識別部２４０２よりＤＲＭ設定情報（課金情報、再生制御情報又はコピー制御情報）を受け取り、その情報を保持、管理するとともに、ＡＫＥに必要な関連情報をＡＫＥ部２４０５に引き渡す。具体的には、ＤＲＭ設定管理部２４０４は、送信条件設定管理部２４０３等から渡されるＤＲＭ設定情報に基づいて、ＡＶデータの再生制御、出力制御又はコピー制御を行うための課金情報、コピー制御情報、有効期限情報、有効再生回数情報の少なくとも１つを生成し、生成した情報を認証情報としてＡＫＥ部２４０５に渡す。ここで、ＤＲＭは、デジタル著作権管理のことである。このＤＲＭ設定管理部２４０４でコンテンツ伝送にＤＲＭの課金、購入処理が必要と判断された場合には、ＤＲＭコンテンツ購入決済部２４１１は、コンテンツの購入処理を行う。コンテンツの購入処理が終了後に、ＤＲＭコンテンツ購入決済部２４１１は、コンテンツのＣＣＩ（コピー制御情報）を設定し、ＡＫＥ部２４０５に渡す。なお、ＡＫＥ部２４０５は、認証処理を行う認証部と、受信側と暗号化鍵の交換を行う暗号化鍵交換部を具備する。

ＡＫＥ部２４０５に対してＡＫＥ設定情報が入力されると、このＡＫＥ設定情報に関連した情報、たとえばコピー保護情報と暗号化鍵変更情報がパケット化部２４０６に入力され、パケット化部２４０６においてＴＣＰ／ＩＰのヘッダを付加され、さらに、フレーム化部２４０８においてＭＡＣヘッダが付加され、イーサネット（登録商標）フレームに変換され、送信フレームとしてネットワークに出力される。

図２９は、本発明の実施におけるＤＴＣＰ方式による暗号化コンテンツの伝送手順を示すフローチャートである。このフローチャートを用いて、ＤＴＣＰ方式による著作権対応のＡＶコンテンツの伝送ステップの一例について説明する。ここで、ＤＲＭ対応のＡＶコンテンツとはデジタル放送のコピー制御や、サーバ型放送（ＡＲＩＢ規格、ＳＴＤ−Ｂ３８）等で取り扱うＲＭＰ（Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ ＆ Ｐｒｏｔｅｃｔｉｏｎ）方式や、各種のネットワークＤＲＭで扱っているコンテンツ保護情報を表す。

ここで、ＲＭＰはＴＶ Ａｎｙｔｉｍｅフォーラム（ｈｔｔｐ：／／ｗｗｗ．ｔｖ−ａｎｙｔｉｍｅ．ｏｒｇ／）の提唱するシステムにおいて、コンテンツ著作権の管理や利用者プライバシーの保護を目的に策定された仕様である。また、ＲＭＰＩ（Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ ＆ Ｐｒｏｔｅｃｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ）はコンテンツ利用の条件をあらわした権利情報を記述、規定したものである。ＲＭＰＩで記述できる機能としては、利用者がコンテンツを視聴できる回数、コピー可否、およびコピー回数などの利用条件である。ＲＭＰＩも暗号化されてセキュアに伝送され、ＲＭＰＩで保護されたコンテンツは、その記述条件の範囲内で視聴ができる。 サーバ型放送においては、受信機内のハードシスクなど蓄積デバイスにデジタル情報のままで映像の劣化無しに蓄積されたプログラムの不正利用や改ざん防止が求められている。

また、放送番組と共に伝送される放送番組に関する番組名、開始／終了時間、番組内容などのメタデータを用いて、番組を編集・再構成して視聴することが簡単になるため、放送受信者が受信した番組をどのように再生、伝送して視聴するかを制御する仕組みが重要である。

このような権利管理保護を行い一例として、秒単位で更新するスクランブル放送の暗号鍵でコンテンツを暗号化したまま受信側内のハードディスクに蓄積し、再生視聴時にその暗号を復号化する。また、スクランブル鍵を、番組単位で付与するコンテンツ鍵により暗号化し、番組単位での保護も行う。このような暗号化により、蓄積番組の不正な改ざんを防止し、また、不正に番組を複製しても、コンテンツ鍵が必要となるため視聴が不可能となる。放送局は、前述したコンテンツ鍵に有効期限などの利用条件を追加することにより、受信者が蓄積した番組に対しても、視聴許可の期間などを制御することができる。

このよう再生制御機能を利用すると、放送番組を利用許諾型サービスに展開したり、課金型サービスに展開できる。例えば、有効期限が過ぎたコンテンツを視聴する場合には、放送受信者は、放送局に番組視聴の許諾を求め、放送、電話回線やインターネットにより新しい有効期限を持つコンテンツ鍵を入手して、番組を視聴できるようになる。
（ステップＳ２１）まず、受信側で送信側より、ＵＰｎＰ−ＡＶ、ＣＤＳなどで与えられるコンテンツリストより受信したいコンテンツを選択し、ソース側にコンテンツの送信要求を投げる。
（ステップＳ２２）コピー制御情報またはＤＲＭ情報を含んだデータがＴＳストリーム識別部２４０２により抽出され、ＤＲＭ設定管理部２４０４経由で、ＡＫＥ部２４０５に入力される。

ＤＴＣＰ情報としてはＡＫＥ部２４０５よりコンテンツの保護モード情報（ＥＭＩ情報）が暗号化情報ヘッダ付加部２４１５に出力され、暗号化情報ヘッダ付加部２４１５においてヘッダ情報として付加された後、パケット化部２４０６に入力される。
（ステップＳ２３）受信側（シンク）では、パケット受信部２４１０よりＡＫＥコマンド受信処理を行うＡＫＥ部２４０５にコンテンツのコピー保護情報が入力されると、ＡＫＥ部２４０５は、そのコピー保護情報を解析し、完全認証もしくは制限付き認証のどちらの認証方式を用いるかを決定し、認証要求をソースに送る。
（ステップＳ２４）ソースとシンク間でＤＴＣＰ所定の処理が行なわれ、認証鍵が共有される。このようにして、ＡＫＥ部２４０５による認証が行われる。例えば、入力端子情報と、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報より生成する認証条件とにより、受信側（シンク）との間で認証が行われる。
（ステップＳ２５）次に、ソースはＡＫＥ部２４０５において、認証鍵を用いて交換鍵を暗号化してパケット化部２４０６を経由してシンクに送り、シンクのＡＫＥ部において交換鍵が復号される。
（ステップＳ２６）ソースでは暗号鍵を時間的に変化させるために、ＡＫＥ部２４０５の暗号化鍵生成部において、時間的に変化するシード情報（Ｏ／Ｅ）が生成され、ＡＫＥ部２４０５、暗号化情報ヘッダ付加部２４１５、およびＨＴＴＰ／ＲＴＰヘッダ付加部２４１６を経由してシンクに送信される。
（ステップＳ２７）ソースでは、暗号化鍵を生成するＡＫＥ部２４０５において交換鍵とシード情報より暗号化鍵を生成して、暗号化部でＭＰＥＧ−ＴＳを暗号化してパケット化部２４０６に出力する。
（ステップＳ２８）シンク内部の、暗号鍵変更情報を生成するＡＫＥ部２４０５は、パケット受信部２４１０よりシード情報を受信し、このシード情報と交換鍵より復号鍵を復元する。
（ステップＳ２９）シンクでは、復号化部２４１８は、この復号鍵を用いて、暗号化されたＭＰＥＧ−ＴＳ信号入力を復号して出力する。

ここで、ＤＲＭコンテンツがあって、そのコピー可能回数がＮ回（Ｎは２以上の整数）である場合の動作について説明する。

まず、受信端末がＤＲＭに対応している場合には、伝送暗号状態のＣＣＩをＣＯＧ（１世代コピー可能）またはＣＮＭ（コピーノーモア）、またはＣＮ（コピーネバー）に設定して伝送する。ここで、暗号化伝送されるエンベデッドＣＣＩとして「残りのコピー可能回数情報」を（Ｎ−１）回として受信側に伝え、受信側で暗号を復号した後に、ＤＲＭ対応端末では残りのコピー可能回数を（Ｎ−１）回に設定する。

また、受信端末がＤＲＭに対応していない場合には、コンテンツのＤＲＭ情報は削除してＮＭＣのＣＣＩを用いて受信側に伝送する。

ＡＫＥ部２４０５は、暗号化ヘッダ情報を暗号化情報ヘッダ付加部２４１５に入力し、暗号化情報ヘッダ付加部２４１５は、以下のように、暗号化情報ヘッダ付加制御を行なう。

なお、送信条件設定管理部２４０３に入力されるＡＶデータの関連情報（放送、または蓄積コンテンツ再生の場合）として、たとえば次のような場合が考えられる。
（ケース１） 前記ＡＶデータがコピーフリーコンテンツを放送する放送チャネルで受信されるコンテンツの場合。この様な放送チャネルの例としては、たとえば、アナログ放送であるＶＨＦ、ＵＨＦ、またはＢＳアナログ放送の放送チャネルがある。
（ケース２） 前記ＡＶデータが一定期間でもコピーフリーでないコンテンツを放送する放送チャネルで受信されるコンテンツの場合。この様な放送チャネルの例としては、たとえば、ＢＳデジタル放送の有料チャネルやＣＡＴＶ放送による有料チャネルがある。この一定期間でもコピーフリーでないコンテンツを放送する放送チャネルのコピー制御情報は、コピーネバー、コピーワンジェネレーション、およびＥＰＮフラグ付きコピーフリーが放送内容により時々刻々と切り替わるのが特徴である。

ここで、一定期間でもコピーフリーでないコンテンツを放送する放送チャネルの受信は、前記放送の配信を行う事業者との間での認証部により正当な受信装置または受信ユーザであることを認証された場合に行われるように制御できる。この認証の例としては、日本のデジタル衛星放送のＢ−ＣＡＳカード、または米国のＣＡＴＶ放送で使用されるＰＯＤカードなどのセキュリティモジュールによる認証が考えられる。

また、暗号化情報ヘッダの付加制御は、たとえば以下の様に行なう。すなわち、コピーフリーコンテンツを放送する放送チャネルを受信した場合には付加しない。また、一定期間でもコピーフリーでないコンテンツを放送する放送チャネルを受信した場合には付加する。さらに、ＡＶデータが蓄積メディアよりコピーフリータイトルのコンテンツを再生した場合には付加しない。そして、ＡＶデータが蓄積メディアよりコピーフリーでないタイトルのコンテンツを再生した場合には付加する。

以上のように、暗号化情報ヘッダの付加制御を行うことにより、著作権者が設定したＡＶコンテンツのＣＣＩ（コピー制御情報）をネットワーク伝送においても継承して伝えていくことができる。さらに、送信側と受信側で暗号化情報ヘッダの付加制御のルールを揃えることにより異機種間での動作互換性を確保することができる。

ここで、パケット化部２４０６は、送信条件設定管理部２４０３により決定された送信パラメータにより、入力データのパケット化および送信を行なう。

送信条件設定管理部２４０３は、送信キュー制御部２４０７に、送信先アドレスやポート番号などの送信情報、送信に用いるパス情報（ルーティング情報）、送信データの帯域、送信データの送信優先度などの送信条件を与える。

これらのデータは、ＴＣＰ／ＩＰ処理によるパケット化部２４０６およびフレーム化部２４０８で生成するヘッダやペイロードデータなどを設定する。

受信側では、ネットワークより入力する信号がフレーム受信部２４０９でＭＡＣヘッダを元にフィルタリングされ、ＩＰパケットとしてパケット受信部２４１０に入力される。パケット受信部２４１０は、ＩＰパケットヘッダなどの識別によりフィルタリングを行い、ＡＫＥ部２４０５に出力する。これにより送信側のＡＫＥ部と、受信側のＡＫＥ部がネットワークを介して接続されるので、通信プロトコルを介してお互いにメッセージが交換される。すなわち、ＡＫＥ部の設定手順に従い、認証と鍵交換を実行することができる。

送信側と、受信側で認証と鍵交換が成立すれば、暗号化したＡＶデータを送信する。
送信側では、入力信号が例えばＭＰＥＧのフルＴＳストリームの場合、そのフルＴＳストリームをＴＳストリーム識別部２４０２に入力し、フルＴＳストリームをパーシャルＴＳストリームに変換する。

そして、変換されたパーシャルＴＳストリームをコンテンツバッファ２４１３に送り暗号化タイミングの調整を行う。

コンテンツバッファ２４１３のパーシャルＴＳ出力を暗号化部２４１４に入力し暗号化を行ない、前述したＥＭＩおよびシード情報（シード情報のすべてのビット、または、Ｏ／Ｅなど一部のビット）などのＡＫＥ情報を暗号化情報ヘッダ付加部２４１５で付加する。

さらに、この信号をパケット化部２４０６に入力し、送信キュー制御部２４０７より与えられる条件を用いてＴＣＰ／ＩＰのヘッダを付加する。パケットの優先伝送制御を行うためには、フレーム化部２４０８において、たとえば、８０２．１Ｑ（ＶＬＡＮ）方式を用いて、ＭＡＣヘッダを付加しイーサネット（登録商標）フレームに変換して、送信フレームとしてネットワークに出力する。ここで、ＭＡＣヘッダ内のＴＣＩ（Ｔａｇ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）内のＰｒｉｏｒｉｔｙ（ユーザ優先度）を高く設定することにより、ネットワーク伝送の優先度を一般のデータよりも高くすることができる。

受信側では、ネットワークより入力する信号がフレーム受信部２４０９でＭＡＣヘッダを元にフィルタリングされ、ＩＰパケットとしてパケット受信部２４１０）入力される。パケット受信部２４１０はパケットヘッダなどの識別によりフィルタリングし、送信条件などの伝送関連データを条件設定部２４１７に出力し、ＡＫＥ関連データをＡＫＥ部２４０５に出力し、ＡＶコンテンツを復号化部２４１８に出力する。復号化部２４１８は、暗号化情報ヘッダの除去と暗号の復号化を行い、復号したＭＰＥＧ−ＴＳ信号を出力する。

なお、条件設定部２４１７には、受信状況を送信側にフィードバックするためのデータが入力され、ＩＰパケットのパケット化部２４０６およびイーサネット（登録商標）フレームのフレーム化部２４０８で生成するヘッダおよびペイロードデータを設定する情報が送信条件設定管理部２４０３にフィードバックされる。

次に、図３０のプロトコルスタックを用い上記手順を補足説明する。図３０の送信側において、まず送信側から受信側へ暗号化されたコンテンツおよびＤＲＭ設定管理部２４０４より与えられるコンテンツの保護モード情報が送信される。受信側は、コンテンツのコピー保護情報の解析を行い、認証方式を決定し、認証要求をパケット送信機器に送る。次に、乱数を発生させ、この乱数を所定の関数に入力し、交換鍵を作成する。交換鍵の情報を所定の関数に入力し、認証鍵を生成する。受信側でも所定の処理により認証鍵の共有を図る。なお、ここで用いる暗号化情報としては、たとえば、送信側の独自情報（機器ＩＤ、機器の認証情報、マックアドレスなど）、秘密鍵、公開鍵、外部から与えられた情報などを１つ以上組み合わせて生成した情報であり、ＤＥＳ方式やＡＥＳ方式など暗号化強度の強い暗号化方式を用いることにより強固な暗号化が可能である。そして、送信側は認証鍵を用いて交換鍵を暗号化して受信側に送り、受信側で交換鍵が復号される。また、交換鍵と初期鍵更新情報を所定の関数に入力し、暗号化鍵を生成する。なお、送信側では暗号鍵を時間的に変化させるために、時間的に変化する鍵更新情報を生成し、受信側に送信する。コンテンツであるＭＰＥＧ−ＴＳは暗号化鍵により暗号化される。そして暗号化されたＭＰＥＧ−ＴＳは、ＡＶデータとしてＴＣＰ（またはＵＤＰ）パケットのペイロードとしてＴＣＰパケットが生成される。さらにこのＴＣＰパケットはＩＰパケットのデータペイロードとして使用され、ＩＰパケットが生成される。さらにこのＩＰパケットはＭＡＣフレームのペイロードデータとして使用され、イーサネット（登録商標）ＭＡＣフレームが生成される。なお、ＭＡＣとしてはイーサネット（登録商標）であるＩＥＥＥ８０２．３だけでなく、無線ＬＡＮ規格のＩＥＥＥ８０２．１１のＭＡＣにも適用できる。

さて、イーサネット（登録商標）ＭＡＣフレームは、イーサネット（登録商標）上を送信側から受信側へ伝送される。受信側で所定の手順に従って復号鍵が生成される。そして、受信したイーサネット（登録商標）ＭＡＣフレームからＩＰパケットがフィルタリングされる。さらにＩＰパケットからＴＣＰ（またはＵＤＰ）パケットが抜き出される。そして、ＴＣＰ（またはＵＤＰ）パケットからＡＶデータが抜き出され、交換鍵と鍵変更情報より復元された復号鍵により、ＭＰＥＧ−ＴＳ（コンテンツ）が復号され出力される。

以上、ＭＰＥＧ−ＴＳ信号などのＡＶストリームがパケット送信機器で暗号化され、ＩＰパケットでネットワークにより伝送され、パケット受信機器で元の信号に復号される。

なお、送信キュー制御部２４０７は、第１キューとしてのＡＶデータキュー、および、第２キューとしての一般データキューを具備している。

図２８に示されるように、ＡＫＥ部２４０５に対してＡＫＥ設定情報が入力され、このＡＫＥ設定情報に関連した情報（たとえば、コピー保護情報と暗号化鍵変更情報）、および、送信データの種別、送信先アドレスやポート番号の情報、送信に用いるパス情報（ルーティング情報）、送信データの帯域、送信データの送信優先度などの送信条件の設定情報と、送信部（ローカル）と受信部（リモート）における機器の管理制御データと、受信状況を送信側にフィードバックするためのデータがパケット化部２４０６に入力され、パケット化部２４０６においてＴＣＰ／ＩＰ処理がなされ、第１キューに入力される。

また、送信側では、ＭＰＥＧ−ＴＳ信号が暗号化部２４１４に入力され、ＭＰＥＧ−ＴＳ信号が暗号化された後、この暗号化されたＭＰＥＧ−ＴＳ信号がパケット化部２４０６に入力され、パケット化部２４０６においてＴＣＰ／ＩＰ処理がなされ、ＡＶデータキューに出力される。

送信キュー制御部２４０７は、第１キューと第２キューにデータが存在する場合、どちらのデータを優先して出力するかの制御を行なう。通常状態では、一般データよりもＭＰＥＧ−ＴＳなどのコンテンツデータを優先制御して出力する。たとえば、パケット送受信機器間でＭＰＥＧ−ＴＳを低レイテンシ（低遅延）で伝送する場合には、ＭＰＥＧ−ＴＳ用バッファも小さくなるため、オーバーフローが発生しやすい。送信側でＭＰＥＧ−ＴＳバッファがオーバーフローしそうになった場合、あるいは、受信側からフィードバックされた情報を参照して受信側のＭＰＥＧ−ＴＳのバッファがアンダーフローしそうになったことが判明した場合には、ＭＰＥＧ−ＴＳデータを優先出力する様に第２キューの優先度を更に適応的に上げることにより、これらバッファ破綻を回避できる。

ただし、受信側機器（リモート機器）の再生、停止などの機器制御応答をより速くするには、第１キューの優先度を適応的に上げればよいが、これでは前述したＭＰＥＧ−ＴＳバッファのオーバーフローまたはアンダーフローが発生する可能性がある。

バッファのオーバーフローやアンダーフローを避け、かつ、受信側機器（リモート機器）の再生、停止などの機器制御応答をより速くする方法として、機器制御用パケットだけはキューを経由せずに直接フレーム化部に出力することにより、迅速な制御応答が実現される。あるいは、機器制御用パケットに対して第３キューを新たに用意する方法により、迅速な制御応答が実現される。

また、図２８のＡＫＥ部２４０５に対してＡＫＥ設定情報が入力され、このＡＫＥ設定情報に関連した情報（たとえば、コピー保護情報と暗号化鍵変更情報）、および、送信データの種別、送信先アドレスやポート番号の情報、送信に用いるパス情報（ルーティング情報）、送信データの帯域、送信データの送信優先度などの送信条件の設定情報と、送信部（ローカル）と受信部（リモート）における機器の管理制御データと、受信状況を送信側にフィードバックするためのデータがパケット化部２４０６に入力されプロセッサを用いた内部のソフトウェア処理でＴＣＰ／ＩＰ処理をされ、一般データキューに入力される。

送信側ではＭＰＥＧ−ＴＳ信号が暗号化部２４１４に入力され、ＭＰＥＧ−ＴＳ信号が暗号化された後、この暗号化されたＭＰＥＧ−ＴＳ信号がパケット化部２４０６に入力され、内部のハードウェア処理によりＵＤＰ／ＩＰの処理をされ、ＡＶデータキューに入力される。

送信キュー制御部２４０７は、第１キューであるＡＶデータキューと第２キューである一般データキューの双方にデータが存在する場合、前述の実施の形態７と同様に、２つのキューからのデータ出力に関して優先制御を行なう。

さて、受信側では、ネットワークより入力する信号がフレーム受信部２４０９でＭＡＣヘッダを元にＩＰパケットがフィルタリングされる。ここでは、ソースの上記パケット化部２４０６出力されたＩＰパケットが、シンクのパケット受信部２４１０に入力される。一般データキューで受信されたパケットは、プロセッサを用いたソフトウェア処理でＴＣＰ／ＩＰの受信処理が行われ、ＡＫＥ部２４０５または条件設定部２４１７に出力される。また、ＡＶデータキューで受信したパケットは、ハードウェア処理によりＵＤＰ／ＩＰの受信処理が行われ、暗号化されたＡＶデータは復号化部２４１８に入力され、暗号復号を行った後にＭＰＥＧ−ＴＳが出力される。

なお、送信側から受信側への、ＥＭＩおよびシード情報の伝送方法としては、たとえば、専用の別パケットを生成して伝送することも可能であり、暗号鍵復元がさらに困難となり、コンテンツの盗聴、漏洩をより困難にできる。インターネットなど公衆網において、リアルタイムに伝送されるＡＶデータの暗号化パラメータが変化させたり、別パケットで送ると、コンテンツの盗聴、漏洩をより困難にすることができる。管理制御データに関しては、ソフトウェア処理によりＴＣＰパケットが生成され、ＩＰパケット化される。

また、ＡＫＥ部２４０５は、送信側と受信側との間で認証を実行する認証実行モードと認証を実行しない認証不実行モードとを持ち、暗号化部２４１４は、ＡＫＥ部２４０５が認証実行モード及び認証不実行モードのいずれであっても、ＤＲＭ設定管理部２４０４より与えられるコンテンツの保護モード情報に基づく暗号化情報ヘッダの付加を行う。

さて、イーサネット（登録商標）ＭＡＣフレームは、イーサネット（登録商標）上を送信側から受信側へ伝送される。受信側で所定の手順に従って復号鍵を生成する。そして、受信したイーサネット（登録商標）ＭＡＣフレームからＩＰパケットがフィルタリングされる。さらにＩＰパケットからＵＤＰパケットが抜き出され、ＵＤＰパケットからＡＶデータが抜き出され、交換鍵とシード情報より復元された復号鍵Ｋｃにより、ＭＰＥＧ−ＴＳ（コンテンツ）が復号され出力される。

以上により、パケット送受信機器間でＭＰＥＧ−ＴＳ信号を暗号化してリアルタイム伝送が可能となるだけでなく、第２のパケット化部がハードウェアで構成されているため、本質的にソフトウェア処理に起因する送信パケットの送り残しや受信パケットの取りこぼしが発生しない。これにより、全ての優先データパケットが完全に送信され、リアルタイム性の保証された高品質映像の伝送が可能となる。また、一般データは一時的にバッファ部に蓄積され、優先データ伝送が優先して行なわれる中で間欠的に伝送される。また、データ量の小さい第１のパケット化部はマイコンなど安価なプロセッサで処理できる。

さらに、ハードウェア処理により、受信処理においても、イーサネット（登録商標）フレームを受信して、３層のＩＰヘッダ、４層のＵＤＰヘッダを同時に検査することもできる。ＭＰＥＧ−ＴＳパケットと一般データパケットを分離し、ＭＰＥＧ−ＴＳパケットの処理をハードウェアで行うことにより、受信フレームの取りこぼしが発生せず、リアルタイム性が保証された高品質な受信ができる。

パケットの送信タイミング、あるいは２つの送信データキューからのデータ送信割合をソフトウェアではなくハードウェアで制御するとクロック単位で完全な送出制御が可能である。これにより全ての優先パケットが完全に送信され、リアルタイム性の保証された高品質の伝送が可能となる。また、出力パケットのシェイピングもクロック単位で正確に行われるため、初段のルータ、またはスイッチングハブでのパケット廃棄の発生確率が非常に少ない高品質な通信が可能となる。

以上により、パケット送受信機器間でＭＰＥＧ−ＴＳ信号をＤＴＣＰ方式により暗号化してリアルタイム伝送が可能となるだけでなく、第２のパケット化部がハードウェアで構成されているため、本質的にソフトウェア処理に起因する送信パケットの送り残しや受信パケットの取りこぼしが発生しない。また、データ量の小さい第１のパケット化部はマイコンなど安価なプロセッサで処理できる。

なお、パケット送受信部２４０１は、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報の少なくとも１つとからなる制御認証情報を、ＡＶデータのプログラム単位毎にアクセス位置を指定するＵＲＩ情報、または、Ｑｕｅｒｙにより拡張されたＵＲＩ情報により、プログラムのリストとして、パケット受信装置に通知してもよい。

同様に、パケット送受信部２４０１は、受信側（シンク）からプログラムリストの送信要求を受けると、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報の少なくとも１つとからなる制御認証情報を、ＡＶデータのプログラム単位毎にアクセス位置を指定するＵＲＩ情報、または、Ｑｕｅｒｙにより拡張されたＵＲＩ情報により、プログラムのリストとして、パケット受信装置に通知してもよい。

さらに、パケット送受信部２４０１は、ＡＶデータの単位プログラムのコピー制御情報がコピー制御を行わない旨を示す場合に、ＡＶデータのデータフォーマット情報を表す第１のＭＩＭＥ−Ｔｙｐｅと、ＡＶデータに間欠的に暗号化情報ヘッダを付加したデータのデータフォーマット情報を表す第２のＭＩＭＥ−Ｔｙｐｅの２つのＭＩＭＥ−Ｔｙｐｅを生成し、ＡＶデータのプログラム単位毎にアクセス位置を指定する２つの拡張ＵＲＩ情報をパケット受信装置に提示してもよい。Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ（ＵＰｎＰ）で規定されているｒｅｓを用いて、ＡＶデータの単位プログラム（ｉｔｅｍに相当）各々をリソースとして論理記述できる。たとえば、ＵＰｎＰのＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）を用いる場合、受信側（クライアント）は送信側（サーバ）内で論理的なｄｉｒｅｃｔｏｒｙ構造にマッピングされているＣｏｎｔａｉｎｅｒに属するｉｔｅｍとして特定のＡＶデータの単位プログラムをｂｒｏｗｓすることにより探しだすことができる。ここで、上述した２つのＭＩＭＥ−Ｔｙｐｅに対するｒｅｓ表現としては、ｒｅｓのアトリビュート（ａｔｔｒｉｂｕｔｅ）であるｐｒｏｔｏｃｏｌＩｎｆｏを用いて、たとえば、ｐｒｏｔｏｃｏｌＩｎｆｏの第３フィールドに各々のＭＩＭＥ−Ｔｙｐｅを挿入することにより、利用可能なリソースとしてのｒｅｓを識別することができる。

コンテンツの位置を表わすＵＲＩ情報は、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ（ＵＰｎＰ）におけるｒｅｓのＵＲＩ指定に使用し、前記２つのＭＩＭＥ−Ｔｙｐｅは前記ｒｅｓのａｔｔｒｉｂｕｔｅであるｐｒｏｔｏｃｏｌＩｎｆｏの第３フィールドに挿入することによりコンテンツの識別を行う。

たとえば、＜ｒｅｓ ｐｒｏｔｏｃｏｌＩｎｆｏ＝"第１フィールド"："第２フィールド"："第３フィールド"："第４フィールド"＞"ｒｅｓのＵＲＩ"＜／ｒｅｓ＞における"第３フィールド"に異なるＭＩＭＥ−Ｔｙｐｅを挿入することにより、他のフィールドが同じでも、コンテンツのリソースであるｒｅｓの識別が可能となる。

なお、ＵＰｎＰ−ＡＶにおけるｐｒｏｔｏｃｏｌＩｎｆｏの定義としては、"第１フィールド"が伝送プロトコル、"第２フィールド"がネットワーク、"第３フィールド"がコンテンツのフォーマット、また、"第４フィールド"が付加情報である。

たとえば、"第１フィールド"が"ｈｔｔｐ−ｇｅｔ"の場合、"第２フィールド"は"＊"、"第３フィールド"は"ＭＩＭＥ−Ｔｙｐｅ"、また、"第４フィールド"は"付加情報"となる。また、"第１フィールド"が"ｒｔｐ"の場合、"第２フィールド"は"＊"、"第３フィールド"は"ＲＴＰのペイロードタイプ"、また、"第４フィールド"は"付加情報"などとして使用できる。

ｐｒｏｔｏｃｏｌＩｎｆｏを用いた伝送制御の場合、その第４フィールド"は"付加情報"として新たな仕様を決めることにより、よりきめ細かい伝送制御が実現できる。

また、パケット送受信部２４０１は、マルチキャスト伝送でパケットを伝送する場合、これら２つのｒｅｓで表現された信号、すなわち、暗号化情報ヘッダが付加されたパケットと付加されていないパケットの両方を出力してもよい。この場合、受信側で受信するｒｅｓを適宜選択する。

（実施の形態８）
次に、本発明の実施の形態８について説明する。本実施の形態におけるパケット送受信部の構成は、基本的には、図２８に示された実施の形態７と同じである。以下、実施の形態７と同じ部分の説明は省略し、異なる部分のみを説明する。

本実施の形態では、上記実施の形態７において、ライブで放送されているコンテンツをＨＴＴＰ／ＲＴＰヘッダ付加部２４１６および、パケット化部２４０６においてＨＴＴＰのチャンク伝送方式で伝送する様に伝送プロトコルを設定する。なお、チャンク伝送方式は、ＨＴＴＰで規定されている伝送方式のひとつで、受信者と送信者との間で伝送データのサイズが決定されたチャンク（かたまりの）データによる伝送をいう。

これにより、従来は、前記暗号化に関して付加するヘッダ長や伝送コンテンツ長ＨＴＴＰリクエストの度に、受信側（クライアント）で計算していたが、この計算の必要がなくなり、受信側の処理を軽くできる。特に、ライブ放送を受信している場合に、伝送側および受信側の処理負荷を軽減できる。

ＨＴＴＰのペイロードデータ長としては、暗号化される伝送ペイロードの暗号化情報ヘッダとＴＳの整数倍であり、送信側で都合のよい値に設定することができる。このチャンク伝送時にはＴＣＰのコネックションは永続的接続モード（ＨＴＴＰのｖｅｒｓｉｏｎが１．０の場合、Ｋｅｅｐ Ａｌｉｖｅ設定。ＨＴＴＰのｖｅｒｓｉｏｎ ２．０の場合はＰｅｒｓｉｓｔｅｎｔ ｃｏｎｎｅｃｔｉｏｎ）されていると、ＴＣＰコネクションの切断、確立をコンテンンツ伝送中にＴＣＰトランザクション毎に頻繁に行う必要がなくなり効率のよいＡＶ伝送を行うことができる。よって、パケット送受信部は、ＡＶデータの伝送プロトコルとして、ＴＣＰと決定された場合は、ＴＣＰコネクションを永続的接続にしてＡＶデータの伝送を効率的に安定して実現できる。

（実施の形態９）
次に、本発明の実施の形態９について説明する。図３１は、本実施の形態におけるパケット送受信部２４０１ａの構成を示すブロック図である。このパケット送受信部２４０１ａは、図２８に示された実施の形態７のパケット送受信部２４０１の構成に加えて、蓄積部２７０１を備える。以下、実施の形態７と同じ部分の説明は省略し、異なる部分のみを説明する。

このパケット送受信部２４０１ａは、ＴＳストリーム識別部２４０２に接続された蓄積部２７０１を具備する。ここで、蓄積部２７０１は、ハードディスクや光ディスクである。本実施の形態において、このパケット送受信部２４０１ａは、ハードディスクや光ディスクなどに蓄積されたＭＰＥＧ−ＴＳデータをＨＴＴＰのレンジリクエストを用いて伝送する。

このレンジリクエストは、蓄積部２７０１に蓄積されたＭＰＥＧ−ＴＳファイルとペアになっているファイル中におけるＩフレーム位置情報を含んだファイルである。例えば、ＤＶＤ−ＶＲ方式ではＩＦＯファイルと呼ばれているものである。このＩＦＯファイルと同等のＩフレーム位置情報を持ってファイルを用いることにより、早送り、巻き戻し、スロー再生などの特殊再生を効率よく簡単に実現できる。

本発明で用いる入力データの適用範囲として、サーバ型放送や各社の異なるＤＲＭ方式など一般のＤＲＭ対応のＡＶコンテンツをＤＴＣＰ−ＩＰを用いて伝送することが可能となる。

なお、ＨＴＴＰによる伝送とＲＴＰによる伝送を切り替えてＡＶデータを伝送してもよい。そのとき、ＨＴＴＰによる伝送として、ソースからの出力がライブ放送の受信信号またはライブ放送の受信チャネルの切り替えまたは蓄積されたプログラム選択時の再生信号の場合には、チャンク伝送を行い、プログラム選択後の蓄積メディアから再生されたプログラムからの再生信号の場合には、レンジリクエストを用いて再生を切替えて行っても実現できる。

（実施の形態１０）
次に、本発明の実施の形態１０について説明する。図３２は、本実施の形態におけるパケット送受信部２４０１ｂの構成を示すブロック図である。このパケット送受信部２４０１ｂは、図３１に示された実施の形態９のパケット送受信部２４０１ａの構成に加えて、Ｉフレーム位置情報生成部２８０１を備える。以下、実施の形態９と同じ部分の説明は省略し、異なる部分のみを説明する。

蓄積部２７０１において、ハードディスクや光ディスクなどに蓄積された異なる蓄積フォーマットのコンテンツの場合、クライアント（シンク）は全ての異なるコンテンツのＩフレーム位置データを格納したファイルを理解しなければならない。そこで、本実施の形態では、フォーマット数が多くなると、これは受信側にとって大きな負担となるため、送信側で異なるＩフレーム位置情報より、共通のＩフレーム位置情報生成部２８０１で共通のＩフレーム位置情報を生成する。これにより、各社のＨＤＤ記録フォーマット、ＤＶＤ−ＶＲ方式、あるいはＢＤ方式など異なる蓄積フォーマットであっても、簡単に、早送り、巻き戻し、スロー再生などの特殊再生することが実現される。

このパケット化において、ＨＴＴＰは受信部からのレンジリクエストまたはデータ取得コマンドを受けて前記ＡＶデータまたは前記暗号化モード情報のうち少なくとも一方を含んだペイロードデータを伝送する。このレンジリクエストまたはデータ取得コマンドは、前記送信側における前記ＡＶデータがＭＰＥＧの場合、ＭＰＥＧストリームにおける不連続発生連続性情報、前記ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報、或るＩピクチャから次のＩピクチャの間に存在するＰピクチャとＢピクチャの各個数または合計個数の内、少なくとも１つの情報を参照して実行する。ここで、ＭＰＥＧストリームにおける不連続発生連続性情報とは、ＡＲＩＢ規格、ＡＲＩＢ−ＴＲ−Ｂ１４またはＡＲＩＢ−ＴＲ−Ｂ１４の第２編に記載されているＤＩＴ情報を元に生成することができる。このストリームの不連続点とは、たとえば、ＭＰＥＧのパーシャルＴＳの場合、ＭＰＥＧ−ＴＳストリームのシステムタイムベースの不連続が発生する点、たとえば、ＰＣＲが不連続になる点、または、パーシャルＴＳを構成するパケットの内のどれか１つのトランスポートパケットヘッダのｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒの不連続が発生する点のことである。

また、ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報は、前記ＡＶデータが複数の異なるファーマットであった場合にもオリジナルに持っている複数のＩピクチャまたはＰピクチャまたはＢピクチャの位置情報、前記ＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの時刻情報より、複数の異なるファーマット間で共通なＩピクチャまたはＰピクチャまたはＢピクチャ位置情報を生成し、この共通のＩピクチャまたはＰピクチャまたはＢピクチャ位置情報を用いて前記ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報、時刻情報の参照情報とする。これにより、たとえばＨＤＤに、異なる記録フォーマットで記録されているＭＰＥＧ−ＴＳファイルがあっても、リモート端末からは共通のＩまたはＰまたはＢピクチャの位置情報や時間情報で特定のピクチャに直接アクセスできるという大きなメリットがある。

たとえば、図３３に示される一例のように、パーシャルＴＳを記録したＨＤＤやＢＤディスクなどから、ＩまたはＰまたはＢピクチャの連続性およびファイル内での位置情報などを統一した「ピクチャ情報ファイル」を読み出す。ネットワークを介して離れた場所に存在する端末からは、この統一されたピクチャ情報ファイルをバイト位置や時刻情報（ｔｉｍｅｓｔａｍｐ）で参照することにより、異なるＴＳ記録フォーマットでも各ピクチャ位置をきめ細かに参照することができる。

図３３において、"ｄｉｓｃｏｎｔ"はパーシャルＴＳの不連続点を示す１ビットのフラグである。たとえば、この値が"０"の時はパーシャルＴＳは連続であり、"１"の時は不連続を意味する。また、"ＩＰＢフラグ"は、２ビットのＩピクチャ、Ｐピクチャ、Ｂピクチャの識別フラグであり、その値が"００"の時はＩピクチャ、"０１"の時はＰピクチャ、"１０"の時はＢピクチャであることを示す。ここで、Ｉピクチャの場合は必ず記述が必要で、ＰまたはＢピクチャの場合は、オプションとし、必ずしも記述しなくてもよい。また、"Ｂｙｔｅ＿ｐｏｓｉｔｉｏｎ"は、Ｉピクチャ、Ｐピクチャ、およびＢピクチャの先頭のファイルにおけるバイト位置を３２ｂｉｔで示す。さらに、"ＰＢ＿ｎｕｍｂｅｒ"は、或るＩピクチャから次のＩピクチャまでの間に存在するＰピクチャとＢピクチャの合計数を５ビットで示す。"Ｔｉｍｅｓｔａｍｐ"は、Ｉピクチャ、Ｐピクチャ、Ｂピクチャの時刻情報で、それぞれのＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャを構成するタイムスタンプ付きＴＳ列の先頭など特定位置のＴＳのタイムスタンプ値を４０ビットに変換して使用する。それぞれのパラメータ、フラグの値の定義は、前記の組合せに限定されない。

以上にように、本実施の形態によれば、きめ細かやで綺麗なスロー再生や高速再生などのトリック再生が実現される。なお、このピクチャ情報ファイルはリモート端末からローカル端末内の異なるファーマットで記録されたＭＰＥＧ−ＴＳファイル内のピクチャ位置を共通のファイル形式で見せることができるフィルタ機能として考えることができる。すなわち、独自のファイル形式でＭＰＥＧ−ＴＳを記録したＡＶデータファイルとその関連情報ファイルより、共通のピクチャ情報ファイルを生成することができる。

また、本実施の形態により、ＡＶコンテンツをＡＫＥや暗号処理を実装しない送受信装置による実装の場合にも、ＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャに効率よくアクセスできるという効果が奏される。

さらに、本発明の別機能について説明する。コンテンツバッファ２４１３において、ＭＰＥＧ−ＴＳ信号に、たとえばリードソロモン方式のエラー訂正符号を付加した後、暗号化部２４１４で暗号化する。これにより、パケット送受信機器間でＭＰＥＧ−ＴＳ信号をＤＴＣＰ方式により暗号化し、さらにエラー訂正符号を付加しリアルタイム伝送が可能となる。ここで、ＭＰＥＧ−ＴＳのヘッダ付加および伝送処理のパケット化部をハードウェアで構成すると、本質的にソフトウェア処理に起因する送信パケットの送り残しや受信パケットの取りこぼしが発生しない。また、データ量の小さい一般データのパケット化はマイコンなど安価なプロセッサで処理できる。

なお、上述した実施の形態においては、一般のＩＰネットワークなどパケットの順序性が保証されていない通信網で伝送する場合には、パケットにシーケンス番号を付加して送信し、受信側でシーケンス番号を用いて順序性の保証を行ってもよい。この順序性の保証は、ＯＳＩモデルの第４層以上、すなわち、ＲＴＰやビデオ信号処理などで行なうことができる。

また、送信側でハードウェア処理され伝送されたＡＶ信号のパケットが、ネットワークでフラグメントされないため対策ができる。すなわち、送信側において、あらかじめアプリケーションレベルの処理で、通信網においてフラグメントされない最大サイズ（ＭＴＵ）を検査し、それ以下のパケットサイズで伝送すればよい。あるいは、ＲＦＣの規格では全ての端末は５７６バイトのサイズのＩＰパケットを扱えなければならないと規定されているので、ルータ等の多くのネットワーク機器はこれ以下のＩＰパケットではフラグメントが起こらない。したがってＩＰパケットのサイズが５７６バイト以下となるように、送信側でハードウェア処理されるＡＶ信号のパケットサイズを調整すればよい。なお、送信側でハードウェア処理されるＡＶ信号のパケットにフラグメントが起こらない場合は、受信したパケットがフラグメントされていれば全て一般パケットとして処理すればよい。また、イーサネット（登録商標）のＩＰパケットの最大値を越えた場合は送信端末でフラグメントしなければ行けないので、優先パケットのフラグメントを起こさせないためにはＩＰパケットの最大値以下でなければならないことは言うまでもない。

また、通信網においてフラグメントが起こる確率が非常に低い場合は、送信側でハードウェア処理され伝送されたＡＶ信号のパケットのＩＰヘッダにフラグメント禁止のフラグを立てて伝送することにより、ルータがフラグメントせざるを得ない状態ではＩＰパケットを廃棄させることにより、受信端末のフラグメント処理負荷を軽減してもよい。この場合、非常に少数のパケットは損失となるが、受信側で誤り訂正あるいは誤り修整を行うことで通信品質を補償することができる。

さらに、上記実施の形態では、通信網プロトコルとしてイーサネット（登録商標）を例としたが、本発明は、この限りではない。

また、ビデオ信号処理の例として、ＭＰＥＧ−ＴＳを用いたが、これに限らず本発明で用いる入力データの適用範囲としては、ＭＰＥＧ１／２／４などＭＰＥＧ−ＴＳストリーム（ＩＳＯ／ＩＥＣ１３８１８）、ＤＶ（ＩＥＣ６１８３４、ＩＥＣ６１８８３）、 ＳＭＰＴＥ３１４Ｍ（ＤＶ−ｂａｓｅｄ）、ＳＭＰＴＥ２５９Ｍ（ＳＤＩ）、ＳＭＰＴＥ３０５Ｍ（ＳＤＴＩ）、ＳＭＰＴＥ２９２Ｍ（ＨＤ−ＳＤＩ）等で規格化されているストリ−ムを含んだあらゆる映像、音声に関するストリームまでも適用可能である。映像や音声のデータレートは、ＣＢＲ（ｃｏｎｓｔａｎｔ ｂｉｔ ｒａｔｅ）に限るものではない。さらに、映像や音声だけでなく、一般のリアルタイムデータ、あるいは優先的に送受信を行うデータであればどのようなものでも本発明から排除するものではない。

また、本発明で用いる入力データの適用範囲として、データのファイル転送にも適用可能である。ファイル転送の場合、送受信端末の処理能力と送受信端末間の伝播遅延時間の関係により、一定の条件化でリアルタイムより高速の伝送も可能である。

また、本発明で用いる入力データの適用範囲として、サーバ型放送や各社の異なるＤＲＭ方式など一般のＤＲＭ対応のＡＶコンテンツをＤＴＣＰ−ＩＰを用いて伝送することが可能となる。

また、上記実施の形態において、パケット送受信装置は、Ｎを２以上の整数とした場合、ＵＤＰまたはＴＣＰのＮ個のポートを用いて、ＡＶデータにより構成されるＮ個のプログラムを前記Ｎ個のポートのそれぞれに割り当てて伝送してもよい。このとき、Ｎ個のポートのそれぞれに割り当てるＮ個のプログラムは、それぞれ、ソースに内蔵された放送受信チューナまたは蓄積メディアデバイスをＵＰｎＰ手段のコンテナ形式で表現し、また、放送受信チャネルまたは蓄積プログラムをＵＰｎＰ手段のｉｔｅｍ形式で表現し、それぞれのｉｔｅｍ（リソースとしてのｒｅｓとなる）の存在位置をＵＲＩ、また伝送プロトコルや属性情報をＵＰｎＰのｐｒｏｔｏｃｏｌＩｎｆｏを用いたｒｅｓ表現で表わし、複数プログラムの複数クライアントへの同時伝送など、きめ細かい伝送システムを実現することができる。

また、放送受信の場合、送信側におけるＮ個のポートのそれぞれに割り当てるＮ個のプログラム（ｒｅｓ）のソースからシンクへの伝送ストリームが複数存在する場合に、各々のストリームをＵＰｎＰのｐｒｏｐｅｒｔｙ形式で表わし、特定の伝送ストリームのｐｒｏｐｅｒｔｙのａｔｔｒｉｂｕｔｅとして、「チューナのコンテナの種別、チューナのコンテナ種別ごとのチューナＩＤ、チューナで選局されたチャネルＩＤ、伝送ストリームの他クライアントとの共有・横取りに関する利用可否情報、ストリームを伝送するトランスポート層が使用するＴＣＰまたはＲＴＰのポート番号、シンクにおけるＵＰｎＰ−ＡＶ手段のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがソースにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ手段のｃｏｎｎｅｃｔｉｏｎＩＤ、ソースにおけるＵＰｎＰ−ＡＶ手段のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがシンクにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶのｃｏｎｎｅｃｔｉｏｎＩＤ」のうち、いずれかを含めることにより、受信側（クライアント、シンク）から送信側（サーバ、ソース）内のチューナのチャネル選局を行なう時に、伝送ストリームのｐｒｏｐｅｒｔｙおよびそのａｔｔｒｉｂｕｔｅを参照することにより、伝送ストリームに空きあるか無いか、およびどのチューナの、どのチャネルが選局されているかを判別することができる。

たとえば、放送受信の場合のＵＰｎＰ−ＡＶコンテナ構造として、＜ｒｏｏｔ＞下に、チューナーのコンテナを配置する。コンテナ種別としては、地上デジタル、ＢＳデジタル、１１０度広帯域ＣＳデジタルなどの放送システム別、各々チューナコンテナを割り当てる。この場合、各チューナーコンテナの下にｉｔｅｍとして各放送システムのチャンネルを割り当てる。ＵＰｎＰのＣＤＳのｓｅｒｃｈやｂｒｏｗｓコマンドを用いて、受信側から送信側のチューナコンテナ、およびチューナコンテナ内のチャンネルｉｔｅｍを認識することができる。チャンネルとしてのｉｔｅｍは放送局より送信される付属情報を持つ。

同様に、蓄積コンテンツの再生の場合、送信側におけるＮ個のポートのそれぞれに割り当てるＮ個のプログラムのソースからシンクへの伝送ストリームが複数存在する場合に、ＵＰｎＰのｐｒｏｐｅｒｔｙ形式で表わし、特定の伝送ストリームのｐｒｏｐｅｒｔｙのａｔｔｒｉｂｕｔｅとして、「蓄積メディアデバイスのコンテナの種別、蓄積メディアデバイスのコンテナ種別ごとの蓄積メディアデバイスＩＤ、蓄積メディアデバイスで選択されたプログラムＩＤ、伝送ストリームの共有を含む利用可否情報、ストリームを伝送するトランスポート層が使用するＴＣＰまたはＲＴＰのポート番号、シンクにおけるＵＰｎＰ−ＡＶ手段のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがソースにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ手段のｃｏｎｎｅｃｔｉｏｎＩＤ、ソースにおけるＵＰｎＰ−ＡＶ手段のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがシンクにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ手段のｃｏｎｎｅｃｔｉｏｎＩＤ」のうち、いずれかを含めることにより、シンクがソース内の蓄積メディアデバイスのプログラム選択を行なう時に、伝送ストリームのｐｒｏｐｅｒｔｙおよびそのａｔｔｒｉｂｕｔｅを参照することにより、伝送ストリームに空きあるか無いか、およびどの蓄積メディアデバイスのどのプログラムが選択されているかなど判別することができる。

たとえば、蓄積・記録デバイスが、ハードディスクドライブ（ＨＤＤ）、ＤＶＤ−ＲＡＭドライブ、ＢＤドライブの場合のＵＰｎＰ−ＡＶコンテナ構造として、＜ｒｏｏｔ＞下に、それぞれのコンテナを配置する。コンテナ種別としては、ＨＤＤ、ＤＶＤ−ＲＡＭドライブ、ＢＤドライブなどそれぞれにデバイス別のコンテナを割り当てる。この場合、各コンテナの下にｉｔｅｍとして、蓄積・記録コンテンツをたとえばプログラム単位で割り当てる。これにより、ＵＰｎＰのＣＤＳのｓｅｒｃｈやｂｒｏｗｓコマンドを用いて、受信側から送信側の蓄積・記録デバイスコンテナ、および蓄積・記録デバイスコンテナ内の蓄積・記録コンテンツをたとえばプログラム単位でｉｔｅｍとして認識することができる。蓄積・記録されているｉｔｅｍは記録時に与えられた付属情報を持つ。

また、送信サーバの放送コンテナに所属するｉｔｅｍをクライアントが受信して蓄積する場合、前記放送システム別のチューナコンテナの属性（地上デジタル、ＢＳデジタル、１１０度広帯域ＣＳデジタルなどの放送システムを区別する属性）を利用して、放送システム別のｐｒｏｐｅｒｔｙを生成し、蓄積・記録デバイスに蓄積・記録して生成したｉｔｅｍのｐｒｏｐｅｒｔｙとして保存する。これにより、蓄積・記録デバイスのコンテナが放送システム別でなくても、蓄積・記録デバイスから再生したｉｔｅｍのｐｒｏｐｅｒｔｙを見れば、どの放送システムから放送されたコンテンツであるかを識別することができる。

以上により、放送受信の場合でも蓄積コンテンツの再生の場合でも、新たにサーバ接続するクライアントはサーバの使用状況を理解し、より効率的にコンテンツの選択、伝送を行うことができる。

なお、「ストリームを伝送するトランスポート層が使用するＴＣＰまたはＵＤＰのポート番号」、および、「シンクにおけるＵＰｎＰ−ＡＶ手段のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがソースにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ手段のｃｏｎｎｅｃｔｉｏｎＩＤ、またはソースにおけるＵＰｎＰ−ＡＶ手段のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがシンクにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ手段のｃｏｎｎｅｃｔｉｏｎＩＤ」の論理対により、ＵＰｎＰ−ＡＶ手段と、ＴＣＰまたはＵＤＰを使用するＨＴＴＰまたはＲＴＰを用いるトランスポート手段とを論理的に対応づけることにより、ＣＤＳやＣＭＳ（Ｃｏｎｎｅｃｔｉｏｎ Ｍａｎａｇｅｒ Ｓｅｒｖｉｃｅ）を用いるＵＰｎＰ−ＡＶレイヤとＨＴＴＰ／ＴＣＰ／ＩＰを取り扱うトランスポートレイヤを論理的に１対１に対応させることができるので、コネクションの確立、コンテンツの選択、コンテンツの伝送、コネクションの切断、存在コネクションの管理などの伝送制御をより簡単に実現することが可能となる。また、ＨＴＴＰのリクエストメッセージのメッセージヘッダーの拡張フィールドや、ＨＴＴＰのレスポンスメッセージのメッセージヘッダーの拡張フィールドにＵＰｎＰ−ＡＶ手段のｃｏｎｎｅｃｔｉｏｎＩＤを記述することによりＨＴＴＰプロトコルによる伝送制御手段とＵＰｎＰ−ＡＶ手段と論理的に１対１対応させることができる。

本発明は、パケット送信装置として、例えば、デジタルチュナーやＤＶＤレコーダ等として、特に、デジタル放送やＤＶＤディスクのコピー制限コンテンツをコンテンツの著作権者によって設定されたコピー制御情報を継承しながらＩＰネットワークを用いて違法コピーを回避しつつ安全に伝送するパケット送信装置として、たとえば、一般家庭において、１階の今にあるデジタルチュナーやＤＶＤレコーダから２階の寝室にあるディスプレイに映画などのプレミアムコンテンツを伝送するパケット送信装置として利用することができる。

図１は、従来技術における送受信システムの説明図である。 図２は、従来技術におけるパケット送受信部のブロック図である。 図３は、従来技術における鍵交換にＤＴＣＰ方式を適用する場合のコンテンツ伝送手順の説明図である。 図４は、従来技術における１３９５アイソクロナスパケットの構成例を示す図である。 図５は、本発明を適用するシステムの一例を示す図である。 図６は、本発明のシステムにおける通信手順を示すフローチャートである。 図７は、認証と鍵交換にＤＴＣＰ方式を適用する場合のコンテンツ伝送手順の説明図である。 図８は、イーサネット（登録商標）を用いる一般家庭に本発明を適用した場合の一例の説明図である。 図９は、本発明の実施の形態１におけるパケット送受信部のブロック図である。 図１０は、本発明の実施の形態１におけるプロトコルスタックの説明図である。 図１１は、本発明の実施の形態２におけるパケット送受信部のブロック図である。 図１２は、本発明の実施の形態３におけるパケット送受信部のブロック図である。 図１３は、本発明の実施の形態４におけるパケット送受信部のブロック図である。 図１４は、本発明の実施の形態５におけるパケット送受信部のブロック図である。 図１５は、本発明の実施の形態５におけるプロトコルスタックの説明図である。 図１６は、本発明の実施の形態５におけるＭＰＥＧ−ＴＳのイーサネット（登録商標）フレーム構成仕様の例を示す図である。 図１７は、本発明の実施の形態５の第１および第２の変形例におけるパケット送受信部のブロック図である。 図１８は、本発明の実施の形態５の第１の変形例におけるパケット化部およびパケット受信部の説明図である。 図１９は、本発明の実施の形態５の第１の変形例におけるＤＴＣＰ方式による暗号化コンテンツの伝送手順を示すフローチャートである。 図２０は、本発明の実施の形態５の第２の変形例におけるパケット化部およびパケット受信部の説明図である。 図２１は、本発明の実施の形態５の第２の変形例におけるプロトコルスタックの説明図である。 図２２は、エラー訂正方式がリードソロモン方式である場合の説明図である。 図２３は、エラー訂正方式がパリティ方式である場合の説明図である。 図２４は、本発明の実施の形態６におけるパケット送受信部のブロック図である。 図２５は、本発明の実施の形態６におけるプロトコルスタックの説明図である。 図２６は、本発明の実施の形態６の第１の変形例におけるパケット送受信部のブロック図である。 図２７は、本発明の実施の形態６の第２の変形例におけるパケット送受信部のブロック図である。 図２８は、本発明の実施の形態７および８におけるパケット送受信部のブロック図である。 図２９は、本発明の実施の形態７におけるＤＴＣＰ方式による暗号化コンテンツの伝送手順を示すフローチャートである。 図３０は、本発明の実施の形態７におけるプロトコルスタックの説明図である。 図３１は、本発明の実施の形態９におけるパケット送受信部の構成を示すブロック図である。 図３２は、本発明の実施の形態１０におけるパケット送受信部の構成を示すブロック図である。 図３３は、ピクチャ情報ファイルの構成を示す図である。

符号の説明

１０１ パケット送信機器
１０２ ルータ
１０３ パケット受信機器
４０１、４０１ａ〜４０１ｈ パケット送受信部
４０２ ＡＫＥ部
４０３ パケット化部
４０４ 送信条件設定管理部
４０５ パケット受信部
４０６ 暗号化データ生成部
４０７ 暗号化データ復号部
４０８ 受信条件設定管理部
４０９ 送信パケットのフレーム化部
４１０ フレーム受信部
２４０１、２４０１ａ〜２４０１ｂ パケット送受信部
２４０２ ＴＳストリーム識別部
２４０３ 送信条件設定管理部
２４０４ ＤＲＭ設定管理部
２４０５ ＡＫＥ部
２４０６ パケット化部
２４０７ 暗号化データ復号部
２４０８ フレーム化部
２４０９ フレーム受信部
２４１０ パケット受信部
２４１１ ＤＲＭコンテンツ購入決済部
２４１２ コンテンツメタ情報
２４１３ コンテンツバッファ
２４１４ 暗号化部
２４１５ 暗号化情報ヘッダ付加部
２４１６ ＨＴＴＰ／ＲＴＰヘッダ付加部
２４１７ 条件設定部
２４１８ 復号化部
２７０１ 蓄積部

Claims (41)

1. パケット受信装置にパケットデータを送信するパケット送信装置であって、
   ＡＶデータが入力される端子を示す入力端子情報、前記ＡＶデータのデータフォーマットを示すデータフォーマット情報及び前記ＡＶデータの属性を示す属性情報を含むＡＶデータ情報を取得するＡＶデータ情報取得手段と、
   前記ＡＶデータ及び非ＡＶデータの入力を受け付けるデータ入力手段と、
   前記非ＡＶデータまたは前記ＡＶデータより、前記ＡＶデータの課金情報、再生制御情報及びコピー制御情報の少なくとも１つの情報を抽出し、抽出した情報から、前記ＡＶデータを送信する際の条件となる暗号化モードを示す暗号化モード情報を生成する送信条件設定管理手段と、
   前記入力端子情報、前記データフォーマット情報及び前記属性情報を組み合わせて決定される送信条件に基づいて、前記データ入力手段より入力された前記ＡＶデータを暗号化し、暗号化された前記ＡＶデータに対して前記暗号化モード情報に基づく暗号化情報ヘッダを付加することによって暗号化データを生成する暗号化データ生成手段と、
   前記暗号化データ生成手段により生成された暗号化データに対して、パケットヘッダを付加することによってパケットを生成するパケット化手段と、
   前記ＡＶデータの前記パケット送信装置内でのアクセス位置を示すＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）情報または拡張ＵＲＩ情報を用いて、前記パケット受信装置との間で前記ＡＶデータの暗号化または復号化のための認証処理を行う認証手段と、
   前記入力端子情報、前記属性情報及び前記パケット受信装置より指定される送信モードを示す情報の少なくとも１つを用いて、前記パケット送信装置と前記パケット受信装置の間での前記ＡＶデータの伝送プロトコルを決定する伝送プロトコル決定手段と、
   前記認証手段によって前記パケット受信装置との認証処理が完了した後に、前記伝送プロトコル決定手段によって決定された伝送プロトコルに従って、前記パケット化手段によって生成された、暗号化データを含むパケットを前記パケット受信装置に伝送する伝送手段と
   を備えることを特徴とするパケット送信装置。
2. 前記パケット送信装置はさらに、前記送信条件設定管理手段より入力される前記課金情報、前記再生制御情報又は前記コピー制御情報に基づいて、前記ＡＶデータの再生制御、出力制御又はコピー制御を行うための課金情報、コピー制御情報、有効期限情報、有効再生回数情報の少なくとも１つを生成し、生成した情報を認証情報として前記認証手段に通知する著作権管理手段を備え、
   前記認証手段は、前記著作権管理手段から通知された認証情報に基づいて、前記パケット受信装置との間で認証処理を行うことで、前記ＡＶデータの前記パケット受信装置における再生制御、出力制御又はコピー制御を行う
   ことを特徴とする請求項１記載のパケット送信装置。
3. 前記パケット送信装置はさらに、前記著作権管理手段による制御の下で、前記課金情報、前記再生制御情報又は前記コピー制御情報に基づいて、前記パケット受信装置との間で、著作権保護の対象となるコンテンツの購入決済を行うコンテンツ購入決済手段を備える
   ことを特徴とする請求項２記載のパケット送信装置。
4. 前記認証手段は、前記パケット送信装置と前記パケット受信装置が規定の条件を備えていることを検証することによって認証処理を実行し、認証処理後に前記パケット送信装置と前記パケット受信装置とで暗号化鍵を共有し、前記入力端子情報と、前記データフォーマット情報と、前記属性情報と、前記課金情報、前記コピー制御情報、前記有効期限情報及び前記有効再生回数情報より生成する伝送条件とにより、前記暗号化鍵を更新し、
   前記暗号化データ生成手段は、前記暗号化鍵を用いて前記ＡＶデータを暗号化する
   ことを特徴とする請求項２記載のパケット送信装置。
5. 前記暗号化データ生成手段は、前記コピー制御情報がコピー制御をする旨を示すかコピー制御をしない旨を示すかに関係なく、前記暗号化モード情報に基づく暗号化情報ヘッダの付加を行う
   ことを特徴とする請求項１記載のパケット送信装置。
6. 前記認証手段は、前記パケット送信装置と前記パケット受信装置との間で認証を実行する認証実行モードと認証を実行しない認証不実行モードとを持ち、
   前記暗号化データ生成手段は、前記認証手段が前記認証実行モード及び前記認証不実行モードのいずれであっても、前記暗号化モード情報に基づく暗号化情報ヘッダの付加を行う
   ことを特徴とする請求項１記載のパケット送信装置。
7. 前記暗号化データ生成手段は、前記コピー制御情報がコピー制御をする旨を示す場合に、前記コピー制御情報を前記暗号化情報ヘッダとして付加し、前記コピー制御情報がコピー制御をしない旨を示す場合に、前記コピー制御情報を前記暗号化情報ヘッダとして付加しない
   ことを特徴とする請求項６記載のパケット送信装置。
8. 前記認証手段は、前記入力端子情報と、前記データフォーマット情報と、前記属性情報と、前記課金情報、前記コピー制御情報、前記有効期限情報及び前記有効再生回数情報より生成する認証条件とにより、前記パケット受信装置との間で認証を行う
   ことを特徴とする請求項２記載のパケット送信装置。
9. 前記パケット送信装置はさらに、前記データフォーマット情報と、前記属性情報と、前記課金情報、前記コピー制御情報、前記有効期限情報及び前記有効再生回数情報の少なくとも１つとからなる制御認証情報を、前記ＡＶデータのプログラム単位毎にアクセス位置を指定するＵＲＩ情報、または、Ｑｕｅｒｙにより拡張されたＵＲＩ情報により、前記プ
   ログラムのリストとして、前記パケット受信装置に通知するアクセス位置通知手段を備える
   ことを特徴とする請求項８記載のパケット送信装置。
10. 前記パケット送信装置はさらに、前記パケット受信装置からプログラムリストの送信要求を受けると、前記データフォーマット情報と、前記属性情報と、前記課金情報、前記コピー制御情報、前記有効期限情報及び前記有効再生回数情報の少なくとも１つとからなる制御認証情報を、前記ＡＶデータのプログラム単位毎にアクセス位置を指定するＵＲＩ情報、または、Ｑｕｅｒｙにより拡張されたＵＲＩ情報により、前記プログラムのリストとして、前記パケット受信装置に通知するアクセス位置通知手段を備える
    ことを特徴とする請求項８記載のパケット送信装置。
11. 前記パケット送信装置はさらに、前記ＡＶデータの単位プログラムのコピー制御情報がコピー制御を行わない旨を示す場合に、前記ＡＶデータのデータフォーマット情報を表す第１のＭＩＭＥ−Ｔｙｐｅと、前記ＡＶデータに間欠的に前記暗号化情報ヘッダを付加したデータのデータフォーマット情報を表す第２のＭＩＭＥ−Ｔｙｐｅの２つのＭＩＭＥ−Ｔｙｐｅを生成し、前記ＡＶデータのプログラム単位毎にアクセス位置を指定する２つの拡張ＵＲＩ情報を前記パケット受信装置に提示するアクセス位置通知手段を備える
    ことを特徴とする請求項８記載のパケット送信装置。
12. 前記２つの拡張ＵＲＩ情報は、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ（ＵＰｎＰ）におけるｒｅｓのＵＲＩ指定に使用し、前記２つのＭＩＭＥ−Ｔｙｐｅは前記ｒｅｓのａｔｔｒｉｂｕｔｅであるｐｒｏｔｏｃｏｌＩｎｆｏの第３フィールドに挿入することによりコンテンツの識別を行う
    ことを特徴とする請求項１１記載のパケット送信装置。
13. 前記パケット送信装置はさらに、
    前記パケット受信装置に送信するＡＶデータ及び非ＡＶデータをそれぞれ一時的に保持する第１及び第２バッファと、
    前記第１及び第２バッファのいずれかに保持されたデータが優先して前記パケット受信装置に送信されるように優先制御する優先制御手段と
    を備えることを特徴とする請求項１記載のパケット送信装置。
14. 前記優先制御手段は、前記非ＡＶデータが前記第２バッファでオーバーフローしないことを維持しつつ、前記ＡＶデータが前記第１バッファから優先して出力されるように、前記優先制御を行う
    ことを特徴とする請求項１３記載のパケット送信装置。
15. 前記伝送手段は、前記伝送プロトコル決定手段によって前記ＡＶデータの伝送プロトコルとして、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）と決定された場合は、ＴＣＰコネクションを永続的接続にして前記伝送を行う
    ことを特徴とする請求項１記載のパケット送信装置。
16. 前記認証手段は、Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ（ＤＴＣＰ）方式に従って、前記パケット受信装置と暗号化鍵を共有するための認証と鍵交換を行う
    ことを特徴とする請求項１記載のパケット送信装置。
17. 前記パケット化手段は、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）、ＴＣＰ又はＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ）に従ったパケット
    化を行う ことを特徴とする請求項１記載のパケット送信装置。
18. 前記パケット化手段は、前記ＨＴＴＰに従ったパケット化を行う場合は、レンジリクエストまたはデータ取得コマンドにより前記パケット化を行い、前記送信側における前記ＡＶデータがＭＰＥＧの場合には、ＭＰＥＧストリームにおける不連続発生連続性情報、前記ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報、前記ＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの時刻情報、或るＩピクチャから次のＩピクチャの間に存在するＰピクチャとＢピクチャの各個数または合計個数のうち少なくとも１つの情報を参照して前記パケット化を行う
    ことを特徴とする請求項１７記載のパケット送信装置。
19. 前記パケット化手段は、前記ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報として、前記ＡＶデータが複数の異なるファーマットであった場合にもオリジナルに持っている複数のＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報より、複数の異なるファーマット間で共通なＩピクチャまたはＰピクチャまたはＢピクチャ位置情報または時刻情報を生成し、この共通のＩピクチャまたはＰピクチャまたはＢピクチャ位置情報または時刻情報を用いて前記ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報の参照情報と前記パケット化を行う
    ことを特徴とする請求項１７記載のパケット送信装置。
20. 前記パケット化手段は、ＨＴＴＰに従ったパケット化を行う場合は、チャンク伝送方式で前記パケット化を行ない、ＨＴＴＰパケットのペイロード長が前記パケット送信装置で決定された値となるように前記パケット化を行う
    ことを特徴とする請求項１７記載のパケット送信装置。
21. 前記パケット化手段は、ＨＴＴＰに従ったパケット化を行う場合は、ＨＴＴＰパケットのペイロード長が、前記暗号化情報ヘッダと整数個の前記ＡＶデータを構成するＴｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ（ＴＳ）により構成されるデータの長さ、または、前記暗号化情報ヘッダと整数個のタイムスタンプつきＴＳにより構成されるデータの長さとなるように前記パケット化を行う
    ことを特徴とする請求項１７記載のパケット送信装置。
22. 前記伝送手段は、前記ＨＴＴＰによる伝送として、レンジリクエスト方式とチャンク伝送方式を切り替えて行う
    ことを特徴とする請求項１７記載のパケット送信装置。
23. 前記伝送手段は、前記ＨＴＴＰによる伝送として、前記パケット送信装置の出力がライブ放送の受信信号またはライブ放送の受信チャネルの切り替えまたは蓄積されたプログラム選択時の再生信号の場合には、チャンク伝送を行い、プログラム選択後の蓄積メディアから再生されたプログラムからの再生信号の場合には、レンジリクエストを用いて再生を切替えて行う
    ことを特徴とする請求項１７記載のパケット送信装置。
24. 前記パケット化手段は、Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＲＴＰ）、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（ＵＤＰ）又はＩＰに従ったパケット化を行う
    ことを特徴とする請求項１記載のパケット送信装置。
25. 前記伝送手段は、マルチキャスト伝送でパケットを伝送する場合、前記暗号化情報ヘッダが付加されたパケットと付加されていないパケットの両方を出力する
    ことを特徴とする請求項２４記載のパケット送信装置。
26. 前記パケット送信装置はさらに、前記ＡＶデータの単位プログラムのコピー制御情報がコピー制御を行わない旨を示す場合に、前記ＡＶデータのデータフォーマット情報を表すｃ−Ｔｙｐｅと、前記ＡＶデータに間欠的に前記暗号化情報ヘッダを付加したデータのデータフォーマット情報を表す第２のＭＩＭＥ−Ｔｙｐｅの２つのＭＩＭＥ−Ｔｙｐｅを生成し、前記ＡＶデータのプログラム単位毎にアクセス位置を指定する２つの拡張ＵＲＩ情報を前記パケット受信装置に提示するアクセス位置通知手段を備える
    ことを特徴とする請求項２５記載のパケット送信装置。
27. 前記２つの拡張ＵＲＩ情報は、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ（ＵＰｎＰ）におけるｒｅｓのＵＲＩ指定に使用し、前記２つのＭＩＭＥ−Ｔｙｐｅは前記ｒｅｓのａｔｔｒｉｂｕｔｅであるｐｒｏｔｏｃｏｌＩｎｆｏの第３フィールドに挿入することによりコンテンツの識別を行う
    ことを特徴とする請求項２６記載のパケット送信装置。
28. 前記伝送手段は、ＨＴＴＰによる伝送とＲＴＰによる伝送を切り替えて前記ＡＶデータを伝送する
    ことを特徴とする請求項１記載のパケット送信装置。
29. 前記伝送手段は、前記ＨＴＴＰによる伝送として、前記パケット送信装置の出力がライブ放送の受信信号またはライブ放送の受信チャネルの切り替えまたは蓄積されたプログラム選択時の再生信号の場合には、チャンク伝送を行い、プログラム選択後の蓄積メディアから再生されたプログラムからの再生信号の場合には、レンジリクエストを用いて再生を切替えて行う
    ことを特徴とする請求項２８記載のパケット送信装置。
30. 前記伝送手段は、ＳＭＰＴＥ２５９Ｍ規格で規定された非圧縮ＳＤ方式信号、ＳＭＰＴＥ２９２Ｍ規格で規定された非圧縮ＨＤ形式、ＩＥＣ６１８８３規格で規定されたＩＥＥＥ１３９４によるＤＶまたはデジタル放送のＭＰＥＧ−ＴＳの伝送ストリーム形式、ＤＶＢ規格Ａ０１０で規定されたＤＶＢ−ＡＳＩによるＭＰＥＧ−ＴＳ形式、ＭＰＥＧ−ＰＥＳ，ＭＰＥＧ−ＥＳ、ＭＰＥＧ４、ＩＳＯ／ＩＥＣ Ｈ．２６４の内のいずれか一つのデータストリーム形式で、前記ＡＶデータを伝送する
    ことを特徴とする請求項１記載のパケット送信装置。
31. 前記パケット化手段は、前記ＡＶデータを構成するデータブロックにタイムスタンプを付加し、１つ以上のタイムスタンプ付データブロックをまとめてＲＴＰまたはＨＴＴＰのペイロードとしてマッピングすることによって前記パケット化を行う
    ことを特徴とする請求項３０記載のパケット送信装置。
32. 前記パケット化手段は、前記ＡＶデータをＭＰＥＧ−ＴＳで伝送する場合、各ＴＳパケットにタイムスタンプを付加し、複数のタイムスタンプ付ＴＳパケットをまとめてＲＴＰまたはＨＴＴＰ上にマッピングする
    ことを特徴とする請求項３１記載のパケット送信装置。
33. 前記各ＴＳパケットに付加するタイムスタンプのクロックはＭＰＥＧのシステムクロック周波数に等しく、
    前記パケット送信装置はさらに、前記ＴＳパケットを受信し、受信したＴＳパケットに
    付加されたタイムスタンプより、ＭＰＥＧ−ＴＳのネットワーク伝送によりＰｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ（ＰＣＲ）に付加された伝送ジッターを除去して、ＭＰＥＧシステムクロックの再生を行うクロック再生手段を備える
    ことを特徴とする請求項３２記載のパケット送信装置。
34. 前記パケット化手段は、外部入力されたＴＳに付加されたタイムスタンプの有効ビット数または蓄積メディアから再生されたＴＳに付加されたタイムスタンプの有効ビット数が前記各ＴＳパケットに付加するタイムスタンプの有効ビット数と異なる場合において、ストリームのＭＰＥＧのＰＣＲが不連続になりシステムタイムベースの不連続が発生しないとき、また、ＴＳのｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒの不連続が発生しないときは、前記外部入力されたＴＳに付加されたタイムスタンプまたは前記蓄積メディアから再生されたＴＳに付加されたタイムスタンプと、前記ＴＳパケットに付加するタイムスタンプとを変えずに載せ変えだけを行ない、ストリームのＭＰＥＧのＰＣＲが不連続になりシステムタイムベースの不連続が発生するポイントまたはＴＳのｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒの不連続が発生するときは、前記不連続の発生点でＴＳの不連続発生を通知するＴＳパケットを挿入することで、前記パケット化を行う
    ことを特徴とする請求項３２記載のパケット送信装置。
35. 前記伝送手段は、Ｎを１以上の整数とした場合、ＵＤＰまたはＴＣＰのＮ個のポートを用いて、前記ＡＶデータにより構成されるＮ個のプログラムを前記Ｎ個のポートのそれぞれに割り当てて伝送する
    ことを特徴とする請求項１記載のパケット送信装置。
36. 前記Ｎ個のポートのそれぞれに割り当てるＮ個のプログラムは、それぞれ、前記パケット送信装置に内蔵された放送受信チューナまたは蓄積メディアデバイスがＵＰｎＰ手段のコンテナ形式で表現され、放送受信チャネルまたは蓄積プログラムがＵＰｎＰ手段のｉｔｅｍ形式で表現され、それぞれのｉｔｅｍの存在位置がＵＲＩでＵＰｎＰ手段の＜ｒｅｓ
    ｐｒｏｔｏｃｏｌＩｎｆｏ＞形式にマッピングされている
    ことを特徴とする請求項３５記載のパケット送信装置。
37. 前記Ｎ個のポートのそれぞれに割り当てるＮ個のプログラムは、前記パケット送信装置から前記パケット受信装置への伝送ストリームが存在する場合に、ＵＰｎＰのｐｒｏｐｅｒｔｙ形式で表われ、
    前記伝送ストリームのｐｒｏｐｅｒｔｙのａｔｔｒｉｂｕｔｅが前記チューナのコンテナの種別、前記チューナのコンテナ種別ごとのチューナＩＤ、前記チューナで選局されたチャネルＩＤ、前記伝送ストリームの共有を含む利用可否情報、前記ストリームを伝送するトランスポート層が使用するＴＣＰまたはＲＴＰのポート番号、前記パケット受信装置におけるＵＰｎＰ−ＡＶ手段のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒが前記パケット送信装置におけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対して前記ｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ手段のｃｏｎｎｅｃｔｉｏｎＩＤ、および、前記パケット送信装置におけるＵＰｎＰ−ＡＶ手段のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒが前記パケット受信装置におけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対して前記ｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶのｃｏｎｎｅｃｔｉｏｎＩＤの少なくとも１つを含んでおり、
    前記パケット送信装置はさらに、前記パケット受信装置として前記パケット送信装置内のチューナのチャネル選局を行なう時に、前記伝送ストリームのｐｒｏｐｅｒｔｙを参照することにより、伝送ストリームに空きあるか無いか、およびどのチューナの、どのチャネルが選局されているかを判別する受信制御手段を備える
    ことを特徴とする請求項３６記載のパケット送信装置。
38. 前記Ｎ個のポートのそれぞれに割り当てるＮ個のプログラムは、前記パケット送信装置から前記パケット受信装置への伝送ストリームが存在する場合に、ＵＰｎＰのｐｒｏｐｅｒｔｙ形式で表わされ、
    前記伝送ストリームのｐｒｏｐｅｒｔｙのａｔｔｒｉｂｕｔｅが前記蓄積メディアデバイスのコンテナの種別、前記蓄積メディアデバイスのコンテナ種別ごとの蓄積メディアデバイスＩＤ、前記蓄積メディアデバイスで選択されたプログラムＩＤ、前記伝送ストリームの共有を含む利用可否情報、前記ストリームを伝送するトランスポート層が使用するＴＣＰまたはＲＴＰのポート番号、前記パケット受信装置におけるＵＰｎＰ−ＡＶ手段のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒが前記パケット受信装置におけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対して前記ｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ手段のｃｏｎｎｅｃｔｉｏｎＩＤの少なくとも１つを含んでおり、
    前記パケット送信装置はさらに、前記パケット受信装置として前記パケット送信装置内の蓄積メディアデバイスのプログラム選択を行なう時に、前記伝送ストリームのｐｒｏｐｅｒｔｙを参照することにより、伝送ストリームに空きあるか無いか、およびどの蓄積メディアデバイスのどのプログラムが選択されているかを判別する受信制御手段を備える
    ことを特徴とする請求項３６記載のパケット送信装置。
39. 「前記ストリームを伝送するトランスポート層が使用するＴＣＰまたはＵＤＰのポート番号」、および、「前記パケット受信装置におけるＵＰｎＰ−ＡＶ手段のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒが前記パケット送信装置におけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対して前記ｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ手段のｃｏｎｎｅｃｔｉｏｎＩＤ、または前記パケット送信装置におけるＵＰｎＰ−ＡＶ手段のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒが前記パケット受信装置におけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対して前記ｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ手段のｃｏｎｎｅｃｔｉｏｎＩＤ」の論理対により、前記ＵＰｎＰ−ＡＶ手段と、前記ＴＣＰまたは前記ＵＤＰを使用するＨＴＴＰまたはＲＴＰを用いるトランスポート手段とが論理的に対応づけられる
    ことを特徴とする請求項１または３７または３８記載のパケット送信装置。
40. パケット受信装置にパケットデータを送信するパケット送信方法であって、
    ＡＶデータが入力される端子を示す入力端子情報、前記ＡＶデータのデータフォーマットを示すデータフォーマット情報及び前記ＡＶデータの属性を示す属性情報を含むＡＶデータ情報を取得するＡＶデータ情報取得ステップと、
    前記ＡＶデータ及び非ＡＶデータの入力を受け付けるデータ入力ステップと、
    前記非ＡＶデータまたは前記ＡＶデータより、前記ＡＶデータの課金情報、再生制御情報及びコピー制御情報の少なくとも１つの情報を抽出し、抽出した情報から、前記ＡＶデータを送信する際の条件となる暗号化モードを示す暗号化モード情報を生成する送信条件設定管理ステップと、
    前記入力端子情報、前記データフォーマット情報及び前記属性情報を組み合わせて決定される送信条件に基づいて、前記データ入力ステップで入力された前記ＡＶデータを暗号化し、暗号化された前記ＡＶデータに対して前記暗号化モード情報に基づく暗号化情報ヘッダを付加することによって暗号化データを生成する暗号化データ生成ステップと、
    前記暗号化データ生成ステップで生成された暗号化データに対して、パケットヘッダを付加することによってパケットを生成するパケット化ステップと、
    前記ＡＶデータの前記パケット送信装置内でのアクセス位置を示すＵＲＩ情報または拡張ＵＲＩ情報を用いて、前記パケット受信装置との間で前記ＡＶデータの暗号化または復号化のための認証処理を行う認証ステップと、
    前記入力端子情報、前記属性情報及び前記パケット受信装置より指定される送信モードを示す情報の少なくとも１つを用いて、前記パケット送信装置と前記パケット受信装置の間での前記ＡＶデータの伝送プロトコルを決定する伝送プロトコル決定ステップと、
    前記認証ステップによって前記パケット受信装置との認証処理が完了した後に、前記伝送プロトコル決定ステップで決定された伝送プロトコルに従って、前記パケット化ステップによって生成された、暗号化データを含むパケットを前記パケット受信装置に伝送する伝送ステップと
    を含むことを特徴とするパケット送信方法。
41. パケット受信装置にパケットデータを送信するパケット送信装置のためのプログラムであって、
    請求項４０記載のパケット送信方法に含まれるステップをコンピュータに実行させる
    ことを特徴とするプログラム。

Images