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

Abstract

【課題】通信によるコンテンツの受信開始タイミングが遅延しても受信側で放送と通信とを併用したコンテンツを再生可能なコンテンツの送信方法を提供する。【解決手段】放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、放送波によるコンテンツと通信路によるコンテンツとの同期を取るための補助情報であって受信側が受信した場合に同期を取らせる補助情報を、少なくとも前記放送波を用いて送信する情報送信ステップを含む。【選択図】図２

Description

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

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

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

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

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

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

そこで、本発明の目的は、通信によるコンテンツの受信開始タイミングが遅延しても受信側で放送と通信とを併用したコンテンツを再生可能なコンテンツの送信方法を提供することにある。

上記課題を解決するため、本発明の一態様に係る送信方法は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合において、前記通信路により送信される前記コンテンツがあることを示す情報と、前記通信路により送信される前記コンテンツの再生制御のメタ情報のフォーマットを示す情報と、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報であって受信側が受信した場合に前記同期を取らせる補助情報とを、少なくとも前記放送波を用いて送信する情報送信ステップを含み、前記補助情報は、前記通信路により送信される前記コンテンツの取得先を示すロケーション情報を含む。

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

本発明によれば、通信によるコンテンツの受信開始タイミングが遅延しても受信側で放送と通信とを併用したコンテンツを再生可能なコンテンツの送信方法等を実現できる。

実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 実施の形態１における伝送路識別デスクリプタの概要の一例を示す図である。 実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の別の一例を示す図である。 実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の別の一例を示す図である。 実施の形態１の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 実施の形態１の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。 実施の形態１における受信装置の構成の一例を示すブロック図である。 実施の形態１の変形例１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 実施の形態１の変形例１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 実施の形態１の変形例１の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 実施の形態１の変形例１の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。 実施の形態１の変形例１における受信装置の構成の一例を示すブロック図である。 実施の形態１の変形例２の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 実施の形態１の変形例２における受信装置の構成の一例を示すブロック図である。 実施の形態１の変形例４の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 実施の形態１の変形例４の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 実施の形態１の変形例４におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。 実施の形態１の変形例４におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。 実施の形態１の変形例４におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。 実施の形態１の変形例４におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。 実施の形態１の変形例６の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 実施の形態１の変形例６の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。 実施の形態１の変形例７の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 実施の形態１の変形例７における受信装置の構成の一例を示すブロック図である。 実施の形態２におけるデフォルト再生制御情報の記述例を示す図である。 図１８Ａに示すデフォルト再生制御情報のレイアウト情報に従ったビデオの表示例について示す図である。 実施の形態２におけるアプリケーション制御情報の一例を示す図である。 図１９Ａに示すアプリケーション制御情報のレイアウト情報に従ったビデオの表示例について示す図である。 実施の形態２におけるデフォルト再生制御情報の別の記述例を示す図である。 図２０Ａに示すデフォルト再生制御情報のレイアウト情報に従ったビデオの表示例について示す図である。 実施の形態２におけるアプリケーション制御情報の一例を示す図である。 図２１Ａに示すアプリケーション制御情報のレイアウト情報に従ったビデオの表示例について示す図である。 実施の形態２における受信側の動作の一例を示すフローチャートである。 実施の形態２における受信装置の構成の一例を示すブロック図である。 実施の形態３における放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 実施の形態３のプログラム構成情報記述子に含まれる情報の一例を示す図である。 実施の形態３のロケーション情報記述子に含まれる情報の一例を示す図である。 実施の形態３のロケーション情報記述子に含まれるロケーションタイプの一例を示す図である。 実施の形態３のアセット構成情報記述子に含まれる情報の一例を示す図である。 実施の形態３の放送通信連携サービスにおける受信方法を示すフローチャートである。 実施の形態３における受信装置の構成の一例を示すブロック図である。

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

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

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

本態様によれば、通信によるコンテンツの受信開始タイミングが遅延しても受信側で放送と通信とを併用したコンテンツを再生可能なコンテンツの送信方法を実現することができる。より具体的には、放送波と通信路を用いてコンテンツを送信した場合には、放送波と通信路とを用いて送信したコンテンツ間との同期を取るための補助情報を送信するので、受信側が補助情報を受信したときには受信側にコンテンツ間の同期を取らせることができる。

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

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

また、例えば、前記補助情報送信ステップでは、前記補助情報を送信することにより、前記コンテンツの基準クロックが異なる場合には、前記差分情報に基づき前記通信路によるコンテンツの基準クロックを前記放送波によるコンテンツの基準クロックに同期させることで前記受信側に前記同期を取らせてもよい。

また、例えば、前記送信方法では、前記コンテンツを、ＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ
Ｔｒａｎｓｐｏｒｔ）にしたがったフォーマットで生成する生成ステップと、前記コンテンツを、前記生成ステップで生成されたフォーマットで送信するコンテンツ送信ステップと、を含んでもよい。

また、例えば、前記生成ステップでは、前記補助情報を、前記コンテンツの取得に関する情報であるメッセージ情報に含めて生成してもよい。

また、上記課題を解決するために、本発明の一態様に係る受信方法は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信ステップと、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報を受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生ステップと、を含む。

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

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

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

また、上記課題を解決するために、本発明の一態様に係る送信装置は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信装置であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報であって、受信側が受信した場合に前記同期を取らせる補助情報を少なくとも前記放送波を用いて送信する情報送信部を備える。

また、上記課題を解決するために、本発明の一態様に係る受信装置は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信部と、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報を受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生部と、を備える。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１）例えばＦＥＣの方式、パラメータなど、通信により送信するパケットにおけるＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）に関連する情報
２）例えばパケットロス率や、パケット到着時刻のジッタ、あるいは、ＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）、通信伝送路におけるｅｎｄ−ｔｏ−ｅｎｄ遅延など、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）コントロールに関連する情報
３）例えばバッファリング時間、バッファリング量など、アセットのデータを受信してから復号開始するまでのバッファリングに関する情報

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、本変形例では、属性情報やロケーション情報が放送のプログラム情報に格納される場合に同期再生されると説明したがそれに限らない。プログラム情報に、伝送路識別デスクリプタが含まれている場合には、伝送路識別デスクリプタにロケーション情報が記述されているストリームと、放送ストリームとを、受信装置は同期再生を行うとしてもよい。このとき、伝送路識別デスクリプタには、放送と通信により伝送されるストリームが互いに同期再生されるかどうかを示す属性情報は含めなくてもよい。

換言すると、本変形例における受信方法は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信ステップと、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報を受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生ステップと、を含むとしてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本変形例では、ロケーション情報の格納方法について具体的な例をあげて説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（変形例６）
以下、変形例５で説明したロケーション情報とは別の例について説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

受信装置は、異なるクロック情報を用いていると判定した場合には、放送と通信の基準クロック情報を同期させる。また、共通のクロック情報を用いていると判定した場合、クロックの同期は不要と判断する。受信装置は、例えば、放送波によるコンテンツの基準クロックと通信路によるコンテンツの基準クロックとの差分情報を含む補助情報を受信し、かつ、放送波によるコンテンツの基準クロックおよび通信路によるコンテンツの基準クロックが異なる場合には、その差分情報に基づき通信路によるコンテンツの基準クロックを前記放送波によるコンテンツの基準クロックに同期させるとしてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

［実施の形態１の効果等］
以上のように、本実施の形態によれば、通信によるコンテンツの受信開始タイミングが遅延しても受信側で放送と通信とを併用したコンテンツを再生可能なコンテンツの送信方法、受信方法、送信装置および受信装置を実現できる。

具体的には、本実施の形態の一態様における送信方法は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報であって受信側が受信した場合に前記同期を取らせる補助情報を、少なくとも前記放送波を用いて送信する情報送信ステップを含む。

これにより、放送波と通信路を用いてコンテンツを送信した場合には、放送波と通信路とを用いて送信したコンテンツ間との同期を取るための補助情報を送信するので、受信側が補助情報を受信したときには受信側にコンテンツ間の同期を取らせることができる。

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

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

また、例えば、前記補助情報送信ステップでは、前記補助情報を送信することにより、前記コンテンツの基準クロックが異なる場合には、前記差分情報に基づき前記通信路によるコンテンツの基準クロックを前記放送波によるコンテンツの基準クロックに同期させることで前記受信側に前記同期を取らせてもよい。

また、例えば、前記送信方法では、前記コンテンツを、ＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ
Ｔｒａｎｓｐｏｒｔ）にしたがったフォーマットで生成する生成ステップと、前記コンテンツを、前記生成ステップで生成されたフォーマットで送信するコンテンツ送信ステップと、を含んでもよい。

また、例えば、前記生成ステップでは、前記補助情報を、前記コンテンツの取得に関する情報であるメッセージ情報に含めて生成してもよい。

また、本実施の形態の一態様における受信方法は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信ステップと、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報を受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生ステップと、を含む。

これにより、例えば放送波などエントリポイントとなる伝送路において送信されるサービス情報を取得し、その中に補助情報が含まれていた場合には、同期を取る処理を行うことができる。

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

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

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

また、本実施の形態の一態様における送信装置は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信装置であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報であって、受信側が受信した場合に前記同期を取らせる補助情報を少なくとも前記放送波を用いて送信する情報送信部を備える。

また、本実施の形態の一態様における受信装置は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信部と、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報を受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生部と、を備える。

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

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

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

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

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

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

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

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

（実施の形態２）
実施の形態１では、放送で送信するストリームと通信で送信するストリームとが同期再生の対象となるか、あるいは、両伝送路により送信されるストリーム間の依存関係などを示す情報を送信する際の送信方法、及び、それら情報を受信する受信方法等について説明した。

ここで、選択可能なオーディオやビデオからユーザーが再生対象を選択する場合や、ビデオにおいて単一ビューの全画面表示からマルチビューに切替えるなど、ユーザー動作の介在を伴う柔軟なコンテンツ再生を受信装置において実現するには、アプリケーションにおいて再生制御を行うのが望ましい。

アプリケーションとしては、広く普及しているＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）のブラウザに基づくものが主流である。アプリケーションがＨＴＭＬである場合、ＨＴＭＬを解釈することで再生制御を行うことができる。ＨＴＭＬであれば、コンテンツの選択や切替え、あるいは、レイアウトの変更などを柔軟に記述できるというメリットもある。

例えば、ＩＰＴＶフォーラムにおいて規定されるハイブリッドキャストでは、ＴＳにおけるＰＭＴの記述子や、ＭＭＴにおけるＭＰＴの記述子など放送番組の受信開始時に必ず参照されるデータにおいて、ａｉｔ＿ｉｄｅｎｔｉｆｉｅｒ＿ｉｎｆｏ（）などアプリケーションが存在することを示す識別情報を送信する。ハイブリッドキャストに対応した受信装置においては、当該識別情報が存在する場合には、ＡＩＴなどのアプリケーション制御情報をＴＳにおけるセクションやデータカルーセル、ＭＭＴにおけるＭＭＴメッセージやデータカルーセルに相当する情報、あるいは、通信ネットワーク経由でダウンロードして取得する。その上で、アプリケーション制御情報に基づいて、ＨＴＭＬファイルなどのアプリケーションを取得する。

以降、アプリケーション制御情報やアプリケーション自体のデータを、アプリケーション関連データと呼ぶ。アプリケーションの記述には、ＸＭＬなどＨＴＭＬ以外の記述言語を用いてもよい。

［デフォルトとなるサービス情報の送信方法］
しかしながら、アプリケーションに対応しない受信機が存在する、あるいは、アプリケーションに対応していたとしても、アプリケーションを取得してから起動するまでには放送や通信における選局開始からのタイムラグが発生する。

従って、再生すべきストリームや表示レイアウトのデフォルト設定情報については、アプリケーション関連データではなく、ＰＭＴやＭＰＴなど選局時に必ず取得するデータ、あるいは、他のＴＳのセクションやＭＭＴのメッセージなど、アプリケーションを起動するまでにかかる時間よりも低遅延で取得できるデータにおいて送信してもよい。そして、高度な再生制御を行うための情報はＨＴＭＬなどのアプリケーションデータとして送信するとしてもよい。

例えば、放送あるいは通信において送信されるストリームの再生制御に関連する情報としては、（ａ）ストリーム間のスケーラビリティに関する情報、（ｂ）マルチリンガルの音声や、ビットレートの異なるビデオなどストリームの切替えに関する情報、（ｃ）同時に表示可能な複数のビデオのストリームを示す情報など同時表示に関する情報、及び、同時表示する場合のレイアウトに関する情報などがあり、これらの情報のデフォルト値をデフォルト再生制御情報と呼ぶとする。

アプリケーションに対応しない受信装置においては、デフォルト値に基づいて再生を行う。一方、アプリケーションに対応する受信装置は、デフォルト値に基づいて再生を開始し、アプリケーションの起動後に、ユーザー動作、あるいは、アプリケーションの制御コマンドなどに基づいて再生動作を切替えるとすればよい。

ユーザー動作による切替えが可能な情報についてのみ、アプリケーションによって再生動作を切替えてもよい。例えば、同時表示に関しては、基本的にはユーザーによる切替えが可能であるが、時間スケーラビリティに関しては、拡張レイヤのストリームが取得可能であれば常に拡張レイヤを使用するとして、受信機が自動的に再生動作を決定してもよい。この場合、時間スケーラビリティに関する情報は、デフォルト再生制御情報においてのみ送信する。

ここで、ＴＳにおいては、再生制御に関する情報は基本的にはアプリケーションにより実行されるが、スケーラビリティに関する情報はデフォルト再生制御情報において送信してもよい。このとき、基本レイヤと拡張レイヤのストリームを対応付けるための情報のみをデフォルト再生制御情報、あるいは、ＭＰＥＧ−２ ＴＳで規定する記述子により送信し、アプリケーションの制御コマンドやユーザー動作に基づいて、アプリケーション側において拡張レイヤを復号するかどうかを決定してもよい。

また、レイアウトに関連する情報についてのみ、アプリケーションによって再生動作を切替えるとしてもよい。例えば、時間スケーラビリティやストリーム切替えは、レイアウトの変更を伴わない。従って、これらの情報はデフォルト再生制御情報においてのみ送信する。一方で、同時表示に関する情報はユーザー動作による切替えが想定されるため、アプリケーションによる再生動作を可能とする。

（デフォルト再生制御情報の記述例）
次に、デフォルト再生制御情報による再生動作をアプリケーションによって切替える際の再生制御情報の記述例について説明する。ここで、デフォルト再生制御情報は記述子に格納され、アプリケーション制御情報はＨＴＭＬにより記述されるものとする。

図１８Ａは、実施の形態２におけるデフォルト再生制御情報の記述例を示す図であり、図１８Ｂは、図１８Ａに示すデフォルト再生制御情報のレイアウト情報に従ったビデオの表示例について示す図である。すなわち、図１８Ａに示すデフォルト再生制御情報において、図１８Ｂに示すようにＰＩＤ＝１００のビデオを全画面表示することがレイアウト情報により示されている。

なお、レイアウト情報としては、ストリームを特定するための情報を示さずに、全画面表示することのみを示してもよい。また、このとき、ビデオストリームが２本以上存在する場合には、デフォルトで再生されるビデオを特定するための情報（アプリケーション制御情報）を別途示すことにすれば、デフォルトで再生されるビデオを全画面表示するように動作させることができる。

図１９Ａは、実施の形態２におけるアプリケーション制御情報の一例を示す図であり、図１９Ｂは、図１９Ａに示すアプリケーション制御情報のレイアウト情報に従ったビデオの表示例について示す図である。

すなわち、図１９Ａに示すアプリケーション制御情報では、領域１と領域２の２つの表示領域をＬａｙｏｕｔタグにより設定し、図１９Ｂに示すようにＰＩＤ＝１００のビデオを領域１に表示し、ＰＩＤ＝２００のビデオを領域２に表示することが示されている。

したがって、図１９Ａに示すＨＴＭＬのアプリケーション制御情報を受信した受信装置は、領域１と領域２に、それぞれＰＩＤ＝１００とＰＩＤ＝２００とのビデオを表示する。なお、ビデオを特定する情報は、ＰＩＤ以外にも、ＵＲＬ、あるいは、ＭＭＴパケットのパケットＩＤなどであってもよい。

このように、図１９Ａおよび１９Ｂに示す例では、デフォルト再生制御情報において、スケーラビリティとレイアウトとの２種類の情報が示されている。スケーラビリティとしては、スケーラビリティの種類が時間スケーラビリティであり、ＰＩＤ＝１００のビデオが基本レイヤで、ＰＩＤ＝２００のビデオが拡張レイヤであることが示される。レイアウト情報としては、ＰＩＤ＝１００のビデオを全画面表示することが示される。

基本レイヤのみではフレームレートが６０ｆｐｓであり、拡張レイヤを用いることで１２０ｆｐｓになるとすると、デフォルトの状態では、ＰＩＤ＝１００のビデオのみを復号して、６０ｆｐｓ相当の映像が全画面表示により再生される。なお、送信されるストリームがスケーラビリティの基本レイヤや拡張レイヤに相当することが、ＭＰＥＧ−２システムのストリームタイプなどストリームの属性情報によって別途示される場合には、デフォルト再生制御情報としては、これらの情報を記述しなくてもよい。また、デフォルトの状態では基本レイヤのみを復号して再生することを別途規定しておけば、レイアウト情報としては、全画面表示することのみを示してもよい。

図２０Ａは、実施の形態２におけるデフォルト再生制御情報の別の記述例を示す図であり、図２０Ｂは、図２０Ａに示すデフォルト再生制御情報のレイアウト情報に従ったビデオの表示例について示す図である。図２１Ａは、実施の形態２におけるアプリケーション制御情報の一例を示す図であり、図２１Ｂは、図２１Ａに示すアプリケーション制御情報のレイアウト情報に従ったビデオの表示例について示す図である。

図２１Ａでは、Ｓｃｒｉｐｔタグにより関数Ａが定義される。関数Ａは、画面上のボタンが押された場合に時間スケーラビリティの拡張レイヤを復号、再生することを指示する関数であり、引数として、基本レイヤと拡張レイヤを特定するインデックス番号などを示す。Ｂｏｄｙタグにおいては、リモコンの特定のボタンなどが押された場合に、関数Ａを呼び出す旨が記述される。

図２１ＡのＨＴＭＬアプリケーションを受信した受信装置は、ボタンが押下げられると、ＰＩＤ＝２００の拡張レイヤのストリームを復号し、１２０ｆｐｓ相当の映像を全画面表示により再生する。

デフォルトで再生するオーディオやビデオなどのストリームは、ＭＰＥＧ−２システムやＭＭＴの記述子などを用いることにより別途示してもよい。例えば、デフォルトで再生するストリームをグループ化して、グループのＩＤとストリームとを対応付けることが可能である。あるいは、デフォルトで再生するストリームを示すための記述子を規定して、記述子の中にデフォルトで再生するストリームのＰＩＤなどのリストを含めることも可能である。

なお、デフォルト再生制御情報におけるデフォルト値を予め規定しておき、パラメータ値が当該デフォルト値と等しい場合にはデフォルト再生制御情報を送信しないことにしてもよい。例えば、レイアウトとして全画面表示をデフォルト値とすれば、全画面表示の場合には、レイアウト情報を含めなくてもよい。このとき、スケーラビリティが使われておらず、ストリームの切替えにも対応しないケースでは、デフォルト再生制御情報を送信しなくてもよい。

［受信方法］
本実施の形態では、受信側は、サービス情報を取得後に、デフォルト再生制御情報、及び、アプリケーションにより提供される再生制御情報を解析して、動作する。以下、図を用いて、本実施の形態における受信方法について説明する。

図２２は、実施の形態２における受信側の動作の一例を示すフローチャートである。図２２には、デフォルト再生制御情報、及び、アプリケーションにより提供される再生制御情報を解析して、スケーラビリティやストリーム切替えなどの機能、コンテンツを提示する際のレイアウトを決定する際の動作の一例が示されている。

まず、ステップＳ７０１において、受信側は、視聴するコンテンツを選局する。

次に、ステップＳ７０２において、受信側は、デフォルト再生制御情報を解析し、復号して再生するストリームを決定するとともに、レイアウトなどの提示方法を決定する。

ここで、デフォルト再生制御情報は、ＰＭＴやＭＰＴなど選局時に必ず取得するデータに含めて送信されるとしてもよいし、アプリケーション関連データとは別途送信される、ＭＰＥＧ−２ ＴＳのセクションやＭＭＴのメッセージなどにより送信されるとしてもよい。

デフォルト再生制御情報がセクションやメッセージにより送信される場合には、デフォルト再生制御情報のデフォルト値を設定しておき、当該セクションやメッセージを受信するまでの間は、デフォルト再生制御情報のデフォルト値に基づいて動作するとしてもよい。また、復号して再生するストリームは、デフォルトで再生するオーディオやビデオなどのストリームを示す記述子を参照することにより決定してもよい。

次に、ステップＳ７０３において、決定した再生制御パラメータに従って再生開始する。

次に、ステップＳ７０４において、アプリケーションを受信するか判定し、受信しない場合（Ｓ７０４でいいえ）には、処理を終了する。一方、受信する場合（Ｓ７０４ではい）には、ステップＳ７０５に進み、アプリケーションにおいて再生制御機能が示されているか判定する。

ステップＳ７０５において、再生制御機能が示されていない場合には（Ｓ７０５でいいえ）、処理を終了する。再生制御機能が示されている場合には（Ｓ７０５ではい）、ステップＳ７０６に進み、アプリケーションに示される再生制御機能に基づいて、制御コマンドやユーザー動作に従って再生制御情報を更新する。

次に、ステップＳ７０７において、更新後の再生制御パラメータに従って再生し、処理を終了する。

［受信装置］
図２３は、実施の形態２における受信装置の構成の一例を示すブロック図である。図２３では、図２２で説明した各ステップの動作を実現する受信装置の構成の一例が示されている。

図２３に示す受信装置７００は、受信部７０１と、デフォルト情報解析部７０２と、アプリ情報受信部７０３と、アプリ再生制御情報解析部７０４と、再生制御実行部７０５とを備える。これらの動作は、図２２で説明した各ステップにおける動作であるため、説明を省略する。

（変形例１）
デフォルト再生制御情報をアプリケーションにより更新する仕組みは、放送単独、通信単独、あるいは、放送と通信を併用してコンテンツを送信する全ての場合において適用できる。

また、本実施の形態における手法における考え方は、現在ＭＰＥＧで規格化中のＭＰＥＧ−２ ＴＳのタイムライン拡張（１３８１８−３：２０１３／ＡＭＤ６）においても適用できる。ＴＳのタイムライン拡張においては、少なくとも１つのＴＳ（基本ＴＳと呼ぶ）を含む複数の多重化ストリームを用いてコンテンツを送信する際に、基本ＴＳと、それ以外の多重化ストリームにおいてコンテンツの復号や表示における基準クロックを同期させるための情報を提供する。

具体的には、基本ＴＳと異なる多重化ストリームの基準クロックと、基本ＴＳのＰＣＲとを対応付ける情報を含むタイムライン拡張用アクセスユニットを定義し、タイムライン拡張用アクセスユニットをＰＥＳパケットに格納し、ＴＳパケット化して送信する。タイムライン拡張用アクセスユニットにおいては、タイムライン拡張用の情報はＭＰＥＧ−２システムの記述子の形式により表現される。このように、ＰＥＳパケット単位でタイムライン拡張用の情報を送信することで、ＰＣＲの不連続が発生した場合にも、更新後のＰＣＲとの基準クロックの同期が迅速に行える。

しかしながら、ＰＣＲの不連続は単一の番組内においては一般的には発生しないため、番組の受信開始時にタイムライン拡張用の情報を受信して、互いの基準クロックを同期すれば、番組内においての再同期は不要であることが多い。

従って、番組内でＰＣＲの不連続が発生しないことが保証される場合には、ＰＭＴなどにタイムライン拡張用の情報のデフォルト値を格納して、タイムライン拡張用のアクセスユニットは送信しないことにしてもよい。例えば、タイムライン拡張用アクセスユニットにおいてタイムライン拡張用の情報を格納する記述子と同様の記述子をＰＭＴなどのセクションに格納して、タイムライン拡張用の情報のデフォルト値として使用できる。また、タイムライン拡張用アクセスユニットとＰＭＴなどに格納されるデフォルト情報とを併用してもよい。

タイムライン拡張用アクセスユニットが送信される場合においても、番組内、あるいは、特定の時刻までＰＣＲの不連続が発生しないことが保証される場合には、選局直後に受信するタイム来拡張用アクセスユニットの情報に基づいてクロック同期を行った後は、番組内、あるいは、特定の時刻までは再同期を行わないことにしてもよい。

また、タイムライン拡張用の情報をセクションにより送信する場合には、ＰＣＲの不連続が発生した直後から一定期間の間、更新後のＰＣＲに対応したタイムライン拡張用の情報を送信してもよい。受信装置においては、セクションのバージョン番号が更新されていれば、当該セクションに含まれるタイムライン拡張用の情報に基づいて再同期を行う。なお、ＰＣＲ不連続の発生後であって、再同期よりも前の時刻においては、ストリーム間のクロック同期が保証できない。このときは、ＴＳのｄｉｓｃｏｎｔｉｎｕｉｔｙ ｉｎｄｉｃａｔｏｒなどＰＣＲの不連続を示す情報に基づいて別途ＰＣＲの不連続を検出し、不連続を検出した場合には、再同期までの間は、基本ＴＳと同期対象となるメディアのアクセスユニットを固定フレームレートと仮定して復号、表示するなどしてもよい。

［実施の形態２の効果等］
以上のように、本実施の形態によれば、オーディオやビデオを含むコンテンツにおける、ビデオの表示に関するレイアウト情報、あるいは、再生時に切替え可能なストリームを示す情報などを含む再生制御情報を送信する際に、選局時に必ず受信するデータに再生制御情報のデフォルト値を格納し、デフォルトの再生制御動作を更新するための情報を、ハイブリッドキャストなどのアプリケーションに関連する情報に格納して送信する。

ここで、再生制御のデフォルト値に従って再生を開始し、受信装置がアプリケーションに対応する場合には、アプリケーションデータとして送信される再生制御機能に基づいて、ユーザー動作などに従ってデフォルトの再生制御情報を更新する。

それにより、コンテンツのレイアウトなど再生制御に係るパラメータの決定に係る遅延時間が低減できる。

（実施の形態３）
上述したように、ＭＭＴ方式によれば、映像及び音声を多重、パケット化し、放送や通信などの一つ以上の伝送路で送信することができる。受信装置においては、一つ以上の伝送路で伝送されたパケットを受信し、プログラム情報を基に受信されたパケットの中から所望のパケットを抽出し、復号・提示をすることができる。

つまり、ＭＭＴ方式では、複数の伝送路で伝送されたメディア（映像や音声、字幕など）を受信してプログラムを構成することが可能である。しかし、放送や通信でダウンロードして蓄積したデータと、放送・通信からストリーミングされたデータの両方を用いてプログラムを構成することができない。

そこで、実施の形態３では、放送や通信でダウンロードして蓄積したデータと、放送・通信からストリーミングされたデータの両方を用いてプログラムを構成する場合の送信方法および受信方法等について説明する。

以下では、放送連携サービスにおける放送側の多重化フォーマットとしては、ＭＰＥＧで規格化されたＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）を例に説明する。

ＭＭＴでは、ＭＰＴ（ＭＭＴ Ｐａｃｋａｇｅ Ｔａｂｌｅ）などのテーブル、あるいは、ＰＡ（Ｐａｃｋａｇｅ Ａｃｃｅｓｓ）メッセージなどのメッセージ情報によりプログラム情報が送信される。ＭＰＴには、プログラムを構成するアセット（ビデオ、オーディオなどの単一メディア）や、アセットを伝送するロケーション情報が記述されている。一つのアセットを複数の伝送路によって伝送することも可能である。

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

［サービス情報］
図２４は、実施の形態３の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。図２５は、実施の形態３のプログラム構成情報記述子に含まれる情報の一例を示す図である。

図２４に示すようにＭＰＴ内にプログラム構成情報記述子が含まれ、本記述子において、パッケージを構成するアセットに関する情報が示される。パッケージを構成するアセットに関する情報には下記を含めることができる。

（アセットに関する情報）
１）プログラムを構成するアセットに、蓄積されているアセット（以後、蓄積アセットと呼ぶ）を含むか含まないかを示す情報をアセットに関する情報としてプログラム構成情報記述子に含めるとしてもよい。ここで、蓄積されているアセットとは、例えばＨＤＤや内部メモリ、ＳＳＤ、ＳＤカードなどのメモリ、ブルーレイディスクなどに蓄積されているアセットである。

２）プログラムを構成するアセットに蓄積アセットを含む場合、プログラムの構成を示す情報をアセットに関する情報としてプログラム構成情報記述子に含めるとしてもよい。

例えば、プログラムが蓄積アセットのみで構成されている、プログラムが蓄積アセットと伝送されているアセット（以後、伝送アセットと呼ぶ）とで構成されている、または、プログラムが蓄積パケットを含むアセットと伝送アセットで構成される、といったプログラムの構成を示す情報を含めるとしてもよい。また、例えばプログラムがスケーラブル符号化された映像で構成される場合、伝送アセットに基本レイヤを含み、蓄積アセットに拡張レイヤを含むことを示す情報を含めるとしてもよい。また、プログラムの再生に、蓄積アセットの復号、再生が必須か、必須でないかを示す情報を含めるとしてもよい。例えば、蓄積アセットのコンテンツが付加的な情報である場合、再生は必須でないとし、蓄積アセットの再生が必須でないことを示す情報を含めるとしてもよい。

また、例えば受信装置が蓄積に対応していない場合、あるいは蓄積アセットが蓄積されていない場合などには、プログラムの再生に蓄積アセットの復号・再生が必須でないことを示す情報を基に、蓄積アセットを用いず、放送や通信から取得したアセットを用いてプログラムを再生することができる。

３）蓄積アセットに関する情報をアセットに関する情報としてプログラム構成情報記述子に含めるとしてもよい。

ここで、例えば、ａ）蓄積アセットの蓄積フォーマットや、映像・音声符号化方式、蓄積アセットを伝送した伝送方式や多重化方式などの属性情報を含めるとしてもよい。この場合、蓄積アセットにはあらかじめ属性情報を付与し、属性情報は、例えば蓄積アセットのヘッダや、蓄積アセットの構成を示すプログラム情報などに含めればよい。受信装置がプログラム情報に格納された属性情報と蓄積アセットの属性情報が一致したときに再生可能としてもよい。また、例えば、ｂ）蓄積アセットを含むプログラムを再生するために必要な受信機の能力、機能に関する情報を含めるとしてもよい。また、例えば、ｃ）プログラムを再生や視聴を制限するための情報（スクランブル方式、視聴制限、限定受信、著作権情報）や鍵を含めるとしてもよい。この場合、受信装置は、プログラム情報に格納された視聴を制限するための情報と、蓄積アセットとを照合し、蓄積アセットの再生や視聴の可否を判断してもよい。また、受信装置は、あらかじめ暗号化されたアセットを蓄積し、送信された鍵を基に蓄積アセットの暗号を復号してもよい。

４）プログラムを構成するアセットが、伝送アセットと蓄積アセットから構成されている場合、伝送アセットと蓄積アセットを同期して再生にするための時刻情報をアセットに関する情報としてプログラム構成情報記述子に含めるとしてもよい。

この時刻情報は、例えば、蓄積アセットに付与されているタイムスタンプの基準となる基準時刻に対する伝送アセットの基準時刻情報とのオフセット量を示すとしてもよい。また、蓄積アセットに付与されているタイムスタンプがＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）やＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）に基づいて付与されている場合、伝送された基準時刻（ＰＣＲやＮＴＰ）に対する相対時刻を示すとしてもよい。また、時刻情報は、蓄積アセットがランダムアクセステーブルをもつフォーマットで蓄積されている場合、蓄積アセットのランダムアクセスポイントに対する伝送アセットの時刻情報テーブルであってもよい。

（ロケーション情報）
ＭＰＴ内には、アセット毎に、アセットのロケーション情報が記述される。例えば一つのアセットが複数のロケーションに存在する場合は、ＭＰＴ内には複数のロケーション情報が記述される。

図２６は、実施の形態３のロケーション情報記述子に含まれる情報の一例を示す図である。図２７は、実施の形態３のロケーション情報記述子に含まれるロケーションタイプの一例を示す図である。

図２６に示すように、ロケーション情報記述子には、ロケーション情報として、ロケーションタイプとロケーションタイプに応じたアセットの特定する識別子とが記述される。

ロケーションタイプは、ロケーション情報のタイプを表す。例えば、図２６に示す例では、ロケーションタイプの値Ｖａｌｕｅが０ｘＡ０（Ｖａｌｕｅ＝０ｘＡ０）であるので、図２７より、ローカルに蓄積されていることがわかる。ロケーションタイプに、ローカルに蓄積されていることが示されている場合、ロケーション情報には蓄積されているデータを一意に示すローカルＩＤを記述される。

ここで、ローカルＩＤは、例えば、蓄積されているアセットのアセットＩＤでもよいし、パケットＩＤでもよい。また、ＡＲＩＢ ＳＴＤ−Ｂ４５に規定されている３２ｂｉｔのトランスポートファイル識別子でもよいし、新たに規定してもよい。また、ネットワークＩＤや、ストリームＩＤなど、さまざまなＩＤを組み合わせ、所定の命名規則に従い、ローカルＩＤを生成してもよい。また、ローカルＩＤは、放送局、送信局、コンテンツプロバイダー等があらかじめ付与してもよいし、受信機側でＩＤを修正、追加の情報を加えて付与してもよい。受信側で独自のＩＤを付与し、送信側で付与されたＩＤとの対応関係を示すテーブルを用意してデータを特定できるとしてもよい。

なお、上記の例は、ロケーションタイプを用いてアセットがローカルに蓄積されていることを示し、別途ローカルＩＤを付与するとしたが、次の方法を用いてもよい。例えば、ロケーションタイプとしてＩＰｖ４を選択し、ローカル特有のＩＰアドレスを用いて指定してもよい。例えば、ＩＰアドレスが、１９２．１６８．ｘｘｘ．ｘｘｘとなっている場合は、アセットがローカルに蓄積されているとし、ｘｘｘ．ｘｘｘの部分で蓄積されたアセットを特定するとしてもよい。

また、蓄積されているアセットのデータ（ファイル）には、ローカルＩＤを付与する。例えば、ファイルの中のファイルヘッダに格納する。ローカルＩＤはあらかじめ放送局、送信局、コンテンツプロバイダーが格納してもよいし、受信側で格納することも考えられる。

上記の記述子は一例であり、同様の機能を持つデータ構造で記述子を構成してもよい。また、本実施の形態の記述子、識別子はＭＰＴのとは異なる、パッケージ単位の情報を示すテーブルやメッセージに格納してもよい。他のシグナリング情報を用いて送信してもよい。

なお、ＭＭＴを例に説明したが、ＭＭＴに限定されるものではなく、ＴＳやＭＰＥＧ−ＤＡＳＨなど他のフォーマットであってもよい。例えば、多重化方式としてＭＰＥＧ２−ＴＳを用いる場合は、ＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）に格納してもよい。また、ＭＰＥＧ２−ＴＳ方式と他の方式とを組み合わせて伝送する場合、ＴＥＭＩ（Ｔｉｍｅｌｉｎｅ ａｎｄ Ｅｘｔｅｒｎａｌ Ｍｅｄｉａ Ｉｎｆｏｒｍａｔｉｏｎ）アクセスユニットに格納してもよい。ＭＰＥＧ−ＤＡＳＨを用いる場合は、ＭＰＤ（Ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ）に記述してもよい。

（アセット構成情報記述子）
ＭＭＴ方式では、一つのアセットを複数の伝送路によって伝送することも可能である。このとき、アセットの構成を示すアセット構成情報記述子を格納してもよい。

図２８は、実施の形態３のアセット構成情報記述子に含まれる情報の一例を示す図である。すなわち、アセットの構成を示す情報には下記を含めることができる。

１）当該アセットが蓄積アセットであることや、アセットが蓄積パケットをアセットの構成を示す情報に含めるとしてもよい。ここで、アセットが蓄積パケットを含む場合とは、一つのアセットが放送や通信から伝送されるパケットと、蓄積されたパケットから構成される場合である。

２）アセットが蓄積アセットである場合、例えば、ａ）当該アセットが蓄積アセットのみで構成されている、蓄積パケットと伝送パケットからと構成されているといった情報をアセットの構成を示す情報として含むとしてもよい。また、ｂ）アセットがスケーラブル符号化された映像で構成される場合、例えば伝送パケットに基本レイヤを含み、蓄積パケットに拡張レイヤを含むことを示す情報などをアセットの構成を示す情報として含むとしてもよい。また、ｃ）アセットの構成として、蓄積パケットの復号、再生が必須であるか必須でないかを示す情報をアセットの構成を示す情報として含むとしてもよい。例えば、蓄積パケットのコンテンツが付加的な情報である場合、再生は必須でないとし、蓄積パケットのコンテンツの再生が必須でないことを示すことができる。

これにより、例えば受信装置が蓄積に対応していない場合、あるいは蓄積パケットを蓄積していない場合などには、アセットの再生に蓄積パケットの復号・再生が必須でないことを示す情報を基に、蓄積パケットを用いず、放送や通信から伝送されるパケットを用いてプログラムを再生することができる。

なお、上述したアセット構成情報記述子は一例であり、同様の機能を持つデータ構造でアセット構成情報記述子を構成してもよい。

また、アセット構成情報記述子、識別子はＭＰＴのとは異なる、パッケージ単位の情報を示すテーブルやメッセージに格納してもよい。他のシグナリング情報を用いて送信してもよい。

なお、ＭＭＴを例に説明したが、ＭＭＴに限定されるものではなく、ＴＳやＭＰＥＧ−ＤＡＳＨなど他のフォーマットであってもよい。例えば、多重化方式としてＭＰＥＧ２−ＴＳを用いる場合は、ＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）に格納してもよい。また、ＭＰＥＧ２−ＴＳ方式と他の方式とを組み合わせて伝送する場合、ＴＥＭＩ（Ｔｉｍｅｌｉｎｅ ａｎｄ Ｅｘｔｅｒｎａｌ Ｍｅｄｉａ Ｉｎｆｏｒｍａｔｉｏｎ）アクセスユニットに格納してもよい。ＭＰＥＧ−ＤＡＳＨを用いる場合は、ＭＰＤ（Ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ）に記述してもよい。

［受信方法および受信装置］
以下、図を用いて、本実施の形態における受信装置が、蓄積アセットを同期再生する動作の一例について説明する。

図２９は、実施の形態３の放送通信連携サービスにおける受信方法を示すフローチャートである。図３０は、実施の形態３における受信装置の構成の一例を示すブロック図である。

図３０に示す受信装置３０は、プログラム情報解析部３１と、蓄積アセット特定部３２、蓄積アセット情報解析部３３、判定部３４と、アセット取得部３５と、同期提示部３６と、同期制御部３７とを備える。

まず、ステップＳ１１において、プログラム情報解析部３１は、エントリポイントとなるプログラム構成情報記述子を解析し、プログラムの構成に蓄積アセットを含むかを解析する。

次に、ステップＳ１２において、プログラム情報解析部３１は、プログラムを構成する要素に蓄積アセットを含むか判定する。プログラムを構成する要素に蓄積アセットを含むと判定した場合（Ｓ１２でＹｅｓ）、ステップＳ１３に進み、プログラムの構成を示す情報や蓄積アセットに関する情報、蓄積アセットとの相対時刻情報などの情報を取得する。蓄積アセットを含まないと判定した場合は（Ｓ１２でＮｏ）、ステップＳ１７に進み、放送や通信などで伝送される伝送アセットを取得して同期再生する。

次に、ステップＳ１４において、受信装置３０は、蓄積アセットのロケーション情報や、ローカルＩＤを取得する。より具体的には、アセットがローカルに蓄積されている場合は、蓄積アセット特定部３２は、受信装置３０に蓄積されているアセットの中から、ローカルＩＤに対応するアセットを検索して特定する。なお、蓄積装置が複数ある場合は、複数の蓄積装置の中から検索してもよいし、特定の蓄積装置の中のみを検索するとしてもよい。また、蓄積アセット情報解析部３３は、特定したアセットの属性情報を取得する。

次に、ステップＳ１５において、判定部３４は、ステップＳ１２で取得された蓄積アセットに関する情報と、ステップＳ１４で取得された蓄積アセットの属性情報とを基に、蓄積アセットを含むプログラムを再生可能かどうか判定する。

プログラムが再生可能と判定されれば（Ｓ１５でＹｅｓ）、ステップＳ１６に進み、アセット取得部３５が放送や通信などの伝送アセットに加え、蓄積アセットを取得する。そして、同期制御部３７は、取得された相対時刻情報を基に、伝送アセットと蓄積アセットとの同期制御処理を施し、同期提示部３６はプログラムの同期や提示を行う。

一方、ステップＳ１５においてプログラムが再生不可能と判定されれば（Ｓ１５でＮｏ）、ステップＳ１７に進み、放送や通信などで伝送される伝送アセットを取得して同期・再生する。

［実施の形態３の効果等］
以上のように、本実施の形態によれば、放送及び通信を連携させたサービスを、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）で規格化中のＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）方式などのフォーマットにより多重化する際のプログラム情報の生成方法、及びプログラムの再生方法、及び再生装置を実現することができる。

ＭＭＴ方式は、映像・音声を多重・パケット化し、放送や通信などの一つ以上の伝送路で送信し、受信装置において一つ以上の伝送路で伝送されたパケットを受信し、プログラム情報を基に受信されたパケットの中から所望のパケットを抽出し、復号・提示をする。

ＭＭＴ方式では、複数の伝送路で伝送されたメディア（映像や音声、字幕など）を受信してプログラムを構成することが可能である。しかし、放送や通信でダウンロードして蓄積したデータと、放送・通信からストリーミングされたデータの両方を用いてプログラムを構成することができない。

そこで、本実施の形態では、プログラムの構成を示すプログラム情報に、プログラムを構成するメディアの一つが蓄積されたデータであることを示す識別子と、蓄積されたメディア（ファイル）を特定できる識別子を設ける。また、再生装置においは、プログラム情報を解析し、放送・通信で伝送されているメディアと蓄積されたデータを特定し、同期して再生する。

それにより、放送や通信でダウンロードして蓄積したデータと、放送・通信からストリーミングされたデータの両方を用いてプログラムを構成することができるので、従来の放送通信連携サービスに加え、蓄積したファイルと連携したサービスを提供することができる。

なお、本実施の形態では、伝送アセットと蓄積アセットとの組み合わせを例に説明したが、それに限らない。伝送アセットは、放送で伝送されるアセットでも良いし、通信で伝送されるアセットでもよい。また、放送と通信両方から伝送されるアセットでもよい。蓄積アセットを用いたサービスとして、下記のようなサービスを提供してもよい。プログラム情報にサービスの内容を示す識別子を格納してもよい。

（蓄積アセットを用いたサービス）
１）あらかじめプログラムを構成するアセットをダウンロードしておき、放送ではプログラム情報や時刻同期情報（時刻基準情報やタイムスタンプの相対値など）のみを送信し、蓄積アセットを用いてプログラムを再生してもよい。このとき、放送業者は、蓄積データを用いたプログラムを、番組編成にそってリアルタイムに視聴者に提供することが可能となる。視聴者はあたかもリアルタイムに放送されている番組を視聴するかのごとく、蓄積データを視聴することができる。リアルタイムな放送だけでなくオンデマンドのコンテンツ提供も可能である。

２）また、あらかじめプログラムを構成するアセットとともにプログラム情報やランダムアクセスポイントなどをダウロード・蓄積し、放送や通信から伝送されるプログラム情報と同期してプログラムを構成してもよい。

３）通常の放送番組は放送のみを用いて送信し、コマーシャル時のみ蓄積データと連携するサービスを提供することも可能である。あらかじめコマーシャルデータを放送又は通信からダウンロードしておき、コマーシャルの時間帯になった時に、蓄積データを含むプログラムを視聴者に提供するとしてもよい。また、複数のあらかじめ複数のコマーシャルデータをダウンロードしておき、視聴者の属性や嗜好に応じて提供するコマーシャルを選択してもよい。視聴者の属性や嗜好などは、受信装置が取得し解析したものであってもよいし、他のアプリやサービスと連携して取得してもよい。

４）放送業者は、蓄積データと連携させたサービスを提供することにより、空いた周波数リソースを他のサービスに割り当ててもよい。このとき、プログラム情報には当該サービスに使用されている周波数リソースが他のサービスに提供されていることを示す情報を格納してもよい。

５）視聴者が蓄積アセットと連携したプログラムに切り替える機能を有してもよい。例えば、伝送アセットのみを視聴している視聴者が、リモコンなどのユーザーインタフェースによって、蓄積アセットを含むプログラムに切り替えてもよい。

６）また、蓄積アセットにアクセスしてプログラムを構成してもよいかを受信装置または視聴者が設定してもよい。また、プログラム情報が、信頼できると認証されている場合にのみ蓄積アセットにアクセスしてプログラムを構成できるとしてもよい。プログラム情報には、そのプログラム情報が信頼できることを示す情報は鍵などを格納してもよい。

（ＥＰＧ）
７）ＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）として表示する情報は、プログラム情報から取得してもよいし、ＥＰＧ専用のシグナリング情報から取得してもよい。

８）プログラムが、放送を用いて提供されるか、通信を用いて提供されるか、蓄積を用いて提供されるか、組み合わせて提供されるか、または拡張サービスとして提供されるか等の情報をＥＰＧに表示してもよい。また、受信装置が提供できる機能のみを表示してもよい。例えば、受信装置が蓄積する機能や通信を受信する機能を保有していない場合は、蓄積や通信に関する情報を表示しないとしてもよい。

９）蓄積アセット含むプログラムにおいて、当該プログラムの蓄積アセットが蓄積されているか蓄積されていないかを示す情報をＥＰＧ上に表示してもよい。当該プログラムの蓄積アセットを提示可能かどうかを示す情報をＥＰＧ上に表示してもよい。文字などで示してもよいし、ＥＰＧのプログラムの背景色などで示してもよい。蓄積アセットを含むコンテンツが視聴制限や著作権に係る情報を提示してもよい。

１０）蓄積アセットを含むプログラムをＥＰＧから予約する場合、蓄積アセットを放送からダウンロード可能か、通信からダウンロード可能か、または通信のストリーミングにより視聴可能かをＥＰＧ等に表示してもよい。受信装置が通信手段を有していない場合は、放送ダウンロード可能かのみを表示するとしてもよい。視聴者はダウンロード予約可能な方法のなかから選択して予約する。

ダウンロードの予約は、事前に視聴者がＥＰＧから予約してもよいし、受信装置が自動でダウンロードしてもよい。ダウンロード方法の選択は視聴者がしてもよいし、受信装置が自動で選択してもよい。

また、放送によりダウンロードできる時間帯、通信によりダウンロードできる時間帯、通信によりストリーミングできる時間帯によってＥＰＧの表示や受信装置の機能を変化させてもよい。

なお、上述のＥＰＧの表示に限らず、ＥＰＧ以外の別の提示方法で提示してもよい。

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

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

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

１１ 識別情報取得部
１４、１０４、３０５、４０５、１１０５ 放送受信部
３０、１００、３００、４００、７００、１１００ 受信装置
３１ プログラム情報解析部
３２ 蓄積アセット特定部
３３ 蓄積アセット情報解析部
３４、１０３ 判定部
３５ アセット取得部
３６ 同期提示部
３７ 同期制御部
１０１、３０１、４０１、１１０１ 識別情報取得部
１０２ アセット決定部
１０５、３０６、４０６、１１０６ 通信受信部
３０２、４０２、１１０２ 決定部
３０３、４０３、１１０３ 通信併用判定部
３０４、４０４、１１０４ Ｌｏｃ情報取得部
４０７ 同期判定部
４０８、１１０８ 再生部
７０１ 受信部
７０２ デフォルト情報解析部
７０３ アプリ情報受信部
７０４ アプリ再生制御情報解析部
７０５ 再生制御実行部
１１０７ 基準クロック判定部

Claims (4)

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

Images