(57)【要約】【課題】再生用情報の更新が反映されずに誤った再生が行われる可能性を低減する。【解決手段】送信機１は、複数のメディアユニットのうち構成情報（ＣＩ）が更新されたメディアユニットを特定するＣＩ更新判断部１５と、ＣＩ更新判断部１５が特定したメディアユニットに、構成情報の更新を示すフラグを含むヘッダを付加した伝送パケットを生成するヘッダ生成部１４とを備えている。【選択図】図１
2015065488.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンポーネントで構成されるコンテンツを送信するために、上記コンポーネントを所定の分割単位で分割して生成された複数のユニットの１つを含むパケットを生成する生成装置であって、
上記複数のユニットのうち、上記コンポーネントの再生態様を示し、再生時に参照すべき再生用情報が更新されたユニットを特定する更新ユニット特定手段と、
上記更新ユニット特定手段が特定したユニットと、上記再生用情報の更新を示す更新情報とを含むパケットを生成するパケット生成手段とを備えていることを特徴とする生成装置。
【請求項２】
上記パケット生成手段は、上記更新情報を含むパケットに、該パケットに含まれる上記ユニットの再生の際に参照すべき上記再生用情報を取得するための取得用情報を含めることを特徴とする請求項１に記載の生成装置。
【請求項３】
更新後の上記再生用情報の取得先を示す取得先情報を含むパケットを生成する再生用情報取得パケット生成手段を備えていることを特徴とする請求項１に記載の生成装置。
【請求項４】
複数のコンポーネントで構成されるコンテンツを、該コンポーネントが所定の分割単位で分割されたユニットとして含まれるパケットとして受信し、再生する再生装置であって、
受信したパケットに、上記コンポーネントの再生態様を示し、再生時に参照すべき再生用情報の更新を示す更新情報が含まれていることを検出する検出手段と、
上記検出手段が、上記パケットに上記更新情報が含まれていることを検出したときに、当該パケットに含まれる上記ユニットを、更新後の再生用情報に従って再生する再生手段とを備えていることを特徴とする再生装置。
【請求項５】
上記検出手段が、上記パケットに上記更新情報が含まれていることを検出したときに、当該パケットに含まれる上記ユニットを、更新後の再生用情報に従って再生するための準備処理を行う準備手段を備えていることを特徴とする請求項４に記載の再生装置。
【請求項６】
複数のコンポーネントで構成されるコンテンツを送信するためのパケットのデータ構造であって、
上記コンポーネントを所定の分割単位で分割して生成された複数のユニットのうち、上記コンポーネントの再生態様を示し、再生時に参照すべき再生用情報が更新されたユニットと、上記再生用情報の更新を示す更新情報とを含むことを特徴とするデータ構造。
【請求項７】
複数のコンポーネントで構成されるコンテンツを送信するために、上記コンポーネントを所定の分割単位で分割して生成された複数のユニットの１つを含むパケットを生成する生成装置によるパケットの生成方法であって、
上記複数のユニットのうち、上記コンポーネントの再生態様を示し、再生時に参照すべき再生用情報が更新されたユニットを特定する更新ユニット特定ステップと、
上記更新ユニット特定ステップで特定したユニットと、上記再生用情報の更新を示す更新情報とを含むパケットを生成するパケット生成ステップとを含むことを特徴とする生成方法。
【請求項８】
複数のコンポーネントで構成されるコンテンツを、該コンポーネントが所定の分割単位で分割されたユニットとして含まれるパケットとして受信し、再生する再生装置による再生方法であって、
受信したパケットに、上記コンポーネントの再生態様を示し、再生時に参照すべき再生用情報の更新を示す更新情報が含まれていることを検出する検出ステップと、
上記検出ステップで、上記パケットに上記更新情報が含まれていることを検出したときに、当該パケットに含まれる上記ユニットを、更新後の再生用情報に従って再生する再生ステップとを含むことを特徴とする再生方法。
【請求項９】
請求項１から３の何れか１項に記載の生成装置を動作させるための制御プログラムであって、コンピュータを上記各手段として機能させるための制御プログラム。
【請求項１０】
請求項４または５に記載の再生装置を動作させるための制御プログラムであって、コンピュータを上記各手段として機能させるための制御プログラム。
【請求項１１】
請求項９または１０に記載の制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のコンポーネントで構成されるコンテンツをネットワークを介して送信するときのデータ構造等に関する。
【背景技術】
【０００２】
近年、映像、音声、テキストなどの様々なコンテンツの配信が行われており、このようなコンテンツを配信するための伝送フォーマットの規格化も進められている。特に、ＭＰＥＧ ＭＭＴ（MPEG Media Transport：MPEGメディア伝送プロトコル）の標準化は、注目を集めている。
【０００３】
このＭＰＥＧ ＭＭＴでは、映像、音声、テキストなどの複数のコンポーネントをそれぞれ異なる経路で配信（ハイブリッド配信）するのに効率的な伝送フォーマット等の標準化が進められている。
【０００４】
ＭＰＥＧ ＭＭＴのコンテンツは、パッケージ（MMT Package）として格納され、複数のコンポーネント（MMT Asset）に加え、各コンポーネントの表示位置、大きさなどのレイアウトや組み合わせ可否などの再生条件を示す構成情報（Composition Information：ＣＩ）、および最適配信経路を判断するための各コンポーネントの必要帯域や許容遅延などの伝送特性情報（Transport Characteristics：ＴＣ）に関するデータを少なくとも含む。
【０００５】
このようなコンテンツは、パケットに分割して単一のネットワークで伝送することができ、また複数のネットワークで（ハイブリッド）伝送することもできる。これについて、図１１に基づいて説明する。図１１は、コンテンツの伝送態様を示す図であり、同図（ａ）は単一ネットワークによる伝送の例を示し、同図（ｂ）は複数ネットワークによるハイブリッド伝送の例を示している。なお、同図では、１つの伝送パケットを１つのブロックとして記載している。
【０００６】
同図（ａ）の例では、構成情報の伝送パケットＣＩ１と、伝送特性情報の伝送パケットＴＣ１の後に、複数の伝送パケット（Ａ１，１、Ａ２，１、…）が続いている。このＡ１，１以降の伝送パケット（Ａｉ,ｊ：ｉ＝１，２，…、ｊ＝１，２，…）には、アセットを構成するメディアユニットがそれぞれ含まれている。これらのメディアユニットは、ＴＣ１に基づいて決定したネットワークを介して受信機に送信され、受信機はこれらのメディアユニットをＣＩ１に基づいて再生する。
【０００７】
また、図示の例では、構成情報の伝送パケットがもう一つ含まれており（ＣＩ２）、この伝送パケットの後には、複数の伝送パケット（Ａ１，ｐ、Ａ２，ｑ、…）が続いている。これらの伝送パケットに含まれるメディアユニットは、ＣＩ２に基づいて再生される。つまり、１つのアセットの途中で参照すべき構成情報がＣＩ１からＣＩ２に変わっている。
【０００８】
同図（ａ）の例では、これらの伝送パケットは、何れも１つのネットワークを介し、１つの経路で送信機から受信機に配信される。
【０００９】
一方、同図（ｂ）の例では、構成情報（ＣＩ１，ＣＩ２，…）の伝送パケットと、１番目のアセットを構成するメディアユニットを含む伝送パケット（Ａ１，１、…、Ａ１，ｐ、…）と、２番目のアセットを構成するメディアユニットを含む伝送パケット（Ａ２，１、…、Ａ２，ｑ、…）とは、それぞれ別のネットワークを介して別の経路で伝送される。なお、ハイブリッド伝送については、下記の特許文献１にも記載されている。
【００１０】
このように、同図（ａ）（ｂ）何れの場合であっても、１つのコンテンツに対して複数の構成情報を送信することができる。このため、送信側の意向やコンポーネントの特性に応じて、１つのコンポーネントの配信途中で構成情報を変更することも可能である。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開平１０−１７３６１２号公報（１９９８年６月２６日公開）
【発明の概要】
【発明が解決しようとする課題】
【００１２】
上記のような伝送パケットを受信した受信機は、構成情報（ＣＩ）の内容に基づいて、コンポーネントをユーザに提示する。このため、何らかの原因で更新後の構成情報の受信が想定以上に遅延した場合等には、構成情報の更新に伴う処理が遅延し、これによって、コンポーネントの再生開始が遅延することがあった。また、更新前の構成情報に基づいて誤ったレイアウトや組み合わせで表示されることもあった。
【００１３】
これは、特に、図１１（ｂ）のように、複数のネットワークを利用した伝送において生じる可能性が高い問題点である。また、これは、構成情報に限られず、再生時に参照すべき再生用情報を受信機に送信するシステムにおける共通の問題点である。
【００１４】
本発明は、上記の問題点に鑑みてなされたものであり、その目的は、再生用情報の更新が反映されずに誤った再生が行われる可能性を低減することのできる生成装置等を提供することにある。
【課題を解決するための手段】
【００１５】
上記の課題を解決するために、本発明の生成装置は、複数のコンポーネントで構成されるコンテンツを送信するために、上記コンポーネントを所定の分割単位で分割して生成された複数のユニットの１つを含むパケットを生成する生成装置であって、上記複数のユニットのうち、上記コンポーネントの再生態様を示し、再生時に参照すべき再生用情報が更新されたユニットを特定する更新ユニット特定手段と、上記更新ユニット特定手段が特定したユニットと、上記再生用情報の更新を示す更新情報とを含むパケットを生成するパケット生成手段とを備えていることを特徴としている。
【００１６】
また、本発明の生成方法は、上記の課題を解決するために、複数のコンポーネントで構成されるコンテンツを送信するために、上記コンポーネントを所定の分割単位で分割して生成された複数のユニットの１つを含むパケットを生成する生成装置によるパケットの生成方法であって、上記複数のユニットのうち、上記コンポーネントの再生態様を示し、再生時に参照すべき再生用情報が更新されたユニットを特定する更新ユニット特定ステップと、上記更新ユニット特定ステップで特定したユニットと、上記再生用情報の更新を示す更新情報とを含むパケットを生成するパケット生成ステップとを含むことを特徴としている。
【００１７】
上記の構成によれば、複数のユニットのうち、再生時に参照すべき再生用情報が更新されたユニットを特定し、該特定したユニットと、再生用情報の更新を示す更新情報とを含むパケットを生成する。
【００１８】
したがって、このパケットを受信した再生装置では、更新情報によって、そのユニットの再生時に参照すべき再生用情報が従前のものから更新されたことを特定することができる。つまり、上記の構成によれば、更新後の再生用情報を参照して再生すべきユニットを含むパケットを受信した再生装置に、そのパケットに含まれるユニットの再生時に参照すべき再生用情報が更新されたことを認識させることができる。
【００１９】
このため、再生装置において、再生用情報の更新が反映されずに誤った再生が行われる可能性を低減することができる。また、再生装置では、更新情報を受信したときから、再生用情報の更新のための準備を開始することができるので、更新後の再生用情報に基づく再生開始をスムーズに行うことができる。
【００２０】
なお、上記再生用情報は、ユニットの再生時に参照すべき情報であり、コンポーネントの再生態様を示すものであればよい。例えば、コンポーネントのレイアウトを示すものであってもよいし、コンポーネントの他のコンポーネントとの組み合わせ可否を示すものであってもよいし、これらの両方を示す情報であってもよい。
【００２１】
また、上記パケット生成手段は、上記更新情報を含むパケットに、該パケットに含まれる上記ユニットの再生の際に参照すべき上記再生用情報を取得するための取得用情報を含めることが好ましい。
【００２２】
上記の構成によれば、更新情報を含むパケットに、該パケットに含まれるユニットの再生の際に参照すべき再生用情報を取得するための取得用情報を含める。
【００２３】
したがって、このパケットを受信した再生装置では、更新後の再生用情報の受信が遅延している場合等であっても、取得用情報を用いて再生用情報を取得し、この再生用情報を参照して当該ユニットを再生することができる。
【００２４】
また、上記生成装置は、更新後の上記再生用情報の取得先を示す取得先情報を含むパケットを生成する再生用情報取得パケット生成手段を備えていることが好ましい。
【００２５】
上記の構成によれば、更新後の上記再生用情報の取得先を示す取得先情報を含むパケットを生成する。したがって、このパケットを受信した再生装置では、取得先情報が示す取得先にアクセスすることによって、更新後の再生用情報を取得することができる。
【００２６】
これにより、更新後の再生用情報の受信が遅延している場合等であっても、更新後の再生用情報を参照した再生が可能になる。また、再生用情報の再生装置への送信を省略することも可能になる。
【００２７】
また、本発明の再生装置は、上記の課題を解決するために、複数のコンポーネントで構成されるコンテンツを、該コンポーネントが所定の分割単位で分割されたユニットとして含まれるパケットとして受信し、再生する再生装置であって、受信したパケットに、上記コンポーネントの再生態様を示し、再生時に参照すべき再生用情報の更新を示す更新情報が含まれていることを検出する検出手段と、上記検出手段が、上記パケットに上記更新情報が含まれていることを検出したときに、当該パケットに含まれる上記ユニットを、更新後の再生用情報に従って再生する再生手段とを備えていることを特徴としている。
【００２８】
そして、本発明の再生方法は、上記の課題を解決するために、複数のコンポーネントで構成されるコンテンツを、該コンポーネントが所定の分割単位で分割されたユニットとして含まれるパケットとして受信し、再生する再生装置による再生方法であって、受信したパケットに、上記コンポーネントの再生態様を示し、再生時に参照すべき再生用情報の更新を示す更新情報が含まれていることを検出する検出ステップと、上記検出ステップで、上記パケットに上記更新情報が含まれていることを検出したときに、当該パケットに含まれる上記ユニットを、更新後の再生用情報に従って再生する再生ステップとを含むことを特徴としている。
【００２９】
上記の構成によれば、受信したパケットに更新情報が含まれていることを検出したときに、当該パケットに含まれるユニットを、更新後の再生用情報に従って再生するので、再生用情報の更新が反映されずに誤った再生が行われることがない。
【００３０】
また、上記再生装置は、上記検出手段が、上記パケットに上記更新情報が含まれていることを検出したときに、当該パケットに含まれる上記ユニットを、更新後の再生用情報に従って再生するための準備処理を行う準備手段を備えていることが好ましい。
【００３１】
上記の構成によれば、パケットに更新情報が含まれていることを検出したときに、当該パケットに含まれるユニットを更新後の再生用情報に従って再生するための準備処理を行う。
【００３２】
このように、更新情報を受信したときから、再生用情報の更新のための準備を開始することによって、更新後の再生用情報に基づく再生開始をスムーズに行うことができる。
【００３３】
また、本発明のデータ構造は、上記の課題を解決するために、複数のコンポーネントで構成されるコンテンツを送信するためのパケットのデータ構造であって、上記コンポーネントを所定の分割単位で分割して生成された複数のユニットのうち、上記コンポーネントの再生態様を示し、再生時に参照すべき再生用情報が更新されたユニットと、上記再生用情報の更新を示す更新情報とを含むことを特徴としている。
【００３４】
上記のデータ構造のパケットは、再生用情報が更新されたユニットと、再生用情報の更新を示す更新情報とを含む。このため、このデータ構造のパケットを受信した再生装置では、更新情報によって、そのユニットの再生時に参照すべき再生用情報が従前のものから更新されたことを特定することができる。
【００３５】
したがって、再生装置において、再生用情報の更新が反映されずに誤った再生が行われる可能性を低減することができる。また、再生装置では、更新情報を受信したときから、再生用情報の更新のための準備を開始することができるので、更新後の再生用情報に基づく再生開始をスムーズに行うことができる。
【００３６】
なお、上記生成装置および上記再生装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記生成装置および上記再生装置の各手段として動作させることにより、上記生成装置および上記再生装置をコンピュータにて実現させる制御プログラム、及びそれを記録したコンピュータ読み取り可能な記録媒体も本発明の範疇に入る。
【発明の効果】
【００３７】
以上のように、本発明の生成装置は、複数のユニットのうち、コンポーネントの再生態様を示し、再生時に参照すべき再生用情報が更新されたユニットを特定する更新ユニット特定手段と、上記更新ユニット特定手段が特定したユニットと、上記再生用情報の更新を示す更新情報とを含むパケットを生成するパケット生成手段とを備えている。
【００３８】
また、本発明の生成方法は、以上のように、複数のユニットのうち、コンポーネントの再生態様を示し、再生時に参照すべき再生用情報が更新されたユニットを特定する更新ユニット特定ステップと、上記更新ユニット特定ステップで特定したユニットと、上記再生用情報の更新を示す更新情報とを含むパケットを生成するパケット生成ステップとを含む構成である。
【００３９】
そして、本発明の再生装置は、以上のように、受信したパケットに、コンポーネントの再生態様を示し、再生時に参照すべき再生用情報の更新を示す更新情報が含まれていることを検出する検出手段と、上記検出手段が、上記パケットに上記更新情報が含まれていることを検出したときに、当該パケットに含まれる上記ユニットを、更新後の再生用情報に従って再生する再生手段とを備えている構成である。
【００４０】
また、本発明の再生方法は、以上のように、受信したパケットに、コンポーネントの再生態様を示し、再生時に参照すべき再生用情報の更新を示す更新情報が含まれていることを検出する検出ステップと、上記検出ステップで、上記パケットに上記更新情報が含まれていることを検出したときに、当該パケットに含まれる上記ユニットを、更新後の再生用情報に従って再生する再生ステップとを含む構成である。
【００４１】
そして、本発明のデータ構造は、以上のように、コンポーネントを所定の分割単位で分割して生成された複数のユニットのうち、上記コンポーネントの再生態様を示し、再生時に参照すべき再生用情報が更新されたユニットと、上記再生用情報の更新を示す更新情報とを含む構成である。
【００４２】
したがって、再生装置において、再生用情報の更新が反映されずに誤った再生が行われる可能性を低減することができる。
【図面の簡単な説明】
【００４３】
【図１】本発明の一実施形態にかかるコンテンツ送受信システムを構成する送信機および受信機の要部構成を示すブロック図である。
【図２】上記コンテンツ送受信システムで取り扱うコンテンツのデータ構造の一例を示す図である。
【図３】上記コンテンツの伝送形式の一例を示す図である。
【図４】更新情報を含む伝送パケットの一例を示す図である。
【図５】構成情報を更新することによってアセットの表示レイアウトを更新する例を示す図である。
【図６】構成情報を更新することによってアセットの組み合わせ表示の可否を変更する例を示す図である。
【図７】上記送信機が実行する伝送パケット生成処理の一例を示すフローチャートである。
【図８】上記受信機が実行する再生処理の一例を示すフローチャートである。
【図９】構成情報を取得するためのＵＲＬを含む伝送パケットヘッダの構造（シンタックス）の一例を示す図である。
【図１０】最新の構成情報を取得するためのＵＲＬを含む構成情報の一例を示す図である。
【図１１】従来から用いられているコンテンツの伝送態様を示す図であり、同図（ａ）は単一ネットワークによる伝送の例を示し、同図（ｂ）は複数ネットワークによるハイブリッド伝送の例を示している。
【発明を実施するための形態】
【００４４】
以下、本発明の実施の形態について、図１〜図１０に基づいて詳細に説明する。
【００４５】
〔システム構成〕
まず、本実施形態にかかるコンテンツ送受信システムの構成を図１に基づいて説明する。図１は、コンテンツ送受信システム３を構成する送信機（生成装置）１および受信機（再生装置）２の要部構成を示すブロック図である。
【００４６】
図示のように、コンテンツ送受信システム３は、送信機１と受信機２とがネットワークを介して接続された構成であり、コンテンツ送受信システム３では、送信機１が送信するコンテンツを受信機２が受信して再生する。
【００４７】
なお、図示の例では、送信機１と受信機２とが直接通信しているが、これに限られない。例えば、送信機１と受信機２との通信は中継機が中継してもよいし、送信機１から他の配信サーバにコンテンツを配信し、この配信サーバから受信機２にコンテンツを配信してもよい。
【００４８】
また、ここでは、送信機１と受信機２とを接続するネットワークがインターネットである例を説明するが、このネットワークは送信機１と受信機２とがコンテンツを送受信可能なものであればよく、これに限定されない。例えば、上記ネットワークとして、放送網を適用してもよいし、インターネットと放送網とを併用するハイブリッド配信を採用してもよい。
【００４９】
送信機１は、コンテンツを配信する装置であり、送信機１の機能を統括して制御する送信機制御部１０、送信機１が送信するデータを格納する送信機記憶部１１、および送信機１が外部の装置と通信を行うための送信機通信部１２を備えている。
【００５０】
また、送信機制御部１０は、コンテンツ分割部１３、ヘッダ生成部（パケット生成手段）１４、およびＣＩ更新判断部（更新ユニット特定手段）１５を含み、送信機記憶部１１にはコンテンツ１６が格納されている。
【００５１】
コンテンツ分割部１３は、コンテンツ１６を配信するために分割する。具体的には、コンテンツのコンポーネントを、例えばメディアユニット単位で分割してペイロードとして格納するデータを生成する。また、コンテンツ１６から構成情報（Composition Information：ＣＩ、再生用情報）や伝送特性情報（Transport Characteristics：ＴＣ）等を特定し抽出する。なお、メディアユニット、構成情報、および伝送特性情報の詳細については後述する。
【００５２】
ヘッダ生成部１４は、コンテンツ分割部１３が生成したデータに付加するヘッダを生成する。具体的には、ヘッダ生成部１４は、少なくともペイロードタイプ（payload type）を示す情報を含むペイロードフォーマットヘッダ（Payload Format Header）を生成し、これをメディアユニット、構成情報、および伝送特性情報のそれぞれに付加してペイロードを生成する。また、配信するパケットのそれぞれについて、伝送パケットヘッダ（Transport Packet Header）を生成し、ペイロードにこれを付加して伝送パケットを生成する。
【００５３】
ＣＩ更新判断部１５は、メディアユニットの再生時に参照すべき構成情報が、その直前に配信したメディアユニット（直前に再生されるメディアユニット）の再生時に参照すべき構成情報から更新されているか否かを判断する。そして、更新されていると判断した場合に、その旨をヘッダ生成部１４に通知する。この通知を受信したヘッダ生成部１４は、構成情報が更新されたことを示す更新情報を含むヘッダを生成する。
【００５４】
このように、送信機１では、構成情報が更新されたメディアユニットについては、更新情報をヘッダに記述する。これにより、構成情報が更新されたことを受信機２に確実に認識させ、メディアユニットを送信機１側の意図に沿って再生させることができる。
【００５５】
コンテンツ１６は、送信機１が配信するコンテンツである。上述のように、コンテンツ１６は、コンテンツ分割部１３によって分割され、ヘッダ生成部１４にヘッダを付加されて、伝送パケットとして配信される。
【００５６】
一方、受信機２は、コンテンツを受信して再生する装置であり、受信機２の機能を統括して制御する受信機制御部２０、受信機２が受信するデータを格納する受信機記憶部２１、受信機２が外部の装置と通信を行うための受信機通信部２２、画像を表示する表示部２３、および音声を出力する音声出力部２４を備えている。
【００５７】
また、受信機制御部２０は、ヘッダ解析部（検出手段）２５、デコーダ（準備手段）２６、および再生制御部（再生手段）２７を含んでいる。
【００５８】
ヘッダ解析部２５は、受信した伝送パケットのヘッダを解析し、その解析結果に応じた処理を実行する。具体的には、ヘッダ解析部２５は、解析したヘッダに上述の更新情報が含まれていることを検出した場合、構成情報が更新されることをデコーダ２６に通知し、構成情報の更新準備を行わせる。また、ヘッダ解析部２５は、解析したヘッダが、ペイロードとしてメディアユニットを含むことを示している場合には、このペイロードをデコーダ２６に送信してデコードさせる。一方、解析したヘッダが、ペイロードとして構成情報を含むことを示している場合には、このペイロードを再生制御部２７に送信する。
【００５９】
デコーダ２６は、受信した伝送パケットに含まれるメディアユニットをデコードする。デコードしたデータは再生制御部２７の制御に従って、表示部２３および音声出力部２４から出力される。また、デコーダ２６は、ヘッダ解析部２５から、構成情報の更新を通知されたときに、構成情報の更新のための準備処理を行う。
【００６０】
再生制御部２７は、構成情報に従ってコンポーネントを再生する。具体的には、再生制御部２７は、デコーダ２６がデコードしたメディアユニットを、構成情報に従って、表示部２３および音声出力部２４から出力させる。また、再生制御部２７は、ヘッダ解析部２５が上述の更新情報を検出した場合、そのペイロードに含まれるメディアユニットを、更新後の構成情報に従って再生する。
【００６１】
〔コンテンツのデータ構造〕
次に、コンテンツ１６のデータ構造を図２に基づいて説明する。図２は、コンテンツ１６のデータ構造の一例を示す図である。
【００６２】
コンテンツ１６は、ヘッダ、構成情報（ＣＩ）、伝送特性情報（ＴＣ）、および複数のアセット（Asset）を含むパッケージ（Package）として送信機記憶部１１に格納されている。
【００６３】
アセットは、映像、音声、テキスト等のコンポーネントであり、ヘッダと複数のメディアユニット（Ｍ−Ｕｎｉｔ：ＭＵ）とで構成されている。また、メディアユニットは、ランダムアクセスやタイムスタンプ付与の単位となるユニットであり、ヘッダと複数のメディアフラグメントユニット（Media Fragment Unit：ＭＦＵ）とで構成されている。
【００６４】
構成情報は、コンポーネントの再生態様を示す。具体的には、構成情報は、各コンポーネントの表示位置、表示サイズなどのレイアウトや、コンポーネント間の組み合わせ可否（他のコンポーネントとの同時再生の可否）などを示す。各メディアユニットは、構成情報を参照して再生される。
【００６５】
伝送特性情報は、各コンポーネントの伝送特性を示す。具体的には、伝送特性情報は、最適配信経路を判断するための各コンポーネントの必要帯域や許容遅延などを示す。
【００６６】
〔コンテンツの伝送形式〕
続いて、コンテンツ１６の伝送形式を図３に基づいて説明する。図３は、コンテンツ１６の伝送形式の一例を示す図である。
【００６７】
コンテンツ１６をＴＣＰ／ＩＰ、ＵＤＰ／ＩＰ等で伝送する場合、ペイロード（Payload）にヘッダを付加した伝送パケット（Transport Packet）の形式とする。このペイロードのヘッダに、上述の更新情報が記述される。
【００６８】
また、コンテンツ１６のパッケージを配信する際のペイロードフォーマットは、図示のように、メディアユニット（ＭＵ）、構成情報（ＣＩ）、および伝送特性情報（ＴＣ）のそれぞれにヘッダを付加した形式である。
【００６９】
なお、図３のペイロードフォーマットでは、１つのメディアユニットを１つのペイロードとしているが、これに限定されない。例えば、伝送パケットのサイズに制約がある場合には、メディアユニットをさらに分割してそれぞれを異なるペイロードとして伝送してもよいし、複数のメディアユニットをまとめて１つのペイロードとして伝送してもよい。この場合、ペイロードフォーマットヘッダに、メディアユニットを構成する最初のメディアフラグメントユニットを含むか否かを示すフラグ、メディアユニットを構成する最後のメディアフラグメントユニットを含むか否かを示すフラグ等を記述する構成としてもよい。
【００７０】
〔更新情報の詳細〕
続いて、更新情報の詳細について、図４に基づいて説明する。図４は、更新情報を含む伝送パケットの一例を示す図である。
【００７１】
同図では、連続して配信する２つの伝送パケットを示しており、先に配信する伝送パケットのペイロードをＡｉ，ｊ−１、次に配信する伝送パケットのペイロードをＡｉ，ｊとしている。
【００７２】
これらのペイロードは、何れもｉ番目のアセットに対応しており、Ａｉ，ｊ−１はこのアセットのｊ−１番目のメディアユニットを含み、Ａｉ，ｊはこのアセットのｊ番目のメディアユニットを含んでいる。そして、このＡｉ，ｊ−１が含むメディアユニットの再生時に参照すべき構成情報と、Ａｉ，ｊが含むメディアユニットの再生時に参照すべき構成情報とは異なっている。
【００７３】
このように、参照すべき構成情報がそれ以前のペイロードとは異なるペイロードについては、構成情報が更新されたことを示す更新情報をそのヘッダに記述する。
【００７４】
図示の例では、フラグ（composition_update_indicator）をペイロードのヘッダに記述することにより、当該ペイロードに含まれるメディアユニットの再生の際に参照する構成情報が、直前のペイロードから更新されたか否かを示している。
【００７５】
具体的には、同図のＡｉ，ｊ−１のペイロードのヘッダには、composition_update_indicator=‘0’と記述されており、これは構成情報が更新されていないことを示している。一方、Ａｉ，ｊのペイロードのヘッダには、composition_update_indicator=‘1’と記述されており、これは構成情報が更新されたことを示している。
【００７６】
受信機２は、このフラグの値を確認することにより、各ペイロードに含まれるメディアユニットを正しい構成情報に基づいて再生することができる。すなわち、受信機２は、composition_update_indicator=‘0’と記述されているペイロードに含まれるメディアユニットについては、参照する構成情報を変更することなく再生する。一方、composition_update_indicator=‘1’と記述されているペイロードに含まれるメディアユニットについては、参照する構成情報を変更して再生する。
【００７７】
以上のように、更新後の構成情報に基づいて再生すべきメディアユニットと更新情報とを含む伝送パケットのデータ構造によれば、受信機２において、構成情報の更新が反映されずに誤った再生が行われる可能性を低減することができる。
【００７８】
〔構成情報の更新の具体例〕
次に、構成情報の更新の具体例を図５に基づいて説明する。図５は、構成情報を更新することによってアセットの表示レイアウトを更新する例を示す図である。
【００７９】
図示のように、更新前の表示レイアウトでは、アセット１がメインコンポーネントとして全画面表示されており、アセット２はサブコンポーネントとして１／２に縮小されて画面の左上に表示されている。この表示レイアウトは、同図に示す構成情報（更新前）に基づいて実現される。
【００８０】
すなわち、構成情報（更新前）では、＜layout＞タグによって、領域r1（全画面表示に対応）および領域r2（表示画面を縦横に４分割した左上領域に対応）が定義されている。そして、アセットの組み合わせ表示を指定する＜combi＞タグによって、領域r1に対してアセット１が対応付けられ、領域r2に対してアセット２が対応付けられている。また、このレイアウトを時刻0sから適用することを示す記述（start="0s"）が含まれている。
【００８１】
このため、受信機２は、アセット１および２を含むコンテンツの再生開始と同時に（0sから）、同図に示すように、アセット１を全画面表示し、アセット２を１／２に縮小して画面の左上に表示する。
【００８２】
一方、構成情報（更新後）では、＜combi＞タグの記述が更新されている。すなわち、構成情報（更新後）では、アセット１は領域r2に対応付けられており、アセット２は領域r1に対応付けられている。また、このレイアウトを時刻15mから開始することを示す記述（start="15m"）が含まれている。
【００８３】
このため、受信機２は、時刻15mに、同図の表示レイアウトに示すように、アセット２をメインコンポーネントとして全画面表示し、アセット１をサブコンポーネントとして１／２に縮小して画面の左上に表示する。このように、構成情報を更新することによって、アセットの表示レイアウトを変更することができる。
【００８４】
この場合、更新後の構成情報に基づく再生が確実に行われるように、更新後の構成情報に基づいて再生すべきメディアユニットのうち再生時間が最先のものについては、構成情報が更新されたことを示す更新情報を対応付ける。具体的には、図示の例では、時刻15mに対応するメディアユニット（アセット１のメディアユニットおよびアセット２のメディアユニット）を含む各伝送パケットのヘッダにcomposition_update_indicator=‘1’のフラグを付加する。また、それ以外の伝送パケットのヘッダにはcomposition_update_indicator=‘0’のフラグを付加する。
【００８５】
続いて、構成情報の更新の他の例を図６に基づいて説明する。図６は、構成情報を更新することによってアセットの組み合わせ表示の可否を変更する例を示す図である。
【００８６】
図６の構成情報（更新前）では、＜layout＞タグによって、領域r1（表示画面を縦横に４分割した左上領域）および領域r2（表示画面を縦横に４分割した右上領域）が定義されている。そして、＜combi＞タグによって、領域r1に対してアセット１が対応付けられ、領域r2に対してアセット２が対応付けられている。また、このレイアウトを時刻0sから適用することを示す記述（start="0s"）が含まれている。
【００８７】
このため、受信機２は、再生開始と同時に（0sから）、同図の表示レイアウトに示すように、アセット１を表示画面を４分割した左上領域に表示し、アセット２を表示画面を４分割した右上領域に表示する。
【００８８】
一方、構成情報（更新後）では、＜layout＞タグの記述が更新されている。また、＜combi＞タグの代わりにアセットの相互排他的（Mutually Exclusive）表示を指定する＜excl＞タグが記述されている。
【００８９】
具体的には、更新後の＜layout＞タグでは、領域r0（全画面表示に対応）が定義されている。また、＜excl＞タグにより、アセット１を領域r0に表示するか、アセット２を領域r0に表示するかの何れか一方が可能であることが定義されている。また、この表示を時刻15mから適用することを示す記述（start="15m"）が含まれている。
【００９０】
このため、受信機２は、時刻15mに、同図の表示レイアウトに示すように、アセット１をメインコンポーネントとして全画面表示するか、またはアセット２をメインコンポーネントとして全画面表示する。このように、構成情報を更新することによって、アセットの組み合わせ表示の可否を変更することもできる。
【００９１】
この場合も、更新後の構成情報に基づく再生が確実に行われるように、更新後の構成情報に基づいて再生すべきメディアユニットについては、構成情報が更新されたことを示す更新情報を対応付ける。具体的には、時刻15mに対応するメディアユニット（アセット１のメディアユニットおよびアセット２のメディアユニット）を含む各伝送パケットのヘッダにcomposition_update_indicator=‘1’のフラグを付加する。また、それ以外の伝送パケットのヘッダにはcomposition_update_indicator=‘0’のフラグを付加する。
【００９２】
なお、図５および図６ではＳＭＩＬ（Synchronized Multimedia Integration Language）によって構成情報を記述した例を示しているが、構成情報はアセットの表示態様を示すものであればよく、その記述形式は特に限定されない。
【００９３】
〔伝送パケット生成処理の流れ〕
次に、送信機１が実行する伝送パケット生成処理（生成方法）の流れを図７に基づいて説明する。図７は、伝送パケット生成処理の一例を示すフローチャートである。なお、伝送パケット生成処理を行うタイミングは特に限定されない。例えばオンデマンド配信では、受信機２からコンテンツの送信要求を受信したとき、ライブ配信ではコンテンツをエンコードする際に行えばよい。
【００９４】
以下では、送信機記憶部１１に既に記録されているコンテンツ１６をオンデマンド配信する場合の伝送パケット生成処理の流れについて説明する。
【００９５】
まず、コンテンツ分割部１３は、送信機記憶部１１に格納されているコンテンツ１６を読み出して、ペイロード（厳密には図３における伝送パケットのペイロード部分に格納するデータ）を生成する。具体的には、コンテンツ分割部１３は、図２に示したようにパッケージとして格納されているコンテンツ１６からアセットを取得し、取得したアセットを分割して複数のペイロードを生成する（Ｓ１）。そして、コンテンツ分割部１３は、上記のようにして生成した複数のペイロードをヘッダ生成部１４に出力する。
【００９６】
なお、ペイロードへの分割単位はメディアユニットに限定されない。例えば、ペイロードのサイズに制約がある場合、メディアユニットを所定のサイズでさらに分割したものをペイロードとしてもよい。また、分割のオーバーヘッドをできるだけ小さくしたい場合等には、複数のメディアユニットをまとめて１つのペイロードとしてもよい。また、コンテンツ分割部１３は、パッケージに含まれる構成情報（ＣＩ）や伝送特性情報（ＴＣ）についてもコンテンツ１６より抽出して、ヘッダ生成部１４に出力する。
【００９７】
次に、ヘッダ生成部１４は、入力された複数のペイロードから、ペイロードタイプを示す情報を含むペイロードフォーマットを生成する（Ｓ２）。具体的には、ヘッダ生成部１４は、ペイロードタイプがメディアユニットであることを示す情報（payload_type=MU）を記述したペイロードフォーマットヘッダを生成し、これを各メディアユニットに付加して、図３に示したようなペイロードフォーマットを生成する。
【００９８】
なお、ペイロードフォーマットのペイロードタイプは、コンテンツ分割部１３から受信したデータに応じたものとする。例えば、コンテンツ分割部１３から構成情報が入力された場合には、ペイロードタイプが構成情報であることを示す情報（payload_type=CI）を記述したペイロードフォーマットヘッダを生成する。同様に、伝送特性情報（ＴＣ）が入力された場合には、伝送特性情報であることを示す情報（payload_type=TC）を記述したペイロードフォーマットヘッダを生成する。
【００９９】
次に、ヘッダ生成部１４は、ＣＩ更新判断部１５に指示して、Ｓ２で生成したペイロードフォーマットに対応するメディアユニットの構成情報が更新されているか判断させる（Ｓ３、更新ユニット特定ステップ）。
【０１００】
ＣＩ更新判断部１５は、当該メディアユニットのタイムスタンプと、更新後のＣＩに記述されている構成情報が変更される時刻（図５の例では時刻15m）とを比較することによって、当該メディアユニットの構成情報が更新されているか判断する。
【０１０１】
すなわち、ＣＩ更新判断部１５は、更新後のＣＩに記述されている、構成情報の変更時刻に対応するタイムスタンプを持つメディアユニットについては、構成情報が更新されていると判断する。一方、上記以外のメディアユニットについては、構成情報が更新されていないと判断する。
【０１０２】
なお、送信機記憶部１１に記録されたコンテンツを配信するのではなく、ライブ配信等でリアルタイムにコンテンツをエンコードしながら配信する場合には、レイアウトなどの再生条件（再生態様）の変更を指示するユーザ入力に基づいて構成情報が更新されたことを判断する。つまり、上記のユーザ入力が行われた直後に処理するメディアユニットについて、構成情報が更新されていると判断する。
【０１０３】
ヘッダ生成部１４は、この判断結果に応じて、composition_update_indicatorの値を決定する。すなわち、ＣＩ更新判断部１５が構成情報が更新されていないと判断した場合（Ｓ３でＮＯ）、ヘッダ生成部１４は、composition_update_indicator=‘0’と決定する（Ｓ４）。一方、構成情報が更新されていると判断した場合（Ｓ３でＹＥＳ）、ヘッダ生成部１４は、composition_update_indicator=‘1’と決定する（Ｓ５）。
【０１０４】
続いて、ヘッダ生成部１４は、Ｓ４またはＳ５で決定した値のcomposition_update_indicatorを含む伝送パケットを生成する（Ｓ６、パケット生成ステップ）。具体的には、ヘッダ生成部１４は、composition_update_indicator=‘0’またはcomposition_update_indicator=‘1’の記述を含む伝送パケットヘッダを生成し、これをＳ２で生成したペイロードフォーマットに付加して、図３に示したような伝送パケットを生成する。
【０１０５】
そして、ヘッダ生成部１４は、生成した伝送パケットを送信機通信部１２に出力し（Ｓ７）、伝送パケット生成処理は終了する。これにより、上記のようにして生成された伝送パケットは、ネットワークを介して受信機２に送信される。
【０１０６】
〔再生処理の流れ〕
続いて、受信機２が実行する再生処理（再生方法）の流れを図８に基づいて説明する。図８は、再生処理の一例を示すフローチャートである。なお、図８では、１つの伝送パケットについて、その受信から出力までの処理を示している。
【０１０７】
受信機通信部２２は、送信機１の送信機通信部１２から送信された伝送パケットを、ネットワーク経由で受信し（Ｓ１０）、この伝送パケットをヘッダ解析部２５に出力する。そして、ヘッダ解析部２５は、受信した伝送パケットのヘッダ（伝送パケットヘッダ）を解析し（Ｓ１１）、composition_update_indicator=‘1’であるか判断する（Ｓ１２、検出ステップ）。
【０１０８】
この解析の結果、composition_update_indicator=‘1’であることが確認された場合（Ｓ１２でＹＥＳ）、ヘッダ解析部２５は、構成情報が更新されることをデコーダ２６に通知する（Ｓ１３）。この通知を受信したデコーダ２６は、構成情報の更新に必要な処理（例えば、画像拡大縮小モジュールの初期化など）を実行する。この後、処理はＳ１４に進む。一方、composition_update_indicator=‘0’であることが確認された場合（Ｓ１２でＮＯ）、Ｓ１３の処理は行わずにＳ１４の処理に進む。
【０１０９】
Ｓ１４では、ヘッダ解析部２５は、ペイロードフォーマットヘッダを解析する。この解析の結果、payload_type==MUであることが確認された場合（Ｓ１５でＹＥＳ）、このペイロードフォーマットヘッダが付加されている伝送パケットに含まれるメディアユニットをデコーダ２６に出力する（Ｓ１６）。
【０１１０】
これにより、このメディアユニットがデコードされて、再生制御部２７の制御により、構成情報に従って、表示部２３および／または音声出力部２４から出力され（再生ステップ）、再生処理は終了する。無論、composition_update_indicator=‘1’のヘッダが付加されたメディアユニットの再生の際に参照する構成情報は、更新後の構成情報である。
【０１１１】
一方、Ｓ１４の解析の結果、payload_type==MUではないことが確認された場合（Ｓ１５でＮＯ）、payload_typeに従ってペイロードを各処理部に出力する（Ｓ１７）。例えば、payload_type==CIであれば、ペイロードは構成情報を含むため、これを再生制御部２７に送信して設定を行わせる。これにより、再生処理は終了する。
【０１１２】
上述の再生処理では、composition_update_indicatorの値を確認した後で、そのヘッダに含まれるメディアユニットを再生するので、更新後の構成情報を参照して再生すべきメディアユニットを更新前の構成情報を参照して再生することを防ぐことができる。
【０１１３】
また、構成情報の更新を伝送パケットヘッダの解析の段階でデコーダ２６へ通知（Ｓ１３）して、構成情報の更新に必要な処理を実行させるので、構成情報の更新のための処理によって、メディアユニットの再生が遅延することを防ぐことができる。
【０１１４】
〔変形例：構成情報を更新するためのＵＲＬの送信〕
以上のように、更新情報を記述することにより、受信機２は構成情報が更新されたことを認識することができる。しかしながら、更新後の構成情報の受信が遅延している場合等には、更新後の構成情報に基づく再生を開始することができない。
【０１１５】
そこで、更新後の構成情報に基づいて再生すべきメディアユニットについては、更新情報と共に、更新後の構成情報を取得するための取得用情報を対応付けて配信してもよい。これについて、図９に基づいて説明する。図９は、構成情報を取得するためのＵＲＬを含む伝送パケットヘッダの構造（シンタックス）の一例を示す図である。
【０１１６】
図示の伝送パケットヘッダ構造では、１ビットのフラグcomposition_update_indicatorの後、composition_update_indicator==‘1’の場合に、ＵＲＬ（取得用情報）を含むか否かを示す１ビットのフラグcontains_urlが続く。contains_url==‘1’の場合、ＵＲＬの長さ（バイト長）を示す14ビットの値url_len、およびＵＲＬを示すurl_lenバイト（url_len*8ビット）の文字列url[i]（i=0, 1, …, url_len-1）が続く。このＵＲＬ（またはＵＲＩ）は、更新後の構成情報のリクエスト先を示している。なお、ＵＲＬに関するこれらの情報は、図７のＳ５において記述すればよい。
【０１１７】
受信機２は、composition_update_indicator==‘1’の伝送パケットを受信した場合、この伝送パケットに含まれるメディアユニットは、従前とは異なる構成情報に基づいて再生する必要がある。更新後の構成情報が受信されていない場合、contains_url==‘1’であれば、url[]で示されるＵＲＬにアクセスすることで、更新後の構成情報を取得することができる。
【０１１８】
また、最新の構成情報の取得先を示す取得先情報を初期の構成情報等に記述しておき、受信機２が、composition_update_indicator=‘1’のパケットを受信したときに、この取得先情報が示す取得先から構成情報を取得して更新するようにしてもよい。
【０１１９】
これについて、図１０に基づいて説明する。図１０は、最新の構成情報を取得するためのＵＲＬ（取得先情報）を含む構成情報の一例を示す図である。図示の構成情報では、＜location＞タグにより、最新の構成情報を取得するためのＵＲＬを記述している。
【０１２０】
この構成情報を受信した受信機２では、まず、この構成情報に基づいてコンテンツの再生を行う。この構成情報に基づく再生は、受信した伝送パケットヘッダにおいて、composition_update_indicator=‘0’である期間中継続する。
【０１２１】
そして、受信した伝送パケットヘッダにおいて、composition_update_indicator=‘1’であることが確認されたときには、ヘッダ解析部２５は、デコーダ２６に構成情報の更新を通知して、更新の準備を行わせる（図８のＳ１３）。また、このときに、ヘッダ解析部２５は、上記のＵＲＬに対してリクエストを行って新たな構成情報を取得し、これを再生制御部２７に通知してコンポジションの設定を更新させる。
【０１２２】
受信機２における上記のような処理を実現するため、送信機１の送信機制御部１０は、上記のような取得先情報を含むパケット（例えば上記ＵＲＬを含む構成情報をペイロードとする伝送パケット）を生成する再生用情報取得パケット生成手段を備えていればよい。これにより、何らかの原因によって受信機２が更新後の構成情報が受信できなかった場合であっても、このＵＲＬにより、構成情報を更新させることができる。
【０１２３】
また、更新後の構成情報を含む伝送パケットを送信する必要もなくなるため、更新後の構成情報を含む伝送パケットの生成および送信を行わないようにして、送信機１から送信するデータ量を減らすこともできる。なお、構成情報を更新する処理の主体は、送信機１であってもよいし、他の装置であってもよい。
【０１２４】
〔伝送パケットの配信を行う主体について〕
上記では、伝送パケットの生成と配信とを何れも送信機１が行う例を説明したが、伝送パケットの生成と配信とを別の装置が行うようにしてもよい。また、伝送パケットの生成と配信とをそれぞれ複数の装置が行うようにしてもよい。例えば、ある装置において放送配信用コンテンツの伝送パケットを生成し、他の装置においてオンデマンド配信用（例えば通信配信用）コンテンツの伝送パケットを生成してもよい。この場合、ある装置と他の装置の何れかにおいて、更新情報を含む伝送パケットを生成すればよい。
【０１２５】
本発明は上述した実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能である。すなわち、請求項に示した範囲で適宜変更した技術的手段を組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
【０１２６】
〔ソフトウェアによる実現例について〕
最後に、送信機１および受信機２の各ブロック、特に送信機制御部１０および受信機制御部２０は、集積回路（ＩＣチップ）上に形成された論理回路によってハードウェア的に実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェア的に実現してもよい。
【０１２７】
後者の場合、送信機１および受信機２は、各機能を実現するプログラムの命令を実行するＣＰＵ、上記プログラムを格納したＲＯＭ（Read Only Memory）、上記プログラムを展開するＲＡＭ（Random Access Memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアである送信機１および受信機２の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、送信機１および受信機２に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
【０１２８】
上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ類、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク類、ＩＣカード（メモリカードを含む）／光カード等のカード類、マスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ／フラッシュＲＯＭ等の半導体メモリ類、あるいはＰＬＤ（Programmable logic device）やＦＰＧＡ（Field Programmable Gate Array）等の論理回路類などを用いることができる。
【０１２９】
また、送信機１および受信機２を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークは、プログラムコードを伝送可能であればよく、特に限定されない。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、この通信ネットワークを構成する伝送媒体も、プログラムコードを伝送可能な媒体であればよく、特定の構成または種類のものに限定されない。例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ（Asymmetric Digital Subscriber Line）回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩＥＥＥ８０２．１１無線、ＨＤＲ（High Data Rate）、ＮＦＣ（Near Field Communication）、ＤＬＮＡ（Digital Living Network Alliance）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。
【産業上の利用可能性】
【０１３０】
本発明は、ネットワークを介してコンテンツを送信する送信機、およびネットワークを介してコンテンツを受信する受信機に利用することができる。
【符号の説明】
【０１３１】
１  送信機（生成装置）
２  受信機（再生装置）
１４  ヘッダ生成部（パケット生成手段）
１５  ＣＩ更新判断部（更新ユニット特定手段）
１６  コンテンツ
２５  ヘッダ解析部（検出手段）
２６  デコーダ（準備手段）
２７  再生制御部（再生手段）
【図１】
2015065488.tif 000003
【図２】
2015065488.tif 000004
【図３】
2015065488.tif 000005
【図４】
2015065488.tif 000006
【図５】
2015065488.tif 000007
【図６】
2015065488.tif 000008
【図７】
2015065488.tif 000009
【図８】
2015065488.tif 000010
【図９】
2015065488.tif 000011
【図１０】
2015065488.tif 000012
【図１１】
2015065488.tif 000013