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

Abstract

著作権保護されたコンテンツをＩＰネットワーク越しに送信可能なパケット送信装置（４０１）は、入力された非ＡＶデータまたはＡＶデータより、ＡＶデータの課金情報、再生制御情報、コピー制御情報およびパケット出力制御情報の少なくとも１つの情報を抽出し、抽出した情報から、ＡＶデータを送信する際の条件となる暗号化モードを示す暗号化モード情報を生成する送信条件設定管理部（４０３）、入力端子情報、データフォーマット情報および属性情報を組み合わせて決定される送信条件に基づいて、入力されたＡＶデータを暗号化し、暗号化されたＡＶデータに対して暗号化モード情報に基づく暗号化情報ヘッダ、タイムベースの不連続情報を付加して暗号化データを生成する暗号化データ生成部（４２２）、及び生成された暗号化データに対して、パケットヘッダとタイムベースの不連続点を表す情報とを付加してパケットを生成するパケット化部（４０６）とを備える。

Description

本発明は、ＩＥＥＥ８０２．３などのイーサネット（登録商標）（有線ＬＡＮ）やＩＥＥＥ８０２．１１などの無線ＬＡＮなどを用いて、暗号化されたＡＶストリームをＩＰパケット化して高品質に送信するパケット送信装置に関し、特にＩＰネットワーク越しにコンテンツ保護を図りつつ、かつ早送り、巻き戻し、スロー再生などの特殊再生に適した形態でＡＶストリームを送信する技術に関する。

近年の通信技術の発展に伴い、効率よくパケットを伝送する様々な技術が提案されている（例えば、特許文献１参照）。その一つとして、従来、一般家庭において、部屋内でデジタル放送チューナやＤＶＨＳ方式ビデオレコーダー間をＩＥＥＥ １３９４方式デジタルインターフェースで接続し、ＩＥＣ ６１８８３−４で規定されたＭＰＥＧ−ＴＳ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ／Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）信号の伝送が行われている。ここで、放送コンテンツにコピーワンジェネレーション（Ｃｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎ）などコンテンツ保護がかかっている場合、コンテンツを不正コピーから保護するため、コンテンツを暗号化して伝送している。

この様にデジタル放送を受信・選局して得られたＭＰＥＧ−ＴＳなどのＡＶデータを暗号化して伝送する方式の一例として、ＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）方式が規定されている。ＤＴＣＰは、ＩＥＥＥ１３９４やＵＳＢなどの伝送メディア上のコンテンツ保護技術である。ＤＴＣＰ方式は、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｃｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）で規格化された方式であり、ＨＹＰＥＲＬＩＮＫ“ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ”ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ、ＨＹＰＥＲＬＩＮＫ“ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｄｔｃｐ＃ｔｕｔ．ｐｄｆ”ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｄｔｃｐ＃ｔｕｔ．ｐｄｆ、ＨＹＰＥＲＬＩＮＫ“ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｗｐ＃ｓｐｅｃ．ｐｄｆ”ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｗｐ＃ｓｐｅｃ．ｐｄｆや、書籍「ＩＥＥＥ１３９４、ＡＶ機器への応用」、高田信司監修、日刊工業新聞社、「第８章、コピープロテクション」、１３３〜１４９ページで説明されている。

ＭＰＥＧ−ＴＳについて説明する。トランスポートストリームはトランスポートパケット（ＴＳ ｐａｃｋｅｔ）が複数個集まったものである。ＴＳ ｐａｃｋｅｔは１８８ｂｙｔｅの固定長パケットで、その長さはＡＴＭのセル長との整合性およびリードソロモン符号などの誤り訂正符号化を行なう場合の適用性を考慮して決定されている。ＴＳ ｐａｃｋｅｔは４ｂｙｔｅ固定長のパケットヘッダと可変長のアダプテーションフィールド（ａｄａｐｔａｔｉｏｎ ｆｉｅｌｄ）およびペイロード（ｐａｙｌｏａｄ）で構成される。パケットヘッダにはＰＩＤ（パケット識別子）や各種のフラグが定義されている。このＰＩＤによりＴＳ ｐａｃｋｅｔの種類を識別する。

ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄとｐａｙｌｏａｄは、片方のみが存在する場合と両方が存在する場合があり、その有無はパケットヘッダ内のフラグ（ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄ＿ｃｏｎｔｒｏｌ）により識別できる。ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄは、ＰＣＲ（Ｐｒｏｇｒａｍ＿Ｃｌｏｃｋ＿Ｒｅｆｅｒｅｎｃｅ）等の情報伝送およびＴＳ ｐａｃｋｅｔを１８８ｂｙｔｅ固定長にするためのＴＳ ｐａｃｋｅｔ内でのスタッフィング機能を持つ。

また、ＰＣＲは２７ＭＨｚのタイムスタンプで、符号化した時の基準時間を復号器のＳＴＣで再現するためにＰＣＲの値が参照される。ＭＰＥＧ−２のＴＳでは復号器のＳＴＣ（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）はＰＣＲによるＰＬＬ同期機能を持つ。このＰＬＬ同期の動作を安定させるためにＰＣＲの送信間隔は最大０．１ｍｓである。映像や音声などの個別ストリームが収められたＭＰＥＧのＰＥＳパケットは同じＰＩＤ番号を持つ複数のＴＳ ｐａｃｋｅｔのｐａｙｌｏａｄに分割して伝送する。また、ＰＥＳパケットの先頭は、ＴＳ ｐａｃｋｅｔの先頭から開始するように構成される。

トランスポートストリームは複数のプログラムを伝送することができるため、ストリームに含まれているプログラムとそのプログラムを構成している映像や音声ストリームなどのプログラムの要素との関係を表すテーブル情報が用いられる。このテーブル情報はＰＳＩ（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）と呼ばれ、ＰＡＴ（Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅ）、ＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）などのテーブルを用いる。ＰＡＴ、ＰＭＴなどのＰＳＩはセクションと呼ばれる単位でＴＳ ｐａｃｋｅｔの中のｐａｙｌｏａｄに配置されて伝送される。

ＰＡＴにはプログラム番号に対応したＰＭＴのＰＩＤなどが指定されており、ＰＭＴには対応するプログラムに含まれる映像、音声、付加データおよびＰＣＲのＰＩＤが記述されるため、ＰＡＴとＰＭＴを参照することにより、ストリームの中から目的のプログラムを構成するＴＳ ｐａｃｋｅｔだけを取り出すことができる。

ＴＳに関する参考文献としては、例えば、ＣＱ出版社、ＴＥＣＨ Ｉ Ｖｏ．４、「画像＆音声圧縮技術のすべて（インターネット／ディジタルテレビ、モバイル通信時代の必須技術）」、監修、藤原洋、第６章、「画像や音声を多重化するＭＰＥＧシステム」があり、同書にて解説されている。

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

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

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

図２は、ＤＴＣＰ方式における従来のパケット通信部の概略を説明する図であり、ここでは、図１のソース９０１が備えるパケット送信部およびシンク９０２が備えるパケット受信部の両方がパケット送受信部として示されている。まず、ＤＴＣＰ方式に準拠した認証と鍵交換（Ａｕｔｈｅｎｔｉｆｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ、ＡＫＥと略する）が行なわれる。ＡＫＥ部１００１に対して、その認証と鍵交換の設定情報が入力され、この情報がパケット化部１００２に伝達され、パケット化部１００２において規定のヘッダが付加されたパケット化が行われ、ネットワーク１００７に出力される。

ここで、パケット化部１００２は、送信条件設定部１００３により決定された送信パラメータにより、入力データのパケット化および送信を行なう。受信側では、ネットワーク１００７より入力する信号がパケット受信部１００４でパケットヘッダなどの識別によりフィルタリングされ、ＡＫＥ部１００１に入力される。これにより送信側（ソース）のＡＫＥ部と、受信側（シンク）のＡＫＥ部がネットワーク１００７を介してお互いにメッセージの通信ができる。すなわち、ＤＴＣＰ方式の手順に従い、認証と鍵交換を実行する。

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

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

ソースでは暗号鍵を時間的に変化させるために、時間的に変化するシード情報を生成し、シンクに送信する。ソースでは、交換鍵とシード情報より暗号化鍵を生成して、ＭＰＥＧ−ＴＳをこの暗号化鍵を用いて暗号化部で暗号化してシンクに送信する。シンクはシード情報を受信し交換鍵とシード情報より復号鍵を復元する。シンクではこの復号鍵を用いて暗号化されたＭＰＥＧ−ＴＳ信号を復号する。

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

以上述べたように、従来のＤＴＣＰ方式に従って、ＭＰＥＧ−ＴＳ信号は、ＩＥＥＥ１３９４に規定される伝送線路を介してコンテンツ保護を図りつつ伝送される。
特開２０００−５９４６３号公報

しかしながら、上記従来のＤＴＣＰ方式は、インターネットの標準プロトコルであるＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ）を用いて、イーサネット（登録商標）（ＩＥＥＥ８０２．３）、無線ＬＡＮ（ＩＥＥＥ８０２．１１）や、その他のＩＰパケットを伝送可能なネットワーク越しに、従来と同様のコンテンツ保護を図りつつ伝送するための技術を示していない。

とりわけ、サーバのハードディスクなどに蓄積されたコンテンツを、端末からの要求に応じて、コンテンツ保護を図った上で、早送り、巻き戻し、スロー再生などの特殊再生を簡単に実現可能な形態で、要求元の端末へ伝送するための有効な技術は、いまだ知られていないのが現状である。

デジタルＴＶやホームサーバが家庭に急速に普及浸透し、家庭内のデジタルＴＶやホームサーバによって放送等から取得されたデジタル著作権保護対応のコンテンツを、ＩＰネットワークによって実現されている家庭内ＬＡＮ越しに、家庭内のパソコン等の様々な機器で視聴したいというニーズが高まっており、ユーザは、そのような視聴の際にも、早送り、巻き戻し、スロー再生などの特殊再生の利便を享受したいと考えるが、従来の技術をもっては、そのようなユーザの期待に応えることができない。

本発明は、このような状況に鑑みてなされたものであり、ＡＶコンテンツを、コンテンツ保護を図りつつ、ＨＴＴＰプロトコルやＲＴＰプロトコルなどを利用してＩＰネットワーク越しに送信し、とりわけ早送り、巻き戻し、スロー再生などの特殊再生に適した形態で送信することが可能なパケット送信装置を提供することを目的とする。

上記目的を達成するために、本発明に係るパケット送信装置は、パケット受信装置にパケットデータを送信するパケット送信装置であって、ＡＶデータが入力される端子を示す入力端子情報、前記ＡＶデータのデータフォーマットを示すデータフォーマット情報、または、前記ＡＶデータの属性を示す属性情報のうち少なくとも１つの情報を含むＡＶデータ情報を取得するＡＶデータ情報取得手段と、前記ＡＶデータ及び非ＡＶデータの入力を受け付けるデータ入力手段と、前記非ＡＶデータまたは前記ＡＶデータより、前記ＡＶデータの課金情報、再生制御情報、または、コピー制御情報、パケットデータ送信許可情報、送信相手のＭＡＣアドレス情報のうち少なくとも１つの情報を抽出し、抽出した情報から、前記ＡＶデータを送信する際の暗号化モードを示す暗号化モード情報を生成する送信条件設定管理手段と、前記入力端子情報、前記データフォーマット情報及び前記属性情報を組み合わせて決定される送信条件に基づいて、前記データ入力手段より入力された前記ＡＶデータの暗号化制御を行い、前記暗号化モード情報に基づく暗号化情報ヘッダを暗号化制御された前記ＡＶデータに付加することによって暗号化情報ヘッダ付き被暗号化制御送信データを生成する暗号化送信データ生成手段と、前記暗号化送信データ生成手段により生成された暗号化情報ヘッダ付き被暗号化制御送信データを含んだデータに対して、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ、及びＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌのうち、１つ以上のプロトコルを組み合わせたパケットヘッダを付加すると共に、前記ＡＶデータにおけるタイムベースの不連続が発生する点にＭＰＥＧストリームのシステムタイムベースの不連続を表す情報を付加することによってパケットを生成するパケット化手段と、前記パケット受信装置との間で認証処理を行う認証手段と、前記入力端子情報、前記属性情報及び前記パケット受信装置より指定される送信モードを示す情報の少なくとも１つを用いて、前記パケット送信装置と前記パケット受信装置の間での前記ＡＶデータの伝送プロトコルを決定する伝送プロトコル決定手段と、前記認証処理によって前記パケット受信装置との認証処理が完了した後に、前記伝送プロトコル決定手段によって決定された伝送プロトコルに従って、前記パケット化手段によって生成された暗号化情報ヘッダ付き被暗号化制御送信データを含むパケットを前記パケット受信装置に伝送する伝送手段とを備える。

また、前記認証手段は、前記パケット送信装置内における前記ＡＶデータのＵＲＩ情報または拡張ＵＲＩ情報を用いて、前記パケット受信装置との間で前記ＡＶデータのアドレス情報の取得および認証処理を行ってもよい。

また、前記パケット化手段は、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌによるデータ伝送において、伝送される前記ＡＶデータが通信回線におけるコネクションの張り直しのために分断される箇所には、ＭＰＥＧストリームのシステムタイムベースの不連続を表す情報を付加しないことが好ましい。

また、前記パケット化手段はＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌレスポンスに挿入するデータ長は、元のデータ長に前記タイムベースの不連続を表す情報の長さ分を付加した長さとしてもよく、またその場合に、送信データ中の有効データの開始位置または終了位置に関する情報に前記タイムベースの不連続を表す情報の長さ分だけオフセットさせて有効データを取得するためのオフセット情報を伝えてもよい。

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

本願発明のパケット送信装置によれば、ＭＰＥＧ−ＴＳ信号などのＡＶストリームを外部から与えられる一定規則による送信条件に従い暗号化モードを決め、さらに暗号化情報ヘッダを付加することを決めることにより、パケット送受信機器間での信号の互換性を確保しながら、ＨＴＴＰプロトコルやＲＴＰプロトコルなどを利用しながらＡＶストリームの秘匿性を保つことが可能となる。ここで、ストリームのコピー制御情報（ＣＣＩ；Ｃｏｐｙ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）は外部から与えられ、暗号化情報ヘッダを付加するかどうか、および、伝送の暗号化モードなどを決定する。

これにより、ＭＰＥＧ−ＴＳ信号などのＡＶストリームをそのコピー制御情報に従い暗号化モードを決め、暗号化情報ヘッダを付加した後、パケット化して伝送するので、ＡＶコンテンツの著作権者が設定したコピー制御モードを漏れなく正しく継承することができる。よって、トータルなシステムとしてＡＶコンテンツの著作権保護を図りつつ、パケット送受信機器間での信号の互換性を確保することが可能となる。

しかも、送信されるＡＶストリームにはタイムベースの不連続点にその旨を表す情報が付加されるので、ＡＶストリームを供給される前記パケット受信装置においてタイムベースの不連続点が明らかとなり、早送り、巻き戻し、スロー再生などの特殊再生を滑らかに行うことが可能となる。

図１（ａ）は従来技術による送受信システムの説明図であり、図１（ｂ）はソース機器およびシンク機器の例を示す図である。 図２は、従来技術におけるパケット送受信部のブロック図である。 図３は、従来技術である１３９４を用いたＤＴＣＰ方式によるコンテンツ伝送手順の説明図である。 図４は、従来技術である１３９４を用いたＤＴＣＰ方式によるパケット形式の説明図である。 図５は、本発明における送受信システムの説明図である。 図６は、本発明における鍵交換にＤＴＣＰ方式を適用する場合のコンテンツ伝送手順の説明図である。 図７は、イーサネット（登録商標）を用いる一般家庭に本発明を適用した場合の一例の説明図である。 図８は、本発明におけるパケット送受信部のブロック図である。 図９は、本発明における認証と鍵交換にＤＴＣＰ方式を適用する場合のコンテンツ伝送手順の説明図である。 図１０は、本発明におけるＭＰＥＧ−ＴＳのイーサネット（登録商標）フレーム構成仕様の例を示す図である。 図１１は、本発明におけるパケット送受信部のブロック図である。 図１２は、本発明におけるパケット送受信部のブロック図である。 図１３は、ピクチャ情報ファイルの構成を示す図である。 図１４（ａ）は本発明におけるＨＴＴＰによるパケット送信の対象となるＡＶデータの一例を示す図であり、図１４（ｂ）は送信手順の一例を示すシーケンスチャートであり、図１４（ｃ）は伝送されるデータの一例を示す図である。 図１５（ａ）は本発明におけるＨＴＴＰによるパケット送信の対象となるＡＶデータの一例を不連続点と共に示す図であり、図１５（ｂ）は伝送されるデータの一例を示す図である。 図１６（ａ）は本発明におけるＨＴＴＰによるパケット送信の対象となる無効データを含んだＡＶデータの一例を示す図であり、図１６（ｂ）は伝送されるデータの一例を示す図である。 図１７は、本発明におけるパケット送受信部のブロック図である。

符号の説明

１０１ パケット送信機器
１０２ ルータ
１０３ パケット受信機器
３０１、３０２ ネットワークシステム
３０３ ルータ
３０４ スイッチングハブ
３０５ ネットワーク
４０１ パケット送受信部
４０２ ＴＳストリーム識別部
４０３ 送信条件設定管理部
４０４ ＤＲＭ設定管理部
４０５ ＡＫＥ部
４０６ パケット化部
４０７ 送信キュー制御部
４０８ フレーム化部
４０９ フレーム受信部
４１０ パケット受信部
４１１ ＤＲＭコンテンツ購入決済部
４１２ コンテンツメタ情報
４１３ コンテンツバッファ
４１４ 暗号化部
４１５ 暗号化情報ヘッダ付加部
４１６ ＨＴＴＰ／ＲＴＰヘッダ付加部
４１７ 受信条件設定管理部
４１８ 暗号化データ復号部
４１９ 認証部
４２０ 暗号化鍵交換部
４２１ 認証モード決定部
４２２ 暗号化データ生成部
７０１ 蓄積部
８０１ データ配列情報生成管理部
９０１ ソース
９０２ シンク
９０３ ネットワーク
１００１ ＡＫＥ部
１００２ パケット化部
１００３ 送信条件設定部
１００４ パケット受信部
１００５ 暗号化部
１００６ 復号部
１００７ ネットワーク
１７０１ ＣＣＩバッファ
７４０１、８４０１、１７４０１ パケット送受信部

以下、本発明の実施の形態について、図面を用いて詳細に説明する。

本発明の実施の形態におけるパケット送信装置は、ＩＰネットワーク越しに、パケット受信装置から要求されたＡＶストリームの部分を前記パケット受信装置へ著作権を保護しつつ送信する装置であり、送信されるＡＶストリームにおけるタイムベースの不連続点に不連続情報を含めることを特徴とする。

これによって、ＩＰネットワーク越しに著作権を保護されたＡＶストリームを供給される前記パケット受信装置においてタイムベースの不連続点が明らかとなり、そのＡＶストリームの滑らかな再生が可能となる。

以下では、本発明のパケット送信装置の特徴を明確にするために、［１］本発明のパケット送信装置を含む通信システムの構成と著作権保護の実現の概要、［２］著作権保護しつつＩＰネットワーク越しにＡＶストリームを伝送する構成の詳細、［３］蓄積されているＡＶストリームの指定部分を送信する構成の詳細、及び［４］指定された部分の送信を効率化する構成の詳細について説明した後、これらの構成との組み合わせにおいて本発明を特徴付けるところの［５］タイムベースの不連続情報を伝送する構成の詳細について説明し、最後に［６］コピー制御情報を専用の伝達経路を用いて伝達する変形例について、この順に説明する。

［１］本発明のパケット送信装置を含む通信システムの構成と著作権保護の実現の概要
最初に、本発明のパケット送信装置を含んで構成される通信システムと著作権保護の実現の概要について説明する。

図５は本発明のパケット送信装置を含んで構成される通信システムの一例である。この通信システムは、パケットを送信するパケット送信機器１０１と、パケットのルーティングを行うルータ１０２と、パケットを受信するパケット受信機器１０３とから構成される。

パケット送信機器１０１およびパケット受信機器１０３は、一例として、互いの機能を兼ね備えた対等かつ一対のパケット送受信機器として実現されてもよい。その場合、パケット送信機器１０１が送信側として機能し、パケット受信機器１０３が受信側として機能する。そのようなパケット送受信器の、ＡＶストリームを送信する機能に係る部分が、本発明のパケット送信装置の一例である。

パケット送信機器１０１には、送受信条件の設定情報、認証と鍵交換の設定情報、入力ストリーム（ＭＰＥＧ−ＴＳなどのコンテンツ）が入力され、図６に示されるように、以下の手順１から３に基づき、ルータ１０２との間で通信を行う。ここで、伝送されるコンテンツの著作権保護は、認証と暗号化を用いたコピー保護に基づいて実現される。

＜手順１＞送受信パラメータの設定を行なう。

（手順１−１）パケット送受信機器のＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス、ＩＰアドレス、ＴＣＰ／ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）ポート番号等を設定。ＵＰｎＰなどの自動設定機能を使用することができる。

（手順１−２）送信信号の種別、帯域を設定。ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）エージェントとして動作するパケット送信機器１０１とパケット受信機器１０３、ＱｏＳマネージャとして動作するルータ１０２との間でＩＥＥＥ８０２．１Ｑ（ＶＬＡＮ；Ｖｉｒｔｕａｌ ＬＡＮ）規格を用いたネットワークの運用に関する設定を実施。

（手順１−３）優先度の設定（ＩＥＥＥ８０２．１Ｑ／ｐによる運用）

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

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

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

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

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

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

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

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

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

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

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

このようにして、パケット送信機器１０１及びパケット受信機器１０３の間で、コピー制御に基づいてコンテンツの著作権を保護しつつ、そのコンテンツの伝送が行われる。

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

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

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

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

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

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

図７において、家庭内の全てのイーサネット（登録商標）の帯域が１００Ｍｂｐｓであるため、１階と２階間のネットワーク３０５の帯域も１００Ｍｂｐｓである。１階と２階の複数の機器間で複数のデータが流れる場合、各データに対する帯域制限がない場合、このネットワーク３０５上を流れるデータのデータレート合計が１００Ｍｂｐｓを超える可能性があり、パーシャルＭＰＥＧ−ＴＳの映像アプリなどリアルタイム伝送が必要なストリームが途切れる可能性がある。この場合、リアルタイム伝送が必要なストリームが途切れない様にするには、伝送データに対して優先制御が必要である。このような問題は、端末だけでなく、ルータやスイッチングハブにおいて、後述するストリーム伝送やファイル転送の速度制限機構などを導入することにより解決できる。

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

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

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

地上波放送、衛星放送、ＣＡＴＶやインターネット経由で受信するデジタル放送信号より検出、抽出できるＡＶコンテンツの属性情報を送信端末と受信端末間でＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）−ＡＶやＨＴＴＰなどのデータ交換プロトコルを用いて伝送することにより、送信端末と受信端末間でのＡＶコンテンツを送信する場合の暗号化モード、コンテンツ属性情報の伝送方法を決めることができる。さらに、暗号化情報ヘッダの付加ルールを決められるため、パケット送受信機器間でのＡＶストリームの秘匿性を保ちながら信号の互換性を確保することが可能となる。

ＵＰｎＰやＵＰｎＰ−ＡＶの標準仕様は、ｈｔｔｐ：／／ｕｐｎｐ．ｏｒｇで公開されている。ｈｔｔｐ：／／ｕｐｎｐ．ｏｒｇにおいて、例えば、「ＭｅｄｉａＳｅｒｖｅｒ Ｖ １．０ ａｎｄ ＭｅｄｉａＲｅｎｄｅｒｅｒ Ｖ １．０」に関して、「ＭｅｄｉａＳｅｒｖｅｒ Ｖ １．０」、「ＭｅｄｉａＲｅｎｄｅｒｅｒ Ｖ １．０」、「ＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ Ｖ １．０」、「ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙ Ｖ １．０」、「ＲｅｎｄｅｒｉｎｇＣｏｎｔｒｏｌ Ｖ １．０」、「ＡＶＴｒａｎｓｐｏｒｔ Ｖ １．０」、「ＵＰｎＰＴＭ ＡＶ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｖ．８３」などの仕様書が公開されている。

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

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

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

この場合、制御情報に基づいて、ＡＶデータの再生制御、出力制御又はコピー制御を行うための課金情報、コピー制御情報、有効期限情報、有効再生回数情報など取り扱い、生成した情報を認証情報として認証手段に通知する著作権管理手段を用い、著作権管理手段から通知された認証情報に基づいて、前記パケット受信装置との間で認証処理を行うことで、ＡＶデータの前記パケット受信装置における再生制御、出力制御又はコピー制御を行う。

さらに、パケット送信装置は、著作権管理手段による制御の下で、課金情報、再生制御情報又はコピー制御情報に基づいて、パケット受信装置との間で、著作権保護の対象となるコンテンツの購入決済を行うコンテンツ購入決済手段を備える。

［２］著作権保護しつつＩＰネットワーク越しにＡＶストリームを伝送する構成の詳細
次に、著作権保護しつつＩＰネットワーク越しにＡＶストリームを伝送するための構成の詳細について説明する。

図８は、本実施の形態におけるパケット送受信部４０１の機能的な構成を示すブロック図である。

このパケット送受信部４０１は、図５に示されるパケット送信機器１０１の機能とパケット受信機器１０３の機能とを兼ね備えたパケット送受信器に用いられ、互いにパケットを送受信可能な一対のパケット送受信部の一方として表現される。このことは、以下に記述する全てのパケット送受信部について同じである。

このパケット送受信部４０１は、ＡＫＥに基づいて設定される暗号化によるパケット送受信を行う装置であり、ＩＰネットワーク越しに著作権を保護しつつＡＶストリームを伝送するための必須な構成要素として、ＡＫＥ部４０５、パケット化部４０６、送信条件設定管理部４０３、パケット受信部４１０、暗号化データ生成部４２２、ＨＴＴＰ／ＲＴＰヘッダ付加部４１６、暗号化データ復号部４１８、受信条件設定管理部４１７、フレーム化部４０８およびフレーム受信部４０９を備える。以下、伝送手順に従って、各構成要素の機能を説明すると共に、これらの必須な構成要素以外の構成要素についても適時説明する。

送信条件設定管理部４０３には非ＡＶデータが入力される。送信条件設定管理部４０３には、非ＡＶデータとして、たとえば、入力ＡＶデータ（送信データ）が入力される端子を示す入力端子情報、ＡＶデータのデータフォーマットを示すデータフォーマット情報、ＡＶデータの属性を示す属性情報を含むＡＶデータ情報、及び伝送を制御するための情報が入力される。

伝送を制御するための情報は、具体的には、送信データの種別、送信先アドレスやポート番号の情報、送信に用いるパス情報（ルーティング情報）、送信データの帯域、送信データの送信優先度などの送信条件の設定情報と、送信部（ローカル）と受信部（リモート）における機器の管理制御データと、受信状況を送信側にフィードバックするためのデータなどである。

送信条件設定管理部４０３は、これらの入力された情報に基づいて、ＡＶデータの伝送にＴＣＰ及びＵＤＰの何れを用いるかを決定し、決定されたプロトコルに従って、パケット化部４０６やフレーム化部４０８におけるヘッダやペイロードデータなどの生成を制御（パラメータの設定等を）すると共に、前記ＡＶデータを送信する際の暗号化モードを示す暗号化モード情報を生成する。

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

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

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

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

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

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

認証部４１９は、パケット送信装置とパケット受信装置が規定の条件を備えていることを検証することによって認証処理を実行する。暗号化鍵交換部４２０は、認証処理後にパケット送信装置とパケット受信装置とで暗号化鍵を共有し、入力端子情報と、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報より生成する伝送条件とにより、暗号化鍵を更新し、暗号化データ生成部４２２は、暗号化鍵を用いてＡＶデータを暗号化する。

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

パケット化部４０６は、ＡＶデータ及び一般データを別個にキューイングし、ＡＶデータのレイテンシを考慮しつつ、それぞれのデータをフレーム化部４０８に送る。

なお、認証部４１９は、パケット送信装置とパケット受信装置との間で認証を実行する認証実行モードと認証を実行しない認証不実行モードとを持ち、暗号化データ生成部４２２は、認証手段が認証実行モード及び認証不実行モードのいずれであっても、送信条件設定管理部４０３によって生成された暗号化モード情報に基づく暗号化情報ヘッダの付加を行うように制御することができる。

この場合、暗号化データ生成部４２２は、コピー制御情報がコピー制御をする旨を示す場合に、コピー制御情報を暗号化情報ヘッダとして付加し、コピー制御情報がコピー制御をしない旨を示す場合に、コピー制御情報を前記暗号化情報ヘッダとして付加しないように制御することができる。

さらに、この場合、認証部４１９は、入力端子情報と、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報より生成する認証条件とにより、パケット受信装置に含まれるパケット送受信部との間で認証を行うこともできる。ここで、パケット送受信部４０１は、さらに、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報の少なくとも１つとからなる制御認証情報を、ＡＶデータのプログラム単位毎にアクセス位置を指定するＵＲＩ情報、または、Ｑｕｅｒｙにより拡張されたＵＲＩ情報により、前記プログラムのリストとして、前記パケット受信装置に通知するアクセス位置通知手段を備える。

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

また、パケット送信装置はさらに、ＡＶデータの単位プログラムのコピー制御情報がコピー制御を行わない旨を示す場合に、ＡＶデータのデータフォーマット情報を表す第１のＭＩＭＥ−Ｔｙｐｅと、ＡＶデータに間欠的に前記暗号化情報ヘッダを付加したデータのデータフォーマット情報を表す第２のＭＩＭＥ−Ｔｙｐｅの２つのＭＩＭＥ−Ｔｙｐｅを生成し、ＡＶデータのプログラム単位毎にアクセス位置を指定する２つの拡張ＵＲＩ情報を前記パケット受信装置に提示するアクセス位置通知手段を備える。

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

また、パケット化部４０６は、送信条件設定管理部４０３によってＡＶデータの伝送プロトコルとして、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）と決定された場合は、ＴＣＰコネクションを永続的接続にして前記伝送を行うことを特徴とする場合もある。さらに、前記認証手段は、Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ（ＤＴＣＰ）方式に従って、パケット受信装置と暗号化鍵を共有するための認証と鍵交換を行うことを特徴とする。

パケット化部４０６は、ＨＴＴＰに従ったパケット化を行う場合は、レンジリクエストまたはデータ取得コマンドなどによりパケット化を行い、送信側におけるＡＶデータがＭＰＥＧの場合には、ＭＰＥＧストリームにおけるタイムベース不連続発生情報または連続性情報、ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報、ＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの時刻情報、或るＩピクチャから次のＩピクチャの間に存在するＰピクチャとＢピクチャの各個数または合計個数のうち少なくとも１つの情報を参照して前記パケット化を行う。

また、パケット化部４０６は、ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報として、ＡＶデータが複数の異なるファーマットであった場合にもオリジナルに持っている複数のＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報より、複数の異なるファーマット間で共通なＩピクチャまたはＰピクチャまたはＢピクチャ位置情報または時刻情報を生成し、この共通のＩピクチャまたはＰピクチャまたはＢピクチャ位置情報または時刻情報を用いて前記ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報の参照情報と前記パケット化を行う。

また、パケット化部４０６は、ＨＴＴＰに従ったパケット化を行う場合は、チャンク伝送方式で前記パケット化を行い、ＨＴＴＰパケットのペイロード長が前記パケット送信装置で決定された値となるように前記パケット化を行う。

また、パケット化部４０６は、ＨＴＴＰに従ったパケット化を行う場合は、ＨＴＴＰパケットのペイロード長が、暗号化情報ヘッダと整数個の前記ＡＶデータを構成するＴｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ（ＴＳ）により構成されるデータの長さ、または、暗号化情報ヘッダと整数個のタイムスタンプつきＴＳにより構成されるデータの長さとなるように前記パケット化を行う。

また、パケット化部４０６は、ＨＴＴＰによる伝送として、前記チャンク伝送方式のみならず、レンジリクエスト方式を切り替えて用いてもよい。

その場合、パケット化部４０６は、ＨＴＴＰによる伝送として、パケット送信装置の出力がライブ放送の受信信号またはライブ放送の受信チャネルの切り替えまたは蓄積されたプログラム選択時の再生信号の場合には、チャンク伝送を行い、プログラム選択後の蓄積メディアから再生されたプログラムからの再生信号の場合には、レンジリクエストを用いて再生を切替えて行う。

さらに、パケット化部４０６は、ＨＴＴＰによる伝送と、伝送データ量のオーバヘッドがより小さいＲＴＰによる伝送を切り替えて前記ＡＶデータを伝送してもよく、これによりきめこまかな再生制御を実現できる。

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

受信側では、フレーム受信部４０９は、ネットワークより入力される信号（フレーム）に対して、ＭＡＣヘッダを元にフィルタリングして受信し、ＩＰパケットとしてパケット受信部４１０に渡す。なお、一般のＥｔｈｅｒｎｅｔ（登録商標）系においては、機器のＭＡＣアドレスはルータのＳｕｂｎｅｔ境界を越えて伝送されないため、送受信機器のＭＡＣアドレスを事前に登録しておき、そのＭＡＣアドレスによる通信相手の識別を行うことによって、ＩＰパケットの伝送範囲をＩＰアドレスのＳｕｂｎｅｔ内に収めることができる。

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

送信側と、受信側で認証と鍵交換が成立すれば、暗号化したＡＶデータを送信する。

さて、図８に示されるパケット送受信部４０１における送信処理においては、パーシャルＭＰＥＧ−ＴＳ信号は、ＴＳストリーム識別部４０２に入力され、前述したストリームの種別が識別された後、コンテンツバッファ４１３に保持されることによって暗号化タイミングの調整を受けた後に、暗号化データ生成部４２２に入力される。

暗号化情報ヘッダ付加部４１５は、コピー制御情報がコピー制御をする旨を示すかコピー制御をしない旨を示すかに関係なく、送信条件設定管理部４０３によって生成された暗号化モード情報に基づく暗号化情報ヘッダの付加を行う場合もある。

パーシャルＭＰＥＧ−ＴＳは、たとえば、日本における地上や衛星やＣＡＴＶや光ファイバー配信によるデジタル放送をデジタル放送チューナで受信して、選局すると放送局より送られるフルＴＳから、番組（プログラム）を構成するパーシャルＭＰＥＧ−ＴＳが抽出される。パーシャルＭＰＥＧ−ＴＳに多重化されているＰＳＩ／ＳＩとしては、ＰＡＴ、ＰＭＴ、ＤＩＴ、ＳＩＴ（例えば、ＡＲＩＢ規格、ＳＴＤ−Ｂ２１参照）があり、ＰＡＴはＤＴＣＰデスクリプタを含んでいる。また、ＤＴＣＰデスクリプタは、アナログコピー制御情報とデジタルコピー制御情報を含んでいる。

たとえば、あるチャンネルのある番組のデジタルコピー制御情報において、ＰＭＴ第１ループのデジタルコピー制御情報とＰＭＴ第２ループのデジタルコピー制御情報が双方とも存在する場合には、ＰＭＴ第２ループのデジタルコピー制御情報を優先してその番組のデジタルコピー制御情報とする。またＰＭＴ第１ループのデジタルコピー制御情報とＰＭＴ第２ループのデジタルコピー制御情報の片方しか存在しない場合には、その存在する片方のデジタルコピー制御情報をその番組のデジタルコピー制御情報とする。

また、外部より入力される情報または、ＰＳＩ／ＳＩに多重されて送信条件設定管理部４０３に入力されるパケットデータ送信許可情報の意味が「許可」の場合、パケットが出力される。逆にパケットデータ送信許可情報の意味が、許可の反対の「禁止」の場合には、他のいかなる条件が許可であってもパケットが禁止される。このパケットデータ送信許可情報は、図面には、同じ意味を反対の論理で表したパケット化出力禁止情報として示されている。パケットデータ送信許可情報は、たとえば、パーシャルＭＰＥＧ−ＴＳのＰＭＴ第１ループまたはＰＭＴ第２ループにパケットデータ送信許可記述子として挿入する。パケットデータ送信許可記述子は基本的には１ビットでよい。

今、あるチャンネルのある番組のデジタルコピー制御情報において、ＰＭＴ第２ループのデジタルコピー制御情報がＣＯＧ（Ｃｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎ、１世代コピーのみ可能）の場合に、暗号化データ生成部４２２内の暗号化部４１４は、パーシャルＭＰＥＧ−ＴＳ信号を暗号化する。さらに、暗号化情報ヘッダ付加部４１５は、ＡＫＥ部４０５から送られてくる前述のＣＯＧを表わすＥＭＩおよび、シード情報（１ビット以上の情報）などのＡＫＥ情報を暗号化情報ヘッダとして付加し、パケット化部４０６に出力する。

また、今、あるチャンネルのある番組のデジタルコピー制御情報において、ＰＭＴ第２ループのデジタルコピー制御情報がＣＦ（Ｃｏｐｙ Ｆｒｅｅ、コピー可能）の場合に、暗号化データ生成部４２２内の暗号化部４１４は、パーシャルＭＰＥＧ−ＴＳ信号を暗号化しない。さらに、暗号化情報ヘッダ付加部４１５は、ＡＫＥ部４０５から送られてくる前述のＣＦを表わすＥＭＩ（暗号化モード情報）および、シード情報（１ビット以上の情報）などのＡＫＥ情報を暗号化情報ヘッダとして付加し、パケット化部４０６に出力する。なお、ここで、外部より暗号化情報ヘッダを付加しないように制御される場合には、暗号化情報ヘッダは付加されない。

また、外部より入力さるか、または、ＰＳＩ／ＳＩに多重されて入力されるパケットデータ送信許可情報が含まれている。たとえば、ＭＰＥＧ−ＴＳのＰＭＴの第１ループまたは第２ループが持っているデジタルコピー制御記述子（たとえば、ＡＲＩＢ ＴＲ−Ｂ１４、第２編、第４編を参照）の中にパケットデータ送信許可情報を含める。この場合、放送局など送信側の設備変更を伴う。

以上のように、暗号化実行の有無および、暗号化情報ヘッダ付加の有無は、パーシャルＴＳのコピー制御情報と外部入力や内部設定で決まられる条件により一意的に決まるように設定されている。

パケット化部４０６は、暗号化データ生成部４２２から出力されるデータに対して、送信条件設定管理部４０３からの送信条件などのパラメータを用いて、ＴＣＰ／ＩＰのヘッダを付加し、フレーム化部４０８に送る。フレーム化部４０８は、パケット化部４０６からのＩＰパケットに対して、８０２．１Ｑ（ＶＬＡＮ）方式を用いてＭＡＣヘッダを付加することでイーサネット（登録商標）フレームに変換し、送信フレームとしてネットワークに出力する。ここで、ＭＡＣヘッダ内のＴＣＩ（Ｔａｇ Ｃｏｎｔｒｏａｌ Ｉｎｆｏｒｍａｉｔｉｏｎ）内のＰｒｉｏｒｉｔｙ（ユーザ優先度）を高く設定することにより、ネットワーク伝送の優先度を一般のデータよりも高くすることができる。

図１０にパーシャルＭＰＥＧ−ＴＳを暗号化してＨＴＴＰ／ＴＣＰ／ＩＰ／Ｅｔｈｅｒｎｅｔ（登録商標）で伝送する場合のＥｔｈｅｒｎｅｔ（登録商標）フレームの一例を示す。ここで、パーシャルＭＰＥＧ−ＴＳパケット（１８８バイト）には４バイトのタイムスタンプがヘッダとして付加されている。この４バイトのタイムスタンプ２７ＭＨｚのクロックでサンプリングされたものである。

受信側では、ネットワークより入力される信号がフレーム受信部４０９でＭＡＣヘッダを元にフィルタリングされ、ＩＰパケットとしてパケット受信部４１０に入力される。パケット受信部４１０では、パケットヘッダなどの識別によりパケットのフィルタリングが行なわれ、暗号化データ復号部４１８に入力され、暗号化データ復号部４１８にて暗号化情報ヘッダを検知、ＥＭＩ（暗号化モード情報）を抽出して暗号の復号化が行い、暗号を復号化されたパーシャルＭＰＥＧ−ＴＳ信号が出力される。ここで、パーシャルＭＰＥＧ−ＴＳ信号のオリジナルのコピー制御情報はＰＭＴ内に存在しているので、コピー制御情報は送信側から受信側へ正しく継承されている。

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

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

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

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

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

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

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

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

また、パケット送受信部４０１を、パーシャルＭＰＥＧ−ＴＳデータなどを蓄積保持するように変形した例を考えることもできる。

図１１は、この変形例におけるパケット送受信部７４０１の構成を示すブロック図である。図１１において、パケット送受信部７４０１は、ＴＳストリーム識別部４０２に接続された蓄積部７０１を具備する。この構成によれば、送信条件設定管理部４０３は、放送と蓄積の両方のソースからＡＶデータを受け取ることができる。

蓄積部７０１については後で改めて詳細に説明し、ここでは、送信条件設定管理部４０３に入力されるＡＶデータの入力ソース情報として、放送及び蓄積の２種類が考えられることに注意して、説明を進める。

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

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

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

また、暗号化情報ヘッダの付加制御は、たとえば以下の様に行う。すなわち、コピーフリーコンテンツを放送する放送チャネルを受信した場合には付加しない。また、一定期間でもコピーフリーでないコンテンツを放送する放送チャネルを受信した場合には付加する。さらに、ＡＶデータが蓄積メディアよりコピーフリータイトルのコンテンツを再生した場合には付加しない。そして、ＡＶデータが蓄積メディアよりコピーフリーでないタイトルのコンテンツを再生した場合には付加する。なお、送信側における暗号化情報ヘッダの付加分される場合、ＨＴＴＰのレスポンスヘッダには、伝送されるデータ長にこの暗号化情報ヘッダの長さだけ増加したＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈが記述される。

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

ここで、サーバ型放送のＲＭＰで用いる課金情報などを含むＲＭＰＩで視聴あるいはコピー制限されたコンテンツをＲＭＰに対応していないクライアントにＣＮＭ（Ｃｏｐｙ Ｎｏ Ｍｏｒｅ）やＣＮ（Ｃｏｐｙ Ｎｅｖｅｒ）で見せるための構成について説明する。

ＤＲＭ設定管理部４０４は、コンテンツメタ情報４１２によって表されるコンテンツに関する著作権管理情報に基づいて、ＡＶデータの再生制御、出力制御又はコピー制御を行うための課金情報、コピー制御情報、有効期限情報、有効再生回数情報などを基に、認証情報を生成してＡＫＥ部４０５へ通知する。

ＡＫＥ部４０５は、ＤＲＭ設定管理部４０４から通知された認証情報に基づいて、前記パケット受信装置との間で認証処理を行うことで、ＡＶデータの前記パケット受信装置における再生制御、出力制御又はコピー制御を行う。

さらに、ＤＲＭコンテンツ購入決済部４１１は、ＤＲＭ設定管理部４０４による制御の下で、課金情報、再生制御情報又はコピー制御情報に基づいて、パケット受信装置との間で、著作権保護の対象となるコンテンツの購入決済を行ってもよい。

次に、図８において、送信キュー制御部４０７、ＡＶデータキュー、および一般データキューの動作について説明する。

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

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

送信キュー制御部４０７は、ＡＶデータキューと一般データキューにデータが存在する場合、どちらのデータを優先して出力するかの制御を行なう。通常状態では、一般データよりもＭＰＥＧ−ＴＳなどのコンテンツデータを優先制御して出力する。たとえば、パケット送受信機器間でＭＰＥＧ−ＴＳを低レイテンシ（低遅延）で伝送する場合には、ＭＰＥＧ−ＴＳ用バッファも小さくなるため、オーバーフローが発生しやすい。

送信側でＭＰＥＧ−ＴＳバッファがオーバーフローしそうになった場合、あるいは、受信側からフィードバックされた情報を参照して受信側のＭＰＥＧ−ＴＳのバッファがアンダーフローしそうになったことが判明した場合には、ＭＰＥＧ−ＴＳデータを優先出力すべくＡＶデータキューの優先度を更に適応的に上げることにより、これらバッファ破綻を回避できる。

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

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

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

送信側ではＭＰＥＧ−ＴＳ信号を暗号化データ生成部４２２に入力し、暗号化データ生成部４２２においてＭＰＥＧ−ＴＳ信号に暗号化する。その後、この暗号化されたＭＰＥＧ−ＴＳ信号をパケット化部４０６に入力され、ハードウェアアクセラレータを用いた処理によりＨＴＴＰ／ＴＣＰ／ＩＰの処理を行い、ＡＶデータキューに入力する。送信キュー制御部４０７は、一般データキューとＡＶデータキューの双方にデータが存在する場合、前述の場合と同様に、２つのキューからのデータ出力に関して優先制御を行なう。

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

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

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

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

なお、ここまでの説明において、送信条件設定管理部４０３がＡＶデータ情報取得手段、送信条件設定管理手段、及び伝送プロトコル決定手段の一例であり、ＴＳストリーム識別部４０２がデータ入力手段の一例であり、暗号化データ生成部４２２が暗号化送信データ生成手段の一例であり、ＨＴＴＰ／ＲＴＰヘッダ付加部４１６及びパケット化部４０６がパケット化手段の一例であり、ＡＫＥ部４０５が認証手段の一例であり、フレーム化部４０８が伝送手段の一例である。

［３］蓄積されているＡＶストリームの指定部分を送信する構成の詳細
次に、蓄積されているＡＶストリームの指定部分を送信するための構成の詳細について説明する。

図１１は、この説明に用いられるパケット送受信部７４０１の構成を示すブロック図である。このパケット送受信部７４０１は、図８に示されたパケット送受信部４０１の構成に加えて、蓄積部７０１を備える。以下、前述した事項と同じ事項について説明を省略し、異なる部分のみを説明する。

このパケット送受信部７４０１は、ＴＳストリーム識別部４０２に接続された蓄積部７０１を具備する。ここで、蓄積部７０１は、ハードディスクドライブ（ＨＤＤ）や光ディスク（ＣＤやＤＶＤなど）や半導体ディスク（ＳＤカードメモリなど）である。一例として、このパケット送受信部７４０１は、ハードディスクや光ディスクなどに蓄積されたパーシャルＭＰＥＧ−ＴＳデータなどをＨＴＴＰのレンジリクエストを用いて伝送する。

このレンジリクエストは、蓄積部７０１に蓄積されたパーシャルＭＰＥＧ−ＴＳのファイルの先頭からの距離、たとえばＡ、Ｂ（Ａ，ＢはＡ＜Ｂを満足する０以上の整数）でレンジ先頭とレンジ末尾を選んでリクエストされる。通常、一般データに対してＡ，Ｂは自由な値を選べるが、ＭＰＥＧ−ＴＳのような映像データをレンジＧＥＴする場合、そのＧＯＰやＰｉｃｔｕｒｅ構造に着目すれば、効率のよい伝送ができる。しかしながら、受信側は、送信側の蓄積ファイルのどの部分でＧＯＰを構成しているとか、どの部分がＩピクチャであるとかは分からない。

そこで、送信側は受信側よりＨＴＴＰのレンジリクエストを受け取ると、そのレンジ先頭とレンジ末尾にそれぞれ最も近いＧＯＰをＨＴＴＰレスポンスとして返す。この伝送方法を、ここでは、ＨＴＴＰアライメントレスポンス法（ＨＴＴＰ ＡＶ Ａｌｉｇｎｍｅｎｔ Ｄａｔａ Ｕｎｉｔ Ｒｅｓｐｏｎｓｅ Ｍｅｔｈｏｄ；ＨＡＲ法と略す）と呼ぶことにする。このような伝送モードの選択のトリガとしては、たとえば次の方法がある。

１）送信側（サーバ）と受信側（クライアント）の間でＵＰｎＰ−ＡＶなどのメカニズムを用いて事前にネゴを行う。

２）ＨＴＴＰのリクエストヘッダに、ＨＡＲ法でのレスポンスを期待してＨＡＲ法を使用することを表す文字列などの指示情報を挿入する。たとえば、
ｈａｒ−ｖａｌｕｅ ＝ ｇｏｐ
をＨＴＴＰリクエストに挿入する。

ＨＡＲ法に対応していないサーバは、この指示情報には反応しないが、ＨＡＲ法に対応しているサーバはこの指示情報に反応して、レンジリクエストされたレンジ先頭にもっとも近いＧＯＰ先頭をリクエストされたデータから探し出しレスポンスのレンジ先頭に設定する、また、レンジリクエストされたレンジ末尾にもっとも近いＧＯＰ先頭をリクエストされたデータから探し出しレスポンスのレンジ末尾に設定する。そして、サーバはＨＴＴＰのレスポンスヘッダにＨＡＲ法によるレスポンスであることを表す文字列などの指示情報を挿入する。たとえば、
ｈａｒ−ｖａｌｕｅ ＝ ｇｏｐ
をＨＴＴＰレスポンスに挿入する。

これらの動作によって、クライアントはサーバ内データに対して適当なレンジリクエストしたにもかかわらず、クライアントはＨＴＴＰレスポンスに挿入されたＭＰＥＧ−ＴＳをＧＯＰ単位で部分ＧＥＴできる。

ＭＰＥＧ−ＴＳが連続的に記録されたファイルの場合は、ひとたび、ＧＯＰ単位のレスポンスを受け取れば、映像を連続フレームで受け取りたい場合に、直前に受け取ったレンジ末尾の値より、次のＧＯＰ先頭の位置を容易に計算できる。たとえば、直前に受け取ったレンジ末尾の値１バイト足すことで次のＧＯＰ先頭の位置が分かる。

以上のように、この例では、受信側より送信側にＨＴＴＰのレンジリクエストによるデータ要求を行う場合に、伝送されるデータブロックの先頭データまたは末尾データを、送信側で管理しているＧＯＰなどのデータブロック単位の先頭データと一致させる。たとえば、データがＭＰＥＧの場合には、送信側で管理するデータブロックの単位は、上記の例で説明したＧＯＰだけでなく、Ｐｉｃｔｕｒｅまたは、マクロブロックまたは、ブロックの単位に指定することができる。また、データブロックが送信装置に内蔵されたハードディスク（ＨＤＤと略す）やＣＤやＤＶＤ（ＤＶＤ−Ｒ、ＤＶＤ−ＲＡＭなど複数の種類がある）などの光ディスク、ＳＤメモリカードのような半導体ディスクの場合には、これはＨＤＤ（たとえば５１２バイトのＬＢＡ単位）やＣＤ（たとえば、２ｋＢ単位）やＤＶＤの各記録フォーマットが、論理ブロックの単位とすることもできる。

よって、たとえば、データ（ファイルやストリーム）がＭＰＥＧの場合に、受信側より送信側にＨＴＴＰのレンジリクエストで要求するデータ範囲がＧＯＰ単位やＰｉｃｔｕｒｅ単位とデータ境界が合っていなくても、すなわち、データのアライメントが取れていなくても、サーバ（送信側）の処理としてＨＴＴＰレスポンスとして要求されたデータ範囲に近いところにあるＧＯＰ単位やＰｉｃｔｕｒｅ単位をレスポンスとして返信できる。そこで、受信側では受信データから効率よくＭＰＥＧデコードを行うことができる。

また、ＭＰＥＧ−ＴＳの例として、サーバがＢｌｕ−ｒａｙディスクレコーダーの場合、ＰＬＡＹＬＩＳＴファイルやＣＬＩＰＩＮＦＯファイルを用いて効率よくＧＯＰ境界位置やＩピクチャ位置を認識して、ＧＯＰやＩピクチャデータを取り出すことができるので、サーバの動作負荷を下げることができる。また、ＭＰＥＧ−ＰＳの場合にも、サーバがＤＶＤ−ＲＡＭディスクレコーダーで記録フォーマットがＤＶＤ−ＶＲ規格に準拠している場合、ＤＶＤ−ＶＲ方式ではＩＦＯファイルと呼ばれている管理ファイルを持っている。よって、サーバ側はこのＩＦＯファイルの管理情報を活用することにより、効率よくＧＯＰ境界位置やＩピクチャ位置を認識して、ＧＯＰやＩピクチャデータを取り出すことができるので、サーバの利用効率も上がる。以上のようにＰＬＡＹＬＩＳＴファイルやＣＬＩＰＩＮＦＯファイルやＩＦＯファイルと同様な構造を持ったデータ管理ファイルを活用することにより、サーバは容易に上述のＨＡＲ法を使用できる。

この場合、サーバはクライアントから上記ＨＡＲ法によるレンジリクエスト値を受け取り、自身の持っているＩＦＯファイルと比較して返信するＧＯＰブロックを決定する。以上により、ＡＶコンテンツにＤＴＣＰ−ＩＰを適用して伝送することが可能となる。

また、蓄積部７０１に暗号化されたコンテンツを記録しておき（いわゆるＤＲＭデジタル著作権管理による暗号化を適用したコンテンツが対象）、その記録されたコンテンツのリストを呼び出し、ユーザが視聴したいコンテンツ（映画、コンサート、ドラマなど）を選択する場合に暗号を解除するために、たとえば、次の方法を実装することができる。

方法１）ユーザは、ユーザはインターネットや電話回線を通じて、あるいはコンビニエンスストアなどで、暗号化されたコンテンツを復号するための情報を購入する。コンテンツは、ユーザが対象機器を購入した時点で、既に蓄積部７０１に、たとえば１００タイトル分の映画、コンサート、ドラマなどが記録されている場合に有効なである。

方法２）ユーザは、インターネットやＣＡＴＶ、放送を通じて、暗号化されたコンテンツをダウンロードする。さらに、ユーザはインターネットや電話回線を通じて、あるいはコンビニエンスストアなどで、暗号化されたコンテンツを復号するための情報を購入する。

方法３）ユーザがパッケージメディアとしてコンテンツを購入した際に付属しているコンテンツの暗号を復号するための情報を使用する。

［４］指定された部分の送信を効率化する構成の詳細
次に、指定された部分の送信を効率化する構成の詳細について説明する。

図１２は、この説明に用いられるパケット送受信部８４０１の構成を示すブロック図である。このパケット送受信部８４０１は、図１１に示されたパケット送受信部７４０１の構成に加えて、データ配列情報生成管理部８０１を備える。以下、前述した事項と同様の事項について説明を省略し、異なる部分のみを説明する。

このパケット送受信部８４０１は、ＴＳストリーム識別部４０２に接続されたデータ配列情報生成管理部８０１を具備する。なお、蓄積部７０１は、ハードディスクドライブ（ＨＤＤ）や光ディスク（ＣＤやＤＶＤなど）や半導体ディスク（ＳＤカードメモリなど）などである。一例として、このパケット送受信部７４０１は、ハードディスクや光ディスクなどに蓄積されたパーシャルＭＰＥＧ−ＴＳデータなどをＨＴＴＰのレンジリクエストを用いて伝送する。

このＨＴＴＰのレンジリクエストおよびレスポンスには、上述したＨＡＲ法でＩフレームに効率的にアクセスする方法について説明する。ここで、伝送モード選択のトリガとしては、たとえば次の方法がある。

１）送信側（サーバ）と受信側（クライアント）の間でＵＰｎＰ−ＡＶなどのメカニズムを用いて事前にネゴを行う。

２）ＨＴＴＰのリクエストヘッダに、ＨＡＲ法でのレスポンスを期待してＨＡＲ法を使用することを表す文字列などの指示情報を挿入する。たとえば、
ｈａｒ−ｖａｌｕｅ ＝ ｉ−ｐｉｃｔｕｒｅ ： １
をＨＴＴＰリクエストに挿入する。ここで、
ｈａｒ−ｖａｌｕｅ ＝ ｉ−ｐｉｃｔｕｒｅ ： ｎ（ｎは整数）
の動作として、サーバ内のデータ配列情報生成管理部８０１は、“ｉ−ｐｉｃｔｕｒｅ”はレンジリクエストされた範囲におけるｉ−ｐｉｃｔｕｒｅの位置情報を計算、生成する。このレンジリクエストされた範囲におけるｉ−ｐｉｃｔｕｒｅの位置情報により、蓄積部７０１はＩピクチャデータをｎ個とばしで抜き出し、クライアントに送る。ｎの値が“＋”の場合は、レンジの最初から末尾方向にｉ−ｐｉｃｔｕｒｅのみを抜き出しｎ個とばしでクライアントに送り、いわゆる、順方向のフレーム飛ばしスキップ再生を行う。ｎの値が“−”の場合は、レンジの末尾から頭方向にｉ−ｐｉｃｔｕｒｅのみを抜き出しｎ個とばしでクライアントに送り、いわゆる、逆方向のフレーム飛ばしスキップ再生を行う。

“ｈａｒ−ｖａｌｕｅ”を“ ＝ ｉ−ｐｉｃｔｕｒｅ ： ｎ（ｎは整数）”に拡張することにより、クライアントはサーバ内データに対して適当なレンジリクエストしたにもかかわらず、クライアントはＨＴＴＰレスポンスに挿入されたＭＰＥＧ−ＴＳをＩピクチャ単位で部分ＧＥＴできる。

また、サーバ内ＨＤＤに記録されたＭＰＥＧ−ＴＳの管理情報として、Ｉフレームの位置と概略サイズに関する情報があれば、その情報を用いてＩピクチャを含むデータをクライアントに送ることもできる。以上のように、サーバ内のＭＰＥＧファイルのＩフレーム位置情報を活用することにより、早送り、巻き戻し、スロー再生などの特殊再生を効率よく実現できる。そこで、一般に、ＤＲＭ対応ＡＶコンテンツをＤＴＣＰ−ＩＰを用いて伝送することが可能となる。

なお、ＨＴＴＰによる伝送をＲＴＰによる伝送を切り替えてＡＶデータを伝送してもよい。ＲＴＰの場合は、ＲＴＣＰで適当な開始位置を指定すれば、そこにＲＴＰに対応したＨＡＲ法を適用することができる。

なお、図１３に示すようなピクチャ情報ファイルを用いて、異なるＭＰＥＧファイルシステムを採用したシステムに対して、そのファイルにおけるＩ／Ｐ／Ｂピクチャの位置情報、時刻情報などを共通のピクチャ情報ファイルとして取り扱うことにより、異なるファイルフォーマットを共通のプラットフォーム上で取り扱うことが可能となる。

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

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

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

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

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

［５］タイムベースの不連続情報を伝送する構成の詳細
次に、タイムベースの不連続情報を伝送する構成の詳細について説明する。この説明に用いられるパケット送受信部の構成は、前述した図１２のパケット送受信部８４０１と同様の構成である。よって、以下では前述と同様の事項についての説明を省略し、異なる部分のみを説明する。

蓄積部７０１を用いて、ハードディスクに蓄積されたＭＰＥＧファイル（一般的なＡＶコンテンツなら何でもよい。）の複数の断片部分をＨＴＴＰプロトコルにより送信側から受信側へ伝送する場合について説明する。ＨＴＴＰプロトコルの伝送シーケンスは、たとえば、図１４（ｂ）の各ステップで表すことができる。

（ステップ−ｐ１）送信側に存在するＭＰＥＧファイルが、ＤＶＤ−ＶＲ仕様におけるＩＦＯファイルや、ＢＤ−ＲＥ仕様におけるＰＬＡＹＬＩＳＴファイルやＣＬＩＰＩＮＦファイルなどの補助データファイルを持っているかどうかを、受信側から送信側に問い合わせる。なお、図１３に示されるピクチャ情報ファイルも、補助データファイルの一例と考えることもできる。

もし、送信側が補助データファイルを持っていれば、以下のステップ−ｃ１、ステップ−ｃ２で述べる処理が実行される。

（ステップ−ｐ２）もし、送信側にステップ−ｐ１で述べた補助データファイルがなければ、その生成を受信側から送信側に要求する。

送信側がこの要求にこたえられない場合については図示を省略するが、一例として、前述したＨＡＲ法を用いて、ＨＴＴＰによる部分ＧＥＴ（レンジリクエスト）を実行することができる。

送信側がこの要求にこたえられる場合には、ＨＴＴＰによる部分ＧＥＴ（レンジリクエスト）は、以下のステップ−ｃ１、ステップ−ｃ２で述べる処理が行われる。

（ステップ−ｃ１）送信側は、受信側から要求された補助データファイルを受信側に送る。

（ステップ−ｃ２）受信側は、送信側より受け取った補助ファイルを参照してＭＰＥＧファイルの１以上の部分よりＶＯＢ単位、Ｉピクチャ単位で、ＭＰＥＧデータを要求する。たとえば、受信側は図１４（ａ）のＲａｎｇｅ、Ｎｏ．１、Ｎｏ．２、・・・、Ｎｏ．（ｎ）のｎ個のデータを要求する。

パケット化部４０６は、この伝送されるデータにおけるタイムベースの不連続点を、例えばデータ配列情報を参照することによって知り、その不連続点に不連続情報を付加する。

この処理の結果、図１４（ｃ）に示されるデータが伝送される。この伝送されるデータは、タイムベースの不連続点に、パケット化部４０６によって付加された不連続情報を含んでいる。一例として、各レンジに含まれるデータが、それぞれのレンジの中では時間的に連続していて、かつ他のレンジとの間で不連続であるとした場合には、Ｎｏ．２からＮｏ．（ｎ）までの各Ｒａｎｇｅの先頭に不連続情報が含まれる。

ここで、ＨＴＴＰプロトコルを用いたレンジリクエストのプロトコルシーケンスにおいて、一つのＲａｎｇｅに対応するデータの伝送途中でＴＣＰコネクションが切断されることによって、データが分割して伝送される場合もある。この場合、元データは時間軸で連続していても、元データの分割である複数のデータブロックはＴＣＰコネクションの確立、切断、確立、切断を繰り返して伝送されることとなる。

この状況において、例えば、従来のパーシャルＭＰＥＧ−ＴＳに適用されるＤＶＢ規格やＡＲＩＢ規格、ＳＴＤ−Ｂ２１やＴＲ−Ｂ１４，１５に準拠した処理を行ったとすると、データのタイムベースは不連続とみなされ、それぞれのデータブロックの先頭と末尾にＤＩＴなどのタイムベースの不連続情報の付加が必要となる。そのため、ＨＴＴＰレスポンスのヘッダ内のＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈが、リクエストされた本来のデータのサイズを示す値から、暗号化情報ヘッダの付加分に加えて、タイムベースの不連続情報の付加分だけ増加することになる。

なお、この暗号化情報ヘッダの付加分はパケット受信部で削除されるので、正味の伝送コンテンツとして扱わなくてよい。本実施の形態では、この暗号化情報ヘッダを正味の伝送コンテンツとして扱わないとして説明する。

本実施の形態では、パーシャルＭＰＥＧ−ＴＳをＨＴＴＰで伝送する場合の新たな仕組みとして、特にタイムベースの不連続点が、例えばデータ配列情報の内容によって、明示されない限りは、パケット化部４０６は、ＨＴＴＰのレスポンスの先頭や末尾にＤＩＴなど不連続情報を挿入しない新たなアルゴリズムをとる。

ここで、補助データファイルには、ＭＰＥＧ−ＴＳのＧＯＰ単位あるいはＩピクチャ単位でのデータ構造を記述してあるので、Ｒａｎｇｅ、Ｎｏ．１、Ｎｏ．２、・・・、Ｎｏ．（ｎ）はそれぞれ、ＭＰＥＧ−ＴＳファイルのＧＯＰ単位あるいはＩピクチャ単位とすることができ、一般的なＭＰＥＧのデコード動作（デコードのアルゴリズムとシーケンスと同等の意味で用いている）に適応した効率的なデータ伝送が実現できる。

以上のように、サーバ内のＭＰＥＧファイルのＧＯＰ構造やＩフレーム位置情報を活用することにより、早送り、巻き戻し、スロー再生などの特殊再生を効率よく実現できる。そこで、一般に、ＤＲＭ対応ＡＶコンテンツをＤＴＣＰ−ＩＰを適用して効率よく伝送することが可能となる。

なお、本実施例ではＨＴＴＰを用いたが、ＨＴＴＰの代わりにＲＴＰ用いてもよい。ＲＴＰの場合は、受信側がＲＴＣＰを用いてＭＰＥＧファイルの伝送を制御すればよい。なお、この場合は、ＨＴＴＰのように伝送サイズの計算が複雑にならないというメリットがある。

ところで、ＨＤＤやＤＶＤなどの光ディスクに蓄積されたコンテンツの蓄積フォーマットが異なる場合、クライアント（シンク）は全ての異なるコンテンツのＩフレーム位置データを格納したファイルフォーマットを識別しなければならない。フォーマット数が多くなると、多くのファイルフォーマットの解析と識別は受信側にとって大きな負担となる。

そこで、送信側におけるデータ配列情報生成管理部８０１により、異なるフォーマットのＩフレーム位置情報から、統一されたフォーマットで表されたＩフレーム位置情報を生成する。これにより、各社のＨＤＤ記録フォーマット、ＤＶＤ−ＶＲ方式、あるいはＢＤ方式など異なる蓄積フォーマットであっても、簡単に、早送り、巻き戻し、スロー再生などの特殊再生することが実現される。

このパケット化において、ＨＴＴＰは受信部からのレンジリクエストまたはデータ取得コマンドを受けて前記ＡＶデータまたは前記暗号化モード情報のうち少なくとも一方を含んだペイロードデータを伝送する。このレンジリクエストまたはデータ取得コマンドは、前記送信側における前記ＡＶデータがＭＰＥＧの場合、ＭＰＥＧストリームにおける不連続発生情報または連続性情報、前記ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報、或るＩピクチャから次のＩピクチャの間に存在するＰピクチャとＢピクチャの各個数または合計個数の内、少なくとも１つの情報を参照して実行する。

なお、ＭＰＥＧストリームにおける不連続発生情報または連続性情報とは、たとえば、ＡＲＩＢ規格、ＡＲＩＢ−ＴＲ−Ｂ１４またはＡＲＩＢ−ＴＲ−Ｂ１４の第２編に記載されているＤＩＴ情報であり、これを元に別の論理記述で不連続発生情報または連続性情報を生成することもできる。このストリームの不連続点とは、たとえば、ＭＰＥＧのパーシャルＴＳの場合、ＭＰＥＧ−ＴＳストリームのシステムタイムベースの不連続が発生する点、たとえば、ＰＣＲが不連続になる点、または、パーシャルＴＳを構成するパケットの内のどれか１つのトランスポートパケットヘッダのｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒの不連続が発生する点をさす。

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

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

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

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

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

［５．１］タイムベースの不連続情報の取り扱いの具体例
次に、ＡＶストリームの複数の部分を送信する場合のタイムベースの不連続情報の取り扱いに関して、具体的に補足説明する。

図１２における蓄積部７０１を用いて、ハードディスクに蓄積されたＭＰＥＧファイル（一般的なＡＶコンテンツなら何でもよい。）の複数の断片部分をＨＴＴＰプロトコルにより送信側から受信側へ伝送する場合について説明する。ＨＴＴＰプロトコルの伝送シーケンスは、基本的には、たとえば、図１４（ｂ）の各ステップに従う。

（ステップ−ｐ１）および（ステップ−ｐ２）は、前述と同様である。

（ステップ−ｃ１）において、送信側は、受信側から要求された補助データファイルを受信側に送る。

（ステップ−ｃ２）において、受信側は、送信側より受け取った補助ファイルを参照してＭＰＥＧファイルの１以上の部分よりＶＯＢ単位、Ｉピクチャ単位で、ＭＰＥＧデータを要求する。たとえば、受信側は図１５（ａ）に示されるＲａｎｇｅ、Ｎｏ．１、Ｎｏ．２、Ｎｏ．３の３つのデータを要求する。ここで、補助データファイルには、ＭＰＥＧ−ＴＳのＧＯＰ単位あるいはＩピクチャ単位でのデータ構造とともに、タイムベースの不連続情報（たとえば、ＤＩＴ）を記述してある。そこで、受信側に伝送されるデータであるＲａｎｇｅ、Ｎｏ．１、Ｎｏ．２、Ｎｏ．３はそれぞれ、タイムベースの不連続点を含んだＭＰＥＧ−ＴＳファイル内のＧＯＰ単位データブロックあるいは、Ｉピクチャ単位データブロックとなる。

図１５（ａ）の送信データは、同図中、Ｒａｎｇｅ、Ｎｏ．１の右側の矢印で示しているようにＲａｎｇｅ、Ｎｏ．１の途中にタイムベースの不連続点を含んでいる。また、同図中、Ｒａｎｇｅ、Ｎｏ．３の先頭部の右側の矢印で示しているようにＲａｎｇｅ、Ｎｏ．３の先頭にタイムベースの不連続点を持つ。

この場合に伝送されるデータは図１５（ｂ）のように表され、Ｒａｎｇｅ Ｎｏ．１の途中にあるタイムベースの不連続点、及びＲａｎｇｅ Ｎｏ．２、Ｎｏ．３の先頭に、それぞれタイムベースの不連続情報が含まれる。

なお、送信側における暗号化情報ヘッダの付加分はパケット受信部で削除されるので、本説明でも正味の伝送コンテンツとして扱わないものとする。

また、伝送プロトコル（例えばＴＣＰ）によって、送信データがコネクションの切断を伴って分割される場合でも、元データが時間的に連続している限りは、分割されたそれぞれの送信データの先頭又は末尾に不連続情報が付加されない点についても前述したとおりである。

以上、一般的なＭＰＥＧのデコード動作（ＭＰＥＧデコードのアルゴリズムまたはシーケンスと同等の意味）に対して効率的なデータ伝送が実現できる。サーバ内のＭＰＥＧファイルのＧＯＰ構造やＩフレーム位置情報を活用することにより、早送り、巻き戻し、スロー再生などの特殊再生を効率よく実現できる。そこで、一般に、ＤＲＭ対応ＡＶコンテンツをＤＴＣＰ−ＩＰを適用して効率よく伝送することが可能となる。

［５．２］無効データの取り扱いの具体例
次に、先頭又は末尾、若しくはその両方に無効データを持つ複数の部分を送信する場合の、その無効データの取り扱いに関して、具体的に補足説明する。

図１２における蓄積部７０１を用いて、ハードディスクに蓄積されたＭＰＥＧファイル（一般的なＡＶコンテンツなら何でもよい。）の複数の断片部分をＨＴＴＰプロトコルにより送信側から受信側へ伝送する場合について説明する。ＨＴＴＰプロトコルの伝送シーケンスは、基本的には、たとえば、図１４（ｂ）の各ステップに従う。

（ステップ−ｐ１）および（ステップ−ｐ２）は、前述と同様である。

（ステップ−ｃ１）において、送信側は、受信側から要求された補助データファイルを受信側に送る。

（ステップ−ｃ２）において、受信側は、送信側より受け取った補助ファイルを参照してＭＰＥＧファイルの１以上の部分よりＶＯＢ単位、Ｉピクチャ単位で、ＭＰＥＧデータを要求する。たとえば、受信側は図１６（ａ）のＲａｎｇｅ、Ｎｏ．１、Ｎｏ．２、Ｎｏ．３の３つのデータを要求する。ここで、補助データファイルは、記録メディアの論理フォーマット情報をベースとして、その論理フォーマット上にパーシャルＭＰＥＧ−ＴＳやＤＶストリームが配置（マッピング）されている。

この配置方法としては、たとえば、ＢＤ−ＲＥ規格（Ｂｌｕ−ｒａｙ Ｄｉｓｋ Ｒｅｗｒｉｔａｂｌｅ ＦｏｒｍａｔのＰａｒｔ１、Ｐａｒｔ２、Ｐａｒｔ３）において規定されているＰｌａｙＬｉｓｔファイルやＣｌｉｐＩｎｆｏｒｍａｔｉｏｎファイルを参照することにより、ＢＤ−ＲＥ対応のディスク上へのパーシャルＭＰＥＧ−ＴＳの配置方法である。ＰｌａｙＬｉｓｔファイルやＣｌｉｐＩｎｆｏｒｍａｔｉｏｎファイルを参照することにより、ＢＤ−ＲＥ対応のディスク上へのパーシャルＭＰＥＧ−ＴＳの配置の対応付けについては、たとえば、松下テクニカルジャーナル、２００４年１０月、３４ページから３８ページ、「Ｂｒｕ−ｒａｙ Ｄｉｓｋ Ｒｅｗｒｉｔａｂｌｅ Ｆｏｒｍａｔ（２）〜論理規格、著作権保護規格〜」や、日経エレクトロニクス、２００３年７月２１日号、１２５〜１３８ページ、で説明されている。

さて、ＢＤ−ＲＥ対応ディスクのようにデータ記録用論理セクタ（たとえば、ＨＤＤではＬＢＡに相当し、数百から数ｋバイトに設定される）へのパーシャルＭＰＥＧ−ＴＳの配置としては、必ずしも論理セクタ先頭と補助データ付きパーシャルＭＰＥＧ−ＴＳ先頭とは一致しない。そこで、論理セクタ番号とその論理セクタ内の先頭からのオフセット（位置）情報のペアにより、パーシャルＭＰＥＧ−ＴＳなどの記録データ位置を表わすことができる。

ディスク上に記録されたパーシャルＭＰＥＧ−ＴＳの位置情報が、論理セクタ番号とその論理セクタ内の先頭からのオフセット（位置）情報のペアで管理されている場合、そのセクタの先頭から記録されている直前の位置までに存在データは不要なデータなデータである。特に編集を行うと、この不要データだけではＭＰＥＧデコードができなくなるので、使い道のないゴミデータとなる。

本実施例では、ディスク上に記録されたパーシャルＭＰＥＧ−ＴＳの位置情報が、論理セクタ番号とその論理セクタ内の先頭からのオフセット（位置）情報のペアで管理されている場合、ネットワークを介してクライアントからサーバに対して、このような不要なデータを考慮して、有効データのみに効率的にアクセスして、スムースな特殊再生やその伝送を実現する。

さて、クライアントはサーバに対して、図１６（ａ）に示されたＲａｎｇｅ、Ｎｏ．１、Ｎｏ．２、Ｎｏ．３の３つのデータを要求（ＨＴＴＰのリクエスト）する。ここで、サーバ内の補助データファイルには、ＭＰＥＧ−ＴＳのＧＯＰ単位あるいはＩピクチャ単位でのデータ構造とともに、タイムベースの不連続情報（たとえば、ＤＩＴ）、および、ディスク上に記録されたパーシャルＭＰＥＧ−ＴＳの位置情報として論理セクタ番号とその論理セクタ内の先頭からのオフセット（位置）情報のペア情報などの補助データを記述してあり、クライアントはネットワークを介してサーバ内の補助データを参照する。

これにより、クライアントはサーバ内ディスクのセクタ上に記録されたパーシャルＭＰＥＧ−ＴＳのＧＯＰ，Ｉピクチャなどの有効データを直接アクセス（ＨＴＴＰのレンジＧＥＴで必要名データをリクエストできる）できる。

図１６（ａ）に示されたＲａｎｇｅ、Ｎｏ．１、Ｎｏ．２の先頭と末尾には、それぞれ、黒い小さなブロックで表現される不要データが存在する。また、図１６（ａ）の送信データは、Ｒａｎｇｅ、Ｎｏ．１の右側の矢印で示しているようにＲａｎｇｅ、Ｎｏ．１中にタイムベースの不連続点を含んでいる。また、同図中、Ｒａｎｇｅ、Ｎｏ．３の先頭部の右側の矢印で示しているようにＲａｎｇｅ、Ｎｏ．３の先頭にタイムベースの不連続点を持つ。

この場合、受信側に送られるデータはＲａｎｇｅ、Ｎｏ．１、Ｎｏ．２、Ｎｏ．３それぞれにおいてタイムベースの不連続点を含んだ、無効データを除いた有効データブロックとなる。

受信データは、図１６（ｂ）に具体的に示されるように、（ｃ３−１）送信元の無効データを含まないで、かつタイムベースの不連続情報を含んだＲａｎｇｅ Ｎｏ．１の情報、（ｃ３−２）送信元の無効データを含まないＲａｎｇｅ Ｎｏ．２の情報、及び（ｃ３−３）タイムベースの不連続情報を先頭に付与されたＲａｎｇｅ Ｎｏ．３の情報である。

なお、送信側における暗号化情報ヘッダの付加分はパケット受信部で削除されるので、本説明でも正味の伝送コンテンツとして扱わないものとする。

また、伝送プロトコル（例えばＴＣＰ）によって、送信データがコネクションの切断を伴って分割される場合でも、元データが時間的に連続している限りは、分割されたそれぞれの送信データの先頭又は末尾に不連続情報が付加されない点についても前述したとおりである。

以上のように、タイムベースの不連続点を含んだ、無効データを除いた有効データブロックをサーバからクライアントに伝送制御することによって、一般的なＭＰＥＧのデコード動作（ＭＰＥＧデコードのアルゴリズムまたはシーケンスと同等の意味）に対して効率的なデータ伝送が実現できる。サーバ内のＭＰＥＧファイルのＧＯＰ構造やＩフレーム位置情報を活用することにより、早送り、巻き戻し、スロー再生などの特殊再生を効率よく実現できる。そこで、一般に、ＤＲＭ対応ＡＶコンテンツをＤＴＣＰ−ＩＰを適用して効率よく伝送することが可能となる。

［６］コピー制御情報を専用の伝達経路を用いて伝達する変形例
次に、コピー制御情報（ＣＣＩ）を専用の伝達経路を用いて伝達する変形例について説明する。本変形例におけるパケット送受信部１７４０１の構成を図１７に示す。

図１７に示されるパケット送受信部は、図１２のパケット送受信部８４０１と基本的に同様の構成であるが、図１７ではＣＣＩバッファ１７０１を具備し、ＴＳストリーム識別部４０２から暗号化データ生成部４２２へ、ＣＣＩバッファ１７０１を含む専用の伝達経路でＣＣＩを伝達する点で異なっている。以下では、前述と同様の事項については説明を省略し、異なる部分のみを説明する。

図１７において、ＴＳストリーム識別部４０２からコンテンツバッファ４１３に出力する信号は、各パーシャルＭＰＥＧ−ＴＳに４バイトのヘッダが付加されたストリームで、蓄積を想定したヘッダつきパーシャルＭＰＥＧ−ＴＳ（「蓄積型パーシャルＭＰＥＧ−ＴＳ」と呼ぶ）であるとする。ここで、この蓄積を想定したヘッダである４バイト（３２ビット）は、２ビットのＣＣＩと３０ビットのタイムスタンプにより構成されている。また、２ビットのＣＣＩは蓄積を想定したＣＣＩであり、暗号化しないコピーフリーモード（ＣＦ）、暗号化を行うコピーフリーモード（ＣＦ／ＥＰＮ：Ｅｎｃｒｉｐｔｉｏｎ ｐｌｕｓ ｎｏｎ−Ｉｎｓｅｒｓｉｏｎ）、コピーノーモアモード（ＣＮＭ）の３つのモードしかサポートしていない。この場合、コンテンツバッファ４１３が扱う信号形式は、たとえば、ＣＯＧモードやコピーネバー（ＣＮ）モードのＣＣＩをサポートしていない。

さて、日本の地上デジタル放送のような１世代のみコピー可能（ＣＯＧ）なコンテンツ（２００５年２月現在）を、一度、ＨＤＤに蓄積して再生する場合は、ＣＯＧの放送コンテンツは蓄積によりＣＮＭコンテンツになるので、その再生出力を「蓄積型パーシャルＭＰＥＧ−ＴＳ」形式で暗号化データ生成部４２２に渡して、「蓄積型パーシャルＭＰＥＧ−ＴＳ」形式のヘッダのＣＣＩにしたがって正常な暗号化、および暗号化ヘッダの付加ができる。

しかしながら、地上デジタル放送のＣＯＧコンテンツを、蓄積せずに直接、従来形式としての「蓄積型パーシャルＭＰＥＧ−ＴＳ」形式で暗号化データ生成部４２２に出力すると、「蓄積型パーシャルＭＰＥＧ−ＴＳ」形式では新たなモードとしてのＣＯＧモードをサポートしていないために、暗号化データ生成部４２２に正しいＣＣＩを継承して、「蓄積型パーシャルＭＰＥＧ−ＴＳ」形式のヘッダのＣＣＩにしたがって正常な暗号化、および暗号化ヘッダの付加ができない。

そこで、本実施例では、ＴＳストリーム識別部４０２から暗号化部４１４および暗号化情報ヘッダ付加部４１５に対して、正しいＣＣＩを伝えるためにＣＣＩバッファ１７０１を新たに追加する。

暗号化部４１４は、ＣＣＩバッファ１７０１、暗号化部４１４および暗号化ヘッダ付加部４１５は、ＣＯＧモードを含むパケット送受信部が使用する全てのＣＣＩを送るサポートする。ＣＣＩバッファ１７０１は、ＣＣＩバッファ１７０１を介して、コンテンツバッファ４１３のストリーム出力と同期して、暗号化部４１４および暗号化情報ヘッダ付加部４１５に対して正しいＣＣＩを伝える。これにより、ＣＯＧモードを含んだ、コンテンツバッファが扱う信号形式が、たとえば、ＣＯＧモードのＣＣＩがサポートしていなくても、正しいＣＣＩで暗号化および暗号化ヘッダの付加が可能となる。

以上のように、パケット送受信部１７４０１が従来の形式にしか対応していないため、内部で扱うＡＶストリームのヘッダが、そのパケット送受信部１７４０１で扱う全てのＣＣＩモードに対応していない場合、パケット送受信部１７４０１が取り扱う全てのＣＣＩモードを取り扱う経路とストリームの暗号化とタイミングを合わせるバッファを具備することにより、従来構成のパケット送受信部でも新たなＣＣＩモードの追加が可能となる。

このＣＣＩモードのサポートは送信側だけでなく、受信側でも送信側同様にＣＣＩモード専用の経路およびバッファを設けることにより、同様の効果を発揮できる。

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

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

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

さらに、上記実施の形態では、通信網プロトコルとしてイーサネット（登録商標）を例としたが、本発明は、この限りではなく、ＩＥＥＥ ８０２．１１ａ／ｂなどの無線のプロトコルをもちいることもできる。

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

パケット化部は、ＡＶデータを構成するデータブロックにタイムスタンプを付加し、１つ以上のタイムスタンプ付データブロックをまとめてＲＴＰまたはＨＴＴＰのペイロードとしてマッピングすることによって前記パケット化を行える。

また、パケット化手段は、ＡＶデータをＭＰＥＧ−ＴＳで伝送する場合、各ＴＳパケットにタイムスタンプを付加し、複数のタイムスタンプ付ＴＳパケットをまとめてＲＴＰまたはＨＴＴＰ上にマッピングする。

また、各ＴＳパケットに付加するタイムスタンプのクロックはＭＰＥＧのシステムクロック周波数に等しく、パケット送信装置はさらに、ＴＳパケットを受信し、受信したＴＳパケットに付加されたタイムスタンプより、ＭＰＥＧ−ＴＳのネットワーク伝送によりＰｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ（ＰＣＲ）に付加された伝送ジッターを除去して、ＭＰＥＧシステムクロックの再生を行うクロック再生手段を備える。

さらに、パケット化手段は、外部入力されたＴＳに付加されたタイムスタンプの有効ビット数または蓄積メディアから再生されたＴＳに付加されたタイムスタンプの有効ビット数が各ＴＳパケットに付加するタイムスタンプの有効ビット数と異なる場合に、ＭＰＥＧストリームのＰＣＲが不連続になりシステムタイムベースの不連続が発生しない時、また、ＴＳのｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒの不連続が発生しない時は、前記外部入力されたＴＳに付加されたタイムスタンプまたは蓄積メディアから再生されたＴＳに付加されたタイムスタンプと、ＴＳパケットに付加するタイムスタンプとを変えずに載せ変えだけを行ない、ストリームのＭＰＥＧのＰＣＲが不連続になりシステムタイムベースの不連続が発生するポイントまたはＴＳのｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒの不連続が発生するときは、不連続の発生点でＴＳの不連続発生を通知するＴＳパケットを挿入することで、パケット化を行う。

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

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

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

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

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

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

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

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

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

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

本発明は、地上デジタル放送などを受信して、その選局信号をＩＰネットワークを介し別室のテレビやパソコンに伝送してリモート視聴を可能にする。また、デジタル放送の受信信号をＨＤＤやＤＶＤディスクに記録し、その再生信号をＩＰネットワークを介して別室から記録コンテンツのタイトル選択や、特殊再生を行いながら、リモート視聴することを可能とする。特に、デジタル放送やＤＶＤディスクなどコピー制限されたコンテンツをその著作権者によって設定されたコピー制御情報の継承処理するため違法コピーを禁止できる。

【０００７】
ケット受信装置に伝送する伝送手段とを備え、前記ＡＶデータが、事前に定めた大きさの複数のデータブロック領域により構成される記録メディアに蓄積され、前記ＡＶデータの記録位置が、前記データブロック領域の識別番号と前記データブロック領域の先頭からのオフセット情報とにより管理される場合に、前記識別番号と前記オフセット情報とにより指定される範囲外に記録されている不要データを除外することにより、前記ＡＶデータのみをパケット化して前記パケット受信装置へ伝送する。
［００２５］
また、前記認証手段は、前記パケット送信装置内における前記ＡＶデータのＵＲＩ情報または拡張ＵＲＩ情報を用いて、前記パケット受信装置との間で前記ＡＶデータのアドレス情報の取得および認証処理を行ってもよい。
［００２６］
また、前記パケット化手段は、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌによるデータ伝送において、伝送される前記ＡＶデータが通信回線におけるコネクションの張り直しのために分断される箇所には、ＭＰＥＧストリームのシステムタイムベースの不連続を表す情報を付加しないことが好ましい。
［００２７］
また、前記パケット化手段はＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌレスポンスに挿入するデータ長は、元のデータ長に前記タイムベースの不連続を表す情報の長さ分を付加した長さとしてもよく、またその場合に、送信データ中の有効データの開始位置または終了位置に関する情報に前記タイムベースの不連続を表す情報の長さ分だけオフセットさせて有効データを取得するためのオフセット情報を伝えてもよい。
［００２８］
なお、本発明は、このようなパケット送信装置として実現できるだけでなく、パケット送信方法として実現したり、パケット送信装置のためのプログラムとして実現したり、そのプログラムを記録したコンピュータ読み取り可能なＣＤ−ＲＯＭやＤＶＤ−ＲＡＭなどの記録媒体としても実現できる。
［発明の効果］
［００２９］
本願発明のパケット送信装置によれば、ＭＰＥＧ−ＴＳ信号などのＡＶストリームを外部から与えられる一定規則による送信条件に従い暗号化モードを決め、さらに暗号化情報ヘッダを付加することを決めることにより、パケット送受信機器間での信号の互換性を確保しながら、ＨＴＴＰプロトコルやＲＴＰプロトコルなどを利用しながらＡＶストリームの秘匿性を保つことが可能となる。ここで、ストリームのコピー制御情報（ＣＣＩ；Ｃｏｐｙ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）は外部から与えられ、暗号化情報ヘッダを付加するかどうか、および、伝送の暗号化モードなどを決定する。
［００３０］
これにより、ＭＰＥＧ−ＴＳ信号などのＡＶストリームをそのコピー制御情報に従い暗号化モードを決め、暗号化情報ヘッダを付加した後、パケット化して伝送するので、ＡＶコンテンツの著作権者が設定したコピー制御モードを漏れなく正しく継承すること

本発明は、ＩＥＥＥ８０２．３などのイーサネット（登録商標）（有線ＬＡＮ）やＩＥＥＥ８０２．１１などの無線ＬＡＮなどを用いて、暗号化されたＡＶストリームをＩＰパケット化して高品質に送信するパケット送信装置に関し、特にＩＰネットワーク越しにコンテンツ保護を図りつつ、かつ早送り、巻き戻し、スロー再生などの特殊再生に適した形態でＡＶストリームを送信する技術に関する。

近年の通信技術の発展に伴い、効率よくパケットを伝送する様々な技術が提案されている（例えば、特許文献１参照）。その一つとして、従来、一般家庭において、部屋内でデジタル放送チューナやＤＶＨＳ方式ビデオレコーダー間をＩＥＥＥ １３９４方式デジタルインターフェースで接続し、ＩＥＣ ６１８８３−４で規定されたＭＰＥＧ−ＴＳ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ／Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）信号の伝送が行われている。ここで、放送コンテンツにコピーワンジェネレーション（Ｃｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎ）などコンテンツ保護がかかっている場合、コンテンツを不正コピーから保護するため、コンテンツを暗号化して伝送している。

この様にデジタル放送を受信・選局して得られたＭＰＥＧ−ＴＳなどのＡＶデータを暗号化して伝送する方式の一例として、ＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）方式が規定されている。ＤＴＣＰは、ＩＥＥＥ１３９４やＵＳＢなどの伝送メディア上のコンテンツ保護技術である。ＤＴＣＰ方式は、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｃｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）で規格化された方式であり、 ＨＹＰＥＲＬＩＮＫ“ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ” ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ、 ＨＹＰＥＲＬＩＮＫ “ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｄｔｃｐ＃ｔｕｔ．ｐｄｆ” ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｄｔｃｐ＃ｔｕｔ．ｐｄｆ、ＨＹＰＥＲＬＩＮＫ “ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｗｐ＃ｓｐｅｃ．ｐｄｆ” ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｗｐ＃ｓｐｅｃ．ｐｄｆや、書籍「ＩＥＥＥ１３９４、ＡＶ機器への応用」、高田信司監修、日刊工業新聞社、「第８章、コピープロテクション」、１３３〜１４９ページで説明されている。

ＭＰＥＧ−ＴＳについて説明する。トランスポートストリームはトランスポートパケット（ＴＳ ｐａｃｋｅｔ）が複数個集まったものである。ＴＳ ｐａｃｋｅｔは１８８ｂｙｔｅの固定長パケットで、その長さはＡＴＭのセル長との整合性およびリードソロモン符号などの誤り訂正符号化を行なう場合の適用性を考慮して決定されている。ＴＳ ｐａｃｋｅｔは４ｂｙｔｅ固定長のパケットヘッダと可変長のアダプテーションフィールド（ａｄａｐｔａｔｉｏｎ ｆｉｅｌｄ）およびペイロード（ｐａｙｌｏａｄ）で構成される。パケットヘッダにはＰＩＤ（パケット識別子）や各種のフラグが定義されている。このＰＩＤによりＴＳ ｐａｃｋｅｔの種類を識別する。

ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄとｐａｙｌｏａｄは、片方のみが存在する場合と両方が存在する場合があり、その有無はパケットヘッダ内のフラグ（ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄ＿ｃｏｎｔｒｏｌ）により識別できる。ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄは、ＰＣＲ（Ｐｒｏｇｒａｍ＿Ｃｌｏｃｋ＿Ｒｅｆｅｒｅｎｃｅ）等の情報伝送およびＴＳ ｐａｃｋｅｔを１８８ｂｙｔｅ固定長にするためのＴＳ ｐａｃｋｅｔ内でのスタッフィング機能を持つ。

また、ＰＣＲは２７ＭＨｚのタイムスタンプで、符号化した時の基準時間を復号器のＳＴＣで再現するためにＰＣＲの値が参照される。ＭＰＥＧ−２のＴＳでは復号器のＳＴＣ（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）はＰＣＲによるＰＬＬ同期機能を持つ。このＰＬＬ同期の動作を安定させるためにＰＣＲの送信間隔は最大０．１ｍｓである。映像や音声などの個別ストリームが収められたＭＰＥＧのＰＥＳパケットは同じＰＩＤ番号を持つ複数のＴＳ ｐａｃｋｅｔのｐａｙｌｏａｄに分割して伝送する。また、ＰＥＳパケットの先頭は、ＴＳ ｐａｃｋｅｔの先頭から開始するように構成される。

トランスポートストリームは複数のプログラムを伝送することができるため、ストリームに含まれているプログラムとそのプログラムを構成している映像や音声ストリームなどのプログラムの要素との関係を表すテーブル情報が用いられる。このテーブル情報はＰＳＩ（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）と呼ばれ、ＰＡＴ（Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅ）、ＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）などのテーブルを用いる。ＰＡＴ、ＰＭＴなどのＰＳＩはセクションと呼ばれる単位でＴＳ ｐａｃｋｅｔの中のｐａｙｌｏａｄに配置されて伝送される。

ＰＡＴにはプログラム番号に対応したＰＭＴのＰＩＤなどが指定されており、ＰＭＴには対応するプログラムに含まれる映像、音声、付加データおよびＰＣＲのＰＩＤが記述されるため、ＰＡＴとＰＭＴを参照することにより、ストリームの中から目的のプログラムを構成するＴＳ ｐａｃｋｅｔだけを取り出すことができる。

ＴＳに関する参考文献としては、例えば、ＣＱ出版社、ＴＥＣＨ Ｉ Ｖｏ．４、「画像＆音声圧縮技術のすべて（インターネット／ディジタルテレビ、モバイル通信時代の必須技術）」、監修、藤原洋、第６章、「画像や音声を多重化するＭＰＥＧシステム」があり、同書にて解説されている。

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

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

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

図２は、ＤＴＣＰ方式における従来のパケット通信部の概略を説明する図であり、ここでは、図１のソース９０１が備えるパケット送信部およびシンク９０２が備えるパケット受信部の両方がパケット送受信部として示されている。まず、ＤＴＣＰ方式に準拠した認証と鍵交換（Ａｕｔｈｅｎｔｉｆｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ、ＡＫＥと略する）が行なわれる。ＡＫＥ部１００１に対して、その認証と鍵交換の設定情報が入力され、この情報がパケット化部１００２に伝達され、パケット化部１００２において規定のヘッダが付加されたパケット化が行われ、ネットワーク１００７に出力される。

ここで、パケット化部１００２は、送信条件設定部１００３により決定された送信パラメータにより、入力データのパケット化および送信を行なう。受信側では、ネットワーク１００７より入力する信号がパケット受信部１００４でパケットヘッダなどの識別によりフィルタリングされ、ＡＫＥ部１００１に入力される。これにより送信側（ソース）のＡＫＥ部と、受信側（シンク）のＡＫＥ部がネットワーク１００７を介してお互いにメッセージの通信ができる。すなわち、ＤＴＣＰ方式の手順に従い、認証と鍵交換を実行する。

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

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

ソースでは暗号鍵を時間的に変化させるために、時間的に変化するシード情報を生成し、シンクに送信する。ソースでは、交換鍵とシード情報より暗号化鍵を生成して、ＭＰＥＧ−ＴＳをこの暗号化鍵を用いて暗号化部で暗号化してシンクに送信する。シンクはシード情報を受信し交換鍵とシード情報より復号鍵を復元する。シンクではこの復号鍵を用いて暗号化されたＭＰＥＧ−ＴＳ信号を復号する。

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

以上述べたように、従来のＤＴＣＰ方式に従って、ＭＰＥＧ−ＴＳ信号は、ＩＥＥＥ１３９４に規定される伝送線路を介してコンテンツ保護を図りつつ伝送される。
特開２０００−５９４６３号公報

しかしながら、上記従来のＤＴＣＰ方式は、インターネットの標準プロトコルであるＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ）を用いて、イーサネット（登録商標）（ＩＥＥＥ８０２．３）、無線ＬＡＮ（ＩＥＥＥ８０２．１１）や、その他のＩＰパケットを伝送可能なネットワーク越しに、従来と同様のコンテンツ保護を図りつつ伝送するための技術を示していない。

とりわけ、サーバのハードディスクなどに蓄積されたコンテンツを、端末からの要求に応じて、コンテンツ保護を図った上で、早送り、巻き戻し、スロー再生などの特殊再生を簡単に実現可能な形態で、要求元の端末へ伝送するための有効な技術は、いまだ知られていないのが現状である。

デジタルＴＶやホームサーバが家庭に急速に普及浸透し、家庭内のデジタルＴＶやホームサーバによって放送等から取得されたデジタル著作権保護対応のコンテンツを、ＩＰネットワークによって実現されている家庭内ＬＡＮ越しに、家庭内のパソコン等の様々な機器で視聴したいというニーズが高まっており、ユーザは、そのような視聴の際にも、早送り、巻き戻し、スロー再生などの特殊再生の利便を享受したいと考えるが、従来の技術をもっては、そのようなユーザの期待に応えることができない。

本発明は、このような状況に鑑みてなされたものであり、ＡＶコンテンツを、コンテンツ保護を図りつつ、ＨＴＴＰプロトコルやＲＴＰプロトコルなどを利用してＩＰネットワーク越しに送信し、とりわけ早送り、巻き戻し、スロー再生などの特殊再生に適した形態で送信することが可能なパケット送信装置を提供することを目的とする。

上記目的を達成するために、本発明に係るパケット送信装置は、パケット受信装置にパケットデータを送信するパケット送信装置であって、ＡＶデータが入力される端子を示す入力端子情報、前記ＡＶデータのデータフォーマットを示すデータフォーマット情報、または、前記ＡＶデータの属性を示す属性情報のうち少なくとも１つの情報を含むＡＶデータ情報を取得するＡＶデータ情報取得手段と、前記ＡＶデータ及び非ＡＶデータの入力を受け付けるデータ入力手段と、前記非ＡＶデータまたは前記ＡＶデータより、前記ＡＶデータの課金情報、再生制御情報、または、コピー制御情報、パケットデータ送信許可情報、送信相手のＭＡＣアドレス情報のうち少なくとも１つの情報を抽出し、抽出した情報から、前記ＡＶデータを送信する際の暗号化モードを示す暗号化モード情報を生成する送信条件設定管理手段と、前記入力端子情報、前記データフォーマット情報及び前記属性情報を組み合わせて決定される送信条件に基づいて、前記データ入力手段より入力された前記ＡＶデータの暗号化制御を行い、前記暗号化モード情報に基づく暗号化情報ヘッダを暗号化制御された前記ＡＶデータに付加することによって暗号化情報ヘッダ付き被暗号化制御送信データを生成する暗号化送信データ生成手段と、前記暗号化送信データ生成手段により生成された暗号化情報ヘッダ付き被暗号化制御送信データを含んだデータに対して、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ、及びＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌのうち、１つ以上のプロトコルを組み合わせたパケットヘッダを付加すると共に、前記ＡＶデータにおけるタイムベースの不連続が発生する点にＭＰＥＧストリームのシステムタイムベースの不連続を表す情報を付加することによってパケットを生成するパケット化手段と、前記パケット受信装置との間で認証処理を行う認証手段と、前記入力端子情報、前記属性情報及び前記パケット受信装置より指定される送信モードを示す情報の少なくとも１つを用いて、前記パケット送信装置と前記パケット受信装置の間での前記ＡＶデータの伝送プロトコルを決定する伝送プロトコル決定手段と、前記認証処理によって前記パケット受信装置との認証処理が完了した後に、前記伝送プロトコル決定手段によって決定された伝送プロトコルに従って、前記パケット化手段によって生成された暗号化情報ヘッダ付き被暗号化制御送信データを含むパケットを前記パケット受信装置に伝送する伝送手段とを備え、前記ＡＶデータが、事前に定めた大きさの複数のデータブロック領域により構成される記録メディアに蓄積され、前記ＡＶデータの記録位置が、前記データブロック領域の識別番号と前記データブロック領域の先頭からのオフセット情報とにより管理される場合に、前記識別番号と前記オフセット情報とにより指定される範囲外に記録されている不要データを除外することにより、前記ＡＶデータのみをパケット化して前記パケット受信装置へ伝送する。

また、前記認証手段は、前記パケット送信装置内における前記ＡＶデータのＵＲＩ情報または拡張ＵＲＩ情報を用いて、前記パケット受信装置との間で前記ＡＶデータのアドレス情報の取得および認証処理を行ってもよい。

また、前記パケット化手段は、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌによるデータ伝送において、伝送される前記ＡＶデータが通信回線におけるコネクションの張り直しのために分断される箇所には、ＭＰＥＧストリームのシステムタイムベースの不連続を表す情報を付加しないことが好ましい。

また、前記パケット化手段はＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌレスポンスに挿入するデータ長は、元のデータ長に前記タイムベースの不連続を表す情報の長さ分を付加した長さとしてもよく、またその場合に、送信データ中の有効データの開始位置または終了位置に関する情報に前記タイムベースの不連続を表す情報の長さ分だけオフセットさせて有効データを取得するためのオフセット情報を伝えてもよい。

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

本願発明のパケット送信装置によれば、ＭＰＥＧ−ＴＳ信号などのＡＶストリームを外部から与えられる一定規則による送信条件に従い暗号化モードを決め、さらに暗号化情報ヘッダを付加することを決めることにより、パケット送受信機器間での信号の互換性を確保しながら、ＨＴＴＰプロトコルやＲＴＰプロトコルなどを利用しながらＡＶストリームの秘匿性を保つことが可能となる。ここで、ストリームのコピー制御情報（ＣＣＩ；Ｃｏｐｙ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）は外部から与えられ、暗号化情報ヘッダを付加するかどうか、および、伝送の暗号化モードなどを決定する。

これにより、ＭＰＥＧ−ＴＳ信号などのＡＶストリームをそのコピー制御情報に従い暗号化モードを決め、暗号化情報ヘッダを付加した後、パケット化して伝送するので、ＡＶコンテンツの著作権者が設定したコピー制御モードを漏れなく正しく継承することができる。よって、トータルなシステムとしてＡＶコンテンツの著作権保護を図りつつ、パケット送受信機器間での信号の互換性を確保することが可能となる。

しかも、送信されるＡＶストリームにはタイムベースの不連続点にその旨を表す情報が付加されるので、ＡＶストリームを供給される前記パケット受信装置においてタイムベースの不連続点が明らかとなり、早送り、巻き戻し、スロー再生などの特殊再生を滑らかに行うことが可能となる。

以下、本発明の実施の形態について、図面を用いて詳細に説明する。

本発明の実施の形態におけるパケット送信装置は、ＩＰネットワーク越しに、パケット受信装置から要求されたＡＶストリームの部分を前記パケット受信装置へ著作権を保護しつつ送信する装置であり、送信されるＡＶストリームにおけるタイムベースの不連続点に不連続情報を含めることを特徴とする。

これによって、ＩＰネットワーク越しに著作権を保護されたＡＶストリームを供給される前記パケット受信装置においてタイムベースの不連続点が明らかとなり、そのＡＶストリームの滑らかな再生が可能となる。

以下では、本発明のパケット送信装置の特徴を明確にするために、［１］本発明のパケット送信装置を含む通信システムの構成と著作権保護の実現の概要、［２］著作権保護しつつＩＰネットワーク越しにＡＶストリームを伝送する構成の詳細、［３］蓄積されているＡＶストリームの指定部分を送信する構成の詳細、及び［４］指定された部分の送信を効率化する構成の詳細について説明した後、これらの構成との組み合わせにおいて本発明を特徴付けるところの［５］タイムベースの不連続情報を伝送する構成の詳細について説明し、最後に［６］コピー制御情報を専用の伝達経路を用いて伝達する変形例について、この順に説明する。

［１］本発明のパケット送信装置を含む通信システムの構成と著作権保護の実現の概要
最初に、本発明のパケット送信装置を含んで構成される通信システムと著作権保護の実現の概要について説明する。

図５は本発明のパケット送信装置を含んで構成される通信システムの一例である。この通信システムは、パケットを送信するパケット送信機器１０１と、パケットのルーティングを行うルータ１０２と、パケットを受信するパケット受信機器１０３とから構成される。

パケット送信機器１０１およびパケット受信機器１０３は、一例として、互いの機能を兼ね備えた対等かつ一対のパケット送受信機器として実現されてもよい。その場合、パケット送信機器１０１が送信側として機能し、パケット受信機器１０３が受信側として機能する。そのようなパケット送受信器の、ＡＶストリームを送信する機能に係る部分が、本発明のパケット送信装置の一例である。

パケット送信機器１０１には、送受信条件の設定情報、認証と鍵交換の設定情報、入力ストリーム（ＭＰＥＧ−ＴＳなどのコンテンツ）が入力され、図６に示されるように、以下の手順１から３に基づき、ルータ１０２との間で通信を行う。ここで、伝送されるコンテンツの著作権保護は、認証と暗号化を用いたコピー保護に基づいて実現される。

＜手順１＞送受信パラメータの設定を行なう。

（手順１−１）パケット送受信機器のＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス、ＩＰアドレス、ＴＣＰ／ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）ポート番号等を設定。ＵＰｎＰなどの自動設定機能を使用することができる。

（手順１−２）送信信号の種別、帯域を設定。ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）エージェントとして動作するパケット送信機器１０１とパケット受信機器１０３、ＱｏＳマネージャとして動作するルータ１０２との間でＩＥＥＥ８０２．１Ｑ（ＶＬＡＮ；Ｖｉｒｔｕａｌ ＬＡＮ）規格を用いたネットワークの運用に関する設定を実施。

（手順１−３）優先度の設定（ＩＥＥＥ８０２．１Ｑ／ｐによる運用）

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

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

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

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

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

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

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

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

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

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

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

このようにして、パケット送信機器１０１及びパケット受信機器１０３の間で、コピー制御に基づいてコンテンツの著作権を保護しつつ、そのコンテンツの伝送が行われる。

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

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

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

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

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

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

図７において、家庭内の全てのイーサネット（登録商標）の帯域が１００Ｍｂｐｓであるため、１階と２階間のネットワーク３０５の帯域も１００Ｍｂｐｓである。１階と２階の複数の機器間で複数のデータが流れる場合、各データに対する帯域制限がない場合、このネットワーク３０５上を流れるデータのデータレート合計が１００Ｍｂｐｓを超える可能性があり、パーシャルＭＰＥＧ−ＴＳの映像アプリなどリアルタイム伝送が必要なストリームが途切れる可能性がある。この場合、リアルタイム伝送が必要なストリームが途切れない様にするには、伝送データに対して優先制御が必要である。このような問題は、端末だけでなく、ルータやスイッチングハブにおいて、後述するストリーム伝送やファイル転送の速度制限機構などを導入することにより解決できる。

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

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

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

地上波放送、衛星放送、ＣＡＴＶやインターネット経由で受信するデジタル放送信号より検出、抽出できるＡＶコンテンツの属性情報を送信端末と受信端末間でＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）−ＡＶやＨＴＴＰなどのデータ交換プロトコルを用いて伝送することにより、送信端末と受信端末間でのＡＶコンテンツを送信する場合の暗号化モード、コンテンツ属性情報の伝送方法を決めることができる。さらに、暗号化情報ヘッダの付加ルールを決められるため、パケット送受信機器間でのＡＶストリームの秘匿性を保ちながら信号の互換性を確保することが可能となる。

ＵＰｎＰやＵＰｎＰ−ＡＶの標準仕様は、ｈｔｔｐ：／／ｕｐｎｐ．ｏｒｇで公開されている。ｈｔｔｐ：／／ｕｐｎｐ．ｏｒｇにおいて、例えば、「ＭｅｄｉａＳｅｒｖｅｒ Ｖ １．０ ａｎｄ ＭｅｄｉａＲｅｎｄｅｒｅｒ Ｖ １．０」に関して、「ＭｅｄｉａＳｅｒｖｅｒ Ｖ １．０」、「ＭｅｄｉａＲｅｎｄｅｒｅｒ Ｖ １．０」、「ＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ Ｖ １．０」、「ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙ Ｖ １．０」、「ＲｅｎｄｅｒｉｎｇＣｏｎｔｒｏｌ Ｖ １．０」、「ＡＶＴｒａｎｓｐｏｒｔ Ｖ １．０」、「ＵＰｎＰＴＭ ＡＶ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｖ ．８３」などの仕様書が公開されている。

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

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

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

この場合、制御情報に基づいて、ＡＶデータの再生制御、出力制御又はコピー制御を行うための課金情報、コピー制御情報、有効期限情報、有効再生回数情報など取り扱い、生成した情報を認証情報として認証手段に通知する著作権管理手段を用い、著作権管理手段から通知された認証情報に基づいて、前記パケット受信装置との間で認証処理を行うことで、ＡＶデータの前記パケット受信装置における再生制御、出力制御又はコピー制御を行う。

さらに、パケット送信装置は、著作権管理手段による制御の下で、課金情報、再生制御情報又はコピー制御情報に基づいて、パケット受信装置との間で、著作権保護の対象となるコンテンツの購入決済を行うコンテンツ購入決済手段を備える。

［２］著作権保護しつつＩＰネットワーク越しにＡＶストリームを伝送する構成の詳細
次に、著作権保護しつつＩＰネットワーク越しにＡＶストリームを伝送するための構成の詳細について説明する。

図８は、本実施の形態におけるパケット送受信部４０１の機能的な構成を示すブロック図である。

このパケット送受信部４０１は、図５に示されるパケット送信機器１０１の機能とパケット受信機器１０３の機能とを兼ね備えたパケット送受信器に用いられ、互いにパケットを送受信可能な一対のパケット送受信部の一方として表現される。このことは、以下に記述する全てのパケット送受信部について同じである。

このパケット送受信部４０１は、ＡＫＥに基づいて設定される暗号化によるパケット送受信を行う装置であり、ＩＰネットワーク越しに著作権を保護しつつＡＶストリームを伝送するための必須な構成要素として、ＡＫＥ部４０５、パケット化部４０６、送信条件設定管理部４０３、パケット受信部４１０、暗号化データ生成部４２２、ＨＴＴＰ／ＲＴＰヘッダ付加部４１６、暗号化データ復号部４１８、受信条件設定管理部４１７、フレーム化部４０８およびフレーム受信部４０９を備える。以下、伝送手順に従って、各構成要素の機能を説明すると共に、これらの必須な構成要素以外の構成要素についても適時説明する。

送信条件設定管理部４０３には非ＡＶデータが入力される。送信条件設定管理部４０３には、非ＡＶデータとして、たとえば、入力ＡＶデータ（送信データ）が入力される端子を示す入力端子情報、ＡＶデータのデータフォーマットを示すデータフォーマット情報、ＡＶデータの属性を示す属性情報を含むＡＶデータ情報、及び伝送を制御するための情報が入力される。

伝送を制御するための情報は、具体的には、送信データの種別、送信先アドレスやポート番号の情報、送信に用いるパス情報（ルーティング情報）、送信データの帯域、送信データの送信優先度などの送信条件の設定情報と、送信部（ローカル）と受信部（リモート）における機器の管理制御データと、受信状況を送信側にフィードバックするためのデータなどである。

送信条件設定管理部４０３は、これらの入力された情報に基づいて、ＡＶデータの伝送にＴＣＰ及びＵＤＰの何れを用いるかを決定し、決定されたプロトコルに従って、パケット化部４０６やフレーム化部４０８におけるヘッダやペイロードデータなどの生成を制御（パラメータの設定等を）すると共に、前記ＡＶデータを送信する際の暗号化モードを示す暗号化モード情報を生成する。

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

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

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

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

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

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

認証部４１９は、パケット送信装置とパケット受信装置が規定の条件を備えていることを検証することによって認証処理を実行する。暗号化鍵交換部４２０は、認証処理後にパケット送信装置とパケット受信装置とで暗号化鍵を共有し、入力端子情報と、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報より生成する伝送条件とにより、暗号化鍵を更新し、暗号化データ生成部４２２は、暗号化鍵を用いてＡＶデータを暗号化する。

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

パケット化部４０６は、ＡＶデータ及び一般データを別個にキューイングし、ＡＶデータのレイテンシを考慮しつつ、それぞれのデータをフレーム化部４０８に送る。

なお、認証部４１９は、パケット送信装置とパケット受信装置との間で認証を実行する認証実行モードと認証を実行しない認証不実行モードとを持ち、暗号化データ生成部４２２は、認証手段が認証実行モード及び認証不実行モードのいずれであっても、送信条件設定管理部４０３によって生成された暗号化モード情報に基づく暗号化情報ヘッダの付加を行うように制御することができる。

この場合、暗号化データ生成部４２２は、コピー制御情報がコピー制御をする旨を示す場合に、コピー制御情報を暗号化情報ヘッダとして付加し、コピー制御情報がコピー制御をしない旨を示す場合に、コピー制御情報を前記暗号化情報ヘッダとして付加しないように制御することができる。

さらに、この場合、認証部４１９は、入力端子情報と、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報より生成する認証条件とにより、パケット受信装置に含まれるパケット送受信部との間で認証を行うこともできる。ここで、パケット送受信部４０１は、さらに、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報の少なくとも１つとからなる制御認証情報を、ＡＶデータのプログラム単位毎にアクセス位置を指定するＵＲＩ情報、または、Ｑｕｅｒｙにより拡張されたＵＲＩ情報により、前記プログラムのリストとして、前記パケット受信装置に通知するアクセス位置通知手段を備える。

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

また、パケット送信装置はさらに、ＡＶデータの単位プログラムのコピー制御情報がコピー制御を行わない旨を示す場合に、ＡＶデータのデータフォーマット情報を表す第１のＭＩＭＥ−Ｔｙｐｅと、ＡＶデータに間欠的に前記暗号化情報ヘッダを付加したデータのデータフォーマット情報を表す第２のＭＩＭＥ−Ｔｙｐｅの２つのＭＩＭＥ−Ｔｙｐｅを生成し、ＡＶデータのプログラム単位毎にアクセス位置を指定する２つの拡張ＵＲＩ情報を前記パケット受信装置に提示するアクセス位置通知手段を備える。

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

また、パケット化部４０６は、送信条件設定管理部４０３によってＡＶデータの伝送プロトコルとして、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）と決定された場合は、ＴＣＰコネクションを永続的接続にして前記伝送を行うことを特徴とする場合もある。さらに、前記認証手段は、Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ（ＤＴＣＰ）方式に従って、パケット受信装置と暗号化鍵を共有するための認証と鍵交換を行うことを特徴とする。

パケット化部４０６は、ＨＴＴＰに従ったパケット化を行う場合は、レンジリクエストまたはデータ取得コマンドなどによりパケット化を行い、送信側におけるＡＶデータがＭＰＥＧの場合には、ＭＰＥＧストリームにおけるタイムベース不連続発生情報または連続性情報、ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報、ＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの時刻情報、或るＩピクチャから次のＩピクチャの間に存在するＰピクチャとＢピクチャの各個数または合計個数のうち少なくとも１つの情報を参照して前記パケット化を行う。

また、パケット化部４０６は、ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報として、ＡＶデータが複数の異なるフォーマットであった場合にもオリジナルに持っている複数のＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報より、複数の異なるフォーマット間で共通なＩピクチャまたはＰピクチャまたはＢピクチャ位置情報または時刻情報を生成し、この共通のＩピクチャまたはＰピクチャまたはＢピクチャ位置情報または時刻情報を用いて前記ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報の参照情報と前記パケット化を行う。

また、パケット化部４０６は、ＨＴＴＰに従ったパケット化を行う場合は、チャンク伝送方式で前記パケット化を行い、ＨＴＴＰパケットのペイロード長が前記パケット送信装置で決定された値となるように前記パケット化を行う。

また、パケット化部４０６は、ＨＴＴＰに従ったパケット化を行う場合は、ＨＴＴＰパケットのペイロード長が、暗号化情報ヘッダと整数個の前記ＡＶデータを構成するＴｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ（ＴＳ）により構成されるデータの長さ、または、暗号化情報ヘッダと整数個のタイムスタンプつきＴＳにより構成されるデータの長さとなるように前記パケット化を行う。

また、パケット化部４０６は、ＨＴＴＰによる伝送として、前記チャンク伝送方式のみならず、レンジリクエスト方式を切り替えて用いてもよい。

その場合、パケット化部４０６は、ＨＴＴＰによる伝送として、パケット送信装置の出力がライブ放送の受信信号またはライブ放送の受信チャネルの切り替えまたは蓄積されたプログラム選択時の再生信号の場合には、チャンク伝送を行い、プログラム選択後の蓄積メディアから再生されたプログラムからの再生信号の場合には、レンジリクエストを用いて再生を切替えて行う。

さらに、パケット化部４０６は、ＨＴＴＰによる伝送と、伝送データ量のオーバヘッドがより小さいＲＴＰによる伝送を切り替えて前記ＡＶデータを伝送してもよく、これによりきめこまかな再生制御を実現できる。

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

受信側では、フレーム受信部４０９は、ネットワークより入力される信号（フレーム）に対して、ＭＡＣヘッダを元にフィルタリングして受信し、ＩＰパケットとしてパケット受信部４１０に渡す。なお、一般のＥｔｈｅｒｎｅｔ（登録商標）系においては、機器のＭＡＣアドレスはルータのＳｕｂｎｅｔ境界を越えて伝送されないため、送受信機器のＭＡＣアドレスを事前に登録しておき、そのＭＡＣアドレスによる通信相手の識別を行うことによって、ＩＰパケットの伝送範囲をＩＰアドレスのＳｕｂｎｅｔ内に収めることができる。

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

送信側と、受信側で認証と鍵交換が成立すれば、暗号化したＡＶデータを送信する。

さて、図８に示されるパケット送受信部４０１における送信処理においては、パーシャルＭＰＥＧ−ＴＳ信号は、ＴＳストリーム識別部４０２に入力され、前述したストリームの種別が識別された後、コンテンツバッファ４１３に保持されることによって暗号化タイミングの調整を受けた後に、暗号化データ生成部４２２に入力される。

暗号化情報ヘッダ付加部４１５は、コピー制御情報がコピー制御をする旨を示すかコピー制御をしない旨を示すかに関係なく、送信条件設定管理部４０３によって生成された暗号化モード情報に基づく暗号化情報ヘッダの付加を行う場合もある。

パーシャルＭＰＥＧ−ＴＳは、たとえば、日本における地上や衛星やＣＡＴＶや光ファイバー配信によるデジタル放送をデジタル放送チューナで受信して、選局すると放送局より送られるフルＴＳから、番組（プログラム）を構成するパーシャルＭＰＥＧ−ＴＳが抽出される。パーシャルＭＰＥＧ−ＴＳに多重化されているＰＳＩ／ＳＩとしては、ＰＡＴ、ＰＭＴ、ＤＩＴ、ＳＩＴ（例えば、ＡＲＩＢ規格、ＳＴＤ−Ｂ２１参照）があり、ＰＡＴはＤＴＣＰデスクリプタを含んでいる。また、ＤＴＣＰデスクリプタは、アナログコピー制御情報とデジタルコピー制御情報を含んでいる。

たとえば、あるチャンネルのある番組のデジタルコピー制御情報において、ＰＭＴ第１ループのデジタルコピー制御情報とＰＭＴ第２ループのデジタルコピー制御情報が双方とも存在する場合には、ＰＭＴ第２ループのデジタルコピー制御情報を優先してその番組のデジタルコピー制御情報とする。またＰＭＴ第１ループのデジタルコピー制御情報とＰＭＴ第２ループのデジタルコピー制御情報の片方しか存在しない場合には、その存在する片方のデジタルコピー制御情報をその番組のデジタルコピー制御情報とする。

また、外部より入力される情報または、ＰＳＩ／ＳＩに多重されて送信条件設定管理部４０３に入力されるパケットデータ送信許可情報の意味が「許可」の場合、パケットが出力される。逆にパケットデータ送信許可情報の意味が、許可の反対の「禁止」の場合には、他のいかなる条件が許可であってもパケットが禁止される。このパケットデータ送信許可情報は、図面には、同じ意味を反対の論理で表したパケット化出力禁止情報として示されている。パケットデータ送信許可情報は、たとえば、パーシャルＭＰＥＧ−ＴＳのＰＭＴ第１ループまたはＰＭＴ第２ループにパケットデータ送信許可記述子として挿入する。パケットデータ送信許可記述子は基本的には１ビットでよい。

今、あるチャンネルのある番組のデジタルコピー制御情報において、ＰＭＴ第２ループのデジタルコピー制御情報がＣＯＧ（Ｃｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎ、１世代コピーのみ可能）の場合に、暗号化データ生成部４２２内の暗号化部４１４は、パーシャルＭＰＥＧ−ＴＳ信号を暗号化する。さらに、暗号化情報ヘッダ付加部４１５は、ＡＫＥ部４０５から送られてくる前述のＣＯＧを表わすＥＭＩおよび、シード情報（１ビット以上の情報）などのＡＫＥ情報を暗号化情報ヘッダとして付加し、パケット化部４０６に出力する。

また、今、あるチャンネルのある番組のデジタルコピー制御情報において、ＰＭＴ第２ループのデジタルコピー制御情報がＣＦ（Ｃｏｐｙ Ｆｒｅｅ、コピー可能）の場合に、暗号化データ生成部４２２内の暗号化部４１４は、パーシャルＭＰＥＧ−ＴＳ信号を暗号化しない。さらに、暗号化情報ヘッダ付加部４１５は、ＡＫＥ部４０５から送られてくる前述のＣＦを表わすＥＭＩ（暗号化モード情報）および、シード情報（１ビット以上の情報）などのＡＫＥ情報を暗号化情報ヘッダとして付加し、パケット化部４０６に出力する。なお、ここで、外部より暗号化情報ヘッダを付加しないように制御される場合には、暗号化情報ヘッダは付加されない。

また、外部より入力さるか、または、ＰＳＩ／ＳＩに多重されて入力されるパケットデータ送信許可情報が含まれている。たとえば、ＭＰＥＧ−ＴＳのＰＭＴの第１ループまたは第２ループが持っているデジタルコピー制御記述子（たとえば、ＡＲＩＢ ＴＲ−Ｂ１４、第２編、第４編を参照）の中にパケットデータ送信許可情報を含める。この場合、放送局など送信側の設備変更を伴う。

以上のように、暗号化実行の有無および、暗号化情報ヘッダ付加の有無は、パーシャルＴＳのコピー制御情報と外部入力や内部設定で決まられる条件により一意的に決まるように設定されている。

パケット化部４０６は、暗号化データ生成部４２２から出力されるデータに対して、送信条件設定管理部４０３からの送信条件などのパラメータを用いて、ＴＣＰ／ＩＰのヘッダを付加し、フレーム化部４０８に送る。フレーム化部４０８は、パケット化部４０６からのＩＰパケットに対して、８０２．１Ｑ（ＶＬＡＮ）方式を用いてＭＡＣヘッダを付加することでイーサネット（登録商標）フレームに変換し、送信フレームとしてネットワークに出力する。ここで、ＭＡＣヘッダ内のＴＣＩ（Ｔａｇ Ｃｏｎｔｒｏａｌ Ｉｎｆｏｒｍａｉｔｉｏｎ）内のＰｒｉｏｒｉｔｙ（ユーザ優先度）を高く設定することにより、ネットワーク伝送の優先度を一般のデータよりも高くすることができる。

図１０にパーシャルＭＰＥＧ−ＴＳを暗号化してＨＴＴＰ／ＴＣＰ／ＩＰ／Ｅｔｈｅｒｎｅｔ（登録商標）で伝送する場合のＥｔｈｅｒｎｅｔ（登録商標）フレームの一例を示す。ここで、パーシャルＭＰＥＧ−ＴＳパケット（１８８バイト）には４バイトのタイムスタンプがヘッダとして付加されている。この４バイトのタイムスタンプ２７ＭＨｚのクロックでサンプリングされたものである。

受信側では、ネットワークより入力される信号がフレーム受信部４０９でＭＡＣヘッダを元にフィルタリングされ、ＩＰパケットとしてパケット受信部４１０に入力される。パケット受信部４１０では、パケットヘッダなどの識別によりパケットのフィルタリングが行なわれ、暗号化データ復号部４１８に入力され、暗号化データ復号部４１８にて暗号化情報ヘッダを検知、ＥＭＩ（暗号化モード情報）を抽出して暗号の復号化が行い、暗号を復号化されたパーシャルＭＰＥＧ−ＴＳ信号が出力される。ここで、パーシャルＭＰＥＧ−ＴＳ信号のオリジナルのコピー制御情報はＰＭＴ内に存在しているので、コピー制御情報は送信側から受信側へ正しく継承されている。

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

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

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

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

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

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

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

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

また、パケット送受信部４０１を、パーシャルＭＰＥＧ−ＴＳデータなどを蓄積保持するように変形した例を考えることもできる。

図１１は、この変形例におけるパケット送受信部７４０１の構成を示すブロック図である。図１１において、パケット送受信部７４０１は、ＴＳストリーム識別部４０２に接続された蓄積部７０１を具備する。この構成によれば、送信条件設定管理部４０３は、放送と蓄積の両方のソースからＡＶデータを受け取ることができる。

蓄積部７０１については後で改めて詳細に説明し、ここでは、送信条件設定管理部４０３に入力されるＡＶデータの入力ソース情報として、放送及び蓄積の２種類が考えられることに注意して、説明を進める。

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

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

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

また、暗号化情報ヘッダの付加制御は、たとえば以下の様に行う。すなわち、コピーフリーコンテンツを放送する放送チャネルを受信した場合には付加しない。また、一定期間でもコピーフリーでないコンテンツを放送する放送チャネルを受信した場合には付加する。さらに、ＡＶデータが蓄積メディアよりコピーフリータイトルのコンテンツを再生した場合には付加しない。そして、ＡＶデータが蓄積メディアよりコピーフリーでないタイトルのコンテンツを再生した場合には付加する。なお、送信側における暗号化情報ヘッダの付加分される場合、ＨＴＴＰのレスポンスヘッダには、伝送されるデータ長にこの暗号化情報ヘッダの長さだけ増加したＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈが記述される。

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

ここで、サーバ型放送のＲＭＰで用いる課金情報などを含むＲＭＰＩで視聴あるいはコピー制限されたコンテンツをＲＭＰに対応していないクライアントにＣＮＭ（Ｃｏｐｙ Ｎｏ Ｍｏｒｅ）やＣＮ（Ｃｏｐｙ Ｎｅｖｅｒ）で見せるための構成について説明する。

ＤＲＭ設定管理部４０４は、コンテンツメタ情報４１２によって表されるコンテンツに関する著作権管理情報に基づいて、ＡＶデータの再生制御、出力制御又はコピー制御を行うための課金情報、コピー制御情報、有効期限情報、有効再生回数情報などを基に、認証情報を生成してＡＫＥ部４０５へ通知する。

ＡＫＥ部４０５は、ＤＲＭ設定管理部４０４から通知された認証情報に基づいて、前記パケット受信装置との間で認証処理を行うことで、ＡＶデータの前記パケット受信装置における再生制御、出力制御又はコピー制御を行う。

さらに、ＤＲＭコンテンツ購入決済部４１１は、ＤＲＭ設定管理部４０４による制御の下で、課金情報、再生制御情報又はコピー制御情報に基づいて、パケット受信装置との間で、著作権保護の対象となるコンテンツの購入決済を行ってもよい。

次に、図８において、送信キュー制御部４０７、ＡＶデータキュー、および一般データキューの動作について説明する。

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

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

送信キュー制御部４０７は、ＡＶデータキューと一般データキューにデータが存在する場合、どちらのデータを優先して出力するかの制御を行なう。通常状態では、一般データよりもＭＰＥＧ−ＴＳなどのコンテンツデータを優先制御して出力する。たとえば、パケット送受信機器間でＭＰＥＧ−ＴＳを低レイテンシ（低遅延）で伝送する場合には、ＭＰＥＧ−ＴＳ用バッファも小さくなるため、オーバーフローが発生しやすい。

送信側でＭＰＥＧ−ＴＳバッファがオーバーフローしそうになった場合、あるいは、受信側からフィードバックされた情報を参照して受信側のＭＰＥＧ−ＴＳのバッファがアンダーフローしそうになったことが判明した場合には、ＭＰＥＧ−ＴＳデータを優先出力すべくＡＶデータキューの優先度を更に適応的に上げることにより、これらバッファ破綻を回避できる。

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

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

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

送信側ではＭＰＥＧ−ＴＳ信号を暗号化データ生成部４２２に入力し、暗号化データ生成部４２２においてＭＰＥＧ−ＴＳ信号に暗号化する。その後、この暗号化されたＭＰＥＧ−ＴＳ信号をパケット化部４０６に入力され、ハードウェアアクセラレータを用いた処理によりＨＴＴＰ／ＴＣＰ／ＩＰの処理を行い、ＡＶデータキューに入力する。送信キュー制御部４０７は、一般データキューとＡＶデータキューの双方にデータが存在する場合、前述の場合と同様に、２つのキューからのデータ出力に関して優先制御を行なう。

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

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

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

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

なお、ここまでの説明において、送信条件設定管理部４０３がＡＶデータ情報取得手段、送信条件設定管理手段、及び伝送プロトコル決定手段の一例であり、ＴＳストリーム識別部４０２がデータ入力手段の一例であり、暗号化データ生成部４２２が暗号化送信データ生成手段の一例であり、ＨＴＴＰ／ＲＴＰヘッダ付加部４１６及びパケット化部４０６がパケット化手段の一例であり、ＡＫＥ部４０５が認証手段の一例であり、フレーム化部４０８が伝送手段の一例である。

［３］蓄積されているＡＶストリームの指定部分を送信する構成の詳細
次に、蓄積されているＡＶストリームの指定部分を送信するための構成の詳細について説明する。

図１１は、この説明に用いられるパケット送受信部７４０１の構成を示すブロック図である。このパケット送受信部７４０１は、図８に示されたパケット送受信部４０１の構成に加えて、蓄積部７０１を備える。以下、前述した事項と同じ事項について説明を省略し、異なる部分のみを説明する。

このパケット送受信部７４０１は、ＴＳストリーム識別部４０２に接続された蓄積部７０１を具備する。ここで、蓄積部７０１は、ハードディスクドライブ（ＨＤＤ）や光ディスク（ＣＤやＤＶＤなど）や半導体ディスク（ＳＤカードメモリなど）である。一例として、このパケット送受信部７４０１は、ハードディスクや光ディスクなどに蓄積されたパーシャルＭＰＥＧ−ＴＳデータなどをＨＴＴＰのレンジリクエストを用いて伝送する。

このレンジリクエストは、蓄積部７０１に蓄積されたパーシャルＭＰＥＧ−ＴＳのファイルの先頭からの距離、たとえばＡ、Ｂ（Ａ，ＢはＡ＜Ｂを満足する０以上の整数）でレンジ先頭とレンジ末尾を選んでリクエストされる。通常、一般データに対してＡ，Ｂは自由な値を選べるが、ＭＰＥＧ−ＴＳのような映像データをレンジＧＥＴする場合、そのＧＯＰやＰｉｃｔｕｒｅ構造に着目すれば、効率のよい伝送ができる。しかしながら、受信側は、送信側の蓄積ファイルのどの部分でＧＯＰを構成しているとか、どの部分がＩピクチャであるとかは分からない。

そこで、送信側は受信側よりＨＴＴＰのレンジリクエストを受け取ると、そのレンジ先頭とレンジ末尾にそれぞれ最も近いＧＯＰをＨＴＴＰレスポンスとして返す。この伝送方法を、ここでは、ＨＴＴＰアライメントレスポンス法（ＨＴＴＰ ＡＶ Ａｌｉｇｎｍｅｎｔ Ｄａｔａ Ｕｎｉｔ Ｒｅｓｐｏｎｓｅ Ｍｅｔｈｏｄ；ＨＡＲ法と略す）と呼ぶことにする。このような伝送モードの選択のトリガとしては、たとえば次の方法がある。

１）送信側（サーバ）と受信側（クライアント）の間でＵＰｎＰ−ＡＶなどのメカニズムを用いて事前にネゴを行う。

２）ＨＴＴＰのリクエストヘッダに、ＨＡＲ法でのレスポンスを期待してＨＡＲ法を使用することを表す文字列などの指示情報を挿入する。たとえば、
ｈａｒ−ｖａｌｕｅ ＝ ｇｏｐ
をＨＴＴＰリクエストに挿入する。

ＨＡＲ法に対応していないサーバは、この指示情報には反応しないが、ＨＡＲ法に対応しているサーバはこの指示情報に反応して、レンジリクエストされたレンジ先頭にもっとも近いＧＯＰ先頭をリクエストされたデータから探し出しレスポンスのレンジ先頭に設定する、また、レンジリクエストされたレンジ末尾にもっとも近いＧＯＰ先頭をリクエストされたデータから探し出しレスポンスのレンジ末尾に設定する。そして、サーバはＨＴＴＰのレスポンスヘッダにＨＡＲ法によるレスポンスであることを表す文字列などの指示情報を挿入する。たとえば、
ｈａｒ−ｖａｌｕｅ ＝ ｇｏｐ
をＨＴＴＰレスポンスに挿入する。

これらの動作によって、クライアントはサーバ内データに対して適当なレンジリクエストしたにもかかわらず、クライアントはＨＴＴＰレスポンスに挿入されたＭＰＥＧ−ＴＳをＧＯＰ単位で部分ＧＥＴできる。

ＭＰＥＧ−ＴＳが連続的に記録されたファイルの場合は、ひとたび、ＧＯＰ単位のレスポンスを受け取れば、映像を連続フレームで受け取りたい場合に、直前に受け取ったレンジ末尾の値より、次のＧＯＰ先頭の位置を容易に計算できる。たとえば、直前に受け取ったレンジ末尾の値１バイト足すことで次のＧＯＰ先頭の位置が分かる。

以上のように、この例では、受信側より送信側にＨＴＴＰのレンジリクエストによるデータ要求を行う場合に、伝送されるデータブロックの先頭データまたは末尾データを、送信側で管理しているＧＯＰなどのデータブロック単位の先頭データと一致させる。たとえば、データがＭＰＥＧの場合には、送信側で管理するデータブロックの単位は、上記の例で説明したＧＯＰだけでなく、Ｐｉｃｔｕｒｅまたは、マクロブロックまたは、ブロックの単位に指定することができる。また、データブロックが送信装置に内蔵されたハードディスク（ＨＤＤと略す）やＣＤやＤＶＤ（ＤＶＤ−Ｒ、ＤＶＤ−ＲＡＭなど複数の種類がある）などの光ディスク、ＳＤメモリカードのような半導体ディスクの場合には、これはＨＤＤ（たとえば５１２バイトのＬＢＡ単位）やＣＤ（たとえば、２ｋＢ単位）やＤＶＤの各記録フォーマットが、論理ブロックの単位とすることもできる。

よって、たとえば、データ（ファイルやストリーム）がＭＰＥＧの場合に、受信側より送信側にＨＴＴＰのレンジリクエストで要求するデータ範囲がＧＯＰ単位やＰｉｃｔｕｒｅ単位とデータ境界が合っていなくても、すなわち、データのアライメントが取れていなくても、サーバ（送信側）の処理としてＨＴＴＰレスポンスとして要求されたデータ範囲に近いところにあるＧＯＰ単位やＰｉｃｔｕｒｅ単位をレスポンスとして返信できる。そこで、受信側では受信データから効率よくＭＰＥＧデコードを行うことができる。

また、ＭＰＥＧ−ＴＳの例として、サーバがＢｌｕ−ｒａｙディスクレコーダーの場合、ＰＬＡＹＬＩＳＴファイルやＣＬＩＰＩＮＦＯファイルを用いて効率よくＧＯＰ境界位置やＩピクチャ位置を認識して、ＧＯＰやＩピクチャデータを取り出すことができるので、サーバの動作負荷を下げることができる。また、ＭＰＥＧ−ＰＳの場合にも、サーバがＤＶＤ−ＲＡＭディスクレコーダーで記録フォーマットがＤＶＤ−ＶＲ規格に準拠している場合、ＤＶＤ−ＶＲ方式ではＩＦＯファイルと呼ばれている管理ファイルを持っている。よって、サーバ側はこのＩＦＯファイルの管理情報を活用することにより、効率よくＧＯＰ境界位置やＩピクチャ位置を認識して、ＧＯＰやＩピクチャデータを取り出すことができるので、サーバの利用効率も上がる。以上のようにＰＬＡＹＬＩＳＴファイルやＣＬＩＰＩＮＦＯファイルやＩＦＯファイルと同様な構造を持ったデータ管理ファイルを活用することにより、サーバは容易に上述のＨＡＲ法を使用できる。

この場合、サーバはクライアントから上記ＨＡＲ法によるレンジリクエスト値を受け取り、自身の持っているＩＦＯファイルと比較して返信するＧＯＰブロックを決定する。以上により、ＡＶコンテンツにＤＴＣＰ−ＩＰを適用して伝送することが可能となる。

また、蓄積部７０１に暗号化されたコンテンツを記録しておき（いわゆるＤＲＭデジタル著作権管理による暗号化を適用したコンテンツが対象）、その記録されたコンテンツのリストを呼び出し、ユーザが視聴したいコンテンツ（映画、コンサート、ドラマなど）を選択する場合に暗号を解除するために、たとえば、次の方法を実装することができる。

方法１）ユーザは、ユーザはインターネットや電話回線を通じて、あるいはコンビニエンスストアなどで、暗号化されたコンテンツを復号するための情報を購入する。コンテンツは、ユーザが対象機器を購入した時点で、既に蓄積部７０１に、たとえば１００タイトル分の映画、コンサート、ドラマなどが記録されている場合に有効なである。

方法２）ユーザは、インターネットやＣＡＴＶ、放送を通じて、暗号化されたコンテンツをダウンロードする。さらに、ユーザはインターネットや電話回線を通じて、あるいはコンビニエンスストアなどで、暗号化されたコンテンツを復号するための情報を購入する。

方法３）ユーザがパッケージメディアとしてコンテンツを購入した際に付属しているコンテンツの暗号を復号するための情報を使用する。

［４］指定された部分の送信を効率化する構成の詳細
次に、指定された部分の送信を効率化する構成の詳細について説明する。

図１２は、この説明に用いられるパケット送受信部８４０１の構成を示すブロック図である。このパケット送受信部８４０１は、図１１に示されたパケット送受信部７４０１の構成に加えて、データ配列情報生成管理部８０１を備える。以下、前述した事項と同様の事項について説明を省略し、異なる部分のみを説明する。

このパケット送受信部８４０１は、ＴＳストリーム識別部４０２に接続されたデータ配列情報生成管理部８０１を具備する。なお、蓄積部７０１は、ハードディスクドライブ（ＨＤＤ）や光ディスク（ＣＤやＤＶＤなど）や半導体ディスク（ＳＤカードメモリなど）などである。一例として、このパケット送受信部７４０１は、ハードディスクや光ディスクなどに蓄積されたパーシャルＭＰＥＧ−ＴＳデータなどをＨＴＴＰのレンジリクエストを用いて伝送する。

このＨＴＴＰのレンジリクエストおよびレスポンスには、上述したＨＡＲ法でＩフレームに効率的にアクセスする方法について説明する。ここで、伝送モード選択のトリガとしては、たとえば次の方法がある。

１）送信側（サーバ）と受信側（クライアント）の間でＵＰｎＰ−ＡＶなどのメカニズムを用いて事前にネゴを行う。

２）ＨＴＴＰのリクエストヘッダに、ＨＡＲ法でのレスポンスを期待してＨＡＲ法を使用することを表す文字列などの指示情報を挿入する。たとえば、
ｈａｒ−ｖａｌｕｅ ＝ ｉ−ｐｉｃｔｕｒｅ ： １
をＨＴＴＰリクエストに挿入する。ここで、
ｈａｒ−ｖａｌｕｅ ＝ ｉ−ｐｉｃｔｕｒｅ ： ｎ （ｎは整数）
の動作として、サーバ内のデータ配列情報生成管理部８０１は、“ｉ−ｐｉｃｔｕｒｅ”はレンジリクエストされた範囲におけるｉ−ｐｉｃｔｕｒｅの位置情報を計算、生成する。このレンジリクエストされた範囲におけるｉ−ｐｉｃｔｕｒｅの位置情報により、蓄積部７０１はＩピクチャデータをｎ個とばしで抜き出し、クライアントに送る。ｎの値が“＋”の場合は、レンジの最初から末尾方向にｉ−ｐｉｃｔｕｒｅのみを抜き出しｎ個とばしでクライアントに送り、いわゆる、順方向のフレーム飛ばしスキップ再生を行う。ｎの値が“−”の場合は、レンジの末尾から頭方向にｉ−ｐｉｃｔｕｒｅのみを抜き出しｎ個とばしでクライアントに送り、いわゆる、逆方向のフレーム飛ばしスキップ再生を行う。

“ｈａｒ−ｖａｌｕｅ”を“ ＝ ｉ−ｐｉｃｔｕｒｅ ： ｎ （ｎは整数）”に拡張することにより、クライアントはサーバ内データに対して適当なレンジリクエストしたにもかかわらず、クライアントはＨＴＴＰレスポンスに挿入されたＭＰＥＧ−ＴＳをＩピクチャ単位で部分ＧＥＴできる。

また、サーバ内ＨＤＤに記録されたＭＰＥＧ−ＴＳの管理情報として、Ｉフレームの位置と概略サイズに関する情報があれば、その情報を用いてＩピクチャを含むデータをクライアントに送ることもできる。以上のように、サーバ内のＭＰＥＧファイルのＩフレーム位置情報を活用することにより、早送り、巻き戻し、スロー再生などの特殊再生を効率よく実現できる。そこで、一般に、ＤＲＭ対応ＡＶコンテンツをＤＴＣＰ−ＩＰを用いて伝送することが可能となる。

なお、ＨＴＴＰによる伝送をＲＴＰによる伝送を切り替えてＡＶデータを伝送してもよい。ＲＴＰの場合は、ＲＴＣＰで適当な開始位置を指定すれば、そこにＲＴＰに対応したＨＡＲ法を適用することができる。

なお、図１３に示すようなピクチャ情報ファイルを用いて、異なるＭＰＥＧファイルシステムを採用したシステムに対して、そのファイルにおけるＩ／Ｐ／Ｂピクチャの位置情報、時刻情報などを共通のピクチャ情報ファイルとして取り扱うことにより、異なるファイルフォーマットを共通のプラットフォーム上で取り扱うことが可能となる。

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

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

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

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

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

［５］タイムベースの不連続情報を伝送する構成の詳細
次に、タイムベースの不連続情報を伝送する構成の詳細について説明する。この説明に用いられるパケット送受信部の構成は、前述した図１２のパケット送受信部８４０１と同様の構成である。よって、以下では前述と同様の事項についての説明を省略し、異なる部分のみを説明する。

蓄積部７０１を用いて、ハードディスクに蓄積されたＭＰＥＧファイル（一般的なＡＶコンテンツなら何でもよい。）の複数の断片部分をＨＴＴＰプロトコルにより送信側から受信側へ伝送する場合について説明する。ＨＴＴＰプロトコルの伝送シーケンスは、たとえば、図１４（ｂ）の各ステップで表すことができる。

（ステップ−ｐ１）送信側に存在するＭＰＥＧファイルが、ＤＶＤ−ＶＲ仕様におけるＩＦＯファイルや、ＢＤ−ＲＥ仕様におけるＰＬＡＹＬＩＳＴファイルやＣＬＩＰＩＮＦファイルなどの補助データファイルを持っているかどうかを、受信側から送信側に問い合わせる。なお、図１３に示されるピクチャ情報ファイルも、補助データファイルの一例と考えることもできる。

もし、送信側が補助データファイルを持っていれば、以下のステップ−ｃ１、ステップ−ｃ２で述べる処理が実行される。

（ステップ−ｐ２）もし、送信側にステップ−ｐ１で述べた補助データファイルがなければ、その生成を受信側から送信側に要求する。

送信側がこの要求にこたえられない場合については図示を省略するが、一例として、前述したＨＡＲ法を用いて、ＨＴＴＰによる部分ＧＥＴ（レンジリクエスト）を実行することができる。

送信側がこの要求にこたえられる場合には、ＨＴＴＰによる部分ＧＥＴ（レンジリクエスト）は、以下のステップ−ｃ１、ステップ−ｃ２で述べる処理が行われる。

（ステップ−ｃ１）送信側は、受信側から要求された補助データファイルを受信側に送る。

（ステップ−ｃ２）受信側は、送信側より受け取った補助ファイルを参照してＭＰＥＧファイルの１以上の部分よりＶＯＢ単位、Ｉピクチャ単位で、ＭＰＥＧデータを要求する。たとえば、受信側は図１４（ａ）のＲａｎｇｅ、Ｎｏ．１、Ｎｏ．２、・・・、Ｎｏ．（ｎ）のｎ個のデータを要求する。

パケット化部４０６は、この伝送されるデータにおけるタイムベースの不連続点を、例えばデータ配列情報を参照することによって知り、その不連続点に不連続情報を付加する。

この処理の結果、図１４（ｃ）に示されるデータが伝送される。この伝送されるデータは、タイムベースの不連続点に、パケット化部４０６によって付加された不連続情報を含んでいる。一例として、各レンジに含まれるデータが、それぞれのレンジの中では時間的に連続していて、かつ他のレンジとの間で不連続であるとした場合には、Ｎｏ．２からＮｏ．（ｎ）までの各Ｒａｎｇｅの先頭に不連続情報が含まれる。

ここで、ＨＴＴＰプロトコルを用いたレンジリクエストのプロトコルシーケンスにおいて、一つのＲａｎｇｅに対応するデータの伝送途中でＴＣＰコネクションが切断されることによって、データが分割して伝送される場合もある。この場合、元データは時間軸で連続していても、元データの分割である複数のデータブロックはＴＣＰコネクションの確立、切断、確立、切断を繰り返して伝送されることとなる。

この状況において、例えば、従来のパーシャルＭＰＥＧ−ＴＳに適用されるＤＶＢ規格やＡＲＩＢ規格、ＳＴＤ−Ｂ２１やＴＲ−Ｂ１４，１５に準拠した処理を行ったとすると、データのタイムベースは不連続とみなされ、それぞれのデータブロックの先頭と末尾にＤＩＴなどのタイムベースの不連続情報の付加が必要となる。そのため、ＨＴＴＰレスポンスのヘッダ内のＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈが、リクエストされた本来のデータのサイズを示す値から、暗号化情報ヘッダの付加分に加えて、タイムベースの不連続情報の付加分だけ増加することになる。

なお、この暗号化情報ヘッダの付加分はパケット受信部で削除されるので、正味の伝送コンテンツとして扱わなくてよい。本実施の形態では、この暗号化情報ヘッダを正味の伝送コンテンツとして扱わないとして説明する。

本実施の形態では、パーシャルＭＰＥＧ−ＴＳをＨＴＴＰで伝送する場合の新たな仕組みとして、特にタイムベースの不連続点が、例えばデータ配列情報の内容によって、明示されない限りは、パケット化部４０６は、ＨＴＴＰのレスポンスの先頭や末尾にＤＩＴなど不連続情報を挿入しない新たなアルゴリズムをとる。

ここで、補助データファイルには、ＭＰＥＧ−ＴＳのＧＯＰ単位あるいはＩピクチャ単位でのデータ構造を記述してあるので、Ｒａｎｇｅ、Ｎｏ．１、Ｎｏ．２、・・・、Ｎｏ．（ｎ）はそれぞれ、ＭＰＥＧ−ＴＳファイルのＧＯＰ単位あるいはＩピクチャ単位とすることができ、一般的なＭＰＥＧのデコード動作（デコードのアルゴリズムとシーケンスと同等の意味で用いている）に適応した効率的なデータ伝送が実現できる。

以上のように、サーバ内のＭＰＥＧファイルのＧＯＰ構造やＩフレーム位置情報を活用することにより、早送り、巻き戻し、スロー再生などの特殊再生を効率よく実現できる。そこで、一般に、ＤＲＭ対応ＡＶコンテンツをＤＴＣＰ−ＩＰを適用して効率よく伝送することが可能となる。

なお、本実施例ではＨＴＴＰを用いたが、ＨＴＴＰの代わりにＲＴＰ用いてもよい。ＲＴＰの場合は、受信側がＲＴＣＰを用いてＭＰＥＧファイルの伝送を制御すればよい。なお、この場合は、ＨＴＴＰのように伝送サイズの計算が複雑にならないというメリットがある。

ところで、ＨＤＤやＤＶＤなどの光ディスクに蓄積されたコンテンツの蓄積フォーマットが異なる場合、クライアント（シンク）は全ての異なるコンテンツのＩフレーム位置データを格納したファイルフォーマットを識別しなければならない。フォーマット数が多くなると、多くのファイルフォーマットの解析と識別は受信側にとって大きな負担となる。

そこで、送信側におけるデータ配列情報生成管理部８０１により、異なるフォーマットのＩフレーム位置情報から、統一されたフォーマットで表されたＩフレーム位置情報を生成する。これにより、各社のＨＤＤ記録フォーマット、ＤＶＤ−ＶＲ方式、あるいはＢＤ方式など異なる蓄積フォーマットであっても、簡単に、早送り、巻き戻し、スロー再生などの特殊再生することが実現される。

このパケット化において、ＨＴＴＰは受信部からのレンジリクエストまたはデータ取得コマンドを受けて前記ＡＶデータまたは前記暗号化モード情報のうち少なくとも一方を含んだペイロードデータを伝送する。このレンジリクエストまたはデータ取得コマンドは、前記送信側における前記ＡＶデータがＭＰＥＧの場合、ＭＰＥＧストリームにおける不連続発生情報または連続性情報、前記ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報、或るＩピクチャから次のＩピクチャの間に存在するＰピクチャとＢピクチャの各個数または合計個数の内、少なくとも１つの情報を参照して実行する。

なお、ＭＰＥＧストリームにおける不連続発生情報または連続性情報とは、たとえば、ＡＲＩＢ規格、ＡＲＩＢ−ＴＲ−Ｂ１４またはＡＲＩＢ−ＴＲ−Ｂ１４の第２編に記載されているＤＩＴ情報であり、これを元に別の論理記述で不連続発生情報または連続性情報を生成することもできる。このストリームの不連続点とは、たとえば、ＭＰＥＧのパーシャルＴＳの場合、ＭＰＥＧ−ＴＳストリームのシステムタイムベースの不連続が発生する点、たとえば、ＰＣＲが不連続になる点、または、パーシャルＴＳを構成するパケットの内のどれか１つのトランスポートパケットヘッダのｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒの不連続が発生する点をさす。

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

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

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

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

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

［５．１］タイムベースの不連続情報の取り扱いの具体例
次に、ＡＶストリームの複数の部分を送信する場合のタイムベースの不連続情報の取り扱いに関して、具体的に補足説明する。

図１２における蓄積部７０１を用いて、ハードディスクに蓄積されたＭＰＥＧファイル（一般的なＡＶコンテンツなら何でもよい。）の複数の断片部分をＨＴＴＰプロトコルにより送信側から受信側へ伝送する場合について説明する。ＨＴＴＰプロトコルの伝送シーケンスは、基本的には、たとえば、図１４（ｂ）の各ステップに従う。

（ステップ−ｐ１）および（ステップ−ｐ２）は、前述と同様である。

（ステップ−ｃ１）において、送信側は、受信側から要求された補助データファイルを受信側に送る。

（ステップ−ｃ２）において、受信側は、送信側より受け取った補助ファイルを参照してＭＰＥＧファイルの１以上の部分よりＶＯＢ単位、Ｉピクチャ単位で、ＭＰＥＧデータを要求する。たとえば、受信側は図１５（ａ）に示されるＲａｎｇｅ、Ｎｏ．１、Ｎｏ．２、Ｎｏ．３の３つのデータを要求する。ここで、補助データファイルには、ＭＰＥＧ−ＴＳのＧＯＰ単位あるいはＩピクチャ単位でのデータ構造とともに、タイムベースの不連続情報（たとえば、ＤＩＴ）を記述してある。そこで、受信側に伝送されるデータであるＲａｎｇｅ、Ｎｏ．１、Ｎｏ．２、Ｎｏ．３はそれぞれ、タイムベースの不連続点を含んだＭＰＥＧ−ＴＳファイル内のＧＯＰ単位データブロックあるいは、Ｉピクチャ単位データブロックとなる。

図１５（ａ）の送信データは、同図中、Ｒａｎｇｅ、Ｎｏ．１の右側の矢印で示しているようにＲａｎｇｅ、Ｎｏ．１の途中にタイムベースの不連続点を含んでいる。また、同図中、Ｒａｎｇｅ、Ｎｏ．３の先頭部の右側の矢印で示しているようにＲａｎｇｅ、Ｎｏ．３の先頭にタイムベースの不連続点を持つ。

この場合に伝送されるデータは図１５（ｂ）のように表され、Ｒａｎｇｅ Ｎｏ．１の途中にあるタイムベースの不連続点、及びＲａｎｇｅ Ｎｏ．２、Ｎｏ．３の先頭に、それぞれタイムベースの不連続情報が含まれる。

なお、送信側における暗号化情報ヘッダの付加分はパケット受信部で削除されるので、本説明でも正味の伝送コンテンツとして扱わないものとする。

また、伝送プロトコル（例えばＴＣＰ）によって、送信データがコネクションの切断を伴って分割される場合でも、元データが時間的に連続している限りは、分割されたそれぞれの送信データの先頭又は末尾に不連続情報が付加されない点についても前述したとおりである。

以上、一般的なＭＰＥＧのデコード動作（ＭＰＥＧデコードのアルゴリズムまたはシーケンスと同等の意味）に対して効率的なデータ伝送が実現できる。サーバ内のＭＰＥＧファイルのＧＯＰ構造やＩフレーム位置情報を活用することにより、早送り、巻き戻し、スロー再生などの特殊再生を効率よく実現できる。そこで、一般に、ＤＲＭ対応ＡＶコンテンツをＤＴＣＰ−ＩＰを適用して効率よく伝送することが可能となる。

［５．２］無効データの取り扱いの具体例
次に、先頭又は末尾、若しくはその両方に無効データを持つ複数の部分を送信する場合の、その無効データの取り扱いに関して、具体的に補足説明する。

図１２における蓄積部７０１を用いて、ハードディスクに蓄積されたＭＰＥＧファイル（一般的なＡＶコンテンツなら何でもよい。）の複数の断片部分をＨＴＴＰプロトコルにより送信側から受信側へ伝送する場合について説明する。ＨＴＴＰプロトコルの伝送シーケンスは、基本的には、たとえば、図１４（ｂ）の各ステップに従う。

（ステップ−ｐ１）および（ステップ−ｐ２）は、前述と同様である。

（ステップ−ｃ１）において、送信側は、受信側から要求された補助データファイルを受信側に送る。

（ステップ−ｃ２）において、受信側は、送信側より受け取った補助ファイルを参照してＭＰＥＧファイルの１以上の部分よりＶＯＢ単位、Ｉピクチャ単位で、ＭＰＥＧデータを要求する。たとえば、受信側は図１６（ａ）のＲａｎｇｅ、Ｎｏ．１、Ｎｏ．２、Ｎｏ．３の３つのデータを要求する。ここで、補助データファイルは、記録メディアの論理フォーマット情報をベースとして、その論理フォーマット上にパーシャルＭＰＥＧ−ＴＳやＤＶストリームが配置（マッピング）されている。

この配置方法としては、たとえば、ＢＤ−ＲＥ規格（Ｂｌｕ−ｒａｙ Ｄｉｓｋ Ｒｅｗｒｉｔａｂｌｅ ＦｏｒｍａｔのＰａｒｔ１、Ｐａｒｔ２、Ｐａｒｔ３）において規定されているＰｌａｙＬｉｓｔファイルやＣｌｉｐＩｎｆｏｒｍａｔｉｏｎファイルを参照することにより、ＢＤ−ＲＥ対応のディスク上へのパーシャルＭＰＥＧ−ＴＳの配置方法である。ＰｌａｙＬｉｓｔファイルやＣｌｉｐＩｎｆｏｒｍａｔｉｏｎファイルを参照することにより、ＢＤ−ＲＥ対応のディスク上へのパーシャルＭＰＥＧ−ＴＳの配置の対応付けについては、たとえば、松下テクニカルジャーナル、２００４年１０月、３４ページから３８ページ、「Ｂｒｕ−ｒａｙ Ｄｉｓｋ Ｒｅｗｒｉｔａｂｌｅ Ｆｏｒｍａｔ（２）〜論理規格、著作権保護規格〜」や、日経エレクトロニクス、２００３年７月２１日号、１２５〜１３８ページ、で説明されている。

さて、ＢＤ−ＲＥ対応ディスクのようにデータ記録用論理セクタ（たとえば、ＨＤＤではＬＢＡに相当し、数百から数ｋバイトに設定される）へのパーシャルＭＰＥＧ−ＴＳの配置としては、必ずしも論理セクタ先頭と補助データ付きパーシャルＭＰＥＧ−ＴＳ先頭とは一致しない。そこで、論理セクタ番号とその論理セクタ内の先頭からのオフセット（位置）情報のペアにより、パーシャルＭＰＥＧ−ＴＳなどの記録データ位置を表わすことができる。

ディスク上に記録されたパーシャルＭＰＥＧ−ＴＳの位置情報が、論理セクタ番号とその論理セクタ内の先頭からのオフセット（位置）情報のペアで管理されている場合、そのセクタの先頭から記録されている直前の位置までに存在データは不要なデータなデータである。特に編集を行うと、この不要データだけではＭＰＥＧデコードができなくなるので、使い道のないゴミデータとなる。

本実施例では、ディスク上に記録されたパーシャルＭＰＥＧ−ＴＳの位置情報が、論理セクタ番号とその論理セクタ内の先頭からのオフセット（位置）情報のペアで管理されている場合、ネットワークを介してクライアントからサーバに対して、このような不要なデータを考慮して、有効データのみに効率的にアクセスして、スムースな特殊再生やその伝送を実現する。

さて、クライアントはサーバに対して、図１６（ａ）に示されたＲａｎｇｅ、Ｎｏ．１、Ｎｏ．２、Ｎｏ．３の３つのデータを要求（ＨＴＴＰのリクエスト）する。ここで、サーバ内の補助データファイルには、ＭＰＥＧ−ＴＳのＧＯＰ単位あるいはＩピクチャ単位でのデータ構造とともに、タイムベースの不連続情報（たとえば、ＤＩＴ）、および、ディスク上に記録されたパーシャルＭＰＥＧ−ＴＳの位置情報として論理セクタ番号とその論理セクタ内の先頭からのオフセット（位置）情報のペア情報などの補助データを記述してあり、クライアントはネットワークを介してサーバ内の補助データを参照する。

これにより、クライアントはサーバ内ディスクのセクタ上に記録されたパーシャルＭＰＥＧ−ＴＳのＧＯＰ，Ｉピクチャなどの有効データを直接アクセス（ＨＴＴＰのレンジＧＥＴで必要名データをリクエストできる）できる。

図１６（ａ）に示されたＲａｎｇｅ、Ｎｏ．１、Ｎｏ．２の先頭と末尾には、それぞれ、黒い小さなブロックで表現される不要データが存在する。また、図１６（ａ）の送信データは、Ｒａｎｇｅ、Ｎｏ．１の右側の矢印で示しているようにＲａｎｇｅ、Ｎｏ．１中にタイムベースの不連続点を含んでいる。また、同図中、Ｒａｎｇｅ、Ｎｏ．３の先頭部の右側の矢印で示しているようにＲａｎｇｅ、Ｎｏ．３の先頭にタイムベースの不連続点を持つ。

この場合、受信側に送られるデータはＲａｎｇｅ、Ｎｏ．１、Ｎｏ．２、Ｎｏ．３それぞれにおいてタイムベースの不連続点を含んだ、無効データを除いた有効データブロックとなる。

受信データは、図１６（ｂ）に具体的に示されるように、（ｃ３−１）送信元の無効データを含まないで、かつタイムベースの不連続情報を含んだＲａｎｇｅ Ｎｏ．１の情報、（ｃ３−２）送信元の無効データを含まないＲａｎｇｅ Ｎｏ．２の情報、及び（ｃ３−３）タイムベースの不連続情報を先頭に付与されたＲａｎｇｅ Ｎｏ．３の情報である。

なお、送信側における暗号化情報ヘッダの付加分はパケット受信部で削除されるので、本説明でも正味の伝送コンテンツとして扱わないものとする。

また、伝送プロトコル（例えばＴＣＰ）によって、送信データがコネクションの切断を伴って分割される場合でも、元データが時間的に連続している限りは、分割されたそれぞれの送信データの先頭又は末尾に不連続情報が付加されない点についても前述したとおりである。

以上のように、タイムベースの不連続点を含んだ、無効データを除いた有効データブロックをサーバからクライアントに伝送制御することによって、一般的なＭＰＥＧのデコード動作（ＭＰＥＧデコードのアルゴリズムまたはシーケンスと同等の意味）に対して効率的なデータ伝送が実現できる。サーバ内のＭＰＥＧファイルのＧＯＰ構造やＩフレーム位置情報を活用することにより、早送り、巻き戻し、スロー再生などの特殊再生を効率よく実現できる。そこで、一般に、ＤＲＭ対応ＡＶコンテンツをＤＴＣＰ−ＩＰを適用して効率よく伝送することが可能となる。

［６］コピー制御情報を専用の伝達経路を用いて伝達する変形例
次に、コピー制御情報（ＣＣＩ）を専用の伝達経路を用いて伝達する変形例について説明する。本変形例におけるパケット送受信部１７４０１の構成を図１７に示す。

図１７に示されるパケット送受信部は、図１２のパケット送受信部８４０１と基本的に同様の構成であるが、図１７ではＣＣＩバッファ１７０１を具備し、ＴＳストリーム識別部４０２から暗号化データ生成部４２２へ、ＣＣＩバッファ１７０１を含む専用の伝達経路でＣＣＩを伝達する点で異なっている。以下では、前述と同様の事項については説明を省略し、異なる部分のみを説明する。

図１７において、ＴＳストリーム識別部４０２からコンテンツバッファ４１３に出力する信号は、各パーシャルＭＰＥＧ−ＴＳに４バイトのヘッダが付加されたストリームで、蓄積を想定したヘッダつきパーシャルＭＰＥＧ−ＴＳ（「蓄積型パーシャルＭＰＥＧ−ＴＳ」と呼ぶ）であるとする。ここで、この蓄積を想定したヘッダである４バイト（３２ビット）は、２ビットのＣＣＩと３０ビットのタイムスタンプにより構成されている。また、２ビットのＣＣＩは蓄積を想定したＣＣＩであり、暗号化しないコピーフリーモード（ＣＦ）、暗号化を行うコピーフリーモード（ＣＦ／ＥＰＮ：Ｅｎｃｒｉｐｔｉｏｎ ｐｌｕｓ ｎｏｎ−Ｉｎｓｅｒｓｉｏｎ）、コピーノーモアモード（ＣＮＭ）の３つのモードしかサポートしていない。この場合、コンテンツバッファ４１３が扱う信号形式は、たとえば、ＣＯＧモードやコピーネバー（ＣＮ）モードのＣＣＩをサポートしていない。

さて、日本の地上デジタル放送のような１世代のみコピー可能（ＣＯＧ）なコンテンツ（２００５年２月現在）を、一度、ＨＤＤに蓄積して再生する場合は、ＣＯＧの放送コンテンツは蓄積によりＣＮＭコンテンツになるので、その再生出力を「蓄積型パーシャルＭＰＥＧ−ＴＳ」形式で暗号化データ生成部４２２に渡して、「蓄積型パーシャルＭＰＥＧ−ＴＳ」形式のヘッダのＣＣＩにしたがって正常な暗号化、および暗号化ヘッダの付加ができる。

しかしながら、地上デジタル放送のＣＯＧコンテンツを、蓄積せずに直接、従来形式としての「蓄積型パーシャルＭＰＥＧ−ＴＳ」形式で暗号化データ生成部４２２に出力すると、「蓄積型パーシャルＭＰＥＧ−ＴＳ」形式では新たなモードとしてのＣＯＧモードをサポートしていないために、暗号化データ生成部４２２に正しいＣＣＩを継承して、「蓄積型パーシャルＭＰＥＧ−ＴＳ」形式のヘッダのＣＣＩにしたがって正常な暗号化、および暗号化ヘッダの付加ができない。

そこで、本実施例では、ＴＳストリーム識別部４０２から暗号化部４１４および暗号化情報ヘッダ付加部４１５に対して、正しいＣＣＩを伝えるためにＣＣＩバッファ１７０１を新たに追加する。

暗号化部４１４は、ＣＣＩバッファ１７０１、暗号化部４１４および暗号化ヘッダ付加部４１５は、ＣＯＧモードを含むパケット送受信部が使用する全てのＣＣＩを送るサポートする。ＣＣＩバッファ１７０１は、ＣＣＩバッファ１７０１を介して、コンテンツバッファ４１３のストリーム出力と同期して、暗号化部４１４および暗号化情報ヘッダ付加部４１５に対して正しいＣＣＩを伝える。これにより、ＣＯＧモードを含んだ、コンテンツバッファが扱う信号形式が、たとえば、ＣＯＧモードのＣＣＩがサポートしていなくても、正しいＣＣＩで暗号化および暗号化ヘッダの付加が可能となる。

以上のように、パケット送受信部１７４０１が従来の形式にしか対応していないため、内部で扱うＡＶストリームのヘッダが、そのパケット送受信部１７４０１で扱う全てのＣＣＩモードに対応していない場合、パケット送受信部１７４０１が取り扱う全てのＣＣＩモードを取り扱う経路とストリームの暗号化とタイミングを合わせるバッファを具備することにより、従来構成のパケット送受信部でも新たなＣＣＩモードの追加が可能となる。

このＣＣＩモードのサポートは送信側だけでなく、受信側でも送信側同様にＣＣＩモード専用の経路およびバッファを設けることにより、同様の効果を発揮できる。

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

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

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

さらに、上記実施の形態では、通信網プロトコルとしてイーサネット（登録商標）を例としたが、本発明は、この限りではなく、ＩＥＥＥ ８０２．１１ａ／ｂなどの無線のプロトコルをもちいることもできる。

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

パケット化部は、ＡＶデータを構成するデータブロックにタイムスタンプを付加し、１つ以上のタイムスタンプ付データブロックをまとめてＲＴＰまたはＨＴＴＰのペイロードとしてマッピングすることによって前記パケット化を行える。

また、パケット化手段は、ＡＶデータをＭＰＥＧ−ＴＳで伝送する場合、各ＴＳパケットにタイムスタンプを付加し、複数のタイムスタンプ付ＴＳパケットをまとめてＲＴＰまたはＨＴＴＰ上にマッピングする。

また、各ＴＳパケットに付加するタイムスタンプのクロックはＭＰＥＧのシステムクロック周波数に等しく、パケット送信装置はさらに、ＴＳパケットを受信し、受信したＴＳパケットに付加されたタイムスタンプより、ＭＰＥＧ−ＴＳのネットワーク伝送によりＰｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ（ＰＣＲ）に付加された伝送ジッターを除去して、ＭＰＥＧシステムクロックの再生を行うクロック再生手段を備える。

さらに、パケット化手段は、外部入力されたＴＳに付加されたタイムスタンプの有効ビット数または蓄積メディアから再生されたＴＳに付加されたタイムスタンプの有効ビット数が各ＴＳパケットに付加するタイムスタンプの有効ビット数と異なる場合に、ＭＰＥＧストリームのＰＣＲが不連続になりシステムタイムベースの不連続が発生しない時、また、ＴＳのｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒの不連続が発生しない時は、前記外部入力されたＴＳに付加されたタイムスタンプまたは蓄積メディアから再生されたＴＳに付加されたタイムスタンプと、ＴＳパケットに付加するタイムスタンプとを変えずに載せ変えだけを行ない、ストリームのＭＰＥＧのＰＣＲが不連続になりシステムタイムベースの不連続が発生するポイントまたはＴＳのｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒの不連続が発生するときは、不連続の発生点でＴＳの不連続発生を通知するＴＳパケットを挿入することで、パケット化を行う。

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

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

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

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

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

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

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

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

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

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

本発明は、地上デジタル放送などを受信して、その選局信号をＩＰネットワークを介し別室のテレビやパソコンに伝送してリモート視聴を可能にする。また、デジタル放送の受信信号をＨＤＤやＤＶＤディスクに記録し、その再生信号をＩＰネットワークを介して別室から記録コンテンツのタイトル選択や、特殊再生を行いながら、リモート視聴することを可能とする。特に、デジタル放送やＤＶＤディスクなどコピー制限されたコンテンツをその著作権者によって設定されたコピー制御情報の継承処理するため違法コピーを禁止できる。

図１（ａ）は従来技術による送受信システムの説明図であり、図１（ｂ）はソース機器およびシンク機器の例を示す図である。 図２は、従来技術におけるパケット送受信部のブロック図である。 図３は、従来技術である１３９４を用いたＤＴＣＰ方式によるコンテンツ伝送手順の説明図である。 図４は、従来技術である１３９４を用いたＤＴＣＰ方式によるパケット形式の説明図である。 図５は、本発明における送受信システムの説明図である。 図６は、本発明における鍵交換にＤＴＣＰ方式を適用する場合のコンテンツ伝送手順の説明図である。 図７は、イーサネット（登録商標）を用いる一般家庭に本発明を適用した場合の一例の説明図である。 図８は、本発明におけるパケット送受信部のブロック図である。 図９は、本発明における認証と鍵交換にＤＴＣＰ方式を適用する場合のコンテンツ伝送手順の説明図である。 図１０は、本発明におけるＭＰＥＧ−ＴＳのイーサネット（登録商標）フレーム構成仕様の例を示す図である。 図１１は、本発明におけるパケット送受信部のブロック図である。 図１２は、本発明におけるパケット送受信部のブロック図である。 図１３は、ピクチャ情報ファイルの構成を示す図である。 図１４（ａ）は本発明におけるＨＴＴＰによるパケット送信の対象となるＡＶデータの一例を示す図であり、図１４（ｂ）は送信手順の一例を示すシーケンスチャートであり、図１４（ｃ）は伝送されるデータの一例を示す図である。 図１５（ａ）は本発明におけるＨＴＴＰによるパケット送信の対象となるＡＶデータの一例を不連続点と共に示す図であり、図１５（ｂ）は伝送されるデータの一例を示す図である。 図１６（ａ）は本発明におけるＨＴＴＰによるパケット送信の対象となる無効データを含んだＡＶデータの一例を示す図であり、図１６（ｂ）は伝送されるデータの一例を示す図である。 図１７は、本発明におけるパケット送受信部のブロック図である。

符号の説明

１０１ パケット送信機器
１０２ ルータ
１０３ パケット受信機器
３０１、３０２ ネットワークシステム
３０３ ルータ
３０４ スイッチングハブ
３０５ ネットワーク
４０１ パケット送受信部
４０２ ＴＳストリーム識別部
４０３ 送信条件設定管理部
４０４ ＤＲＭ設定管理部
４０５ ＡＫＥ部
４０６ パケット化部
４０７ 送信キュー制御部
４０８ フレーム化部
４０９ フレーム受信部
４１０ パケット受信部
４１１ ＤＲＭコンテンツ購入決済部
４１２ コンテンツメタ情報
４１３ コンテンツバッファ
４１４ 暗号化部
４１５ 暗号化情報ヘッダ付加部
４１６ ＨＴＴＰ／ＲＴＰヘッダ付加部
４１７ 受信条件設定管理部
４１８ 暗号化データ復号部
４１９ 認証部
４２０ 暗号化鍵交換部
４２１ 認証モード決定部
４２２ 暗号化データ生成部
７０１ 蓄積部
８０１ データ配列情報生成管理部
９０１ ソース
９０２ シンク
９０３ ネットワーク
１００１ ＡＫＥ部
１００２ パケット化部
１００３ 送信条件設定部
１００４ パケット受信部
１００５ 暗号化部
１００６ 復号部
１００７ ネットワーク
１７０１ ＣＣＩバッファ
７４０１、８４０１、１７４０１ パケット送受信部

Claims (7)

1. パケット受信装置にパケットデータを送信するパケット送信装置であって、
   ＡＶデータが入力される端子を示す入力端子情報、前記ＡＶデータのデータフォーマットを示すデータフォーマット情報、または、前記ＡＶデータの属性を示す属性情報のうち少なくとも１つの情報を含むＡＶデータ情報を取得するＡＶデータ情報取得手段と、
   前記ＡＶデータ及び非ＡＶデータの入力を受け付けるデータ入力手段と、
   前記非ＡＶデータまたは前記ＡＶデータより、前記ＡＶデータの課金情報、再生制御情報、または、コピー制御情報、パケットデータ送信許可情報、送信相手のＭＡＣアドレス情報のうち少なくとも１つの情報を抽出し、抽出した情報から、前記ＡＶデータを送信する際の暗号化モードを示す暗号化モード情報を生成する送信条件設定管理手段と、
   前記入力端子情報、前記データフォーマット情報及び前記属性情報を組み合わせて決定される送信条件に基づいて、前記データ入力手段より入力された前記ＡＶデータの暗号化制御を行い、前記暗号化モード情報に基づく暗号化情報ヘッダを暗号化制御された前記ＡＶデータに付加することによって暗号化情報ヘッダ付き被暗号化制御送信データを生成する暗号化送信データ生成手段と、
   前記暗号化送信データ生成手段により生成された暗号化情報ヘッダ付き被暗号化制御送信データを含んだデータに対して、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ、及びＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌのうち、１つ以上のプロトコルを組み合わせたパケットヘッダを付加すると共に、前記ＡＶデータにおけるタイムベースの不連続が発生する点にＭＰＥＧストリームのシステムタイムベースの不連続を表す情報を付加することによってパケットを生成するパケット化手段と、
   前記パケット受信装置との間で認証処理を行う認証手段と、
   前記入力端子情報、前記属性情報及び前記パケット受信装置より指定される送信モードを示す情報の少なくとも１つを用いて、前記パケット送信装置と前記パケット受信装置の間での前記ＡＶデータの伝送プロトコルを決定する伝送プロトコル決定手段と、
   前記認証処理によって前記パケット受信装置との認証処理が完了した後に、前記伝送プロトコル決定手段によって決定された伝送プロトコルに従って、前記パケット化手段によって生成された暗号化情報ヘッダ付き被暗号化制御送信データを含むパケットを前記パケット受信装置に伝送する伝送手段と
   を備えることを特徴とするパケット送信装置。
2. 前記認証手段は、前記パケット送信装置内における前記ＡＶデータのＵＲＩ情報または拡張ＵＲＩ情報を用いて、前記パケット受信装置との間で前記ＡＶデータのアドレス情報の取得および認証処理を行う
   ことを特徴とする請求項１に記載のパケット送信装置。
3. 前記パケット化手段は、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌによるデータ伝送において、伝送される前記ＡＶデータが通信回線におけるコネクションの張り直しのために分断される箇所には、ＭＰＥＧストリームのシステムタイムベースの不連続を表す情報を付加しない
   ことを特徴とする請求項１に記載のパケット送信装置。
4. 前記パケット化手段はＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌレスポンスに挿入するデータ長は、元のデータ長に前記タイムベースの不連続を表す情報の長さ分を付加した長さとする
   ことを特徴とする請求項１に記載のパケット送信装置。
5. 前記パケット化手段はＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌレスポンスに挿入するデータ長として、元のデータ長に前記タイムベースの不連続を表す情報の長さ分を付加した長さをレスポンスとして送信する場合、送信データ中の有効データの開始位置または終了位置に関する情報に前記タイムベースの不連続を表す情報の長さ分だけオフセットさせて有効データを取得するためのオフセット情報を伝える
   ことを特徴とする請求項４に記載のパケット送信装置。
6. パケット受信装置にパケットデータを送信するパケット送信方法であって、
   ＡＶデータが入力される端子を示す入力端子情報、前記ＡＶデータのデータフォーマットを示すデータフォーマット情報、または、前記ＡＶデータの属性を示す属性情報のうち少なくとも１つの情報を含むＡＶデータ情報を取得するＡＶデータ情報取得ステップと、
   前記ＡＶデータ及び非ＡＶデータの入力を受け付けるデータ入力ステップと、
   前記非ＡＶデータまたは前記ＡＶデータより、前記ＡＶデータの課金情報、再生制御情報、または、コピー制御情報、パケットデータ送信許可情報、送信相手のＭＡＣアドレス情報のうち少なくとも１つの情報を抽出し、抽出した情報から、前記ＡＶデータを送信する際の暗号化モードを示す暗号化モード情報を生成する送信条件設定管理ステップと、
   前記入力端子情報、前記データフォーマット情報及び前記属性情報を組み合わせて決定される送信条件に基づいて、前記データ入力手段より入力された前記ＡＶデータの暗号化制御を行い、前記暗号化モード情報に基づく暗号化情報ヘッダを暗号化制御された前記ＡＶデータに付加することによって暗号化情報ヘッダ付き被暗号化制御送信データを生成する暗号化送信データ生成ステップと、
   前記暗号化送信データ生成手段により生成された暗号化情報ヘッダ付き被暗号化制御送信データを含んだデータに対して、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ、及びＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌのうち、１つ以上のプロトコルを組み合わせたパケットヘッダを付加すると共に、前記ＡＶデータにおけるタイムベースの不連続が発生する点にＭＰＥＧストリームのシステムタイムベースの不連続を表す情報を付加することによってパケットを生成するパケット化ステップと、
   前記パケット受信装置との間で認証処理を行う認証ステップと、
   前記入力端子情報、前記属性情報及び前記パケット受信装置より指定される送信モードを示す情報の少なくとも１つを用いて、前記パケット送信装置と前記パケット受信装置の間での前記ＡＶデータの伝送プロトコルを決定する伝送プロトコル決定ステップと、
   前記認証処理によって前記パケット受信装置との認証処理が完了した後に、前記伝送プロトコル決定ステップで決定された伝送プロトコルに従って、前記パケット化手段によって生成された暗号化情報ヘッダ付き被暗号化制御送信データを含むパケットを前記パケット受信装置に伝送する伝送ステップと
   を含むことを特徴とするパケット送信方法。
7. パケット受信装置にパケットデータを送信するためのコンピュータ実行可能なプログラムであって、
   ＡＶデータが入力される端子を示す入力端子情報、前記ＡＶデータのデータフォーマットを示すデータフォーマット情報、または、前記ＡＶデータの属性を示す属性情報のうち少なくとも１つの情報を含むＡＶデータ情報を取得するＡＶデータ情報取得ステップと、
   前記ＡＶデータ及び非ＡＶデータの入力を受け付けるデータ入力ステップと、
   前記非ＡＶデータまたは前記ＡＶデータより、前記ＡＶデータの課金情報、再生制御情報、または、コピー制御情報、パケットデータ送信許可情報、送信相手のＭＡＣアドレス情報のうち少なくとも１つの情報を抽出し、抽出した情報から、前記ＡＶデータを送信する際の暗号化モードを示す暗号化モード情報を生成する送信条件設定管理ステップと、
   前記入力端子情報、前記データフォーマット情報及び前記属性情報を組み合わせて決定される送信条件に基づいて、前記データ入力手段より入力された前記ＡＶデータの暗号化制御を行い、前記暗号化モード情報に基づく暗号化情報ヘッダを暗号化制御された前記ＡＶデータに付加することによって暗号化情報ヘッダ付き被暗号化制御送信データを生成する暗号化送信データ生成ステップと、
   前記暗号化送信データ生成手段により生成された暗号化情報ヘッダ付き被暗号化制御送信データを含んだデータに対して、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ、及びＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌのうち、１つ以上のプロトコルを組み合わせたパケットヘッダを付加すると共に、前記ＡＶデータにおけるタイムベースの不連続が発生する点にＭＰＥＧストリームのシステムタイムベースの不連続を表す情報を付加することによってパケットを生成するパケット化ステップと、
   前記パケット受信装置との間で認証処理を行う認証ステップと、
   前記入力端子情報、前記属性情報及び前記パケット受信装置より指定される送信モードを示す情報の少なくとも１つを用いて、前記パケット送信装置と前記パケット受信装置の間での前記ＡＶデータの伝送プロトコルを決定する伝送プロトコル決定ステップと、
   前記認証処理によって前記パケット受信装置との認証処理が完了した後に、前記伝送プロトコル決定ステップで決定された伝送プロトコルに従って、前記パケット化手段によって生成された暗号化情報ヘッダ付き被暗号化制御送信データを含むパケットを前記パケット受信装置に伝送する伝送ステップと
   をコンピュータに実行させることを特徴とするプログラム。

Images