(57)【要約】  ＤＴＣＰ等のコンテンツ保護技術で保護されたコンテンツをＩＰパケット等の広く普及したパケットで送信すると共に、多様なＥＰＧ情報を提供可能なパケット送信装置を提供する。  ＡＶストリームのメタデータを活用し、ストリームに含まれる映像、音声およびデータなどコンテンツの出力モード、暗号化モード、暗号化情報ヘッダ付加等を制御する（４０７）。これによりパケット送受信装置間で、秘匿性を保ちながら相互接続互換性を確保する（４１４）。ＡＶストリームとしてデジタルテレビ放送の受信コンテンツを用いる場合、放送受信したフルトランスポートストリームからチャンネル選局することにより（４０９）、パーシャルトランスポートストリームを抽出・構築して用いる（４１０）。ＥＰＧ情報を、デジタル放送信号に含まれるＳＩ情報からだけでなく、ＥＰＧ専用チャンネルやＩｎｔｅｒｎｅｔなど複数の情報源から選択可能にする（４１２）。【特許請求の範囲】
【請求項１】
番組に関する第１のプログラム情報を含む入力ストリームを受信する受信手段と、
前記受信された入力ストリームから前記第１のプログラム情報を抽出すると共に、放送チャンネル及び通信ネットワークのうちの少なくとも一方から前記番組に関する第２のプログラム情報を取得するプログラム情報取得手段と、
前記第１のプログラム情報及び前記第２のプログラム情報の一方を選択するか又は両方を合成して、前記番組に関する新たなプログラム情報を再構成するプログラム情報再構成手段と、
前記再構成された新たなプログラム情報を用いて前記入力されたストリームにフィルタリング処理を行うフィルタリング手段と、
前記フィルタリング後の前記入力ストリームを含む新たな出力ストリームを構成し、構成された出力ストリームをパケット化して外部へ送信する送信手段と
を備えることを特徴とするパケット送信装置。
【請求項２】
前記受信手段は放送信号から前記入力ストリームを受信し、
さらに、
前記放送信号とは異なる外部入力信号から他の入力ストリームを受け付ける入力手段と、
前記受信手段によって受信される入力ストリーム及び前記入力手段によって受け付けられる入力ストリームの何れかを選択するスイッチャと、
前記選択された入力ストリームから、その入力ストリームに含まれるコンテンツデータのデータフォーマットを示すデータフォーマット情報、又は前記コンテンツデータの属性を示す属性情報を検出する信号フォーマット及びプロパティ検出手段と、
前記検出されたデータフォーマット情報又は属性情報をトランスポートパケットにカプセル化するカプセル化手段と、
前記選択された入力ストリームに含まれるコンテンツデータに関するデスクリプタを生成し、前記入力ストリームに挿入するデスクリプタ挿入手段と、
前記カプセル化されたトランスポートパケットと、前記デスクリプタ挿入後の入力ストリームのトランスポートパケットとを、後者に比べて前者へより大きな遅延を与えて多重化すると共に、それぞれのトランスポートパケットにタイムスタンプを付加することにより、パーシャルトランスポートストリームを生成するパーシャルトランスポートストリーム生成手段と、
前記生成されたパーシャルトランスポートストリームのトランスポートパケットを所定の大きさの伝送パケットペイロードに変換するデータブロック化手段と、
前記所定の大きさを表すサイズ情報を含むと共に、前記検出されたデータフォーマット情報又は属性情報が前記コンテンツデータの伝送、複製、又は再生に関する制御情報である場合にはその制御情報を含む伝送パケットヘッダを生成する伝送パケットヘッダ生成手段と、
前記変換された伝送パケットペイロードと、前記生成された伝送パケットヘッダとを結合することにより、伝送パケットを生成する伝送パケット生成手段と
を備えることを特徴とする請求項１に記載のパケット送信装置。
【請求項３】
前記属性情報は、放送システムの種別、放送ネットワーク識別、放送の編成チャンネル情報、番組名、番組のジャンル、チャンネル番号、番組の開始時間、番組の終了時間、番組の説明記述のうち少なくとも一つを表す
ことを特徴とする請求項２記載のパケット送信装置。
【請求項４】
前記選択された入力ストリームがフルトランスポートストリームの場合には、前記伝送パケットペイロードの大きさはそのフルトランスポートストリームを受信した時間長で指定され、
前記選択された入力ストリームがパーシャルトランスポートストリームの場合には、前記伝送パケットペイロードの大きさは時間長またはバイト長で指定される
ことを特徴とする請求項２記載のパケット送信装置。
【請求項５】
前記デスクリプタ挿入手段は、前記選択された入力ストリームに含まれる、放送システムの種別、放送ネットワーク識別、放送の編成チャンネル情報、コピー制御情報のうち少なくとも１つの情報を制御情報として用いて、ＤＴＣＰ＿ｄｅｓｃｉｐｔｏｒまたはＤＴＣＰ＿ａｕｄｉｏ＿ｄｅｓｃｒｉｐｔｏｒを生成し、生成したＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒまたは前記ＤＴＣＰ＿ａｕｄｉｏ＿ｄｅｓｃｒｉｐｔｏｒを前記入力ストリームのＰｒｏｇｒａｍ  Ｍａｐ  Ｔａｂｌｅに挿入する
ことを特徴とする請求項２記載のパケット送信装置。
【請求項６】
前記カプセル化手段は、前記選択された入力ストリームの単位プログラムのコピー制御情報の内容に係わらず、同じデータフォーマット情報または同じＭＩＭＥ−Ｔｙｐｅをトランスポートパケットにカプセル化する
ことを特徴とする請求項５記載のパケット送信装置。
【請求項７】
ＨＴＴＰプロトコルによるデータ伝送の対象を、ＭＰＥＧのＧＯＰ、ピクチャ、スライス、マクロブロック、ブロック、ＴＳパケット、タイムスタンプを付加したＴＳパケット、又は、記録メディアのセクタサイズ、クラスタサイズ、論理ブロックサイズのいずれかの単位で指定したデータリクエストを外部から受け付ける
ことを特徴とする請求項２記載のパケット送信装置。
【請求項８】
さらに、前記選択された入力ストリームに含まれるコンテンツデータの表現形式をＭＰＥＧ−２とＨ．２６４との間で形式変換するトランスコーダを備え、
前記トランスコーダによって形式変換された後の入力ストリームをパーシャルトランスポートにして出力する
ことを特徴とする請求項２記載のパケット送信装置。
【請求項９】
さらに、前記選択された入力ストリームをファイルとして蓄積する蓄積手段を備える
ことを特徴とする請求項２記載のパケット送信装置。
【請求項１０】
再生時に、ファイル内での位置情報管理表で指定された各コンテンツにアクセスするために、
各コンテンツに含まれる１つ以上のフレーム画像を構成するタイトルデータ又は画像データのいずれかをＩｎｔｅｒｎｅｔ上のコンテンツ情報サービスに問い合わせ、該コンテンツが含む１つ以上のシーンに関するメタデータ又は放送日時データを取得し、前記取得データを前記蓄積手段に記録されている該コンテンツの記録管理情報にリンクさせたコンテンツ詳細内容テーブルを作成する手段と、再生の際には前記コンテンツ詳細内容テーブルを参照してコンテンツ内の各シーンにアクセスする手段を備える
ことを特徴とする請求項９記載のパケット送信装置。
【請求項１１】
前記蓄積手段に高解像度のコンテンツとそのメタデータが蓄積されている場合、前記高解像度コンテンツを低解像度コンテンツに変換する手段をさらに備え、
受信側はネットワークを介して前記高解像度コンテンツから変換された前記低解像度コンテンツを受信し、前記低解像度コンテンツよりコンテンツ選択・取得リストを作成した後、前記コンテンツ選択・取得リストを送信側に伝送し、
送信側は受信したコンテンツ選択・取得リストに基づき高解像度コンテンツを受信側に伝送する手段を備える
ことを特徴とする請求項９記載のパケット送信装置。
【請求項１２】
前記制御手段は、前記蓄積手段に蓄積されている前記ファイルが音楽に関するコンテンツを含んでいる場合、
Ｉｎｔｅｒｎｅｔ上の楽曲情報サーバにアクセスして、該音楽番組内の楽曲情報を取得し、取得した該音楽に関係したファイル内の楽曲情報と蓄積手段に記録されている該音楽に関するファイル内の複数の楽曲とを該音楽番組のタイムレンジ情報で関連付けた楽曲位置テーブルを作成し、蓄積手段の楽曲位置テーブル格納用ディレクトリに記録し、再生の際には前記楽曲いたテーブルを持つファイル内の各楽曲にアクセスする手段を備える
ことを特徴とする請求項９記載のパケット送信装置。
【請求項１３】
外音楽番組中の各楽曲に対してＵＰｎＰ−ＡＶのコンテンツディレクトリサービスでブラウズ、サーチなどを行うと、該音楽番組タイトルのファイル又はＵＰｎＰの＜ｒｅｓ＞内の各楽曲に対する前記楽曲位置テーブルにアクセスする手段を備える
ことを特徴とする請求項１２記載のパケット送信装置。
【請求項１４】
再生時に前記楽曲位置テーブルを持つファイル内の各楽曲にアクセスするために、
受信装置よりＣＧＩにパラメータとして楽曲名を指定して、送信装置に送り、送信装置では前記ＣＧＩのパラメータを利用して前記ファイルより各楽曲にアクセスする手段を備える
ことを特徴とする請求項１２記載のパケット送信装置。
【請求項１５】
左眼用映像、右眼用映像をそれぞれＨ．２６４信号に符号化するＨ．２６４エンコーダと前記Ｈ．２６４エンコーダの出力をトランスポートストリームパケットに変換する手段とを備え、前記Ｈ．２６４エンコーダでのエンコードの際、２ｃｈ映像はお互いに時間的に最も近いフレームでＨ．２６４のＩＤＲピクチャを構成するようにエンコードして２チャンネル映像の同期を取り、請求項１で記載したパケット送信装置２台に２つのトランスポートストリームパケットをそれぞれ入力する手段を備える
ことを特徴とする請求項２記載のパケット送信装置。
【請求項１６】
前記左眼用映像、前記右眼用映像をそれぞれＨ．２６４信号に符号化する際、何れか一方の映像は他方の映像を参照することにより、何れか一方の映像はＢピクチャ又はＰピクチャにのみ符号化する手段を備える
ことを特徴とする請求項１５記載のパケット送信装置。
【請求項１７】
番組に関する第１のプログラム情報を含む入力ストリームを受信する受信ステップと、
前記受信された入力ストリームから前記第１のプログラム情報を抽出すると共に、放送チャンネル及び通信ネットワークのうちの少なくとも一方から前記番組に関する第２のプログラム情報を取得するプログラム情報取得ステップと、
前記第１のプログラム情報及び前記第２のプログラム情報の一方を選択するか又は両方を合成して、前記番組に関する新たなプログラム情報を再構成するプログラム情報再構成ステップと、
前記再構成された新たなプログラム情報を用いて前記入力されたストリームにフィルタリング処理を行うフィルタリングステップと、
前記フィルタリング後の前記入力ストリームを含む新たな出力ストリームを構成し、構成された出力ストリームをパケット化して外部へ送信する送信ステップと
を備えることを特徴とするパケット送信方法。
【請求項１８】
パケット送信を行うためのコンピュータ実行可能なプログラムであって、
番組に関する第１のプログラム情報を含む入力ストリームを受信する受信ステップと、
前記受信された入力ストリームから前記第１のプログラム情報を抽出すると共に、放送チャンネル及び通信ネットワークのうちの少なくとも一方から前記番組に関する第２のプログラム情報を取得するプログラム情報取得ステップと、
前記第１のプログラム情報及び前記第２のプログラム情報の一方を選択するか又は両方を合成して、前記番組に関する新たなプログラム情報を再構成するプログラム情報再構成ステップと、
前記再構成された新たなプログラム情報を用いて前記入力されたストリームにフィルタリング処理を行うフィルタリングステップと、
前記フィルタリング後の前記入力ストリームを含む新たな出力ストリームを構成し、構成された出力ストリームをパケット化して外部へ送信する送信ステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項１９】
請求項１８に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＥＥＥ８０２．３などのイーサネット（登録商標）などの有線ＬＡＮやＩＥＥＥ８０２．１１などの無線ＬＡＮなどを用いて、ＭＰＥＧ−２やＨ．２６４などで圧縮されたＡＶストリームを暗号化した後、ＩＰパケット化して高品質に送信するパケット送信装置に関する。
【背景技術】
【０００２】
デジタルＴＶ放送の開始に伴い、家庭でも手軽にハイビジョン品質（ＨＤ品質）のＴＶ視聴が可能となり、現在、ＴＶ受信機の普及が加速している。【０００３】
一方、近年、通信やネットワーク技術の発展に伴い、効率よくパケットを伝送するために様々な技術が提案されている（例えば、特許文献１参照）。その一つとして、従来、一般家庭において、部屋内でデジタル放送チューナやＤＶＨＳ方式ビデオレコーダ間をＩＥＥＥ  １３９４方式デジタルインターフェースで接続し、ＩＥＣ  ６１８８３−４で規定されたＭＰＥＧ−ＴＳ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ、Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ）信号の伝送が行われている。ここで、放送コンテンツにコピーワンジェネレーション（Ｃｏｐｙ  Ｏｎｅ  Ｇｅｎｅｒａｔｉｏｎ、ＣＯＧと略す）などのコピー制御モードでコンテンツ保護がかかっている場合、コンテンツを不正コピーから保護するため、コンテンツを暗号化してセキュアに伝送する必要がある。【０００４】
この様にデジタル放送を受信・選局して得られたパーシャルＭＰＥＧ−ＴＳなどのＡＶデータを暗号化して伝送する方式の一例として、ＤＴＣＰ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ）方式が規定されている。ＤＴＣＰは、ＩＥＥＥ１３９４やＵＳＢなどの伝送メディア上のコンテンツ保護技術である。ＤＴＣＰ方式は、ＤＴＬＡ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｌｉｃｅｎｃｉｎｇ  Ａｄｍｉｎｉｓｔｒａｔｏｒ）で規格化された方式であり、  ＨＹＰＥＲＬＩＮＫ“ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ”  ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ、  ＨＹＰＥＲＬＩＮＫ  “ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｄｔｃｐ＃ｔｕｔ．ｐｄｆ”  ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｄｔｃｐ＃ｔｕｔ．ｐｄｆ、ＨＹＰＥＲＬＩＮＫ  “ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｗｐ＃ｓｐｅｃ．ｐｄｆ”  ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｗｐ＃ｓｐｅｃ．ｐｄｆや、書籍「ＩＥＥＥ１３９４、ＡＶ機器への応用」、高田信司監修、日刊工業新聞社、「第８章、コピープロテクション」、１３３〜１４９ページで説明されている。【０００５】
ここで、ＭＰＥＧトランスポートストリーム（ＭＰＥＧ−ＴＳと略す）について説明する。ＭＰＥＧ−ＴＳはＭＰＥＧトランスポートパケット（ＴＳパケットと略す）が複数個集まったものである。ＴＳパケットは１８８ｂｙｔｅの固定長パケットで、その長さはＡＴＭのセル長（５３バイト中、ＡＴＭペイロードは４７バイト）との整合性、およびリードソロモン符号などの誤り訂正符号化を行なう場合の適用性を考慮して決定されている。【０００６】
ＴＳパケットは４ｂｙｔｅ固定長のパケットヘッダと可変長のアダプテーションフィールド（ａｄａｐｔａｔｉｏｎ  ｆｉｅｌｄ）およびペイロード（ｐａｙｌｏａｄ）で構成される。パケットヘッダにはＰＩＤ（パケット識別子）や各種フラグが定義されている。このＰＩＤによりＴＳパケットの種類を識別する。ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄとｐａｙｌｏａｄは、片方のみが存在する場合と両方が存在する場合とがあり、その有無はパケットヘッダ内のフラグ（ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄ＿ｃｏｎｔｒｏｌ）により識別できる。ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄは、ＰＣＲ（Ｐｒｏｇｒａｍ＿Ｃｌｏｃｋ＿Ｒｅｆｅｒｅｎｃｅ）等の情報伝送、および、ＴＳパケットを１８８ｂｙｔｅ固定長にするためのＴＳパケット内でのスタッフィング機能を持つ。また、ＭＰＥＧ−２の場合、ＰＣＲは２７ＭＨｚのタイムスタンプで、符号化時の基準時間を復号器のＳＴＣ（Ｓｙｓｔｅｍ  Ｔｉｍｅ  Ｃｌｏｃｋ）で再現するためにＰＣＲ値が参照される。各ＴＳパケットに付加するタイムスタンプのクロックは、たとえば、ＭＰＥＧのシステムクロック周波数に等しく、パケット送信装置はさらに、ＴＳパケットを受信し、受信したＴＳパケットに付加されたタイムスタンプより、ＭＰＥＧ−ＴＳのネットワーク伝送によりＰｒｏｇｒａｍ  Ｃｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ（ＰＣＲ）に付加された伝送ジッターを除去して、ＭＰＥＧシステムクロックの再生を行うクロック再生手段を備える。【０００７】
ＭＰＥＧ−２のＴＳでは復号器のＳＴＣはＰＣＲによるＰＬＬ同期機能を持つ。このＰＬＬ同期の動作を安定させるためにＰＣＲの送信間隔は、ＭＰＥＧ規格で１００ｍｓｅｃ以内と決められている。映像や音声などの個別ストリームが収められたＭＰＥＧ−ＰＥＳパケットは同じＰＩＤ番号を持つ複数のＴＳパケットのペイロードに分割して伝送する。ここで、ＰＥＳパケットの先頭は、ＴＳパケットの先頭から開始するように構成される。【０００８】
トランスポートストリームは複数のプログラムを混合して伝送することができるため、ストリームに含まれているプログラムとそのプログラムを構成している映像や音声ストリームなどのプログラムの要素との関係を表すテーブル情報が用いられる。このテーブル情報はＰＳＩ（Ｐｒｏｇｒａｍ  Ｓｐｅｃｉｆｉｃ  Ｉｎｆｏｒｍａｔｉｏｎ）と呼ばれ、ＰＡＴ  （Ｐｒｏｇｒａｍ  Ａｓｓｏｃｉａｔｉｏｎ  Ｔａｂｌｅ）、ＰＭＴ（Ｐｒｏｇｒａｍ  Ｍａｐ  Ｔａｂｌｅ）などのテーブルを用いる。ＰＡＴ、ＰＭＴなどのＰＳＩはセクションと呼ばれる単位でＴＳパケット中のペイロードに配置されて伝送される。【０００９】
ＰＡＴにはプログラム番号に対応したＰＭＴのＰＩＤなどが指定されており、ＰＭＴには対応するプログラムに含まれる映像、音声、付加データおよびＰＣＲのＰＩＤが記述されるため、ＰＡＴとＰＭＴを参照することにより、ストリームの中から目的のプログラムを構成するＴＳパケットを取り出すことができる。ＴＳに関する参考文献としては、例えば、ＣＱ出版社、ＴＥＣＨ  Ｉ  Ｖｏ．４、「画像＆音声圧縮技術のすべて（インターネット／ディジタルテレビ、モバイル通信時代の必須技術）」、監修、藤原洋、第６章、「画像や音声を多重化するＭＰＥＧシステム」があり、同書にて解説されている。【００１０】
ＰＳＩやＳＩに関する論理的な階層構造、処理手順の例、選局処理の例に関して、「ディジタル放送受信機における選局技術」、三宅他、三洋電機技報、ＶＯＬ．３６、ＪＵＮＥ  ２００４、第７４号、３１ページから４４ページにて解説されている。【００１１】
また、デジタル放送で使用されるアクセス制御方式に関し、スクランブル、関連情報の仕様及びそれに関わる受信機仕様については、ＡＲＩＢ規格、ＡＲＩＢ  ＳＴＤ−Ｂ２５において規定されており、その運用については、ＡＲＩＢ技術資料、ＡＲＩＢ  ＴＲ−Ｂ１４およびＡＲＩＢ  ＴＲ−Ｂ１５において規定されている。【００１２】
図１（ａ）は、ＤＴＣＰ方式を用い、ＭＰＥＧ―ＴＳをＩＥＥＥ１３９４で伝送する一例を模式的に表した図面である。ＤＴＣＰ方式では、送信側（パケット送信機器）をソース１９０１、受信側（パケット受信機器）をシンク１９０２と呼び、暗号化したＭＰＥＧ−ＴＳなどのコンテンツをソース１９０１からネットワーク１９０３を介して、シンク１９０２へ伝送している。図１（ｂ）に、補足情報として、ソース機器およびシンク機器の例を併記する。【００１３】
図２は、ＤＴＣＰ方式における従来のパケット通信部の概略を説明する図であり、ここでは、図１のソース１９０１が備えるパケット送信部およびシンク１９０２が備えるパケット受信部の両方がパケット送受信部として示されている。まず、ＤＴＣＰ方式に準拠した認証と鍵交換（Ａｕｔｈｅｎｔｉｆｉｃａｔｉｏｎ  ａｎｄ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ、ＡＫＥと略する）が行なわれる。ＡＫＥ部２００１に対して、その認証と鍵交換の設定情報が入力され、この情報がパケット化部２００２に伝達され、パケット化部２００２において規定のヘッダが付加されたパケット化が行われ、ネットワーク２００７に出力される。ここで、パケット化部２００２は、送信条件設定部２００３により決定された送信パラメータにより、入力データのパケット化および送信を行なう。受信側では、ネットワーク２００７より入力する信号がパケット受信部２００４でパケットヘッダなどの識別によりフィルタリングされ、ＡＫＥ部２００１に入力される。これにより送信側（ソース）のＡＫＥ部と、受信側（シンク）のＡＫＥ部がネットワーク２００７を介してお互いにメッセージの通信ができる。すなわち、ＤＴＣＰ方式の手順に従い、認証と鍵交換を実行する。【００１４】
送信側（ソース）と、受信側（シンク）で認証と鍵交換が成立すれば、次に、ＡＶデータの伝送を行なう。ソースでは、ＭＰＥＧ−ＴＳ信号を暗号化部２００５に入力して、ＭＰＥＧ−ＴＳ信号を暗号化した後、この暗号化されたＭＰＥＧ−ＴＳ信号をパケット化部２００２に入力し、ネットワーク２００７に出力する。シンクでは、ネットワーク２００７より入力する信号がパケット受信部２００４でパケットヘッダなどの識別によりフィルタリングされ、復号部２００６に入力され、復号されＭＰＥＧ−ＴＳ信号が出力される。【００１５】
次に、図３を用いて上記手順を補足説明する。図３においては、ソースとシンク間はＩＥＥＥ１３９４で接続されていると仮定する。まず、ソース側でコンテンツの送信要求が発生する。そして、ソースからシンクへ暗号化されたコンテンツおよびコンテンツの保護モード情報が送信される。シンクは、コンテンツのコピー保護情報の解析を行い、完全認証もしくは制限付き認証のどちらの認証方式を用いるかを決定し、認証要求をソースに送る。ソースとシンクはＤＴＣＰ所定の処理により認証鍵の共有を図る。そして、ソースは認証鍵を用いて交換鍵を暗号化してシンクに送り、シンクで交換鍵が復号される。ソースでは暗号鍵を時間的に変化させるために、時間的に変化するシード情報を生成し、シンクに送信する。ソースでは、交換鍵とシード情報より暗号化鍵を生成して、ＭＰＥＧ−ＴＳをこの暗号化鍵を用いて暗号化部で暗号化してシンクに送信する。シンクはシード情報を受信し交換鍵とシード情報より復号鍵を復元する。シンクではこの復号鍵を用いて暗号化されたＭＰＥＧ−ＴＳ信号を復号する。【００１６】
図４は、図１においてＭＰＥＧ−ＴＳ信号を伝送する場合のＩＥＥＥ１３９４アイソクロナスパケットの一例である。このパケットは、４バイト（３２ビット）のヘッダ、４バイト（３２ビット）のヘッダＣＲＣ、２２４バイトのデータフィールド、４バイト（３２ニット）のトレイラによって構成されている。暗号化されて伝送されるのは２２４バイトのデータフィールドを構成するＣＩＰヘッダとＴＳ信号のうち、ＴＳ信号のみで、他のデータは暗号化されない。ここで、ＤＴＣＰ方式固有の情報は、コピー保護情報である２ビットのＥＭＩ（Ｅｎｃｒｉｐｔｉｏｎ  Ｍｏｄｅ  Ｉｎｄｉｃａｔｏｒ）、およびシード情報のＬＳＢビットであるＯ／Ｅ（Ｏｄｄ／Ｅｖｅｎ）であり、これらは上記３２ビットのヘッダ内に存在するため暗号化されずに伝送される。【００１７】
以上説明したようにして、デジタル放送を受信・選局して得られた放送番組のＡＶデータが、暗号化による保護の下に受信側へ送信される。なお、その際、そのＡＶデータと同じＴＳ信号に含まれているメタデータを、そのＡＶデータと共に受信側へ送ることは容易である。【００１８】
例えば、放送番組のＡＶデータと同じＴＳ信号には、電子番組表（ＥＰＧ）情報が多重化されて放送されている。ＥＰＧ情報は、放送番組に関するメタデータの典型的な一例である。ユーザは、ＥＰＧ情報を参照することによって、番組の選択や録画予約のための利便を享受できる。
【特許文献１】特開２０００−５９４６３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１９】
しかしながら、コンテンツと多重されるメタデータに加えて、他の情報源からもそのコンテンツに関する異なるメタデータが提供される状況において、好ましいメタデータをユーザに提示するための有効な技術は、いまだ知られていない。【００２０】
具体的に放送番組の例で言えば、現在では、放送番組のチャンネルとは別のＥＰＧ情報配信チャンネルや、インターネット上のテレビガイドサイト、テレビブログサイトといった多くの情報源から、その放送番組に関する多様なメタデータが提供される。【００２１】
例えば、インターネット上のテレビガイドサイトからは、放送番組と多重されるＥＰＧ情報に含まれる番組説明よりも詳細な番組説明が提供されるし、また、テレビブログサイトからは放送番組への感想や録画視聴する人への必見箇所の紹介といった、ＥＰＧ情報の内容を超えるメタデータが提供されている。【００２２】
以上を鑑み、本発明は、ＤＴＣＰ等のコンテンツ保護技術で保護されたコンテンツをＨＴＴＰプロトコルやＲＴＰプロトコルなどを利用してＩＰパケット化して送信すると共に、従来よりも多様なメタデータをユーザに提供できる可能性を高めたパケット送信装置を提供することを目的とする。
【課題を解決するための手段】
【００２３】
上記目的を達成するために、本発明に係るパケット送信装置は、番組に関する第１のプログラム情報を含む入力ストリームを受信する受信手段と、前記受信された入力ストリームから前記第１のプログラム情報を抽出すると共に、放送チャンネル及び通信ネットワークのうちの少なくとも一方から前記番組に関する第２のプログラム情報を取得するメタデータ取得手段と、前記第１のプログラム情報及び前記第２のプログラム情報の一方を選択するか又は両方を合成して、前記番組に関する新たなプログラム情報を再構成するプログラム情報再構成手段と、前記再構成された新たなプログラム情報を用いて前記入力されたストリームにフィルタリング処理を行うフィルタリング手段と、前記フィルタリング後の前記入力ストリームを含む新たな出力ストリームを構成し、構成された出力ストリームをパケット化して外部へ送信する送信手段とを備える。【００２４】
また、前記パケット送信装置において前記受信手段は放送信号から前記入力ストリームを受信し、さらに、前記パケット送信装置は、前記放送信号とは異なる外部入力信号から他の入力ストリームを受け付ける入力手段と、前記受信手段によって受信される入力ストリーム及び前記入力手段によって受け付けられる入力ストリームの何れかを選択するスイッチャと、前記選択された入力ストリームから、その入力ストリームに含まれるコンテンツデータのデータフォーマットを示すデータフォーマット情報、又は前記コンテンツデータの属性を示す属性情報を検出する信号フォーマット及びプロパティ検出手段と、前記検出されたデータフォーマット情報又は属性情報をトランスポートパケットにカプセル化するカプセル化手段と、前記選択された入力ストリームに含まれるコンテンツデータに関するデスクリプタを生成し、前記入力ストリームに挿入するデスクリプタ挿入手段と、前記カプセル化されたトランスポートパケットと、前記デスクリプタ挿入後の入力ストリームのトランスポートパケットとを、後者に比べて前者へより大きな遅延を与えて多重化すると共に、それぞれのトランスポートパケットにタイムスタンプを付加することにより、パーシャルトランスポートストリームを生成するパーシャルトランスポートストリーム生成手段と、前記生成されたパーシャルトランスポートストリームのトランスポートパケットを所定の大きさの伝送パケットペイロードに変換するデータブロック化手段と、前記所定の大きさを表すサイズ情報を含むと共に、前記検出されたデータフォーマット情報又は属性情報が前記コンテンツデータの伝送、複製、又は再生に関する制御情報である場合にはその制御情報を含む伝送パケットヘッダを生成する伝送パケットヘッダ生成手段と、前記変換された伝送パケットペイロードと、前記生成された伝送パケットヘッダとを結合することにより、伝送パケットを生成する伝送パケット生成手段とを備えてもよい。【００２５】
より具体的には、本願第１の発明は、入力されたＡＶデータとそのメタデータを用いて、規定の送信および受信条件によりデータブロックヘッダの付加制御および、暗号化制御を行ってパケット化を行なう。暗号化のモードは、ＭＰＥＧ−ＴＳ信号などのＡＶストリームのコピー制御情報（ＣＣＩ）を用いて行ない、パケット送受信機器間での信号の互換性を確保しながら、パケット伝送を行なうことが可能となる。【００２６】
放送のＥＰＧ情報として、たとえば、デジタル放送信号に含まれるＳＩ情報から抽出した情報、ＥＰＧ専用チャンネルから抽出した情報、ＩｎｔｅｒｎｅｔのＥＰＧ情報などから取得した情報があり、これらの情報は、放送システムの種別、放送ネットワーク識別、放送の編成チャンネル情報、番組名、番組のジャンル、チャンネル番号、番組の開始時間、番組の終了時間、番組の説明記述（簡易記述版、詳細記述版）などにより構成されている。【００２７】
本発明では、これら複数の情報源より、希望する情報を選択したり、個別情報を選択、結合し、ＥＰＧ情報を再構成することもできる点が従来の発明と大きく異なる。さらに上記情報の結合、再構成の際に、その情報源のアトリビュートを持ち、継承させることも可能である。【００２８】
本願第２の発明は、受信側より送信側にＨＴＴＰプロトコルによるデータ伝送の要求を行う場合に、複数の前記暗号化制御された前記ＡＶデータにより構成される、被伝送データブロックの先頭データまたは末尾データを、送信側で管理しているデータブロックの先頭データと一致させる。一例として、データがＭＰＥＧの場合には、送信側で管理するデータブロックの単位は、ＧＯＰまたは、Ｐｉｃｔｕｒｅまたは、マクロブロック、ブロック、ＴＳパケット、または、タイムスタンプ付きＴＳパケットの単位とすることができる。【００２９】
また、データブロックが送信装置に内蔵されたハードディスクドライブ（ＨＤＤと略す）やＣＤやＤＶＤ（ＤＶＤ−Ｒ、ＤＶＤ−ＲＡＭなど複数の種類がある）などの光ディスクの場合には、これはＨＤＤやＣＤやＤＶＤの各記録フォーマットにおける論理ブロックの単位とすることもできる。【００３０】
たとえば、データ（ファイルやストリーム）がＭＰＥＧの場合に、受信側より送信側にＨＴＴＰのレンジリクエストで要求するデータ範囲がＧＯＰ単位やＰｉｃｔｕｒｅ単位とデータ境界が合っていなくても（専門用語で、データのアライメントが取れていないなどとも言う）、送信側の処理としてＨＴＴＰレスポンスとして要求されたデータ範囲に近いところにあるＧＯＰ単位やＰｉｃｔｕｒｅ単位をレスポンスとして返信することができる。そこで、受信側では受信データから効率よくＭＰＥＧデコードを行うことができる。【００３１】
本願第３の発明は、上記のパケット送信手段の構成に加えて、ＭＰＥＧ−２／Ｈ．２６４トランスコーダを備え、蓄積手段に蓄積されたＭＰＥＧ−２  ＴＳのファイルをＨ．２６４にトランスコードする。これにより、画質を保ちながらファイルサイズを約２分の１以下に削減できるため、より多くのファイルの蓄積が可能になるとともに、より狭い帯域でＨ．２６４ストリームを実時間伝送すること、あるいは、より高速にファイル転送することができる。【００３２】
たとえば、家庭内ネットワークを無線ＬＡＮで構築している場合、ＭＰＥＧ−２では、ＨＤＴＶのＴＳビットレートが約２５Ｍｂｐｓとなり、無線ＬＡＮでは帯域が不足する場合でも、Ｈ．２６４の場合、約８Ｍｂｐｓに伝送レートを削減できるため、余裕を持って家庭内でのＨＤＴＶの無線伝送ができる。ＳＤＴＶの場合には、約１．５Ｍｂｐｓに削減できるので、たとえば６ｃｈでも約９Ｍｂｐｓであり、主要放送局６局分のＭＰＥＧ−ＴＳを同時にホームサーバとクライアント間で伝送することが可能となる。【００３３】
本願第４の発明は、上述の構成に類似しているが、入力系と出力系がそれぞれ２系統ある点が大きく異なる。すなわち、入力される系統の信号は立体画像を構成する。立体画像を伝送するために、２つの入力に、左眼用映像、右眼用映像を入力する。ここで、入力される左眼用映像、右眼用映像は、Ｈ．２６４エンコード時に左右の映像で映像フレーム同期または映像フィールド同期を取る。また、Ｈ．２６４ではＩＤＲピクチャで左眼用映像、右眼用映像より構成される２ｃｈ映像の同期を取ることにより、映像同期処理など信号処理が簡単にでき、装置の低コスト化も図れる。さらに、ＭＰＥＧ−２やＨ．２６４を用いた３Ｄ（立体）映像のエンコードにおいて、一般的に左眼用映像と右眼用映像は似ているので、左眼用映像は右眼用映像を参照してエンコードすれば、左眼用映像のビットレートを小さくできる。よって、この場合には、トータルとして、右眼用映像の約１．５倍のビットレートに抑えることができる。【００３４】
本願第５の発明は、第２の発明の構成において、外部入力がＨ．２６４エンコーダに接続されている。Ｈ．２６４処理において、一般的なメタデータ、デジタル放送を受信して、そのＳＩ（Ｓｅｒｖｉｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ）より得るメタデータ、ＥＰＧ提供事業者より得たＥＰＧ情報などのメタデータ、Ｉｎｔｅｒｎｅｔから得たＥＰＧなどのメタデータ、また、個人でムービー撮影したＡＶコンテンツ（クリップなど）に関連付けたメタデータなどをＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ  Ｅｎｈａｎｃｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ）に入力する。たとえば、ＳＥＩのＵｓｅｒ  Ｄａｔａ  Ｕｎｒｅｇｉｓｔｅｒｅｄ  ＳＥＩにメタデータが格納できる。これらメタデータを活用することにより、多くのＡＶコンテンツから所望のコンテンツを検索する、ライブラリに分類する、自動表示を行うなどコンテンツの効率的な利用が可能となる。【００３５】
また、デジタル放送で音楽番組を受信する場合、音楽番組をライブで別室に伝送する場合は、頭出しの必要はないが、デジタル放送で音楽番組を受信して、一旦、蓄積手段に蓄積して、後ほど、音楽番組を視聴する場合、番組中に放送された複数の楽曲の中より所望の楽曲に簡単にアクセスしたいというユーザ要求がある。ところが、デジタル放送で音楽番組を受信しても、番組タイトルと、一部の楽曲名はＳＩのＥＰＧ情報（たとえば、ＥＩＴ；Ｅｖｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）から取得できるが、各楽曲の放送時間などの情報があいために、蓄積手段より楽曲を再生する際に、簡単に所望の楽曲に簡単にアクセスできないという課題がある。【００３６】
そこで、本発明では解決手段として、Ｉｎｔｅｒｎｅｔ上の楽曲情報サーバにアクセスして、該音楽番組内の楽曲情報を取得する。そして、取得した該音楽番組内の楽曲情報と蓄積手段に記録されている該音楽番組内の複数の楽曲とを該音楽番組のタイムレンジ情報などで関連付けた楽曲位置テーブルを作成し、蓄積手段の楽曲位置テーブル格納用Ｄｉｒｅｃｔｏｒｙに記録する。ユーザはＵＰｎＰ−ＡＶのサービスでブラウズ、サーチなどを行うと、該音楽番組タイトルのファイル（または、ＵＰｎＰで定義された＜ｒｅｓ＞）に対して、該音楽番組中の各楽曲に対して楽曲位置テーブルを用いることにより、ＨＴＴＰのタイムレンジ指定などで瞬時に所望の楽曲にアクセスできる。また、ＨＴＴＰでの楽曲アクセスに関して、たとえば、「ＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）パラメータで楽曲名を指定により、サーバ側で楽曲名から放送番組内の該楽曲の放送時刻を指定するアプリケーションを組む」ことにより、便利な楽曲アクセス機能を実現することもできる。また、Ｉｎｔｅｒｎｅｔより該音楽番組内の楽曲情報が取得できない場合には、各楽曲の波形データ、たとえば、楽曲のサビなど、をＩｎｔｅｒｎｅｔ上の楽曲名解析サービスのサーバなどに問い合わせることにより、該音楽番組内の楽曲情報を取得することができる。【００３７】
本願第６の発明は、ＨＤムービーで撮影したＭＰＥＧ−ＴＳ形式のＨＤコンテンツとそのメタデータがホームサーバに蓄積しておく場合、効率的な編集を実現する。ＨＤ／低解像度変換手段は蓄積手段１に蓄積されたＨＤコンテンツを低解像度で低ビットレートのコンテンツに変換する。別室などのＰＣや携帯端末よりネットワークを介して、ホームサーバに蓄積されたコンテンツをリモート編集する場合、ＨＤコンテンツをＰＣや携帯端末に送るには、各機器の処理負荷およびネットワーク負荷が小さくするため、蓄積された低解像度コンテンツを受信側に送信する。また、受信側の処理としては、編集リスト（ＥＤＬ）を作成し、ＥＤＬを送信側に伝送する。送信側は、受信したＥＤＬに基づいて編集されたＨＤコンテンツを受信側に伝送する。この様に不必要な映像を削除することにより、受信側に伝送するデータ量を削減することができる。【００３８】
なお、本発明は、このようなパケット送信装置として実現できるだけでなく、パケット送信方法として実現したり、パケット送信装置のためのプログラムとして実現したり、そのプログラムを記録したコンピュータ読み取り可能なＣＤ−ＲＯＭやＤＶＤ−ＲＡＭなどの記録媒体としても実現できる。
【発明の効果】
【００３９】
本願第１の発明によれば、入力されたＡＶデータとそのメタデータを用いて、パケット送受信機器間での信号の互換性を確保しながら、パケット伝送を行なうことが可能となる。【００４０】
放送のＥＰＧ情報として、デジタル放送信号のＳＩ情報、ＥＰＧ専用チャンネルから抽出した情報、ＩｎｔｅｒｎｅｔのＥＰＧ情報などから取得した情報などより希望する情報を選択したり、個別情報を選択、結合し、ＥＰＧ情報を再構成することにより、従来よりも幅広く詳細なメタデータをもつことができるので、よいきめ細かい制御による番組選択、視聴が可能となる。すなわち、多くのＡＶコンテンツから所望のコンテンツを検索する、ライブラリに分類する、自動表示を行うなどコンテンツの効率的な利用が可能となる。【００４１】
本願第２の発明によれば、被伝送データブロックの先頭データまたは末尾データを、送信側で管理しているデータブロックの先頭データと一致させて伝送することにより、受信データから効率よくＭＰＥＧデコードを行うことができる。【００４２】
本願第３の発明によれば、ＭＰＥＧ−２／Ｈ．２６４トランスコーダを備えることにより、画質を保ちながらファイルサイズを約２分の１以下に削減できるため、より多くのファイルの蓄積が可能になるとともに、より狭い帯域でＨ．２６４ストリームを実時間伝送すること、あるいは、より高速にファイル転送することができる。【００４３】
本願第４の発明によれば、Ｈ．２６４ではＩＤＲピクチャで左眼用映像、右眼用映像より構成される２ｃｈ映像の同期を取ることにより、立体画像を効率よく伝送することができる。また、ＭＰＥＧ−２やＨ．２６４を用いた３Ｄ（立体）映像のエンコードにおいて、一般的に左眼用映像と右眼用映像は似ているので、左眼用映像は右眼用映像を参照してエンコードすれば、左眼用映像のビットレートを小さくできる。よって、この場合には、トータルとして、右眼用映像の約１．５倍のビットレートにおさえることができる。【００４４】
本願第５の発明によれば、外部入力であるＨ．２６４信号にメタデータを格納する方法を与える。また、デジタル放送で音楽番組を受信する場合、音楽番組をライブで別室に伝送する場合は、頭出しの必要はないが、デジタル放送で音楽番組を受信して、一旦、蓄積手段に蓄積して、後ほど、音楽番組を視聴する場合、番組中に放送された複数の楽曲の中より所望の楽曲に簡単なアクセスを実現する。【００４５】
本願第６の発明によれば、ＨＤムービーで撮影したＭＰＥＧ−ＴＳ形式のＨＤコンテンツとそのメタデータがホームサーバに蓄積しておく場合、効率的な編集を実現する。ＨＤ／低解像度変換手段は蓄積手段１に蓄積されたＨＤコンテンツを低解像度で低ビットレートのコンテンツに変換する。別室などのＰＣや携帯端末よりネットワークを介して、ホームサーバに蓄積されたコンテンツをリモート編集する場合、ＨＤコンテンツをＰＣや携帯端末に送るには、各機器の処理負荷およびネットワーク負荷が小さくするため、蓄積された低解像度コンテンツを受信側に送信する。また、受信側の処理としては、編集リスト（ＥＤＬ）を作成し、ＥＤＬを送信側に伝送する。送信側は、受信したＥＤＬに基づいて編集されたＨＤコンテンツを受信側に伝送する。この様に不必要な映像を削除することにより、受信側に伝送するデータ量を削減することができる。
【図面の簡単な説明】
【００４６】
【図１】図１は、従来のパケット送受信システムの構成図である。
【図２】図２は、従来のパケット送受信装置の構成図である。
【図３】図３は、従来、鍵交換にＤＴＣＰ方式を適用する場合のコンテンツ伝送手順の説明図である。
【図４】図４は、従来の１３９４パケットの説明図である。
【図５】図５は、本発明における送受信システムの概念図である。
【図６】図６は、本発明における鍵交換にＤＴＣＰ方式を適用する場合のコンテンツ伝送手順の説明図である。
【図７】図７は、イーサネット（登録商標）を用いる一般家庭に本発明を適用した場合の一例の説明図である。
【図８】図８は、本発明の実施の形態１におけるパケット送信部のブロック図である。
【図９】図９は、本発明の実施の形態１におけるパケット受信部のブロック図である。
【図１０】図１０は、本発明の実施の形態１におけるＭＰＥＧ−ＴＳのイーサネット（登録商標）フレーム構成仕様の例を示す図である。
【図１１】図１１は、本発明の実施の形態１における信号およびプロトコル処理をレイヤ別に説明した図である。
【図１２】図１２は、本発明の実施の形態１におけるパケット送受信部の説明図である。
【図１３】図１３は、図８を簡略的に表した図である。
【図１４】図１４は、本発明の実施の形態２におけるパケット送信部のブロック図である。
【図１５】図１５は、本発明の実施の形態３におけるパケット送信部のブロック図である。
【図１６】図１６は、本発明の実施の形態４におけるパケット送受信部のブロック図である。
【図１７】図１７は、本発明の実施の形態５におけるパケット送受信部のブロック図である。
【図１８】図１８は、本発明の実施の形態６におけるパケット送受信部のブロック図である。
【図１９】図１９は、本発明の実施の形態６におけるＨ．２６４処理部のより詳細な説明図である。
【図２０】図２０は、本発明で取り扱うメタデータの例を示す図である。
【図２１】図２１は、本発明の実施の形態７におけるパケット送受信部のブロック図である。
【図２２】図２２は、本発明の実施の形態７におけるアプリケーションの説明図である。
【符号の説明】
【００４７】
１０１    パケット送信機器
１０２    ルータ
１０３    パケット受信機器
４０１    パケット送信部
４０２    セキュアＩＰパケット送信処理部
４０３    デジタルチューナ
４０４    ＴＳインタフェース
４０５    スイッチャ
４０６    リモコンインタフェース
４０７    信号フォーマット・プロパティ検出部
４０８    ＴＳカプセル化部
４０９    ＴＳパケットフィルタリング及びデスクリプタ挿入部
４１０    ＴＳ−ＭＵＸ部
４１１    ＣＣＩ検出部
４１２    ＥＰＧ・録画データ処理部
４１３    管理制御部
４１４    認証と鍵交換（ＡＫＥ）部
４１５    データブロック化部
４１６    データブロックヘッダ生成部
４１７    暗号化部
４１８    データブロックパケット生成部
４１９    伝送プロトコル処理部
４２０    タイムスタンプ付加部
【発明を実施するための最良の形態】
【００４８】
以下、本発明の実施の形態について図面を用いて詳細に説明する。まず、本発明の位置付けを明確にするために適用する通信システム例の概略について説明する。【００４９】
図５は本発明を適用する通信システムの一例である。この通信システムは、パケットを送信するパケット送信機器１０１と、パケットのルーティングを行うルータ１０２と、パケットを受信するパケット受信機器１０３とから構成される。【００５０】
パケット送信機器１０１には、機器の管理運用を含む送受信条件の設定情報、認証と鍵交換の設定情報、入力ストリーム（ＭＰＥＧ−ＴＳ形式等のコンテンツ）が入力され、図６に示されるように、以下の手順１から３に基づき、ルータ１０２との間で通信を行う。ここで、伝送されるコンテンツの著作権保護は、認証と暗号化を用いたコピー保護に基づいて実現される。【００５１】
＜手順１＞送受信パラメータの設定を行なう。【００５２】
（手順１−１）パケット送受信機器のＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）アドレス、ＩＰアドレス、ＴＣＰ／ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）ポート番号等を設定。ＵＰｎＰなどの自動設定機能を使用することができる。【００５３】
（手順１−２）送信信号の種別、帯域を設定。ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）エージェントとして動作するパケット送信機器１０１とパケット受信機器１０３、ＱｏＳマネージャとして動作するルータ１０２との間でＩＥＥＥ８０２．１Ｑ（ＶＬＡＮ；Ｖｉｒｔｕａｌ  ＬＡＮ）規格を用いたネットワークの運用に関する設定を実施。【００５４】
（手順１−３）優先度の設定（ＩＥＥＥ８０２．１Ｑ／ｐによる運用）【００５５】
＜手順２＞認証と鍵交換：
（手順２−１）認証と鍵交換を行なう。たとえば、ＤＴＣＰ方式を用いることもできる。【００５６】
＜手順３＞ストリーム伝送：
（手順３−１）パケット送信機器とパケット受信機器間での暗号化されたストリームコンテンツ（パーシャルＭＰＥＧ−ＴＳ）を伝送する。【００５７】
なお、上記例ではＭＰＥＧ−ＴＳを使用しているが、これに限らず本発明で用いる入力コンテンツの適用範囲としては、ＭＰＥＧ１／２／４などＭＰＥＧ−ＴＳストリーム（ＩＳＯ／ＩＥＣ１３８１８）、ＭＰＥＧ−ＰＳ（Ｐｒｏｇｒａｍ  Ｓｔｒｅａｍ）、ＭＰＥＧ−ＥＳ（Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ）、ＭＰＥＧ−ＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ  Ｅｌｅｍｅｎｔａｒｔｙ  Ｓｔｒｅａｍ）、ＤＶ（ＩＥＣ６１８３４、ＩＥＣ６１８８３）、ＳＭＰＴＥ（Ｓｏｃｉｅｔｙ  ｏｆ  Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  ＆  Ｔｅｌｅｖｉｓｉｏｎ  Ｅｎｇｉｎｅｅｒｓ）  ３１４Ｍ（ＤＶ−ｂａｓｅｄ）、ＳＭＰＴＥ２５９Ｍ（ＳＤＩ）、ＳＭＰＴＥ３０５Ｍ（ＳＤＴＩ）、ＳＭＰＴＥ２９２Ｍ（ＨＤ−ＳＤＩ）、ＩＳＯ／ＩＥＣ  Ｈ．２６４等で規格化されているストリ−ム、さらには、一般的なＡＶコンテンツも適用可能である。【００５８】
さらに、本発明で用いる入力データはファイル転送にも適用できる。ファイル転送の場合、送受信装置の処理能力と、送受信装置間の伝播遅延時間の関係により、データ転送速度がコンテンツストリームの通常再生データレートよりも大きくなる条件下では、リアルタイムより高速のコンテンツ伝送も可能となる。【００５９】
次に、上記手順２の認証と鍵交換に関して補足説明する。図５において、パケット送信機器１０１とパケット受信機器１０３間はＩＰネットワークにより接続されている。まず、パケット送信機器１０１からパケット受信機器１０３へコンテンツに関する信号フォーマット、プロパティ情報、コピーや出力に対する保護・制御モード情報等が送信される。【００６０】
パケット受信機器１０３は、コンテンツに関する信号フォーマット、プロパティ情報、保護・制御モード情報等の解析を行い、使用する認証方式を決定して認証要求をパケット送信機器１０１に送る。これらの処理を通して、パケット送信機器１０１とパケット受信機器１０３は認証鍵を共有する。【００６１】
次に、パケット送信機器１０１は認証鍵を用いて交換鍵を暗号化してパケット受信機器１０３に送り、パケット受信機器１０３で交換鍵が復号される。【００６２】
パケット送信機器１０１では暗号鍵を、たとえば、一定のデータ量毎（一定の時間ごと、またはコマンドや信号検出により）に変化させて一定のデータ量毎に変化する鍵変更情報を生成し、パケット受信機器１０３に送信する。【００６３】
パケット送信機器１０１では、交換鍵と鍵変更情報より暗号化鍵を生成して、ＭＰＥＧ−ＴＳをこの暗号化鍵を用いて暗号化部で暗号化してパケット受信機器１０３に送信する。【００６４】
パケット受信機器１０３は受信した鍵変更情報を交換鍵より復号鍵を復元する。パケット受信機器１０３ではこの復号鍵を用いて暗号化されたＭＰＥＧ−ＴＳ信号を復号する。【００６５】
このようにして、パケット送信機器１０１及びパケット受信機器１０３の間で、コピー制御に基づいてコンテンツの著作権を保護しつつ、そのコンテンツの伝送が行われる。【００６６】
図７は、本方式をイーサネット（登録商標）によるＬＡＮを備える２階建ての家庭に適用した場合の一例である。この家庭は、１階に設置されたルータ３０３を含むネットワークシステム３０１と、２階に設置されたスイッチングハブ３０４を含むネットワークシステム３０２を備える。ネットワーク３０５は、ルータ３０３とスイッチングハブ３０４を接続するイーサネット（登録商標）ネットワークである。ここで、ネットワークシステムとしてＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）のサブネットマスク（Ｓｕｂｎｅｔ  Ｍａｓｋ）によって設定されるサブネット（Ｓｕｂｎｅｔ）がある。家庭内の全てのイーサネット（登録商標）ネットワークの帯域は１００Ｍｂｐｓである。【００６７】
また、ルータ３０３は、１階のネットワークと２階のネットワークを同じサブネットとして結合させ動作させるために、家庭内ネットワークに対してはスイッチングハブとして働かせる。ただし、ルータ３０３が家庭外とは、異なるサブネットとして構成する。このように家庭内で１つのサブネットを構成することにより、上述の暗号化したＩＰパケットのＴＴＬを１に制限することにより、上述の暗号化通信をサブネット内、すなわち、家庭内に制限することが可能となる。【００６８】
１階のネットワークシステム３０１の構成として、ルータ３０３には、テレビ（ＴＶ）、カメラ、ＤＶＤレコーダが１００Ｍｂｐｓのイーサネット（登録商標）で接続され、また、エアコン、冷蔵庫がＥＣＨＯＮＥＴで接続されている。【００６９】
また、２階では、スイッチングハブ３０４にテレビ（ＴＶ）、パソコン（ＰＣ）、ムービーが１００Ｍｂｐｓのイーサネット（登録商標）で接続され、また、エアコンがＥＣＨＯＮＥＴで接続されている。なお、ＥＣＨＯＮＥＴは「エコーネットコンソーシアム」（ＨＹＰＥＲＬＩＮＫ  “ｈｔｔｐ：／／ｗｗｗ．ｅｃｈｏｎｅｔ．ｇｒ．ｊｐ／”  ｈｔｔｐ：／／ｗｗｗ．ｅｃｈｏｎｅｔ．ｇｒ．ｊｐ／）で開発されている伝送方式である。【００７０】
なお、この家庭において、例えば、デジタル著作権保護の対象となるコンテンツを放送で受信し、家庭内の各機器（エアコン、ＤＶＤ、ＰＣ、冷蔵庫）にＩＰパケットで配信するＴＶが本発明のパケット送信機器１０１に相当し、各機器がパケット受信機器１０３に相当する。【００７１】
図７において、パソコン（ＰＣ）、ＤＶＤレコーダ、ルータ３０３およびスイッチングハブ３０４は、ＩＥＥＥ８０２．１Ｑ（ＶＬＡＮ）に対応している。すなわち、ルータ３０３およびスイッチングハブ３０４において、各ポートのデータレートが全て同じ（例えば１００Ｍｂｐｓ）場合、特定ポートへ出力されるデータ帯域の合計がそのポートの伝送レートの規格値または実力値を超えない限り、入力ポートへ入力されたデータはルータ（あるいは、スイッチングハブ）内部で失われず全て出力ポートに出力される。【００７２】
スイッチングハブでは、たとえば８個の入力ポートにデータが同時に入力されても、それぞれのデータの出力ポートが異なっていれば、それぞれのデータはハブ内部のバッファで競合しないでスイッチングされて出力ポートより出力されるため、入力データはパケット落ちすることなく全て出力ポートに出力される。【００７３】
図７において、家庭内の全てのイーサネット（登録商標）の帯域が１００Ｍｂｐｓであるため、１階と２階間のネットワーク３０５の帯域も１００Ｍｂｐｓである。１階と２階の複数の機器間で複数のデータが流れる場合、各データに対する帯域制限がない場合、このネットワーク３０５上を流れるデータのデータレート合計が１００Ｍｂｐｓを超える可能性があり、パーシャルＭＰＥＧ−ＴＳの映像アプリなどリアルタイム伝送が必要なストリームが途切れる可能性がある。この場合、リアルタイム伝送が必要なストリームが途切れない様にするには、１階と２階間のネットワーク３０５の帯域を１Ｇｂｐｓに拡大する、または、伝送データに対して優先制御が必要である。このような優先制御については、端末だけでなく、ルータやスイッチングハブにおいて、後述するストリーム伝送やファイル転送の速度制限機構などを導入することにより解決できる。【００７４】
たとえば、パーシャルＭＰＥＧ−ＴＳストリームの伝送優先度をファイル転送データの伝送優先度よりも高くすると、１階と２階のＰＣ間でのファイル転送をバックグラウンドで行いながら、同時に、１階および２階のＤＶＤレコーダ、ＰＣ，ＴＶの間でＭＰＥＧ−ＴＳを暗号化して、ＨＴＴＰプロトコルやＲＴＰプロトコルなどを利用してリアルタイムで伝送することが可能となる。【００７５】
なお、パーシャルＭＰＥＧ−ＴＳはＭＰＥＧ−ＴＳストリームの一種であり、たとえば、ＡＲＩＢ規格、ＳＴＤ−Ｂ２１に記述されている。また、ＨＴＴＰプロトコル（ＩＥＴＦ規格、ＲＦＣ２６１６、ＲＦＣ１９４５）の概要、構成、動作に関しては、たとえば、「連載：インターネット・プロトコル詳説（１）、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）〜前編」、ＷＥＢ資料、で解説されている。【００７６】
前述したルータ３０３、またはスイッチングハブ３０４における伝送速度制限機構は、データ流入制御により実現できる。すなわち、ルータ（あるいは、スイッチングハブ）の入力データキューにおいて優先度の高いデータと低いデータを比較して、優先度の高いデータを優先して出力することにより実現できる。この優先制御方式に用いるバッファ制御ルールとしては、ラウンドロビン方式、流体フェアスケジューリング方式、重み付けフェアスケジューリング方式自己同期フェアスケジューリング方式ＷＦＦＱ方式、仮想時計スケジューリング方式、クラス別スケジューリング方式などがある。これらのスケジューリング方式に関する情報は、戸田巌著、「ネットワークＱｏＳ技術」、平成１３年５月２５日（第１版）、オーム社刊の第１２章などに記述されている。【００７７】
地上波デジタル放送、ＢＳデジタル衛星放送、１１０度ＣＳデジタル衛星放送、ＣＡＴＶやインターネット経由等で受信するデジタル放送信号より検出、抽出できるＡＶコンテンツの属性情報を送信端末と受信端末間でＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ）−ＡＶやＨＴＴＰなどのデータ交換プロトコルを用いて伝送することにより、送信端末と受信端末間でのＡＶコンテンツを送信する場合の暗号化モード、コンテンツ属性情報（プロパティ）の伝送方法を決めることができる。さらに、暗号化情報ヘッダの付加ルールを決められるため、パケット送受信機器間でのＡＶストリームの秘匿性を保ちながら信号の互換性を確保することが可能となる。ＵＰｎＰやＵＰｎＰ−ＡＶの標準仕様は、ｈｔｔｐ：／／ｕｐｎｐ．ｏｒｇで公開されている。ｈｔｔｐ：／／ｕｐｎｐ．ｏｒｇにおいて、例えば、「ＭｅｄｉａＳｅｒｖｅｒ  Ｖ  １．０  ａｎｄ  ＭｅｄｉａＲｅｎｄｅｒｅｒ  Ｖ  １．０」に関して、「ＭｅｄｉａＳｅｒｖｅｒ  Ｖ  １．０」、「ＭｅｄｉａＲｅｎｄｅｒｅｒ  Ｖ  １．０」、「ＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ  Ｖ  １．０」、「ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙ  Ｖ  １．０」、「ＲｅｎｄｅｒｉｎｇＣｏｎｔｒｏｌ  Ｖ  １．０」、「ＡＶＴｒａｎｓｐｏｒｔ  Ｖ  １．０」、「ＵＰｎＰＴＭ  ＡＶ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｖ  ．８３」などの仕様書が公開されている。【００７８】
また、ネットワークを用いたＡＶコンテンツの伝送に関して、ネットワーク上でのデータ盗聴を防止し、安全性の高いデータ伝送を実現する。これにより、伝送路にインターネットなど公衆網を使用した場合においても、リアルタイム伝送される優先データ（ＡＶデータコンテンツ）の盗聴、漏洩を防止することができる。また、インターネット等で伝送されるＡＶデータの販売、課金が可能となり、より高い安全性が要求されるＢ−Ｂ（Ｂ  ｔｏ  Ｂ）、Ｂ−Ｃ（Ｂ  ｔｏ  Ｃ）におけるコンテンツ販売流通が可能となる。【００７９】
さらに、送信データよりＡＶコンテンツを分離してハードウェアで伝送プロトコル処理の一部をアクセラレートする場合にも、ＡＶコンテンツでない一般のデータパケットは従来通りプロセッサを用いてソフトウェア処理を行える。よって、ソフトウェアの追加により管理情報や制御情報などデータを一般データとして伝送させることができる。一般に、これらＡＶコンテンツでない一般データの量は優先データであるＡＶデータに比べて非常に少ないので、マイコンなど安価なマイクロプロセッサで処理することが可能となるので、低コストでのシステム実現ができる。なお、高負荷かつ高伝送レート優先パケットのプロトコル処理にも高価なＣＰＵや大規模メモリを必要としないので、これらの点からも低コストで高機能な装置を提供できる。【００８０】
また、サーバ型放送のＲＭＰで用いる課金情報などを含むＲＭＰＩ（Ｒｉｇｈｔｓ  Ｍａｎａｇｅｍｅｎｔ  ＆  Ｐｒｏｔｅｃｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ）で視聴あるいはコピー制限されたコンテンツをＲＭＰに対応していないクライアントにＣＮＭ（Ｃｏｐｙ  Ｎｏ  Ｍｏｒｅ）やＣＮ（Ｃｏｐｙ  Ｎｅｖｅｒ）で見せることができ、サーバ型放送の普及を加速することができる。この場合、制御情報に基づいて、ＡＶデータの再生制御、出力制御又はコピー制御を行うための課金情報、コピー制御情報、有効期限情報、有効再生回数情報など取り扱い、生成した情報を認証情報として認証部に通知する著作権管理部を用い、著作権管理部から通知された認証情報に基づいて、前記パケット受信装置との間で認証処理を行うことで、ＡＶデータの前記パケット受信装置における再生制御、出力制御又はコピー制御を行う。さらに、パケット伝送装置は、著作権管理部による制御の下で、課金情報、再生制御情報又はコピー制御情報に基づいて、パケット受信装置との間で、著作権保護の対象となるコンテンツの購入決済を行うコンテンツ購入決済部を備える。【００８１】
（実施の形態１）
まず、本発明の実施の形態１について説明する。図８は、本実施の形態におけるパケット送信部４０１の構成を示すブロック図である。このパケット送信部４０１は、ＡＫＥに基づいて設定される暗号化によるパケット送受信を行う装置であり、セキュアＩＰパケット送信処理部４０２をコアとして内蔵している。パケット送信部４０１は、デジタルチューナ４０３、ＴＳインタフェース４０４、スイッチャ４０５、リモコンインタフェース４０６、信号フォーマット及びプロパティ検出部４０７、ＴＳカプセル化部４０８、ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９、ＴＳ−ＭＵＸ部４１０、ＣＣＩ検出部４１１、ＥＰＧ・録画データ処理部４１２、管理制御部４１３、認証と鍵交換（ＡＫＥ）部４１４、データブロック化部４１５、データブロックヘッダ生成部４１６、暗号化部４１７、データブロクパケット生成部４１８、伝送プロトコル処理部４１９、タイムスタンプ付加部４２０を備える。【００８２】
なお、ここでＥＰＧ・録画データ処理部４１２がプログラム情報取得手段及びプログラム情報再構成手段の一例であり、ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９がフィルタリング手段の一例であり、データブロック化部４１５、データブロックヘッダ生成部４１６、データブロクパケット生成部４１８、及び伝送プロトコル処理部４１９の総体が送信手段の一例である。【００８３】
また、データブロック化部４１５、データブロックヘッダ生成部４１６、データブロックパケット生成部４１８は、個別に見るとそれぞれ、データブロック化手段、伝送パケットヘッダ生成手段、及び伝送パケット生成手段の一例である。【００８４】
また、ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９はデスクリプタ挿入手段の一例であり、ＴＳ−ＭＵＸ部４１０はパーシャルトランスポート生成手段の一例である。【００８５】
以下、伝送手順に従って、各構成要素の機能を説明する。【００８６】
管理制御部４１３には、管理用データと制御用データとしてのＡＶデータとメタデータが入力される。たとえば、管理制御部４１３には、ＡＶデータ（送信コンテンツ）の入力端子情報、ＡＶデータのデータフォーマット情報、及び、ＡＶデータのプロパティ（属性）を示す属性情報を含むＡＶデータ情報が入力される。これらの情報は、具体的には、たとえば、送信データの種別、送信先アドレスやポート番号の情報、送信に用いるパス情報（ルーティング情報）、送信データの帯域、送信データの送信優先度などの送信条件の設定情報と、送信部（ローカル）と受信部（リモート）における機器の管理制御データと、受信状況を送信側にフィードバックするためのデータを表す。管理制御部４１３は、入力された情報を用いて、データブロック化部４１５やプロトコル処理部４１９におけるヘッダやペイロードデータなどの生成（パラメータの設定等を）を制御する。【００８７】
なお、パケット送信部４０１では省略してあるが、送信信号の入力端子情報とは、取り扱う信号がＭＰＥＧ−ＴＳ信号の場合に、（１）デジタル放送の入力端子（日本の場合、地上デジタル放送、ＢＳデジタル放送、１１０度広帯域ＣＳデジタル放送に対応するＲＦ入力端子）、（２）ＩＥＥＥ１３９４  Ｄ−Ｉ／Ｆ、（３）ＵＳＢ−Ｉ／Ｆ、（４）ＩＰ−Ｉ／Ｆ（Ｅｔｈｅｒｎｅｔ（登録商標）や無線ＬＡＮの区別）、（５）アナログ映像音声入力（この場合は、パケット送受信部４０１内で入力されたアナログ映像音声をＭＰＥＧ−ＴＳ信号に変換する）などがある。なお、デジタル放送に関しては、たとえば、映像情報メディア学会誌、Ｖｏｌ．５８、ｎｏ．５、ｐｐ．６０４〜ｐｐ．６５４において解説記事がある。【００８８】
また、パケット送信部４０１におけるＡＶ信号のフォーマットを示すデータフォーマット情報とは、取り扱う信号がパーシャルＭＰＥＧ−ＴＳの場合、そのＭＩＭＥ−Ｔｙｐｅやメディアフォーマットを表わす。たとえば、送信部（サーバ）や受信部（クライアント）は、各々が取り扱う静止画メディア、音楽メディア、動画メディアに対して、それぞれのメディアフォーマットを定める。たとえば、動画（映像）のメディアフォーマットとしては、ＭＰＥＧ２、ＭＰＥＧ１、ＭＰＥＧ４、ＷＭＶなどがある。また、静止画のメディアフォーマットとしては、ＪＰＥＧ、ＰＮＧ、ＧＩＦ、ＴＩＦＦなどがある。さらに、音楽のメディアフォーマットとしては、リニアＰＣＭ、ＡＡＣ、ＡＣ３、ＡＴＲＡＣ３ｐｌｕｓ、ＭＰ３、ＷＭＡなどがある。これらは、たとえば、ＤＬＮＡ（Ｄｉｇｉｔａｌ  Ｌｉｖｉｎｇ  Ｎｅｔｗｏｒｋ  Ａｌｌｉａｎｃｅ；  ホームページはｗｗｗ．ｄｌｎａ．ｏｒｇ）でも同様に規定されている。ＤＬＮＡ  Ｇｕｉｄｅｌｉｎｅのｖｅｒｓｉｏｎ１．０では、サーバ（コンテンツの送信側、ＤＴＣＰではソース）をＤＭＰ（Ｄｉｇｉｔａｌ  Ｍｅｄｉａ  Ｓｅｒｖｅｒ）、クライアント（コンテンツの受信側、ＤＴＣＰではシンク）をＤＭＰ（Ｄｉｇｉｔａｌ  Ｍｅｄｉａ  Ｐｌａｙｅｒ）と呼んでいる。ＤＭＳはＵＰｎＰ−ＡＶのＭｅｄｉａＳｅｒｖｅｒ（ＭＳ）とＣｏｎｔｒｏｌＰｏｉｎｔ（ＣＰ）により構成され、ＤＭＰはＵＰｎＰ−ＡＶのＭｅｄｉａＲｅｎｄｅｒｅｒ（ＭＲ）とＣｏｎｔｒｏｌＰｏｉｎｔ（ＣＰ）により構成される。ＵＰｎＰ−ＡＶのＭＳ，ＭＲ、ＣＰについては、ＵＰｎＰのホームページ、ｗｗｗ／ｕｐｎｐ．ｏｒｇに記載されている。【００８９】
映像メディアフォーマットの場合には、（１）解像度の区別（ＳＤ、ＨＤ）、（２）ＴＶ方式の区別（アナログではＮＴＳＣ、ＰＡＬ，ＳＥＣＡＭ，デジタルでは米国ＡＴＳＣ、欧州ＤＶＢ、日本のＩＳＤＢなどＡＲＩＢ規格に基づく放送方式）、（３）タイムスタンプ形式などの付加情報の有無、などを追加パラメータとして持つ。なお、たとえば映像の場合、ＭＰＥＧ−ＰＳでもＭＰＥＧ−ＴＳに対してもＭＩＭＥ−Ｔｙｐｅは“ｍｐｅｇ／ｖｉｄｅｏ”であるので、上記の付加情報を用いることにより、よりきめ細かい映像メディアの取り扱い、制御が可能となる。【００９０】
なお、デジタル放送に関するＡＲＩＢ規格の概要は、たとえば、松下テクニカルジャーナル２００４年２月、Ｖｏｌ．５０、Ｎｏ．１、７ページから１２ページで解説されている。【００９１】
また、パケット送受信部４０１におけるＡＶデータの属性を示す属性情報とは、例えば取り扱うＡＶ信号が日本の地上デジタル放送システムで放送局より放送され、家庭等の受信機で選局されたＭＰＥＧ−ＴＳ信号（正確には、ＡＲＩＢ標準規格、ＡＲＩＢ  ＳＴＤ  Ｂ２１、第９章において、シリアルインタフェースの入出力トランスポートストリームとして規定されているパーシャルトランスポート信号（パーシャルＴＳ信号））の場合、その属性情報としては、放送局よりＰＳＩ／ＳＩ情報として送信される、チャンネル名（放送局名）、チャンネル番号、番組名、番組のジャンル、スケジュールされた放送開始時間、スケジュールされた放送終了時間、番組内容に関する情報、番組の解像度、パレンタルなどの視聴制限情報、コピー制御情報、視聴料金などがある。ＰＳＩやＳＩに関しては、ＡＲＩＢ技術資料、ＡＲＩＢ  ＴＲ−Ｂ１４やＡＲＩＢ  ＴＲ−Ｂ１５にて規定されている。【００９２】
図８において、デジタル放送対応のアンテナから受信ＲＦ信号がデジタルチューナ４０３に入力され、チャンネル選局されてフルＴＳがスイッチャ４０５に入力される。一方、ＴＳインタフェース４０４には、たとえば、ＨＤＴＶ（１０８０ｉ、７２０ｐなど）とＳＤＴＶ（５２５ｉ）の録画モードで録画できるデジタル方式ムービーより、ＨＤＴＶ（１０８０ｉ、７２０ｐなど）とＳＤＴＶ（５２５ｉ）のＭＰＥＧ−ＴＳ信号や、該ＭＰＥＧ−ＴＳ信号に関する録画情報（Ｍｅｔａｄａｔａ）がＭＰＥＧ−ＴＳ形式で入力される。スイッチャ４０５は、デジタルチューナ４０３入力とＴＳインタフェース４０４の出力を選択して出力する。このスイッチャ４０５の出力選択は、たとえば、リモコンよりリモコンインタフェース部４０６、内部にメモリとマイコンを持った管理制御部４１３により実行できる。なお、図８においては、図が複雑にならないように、管理制御部４１３とスイッチャ４０５の間の信号線は省略している。同様に、本発明の図面においては、図を簡単にするため省略しているが、管理制御部４１３は、全てのモジュールと信号線で接続されていて、各モジュール動作の管理や制御が可能である。【００９３】
スイッチャ４０５で選択されたＭＰＥＧ−ＴＳは、信号フォーマット及びプロパティ検出部４０７、および、ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９に入力される。【００９４】
信号フォーマット及びプロパティ検出部４０７に入力されたＴＳ信号は、ＥＰＧ・録画データ処理部４１２に入力され、放送のＥＰＧ情報やムービー録画に関するメタデータなどが抽出され、管理制御部４１３に渡される。ここで、放送のＥＰＧ情報は、たとえば、次の３つがある。【００９５】
（１）  デジタル放送信号に含まれるＳＩ情報から抽出したＥＰＧ情報【００９６】
（２）  ＥＰＧ専用チャンネルから抽出したＥＰＧ情報。たとえば、Ｇｅｍｓｔａｒ社やナノメディア社のＴＶ番組の提供するＥＰＧ情報。【００９７】
（３）  Ｉｎｔｅｒｎｅｔから取得したＥＰＧ情報。例えば、テレビガイドサイトから取得されるＥＰＧ情報。より広義には、テレビブログサイトから取得される、放送番組に関するメタデータをこのＥＰＧ情報に含めてもよい。【００９８】
ここで、ＩｎｔｅｒｎｅｔからのＥＰＧ情報は、プロトコル処理部４１９及び管理制御部４１３を介して取得される。【００９９】
なお、ＥＰＧ情報としては、放送システムの種別、放送ネットワーク識別、放送の編成チャンネル情報、番組名、番組のジャンル、チャンネル番号、番組の開始時間、番組の終了時間、番組の説明記述（簡易記述版、詳細記述版）などがある。【０１００】
ＥＰＧ・録画データ処理部４１２では、上記の複数のＥＰＧ情報より、希望するＥＰＧ情報を選択するだけでなく、個別のＥＰＧ情報を選択、結合し、ＥＰＧ情報を再構成することもできる。【０１０１】
さらに上記情報の結合、再構成の際に、その情報源のアトリビュートを持ち、継承させることも可能である。たとえば、ＵＰｎＰ−ＡＶの仕組みを使用すれば、上記３つの情報源のアトリビュートを、それぞれ、＠ＳＩ、＠ＥＰＧ専用ｃｈ１、＠Ｉｎｔｅｒｎｅｔ＿情報源１、などと標記することにより情報源を継承させることができる。【０１０２】
従来は、放送波に含まれるＳＩ情報のみからＥＰＧ情報を構成していたが、本発明の特徴は、ＥＰＧ情報を複数の情報源から取得してそれらから新たなＥＰＧ情報を再構成できる点にもある。【０１０３】
例えば、放送時刻情報を含むＥＰＧ情報を放送波から取得すると共に、より詳しい番組説明記述を含むＥＰＧ情報をインターネットから取得し、その放送時刻情報と番組説明記述とを新たなＥＰＧ情報に再構成してもよい。そうすれば、番組の延長や変更が反映されている可能性が高い新鮮な放送時刻情報と充実した番組説明記述とを含む好ましいＥＰＧ情報が得られる。【０１０４】
また、再構成に用いるＥＰＧ情報を、再構成された新たなＥＰＧ情報の送信先として予定される受信装置の属性に応じて選択してもよい。【０１０５】
例えば、受信装置が携帯情報端末装置である場合には、表示画面があまり大きくないことを考慮して、放送波からのＥＰＧ情報に含まれる番組説明記述を用いてもよい。また、例えば、受信装置がパソコンである場合には、そのパソコンのユーザのお気に入りのテレビブログサイトにアクセスして得られる広義のＥＰＧ情報を新たなＥＰＧ情報に再構成してもよい。アクセスすべきテレビブログサイトのアドレスは、受信装置たるパソコンから予め取得しておくことができる。【０１０６】
ユーザは、このようにして再構成された新たなＥＰＧ情報を参照して番組選択に役立てることができる。【０１０７】
そのＥＰＧ情報を、例えば、図示しないテレビ受像機に表示し、それを見たユーザによって行われる番組選択操作をリモコンインタフェース４０６を介して受け付けることも可能であるし、ＵＰｎＰ−ＡＶやＤＬＮＡガイドラインで規定された番組情報などのメタデータの遠隔表示・制御に関する規格、仕様に則してホームネットワークを介して別室のテレビ受像機に伝送して表示し、別室でそれを見たユーザによって行われる番組選択操作をホームネットワークを介して受け付けることも可能である。また、ムービー録画の表示の場合には、録画ファイルの一覧をＥＰＧ情報のように、録画データ（メタデータ）とともにリスト形式で表示できる。【０１０８】
ＴＳカプセル化部４０８は、信号フォーマット及びプロパティ検出部４０７に入力されたＴＳ信号から、上述のようにして選択された番組のＰＩＤを持つＴＳパケットに関してＳＩＴ（Ｓｅｌｅｃｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）などを再構成し、ＴＳ−ＭＵＸ部４１０へ出力する。【０１０９】
ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９に入力されたＴＳ信号は、上述のようにして選択された番組のＰＩＤをもつＴＳパケットに関して、ＤＴＣＰオーディオデスクリプタの生成を行い、これらのデスクリプタをＰＭＴ（Ｐｒｏｇｒａｍ  Ｍａｐ  Ｔａｂｌｅ）に挿入し、その後、ＴＳパケットのＰＩＤを見て選択された番組を表すＴＳパケットのみを抽出するフィルタリングを行い、抽出されたＴＳパケットをＴＳ−ＭＵＸ部４１０に出力する。【０１１０】
ＴＳ−ＭＵＸ部４１０では、ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９およびＴＳカプセル化部４０８の出力であるＴＳパケットの多重化（ＴＳ−ＭＵＸ）を行いデータブロック化部４１５へ出力する。ここで、ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９およびＴＳカプセル化部４０８の出力が重なった場合には、後段でのタイムスタンプ付加の正確さを考慮してＴＳパケットフィルタリング及びデスクリプタ挿入部４０９の出力を優先して、ＴＳカプセル化部４０８の出力は遅延させる。【０１１１】
タイムスタンプ付加部４２０では、各ＴＳパケットに対して、２７ＭＨｚクロックで３２ｂｉｔのタイムスタンプを付加する。なお、ムービー出力の場合は、ムービーから出力する際に、タイムスタンプを付加しておく構成をとることもできる。この場合、スイッチャではタイムスタンプ付きＴＳを扱い、ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９にはタイムスタンプ付きＴＳを出力し、信号フォーマット及びプロパティ検出部４０７にはタイムスタンプを除去したＴＳパケットを提供してもよい。そして、タイムスタンプ付加部４２０でタイムスタンプのないパケット（ＴＳカプセル化部の出力）にのみタイムスタンプを付加する。【０１１２】
データブロック化部４１５では、ＣＣＩ検出部４１１を用いて、該データブロック内にＣＣＩが存在するかどうかを検出する。ここで、伝送するＴＳのコンテンツのＣＣＩ（ＰＭＴの第１ループまたは第２ループに設定したコピー制御情報）がＣＮＭ（Ｃｏｐｙ  Ｎｏ  Ｍｏｒｅ）、ＣＯＧ（Ｃｏｐｙ  Ｏｎｅ  Ｇｅｎｅｒａｔｉｏｎ）、ＣＮ（Ｃｏｐｙ  Ｎｅｖｅｒ）の場合、該データブロック内にＣＣＩが存在しなければ、暗号化ブロックにエンベデドＣＣＩが存在しないため、ＤＴＣＰ（ＤＴＣＰ−ＩＰ）などによるＩＰプロトコルによる出力は禁止する。【０１１３】
さて、ＡＫＥ部４１４は、内部に認証部暗号化鍵交換部を具備する。信号フォーマット及びプロパティ検出部４０７で検出したＴＳ信号のＣＣＩを認証とＡＫＥ部４１４に送る。ここで、ＣＣＩがＣＦ（Ｃｏｐｙ  Ｆｒｅｅ）以外の場合、すなわち、ＣＮＭ（Ｃｏｐｙ  Ｎｏ  Ｍｏｒｅ）、ＣＯＧ（Ｃｏｐｙ  Ｏｎｅ  Ｇｅｎｅｒａｔｉｏｎ）、ＣＮ（Ｃｏｐｙ  Ｎｅｖｅｒ）の場合、認証と鍵交換（ＡＫＥ）を行う。このＡＫＥ部４１４は、認証と鍵交換に関する設定情報（ＡＫＥ設定情報）を取得し、このＡＫＥ設定情報に関連した情報、たとえば、コピー保護情報と暗号化鍵変更情報をデータブロック化部４１５やデータブロックヘッダ生成部４１６、暗号化部４１７に出力する。【０１１４】
ＡＫＥ部４１４は、パケット送信装置とパケット受信装置が、認証局などにより正当な機器であることを保証されるなど規定の条件を備えていることを検証することによって認証処理を実行し、認証処理後にパケット送信装置とパケット受信装置とで暗号化鍵を共有し、入力端子情報と、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報より生成する伝送条件とにより、暗号化鍵を更新し、暗号化データ生成部は、暗号化鍵を用いてＡＶデータを暗号化する。【０１１５】
データブロック化部４１５は、管理制御部４１３から与えられる送信パラメータに従って、ＴＳ−ＭＵＸ部４１０から入力されるタイムスタンプ付きパーシャルＭＰＥＧ−ＴＳを特定長のデータブロックにブロック化する。このデータブロック長はデータブロックヘッダ生成部４１６に入力される。【０１１６】
データブロックヘッダ生成部４１６は、その特定長を表すサイズ情報を含むと共に、前記検出されたデータフォーマット情報又は属性情報が前記コンテンツデータの伝送、複製、又は再生に関する制御情報である場合にはその制御情報を含むデータブロックヘッダを生成する。【０１１７】
データブロック化部４１５でブロック化されたブロックデータは、暗号化部４１７に入力される。暗号化部４１７はＡＫＥ部４１４から与えられる暗号化鍵を用いてＡＥＳ（Advanced Encryption Standard）暗号化を行う。なお、暗号化方式はＡＥＳ以外のＤＥＳ（Data Encryption Standard）など一般的な暗号化方式も用いることができる。暗号化部４１７において暗号化されたデータブロックは、データブロックパケット生成部４１８に入力される。データブロックパケット生成部４１８は、データブロックヘッダ生成部４１６で生成された該データブロックに付加されるべきデータブロックヘッダと入力されたデータブロックとを結合し、伝送パケットとする。【０１１８】
この伝送パケットは、プロトコル処理部４１９に入力され、ＨＴＴＰ，ＴＣＰ，ＩＰなどのプロトコル処理をされて、Ｅｔｈｅｒｎｅｔ（登録商標）−ＭＡＣ層に渡され、イーサネット（登録商標）フレームとなり、家庭内のネットワーク上で伝送し、別室のテレビ受像機などにＴＳを用いてコンテンツを伝送する。【０１１９】
なお、ＡＫＥ部４１４は、パケット送信装置とパケット受信装置との間で、認証実行モードと認証不実行モードとを持ち、暗号化データ生成部は、ＡＫＥ部４１４における認証実行モード及び認証不実行モードのいずれであっても、データブロックヘッダの付加制御を行う。すなわち、暗号化部４１７は、コピー制御情報（ＣＣＩ）がコピー制御を行うことを意味する場合に、ＣＣＩから生成した暗号化モード情報をデータブロックヘッダに含め付加する。また、コピー制御情報がコピー制御をしない意味の場合には、データブロックヘッダを付加しないように制御することもできる。【０１２０】
さらに、この場合、ＡＫＥ部４１４は、入力端子情報と、ＥＰＧ情報に含まれるデータフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報より生成する認証条件とにより、パケット受信装置との間で認証を行うこともできる。ここで、パケット送信装置は、さらに、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報の少なくとも１つとからなる制御認証情報を、ＡＶデータのプログラム単位毎にアクセス位置を指定するＵＲＩ情報、または、Ｑｕｅｒｙにより拡張されたＡＫＥアドレスとポートに関するＵＲＩ情報により、前記プログラムのリストとして、前記パケット受信装置に通知するアクセス位置通知部を備える。【０１２１】
また、パケット送信装置はさらに、パケット受信装置からプログラムリストの送信要求を受けると、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報の少なくとも１つとからなる制御認証情報を、ＡＶデータのプログラム単位毎にアクセス位置を指定するＵＲＩ情報、または、Ｑｕｅｒｙにより拡張されたＡＫＥアドレスとポートに関するＵＲＩ情報により、前記プログラムのリストとして、前記パケット受信装置に通知するアクセス位置通知部を備えてもよい。【０１２２】
また、パケット送信装置はさらに、ＡＶデータの単位プログラムのコピー制御情報がコピー制御を行わない意味の場合に、ＡＶデータのデータフォーマット情報を表す第１のＭＩＭＥ−Ｔｙｐｅと、ＡＶデータに間欠的に前記データブロックヘッダを付加したデータのデータフォーマット情報を表す第２のＭＩＭＥ−Ｔｙｐｅの２つのＭＩＭＥ−Ｔｙｐｅを生成し、ＡＶデータのプログラム単位毎にアクセス位置を指定する２つの拡張ＵＲＩ情報を前記パケット受信装置に提示するアクセス位置通知部を備えてもよい。【０１２３】
また、２つの拡張ＵＲＩ情報は、Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ（ＵＰｎＰ）におけるｒｅｓのＵＲＩ指定に使用し、前記２つのＭＩＭＥ−Ｔｙｐｅは前記ｒｅｓのａｔｔｒｉｂｕｔｅであるｐｒｏｔｏｃｏｌＩｎｆｏの第３フィールドに挿入することによりコンテンツの識別を行う。【０１２４】
パケット送信装置はさらに、パケット受信装置に送信するＡＶデータ及び非ＡＶデータ（ＥＰＧ情報などのメタデータ）をそれぞれ一時的に保持する第１及び第２バッファと、第１及び第２バッファのいずれかに保持されたデータが優先してパケット受信装置に送信されるように優先制御する構成をとることもできる。この場合、管理制御部４１３は、非ＡＶデータが前記第２バッファでオーバーフローしないことを維持しつつ、ＡＶデータが前記第１バッファから優先して出力されるように、優先制御を行うことを特徴とする。【０１２５】
また、プロトコル処理部４１９は、管理制御部４１３によってＡＶデータの伝送プロトコルとして、Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ（ＴＣＰ）と決定された場合は、ＴＣＰコネクションを永続的接続にして前記伝送を行うことを特徴とする場合もある。さらに、前記認証部は、Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ（ＤＴＣＰ）方式に従って、パケット受信装置と暗号化鍵を共有するための認証と鍵交換を行うことを特徴とする。【０１２６】
プロトコル処理部４１９は、ＨＴＴＰによるパケット化を行う場合、レンジリクエストまたはデータ取得コマンドなどによりパケット化を行なう。送信データがＭＰＥＧの場合には、ＭＰＥＧストリームにおけるタイムベース不連続発生情報または連続性情報、ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報、ＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの時刻情報、或るＩピクチャから次のＩピクチャの間に存在するＰピクチャとＢピクチャの各個数または合計個数のうち少なくとも１つの情報を参照して前記パケット化を行うこともできる。【０１２７】
また、プロトコル処理部４１９は、ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報として、ＡＶデータが複数の異なるファーマットであった場合にもオリジナルに持っている複数のＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報より、複数の異なるファーマット間で共通なＩピクチャまたはＰピクチャまたはＢピクチャ位置情報または時刻情報を生成し、この共通のＩピクチャまたはＰピクチャまたはＢピクチャ位置情報または時刻情報を用いて前記ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報の参照情報と前記パケット化を行うこともできる。【０１２８】
また、プロトコル処理部４１９は、ＨＴＴＰに従ったパケット化を行う場合、チャンク伝送方式で前記パケット化を行ない、ＨＴＴＰパケットのペイロード長が前記パケット送信装置で決定された値となるように前記パケット化を行うこともできる。【０１２９】
また、プロトコル処理部４１９は、ＨＴＴＰに従ったパケット化を行う場合は、ＨＴＴＰパケットのペイロード長が、暗号化情報ヘッダおよび整数個のトランスポートパケット（ＴＳ，１８８バイト長）により構成されるデータの長さ（暗号化情報ヘッダに１８８バイトの整数倍長を加算した長さ）、または、データブロックヘッダと整数個のタイムスタンプつきＴＳ（ＴＳに４バイトのタイムスタンプを付加し、１９２バイト長）により構成されるデータの長さ（暗号化情報ヘッダに１９２バイトの整数倍長を加算した長さ）となるように前記パケット化を行うこともできる。【０１３０】
また、プロトコル処理部４１９は、ＨＴＴＰによる伝送として、レンジリクエスト方式とチャンク伝送方式を切り替えて行うこともできる。【０１３１】
また、プロトコル処理部４１９は、ＨＴＴＰによる伝送として、パケット送信装置の出力がライブ放送の受信信号またはライブ放送の受信チャネルの切り替えまたは蓄積されたプログラム選択時の再生信号の場合には、チャンク伝送を行い、プログラム選択後の蓄積メディアから再生されたプログラムからの再生信号の場合には、レンジリクエストを用いて再生を切替えて行う。【０１３２】
また、プロトコル処理部４１９は、ＨＴＴＰによる伝送とＲＴＰによる伝送を切り替えて前記ＡＶデータを伝送することで、きめこまかな再生制御を実現できる。【０１３３】
次に受信側の処理を図９を用いて説明する。受信部５０１は、セキュアＩＰパケット受信処理部５０２をコアとして構成される。受信側において、プロトコル処理部５０３は、ネットワークより入力されるイーサネット（登録商標）フレームに対して、ＭＡＣヘッダを元にフィルタリングして受信し、ＩＰパケットを復元する。なお、一般のＥｔｈｅｒｎｅｔ（登録商標）系においては、機器のＭＡＣアドレスはルータのＳｕｂｎｅｔ境界を越えて伝送されないため、送受信機器のＭＡＣアドレスを事前に登録しておき、そのＭＡＣアドレスによる通信相手の識別を行うことによって、ＩＰパケットの伝送範囲をＩＰアドレスのＳｕｂｎｅｔ内に収めることができる。【０１３４】
データブロックパケット受信部５０４は、プロトコル処理部５０３から送られるデータパケットに対して、データブロックヘッダ検出部５０５でヘッダを識別し、ＡＫＥ部５０６にヘッダ情報を渡す。ＡＫＥ部５０６は、暗号の復号鍵を生成し、復号化部５０７に渡す。なお、ＡＫＥ部５０６は、規定の動作シーケンスに従い、認証と鍵交換を行なう。【０１３５】
送信側と受信側の間で認証と鍵交換が成立すれば、暗号化されたＡＶデータを受信しても暗号の復号ができる。送信側と受信側の間で認証と鍵交換が成立していなければ、暗号化されたＡＶデータを受信しても暗号の復号ができない。【０１３６】
復号化部５０７によって復号化されたＡＶデータは、データブロック生成部によって個々のデータブロックに区分され、デマルチプレクサ部５０９でデータパケットとＴＳパケットとに分離される。【０１３７】
分離されたデータパケットはデータパケット検出部５１０で検出された後、信号フォーマット及びプロパティ検出部で、ＴＳパケットによって表される映像信号の属性、例えばコピー制御条件など、として検出される。【０１３８】
分離されたＴＳパケットはＴＳパケットフィルタリング部５１２でフィルタリングされ、ＴＳインタフェース５１３を介して外部へ出力される。【０１３９】
ところで、パーシャルＭＰＥＧ−ＴＳは、たとえば、日本における地上デジタル放送、衛星デジタル放送、ＣＡＴＶ、インターネットや高速ＩＰ網配信システムにより伝送されるデジタル放送信号をデジタル放送チューナで受信し、選局する。ここで、放送局より送られるフルＴＳから、番組（プログラム）を構成するパーシャルＭＰＥＧ−ＴＳが抽出される。パーシャルＭＰＥＧ−ＴＳに多重化されているＰＳＩ／ＳＩとしては、ＰＡＴ，ＰＭＴ、ＤＩＴ，ＳＩＴ（例えば、ＡＲＩＢ規格、ＳＴＤ−Ｂ２１参照）などがあり、ＰＭＴはＤＴＣＰデスクリプタを含んでいる。また、ＤＴＣＰデスクリプタは、アナログコピー制御情報とデジタルコピー制御情報を含んでいる。たとえば、あるチャンネルのある番組のデジタルコピー制御情報において、ＰＭＴ第１ループのデジタルコピー制御情報とＰＭＴ第２ループのデジタルコピー制御情報が双方とも存在する場合には、ＰＭＴ第２ループのデジタルコピー制御情報を優先してその番組のデジタルコピー制御情報とする。またＰＭＴ第１ループのデジタルコピー制御情報とＰＭＴ第２ループのデジタルコピー制御情報の片方しか存在しない場合には、その存在する片方のデジタルコピー制御情報をその番組のデジタルコピー制御情報とする。これらの規定は、たとえば、ＡＲＩＢ規格、ＴＲ−Ｂ１４、第４編、「デジタルコピー制御」の章に記述されており、デジタル放送で運用されている。ただし、著作権に関する解釈や考え方は、情報公開やＩｎｔｅｒｎｅｔの発展普及などに伴って時代と共に変化していくため、前述の規定はあくまで一例であり、それ以外の運用も可能である。【０１４０】
今、ある放送チャンネルのある番組のデジタルコピー制御情報において、ＰＭＴ第２ループのデジタルコピー制御情報がＣＯＧ（Ｃｏｐｙ  Ｏｎｅ  Ｇｅｎｅｒａｔｉｏｎ、１世代コピーのみ可能）の場合に、暗号化部４１７は、パーシャルＭＰＥＧ−ＴＳ信号を暗号化する。さらに、データブロックヘッダ生成部４１６は、ＡＫＥ部４１４から送られてくるＣＯＧを表わす暗号化モードおよび、暗号化鍵更新情報（１ビット以上の情報）などのＡＫＥ情報を暗号化情報ヘッダとして付加する。【０１４１】
また、今、あるチャンネルのある番組のデジタルコピー制御情報において、ＰＭＴ第２ループのデジタルコピー制御情報がＣＦ（Ｃｏｐｙ  Ｆｒｅｅ、コピー可能）の場合に、暗号化部４１７は、パーシャルＭＰＥＧ−ＴＳ信号を暗号化しない。さらに、データブロックヘッダ生成部４１６は、ＡＫＥ部４１４から送られてくる前述のＣＦを表わすＥＭＩ（暗号化モード情報）および、シード情報（１ビット以上の情報）などのＡＫＥ情報を暗号化情報ヘッダとして付加し、プロトコル処理部４１９に出力する。なお、ここで、外部より暗号化情報ヘッダを付加しないように制御される場合には、暗号化情報ヘッダは付加されない。【０１４２】
また、外部入力データまたは、ＰＳＩ／ＳＩに多重されて入力されるパケットデータに送信許可情報を含めることができる。たとえば、ＭＰＥＧ−ＴＳのＰＭＴの第１ループまたは第２ループが持っているデジタルコピー制御記述子（たとえば、ＡＲＩＢ  ＴＲ−Ｂ１４、第２編、第４編を参照）の中にパケットデータ送信許可情報を含める。この場合、放送局など送信側の設備変更を伴う。【０１４３】
以上のように、暗号化実行の有無および、暗号化情報ヘッダ付加の有無は、パーシャルＴＳのコピー制御情報と外部入力や内部設定で決まられる条件により一意的に決めることができる。【０１４４】
プロトコル処理部４１９は、データブロックパケット生成部４１８から出力されるデータに対して、管理制御部４１３からの送信条件パラメータを用いて、ＴＣＰ／ＩＰのヘッダを付加する。また、プロトコル処理部４１９は、８０２．１Ｑ（ＶＬＡＮ）方式を用いてＭＡＣヘッダを付加することでイーサネット（登録商標）フレームに変換し、送信フレームとしてネットワークに出力する。ここで、ＭＡＣヘッダ内のＴＣＩ（Ｔａｇ  Ｃｏｎｔｒｏａｌ  Ｉｎｆｏｒｍａｉｔｉｏｎ）内のＰｒｉｏｒｉｔｙ（ユーザ優先度）を高く設定することにより、ネットワーク伝送の優先度を一般のデータよりも高くすることができる。【０１４５】
図１０にパーシャルＭＰＥＧ−ＴＳを暗号化してＨＴＴＰ／ＴＣＰ／ＩＰ／Ｅｔｈｅｒｎｅｔ（登録商標）で伝送する場合のＥｔｈｅｒｎｅｔ（登録商標）フレームの一例を示す。ここで、パーシャルＭＰＥＧ−ＴＳパケット（１８８バイト）には４バイトのタイムスタンプがヘッダとして付加されている。この４バイトのタイムスタンプ２７ＭＨｚのクロックでサンプリングされたものである。【０１４６】
さて、図１１は図８、図９の動作をプロトコルスタックを用いて補足説明した図である。図１１において、送信側、受信側ともコンテンツ、メタデータ、管理制御の３種類のデータを扱う。管理制御データは送信側と受信側の機器の動作設定、制御、管理を行うためのデータである。また、メタデータはコンテンツの伝送前に、コンテンツを選択したり、コンテンツ受信中にそのコンテンツの属性説明を確認するためのデータである。【０１４７】
また、図１２は図１１の動作を送受信部にまとめた説明図である。【０１４８】
コンテンツであるＭＰＥＧ−ＴＳは暗号化鍵により暗号化される。そして暗号化されたＭＰＥＧ−ＴＳは、ＡＶデータとしてＴＣＰ（またはＵＤＰ）パケットのペイロードとしてＴＣＰパケットが生成される。さらにこのＴＣＰパケットはＩＰパケットのデータペイロードとして使用され、ＩＰパケットが生成される。さらにこのＩＰパケットはＭＡＣフレームのペイロードデータとして使用され、イーサネット（登録商標）ＭＡＣフレームが生成される。なお、ＭＡＣとしてはイーサネット（登録商標）であるＩＥＥＥ８０２．３だけでなく、無線ＬＡＮ規格のＩＥＥＥ８０２．１１のＭＡＣにも適用できる。【０１４９】
イーサネット（登録商標）ＭＡＣフレームは、イーサネット（登録商標）上を送信側から受信側へ伝送される。受信側で所定の手順に従って復号鍵を生成する。そして、受信したイーサネット（登録商標）ＭＡＣフレームからＩＰパケットがフィルタリングされる。さらにＩＰパケットからＴＣＰ（またはＵＤＰ）パケットが抜き出される。そして、ＴＣＰ（またはＵＤＰ）パケットからＡＶデータが抜き出され、交換鍵と鍵変更情報より復元された復号鍵により、ＭＰＥＧ−ＴＳ（コンテンツ）が復号され出力される。【０１５０】
以上のように、本実施の形態によれば、パーシャルＭＰＥＧ−ＴＳ信号などのＡＶストリームをパケット送信機器で暗号化してＩＰパケット化してネットワークにより伝送し、ＩＰパケット受信機器で元の信号に復号することが可能である。【０１５１】
なお、図７において、スイッチングハブを用いたネットワークトポロジーを工夫することにより、ストリーム伝送とファイル転送を共存させることができる。たとえば、１階と２階の間のネットワーク３０５の帯域を、従来の技術で説明した１００Ｍｂｐｓから１Ｇｂｐｓに拡張することによって、１階と２階のＰＣ間でのファイル転送をバックグラウンドで行いながら、同時に、１階および２階のＤＶＤレコーダ、ＰＣ、ＴＶの間でＭＰＥＧ−ＴＳを暗号化してリアルタイムで伝送することができる。たとえば、市販されている１００Ｍｂｐｓのポートを８つ、１Ｇｂｐｓのポートを１つ持ったスイッチングハブを用い、１階と２階を結ぶネットワーク３０５に１Ｇｂｐｓのポートを接続し、残りの８ｃｈの１００ＭｂｐｓのポートにＴＶなどのＡＶ機器を接続する。１００Ｍｂｐｓのポートは８つなので、８つのポートのデータがそれぞれ最大１００Ｍｂｐｓで入力されて１Ｇｂｐｓのポートに出力されたとしても、１００Ｍｂｐｓ×８ｃｈ＝８００Ｍｂｐｓと１Ｇｂｐｓより小さいため、８つのポートから入力されたデータはスイッチングハブ内部で失われず全て１Ｇｂｐｓのポートに出力される。よって、１階で発生したデータは全て２階に伝送することが可能である。また、逆に２階で発生したデータも全て１階に伝送することが可能である。以上のように、スイッチングハブを用いる場合、ネットワークトポロジーを工夫することによりストリーム伝送とファイル転送を共存させることができる。【０１５２】
また、図８において、ＡＫＥ部４１４は認証モード決定部を内部に持つ。ＡＫＥ部４１４に対してＡＫＥ設定情報として、認証用のＴＣＰのポート番号が、管理制御データとして、管理制御部４１３に入力される。ここで、認証用のＴＣＰポート情報は、ＵＰｎＰ−ＡＶの仕組みを用いて、コンテンツ毎または放送チャネル毎にアクセス位置を指定するＵＲＩ、または、Ｑｕｅｒｙにより拡張されたＵＲＩにより与えることができる。ここでＵＲＩの主データ部にはコンテンツのＵＲＩ情報、Ｑｕｅｒｙ部にはそのコンテンツの認証情報をマッピングする。ここで、もし、Ｑｕｅｒｙ部がなければそのコンテンツの伝送には認証が不必要であり、Ｑｕｅｒｙ部が存在すればそのコンテンツの伝送には認証が必要である様にモード設定できる。ＵＲＩとＱｕｅｒｙの例は、例えば下記の形式で与えることができる。【０１５３】
＜ｓｅｒｖｉｃｅ＞：／／＜ｈｏｓｔ＞：＜ｐｏｒｔ＞／＜ｐａｔｈ＞／＜ｆｉｌｅｎａｍｅ＞．＜ｅｘｔ＞
？ＡＫＥＨＯＳＴ＝＜ｈｏｓｔ２＞：ＡＫＥＰＯＲＴ＝＜ｐｏｒｔ２＞
ここで、＜ｈｏｓｔ＞：＜ｐｏｒｔ＞／＜ｐａｔｈ＞／＜ｆｉｌｅｎａｍｅ＞．＜ｅｘｔ＞はＡＶコンテンツのＵＲＩとファイル名称を表しており、「？」以下のＱｕｅｒｙ部における＜ｈｏｓｔ２＞、＜ｐｏｒｔ２＞は、それぞれ認証用ＩＰアドレスとポート番号を表している。【０１５４】
送信側はこのＵＲＩとＱｕｅｒｙで認証の実行モード情報を受信側に与える。受信側はＷＥＢブラウザやＵＰｎＰ−ＡＶのＣＤＳ（Ｃｏｎｔｅｎｔ  Ｄｉｒｅｃｔｏｒｙ  ｓｅｒｖｉｃｅ）を用いて、上記のＵＲＩとＱｕｅｒｙ情報を受け取り、認証モード決定部６０１が認証モードを決定することができる。【０１５５】
図８において、管理制御部４１３に入力されるＡＶデータの入力ソース情報（放送、外部ムービーからの入力）としては、たとえば次のケースが考えられる。
（ケース１）ＡＶデータがコピーフリーコンテンツを放送する放送チャネルで受信されるコンテンツである場合。この様な放送チャネルの例としては、たとえば、アナログ放送であるＶＨＦ、ＵＨＦ、またはＢＳアナログ放送の放送チャネルがある。
（ケース２）ＡＶデータが一時的にでもコピーフリーでないコンテンツを放送する放送チャネルで受信されるコンテンツの場合。この様な放送チャネルの例としては、たとえば、ＢＳデジタル放送の有料チャネルやＣＡＴＶ放送による有料チャネルがある。この一定期間でもコピーフリーでないコンテンツを放送する放送チャネルのコピー制御情報は、コピーネバー、コピーワンジェネレーション、およびＥＰＮ（Ｅｎｃｒｙｐｔｉｏｎ  Ｐｌｕｓ  Ｎｏｎ−ａｓｓｅｔｉｏｎ）フラグ付きコピーフリーが放送内容により時々刻々と切り替わる。【０１５６】
ここで、一時的にでもコピーフリーでないコンテンツを放送する放送チャネルの受信は、放送の配信を行う事業者との間での認証部により正当な受信装置または受信ユーザであることを認証された場合に行われるように制御できる。この認証の例としては、日本のデジタル衛星放送のＢ−ＣＡＳ（ＢＳ−Ｃｏｎｄｉｔｉｏｎａｌ  Ａｃｃｅｓｓ  Ｓｙｓｔｅｍｓ）カード、または米国のＣＡＴＶ放送で使用されるＰＯＤ（Ｐｏｉｎｔ  Ｏｆ  Ｄｅｐｌｏｙｍｅｎｔ）カードなどのセキュリティモジュールによる認証が考えられる。【０１５７】
また、暗号化情報ヘッダの付加制御は、たとえば以下の様に行なう。すなわち、コピーフリーコンテンツを放送する放送チャネルを受信した場合には付加しない。また、一定期間でもコピーフリーでないコンテンツを放送する放送チャネルを受信した場合には付加する。さらに、ＡＶデータが蓄積メディアよりコピーフリータイトルのコンテンツを再生した場合には付加しない。そして、ＡＶデータが蓄積メディアよりコピーフリーでないタイトルのコンテンツを再生した場合には付加する。なお、送信側における暗号化情報ヘッダの付加分される場合、ＨＴＴＰのレスポンスヘッダには、伝送されるデータ長にこの暗号化情報ヘッダの長さだけ増加したＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈが記述される。【０１５８】
以上のように、暗号化情報ヘッダの付加制御を行うことにより、著作権者が設定したＡＶコンテンツのＣＣＩ（コピー制御情報）をネットワーク伝送においても継承して伝えていくことができる。さらに、送信側と受信側で暗号化情報ヘッダの付加制御のルールを揃えることにより異機種間での動作互換性を確保することができる。【０１５９】
図１３は図８を簡略的に表した図であり、代表的な構成要素として、デジタルチューナ４０３、ＴＳインタフェース４０４、スイッチャ４０５、セキュアＩＰ化送信制御部４０２、伝送プロトコル処理部４１９を備える。【０１６０】
図１３において、デジタルチューナ４０３より入力されるＡＶ信号は、それぞれ、日本のデジタル放送（地上波デジタル放送、ＢＳデジタル放送、１１０度ＣＳデジタル放送）を受信したコピーワンジェネレーション（ＣＯＧ）にコピー制御された（著作権保護が実施されているという意味）ＭＰＥＧ−ＴＳ信号である。また、ＴＳインタフェース４０４より入力されるＡＶ信号は、ＨＤＴＶ対応のカムコーダ（ムービー）で撮影されたコピーフリー（著作権保護が実施されていないという意味）のＭＰＥＧ−ＴＳ信号である。【０１６１】
上記において、パケット送信装置でＡＶデータの単位プログラムが第１のＭＩＭＥ−Ｔｙｐｅ（ブロックヘッダを付加する、かつ、暗号化も実施する場合）と、第２のＭＩＭＥ−Ｔｙｐｅ（ブロックヘッダを付加する、かつ、暗号化は実施しない場合）を用いることについて説明した。ここでは、更に、ＨＤＴＶ対応のカムコーダ（ムービー）で撮影されたコピーフリーのＭＰＥＧ−ＴＳ信号第３のＭＩＭＥ−Ｔｙｐｅ（ブロックヘッダを付加しない、かつ、暗号化も実施しない場合）を用いる。【０１６２】
ＭＩＭＥ−Ｔｙｐｅによるコンテンツの識別に関しては、前述した＜ｒｅｓ＞のａｔｔｒｉｂｕｔｅであるｐｒｏｔｏｃｏｌＩｎｆｏの第３フィールドに挿入されたＭＩＭＥ−Ｔｙｐｅや、ＨＴＴＰのレスポンスヘッダに挿入されたＭＩＭＥ−Ｔｙｐｅからコンテンツの識別を行うことができる。【０１６３】
なお、ＨＤＴＶ対応のカムコーダ（ムービー）の撮影指揮者（著作権者の意味）が撮影したＭＰＥＧ−ＴＳ信号をコピーフリーにしたくない場合、著作権に関する法令にしたがって著作権の主張を行うことにより、自分で撮影したＭＰＥＧ−ＴＳ信号のＣＣＩをＣＯＧやＣＮに設定して運用することもできるし、また、有償コンテンツとしてサーバにアップロードして課金することもできる。この場合、たとえば、第１のＭＩＭＥ−Ｔｙｐｅ（ブロックヘッダを付加する、かつ、暗号化も実施する）を用いることができる。【０１６４】
なお、本実施例では著作権保護方式としてＤＴＣＰ方式を用いた説明を行ったが、著作権保護方式としてはＤＴＣＰ方式以外のＤＲＭ方式でも、同様の効果が得られる。【０１６５】
（実施の形態２）
次に、本発明の実施の形態２について説明する。図１４は、本実施の形態におけるパケット送信部の構成を示すブロック図である。図１４は、代表的な構成要素として、デジタルチューナ４０３、ＴＳインタフェース４０４、スイッチャ４０５、セキュアＩＰ化送信制御部４０２、伝送プロトコル処理部４１９、および蓄積部１００１を備える。図１４の構成は、図８および図１３に示された実施の形態１のパケット送信部の構成に加えて、蓄積部１００１を備える。以下、実施の形態１と同じ部分の説明は省略し、異なる部分のみを説明する。【０１６６】
このパケット送信部は、デジタルチューナ４０３および、ＴＳインタフェース４０４に接続された蓄積部１００１を具備する。ここで、蓄積部１００１は、ハードディスクドライブ（ＨＤＤ）や光ディスク（ＣＤやＤＶＤなど）や半導体ディスク（ＳＤカードメモリなど）やその組み合わせを採用することができる。本実施の形態において、このパケット送信部は、ハードディスクや光ディスクなどに蓄積されたパーシャルＭＰＥＧ−ＴＳデータなどを、たとえば、受信部からのＨＴＴＰのレンジリクエストを用いて伝送する。【０１６７】
このレンジリクエストは、蓄積部１００１に蓄積されたパーシャルＭＰＥＧ−ＴＳのファイルの先頭からの距離、たとえばＡ、Ｂ（Ａ，ＢはＡ＜Ｂを満足する０以上の整数）でレンジ先頭とレンジ末尾を選んでリクエストされる。通常、一般データに対してＡ，Ｂは自由な値を選べるが、ＭＰＥＧ−ＴＳのような映像データをレンジＧＥＴする場合、そのＧＯＰやＰｉｃｔｕｒｅ構造に着目すれば、効率のよい伝送ができる。しかしながら、受信側は、送信側の蓄積ファイルのどの部分でＧＯＰを構成しているとか、どの部分がＩピクチャであるとかは分からない。そこで、送信側は受信側よりＨＴＴＰのレンジリクエストを受け取ると、そのレンジ先頭とレンジ末尾にそれぞれ最も近いＧＯＰをＨＴＴＰレスポンスとして返す。この伝送方法を仮にＨＴＴＰアライメントレスポンス法（ＨＴＴＰ  ＡＶ  Ａｌｉｇｎｍｅｎｔ  Ｄａｔａ  Ｕｎｉｔ  Ｒｅｓｐｏｎｓｅ  Ｍｅｔｈｏｄ；ＨＡＲ法と略す）と呼ぶ。このような伝送モードの選択のトリガとしては、たとえば次の方法がある。【０１６８】
１）送信側（サーバ）と受信側（クライアント）の間でＵＰｎＰ−ＡＶなどのメカニズムを用いて事前にネゴを行う。【０１６９】
２）ＨＴＴＰのリクエストヘッダに、ＨＡＲ法でのレスポンスを期待してＨＡＲ法を使用することを表す文字列などの指示情報を挿入する。たとえば、
ｈａｒ−ｖａｌｕｅ  ＝  ｇｏｐ
をＨＴＴＰリクエストに挿入する。【０１７０】
ＨＡＲ法に対応していないサーバは、この指示情報には反応しないが、ＨＡＲ法に対応しているサーバはこの指示情報に反応して、レンジリクエストされたレンジ先頭にもっとも近いＧＯＰ先頭をリクエストされたデータから探し出しレスポンスのレンジ先頭に設定する、また、レンジリクエストされたレンジ末尾にもっとも近いＧＯＰ先頭をリクエストされたデータから探し出しレスポンスのレンジ末尾に設定する。そして、サーバはＨＴＴＰのレスポンスヘッダにＨＡＲ法によるレスポンスであることを表す文字列などの指示情報を挿入する。たとえば、
ｈａｒ−ｖａｌｕｅ  ＝  ｇｏｐ
をＨＴＴＰレスポンスに挿入する。【０１７１】
これらの動作によって、クライアントはサーバ内データに対して適当なレンジリクエストしたにもかかわらず、クライアントはＨＴＴＰレスポンスに挿入されたＭＰＥＧ−ＴＳをＧＯＰ単位で部分ＧＥＴできる。【０１７２】
ＭＰＥＧ−ＴＳが連続的に記録されたファイルの場合は、ひとたび、ＧＯＰ単位のレスポンスを受け取れば、映像を連続フレームで受け取りたい場合に、直前に受け取ったレンジ末尾の値より、次のＧＯＰ先頭の位置を容易に計算できる。たとえば、直前に受け取ったレンジ末尾の値１バイト足すことで次のＧＯＰ先頭の位置が分かる。【０１７３】
以上のように第２の実施例では、受信側より送信側にＨＴＴＰのレンジリクエストによるデータ要求を行う場合に、伝送されるデータブロックの先頭データまたは末尾データを、送信側で管理しているＧＯＰなどのデータブロック単位の先頭データと一致させる。たとえば、データがＭＰＥＧの場合には、送信側で管理するデータブロックの単位は、上記の例で説明したＧＯＰだけでなく、Ｐｉｃｔｕｒｅ、マクロブロック、ブロック、ＴＳパケット、または、タイムスタンプ付きＴＳパケットなどの単位に指定することができる。【０１７４】
また、データブロックが送信装置に内蔵されたハードディスク（ＨＤＤと略す）やＣＤやＤＶＤ（ＤＶＤ−Ｒ、ＤＶＤ−ＲＡＭなど複数の種類がある）などの光ディスク、ＳＤメモリカードのような半導体ディスクの場合には、これはＨＤＤ（たとえば５１２バイトのＬＢＡ単位）やＣＤ（たとえば、２ｋＢ単位）やＤＶＤの各記録フォーマットが、論理ブロックの単位とすることもできる。【０１７５】
よって、たとえば、データ（ファイルやストリーム）がＭＰＥＧの場合に、受信側より送信側にＨＴＴＰのレンジリクエストで要求するデータ範囲がＧＯＰ単位やＰｉｃｔｕｒｅ単位とデータ境界が合っていなくても、すなわち、データのアライメントが取れていなくても、あらかじめレスポンス単位をＧＯＰ単位やＰｉｃｔｕｒｅ単位にネゴシエーションなどで決めてあれば、サーバ（送信側）の処理としてＨＴＴＰレスポンスとして要求されたデータ範囲に近いところにあるＧＯＰ単位、Ｐｉｃｔｕｒｅ単位、やＴＳパケット単位で境界を合わせたレスポンスとして返信できる。そこで、受信側では受信データから効率よくＭＰＥＧデコードを行うことができる。【０１７６】
また、ＭＰＥＧ−ＴＳの例として、サーバがＢｌｕ−ｒａｙディスクレコーダの場合、ＰＬＡＹＬＩＳＴファイルやＣＬＩＰＩＮＦＯファイルを用いて効率よくＧＯＰ境界位置やＩピクチャ位置を認識して、ＧＯＰやＩピクチャデータを取り出すことができるので、サーバの動作負荷を下げることができる。また、ＭＰＥＧ−ＰＳの場合にも、サーバがＤＶＤ−ＲＡＭディスクレコーダで記録フォーマットがＤＶＤ−ＶＲ規格に準拠している場合、ＤＶＤ−ＶＲ方式ではＩＦＯファイルと呼ばれている管理ファイルを持っている。よって、サーバ側はこのＩＦＯファイルの管理情報を活用することにより、効率よくＧＯＰ境界位置やＩピクチャ位置を認識して、ＧＯＰやＩピクチャデータを取り出すことができるので、サーバの利用効率も上がる。以上のようにＰＬＡＹＬＩＳＴファイルやＣＬＩＰＩＮＦＯファイルやＩＦＯファイルと同様な構造を持ったデータ管理ファイルを活用することにより、サーバは容易に上述のＨＡＲ法を使用できる。【０１７７】
この場合、サーバはクライアントから上記ＨＡＲ法によるレンジリクエスト値を受け取り、自身の持っているＩＦＯファイルと比較して返信するＧＯＰブロックを決定する。以上により、ＡＶコンテンツにＤＴＣＰ−ＩＰを適用して伝送することが可能となる。【０１７８】
また、蓄積部７０１に暗号化されたコンテンツを記録しておき（いわゆるＤＲＭによる暗号化を適用したコンテンツが対象）、その記録されたコンテンツのリストを呼び出し、ユーザが視聴したいコンテンツ（映画、コンサート、ドラマなど）を選択する場合に暗号を解除するために、たとえば、次の方法を実装することができる。【０１７９】
方法１）ユーザは、インターネットや電話回線を通じて、あるいはコンビニエンスストアなどで、暗号化されたコンテンツを復号するための情報を購入する。コンテンツは、ユーザが対象機器を購入した時点で、既に蓄積部７０１に、たとえば１００タイトル分の映画、コンサート、ドラマなどが記録されている場合に有効なである。【０１８０】
方法２）ユーザは、インターネットやＣＡＴＶ、放送を通じて、暗号化されたコンテンツをダウンロードする。さらに、ユーザはインターネットや電話回線を通じて、あるいはコンビニエンスストアなどで、暗号化されたコンテンツを復号するための情報を購入する。【０１８１】
方法３）ユーザがパッケージメディアとしてコンテンツを購入した際に付属しているコンテンツの暗号を復号するための情報を使用する。【０１８２】
また、このパケット送信部がＴＳストリームからＩフレーム位置情報生成部を具備する場合、蓄積部からパーシャルＭＰＥＧ−ＴＳデータなどをＨＴＴＰのレンジリクエストを用いて伝送する。このＨＴＴＰのレンジリクエストおよびレスポンスには、上述したＨＡＲ法でＩフレームに効率的にアクセスする方法について説明する。ここで、伝送モード選択のトリガとしては、たとえば次の方法がある。【０１８３】
１）送信側（サーバ）と受信側（クライアント）の間でＵＰｎＰ−ＡＶなどのメカニズムを用いて事前にネゴを行う。【０１８４】
２）ＨＴＴＰのリクエストヘッダに、ＨＡＲ法でのレスポンスを期待してＨＡＲ法を使用することを表す文字列などの指示情報を挿入する。たとえば、
ｈａｒ−ｖａｌｕｅ  ＝  ｉ−ｐｉｃｔｕｒｅ  ：  １
をＨＴＴＰリクエストに挿入する。ここで、
ｈａｒ−ｖａｌｕｅ  ＝  ｉ−ｐｉｃｔｕｒｅ  ：  ｎ  （ｎは整数）
の動作として、サーバ内のＩフレーム位置情報生成部は、”ｉ−ｐｉｃｔｕｒｅ”はレンジリクエストされた範囲におけるｉ−ｐｉｃｔｕｒｅの位置情報を計算、生成する。このレンジリクエストされた範囲におけるｉ−ｐｉｃｔｕｒｅの位置情報により、蓄積制御部７０１はＩピクチャデータをｎ個とばしで抜き出し、クライアントに送る。ｎの値が“＋”の場合は、レンジの最初から末尾方向にｉ−ｐｉｃｔｕｒｅのみを抜き出しｎ個とばしでクライアントに送り、いわゆる、順方向のフレーム飛ばしスキップ再生を行う。ｎの値が“−”の場合は、レンジの末尾から頭方向にｉ−ｐｉｃｔｕｒｅのみを抜き出しｎ個とばしでクライアントに送り、いわゆる、逆方向のフレーム飛ばしスキップ再生を行う。【０１８５】
“ｈａｒ−ｖａｌｕｅ”を“  ＝  ｉ−ｐｉｃｔｕｒｅ  ：  ｎ  （ｎは整数）”に拡張することにより、クライアントはサーバ内データに対して適当なレンジリクエストしたにもかかわらず、クライアントはＨＴＴＰレスポンスに挿入されたＭＰＥＧ−ＴＳをＩピクチャ単位で部分ＧＥＴできる。【０１８６】
また、サーバ内ＨＤＤに記録されたＭＰＥＧ−ＴＳの管理情報として、Ｉフレームの位置と概略サイズに関する情報があれば、その情報を用いてＩピクチャを含むデタをクライアントに送ることもできる。【０１８７】
以上のように、サーバ内のＭＰＥＧファイルのＩフレーム位置情報を活用することにより、早送り、巻き戻し、スロー再生などの特殊再生を効率よく実現できる。そこで、一般に、ＤＲＭ対応ＡＶコンテンツをＤＴＣＰ−ＩＰを用いて伝送することが可能となる。【０１８８】
なお、ＨＴＴＰによる伝送とＲＴＰによる伝送を切り替えてＡＶデータを伝送することもできる。ＲＴＰの場合は、ＲＴＣＰプロトコルを用いて適切な開始位置を指定すれば、そこにＲＴＰに対応したＨＡＲ法を適用することができる。【０１８９】
なお、複数のファイルフォーマットに対して共通に使用できるピクチャ位置情報ファイルを用いて、異なるＭＰＥＧファイルシステムを採用したシステムに対して、そのファイルにおけるＩ／Ｐ／Ｂピクチャの位置情報、時刻情報などを共通のピクチャ情報ファイルとして取り扱うことにより、異なるファイルフォーマットを共通のプラットフォーム上で取り扱うことが可能となる。【０１９０】
ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報は、前記ＡＶデータが複数の異なるファーマットであった場合にもオリジナルに持っている複数のＩピクチャまたはＰピクチャまたはＢピクチャの位置情報、前記ＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの時刻情報より、複数の異なるファーマット間で共通なＩピクチャまたはＰピクチャまたはＢピクチャ位置情報を生成し、この共通のＩピクチャまたはＰピクチャまたはＢピクチャ位置情報を用いて前記ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報、時刻情報の参照情報とする。これにより、たとえばＨＤＤに、異なる記録フォーマットで記録されているＭＰＥＧ−ＴＳファイルがあっても、リモート端末からは共通のＩまたはＰまたはＢピクチャの位置情報や時間情報で特定のピクチャに直接アクセスできるという大きなメリットがある。【０１９１】
たとえば、パーシャルＴＳを記録したＨＤＤやＢＤディスクなどから、ＩまたはＰまたはＢピクチャの連続性およびファイル内での位置情報などを統一した「ピクチャ情報ファイル」を読み出す。ネットワークを介して離れた場所に存在する端末からは、この統一されたピクチャ情報ファイルをバイト位置や時刻情報（ｔｉｍｅｓｔａｍｐ）で参照することにより、異なるＴＳ記録フォーマットでも各ピクチャ位置をきめ細かに参照することができる。【０１９２】
以上にように、きめ細かやで綺麗なスロー再生や高速再生などのトリック再生が実現される。なお、このピクチャ情報ファイルはリモート端末からローカル端末内の異なるファーマットで記録されたＭＰＥＧ−ＴＳファイル内のピクチャ位置を共通のファイル形式で見せることができるフィルタ機能として考えることができる。すなわち、独自のファイル形式でＭＰＥＧ−ＴＳを記録したＡＶデータファイルとその関連情報ファイルより、共通のピクチャ情報ファイルを生成することができる。【０１９３】
また、本実施の形態により、ＡＶコンテンツをＡＫＥや暗号処理を実装しない送受信装置による実装の場合にも、ＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャに効率よくアクセスできるという効果が奏される。【０１９４】
また、ＨＴＴＰプロトコルを用いたレンジリクエストのプロトコルシーケンスは、送信データの一部だけを切り出して伝送するので、データ伝送が終わるごとにＴＣＰコネクションを切断する場合もありうる。そのような場合、元データは時間軸で連続していても、伝送された複数のデータブロック集合はＴＣＰコネクションの確立、切断、確立、切断を繰り返しで伝送されたものであり、データのタイムベースは不連続とみなされてしまい、パーシャルＭＰＥＧ−ＴＳの場合は、たとえば、ＤＶＢ規格やＡＲＩＢ規格、ＳＴＤ−Ｂ２１やＴＲ−Ｂ１４，１５に準拠した従来の処理を行うと、伝送データの先頭と末尾にＤＩＴなどのタイムベースの不連続情報の付加が必要となる。これによって、伝送データサイズが変化するとＨＴＴＰレスポンスのヘッダ内のＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈが、もともとリクエストした値から、暗号化情報ヘッダの付加分だけでなく、タイムベースの不連続情報の付加分だけ増加してしまう。なお、この暗号化情報ヘッダの付加分はパケット受信部で削除されるので、正味の伝送コンテンツとして扱わなくてよい。本発明では、以降の実施例でも、この暗号化情報ヘッダの付加分はパケット受信部で削除されるので、正味の伝送コンテンツとして扱わない。【０１９５】
本実施例では、パーシャルＭＰＥＧ−ＴＳをＨＴＴＰで伝送する場合の新たな仕組みとして、特にタイムベースが不連続であることを指示されない限りは、ＨＴＴＰのレスポンスの先頭や末尾にＤＩＴなど不連続情報を挿入しないアルゴリズムとする。なお、ＭＰＥＧストリームにおける不連続発生連続性情報とは、たとえば、ＡＲＩＢ規格、ＡＲＩＢ−ＴＲ−Ｂ１４またはＡＲＩＢ−ＴＲ−Ｂ１４の第２編に記載されているＤＩＴ情報であり、これを元に別の論理記述で不連続発生連続性情報を生成することもできる。このストリームの不連続点とは、たとえば、ＭＰＥＧのパーシャルＴＳの場合、ＭＰＥＧ−ＴＳストリームのシステムタイムベースの不連続が発生する点、たとえば、ＰＣＲが不連続になる点、または、パーシャルＴＳを構成するパケットの内のどれか１つのトランスポートパケットヘッダのｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒの不連続が発生する点をさす。【０１９６】
ここで、補助データファイルには、ＭＰＥＧ−ＴＳのＧＯＰ単位あるいはＩピクチャ単位でのデータ構造を記述してあるので、Ｒａｎｇｅ、Ｎｏ．１、Ｎｏ．２、Ｎｏ．３はそれぞれ、ＭＰＥＧ−ＴＳファイルのＧＯＰ単位あるいはＩピクチャ単位とすることができ、一般的なＭＰＥＧのデコード動作（デコードのアルゴリズムとシーケンスと同等の意味で用いている）に対して効率的なデータ伝送が実現できる。【０１９７】
以上のように、サーバ内のＭＰＥＧファイルのＧＯＰ構造やＩフレーム位置情報を活用することにより、早送り、巻き戻し、スロー再生などの特殊再生を効率よく実現できる。そこで、一般に、ＤＲＭ対応ＡＶコンテンツをＤＴＣＰ−ＩＰを適用して効率よく伝送することが可能となる。【０１９８】
（実施の形態３）
次に、本発明の実施の形態３について説明する。図１５は、本実施の形態におけるパケット送信部の構成を示すブロック図である。このパケット送受信部は、図１４に示した実施の形態２のパケット送信部の構成に加えて、ＭＰＥＧ−２／Ｈ．２６４トランスコーダ１１０１を備える。以下、実施の形態２と同じ部分の説明は省略し、異なる部分のみを説明する。【０１９９】
このパケット送信部は、新たに蓄積部１００１に接続されたＭＰＥＧ−２／Ｈ．２６４トランスコーダ１１０１を具備する。ＭＰＥＧ−２／Ｈ．２６４トランスコーダ１１０１は、蓄積部１００１に蓄積されたＭＰＥＧ−２  ＴＳのファイルをＨ．２６４（Ｈ．２６４／ＡＶＣ形式と呼ばれている）にトランスコードする。このトランスコードによって、画質を保ちながらファイルサイズを約２分の１以下に削減できるため、より多くのファイルの蓄積が可能になるとともに、より狭い帯域でＨ．２６４ストリームを実時間伝送すること、あるいは、より高速にファイル転送することができる。【０２００】
たとえば、家庭内ネットワークを無線ＬＡＮ（８０２．１１ａ／ｂなど）で構築している場合、ＭＰＥＧ−２では、ＨＤＴＶのＴＳビットレートが約２５Ｍｂｐｓとなり、無線ＬＡＮでは帯域が不足する場合でも、Ｈ．２６４の場合、約８Ｍｂｐｓに伝送レートを削減できるため、本構成により余裕を持って家庭内でのＨＤＴＶの無線伝送が可能となる。また、ＳＤＴＶの場合は１．５Ｍｂｐｓ程度にできるので、たとえば６ｃｈでも９Ｍｂｐｓであり、主要放送局６局分のＭＰＥＧ−ＴＳを同時にホームサーバとクライアント間で伝送することが可能となる。【０２０１】
なお、Ｈ．２６４の解説は、たとえば、「Ｈ．２６４／ＡＶＣ教科書」、大久保榮監修、株式会社インプレス発行、などで説明されている。【０２０２】
ＭＰＥＧ−２／Ｈ．２６４トランスコーダ１１０１におけるＣＣＩの取り扱いとして、たとえば、Ｈ．２６４はＭＰＥＧ−２のＴＳパケットにマッピングしてＭＰＥＧシステムで運用する場合、ＭＰＥＧ−２のＴＳでＣＣＩを含んでいるＰＭＴ中のＣＣＩモードの意味を変化させないで、「ＭＰＥＧ−２のＴＳのＰＭＴ」から「Ｈ．２６４のＴＳのＰＭＴ」に継承させる。ＭＰＥＧ−２からＨ．２６４へのトランスコードによりＰＡＴ、ＰＭＴが、それぞれ指定するプログラムマップテーブル（ＰＭＴ）とストリームＰＩＤは変化する。なお、ＳＩＴ、ＤＩＴは適切な値に書き換えられる。以上により、ＡＶ信号部分をＭＰＥＧ−２からＨ．２６４にトランスコードし、ＰＡＴ，ＰＭＴ、ＳＩＴ、ＤＩＴを含んだＨ．２６４のＴＳにトランスコードすることができる。【０２０３】
また、ＭＰＥＧ−２のＴＳからＰＳにトランスコードする場合にも、同様に考えることができる。ＭＰＥＧ−ＰＳとして、たとえば、ＤＶＤ−ＶＲ（Ｖｉｄｅｏ  Ｒｅｃｏｒｄｉｎｇ）仕様を用いる場合、ＭＰＥＧ−２のＴＳパケットはＰＥＳに変換された後にＭＰＥＧ−ＰＳに変換できる。ＣＣＩの継承に関しては、ＭＰＥＧ−２のＴＳでＣＣＩを含んでいるＰＭＴ中のＣＣＩモードの意味を変化させないで、「ＭＰＥＧ−２のＴＳのＰＭＴ」から、たとえば、「ＤＶＤ−ＶＲ規格においてＣＣＩを含んでいる、ＲＤＩパック中のＣＣＩ」に継承させる。デジタルコピー制御に関しては、ＰＭＴのデジタルコピー制御用ＣＣＩの意味をＲＤＩパックのデジタルコピー制御用ＣＣＩに継承させる。また、アナログコピー制御に関しては、ＰＭＴのデジタルアナログコピー制御用ＣＣＩの意味をＲＤＩパックのアナログコピー制御用ＣＣＩに継承させる。以上により、ＡＶ信号部分をＣＣＩ情報（ＣＣＩの意味）と共に、ＭＰＥＧ−２のＴＳからＰＳにトランスコードすることができる。【０２０４】
ＭＰＥＧ−ＰＳを用いることにより、たとえば、家庭内ネットワークを無線ＬＡＮ（８０２．１１ａ／ｂなど）で構築している場合、ＭＰＥＧ−２のＰＳの場合、伝送レートを約１．５〜１０．８Ｍｂｐｓにできるため、ＭＰＥＧ−ＴＳの場合より余裕を持って家庭内で映像の無線伝送が可能となる。また、１．５Ｍｂｐｓ程度に圧縮した場合、たとえば６ｃｈでも９Ｍｂｐｓであるので、主要放送局６局分のＭＰＥＧ−ＰＳを同時にホームサーバとクライアント間で伝送することも可能となる。【０２０５】
（実施の形態４）
次に、本発明の実施の形態４について説明する。本実施の形態におけるパケット送受信部の構成を図１６に示すが、図１６は第１の実施例で述べた図８の送信部および図９の受信部とを組み合わせて、送受信部にまとめた構成である。図１６は、代表的な構成要素として、ＴＳ入力インタフェース部１２０１、ＴＳ−ＭＵＸ部１２０２、ＴＳ出力インタファース部１２０３、セキュアＩＰ化送信制御部８０１、および、伝送プロトコル処理部８０２を備える。よって、以下では実施の形態１と同じ部分の説明は省略し、異なる部分のみを説明する。【０２０６】
図１６において、ＴＳ入力インタフェース部１２０１に入力されたＴＳ信号は、ＴＳ−ＭＵＸ部を通じてセキュアＩＰ化送信制御部８０１に入力され、伝送プロトコル処理部８０２から受信部に送信される。また、伝送プロトコル処理部８０２で受信した信号はセキュアＩＰ化送信制御部８０１に入力され、ＴＳ−ＭＵＸ部を通じてＴＳ出力インタフェース部１２０３に出力される。【０２０７】
以上のように、図１６の構成により双方向通信が可能となる。【０２０８】
なお、ＨＤＴＶ対応のカムコーダ（ムービー）を用いて双方向通信を行っている場合、撮影指揮者（著作権者の意味）が撮影したＭＰＥＧ−ＴＳ信号をコピーフリーでも暗号化したい場合、自分で撮影したＭＰＥＧ−ＴＳ信号のＣＣＩをＣＦ／ＥＰＮ（Ｃｏｐｙ  Ｆｒｅｅ、Ｅｎｃｒｉｐｔｉｏｎ  ｐｌｕｓ  ｎｏｎ−ａｓｓｅｒｔｉｏｎ）モードに設定して、Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ（ＰｔｏＰ）通信などに使用することができる。この場合、たとえば、第１のＭＩＭＥ−Ｔｙｐｅ（ブロックヘッダを付加する、かつ、暗号化も実施する）を用いることができる。【０２０９】
（実施の形態５）
次に、本発明の実施の形態５について説明する。本実施の形態におけるパケット送受信部の構成を図１７に示すが、図１７は第４の実施例で述べた図１６の構成に類似ではあるが、入力系と出力系がそれぞれ２系統ある点が大きく異なる。【０２１０】
図１７は、代表的な構成要素として、外部入力１のＴＳ入力インタフェース部１３０１、外部入力２のＴＳ入力インタフェース部１３０２、ＴＳ−ＭＵＸ部１３０３、セキュアパケット送信処理部１３０４、伝送プロトコル処理部１３０５、受信プロトコル処理部１３０７、セキュアパケット受信処理部１３０８、ＴＳ−ＤＥＭＵＸ部１３０９、外部出力１のＴＳ出力インタフェース部１３１０、外部出力２のＴＳ出力インタフェース部１３１１とを備える。よって、以下では実施の形態４と同じ部分の説明は省略し、異なる部分のみを説明する。【０２１１】
立体画像を伝送する目的においては、図１７において、外部入力１と外部入力２に、それぞれ、左眼用映像、右眼用映像を入力する。ここで、入力される左眼用映像、右眼用映像は、ＭＰＥＧ−２やＨ．２６４エンコード時に左右の映像で映像フレーム同期または映像フィールド同期を取る。ＭＰＥＧ−２の場合はＩ−Ｐｉｃｔｕｒｅで２ｃｈ映像の映像同期を取り、Ｈ．２６４／ＡＶＣの場合はＩＤＲ−Ｐｉｃｔｕｒｅで２ｃｈ映像の同期を取ると、映像同期処理など信号処理が簡単にできるので、装置の低コスト化も図れる。なお、ＩＤＲとは、Ｉｎｓｔａｎｔａｎｅｏｕｓ  Ｄｅｃｏｄｉｎｇ  Ｒｅｆｒｅｓｈの略であり、Ｈ．２６４ではＳｅｑｕｅｎｃｅ（Ｐｉｃｔｕｒｅの集まりである動画）の先頭は、ＩＤＲピクチャである。【０２１２】
さらに、ＭＰＥＧ−２やＨ．２６４を用いた３Ｄ（立体）映像のエンコードにおいて、一般的に左眼用映像と右眼用映像は似ているので、左眼用映像は右眼用映像を参照してエンコードすれば、左眼用映像のビットレートを小さくできる。よって、この場合には、トータルとして、右眼用映像の約１．５倍のビットレートにおさえることができる。【０２１３】
（実施の形態６）
本発明の実施の形態６について説明する。本実施の形態におけるパケット送信部の構成を図１８に示すが、第２の実施例で説明した構成に類似している。ＴＳ外部入力がＨ．２６５エンコーダになっているところである。【０２１４】
図１８は、代表的な構成要素として、デジタルチューナ４０３、外部入力のＴＳ入力インタフェース部４０４、ＴＳ−ＭＵＸ部４０５、セキュアパケット送信処理部４０２、伝送プロトコル処理部４１９、Ｈ．２６４処理部１４０８、及び蓄積部１４０９から構成される。【０２１５】
Ｈ．２６４処理部１４０８は、映像符号化（Ｈ．２６４）モジュール１４０１、音声符号化モジュール１４０２、メタデータ符号化モジュール１４０３、ＶＣＬ（Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  Ｌａｙｅｒ）のＮＡＬ（Ｎｅｔｗｏｒｋ  Ａｂｓｔｒａｃｔｉｏｎ  Ｌａｙｅｒ）ユニット処理部１４０５、および、ｎｏｎ−ＶＣＬのＮＡＬユニット処理部１４０６を含むＮＡＬユニット処理部１４０４、ＮＡＬユニット処理部１６０４のＭＰＥＧ−ＰＥＳ出力をＰＥＳ／ＴＳ変換するＰＥＳ／ＴＳ変換部１４０７から構成される。【０２１６】
以下では既に説明した実施の形態と同じ部分の説明は省略し、異なる部分のみを説明する。【０２１７】
図１９は、図１８のＨ．２６４処理部１４０８の構成を、データを一時的に保持するための複数のバッファを明示して、より詳細に説明する図である。【０２１８】
図１９は、代表的な構成要素として、映像符号化部１５０１、ＶＣＬ−ＮＡＬユニットバッファ１５０２、音声符号化部１５０３、ＰＳ（Ｐａｒａｍｅｔｅｒ  Ｓｅｔ）バッファ１５０４、ＶＵＩ（Ｖｉｄｅｏ  Ｕｓａｂｉｌｉｔｙ  Ｉｎｆｏｒｍａｔｉｏｎ）バッファ（１５０５）、ＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ  Ｅｎｈａｎｃｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ）バッファ１５０６、ｎｏｎ−ＶＣＬ−ＮＡＬユニットバッファ１５０７、ＭＰＥＧ−ＴＳマッピング処理部１５０８などにより構成される。【０２１９】
ＳＥＩバッファ１５０６にはメタデータを入力することができる。メタデータは、Ｈ．２６４／ＡＶＣの場合には、ＳＥＩのＵｓｅｒ  Ｄａｔａ  Ｕｎｒｅｇｉｓｔｅｒｅｄ  ＳＥＩにメタデータを格納することができる。また、ＭＰＥＧ−２の場合には、ＥＳ（Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ）のＰｉｃｔｕｒｅ  ＨｅａｄｅｒのＵｓｅｒ  Ｄａｔａ領域に格納するか、ＰＳ（Ｐｒｏｇｒａｍ  Ｓｔｒｅａｍ）のＰｒｉｖａｔｅ  Ｓｔｒｅａｍに格納するか、ＴＳ（Ｔｒａｎｓｐｏｓｔ  Ｓｔｒｅａｍ）のＰｒｉｖａｔｅパケットにＰＩＤ指定により格納することができる。【０２２０】
メタデータの種類としては、図２０に示すように、一般的なメタデータ、デジタル放送を受信して、そのＳＩ（Ｓｅｒｖｉｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ；  番組配列情報）より得るメタデータ、ＥＰＧ提供事業者より得たＥＰＧ情報などのメタデータ、Ｉｎｔｅｒｎｅｔから得たＥＰＧなどのメタデータ、また、個人や撮影クルーなどでムービー撮影したＡＶコンテンツ（クリップなど）に関連付けたメタデータなどがある。ムービー撮影の場合、たとえば、日時、場所、撮影者、撮影イベントのジャンル、撮影イベント名などがある。【０２２１】
場所の場合、昔は測定が難しかったが、最近ではカーナビゲーションシステムでも実用化されている様に、ＧＰＳと３Ｄジャイロセンサーの組み合わせにより、ＧＰＳ電波が届かない場所でもより正確な位置を算出することができる。また場所の測定データを電子化された地図データとリンクさせ、住所で表現することもできる。また住所に限らず、各種のメタデータをタッチパネルなどから直接入力することも可能である。【０２２２】
これらメタデータを活用することにより、多くのＡＶコンテンツから所望のコンテンツを検索する、ライブラリに分類する、自動表示を行うなどコンテンツの効率的な利用が可能となる。【０２２３】
なお、現在次のような環境が整備され、メタデータの今後一層の多様化と流通促進とが期待される。【０２２４】
例えば、視聴者が作成したメタデータを提供する多くのテレビブログサイトがインターネット上に開設され（例えば、ｈｔｔｐ：／／ｗｗｗ．ｔｖｂｌｏｇ．ｊｐ／を参照）、また、既存の広報関連の番組情報はもちろん、番組の企画、収録、編集、編成、送出、アーカイブ（保存）など、放送に関する各段階で発生するメタデータの収集、加工、配信を請け負うサービスが開始されている（ｈｔｔｐ：／／ｗｗｗ．ｐｌａｔ−ｅａｓｅ．ｃｏ．ｊｐ／ｍｅｔａｄａｔａ．ｈｔｍを参照）。また、コンテンツの著作権処理の円滑化に資するメタデータ体系が、総務省によって策定されている（例えば、ｈｔｔｐ：／／ｗｗｗ．ｓｏｕｍｕ．ｇｏ．ｊｐ／ｓ−ｎｅｗｓ／２００３／０３０５２０＿４．ｈｔｍ、ｈｔｔｐ：／／ｗｗｗ．ｓｏｕｍｅ．ｇｏ．ｊｐ／ｓ−ｎｅｗｓ／２００３／ｐｄｆ／０３０５２０＿４＿０１．ｐｄｆを参照）。【０２２５】
さて、図１８において、デジタル放送で音楽番組を受信する場合、音楽番組をライブで別室に伝送する場合は、頭出しの必要はないが、デジタル放送で音楽番組を受信して、一旦、蓄積部１４０９に蓄積して、後ほど、音楽番組を視聴する場合、番組中に放送された複数の楽曲の中より所望の楽曲に簡単にアクセスしたいというユーザ要求がある。ところが、デジタル放送で音楽番組を受信しても、番組タイトルと、一部の楽曲名はＳＩのＥＰＧ情報（たとえば、ＥＩＴ：Ｅｖｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）から取得できるが、各楽曲の放送時間などの情報があいために、蓄積部より楽曲を再生する際に、簡単に所望の楽曲に簡単にアクセスできないという課題がある。【０２２６】
そこで、その解決のため、セキュアパケット送信処理部４０２内の管理制御部が、プロトコル処理部４１９を介して、図７に示した家庭内のルータからＩｎｔｅｒｎｅｔ上の楽曲情報サーバにアクセスして、該音楽番組内の楽曲情報（曲名、アーティスト名、アルバム名、ジャンル、演奏時間、放送時間、作詞、作曲、伴奏、楽曲の説明など）を取得する。そして、取得した該音楽番組内の楽曲情報と蓄積部１４０９に記録されている該音楽番組内の複数の楽曲とを該音楽番組（蓄積部上のファイル）のタイムレンジ情報（またはバイトレンジ情報）で関連付けた楽曲位置テーブルを作成し、蓄積部の楽曲位置テーブル格納用Ｄｉｒｅｃｔｏｒｙに記録する。よって、ユーザはＵＰｎＰ−ＡＶ  Ｓｅｒｖｉｃｅ）でブラウズ、サーチなどを行うと、該音楽番組タイトルのファイルの＜ｒｅｓ＞に対して、該音楽番組中の各楽曲に対して楽曲位置テーブルを用いることにより、ＨＴＴＰのタイムレンジ（バイトレンジ）指定で瞬時に所望の楽曲にアクセスすることができる。また、ＨＴＴＰでの楽曲アクセスに関して、たとえば、ＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）パラメータで楽曲名を指定すると、サーバ側で楽曲名から放送番組内の該楽曲の放送時刻を指定するアプリケーションを組むことにより、楽曲アクセスを実現することもできる。【０２２７】
また、Ｉｎｔｅｒｎｅｔより該音楽番組内の楽曲情報が取得できない場合には、各楽曲の波形データ（楽曲のサビなど）をＩｎｔｅｒｎｅｔ上の楽曲名解析サービスのサーバなどに問い合わせることにより、該音楽番組内の楽曲情報を取得することができる。【０２２８】
この方式は、さらに、音楽番組以外にも拡張できる。たとえば、映画、ドラマ、バラエティ番組、スポーツやニュースなどの放送番組を蓄積部に録画した場合、その映画に関するメタデータ、たとば、シーン情報（必見シーン、人気のあるシーン）などのメタデータをＩｎｔｅｒｎｅｔやデータ放送などのサービスより取得し、蓄積媒体に記録された映画のファイルと関連付けることにより、ユーザは瞬時に所望の映画シーンにアクセスすることができる。これらのメタデータはＩｎｒｅｒｎｅｔだけでなく、データ放送でも伝送することができる。【０２２９】
（実施の形態７）
本発明の実施の形態７について説明する。本実施の形態におけるパケット送受信部の構成を図２１に示す。図２１は実施の形態４で述べた図１６の構成に類似している。図２１は、代表的な構成要素として、ＡＶ信号やメタデータの入力部１７０１、ＨＤ（高解像度）符号化部１７０２、ＴＳ−ＭＵＸ／ＤＥＭＵＸ部１７０３、第１蓄積部１７０４、ＨＤ／低解像度変換部１７０５、セキュアパケット送受信処理部１７０６、伝送プロトコル処理部１７０７、ＩＰネットワーク１７０８、伝送プロトコル処理部１７０９、セキュアパケット送受信処理部１７１０、ＴＳ−ＭＵＸ／ＤＥＭＵＸ部１７１１、第２蓄積部１７１２、ＥＤＬ入力部１７１３、ＨＤ出力部１７１４などにより構成される。以下では既に説明した実施の形態と同じ部分の説明は省略し、異なる部分のみを説明する。【０２３０】
図２１において、ＨＤムービーで撮影したＭＰＥＧ−ＴＳ形式のＨＤコンテンツと、そのメタデータ（たとえば、図２０に記載したメタデータ）が入力部１７０１より入力され、ＴＳ−ＭＵＸ／ＤＥＭＵＸ部を経由して蓄積部１に蓄積される。ＨＤ／低解像度変換部１７０５は蓄積部１に蓄積されたＨＤコンテンツを低解像度（たとえば、水平画素数３２０、垂直画素数２４０のＱＶＧＡサイズ）で低ビットレートのコンテンツに変換する。【０２３１】
ＨＤムービーで撮影したＭＰＥＧ−ＴＳ形式のＨＤコンテンツをホームサーバに記録しておく。次に別室などのＰＣや携帯端末からネットワークを介してリモートで編集する場合、ＨＤコンテンツをＰＣや携帯端末に送るには、機器の処理負荷およびネットワーク負荷が大きくなる。【０２３２】
そこで、送信側の処理としては、まず、ＡＶ信号とＭｅｔａｄａｔａを入力し、ＨＤ符号化（同時に低解像度符号化）およびＴＳパケット化を行う。次に、ＴＳパケットを第１蓄積部１７０４に蓄積し、蓄積された低解像度コンテンツを受信側に送信する。【０２３３】
また、受信側の処理としては、まず、編集リスト（ＥＤＬ）を作成し、ＥＤＬを送信側に伝送する。次に、送信側は、受信したＥＤＬに基づいて編集されたＨＤコンテンツを受信側に伝送する。不必要な映像を削除することにより、受信側に伝送するデータ量を削減することができる。ここで、伝送プロトコルはＴＣＰ／ＩＰに限定されないで、一般のデジタルインタフェースでもよい。また、送信側でローカルに編集することもできる。【０２３４】
次に図２２を用いて、より具体的な実施例について説明する。ＨＤムービー１８０１で録画したコンテンツを携帯端末１８０２で編集し、ＥＤＬを作成する。携帯端末１８０２はこのＥＤＬをＨＤムービーに渡す。ＨＤムービーは、撮影したＨＤコンテンツとＥＤＬを、ＨＤＤを内蔵したＤＶＤレコーダ１８０３に渡す。ＴＶ受像機１８０４はリモコン１８０５からの指示で、ムービー１８０１または、ＤＶＤレコーダ１８０３内のコンテンツを呼び出す。この場合、タイトル選択だけでなく、携帯端末１８０２で作成したＥＤＬを用いることにより不要な部分を除いた撮影データを視聴することができる。また、ＤＶＤレコーダ１８０３は前記ＥＤＬに従って、撮影データを編集してファイルサイズを小さくすることができる。【０２３５】
また、図２２において、寝室のＴＶにおいて、寝室のＤＶＤレコーダ経由で、リビングルームのＤＶＤレコーダに存在するコンテンツを視聴する場合、寝室のＴＶは、リビングルームのＤＶＤレコーダに存在するコンテンツを選択する。さらに、選択したコンテンツのＥＤＬを取得して、そのＥＤＬに沿って撮影データをリモート視聴する。また、寝室のＤＶＤレコーダに、ＥＤＬに基づいて編集したＨＤコンテンツを受信側のＤＶＤレコーダに伝送する。以上のように、不必要な映像を削除することにより、受信側に伝送するデータ量を削減することができる。【０２３６】
なお、本実施例ではＨＴＴＰを用いたが、ＨＴＴＰの代わりにＲＴＰ用いてもよい。ＲＴＰの場合は、受信側がＲＴＣＰでＭＰＥＧファイルの伝送部分を指定すればよい。なお、この場合は、ＨＴＴＰのように伝送サイズの計算が複雑にならないというメリットがある。【０２３７】
また、ビデオ信号処理の例として、ＭＰＥＧ−ＴＳを用いたが、これに限らず本発明で用いる入力データの適用範囲としては、ＭＰＥＧ１／２／４などＭＰＥＧ−ＴＳストリーム（ＩＳＯ／ＩＥＣ１３８１８）、ＳＭＰＴＥ３１４Ｍ（ＤＶ−ｂａｓｅｄ）、ＳＭＰＴＥ２５９Ｍ規格で規定された非圧縮ＳＤ方式信号、ＳＭＰＴＥ２９２Ｍ規格で規定された非圧縮ＨＤ形式、ＩＥＣ６１８８３規格で規定されたＩＥＥＥ１３９４によるＤＶまたはデジタル放送のＭＰＥＧ−ＴＳの伝送ストリーム形式、ＤＶＢ規格Ａ０１０で規定されたＤＶＢ−ＡＳＩによるＭＰＥＧ−ＴＳ形式、ＭＰＥＧ−ＰＥＳ，ＭＰＥＧ−ＥＳ、ＭＰＥＧ４、ＩＳＯ／ＩＥＣ  Ｈ．２６４等で規格化されているストリ−ムを含んだあらゆる映像、音声に関するストリームにも適用可能である。映像や音声のデータレートは、ＣＢＲ（ｃｏｎｓｔａｎｔ  ｂｉｔ  ｒａｔｅ）に限るものではない。さらに、映像や音声だけでなく、一般のリアルタイムデータ、あるいは優先的に送受信を行うデータであればどのようなものでも本発明から排除するものではない。【０２３８】
また、上記実施の形態において、パケット送受信装置は、Ｎを２以上の整数とした場合、ＵＤＰまたはＴＣＰのＮ個のポートを用いて、ＡＶデータにより構成されるＮ個のプログラムを前記Ｎ個のポートのそれぞれに割り当てて伝送してもよい。このとき、Ｎ個のポートのそれぞれに割り当てるＮ個のプログラムは、それぞれ、ソースに内蔵された放送受信チューナまたは蓄積メディアデバイスをＵＰｎＰ部のコンテナ形式で表現し、また、放送受信チャネルまたは蓄積プログラムをＵＰｎＰ部のｉｔｅｍ形式で表現し、それぞれのｉｔｅｍ（リソースとしてのｒｅｓとなる）の存在位置をＵＲＩ、また伝送プロトコルや属性情報をＵＰｎＰのｐｒｏｔｏｃｏｌＩｎｆｏを用いたｒｅｓ表現で表わし、複数プログラムの複数クライアントへの同時伝送など、きめ細かい伝送システムを実現することができる。【０２３９】
また、放送受信の場合、送信側におけるＮ個のポートのそれぞれに割り当てるＮ個のプログラム（ｒｅｓ）のソースからシンクへの伝送ストリームが複数存在する場合に、各々のストリームをＵＰｎＰのｐｒｏｐｅｒｔｙ形式で表わし、特定の伝送ストリームのｐｒｏｐｅｒｔｙのａｔｔｒｉｂｕｔｅとして、「チューナのコンテナの種別、チューナのコンテナ種別ごとのチューナＩＤ、チューナで選局されたチャネルＩＤ、伝送ストリームの他クライアントとの共有・横取りに関する利用可否情報、ストリームを伝送するトランスポート層が使用するＴＣＰまたはＲＴＰのポート番号、シンクにおけるＵＰｎＰ−ＡＶ部のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがソースにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ部のｃｏｎｎｅｃｔｉｏｎＩＤ、ソースにおけるＵＰｎＰ−ＡＶ部のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがシンクにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶのｃｏｎｎｅｃｔｉｏｎＩＤ」のうち、いずれかを含めることにより、受信側（クライアント、シンク）から送信側（サーバ、ソース）内のチューナのチャネル選局を行なう時に、伝送ストリームのｐｒｏｐｅｒｔｙおよびそのａｔｔｒｉｂｕｔｅを参照することにより、伝送ストリームに空きあるか無いか、およびどのチューナの、どのチャネルが選局されているかを判別することができる。【０２４０】
たとえば、放送受信の場合のＵＰｎＰ−ＡＶコンテナ構造として、＜ｒｏｏｔ＞下に、チューナのコンテナを配置する。コンテナ種別としては、地上デジタル、ＢＳデジタル、１１０度広帯域ＣＳデジタルなどの放送システム別、各々チューナコンテナを割り当てる。この場合、各チューナコンテナの下にｉｔｅｍとして各放送システムのチャンネルを割り当てる。ＵＰｎＰのＣＤＳのｓｅｒｃｈやｂｒｏｗｓコマンドを用いて、受信側から送信側のチューナコンテナ、およびチューナコンテナ内のチャンネルｉｔｅｍを認識することができる。チャンネルとしてのｉｔｅｍは放送局より送信される付属情報を持つ。【０２４１】
同様に、蓄積コンテンツの再生の場合、送信側におけるＮ個のポートのそれぞれに割り当てるＮ個のプログラムのソースからシンクへの伝送ストリームが複数存在する場合に、ＵＰｎＰのｐｒｏｐｅｒｔｙ形式で表わし、特定の伝送ストリームのｐｒｏｐｅｒｔｙのａｔｔｒｉｂｕｔｅとして、「蓄積メディアデバイスのコンテナの種別、蓄積メディアデバイスのコンテナ種別ごとの蓄積メディアデバイスＩＤ、蓄積メディアデバイスで選択されたプログラムＩＤ、伝送ストリームの共有を含む利用可否情報、ストリームを伝送するトランスポート層が使用するＴＣＰまたはＲＴＰのポート番号、シンクにおけるＵＰｎＰ−ＡＶ部のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがソースにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ部のｃｏｎｎｅｃｔｉｏｎＩＤ、ソースにおけるＵＰｎＰ−ＡＶ部のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがシンクにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ部のｃｏｎｎｅｃｔｉｏｎＩＤ」のうち、いずれかを含めることにより、シンクがソース内の蓄積メディアデバイスのプログラム選択を行なう時に、伝送ストリームのｐｒｏｐｅｒｔｙおよびそのａｔｔｒｉｂｕｔｅを参照することにより、伝送ストリームに空きあるか無いか、およびどの蓄積メディアデバイスのどのプログラムが選択されているかなど判別することができる。【０２４２】
たとえば、蓄積・記録デバイスが、ハードディスクドライブ（ＨＤＤ）、ＤＶＤ−ＲＡＭドライブ、ＢＤドライブの場合のＵＰｎＰ−ＡＶコンテナ構造として、＜ｒｏｏｔ＞下に、それぞれのコンテナを配置する。コンテナ種別としては、ＨＤＤ、ＤＶＤ−ＲＡＭドライブ、ＢＤドライブなどそれぞれにデバイス別のコンテナを割り当てる。この場合、各コンテナの下にｉｔｅｍとして、蓄積・記録コンテンツをたとえばプログラム単位で割り当てる。これにより、ＵＰｎＰのＣＤＳのｓｅｒｃｈやｂｒｏｗｓコマンドを用いて、受信側から送信側の蓄積・記録デバイスコンテナ、および蓄積・記録デバイスコンテナ内の蓄積・記録コンテンツをたとえばプログラム単位でｉｔｅｍとして認識することができる。蓄積・記録されているｉｔｅｍは記録時に与えられた付属情報を持つ。【０２４３】
また、送信サーバの放送コンテナに所属するｉｔｅｍをクライアントが受信して蓄積する場合、前記放送システム別のチューナコンテナの属性（地上デジタル、ＢＳデジタル、１１０度広帯域ＣＳデジタルなどの放送システムを区別する属性）を利用して、放送システム別のｐｒｏｐｅｒｔｙを生成し、蓄積・記録デバイスに蓄積・記録して生成したｉｔｅｍのｐｒｏｐｅｒｔｙとして保存する。これにより、蓄積・記録デバイスのコンテナが放送システム別でなくても、蓄積・記録デバイスから再生したｉｔｅｍのｐｒｏｐｅｒｔｙを見れば、どの放送システムから放送されたコンテンツであるかを識別することができる。【０２４４】
以上により、放送受信の場合でも蓄積コンテンツの再生の場合でも、新たにサーバ接続するクライアントはサーバの使用状況を理解し、より効率的にコンテンツの選択、伝送を行うことができる。【０２４５】
なお、「ストリームを伝送するトランスポート層が使用するＴＣＰまたはＵＤＰのポート番号」、および、「シンクにおけるＵＰｎＰ−ＡＶ部のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがソースにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ部のｃｏｎｎｅｃｔｉｏｎＩＤ、またはソースにおけるＵＰｎＰ−ＡＶ部のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがシンクにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ部のｃｏｎｎｅｃｔｉｏｎＩＤ」の論理対により、ＵＰｎＰ−ＡＶ部と、ＴＣＰまたはＵＤＰを使用するＨＴＴＰまたはＲＴＰを用いるトランスポート部とを論理的に対応づけることにより、ＣＤＳやＣＭＳ（Ｃｏｎｎｅｃｔｉｏｎ  Ｍａｎａｇｅｒ  Ｓｅｒｖｉｃｅ）を用いるＵＰｎＰ−ＡＶレイヤとＨＴＴＰ／ＴＣＰ／ＩＰを取り扱うトランスポートレイヤを論理的に１対１に対応させることができるので、コネクションの確立、コンテンツの選択、コンテンツの伝送、コネクションの切断、存在コネクションの管理などの伝送制御をより簡単に実現することが可能となる。また、ＨＴＴＰのリクエストメッセージのメッセージヘッダの拡張フィールドや、ＨＴＴＰのレスポンスメッセージのメッセージヘッダの拡張フィールドにＵＰｎＰ−ＡＶ部のｃｏｎｎｅｃｔｉｏｎＩＤを記述することによりＨＴＴＰプロトコルによる伝送制御部とＵＰｎＰ−ＡＶ部と論理的に１対１対応させることができる。
【産業上の利用可能性】
【０２４６】
本発明は、地上デジタル放送などを受信・番組選局したコンテンツや、ＨＤ、ムービーで録画したコンテンツを宅内のＩＰネットワークにより別室のテレビやパソコンに伝送し、リモート視聴を可能にする。また、前述したコンテンツをＨＤＤやＤＶＤディスクに記録し、別室よりＩＰネットワークを介して記録コンテンツのタイトル選択や、特殊再生を実現しながら、リモート視聴を可能とする。
【図１】
2007010779.tif 000002
【図２】
2007010779.tif 000003
【図３】
2007010779.tif 000004
【図４】
2007010779.tif 000005
【図５】
2007010779.tif 000006
【図６】
2007010779.tif 000007
【図７】
2007010779.tif 000008
【図８】
2007010779.tif 000009
【図９】
2007010779.tif 000010
【図１０】
2007010779.tif 000011
【図１１】
2007010779.tif 000012
【図１２】
2007010779.tif 000013
【図１３】
2007010779.tif 000014
【図１４】
2007010779.tif 000015
【図１５】
2007010779.tif 000016
【図１６】
2007010779.tif 000017
【図１７】
2007010779.tif 000018
【図１８】
2007010779.tif 000019
【図１９】
2007010779.tif 000020
【図２０】
2007010779.tif 000021
【図２１】
2007010779.tif 000022
【図２２】
2007010779.tif 000023
【手続補正書】
【提出日】平成18年10月17日(2006.10.17)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求の範囲
【補正方法】変更
【補正の内容】
【書類名】請求の範囲
【請求項１】各々が独自のプログラム情報を持つ複数の放送チャンネルを受信し、受信した複数の放送チャンネルの中から特定の放送チャンネルの入力ストリームを取得する受信手段と、
前記取得された入力ストリームから第１のプログラム情報を抽出すると共に、事前に設定した前記特定の放送チャンネルとは異なる放送チャンネルの受信信号及び通信ネットワーク経由の入力信号のうちの少なくとも一方から、前記特定の放送チャンネルの番組に関する第２のプログラム情報を取得するプログラム情報取得手段と、
前記第１のプログラム情報及び前記第２のプログラム情報の一方を選択するか又は両方を合成して、前記番組に関する新たなプログラム情報を再構成するプログラム情報再構成手段と、
前記再構成された新たなプログラム情報を用いて前記取得された入力ストリームにフィルタリング処理を行うフィルタリング手段と、
前記フィルタリング後の前記入力ストリームを含む新たな出力ストリームを構成し、構成された出力ストリームをパケット化して外部へ送信する送信手段と
を備えることを特徴とするパケット送信装置。
【請求項２】前記取得された入力ストリームから、その入力ストリームに含まれるコンテンツデータのデータフォーマットを示すデータフォーマット情報、又は前記コンテンツデータの属性を示す属性情報を検出する信号フォーマット及びプロパティ検出手段と、
前記検出されたデータフォーマット情報又は属性情報をトランスポートパケットにカプセル化するカプセル化手段と、
前記取得された入力ストリームに含まれるコンテンツデータに関するデスクリプタを生成し、前記入力ストリームに挿入するデスクリプタ挿入手段と、
前記カプセル化されたトランスポートパケットと、前記デスクリプタ挿入後の入力ストリームのトランスポートパケットとを、後者に比べて前者へより大きな遅延を与えて多重化すると共に、それぞれのトランスポートパケットにタイムスタンプを付加することにより、パーシャルトランスポートストリームを生成するパーシャルトランスポートストリーム生成手段と、
前記生成されたパーシャルトランスポートストリームのトランスポートパケットを所定の大きさの伝送パケットペイロードに変換するデータブロック化手段と、
前記所定の大きさを表すサイズ情報を含むと共に、前記検出されたデータフォーマット情報又は属性情報が前記コンテンツデータの伝送、複製、又は再生に関する制御情報である場合にはその制御情報を含む伝送パケットヘッダを生成する伝送パケットヘッダ生成手段と、
前記変換された伝送パケットペイロードと、前記生成された伝送パケットヘッダとを結合することにより、伝送パケットを生成する伝送パケット生成手段と
を備えることを特徴とする請求項１に記載のパケット送信装置。
【請求項３】  前記属性情報は、放送システムの種別、放送ネットワーク識別、放送の編成チャンネル情報、番組名、番組のジャンル、チャンネル番号、番組の開始時間、番組の終了時間、番組の説明記述のうち少なくとも一つを表す
ことを特徴とする請求項２記載のパケット送信装置。
【請求項４】前記取得された入力ストリームがフルトランスポートストリームの場合には、前記伝送パケットペイロードの大きさはそのフルトランスポートストリームを受信した時間長で指定され、
前記取得された入力ストリームがパーシャルトランスポートストリームの場合には、前記伝送パケットペイロードの大きさは時間長またはバイト長で指定される
ことを特徴とする請求項２記載のパケット送信装置。
【請求項５】前記デスクリプタ挿入手段は、前記取得された入力ストリームに含まれる、放送システムの種別、放送ネットワーク識別、放送の編成チャンネル情報、コピー制御情報のうち少なくとも１つの情報を制御情報として用いて、ＤＴＣＰ＿ｄｅｓｃｉｐｔｏｒまたはＤＴＣＰ＿ａｕｄｉｏ＿ｄｅｓｃｒｉｐｔｏｒを生成し、生成したＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒまたは前記ＤＴＣＰ＿ａｕｄｉｏ＿ｄｅｓｃｒｉｐｔｏｒを前記入力ストリームのＰｒｏｇｒａｍ  Ｍａｐ  Ｔａｂｌｅに挿入する
ことを特徴とする請求項２記載のパケット送信装置。
【請求項６】前記カプセル化手段は、前記取得された入力ストリームの単位プログラムのコピー制御情報の内容に係わらず、同じデータフォーマット情報または同じＭＩＭＥ−Ｔｙｐｅをトランスポートパケットにカプセル化する
ことを特徴とする請求項５記載のパケット送信装置。
【請求項７】  ＨＴＴＰプロトコルによるデータ伝送の対象を、ＭＰＥＧのＧＯＰ、ピクチャ、スライス、マクロブロック、ブロック、ＴＳパケット、タイムスタンプを付加したＴＳパケット、又は、記録メディアのセクタサイズ、クラスタサイズ、論理ブロックサイズのいずれかの単位で指定したデータリクエストを外部から受け付ける
ことを特徴とする請求項２記載のパケット送信装置。
【請求項８】さらに、前記取得された入力ストリームに含まれるコンテンツデータの表現形式をＭＰＥＧ−２とＨ．２６４との間で形式変換するトランスコーダを備え、
前記トランスコーダによって形式変換された後の入力ストリームをパーシャルトランスポートにして出力する
ことを特徴とする請求項２記載のパケット送信装置。
【請求項９】さらに、前記取得された入力ストリームをファイルとして蓄積する蓄積手段を備える
ことを特徴とする請求項２記載のパケット送信装置。
【請求項１０】  再生時に、ファイル内での位置情報管理表で指定された各コンテンツにアクセスするために、
各コンテンツに含まれる１つ以上のフレーム画像を構成するタイトルデータ又は画像データのいずれかをＩｎｔｅｒｎｅｔ上のコンテンツ情報サービスに問い合わせ、該コンテンツが含む１つ以上のシーンに関するメタデータ又は放送日時データを取得し、前記取得データを前記蓄積手段に記録されている該コンテンツの記録管理情報にリンクさせたコンテンツ詳細内容テーブルを作成する手段と、再生の際には前記コンテンツ詳細内容テーブルを参照してコンテンツ内の各シーンにアクセスする手段を備える
ことを特徴とする請求項９記載のパケット送信装置。
【請求項１１】  前記蓄積手段に高解像度のコンテンツとそのメタデータが蓄積されている場合、前記高解像度コンテンツを低解像度コンテンツに変換する手段をさらに備え、
受信側はネットワークを介して前記高解像度コンテンツから変換された前記低解像度コンテンツを受信し、前記低解像度コンテンツよりコンテンツ選択・取得リストを作成した後、前記コンテンツ選択・取得リストを送信側に伝送し、
送信側は受信したコンテンツ選択・取得リストに基づき高解像度コンテンツを受信側に伝送する手段を備える
ことを特徴とする請求項９記載のパケット送信装置。
【請求項１２】前記制御手段は、前記蓄積手段に蓄積されている前記ファイルが音楽に関するコンテンツを含んでいる場合、
Ｉｎｔｅｒｎｅｔ上の楽曲情報サーバにアクセスして、該音楽番組内の楽曲情報を取得し、取得した該音楽に関係したファイル内の楽曲情報と蓄積手段に記録されている該音楽に関するファイル内の複数の楽曲とを該音楽番組のタイムレンジ情報で関連付けた楽曲位置テーブルを作成し、蓄積手段の楽曲位置テーブル格納用ディレクトリに記録し、再生の際には前記楽曲位置テーブルを持つファイル内の各楽曲にアクセスする手段を備える
ことを特徴とする請求項９記載のパケット送信装置。
【請求項１３】  外音楽番組中の各楽曲に対してＵＰｎＰ−ＡＶのコンテンツディレクトリサービスでブラウズ、サーチなどを行うと、該音楽番組タイトルのファイル又はＵＰｎＰの＜ｒｅｓ＞内の各楽曲に対する前記楽曲位置テーブルにアクセスする手段を備える
ことを特徴とする請求項１２記載のパケット送信装置。
【請求項１４】  再生時に前記楽曲位置テーブルを持つファイル内の各楽曲にアクセスするために、
受信装置よりＣＧＩにパラメータとして楽曲名を指定して、送信装置に送り、送信装置では前記ＣＧＩのパラメータを利用して前記ファイルより各楽曲にアクセスする手段を備える
ことを特徴とする請求項１２記載のパケット送信装置。
【請求項１５】  左眼用映像、右眼用映像をそれぞれＨ．２６４信号に符号化するＨ．２６４エンコーダと前Ｈ．２６４エンコーダの出力をトランスポートストリームパケットに変換する手段とを備え、前記Ｈ．２６４エンコーダでのエンコードの際、２ｃｈ映像はお互いに時間的に最も近いフレームでＨ．２６４のＩＤＲピクチャを構成するようにエンコードして２チャンネル映像の同期を取り、請求項１で記載したパケット送信装置２台に２つのトランスポートストリームパケットをそれぞれ入力する手段を備える
ことを特徴とする請求項２記載のパケット送信装置。
【請求項１６】  前記左眼用映像、前記右眼用映像をそれぞれＨ．２６４信号に符号化する際、何れか一方の映像は他方の映像を参照することにより、何れか一方の映像はＢピクチャ又はＰピクチャにのみ符号化する手段を備える
ことを特徴とする請求項１５記載のパケット送信装置。
【請求項１７】各々が独自のプログラム情報を持つ複数の放送チャンネルを受信し、受信した複数の放送チャンネルの中から特定の放送チャンネルの入力ストリームを取得する受信ステップと、
前記取得された入力ストリームから第１のプログラム情報を抽出すると共に、事前に設定した前記特定の放送チャンネルとは異なる放送チャンネルの受信信号及び通信ネットワーク経由の入力信号のうちの少なくとも一方から、前記特定の放送チャンネルの番組に関する第２のプログラム情報を取得するプログラム情報取得ステップと、
前記第１のプログラム情報及び前記第２のプログラム情報の一方を選択するか又は両方を合成して、前記番組に関する新たなプログラム情報を再構成するプログラム情報再構成ステップと、
前記再構成された新たなプログラム情報を用いて前記取得された入力ストリームにフィルタリング処理を行うフィルタリングステップと、
前記フィルタリング後の前記入力ストリームを含む新たな出力ストリームを構成し、構成された出力ストリームをパケット化して外部へ送信する送信ステップと
を備えることを特徴とするパケット送信方法。
【請求項１８】パケット送信を行うためのコンピュータ実行可能なプログラムであって、
各々が独自のプログラム情報を持つ複数の放送チャンネルを受信し、受信した複数の放送チャンネルの中から特定の放送チャンネルの入力ストリームを取得する受信ステップと、
前記取得された入力ストリームから第１のプログラム情報を抽出すると共に、事前に設定した前記特定の放送チャンネルとは異なる放送チャンネルの受信信号及び通信ネットワーク経由の入力信号のうちの少なくとも一方から、前記特定の放送チャンネルの番組に関する第２のプログラム情報を取得するプログラム情報取得ステップと、
前記第１のプログラム情報及び前記第２のプログラム情報の一方を選択するか又は両方を合成して、前記番組に関する新たなプログラム情報を再構成するプログラム情報再構成ステップと、
前記再構成された新たなプログラム情報を用いて前記取得された入力ストリームにフィルタリング処理を行うフィルタリングステップと、
前記フィルタリング後の前記入力ストリームを含む新たな出力ストリームを構成し、構成された出力ストリームをパケット化して外部へ送信する送信ステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項１９】  請求項１８に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【手続補正書】
【提出日】平成20年1月23日(2008.1.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
各々が独自のプログラム情報を持つ複数の放送チャンネルを受信し、受信した複数の放送チャンネルの中から特定の放送チャンネルの入力ストリームを取得する受信手段と、
前記取得された入力ストリームから第１のプログラム情報を抽出すると共に、事前に設定した前記特定の放送チャンネルとは異なる放送チャンネルの受信信号及び通信ネットワーク経由の入力信号のうちの少なくとも一方から、前記特定の放送チャンネルの番組に関する第２のプログラム情報を取得するプログラム情報取得手段と、
前記第１のプログラム情報及び前記第２のプログラム情報の一方を選択するか又は両方を合成して、前記番組に関する新たなプログラム情報を再構成するプログラム情報再構成手段と、
前記再構成された新たなプログラム情報を用いて前記取得された入力ストリームにフィルタリング処理を行うフィルタリング手段と、
前記フィルタリング後の前記入力ストリームを含む新たな出力ストリームを構成し、構成された出力ストリームをパケット化して外部へ送信する送信手段と
を備えることを特徴とするパケット送信装置。
【請求項２】
前記取得された入力ストリームから、その入力ストリームに含まれるコンテンツデータのデータフォーマットを示すデータフォーマット情報、又は前記コンテンツデータの属性を示す属性情報を検出する信号フォーマット及びプロパティ検出手段と、
前記検出されたデータフォーマット情報又は属性情報をトランスポートパケットにカプセル化するカプセル化手段と、
前記取得された入力ストリームに含まれるコンテンツデータに関するデスクリプタを生成し、前記入力ストリームに挿入するデスクリプタ挿入手段と、
前記カプセル化されたトランスポートパケットと、前記デスクリプタ挿入後の入力ストリームのトランスポートパケットとを、後者に比べて前者へより大きな遅延を与えて多重化すると共に、それぞれのトランスポートパケットにタイムスタンプを付加することにより、パーシャルトランスポートストリームを生成するパーシャルトランスポートストリーム生成手段と、
前記生成されたパーシャルトランスポートストリームのトランスポートパケットを所定の大きさの伝送パケットペイロードに変換するデータブロック化手段と、
前記所定の大きさを表すサイズ情報を含むと共に、前記検出されたデータフォーマット情報又は属性情報が前記コンテンツデータの伝送、複製、又は再生に関する制御情報である場合にはその制御情報を含む伝送パケットヘッダを生成する伝送パケットヘッダ生成手段と、
前記変換された伝送パケットペイロードと、前記生成された伝送パケットヘッダとを結合することにより、伝送パケットを生成する伝送パケット生成手段と
を備えることを特徴とする請求項１に記載のパケット送信装置。
【請求項３】
前記属性情報は、放送システムの種別、放送ネットワーク識別、放送の編成チャンネル情報、番組名、番組のジャンル、チャンネル番号、番組の開始時間、番組の終了時間、番組の説明記述のうち少なくとも一つを表す
ことを特徴とする請求項２記載のパケット送信装置。
【請求項４】
前記取得された入力ストリームがフルトランスポートストリームの場合には、前記伝送パケットペイロードの大きさはそのフルトランスポートストリームを受信した時間長で指定され、
前記取得された入力ストリームがパーシャルトランスポートストリームの場合には、前記伝送パケットペイロードの大きさは時間長またはバイト長で指定される
ことを特徴とする請求項２記載のパケット送信装置。
【請求項５】
前記デスクリプタ挿入手段は、前記取得された入力ストリームに含まれる、放送システムの種別、放送ネットワーク識別、放送の編成チャンネル情報、コピー制御情報のうち少なくとも１つの情報を制御情報として用いて、ＤＴＣＰ＿ｄｅｓｃｉｐｔｏｒまたはＤＴＣＰ＿ａｕｄｉｏ＿ｄｅｓｃｒｉｐｔｏｒを生成し、生成したＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒまたは前記ＤＴＣＰ＿ａｕｄｉｏ＿ｄｅｓｃｒｉｐｔｏｒを前記入力ストリームのＰｒｏｇｒａｍ  Ｍａｐ  Ｔａｂｌｅに挿入する
ことを特徴とする請求項２記載のパケット送信装置。
【請求項６】
前記カプセル化手段は、前記取得された入力ストリームの単位プログラムのコピー制御情報の内容に係わらず、同じデータフォーマット情報または同じＭＩＭＥ−Ｔｙｐｅをトランスポートパケットにカプセル化する
ことを特徴とする請求項５記載のパケット送信装置。
【請求項７】
ＨＴＴＰプロトコルによるデータ伝送の対象を、ＭＰＥＧのＧＯＰ、ピクチャ、スライス、マクロブロック、ブロック、ＴＳパケット、タイムスタンプを付加したＴＳパケット、又は、記録メディアのセクタサイズ、クラスタサイズ、論理ブロックサイズのいずれかの単位で指定したデータリクエストを外部から受け付ける
ことを特徴とする請求項２記載のパケット送信装置。
【請求項８】
さらに、前記取得された入力ストリームに含まれるコンテンツデータの表現形式をＭＰＥＧ−２とＨ．２６４との間で形式変換するトランスコーダを備え、
前記トランスコーダによって形式変換された後の入力ストリームをパーシャルトランスポートにして出力する
ことを特徴とする請求項２記載のパケット送信装置。
【請求項９】
さらに、前記取得された入力ストリームをファイルとして蓄積する蓄積手段を備える
ことを特徴とする請求項２記載のパケット送信装置。
【請求項１０】
再生時に、ファイル内での位置情報管理表で指定された各コンテンツにアクセスするために、
各コンテンツに含まれる１つ以上のフレーム画像を構成するタイトルデータ又は画像データのいずれかをＩｎｔｅｒｎｅｔ上のコンテンツ情報サービスに問い合わせ、該コンテンツが含む１つ以上のシーンに関するメタデータ又は放送日時データを取得し、前記取得データを前記蓄積手段に記録されている該コンテンツの記録管理情報にリンクさせたコンテンツ詳細内容テーブルを作成する手段と、再生の際には前記コンテンツ詳細内容テーブルを参照してコンテンツ内の各シーンにアクセスする手段を備える
ことを特徴とする請求項９記載のパケット送信装置。
【請求項１１】
前記蓄積手段に高解像度のコンテンツとそのメタデータが蓄積されている場合、前記高解像度コンテンツを低解像度コンテンツに変換する手段をさらに備え、
受信側はネットワークを介して前記高解像度コンテンツから変換された前記低解像度コンテンツを受信し、前記低解像度コンテンツよりコンテンツ選択・取得リストを作成した後、前記コンテンツ選択・取得リストを送信側に伝送し、
送信側は受信したコンテンツ選択・取得リストに基づき高解像度コンテンツを受信側に伝送する手段を備える
ことを特徴とする請求項９記載のパケット送信装置。
【請求項１２】
前記制御手段は、前記蓄積手段に蓄積されている前記ファイルが音楽に関するコンテンツを含んでいる場合、
Ｉｎｔｅｒｎｅｔ上の楽曲情報サーバにアクセスして、該音楽番組内の楽曲情報を取得し、取得した該音楽に関係したファイル内の楽曲情報と蓄積手段に記録されている該音楽に関するファイル内の複数の楽曲とを該音楽番組のタイムレンジ情報で関連付けた楽曲位置テーブルを作成し、蓄積手段の楽曲位置テーブル格納用ディレクトリに記録し、再生の際には前記楽曲位置テーブルを持つファイル内の各楽曲にアクセスする手段を備える
ことを特徴とする請求項９記載のパケット送信装置。
【請求項１３】
該音楽番組中の各楽曲に対してＵＰｎＰ−ＡＶのコンテンツディレクトリサービスでブラウズ、サーチなどを行うと、該音楽番組タイトルのファイル又はＵＰｎＰの＜ｒｅｓ＞内の各楽曲に対する前記楽曲位置テーブルにアクセスする手段を備える
ことを特徴とする請求項１２記載のパケット送信装置。
【請求項１４】
再生時に前記楽曲位置テーブルを持つファイル内の各楽曲にアクセスするために、
受信装置よりＣＧＩにパラメータとして楽曲名を指定して、送信装置に送り、送信装置では前記ＣＧＩのパラメータを利用して前記ファイルより各楽曲にアクセスする手段を備える
ことを特徴とする請求項１２記載のパケット送信装置。
【請求項１５】
左眼用映像、右眼用映像をそれぞれＨ．２６４信号に符号化するＨ．２６４エンコーダと前記Ｈ．２６４エンコーダの出力をトランスポートストリームパケットに変換する手段とを備え、前記Ｈ．２６４エンコーダでのエンコードの際、２ｃｈ映像はお互いに時間的に最も近いフレームでＨ．２６４のＩＤＲピクチャを構成するようにエンコードして２チャンネル映像の同期を取り、請求項１で記載したパケット送信装置２台に２つのトランスポートストリームパケットをそれぞれ入力する手段を備える
ことを特徴とする請求項２記載のパケット送信装置。
【請求項１６】
前記左眼用映像、前記右眼用映像をそれぞれＨ．２６４信号に符号化する際、何れか一方の映像は他方の映像を参照することにより、何れか一方の映像はＢピクチャ又はＰピクチャにのみ符号化する手段を備える
ことを特徴とする請求項１５記載のパケット送信装置。
【請求項１７】
各々が独自のプログラム情報を持つ複数の放送チャンネルを受信し、受信した複数の放送チャンネルの中から特定の放送チャンネルの入力ストリームを取得する受信ステップと、
前記取得された入力ストリームから第１のプログラム情報を抽出すると共に、事前に設定した前記特定の放送チャンネルとは異なる放送チャンネルの受信信号及び通信ネットワーク経由の入力信号のうちの少なくとも一方から、前記特定の放送チャンネルの番組に関する第２のプログラム情報を取得するプログラム情報取得ステップと、
前記第１のプログラム情報及び前記第２のプログラム情報の一方を選択するか又は両方を合成して、前記番組に関する新たなプログラム情報を再構成するプログラム情報再構成ステップと、
前記再構成された新たなプログラム情報を用いて前記取得された入力ストリームにフィルタリング処理を行うフィルタリングステップと、
前記フィルタリング後の前記入力ストリームを含む新たな出力ストリームを構成し、構成された出力ストリームをパケット化して外部へ送信する送信ステップと
を備えることを特徴とするパケット送信方法。
【請求項１８】
パケット送信を行うためのコンピュータ実行可能なプログラムであって、
各々が独自のプログラム情報を持つ複数の放送チャンネルを受信し、受信した複数の放送チャンネルの中から特定の放送チャンネルの入力ストリームを取得する受信ステップと、
前記取得された入力ストリームから第１のプログラム情報を抽出すると共に、事前に設定した前記特定の放送チャンネルとは異なる放送チャンネルの受信信号及び通信ネットワーク経由の入力信号のうちの少なくとも一方から、前記特定の放送チャンネルの番組に関する第２のプログラム情報を取得するプログラム情報取得ステップと、
前記第１のプログラム情報及び前記第２のプログラム情報の一方を選択するか又は両方を合成して、前記番組に関する新たなプログラム情報を再構成するプログラム情報再構成ステップと、
前記再構成された新たなプログラム情報を用いて前記取得された入力ストリームにフィルタリング処理を行うフィルタリングステップと、
前記フィルタリング後の前記入力ストリームを含む新たな出力ストリームを構成し、構成された出力ストリームをパケット化して外部へ送信する送信ステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項１９】
請求項１８に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＥＥＥ８０２．３などのイーサネット（登録商標）などの有線ＬＡＮやＩＥＥＥ８０２．１１などの無線ＬＡＮなどを用いて、ＭＰＥＧ−２やＨ．２６４などで圧縮されたＡＶストリームを暗号化した後、ＩＰパケット化して高品質に送信するパケット送信装置に関する。
【背景技術】
【０００２】
デジタルＴＶ放送の開始に伴い、家庭でも手軽にハイビジョン品質（ＨＤ品質）のＴＶ視聴が可能となり、現在、ＴＶ受信機の普及が加速している。
【０００３】
一方、近年、通信やネットワーク技術の発展に伴い、効率よくパケットを伝送するために様々な技術が提案されている（例えば、特許文献１参照）。その一つとして、従来、一般家庭において、部屋内でデジタル放送チューナやＤＶＨＳ方式ビデオレコーダ間をＩＥＥＥ  １３９４方式デジタルインターフェースで接続し、ＩＥＣ  ６１８８３−４で規定されたＭＰＥＧ−ＴＳ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ、Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ）信号の伝送が行われている。ここで、放送コンテンツにコピーワンジェネレーション（Ｃｏｐｙ  Ｏｎｅ  Ｇｅｎｅｒａｔｉｏｎ、ＣＯＧと略す）などのコピー制御モードでコンテンツ保護がかかっている場合、コンテンツを不正コピーから保護するため、コンテンツを暗号化してセキュアに伝送する必要がある。
【０００４】
この様にデジタル放送を受信・選局して得られたパーシャルＭＰＥＧ−ＴＳなどのＡＶデータを暗号化して伝送する方式の一例として、ＤＴＣＰ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ）方式が規定されている。ＤＴＣＰは、ＩＥＥＥ１３９４やＵＳＢなどの伝送メディア上のコンテンツ保護技術である。ＤＴＣＰ方式は、ＤＴＬＡ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｌｉｃｅｎｃｉｎｇ  Ａｄｍｉｎｉｓｔｒａｔｏｒ）で規格化された方式であり、  ＨＹＰＥＲＬＩＮＫ“ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ”  ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ、  ＨＹＰＥＲＬＩＮＫ  “ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｄｔｃｐ＃ｔｕｔ．ｐｄｆ”  ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｄｔｃｐ＃ｔｕｔ．ｐｄｆ、ＨＹＰＥＲＬＩＮＫ  “ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｗｐ＃ｓｐｅｃ．ｐｄｆ”  ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｗｐ＃ｓｐｅｃ．ｐｄｆや、書籍「ＩＥＥＥ１３９４、ＡＶ機器への応用」、高田信司監修、日刊工業新聞社、「第８章、コピープロテクション」、１３３〜１４９ページで説明されている。
【０００５】
ここで、ＭＰＥＧトランスポートストリーム（ＭＰＥＧ−ＴＳと略す）について説明する。ＭＰＥＧ−ＴＳはＭＰＥＧトランスポートパケット（ＴＳパケットと略す）が複数個集まったものである。ＴＳパケットは１８８ｂｙｔｅの固定長パケットで、その長さはＡＴＭのセル長（５３バイト中、ＡＴＭペイロードは４７バイト）との整合性、およびリードソロモン符号などの誤り訂正符号化を行なう場合の適用性を考慮して決定されている。
【０００６】
ＴＳパケットは４ｂｙｔｅ固定長のパケットヘッダと可変長のアダプテーションフィールド（ａｄａｐｔａｔｉｏｎ  ｆｉｅｌｄ）およびペイロード（ｐａｙｌｏａｄ）で構成される。パケットヘッダにはＰＩＤ（パケット識別子）や各種フラグが定義されている。このＰＩＤによりＴＳパケットの種類を識別する。ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄとｐａｙｌｏａｄは、片方のみが存在する場合と両方が存在する場合とがあり、その有無はパケットヘッダ内のフラグ（ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄ＿ｃｏｎｔｒｏｌ）により識別できる。ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄは、ＰＣＲ（Ｐｒｏｇｒａｍ＿Ｃｌｏｃｋ＿Ｒｅｆｅｒｅｎｃｅ）等の情報伝送、および、ＴＳパケットを１８８ｂｙｔｅ固定長にするためのＴＳパケット内でのスタッフィング機能を持つ。また、ＭＰＥＧ−２の場合、ＰＣＲは２７ＭＨｚのタイムスタンプで、符号化時の基準時間を復号器のＳＴＣ（Ｓｙｓｔｅｍ  Ｔｉｍｅ  Ｃｌｏｃｋ）で再現するためにＰＣＲ値が参照される。各ＴＳパケットに付加するタイムスタンプのクロックは、たとえば、ＭＰＥＧのシステムクロック周波数に等しく、パケット送信装置はさらに、ＴＳパケットを受信し、受信したＴＳパケットに付加されたタイムスタンプより、ＭＰＥＧ−ＴＳのネットワーク伝送によりＰｒｏｇｒａｍ  Ｃｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ（ＰＣＲ）に付加された伝送ジッターを除去して、ＭＰＥＧシステムクロックの再生を行うクロック再生手段を備える。
【０００７】
ＭＰＥＧ−２のＴＳでは復号器のＳＴＣはＰＣＲによるＰＬＬ同期機能を持つ。このＰＬＬ同期の動作を安定させるためにＰＣＲの送信間隔は、ＭＰＥＧ規格で１００ｍｓｅｃ以内と決められている。映像や音声などの個別ストリームが収められたＭＰＥＧ−ＰＥＳパケットは同じＰＩＤ番号を持つ複数のＴＳパケットのペイロードに分割して伝送する。ここで、ＰＥＳパケットの先頭は、ＴＳパケットの先頭から開始するように構成される。
【０００８】
トランスポートストリームは複数のプログラムを混合して伝送することができるため、ストリームに含まれているプログラムとそのプログラムを構成している映像や音声ストリームなどのプログラムの要素との関係を表すテーブル情報が用いられる。このテーブル情報はＰＳＩ（Ｐｒｏｇｒａｍ  Ｓｐｅｃｉｆｉｃ  Ｉｎｆｏｒｍａｔｉｏｎ）と呼ばれ、ＰＡＴ（Ｐｒｏｇｒａｍ  Ａｓｓｏｃｉａｔｉｏｎ  Ｔａｂｌｅ）、ＰＭＴ（Ｐｒｏｇｒａｍ  Ｍａｐ  Ｔａｂｌｅ）などのテーブルを用いる。ＰＡＴ、ＰＭＴなどのＰＳＩはセクションと呼ばれる単位でＴＳパケット中のペイロードに配置されて伝送される。
【０００９】
ＰＡＴにはプログラム番号に対応したＰＭＴのＰＩＤなどが指定されており、ＰＭＴには対応するプログラムに含まれる映像、音声、付加データおよびＰＣＲのＰＩＤが記述されるため、ＰＡＴとＰＭＴを参照することにより、ストリームの中から目的のプログラムを構成するＴＳパケットを取り出すことができる。ＴＳに関する参考文献としては、例えば、ＣＱ出版社、ＴＥＣＨ  Ｉ  Ｖｏ．４、「画像＆音声圧縮技術のすべて（インターネット／ディジタルテレビ、モバイル通信時代の必須技術）」、監修、藤原洋、第６章、「画像や音声を多重化するＭＰＥＧシステム」があり、同書にて解説されている。
【００１０】
ＰＳＩやＳＩに関する論理的な階層構造、処理手順の例、選局処理の例に関して、「ディジタル放送受信機における選局技術」、三宅他、三洋電機技報、ＶＯＬ．３６、ＪＵＮＥ  ２００４、第７４号、３１ページから４４ページにて解説されている。
【００１１】
また、デジタル放送で使用されるアクセス制御方式に関し、スクランブル、関連情報の仕様及びそれに関わる受信機仕様については、ＡＲＩＢ規格、ＡＲＩＢ  ＳＴＤ−Ｂ２５において規定されており、その運用については、ＡＲＩＢ技術資料、ＡＲＩＢ  ＴＲ−Ｂ１４およびＡＲＩＢ  ＴＲ−Ｂ１５において規定されている。
【００１２】
図１（ａ）は、ＤＴＣＰ方式を用い、ＭＰＥＧ―ＴＳをＩＥＥＥ１３９４で伝送する一例を模式的に表した図面である。ＤＴＣＰ方式では、送信側（パケット送信機器）をソース１９０１、受信側（パケット受信機器）をシンク１９０２と呼び、暗号化したＭＰＥＧ−ＴＳなどのコンテンツをソース１９０１からネットワーク１９０３を介して、シンク１９０２へ伝送している。図１（ｂ）に、補足情報として、ソース機器およびシンク機器の例を併記する。
【００１３】
図２は、ＤＴＣＰ方式における従来のパケット通信部の概略を説明する図であり、ここでは、図１のソース１９０１が備えるパケット送信部およびシンク１９０２が備えるパケット受信部の両方がパケット送受信部として示されている。まず、ＤＴＣＰ方式に準拠した認証と鍵交換（Ａｕｔｈｅｎｔｉｆｉｃａｔｉｏｎ  ａｎｄ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ、ＡＫＥと略する）が行なわれる。ＡＫＥ部２００１に対して、その認証と鍵交換の設定情報が入力され、この情報がパケット化部２００２に伝達され、パケット化部２００２において規定のヘッダが付加されたパケット化が行われ、ネットワーク２００７に出力される。ここで、パケット化部２００２は、送信条件設定部２００３により決定された送信パラメータにより、入力データのパケット化および送信を行なう。受信側では、ネットワーク２００７より入力する信号がパケット受信部２００４でパケットヘッダなどの識別によりフィルタリングされ、ＡＫＥ部２００１に入力される。これにより送信側（ソース）のＡＫＥ部と、受信側（シンク）のＡＫＥ部がネットワーク２００７を介してお互いにメッセージの通信ができる。すなわち、ＤＴＣＰ方式の手順に従い、認証と鍵交換を実行する。
【００１４】
送信側（ソース）と、受信側（シンク）で認証と鍵交換が成立すれば、次に、ＡＶデータの伝送を行なう。ソースでは、ＭＰＥＧ−ＴＳ信号を暗号化部２００５に入力して、ＭＰＥＧ−ＴＳ信号を暗号化した後、この暗号化されたＭＰＥＧ−ＴＳ信号をパケット化部２００２に入力し、ネットワーク２００７に出力する。シンクでは、ネットワーク２００７より入力する信号がパケット受信部２００４でパケットヘッダなどの識別によりフィルタリングされ、復号部２００６に入力され、復号されＭＰＥＧ−ＴＳ信号が出力される。
【００１５】
次に、図３を用いて上記手順を補足説明する。図３においては、ソースとシンク間はＩＥＥＥ１３９４で接続されていると仮定する。まず、ソース側でコンテンツの送信要求が発生する。そして、ソースからシンクへ暗号化されたコンテンツおよびコンテンツの保護モード情報が送信される。シンクは、コンテンツのコピー保護情報の解析を行い、完全認証もしくは制限付き認証のどちらの認証方式を用いるかを決定し、認証要求をソースに送る。ソースとシンクはＤＴＣＰ所定の処理により認証鍵の共有を図る。そして、ソースは認証鍵を用いて交換鍵を暗号化してシンクに送り、シンクで交換鍵が復号される。ソースでは暗号鍵を時間的に変化させるために、時間的に変化するシード情報を生成し、シンクに送信する。ソースでは、交換鍵とシード情報より暗号化鍵を生成して、ＭＰＥＧ−ＴＳをこの暗号化鍵を用いて暗号化部で暗号化してシンクに送信する。シンクはシード情報を受信し交換鍵とシード情報より復号鍵を復元する。シンクではこの復号鍵を用いて暗号化されたＭＰＥＧ−ＴＳ信号を復号する。
【００１６】
図４は、図１においてＭＰＥＧ−ＴＳ信号を伝送する場合のＩＥＥＥ１３９４アイソクロナスパケットの一例である。このパケットは、４バイト（３２ビット）のヘッダ、４バイト（３２ビット）のヘッダＣＲＣ、２２４バイトのデータフィールド、４バイト（３２ビット）のトレイラによって構成されている。暗号化されて伝送されるのは２２４バイトのデータフィールドを構成するＣＩＰヘッダとＴＳ信号のうち、ＴＳ信号のみで、他のデータは暗号化されない。ここで、ＤＴＣＰ方式固有の情報は、コピー保護情報である２ビットのＥＭＩ（Ｅｎｃｒｉｐｔｉｏｎ  Ｍｏｄｅ  Ｉｎｄｉｃａｔｏｒ）、およびシード情報のＬＳＢビットであるＯ／Ｅ（Ｏｄｄ／Ｅｖｅｎ）であり、これらは上記３２ビットのヘッダ内に存在するため暗号化されずに伝送される。
【００１７】
以上説明したようにして、デジタル放送を受信・選局して得られた放送番組のＡＶデータが、暗号化による保護の下に受信側へ送信される。なお、その際、そのＡＶデータと同じＴＳ信号に含まれているメタデータを、そのＡＶデータと共に受信側へ送ることは容易である。
【００１８】
例えば、放送番組のＡＶデータと同じＴＳ信号には、電子番組表（ＥＰＧ）情報が多重化されて放送されている。ＥＰＧ情報は、放送番組に関するメタデータの典型的な一例である。ユーザは、ＥＰＧ情報を参照することによって、番組の選択や録画予約のための利便を享受できる。
【特許文献１】特開２０００−５９４６３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１９】
しかしながら、コンテンツと多重されるメタデータに加えて、他の情報源からもそのコンテンツに関する異なるメタデータが提供される状況において、好ましいメタデータをユーザに提示するための有効な技術は、いまだ知られていない。
【００２０】
具体的に放送番組の例で言えば、現在では、放送番組のチャンネルとは別のＥＰＧ情報配信チャンネルや、インターネット上のテレビガイドサイト、テレビブログサイトといった多くの情報源から、その放送番組に関する多様なメタデータが提供される。
【００２１】
例えば、インターネット上のテレビガイドサイトからは、放送番組と多重されるＥＰＧ情報に含まれる番組説明よりも詳細な番組説明が提供されるし、また、テレビブログサイトからは放送番組への感想や録画視聴する人への必見箇所の紹介といった、ＥＰＧ情報の内容を超えるメタデータが提供されている。
【００２２】
以上を鑑み、本発明は、ＤＴＣＰ等のコンテンツ保護技術で保護されたコンテンツをＨＴＴＰプロトコルやＲＴＰプロトコルなどを利用してＩＰパケット化して送信すると共に、従来よりも多様なメタデータをユーザに提供できる可能性を高めたパケット送信装置を提供することを目的とする。
【課題を解決するための手段】
【００２３】
上記目的を達成するために、本発明に係るパケット送信装置は、番組に関する第１のプログラム情報を含む入力ストリームを受信する受信手段と、前記受信された入力ストリームから前記第１のプログラム情報を抽出すると共に、放送チャンネル及び通信ネットワークのうちの少なくとも一方から前記番組に関する第２のプログラム情報を取得するメタデータ取得手段と、前記第１のプログラム情報及び前記第２のプログラム情報の一方を選択するか又は両方を合成して、前記番組に関する新たなプログラム情報を再構成するプログラム情報再構成手段と、前記再構成された新たなプログラム情報を用いて前記入力されたストリームにフィルタリング処理を行うフィルタリング手段と、前記フィルタリング後の前記入力ストリームを含む新たな出力ストリームを構成し、構成された出力ストリームをパケット化して外部へ送信する送信手段とを備える。
【００２４】
また、前記パケット送信装置において前記受信手段は放送信号から前記入力ストリームを受信し、さらに、前記パケット送信装置は、前記放送信号とは異なる外部入力信号から他の入力ストリームを受け付ける入力手段と、前記受信手段によって受信される入力ストリーム及び前記入力手段によって受け付けられる入力ストリームの何れかを選択するスイッチャと、前記選択された入力ストリームから、その入力ストリームに含まれるコンテンツデータのデータフォーマットを示すデータフォーマット情報、又は前記コンテンツデータの属性を示す属性情報を検出する信号フォーマット及びプロパティ検出手段と、前記検出されたデータフォーマット情報又は属性情報をトランスポートパケットにカプセル化するカプセル化手段と、前記選択された入力ストリームに含まれるコンテンツデータに関するデスクリプタを生成し、前記入力ストリームに挿入するデスクリプタ挿入手段と、前記カプセル化されたトランスポートパケットと、前記デスクリプタ挿入後の入力ストリームのトランスポートパケットとを、後者に比べて前者へより大きな遅延を与えて多重化すると共に、それぞれのトランスポートパケットにタイムスタンプを付加することにより、パーシャルトランスポートストリームを生成するパーシャルトランスポートストリーム生成手段と、前記生成されたパーシャルトランスポートストリームのトランスポートパケットを所定の大きさの伝送パケットペイロードに変換するデータブロック化手段と、前記所定の大きさを表すサイズ情報を含むと共に、前記検出されたデータフォーマット情報又は属性情報が前記コンテンツデータの伝送、複製、又は再生に関する制御情報である場合にはその制御情報を含む伝送パケットヘッダを生成する伝送パケットヘッダ生成手段と、前記変換された伝送パケットペイロードと、前記生成された伝送パケットヘッダとを結合することにより、伝送パケットを生成する伝送パケット生成手段とを備えてもよい。
【００２５】
より具体的には、本願第１の発明は、入力されたＡＶデータとそのメタデータを用いて、規定の送信および受信条件によりデータブロックヘッダの付加制御および、暗号化制御を行ってパケット化を行なう。暗号化のモードは、ＭＰＥＧ−ＴＳ信号などのＡＶストリームのコピー制御情報（ＣＣＩ）を用いて行ない、パケット送受信機器間での信号の互換性を確保しながら、パケット伝送を行なうことが可能となる。
【００２６】
放送のＥＰＧ情報として、たとえば、デジタル放送信号に含まれるＳＩ情報から抽出した情報、ＥＰＧ専用チャンネルから抽出した情報、ＩｎｔｅｒｎｅｔのＥＰＧ情報などから取得した情報があり、これらの情報は、放送システムの種別、放送ネットワーク識別、放送の編成チャンネル情報、番組名、番組のジャンル、チャンネル番号、番組の開始時間、番組の終了時間、番組の説明記述（簡易記述版、詳細記述版）などにより構成されている。
【００２７】
本発明では、これら複数の情報源より、希望する情報を選択したり、個別情報を選択、結合し、ＥＰＧ情報を再構成することもできる点が従来の発明と大きく異なる。さらに上記情報の結合、再構成の際に、その情報源のアトリビュートを持ち、継承させることも可能である。
【００２８】
本願第２の発明は、受信側より送信側にＨＴＴＰプロトコルによるデータ伝送の要求を行う場合に、複数の前記暗号化制御された前記ＡＶデータにより構成される、被伝送データブロックの先頭データまたは末尾データを、送信側で管理しているデータブロックの先頭データと一致させる。一例として、データがＭＰＥＧの場合には、送信側で管理するデータブロックの単位は、ＧＯＰまたは、Ｐｉｃｔｕｒｅまたは、マクロブロック、ブロック、ＴＳパケット、または、タイムスタンプ付きＴＳパケットの単位とすることができる。
【００２９】
また、データブロックが送信装置に内蔵されたハードディスクドライブ（ＨＤＤと略す）やＣＤやＤＶＤ（ＤＶＤ−Ｒ、ＤＶＤ−ＲＡＭなど複数の種類がある）などの光ディスクの場合には、これはＨＤＤやＣＤやＤＶＤの各記録フォーマットにおける論理ブロックの単位とすることもできる。
【００３０】
たとえば、データ（ファイルやストリーム）がＭＰＥＧの場合に、受信側より送信側にＨＴＴＰのレンジリクエストで要求するデータ範囲がＧＯＰ単位やＰｉｃｔｕｒｅ単位とデータ境界が合っていなくても（専門用語で、データのアライメントが取れていないなどとも言う）、送信側の処理としてＨＴＴＰレスポンスとして要求されたデータ範囲に近いところにあるＧＯＰ単位やＰｉｃｔｕｒｅ単位をレスポンスとして返信することができる。そこで、受信側では受信データから効率よくＭＰＥＧデコードを行うことができる。
【００３１】
本願第３の発明は、上記のパケット送信手段の構成に加えて、ＭＰＥＧ−２／Ｈ．２６４トランスコーダを備え、蓄積手段に蓄積されたＭＰＥＧ−２  ＴＳのファイルをＨ．２６４にトランスコードする。これにより、画質を保ちながらファイルサイズを約２分の１以下に削減できるため、より多くのファイルの蓄積が可能になるとともに、より狭い帯域でＨ．２６４ストリームを実時間伝送すること、あるいは、より高速にファイル転送することができる。
【００３２】
たとえば、家庭内ネットワークを無線ＬＡＮで構築している場合、ＭＰＥＧ−２では、ＨＤＴＶのＴＳビットレートが約２５Ｍｂｐｓとなり、無線ＬＡＮでは帯域が不足する場合でも、Ｈ．２６４の場合、約８Ｍｂｐｓに伝送レートを削減できるため、余裕を持って家庭内でのＨＤＴＶの無線伝送ができる。ＳＤＴＶの場合には、約１．５Ｍｂｐｓに削減できるので、たとえば６ｃｈでも約９Ｍｂｐｓであり、主要放送局６局分のＭＰＥＧ−ＴＳを同時にホームサーバとクライアント間で伝送することが可能となる。
【００３３】
本願第４の発明は、上述の構成に類似しているが、入力系と出力系がそれぞれ２系統ある点が大きく異なる。すなわち、入力される系統の信号は立体画像を構成する。立体画像を伝送するために、２つの入力に、左眼用映像、右眼用映像を入力する。ここで、入力される左眼用映像、右眼用映像は、Ｈ．２６４エンコード時に左右の映像で映像フレーム同期または映像フィールド同期を取る。また、Ｈ．２６４ではＩＤＲピクチャで左眼用映像、右眼用映像より構成される２ｃｈ映像の同期を取ることにより、映像同期処理など信号処理が簡単にでき、装置の低コスト化も図れる。さらに、ＭＰＥＧ−２やＨ．２６４を用いた３Ｄ（立体）映像のエンコードにおいて、一般的に左眼用映像と右眼用映像は似ているので、左眼用映像は右眼用映像を参照してエンコードすれば、左眼用映像のビットレートを小さくできる。よって、この場合には、トータルとして、右眼用映像の約１．５倍のビットレートに抑えることができる。
【００３４】
本願第５の発明は、第２の発明の構成において、外部入力がＨ．２６４エンコーダに接続されている。Ｈ．２６４処理において、一般的なメタデータ、デジタル放送を受信して、そのＳＩ（Ｓｅｒｖｉｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ）より得るメタデータ、ＥＰＧ提供事業者より得たＥＰＧ情報などのメタデータ、Ｉｎｔｅｒｎｅｔから得たＥＰＧなどのメタデータ、また、個人でムービー撮影したＡＶコンテンツ（クリップなど）に関連付けたメタデータなどをＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ  Ｅｎｈａｎｃｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ）に入力する。たとえば、ＳＥＩのＵｓｅｒ  Ｄａｔａ  Ｕｎｒｅｇｉｓｔｅｒｅｄ  ＳＥＩにメタデータが格納できる。これらメタデータを活用することにより、多くのＡＶコンテンツから所望のコンテンツを検索する、ライブラリに分類する、自動表示を行うなどコンテンツの効率的な利用が可能となる。
【００３５】
また、デジタル放送で音楽番組を受信する場合、音楽番組をライブで別室に伝送する場合は、頭出しの必要はないが、デジタル放送で音楽番組を受信して、一旦、蓄積手段に蓄積して、後ほど、音楽番組を視聴する場合、番組中に放送された複数の楽曲の中より所望の楽曲に簡単にアクセスしたいというユーザ要求がある。ところが、デジタル放送で音楽番組を受信しても、番組タイトルと、一部の楽曲名はＳＩのＥＰＧ情報（たとえば、ＥＩＴ；Ｅｖｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）から取得できるが、各楽曲の放送時間などの情報がないために、蓄積手段より楽曲を再生する際に、簡単に所望の楽曲に簡単にアクセスできないという課題がある。
【００３６】
そこで、本発明では解決手段として、Ｉｎｔｅｒｎｅｔ上の楽曲情報サーバにアクセスして、該音楽番組内の楽曲情報を取得する。そして、取得した該音楽番組内の楽曲情報と蓄積手段に記録されている該音楽番組内の複数の楽曲とを該音楽番組のタイムレンジ情報などで関連付けた楽曲位置テーブルを作成し、蓄積手段の楽曲位置テーブル格納用Ｄｉｒｅｃｔｏｒｙに記録する。ユーザはＵＰｎＰ−ＡＶのサービスでブラウズ、サーチなどを行うと、該音楽番組タイトルのファイル（または、ＵＰｎＰで定義された＜ｒｅｓ＞）に対して、該音楽番組中の各楽曲に対して楽曲位置テーブルを用いることにより、ＨＴＴＰのタイムレンジ指定などで瞬時に所望の楽曲にアクセスできる。また、ＨＴＴＰでの楽曲アクセスに関して、たとえば、「ＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）パラメータで楽曲名を指定により、サーバ側で楽曲名から放送番組内の該楽曲の放送時刻を指定するアプリケーションを組む」ことにより、便利な楽曲アクセス機能を実現することもできる。また、Ｉｎｔｅｒｎｅｔより該音楽番組内の楽曲情報が取得できない場合には、各楽曲の波形データ、たとえば、楽曲のサビなど、をＩｎｔｅｒｎｅｔ上の楽曲名解析サービスのサーバなどに問い合わせることにより、該音楽番組内の楽曲情報を取得することができる。
【００３７】
本願第６の発明は、ＨＤムービーで撮影したＭＰＥＧ−ＴＳ形式のＨＤコンテンツとそのメタデータがホームサーバに蓄積しておく場合、効率的な編集を実現する。ＨＤ／低解像度変換手段は蓄積手段１に蓄積されたＨＤコンテンツを低解像度で低ビットレートのコンテンツに変換する。別室などのＰＣや携帯端末よりネットワークを介して、ホームサーバに蓄積されたコンテンツをリモート編集する場合、ＨＤコンテンツをＰＣや携帯端末に送るには、各機器の処理負荷およびネットワーク負荷を小さくするため、蓄積された低解像度コンテンツを受信側に送信する。また、受信側の処理としては、編集リスト（ＥＤＬ）を作成し、ＥＤＬを送信側に伝送する。送信側は、受信したＥＤＬに基づいて編集されたＨＤコンテンツを受信側に伝送する。この様に不必要な映像を削除することにより、受信側に伝送するデータ量を削減することができる。
【００３８】
なお、本発明は、このようなパケット送信装置として実現できるだけでなく、パケット送信方法として実現したり、パケット送信装置のためのプログラムとして実現したり、そのプログラムを記録したコンピュータ読み取り可能なＣＤ−ＲＯＭやＤＶＤ−ＲＡＭなどの記録媒体としても実現できる。
【発明の効果】
【００３９】
本願第１の発明によれば、入力されたＡＶデータとそのメタデータを用いて、パケット送受信機器間での信号の互換性を確保しながら、パケット伝送を行なうことが可能となる。
【００４０】
放送のＥＰＧ情報として、デジタル放送信号のＳＩ情報、ＥＰＧ専用チャンネルから抽出した情報、ＩｎｔｅｒｎｅｔのＥＰＧ情報などから取得した情報などより希望する情報を選択したり、個別情報を選択、結合し、ＥＰＧ情報を再構成することにより、従来よりも幅広く詳細なメタデータをもつことができるので、よりきめ細かい制御による番組選択、視聴が可能となる。すなわち、多くのＡＶコンテンツから所望のコンテンツを検索する、ライブラリに分類する、自動表示を行うなどコンテンツの効率的な利用が可能となる。
【００４１】
本願第２の発明によれば、被伝送データブロックの先頭データまたは末尾データを、送信側で管理しているデータブロックの先頭データと一致させて伝送することにより、受信データから効率よくＭＰＥＧデコードを行うことができる。
【００４２】
本願第３の発明によれば、ＭＰＥＧ−２／Ｈ．２６４トランスコーダを備えることにより、画質を保ちながらファイルサイズを約２分の１以下に削減できるため、より多くのファイルの蓄積が可能になるとともに、より狭い帯域でＨ．２６４ストリームを実時間伝送すること、あるいは、より高速にファイル転送することができる。
【００４３】
本願第４の発明によれば、Ｈ．２６４ではＩＤＲピクチャで左眼用映像、右眼用映像より構成される２ｃｈ映像の同期を取ることにより、立体画像を効率よく伝送することができる。また、ＭＰＥＧ−２やＨ．２６４を用いた３Ｄ（立体）映像のエンコードにおいて、一般的に左眼用映像と右眼用映像は似ているので、左眼用映像は右眼用映像を参照してエンコードすれば、左眼用映像のビットレートを小さくできる。よって、この場合には、トータルとして、右眼用映像の約１．５倍のビットレートにおさえることができる。
【００４４】
本願第５の発明によれば、外部入力であるＨ．２６４信号にメタデータを格納する方法を与える。また、デジタル放送で音楽番組を受信する場合、音楽番組をライブで別室に伝送する場合は、頭出しの必要はないが、デジタル放送で音楽番組を受信して、一旦、蓄積手段に蓄積して、後ほど、音楽番組を視聴する場合、番組中に放送された複数の楽曲の中より所望の楽曲に簡単なアクセスを実現する。
【００４５】
本願第６の発明によれば、ＨＤムービーで撮影したＭＰＥＧ−ＴＳ形式のＨＤコンテンツとそのメタデータがホームサーバに蓄積しておく場合、効率的な編集を実現する。ＨＤ／低解像度変換手段は蓄積手段１に蓄積されたＨＤコンテンツを低解像度で低ビットレートのコンテンツに変換する。別室などのＰＣや携帯端末よりネットワークを介して、ホームサーバに蓄積されたコンテンツをリモート編集する場合、ＨＤコンテンツをＰＣや携帯端末に送るには、各機器の処理負荷およびネットワーク負荷を小さくするため、蓄積された低解像度コンテンツを受信側に送信する。また、受信側の処理としては、編集リスト（ＥＤＬ）を作成し、ＥＤＬを送信側に伝送する。送信側は、受信したＥＤＬに基づいて編集されたＨＤコンテンツを受信側に伝送する。この様に不必要な映像を削除することにより、受信側に伝送するデータ量を削減することができる。
【発明を実施するための最良の形態】
【００４６】
以下、本発明の実施の形態について図面を用いて詳細に説明する。まず、本発明の位置付けを明確にするために適用する通信システム例の概略について説明する。
【００４７】
図５は本発明を適用する通信システムの一例である。この通信システムは、パケットを送信するパケット送信機器１０１と、パケットのルーティングを行うルータ１０２と、パケットを受信するパケット受信機器１０３とから構成される。
【００４８】
パケット送信機器１０１には、機器の管理運用を含む送受信条件の設定情報、認証と鍵交換の設定情報、入力ストリーム（ＭＰＥＧ−ＴＳ形式等のコンテンツ）が入力され、図６に示されるように、以下の手順１から３に基づき、ルータ１０２との間で通信を行う。ここで、伝送されるコンテンツの著作権保護は、認証と暗号化を用いたコピー保護に基づいて実現される。
【００４９】
＜手順１＞送受信パラメータの設定を行なう。
【００５０】
（手順１−１）パケット送受信機器のＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）アドレス、ＩＰアドレス、ＴＣＰ／ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）ポート番号等を設定。ＵＰｎＰなどの自動設定機能を使用することができる。
【００５１】
（手順１−２）送信信号の種別、帯域を設定。ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）エージェントとして動作するパケット送信機器１０１とパケット受信機器１０３、ＱｏＳマネージャとして動作するルータ１０２との間でＩＥＥＥ８０２．１Ｑ（ＶＬＡＮ；Ｖｉｒｔｕａｌ  ＬＡＮ）規格を用いたネットワークの運用に関する設定を実施。
【００５２】
（手順１−３）優先度の設定（ＩＥＥＥ８０２．１Ｑ／ｐによる運用）
【００５３】
＜手順２＞認証と鍵交換：
（手順２−１）認証と鍵交換を行なう。たとえば、ＤＴＣＰ方式を用いることもできる。
【００５４】
＜手順３＞ストリーム伝送：
（手順３−１）パケット送信機器とパケット受信機器間での暗号化されたストリームコンテンツ（パーシャルＭＰＥＧ−ＴＳ）を伝送する。
【００５５】
なお、上記例ではＭＰＥＧ−ＴＳを使用しているが、これに限らず本発明で用いる入力コンテンツの適用範囲としては、ＭＰＥＧ１／２／４などＭＰＥＧ−ＴＳストリーム（ＩＳＯ／ＩＥＣ１３８１８）、ＭＰＥＧ−ＰＳ（Ｐｒｏｇｒａｍ  Ｓｔｒｅａｍ）、ＭＰＥＧ−ＥＳ（Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ）、ＭＰＥＧ−ＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ  Ｅｌｅｍｅｎｔａｒｔｙ  Ｓｔｒｅａｍ）、ＤＶ（ＩＥＣ６１８３４、ＩＥＣ６１８８３）、ＳＭＰＴＥ（Ｓｏｃｉｅｔｙ  ｏｆ  Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  ＆  Ｔｅｌｅｖｉｓｉｏｎ  Ｅｎｇｉｎｅｅｒｓ）３１４Ｍ（ＤＶ−ｂａｓｅｄ）、ＳＭＰＴＥ２５９Ｍ（ＳＤＩ）、ＳＭＰＴＥ３０５Ｍ（ＳＤＴＩ）、ＳＭＰＴＥ２９２Ｍ（ＨＤ−ＳＤＩ）、ＩＳＯ／ＩＥＣ  Ｈ．２６４等で規格化されているストリーム、さらには、一般的なＡＶコンテンツも適用可能である。
【００５６】
さらに、本発明で用いる入力データはファイル転送にも適用できる。ファイル転送の場合、送受信装置の処理能力と、送受信装置間の伝播遅延時間の関係により、データ転送速度がコンテンツストリームの通常再生データレートよりも大きくなる条件下では、リアルタイムより高速のコンテンツ伝送も可能となる。
【００５７】
次に、上記手順２の認証と鍵交換に関して補足説明する。図５において、パケット送信機器１０１とパケット受信機器１０３間はＩＰネットワークにより接続されている。まず、パケット送信機器１０１からパケット受信機器１０３へコンテンツに関する信号フォーマット、プロパティ情報、コピーや出力に対する保護・制御モード情報等が送信される。
【００５８】
パケット受信機器１０３は、コンテンツに関する信号フォーマット、プロパティ情報、保護・制御モード情報等の解析を行い、使用する認証方式を決定して認証要求をパケット送信機器１０１に送る。これらの処理を通して、パケット送信機器１０１とパケット受信機器１０３は認証鍵を共有する。
【００５９】
次に、パケット送信機器１０１は認証鍵を用いて交換鍵を暗号化してパケット受信機器１０３に送り、パケット受信機器１０３で交換鍵が復号される。
【００６０】
パケット送信機器１０１では暗号鍵を、たとえば、一定のデータ量毎（一定の時間ごと、またはコマンドや信号検出により）に変化させて一定のデータ量毎に変化する鍵変更情報を生成し、パケット受信機器１０３に送信する。
【００６１】
パケット送信機器１０１では、交換鍵と鍵変更情報より暗号化鍵を生成して、ＭＰＥＧ−ＴＳをこの暗号化鍵を用いて暗号化部で暗号化してパケット受信機器１０３に送信する。
【００６２】
パケット受信機器１０３は受信した鍵変更情報を交換鍵より復号鍵を復元する。パケット受信機器１０３ではこの復号鍵を用いて暗号化されたＭＰＥＧ−ＴＳ信号を復号する。
【００６３】
このようにして、パケット送信機器１０１及びパケット受信機器１０３の間で、コピー制御に基づいてコンテンツの著作権を保護しつつ、そのコンテンツの伝送が行われる。
【００６４】
図７は、本方式をイーサネット（登録商標）によるＬＡＮを備える２階建ての家庭に適用した場合の一例である。この家庭は、１階に設置されたルータ３０３を含むネットワークシステム３０１と、２階に設置されたスイッチングハブ３０４を含むネットワークシステム３０２を備える。ネットワーク３０５は、ルータ３０３とスイッチングハブ３０４を接続するイーサネット（登録商標）ネットワークである。ここで、ネットワークシステムとしてＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）のサブネットマスク（Ｓｕｂｎｅｔ  Ｍａｓｋ）によって設定されるサブネット（Ｓｕｂｎｅｔ）がある。家庭内の全てのイーサネット（登録商標）ネットワークの帯域は１００Ｍｂｐｓである。
【００６５】
また、ルータ３０３は、１階のネットワークと２階のネットワークを同じサブネットとして結合させ動作させるために、家庭内ネットワークに対してはスイッチングハブとして働かせる。ただし、ルータ３０３が家庭外とは、異なるサブネットとして構成する。このように家庭内で１つのサブネットを構成することにより、上述の暗号化したＩＰパケットのＴＴＬを１に制限することにより、上述の暗号化通信をサブネット内、すなわち、家庭内に制限することが可能となる。
【００６６】
１階のネットワークシステム３０１の構成として、ルータ３０３には、テレビ（ＴＶ）、カメラ、ＤＶＤレコーダが１００Ｍｂｐｓのイーサネット（登録商標）で接続され、また、エアコン、冷蔵庫がＥＣＨＯＮＥＴで接続されている。
【００６７】
また、２階では、スイッチングハブ３０４にテレビ（ＴＶ）、パソコン（ＰＣ）、ムービーが１００Ｍｂｐｓのイーサネット（登録商標）で接続され、また、エアコンがＥＣＨＯＮＥＴで接続されている。なお、ＥＣＨＯＮＥＴは「エコーネットコンソーシアム」（ＨＹＰＥＲＬＩＮＫ  “ｈｔｔｐ：／／ｗｗｗ．ｅｃｈｏｎｅｔ．ｇｒ．ｊｐ／”  ｈｔｔｐ：／／ｗｗｗ．ｅｃｈｏｎｅｔ．ｇｒ．ｊｐ／）で開発されている伝送方式である。
【００６８】
なお、この家庭において、例えば、デジタル著作権保護の対象となるコンテンツを放送で受信し、家庭内の各機器（エアコン、ＤＶＤ、ＰＣ、冷蔵庫）にＩＰパケットで配信するＴＶが本発明のパケット送信機器１０１に相当し、各機器がパケット受信機器１０３に相当する。
【００６９】
図７において、パソコン（ＰＣ）、ＤＶＤレコーダ、ルータ３０３およびスイッチングハブ３０４は、ＩＥＥＥ８０２．１Ｑ（ＶＬＡＮ）に対応している。すなわち、ルータ３０３およびスイッチングハブ３０４において、各ポートのデータレートが全て同じ（例えば１００Ｍｂｐｓ）場合、特定ポートへ出力されるデータ帯域の合計がそのポートの伝送レートの規格値または実力値を超えない限り、入力ポートへ入力されたデータはルータ（あるいは、スイッチングハブ）内部で失われず全て出力ポートに出力される。
【００７０】
スイッチングハブでは、たとえば８個の入力ポートにデータが同時に入力されても、それぞれのデータの出力ポートが異なっていれば、それぞれのデータはハブ内部のバッファで競合しないでスイッチングされて出力ポートより出力されるため、入力データはパケット落ちすることなく全て出力ポートに出力される。
【００７１】
図７において、家庭内の全てのイーサネット（登録商標）の帯域が１００Ｍｂｐｓであるため、１階と２階間のネットワーク３０５の帯域も１００Ｍｂｐｓである。１階と２階の複数の機器間で複数のデータが流れる場合、各データに対する帯域制限がない場合、このネットワーク３０５上を流れるデータのデータレート合計が１００Ｍｂｐｓを超える可能性があり、パーシャルＭＰＥＧ−ＴＳの映像アプリなどリアルタイム伝送が必要なストリームが途切れる可能性がある。この場合、リアルタイム伝送が必要なストリームが途切れない様にするには、１階と２階間のネットワーク３０５の帯域を１Ｇｂｐｓに拡大する、または、伝送データに対して優先制御が必要である。このような優先制御については、端末だけでなく、ルータやスイッチングハブにおいて、後述するストリーム伝送やファイル転送の速度制限機構などを導入することにより解決できる。
【００７２】
たとえば、パーシャルＭＰＥＧ−ＴＳストリームの伝送優先度をファイル転送データの伝送優先度よりも高くすると、１階と２階のＰＣ間でのファイル転送をバックグラウンドで行いながら、同時に、１階および２階のＤＶＤレコーダ、ＰＣ、ＴＶの間でＭＰＥＧ−ＴＳを暗号化して、ＨＴＴＰプロトコルやＲＴＰプロトコルなどを利用してリアルタイムで伝送することが可能となる。
【００７３】
なお、パーシャルＭＰＥＧ−ＴＳはＭＰＥＧ−ＴＳストリームの一種であり、たとえば、ＡＲＩＢ規格、ＳＴＤ−Ｂ２１に記述されている。また、ＨＴＴＰプロトコル（ＩＥＴＦ規格、ＲＦＣ２６１６、ＲＦＣ１９４５）の概要、構成、動作に関しては、たとえば、「連載：インターネット・プロトコル詳説（１）、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）〜前編」、ＷＥＢ資料、で解説されている。
【００７４】
前述したルータ３０３、またはスイッチングハブ３０４における伝送速度制限機構は、データ流入制御により実現できる。すなわち、ルータ（あるいは、スイッチングハブ）の入力データキューにおいて優先度の高いデータと低いデータを比較して、優先度の高いデータを優先して出力することにより実現できる。この優先制御方式に用いるバッファ制御ルールとしては、ラウンドロビン方式、流体フェアスケジューリング方式、重み付けフェアスケジューリング方式自己同期フェアスケジューリング方式ＷＦＦＱ方式、仮想時計スケジューリング方式、クラス別スケジューリング方式などがある。これらのスケジューリング方式に関する情報は、戸田巌著、「ネットワークＱｏＳ技術」、平成１３年５月２５日（第１版）、オーム社刊の第１２章などに記述されている。
【００７５】
地上波デジタル放送、ＢＳデジタル衛星放送、１１０度ＣＳデジタル衛星放送、ＣＡＴＶやインターネット経由等で受信するデジタル放送信号より検出、抽出できるＡＶコンテンツの属性情報を送信端末と受信端末間でＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ）−ＡＶやＨＴＴＰなどのデータ交換プロトコルを用いて伝送することにより、送信端末と受信端末間でのＡＶコンテンツを送信する場合の暗号化モード、コンテンツ属性情報（プロパティ）の伝送方法を決めることができる。さらに、暗号化情報ヘッダの付加ルールを決められるため、パケット送受信機器間でのＡＶストリームの秘匿性を保ちながら信号の互換性を確保することが可能となる。ＵＰｎＰやＵＰｎＰ−ＡＶの標準仕様は、ｈｔｔｐ：／／ｕｐｎｐ．ｏｒｇで公開されている。ｈｔｔｐ：／／ｕｐｎｐ．ｏｒｇにおいて、例えば、「ＭｅｄｉａＳｅｒｖｅｒ  Ｖ  １．０  ａｎｄ  ＭｅｄｉａＲｅｎｄｅｒｅｒ  Ｖ  １．０」に関して、「ＭｅｄｉａＳｅｒｖｅｒ  Ｖ  １．０」、「ＭｅｄｉａＲｅｎｄｅｒｅｒ  Ｖ  １．０」、「ＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ  Ｖ  １．０」、「ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙ  Ｖ  １．０」、「ＲｅｎｄｅｒｉｎｇＣｏｎｔｒｏｌ  Ｖ  １．０」、「ＡＶＴｒａｎｓｐｏｒｔ  Ｖ  １．０」、「ＵＰｎＰＴＭ  ＡＶ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｖ  ．８３」などの仕様書が公開されている。
【００７６】
また、ネットワークを用いたＡＶコンテンツの伝送に関して、ネットワーク上でのデータ盗聴を防止し、安全性の高いデータ伝送を実現する。これにより、伝送路にインターネットなど公衆網を使用した場合においても、リアルタイム伝送される優先データ（ＡＶデータコンテンツ）の盗聴、漏洩を防止することができる。また、インターネット等で伝送されるＡＶデータの販売、課金が可能となり、より高い安全性が要求されるＢ−Ｂ（Ｂ  ｔｏ  Ｂ）、Ｂ−Ｃ（Ｂ  ｔｏ  Ｃ）におけるコンテンツ販売流通が可能となる。
【００７７】
さらに、送信データよりＡＶコンテンツを分離してハードウェアで伝送プロトコル処理の一部をアクセラレートする場合にも、ＡＶコンテンツでない一般のデータパケットは従来通りプロセッサを用いてソフトウェア処理を行える。よって、ソフトウェアの追加により管理情報や制御情報などデータを一般データとして伝送させることができる。一般に、これらＡＶコンテンツでない一般データの量は優先データであるＡＶデータに比べて非常に少ないので、マイコンなど安価なマイクロプロセッサで処理することが可能となるので、低コストでのシステム実現ができる。なお、高負荷かつ高伝送レート優先パケットのプロトコル処理にも高価なＣＰＵや大規模メモリを必要としないので、これらの点からも低コストで高機能な装置を提供できる。
【００７８】
また、サーバ型放送のＲＭＰで用いる課金情報などを含むＲＭＰＩ（Ｒｉｇｈｔｓ  Ｍａｎａｇｅｍｅｎｔ  ＆  Ｐｒｏｔｅｃｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ）で視聴あるいはコピー制限されたコンテンツをＲＭＰに対応していないクライアントにＣＮＭ（Ｃｏｐｙ  Ｎｏ  Ｍｏｒｅ）やＣＮ（Ｃｏｐｙ  Ｎｅｖｅｒ）で見せることができ、サーバ型放送の普及を加速することができる。この場合、制御情報に基づいて、ＡＶデータの再生制御、出力制御又はコピー制御を行うための課金情報、コピー制御情報、有効期限情報、有効再生回数情報など取り扱い、生成した情報を認証情報として認証部に通知する著作権管理部を用い、著作権管理部から通知された認証情報に基づいて、前記パケット受信装置との間で認証処理を行うことで、ＡＶデータの前記パケット受信装置における再生制御、出力制御又はコピー制御を行う。さらに、パケット伝送装置は、著作権管理部による制御の下で、課金情報、再生制御情報又はコピー制御情報に基づいて、パケット受信装置との間で、著作権保護の対象となるコンテンツの購入決済を行うコンテンツ購入決済部を備える。
【００７９】
（実施の形態１）
まず、本発明の実施の形態１について説明する。図８は、本実施の形態におけるパケット送信部４０１の構成を示すブロック図である。このパケット送信部４０１は、ＡＫＥに基づいて設定される暗号化によるパケット送受信を行う装置であり、セキュアＩＰパケット送信処理部４０２をコアとして内蔵している。パケット送信部４０１は、デジタルチューナ４０３、ＴＳインタフェース４０４、スイッチャ４０５、リモコンインタフェース４０６、信号フォーマット及びプロパティ検出部４０７、ＴＳカプセル化部４０８、ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９、ＴＳ−ＭＵＸ部４１０、ＣＣＩ検出部４１１、ＥＰＧ・録画データ処理部４１２、管理制御部４１３、認証と鍵交換（ＡＫＥ）部４１４、データブロック化部４１５、データブロックヘッダ生成部４１６、暗号化部４１７、データブロックパケット生成部４１８、伝送プロトコル処理部４１９、タイムスタンプ付加部４２０を備える。
【００８０】
なお、ここでＥＰＧ・録画データ処理部４１２がプログラム情報取得手段及びプログラム情報再構成手段の一例であり、ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９がフィルタリング手段の一例であり、データブロック化部４１５、データブロックヘッダ生成部４１６、データブロックパケット生成部４１８、及び伝送プロトコル処理部４１９の総体が送信手段の一例である。
【００８１】
また、データブロック化部４１５、データブロックヘッダ生成部４１６、データブロックパケット生成部４１８は、個別に見るとそれぞれ、データブロック化手段、伝送パケットヘッダ生成手段、及び伝送パケット生成手段の一例である。
【００８２】
また、ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９はデスクリプタ挿入手段の一例であり、ＴＳ−ＭＵＸ部４１０はパーシャルトランスポート生成手段の一例である。
【００８３】
以下、伝送手順に従って、各構成要素の機能を説明する。
【００８４】
管理制御部４１３には、管理用データと制御用データとしてのＡＶデータとメタデータが入力される。たとえば、管理制御部４１３には、ＡＶデータ（送信コンテンツ）の入力端子情報、ＡＶデータのデータフォーマット情報、及び、ＡＶデータのプロパティ（属性）を示す属性情報を含むＡＶデータ情報が入力される。これらの情報は、具体的には、たとえば、送信データの種別、送信先アドレスやポート番号の情報、送信に用いるパス情報（ルーティング情報）、送信データの帯域、送信データの送信優先度などの送信条件の設定情報と、送信部（ローカル）と受信部（リモート）における機器の管理制御データと、受信状況を送信側にフィードバックするためのデータを表す。管理制御部４１３は、入力された情報を用いて、データブロック化部４１５やプロトコル処理部４１９におけるヘッダやペイロードデータなどの生成（パラメータの設定等を）を制御する。
【００８５】
なお、パケット送信部４０１では省略してあるが、送信信号の入力端子情報とは、取り扱う信号がＭＰＥＧ−ＴＳ信号の場合に、（１）デジタル放送の入力端子（日本の場合、地上デジタル放送、ＢＳデジタル放送、１１０度広帯域ＣＳデジタル放送に対応するＲＦ入力端子）、（２）ＩＥＥＥ１３９４  Ｄ−Ｉ／Ｆ、（３）ＵＳＢ−Ｉ／Ｆ、（４）ＩＰ−Ｉ／Ｆ（Ｅｔｈｅｒｎｅｔ（登録商標）や無線ＬＡＮの区別）、（５）アナログ映像音声入力（この場合は、パケット送受信部４０１内で入力されたアナログ映像音声をＭＰＥＧ−ＴＳ信号に変換する）などがある。なお、デジタル放送に関しては、たとえば、映像情報メディア学会誌、Ｖｏｌ．５８、ｎｏ．５、ｐｐ．６０４〜ｐｐ．６５４において解説記事がある。
【００８６】
また、パケット送信部４０１におけるＡＶ信号のフォーマットを示すデータフォーマット情報とは、取り扱う信号がパーシャルＭＰＥＧ−ＴＳの場合、そのＭＩＭＥ−Ｔｙｐｅやメディアフォーマットを表わす。たとえば、送信部（サーバ）や受信部（クライアント）は、各々が取り扱う静止画メディア、音楽メディア、動画メディアに対して、それぞれのメディアフォーマットを定める。たとえば、動画（映像）のメディアフォーマットとしては、ＭＰＥＧ２、ＭＰＥＧ１、ＭＰＥＧ４、ＷＭＶなどがある。また、静止画のメディアフォーマットとしては、ＪＰＥＧ、ＰＮＧ、ＧＩＦ、ＴＩＦＦなどがある。さらに、音楽のメディアフォーマットとしては、リニアＰＣＭ、ＡＡＣ、ＡＣ３、ＡＴＲＡＣ３ｐｌｕｓ、ＭＰ３、ＷＭＡなどがある。これらは、たとえば、ＤＬＮＡ（Ｄｉｇｉｔａｌ  Ｌｉｖｉｎｇ  Ｎｅｔｗｏｒｋ  Ａｌｌｉａｎｃｅ；  ホームページはｗｗｗ．ｄｌｎａ．ｏｒｇ）でも同様に規定されている。ＤＬＮＡ  Ｇｕｉｄｅｌｉｎｅのｖｅｒｓｉｏｎ１．０では、サーバ（コンテンツの送信側、ＤＴＣＰではソース）をＤＭＰ（Ｄｉｇｉｔａｌ  Ｍｅｄｉａ  Ｓｅｒｖｅｒ）、クライアント（コンテンツの受信側、ＤＴＣＰではシンク）をＤＭＰ（Ｄｉｇｉｔａｌ  Ｍｅｄｉａ  Ｐｌａｙｅｒ）と呼んでいる。ＤＭＳはＵＰｎＰ−ＡＶのＭｅｄｉａＳｅｒｖｅｒ（ＭＳ）とＣｏｎｔｒｏｌＰｏｉｎｔ（ＣＰ）により構成され、ＤＭＰはＵＰｎＰ−ＡＶのＭｅｄｉａＲｅｎｄｅｒｅｒ（ＭＲ）とＣｏｎｔｒｏｌＰｏｉｎｔ（ＣＰ）により構成される。ＵＰｎＰ−ＡＶのＭＳ、ＭＲ、ＣＰについては、ＵＰｎＰのホームページ、ｗｗｗ／ｕｐｎｐ．ｏｒｇに記載されている。
【００８７】
映像メディアフォーマットの場合には、（１）解像度の区別（ＳＤ、ＨＤ）、（２）ＴＶ方式の区別（アナログではＮＴＳＣ、ＰＡＬ、ＳＥＣＡＭ、デジタルでは米国ＡＴＳＣ、欧州ＤＶＢ、日本のＩＳＤＢなどＡＲＩＢ規格に基づく放送方式）、（３）タイムスタンプ形式などの付加情報の有無、などを追加パラメータとして持つ。なお、たとえば映像の場合、ＭＰＥＧ−ＰＳでもＭＰＥＧ−ＴＳに対してもＭＩＭＥ−Ｔｙｐｅは“ｍｐｅｇ／ｖｉｄｅｏ”であるので、上記の付加情報を用いることにより、よりきめ細かい映像メディアの取り扱い、制御が可能となる。
【００８８】
なお、デジタル放送に関するＡＲＩＢ規格の概要は、たとえば、松下テクニカルジャーナル２００４年２月、Ｖｏｌ．５０、Ｎｏ．１、７ページから１２ページで解説されている。
【００８９】
また、パケット送受信部４０１におけるＡＶデータの属性を示す属性情報とは、例えば取り扱うＡＶ信号が日本の地上デジタル放送システムで放送局より放送され、家庭等の受信機で選局されたＭＰＥＧ−ＴＳ信号（正確には、ＡＲＩＢ標準規格、ＡＲＩＢ  ＳＴＤ  Ｂ２１、第９章において、シリアルインタフェースの入出力トランスポートストリームとして規定されているパーシャルトランスポート信号（パーシャルＴＳ信号））の場合、その属性情報としては、放送局よりＰＳＩ／ＳＩ情報として送信される、チャンネル名（放送局名）、チャンネル番号、番組名、番組のジャンル、スケジュールされた放送開始時間、スケジュールされた放送終了時間、番組内容に関する情報、番組の解像度、パレンタルなどの視聴制限情報、コピー制御情報、視聴料金などがある。ＰＳＩやＳＩに関しては、ＡＲＩＢ技術資料、ＡＲＩＢ  ＴＲ−Ｂ１４やＡＲＩＢ  ＴＲ−Ｂ１５にて規定されている。
【００９０】
図８において、デジタル放送対応のアンテナから受信ＲＦ信号がデジタルチューナ４０３に入力され、チャンネル選局されてフルＴＳがスイッチャ４０５に入力される。一方、ＴＳインタフェース４０４には、たとえば、ＨＤＴＶ（１０８０ｉ、７２０ｐなど）とＳＤＴＶ（５２５ｉ）の録画モードで録画できるデジタル方式ムービーより、ＨＤＴＶ（１０８０ｉ、７２０ｐなど）とＳＤＴＶ（５２５ｉ）のＭＰＥＧ−ＴＳ信号や、該ＭＰＥＧ−ＴＳ信号に関する録画情報（Ｍｅｔａｄａｔａ）がＭＰＥＧ−ＴＳ形式で入力される。スイッチャ４０５は、デジタルチューナ４０３入力とＴＳインタフェース４０４の出力を選択して出力する。このスイッチャ４０５の出力選択は、たとえば、リモコンよりリモコンインタフェース部４０６、内部にメモリとマイコンを持った管理制御部４１３により実行できる。なお、図８においては、図が複雑にならないように、管理制御部４１３とスイッチャ４０５の間の信号線は省略している。同様に、本発明の図面においては、図を簡単にするため省略しているが、管理制御部４１３は、全てのモジュールと信号線で接続されていて、各モジュール動作の管理や制御が可能である。
【００９１】
スイッチャ４０５で選択されたＭＰＥＧ−ＴＳは、信号フォーマット及びプロパティ検出部４０７、および、ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９に入力される。
【００９２】
信号フォーマット及びプロパティ検出部４０７に入力されたＴＳ信号は、ＥＰＧ・録画データ処理部４１２に入力され、放送のＥＰＧ情報やムービー録画に関するメタデータなどが抽出され、管理制御部４１３に渡される。ここで、放送のＥＰＧ情報は、たとえば、次の３つがある。
【００９３】
（１）  デジタル放送信号に含まれるＳＩ情報から抽出したＥＰＧ情報
【００９４】
（２）  ＥＰＧ専用チャンネルから抽出したＥＰＧ情報。たとえば、Ｇｅｍｓｔａｒ社やナノメディア社のＴＶ番組の提供するＥＰＧ情報。
【００９５】
（３）  Ｉｎｔｅｒｎｅｔから取得したＥＰＧ情報。例えば、テレビガイドサイトから取得されるＥＰＧ情報。より広義には、テレビブログサイトから取得される、放送番組に関するメタデータをこのＥＰＧ情報に含めてもよい。
【００９６】
ここで、ＩｎｔｅｒｎｅｔからのＥＰＧ情報は、プロトコル処理部４１９及び管理制御部４１３を介して取得される。
【００９７】
なお、ＥＰＧ情報としては、放送システムの種別、放送ネットワーク識別、放送の編成チャンネル情報、番組名、番組のジャンル、チャンネル番号、番組の開始時間、番組の終了時間、番組の説明記述（簡易記述版、詳細記述版）などがある。
【００９８】
ＥＰＧ・録画データ処理部４１２では、上記の複数のＥＰＧ情報より、希望するＥＰＧ情報を選択するだけでなく、個別のＥＰＧ情報を選択、結合し、ＥＰＧ情報を再構成することもできる。
【００９９】
さらに上記情報の結合、再構成の際に、その情報源のアトリビュートを持ち、継承させることも可能である。たとえば、ＵＰｎＰ−ＡＶの仕組みを使用すれば、上記３つの情報源のアトリビュートを、それぞれ、＠ＳＩ、＠ＥＰＧ専用ｃｈ１、＠Ｉｎｔｅｒｎｅｔ＿情報源１、などと標記することにより情報源を継承させることができる。
【０１００】
従来は、放送波に含まれるＳＩ情報のみからＥＰＧ情報を構成していたが、本発明の特徴は、ＥＰＧ情報を複数の情報源から取得してそれらから新たなＥＰＧ情報を再構成できる点にもある。
【０１０１】
例えば、放送時刻情報を含むＥＰＧ情報を放送波から取得すると共に、より詳しい番組説明記述を含むＥＰＧ情報をインターネットから取得し、その放送時刻情報と番組説明記述とを新たなＥＰＧ情報に再構成してもよい。そうすれば、番組の延長や変更が反映されている可能性が高い新鮮な放送時刻情報と充実した番組説明記述とを含む好ましいＥＰＧ情報が得られる。
【０１０２】
また、再構成に用いるＥＰＧ情報を、再構成された新たなＥＰＧ情報の送信先として予定される受信装置の属性に応じて選択してもよい。
【０１０３】
例えば、受信装置が携帯情報端末装置である場合には、表示画面があまり大きくないことを考慮して、放送波からのＥＰＧ情報に含まれる番組説明記述を用いてもよい。また、例えば、受信装置がパソコンである場合には、そのパソコンのユーザのお気に入りのテレビブログサイトにアクセスして得られる広義のＥＰＧ情報を新たなＥＰＧ情報に再構成してもよい。アクセスすべきテレビブログサイトのアドレスは、受信装置たるパソコンから予め取得しておくことができる。
【０１０４】
ユーザは、このようにして再構成された新たなＥＰＧ情報を参照して番組選択に役立てることができる。
【０１０５】
そのＥＰＧ情報を、例えば、図示しないテレビ受像機に表示し、それを見たユーザによって行われる番組選択操作をリモコンインタフェース４０６を介して受け付けることも可能であるし、ＵＰｎＰ−ＡＶやＤＬＮＡガイドラインで規定された番組情報などのメタデータの遠隔表示・制御に関する規格、仕様に則してホームネットワークを介して別室のテレビ受像機に伝送して表示し、別室でそれを見たユーザによって行われる番組選択操作をホームネットワークを介して受け付けることも可能である。また、ムービー録画の表示の場合には、録画ファイルの一覧をＥＰＧ情報のように、録画データ（メタデータ）とともにリスト形式で表示できる。
【０１０６】
ＴＳカプセル化部４０８は、信号フォーマット及びプロパティ検出部４０７に入力されたＴＳ信号から、上述のようにして選択された番組のＰＩＤを持つＴＳパケットに関してＳＩＴ（Ｓｅｌｅｃｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）などを再構成し、ＴＳ−ＭＵＸ部４１０へ出力する。
【０１０７】
ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９に入力されたＴＳ信号は、上述のようにして選択された番組のＰＩＤをもつＴＳパケットに関して、ＤＴＣＰオーディオデスクリプタの生成を行い、これらのデスクリプタをＰＭＴ（Ｐｒｏｇｒａｍ  Ｍａｐ  Ｔａｂｌｅ）に挿入し、その後、ＴＳパケットのＰＩＤを見て選択された番組を表すＴＳパケットのみを抽出するフィルタリングを行い、抽出されたＴＳパケットをＴＳ−ＭＵＸ部４１０に出力する。
【０１０８】
ＴＳ−ＭＵＸ部４１０では、ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９およびＴＳカプセル化部４０８の出力であるＴＳパケットの多重化（ＴＳ−ＭＵＸ）を行いデータブロック化部４１５へ出力する。ここで、ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９およびＴＳカプセル化部４０８の出力が重なった場合には、後段でのタイムスタンプ付加の正確さを考慮してＴＳパケットフィルタリング及びデスクリプタ挿入部４０９の出力を優先して、ＴＳカプセル化部４０８の出力は遅延させる。
【０１０９】
タイムスタンプ付加部４２０では、各ＴＳパケットに対して、２７ＭＨｚクロックで３２ｂｉｔのタイムスタンプを付加する。なお、ムービー出力の場合は、ムービーから出力する際に、タイムスタンプを付加しておく構成をとることもできる。この場合、スイッチャではタイムスタンプ付きＴＳを扱い、ＴＳパケットフィルタリング及びデスクリプタ挿入部４０９にはタイムスタンプ付きＴＳを出力し、信号フォーマット及びプロパティ検出部４０７にはタイムスタンプを除去したＴＳパケットを提供してもよい。そして、タイムスタンプ付加部４２０でタイムスタンプのないパケット（ＴＳカプセル化部の出力）にのみタイムスタンプを付加する。
【０１１０】
データブロック化部４１５では、ＣＣＩ検出部４１１を用いて、該データブロック内にＣＣＩが存在するかどうかを検出する。ここで、伝送するＴＳのコンテンツのＣＣＩ（ＰＭＴの第１ループまたは第２ループに設定したコピー制御情報）がＣＮＭ（Ｃｏｐｙ  Ｎｏ  Ｍｏｒｅ）、ＣＯＧ（Ｃｏｐｙ  Ｏｎｅ  Ｇｅｎｅｒａｔｉｏｎ）、ＣＮ（Ｃｏｐｙ  Ｎｅｖｅｒ）の場合、該データブロック内にＣＣＩが存在しなければ、暗号化ブロックにエンベデドＣＣＩが存在しないため、ＤＴＣＰ（ＤＴＣＰ−ＩＰ）などによるＩＰプロトコルによる出力は禁止する。
【０１１１】
さて、ＡＫＥ部４１４は、内部に認証部暗号化鍵交換部を具備する。信号フォーマット及びプロパティ検出部４０７で検出したＴＳ信号のＣＣＩを認証とＡＫＥ部４１４に送る。ここで、ＣＣＩがＣＦ（Ｃｏｐｙ  Ｆｒｅｅ）以外の場合、すなわち、ＣＮＭ（Ｃｏｐｙ  Ｎｏ  Ｍｏｒｅ）、ＣＯＧ（Ｃｏｐｙ  Ｏｎｅ  Ｇｅｎｅｒａｔｉｏｎ）、ＣＮ（Ｃｏｐｙ  Ｎｅｖｅｒ）の場合、認証と鍵交換（ＡＫＥ）を行う。このＡＫＥ部４１４は、認証と鍵交換に関する設定情報（ＡＫＥ設定情報）を取得し、このＡＫＥ設定情報に関連した情報、たとえば、コピー保護情報と暗号化鍵変更情報をデータブロック化部４１５やデータブロックヘッダ生成部４１６、暗号化部４１７に出力する。
【０１１２】
ＡＫＥ部４１４は、パケット送信装置とパケット受信装置が、認証局などにより正当な機器であることを保証されるなど規定の条件を備えていることを検証することによって認証処理を実行し、認証処理後にパケット送信装置とパケット受信装置とで暗号化鍵を共有し、入力端子情報と、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報より生成する伝送条件とにより、暗号化鍵を更新し、暗号化データ生成部は、暗号化鍵を用いてＡＶデータを暗号化する。
【０１１３】
データブロック化部４１５は、管理制御部４１３から与えられる送信パラメータに従って、ＴＳ−ＭＵＸ部４１０から入力されるタイムスタンプ付きパーシャルＭＰＥＧ−ＴＳを特定長のデータブロックにブロック化する。このデータブロック長はデータブロックヘッダ生成部４１６に入力される。
【０１１４】
データブロックヘッダ生成部４１６は、その特定長を表すサイズ情報を含むと共に、前記検出されたデータフォーマット情報又は属性情報が前記コンテンツデータの伝送、複製、又は再生に関する制御情報である場合にはその制御情報を含むデータブロックヘッダを生成する。
【０１１５】
データブロック化部４１５でブロック化されたブロックデータは、暗号化部４１７に入力される。暗号化部４１７はＡＫＥ部４１４から与えられる暗号化鍵を用いてＡＥＳ（Advanced Encryption Standard）暗号化を行う。なお、暗号化方式はＡＥＳ以外のＤＥＳ（Data Encryption Standard）など一般的な暗号化方式も用いることができる。暗号化部４１７において暗号化されたデータブロックは、データブロックパケット生成部４１８に入力される。データブロックパケット生成部４１８は、データブロックヘッダ生成部４１６で生成された該データブロックに付加されるべきデータブロックヘッダと入力されたデータブロックとを結合し、伝送パケットとする。
【０１１６】
この伝送パケットは、プロトコル処理部４１９に入力され、ＨＴＴＰ、ＴＣＰ、ＩＰなどのプロトコル処理をされて、Ｅｔｈｅｒｎｅｔ（登録商標）−ＭＡＣ層に渡され、イーサネット（登録商標）フレームとなり、家庭内のネットワーク上で伝送し、別室のテレビ受像機などにＴＳを用いてコンテンツを伝送する。
【０１１７】
なお、ＡＫＥ部４１４は、パケット送信装置とパケット受信装置との間で、認証実行モードと認証不実行モードとを持ち、暗号化データ生成部は、ＡＫＥ部４１４における認証実行モード及び認証不実行モードのいずれであっても、データブロックヘッダの付加制御を行う。すなわち、暗号化部４１７は、コピー制御情報（ＣＣＩ）がコピー制御を行うことを意味する場合に、ＣＣＩから生成した暗号化モード情報をデータブロックヘッダに含め付加する。また、コピー制御情報がコピー制御をしない意味の場合には、データブロックヘッダを付加しないように制御することもできる。
【０１１８】
さらに、この場合、ＡＫＥ部４１４は、入力端子情報と、ＥＰＧ情報に含まれるデータフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報より生成する認証条件とにより、パケット受信装置との間で認証を行うこともできる。ここで、パケット送信装置は、さらに、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報の少なくとも１つとからなる制御認証情報を、ＡＶデータのプログラム単位毎にアクセス位置を指定するＵＲＩ情報、または、Ｑｕｅｒｙにより拡張されたＡＫＥアドレスとポートに関するＵＲＩ情報により、前記プログラムのリストとして、前記パケット受信装置に通知するアクセス位置通知部を備える。
【０１１９】
また、パケット送信装置はさらに、パケット受信装置からプログラムリストの送信要求を受けると、データフォーマット情報と、属性情報と、課金情報、コピー制御情報、有効期限情報及び有効再生回数情報の少なくとも１つとからなる制御認証情報を、ＡＶデータのプログラム単位毎にアクセス位置を指定するＵＲＩ情報、または、Ｑｕｅｒｙにより拡張されたＡＫＥアドレスとポートに関するＵＲＩ情報により、前記プログラムのリストとして、前記パケット受信装置に通知するアクセス位置通知部を備えてもよい。
【０１２０】
また、パケット送信装置はさらに、ＡＶデータの単位プログラムのコピー制御情報がコピー制御を行わない意味の場合に、ＡＶデータのデータフォーマット情報を表す第１のＭＩＭＥ−Ｔｙｐｅと、ＡＶデータに間欠的に前記データブロックヘッダを付加したデータのデータフォーマット情報を表す第２のＭＩＭＥ−Ｔｙｐｅの２つのＭＩＭＥ−Ｔｙｐｅを生成し、ＡＶデータのプログラム単位毎にアクセス位置を指定する２つの拡張ＵＲＩ情報を前記パケット受信装置に提示するアクセス位置通知部を備えてもよい。
【０１２１】
また、２つの拡張ＵＲＩ情報は、Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ（ＵＰｎＰ）におけるｒｅｓのＵＲＩ指定に使用し、前記２つのＭＩＭＥ−Ｔｙｐｅは前記ｒｅｓのａｔｔｒｉｂｕｔｅであるｐｒｏｔｏｃｏｌＩｎｆｏの第３フィールドに挿入することによりコンテンツの識別を行う。
【０１２２】
パケット送信装置はさらに、パケット受信装置に送信するＡＶデータ及び非ＡＶデータ（ＥＰＧ情報などのメタデータ）をそれぞれ一時的に保持する第１及び第２バッファと、第１及び第２バッファのいずれかに保持されたデータが優先してパケット受信装置に送信されるように優先制御する構成をとることもできる。この場合、管理制御部４１３は、非ＡＶデータが前記第２バッファでオーバーフローしないことを維持しつつ、ＡＶデータが前記第１バッファから優先して出力されるように、優先制御を行うことを特徴とする。
【０１２３】
また、プロトコル処理部４１９は、管理制御部４１３によってＡＶデータの伝送プロトコルとして、Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ（ＴＣＰ）と決定された場合は、ＴＣＰコネクションを永続的接続にして前記伝送を行うことを特徴とする場合もある。さらに、前記認証部は、Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ（ＤＴＣＰ）方式に従って、パケット受信装置と暗号化鍵を共有するための認証と鍵交換を行うことを特徴とする。
【０１２４】
プロトコル処理部４１９は、ＨＴＴＰによるパケット化を行う場合、レンジリクエストまたはデータ取得コマンドなどによりパケット化を行なう。送信データがＭＰＥＧの場合には、ＭＰＥＧストリームにおけるタイムベース不連続発生情報または連続性情報、ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報、ＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの時刻情報、或るＩピクチャから次のＩピクチャの間に存在するＰピクチャとＢピクチャの各個数または合計個数のうち少なくとも１つの情報を参照して前記パケット化を行うこともできる。
【０１２５】
また、プロトコル処理部４１９は、ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報として、ＡＶデータが複数の異なるフォーマットであった場合にもオリジナルに持っている複数のＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報より、複数の異なるフォーマット間で共通なＩピクチャまたはＰピクチャまたはＢピクチャ位置情報または時刻情報を生成し、この共通のＩピクチャまたはＰピクチャまたはＢピクチャ位置情報または時刻情報を用いて前記ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報または時刻情報の参照情報と前記パケット化を行うこともできる。
【０１２６】
また、プロトコル処理部４１９は、ＨＴＴＰに従ったパケット化を行う場合、チャンク伝送方式で前記パケット化を行ない、ＨＴＴＰパケットのペイロード長が前記パケット送信装置で決定された値となるように前記パケット化を行うこともできる。
【０１２７】
また、プロトコル処理部４１９は、ＨＴＴＰに従ったパケット化を行う場合は、ＨＴＴＰパケットのペイロード長が、暗号化情報ヘッダおよび整数個のトランスポートパケット（ＴＳ，１８８バイト長）により構成されるデータの長さ（暗号化情報ヘッダに１８８バイトの整数倍長を加算した長さ）、または、データブロックヘッダと整数個のタイムスタンプつきＴＳ（ＴＳに４バイトのタイムスタンプを付加し、１９２バイト長）により構成されるデータの長さ（暗号化情報ヘッダに１９２バイトの整数倍長を加算した長さ）となるように前記パケット化を行うこともできる。
【０１２８】
また、プロトコル処理部４１９は、ＨＴＴＰによる伝送として、レンジリクエスト方式とチャンク伝送方式を切り替えて行うこともできる。
【０１２９】
また、プロトコル処理部４１９は、ＨＴＴＰによる伝送として、パケット送信装置の出力がライブ放送の受信信号またはライブ放送の受信チャネルの切り替えまたは蓄積されたプログラム選択時の再生信号の場合には、チャンク伝送を行い、プログラム選択後の蓄積メディアから再生されたプログラムからの再生信号の場合には、レンジリクエストを用いて再生を切替えて行う。
【０１３０】
また、プロトコル処理部４１９は、ＨＴＴＰによる伝送とＲＴＰによる伝送を切り替えて前記ＡＶデータを伝送することで、きめこまかな再生制御を実現できる。
【０１３１】
次に受信側の処理を図９を用いて説明する。受信部５０１は、セキュアＩＰパケット受信処理部５０２をコアとして構成される。受信側において、プロトコル処理部５０３は、ネットワークより入力されるイーサネット（登録商標）フレームに対して、ＭＡＣヘッダを元にフィルタリングして受信し、ＩＰパケットを復元する。なお、一般のＥｔｈｅｒｎｅｔ（登録商標）系においては、機器のＭＡＣアドレスはルータのＳｕｂｎｅｔ境界を越えて伝送されないため、送受信機器のＭＡＣアドレスを事前に登録しておき、そのＭＡＣアドレスによる通信相手の識別を行うことによって、ＩＰパケットの伝送範囲をＩＰアドレスのＳｕｂｎｅｔ内に収めることができる。
【０１３２】
データブロックパケット受信部５０４は、プロトコル処理部５０３から送られるデータパケットに対して、データブロックヘッダ検出部５０５でヘッダを識別し、ＡＫＥ部５０６にヘッダ情報を渡す。ＡＫＥ部５０６は、暗号の復号鍵を生成し、復号化部５０７に渡す。なお、ＡＫＥ部５０６は、規定の動作シーケンスに従い、認証と鍵交換を行なう。
【０１３３】
送信側と受信側の間で認証と鍵交換が成立すれば、暗号化されたＡＶデータを受信しても暗号の復号ができる。送信側と受信側の間で認証と鍵交換が成立していなければ、暗号化されたＡＶデータを受信しても暗号の復号ができない。
【０１３４】
復号化部５０７によって復号化されたＡＶデータは、データブロック生成部によって個々のデータブロックに区分され、デマルチプレクサ部５０９でデータパケットとＴＳパケットとに分離される。
【０１３５】
分離されたデータパケットはデータパケット検出部５１０で検出された後、信号フォーマット及びプロパティ検出部で、ＴＳパケットによって表される映像信号の属性、例えばコピー制御条件など、として検出される。
【０１３６】
分離されたＴＳパケットはＴＳパケットフィルタリング部５１２でフィルタリングされ、ＴＳインタフェース５１３を介して外部へ出力される。
【０１３７】
ところで、パーシャルＭＰＥＧ−ＴＳは、たとえば、日本における地上デジタル放送、衛星デジタル放送、ＣＡＴＶ、インターネットや高速ＩＰ網配信システムにより伝送されるデジタル放送信号をデジタル放送チューナで受信し、選局する。ここで、放送局より送られるフルＴＳから、番組（プログラム）を構成するパーシャルＭＰＥＧ−ＴＳが抽出される。パーシャルＭＰＥＧ−ＴＳに多重化されているＰＳＩ／ＳＩとしては、ＰＡＴ、ＰＭＴ、ＤＩＴ、ＳＩＴ（例えば、ＡＲＩＢ規格、ＳＴＤ−Ｂ２１参照）などがあり、ＰＭＴはＤＴＣＰデスクリプタを含んでいる。また、ＤＴＣＰデスクリプタは、アナログコピー制御情報とデジタルコピー制御情報を含んでいる。たとえば、あるチャンネルのある番組のデジタルコピー制御情報において、ＰＭＴ第１ループのデジタルコピー制御情報とＰＭＴ第２ループのデジタルコピー制御情報が双方とも存在する場合には、ＰＭＴ第２ループのデジタルコピー制御情報を優先してその番組のデジタルコピー制御情報とする。またＰＭＴ第１ループのデジタルコピー制御情報とＰＭＴ第２ループのデジタルコピー制御情報の片方しか存在しない場合には、その存在する片方のデジタルコピー制御情報をその番組のデジタルコピー制御情報とする。これらの規定は、たとえば、ＡＲＩＢ規格、ＴＲ−Ｂ１４、第４編、「デジタルコピー制御」の章に記述されており、デジタル放送で運用されている。ただし、著作権に関する解釈や考え方は、情報公開やＩｎｔｅｒｎｅｔの発展普及などに伴って時代と共に変化していくため、前述の規定はあくまで一例であり、それ以外の運用も可能である。
【０１３８】
今、ある放送チャンネルのある番組のデジタルコピー制御情報において、ＰＭＴ第２ループのデジタルコピー制御情報がＣＯＧ（Ｃｏｐｙ  Ｏｎｅ  Ｇｅｎｅｒａｔｉｏｎ、１世代コピーのみ可能）の場合に、暗号化部４１７は、パーシャルＭＰＥＧ−ＴＳ信号を暗号化する。さらに、データブロックヘッダ生成部４１６は、ＡＫＥ部４１４から送られてくるＣＯＧを表わす暗号化モードおよび、暗号化鍵更新情報（１ビット以上の情報）などのＡＫＥ情報を暗号化情報ヘッダとして付加する。
【０１３９】
また、今、あるチャンネルのある番組のデジタルコピー制御情報において、ＰＭＴ第２ループのデジタルコピー制御情報がＣＦ（Ｃｏｐｙ  Ｆｒｅｅ、コピー可能）の場合に、暗号化部４１７は、パーシャルＭＰＥＧ−ＴＳ信号を暗号化しない。さらに、データブロックヘッダ生成部４１６は、ＡＫＥ部４１４から送られてくる前述のＣＦを表わすＥＭＩ（暗号化モード情報）および、シード情報（１ビット以上の情報）などのＡＫＥ情報を暗号化情報ヘッダとして付加し、プロトコル処理部４１９に出力する。なお、ここで、外部より暗号化情報ヘッダを付加しないように制御される場合には、暗号化情報ヘッダは付加されない。
【０１４０】
また、外部入力データまたは、ＰＳＩ／ＳＩに多重されて入力されるパケットデータに送信許可情報を含めることができる。たとえば、ＭＰＥＧ−ＴＳのＰＭＴの第１ループまたは第２ループが持っているデジタルコピー制御記述子（たとえば、ＡＲＩＢ  ＴＲ−Ｂ１４、第２編、第４編を参照）の中にパケットデータ送信許可情報を含める。この場合、放送局など送信側の設備変更を伴う。
【０１４１】
以上のように、暗号化実行の有無および、暗号化情報ヘッダ付加の有無は、パーシャルＴＳのコピー制御情報と外部入力や内部設定で決められる条件により一意的に決めることができる。
【０１４２】
プロトコル処理部４１９は、データブロックパケット生成部４１８から出力されるデータに対して、管理制御部４１３からの送信条件パラメータを用いて、ＴＣＰ／ＩＰのヘッダを付加する。また、プロトコル処理部４１９は、８０２．１Ｑ（ＶＬＡＮ）方式を用いてＭＡＣヘッダを付加することでイーサネット（登録商標）フレームに変換し、送信フレームとしてネットワークに出力する。ここで、ＭＡＣヘッダ内のＴＣＩ（Ｔａｇ  Ｃｏｎｔｒｏａｌ  Ｉｎｆｏｒｍａｉｔｉｏｎ）内のＰｒｉｏｒｉｔｙ（ユーザ優先度）を高く設定することにより、ネットワーク伝送の優先度を一般のデータよりも高くすることができる。
【０１４３】
図１０にパーシャルＭＰＥＧ−ＴＳを暗号化してＨＴＴＰ／ＴＣＰ／ＩＰ／Ｅｔｈｅｒｎｅｔ（登録商標）で伝送する場合のＥｔｈｅｒｎｅｔ（登録商標）フレームの一例を示す。ここで、パーシャルＭＰＥＧ−ＴＳパケット（１８８バイト）には４バイトのタイムスタンプがヘッダとして付加されている。この４バイトのタイムスタンプ２７ＭＨｚのクロックでサンプリングされたものである。
【０１４４】
さて、図１１は図８、図９の動作をプロトコルスタックを用いて補足説明した図である。図１１において、送信側、受信側ともコンテンツ、メタデータ、管理制御の３種類のデータを扱う。管理制御データは送信側と受信側の機器の動作設定、制御、管理を行うためのデータである。また、メタデータはコンテンツの伝送前に、コンテンツを選択したり、コンテンツ受信中にそのコンテンツの属性説明を確認するためのデータである。
【０１４５】
また、図１２は図１１の動作を送受信部にまとめた説明図である。
【０１４６】
コンテンツであるＭＰＥＧ−ＴＳは暗号化鍵により暗号化される。そして暗号化されたＭＰＥＧ−ＴＳは、ＡＶデータとしてＴＣＰ（またはＵＤＰ）パケットのペイロードとしてＴＣＰパケットが生成される。さらにこのＴＣＰパケットはＩＰパケットのデータペイロードとして使用され、ＩＰパケットが生成される。さらにこのＩＰパケットはＭＡＣフレームのペイロードデータとして使用され、イーサネット（登録商標）ＭＡＣフレームが生成される。なお、ＭＡＣとしてはイーサネット（登録商標）であるＩＥＥＥ８０２．３だけでなく、無線ＬＡＮ規格のＩＥＥＥ８０２．１１のＭＡＣにも適用できる。
【０１４７】
イーサネット（登録商標）ＭＡＣフレームは、イーサネット（登録商標）上を送信側から受信側へ伝送される。受信側で所定の手順に従って復号鍵を生成する。そして、受信したイーサネット（登録商標）ＭＡＣフレームからＩＰパケットがフィルタリングされる。さらにＩＰパケットからＴＣＰ（またはＵＤＰ）パケットが抜き出される。そして、ＴＣＰ（またはＵＤＰ）パケットからＡＶデータが抜き出され、交換鍵と鍵変更情報より復元された復号鍵により、ＭＰＥＧ−ＴＳ（コンテンツ）が復号され出力される。
【０１４８】
以上のように、本実施の形態によれば、パーシャルＭＰＥＧ−ＴＳ信号などのＡＶストリームをパケット送信機器で暗号化してＩＰパケット化してネットワークにより伝送し、ＩＰパケット受信機器で元の信号に復号することが可能である。
【０１４９】
なお、図７において、スイッチングハブを用いたネットワークトポロジーを工夫することにより、ストリーム伝送とファイル転送を共存させることができる。たとえば、１階と２階の間のネットワーク３０５の帯域を、従来の技術で説明した１００Ｍｂｐｓから１Ｇｂｐｓに拡張することによって、１階と２階のＰＣ間でのファイル転送をバックグラウンドで行いながら、同時に、１階および２階のＤＶＤレコーダ、ＰＣ、ＴＶの間でＭＰＥＧ−ＴＳを暗号化してリアルタイムで伝送することができる。たとえば、市販されている１００Ｍｂｐｓのポートを８つ、１Ｇｂｐｓのポートを１つ持ったスイッチングハブを用い、１階と２階を結ぶネットワーク３０５に１Ｇｂｐｓのポートを接続し、残りの８ｃｈの１００ＭｂｐｓのポートにＴＶなどのＡＶ機器を接続する。１００Ｍｂｐｓのポートは８つなので、８つのポートのデータがそれぞれ最大１００Ｍｂｐｓで入力されて１Ｇｂｐｓのポートに出力されたとしても、１００Ｍｂｐｓ×８ｃｈ＝８００Ｍｂｐｓと１Ｇｂｐｓより小さいため、８つのポートから入力されたデータはスイッチングハブ内部で失われず全て１Ｇｂｐｓのポートに出力される。よって、１階で発生したデータは全て２階に伝送することが可能である。また、逆に２階で発生したデータも全て１階に伝送することが可能である。以上のように、スイッチングハブを用いる場合、ネットワークトポロジーを工夫することによりストリーム伝送とファイル転送を共存させることができる。
【０１５０】
また、図８において、ＡＫＥ部４１４は認証モード決定部を内部に持つ。ＡＫＥ部４１４に対してＡＫＥ設定情報として、認証用のＴＣＰのポート番号が、管理制御データとして、管理制御部４１３に入力される。ここで、認証用のＴＣＰポート情報は、ＵＰｎＰ−ＡＶの仕組みを用いて、コンテンツ毎または放送チャネル毎にアクセス位置を指定するＵＲＩ、または、Ｑｕｅｒｙにより拡張されたＵＲＩにより与えることができる。ここでＵＲＩの主データ部にはコンテンツのＵＲＩ情報、Ｑｕｅｒｙ部にはそのコンテンツの認証情報をマッピングする。ここで、もし、Ｑｕｅｒｙ部がなければそのコンテンツの伝送には認証が不必要であり、Ｑｕｅｒｙ部が存在すればそのコンテンツの伝送には認証が必要である様にモード設定できる。ＵＲＩとＱｕｅｒｙの例は、例えば下記の形式で与えることができる。
【０１５１】
＜ｓｅｒｖｉｃｅ＞：／／＜ｈｏｓｔ＞：＜ｐｏｒｔ＞／＜ｐａｔｈ＞／＜ｆｉｌｅｎａｍｅ＞．＜ｅｘｔ＞
？ＡＫＥＨＯＳＴ＝＜ｈｏｓｔ２＞：ＡＫＥＰＯＲＴ＝＜ｐｏｒｔ２＞
ここで、＜ｈｏｓｔ＞：＜ｐｏｒｔ＞／＜ｐａｔｈ＞／＜ｆｉｌｅｎａｍｅ＞．＜ｅｘｔ＞はＡＶコンテンツのＵＲＩとファイル名称を表しており、「？」以下のＱｕｅｒｙ部における＜ｈｏｓｔ２＞、＜ｐｏｒｔ２＞は、それぞれ認証用ＩＰアドレスとポート番号を表している。
【０１５２】
送信側はこのＵＲＩとＱｕｅｒｙで認証の実行モード情報を受信側に与える。受信側はＷＥＢブラウザやＵＰｎＰ−ＡＶのＣＤＳ（Ｃｏｎｔｅｎｔ  Ｄｉｒｅｃｔｏｒｙ  ｓｅｒｖｉｃｅ）を用いて、上記のＵＲＩとＱｕｅｒｙ情報を受け取り、認証モード決定部６０１が認証モードを決定することができる。
【０１５３】
図８において、管理制御部４１３に入力されるＡＶデータの入力ソース情報（放送、外部ムービーからの入力）としては、たとえば次のケースが考えられる。
（ケース１）ＡＶデータがコピーフリーコンテンツを放送する放送チャネルで受信されるコンテンツである場合。この様な放送チャネルの例としては、たとえば、アナログ放送であるＶＨＦ、ＵＨＦ、またはＢＳアナログ放送の放送チャネルがある。
（ケース２）ＡＶデータが一時的にでもコピーフリーでないコンテンツを放送する放送チャネルで受信されるコンテンツの場合。この様な放送チャネルの例としては、たとえば、ＢＳデジタル放送の有料チャネルやＣＡＴＶ放送による有料チャネルがある。この一定期間でもコピーフリーでないコンテンツを放送する放送チャネルのコピー制御情報は、コピーネバー、コピーワンジェネレーション、およびＥＰＮ（Ｅｎｃｒｙｐｔｉｏｎ  Ｐｌｕｓ  Ｎｏｎ−ａｓｓｅｔｉｏｎ）フラグ付きコピーフリーが放送内容により時々刻々と切り替わる。
【０１５４】
ここで、一時的にでもコピーフリーでないコンテンツを放送する放送チャネルの受信は、放送の配信を行う事業者との間での認証部により正当な受信装置または受信ユーザであることを認証された場合に行われるように制御できる。この認証の例としては、日本のデジタル衛星放送のＢ−ＣＡＳ（ＢＳ−Ｃｏｎｄｉｔｉｏｎａｌ  Ａｃｃｅｓｓ  Ｓｙｓｔｅｍｓ）カード、または米国のＣＡＴＶ放送で使用されるＰＯＤ（Ｐｏｉｎｔ  Ｏｆ  Ｄｅｐｌｏｙｍｅｎｔ）カードなどのセキュリティモジュールによる認証が考えられる。
【０１５５】
また、暗号化情報ヘッダの付加制御は、たとえば以下の様に行なう。すなわち、コピーフリーコンテンツを放送する放送チャネルを受信した場合には付加しない。また、一定期間でもコピーフリーでないコンテンツを放送する放送チャネルを受信した場合には付加する。さらに、ＡＶデータが蓄積メディアよりコピーフリータイトルのコンテンツを再生した場合には付加しない。そして、ＡＶデータが蓄積メディアよりコピーフリーでないタイトルのコンテンツを再生した場合には付加する。なお、送信側における暗号化情報ヘッダの付加分される場合、ＨＴＴＰのレスポンスヘッダには、伝送されるデータ長にこの暗号化情報ヘッダの長さだけ増加したＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈが記述される。
【０１５６】
以上のように、暗号化情報ヘッダの付加制御を行うことにより、著作権者が設定したＡＶコンテンツのＣＣＩ（コピー制御情報）をネットワーク伝送においても継承して伝えていくことができる。さらに、送信側と受信側で暗号化情報ヘッダの付加制御のルールを揃えることにより異機種間での動作互換性を確保することができる。
【０１５７】
図１３は図８を簡略的に表した図であり、代表的な構成要素として、デジタルチューナ４０３、ＴＳインタフェース４０４、スイッチャ４０５、セキュアＩＰ化送信制御部４０２、伝送プロトコル処理部４１９を備える。
【０１５８】
図１３において、デジタルチューナ４０３より入力されるＡＶ信号は、それぞれ、日本のデジタル放送（地上波デジタル放送、ＢＳデジタル放送、１１０度ＣＳデジタル放送）を受信したコピーワンジェネレーション（ＣＯＧ）にコピー制御された（著作権保護が実施されているという意味）ＭＰＥＧ−ＴＳ信号である。また、ＴＳインタフェース４０４より入力されるＡＶ信号は、ＨＤＴＶ対応のカムコーダ（ムービー）で撮影されたコピーフリー（著作権保護が実施されていないという意味）のＭＰＥＧ−ＴＳ信号である。
【０１５９】
上記において、パケット送信装置でＡＶデータの単位プログラムが第１のＭＩＭＥ−Ｔｙｐｅ（ブロックヘッダを付加する、かつ、暗号化も実施する場合）と、第２のＭＩＭＥ−Ｔｙｐｅ（ブロックヘッダを付加する、かつ、暗号化は実施しない場合）を用いることについて説明した。ここでは、更に、ＨＤＴＶ対応のカムコーダ（ムービー）で撮影されたコピーフリーのＭＰＥＧ−ＴＳ信号第３のＭＩＭＥ−Ｔｙｐｅ（ブロックヘッダを付加しない、かつ、暗号化も実施しない場合）を用いる。
【０１６０】
ＭＩＭＥ−Ｔｙｐｅによるコンテンツの識別に関しては、前述した＜ｒｅｓ＞のａｔｔｒｉｂｕｔｅであるｐｒｏｔｏｃｏｌＩｎｆｏの第３フィールドに挿入されたＭＩＭＥ−Ｔｙｐｅや、ＨＴＴＰのレスポンスヘッダに挿入されたＭＩＭＥ−Ｔｙｐｅからコンテンツの識別を行うことができる。
【０１６１】
なお、ＨＤＴＶ対応のカムコーダ（ムービー）の撮影指揮者（著作権者の意味）が撮影したＭＰＥＧ−ＴＳ信号をコピーフリーにしたくない場合、著作権に関する法令にしたがって著作権の主張を行うことにより、自分で撮影したＭＰＥＧ−ＴＳ信号のＣＣＩをＣＯＧやＣＮに設定して運用することもできるし、また、有償コンテンツとしてサーバにアップロードして課金することもできる。この場合、たとえば、第１のＭＩＭＥ−Ｔｙｐｅ（ブロックヘッダを付加する、かつ、暗号化も実施する）を用いることができる。
【０１６２】
なお、本実施例では著作権保護方式としてＤＴＣＰ方式を用いた説明を行ったが、著作権保護方式としてはＤＴＣＰ方式以外のＤＲＭ方式でも、同様の効果が得られる。
【０１６３】
（実施の形態２）
次に、本発明の実施の形態２について説明する。図１４は、本実施の形態におけるパケット送信部の構成を示すブロック図である。図１４は、代表的な構成要素として、デジタルチューナ４０３、ＴＳインタフェース４０４、スイッチャ４０５、セキュアＩＰ化送信制御部４０２、伝送プロトコル処理部４１９、および蓄積部１００１を備える。図１４の構成は、図８および図１３に示された実施の形態１のパケット送信部の構成に加えて、蓄積部１００１を備える。以下、実施の形態１と同じ部分の説明は省略し、異なる部分のみを説明する。
【０１６４】
このパケット送信部は、デジタルチューナ４０３および、ＴＳインタフェース４０４に接続された蓄積部１００１を具備する。ここで、蓄積部１００１は、ハードディスクドライブ（ＨＤＤ）や光ディスク（ＣＤやＤＶＤなど）や半導体ディスク（ＳＤカードメモリなど）やその組み合わせを採用することができる。本実施の形態において、このパケット送信部は、ハードディスクや光ディスクなどに蓄積されたパーシャルＭＰＥＧ−ＴＳデータなどを、たとえば、受信部からのＨＴＴＰのレンジリクエストを用いて伝送する。
【０１６５】
このレンジリクエストは、蓄積部１００１に蓄積されたパーシャルＭＰＥＧ−ＴＳのファイルの先頭からの距離、たとえばＡ、Ｂ（Ａ、ＢはＡ＜Ｂを満足する０以上の整数）でレンジ先頭とレンジ末尾を選んでリクエストされる。通常、一般データに対してＡ、Ｂは自由な値を選べるが、ＭＰＥＧ−ＴＳのような映像データをレンジＧＥＴする場合、そのＧＯＰやＰｉｃｔｕｒｅ構造に着目すれば、効率のよい伝送ができる。しかしながら、受信側は、送信側の蓄積ファイルのどの部分でＧＯＰを構成しているとか、どの部分がＩピクチャであるとかは分からない。そこで、送信側は受信側よりＨＴＴＰのレンジリクエストを受け取ると、そのレンジ先頭とレンジ末尾にそれぞれ最も近いＧＯＰをＨＴＴＰレスポンスとして返す。この伝送方法を仮にＨＴＴＰアライメントレスポンス法（ＨＴＴＰ  ＡＶ  Ａｌｉｇｎｍｅｎｔ  Ｄａｔａ  Ｕｎｉｔ  Ｒｅｓｐｏｎｓｅ  Ｍｅｔｈｏｄ；ＨＡＲ法と略す）と呼ぶ。このような伝送モードの選択のトリガとしては、たとえば次の方法がある。
【０１６６】
１）送信側（サーバ）と受信側（クライアント）の間でＵＰｎＰ−ＡＶなどのメカニズムを用いて事前にネゴを行う。
【０１６７】
２）ＨＴＴＰのリクエストヘッダに、ＨＡＲ法でのレスポンスを期待してＨＡＲ法を使用することを表す文字列などの指示情報を挿入する。たとえば、
ｈａｒ−ｖａｌｕｅ  ＝  ｇｏｐ
をＨＴＴＰリクエストに挿入する。
【０１６８】
ＨＡＲ法に対応していないサーバは、この指示情報には反応しないが、ＨＡＲ法に対応しているサーバはこの指示情報に反応して、レンジリクエストされたレンジ先頭にもっとも近いＧＯＰ先頭をリクエストされたデータから探し出しレスポンスのレンジ先頭に設定する、また、レンジリクエストされたレンジ末尾にもっとも近いＧＯＰ先頭をリクエストされたデータから探し出しレスポンスのレンジ末尾に設定する。そして、サーバはＨＴＴＰのレスポンスヘッダにＨＡＲ法によるレスポンスであることを表す文字列などの指示情報を挿入する。たとえば、
ｈａｒ−ｖａｌｕｅ  ＝  ｇｏｐ
をＨＴＴＰレスポンスに挿入する。
【０１６９】
これらの動作によって、クライアントはサーバ内データに対して適当なレンジリクエストしたにもかかわらず、クライアントはＨＴＴＰレスポンスに挿入されたＭＰＥＧ−ＴＳをＧＯＰ単位で部分ＧＥＴできる。
【０１７０】
ＭＰＥＧ−ＴＳが連続的に記録されたファイルの場合は、ひとたび、ＧＯＰ単位のレスポンスを受け取れば、映像を連続フレームで受け取りたい場合に、直前に受け取ったレンジ末尾の値より、次のＧＯＰ先頭の位置を容易に計算できる。たとえば、直前に受け取ったレンジ末尾の値１バイト足すことで次のＧＯＰ先頭の位置が分かる。
【０１７１】
以上のように第２の実施例では、受信側より送信側にＨＴＴＰのレンジリクエストによるデータ要求を行う場合に、伝送されるデータブロックの先頭データまたは末尾データを、送信側で管理しているＧＯＰなどのデータブロック単位の先頭データと一致させる。たとえば、データがＭＰＥＧの場合には、送信側で管理するデータブロックの単位は、上記の例で説明したＧＯＰだけでなく、Ｐｉｃｔｕｒｅ、マクロブロック、ブロック、ＴＳパケット、または、タイムスタンプ付きＴＳパケットなどの単位に指定することができる。
【０１７２】
また、データブロックが送信装置に内蔵されたハードディスク（ＨＤＤと略す）やＣＤやＤＶＤ（ＤＶＤ−Ｒ、ＤＶＤ−ＲＡＭなど複数の種類がある）などの光ディスク、ＳＤメモリカードのような半導体ディスクの場合には、これはＨＤＤ（たとえば５１２バイトのＬＢＡ単位）やＣＤ（たとえば、２ｋＢ単位）やＤＶＤの各記録フォーマットが、論理ブロックの単位とすることもできる。
【０１７３】
よって、たとえば、データ（ファイルやストリーム）がＭＰＥＧの場合に、受信側より送信側にＨＴＴＰのレンジリクエストで要求するデータ範囲がＧＯＰ単位やＰｉｃｔｕｒｅ単位とデータ境界が合っていなくても、すなわち、データのアライメントが取れていなくても、あらかじめレスポンス単位をＧＯＰ単位やＰｉｃｔｕｒｅ単位にネゴシエーションなどで決めてあれば、サーバ（送信側）の処理としてＨＴＴＰレスポンスとして要求されたデータ範囲に近いところにあるＧＯＰ単位、Ｐｉｃｔｕｒｅ単位やＴＳパケット単位で境界を合わせたレスポンスとして返信できる。そこで、受信側では受信データから効率よくＭＰＥＧデコードを行うことができる。
【０１７４】
また、ＭＰＥＧ−ＴＳの例として、サーバがＢｌｕ−ｒａｙディスクレコーダの場合、ＰＬＡＹＬＩＳＴファイルやＣＬＩＰＩＮＦＯファイルを用いて効率よくＧＯＰ境界位置やＩピクチャ位置を認識して、ＧＯＰやＩピクチャデータを取り出すことができるので、サーバの動作負荷を下げることができる。また、ＭＰＥＧ−ＰＳの場合にも、サーバがＤＶＤ−ＲＡＭディスクレコーダで記録フォーマットがＤＶＤ−ＶＲ規格に準拠している場合、ＤＶＤ−ＶＲ方式ではＩＦＯファイルと呼ばれている管理ファイルを持っている。よって、サーバ側はこのＩＦＯファイルの管理情報を活用することにより、効率よくＧＯＰ境界位置やＩピクチャ位置を認識して、ＧＯＰやＩピクチャデータを取り出すことができるので、サーバの利用効率も上がる。以上のようにＰＬＡＹＬＩＳＴファイルやＣＬＩＰＩＮＦＯファイルやＩＦＯファイルと同様な構造を持ったデータ管理ファイルを活用することにより、サーバは容易に上述のＨＡＲ法を使用できる。
【０１７５】
この場合、サーバはクライアントから上記ＨＡＲ法によるレンジリクエスト値を受け取り、自身の持っているＩＦＯファイルと比較して返信するＧＯＰブロックを決定する。以上により、ＡＶコンテンツにＤＴＣＰ−ＩＰを適用して伝送することが可能となる。
【０１７６】
また、蓄積部７０１に暗号化されたコンテンツを記録しておき（いわゆるＤＲＭによる暗号化を適用したコンテンツが対象）、その記録されたコンテンツのリストを呼び出し、ユーザが視聴したいコンテンツ（映画、コンサート、ドラマなど）を選択する場合に暗号を解除するために、たとえば、次の方法を実装することができる。
【０１７７】
方法１）ユーザは、インターネットや電話回線を通じて、あるいはコンビニエンスストアなどで、暗号化されたコンテンツを復号するための情報を購入する。コンテンツは、ユーザが対象機器を購入した時点で、既に蓄積部７０１に、たとえば１００タイトル分の映画、コンサート、ドラマなどが記録されている場合に有効である。
【０１７８】
方法２）ユーザは、インターネットやＣＡＴＶ、放送を通じて、暗号化されたコンテンツをダウンロードする。さらに、ユーザはインターネットや電話回線を通じて、あるいはコンビニエンスストアなどで、暗号化されたコンテンツを復号するための情報を購入する。
【０１７９】
方法３）ユーザがパッケージメディアとしてコンテンツを購入した際に付属しているコンテンツの暗号を復号するための情報を使用する。
【０１８０】
また、このパケット送信部がＴＳストリームからＩフレーム位置情報生成部を具備する場合、蓄積部からパーシャルＭＰＥＧ−ＴＳデータなどをＨＴＴＰのレンジリクエストを用いて伝送する。このＨＴＴＰのレンジリクエストおよびレスポンスには、上述したＨＡＲ法でＩフレームに効率的にアクセスする方法について説明する。ここで、伝送モード選択のトリガとしては、たとえば次の方法がある。
【０１８１】
１）送信側（サーバ）と受信側（クライアント）の間でＵＰｎＰ−ＡＶなどのメカニズムを用いて事前にネゴを行う。
【０１８２】
２）ＨＴＴＰのリクエストヘッダに、ＨＡＲ法でのレスポンスを期待してＨＡＲ法を使用することを表す文字列などの指示情報を挿入する。たとえば、
ｈａｒ−ｖａｌｕｅ  ＝  ｉ−ｐｉｃｔｕｒｅ  ：  １
をＨＴＴＰリクエストに挿入する。ここで、
ｈａｒ−ｖａｌｕｅ  ＝  ｉ−ｐｉｃｔｕｒｅ  ：  ｎ  （ｎは整数）
の動作として、サーバ内のＩフレーム位置情報生成部は、“ｉ−ｐｉｃｔｕｒｅ”はレンジリクエストされた範囲におけるｉ−ｐｉｃｔｕｒｅの位置情報を計算、生成する。このレンジリクエストされた範囲におけるｉ−ｐｉｃｔｕｒｅの位置情報により、蓄積制御部７０１はＩピクチャデータをｎ個とばしで抜き出し、クライアントに送る。ｎの値が“＋”の場合は、レンジの最初から末尾方向にｉ−ｐｉｃｔｕｒｅのみを抜き出しｎ個とばしでクライアントに送り、いわゆる、順方向のフレーム飛ばしスキップ再生を行う。ｎの値が“−”の場合は、レンジの末尾から頭方向にｉ−ｐｉｃｔｕｒｅのみを抜き出しｎ個とばしでクライアントに送り、いわゆる、逆方向のフレーム飛ばしスキップ再生を行う。
【０１８３】
“ｈａｒ−ｖａｌｕｅ”を“  ＝  ｉ−ｐｉｃｔｕｒｅ  ：  ｎ  （ｎは整数）”に拡張することにより、クライアントはサーバ内データに対して適当なレンジリクエストしたにもかかわらず、クライアントはＨＴＴＰレスポンスに挿入されたＭＰＥＧ−ＴＳをＩピクチャ単位で部分ＧＥＴできる。
【０１８４】
また、サーバ内ＨＤＤに記録されたＭＰＥＧ−ＴＳの管理情報として、Ｉフレームの位置と概略サイズに関する情報があれば、その情報を用いてＩピクチャを含むデータをクライアントに送ることもできる。
【０１８５】
以上のように、サーバ内のＭＰＥＧファイルのＩフレーム位置情報を活用することにより、早送り、巻き戻し、スロー再生などの特殊再生を効率よく実現できる。そこで、一般に、ＤＲＭ対応ＡＶコンテンツをＤＴＣＰ−ＩＰを用いて伝送することが可能となる。
【０１８６】
なお、ＨＴＴＰによる伝送とＲＴＰによる伝送を切り替えてＡＶデータを伝送することもできる。ＲＴＰの場合は、ＲＴＣＰプロトコルを用いて適切な開始位置を指定すれば、そこにＲＴＰに対応したＨＡＲ法を適用することができる。
【０１８７】
なお、複数のファイルフォーマットに対して共通に使用できるピクチャ位置情報ファイルを用いて、異なるＭＰＥＧファイルシステムを採用したシステムに対して、そのファイルにおけるＩ／Ｐ／Ｂピクチャの位置情報、時刻情報などを共通のピクチャ情報ファイルとして取り扱うことにより、異なるファイルフォーマットを共通のプラットフォーム上で取り扱うことが可能となる。
【０１８８】
ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報は、前記ＡＶデータが複数の異なるフォーマットであった場合にもオリジナルに持っている複数のＩピクチャまたはＰピクチャまたはＢピクチャの位置情報、前記ＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの時刻情報より、複数の異なるフォーマット間で共通なＩピクチャまたはＰピクチャまたはＢピクチャ位置情報を生成し、この共通のＩピクチャまたはＰピクチャまたはＢピクチャ位置情報を用いて前記ＡＶデータのファイル内におけるＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャの位置情報、時刻情報の参照情報とする。これにより、たとえばＨＤＤに、異なる記録フォーマットで記録されているＭＰＥＧ−ＴＳファイルがあっても、リモート端末からは共通のＩまたはＰまたはＢピクチャの位置情報や時間情報で特定のピクチャに直接アクセスできるという大きなメリットがある。
【０１８９】
たとえば、パーシャルＴＳを記録したＨＤＤやＢＤディスクなどから、ＩまたはＰまたはＢピクチャの連続性およびファイル内での位置情報などを統一した「ピクチャ情報ファイル」を読み出す。ネットワークを介して離れた場所に存在する端末からは、この統一されたピクチャ情報ファイルをバイト位置や時刻情報（ｔｉｍｅｓｔａｍｐ）で参照することにより、異なるＴＳ記録フォーマットでも各ピクチャ位置をきめ細かに参照することができる。
【０１９０】
以上のように、きめ細かやで綺麗なスロー再生や高速再生などのトリック再生が実現される。なお、このピクチャ情報ファイルはリモート端末からローカル端末内の異なるフォーマットで記録されたＭＰＥＧ−ＴＳファイル内のピクチャ位置を共通のファイル形式で見せることができるフィルタ機能として考えることができる。すなわち、独自のファイル形式でＭＰＥＧ−ＴＳを記録したＡＶデータファイルとその関連情報ファイルより、共通のピクチャ情報ファイルを生成することができる。
【０１９１】
また、本実施の形態により、ＡＶコンテンツをＡＫＥや暗号処理を実装しない送受信装置による実装の場合にも、ＭＰＥＧのＩピクチャまたはＰピクチャまたはＢピクチャに効率よくアクセスできるという効果が奏される。
【０１９２】
また、ＨＴＴＰプロトコルを用いたレンジリクエストのプロトコルシーケンスは、送信データの一部だけを切り出して伝送するので、データ伝送が終わるごとにＴＣＰコネクションを切断する場合もありうる。そのような場合、元データは時間軸で連続していても、伝送された複数のデータブロック集合はＴＣＰコネクションの確立、切断、確立、切断を繰り返しで伝送されたものであり、データのタイムベースは不連続とみなされてしまい、パーシャルＭＰＥＧ−ＴＳの場合は、たとえば、ＤＶＢ規格やＡＲＩＢ規格、ＳＴＤ−Ｂ２１やＴＲ−Ｂ１４、１５に準拠した従来の処理を行うと、伝送データの先頭と末尾にＤＩＴなどのタイムベースの不連続情報の付加が必要となる。これによって、伝送データサイズが変化するとＨＴＴＰレスポンスのヘッダ内のＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈが、もともとリクエストした値から、暗号化情報ヘッダの付加分だけでなく、タイムベースの不連続情報の付加分だけ増加してしまう。なお、この暗号化情報ヘッダの付加分はパケット受信部で削除されるので、正味の伝送コンテンツとして扱わなくてよい。本発明では、以降の実施例でも、この暗号化情報ヘッダの付加分はパケット受信部で削除されるので、正味の伝送コンテンツとして扱わない。
【０１９３】
本実施例では、パーシャルＭＰＥＧ−ＴＳをＨＴＴＰで伝送する場合の新たな仕組みとして、特にタイムベースが不連続であることを指示されない限りは、ＨＴＴＰのレスポンスの先頭や末尾にＤＩＴなど不連続情報を挿入しないアルゴリズムとする。なお、ＭＰＥＧストリームにおける不連続発生連続性情報とは、たとえば、ＡＲＩＢ規格、ＡＲＩＢ−ＴＲ−Ｂ１４またはＡＲＩＢ−ＴＲ−Ｂ１４の第２編に記載されているＤＩＴ情報であり、これを元に別の論理記述で不連続発生連続性情報を生成することもできる。このストリームの不連続点とは、たとえば、ＭＰＥＧのパーシャルＴＳの場合、ＭＰＥＧ−ＴＳストリームのシステムタイムベースの不連続が発生する点、たとえば、ＰＣＲが不連続になる点、または、パーシャルＴＳを構成するパケットの内のどれか１つのトランスポートパケットヘッダのｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒの不連続が発生する点をさす。
【０１９４】
ここで、補助データファイルには、ＭＰＥＧ−ＴＳのＧＯＰ単位あるいはＩピクチャ単位でのデータ構造を記述してあるので、Ｒａｎｇｅ、Ｎｏ．１、Ｎｏ．２、Ｎｏ．３はそれぞれ、ＭＰＥＧ−ＴＳファイルのＧＯＰ単位あるいはＩピクチャ単位とすることができ、一般的なＭＰＥＧのデコード動作（デコードのアルゴリズムとシーケンスと同等の意味で用いている）に対して効率的なデータ伝送が実現できる。
【０１９５】
以上のように、サーバ内のＭＰＥＧファイルのＧＯＰ構造やＩフレーム位置情報を活用することにより、早送り、巻き戻し、スロー再生などの特殊再生を効率よく実現できる。そこで、一般に、ＤＲＭ対応ＡＶコンテンツをＤＴＣＰ−ＩＰを適用して効率よく伝送することが可能となる。
【０１９６】
（実施の形態３）
次に、本発明の実施の形態３について説明する。図１５は、本実施の形態におけるパケット送信部の構成を示すブロック図である。このパケット送受信部は、図１４に示した実施の形態２のパケット送信部の構成に加えて、ＭＰＥＧ−２／Ｈ．２６４トランスコーダ１１０１を備える。以下、実施の形態２と同じ部分の説明は省略し、異なる部分のみを説明する。
【０１９７】
このパケット送信部は、新たに蓄積部１００１に接続されたＭＰＥＧ−２／Ｈ．２６４トランスコーダ１１０１を具備する。ＭＰＥＧ−２／Ｈ．２６４トランスコーダ１１０１は、蓄積部１００１に蓄積されたＭＰＥＧ−２  ＴＳのファイルをＨ．２６４（Ｈ．２６４／ＡＶＣ形式と呼ばれている）にトランスコードする。このトランスコードによって、画質を保ちながらファイルサイズを約２分の１以下に削減できるため、より多くのファイルの蓄積が可能になるとともに、より狭い帯域でＨ．２６４ストリームを実時間伝送すること、あるいは、より高速にファイル転送することができる。
【０１９８】
たとえば、家庭内ネットワークを無線ＬＡＮ（８０２．１１ａ／ｂなど）で構築している場合、ＭＰＥＧ−２では、ＨＤＴＶのＴＳビットレートが約２５Ｍｂｐｓとなり、無線ＬＡＮでは帯域が不足する場合でも、Ｈ．２６４の場合、約８Ｍｂｐｓに伝送レートを削減できるため、本構成により余裕を持って家庭内でのＨＤＴＶの無線伝送が可能となる。また、ＳＤＴＶの場合は１．５Ｍｂｐｓ程度にできるので、たとえば６ｃｈでも９Ｍｂｐｓであり、主要放送局６局分のＭＰＥＧ−ＴＳを同時にホームサーバとクライアント間で伝送することが可能となる。
【０１９９】
なお、Ｈ．２６４の解説は、たとえば、「Ｈ．２６４／ＡＶＣ教科書」、大久保榮監修、株式会社インプレス発行、などで説明されている。
【０２００】
ＭＰＥＧ−２／Ｈ．２６４トランスコーダ１１０１におけるＣＣＩの取り扱いとして、たとえば、Ｈ．２６４はＭＰＥＧ−２のＴＳパケットにマッピングしてＭＰＥＧシステムで運用する場合、ＭＰＥＧ−２のＴＳでＣＣＩを含んでいるＰＭＴ中のＣＣＩモードの意味を変化させないで、「ＭＰＥＧ−２のＴＳのＰＭＴ」から「Ｈ．２６４のＴＳのＰＭＴ」に継承させる。ＭＰＥＧ−２からＨ．２６４へのトランスコードによりＰＡＴ、ＰＭＴが、それぞれ指定するプログラムマップテーブル（ＰＭＴ）とストリームＰＩＤは変化する。なお、ＳＩＴ、ＤＩＴは適切な値に書き換えられる。以上により、ＡＶ信号部分をＭＰＥＧ−２からＨ．２６４にトランスコードし、ＰＡＴ，ＰＭＴ、ＳＩＴ、ＤＩＴを含んだＨ．２６４のＴＳにトランスコードすることができる。
【０２０１】
また、ＭＰＥＧ−２のＴＳからＰＳにトランスコードする場合にも、同様に考えることができる。ＭＰＥＧ−ＰＳとして、たとえば、ＤＶＤ−ＶＲ（Ｖｉｄｅｏ  Ｒｅｃｏｒｄｉｎｇ）仕様を用いる場合、ＭＰＥＧ−２のＴＳパケットはＰＥＳに変換された後にＭＰＥＧ−ＰＳに変換できる。ＣＣＩの継承に関しては、ＭＰＥＧ−２のＴＳでＣＣＩを含んでいるＰＭＴ中のＣＣＩモードの意味を変化させないで、「ＭＰＥＧ−２のＴＳのＰＭＴ」から、たとえば、「ＤＶＤ−ＶＲ規格においてＣＣＩを含んでいる、ＲＤＩパック中のＣＣＩ」に継承させる。デジタルコピー制御に関しては、ＰＭＴのデジタルコピー制御用ＣＣＩの意味をＲＤＩパックのデジタルコピー制御用ＣＣＩに継承させる。また、アナログコピー制御に関しては、ＰＭＴのデジタルアナログコピー制御用ＣＣＩの意味をＲＤＩパックのアナログコピー制御用ＣＣＩに継承させる。以上により、ＡＶ信号部分をＣＣＩ情報（ＣＣＩの意味）と共に、ＭＰＥＧ−２のＴＳからＰＳにトランスコードすることができる。
【０２０２】
ＭＰＥＧ−ＰＳを用いることにより、たとえば、家庭内ネットワークを無線ＬＡＮ（８０２．１１ａ／ｂなど）で構築している場合、ＭＰＥＧ−２のＰＳの場合、伝送レートを約１．５〜１０．８Ｍｂｐｓにできるため、ＭＰＥＧ−ＴＳの場合より余裕を持って家庭内で映像の無線伝送が可能となる。また、１．５Ｍｂｐｓ程度に圧縮した場合、たとえば６ｃｈでも９Ｍｂｐｓであるので、主要放送局６局分のＭＰＥＧ−ＰＳを同時にホームサーバとクライアント間で伝送することも可能となる。
【０２０３】
（実施の形態４）
次に、本発明の実施の形態４について説明する。本実施の形態におけるパケット送受信部の構成を図１６に示すが、図１６は第１の実施例で述べた図８の送信部および図９の受信部とを組み合わせて、送受信部にまとめた構成である。図１６は、代表的な構成要素として、ＴＳ入力インタフェース部１２０１、ＴＳ−ＭＵＸ部１２０２、ＴＳ出力インタフェース部１２０３、セキュアＩＰ化送信制御部８０１、および、伝送プロトコル処理部８０２を備える。よって、以下では実施の形態１と同じ部分の説明は省略し、異なる部分のみを説明する。
【０２０４】
図１６において、ＴＳ入力インタフェース部１２０１に入力されたＴＳ信号は、ＴＳ−ＭＵＸ部を通じてセキュアＩＰ化送信制御部８０１に入力され、伝送プロトコル処理部８０２から受信部に送信される。また、伝送プロトコル処理部８０２で受信した信号はセキュアＩＰ化送信制御部８０１に入力され、ＴＳ−ＭＵＸ部を通じてＴＳ出力インタフェース部１２０３に出力される。
【０２０５】
以上のように、図１６の構成により双方向通信が可能となる。
【０２０６】
なお、ＨＤＴＶ対応のカムコーダ（ムービー）を用いて双方向通信を行っている場合、撮影指揮者（著作権者の意味）が撮影したＭＰＥＧ−ＴＳ信号をコピーフリーでも暗号化したい場合、自分で撮影したＭＰＥＧ−ＴＳ信号のＣＣＩをＣＦ／ＥＰＮ（Ｃｏｐｙ  Ｆｒｅｅ、Ｅｎｃｒｉｐｔｉｏｎ  ｐｌｕｓ  ｎｏｎ−ａｓｓｅｒｔｉｏｎ）モードに設定して、Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ（ＰｔｏＰ）通信などに使用することができる。この場合、たとえば、第１のＭＩＭＥ−Ｔｙｐｅ（ブロックヘッダを付加する、かつ、暗号化も実施する）を用いることができる。
【０２０７】
（実施の形態５）
次に、本発明の実施の形態５について説明する。本実施の形態におけるパケット送受信部の構成を図１７に示すが、図１７は第４の実施例で述べた図１６の構成に類似ではあるが、入力系と出力系がそれぞれ２系統ある点が大きく異なる。
【０２０８】
図１７は、代表的な構成要素として、外部入力１のＴＳ入力インタフェース部１３０１、外部入力２のＴＳ入力インタフェース部１３０２、ＴＳ−ＭＵＸ部１３０３、セキュアパケット送信処理部１３０４、伝送プロトコル処理部１３０５、受信プロトコル処理部１３０７、セキュアパケット受信処理部１３０８、ＴＳ−ＤＥＭＵＸ部１３０９、外部出力１のＴＳ出力インタフェース部１３１０、外部出力２のＴＳ出力インタフェース部１３１１とを備える。よって、以下では実施の形態４と同じ部分の説明は省略し、異なる部分のみを説明する。
【０２０９】
立体画像を伝送する目的においては、図１７において、外部入力１と外部入力２に、それぞれ、左眼用映像、右眼用映像を入力する。ここで、入力される左眼用映像、右眼用映像は、ＭＰＥＧ−２やＨ．２６４エンコード時に左右の映像で映像フレーム同期または映像フィールド同期を取る。ＭＰＥＧ−２の場合はＩ−Ｐｉｃｔｕｒｅで２ｃｈ映像の映像同期を取り、Ｈ．２６４／ＡＶＣの場合はＩＤＲ−Ｐｉｃｔｕｒｅで２ｃｈ映像の同期を取ると、映像同期処理など信号処理が簡単にできるので、装置の低コスト化も図れる。なお、ＩＤＲとは、Ｉｎｓｔａｎｔａｎｅｏｕｓ  Ｄｅｃｏｄｉｎｇ  Ｒｅｆｒｅｓｈの略であり、Ｈ．２６４ではＳｅｑｕｅｎｃｅ（Ｐｉｃｔｕｒｅの集まりである動画）の先頭は、ＩＤＲピクチャである。
【０２１０】
さらに、ＭＰＥＧ−２やＨ．２６４を用いた３Ｄ（立体）映像のエンコードにおいて、一般的に左眼用映像と右眼用映像は似ているので、左眼用映像は右眼用映像を参照してエンコードすれば、左眼用映像のビットレートを小さくできる。よって、この場合には、トータルとして、右眼用映像の約１．５倍のビットレートにおさえることができる。
【０２１１】
（実施の形態６）
本発明の実施の形態６について説明する。本実施の形態におけるパケット送信部の構成を図１８に示すが、第２の実施例で説明した構成に類似している。ＴＳ外部入力がＨ．２６５エンコーダになっているところである。
【０２１２】
図１８は、代表的な構成要素として、デジタルチューナ４０３、外部入力のＴＳ入力インタフェース部４０４、ＴＳ−ＭＵＸ部４０５、セキュアパケット送信処理部４０２、伝送プロトコル処理部４１９、Ｈ．２６４処理部１４０８、及び蓄積部１４０９から構成される。
【０２１３】
Ｈ．２６４処理部１４０８は、映像符号化（Ｈ．２６４）モジュール１４０１、音声符号化モジュール１４０２、メタデータ符号化モジュール１４０３、ＶＣＬ（Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  Ｌａｙｅｒ）のＮＡＬ（Ｎｅｔｗｏｒｋ  Ａｂｓｔｒａｃｔｉｏｎ  Ｌａｙｅｒ）ユニット処理部１４０５、および、ｎｏｎ−ＶＣＬのＮＡＬユニット処理部１４０６を含むＮＡＬユニット処理部１４０４、ＮＡＬユニット処理部１６０４のＭＰＥＧ−ＰＥＳ出力をＰＥＳ／ＴＳ変換するＰＥＳ／ＴＳ変換部１４０７から構成される。
【０２１４】
以下では既に説明した実施の形態と同じ部分の説明は省略し、異なる部分のみを説明する。
【０２１５】
図１９は、図１８のＨ．２６４処理部１４０８の構成を、データを一時的に保持するための複数のバッファを明示して、より詳細に説明する図である。
【０２１６】
図１９は、代表的な構成要素として、映像符号化部１５０１、ＶＣＬ−ＮＡＬユニットバッファ１５０２、音声符号化部１５０３、ＰＳ（Ｐａｒａｍｅｔｅｒ  Ｓｅｔ）バッファ１５０４、ＶＵＩ（Ｖｉｄｅｏ  Ｕｓａｂｉｌｉｔｙ  Ｉｎｆｏｒｍａｔｉｏｎ）バッファ（１５０５）、ＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ  Ｅｎｈａｎｃｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ）バッファ１５０６、ｎｏｎ−ＶＣＬ−ＮＡＬユニットバッファ１５０７、ＭＰＥＧ−ＴＳマッピング処理部１５０８などにより構成される。
【０２１７】
ＳＥＩバッファ１５０６にはメタデータを入力することができる。メタデータは、Ｈ．２６４／ＡＶＣの場合には、ＳＥＩのＵｓｅｒ  Ｄａｔａ  Ｕｎｒｅｇｉｓｔｅｒｅｄ  ＳＥＩにメタデータを格納することができる。また、ＭＰＥＧ−２の場合には、ＥＳ（Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ）のＰｉｃｔｕｒｅ  ＨｅａｄｅｒのＵｓｅｒ  Ｄａｔａ領域に格納するか、ＰＳ（Ｐｒｏｇｒａｍ  Ｓｔｒｅａｍ）のＰｒｉｖａｔｅ  Ｓｔｒｅａｍに格納するか、ＴＳ（Ｔｒａｎｓｐｏｓｔ  Ｓｔｒｅａｍ）のＰｒｉｖａｔｅパケットにＰＩＤ指定により格納することができる。
【０２１８】
メタデータの種類としては、図２０に示すように、一般的なメタデータ、デジタル放送を受信して、そのＳＩ（Ｓｅｒｖｉｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ；  番組配列情報）より得るメタデータ、ＥＰＧ提供事業者より得たＥＰＧ情報などのメタデータ、Ｉｎｔｅｒｎｅｔから得たＥＰＧなどのメタデータ、また、個人や撮影クルーなどでムービー撮影したＡＶコンテンツ（クリップなど）に関連付けたメタデータなどがある。ムービー撮影の場合、たとえば、日時、場所、撮影者、撮影イベントのジャンル、撮影イベント名などがある。
【０２１９】
場所の場合、昔は測定が難しかったが、最近ではカーナビゲーションシステムでも実用化されている様に、ＧＰＳと３Ｄジャイロセンサーの組み合わせにより、ＧＰＳ電波が届かない場所でもより正確な位置を算出することができる。また場所の測定データを電子化された地図データとリンクさせ、住所で表現することもできる。また住所に限らず、各種のメタデータをタッチパネルなどから直接入力することも可能である。
【０２２０】
これらメタデータを活用することにより、多くのＡＶコンテンツから所望のコンテンツを検索する、ライブラリに分類する、自動表示を行うなどコンテンツの効率的な利用が可能となる。
【０２２１】
なお、現在次のような環境が整備され、メタデータの今後一層の多様化と流通促進とが期待される。
【０２２２】
例えば、視聴者が作成したメタデータを提供する多くのテレビブログサイトがインターネット上に開設され（例えば、ｈｔｔｐ：／／ｗｗｗ．ｔｖｂｌｏｇ．ｊｐ／を参照）、また、既存の広報関連の番組情報はもちろん、番組の企画、収録、編集、編成、送出、アーカイブ（保存）など、放送に関する各段階で発生するメタデータの収集、加工、配信を請け負うサービスが開始されている（ｈｔｔｐ：／／ｗｗｗ．ｐｌａｔ−ｅａｓｅ．ｃｏ．ｊｐ／ｍｅｔａｄａｔａ．ｈｔｍを参照）。また、コンテンツの著作権処理の円滑化に資するメタデータ体系が、総務省によって策定されている（例えば、ｈｔｔｐ：／／ｗｗｗ．ｓｏｕｍｕ．ｇｏ．ｊｐ／ｓ−ｎｅｗｓ／２００３／０３０５２０＿４．ｈｔｍ、ｈｔｔｐ：／／ｗｗｗ．ｓｏｕｍｅ．ｇｏ．ｊｐ／ｓ−ｎｅｗｓ／２００３／ｐｄｆ／０３０５２０＿４＿０１．ｐｄｆを参照）。
【０２２３】
さて、図１８において、デジタル放送で音楽番組を受信する場合、音楽番組をライブで別室に伝送する場合は、頭出しの必要はないが、デジタル放送で音楽番組を受信して、一旦、蓄積部１４０９に蓄積して、後ほど、音楽番組を視聴する場合、番組中に放送された複数の楽曲の中より所望の楽曲に簡単にアクセスしたいというユーザ要求がある。ところが、デジタル放送で音楽番組を受信しても、番組タイトルと、一部の楽曲名はＳＩのＥＰＧ情報（たとえば、ＥＩＴ：Ｅｖｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）から取得できるが、各楽曲の放送時間などの情報がないために、蓄積部より楽曲を再生する際に、簡単に所望の楽曲に簡単にアクセスできないという課題がある。
【０２２４】
そこで、その解決のため、セキュアパケット送信処理部４０２内の管理制御部が、プロトコル処理部４１９を介して、図７に示した家庭内のルータからＩｎｔｅｒｎｅｔ上の楽曲情報サーバにアクセスして、該音楽番組内の楽曲情報（曲名、アーティスト名、アルバム名、ジャンル、演奏時間、放送時間、作詞、作曲、伴奏、楽曲の説明など）を取得する。そして、取得した該音楽番組内の楽曲情報と蓄積部１４０９に記録されている該音楽番組内の複数の楽曲とを該音楽番組（蓄積部上のファイル）のタイムレンジ情報（またはバイトレンジ情報）で関連付けた楽曲位置テーブルを作成し、蓄積部の楽曲位置テーブル格納用Ｄｉｒｅｃｔｏｒｙに記録する。よって、ユーザはＵＰｎＰ−ＡＶ  Ｓｅｒｖｉｃｅ）でブラウズ、サーチなどを行うと、該音楽番組タイトルのファイルの＜ｒｅｓ＞に対して、該音楽番組中の各楽曲に対して楽曲位置テーブルを用いることにより、ＨＴＴＰのタイムレンジ（バイトレンジ）指定で瞬時に所望の楽曲にアクセスすることができる。また、ＨＴＴＰでの楽曲アクセスに関して、たとえば、ＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）パラメータで楽曲名を指定すると、サーバ側で楽曲名から放送番組内の該楽曲の放送時刻を指定するアプリケーションを組むことにより、楽曲アクセスを実現することもできる。
【０２２５】
また、Ｉｎｔｅｒｎｅｔより該音楽番組内の楽曲情報が取得できない場合には、各楽曲の波形データ（楽曲のサビなど）をＩｎｔｅｒｎｅｔ上の楽曲名解析サービスのサーバなどに問い合わせることにより、該音楽番組内の楽曲情報を取得することができる。
【０２２６】
この方式は、さらに、音楽番組以外にも拡張できる。たとえば、映画、ドラマ、バラエティ番組、スポーツやニュースなどの放送番組を蓄積部に録画した場合、その映画に関するメタデータ、たとば、シーン情報（必見シーン、人気のあるシーン）などのメタデータをＩｎｔｅｒｎｅｔやデータ放送などのサービスより取得し、蓄積媒体に記録された映画のファイルと関連付けることにより、ユーザは瞬時に所望の映画シーンにアクセスすることができる。これらのメタデータはＩｎｒｅｒｎｅｔだけでなく、データ放送でも伝送することができる。
【０２２７】
（実施の形態７）
本発明の実施の形態７について説明する。本実施の形態におけるパケット送受信部の構成を図２１に示す。図２１は実施の形態４で述べた図１６の構成に類似している。図２１は、代表的な構成要素として、ＡＶ信号やメタデータの入力部１７０１、ＨＤ（高解像度）符号化部１７０２、ＴＳ−ＭＵＸ／ＤＥＭＵＸ部１７０３、第１蓄積部１７０４、ＨＤ／低解像度変換部１７０５、セキュアパケット送受信処理部１７０６、伝送プロトコル処理部１７０７、ＩＰネットワーク１７０８、伝送プロトコル処理部１７０９、セキュアパケット送受信処理部１７１０、ＴＳ−ＭＵＸ／ＤＥＭＵＸ部１７１１、第２蓄積部１７１２、ＥＤＬ入力部１７１３、ＨＤ出力部１７１４などにより構成される。以下では既に説明した実施の形態と同じ部分の説明は省略し、異なる部分のみを説明する。
【０２２８】
図２１において、ＨＤムービーで撮影したＭＰＥＧ−ＴＳ形式のＨＤコンテンツと、そのメタデータ（たとえば、図２０に記載したメタデータ）が入力部１７０１より入力され、ＴＳ−ＭＵＸ／ＤＥＭＵＸ部を経由して蓄積部１に蓄積される。ＨＤ／低解像度変換部１７０５は蓄積部１に蓄積されたＨＤコンテンツを低解像度（たとえば、水平画素数３２０、垂直画素数２４０のＱＶＧＡサイズ）で低ビットレートのコンテンツに変換する。
【０２２９】
ＨＤムービーで撮影したＭＰＥＧ−ＴＳ形式のＨＤコンテンツをホームサーバに記録しておく。次に別室などのＰＣや携帯端末からネットワークを介してリモートで編集する場合、ＨＤコンテンツをＰＣや携帯端末に送るには、機器の処理負荷およびネットワーク負荷が大きくなる。
【０２３０】
そこで、送信側の処理としては、まず、ＡＶ信号とＭｅｔａｄａｔａを入力し、ＨＤ符号化（同時に低解像度符号化）およびＴＳパケット化を行う。次に、ＴＳパケットを第１蓄積部１７０４に蓄積し、蓄積された低解像度コンテンツを受信側に送信する。
【０２３１】
また、受信側の処理としては、まず、編集リスト（ＥＤＬ）を作成し、ＥＤＬを送信側に伝送する。次に、送信側は、受信したＥＤＬに基づいて編集されたＨＤコンテンツを受信側に伝送する。不必要な映像を削除することにより、受信側に伝送するデータ量を削減することができる。ここで、伝送プロトコルはＴＣＰ／ＩＰに限定されないで、一般のデジタルインタフェースでもよい。また、送信側でローカルに編集することもできる。
【０２３２】
次に図２２を用いて、より具体的な実施例について説明する。ＨＤムービー１８０１で録画したコンテンツを携帯端末１８０２で編集し、ＥＤＬを作成する。携帯端末１８０２はこのＥＤＬをＨＤムービーに渡す。ＨＤムービーは、撮影したＨＤコンテンツとＥＤＬを、ＨＤＤを内蔵したＤＶＤレコーダ１８０３に渡す。ＴＶ受像機１８０４はリモコン１８０５からの指示で、ムービー１８０１または、ＤＶＤレコーダ１８０３内のコンテンツを呼び出す。この場合、タイトル選択だけでなく、携帯端末１８０２で作成したＥＤＬを用いることにより不要な部分を除いた撮影データを視聴することができる。また、ＤＶＤレコーダ１８０３は前記ＥＤＬに従って、撮影データを編集してファイルサイズを小さくすることができる。
【０２３３】
また、図２２において、寝室のＴＶにおいて、寝室のＤＶＤレコーダ経由で、リビングルームのＤＶＤレコーダに存在するコンテンツを視聴する場合、寝室のＴＶは、リビングルームのＤＶＤレコーダに存在するコンテンツを選択する。さらに、選択したコンテンツのＥＤＬを取得して、そのＥＤＬに沿って撮影データをリモート視聴する。また、寝室のＤＶＤレコーダに、ＥＤＬに基づいて編集したＨＤコンテンツを受信側のＤＶＤレコーダに伝送する。以上のように、不必要な映像を削除することにより、受信側に伝送するデータ量を削減することができる。
【０２３４】
なお、本実施例ではＨＴＴＰを用いたが、ＨＴＴＰの代わりにＲＴＰ用をいてもよい。ＲＴＰの場合は、受信側がＲＴＣＰでＭＰＥＧファイルの伝送部分を指定すればよい。なお、この場合は、ＨＴＴＰのように伝送サイズの計算が複雑にならないというメリットがある。
【０２３５】
また、ビデオ信号処理の例として、ＭＰＥＧ−ＴＳを用いたが、これに限らず本発明で用いる入力データの適用範囲としては、ＭＰＥＧ１／２／４などＭＰＥＧ−ＴＳストリーム（ＩＳＯ／ＩＥＣ１３８１８）、ＳＭＰＴＥ３１４Ｍ（ＤＶ−ｂａｓｅｄ）、ＳＭＰＴＥ２５９Ｍ規格で規定された非圧縮ＳＤ方式信号、ＳＭＰＴＥ２９２Ｍ規格で規定された非圧縮ＨＤ形式、ＩＥＣ６１８８３規格で規定されたＩＥＥＥ１３９４によるＤＶまたはデジタル放送のＭＰＥＧ−ＴＳの伝送ストリーム形式、ＤＶＢ規格Ａ０１０で規定されたＤＶＢ−ＡＳＩによるＭＰＥＧ−ＴＳ形式、ＭＰＥＧ−ＰＥＳ、ＭＰＥＧ−ＥＳ、ＭＰＥＧ４、ＩＳＯ／ＩＥＣ  Ｈ．２６４等で規格化されているストリームを含んだあらゆる映像、音声に関するストリームにも適用可能である。映像や音声のデータレートは、ＣＢＲ（ｃｏｎｓｔａｎｔ  ｂｉｔ  ｒａｔｅ）に限るものではない。さらに、映像や音声だけでなく、一般のリアルタイムデータ、あるいは優先的に送受信を行うデータであればどのようなものでも本発明から排除するものではない。
【０２３６】
また、上記実施の形態において、パケット送受信装置は、Ｎを２以上の整数とした場合、ＵＤＰまたはＴＣＰのＮ個のポートを用いて、ＡＶデータにより構成されるＮ個のプログラムを前記Ｎ個のポートのそれぞれに割り当てて伝送してもよい。このとき、Ｎ個のポートのそれぞれに割り当てるＮ個のプログラムは、それぞれ、ソースに内蔵された放送受信チューナまたは蓄積メディアデバイスをＵＰｎＰ部のコンテナ形式で表現し、また、放送受信チャネルまたは蓄積プログラムをＵＰｎＰ部のｉｔｅｍ形式で表現し、それぞれのｉｔｅｍ（リソースとしてのｒｅｓとなる）の存在位置をＵＲＩ、また伝送プロトコルや属性情報をＵＰｎＰのｐｒｏｔｏｃｏｌＩｎｆｏを用いたｒｅｓ表現で表わし、複数プログラムの複数クライアントへの同時伝送など、きめ細かい伝送システムを実現することができる。
【０２３７】
また、放送受信の場合、送信側におけるＮ個のポートのそれぞれに割り当てるＮ個のプログラム（ｒｅｓ）のソースからシンクへの伝送ストリームが複数存在する場合に、各々のストリームをＵＰｎＰのｐｒｏｐｅｒｔｙ形式で表わし、特定の伝送ストリームのｐｒｏｐｅｒｔｙのａｔｔｒｉｂｕｔｅとして、「チューナのコンテナの種別、チューナのコンテナ種別ごとのチューナＩＤ、チューナで選局されたチャネルＩＤ、伝送ストリームの他クライアントとの共有・横取りに関する利用可否情報、ストリームを伝送するトランスポート層が使用するＴＣＰまたはＲＴＰのポート番号、シンクにおけるＵＰｎＰ−ＡＶ部のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがソースにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ部のｃｏｎｎｅｃｔｉｏｎＩＤ、ソースにおけるＵＰｎＰ−ＡＶ部のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがシンクにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶのｃｏｎｎｅｃｔｉｏｎＩＤ」のうち、いずれかを含めることにより、受信側（クライアント、シンク）から送信側（サーバ、ソース）内のチューナのチャネル選局を行なう時に、伝送ストリームのｐｒｏｐｅｒｔｙおよびそのａｔｔｒｉｂｕｔｅを参照することにより、伝送ストリームに空きがあるか無いか、およびどのチューナの、どのチャネルが選局されているかを判別することができる。
【０２３８】
たとえば、放送受信の場合のＵＰｎＰ−ＡＶコンテナ構造として、＜ｒｏｏｔ＞下に、チューナのコンテナを配置する。コンテナ種別としては、地上デジタル、ＢＳデジタル、１１０度広帯域ＣＳデジタルなどの放送システム別、各々チューナコンテナを割り当てる。この場合、各チューナコンテナの下にｉｔｅｍとして各放送システムのチャンネルを割り当てる。ＵＰｎＰのＣＤＳのｓｅｒｃｈやｂｒｏｗｓコマンドを用いて、受信側から送信側のチューナコンテナ、およびチューナコンテナ内のチャンネルｉｔｅｍを認識することができる。チャンネルとしてのｉｔｅｍは放送局より送信される付属情報を持つ。
【０２３９】
同様に、蓄積コンテンツの再生の場合、送信側におけるＮ個のポートのそれぞれに割り当てるＮ個のプログラムのソースからシンクへの伝送ストリームが複数存在する場合に、ＵＰｎＰのｐｒｏｐｅｒｔｙ形式で表わし、特定の伝送ストリームのｐｒｏｐｅｒｔｙのａｔｔｒｉｂｕｔｅとして、「蓄積メディアデバイスのコンテナの種別、蓄積メディアデバイスのコンテナ種別ごとの蓄積メディアデバイスＩＤ、蓄積メディアデバイスで選択されたプログラムＩＤ、伝送ストリームの共有を含む利用可否情報、ストリームを伝送するトランスポート層が使用するＴＣＰまたはＲＴＰのポート番号、シンクにおけるＵＰｎＰ−ＡＶ部のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがソースにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ部のｃｏｎｎｅｃｔｉｏｎＩＤ、ソースにおけるＵＰｎＰ−ＡＶ部のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがシンクにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ部のｃｏｎｎｅｃｔｉｏｎＩＤ」のうち、いずれかを含めることにより、シンクがソース内の蓄積メディアデバイスのプログラム選択を行なう時に、伝送ストリームのｐｒｏｐｅｒｔｙおよびそのａｔｔｒｉｂｕｔｅを参照することにより、伝送ストリームに空きがあるか無いか、およびどの蓄積メディアデバイスのどのプログラムが選択されているかなど判別することができる。
【０２４０】
たとえば、蓄積・記録デバイスが、ハードディスクドライブ（ＨＤＤ）、ＤＶＤ−ＲＡＭドライブ、ＢＤドライブの場合のＵＰｎＰ−ＡＶコンテナ構造として、＜ｒｏｏｔ＞下に、それぞれのコンテナを配置する。コンテナ種別としては、ＨＤＤ、ＤＶＤ−ＲＡＭドライブ、ＢＤドライブなどそれぞれにデバイス別のコンテナを割り当てる。この場合、各コンテナの下にｉｔｅｍとして、蓄積・記録コンテンツをたとえばプログラム単位で割り当てる。これにより、ＵＰｎＰのＣＤＳのｓｅｒｃｈやｂｒｏｗｓコマンドを用いて、受信側から送信側の蓄積・記録デバイスコンテナ、および蓄積・記録デバイスコンテナ内の蓄積・記録コンテンツをたとえばプログラム単位でｉｔｅｍとして認識することができる。蓄積・記録されているｉｔｅｍは記録時に与えられた付属情報を持つ。
【０２４１】
また、送信サーバの放送コンテナに所属するｉｔｅｍをクライアントが受信して蓄積する場合、前記放送システム別のチューナコンテナの属性（地上デジタル、ＢＳデジタル、１１０度広帯域ＣＳデジタルなどの放送システムを区別する属性）を利用して、放送システム別のｐｒｏｐｅｒｔｙを生成し、蓄積・記録デバイスに蓄積・記録して生成したｉｔｅｍのｐｒｏｐｅｒｔｙとして保存する。これにより、蓄積・記録デバイスのコンテナが放送システム別でなくても、蓄積・記録デバイスから再生したｉｔｅｍのｐｒｏｐｅｒｔｙを見れば、どの放送システムから放送されたコンテンツであるかを識別することができる。
【０２４２】
以上により、放送受信の場合でも蓄積コンテンツの再生の場合でも、新たにサーバ接続するクライアントはサーバの使用状況を理解し、より効率的にコンテンツの選択、伝送を行うことができる。
【０２４３】
なお、「ストリームを伝送するトランスポート層が使用するＴＣＰまたはＵＤＰのポート番号」、および、「シンクにおけるＵＰｎＰ−ＡＶ部のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがソースにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ部のｃｏｎｎｅｃｔｉｏｎＩＤ、またはソースにおけるＵＰｎＰ−ＡＶ部のＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒがシンクにおけるＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒに対してｉｔｅｍに関する論理的接続に関連して設定するＵＰｎＰ−ＡＶ部のｃｏｎｎｅｃｔｉｏｎＩＤ」の論理対により、ＵＰｎＰ−ＡＶ部と、ＴＣＰまたはＵＤＰを使用するＨＴＴＰまたはＲＴＰを用いるトランスポート部とを論理的に対応づけることにより、ＣＤＳやＣＭＳ（Ｃｏｎｎｅｃｔｉｏｎ  Ｍａｎａｇｅｒ  Ｓｅｒｖｉｃｅ）を用いるＵＰｎＰ−ＡＶレイヤとＨＴＴＰ／ＴＣＰ／ＩＰを取り扱うトランスポートレイヤを論理的に１対１に対応させることができるので、コネクションの確立、コンテンツの選択、コンテンツの伝送、コネクションの切断、存在コネクションの管理などの伝送制御をより簡単に実現することが可能となる。また、ＨＴＴＰのリクエストメッセージのメッセージヘッダの拡張フィールドや、ＨＴＴＰのレスポンスメッセージのメッセージヘッダの拡張フィールドにＵＰｎＰ−ＡＶ部のｃｏｎｎｅｃｔｉｏｎＩＤを記述することによりＨＴＴＰプロトコルによる伝送制御部とＵＰｎＰ−ＡＶ部と論理的に１対１対応させることができる。
【産業上の利用可能性】
【０２４４】
本発明は、地上デジタル放送などを受信・番組選局したコンテンツや、ＨＤ、ムービーで録画したコンテンツを宅内のＩＰネットワークにより別室のテレビやパソコンに伝送し、リモート視聴を可能にする。また、前述したコンテンツをＨＤＤやＤＶＤディスクに記録し、別室よりＩＰネットワークを介して記録コンテンツのタイトル選択や、特殊再生を実現しながら、リモート視聴を可能とする。
【図面の簡単な説明】
【０２４５】
【図１】図１は、従来のパケット送受信システムの構成図である。
【図２】図２は、従来のパケット送受信装置の構成図である。
【図３】図３は、従来、鍵交換にＤＴＣＰ方式を適用する場合のコンテンツ伝送手順の説明図である。
【図４】図４は、従来の１３９４パケットの説明図である。
【図５】図５は、本発明における送受信システムの概念図である。
【図６】図６は、本発明における鍵交換にＤＴＣＰ方式を適用する場合のコンテンツ伝送手順の説明図である。
【図７】図７は、イーサネット（登録商標）を用いる一般家庭に本発明を適用した場合の一例の説明図である。
【図８】図８は、本発明の実施の形態１におけるパケット送信部のブロック図である。
【図９】図９は、本発明の実施の形態１におけるパケット受信部のブロック図である。
【図１０】図１０は、本発明の実施の形態１におけるＭＰＥＧ−ＴＳのイーサネット（登録商標）フレーム構成仕様の例を示す図である。
【図１１】図１１は、本発明の実施の形態１における信号およびプロトコル処理をレイヤ別に説明した図である。
【図１２】図１２は、本発明の実施の形態１におけるパケット送受信部の説明図である。
【図１３】図１３は、図８を簡略的に表した図である。
【図１４】図１４は、本発明の実施の形態２におけるパケット送信部のブロック図である。
【図１５】図１５は、本発明の実施の形態３におけるパケット送信部のブロック図である。
【図１６】図１６は、本発明の実施の形態４におけるパケット送受信部のブロック図である。
【図１７】図１７は、本発明の実施の形態５におけるパケット送受信部のブロック図である。
【図１８】図１８は、本発明の実施の形態６におけるパケット送受信部のブロック図である。
【図１９】図１９は、本発明の実施の形態６におけるＨ．２６４処理部のより詳細な説明図である。
【図２０】図２０は、本発明で取り扱うメタデータの例を示す図である。
【図２１】図２１は、本発明の実施の形態７におけるパケット送受信部のブロック図である。
【図２２】図２２は、本発明の実施の形態７におけるアプリケーションの説明図である。
【符号の説明】
【０２４６】
１０１    パケット送信機器
１０２    ルータ
１０３    パケット受信機器
４０１    パケット送信部
４０２    セキュアＩＰパケット送信処理部
４０３    デジタルチューナ
４０４    ＴＳインタフェース
４０５    スイッチャ
４０６    リモコンインタフェース
４０７    信号フォーマット・プロパティ検出部
４０８    ＴＳカプセル化部
４０９    ＴＳパケットフィルタリング及びデスクリプタ挿入部
４１０    ＴＳ−ＭＵＸ部
４１１    ＣＣＩ検出部
４１２    ＥＰＧ・録画データ処理部
４１３    管理制御部
４１４    認証と鍵交換（ＡＫＥ）部
４１５    データブロック化部
４１６    データブロックヘッダ生成部
４１７    暗号化部
４１８    データブロックパケット生成部
４１９    伝送プロトコル処理部
４２０    タイムスタンプ付加部
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2007010779.tif 000024
【図２】
2007010779.tif 000025
【図３】
2007010779.tif 000026
【図４】
2007010779.tif 000027
【図５】
2007010779.tif 000028
【図６】
2007010779.tif 000029
【図７】
2007010779.tif 000030
【図８】
2007010779.tif 000031
【図９】
2007010779.tif 000032
【図１０】
2007010779.tif 000033
【図１１】
2007010779.tif 000034
【図１２】
2007010779.tif 000035
【図１３】
2007010779.tif 000036
【図１４】
2007010779.tif 000037
【図１５】
2007010779.tif 000038
【図１６】
2007010779.tif 000039
【図１７】
2007010779.tif 000040
【図１８】
2007010779.tif 000041
【図１９】
2007010779.tif 000042
【図２０】
2007010779.tif 000043
【図２１】
2007010779.tif 000044
【図２２】
2007010779.tif 000045
【国際調査報告】
2007010779.tif 000046
2007010779.tif 000047
2007010779.tif 000048
2007010779.tif 000049