JPWO2017122554A1 - 受信装置、送信装置、及び、データ処理方法 - Google Patents

受信装置、送信装置、及び、データ処理方法 Download PDF

Info

Publication number
JPWO2017122554A1
JPWO2017122554A1 JP2017561587A JP2017561587A JPWO2017122554A1 JP WO2017122554 A1 JPWO2017122554 A1 JP WO2017122554A1 JP 2017561587 A JP2017561587 A JP 2017561587A JP 2017561587 A JP2017561587 A JP 2017561587A JP WO2017122554 A1 JPWO2017122554 A1 JP WO2017122554A1
Authority
JP
Japan
Prior art keywords
application
content
unit
server
signaling
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2017561587A
Other languages
English (en)
Inventor
山岸　靖明
靖明 山岸
五十嵐　卓也
卓也 五十嵐
高林　和彦
和彦 高林
淳 北原
淳 北原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Publication of JPWO2017122554A1 publication Critical patent/JPWO2017122554A1/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/16—Program or content traceability, e.g. by watermarking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/4722—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting additional data associated with the content
    • H04N21/4725—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting additional data associated with the content using interactive regions of the image, e.g. hot spots
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86—Arrangements characterised by the broadcast information itself
    • H04H20/91—Arrangements characterised by the broadcast information itself broadcasting computer programmes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86—Arrangements characterised by the broadcast information itself
    • H04H20/93—Arrangements characterised by the broadcast information itself which locates resources of other pieces of information, e.g. URL [Uniform Resource Locator]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/13—Arrangements for device control affected by the broadcast information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/14—Arrangements for conditional access to broadcast information or to broadcast-related services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/14—Arrangements for conditional access to broadcast information or to broadcast-related services
    • H04H60/23—Arrangements for conditional access to broadcast information or to broadcast-related services using cryptography, e.g. encryption, authentication, key distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H04N21/4353—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream involving decryption of additional data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44236—Monitoring of piracy processes or activities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/8173—End-user applications, e.g. Web browser, game
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8358—Generation of protective data, e.g. certificates involving watermark
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
    • H04H60/81—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself
    • H04H60/82—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself the transmission system being the Internet

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Technology Law (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Human Computer Interaction (AREA)
  • Virology (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Circuits Of Receivers In General (AREA)

Abstract

本技術は、コンテンツに付随するアプリケーションを用いたサービスを柔軟に運用することができるようにする受信装置、送信装置、及び、データ処理方法に関する。
受信装置は、コンテンツを受信する受信部と、前記コンテンツとともに伝送される制御情報に含まれる、前記コンテンツに付随するアプリケーションの取得先を示す取得先情報に基づいて、前記アプリケーションを取得する取得部と、取得された前記アプリケーションを即時に起動する制御部とを備える。本技術は、例えば、デジタル放送を受信可能なテレビ受像機に適用することができる。

Description

本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、コンテンツに付随するアプリケーションを用いたサービスを柔軟に運用することができるようにした受信装置、送信装置、及び、データ処理方法に関する。
番組や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

Claims (20)

  1. コンテンツを受信する受信部と、
    前記コンテンツとともに伝送される制御情報に含まれる、前記コンテンツに付随するアプリケーションの取得先を示す取得先情報に基づいて、前記アプリケーションを取得する取得部と、
    取得された前記アプリケーションを即時に起動する制御部と
    を備える受信装置。
  2. 前記コンテンツ及び前記制御情報は、放送波により伝送され、
    前記制御情報は、デジタル放送のサービスを提供するためのシグナリングであり、
    前記取得先情報は、URL(Uniform Resource Locator)である
    請求項１に記載の受信装置。
  3. 前記制御部は、前記コンテンツ又は前記制御情報とともに伝送されるイベントに従い、前記アプリケーションの動作を制御する
    請求項２に記載の受信装置。
  4. 前記取得部は、前記コンテンツのDRM(Digital Rights Management)により保護された前記アプリケーションを取得し、
    前記受信装置は、取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する検証部をさらに備え、
    前記制御部は、前記アプリケーションが正当なアプリケーションであると認められた場合に、当該アプリケーションを起動する
    請求項１に記載の受信装置。
  5. 前記検証部は、
    前記コンテンツのストリームに含まれる、前記アプリケーションに応じた第１のダイジェスト値を抽出し、
    取得された前記アプリケーションに応じた第２のダイジェスト値を生成し、
    前記第１のダイジェスト値と、前記第２のダイジェスト値とを比較することで、取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する
    請求項４に記載の受信装置。
  6. 前記コンテンツのビデオデータは、所定の符号化方式に従い、符号化されており、
    前記第１のダイジェスト値は、暗号化されたVCL-NAL(Video Coding Layer - Network Abstraction Layer)ユニットに含まれるベースバンドフレームに挿入されるウォータマークに格納される
    請求項５に記載の受信装置。
  7. 前記コンテンツのビデオデータは、所定の符号化方式に従い、符号化されており、
    前記第１のダイジェスト値は、暗号化された非VCL-NAL(Non Video Coding Layer - Network Abstraction Layer)ユニットに格納される
    請求項５に記載の受信装置。
  8. 受信装置のデータ処理方法において、
    前記受信装置が、
    コンテンツを受信し、
    前記コンテンツとともに伝送される制御情報に含まれる、前記コンテンツに付随するアプリケーションの取得先を示す取得先情報に基づいて、前記アプリケーションを取得し、
    取得された前記アプリケーションを即時に起動する
    ステップを含むデータ処理方法。
  9. コンテンツに付随するアプリケーションの取得先を示す取得先情報であって、取得された前記アプリケーションを即時に起動させるための前記取得先情報を含む制御情報を生成する生成部と、
    前記コンテンツとともに、前記制御情報を送信する送信部と
    を備える送信装置。
  10. 送信装置のデータ処理方法において、
    前記送信装置が、
    コンテンツに付随するアプリケーションの取得先を示す取得先情報であって、取得された前記アプリケーションを即時に起動させるための前記取得先情報を含む制御情報を生成し、
    前記コンテンツとともに、前記制御情報を送信する
    ステップを含むデータ処理方法。
  11. コンテンツを受信する受信部と、
    前記コンテンツに付随するアプリケーションであって、前記コンテンツのDRM(Digital Rights Management)により保護された前記アプリケーションを取得する取得部と、
    取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する検証部と、
    前記アプリケーションが正当なアプリケーションであると認められた場合に、当該アプリケーションを起動する制御部と
    を備える受信装置。
  12. 前記検証部は、
    前記コンテンツのストリームに含まれる、前記アプリケーションに応じた第１のダイジェスト値を抽出し、
    取得された前記アプリケーションに応じた第２のダイジェスト値を生成し、
    前記第１のダイジェスト値と、前記第２のダイジェスト値とを比較することで、取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する
    請求項１１に記載の受信装置。
  13. 前記コンテンツのビデオデータは、所定の符号化方式に従い、符号化されており、
    前記第１のダイジェスト値は、暗号化されたVCL-NAL(Video Coding Layer - Network Abstraction Layer)ユニットに含まれるベースバンドフレームに挿入されるウォータマークに格納される
    請求項１２に記載の受信装置。
  14. 前記コンテンツのビデオデータは、所定の符号化方式に従い、符号化されており、
    前記第１のダイジェスト値は、暗号化された非VCL-NAL(Non Video Coding Layer - Network Abstraction Layer)ユニットに格納される
    請求項１２に記載の受信装置。
  15. 前記第１のダイジェスト値は、前記アプリケーションを識別するための識別情報とともに、メッセージに含めて伝送される
    請求項１２に記載の受信装置。
  16. 前記取得部は、前記コンテンツとともに伝送される制御情報に含まれる、前記アプリケーションの取得先を示す取得先情報に基づいて、前記アプリケーションを取得し、
    前記制御部は、取得された前記アプリケーションが正当なアプリケーションであると認められた場合、当該アプリケーションを即時に起動する
    請求項１１に記載の受信装置。
  17. 前記コンテンツ及び前記制御情報は、放送波により伝送され、
    前記制御情報は、デジタル放送のサービスを提供するためのシグナリングであり、
    前記取得先情報は、URL(Uniform Resource Locator)である
    請求項１６に記載の受信装置。
  18. 受信装置のデータ処理方法において、
    前記受信装置が、
    コンテンツを受信し、
    前記コンテンツに付随するアプリケーションであって、前記コンテンツのDRM(Digital Rights Management)により保護された前記アプリケーションを取得し、
    取得された前記アプリケーションが、正当なアプリケーションであるかどうかを検証する検証部と、
    前記アプリケーションが正当なアプリケーションであると認められた場合、当該アプリケーションを起動する
    ステップを含むデータ処理方法。
  19. コンテンツに付随するアプリケーションを、前記コンテンツのDRM(Digital Rights Management)により保護する保護部と、
    共通のDRM(Digital Rights Management)により保護された前記コンテンツ及び前記アプリケーションを送信する送信部と
    を備える送信装置。
  20. 送信装置のデータ処理方法において、
    前記送信装置が、
    コンテンツに付随するアプリケーションを、前記コンテンツのDRM(Digital Rights Management)により保護し、
    共通のDRM(Digital Rights Management)により保護された前記コンテンツ及び前記アプリケーションを送信する
    ステップを含むデータ処理方法。
JP2017561587A 2016-01-15 2017-01-04 受信装置、送信装置、及び、データ処理方法 Pending JPWO2017122554A1 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2016006375 2016-01-15
JP2016006375 2016-01-15
PCT/JP2017/000012 WO2017122554A1 (ja) 2016-01-15 2017-01-04 受信装置、送信装置、及び、データ処理方法

Publications (1)

Publication Number Publication Date
JPWO2017122554A1 true JPWO2017122554A1 (ja) 2018-11-01

Family

ID=59310968

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017561587A Pending JPWO2017122554A1 (ja) 2016-01-15 2017-01-04 受信装置、送信装置、及び、データ処理方法

Country Status (7)

Country Link
US (2) US11449583B2 (ja)
EP (1) EP3404924B1 (ja)
JP (1) JPWO2017122554A1 (ja)
KR (1) KR102653289B1 (ja)
CA (1) CA3010777C (ja)
MX (1) MX2018008395A (ja)
WO (1) WO2017122554A1 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2016017451A1 (ja) * 2014-08-01 2017-05-18 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
CA3071560C (en) * 2017-08-10 2024-01-23 Sony Corporation Transmission apparatus, transmission method, reception apparatus, and reception method
US11310540B2 (en) * 2017-11-10 2022-04-19 Qualcomm Incorporated Interfaces between dash aware application and dash client for service interactivity support
KR102642928B1 (ko) * 2019-03-26 2024-03-04 삼성전자주식회사 방송 수신 장치 및 그 동작 방법
JP7390816B2 (ja) * 2019-08-02 2023-12-04 日本放送協会 配信システム、受信装置およびプログラム
US11303688B2 (en) * 2019-09-30 2022-04-12 Tencent America LLC Methods and apparatuses for dynamic adaptive streaming over HTTP
KR102302755B1 (ko) * 2019-12-30 2021-09-16 재단법인 경주스마트미디어센터 Drm 콘텐츠 병렬 패키징 장치 및 이를 포함하는 drm 콘텐츠 병렬 패키징 시스템 및 drm 콘텐츠 병렬 패키징 방법
WO2021137633A2 (ko) * 2019-12-30 2021-07-08 재단법인 경주스마트미디어센터 Drm 콘텐츠 병렬 패키징 장치 및 이를 포함하는 drm 콘텐츠 병렬 패키징 시스템 및 drm 콘텐츠 병렬 패키징 방법
US11941092B2 (en) * 2020-02-06 2024-03-26 Saturn Licensing Llc Techniques for launching applications based on partial signature validation
JP7523279B2 (ja) 2020-08-06 2024-07-26 日本放送協会 メタデータ挿入装置およびプログラム
KR102711122B1 (ko) * 2021-11-11 2024-09-30 주식회사 엘지유플러스 Drm 컨텐트 재생을 위한 미디어 sdk 및 그 제어 방법

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6243480B1 (en) * 1998-04-30 2001-06-05 Jian Zhao Digital authentication with analog documents
US6487301B1 (en) * 1998-04-30 2002-11-26 Mediasec Technologies Llc Digital authentication with digital and analog documents
US20030217369A1 (en) * 2002-05-17 2003-11-20 Heredia Edwin Arturo Flexible application information formulation
US8869289B2 (en) 2009-01-28 2014-10-21 Microsoft Corporation Software application verification
JP6053323B2 (ja) * 2011-05-20 2016-12-27 日本放送協会 放送送信装置、放送通信連携受信装置およびそのプログラム、ならびに、放送通信連携システム
US20130042100A1 (en) * 2011-08-09 2013-02-14 Nokia Corporation Method and apparatus for forced playback in http streaming
TWI528749B (zh) 2011-09-06 2016-04-01 Sony Corp A signal receiving device, a signal receiving method, an information processing program and an information processing system
KR101654439B1 (ko) * 2011-09-23 2016-09-12 엘지전자 주식회사 방송 서비스 수신 방법 및 그 수신 장치
IN2014MN00981A (ja) * 2011-12-21 2015-04-24 Sony Corp
CN106452759B (zh) * 2012-04-27 2019-11-19 华为技术有限公司 用于在模板模式下有效支持短加密区间的系统和方法
US9883247B2 (en) * 2012-08-13 2018-01-30 Saturn Licensing Llc Reception apparatus, reception method, transmission apparatus, and transmission method
EP2925007B1 (en) 2012-11-23 2019-06-26 Saturn Licensing LLC Information processing device and information processing method
ES2645101T3 (es) * 2013-01-17 2017-12-04 Intel IP Corporation Autentificación de URL de contenidos para dash
KR20160142327A (ko) * 2014-04-30 2016-12-12 엘지전자 주식회사 방송 전송 장치, 방송 수신 장치, 방송 전송 장치의 동작 방법 및 방송 수신 장치의 동작 방법
WO2015182490A1 (ja) * 2014-05-30 2015-12-03 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法

Also Published As

Publication number Publication date
CA3010777C (en) 2024-06-04
EP3404924A1 (en) 2018-11-21
CA3010777A1 (en) 2017-07-20
WO2017122554A1 (ja) 2017-07-20
KR20180105641A (ko) 2018-09-28
US12045325B2 (en) 2024-07-23
EP3404924B1 (en) 2023-04-26
US20190026444A1 (en) 2019-01-24
EP3404924A4 (en) 2019-05-01
US11449583B2 (en) 2022-09-20
MX2018008395A (es) 2018-08-15
KR102653289B1 (ko) 2024-04-02
US20230099480A1 (en) 2023-03-30

Similar Documents

Publication Publication Date Title
KR102653289B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
US11368766B2 (en) System and method for signaling security and database population
EP2925007B1 (en) Information processing device and information processing method
WO2012157756A1 (ja) 受信機
KR20180088383A (ko) 수신 장치, 송신 장치, 및 데이터 처리 방법
JP6973454B2 (ja) 情報処理システムおよび送受信方法
JP6423067B2 (ja) 放送通信連携受信装置及び放送通信連携システム
JP2013009344A (ja) 受信機
US8850590B2 (en) Systems and methods for using transport stream splicing for programming information security
KR102586630B1 (ko) 수신 장치, 송신 장치, 및 데이터 처리 방법
JPWO2012157718A1 (ja) 受信機および受信方法
JP6018798B2 (ja) 受信機
JP5350021B2 (ja) ファイル生成装置、ファイル再生装置およびコンピュータプログラム
US20220201372A1 (en) Live video streaming architecture with real-time frame and subframe level live watermarking
JP2012257229A (ja) 受信機
JP2005269412A (ja) コンテンツ配信システムおよび視聴者端末装置