(57)【要約】  本技術は、コンテンツに付随するアプリケーションを用いたサービスを柔軟に運用することができるようにする受信装置、送信装置、及び、データ処理方法に関する。受信装置は、コンテンツを受信する受信部と、前記コンテンツとともに伝送される制御情報に含まれる、前記コンテンツに付随するアプリケーションの取得先を示す取得先情報に基づいて、前記アプリケーションを取得する取得部と、取得された前記アプリケーションを即時に起動する制御部とを備える。本技術は、例えば、デジタル放送を受信可能なテレビ受像機に適用することができる。
2017122554.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツを受信する受信部と、
前記コンテンツとともに伝送される制御情報に含まれる、前記コンテンツに付随するアプリケーションの取得先を示す取得先情報に基づいて、前記アプリケーションを取得する取得部と、
取得された前記アプリケーションを即時に起動する制御部と
を備える受信装置。
【請求項２】
前記コンテンツ及び前記制御情報は、放送波により伝送され、
前記制御情報は、デジタル放送のサービスを提供するためのシグナリングであり、
前記取得先情報は、URL(Uniform Resource Locator)である
請求項１に記載の受信装置。
【請求項３】
前記制御部は、前記コンテンツ又は前記制御情報とともに伝送されるイベントに従い、前記アプリケーションの動作を制御する
請求項２に記載の受信装置。
【請求項４】
前記取得部は、前記コンテンツのDRM(Digital Rights Management)により保護された前記アプリケーションを取得し、
前記受信装置は、取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する検証部をさらに備え、
前記制御部は、前記アプリケーションが正当なアプリケーションであると認められた場合に、当該アプリケーションを起動する
請求項１に記載の受信装置。
【請求項５】
前記検証部は、
前記コンテンツのストリームに含まれる、前記アプリケーションに応じた第１のダイジェスト値を抽出し、
取得された前記アプリケーションに応じた第２のダイジェスト値を生成し、
前記第１のダイジェスト値と、前記第２のダイジェスト値とを比較することで、取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する
請求項４に記載の受信装置。
【請求項６】
前記コンテンツのビデオデータは、所定の符号化方式に従い、符号化されており、
前記第１のダイジェスト値は、暗号化されたVCL-NAL(Video Coding Layer - Network Abstraction Layer)ユニットに含まれるベースバンドフレームに挿入されるウォータマークに格納される
請求項５に記載の受信装置。
【請求項７】
前記コンテンツのビデオデータは、所定の符号化方式に従い、符号化されており、
前記第１のダイジェスト値は、暗号化された非VCL-NAL(Non Video Coding Layer - Network Abstraction Layer)ユニットに格納される
請求項５に記載の受信装置。
【請求項８】
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツを受信し、
前記コンテンツとともに伝送される制御情報に含まれる、前記コンテンツに付随するアプリケーションの取得先を示す取得先情報に基づいて、前記アプリケーションを取得し、
取得された前記アプリケーションを即時に起動する
ステップを含むデータ処理方法。
【請求項９】
コンテンツに付随するアプリケーションの取得先を示す取得先情報であって、取得された前記アプリケーションを即時に起動させるための前記取得先情報を含む制御情報を生成する生成部と、
前記コンテンツとともに、前記制御情報を送信する送信部と
を備える送信装置。
【請求項１０】
送信装置のデータ処理方法において、
前記送信装置が、
コンテンツに付随するアプリケーションの取得先を示す取得先情報であって、取得された前記アプリケーションを即時に起動させるための前記取得先情報を含む制御情報を生成し、
前記コンテンツとともに、前記制御情報を送信する
ステップを含むデータ処理方法。
【請求項１１】
コンテンツを受信する受信部と、
前記コンテンツに付随するアプリケーションであって、前記コンテンツのDRM(Digital Rights Management)により保護された前記アプリケーションを取得する取得部と、
取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する検証部と、
前記アプリケーションが正当なアプリケーションであると認められた場合に、当該アプリケーションを起動する制御部と
を備える受信装置。
【請求項１２】
前記検証部は、
前記コンテンツのストリームに含まれる、前記アプリケーションに応じた第１のダイジェスト値を抽出し、
取得された前記アプリケーションに応じた第２のダイジェスト値を生成し、
前記第１のダイジェスト値と、前記第２のダイジェスト値とを比較することで、取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する
請求項１１に記載の受信装置。
【請求項１３】
前記コンテンツのビデオデータは、所定の符号化方式に従い、符号化されており、
前記第１のダイジェスト値は、暗号化されたVCL-NAL(Video Coding Layer - Network Abstraction Layer)ユニットに含まれるベースバンドフレームに挿入されるウォータマークに格納される
請求項１２に記載の受信装置。
【請求項１４】
前記コンテンツのビデオデータは、所定の符号化方式に従い、符号化されており、
前記第１のダイジェスト値は、暗号化された非VCL-NAL(Non Video Coding Layer - Network Abstraction Layer)ユニットに格納される
請求項１２に記載の受信装置。
【請求項１５】
前記第１のダイジェスト値は、前記アプリケーションを識別するための識別情報とともに、メッセージに含めて伝送される
請求項１２に記載の受信装置。
【請求項１６】
前記取得部は、前記コンテンツとともに伝送される制御情報に含まれる、前記アプリケーションの取得先を示す取得先情報に基づいて、前記アプリケーションを取得し、
前記制御部は、取得された前記アプリケーションが正当なアプリケーションであると認められた場合、当該アプリケーションを即時に起動する
請求項１１に記載の受信装置。
【請求項１７】
前記コンテンツ及び前記制御情報は、放送波により伝送され、
前記制御情報は、デジタル放送のサービスを提供するためのシグナリングであり、
前記取得先情報は、URL(Uniform Resource Locator)である
請求項１６に記載の受信装置。
【請求項１８】
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツを受信し、
前記コンテンツに付随するアプリケーションであって、前記コンテンツのDRM(Digital Rights Management)により保護された前記アプリケーションを取得し、
取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する検証部と、
前記アプリケーションが正当なアプリケーションであると認められた場合、当該アプリケーションを起動する
ステップを含むデータ処理方法。
【請求項１９】
コンテンツに付随するアプリケーションを、前記コンテンツのDRM(Digital Rights Management)により保護する保護部と、
共通のDRM(Digital Rights Management)により保護された前記コンテンツ及び前記アプリケーションを送信する送信部と
を備える送信装置。
【請求項２０】
送信装置のデータ処理方法において、
前記送信装置が、
コンテンツに付随するアプリケーションを、前記コンテンツのDRM(Digital Rights Management)により保護し、
共通のDRM(Digital Rights Management)により保護された前記コンテンツ及び前記アプリケーションを送信する
ステップを含むデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、コンテンツに付随するアプリケーションを用いたサービスを柔軟に運用することができるようにした受信装置、送信装置、及び、データ処理方法に関する。
【背景技術】
【０００２】
番組やCM等のコンテンツに付随するアプリケーション（以下、単にアプリケーションという）の配信のライフサイクルコントロールに、AIT(Application Information Table)等のアプリケーション制御情報を用いることが知られている。このアプリケーション制御情報によって、アプリケーションの起動や終了の動作を制御することができる。【０００３】
一方で、アプリケーションが、いわゆる電波ジャック（放送信号割り込み：Broadcast signal intrusion）などの不正行為により、コンテンツの提供者の意図しない悪意のあるアプリケーションに置き換えられる可能性が問題視されている。【０００４】
この種の問題の解決策としては、PKI(Public Key Infrastructure)等を利用した本格的なアプリケーション認証のプラットフォームを構築する方法も考えられるが、アプリケーション認証のためだけに、本格的なプラットフォームを構築することは、コストの面から現実的ではない。また、コンテンツの著作権を保護するための仕組みとして、デジタル著作権管理（DRM：Digital Rights Management）が知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】WO 2014/080783 A1
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、アプリケーションのライフサイクルコントロールを簡素化する一方で、アプリケーションを低コストでセキュアに提供して、コンテンツに付随するアプリケーションを用いたサービスを柔軟に運用するための提案が要請されていた。【０００７】
本技術はこのような状況に鑑みてなされたものであり、コンテンツに付随するアプリケーションを用いたサービスを柔軟に運用することができるようにするものである。
【課題を解決するための手段】
【０００８】
本技術の第１の側面の受信装置は、コンテンツを受信する受信部と、前記コンテンツとともに伝送される制御情報に含まれる、前記コンテンツに付随するアプリケーションの取得先を示す取得先情報に基づいて、前記アプリケーションを取得する取得部と、取得された前記アプリケーションを即時に起動する制御部とを備える受信装置である。【０００９】
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。【００１０】
本技術の第１の側面の受信装置、及び、データ処理方法においては、コンテンツが受信され、前記コンテンツとともに伝送される制御情報に含まれる、前記コンテンツに付随するアプリケーションの取得先を示す取得先情報に基づいて、前記アプリケーションが取得され、取得された前記アプリケーションが即時に起動される。【００１１】
本技術の第２の側面の送信装置は、コンテンツに付随するアプリケーションの取得先を示す取得先情報であって、取得された前記アプリケーションを即時に起動させるための前記取得先情報を含む制御情報を生成する生成部と、前記コンテンツとともに、前記制御情報を送信する送信部とを備える送信装置である。【００１２】
本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。【００１３】
本技術の第２の側面の送信装置、及び、データ処理方法においては、コンテンツに付随するアプリケーションの取得先を示す取得先情報であって、取得された前記アプリケーションを即時に起動させるための前記取得先情報を含む制御情報が生成され、前記コンテンツとともに、前記制御情報が送信される。【００１４】
本技術の第３の側面の受信装置は、コンテンツを受信する受信部と、前記コンテンツに付随するアプリケーションであって、前記コンテンツのDRM(Digital Rights Management)により保護された前記アプリケーションを取得する取得部と、取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する検証部と、前記アプリケーションが正当なアプリケーションであると認められた場合に、当該アプリケーションを起動する制御部とを備える受信装置である。【００１５】
本技術の第３の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第３の側面のデータ処理方法は、上述した本技術の第３の側面の受信装置に対応するデータ処理方法である。【００１６】
本技術の第３の側面の受信装置、及び、データ処理方法においては、コンテンツが受信され、前記コンテンツに付随するアプリケーションであって、前記コンテンツのDRM(Digital Rights Management)により保護された前記アプリケーションが取得され、取得された前記アプリケーションが、正当なアプリケーションであるかどうかが検証され、前記アプリケーションが正当なアプリケーションであると認められた場合に、当該アプリケーションが起動される。【００１７】
本技術の第４の側面の送信装置は、コンテンツに付随するアプリケーションを、前記コンテンツのDRM(Digital Rights Management)により保護する保護部と、共通のDRM(Digital Rights Management)により保護された前記コンテンツ及び前記アプリケーションを送信する送信部とを備える送信装置である。【００１８】
本技術の第４の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第４の側面のデータ処理方法は、上述した本技術の第４の側面の送信装置に対応するデータ処理方法である。【００１９】
本技術の第４の側面の送信装置、及び、データ処理方法においては、コンテンツに付随するアプリケーションが、前記コンテンツのDRM(Digital Rights Management)により保護され、共通のDRM(Digital Rights Management)により保護された前記コンテンツ及び前記アプリケーションが送信される。
【発明の効果】
【００２０】
本技術の第１の側面乃至第４の側面によれば、コンテンツに付随するアプリケーションを用いたサービスを柔軟に運用することができる。【００２１】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００２２】
【図１】第１の実施の形態の伝送システムの構成例を示す図である。
【図２】DASHサーバの構成例を示す図である。
【図３】シグナリングサーバの構成例を示す図である。
【図４】アプリケーションサーバの構成例を示す図である。
【図５】放送サーバの構成例を示す図である。
【図６】クライアント装置の構成例を示す図である。
【図７】アプリURLに応じたアプリケーション制御の概要を示す図である。
【図８】アプリURLに応じたアプリケーション制御を行う場合の送信側の処理の流れを説明するフローチャートである。
【図９】アプリURLに応じたアプリケーション制御を行う場合の受信側の処理の流れを説明するフローチャートである。
【図１０】MPDイベント方式のMPDメタデータの記述例を示す図である。
【図１１】MPDイベント方式のイベントによるアプリケーション制御を行う場合の送信側の処理の流れを説明するフローチャートである。
【図１２】MPDイベント方式のイベントによるアプリケーション制御を行う場合の受信側の処理の流れを説明するフローチャートである。
【図１３】インバンドイベント方式のDASHEventMessageBoxの配置例を示す図である。
【図１４】インバンドイベント方式のイベントによるアプリケーション制御を行う場合の送信側の処理の流れを説明するフローチャートである。
【図１５】インバンドイベント方式のイベントによるアプリケーション制御を行う場合の受信側の処理の流れを説明するフローチャートである。
【図１６】第２の実施の形態の伝送システムの構成例を示す図である。
【図１７】ストリームサーバの構成例を示す図である。
【図１８】DASHサーバの構成例を示す図である。
【図１９】アプリケーションサーバの構成例を示す図である。
【図２０】クライアント装置の構成例を示す図である。
【図２１】アプリダイジェストの概要を示す図である。
【図２２】アプリダイジェストのシンタックスの例を示す図である。
【図２３】digest_typeの例を示す図である。
【図２４】ISOBMFFに対応したセグメントのデータ形式の例を示す図である。
【図２５】ウォータマーク格納方式の概要を説明する図である。
【図２６】ビデオウォータマークを利用したアプリダイジェストの格納方法を示す図である。
【図２７】ウォータマークペイロードのシンタックスの例を示す図である。
【図２８】WMメッセージブロックのシンタックスの例を示す図である。
【図２９】WMメッセージIDの例を示す図である。
【図３０】ウォータマーク格納方式を採用した場合の送信側の処理の流れを説明するフローチャートである。
【図３１】ウォータマーク格納方式を採用した場合の受信側の処理の流れを説明するフローチャートである。
【図３２】非VCL-NALユニット格納方式の概要を説明する図である。
【図３３】非VCL-NALユニット格納方式を採用した場合の送信側の処理の流れを説明するフローチャートである。
【図３４】非VCL-NALユニット格納方式を採用した場合の受信側の処理の流れを説明するフローチャートである。
【図３５】SLTのフォーマットの例を示す図である。
【図３６】USDのフォーマットの例を示す図である。
【図３７】S-TSIDのフォーマットの例を示す図である。
【図３８】MPDメタデータのapplicationUrl要素の拡張の例を示す図である。
【図３９】S-TSIDのフォーマットの例を示す図である。
【図４０】SrcFlowのフォーマットの例を示す図である。
【図４１】EFDTのフォーマットの例を示す図である。
【図４２】EFDT-Instance要素又はFile要素の拡張の例を示す図である。
【図４３】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００２３】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００２４】
１．第１の実施の形態：アプリケーションのライフサイクルコントロール
（１）システムの構成
（２）アプリURLに応じたアプリケーション制御
（３）アプリ制御イベントに応じたアプリケーション制御
（Ａ）MPDイベント方式
（Ｂ）インバンドイベント方式
２．第２の実施の形態：アプリケーションのセキュアな提供
（１）システムの構成
（２）アプリダイジェストの概要
（３）アプリダイジェストの伝送方式
（Ａ）ウォータマーク格納方式
（Ｂ）非VCL-NALユニット格納方式
３．シグナリングの例
４．変形例
５．コンピュータの構成
【００２５】
＜１．第１の実施の形態：アプリケーションのライフサイクルコントロール＞
【００２６】
ところで、番組やCM等のコンテンツに付随するアプリケーションを用いたサービスを提供するに際し、アプリケーションの制御モデルをシンプルに実装する提案が要請されている。例えば、現在策定が進められている米国の次世代放送規格であるATSC(Advanced Television Systems Committee)3.0では、アプリケーションの配信のライフサイクルコントロールに、AST(Application Signaling Table)を用いることが検討されているが、ASTを利用する以外に、よりアプリケーションの制御モデルをシンプルに実装することが求められている。
【００２７】
そこで、本技術では、シグナリングに、コンテンツに付随して起動するアプリケーションのURL（以下、アプリURL(Uniform Resource Locator)という）のみを記述して、サービス（チャンネル）が選局された場合には、直ちにそのシグナリングに記述されたアプリURLに従い、アプリケーションを取得して、取得されたアプリケーションが即時に起動されるようにする。
【００２８】
すなわち、本技術では、ASTやAIT等のアプリケーション制御情報により制御される個別のアプリケーションのライフサイクルコントロールは行わずに、サービス（チャンネル）そのもの、あるいは、サービス（チャンネル）の特定の時間帯（例えば番組枠やCM枠）にバインドされた１又は複数のアプリURLが、シグナリングに記述されるようにしておくことで、シグナリングにアプリURLが記述される場合には、対象のアプリケーションを取得して、即時に起動されるようにしている。
【００２９】
以下、第１の実施の形態として、アプリURLを利用したアプリケーションのライフサイクルコントロールの簡素化について説明する。
【００３０】
（１）システムの構成
【００３１】
（伝送システムの構成）
図１は、本技術を適用した伝送システムの一実施の形態（第１の実施の形態）の構成例を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
【００３２】
図１において、伝送システム１は、送信側システム５と、受信側のクラインと装置６０から構成される。伝送システム１においては、送信側システム５から送信されるデータが、伝送路８０又はインターネット９０を介してクライアント装置６０により受信される。
【００３３】
例えば、伝送システム１では、ATSC3.0等の所定の規格に準拠したデータ伝送が行われる。なお、ATSC3.0では、伝送方式として、現在広く普及しているMPEG2-TS(Transport Stream)方式ではなく、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式を導入することで、より高度なサービスを提供することが想定されている。
【００３４】
送信側システム５は、例えば、ATSC3.0等の所定の規格に準拠したデータを送信するための処理を行う。送信側システム５は、DASHサーバ１０、シグナリングサーバ２０、アプリケーションサーバ３０、放送サーバ４０、及び、通信サーバ５０から構成される。
【００３５】
DASHサーバ１０は、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)に対応した配信サービスを行うためのサーバである。ここで、MPEG-DASHは、OTT-V(Over The Top Video)に従ったストリーミング配信規格であって、HTTP(Hypertext Transfer Protocol)をベースとしたストリーミングプロトコルを用いたアダプティブストリーミング配信に関する規格である。
【００３６】
このMPEG-DASHの規格では、動画や音声のファイルの管理情報であるメタデータを記述するためのマニフェストファイルと、動画のコンテンツを伝送するためのファイルフォーマットが規定されている。なお、前者のマニフェストファイルは、MPD(Media Presentation Description)と称される。また、後者のファイルフォーマットは、セグメントフォーマットとも称される。
【００３７】
DASHサーバ１０は、外部からMPDメタデータを生成するためのデータや、コンテンツのデータなどを受信する。DASHサーバ１０は、外部からのデータに基づいて、MPDメタデータを生成し、シグナリングサーバ２０に送信する。また、DASHサーバ１０は、外部からのデータに基づいて、番組やCM等のコンテンツのセグメント（以下、DASHセグメントともいう）のファイルを生成し、放送サーバ４０又は通信サーバ５０に送信する。
【００３８】
アプリケーションサーバ３０は、外部からアプリケーションを生成するためのデータなどを受信する。アプリケーションサーバ３０は、外部からのデータに基づいて、アプリケーションの取得先を示すアプリURLを生成し、シグナリングサーバ２０に送信する。また、アプリケーションサーバ３０は、外部からのデータに基づいて、アプリURLで識別されるアプリケーションを生成し、放送サーバ４０又は通信サーバ５０に送信する。
【００３９】
なお、アプリケーションは、番組やCM等のコンテンツに付随するアプリケーションである。また、コンテンツに付随するアプリケーションとしては、例えば、HTML5(HyperText Markup Language 5)等のマークアップ言語や、JavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションを用いることができる。
【００４０】
また、アプリケーションサーバ３０は、アプリケーションの動作を制御するためのイベント（以下、アプリ制御イベントという）を生成し、DASHサーバ１０に送信する。DASHサーバ１０は、アプリケーションサーバ３０から送信されてくるアプリ制御イベントを、MPDメタデータ又はDASHセグメントに格納することができる。
【００４１】
シグナリングサーバ２０は、外部からシグナリングを生成するためのデータを受信する。また、シグナリングサーバ２０は、DASHサーバ１０からのMPDメタデータと、アプリケーションサーバ３０からのアプリURLを受信する。シグナリングサーバ２０は、外部からのデータや、MPDメタデータ、アプリURLに基づいて、シグナリングを生成し、放送サーバ４０又は通信サーバ５０に送信する。
【００４２】
ここで、例えば、ATSC3.0では、シグナリングとして、LLS(Link Layer Signaling)シグナリングとSLS(Service Layer Signaling)シグナリングを用いることが想定されている。LLSシグナリングは、SLSシグナリングに先行して取得されるシグナリングであって、LLSシグナリングに含まれる情報に従い、SLSシグナリングが取得される。SLSシグナリングは、サービス単位のシグナリングである。
【００４３】
LLSシグナリングは、SLT(Service List Table)等のメタデータを含む。SLTメタデータは、サービスの選局に必要な情報（選局情報）など、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含んでいる。
【００４４】
SLSシグナリングは、USD(User Service Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation Description)等のメタデータを含む。USDメタデータは、他のメタデータの取得先などの情報を含む。ただし、USDは、USBD(User Service Bundle Description)と称されることがある。
【００４５】
S-TSIDメタデータは、LSID(LCT Session Instance Description)をATSC3.0向けに拡張したものであって、ROUTE(Real-time Object Delivery over Unidirectional Transport)プロトコルの制御情報である。なお、ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。
【００４６】
MPDメタデータは、上述したように、ストリーミング配信される動画や音声のファイルの管理情報である。なお、SLT，USD，S-TSID，MPD等のメタデータは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記述することができる。
【００４７】
シグナリングサーバ２０は、SLTメタデータを含むLLSシグナリングと、USDメタデータ、S-TSIDメタデータ、及びMPDメタデータを含むSLSシグナリングを生成する。ただし、シグナリングサーバ２０は、DASHサーバ１０により生成されたMPDメタデータを、SLSシグナリングとして処理する。また、シグナリングサーバ２０は、アプリケーションサーバ３０により生成されたアプリURLを、SLT，USD，S-TSID，MPD等のメタデータに含める。
【００４８】
放送サーバ４０は、ATSC3.0等のデジタル放送の規格に準拠したデータ伝送を行うことが可能な送信機である。
【００４９】
放送サーバ４０は、DASHサーバ１０から送信されてくるDASHセグメント、シグナリングサーバ２０から送信されてくるシグナリング、及び、アプリケーションサーバ３０から送信されるアプリケーション（のファイル）を受信する。放送サーバ４０は、DASHセグメント、シグナリング、及び、アプリケーション（のファイル）を処理し、伝送路８０を介して送信（一斉同報配信）する。
【００５０】
また、放送サーバ４０には、LCC(Locally Cached Content)コンテンツが入力される。LCCコンテンツは、クライアント装置６０のストレージに一旦蓄積された後で再生が行われるコンテンツである。放送サーバ４０は、そこに入力されるLCCコンテンツ（のファイル）を処理し、伝送路８０を介して送信（一斉同報配信）する。
【００５１】
通信サーバ５０は、インターネット９０に接続されたクライアント装置６０からの要求に応じて、インターネット９０を介して各種のデータを提供するサーバである。
【００５２】
通信サーバ５０は、DASHサーバ１０から送信されてくるDASHセグメント、シグナリングサーバ２０から送信されてくるシグナリング、及び、アプリケーションサーバ３０から送信されるアプリケーション（のファイル）を受信する。通信サーバ５０は、DASHセグメント、シグナリング、及び、アプリケーション（のファイル）を処理する。そして、通信サーバ５０は、クライアント装置６０からの要求に応じて、インターネット９０を介して、各種のファイルを送信する。
【００５３】
クライアント装置６０は、ATSC3.0等のデジタル放送の規格に準拠した伝送データを受信可能な受信機である。例えば、クライアント装置６０は、テレビ受像機やセットトップボックスなどの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機である。また、クライアント装置６０は、例えば車載テレビなどの自動車に搭載される機器であってもよい。
【００５４】
クライアント装置６０は、放送サーバ４０から伝送路８０を介して送信（一斉同報配信）されてくる、DASHセグメント、シグナリング、LCCコンテンツなどのファイルを受信して処理することで、放送番組などのコンテンツの映像や音声を出力する。
【００５５】
また、クライアント装置６０は、通信機能を有する場合、インターネット９０を介して、通信サーバ５０にアクセスし、各種のファイルを取得することができる。例えば、クライアント装置６０は、通信サーバ５０からインターネット９０を介して送信（適応的にストリーミング配信）される、DASHセグメントやMPDメタデータ等のファイルを受信して処理することで、VOD(Video On Demand)番組などのコンテンツの映像や音声を出力する。
【００５６】
また、クライアント装置６０は、放送サーバ４０又は通信サーバ５０から送信されるシグナリングに含まれるアプリURLに基づいて、放送サーバ４０又は通信サーバ５０から配信されるアプリケーションを取得し、取得されたアプリケーションを即時に起動する。
【００５７】
これにより、クライアント装置６０では、放送経由又は通信経由で取得されたコンテンツに付随して、放送経由又は通信経由で取得されたアプリケーションが実行される。ただし、アプリケーションは、何らかの情報を明示的に表示するだけでなく、非表示で（バックグラウンドで）動作する場合もある（ユーザに認識されずに起動することがある）。
【００５８】
さらに、クライアント装置６０は、MPDメタデータ又はDASHセグメントにアプリ制御イベントが格納されている場合、当該アプリ制御イベントに応じて、アプリケーションの動作を制御する。
【００５９】
なお、伝送システム１において、伝送路８０は、地上波（地上波放送）のほか、例えば、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）を利用した衛星放送、あるいは、ケーブルを用いた有線放送（CATV）などであってもよい。
【００６０】
ここで、図１の伝送システム１においては、説明を簡単にするために、クライアント装置６０を１つだけ図示しているが、クライアント装置６０は複数設けることができ、送信側システム５が送信（一斉同報配信）するデジタル放送信号は、伝送路８０を介して複数のクライアント装置６０で同時に受信することができる。
【００６１】
また、送信側システム５も複数設けることができる。複数の送信側システム５のそれぞれでは、別個のチャンネルとしての、例えば、別個の周波数帯域で、放送ストリームを含むデジタル放送信号を送信し、クライアント装置６０では、複数の送信側システム５のそれぞれのチャンネルの中から、放送ストリームを受信するチャンネルを選択することができる。
【００６２】
次に、図２乃至図６を参照して、図１の伝送システム１における、送信側システム５のDASHサーバ１０、シグナリングサーバ２０、アプリケーションサーバ３０、及び、放送サーバ４０と、クライアント装置６０の構成について説明する。なお、ここでは、通信サーバ５０の詳細な構成は省略するが、通信サーバ５０は、通信機能を有する一般的なサーバと同様の構成を有している。
【００６３】
（DASHサーバの構成）
図２は、図１のDASHサーバ１０の構成例を示す図である。
【００６４】
図２において、DASHサーバ１０は、受信部１０１、処理部１０２、及び、送信部１０３から構成される。
【００６５】
受信部１０１は、外部のサーバ（不図示）などからストリーミング配信用のデータを受信し、処理部１０２に供給する。また、受信部２０１は、アプリケーションサーバ３０から、アプリ制御イベントを受信した場合、アプリ制御イベントを、処理部１０２に供給する。なお、アプリ制御イベントの詳細については後述する。
【００６６】
処理部１０２は、受信部１０１から供給されるデータを処理し、送信部１０３に供給する。また、処理部１０２は、MPD生成部１１１及びDASHセグメント生成部１１２を含んでいる。
【００６７】
MPD生成部１１１は、受信部１０１から供給されるデータに基づいて、MPDメタデータを生成する。また、MPD生成部１１１は、受信部２０１からアプリ制御イベントが供給された場合（後述するMPDイベント方式を採用した場合）、当該アプリ制御イベントを、MPDメタデータに格納する。
【００６８】
DASHセグメント生成部１１２は、受信部１０１から供給されるデータに基づいて、DASHセグメントを生成する。なお、DASHセグメントは、ISOBMFF(ISO Base Media File Format)に準じている。また、DASHセグメント生成部１１２は、受信部２０１からアプリ制御イベントが供給された場合（後述するインバンドイベント方式を採用した場合）、当該アプリ制御イベントを、DASHセグメントに格納する。ただし、詳細は、図１０乃至図１５を参照して後述するが、アプリ制御イベントは、MPDメタデータ又はDASHセグメントのいずれか一方に格納されるようにすればよい。
【００６９】
ここで、DASHセグメントは、中継場所から伝送路や通信回線を介して送られてくるライブコンテンツ（例えば、スポーツ中継等の生放送番組）や、ストレージに蓄積された収録済みのコンテンツ（例えば、ドラマ等の事前収録番組）などのコンテンツを処理して得られるセグメントファイルである。
【００７０】
送信部１０３は、処理部１０２から供給されるデータのうち、MPDメタデータを、シグナリングサーバ２０に送信し、DASHセグメントを、放送サーバ４０又は通信サーバ５０に送信する。なお、ここでは、DASHセグメントが放送経由で配信される場合には、そのデータが放送サーバ４０に送信され、DASHセグメントが通信経由で配信される場合には、そのデータが通信サーバ５０に送信される。
【００７１】
DASHサーバ１０は、以上のように構成される。
【００７２】
（シグナリングサーバの構成）
図３は、図１のシグナリングサーバ２０の構成例を示す図である。
【００７３】
図３において、シグナリングサーバ２０は、受信部２０１、処理部２０２、及び、送信部２０３から構成される。
【００７４】
受信部２０１は、外部のサーバ（不図示）などからシグナリング生成用のデータを受信し、処理部２０２に供給する。また、受信部２０１は、DASHサーバ１０から送信されてくるMPDメタデータと、アプリケーションサーバ３０から送信されてくるアプリURLを受信し、処理部２０２に供給する。
【００７５】
処理部２０２は、受信部２０１から供給されるデータを処理し、送信部２０３に供給する。また、処理部２０２は、シグナリング生成部２１１を含んでいる。
【００７６】
シグナリング生成部２１１は、受信部２０１から供給されるデータに基づいて、SLTメタデータを含むLLSシグナリングと、USDメタデータ、S-TSIDメタデータ、及びMPDメタデータを含むSLSシグナリングを生成する。ただし、SLTメタデータ、USDメタデータ、S-TSIDメタデータ、及びMPDメタデータのうち、いずれかのメタデータには、アプリケーションサーバ３０により生成されたアプリURLが含められる。
【００７７】
送信部２０３は、処理部２０２（のシグナリング生成部２１１）から供給されるシグナリングを、放送サーバ４０又は通信サーバ５０に送信する。なお、ここでは、シグナリングが放送経由で配信される場合には、そのデータが放送サーバ４０に送信され、シグナリングが通信経由で配信される場合には、そのデータが通信サーバ５０に送信される。
【００７８】
シグナリングサーバ２０は、以上のように構成される。
【００７９】
（アプリケーションサーバの構成）
図４は、図１のアプリケーションサーバ３０の構成例を示す図である。
【００８０】
図４において、アプリケーションサーバ３０は、受信部３０１、処理部３０２、及び、送信部３０３から構成される。
【００８１】
受信部３０１は、外部のサーバ（不図示）などからアプリケーション用のデータを受信し、処理部３０２に供給する。処理部３０２は、受信部３０１から供給されるデータを処理し、送信部３０３に供給する。また、処理部３０２は、アプリURL生成部３１１、アプリケーション生成部３１２、及び、アプリ制御イベント生成部３１３を含んでいる。
【００８２】
アプリURL生成部３１１は、受信部３０１から供給されるデータに基づいて、アプリケーションの取得先を示すアプリURLを生成する。アプリケーション生成部３１２は、受信部３０１から供給されるデータに基づいて、アプリURLで識別されるアプリケーションを生成する。
【００８３】
アプリ制御イベント生成部３１３は、アプリケーションに対して所定の動作をさせる所定のタイミングになったとき、アプリケーションの動作を制御するためのイベント（アプリ動作イベント）を生成する。
【００８４】
送信部３０３は、処理部３０２から供給されるデータのうち、アプリURLを、シグナリングサーバ２０に送信し、アプリケーションを、放送サーバ４０又は通信サーバ５０に送信する。なお、ここでは、アプリケーションが放送経由で配信される場合には、そのデータが放送サーバ４０に送信され、アプリケーションが通信経由で配信される場合には、そのデータが通信サーバ５０に送信される。
【００８５】
また、送信部３０３は、処理部３０２（のアプリ制御イベント生成部３１３）からアプリ動作イベントが供給された場合、当該アプリ動作イベントを、DASHサーバ１０に供給する。
【００８６】
アプリケーションサーバ３０は、以上のように構成される。
【００８７】
（放送サーバの構成）
図５は、図１の放送サーバ４０の構成例を示す図である。
【００８８】
図５において、放送サーバ４０は、受信部４０１、処理部４０２、及び、送信部４０３から構成される。
【００８９】
受信部４０１は、DASHサーバ１０から送信されてくるDASHセグメントと、シグナリングサーバ２０から送信されてくるシグナリングと、アプリケーションサーバ３０から送信されてくるアプリケーションを受信し、処理部４０２に供給する。
【００９０】
処理部４０２は、受信部４０１から供給されるDASHセグメント、シグナリング、及び、アプリケーションに対して必要な処理を施し、送信部４０３に供給する。ここでは、例えば、DASHセグメント、SLSシグナリング、及びアプリケーションを含むLCTセッションのデータをペイロードに格納したIP/UDPパケットや、LLSシグナリングのデータをペイロードに格納したIP/UDPパケットを生成するための処理などが行われる。
【００９１】
送信部４０３は、処理部４０２から供給されるデータを含む放送波（デジタル放送信号）を、アンテナ４２１によって、伝送路８０を介して送信（一斉同報配信）する。
【００９２】
放送サーバ４０は、以上のように構成される。
【００９３】
（クライアント装置の構成）
図６は、図１のクライアント装置６０の構成例を示す図である。
【００９４】
図６において、クライアント装置６０は、処理部６０１、入力部６０２、受信部６０３、放送ミドルウェア６０４、DASHクライアント６０５、デコーダ６０６、出力部６０７、及び、通信部６０８から構成される。
【００９５】
処理部６０１は、クライアント装置６０の各部の動作を制御する処理など行う。
【００９６】
入力部６０２は、ユーザの操作に応じた操作信号を処理部６０１に供給する。処理部６０１は、入力部６０２から供給される操作信号に基づいて、クライアント装置６０の各部の動作を制御する。
【００９７】
受信部６０３は、アンテナ６２１によって、放送サーバ４０から伝送路８０を介して送信（一斉同報配信）されてくる放送波（デジタル放送信号）を受信して処理し、それにより得られるデータを、放送ミドルウェア６０４に供給する。なお、受信部６０３は、チューナなどから構成される。
【００９８】
放送ミドルウェア６０４は、受信部６０３から供給されるデータを処理し、処理部６０１又はDASHクライアント６０５に供給する。ここで、処理対象のデータのうち、MPDメタデータ及びDASHセグメントは、DASHクライアント６０５に供給され、アプリケーションやシグナリング等のデータは、処理部６０１に供給される。
【００９９】
DASHクライアント６０５には、放送ミドルウェア６０４からMPDメタデータ及びDASHセグメントが供給される。DASHクライアント６０５は、MPDメタデータに基づいて、DASHセグメントを処理する。このDASHセグメントを処理して得られるビデオとオーディオのデータは、デコーダ６０６に供給される。
【０１００】
デコーダ６０６は、所定の復号方式（例えばHEVC(High Efficiency Video Coding)やAAC(Advanced Audio Coding)等）に従い、DASHクライアント６０５から供給されるビデオとオーディオのデータのデコードを行う。このデコードにより得られるビデオとオーディオのデータは、出力部６０７に供給される。
【０１０１】
出力部６０７は、デコーダ６０６から供給されるビデオとオーディオのデータを出力する。これにより、クライアント装置６０では、番組やCM等のコンテンツが再生され、その映像や音声が出力されることになる。
【０１０２】
通信部６０８は、処理部６０１からの制御に従い、インターネット９０を介して、通信サーバ５０とデータのやりとりを行う。通信部６０８により受信されるデータのうち、MPDメタデータ及びDASHセグメントは、DASHクライアント６０５に供給され、アプリケーション及びシグナリング等のデータは、処理部６０１に供給される。これらの通信経由で取得されたデータに対する処理は、上述した放送経由で取得されたデータと同様であるため、ここでは、その説明は省略する。
【０１０３】
また、処理部６０１は、アプリケーション制御部６１１及びレンダリングエンジン６１２を含んで構成される。アプリケーション制御部６１１は、放送ミドルウェア６０４又は通信部６０８から供給されるアプリケーションの動作を制御する。レンダリングエンジン６１２は、出力部６０７を制御して、ビデオやオーディオ、アプリケーションのデータをレンダリングすることで、映像や音声などを生成する。
【０１０４】
クライアント装置６０は、以上のように構成される。
【０１０５】
（２）アプリURLに応じたアプリケーション制御
【０１０６】
上述したように、番組やCM等のコンテンツに付随するアプリケーションの制御モデルをシンプルに実装する提案が要請されている。第１の実施の形態では、コンテンツに付随して起動するアプリケーションのアプリURLを、シグナリング（例えばSLT，USD，S-TSID，MPD等のメタデータ）に記述することで、クライアント装置６０において、サービスが選局された場合には、直ちにそのシグナリングに記述されたアプリURLに従い、アプリケーションを取得して即時に起動されるようにする。
【０１０７】
ここで、図７の左側に示すように、送信側の送信側システム５においては、アプリケーションサーバ３０のアプリURL生成部３１１により、アプリURLが生成される。また、アプリケーションサーバ３０のアプリケーション生成部３１２により、アプリケーションが生成される。
【０１０８】
ここで、例えば、アプリケーションは、HTML5等のマークアップ言語や、JavaScript（登録商標）等のスクリプト言語で開発され、HTML文書ファイルや画像ファイルなど、複数のファイルから構成されている。また、アプリケーションのエントリ（例えば、index.html）は、アプリURLにより識別される。ただし、エントリとは、アプリケーションにおいて、最初に起動されるページを意味している。
【０１０９】
送信側の送信側システム５においては、放送サーバ４０（又は通信サーバ５０）によって、アプリケーションサーバ３０により生成されたアプリケーションが、伝送路８０（又はインターネット９０）を介して受信側のクライアント装置６０に送信される。
【０１１０】
また、送信側の送信側システム５において、シグナリングサーバ２０（のシグナリング生成部２１１）により生成される、SLTメタデータ、又はSLSシグナリング（例えば、USD，S-TSID，MPD等のメタデータ）には、アプリケーションサーバ３０により生成されたアプリURLが含められる。
【０１１１】
送信側の送信側システム５においては、放送サーバ４０（又は通信サーバ５０）によって、シグナリングサーバ２０により生成されたシグナリングが、伝送路８０（又はインターネット９０）を介して受信側のクライアント装置６０に送信される。
【０１１２】
一方で、図７の右側に示すように、受信側のクライアント装置６０においては、送信側の送信側システム５から送信されるシグナリングが受信され、処理される。このシグナリングには、SLTメタデータ、又はSLSシグナリング（例えば、USD，S-TSID，MPD等のメタデータ）に、アプリURLが含まれている。
【０１１３】
受信側のクライアント装置６０は、SLTメタデータ、又はSLSシグナリングに含まれるアプリURLに従い、放送サーバ４０（又は通信サーバ５０）から送信されるアプリケーションを受信する。そして、受信側のクライアント装置６０は、受信されたアプリケーションを即時に起動する。
【０１１４】
ここで、起動されたアプリケーションは、何らかの情報を明示的に表示する場合もあれば、バックグラウンドを透明にして起動される場合（何も表示せずに起動され、起動されていることをユーザに認識させない場合）もある。
【０１１５】
また、起動中のアプリケーションを停止するタイミングであるが、例えば、ユーザの操作（例えば、リモートコントローラによるサービスの切り替え操作）を契機として、あるいは、クライアント装置６０で実行されるネイティブアプリケーション（組み込みアプリケーション）の制御を契機として、他のサービスに切り替える際に停止することができる。
【０１１６】
ただし、他のサービスに切り替える場合でも、当該他のサービスのSLSメタデータ、又はSLSシグナリングに、同一のアプリURLが含まれていれば、起動中のアプリケーションは停止させずに、そのまま起動が継続されるようにする。この場合には、切り替え先のサービスのサービスID又はメジャーチャンネル番号が、起動中のアプリケーションに通知されるようにして、サービスの切り替えが起こったことが、起動中のアプリケーションにより検知されるようにする。
【０１１７】
なお、シグナリングにおいて、アプリURLは、１つ又は複数をリストとして記述することができる。アプリURLをリストとして記述した場合には、例えば、クライアント装置６０の実行環境などに応じて、それらのアプリURLに応じたアプリケーションの起動優先度の制御や、起動選択制御などが行われる。
【０１１８】
以上のように、第１の実施の形態におけるアプリURLに応じたアプリケーション制御では、SLTメタデータ、又はSLSシグナリング（例えば、USD，S-TSID，MPD等のメタデータ）に含まれるアプリURLに従い、アプリケーションが取得され、即時に起動されるため、アプリケーションの配信ライフサイクルコントロールに、ASTやAIT等のアプリケーション制御情報を利用した場合と比べて、アプリケーションの制御モデルをシンプルに実装することが可能となる。
【０１１９】
次に、図８及び図９のフローチャートを参照して、アプリURLに応じたアプリケーション制御を行う場合における伝送システム１（図１）の各装置で実行される処理の流れを説明する。
【０１２０】
（送信側の処理の流れ）
まず、図８のフローチャートを参照して、アプリURLに応じたアプリケーション制御を行う場合の送信側の処理の流れを説明する。
【０１２１】
図８のステップＳ１０１乃至Ｓ１０３の処理は、DASHサーバ１０により実行される。ステップＳ１０１において、MPD生成部１１１は、MPDメタデータを生成する。また、ステップＳ１０２において、DASHセグメント生成部１１２は、番組等のコンテンツ（のデータ）を処理することで、ステップＳ１０１の処理で生成されたMPDメタデータにより再生が管理されるDASHセグメントを生成する。
【０１２２】
ステップＳ１０３において、送信部１０３は、ステップＳ１０１の処理で生成されたMPDメタデータを、シグナリングサーバ２０に送信し、ステップＳ１０２の処理で生成されたDASHセグメントを放送サーバ４０に送信する。
【０１２３】
図８のステップＳ３０１乃至Ｓ３０３の処理は、アプリケーションサーバ３０により実行される。ステップＳ３０１において、アプリURL生成部３１１は、アプリURLを生成する。ステップＳ３０２において、アプリケーション生成部３１２は、ステップＳ３０１の処理で生成されたアプリURLにより識別されるアプリケーションを生成する。
【０１２４】
ステップＳ３０３において、送信部３０３は、ステップＳ３０１の処理で生成されたアプリURLを、シグナリングサーバ２０に送信し、ステップＳ３０２の処理で生成されたアプリケーションを、放送サーバ４０に送信する。
【０１２５】
図８のステップＳ２０１乃至Ｓ２０２の処理は、シグナリングサーバ２０により実行される。また、シグナリングサーバ２０においては、ステップＳ１０３の処理で送信されたMPDメタデータと、ステップＳ３０３の処理で送信されたアプリURLが受信される。
【０１２６】
ステップＳ２０１において、シグナリング生成部２１１は、シグナリングを生成する。ここで、シグナリングとしては、SLTメタデータを含むLLSシグナリングと、USDメタデータ、S-TSIDメタデータ、及びMPDメタデータを含むSLSシグナリングが生成される。また、SLTメタデータ、又はSLSシグナリング（例えば、USD，S-TSID，MPD等のメタデータ）には、アプリケーションサーバ３０により生成されたアプリURLが記述される。
【０１２７】
ステップＳ２０２において、送信部２０３は、ステップＳ２０１の処理で生成されたシグナリングを、放送サーバ４０に送信する。
【０１２８】
図８のステップＳ４０１乃至Ｓ４０３の処理は、放送サーバ４０により実行される。また、放送サーバ４０においては、ステップＳ１０３の処理で送信されたDASHセグメント、ステップＳ２０２の処理で送信されたシグナリング、及び、ステップＳ３０３の処理で送信されたアプリケーションが受信される。
【０１２９】
送信部４０３は、アプリケーションサーバ３０により生成されたアプリケーション、シグナリングサーバ２０により生成されたシグナリング、及び、DASHサーバ１０により生成されたDASHセグメントを、伝送路８０を介して送信（一斉同報配信）する（Ｓ４０１乃至Ｓ４０３）。
【０１３０】
以上、送信側の処理の流れについて説明した。
【０１３１】
なお、図８の送信側の処理では、アプリケーション、シグナリング、及びDASHセグメントが、放送サーバ４０により放送経由で配信される場合を説明したが、アプリケーション、シグナリング、及びDASHセグメントの全部又はその一部のデータが、通信サーバ５０により通信経由で配信されるようにしてもよい。ただし、以下の説明においても、アプリケーション、シグナリング、及びDASHセグメント等のデータは、放送サーバ４０により放送経由で配信される場合を中心に説明する。
【０１３２】
（受信側の処理の流れ）
次に、図９のフローチャートを参照して、アプリURLに応じたアプリケーション制御を行う場合の受信側の処理の流れを説明する。
【０１３３】
図９に示した処理は、クライアント装置６０により実行される。なお、図９においては、放送ミドルウェア６０４により実行される処理のほか、DASHクライアント６０５やデコーダ６０６、レンダリングエンジン６１２等により実行されるビデオ・オーディオ対応処理と、アプリケーション制御部６１１やレンダリングエンジン６１２等により実行されるアプリケーション対応処理の流れが示されている。
【０１３４】
ただし、ビデオ・オーディオ対応処理は、コンテンツのビデオやオーディオのデータに関する処理を表し、アプリケーション対応処理は、アプリケーションのデータに関する処理を表している。
【０１３５】
クライアント装置６０においては、コンテンツの視聴を行うユーザにより、起動操作が行われた場合（Ｓ１）、処理部６０１や放送ミドルウェア６０４、DASHクライアント６０５、デコーダ６０６などの各部が起動される（Ｓ６０１，Ｓ６２１，Ｓ６３１）。
【０１３６】
ステップＳ６０２において、放送ミドルウェア６０４は、受信部６０３を介して、放送サーバ４０から送信されてくるシグナリングを受信する。ステップＳ６０３において、放送ミドルウェア６０４は、ステップＳ６０２の処理で受信されたシグナリングを処理する。
【０１３７】
ここで、シグナリングとしては、SLTメタデータを含むLLSシグナリングと、USDメタデータ、S-TSIDメタデータ、及びMPDメタデータを含むSLSシグナリングが処理される。また、コンテンツに付随するアプリケーションが存在する場合、SLTメタデータ、又はSLSシグナリング（例えば、USD，S-TSID，MPD等のメタデータ）に、アプリURLが記述されている。
【０１３８】
ステップＳ６０４において、放送ミドルウェア６０４は、ステップＳ６０３の処理で取得されたMPDメタデータを、DASHクライアント６０５に通知する。ステップＳ６２２において、DASHクライアント６０５は、ステップＳ６０４の処理で通知されたMPDメタデータを処理する。
【０１３９】
ステップＳ６０５において、放送ミドルウェア６０４は、受信部６０３を介して、放送サーバ４０から送信されてくるDASHセグメントを受信する。ステップＳ６０６において、放送ミドルウェア６０４は、ステップＳ６０５の処理で受信されたDASHセグメントを、DASHクライアント６０５に転送する。
【０１４０】
ステップＳ６２３において、DASHクライアント６０５は、ステップＳ６２２のMPDメタデータの処理結果に基づいて、ステップＳ６０６の処理で転送されたDASHセグメントを処理する。また、ステップＳ６２４において、デコーダ６０６は、ステップＳ６２３の処理で得られるビデオとオーディオのデータのデコードを行う。
【０１４１】
ステップＳ６２５において、レンダリングエンジン６１２は、ステップＳ６２４の処理で得られるビデオとオーディオのデータのレンダリングを行う。これにより、クライアント装置６０においては、出力部６０７を介して、番組等のコンテンツの映像が表示されるとともにその音声が出力される。
【０１４２】
このように、クライアント装置６０においては、DASHクライアント６０５、デコーダ６０６、及びレンダリングエンジン６１２によって、ステップＳ６２２乃至Ｓ６２５の処理が行われることで、選局された番組等のコンテンツが再生されることになる。
【０１４３】
また、ステップＳ６０７において、放送ミドルウェア６０４は、ステップＳ６０３のシグナリングの処理結果に基づいて、SLTメタデータ、又はSLSシグナリング（例えば、USD，S-TSID，MPD等のメタデータ）等のシグナリングに、アプリURLが記述されているかどうかを判定する。
【０１４４】
ステップＳ６０７において、シグナリングに、アプリURLが記述されていると判定された場合、処理は、ステップＳ６０８に進められる。ステップＳ６０８において、放送ミドルウェア６０４は、アプリケーション制御部６１１からの制御に従い、シグナリングに記述されたアプリURLに基づいて、受信部６０３を介して、放送サーバ４０から送信されてくるアプリケーションを受信する。
【０１４５】
ステップＳ６０９において、放送ミドルウェア６０４は、ステップＳ６０８の処理で受信されたアプリケーションを、アプリケーション制御部６１１に転送する。
【０１４６】
ステップＳ６３２において、アプリケーション制御部６１１は、ステップＳ６０９の処理で転送されたアプリケーションを即時に起動する。また、ステップＳ６３３において、レンダリングエンジン６１２は、ステップＳ６３２の処理で起動されたアプリケーションのデータのレンダリングを行う。これにより、クライアント装置６０においては、番組等のコンテンツに付随したアプリケーションの映像が表示される。
【０１４７】
このように、クライアント装置６０においては、アプリケーション制御部６１１及びレンダリングエンジン６１２によって、ステップＳ６３２乃至６３３の処理が行われることで、アプリケーションが起動されることになる。ただし、アプリケーションは、番組等のコンテンツの映像とともに、画面上に表示されるようにすることは勿論、非表示としてバックグラウンドで実行されるようにしてもよい。
【０１４８】
なお、ステップＳ６０７において、シグナリングに、アプリURLが記述されていないと判定された場合、ステップＳ６０８乃至Ｓ６０９の処理はスキップされる。すなわち、この場合、コンテンツに付随したアプリケーションは、未起動とされる。
【０１４９】
その後、例えば、クライアント装置６０において、コンテンツを視聴しているユーザにより、サービスの切り替え操作が行われた場合（Ｓ２）、放送ミドルウェア６０４は、受信部６０３を介して、放送サーバ４０から送信されてくる、切り替え先のサービスのシグナリングを受信して処理する（Ｓ６１０）。
【０１５０】
なお、ここでは、繰り返しになるのでその詳細な説明は省略するが、サービスの切り替え操作が行われた場合には、上述したステップＳ６０４乃至Ｓ６０６の処理、及び、ステップＳ６２２乃至Ｓ６２５の処理と同様の処理が行われ、切り替え先の番組のコンテンツが再生されることになる。
【０１５１】
また、ステップＳ６１１において、放送ミドルウェア６０４は、ステップＳ６１０のシグナリングの処理結果に基づいて、SLTメタデータ等のシグナリングに、アプリURLが記述されている場合に、そのアプリURLが、起動中のアプリケーションのアプリURLと同一であるかどうかを判定する。
【０１５２】
ステップＳ６１１において、シグナリングに記述されたアプリURLが、起動中のアプリケーションのアプリURLと異なっていると判定された場合、処理は、ステップＳ６１２に進められる。ステップＳ６１２において、放送ミドルウェア６０４は、アプリケーション制御部６１１からの制御に従い、シグナリングに記述されたアプリURLに基づいて、受信部６０３を介して、放送サーバ４０から送信されてくるアプリケーションを受信する。
【０１５３】
ステップＳ６１３において、放送ミドルウェア６０４は、ステップＳ６１２の処理で受信されたアプリケーションを、アプリケーション制御部６１１に転送する。
【０１５４】
ステップＳ６３４において、アプリケーション制御部６１１は、ステップＳ６３２の処理で起動済みのアプリケーションを停止（終了）する。
【０１５５】
ステップＳ６３５において、アプリケーション制御部６１１は、ステップＳ６１３の処理で転送された新たなアプリケーションを即時に起動する。また、ステップＳ６３６において、レンダリングエンジン６１２は、ステップＳ６３５の処理で起動された新たなアプリケーションのデータのレンダリングを行う。これにより、クライアント装置６０においては、ステップＳ６３２の処理で起動されたアプリケーションの映像の代わりに、ステップＳ６３５の処理で起動された新たなアプリケーションの映像が表示される。
【０１５６】
一方で、ステップＳ６１１において、シグナリングにアプリURLが記述されている場合に、起動中のアプリケーションのアプリURLと同一であると判定された場合、処理は、ステップＳ６１４に進められる。
【０１５７】
ステップＳ６１４において、放送ミドルウェア６０４は、切り替え先のサービスのサービスID又はチャンネル番号（メジャーチャンネル番号）を、アプリケーション制御部６１１に通知する。これにより、アプリケーション制御部６１１は、ステップＳ６３２の処理で起動済みのアプリケーションに対して、切り替え先のサービスのサービスID又はチャンネル番号を認識させて、サービスの切り替えが起こったことを、当該アプリケーションが検知できるようにする。
【０１５８】
なお、ステップＳ６１１において、シグナリングにアプリURLが記述されていないと判定された場合には、ステップＳ６１２乃至Ｓ６１４の処理はスキップされる。
【０１５９】
以上、受信側の処理の流れについて説明した。
【０１６０】
（３）アプリ制御イベントに応じたアプリケーション制御
【０１６１】
ところで、アプリケーション自身が、ユーザとのインタラクションやその他のイベントにより、能動的にサービスの切り替えを行うようにしてもよい。この場合には、アプリケーションが、サービスの切り替えのAPI(Application Programming Interface)などをコールすることになる。また、クライアント装置６０において、あるサービスのコンテンツを再生している場合に、明示的にアプリケーションを停止するときには、MPEG-DASHで規定されているDASHイベントを利用して、対象のアプリケーションが解釈できる制御コマンドにより、当該アプリケーションを停止するといったことも可能である。
【０１６２】
ここで、MPEG-DASHでは、DASHイベントと称されるイベント通知機構が定義され、２種類のイベントの転送方法が規定されている。すなわち、１つ目の転送方法は、MPDイベントであり、２つ目の転送方法は、インバンドイベント（インバンドイベントシグナリング）である。第１の実施の形態では、これらのMPDイベントとインバンドイベントを利用して、アプリケーションの動作を制御する。
【０１６３】
なお、DASHイベントを利用する場合の制御コマンドであるが、対象のアプリケーションが解釈できる制御コマンドであればよいため、そのフォーマットや意味などのコマンドの内容については、特に標準化して規定する必要はない。よって、第１の実施の形態では、新たなイベントの種類を定義するSchemIdUriとして、schemIdUri = "urn:atsc:applicationPrivateEvent"を定義することで、送信側システム５とクライアント装置６０とが共通に理解できるプロトコルプリミティブを運ぶためのDASHイベントを導入するものとする。
【０１６４】
以下、MPDイベントを用いてアプリケーションの動作を制御する方式を、MPDイベント方式と称するとともに、インバンドイベント（インバンドイベントシグナリング）を用いてアプリケーションの動作を制御する方式を、インバンドイベント方式と称して、それらの方式の詳細な内容を順に説明する。
【０１６５】
（Ａ）MPDイベント方式
【０１６６】
MPDイベント方式では、MPDメタデータにおいて、ピリオド単位で、EventStream要素が追加され、そこにイベントに関する情報が記述される。すなわち、MPDメタデータ内に、ピリオド単位でイベントの発火スケジュールと、各イベントの発火のタイミングでのクライアント装置６０が処理すべきイベントデータが記述される。これにより、クライアント装置６０においては、MPDメタデータを解析することで、所定のイベントの発火のタイミングで、イベントデータを用いた処理が行われることになる。
【０１６７】
（MPDの記述例）
図１０は、MPDイベント方式のMPDメタデータの記述例を示す図である。
【０１６８】
なお、XML形式のMPDメタデータでは、Period要素、AdaptationSet要素、及び、Representation要素が階層構造で記述されている。Period要素は、コンテンツ等のサービスの構成を記述する単位となる。また、AdaptationSet要素と、Representation要素は、ビデオやオーディオ、字幕等のサービスコンポーネントのストリームごとに利用され、それぞれのストリームの属性を記述できるようになっている。
【０１６９】
図１０において、ルート要素であるMPD要素のavailabilityStartTime属性は、最初のPeriod要素の開始のUTC時刻を表している。また、Period要素のstartTime属性は、MPD要素のavailabilityStartTime属性からのオフセット時間を表している。
【０１７０】
ここで、Period要素には、ビデオやオーディオ等のサービスコンポーネントのストリームごとの情報が記述されるAdaptationSet要素やRepresentation要素のほかに、EventStream要素が追加されている。すなわち、このEventStream要素で指定されるイベントが、AdaptationSet要素で指定されるサービスコンポーネントのストリームと関連付けられている。
【０１７１】
このEventStream要素により、Period要素の単位でのイベント発火スケジュールと、各イベント発火のタイミングでのクライアント装置６０が処理すべき（クライアント装置６０で起動（稼働）しているアプリケーションに渡すべき）イベント関連データを記述することができる。
【０１７２】
図１０のMPDメタデータの記述例では、EventStream要素のschemeIdUri属性により、イベントの種類を定義し、EventStream要素のEvent要素のコンテンツパートに、イベント関連データを記述することができる。つまり、このEvent要素のコンテンツパートに格納されるイベント関連データのフォーマット（何を格納すべきか）については、schemeIdUri属性の値（この例では"urn:xxx"）により定義（特定）される。
【０１７３】
なお、EventStream要素のtimescale属性として、"1000"が指定されているが、これは、Event要素のpresentationTime属性の値の単位時間が、1/1000秒となることを表している。
【０１７４】
また、図１０のEventStream要素において、１つ目のEvent要素のコンテンツパートに、例えば、イベント関連データ−１を記述することで、presentationTime属性で指定される"0"である発火時刻から、duration属性で指定される"1000"である単位時間だけ継続するイベントで、起動中のアプリケーションに対し、イベント関連データ−１を渡すことができる。
【０１７５】
また、２つ目のEvent要素のコンテンツパートに、例えば、イベント関連データ−２を記述することで、presentationTime属性で指定される"1000"である発火時刻から、duration属性で指定される"4000"である単位時間だけ継続するイベントで、起動中のアプリケーションに対し、イベント関連データ−２を渡すことができる。
【０１７６】
ここでは、EventStream要素のschemeIdUri属性の値として、例えば、"urn:atsc:applicationPrivateEvent"を定義することで、図１の送信側システム５とクライアント装置６０とが共通に理解できる独自プロトコルの処理を実現することができる。このような独自プロトコルの処理としては、例えば、クライアント装置６０で実行されているアプリケーションの表示内容の変更やその実行の停止などの処理が該当する。
【０１７７】
なお、MPDイベント方式は、送信側システム５において、MPDメタデータの送出前に、MPDメタデータ内に記述されるPeriod要素の内容が確定できる場合にのみ適用可能となる。
【０１７８】
次に、図１１及び図１２のフローチャートを参照して、MPDイベント方式のイベントによるアプリケーション制御を行う場合における伝送システム１（図１）の各装置で実行される処理の流れを説明する。ただし、このMPDイベント方式のイベントによるアプリケーション制御が行われる前提として、上述した図８及び図９に示した処理によって、クライアント装置６０においてアプリケーションが既に起動中であるものとする。
【０１７９】
（送信側の処理の流れ）
まず、図１１のフローチャートを参照して、MPDイベント方式のイベントによるアプリケーション制御を行う場合の送信側の処理の流れを説明する。
【０１８０】
図１１のステップＳ３１１乃至Ｓ３１２の処理は、アプリケーションサーバ３０により実行される。ステップＳ３１１において、アプリ制御イベント生成部３１３は、アプリ制御イベントを生成する。ステップＳ３１２において、送信部３０３は、ステップＳ３１１の処理で生成されたアプリ制御イベントを、DASHサーバ１０に送信する。
【０１８１】
図１１のステップＳ１１１乃至Ｓ１１３の処理は、DASHサーバ１０により実行される。また、DASHサーバ１０においては、ステップＳ３１２の処理で送信されたアプリ制御イベントが受信される。
【０１８２】
ステップＳ１１１において、MPD生成部１１１は、MPDメタデータを生成するに際して、アプリケーションサーバ３０により生成されたアプリ制御イベントを、MPDイベントとして、MPDメタデータに格納する。
【０１８３】
すなわち、MPDメタデータにおいては、Period要素に、EventStream要素が記述され、そのイベント関連データとして、アプリケーションサーバ３０により生成されたアプリ制御イベントが記述される。なお、このとき、EventStream要素のschemeIdUri属性には、"urn:atsc:applicationPrivateEvent"が指定されている。
【０１８４】
ステップＳ１１２において、DASHセグメント生成部１１２は、番組等のコンテンツを処理することで、ステップＳ１１１の処理で生成されたMPDメタデータにより再生が管理されるDASHセグメントを生成する。
【０１８５】
ステップＳ１１３において、送信部１０３は、ステップＳ１１１の処理で生成されたMPDメタデータを、シグナリングサーバ２０に送信し、ステップＳ１１２の処理で生成されたDASHセグメントを放送サーバ４０に送信する。
【０１８６】
図１１のステップＳ２１１乃至Ｓ２１２の処理は、シグナリングサーバ２０により実行される。また、シグナリングサーバ２０においては、ステップＳ１１３の処理で送信されたMPDメタデータが受信される。
【０１８７】
ステップＳ２１１において、シグナリング生成部２１１は、シグナリングを生成する。ここで、シグナリングとしては、SLTメタデータを含むLLSシグナリングと、USDメタデータ、S-TSIDメタデータ、及びMPDメタデータを含むSLSシグナリングが生成される。ただし、MPDメタデータには、MPDイベント（アプリ制御イベント）が含まれている。
【０１８８】
ステップＳ２１２において、送信部２０３は、ステップＳ２１１の処理で生成されたシグナリングを、放送サーバ４０に送信する。
【０１８９】
図１１のステップＳ４１１乃至Ｓ４１２の処理は、放送サーバ４０により実行される。また、放送サーバ４０においては、ステップＳ１１３の処理で送信されたDASHセグメント、及び、ステップＳ２１２の処理で送信されたシグナリングが受信される。
【０１９０】
送信部４０３は、シグナリングサーバ２０により生成されたシグナリング、及び、DASHサーバ１０により生成されたDASHセグメントを、伝送路８０を介して送信（一斉同報配信）する（Ｓ４１１乃至Ｓ４１２）。
【０１９１】
以上、送信側の処理の流れについて説明した。
【０１９２】
なお、図１１の送信側の処理では、アプリ制御イベントが、アプリケーションサーバ３０により生成される場合を説明したが、アプリ制御イベントの生成を行う専用のイベントサーバを設けるようにしてもよい。また、シグナリング又はDASHセグメントは、通信サーバ５０により通信経由で配信されるようにしてもよい。
【０１９３】
（受信側の処理の流れ）
次に、図１２のフローチャートを参照して、MPDイベント方式のイベントによるアプリケーション制御を行う場合の受信側の処理の流れを説明する。
【０１９４】
ステップＳ６４１乃至Ｓ６４３においては、図９のステップＳ６０２乃至Ｓ６０４と同様に、放送ミドルウェア６０４によって、放送サーバ４０からのシグナリングが受信されて処理され、MPDメタデータが、DASHクライアント６０５に通知される。
【０１９５】
ステップＳ６５１において、DASHクライアント６０５は、ステップＳ６４３の処理で通知されたMPDメタデータを処理する。また、ステップＳ６５２において、DASHクライアント６０５は、ステップＳ６５１のMPDメタデータの処理結果に基づいて、MPDメタデータから、MPDイベントとして格納されたアプリ制御イベントを抽出する。
【０１９６】
すなわち、MPDメタデータにおいては、Period要素に、EventStream要素が記述され、そのイベント関連データとして、アプリ制御イベントが記述されているので、そこから、アプリ制御イベントが抽出される。なお、このとき、EventStream要素のschemeIdUri属性には、"urn:atsc:applicationPrivateEvent"が指定されている。
【０１９７】
ステップＳ６５３において、DASHクライアント６０５は、ステップＳ６５２の処理で抽出されたアプリ制御イベントを、アプリケーション制御部６１１に通知する。
【０１９８】
ステップＳ６６１において、アプリケーション制御部６１１は、ステップＳ６５３の処理で通知されたアプリ制御イベントを受け取る。ステップＳ６６２において、アプリケーション制御部６１１は、ステップＳ６６１の処理で取得したアプリ制御イベントに応じて、独自プロトコルの処理を行う。ここで、独自プロトコルの処理としては、送信側システム５とクライアント装置６０とが共通に理解できる処理であって、例えば、起動中のアプリケーションの表示内容の変更やその実行の停止などの処理が行われる。
【０１９９】
なお、ステップＳ６４４乃至Ｓ６４５においては、図９のステップＳ６０５乃至Ｓ６０６と同様に、放送ミドルウェア６０４によって、DASHセグメントが受信され、DASHクライアント６０５に転送される。また、ステップＳ６５４乃至Ｓ６５６においては、図９のステップＳ６２３乃至Ｓ６２５と同様に、DASHクライアント６０５、デコーダ６０６、及びレンダリングエンジン６１２によって、コンテンツのビデオやオーディオのデータに関する処理が行われることで、番組等のコンテンツの映像が表示されるとともにその音声が出力される。
【０２００】
以上、受信側の処理の流れについて説明した。
【０２０１】
なお、クライアント装置６０においては、図１２の受信側の処理が行われることで、ステップＳ６６２の処理によって、アプリ制御イベントに応じて、起動中のアプリケーションを停止（終了）させることができるが、アプリケーションがいったん停止した後は、同一のサービスのSLSシグナリング（又はSLTメタデータの当該サービスのエントリ）に、停止したアプリケーションのアプリURLと異なるアプリURLが指定されるまでは、アプリケーションが起動されないようにする。このような制御モデルの簡略化によって、アプリケーションのライフサイクルコントロールを簡素化することができるため、例えば、クライアント装置６０の実装やテストを容易にし、導入コストを低減することが可能となる。
【０２０２】
（Ｂ）インバンドイベント方式
【０２０３】
インバンドイベント方式では、MP4のブランド名として"emsg"であるbox_typeを有するDASHEventMessageBoxと称されるMP4 boxを、DASHセグメントに挿入することで、セグメントのストリームの中で、アプリ制御イベントが伝送されるようにする。なお、以下の説明では、DASHEventMessageBoxのうち、"emsg"であるbox_typeを有するDASHEventMessageBoxを、emsgボックスとも称している。
【０２０４】
（DASHEventMessageBoxの配置例）
図１３は、インバンドイベント方式のDASHEventMessageBoxの配置例を示す図である。
【０２０５】
図１３の例では、box_typeのフィールドに、"emsg"が配置されている。また、scheme_id_uriのフィールドには、イベントの種類が定義され、message_dataのフィールドには、イベント関連データが配置されている。
【０２０６】
ここでは、scheme_id_uriのフィールドに、"urn:atsc:applicationPrivateEvent"を定義することで、図１の送信側システム５とクライアント装置６０とが共通に理解できる独自プロトコルの処理を実現することができる。
【０２０７】
また、図１３のＡにおいて、message_dataのフィールドに、イベント関連データ−１を配置することで、presentation_time_deltaのフィールドに配置される"0"である発火時刻（DASHセグメントの一番早いプレゼンテーションタイムから0 x 1/1000秒後）から、event_durationのフィールドに配置される"0xFFFF"である単位時間だけ継続するイベントで、起動中のアプリケーションに対し、イベント関連データ−１を渡すことができる。
【０２０８】
一方で、図１３のＢにおいて、message_dataのフィールドに、イベント関連データ−２を配置することで、presentation_time_deltaのフィールドに配置される"500"である発火時刻（DASHセグメントの一番早いプレゼンテーションタイムから500 x 1/1000秒後）から、event_durationのフィールドに配置される"0xFFFF"である単位時間だけ継続するイベントで、起動中のアプリケーションに対し、イベント関連データ−２を渡すことができる。
【０２０９】
このように、scheme_id_uriのフィールドに、"urn:atsc:applicationPrivateEvent"を定義するとともに、message_dataのフィールドに、イベント関連データ−１やイベント関連データ−２を配置することで、例えば、クライアント装置６０で実行されているアプリケーションの表示内容を変更したり、その実行を停止したりすることができる。
【０２１０】
次に、図１４及び図１５のフローチャートを参照して、インバンドイベント方式のイベントによるアプリケーション制御を行う場合における伝送システム１（図１）の各装置で実行される処理の流れを説明する。
【０２１１】
（送信側の処理の流れ）
まず、図１４のフローチャートを参照して、インバンドイベント方式のイベントによるアプリケーション制御を行う場合の送信側の処理の流れを説明する。
【０２１２】
図１４のステップＳ３２１乃至Ｓ３２２においては、図１１のステップＳ３１１乃至Ｓ３１２と同様に、アプリケーションサーバ３０のアプリ制御イベント生成部３１３によって、アプリ制御イベントが生成され、DASHサーバ１０に送信される。
【０２１３】
図１４のステップＳ１２１乃至Ｓ１２３は、DASHサーバ１０により実行される。また、DASHサーバ１０においては、ステップＳ３２２の処理で送信されたアプリ制御イベントが受信される。ステップＳ１２１において、MPD生成部１１１は、MPDメタデータを生成する。
【０２１４】
ステップＳ１２２において、DASHセグメント生成部１１２は、DASHセグメントを生成するに際して、アプリ制御イベントを、インバンドイベントとして、emsgボックス（DASHEventMessageBox）に格納して、DASHセグメント（のbox構造）に挿入する。
【０２１５】
すなわち、emsgボックス（DASHEventMessageBox）において、scheme_id_uriのフィールドに、"urn:atsc:applicationPrivateEvent"が定義されるとともに、message_dataのフィールドに、イベント関連データとして、アプリケーションサーバ３０により生成されたアプリ制御イベントが配置される。
【０２１６】
ステップＳ１２３において、送信部１０３は、ステップＳ１２１の処理で生成されたMPDメタデータを、シグナリングサーバ２０に送信し、ステップＳ１２２の処理で生成されたDASHセグメントを放送サーバ４０に送信する。
【０２１７】
図１４のステップＳ２２１乃至Ｓ２２２においては、図１１のステップＳ２１１乃至Ｓ２１２と同様に、シグナリングサーバ２０のシグナリング生成部２１１によって、LLSシグナリングとSLSシグナリングが生成され、放送サーバ４０に送信される。
【０２１８】
図１４のステップＳ４２１乃至Ｓ４２２においては、図１１のステップＳ４１１乃至Ｓ４１２と同様に、放送サーバ４０の送信部４０３によって、シグナリングサーバ２０により生成されたシグナリングと、DASHサーバ１０により生成されたDASHセグメントが、伝送路８０を介して送信される。
【０２１９】
以上、送信側の処理の流れについて説明した。
【０２２０】
なお、図１４の送信側の処理では、図１１の送信側の処理と同様に、アプリ制御イベントが、アプリケーションサーバ３０により生成される場合を説明したが、アプリ制御イベントの生成を行う専用のイベントサーバを設けるようにしてもよい。また、シグナリング又はDASHセグメントは、通信サーバ５０により通信経由で配信されるようにしてもよい。
【０２２１】
（受信側の処理の流れ）
次に、図１５のフローチャートを参照して、インバンドイベント方式のイベントによるアプリケーション制御を行う場合の受信側の処理の流れを説明する。
【０２２２】
ステップＳ６７１乃至Ｓ６７３においては、図１２のステップＳ６４１乃至Ｓ６４３と同様に、放送ミドルウェア６０４によって、放送サーバ４０からのシグナリングが受信されて処理され、MPDメタデータが、DASHクライアント６０５に通知される。
【０２２３】
ステップＳ６８１において、DASHクライアント６０５は、ステップＳ６７３の処理で通知されたMPDメタデータを処理する。
【０２２４】
ステップＳ６７４乃至Ｓ６７５においては、図１２のステップＳ６４４乃至Ｓ６４５と同様に、放送ミドルウェア６０４によって、放送サーバ４０からのDASHセグメントが受信され、DASHクライアント６０５に転送される。
【０２２５】
ステップＳ６８２において、DASHクライアント６０５は、ステップＳ６８１のMPDメタデータの処理結果に基づいて、ステップＳ６７５の処理で転送されたDASHセグメントを処理する。また、ステップＳ６８３において、DASHクライアント６０５は、ステップＳ６８２の処理結果に基づいて、DASHセグメント（のbox構造）に挿入されたemsgボックス（DASHEventMessageBox）から、インバンドイベントとして格納されたアプリ制御イベントを抽出する。
【０２２６】
すなわち、emsgボックス（DASHEventMessageBox）においては、scheme_id_uriのフィールドに、"urn:atsc:applicationPrivateEvent"が定義されるとともに、message_dataのフィールドに、イベント関連データとして、アプリ制御イベントが配置されているので、そこから、アプリ制御イベントが抽出される。
【０２２７】
ステップＳ６８４において、DASHクライアント６０５は、ステップＳ６８３の処理で抽出されたアプリ制御イベントを、アプリケーション制御部６１１に通知する。
【０２２８】
ステップＳ６９１乃至Ｓ６９２においては、図１２のステップＳ６６１乃至Ｓ６６２と同様に、アプリケーション制御部６１１によって、アプリ制御イベントに応じた独自プロトコルの処理が行われる。ここで、独自プロトコルの処理としては、送信側システム５とクライアント装置６０とが共通に理解できる処理であって、例えば、起動中のアプリケーションの表示内容の変更やその実行の停止などの処理が行われる。
【０２２９】
なお、ステップＳ６８５乃至Ｓ６８６においては、図１２のステップＳ６５５乃至Ｓ６５６と同様に、デコーダ６０６、及び、レンダリングエンジン６１２によって、コンテンツのビデオやオーディオのデータに関する処理が行われることで、番組等のコンテンツの映像が表示されるとともにその音声が出力される。
【０２３０】
以上、受信側の処理の流れについて説明した。
【０２３１】
なお、クライアント装置６０においては、図１５の受信側の処理が行われることで、ステップＳ６９２の処理によって、アプリ制御イベントに応じて、起動中のアプリケーションを停止（終了）させることができるが、アプリケーションがいったん停止した後は、同一のサービスのSLSシグナリング（又はSLTメタデータの当該サービスのエントリ）に、停止したアプリケーションのアプリURLと異なるアプリURLが指定されるまでは、アプリケーションが起動されないようにする。このような制御モデルの簡略化によって、アプリケーションのライフサイクルコントロールを簡素化することができるため、例えば、クライアント装置６０の実装やテストを容易にし、導入コストを低減することが可能となる。
【０２３２】
＜２．第２の実施の形態：アプリケーションのセキュアな提供＞
【０２３３】
ところで、番組やCM等のコンテンツに付随するアプリケーションは、いわゆる電波ジャックなどの不正行為により、番組等のコンテンツの提供者（例えば放送局）の意図しない悪意のあるアプリケーションに置き換えられる可能性が問題視されている。この種の問題の解決策としては、PKI(Public Key Infrastructure)等を利用した本格的なアプリケーション認証のプラットフォームを構築する方法も考えられるが、アプリケーション認証のためだけに、本格的なプラットフォームを構築することは、コストの面から現実的ではない。
【０２３４】
一方で、アプリケーションが付随する番組等のコンテンツは、デジタル著作権管理（DRM：Digital Rights Management）によって、不正な利用から保護するという運用が想定されるが、本技術では、このDRMのコンテンツ保護の仕組みを利用して、コンテンツに付随するアプリケーションがセキュアに提供されるようにする。
【０２３５】
以下、第２の実施の形態として、DRMのコンテンツ保護の仕組みを利用したアプリケーションのセキュアな提供について説明する。ただし、第２の実施の形態においても、上述した第１の実施の形態と同様に、セキュアに提供されるアプリケーションのライフサイクルコントロールが、簡素化されているものとする。
【０２３６】
また、第２の実施の形態においては、DRMのコンテンツ保護の仕組みを利用して、アプリケーションから一定の計算手順（アルゴリズム）により求められたダイジェスト値（ハッシュ値）を含むアプリダイジェスト（後述する図２２のアプリダイジェスト（app_digest_message））が、次の２つの方式により格納されるようにする。
【０２３７】
すなわち、第１の方式としては、アプリダイジェストを、ウォータマーク（Watermark）として、ビデオ符号化データに挿入してから、VCL-NAL(Video Coding Layer - Network Abstraction Layer)ユニットとして、ISOBMFF(ISO Base Media File Format)のfragmented mp4のmdat内のサンプルとして伝送されるようにする。以下、この第１の方式のことを、ウォータマーク格納方式と称して説明する。
【０２３８】
また、第２の方式としては、アプリダイジェストを、非VCL-NAL(Non Video Coding Layer - Network Abstraction Layer)ユニットに直接格納して、ISOBMFFのfragmented mp4のmdat内のサンプルとして伝送されるようにする。以下、この第２の方式のことを、非VCL-NALユニット格納方式と称して説明する。
【０２３９】
なお、NAL(Network Abstraction Layer)とは、例えばHEVC(High Efficiency Video Coding)等において、ビデオ符号化処理そのものを扱うVCL(Video Coding Layer)と、符号化された情報（符号列）を伝送・蓄積する下位システムとの間に設けられた層（ネットワーク抽象レイヤ）である。したがって、VCLとNALとは、分離された構造となっている。
【０２４０】
（１）システムの構成
【０２４１】
（伝送システムの構成）
図１６は、本技術を適用した伝送システムの一実施の形態（第２の実施の形態）の構成例を示す図である。
【０２４２】
図１６において、伝送システム２は、送信側システム７と、受信側のクライアント装置６０から構成される。なお、図１６の伝送システム２において、図１の伝送システム１と対応する部分には同一の符号が付してあり、繰り返しになる部分の説明は適宜省略するものとする。
【０２４３】
図１６において、送信側システム７は、図１の送信側システム５と比べて、DASHサーバ１０乃至通信サーバ５０に加えて、ストリームサーバ７０が新たに設けられている点が異なっている。
【０２４４】
アプリケーションサーバ３０は、アプリダイジェストを生成する。なお、詳細は、図２２等を参照して後述するが、アプリダイジェストには、アプリケーションのアプリURLと、当該アプリケーションに対して所定のアルゴリズムを適用することで生成されたダイジェスト値（ハッシュ値）が含まれる。
【０２４５】
アプリケーションサーバ３０は、ウォータマーク格納方式を採用した場合には、アプリダイジェストを、ストリームサーバ７０に送信し、非VCL-NALユニット格納方式を採用した場合には、アプリダイジェストを、DASHサーバ１０に送信する。
【０２４６】
ストリームサーバ７０は、番組等のコンテンツ（のデータ）を処理することで、ストリーム（ベースバンドフレームシーケンス）を生成する。また、ストリームサーバ７０は、ストリームのベースバンドフレームをエンコードすることで、VCL-NALユニットを生成する。
【０２４７】
ただし、ストリームサーバ７０は、ウォータマーク格納方式を採用した場合、ストリームのベースバンドフレームに挿入されるウォータマークに、アプリケーションサーバ３０により生成されたアプリダイジェストを格納する。
【０２４８】
DASHサーバ１０は、ストリームサーバ７０から送信されてくるストリームのデータを処理して、DASHセグメントを生成し、放送サーバ４０又は通信サーバ５０に送信する。
【０２４９】
ただし、DASHサーバ１０は、ウォータマーク格納方式を採用した場合、アプリケーションサーバ３０により生成されたアプリダイジェストを格納したウォータマークを含むVCL-NALユニットを暗号化して得られるDRM保護ファイルを処理することで、DASHセグメントを生成する。
【０２５０】
一方で、DASHサーバ１０は、非VCL-NALユニット格納方式を採用した場合、アプリケーションサーバ３０により生成されたアプリダイジェストを格納した非VCL-NALユニットを生成し、VCL-NALユニットと非VCL-NALユニットを暗号化して得られるDRM保護ファイルを処理することで、DASHセグメントを生成する。
【０２５１】
放送サーバ４０又は通信サーバ５０は、DASHサーバ１０により生成されたDASHセグメント、シグナリングサーバ２０により生成されたシグナリング、及び、アプリケーションサーバ３０により生成されたアプリケーションを、伝送路８０又はインターネット９０を介して配信する。
【０２５２】
クライアント装置６０は、図１のクライアント装置６０と同様に、コンテンツを再生したり、当該コンテンツに付随したアプリケーションを実行したりする。また、クライアント装置６０は、図１のクライアント装置６０と比べて、アプリダイジェストを用いてアプリケーションの検証処理を行う点が異なっている。
【０２５３】
すなわち、クライアント装置６０は、ウォータマーク格納方式を採用した場合、DRM保護ファイルに含まれるウォータマークに格納されたアプリダイジェストを抽出し、当該アプリダイジェストを用いて、アプリケーションの検証処理を行う。一方で、クライアント装置６０は、非VCL-NALユニット格納方式を採用した場合、DRM保護ファイルに含まれる非VCL-NALユニットに格納されたアプリダイジェストを抽出し、当該アプリダイジェストを用いて、アプリケーションの検証処理を行う。
【０２５４】
なお、図１６の伝送システム２の構成は一例であって、他の構成を採用してもよい。例えば、アプリダイジェストは、アプリケーションサーバ３０ではなく、専用のサーバが生成するようにしてもよい。また、例えば、ウォータマーク格納方式を採用した場合のウォータマークに関する処理などを、専用のサーバが行うようにしてもよい。
【０２５５】
次に、図１７乃至図２０を参照して、図１６の伝送システム２における、送信側システム７のストリームサーバ７０、DASHサーバ１０、及び、アプリケーションサーバ３０と、クライアント装置６０の構成について説明する。なお、シグナリングサーバ２０は、図３に示した構成と同一であるため、その説明は省略する。また、通信サーバ５０についても、上述した構成と同一の構成を有している。
【０２５６】
（ストリームサーバの構成）
図１７は、図１６のストリームサーバ７０の構成例を示す図である。
【０２５７】
図１７において、ストリームサーバ７０は、受信部７０１、処理部７０２、及び、送信部７０３から構成される。また、処理部７０２は、ストリーム生成部７１１、ウォータマークインサータ７１２、及び、エンコーダ７１３を含んでいる。
【０２５８】
受信部７０１は、外部のサーバ（不図示）などから、番組やCM等のコンテンツ（のデータ）を受信し、処理部７０２に供給する。なお、この例では、番組やCM等のコンテンツ（のデータ）が、外部から提供される場合を説明するが、番組やCM等のコンテンツ（のデータ）は、ストリームサーバ７０により蓄積されるようにしてもよい。
【０２５９】
また、受信部７０１は、ウォータマーク格納方式を採用した場合、アプリケーションサーバ３０から送信されてくるアプリダイジェストを受信し、処理部７０２（のウォータマークインサータ７１２）に供給する。
【０２６０】
処理部７０２は、受信部７０１から供給される番組等のコンテンツ（のデータ）を処理し、送信部７０３に供給する。また、処理部７０２は、ストリーム生成部７１１、ウォータマークインサータ７１２、及び、エンコーダ７１３から供給される。
【０２６１】
ストリーム生成部７１１は、受信部７０１から供給される番組等のコンテンツ（のデータ）を処理することで、ビデオのストリーム（ベースバンドフレームシーケンス）を生成する。なお、ここでは詳細な説明は省略するが、ストリーム生成部７１１はコンテンツ（のデータ）を処理することで、オーディオのストリームも生成している。
【０２６２】
ウォータマークインサータ７１２は、ウォータマーク格納方式を採用した場合、ストリーム生成部７１１により生成されたストリームのベースバンドフレームに挿入されるウォータマーク（ウォータマークペイロード）に、アプリケーションサーバ３０により生成されるアプリダイジェストを格納する。
【０２６３】
ただし、ウォータマークインサータ７１２は、ウォータマーク格納方式を採用した場合にのみ動作するものであって、非VCL-NALユニット格納方式を採用した場合、ストリームサーバ７０において、ウォータマークインサータ７１２を動作させる必要はない（設ける必要はない）。
【０２６４】
エンコーダ７１３は、所定の符号化方式（例えばHEVC等）に従い、ストリーム生成部７１１により生成されたビデオのストリームのベースバンドフレームをエンコードし、VCL-NALユニットを生成する。なお、ここでは詳細な説明は省略するが、エンコーダ７１３は、ストリーム生成部７１１により生成されたオーディオのストリームについても、所定の符号化方式（例えばAAC等）に従い、エンコードすることになる。
【０２６５】
送信部７０３は、処理部７０２（のエンコーダ７１３）から供給されるVCL-NALユニット（とオーディオのデータ）を含むストリームのデータを、DASHサーバ１０に送信する。
【０２６６】
ストリームサーバ７０は、以上のように構成される。
【０２６７】
（DASHサーバの構成）
図１８は、図１６のDASHサーバ１０の構成例を示す図である。なお、図１８のDASHサーバ１０において、図２のDASHサーバ１０と対応する部分には同一の符号が付してあり、その説明は適宜省略する。
【０２６８】
図１８において、DASHサーバ１０は、受信部１０１、処理部１０２、及び、送信部１０３から構成される。また、処理部１０２は、MPD生成部１１１、及び、DASHセグメント生成部１１２に加えて、暗号化部１１３、DRM保護ファイル生成部１１４、及び、非VCL-NALユニット生成部１１５を含んでいる。
【０２６９】
受信部１０１は、ストリームサーバ７０から送信されてくるストリームのデータを受信し、処理部１０２に供給する。処理部１０２は、受信部１０１から供給されるストリームのデータを処理し、DASHセグメントを生成し、送信部１０３に供給する。送信部１０３は、処理部１０２から供給されるDASHセグメントを、放送サーバ４０又は通信サーバ５０に送信する。
【０２７０】
より具体的には、ウォータマーク格納方式を採用した場合には、次のようにしてDASHセグメントが生成される。すなわち、暗号化部１１３は、所定の暗号化方式に従い、ストリームサーバ７０により生成されたVCL-NALユニットを暗号化する。
【０２７１】
続いて、DRM保護ファイル生成部１１４は、暗号化部１１３により暗号化されたVCL-NALユニットを処理して、DRM保護ファイルを生成する。ここでは、例えば、PlayReady（登録商標）等のDRMの方式に従い、DRM保護ファイルは保護される。そして、DASHセグメント生成部１１２は、DRM保護ファイル生成部１１４により生成されたDRM保護ファイルを処理して、DASHセグメントを生成する。
【０２７２】
一方で、非VCL-NALユニット格納方式を採用した場合には、次のようにしてDASHセグメントが生成される。すなわち、非VCL-NALユニット生成部１１５は、アプリケーションサーバ３０により生成されたアプリダイジェストを格納した非VCL-NALユニットを生成する。また、暗号化部１１３は、所定の暗号化方式に従い、ストリームサーバ７０により生成されたVCL-NALユニットと、非VCL-NALユニット生成部１１５により生成された非VCL-NALユニットを暗号化する。
【０２７３】
続いて、DRM保護ファイル生成部１１４は、暗号化部１１３により暗号化されたVCL-NALユニットと非VCL-NALユニットを処理して、DRM保護ファイルを生成する。ここでは、例えば、PlayReady（登録商標）等のDRMの方式に従い、DRM保護ファイルは保護される。そして、DASHセグメント生成部１１２は、DRM保護ファイル生成部１１４により生成されたDRM保護ファイルを処理して、DASHセグメントを生成する。ただし、非VCL-NALユニット生成部１１５は、非VCL-NALユニット格納方式を採用した場合にのみ動作するものであって、ウォータマーク格納方式を採用した場合、DASHサーバ１０において、非VCL-NALユニット生成部１１５を動作させる必要はない（設ける必要はない）。
【０２７４】
DASHサーバ１０は、以上のように構成される。
【０２７５】
（アプリケーションサーバの構成）
図１９は、図１６のアプリケーションサーバ３０の構成例を示す図である。なお、図１９のアプリケーションサーバ３０において、図４のアプリケーションサーバ３０と対応する部分には同一の符号が付してあり、その説明は適宜省略する。
【０２７６】
図１９において、アプリケーションサーバ３０は、受信部３０１、処理部３０２、及び、送信部３０３から構成される。また、処理部３０２は、アプリURL生成部３１１、アプリケーション生成部３１２、及び、アプリ制御イベント生成部３１３に加えて、アプリダイジェスト生成部３１４を含んでいる。
【０２７７】
アプリダイジェスト生成部３１４は、アプリケーション生成部３１２により生成されたアプリケーションから一定の計算手順（アルゴリズム）により求められたダイジェスト値（ハッシュ値）を含むアプリダイジェストを生成し、送信部３０３に供給する。なお、アプリダイジェストの詳細な内容は、図２２等を参照して後述する。
【０２７８】
送信部３０３は、アプリダイジェスト生成部３１４から供給されるアプリダイジェストを、DASHサーバ１０又はストリームサーバ７０に送信する。
【０２７９】
なお、ここでは、ウォータマーク格納方式を採用した場合、アプリダイジェストは、ストリームサーバ７０に送信される。一方で、非VCL-NALユニット格納方式を採用した場合、アプリダイジェストは、DASHサーバ１０に送信される。
【０２８０】
アプリケーションサーバ３０は、以上のように構成される。
【０２８１】
（クライアント装置の構成）
図２０は、図１６のクライアント装置６０の構成例を示す図である。なお、図２０のクライアント装置６０において、図６のクライアント装置６０と対応する部分には同一の符号が付してあり、その説明は適宜省略する。
【０２８２】
図２０において、クライアント装置６０は、処理部６０１、入力部６０２、受信部６０３、放送ミドルウェア６０４、DASHクライアント６０５、デコーダ６０６、出力部６０７、及び、通信部６０８から構成される。また、処理部６０１は、図６の処理部６０１と比べて、アプリケーション制御部６１１及びレンダリングエンジン６１２に加えて、ウォータマークイクストラクタ６１３及びアプリダイジェストバリデータ６１４を有している。
【０２８３】
図１６のクライアント装置６０では、図６のクライアント装置６０と比べて、アプリダイジェストを用いてアプリケーションの検証処理を行う点が異なっている。
【０２８４】
より具体的には、ウォータマーク格納方式を採用した場合には、次のようにして、アプリダイジェストを用いたアプリケーションの検証処理が行われる。すなわち、DASHクライアント６０５（のDRM保護ファイル処理部）は、DASHセグメントを処理することで得られるDRM保護ファイルのアンパッケージングを行う。また、DASHクライアント６０５（の復号部）は、所定の復号方式に従い、DRM保護ファイルのアンパッケージングを行うことで得られる暗号化されたVCL-NALユニットを復号する。
【０２８５】
続いて、デコーダ６０６は、所定の復号方式（例えばHEVC等）に従い、DASHクライアント６０５により処理されたVCL-NALユニットをデコードする。このとき、ウォータマークイクストラクタ６１３は、VCL-NALユニットをデコードすることで得られるベースバンドフレームに挿入されているウォータマークを抽出する。アプリダイジェストバリデータ６１４は、ウォータマークイクストラクタ６１３により抽出されたウォータマークに格納されたアプリダイジェストを抽出する。
【０２８６】
そして、アプリダイジェストバリデータ６１４は、ウォータマークに格納されたアプリダイジェストと、放送ミドルウェア６０４からのアプリケーションに応じたアプリダイジェストとを比較して、比較対象のアプリダイジェストが一致する場合には、放送ミドルウェア６０４からのアプリケーションを（即時に）起動する。
【０２８７】
一方で、非VCL-NALユニット格納方式を採用した場合には、次のようにして、アプリダイジェストを用いたアプリケーションの検証処理が行われる。すなわち、DASHクライアント６０５（のDRM保護ファイル処理部）は、DASHセグメントを処理することで得られるDRM保護ファイルのアンパッケージングを行う。また、DASHクライアント６０５（の復号部）は、所定の復号方式に従い、DRM保護ファイルのアンパッケージングを行うことで得られる暗号化された非VCL-NALユニットを復号する。
【０２８８】
続いて、アプリダイジェストバリデータ６１４は、DASHクライアント６０５（の復号部）により復号された非VCL-NALユニットに格納されたアプリダイジェストを抽出する。
【０２８９】
そして、アプリダイジェストバリデータ６１４は、非VCL-NALユニットに格納されたアプリダイジェストと、放送ミドルウェア６０４からのアプリケーションに応じたアプリダイジェストとを比較して、比較対象のアプリダイジェストが一致する場合には、放送ミドルウェア６０４からのアプリケーションを（即時に）起動する。
【０２９０】
このようにして、クライアント装置６０では、ウォータマーク格納方式又は非VCL-NALユニット格納方式によって、アプリダイジェストを用いたアプリケーションの検証処理が行われる。ただし、ウォータマークイクストラクタ６１３は、ウォータマーク格納方式を採用した場合にのみ動作するものであって、非VCL-NALユニット格納方式を採用した場合、クライアント装置６０において、ウォータマークイクストラクタ６１３を動作させる必要はない（設ける必要はない）。
【０２９１】
クライアント装置６０は、以上のように構成される。
【０２９２】
（２）アプリダイジェストの概要
【０２９３】
上述した第１の実施の形態においては、コンテンツに付随するアプリケーションのライフサイクルコントロールとして、アプリケーションの起動制御を行う場合に、アプリケーションのアプリURLを、クライアント装置６０に通知することで、クライアント装置６０では、当該アプリURLで識別されるアプリケーション（アプリケーションパッケージ）が取得され、即時に起動されることになる。
【０２９４】
このとき、アプリケーションは、放送経由又は通信経由で取得されることになるが、放送の伝送経路上で、アプリURL又はアプリケーションそのもののすげ替えや改ざんなどの不正行為が行われる危険性がある場合には、これを保護する必要がある。
【０２９５】
このような保護の方法の１つとして、例えば、アプリURLを含むSLTメタデータやSLSシグナリング（のメタデータ）を伝送するセッション、さらには、アプリケーションを伝送するセッションそのものを、しかるべきトランスポート／ネットワークのセキュリティ技術（例えば、IPSec(Security Architecture for Internet Protocol)など）を利用して、暗号化する方法が想定される。
【０２９６】
しかしながら、この種の暗号化や改ざんなどの検出のためのシステムを構築するにはコストが問題となることがあり、コストを最小限に抑えて、より容易に、アプリURLやアプリケーションのすげ替えや改ざんなどの不正行為の危険性から保護するための仕組みが求められている。
【０２９７】
そこで、第２の実施の形態では、アプリケーションのすげ替えや改ざんなどの不正行為を検出するために、送信側システム７で、ハッシュ関数のアルゴリズムにより計算されるアプリケーション自身のダイジェスト値（ハッシュ値）が、アプリダイジェストとして、クライアント装置６０に通知されるようにする。そして、クライアント装置６０では、送信側システム７から通知されるアプリダイジェスト（アプリケーション自身のダイジェスト値）を用い、アプリケーションに対し、すげ替えや改ざんなどの不正行為が行われているか否かを検証することになる。
【０２９８】
例えば、アプリケーションが、HTML文書ファイル等の複数のファイル群から構成される場合に、当該アプリケーションを構成するファイル群をまとめて署名する方式としては、XML署名（XML Signature）により規定された方式を用いることができる。なお、XML署名は、W3C(World Wide Web Consortium)によって、デジタル署名のためのXML構文を規定するものとして勧告されている。
【０２９９】
ここで、図２１の左側に示すように、送信側の送信側システム７においては、アプリケーションサーバ３０のアプリダイジェスト生成部３１４により、クライアント装置６０に配信されるアプリケーションに対して、所定のアルゴリズムを適用することで生成されたダイジェスト値（ハッシュ値）を含むアプリダイジェストが生成される。このアプリダイジェストとしては、例えば、対象のアプリケーションのアプリURLと、そのアプリURLに、MD5(Message Digest Algorithm 5)やSHA-1，SHA-256などの所定のアルゴリズムを適用することで得られるダイジェスト値が含まれるようにすることができる。
【０３００】
送信側の送信側システム７においては、放送サーバ４０（又は通信サーバ５０）によって、アプリケーションサーバ３０により生成されたアプリケーションが、伝送路８０（又はインターネット９０）を介して、受信側のクライアント装置６０に送信される。
【０３０１】
また、送信側の送信側システム７においては、放送サーバ４０（又は通信サーバ５０）によって、アプリケーションサーバ３０により生成されたアプリダイジェストが、ウォータマーク格納方式又は非VCL-NALユニット格納方式により保護された状態で、伝送路８０（又はインターネット９０）を介して、受信側のクライアント装置６０に送信される。
【０３０２】
一方で、受信側のクライアント装置６０においては、送信側の送信側システム７から送信されるアプリケーションが受信される。受信側のクライアント装置６０は、送信側の送信側システム７から配信（受信）されたアプリケーションに対して、送信側の送信側システム７と同一のアルゴリズムを適用して、アプリダイジェスト（ダイジェスト値）を生成する。ここでは、例えば、対象のアプリケーションのアプリURLに、MD5やSHA-1，SHA-256などの所定のアルゴリズムを適用することで、ダイジェスト値が求められる。
【０３０３】
また、受信側のクライアント装置６０においては、送信側の送信側システム７から送信されるアプリダイジェストであって、ウォータマーク格納方式又は非VCL-NALユニット格納方式により保護されたアプリダイジェストが受信される。
【０３０４】
そして、受信側のクライアント装置６０は、ウォータマーク格納方式又は非VCL-NALユニット格納方式により保護されたアプリダイジェスト（ダイジェスト値）と、自身が送信側と同一のアルゴリズムを適用することで求めたアプリダイジェスト（ダイジェスト値）とを比較して、それらのアプリダイジェスト（ダイジェスト値）が一致するかどうかを判定する。
【０３０５】
受信側のクライアント装置６０は、アプリダイジェスト（ダイジェスト値）が一致すると判定した場合には、送信側の送信側システム７から配信されたアプリケーションを、例えば、即時に起動するなど、正当なアプリケーションとして処理する。一方で、受信側のクライアント装置６０は、アプリダイジェスト（ダイジェスト値）が一致しないと判定した場合には、送信側の送信側システム７から配信されたアプリケーションを、例えば、未起動とするなど、不当なアプリケーションとして処理する。
【０３０６】
ところで、アプリケーションが付随するコンテンツは、デジタル著作権管理（DRM）によって、不正な利用から保護するという運用が想定される。特に、ATSC3.0では、番組等のコンテンツ（のストリーム）の保護が要件となっており、何らかのDRMが導入される可能性が高い。第２の実施の形態では、このコンテンツを保護するためのDRMを利用して、送信側システム７からクライアント装置６０に、アプリダイジェストを通知することで、正当なアプリケーションであるかどうかを検証できるようにしている。
【０３０７】
また、DRMを利用することにより、保護対象となるコンテンツ（のストリーム）と、それに付随するアプリケーションとのバインディング（関連付け）をも検証することができる。
【０３０８】
ここで、DRMとしては、例えば、PlayReady（登録商標），Marlin，Widevine，Verimatrix等の方式を適用することができるが、いずれの方式にも共通に適用可能なアプリケーションバインディング保護のための各種のフォーマットを仕様化しておくようにする。これにより、クライアント装置６０では、DRMとして、いずれの方式が適用された場合でも、各方式の違いによらずに、正当なアプリケーションとのバインディングであるかどうかを検証することができる。
【０３０９】
（アプリダイジェストのシンタックスの例）
図２２は、アプリダイジェスト（app_digest_message）のシンタックスの例を示す図である。
【０３１０】
8ビットのuri_strlenは、対象のアプリケーションを識別するURL（アプリURL）の長さを表している。8×uri_strlenビットのuri_string()は、対象のアプリケーションを識別するURL（アプリURL）を表している。
【０３１１】
8ビットのdigest_typeは、暗号学的ハッシュ関数のアルゴリズムの種別を示す。例えば、図２３に示すように、digest_typeとして"0x01"が指定された場合、アルゴリズムは、MD5(Message Digest Algorithm 5)であることを表している。また、例えば、digest_typeとして、"0x02"が指定された場合には、SHA-1，"0x03"が指定された場合には、SHA-256が、アルゴリズムとして指定されることになる。なお、SHAは、Secure Hash Algorithmの略である。また、0x00，0x04〜0xFFは、将来の拡張のために予約された値（reserved）とされる。
【０３１２】
図２２の説明に戻り、8ビットのdigest_lenは、対象のアプリケーションのダイジェスト値のバイト長を表している。8×digest_lenビットのdigest_valueは、対象のアプリケーションのダイジェスト値を表している。
【０３１３】
そして、第２の実施の形態では、図２２のアプリダイジェスト（app_digest_message）が、上述したウォータマーク格納方式、又は非VCL-NALユニット格納方式に応じて格納されることになる。
【０３１４】
すなわち、ウォータマーク格納方式では、アプリダイジェストを、ウォータマークとして、ビデオ符号化データに挿入してから、VCL-NALユニットとして、ISOBMFFのfragmented mp4のmdat内のサンプルとして伝送されるようにしている。また、非VCL-NALユニット格納方式では、アプリダイジェストを、非VCL-NALユニットに直接格納して、ISOBMFFのfragmented mp4のmdat内のサンプルとして伝送されるようにしている。
【０３１５】
なお、図２４には、ISOBMFFに対応したセグメントのデータ形式の例を示しているが、ウォータマーク格納方式、又は非VCL-NALユニット格納方式を採用した場合には、メディアセグメント（Media Segment）において、サブセグメント（Sub Segment）のMovie fragmentを構成するmoofとmdatのうち、mdat内に、アプリダイジェストが格納されることになる。
【０３１６】
（３）アプリダイジェストの伝送方式
【０３１７】
次に、ウォータマーク格納方式と、非VCL-NALユニット格納方式の詳細な内容について説明する。
【０３１８】
（Ａ）ウォータマーク格納方式
【０３１９】
（ウォータマーク格納方式の概要）
図２５は、ウォータマーク格納方式の概要を説明する図である。
【０３２０】
図２５においては、送信側システム７の放送サーバ４０から、伝送路８０を介してクライアント装置６０に伝送される放送ストリームを模式的に表している。この放送ストリームには、DRMにより暗号化されている部分（暗号化パイプ（Encrypted Pipe））と、暗号化されていない部分（非暗号化パイプ（Clear Pipe））がある。
【０３２１】
ウォータマーク格納方式では、暗号化パイプで、アプリケーション（App）を検証するためのアプリダイジェスト（App Digest）を、ウォータマーク（Watermark）に格納することで、当該アプリダイジェストが保護されるようにする。ただし、このアプリダイジェストには、図２２に示したように、アプリケーションの識別情報（例えばアプリURL）と、アプリケーションのダイジェスト値が含まれている。
【０３２２】
クライアント装置６０では、番組等のコンテンツの再生中にDRMを解くことで、ウォータマークに格納されたアプリケーションのアプリURLとダイジェスト値を抽出し、ダイジェスト値を用いて、アプリURLにより特定されるアプリケーションが、正当なアプリケーションであるかどうかの検証を行う。ここでは、ウォータマークに格納されたダイジェスト値と、アプリURLに従って取得されるアプリケーションに応じたダイジェスト値とを比較することで検証を行い、これらのダイジェスト値が一致する場合には、アプリURLにより特定されるアプリケーションは、正当なアプリケーションであると判定する。
【０３２３】
例えば、IP伝送方式を採用するATSC3.0において、番組等のコンテンツのビデオとオーディオのストリームは、DRMによるセキュアな暗号化パイプで伝送されて保護されるが、IP/UDP上のROUTEセッションで伝送される（コンテンツの）DASHセグメントのファイル（DASHセグメント MP4フラグメントファイル）を構成するメディアセグメントのMovie fragmentのmdatに格納されるVCL-NALユニットには、アプリダイジェストを含むウォータマークが格納されている。そして、このウォータマークの構造として、アプリケーションのアプリURLとダイジェスト値を含むアプリダイジェストのフィールドが定義されているのである。
【０３２４】
このように、ウォータマーク格納方式を採用することで、番組等のコンテンツの保護のためのDRMによるセキュアな暗号化パイプを、アプリダイジェストの伝送に流用することで、エンドツーエンドのセキュリティが保証され、例えば、アプリケーションのすげ替えや改ざん、コンテンツとアプリケーションとの関連付けの改ざんなど、悪意のある第三者による不正（攻撃）を回避することができる。
【０３２５】
また、ウォータマーク格納方式によれば、PKI等を利用した本格的なアプリケーション認証のためのプラットフォーム（インフラストラクチャ）を構築することなく、既存のDRMを流用してアプリケーション認証を行うことが可能となるため、コストの軽減を担保することができる。
【０３２６】
（ウォータマークペイロードの構造）
図２６は、ビデオウォータマーク（ウォータマーク）を利用したアプリダイジェストの格納方法を示す図である。
【０３２７】
図２６に示すように、１ビデオフレームにおいては、映像表示領域の上側の所定のライン（例えば２ライン）をビデオウォータマークとして利用することができる。このビデオウォータマークで利用されるラインでは、例えば、１ブロックごとに、１ビットや２ビットの情報量を伝送することができる。そして、ビデオウォータマークでは、ビデオ符号化データの所定のライン（例えば２ライン）を用い、ウォータマークペイロード(Watermark payload)を伝送することができる。
【０３２８】
このウォータマークペイロードには、WMメッセージ（wm_message()）として、図２２に示したアプリダイジェストメッセージ（app_digest_message()）を配置することができる。このアプリダイジェストメッセージには、アプリURLを格納したuri_string()と、ダイジェスト値を格納したdigest_valueが含まれる。以下、図２７乃至図２９を参照して、ウォータマークペイロードのシンタックスについて説明する。
【０３２９】
（ウォータマークペイロードのシンタックス）
図２７は、ウォータマークペイロード（Watermark payload）のシンタックスの例を示す図である。
【０３３０】
16ビットのrun_in_patternには、ビデオウォータマークの伝送パターンと、白から黒までの範囲で表される１領域の分解能が指定される。この伝送パターンとしては、例えば、１ライン又は２ラインが指定される。また、１領域の分解能としては、例えば、8ビット〜12ビットが指定される。
【０３３１】
wm_message_block()は、ウォータマークのメッセージ領域を表している。8ビットのzero_padは、ゼロパディングを表している。
【０３３２】
（WMメッセージブロックのシンタックス）
図２８は、図２７のWMメッセージブロック（wm_message_block()）のシンタックスの例を示す図である。
【０３３３】
8ビットのwm_message_idには、WMメッセージIDが指定される。8ビットのwm_message_block_lengthには、WMメッセージブロック長が指定される。
【０３３４】
4ビットのwm_message_versionには、WMメッセージのバージョンが指定される。2ビットのfragment_numberと、2ビットのlast_fragmentには、フラグメントに関する情報が指定される。
【０３３５】
ここで、wm_message()には、WMメッセージIDに指定される値に応じたWMメッセージが指定される。例えば、図２９に示すように、WMメッセージIDとして、"0x08"が指定された場合、WMメッセージとして、アプリダイジェストメッセージ（app_digest_message()）が配置される。なお、WMメッセージには、message_CRC_32やCRC_32などの誤り検出符号が含まれる。
【０３３６】
次に、図３０及び図３１のフローチャートを参照して、ウォータマーク格納方式を採用した場合における伝送システム２（図１６）の各装置で実行される処理の流れを説明する。
【０３３７】
（送信側の処理の流れ）
まず、図３０のフローチャートを参照して、ウォータマーク格納方式を採用した場合の送信側の処理の流れを説明する。なお、この送信側の処理では、アプリダイジェストがビデオウォータマークに格納される場合を説明するため、ビデオのデータに対する処理を中心に説明し、オーディオのデータに対する処理の説明については適宜省略する。
【０３３８】
図３０のステップＳ３５１乃至Ｓ３５５の処理は、アプリケーションサーバ３０により実行される。ステップＳ３５１において、アプリURL生成部３１１は、アプリURLを生成する。ステップＳ３５２において、アプリケーション生成部３１２は、ステップＳ３５１の処理で生成されたアプリURLにより識別されるアプリケーションを生成する。
【０３３９】
ステップＳ３５３において、送信部３０３は、ステップＳ３５１の処理で生成されたアプリURLを、シグナリングサーバ２０に送信し、ステップＳ３５２の処理で生成されたアプリケーションを、放送サーバ４０に送信する。
【０３４０】
ステップＳ３５４において、アプリダイジェスト生成部３１４は、アプリダイジェストを生成する。このアプリダイジェストには、例えば、ステップＳ３５１の処理で生成されたアプリURLと、ステップＳ３５２の処理で生成されたアプリケーションに対して、所定のアルゴリズム（例えば、MD5など）を適用することで生成されたダイジェスト値（ハッシュ値）が含まれる。
【０３４１】
ステップＳ３５５において、送信部３０３は、ステップＳ３５４の処理で生成されたアプリダイジェストを、ストリームサーバ７０に送信する。
【０３４２】
図３０のステップＳ７０１乃至Ｓ７０４の処理は、ストリームサーバ７０により実行される。また、ストリームサーバ７０においては、ステップＳ３５５の処理で送信されたアプリダイジェストが受信される。
【０３４３】
ステップＳ７０１において、ストリーム生成部７１１は、受信部７０１に蓄積された番組等のコンテンツ（のデータ）を処理することで、ストリーム（ベースバンドフレームシーケンス）を生成する。
【０３４４】
ステップＳ７０２において、ウォータマークインサータ７１２は、ステップＳ７０１の処理で生成されたストリームのベースバンドフレームに挿入されるウォータマーク（ウォータマークペイロード）に、アプリケーションサーバ３０により生成されたアプリダイジェストを格納する。
【０３４５】
ステップＳ７０３において、エンコーダ７１３は、所定の符号化方式（例えばHEVC等）に従い、ステップＳ７０２で処理されたベースバンドフレームをエンコードし、VCL-NALユニットを生成する。ステップＳ７０４において、送信部７０３は、ステップＳ７０３の処理で生成されたVCL-NALユニットを、DASHサーバ１０に送信する。
【０３４６】
図３０のステップＳ１５１乃至Ｓ１５６の処理は、DASHサーバ１０により実行される。また、DASHサーバ１０においては、ステップＳ７０４の処理で送信されたVCL-NALユニットが受信される。
【０３４７】
ステップＳ１５１において、MPD生成部１１１は、MPDメタデータを生成する。また、ステップＳ１５２において、送信部１０３は、ステップＳ１５１の処理で生成されたMPDメタデータを、シグナリングサーバ２０に送信する。
【０３４８】
ステップＳ１５３において、暗号化部１１３は、所定の暗号化方式に従い、ストリームサーバ７０により生成されたVCL-NALユニットを暗号化する。ステップＳ１５４において、DRM保護ファイル生成部１１４は、ステップＳ１５３の処理で暗号化されたVCL-NALユニットを処理して、DRM保護ファイルを生成する。
【０３４９】
ステップＳ１５５において、DASHセグメント生成部１１２は、ステップＳ１５４の処理で生成されたDRM保護ファイルを処理して、DASHセグメントを生成する。ステップＳ１５６において、送信部１０３は、ステップＳ１５５の処理で生成されたDASHセグメントを、放送サーバ４０に送信する。
【０３５０】
図３０のステップＳ２５１乃至Ｓ２５２の処理は、シグナリングサーバ２０により実行される。また、シグナリングサーバ２０においては、ステップＳ１５２の処理で送信されたMPDメタデータと、ステップＳ３５３の処理で送信されたアプリURLが受信される。
【０３５１】
ステップＳ２５１において、シグナリング生成部２１１は、シグナリングを生成する。ここで、シグナリングとしては、SLTメタデータを含むLLSシグナリングと、USDメタデータ、S-TSIDメタデータ、及びMPDメタデータを含むSLSシグナリングが生成される。また、SLTメタデータ、又はSLSシグナリング（例えば、USD，S-TSID，MPD等のメタデータ）には、アプリケーションサーバ３０により生成されたアプリURLが記述される。
【０３５２】
ステップＳ２５２において、送信部２０３は、ステップＳ２５１の処理で生成されたシグナリングを、放送サーバ４０に送信する。
【０３５３】
図３０のステップＳ４５１乃至Ｓ４５３の処理は、放送サーバ４０により実行される。また、放送サーバ４０においては、ステップＳ１５６の処理で送信されたDASHセグメント、ステップＳ２５２の処理で送信されたシグナリング、及び、ステップＳ３５３の処理で送信されたアプリケーションが受信される。
【０３５４】
送信部４０３は、アプリケーションサーバ３０により生成されたアプリケーション、シグナリングサーバ２０により生成されたシグナリング、及び、DASHサーバ１０により生成されたDASHセグメントを、伝送路８０を介して送信（一斉同報配信）する（Ｓ４５１乃至Ｓ４５３）。
【０３５５】
以上、送信側の処理の流れについて説明した。
【０３５６】
（受信側の処理の流れ）
次に、図３１のフローチャートを参照して、ウォータマーク格納方式を採用した場合の受信側の処理の流れを説明する。なお、この受信側の処理では、アプリダイジェストがビデオウォータマークに格納されている場合を説明するため、ビデオのデータに対する処理を中心に説明し、オーディオのデータに対する処理の説明については適宜省略する。
【０３５７】
図３１においては、放送ミドルウェア６０４とDASHクライアント６０５により実行される処理のほか、デコーダ６０６やレンダリングエンジン６１２、ウォータマークイクストラクタ６１３等により実行されるビデオ・オーディオ対応処理と、アプリケーション制御部６１１やレンダリングエンジン６１２、アプリダイジェストバリデータ６１４等により実行されるアプリケーション対応処理の流れが示されている。
【０３５８】
ただし、図９等と同様に、ビデオ・オーディオ対応処理は、コンテンツのビデオやオーディオのデータに関する処理を表し、アプリケーション対応処理は、アプリケーションのデータに関する処理を表している。
【０３５９】
ステップＳ８０１において、放送ミドルウェア６０４は、受信部６０３を介して、放送サーバ４０から送信されてくるシグナリングを受信する。ステップＳ８０２において、放送ミドルウェア６０４は、ステップＳ８０１の処理で受信されたシグナリングを処理する。
【０３６０】
ここで、シグナリングとしては、SLTメタデータを含むLLSシグナリングと、USDメタデータ、S-TSIDメタデータ、及びMPDメタデータを含むSLSシグナリングが処理される。また、SLTメタデータ、又はSLSシグナリング（例えば、USD，S-TSID，MPD等のメタデータ）には、アプリケーションサーバ３０により生成されたアプリURLが記述される。
【０３６１】
ステップＳ８０３において、放送ミドルウェア６０４は、ステップＳ８０２の処理で取得されたMPDメタデータを、DASHクライアント６０５に通知するとともに、ステップＳ８０２の処理で取得されたアプリURLを、アプリケーション制御部６１１に通知する。
【０３６２】
ステップＳ８０４において、放送ミドルウェア６０４は、アプリケーション制御部６１１からの制御に従い、シグナリングに記述されたアプリURLに基づいて、受信部６０３を介して、放送サーバ４０から送信されてくるアプリケーションを受信する。ステップＳ８０５において、放送ミドルウェア６０４は、ステップＳ８０４の処理で受信されたアプリケーションを、アプリケーション制御部６１１に転送する。
【０３６３】
ステップＳ８３１において、アプリケーション制御部６１１は、ステップＳ８０５の処理で転送されたアプリケーションを取得する。また、ステップＳ８３２において、アプリダイジェストバリデータ６１４は、ステップＳ８３１の処理で取得されたアプリケーションに応じたアプリダイジェストを生成する。
【０３６４】
このステップＳ８３２の処理では、ステップＳ８３１の処理で取得されたアプリケーションに対して、送信側システム７のステップＳ３５４（図３０）の処理と同一のアルゴリズム（例えば、MD5など）を適用することで、ダイジェスト値（ハッシュ値）が生成される。
【０３６５】
ステップＳ８０６において、放送ミドルウェア６０４は、受信部６０３を介して、放送サーバ４０から送信されてくるDASHセグメントを受信する。ステップＳ８０７において、放送ミドルウェア６０４は、ステップＳ８０６の処理で受信されたDASHセグメントを、DASHクライアント６０５に転送する。
【０３６６】
ステップＳ８１２において、DASHクライアント６０５は、ステップＳ８１１のMPDメタデータの処理結果に基づいて、ステップＳ８０７の処理で転送されたDASHセグメントを処理する。ステップＳ８１３において、DASHクライアント６０５（のDRM保護ファイル処理部）は、ステップＳ８１２の処理で得られるDRM保護ファイルを処理して、当該DRM保護ファイルのアンパッケージングを行う。
【０３６７】
ステップＳ８１４において、DASHクライアント６０５（の復号部）は、所定の復号方式に従い、ステップＳ８１４の処理で得られる暗号化されたVCL-NALユニットを復号する。ステップＳ８１５において、DASHクライアント６０５は、ステップＳ８１４の処理で復号されたVCL-NALユニットを、デコーダ６０６に転送する。
【０３６８】
ステップＳ８２１において、デコーダ６０６は、所定の復号方式（例えばHEVC等）に従い、ステップＳ８１５の処理で転送されたVCL-NALユニットをデコードする。ステップＳ８２２において、ウォータマークイクストラクタ６１３は、ステップＳ８２１の処理で得られるベースバンドフレームに挿入されたウォータマーク（ビデオウォータマーク）を抽出する。
【０３６９】
ステップＳ８２３において、アプリダイジェストバリデータ６１４は、ステップＳ８２２の処理で抽出されたウォータマーク（ウォータマークペイロード）に格納されたアプリダイジェストを抽出する。なお、上述した場合と同様に、クライアント装置６０では、レンダリングエンジン６１２によって、ステップＳ８２１の処理で得られるビデオとオーディオのデータのレンダリングが行われることで、番組等のコンテンツの映像と音声が出力される（Ｓ８２４）。
【０３７０】
ステップＳ８３３において、アプリダイジェストバリデータ６１４は、ステップＳ８３２の処理で生成されたアプリダイジェストと、ステップＳ８２３の処理で抽出されたアプリダイジェストとを比較することで、アプリダイジェストを検証する。ステップＳ８３４において、アプリダイジェストバリデータ６１４は、ステップＳ８３３の検証結果に基づいて、比較対象のアプリダイジェストが一致するかどうかを判定する。
【０３７１】
ここで、ステップＳ８２３の処理で抽出されたアプリダイジェスト（ダイジェスト値）は、送信側システム７の（アプリケーションサーバ３０による）ステップＳ３５４（図３０）の処理で生成されたものであって、ステップＳ８３２の処理で生成されたアプリダイジェスト（ダイジェスト値）と同一のアルゴリズム（例えば、MD5など）を適用して生成されたものとなる。したがって、ステップＳ８３４の判定処理の比較対象のアプリダイジェスト（ダイジェスト値）が一致すれば、対象のアプリケーションは、正当なアプリケーションであるとみなすことができる。
【０３７２】
ステップＳ８３４において、比較対象のアプリダイジェストが一致すると判定された場合、処理は、ステップＳ８３５に進められる。ステップＳ８３５において、アプリケーション制御部６１１は、ステップＳ８３１の処理で取得されたアプリケーションを（即時に）起動する。すなわち、この場合、クライアント装置６０では、受信されたアプリケーションが、正当なアプリケーションであるとみなして、その起動を許可している。
【０３７３】
ステップＳ８３６において、レンダリングエンジン６１２は、ステップＳ８３５の処理で起動されたアプリケーションのデータのレンダリングを行う。これにより、例えば、クライアント装置６０においては、番組等のコンテンツに付随したアプリケーションの映像が表示される。
【０３７４】
一方で、ステップＳ８３４において、比較対象のアプリダイジェストが一致しないと判定された場合、ステップＳ８３５乃至Ｓ８３６の処理はスキップされる。すなわち、この場合、クライアント装置６０では、受信されたアプリケーションが、不当なアプリケーションであるとみなして、その起動を拒否している。なお、このような不当なアプリケーションが検出された場合には、例えば、ユーザや関連する放送局に通知するなど、他の動作が行われるようにしてもよい。
【０３７５】
以上、受信側の処理の流れについて説明した。
【０３７６】
（Ｂ）非VCL-NALユニット格納方式
【０３７７】
（非VCL-NALユニット格納方式の概要）
図３２は、非VCL-NALユニット格納方式の概要を説明する図である。
【０３７８】
図３２においては、図２５と同様に、放送サーバ４０から、伝送路８０を介してクライアント装置６０に伝送される放送ストリームを模式的に表している。この放送ストリームには、DRMにより暗号化されている部分（暗号化パイプ（Encrypted Pipe））と、暗号化されていない部分（非暗号化パイプ（Clear Pipe））がある。
【０３７９】
非VCL-NALユニット格納方式では、暗号化パイプで、アプリケーション（App）を検証するためのアプリダイジェスト（App Digest）を、NALユニットに格納されるVideo-SEIに格納することで、当該アプリダイジェストが保護されるようにする。
【０３８０】
ここで、NAL(Network Abstraction Layer)ユニットは、様々なデータを含んでおり、大きく分けると、VCL(Video Coding Layer：ビデオ符号化階層)と、非VCL(Non Video Coding Layer)とに分類することができる。VCL-NALユニットは、圧縮されたビデオのスライスデータ（符号化データ）である。
【０３８１】
一方で、非VCL-NALユニットは、その他の補助的な情報を格納するためのものである。例えば、非VCL-NALユニットには、VPS(Video Parameter Set)，SPS(Sequence Parameter Set)，PPS(Picture Parameter Set)，SEI(Supplemental Enhancement Information)などがある。特に、SEIメッセージは、VCLの復号に必須ではない付加情報を格納するためのものであって、ユーザが独自に定義する情報（User data unregistered）を含めることができるので、そこに、アプリダイジェストを格納することができる。
【０３８２】
ただし、非VCL-NALユニット格納方式では、VCL-NALユニットのみならず、アプリダイジェストを含むSEIメッセージが格納されるNALユニット（非VCL-NALユニット）も合わせてDRMの暗号化の対象とする必要がある。また、このアプリダイジェストには、図２２に示したように、アプリケーションの識別情報（例えばアプリURL）と、アプリケーションのダイジェスト値が含まれている。
【０３８３】
クライアント装置６０では、番組等のコンテンツの再生中にDRMを解くことで、非VCL-NALユニット（SEIメッセージ）に格納されたアプリケーションのアプリURLとダイジェスト値を抽出し、ダイジェスト値を用いて、アプリURLにより特定されるアプリケーションが、正当なアプリケーションであるかどうかの検証を行う。ここでは、非VCL-NALユニット（SEIメッセージ）に格納されたダイジェスト値と、アプリURLに従って取得されるアプリケーションに応じたダイジェスト値とを比較することで検証を行い、これらのダイジェスト値が一致する場合には、アプリURLにより特定されるアプリケーションは、正当なアプリケーションであると判定する。
【０３８４】
このように、非VCL-NALユニット格納方式を採用することで、番組等のコンテンツの保護のためのDRMによるセキュアな暗号化パイプを、アプリダイジェストの伝送に流用することで、エンドツーエンドのセキュリティが保証され、アプリケーションのすげ替えや改ざん、コンテンツとアプリケーションとの関連付けの改ざんなど、悪意のある第三者による不正（攻撃）を回避することができる。
【０３８５】
また、非VCL-NALユニット格納方式によれば、PKI等を利用した本格的なアプリケーション認証のためのプラットフォーム（インフラストラクチャ）を構築することなく、既存のDRMを流用してアプリケーション認証を行うことが可能となるため、コストの軽減を担保することができる。
【０３８６】
さらに、クライアント装置６０においては、ウォータマーク格納方式を採用した場合、ウォータマークに格納されたアプリダイジェストを抽出するために、常時、ウォータマークイクストラクタ６１３（図２０）を起動しておく必要がある一方で、非VCL-NALユニット格納方式を採用した場合には、ウォータマークイクストラクタ６１３を起動することなく（設けることなく）、アプリダイジェストを抽出することができる。
【０３８７】
次に、図３３及び図３４のフローチャートを参照して、非VCL-NALユニット格納方式を採用した場合における伝送システム２（図１６）の各装置で実行される処理の流れを説明する。
【０３８８】
（送信側の処理の流れ）
まず、図３３のフローチャートを参照して、非VCL-NALユニット格納方式を採用した場合の送信側の処理の流れを説明する。なお、この送信側の処理では、アプリダイジェストが非VCL-NALユニットに格納される場合を説明するため、ビデオのデータに対する処理を中心に説明し、オーディオのデータに対する処理の説明については適宜省略する。
【０３８９】
図３３のステップＳ３６１乃至Ｓ３６５の処理は、アプリケーションサーバ３０により実行される。ステップＳ３６１乃至Ｓ３６５においては、図３０のステップＳ３５１乃至Ｓ３５５と同様に、アプリURL、アプリケーション、及び、アプリダイジェストが生成され、対象のサーバに送信される。
【０３９０】
ただし、非VCL-NALユニット格納方式を採用した場合、アプリダイジェストは、ストリームサーバ７０ではなく、DASHサーバ１０に送信される。また、アプリダイジェストには、例えば、ステップＳ３６１の処理で生成されたアプリURLと、ステップＳ３６２の処理で生成されたアプリケーションに対して、所定のアルゴリズム（例えば、MD5など）を適用することで生成されたダイジェスト値（ハッシュ値）が含まれる。
【０３９１】
図３３のステップＳ７１１乃至Ｓ７１３の処理は、ストリームサーバ７０により実行される。ステップＳ７１１においては、図３０のステップＳ７０１と同様に、ストリーム（ベースバンドフレームシーケンス）が生成される。
【０３９２】
ステップＳ７１２において、エンコーダ７１３は、所定の符号化方式（例えばHEVC等）に従い、ステップＳ７１１の処理で生成されたベースバンドフレームをエンコードし、VCL-NALユニットを生成する。ステップＳ７１３において、送信部７０３は、ステップＳ７１２の処理で生成されたVCL-NALユニットを、DASHサーバ１０に送信する。
【０３９３】
図３３のステップＳ１６１乃至Ｓ１６７の処理は、DASHサーバ１０により実行される。また、DASHサーバ１０においては、ステップＳ７１３の処理で送信されたVCL-NALユニットのほかに、ステップＳ３６５の処理で送信されたアプリダイジェストが受信される。
【０３９４】
図３３のステップＳ１６１乃至Ｓ１６２においては、図３０のステップＳ１５１乃至Ｓ１５２と同様に、MPDメタデータが生成され、シグナリングサーバ２０に送信される。
【０３９５】
ステップＳ１６３において、非VCL-NALユニット生成部１１５は、アプリケーションサーバ３０により生成されたアプリダイジェストを格納した非VCL-NALユニットを生成する。ここでは、非VCL-NALユニットとして、ユーザが独自に定義することができるSEIメッセージを用いることができる。
【０３９６】
ステップＳ１６４において、暗号化部１１３は、所定の暗号化方式に従い、ストリームサーバ７０により生成されたVCL-NALユニットと、ステップＳ１６３の処理で生成された非VCL-NALユニットを暗号化する。ステップＳ１６５において、DRM保護ファイル生成部１１４は、ステップＳ１６４の処理で暗号化されたVCL-NALユニットと非VCL-NALユニットを処理して、DRM保護ファイルを生成する。
【０３９７】
ステップＳ１６６において、DASHセグメント生成部１１２は、ステップＳ１６５の処理で生成されたDRM保護ファイルを処理して、DASHセグメントを生成する。ステップＳ１６７において、送信部１０３は、ステップＳ１６６の処理で生成されたDASHセグメントを、放送サーバ４０に送信する。
【０３９８】
図３３のステップＳ２６１乃至Ｓ２６２の処理は、シグナリングサーバ２０により実行される。ステップＳ２６１乃至Ｓ２６２においては、図３０のステップＳ２５１乃至Ｓ２５２と同様に、シグナリングが生成され、放送サーバ４０に送信される。
【０３９９】
図３３のステップＳ４６１乃至Ｓ４６３の処理は、放送サーバ４０により実行される。ステップＳ４６１乃至Ｓ４６３においては、図３０のステップＳ４５１乃至Ｓ４５３と同様に、送信部４０３によって、アプリケーション、シグナリング、及び、DASHセグメントが、伝送路８０を介して送信（一斉同報配信）される。
【０４００】
以上、送信側の処理の流れについて説明した。
【０４０１】
（受信側の処理の流れ）
次に、図３４のフローチャートを参照して、非VCL-NALユニット格納方式を採用した場合の受信側の処理の流れを説明する。なお、この受信側の処理では、アプリダイジェストが非VCL-NALユニットに格納されている場合を説明するため、ビデオのデータに対する処理を中心に説明し、オーディオのデータに対する処理の説明については適宜省略する。
【０４０２】
ステップＳ８４１乃至Ｓ８４７においては、図３１のステップＳ８０１乃至Ｓ８０７と同様に、放送ミドルウェア６０４によって、放送サーバ４０から送信されてくるシグナリング、アプリケーション、及びDASHセグメントが受信され、処理される。
【０４０３】
また、ステップＳ８５１においては、図３１のステップＳ８１１と同様に、DASHクライアント６０５によって、MPDメタデータが処理される。さらに、ステップＳ８７１乃至Ｓ８７２においては、図３１のステップＳ８３１乃至Ｓ８３２と同様に、アプリケーション制御部６１１によって、アプリURLに対応したアプリケーションが取得されるとともに、アプリダイジェストバリデータ６１４によって、当該アプリケーションに応じたアプリダイジェストが生成される。
【０４０４】
このステップＳ８３２の処理では、ステップＳ８７１の処理で取得されたアプリケーションに対して、送信側システム７のステップＳ３６４（図３３）の処理と同一のアルゴリズム（例えば、MD5など）を適用することで、ダイジェスト値（ハッシュ値）が生成される。
【０４０５】
ステップＳ８５２において、DASHクライアント６０５は、ステップＳ８５１のMPDメタデータの処理結果に基づいて、ステップＳ８４７の処理で転送されたDASHセグメントを処理する。ステップＳ８５３において、DASHクライアント６０５（のDRM保護ファイル処理部）は、ステップＳ８５２の処理で得られるDRM保護ファイルを処理して、当該DRM保護ファイルのアンパッケージングを行う。
【０４０６】
ステップＳ８５４において、DASHクライアント６０５（の復号部）は、所定の復号方式に従い、ステップＳ８５３の処理で得られる暗号化されたVCL-NALユニットを復号する。ステップＳ８５５において、DASHクライアント６０５は、ステップＳ８５４の処理で復号されたVCL-NALユニットを、デコーダ６０６に転送する。
【０４０７】
ステップＳ８６１において、デコーダ６０６は、所定の復号方式（例えばHEVC等）に従い、ステップＳ８５５の処理で転送されたVCL-NALユニットをデコードする。また、ステップＳ８６２において、レンダリングエンジン６１２は、ステップＳ８６１の処理で得られるビデオとオーディオのデータのレンダリングを行う。これにより、クライアント装置６０では、番組等のコンテンツの映像と音声が出力されることになる。
【０４０８】
また、ステップＳ８５６において、DASHクライアント６０５（の復号部）は、所定の復号方式に従い、ステップＳ８５３の処理で得られる暗号化された非VCL-NALユニットを復号する。ステップＳ８５７において、アプリダイジェストバリデータ６１４は、ステップＳ８５６の処理で復号された非VCL-NALユニットに格納されたアプリダイジェストを抽出する。
【０４０９】
ステップＳ８７３において、アプリダイジェストバリデータ６１４は、ステップＳ８７２の処理で生成されたアプリダイジェストと、ステップＳ８５７の処理で抽出されたアプリダイジェストとを比較することで、アプリダイジェストを検証する。ステップＳ８７４において、アプリダイジェストバリデータ６１４は、ステップＳ８７３の検証結果に基づいて、比較対象のアプリダイジェストが一致するかどうかを判定する。
【０４１０】
ここで、ステップＳ８５７の処理で抽出されたアプリダイジェスト（ダイジェスト値）は、送信側システム７の（アプリケーションサーバ３０による）ステップＳ３６４（図３３）の処理で生成されたものであって、ステップＳ８７２の処理で生成されたアプリダイジェスト（ダイジェスト値）と同一のアルゴリズム（例えば、MD5など）を適用して生成されたものとなる。したがって、ステップＳ８７４の判定処理の比較対象のアプリダイジェスト（ダイジェスト値）が一致すれば、対象のアプリケーションは、正当なアプリケーションであるとみなすことができる。
【０４１１】
ステップＳ８７４において、比較対象のアプリダイジェストが一致すると判定された場合、処理は、ステップＳ８７５に進められる。ステップＳ８７５乃至Ｓ８７６においては、図３１のステップＳ８３５乃至Ｓ８３６と同様に、受信されたアプリケーションが正当なアプリケーションであるとみなされ、当該アプリケーションが（即時に）起動され、その映像が表示されることになる。
【０４１２】
一方で、ステップＳ８７４において、比較対象のアプリダイジェストが一致しないと判定された場合、受信されたアプリケーションが、不当なアプリケーションであるとみなして、当該アプリケーションは未起動とされる。
【０４１３】
以上、受信側の処理の流れについて説明した。
【０４１４】
＜３．シグナリングの例＞
【０４１５】
次に、図３５乃至図４２を参照して、アプリケーションの取得先を示す取得先情報（例えばURL）を伝送するシグナリングのフォーマットの例を説明する。
【０４１６】
（SLTのフォーマット）
図３５は、XML形式のSLTメタデータのフォーマットの例を示す図である。なお、図３５において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。これらの関係は、後述する他のシグナリングのフォーマットでも同様とされる。
【０４１７】
SLT要素は、ルート要素であって、bsid属性、sltCapabilities属性、sltInetUrl要素、及び、Service要素の上位要素となる。
【０４１８】
bsid属性には、ブロードキャストストリームIDが指定される。sltCapabilities属性には、必要とされる機能に関する情報が指定される。
【０４１９】
sltInetUrl要素には、ESG(Electronic Service Guide)やSLSシグナリングを取得するためのベースURLが指定される。sltInetUrl要素は、urlType属性の上位要素となる。urlType属性には、ベースURLで利用可能なファイルの種類が指定される。
【０４２０】
Service要素には、１又は複数のサービスに関する情報が指定される。Service要素は、serviceId属性、sltSvcSeqNum属性、protected属性、majorChannelNo属性、minorChannelNo属性、serviceCategory属性、shortServiceName属性、hidden属性、broadbandAccessRequired属性、svcCapabilities属性、applicationUrl属性、BroadcastSvcSignaling要素、及び、svcInetUrl要素の上位要素となる。
【０４２１】
serviceId属性には、サービスIDが指定される。sltSvcSeqNum属性には、SLTメタデータのバージョンに関する情報が指定される。protected属性には、サービスの保護を示す暗号化情報が指定される。
【０４２２】
majorChannelNo属性には、メジャーチャンネル番号が指定される。minorChannelNo属性には、マイナーチャンネル番号が指定される。serviceCategory属性には、サービスのカテゴリが指定される。shortServiceName属性には、ショートサービス名が指定される。
【０４２３】
hidden属性には、サービスが、隠されたサービスであるかどうかが指定される。broadbandAccessRequired属性には、インターネット９０等の通信回線にアクセスする必要があるかどうかが指定される。svcCapabilities属性には、デコードに必要な機能などの情報が指定される。
【０４２４】
applicationUrl属性には、アプリケーションの取得先を示すURL（アプリURL）が指定される。このアプリURLは、例えば、アプリケーションが、HTML文書ファイルや画像ファイルなど、複数のファイルから構成されている場合に、そのエントリ（例えば、index.html）を識別するための情報とされる。また、このSLTメタデータを受信したクライアント装置６０においては、アプリURLに応じてアプリケーションが取得され、即時に起動されることになる。
【０４２５】
BroadcastSvcSignaling要素には、SLSシグナリングが放送経由で取得される場合に、当該SLSシグナリングの取得先に関する情報が指定される。BroadcastSvcSignaling要素は、slsProtocol属性、slsMajorProtocolVersion属性、slsMinorProtocolVersion属性、slsPlpId属性、slsDestinationIpAddress属性、slsDestinationUdpPort属性、及び、slsSourceIpAddress属性の上位要素となる。
【０４２６】
slsProtocol属性には、SLSシグナリングのプロトコルに関する情報が指定される。slsMajorProtocolVersion属性には、SLSシグナリングのプロトコルのメジャーバージョン番号が指定される。slsMinorProtocolVersion属性には、SLSシグナリングのプロトコルのマイナーバージョン番号が指定される。
【０４２７】
slsPlpId属性には、SLSシグナリングが伝送されるPLP(Physical Layer Pipe)のIDが指定される。slsDestinationIpAddress属性には、SLSシグナリングの宛先（destination）のIPアドレスが指定される。slsDestinationUdpPort属性には、SLSシグナリングの宛先（destination）のポート番号が指定される。slsSourceIpAddress属性には、SLSシグナリングの送信元（source）のIPアドレスが指定される。
【０４２８】
svcInetUrl要素には、SLSシグナリングが通信経由で取得される場合に、当該SLSシグナリングの取得先のURLが指定される。svcInetUrl要素は、urlType属性の上位要素となる。urlType属性には、このURLで利用可能なファイルの種類が指定される。
【０４２９】
なお、図３５において、出現数（Use）であるが、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定され、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。また、"1..N"が指定された場合には、その要素又は属性は１以上指定され、"0..N"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。
【０４３０】
また、Data Typeとして、"unsignedShort"又は"unsignedByte"が指定された場合、その要素又は属性の値が、整数型であることを示している。Data Typeとして、"string"が指定された場合には、その要素又は属性の値が、文字列型であることを示し、"anyURI"が指定された場合、その要素又は属性の値が、URIの形式をした文字列であることを示している。Data Typeとして、"boolean"が指定された場合には、その要素又は属性がブール型であることを示している。なお、Data Typeとして、"language"が指定された場合、その要素又は属性の値が、xml:lang属性の値として有効なものであることを示し、"dateTime"が指定された場合、その要素又は属性の値が、特定の日時であることを示すものとする。
【０４３１】
（USDのフォーマット）
図３６は、XML形式のUSDメタデータ（USBDメタデータ）のフォーマットの例を示す図である。
【０４３２】
bundleDescription要素は、ルート要素であって、userServiceDescription要素（USD要素）の上位要素となる。このuserServiceDescription要素は、globalServiceID属性、serviceId属性、serviceStatus属性、fullMPDUri属性、sTSIDUri属性、applicationUrl属性、name要素、serviceLanguage要素、capabilityCode要素、及び、deliveryMethod要素の上位要素となる。
【０４３３】
globalServiceID属性には、グローバルサービスIDが指定される。serviceId属性には、サービスIDが指定される。serviceStatus属性には、サービスのステータスに関する情報が指定される。fullMPDUri属性には、MPDメタデータを参照するためのURIが指定される。sTSIDUri属性には、S-TSIDメタデータを参照するためのURIが指定される。
【０４３４】
applicationUrl属性には、アプリケーションの取得先を示すURL（アプリURL）が指定される。このアプリURLは、例えば、アプリケーションが、HTML文書ファイルや画像ファイルなど、複数のファイルから構成されている場合に、そのエントリ（例えば、index.html）を識別するための情報とされる。また、このUSDメタデータを受信したクライアント装置６０においては、アプリURLに応じてアプリケーションが取得され、即時に起動されることになる。
【０４３５】
name要素には、ATSC3.0のサービスの名称が指定される。name要素は、lang属性の上位要素となる。lang属性には、ATSC3.0のサービスの名称の言語が指定される。serviceLanguage要素には、ATSC3.0のサービスで利用できる言語が指定される。capabilityCode要素には、機能に関するコードが指定される。
【０４３６】
deliveryMethod要素には、データの配信方法に関する情報が指定される。deliveryMethod要素は、broadcastAppService要素及びunicastAppService要素の上位要素となる。broadcastAppService要素は、basePattern要素の上位要素であって、放送経由での配信に関する情報が指定される。unicastAppService要素は、basePattern要素の上位要素であって、通信経由での配信に関する情報が指定される。
【０４３７】
（S-TSIDのフォーマット）
図３７は、S-TSIDメタデータのフォーマットの例を示す図である。
【０４３８】
S-TSID要素は、ルート要素であって、serviceId属性、applicationUrl属性、及び、RS要素の上位要素となる。serviceId属性には、サービスIDが指定される。
【０４３９】
applicationUrl属性には、アプリケーションの取得先を示すURL（アプリURL）が指定される。このアプリURLは、例えば、アプリケーションが、HTML文書ファイルや画像ファイルなど、複数のファイルから構成されている場合に、そのエントリ（例えば、index.html）を識別するための情報とされる。また、このS-TSIDメタデータを受信したクライアント装置６０においては、アプリURLに応じてアプリケーションが取得され、即時に起動されることになる。
【０４４０】
RS要素には、ROUTEセッションに関する情報が指定される。RS要素は、bsid属性、sIpAddr属性、dIpAddr属性、dport属性、PLPID属性、及び、LS要素の上位要素となる。
【０４４１】
bsid属性には、ブロードキャストストリームIDが指定される。sIpAddr属性には、送信元（source）のIPアドレスが指定される。dIpAddr属性には、宛先（destination）のIPアドレスが指定される。dport属性には、宛先（destination）のポート番号が指定される。PLPID属性には、ROUTEセッションのPLPのIDが指定される。
【０４４２】
LS要素には、LCTセッションに関する情報が指定される。LS要素は、tsi属性、PLPID属性、bw属性、startTime属性、endTime属性、SrcFlow要素、及び、RprFlow要素の上位要素となる。
【０４４３】
tsi属性には、TSIが指定される。PLPID属性には、PLPのIDが指定される。bw属性には、帯域幅が指定される。startTime属性とendTime属性には、開始日時と終了日時が指定される。SrcFlow要素には、ソースフロー情報が指定される。
【０４４４】
（MPDのフォーマット）
図３８は、MPDメタデータのフォーマットの例を示す図である。
【０４４５】
図３８において、"attributes"の枠内には、ルート要素であるMPD要素の配下に規定される属性が列挙され、"attributes"の枠外には、MPD要素の配下に規定される要素が列挙されている。MPD要素に規定されている属性又は要素のうち、"any ##other"は、自由に拡張可能な領域であることを表しており、ここに、applicationUrl属性又はapplicationUrl要素が定義されるようにする。
【０４４６】
このapplicationUrl属性又はapplicationUrl要素には、アプリケーションの取得先を示すURL（アプリURL）が指定される。このアプリURLは、例えば、アプリケーションが、HTML文書ファイルや画像ファイルなど、複数のファイルから構成されている場合に、そのエントリ（例えば、index.html）を識別するための情報とされる。また、このMPDメタデータを受信したクライアント装置６０においては、アプリURLに応じてアプリケーションが取得され、即時に起動されることになる。
【０４４７】
ここで、例えば、applicationUrl要素を用いて、アプリURLを記述する場合には、以下のような構造で記述することができる。つまり、この例では、コンテンツパートに、アプリURLをそのまま格納している場合を示している。
【０４４８】
<ApplicationUrl>http://xxx.com/app.html</ApplicationUrl>
【０４４９】
（S-TSIDにアプリケーションのエントリを明示する場合のメタデータの構造）
次に、図３９乃至図４２を参照して、S-TSIDにアプリケーションのエントリを明示する場合のメタデータの構造について説明する。
【０４５０】
図３９は、S-TSIDメタデータのフォーマットの例を示す図である。
【０４５１】
図３９のS-TSIDメタデータは、図３７のS-TSIDメタデータと比べて、applicationUrl属性が除かれている点が異なっている。ここで、図４０には、図３９のS-TSIDメタデータに含まれるSrcFlow要素のフォーマットが示されている。
【０４５２】
図４０のSrcFlow要素は、rt属性、minBuffSize属性、EFDT要素、ContentInfo要素、及び、Payload要素の上位要素となる。
【０４５３】
minBuffSize属性には、クライアント装置４０が必要とする最小バッファサイズが指定される。EFDT要素には、拡張されたFDT（Extended FDT）に関する情報が指定される。ContentInfo要素には、コンテンツに関する情報が指定される。
【０４５４】
Payload要素は、codePoint属性、formatID属性、frag属性、order属性、srcFecPayloadID属性、及び、FECParams属性の上位要素であって、ソースフローのオブジェクトを格納するROUTEパケットのペイロードに関する情報が指定される。
【０４５５】
ここで、図４１には、図４０のSrcFlow要素に含まれるEFDT要素のフォーマットが示されている。図４１のEFDT要素は、tsi属性、idRef属性、version属性、maxExpiresDelta属性、maxTransportSize属性、FileTemplate属性、及び、FDTParameters属性の上位要素となる。
【０４５６】
FDTParameters属性には、IETF(Internet Engineering Task Force)で定義されているFDTのルート要素であるFDT-Instanceと同じ型が定義される。図４２には、FDT-Instance要素の構造が示されている。すなわち、FDT-Instance要素に規定されている属性のうち、"any"（"any ##other"）は、自由に拡張可能な領域であることを表しており、ここに、ApplicationEntry属性を定義することができる。このApplicationEntry属性には、アプリケーションのエントリ用のファイルのURLであるファイルURL（つまり、アプリURL）が記述される。
【０４５７】
また、FDT-Instance要素の配下には、File要素が定義されているが、このFile要素の属性又は要素のうち、"any"（"any ##other"）は、自由に拡張可能な領域であることを表しており、ここに、ApplicationEntry属性又はApplicationEntry要素が定義されるようにする。
【０４５８】
ただし、File要素に、ApplicationEntry属性を定義した場合には、この属性（ブーリアン値は"ture"）を持つFile要素のContent-Location属性（ファイルURL（アプリURL））で示されるファイルが、アプリケーションのエントリであることを示している。また、File要素に、ApplicationEntry要素を定義した場合には、この要素が存在するFile要素のContent-Location属性（ファイルURL（アプリURL））で示されるファイルが、アプリケーションのエントリであることを示している。
【０４５９】
なお、図４２において、FDT-Instance要素に定義可能なApplicationEntry属性と、FDT-Instance要素の配下のFile要素に定義可能なApplicationEntry属性又はApplicationEntry要素は、いずれか一方が定義されることになる。
【０４６０】
＜４．変形例＞
【０４６１】
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、上述した説明では、IP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。
【０４６２】
また、デジタル放送としては、地上波放送のほか、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）等を利用した衛星放送や、ケーブルテレビ（CATV）等の有線放送などに適用することができる。
【０４６３】
また、上述したシグナリングなどの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象のシグナリングなどの実質的な内容が異なるものではない。例えば、AST(Application Signaling Table)は、AIT(Application Information Table)などと称され、LCC(Locally Cached Content)は、NRT(Non Real Time)などと称される場合がある。さらに、シグナリングがXML等のマークアップ言語により記述される場合において、それらの要素や属性の名称は一例であって、他の名称が採用されるようにしてもよい。ただし、これらの名称の違いは、形式的な違いであって、それらの要素や属性の実質的な内容が異なるものではない。
【０４６４】
また、上述した説明では、LLSシグナリングとして、SLTメタデータを説明したが、LLSシグナリングには、EAT(Emergency Alerting Table)やRRT(Region Rating Table)などのメタデータが含まれるようにしてもよい。EATメタデータは、緊急に告知する必要がある緊急情報に関する情報を含む。RRTメタデータは、レーティングに関する情報を含む。
【０４６５】
なお、アプリケーションは、HTML5等のマークアップ言語やJavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションに限らず、例えば、Java（登録商標）などのプログラミング言語で開発されたアプリケーションであってもよい。また、上述したコンテンツには、動画や広告のほか、例えば、電子書籍やゲーム、音楽など、あらゆるコンテンツを含めることができる。
【０４６６】
また、本技術は、伝送路として、放送網以外の伝送路、すなわち、例えば、インターネットや電話網等の通信回線（通信網）などを利用することを想定して規定されている所定の規格（デジタル放送の規格以外の規格）などにも適用することができる。
【０４６７】
＜５．コンピュータの構成＞
【０４６８】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図４３は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
【０４６９】
コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
【０４７０】
入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア１０１１を駆動する。
【０４７１】
以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
【０４７２】
コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０４７３】
コンピュータ１０００では、プログラムは、リムーバブルメディア１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
【０４７４】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０４７５】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０４７６】
また、本技術は、以下のような構成をとることができる。
【０４７７】
（１）
コンテンツを受信する受信部と、
前記コンテンツとともに伝送される制御情報に含まれる、前記コンテンツに付随するアプリケーションの取得先を示す取得先情報に基づいて、前記アプリケーションを取得する取得部と、
取得された前記アプリケーションを即時に起動する制御部と
を備える受信装置。
（２）
前記コンテンツ及び前記制御情報は、放送波により伝送され、
前記制御情報は、デジタル放送のサービスを提供するためのシグナリングであり、
前記取得先情報は、URL(Uniform Resource Locator)である
（１）に記載の受信装置。
（３）
前記制御部は、前記コンテンツ又は前記制御情報とともに伝送されるイベントに従い、前記アプリケーションの動作を制御する
（２）に記載の受信装置。
（４）
前記取得部は、前記コンテンツのDRM(Digital Rights Management)により保護された前記アプリケーションを取得し、
前記受信装置は、取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する検証部をさらに備え、
前記制御部は、前記アプリケーションが正当なアプリケーションであると認められた場合に、当該アプリケーションを起動する
（１）乃至（３）のいずれかに記載の受信装置。
（５）
前記検証部は、
前記コンテンツのストリームに含まれる、前記アプリケーションに応じた第１のダイジェスト値を抽出し、
取得された前記アプリケーションに応じた第２のダイジェスト値を生成し、
前記第１のダイジェスト値と、前記第２のダイジェスト値とを比較することで、取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する
（４）に記載の受信装置。
（６）
前記コンテンツのビデオデータは、所定の符号化方式に従い、符号化されており、
前記第１のダイジェスト値は、暗号化されたVCL-NAL(Video Coding Layer - Network Abstraction Layer)ユニットに含まれるベースバンドフレームに挿入されるウォータマークに格納される
（５）に記載の受信装置。
（７）
前記コンテンツのビデオデータは、所定の符号化方式に従い、符号化されており、
前記第１のダイジェスト値は、暗号化された非VCL-NAL(Non Video Coding Layer - Network Abstraction Layer)ユニットに格納される
（５）に記載の受信装置。
（８）
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツを受信し、
前記コンテンツとともに伝送される制御情報に含まれる、前記コンテンツに付随するアプリケーションの取得先を示す取得先情報に基づいて、前記アプリケーションを取得し、
取得された前記アプリケーションを即時に起動する
ステップを含むデータ処理方法。
（９）
コンテンツに付随するアプリケーションの取得先を示す取得先情報であって、取得された前記アプリケーションを即時に起動させるための前記取得先情報を含む制御情報を生成する生成部と、
前記コンテンツとともに、前記制御情報を送信する送信部と
を備える送信装置。
（１０）
送信装置のデータ処理方法において、
前記送信装置が、
コンテンツに付随するアプリケーションの取得先を示す取得先情報であって、取得された前記アプリケーションを即時に起動させるための前記取得先情報を含む制御情報を生成し、
前記コンテンツとともに、前記制御情報を送信する
ステップを含むデータ処理方法。
（１１）
コンテンツを受信する受信部と、
前記コンテンツに付随するアプリケーションであって、前記コンテンツのDRM(Digital Rights Management)により保護された前記アプリケーションを取得する取得部と、
取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する検証部と、
前記アプリケーションが正当なアプリケーションであると認められた場合に、当該アプリケーションを起動する制御部と
を備える受信装置。
（１２）
前記検証部は、
前記コンテンツのストリームに含まれる、前記アプリケーションに応じた第１のダイジェスト値を抽出し、
取得された前記アプリケーションに応じた第２のダイジェスト値を生成し、
前記第１のダイジェスト値と、前記第２のダイジェスト値とを比較することで、取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する
（１１）に記載の受信装置。
（１３）
前記コンテンツのビデオデータは、所定の符号化方式に従い、符号化されており、
前記第１のダイジェスト値は、暗号化されたVCL-NAL(Video Coding Layer - Network Abstraction Layer)ユニットに含まれるベースバンドフレームに挿入されるウォータマークに格納される
（１２）に記載の受信装置。
（１４）
前記コンテンツのビデオデータは、所定の符号化方式に従い、符号化されており、
前記第１のダイジェスト値は、暗号化された非VCL-NAL(Non Video Coding Layer - Network Abstraction Layer)ユニットに格納される
（１２）に記載の受信装置。
（１５）
前記第１のダイジェスト値は、前記アプリケーションを識別するための識別情報とともに、メッセージに含めて伝送される
（１２）に記載の受信装置。
（１６）
前記取得部は、前記コンテンツとともに伝送される制御情報に含まれる、前記アプリケーションの取得先を示す取得先情報に基づいて、前記アプリケーションを取得し、
前記制御部は、取得された前記アプリケーションが正当なアプリケーションであると認められた場合、当該アプリケーションを即時に起動する
（１１）乃至（１５）のいずれかに記載の受信装置。
（１７）
前記コンテンツ及び前記制御情報は、放送波により伝送され、
前記制御情報は、デジタル放送のサービスを提供するためのシグナリングであり、
前記取得先情報は、URL(Uniform Resource Locator)である
（１６）に記載の受信装置。
（１８）
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツを受信し、
前記コンテンツに付随するアプリケーションであって、前記コンテンツのDRM(Digital Rights Management)により保護された前記アプリケーションを取得し、
取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する検証部と、
前記アプリケーションが正当なアプリケーションであると認められた場合、当該アプリケーションを起動する
ステップを含むデータ処理方法。
（１９）
コンテンツに付随するアプリケーションを、前記コンテンツのDRM(Digital Rights Management)により保護する保護部と、
共通のDRM(Digital Rights Management)により保護された前記コンテンツ及び前記アプリケーションを送信する送信部と
を備える送信装置。
（２０）
送信装置のデータ処理方法において、
前記送信装置が、
コンテンツに付随するアプリケーションを、前記コンテンツのDRM(Digital Rights Management)により保護し、
共通のDRM(Digital Rights Management)により保護された前記コンテンツ及び前記アプリケーションを送信する
ステップを含むデータ処理方法。
【符号の説明】
【０４７８】
１，２  伝送システム，  ５，７  送信側システム，  １０  DASHサーバ，  ２０  シグナリングサーバ，  ３０  アプリケーションサーバ，  ４０  放送サーバ，  ５０  通信サーバ，  ６０  クライアント装置，  ７０  ストリームサーバ，  ８０  伝送路，  ９０  インターネット，  １０１  受信部，  １０２  処理部，  １０３  送信部，  １１１  MPD生成部，  １１２  DASHセグメント生成部，  １１３  暗号化部，  １１４  DRM保護ファイル生成部，  １１５  非VCL-NALユニット生成部，  ２０１  受信部，  ２０２  処理部，  ２０３  送信部，  ２１１  シグナリング生成部，  ３０１  受信部，  ３０２  処理部，  ３０３  送信部，  ３１１  アプリURL生成部，  ３１２  アプリケーション生成部，  ３１３  アプリ制御イベント生成部，  ３１４  アプリダイジェスト生成部，  ４０１  受信部，  ４０２  処理部，  ４０３  送信部，  ６０１  処理部，  ６０２  入力部，  ６０３  受信部，  ６０４  放送ミドルウェア，  ６０５  DASHクライアント，  ６０６  デコーダ，  ６０７  出力部，  ６０８  通信部，  ６１１  アプリケーション制御部，  ６１２  レンダリングエンジン，  ６１３  ウォータマークイクストラクタ，  ６１４  アプリダイジェストバリデータ，  ７０１  受信部，  ７０２  処理部，  ７０３  送信部，  ７１１  ストリーム生成部，  ７１２  ウォータマークインサータ，  ７１３  エンコーダ，  １０００  コンピュータ，  １００１  CPU
【図１】
2017122554.tif 000003
【図２】
2017122554.tif 000004
【図３】
2017122554.tif 000005
【図４】
2017122554.tif 000006
【図５】
2017122554.tif 000007
【図６】
2017122554.tif 000008
【図７】
2017122554.tif 000009
【図８】
2017122554.tif 000010
【図９】
2017122554.tif 000011
【図１０】
2017122554.tif 000012
【図１１】
2017122554.tif 000013
【図１２】
2017122554.tif 000014
【図１３】
2017122554.tif 000015
【図１４】
2017122554.tif 000016
【図１５】
2017122554.tif 000017
【図１６】
2017122554.tif 000018
【図１７】
2017122554.tif 000019
【図１８】
2017122554.tif 000020
【図１９】
2017122554.tif 000021
【図２０】
2017122554.tif 000022
【図２１】
2017122554.tif 000023
【図２２】
2017122554.tif 000024
【図２３】
2017122554.tif 000025
【図２４】
2017122554.tif 000026
【図２５】
2017122554.tif 000027
【図２６】
2017122554.tif 000028
【図２７】
2017122554.tif 000029
【図２８】
2017122554.tif 000030
【図２９】
2017122554.tif 000031
【図３０】
2017122554.tif 000032
【図３１】
2017122554.tif 000033
【図３２】
2017122554.tif 000034
【図３３】
2017122554.tif 000035
【図３４】
2017122554.tif 000036
【図３５】
2017122554.tif 000037
【図３６】
2017122554.tif 000038
【図３７】
2017122554.tif 000039
【図３８】
2017122554.tif 000040
【図３９】
2017122554.tif 000041
【図４０】
2017122554.tif 000042
【図４１】
2017122554.tif 000043
【図４２】
2017122554.tif 000044
【図４３】
2017122554.tif 000045
【国際調査報告】
2017122554.tif 000046
2017122554.tif 000047
2017122554.tif 000048
2017122554.tif 000049