JP6625318B2 - 送信方法および受信方法 - Google Patents

Description

本発明は、送信方法および受信方法に関する。

従来、コンテンツを配信するための主な伝送路は放送波であり、放送波を用いた放送システムで広く用いられているメディアトランスポート方式として、例えば、ＭＰＥＧ−２
ＴＳ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ−２ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）がある。

一方、近年のネットワーク技術の進展に伴い、インターネットなどの通信路を用いてコンテンツを配信することができるようになっている。つまり、放送波だけでなく通信路も用いてコンテンツを配信できるようになっており、コンテンツを配信可能な伝送路が多様化している。

例えば、非特許文献１には、放送と通信とを併用してコンテンツを配信することを想定した新たなメディアトランスポート方式として、ＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）などがある（非特許文献１参照）。例えば、特許文献１には、放送をメインとして、放送から取得したデータに基づいて、通信コンテンツにアクセスする技術が開示されている。

Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ − Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｃｏｄｉｎｇ ａｎｄ ｍｅｄｉａ ｄｅｌｉｖｅｒｙ ｉｎ ｈｅｔｅｒｏｇｅｎｅｏｕｓ ｅｎｖｉｒｏｎｍｅｎｔ − Ｐａｒｔ１：ＭＰＥＧ ｍｅｄｉａ ｔｒａｎｓｐｏｒｔ（ＭＭＴ）、ＩＳＯ／ＩＥＣ ＤＩＳ ２３００８−１

しかしながら、放送と通信とを併用したコンテンツの配信および配信されたコンテンツを受信するために、コンテンツの受信等に関する情報（サービス情報）を取得してコンテンツの受信を開始することについて議論されているものの、通信によるコンテンツへの迅速なアクセス動作などが考慮されておらず、通信によるコンテンツの受信開始タイミングが遅延するなどの課題がある。

そこで、本発明の目的は、受信側で放送と通信とを併用したコンテンツを再生する際に通信によるコンテンツへの迅速なアクセスを可能とするコンテンツの送信方法を提供することにある。

上記課題を解決するため、本発明の一態様に係る送信方法は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、受信側が受信した場合に前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取らせるための情報であって前記通信路により送信されるコンテンツに関する情報をアプリケーション制御情報に含めて、前記放送波と前記通信路のうちの少なくとも前記放送波を用いて送信する情報送信ステップを含む。

なお、これらの全般的または具体的な態様は、データ受信方法、集積回路、コンピュータプログラムまたはコンピュータで読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、データ送信方法、データ受信方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

本発明によれば、受信側で放送と通信とを併用したコンテンツを再生する際に通信によるコンテンツへの迅速なアクセスを可能とするコンテンツの送信方法等を実現できる。

実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 実施の形態１における伝送路識別デスクリプタの概要の一例を示す図である。 実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の別の一例を示す図である。 実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の別の一例を示す図である。 実施の形態１の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 実施の形態１の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。 実施の形態１における受信装置の構成の一例を示すブロック図である。 実施の形態１の変形例１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 実施の形態１の変形例１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 実施の形態１の変形例１の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 実施の形態１の変形例１の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。 実施の形態１の変形例１における受信装置の構成の一例を示すブロック図である。 実施の形態１の変形例２の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 実施の形態１の変形例２における受信装置の構成の一例を示すブロック図である。 実施の形態１の変形例４の放送通信連携サービスにおけるアプリケーション制御情報のデータ構造の一例を示す図である。 実施の形態１の変形例４の放送通信連携サービスにおけるアプリケーション制御情報のデータ構造の一例を示す図である。 実施の形態１の変形例４の放送通信連携サービスにおけるアプリケーション制御情報のデータ構造の別の一例を示す図である。 実施の形態１の変形例４の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 実施の形態１の変形例４の放送通信連携サービスにおける受信側の動作の比較例を示すフローチャートである。 実施の形態２の実施例１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 実施の形態２の実施例１の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 実施の形態２の実施例２におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。 実施の形態２の実施例２におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。 実施の形態２の実施例２におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。 実施の形態２の実施例２におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。 実施の形態２の実施例３の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 実施の形態２の実施例３の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。 実施の形態２の実施例４の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 実施の形態２の実施例４における受信装置の構成の一例を示すブロック図である。

（本発明の基礎となった知見）
現在、放送と通信とを併用して、コンテンツを配信するサービス（放送通信連携サービス）が検討されている。中でも、放送をメインとして、放送から取得したデータに基づいて、通信から取得したコンテンツ（以下通信コンテンツ）にアクセスする方式が有望である。放送通信連携サービスにおけるコンテンツを受信する受信側での視聴開始時の動作としては、放送のみでコンテンツを配信する従来のサービスと同様に、サービス情報を取得後に、オーディオやビデオの符号化データ、または、ＭＰＥＧ−２システムにおけるデータカルーセルなどによりコンテンツの受信を開始することが考えられている。

しかしながら、従来のサービスで取得できるサービス情報では、通信コンテンツへの迅速なアクセス動作や放送コンテンツのみを選択して受信する際の動作などに対する考慮はされていない。そのため、従来のサービス情報を利用して放送通信連携サービスを行う場合には、サービス情報の解析に係る処理が増加したり通信コンテンツの取得開始タイミングが遅延したりするなどの課題がある。

また、ＩＰＴＶフォーラムにおいて規格化され、ＡＲＩＢ規格においても採用済みのハイブリッドキャスト規格でも同様に、通信コンテンツへの迅速なアクセス動作や放送コンテンツのみを選択して受信する際の動作などに対する考慮はされていない。

ＩＰＴＶフォーラムにおいて規格化され、ＡＲＩＢ規格においても採用済みである従来のハイブリッドキャストの仕様では、通信側においてＨＴＭＬ５のアプリケーションをダウンロードし、イベントメッセージの発火などに伴ってアプリケーションを開始する。そのため、放送側のオーディオやビデオのフレームにおけるＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）やＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）に基づいた通信コンテンツの再生制御には対応しておらず、放送コンテンツと通信コンテンツの表示時刻をフレーム単位で同期させるなど高精度な同期再生には対応できないなどの課題がある。

このような課題を解決するために、本発明の一態様に係る送信方法は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、受信側が受信した場合に前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取らせるための情報であって前記通信路により送信されるコンテンツに関する情報をアプリケーション制御情報に含めて、前記放送波と前記通信路のうちの少なくとも前記放送波を用いて送信する情報送信ステップを含む。

本態様によれば、受信側で放送と通信とを併用したコンテンツを再生する際に通信によるコンテンツへの迅速なアクセスを可能とするコンテンツの送信方法を実現することができる。より具体的には、放送波と通信路を用いてコンテンツを送信した場合には、放送波と通信路とを用いて送信したコンテンツ間との同期を取るための情報がアプリケーション制御情報に含めて送信するので、受信側がこの情報を含むアプリケーション制御情報を受信したときには、受信側にこの情報に従って通信によるコンテンツへの迅速なアクセスをさせることができ、受信側にコンテンツ間の同期を取らせることができる。

ここで、例えば、前記情報送信ステップでは、前記コンテンツを送信するのに先だって前記アプリケーション制御情報を送信し、前記アプリケーション制御情報には、さらに、前記コンテンツの取得先を示すロケーション情報または前記ロケーション情報の取得先を示す情報が含まれているとしてもよい。

また、例えば、前記情報送信ステップでは、さらに、前記アプリケーション制御情報に、前記放送波によるコンテンツの基準クロックと前記通信路によるコンテンツの基準クロックとの差分情報を含めて送信するとしてもよい。

また、例えば、前記情報送信ステップでは、前記アプリケーション制御情報を送信することにより、前記差分情報に基づき前記通信路によるコンテンツの基準クロックを前記放送波によるコンテンツの基準クロックに同期させることで前記受信側に前記同期を取らせるとしてもよい。

また、上記課題を解決するために、本発明の一態様に係る受信方法は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信ステップと、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るため情報であって前記通信路により送信されるコンテンツに関する情報が含まれるアプリケーション制御情報を、前記放送波と前記通信路のうちの少なくとも前記放送波から受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生ステップと、を含む。

ここで、例えば、前記受信ステップでは、前記コンテンツを受信するのに先だって前記アプリケーション制御情報を受信し、前記アプリケーション制御情報に、前記コンテンツの取得先を示すロケーション情報が含まれている場合には、前記ロケーション情報に基づき前記コンテンツを取得することで、前記コンテンツを受信するとしてもよい。

また、例えば、前記受信ステップでは、前記コンテンツを受信するのに先だって前記アプリケーション制御情報を受信し、前記アプリケーション制御情報に、前記コンテンツの取得先を示すロケーション情報の取得先を示す情報が含まれている場合には、前記ロケーション情報の取得先を示す情報に基づき前記ロケーション情報を取得し、取得した前記ロケーション情報から前記コンテンツを取得することで、前記コンテンツを受信するとしてもよい。

また、例えば、前記再生ステップでは、前記受信ステップにおいて、前記放送波によるコンテンツの基準クロックと前記通信路によるコンテンツの基準クロックとの差分情報を含む前記アプリケーション制御情報を受信し、かつ、前記放送波によるコンテンツの基準クロックおよび前記通信路によるコンテンツの基準クロックが異なる場合には、前記差分情報に基づき前記通信路によるコンテンツの基準クロックを前記放送波によるコンテンツの基準クロックに同期させることで前記コンテンツの同期を取る処理を行い、前記コンテンツを再生するとしてもよい。

また、上記課題を解決するために、本発明の一態様に係る送信装置は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信装置であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、受信側が受信した場合に前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための情報であって前記通信路により送信されるコンテンツに関する情報をアプリケーション制御情報に含めて、前記放送波と前記通信路のうちの少なくとも前記放送波を用いて送信する情報送信部を備える。

また、上記課題を解決するために、本発明の一態様に係る受信装置は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信部と、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための情報であって前記通信路により送信されるコンテンツに関する情報が含まれるアプリケーション制御情報を受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生部と、を備える。

なお、これらの全般的または具体的な態様は、送信方法、送信装置、受信方法、受信装置、集積回路、コンピュータプログラムまたはコンピュータで読み取り可能なＣＤ−ＲＯＭなどの記録媒体記録媒体で実現されてもよく、データ受信方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。

以下、本発明の一態様に係る送信方法および受信方法等について、図面を参照しながら具体的に説明する。

なお、以下で説明する実施の形態は、いずれも本発明の一具体例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。

（実施の形態１）
本実施の形態では、放送通信連携サービスにおけるコンテンツを送信および受信する送信方法について説明する。

［送信方法］
本実施の形態では、送信側は、放送波と通信路を用いてコンテンツ（データまたはアセット）を送信するが、コンテンツの送信に先だってサービス情報を送信する。

［サービス情報］
ここで、サービス情報とは、選局動作後（選局後）にオーディオやビデオ、もしくは、データ放送に関連するデータなどを取得するための情報、または、ＥＰＧ（Ｅｌｅｃｔｒｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）の情報など、コンテンツの受信やメタデータの取得に関連する一連の情報を指す。

なお、現状の放送は、主に、ＭＰＥＧ−２ ＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）のセクションを用いて送信され、ＰＡＴ（Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅ）、ＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）、ＮＩＴ（Ｎｅｔｗｏｒｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）、ＣＡＴ（Ｃｏｎｄｉｔｉｏｎａｌ Ａｃｃｅｓｓ Ｔａｂｌｅ）、または、ＡＲＩＢ（電波産業会）において規定されたＥＩＴ（Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）などが含まれる。

本実施の形態では、放送連携サービスにおける放送側の多重化フォーマットとして、ＭＰＥＧで規格化されたＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）を例に挙げて説明する。しかし、この多重化フォーマットはＭＭＴに限定されるものではなく、ＴＳやＭＰＥＧ−ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）など他の多重化フォーマットであってもよい。

本実施の形態におけるサービス情報は、多重化フォーマットに格納できるデータ構造において送信される。例えばＭＭＴでは、サービス情報は、ＭＰＴ（ＭＭＴ Ｐａｃｋａｇｅ Ｔａｂｌｅ）などのテーブル、あるいは、ＰＡ（Ｐａｃｋａｇｅ Ａｃｃｅｓｓ）メッセージなどのメッセージ情報により送信される。なお、各テーブルにおいては、ＴＳと同様に、デスクリプタを用いて補助情報を記述することができる。

図１Ａ及び図１Ｂは、実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。より具体的には、図１Ａには、伝送路識別デスクリプタが含まれたＭＰＴが示されており、図１Ｂでは、図１Ａに示す伝送路識別デスクリプタにおいて、例えばパッケージを構成するアセットの伝送路に関する情報が属性情報として記述されている例が示されている。

（属性情報）
１）パッケージを構成するアセットが、（１）放送のみを用いる、および、（２）放送と通信とを併用のうちのどちらの方法により送信されるかを示す情報を属性情報として含めるとしてもよい。

なお、本編のオーディオとビデオのデータが、（１）放送のみを用いる、および、（２）放送と通信とを併用のうちのどちらの方法により送信されるかを示す情報であってもよい。この情報により、本編が放送のみを用いて送信される場合でも、オーディオ、ビデオ、静止画、あるいは、ＨＴＭＬファイルなどの本編とは別のメタデータなどは、通信ネットワークから取得できる。

２）オーディオやビデオのデータが、放送と通信とを併用して送信される際に、それぞれで送信されるデータの関連を示す情報を属性情報として含めるとしてもよい。

ここで、例えば、スケーラビリティ（時間解像度（６０ｆｐｓ→１２０ｆｐｓなど）、空間解像度（４ｋ→８ｋなど）、ビット深度（８ｂｉｔ→１０ｂｉｔなど））を実現する場合、属性情報により放送は基本レイヤを、通信は拡張レイヤを用いて送信することを示すことができる。なお、属性情報は、放送データのみではフレームレートが６０ｆｐｓであるが、通信データを併用すると１２０ｆｐｓまでフレームレートを向上できるなどを示すとしてもよい。また、放送のバックアップ用のデータを通信で送信することを示してもよい。これにより、送信側は、属性情報を用いて、降雨減衰などで放送の受信状況が悪化した場合には、通信によりデータを送信するように切替えることができる。

また、属性情報は、互いに関連するアセットを識別するための情報を示すとしてもよい。例えば、属性情報が基本レイヤのアセットＩＤと、基本レイヤに対応する拡張レイヤのアセットＩＤを示すとしてもよい。

ＭＭＴでは、同一のアセットを複数の伝送路を用いて送信することも可能である。従って、属性情報は、同一アセットが放送と通信を併用して送信されるかどうかを示してもよい。このとき、当該アセットの識別情報（アセットＩＤなど）を別途示すとしてもよい。関連するアセットを識別するための情報を、例えば図２に示すようにアセット毎の個別の伝送路識別デスクリプタにより示してもよい。ここで、図２は、実施の形態１における伝送路識別デスクリプタの概要の一例を示す図である。図２に示す個別の伝送路識別デスクリプタは、例えば当該アセットが、基本レイヤ、あるいは、拡張レイヤのどちらのアセットであるかを識別するための情報を示すとしてもよいし、当該アセットが拡張レイヤである場合には、対応する基本レイヤのアセットのＩＤなどを示すとしてもよい。

また、属性情報は、放送のアセットと通信のアセットとをそれぞれグループ化し、グループ内に含まれるアセットのリストを示すとしてもよい。放送と通信を併用して送信されるアセットが存在する場合には、別途グループ化してもよい。

３）放送により送信されるオーディオやビデオと、通信により送信されるオーディオやビデオとが、同期再生されるかどうかを示す情報を属性情報として含めるとしてもよい。

なお、属性情報は、個々の情報を個別のフィールドとして示してもよいし、サービスのタイプを示す情報を定義して、タイプにより識別できるようにしてもよい。また、属性情報は、デスクリプタとは異なる形式により記述されるとしてもよい。

また、伝送路識別デスクリプタは、ＭＰＴとは異なる、パッケージ単位の情報を示すテーブルやメッセージに格納するとしてもよい。また、上記の伝送路識別デスクリプタの内容をデスクリプタとは異なるデータ構造として記述してもよい。

また、複数のパッケージを送信する際には、パッケージの一覧を示すテーブルやメッセージを定義して、パッケージ単位の情報として、伝送路識別デスクリプタのような情報をパッケージの属性情報として示してもよい。

図３Ａ及び図３Ｂは、実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の別の一例を示す図である。

すなわち、図３Ａおよび図３Ｂに示すように、アセット毎のロケーション情報については、放送と通信とで送信されるアセットを、それぞれ別のＭＰＴに格納してもよい。このとき、パッケージの属性情報は、サービスのエントリポイントとなる伝送路において送られるＭＰＴに格納できる。例えば、放送がエントリポイントとなる場合には、放送で送られるＭＰＴに格納する。また、これらのＭＰＴはｔａｂｌｅ＿ｉｄにより識別できる。

ＭＭＴ規格では、基準となるＭＰＴのｔａｂｌｅ＿ｉｄの値はゼロと規定されているため、エントリポイントとなる伝送路に対応するＭＰＴのｔａｂｌｅ＿ｉｄをゼロとし、他方の伝送路に対応するＭＰＴのｔａｂｌｅ＿ｉｄを１以上とするなどが可能である。

なお、放送アセットのＭＰＴは放送により、通信アセットのＭＰＴは通信により送信してもよい。

また、放送と通信のアセットのロケーション情報を１つのＭＰＴに格納するとしてもよい。この場合、それぞれのアセットのロケーション情報を連続して格納するなどして容易に識別できるようにすればよい。例えば、放送のアセットがＮ１個、通信のアセットがＮ２個存在する場合には、まず、Ｎ１個の放送アセットの情報を連続して記述し、その後にＮ２個の通信アセットの情報を連続して記述する。なお、伝送路識別デスクリプタにおいて、Ｎ１個のアセットが放送において、Ｎ２個のアセットが通信において送信される旨を示してもよい。

このように、送信側において、サービス情報に補助情報である伝送路識別デスクリプタを含めて送信する。それにより、受信側において、補助情報を含むサービス情報を取得するだけで、伝送路識別デスクリプタに記述されるパッケージの属性情報により、通信のデータが含まれるかどうか、あるいは、放送データと通信データとの依存関係などを、アセット毎の情報を解析することなく前もって取得できる。

特に、通信データを受信する際には、受信処理の起動に係る遅延時間を短縮できるというメリットがある。

［送信装置］
例えば、本実施の形態の送信装置は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信装置であって、補助情報として伝送路識別デスクリプタなどパッケージの属性情報を生成し、サービス情報に含めて送信する。

本実施の形態の送信装置は、このサービス情報を、周期的に送信してもよい。このサービス情報の内容が更新される際には、更新直後にその更新した内容をサービス情報において反映する。

また、エントリポイントは、放送に限定されるものではなく、通信であってもよいし、放送と通信の両方からエントリできるようにしてもよい。なお、両方からエントリ可能とする際には、パッケージ単位の情報については、少なくとも、放送と通信の両方の送信装置から送信する。

なお、受信側において放送通信連携サービスのコンテンツを受信する際には、必ずしも両伝送路により送られるデータを受信しなくてもよい。例えば、放送のデータのみを受信して再生するとしてもよい。このとき、受信側が通信データを受信する際に必要となる情報は、放送データの受信時には不要であるため、送信側は通信データを受信する際に必要となる情報を通信において送信するとしてもよい。すなわち、送信側は、パッケージ単位の情報についてエントリポイントとなる伝送路において送信し、放送、通信など伝送路に固有の情報は、それぞれの伝送路において送信するとしてもよい（例えば図２）。なお、以下では、放送がエントリポイントであるとして説明する。

こうすることで、各伝送路に固有のサービス情報は、各伝送路における送信装置が生成して送信できる。ただし、アセットのロケーション情報などＭＰＴにより送信される情報は、最初に一括して取得することで、通信側のアセットの取得開始に係る遅延時間が低減できるため、放送で送信してもよい。

（通信に固有の情報の例）
通信（インターネット、ＣＤＮ（Ｃｏｎｔｅｎｔｓ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）などの通信ネットワーク）に固有の情報の例を示す。

１）例えばＦＥＣの方式、パラメータなど、通信により送信するパケットにおけるＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）に関連する情報

２）例えばパケットロス率や、パケット到着時刻のジッタ、あるいは、ＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）、通信伝送路におけるｅｎｄ−ｔｏ−ｅｎｄ遅延など、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）コントロールに関連する情報

３）例えばバッファリング時間、バッファリング量など、アセットのデータを受信してから復号開始するまでのバッファリングに関する情報

なお、放送においても、特に移動体向けの放送（日本における１セグメント放送など）においては、ＦＥＣやＱｏＳが重要となるが、これらにおけるパラメータは通信路とは異なる。そのため、放送に固有の情報は、放送においてのみ送信すればよい。

一方、通信においては、ビットレートやフレームレートなど、通信ネットワークの帯域に応じた複数のオーディオやビデオデータを選択可能とすることができる。このとき、選択可能なデータの属性情報（ビットレートなど）とアセットＩＤとを対応付ける情報を送信してもよい。なお、このような対応付ける情報は、放送において送信してもよい。

なお、対応付ける情報として、選択可能な複数のアセットが存在するかどうかを示す情報を示してもよいし、選択可能な複数のアセットが存在する場合に、選択可能なアセットのリストを示してもよい。

［受信方法］
本実施の形態では、受信側は、サービス情報を取得後に、コンテンツの受信（取得）を開始する。以下、図を用いて、本実施の形態における受信方法について説明する。

図４Ａは、実施の形態１の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。図４Ａには、受信装置が本実施の形態の伝送路識別デスクリプタを取得して、受信するアセットを決定する動作の一例が示されている。

まず、エントリポイントとなる伝送路において送信されるサービス情報として例えばＰＡメッセージ、あるいは、ＭＰＴメッセージなどに含まれるＭＰＴテーブルを取得して、その中に含まれる伝送路識別デスクリプタを取得する。

次に、放送と通信を併用してアセットが送信されるかどうか、及び、両伝送路が使われる際には、放送と通信のアセットの依存関係など、伝送路識別デスクリプタの情報を解釈する（ステップＳ１０１）。

ＰＡメッセージなどのメッセージは、ＭＭＴパケットなどのパケットのペイロードに格納され、パケットヘッダにより、格納されるデータの種別が示される。従って、ＭＭＴパッケージの受信時には、まず、パケットヘッダにおけるＩＤ番号（ＭＭＴパケットではｐａｃｋｅｔ＿ｉｄに相当）を参照して、ＰＡメッセージのＭＭＴパケットを取得する。

次に、端末の再生能力、あるいは、通信路が利用可能かどうかなどに基づいて、受信するアセットを決定する（ステップＳ１０２）。

ここで、アセットの決定方法の例について説明する。

１）受信装置が通信ネットワークに接続していない場合には、放送のアセットのみ受信すると決定する。このとき、放送と通信とを併用して送信されるアセットは受信しない。

２）ビデオの基本レイヤが放送、拡張レイヤが通信により送信される場合に、基本レイヤのみ再生可能な場合には放送のみを、両レイヤを再生可能な場合には放送と通信とを共に受信すると決定する。例えば、基本レイヤのみで６０ｆｐｓ、基本レイヤおよび拡張レイヤで１２０ｆｐｓの時間スケーラビリティが実現できるとする。この場合に受信装置が６０ｆｐｓまでしか復号、表示できなければ放送のみを、１２０ｆｐｓまで復号、表示できる場合には放送と通信の両データを受信する。

３）受信装置が接続する通信ネットワークの帯域に応じて、通信により送信されるビットレートの異なる複数のアセットから、受信可能なアセットを決定する。ここで、例えば、各アセットのビットレートなどの情報は、別途サービス情報などにおいて送信されるものとする。なお、通信ネットワークの輻輳などにより受信状態が悪く、安定して受信可能なアセットが存在しない場合には、通信側のデータを受信しないと決定してもよい。

４）また、放送の受信環境悪化に備えて、通信においてバックアップ用のデータが送信されている場合、受信環境が悪化したときには取得するアセットを決定するとしてもよい。この場合、受信装置は、受信環境をモニタし、受信データにおけるエラー率などの指標に基づいて、通信のアセットを受信するかどうかを判定し、受信処理を行えばよい。

５）放送により送信される本編のオーディオやビデオのデータと同期再生されるデータ（ビデオにおける拡張レイヤのデータなど）を通信から受信する際には、放送により受信したデータと通信により受信したデータの同期を保証するために、再生開始前にデータをバッファリングするなど特別な動作が必要となる場合がある。この場合において、通信からは、放送により送信されるデータと厳密な同期（例えば、フレーム単位での同期など）が必要でないアセットのみ受信することとしてもよい。例えば、ＨＴＭＬなどのデータ、静止画、厳密な同期が不要な動画などのアセットであれば通信から取得すると決定するとしてもよい。

以下、図４Ａのフローチャートに戻って説明する。

次に、ステップＳ１０３では、通信により送信されるアセットを受信するかどうかを決定（判定）し、受信すると決定（判定）した場合（Ｓ１０３ではい）、Ｓ１０４に進み、受信しないと決定（判定）した場合（Ｓ１０３でいいえ）には、Ｓ１０５に進む。

Ｓ１０４では、放送と通信との両伝送路からアセットを受信し、Ｓ１０５では、放送のみからアセットを受信する。

図４Ｂは、実施の形態１の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。

図４Ｂは、図４Ａと比較して、通信に固有のサービス情報が通信において送信される場合に、当該サービス情報を受信するステップ（ステップＳ１０６）が追加されている。その他については、図４Ａで説明したものと同様のため、説明を省略する。

なお、放送に固有のサービス情報が存在する場合には、図示しないステップにおいて別途受信するものとする。

また、受信装置が放送通信連携サービスに対応していない場合には、放送のアセットのみを受信するとすればよい。この場合、放送と通信とを併用して送信されるアセットが存在する場合には、当該アセットは受信しない。

［受信装置］
図５は、実施の形態１における受信装置の構成の一例を示すブロック図である。図５では、図４Ａで説明した受信方法を実現する受信装置の構成の一例が示されている。

図５に示す受信装置１００は、識別情報取得部１０１と、アセット決定部１０２と、判定部１０３と、放送受信部１０４と、通信受信部１０５とを備える。

識別情報取得部１０１は、図４Ａに示すステップＳ１０１を実現する機能を備える。具体的には、識別情報取得部１０１は、エントリポイントとなる伝送路において送信されるサービス情報を取得し、その中に含まれる伝送路識別デスクリプタ（補助情報）を取得する。そして、識別情報取得部１１は、伝送路識別デスクリプタの情報を解釈する。

アセット決定部１０２は、図４Ａに示すステップＳ１０２を実現する機能を備え、端末の再生能力、あるいは、通信路が利用可能かどうかなどに基づいて、受信するアセットを決定する。

判定部１０３は、図４Ａに示すステップＳ１０３を実現する機能を備え、通信により送信されるアセットを受信するかどうかを決定（判定）する。具体的には、判定部１０３は、通信データを受信するかどうかを判定し、受信すると判定した場合には放送受信部１０４および通信受信部１０５において、ステップ１０２において決定したアセットのデータを受信する。

判定部１０３は、通信データを受信しないと判定した場合には、放送受信部１４のみを用いてデータを受信する。

（変形例１）
本変形例では、放送はＴＳを用いて送信し、通信はＤＡＳＨやＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などを用いて送信する場合の例について説明する。

図６Ａ及び図６Ｂは、実施の形態１の変形例１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。図６Ａには、通信において送信されるデータに関する情報をＰＭＴに格納する例が示されている。図６Ｂには、本変形例の伝送路識別デスクリプタのデータ構造の一例が示されている。

本変形例では、サービス情報の一例であるＰＭＴに、図１Ａおよび図１Ｂにおいて説明した属性情報など示す伝送路識別デスクリプタが格納される。

ＰＭＴなどＴＳにおけるプログラム情報では、ＴＳにより送信されるデータのロケーション情報のみが示される。そのため、本変形例では、コンテンツのデータが通信を併用して送信される際には、通信側のデータのロケーション情報を伝送路識別デスクリプタに格納する。より具体的には、属性情報において、通信が併用されるかどうかを示すフラグ情報を含める。これにより、送信側は、当該フラグ情報の値に応じて、通信側のデータのロケーション情報を含めるかどうかを選択することができる。なお、ロケーション情報は、伝送路識別デスクリプタに格納される場合に限らない。別途デスクリプタを定義して、ロケーション情報を格納してもよい。

（ロケーション情報）
ロケーション情報とは、データの取得先を示す情報であり、ＴＳであればＰＩＤ、通信であればＵＲＬやＵＲＩなどが相当する。

ロケーション情報としては、ＤＡＳＨのＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）や、ＲＴＰにおけるＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）などを格納してもよい。

また、ロケーション情報には、ＭＰＤやＳＤＰなどのロケーション情報の実体データを格納する場合に限らず、ロケーション情報の実体データの取得先を示す情報を格納するとしてもよい。ここで、ロケーション情報の実体データの取得先を示す情報は、例えば、ＭＰＤを取得するためのＵＲＬを示す情報などである。ただし、ロケーション情報にロケーション情報の実体データの取得先を示す情報を格納する場合には、ロケーション情報の実体データを別途取得するための遅延が発生する。そのため、通信側のデータを受信開始するまでの遅延を低減する観点から、ロケーション情報には、実体データを直接格納するのが望ましい。

なお、ＤＡＳＨのＭＰＤには、コンテンツの取得先に関して様々な情報が含まれるため、サイズが大きい。従って、ロケーション情報にＭＰＤをそのまま格納するのではなく、コンテンツの取得先のＵＲＬと、セグメントのＤＴＳやＰＴＳに関する情報のみを含むサブセット化した情報を格納するとしてもよい。

また、ＭＰＤなどロケーション情報の内容の更新にも対応できることが望ましい。

例えば、ロケーション情報に対してバージョン番号を付与するなどしてもよい。これにより、バージョン番号が更新された場合には、ロケーション情報を取得し直すことができる。なお、バージョン番号が更新されたかどうかを確認するために、周期的に送信されるＰＭＴ内の伝送路識別デスクリプタなどの情報を逐次チェックしてもよい。しかし、この逐次チェックの処理は重いため、ロケーション情報などを格納するためのセクションデータを別途生成（伝送路識別セクションと呼ぶ）し、周期的に送信するとしてもよい。

受信装置においては、伝送路識別セクションにおけるバージョン番号を確認すればロケーション情報が更新されたかどうかを判定できる。なお、ＰＭＴなどのプログラム情報と、伝送路識別セクションの双方において、属性情報やロケーション情報を送信してもよい。あるいは、伝送路識別セクションにおいては、ロケーション情報のみを格納してもよい。

また、放送から取得したロケーション情報に基づいて通信側のデータを取得開始した後は、通信においてロケーション情報の更新内容を取得してもよい。このとき、ロケーション情報の取得先が必要となるため、放送の伝送路識別デスクリプタなどにおいて、ロケーション情報の実体データと共に、ロケーション情報の取得先も合わせて格納してもよい。

受信装置では、ロケーション情報の取得先に定期的にアクセスするなどして、通信において更新内容を取得できる。

また、ＤＡＳＨコンテンツの配信サーバと受信装置との間でメッセージ交換などの仕組みが存在する場合には、ロケーション情報が更新されたことを示すメッセージをサーバが受信装置に対して発行するとしてもよい。そして、受信装置では、メッセージを受信した際にはロケーション情報を取得し直すなどしてもよい。

なお、通信において送信されるデータに関する情報をＰＭＴに格納するとして説明したがこれに限らない。属性情報やロケーション情報を、ＰＭＴとは異なるセクションにより送信するとしてもよい。

また、通信において送信されるデータが、放送におけるオーディオやビデオと同期再生されるかどうかに基づいて、通信側のデータの取得方法を切替えてもよい。

例えば、同期再生される場合には、上述したように放送のプログラム情報から通信側のデータにアクセスできるようにする。同期再生されない場合には、ＡＲＩＢ（電波産業会）におけるハイブリッドキャスト仕様に規定されたＡＩＴ（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）などを用いて、通信側のデータにアクセスするための情報をデータ放送により送信してもよい。受信装置では、テーブル、あるいは、カルーセルなどの形式でＡＩＴを受信し、ＡＩＴの内容に基づいて通信側のデータを取得する。取得した通信側のデータは、データ放送により送信されるイベントメッセージを受信すると、再生開始される。

なお、放送データと通信データとが同期再生される場合にも、ＡＩＴなどの情報を利用してもよい。このとき、通信側のデータの再生開始、終了などの時刻は、別途データ放送内に示されるものとする。受信装置では、これらの時刻に従って、通信側のデータを再生する。

ＤＡＳＨにおけるＭＰＤや、ＲＴＰにおけるＳＤＰでは、コンテンツの再生開始時刻、あるいは、復号開始時刻を示すことができ、これらの時刻はＵＴＣ（Ｃｏｏｒｄｉｎａｔｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｉｍｅ）など、多重化や伝送の方式毎に規定される基準クロックに基づいて指定される。また、個々のビデオフレームやオーディオのサンプルのＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）やＤＴＳ（Ｄｅｃｏｄｉｎｇ
Ｔｉｍｅ Ｓｔａｍｐ）も、基準クロックに基づいて設定される。一方、放送では、ＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）が基準クロックとなるため、放送側のデータと通信側のデータとを同期再生する際には、 互いの基準クロックの対応関係を示す情報が必要となる。

従って、放送側のデータと通信側のデータの基準クロックの対応関係を示す情報を、放送におけるＰＭＴなどのプログラム情報に含めてもよい。例えば、放送におけるＰＣＲの値がＮ１である時刻と、通信におけるＵＴＣの値がＮ２である時刻が同一時刻に相当するなどの情報であってもよい。なお、これらの情報は、ＭＰＤやＳＤＰなどに含めてもよい。

また、伝送路識別デスクリプタにおいて、通信側のデータが、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）、及び、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）のいずれによって送信されるかなど、トランスポート層のプロトコルの情報を示してもよい。これにより、受信装置においては、各プロトコルにおいて使用するポートをオープンする、あるいは、使用されるプロトコルに対応しているかどうか判断するなどが可能となる。

また、通信側のデータにおける多重化フォーマットの識別情報を示して、例えば、ＤＡＳＨ、あるいはＲＴＰであるかどうかなどを識別できるようにしてもよい。

［受信方法］
以下、図を用いて、本変形例における受信方法として、放送がＴＳを用いて送信され、通信がＤＡＳＨやＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などを用いて送信される場合の受信装置の動作の一例について説明する。

図７Ａは、実施の形態１の変形例１の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。図７Ａには、属性情報やロケーション情報が放送のプログラム情報に格納される際の受信装置の動作の一例が示されている。

各ステップ（ステップＳ２０１〜ステップＳ２０５）の動作は、図４Ａのフローチャートと同様であるが、図４Ａにおいては、放送側と通信側とのデータがＭＭＴパッケージのアセットで統一されていたのに対し、図７Ａでは放送側はＴＳ、通信側はＤＡＳＨやＲＴＰのデータとなる点において異なる。それ以外の点については、図４Ａで説明した通りであるため、詳細な説明は省略する。

図７Ｂは、実施の形態１の変形例１の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。図７Ｂでは、放送のプログラム情報において、属性情報、及び、ロケーション情報を取得するためのアクセス情報が格納され、ロケーション情報の実体は格納されない場合の動作の一例が示されている。

ステップＳ３０１は、ステップＳ２０１と同様であるので、説明を省略する。

次に、ステップＳ３０２において、通信側のデータを受信するかどうかを決定（判定）し、ステップＳ３０３において、通信側のデータを受信する際にはＳ３０４に進み、通信側のデータを受信しない場合にはＳ３０６に進む。

ステップＳ３０４では、放送のプログラム情報に含まれる通信側データのロケーション情報の取得先に従って、ロケーション情報を取得する。

一方、ステップＳ３０５では、Ｓ３０４で取得したロケーション情報に基づいて通信側データを取得すると共に、放送データを取得する。また、Ｓ３０６では、放送により送信されるデータのみを取得する。

（属性情報）
属性情報は、実施の形態１において説明した内容と同様であるが、実施の形態１ではＭＭＴを例に説明したため、以下、放送がＴＳ、通信がＤＡＳＨやＲＴＰを用いる際の例について説明する。

１）コンテンツを構成するオーディオやビデオなどのデータが、（１）放送のみを用いる、および（２）放送と通信を併用のうちのどちらの方法により送信されるかを示す情報を属性情報として含めるとしてもよい。

なお、オーディオとビデオのデータが、（１）放送のみを用いる、および、（２）放送と通信とを併用のうちのどちらの方法により送信されるかを示す情報であってもよい。この情報により、本編が放送のみを用いて送信される場合でも、オーディオ、ビデオ、静止画、あるいは、ＨＴＭＬファイルなどのメタデータなどは、本編とは別の通信ネットワークから取得できる。

２）オーディオやビデオが、放送と通信とを併用して送信される際に、それぞれで送信されるデータの関連を示す情報を属性情報として含めるとしてもよい。

ここで、例えば、スケーラビリティ（時間解像度（６０ｆｐｓ→１２０ｆｐｓなど）、空間解像度（４ｋ→８ｋなど）、ビット深度（８ｂｉｔ→１０ｂｉｔなど））を実現する場合に、属性情報により放送は基本レイヤを、通信は拡張レイヤを用いて送信することを示すことができる。属性情報は、ユースケースとして、放送データのみではフレームレートが６０ｆｐｓであるが、通信データを併用すると１２０ｆｐｓまでフレームレートを向上できるなどを示すとしてもよい。また、属性情報は、放送のバックアップ用のデータを通信で送信することを示してもよい。これにより、送信側は、属性情報を用いて、降雨減衰などで放送の受信状況が悪化した場合には、通信によりデータを送信するように切替えることができる。

また、属性情報は、互いに関連する符号化ストリームを識別するための情報を示すとしてもよい。例えば、属性情報は、放送で送信される基本レイヤのデータが格納されるＴＳパケットのＰＩＤと、通信で送信されるＤＡＳＨデータにおけるセグメント、あるいは、ＭＰ４におけるトラックＩＤなどのビデオデータの識別情報を示すことができる。

また、属性情報は、互いに同期再生される放送側のデータと、通信側のデータを示す情報を示すとしてもよい。これにより、送信側は、複数視点の映像、あるいは、ピクチャ・イン・ピクチャにおける親画面と子画面の映像を、それぞれ放送と通信とにより送信するなどができる。

３）放送により送信されるオーディオやビデオなどと、通信により送信されるオーディオやビデオなどとが、同期再生されるかどうかを示す情報を属性情報として含めるとしてもよい。

４）放送により送信されるオーディオやビデオのクロック情報と、通信により送信されるオーディオやビデオのクロック情報とが、同じかどうかを示す情報を属性情報として含めるとしてもよい。

５）通信側のデータがライブコンテンツであるかどうかを示す情報を属性情報として含めるとしてもよい。

例えば、送信されるコンテンツがライブコンテンツでなければ、現在時刻（Ｔ１）よりも後のデータを取得することができる。従って、コンテンツの取得要求から受信開始するまでにかかる時間（あるいは、その推定値）、及び、データをバッファリングする時間の総和（△Ｔ）を現在時刻に加算した時刻（Ｔ２）が再生時刻となるデータから受信開始することで、放送側のデータを遅延させることなく再生できる。この時、通信側のデータは時刻Ｔ２から再生される。一方、送信されるコンテンツがライブコンテンツである場合には、放送側のデータを△Ｔだけバッファリングして、時刻Ｔ２において放送と通信のデータを共に再生開始するなどしてもよい。

なお、通信側がコンテンツをＲＴＰなどによりマルチキャスト、あるいは、ブロードキャストする場合には、そのコンテンツがライブコンテンツであるかどうかに関わらず、現在時刻よりも後のデータは取得できない。従って、通信側のデータがマルチキャストやブロードキャストであるかどうかを示す情報も属性情報に含めるとしてもよい。

［受信装置］
次に、放送がＴＳを用いて送信され、通信がＤＡＳＨやＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などを用いて送信される場合の受信装置の構成の一例について説明する。

図８は、実施の形態１の変形例１における受信装置の構成の一例を示すブロック図である。図８では図７Ｂで説明した受信方法を実現する受信装置の構成の一例が示されている。

図８に示す受信装置３００は、識別情報取得部３０１と、決定部３０２と、通信併用判定部３０３と、Ｌｏｃ情報取得部３０４と、放送受信部３０５と、通信受信部３０６とを備える。なお、図７Ａを実現する受信方法を実現する受信装置の構成は、図８で、Ｌｏｃ情報取得部３０４がない場合に対応する。

識別情報取得部３０１は、図７Ｂに示すステップＳ３０１を実現する機能を備える。具体的には、識別情報取得部３０１は、エントリポイントとなる伝送路において送信されるサービス情報を取得し、その中に含まれる伝送路識別デスクリプタ（補助情報）を取得する。そして、識別情報取得部３０１は、伝送路識別デスクリプタの情報を解釈する。

決定部３０２は、図７Ｂに示すステップＳ３０２を実現する機能を備え、端末の再生能力、あるいは、通信路が利用可能かどうかなどに基づいて、受信するデータを決定する。

通信併用判定部３０３は、図７Ｂに示すステップＳ３０３を実現する機能を備え、通信により送信されるデータを受信するかどうかを決定（判定）する。

Ｌｏｃ情報取得部３０４は、図７Ｂに示すステップＳ３０４を実現する機能を備え、通信側データのロケーションデータを取得する。

（変形例２）
本変形例では、属性情報やロケーション情報が放送のプログラム情報に格納されて送信される場合の受信方法の一例について説明する。

［受信方法］
図９は、実施の形態１の変形例２の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。図９には、属性情報やロケーション情報が放送のプログラム情報に格納されて送信される場合に受信装置が放送コンテンツと通信コンテンツとを同期再生するかどうかを判定して再生するまでの動作例について示されている。

なお、図９の動作は、図７Ａにおける動作に基づいているが、送信データをＭＭＴのアセットとせずに、より一般的なコンテンツとした場合の例として記載している。

まず、エントリポイントとなる伝送路において送信されるプログラム情報を取得して、その中に含まれる伝送路識別デスクリプタを取得し、コンテンツの属性情報や通信コンテンツのロケーション情報を取得する（ステップＳ４０１）。

ここで、ロケーション情報の実体がプログラム情報に格納されない場合には、図７Ｂで説明したのと同様の方法によりロケーション情報の実体データを取得する。

次に、受信装置の再生能力、あるいは、通信路が利用可能かどうかなどに基づいて、受信するデータを決定する（ステップＳ４０２）。

次に、通信コンテンツを取得するかどうかを決定し（ステップＳ４０３）、通信コンテンツを取得すると決定した場合には（Ｓ４０３ではい）、ステップＳ４０４に進み、放送と通信の両伝送路からデータを受信する。なお、受信しないと決定（判定）した場合（Ｓ４０３でいいえ）には、ステップＳ４０９に進み、放送のみからデータを受信して、ステップＳ４１０で放送コンテンツのみを再生する。

次に、放送コンテンツと通信コンテンツを同期再生するかどうかを判定する（ステップＳ４０５）。

同期再生すると決定した場合には（Ｓ４０５ではい）、ステップＳ４０６において放送コンテンツと通信コンテンツとの基準クロックを同期させて、ステップＳ４０７において両者を同期再生する。

なお、Ｓ４０６における基準クロックの同期は、Ｓ４０４に先立って実施するとしてもよい。これは、コンテンツの受信データをプリバッファリングしてから再生開始する場合などでは、放送コンテンツにおいてＰＴＳがＴ１となるデータと、通信コンテンツにおいてＰＴＳがＴ１となるデータ（ここで、互いのＰＴＳは既に同期されているものとする）が受信済みとなることを確認して復号、再生を開始することがあり、互いに同期再生されるデータが揃っているかどうかを判定する際に、両者の基準クロックが同期済みであることが必要となるためである。

また、Ｓ４０６における基準クロックの同期においては、放送、あるいは、通信のいずれかで使用されている基準クロックに揃えることができる。例えば、放送においてＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）が用いられ、通信においてＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）が用いられる場合には、ビデオやオーディオにおけるＮＴＰ基準でのＤＴＳやＰＴＳを、ＰＣＲ基準に変換することで、放送と通信とにおける基準クロックを同期できる。また、受信装置内で使用される固有のクロックと同期するように、放送と通信とのＤＴＳやＰＴＳを変換してもよい。

なお、図９では、属性情報やロケーション情報が放送のプログラム情報に格納されて送信される場合の動作について説明したが、そもそも同期再生される必要がなければ、これらの情報を記述した伝送路識別デスクリプタが放送のプログラム情報に格納されないとしてもよい。

また、基準クロックの同期においては、放送、あるいは、通信のいずれかで使用されているクロックに揃えることが可能である。例えば、放送においてＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）が用いられ、通信においてＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）が用いられる場合には、ビデオやオーディオにおけるＮＴＰ基準でのＤＴＳやＰＴＳを、ＰＣＲ基準に変換することで、放送と通信における基準クロックを同期できる。なお、受信装置内で使用される固有のクロックと同期するように、放送と通信のＤＴＳやＰＴＳを変換するとしてもよい。

［受信装置］
図１０は、実施の形態１の変形例２における受信装置の構成の一例を示すブロック図である。図１０では、図９で説明した受信方法を実現する受信装置の構成の一例が示されている。

図１０に示す受信装置４００は、識別情報取得部４０１と、決定部４０２と、通信併用判定部４０３と、Ｌｏｃ情報取得部４０４と、放送受信部４０５と、通信受信部４０６と、同期判定部４０７と、再生部４０８とを備える。

識別情報取得部４０１〜通信受信部４０６は、図８で説明した識別情報取得部３０１〜通信受信部３０６と同様であるので説明を省略する。

同期判定部４０７は、図９に示すステップＳ４０５の処理を行う機能を備える。

再生部４０８は、通信併用判定部４０３、及び、同期判定部４０７手段における判定結果により決定された再生方法に基づいて、放送コンテンツあるいは通信コンテンツを復号して、再生する。

（変形例３）
以下では、上記で説明したものと異なるものをその他の例として説明する。

［その他１］
伝送路は、放送と通信との組合せに限定されるものではなく、放送と放送、通信と通信など同種の伝送路の組合せであってもよい。

また、伝送路識別デスクリプタのようなパッケージ単位の情報が示されない場合には、図１Ａおよび図１Ｂに示したようなアセット毎のロケーション情報を解釈することで、各アセットが放送と通信とのどちらにより送信されるか、あるいは、パッケージ内に通信により送信されるアセットが存在するかどうかなどを決定してもよい。

（ロケーション情報）
ロケーション情報においては、アセットの取得先のＵＲＬ情報などを含むとしてもよい。取得先がＵＲＬである場合には、当該ＵＲＬが、放送サービスにおいて予め規定された特定のＵＲＬであるかどうかに基づいて、アセットが放送、通信のどちらで送信されるかを決定できる。

例えばＭＰＴなどのメッセージ情報と同一のストリームにおいて放送アセットが送信される場合には、ロケーション情報において、放送アセットの取得先として、アセットのデータを格納するパケットのＩＤ（ＭＭＴパケットの場合はｐａｃｋｅｔ＿ｉｄ）が示され、通信により送信されるアセットについては、取得先としてＵＲＬが示される。従って、ロケーション情報において、取得先がＵＲＬであるかどうかに応じて、アセットが通信により送信されるかどうかを決定してもよい。

（ＭＰＴの記述の変形例）
上記図１Ａおよび図１Ｂにおいては、アセット毎の情報として、アセット毎のロケーション情報、及び、個別の伝送路識別デスクリプタを定義した場合を説明したが、それに限らない。アセットの符号化方式を示すフィールドを別途設けてもよい。符号化方式は復号時に必須の情報であり、ＭＰＴのように復号に先立って取得できる情報においてシグナリングすることが望ましい。例えば、ＭＰＥＧ−２システムにおけるｓｔｒｅａｍ＿ｔｙｐｅのような情報を用いることが可能である。

また、スケーラブルな符号化が可能な符号化方式である場合には、符号化方式と共に、当該アセットが基本レイヤであるか、拡張レイヤであるかを示してもよい。

また、同一ＭＭＴパッケージにおいて、時間スケーラビリティを有するビデオが２つ存在する場合など、スケーラビリティを有するアセットが複数含まれるケースもある。このとき、拡張レイヤのアセットが、どの基本レイヤのアセットと対応するかを示す情報を示してもよい。例えば、拡張レイヤのアセットに対しては、対応する基本レイヤのアセットのアセットＩＤを示してもよい。また、拡張レイヤと基本レイヤのアセットをグループ化して、各アセットに対してグループのＩＤを割り振ってもよい。

これらの情報は、放送はＴＳを利用し、通信はＤＡＳＨやＲＴＰなどを利用する場合でも、放送におけるプログラム情報などにおいて示すことができる。例えば、ＰＭＴのデスクリプタ等において、放送で送信されるビデオストリームと通信で送信されるビデオストリームとの間の依存関係（通信側のビデオストリームが拡張レイヤに相当するなど）、あるいは、通信側のビデオやオーディオの符号化方式を示す情報を記述できる。また、放送側のストリームと通信側のストリームとが同期再生されるかどうかなどを示してもよい。

（伝送路に関する情報）
コンテンツのデータが放送のみで送信されるか、あるいは、放送と通信を併用して送信されるかなどを示す情報は、ＥＰＧなどの番組情報に格納してもよい。

例えば、ＥＰＧから視聴選択、あるいは、録画予約を行う場合に、通信ネットワークに接続していない、あるいは、受信装置が通信によるデータの取得に対応していないなど、通信により送信されるデータが再生、あるいは、録画できない場合には、その旨を示すメッセージ情報を表示してもよい。

さらに、通信により送信されるデータが、番組の開始時刻に先立って取得可能であるかどうかを示す情報を格納してもよい。特に、ＤＡＳＨなどダウンロード型の方式では、番組開始に先立って通信側のデータをダウンロードしておくことで、番組開始時刻において、放送のデータと通信のデータを共に再生開始することができる。

例えば通信側のデータが番組開始時刻に先立って取得可能である場合には、受信装置は、番組開始時刻よりも前に通信側のデータを受信開始するとしてもよい。このとき、予め定めたバッファリングのデータ量、あるいは、バッファリング時間分のデータが番組開始時刻において受信できるように、受信開始時刻を決定する。

また、例えば、番組の予約録画などにおいても同様に動作してもよい。

なお、放送などでは、ユーザーが複数の番組を任意のタイミングで選択可能であり、視聴中のチャネルの次番組の通信データを予め受信しても、視聴番組の切替えが発生すると、通信データを予め受信してもメリットが得られない。そこで、任意の視聴時刻において、当該視聴時刻よりも後に視聴可能であって、放送と通信を併用してデータが送信される全ての番組について、通信側のデータを予めバッファリングしておくように動作してもよい。全ての番組のデータを受信できない場合には、受信可能な範囲内で番組を選択し、受信してもよい。

また、放送側のデータと通信側のデータが同期再生されるかどうかを示す情報もＥＰＧなどの番組情報に含めておいて、同期再生される場合には、通信側のデータを予めバッファリングするように動作してもよい。同期再生されない場合は、放送側のデータの受信開始後に通信側のデータを受信開始してもよい。

なお、ＥＰＧにこのような情報が含まれない場合でも、ＭＭＴにおけるＭＰＴ、あるいは、放送にＴＳを用いる際のＰＭＴなどを解析して同様の情報を取得して、同様のメッセージを表示できる。

また、日本における放送方式（ＩＳＤＢ−Ｔ）におけるＴＭＣＣ信号など、伝送路で伝送される信号を復調する際の制御情報において、これらの情報を格納してもよい。

こうすることで、通信における受信が必要かどうかを、復調時に判定でき、通信側の起動を早めることができる。

（フォーマット）
なお、ＨＴＴＰベースのファイルフォーマットはＤＡＳＨに限定されるものではなく、ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）やＭｉｃｒｏｓｏｆｔ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ（ＭＳＳ）などであってもよく、これらの方式においても、ＭＰＤに相当するコンテンツ管理情報が存在するため、ＤＡＳＨと同様の仕組みにより放送側のデータと通信側のデータとの関係を示すことができる。

また、通信側においても、ＴＳのストリームを用いてもよいし、ＴＳパケットの先頭に４バイトのタイムスタンプを示すフィールドを追加したフォーマットであってもよい。ここでタイムスタンプ付のＴＳはＢＤ（Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ）や、ＩＰＴＶフォーラムなど多くの規格において使用されるものである。

［その他２］
（属性情報とロケーション情報）
属性情報やロケーション情報において、コンテンツ全体の属性と、オーディオやビデオなどのストリームの個別の属性とを分けて格納してもよい。

例えば、通信側においてＤＡＳＨを用いる場合は、放送コンテンツと通信コンテンツとが同期再生されるか、あるいは、放送コンテンツがスケーラビリティの基本レイヤで、通信コンテンツが拡張レイヤであるかなど、コンテンツ全体の属性情報を伝送路識別デスクリプタなどに格納するとしてもよい。一方、互いに同期再生の対象となるビデオやオーディオを識別するための情報など、ストリーム毎の個別の属をＭＰＤに格納するとしてもよい。

ストリーム毎の属性例として、放送におけるビデオと、通信において送信される副音声のオーディオを関連付ける場合には、ＭＰＤにおいて、ビデオを格納するＴＳパケットのＰＩＤと、オーディオのトラックＩＤなどＤＡＳＨのデータ内においてオーディオのトラックやセグメント、あるいは、Ａｄａｐｔａｔｉｏｎ ＳｅｔやＲｅｐｒｅｓｅｎｔａｔｉｏｎを識別するための情報を互いに関連付けるとしてもよい。ここで、放送側のメディアの識別情報としては、ＰＩＤの他に、当該ＰＩＤのＴＳパケットを含むトランスポートストリームのＩＤや、サービスＩＤなどを含んでもよい。

なお、ＭＰＤの内容は更新されることがあり、更新情報はＤＡＳＨコンテンツの配信サーバが管理する。そのため、特にストリームの個別属性についてはＭＰＤにおいて記述することにより、放送コンテンツの送出装置と通信コンテンツの送出サーバとの間における情報の交換を低減できるというメリットと、全体属性はＰＭＴなど放送受信開始時に取得する情報に格納することで通信コンテンツの受信開始処理を迅速に起動できるメリットとを両立できる。

また、全体属性と個別属性の両方を、放送におけるＰＭＴなどのデスクリプタ、あるいは、ＭＰＤのどちらか一方において記述してもよいし、両方において記述してもよい。例えば放送においては、ＡＩＴなどのアプリケーション制御情報の記述子において記述してもよい。

（属性情報）
さらに、放送や通信など異なる伝送路において送信されるストリームのクロック情報を同期する方法を属性情報に含めてもよい。この場合、受信装置は、本情報に基づいてクロック同期を行うとしてもよい。

例えば、下記の３つの方法を識別するための情報を属性情報として記述してもよい。

方法１）同期対象となるストリームは共通のクロックに基づいており、互いのクロックの同期は不要である。

方法２）ＰＭＴ内のデスクリプタのように、ストリームとは別途送信されるクロック同期用の情報に基づいて同期する。

方法３）現在ＭＰＥＧで規格化中であるＴＳのタイムライン拡張（１３８１８−１：２０１３／ＡＭＤ６（２ｎｄ ＷＤ））のように、クロック同期のための情報を含む独立したストリームを参照して同期する。

なお、方法３においては、クロック同期用のストリームを格納するＴＳパケットのＰＩＤを属性情報に含めてもよい。

（変形例４）
放送と通信が融合した新サービスとして、ＩＰＴＶフォーラムにおいて規格化され、ＡＲＩＢ規格においても採用済みのハイブリッドキャスト規格がある。

ＩＰＴＶフォーラムにおいて規格化され、ＡＲＩＢ規格においても採用済みである従来のハイブリッドキャスト仕様では、アプリケーション制御情報（AIT：Application Information Table)に基づき、放送系サービスと通信系サービスとの連係を機能させる。

しかしながら、従来のハイブリッドキャスト仕様では、通信側についてはＨＴＭＬ５のアプリケーションをダウンロードし、イベントメッセージの発火などに伴ってアプリケーションを開始する。そのため、従来のハイブリッドキャスト仕様では、放送側のオーディオやビデオのフレームにおけるＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）やＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）に基づいた通信コンテンツの再生制御には対応しておらず、放送コンテンツと通信コンテンツとの表示時刻をフレーム単位で同期させるなど高精度な同期再生には対応できなかった。

本変形例では、従来のハイブリッドキャスト仕様を拡張して、放送コンテンツと通信コンテンツとを高精度に同期再生する仕組みについて説明する。

以下では、高精度な同期再生を可能とするアプリケーション制御情報の拡張について説明し、その後に、本変形例における送信方法、及び、再生方法等について説明する。

［実行モード］
本変形例のアプリケーション制御情報では、アプリケーションを実行する際の実行モードを示す情報を新規に導入する。実行モードにはモード１とモード２とがあり、以下に、実行モードの例を示す。

（モード１）
モード１は、他のコンテンツとの高精度な同期を必要としない実行モードである。

また、モード１では、従来のハイブリッドキャスト規格のアプリケーションのように、自動起動（ＡＵＴＯＳＴＡＲＴ）、動作可能（ＰＲＥＳＥＮＴ）、プリフェッチ（ＰＲＥＦＥＴＣＨ）などの制御コード、または、イベントメッセージにより起動、もしくは、状態遷移を行う。モード１では、他のオーディオやビデオのストリームなどのＰＴＳやＤＴＳを参照しての同期再生は不要である。

例えば、従来のハイブリッドキャスト規格におけるアプリケーション例として、ＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）がある。このＶＯＤでは、アプリケーションを起動すると、再生開始ボタンなどが配置されたＵＩが表示され、ユーザが再生開始ボタンを押下げるとコンテンツのダウンロード、あるいは、ストリーミングを開始して再生する。

（モード２）
モード２は、放送波以外の他伝送路において送信されるコンテンツとの高精度な同期を必要とする実行モードである。

モード２では、例えば、放送におけるビデオと、アプリケーションにより取得するオーディオとを互いのＰＴＳに同期して再生する。また、例えば、ビデオのスケーラビリティが適用される際に、放送により送信される基本レイヤとアプリケーションにより取得する拡張レイヤとのデータにおいて、互いに同期したＤＴＳ、ＰＴＳを用いて、それぞれ復号、表示する。ここで、互いに同期再生されるオーディオやビデオなどのストリームは、前述したコンテンツの属性情報を参照して取得する。

（モード２におけるアプリケーションの動作）
アプリケーションにおいては、上記の実行モードに基づいて、通信側のコンテンツの再生方法を決定する。モード１における動作は従来と同様であるため説明を省略し、以下では、モード２におけるアプリケーションの動作について説明する。

放送コンテンツと通信コンテンツとを同期再生する時の基本的な動作は、図９のフローチャートに示す通りである。

クロック同期を行った後に、同期後のクロックに変換したＤＴＳやＰＴＳに従って通信コンテンツを復号し、再生するのみであれば、通信コンテンツの処理については放送コンテンツの再生処理と独立に実施できる。

一方、ビデオにおいて空間スケーラビリティが適用され、放送で基本レイヤを、通信で拡張レイヤをそれぞれ送信する際には、基本レイヤの復号結果を用いて拡張レイヤを復号するため、放送コンテンツと通信コンテンツの復号処理を統合して制御する必要がある。また、放送コンテンツと通信コンテンツとをプリバッファリングしてから再生開始する、もしくは、再生中にいずれかのコンテンツの受信バッファがオーバーフロー、または、アンダーフローした場合にも、両伝送路の再生処理を統合して制御する必要がある。例えば、オーバーフローした側のデータ受信を停止する、あるいは、アンダーフローが発生した場合には、所定の時間長、又は、所定のデータサイズのデータが受信できるまで放送コンテンツと通信コンテンツの両方の再生処理を停止するなどの処理がなされる。

ここで、両伝送路における受信から復号、再生までの少なくともいずれかの処理を統合的に制御する場合には、通信側のアプリケーションと放送コンテンツの再生処理部との間で制御コマンドの受け渡しが発生する。例えば、以下のような制御コマンドにより動作する。

１）復号処理関連：例えば特定のＤＴＳ、あるいは、ＰＴＳに対応するアクセスユニットのデータを要求し、取得する制御コマンドにより動作する。なお、再生開始時においてのみ、放送と通信で同期したアクセスユニットを取得し、その後は、ＤＴＳ、あるいは、ＰＴＳの昇順で直後となるアクセスユニットのデータを要求し、取得する制御コマンドを用いてもよい。

２）データ受信関連：データ受信の停止・再開を指示する、または、所定の条件を満たすデータ量がプリバッファリング用のバッファに溜まったことを通信する制御コマンドにより動作する。なお、データ受信の停止、再開時においては、復号や再生などの後段の処理も停止、再開するとしてもよいし、後段の特定の処理に対する制御コマンドを別途規定してもよい。

なお、モード２におけるアプリケーションの動作において、プリバッファリング用のバッファのオーバーフローやアンダーフローへの対策としては、両伝送路のデータが揃うまで待ってから再生する、または、データが揃っている方のみを再生し、揃っていない方の再生をスキップするという、大きく２つの対処方法が存在する。

従って、再生モードの指定に加えて、プリバッファリング用のバッファのオーバーフローやアンダーフローへの対処方法を示す情報を指定できるようにしてもよい。

例えば、放送では伝送路の輻輳がなく、輻輳に伴うアンダーフローなども発生しないため、放送コンテンツについてはアクセスユニットのＤＴＳ、ＰＴＳに従って再生するものとし、通信路の輻輳などにより通信コンテンツのバッファがアンダーフローした場合には、ＤＴＳにおいてデータが存在しない通信コンテンツのアクセスユニットの再生はスキップする。

ここで、通信コンテンツとしてＤＡＳＨを用いる場合には、バッファがアンダーフローした際には、後続の全てのセグメントを取得せずに、一部のセグメントをスキップすることにより、迅速に再生開始することができる。

より具体的には、ＤＡＳＨの各セグメントがＤＴＳの昇順でＳＥＧ１，ＳＥＧ２，ＳＥＧ３，．．．であり、セグメントの先頭アクセスユニットのＤＴＳがＴ１，Ｔ２，Ｔ３，．．．であるとするとする。この場合に、ＳＥＧ１の受信中にアンダーフローが発生したとすると、ＳＥＧ２の受信をスキップして、ＳＥＧ３を受信することにより、時刻Ｔ３においてＳＥＧ３の先頭アクセスユニットのデータが受信できている可能性が高くなり、結果として、時刻Ｔ３から放送と通信の両コンテンツの復号、再生を開始できる。ＳＥＧ２を受信した場合には、アンダーフローの状態が継続する可能性が高いため、受信セグメントをスキップすることにより、迅速な再生再開が見込まれる。

また、例えば、通信側がアンダーフローした場合には、通信コンテンツのデータのバッファリングが完了して再生可能となるまでの間、放送コンテンツの再生を停止する。

なお、放送のＰＭＴなどにより送信されるコンテンツの属性情報において、通信コンテンツが放送コンテンツの同期再生対象であることが示される場合、または、通信コンテンツのロケーション情報の拡張子などに基づいて、当該ロケーション情報がＤＡＳＨのＭＰＤなど特定ファイルであることが識別できる場合には、実行モードを制御情報として明示的に記述すること無しに、実行モードを決定してもよい。

また、複数伝送路において送信されるコンテンツを同期再生する際には、放送と通信の受信から再生までを単一のアプリケーションにより制御することとしてもよい。

［アプリケーション制御情報］
次に、ハイブリッドキャスト仕様において、放送コンテンツと通信コンテンツとを同期再生する際、通信において送信されるデータに関する情報をアプリケーション制御情報に格納する例について説明する。

図６Ａおよび図６Ｂでは、通信側のデータのロケーション情報を伝送路識別デスクリプタに格納し、ＰＭＴに格納する例を示した。本変形例では、伝送路識別デスクリプタをアプリケーション制御情報に格納する場合の例について説明する。

従来のハイブリッドキャスト仕様では、アプリケーション制御情報に伝送路識別デスクリプタが格納されておらず、アプリケーションの実行後にロケーション情報を取得する必要があるため、遅延が発生する。それに対し、アプリケーション制御情報に伝送路識別デスクリプタを格納し、伝送路識別デスクリプタにロケーション情報を記述（配置）することにより、より早くコンテンツの取得を開始できる。

ここで、アプリケーション制御情報は、例えば、AIT：Application Information Table)であり、アプリケーションの起動、終了やリソース、アクセスを制御する情報である。例えばアプリケーション制御情報には、アプリケーションを特定するアプリケーションＩＤ、アプリケーションの起動、終了などのライフサイクルを制御可能な制御コード、アプリケーションのロケーション情報などが記述されている。また、アプリケーション制御情報は、セクション形式とＸＭＬ形式のフォーマットが規定されており、伝送方式には、セクション形式で伝送する方法と、ＸＭＬ形式のアプリケーション制御情報をデータカルーセルによって伝送する方法がある。なお、アプリケーション制御情報を伝送する際には、ＰＭＴのＥＳループにおいて、ａｉｔ＿ｉｄｅｎｔｉｆｉｅｒ＿ｉｎｆｏ（）を含む、データ符号化方式記述子が配置されている。

図１１Ａおよび図１１Ｂは、実施の形態１の変形例４の放送通信連携サービスにおけるアプリケーション制御情報のデータ構造の一例を示す図である。具体的には、図１１Ａおよび図１１Ｂには、通信において送信されるデータに関する情報をセクション形式のアプリケーション制御情報に格納する例が示されている。

本変形例でも、図１Ａおよび図１Ｂにおいて説明した属性情報などを示すために、アプリケーション毎のデスクリプタに伝送路識別デスクリプタを格納する。例えばＰＭＴなどＴＳにおけるプログラム情報では、ＴＳにより送信されるデータのロケーション情報のみが示されるため、コンテンツのデータが通信を併用して送信される際には、通信側のデータのロケーション情報を伝送路識別デスクリプタに格納する。より具体的には、属性情報において、通信が併用されるかどうかを示すフラグ情報を含めるなどして、当該フラグ情報の値に応じて、通信側のデータのロケーション情報を含めるかどうかが選択される。

ここで、ロケーション情報とは、データの取得先を示す情報であり、ＴＳセクションであればＰＩＤ、通信であればＵＲＬやＵＲＩなどが相当する。ロケーション情報としては、ＤＡＳＨのＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）や、ＲＴＰにおけるＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）などを格納できる。

なお、別途デスクリプタを定義して、ロケーション情報を格納してもよい。また、ＭＰＤやＳＤＰなど、ロケーション情報の実体データを格納するのではなく、実体データの取得先を示す情報を示してもよい。

例えば、ＭＰＤを取得するためのＵＲＬを示すなどが可能である。但し、ロケーション情報の実体データを別途取得するための遅延が発生するため、通信側のデータを受信開始するまでの遅延を低減するためには、実体データを直接格納するのが望ましい。しかし、ＤＡＳＨのＭＰＤには、コンテンツの取得先に関して様々な情報が含まれるため、ＭＰＤのサイズは大きい。従って、ＭＰＤをそのまま格納するのではなく、コンテンツの取得先のＵＲＬと、セグメントのＤＴＳやＰＴＳに関する情報のみを含むサブセット化した情報を格納してもよい。

なお、本変形例では、図１１Ａおよび図１１Ｂに示すように、伝送路識別デスクリプタをアプリケーション毎のループに格納する例について説明したがそれに限らない。

例えば、一つの伝送路識別デスクリプタを複数のアプリケーションで兼用する場合には、伝送路識別デスクリプタを使用するアプリケーションのうち、少なくとも１つのアプリケーションのループに伝送路識別デスクリプタを格納すればよい。この場合、残りのアプリケーションループでは、伝送路識別デスクリプタを参照できる情報を示すことにより省略することができる。伝送路識別デスクリプタを参照できる情報とは、例えば、伝送路識別デスクリプタが格納されたアプリケーションのループ番号や、アプリケーションＩＤである。

また、アプリケーション制御情報直下のループ（ループ数Ｎ）に伝送路識別デスクリプタを格納し、伝送路識別デスクリプタを特定できる識別子を付与し、それぞれのアプリケーションにおいて参照する識別子を参照するとしてもよい。

また、ロケーション情報の実体を伝送路識別デスクリプタに格納する場合の例は上述の例に限らない。

例えばロケーション情報の実体のサイズが大きい場合、ロケーション情報の実体を含む伝送路識別デスクリプタまたは当該伝送路識別デスクリプタを含むアプリケーション情報は、ロケーション情報の実体を含まないアプリケーション情報より後のループ（ここではＮ１のループ）に記述するとしてもよい。これにより、ロケーション情報の実体データ以外のデータを先に取得可能となる。また、ロケーション情報の実体データを取得する必要のない受信装置は、ロケーション情報の実体データを最後まで取得しないでアプリケーション制御情報の取得を完了するとしてもよい。

また、ロケーション情報の実体の取得先を示す情報をアプリケーションの内部で示してもよい。このとき、ロケーション情報の実体の取得先を示す代わりに、取得先が示されているアプリケーションを特定できる情報（例えば、アプリケーションＩＤやアプリケーションのＵＲＬなど）を示してもよいし、ロケーション情報の実体の取得先を示さなくてもよい。

また、図１２は、実施の形態１の変形例４の放送通信連携サービスにおけるアプリケーション制御情報のデータ構造の別の一例を示す図である。すなわち、本変形例では、図１２に示すように、ＰＭＴに格納されるａｉｔ＿ｉｄｅｎｔｉｆｉｅｒ＿ｉｎｆｏ（）などの記述子に、アプリケーション情報識別子に伝送識別デスクリプタを含むことを示す情報や属性情報を格納してもよい。受信機はＰＭＴを解析することで、放送通信連携コンテンツであることをより早く知ることができ、放送と通信とを同期再生するまでの時間を短縮できる。

また、伝送路識別デスクリプタのうち、属性情報のみをＰＭＴで送信するとしてもよい。

また、例えば、ａｐｐｌｉｃａｔｉｏｎ ｔｙｐｅなどの識別子に、アプリケーションが放送と連動して動作するＨＴＭＬ５アプリケーションであることを示してもよい。

なお、本変形例では、セクション形式のアプリケーション制御情報を用いて説明したが、それに限らない。ＸＭＬ形式のアプリケーション制御情報に伝送路識別デスクリプタを格納してもよい。この場合において、伝送路識別デスクリプタはセクション形式でもＸＭＬ形式で表現してもよい。

また、本変形例では、アプリケーション制御情報を用いずに別のセクションを定義し、同様の機能を実現してもよい。この場合、ＰＭＴには、伝送路識別デスクリプタが含まれるセクションを特定するための情報（ＰＩＤやストリームタイプ等）を格納すればよい。ＭＰＤなどロケーション情報の内容の更新にも対応できることが望ましい。例えば、アプリケーション制御情報のバージョン番号でＭＰＤが更新されたことを示すとしてもよいし、アプリケーション制御情報内の制御コードを用いて、例えば制御コードがＭＰＤ＿ＣＨＡＮＧＥと示された場合にＭＰＤが更新されたとしてもよいし、ＭＰＤを通信から取得する場合は、制御コードをＭＰＤ＿ＲＥＲＯＡＤとしてアプリケーションに再取得させるとしてもよい。

また、本変形例では、ＰＭＴなどのプログラム情報と、伝送路識別デスクリプタの双方において、属性情報やロケーション情報を送信するとしてもよい。この場合において、伝送路識別デスクリプタには、ロケーション情報のみを格納するとしてもよい。

また、本変形例では、放送から取得したロケーション情報に基づいて通信側のデータを取得開始した後は、通信においてロケーション情報の更新内容を取得してもよい。このとき、ロケーション情報の取得先が必要となるため、放送の伝送路識別デスクリプタなどにおいて、ロケーション情報の実体データと共に、ロケーション情報の取得先も合わせて格納してもよい。受信装置では、ロケーション情報の取得先に定期的にアクセスするなどして、通信において更新内容を取得できる。ＤＡＳＨコンテンツの配信サーバと受信装置との間でメッセージ交換などの仕組みが存在する際には、ロケーション情報が更新されたことを示すメッセージをサーバから受信装置に対して発行し、受信装置では、メッセージを受信した際にはロケーション情報を取得し直すなどしてもよい。

また、本変形例では、図６Ａおよび図６Ｂで説明した、放送側のデータと通信側のデータの基準クロックの対応関係を示す情報を、伝送路識別デスクリプタやアプリケーション制御情報に含めてもよい。

また、本変形例では、伝送路識別デスクリプタにおいて、通信側のデータが、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）、または、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）のどちらにより送信されるかなど、トランスポート層のプロトコルの情報を示してもよい。これにより、受信装置においては、各プロトコルにおいて使用するポートをオープンする、または、使用されるプロトコルに対応しているかどうか判断するなどが可能となる。また、通信側のデータにおける多重化フォーマットの識別情報を示して、例えば、ＤＡＳＨ、あるいはＲＴＰであるかどうかなどを識別できるようにしてもよい。これにより、例えば多重化フォーマットがＤＡＳＨであればロケーション情報はＭＰＤフォーマットで記述されていると判定することができる。

［送信方法］
本実施の形態では、送信側は、放送波と通信路を用いてコンテンツ（データまたはアセット）を送信するが、コンテンツの送信に先だってアプリケーション制御情報を送信する。

［受信方法］
本実施の形態では、受信側は、アプリケーション制御情報を取得後に、コンテンツの受信（取得）を開始する。以下、図を用いて、本変形例における受信方法について説明する。つまり、ハイブリッドキャスト仕様を用いて、放送通信連携する場合の受信装置の動作例について説明する。本変形例では、放送はＴＳを用いて送信され、通信はＤＡＳＨやＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などを用いて伝送される場合を例に挙げて説明する。

図１３Ａは、実施の形態１の変形例４の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。図１３Ａには、属性情報やロケーション情報が放送のアプリケーション制御情報に格納される際の動作例が示されている。なお、図１３Ａ中で表記されているアセットは、放送側はＴＳ、通信側はＤＡＳＨやＲＴＰのデータであるとする。属性情報は、図７Ａで説明した内容と同等である。

まず、ステップＳ５０１において、アプリケーション制御情報を取得する。次に、ステップＳ５０２に続く動作を行うが、ステップＳ５０２以降の動作（ステップＳ５０２、ステップＳ５０４〜ステップＳ５０６）は、図７Ａで説明した動作（ステップＳ２０１、ステップＳ２０３〜ステップＳ２０５）と同じであるので説明を省略する。以下では異なる動作をするステップＳ５０３のみ説明する。

ステップＳ５０３において、伝送路識別デスクリプタの情報を基に通信より送信されるデータを受信するかどうかを決定するとともに、アプリケーション制御情報に記述されるアプリケーションのロケーション情報を基に通信より送信されるアプリケーションを受信するかどうかを決定する。

図１３Ｂは、実施の形態１の変形例４の放送通信連携サービスにおける受信側の動作の比較例を示すフローチャートである。図１３Ｂには、放送のプログラム情報において、属性情報、及び、ロケーション情報を取得するためのアクセス情報が格納され、ロケーション情報の実体は格納されない場合の動作例が示されている。

ステップＳ６０１において、アプリケーション制御情報を取得する次に、ステップＳ６０２に続く動作を行うが、ステップＳ６０２以降の動作（ステップＳ６０２、ステップＳ６０４〜ステップＳ６０７）は図７Ｂで説明した動作（ステップＳ３０１、ステップＳ３０３〜ステップＳ３０５）と同じであるので説明を省略する。

ステップＳ６０３において、伝送路識別デスクリプタの情報を基に通信より送信されるデータを受信するかどうかを決定するとともに、アプリケーション制御情報に記述されるアプリケーションのロケーション情報を基に通信より送信されるアプリケーションを受信するかどうかを決定する。

なお、図１３Ａに示す動作フローは、図１３Ｂに示す動作フローと比較して、通信側のロケーション情報を取得するステップがない。それにより、図１３Ａに示す受信側の動作では、通信のデータ受信開始を迅速に取得することが可能である。

また、図１３Ａに示す動作フローにおいて、図９で説明したステップＳ４０５、ステップＳ４０６およびステップＳ４０７に相当する処理を行うとしてもよい。すなわち、放送コンテンツと通信コンテンツとが同期再生されるかどうかを判定し、同期再生する場合には、伝送路識別デスクリプタから同期情報を取得し、放送と通信との基準クロックを同期させることにより、同期再生をしてもよい。

また、ステップＳ５０３やステップＳ６０３において、通信により送信されるデータを受信すると判定された時点でアプリケーションの起動準備をしてもよい。

例えば、通信により送信されたデータを受信すると判定した時点でＨＴＭＬ５のブラウザが起動させることで、アプリケーションの実行までの時間を短縮できる。

また、ステップＳ６０３において、例えば通信側のロケーション情報が通信により送信されると判定された場合、直ちにアプリケーションを起動し、通信側のロケーション情報を取得するとしてもよい。さらに、通信側のロケーション情報の取得後、通信コンテンツのバッファリングを開始してもよい。バッファリングの開始タイミングは、アプリケーション制御情報の制御コマンドで指示してもよいし、通信側のロケーション情報にプリバッファリングの時刻情報を記述しておき、受信装置で解析してプリバッファリングしてもよい。

なお、通信側のロケーション情報を取得するアプリケーションや通信コンテンツを取得するアプリケーションとして、アプリケーション制御情報により指定されたアプリケーションを放送又は通信から取得して実行してもよい。また、通信側のロケーション情報を取得するアプリケーションや通信コンテンツを取得するアプリケーションを、レジデントアプリケーションとして実現してもよい。例えばアプリケーション制御情報の制御コマンドでＨＴＭＬ５アプリケーションやレジデントアプリケーションの実行やデータの取得などの制御を指示してもよいし、受信装置の判断でＨＴＭＬ５アプリケーションやレジデントアプリケーションの実行やデータの取得など制御してもよい。

また、ロケーション情報に、コンテンツを再生するために必要な受信装置の能力に関する情報が記述されている場合、受信装置はＡＰＩコマンドで受信装置の再生能力を取得する。この場合、ロケーション情報を解析するアプリケーションに受信装置の再生能力を取得する権限を付与する。例えば、ステップＳ６０５において通信側のロケーション情報を取得後に、受信装置がコンテンツを再生できないと判断された場合、ステップＳ６０７へ移行し、放送により伝送されるデータのみを受信するとしてもよい。

また、様々な方法で取得した通信側のロケーション情報や通信コンテンツの情報を、受信装置のメモリに格納したり、メモリから取得したり、アプリケーション間で受け渡したりする制御をＡＰＩコマンドによって実現してもよい。アプリケーションは、ＡＰＩコマンドを実行することにより通信側のロケーション情報の一部又は全部を取得できる。例えば、レジデントアプリケーションで取得したロケーション情報をＡＰＩコマンドにより受信装置のメモリにセットし、ＨＴＭＬ５アプリケーションからＡＰＩコマンドによりメモリからゲットすることも可能である。

［実施の形態１の効果等］
以上のように、本実施の形態によれば、オーディオやビデオを含むコンテンツが、放送に加えて通信を併用して送信されるかどうかを示す識別情報、および、放送と通信を併用する際には、両伝送路において送信されるデータ間の依存関係などを示す情報を、コンテンツの管理情報として生成し、送信するとしてもよい。ここで、例えば、データ間の依存関係を示す情報は、両伝送路において送信されるデータが同期再生されるかどうかを含むとしてもよい。また、データ間の依存関係を示す情報は、両伝送路において送信されるデータのクロック情報が同じかどうかを含むとしてもよい。

それにより、オーディオやビデオを含むコンテンツが送信される伝送路、および、異なる伝送路において送信されるデータ間の依存関係が、コンテンツの受信開始時に取得できるので、受信するアセットの決定や、通信コンテンツの取得開始に係る遅延時間が低減できる。

また、本実施の形態によれば、通信において送信されるデータのロケーション情報を、コンテンツの管理情報に含めるとしてもよい。ここで、送信されるデータのロケーション情報は、例えば、ＭＰＥＧ−ＤＡＳＨにおけるＭＰＤであるとしてもよい。また、コンテンツ管理情報には、ＭＰＤなどのロケーション情報の実体データではなく、ロケーション情報の取得先を示す情報を格納してもよい。

それにより、オーディオやビデオを含むコンテンツが送信される伝送路、および、異なる伝送路において送信されるデータ間の依存関係が、コンテンツの受信開始時に取得できるので、受信するアセットの決定や、通信コンテンツの取得開始に係る遅延時間が低減できる。

また、本実施の形態によれば、受信装置においては、コンテンツの管理情報を解析して、コンテンツを受信する伝送路、および、各伝送路において受信するデータを決定するとしてもよい。また、両伝送路において送信されるデータを同期再生する場合には、データ間のクロック同期のために必要な補助情報を取得して、各データにおけるＤＴＳやＰＴＳを同期して、復号し、再生するとしてもよい。

それにより、放送データのみを受信する受信装置においては、従来の放送受信と同様の動作により放送データの再生を可能としつつ、通信データの再生に対応することができる。

さらに、受信装置に対しては、放送と通信のデータを同期して再生するための仕組みを提供することができる。

また、以上のように、本実施の形態によれば、受信側で放送と通信とを併用したコンテンツを再生する際に通信によるコンテンツへの迅速なアクセスを可能とするコンテンツの送信方法、受信方法、送信装置および受信装置を実現できる。

ここで、例えば、本実施の形態の一態様における送信方法は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、受信側が受信した場合に前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取らせるための情報であって前記通信路により送信されるコンテンツに関する情報をアプリケーション制御情報に含めて、前記放送波と前記通信路のうちの少なくとも前記放送波を用いて送信する情報送信ステップを含む。

これにより、放送波と通信路を用いてコンテンツを送信した場合には、受信側が受信した場合に放送波によるコンテンツと通信路によるコンテンツとの同期を取らせるための情報であって通信路により送信されるコンテンツに関する情報をアプリケーション制御情報に含めて送信するので、受信側がアプリケーション制御情報を受信したときには受信側にこの情報に従って通信によるコンテンツへの迅速なアクセスをさせることができ、コンテンツ間の同期を取らせることができる。

また、例えば、前記情報送信ステップでは、前記コンテンツを送信するのに先だって前記アプリケーション制御情報を送信し、前記アプリケーション制御情報には、さらに、前記コンテンツの取得先を示すロケーション情報または前記ロケーション情報の取得先を示す情報が含まれているとしてもよい。

また、本実施の形態の一態様における受信方法は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信ステップと、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るため情報であって前記通信路により送信されるコンテンツに関する情報が含まれるアプリケーション制御情報を、前記放送波と前記通信路のうちの少なくとも前記放送波から受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生ステップと、を含む。

これにより、例えば放送波などエントリポイントとなる伝送路において送信されるアプリケーション制御情報を取得し、その中に、放送波によるコンテンツと通信路によるコンテンツとの同期を取らせるための情報であって通信路により送信されるコンテンツに関する情報が含まれていた場合には、同期を取る処理を行うことができる。

また、例えば、前記受信ステップでは、前記コンテンツを受信するのに先だって前記アプリケーション制御情報を受信し、前記アプリケーション制御情報に、前記コンテンツの取得先を示すロケーション情報が含まれている場合には、前記ロケーション情報に基づき前記コンテンツを取得することで、前記コンテンツを受信するとしてもよい。

また、例えば、前記受信ステップでは、前記コンテンツを受信するのに先だって前記アプリケーション制御情報を受信し、前記アプリケーション制御情報に、前記コンテンツの取得先を示すロケーション情報の取得先を示す情報が含まれている場合には、前記ロケーション情報の取得先を示す情報に基づき前記ロケーション情報を取得し、取得した前記ロケーション情報から前記コンテンツを取得することで、前記コンテンツを受信するとしてもよい。

また、本実施の形態の一態様における送信装置は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信装置であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、受信側が受信した場合に前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための情報であって前記通信路により送信されるコンテンツに関する情報をアプリケーション制御情報に含めて、前記放送波と前記通信路のうちの少なくとも前記放送波を用いて送信する情報送信部を備える。

また、本実施の形態の一態様における受信装置は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信部と、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための情報であって前記通信路により送信されるコンテンツに関する情報が含まれるアプリケーション制御情報を受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生部と、を備える。

（実施の形態２）
（実施例１）
例えば実施の形態１の変形例３では、図６Ａ〜図７Ｂなどにおいて、放送はＴＳを用いて、通信はＤＡＳＨやＲＴＰなどを用いてそれぞれ送信するケースにおけるロケーション情報などの格納方法については説明したが、これに限らない。

本実施の形態では、実施例１として、ロケーション情報の格納方法の一具体例について説明する。

図１４は、実施の形態２の実施例１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。図１４には、ＭＰＤなどのロケーション情報を示すデスクリプタ（ロケーション情報デスクリプタ）の例が示されている。なお、ロケーション情報は、上述した伝送路識別デスクリプタに含めてもよい。そのため、ロケーション情報デスクリプタは伝送路識別デスクリプタに相当するとして考えてもよい。

本実施例において、デスクリプタは、ＰＭＴ、あるいは、ＰＭＴとは異なるセクションデータなどに格納される。

このデスクリプタにより示される情報としては、ロケーション情報により参照される実体データの種別を示す伝送フォーマット、ロケーション情報、及び、放送におけるＰＣＲと通信側のデータとの同期情報を示すフィールドが含まれる。

なお、本実施例においてロケーション情報は、ロケーション情報の実体データの参照先を示すものとする。ここでは、ロケーション情報の実体データがＭＰＤである場合の例を示しており、伝送フォーマットとしてはＭＰＤが示され、同期情報としては、ＰＣＲとＮＴＰとの同期情報が示される。

ＭＰＤは、ＤＡＳＨにおいて使用されるロケーション情報であるため、伝送フォーマットとしてはＤＡＳＨを示し、ロケーションとしてＭＰＤの参照先を示すことにしてもよい。ロケーション情報のＵＲＬにおける拡張子などにより伝送フォーマットを識別できる場合などにおいては、伝送フォーマットのフィールドを含めなくてもよい。また、ＭＰＤは放送内で送信する場合と、通信ネットワーク経由で送信する場合の２通りがあり、放送内で送信する場合には、ＭＰＥＧ−２ ＴＳのプライベートセクションなどを用いる。

従って、ＭＰＤのロケーション情報としては、放送内で送信する場合にはプライベートセクションのＰＩＤなど、トランスポートストリーム内でＭＰＤを格納するＴＳパケットの識別情報を示し、通信ネットワーク経由で送信する場合にはＵＲＬなどの情報を示すことができる。

［受信方法］
以下、本実施例における受信方法として、ロケーション情報を示すデスクリプタを解析して放送と通信コンテンツとを同期再生する場合の受信装置の動作の一例について説明する。

図１５は、実施の形態２の実施例１の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。

まず、ステップＳ８０１において、ＰＭＴなどに格納されるロケーション情報デスクリプタを解析する。

次に、ステップＳ８０２において、放送内にＭＰＤが存在するかどうかを判定する。放送内に存在する（放送によりＭＰＤが送信される）場合には（Ｓ８０２ではい）、ステップＳ８０３に進み、ロケーション情報により示されるＰＩＤを持つＴＳパケットからＭＰＤの実体データを取得する。一方、放送内にＭＰＤが存在しない場合には（Ｓ８０２でいいえ）、ロケーション情報において示されるＵＲＬなどに基づいて通信サーバからＭＰＤを取得する。

次に、ステップＳ８０５では、ＭＰＤの解析結果に基づいて、ＤＡＳＨコンテンツの中から取得するデータを決定し、ダウンロード（またはプログレッシブダウンロードなど）により当該データを取得する。

次に、ステップＳ８０６において、ロケーション情報デスクリプタに含まれる同期情報、あるいは、ＭＰＥＧ−２ ＴＳのタイムライン拡張が使用される場合にはタイムライン拡張情報を格納するＴＳパケットから取得した同期情報に基づいて、放送コンテンツと通信コンテンツとを同期再生する。

なお、タイムライン拡張を用いる場合には、ロケーション情報デスクリプタには同期情報を含めなくてもよい。また、ＤＡＳＨコンテンツと放送コンテンツとを同期再生する必要がない場合には、同期情報は送信しなくてもよい。この場合、ロケーション情報デスクリプタの同期情報、あるいは、タイムライン拡張用のデータにおける同期情報が存在するかどうかに基づいて、両者の同期再生が必要かどうかを判定してもよい。同期再生が必要かどうかは、別途示してもよい。

また、同期再生が必要でない場合には、ステップＳ８０６では、ユーザーの指示、あるいは、ハイブリッドキャストのアプリケーションにおける制御コマンドなどに基づいて、ＤＡＳＨコンテンツの再生開始と終了とを決定できる。なお、この場合、通信によるデータを取得するかどうかは、Ｓ８０１の前段において決定しているものとする。

図１５では、ＭＰＤを取得してＤＡＳＨコンテンツを再生する例について説明したが、ＲＴＰやＴＳなど他の方式のデータを取得して再生する場合も同様である。

なお、タイムライン拡張においては、タイムライン拡張情報を格納するアクセスユニットを定義し、アクセスユニット内に、ロケーション情報を示すデスクリプタと同期情報を示すデスクリプタの両方を格納することができる。

従って、ロケーション情報デスクリプタを送信せずに、タイムライン拡張によりロケーション情報と同期情報を共に示してもよい。現状のタイムライン拡張においては、ロケーション情報としてＰＩＤを示すことができないため、ロケーション情報のスキームタイプを示すフィールドを拡張し、ＰＩＤをシグナリングできるようにしてもよい。

また、ＰＭＴのセクションサイズの上限は１０２１バイトに制限されており、ロケーション情報におけるＵＲＬによっては、上限を超えることがある。ＰＭＴセクションを分割して格納することも可能であるが、特にＰＭＴは１つのセクションに格納されることが望ましい。

従って、ＰＭＴのセクションサイズが１０２１バイトを超える場合には、ロケーション情報デスクリプタをＰＭＴとは異なるセクションにより送信してもよい。なお、ロケーション情報がＰＩＤを示す場合には、ＰＭＴのサイズ上限以内に収めることが可能であり、ＰＭＴに含めることができるため、ロケーション情報がＰＩＤ、ＵＲＬのどちらであるかに基づいて、ロケーション情報を格納するセクションを切替えてもよい。

（実施例２）
実施例１において、タイムライン拡張におけるＴＥＭＩ（Ｔｉｍｅｌｉｎｅ ａｎｄ Ｅｘｔｅｎｄ Ｍｅｄｉａ Ｉｎｆｏｒｍａｔｉｏｎ ｓｔｒｅａｍ）アクセスユニットにおいてもロケーション情報を示すことができることを述べた。

具体的には、ｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒを用いて通信側のコンテンツのＵＲＬなどを記述できる。Ｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒにおいては、複数コンテンツのＵＲＬを記述できると共に、ＰＭＴのセクションサイズのようなデータサイズの制約も存在しないことから、ＵＲＬの記述に関して柔軟な運用が可能となる。

一方で、ロケーション情報としてトランスポートストリーム内のＴＳパケットのＰＩＤを示す場合などでは、ロケーション情報のデータサイズも小さく、ロケーション情報デスクリプタを参照してＰＭＴの解析時にロケーション情報を取得することで、取得に係る遅延時間を低減できる。そのため、ロケーション情報の格納場所としては、ロケーション情報デスクリプタとＴＥＭＩアクセスユニット内のｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒを併用できることが望ましい。

以下、本実施例におけるロケーション情報デスクリプタのシンタックス（データ構造）の一例について説明する。

図１６Ａは、実施の形態２の実施例２におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。図１６Ａには、ロケーション情報をロケーション情報デスクリプタ、あるいは、ＴＥＭＩアクセスユニットのいずれかに格納するためのロケーション情報デスクリプタのシンタックス例が示されている。

本実施例では、ＰＣＲとの同期情報はＴＥＭＩアクセスユニットのｔｅｍｉ＿ｔｉｍｅｌｉｎｅ＿ｄｅｓｃｒｉｐｔｏｒを用いて記述されることとし、ロケーション情報デスクリプタには含めていないとして説明する。図１６Ａに示すフィールド毎のセマンティクスについて説明する。

「ｄａｔａ＿ｆｏｒｍａｔ」は、図１４に示す伝送フォーマットと同様である。つまり、ＤＡＳＨにおけるＭＰＤ、ＩＰＴＶフォーラムのＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）仕様における再生制御メタファイル、あるいは、ＩＰＴＶフォーラムなどにおいて規定されるＴＴＳ（Ｔｉｍｅ−ｓｔａｍｐ ＴＳ）など、サービスで使用する再生制御のメタ情報のフォーマットを示す。ＴＴＳやＭＰ４ファイル、あるいは、ＡＶの符号化データそのものなど、メタ情報ではなく、ストリーム自体の識別情報を示してもよい。ＭＭＴにおけるＭＰＴ、ＰＡメッセージやＭＭＴパケット、アセットなどを示してもよい。

例えば、Ｈ．２６５などの動画符号化方式において時間スケーラビリティを実現することができる。ここで、放送で６０ｆｐｓの基本レイヤを送信し、通信において６０ｆｐｓから１２０ｆｐｓにフレームレートを向上させるための拡張レイヤの符号化データを送信するとする。この場合、通信コンテンツのロケーション情報としては、拡張レイヤの符号化ストリームのＵＲＬのみを示せばよい。符号化ストリームにおける解像度や符号化方式などの情報は、基本レイヤを送信する放送データにおいて取得することが可能である。

「ｌｏｃａｔｉｏｎ＿ｔｙｐｅ」は、ロケーション情報が、放送におけるＴＳのＰＩＤ、あるいは、通信におけるＵＲＬにより示されるかを識別するためのものである。ここでは、ｌｏｃａｔｉｏｎ＿ｔｙｐｅ＝０である場合に放送におけるＴＳのＰＩＤを示すものとする。なお、ロケーション情報デスクリプタは、例えば、ＭＰＥＧのＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）などＴＳ以外においても使用可能である。ＴＳ以外のフォーマットにおいては、「ｌｏｃａｔｉｏｎ＿ｔｙｐｅ」を用いなくてもよい。例えば、ＭＭＴにおけるＭＭＴパケットのｐａｃｋｅｔ＿ｉｄなどロケーションを識別するための他の情報を用いてもよい。

「ＰＩＤ」は、ＴＳパケットのＰＩＤを示す。放送が複数のトランスポートストリームから構成される場合には、トランスポートストリームの識別番号などを合わせて格納してもよい。

「ｕｒｌ＿ｌｏｃａｔｉｏｎ」は、通信コンテンツのＵＲＬが、ロケーション情報デスクリプタ内、あるいは、ＴＥＭＩアクセスユニットのどちらに格納されるかを示す。本実施例では、ｕｒｌ＿ｌｏｃａｔｉｏｎ＝０である場合に、ロケーション情報デスクリプタに格納されるものとする。ｕｒｌ＿ｌｏｃａｔｉｏｎが１である場合には、通信コンテンツのＵＲＬはＴＥＭＩアクセスユニットにおけるｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒに格納される。

「ｕｒｌ＿ｌｅｎｇｔｈ」は、「ｕｒｌ＿ｐａｔｈ」のバイト長を示す。「ｕｒｌ＿ｐａｔｈ」は、ＵＲＬのデータを示す。

図１６Ｂは、実施の形態２の実施例２におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。図１６Ｂには、図１６Ａで示したロケーション情報デスクリプタのシンタックスとは別の例が示されている。図１６Ａに示すシンタックスとの違いは、ロケーション情報をＴＥＭＩアクセスユニットに格納する場合には、ｄａｔａ＿ｆｏｒｍａｔフィールドが存在しないという点である。

ここで、Ｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒは、ｓｅｒｖｉｃｅ＿ｔｙｐｅと呼ばれるフィールドにおいてＴＥＭＩのサービスタイプを示すことができる。このサービスタイプがｄａｔａ＿ｆｏｒｍａｔに相当する。従って、ｄａｔａ＿ｆｏｒｍａｔの情報は、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドにおいて示すこととする。

なお、図１６Ａに示すシンタックスでは、ｄａｔａ＿ｆｏｒｍａｔフィールドと、ｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒのｓｅｒｖｉｃｅ＿ｔｙｐｅとが共に存在することがある。この場合、両者は同一の情報を示すものとする。

ｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒでは、ｓｅｒｖｉｃｅ＿ｔｙｐｅをシグナリングせずに通信コンテンツのＵＲＬのみを示すことも可能である。従って、図１６Ａのシンタックスを用いる場合には、伝送フォーマットとしてはロケーション情報デスクリプタのｄａｔａ＿ｆｏｒｍａｔを参照し、ｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒのｓｅｒｖｉｃｅ＿ｔｙｐｅはシグナリングしないこととしてもよい。

図１６Ｃは、実施の形態２の実施例２におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。図１６Ｃには、図１６Ａおよび図１６Ｂで示したロケーション情報デスクリプタのシンタックスとは別の例が示されている。

図１６Ａとの違いは、初めにｕｒｌ＿ｌｏｃａｔｉｏｎの条件分岐をしている点にある。つまり、ｕｒｌ＿ｌｏｃａｔｉｏｎ＝０でロケーション情報がロケーション情報デスクリプ内にある場合は、ｌｏｃａｔｉｏｎ＿ｔｙｐｅに応じて放送のＴＳのＰＩＤや通信ＵＲＬが格納される。一方、ｕｒｌ＿ｌｏｃａｔｉｏｎ＝１の場合は、ｌｏｃａｔｉｏｎ＿ｔｙｐｅはロケーション情報デスクリプタ内には記述されず、ＴＥＭＩアクセスユニットにおけるｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ内に、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドにおいてｌｏｃａｔｉｏｎ＿ｔｙｐｅを示し、ｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒに放送におけるＴＳのＰＩＤ或いは通信ＵＲＬを格納する。

図１６Ｄは、実施の形態２の実施例２におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。図１６Ｄには、図１６Ａ〜図１６Ｃで示したロケーション情報デスクリプタのシンタックスとは別の例が示されている。

図１６Ａとの違いは、ｕｒｌ＿ｌｏｃａｔｉｏｎとｌｏｃａｔｉｏｎ＿ｔｙｐｅとを統合した点である。ｌｏｃａｔｉｏｎ＿ｔｙｐｅ＝０である場合は放送のＰＩＤを示し、ｌｏｃａｔｉｏｎ＿ｔｙｐｅ＝１の場合は通信のＵＲＬを示す。また、ｌｏｃａｔｉｏｎ＿ｔｙｐｅ＝２の場合はＴＥＭＩアクセスユニットにおけるｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒに、放送におけるＴＳのＰＩＤ或いは通信ＵＲＬが格納されることを示す。

なお、ロケーション情報デスクリプタのシンタックスのデータやデータ構造は、上述の例に限るものではない。例えばロケーションタイプとフォーマットタイプとを統合して示すなど、他のデータと組み合わせて用いてもよい。また、例えばロケーション情報のＵＲＬにおける拡張子などにより伝送フォーマットを識別できる場合などにおいては、伝送フォーマットのフィールドを含めなくてもよい。また、例えばロケーション情報デスクリプタが存在しなければ、ロケーション情報がｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒにより示されることとして、ｕｒｌ＿ｌｏｃａｔｉｏｎのフィールドを省略してもよい。

（実施例３）
以下、実施例２で説明したロケーション情報とは別の例について説明する。

（ロケーション情報のその他の例）
例えば、同一プログラム内に２種類以上の複数のタイムラインが存在する場合、タイムラインの種類毎に複数のＴＥＭＩストリームを含む場合がある。

この場合、ロケーション情報デスクリプタに複数のロケーション情報を格納してもよい。複数のロケーション情報を格納する場合には、ロケーション情報デスクリプタ内にＴＥＭＩストリームの数のループを作成し、それぞれのＴＥＭＩストリームに対応するロケーション情報を格納する。また、ロケーション情報デスクリプタにおける複数のロケーション情報ループと複数のＴＥＭＩストリームとの対応関係を示す方法として、例えばロケーション情報のループの順番と、ＴＥＭＩストリームを示すＥＳループ（ＰＭＴ第２ループ）の順番が一致するものが対応関係にあるなどとしてもよい。また、２種類以上のタイムラインが存在する場合には、ロケーション情報はロケーション情報デスクリプタに格納せず、ＴＥＭＩアクセスユニットのｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒに格納するとしてもよいし、ロケーション情報デスクリプタをＥＳループ（ＰＭＴ第２ループ）に格納してもよい。

（ロケーション情報の更新）
なお、メタ情報などのロケーション情報の内容の更新にも対応できることが望ましい。

例えば、ＰＭＴ内のロケーション情報デスクリプタにｒｅｌｏａｄフラグを追加し、ロケーション情報の内容を更新する場合にはｒｅｌｏａｄ＝１とし、受信装置はｒｅｌｏａｄ＝１である場合にはロケーション情報の内容が更新されたとして、ロケーション情報に格納されているＰＩＤやＵＲＬなどを再取得してもよい。ＰＩＤやＵＲＬなどのロケーション情報は更新されておらず、データのみが更新されている場合は、データのみを再取得してもよい。

また、ロケーション情報自体、あるいは、ロケーション情報により取得先が示されるＭＰＤなどのデータの内容が更新されたかを示す情報を、それぞれ独立に示してもよい。

また、周期的に送信されるＰＭＴ内のロケーション情報デスクリプタを逐次チェックしてもよい。しかし、この逐次チェックの処理は重たいため、ロケーション情報デスクリプタなどを格納するためのセクションデータや、更新されたことを通知するイベント用セクションなどを別途生成し、周期的に送信してもよい。

受信装置では、セクションにおけるバージョン番号を確認すればロケーション情報が更新されたかどうかを判定できる。また、ロケーション情報を放送のセクションで送信する場合には、ロケーション情報のセクションのバージョン番号を更新することで、メタ情報の更新を示す。

また、放送から取得したロケーション情報に基づいて通信側のデータを取得開始した後は、通信においてロケーション情報の更新内容を取得してもよい。

［受信方法］
次に、本実施例における受信方法として、ロケーション情報を示すデスクリプタを解析して放送と通信コンテンツとを同期再生する場合の受信装置の動作の一例について説明する。

図１７は、実施の形態２の実施例３の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。

図１５のステップＳ８０４が図１７ではステップＳ９０６、ステップＳ９０７，およびステップＳ９０８に変わっている。その他の動作（ステップＳ９０１〜ステップＳ９０５）は、図１５の動作（ステップＳ８０１〜ステップＳ８０３、ステップＳ８０５およびステップＳ８０６）と同様であるので説明を諸略する。

ステップＳ９０６において、ＭＰＤなどの取得先ＵＲＬがロケーション情報デスクリプタ、あるいは、ＴＥＭＩアクセスユニットのどちらに格納されるかを判定する。ロケーション情報デスクリプタにある場合は（Ｓ９０６ではい）、ステップＳ９０７に進み、ロケーション情報デスクリプタを解析し、ロケーション情報に示されるＵＲＬに基づいて通信サーバからＭＰＤを取得する。一方、ステップＳ９０６において、ＴＥＭＩアクセスユニットに格納されていると判定された場合には（Ｓ９０６でいいえ）、ＴＥＭＩアクセスユニットにおけるｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒに示されるＵＲＬに基づいて通信サーバからＭＰＤを取得する。

なお、図１７では、フォーマット情報としてＭＰＤが示されている場合の例について示されているが、他のメタ情報であっても同様のフローの動作で放送コンテンツと通信コンテンツとを同期再生できる。

図１８は、実施の形態２の実施例３の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。図１８では、フォーマット情報がＭＰＤ以外の他のメタ情報である場合の動作の動作が示されている。より具体的には、フォーマット情報に、ＭＰＤのようなメタ情報ではなく、ストリームなどの実体データのフォーマットが示されている場合に、図１１に示すステップＳ９０７やステップＳ９０８においてメタ情報のＵＲＬの代わりにストリームの実体データのＵＲＬを取得する場合の動作が示されている。

まず、ステップＳ１００１において、受信装置は、ロケーション情報デスクリプタを解析する。

次に、フォーマットに示されるデータが放送内に存在するかどうかを判定する（ステップＳ１００２）。放送内にデータが存在する場合には（Ｓ１００２ではい）、ステップＳ１００３に進み、ロケーション情報に示されるＰＩＤを取得する。ここでは、ストリームなどの実体データを放送内に含むことを想定していないため、放送内にデータが存在する場合には、そのフォーマットはメタデータであることが確定する。

次に、ＰＩＤに基づいて放送ストリームからメタ情報ファイルを取得し（ステップＳ１００４）、取得する通信データを決定する（ステップＳ１００５）。

一方、ステップＳ１００２において通信にデータが存在する場合には（Ｓ１００２でいいえ）、ステップＳ１００８に進み、通信データのＵＲＬがロケーション情報デスクリプタに存在するか、ＴＥＭＩアクセスユニットのｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒに存在するかを判定する。そして、それぞれの場合に応じて、ステップＳ１００９またはステップＳ１０１０においてＵＲＬを取得する。

ステップＳ１０１１では、フォーマットがメタ情報であるかの判定をする。フォーマットがメタ情報である場合には（Ｓ１０１１ではい）、ステップＳ１０１２に進み、ＵＲＬに基づいて通信ストリームからメタ情報を取得し、ステップＳ１００５に進み、取得する通信データを決定する。

ステップＳｐ１００５において取得する通信データが決まった後や、ステップＳ１０１１においてフォーマットがメタ情報でないと判定された場合には、ステップＳ１００６に進み、通信データを取得する。

最後に、ステップＳ１００７では、ロケーション情報デスクリプタに含まれる同期情報、あるいは、ＭＰＥＧ−２ ＴＳのタイムライン拡張により示される同期情報に基づいて、放送コンテンツと通信コンテンツを同期再生する。

（実施例４）
これまでは、放送コンテンツと通信コンテンツとが同期再生されるかどうかを判定して、同期再生される場合に、放送コンテンツと通信コンテンツとの取得や同期再生をするとして説明をしたが、これに限らない。

本実施例では、放送により送信されるオーディオやビデオの基準クロック情報と、通信により送信されるオーディオやビデオの基準クロック情報とが、同じかどうかを示す情報がサービス情報（伝送識別デスクリプタ等）に含まれ、この情報に基づいた動作について説明する。

［放送と通信との基準クロック（タイムライン）が同期しているかの情報］
放送と通信とを用いたコンテンツをＭＭＴやＤＡＳＨ、ＲＴＰ、或いはハイブリッドキャストなどを用いて伝送する場合、放送により送信されるオーディオやビデオの基準クロック情報と、通信により送信されるオーディオやビデオの基準クロック情報とが、同じかどうかを示す情報を伝送識別デスクリプタやプログラム情報、ＥＰＧやＥＩＴなどに格納するとしてもよい。

例えば、放送と通信とにより伝送されるコンテンツが、共通の基準クロックに基づいて動作（例えば、タイムスタンプの付与など）されている場合、共通の基準クロックに基づいて動作していることを示す情報を格納する。また、放送と通信とにより伝送されるコンテンツが異なる基準クロックに基づいて動作されている場合、異なる基準クロックに基づいて動作していることを示す情報を格納する。

また、放送と通信とで異なる基準クロック情報を用いていることを示す場合のみ、基準クロック同期に必要な情報（例えば、タイムライン拡張情報など）を示すとしてもよい。また、基準クロック同期に必要な情報の格納場所や、基準クロック同期に必要な情報の種類、基準クロック同期の方法などを示してもよい。

ここで、基準クロックの同期においては、放送または通信のいずれかで使用されている基準クロックに揃えることが可能である。

例えば、放送においてＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）が用いられ、通信においてＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）が用いられる場合、ビデオやオーディオにおけるＮＴＰ基準でのＤＴＳやＰＴＳを、ＰＣＲ基準に変換することで、放送と通信とにおける基準クロックを同期できるというように基準クロック同期の種類や方法を示してもよい。また、受信装置内で使用される固有のクロックと同期するように、放送と通信のＤＴＳやＰＴＳを変換するというように基準クロック同期の種類や方法を示ししてもよい。

なお、基準クロック同期に必要な情報の種類や方法を示した識別情報を解析し、識別情報に基づいた方法で基準クロック同期をしてもよい。

また、基準クロックが異なるストリームが複数ある場合、基準クロックが異なる基準クロックが複数あることを示す情報をデスクリプタに格納してもよい。デスクリプタを異なる基準クロックごとに示してもよいし、一つのデスクリプタで示してもよい。基準クロックと当該基準クロックを用いたプログラムとの対応関係を示す情報を格納してもよい。

基準クロックが同じかどうかを示す情報としては、上記のようなデスクリプタとして示してもよいし、他のデスクリプタやテーブル、セクションなどを用いてもよい。また、クロック同期に必要な情報（例えば、タイムライン拡張情報など）が存在するかどうかによって示してもよい。クロック同期に必要な情報が存在すれば、クロック情報が異なるとしてもよい。あるいは、伝送識別デスクリプタなどに示された、通信コンテンツの属性情報（たとえば、フォーマットや種類に関する情報、あるいは、ロケーション情報やＵＲＬに記述された拡張子など）を用いて、クロック情報が異なるということを示してもよい。 ハイブリッドキャストの場合は、ＡＩＴコントロールドセクションや、アプリケーションの中に格納してもよい。

受信装置は、異なるクロック情報を用いていると判定した場合には、放送と通信の基準クロック情報を同期させる。また、共通のクロック情報を用いていると判定した場合、クロックの同期は不要と判断する。

なお、受信装置は、伝送識別デスクリプタなどに格納された、データの基準クロック情報が同じかどうかの識別結果に加え、ユーザーインタフェースなどによるユーザーの選択やユーザー設定、コンテンツ提供者やサービス事業者、放送局の意図、または受信装置のスペックや仕様、受信機メーカーの意図など、すべてを勘案し、実際に放送コンテンツと通信コンテンツの基準クロック同期をするかどうかを判定してもよい。

また、受信装置は、基準クロック同期をすると判定した場合に、実際にクロック同期をするタイミングとしては、判定後に同期開始してもよいし、判定をまたずに、同期に関する情報を取得した際に開始してもよい。あるいは、通信コンテンツの取得を開始する時間に合わせて同期してもよい（例えばコンテンツの取得を開始する一定時間前や、取得開始と同じ時間など）。

また、参照元となる基準クロック（例えば、放送のＰＣＲ）のクロック再生が完了していない（ジッタ等の影響を平滑するなどしてクロックの使用ができる状態になっていない）場合は、参照元の基準クロック情報のクロック再生が完了した時点で、参照先とのクロックの同期を開始するとしてもよい。

放送と通信との基準クロックが同期しているかの情報が、ＥＰＧによって示されている場合は、通信コンテンツのプロバッファリングと同様に、放送開始前に基準クロックの同期が必要かどうかの判定や基準クロックの同期を開始してもよい。このように、より早く基準クロックの同期を行うことで、より早く、サービスを視聴者に提供できる。

なお、基準クロックが同じかどうかを示す情報は、放送と通信との組み合わせに限られるものではなく、同じ経路で伝送される場合や、放送や通信、蓄積フォーマットなど複数の経路から取得されるデータ中で、異なる基準クロック情報を用いていれば適用可能である。

なお、本実施例で説明する機能や処理の一部または全部は、ハードウェアで実装してもよいし、ソフトウェアで実装してもよい。一部をハードウェアあるいはソフトウェアとして実装することもできる。

例えば、ソフトウェアで実装する場合は、本実施例で説明した機能や処理を指示したり、受信機能の状態をＰＵＳＨで通知したり、ＰＵＬＬで取得する機能などをパッケージし、ＡＰＩ関数として提供してもよい。

ＡＰＩ関数は、アプリケーションから実行できる。アプリケーションとして実装する場合は、レジデントアプリケーションで実装してもよいし、ＨＴＭＬ５などのアプリケーションも用いてもよい。上記ＡＰＩをアプリケーション間でのデータの受け渡し、状態の通知として実装してもよい。

ここで、基準クロックが同期しているかの情報に関連するＡＰＩ関数の機能としては例えば下記の１）〜９）のようなものがある。

１）放送コンテンツと通信コンテンツの基準クロック情報が同じかどうかの情報を取得する。２）基準クロック同期が必要かどうかの情報を取得する。３）それぞれの基準クロック情報の種類や同期方法を取得する。４）クロック同期に必要な情報（タイムライン情報など）を取得する。５）クロック同期に必要な情報の取得先を取得する。６）参照元のクロック情報を引数とし、同期のとれた参照先のクロック情報を返す。例えば、同期がとれていない場合は、同期がとれていないことを示す値を返す。７）互いの基準クロックの同期開始を指示する。８）基準クロック同期がとれているかどうかの状態を取得する。９）基準クロック同期がとれたことを通知する。

［受信方法］
以下、図を用いて、本実施例における受信方法として、属性情報やロケーション情報が放送のプログラム情報に格納される場合に、受信装置が放送コンテンツと通信コンテンツとを同期再生するかどうかを判定して動作するときの動作の一例について説明する。

図１９は、実施の形態２の実施例４の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。なお、図１９に示すフローチャートの動作は、ＭＭＴやＤＡＳＨ、 ＲＴＰなどいかなる多重化方式の組み合わせを用いた放送通信連携サービスにも適用可能である。また、ハイブリッドキャストにも適用可能である。

図１９では、放送コンテンツと通信コンテンツとが同期されることを前提としており、放送コンテンツと通信コンテンツとを同期するかどうかの判定は省略している。

また、ステップＳ１１０１およびステップＳ１１０２は、図９のステップＳ４０１およびステップＳ４０２と同様の動作であるので、説明を省略する。

次に、ステップＳ１１０３において、受信装置は通信コンテンツを取得するかどうかを決定する。通信コンテンツを取得すると決定した場合には（Ｓ１１０３ではい）、ステップＳ１１０４に進み、放送と通信の両伝送路からデータを受信し、続くステップＳ１１０５において、放送コンテンツと通信コンテンツとの基準クロックが同じか異なるかを判定する。

ステップＳ１１０５において基準クロックが異なると判定した場合には（Ｓ１１０５ではい）、ステップＳ１１０６に進み、放送コンテンツと通信コンテンツとの基準クロックを同期させ、ステップＳ１１０７において両者を同期再生する。

一方、ステップＳ１１０５において基準クロックが同じであると判定した場合には（Ｓ１１０５でいいえ）、基準クロックの同期をせずに、共通のクロックを用いて同期再生する。

なお、ステップＳ１１０５の後に、基準クロックの同期が必要かどうかを判定する処理を行ってもよい。例えば、クロック同期の種類や方法によって、受信装置の能力がクロックの同期に対応するかどうか、あるいは、受信機の仕様としてクロック同期をするかどうか、あるいはユーザーがクロック同期をするかどうかなどを判定する。そして、ステップＳ１１０５と上記の判定結果によって、総合的に放送と通信とにおける基準クロックの同期をするかどうかを判定し、ステップＳ１１０６またはステップＳ１１０７に進むとしてもよい。

また、ステップＳ１１０６における基準クロックの同期は、ステップＳ１１０４に先立って実施してもよい。これは、コンテンツの受信データをプリバッファリングしてから再生開始する場合など、放送コンテンツにおいてＰＴＳがＴ１となるデータと、通信コンテンツにおいてＰＴＳがＴ１となるデータ（ここで、互いのＰＴＳは既に同期されているものとする）が受信済みとなることを確認して復号、再生を開始することがあるからである。そして、互いに同期再生されるデータが揃っているかどうかを判定する際に、両者の基準クロックが同期済みであることが必要となるためである。

また、ステップＳ１１０６において、クロック同期情報が取得できないなどによって、または、受信機の仕様によって、クロック同期ができない場合、放送と通信との連携したサービスをユーザーに提供できない場合がある。その場合には、同期させることが必須かどうか、同期させずに再生してもいか、などの判定をすることによって、ステップＳ１１０３の通信により送信されるデータを受信するかどうかを判定してもよい。

なお、ステップＳ１１０３では、伝送路識別デスクリプタで識別できる情報の他にも、ユーザーの選択や設定、コンテンツ提供者やサービス事業者、放送局の意図、または受信装置のスペックや仕様、メーカーの意図など、すべてを勘案し、実際に通信により送信されるデータを受信するかどうかを決定してもよい。

［受信装置］
次に、図１９に示す動作を実現する受信装置の構成の一例について説明する。図２０は、実施の形態２の実施例４における受信装置の構成の一例を示すブロック図である。

図２０に示す受信装置１１００は、識別情報取得部１１０１と、決定部１１０２と、通信併用判定部１１０３と、Ｌｏｃ情報取得部１１０４と、放送受信部１１０５と、通信受信部１１０６と、基準クロック判定部１１０７と、再生部１１０８とを備える。

識別情報取得部１１０１〜通信受信部１１０６は、図８で説明した識別情報取得部３０１〜通信受信部３０６と同様であるので説明を省略する。

基準クロック判定部１１０７は、図１９に示すステップＳ１１０５の処理を行う機能を備える。また、基準クロック判定部１１０７は、基準クロックが異なるかどうかを判定した上で、さらに、上述したような基準クロックの同期が必要かどうかを判定する処理を行うとしてもよい。

再生部１１０８は、基準クロック判定部１１０７における判定結果により決定された方法に基づいて、基準クロックが異なる場合は基準クロックを同期した後に、放送コンテンツまたは通信コンテンツを復号して、再生する。

なお、本変形例で説明した機能や受信装置の構成、受信方法は一例であり、これに限られるものでなく、同様の機能や効果が実現できるものであればよい。

［実施の形態２の効果等］
以上のように、本実施の形態によれば、オーディオやビデオを含むコンテンツが、放送に加えて通信を併用して送信されるかどうかを示す識別情報、および、放送と通信を併用する際には、両伝送路において送信されるデータ間の依存関係などを示す情報を、コンテンツの管理情報として生成し、送信するとしてもよい。ここで、例えば、データ間の依存関係を示す情報は、両伝送路において送信されるデータが同期再生されるかどうかを含むとしてもよい。また、データ間の依存関係を示す情報は、両伝送路において送信されるデータのクロック情報が同じかどうかを含むとしてもよい。

それにより、オーディオやビデオを含むコンテンツが送信される伝送路、および、異なる伝送路において送信されるデータ間の依存関係が、コンテンツの受信開始時に取得できるので、受信するアセットの決定や、通信コンテンツの取得開始に係る遅延時間が低減できる。

また、本実施の形態によれば、通信において送信されるデータのロケーション情報を、コンテンツの管理情報に含めるとしてもよい。ここで、送信されるデータのロケーション情報は、例えば、ＭＰＥＧ−ＤＡＳＨにおけるＭＰＤであるとしてもよい。また、コンテンツ管理情報には、ＭＰＤなどのロケーション情報の実体データではなく、ロケーション情報の取得先を示す情報を格納してもよい。

それにより、オーディオやビデオを含むコンテンツが送信される伝送路、および、異なる伝送路において送信されるデータ間の依存関係が、コンテンツの受信開始時に取得できるので、受信するアセットの決定や、通信コンテンツの取得開始に係る遅延時間が低減できる。

また、本実施の形態によれば、受信装置においては、コンテンツの管理情報を解析して、コンテンツを受信する伝送路、および、各伝送路において受信するデータを決定するとしてもよい。例えば、両伝送路において送信されるデータのクロック情報が異なる場合は、データ間のクロック同期のために必要な補助情報を取得し、各データにおけるＤＴＳやＰＴＳを同期して、復号し、再生するとしてもよい。また、両伝送路において送信されるデータを同期再生する場合には、データ間のクロック同期のために必要な補助情報を取得して、各データにおけるＤＴＳやＰＴＳを同期して、復号し、再生するとしてもよい。

それにより、放送データのみを受信する受信装置においては、従来の放送受信と同様の動作により放送データの再生を可能としつつ、通信データの再生に対応することができる。

さらに、受信装置に対しては、放送と通信のデータを同期して再生するための仕組みを提供することができる。

さらに、複数の伝送路で伝送されるデータのクロック間の同期がとれていない場合でも、クロック同期に必要な補助情報を取得することによりクロックの同期をし、データを同期再生できる。

以上のように、本実施の形態によれば、受信側で放送と通信とを併用したコンテンツを再生する際に通信によるコンテンツへの迅速なアクセスを可能とするコンテンツの送信方法、受信方法、送信装置および受信装置を実現できる。

ここで、例えば本実施の形態の一態様における送信方法は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、受信側が受信した場合に前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取らせるための情報であって前記通信路により送信されるコンテンツに関する情報をアプリケーション制御情報に含めて、前記放送波と前記通信路のうちの少なくとも前記放送波を用いて送信する情報送信ステップを含む。

これにより、放送波と通信路を用いてコンテンツを送信した場合には、受信側が受信した場合に放送波によるコンテンツと通信路によるコンテンツとの同期を取らせるための情報であって通信路により送信されるコンテンツに関する情報をアプリケーション制御情報に含めて送信するので、受信側がアプリケーション制御情報を受信したときには受信側に通信によるコンテンツへの迅速なアクセスをさせることができ、コンテンツ間の同期を取らせることができる。

また、例えば、前記情報送信ステップでは、前記コンテンツを送信するのに先だって前記アプリケーション制御情報を送信し、前記アプリケーション制御情報には、さらに、前記コンテンツの取得先を示すロケーション情報または前記ロケーション情報の取得先を示す情報が含まれているとしてもよい。

また、例えば、前記情報送信ステップでは、さらに、前記アプリケーション制御情報に、前記放送波によるコンテンツの基準クロックと前記通信路によるコンテンツの基準クロックとの差分情報を含めて送信するとしてもよい。

また、例えば、前記情報送信ステップでは、前記アプリケーション制御情報を送信することにより、前記差分情報に基づき前記通信路によるコンテンツの基準クロックを前記放送波によるコンテンツの基準クロックに同期させることで前記受信側に前記同期を取らせるとしてもよい。

また、本実施の形態の一態様における受信方法は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信ステップと、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るため情報であって前記通信路により送信されるコンテンツに関する情報が含まれるアプリケーション制御情報を、前記放送波と前記通信路のうちの少なくとも前記放送波から受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生ステップと、を含む。

これにより、例えば放送波などエントリポイントとなる伝送路において送信されるアプリケーション制御情報を取得し、その中に、放送波によるコンテンツと通信路によるコンテンツとの同期を取らせるための情報であって通信路により送信されるコンテンツに関する情報が含まれていた場合には、同期を取る処理を行うことができる。

ここで、例えば、前記受信ステップでは、前記コンテンツを受信するのに先だって前記アプリケーション制御情報を受信し、前記アプリケーション制御情報に、前記コンテンツの取得先を示すロケーション情報が含まれている場合には、前記ロケーション情報に基づき前記コンテンツを取得することで、前記コンテンツを受信するとしてもよい。

また、例えば、前記受信ステップでは、前記コンテンツを受信するのに先だって前記アプリケーション制御情報を受信し、前記アプリケーション制御情報に、前記コンテンツの取得先を示すロケーション情報の取得先を示す情報が含まれている場合には、前記ロケーション情報の取得先を示す情報に基づき前記ロケーション情報を取得し、取得した前記ロケーション情報から前記コンテンツを取得することで、前記コンテンツを受信するとしてもよい。

また、例えば、前記再生ステップでは、前記受信ステップにおいて、前記放送波によるコンテンツの基準クロックと前記通信路によるコンテンツの基準クロックとの差分情報を含む前記アプリケーション制御情報を受信し、かつ、前記放送波によるコンテンツの基準クロックおよび前記通信路によるコンテンツの基準クロックが異なる場合には、前記差分情報に基づき前記通信路によるコンテンツの基準クロックを前記放送波によるコンテンツの基準クロックに同期させることで前記コンテンツの同期を取る処理を行い、前記コンテンツを再生するとしてもよい。

以上、本発明の一つまたは複数の態様に係る送信方法および受信方法等について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本発明の一つまたは複数の態様の範囲内に含まれてもよい。

例えば、上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。

また、例えば、属性情報は、放送により送信されるオーディオやビデオのクロック情報と、通信により送信されるオーディオやビデオのクロック情報とが、同じかどうかを示す情報を含めるとしてもよい。

また、Ｓ４０６における基準クロックの同期において、属性情報に複数のコンポーネントの基準クロック情報が同じかどうかを示す情報が含まれており、属性情報により基準クロック情報が異なることを受信側で取得できる場合には、上記の方法を用いて放送と通信とにおける基準クロックを同期するとしてもよい。

また、放送波と通信路を用いてコンテンツが送信される際には、伝送路識別デスクリプタを送信し、放送波のみを用いてコンテンツを送信する際には伝送路識別デスクリプタを送信しないとしてもよい。この構成によると、受信機は、伝送路識別デスクリプタのが含まれているか否かに基づいて、通信路を併用してコンテンツが送信されるのか、放送波のみを用いてコンテンツが送信されるのかを判定することができる。

また、放送や通信など異なる伝送路において送信されるストリームのクロック情報を同期する方法を属性情報に含めてもよいとしたがそれに限らない。放送や通信など異なる伝送路において送信されるストリームのクロック情報が互いに同期されているかどうかを示す情報を同期する方法、あるいは同期するための方法を属性情報に含めてもよい。

本発明は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法、受信方法などとして有用である。

１１ 識別情報取得部
１４、１０４、３０５、４０５、１１０５ 放送受信部
１００、３００、４００、１１００ 受信装置
１０１、３０１、４０１、１１０１ 識別情報取得部
１０２ アセット決定部
１０３ 判定部
１０５、３０６、４０６、１１０６ 通信受信部
３０２、４０２、１１０２ 決定部
３０３、４０３、１１０３ 通信併用判定部
３０４、４０４、１１０４ Ｌｏｃ情報取得部
４０７ 同期判定部
４０８、１１０８ 再生部
１１０７ 基準クロック判定部

Claims (4)

1. 放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法であって、
   放送波と通信路とのそれぞれを用いてコンテンツを送信する場合において、前記通信路により送信される前記コンテンツがあることを示す情報と、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取らせるための情報であって前記通信路により送信されるコンテンツに関する情報とをアプリケーション制御情報に含めて、前記放送波と前記通信路のうちの少なくとも前記放送波を用いて送信する情報送信ステップを含む、
   送信方法。
2. 放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信ステップと、
   前記通信路により送信される前記コンテンツがあることを示す情報と、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るため情報であって前記通信路により送信されるコンテンツに関する情報とが含まれるアプリケーション制御情報を、前記放送波と前記通信路のうちの少なくとも前記放送波から受信した場合には、前記通信路により送信される前記コンテンツがあると判定して前記同期を取る処理を行い、前記コンテンツを再生する再生ステップと、を含む、
   受信方法。
3. 放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信装置であって、
   放送波と通信路とのそれぞれを用いてコンテンツを送信する場合において、前記通信路により送信される前記コンテンツがあることを示す情報と、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための情報であって前記通信路により送信されるコンテンツに関する情報とをアプリケーション制御情報に含めて、前記放送波と前記通信路のうちの少なくとも前記放送波を用いて送信する情報送信部を備える、
   送信装置。
4. 放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信部と、
   前記通信路により送信される前記コンテンツがあることを示す情報と、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための情報であって前記通信路により送信されるコンテンツに関する情報とが含まれるアプリケーション制御情報を受信した場合には、前記通信路により送信される前記コンテンツがあると判定して前記同期を取る処理を行い、前記コンテンツを再生する再生部と、を備える、
   受信装置。

Images