(57)【要約】【課題】使用する帯域を容易に減らすことができるデータ配信方法、データ配信装置及びデータ配信プログラムを提供することを課題とする。【解決手段】受信した複数種類のデータをネットワークに配信するデータ配信装置１２によって実行されるデータ配信方法であって、ネットワークに配信したデータを受信する受信機１４から、必要なデータの種類を必要情報として受信し、受信したデータの種類を解析し、受信したデータを必要情報に基づき必要なデータの種類で再構築してネットワークに配信することで上記課題を解決する。【選択図】  図３
2012119741.tif 000002
【特許請求の範囲】
【請求項１】
受信した複数種類のデータをネットワークに配信するデータ配信装置によって実行されるデータ配信方法であって、
前記ネットワークに配信した前記データを受信する受信機から、必要なデータの種類を必要情報として受信し、
前記受信したデータの種類を解析し、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築し、
前記再構築したデータを前記ネットワークに配信する
ことを特徴とするデータ配信方法。
【請求項２】
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築する処理は、前記必要情報に基づき変更される記憶部に記憶された前記必要なデータの種類を表すテーブルに従って、前記受信したデータを前記必要なデータの種類で再構築する
ことを特徴とする請求項１記載のデータ配信方法。
【請求項３】
前記テーブルは前記受信機ごとに、前記必要なデータの種類を表す
ことを特徴とする請求項２記載のデータ配信方法。
【請求項４】
前記テーブルは前記受信機及び前記受信機で選択可能なチャンネルごとに、前記必要なデータの種類を表す
ことを特徴とする請求項２記載のデータ配信方法。
【請求項５】
受信した複数種類のデータをネットワークに配信するデータ配信装置であって、
前記ネットワークに配信した前記データを受信する受信機から、必要なデータの種類を必要情報として受信する受信手段と、
前記受信したデータの種類を解析する解析手段と、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築する再構築手段と、
前記再構築したデータを前記ネットワークに配信する配信手段と
を有することを特徴とするデータ配信装置。
【請求項６】
受信した複数種類のデータをネットワークに配信するデータ配信装置に、
前記ネットワークに配信した前記データを受信する受信機から、必要なデータの種類を必要情報として受信し、
前記受信したデータの種類を解析し、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築し、
前記再構築したデータを前記ネットワークに配信する
処理を実行させるデータ配信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は受信したデータを配信するデータ配信方法、データ配信装置及びデータ配信プログラムに関する。
【背景技術】
【０００２】
日本におけるＩＰＴＶ（Internet Protocol TeleVision）の仕様は一般社団法人ＩＰＴＶフォーラム（http://www.iptvforum.jp/）により策定され、標準技術となっている。ＩＰ放送サービスは、ＩＰＴＶの技術を利用して、ＩＰネットワークを通じて、放送のように番組を配信するものである。ＩＰ放送サービスは普及しつつある。
【０００３】
ＩＰ放送では、地上デジタル放送をＩＰプロトコルに乗せて配信するなど、ＨＤ(High Definition)コンテンツの配信も行われている。ＨＤコンテンツを配信するには広い帯域が必要となるため、通常ＦＴＴＨ（Fiber To The Home）を使用して配信される。
【０００４】
ＨＤコンテンツを配信する仕組みは、ＲＴＰ（Real-time Transport Protocol）マルチキャストと呼ばれる方式が利用される。ＲＴＰとは音声や映像をストリーミング再生するための伝送プロトコルである。
【０００５】
ＨＤコンテンツを配信する上記の仕組みでは、Ｊｏｉｎ／Ｌｅａｖｅと呼ばれる配信要求／停止要求にしたがって、その配信要求／停止要求を出したホームネットワークに対するストリームの配信／停止を決定する。上記の仕組みでは、あるストリームを配信するか停止するかを決めるだけなので、配信要求を出した各家庭のホームネットワークに同じストリームが配信されることになる。
【０００６】
また、ストリーミングされるＨＤコンテンツ等のコンテンツは、地上デジタル放送と同様、ＭＰＥＧ２システム（MPEG2-TTS）と呼ばれるフォーマットを使用して、映像や音声が暗号化されて送られることが多い。
【０００７】
図１はコンテンツを配信するシステムの一例の構成図である。システム１はＩＰＴＶ用サーバ１０、Ｗｅｂサーバ１１、無線／有線ＬＡＮゲートウェイ１２、ＰＣ１３、ＩＰＴＶ対応プレイヤ１４、ネットワーク１５及び１６を含む。ＩＰＴＶ用サーバ１０及びＷｅｂサーバ１１はネットワーク１５を介して無線／有線ＬＡＮゲートウェイ１２にデータ通信可能に接続されている。ＰＣ１３及びＩＰＴＶ対応プレイヤ１４はネットワーク１６を介して無線／有線ＬＡＮゲートウェイ１２にデータ通信可能に接続されている。
【０００８】
家庭までのネットワーク１５はＦＴＴＨなどの広帯域のネットワークが使用されていることが多い。また、宅内のホームネットワークであるネットワーク１６は、無線ＬＡＮなどの狭帯域のネットワークが使用されていることが多い。一方で、近年では、ＰＣ１３の他、ＴＶやゲーム機などホームネットワークであるネットワーク１６に接続できる機器が増加している。
【０００９】
そのため、システム１ではＩＰＴＶ対応プレイヤ１４で高ビットレートのＩＰ放送を見ると、ホームネットワークであるネットワーク１６の帯域を占有してしまい、ＰＣ１３などの他の機器のネットワークアクセスが遅くなったり、できなくなったりすることがあるという問題があった。そこで、従来は、ホームネットワークで使用する帯域を減らす方法が求められていた（例えば特許文献１参照）。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開平１０−２００４９４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかしながら、ホームネットワークで使用する帯域を減らす従来の方法は各パケットのパケット識別子とパケット優先度との対応関係をフィルタリング情報テーブルとして作成しておき、ストリームの各パケットから抽出されるパケット識別子をもとに、フィルタリング情報テーブルを参照して各パケットの送信又は破棄を判定するものである。
【００１２】
ホームネットワークで使用する帯域を減らす従来の方法は破棄と判定されたパケットの分だけ帯域を減らすことができるが、パケットの優先度付けを適切に行わなければ、使用する帯域を効果的に減らすことができない。しかし、パケットの優先度付けを適切に行うことは容易でないという問題があった。
【００１３】
なお、マルチキャスト配信は、例えばＩＰＴＶ用サーバ１０から各家庭のホームネットワークに同じストリームを配信するものである。したがって、ＩＰＴＶ用サーバ１０は各家庭のホームネットワークに応じたストリームを個別に配信することができない。
【００１４】
本実施形態は使用する帯域を容易に減らすことができるデータ配信方法、データ配信装置及びデータ配信プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１５】
上記課題を解決するため、本実施形態は、受信した複数種類のデータをネットワークに配信するデータ配信装置によって実行されるデータ配信方法であって、前記ネットワークに配信した前記データを受信する受信機から、必要なデータの種類を必要情報として受信し、前記受信したデータの種類を解析し、前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築し、前記再構築したデータを前記ネットワークに配信することを特徴とする。
【００１６】
なお、本実施形態の構成要素、表現又は構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、データ構造などに適用したものも本発明の態様として有効である。
【発明の効果】
【００１７】
本実施形態によれば使用する帯域を容易に減らすことができるデータ配信方法、データ配信装置及びデータ配信プログラムを提供可能である。
【図面の簡単な説明】
【００１８】
【図１】コンテンツを配信するシステムの一例の構成図である。
【図２】コンテンツを配信するシステムの一実施例の構成図である。
【図３】コンテンツを配信するシステムの一実施例の処理ブロック図である。
【図４】無線／有線ＬＡＮゲートウェイの一実施例のハードウェア構成図である。
【図５】無線／有線ＬＡＮゲートウェイの処理手順を表した一実施例のフローチャートである。
【図６】ＰＩＤパケット種別対応テーブルの一実施例の構成図である。
【図７】無線／有線ＬＡＮゲートウェイ及びＩＰＴＶ対応プレイヤの処理手順を表した一実施例のフローチャートである。
【図８】必要情報の一例の構成図である。
【図９】必要性規則テーブルの一実施例の構成図である。
【図１０】コンテンツを配信するシステムの他の実施例の処理ブロック図である。
【図１１】必要ＰＩＤテーブルの一実施例の構成図である。
【図１２】必要ＰＩＤの一例の構成図である。
【図１３】複数のＩＰＴＶ対応プレイヤに対応する必要性規則テーブルの一実施例の構成図である。
【図１４】複数のＩＰＴＶ対応プレイヤに対応する必要情報の一例の構成図である。
【図１５】複数のチャンネル（コンテンツストリーム）に対応する必要性規則テーブルの一実施例の構成図である。
【図１６】複数のＩＰＴＶ対応プレイヤ及びチャンネルに対応する必要情報の一例の構成図である。
【発明を実施するための形態】
【００１９】
次に、本発明を実施するための形態を、以下の実施例に基づき図面を参照しつつ説明していく。なお、本実施例ではデータ配信装置の一例として無線／有線ＬＡＮゲートウェイを説明するが、受信したデータを配信する他の機器、装置であってもよい。
【００２０】
図２はコンテンツを配信するシステムの一実施例の構成図である。システム２はＩＰＴＶ用サーバ１０、無線／有線ＬＡＮゲートウェイ１２、ＩＰＴＶ対応プレイヤ１４及び２１、ネットワーク１５及び１６を含む。ＩＰＴＶ用サーバ１０はネットワーク１５を介して無線／有線ＬＡＮゲートウェイ１２にデータ通信可能に接続されている。また、ＩＰＴＶ用サーバ１０はネットワーク１５を介してＩＰＴＶ対応プレイヤ２１にデータ通信可能に接続されている。ＩＰＴＶ対応プレイヤ１４はネットワーク１６を介して無線／有線ＬＡＮゲートウェイ１２にデータ通信可能に接続されている。
【００２１】
家庭までのネットワーク１５はＮＧＮ（Next Generation Network）やＦＴＴＨなどの広帯域のネットワークが使用されているものとする。また、宅内のホームネットワークであるネットワーク１６は、無線ＬＡＮなどの狭帯域のネットワークが使用されているものとする。ＩＰＴＶ対応プレイヤ１４及び２１は例えば別の家庭に設置されている。
【００２２】
ＩＰＴＶ用サーバ１０はＩＰ放送のコンテンツをマルチキャスト配信する。無線／有線ＬＡＮゲートウェイ１２は宅外のＦＴＴＨ等の広帯域のネットワーク１５と宅内のホームネットワーク等の狭帯域のネットワーク１６を繋ぐ。無線／有線ＬＡＮゲートウェイ１２は複数のインタフェースを持ち、複数のネットワークを接続する機器の一例である。
【００２３】
ＩＰＴＶ対応プレイヤ１４、２１はＩＰ放送のコンテンツを受信して再生する機器（受信機）の一例である。なお、ＩＰＴＶ対応プレイヤ１４、２１はＩＰＴＶ対応のチューナやレコーダなど、他の機器であってもよい。
【００２４】
図２のシステム２は例えば以下のような手順で処理を行う。ＩＰＴＶ対応プレイヤ１４はＩＰ放送の配信要求をＩＰＴＶ用サーバ１０に送信する。言い換えれば、ＩＰＴＶ対応プレイヤ１４はＲＴＰマルチキャストにＪｏｉｎする。ＲＴＰマルチキャストによるストリーム（ＲＴＰマルチキャストストリーム）がＩＰＴＶ用サーバ１０から、配信要求を出したＩＰＴＶ対応プレイヤ１４に送信されるように、ＩＰＴＶ用サーバ１０と無線／有線ＬＡＮゲートウェイ１２との間にあるルータ機器（エッジルータ）は状態を移行する。
【００２５】
無線／有線ＬＡＮゲートウェイ１２はＲＴＰマルチキャストストリームを受信し、そのＲＴＰマルチキャストストリームを後述のように再構築したあと、ホームネットワークであるネットワーク１６に再配信する。ＩＰＴＶ対応プレイヤ１４はＲＴＰマルチキャストストリームを受信する。
【００２６】
ＲＴＰマルチキャストストリームは、ＲＴＰヘッダとＲＴＰペイロードとを含むＲＴＰパケットが、ＵＤＰ通信と同様にＩＰヘッダやＵＤＰヘッダを付けられてＩＰパケットにされた上で、連続して配信されるものである。
【００２７】
また、ＲＴＰペイロードにはＭＰＥＧ２−ＴＴＳパケットが複数個（７個程度）、含まれる。例えばネットワークのＭＴＵ（最大転送単位）が通常１５００バイトであり、ＭＰＥＧ２−ＴＴＳパケットが１９２バイトであるとき、ＲＴＰペイロードはＭＰＥＧ２−ＴＴＳパケットを最大７個含めることができる。
【００２８】
ＭＰＥＧ２−ＴＴＳパケットには、映像データ、音声データ、番組表などの作成に使用するデータが記述されているパケットに加えて、映像データや音声データが記述されているパケットがどのＰＩＤを持つかを記述しているパケット（パケット種別:PMT）、ＰＭＴのパケットがどのＰＩＤを持つかを記述しているパケット（パケット種別:PAT）が存在する。逆に言えば、ＰＡＴ／ＰＭＴのパケットを解析することで、映像データ、音声データ、番組表などの作成に使用するデータが記述されているパケットのＰＩＤは知ることができる。そこで、ＩＰ放送のコンテンツを再生する際、ＩＰＴＶ対応プレイヤ１４はＰＡＴ／ＰＭＴのパケットを利用する。
【００２９】
図３はコンテンツを配信するシステムの一実施例の処理ブロック図である。ＩＰＴＶ用サーバ１０はマルチキャスト送信部３１を有する。無線／有線ＬＡＮゲートウェイ１２はマルチキャスト受信部３２、ＲＴＰ解析部３３、ＭＰＥＧ解析部３４、ＰＩＤパケット種別対応テーブル更新部３５、ＰＩＤ必要性対応づけ実施部３６、パケット蓄積部３７、ＲＴＰ再構築部３８、マルチキャスト配信部３９、必要情報受信部４０、必要性規則変更部４１、ＰＩＤパケット種別対応テーブル記憶部４２、必要性規則テーブル記憶部４３、ＭＰＥＧ２−ＴＴＳパケット記憶部４４を有する。
【００３０】
また、ＩＰＴＶ対応プレイヤ１４は録画部４５、表示部４６、制御部４７、必要情報判定部４８、必要情報通知部４９、マルチキャスト受信部５０を有する。なお、図３の処理ブロック図は本実施例の説明に不要な一部構成を省略している。図３の処理ブロック図において、無線／有線ＬＡＮゲートウェイ１２はマルチキャスト受信部３２の前段に、ＲＴＰマルチキャストストリームと、その他のパケットとを振り分ける処理ブロックを設けるようにしてもよい。
【００３１】
ＩＰＴＶ用サーバ１０のマルチキャスト送信部３１はＲＴＰマルチキャストストリームを送信する。無線／有線ＬＡＮゲートウェイ１２のマルチキャスト受信部３２はＲＴＰマルチキャストストリームを受信し、ＲＴＰマルチキャストストリームからＲＴＰパケットを取り出す。ＲＴＰ解析部３３はＲＴＰパケットを解析し、ＲＴＰペイロードに含まれるＭＰＥＧ２−ＴＴＳパケットを抽出する。
【００３２】
ＭＰＥＧ解析部３４はＭＰＥＧ２−ＴＴＳパケットを解析し、パケット種別ごとのＰＩＤを検出する。ＰＩＤパケット種別対応テーブル更新部３５はパケット種別とＰＩＤとの対応づけを行い、ＰＩＤパケット種別対応テーブルを更新する。ＰＩＤ必要性対応づけ実施部３６はＰＩＤパケット種別対応テーブル、必要性規則テーブルに基づき、ＰＩＤと必要性との対応づけを実施する。
【００３３】
パケット蓄積部３７は、ＰＩＤと必要性との対応づけにより必要と判定されたＭＰＥＧ２−ＴＴＳパケットをＭＰＥＧ２−ＴＴＳパケット記憶部４４に蓄積する。ＲＴＰ再構築部３８は蓄積されたＭＰＥＧ２−ＴＴＳパケットが一定数存在する場合、ＲＴＰパケットを再構築する。マルチキャスト配信部３９は再構築したＲＴＰパケットを含むＲＴＰマルチキャストストリームをＩＰＴＶ対応プレイヤ１４に送信する。
【００３４】
必要情報受信部４０はＩＰＴＶ対応プレイヤ１４から後述の必要情報を受信する。必要性規則変更部４１は必要情報に基づき、必要性規則テーブルを更新する。ＰＩＤパケット種別対応テーブル記憶部４２はＰＩＤパケット種別対応テーブルを記憶する。必要性規則テーブル記憶部４３は必要性規則テーブルを記憶する。ＭＰＥＧ２−ＴＴＳパケット記憶部４４はＭＰＥＧ２−ＴＴＳパケットを記憶する。
【００３５】
録画部４５はＭＰＥＧ２−ＴＴＳパケットに基づき、コンテンツの録画を行う。表示部４６はＭＰＥＧ２−ＴＴＳパケットに基づき、コンテンツの表示を行う。制御部４７はＲＴＰパケットを解析し、ＲＴＰペイロードに含まれるＭＰＥＧ２−ＴＴＳパケットを抽出する。制御部４７はユーザ操作等により、ＭＰＥＧ２−ＴＴＳパケットを録画部４５や表示部４６に送信して、コンテンツの録画や表示を行う。
【００３６】
必要情報判定部４８はユーザ操作や自動的な動作により後述の必要情報を判定する。必要情報通知部４９は、必要情報を無線／有線ＬＡＮゲートウェイ１２に通知する。マルチキャスト受信部５０はＲＴＰマルチキャストストリームを受信し、ＲＴＰマルチキャストストリームからＲＴＰパケットを取り出す。
【００３７】
図４は無線／有線ＬＡＮゲートウェイの一実施例のハードウェア構成図である。図４に示す無線／有線ＬＡＮゲートウェイ１２は、ＣＰＵ６１、ＲＯＭ６２、ＲＡＭ６３、第１インタフェース（Ｉ／Ｆ）６４、第２インタフェース（Ｉ／Ｆ）６５、Ｉ／Ｏ６６、表示部６７、キー部６８を有する。
【００３８】
第１Ｉ／Ｆ６４はＦＴＴＨなどの広帯域のネットワーク１５に対するインタフェースである。また、第２Ｉ／Ｆ６５は無線ＬＡＮなどの狭帯域のネットワーク１６に対するインタフェースである。ＣＰＵ６１は無線／有線ＬＡＮゲートウェイ１２の処理を全体制御する。ＲＯＭ６２及びＲＡＭ６３はプログラム、データなどを記憶する。
【００３９】
表示部６７及びキー部６８はＩ／Ｏ６６を介して接続されている。表示部６７は情報を表示する。キー部６８はユーザからの操作を受け付ける。第１Ｉ／Ｆ６４はネットワーク１５側からデータを受信し、データの内容をＣＰＵ６１に渡す。また、第１Ｉ／Ｆ６４はＣＰＵ６１からの指示に応じてネットワーク１５側にデータを送信する。第２Ｉ／Ｆ６５はネットワーク１６側からデータを受信し、データの内容をＣＰＵ６１に渡す。また、第２Ｉ／Ｆ６５はＣＰＵ６１からの指示に応じてネットワーク１６側にデータを送信する。
【００４０】
例えばＲＯＭ６２には無線／有線ＬＡＮゲートウェイ１２を制御するプログラムの一部として、データ配信プログラムが記憶されている。そして、ＣＰＵ６１はデータ配信プログラムをＲＯＭ６２から読み出して実行する。データ配信プログラムは、ＲＯＭ６２以外のＣＰＵ６１とアクセス可能な記憶部に記憶されていても良い。
【００４１】
データ配信プログラムは読み取り可能な記録媒体に記録しておくことができる。記録媒体には磁気記録媒体、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録媒体には、ＨＤＤ、フレキシブルディスク（ＦＤ）、磁気テープ（ＭＴ）などがある。光ディスクには、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ  −  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＣＤ−Ｒ（Ｒｅｃｏｒｄａｂｌｅ）／ＲＷ（ＲｅＷｒｉｔａｂｌｅ）などがある。また、光磁気記録媒体には、ＭＯ（Ｍａｇｎｅｔｏ  −  Ｏｐｔｉｃａｌ  ｄｉｓｋ）などがある。
【００４２】
データ配信プログラムを流通させる場合は例えばデータ配信プログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型の記録媒体を販売することが考えられる。データ配信プログラムを実行する無線／有線ＬＡＮゲートウェイ１２は例えば記録媒体読取装置（図示せず）が記録媒体からデータ配信プログラムを読み出す。ＣＰＵ６１は、読み出されたデータ配信プログラムをＲＡＭ６３に格納する。
【００４３】
そして、ＣＰＵ６１はＲＡＭ６３からデータ配信プログラムを読み取り、データ配信プログラムに従った処理を実行する。ＣＰＵ６１はデータ配信プログラムに従って、各種処理を実現している。
【００４４】
図５は無線／有線ＬＡＮゲートウェイの処理手順を表した一実施例のフローチャートである。ステップＳ１において、マルチキャスト受信部３２はＩＰＴＶ用サーバ１０のマルチキャスト送信部３１から送信されたＲＴＰマルチキャストストリームを受信し、ＲＴＰマルチキャストストリームからＲＴＰパケットを取り出す。ステップＳ２において、ＲＴＰ解析部３３はＲＴＰパケットを解析し、ＲＴＰペイロードに含まれるＭＰＥＧ２−ＴＴＳパケットを抽出する。ステップＳ３において、ＭＰＥＧ解析部３４はＭＰＥＧ２−ＴＴＳパケットを解析し、パケット種別ごとのＰＩＤを検出する。
【００４５】
ステップＳ４において、ＰＩＤパケット種別対応テーブル更新部３５はパケット種別とＰＩＤとの対応づけを行い、ＰＩＤパケット種別対応テーブルを更新する。ステップＳ５において、ＰＩＤ必要性対応づけ実施部３６はＰＩＤパケット種別対応テーブル、必要性規則テーブルに基づき、ＰＩＤと必要性との対応づけを行う。ＰＩＤと必要性との対応づけは、どのＰＩＤのＭＰＥＧ２−ＴＴＳパケットが必要かを判定する為のものである。
【００４６】
ステップＳ６において、パケット蓄積部３７はＰＩＤと必要性との対応づけにより必要と判定されたＭＰＥＧ２−ＴＴＳパケットをＭＰＥＧ２−ＴＴＳパケット記憶部４４に蓄積する。ステップＳ７において、ＲＴＰ再構築部３８は蓄積されたＭＰＥＧ２−ＴＴＳパケットが一定数存在する場合、ＲＴＰパケットを再構築する。ステップＳ８において、マルチキャスト配信部３９は再構築したＲＴＰパケットを含むＲＴＰマルチキャストストリームを配信する。
【００４７】
ＰＭＴのパケット、映像データ又は音声データのパケットはＰＩＤが変更されることもある。したがって、無線／有線ＬＡＮゲートウェイ１２は基本的に、ＰＡＴ／ＰＭＴのパケットを受信する毎に、図５のフローチャートの処理が必要となる。なお、ＰＡＴ／ＰＭＴのパケットの解析は、負荷を下げるために、所定時間ごとに行うようにしてもよい。
【００４８】
図５のフローチャートに示した処理により、システム２は不要なＭＰＥＧ２−ＴＴＳパケットを取り除いたＲＴＰパケットを含むＲＴＰマルチキャストストリームを配信することができる。ＲＴＰパケットの生成は、複数のＭＰＥＧ２−ＴＴＳパケットを連続してＲＴＰパケットのペイロードとして、ＲＴＰヘッダをＲＴＰプロトコルにしたがって付ければよい。
【００４９】
図６はＰＩＤパケット種別対応テーブルの一実施例の構成図である。ＰＩＤパケット種別対応テーブルはデータ項目として、例えばパケット種別、対応ユーザ要求、ＰＩＤ（パケット識別子）を有している。
【００５０】
図６のパケット種別としてはＰＡＴ／ＰＭＴ／ＢＩＴ／ＮＩＴ／ＥＩＴ／ＣＤＴ／ＳＤＴＴ／ＰＥＳ（映像／音声／データカルーセル）等が考えられる。なお、ＰＥＳ（データカルーセル）とは地上デジタル放送で行われているデータ放送のようなデータを送信するために使用されるパケットのパケット種別である。
【００５１】
通常、ＰＡＴ／ＢＩＴ／ＮＩＴ／ＥＩＴ／ＣＤＴ／ＳＤＴＴのパケットのＰＩＤは固定である。一方、ＰＭＴ／ＰＥＳのパケットのＰＩＤはＰＡＴ／ＰＭＴを解析することで得ることができる。図６のＰＩＤパケット種別対応テーブルの固定でないＰＭＴ／ＰＥＳのパケットのＰＩＤは、ＰＡＴ／ＰＭＴを解析した結果で埋められる。
【００５２】
なお、ＰＩＤパケット種別対応テーブルは後述の必要情報によって得られる情報と対応づけるために、データ項目として対応ユーザ要求を定義している。なお、ＰＩＤパケット種別対応テーブルは、パケット種別と対応ユーザ要求との対応づけを例えばユーザが変更できるようにしてもよい。
【００５３】
図７は無線／有線ＬＡＮゲートウェイ及びＩＰＴＶ対応プレイヤの処理手順を表した一実施例のフローチャートである。ステップＳ１１において、ＩＰＴＶ対応プレイヤ１４の必要情報判定部４８は画面表示／録画などの動作上、必要となる情報が何であるかを判定する。
【００５４】
必要情報判定部４８は、例えば録画予約状態時、放送時間変更を確認するために番組表用のデータが必要となると判定する。必要情報判定部４８は番組表を表示（なお、音声は出力されるが、映像は出ない）しようとする場合は、番組表用のデータと音声用のデータとが必要となると判定する。２ヶ国語放送で第一音声を出力している場合は音声１データが必要となると判定する。音声を第一音声から第二音声に切り替えた場合は音声２データが必要となると判定する。
【００５５】
上記のように、ＩＰＴＶ対応プレイヤ１４において必要となる情報は状況に応じて変化する。そして、ステップＳ１２において、必要情報通知部４９は必要となる情報を必要情報として無線／有線ＬＡＮゲートウェイ１２の必要情報受信部４０に送信する。
【００５６】
ステップＳ１３において、無線／有線ＬＡＮゲートウェイ１２の必要情報受信部４０はＩＰＴＶ対応プレイヤ１４から情報の必要・不要に関する必要情報を受信する。ステップＳ１４において、必要性規則変更部４１は必要情報に基づき、必要性規則テーブルを更新する。
【００５７】
必要情報として情報のやりとりをするパラメータ、および、必要性規則テーブルで必要・不要に対応づけるパラメータとしては以下のものが考えられる。必要性規則テーブルを更新する処理は、ＩＰＴＶ対応プレイヤ１４から必要情報を受信する毎に実行することになる。したがって、ＩＰＴＶ対応プレイヤ１４からの必要情報に応じて、無線／有線ＬＡＮゲートウェイ１２が行うマルチキャスト配信に含まれるＭＰＥＧ２−ＴＴＳパケットのパケット種別は変わることになる。
【００５８】
例えば番組表と音声１データとが必要情報として要求された場合は、無線／有線ＬＡＮゲートウェイ１２が行うマルチキャスト配信に含まれるＭＰＥＧ２−ＴＴＳパケットのパケット種別に番組表と音声１データとが必要であるように必要性規則テーブルを更新することになる。
【００５９】
具体的に、ＩＰＴＶ対応プレイヤ１４で録画予約状態のとき、必要情報としては放送時間変更を確認するため、番組表用のデータが含まれる。ＩＰＴＶ対応プレイヤ１４で番組表を表示するとき、必要情報としては番組表用のデータが含まれる。ＩＰＴＶ対応プレイヤ１４で第一音声を出力しているとき、必要情報としては音声１データが含まれる。
【００６０】
図８は必要情報の一例の構成図である。図８に示すように、必要情報はＩＰＴＶ対応プレイヤ１４の動作に応じて必要となる情報を指定するものである。図８の例では番組表用のデータ（ＥＰＧ）と第一音声のデータ（Ａｕｄｉｏ１）とが必要となる情報として指定されている。図８の例では映像のデータ、マルチ音声の第一音声以降のデータ、データ放送のデータが不要であることを表している。
【００６１】
図９は必要性規則テーブルの一実施例の構成図である。必要性規則テーブルはデータ項目として、例えば対応ユーザ要求、必要・不要を有している。なお、図９において、対応ユーザ要求「Ａｌｗａｙｓ」は必ず送信が必要であることを表している。「ＥＰＧ」は番組表のデータを表している。
【００６２】
「Ｌｏｇｏ」は放送局ロゴアイコンのデータを表している。「Ｄｏｗｎｌｏａｄ」はソフトウェア更新のためのデータを表している。「Ｖｉｄｅｏ」は映像のデータを表している。「Ａｕｄｉｏ」は音声のデータを表している。「Ｄａｔａ」はデータ放送のデータを表している。
【００６３】
図９の必要性規則テーブルではデータ項目「必要・不要」が「Ｔｒｕｅ」になっているところがＩＰＴＶ対応プレイヤ１４の動作に応じて必要となる情報（必要情報）を表している。
【００６４】
図１０はコンテンツを配信するシステムの他の実施例の処理ブロック図である。ＩＰＴＶ用サーバ１０はマルチキャスト送信部７１を有する。無線／有線ＬＡＮゲートウェイ１２はマルチキャスト受信部７２、ＲＴＰ解析部７３、ＭＰＥＧ２ヘッダ解析部７４、ＰＩＤ判定部７５、パケット蓄積部７６、ＲＴＰ再構築部７７、マルチキャスト配信部７８、必要ＰＩＤ受信部７９、必要ＰＩＤテーブル記憶部８０、ＭＰＥＧ２−ＴＴＳパケット記憶部８１を有する。
【００６５】
また、ＩＰＴＶ対応プレイヤ１４は必要情報判定部８２、必要性規則変更部８３、ＰＩＤ必要性対応づけ実施部８４、必要ＰＩＤ送信部８５、必要性規則テーブル８６、ＰＩＤパケット種別対応テーブル８７、録画部８８、表示部８９、制御部９０、ＲＴＰ解析部９１、ＭＰＥＧ２解析部９２、ＰＩＤパケット種別対応テーブル更新部９３、マルチキャスト受信部９４を有する。なお、図１０の処理ブロック図は本実施例の説明に不要な一部構成を省略している。また、図１０の処理ブロック図は図３の処理ブロック図と同一な部分を含むため、同一な部分について適宜説明を省略している。
【００６６】
ＩＰＴＶ用サーバ１０のマルチキャスト送信部７１はＲＴＰマルチキャストストリームを送信する。無線／有線ＬＡＮゲートウェイ１２のマルチキャスト受信部７２はＲＴＰマルチキャストストリームを受信し、ＲＴＰマルチキャストストリームからＲＴＰパケットを取り出す。ＲＴＰ解析部７３はＲＴＰパケットを解析し、ＲＴＰペイロードに含まれるＭＰＥＧ２−ＴＴＳパケットを抽出する。
【００６７】
ＭＰＥＧ２ヘッダ解析部７４はＭＰＥＧ２−ＴＴＳパケットのヘッダ部を解析してＰＩＤを検出する。ＰＩＤ判定部７５は必要ＰＩＤテーブルに基づき、検出したＰＩＤが必要か否かを判定する。パケット蓄積部７６は必要と判定されたＭＰＥＧ２−ＴＴＳパケットをＭＰＥＧ２−ＴＴＳパケット記憶部８１に蓄積する。ＲＴＰ再構築部７７は蓄積されたＭＰＥＧ２−ＴＴＳパケットが一定数存在する場合、ＲＴＰパケットを再構築する。マルチキャスト配信部７８は再構築したＲＴＰパケットをＩＰＴＶ対応プレイヤ１４にマルチキャスト配信する。
【００６８】
必要ＰＩＤ受信部７９はＩＰＴＶ対応プレイヤ１４から必要ＰＩＤを受信し、必要ＰＩＤに基づき、必要ＰＩＤテーブルを更新する。必要ＰＩＤテーブル記憶部８０は必要ＰＩＤテーブルを記憶する。ＭＰＥＧ２−ＴＴＳパケット記憶部８１はＭＰＥＧ２−ＴＴＳパケットを記憶する。
【００６９】
必要情報判定部８２はユーザ操作や自動的な動作により必要情報を判定する。必要性規則変更部８３は必要情報に基づき、必要性規則テーブルを更新する。ＰＩＤ必要性対応づけ実施部８４はＰＩＤパケット種別対応テーブル、必要性規則テーブルに基づき、ＰＩＤと必要性との対応づけを実施する。必要ＰＩＤ送信部８５は対応づけにより必要と判定されたＰＩＤを必要ＰＩＤとして無線／有線ＬＡＮゲートウェイ１２に通知する。
【００７０】
必要性規則テーブル記憶部８６は必要性規則テーブルを記憶する。ＰＩＤパケット種別対応テーブル記憶部８７はＰＩＤパケット種別対応テーブルを記憶する。録画部８８はＭＰＥＧ２−ＴＴＳパケットに基づき、コンテンツの録画を行う。表示部８９は、ＭＰＥＧ２−ＴＴＳパケットに基づき、コンテンツの表示を行う。
【００７１】
制御部９０はＲＴＰパケットを解析し、ＲＴＰペイロードに含まれるＭＰＥＧ２−ＴＴＳパケットを抽出する。制御部９０はユーザ操作等により、ＭＰＥＧ２−ＴＴＳパケットを録画部８８や表示部８９に送信して、コンテンツの録画や表示を行う。ＲＴＰ解析部９１はＲＴＰパケットを解析し、ＲＴＰペイロードに含まれるＭＰＥＧ２−ＴＴＳパケットを抽出する。ＭＰＥＧ２解析部９２はＭＰＥＧ２−ＴＴＳパケットを解析し、パケット種別ごとのＰＩＤを検出する。
【００７２】
ＰＩＤパケット種別対応テーブル更新部９３はパケット種別とＰＩＤとの対応づけを行い、ＰＩＤパケット種別対応テーブルを更新する。マルチキャスト受信部９４はＲＴＰマルチキャストストリームを受信し、ＲＴＰマルチキャストストリームからＲＴＰパケットを取り出す。
【００７３】
図１１は必要ＰＩＤテーブルの一実施例の構成図である。図１１の必要ＰＩＤテーブルはＩＰＴＶ対応プレイヤ１４から受信した必要ＰＩＤを蓄積したものである。必要ＰＩＤテーブルを利用することにより、図１０の無線／有線ＬＡＮゲートウェイ１２はＩＰＴＶ対応プレイヤ１４で不要なＭＰＥＧ２−ＴＴＳパケットを取り除いたＲＴＰパケットをマルチキャスト配信できる。
【００７４】
図１２は必要ＰＩＤの一例の構成図である。図１２に示すように、必要ＰＩＤはＩＰＴＶ対応プレイヤ１４の動作に応じて必要となるＭＰＥＧ２−ＴＴＳパケットのＰＩＤを指定するものである。例えば図１２の例ではＰＩＤが０ｘ０００１、０ｘ００２４、０ｘ００１０、０ｘ００１２のＭＰＥＧ２−ＴＴＳパケットが必要なことを示している。
【００７５】
ＩＰＴＶ対応プレイヤ１４から受信した図１２の必要ＰＩＤにより、無線／有線ＬＡＮゲートウェイ１２の必要ＰＩＤテーブルは書き換えられる。したがって、無線／有線ＬＡＮゲートウェイ１２は、ＩＰＴＶ対応プレイヤ１４側の状況に応じた対応を行うことができる。
【００７６】
無線／有線ＬＡＮゲートウェイ１２は、ＩＰＴＶ対応プレイヤ１４側の状況の変化に応じて必要となるＭＰＥＧ２−ＴＴＳパケットのＰＩＤを必要ＰＩＤとして受信することにより、不要なＭＰＥＧ２−ＴＴＳパケットを削除し、必要なＭＰＥＧ２−ＴＴＳパケットをマルチキャスト配信できる。
【００７７】
図１０のコンテンツを配信するシステムは必要性規則テーブル８６、ＰＩＤパケット種別対応テーブル８７をＩＰＴＶ対応プレイヤ１４側に有している。図１０のコンテンツを配信するシステムはＩＰＴＶ対応プレイヤ１４側でＲＴＰマルチキャストストリームを解析して、ＩＰＴＶ対応プレイヤ１４側の状況の変化に応じて必要となるＭＰＥＧ２−ＴＴＳパケットのＰＩＤを必要ＰＩＤとして無線／有線ＬＡＮゲートウェイ１２に要求することができる。
【００７８】
図１３は複数のＩＰＴＶ対応プレイヤに対応する必要性規則テーブルの一実施例の構成図である。図１３の必要性規則テーブルは図９の必要性規則テーブルの必要情報をＩＰＴＶ対応プレイヤ１４毎に管理するように拡張した例である。図１３の必要性規則テーブルはＩＰＴＶ対応プレイヤ１４が増えた場合、列を増やすことで対応できる。
【００７９】
図１３の必要性規則テーブルはＩＰＴＶ対応プレイヤ１４を識別するための情報を持つことが必要である。ＩＰＴＶ対応プレイヤ１４を識別する方法は一般的に使用されている方法でよい。例えば図１３の必要性規則テーブルは機器ＩＤ（ｄｅｖｉｃｅｉｄ）が「２００１：：１」のＩＰＴＶ対応プレイヤ１４と機器ＩＤが「２００１：：２」のＩＰＴＶ対応プレイヤ１４とに対応する必要情報を表している。なお、図１３の必要性規則テーブルは、どちらか一方が必要を表す「Ｔｒｕｅ」になっている場合、必要を意味する。
【００８０】
例えば図３のコンテンツを配信するシステムではＩＰＴＶ対応プレイヤ１４を識別する情報を、例えば図１４に示すように必要情報を拡張して通知する。図１４は複数のＩＰＴＶ対応プレイヤに対応する必要情報の一例の構成図である。図１４の必要情報では図８の必要情報に加えて、ｄｅｖｉｃｅｉｄと呼ばれる属性を設定し、そのｄｅｖｉｃｅｉｄ属性にＩＰＴＶ対応プレイヤ１４を識別するための情報の一例としてＩＰＴＶ対応プレイヤ１４のＩＰｖ６アドレスを使用している。なお、ＩＰｖ６アドレスは他の機器と重複することがない。その他、ＩＰＴＶ対応プレイヤ１４を識別するための情報はＭＡＣアドレスを使用してもよい。
【００８１】
また、図１０のコンテンツを配信するシステムではＩＰＴＶ対応プレイヤ１４を識別する情報を、例えば図１２に示すＰＩＤ情報を拡張して通知する。図１２に示すＰＩＤ情報を拡張して、ＩＰＴＶ対応プレイヤ１４を識別する情報を通知する場合は、例えばｄｅｖｉｃｅｉｄ属性を設定するなど同様に拡張して、必要ＰＩＤテーブルにＩＰＴＶ対応プレイヤ１４ごとのＰＩＤを記憶すればよい。
【００８２】
このように、図３及び図１０のコンテンツを配信するシステムは、複数のＩＰＴＶ対応プレイヤ１４がホームネットワーク上に存在する場合であっても、適切に動作することができる。
【００８３】
図１５は複数のチャンネル（コンテンツストリーム）に対応する必要性規則テーブルの一実施例の構成図である。図１５の必要性規則テーブルは、図１３の必要性規則テーブルの必要情報をＩＰＴＶ対応プレイヤ１４及びチャンネル毎に管理するように拡張した例である。
【００８４】
複数のＩＰＴＶ対応プレイヤ１４が存在する場合、各ＩＰＴＶ対応プレイヤ１４は異なるチャンネルを表示している状況がある。また、ＩＰＴＶ対応プレイヤ１４が一つしか存在しない場合であっても、別々のチャンネルを同時に録画及び表示する場合もある。このような場合、図１５の必要性規則テーブルはＩＰＴＶ対応プレイヤ１４及びチャンネルに対応する列を増やすことで対応できる。
【００８５】
図１５の必要性規則テーブルは、チャンネルを識別するための情報を持つことが必要である。チャンネルを識別する方法は一般的に使用されている方法でよい。例えばチャンネルを識別する方法は、ソースアドレスと呼ばれるＲＴＰ配信要求をする際に指定されるＩＰアドレスを使用することが容易である。ソースアドレスは、実際に配信されているＲＴＰマルチキャストストリームのヘッダ部を見ることでも確認できる。ＩＰＴＶ対応プレイヤ１４が指定して配信要求をするため、無線／有線ＬＡＮゲートウェイ１２及びＩＰＴＶ対応プレイヤ１４はソースアドレスで一意にチャンネルを識別できる。
【００８６】
例えば図１５の必要性規則テーブルは、ＩＰＴＶ対応プレイヤ１４及びチャンネル毎に対応する必要情報を表している。なお、図１５の必要性規則テーブルは、何れかが必要を表す「Ｔｒｕｅ」になっている場合、必要を意味する。言い換えれば、ＩＰＴＶ対応プレイヤ１４及びチャンネルの組み合わせの何れかが必要である情報はマルチキャスト配信される。
【００８７】
例えば図３のコンテンツを配信するシステムではチャンネルを識別するための情報を例えば図１６に示すように必要情報を拡張して通知する。図１６は複数のＩＰＴＶ対応プレイヤ及びチャンネルに対応する必要情報の一例の構成図である。図１６の必要情報では図１４の必要情報に加えて、ｃｈａｎｎｅｌｉｄと呼ばれる属性を設定し、そのｃｈａｎｎｅｌｉｄ属性にチャンネルを識別するための情報の一例としてソースアドレスを使用している。なお、チャンネルを識別するための情報はソースアドレス以外を使用してもかまわない。
【００８８】
以上、本実施例のコンテンツを配信するシステムによれば、ＩＰＴＶ対応プレイヤ１４で不要なＭＰＥＧ２−ＴＴＳパケットを無線／有線ＬＡＮゲートウェイ１２で取り除いて配信できるので、ホームネットワークで使用する帯域を減らすことができる。
【００８９】
また、本実施例のコンテンツを配信するシステムによれば、ユーザのＩＰＴＶ対応プレイヤ１４の使用状況に応じて必要なＭＰＥＧ２−ＴＴＳパケットを自動的に判定し、動的に配信するＭＰＥＧ２−ＴＴＳパケットを変更するため、ユーザは負担を感じない。
【００９０】
また、本実施例のコンテンツを配信するシステムは、ＰＩＤとパケット種別との対応づけを行うため、ＰＩＤが固定でない場合にも利用できる。また、本実施例のコンテンツを配信するシステムは、複数のＩＰＴＶ対応プレイヤ１４が存在しても、必要性規則テーブルを変更することにより、対応することができる。さらに、本実施例のコンテンツを配信するシステムは、複数のチャンネルが存在し、複数のチャンネルを同時に利用する場合であっても、必要性規則テーブルを変更することにより、対応することができる。
【００９１】
なお、本実施例のコンテンツを配信するシステムのホームネットワークにおける帯域の削減効果は、通常のテレビ放送を基準とすると以下のようになる。例えばマルチ編成として複数（２〜３）の番組がひとつのＲＴＰマルチキャストストリームに含まれる場合にはホームネットワークにおける帯域を１／３程度に削減できる。また、通常のテレビ放送において、データ放送のデータは最大１割程度含まれる。データ放送が不要なとき、データ放送のデータを削減することで、ホームネットワークにおける帯域は最大１割程度、削減できる。
【００９２】
また、マルチビューとよばれる複数の映像がひとつのＲＴＰマルチキャストストリームに含まれる場合には、ひとつの映像にすることで、ホームネットワークにおける帯域を最大１／２程度に削減できる。さらに、ＩＰＴＶ対応プレイヤ１４で予約録画をしている場合には番組の時間変更を確認するため、ＳＩ情報（番組情報）が必要となる。このような場合は、映像・音声・データ放送のデータをすべて削減できるため、ホームネットワークにおける帯域を９割以上、削減できる。
【００９３】
本発明は、以下に記載する付記のような構成が考えられる。
（付記１）
受信した複数種類のデータをネットワークに配信するデータ配信装置によって実行されるデータ配信方法であって、
前記ネットワークに配信した前記データを受信する受信機から、必要なデータの種類を必要情報として受信し、
前記受信したデータの種類を解析し、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築し、
前記再構築したデータを前記ネットワークに配信する
ことを特徴とするデータ配信方法。
（付記２）
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築する処理は、前記必要情報に基づき変更される記憶部に記憶された前記必要なデータの種類を表すテーブルに従って、前記受信したデータを前記必要なデータの種類で再構築する
ことを特徴とする付記１記載のデータ配信方法。
（付記３）
前記テーブルは前記受信機ごとに、前記必要なデータの種類を表す
ことを特徴とする付記２記載のデータ配信方法。
（付記４）
前記テーブルは前記受信機及び前記受信機で選択可能なチャンネルごとに、前記必要なデータの種類を表す
ことを特徴とする付記２記載のデータ配信方法。
（付記５）
必要なデータの種類を必要情報として受信する処理は、前記必要情報として前記データの識別子を受信し、
前記受信したデータの種類を解析する処理は、前記データの識別子を解析し、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築する処理は、前記受信したデータの識別子と前記必要情報として受信した前記データの識別子とに基づき、前記必要情報として受信した前記識別子のデータで前記受信したデータを再構築する
ことを特徴とする付記３又は４記載のデータ配信方法。
（付記６）
必要なデータの種類を必要情報として受信する処理は、前記必要情報として前記データの種別を受信し、
前記受信したデータの種類を解析する処理は、前記データの識別子を解析し、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築する処理は、前記受信したデータの識別子と前記必要情報として受信した前記データの種別とに基づき、前記必要情報に基づき変更される記憶部に記憶された前記必要なデータの種別と前記データの識別子とを対応づけるテーブルに従って、前記必要情報として受信した前記種別のデータで前記受信したデータを再構築する
ことを特徴とする付記３又は４記載のデータ配信方法。
（付記７）
受信した複数種類のデータをネットワークに配信するデータ配信装置であって、
前記ネットワークに配信した前記データを受信する受信機から、必要なデータの種類を必要情報として受信する受信手段と、
前記受信したデータの種類を解析する解析手段と、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築する再構築手段と、
前記再構築したデータを前記ネットワークに配信する配信手段と
を有することを特徴とするデータ配信装置。
（付記８）
受信した複数種類のデータをネットワークに配信するデータ配信装置に、
前記ネットワークに配信した前記データを受信する受信機から、必要なデータの種類を必要情報として受信し、
前記受信したデータの種類を解析し、
前記受信したデータを前記必要情報に基づき前記必要なデータの種類で再構築し、
前記再構築したデータを前記ネットワークに配信する
処理を実行させるデータ配信プログラム。
【００９４】
本実施例におけるデータ配信プログラムは、パッケージソフトの他、ＷＥＢサービス等によっても提供可能である。なお、上記の特許請求の範囲に記載した記憶部は例えばＲＡＭ６３に相当し、受信手段は例えば必要情報受信部４０に相当し、解析手段はＭＰＥＧ解析部３４に相当し、再構築手段はＲＴＰ再構築部３８に相当し、配信手段はマルチキャスト配信部３９に相当する。
【符号の説明】
【００９５】
１    システム
１０    ＩＰＴＶ用サーバ
１１    Ｗｅｂサーバ
１２    無線／有線ＬＡＮゲートウェイ
１３    ＰＣ
１４、２１    ＩＰＴＶ対応プレイヤ
１５、１６    ネットワーク
３１、７１    マルチキャスト送信部
３２、７２    マルチキャスト受信部
３３、７３、９１    ＲＴＰ解析部
３４    ＭＰＥＧ解析部
３５、９３    ＰＩＤパケット種別対応テーブル更新部
３６、８４    ＰＩＤ必要性対応づけ実施部
３７、７６    パケット蓄積部
３８、７７    ＲＴＰ再構築部
３９、７８    マルチキャスト配信部
４０    必要情報受信部
４１、８３    必要性規則変更部
４２、８７    ＰＩＤパケット種別対応テーブル記憶部
４３、８６    必要性規則テーブル記憶部
４４、８１    ＭＰＥＧ２−ＴＴＳパケット記憶部
４５、８８    録画部
４６、８９    表示部
４７、９０    制御部
４８、８２    必要情報判定部
４９    必要情報通知部
５０、９４    マルチキャスト受信部
６１    ＣＰＵ
６２    ＲＯＭ
６３    ＲＡＭ
６４    第１インタフェース（Ｉ／Ｆ）
６５    第２インタフェース（Ｉ／Ｆ）
６６    Ｉ／Ｏ
６７    表示部
６８    キー部
７４    ＭＰＥＧ２ヘッダ解析部
７５    ＰＩＤ判定部
７９    必要ＰＩＤ受信部
８０    必要ＰＩＤテーブル記憶部
８５    必要ＰＩＤ送信部
９２    ＭＰＥＧ２解析部
【図１】
2012119741.tif 000003
【図２】
2012119741.tif 000004
【図３】
2012119741.tif 000005
【図４】
2012119741.tif 000006
【図５】
2012119741.tif 000007
【図６】
2012119741.tif 000008
【図７】
2012119741.tif 000009
【図８】
2012119741.tif 000010
【図９】
2012119741.tif 000011
【図１０】
2012119741.tif 000012
【図１１】
2012119741.tif 000013
【図１２】
2012119741.tif 000014
【図１３】
2012119741.tif 000015
【図１４】
2012119741.tif 000016
【図１５】
2012119741.tif 000017
【図１６】
2012119741.tif 000018