(57)【要約】【課題】コンテンツを構成する各コンポーネントの配信経路を容易に決定する。【解決手段】二次配信サーバ２は、各コンポーネント６０の配信経路を特定するための経路情報を含むコンポーネント管理情報６１を用いて、各コンポーネント６０の配信経路を決定する経路決定部５２と、経路決定部５２が決定した配信経路で各コンポーネント６０を配信する配信制御部５１とを備えている。【選択図】図１
2014038581.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンポーネントで構成されるコンテンツを配信する配信装置であって、
コンポーネントの配信経路を特定するための経路情報が各コンポーネントに対応付けられた対応情報を用いて、各コンポーネントの配信経路を決定する経路決定手段と、
上記経路決定手段が決定した配信経路で各コンポーネントを配信する配信制御手段と、を備えていることを特徴とする配信装置。
【請求項２】
上記コンポーネントおよび上記対応情報を受信する受信部を備え、
上記経路決定手段は、上記受信部が受信した対応情報を用いて、上記受信部が受信したコンポーネントの配信経路を決定し、
上記配信制御手段は、上記経路決定手段が決定した配信経路で、上記受信部が受信したコンポーネントを配信することを特徴とする請求項１に記載の配信装置。
【請求項３】
上記対応情報は、複数のコンポーネントからなるグループに対して経路情報が対応付けられたものであり、
上記経路決定手段は、同一グループに属する各コンポーネントの配信経路を、該グループに対して対応付けられている経路情報を用いて決定することを特徴とする請求項１または２に記載の配信装置。
【請求項４】
各コンポーネントに経路情報を対応付けて、上記対応情報とは異なる二次対応情報を生成する二次対応情報生成手段を備えていることを特徴とする請求項１から３の何れか１項に記載の配信装置。
【請求項５】
上記二次対応情報生成手段は、上記対応情報に含まれる経路情報のうち、自装置が使用できない配信経路を示す経路情報を、自装置が使用できる配信経路に変更して、上記二次対応情報を生成することを特徴とする請求項４に記載の配信装置。
【請求項６】
上記コンポーネントおよび上記対応情報を受信する受信部と、
上記受信部が受信した上記対応情報において、経路情報が対応付けられたコンポーネントに対してさらに経路情報を対応付ける対応情報更新手段とを備えていることを特徴とする請求項１から５の何れか１項に記載の配信装置。
【請求項７】
上記コンポーネントおよび上記対応情報を受信する受信部と、
上記経路決定手段が決定した配信経路によって上記コンポーネントを取得するための取得先情報を生成する取得先情報生成手段と、
上記取得先情報生成手段が生成した上記取得先情報を配信する取得先情報配信手段とを備えていることを特徴とする請求項１から６の何れか１項に記載の配信装置。
【請求項８】
上記取得先情報生成手段は、上記受信部が、上記コンポーネントと共に該コンポーネントを他の装置から取得するための他装置取得先情報を受信した場合に、上記経路決定手段が決定した配信経路によって当該コンポーネントを取得するための取得先情報を生成することを特徴とする請求項７に記載の配信装置。
【請求項９】
上記取得先情報生成手段は、上記受信部が、上記コンポーネントと共に該コンポーネントを他の装置から取得するための他装置取得先情報を受信した場合に、受信した他装置取得先情報が示す取得先または上記経路決定手段が決定した配信経路によって当該コンポーネントを取得するための取得先情報を生成することを特徴とする請求項７に記載の配信装置。
【請求項１０】
コンテンツを構成する各コンポーネントについて、該コンポーネントの配信経路を特定するための経路情報を決定する経路情報決定手段と、
上記経路情報決定手段が決定した経路情報とコンポーネントとを対応付けて対応情報を生成する対応情報生成手段と、を備えていることを特徴とする対応情報生成装置。
【請求項１１】
上記経路情報決定手段は、上記各コンポーネントの属性を示す属性情報と、経路情報毎に予め定められた判定基準とを参照し、上記属性情報が上記判定基準を満たすコンポーネントについて、当該判定基準に対応する経路情報を、当該コンポーネントの経路情報として決定することを特徴とする請求項１０に記載の対応情報生成装置。
【請求項１２】
上記対応情報生成手段は、上記経路情報決定手段が決定した経路情報が同一であるコンポーネントを１つのグループとして、当該グループに対して経路情報を対応付けることを特徴とする請求項１０または１１に記載の対応情報生成装置。
【請求項１３】
複数のコンポーネントで構成されるコンテンツを配信する配信装置による配信方法であって、
コンポーネントの配信経路を特定するための経路情報が各コンポーネントに対応付けられた対応情報を用いて、各コンポーネントの配信経路を決定する経路決定ステップと、
上記経路決定ステップにて決定した配信経路で各コンポーネントを配信する配信制御ステップと、を含むことを特徴とする配信方法。
【請求項１４】
対応情報生成装置による対応情報生成方法であって、
コンテンツを構成する各コンポーネントについて、該コンポーネントの配信経路を特定するための経路情報を決定する経路情報決定ステップと、
上記経路情報決定ステップにて決定した経路情報とコンポーネントとを対応付けて対応情報を生成する対応情報生成ステップと、を含むことを特徴とする対応情報生成方法。
【請求項１５】
請求項１から９の何れか１項に記載の配信装置を動作させるための制御プログラムであって、コンピュータを上記各手段として機能させるための制御プログラム。
【請求項１６】
請求項１０から１２の何れか１項に記載の対応情報生成装置を動作させるための制御プログラムであって、コンピュータを上記各手段として機能させるための制御プログラム。
【請求項１７】
請求項１５または１６に記載の制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチコンポーネントコンテンツのハイブリッド配信に関し、より詳細にはハイブリッド配信するコンポーネントの配信経路の決定に関する。
【背景技術】
【０００２】
従来から、コンテンツを複数の性質の異なるネットワークを使って配信する「ハイブリッド配信」が知られている（例えば下記の特許文献１）。また、ハイブリッド配信の１つとして、複数の性質の異なるコンポーネントからなる「マルチコンポーネントコンテンツ」について、各コンポーネントを複数の性質の異なる配信経路で配信するといったマルチコンポーネントコンテンツのハイブリッド配信も注目されつつある。
【０００３】
マルチコンポーネントコンテンツのハイブリッド配信を行う場合、コンポーネントの性質（例えばコンポーネントのメディア種別や内容）に応じて、適した配信経路が異なるため、コンポーネント毎に適切な配信経路を決定する必要がある。
【０００４】
例えば、容量の大きいコンポーネントや、クライアント毎に配信の中身が同一のコンポーネントは、片方向、一斉同報配信（例えば放送）により配信することが望ましい。一方、容量の小さいコンポーネントや、クライアント毎に配信の中身が変わるコンポーネントは、双方向、要求応答型配信である通信により、ユニキャスト配信することが望ましい。
【０００５】
このため、コンテンツの配信経路は、その配信者（コンテンツ制作者）によって厳密にコントロールされている。これについて、図１５に基づいて説明する。図１５は従来の配信システムを構成する一次配信サーバ１００、１００’、１００”、およびクライアント１０１の要部構成を示すブロック図である。
【０００６】
一次配信サーバ１００は、コンテンツを生成して配信するサーバであり、メディア生成部１１０、フォーマット部１１１、および送信部１１２を備えている。
【０００７】
メディア生成部１１０は、コンテンツのメディアを生成する。具体的には、メディア生成部１１０は、コンテンツの製作者（Creator）が入力したコンテンツに対応するメディア（ビデオデータ、オーディオデータなど）を生成する。
【０００８】
フォーマット部１１１は、メディア生成部１１０が生成したメディアをフォーマット化してコンポーネントを生成する。そして、送信部１１２は、フォーマット部１１１が生成したコンポーネントを配信する。
【０００９】
また、一次配信サーバ１００’および１００”も、一次配信サーバ１００と同様の機能を果たすものであり、同様の構成を備えている。すなわち、一次配信サーバ１００’では、メディア生成部１１０’が生成したメディアをフォーマット部１１１’がフォーマット化（配信フォーマットに格納、あるいは配信フォーマットを形成）し、送信部１１２’から配信する。また、一次配信サーバ１００”では、メディア生成部１１０”が生成したメディアをフォーマット部１１１”がフォーマット化し、送信部１１２”から配信する。
【００１０】
一次配信サーバ１００、１００’、１００”の相違点の１つは、コンポーネントの配信経路である。つまり、送信部１１２、１１２’、１１２”による配信経路はそれぞれ異なっている。例えば、送信部１１２は放送経路により配信を行い、送信部１１２’はマルチキャストが可能な通信経路により配信を行い、送信部１１２”はユニキャストのみ可能な通信経路により配信を行うものであってもよい。なお、放送経路とは、放送波により配信を行う経路であり、通信経路とは通信によりインターネット等を介して配信を行う経路である。
【００１１】
また、一次配信サーバ１００、１００’、１００”の他の相違点は、配信するコンポーネントである。すなわち、一次配信サーバ１００、１００’、１００”がそれぞれ配信するコンポーネントは、これを組み合せることによって１つのコンテンツとなるものである。言い換えれば、一次配信サーバ１００、１００’、１００”は、１つのコンテンツを構成するコンポーネントをそれぞれ配信する。
【００１２】
このように、一次配信サーバ１００、１００’、１００”は、それぞれが生成したコンポーネントを、それぞれが有する送信部１１２、１１２’、１１２”によって配信する。つまり、一次配信サーバ１００、１００’、１００”によって、ハイブリッド配信がなされる。
【００１３】
なお、１つのサーバでハイブリッド配信を行ってもよく、この場合のサーバは、メディア生成部１１０、１１０’、１１０”、フォーマット部１１１、１１１’、１１１”、および送信部１１２、１１２’、１１２”を備えた構成となる。
【００１４】
そして、フォーマット部１１１が生成したコンポーネントは送信部１１２により配信することが、例えばコンテンツ製作者等によって予め決められる。同様に、フォーマット部１１１’が生成したコンポーネントは送信部１１２’により配信すること、およびフォーマット部１１１”が生成したコンポーネントは送信部１１２”により配信することが予め決められる。
【００１５】
クライアント１０１は、このような複数の配信経路で配信されるコンポーネント（ハイブリッド配信コンポーネント）を受信し、これらを合成して表示する。図示のように、クライアント１０１は、第１受信部１２０、第２受信部１２０’、第３受信部１２０”、第１メディア復元部１２１、第２メディア復元部１２１’、第３メディア復元部１２１”、および合成・表示部１２２を備えている。
【００１６】
第１受信部１２０は、一次配信サーバ１００の送信部１１２が送信するコンポーネントを受信する。同様に、第２受信部１２０’は一次配信サーバ１００’の送信部１１２’が送信するコンポーネントを受信し、第３受信部１２０”は、一次配信サーバ１００”の送信部１１２”が送信するコンポーネントを受信する。
【００１７】
第１メディア復元部１２１は、第１受信部１２０が受信したコンポーネントをメディアに復元する。同様に、第２メディア復元部１２１’は、第１受信部１２０’が受信したコンポーネントをメディアに復元し、第３メディア復元部１２１”は第１受信部１２０”が受信したコンポーネントをメディアに復元する。
【００１８】
合成・表示部１２２は、第１〜第３メディア復元部１２１、１２１’、１２１”が復元したメディアを合成し、表示する。これにより、ハイブリッド配信されたコンポーネントが１つのコンテンツとしてユーザに提示される。
【００１９】
以上のように、従来は、メディアの生成からコンポーネントの配信までを１つのサーバで管理しており、コンポーネントの配信経路はコンテンツの製作者等によって一義的に決定される。そして、これにより、コンテンツの製作者の意図に沿った配信経路による配信が実現されていた。
【先行技術文献】
【特許文献】
【００２０】
【特許文献１】特開平１０−１７３６１２号公報（１９９８年６月２６日公開）
【発明の概要】
【発明が解決しようとする課題】
【００２１】
ここで、従来は、上記のようなマルチコンポーネントコンテンツを、コンテンツ制作者ではないサーバから配信することは想定されていなかった。このため、コンテンツ制作者ではないサーバが、コンテンツを構成する各コンポーネントを適切な配信経路で配信することが困難であった。
【００２２】
つまり、上記のようなマルチコンポーネントコンテンツが、配信後もコンポーネントの状態のまま（フォーマットされた状態のまま）管理され、コンテンツ制作者ではないサーバが、マルチコンポーネントコンテンツを利用する場合がある。このとき、コンテンツ製作者ではないサーバは、コンテンツをコンポーネント単位で取り扱う必要がある。
【００２３】
しかし、コンテンツ制作者ではないサーバは、マルチコンポーネントコンテンツのコンポーネント毎の適切な配信経路を知らない。また、このサーバは、コンポーネントの中身も知らない。特に、従来のアーカイブ、配信済コンポーネントの二次配信サーバ等では、このような情報を取得する手立てがなく、コンポーネントの配信経路を特定するための手がかりが全く存在しなかった。
【００２４】
また、コンポーネントを解析する等により、コンポーネントに対応するメディアの情報などが判明したとしても、コンポーネントの中身と適当な配信経路とが一意にリンクするものではない。このため、適切な配信経路を決定するためには、サーバでのそれなりの判断が必要となる。そして、コンポーネント毎にこのような判断を行った場合、配信までに要する時間が長大化してしまう。
【００２５】
このように、従来技術では、複数のコンポーネントからなるコンテンツを配信するサーバ（配信装置）が各コンポーネントの適切な配信経路を判断することが極めて困難であるという問題がある。
【００２６】
これは、将来、マルチコンポーネントコンテンツが、アーカイブや二次配信サーバに登録され、任意のサーバがそれらを配信するといった状況が到来したときに、重大な問題となると考えられる。
【００２７】
本発明は、上記の問題点に鑑みてなされたものであり、その目的は、コンテンツを構成する各コンポーネントの配信経路を容易に決定することができる配信装置等を提供することにある。
【課題を解決するための手段】
【００２８】
上記の課題を解決するために、本発明の配信装置は、複数のコンポーネントで構成されるコンテンツを配信する配信装置であって、コンポーネントの配信経路を特定するための経路情報が各コンポーネントに対応付けられた対応情報を用いて、各コンポーネントの配信経路を決定する経路決定手段と、上記経路決定手段が決定した配信経路で各コンポーネントを配信する配信制御手段と、を備えていることを特徴としている。
【００２９】
また、本発明の配信方法は、上記の課題を解決するために、複数のコンポーネントで構成されるコンテンツを配信する配信装置による配信方法であって、コンポーネントの配信経路を特定するための経路情報が各コンポーネントに対応付けられた対応情報を用いて、各コンポーネントの配信経路を決定する経路決定ステップと、上記経路決定ステップにて決定した配信経路で各コンポーネントを配信する配信制御ステップと、を含むことを特徴としている。
【００３０】
上記の構成によれば、各コンポーネントの配信経路を特定するための経路情報が各コンポーネントに対応付けられた対応情報を用いて、各コンポーネントの配信経路を決定し、決定した配信経路で各コンポーネントを配信する。
【００３１】
このため、上記の構成によれば、配信経路の決定のためにコンポーネントの内容についての解析等を行う必要がなく、コンテンツを構成する各コンポーネントの配信経路を容易に決定し、配信を行うことができる。
【００３２】
なお、上記対応情報は、コンポーネント自体（例えばコンポーネントのヘッダ）に経路情報が対応付けられたものであってもよいし、コンポーネントとは別に管理される情報（例えばテーブルやＸＭＬの形式の情報）であってもよい。
【００３３】
また、上記経路情報は、コンポーネントの配信経路を特定するために用いることができる情報であればよい。例えば、特定の配信経路（放送経路や通信経路等）を直接的に示すものであってもよいし、配信経路の特性（双方向、単方向、マルチキャスト、ユニキャスト等）を示すものであってもよい。また、特定の配信経路による配信を許可（推奨）または禁止することを示す情報であってもよい。
【００３４】
なお、上記コンポーネントは、１つのコンテンツの一部分を構成するものであり、他の構成部分とは異なる経路で配信され得る構成部分である。例えば、１つの動画コンテンツを構成するビデオデータとオーディオデータとは、それぞれ別の経路で配信可能であるから、それぞれが上記コンポーネントとなり得る。
【００３５】
また、上記配信装置は、上記コンポーネントおよび上記対応情報を受信する受信部を備え、上記経路決定手段は、上記受信部が受信した対応情報を用いて、上記受信部が受信したコンポーネントの配信経路を決定し、上記配信制御手段は、上記経路決定手段が決定した配信経路で、上記受信部が受信したコンポーネントを配信することが好ましい。
【００３６】
上記の構成によれば、上記コンポーネントおよび上記対応情報を受信する受信部を備え、受信部が受信した対応情報を用いて受信部が受信したコンポーネントの配信経路を決定し、決定した配信経路で受信部が受信したコンポーネントを配信する。
【００３７】
つまり、上記の構成によれば、他の装置から受信したコンポーネントを、さらに他の装置に再配信する。そして、このコンポーネントを再送信する際には、受信した対応情報を用いて配信経路を決定する。したがって、上記の構成によれば、対応情報に応じた適切な配信経路でコンポーネントの再配信を行うことができる。
【００３８】
また、上記対応情報は、複数のコンポーネントからなるグループに対して経路情報が対応付けられたものであり、上記経路決定手段は、同一グループに属する各コンポーネントの配信経路を、該グループに対して対応付けられている経路情報を用いて決定することが好ましい。
【００３９】
上記の構成によれば、対応情報は、複数のコンポーネントからなるグループに対して経路情報が対応付けられたものであり、同一グループに属する各コンポーネントの配信経路を、該グループに対して対応付けられている経路情報を用いて決定する。
【００４０】
したがって、コンポーネントをグループ単位で容易に配信することができる。なお、複数のコンポーネントからなるグループは、独立した複数のコンポーネントからなるものであってもよいし、複数のコンポーネントが多重化されたものであってもよい。また、独立した複数のコンポーネントからなるものである場合、それらのコンポーネントを多重化した後で配信してもよい。
【００４１】
また、上記配信装置は、各コンポーネントに経路情報を対応付けて、上記対応情報とは異なる二次対応情報を生成する二次対応情報生成手段を備えていることが好ましい。
【００４２】
上記の構成によれば、各コンポーネントに経路情報を対応付けて、上記対応情報とは異なる二次対応情報を生成する。このため、コンポーネントの配信経路を決定するための情報として、対応情報と二次対応情報という２つの情報が生じることになる。
【００４３】
したがって、上記の構成によれば、コンポーネントの配信経路に多様性を持たせることができる。これにより、例えば、上記配信装置を用いる配信業者毎に、その配信能力に応じた適切な配信経路で配信を行わせることも可能になる。
【００４４】
また、上記二次対応情報生成手段は、上記対応情報に含まれる経路情報のうち、自装置が使用できない配信経路を示す経路情報を、自装置が使用できる配信経路に変更して、上記二次対応情報を生成することが好ましい。
【００４５】
ここで、上記配信装置がコンテンツの二次配信に用いられるような場合には、対応情報の経路情報が示す配信経路での配信が困難であることも想定される。例えば、上記配信装置が放送配信のみに対応している場合には、通信経路を示す経路情報がコンポーネントに対応付けられていたとしても、このコンポーネントを通信経路で配信することはできない。また、通信配信に対応している場合であっても、クライアントとの間のネットワークトラフィックが混雑しているときには、通信経路による配信が難しくなる。
【００４６】
そこで、上記の構成によれば、対応情報に含まれる経路情報のうち、自装置が使用できない配信経路を示す経路情報を、自装置が使用できる配信経路に変更して、二次対応情報を生成する。
【００４７】
したがって、上記のようにして生成した二次対応情報を用いて配信を行うことにより、元の対応情報をベースとしつつ、自装置の配信能力や配信経路の混雑状況等に応じた適切な配信経路での配信が可能になる。
【００４８】
さらに、このような二次対応情報を他の配信装置に送信してもよく、これにより自装置と同様の配信能力を有する配信装置や、自装置と同様の通信環境下にある配信装置にも適切な配信経路での配信を行わせることができる。
【００４９】
また、上記配信装置は、上記コンポーネントおよび上記対応情報を受信する受信部と、上記受信部が受信した上記対応情報において、経路情報が対応付けられたコンポーネントに対してさらに経路情報を対応付ける対応情報更新手段とを備えていることが好ましい。
【００５０】
上記の構成によれば、受信部が受信した対応情報において、経路情報が対応付けられたコンポーネントに対してさらに経路情報を対応付ける。すなわち、１つのコンポーネントに対して複数の経路情報を対応付ける。したがって、上記の構成によれば、コンポーネントの配信経路の選択の幅を増やすことができる。
【００５１】
また、上記配信装置は、上記コンポーネントおよび上記対応情報を受信する受信部と、上記経路決定手段が決定した配信経路によって上記コンポーネントを取得するための取得先情報を生成する取得先情報生成手段と、上記取得先情報生成手段が生成した上記取得先情報を配信する取得先情報配信手段とを備えていることが好ましい。
【００５２】
上記の構成によれば、経路決定手段が決定した配信経路によってコンポーネントを取得するための取得先情報を生成し、この取得先情報を配信する。なお、取得先情報は、対応情報に追記することによって、対応情報と共に配信してもよい。
【００５３】
したがって、上記取得先情報の配信を受けた装置では、この取得先情報を参照することによって、経路決定手段が決定した配信経路によってコンポーネントを取得することができる。つまり、上記の構成によれば、クライアントに、対応情報に従ってコンポーネントを取得させることができる。
【００５４】
また、上記取得先情報生成手段は、上記受信部が、上記コンポーネントと共に該コンポーネントを他の装置から取得するための他装置取得先情報を受信した場合に、上記配信装置から当該コンポーネントを取得するための取得先情報を生成することが好ましい。
【００５５】
上記の構成によれば、コンポーネントと共に該コンポーネントを他の装置から取得するための他装置取得先情報を受信した場合に、上記経路決定手段が決定した配信経路によって当該コンポーネントを取得するための取得先情報を生成する。
【００５６】
つまり、上記の構成によれば、クライアントに、上記経路決定手段が決定した配信経路によって当該コンポーネントを取得させることができる。これにより、他装置取得先情報が示す取得先から当該コンポーネントの取得ができなくなった場合であっても、クライアントに当該コンポーネントを取得させることが可能になる。
【００５７】
また、上記取得先情報生成手段は、上記受信部が、上記コンポーネントと共に該コンポーネントを他の装置から取得するための他装置取得先情報を受信した場合に、受信した他装置取得先情報が示す取得先または上記経路決定手段が決定した配信経路によって当該コンポーネントを取得するための取得先情報を生成するものであってもよい。
【００５８】
上記の構成によれば、コンポーネントと共に他装置取得先情報を受信した場合に、他装置取得先情報が示す取得先または経路決定手段が決定した配信経路によって当該コンポーネントを取得するための取得先情報を生成する。
【００５９】
したがって、クライアントに、他装置取得先情報が示す取得先または上記経路決定手段が決定した配信経路によって当該コンポーネントを取得させることができる。これにより、クライアントに、コンポーネントを取得する経路の選択の余地を与えることができる。また、これにより、他装置取得先情報が示す取得先または上記経路決定手段が決定した配信経路の何れかから当該コンポーネントの取得ができなくなった場合であっても、クライアントに当該コンポーネントを取得させることが可能になる。
【００６０】
また、本発明の対応情報生成装置は、上記の課題を解決するために、コンテンツを構成する各コンポーネントについて、該コンポーネントの配信経路を特定するための経路情報を決定する経路情報決定手段と、上記経路情報決定手段が決定した経路情報とコンポーネントとを対応付けて対応情報を生成する対応情報生成手段と、を備えていることを特徴としている。
【００６１】
そして、本発明の対応情報生成方法は、上記の課題を解決するために、対応情報生成装置による対応情報生成方法であって、コンテンツを構成する各コンポーネントについて、該コンポーネントの配信経路を特定するための経路情報を決定する経路情報決定ステップと、上記経路情報決定ステップにて決定した経路情報とコンポーネントとを対応付けて対応情報を生成する対応情報生成ステップと、を含むことを特徴としている。
【００６２】
上記の構成によれば、コンテンツを構成する各コンポーネントについて、その配信経路を特定するための経路情報を決定し、決定した経路情報とコンポーネントとを対応付けて対応情報を生成する。
【００６３】
したがって、この対応情報を用いることにより、配信経路の決定のためにコンポーネントの内容についての解析等を行う必要がなく、コンテンツを構成する各コンポーネントの配信経路を容易に決定し、配信を行うことが可能になる。
【００６４】
なお、生成した対応情報を用いて配信を行う主体は、上記対応情報生成装置であってもよいし、他の配信装置であってもよい。そして、他の配信装置が配信を行う場合には、その配信装置に対応情報を送信してもよい。
【００６５】
また、上記経路情報決定手段は、上記各コンポーネントの属性を示す属性情報と、経路情報毎に予め定められた判定基準とを参照し、上記属性情報が上記判定基準を満たすコンポーネントについて、当該判定基準に対応する経路情報を、当該コンポーネントの経路情報として決定することが好ましい。
【００６６】
上記の構成によれば、各コンポーネントの属性を示す属性情報と、経路情報毎に予め定められた判定基準とを参照し、属性情報が判定基準を満たすコンポーネントについて、当該判定基準に対応する経路情報を、当該コンポーネントの経路情報として決定する。
【００６７】
したがって、上記の構成によれば、予め定められた判定基準に応じた経路情報が自動的に決定される。なお、予め定められた判定基準は、例えば、経路情報が、放送配信のような大容量コンテンツの配信に適応できる配信経路を示すものである場合、コンポーネントのファイルサイズが予め定めた上限値を超えていることであってもよい。この場合、参照する属性情報はコンポーネントのファイルサイズということになる。
【００６８】
また、上記対応情報生成手段は、上記経路情報決定手段が決定した経路情報が同一であるコンポーネントを１つのグループとして、当該グループに対して経路情報を対応付けることが好ましい。
【００６９】
上記の構成によれば、決定した経路情報が同一であるコンポーネントを１つのグループとして、当該グループに対して経路情報を対応付ける。このため、同一の経路情報が決定されたコンポーネントが複数存在する場合には、その複数のコンポーネントからなるグループに対して経路情報が対応付けられた対応情報が生成される。そして、このような対応情報を用いることにより、コンポーネントをグループ単位で容易に配信することができる。
【００７０】
なお、上記配信装置および上記対応情報生成装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記配信装置または上記対応情報生成装置の各手段として動作させることにより、上記配信装置または上記対応情報生成装置をコンピュータにて実現させる制御プログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も本発明の範疇に入る。
【発明の効果】
【００７１】
以上のように、本発明の配信装置は、コンポーネントの配信経路を特定するための経路情報が各コンポーネントに対応付けられた対応情報を用いて、各コンポーネントの配信経路を決定する経路決定手段と、上記経路決定手段が決定した配信経路で各コンポーネントを配信する配信制御手段と、を備えている構成である。
【００７２】
また、本発明の配信方法は、以上のように、コンポーネントの配信経路を特定するための経路情報が各コンポーネントに対応付けられた対応情報を用いて、各コンポーネントの配信経路を決定する経路決定ステップと、上記経路決定ステップにて決定した配信経路で各コンポーネントを配信する配信制御ステップと、を含む構成である。
【００７３】
上記の構成によれば、各コンポーネントの配信経路を特定するための経路情報が各コンポーネントに対応付けられた対応情報を用いて、各コンポーネントの配信経路を決定し、決定した配信経路で各コンポーネントを配信する。
【００７４】
このため、配信経路の決定のためにコンポーネントの内容についての解析等を行う必要がなく、コンテンツを構成する各コンポーネントの配信経路を容易に決定し、配信を行うことができるという効果を奏する。
【００７５】
また、本発明の対応情報生成装置は、以上のように、コンテンツを構成する各コンポーネントについて、該コンポーネントの配信経路を特定するための経路情報を決定する経路情報決定手段と、上記経路情報決定手段が決定した経路情報とコンポーネントとを対応付けて対応情報を生成する対応情報生成手段と、を備えている構成である。
【００７６】
そして、本発明の対応情報生成方法は、以上のように、対応情報生成装置による対応情報生成方法であって、コンテンツを構成する各コンポーネントについて、該コンポーネントの配信経路を特定するための経路情報を決定する経路情報決定ステップと、上記経路情報決定ステップにて決定した経路情報とコンポーネントとを対応付けて対応情報を生成する対応情報生成ステップと、を含む構成である。
【００７７】
上記の構成によれば、コンテンツを構成する各コンポーネントについて、その配信経路を特定するための経路情報を決定し、決定した経路情報とコンポーネントとを対応付けて対応情報を生成する。
【００７８】
したがって、この対応情報を用いることにより、配信経路の決定のためにコンポーネントの内容についての解析等を行う必要がなく、コンテンツを構成する各コンポーネントの配信経路を容易に決定し、配信を行うことが可能になるという効果を奏する。
【図面の簡単な説明】
【００７９】
【図１】本発明の一実施形態を示すものであり、配信システムを構成する二次配信サーバの要部構成の一例を示すブロック図である。
【図２】上記配信システムを構成する一次配信サーバ、二次配信サーバ、およびクライアントの構成の一例を示すブロック図である。
【図３】上記一次配信サーバの要部構成の一例を示すブロック図である。
【図４】双方向配信を指定する経路情報がコンポーネントに対して設定されたコンポーネント管理情報の一例を示す図であり、同図（ａ）はテーブル形式とした例を示し、同図（ｂ）はＸＭＬ形式とした例を示している。
【図５】マルチキャスト配信またはユニキャスト配信を指定する経路情報がコンポーネントに対して設定されたコンポーネント管理情報の一例を示す図であり、同図（ａ）はテーブル形式とした例を示し、同図（ｂ）はＸＭＬ形式とした例を示している。
【図６】上記一次配信サーバが実行するコンポーネント管理情報生成処理の一例を示すフローチャートである。
【図７】上記二次配信サーバが実行する配信処理の一例を示すフローチャートである。
【図８】双方向配信を指定する経路情報が、コンポーネントのグループに対して設定されたコンポーネント管理情報の一例を示す図であり、同図（ａ）はテーブル形式とした例を示し、同図（ｂ）はＸＭＬ形式とした例を示している。
【図９】双方向配信を指定する経路情報が、多重化されたコンポーネントに対して設定されたコンポーネント管理情報の一例を示す図であり、同図（ａ）はテーブル形式とした例を示し、同図（ｂ）はＸＭＬ形式とした例を示している。
【図１０】本発明の他の実施形態にかかる配信システムを構成する、一次配信サーバ、二次配信サーバ、およびクライアントの構成の一例を示すブロック図である。
【図１１】上記二次配信サーバの要部構成の一例を示すブロック図である。
【図１２】上記二次配信サーバが実行するサービス経路情報生成処理の一例を示すフローチャートである。
【図１３】本発明のさらに他の実施形態にかかる配信システムを構成する、一次配信サーバおよびクライアントの構成の一例を示すブロック図である。
【図１４】上記一次配信サーバの要部構成の一例を示すブロック図である。
【図１５】従来技術を示す図であり、従来の配信システムを構成する一次配信サーバおよびクライアントの要部構成を示すブロック図である。
【図１６】本発明のさらに他の実施形態にかかる配信システムの概要を示すブロック図であり、同図（ａ）は中継サーバを含まない例を示し、同図（ｂ）は中継サーバを含む例を示す。
【図１７】１つのコンポーネントに対して複数の経路情報を記述可能なコンポーネント管理情報、および１つの経路情報に対して複数の経路情報を記述可能なコンポーネント管理情報の一例を示す図であり、同図（ａ）は１つのコンポーネントに対して２つの経路情報を記述したコンポーネント管理情報の例を示し、同図（ｂ）は２つの経路情報のそれぞれに対して取得先情報を記述したコンポーネント管理情報の例を示し、同図（ｃ）は、１つの経路情報に対して２つの取得先情報を記述したコンポーネント管理情報の例を示している。
【図１８】コンポーネントの誤り耐性を示す情報とコンポーネントの遅延耐性を示す情報との両方を選択して組み合わせて利用する場合の例を示している。
【図１９】図１８のコンポーネントの誤り耐性を示す情報とコンポーネントの遅延耐性を示す情報との両方を選択して組み合わせて利用する場合の例において、誤り、及び遅延のそれぞれの値の大小について示す図である。
【発明を実施するための形態】
【００８０】
以下、本発明の実施の形態について、図１から図１４に基づいて詳細に説明する。
【００８１】
〔実施形態１〕
本発明の実施形態１について、図１から図９に基づいて説明する。まず、図２に基づいて本実施形態に係る配信システムについて説明する。図２は、本実施形態の配信システム４を構成する一次配信サーバ（対応情報生成装置）１、１’、１”、二次配信サーバ（配信装置）２、およびクライアント３の構成の一例を示すブロック図である。
【００８２】
〔一次配信サーバ１の構成〕
一次配信サーバ１は、コンテンツを生成して配信するサーバであり、メディア生成部１０、フォーマット部１１、経路設定部（経路情報決定手段、対応情報生成手段）１２、および第１送信部２０を備えている。一次配信サーバ１は、コンポーネントの配信経路を特定するための経路情報を含むコンポーネント管理情報（対応情報）を生成する経路設定部１２を備えている点が、図１５に示した従来の一次配信サーバ１００との相違点である。
【００８３】
ただし、図２の一次配信サーバ１、１’、１”では対応する配信経路が第１〜第３送信部２０、２０’、２０”で予め決まっているため、ここで生成されたコンポーネント管理情報が一次配信サーバでの配信に直接利用されることはない。一次配信サーバで生成されたコンポーネント管理情報は二次配信サーバ２に配信され、二次配信サーバでの配信に直接利用される、あるいは、二次配信サーバで各コンポーネントをまとめたコンポーネント管理情報を形成するのに利用される。
【００８４】
メディア生成部１０は、配信するコンテンツのメディア（ビデオデータ、オーディオデータなど）を生成する。また、フォーマット部１１は、メディア生成部１０が生成したメディアをフォーマット化（配信フォーマットに格納、あるいは配信フォーマットを形成）してコンポーネントを生成する。なお、配信用のフォーマットとしては、例えばMPEG-2 TS形式の伝送フォーマットやMP4ファイルフォーマットなどが挙げられる。そして、第１送信部２０は、フォーマット部１１が生成したコンポーネントと、経路設定部１２が生成したコンポーネント管理情報を配信する。
【００８５】
なお、ここでのメディアとは、ビデオやオーディオなど、１つのコンテンツを構成する構成部分として再生・表示されるインスタンスデータを指し、これらのメディアデータは通常、符号化され、上述したような所定の配信用フォーマットに格納されて配信される。すなわち、生成された各メディアはそれぞれ１つのコンテンツを構成するコンポーネント（構成部分）である。そのほか、字幕などのテキストデータ、ビデオとともに表示されるウィジェットなどのアプリケーションもコンポーネントである。ただし、説明の簡便のため、本明細書では、以降特に断らない限り、メディアを配信用に所定の形式でフォーマット化した後のものをコンポーネントと呼んで区別する。
【００８６】
無論、メディアを配信用に所定の形式でフォーマット化したコンポーネント単位で配信を行う態様は、本発明の一実施形態に過ぎない。本発明において配信単位となる「コンポーネント」は、１つのコンテンツの構成部分であり、ハイブリッド配信の対象となるものであればよい。
【００８７】
また、コンポーネント管理情報は、コンポーネントを管理するための情報であり、上述のようにコンポーネントの配信経路を特定するための経路情報を含む。したがって、このコンポーネント管理情報を参照することによって、コンポーネントの配信経路を特定することができる。
【００８８】
経路設定部１２は、コンポーネントの配信経路を示す経路情報を生成し、コンポーネントを示す情報と組み合せてコンポーネント管理情報を生成する。上述したように、ここで生成されるコンポーネント管理情報は、二次配信サーバ２での配信に利用される。なお、経路設定部１２（並びに、二次配信サーバ２）がコンポーネント管理情報を生成する処理、およびコンポーネント管理情報の詳細については後述する。
【００８９】
一次配信サーバ１’、１”は、一次配信サーバ１と同様に、コンテンツを生成して配信するサーバである。これらのサーバは、コンポーネントの配信経路が異なる以外は同様の機能を備えている。つまり、一次配信サーバ１’の第２送信部２０’は、一次配信サーバ１の第１送信部２０とは異なる経路でコンポーネントを配信する。また、一次配信サーバ１”の第３送信部２０”は、第１送信部２０および第２送信部２０’とは異なる経路でコンポーネントを配信する。
【００９０】
なお、図２では、３つの一次配信サーバによる３通りの配信経路で配信を行う例を示しているが、配信経路は複数であればよい。つまり、２つの一次配信サーバによって２通りの配信経路で配信を行ってもよい。
【００９１】
また、図２では、複数の一次配信サーバを用いることによって、複数経路による配信を行う例を示しているが、１つの一次配信サーバに複数の送信部を設け、これにより複数経路による配信を行ってもよい。
【００９２】
〔二次配信サーバ２の構成〕
二次配信サーバ２は、一次配信サーバ１が配信したコンテンツ（マルチコンポーネントコンテンツ）を受信して記憶し、クライアント３に配信するサーバである。図示のように、二次配信サーバ２は、第１受信部４０、第２受信部４０’、第３受信部４０”、記憶部４１、選択部５０、第１送信部４２、第２送信部４２’、および第３送信部４２”を備えている。
【００９３】
第１受信部４０は、一次配信サーバ１の第１送信部２０から送信されるコンポーネントおよびコンポーネント管理情報を受信する。同様に、第２受信部４０’は、一次配信サーバ１’の第２送信部２０’から送信されるコンポーネントおよびコンポーネント管理情報を受信する。また、第３受信部４０”は、一次配信サーバ１”の第３送信部２０”から送信されるコンポーネントおよびコンポーネント管理情報を受信する。
【００９４】
記憶部４１は、二次配信サーバ２で使用する各種データを格納するものであり、上記のコンポーネントおよびコンポーネント管理情報も記憶部４１に格納される。
【００９５】
選択部５０は、記憶部４１に格納されているコンポーネントの配信経路を、同じく記憶部４１に格納されているコンポーネント管理情報に基づいて決定する。そして、決定した配信経路に応じた送信部（第１送信部４２、第２送信部４２’、および第３送信部４２”の何れか）を選択し、選択した送信部からコンポーネントを配信する。
【００９６】
第１送信部４２は、選択部５０の制御に従ってコンポーネントを配信する。第２送信部４２’および第３送信部４２”も同様である。ただし、第１送信部４２、第２送信部４２’、および第３送信部４２”は、コンポーネントの配信経路がそれぞれ異なっている。例えば、第１送信部４２は放送経路により配信を行い、第２送信部４２’はマルチキャストが可能な通信経路により配信を行い、第３送信部４２”はユニキャストのみ可能な通信経路により配信を行うものであってもよい。あるいは、第１送信部４２が放送経路のうち本放送の経路を利用した配信、第２送信部４２’が放送経路のうちデータ放送の経路を利用した配信、第３送信部４２”が通信経路による配信、といった組合せも可能である。
【００９７】
〔クライアント３の構成〕
クライアント３は、二次配信サーバ２がハイブリッド配信するコンテンツ（マルチコンポーネントコンテンツ）を受信し、合成して表示するものである。図示のように、クライアント３は、第１受信部７０、第２受信部７０’、第３受信部７０”、第１メディア復元部７１、第２メディア復元部７１’、第３メディア復元部７１”、および合成・表示部７２を備えている。ここで、メディア復元部とは、フォーマット化されたコンポーネントからメディアのデータストリームを復元する処理、符号化データストリームを復号して再生メディアを復元する処理を実行するものである。なお、クライアント３は、図１５に示した従来のクライアント１０１と同様の構成であるから、説明は省略する。
【００９８】
〔配信システム４の主な特徴点について〕
以上のように、配信システム４では、一次配信サーバ１、１’、１”が一次配信したコンポーネントを二次配信サーバ２が受信して記憶し、二次配信サーバ２がクライアント３に二次配信する。
【００９９】
この配信システム４では、一次配信サーバ１、１’、１”が、各コンポーネントの経路情報を示すコンポーネント管理情報を生成し、このコンポーネント管理情報と共にコンポーネントを配信する。
【０１００】
このため、二次配信サーバ２は、コンポーネント管理情報を参照することにより、コンポーネントの解析等の煩雑な処理を行うことなく、一次配信サーバ１、１’、１”の意図（コンテンツ制作者の意図）に応じた経路でクライアント３への配信を行うことができる。この二次配信サーバ２におけるコンポーネント管理情報は、一次配信サーバで生成されたコンポーネント管理情報そのもの、あるいは各コンポーメントをまとめて形成されたコンポーネント管理情報のいずれの場合もある。
【０１０１】
〔一次配信サーバ１の詳細な構成〕
続いて、一次配信サーバ１のより詳細な構成を図３に基づいて説明する。図３は、一次配信サーバ１の要部構成の一例を示すブロック図である。図示のように、一次配信サーバ１は、第１送信部２０、制御部２１、および記憶部２２を備えている。
【０１０２】
制御部２１は、一次配信サーバ１の機能を統括して制御するものであり、メディア生成部１０、フォーマット部１１、経路設定部１２、および配信制御部１３を含む。また、記憶部２２は、一次配信サーバ１で使用する各種データを格納するものであり、コンポーネント３０およびコンポーネント管理情報３１が格納されている。
【０１０３】
上述のように、メディア生成部１０がメディアを生成し、生成されたメディアをフォーマット部１１がフォーマット化してコンポーネントを生成し、生成された各コンポーネントの経路情報を含むコンポーネント管理情報を経路設定部１２が生成する。図示の例では、フォーマット部１１が生成したコンポーネントがコンポーネント３０として格納されている。また、経路設定部１２が生成したコンポーネント管理情報がコンポーネント管理情報３１として格納されている。
【０１０４】
配信制御部１３は、記憶部２２に格納されているコンポーネント３０とコンポーネント管理情報３１とを第１送信部２０を介して他の機器に配信する。ここでは、配信先が二次配信サーバ２であるとして説明するが、配信先はクライアント３であってもよいし、他の配信サーバ（三次配信サーバ）等であってもよい。
【０１０５】
〔二次配信サーバの構成〕
続いて、二次配信サーバ２のより詳細な構成を図１に基づいて説明する。図１は、二次配信サーバ２の要部構成の一例を示すブロック図である。図示のように、二次配信サーバ２は、第１受信部４０、第２受信部４０’、第３受信部４０”、記憶部４１、第１送信部４２、第２送信部４２’、第３送信部４２”、および制御部４３を備えている。
【０１０６】
上述のように、第１受信部４０、第２受信部４０’、および第３受信部４０”は、コンポーネントおよびコンポーネント管理情報を受信するものである。図示のように、これらの受信部が受信したコンポーネントおよびコンポーネント管理情報は、コンポーネント６０およびコンポーネント管理情報６１として記憶部４１に格納される。
【０１０７】
制御部４３は、二次配信サーバ２の機能を統括して制御するものであり、コンポーネント６０ごとの配信経路を決定し、決定した配信経路に対応する送信部を介して配信する選択部５０を含む。選択部５０は、このような機能を実現するため、配信制御部（配信制御手段）５１と経路決定部（経路決定手段）５２とを含む。
【０１０８】
配信制御部５１は、記憶部４１からコンポーネント６０を読み出して、そのコンポーネント６０の送信経路を経路決定部５２に問い合わせる。そして、当該コンポーネント６０を、この問い合わせに対する応答に応じた送信部（第１送信部４２、第２送信部４２’、第３送信部４２”の何れか）から送信する。なお、以下では、第１送信部４２による配信経路を第１配信経路、第２送信部４２’による配信経路を第２配信経路、第３送信部４２”による配信経路を第３配信経路と呼ぶ。
【０１０９】
経路決定部５２は、配信制御部５１からの経路の問い合わせを受信すると、記憶部４１のコンポーネント管理情報６１に基づいて当該コンポーネント６０の配信経路を決定する。そして、決定した配信経路を示す情報を、受信した問い合わせに対する応答として配信制御部５１に通知する。
【０１１０】
第１送信部４２、第２送信部４２’、および第３送信部４２”は、上述のように、選択部５０の制御に従ってコンポーネント６０およびコンポーネント管理情報６１を配信する。ただし、コンポーネント管理情報６１の配信は必須ではなく、以降の配信先でコンポーネント管理情報６１を参照しないことが明らかである場合には、コンポーネント管理情報６１の配信を省略してもよい。配信先は、クライアント３であってもよいし、他のサーバ（三次配信サーバ）であってもよい。
【０１１１】
〔コンポーネント管理情報の例〕
続いて、コンポーネント管理情報の具体例を図４および図５に基づいて説明する。
【０１１２】
〔双方向配信を指定〕
図４は、双方向配信を指定する経路情報がコンポーネントに対して設定されたコンポーネント管理情報の一例を示す図であり、同図（ａ）はテーブル形式とした例を示し、同図（ｂ）はＸＭＬ形式とした例を示している。なお、図４のコンポーネント管理情報は、複数コンポーネントをまとめて記載した形式の情報、すなわち二次配信サーバ２で形成されるコンポーネント管理情報の例を示したものである。図示のコンポーネント管理情報に対応するコンテンツは、名称が「cont1」であり、「compA」から「compM」までのコンポーネントからなる。
【０１１３】
同図（ａ）の例では、「compB」と「compM」に「bidirectional」の文字列が対応付けられている。この「bidirectional」は、双方向配信向け（双方向配信が必須）のコンポーネントであることを示す情報である。
【０１１４】
これにより、「compB」と「compM」は、双方向配信向けのコンポーネントであると特定することができる。したがって、コンテンツの製作者ではないサーバ（例えば、二次配信サーバ２）であっても、「compB」と「compM」については、双方向配信可能な配信経路（例えば通信経路）で配信することを決定することができる。
【０１１５】
なお、インタラクティブなコンポーネントや、利用者（クライアント３）毎に使用／不使用を選択可能なコンポーネントについては、「bidirectional」を対応付けて双方向配信向けとすればよい。また、一斉配信するコンポーネント、大容量コンポーネント、および利用者に依存しないコンポーネント等については、「bidirectional」を対応付けず、単方向配信向けとすればよい。
【０１１６】
一方、「compA」には「bidirectional」の文字列が対応付けられていない。これにより、「compA」は、双方向配信向けのコンポーネントではないということが分かる。このようなコンポーネントについては、単方向配信する配信経路（例えば放送経路）で配信すればよい。
【０１１７】
また、同図（ｂ）の例では、「trans="bidirectional"」の形式でコンポーネントが双方向配信向けであることを示している。このような形式のコンポーネント管理情報であっても、「cont1」の名称のコンテンツを構成するコンポーネントのうち、「compB」と「compM」は双方向配信向けであり、「compA」は双方向配信向けではないと特定することができる。なお、同図（ｂ）の例において、各<component>要素内の省略した部分（「…」の部分）には、そのコンポーネントに含まれるメディアの情報（コーデック形式や符号化レートなどの属性情報）や取得先の情報（ファイル名や取得先ＵＲＬなど）などが記述される。
【０１１８】
ここで、図４および図５では、１つのコンテンツを構成する全てのコンポーネントについて、その経路情報が示されたコンポーネント管理情報の例を示している。すなわち、二次配信サーバ２におけるコンポーネント管理情報を示しているが、コンポーネント管理情報は、少なくとも１つのコンポーネントの経路情報を示すものであればよい。
【０１１９】
例えば、図２の配信システム４のように、一次配信サーバ１、１’、１”がそれぞれコンポーネント管理情報を生成する場合、１つのコンテンツに対応するコンポーネント管理情報が複数生成されてそれらが管理される。すなわち、一次配信サーバ１、１’、１”で生成されたコンポーネント管理情報が二次配信サーバでそのまま管理されるが、このような情報を用いても配信経路は決定できるので構わない。
【０１２０】
無論、１つのコンテンツに対応するコンポーネント管理情報を１つにまとめてもよい。これは、例えば、二次配信サーバ２の内部または外部に、同一のコンテンツに対応するコンポーネント管理情報を統合する構成を設けることで実現可能である。
【０１２１】
〔ユニキャスト配信またはマルチキャスト配信を指定〕
また、図５は、マルチキャスト配信またはユニキャスト配信を指定する経路情報がコンポーネントに対して設定されたコンポーネント管理情報の一例を示す図であり、同図（ａ）はテーブル形式とした例を示し、同図（ｂ）はＸＭＬ形式とした例を示している。
【０１２２】
なお、マルチキャスト配信は、同じコンポーネントを複数のクライアントに一斉配信する配信形式であり、放送による配信もこの配信形式に属する。一方、ユニキャスト配信は、コンポーネントをクライアントごとに個別に配信する配信形式である。クライアントからのリクエストに応じてコンポーネントを配信する形式の通信による配信もこの配信形式に属する。
【０１２３】
同図（ａ）の例では、「compB」と「compM」に「unicast」の文字列が対応付けられている。この「unicast」は、ユニキャスト配信向けのコンポーネントであることを示す情報である。また、「compA」には、「multicast」の文字列が対応付けられている。この「multicast」は、マルチキャスト配信向けのコンポーネントであることを示す情報である。
【０１２４】
したがって、このようなコンポーネント管理情報を参照することにより、メディアの製作者ではないサーバ（例えば、二次配信サーバ２）であっても、「compB」と「compM」については、ユニキャスト配信可能な配信経路でユニキャスト配信することを決定することができる。また、「compA」については、マルチキャスト配信可能な配信経路でマルチキャスト配信することを決定することができる。
【０１２５】
同図（ｂ）の例では、「trans="unicast"」の形式でコンポーネントがユニキャスト配信向けであることを示し、「trans="multicast"」の形式でコンポーネントがマルチキャスト配信向けであることを示している。このような形式のコンポーネント管理情報であっても、「cont1」の名称のコンテンツを構成するコンポーネントのうち、「compB」と「compM」はユニキャスト配信向けであり、「compA」はマルチキャスト配信向けであると特定することができる。
【０１２６】
〔その他の例〕
コンポーネント管理情報に含まれる経路情報は、その情報に基づいて配信経路を決定できるような情報（配信経路決定の指標となる情報）であればよく、上記の例に限られない。
【０１２７】
例えば、配信経路を機能面で特定した情報を経路情報としてもよい。具体的には、即時性、応答性、高信頼性などを示す情報を経路情報とすることが考えられる。この場合、二次配信サーバ２は、第１送信部４２、第２送信部４２’、第３送信部４２”から、その即時性、応答性、高信頼性に応じた送信部を選択する。例えば、即時性や応答性を示す情報が対応付けられているコンポーネントについては、通信経路で配信すればよい。また、高信頼性を示す情報が対応付けられているコンポーネントについては、放送経路で配信すればよい。
【０１２８】
配信経路を機能面で特定した情報のうち、高信頼性を示す情報を経路情報としては、例えば、コンポーネントの誤り耐性を示す情報（例えば「loss_priority」）や、コンポーネントの遅延耐性を示す情報（例えば「delay_priority」）が挙げられる。ここで、「loss_priority」（誤り耐性情報）は、例えば、「11: loss priority 0 (Lossless)」、「10: loss priority 1 (Lossy, High priority)」、「01: loss priority 2 (Lossy, Medium priority)」、「00: loss priority 3 (Lossy, Low priority)」、といった優先度を含んでいてもよい。また、「delay_priority」（遅延耐性情報）は、例えば、「11: high sensitivity: end-to-end delay << 1sec」、「10: medium sensitivity: end-to-end delay approx. 1 sec」、「01: low sensitivity: end-to-end delay < 5〜10 sec」、「00: don't care」、といった優先度を含んでいてもよい。
【０１２９】
なお、高信頼性を示す情報として、コンポーネントの誤り耐性を示す情報とコンポーネントの遅延耐性を示す情報とのうち、いずれか一つを選択して利用してもよいし、両方を選択して組み合わせて利用してもよい。
【０１３０】
ここで、高信頼性を示す情報として、コンポーネントの誤り耐性を示す情報とコンポーネントの遅延耐性を示す情報とのうち、いずれか一つを選択して利用する場合の例を示す。例えば、高信頼性を示す情報が、優先度「11: loss priority 0 (Lossless)」を含んだコンポーネントの誤り耐性を示す情報であれば、ブロードバンド配信向けであることを示す情報（例えば「broadband」）を経路情報として対応付けることができる。また、例えば、高信頼性を示す情報が、優先度「11: high sensitivity: end-to-end delay << 1sec」を含んだコンポーネントの遅延耐性を示す情報であれば、マルチキャスト配信向けであることを示す情報（例えば「multicast」）を経路情報として対応付けることができる。
【０１３１】
また、図１８では、コンポーネントの誤り耐性を示す情報とコンポーネントの遅延耐性を示す情報との両方を選択して組み合わせて利用する場合の例を示している。例えば、コンポーネントの誤り耐性を示す情報に含まれる優先度が「11: loss priority 0 (Lossless)」であるコンポーネントの誤り耐性を示す情報とコンポーネントの遅延耐性を示す情報に含まれる優先度が「00: don't care」であるコンポーネントの遅延耐性を示す情報とを選択して組み合わせた場合、ユニキャスト配信向けであることを示す情報（例えば「unicast」）を経路情報として対応付けることができる。また、例えば、コンポーネントの誤り耐性を示す情報に含まれる優先度が「00: loss priority 3」であるコンポーネントの誤り耐性を示す情報とコンポーネントの遅延耐性を示す情報に含まれる優先度が「11: high sensitivity: end-to-end delay」であるコンポーネントの遅延耐性を示す情報とを選択して組み合わせた場合、放送配信向けであることを示す情報（例えば「broadcast」）を示す情報（例えば「broadband」）を経路情報として対応付けることができる。
【０１３２】
また、図４の例では、双方向配信向け（双方向配信が必須）のコンポーネントであることを示す情報である「bidirectional」をコンポーネントに対応付けているが、これに限られない。例えば、双方向配信を許可する（双方向配信を推奨するが、必須ではない）ことを示す情報や、双方向配信を禁止することを示す情報のような、特定の配信方式を禁止または許可する情報を対応付けてもよい。
【０１３３】
同様に、図５の例においても、マルチキャスト配信を許可する情報、禁止する情報、ユニキャスト配信を許可する情報、禁止する情報等を経路情報としてコンポーネント管理情報に含めてもよい。
【０１３４】
二次配信サーバ２は、特定の配信方式を許可する経路情報に基づいて選択する場合、許可された配信方式に対応する配信経路を優先して適用し、許可された配信方式が適用できない場合には、他の配信経路を適用する。また、特定の配信方式を禁止する経路情報に基づいて選択する場合、禁止された配信方式以外の配信経路から選択する。
【０１３５】
なお、これらの場合、配信経路が一義的に特定できない可能性があるが、少なくとも配信経路が絞り込まれるため、コンポーネント管理情報を用いない場合と比べて、適切な配信経路を容易に選択することができる。
【０１３６】
また、経路情報は、上記のような配信経路の特性（双方向、マルチキャスト、ユニキャスト等）を示す情報に限られず、配信経路を直接的に示すものであってもよい。例えば、放送配信向けであることを示す情報（例えば「broadcast」）や、通信配信向けであることを示す情報（例えば「broadband」）を経路情報としてもよい。
【０１３７】
また、配信経路を直接に示す情報と配信経路の特性を示す情報とを組み合わせて、詳細な経路情報を規定することもできる。例えば、配信経路を直接に示すtrans属性に加えて、配信経路の特性を示すdirec属性を規定し、これら２つの属性で経路情報を表してもよい。
【０１３８】
この場合、コンポーネントcompAのコンポーネント管理情報は、例えば放送配信向けであることを示す情報「trans＝"broadcast"」と、双方向の機能が必要（双方向配信向け）であることを示す「direc="bidirectional"」とを用いて以下のように記述される。
【０１３９】
<component name="compA" trans="broadcast" direc="bidirectional"/>
この例では、「broadcast」は下り経路の種別を示し、「bidirectional」は下り経路に加えて上り経路がコンポーネントの利用時に必要であることを示す。なお、上り経路の種別は「broadcast」に制限されず、通常の通信回線が使われてよい。
【０１４０】
また、配信経路を直接に示すtrans要素を規定し、trans要素に双方向が必要かを示すbidirectional属性を付加するようにして、要素全体で経路情報を表すようにしてもよい。例えば、以下のスキーマで定義されるtrans要素がこれにあたる。
<element name=trans type="transType"/>
<complexType name="transType">
<attribute name="cast" type="castType"/>
<attribute name="bidirectional" type="xs:boolean"/>
</complexType>
<simpleType name="castType">
<restriction base="string">
<<enumeration value="broadcast"/>
<<enumeration value="unicast"/>
<<enumeration value="multicast"/>
</restriction>
</simpleType>
上記のスキーマによる定義に従えば、配信経路が「broadcast」で双方向の機能が必要な（双方向配信向け）コンポーネントcompAは、次のように記述される。
<component name="compA">
<trans cast="broadcast" bidirectional="true"/>
</component>
さらに、上記では、コンポーネントとは独立したデータであるコンポーネント管理情報によって配信経路を決定する例を示したが、各コンポーネントの配信経路が特定できるようになっていれば、その形式は問わない。例えば、コンポーネントのデータヘッダに、そのコンポーネントの配信経路を示す経路情報を含めてもよい。
【０１４１】
〔コンポーネント管理情報生成処理の流れ〕
次に、一次配信サーバ１が実行するコンポーネント管理情報生成処理（対応情報生成方法）の流れを図６に基づいて説明する。図６は、コンポーネント管理情報生成処理の一例を示すフローチャートである。なお、図６では、メディア生成部１０によってメディアが生成された後の処理を示している。
【０１４２】
まず、フォーマット部１１は、メディア生成部１０が生成したメディアをコンポーネント化し、コンポーネント３０として記憶部２２に記憶する（Ｓ１）。また、フォーマット部１１は、コンポーネント３０を記憶したことを経路設定部１２に通知する。なお、ここでは１つのメディアから１つのコンポーネントを生成する例を説明するが、１つのメディアから生成するコンポーネントは複数であってもよい。
【０１４３】
上記の通知を受信した経路設定部１２は、記憶されたコンポーネント３０のそれぞれについて、経路情報を決定する（Ｓ２、経路情報決定ステップ）。具体的には、コンポーネント３０の配信経路を一次配信サーバ１のユーザ（例えば、当該メディアの製作者）に入力させることによって、経路情報を決定する。これにより、二次配信サーバ２にメディアの製作者の意図に沿った配信経路で配信させることも可能になる。
【０１４４】
なお、経路情報の決定は、経路設定部１２が自動で行うようにしてもよい。例えば、一次配信サーバ１は、配信を行うための構成として第１送信部２０のみを備えているため、経路設定部１２は、第１送信部２０による配信経路を示す経路情報を自動的に決定してもよい。
【０１４５】
また、経路情報の自動決定は、メディアまたはコンポーネントの属性情報等から得られる情報に基づいて行ってもよい。この場合、経路設定部１２は、コンポーネントの属性を示す属性情報と、配信経路毎に予め定められた判定基準とを参照し、属性情報が判定基準を満たすコンポーネントについて、当該判定基準に対応する経路情報を、当該コンポーネントの経路情報として決定してもよい。
【０１４６】
例えば、双方向配信である通信配信は、大容量のデータの送信には適さないことがあるので、双方向配信を示す経路情報についての判定基準をコンポーネントのファイルサイズとしてもよい。そして、コンポーネントのヘッダ情報等に含まれる属性情報から取得したファイルサイズと、所定の閾値とを比較し、閾値以下であれば双方向配信経路を示す経路情報を決定し、閾値を超えていれば単方向配信経路を示す経路情報を決定してもよい。
【０１４７】
なお、コンポーネントに対応する経路情報は、そのコンポーネントをクライアント３に配信するときに使用するべき配信経路を示すものである。このため、図２の配信システム４のように、一次配信サーバ１からクライアント３へ直接に配信を行わない場合には、第１送信部２０が対応していない配信経路を示す経路情報を決定してもよい。
【０１４８】
そして、経路設定部１２は、コンポーネントの経路情報の決定が終了すると、決定した経路情報をコンポーネントに対応付けて、当該メディアに対応するコンテンツのコンポーネント管理情報３１として記憶部２２に記憶する（Ｓ３、対応情報生成ステップ）。
【０１４９】
なお、コンポーネント管理情報は、コンテンツの一次配信元である一次配信サーバ１によって生成されるものであるから、コンポーネント管理情報に含まれる経路情報は、コンポーネントに固有の情報として、基本的に配信先において変更等の対象としない。
【０１５０】
これにより、コンテンツの製作者の意図を、二次配信およびそれ以降の配信において強く反映させることができる。つまり、二次配信およびそれ以降の配信において、製作者の意図に従った配信経路での配信を行わせることができる。
【０１５１】
〔配信処理の流れ〕
次に、二次配信サーバ２が実行する配信処理（配信方法）の流れを図７に基づいて説明する。図７は、配信処理の一例を示すフローチャートである。まず、配信制御部５１は、記憶部４１からコンポーネント６０を読み出し（Ｓ１０）、読み出したコンポーネント６０を経路決定部５２に通知する。
【０１５２】
この通知を受信した経路決定部５２は、コンポーネント管理情報６１を用いて配信経路を決定する（Ｓ１１、経路決定ステップ）。具体的には、経路決定部５２は、コンポーネント管理情報６１を用いて、配信制御部５１から通知されたコンポーネント６０に対応付けられた経路情報を特定する。そして、この経路情報に基づいて、当該コンポーネント６０の配信経路として、第１〜第３配信経路の何れかを決定する。
【０１５３】
上記のようにして配信経路を決定した経路決定部５２は、決定した配信経路を配信制御部５１に通知する。そして、この通知を受信した配信制御部５１は、経路決定部５２が決定した配信経路が第１〜第３配信経路の何れであるかを確認する（Ｓ１２）。
【０１５４】
ここで、第１配信経路が決定されたことが確認された場合、配信制御部５１は、当該コンポーネント６０を送信する送信部として、第１送信部４２を選択する（Ｓ１３）。一方、第２配信経路が決定されたことが確認された場合、第２送信部４２’を選択し（Ｓ１４）、第３配信経路が決定されたことが確認された場合、第３送信部４２”を選択する（Ｓ１５）。
【０１５５】
そして、配信制御部５１は、上記のようにして選択した送信部から、当該コンポーネント６０を配信し（Ｓ１６、配信制御ステップ）、これにより１つのコンポーネントの配信処理は終了する。この配信処理を各コンポーネントについて行うことにより、１つのコンテンツ全体が配信され、クライアント３は配信された各コンポーネント６０を組み合せることによってこのコンテンツを表示（再生）する。
【０１５６】
〔コンポーネントのグループ単位での経路情報の設定〕
上記では、各コンポーネントに経路情報を設定する例を示したが、経路情報は複数のコンポーネントからなるグループに対して設定してもよい。これについて、図８に基づいて説明する。
【０１５７】
図８は、双方向配信を指定する経路情報が、コンポーネントのグループに対して設定されたコンポーネント管理情報の一例を示す図であり、同図（ａ）はテーブル形式とした例を示し、同図（ｂ）はＸＭＬ形式とした例を示している。なお、図示のコンポーネント管理情報に対応するコンテンツは、名称が「cont2」であり、「compA-1」から「compA-L」までの「groupA」と、「compB-1」から「compB-M」までの「groupB」との２つのグループからなる。
【０１５８】
同図（ａ）の例では、「groupB」には、「bidirectional」との文字列が対応付けられている。この文字列は、上述のように双方向配信向け（双方向配信が必須）のコンポーネントであることを示す経路情報である。
【０１５９】
このように、コンポーネントのグループに対して経路情報を設定した場合、そのグループに属するコンポーネントの経路情報を一括して示すことができる。つまり、図示の例では、「groupB」に属する「compB-1」から「compB-M」までの全てのコンポーネントが双方向配信向けである。
【０１６０】
一方、「groupA」には、「bidirectional」との文字列が対応付けられていないので、「groupA」に属する「compA-1」から「compA-L」までの全てのコンポーネントは、双方向配信が必須ではない。
【０１６１】
また、同図（ｂ）の例では、「trans="bidirectional"」の形式でコンポーネントが双方向配信向けであることを示しており、この文字列がコンポーネントのグループ名に対して付加されている。
【０１６２】
このような形式のコンポーネント管理情報であっても、「cont2」の名称のコンテンツを構成するコンポーネントのうち、「groupB」に属するコンポーネントは、双方向配信向けであると特定することができる。また、「groupA」に属するコンポーネントは、双方向配信向けではないと特定することができる。
【０１６３】
このような形式のコンポーネント管理情報は、コンポーネントをグループ単位で取り扱う場合（例えばグループ単位で二次配信する場合や、グループ単位で多重化して利用する場合）に好適である。
【０１６４】
なお、このような形式のコンポーネント管理情報を生成する場合、図６のＳ３において、同じ経路情報が設定されたコンポーネントを抽出し、これらをグループ化して、グループ毎に経路情報を設定することにより、コンポーネント管理情報として生成する。
【０１６５】
〔多重化されたコンポーネントに対する経路情報の設定〕
また、多重化済みのコンポーネントに対して経路情報を設定してもよい。これについて、図９に基づいて説明する。図９は、双方向配信を指定する経路情報が、多重化されたコンポーネントに対して設定されたコンポーネント管理情報の一例を示す図であり、同図（ａ）はテーブル形式とした例を示し、同図（ｂ）はＸＭＬ形式とした例を示している。
【０１６６】
なお、図示のコンポーネント管理情報に対応するコンテンツは、名称が「cont2」であり、「compA-1」から「compA-L」が多重化された「muxcompA」と、「compB-1」から「compB-M」が多重化された「muxcompB」とからなる。
【０１６７】
同図（ａ）には、「cont2」と「muxcompA」および「muxcompB」とが対応付けられたテーブルと、「muxcompA」と「compA-1」から「compA-L」とが対応付けられたテーブルと、「muxcompB」と「compB-1」から「compB-M」とが対応付けられたテーブルとが含まれる。
【０１６８】
「cont2」と「muxcompA」および「muxcompB」とが対応付けられたテーブルは、「cont2」の構成を示すテーブルである。つまり、このテーブルは、「cont2」が、多重化されたコンポーネントである「muxcompA」および「muxcompB」で構成されていることを示している。
【０１６９】
また、「muxcompA」と「compA-1」から「compA-L」とが対応付けられたテーブルは、「muxcompA」の構成を示すテーブルである。つまり、このテーブルは、「muxcompA」が、「compA-1」から「compA-L」までを多重化して構成されていることを示している。同様に、「muxcompB」と「compB-1」から「compB-M」とが対応付けられたテーブルは、「muxcompB」の構成を示すテーブルであり、「muxcompB」が、「compB-1」から「compB-M」までを多重化して構成されていることを示している。
【０１７０】
そして、「cont2」と「muxcompA」および「muxcompB」とが対応付けられたテーブルでは、「muxcompB」に、双方向配信向け（双方向配信が必須）であることを示す「bidirectional」との文字列が対応付けられている。
【０１７１】
このように、多重化したコンポーネントに対して経路情報を設定することもできる。図示の例では、「muxcompB」が双方向配信向けであり、「bidirectional」との文字列が対応付けられていない「muxcompA」は双方向配信が必須ではない。
【０１７２】
また、同図（ｂ）の例においても、同図（ａ）の例と同様に、「cont2」が、多重化されたコンポーネントである「muxcompA」および「muxcompB」で構成されていることを示す記述部分と、「muxcompA」および「muxcompB」の各構成を示す記述部分とが含まれている。そして、「cont2」の構成を示す記述部分では、双方向配信向けであることを示す「trans="bidirectional"」の文字列が「muxcompB」に対して付加されている。
【０１７３】
このような形式のコンポーネント管理情報であっても、「cont2」の名称のコンテンツを構成する多重化コンポーネントのうち、「muxcompB」の名称のものは、双方向配信向けであると特定することができる。また、「muxcompA」の名称の多重化コンポーネントは、双方向配信向けではないと特定することができる。
【０１７４】
なお、図８および図９では、経路情報の一例として「bidirectional」を用いた例を示しているが、経路情報は経路を特定可能なものであればよく、これに限られない。例えば、図５（ａ）（ｂ）に示したような、ユニキャスト配信またはマルチキャスト配信を示す経路情報を用いてもよい。また、既に説明した特定の配信経路による配信を許可または禁止する経路情報を用いてもよい。
【０１７５】
〔実施形態２〕
続いて、本発明の実施形態２について、図１０から図１２に基づいて説明する。まず、図１０に基づいて本実施形態に係る配信システムについて説明する。図１０は、本実施形態の配信システム５を構成する一次配信サーバ１、１’、１”、二次配信サーバ（配信装置）８０、およびクライアント３の構成の一例を示すブロック図である。なお、上記実施形態と同様の構成については同一の参照番号を付し、その説明を省略する。
【０１７６】
配信システム５は、上記実施形態の配信システム４と比べて、二次配信サーバ２が二次配信サーバ８０に変わっている点で相違している。そして、二次配信サーバ８０は、二次配信サーバ２と比べて、サービス設計部（二次対応情報生成手段）５３を備えている点で相違している。
【０１７７】
サービス設計部５３は、コンポーネント管理情報に基づいて、経路情報が各コンポーネントに設定されたサービス経路情報（二次対応情報）を生成する。これにより、一次配信サーバ１等が生成したコンポーネント管理情報をベースとしつつ、二次配信サーバ８０独自の基準で配信経路を指定することができる。
【０１７８】
実施形態１では、メディアの製作者等によってコンポーネント毎に固定の経路情報を与えたのに対し、実施形態２では、二次配信者がコンポーネントの配信経路を独自に設定して配信することを想定している。ここでは、このような配信者主体によるマルチコンポーネントコンテンツの配信をサービスと呼ぶ。なお、実施形態１の配信サーバ１等による配信もメディアの製作者＝配信者主体による１つのサービスであると言える。
【０１７９】
つまり、二次配信サーバ８０は、想定されるサービス毎に、各コンポーネントについて独自に経路情報を設定したサービス経路情報を生成する。そして、生成したサービス経路情報を用いてコンポーネントの配信を行う。また、生成したサービス経路情報を他の配信サーバに送信し、このサービス経路情報に基づいた配信を行わせることもできる。
【０１８０】
このように、二次配信サーバ８０が独自に経路情報を設定する構成とすることにより、同じメディアであっても、二次配信者毎に異なる配信経路によるコンポーネントの配信サービスが実現される。
【０１８１】
例えば、Ａ、Ｂ、Ｃの３つのコンポーネントからなるメディアについて、ある二次配信業者は、Ａ、Ｂは単方向配信し、Ｃは双方向配信することを示すサービス経路情報を生成したとする。一方、他の二次配信業者は、Ａは単方向配信し、Ｂ、Ｃは双方向配信することを示すサービス経路情報を生成したとする。
【０１８２】
この場合、コンポーネントＢの配信経路が、２つの二次配信業者間で異なっている。このように、二次配信業者は、サービス経路情報を生成することにより、同じメディアであっても他の二次配信業者とは異なる配信経路での配信サービスを行うことができる。つまり、配信経路に二次配信業者の意図を反映させることができる。そして、クライアントは、自身の好みの配信経路による配信サービスを提供する二次配信業者からコンポーネントの配信を受けることが可能になる。
【０１８３】
〔二次配信サーバの構成〕
続いて、二次配信サーバ８０のより詳細な構成を図１１に基づいて説明する。図１１は、二次配信サーバ８０の要部構成の一例を示すブロック図である。二次配信サーバ８０は、制御部４３にサービス設計部５３が含まれている点、および記憶部４１にサービス経路情報６２が格納されている点が二次配信サーバ２との相違点である。
【０１８４】
サービス設計部５３は、コンポーネント管理情報６１に基づいて各コンポーネントの経路情報を生成し、経路情報とコンポーネントとを対応付けてサービス経路情報６２として記憶部４１に格納する。また、サービス設計部５３は、複数の異なるサービス経路情報６２を生成して格納してもよい。
【０１８５】
サービス経路情報６２は、コンポーネント管理情報６１と同様に、コンテンツを構成する各コンポーネントの経路情報を示すものであるから、そのデータ構造もコンポーネント管理情報６１と同様となる。
【０１８６】
ただし、サービス経路情報６２が存在することにより、配信経路を決定する際に、コンポーネント管理情報６１を用いるか、サービス経路情報６２を用いるかを判断する必要が生じる。また、複数のサービス経路情報６２が生成された場合には、その中から使用する１つを選択する必要が生じることもあり得る。
【０１８７】
このため、サービス経路情報６２は、選択の指標となる情報を含むことが好ましい。例えば、放送事業者向けのサービス経路情報６２にはその旨を示す情報を含めておき、通信事業者向けのサービス経路情報６２にはその旨を示す情報を含めておいてもよい。これにより、サービス経路情報６２を受信したサーバが通信事業者であれば、その旨を示す情報を含むサービス経路情報６２を選択することができる。サービス経路情報６２を受信したサーバが放送事業者である場合も同様である。また、コンポーネント管理情報６１が並存する場合に、何れを使用するかを指定する情報を含んでいてもよい。この他、サービス経路情報６２の製作者を特定する情報や、サービス経路情報６２を生成した二次配信サーバ８０を特定する情報を含んでいてもよい。これらの指標に基づく選択は、二次配信サーバ、他のサーバ（三次配信サーバ）、あるいはクライアントが行う。
【０１８８】
〔サービス経路情報生成処理の流れ〕
次に、二次配信サーバ８０がサービス経路情報６２を生成する処理であるサービス経路情報生成処理の流れを図１２に基づいて説明する。図１２は、サービス経路情報生成処理の一例を示すフローチャートである。
【０１８９】
まず、サービス設計部５３は、記憶部４１に格納されているコンポーネント管理情報６１を参照して、コンポーネント６０のそれぞれに対応する経路情報を読み出す（Ｓ２０）。そして、読み出した経路情報に基づいて、各コンポーネントに対応する経路情報を決定する（Ｓ２１）。
【０１９０】
具体的には、サービス設計部５３は、各コンポーネント６０について、二次配信サーバ８０が、コンポーネント管理情報６１の経路情報が示す配信経路により配信可能であるか判断する。そして、配信可能であれば、コンポーネント管理情報６１の経路情報をそのコンポーネントの経路情報として決定する。一方、配信不能であれば、配信可能な配信経路を示す経路情報に変更する。
【０１９１】
例えば、第１送信部４２、第２送信部４２’、第３送信部４２”が何れも放送経路による配信ができない場合、放送経路による配信を示す経路情報を、第１送信部４２、第２送信部４２’または第３送信部４２”により配信可能な配信経路を示す適切な経路情報に変更する。このとき、放送経路に近いマルチキャスト配信の通信経路を選択するなど、適切な経路を適宜選択する。なお、経路を選択する基準は予め定めておけばよい。これにより、コンポーネント管理情報６１に反映されたコンテンツ制作者の意図を尊重しつつ、二次配信サーバ８０に適合したサービス経路情報６２を生成することができる。
【０１９２】
そして、サービス設計部５３は、１つのコンテンツに対応する全てのコンポーネントの経路情報の決定が終了すると、決定した経路情報をコンポーネント毎に対応付けて、当該メディアのサービス経路情報６２として記憶部４１に記憶する（Ｓ２２）。ここで、サービス設計部５３は、同一の経路情報に対応するコンポーネントをグループ化し、グループ単位で経路情報を設定してもよい（図８（ａ）（ｂ）参照）。
【０１９３】
なお、上記の例では、二次配信サーバ８０の対応可能な配信経路に応じたサービス経路情報６２を生成しているが、サービス経路情報６２はこの例に限られない。例えば、サービス設計部５３は、各コンポーネント６０の経路情報を表示装置に表示させる等して二次配信サーバ８０のユーザ（例えば、二次配信業者）に提示し、各コンポーネント６０の新たな経路情報を入力させることによって、経路情報を決定してもよい。このような経路情報を用いて生成されたサービス経路情報６２によれば、二次配信サーバ８０の配信経路および三次配信以降の配信経路に、二次配信業者の意図を反映させることが可能になる。
【０１９４】
また、サービス設計部５３は、二次配信サーバ８０とクライアント３との間の接続経路の状態を検出し、その検出結果に応じて配信経路を設定してもよい。これにより、接続経路の状態に応じた適切な配信経路を設定することができる。例えば、二次配信サーバ８０とクライアント３との間の通信に遅延が生じていることを検出した場合には、放送経路を指定する経路情報を設定してもよい。
【０１９５】
さらに、複数のクライアントが有する接続経路の情報を収集、集計し、最適な配信経路の組合せによるサービス経路情報を適宜生成してもよい。この場合、配信可能な経路による代表的な組合せを抽出して、それらに対応した複数のサービス経路情報を生成するといったことも可能である。
【０１９６】
また、サービス設計部５３は、配信経路をクライアント３に選択させてもよい。例えば、サービス設計部５３は、メディアを構成する各コンポーネントのそれぞれについて、二次配信サーバ８０の対応可能な配信経路を示す情報を付加して、クライアント３に送信する。この対応可能な配信経路を示す情報は、複数の配信経路（例えば放送経路および通信経路）を示すものであってもよい。次に、クライアント３は、受信した情報に基づいて、各コンポーネントについて所望の配信経路を決定し、決定した結果を二次配信サーバ８０に通知する。そして、サービス設計部５３は、通知された上記結果に従って各コンポーネントの経路情報を生成し、生成した経路情報からサービス経路情報を生成する。
【０１９７】
これにより、クライアント３の意図に沿った配信のためのサービス経路情報が生成される。このため、このサービス経路情報に基づいて配信を行う二次配信サーバ８０（または三次配信以降のサーバ）により、クライアント３の意図に沿った配信が行われる。
【０１９８】
〔配信処理の流れ〕
二次配信サーバ８０が実行する配信処理の流れは、図７に記載の二次配信サーバ２の配信処理と同様である。ただし、二次配信サーバ８０は、サービス経路情報６２を生成するので、図７のＳ１１ではコンポーネント管理情報６１の代わりにサービス経路情報６２を用いて配信経路を決定してもよい。また、生成したサービス経路情報６２は用いずに、コンポーネント管理情報を使用して配信経路を決定してもよい。
【０１９９】
さらに、コンポーネント管理情報６１およびサービス経路情報６２の何れを用いるかは、予め定めておいてもよいし、上述のようにサービス経路情報６２に含まれる情報に基づいて決定してもよい。
【０２００】
また、二次配信サーバ８０は、図７のＳ１６の処理では、コンポーネント６０と共にサービス経路情報６２を送信する。なお、このときにコンポーネント管理情報６１についても送信してもよい。ただし、サービス経路情報６２（およびコンポーネント管理情報６１）の配信は必須ではない。すなわち、以降の配信先でサービス経路情報６２（およびコンポーネント管理情報６１）を参照しないことが明らかである場合には、サービス経路情報６２（およびコンポーネント管理情報６１）の配信を省略してもよい。これらのデータの送信先は、クライアント３であってもよいし、他の配信サーバ（例えば三次配信サーバ）であってもよい。
【０２０１】
〔実施形態３〕
続いて、本発明の実施形態３について、図１３および図１４に基づいて説明する。まず、図１３に基づいて本実施形態に係る配信システムについて説明する。図１３は、本実施形態の配信システム６を構成する一次配信サーバ（対応情報生成装置、配信装置）９０およびクライアント３の構成の一例を示すブロック図である。なお、上記実施形態と同様の構成については同一の参照番号を付し、その説明を省略する。
【０２０２】
配信システム６は、上記実施形態の配信システム５と比べて、一次配信サーバ１、１’、１”が一次配信サーバ９０に変わっている点で相違している。この一次配信サーバ９０は、一次配信サーバ１、１’、１”を１つの装置に統合したものである。
【０２０３】
このため、一次配信サーバ９０には、一次配信サーバ１の備えるメディア生成部１０、フォーマット部１１、および経路設定部１２が第１ユニット１４として含まれる。同様に、一次配信サーバ１’、１”の備えるメディア生成部１０’、１０”、フォーマット部１１’、１１”、および経路設定部１２’、１２”が、それぞれ第２ユニット１４’および第３ユニット１４”として含まれる。これら各ユニットで生成されたコンポーネントおよびコンポーネント管理情報は、記憶部２２に格納される。このとき、コンポーネント管理情報は、図４、５に示したような、コンテンツを構成するコンポーネントを１つにまとめたコンポーネント管理情報としてもよい。
【０２０４】
また、一次配信サーバ９０は、上記実施形態の二次配信サーバ８０と同様に、サービス設計部（二次対応情報生成手段）１５および選択部（配信制御手段、経路決定手段）１６を備えている。サービス設計部１５および選択部１６は、二次配信サーバ８０のサービス設計部５３および選択部５０と同様の機能を有している。つまり、本実施形態の配信システム６では、一次配信サーバ９０がサービス経路情報を生成する構成である。
【０２０５】
なお、同図では、二次配信サーバを介さずに一次配信サーバ９０からクライアント３に配信する例を示しているが、一次配信サーバ９０とクライアント３との間に、１または複数の配信サーバが介在していてもよい。
【０２０６】
〔一次配信サーバ９０の構成〕
続いて、一次配信サーバ９０のより詳細な構成を図１４に基づいて説明する。図１４は、一次配信サーバ９０の要部構成の一例を示すブロック図である。図示のように、一次配信サーバ９０は、第１送信部２０、第２送信部２０’、第３送信部２０”、制御部２１、および記憶部２２を備えている。
【０２０７】
また、制御部２１には、第１ユニット１４、第２ユニット１４’、第３ユニット１４”、サービス設計部１５、および選択部１６が含まれている。なお、第２ユニット１４’は、第１ユニット１４と同様に、メディア生成部１０’、フォーマット部１１’、および経路設定部１２’を備えているが、これらの構成は図示を省略している。第３ユニット１４”についても同様である。また、選択部１６は、選択部５１と同様に配信制御部と経路決定部とを備えている（図１参照）が、これらの構成についても図示を省略している。
【０２０８】
一次配信サーバ９０では、第１ユニット１４、第２ユニット１４’、および第３ユニット１４”が生成したコンポーネントがコンポーネント３０として記憶部２２に格納される。また、第１ユニット１４、第２ユニット１４’、および第３ユニット１４”が生成したコンポーネント管理情報がコンポーネント管理情報３１として記憶部２２に格納される。
【０２０９】
なお、図４、図５に示したような、１つのコンテンツを構成する各コンポーネントの経路情報が１つにまとまったコンポーネント管理情報３１を生成する場合、各ユニットが生成したコンポーネント管理情報を統合する処理を行う構成を追加すればよい。
【０２１０】
また、一次配信サーバ９０では、サービス設計部１５がコンポーネント管理情報３１に基づいてサービス経路情報を生成し、これをサービス経路情報３２として記憶部２２に格納する。
【０２１１】
ここで、サービス設計部１５は、二次配信者（二次配信サーバ）のタイプに応じた複数のサービス経路情報３２を生成してもよい。例えば、放送事業者向けに、放送経路を示す経路情報を主体としたサービス経路情報３２を生成すると共に、通信事業者向けに、通信経路を示す経路情報を主体としたサービス経路情報３２を生成してもよい。
【０２１２】
また、このように他のサーバ向けのサービス経路情報３２を生成する場合、サービス設計部１５は、コンポーネント管理情報３１を参照しなくともよい。この場合、コンテンツの製作者等がサービス経路情報３２に含まれる各経路情報を設定すればよい。
【０２１３】
そして、選択部１６は、コンポーネント管理情報３１を参照して、コンポーネント３０の配信経路をそれぞれ決定し、決定した配信経路に対応する送信部（第１送信部２０、第２送信部２０’、および第３送信部２０”の何れか）から配信する。なお、選択部１６は、サービス経路情報３２を参照して、一次配信時点での接続状況等に適した配信経路を決定してもよい。また、配信先が予め決まった二次配信サーバ等である場合には、コンポーネント管理情報３１およびサービス経路情報３２の何れも参照せずに、そのサーバへの配信に利用可能な配信経路を決定してもよい。
【０２１４】
また、選択部１６は、サービス経路情報３２の配信も行う。これにより、サービス経路情報３２を受信した二次配信サーバ等において、サービス経路情報３２に基づいた適切な配信経路での再配信が可能になる。なお、選択部１６は、コンポーネント管理情報３１も配信してもよい。これにより、二次配信サーバ等における配信経路選択の幅を広げることができる。
【０２１５】
〔一次配信サーバ９０が実行する処理〕
一次配信サーバ９０は、コンポーネント管理情報生成処理（図６参照）を実行してコンポーネント管理情報３１を生成する。コンポーネント管理情報生成処理の内容は、概ね実施形態１で説明したとおりである。ただし、一次配信サーバ９０はクライアント３に対して直接配信を行う点で、実施形態１の一次配信サーバ１、１’、１”と相違する。このため、図６のＳ２において、経路決定部１２、１２’、１２”は、それぞれ第１〜第３送信部２０、２０’、２０”による配信経路を示す経路情報を自動的にまたはユーザ（メディアの製作者等）の入力操作に基づき決定する。
【０２１６】
また、サービス経路情報生成処理（図１２参照）を実行してサービス経路情報３２を生成する。そして、配信処理（図７参照）を実行してコンポーネントを配信する。これらの処理は、上述の実施形態で説明したとおりであるから、ここでは説明を省略する。
【０２１７】
〔双方向配信経路の利用について〕
上述のように、コンポーネント管理情報およびサービス経路情報は、配信サーバが、コンポーネントの適切な配信経路を選択するために用いられるが、クライアントにコンポーネントの存在を通知するために用いることもできる。
【０２１８】
ここで、あるコンポーネントについて選択した配信経路が、双方向配信を行う配信経路である場合、そのコンポーネントの配信はクライアントからの要求を受けたときに行われる。つまり、双方向配信経路を利用する場合、双方向配信経路でのコンポーネント配信の存在をクライアントに通知し、クライアントにコンポーネント要求を送信させる必要がある。
【０２１９】
上述のコンポーネント管理情報およびサービス経路情報は、このような通知に利用することもできる。つまり、コンポーネント管理情報またはサービス経路情報をクライアントに送信することにより、クライアントはコンポーネントがどのようにして配信されるかを特定することができる。そして、双方向配信されることを特定したコンポーネントについて、送信要求を行うことによって、当該コンポーネントを取得することができる。なお、この場合、クライアントに送信要求先を特定させる必要があるので、要求先を特定するための情報（ＵＲＬ等）についてもクライアントに配信する。
【０２２０】
〔実施形態４〕
実施形態３でも説明した通り、クライアントが様々な経路で配信されるコンポーネントを受け取り、適切に再生するためには、それぞれのコンポーネントの取得先のＵＲＬ、チャンネル等を記した取得先の情報（以下、取得先情報と呼ぶ）が必要である。
【０２２１】
そして、この取得先情報は、通常、コンポーネント管理情報の一部として、サーバからクライアントへと送られる。このことは、実施形態１の図４（ｂ）の説明でも既に示している。すなわち、図４（ｂ）のコンポーネント管理情報は、各<component>要素内の省略した部分（「…」の部分）に取得先情報が記述されて、サーバからクライアントへと送られる。
【０２２２】
コンポーネント管理情報に含まれる、実施形態１から３に示した本発明の経路情報は、送り手側（例えばサーバ）が利用する情報である。これに対し、取得先情報は、受け手側（例えばクライアント）が利用する情報である。ただし、本来、コンポーネントの取得先情報は、経路情報を反映して値が決まる（サーバで値を設定する）ものであり、経路情報と取得先情報とは、生成、利用のタイミングが異なっているが、互いに関係のある情報である。
【０２２３】
そこで、本実施形態４では、配信システム上において、コンポーネント管理情報内の経路情報および取得先情報が、どのように生成、変更、利用されるかを、図１６に基づいて説明する。
【０２２４】
図１６は、本実施形態の配信システムの概要を示すブロック図であり、同図（ａ）は中継サーバを含まない例を示し、同図（ｂ）は中継サーバを含む例を示す。また、同図（ａ）（ｂ）では、当該配信システムにおいて伝送されるコンポーネントおよびコンポーネント管理情報の関係についても示している。
【０２２５】
〔中継サーバを含まない配信システムの構成〕
まず、中継サーバを含まない図１６（ａ）の配信システムの構成について説明する。図１６（ａ）の配信システムは、図示のように、コンテンツプロバイダサーバ１３１、サービスプロバイダサーバ１３２、およびクライアント１３３を含む構成である。
【０２２６】
コンテンツプロバイダサーバ１３１は、コンテンツ製作者が管理する配信サーバである。図示のように、コンテンツプロバイダサーバ１３１は、コンポーネントを複数の配信経路でサービスプロバイダサーバ１３２に配信する配信装置である。実施形態１の図２および実施形態２の図１０で示した一次配信サーバ１〜１”が、これに相当する。
【０２２７】
サービスプロバイダサーバ１３２は、配信サービス事業者が管理するサーバである。図示のように、サービスプロバイダサーバ１３２は、コンテンツプロバイダサーバ１３１から受信したコンポーネントを、複数の配信経路でクライアント１３３に配信する。つまり、サービスプロバイダサーバ１３２は、配信装置としての機能を有する。実施形態１の図２および実施形態２の図１０で示した二次配信サーバ２、８０が、これに相当する。
【０２２８】
クライアント１３３は、最終的にコンポーネントを受け取り、コンテンツを再生する端末である。図示のように、クライアント１３３は、サービスプロバイダサーバ１３２から複数の配信経路でコンポーネントを受信する。上記各実施形態のクライアント３が、これに相当する。
【０２２９】
〔中継サーバを含まない配信システムにおける処理の流れ〕
続いて、中継サーバを含まない配信システムおける処理の流れを図１６（ａ）に基づいて説明する。
【０２３０】
まず、コンテンツプロバイダサーバ１３１（コンテンツ製作者）は、コンテンツの各コンポーネントを生成すると共に、各コンポーネントをどのような経路で配信するのが適当であるかを示す経路情報を生成する。経路情報の生成については、上記各実施形態で説明した通りである。
【０２３１】
そして、コンテンツプロバイダサーバ１３１は、生成した経路情報をサービスプロバイダサーバ１３２に送信する。具体的には、生成した経路情報を含むコンポーネント管理情報９１をサービスプロバイダサーバ１３２に送信する。
【０２３２】
図示のように、管理情報９１には、コンポーネント「compA」がユニキャスト配信向けコンポーネントであることを示す経路情報「unicast」と、コンポーネント「compB」が放送向けコンポーネントであることを示す経路情報「broadcast」とが記述されている。上述のように、これらの経路情報は、サービスプロバイダサーバ１３２（配信サービス事業者）が取得先情報を決定するために利用される。
【０２３３】
次に、サービスプロバイダサーバ１３２（配信サービス事業者）は、コンテンツプロバイダサーバ１３１から受信した管理情報９１に含まれる経路情報を参照して、各コンポーネントを伝送する経路を具体的に決定する。そして、決定した経路をクライアント１３３に通知するための取得先情報を生成する。つまり、サービスプロバイダサーバ１３２は、取得先情報を生成する取得先情報生成手段を備えている。
【０２３４】
この取得先情報は、クライアント１３３が各コンポーネントを取得するために利用する情報である。このため、サービスプロバイダサーバ１３２は、生成した上記取得先情報を、コンポーネント管理情報９１’に記述して、クライアント１３３に配信する。つまり、サービスプロバイダサーバ１３２は、取得先情報配信手段を備えている。なお、取得先情報は、コンポーネント管理情報９１’と独立したデータとして配信してもよい。
【０２３５】
図示のように、クライアント１３３に送信するコンポーネント管理情報９１’には、コンポーネント「compA」がユニキャスト配信向けコンポーネントであることを示す経路情報「unicast」と共に、その具体的な取得先を示す取得先情報「url-a1」（取得先の通信ＵＲＬ）が記述されている。また、コンポーネント「compB」が放送向けコンポーネントであることを示す経路情報「broadcast」と共に、その具体的な取得先を示す取得先情報「ch-b1」（取得先の放送局・チャンネル情報）が記述されている。
【０２３６】
このようなコンポーネント管理情報９１’を受信したクライアント１３３は、その取得先情報を参照して、所望のコンポーネントを取得することができる。すなわち、コンポーネント「compA」を取得する場合には、取得先情報「url-a1」の示す取得先にアクセスすればよい。同様に、コンポーネント「compB」を取得する場合には、取得先情報「ch-b1」の示す取得先に受信チャンネルを合わせればよい。これにより、経路情報に応じた配信経路でコンポーネントを取得することができる。
【０２３７】
〔中継サーバを含む配信システムの構成〕
続いて、中継サーバを含む図１６（ｂ）の配信システムの構成について説明する。図１６（ｂ）の配信システムでは、サービスプロバイダサーバ１３２と、クライアント１３３との間に、中継サーバ１４２が介在している点が、同図（ａ）の配信システムとの相違点である。
【０２３８】
中継サーバ１４２は、コンテンツ配信のための中継を行うサーバである。この中継サーバ１４２は、例えば転送のためのプロキシサーバやミラーサーバであってもよいし、他の配信サービス事業者が管理するサーバ等であってもよい。つまり、中継サーバ１４２は、配信装置としての機能も有する。
【０２３９】
図示のように、中継サーバ１４２は、サービスプロバイダサーバ１３２から受信したコンポーネントを複数の配信経路でクライアント１３３に配信する。なお、中継サーバ１４２は、コンテンツプロバイダサーバ１３１からコンポーネントを受信してもよい。また、中継サーバ１４２によるコンポーネントの配信先は、図示しない他の中継サーバであってもよい。
【０２４０】
そして、中継サーバ１４２は、サービスプロバイダサーバ１３２またはコンテンツプロバイダサーバ１３１から配信されたコンポーネントを自機内あるいはその他の機器に蓄積し、以降の中継サーバあるいはクライアント１３３に転送する機能を有するものとする。
【０２４１】
〔中継サーバを含む配信システムにおける処理の流れ〕
中継サーバを含む配信システムにおける処理は、サービスプロバイダサーバ１３２が経路情報と取得先情報とを含むコンポーネント管理情報９１’を形成するところまでは、図１６（ａ）の例と同じである。ただし、図１６（ｂ）の配信システムでは、コンポーネント管理情報９１’が中継サーバ１４２に送られる点が図１６（ａ）とは異なる。
【０２４２】
ここで、経路情報は、メディアの性質等により決定されているため、中継サーバ１４２が介在する場合であっても、基本的に変更の必要がない。一方、コンポーネントの取得先情報は、中継サーバ１４２が介在する場合には、中継サーバ１４２の蓄積先に変更する必要がある。
【０２４３】
このため、中継サーバ１４２は、サービスプロバイダサーバ１３２から得たコンポーネント管理情報９１’のうち、経路情報のみを継承したコンポーネント管理情報９１”を生成する。図示のように、コンポーネント管理情報９１”では、コンポーネント管理情報９１’に記述されていた取得先情報（他装置取得先情報）は記述されておらず、各コンポーネントの経路情報が記述されている。
【０２４４】
また、中継サーバ１４２は、継承した上記経路情報を参照して、新たに取得先情報を生成する。つまり、中継サーバ１４２は、取得先情報を生成する取得先情報生成手段を備えている。そして、コンポーネント管理情報９１”に対して、新たに生成した取得先情報を記述したコンポーネント管理情報９１’’’を生成して、以降の中継サーバあるいはクライアント１３３に配信する。つまり、中継サーバ１４２は、取得先情報配信手段を備えている。
【０２４５】
図示のように、中継サーバ１４２から送出されるコンテンツ管理情報９１’’’には、コンポーネント「compA」がユニキャスト配信向けコンポーネントであることを示す経路情報「unicast」と共に、その具体的な取得先を示す新たな取得先情報「url-a2」が記述されている。また、コンポーネント「compB」が放送向けコンポーネントであることを示す経路情報「broadcast」と共に、その具体的な取得先を示す新たな取得先情報「ch-b2」が記述されている。
【０２４６】
このようなコンポーネント管理情報９１’’’を受信したクライアント１３３は、その取得先情報を参照して、所望のコンポーネントを取得することができる。すなわち、コンポーネント「compA」を取得する場合には、取得先情報「url-a2」の示す取得先にアクセスすればよい。同様に、コンポーネント「compB」を取得する場合には、取得先情報「ch-b2」の示す取得先に受信チャンネルを合わせればよい。これにより、中継サーバ１４２から当該コンポーネントを取得することができる。
【０２４７】
なお、図１６（ａ）の例では、サービスプロバイダサーバ１３２が取得先情報を記述したコンポーネント管理情報を生成する例を示したが、同様の処理を同図（ａ）のコンテンツプロバイダサーバ１３１が行うようにしてもよい。また、同様の処理を同図（ｂ）の中継サーバ１４２が行う（中継サーバ１４２が新たにコンポーネント管理情報を生成する）ようにしてもよい。
【０２４８】
また、同図（ｂ）の例において、コンテンツプロバイダサーバ１３１が、取得先情報を記述したコンポーネント管理情報を生成する構成としてもよい。この場合、サービスプロバイダサーバ１３２が、取得先情報を更新したコンポーネント管理情報（図１６（ｂ）のコンポーネント管理情報９１’’’に相当）を生成してもよい。
【０２４９】
そして、図１６（ａ）（ｂ）の例では、１つの配信システムに対して各サーバが１つ含まれ、１つのサーバが複数の経路での配信を実行する態様を示しているが、実施形態１、２で既に示している通り、複数のサーバによって複数の経路で配信してもよい。すなわち、コンテンツプロバイダサーバ１３１および／またはサービスプロバイダサーバ１３２が複数で構成され、複数のサーバかつ複数の経路でコンポーネントの配信がなされるとしてもよい。中継サーバ１４２も同様である。
【０２５０】
さらに、図１６（ａ）（ｂ）の例では、コンポーネントが「compA」、「compB」の２つの場合の例を示しているが、コンポーネント管理情報に記述されるコンポーネントの数はこれに限られない。そして、図１６（ａ）（ｂ）の例では、各コンポーネントがユニキャスト配信向けと放送向けのものである例を示しているが、コンポーネントの経路情報もこれに限るものでないことは言うまでもない。
【０２５１】
例えば、３つのコンポーネントを対象とし、そのうち１つが放送向け、２つがユニキャスト向けであってもよい。また、４つのコンポーネントを対象とし、そのうち１つが放送向け、１つがマルチキャスト配信向け、残り２つがユニキャスト配信向けであってもよい。これらの何れのケースであっても、上記と同様のコンポーネント管理情報による管理が可能である。このように、本発明の配信システムは、様々なコンポーネント数、経路情報のパターンに対して適用可能である。無論、コンポーネントが１つの場合も含まれる。
【０２５２】
〔経路情報の変更について〕
図１６（ａ）（ｂ）の例では、コンテンツプロバイダサーバ１３１（コンテンツ製作者）で設定された経路情報が配信システム全体にわたって継承される場合の例を示している。実施形態１で示した通り、経路情報を継承することは、コンテンツ製作者の意図を配信において強く反映させ得るとの効果を持つ。
【０２５３】
しかしながら、実施形態２で既に示している通り、サービスプロバイダサーバ１３２および／またはそれ以降のサービス事業者が、自身のサービスに合せて、もしくは自身の保有する配信経路に合せて、経路情報を変更することも可能である。
【０２５４】
この場合、実施形態２で示したように、コンポーネント管理情報と別のサービス経路情報を形成して管理することも可能であるし、あるいは、コンポーネント管理情報自体を変更し、以降の中継サーバ１４２もしくはクライアント１３３に送ることも可能である。
【０２５５】
〔複数の経路情報（取得先情報）を記述したコンポーネント管理情報について〕
また、コンポーネント管理情報において、１つのコンポーネントに対して、複数の経路情報を記述可能とし、コンポーネントの配信に介在する機器（サービスプロバイダサーバ１３２や中継サーバ１４２等）が経路情報を追記するようにしてもよい。同様に、１つの経路情報に対して、複数の取得先情報を記述可能とし、コンポーネントの配信に介在する機器（サービスプロバイダサーバ１３２や中継サーバ１４２等）が取得先情報を追記するようにしてもよい。
【０２５６】
これについて、図１７に基づいて説明する。図１７は、１つのコンポーネントに対して複数の経路情報を記述可能なコンポーネント管理情報、および１つの経路情報に対して複数の経路情報を記述可能なコンポーネント管理情報の一例を示す図である。
【０２５７】
具体的には、同図（ａ）は１つのコンポーネントに対して２つの経路情報を記述したコンポーネント管理情報の例を示し、同図（ｂ）は２つの経路情報のそれぞれに対して取得先情報を記述したコンポーネント管理情報の例を示している。また、同図（ｃ）は、１つの経路情報に対して２つの取得先情報を記述したコンポーネント管理情報の例を示している。なお、コンポーネント管理情報は、基本的にはコンテンツプロバイダサーバ１３１が生成したものを用いるため、これを変更する図１７（ａ）〜（ｃ）のような例は、特殊なケースと言える。
【０２５８】
同図（ａ）のコンポーネント管理情報では、１つのコンポーネントに対して、複数の経路情報を記述可能である。具体的には、コンポーネント「compB」に対して、「broadcast」の経路情報が対応付けて記述されていると共に、２つ目の経路情報として「unicast」が対応付けて記述されている。
【０２５９】
この１つ目の経路情報は、例えば図１６（ｂ）のコンテンツプロバイダサーバ１３１によって記述され、２つ目の経路情報は、例えば中継サーバ１４２によって記述される。この場合、サービスプロバイダサーバ１３２からコンポーネント管理情報９１’を受信した中継サーバ１４２が、コンポーネント「compB」をユニキャストでも配信可能であると判断する。そして、図１６（ｂ）のコンポーネント管理情報９１’’の代わりに、図１７（ａ）のコンポーネント管理情報を生成する。つまり、中継サーバ１４２は、受信したコンポーネント管理情報において、経路情報が対応付けられたコンポーネントに対して、さらに経路情報を対応付ける対応情報更新手段を備えている。
【０２６０】
さらに、中継サーバ１４２は、コンポーネント「compB」をユニキャストで配信する際の経路を決定し、決定した配信経路に応じた取得先情報を生成する。そして、生成した取得先情報をコンポーネント「compB」と対応付けて記述して、図１７（ｂ）のコンポーネント管理情報を生成する。このコンポーネント管理情報が、図１６（ｂ）のコンポーネント管理情報９１’’’の代わりに、以降の中継サーバあるいはクライアント１３３に配信される。
【０２６１】
なお、上述のような経路情報の追記は、クライアント１３３に対してコンポーネントの配信を行う任意の機器が行うことが可能であり、例えばサービスプロバイダサーバ１３２が行ってもよい。
【０２６２】
図１７（ｂ）の例では、コンポーネント「compB」に対して、２つの経路情報が記述されており、各経路情報に対して取得先情報が記述されている。このため、これを受信したクライアント１３３では、何れかの経路情報に対応する取得先情報を用いてコンポーネント「compB」を取得することができる。
【０２６３】
つまり、クライアント１３３は、取得先情報「ch-b2」のチャンネルでコンポーネント「compB」を受信することもできるし、取得先情報「url-b2」にアクセスしてコンポーネント「compB」を取得することもできる。
【０２６４】
このように、経路情報を追記したコンポーネント管理情報を生成することにより、クライアント１３３におけるコンポーネントの取得経路の選択の幅を増やすことができる。また、何れかの経路でコンポーネントを取得できなかった場合に、他の経路で取得することも可能になる。
【０２６５】
無論、コンポーネント管理情報において、１つのコンポーネントに対応付ける経路の数、および対応付ける経路情報の値は、図１７（ａ）（ｂ）の例に限られるものではなく、様々なパターンが適用可能である。
【０２６６】
また、図１７（ｃ）のコンポーネント管理情報では、１つの経路情報に対して複数の取得先情報を記述可能となっている。具体的には、コンポーネント「compA」に対応付けて記述されている経路情報「unicast」に対して、「url-a1」および「url-a2」の２つの取得先情報が対応付けて記述されている。
【０２６７】
このようなコンポーネント管理情報は、例えば図１６（ｂ）の中継サーバ１４２によって生成される。この場合、中継サーバ１４２は、受信したコンポーネント管理情報９１’の経路情報に基づいて、コンポーネント「compA」を、中継サーバ１４２からユニキャスト配信するための新たな取得先情報「url-a2」を生成する。そして、この新たな取得先情報を、元の取得先情報「url-a1」（他装置取得先情報）と並存させる形で記述して、図１７（ｃ）のコンポーネント管理情報を生成する。このコンポーネント管理情報が、図１６（ｂ）のコンポーネント管理情報９１’’’の代わりに、以降の中継サーバあるいはクライアント１３３に配信される。
【０２６８】
このようなコンポーネント管理情報を受信したクライアント１３３では、何れかの取得先情報を用いてコンポーネント「compA」を取得する。つまり、クライアント１３３は、取得先情報「url-a1」および「url-a2」から適当な何れかを選択し、選択したＵＲＬにアクセスしてコンポーネント「compA」を取得する。
【０２６９】
無論、コンポーネント管理情報において、１つの経路情報に対応付ける取得先情報の数および取得先情報の値は、図１７（ｃ）の例に限られるものではなく、様々なパターンが適用可能である。
【０２７０】
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
【０２７１】
〔ソフトウェアによる構成例〕
最後に、一次配信サーバ１、９０および二次配信サーバ２、８０の各ブロック、特に制御部２１および４３は、集積回路（ＩＣチップ）上に形成された論理回路によってハードウェア的に実現してもよいし、ＣＰＵ（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）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。
【０２７５】
〔経路情報の例〕
実施形態１の〔その他の例〕に関連して、配信経路を機能面で特定した情報からなる経路情報の例を説明する。
【０２７６】
配信経路を機能面で特定した情報のうち、即時性を示す経路情報としては、コンポーネントの遅延耐性を示す情報、例えば「delay_priority」が挙げられる。「delay_priority」（遅延優先度）とは、コンポーネントを伝送する際に、どの程度まで伝送時の遅延を許容するかを示した指標であり、例えば「レベル３（バイナリ表記では“11”）: high sensitivity: end-to-end delay << 1sec」、「レベル２（“10”）: medium sensitivity: end-to-end delay approx. 1 sec」、「レベル１（“01”）: low sensitivity: end-to-end delay < 5〜10 sec」、「レベル０（“00”）: don't care」のようにレベル分けされた指標で表されるものとする。この場合、遅延を許容しない、即ち遅延耐性の極めて低いコンポーネントはレベル３とレベル付けされ、例えば遅延の無い放送経路で伝送する。十分に遅延を許容する（10秒以上の遅延を許容する、あるいは遅延を全く考慮しない）、即ち遅延耐性の高いコンポーネントはレベル０とレベル付けされ、例えばベストエフォート方式のオープンインターネット経路で伝送する。
【０２７７】
配信経路を機能面で特定した情報のうち、応答性を示す経路情報としては、双方向通信での応答の即時性を示す、例えば「response_priority」が挙げられる。「response_priority」（応答優先度）とは、応答に関する遅延の許容量を示す指標であり、上記したdelay_priorityと同様のレベル分けされた指標で表されるものとする。また、response_priorityは、既に示した双方向配信を示す経路情報「bidirectional」と共に利用される。
【０２７８】
配信経路を機能面で特定した情報のうち、高信頼性を示す経路情報としては、例えば、コンポーネントの誤り耐性を示す情報、例えば「loss_priority」や、コンポーネントの遅延耐性を示す情報、例えば「delay_priority」が挙げられる。「loss_priority」（欠損優先度）とは、コンポーネントを伝送する際に、どの程度まで伝送時の欠損を許容するかを示した指標であり、例えば、「レベル３（バイナリ表記では“11”）: loss priority 0 (Lossless)」、「レベル２（“10”）: loss priority 1 (Lossy, High priority)」、「レベル１（“01”）: loss priority 2 (Lossy, Medium priority)」、「レベル０（“00”）: loss priority 3 (Lossy, Low priority)」のようにレベル付けされた指標で表されるものとする。この場合、欠損を許容しない、即ち誤り耐性の極めて低いコンポーネントはレベル３とレベル付けされ、例えば再送要求等により実質的に欠損の無いユニキャスト通信経路で伝送する。配信経路として見た場合、欠損無し（lossless）の配信経路は信頼性が高いと解釈される。欠損を許容する、誤り耐性を有するコンポーネントは誤り耐性の度合いに応じてレベル２から０にレベル付けされ、マルチキャスト通信や放送経路等で伝送する。また、既に説明した「delay_priority」（遅延優先度）を、高信頼性を示す経路情報と解釈することもできる。例えば、「レベル３（“11”）: high sensitivity: end-to-end delay << 1sec」、「レベル２（“10”）: medium sensitivity: end-to-end delay approx. 1 sec」、「レベル１（“01”）: low sensitivity: end-to-end delay < 5〜10 sec」、「レベル０（“00”）: don't care」のようにレベル付けされた指標で表されるとしたとき、遅延の少ない経路をより信頼性の高い経路と解釈し、高い値にレベル付けする。
【０２７９】
なお、高信頼性を示す経路情報として、コンポーネントの誤り耐性を示す情報とコンポーネントの遅延耐性を示す情報とのうち、いずれか一つを選択して利用してもよいし、両方を選択し組み合わせて利用してもよい。
【０２８０】
ここで、高信頼性を示す経路情報として、コンポーネントの誤り耐性を示す情報とコンポーネントの遅延耐性を示す情報とのうち、いずれか一つを選択して利用する場合の例を示す。例えば、高信頼性を示す経路情報が、優先度「11: loss priority 0 (Lossless)」のloss_priorityであれば、このコンポーネントは欠損無しの経路で配信するのが適当と判断される。このとき、利用可能な配信経路が放送経路あるいは通信経路のいずれかであれば、優先度「11」のloss_priorityは、通信経路でのブロードバンド配信向けであることを直接に示す経路情報、例えば「broadband」に対応すると解釈することができる。また、例えば、高信頼性を示す経路情報が、優先度「11: high sensitivity: end-to-end delay << 1sec」のdelay_priorityであれば、このコンポーネントは遅延無しの経路で配信するのが適当と判断される。このとき、利用可能な配信経路がユニキャスト配信あるいはマルチキャスト配信のいずれかであれば、優先度「11」のdelay_priorityは、要求・応答にかかる処理が少ないマルチキャスト配信向けであることを示す経路情報、例えば「multicast」に対応すると解釈することができる。
【０２８１】
また、図１９は、コンポーネントの誤り耐性を示す情報とコンポーネントの遅延耐性を示す情報との両方を選択し組み合わせて利用する場合に、それらの組合せによって選択すべき配信経路の例を示している。なお、図１９では、それぞれの軸を、既に説明したloss_priority（欠損優先度）、delay_priority（遅延優先度）のレベル付けした優先度値に対応付けて描いている。即ち、誤り耐性の軸は、値が大きいほど誤りの許容量が小さく、値が小さいほど誤りの許容量が大きいものとし、遅延耐性の軸は、値が大きいほど遅延の許容量が小さく、値が小さいほど遅延の許容量が大きいとしている。例えば、コンポーネントの誤り耐性を示す情報として優先度「11: loss priority 0 (Lossless)」のloss_priorityと、コンポーネントの遅延耐性を示す情報として優先度「00: don't care」のdelay_priorityとを選択して組み合わせた場合、これらの組合せはユニキャスト配信向けであることを示す経路情報（例えば「unicast」）に対応すると解釈することができる。また、例えば、優先度が「00: loss priority 3」のloss_priorityと優先度が「11: high sensitivity: end-to-end delay」のdelay_priorityとを選択して組み合わせた場合、これらの組合せは放送配信向けであることを示す経路情報（例えば「broadcast」）に対応すると解釈することができる。
【０２８２】
さらに、１つのコンポーネントをどのように配信するかといったコンポーネントの配信形態に係る要求情報を、経路選択のための情報、即ち本発明で言う経路情報とすることも可能である。配信形態に係る要求情報としては、具体的には同報性、速報性などが考えられる。
【０２８３】
配信形態に係る要求情報のうち、同報性を示す経路情報としては、コンポーネントが一斉配信向けコンポーネントであることを示す情報、例えば「simultaneity_priority」が挙げられる。「simultaneity_priority」（同報優先度）とは、該当のコンポーネントが不特定多数のクライアント向けに一斉配信されるコンポーネントであるか否かを示した指標であり、例えば「レベル３（バイナリ表記では“11”）: priority 0 (simultaneous, many and unspecified)」、「レベル２（“10”）: priority 1 (simultaneous, small and unspecified)」、「レベル１（“01”）: priority 2 (simultaneous, small and specified)」、「レベル０（“00”）: priority 3 (single)」のようにレベル付けされた指標で表すものとする。この場合、不特定多数に一斉配信するコンポーネントはレベル３とレベル付けされ、例えば放送経路で伝送する。クライアントに一対一配信するコンポーネントはレベル０とレベル付けされ、通信経路でユニキャスト配信する。
【０２８４】
配信形態に係る要求情報のうち、速報性を示す経路情報としては、コンポーネントが生成（撮影・録音）されてから実際に配信されるまでにかかる配信待ち時間に係る情報、例えば「live_priority」を挙げてもよい。「live_priority」（ライブ優先度）とは、コンポーネントが生成されてから配信されるまでにかかる時間を配信の遅延と解釈し、その配信遅延についての許容の程度を表した指標であり、例えば「レベル１: priority 0 (immediate)」、「レベル０: priority 1 (don't care)」のようにレベル付けされた指標で表すものとする。この場合、速報性の求められるコンポーネント、即ち生成と共に即配信されるべきコンポーネントはレベル１とし、リアルタイムに配信可能な通信経路で即時配信される。速報性の不要なコンポーネントはレベル０とし、放送経路で適当な時刻に配信されることを許容する。
【０２８５】
これらの配信経路を機能面で示した経路情報、配信形態の要求情報を示した経路情報はコンポーネント管理情報にそれぞれ記述され、それらの情報を組み合わせることで選択部あるいは経路決定部はコンポーネントの実際の配信経路を適宜選択、決定する。例えば、経路情報のうち、即時性、速報性、同報性、単/双方向性を示す経路情報を記述したコンポーネント“compA”のコンポーネント管理情報を以下のように記述する。
<component name="compA"
delay_priority="3"
live_pliority="3"
simultaneity_priority="0"
trans="bidirectional"
… />
【産業上の利用可能性】
【０２８６】
本発明は、マルチコンポーネントコンテンツの配信に利用することができる。
【符号の説明】
【０２８７】
１、１’、１”      一次配信サーバ（対応情報生成装置）
１２、１２’、１２”  経路設定部（経路情報決定手段、対応情報生成手段）
３０    コンポーネント
３１    コンポーネント管理情報（対応情報）
２    二次配信サーバ（配信装置）
４０    第１受信部（受信部）
４０’  第２受信部（受信部）
４０”  第３受信部（受信部）
５１    配信制御部（配信制御手段）
５２    経路決定部（経路決定手段）
６０    コンポーネント
６１    コンポーネント管理情報（対応情報）
８０    二次配信サーバ（配信装置）
５３    サービス設計部（二次対応情報生成手段）
６２    サービス経路情報（二次対応情報）
９０    一次配信サーバ（対応情報生成装置、配信装置）
１５    サービス設計部（二次対応情報生成手段）
１６    選択部（配信制御手段、経路決定手段）
３２    サービス経路情報（二次対応情報）
１３２  サービスプロバイダサーバ（配信装置）
１４２  中継サーバ（配信装置）
【図１】
2014038581.tif 000003
【図２】
2014038581.tif 000004
【図３】
2014038581.tif 000005
【図４】
2014038581.tif 000006
【図５】
2014038581.tif 000007
【図６】
2014038581.tif 000008
【図７】
2014038581.tif 000009
【図８】
2014038581.tif 000010
【図９】
2014038581.tif 000011
【図１０】
2014038581.tif 000012
【図１１】
2014038581.tif 000013
【図１２】
2014038581.tif 000014
【図１３】
2014038581.tif 000015
【図１４】
2014038581.tif 000016
【図１５】
2014038581.tif 000017
【図１６】
2014038581.tif 000018
【図１７】
2014038581.tif 000019
【図１８】
2014038581.tif 000020
【図１９】
2014038581.tif 000021