JP6544352B2 - 受信装置、及び、受信方法 - Google Patents

受信装置、及び、受信方法 Download PDF

Info

Publication number
JP6544352B2
JP6544352B2 JP2016521030A JP2016521030A JP6544352B2 JP 6544352 B2 JP6544352 B2 JP 6544352B2 JP 2016521030 A JP2016521030 A JP 2016521030A JP 2016521030 A JP2016521030 A JP 2016521030A JP 6544352 B2 JP6544352 B2 JP 6544352B2
Authority
JP
Japan
Prior art keywords
broadcast
application
tpt
receiver
attribute
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.)
Expired - Fee Related
Application number
JP2016521030A
Other languages
English (en)
Other versions
JPWO2015178218A1 (ja
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 JPWO2015178218A1 publication Critical patent/JPWO2015178218A1/ja
Application granted granted Critical
Publication of JP6544352B2 publication Critical patent/JP6544352B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • 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/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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25875—Management of end-user data involving end-user authentication
    • 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/41—Structure of client; Structure of client peripherals
    • H04N21/418—External card to be used in combination with the client device, e.g. for conditional access
    • H04N21/4182—External card to be used in combination with the client device, e.g. for conditional access for identification purposes, e.g. storing user identification data, preferences, personal settings or 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/431—Generation of visual interfaces for content selection or interaction; Content or additional data rendering
    • H04N21/4312—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations
    • H04N21/4316—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations for displaying supplemental content in a region of the screen, e.g. an advertisement in a separate window
    • 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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG 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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H04N21/4349—Demultiplexing of additional data and video streams by extracting from data carousels, e.g. extraction of software modules from a DVB carousel
    • 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/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/44204—Monitoring of content usage, e.g. the number of times a movie has been viewed, copied or the amount which has been watched
    • 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
    • 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/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4782—Web browsing, e.g. WebTV
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6112—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving terrestrial transmission, e.g. DVB-T
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • 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/854—Content authoring
    • H04N21/8545—Content authoring for generating interactive applications
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Human Computer Interaction (AREA)
  • Computer Graphics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

本技術は、受信装置、及び、受信方法に関し、特に、特定のアプリケーションによる放送リソースの利用を制限することができるようにした受信装置、及び、受信方法に関する。
近年、デジタル放送信号で送信されるAVコンテンツを受信するだけでなく、インターネット配信されるアプリケーションやVOD(Video On Demand)コンテンツを受信可能な受信機が提供されている（例えば、特許文献１参照）。
特開２０１１−６６５５６号公報
ところで、この種の受信機において、例えばインターネット配信などの、放送局が放送波により提供する放送サービス以外の環境で取得されたアプリケーションによって、AVコンテンツ等の放送リソースが利用される場合に、特定のアプリケーションによる放送リソースの利用を制限する運用が行われることが想定される。しかしながら、そのような、特定のアプリケーションによる放送リソースの利用を制限するための技術方式は確立されていない。
本技術はこのような状況に鑑みてなされたものであり、特定のアプリケーションによる放送リソースの利用を制限することができるようにするものである。
本技術の一側面の受信装置は、デジタル放送信号を受信する受信部と、前記デジタル放送信号で送信される放送リソースの利用を要求可能な第１のアプリケーションを取得するアプリケーション取得部と、前記第１のアプリケーションの動作を制御するための第１の制御情報を取得する制御情報取得部と、前記第１のアプリケーションにより前記放送リソースの利用が要求された場合、前記第１の制御情報に基づいて、前記第１のアプリケーションによる前記放送リソースの利用を制御するアプリケーション制御部とを備え、前記制御情報取得部は、放送サービス内で起動される第２のアプリケーションの動作を制御するための第２の制御情報をさらに取得し、前記アプリケーション制御部は、前記第１の制御情報と、前記第２の制御情報との照合の結果に基づいて、前記第１のアプリケーションによる前記放送リソースを利用する動作の継続が認められない場合に、前記第１のアプリケーションによる前記放送リソースの利用を制限する受信装置である。
本技術の一側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。
本技術の一側面の受信方法は、上述した本技術の一側面の受信装置に対応する受信方法である。
本技術の一側面の受信装置、及び、受信方法においては、デジタル放送信号が受信され、前記デジタル放送信号で送信される放送リソースの利用を要求可能な第１のアプリケーションが取得され、前記第１のアプリケーションの動作を制御するための第１の制御情報が取得され、前記第１のアプリケーションにより前記放送リソースの利用が要求された場合、前記第１の制御情報に基づいて、前記第１のアプリケーションによる前記放送リソースの利用が制御される。また、放送サービス内で起動される第２のアプリケーションの動作を制御するための第２の制御情報がさらに取得され、前記第１の制御情報と、前記第２の制御情報との照合の結果に基づいて、前記第１のアプリケーションによる前記放送リソースを利用する動作の継続が認められない場合に、前記第１のアプリケーションによる前記放送リソースの利用が制限される。
本技術の一側面によれば、特定のアプリケーションによる放送リソースの利用を制限することができる。
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
放送リレートアプリの画面遷移を示す図である。 放送リレートアプリを実行する受信機の状態遷移を示す図である。 放送リレートアプリを実行する受信機の動作を示す図である。 放送リレートアプリの動作を制御するトリガ情報とTPTの対応を示す図である。 放送リレートアプリ用のTPTの記述例を示す図である。 放送リレートアプリ用のTPTのシンタックスの例を示す図である。 放送インディペンデントアプリの画面遷移を示す図である。 第１の実施の形態におけるシステム全体の処理の流れを示す図である。 放送インディペンデントアプリを実行する受信機の状態遷移を示す図である。 放送インディペンデントアプリを実行する受信機の動作を示す図である。 放送インディペンデントアプリ用のTPTの記述例を示す図である。 放送インディペンデントアプリ用のTPTのシンタックスの例を示す図である。 第２の実施の形態におけるシステム全体の処理の流れを示す図である。 放送インディペンデントアプリを実行する受信機の状態遷移を示す図である。 放送インディペンデントアプリを実行する受信機の動作を示す図である。 放送インディペンデントアプリ用のTPTの記述例を示す図である。 放送インディペンデントアプリ用のTPTのシンタックスの例を示す図である。 BroadcastPermission要素の詳細な内容を示す図である。 パーミッションビットマップの例を示す図である。 放送通信システムの構成例を示す図である。 送信装置の構成例を示す図である。 受信装置の構成例を示す図である。 制御部の構成例を示す図である。 各サーバの構成例を示す図である。 デジタル放送信号送信処理を説明するフローチャートである。 デジタル放送信号受信処理を説明するフローチャートである。 第１の放送インディペンデントアプリ対応処理を説明するフローチャートである。 第２の放送インディペンデントアプリ対応処理を説明するフローチャートである。 放送インディペンデントアプリ提供処理を説明するフローチャートである。 TPT提供処理を説明するフローチャートである。 放送通信システムの他の構成例を示す図である。 フィンガプリント情報を利用した場合の受信機の動作を示す図である。 ACR技術の概念を説明する図である。 コンピュータの構成例を示す図である。
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
１．ブロードキャストリレートアプリケーション
２．ブロードキャストインディペンデントアプリケーション
（１）第１の実施の形態
（２）第２の実施の形態
３．システム構成
４．各装置で実行される処理の流れ
５．変形例
６．コンピュータの構成
＜１．ブロードキャストリレートアプリケーション＞
ブロードキャストリレートアプリケーション（Broadcast Related Application）は、放送局が放送波により提供する放送サービス内で起動されるアプリケーションである。ここでは、デジタル放送信号を受信可能な受信機により実行されるブロードキャストリレートアプリケーションについて説明する。
なお、このブロードキャストリレートアプリケーションは、例えばHTML(HyperText Markup Language)ファイルなどから構成される。以下、ブロードキャストリレートアプリケーションは、「放送リレートアプリ」と称して説明する。また、Broadcast Related Applicationは、「Broadcast Related App」と略記する場合がある。
（放送リレートアプリの画面遷移）
図１は、放送リレートアプリの画面遷移を示す図である。
図１においては、放送番組等のAV（Audio Video）コンテンツのみが再生されている画面を、「放送全画面」と称し、AVコンテンツの再生とともに放送リレートアプリが実行されている画面を、「アプリ＋放送画面」と称するものとする。なお、これらの画面の名称は、後述する他の図でも同様とされる。
受信機においては、電源がオンされると、チャンネルＸの放送番組の映像が「放送全画面」で表示される。また、受信機では、チャンネルＸの放送番組の映像を「放送全画面」で表示中に、チャンネルＸの放送番組用の放送リレートアプリApp1が起動されると、その画面は、「放送全画面」から「アプリ＋放送画面」に遷移する。この「アプリ＋放送画面」は、チャンネルＸの放送番組の映像が縮小され、その余白部分に放送リレートアプリApp1の情報が表示されたＬ字型画面となる。すなわち、チャンネルＸの放送番組の映像は、子画面表示となる。
なお、「アプリ＋放送画面」を表示中に、放送リレートアプリApp1が終了すると、その画面は、「アプリ＋放送画面」から「放送全画面」に遷移して、子画面表示されていたチャンネルＸの放送番組の映像は、通常の大きさに戻されることになる。
ここで、「アプリ＋放送画面」を表示中に、ユーザによって、チャンネルがＸからＹに切り替えられた場合、「アプリ＋放送画面」では、その画面内に子画面表示されている映像が、チャンネルＸの放送番組の映像から、チャンネルＹの放送番組の映像に切り替えられる。また、受信機では、チャンネルＸの放送番組用の放送リレートアプリApp1が終了され、チャンネルＹの放送番組用の放送リレートアプリApp2が起動される。その結果、「アプリ＋放送画面」は、チャンネルＹの放送番組の映像が縮小され、その余白部分に放送リレートアプリApp2の情報が表示されたＬ字型画面となる。
その後、ユーザによって、放送リレートアプリApp2の終了が指示された場合、放送リレートアプリApp2は終了し、その画面は、「アプリ＋放送画面」から「放送全画面」に遷移して、子画面表示されていたチャンネルＹの放送番組の映像は、通常の大きさに戻されて表示されることになる。
（受信機の状態遷移）
図２は、放送リレートアプリを実行する受信機の状態遷移を示す図である。図２に示すように、受信機の状態は、「端末動作停止」、「放送受信（AVのみ再生）」、又は、「放送受信（AV再生＋放送リレートアプリ実行）」のうち、いずれかの状態に遷移していると定義される。
「端末動作停止」は、受信機の電源がオフされている状態を表している。「放送受信（AVのみ再生）」は、放送番組等のAVコンテンツのみが再生されている状態を表している。この状態に遷移した受信機では、「放送全画面」（図１）が表示される。「放送受信（AV再生＋放送リレートアプリ実行）」は、放送番組等のAVコンテンツの再生とともに、放送リレートアプリが実行されている状態を表している。この状態に遷移した受信機では、「アプリ＋放送画面」（図１）が表示される。
受信機が「端末動作停止」の状態に遷移している場合に、電源がオンされると、その状態は、「放送受信（AVのみ再生）」の状態に遷移する。また、受信機が「放送受信（AVのみ再生）」の状態に遷移している場合に、放送リレートアプリが起動されると、その状態は、「放送受信（AV再生＋放送リレートアプリ実行）」の状態に遷移する。なお、「受信機が放送受信（AVのみ再生）」の状態に遷移している場合に、電源がオフされると、その状態は、「端末動作停止」の状態に遷移する。
受信機が「放送受信（AV再生＋放送リレートアプリ実行）」の状態に遷移している場合に、放送リレートアプリ実行が終了されると、その状態は、「放送受信（AVのみ再生）」の状態に遷移する。なお、受信機が「放送受信（AV再生＋放送リレートアプリ実行）」の状態に遷移している場合に、電源がオフされると、その状態は、「端末動作停止」の状態に遷移する。
（受信機の動作）
図３は、放送リレートアプリを実行する受信機の動作を示す図である。すなわち、図３は、図２の「放送受信（AV再生＋放送リレートアプリ実行）」の状態に遷移したときの受信機の動作を表している。
図３においては、放送局の送信機（Broadcaster）によって、AVコンテンツ（図中の「Content」）のデジタル放送信号が、トリガ情報（図中の「Trigger」）を含めて送信される（Ｓ１）。受信機（Receiver）は、AVコンテンツとともに送信されるトリガ情報を取得し、トリガ情報に応じて、TPT(Trigger Parameters Table)を取得するかどうかを判定する。そして、受信機は、TPTを取得すると判定した場合、ネットワークを介してTPTサーバにアクセスし、TPTを要求する（Ｓ２）。
TPTサーバ（TPT Server）は、受信機からの要求に応じて、TPT（図中の「TPT」）を、ネットワークを介して受信機に送信する（Ｓ３）。受信機は、TPTサーバから送信されるTPTを受信して、保持する。そして、受信機は、送信機から送信されるトリガ情報を取得した場合、保持しているTPTを参照して、トリガ情報に含まれるイベントIDと、TPTに定義されたイベントIDとが一致する場合、そのイベントIDに対応する有効なコマンドを特定する。
受信機は、TPTを用いたコマンドの特定結果に従い、ネットワークを介してアプリケーションサーバにアクセスし、放送リレートアプリを要求する（Ｓ４）。アプリケーションサーバ（App Server）は、受信機からの要求に応じて、放送リレートアプリ（図中の「App」）を、ネットワークを介して受信機に送信する（Ｓ５）。受信機は、アプリケーションサーバから送信される放送リレートアプリを受信して起動する。
また、受信機では、送信機から送信されるトリガ情報が取得される度に、そのトリガ情報に対応するコマンドが、TPTによって順次特定される。そして、受信機において、実行中の放送リレートアプリは、特定されたコマンドに応じて、休止若しくは再開、又は、終了等の動作を実行することになる。
以上のように、受信機は、図２の「放送受信（AV再生＋放送リレートアプリ実行）」の状態に遷移した場合には、送信機からのトリガ情報に応じて、TPTサーバとアプリケーションサーバとの連携動作を行うことで、再生中のAVコンテンツとともに実行される放送リレートアプリを取得して実行する。
（トリガ情報とTPTの対応）
図４は、放送リレートアプリの動作を制御するトリガ情報とTPTの対応を示す図である。
図４において、受信機では、放送ストリームからトリガ情報が取得されると、トリガ情報に基づいて、TPTサーバからTPTを取得するか否かが判定される。ここで、図４のトリガ情報に含まれる"program1"には、domain_nameとprogram_idからなるURL(Uniform Resource Locator)が指定されているので、例えばprogram_idの値が変化したときに、TPTを取得すると判定される。
受信機は、TPTを取得すると判定した場合、domain_nameとprogram_idからなるURLに従い、ネットワークを介してTPTサーバにアクセスして、TPTを取得する。これにより、受信機は、更新後のTPT（図４）を保持することになる。
図４のTPTには、説明の簡略化のため、TPTを構成する一部の要素と属性のみを示している。すなわち、図４のTPTにおいては、アプリケーションID（AppID）により識別される放送リレートアプリごとに、イベントID（ID）により識別されるコマンド（例えば、"Prep"、"Exec"、"Susp"、"Kill"）が定義されている。
ここで、例えば、受信機において、イベントID（ID）="1"のトリガ情報が取得された場合、TPTを参照することで、イベントID（ID）="1"に対応した放送リレートアプリ（アプリケーションID="1"）に対するプリペアコマンド（"Prep"）が特定される。受信機は、プリペアコマンドに応じて、ネットワークを介してアプリケーションサーバにアクセスして、放送リレートアプリを取得して登録する。
また、受信機において、イベントID（ID）="2"のトリガ情報が取得された場合、TPTを参照することで、イベントID（ID）="2"に対応した放送リレートアプリ（アプリケーションID="1"）に対応するエクスキュートコマンド（"Exec"）が特定される。受信機は、エクスキュートコマンドに応じて、取得済みの放送リレートアプリを起動する。
さらに、受信機において、イベントID（ID）="4"のトリガ情報が取得された場合、TPTを参照することで、イベントID（ID）="4"に対応した放送リレートアプリ（アプリケーションID="1"）に対応するキルコマンド（"Kill"）が特定される。受信機は、キルコマンドに応じて、実行中の放送リレートアプリを終了する。
以上のように、受信機においては、放送ストリームからトリガ情報が取得される度に、トリガ情報に応じたコマンドがTPTより順次特定され、特定されたコマンドに従い、放送リレートアプリの動作が制御される。
（放送リレートアプリ用のTPTの記述例）
図５は、図４の放送リレートアプリ用のTPTの記述例を示す図である。
図５においては、tpt要素のid属性には、"abc.tv/300"が指定される。例えば、この記述は、abc放送局（domain_name="abc.tv"）により放送されるAVコンテンツ（program_id="300"）用のTPTであることを意味する。また、tptVersion属性には、TPTのバージョンとして、"1"が指定されている。
また、このtpt要素中には、２つのApplication要素が記述されている。１つ目のApplication要素により指定される放送リレートアプリには、appID属性によりアプリケーションID="1"が指定され、globalID属性によりグローバルID="abc.tv/100"が指定されている。なお、グローバルIDは、グローバルに識別可能なURI（Uniform Resource Identifier）により指定される。
Application要素にはまた、URL要素が記述されており、放送リレートアプリの取得先のURLとして、"http://abc.com/app1"が指定されている。また、URL要素のentry属性には、"true"が指定されているので、このURLがエントリされていることを示す。Application要素の開始タグと終了タグの間には、複数のEvent要素が記述されている。各Event要素には、eventID属性とaction属性がそれぞれ記述される。
１つ目のEvent要素には、eventID属性によりイベントID="1"が指定され、action属性によりプリペアコマンド（"prep"）が指定されている。すなわち、図５のTPTには、イベントID="1"であるトリガ情報に対して、アプリケーションID="1"である放送リレートアプリ用のプリペアコマンドが定義されている。
２つ目のEvent要素には、eventID属性によりイベントID="2"が指定され、action属性によりエクスキュートコマンド（"exec"）が指定されている。すなわち、図５のTPTには、イベントID="2"であるトリガ情報に対して、アプリケーションID="1"である放送リレートアプリ用のエクスキュートコマンドが定義されている。
３つ目のEvent要素には、eventID属性によりイベントID="3"が指定され、action属性によりサスペンドコマンド（"susp"）が指定されている。すなわち、図５のTPTには、イベントID="3"であるトリガ情報に対して、アプリケーションID="1"である放送リレートアプリ用のサスペンドコマンドが定義されている。
４つ目のEvent要素には、eventID属性によりイベントID="4"が指定され、action属性によりキルコマンド（"kill"）が指定されている。すなわち、図５のTPTには、イベントID="4"であるトリガ情報に対して、アプリケーションID="1"である放送リレートアプリ用のキルコマンドが定義されている。
また、２つ目のApplication要素により指定される放送リレートアプリには、appID属性によりアプリケーションID="2"が指定され、globalID属性によりグローバルID="abc.tv/101"が指定されている。また、URL要素によって、放送リレートアプリの取得先のURLとして、"http://abc.com/app2"が指定されている。Application要素の開始タグと終了タグの間には、複数のEvent要素が記述されている。
１つ目のEvent要素には、eventID属性によりイベントID="11"が指定され、action属性によりエクスキュートコマンド（"exec"）が指定されている。すなわち、図５のTPTには、イベントID="11"であるトリガ情報に対して、アプリケーションID="2"である放送リレートアプリ用のエクスキュートコマンドが定義されている。
２つ目のEvent要素には、eventID属性によりイベントID="12"が指定され、action属性によりキルコマンド（"kill"）が指定されている。すなわち、図５のTPTには、イベントID="12"であるトリガ情報に対して、アプリケーションID="2"である放送リレートアプリ用のキルコマンドが定義されている。
（放送リレートアプリ用のTPTのシンタックス）
図６は、放送リレートアプリ用のTPTのシンタックスの例を示す図である。図６のTPTは、例えば、XML（Extensible Markup Language）などのマークアップ言語により記述される。
図６において、TPTのルート要素には、TPT要素が記述される。TPT要素には、放送リレートアプリの動作を制御するためのイベントなどの情報が記述される。
TPT要素は、majorProtocolVersion属性、minorProtocolVersion属性、id属性、tptVersion属性、expireDate属性、updatingTime属性、serviceId属性、baseURL属性、Capabilities要素、LiveTrigger要素、及び、Application要素の上位要素となる。
majorProtocolVersion属性には、TPTに定義された仕様のメジャーバージョンを示す情報が指定される。minorProtocolVersion属性には、TPTに定義された仕様のマイナーバージョンを示す情報が指定される。
id属性には、TPTを識別するためのIDが指定される。例えば、id属性には、domain_nameと、program_idとを"/"により連結した文字列が指定される。ただし、program_idは、segment_idに対応するものであって、AVコンテンツを識別可能なIDとされる。
tptVersion属性には、TPTのバージョンを示す情報が指定される。expireDate属性には、TPTの有効期限を示す情報が指定される。updatingTime属性には、TPTの更新期間を示す情報が指定される。
serviceId属性には、デジタル放送信号により伝送されるサービスのうち、放送リレートアプリが、どのサービスで伝送されるかを示すサービスIDが指定される。例えば、放送リレートアプリがNRTサービスで伝送される場合、serviceId属性には、NRTサービスのサービスIDが指定される。
なお、NRT（Non-RealTime）サービスとは、FLUTE(File Delivery over Unidirectional Transport)セッションを利用して伝送されるNRTコンテンツを、一旦受信機のストレージに蓄積させた後で、再生を行わせるサービスである。アプリケーション伝送においてNRTサービスを利用する場合には、NRTコンテンツの代わりに、放送リレートアプリが伝送されることになる。
baseURL属性には、TPT内で指定されるURLのベースとなるURLが指定される。すなわち、当該TPTで指定される他のURLには、ベースURLを基準とした場合の相対的なパスを指定すればよいことになる。
Capabilities要素には、TPTを利用する場合に、受信機に要求される機能を示す情報が指定される。すなわち、受信機は、Capabilities要素に指定された機能を有する場合に、そのTPTを利用可能であると判断する。一方、受信機は、Capabilities要素に指定された機能を有しない場合には、そのTPTを無視する。
LiveTrigger要素は、TPT要素の子要素であって、AVコンテンツをライブ放送する場合に、放送事業者等が、所望のタイミングでイベントを実行させるためのトリガ情報に関する情報が記述される。つまり、当該トリガ情報は、アクティブ・トリガ情報（Activation Trigger）であると言える。liveTrigger要素は、URL属性、及び、pollPeriod属性を含む。
URL属性には、トリガ情報を提供するトリガサーバにアクセスするためのURLが記述される。pollPeriod属性には、トリガ情報を、トリガサーバに問い合わせる間隔を示す時間が指定される。この時間は、例えば、秒単位で指定される。
Application要素は、TPT要素の子要素であって、放送リレートアプリに関する情報が記述される。Application要素は、appID属性、appType属性、appName属性、globalId属性、appVersion属性、cookieSpace属性、frequencyOfUse属性、expireDate属性、testApp属性、availInternet属性、availBroadcast属性、URL要素、Capabilities要素、ApplicationBoundary要素、ContentItem要素、及び、Event要素の上位要素となる。
appID属性には、放送リレートアプリを識別するためのアプリケーションIDが指定される。appType属性には、放送リレートアプリのファイル属性等に関する情報が指定される。appName属性には、放送リレートアプリの名称を示す情報が指定される。例えば、複数の放送リレートアプリが起動可能である場合に、それらの名称をユーザに提示して選択させることで、所望の放送リレートアプリが起動されるようにする。
globalId属性には、放送リレートアプリをグローバルに識別可能なグローバルIDが指定される。グローバルIDは、例えばURIにより指定される。appVersion属性には、放送リレートアプリのバージョンを示す情報が指定される。cookieSpace属性には、放送リレートアプリを実行する際に必要となるストレージの容量を示す情報が指定される。
frequencyOfUse属性には、放送リレートアプリがどれくらいの頻度で利用されるかを示す情報が指定される。例えば、この利用頻度は、時間単位や日単位で指定され、利用頻度が高い放送リレートアプリを、優先的にキャッシュすることができる。expireDate属性には、放送リレートアプリの有効期限を示す情報が指定される。
testApp属性は、放送リレートアプリが、例えば製品開発のテスト目的で使用される場合に指定される。従って、通常の運用においては、testApp属性は無視される。availInternet属性には、放送リレートアプリが、インターネット配信されるか否かを示す情報が指定される。availBroadcast属性には、放送リレートアプリが、放送配信されるか否かを示す情報が指定される。
URL要素には、放送リレートアプリの取得先を示すURLが指定される。例えば、URL要素には、アプリケーションサーバのURLが指定される。ただし、前述のベースURLが指定されている場合には、ベースURLを基準とした場合の相対的なパスが指定されることになる。
URL要素は、entry属性の上位要素となる。entry属性には、URLがエントリされているか否かを示す情報が指定される。例えば、URL要素により複数のURLが指定されている場合に、index.htmlなどの最初に取得する必要のあるファイルをエントリしておくことで、それに関連するリソースを一括して取得することができる。
Capabilities要素には、放送リレートアプリを実行するに際し、受信機に要求される機能を示す情報が指定される。すなわち、受信機は、Capabilities要素に指定された機能を有する場合に、放送リレートアプリを実行可能であると判断する。
ApplicationBoundary要素は、放送リレートアプリが動作可能なURLの範囲を示す情報が指定される。ApplicationBoundary要素は、OriginURL要素の上位要素となる。OriginURL要素は、放送リレートアプリが動作可能なURLが指定される。
ContentItem要素は、Application要素の子要素であって、放送リレートアプリを構成するファイル（例えば、HTMLファイルやJPEGファイルなど）のキャッシュに関する情報が記述される。ContentItem要素は、URL要素、updatesAvail要素、pollPeriod属性、size属性、availInternet属性、及び、availBroadcast属性の上位要素となる。
URL属性には、キャッシュされるファイルのURLが指定される。URL要素は、entry属性の上位要素となる。entry属性には、URLがエントリされているか否かを示す情報が指定される。updatesAvail属性には、キャッシュされるファイルの更新に関する情報が指定される。pollPeriod属性には、キャッシュされるファイルをサーバに問い合わせる間隔を示す時間が指定される。
size属性には、キャッシュされるファイルのサイズを示す情報が指定される。availInternet属性には、キャッシュされるファイルが、インターネット配信されるか否かを示す情報が指定される。availBroadcast属性には、キャッシュされるファイルが、放送配信されるか否かを示す情報が指定される。
Event要素は、Application要素の子要素であって、放送リレートアプリの動作を制御するためのイベント情報が記述される。Event要素は、eventId属性、action属性、destination属性、diffusion属性、及び、Data要素の上位要素となる。
eventId属性には、イベントを識別するためのイベントIDが指定される。action属性には、イベントIDにより指定されるコマンドとして、"prep"、"exec"、"susp"、"kill"などが指定される。
プリペアコマンド（"prep"：prepare command）は、放送リレートアプリの取得又は登録を指示するためのコマンドである。ここで、放送リレートアプリの登録とは、取得した放送リレートアプリに対応付けて、その優先度と有効期限を記憶することを意味する。
エクスキュートコマンド（"exec"：execute command）は、放送リレートアプリの取得又は起動を指示するためのコマンドである。また、エクスキュートコマンドは、指定された放送リレートアプリが休止している場合に、その放送リレートアプリの実行を再開させる。
サスペンドコマンド（"susp"：suspend command）は、実行中の放送リレートアプリを中断して、休止させるためのコマンドである。キルコマンド（"kill"：kill command）は、実行中の放送リレートアプリを終了させるためのコマンドである。
destination属性には、イベントによる放送リレートアプリの制御対象となる機器が指定される。ここでは、受信機のほか、例えば、受信機に外部機器が接続される場合には、その外部機器がイベントの対象機器として指定される。
diffusion属性には、受信機においてイベントを適用するタイミングを確率的に分散させるための情報が指定される。この情報を設定することにより、複数の受信機がアプリケーションサーバから放送リレートアプリを取得するに際し、そのアクセスが一時期に集中せず分散させることができる。
Data要素には、イベントを適用する際に参照されるデータが指定される。Data要素は、dataID属性の上位要素となる。dataID属性には、データを識別するためのデータIDが指定される。
なお、図６の放送リレートアプリ用のTPTのシンタックスは一例であって、運用に合わせて要素や属性の追加や削除を行ってもよい。例えば、TPT要素に、independent属性を追加して、TPTが、放送リレートアプリ用であるか、あるいは、後述のブロードキャストインディペンデントアプリケーション（放送インディペンデントアプリ）用であるかを示す情報が指定されるようにしてもよい。この場合、図６のTPTは、放送リレートアプリ用であるので、例えば、"0"が指定される。
また、図６において、出現数(Cardinality)であるが、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定され、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。また、"1..N"が指定された場合には、その要素又は属性は１以上指定され、"0..N"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。これらの出現数の意味は、後述する他のシンタックスでも同様とされる。
以上、デジタル放送信号を少なくとも受信することが可能な受信機で実行されるブロードキャストリレートアプリケーション（放送リレートアプリ）について説明した。
＜２．ブロードキャストインディペンデントアプリケーション＞
ブロードキャストインディペンデントアプリケーション（Broadcast Independent Application）は、例えばインターネット配信などの、放送局が放送波により提供する放送サービス以外の環境で取得されたアプリケーションである。ここでは、デジタル放送信号を受信するだけでなく、インターネット配信されるアプリケーションなどを受信可能な受信機により実行されるブロードキャストインディペンデントアプリケーションについて説明する。
なお、このブロードキャストインディペンデントアプリケーションは、例えばHTMLファイルなどから構成される。以下、ブロードキャストインディペンデントアプリケーションは、「放送インディペンデントアプリ」と称して説明する。また、Broadcast Independent Applicationは、「Broadcast Independent App」と略記する場合がある。
（放送インディペンデントアプリの画面遷移）
図７は、放送インディペンデントアプリの画面遷移を示す図である。
図７においては、AVコンテンツのみが再生されている画面である「放送全画面」と、AVコンテンツとともに放送インディペンデントアプリが実行されている画面である「アプリ＋放送画面」の他に、「ポータル画面」、「アプリ画面」、及び、「アプリのみ表示画面」が示されている。
ここで、「ポータル画面」は、例えばアプリケーションストアなど、放送インディペンデントアプリを提供可能なポータルサイトが表示されている画面である。「アプリ画面」は、放送インディペンデントアプリが実行されている画面である。「アプリのみ表示画面」は、AVコンテンツの映像を表示させずに、放送インディペンデントアプリのみが表示されている画面である。
受信機においては、電源がオンされ、「ポータル画面」の表示が指示されると、「ポータル画面」が表示される。また、受信機では、「ポータル画面」に表示されたアイコンがユーザにより選択され、所望の放送インディペンデントアプリApp1の起動が指示された場合、選択された放送インディペンデントアプリApp1に対応した「アプリ画面」が表示される。
また、受信機は、実行中の放送インディペンデントアプリApp1によって、チャンネルＸの放送番組が選局された場合、選局されたチャンネルＸの放送番組の利用が認められるかどうかを判定する。すなわち、この判定処理では、放送局が放送波により提供する放送サービス以外の環境で取得された放送インディペンデントアプリが、放送サービスで提供される放送リソースを利用する場合に、その放送リソースの利用が認められるかどうかが判定されることになる。
放送インディペンデントアプリApp1によるチャンネルＸの放送番組の利用が認められる場合、受信機の画面は、「アプリ画面」から「アプリ＋放送画面１」に遷移する。この「アプリ＋放送画面１」は、チャンネルＸの放送番組の映像が縮小され、その余白部分に放送インディペンデントアプリApp1の情報が表示されたＬ字型画面となる。すなわち、チャンネルＸの放送番組の映像は、子画面表示となる。
なお、放送リソースの利用が認められた放送インディペンデントアプリは、放送番組等のAVコンテンツを提供している放送事業者により動作継続が認められた放送リレートアプリであるとも言える。当該放送インディペンデントアプリは、その後、放送リレートアプリとして動作する場合がある。
ここで、「アプリ＋放送画面１」を表示中に、ユーザによって、チャンネルがＸからＹに切り替えられた場合、放送インディペンデントアプリApp1によって、切り替え先のチャンネルＹの放送番組の利用が認められるかどうかが判定される。放送インディペンデントアプリApp1によるチャンネルＹの放送番組の利用が認められる場合、受信機の画面は「アプリ＋放送画面１」から「アプリ＋放送画面２」に遷移して、その画面内に子画面表示されている映像が、チャンネルＸの放送番組の映像から、チャンネルＹの放送番組の映像に切り替えられる。すなわち、チャンネルＹの放送番組の映像は、子画面表示となる。
このように、放送インディペンデントアプリによる放送リソースの利用が認められる場合、放送リソースと共存できるので、「アプリ＋放送画面」に遷移して、放送インディペンデントアプリとともに、放送リソースの映像が表示されることになる。他方、放送インディペンデントアプリによる放送リソースの利用が認められない場合には、遷移元の画面から、「アプリのみ表示画面」又は「放送全画面」に遷移することになる。以下、遷移元の画面から「アプリのみ表示画面」への遷移を、「ケースＡ（Case A）」と称し、遷移元の画面から「放送全画面」への遷移を、「ケースＢ（Case B）」と称して説明する。
図７において、「アプリ画面」を表示中に、放送インディペンデントアプリApp1によって、チャンネルＸの放送番組が選局された場合に、放送インディペンデントアプリApp1によるチャンネルＸの放送番組の利用が認められなかったとき、受信機の画面は、「アプリ画面」から、「アプリのみ表示画面」又は「放送全画面１」に遷移する。
ここで、受信機の画面が「アプリ画面」から「アプリのみ表示画面」に遷移した場合、すなわち、図中のケースＡの場合、「アプリのみ表示画面」は、Ｌ字型画面となって、放送インディペンデントアプリApp1の情報は表示されるが、子画面表示されるはずのチャンネルＸの放送番組の映像の代わりに、チャンネルＸの放送番組の映像を表示させることができない旨のメッセージが表示される。このように、放送インディペンデントアプリによる放送リソースの利用が認められなかった場合に表示される「アプリのみ表示画面」では、放送インディペンデントアプリと放送リソースは共存せず、放送リソースの利用が制限されることになる。
なお、図７において、「アプリのみ表示画面」は、Ｌ字型画面であるとして説明するが、例えば、コの字型画面やＵの字型画面の他、オーバーレイ表示画面など、放送リソースの映像を表示させずに、ユーザに放送リソースを利用できない旨を通知することができる画面であれば、他の表示形態を採用することができる。
また、受信機の画面が「アプリ画面」から「放送全画面１」に遷移した場合、すなわち、図中のケースＢの場合、「放送全画面」は、チャンネルＸの放送番組の映像を通常の大きさで表示して、放送インディペンデントアプリApp1は終了される。このように、放送インディペンデントアプリによる放送リソースの利用が認められなかった場合に表示される「放送全画面」では、放送インディペンデントアプリと放送リソースは共存せず、放送リソースの利用が制限されることになる。
同様に、「アプリ＋放送画面１」を表示中に、放送インディペンデントアプリApp1によって、チャンネルＹの放送番組が選局された場合に、放送インディペンデントアプリApp1によるチャンネルＹの放送番組の利用が認められなかったとき、受信機の画面は、「アプリ＋放送画面１」から、「アプリのみ表示画面」又は「放送全画面１」に遷移する。
ここで、受信機の画面が「アプリ＋放送画面１」から「アプリのみ表示画面」に遷移した場合、すなわち、図中のケースＡの場合、「アプリのみ表示画面」は、Ｌ字型画面となって、放送インディペンデントアプリApp1の情報は表示されるが、子画面表示されるはずのチャンネルＹの放送番組の映像の代わりに、チャンネルＹの放送番組の映像を表示させることができない旨のメッセージが表示される。
また、受信機の画面が「アプリ＋放送画面１」から「放送全画面１」に遷移した場合、すなわち、図中のケースＢの場合、「放送全画面１」は、チャンネルＸの放送番組の映像を通常の大きさで表示して、放送インディペンデントアプリApp1は終了される。なお、この場合の遷移先を、「放送全画面１」の代わりに、「放送全画面２」として、チャンネルＹの放送番組の映像を通常の大きさで表示するようにしてもよい。
このように、放送インディペンデントアプリによる放送リソースの利用が認められなかった場合に表示される「アプリのみ表示画面」又は「放送全画面」では、放送インディペンデントアプリと放送リソースは共存せず、放送リソースの利用が制限されることになる。
なお、「アプリ＋放送画面２」を表示中に、放送リレートアプリApp1の終了が指示された場合、放送リレートアプリApp1は終了され、その画面は、「アプリ＋放送画面２」から「ポータル画面」又は「放送全画面２」に遷移する。また、「アプリのみ表示画面」を表示中に、放送リレートアプリApp1の終了が指示された場合、放送リレートアプリApp1は終了され、その画面は、「アプリのみ表示画面」から「ポータル画面」又は「放送全画面１」に遷移する。ただし、この場合の遷移先を、「放送全画面１」の代わりに、「放送全画面２」としてもよい。
以上の画面遷移を行うことで、放送インディペンデントアプリによって、放送リソースが利用される場合に、放送リソースと共存できないときには、特定の放送インディペンデントアプリによる放送リソースの利用を制限することが可能となる。
例えば、放送インディペンデントアプリとして、ソーシャルネットワーキングサービス（SNS：Social Networking Service）のアプリケーションが起動されている場合に、当該アプリケーションによる、放送リソースの利用が認められなかったときには、ケースＡの「アプリのみ表示画面」を表示させることで、ソーシャルネットワーキングサービスのアプリケーションの表示を優先させることができる。
また、例えば、放送インディペンデントアプリとして、AVコンテンツの視聴をサポートするアプリケーションが起動されている場合に、当該アプリケーションによる、放送リソースの利用が認められなかったときには、ケースＢの「放送全画面」を表示させることで、AVコンテンツの表示を優先させることができる。
以下、図７の画面遷移を実現するための実施の形態として、第１の実施の形態と第２の実施の形態を順に説明する。
（１）第１の実施の形態
（システム全体の処理の流れ）
図８は、第１の実施の形態におけるシステム全体の処理の流れを示す図である。
図８においては、受信機、放送局の送信機、TPTサーバ、及び、アプリケーションサーバで実行される処理の流れが示されている。
受信機では、「ポータル画面」（図７）が表示されており（Ｓ１１）、「ポータル画面」から、ユーザにより放送インディペンデントアプリが選択される（Ｓ１２）。そして、放送インディペンデントアプリが選択されると、受信機は、TPTサーバにアクセスして、放送インディペンデントアプリ用のTPTを取得し、解析する（Ｓ１３，Ｓ１４）。
受信機は、放送インディペンデントアプリ用のTPTに基づいて、アプリケーションサーバにアクセスして、放送インディペンデントアプリを取得して起動する（Ｓ１５）。これにより、受信機では、「アプリ画面」（図７）が表示される。また、受信機では、実行中の放送インディペンデントアプリによって、放送サービス（例えば、放送番組）が選局された場合、放送ストリームで伝送されるトリガ情報を取得して解析する（Ｓ１７，Ｓ１８）。
受信機は、トリガ情報に基づいて、TPTサーバにアクセスして、放送リレートアプリ用のTPTを取得し、解析する（Ｓ１９，Ｓ２０）。そして、受信機は、放送インディペンデントアプリ用のTPT（Ｓ１３，Ｓ１４で取得・解析）の記述内容と、放送リレートアプリ用のTPT（Ｓ１９，Ｓ２０で取得・解析）の記述内容を比較することで、放送インディペンデントアプリの放送リソースを利用する動作の継続が認められるかどうかの動作継続可否判定処理を行う（Ｓ２１）。
具体的には、放送リレートアプリ用のTPTにおいて、放送サービスを選局した放送インディペンデントアプリと、グローバルIDが同一の値で、かつ、取得先のURL（ただし、entry="true"）も同一の値となる放送リレートアプリであって、その時点でのイベントに、エクスキュートコマンド（"exec"）が指定されている放送リレートアプリの記述がある場合には、当該放送インディペンデントアプリによる放送リソースの利用を認めるものとする。
ステップＳ２１の判定処理で、放送インディペンデントアプリによる放送リソースの利用が認められ、放送インディペンデントアプリの動作の継続が認められた場合、受信機では、「アプリ＋放送画面」（図７）が表示される。なお、このように、放送リレートアプリ用のTPTによって、動作継続が認められた放送インディペンデントアプリは、放送局（放送事業者）により動作継続が認められた放送リレートアプリであるとも言える。したがって、その後、当該放送インディペンデントアプリは、放送リレートアプリとして動作することになる。
また、上記の条件を満たさずに、放送インディペンデントアプリによる放送リソースの利用が認められなかった場合、受信機は、放送インディペンデントアプリ用のTPTに記述される、Application要素のcontext属性（後述する図１１又は図１２参照）に基づいて、ケースＡの「アプリのみ表示画面」（図７）、又は、ケースＢの「放送全画面」（図７）を表示する。
以上のように、第１の実施の形態においては、放送インディペンデントアプリによって、放送リソースが利用される場合に、放送インディペンデントアプリ用のTPTの記述内容と、放送リレートアプリ用のTPTの記述内容が照合される。そして、その照合の結果に応じて、放送リソースの利用が認められた場合には、「アプリ＋放送画面」（図７）が表示され、放送リソースの利用が認められない場合には、「アプリのみ表示画面」（図７）又は「放送全画面」（図７）が表示される。
これにより、放送インディペンデントアプリが、放送リソースの利用を認められない場合には、放送リソースを利用できないことになるため、特定の放送インディペンデントアプリによる、放送リソースの利用を制限することができる。
（受信機の状態遷移）
図９は、放送インディペンデントアプリを実行する受信機の状態遷移を示す図である。図９に示すように、受信機の状態は、「端末動作停止」、「放送受信（AVのみ再生）」、「放送受信（AV再生＋放送リレートアプリ実行）」、「ポータル表示」、又は、「放送インディペンデントアプリ実行」のうち、いずれかの状態に遷移していると定義される。
「端末動作停止」は、受信機の電源がオフされている状態を表している。「放送受信（AVのみ再生）」は、放送番組等のAVコンテンツのみが再生されている状態を表している。この状態に遷移した受信機では、「放送全画面」（図７）が表示される。
「放送受信（AV再生＋放送リレートアプリ実行）」は、AVコンテンツの再生とともに、放送リレートアプリ（放送インディペンデントアプリ）が実行されている状態を表している。すなわち、この状態は、放送リレートアプリが直接起動された場合だけでなく、放送インディペンデントアプリが放送リソースを利用する場合に、放送リレートアプリ用のTPTによって動作継続を認められ、実質的に放送リレートアプリとして動作している場合も含まれる。この状態に遷移した受信機では、「アプリ＋放送画面」（図７）が表示される。
「ポータル表示」は、放送インディペンデントアプリを選択可能なポータルサイトが表示されている状態を表している。この状態に遷移した受信機では、「ポータル画面」（図７）が表示される。「放送インディペンデントアプリ実行」は、放送インディペンデントアプリが実行されている状態、又は、AVコンテンツの利用が制限され、放送インディペンデントアプリのみが実行されている状態を表している。この状態に遷移した受信機では、「アプリ画面」又は「アプリのみ表示画面」（図７）が表示される。
受信機が「端末動作停止」の状態に遷移している場合に、電源がオンされると、その状態は、「放送受信（AVのみ再生）」の状態に遷移する。また、受信機が「放送受信（AVのみ再生）」の状態に遷移している場合に、放送リレートアプリが起動されると、その状態は、「放送受信（AV再生＋放送リレートアプリ実行）」の状態に遷移する。なお、受信機が「放送受信（AVのみ再生）」の状態に遷移している場合に、電源がオフされると、その状態は、「端末動作停止」の状態に遷移する。
受信機が「放送受信（AV再生＋放送リレートアプリ実行）」の状態に遷移している場合に、放送リレートアプリ実行が終了されると、その状態は、「放送受信（AVのみ再生）」の状態に遷移する。なお、受信機が「放送受信（AV再生＋放送リレートアプリ実行）」の状態に遷移している場合に、電源がオフされると、その状態は、「端末動作停止」の状態に遷移する。
また、受信機が「放送受信（AVのみ再生）」の状態に遷移している場合に、「ポータル画面」（図７）の表示が選択されると、その状態は、「ポータル表示」の状態に遷移する。受信機が「ポータル表示」の状態に遷移している場合に、放送インディペンデントアプリが起動されると、その状態は、「放送インディペンデントアプリ実行」の状態に遷移する。なお、受信機が「ポータル表示」の状態に遷移している場合に、放送表示が選択されると、その状態は「放送受信（AVのみ再生）」に遷移し、電源がオフされると、その状態は「端末動作停止」の状態に遷移する。
受信機が「放送インディペンデントアプリ実行」の状態に遷移している場合に、放送インディペンデントアプリにより放送選局用のAPI(Application Programming Interface)が実行され、放送リソースを利用するときには、その状態は、「放送受信（AV再生＋放送リレートアプリ実行）」の状態に遷移する。すなわち、この場合、放送リレートアプリ用のTPTを用いて、放送インディペンデントアプリの動作継続可否判定処理が実行され、動作継続が認められた場合には、「放送受信（AV再生＋放送リレートアプリ実行）」の状態に留まり、放送インディペンデントアプリは、いわば、放送リレートアプリとして動作を継続する。
それに対し、動作継続可否判定処理により動作継続が認められなかった場合には、その状態は、「放送インディペンデントアプリ実行」の状態、又は、「放送受信（AVのみ再生）」の状態に遷移する。すなわち、この場合、放送インディペンデントアプリによる放送リソースの利用が認められなかったので、ケースＡの場合には、受信機は、「放送インディペンデントアプリ実行」の状態に遷移して、「アプリのみ表示画面」（図７）を表示する。また、ケースＢの場合には、受信機は、「放送受信（AVのみ再生）」の状態に遷移して、「放送全画面」（図７）を表示する。
なお、受信機が「放送インディペンデントアプリ実行」の状態に遷移している場合に、放送インディペンデントアプリが終了されると、その状態は、「ポータル表示」の状態に遷移する。また、受信機が「放送インディペンデントアプリ実行」の状態に遷移している場合に、電源がオフされると、その状態は、「端末動作停止」の状態に遷移する。
（受信機の動作）
図１０は、放送インディペンデントアプリを実行する受信機の動作を示す図である。
図１０において、受信機は、ポータルサイトの表示が指示された場合、ネットワークを介してポータルサーバにアクセスし、ポータルサイトのウェブページを要求する（Ｓ３１）。ポータルサーバは、受信機からの要求に応じて、ポータルサイトのウェブページを、ネットワークを介して受信機に送信する（Ｓ３２）。受信機は、ポータルサーバから受信したポータルサイトのウェブページを表示する。
受信機では、ポータルサイトから放送インディペンデントアプリが選択された場合、ネットワークを介してTPTサーバにアクセスし、放送インディペンデントアプリ用のTPTを要求する（Ｓ３３）。TPTサーバは、受信機からの要求に応じて、放送インディペンデントアプリ用のTPT（図中の「TPT」）を、ネットワークを介して受信機に送信する（Ｓ３４）。受信機は、TPTサーバから送信される放送インディペンデントアプリ用のTPTを受信して、保持する。
そして、受信機は、放送インディペンデントアプリ用のTPTに基づいて、ネットワークを介してアプリケーションサーバにアクセスし、放送インディペンデントアプリを要求する（Ｓ３５）。アプリケーションサーバは、受信機からの要求に応じて、放送インディペンデントアプリ（図中の「App」）を、ネットワークを介して受信機に送信する（Ｓ３６）。受信機は、アプリケーションサーバから送信される放送インディペンデントアプリを受信して起動する。
ここで、受信機は、実行中の放送インディペンデントアプリによって、放送サービス（例えば、放送番組）が選局された場合、放送局の送信機によって、AVコンテンツ（図中の「Content」）とともに送信されるトリガ情報（図中の「Trigger」）を取得する（Ｓ３７）。
受信機は、トリガ情報に基づいて、ネットワークを介してTPTサーバにアクセスし、放送リレートアプリ用のTPTを要求する（Ｓ３８）。TPTサーバは、受信機からの要求に応じて、放送リレートアプリ用のTPT（図中の「TPT」）を、ネットワークを介して受信機に送信する（Ｓ３９）。受信機は、TPTサーバから送信される放送リレートアプリ用のTPTを受信して取得する。
そして、受信機は、放送インディペンデントアプリ用のTPTと、放送リレートアプリ用のTPTに基づいて、放送インディペンデントアプリによる放送リソースを利用する動作の継続が認められるかどうかの動作継続可否判定処理を行う。
動作継続可否判定処理によって、放送インディペンデントアプリによる放送リソースの利用が認められた場合、受信機は、図９の「放送受信（AV再生＋放送リレートアプリ実行）」の状態に遷移して、放送インディペンデントアプリは、放送リレートアプリとして動作を継続する。この場合、受信機では、「アプリ＋放送画面」（図７）が表示される。
他方、放送インディペンデントアプリによる放送リソースの利用が認められなかった場合、受信機は、図９の「放送インディペンデントアプリ実行」の状態、又は、図９の「放送受信（AVのみ再生）」の状態に遷移して、ケースＡの「アプリのみ表示画面」（図７）、又は、ケースＢの「放送全画面」（図７）を表示する。
なお、図１０においては、説明の都合上、放送インディペンデントアプリ用のTPTと、放送リレートアプリ用のTPTは、同一のTPTサーバにより提供されるとして説明したが、実際には、放送リレートアプリ用のTPTは放送事業者により提供され、放送インディペンデントアプリ用のTPTは、サードパーティ等の放送事業者以外の事業者により提供されることが想定されるため、それらのTPTが異なるTPTサーバにより提供されるようにしてもよい。
（放送インディペンデントアプリ用のTPTの記述例）
図１１は、放送インディペンデントアプリ用のTPTの記述例を示す図である。
図１１において、tpt要素のid属性には、"abc.tv/300"が指定され、tptVersion属性には、"1"が指定されている。また、tpt要素において、independent属性には、"1"が指定されているので、図１１のTPTは、放送インディペンデントアプリ用のTPTであることを示している。
tpt要素には、１つのApplication要素が記述されている。このApplication要素のappID属性とglobalID属性によって、放送インディペンデントアプリには、アプリケーションID="1"と、グローバルID="abc.tv/100"が指定されている。また、context属性として、"app"が指定されているので、放送インディペンデントアプリによる放送リソースの利用が認められなかった場合に、受信機が、放送インディペンデントアプリの動作を継続して、ケースＡの「アプリのみ表示画面」（図７）を表示することを示している。
Application要素にはまた、URL要素が記述されており、放送インディペンデントアプリの取得先のURLとして、"http://abc.com/app1"が指定されている。また、URL要素のentry属性には、"true"が指定されているので、このURLがエントリされていることを示している。
（放送インディペンデントアプリ用のTPTのシンタックス）
図１２は、放送インディペンデントアプリ用のTPTのシンタックスの例を示す図である。図１２のTPTは、例えば、XMLなどのマークアップ言語により記述される。
図１２において、TPTのルート要素には、TPT要素が記述される。TPT要素には、放送インディペンデントアプリ用を取得するための情報等が記述される。
TPT要素は、majorProtocolVersion属性、minorProtocolVersion属性、id属性、independent属性、tptVersion属性、expireDate属性、baseURL属性、Capabilities要素、及び、Application要素の上位要素となる。
majorProtocolVersion属性には、TPTに定義された仕様のメジャーバージョンを示す情報が指定される。minorProtocolVersion属性には、TPTに定義された仕様のマイナーバージョンを示す情報が指定される。id属性には、TPTを識別するためのIDが指定される。
independent属性には、TPTが、放送リレートアプリ用であるか、あるいは、放送インディペンデントアプリ用であるかを示す情報が指定される。図１２のTPTは、放送インディペンデントアプリ用であるので、"1"が指定される。
tptVersion属性には、TPTのバージョンを示す情報が指定される。expireDate属性には、TPTの有効期限を示す情報が指定される。baseURL属性には、TPT内で指定されるURLのベースとなるURLが指定される。従って、当該TPTで指定される他のURLには、ベースURLを基準とした場合の相対的なパスを指定すればよい。
Capabilities要素には、TPTを利用する場合に、受信機に要求される機能を示す情報が指定される。すなわち、受信機は、Capabilities要素に指定された機能を有する場合に、そのTPTを利用可能であると判断する。
Application要素は、TPT要素の子要素であって、放送インディペンデントアプリに関する情報が記述される。Application要素は、appID属性、appType属性、appName属性、globalId属性、appVersion属性、cookieSpace属性、expireDate属性、context属性、URL要素、ApplicationBoundary要素、及び、ContentItem要素の上位要素となる。
appID属性には、放送インディペンデントアプリを識別するためのアプリケーションIDが指定される。appType属性には、放送インディペンデントアプリのファイル属性等に関する情報が指定される。appName属性には、放送インディペンデントアプリの名称を示す情報が指定される。
globalId属性には、放送インディペンデントアプリをグローバルに識別可能なグローバルIDが指定される。グローバルIDは、例えばURIにより指定される。appVersion属性には、放送インディペンデントアプリのバージョンを示す情報が指定される。cookieSpace属性には、放送インディペンデントアプリを実行する際に必要となるストレージの容量を示す情報が指定される。expireDate属性には、放送インディペンデントアプリの有効期限を示す情報が指定される。
context属性には、放送インディペンデントアプリによる放送リソースの利用が認められなかった場合に、放送インディペンデントアプリの動作を継続するか否かを示す情報が指定される。例えば、context属性として、"app"が指定された場合、放送インディペンデントアプリの動作を継続して、ケースＡの「アプリのみ表示画面」（図７）が表示されるようにする。また、context属性として、"broadcast"が指定された場合、放送インディペンデントアプリを終了して、ケースＢの「放送全画面」（図７）が表示されるようにする。
URL要素には、放送インディペンデントアプリの取得先を示すURLが指定される。例えば、URL要素には、アプリケーションサーバのURLが指定される。URL要素は、entry属性の上位要素となる。entry属性には、URLがエントリされているか否かを示す情報が指定される。例えば、URL要素により複数のURLが指定されている場合に、index.htmlなどの最初に取得する必要のあるファイルをエントリしておくことで、それに関連するリソースを一括して取得することができる。
ApplicationBoundary要素は、放送インディペンデントアプリが動作可能なURLの範囲を示す情報が指定される。ApplicationBoundary要素は、OriginalURL要素の上位要素となる。OriginalURL要素は、放送インディペンデントアプリが動作可能なURLが指定される。
ContentItem要素は、放送インディペンデントアプリを構成するファイル（例えば、HTMLファイルやJPEGファイルなど）のキャッシュに関する情報が記述される。ContentItem要素は、URL要素、及び、size属性の上位要素となる。URL属性には、キャッシュされるファイルのURLが指定される。URL要素は、entry属性の上位要素となる。entry属性には、URLがエントリされているか否かを示す情報が指定される。size属性には、キャッシュされるファイルのサイズを示す情報が指定される。
なお、図１２の放送インディペンデントアプリ用のTPTのシンタックスは一例であって、運用に合わせて要素や属性の追加や削除を行ってもよい。
また、図１２の放送インディペンデントアプリ用のTPTと、図６の放送リレートアプリ用のTPTを比較すれば、放送インディペンデントアプリ用のTPTは、independent属性と、Application要素のcontext属性が追加されているが、放送リレートアプリ用のTPTのサブセットとなっている。また、図１２の放送インディペンデントアプリ用のTPTは、特定の放送インディペンデントアプリ用となるため、１つのApplication要素のみが記述され、さらに、コマンドが、エクスキュートコマンド（"exec"）のみとされるので、イベントに関する記述が省かれている。
（２）第２の実施の形態
（システム全体の処理の流れ）
図１３は、第２の実施の形態におけるシステム全体の処理の流れを示す図である。
図１３においては、受信機、放送局の送信機、TPTサーバ、及び、アプリケーションサーバで実行される処理の流れが示されている。
受信機では、「ポータル画面」（図７）が表示されており（Ｓ４１）、ポータル画面から、ユーザにより放送インディペンデントアプリが選択される（Ｓ４２）。そして、放送インディペンデントアプリが選択されると、受信機は、TPTサーバにアクセスして、放送インディペンデントアプリ用のTPTを取得する（Ｓ４３）。
受信機は、放送局公開鍵証明書をあらかじめ保持しており、この放送局公開鍵証明書を用いて、放送インディペンデントアプリ用のTPTに記述された電子署名を検証する（Ｓ４４）。受信機は、ステップＳ４４の電子署名の検証に成功した場合、放送インディペンデントアプリ用のTPTに基づいて、アプリケーションサーバにアクセスして、放送インディペンデントアプリを取得して起動する（Ｓ４５）。これにより、受信機では、「アプリ画面」（図７）が表示される。
その後、実行中の放送インディペンデントアプリによって、放送サービスの選局等の放送リソースへのアクセス要求が発生した場合（Ｓ４６）、受信機は、放送インディペンデントアプリ用のTPTに基づいて、放送インディペンデントアプリによる放送リソースの利用を認めるかどうかのアクセス可否判定処理を行う（Ｓ４７）。
具体的には、アクセス可否判定処理では、放送インディペンデントアプリ用のTPTにおいて、例えば、放送局（放送サービス）ごとのアクセス権限（以下、「放送パーミッション情報」ともいう。）が記述されているので、放送サービスを選局した放送インディペンデントアプリが、選局を指示した放送サービスのアクセス権限を有しているかどうかが判定される。
ステップＳ４７の判定処理で、放送インディペンデントアプリが、放送サービスのアクセス権限を有していると判定された場合、放送インディペンデントアプリによる放送リソースの利用が認められ、受信機では、「アプリ＋放送画面」（図７）が表示される。
また、ステップＳ４７の判定処理で、放送インディペンデントアプリが、放送サービスのアクセス権限を有していないと判定された場合、放送インディペンデントアプリによる放送リソースの利用は認められない。この場合、受信機は、放送インディペンデントアプリ用のTPTに記述される、Application要素のcontext属性（後述する図１６又は図１７参照）に基づいて、ケースＡの「アプリのみ表示画面」（図７）、又は、ケースＢの「放送全画面」（図７）を表示する。
以上のように、第２の実施の形態においては、放送インディペンデントアプリによって、放送リソースが利用される場合に、放送インディペンデントアプリ用のTPTに記述された放送パーミッション情報を用い、当該放送インディペンデントアプリが、放送サービスのアクセス権限を有しているかどうかが判定される。そして、放送リソースへのアクセス権限を有している場合には、「アプリ＋放送画面」（図７）が表示され、放送リソースへのアクセス権限を有していない場合には、「アプリのみ表示画面」（図７）又は「放送全画面」（図７）が表示される。
これにより、放送インディペンデントアプリが、放送リソースへのアクセス権限を有していない場合には、放送リソースを利用できないことになるため、特定の放送インディペンデントアプリによる、放送リソースの利用を制限することができる。
（受信機の状態遷移）
図１４は、放送インディペンデントアプリを実行する受信機の状態遷移を示す図である。図１４に示すように、受信機の状態は、「端末動作停止」、「放送受信（AVのみ再生）」、「放送受信（AV再生＋放送リレートアプリ実行）」、「ポータル表示」、「放送インディペンデントアプリ実行」、又は、「放送受信（AV再生＋放送インディペンデントアプリ実行）」のうち、いずれかの状態に遷移していると定義される。
「端末動作停止」は、受信機の電源がオフされている状態を表している。「放送受信（AVのみ再生）」は、放送番組等のAVコンテンツのみが再生されている状態を表している。この状態に遷移した受信機では、「放送全画面」（図７）が表示される。「放送受信（AV再生＋放送リレートアプリ実行）」は、AVコンテンツの再生とともに、放送リレートアプリが実行されている状態を表している。この状態に遷移した受信機では、「アプリ＋放送画面」（図７）が表示される。
「ポータル表示」は、放送インディペンデントアプリを選択可能なポータルサイトが表示されている状態を表している。この状態に遷移した受信機では、「ポータル画面」（図７）が表示される。
「放送インディペンデントアプリ実行」は、放送インディペンデントアプリが実行されている状態、又は、AVコンテンツの利用が制限され、放送インディペンデントアプリのみが実行されている状態を表している。この状態に遷移した受信機では、「アプリ画面」又は「アプリのみ表示画面」（図７）が表示される。
「放送受信（AV再生＋放送インディペンデントアプリ実行）」は、AVコンテンツの再生とともに、放送インディペンデントアプリが実行されている状態を表している。この状態に遷移した受信機では、「アプリ＋放送画面」（図７）が表示される。
受信機が「端末動作停止」の状態に遷移している場合に、電源がオンされると、その状態は、「放送受信（AVのみ再生）」の状態に遷移する。また、受信機が「放送受信（AVのみ再生）」の状態に遷移している場合に、放送リレートアプリが起動されると、その状態は、「放送受信（AV再生＋放送リレートアプリ実行）」の状態に遷移する。また、受信機が「放送受信（AV再生＋放送リレートアプリ実行）」の状態に遷移している場合、放送リレートアプリが終了されると、その状態は、「放送受信（AVのみ再生）」の状態に遷移する。
なお、受信機が「放送受信（AVのみ再生）」又は「放送受信（AV再生＋放送リレートアプリ実行）」の状態に遷移している場合に、電源がオフされると、その状態は、「端末動作停止」の状態に遷移する。
また、受信機が「放送受信（AVのみ再生）」の状態に遷移している場合に、「ポータル画面」（図７）の表示が選択されると、その状態は、「ポータル表示」の状態に遷移する。受信機が「ポータル表示」の状態に遷移している場合に、放送インディペンデントアプリが起動されると、その状態は、「放送インディペンデントアプリ実行」の状態に遷移する。なお、受信機が「ポータル表示」の状態に遷移している場合に、放送表示が選択されると、その状態は「放送受信（AVのみ再生）」に遷移し、電源がオフされると、その状態は「端末動作停止」の状態に遷移する。
受信機が「放送インディペンデントアプリ実行」の状態に遷移している場合に、放送選局用のAPIが実行され、放送リソースを利用するときには、その状態は、「放送受信（AV再生＋放送インディペンデントアプリ実行）」の状態に遷移する。すなわち、この場合、放送インディペンデントアプリ用のTPTを用いて、放送インディペンデントアプリの放送リソースに対するアクセス可否判定処理が実行され、アクセス権限を有している場合には、「放送受信（AV再生＋放送インディペンデントアプリ実行）」の状態に留まり、放送インディペンデントアプリとして動作を継続する。
それに対し、アクセス可否判定処理によりアクセス権限を有していない場合には、その状態は、その状態は、「放送インディペンデントアプリ実行」の状態、又は、「放送受信（AVのみ再生）」の状態に遷移する。すなわち、この場合、放送インディペンデントアプリによる放送リソースの利用が認められなかったので、ケースＡの場合には、受信機は、「放送インディペンデントアプリ実行」の状態に遷移して、「アプリのみ表示画面」（図７）を表示する。また、ケースＢの場合には、受信機は、「放送受信（AVのみ再生）」の状態に遷移して、「放送全画面」（図７）を表示する。
なお、受信機が「放送インディペンデントアプリ実行」の状態に遷移している場合に、放送インディペンデントアプリが終了されると、その状態は、「ポータル表示」の状態に遷移する。また、受信機が「放送インディペンデントアプリ実行」又は「放送受信（AV再生＋放送インディペンデントアプリ実行）」の状態に遷移している場合に、電源がオフされると、その状態は、「端末動作停止」の状態に遷移する。
（受信機の動作）
図１５は、放送インディペンデントアプリを実行する受信機の動作を示す図である。
図１５において、受信機は、ポータルサイトの表示が指示された場合、ネットワークを介してポータルサーバにアクセスし、ポータルサイトのウェブページを要求する（Ｓ５１）。ポータルサーバは、受信機からの要求に応じて、ポータルサイトのウェブページを、ネットワークを介して受信機に送信する（Ｓ５２）。受信機は、ポータルサーバから受信したポータルサイトのウェブページを表示する。
受信機では、ポータルサイトから放送インディペンデントアプリが選択された場合、ネットワークを介してTPTサーバにアクセスし、放送インディペンデントアプリ用のTPTを要求する（Ｓ５３）。TPTサーバは、受信機からの要求に応じて、放送インディペンデントアプリ用のTPT（図中の「TPT」）を、ネットワークを介して受信機に送信する（Ｓ５４）。受信機は、TPTサーバから送信される放送インディペンデントアプリ用のTPTを受信して、保持する。
受信機は、あらかじめ保持している放送局公開鍵証明書を用い、放送インディペンデントアプリ用のTPTに記述された電子署名を検証する。そして、受信機は、電子署名の検証に成功した場合には、放送インディペンデントアプリ用のTPTに基づいて、アプリケーションサーバにアクセスし、放送インディペンデントアプリを要求する（Ｓ５５）。アプリケーションサーバは、受信機からの要求に応じて、放送インディペンデントアプリ（図中の「App」）を、ネットワークを介して受信機に送信する（Ｓ５６）。受信機は、アプリケーションサーバから送信される放送インディペンデントアプリを受信して起動する。
ここで、受信機は、実行中の放送インディペンデントアプリによって、放送サービスの選局等の放送リソースへのアクセス要求が発生した場合、放送インディペンデントアプリ用のTPTに記述された放送パーミッション情報に基づいて、放送インディペンデントアプリが、選局を指示した放送リソースへのアクセス権限を有しているかどうかのアクセス可否判定処理を行う。
アクセス可否判定処理によって、放送インディペンデントアプリによる放送リソースへのアクセス権限が認められた場合、受信機は、図１４の「放送受信（AV再生＋放送インディペンデントアプリ実行）」の状態に遷移して、「アプリ＋放送画面」（図７）を表示する。他方、放送インディペンデントアプリによる放送リソースへのアクセス権限が認められなかった場合、受信機は、図１４の「放送インディペンデントアプリ実行」の状態、又は、図１４の「放送受信（AVのみ再生）」の状態に遷移して、ケースＡの「アプリのみ表示画面」（図７）、又は、ケースＢの「放送全画面」（図７）を表示する。
（放送インディペンデントアプリ用のTPTの記述例）
図１６は、放送インディペンデントアプリ用のTPTの記述例を示す図である。
図１６において、tpt要素のid属性には、"abc.tv/300"が指定され、tptVersion属性には、"1"が指定されている。また、tpt要素において、independent属性には、"1"が指定されているので、図１６のTPTは、放送インディペンデントアプリ用のTPTであることを示している。
tpt要素には、Application要素とSignature要素が記述されている。このApplication要素のappID属性とglobalID属性によって、放送インディペンデントアプリには、アプリケーションID="1"と、グローバルID="abc.tv/100"が指定されている。また、context属性として、"app"が指定されているので、放送インディペンデントアプリによる放送リソースへのアクセス権が認められなかった場合に、受信機が、放送インディペンデントアプリの動作を継続して、ケースＡの「アプリのみ表示画面」（図７）を表示することを示している。
Application要素にはまた、BroadcastPermission要素とURL要素が記述されている。BroadcastPermission要素では、Permission要素によって、放送リソースごとのアクセス権限として、"8000"が指定されているので、受信機では、この放送パーミッション情報を用いて、インディペンデントアプリが、RFチャンネルIDが"128"である放送局の放送サービスへのアクセス権限を有しているかどうかのアクセス可否判定処理が行われる。
URL要素には、放送インディペンデントアプリの取得先のURLとして、"http://abc.com/app1"が指定されている。また、URL要素のentry属性には、"true"が指定されているので、このURLがエントリされていることを示している。
Signature要素には、署名情報として、図１６のTPTを受信した受信機で実行される、放送局公開鍵証明書を用いた検証処理で用いられる電子署名が記述される。
（放送インディペンデントアプリ用のTPTのシンタックス）
図１７は、放送インディペンデントアプリ用のTPTのシンタックスの例を示す図である。図１７のTPTは、例えば、XMLなどのマークアップ言語により記述される。
図１７において、TPTのルート要素には、TPT要素が記述される。TPT要素には、放送インディペンデントアプリ用を取得するための情報の他、検証処理やアクセス可否判定処理等で用いられる情報などが記述される。
TPT要素は、majorProtocolVersion属性、minorProtocolVersion属性、id属性、independent属性、tptVersion属性、expireDate属性、baseURL属性、Capabilities要素、Application要素、及び、Signature要素の上位要素となる。
majorProtocolVersion属性には、TPTに定義された仕様のメジャーバージョンを示す情報が指定される。minorProtocolVersion属性には、TPTに定義された仕様のマイナーバージョンを示す情報が指定される。id属性には、TPTを識別するためのIDが指定される。
independent属性には、TPTが、放送リレートアプリ用であるか、あるいは、放送インディペンデントアプリ用であるかを示す情報が指定される。図１７のTPTは、放送インディペンデントアプリ用であるので、"1"が指定される。
tptVersion属性には、TPTのバージョンを示す情報が指定される。expireDate属性には、TPTの有効期限を示す情報が指定される。baseURL属性には、TPT内で指定されるURLのベースとなるURLが指定される。従って、当該TPTで指定される他のURLには、ベースURLを基準とした場合の相対的なパスを指定すればよい。
Capabilities要素には、TPTを利用する場合に、受信機に要求される機能を示す情報が指定される。すなわち、受信機は、Capabilities要素に指定された機能を有する場合に、そのTPTを利用可能であると判断する。
Application要素は、TPT要素の子要素であって、放送インディペンデントアプリに関する情報が記述される。Application要素は、appID属性、appType属性、appName属性、globalId属性、appVersion属性、cookieSpace属性、expireDate属性、context属性、BroadcastPermission要素、URL要素、ApplicationBoundary要素、及び、ContentItem要素の上位要素となる。
appID属性には、放送インディペンデントアプリを識別するためのアプリケーションIDが指定される。appType属性には、放送インディペンデントアプリのファイル属性等に関する情報が指定される。appName属性には、放送インディペンデントアプリの名称を示す情報が指定される。
globalId属性には、放送インディペンデントアプリをグローバルに識別可能なグローバルIDが指定される。グローバルIDは、例えばURIにより指定される。appVersion属性には、放送インディペンデントアプリのバージョンを示す情報が指定される。cookieSpace属性には、放送インディペンデントアプリを実行する際に必要となるストレージの容量を示す情報が指定される。expireDate属性には、放送インディペンデントアプリの有効期限を示す情報が指定される。
context属性には、放送インディペンデントアプリによる放送リソースへのアクセス権限が認められなかった場合に、放送インディペンデントアプリの動作を継続するか否かを示す情報が指定される。例えば、context属性として、"app"が指定された場合、放送インディペンデントアプリの動作を継続して、ケースＡの「アプリのみ表示画面」（図７）が表示されるようにする。また、context属性として、"broadcast"が指定された場合、放送インディペンデントアプリを終了して、ケースＢの「放送全画面」（図７）が表示されるようにする。
BroadcastPermission要素には、放送リソースごとのアクセス権限としての放送パーミッション情報が指定される。なお、BroadcastPermission要素の詳細な内容については、図１８を参照して後述する。
URL要素には、放送インディペンデントアプリの取得先を示すURLが指定される。例えば、URL要素には、アプリケーションサーバのURLが指定される。URL要素は、entry属性の上位要素となる。entry属性には、URLがエントリされているか否かを示す情報が指定される。例えば、URL要素により複数のURLが指定されている場合に、index.htmlなどの最初に取得する必要のあるファイルをエントリしておくことで、それに関連するリソースを一括して取得することができる。
ApplicationBoundary要素は、放送インディペンデントアプリが動作可能なURLの範囲を示す情報が指定される。ApplicationBoundary要素は、OriginalURL要素の上位要素となる。OriginalURL要素は、放送インディペンデントアプリが動作可能なURLが指定される。
ContentItem要素は、放送インディペンデントアプリを構成するファイル（例えば、HTMLファイルやJPEGファイルなど）のキャッシュに関する情報が記述される。ContentItem要素は、URL要素、及び、size属性の上位要素となる。URL属性には、キャッシュされるファイルのURLが指定される。URL要素は、entry属性の上位要素となる。entry属性には、URLがエントリされているか否かを示す情報が指定される。size属性には、キャッシュされるファイルのサイズを示す情報が指定される。
Signature要素には、TPT要素の子要素であって、署名情報として、TPTを受信した受信機で実行される、放送局公開鍵証明書を用いた検証処理で用いられる電子署名が記述される。
なお、図１７の放送インディペンデントアプリ用のTPTのシンタックスは一例であって、運用に合わせて要素や属性の追加や削除を行ってもよい。
また、図１７の放送インディペンデントアプリ用のTPTと、図６の放送リレートアプリ用のTPTを比較すれば、放送インディペンデントアプリ用のTPTは、independent属性と、Application要素のcontext属性及びBroadcastPermission要素と、Signature要素が追加されているが、放送リレートアプリ用のTPTのサブセットとなっている。また、図１７の放送インディペンデントアプリ用のTPTは、特定の放送インディペンデントアプリ用となるため、１つのApplication要素のみが記述され、さらに、コマンドが、エクスキュートコマンド（"exec"）のみとされるので、イベントに関する記述が省かれている。
（BroadcastPermission要素の詳細な内容）
図１８は、図１７のBroadcastPermission要素の詳細な内容を示す図である。
BroadcastPermission要素には、放送リソースごとのアクセス権限としての放送パーミッション情報が指定される。BroadcastPermission要素は、RFChannelId属性、BBPStreamId属性、ServiceId属性、及び、Permission要素の上位要素となる。
RFChannelId属性には、IP(Internet Protocol)伝送方式のデジタル放送における所定の周波数帯域を有する放送波において、放送事業者（放送局）ごとに割り当てられるRFチャンネルIDが指定される。また、BBPStreamId属性には、RFチャンネルIDにより識別される放送波で伝送されるBBPストリーム(Base Band Packet Stream)に割り当てられるBBPストリームIDが指定される。ServiceId属性には、BBPストリームIDにより識別されるBBPストリームで伝送される、ビデオやオーディオのデータからなるサービスごとに割り当てられるサービスIDが指定される。
すなわち、このIP伝送方式のID体系としては、MPEG2-TS(Moving Picture Expert Group 2 - Transport Stream)方式で用いられているネットワークIDと、トランスポートストリームIDと、サービスIDの組み合わせ（以下、「トリプレット(Triplet)」という。）に対応する構成が採用され、このトリプレットによって、放送ネットワーク内のBBPストリーム構成とサービス構成が示される。ただし、IP伝送方式のID体系においては、RFチャンネルIDとBBPストリームIDが、MPEG2-TS方式におけるネットワークIDとトランスポートストリームIDに相当している。
Permission要素には、トリプレットにより指定される放送リソースごとのアクセス権限がビットマップにより指定される。例えば、図１９のパーミッションビットマップのアサイン例に示すように、16ビットのうち、MSB(Most Significant Bit)のビットに、放送番組の映像の子画面参照許可の可否を示す情報が割り当てられている場合を想定する。この場合において、RFチャンネルID="128"が指定されているときには、インディペンデントアプリが、RFチャンネルIDが"128"である放送局の放送サービスに関して放送番組の映像の子画面表示参照許可のアクセス権限を有していることになる。
したがって、この場合、受信機では、実行中の放送インディペンデントアプリによって、RFチャンネルIDが"128"である放送局の放送サービスへのアクセス要求が発生した場合に、図１４の「放送受信（AV再生＋放送インディペンデントアプリ実行）」の状態に遷移して、「アプリ＋放送画面」（図７）を表示することになる。すなわち、「アプリ＋放送画面」（図７）では、放送インディペンデントアプリの動作が継続するとともに、RFチャンネルIDが"128"である放送局の放送番組の映像が子画面表示される。
なお、図１９のパーミッションビットマップのアサイン例では、放送サービスの映像の子画面表示参照許可のアクセス権限を説明したが、例えば、オーバーレイ表示参照許可のアクセス権限や、電子サービスガイド(ESG：Electronic Service Guide)表示参照許可のアクセス権限など、その他のアクセス権限を指定することができる。
以上、デジタル放送信号を受信するだけでなく、インターネット配信されるアプリケーションなどを受信可能な受信機で実行されるブロードキャストインディペンデントアプリケーション（放送インディペンデントアプリ）について説明した。
＜３．システム構成＞
（放送通信システムの構成例）
図２０は、放送通信システムの構成例を示す図である。なお、システムとは、複数の構成要素（装置等）の集合を意味する。
図２０の放送通信システム１は、上述した第１の実施の形態と第２の実施の形態を実現するための構成を有している。すなわち、図２０において、放送通信システム１は、送信装置１０、受信装置２０、ポータルサーバ３０、アプリケーションサーバ４０、TPTサーバ５０−１、及び、TPTサーバ５０−２から構成される。また、受信装置２０は、ポータルサーバ３０、アプリケーションサーバ４０、TPTサーバ５０−１、及び、TPTサーバ５０−２と、ネットワーク９０を介して、相互に接続されている。
送信装置１０は、放送番組等のAVコンテンツを、デジタル放送信号により送信する。また、送信装置１０は、放送リレートアプリの動作を制御するためのトリガ情報を、デジタル放送信号に含めて送信する。なお、トリガ情報は、AVコンテンツのビデオデータ又はオーディオデータに挿入するか、あるいは、デジタル放送信号により伝送されるストリーム内に配置することで送信される。
なお、送信装置１０は、上述した送信機（例えば、図１０，図１５の「Broadcaster」）に対応するものであり、放送事業者により提供され、その放送局内に配置される。また、送信装置１０は、放送局公開鍵証明書のファイルを、FLUTEセッションで伝送することができる。
受信装置２０は、送信装置１０から送信されたデジタル放送信号を受信して、AVコンテンツの映像及び音声を取得し、出力する。
受信装置２０は、ネットワーク９０を介してポータルサーバ３０にアクセスし、ポータルサイトのウェブページを取得する。受信装置２０は、ポータルサーバ３０から取得したウェブページに基づいて、ポータルサイトを表示する。
受信装置２０は、ネットワーク９０を介してアプリケーションサーバ４０にアクセスし、放送インディペンデントアプリを取得する。受信装置２０は、アプリケーションサーバ４０から取得した放送インディペンデントアプリを実行する。
受信装置２０は、ネットワーク９０を介してTPTサーバ５０−１にアクセスし、放送インディペンデントアプリ用のTPTを取得する。また、受信装置２０は、ネットワーク９０を介してTPTサーバ５０−２にアクセスし、放送リレートアプリ用のTPTを取得する。受信装置２０は、TPTサーバ５０−１から取得した放送インディペンデントアプリ用のTPT、又は、TPTサーバ５０−２から取得した放送リレートアプリ用のTPTに基づいて、放送インディペンデントアプリの動作を制御する。
なお、受信装置２０は、上述した受信機（例えば、図１０，図１５の「Receiver(TV)」）に対応するものであり、家庭内などに配置される。また、受信装置２０は、テレビ受像機として構成される他、ディスプレイやスピーカを有さない構成とすることで、ビデオレコーダ等の電子機器に内蔵されるようにしてもよい。
ポータルサーバ３０は、受信装置２０からの要求に応じて、ポータルサイトのウェブページを、ネットワーク９０を介して受信装置２０に提供する。なお、ポータルサーバ３０は、上述したポータルサーバ（例えば、図１０，図１５の「Portal Server」）に対応するものである。
アプリケーションサーバ４０は、受信装置２０からの要求に応じて、放送インディペンデントアプリを、ネットワーク９０を介して受信装置２０に提供する。なお、送信装置１０は、上述したアプリケーションサーバ（例えば、図１０，図１５の「App Server」）に対応するものであり、アプリケーションの制作事業者、放送事業者その他の事業者により提供される。
TPTサーバ５０−１は、受信装置２０からの要求に応じて、放送インディペンデントアプリ用のTPTを、ネットワーク９０を介して受信装置２０に提供する。また、TPTサーバ５０−２は、受信装置２０からの要求に応じて、放送リレートアプリ用のTPTを、ネットワーク９０を介して受信装置２０に提供する。
なお、TPTサーバ５０−１は、上述したTPTサーバ（例えば、図１０，図１５の「TPT Server」）に対応するものであり、サードパーティ等の放送事業者以外の事業者により提供される。また、TPTサーバ５０−２は、上述したTPTサーバ（例えば、図１０，図１５の「TPT Server」）に対応するものであり、放送事業者により提供される。また、以下の説明で、TPTサーバ５０−１とTPTサーバ５０−２を、特に区別する必要がない場合には、単にTPTサーバ５０と称して説明する。なお、TPTサーバ５０は、TPTを送信する送信装置であるとも言える。
放送通信システム１は、以上のように構成される。次に、図２０の放送通信システム１を構成する各装置の構成例について説明する。
（送信装置の構成例）
図２１は、図２０の送信装置の構成例を示す図である。
図２１において、送信装置１０は、オーディオデータ取得部１１１、オーディオエンコーダ１１２、ビデオデータ取得部１１３、ビデオエンコーダ１１４、トリガ情報生成部１１５、多重化部１１６、及び、送信部１１７から構成される。
オーディオデータ取得部１１１は、外部のサーバ、マイクロフォン、又は、記録媒体等から、AVコンテンツのオーディオデータを取得し、オーディオエンコーダ１１２に供給する。オーディオエンコーダ１１２は、オーディオデータ取得部１１１から供給されるオーディオデータを、MPEG(Moving Picture Experts Group)等の符号化方式に準拠して符号化し、多重化部１１６に供給する。
ビデオデータ取得部１１３は、外部のサーバ、カメラ、又は記録媒体等から、AVコンテンツのビデオデータを取得し、ビデオエンコーダ１１４、及び、トリガ情報生成部１１５に供給する。ビデオエンコーダ１１４は、ビデオデータ取得部１１３から供給されるビデオデータを、MPEG等の符号化方式に準拠して符号化し、多重化部１１６に供給する。
トリガ情報生成部１１５は、ビデオデータ取得部１１３から供給されるビデオデータに対応するAVコンテンツの進行にあわせてトリガ情報を生成し、ビデオエンコーダ１１４又は多重化部１１６に供給する。ビデオエンコーダ１１４は、ビデオデータの符号化を行うに際して、ビデオデータに、トリガ情報生成部１１５から供給されるトリガ情報を埋め込んで符号化することができる。
多重化部１１６は、オーディオエンコーダ１１２からのオーディオデータと、ビデオエンコーダ１１４からのビデオデータとを多重化して、その結果得られるストリームを、送信部１１７に供給する。また、多重化部１１６は、トリガ情報生成部１１５からトリガ情報が供給された場合には、オーディオデータとビデオデータに、さらにトリガ情報を多重化して、ストリームを生成する。
送信部１１７は、多重化部１１６から供給されるストリームを、アンテナ１１８を介して、デジタル放送信号として送信する。
なお、図２１においては、トリガ情報を、ビデオデータに埋め込まれる場合と、ストリームに多重化される場合を例示したが、例えば、トリガ情報をオーディオデータに埋め込むなど、それ以外の方法によって、トリガ情報を配置するようにしてもよい。
（受信装置の構成例）
図２２は、図２０の受信装置の構成例を示す図である。
図２２において、受信装置２０は、チューナ２１２、多重分離部２１３、オーディオデコーダ２１４、オーディオ出力部２１５、ビデオデコーダ２１６、ビデオ出力部２１７、トリガ情報取得部２１８、制御部２１９、メモリ２２０、入力部２２１、通信部２２２、アプリケーションエンジン２２３、及び、キャッシュメモリ２２４から構成される。
チューナ２１２は、アンテナ２１１を介して受信されたデジタル放送信号を選局・復調し、その結果得られるストリームを多重分離部２１３に供給する。多重分離部２１３は、チューナ２１２から供給されるストリームを、オーディオデータと、ビデオデータに分離し、それぞれをオーディオデコーダ２１４と、ビデオデコーダ２１６に供給する。
オーディオデコーダ２１４は、多重分離部２１３から供給されるオーディオデータを、オーディオエンコーダ１１２（図２１）による符号化方式に対応する復号方式で復号し、その結果得られるオーディオデータを、オーディオ出力部２１５に供給する。
オーディオ出力部２１５は、オーディオデコーダ２１４から供給されるオーディオデータを、スピーカ（不図示）に出力する。スピーカは、オーディオ出力部２１５から供給されるオーディオデータに対応する音声を出力する。
ビデオデコーダ２１６は、多重分離部２１３から供給されるビデオデータを、ビデオエンコーダ１１４（図２１）による符号化方式に対応する復号方式で復号し、その結果得られるビデオデータを、ビデオ出力部２１７及びトリガ情報取得部２１８に供給する。
ビデオ出力部２１７は、ビデオデコーダ２１６から供給されるビデオデータを、ディスプレイ（不図示）に出力する。ディスプレイは、ビデオ出力部２１７から供給されるビデオデータに対応する映像を表示する。これにより、例えば、「放送全画面」（図７）が表示される。
トリガ情報取得部２１８は、ビデオデコーダ２１６から供給されるビデオデータを常に監視して、ビデオデータに埋め込まれているトリガ情報を取得し、制御部２１９に供給する。なお、トリガ情報がストリームに配置されている場合には、トリガ情報取得部２１８は、多重分離部２１３により分離されたトリガ情報を含むパケットを監視し、そこからトリガ情報を取得することになる。
制御部２１９は、入力部２２１からの操作信号等に基づいて、受信装置２０の各部の動作を制御する。メモリ２２０には、制御部２１９からの制御に従い、各種のデータを記憶する。入力部２２１は、ユーザからの操作を受け付けて、それに対応する操作信号を制御部２１９に供給する。また、制御部２１９は、トリガ情報取得部２１８から供給されるトリガ情報に基づいて、通信部２２２を制御する。
通信部２２２は、制御部２１９からの制御に従い、ネットワーク９０を介してTPTサーバ５０にアクセスし、TPTを要求する。通信部２２２は、TPTサーバ５０からネットワーク９０を介して送信されるTPTを受信して、制御部２１９に供給する。制御部２１９は、通信部２２２から供給されるTPTを取得して、メモリ２２０に記憶させる。また、制御部２１９は、TPTに基づいて、アプリケーションエンジン２２３を制御する。
アプリケーションエンジン２２３は、制御部２１９からの制御に従い、通信部２２２を制御して、ネットワーク９０を介してアプリケーションサーバ４０にアクセスし、放送インディペンデントアプリを要求する。通信部２２２は、アプリケーションサーバ４０からネットワーク９０を介して送信される放送インディペンデントアプリを受信し、キャッシュメモリ２２４に保持させる。
アプリケーションエンジン２２３は、制御部２１９からの制御に従い、キャッシュメモリ２２４に保持されている放送インディペンデントアプリを読み出して実行する。このようにして実行される放送インディペンデントアプリのビデオデータは、ビデオ出力部２１７に供給される。
ビデオ出力部２１７は、アプリケーションエンジン２２３から供給されるビデオデータの映像を、ディスプレイに表示させる。これにより、例えば、「アプリ画面」（図７）や「アプリのみ表示画面」（図７）が表示される。また、ビデオ出力部２１７は、アプリケーションエンジン２２３から供給されるビデオデータを、ビデオデコーダ２１６から供給されたビデオデータと合成し、それにより得られる映像を、ディスプレイに表示させる。これにより、例えば、「アプリ＋放送画面」（図７）が表示される。
なお、ポータルサイトのウェブページは、アプリケーションサーバ４０から取得される放送インディペンデントアプリと同様にして、ポータルサーバ３０から取得され、その映像が、ビデオ出力部２１７を介してディスプレイに表示される。これにより、例えば、「ポータル画面」（図７）が表示される。
（制御部の構成例）
図２３は、図２２の制御部２１９における、放送インディペンデントアプリに関する処理を行う部分の機能的構成例を示す図である。
図２３において、制御部２１９は、TPT取得部２５１、TPT解析部２５２、アプリケーション制御部２５３、及び、トリガ情報解析部２５４から構成される。
TPT取得部２５１は、通信部２２２（図２２）を制御して、ネットワーク９０を介してTPTサーバ５０−１にアクセスし、放送インディペンデントアプリ用のTPTを取得し、TPT解析部２５２に供給する。
また、TPT取得部２５１は、後述のトリガ情報解析部２５４から供給されるトリガ情報の解析結果に基づいて、通信部２２２（図２２）を制御して、ネットワーク９０を介してTPTサーバ５０−２にアクセスし、放送リレートアプリ用のTPTを取得し、TPT解析部２５２に供給する。
TPT解析部２５２は、TPT取得部２５１から供給される放送インディペンデントアプリ用のTPTを解析する。また、TPT解析部２５２は、TPT取得部２５１から供給される放送リレートアプリ用のTPTを解析する。TPTの解析結果は、アプリケーション制御部２５３に供給される。
アプリケーション制御部２５３は、TPT解析部２５２から供給される放送インディペンデントアプリ用のTPTの解析結果に基づいて、アプリケーションエンジン２２３（図２２）を制御して、ネットワーク９０を介してアプリケーションサーバ４０にアクセスし、放送インディペンデントアプリを取得する。
また、アプリケーション制御部２５３は、TPT解析部２５２から供給されるTPTの解析結果などに従い、アプリケーションエンジン２２３（図２２）を制御して、放送インディペンデントアプリの動作を制御する。
トリガ情報解析部２５４は、トリガ情報取得部２１８（図２２）から供給されるトリガ情報を解析して、その解析の結果を、TPT取得部２５１に供給する。
（各サーバの構成例）
図２４は、図２０の各サーバの構成例を示す図である。図２４には、ポータルサーバ３０、アプリケーションサーバ４０、及び、TPTサーバ５０の構成例が示されている。
図２４において、ポータルサーバ３０は、制御部３１１、通信部３１２、及び、ファイル保持部３１３から構成される。制御部３１１は、ポータルサーバ３０の各部の動作を制御する。通信部３１２は、制御部３１１からの制御に従い、ネットワーク９０を介して受信装置２０と通信を行う。ファイル保持部３１３は、ポータルサイトのウェブページを構成する各種のファイル（例えばHTMLファイルやJPEGファイル等）を保持している。なお、ポータルサイトのウェブページは、制御部３１１により生成されるようにしてもよいし、通信部３１２がネットワーク９０を介して外部のサーバ等から取得するようにしてもよい。
制御部３１１は、通信部３１２の通信状況を常に監視し、受信装置２０からポータルサイトが要求された場合、ファイル保持部３１３からポータルサイトのウェブページを取得して、通信部３１２に供給する。通信部３１２は、制御部３１１からの制御に従い、ポータルサイトのウェブページを、ネットワーク９０を介して要求元の受信装置２０に送信する。
ポータルサーバ３０は、以上のように構成される。
図２４において、アプリケーションサーバ４０は、制御部４１１、通信部４１２、及び、アプリケーション保持部４１３から構成される。制御部４１１は、アプリケーションサーバ４０の各部の動作を制御する。通信部４１２は、制御部４１１からの制御に従い、ネットワーク９０を介して受信装置２０と通信を行う。アプリケーション保持部４１３は、放送インディペンデントアプリを構成する各種のファイル（例えばHTMLファイルやJPEGファイル等）などのデータを保持している。なお、放送インディペンデントアプリは、制御部４１１により生成されるようにしてもよいし、通信部４１２がネットワーク９０を介して外部のサーバ等から取得するようにしてもよい。
制御部４１１は、通信部４１２の通信状況を常に監視し、受信装置２０から放送インディペンデントアプリが要求された場合、アプリケーション保持部４１３から放送インディペンデントアプリを取得して、通信部４１２に供給する。通信部４１２は、制御部４１１からの制御に従い、放送インディペンデントアプリを、ネットワーク９０を介して要求元の受信装置２０に送信する。
アプリケーションサーバ４０は、以上のように構成される。
図２４において、TPTサーバ５０は、制御部５１１、通信部５１２、及び、TPT保持部５１３から構成される。制御部５１１は、TPTサーバ５０の各部の動作を制御する。通信部５１２は、制御部５１１からの制御に従い、ネットワーク９０を介して受信装置２０と通信を行う。TPT保持部５１３は、TPTのファイル（例えばXMLファイル）を保持している。なお、TPTのファイルは、制御部５１１により生成されるようにしてもよいし、通信部５１２がネットワーク９０を介して外部のサーバ等から取得するようにしてもよい。
制御部５１１は、通信部５１２の通信状況を常に監視し、受信装置２０からTPTが要求された場合、TPT保持部５１３からTPTを取得して、通信部５１２に供給する。通信部５１２は、制御部５１１からの制御に従い、TPTを、ネットワーク９０を介して要求元の受信装置２０に送信する。
なお、ここでは、説明の簡略化のため、TPTサーバ５０−１とTPTサーバ５０−２をまとめて、TPTサーバ５０として説明したが、TPTサーバ５０−１のTPT保持部５１３−１には、放送インディペンデントアプリ用のTPTのファイルが保持されている。また、TPTサーバ５０−２のTPT保持部５１３−２には、放送リレートアプリ用のTPTが保持されている。
TPTサーバ５０は、以上のように構成される。
＜４．各装置で実行される処理の流れ＞
次に、図２５乃至図３０のフローチャートを参照して、図２０の放送通信システムを構成する各装置で実行される処理の流れを説明する。
（デジタル放送信号送信処理）
まず、図２５のフローチャートを参照して、図２０の送信装置１０により実行されるデジタル放送信号送信処理の流れについて説明する。
ステップＳ１１１において、オーディオデータ取得部１１１は、外部のサーバ等から、AVコンテンツのオーディオデータを取得し、オーディオエンコーダ１１２に供給する。また、ステップＳ１１２において、ビデオデータ取得部１１３は、外部のサーバ等から、AVコンテンツのビデオデータを取得し、ビデオエンコーダ１１４、及び、トリガ情報生成部１１５に供給する。
ステップＳ１１３において、トリガ情報生成部１１５は、ビデオデータ取得部１１３から供給されるビデオデータに対応するAVコンテンツの進行にあわせてトリガ情報を生成し、ビデオエンコーダ１１４に供給する。
ステップＳ１１４において、オーディオエンコーダ１１２は、オーディオデータ取得部１１１から供給されるオーディオデータを、MPEG等の符号化方式に準拠して符号化し、多重化部１１６に供給する。
ステップＳ１１５において、ビデオエンコーダ１１４は、ビデオデータ取得部１１３から供給されるビデオデータを、MPEG等の符号化方式に準拠して符号化し、多重化部１１６に供給する。また、ビデオエンコーダ１１４は、ビデオデータの符号化を行うに際して、ビデオデータに、トリガ情報生成部１１５から供給されるトリガ情報を埋め込んで符号化を行う。
ステップＳ１１６において、多重化部１１６は、オーディオエンコーダ１１２からのオーディオデータと、ビデオエンコーダ１１４からのビデオデータとを多重化して、その結果得られるストリームを、送信部１１７に供給する。
ステップＳ１１７において、送信部１１７は、多重化部１１６から供給されるストリームを、アンテナ１１８を介して、デジタル放送信号として送信する。ステップＳ１１７の処理が終了すると、図２５のデジタル放送信号送信処理は終了する。
以上、デジタル放送信号送信処理について説明した。なお、図２５のデジタル放送信号送信処理では、説明を簡略化するため、トリガ情報がビデオデータに埋め込まれる場合を一例に説明した。
（デジタル放送信号受信処理）
次に、図２６のフローチャートを参照して、図２０の受信装置２０により実行されるデジタル放送信号受信処理の流れについて説明する。
ステップＳ２１１において、チューナ２１２は、アンテナ２１１を介して受信されたデジタル放送信号の選局・復調を行う。また、ステップＳ２１２において、多重分離部２１３は、チューナ２１２により復調されたストリームを、オーディオデータと、ビデオデータに分離する。
ステップＳ２１３において、オーディオデコーダ２１４は、多重分離部２１３により分離されたオーディオデータを、オーディオエンコーダ１１２（図２１）による符号化方式に対応する復号方式で復号し、その結果得られるオーディオデータを、オーディオ出力部２１５に供給する。
ステップＳ２１４において、ビデオデコーダ２１６は、多重分離部２１３から供給されるビデオデータを、ビデオエンコーダ１１４（図２１）による符号化方式に対応する復号方式で復号し、その結果得られるビデオデータを、ビデオ出力部２１７に供給する。
ステップＳ２１５において、オーディオ出力部２１５は、オーディオデコーダ２１４から供給されるオーディオデータを、スピーカ（不図示）に出力する。また、ステップＳ２１６において、ビデオ出力部２１７は、ビデオデコーダ２１６から供給されるビデオデータを、ディスプレイ（不図示）に出力する。これにより、ディスプレイには、AVコンテンツの映像が表示され、スピーカからは、その映像に同期した音声が出力される。
ステップＳ２１６の処理が終了すると、図２６のデジタル放送信号受信処理は終了する。
以上、デジタル放送信号受信処理について説明した。
（第１の放送インディペンデントアプリ対応処理）
次に、図２７のフローチャートを参照して、図２０の受信装置２０により実行される第１の放送インディペンデントアプリ対応処理の流れについて説明する。なお、この第１の放送インディペンデントアプリ対応処理は、上述した第１の実施の形態に対応した処理とされる。
ステップＳ２３１の処理で「ポータル画面」（図７）が表示された場合、ステップＳ２３２において、制御部２１９は、入力部２２１からの操作信号に基づいて、「ポータル画面」から、ユーザにより放送インディペンデントアプリが選択されたかどうかを判定する。
ステップＳ２３２において、放送インディペンデントアプリが選択されていないと判定された場合、ステップＳ２３２の判定処理が繰り返される。ステップＳ２３２においては、ユーザにより放送インディペンデントアプリが選択されるのを待って、処理は、ステップＳ２３３に進められる。
ステップＳ２３３において、TPT取得部２５１は、通信部２２２を制御して、ネットワーク９０を介してTPTサーバ５０−１にアクセスし、放送インディペンデントアプリ用のTPTを取得する。この放送インディペンデントアプリ用のTPTは、メモリ２２０に記憶される。
ステップＳ２３４において、TPT解析部２５２は、ステップＳ２３３の処理で取得された放送インディペンデントアプリ用のTPTを解析し、その解析結果を、アプリケーション制御部２５３に供給する。
ステップＳ２３５において、アプリケーション制御部２５３は、ステップＳ２３４の処理で得られるTPTの解析結果に基づいて、アプリケーションエンジン２２３を制御して、ネットワーク９０を介してアプリケーションサーバ４０にアクセスし、放送インディペンデントアプリを取得する。なお、アプリケーションサーバ４０にアクセスする際には、放送インディペンデントアプリ用のTPT（図１２）に記述されたApplication要素のURL要素に指定されたURLが用いられる。
ステップＳ２３６において、アプリケーション制御部２５３は、アプリケーションエンジン２２３を制御して、ステップＳ２３５の処理で取得された放送インディペンデントアプリを起動する。これにより、受信装置２０では、放送インディペンデントアプリが実行され、「アプリ画面」（図７）が表示される。
ステップＳ２３７において、アプリケーション制御部２５３は、実行中の放送インディペンデントアプリによって、放送サービス（例えば、放送番組）が選局されたかどうかを判定する。ステップＳ２３７において、放送インディペンデントアプリによって、放送サービスが選局されていないと判定された場合、ステップＳ２３７の判定処理が繰り返される。ステップＳ２３７においては、放送インディペンデントアプリによって、放送サービスが選局されるのを待って、処理は、ステップＳ２３８に進められる。
ステップＳ２３８において、トリガ情報取得部２１８は、ビデオデコーダ２１６から供給されるビデオデータに埋め込まれているトリガ情報を取得し、トリガ情報解析部２５４に供給する。
ステップＳ２３９において、トリガ情報解析部２５４は、ステップＳ２３８の処理で取得されたトリガ情報を解析する。
ステップＳ２４０において、TPT取得部２５１は、ステップＳ２３９の処理で得られるトリガ情報の解析結果に基づいて、通信部２２２を制御して、ネットワーク９０を介してTPTサーバ５０−２にアクセスし、放送リレートアプリ用のTPTを取得する。この放送リレートアプリ用のTPTは、メモリ２２０に記憶される。
ステップＳ２４１において、TPT解析部２５２は、ステップＳ２４０の処理で取得された放送リレートアプリ用のTPTを解析する。
ステップＳ２４２において、TPT解析部２５２は、ステップＳ２３４の処理で得られる放送インディペンデントアプリ用のTPTの解析結果と、ステップＳ２４１の処理で得られる放送リレートアプリ用のTPTの解析結果に基づいて、放送インディペンデントアプリによる放送リソースを利用する動作の継続が認められるかどうかを判定する。
具体的には、放送リレートアプリ用のTPT（図６）において、実行中の放送インディペンデントアプリと、グローバルIDが同一の値で、かつ、取得先のURL（ただし、entry="true"）も同一の値となる放送リレートアプリであって、その時点でのイベントに、エクスキュートコマンド（"exec"）が指定されている放送リレートアプリの記述がある場合には、放送インディペンデントアプリによる放送リソースの利用を認めるものとする。すなわち、放送インディペンデントアプリによる放送リソースの利用を認めるか否かに応じて、放送インディペンデントアプリによる放送リソースを利用する動作の継続が認められるかどうかが判定される。
ステップＳ２４２において、放送インディペンデントアプリの放送リソースを利用する動作の継続が認められると判定された場合、処理は、ステップＳ２４３に進められる。この場合、放送インディペンデントアプリは、放送リソースの利用が認められ、その動作を継続するので、ステップＳ２４３においては、「アプリ＋放送画面」（図７）が表示される。
なお、このように、放送リレートアプリ用のTPTによって、放送リソースを利用する動作の継続が認められた放送インディペンデントアプリは、放送事業者により動作の継続が認められた放送リレートアプリであるとも言える。したがって、当該放送インディペンデントアプリは、その後、放送リレートアプリとして動作することになる。
また、ステップＳ２４２において、放送インディペンデントアプリの放送リソースを利用する動作の継続が認められなかった場合、処理は、ステップＳ２４４に進められる。ステップＳ２４４においては、放送インディペンデントアプリ用のTPT（図１２）に記述される、Application要素のcontext属性に基づいて、ケースＡ又はケースＢのどちらで対応するかが判定される。
ステップＳ２４４において、ケースＡで対応すると判定された場合、処理は、ステップＳ２４５に進められる。この場合、放送インディペンデントアプリは、放送リソースを利用する動作の継続は認められなかったが、放送リソースを利用せずにその動作を継続するので、ステップＳ２４５においては、「アプリのみ表示画面」（図７）が表示される。
また、ステップＳ２４４において、ケースＢで対応すると判定された場合、処理は、ステップＳ２４６に進められる。この場合、放送インディペンデントアプリは、放送リソースを利用する動作の継続が認められなかったために、その動作を終了するので、ステップＳ２４６においては、「放送全画面」（図７）が表示される。
ステップＳ２４３，Ｓ２４５，Ｓ２４６のいずれかの処理によって、上述の判定結果に応じた画面が表示されると、図２７の第１の放送インディペンデントアプリ対応処理は終了する。
以上、第１の放送インディペンデントアプリ対応処理について説明した。この第１の放送インディペンデントアプリ対応処理においては、放送インディペンデントアプリによって、放送リソースが利用される場合に、放送インディペンデントアプリ用のTPTの記述内容と、放送リレートアプリ用のTPTの記述内容が照合される。そして、その照合の結果に応じて、放送リソースの利用が認められた場合には、「アプリ＋放送画面」（図７）が表示され、放送リソースの利用が認められない場合には、「アプリのみ表示画面」（図７）又は「放送全画面」（図７）が表示される。
（第２の放送インディペンデントアプリ対応処理）
次に、図２８のフローチャートを参照して、図２０の受信装置２０により実行される第２の放送インディペンデントアプリ対応処理の流れについて説明する。なお、この第２の放送インディペンデントアプリ対応処理は、上述した第２の実施の形態に対応した処理とされる。
ステップＳ２６１の処理で「ポータル画面」（図７）が表示された場合、ステップＳ２６２において、制御部２１９は、入力部２２１からの操作信号に基づいて、「ポータル画面」から、ユーザにより放送インディペンデントアプリが選択されたかどうかを判定する。
ステップＳ２６２において、放送インディペンデントアプリが選択されていないと判定された場合、ステップＳ２６２の判定処理が繰り返される。ステップＳ２６２においては、ユーザにより放送インディペンデントアプリが選択されるのを待って、処理は、ステップＳ２６３に進められる。
ステップＳ２６３において、TPT取得部２５１は、通信部２２２を制御して、ネットワーク９０を介してTPTサーバ５０−１にアクセスし、放送インディペンデントアプリ用のTPTを取得する。この放送インディペンデントアプリ用のTPTは、メモリ２２０に記憶される。
ステップＳ２６４において、TPT解析部２５２は、ステップＳ２６３の処理で取得された放送インディペンデントアプリ用のTPTを解析し、アプリケーション制御部２５３に供給する。
ステップＳ２６５において、TPT解析部２５２は、メモリ２２０にあらかじめ保持している放送局公開鍵証明書を用いて、放送インディペンデントアプリ用のTPTに記述された電子署名を検証する。なお、電子署名は、放送インディペンデントアプリ用のTPT（図１７）のSignature要素に指定される。また、放送局公開鍵証明書がメモリ２２０に保持されていない場合には、例えば、目的の放送局公開鍵証明書のファイルが、送信装置１０からFLUTEセッションで伝送されるまで待って、目的の放送局公開鍵証明書が取得された後に、ステップＳ２６５の検証処理が実行される。
ステップＳ２６６においては、ステップＳ２６５の検証処理による、電子署名の検証に成功したかどうかが判定される。ステップＳ２６６において、電子署名の検証に失敗したと判定された場合、放送インディペンデントアプリは起動されずに、図２８の第２の放送インディペンデントアプリ対応処理は終了する。また、ステップＳ２６６において、電子署名の検証に成功したと判定された場合、処理は、ステップＳ２６７に進められる。
ステップＳ２６７において、アプリケーション制御部２５３は、ステップＳ２６４の処理で得られるTPTの解析結果に基づいて、アプリケーションエンジン２２３を制御して、ネットワーク９０を介してアプリケーションサーバ４０にアクセスし、放送インディペンデントアプリを取得する。なお、アプリケーションサーバ４０にアクセスする際には、放送インディペンデントアプリ用のTPT（図１７）に記述されたApplication要素のURL要素に指定されたURLが用いられる。
ステップＳ２６８において、アプリケーション制御部２５３は、アプリケーションエンジン２２３を制御して、ステップＳ２６７の処理で取得された放送インディペンデントアプリを起動する。これにより、受信装置２０では、放送インディペンデントアプリが実行され、「アプリ画面」（図７）が表示される。
ステップＳ２６９において、アプリケーション制御部２５３は、実行中の放送インディペンデントアプリによって、放送リソースへのアクセス要求が発生したかどうかを判定する。ステップＳ２６９において、放送インディペンデントアプリによって、放送リソースへのアクセス要求が発生していないと判定された場合、ステップＳ２６９の判定処理が繰り返される。ステップＳ２６９においては、放送インディペンデントアプリによって、放送リソースへのアクセス要求が発生するのを待って、処理は、ステップＳ２７０に進められる。
ステップＳ２７０において、TPT解析部２５２は、メモリ２２０に記憶されている放送インディペンデントアプリ用のTPTに基づいて、放送インディペンデントアプリが、放送リソースのアクセス権限を有しているかどうかを判定する。具体的には、放送インディペンデントアプリ用のTPT（図１７）において、放送局（放送サービス）ごとのアクセス権限が記述されているので、この放送パーミッション情報を用いて、放送インディペンデントアプリが、放送リソース（例えば、選局が指示された放送局の放送サービス）のアクセス権限を有しているかどうかが判定される。
ステップＳ２７０において、放送インディペンデントアプリが放送リソースへのアクセス権限を有していると判定された場合、処理は、ステップＳ２７１に進められる。この場合、放送インディペンデントアプリは、放送リソースの利用が認められ、その動作を継続するので、ステップＳ２７１においては、「アプリ＋放送画面」（図７）が表示される。
また、ステップＳ２７０において、放送インディペンデントアプリが放送リソースへのアクセス権限を有していないと判定された場合、処理は、ステップＳ２７２に進められる。ステップＳ２７２においては、放送インディペンデントアプリ用のTPT（図１７）に記述される、Application要素のcontext属性に基づいて、ケースＡ又はケースＢのどちらで対応するかが判定される。
ステップＳ２７２において、ケースＡで対応すると判定された場合、処理は、ステップＳ２７３に進められる。この場合、放送インディペンデントアプリは、放送リソースへのアクセス権は有していなかったが、放送リソースを利用せずにその動作を継続するので、ステップＳ２７３においては、「アプリのみ表示画面」（図７）が表示される。
また、ステップＳ２７２において、ケースＢで対応すると判定された場合、処理は、ステップＳ２７４に進められる。この場合、放送インディペンデントアプリは、放送リソースへのアクセス権を有していなかったために、その動作を終了するので、ステップＳ２７４においては、「放送全画面」（図７）が表示される。
ステップＳ２７１，Ｓ２７３，Ｓ２７４のいずれかの処理によって、上述の判定結果に応じた画面が表示されると、図２８の第２の放送インディペンデントアプリ対応処理は終了する。
以上、第２の放送インディペンデントアプリ対応処理について説明した。この第２の放送インディペンデントアプリ対応処理においては、放送インディペンデントアプリによって、放送リソースが利用される場合に、放送インディペンデントアプリ用のTPTに記述された放送パーミッション情報を用い、当該放送インディペンデントアプリが、放送サービスのアクセス権限を有しているかどうかが判定される。そして、放送リソースへのアクセス権限を有している場合には、「アプリ＋放送画面」（図７）が表示され、放送リソースへのアクセス権限を有していない場合には、「アプリのみ表示画面」（図７）又は「放送全画面」（図７）が表示される。
（放送インディペンデントアプリ提供処理）
次に、図２９のフローチャートを参照して、図２０のアプリケーションサーバ４０により実行される放送インディペンデントアプリ提供処理の流れについて説明する。なお、図２９の放送インディペンデントアプリ提供処理に先立って、アプリケーション保持部４１３には、制御部４１１により生成された放送インディペンデントアプリが保持されているものとする。
ステップＳ４１１において、制御部４１１は、通信部４１２の通信状況を常に監視して、受信装置２０から放送インディペンデントアプリが要求されたかどうかを判定する。ステップＳ４１１において、放送インディペンデントアプリが要求されていないと判定された場合、ステップＳ４１１の処理が繰り返される。すなわち、ステップＳ４１１においては、受信装置２０から放送インディペンデントアプリが要求されるのを待って、処理は、ステップＳ４１２に進められる。
ステップＳ４１２において、制御部４１１は、アプリケーション保持部４１３から放送インディペンデントアプリを取得して、通信部４１２に供給する。また、ステップＳ４１３において、通信部４１２は、制御部４１１からの制御に従い、放送インディペンデントアプリを、ネットワーク９０を介して要求元の受信装置２０に送信する。ステップＳ４１３の処理が終了すると、図２９の放送インディペンデントアプリ提供処理は終了する。
以上、放送インディペンデントアプリ提供処理について説明した。
（TPT提供処理）
最後に、図３０のフローチャートを参照して、図２０のTPTサーバ５０により実行されるTPT提供処理の流れについて説明する。なお、図３０のTPT提供処理に先立って、TPT保持部５１３には、制御部５１１により生成された放送インディペンデントアプリ用のTPT、又は、放送リレートアプリ用のTPTが保持されているものとする。
ステップＳ５１１において、制御部５１１は、通信部５１２の通信状況を常に監視し、受信装置２０からTPTが要求されたかどうかを判定する。ステップＳ５１１において、TPTが要求されていないと判定された場合、ステップＳ５１１の処理が繰り返される。すなわち、ステップＳ５１１においては、受信装置２０からTPTが要求されるのを待って、処理は、ステップＳ５１２に進められる。
ステップＳ５１２において、制御部５１１は、TPT保持部５１３からTPTを取得して、通信部５１２に供給する。また、ステップＳ５１３において、通信部５１２は、制御部５１１からの制御に従い、TPTを、ネットワーク９０を介して要求元の受信装置２０に送信する。ステップＳ５１３の処理が終了すると、図３０のTPT提供処理は終了する。
以上、TPT提供処理について説明した。なお、このTPT提供処理においては、TPTサーバ５０−１とTPTサーバ５０−２によるTPT提供処理をまとめて説明したが、TPTサーバ５０−１が、図３０のTPT提供処理を実行することで、放送インディペンデントアプリ用のTPTが、要求元の受信装置２０に提供される。また、TPTサーバ５０−２が、図３０のTPT提供処理を実行することで、放送リレートアプリ用のTPTが、要求元の受信装置２０に提供される。
＜５．変形例＞
（放送通信システムの他の構成例）
図３１は、放送通信システムの他の構成例を示す図である。
放送通信システム２は、送信装置１０、受信装置２０、ポータルサーバ３０、アプリケーションサーバ４０、TPTサーバ５０、及び、ACRサーバ６０から構成される。
すなわち、図３１の放送通信システム２は、図２０の放送通信システム１と比べて、ACRサーバ６０が新たに設けられている点で異なっている。それ以外の構成については、図２０の放送通信システム１と同様であるため、その説明は適宜省略する。
ACRサーバ６０は、ネットワーク９０を介して受信装置２０と接続されている。受信装置２０は、ネットワーク９０を介してACRサーバ６０にアクセスして、トリガ情報を問い合わせる。その際、放送番組等のAVコンテンツのビデオデータ、及び、オーディオデータの少なくとも一方から抽出される特徴量（以下、フィンガプリント情報（Finger Print）ともいう）が、ACRサーバ６０に送信される。
ACRサーバ６０は、例えば、AVコンテンツを提供する放送事業者等により提供される。ACRサーバ６０は、任意のAVコンテンツのビデオデータ及びオーディオデータから抽出された特徴量が登録されているデータベースを有しており、ネットワーク９０を介して受信装置２０からの問い合わせに応じて、ACR（Automatic Content Recognition）技術を用いたAVコンテンツの識別を行う。
具体的には、ACRサーバ６０は、受信装置２０からのフィンガプリント情報を、データベースと照合することで、AVコンテンツを識別し、その識別結果に応じたトリガ情報を生成する。ACRサーバ６０は、生成したトリガ情報を、ネットワーク９０を介して受信装置２０に送信する。
受信装置２０は、ACRサーバ６０から受信したトリガ情報に応じて、ネットワーク９０を介してTPTサーバ５０−２にアクセスして、放送リレートアプリ用のTPTを取得する。そして、上述した第１の実施の形態で説明したように、受信装置２０は、放送インディペンデントアプリ用のTPT、及び、放送リレートアプリ用のTPTに基づいて、放送インディペンデントアプリによる放送リソースを利用する動作の継続が認められるかどうかの動作継続可否判定処理を行い、その判定結果に応じた画面（例えば、図７の「アプリ＋放送画面」、「アプリのみ表示画面」、又は、「放送全画面」）を表示することになる。
放送通信システム２は、以上のように構成される。
（フィンガプリント情報を利用した場合の受信機の動作）
図３２は、フィンガプリント情報を利用した場合の受信機の動作を示す図である。
図３２において、受信装置２０（図３１）は、ポータルサイトの表示が指示された場合、ネットワーク９０を介してポータルサーバ３０（図３１）にアクセスし、ポータルサイトのウェブページを要求する（Ｓ７１）。ポータルサーバ３０は、受信装置２０からの要求に応じて、ポータルサイトのウェブページを、ネットワーク９０を介して受信装置２０に送信する（Ｓ７２）。受信装置２０は、ポータルサーバ３０から受信したポータルサイトのウェブページを表示する。
受信装置２０（図３１）では、ポータルサイトから放送インディペンデントアプリが選択された場合、ネットワーク９０を介してTPTサーバ５０−１（図３１）にアクセスし、放送インディペンデントアプリ用のTPTを要求する（Ｓ７３）。TPTサーバ５０−１は、受信装置２０からの要求に応じて、放送インディペンデントアプリ用のTPT（図中の「TPT」）を、ネットワーク９０を介して受信装置２０に送信する（Ｓ７４）。受信装置２０は、TPTサーバ５０−１から送信される放送インディペンデントアプリ用のTPTを受信して、保持する。
そして、受信装置２０（図３１）は、放送インディペンデントアプリ用のTPTに基づいて、ネットワーク９０を介してアプリケーションサーバ４０（図３１）にアクセスし、放送インディペンデントアプリを要求する（Ｓ７５）。アプリケーションサーバ４０は、受信装置２０からの要求に応じて、放送インディペンデントアプリ（図中の「App」）を、ネットワーク９０を介して受信装置２０に送信する（Ｓ７６）。受信装置２０は、アプリケーションサーバ４０から送信される放送インディペンデントアプリを受信して起動する。
ここで、受信装置２０（図３１）は、実行中の放送インディペンデントアプリによって、放送サービス（例えば、放送番組等のAVコンテンツ）が選局された場合、放送局の送信装置１０（図３１）によって、AVコンテンツ（図中の「Content」）のビデオデータ及びオーディオデータから抽出される特徴量をフィンガプリント情報として、ACRサーバ６０（図３１）に送信して、トリガ情報を要求する（Ｓ７８）。
ACRサーバ６０は、ACR識別処理を行い、受信装置２０からのフィンガプリント情報を、データベースと照合することで、受信装置２０において、放送インディペンデントアプリにより選局された放送サービス（例えば、放送番組等のAVコンテンツ）を識別する。
具体的には、図３３に示すように、ACRサーバ６０では、受信装置２０からフィンガプリント情報による問い合わせを受けると、ACR識別処理部６１１によって、フィンガプリント情報が、あらかじめ用意されたＦＰデータベース６１２と照合され、放送インディペンデントアプリによって選局されたAVコンテンツが識別される。この識別結果は、トリガ情報生成部６１３に供給される。トリガ情報生成部６１３は、ACR識別処理部６１１からの識別結果及びトリガ用データベース６１４に登録された各種の情報に基づいて、トリガ情報を生成する。
なお、フィンガプリント情報（特徴量）は、例えば、AVコンテンツの全体又は一部構成要素の固有情報であって、ＦＰデータベース６１２には、あらかじめ多数のAVコンテンツの固有情報が登録されている。ACR識別処理では、例えば、それらの固有情報の類似度又は一致度が判定される。なお、この類似度又は一致度の判定方法としては、各種の文献などによって開示されている、公知の技術を用いることができる。ACR技術を用いることで、AVコンテンツの解像度、アスペクト比、ビットレート、又はフォーマットなどの情報に依存せずに、ビデオデータ及びオーディオデータの特徴量からAVコンテンツを識別することができる。
図３２に戻り、ACRサーバ６０は、生成したトリガ情報（図中の「Trigger」）を、問い合わせ元の受信装置２０に送信する（Ｓ７９）。受信装置２０は、ACRサーバ６０からトリガ情報に基づいて、ネットワーク９０を介してTPTサーバ５０−２（図３１）にアクセスし、放送リレートアプリ用のTPTを要求する（Ｓ８０）。TPTサーバ５０−２は、受信装置２０からの要求に応じて、放送リレートアプリ用のTPT（図中の「TPT」）を、ネットワーク９０を介して受信装置２０に送信する（Ｓ８１）。受信装置２０は、TPTサーバ５０−２から送信される放送リレートアプリ用のTPTを受信して、取得する。
そして、受信装置２０は、放送インディペンデントアプリ用のTPTと、放送リレートアプリ用のTPTに基づいて、放送インディペンデントアプリによる放送リソースを利用する動作の継続が認められるかどうかの動作継続可否判定処理を行う。
動作継続可否判定処理によって、放送インディペンデントアプリによる放送リソースの利用が認められた場合、受信装置２０は、図９の「放送受信（AV再生＋放送リレートアプリ実行）」の状態に遷移して、放送インディペンデントアプリは、放送リレートアプリとして動作を継続する。この場合、受信装置２０では、「アプリ＋放送画面」（図７）が表示される。
他方、放送インディペンデントアプリによる放送リソースの利用が認められなかった場合、受信装置２０は、図９の「放送インディペンデントアプリ実行」の状態、又は、図９の「放送受信（AVのみ再生）」の状態に遷移して、ケースＡの「アプリのみ表示画面」（図７）、又は、ケースＢの「放送全画面」（図７）を表示する。
なお、上述した説明では、AVコンテンツとして、放送番組等の放送コンテンツを説明したが、放送コンテンツの代わりに、通信コンテンツが、ネットワーク９０を介してストリーミングサーバ（不図示）からストリーミング配信されるようにしてもよい。
＜６．コンピュータの構成＞
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図３４は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
コンピュータ９００において、CPU（Central Processing Unit）９０１，ROM（Read Only Memory）９０２，RAM（Random Access Memory）９０３は、バス９０４により相互に接続されている。バス９０４には、さらに、入出力インターフェース９０５が接続されている。入出力インターフェース９０５には、入力部９０６、出力部９０７、記録部９０８、通信部９０９、及び、ドライブ９１０が接続されている。
入力部９０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部９０７は、ディスプレイ、スピーカなどよりなる。記録部９０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部９０９は、ネットワークインターフェースなどよりなる。ドライブ９１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア９１１を駆動する。
以上のように構成されるコンピュータ９００では、CPU９０１が、ROM９０２や記録部９０８に記憶されているプログラムを、入出力インターフェース９０５及びバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。
コンピュータ９００（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
コンピュータ９００では、プログラムは、リムーバブルメディア９１１をドライブ９１０に装着することにより、入出力インターフェース９０５を介して、記録部９０８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部９０９で受信し、記録部９０８にインストールすることができる。その他、プログラムは、ROM９０２や記録部９０８に、あらかじめインストールしておくことができる。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
また、本技術は、以下のような構成をとることができる。
（１）
デジタル放送信号を受信する受信部と、
前記デジタル放送信号で送信される放送リソースの利用を要求可能な第１のアプリケーションを取得するアプリケーション取得部と、
前記第１のアプリケーションの動作を制御するための第１の制御情報を取得する制御情報取得部と、
前記第１のアプリケーションにより前記放送リソースの利用が要求された場合、前記第１の制御情報に基づいて、前記第１のアプリケーションによる前記放送リソースの利用を制御するアプリケーション制御部と
を備える受信装置。
（２）
前記制御情報取得部は、放送サービス内で起動される第２のアプリケーションの動作を制御するための第２の制御情報をさらに取得し、
前記アプリケーション制御部は、前記第１の制御情報と、前記第２の制御情報との照合の結果に基づいて、前記第１のアプリケーションによる前記放送リソースを利用する動作の継続が認められない場合に、前記第１のアプリケーションによる前記放送リソースの利用を制限する
（１）に記載の受信装置。
（３）
前記アプリケーション制御部は、前記第１のアプリケーションによる前記放送リソースを利用する動作の継続が認められない場合、前記第１のアプリケーションの動作を継続するとともに、前記放送リソースの表示を非表示にする
（２）に記載の受信装置。
（４）
前記アプリケーション制御部は、前記第１のアプリケーションによる前記放送リソースを利用する動作の継続が認められない場合、前記第１のアプリケーションの動作を終了するとともに、前記放送リソースを通常の状態で表示する
（２）に記載の受信装置。
（５）
前記アプリケーション制御部は、前記第１のアプリケーションによる前記放送リソースを利用する動作の継続が認められる場合、前記第１のアプリケーションを、前記第２のアプリケーションとして動作を継続させる
（２）乃至（４）のいずれか一項に記載の受信装置。
（６）
前記第２のアプリケーションの動作を制御するためのトリガ情報を取得するトリガ情報取得部をさらに備え、
前記制御情報取得部は、前記トリガ情報に基づいて、前記第２の制御情報を取得する
（２）乃至（５）のいずれか一項に記載の受信装置。
（７）
前記アプリケーション制御部は、前記第１の制御情報に含まれる、放送サービスごとのアクセス権を示す放送パーミッション情報に基づいて、前記第１のアプリケーションが前記放送リソースへのアクセス権を有していない場合に、前記第１のアプリケーションによる前記放送リソースの利用を制限する
（２）に記載の受信装置。
（８）
前記アプリケーション制御部は、前記第１のアプリケーションが前記放送リソースへのアクセス権を有していない場合、前記第１のアプリケーションの動作を継続するとともに、前記放送リソースの表示を非表示にする
（７）に記載の受信装置。
（９）
前記アプリケーション制御部は、前記第１のアプリケーションが前記放送リソースへのアクセス権を有していない場合、前記第１のアプリケーションの動作を終了するとともに、前記放送リソースを通常の状態で表示する
（７）に記載の受信装置。
（１０）
前記アプリケーション取得部は、所定の証明書を用いて、前記第１の制御情報に含まれる署名情報の検証に成功した場合に、前記第１のアプリケーションを取得する
（７）乃至（９）のいずれか一項に記載の受信装置。
（１１）
前記放送パーミッション情報は、前記放送サービスごとに、ビットマップ形式で指定される
（７）乃至（１０）のいずれか一項に記載の受信装置。
（１２）
受信装置の受信方法において、
前記受信装置が、
デジタル放送信号を受信し、
前記デジタル放送信号で送信される放送リソースの利用を要求可能な第１のアプリケーションを取得し、
前記第１のアプリケーションの動作を制御するための第１の制御情報を取得し、
前記第１のアプリケーションにより前記放送リソースの利用が要求された場合、前記第１の制御情報に基づいて、前記第１のアプリケーションによる前記放送リソースの利用を制御する
ステップを含む受信方法。
（１３）
デジタル放送信号で送信される放送リソースの利用を要求可能な第１のアプリケーションの動作を制御するための第１の制御情報であって、前記第１のアプリケーションによる前記放送リソースの利用の際に用いられる前記第１の制御情報を生成する制御情報生成部と、
受信機からの要求に応じて、ネットワークを介して前記第１の制御情報を送信する送信部と
を備える送信装置。
（１４）
前記第１の制御情報は、前記第１のアプリケーションによる前記放送リソースの利用に際して、放送サービス内で起動される第２のアプリケーションの動作を制御するための第２の制御情報との照合に用いられる
（１３）に記載の送信装置。
（１５）
前記第１の制御情報は、前記第１のアプリケーションによる前記放送リソースを利用する動作の継続が認められない場合に、前記第１のアプリケーションの動作を継続するとともに、前記放送リソースの表示を非表示にするか、あるいは、前記第１のアプリケーションの動作を終了するとともに、前記放送リソースを通常の状態で表示するかを示す情報を含む
（１４）に記載の送信装置。
（１６）
前記第１の制御情報は、放送サービスごとのアクセス権を示す放送パーミッション情報を含む
（１３）に記載の送信装置。
（１７）
前記第１の制御情報は、前記第１のアプリケーションが前記放送リソースへのアクセス権を有していない場合に、前記第１のアプリケーションの動作を継続するとともに、前記放送リソースの表示を非表示にするか、あるいは、前記第１のアプリケーションの動作を終了するとともに、前記放送リソースを通常の状態で表示するかを示す情報を含む
（１６）に記載の送信装置。
（１８）
前記第１の制御情報は、前記第１のアプリケーションの取得時に、所定の証明書を用いた検証に用いられる署名情報を含む
（１６）又は（１７）に記載の送信装置。
（１９）
前記放送パーミッション情報は、前記放送サービスごとに、ビットマップ形式で指定される
（１６）乃至（１８）のいずれか一項に記載の送信装置。
（２０）
送信装置の送信方法において、
前記送信装置が、
デジタル放送信号で送信される放送リソースの利用を要求可能な第１のアプリケーションの動作を制御するための第１の制御情報であって、前記第１のアプリケーションによる前記放送リソースの利用の際に用いられる前記第１の制御情報を生成し、
受信機からの要求に応じて、ネットワークを介して前記第１の制御情報を送信する
ステップを含む送信方法。
１，２ 放送通信システム， １０ 送信装置， ２０ 受信装置， ３０ ポータルサーバ， ４０ アプリケーションサーバ， ５０，５０−１，５０−２ TPTサーバ， ６０ ACRサーバ， ９０ ネットワーク， １１１ オーディオデータ取得部， １１３ ビデオデータ取得部， １１５ トリガ情報生成部， １１７ 送信部， ２１２ チューナ， ２１８ トリガ情報取得部， ２１９ 制御部， ２２２ 通信部， ２２３ アプリケーションエンジン， ２５１ TPT取得部， ２５２ TPT解析部， ２５３ アプリケーション制御部， ２５４ トリガ情報解析部， ３１１ 制御部， ３１２ 通信部， ４１１ 制御部， ４１２ 通信部， ５１１ 制御部， ５１２ 通信部， ６１３ トリガ情報生成部， ９００ コンピュータ， ９０１ CPU

Claims (11)

  1. デジタル放送信号を受信する受信部と、
    前記デジタル放送信号で送信される放送リソースの利用を要求可能な第１のアプリケーションを取得するアプリケーション取得部と、
    前記第１のアプリケーションの動作を制御するための第１の制御情報を取得する制御情報取得部と、
    前記第１のアプリケーションにより前記放送リソースの利用が要求された場合、前記第１の制御情報に基づいて、前記第１のアプリケーションによる前記放送リソースの利用を制御するアプリケーション制御部と
    を備え、
    前記制御情報取得部は、放送サービス内で起動される第２のアプリケーションの動作を制御するための第２の制御情報をさらに取得し、
    前記アプリケーション制御部は、前記第１の制御情報と、前記第２の制御情報との照合の結果に基づいて、前記第１のアプリケーションによる前記放送リソースを利用する動作の継続が認められない場合に、前記第１のアプリケーションによる前記放送リソースの利用を制限する
    受信装置。
  2. 前記アプリケーション制御部は、前記第１のアプリケーションによる前記放送リソースを利用する動作の継続が認められない場合、前記第１のアプリケーションの動作を継続するとともに、前記放送リソースの表示を非表示にする
    請求項１に記載の受信装置。
  3. 前記アプリケーション制御部は、前記第１のアプリケーションによる前記放送リソースを利用する動作の継続が認められない場合、前記第１のアプリケーションの動作を終了するとともに、前記放送リソースを通常の状態で表示する
    請求項１に記載の受信装置。
  4. 前記アプリケーション制御部は、前記第１のアプリケーションによる前記放送リソースを利用する動作の継続が認められる場合、前記第１のアプリケーションを、前記第２のアプリケーションとして動作を継続させる
    請求項１に記載の受信装置。
  5. 前記第２のアプリケーションの動作を制御するためのトリガ情報を取得するトリガ情報取得部をさらに備え、
    前記制御情報取得部は、前記トリガ情報に基づいて、前記第２の制御情報を取得する
    請求項４に記載の受信装置。
  6. 前記アプリケーション制御部は、前記第１の制御情報に含まれる、放送サービスごとのアクセス権を示す放送パーミッション情報に基づいて、前記第１のアプリケーションが前記放送リソースへのアクセス権を有していない場合に、前記第１のアプリケーションによる前記放送リソースの利用を制限する
    請求項１に記載の受信装置。
  7. 前記アプリケーション制御部は、前記第１のアプリケーションが前記放送リソースへのアクセス権を有していない場合、前記第１のアプリケーションの動作を継続するとともに、前記放送リソースの表示を非表示にする
    請求項６に記載の受信装置。
  8. 前記アプリケーション制御部は、前記第１のアプリケーションが前記放送リソースへのアクセス権を有していない場合、前記第１のアプリケーションの動作を終了するとともに、前記放送リソースを通常の状態で表示する
    請求項６に記載の受信装置。
  9. 前記アプリケーション取得部は、所定の証明書を用いて、前記第１の制御情報に含まれる署名情報の検証に成功した場合に、前記第１のアプリケーションを取得する
    請求項６に記載の受信装置。
  10. 前記放送パーミッション情報は、前記放送サービスごとに、ビットマップ形式で指定される
    請求項６に記載の受信装置。
  11. 受信装置の受信方法において、
    前記受信装置が、
    デジタル放送信号を受信し、
    前記デジタル放送信号で送信される放送リソースの利用を要求可能な第１のアプリケーションを取得し、
    前記第１のアプリケーションの動作を制御するための第１の制御情報を取得し、
    前記第１のアプリケーションにより前記放送リソースの利用が要求された場合、前記第１の制御情報に基づいて、前記第１のアプリケーションによる前記放送リソースの利用を制御し、
    放送サービス内で起動される第２のアプリケーションの動作を制御するための第２の制御情報をさらに取得し、
    前記第１の制御情報と、前記第２の制御情報との照合の結果に基づいて、前記第１のアプリケーションによる前記放送リソースを利用する動作の継続が認められない場合に、前記第１のアプリケーションによる前記放送リソースの利用を制限する
    ステップを含む受信方法。
JP2016521030A 2014-05-22 2015-05-08 受信装置、及び、受信方法 Expired - Fee Related JP6544352B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2014106129 2014-05-22
JP2014106129 2014-05-22
PCT/JP2015/063268 WO2015178218A1 (ja) 2014-05-22 2015-05-08 受信装置、受信方法、送信装置、及び、送信方法

Publications (2)

Publication Number Publication Date
JPWO2015178218A1 JPWO2015178218A1 (ja) 2017-04-20
JP6544352B2 true JP6544352B2 (ja) 2019-07-17

Family

ID=54553891

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016521030A Expired - Fee Related JP6544352B2 (ja) 2014-05-22 2015-05-08 受信装置、及び、受信方法

Country Status (5)

Country Link
US (3) US10321183B2 (ja)
EP (2) EP3796665A1 (ja)
JP (1) JP6544352B2 (ja)
KR (1) KR102347851B1 (ja)
WO (1) WO2015178218A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102347851B1 (ko) * 2014-05-22 2022-01-06 소니그룹주식회사 수신 장치, 수신 방법, 송신 장치 및 송신 방법
KR102504174B1 (ko) 2018-05-11 2023-02-27 삼성전자주식회사 전자 장치 및 그의 제어방법
CN112492391B (zh) * 2019-09-11 2024-03-22 Vidaa(荷兰)国际控股有限公司 HbbTV应用添加到应用列表的方法及相关设备

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6591266B1 (en) * 2000-07-14 2003-07-08 Nec Corporation System and method for intelligent caching and refresh of dynamically generated and static web content
KR20080060818A (ko) * 2006-12-27 2008-07-02 엘지전자 주식회사 데이터 방송 신호 수신 장치 및 데이터 방송 신호를처리하는 방법
JP5493627B2 (ja) 2009-09-15 2014-05-14 ソニー株式会社 情報処理装置、データ管理方法、およびプログラム
US9078031B2 (en) * 2010-10-01 2015-07-07 Sony Corporation Reception apparatus, reception method, and program
JP5544395B2 (ja) * 2011-05-19 2014-07-09 日本放送協会 受信機
EP2750309A4 (en) * 2011-08-26 2015-07-15 Japan Broadcasting Corp RECEIVERS AND RECEIVER PROCEDURES
EP3780591B1 (en) 2011-12-02 2023-04-12 Sony Group Corporation Information processing apparatus, information processing method, and program to activate an application
US8930988B2 (en) * 2011-12-21 2015-01-06 Sony Corporation Reception apparatus, reception method, program, and information processing system
JP5959206B2 (ja) 2012-01-18 2016-08-02 ソニー株式会社 受信装置、受信方法、及びプログラム
US9195840B2 (en) * 2012-04-23 2015-11-24 Google Inc. Application-specific file type generation and use
BR112014001763A2 (pt) 2012-06-01 2017-02-21 Sony Corp aparelho e método de processamento de informação, programa, e, aparelho transmissor de tabela de informação de aplicativo
BR112014008364A2 (pt) * 2012-08-21 2017-04-18 Sony Corp aparelho e método de processamento de informação, programa, e, aparelho de servidor
TW201414295A (zh) * 2012-09-20 2014-04-01 Sony Corp 收訊裝置、收訊方法、播送裝置、播送方法、程式、及連動應用程式控制系統
KR102347851B1 (ko) * 2014-05-22 2022-01-06 소니그룹주식회사 수신 장치, 수신 방법, 송신 장치 및 송신 방법

Also Published As

Publication number Publication date
US10945028B2 (en) 2021-03-09
EP3796665A1 (en) 2021-03-24
US20210152875A1 (en) 2021-05-20
EP3148205A1 (en) 2017-03-29
US20190313145A1 (en) 2019-10-10
JPWO2015178218A1 (ja) 2017-04-20
EP3148205A4 (en) 2017-12-27
US10321183B2 (en) 2019-06-11
KR102347851B1 (ko) 2022-01-06
WO2015178218A1 (ja) 2015-11-26
KR20170012211A (ko) 2017-02-02
US11405683B2 (en) 2022-08-02
US20170142474A1 (en) 2017-05-18

Similar Documents

Publication Publication Date Title
US10171874B2 (en) Receiving device, receiving method, and program
JP6082946B2 (ja) 受信装置、受信方法、プログラム、及び情報処理システム
JP6346859B2 (ja) 受信装置、受信方法、送信装置、及び、送信方法
JP6276593B2 (ja) 受信装置、受信方法、及びプログラム
CA2838471C (en) Receiving apparatus, reception method, transmitting apparatus, transmission method, and program
WO2014021126A1 (ja) 受信装置、受信方法、送信装置、及び送信方法
US11405683B2 (en) Reception apparatus, reception method, transmission apparatus, and transmission method for controlling termination of application
US11889163B2 (en) Receiving device, receiving method, transmitting device, and transmitting method
KR102532046B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
KR102460356B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
KR102460444B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
KR102611253B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
WO2016035588A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180427

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180427

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20181227

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190220

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190312

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190510

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190521

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190603

R151 Written notification of patent or utility model registration

Ref document number: 6544352

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

LAPS Cancellation because of no payment of annual fees