JP6450804B2 - 再生装置および再生方法 - Google Patents

Description

本発明は、複数のコンポーネントで構成されるコンテンツを再生するために必要な構成情報の配信に関する。また、本発明は、そのようなコンテンツの再生に関する。

下記の特許文献１に記載されているように、近年、映像、音声、テキストなどの複数のコンポーネントで構成されるマルチコンポーネントコンテンツの配信が行われるようになっている。

ここで、このようなマルチコンポーネントコンテンツの受信および再生には、使用可能なコンポーネントおよびその再生態様等を示す構成情報が必要である。このため、再生装置は、再生対象コンテンツの構成情報を各コンポーネントと共に、あるいはコンポーネントとは独立に取得する必要がある。

例えば、ＭＰＥＧ ＭＭＴ（MPEG Media Transport：MPEGメディア伝送）では、構成情報（ＣＩ：Composition Information）をコンポーネントと共に配信し、再生装置はこの構成情報を参照してコンポーネントを再生する。

また、例えば、ＭＰＥＧ−２ Ｓｙｓｔｅｍｓ（ISO/IEC 13818-1）では、ＰＡＴ／ＰＭＴ（Program Association Table/Program Map Table）という構成情報に相当する情報を各コンポーネントと共に多重化して、繰り返し配信している。具体的には、地上デジタル放送では、チャンネル切り替え時の再生開始遅延を最小にするため、通常１００ｍｓｅｃ間隔で構成情報を配信している。

さらに、例えばＲＦＣ ４５６６のＳＤＰ（Session Description Table）や、ＭＰＥＧＤＡＳＨ（ISO/IEC 23009-1）のＭＰＤ（Media Presentation Description）も上記の構成情報に相当する。これらの情報は、コンポーネントとは独立した通信によって、コンポーネントと非同期でオンデマンド配信される。

ここで、ＭＰＥＧ ＭＭＴのコンテンツを構成するコンポーネント、および構成情報について、図１６に基づいて説明する。図１６は、ＭＰＥＧ ＭＭＴにおけるコンポーネントおよび構成情報を説明する図であり、同図（ａ）はコンポーネントおよび構成情報の配信例を示し、同図（ｂ）は構成情報の一例を示している。

同図（ａ）では、１つのコンポーネントおよび１つの構成情報を１つのブロックとして示している。また、同図（ａ）では、コンポーネントおよび構成情報の配信時刻を時系列で示している。なお、破線で示すコンポーネントは、再生が任意のコンポーネントである。

つまり、同図（ａ）では、ｃ１からｃ８の８種類のコンポーネントが送信されるが、このうちｃ１からｃ４のコンポーネントは同じ期間に配信され、ｃ５からｃ８のコンポーネントはこれより後の期間に配信される。

具体例を挙げれば、ｃ１のコンポーネントは、動画像のコンポーネントであり、ｃ２のコンポーネントはこの動画像に対応する音声のコンポーネントであってもよい。そして、ｃ３のコンポーネントは、ｃ１およびｃ２に対応する英語字幕のコンポーネントであり、ｃ４のコンポーネントは仏語字幕のコンポーネントであってもよい。

同様に、ｃ５のコンポーネントは、動画像のコンポーネントであり、ｃ６のコンポーネントはこの動画像に対応する音声のコンポーネントであってもよい。そして、ｃ７のコンポーネントは、ｃ５およびｃ６に対応する英語字幕のコンポーネントであり、ｃ８のコンポーネントは仏語字幕のコンポーネントであってもよい。

この場合、ｃ１、ｃ２のコンポーネントで構成されるシーンの再生後、ｃ５、ｃ６のコンポーネントで構成されるシーンが再生される。また、ｃ１、ｃ２のコンポーネントで構成されるシーンにて、ｃ３またはｃ４のコンポーネントを使用することにより、英語または仏語の字幕を表示させることができる。ｃ５、ｃ６のコンポーネントで構成されるシーンにおいても同様である。

また、同図（ａ）に示すように、構成情報（ＣＩ）は、一定の時間間隔で繰り返し配信される。各構成情報の内容は何れも同じであり、例えば同図（ｂ）に示すような内容である。

同図（ｂ）の構成情報は、＜components＞タグで記述されたコンポーネントの属性に関する情報（コンテンツを構成するコンポーネントを示す情報）と、＜compositions＞タグで記述された再生方法（再生態様）に関する情報とを含む。

具体的には、＜components＞タグ内において、idが"c1"のコンポーネントから、idが"c8"のコンポーネントまでの８つのコンポーネントが記述されている。

また、＜compositions＞タグ内において、ビデオコンポーネントであるｃ１とオーディオコンポーネントであるｃ２とを同時に再生することが記述されている。また、テキストコンポーネントであるｃ３およびｃ４は何れかを選択して使用することが可能であることが記述されている。そして、ｃ５からｃ８のコンポーネントについても同様の記述がなされている。

したがって、これらのコンポーネントを再生する再生装置は、最初に配信されるｃ１およびｃ２のコンポーネントを取得すると共に、繰り返し配信される構成情報を取得する。また、必要に応じてｃ３またはｃ４のコンポーネントも取得する。

これにより、再生装置は、構成情報に従って、ｃ１およびｃ２のコンポーネントを同時に再生し、この再生中において、必要に応じてｃ３またはｃ４のコンポーネントを使用する。

この後、再生装置は、ｃ１およびｃ２のコンポーネントの次に配信されるｃ５およびｃ６のコンポーネントを取得し、必要に応じてｃ７またはｃ８のコンポーネントも取得する。これにより、構成情報に従って、ｃ５およびｃ６のコンポーネントを同時に再生し、この再生中において、必要に応じてｃ７またはｃ８のコンポーネントを使用する。

このように、構成情報を送信することによって、複数のコンポーネントを適切な組み合わせで再生させることができる。また、構成情報に、コンポーネントの再生態様として表示レイアウト等を記述しておくことによって、所定のレイアウトでコンポーネントを再生させること等も可能である。

特開平１０−１７３６１２号公報（１９９８年６月２６日公開）

ここで、複数のネットワーク（伝送経路）を用いたハイブリッド伝送では、１つのコンテンツを構成するコンポーネントが、今後増加することが想定される。そして、マルチコンポーネント化に伴って構成情報の記述が複雑化して、構成情報のデータ量が増加することが想定される。

そして、このように構成情報のデータ量が増大した場合、ＰＡＴ／ＰＭＴのように繰り返し送信する方式では、無駄なデータ送受信が増大することが懸念される。繰り返し送信される構成情報の１つを受信した再生装置は、以後の同一内容の構成情報を参照することなく再生が可能であり、以後の構成情報は破棄することになるためである。

一方、ＳＤＰやＭＤＰのように、オンデマンドで構成情報を取得する方法は、伝送効率はよいが、適応可能なシステムが限られる。例えば、再生クライアントから配信サーバへの通信手段（バックチャネル）をもたない放送などのシステムへの適用が困難である。

本発明は、上記の問題点に鑑みてなされたものであり、その目的は、オンデマンドによる配信を利用しなくとも、効率よく構成情報を配信することが可能な配信装置等を提供することにある。

上記の課題を解決するために、本発明の一態様に係る再生装置は、コンテンツを構成する複数のコンポーネントをそれぞれ特定する情報と、該コンポーネントの再生態様を示す情報とのいずれかを少なくとも含む構成情報に基づき上記コンテンツを再生する再生装置であって、上記構成情報の部分から成る複数の部分構成情報を解析する構成情報解析手段と、上記構成情報解析手段が解析した上記部分構成情報に基づき上記コンテンツを再生する再生手段と、を備え、上記部分構成情報は、該部分構成情報の処理を行う順序を表す参照情報を含み、上記構成情報解析手段は、上記部分構成情報として、一つの主構成情報と一つ以上の副構成情報を解析することを特徴としている。

また、本発明の一態様に係る再生装置は、上記構成情報解析手段が、上記部分構成情報を識別するための情報を、上記部分構成情報、および、上記部分構成情報を格納するデータ形式のヘッダから取得することが好ましい。

上記の課題を解決するために、本発明の一態様に係る再生方法は、コンテンツを構成する複数のコンポーネントをそれぞれ特定する情報と、該コンポーネントの再生態様を示す情報とのいずれかを少なくとも含む構成情報に基づき上記コンテンツを再生する再生方法であって、上記構成情報の部分から成る複数の部分構成情報を解析する構成情報解析ステップと、上記構成情報解析ステップで解析した上記部分構成情報に基づき上記コンテンツを再生する再生ステップと、を含み、上記部分構成情報は、該部分構成情報の処理を行う順序を表す参照情報を含み、上記構成情報解析ステップは、上記部分構成情報として、一つの主構成情報と一つ以上の副構成情報を解析することを特徴としている。

また、上記の課題を解決するために、本発明の一態様に係る配信装置は、コンテンツを構成する複数のコンポーネントをそれぞれ特定する情報と、該コンポーネントの再生態様を示す情報とを少なくとも含む構成情報を取得する取得手段を備えた配信装置であって、上記取得手段が取得した構成情報に含まれる情報の一部を参照形式に書き換えて参照形式構成情報を生成すると共に、参照形式に書き換えられた情報を含む参照先構成情報を生成する構成情報生成手段と、上記構成情報生成手段が生成した上記参照形式構成情報と上記参照先構成情報とを配信する配信制御手段とを備えていることを特徴としている。

また、本発明の一態様に係る配信方法は、上記の課題を解決するために、コンテンツを構成する複数のコンポーネントをそれぞれ特定する情報と、該コンポーネントの再生態様を示す情報とを少なくとも含む構成情報を取得する配信装置による配信方法であって、取得した構成情報に含まれる情報の一部を参照形式に書き換えて参照形式構成情報を生成すると共に、参照形式に書き換えられた情報を含む参照先構成情報を生成する構成情報生成ステップと、上記構成情報生成ステップで生成した上記参照形式構成情報と上記参照先構成情報とを配信する配信制御ステップとを含むことを特徴としている。

また、本発明の一態様に係るデータ構造は、上記課題を解決するために、コンテンツを構成する複数のコンポーネントをそれぞれ特定する情報と、該コンポーネントの再生態様を示す情報とを少なくとも含み、上記コンテンツの再生に用いられる構成情報のデータ構造であって、コンテンツを構成する複数のコンポーネントをそれぞれ特定する上記情報および該コンポーネントの再生態様を示す上記情報の一部が参照形式で記述された参照形式構成情報と、該参照形式構成情報で参照される情報を含む参照先構成情報とを含むことを特徴としている。

以上のように、本発明の配信装置は、取得手段が取得した構成情報に含まれる情報の一部を参照形式に書き換えて参照形式構成情報を生成すると共に、参照形式に書き換えられた情報を含む参照先構成情報を生成する構成情報生成手段と、上記構成情報生成手段が生成した上記参照形式構成情報と上記参照先構成情報とを配信する配信制御手段とを備えている構成である。

また、本発明の配信方法は、以上のように、取得した構成情報に含まれる情報の一部を参照形式に書き換えて参照形式構成情報を生成すると共に、参照形式に書き換えられた情報を含む参照先構成情報を生成する構成情報生成ステップと、上記構成情報生成ステップで生成した上記参照形式構成情報と上記参照先構成情報とを配信する配信制御ステップとを含む構成である。

そして、本発明のデータ構造は、以上のように、コンテンツを構成する複数のコンポーネントをそれぞれ特定する情報および該コンポーネントの再生態様を示す情報の一部が参照形式で記述された参照形式構成情報と、該参照形式構成情報で参照される情報を含む参照先構成情報とを含む構成である。

したがって、取得した構成情報（コンテンツを構成する複数のコンポーネントをそれぞれ特定する情報および該コンポーネントの再生態様を示す情報）をそのまま配信するよりも、全体として効率のよい配信が可能になるという効果を奏する。

本発明の一実施形態を示す図であり、コンテンツ送受信システムを構成する配信サーバおよび再生クライアントの要部構成を示すブロック図である。 記憶している構成情報を、主構成情報と２つの副構成情報とに分割して生成した構成情報の一例を示す図である。 上記主構成情報および副構成情報の配信タイミングの一例を示す図である。 主構成情報、副構成情報、および２つのコンポーネントを配信するペイロードのヘッダに構成情報を識別するための情報を記述したデータ構造の一例を示す図である。 記憶している構成情報を、主構成情報と４つの副構成情報とに分割して生成した構成情報の一例を示す図である。 主構成情報および４つの副構成情報の配信タイミングの一例を示す図である。 コンポーネントのレイアウトの一例を示す図である。 上記レイアウトでコンポーネントを再生させるための構成情報の一例を示す図である。 主構成情報および副構成情報の配信タイミングの一例を示す図である。 構成情報をオンデマンド配信する例を説明する図であり、同図（ａ）は構成情報の配信タイミングの一例を示し、同図（ｂ）は構成情報のデータ例を示している。 構成情報において外部の情報を参照するためのＵＲＬの記述例を示す図であり、同図（ａ）はベースＵＲＬを省略した例、同図（ｂ）は上位ノードに設定されたＵＲＬをベースＵＲＬとして利用する例、同図（ｃ）はベースＵＲＬ形式でベースＵＲＬを指定する例を示している。 主構成情報と副構成情報とを別個の伝送路で配信する例を説明する図であり、同図（ａ）は構成情報の配信タイミングの一例を示し、同図（ｂ）は構成情報のデータ例を示している。 ２種類の再生装置にそれぞれ対応する２つの主構成情報、およびこれら再生装置で共用される副構成情報のデータ例を示す図である。 上記配信サーバがコンテンツの配信の際に実行する配信処理の一例を示すフローチャートである。 上記再生クライアントがコンテンツの再生の際に実行する再生処理の一例を示すフローチャートである。 ＭＰＥＧ ＭＭＴにおけるコンポーネントおよび構成情報を説明する図であり、同図（ａ）はコンポーネントおよび構成情報の配信例を示し、同図（ｂ）は構成情報の一例を示している。 本発明の別の一実施形態を示す図であり、コンテンツ送受信システムを構成する２つの配信サーバおよび再生クライアントの要部構成を示すブロック図である。 主構成情報、副構成情報、および、主構成情報を副構成情報で更新して得られる新たな構成情報を例示した図である。 主構成情報、副構成情報、および、主構成情報を副構成情報で更新して得られる新たな構成情報を例示した図である。 主構成情報、副構成情報、および、主構成情報を副構成情報で更新して得られる新たな構成情報を例示した図である。 主構成情報、副構成情報、および、主構成情報を副構成情報で更新して得られる新たな構成情報を例示した図である。 図１７のコンテンツ送受信システムによる処理の流れと、図２３のコンテンツ送受信システムによる処理の流れと、を概略的に対比した図である。 本発明の別の一実施形態を示す図であり、コンテンツ送受信システムを構成する２つの配信サーバおよび再生クライアントの要部構成を示すブロック図である。 本発明の別の一実施形態を示す図であり、コンテンツ送受信システムを構成する２つの配信サーバおよび再生クライアントの要部構成を示すブロック図である。 主構成情報、副構成情報、および、主構成情報を副構成情報で更新して得られる新たな構成情報を例示した図である。 主構成情報を例示した図である。 主構成情報、副構成情報、および、主構成情報を副構成情報で更新して得られる新たな構成情報を例示した図である。 本発明の別の一実施形態を示す図であり、コンテンツ送受信システムを構成する２つの配信サーバ、２つの配信サーバを管理するコントロールサーバ、および再生クライアントの要部構成を示すブロック図である。 図２８のコントロールサーバの動作を示すフローチャート図である。 本発明の別の一実施形態を示す図であり、コンテンツ送受信システムを構成する２つの配信サーバ、２つの配信サーバを管理するコントロールサーバ、および再生クライアントの要部構成を示すブロック図である。 図３０のコントロールサーバの動作を示すフローチャート図である。 図３０のコントロールサーバの変形例に係る動作を示すフローチャート図である。 本発明の各実施形態に係るコンテンツ送受信システムが使用する構成情報（ＣＩ）と、ＭＭＴ−ＣＩと、を対比した図である。

〔実施形態１〕
以下、本発明の実施の形態について、図１〜図１５に基づいて詳細に説明する。

《システム構成》
まず、本実施形態に係るコンテンツ送受信システムの構成を図１に基づいて説明する。図１は、コンテンツ送受信システム３を構成する配信サーバ（配信装置）１および再生クライアント（再生装置）２の要部構成を示すブロック図である。

図示のように、コンテンツ送受信システム３は、配信サーバ１と再生クライアント２とがネットワークを介して接続された構成であり、コンテンツ送受信システム３では、配信サーバ１が配信するコンテンツを再生クライアント２が受信して再生する。

なお、図示の例では、配信サーバ１と再生クライアント２とが直接通信しているが、これに限られない。例えば、配信サーバ１と再生クライアント２との通信は中継サーバが中継してもよいし、配信サーバ１から他の配信サーバにコンテンツを配信し、この配信サーバから再生クライアント２にコンテンツを配信してもよい。

また、配信サーバ１と再生クライアント２とを接続するネットワークは、配信サーバ１と再生クライアント２とがコンテンツを送受信可能なものであればよく、特に限定されない。例えば、上記ネットワークとして、放送網を適用してもよいし、インターネットを適用してもよい。また、インターネットと放送網など複数のネットワークを併用するハイブリッドネットワークを採用してもよい。

配信サーバ１は、コンテンツを配信する装置であり、配信サーバ１の機能を統括して制御するサーバ制御部１０、配信サーバ１で使用するデータを格納するサーバ記憶部１１、および配信サーバ１が外部の装置と通信を行うためのサーバ通信部１２を備えている。また、サーバ制御部１０は、コンポーネント変換部１３、構成情報解析部（取得手段）１４、構成情報生成部（構成情報生成手段）１５、および配信制御部（配信制御手段）１６を含み、サーバ記憶部１１には構成情報１７およびコンテンツ１８が格納されている。

コンポーネント変換部１３は、コンテンツ１８を所定の分割単位で分割して配信用のコンポーネントに変換する。なお、コンテンツ１８が配信用のコンポーネントとして格納されている場合、コンポーネント変換部１３を省略してもよい。

構成情報解析部１４は、サーバ記憶部１１に格納されている構成情報１７を取得・解析し、構成情報１７に含まれる情報のうち、何れを主構成情報（参照形式構成情報）とし、何れを副構成情報（参照先構成情報）とするかを決定する。なお、主構成情報および副構成情報の詳細は後に詳しく説明する。

構成情報生成部１５は、構成情報解析部１４の決定に従って主構成情報および副構成情報を生成する。配信サーバ１は、構成情報１７から主構成情報および副構成情報を生成し、これらを配信する点が主な特徴点である。

配信制御部１６は、コンテンツ１８の配信を制御する。具体的には、配信制御部１６は、コンポーネント変換部１３が生成したコンポーネントおよび構成情報生成部１５が生成した主構成情報および副構成情報の配信スケジュールを決定する。そして、決定した配信スケジュールに従って、サーバ通信部１２を介して、コンポーネント、主構成情報、および副構成情報を再生クライアント２に配信する。

構成情報１７は、コンテンツ１８を構成するコンポーネント、該コンポーネントの表示位置、大きさなどのレイアウトや組み合わせ可否などの再生条件（再生態様）を示す情報である。構成情報１７は、例えば、図１６（ｂ）に示すような情報であってもよい。なお、図１では構成情報１７とコンテンツ１８とが個別に格納されている状態を示しているが、構成情報１７は、コンテンツ１８と多重化された状態で格納されていてもよい。

コンテンツ１８は、配信サーバ１が配信するコンテンツである。コンテンツ１８は複数のコンポーネントからなり、所定の分割単位で分割され、ヘッダを付加された伝送パケットとして配信される。なお、コンテンツ１８を構成するコンポーネントとしては、例えば動画像、音声、テキスト、プログラム等が挙げられる。

一方、再生クライアント２は、コンテンツを受信して再生する装置であり、再生クライアント２の機能を統括して制御するクライアント制御部２０、再生クライアント２で使用するデータを格納するクライアント記憶部２１、および再生クライアント２が外部の装置と通信を行うためのクライアント通信部２２を備えている。また、クライアント制御部２０は、再生制御部２３および再生部２４を含み、クライアント記憶部２１には構成情報２５が格納されていると共に、受信データ格納部２６が設けられている。

再生制御部２３は、コンテンツ１８の再生を統括して制御する。具体的には、再生制御部２３は、配信サーバ１が配信する主構成情報および副構成情報を解析し、この解析結果に基づいて、再生部２４にコンテンツ１８を再生させる。また、再生制御部２３は、受信した主構成情報および副構成情報をクライアント記憶部２１に構成情報２５として記録し、コンテンツ１８を再生するときに適宜これを利用する。

再生部２４は、再生制御部２３の制御に従ってコンテンツ１８を再生する。より詳細には、再生部２４は、コンテンツ１８を構成するコンポーネントをその属性に応じた再生態様で再生する。例えば、再生対象のコンポーネントが動画像や音声であればこれを再生し、図示しない表示部および音声出力部から出力する。また、テキストであれば図示しない表示部に表示し、プログラムであればこれを実行する。無論、コンポーネントに応じた再生、表示、実行処理は、それぞれ個別のブロックで実行するようにしてもよい。

《構成情報の例１》
配信サーバ１が生成する構成情報について、図２に基づいて説明する。図２は、記憶している構成情報１７を、主構成情報と２つの副構成情報とに分割して生成した構成情報の一例を示す図である。なお、分割の元となる構成情報１７は、図１６（ｂ）に示した構成情報である。

同図の主構成情報（ｍａｉｎ）では、構成情報のバージョンが"1"であることが記述されている。また、＜components＞タグによって、コンテンツを構成するコンポーネントが＜comp href=" "＞との参照形式で記述されている。さらに、＜compositions＞タグによって、コンポーネントの再生態様が＜par href=" "＞との参照形式で記述されている。

このように、主構成情報は、構成情報１７に含まれる情報の一部を参照形式に書き換えた構成であり、コンテンツの構成全体の概要を表すために用いる。情報の一部を参照形式に書き換えるため、図１６（ｂ）の構成情報と比べて、データ量が大幅に削減されている。

そして、コンテンツを構成するコンポーネントおよびその再生態様が参照形式で記述されているので、コンテンツを構成するコンポーネントおよびその再生態様を変更したい場合に、主構成情報を変更する必要がない。このため、主構成情報の更新が必要となる頻度も、図１６（ｂ）の構成情報と比べて低くなっている。

一方、副構成情報（ｓｕｂ）には、主構成情報からの参照の対象となる具体的な情報（構成情報１７に含まれる情報のうち、主構成情報において参照形式に書き換えられた情報）が含まれている。つまり、主構成情報がコンテンツの構成全体の概要を表すのに対し、副構成情報はコンテンツの一部についての詳細を表すために用いる。

すなわち、同図の副構成情報のうち、バージョンが"1"の副構成情報では、ｃ１からｃ４のコンポーネントを特定する情報が記述されており、これらのコンポーネントに対して、"s1"のidが割り当てられている。すなわち、主構成情報の＜comp href="sub#s1"/＞は、副構成情報におけるid=s1のコンポーネントを参照することを示している。

また、バージョンが"1"の副構成情報では、ビデオコンポーネントであるｃ１とオーディオコンポーネントであるｃ２とを同時に再生することが記述されている。また、テキストコンポーネントであるｃ３およびｃ４は何れかを選択して使用することが可能であることが記述されている。そして、これらの再生態様に対して、"p1"のidが割り当てられている。すなわち、主構成情報の＜par href="sub#p1"/＞は、副構成情報におけるid=p1の再生態様を参照することを示している。

これにより、図１６（ｂ）に示した構成情報を用いた場合と同様に、ｃ１およびｃ２のコンポーネントを同時に再生し、この再生中において、必要に応じてｃ３またはｃ４のコンポーネントを使用することができる。

また、バージョンが"2"の副構成情報（別版参照先構成情報）においても、id=s1のコンポーネントと、id=p1の再生態様とが記述されている。ただし、バージョンが"2"の副構成情報では、バージョンが"1"の副構成情報と記述内容が異なっている。

具体的には、バージョンが"2"の副構成情報では、ｃ５からｃ８のコンポーネントが記述されている。また、ビデオコンポーネントであるｃ５とオーディオコンポーネントであるｃ６とを同時に再生すること、そしてテキストコンポーネントであるｃ７およびｃ８は何れかを選択して使用することが可能であることが記述されている。

これにより、図１６（ｂ）に示した構成情報を用いた場合と同様に、ｃ５およびｃ６のコンポーネントを同時に再生し、この再生中において、必要に応じてｃ７またはｃ８のコンポーネントを使用することができる。

このように、本実施形態では、主構成情報と副構成情報とを参照することによって、従来の構成情報を用いた場合と同様の再生を可能にしている。また、詳細は後述するが、１つの構成情報を、主構成情報と副構成情報とに分割した場合、更新が必要になる頻度の低い主構成情報の配信頻度を下げることができる。これにより、構成情報１７をそのまま配信する場合と比べて、全体として配信データ量を削減することも可能になる。

なお、構成情報１７のうち参照形式とする部分は特に限定されず、例えば＜components＞タグ内のコンポーネントおよび＜compositions＞タグ内の再生態様の何れかを参照形式としてもよい。また、例えば＜components＞タグ内の一部のコンポーネントを参照形式としてもよく、同様に＜compositions＞タグ内の再生態様の一部を参照形式としてもよい。

〈配信態様〉
続いて、上記の主構成情報および副構成情報の配信態様を図３に基づいて説明する。図３は、主構成情報および副構成情報の配信タイミングの一例を示す図である。なお、図３においても、図１６（ａ）と同様、１つのコンポーネント、１つの構成情報を１つのブロックで示し、破線のブロックは使用が任意のコンポーネントを示している。

図３の例においても、コンポーネントの配信タイミングは、図１６（ａ）の例と同様であり、まずｃ１からｃ４のコンポーネントを配信し、その後ｃ５からｃ８のコンポーネントを配信する。より詳細には、再生対象コンテンツの配信開始時刻である時刻ｔ０において、ｃ１からｃ４のコンポーネントの配信を開始する。そして、再生対象コンテンツの構成変更時刻である時刻ｔ３において、ｃ５からｃ８のコンポーネントの配信を開始する。

一方、構成情報の配信態様は、図１６（ａ）の例と異なっている。すなわち、図３の例では、主構成情報（ｍａｉｎ）を、時刻ｔ０、ｔ３、ｔ５に配信しており、この配信頻度は、図１６（ａ）の構成情報（ＣＩ）よりも低くなっている。

また、図３の例では、ｃ１からｃ４のコンポーネントを配信する時刻ｔ０からｔ３の期間には、この期間を再生期間とするコンポーネントに関する情報を含むバージョン１の副構成情報を繰り返し配信する。副構成情報の配信頻度は、主構成情報よりも高い。

同様に、ｃ５からｃ８のコンポーネントを配信する時刻ｔ３からｔ５の期間には、この期間を再生期間とするコンポーネントに関する情報を含むバージョン２の副構成情報を繰り返し配信する。

このようなタイミングでコンポーネント、主構成情報、および副構成情報を配信する場合、再生クライアント２は、主構成情報および副構成情報の両方が取得されたタイミングで、コンポーネントの再生を開始することができる。

例えば、同図の時刻ｔ１に受信を開始した場合、この時刻には２回目に配信されたバージョン１の副構成情報の配信途中であるから、再生クライアント２は次に配信されるバージョン１の副構成情報の受信が完了する時刻ｔ２までは再生待ちの状態となる。

ここで、再生クライアント２が過去（図示されない時刻ｔ０以前）に配信サーバ１からコンテンツを受信していた場合、再生クライアント２が主構成情報を記憶しておくことで、時刻ｔ２において、過去に受信した主構成情報と、時刻ｔ２で受信完了したバージョン１の副構成情報とを用いることにより、時刻ｔ２からコンポーネントｃ１からｃ４の再生を開始することができる。

そして、時刻ｔ３には、コンポーネントｃ５からｃ８およびバージョン２の副構成情報の配信が開始され、時刻ｔ４にはバージョン２の副構成情報の受信が完了するので、時刻ｔ４以降において、コンポーネントｃ５からｃ８の再生も可能になる。

なお、主構成情報および副構成情報は、コンポーネントｃ１、ｃ２の再生を開始させたい時刻に応じたタイミングで配信すればよい。例えば、時刻ｔ０から再生開始させたい場合、時刻ｔ０に受信が完了するようなタイミングで主構成情報および副構成情報を配信すればよい。

一方、時刻ｔ２において、主構成情報を過去に受信していなかった場合、次に配信される主構成情報の受信が完了する時刻ｔ４までは再生待ちの状態となる。そして、時刻ｔ４には、主構成情報および副構成情報の両方が取得された状態となるので、これらの情報に基づいて、コンポーネントｃ１からｃ４の再生を開始することが可能になる。

なお、時刻ｔ４には、バージョン２の副構成情報も取得されているが、バージョン２の副構成情報にはコンポーネントｃ５からｃ８に関する情報が記述されているので（図２参照）、コンポーネントｃ１からｃ４の再生には利用できない。このため、時刻ｔ３までに受信済みとなっている、コンポーネントｃ１からｃ４に関する情報が記述されているバージョン１の副構成情報を参照して再生する。

〈ペイロードレベルでの識別について〉
上記のような主構成情報と、副構成情報とを用いる場合、再生クライアントは、コンテンツを構成する各コンポーネントと共に多重化されて配信される構成情報が主構成情報であるか副構成情報であるかを識別する必要がある。無論、構成情報の内容を解析することにより、主構成情報であるか副構成情報であるかの識別は可能であるが、複数回配信される構成情報を取得する度にその解析を行うことは無駄が多い。

ここで、主構成情報および副構成情報は、コンテンツを構成する各コンポーネントと同様、ペイロード単位で多重化され配信される。このため、ペイロードレベルで主構成情報であるか副構成情報であるかを識別でき、またそのバージョンを識別できるようにすることが望ましい。これにより、これらの識別のために構成情報を解析する必要がなくなるためである。

ここでは、ペイロードのヘッダに構成情報を識別するための情報を記述する例について、図４に基づいて説明する。図４は、主構成情報、副構成情報、および２つのコンポーネントを配信するペイロードのヘッダに構成情報を識別するための情報を記述したデータ構造の一例を示す図である。

図示の例では、主構成情報（ｍａｉｎ）および副構成情報（ｓｕｂ）は分割せずにそれぞれ１つのペイロードに格納し、コンポーネントｃ１およびコンポーネントｃ２は複数の部分に分割してそれぞれ個別のペイロードに格納している。また、主構成情報（ｍａｉｎ）および副構成情報（ｓｕｂ）については、繰り返し配信されるように複数のペイロードに繰り返し格納されている。

そして、主構成情報のペイロードヘッダには、”Payload Type=CI”の形式でペイロードの内容が構成情報であることが記述されていると共に、"ID=main"の形式で当該ペイロードに主構成情報が格納されていることが示されている。また、"Ver=（バージョン番号）"の形式で当該主構成情報のバージョンが記述されている。

同様に、副構成情報のペイロードヘッダには、”Payload Type=CI”の形式でペイロードの内容が構成情報であることが記述されていると共に、"ID=sub"の形式で当該ペイロードに副構成情報が格納されていることが示されている。また、"Ver=（バージョン番号）"の形式で当該副構成情報のバージョンが記述されている。

再生クライアント２は、ペイロードヘッダに記述されたこれらの情報を参照することによって、ペイロード内のデータを解析することなく、そのペイロードに格納されているのが主構成情報、副構成情報の何れの構成情報であるかを識別することができる。これにより、主構成情報または副構成情報の受信待ち状態において、受信待ちの構成情報を受信したことをスムーズに特定することができる。

また、ペイロードヘッダを参照するだけで、受信した構成情報のバージョンを識別することができ、これにより過去に受信していないバージョンの構成情報を受信したことをスムーズに特定することができる。

なお、主構成情報および副構成情報を識別するための情報は、ペイロードヘッダのみの参照によって主構成情報または副構成情報の識別子が特定できる情報でなくともよい。構成情報は、主構成情報、副構成情報に分類されるので、例えば、ペイロードヘッダには、主構成情報であるか否かを示す１ビットのフラグを記述するのみであってもよく、ペイロードヘッダに記述する情報量を削減することができる。なお、この場合必要に応じて各構成情報の識別子は、例えば構成情報の内部に<ci id=“sub”>…</ci>のような形式で記述してもよい。

また、ペイロードレベルでのバージョン管理は、変更有無を示す１ビットのフラグとし、実際のバージョン番号は構成情報を解析して特定してもよい。この場合、当該ビットで変更が示されたとき、受信開始時、および受信エラーからの回復直後には、実際にペイロード内の構成情報を解析して更新内容を確認する。

《構成情報の例２》
上記では、１つの構成情報を１つの主構成情報と１つの副構成情報とに分割し、副構成情報を複数バージョン生成する例を示したが、副構成情報をコンポーネントに応じてさらに分割してもよい。これにより、伝送データ量をさらに削減することが可能になる。

ここでは、副構成情報をコンポーネントに応じてさらに分割した構成情報について、図５に基づいて説明する。図５は、構成情報１７を、主構成情報と４つの副構成情報とに分割して生成した構成情報の一例を示す図である。なお、分割の元となる構成情報１７は、図１６（ｂ）に示した構成情報である。

図５の主構成情報の＜components＞タグにおいても、図２の例と同様に、コンテンツ１８を構成するコンポーネントが参照形式で記述されているが、参照されているコンポーネントが"sub1#s1"と"sub2#s2"の２つになっている点で図２の例と異なっている。この"sub1"が第１の副構成情報（参照先構成情報）であり、"sub2"が第２の副構成情報（副参照先構成情報）である。

また、図５の主構成情報の＜compositions＞タグにおいては、コンポーネントの再生態様が引用形式で記述されている。具体的には、再生態様として"sub1#p1"が引用形式で記述されていると共に、任意選択のコンポーネントを使用する場合の参照先が"sub2#e2"と記述されている。

そして、同図では、第１の副構成情報（ｓｕｂ１）および第２の副構成情報（ｓｕｂ２）のそれぞれについて、２つのバージョン（１と２）を図示している。

具体的には、第１の副構成情報（バージョン１）では、ｃ１およびｃ２のコンポーネントが記述されており、これらのコンポーネントに対して"s1"のidが割り当てられている。また、ビデオコンポーネントであるｃ１とオーディオコンポーネントであるｃ２とを同時に再生することが記述されており、この再生態様に対して"p1"のidが割り当てられている。

また、第２の副構成情報（バージョン１）では、ｃ３およびｃ４のコンポーネントが記述されており、これらのコンポーネントに対して"s2"のidが割り当てられている。また、テキストコンポーネントであるｃ３、ｃ４の何れか一方を使用することが記述されており、この使用態様に対して"e2"のidが割り当てられている。

したがって、主構成情報、第１の副構成情報（バージョン１）、および第２の副構成情報（バージョン１）を参照することにより、図１６（ｂ）に示した構成情報を用いた場合と同様の再生が可能になる。

すなわち、主構成情報の＜components＞タグの記述、第１の副構成情報（バージョン１）のid=s1の記述、および第２の副構成情報（バージョン１）のid=s2の記述を参照することによって、再生対象がｃ１からｃ４の４つのコンポーネントであることを特定することができる。

そして、主構成情報の＜compositions＞タグの記述、第１の副構成情報（バージョン１）のid=p1の記述、および第２の副構成情報（バージョン１）のid=e2の記述を参照することによって、ｃ１およびｃ２のコンポーネントを同時に再生し、この再生中において、必要に応じてｃ３またはｃ４のコンポーネントを使用することができる。無論、再生が任意のコンポーネントに関する第２の副構成情報は取得しなくとも、第１の副構成情報を取得すれば、ｃ１およびｃ２のコンポーネントを再生することができる。

同様に、第１の副構成情報（バージョン２）には、ｃ５およびｃ６のコンポーネントが記述されており、これらのコンポーネントに対して"s1"のidが割り当てられている。また、ビデオコンポーネントであるｃ５とオーディオコンポーネントであるｃ６とを同時に再生することが記述されており、この再生態様に対して"p1"のidが割り当てられている。

そして、第２の副構成情報（バージョン２）では、ｃ７およびｃ８のコンポーネントが記述されており、これらのコンポーネントに対して"s2"のidが割り当てられている。また、テキストコンポーネントであるｃ７、ｃ８の何れか一方を使用することが記述されており、この使用態様に対して"e2"のidが割り当てられている。

したがって、バージョン２の第１および第２の副構成情報を参照する場合には、再生対象がｃ５からｃ８の４つのコンポーネントであることが特定される。また、ｃ５およびｃ６のコンポーネントを同時に再生し、この再生中において、必要に応じてｃ７またはｃ８のコンポーネントを使用することができる。無論、再生が任意のコンポーネントに関する第２の副構成情報は取得しなくとも、第１の副構成情報を取得すれば、ｃ１およびｃ２のコンポーネントを再生することができる。

このように、再生が必須のコンポーネント（ｃ１、ｃ２、ｃ５、ｃ６）と、使用が任意のコンポーネント（ｃ３、ｃ４、ｃ７、ｃ８）とを、別の副構成情報に記述した場合、更新の頻度を下げても問題の少ない第２の副構成情報の配信頻度を下げることによって、全体として配信データ量を削減することも可能になる。

〈配信態様〉
続いて、上記の主構成情報および副構成情報の配信態様を図６に基づいて説明する。図６は、主構成情報および４つの副構成情報の配信タイミングの一例を示す図である。なお、図６においても、図１６（ａ）および図３と同様、１つのコンポーネント、１つの構成情報を１つのブロックで示し、破線のブロックは使用が任意のコンポーネントを示している。

図６の例においても、コンポーネントの配信タイミングは、図３の例と同様であり、時刻ｔ０にｃ１からｃ４のコンポーネントの配信を開始し、時刻ｔ３にｃ５からｃ８のコンポーネントの配信を開始する。また、主構成情報の配信タイミングも、図３の例と同じである。

一方、副構成情報の配信態様は、図３の例と異なっている。すなわち、図６の例では、第１の副構成情報（ｓｕｂ１）および第２の副構成情報（ｓｕｂ２）の２種類の副構成情報を配信している。なお、時刻ｔ０からｔ３の期間に配信される副構成情報は、何れもバージョンが１であり、時刻ｔ３からｔ５の期間に配信される副構成情報は、何れもバージョンが２である。

そして、第１の副構成情報の配信頻度は、図３の副構成情報と同様であるが、第２の副構成情報の配信頻度は、第１の副構成情報よりも低くしている。これにより、図３の例よりも配信する副構成情報のデータ量が削減されている。

このような主構成情報および４つの副構成情報を参照して再生を行う場合、再生クライアント２における処理は、例えば以下のようになる。

すなわち、時刻ｔ１に受信を開始した場合、この時刻には２回目に配信されたバージョン１の第１の副構成情報の配信途中であるから、再生クライアントは次に配信されるバージョン１の第１の副構成情報の受信が完了する時刻ｔ２までは再生待ちの状態となる。

ここで、時刻ｔ２において、主構成情報を過去に受信していた場合、過去に受信した主構成情報と、時刻ｔ２で受信完了したバージョン１の第１の副構成情報とを用いることにより、時刻ｔ２からコンポーネントｃ１およびｃ２の再生を開始することができる。

また、この場合、時刻ｔ６で受信完了したバージョン１の第２の副構成情報を用いることにより、時刻ｔ６からコンポーネントｃ３およびｃ４の使用を開始することができる。コンポーネントｃ３およびｃ４は、使用が必須ではない字幕のテキストであるから、この例における程度の遅延（ｔ２からｔ６）であれば、多くのユーザが許容すると考えられる。

そして、時刻ｔ３には、バージョン２の第１および第２の副構成情報の配信が開始され、時刻ｔ４にはこれらの受信が完了するので、時刻ｔ４以降において、コンポーネントｃ５からｃ８の再生も可能になる。

一方、時刻ｔ２において、主構成情報を過去に受信していなかった場合、次に配信される主構成情報の受信が完了する時刻ｔ４までは再生待ちの状態となる。そして、時刻ｔ４には、主構成情報、第１および第２の副構成情報の全てが取得された状態となるので、これらの情報に基づいて、コンポーネントｃ１からｃ４の再生を開始することが可能になる。

以上のように、図６の例では、コンポーネント毎の重要度の高さ（即時表示が求められるか否か、または再生が必須か否か）でコンポーネントを分類し、各分類に応じた副構成情報を生成している。そして、これら副構成情報のうち、相対的に重要度の高い副構成情報の配信頻度を高く、相対的に重要度の低い副構成情報の配信頻度を低くしている。

具体的には、再生が必須であり即時再生の必要性の高いＡＶコンポーネント（ビデオコンポーネントおよびオーディオコンポーネント）を再生するための第１の副構成情報については高頻度で配信している。一方、使用が任意であり、即時再生の必要性が相対的に低い字幕等のテキストコンポーネントを使用するための第２の副構成情報については、低頻度で配信している。

これにより、第１の副構成情報の受信待ちによるＡＶコンポーネントの再生開始遅延を最小限に抑えつつ、構成情報全体としての配信データ量を削減することができる。

なお、コンポーネントの配信方法に応じて、そのコンポーネントを再生するための構成情報の配信頻度を変えてもよい。例えば、現行のデジタル放送で用いられているデータ放送のように、コンポーネント自体がカルーセルで繰り返し送信される場合、その配信頻度に合わせて当該コンポーネントに関する構成情報を送信してもよい。

《構成情報の例３》
上記では、再生態様を示す情報として、同時に再生するコンポーネントの組み合わせを示す情報を副構成情報に記述した例を示したが、レイアウトを示す情報を記述してもよい。

ここでは、レイアウトを示す情報を記述した副構成情報を用いる例を図７および図８に基づいて説明する。図７は、コンポーネントのレイアウトの一例を示す図であり、図８は、図７のレイアウトでコンポーネントを再生させるための構成情報の一例を示す図である。

図７の例では、"layout1"から"layout3"までの３通りのレイアウトがユーザ選択の対象となっている。コンポーネントを再生するユーザは、これらのレイアウトから所望のものを選択し、再生クライアント２は、選択されたレイアウトに従ってコンポーネントを表示する。

具体的には、layout1を選択した場合、まず、デフォルトの画面レイアウトが適用される。デフォルトの画面レイアウトは、ｖ１（ビデオコンポーネント）を全画面表示し、ｖ２（ビデオコンポーネント）を小画面表示すると共に、ａ１（オーディオコンポーネント）を再生するというものである。

この後、所定の時間が経過したタイミングでレイアウトが自動で変更される。変更後のレイアウトは、ｖ２を全画面表示し、ｖ１を小画面表示すると共に、ａ１を再生するというものである。そして、さらに所定の時間が経過したタイミングで、レイアウトが自動でデフォルトに戻される。

一方、layout2またはlayout3が選択された場合には、上記のようなレイアウトの自動変更は行われず、選択されたレイアウトが維持される。すなわち、layout2が選択された場合には、ｖ１を全画面表示し、ｖ２を小画面表示すると共に、ａ１を再生する。また、layout3が選択された場合には、ｖ２を全画面表示し、ｖ１を小画面表示すると共に、ａ１を再生する。

このようなレイアウトでの表示は、図８の構成情報によって実現可能である。図８の構成情報は、主構成情報と、第１の副構成情報と、第２の副構成情報とを含み、第２の副構成情報にはバージョン１から３までの３つのバージョンが含まれている。

同図の主構成情報では、＜components＞タグによって、"sub1#s1"のコンポーネント属性が参照されている。また、＜layouts＞タグによって、全画面表示に対応する"reg_1"と、小画面表示に対応する"reg_2"とが定義されている。

そして、＜compositions＞タグによって、外部参照の"sub2#layout1"、"layout2"、および"layout3"の何れかのレイアウトで再生することが記述されている。また、これらのレイアウトの具体的内容がそれぞれ記述されている。

一方、第１の副構成情報では、"ｖ１"、"ｖ２"、および"ａ１"のコンポーネントが記述されており、これらのコンポーネントに対して、"s1"のidが割り当てられている。

また、第２の副構成情報のバージョン１では、reg_1にビデオコンポーネントｖ１を表示し、reg_2にビデオコンポーネントｖ２を表示すると共に、オーディオコンポーネントａ１を再生するというレイアウトが記述されている。そして、このレイアウトに対して、"layout1"のidが割り当てられている。

同様に、第２の副構成情報のバージョン２では、reg_2にビデオコンポーネントｖ１を表示し、reg_1にビデオコンポーネントｖ２を表示すると共に、オーディオコンポーネントａ１を再生するというレイアウトが記述されている。そして、このレイアウトに対して、"layout1"のidが割り当てられている。

また、第２の副構成情報のバージョン３では、バージョン１と同様に、reg_1にビデオコンポーネントｖ１を表示し、reg_2にビデオコンポーネントｖ２を表示すると共に、オーディオコンポーネントａ１を再生するというレイアウトが記述されている。そして、このレイアウトに対して、"layout1"のidが割り当てられている。

以上の構成情報を用いる場合、主構成情報と、第１の副構成情報とを取得することにより、ｖ１、ｖ２、ａ１のコンポーネントが再生可能となる。また、ユーザに任意のタイミングでlayout1からlayout3の何れかを選択させ、選択されたレイアウトに従ってコンポーネントを再生することも可能になる。つまり、第２の副構成情報を受信していない場合であっても、主構成情報に記述されたレイアウトに従って再生することが可能である。

そして、layout1が選択された場合、このレイアウトを変更するタイミングで第２の副構成情報のバージョン２を取得することによって、図７に示したように、レイアウトを自動で（ユーザ操作なしで）変更することができる。主構成情報の"sub2#layout1"で参照される情報が、バージョン２の第２の副構成情報に変わるためである。このレイアウトを自動で元に戻すときも同様であり、レイアウトを変更するタイミングで第２の副構成情報のバージョン３を取得すればよい。

〈配信態様〉
続いて、上記の主構成情報および副構成情報の配信態様を図９に基づいて説明する。図９は、主構成情報および副構成情報の配信タイミングの一例を示す図である。なお、図９においても、図３および図６と同様、１つのコンポーネント、１つの構成情報を１つのブロックで示している。

図９の例では、再生対象コンテンツの配信開始時刻である時刻ｔ０において、コンポーネントａ１、ｖ２、ｖ１が配信開始されている。また、時刻ｔ０には、主構成情報、バージョン１の第１の副構成情報、およびバージョン１の第２の副構成情報が配信開始されている。

なお、主構成情報の配信タイミングは、図３、図６の例と同様であり、対応するコンポーネントの配信開始時に１回のみ配信している。また、第１の副構成情報の配信タイミングは、図６の例と同様であり、コンポーネントが配信されている期間中、所定の周期で繰り返し配信している。一方、第２の副構成情報については、バージョンが異なるものを１回ずつ配信している。

ここで、同図の例では、時刻ｔ１において、バージョン２の第２の副構成情報が配信完了している。これにより、再生クライアント２は、バージョン２の第２の副構成情報を参照することによって、コンポーネントの表示レイアウトを自動的にバージョン２の第２の副構成情報に基づくものに切り替えることができる。

同様に、同図の例では、時刻ｔ２において、バージョン３の第２の副構成情報が配信完了している。これにより、再生クライアント２は、バージョン３の第２の副構成情報を参照することによって、コンポーネントの表示レイアウトを自動的にバージョン３の第２の副構成情報に基づくものに切り替えることができる。

《オンデマンド配信の併用》
構成情報をオンデマンド配信することが可能であれば、オンデマンド配信を併用することによって、構成情報の伝送効率をさらに高めることができる。ここでは、構成情報をオンデマンド配信する例を図１０に基づいて説明する。

図１０は、構成情報をオンデマンド配信する例を説明する図であり、同図（ａ）は構成情報の配信タイミングの一例を示し、同図（ｂ）は構成情報のデータ例を示している。なお、同図（ａ）においても、図１６（ａ）、図３、図６の例と同様、１つのコンポーネント、１つの構成情報を１つのブロックで示し、破線のブロックは使用が任意のコンポーネントを示している。また、配信対象となるコンポーネントも図１６（ａ）、図３、図６の例と同様である。

図１０（ａ）の例では、ｃ１からｃ４のコンポーネントの配信開始時刻に、これらのコンポーネントと共に、主構成情報と副構成情報とをprotocolAというプロトコルにて配信している。そして、このｃ１からｃ４のコンポーネントの配信期間においては、バージョン１の副構成情報をＨＴＴＰによってオンデマンドで取得することも可能となっている。

同様に、ｃ５からｃ８のコンポーネントの配信開始時刻に、これらのコンポーネントと主構成情報と副構成情報とを多重化し、protocolAというプロトコルにて配信している。そして、このｃ５からｃ８のコンポーネントの配信期間においては、バージョン２の副構成情報をＨＴＴＰによってオンデマンドで取得することも可能となっている。

このようなオンデマンドによる取得を可能にするためには、例えば同図（ｂ）に示すような構成情報を使用すればよい。同図（ｂ）の構成情報は、主構成情報と、バージョン１の副構成情報と、バージョン２の副構成情報とを含んでいる。なお、副構成情報（バージョン１および２）は、図２の例と同じであるから、ここでは説明を省略する。

図１０（ｂ）の主構成情報には、ベースＵＲＬの形式で２つのパス（"protocolA://.../"および"http://.../"）が記述されている。また、＜component＞タグ内では、"sub#s1"が参照されており、＜compositions＞タグ内では、"sub#p1"が参照されている。

再生クライアント２は、これらの情報を参照することによって、参照先の構成情報をprotocolAまたはＨＴＴＰにより取得することができる。つまり、副構成情報は、protocolAで配信されているため、"protocolA://.../"とのベースＵＲＬに副構成情報を示す"sub#s1"（あるいは"sub#p1"）を組み合せたＵＲＬによって取得することができる。また、ＨＴＴＰを利用する場合、"http://.../" とのベースＵＲＬに副構成情報を示す"sub#s1"（あるいは"sub#p1"）を組み合せたＵＲＬによって取得することができる。

なお、protocolAは、構成情報を配信することのできるプロトコルであればよく、特に限定されない。また、図４を用いて説明した通り、構成情報は他のコンポーネントと共に多重化されて配信することが可能であり、例えば、デジタル放送用にＡＶコンポーネントを配信するためにＡＲＩＢ（Association of Radio Industries and Business）で規定されたプロトコルや、ＤＶＢ（Digital Video Broadcasting）で規定されたプロトコルが利用可能である。

〈外部参照ＵＲＬの記述形式について〉
構成情報の配信形態が複数（ライブ配信およびオンデマンド配信）存在する場合、配信形態に応じて、当該構成情報の参照するためのＵＲＬが複数必要となるため、ＵＲＬ記述の情報量が問題となる。そこで当該システムでは「伝送プロトコル://伝送されるリソー
ス識別子/コンポーネント識別子#コンポーネント内要素識別子」の形式のＵＲＬ記述を用いる。従って配信形態（ライブ配信およびオンデマンド配信）毎に異なる部分のみをベースＵＲＬの形式をそれぞれ記述し、配信形態に依存しない部分（例えば「コンポーネント識別子#コンポーネント内要素識別子」）のみからなる相対ＵＲＬをhref属性に記述することでＵＲＬ記述の情報量を削減している。

ここで、相対ＵＲＬを用いたＵＲＬ記述の情報量削減について、図１１に基づいて補足する。図１１は、構成情報において外部の情報を参照するためのＵＲＬの記述例を示す図であり、同図（ａ）はベースＵＲＬを省略した例、同図（ｂ）は上位ノードに設定されたＵＲＬをベースＵＲＬとして利用する例、同図（ｃ）はベースＵＲＬ形式でベースＵＲＬを指定する例を示している。

ただし、相対ＵＲＬ形式で参照される参照先から情報を取得するためには、当該コンポーネントの伝送プロトコル、伝送リソース識別子を補う必要がある。

例えば、図１１（ａ）の例では、コンポーネントｃ１において、相対ＵＲＬ形式で"sub#s1"が参照されているが、ベースＵＲＬ（伝送プロトコル、伝送されるリソース識別子）は記述されていない。

このような場合、コンポーネントｃ１のベースＵＲＬは、当該構成情報が伝送されている多重化ストリームであると判断して、当該多重化ストリームに含まれる情報の中から"sub#s1"で特定される情報を参照する。

これに対し、同図（ｂ）の例では、ｃ１に、相対ＵＲＬとして、コンポーネント内要素識別子のみが設定されている。またｃ１が属する親ノードには、href属性"protocolA://.../sub"が設定されている。したがって、これらの情報を組み合せることによって、ｃ１を外部参照するためのＵＲＬ、"protocolA://.../sub#s1"が得られる。つまり、この例では、"protocolA://.../sub"がベースＵＲＬとして機能している。

また、同図（ｃ）の例では、図１０（ｂ）の例と同様に、相対ＵＲＬ記述が用いられたｃ１の上位ノードに"protocolA://.../"および"http://.../"の２つのベースＵＲＬが記述されている。この例では、"protocolA://.../"と"sub#s1"とを組み合せることによって、protocolAで伝送される副構成情報の"s1"部分を参照することができる。また、"http://.../"と"sub#s1"とを組み合せることによって、ＨＴＴＰによって副構成情報の"s1"部分を参照することができる。このように、ベースＵＲＬを用いた記述とすることによって、各プロトコルにおける共通部分である"sub#s1"の記述が重複することがないため、構成情報全体のデータ量を減らすことができる。

なお、上述の説明では、構成情報を外部参照するためのＵＲＬ記述についてのみ説明したが、構成情報から参照される各コンポーネントを参照するＵＲＬ記述についても同様の記述方法を用いても構わない。

《構成情報の例４》
上記では、主構成情報および副構成情報の伝送路については特に言及しなかったが、配信サーバ１と再生クライアント２を繋ぐネットワークが、ハイブリッドネットワークの場合等、配信サーバ１から再生クライアント２までのコンテンツの伝送路が複数存在する場合、これらを異なる伝送路で配信してもよい。これについて、図１２に基づいて説明する。図１２は、主構成情報と副構成情報とを別個の伝送路で配信する例を説明する図であり、同図（ａ）は構成情報の配信タイミングの一例を示し、同図（ｂ）は構成情報のデータ例を示している。なお、同図（ａ）においても、図１６（ａ）、図３、図６の例と同様、１つのコンポーネント、１つの構成情報を１つのブロックで示し、破線のブロックは使用が任意のコンポーネントを示している。また、配信対象となるコンポーネントも図１６（ａ）、図３、図６、図１０の例と同様である。

図１２（ａ）の例では、再生が必須のコンポーネントｃ１、ｃ２、ｃ５、およびｃ６は伝送路Ａで配信しており、この伝送路Ａにて主構成情報も配信している。また、使用が任意のコンポーネントｃ３、ｃ４、ｃ７、およびｃ８は、伝送路Ａとは異なる伝送路Ｂで配信しており、この伝送路Ｂでは副構成情報も配信している。この例では、主構成情報の配信は必須となっているが、副構成情報の配信は任意となっている。

このような態様で配信する主構成情報および副構成情報は、例えば同図（ｂ）に示すものとすればよい。同図（ｂ）の主構成情報では、＜components＞タグにおいて、伝送路Ａで配信されるコンポーネントｃ１、ｃ２、ｃ５、ｃ６が記述されていると共に、外部参照用のＵＲＬ（取得先情報）として"protocolA://.../sub#s1"が記述されている。

また、＜compositions＞タグにおいては、ビデオコンポーネントｃ１とオーディオコンポーネントｃ２とを同時に再生すると共に、"protocolA://.../sub#e1"に示されるコンポーネントの何れかを使用可能であることが記述されている。同様に、ビデオコンポーネントｃ５とオーディオコンポーネントｃ６とを同時に再生すると共に、"protocolA://.../sub#e2"に示されるコンポーネントの何れかを使用可能であることが記述されている。

一方、副構成情報では、使用が任意のコンポーネントｃ３、ｃ４、ｃ７、ｃ８が記述されており、これらのコンポーネントに対してs1のidが割り当てられている。また、使用が任意のコンポーネントを使用する場合には、テキストコンポーネントｃ３またはｃ４を使用するという再生態様が記述されており、この再生態様に対してe1のidが割り当てられている。同様に、使用が任意のコンポーネントを使用する場合には、テキストコンポーネントｃ７またはｃ８を使用するという再生態様が記述されており、この再生態様に対してe2のidが割り当てられている。

このように、図１２（ｂ）の主構成情報は、伝送路Ａで配信されるコンポーネントに関する情報を含み、伝送路Ｂで配信されるコンポーネントについては参照形式で記述されている。そして、主構成情報は、伝送路Ａにおいて所定の時間間隔で繰り返し配信される。

一方、図１２（ｂ）の副構成情報は、伝送路Ｂで配信されるコンポーネントに関する情報を含んでいる。そして、副構成情報は、伝送路Ｂにおいて所定の時間間隔で繰り返し配信される。

したがって、再生クライアントは、伝送路Ａで配信されるコンポーネントを、同じく伝送路Ａで配信される主構成情報を参照することによって再生することができる。また、伝送路Ｂで配信されるコンポーネントについては、伝送路Ｂで配信される副構成情報を参照することによって、これを使用することが可能になる。

このように、複数の伝送路でコンポーネントが配信される場合、ある伝送路で配信するコンポーネントに関する情報を含む構成情報と、他の伝送路で配信するコンポーネントに関する情報を含む構成情報とを分割することが好ましい。これにより、コンポーネント１つ当たりのデータ量を削減することができるからである。

なお、図１２（ａ）（ｂ）には、再生時間帯の異なるコンポーネント（ｃ１〜ｃ４とｃ５〜ｃ８）に関する情報を全て含む主構成情報および副構成情報を例示しているが、図２、図３の例のように、再生時間帯毎に分割してもよい。これにより、各構成情報のデータ量をさらに削減することができる。

また、図１２（ｂ）の主構成情報では、外部参照用ＵＲＬ（"protocolA://.../..."）が記述されている。つまり、この例では、伝送路ＢにおいてはprotocolAによってコンポーネントｃ３、ｃ４、ｃ７、ｃ８、および副構成情報が配信されることを想定している。したがって、このＵＲＬを参照することによって、伝送路Ｂのデータストリーム中から副構成情報の所望の部分を参照することができる。

《構成情報の例５》
複数の異なるコンテンツ１８があり、これに対応する構成情報１７がそれぞれ存在する場合、各構成情報１７に含まれる情報の一部が共通していることが考えられる。このような場合、共通部分を１つの副構成情報とすることによって、各構成情報１７を個別に配信する場合と比べて伝送データ量を削減することが可能になる。

ここでは、複数の構成情報の共通部分を１つの副構成情報とする例について、図１３に基づいて説明する。図１３は、２種類の再生装置にそれぞれ対応する２つの主構成情報、およびこれら再生装置で共用される副構成情報のデータ例を示す図である。

同図には、第１の主構成情報（ｍａｉｎ１）、副構成情報、および第２の主構成情報（ｍａｉｎ２）が示されている。このうち、第１の主構成情報は、テレビ向けの主構成情報であり、第２の主構成情報は、モバイル機器向けの主構成情報である。そして、副構成情報は、テレビおよびモバイル機器共通のコンポーネント（ここでは現行の地上デジタル放送におけるデータ放送のようなテキストおよび画像コンポーネントを想定）に対応する構成情報である。

すなわち、ここでは、再生装置であるテレビは、第１の主構成情報および副構成情報を参照して、例えば地上デジタル放送のような高解像度のＡＶコンテンツを再生し、またデータ放送を表示する。

また、再生装置であるモバイル機器は、第２の主構成情報および副構成情報を参照して、例えば現行のワンセグ放送のような低解像度のＡＶコンテンツを再生すると共に、テレビと共通のコンポーネント（データ放送に相当）を表示する。ただし、モバイル機器はディスプレイの解像度が低いため、表示させるテキストコンポーネントはテレビと共通のものを用いるが、テキストの背景に表示させる背景画像はテレビ向けのものと異なる画像コンポーネントを用いるものとする。

このような再生を実現するため、同図の第１の主構成情報では、＜components＞タグにおいて、idがそれぞれｃ１、ｃ２のコンポーネントが記述されている。また、コンポーネントが"protocolA://.../sub#s1"の記述によって外部参照されている。

また、＜compositions＞タグでは、ビデオコンポーネントであるｃ１と、オーディオコンポーネントであるｃ２とを同時に再生すること、およびこの再生中に"protocolA://.../sub#p1"の使用が可能であることが記述されている。

一方、同図の第２の主構成情報では、＜components＞タグにおいて、idがそれぞれｃ３、ｃ４のコンポーネントが記述されている。このように、第２の主構成情報では、対象とするコンポーネントが第１の主構成情報と異なっている。また、コンポーネントが"protocolA://.../sub#s1"の記述によって外部参照されており、この記述は第１の主構成情報と同じである。つまり、第１の主構成情報と第２の主構成情報とは、外部参照先が同じ副構成情報の"s1"部分である。

また、＜compositions＞タグでは、ビデオコンポーネントであるｃ３と、オーディオコンポーネントであるｃ４とを同時に再生すること、およびこの再生中に"protocolA://.../sub#p2"の使用が可能であることが記述されている。ここでは、外部参照先は"sub"すなわち同図の副構成情報であって、第１の主構成情報と同じであるが、参照する要素がp2に変わっている。

そして、同図の副構成情報は、ｃ５、ｃ６、およびｃ７のコンポーネントが記述されており、これらのコンポーネントに対して"s1"のidが割り当てられている。上述のように、第１および第２の主構成情報の＜components＞タグでは、何れも"protocolA://.../sub#s1"の記述によって、副構成情報のs1が参照されている。

このため、これらのコンポーネントは、第１の主構成情報を使用するテレビにおいても、第２の主構成情報を使用するモバイル機器においても使用可能なコンポーネントとなる。

また、副構成情報の＜par＞タグにおいては、任意選択のコンポーネントを使用する場合に、テキストコンポーネントであるｃ５と、画像コンポーネントであるｃ６とを同時に表示する再生態様に対して、"p1"のidが割り当てられている。同様に、任意選択のコンポーネントを使用する場合に、テキストコンポーネントであるｃ５と、画像コンポーネントであるｃ７とを同時に表示する再生態様に対して、"p2"のidが割り当てられている。

したがって、第１の主構成情報および副構成情報を参照するテレビは、コンポーネントｃ１、ｃ２（例えば地上デジタル放送の映像と音声に相当）を再生する。そして、これらの再生中において、例えば所定のユーザ操作があった場合には、任意再生のコンポーネントであるｃ５、ｃ６（例えばデータ放送のテキストと、テレビ用背景画像に相当）を表示することができる。

また、第２の主構成情報および副構成情報を参照するモバイル機器は、コンポーネントｃ３、ｃ４（例えばワンセグ放送の映像と音声に相当）を再生する。そして、これらの再生中において、例えば所定のユーザ操作があった場合には、任意再生のコンポーネントであるｃ５、ｃ７（例えばデータ放送のテキストと、モバイル用背景画像に相当）を表示することができる。

《構成情報に関するその他の付記事項》
１つの主構成情報内において、１つの副構成情報の外部参照用ＵＲＬが複数箇所に記述されるケースがある。例えば、主構成情報および副構成情報に基づいて再生クライアント２がコンテンツの再生中に同じＣＭを何度も再生する、以下のようなケースが考えられる。
・コンテンツを構成するコンポーネントの中にＣＭ映像を表すＣＭ映像コンポーネントおよびＣＭ音声を表すＣＭ音声コンポーネントが含まれている。そして、副構成情報には、２つのＣＭコンポーネントの各々について対応するcompタグが含まれており、さらに、再生クライアントに２つのＣＭコンポーネントを並行して再生させるためのpar要素が含まれている。また、主構成情報にはseq要素が記述されており、seq開始タグとseq終了タグとの間の複数箇所に、副構成要素のpar要素を参照する外部参照用ＵＲＬが記述されている。

seq要素は、par要素およびexcl要素と同様に、compositions要素の内容として記述されるものである。seq要素は、開始タグと終了タグとで囲まれている各タグ（videoタグ、audioタグ等）について、より上側に記述されているタグに対応するコンポーネントを相対
的に先に再生することを示している。なお、par要素は、開始タグと終了タグとで囲まれている各タグに対応するコンポーネント群を並列的に再生すべきことを示しており、excl要素は、開始タグと終了タグとで囲まれている各タグに対応するコンポーネント群を排他的に再生すべきことを示している。

このケースでは、本来、２つのＣＭコンポーネントを示すcompタグおよびそれらを並列に再生させるためのpar要素が、複数の副構成情報それぞれについて記述されていたところを、１つの副構成情報と複数の外部参照用ＵＲＬとで記述されることになる。このため、配信サーバ１が再生クライアント２に送信する構成情報のデータ量を従来に比べて一層削減することができる。

《配信処理》
続いて、配信サーバ１がコンテンツ１８の配信の際に実行する配信処理（配信方法）の流れを図１４に基づいて説明する。図１４は、配信処理の一例を示すフローチャートである。なお、ここではまず、図２の構成情報を図３の配信タイミングで配信する例について説明し、他の構成情報を用いる場合の処理についてはその後で説明する。

配信対象のコンテンツが決定すると、コンポーネント変換部１３は、サーバ記憶部１１から配信対象のコンテンツ１８を読み出して、配信用のコンポーネントに変換し（Ｓ１）、配信制御部１６に出力する。

なお、配信対象コンテンツの決定方法は特に限定されず、例えば所定の時刻に所定のコンテンツを配信することが決まっている場合には、時刻に応じたコンテンツを配信対象とすればよい。また、例えば配信サーバ１に対するユーザ操作で指定されたコンテンツを配信対象としてもよい。

また、配信対象のコンテンツが決定すると、構成情報解析部１４は、配信対象のコンテンツ１８に対応する構成情報１７をサーバ記憶部１１から読み出す（Ｓ２）。そして、構成情報１７を解析して、主構成情報とする情報を決定する（Ｓ３）と共に、副構成情報とする情報を決定する（Ｓ４）。そして、構成情報解析部１４は、構成情報１７に含まれる情報のうち、副構成情報に記述することを決定した情報を構成情報生成部１５に通知する。

具体的には、構成情報解析部１４は、構成情報１７に含まれる情報のうち、＜components＞タグに記述されているコンポーネントを示す情報と、＜compositions＞タグに記述されている再生態様を示す情報とを副構成情報とすることを決定する。そして、これら以外の情報を主構成情報とすることを決定する。

次に、構成情報生成部１５は、構成情報解析部１４からの上記通知に従って主構成情報および副構成情報を生成する（Ｓ５、構成情報生成ステップ）。

具体的には、構成情報生成部１５は、構成情報１７に記述されている情報のうち、副構成情報に記述することが決定された情報を、当該副構成情報を参照する形式に書き換えて、主構成情報を生成する。また、副構成情報に記述することが決定された情報については、主構成情報から参照されるように割り当てた識別情報（id）と共に副構成情報に記述する。

また、副構成情報に記述することが決定された情報について、構成情報１７を配信時刻順に解析し、内容に変更が生じる度に新たなバージョンの副構成情報として記述する。なお、変更内容が、副構成情報に記述することが決定された情報の一部であった場合でも、副構成情報に記述することが決定された情報全てを記述した副構成情報を生成する構成が望ましい。そのような構成とすることで、一時的なネットワーク障害等の理由で一部の副構成情報が再生クライアント２に配信されなかった場合においても、障害解消後に受信した副構成情報によって、正常な再生を継続することが可能である。

以上のような処理により、図１６（ｂ）に示す構成情報から、図２に示すような主構成情報と、バージョン１および２の副構成情報とが生成される。そして、構成情報生成部１５は、生成した主構成情報と副構成情報とを配信制御部１６に出力する。

次に、配信制御部１６は、コンポーネント変換部１３が生成したコンポーネントと、構成情報生成部１５が生成した主構成情報および副構成情報との配信スケジュールを決定する（Ｓ６）。

具体的には、配信制御部１６は、主構成情報の一回目の配信タイミングを、最初に再生されるコンポーネントの再生開始時刻と同じかそれ以前に決定する。そして、以後の主構成情報の配信タイミングを、一回目の配信タイミングから所定時間後、あるいは再生されるコンポーネントの構成が変化するタイミング（図３のｔ３参照）に決定する。

また、具体的なコンポーネントおよびその再生態様を示すがゆえに、主構成情報と比べて更新頻度が高いと予想される副構成情報については、主構成情報よりも高い頻度で配信されるように、配信タイミングを主構成情報よりも短い時間間隔とする。そして、副構成情報のバージョンを変えるタイミングは、再生されるコンポーネントの構成を変化させるタイミング（図３のｔ３参照）とする。

同様に、主構成情報と比べて更新頻度が低いと予想される副構成情報については、主構成情報よりも低い頻度で配信されるように、配信タイミングを主構成情報よりも長い時間間隔とする。また、副構成情報のバージョンを変えるタイミングは、再生されるコンポーネントの構成を変化させるタイミングとする。更新頻度を設定するための基準としては、この他、各コンポーネントの重要度、例えば、含まれるコンポーネント再生が必須であるか、任意であるか、といった点もあげられる。再生が必須であるコンポーネントを主構成情報が含む場合、高い頻度で配信する。一方、再生が任意である（再生しないことが許可される）コンポーネントのみを含んだ副構成情報である場合、配信の頻度を低く設定する。

最後に、配信制御部１６は、上記のようにして決定した配信スケジュールにて、サーバ通信部１２を介して再生クライアント２にコンポーネントおよび構成情報（主構成情報、副構成情報）を配信し（Ｓ７、配信制御ステップ）、これにより配信処理は終了する。

〈図５の構成情報を図６の配信タイミングで配信する場合の配信処理〉
図５の構成情報を図６の配信タイミングで配信する場合、図１４のＳ４では、構成情報解析部１４は、＜components＞タグに記述されているコンポーネントのうち、相対的に重要度の高いコンポーネントを第１の副構成情報に記述する情報と決定する。そして、相対的に重要度の低い他のコンポーネントを第２の副構成情報に記述する情報と決定する。

なお、重要度の高いコンポーネントは、その属性等に応じて予め定めておけばよい。例えば、「audio」、「video」等のような属性のコンポーネント（主映像のコンポーネントおよび副映像のコンポーネント等）を、重要度の高いコンポーネントとして定め、「text」等のような属性のコンポーネント（字幕コンポーネント等）を、重要度の低いコンポーネントとして定めてもよい。

また、再生が必須のコンポーネントを重要度の高いコンポーネントと判断してもよい。この場合、構成情報１７の＜compositions＞タグにおいて"optional"となっているコンポーネントを重要度の低いコンポーネントと判断し、このコンポーネントに関する情報を第２の副構成情報に記述する情報と決定する。そして、他のコンポーネントを重要度の高いコンポーネントと判断し、そのコンポーネントに関する情報を第１の副構成情報に記述する情報と決定する。

また、Ｓ６では、配信制御部１６は、第１の副構成情報の配信頻度が最も高くなり、第２の副構成情報の配信頻度が次に高くなり、主構成情報の配信頻度が最も低くなるように配信スケジュールを決定する。

〈図８の構成情報を図９の配信タイミングで配信する場合の配信処理〉
図８の構成情報を図９の配信タイミングで配信する場合、図１４のＳ４では、構成情報解析部１４は、＜components＞タグに記述されているコンポーネントを第１の副構成情報に記述する情報と決定する。

また、レイアウト１を第２の副構成情報に記述する情報と決定すると共に、レイアウト１の経時変化に応じたバージョン１から３の第２の副構成情報に含める情報を決定する。具体的には、バージョン１には、レイアウト１のデフォルトのレイアウトとして記述された情報を記述することを決定する。また、バージョン２には、レイアウト３に記述された情報を記述し、バージョン３には、上記デフォルトのレイアウトとして記述された情報を記述することを決定する。なお、各バージョンに何れのレイアウトを記述するかは、配信サーバ１を用いてコンテンツの配信を行う事業者に選択させてもよいし、予め設定した条件に基づいて自動で選択するようにしてもよい。

そして、Ｓ６では、配信制御部１６は、図３の副構成情報と同様にして、第１の副構成情報の配信タイミングを決定する。また、バージョン１から３の第２の副構成情報については、レイアウト１を変更すべきタイミングで配信されるように、配信タイミングを決定する。

すなわち、コンポーネントの再生開始と同時に選択候補となるバージョン１の配信タイミングは、当該コンポーネントの配信時刻と同じかそれ以前とする。また、レイアウト１を最初に変更させる時刻であるｔ１には配信が完了するようにバージョン２の配信タイミングを決定し、バージョン３の配信タイミングについては、次に変更させる時刻ｔ２に配信が完了するように決定する。

〈図１０（ｂ）の構成情報を同図（ａ）の配信タイミングで配信する場合の配信処理〉
図１０（ｂ）の構成情報を同図（ａ）の配信タイミングで配信する場合、図１４のＳ３およびＳ４では、構成情報解析部１４は、図２の構成情報を生成する場合と同様にして主構成情報および副構成情報のそれぞれに記述する情報を決定する。

次に、構成情報生成部１５は、Ｓ３、Ｓ４で決定された情報をそれぞれ含む主構成情報および副構成情報を生成する。また、この主構成情報には、副構成情報を参照するための情報を記述する。さらに、主構成情報には、副構成情報を所定のプロトコル（図１０の例ではprotocolA）から取得するためのベースＵＲＬと、主構成情報および副構成情報をＨＴＴＰにより取得するためのベースＵＲＬとを記述する。

そして、Ｓ６では、配信制御部１６は、主構成情報および副構成情報を上記所定のプロトコルでコンポーネントと共に配信することを決定する。また、配信制御部１６は、主構成情報および副構成情報を、主構成情報に記述したＵＲＬにより取得することができるようにする。例えば、記述したＵＲＬが配信サーバ１のＵＲＬではない場合には、当該ＵＲＬが示す格納先に主構成情報および副構成情報をアップロードする。

〈図１２（ｂ）の構成情報を同図（ａ）の配信タイミングで配信する場合の配信処理〉
図１２（ｂ）の構成情報を同図（ａ）の配信タイミングで配信する場合、配信サーバ１には、サーバ通信部１２による伝送路（伝送路Ａ）とは別の伝送路（伝送路Ｂ）で配信するための通信部を設けておく。

この場合、図１４のＳ３およびＳ４では、構成情報解析部１４は、再生が必須のコンポーネントに関する情報を主構成情報に記述する情報と決定する。また、再生が任意（optional）のコンポーネントに関する情報を副構成情報に記述する情報と決定する。

そして、Ｓ６では、配信制御部１６は、再生が必須のコンポーネントを再生するための主構成情報を、このコンポーネントを伝送する伝送路（伝送路Ａ）で配信することを決定する。また、再生が任意のコンポーネントを再生するための副構成情報を、このコンポーネントを伝送する伝送路（伝送路Ｂ）で配信することを決定する。

なお、主構成情報および副構成情報の配信周期は特に限定されず、対応するコンポーネントにかかわらず所定の周期としてもよいし、コンポーネントの属性に応じて周期を変えてもよい。

また、Ｓ３およびＳ４では、構成情報解析部１４は、重要なコンポーネントに関する情報を主構成情報に記述する情報と決定し、その他のコンポーネントに関する情報を副構成情報に記述する情報と決定してもよい。そして、Ｓ６では、配信制御部１６は、重要なコンポーネントを再生するための主構成情報を、このコンポーネントを伝送する伝送路（伝送路Ａ）で配信することを決定し、その他のコンポーネントを再生するための副構成情報を、このコンポーネントを伝送する伝送路（伝送路Ｂ）で配信することを決定してもよい。

〈図１３の構成情報を配信する場合の配信処理〉
図１３の構成情報を配信する場合、配信対象の２つのコンテンツ（第１のコンテンツおよび第２のコンテンツ）をそれぞれ配信用のコンポーネントに変換し（Ｓ１）、各コンテンツの構成情報（第１の構成情報および第２の構成情報）を取得する（Ｓ２）。

次に、構成情報解析部１４は、双方の構成情報に共通して含まれる情報を副構成情報とし、他の情報を主構成情報とすることを決定する（Ｓ３、Ｓ４）。なお、副構成情報には、双方の構成情報に共通して含まれる情報以外にも、他の例と同様に、再生対象のコンポーネントを特定する情報や、コンポーネントの再生態様を示す情報等を含めてもよい。

そして、構成情報生成部１５は、各コンテンツの構成情報に記述されている情報のうち、副構成情報とすることが決定された情報を参照形式に書き換えて、各コンテンツの構成情報にそれぞれ対応する主構成情報（第１の参照形式構成情報および第２の参照形式構成情報）を生成する。また、副構成情報とすることが決定された情報を副構成情報として生成する（Ｓ５）。このとき、構成情報生成部１５は、副構成情報において、生成した２つの主構成情報から共通して参照される情報には、これら３つの構成情報で共通のidを付す（図１３の"s1"）。

最後に、配信制御部１６は、２つの主構成情報と１つの副構成情報、および配信対象の２つのコンテンツの配信スケジュールを決定し（Ｓ６）、決定したスケジュールに従って配信する（Ｓ７）。

例えば、地上デジタル放送のようなテレビ向け高解像度コンテンツと、ワンセグ放送のようなモバイル機器向け低解像度コンテンツとをそれぞれ配信する場合に、両コンテンツで共通する、例えばデータ放送のようなテキストコンポーネントおよび画像コンポーネントに関する情報を副構成情報としたときには、テレビ向け高解像度コンテンツとこれに対応する主構成情報とを多重化して繰り返し配信してもよい。同様に、モバイル向け低解像度コンテンツとこれに対応する主構成情報とを多重化して繰り返し配信してもよい。また、デジタル放送におけるデータ放送のように、テキストコンポーネントおよび画像コンポーネントをデータカルーセルで配信する場合には、当該コンポーネントに関する副構成情報をデータカルーセルの配信頻度に合わせて配信することで、当該副構成情報の配信頻度を低くしてもよい。

《再生処理》
続いて、再生クライアント２がコンテンツ１８の再生の際に実行する再生処理の流れを図１５に基づいて説明する。図１５は、再生処理の一例を示すフローチャートである。なお、ここではまず、図３の配信タイミングで配信された図２の構成情報に基づいて再生する例について説明し、他の構成情報を用いる場合の処理についてはその後で説明する。

クライアント通信部２２は、配信サーバ１が配信したコンテンツ１８の受信を開始し（Ｓ１０）、受信したコンテンツ１８を受信データ格納部２６に格納する。なお、コンテンツ１８は、構成情報を含む図４のようなストリームデータとして受信され、格納される。

受信データ格納部２６へのコンテンツ１８の格納が開始されると、再生制御部２３は、このコンテンツ１８を再生するための主構成情報をクライアント記憶部２１に記憶しているか確認する（Ｓ１１）。なお、主構成情報は、複数種類のコンテンツで共通化してもよい。この場合、コンテンツ１８とは異なる他のコンテンツの再生に用いた主構成情報が記憶されていれば、これを適用することができる。

ここで、構成情報２５がクライアント記憶部２１に記憶されていることが確認された場合（Ｓ１１でＹＥＳ）、再生制御部２３は、記憶している構成情報２５に含まれる主構成情報をコンテンツ１８の再生に適用することを決定し（Ｓ１２）、Ｓ１５の処理に進む。

一方、構成情報２５がクライアント記憶部２１に記憶されていないことが確認された場合（Ｓ１１でＮＯ）、再生制御部２３は、受信した主構成情報が受信データ格納部２６に格納されていないか確認する（Ｓ１３）。

そして、受信データ格納部２６に格納されていることが確認されると（Ｓ１３でＹＥＳ）、再生制御部２３は、受信した主構成情報をコンテンツ１８の再生に適用することを決定し（Ｓ１４）、Ｓ１５の処理に進む。

Ｓ１５では、再生制御部２３は、再生開始に必要な主構成情報および副構成情報が受信済みであるか確認する。なお、再生開始に必要な構成情報を受信済みであるかは、Ｓ１２またはＳ１４で適用することを決めた主構成情報を参照することで判断可能である。

つまり、図２の主構成情報では、１つの副構成情報が参照されている。このため、この参照先の副構成情報が受信データ格納部２６に格納されていれば、再生開始に必要な構成情報を受信済みであると判断し、格納されていなければ受信済みではないと判断することができる。

Ｓ１５において、再生開始に必要な構成情報が受信済みでない場合（Ｓ１５でＮＯ）、Ｓ１５の処理を繰り返す。ただし、Ｓ１５を繰り返し処理する間に、異なるバージョンの主構成情報を受信した場合には、その主構成情報に基づき、再生開始に必要な主構成情報および副構成情報が受信済みであるかの判断を行う。

Ｓ１５において、再生開始に必要な構成情報が受信済みであることが確認されると（Ｓ１５でＹＥＳ）、再生制御部２３は、主構成情報および副構成情報に基づいて、再生部２４にコンテンツ１８の再生を開始させる（Ｓ１６）。

具体的には、再生制御部２３は、主構成情報で参照形式となっている部分を、参照先の副構成情報中で特定して、コンポーネントの組み合わせ等のコンテンツ１８の再生に必要な情報を取得する。そして、取得した情報に従って再生部２４に再生対象のコンポーネントおよびその再生態様を通知することによって、コンテンツ１８を再生させる。

また、再生制御部２３は、コンテンツ１８の再生中において、新たなバージョンの構成情報を受信したか確認する（Ｓ１７）。なお、図４に基づいて説明したように、新たなバージョンの構成情報を受信したかは、ペイロードヘッダを参照して特定できるようにすることが好ましい。

ここで、新たなバージョンの構成情報の受信が確認されなければ（Ｓ１７でＮＯ）Ｓ１９の処理に進む。一方、受信を確認した場合（Ｓ１７でＹＥＳ）、再生制御部２３は、適用する構成情報を新たなバージョンのものに更新する（Ｓ１８）。

具体的には、新たなバージョンの主構成情報を受信した場合には、Ｓ１２またはＳ１４で適用を決めた主構成情報の代わりに、新たなバージョンの主構成情報を適用する。また、新たなバージョンの副構成情報を受信した場合には、前バージョンの副構成情報の代わりに、新たなバージョンの副構成情報を適用する。

この後、再生制御部２３は、コンテンツ１８の再生を終了するか判断し（Ｓ１９）、終了する場合には（Ｓ１９でＹＥＳ）、再生部２４にその旨を通知して再生を終了させ、再生処理を終了する。一方、終了しない場合には（Ｓ１９でＮＯ）Ｓ１７の処理に戻る。

〈図５の構成情報を図６の配信タイミングで配信する場合の再生処理〉
図５の構成情報を図６の配信タイミングで配信する場合、図１５のＳ１５において、再生制御部２３は、全ての副構成情報のうち、再生の開始に必要な副構成情報が全て受信済みであるか確認する。

これは、図５の構成情報には、再生が任意のコンポーネントに対応する第２の副構成情報が含まれており、第２の副構成情報が受信されていなくとも、第１の副構成情報が受信されていれば再生を開始することができるためである。

〈図８の構成情報を図９の配信タイミングで配信する場合の再生処理〉
図８の構成情報を図９の配信タイミングで配信する場合、図１５のＳ１２またはＳ１４で適用する主構成情報を決定した再生制御部２３は、ユーザにレイアウトを選択させる。

ここで、第２の副構成情報を用いずに使用可能なレイアウト２または３が選択された場合、再生制御部２３は、第１の副構成情報の受信が確認された時点で、再生の開始に必要な副構成情報が全て受信済みである（Ｓ１５でＹＥＳ）と判断し、Ｓ１６の処理に進む。

一方、第２の副構成情報が必要なレイアウト１が選択された場合、再生制御部２３は、第１および第２の副構成情報の両方の受信が確認された時点で、再生の開始に必要な副構成情報が全て受信済みである（Ｓ１５でＹＥＳ）と判断し、Ｓ１６の処理に進む。

そして、この後、時刻ｔ１に配信されるバージョン２の第２の副構成情報を受信し（Ｓ１７でＹＥＳ）、再生制御部２３は、適用する第２の副構成情報をバージョン２に更新する。これにより、コンテンツ１８の表示レイアウトが変化する。時刻ｔ３においても同様に適用する第２の副構成情報をバージョン３に更新し、これにより表示レイアウトが変化する。

〈図１０（ｂ）の構成情報を同図（ａ）の配信タイミングで配信する場合の再生処理〉
図１０（ｂ）の構成情報を同図（ａ）の配信タイミングで配信する場合、Ｓ１５において、再生に必要な全ての副構成情報の受信が確認されなかった場合（Ｓ１５でＮＯ）、再生制御部２３は、副構成情報をオンデマンドで取得する。

具体的には、再生制御部２３は、主構成情報に記述されているＵＲＬを用いて副構成情報の送信要求を行い、この送信要求に対する応答として送信される副構成情報を取得して、Ｓ１６の処理に進む。

なお、構成情報の送信要求は、図１には示していないが、再生制御部２３とは別の機能ブロックで行うようにしてもよい。また、構成情報の送信要求を行わずに、protocolAにて所定の周期で配信される副構成情報の受信を待ってもよい。

〈図１２（ｂ）の構成情報を同図（ａ）の配信タイミングで配信する場合の再生処理〉
図１２（ｂ）の構成情報を同図（ａ）の配信タイミングで配信する場合、Ｓ１０では、伝送路ＡおよびＢでコンテンツの受信が開始される。無論、伝送路ＡおよびＢにおけるコンテンツの受信開始タイミングは異なっていてもよく、伝送路Ｂにおけるコンテンツの受信はオンデマンドで行ってもよい。

また、この場合、再生制御部２３は、Ｓ１２またはＳ１４で適用を決定した主構成情報における"optional"の記述から、副構成情報に記述されている情報が何れも任意再生のコンポーネントに関する情報であると特定する。そして、当該任意再生のコンポーネントの再生可否をユーザ入力等に基づいて判断する。

ここで、任意再生のコンポーネントを再生すると判断した場合、任意再生のコンポーネントの再生に必要な副構成情報の受信が完了した後（Ｓ１５でＹＥＳ）、主構成情報および副構成情報に基づいてコンテンツを再生する（Ｓ１６）。一方、任意再生のコンポーネントを再生しないと判断した場合、主構成情報のみで再生開始可能と判断し（Ｓ１５）、主構成情報に基づいてコンテンツを再生する（Ｓ１６）。

〈図１３の構成情報を配信する場合の再生処理〉
図１３の構成情報を配信する場合、一方の主構成情報は一方の再生装置（例えば再生クライアント２）に配信され、他方の主構成情報は他方の再生装置に配信されるので、各再生装置における再生処理は、図２等の構成情報を用いる場合と同様である。

本発明は上述した実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能である。すなわち、請求項に示した範囲で適宜変更した技術的手段を組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

〔実施形態２〕
次に、本発明の別の一実施形態に係るコンテンツ送受信システムについて説明する。

本実施形態に係るコンテンツ送受信システムは、メイン配信サーバと１台以上のサブ配信サーバと再生クライアントとを含むシステムである。

配信者によって、新たにアップロードするコンテンツは１台以上の配信サーバに格納される。具体的には、コンテンツを構成する全コンポーネントがメイン配信サーバに格納されることもあれば、全コンポーネントがメイン配信サーバおよび１台以上のサブ配信サーバに分けて格納されることもある。

本実施形態では、再生クライアントがコンテンツのリクエストをメイン配信サーバに送信すると、メイン配信サーバは、そのコンテンツ（以下では「配信対象コンテンツ」とも称する）の提供に関係している１台以上の配信サーバを特定する。そして、メイン配信サーバは、特定した各配信サーバに再生クライアントのアドレスを通知する。特定するアドレスは、再生クライアントを一意に特定する情報でも、ドメインのように複数の再生クライアントを論理的に代表した情報であってもよい。各配信サーバは、再生クライアントとのコネクションを確立して配信対象コンテンツに関する構成情報を配信するとともに、配信対象コンテンツを構成するコンポーネント群を再生クライアントに配信する。

再生クライアントは、配信対象コンテンツの提供に関係している１台以上の配信サーバから受信した主構成情報および副構成情報に基づいて再生すべきコンポーネント群を特定し、配信されてきたコンポーネント群の中から特定したコンポーネント群だけを取得して再生する。

本実施形態に係るコンテンツ送受信システムの構成を図１７に基づいて説明する。図１７は、コンテンツ送受信システム３００を構成するメイン配信サーバ１００、サブ配信サーバ１１０および再生クライアント２’の要部構成を示すブロック図である。なお、図では、サブ配信サーバとしてサブ配信サーバ１１０のみが示されているが、コンテンツ送受信システムには、サブ配信サーバ１１０と同様に構成された他のサブ配信サーバも含まれている。

図示のように、コンテンツ送受信システム３００は、メイン配信サーバ１００とサブ配信サーバ１１０と再生クライアント２’とがネットワークを介して接続された構成である。また、図示はしていないが、他のサブ配信サーバもこのネットワークに接続されている。

メイン配信サーバ１００は、コンテンツを配信する装置であるが、必要に応じて各サブ配信サーバを統括する役割を担っている。また、メイン配信サーバ１００は、再生クライアント２’からのコンテンツの配信要求を受け付ける役割を担っている。

メイン配信サーバ１００は、メイン配信サーバ１００の機能を統括して制御するサーバ制御部１０２０、メイン配信サーバ１００で使用するデータを格納するサーバ記憶部１１、およびメイン配信サーバ１００が外部の装置と通信を行うためのサーバ通信部１２を備えている。また、サーバ制御部１０２０は、設定情報解析部１０１４および配信制御部１０１６を含み、サーバ記憶部１１には、コンテンツ送受信システム３００で配信可能なコンテンツ毎に、コンテンツに関する主構成情報１７ａ、コンテンツを構成するコンポーネント群１８ａ、および、コンテンツに関する設定情報１９が格納されている。なお、主構成情報１７ａには、コンポーネントを再生するための情報としてコンポーネント群１８ａの全部または一部を再生するための情報のみが含まれている。また、コンテンツに関する設定情報１９には、そのコンテンツの配信に関係している各配信サーバのＵＲＬが記述されている。

設定情報解析部１０１４は、サーバ記憶部１１に格納されている設定情報１９を取得・解析し、設定情報１９に基づいて配信対象コンテンツの配信に関係しているサブ配信サーバを特定する。

配信制御部１０１６は、配信対象コンテンツの配信を制御する。具体的には、配信制御部１０１６は、設定情報解析部１０１４が特定した各サブ配信サーバに対し、再生クライアント２’との間でコネクションを確立するとともに副構成情報とサブ配信サーバが保存している配信対象コンテンツのコンポーネント群１８ｂとを再生クライアント２’に配信するよう、要求する。

また、配信制御部１０１６は、サーバ通信部１２を介して、サーバ記憶部１１の主構成情報１７ａを再生クライアント２に配信する。さらに、配信制御部１０１６は、サーバ通信部１２を介して、サーバ記憶部１１のコンポーネント群１８ａを配信する。

サブ配信サーバ１１０は、メイン配信サーバ１００と同様にコンテンツを配信する装置であるが、メイン配信サーバ１００からの指示を受けて、配信対象コンテンツを構成するコンポーネント群、および、配信対象コンテンツに関する副構成情報を再生クライアント２’に配信する。

サブ配信サーバ１１０は、サブ配信サーバ１１０で使用するデータを格納するサーバ記憶部１１、サブ配信サーバ１１０が外部の装置と通信を行うためのサーバ通信部１２、および、配信制御部１１１６を備えている。サーバ記憶部１１には、サブ配信サーバ１１０が配信可能なコンテンツ毎に、コンテンツに関する副構成情報１７ｂおよびコンテンツを構成するコンポーネント群１８ｂが格納されている。副構成情報１７ｂには、コンポーネントを再生するための情報としてコンポーネント群１８ｂの全部または一部を再生するための情報のみが含まれている。

配信制御部１１１６は、配信対象コンテンツの配信を制御する。具体的には、配信制御部１１１６は、副構成情報１７ｂの配信スケジュールを決定し、サーバ通信部１２を介して、決定した配信スケジュールに従ってサーバ記憶部１１の副構成情報１７ｂを再生クライアント２’に順次配信する。また、配信制御部１１１６は、サーバ通信部１２を介して、サーバ記憶部１１のコンポーネント群１８ｂを配信する。

一方、再生クライアント２’は、コンテンツを受信して再生する装置であり、再生クライアント２’の機能を統括して制御するクライアント制御部２０’、再生クライアント２’で使用するデータを格納するクライアント記憶部２１、および再生クライアント２’が外部の装置と通信を行うためのクライアント通信部２２を備えている。また、クライアント制御部２０’は、再生制御部２３’および再生部２４を含み、クライアント記憶部２１には構成情報２５が格納されていると共に、受信データ格納部２６が設けられている。すなわち、再生クライアント２’が再生クライアント２と相違する点は、再生制御部として再生制御部２３’を備えている点である。

再生制御部２３’は、コンテンツの再生を統括して制御する。具体的には、再生制御部２３’は、配信対象コンテンツの配信に関係している１台以上の配信サーバ（例えば、メイン配信サーバ１００およびサブ配信サーバ１１０）から配信された主構成情報および副構成情報（例えば、主構成情報１７ａおよび副構成情報１７ｂ）を解析し、この解析結果に基づいて、再生部２４に配信対象コンテンツを再生させる。

具体的には、再生制御部２３’は、主構成情報を構成情報２５としてクライアント記憶部２１に記録する。そして、再生制御部２３’は、配信されるコンポーネント群のうち、構成情報２５に基づいて再生対象であると判断されたコンポーネント群のみをクライアント記憶部２１に記録して再生する。

また、再生制御部２３’は、コンテンツの再生前または再生中に、副構成情報を受信すると、副構成情報を用いてクライアント記憶部２１の構成情報２５を更新する。構成情報２５が更新されると、更新後の構成情報２５に基づいて再生対象のコンポーネント群を特定し、配信されるコンポーネント群のうち、特定したコンポーネント群のみをクライアント記憶部２１に記憶して再生する。

以上、コンテンツ送受信システム３００の構成について説明した。なお、本実施形態における以下の説明では、メイン配信サーバ１００が配信対象コンテンツを構成する一部のコンポーネントと主構成情報とを配信し、サブ配信サーバ１１０が配信対象コンテンツを構成する残りのコンポーネントと副構成情報とを配信するものとする。すなわち、コンポーネント群１８ａは上記一部のコンポーネントに相当し、コンポーネント群１８ｂは上記残りのコンポーネントに相当する。

《主構成情報および副構成情報について》
コンテンツ送受信システム３００内で配信される主構成情報には、components要素、par要素、およびseq要素にid属性が付与されている。これらのid属性は、再生制御部２３’が副構成情報を用いて主構成情報を構成情報２５に更新するために参照する属性である。

また、コンテンツ送受信システム３００内で配信される副構成情報には、ref_id属性を持つinsert要素が記述されている。再生制御部２３’は、記述されている各insert要素について、insert要素の内容を、属性値がref_id属性と同一であるid属性が付与されている主構成情報内の要素に追加する。すなわち、このid属性は、主構成情報内の更新可能（挿入可能）な箇所を示している。

例えば、再生制御部２３’は、図１８（ａ）に示す主構成情報をメイン配信サーバ１００から受信するとともに、図１８（ｂ）に示す副構成情報をサブ配信サーバ１１０から受信した場合には、以下の処理を行う。
・id属性の属性値が"c3"であるcomp要素を、主構成情報におけるid属性の属性値が"cpn1"であるcomponents要素の内容として追加する。
・comp属性の属性値が"c3"であるtext要素を、主構成情報におけるid属性の属性値が"par1"であるpar要素の内容として追加する。

その結果、再生制御部２３’は、主構成情報を、図１８（ｃ）に示すような構成情報２５に更新することになる。そして、再生制御部２３’は、コンテンツの再生前あるいは再生中に図１８（ｂ）の副構成情報を受信した場合には、メイン配信サーバのコンポーネントと並行して、comp属性の属性値が"c3"であるtext要素に対応するサブ配信サーバのテキストコンポーネントを新たに再生する。

同様に、再生制御部２３’は、図１９（ａ）に示す主構成情報をメイン配信サーバ１００から受信するとともに、図１９（ｂ）に示す副構成情報をサブ配信サーバ１１０から受信した場合には、以下の処理を行う。
・id属性の属性値がそれぞれ"c3"および"c4"である２つのcomp要素を、主構成情報におけるid属性の属性値が“cpn1”であるcomponents要素の内容の末尾に追加する。
・comp属性の属性値が"c3"であるvideo要素とcomp属性の属性値が"c4"であるaudio要素とを内容として含むpar要素を、主構成情報におけるid属性の属性値が"seq1"であるseq要素の内容として追加する。

その結果、再生制御部２３’は、主構成情報を、図１９（ｃ）に示すような構成情報２５に更新することになる。再生制御部２３’は、コンテンツの再生前あるいは再生中に図１９（ｂ）の副構成情報を受信した場合には、図１９（ｃ）の構成情報２５に基づいて、メイン配信サーバのコンポーネントの再生完了後に、サブ配信サーバの配信コンポーネントであるcomp属性の属性値が"c3"であるvideo要素に対応する映像コンポーネントと、comp属性の属性値が"c4"であるaudio要素に対応する音声コンポーネントとを並列的に再生する。

なお、再生制御部２３’は、副構成情報に記載された要素をseq要素の内容として追加する処理を主構成情報に施す場合、必ず、追加する要素がseq要素の内容の末尾に来るように追加する。例えば、図２０（ａ）に示す主構成情報をメイン配信サーバ１００から受信するとともに、図２０（ｂ）に示す副構成情報をサブ配信サーバ１１０から受信した場合には、comp属性の属性値が"c3"であるvideo要素がid属性の属性値が"seq1"であるseq要素の内容の末尾に来るように、video要素を追加する。

従って、seq要素の内容として追加される要素を含む、異なる副構成情報が配信サーバから配信される場合、再生クライアント２’が副構成情報を受信する順序に応じて、構成情報２５の内容が異なることになる。例えば、先に再生すべき映像コンポーネントに対応するvideo要素を含む第１の副構成情報と、後に再生すべき映像コンポーネントに対応するvideo要素を含む第２の副構成情報と、が順に配信されるケースがある。このケースにおいて、第１の副構成情報の配信経路と第２の副構成情報の配信経路とが異なっているときには、再生クライアント２’が第２の副構成情報を先に受信することもある。

そして、第２の副構成情報が先に受信された場合には、seq要素の内容として２つのvideo要素が追加されるものの、後に再生すべき映像コンポーネントに対応するvideo要素の直後に、先に再生すべき映像コンポーネントに対応するvideo要素が追加されてしまう。結果として、再生制御部２３’は、コンテンツ配信者の意図に沿わない順序で映像コンポーネントを再生してしまう。

そのため、主構成情報および副構成情報のci要素には、更新処理をすべき順序を示すlayer属性を含めることが望ましい。例えば、主構成情報を図２１（ａ）に示すような構成情報とし、順次配信する副構成情報を図２１（ｂ）の構成情報および図２１（ｄ）の構成情報とすることが望ましい。

配信される構成情報にlayer属性が含まれている場合、再生制御部２３’は、layer属性の属性値がｉである副構成情報をｉ回目の構成情報２５の更新処理に用いる。

例えば、メイン配信サーバ１００から受信した図２１（ａ）の主構成情報がクライアント記憶部２１に記録されている状態で、先に図２１（ｂ）の副構成情報を受信した場合には、受信した副構成情報を用いてすぐに図２１（ａ）の主構成情報を図２１（ｃ）の構成情報２５に更新する。そして、その後に図２１（ｄ）の副構成情報を受信すると、受信した副構成情報を用いてすぐに図２１（ｃ）の構成情報２５を図２１（ｅ）の構成情報２５に更新する。

一方、メイン配信サーバ１００から受信した図２１（ａ）の主構成情報がクライアント記憶部２１に記録されている状態で先に図２１（ｄ）の副構成情報を受信した場合には、layer属性の属性値が"１"である副構成情報を用いた更新処理を行うまで、その副構成情報をクライアント記憶部２１に記録しておく。そして、その後に図２１（ｂ）の副構成情報を受信すると、まず図２１（ｂ）の副構成情報を用いて更新処理を行った上で、図２１（ｄ）の副構成情報を用いて更新処理を行う。

このように、再生制御部２３’は、どちらの副構成情報が先に受信された場合にも、図２１（ａ）の主構成情報を同じ図２１（ｅ）の構成情報２５に更新する。したがって、再生クライアント２’は、必ず、コンテンツ配信者の意図に沿った順序で映像コンポーネントを再生することになる。

《コンテンツ送受信システム３００の変形例３００ａ》
前述したように、コンテンツ送受信システム３００は、図２２（ａ）に示すような処理を行った上で再生クライアント２’がコンテンツの再生を開始するが、本発明をコンテンツ送受信システム３００ａとしても実施できる。

コンテンツ送受信システム３００ａについて図２２および図２３を参照しながら説明する。図２３は、コンテンツ送受信システム３００ａを構成するメイン配信サーバ１００、サブ配信サーバ１１０および再生クライアント２ａの要部構成を示すブロック図である。なお、図では、サブ配信サーバとしてサブ配信サーバ１１０ａのみが示されているが、コンテンツ送受信システムには、サブ配信サーバ１１０ａと同様に構成された他のサブ配信サーバも含まれている。

図２３に示したように、再生クライアント２ａは、クライアント制御部２０ａ（具体的には再生制御部２３ａ）を備えている点で、再生クライアント２’と異なっている。また、メイン配信サーバ１００ａは、メイン配信サーバ１００と異なり、設定情報解析部１０１４を備えておらず、配信制御部１０１６ａを備えている。サブ配信サーバ１１０ａは、サブ配信サーバ１１０と異なり、配信制御部１１１６ａを備えている。

再生制御部２３ａは、配信対象コンテンツの設定情報１９に基づいて、配信対象コンテンツの配信に関係している１台以上の配信サーバ（例えば、メイン配信サーバ１００ａおよびサブ配信サーバ１１０ａ）を特定し、特定した各配信サーバとのコネクションを確立する。そして、再生制御部２３ａは、各配信サーバに対して配信対象コンテンツの構成情報を配信するよう要求する。再生制御部２３ａは、各配信サーバから配信される構成情報に基づいて、各配信サーバから配信されるコンポーネント群の中から再生に必要なコンポーネント群を特定し、特定したコンポーネント群を記録して再生する。

配信制御部１０１６ａは、配信対象コンテンツに関する主構成情報１７ａ、コンポーネント群１８ａおよび設定情報１９を再生クライアント２ａに配信する。配信制御部１１１６ａは、再生クライアント２ａから配信対象コンテンツに関する構成情報の要求を受信すると、副構成情報１７ｂを再生クライアント２ａに送信する。その後、配信制御部１１１６ａは、配信対象コンテンツのコンポーネント群１８ｂを再生クライアント２ａに配信する。

概略的に言うと、コンテンツ送受信システム３００ａは、図２２（ｂ）に示すような処理を行った上で再生クライアント２ａがコンテンツの再生を開始することになる。

《コンテンツ送受信システム３００に関する付記事項》
配信対象コンテンツの配信に関係しているサブ配信サーバが存在しない場合（すなわち、配信対象コンテンツの配信に関係している配信サーバがメイン配信サーバ１００のみである場合）には、当然ながら、メイン配信サーバ１００のみが、配信対象コンテンツに関する主構成情報、副構成情報およびコンポーネント群を配信することになる。そして、再生クライアント２は、メイン配信サーバ１００から配信された主構成情報を、同じくメイン配信サーバ１００から配信された副構成情報を用いて構成情報２５に更新することになる。

〔実施形態３〕
本発明の別の一実施形態に係るコンテンツ送受信システムについて説明する。

本実施形態に係るコンテンツ送受信システムは、実施形態１に係るコンテンツ送受信システムと同様に、配信サーバと再生クライアントとを含むシステムである。

本実施形態では、再生クライアントがコンテンツのリクエスト（コンテンツ配信サービスへの参加要求）を配信サーバに送信すると、配信サーバは、配信対象コンテンツに関する主構成情報を再生クライアントに配信するとともに、配信対象コンテンツを構成するコンポーネント群を再生クライアントに配信する。その後、配信サーバは、自ら決定した配信スケジュールに基づいて、副構成情報を順次配信する。

再生クライアントは、受信した主構成情報および副構成情報に基づいて、再生すべきコンポーネント群を特定し、配信されてきたコンポーネント群の中から特定したコンポーネント群だけを記録して再生する。

本実施形態に係るコンテンツ送受信システムの構成を図２４に基づいて説明する。図２４は、コンテンツ送受信システム３００’を構成する配信サーバ１００’および再生クライアント２’の要部構成を示すブロック図である。

図示のように、コンテンツ送受信システム３００’は、配信サーバ１００’と再生クライアント２’とがネットワークを介して接続された構成である。

配信サーバ１００’は、コンテンツの配信を制御する配信制御部１０１６’、配信サーバ１００’で使用するデータを格納するサーバ記憶部１１、および配信サーバ１００’が外部の装置と通信を行うためのサーバ通信部１２を備えている。また、サーバ記憶部１１には、配信サーバ１００’で配信可能なコンテンツ毎に、コンテンツに関する主構成情報１７ａおよび副構成情報１７ｂ、コンテンツを構成するコンポーネント群１８、および、コンテンツに関する設定情報１９が格納されている。コンポーネント群１８は、コンテンツを構成する全コンポーネントである。

配信制御部１０１６’は、サーバ通信部１２を介して、サーバ記憶部１１の主構成情報１７ａを再生クライアント２に配信し、サーバ記憶部１１のコンポーネント群１８を配信する。また、配信制御部１１１６は、副構成情報１７ｂの配信スケジュールを決定し、サーバ通信部１２を介して、決定した配信スケジュールに従ってサーバ記憶部１１の副構成情報１７ｂを再生クライアント２’に順次配信する。

なお、再生クライアント２’は、実施形態２に係るコンテンツ送受信システム３００の再生クライアント２’と同一であるため、再生クライアント２’の構成については説明を省略する。

《主構成情報および副構成情報について》
コンテンツ送受信システム３００と同様に、コンテンツ送受信システム３００’内で配信される主構成情報には、components要素およびseq要素にid属性が付与されている。

また、コンテンツ送受信システム３００’内で配信される副構成情報には、ref_id属性を持つreplace要素が記述されている。再生制御部２３’は、記述されている各replace要素について、属性値がref_id属性と同一であるid属性が付与されている主構成情報内の要素の内容をreplace要素の内容に置き換える。すなわち、このid属性は、主構成情報内の更新可能な（置換可能な）箇所を示している。

例えば、再生クライアント２’が図２５（ａ）に示す主構成情報と図２５（ｂ）に示す副構成情報とを配信サーバ１００’から受信した場合には、再生制御部２３’は以下の処理を行う。
・主構成情報におけるid属性の属性値が"cpn1"であるcomponents要素の内容を、id属性の属性値がそれぞれ"c3"および"c4"である２つのcomp要素に置き換える。
・主構成情報におけるid属性の属性値が"seq1"であるseq要素の内容を、comp属性の属性値が"c1"であるvideo要素およびcomp属性の属性値が"c2"であるaudio要素から、comp属性の属性値が"c3"であるvideo要素およびcomp属性の属性値が"c4"であるaudio要素に置き換える。

その結果、再生制御部２３’は、主構成情報を、図２５（ｃ）の構成情報２５に更新することになる。そして、再生制御部２３’は、図２５（ｃ）の構成情報２５に基づいて、comp属性の属性値が"c3"であるvideo要素に対応する映像コンポーネントとcomp属性の属性値が"c4"であるaudio要素に対応する音声コンポーネントとを並行して再生する。なお、本実施形態の以降の説明では、この映像コンポーネントを「映像コンポーネント３」と称し、この音声コンポーネントを「音声コンポーネント４」と称することにする。

さらに、再生クライアント２’が図２５（ｄ）に示す副構成情報を配信サーバ１００’から受信した場合には、再生制御部２３’は以下の処理を行う。
・主構成情報におけるid属性の属性値が"cpn1"であるcomponents要素の内容を、id属性の属性値がそれぞれ"c3"および"c4"である２つのcomp要素から、id属性の属性値がそれぞれ"c5"および"c6"である２つのcomp要素に置き換える。なお、主構成情報にあるid属性の属性値がそれぞれ"c1"および"c2"のcomp要素を置換対象としてもよいし、前段で置換後の図２５（ｃ）の構成情報２５にあるid属性の属性値がそれぞれ"c3"および"c4"のcomp要素を置換対象としてもよい。
・主構成情報におけるid属性の属性値が"seq1"であるseq要素の内容を、comp属性の属性値が"c3"であるvideo要素およびcomp属性の属性値が"c4"であるaudio要素から、comp属性の属性値が"c5"であるvideo要素およびcomp属性の属性値が"c6"であるaudio要素に置き換える。なお、主構成情報にあるcomp属性の属性値が"c1"であるvideo要素およびcomp属性の属性値が"c2"であるaudio要素を置換対象としてもよいし、前段で置換後の図２５（ｃ）の構成情報２５にあるcomp属性の属性値が"c3"であるvideo要素およびcomp属性の属性値が"c4"であるaudio要素を置換対象としてもよい。

その結果、再生制御部２３’は、図２５（ｃ）の構成情報を図２５（ｅ）の構成情報２５に更新することになる。そして、再生制御部２３’は、図２５（ｅ）の構成情報２５に基づいて、comp属性の属性値が"c5"であるvideo要素に対応する映像コンポーネントとcomp属性の属性値が"c6"であるaudio要素に対応する音声コンポーネントとを並行して再生する。なお、本実施形態の以降の説明では、この映像コンポーネントを「映像コンポーネント５」と称し、この音声コンポーネントを「音声コンポーネント６」と称することにする。

以上の説明からわかるように、配信サーバ１００’は、コンテンツの配信中に新たな副構成情報を再生クライアント２’に配信することで、再生クライアント２’での再生対象となるコンポーネントを切り替えることができる。

なお、図２５の構成情報のように、副構成情報のci要素には、副構成情報のバージョンを示すversion属性が含まれていることが望ましい。再生クライアント２’は、副構成情報を用いて構成情報２５を更新した場合には、その副構成情報よりもバージョンが古い（version属性の属性値が相対的に小さい）副構成情報を用いて構成情報２５を更新することはできない。例えば、図２５（ｄ）の副構成情報を用いて図２５（ａ）の構成情報２５を更新した後に、図２５（ｂ）の副構成情報を受信しても、その副構成情報は構成情報２５の更新に使用することができない。

古いバージョンの副構成情報を用いて構成情報２５を更新できないことには以下に説明するような利点がある。

例えば、配信者が、時刻ｔ１以降に再生クライアント２’に映像コンポーネント３および音声コンポーネント４を再生させ、時刻ｔ２（＞ｔ１）以降に再生クライアント２’に映像コンポーネント５および音声コンポーネント６を再生させることを所望するケースを考える。この場合、配信サーバ１００’は、時刻ｔ１になる頃に図２５（ｂ）の副構成情報を配信し、時刻ｔ２になる頃に図２５（ｄ）の副構成情報を配信するように設定される。

前述のように、先に配信された図２５（ｂ）の副構成情報が、ネットワーク障害等の理由で、後に配信された図２５（ｄ）の副構成情報よりも後に再生クライアント２’に届くことがある（図２５（ｂ）の副構成情報が再生クライアント２’に届く時刻をｔ３（＞ｔ２）とする）。この場合であっても、再生クライアント２’は時刻ｔ３で受信した図２５（ｂ）の副構成情報を用いて構成情報２５を更新しないため、クライアント記憶部２１の構成情報２５は、時刻ｔ３の前後で図２５（ｅ）の構成情報２５のまま変わらない。したがって、再生クライアント２’は、図２５（ｂ）の副構成情報および図２５（ｄ）の副構成情報のいずれを先に受信した場合にも、時刻ｔ２以降に配信者の意図通りに映像コンポーネント５および音声コンポーネント６を再生することになる。

一方、副構成情報のci要素にversion属性が含まれていないと、再生クライアント２’は、時刻ｔ３以降で配信者の意図しない映像コンポーネント３および音声コンポーネント４を再生してしまうことになる。

このように、副構成情報のci要素にversion属性を含めることには、再生クライアント２’が配信者の意図しない再生を行うことを防ぐことができるというメリットがある。

なお、主構成情報に関して、配信者が配信対象コンテンツの再生中に再生クライアント２’に常に再生させたいコンポーネントがある場合、そのコンポーネントに関する要素は主構成情報に記述される。また、主構成情報は、図２６（ａ）に示したようなinitialエレメントを含む主構成情報、および、図２６（ｂ）に示したようなダミーエレメントを含む主構成情報のいずれかの形で記述される。

また、配信サーバ１００’のサーバ記憶部１１には、ダミーエレメントを含む主構成情報１７ａと、ci要素にlayer属性とversion属性との両方の属性が含まれている副構成情報１７ｂとが格納されていてもよい。この場合における、再生クライアント２’による構成情報２５の更新処理について図２７を参照しながら説明する。

再生制御部２３’は、受信した副構成情報のversion属性の属性値が"１"である場合には、layer属性の属性値に基づいて適切なタイミングでその副構成情報を用いて構成情報２５を更新する。例えば、図２７（ａ）の副構成情報を構成情報２５としてクライアント記憶部２１に記録した後、１度も構成情報２５を更新していない状態で図２７（ｂ）の構成情報を受信した場合には、すぐに図２７（ａ）の構成情報２５を図２７（ｃ）の構成情報２５に更新する。

一方、再生制御部２３’は、受信した副構成情報（対象副構成情報）のversion属性の属性値が"１"以外である場合には、対象副構成情報のversion属性の属性値が"１"である場合と異なる処理を行うことがある。

具体的には、対象副構成情報のlayer属性の属性値と、対象副構成情報の受信前に直近で受信した副構成情報のlayer属性の属性値と、が同一であり、対象副構成情報のversion属性の属性値がより大きい場合には、insert要素の内容を、構成情報２５に追加するのではなく、insert要素の内容で構成情報２５内の対応要素の内容を置き換える（即ち、insertは常に図２７（ａ）の主構成情報に対する挿入と解釈する。この処理を前段の更新後の構成情報図２７（ｃ）から見た場合には、対応要素の内容を置き換えていると解釈される）。例えば、図２７（ｂ）の構成情報を受信した後、次に図２７（ｄ）の構成情報を受信した場合には、すぐに図２７（ｃ）の構成情報２５を図２７（ｅ）の構成情報２５に更新する。

《コンテンツ送受信システム３００’に関する付記事項》
コンテンツ送受信システム３００’には、配信サーバ１００’に代えて、メイン配信サーバとサブ配信サーバとが含まれていてもよい。この場合、メイン配信サーバが図２６（ａ）や図２７（ａ）等のような主構成情報１７ａとコンポーネント群１８ａとを配信し、サブ配信サーバが図２６（ｂ）や図２７（ｂ）等のような副構成情報１７ｂとコンポーネント群１８ｂとを配信してもよい。

〔実施形態４〕
次に、本発明の別の一実施形態に係るコンテンツ送受信システムについて説明する。

本実施形態に係るコンテンツ送受信システムは、メイン配信サーバ、１台以上のサブ配信サーバ、および再生クライアントに加え、各配信サーバにその配信サーバ用の構成情報を提供するコントロールサーバを含んでいる。

配信者によって、新たにアップロードするコンテンツは１台以上の配信サーバに格納される。具体的には、コンテンツを構成する全コンポーネントがメイン配信サーバに格納されることもあれば、全コンポーネントがメイン配信サーバおよび１台以上のサブ配信サーバに分けて格納されることもある。

また、配信者によって、新たにアップロードしようとするコンテンツに関する構成情報がコントロールサーバに格納される。コントロールサーバは、新たな格納された構成情報から主構成情報および副構成情報を生成し、主構成情報をメイン配信サーバに配信するとともに、副構成情報を１台以上のサブ配信サーバに配信する。

以下、本実施形態に係るコンテンツ送受信システムの構成について図２８を参照しながら説明する。図２８は、コンテンツ送受信システム３００ｂを構成するメイン配信サーバ１００、サブ配信サーバ１１０、再生クライアント２’およびコントロールサーバ５０の要部構成を示すブロック図である。なお、図では、サブ配信サーバとしてサブ配信サーバ１１０のみが示されているが、コンテンツ送受信システムにはサブ配信サーバ１１０と同様に構成された他のサブ配信サーバも含まれている。

図示のように、コンテンツ送受信システム３００は、メイン配信サーバ１００とサブ配信サーバ１１０と再生クライアント２’とコントロールサーバ５０とがネットワークを介して接続された構成である。また、図示はしていないが、他のサブ配信サーバもこのネットワークに接続されている。

メイン配信サーバ１００、サブ配信サーバ１１０、再生クライアント２’の構成については既に説明したので、ここではコントロールサーバ５０の構成について説明する。なお、以下では、説明を単純化するため、コンテンツを構成する一部のコンポーネントがメイン配信サーバ１００にアップロードされ、コンテンツを構成する残りのコンポーネントがサブ配信サーバ１１０にアップロードされたものとして、コントロールサーバ５０の説明を行う。

図２８に示すように、コントロールサーバ５０は、コントロールサーバ５０が外部の装置と通信を行うためのサーバ通信部１２、構成情報の配信を制御する配信制御部５１、および、コントロールサーバ５０で使用するデータが格納されるサーバ記憶部５３を備えている。

サーバ記憶部５１には配信サーバ情報５２が格納されている。また、構成情報５３は、サーバ記憶部５１に新たに格納された構成情報である。

配信サーバ情報５２は、メイン配信サーバおよび１台以上の各サブ配信サーバについて、配信サーバの管理主体（管理会社等）を示す情報が含まれている。

配信制御部５１は、構成情報５３内に含まれている各comp要素について、comp要素に対応するコンポーネントを格納しているか否かをメイン配信サーバおよび１台以上のサブ配信サーバに問い合わせる。これにより、配信制御部５１は、新たにアップロードされたコンテンツを構成する各コンポーネントについて、コンポーネントの配信に関係している配信サーバを特定する。

そして、配信制御部５１は、特定した各配信サーバについて、その配信サーバ用の構成情報を生成する。ここでは、メイン配信サーバ１００用の主構成情報とサブ配信サーバ１１０用の副構成情報とを生成する。

以上、本実施形態に係るコンテンツ送受信システム３００ｂの構成について説明した。

次に、コントロールサーバ５０の動作について図２９を参照しながら説明する。図２９は、コントロールサーバ５０の動作を示すフローチャート図である。

図２９に示すように、最初に、配信制御部５１は、サーバ記憶部１１から構成情報５３を読み出す（Ｓ３１）。

Ｓ３１の後、配信制御部５１は、メイン配信サーバ１００が配信するコンポーネントに対応するcomp要素を主構成情報に含めることを決定し、サブ配信サーバ１１０が配信するコンポーネントに対応するcomp要素を副構成情報に含めることを決定する（Ｓ３２）。

その後、配信制御部５１は、外部参照ＵＲＬを主構成情報に含める実施形態１の参照方式と、insert要素またはreplace要素を副構成情報に含める実施形態２または３の参照方式のいずれを採用するかを決定する（Ｓ３３）。具体的には、配信制御部５１は、配信サーバ情報５２に基づいて、構成情報５３に対応するコンテンツの配信に関係している全配信サーバの管理主体（ここでは、メイン配信サーバ１００の管理主体とサブ配信サーバの管理主体）が同一であるか否かを判定する。配信制御部５１は、全配信サーバの管理主体が同一であると判定した場合には実施形態１の参照方式を採用することを決定し、全配信サーバの管理主体が同一でないと判定した場合には実施形態２の参照方式を採用することを決定する。

Ｓ３３の後、配信制御部５１は、Ｓ３２およびＳ３３の処理結果に基づいて、メイン配信サーバ１００に配信する主構成情報を生成し、サブ配信サーバ１１０に配信する副構成情報を生成する（Ｓ３４）。

そして、主構成情報をメイン配信サーバ１００に配信するとともに（Ｓ３５）、副構成情報をサブ配信サーバ１１０に配信して、処理を終了する。

コントロールサーバ５０により上記処理が行われた後、メイン配信サーバ１００はサーバ記憶部１１に主構成情報を格納し、サブ配信サーバ１１０はサーバ記憶部１１に副構成情報を格納する。そして、メイン配信サーバ１００は、新たにアップロードされたコンテンツの配信リクエストを待ち受けることになる。

以上のように、メイン配信サーバ１００およびサブ配信サーバ１１０が同一の管理主体によって管理されている場合には、メイン配信サーバ１００およびサブ配信サーバ１１０は、それぞれ、実施形態１で説明した主構成情報（外部参照ＵＲＬを含む主構成情報）および副構成情報（外部参照ＵＲＬにより参照される副構成情報）を再生クライアントに配信する。また、メイン配信サーバ１００およびサブ配信サーバ１１０の管理主体が異なっている場合には、メイン配信サーバ１００およびサブ配信サーバ１１０は、それぞれ、実施形態２および３で説明した主構成情報（挿入可能な箇所または置換可能な箇所が示されている主構成情報）および副構成情報（insert要素またはreplace要素を含む副構成情報）を再生クライアントに配信する。

メイン配信サーバと管理主体が同一のサブ配信サーバにあるコンテンツを構成するコンポーネントは、外部参照ＵＲＬを含む主構成情報によって厳密に管理される。即ち、このような主構成情報を受け取った再生クライアントは、コンテンツを再生するために更に副構成情報が必要であることを知り得、配信サーバは、副構成情報および副構成情報に示されたコンポーネントを参照してコンテンツを適当に、管理主体が望む形で再生させることができる。

メイン配信サーバと管理主体が異なる配信サーバにあるコンテンツを構成するコンポーネントは、メイン配信サーバが特にその存在を知らなくても再生されるコンポーネントである。従ってメイン配信サーバがその再生を管理する必要はない。このため、主構成情報には特別な情報を付加せず、副構成情報にinsert要素またはreplace要素を含むことが望ましい。

メインのコンテンツを提供するプロバイダ（放送局など）の認定情報を利用し、必須と認定されたコンポーネントを有するサブ配信サーバの構成情報は実施形態１の方式で記述し、認定無しのコンポーネントを有するサブ配信サーバの構成情報は実施形態２および３で示した方式で記述するといった選択も可能である。無論、管理主体によって参照方式を決定する以外に、オペレータの操作によって随時参照方式を決定するといったことも可能である。

メイン配信サーバ１００およびサブ配信サーバ１１０によるコンテンツの配信処理、並びに、再生クライアントによるコンテンツの再生処理についての詳細な説明は割愛する。当業者であれば、実施形態１〜３の説明を参照すれば、コンテンツの配信処理および再生処理について理解できるであろう。

なお、メイン配信サーバ１００とコントロールサーバ５０とを別のサーバとせず、メイン配信サーバ１００がコントロールサーバ５０の機能を兼ねる構成としてもよい。

〔実施形態５〕
次に、本発明の別の一実施形態に係るコンテンツ送受信システムについて説明する。

本実施形態に係るコンテンツ送受信システムは、実施形態４に係るコンテンツ送受信システムと同様に、メイン配信サーバ、サブ配信サーバ、および再生クライアントに加え、各配信サーバにその配信サーバ用の構成情報を提供するコントロールサーバを含んでいる。

以下、本実施形態に係るコンテンツ送受信システムの構成について図３０を参照しながら説明する。図３０は、コンテンツ送受信システム３００ｃを構成するメイン配信サーバ１００ｃ、サブ配信サーバ１１０ｃ、再生クライアント２ｃおよびコントロールサーバ５０ｃの要部構成を示すブロック図である。

図示のように、コンテンツ送受信システム３００ｃは、メイン配信サーバ１００ｃとサブ配信サーバ１１０ｃと再生クライアント２ｃとコントロールサーバ５０ｃとがネットワークを介して接続された構成である。

図３０に示すように、コントロールサーバ５０ｃは、コントロールサーバ５０ｃが外部の装置と通信を行うためのサーバ通信部１２、構成情報の配信を制御する配信制御部５１ｃ、および、コントロールサーバ５０ｃで使用するデータが格納されるサーバ記憶部１１を備えている。

サーバ記憶部１１には、配信者によって新たにアップロードされた構成情報５３が記録されている。

配信制御部５１ｃは、構成情報５３内に含まれている各comp要素について、comp要素に対応するコンポーネントを格納しているか否かをメイン配信サーバ１００ｃおよびサブ配信サーバ１１０ｃに問い合わせる。また、配信制御部５１ｃは、構成情報５３内に含まれている各comp要素について、comp要素に対応するコンポーネントの重要度を特定する。なお、例えば、コンポーネントの重要度を示す属性が、構成情報５３内のそのコンポーネントに対応するcomp要素内に含まれていてもよい。

そして、配信制御部５１ｃは、メイン配信サーバ１００ｃおよびサブ配信サーバ１１０ｃの各配信サーバについて、その配信サーバが格納している各コンポーネントの重要度に基づいてその配信サーバ用の一群の構成情報を生成する。配信制御部５１ｃは、メイン配信サーバ１００ｃ用の構成情報をメイン配信サーバ１００ｃに配信し、サブ配信サーバ１１０ｃ用の構成情報をサブ配信サーバ１１０ｃに配信する。

メイン配信サーバ１００ｃは、コンテンツを配信する装置であるが、各サブ配信サーバを統括する役割を担っている。また、メイン配信サーバ１００ｃは、再生クライアント２ｃからのコンテンツの配信要求（コンテンツの配信サービスへの参加要求）を受け付ける役割を担っている。

メイン配信サーバ１００ｃは、メイン配信サーバ１００ｃの機能を統括して制御するサーバ制御部１０２０ｃ、メイン配信サーバ１００ｃで使用するデータを格納するサーバ記憶部１１、およびメイン配信サーバ１００ｃが外部の装置と通信を行うためのサーバ通信部１２を備えている。サーバ制御部１０２０ｃは、設定情報解析部１０１４および配信制御部１０１６ｃを含んでいる。

また、サーバ記憶部１１には、コンテンツ送受信システム３００ｃで配信可能なコンテンツ毎に、コンテンツに関する主構成情報１７Ａ、階層１〜階層Ｎの各副構成情報１７Ｂ、コンテンツを構成するコンポーネント群１８ａ、および、コンテンツに関する設定情報１９が格納される。

コンポーネント群１８ａは、メイン配信サーバ１００ｃで配信される、主番組を構成する映像、音声、字幕等のコンポーネントを想定したコンポーネント群である。主構成情報１７Ａには、最も重要度の高い主映像、主音声のコンポーネントが記述される。階層１〜階層Ｎの副構成情報１７Ｂには、重要度に応じて、副音声のコンポーネントや、字幕、差替え字幕のコンポーネントが記述される。これらは、同一のメイン配信サーバ１００ｃから配信される、使用時の順位関係などが明確なコンポーネント群であることから、insert要素またはreplace要素を副構成情報に含める実施形態２または３の参照方式を使って記述する。

また、メイン配信サーバ１００ｃで配信される主構成情報１７Ａおよび／または階層１〜Ｎの副構成情報１７Ｂには、サブ配信サーバ１１０ｃから配信される主構成情報１７ａおよび／または階層１〜Ｍの副構成情報１７ｂについて、それらを参照するための外部参照ＵＲＬを記述し、主番組と共に再生されるＣＭコンポーネントやその関連コンポーネント、天気予報などのデータ配信コンポーネントなどが指定される。これらのコンポーネントはサブ配信サーバ１１０ｃに記録されたコンポーネント群１８ｂに含まれるものであり、主構成情報１７ａおよび／または階層１〜Ｍの副構成情報１７ｂは、それらを参照するための外部参照ＵＲＬが表す位置に格納される。設定情報１９および設定情報解析部１０１４については実施形態２で説明したので、ここでは説明を割愛する。

配信制御部１０１６ｃは、コントロールサーバ５０ｃからあるコンポーネントを格納しているか否かの問合せを受けた場合に、そのコンポーネントを格納しているか否かを示す応答をコントロールサーバ５０ｃに返却する。

配信制御部１０１６ｃは、配信対象コンテンツの配信を制御する。具体的には、配信制御部１０１６ｃは、サブ配信サーバ１１０ｃに対し、再生クライアント２ｃとの間でコネクションを確立するとともに、必要に応じて、主構成情報１７ａ、副構成情報１７ｂ、およびサブ配信サーバ１１０が保存している配信対象コンテンツのコンポーネント群１８ｂを再生クライアント２ｃに配信するよう、要求する。

配信制御部１０１６ｃは、サーバ通信部１２を介して、サーバ記憶部１１の主構成情報１７Ａおよびコンポーネント群１８ａを配信する。さらに、配信制御部１０１６ｃは、階層１〜階層Ｎの各副構成情報１７Ｂの配信スケジュールを決定し、決定した配信スケジュールに従って階層数の小さい順に副構成情報１７Ｂを再生クライアント２ｃに配信する。また、再生クライアント２ｃの要求に応じて副構成情報１７Ｂを配信するといった構成も可能である。

サブ配信サーバ１１０ｃは、メイン配信サーバ１００ｃと同様にコンテンツを配信する装置であるが、メイン配信サーバ１００ｃからの指示を受けて、配信対象コンテンツを構成するコンポーネント群１８ｂ、および、配信対象コンテンツに関する主構成情報１７ａおよび副構成情報１７ｂを再生クライアント２ｃに配信する。コンポーネント群１８ｂは、既に説明したように、主番組と共に再生されるＣＭコンポーネントやその関連コンポーネント、天気予報などのデータ配信コンポーネントなどを想定したコンポーネント群である。

サブ配信サーバ１１０ｃは、コンテンツおよび構成情報の配信を制御する配信制御部１１１６ｃ、サブ配信サーバ１１０ｃで使用するデータを格納するサーバ記憶部１１、並びに、サブ配信サーバ１１０ｃが外部の装置と通信を行うためのサーバ通信部１２を備えている。サーバ記憶部１１には、サブ配信サーバ１１０ｃから配信可能なコンテンツ毎に、コンテンツに関する主構成情報１７ａ、階層１〜階層Ｍの各副構成情報１７ｂ、コンテンツを構成するコンポーネント群１８ｂが格納される。主構成情報１７ａには、主番組と共に再生されるＣＭコンポーネントが記述される。階層１〜階層Ｍの副構成情報１７ｂには、重要度に応じて、ＣＭの関連情報を提示するコンポーネントや、データ配信コンポーネントが記述される。これらは、同一のサブ配信サーバ１１０ｃから配信される、使用時の順位関係などが明確なコンポーネント群であることから、insert要素またはreplace要素を副構成情報に含める実施形態２または３の参照方式を使って記述する。そして、これらを、主番組と共に（主番組を構成する映像、音声、字幕等のコンポーネントと共に）再生することは、メイン配信サーバ１００ｃから配信される主構成情報１７Ａおよび／または階層１〜Ｎの副構成情報１７Ｂ内に記述された外部参照ＵＲＬによって示される。

配信制御部１１１６ｃは、コントロールサーバ５０ｃからあるコンポーネントを格納しているか否かの問合せを受けた場合に、そのコンポーネントを格納しているか否かを示す応答をコントロールサーバ５０ｃに返却する。

また、配信制御部１１１６ｃは、配信対象コンテンツの配信を制御する。具体的には、配信制御部１１１６ｃは、配信対象コンテンツを構成するコンポーネント群１８ｂを配信する。また、配信制御部１１１６ｃは、主構成情報１７ａおよび階層１〜階層Ｍの各副構成情報１７ｂの配信スケジュールを決定し、決定した配信スケジュールに従って、サーバ通信部１２を介して、サーバ記憶部１１の主構成情報１７ａおよび副構成情報１７ｂを、階層の小さい順に再生クライアント２ｃに配信する。また、再生クライアント２ｃの要求に応じて主構成情報１７ａおよび副構成情報１７ｂを配信するといった構成も可能である。

一方、再生クライアント２ｃは、コンテンツを受信して再生する端末であり、再生クライアント２ｃの機能を統括して制御するクライアント制御部２０ｃ、再生クライアント２ｃで使用するデータを格納するクライアント記憶部２１、および再生クライアント２ｃが外部の装置と通信を行うためのクライアント通信部２２を備えている。また、クライアント制御部２０ｃは、再生制御部２３ｃおよび再生部２４を含み、クライアント記憶部２１には構成情報２５が格納されていると共に、受信データ格納部２６が設けられている。すなわち、再生クライアント２ｃは、再生制御部２３ｃを備えている点で再生クライアント２’と相違している。

再生制御部２３ｃは、コンテンツの再生を統括して制御する。具体的には、再生制御部２３ｃは、配信対象コンテンツの配信に関係しているメイン配信サーバ１００およびサブ配信サーバ１１０からそれぞれ配信された主構成情報１７Ａおよび主構成情報１７ａを参照し、再生する配信対象コンテンツのコンポーネント群を決定する。

再生制御部２３ｃは、主構成情報１７Ａを構成情報２５としてクライアント記憶部２１に記録し、以降、副構成情報１７Ｂを受信するたびに、受信した副構成情報１７Ｂを用いてクライアント記憶部２１の構成情報２５を更新する。さらに、再生制御部２３ｃは、主構成情報１７ａを受信すると構成情報２５を更新し、以降、副構成情報１７ｂを受信するたびに、受信した副構成情報１７ｂを用いてクライアント記憶部２１の構成情報２５を更新する。なお、再生クライアント２ｃが予め不要と判断された副構成情報１７Ｂおよび副構成情報１７ｂについては構成情報２５の更新を行わないといった構成も可能である。

以上、本実施形態に係るコンテンツ送受信システム３００ｃの構成について説明した。

次に、コントロールサーバ５０ｃの動作について図３１を参照しながら説明する。図３１は、コントロールサーバ５０ｃの動作を示すフローチャート図である。

図３１に示すように、最初に、コントロールサーバ５０ｃの配信制御部５１ｃは、サーバ記憶部１１から構成情報５３を読み出す（Ｓ４１）。

Ｓ４１の後、配信制御部５１ｃは、メイン配信サーバ１００ｃに配信する構成情報に含めるcomp要素とサブ配信サーバ１１０ｃに配信する構成情報に含めるcomp要素とを決定する（Ｓ４２）。具体的には、配信制御部５１ｃは、構成情報５３内に含まれている各comp要素について、comp要素に対応するコンポーネントを格納しているか否かをメイン配信サーバ１００ｃおよびサブ配信サーバ１１０ｃに問い合わせる。そして、メイン配信サーバ１００ｃに格納されているとの応答を受けた各コンポーネントに対応するcomp要素を、メイン配信サーバ１００ｃに配信する構成情報に含めることを決定する。同様に、サブ配信サーバ１１０ｃに格納されているとの応答を受けた各コンポーネントに対応するcomp要素を、サブ配信サーバ１１０ｃに配信する構成情報に含めることを決定する。

Ｓ４２の後、配信制御部５１ｃは、構成情報５３に基づいて、メイン配信サーバ１００ｃに配信する構成情報に含める各comp要素について、comp要素に対応するコンポーネントの重要度を特定する（Ｓ４３）。

同様に、配信制御部５１ｃは、構成情報５３に基づいて、サブ配信サーバ１１０ｃに配信する構成情報に含める各comp要素について、comp要素に対応するコンポーネントの重要度を特定する（Ｓ４４）。

Ｓ４４の後、配信制御部５１ｃは、メイン配信サーバ１００ｃに配信する、主構成情報、階層１の副構成情報、階層２の副構成情報・・階層Ｎの副構成情報を生成する（Ｓ４５）。具体的には、重要度が最も高いコンポーネントに関するcompタグが主構成情報に含まれ、重要度が相対的に低いコンポーネントに関するcompタグが、バージョンの値が相対的に大きい副構成情報に含まれるように、Ｎ＋１個の構成情報を生成する。これらはinsert要素またはreplace要素を副構成情報に含める実施形態２または３の参照方式を使って記述する。

Ｓ４５の後、配信制御部５１ｃは、サブ配信サーバ１１０ｃに配信する、主構成情報、階層１の副構成情報、階層２の副構成情報・・階層Ｍの副構成情報を生成する（Ｓ４６）。具体的には、重要度が最も高いコンポーネントに関するcompタグが主構成情報に含まれ、重要度が相対的に低いコンポーネントに関するcompタグが、階層の値が相対的に大きい副構成情報に含まれるように、Ｍ＋１個の構成情報を生成する。これらはinsert要素またはreplace要素を副構成情報に含める実施形態２または３の参照方式を使って記述する。

Ｓ４６の後、メイン配信サーバ１００ｃに配信する主構成情報、階層１の副構成情報、階層２の副構成情報・・階層Ｎの副構成情報に対し、サブ配信サーバ１１０ｃに配信する主構成情報、階層１の副構成情報、階層２の副構成情報・・階層Ｍの副構成情報を参照するための外部参照ＵＲＬを追記する（Ｓ４７）。

Ｓ４７の後、配信制御部５１ｃは、Ｓ４７で生成したＮ＋１個の構成情報をメイン配信サーバ１００ｃに配信し（Ｓ４８）、Ｓ４６で生成したＭ＋１個の構成情報をサブ配信サーバ１１０ｃに配信して（Ｓ４９）、処理を終了する。

《コントロールサーバ５０ｃの動作の変形例》
コントロールサーバ５０ｃの動作の変形例について図３２を参照しながら説明する。

図３２は、コントロールサーバ５０ｃの変形例に係る動作を示すフローチャート図である。

図３２に示すように、最初に、コントロールサーバ５０ｃの配信制御部５１ｃは、サーバ記憶部１１から構成情報５３を読み出す（Ｓ５１）。

Ｓ５１の後、配信制御部５１ｃは、構成情報５３内の各comp要素について、comp要素に対応するコンポーネントの重要度を特定する（Ｓ５２）。

Ｓ５２の後、配信制御部５１ｃは、同一の重要度を持つコンポーネント群毎に、コンポーネント群を構成する各コンポーネントについて、コンポーネントを配信する配信サーバを特定する（Ｓ５３）。

具体的には、構成情報５３内に対応するcomp要素が含まれている全コンポーネント群のうち、最も重要度が高いグループに属するコンポーネント群の各コンポーネントについて、コンポーネントを格納しているか否かをメイン配信サーバ１００ｃおよびサブ配信サーバ１１０ｃに問い合わせる。さらに同様の処理を残りＮ回行う。すなわち、２番目に重要度が高いグループに属するコンポーネント群、…、最も重要度が低い（Ｎ＋１番目に重要度が高い）グループに属するコンポーネント群について、同様の処理を行う。

Ｓ５３の後、配信制御部５１ｃは、メイン配信サーバ１００ｃに配信する、主構成情報１７Ａ、および、サブ配信サーバ１１０ｃに配信する、主構成情報１７ａを生成する（Ｓ５４）。

具体的には、最も重要度が高いグループに属するコンポーネント群のうちメイン配信サーバが配信するコンポーネント群について、コンポーネント群に対応するcomp要素群と、最も重要度が高いグループに属するコンポーネント群のうちサブ配信サーバが配信するコンポーネント群について、コンポーネント群に対応するcomp要素群とから、主構成情報１７Ａ、および、主構成情報１７ａを生成した上で、主構成情報１７ａの参照先を示す外部参照ＵＲＬを含む主構成情報１７Ａを生成する。

Ｓ５４の後、配信制御部５１ｃは、メイン配信サーバ１００ｃに配信する、階層１の副構成情報１７Ｂ、および、サブ配信サーバ１１０ｃに配信する、階層１の構成情報１７ｂを生成する。以下同様に、メイン配信サーバ１００ｃに配信する、階層Ｎの副構成情報１７Ｂ、および、サブ配信サーバ１１０ｃに配信する、階層Ｎの構成情報１７ｂまでを生成する（Ｓ５５）。

具体的には、２番目に重要度が高いグループに属するコンポーネント群のうちメイン配信サーバが配信するコンポーネント群について、コンポーネント群に対応するcomp要素群と、２番目に重要度が高いグループに属するコンポーネント群のうちサブ配信サーバが配信するコンポーネント群について、コンポーネント群に対応するcomp要素群とから、階層１の副構成情報１７Ｂ、および、階層１の副構成情報１７ｂを生成した上で、階層１の副構成情報１７ｂの参照先を示す外部参照ＵＲＬを含む階層１の副構成情報１７ｂを生成する。

同様の処理によって、階層２〜階層Ｎの副構成情報１７Ｂ、１７ｂを生成する。

Ｓ５５の後、配信制御部５１ｃは、Ｓ５４、Ｓ５５で生成したＮ＋１個の構成情報をメイン配信サーバ１００ｃに配信し（Ｓ５６）、Ｓ５４、Ｓ５５で生成したＮ＋１個の構成情報をサブ配信サーバ１１０ｃに配信して（Ｓ５７）、処理を終了する。

以上、図３１、図３２で説明したコントロールサーバにおける構成情報２５の生成処理では、１つの配信サーバで配信されるコンポーネント間の関係をinsert要素またはreplace要素を副構成情報に含める実施形態２または３の参照方式を使って記述し、異なる配信サーバで配信されるコンポーネント間の関係を外部参照ＵＲＬを主構成情報に含める実施形態１の参照方式を使って記述するとした。反対に、１つの配信サーバで配信されるコンポーネント間の関係を外部参照ＵＲＬを主構成情報に含める実施形態１の参照方式を使って記述し、異なる配信サーバで配信されるコンポーネント間の関係をinsert要素またはreplace要素を副構成情報に含める実施形態２または３の参照方式を使って記述することも可能である。

《再生クライアント２ｃでの再生処理》
再生制御部２３ｃの説明からわかるように、再生クライアント２ｃは、メイン配信サーバ１００ｃから取得する主構成情報１７Ａ、メイン配信サーバ１００ｃから順次配信される階層１〜階層Ｎの副構成情報１７Ｂ、サブ配信サーバ１１０ｃから取得する主構成情報１７ａ、および、サブ配信サーバ１１０ｃから順次配信される階層１〜階層Ｍの副構成情報１７ｂに基づいて、メイン配信サーバ１００ｃ、サブ配信サーバ１１０ｃから配信されてくるコンポーネント群のうち再生すべきコンポーネントを再生することになる。

《コンテンツ送受信システム３００ｃの付記事項１》
Ｓ４５（Ｓ５３）の前までに、配信制御部５１ｃは、配信サーバ情報５２に基づいて、メイン配信サーバ１００ｃおよびサブ配信サーバ１１０ｃの管理主体が同一であるか否かを判定してもよい。

配信制御部５１ｃは、メイン配信サーバ１００ｃおよびサブ配信サーバ１１０ｃの管理主体が同一であると判定した場合には、Ｓ４７（Ｓ５４、Ｓ５５）において、メイン配信サーバ１００ｃに配信する構成情報にサブ配信サーバ１１０ｃに配信する構成情報に対する外部参照ＵＲＬを記述するのに代えて、サブ配信サーバ１１０ｃに配信する構成情報をinsert要素またはreplace要素を含む構成情報として生成してもよい。

また、Ｓ４５、Ｓ４６（Ｓ５４、Ｓ５５）において、メイン配信サーバ１００ｃに配信する主構成情報１７Ａ、及びサブ配信サーバ１１０ｃに配信する構成情報を、全て、外部参照ＵＲＬにより主構成情報、副構成情報を参照する構成情報を生成してもよい。

《コンテンツ送受信システム３００ｃの付記事項２》
配信サーバ情報５２には、各配信サーバについて、その配信サーバがメイン配信サーバの管理主体によって必須のサーバであると認定されている否かを示す認定情報が含まれていても良い。

この場合、Ｓ４６（Ｓ５５）の前までに、配信制御部５１ｃは、配信サーバ情報５２に基づいて、サブ配信サーバ１１０ｃが必須のサーバであると認定されているか否かを判定してもよい。

サブ配信サーバ１１０ｃが必須のサーバでなると判定した場合には、Ｓ４６（Ｓ５５）において、サブ配信サーバ１１０ｃに配信する構成情報として、外部参照ＵＲＬが含まれている主構成情報１７Ａ、および、外部参照ＵＲＬによって参照されるバージョン１〜バージョンＮの副構成情報１７Ｂを生成してもよい。

《コンテンツ送受信システム３００ｃの付記事項３》
Ｓ４３およびＳ５２では、配信制御部５１ｃは、実施形態１で説明した方法を用いて重要度を特定してもよい。

また、前述のように、構成情報５３内の各compタグの属性として、そのcompタグに対応するコンポーネントの重要度を表す属性が含まれていてもよいが、コンポーネントの重要度を示す情報が、そのコンポーネントのヘッダ部分に含まれていてもよい。そして、配信制御部５１ｃは、メイン配信サーバ１００およびサブ配信サーバ１１０の各配信サーバに対し、該配信サーバが格納している各コンポーネントの重要度を問い合わせることにより、各コンポーネントの重要度を特定してもよい。

《その他の付記事項》
構成情報２５とＭＭＴ−ＣＩとの対応関係を図３３に示しておく。なお、図３３に示したＭＭＴ−ＣＩのデータ構造は、本願出願時点における暫定的なものであることを述べておく。

図３３に示すように、ＭＭＴ−ＣＩのLoAタグは構成情報２５のcomponentsタグに対応し、ＭＭＴ−ＣＩのAIタグは構成情報２５のcompタグに対応する。また、ＭＭＴ−ＣＩのSTIAタグは構成情報２５のcompositionsタグに対応し、ＭＭＴ−ＣＩのparタグ、videoタグ、audioタグは、それぞれ、構成情報２５のparタグ、videoタグ、audioタグに対応する。また、ＭＭＴ−ＣＩのSceneタグは、構成情報２５のseqタグに類似する。

実施形態４または実施形態５に係るコンテンツ送受信システム３００ｂ（３００ｃ）では、コントロールサーバ５０（５０ｃ）を備える代わりに、メイン配信サーバに、コントロールサーバ５０（５０ｃ）の配信制御部５１（５１ｃ）を備えるとともに、メイン配信サーバのサーバ記憶部１１に配信サーバ情報５２を格納してもよい。すなわち、メイン配信サーバにコントロールサーバの機能を持たせてもよい。

（本発明の構成１）
以上の実施形態２〜５の説明からわかるように、本発明に係る配信装置は、コンテンツを構成する複数のコンポーネントの各々について該コンポーネントを特定する情報と該コンポーネントの再生態様を示す情報とを含む再生用メタデータから、更新可能な箇所が示されている被更新用メタデータを生成する第１生成手段と、
上記被更新用メタデータ内の上記更新可能な箇所の更新に用いる更新用情報であって、上記複数のコンポーネントの全部または一部を特定する情報と上記全部または一部の再生態様を示す情報とを含む更新用情報、を含む更新用メタデータを上記再生用メタデータから生成する第２生成手段と、
上記被更新用メタデータを配信する第１配信制御手段と、
上記更新用メタデータを配信する第２配信制御手段と、を備えていることが望ましい。

（本発明の構成２）
構成１に係る配信装置において、上記第２生成手段は互いに相異なる複数の上記更新用メタデータを生成し、上記第２配信制御手段は上記複数の更新用メタデータを１つずつ配信することが望ましい。

（本発明の構成３）
構成２に係る配信装置において、上記第２生成手段が生成する各更新用メタデータには、その更新用メタデータのバージョンを示すバージョン情報が含まれており、
上記第２配信制御手段は、上記バージョン情報が示すバージョンの小さい順（古い順）に、上記更新用メタデータを配信することが望ましい。

（本発明の構成４）
構成２に係る配信装置において、上記第２生成手段が生成する各更新用メタデータには、何回目の上記被更新用メタデータの更新時にその更新用メタデータを使用すべきであるかを示す情報が含まれており、
上記第２配信制御手段は、各更新用メタデータの当該情報に基づいて、より早い時期に上記被更新用メタデータの更新に使用すべき更新用メタデータをより早くに配信する、ことが望ましい。

（本発明の構成５）
構成１〜構成４に係る配信装置において、第１生成手段および第２生成手段の一方または両方は、配信装置自身に含まれていなくともよい。

（本発明の構成６）
本発明は、第１配信制御手段を備える第１の配信装置と、第２配信制御手段（構成１〜４に係る配信装置が備える第２配信制御手段のうちの任意の第２配信制御手段）を備える第２の配信装置とを含む配信システムとしても実現できる。

（本発明の構成７）
また、本発明に係る再生装置は、構成１〜構成５に係る配信装置または構成６に係る配信システムから配信される被更新用メタデータおよび更新用メタデータを取得する取得手段と、上記更新用メタデータ内の更新用メタデータを用いて、上記更新用メタデータ内の上記更新可能な箇所を更新する更新手段と、を備えている。

（本発明の構成８）
構成７に係る再生装置において、上記取得手段は、構成４に係る配信装置から上記複数の更新用メタデータを取得するように構成されており、上記更新手段は、１〜Ｎ（Ｎ：任意の整数）までの各ｉについて、ｉ回目の上記被更新用メタデータの更新時に、ｉ回目の上記被更新用メタデータの更新時に使用すべきであることを示す情報を含む更新用メタデータを用いて、上記被更新用メタデータを更新する、ことが望ましい。

（本発明の構成９）
構成７に係る再生装置において、上記取得手段は、構成３に係る配信装置から上記複数の更新用メタデータを取得するように構成されており、上記更新手段は、過去に上記被更新用メタデータの更新に上記更新用メタデータを使用した場合には、上記バージョン情報に基づいて当該更新用メタデータのバージョンよりも新しいバージョンの更新用メタデータのみを用いて上記被更新用メタデータを更新する、ことが望ましい。

《ソフトウェアによる構成例》
最後に、配信サーバ１、メイン配信サーバ１００（１００’、１００ａ、１００ｃ）、サブ配信サーバ１１０（１１０’、１１０ａ、１１０ｃ）および再生クライアント２（２’、２ｃ）、コントロールサーバ（５０、５０ｃ）の各ブロック、特にサーバ制御部１０およびクライアント制御部２０は、集積回路（ＩＣチップ）上に形成された論理回路によってハードウェア的に実現してもよいし、ＣＰＵ（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）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。

〔まとめ〕
上記の課題を解決するために、本発明の配信装置は、コンテンツを構成する複数のコンポーネントをそれぞれ特定する情報と、該コンポーネントの再生態様を示す情報とを少なくとも含む構成情報を取得する取得手段を備えた配信装置であって、上記取得手段が取得した構成情報に含まれる情報の一部を参照形式に書き換えて参照形式構成情報を生成すると共に、参照形式に書き換えられた情報を含む参照先構成情報を生成する構成情報生成手段と、上記構成情報生成手段が生成した上記参照形式構成情報と上記参照先構成情報とを配信する配信制御手段とを備えていることを特徴としている。

また、本発明の配信方法は、上記の課題を解決するために、コンテンツを構成する複数のコンポーネントをそれぞれ特定する情報と、該コンポーネントの再生態様を示す情報とを少なくとも含む構成情報を取得する配信装置による配信方法であって、取得した構成情報に含まれる情報の一部を参照形式に書き換えて参照形式構成情報を生成すると共に、参照形式に書き換えられた情報を含む参照先構成情報を生成する構成情報生成ステップと、上記構成情報生成ステップで生成した上記参照形式構成情報と上記参照先構成情報とを配信する配信制御ステップとを含むことを特徴としている。

上記の構成によれば、取得した構成情報に含まれる情報の一部を参照形式に書き換えて参照形式構成情報を生成すると共に、参照形式に書き換えられた情報を含む参照先構成情報を生成する。そして、生成した参照形式構成情報と参照先構成情報とを配信する。

このように、取得した構成情報から生成した参照形式構成情報と参照先構成情報とを配信することにより、取得した構成情報をそのまま配信するよりも、全体として効率のよい配信が可能になる。参照形式構成情報と参照先構成情報との配信タイミングをずらしたり、配信頻度を変えたり、伝送路を変えたりすることができるためである。

また、上記の構成によれば、参照形式構成情報では、取得した構成情報に含まれる情報の一部を参照形式に書き換えているが、参照形式に書き換えられた情報は、参照先構成情報に含まれている。このため、参照形式構成情報と参照先構成情報とを取得することによって、取得した構成情報を用いた場合と同様にしてコンテンツを再生することができる。

また、上記構成情報生成手段は、上記取得手段が取得した構成情報に含まれる情報のうち、上記コンポーネントを特定する情報および上記再生態様を示す情報の少なくとも一方を参照形式に書き換えて上記参照形式構成情報を生成し、上記配信制御手段は、上記参照形式構成情報を上記参照先構成情報よりも低い頻度で配信することが好ましい。

上記の構成によれば、取得した構成情報に含まれる情報のうち、コンテンツを構成するコンポーネントを特定する情報およびコンポーネントの再生態様を示す情報の少なくとも一方を参照形式に書き換えて参照形式構成情報を生成する。そして、参照形式構成情報を参照先構成情報よりも低い頻度で配信する。

ここで、コンテンツを構成するコンポーネントやその再生態様は、一般的に変更の頻度が高い。このため、取得した構成情報に含まれる情報のうち、コンテンツを構成するコンポーネントやその再生態様を参照形式とした参照形式構成情報は、参照先構成情報よりも更新頻度が高くなると考えられる。

すなわち、上記の構成によれば、相対的に変更頻度が低いと予想される参照形式構成情報の配信頻度を低くすることによって、配信データ量を削減している。また、相対的に変更頻度が高いと予想される参照先構成情報については、参照形式構成情報よりも配信頻度を高くすることによって、部分構成の変更を短時間で反映させることを可能にしている。

また、上記構成情報生成手段は、上記取得手段が取得した構成情報に含まれる情報のうち、相対的に重要度の高いコンポーネントに関する情報と、相対的に重要度の低いコンポーネントに関する情報とを参照形式に書き換えて参照形式構成情報を生成すると共に、相対的に重要度の高いコンポーネントに関する上記情報を含む参照先構成情報と、相対的に重要度の低い上記情報を含む副参照先構成情報とを生成し、上記配信制御手段は、上記副参照先構成情報を上記参照先構成情報よりも低い頻度で配信することが好ましい。

上記の構成によれば、取得した構成情報に含まれる情報のうち、相対的に重要度の高いコンポーネントに関する情報と、相対的に重要度の低いコンポーネントに関する情報とを参照形式に書き換えて参照形式構成情報を生成する。また、相対的に重要度の高いコンポーネントに関する情報を含む参照先構成情報と、相対的に重要度の低いコンポーネントに関する情報を含む副参照先構成情報とを生成する。そして、副参照先構成情報を参照先構成情報よりも低い頻度で配信する。

ここで、相対的に重要度の高いコンポーネントに関する情報を含む参照先構成情報は、当該コンポーネントの再生開始までの期間を短縮するために、できるだけ高頻度で配信することが望ましい。一方、相対的に重要度の低いコンポーネントに関する情報を含む副参照先構成情報は、配信頻度を低くしても問題が少ないと考えられる。

すなわち、上記の構成によれば、参照先構成情報と副参照先構成情報とを併用し、配信頻度を低くしても問題が少ないと考えられる副参照先構成情報の配信頻度を低くすることによって、配信データ量を削減している。また、高頻度で配信することが望ましい参照先構成情報については、副参照先構成情報よりも配信頻度を高くすることによって、即時再生の必要性が高いまたは再生が必須のコンポーネント速やかに再生することを可能にしている。

なお、相対的に重要度の高いコンポーネントとは、例えば即時再生の必要性が高いコンポーネントや、再生が必須のコンポーネントである。また、相対的に重要度の低いコンポーネントとは、例えば即時再生の必要性が低いコンポーネントや、再生が任意のコンポーネントである。

例えば、コンテンツがビデオコンポーネント、オーディオコンポーネント、およびビデオに重畳するテキストコンポーネントで構成されている場合、ビデオコンポーネントおよびオーディオコンポーネントが、即時再生の必要性が高いコンポーネントとなる。

そして、即時再生の必要性が高いコンポーネントは、コンポーネントの属性（ビデオ、オーディオ、テキスト等）を示す属性情報から判断することができる。また、何れの属性のコンポーネントを即時再生の必要性が高いコンポーネントとするかは予め決めておけばよい。また、再生が必須のコンポーネントと、再生が任意のコンポーネントは、取得した構成情報におけるコンポーネントの再生態様等から判断することが可能である。

また、上記配信制御手段は、上記参照形式構成情報を格納するペイロードのヘッダに、参照形式構成情報が格納されていることを示す情報を記述すると共に、上記参照先構成情報を格納するペイロードのヘッダに、参照先構成情報が格納されていることを示す情報を記述することが好ましい。

上記の構成によれば、参照形式構成情報を格納するペイロードのヘッダに、参照形式構成情報が格納されていることを示す情報を記述すると共に、参照先構成情報を格納するペイロードのヘッダに、参照先構成情報が格納されていることを示す情報を記述する。

これにより、このペイロードを受信した再生装置では、ペイロードに格納された情報を解析することなく、そのヘッダを参照することで、参照形式構成情報および参照先構成情報が格納されたペイロードを特定することができる。つまり、上記の構成によれば、参照形式構成情報および参照先構成情報を再生装置に容易に取得させることができる。

また、上記構成情報生成手段は、上記参照形式構成情報で参照される情報を含む参照先構成情報を生成すると共に、上記参照形式構成情報で参照され、上記取得手段が取得した構成情報に含まれる情報のうち、上記参照先構成情報に含まれる情報とは異なる情報を含む別版参照先構成情報を生成し、上記配信制御手段は、上記参照先構成情報と、上記別版参照先構成情報とを異なるタイミングで配信することが好ましい。

上記の構成によれば、参照形式構成情報で参照される情報を含む参照先構成情報を生成すると共に、上記参照形式構成情報で参照され、取得した構成情報に含まれる情報のうち、上記参照先構成情報に含まれる情報とは異なる情報を含む別版参照先構成情報を生成する。そして、参照先構成情報と別版参照先構成情報とを異なるタイミングで配信する。

したがって、再生装置は、参照先構成情報を受信したときには、参照形式構成情報で該参照先構成情報を参照してコンテンツを再生し、別版参照先構成情報を受信したときには、参照形式構成情報で該別版参照先構成情報を参照してコンテンツを再生する。

すなわち、上記の構成によれば、参照形式構成情報を変更することなく、再生装置におけるコンテンツの再生態様（使用コンポーネントおよび各コンポーネントの再生態様）を変えさせることができる。

また、上記配信制御手段は、上記別版参照先構成情報を、該別版参照先構成情報に含まれる情報を用いて再生すべきコンポーネントと共に配信することが好ましい。

上記の構成によれば、別版参照先構成情報を、該別版参照先構成情報に含まれる情報を用いて再生すべきコンポーネントと共に配信するので、このコンポーネントをスムーズに再生させることができる。また、別版参照先構成情報に含まれる情報を用いて再生すべきコンポーネントを、誤って参照先構成情報に含まれる情報を用いて再生してしまうことを防ぐ効果も期待できる。

そして、上記の構成によれば、コンテンツの急な構成変更（緊急警報放送など）が必要となった場合に、変更先のコンポーネントおよびその再生態様を記述した別版参照情報を、当該変更先のコンポーネントと共に配信することによって、迅速な変更が可能となる。なお、オンデマンドで構成情報を配信する場合、コンポーネントの配信と構成情報の配信とが非同期となるため、このような急な構成変更に対応することは困難である。

また、上記参照先構成情報は、上記コンポーネントの再生態様を示す情報を含み、上記別版参照先構成情報は、上記参照先構成情報とは異なる再生態様を示す情報を含み、上記配信制御手段は、上記参照先構成情報を配信した後、上記コンポーネントの再生態様を変更すべきタイミングで、上記別版参照先構成情報を配信することが好ましい。

上記の構成によれば、参照先構成情報は、コンポーネントの再生態様を示す情報を含み、別版参照先構成情報は、参照先構成情報とは異なる再生態様を示す情報を含む。そして、参照先構成情報を配信した後、コンポーネントの再生態様を変更すべきタイミングで、別版参照先構成情報を配信する。

したがって、参照形式構成情報を変更することなく、再生装置におけるコンテンツの再生態様（使用コンポーネントおよび各コンポーネントの再生態様）を、所定のタイミングで変えさせることができる。

また、上記複数のコンポーネントには、再生期間の異なるコンポーネントが含まれており、上記構成情報生成手段は、上記再生期間の１つで再生されるコンポーネントに関する情報を含む参照先構成情報を生成すると共に、他の再生期間で再生されるコンポーネントに関する情報を含む別版参照先構成情報を生成し、上記配信制御手段は、上記再生期間に応じて、上記参照先構成情報または上記別版参照先構成情報を配信することが好ましい。

上記の構成によれば、コンテンツを構成する複数のコンポーネントには、再生期間の異なるコンポーネントが含まれている。また、上記再生期間の１つで再生されるコンポーネントに関する情報を含む参照先構成情報を生成すると共に、他の再生期間で再生されるコンポーネントに関する情報を含む別版参照先構成情報を生成する。そして、再生期間に応じて、参照先構成情報または別版参照先構成情報を配信する。

したがって、ある再生期間に使用されることのない情報を、その再生期間に配信せずに済むため、配信するデータ量を大きく削減することができる。なお、コンポーネントに関する情報とは、そのコンポーネントの再生に必要な情報であり、例えば該コンポーネント特定する情報およびその再生態様を示す情報である。

また、上記配信制御手段は、上記別版参照先構成情報を格納するペイロードのヘッダに、別版参照先構成情報が格納されていることを示す情報を記述することが好ましい。

上記の構成によれば、別版参照先構成情報を格納するペイロードのヘッダに、別版参照先構成情報が格納されていることを示す情報を記述する。これにより、このペイロードを受信した再生装置では、ペイロードに格納された情報を解析することなく、そのヘッダを参照することで、別版参照先構成情報を受信したことを特定することができる。

つまり、上記の構成によれば、別版参照先構成情報を受信したことを再生装置に容易に認識させ、別版参照先構成情報を参照した再生をスムーズに開始させることができる。

また、上記構成情報生成手段は、上記参照先構成情報の取得先を示す取得先情報を含む上記参照形式構成情報を生成することが好ましい。

上記の構成によれば、参照先構成情報の取得先を示す取得先情報を含む参照形式構成情報を生成するので、これを受信した再生装置は、取得先情報が示す取得先にアクセスすることによって、即座に参照先構成情報を取得することができる。

つまり、上記の構成によれば、参照先構成情報の受信待ちによって、再生開始が遅延することを防ぐことができる。

また、上記配信制御手段は、上記参照先構成情報を、上記参照形式構成情報を配信する伝送路とは異なる伝送路で配信することが好ましい。

上記の構成によれば、参照先構成情報を、参照形式構成情報を配信する伝送路とは異なる伝送路で配信するので、取得した構成情報をそのまま配信する場合と比べて、各伝送路における伝送データ量を削減することができる。

また、上記構成情報生成手段は、複数の上記コンポーネントのうち、再生が任意のコンポーネントを再生するための情報を参照形式とし、再生が必須の上記コンポーネントを再生するための情報を含む上記参照形式構成情報を生成すると共に、再生が任意の上記コンポーネントを再生するための情報を含む上記参照先構成情報を生成し、上記配信制御手段は、再生が必須の上記コンポーネントと共に上記参照形式構成情報を配信し、再生が任意の上記コンポーネントと共に上記参照先構成情報を配信することが好ましい。

上記の構成によれば、複数の上記コンポーネントのうち、再生が任意のコンポーネントを再生するための情報を参照形式とし、再生が必須の上記コンポーネントを再生するための情報を含む参照形式構成情報を生成する。また、再生が任意の上記コンポーネントを再生するための情報を含む参照先構成情報を生成する。そして、再生が必須のコンポーネントと共に参照形式構成情報を配信し、再生が任意のコンポーネントと共に参照先構成情報を配信する。また、これらの配信に用いられる伝送路は互いに異なっている。

したがって、再生装置は、再生が任意のコンポーネントを再生しない場合、１つの伝送路で配信される参照形式構成情報と、再生が必須のコンポーネントとを受信することにより、再生が必須のコンポーネントの再生を開始することができる。

つまり、上記の構成によれば、参照先構成情報を受信していない再生装置に再生が必須のコンポーネントの再生を開始させることができる。また、再生が必須のコンポーネントを再生する場合、再生が任意のコンポーネントと参照先構成情報とを配信する伝送路は使用の必要がないため、使用する伝送路のリソースを大幅に削減することも可能になる。

また、上記取得手段は、第１のコンテンツに対応する第１の構成情報と、第２のコンテンツに対応する第２の構成情報とを取得し、上記構成情報生成手段は、上記取得手段が取得した第１および第２の構成情報に共通して含まれる情報の少なくとも一部を参照形式に書き換えて、第１および第２の構成情報にそれぞれ対応する第１および第２の参照形式構成情報を生成すると共に、第１および第２の構成情報に共通して含まれる上記情報を含む参照先構成情報を生成することが好ましい。

上記の構成によれば、第１のコンテンツに対応する第１の構成情報と、第２のコンテンツに対応する第２の構成情報とを取得する。また、取得した第１および第２の構成情報に共通して含まれる情報の少なくとも一部を参照形式に書き換えて、第１および第２の構成情報にそれぞれ対応する第１および第２の参照形式構成情報を生成する。そして、第１および第２の構成情報に共通して含まれる上記情報を含む参照先構成情報を生成する。

これにより、参照先構成情報が第１および第２の参照形式構成情報で共用されるため、第１および第２の構成情報を配信する場合と比べて、配信データ量を削減することができる。

また、請求項１から１３の何れか１項に記載の配信装置が配信する参照形式構成情報および参照先構成情報を用いて上記コンテンツを再生する再生装置であれば、効率よく配信された参照形式構成情報および参照先構成情報に基づく再生が可能になる。

また、本発明のデータ構造は、上記課題を解決するために、コンテンツを構成する複数のコンポーネントをそれぞれ特定する情報と、該コンポーネントの再生態様を示す情報とを少なくとも含み、上記コンテンツの再生に用いられる構成情報のデータ構造であって、コンテンツを構成する複数のコンポーネントをそれぞれ特定する上記情報および該コンポーネントの再生態様を示す上記情報の一部が参照形式で記述された参照形式構成情報と、該参照形式構成情報で参照される情報を含む参照先構成情報とを含むことを特徴としている。

上記のデータ構造によれば、コンテンツを構成する複数のコンポーネントをそれぞれ特定する情報および該コンポーネントの再生態様を示す情報の一部が参照形式で記述された参照形式構成情報と、該参照形式構成情報で参照される情報を含む参照先構成情報とを含む。

よって、コンテンツを構成する複数のコンポーネントをそれぞれ特定する情報と、該コンポーネントの再生態様を示す情報とを含む構成情報をそのまま配信するよりも、全体として効率のよい配信が可能になる。

また、上記データ構造では、上記参照形式構成情報を格納するペイロードのヘッダに、参照形式構成情報が格納されていることを示す情報が記述され、上記参照先構成情報を格納するペイロードのヘッダに、参照先構成情報が格納されていることを示す情報が記述されていることが好ましい。

これにより、このペイロードを受信した再生装置では、ペイロードに格納された情報を解析することなく、そのヘッダを参照することで、参照形式構成情報および参照先構成情報が格納されたペイロードを特定することができる。つまり、上記の構成によれば、参照形式構成情報および参照先構成情報を再生装置に容易に取得させることができる。

また、上記データ構造では、上記構成情報は、上記参照形式構成情報で参照され、上記参照先構成情報に含まれる情報とは異なる情報を含む別版参照先構成情報をさらに含み、上記別版参照先構成情報を格納するペイロードのヘッダに、別版参照先構成情報が格納されていることを示す情報が記述されていることが好ましい。

上記の構成によれば、別版参照先構成情報を受信したことを再生装置に容易に認識させ、別版参照先構成情報を参照した再生をスムーズに開始させることができる。

なお、上記配信装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記配信装置の構成情報生成手段および配信制御手段として動作させることにより、上記配信装置をコンピュータにて実現させる制御プログラム、及びそれを記録したコンピュータ読み取り可能な記録媒体も本発明の範疇に入る。

本発明は、複数のコンポーネントで構成されるコンテンツの配信等に利用することができる。

１ 配信サーバ（配信装置）
１４ 構成情報解析部（取得手段）
１５ 構成情報生成部（構成情報生成手段）
１６ 配信制御部（配信制御手段）
１７ 構成情報
１７ａ 構成情報（被更新用メタデータ）
１７ｂ 構成情報（更新用メタデータ）
２５ 構成情報（被更新用メタデータ）
１８ コンテンツ
１９ 設定情報
２ 再生クライアント（再生装置）
２２ クライアント通信部（取得手段）
２３ 再生制御部（取得手段、更新手段）
５０ コントロールサーバ（配信装置）
５１ 配信制御部（第１生成手段、第２生成手段、第１配信制御手段、第２配信
制御手段）
５３ 構成情報（再生用メタデータ）
１００ メイン配信サーバ（第１の配信装置）
１００’ メイン配信サーバ（配信装置）
１００ｃ メイン配信サーバ（配信装置）
１１０ サブ配信サーバ（第２の配信装置）
１１０ｃ サブ配信サーバ（配信装置、第２の配信装置）
１０１６ 配信制御部（第１配信制御手段、第２配信制御手段）
１１１６ 配信制御部（第２配信制御手段）
１１１６ｃ 配信制御部（第１配信制御手段、第２配信制御手段）

Claims (2)

1. 複数のコンポーネントから構成されるコンテンツに関する情報である構成情報に基づき、該コンテンツを再生する再生装置であって、
   一つの主構成情報と一つ以上の副構成情報とから構成される上記構成情報を解析する構成情報解析手段と、
   上記一つの主構成情報と上記一つ以上の副構成情報に基づき、上記コンテンツを再生する再生手段と、を備え、
   上記複数のコンポーネントのおのおのは識別子を有し、
   上記一つの主構成情報と上記一つ以上の副構成情報のおのおのは、処理を行う順序を表す情報と、各構成情報のバージョン情報と、上記複数のコンポーネントのうち所定のコンポーネントを示す情報と、再生態様に関する情報と、コンポーネントの取得先情報と、を含むことを特徴とする再生装置。
2. 複数のコンポーネントから構成されるコンテンツに関する情報である構成情報に基づき、該コンテンツを再生する再生方法であって、
   一つの主構成情報と一つ以上の副構成情報とから構成される上記構成情報を解析する構成情報解析ステップと、
   上記一つの主構成情報と上記一つ以上の副構成情報に基づき、上記コンテンツを再生する再生ステップと、を含み、
   上記複数のコンポーネントのおのおのは識別子を有し、
   上記一つの主構成情報と上記一つ以上の副構成情報のおのおのは、処理を行う順序を表す情報と、各構成情報のバージョン情報と、上記複数のコンポーネントのうち所定のコンポーネントを示す情報と、再生形態に関する情報と、コンポーネントの取得先情報と、を含むことを特徴とする再生方法。

Images