KR20180113514A - 수신 장치, 송신 장치 및 데이터 처리 방법 - Google Patents

수신 장치, 송신 장치 및 데이터 처리 방법 Download PDF

Info

Publication number
KR20180113514A
KR20180113514A KR1020187021835A KR20187021835A KR20180113514A KR 20180113514 A KR20180113514 A KR 20180113514A KR 1020187021835 A KR1020187021835 A KR 1020187021835A KR 20187021835 A KR20187021835 A KR 20187021835A KR 20180113514 A KR20180113514 A KR 20180113514A
Authority
KR
South Korea
Prior art keywords
file
resource
distribution
information
application
Prior art date
Application number
KR1020187021835A
Other languages
English (en)
Other versions
KR102656879B1 (ko
Inventor
야스아키 야마기시
다츠야 이가라시
요시하루 데와
Original Assignee
소니 주식회사
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 소니 주식회사 filed Critical 소니 주식회사
Publication of KR20180113514A publication Critical patent/KR20180113514A/ko
Application granted granted Critical
Publication of KR102656879B1 publication Critical patent/KR102656879B1/ko

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/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/458—Scheduling content for creating a personalised stream, e.g. by combining a locally stored advertisement with an incoming stream; Updating operations, e.g. for OS modules ; time-related management operations
    • 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
    • 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/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
    • 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/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/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • 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/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • 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
    • 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/4351—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream involving reassembling additional data, e.g. rebuilding an executable program from recovered modules
    • 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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • 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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64315—DVB-H
    • 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/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • H04N21/8133—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts specifically related to the content, e.g. biography of the actors in a movie, detailed information about an article seen in a video program
    • 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/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • 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)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

본 기술은, 콘텐츠에 부수되는 애플리케이션의 리소스 파일의 배신에 따른 처리를 행할 수 있도록 하는 수신 장치, 송신 장치 및 데이터 처리 방법에 관한 것이다. 수신 장치는, 콘텐츠를 수신하고, 콘텐츠와 함께 전송되는, 콘텐츠에 부수되는 애플리케이션의 일부인 하나 또는 복수의 리소스 파일의 배신에 관한 리소스 배신 정보를 취득하고, 취득된 리소스 배신 정보에 기초하여, 리소스 파일의 배신에 따른 처리를 행한다. 본 기술은, 예를 들어 디지털 방송을 수신 가능한 텔레비전 수상기에 적용할 수 있다.

Description

수신 장치, 송신 장치 및 데이터 처리 방법
본 기술은, 수신 장치, 송신 장치 및 데이터 처리 방법에 관한 것이며, 특히 콘텐츠에 부수되는 애플리케이션의 리소스 파일의 배신에 따른 처리를 행할 수 있도록 한 수신 장치, 송신 장치 및 데이터 처리 방법에 관한 것이다.
프로그램이나 CM 등의 콘텐츠에 부수되는 애플리케이션(이하, 간단히 애플리케이션이라고도 함)의 배신 라이프 사이클 컨트롤에, AIT(Application Information Table) 등의 애플리케이션 제어 정보를 사용하는 것이 알려져 있다(예를 들어, 특허문헌 1 참조). 이 애플리케이션 제어 정보에 의해, 수신기에서는, 애플리케이션의 기동이나 종료의 동작을 제어할 수 있다.
일본 특허 공개 제2015-180065호 공보
그런데, 애플리케이션의 배신 라이프 사이클 컨트롤을 간소화하는 한편, 수신기측에서, 콘텐츠에 부수되는 애플리케이션의 리소스 파일의 배신에 따른 처리를 행할 수 있도록 하기 위한 제안이 요청되고 있었다.
본 기술은 이러한 상황을 감안하여 이루어진 것이며, 콘텐츠에 부수되는 애플리케이션의 리소스 파일의 배신에 따른 처리를 행할 수 있도록 하는 것이다.
본 기술의 제1 측면의 수신 장치는, 콘텐츠를 수신하는 수신부와, 상기 콘텐츠와 함께 전송되는, 상기 콘텐츠에 부수되는 애플리케이션의 일부인 하나 또는 복수의 리소스 파일의 배신에 관한 리소스 배신 정보를 취득하는 취득부와, 취득된 상기 리소스 배신 정보에 기초하여, 상기 리소스 파일의 배신에 따른 처리를 행하는 처리부를 구비하는 수신 장치이다.
본 기술의 제1 측면의 수신 장치는, 독립된 장치여도 되고, 하나의 장치를 구성하고 있는 내부 블록이어도 된다. 또한, 본 기술의 제1 측면의 데이터 처리 방법은, 상술한 본 기술의 제1 측면의 수신 장치에 대응하는 데이터 처리 방법이다.
본 기술의 제1 측면의 수신 장치 및 데이터 처리 방법에 있어서는, 콘텐츠가 수신되고, 상기 콘텐츠와 함께 전송되는, 상기 콘텐츠에 부수되는 애플리케이션의 일부인 하나 또는 복수의 리소스 파일의 배신에 관한 리소스 배신 정보가 취득되고, 취득된 상기 리소스 배신 정보에 기초하여, 상기 리소스 파일의 배신에 따른 처리가 행해진다.
본 기술의 제2 측면의 송신 장치는, 콘텐츠에 부수되는 애플리케이션의 일부인 하나 또는 복수의 리소스 파일의 배신에 관한 리소스 배신 정보를 생성하는 생성부와, 상기 콘텐츠와 함께, 상기 리소스 배신 정보를 송신하는 송신부를 구비하는 송신 장치이다.
본 기술의 제2 측면의 송신 장치는, 독립된 장치여도 되고, 하나의 장치를 구성하고 있는 내부 블록이어도 된다. 또한, 본 기술의 제2 측면의 데이터 처리 방법은, 상술한 본 기술의 제2 측면의 송신 장치에 대응하는 데이터 처리 방법이다.
본 기술의 제2 측면의 송신 장치 및 데이터 처리 방법에 있어서는, 콘텐츠에 부수되는 애플리케이션의 일부인 하나 또는 복수의 리소스 파일의 배신에 관한 리소스 배신 정보가 생성되고, 상기 콘텐츠와 함께, 상기 리소스 배신 정보가 송신된다.
본 기술의 제1 측면 및 제2 측면에 따르면, 콘텐츠에 부수되는 애플리케이션의 리소스 파일의 배신에 따른 처리를 행할 수 있다.
또한, 여기에 기재된 효과는 반드시 한정되는 것은 아니며, 본 개시 중에 기재된 어느 효과여도 된다.
도 1은, 본 기술을 적용한 전송 시스템의 일 실시 형태의 구성예를 도시하는 도면이다.
도 2는, 클라이언트 장치의 구성예를 도시하는 도면이다.
도 3은, 본 기술의 IP 전송 방식의 프로토콜 스택의 예를 도시하는 도면이다.
도 4는, LLS 시그널링과 SLS 시그널링의 관계를 도시하는 도면이다.
도 5는, 애플리케이션 URL에 따른 애플리케이션 제어를 설명하는 도면이다.
도 6은, SLS 시그널링 채널과 LCC 채널의 관계를 도시하는 도면이다.
도 7은, 스타트업 패키지 파일의 구조의 예를 도시하는 도면이다.
도 8은, W3C의 Web App Manifest의 포맷의 예를 도시하는 도면이다.
도 9는, 확장 Web App Manifest를 이용하는 경우의 스타트업 패키지 파일의 기술예를 도시하는 도면이다.
도 10은, 확장 Web App Manifest의 포맷의 예를 도시하는 도면이다.
도 11은, 확장 Web App Manifest의 기술예를 도시하는 도면이다.
도 12는, 도 11의 확장 Web App Manifest의 기술예를 시계열로 도시한 도면이다.
도 13은, EFDT에 기술되는 전송 제어 정보를 설명하는 도면이다.
도 14는, 전형적인 애플리케이션의 구성예를 도시하는 도면이다.
도 15는, 방송 모드가 설정되었을 때 처리되는 애플리케이션에 관한 데이터의 흐름을 설명하는 도면이다.
도 16은, 방송 모드가 설정된 경우의 송신측의 처리의 흐름에 대하여 설명하는 흐름도이다.
도 17은, 방송 모드가 설정된 경우의 수신측의 처리의 흐름에 대하여 설명하는 흐름도이다.
도 18은, 방송 모드가 설정된 경우의 수신측의 처리의 흐름에 대하여 설명하는 흐름도이다.
도 19는, 하이브리드 모드가 설정되었을 때 처리되는 애플리케이션에 관한 데이터의 흐름을 설명하는 도면이다.
도 20은, 하이브리드 모드가 설정된 경우의 송신측의 처리의 흐름에 대하여 설명하는 흐름도이다.
도 21은, 하이브리드 모드가 설정된 경우의 수신측의 처리의 흐름에 대하여 설명하는 흐름도이다.
도 22는, 하이브리드 모드가 설정된 경우의 수신측의 처리의 흐름에 대하여 설명하는 흐름도이다.
도 23은, 통신 모드가 설정되었을 때 처리되는 애플리케이션에 관한 데이터의 흐름을 설명하는 도면이다.
도 24는, 통신 모드가 설정된 경우의 송신측의 처리의 흐름에 대하여 설명하는 흐름도이다.
도 25는, 통신 모드가 설정된 경우의 수신측의 처리의 흐름에 대하여 설명하는 흐름도이다.
도 26은, 통신 모드가 설정된 경우의 수신측의 처리의 흐름에 대하여 설명하는 흐름도이다.
도 27은, USD 메타데이터의 포맷의 예를 도시하는 도면이다.
도 28은, S-TSID 메타데이터의 포맷의 예를 도시하는 도면이다.
도 29는, SrcFlow 요소의 포맷의 예를 도시하는 도면이다.
도 30은, EFDT 요소의 포맷의 예를 도시하는 도면이다.
도 31은, EFDT의 XML 스키마의 예를 도시하는 도면이다.
도 32는, 컴퓨터의 구성예를 도시하는 도면이다.
이하, 도면을 참조하면서 본 기술의 실시 형태에 대하여 설명한다. 또한, 설명은 이하의 순서로 행하기로 한다.
1. 시스템의 구성
2. 본 기술의 개요
3. 구체적인 운용예
(A) 방송 모드
(B) 하이브리드 모드
(C) 통신 모드
4. 시그널링의 예
5. 변형예
6. 컴퓨터의 구성
<1. 시스템의 구성>
(전송 시스템의 구성)
도 1은, 본 기술을 적용한 전송 시스템의 일 실시 형태의 구성예를 도시하는 도면이다. 또한, 시스템이란, 복수의 장치가 논리적으로 집합한 것을 말한다.
도 1에 있어서, 전송 시스템(1)은, 송신측 시스템(10)과, 수신측의 클라이언트 장치(20)로 구성된다. 전송 시스템(1)에 있어서는, 송신측 시스템(10)으로부터 송신되는 데이터가, 방송망으로서의 전송로(80), 또는 통신망으로서의 인터넷(90)을 통하여 클라이언트 장치(20)에 의해 수신된다.
예를 들어, 전송 시스템(1)에서는, 현재 책정이 진행되고 있는 미국의 차세대 방송 규격인 ATSC(Advanced Television Systems Committee) 3.0 등의 소정의 규격에 준거한 데이터 전송이 행해진다.
또한, ATSC3.0에서는, 전송 방식으로서, 현재 널리 보급되어 있는 MPEG2-TS(Transport Stream) 방식이 아니라, 통신 분야에서 사용되고 있는 IP(Internet Protocol) 패킷을 디지털 방송에 사용한 IP 전송 방식을 도입함으로써, 보다 고도의 서비스를 제공하는 것이 상정되어 있다.
송신측 시스템(10)은, ATSC3.0 등의 소정의 규격에 준거한 데이터를 송신하기 위한 처리를 행한다. 송신측 시스템(10)은, DASH 서버(101), 시그널링 서버(102), 애플리케이션 서버(103), SCH/PKG 서버(104), 방송 서버(105) 및 통신 서버(106)로 구성된다.
DASH 서버(101)는, 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 서버(101)는, 외부로부터 MPD 메타데이터를 생성하기 위한 데이터나, 콘텐츠의 데이터 등을 수신한다. DASH 서버(101)는, 외부로부터의 데이터에 기초하여, MPD 메타데이터를 생성하고, 시그널링 서버(102)에 송신한다. 또한, DASH 서버(101)는, 외부로부터의 데이터에 기초하여, 프로그램이나 CM 등의 콘텐츠의 세그먼트(DASH 세그먼트)의 파일을 생성하고, 방송 서버(105) 또는 통신 서버(106)에 송신한다.
시그널링 서버(102)는, 외부로부터 시그널링을 생성하기 위한 데이터를 수신한다. 또한, 시그널링 서버(102)는, DASH 서버(101)로부터의 MPD 메타데이터를 수신한다. 시그널링 서버(102)는, 외부로부터의 데이터나, MPD 메타데이터 등에 기초하여, 시그널링을 생성하고, 방송 서버(105) 또는 통신 서버(106)에 송신한다.
여기서, 예를 들어 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)를 확장한 것이다. 또한, S-TSID 메타데이터는, ROUTE 세션으로 전송되는 EFDT(Extended FDT)를 특정할 수 있다. EFDT는, FLUTE에서 도입되어 있었던 FDT(File Delivery Table)를 확장한 것이며, 전송용 제어 정보이다.
MPD 메타데이터는, 상술한 바와 같이, 스트리밍 배신되는 동화상이나 음성의 파일의 관리 정보이다. 또한, SLT, USD, S-TSID, MPD 등의 메타데이터는, 예를 들어 XML(Extensible Markup Language) 등의 마크업 언어에 의해 기술할 수 있다.
시그널링 서버(102)는, SLT 메타데이터를 포함하는 LLS 시그널링과, USD 메타데이터, S-TSID 메타데이터 및 MPD 메타데이터를 포함하는 SLS 시그널링을 생성한다. 단, 시그널링 서버(102)는, DASH 서버(101)에 의해 생성된 MPD 메타데이터를, SLS 시그널링으로서 처리한다.
애플리케이션 서버(103)는, 외부로부터 애플리케이션을 구성하는 파일을 생성하기 위한 데이터를 수신한다. 애플리케이션 서버(103)는, 외부로부터의 데이터에 기초하여, 애플리케이션을 구성하는 스타트업 페이지 파일(예를 들어, HTML 문서 파일 등)이나, 하나 또는 복수의 리소스 파일(예를 들어, 화상 파일이나 스크립트 파일 등)을 생성하고, SCH/PKG 서버(104)에 송신한다.
또한, 애플리케이션은, 프로그램이나 CM 등의 콘텐츠에 부수되는 애플리케이션이다. 또한, 이러한 애플리케이션으로서는, 예를 들어 HTML5(HyperText Markup Language 5) 등의 마크업 언어나, JavaScript(등록 상표) 등의 스크립트 언어로 개발된 애플리케이션을 사용할 수 있다.
SCH/PKG 서버(104)는, 애플리케이션을 구성하는 파일(리소스 파일)의 배신 스케줄을 결정하고, 애플리케이션 매니페스트 파일에 포함한다. 또한, SCH/PKG 서버(104)는, 애플리케이션 매니페스트 파일, 스타트업 페이지 파일 및 리소스 파일을 포함하는 스타트업 패키지 파일을 생성하고, 방송 서버(105)에 송신한다.
또한, 스타트업 패키지 파일과 애플리케이션 매니페스트 파일의 상세는, 후술한다. 또한, 스타트업 패키지 파일에는, 스타트업 페이지 파일과 리소스 파일을 반드시 포함할 필요는 없다. 또한, 스타트업 페이지 파일과 리소스 파일은, 통신 경유로 배신되는 경우, 통신 서버(106)에 송신된다.
또한, SCH/PKG 서버(104)는, 애플리케이션을 구성하는 파일(리소스 파일)의 배신 스케줄에 따른 전송 제어 정보를 포함하는 EFDT를 생성하고, 방송 서버(105)에 송신한다. 또한, 전송 제어 정보는, 시간대에 따라 배신 스케줄이 변경될 가능성이 있는 특정한 리소스 파일에 관한 정보이며, 그 상세에 대해서는 후술한다.
또한, SCH/PKG 서버(104)는, 스타트업 페이지 파일에 의해 뒤에서 참조될 리소스 파일인 추가 리소스 파일을, 방송 서버(105) 또는 통신 서버(106)에 송신한다.
방송 서버(105)는, ATSC3.0 등의 디지털 방송의 규격에 준거한 데이터 전송을 행하는 것이 가능한 송신기이다.
방송 서버(105)는, DASH 서버(101)로부터 송신되어 오는 DASH 세그먼트, 시그널링 서버(102)로부터 송신되어 오는 시그널링, 및 SCH/PKG 서버(104)로부터 송신되는 애플리케이션에 관한 파일(예를 들어, 스타트업 패키지 파일 등)을 수신한다. 방송 서버(105)는, DASH 세그먼트, 시그널링 및 애플리케이션에 관한 파일을 처리하고, 전송로(80)를 통하여 송신(일제 동보 배신)한다.
통신 서버(106)는, 인터넷(90)에 접속된 클라이언트 장치(20)로부터의 요구에 따라, 인터넷(90)을 통하여 각종 데이터를 제공하는 서버이다.
통신 서버(106)는, DASH 서버(101)로부터 송신되어 오는 DASH 세그먼트, 시그널링 서버(102)로부터 송신되어 오는 시그널링, 및 SCH/PKG 서버(104)로부터 송신되는 애플리케이션에 관한 파일(예를 들어, 추가 리소스 파일 등)을 수신한다. 통신 서버(106)는, DASH 세그먼트, 시그널링 및 애플리케이션에 관한 파일을 처리한다. 그리고, 통신 서버(106)는, 클라이언트 장치(20)로부터의 요구에 따라, 인터넷(90)을 통하여, 각종 파일을 송신한다.
클라이언트 장치(20)는, ATSC3.0 등의 소정의 규격에 준거한 전송 데이터를 수신 가능한 수신기이다. 예를 들어, 클라이언트 장치(20)는, 텔레비전 수상기나 셋톱 박스 등의 고정 수신기, 혹은 스마트폰이나 휴대 전화기, 태블릿형 컴퓨터 등의 모바일 수신기이다. 또한, 클라이언트 장치(20)는, 예를 들어 차량 탑재 TV 등의 자동차에 탑재되는 기기여도 된다. 또한, 클라이언트 장치(20)의 상세한 구성은, 도 2를 참조하여 후술한다.
클라이언트 장치(20)는, 방송 서버(105)로부터 전송로(80)를 통하여 송신(일제 동보 배신)되어 오는, DASH 세그먼트, 시그널링 등의 파일을 수신하여 처리함으로써, 방송 프로그램 등의 콘텐츠의 영상이나 음성을 출력한다.
또한, 클라이언트 장치(20)는, 통신 기능을 갖는 경우, 인터넷(90)을 통하여, 통신 서버(106)에 액세스하여, 각종 파일을 취득할 수 있다. 예를 들어, 클라이언트 장치(20)는, 통신 서버(106)로부터 인터넷(90)을 통하여 송신(적응적으로 스트리밍 배신)되는, DASH 세그먼트나 MPD 메타데이터 등의 파일을 수신하여 처리함으로써, VOD(Video On Demand) 프로그램 등의 콘텐츠의 영상이나 음성을 출력한다.
또한, 클라이언트 장치(20)는, 방송 서버(105) 또는 통신 서버(106)로부터 송신되는, 애플리케이션에 관한 파일을 수신하여 처리함으로써, 애플리케이션을 실행한다. 즉, 클라이언트 장치(20)에서는, 방송 경유 또는 통신 경유로 취득된 콘텐츠에 부수하여, 방송 경유 또는 통신 경유로 취득된 애플리케이션이 실행된다. 단, 애플리케이션은, 어떠한 정보를 명시적으로 표시할 뿐만 아니라, 비표시로(백그라운드에서) 동작하는 경우도 있다(유저에게 인식되지 않고 기동하는 경우가 있음).
또한, 클라이언트 장치(20)는, 스타트업 패키지 파일의 애플리케이션 매니페스트 파일에 포함되는 배신 스케줄 정보나, EFDT에 포함되는 전송 제어 정보에 기초하여, 애플리케이션의 리소스 파일의 배신에 따른 처리를 행할 수 있다. 또한, 배신 스케줄 정보나 전송 제어 정보의 상세는, 도 7 내지 도 13 등을 참조하여 후술한다.
또한, 전송 시스템(1)에 있어서, 전송로(80)는, 지상파(지상파 방송) 외에, 예를 들어 방송 위성(BS: Broadcasting Satellite)이나 통신 위성(CS: Communications Satellite)을 이용한 위성 방송, 혹은 케이블을 이용한 유선 방송(CATV) 등이어도 된다.
여기서, 도 1의 전송 시스템(1)에 있어서는, 설명을 간단하게 하기 위해, 클라이언트 장치(20)를 하나만 도시하고 있지만, 클라이언트 장치(20)는 복수 설치할 수 있고, 송신측 시스템(10)이 송신(일제 동보 배신)하는 디지털 방송 신호는, 전송로(80)를 통하여 복수의 클라이언트 장치(20)에서 동시에 수신할 수 있다.
또한, 송신측 시스템(10)도 복수 설치할 수 있다. 복수의 송신측 시스템(10)의 각각에서는, 별개의 채널로서의, 예를 들어 별개의 주파수 대역에서, 방송 스트림을 포함하는 디지털 방송 신호를 송신하고, 클라이언트 장치(20)에서는, 복수의 송신측 시스템(10)의 각각의 채널 중에서 방송 스트림을 수신하는 채널을 선택할 수 있다.
(클라이언트 장치의 구성)
도 2는, 도 1의 클라이언트 장치(20)의 구성예를 도시하는 도면이다.
도 2에 있어서, 클라이언트 장치(20)는, 처리부(201), 입력부(202), 메모리(203), 수신부(204), 방송 미들웨어(205), DASH 클라이언트(206), 디코더(207), 출력부(208), 브라우저(209) 및 통신부(210)로 구성된다.
처리부(201)는, 클라이언트 장치(20)의 각 부의 동작을 제어하는 처리 등을 행한다.
입력부(202)는, 유저의 조작에 따른 조작 신호를 처리부(201)에 공급한다. 처리부(201)는, 입력부(202)로부터 공급되는 조작 신호에 기초하여, 클라이언트 장치(20)의 각 부의 동작을 제어한다. 메모리(203)는, 처리부(201)로부터의 제어에 따라, 각종 데이터를 기억한다.
수신부(204)는, 튜너 등으로 구성된다. 수신부(204)는, 안테나(221)에 의해, 방송 서버(105)로부터 전송로(80)를 통하여 송신(일제 동보 배신)되어 오는 방송파(디지털 방송 신호)를 수신하여 처리하고, 그에 의해 얻어지는 데이터를, 방송 미들웨어(205)에 공급한다.
방송 미들웨어(205)는, 수신부(204)로부터 공급되는 데이터를 처리하고, 처리부(201), DASH 클라이언트(206) 또는 브라우저(209)에 공급한다. 여기서, 처리 대상의 데이터 중, MPD 메타데이터 및 DASH 세그먼트는, DASH 클라이언트(206)에 공급되고, 애플리케이션에 관한 데이터는, 브라우저(209)에 공급되고, 시그널링 등의 데이터는, 처리부(201)에 공급된다.
DASH 클라이언트(206)에는, 방송 미들웨어(205)로부터 MPD 메타데이터 및 DASH 세그먼트가 공급된다. DASH 클라이언트(206)는, MPD 메타데이터에 기초하여, DASH 세그먼트를 처리한다. 이 DASH 세그먼트를 처리하여 얻어지는 비디오와 오디오의 데이터는, 디코더(207)에 공급된다.
디코더(207)는, 소정의 복호 방식(예를 들어 HEVC(High Efficiency Video Coding)나 AAC(Advanced Audio Coding) 등)에 따라, DASH 클라이언트(206)로부터 공급되는 비디오와 오디오의 데이터의 디코드를 행한다. 이 디코드에 의해 얻어지는 비디오와 오디오의 데이터는, 출력부(208)에 공급된다.
출력부(208)는, 디코더(207)로부터 공급되는 비디오와 오디오의 데이터를 출력한다. 이에 의해, 클라이언트 장치(20)에서는, 프로그램이나 CM 등의 콘텐츠가 재생되고, 그 영상이나 음성이 출력되게 된다.
브라우저(209)는, 예를 들어 HTML5에 대응한 브라우저이다. 브라우저(209)는, 방송 미들웨어(205)로부터 공급되는, 애플리케이션의 데이터를 처리하고, 출력부(208)에 공급한다. 출력부(208)는, 브라우저(209)로부터 공급되는 애플리케이션의 데이터를 출력한다. 이에 의해, 클라이언트 장치(20)에서는, 프로그램 등에 연동하여, 애플리케이션의 영상이 표시되게 된다.
통신부(210)는, 처리부(201)로부터의 제어에 따라, 인터넷(90)을 통하여, 통신 서버(106)와 데이터의 수수를 행한다. 통신부(210)에 의해 수신되는 데이터 중, MPD 메타데이터 및 DASH 세그먼트는, DASH 클라이언트(206)에 공급되고, 애플리케이션에 관한 데이터는, 브라우저(209)에 공급되고, 시그널링 등의 데이터는, 처리부(201)에 공급된다. 이들 통신 경유로 취득된 데이터에 대한 처리는, 상술한 방송 경유로 취득된 데이터와 마찬가지이기 때문에, 여기서는, 그 설명은 생략한다.
또한, 처리부(201)는, 제어부(211), 프록시 서버(212) 및 렌더러(213)를 포함하여 구성된다. 제어부(211)는, 클라이언트 장치(20)의 각 부의 동작을 제어한다. 프록시 서버(212)는, 처리 대상의 데이터의 송수신에 관한 처리 등을 행한다. 렌더러(213)는, 처리 대상의 데이터를 출력하기 위한 처리를 행한다.
클라이언트 장치(20)는, 이상과 같이 구성된다.
<2. 본 기술의 개요>
(본 기술의 프로토콜 스택)
도 3은, 본 기술의 IP 전송 방식의 프로토콜 스택의 예를 도시하는 도면이다.
도 3에 있어서, 가장 하위의 계층은, 물리층(Physical Layer)으로 된다. ATSC3.0 등의 IP 전송 방식의 디지털 방송에서는, 일방향의 방송을 이용한 전송에 한하지 않고, 일부의 데이터를, 쌍방향의 통신을 이용하여 전송하는 경우가 있지만, 방송(Broadcast)을 이용하는 경우, 그 물리층(Physical Layer)은, 서비스(채널)를 위해 할당된 방송파의 주파수 대역이 대응하게 된다.
물리층(Physical Layer)의 상위의 계층은, 데이터 링크층(Data Link Layer)으로 된다. 또한, 데이터 링크층의 상위의 계층은, IP층으로 된다. IP층은, 통신의 계층 모델에 있어서의 네트워크층에 상당하는 것이며, IP 어드레스에 의해 IP 패킷이 특정된다. IP층에 인접하는 상위 계층은, 통신의 계층 모델에 있어서의 트랜스포트층에 상당하는 UDP(User Datagram Protocol)층으로 되고, 또한 그 상위의 계층은, ROUTE로 된다.
또한, UDP층의 상위의 계층, 즉 UDP 패킷을 포함하는 IP 패킷(IP/UDP 패킷)에는, SLT 메타데이터가 저장되어, 전송된다. SLS 메타데이터는, LLS 시그널링이며, 방송 네트워크에 있어서의 스트림이나 서비스의 구성을 나타내는 기본 정보를 포함하고 있다.
ROUTE는, 스트리밍 파일 전송용 프로토콜이며, FLUTE를 확장한 것이다. ROUTE에 인접하는 상위 계층 중, 일부의 계층은, 시그널링(Signaling)과, LCC(Locally Cached Content) 콘텐츠(LCC(NRT))로 된다.
이 시그널링은, SLS 시그널링이며, 예를 들어 USD, S-TSID, MPD 등의 메타데이터가 포함된다. 즉, 도 4에 도시하는 바와 같이, 클라이언트 장치(20)에서는, 최초로, LLS 시그널링으로서의 SLT 메타데이터를 취득하고 나서, 서비스 단위의 SLS 시그널링(S-TSID 등)을 취득하게 된다.
도 3의 설명으로 되돌아가, LCC 콘텐츠는, 클라이언트 장치(20)의 스토리지에 일단 축적된 후에 재생이 행해지는 콘텐츠이다. 또한, LCC(Locally Cached Content)는, NRT(Non Real Time)라고 칭해지는 경우가 있다. 상술한 애플리케이션은, LCC 콘텐츠로서 ROUTE 세션에 의해 전송할 수 있다. 또한, LCC 콘텐츠로서, 예를 들어 전자 서비스 가이드(ESG: Electronic Service Guide) 등의 콘텐츠가, ROUTE 세션에 의해 전송되도록 해도 된다.
ROUTE에 인접하는 상위 계층 중, 상술한 계층 이외의 다른 계층은, DASH 세그먼트(DASH)로 된다. 즉, 방송 프로그램 등의 콘텐츠를 구성하는 서비스 컴포넌트(비디오나 오디오, 자막 등)의 스트림 데이터는, ISO BMFF(ISO Base Media File Format)의 규격에 준한 DASH 세그먼트 단위로, ROUTE 세션에 의해 전송되게 된다.
또한, 쌍방향의 통신(Broadband)을 이용하는 경우, 그 물리층(Physical Layer)의 상위의 계층은, 데이터 링크층(Data Link Layer)으로 된다. 또한, 데이터 링크층의 상위의 계층은, 네트워크층에 상당하는 IP층으로 된다. 또한, IP층에 인접하는 상위 계층은, 트랜스포트층에 상당하는 TCP(Transmission Control Protocol)층으로 되고, 또한 TCP층에 인접하는 상위 계층은, 애플리케이션층에 상당하는 HTTP층으로 된다. 즉, 이들 계층에 의해, 인터넷(90) 등의 네트워크에서 가동하는 TCP/IP 등의 프로토콜이 실장된다.
HTTP층에 인접하는 상위 계층 중, 일부의 계층은, 시그널링(Signaling)과, LCC 콘텐츠(LCC(NRT))로 된다. 이 시그널링으로서는, 상술한 ROUTE에서 전송되는 시그널링 등, 모든 시그널링이 포함된다. 또한, LCC 콘텐츠는, 통신 경유로 취득되는 콘텐츠이며, 예를 들어 애플리케이션이 포함된다.
HTTP층에 인접하는 상위 계층 중, 상술한 계층 이외의 다른 계층은, DASH 세그먼트(DASH)로 된다. 즉, 쌍방향의 통신계 스트리밍 배신에서는, VOD 프로그램 등의 콘텐츠를 구성하는 서비스 컴포넌트(비디오나 오디오, 자막 등)의 스트림 데이터가, ISO BMFF의 규격에 준한 DASH 세그먼트 단위로 전송되게 된다.
이상과 같이, 본 기술의 IP 전송 방식의 프로토콜 스택에 있어서는, 일방향의 방송계 계층과, 쌍방향의 통신계 계층의 일부가 공통의 프로토콜로 되어, 일방향의 방송과 쌍방향의 통신에서, 콘텐츠를 구성하는 서비스 컴포넌트의 스트림 데이터를, ISO BMFF의 규격에 준한 DASH 세그먼트 단위로 전송할 수 있다. 그 때문에, 일방향의 방송계 스트리밍 배신과, 쌍방향의 통신계 스트리밍 배신의 양쪽을 행하는 경우에 있어서, 상위의 계층의 프로토콜이 공통화되어 있기 때문에, 예를 들어 방송 서버(105)나 클라이언트 장치(20)에서는, 실장의 부담이나 처리의 부담을 경감할 수 있다.
(애플리케이션의 제어)
그런데, 프로그램이나 CM 등의 콘텐츠에 부수되는 애플리케이션을 사용한 서비스를 제공할 때, 애플리케이션의 제어 모델을 심플하게 실장하는 제안이 요청되고 있다. 예를 들어, ATSC3.0에서는, 애플리케이션의 배신 라이프 사이클 컨트롤에, AST(Application Signaling Table)를 사용하는 것이 검토되고 있지만, AST를 이용하는 것 이외에, 보다 애플리케이션의 제어 모델을 심플하게 실장하는 것이 요구되고 있다.
예를 들어, 도 5에 도시하는 바와 같이, 콘텐츠에 부수되어 기동하는 애플리케이션의 URL(이하, 애플리케이션 URL(App URL)이라고 함)을, 특정한 파일(후술하는 애플리케이션 매니페스트 파일)이나 시그널링 등에 기술해 둠으로써, 애플리케이션의 제어 모델을 심플하게 실장할 수 있다. 이러한 실장을 행한 경우, 클라이언트 장치(20)에 있어서는, 서비스가 선국되었을 때, 즉시 그 파일이나 시그널링에 기술된 애플리케이션 URL에 따라, 애플리케이션이 취득되어, 기동되게 된다.
이러한 애플리케이션 URL에 따라 애플리케이션을 기동하는 방법을 채용한 경우, 당해 애플리케이션 URL에 의해, 애플리케이션의 최초 페이지의 파일(스타트업 페이지 파일(예를 들어 HTML 문서 파일))의 URL(스타트업 페이지 URL)을, 클라이언트 장치(20)에 통지할 수는 있다. 한편, 그 URL로 나타나는 페이지의 파일(스타트업 페이지 파일)에 있어서 참조되는, 화상 파일(예를 들어 jpeg 파일)이나 스크립트 파일(예를 들어 JavaScript(등록 상표)의 코드가 기술된 파일) 등의 각종 리소스 파일은, 최초 페이지의 파일(스타트업 페이지 파일)을 취득한 후에, 애플리케이션의 요구에 따라 필요한 타이밍에 방송 경유 또는 통신 경유(인터넷 경유)로 취득된다.
이 경우, 클라이언트 장치(20)의 브라우저(209)(도 2)에서는, 최초로 취득된 페이지의 파일(스타트업 페이지 파일)을 파싱(구문 분석)하여, 필요한 리소스 파일의 취득처를 나타내는 URL이 해결되면, 그 각각의 URL에 의해 특정되는 리소스 파일을 취득하기 위한 리퀘스트를 발행하게 된다. 일반적으로, HTML 문서(페이지)에서는, 복수의 리소스 파일을 참조하고 있기 때문에, 모든 리소스 파일이, 클라이언트 장치(20)의 메모리(203)(도 2) 내에 정렬된 시점에서, 애플리케이션(의 페이지)를 표시할 필요가 있다.
여기서, ATSC3.0에서는, 클라이언트 장치(20)의 브라우저(209)(도 2)가 액세스하는 곳(HTTP 리퀘스트를 보내는 곳)은, 로컬의 프록시 서버(212)(도 2)로 되어 있다. 그리고, ATSC3.0에서 규정되는 시그널링이나 트랜스포트 프로토콜을 종단하는 방송 미들웨어(205)(도 2)가, 방송 경유로 배신된 시그널링이나 콘텐츠를 로컬 파일 시스템에 전개하고, 로컬의 프록시 서버(212)(도 2) 상에 실장된 서버 사이드 스크립트(모듈) 등에 의한 프로그램 처리에 의해, 방송 미들웨어(205)(도 2)와 직접 또는 일체로 되어, DASH 클라이언트(206)(도 2)나 브라우저(209)(도 2) 상에서 실행되는 애플리케이션 등(클라이언트)으로부터의 취득 리퀘스트에 따른 모델이 상정되어 있다.
상술한 바와 같이, 브라우저(209)(도 2)가, 최초의 HTML 문서 파일(스타트업 페이지 파일)을 파싱하여, 그 HTML 문서 파일에 의해 참조되고 있는 리소스 파일의 취득 리퀘스트를 발행하였다고 해도, 그 리소스 파일이, 로컬 파일 시스템 상에 전개되어 있는 상태로 되어 있거나, 혹은 로컬의 프록시 서버(212)(도 2)의 서버 사이드 스크립트(모듈)가 액세스 가능한 상태로 되어 있지 않으면 안된다.
즉, 이러한 상태로 되어 있지 않으면, HTML 문서 파일(스타트업 페이지 파일)의 모든 리소스 파일을 표시 가능한 상태로 할 수 없는 채, 리소스 파일의 취득 리퀘스트가 타임 아웃으로 되고, 유저에 따라서는, 불완전한 상태에서 애플리케이션(의 페이지)가 로드되었다고 오인식되어 버리게 된다. 그 때문에, 모든 리소스 파일이 최초로 통합하여 준비되어 있는 것이 필수가 된다.
또한, 예를 들어 방송 프로그램에 부수되는 애플리케이션에서는, 최초의 HTML 문서 파일(스타트업 페이지 파일)을 로드한 후에, 각 씬마다 제시하는 리소스 파일이 순차 변화(추가)해 가는 것이 일반적이며, 이러한 프로그램 전체에 걸쳐 필요한 리소스 파일을 부감할 수 없다면, 프로토콜 처리나 메모리 관리의 최적화를 행할 수 없다. 즉, 어느 만큼의 리소스 파일이 어떠한 타이밍에 이후 필요로 되는지에 대하여, 프로그램 전체에 걸쳐 부감하여, 클라이언트 장치(20)의 컴퓨팅 리소스를, 각 서비스(프로그램)에 대하여 어떻게 분배할지 등에 대한 최적화를 도모할 필요가 있다.
본 기술에서는, 이들 문제를 해결하기 위해, 다음과 같은 제안을 행하기로 한다. 즉, ROUTE 프로토콜의 제어 정보인 EFDT에, 스타트업 패키지 파일에 대한 URL(스타트업 패키지 URL)을 포함하는 전송 제어 속성을 기술하고, 그 스타트업 패키지 파일에 포함되는 애플리케이션 매니페스트 파일에, 대상의 애플리케이션의 엔트리의 스타트업 페이지 파일(예를 들어 HTML 문서 파일)을 지정한 URL(스타트업 페이지 URL)이 기술되도록 한다.
즉, 이 스타트업 페이지 URL이, 상술한 애플리케이션 URL(도 5)에 상당하는 것으로 된다. 즉, 본 기술의 애플리케이션 제어에서는, AIT나 AST 등의 애플리케이션 제어 정보를 사용한 경우의 애플리케이션 제어와는 달리, 배신 라이프 사이클 컨트롤은 행하지 않고, 스타트업 페이지 URL(도 5의 애플리케이션 URL)에 따라, 즉시 애플리케이션이 기동(취득)된다고 하는 흐름으로 되므로, 애플리케이션의 제어 모델을 보다 심플하게 실장할 수 있다.
또한, 스타트업 패키지 파일은, ROUTE의 패키지 모드로 구성된 파일이며, 스타트업 페이지 파일(예를 들어 HTML 문서 파일)과, 리소스 파일(예를 들어 화상 파일이나 스크립트 파일 등)을 포함할 수 있다.
또한, 스타트업 패키지 파일의 애플리케이션 매니페스트 파일에는, 대상의 애플리케이션에 포함되는 리소스 파일 모두에 대한 배신 스케줄링의 최적화에 이용 가능한 속성을 기술할 수 있도록 한다. 이러한 리소스 파일의 전체를 부감하기 위한 리소스 리스트가 있다면, 리소스 파일의 취득 타이밍의 신뢰성 등을 향상시킬 수 있다. 또한, 각각의 리소스 파일의 전송 속성을, 각 파일의 URL을 포함하는 전송 제어 속성을 기술하는 EFDT에 기술할 수 있도록 한다.
또한, 상술한 바와 같이, SLS 시그널링이나 LCC 콘텐츠는, ROUTE 세션으로 전송되지만, 도 6에 도시하는 바와 같이, ROUTE 프로토콜의 서비스 레이어의 제어에 사용되는 S-TSID에 의해 기술되는 LCT 채널(세션) 중 하나가, 논리얼타임 콘텐츠인 LCC 콘텐츠의 전송에 할당되어 있다. 또한, LCC 콘텐츠용 LCT 채널에 있어서는, 파일 모드에서 전송되는 EFDT에 의해, 그 채널로 전송하는 파일군의 전송 제어 파라미터가 기술되도록 한다. 여기서, 파일 모드(File Mode)는, 단일의 파일을 전송하는 모드이다. 한편, 패키지 모드(Package Mode)는, 복수의 파일을 통합하여(동봉하여) 패키지로서 전송하는 모드로 된다.
(스타트업 패키지 파일의 구조)
도 7은, 스타트업 패키지 파일의 구조의 예를 도시하는 도면이다.
스타트업 패키지 파일은, 패키지 모드에서 배신되고, 애플리케이션 매니페스트 파일과 함께, 스타트업 페이지 파일(예를 들어 HTML 문서 파일)이나 리소스 파일(예를 들어 화상 파일이나 스크립트 파일 등)을 동봉할 수 있다.
여기서, 애플리케이션 매니페스트 파일은, 포맷으로서, 예를 들어 W3C(World Wide Web Consortium)에 의해 표준화가 진행되고 있는 Web App Manifest("https://www.w3.org/TR/appmanifest/")를 이용할 수 있다.
또한, 도 7에 도시하는 바와 같이, 애플리케이션 매니페스트 파일이, 어느 포맷을 이용할지는, 패키지 모드에서 이용하고 있는 Multipart MIME 포맷의 루트 파트에 저장되는, MetadataEnvelope의 item 요소의 content-Type 속성에 지정되는 MIME 타입 등에 의해 식별되도록 할 수 있다. 또한, 도 7에 도시한 2개의 item 요소 중, 상측의 item 요소는, 애플리케이션 매니페스트 파일의 포맷에 대응하고, 하측의 item 요소는, 스타트업 페이지 파일의 포맷에 대응하고 있다.
예를 들어, 현상의 애플리케이션 매니페스트 파일에서는, MetadataEnvelope의 item 요소의 content-Type 속성으로서, "application/w3c-manifest+json"이 지정된 경우에는, W3C의 Web App Manifest의 포맷을 이용하게 된다. 도 8에는, W3C의 Web App Manifest의 포맷의 예가 도시되어 있다. 도 8의 Web App Manifest의 포맷에서는, "start_url"에 대하여, 스타트업 페이지 URL의 값이 지정 가능하다.
본 기술에서는, 리소스 배신 정보로서, 애플리케이션의 일부인 하나 또는 복수의 리소스 파일의 배신 스케줄에 관한 배신 스케줄 정보가 배신되도록 하지만, 현상의 애플리케이션 매니페스트 파일의 포맷에서는, 당해 배신 스케줄 정보를 지정할 수 없다.
그래서, 본 기술에서는, 애플리케이션 매니페스트 파일의 포맷 중 하나인, Web App Manifest를 확장함으로써, 스타트업 페이지 URL뿐만 아니라, 리소스 파일별로, 배신 스케줄 정보를 지정할 수 있도록 한다.
단, 이 확장된 Web App Manifest(이하, 확장 Web App Manifest라고도 기술함)를, W3C의 Web App Manifest(도 8)와 구별하기 위해, 애플리케이션 매니페스트 파일의 포맷으로서, 확장 Web App Manifest를 이용하는 경우에는, 스타트업 패키지 파일(도 7)의 MetadataEnvelope의 item 요소의 content-Type 속성으로서, "application/atsc-manifest+json"이 지정되도록 한다(도 9). 또한, "json"은, 텍스트 포맷의 1종인 JSON(JavaScript(등록 상표) Object Notation) 형식으로 표현됨을 의미하고 있다.
(확장 Web App Manifest의 구조)
도 10은, 확장 Web App Manifest의 포맷의 예를 도시하는 도면이다. 또한, 이 포맷의 예는 JSON 형식으로 기술되어 있다. 이 JSON 형식의 오브젝트는, 키와 값의 페어를 콜론(:)으로 쌍으로 하여, 이들 쌍을 콤마(,)로 구획하여 제로개 이상 열거하고, 전체를 파괄호({ })로 묶음으로써 표현된다.
도 10의 확장 Web App Manifest에서는, 스타트업 페이지 URL 외에, 리소스 파일별의 배신 스케줄 정보가, 배신 스케줄 속성으로서 지정 가능하다. 이 배신 스케줄 속성으로서는, 예를 들어 리소스 파일의 취득처를 나타내는 정보, 리소스 파일의 사이즈, 및 리소스 파일의 배신 시간을 지정할 수 있다.
예를 들어, 도 10의 확장 Web App Manifest에 있어서, "url"인 키에 대하여, 리소스 파일의 파일 URL을 나타내는 값이 페어로 되어 지정됨을 나타내고 있다. 단, 리소스 파일의 파일 URL은 필수적인 값이다. 또한, "sizes"인 키에 대하여, 리소스 파일의 사이즈(바이트 단위)를 나타내는 값이 페어로 되어 지정된다. 단, 리소스 파일의 사이즈는 임의의 값이다.
"absoluteDeliveryTimeStart"인 키에 대하여, 절대 시각에서의 배신 개시 시각을 나타내는 값이 페어로 되어 지정된다. 또한, "absoluteDeliveryTimeEnd"인 키에 대하여, 절대 시각에서의 배신 종료 시각을 나타내는 값이 페어로 되어 지정된다. 단, 절대 시각에서의 배신 개시 시각과 배신 종료 시각의 형식은, "YYYY-MM-DDTHH:mm:ssZ"로 할 수 있다. 또한, 절대 시각에서의 배신 개시 시각과 배신 종료 시각은, 임의의 값이다.
"relativeDeliveryTimeStart"인 키에 대하여, 노멀 플레이 타임(Normal Play Time)적인 프로그램의 선두로부터의 상대 시각에서의 배신 개시 시각을 나타내는 값이 페어로 되어 지정된다. 또한, "relativeDeliveryTimeEnd"인 키에 대하여, 노멀 플레이 타임(Normal Play Time)적인 프로그램의 선두로부터의 상대 시각에서의 배신 종료 시각을 나타내는 값이 페어로 되어 지정된다. 단, 상대 시각에서의 배신 개시 시각과 배신 종료 시각의 형식은, "THH:mm:ss.ffffff"로 할 수 있다. 또한, 상대 시각에서의 배신 개시 시각과 배신 종료 시각은, 임의의 값이다.
또한, 도 10의 확장 Web App Manifest의 예에서는, 하나의 리소스 파일에 대한 배신 스케줄 속성이 지정되는 경우가 예시되어 있지만, 복수의 리소스 파일이 존재하는 경우에는, 리소스 파일별로, 배신 스케줄 속성이 기술된다. 한편, 리소스 파일이 존재하지 않는 경우에는, 이 배신 스케줄 속성을 기술할 필요는 없다.
(확장 Web App Manifest의 기술예)
도 11은, 확장 Web App Manifest의 기술예를 도시하는 도면이다.
도 11의 확장 Web App Manifest에 있어서는, "StartUpPage-url"인 스타트업 페이지 URL과 함께, 2개의 리소스 파일별의 배신 스케줄 속성이 기술되어 있다.
첫 번째 리소스 파일의 배신 스케줄 속성에는, 당해 리소스 파일의 파일 URL로서, "ResourceFile-10-url"인 URL이 지정되고, 당해 리소스 파일의 사이즈로서, 123바이트가 지정되어 있다. 또한, 첫 번째 리소스 파일의 배신 스케줄 속성에는, 당해 리소스 파일의 상대 시각에서의 배신 개시 시각과 배신 종료 시각으로서, "T00:10:22.123456"과 "T00:12:33.654321"이 지정되어 있다.
두 번째 리소스 파일의 배신 스케줄 속성에는, 당해 리소스 파일의 파일 URL로서, "ResourceFile-11-url"인 URL이 지정되고, 당해 리소스 파일의 사이즈로서, 4567바이트가 지정되어 있다. 또한, 두 번째 리소스 파일의 배신 스케줄 속성에는, 당해 리소스 파일의 상대 시각에서의 배신 개시 시각과 배신 종료 시각으로서, "T00:13:44.345678"과 "T00:16:55.654321"이 지정되어 있다.
도 11의 확장 Web App Manifest의 기술예를 시계열로 나타내면, 도 12에 도시하는 바와 같이 된다. 즉, 도 12에 있어서는, 시간의 방향은, 도면 중 좌측으로부터 우측을 향하는 방향으로 되지만, 프로그램의 선두를 기점(T00:00:00.000000)으로 하여, "T00:10:22.123456"부터 "T00:12:33.654321"까지의 사이에, "ResourceFile-10-url"인 파일 URL의 리소스 파일이 제시된다. 또한, 프로그램의 선두를 기점(T00:00:00.000000)으로 하여, "T00:13:44.345678"부터 "T00:16:55.654321"까지의 사이에, "ResourceFile-11-url"인 파일 URL의 리소스 파일이 제시된다.
또한, 도 12의 예는, 리소스 파일이 방송 경유로 배신되는 경우를 도시하고 있으며, 리소스 파일이 통신 경유로 배신되는 경우에는, 지정된 기간에, 인터넷(90) 상의 통신 서버(106)로부터 대상의 리소스 파일이 취득 가능함을 나타내게 된다.
(EFDT의 전송 제어 정보)
도 13은, EFDT에 기술되는 전송 제어 정보를 설명하는 도면이다.
리소스 배신 정보로서는, 상술한 확장 Web App Manifest의 포맷에 기술되는 배신 스케줄 정보(배신 스케줄 속성) 외에, EFDT에 기술되는 전송 제어 정보(전송 제어 속성)가 있다.
이 전송 제어 정보는, 시간대에 따라 배신 스케줄이 변경될 가능성이 있는 특정한 리소스 파일의 상세한 전송 제어를 행하기 위한 정보이다. EFDT에서는, 리소스 파일별의 상세한 전송 제어를 행하기 위한 전송 제어 정보가, 전송 제어 속성으로서 지정 가능하다. 이 전송 제어 속성으로서는, 예를 들어 각 리소스 파일의 재송 주기 및 재송 종료 일시 중 적어도 한쪽을 지정할 수 있다.
여기서, 리소스 파일의 재송 주기(Retransmission-Cycle)의 속성으로서는, 예를 들어 "everyDay", "everyHour", "everyMinute", "everySecond" 등을 지정할 수 있다.
"everyDay"는, 대상의 리소스 파일이 1일 1회는 재송될 가능성이 있음을 의미한다. 즉, 재송 주기의 속성으로서, "everyDay"가 지정된 경우, 클라이언트 장치(20)는, 1일 대기하면, 반드시 재취득의 가능성이 있게 된다.
"everyHour"는, 1시간에 1회는 재송될 가능성이 있음을 의미한다. "everyMinute"는, 1분에 1회는 재송될 가능성이 있음을 의미한다. "everySecond"은, 1초에 1회는 재송될 가능성이 있음을 의미한다.
또한, 리소스 파일의 재송 종료 일시(Retransmission-End)의 속성으로서는, 예를 들어 그 재송이 종료되는 일시를 나타내는, "YYYY-MM-DDTHH:mm:ss"의 형식으로 지정되도록 할 수 있다.
예를 들어, 도 13의 EFDT에 있어서는, 리소스 파일의 재송 주기(Retransmission-Cycle)의 속성으로서, "everyMinute"가 기술되고, 리소스 파일의 재송 종료 일시(Retransmission-End)의 속성으로서, "2012-03-14T00:00:00"이 기술되어 있다.
도 13의 EFDT의 기술예를 시계열로서 나타내면, 도 13의 우측에 도시하는 바와 같은 관계로 된다. 즉, 도 13의 우측의 시계열에 있어서는, 시간의 방향은, 도면 중 좌측으로부터 우측을 향하는 방향으로 되지만, "ResourceFile-url"로 식별되는 리소스 파일은, 매초마다 재송되어(00:00:00, 00:01:00, 00:02:00, …), 그 재송이 끝나는 일시(시각)는, 2012년 3월 14일 오전 0시로 된다.
클라이언트 장치(20)에서는, 리소스 파일의 재송 주기나 재송 종료 일시의 속성을 힌트로 하여, 놓친 리소스 파일(예를 들어 화상 파일 등)이, 언제 재송되어 오는지를 예측할 수 있기 때문에, 리소스 파일을 취득하기 위한 스케줄링의 최적화를 행할 수 있다.
또한, 리소스 파일의 재송 주기(Retransmission-Cycle)나 재송 종료 일시(Retransmission-End)의 속성은, 적어도 한쪽이 기술되어 있으면 되며, 예를 들어 재송 주기의 속성의 기술을 하지 않고, 재송 종료 일시의 속성만이 기술된 경우에는, 당해 재송 종료 일시의 속성에 의해 지정되는 일시(시각)까지, 대상의 리소스 파일이 한번만 재송됨을 의미한다.
이와 같이, 확장 Web App Manifest의 포맷을 이용한 애플리케이션 매니페스트 파일에 의해, 배신 스케줄 정보가 지정됨으로써, 클라이언트 장치(20)에서는, 프로그램 전체에 걸친 개개의 리소스 파일의 사이즈나 배신 타이밍을 인식할 수 있다. 또한, EFDT에 의해, 전송 제어 정보로서, 개개의 리소스 파일의 배신 예정 구간 내의 세세한 재송 주기나 재송 종료 일시가 지정됨으로써, 클라이언트 장치(20)에서는, 수신 처리를 행하는 리소스에 대하여, 보다 정교하게, 최적의 배분을 행하는 것이 가능하게 된다.
<3. 구체적인 운용예>
도 14는, 전형적인 애플리케이션의 구성예를 도시하는 도면이다.
도 14에 있어서는, 시간의 방향이, 도면 중 좌측으로부터 우측을 향하는 방향으로 된다. 방송 프로그램(Program)은, 씬 1 내지 씬 3을 포함하고, 씬 1(Scene1), 씬 2(Scene2), 씬 3(Scene3)의 순으로 천이된다.
최초의 씬 1에는, 애플리케이션의 최초 엔트리로 되는 스타트업 페이지 파일(StartUpPage)이 제시된다. 이 스타트업 페이지 파일은, 예를 들어 HTML 문서 파일을 포함하고, 화상 파일(예를 들어 jpeg 파일)이나 스크립트 파일(예를 들어 JavaScript(등록 상표)의 코드가 기술된 파일) 등의 각종 리소스 파일(Resource1, Resource2, Resource3)을 참조함으로써, 애플리케이션의 1번째 뷰(The 1st View)로서, 동시에 제시된다.
씬 1로부터 씬 2로 천이하면, 애플리케이션의 2번째 뷰(The 2nd View)의 내용이 제시된다. 이때, 2번째 뷰에 있어서, HTML 문서 파일 자체는, 최초의 스타트업 페이지 파일과 동일하지만, 동시에 제시되는 내용으로서, 새로운 리소스 파일(Resource4)이 추가되어 있는 점이 상이하다.
또한, 씬 2에 있어서, 애플리케이션은, 2번째 뷰로부터, 3번째 뷰(The 3rd View)로 전환되고, 3번째 뷰의 내용이 제시된다. 이때, 3번째 뷰에 있어서, HTML 문서 파일 자체는, 최초의 스타트업 페이지 파일과 동일하지만, 동시에 제시되는 내용으로서, 제시되어 있던 리소스 파일(Resource4)이 소거되고, 새로운 리소스 파일(Resource5)이 추가되어 있는 점이 상이하다.
또한, 반복이 되므로, 그 설명은 생략하지만, 각 씬에 있어서, 스타트업 페이지 파일에 의해 참조되는 리소스 파일이 추가 또는 소거됨으로써, 애플리케이션의 뷰가 전환되게 된다.
씬 2에 이어지는, 씬 3에 있어서는, 애플리케이션은, N-1번째 뷰로부터, N번째 뷰(The Nth View)로 전환되고, N번째 뷰의 내용이 제시된다. 이때, N번째 뷰에 있어서, HTML 문서 파일 자체는, 최초의 스타트업 페이지 파일과 동일하지만, 동시에 제시되는 내용으로서, 제시되어 있던 리소스 파일(Resource4 내지 Resource N-1)이 소거되고, 새로운 리소스 파일(Resource N)이 제시되어 있다.
이와 같이, 방송 프로그램에 부수되는 애플리케이션에서는, 스타트업 페이지 파일을 제어의 중심으로 하여, 참조되는 리소스 파일을 추가 또는 소거함으로써, 각 씬에 따른 표시 내용(뷰의 내용)이 제시되게 된다. 또한, 상이한 HTML 문서 파일이 복수 취득되도록 하고, 예를 들어 인라인 프레임(HTML로 규정되는 iframe 요소) 등을 이용하여, 상이한 문서(도큐멘트)를 그대로, 일련의 뷰로서 제시하는 방법도 있지만, 본 기술의 실시 형태에서는, 스타트업 페이지 파일을 제어의 중심으로 한 경우를 설명한다.
또한, 본 기술의 실시 형태에서는, 애플리케이션의 배신 모드(딜리버리 모드)로서, 다음의 3종류의 모드를 서포트하는 경우를 설명한다. 즉, 배신 모드로서는, 방송 모드, 하이브리드 모드 및 통신 모드를 설정할 수 있다.
방송 모드(Broadcast Only Mode)는, 애플리케이션을 구성하는 스타트업 페이지 파일(HTML 문서 파일)과, 그 스타트업 페이지 파일에 의해 참조되는 리소스 파일이, 방송 경유에서의 배신에 의해 완결되어 있는 모드이다.
하이브리드 모드(Hybrid Mode)는, 애플리케이션을 구성하는 스타트업 페이지 파일(HTML 문서 파일)과, 그 스타트업 페이지 파일에서 항상 참조되는 리소스 파일 이외의 리소스 파일에 대해서는, 방송 경유 또는 통신 경유로 배신되는 모드이다. 이 경우, EFDT에는, 항상 스타트업 패키지 파일 URL이 기술되고, 그 이외의 리소스 파일에 대해서는, 방송 경유로 배신하는 것에 대해서만, 전송 제어 속성을 기술하게 된다. 스타트업 페이지 파일과 그 스타트업 페이지 파일에서 참조되는 리소스 파일은, 아토믹하게 취득, 표시된다.
통신 모드(Broadband Only Mode)는, 애플리케이션을 구성하는 스타트업 페이지 파일(HTML 문서 파일)과, 그 스타트업 페이지 파일에 의해 참조되는 모든 리소스 파일이, 통신 경유로 배신되는 모드이다. 이 경우, EFDT에는, 항상 스타트업 패키지 파일 URL이 기술되고, 스타트업 패키지 파일에는, 애플리케이션 매니페스트 파일만이 저장되기 때문에, 그 이외의 파일의 전송 제어 속성은 기술되지 않게 된다.
이하, 배신 모드로서, 방송 모드, 하이브리드 모드, 또는 통신 모드가 설정된 경우의 각각에 대하여 설명한다.
(A) 방송 모드
우선, 도 15 내지 도 18을 참조하여, 배신 모드로서, 방송 모드가 설정된 경우에 대하여 설명한다.
(방송 모드 시의 데이터의 흐름)
도 15는, 클라이언트 장치(20)(도 1)에 있어서, 방송 모드가 설정되었을 때 처리되는, 콘텐츠에 부수되는 애플리케이션에 관한 데이터의 흐름을 설명하는 도면이다. 또한, 도 15의 애플리케이션에 관한 데이터의 흐름은, 도 14에 도시한 방송 프로그램의 각 씬에 따라 제시되는 애플리케이션의 표시 내용(뷰의 내용)에 대응하고 있다.
도 15에 있어서는, 도면 중 좌측으로부터 우측을 향하는 시간축의 상측에, ROUTE 세션의 LCC 채널로 배신되는 EFDT가 시계열로 표시되는 한편, 시간축의 하측에, ROUTE 세션의 LCC 채널로 배신되는 스타트업 패키지 파일이나 리소스의 파일이 모식적으로 표시되어 있다.
도 15에 있어서, 파일 모드에서 배신되는 EFDT는, 시계열로 버전이 갱신되지만, 최초로 취득되는 Ver1.0(v.1)의 EFDT는, 씬 1(도 14)인 동안에 배신되는 EFDT이며, 당해 EFDT를 식별하는 EFDT URL 외에, 스타트업 패키지 URL이 기술되어 있다. 클라이언트 장치(20)에서는, 이 EFDT(Ver1.0)의 스타트업 패키지 URL에 따라, 패키지 모드에서 배신되는 스타트업 패키지 파일이 취득된다(S11).
이 스타트업 패키지 파일(StartUpPackage)에는, 당해 스타트업 패키지 파일을 식별하는 스타트업 패키지 URL(StartUpPackageURL)이 기술되는 것 외에, 애플리케이션 매니페스트 파일(AppManifest)과, 스타트업 페이지 파일(HTML 문서 파일)과, 리소스 파일(Resource1, Resource2, Resource3)이 동봉되어 있다.
또한, 스타트업 패키지 파일에 있어서, 애플리케이션 매니페스트의 파일과 동봉되는 파일에는, 스타트업 페이지 파일(HTML 문서 파일)과, 리소스 파일(Resource1, Resource2, Resource3)이 있지만, 이들 파일은, 애플리케이션 매니페스트의 파일과 동시에 취득되는 것이 보증되어 있다.
또한, 리소스 파일은, 예를 들어 화상 파일이나 스크립트 파일이다. 예를 들어, Resource1은, JavaScript(등록 상표)의 코드가 기술된 파일이고, Resource2는, jpeg 형식의 화상 파일이고, Resource3은, mp4 형식의 동화상 파일이다.
이 스타트업 페이지 파일(HTML 문서 파일)에 의해, 리소스 파일(Resource1, Resource2, Resource3)이 참조됨으로써, 애플리케이션의 1번째 뷰(도 14)가 제시된다.
여기서, 애플리케이션 매니페스트 파일은, 확장 Web App Manifest(도 10)의 포맷을 채용하고 있고, 파일 URL로서의 애플리케이션 매니페스트 URL(AppManifestURL)이 기술되는 것 외에, 스타트업 페이지 URL(StartUpPageURL)과, 리소스 파일별의 배신 스케줄에 관한 배신 스케줄 정보(Attributes)를 포함하고 있다. 이 스타트업 페이지 URL에 의해, 애플리케이션의 엔트리 파일(스타트업 페이지 파일)을 나타내고 있다. 또한, 배신 스케줄 정보에는, 각 리소스 파일의 파일 URL, 사이즈 및 배신 시각에 관한 정보 등이 포함된다.
씬 1로부터 씬 2로 천이하면, EFDT의 내용이 변경되고, 그 버전이 Ver1.0(v.1)으로부터 Ver2.0(v.2)으로 갱신된다. Ver2.0의 EFDT는, 씬 2(도 14)인 동안에 배신되는 EFDT이며, 스타트업 패키지 URL과 함께, 씬 2의 전단 파트에서 제시되는 리소스 파일(Resource4)과, 씬 2의 후단 파트에서 제시되는 리소스 파일(Resource5)의 URL 등이 기술된다.
Ver2.0의 EFDT의 스타트업 패키지 URL에 의해, Ver1.0의 EFDT에 따라 취득 완료 스타트업 패키지 파일이 참조되고(S12), 리소스 파일 URL에 의해, 방송 경유의 파일 모드에서 배신되는 리소스 파일(Resource4, Resource5)이 취득된다(S13, S14).
즉, 스타트업 페이지 파일(HTML 문서 파일) 자체는, 최초의 스타트업 페이지 파일과 동일하지만, 새로운 리소스 파일(Resource4)의 추가가 행해진 2번째 뷰(도 14)나, 리소스 파일(Resource4)의 소거와 리소스 파일(Resource5)의 추가가 행해진 3번째 뷰(도 14)가 제시된다.
2번째 뷰(도 14)에서는, 스타트업 페이지 파일(HTML 문서 파일)이, 리소스 파일로서, Resource1 내지 Resource4를 참조하고 있다. 또한, 3번째 뷰(도 14)에서는, 스타트업 페이지 파일(HTML 문서 파일)이, 리소스 파일로서, Resource1 내지 Resource3과, Resource5를 참조하고 있다.
또한, 씬 2로부터 씬 3으로 천이할 때까지의 동안에, EFDT의 버전이, Ver2.0(v.2)으로부터 Ver M(v.M)까지 순차적으로 갱신된다. Ver M의 EFDT는, 씬 3(도 14)인 동안에 배신되는 EFDT이며, 스타트업 패키지 URL과 함께, 리소스 파일(Resource N)의 URL 등이 기술된다.
Ver M의 EFDT의 스타트업 패키지 URL에 의해, Ver1.0의 EFDT에 따라 취득 완료 스타트업 패키지 파일이 참조되고(S15), 리소스 파일 URL에 의해, 방송 경유의 파일 모드에서 배신되는 리소스 파일(Resource N)이 취득된다(S15, S16).
즉, 스타트업 페이지 파일(HTML 문서 파일) 자체는, 최초의 스타트업 페이지 파일과 동일하지만, 리소스 파일(Resource4 내지 Resource N-1)의 소거와 리소스 파일(Resource N)의 추가가 행해진 N번째 뷰(도 14)가 제시된다. N번째 뷰(도 14)에서는, 스타트업 페이지 파일(HTML 문서 파일)이, 리소스 파일로서, Resource1 내지 Resource3과, Resource N을 참조하고 있다.
이어서, 도 16 내지 도 18의 흐름도를 참조하여, 방송 모드가 설정된 경우에 있어서의 전송 시스템(1)(도 1)의 각 장치에서 실행되는 처리의 흐름을 설명한다.
(송신측의 처리의 흐름)
최초로, 도 16의 흐름도를 참조하여, 송신측 시스템(10)에 의해 실행되는, 방송 모드가 설정된 경우의 송신측의 처리의 흐름에 대하여 설명한다. 또한, 이 송신측의 처리에서는, 애플리케이션 서버(103), SCH/PKG 서버(104) 및 방송 서버(105)에 의해 실행되는, 콘텐츠에 부수되는 애플리케이션에 관한 처리를 중심으로 설명하고, DASH 서버(101) 등에 의해 실행되는, 방송 프로그램 등의 콘텐츠에 관한 처리는 생략하기로 한다.
도 16의 스텝 S301 내지 S302의 처리는, 애플리케이션 서버(103)(도 1)에 의해 실행된다.
스텝 S301에 있어서, 애플리케이션 서버(103)는, 애플리케이션의 오서링 처리를 행한다. 이 오서링 처리에서는, 스타트업 페이지 파일이나 하나 또는 복수의 리소스 파일이 생성되고, 그들 파일군에 의해 구성되는 애플리케이션이 생성된다.
스텝 S302에 있어서, 애플리케이션 서버(103)는, 스텝 S301의 처리에서 생성된 스타트업 페이지 파일이나 하나 또는 복수의 리소스 파일 등의 파일군을, SCH/PKG 서버(104)에 송신한다.
도 16의 스텝 S401 내지 S408의 처리는, SCH/PKG 서버(104)(도 1)에 의해 실행된다. 또한, SCH/PKG 서버(104)에 있어서는, 스텝 S302의 처리에서 송신된 파일군이 수신된다.
스텝 S401에 있어서, SCH/PKG 서버(104)는, 애플리케이션을 구성하는 파일(리소스 파일)의 배신 스케줄을 결정한다.
스텝 S402에 있어서, SCH/PKG 서버(104)는, 스텝 S401의 처리에서 결정된 배신 스케줄에 따라, EFDT를 생성한다. 또한, EFDT에는, 스텝 S401의 처리에서 결정된 배신 스케줄에 따른 전송 제어 정보를 포함할 수 있다. 스텝 S403에 있어서, SCH/PKG 서버(104)는, 스텝 S402의 처리에서 생성된 EFDT를, 방송 서버(105)에 송신한다.
스텝 S404에 있어서, SCH/PKG 서버(104)는, 스텝 S301의 처리에서 생성된 파일군(예를 들어, 스타트업 페이지 파일이나 하나 또는 복수의 리소스 파일 등)에 기초하여, 스타트업 패키지 파일을 생성한다. 또한, 스타트업 패키지 파일에 저장되는 애플리케이션 매니페스트 파일은, 확장 Web App Manifest(도 10)의 포맷을 채용함으로써, 스텝 S401의 처리에서 결정된 배신 스케줄에 따른 배신 스케줄 정보를 포함할 수 있다.
스텝 S405에 있어서, SCH/PKG 서버(104)는, 스텝 S404의 처리에서 생성된 스타트업 패키지 파일을, 방송 서버(105)에 송신한다.
스텝 S406에 있어서, SCH/PKG 서버(104)는, 스텝 S401의 처리에서 결정된 배신 스케줄에 따라, EFDT를 생성한다. 또한, EFDT에는, 스텝 S401의 처리에서 결정된 배신 스케줄에 따른 전송 제어 정보를 포함할 수 있다. 스텝 S407에 있어서, SCH/PKG 서버(104)는, 스텝 S406의 처리에서 생성된 EFDT를, 방송 서버(105)에 송신한다.
스텝 S408에 있어서, SCH/PKG 서버(104)는, 스텝 S301의 처리에서 생성된 파일군 중, 추가 리소스 파일을, 방송 서버(105)에 전송한다.
도 16의 스텝 S501 내지 S504는, 방송 서버(105)(도 1)에 의해 실행된다. 또한, 방송 서버(105)에 있어서는, 스텝 S403 또는 S407의 처리에서 송신된 EFDT와, 스텝 S405의 처리에서 송신된 스타트업 패키지 파일과, 스텝 S407의 처리에서 송신된 추가 리소스 파일이 수신된다.
스텝 S501에 있어서, 방송 서버(105)는, 스텝 S402의 처리에서 생성된 EFDT를, 파일 모드에서, 전송로(80)를 통하여 송신(일제 동보 배신)한다.
스텝 S502에 있어서, 방송 서버(105)는, 스텝 S404의 처리에서 생성된 스타트업 패키지 파일을, 패키지 모드에서, 전송로(80)를 통하여 송신(일제 동보 배신)한다.
스텝 S503에 있어서, 방송 서버(105)는, 스텝 S406의 처리에서 생성된 EFDT를, 파일 모드에서, 전송로(80)를 통하여 송신(일제 동보 배신)한다.
스텝 S504에 있어서, 방송 서버(105)는, 스텝 S408의 처리에서 전송된 추가 리소스 파일(스텝 S301의 처리에서 생성된 리소스 파일)을, 파일 모드에서, 전송로(80)를 통하여 송신(일제 동보 배신)한다.
이상, 송신측의 처리의 흐름에 대하여 설명하였다.
(수신측의 처리의 흐름)
이어서, 도 17 및 도 18의 흐름도를 참조하여, 클라이언트 장치(20)에 의해 실행되는, 방송 모드가 설정된 경우의 수신측의 처리의 흐름에 대하여 설명한다. 또한, 이 수신측의 처리에서는, 콘텐츠에 부수되는 애플리케이션에 관한 처리를 중심으로 설명하고, 방송 프로그램 등의 콘텐츠에 관한 처리는 생략하기로 한다. 즉, 도 17 및 도 18의 처리가 실행되는 전제로서, 클라이언트 장치(20)에서는, 방송 서버(105)로부터 배신되는 방송 프로그램이나, 통신 서버(106)로부터 배신되는 VOD 프로그램 등의 콘텐츠가 재생되어 있는 것으로 한다.
스텝 S201에 있어서, 방송 미들웨어(205)는, IP/UDP 패킷에 저장되는 SLT 메타데이터와, ROUTE 세션으로 전송되는 SLS 시그널링을 취득한다. 여기서, SLS 시그널링으로서는, USD 메타데이터가 취득됨으로써, 거기에 기술되어 있는 정보에 따라, S-TSID 메타데이터가 취득된다.
스텝 S202에 있어서, 방송 미들웨어(205)는, 스텝 S201의 처리에서 취득된 SLS 시그널링(S-TSID 메타데이터)에 기초하여, ROUTE 세션의 LCC 채널로, 파일 모드에 의해 배신되는 EFDT를 취득한다.
스텝 S203에 있어서, 방송 미들웨어(205)는, 스텝 S202의 처리에서 취득된 EFDT를 파싱한다.
스텝 S204에 있어서, 방송 미들웨어(205)는, 스텝 S203의 처리의 해석 결과에 기초하여, ROUTE 세션의 LCC 채널로, 패키지 모드에 의해 배신되는 스타트업 패키지 파일을 취득한다.
스텝 S205에 있어서, 방송 미들웨어(205)는, 스텝 S204의 처리에서 취득된 스타트업 패키지 파일의 애플리케이션 매니페스트 파일에, 새로운 스타트업 페이지 URL이 기술되어 있는지 여부를 판정한다.
스텝 S205에 있어서, 새로운 스타트업 페이지 URL이 기술되어 있지 않다고 판정된 경우, 처리는, 스텝 S201로 복귀되어, 그 이후의 처리가 반복된다. 그리고, 스텝 S201 내지 S205의 처리가 반복됨으로써, 스텝 S205의 판정 처리에서, 새로운 스타트업 페이지 URL이 기술되어 있다고 판정된 경우, 처리는, 스텝 S206으로 진행된다.
스텝 S206에 있어서, 방송 미들웨어(205)는, 스타트업 패키지 파일의 애플리케이션 매니페스트 파일에 기술된 (새로운) 스타트업 페이지 URL을, 브라우저(209)에 통지한다. 이에 의해, 애플리케이션의 기동이 개시되게 된다.
또한, 이 스타트업 페이지 URL이, 방송 미들웨어(205)로부터, 브라우저(209)에 통지되는 시점에서, 스텝 S204의 처리에서 취득된 스타트업 패키지 파일에 저장된 스타트업 페이지 파일과 하나 또는 복수의 리소스의 파일이, 메모리(203)의 로컬 파일 시스템 상에 전개되어 있거나, 혹은 프록시 서버(212)의 서버 사이드 스크립트가 액세스 가능하게 되어 있다. 즉, 애플리케이션의 기동이 개시된 경우에, 브라우저(209)로부터의 요구에 대하여, 즉시 회답(신)할 수 있도록, 스타트업 페이지 파일이나 리소스 파일의 회답의 준비가 이루어져 있다.
또한, 애플리케이션 매니페스트 파일은, 확장 Web App Manifest(도 10)의 포맷을 채용하고 있기 때문에, 리소스 파일별의 배신 스케줄 정보(리소스 파일의 사이즈나 배신 시각)가 기술되어 있지만, 이 배신 스케줄 정보는, 방송 미들웨어(205) 또는 처리부(201)(제어부(211))에 의해 해석되고, 그 해석 결과는, 메모리(203)에 기억된다. 그리고, 예를 들어 메모리(203)의 메모리 관리를 행하는 경우에, 메모리(203)의 용량에 충분한 여유가 있을 때에는, 이 배신 스케줄 정보의 해석 결과를 사용하여, 최초로, 각 리소스 파일의 바이트수의 총합에 따른 기억 영역을 메모리부(203)에 확보해 두는 등의 처리를 행할 수 있다.
한편, 예를 들어 메모리(203)의 용량에, 충분한 여유가 없을 때에는, 메모리(203)의 기억 영역의 확보가 필요하게 되었을 때, 배신 스케줄 정보의 해석 결과를 참조하여, 그때 필요한 기억 영역을 확보하는 등의 처리를 행할 수 있다. 또한, 메모리(203)의 용량에, 충분한 여유가 없을 때에는, 장래 취득할 리소스 파일의 EFDT가 취득되기 전에, 배신 스케줄 정보의 해석 결과에 따라(적당한 타이밍에), 리소스 파일(의 회답)의 준비가 필요하게 되었을 때, 리소스 파일의 사이즈를 견적함으로써, 미리 필요한 기억 영역을 메모리(203) 상에 확보해 두는 등의 처리를 행할 수도 있다. 단, 여기에 설명한 배신 스케줄 정보(의 해석 결과)를 사용한 처리는 일례이며, 리소스 파일의 배신에 따른 각종 처리를 행할 수 있다.
스텝 S221에 있어서, 브라우저(209)는, 스텝 S206의 처리에서 통지된 스타트업 페이지 URL에 따라, 프록시 서버(212)에 대하여, 스타트업 페이지 파일을 요구한다.
스텝 S207에 있어서, 프록시 서버(212)는, 브라우저(209)로부터의 스타트업 페이지 파일의 요구에 따라, 회답의 준비가 이루어져 있는 스타트업 페이지 파일을, 브라우저(209)에 회답한다. 이에 의해, 브라우저(209)는, 프록시 서버(212)로부터의 스타트업 페이지 파일을 취득할 수 있다.
스텝 S222에 있어서, 브라우저(209)는, 프록시 서버(212)에 대하여, 스타트업 페이지 파일에 동봉된 스타트업 페이지 파일 내의 리소스 파일을 요구한다.
스텝 S208에 있어서, 프록시 서버(212)는, 브라우저(209)로부터의 스타트업 페이지 파일 내 리소스 파일의 요구에 따라, 회답의 준비가 이루어져 있는 스타트업 페이지 파일에 동봉된 스타트업 페이지 파일 내의 리소스 파일을, 브라우저(209)에 회답한다.
스텝 S223에 있어서, 브라우저(209)는, 프록시 서버(212)로부터 취득된 스타트업 페이지 파일 및 그 스타트업 페이지 파일 내의 리소스 파일에 기초하여, 렌더러(213)를 통하여 스타트업 페이지 파일을 제시한다. 이에 의해, 애플리케이션(의 스타트업 페이지)가, 방송 프로그램 등의 콘텐츠와 함께 표시된다.
스텝 S209에 있어서, 방송 미들웨어(205)는, 스텝 S201의 처리에서 취득된 SLS 시그널링(S-TSID 메타데이터)에 기초하여, ROUTE 세션의 LCC 채널로, 파일 모드에 의해 배신되는 EFDT를 취득한다.
스텝 S210에 있어서, 방송 미들웨어(205)는, 스텝 S209의 처리에서 취득된 EFDT를 파싱한다. 또한, 스텝 S209의 처리에서 취득된 EFDT의 버전(예를 들어 Ver2.0)은, 스텝 S202의 처리에서 취득된 EFDT의 버전(예를 들어 Ver1.0)보다 새로운 것으로 한다. 또한, EFDT의 전송 제어 속성으로서, 전송 제어 정보(도 13)가 기술되어 있는 경우, 방송 미들웨어(205) 또는 처리부(201)(제어부(211))는, 전송 제어 정보를 해석하여, 그 해석 결과에 따른 처리를 행할 수 있다. 예를 들어, 전송 제어 정보(도 13)는, 특정한 리소스 파일의 재송 주기나 재송 종료 일시가 기술되므로, 방송 미들웨어(205)는, 이 재송 주기나 재송 종료 일시에 따라, 재송될 특정한 리소스 파일을 취득할 수 있다.
스텝 S211에 있어서, 방송 미들웨어(205)는, 스텝 S210의 해석 결과에 기초하여, ROUTE 세션의 LCC 채널로, 파일 모드에 의해 배신되는 추가 리소스 파일을 취득한다.
한편, 브라우저(209)에서는, 추가 리소스 파일의 제시 타이밍이 감시된다(S224). 스텝 S225에 있어서, 브라우저(209)는, 스텝 S224의 감시 결과에 기초하여, 추가 리소스 파일의 제시 타이밍이 검지되었는지 여부를 판정한다.
여기서는, 예를 들어 스타트업 페이지 파일 내에, 모든 리소스 파일의 제시 타이밍이 (프로그램 전체에 걸쳐) 스케줄링되어 있는 경우에는, 그 타이밍에 타이머가 발화하도록 스크립트를 프로그램함으로써, 추가 리소스 파일을 제시할 타이밍을 검지할 수 있다. 또한, 스타트업 페이지 파일이, 외부로부터의 이벤트(예를 들어 콘텐츠 스트림에 인 밴드로 전송되는 애플리케이션 서버(103)가 발행하는 스트림 이벤트, 또는 유저와의 인터랙션)를 갖도록 스크립트를 프로그램함으로써, 추가 리소스를 제시할 타이밍을 검지할 수 있다.
이들 중 어느 것에 의해 검지하는 경우에도, 프로그램 전체에 걸쳐 동일한 스타트업 페이지 파일이면 되며, 스타트업 페이지 파일의 갱신은 불필요하다. 즉, 스타트업 패키지 파일 내의 스타트업 페이지 파일의 갱신은 없기 때문에, 항상, 애플리케이션 매니페스트 파일, 스타트업 페이지 파일, 스타트업 페이지 파일 내에서 최초로 참조되는 리소스 파일(예를 들어, Resource1, Resource2, Resource3)은 갱신되지 않으므로, 스타트업 패키지 파일 그 자체의 갱신이 없기 때문이다.
스텝 S225에 있어서, 추가 리소스 파일의 제시 타이밍이 검지되지 않았다고 판정된 경우, 처리는, 스텝 S224로 복귀되고, 스텝 S224 내지 S225의 감시 처리가 반복된다. 그리고, 스텝 S225에 있어서, 추가 리소스 파일의 제시 타이밍이 검지되었다고 판정된 경우, 처리는, 스텝 S226으로 진행된다.
스텝 S226에 있어서, 브라우저(209)는, 스텝 S225의 처리의 (제시 타이밍 검지의) 검지 결과에 따라, 프록시 서버(212)에 대하여, 추가 리소스 파일을 요구한다.
스텝 S212에 있어서, 프록시 서버(212)는, 브라우저(209)로부터의 추가 리소스 파일 요구에 따라, 회답의 준비가 이루어져 있는 추가 리소스 파일을, 브라우저(209)에 회답한다. 이에 의해, 브라우저(209)는, 프록시 서버(212)로부터의 추가 리소스 파일을 취득할 수 있다.
스텝 S227에 있어서, 브라우저(209)는, 렌더러(213)를 제어하여, 프록시 서버(212)로부터 취득된 추가 리소스 파일을 제시한다. 이에 의해, 애플리케이션(의 스타트업 페이지)에, 추가 리소스의 정보가 추가되게 된다.
이상, 수신측의 처리의 흐름에 대하여 설명하였다.
(B) 하이브리드 모드
이어서, 도 19 내지 도 22를 참조하여, 배신 모드로서, 하이브리드 모드가 설정된 경우에 대하여 설명한다.
(하이브리드 모드 시의 데이터의 흐름)
도 19는, 클라이언트 장치(20)(도 1)에 있어서, 하이브리드 모드가 설정되었을 때 처리되는, 콘텐츠에 부수되는 애플리케이션에 관한 데이터의 흐름을 설명하는 도면이다. 또한, 도 19의 애플리케이션에 관한 데이터의 흐름은, 도 14에 도시한 방송 프로그램의 각 씬에 따라 제시되는 애플리케이션의 표시 내용(뷰의 내용)에 대응하고 있다.
도 19에 있어서, 클라이언트 장치(20)에서는, 상술한 도 15의 S11(방송 모드)과 마찬가지로, EFDT(Ver1.0)의 스타트업 패키지 URL에 따라, 패키지 모드에서 배신되는 스타트업 패키지 파일이 취득된다(S21).
이 스타트업 패키지 파일에는, 당해 스타트업 패키지 파일을 식별하는 스타트업 패키지 URL이 기술되는 것 외에, 애플리케이션 매니페스트 파일과, 스타트업 페이지 파일(HTML 문서 파일)과, 리소스 파일(Resource1, Resource2, Resource3)이 동봉되어 있다.
이에 의해, 씬 1(도 14)에 있어서는, 스타트업 페이지 파일(HTML 문서 파일)에 의해, 리소스 파일(Resource1, Resource2, Resource3)이 참조됨으로써, 애플리케이션의 1번째 뷰(도 14)가 제시된다.
씬 1로부터 씬 2로 천이하면, EFDT의 내용이 변경되고, 그 버전이 Ver1.0(v.1)으로부터 Ver2.0(v.2)으로 갱신된다. Ver2.0의 EFDT는, 씬 2(도 14)인 동안에 배신되는 EFDT이며, 스타트업 패키지 URL과 함께, 씬 2의 후단 파트에서 제시되는 리소스 파일(Resource5)의 URL만이 기술된다.
즉, 도 19의 예에서는, 리소스 파일(Resource5)은, 방송 경유로 배신되는 한편, 리소스 파일(Resource4)은, 통신 경유로 배신되므로, Ver2.0의 EFDT에는, 방송 경유로 배신되는 리소스 파일(Resource5)에 관한 정보만이 기술된다.
그리고, Ver2.0의 EFDT의 스타트업 패키지 URL에 의해, Ver1.0의 EFDT에 따라 취득 완료 스타트업 패키지 파일이 참조되고(S22), 리소스 파일 URL에 의해, 통신 경유로 배신되는 리소스 파일(Resource4)이나, 방송 경유로 배신되는 리소스 파일(Resource5)이 취득된다(S23, S24).
단, 통신 경유로 배신되는 리소스 파일(Resource4)의 리소스 파일 URL은, 예를 들어 애플리케이션 매니페스트 파일의 배신 스케줄 정보의 각 리소스 파일(Resource4)의 파일 URL이 사용된다. 또한, 방송 경유로 배신되는 리소스 파일(Resource5)의 리소스 파일 URL은, Ver2.0의 EFDT에 기술되는 리소스 파일 URL이 사용된다.
이에 의해, 씬 2(도 14)의 전단 파트에서는, 스타트업 페이지 파일 자체는, 최초의 스타트업 페이지 파일과 동일하지만, 통신 경유로 배신되는 리소스 파일(Resource4)의 추가가 행해진 2번째 뷰(도 14)가 제시된다. 또한, 씬 2(도 14)의 후단 파트에서는, 스타트업 페이지 파일 자체는, 최초의 스타트업 페이지 파일과 동일하지만, 리소스 파일(Resource4)의 소거와, 방송 경유로 배신되는 리소스 파일(Resource5)의 추가가 행해진 3번째 뷰(도 14)가 제시된다.
또한, 씬 2로부터 씬 3으로 천이하는 동안에, EFDT의 버전이, Ver2.0(v.2)으로부터 Ver M(v.M)까지 순차적으로 갱신된다. Ver M의 EFDT는, 씬 3(도 14)인 동안에 배신되는 EFDT이며, 스타트업 패키지 URL만이 기술된다.
그리고, Ver M의 EFDT의 스타트업 패키지 URL에 의해, Ver1.0의 EFDT에 따라 취득 완료 스타트업 패키지 파일이 참조되고(S25), 리소스 파일 URL에 의해, 통신 경유로 배신되는 리소스 파일(Resource N)이 취득된다(S26).
단, 통신 경유로 배신되는 리소스 파일(Resource N)의 리소스 파일 URL은, 예를 들어 애플리케이션 매니페스트 파일의 배신 스케줄 정보의 각 리소스 파일의 파일 URL을 사용할 수 있다.
이에 의해, 씬 3에서는, 스타트업 페이지 파일 자체는, 최초의 스타트업 페이지 파일과 동일하지만, 통신 경유로 배신되는 리소스 파일(Resource N)의 추가가 행해진 N번째 뷰(도 14)가 제시된다.
이어서, 도 20 내지 도 22의 흐름도를 참조하여, 하이브리드 모드가 설정된 경우에 있어서의 전송 시스템(1)(도 1)의 각 장치에서 실행되는 처리의 흐름을 설명한다.
(송신측의 처리의 흐름)
최초로, 도 20의 흐름도를 참조하여, 송신측 시스템(10)에 의해 실행되는, 하이브리드 모드가 설정된 경우의 송신측의 처리의 흐름에 대하여 설명한다.
도 20의 스텝 S321 내지 S322에 있어서는, 도 16의 스텝 S301 내지 S302와 마찬가지로, 애플리케이션 서버(도 1)에 의해, 오서링 처리가 행해져, 애플리케이션을 구성하는 파일군이 생성된다.
도 20의 스텝 S421 내지 S429에 있어서는, 도 16의 스텝 S401 내지 S408과 마찬가지로, SCH/PKG 서버(104)(도 1)에 의해, 배신 스케줄의 결정과, EFDT의 생성과, 스타트업 패키지 파일의 생성의 처리가 행해지지만, 추가 리소스 파일의 전송처에, 방송 서버(105)뿐만 아니라, 통신 서버(106)가 포함되는 점이 상이하다.
즉, 스텝 S428에 있어서, SCH/PKG 서버(104)는, 스텝 S321의 처리에서 생성된 파일군 중, 추가 리소스 파일의 일부를, 방송 서버(105)에 전송한다. 또한, 스텝 S429에 있어서, SCH/PKG 서버(104)는, 스텝 S321의 처리에서 생성된 파일군 중, 추가 리소스 파일의 일부를, 통신 서버(106)에 전송한다.
스텝 S521 내지 S524에 있어서는, 도 16의 스텝 S501 내지 S504와 마찬가지로, 방송 서버(105)(도 1)에 의해, EFDT와 추가 리소스 파일이 파일 모드에서, 스타트업 패키지 파일이 패키지 모드에서, 전송로(80)를 통하여 송신(일제 동보 배신)된다.
도 20의 스텝 S621 내지 S622는, 통신 서버(106)(도 1)에 의해 실행된다. 또한, 통신 서버(106)에 있어서는, 스텝 S429의 처리에서 전송된 추가 리소스 파일이 수신된다.
스텝 S621에 있어서, 통신 서버(106)는, 인터넷(90)을 통하여, 클라이언트 장치(20)로부터 추가 리소스 파일이 요구되었는지 여부를 판정한다. 스텝 S621에 있어서, 추가 리소스 파일이 요구되지 않았다고 판정된 경우, 스텝 S621의 판정 처리가 반복된다.
한편, 스텝 S621에 있어서, 추가 리소스 파일이 요구되었다고 판정된 경우, 처리는, 스텝 S622로 진행된다. 스텝 S622에 있어서, 통신 서버(106)는, 스텝 S429의 처리에서 전송된 추가 리소스 파일(스텝 S321의 처리에서 생성된 리소스 파일)을, 요구원인 클라이언트 장치(20)에 대하여, 인터넷(90)을 통하여 배신한다.
이상, 송신측의 처리의 흐름에 대하여 설명하였다.
(수신측의 처리의 흐름)
이어서, 도 21 및 도 22의 흐름도를 참조하여, 클라이언트 장치(20)에 의해 실행되는, 하이브리드 모드가 설정된 경우의 수신측의 처리의 흐름에 대하여 설명한다. 또한, 이 수신측의 처리가 실행되는 전제로서, 상술한 도 17 및 도 18과 마찬가지로, 클라이언트 장치(20)에서는, 방송 서버(105)로부터 배신되는 방송 프로그램이나, 통신 서버(106)로부터 배신되는 VOD 프로그램 등의 콘텐츠가 재생되어 있는 것으로 한다.
도 21의 스텝 S231 내지 S238에 있어서는, 도 17의 스텝 S201 내지 S208과 마찬가지로, 방송 미들웨어(205)에 의해, 방송 서버(105)로부터 배신되는 EFDT와 스타트업 패키지 파일이 처리되고, 스타트업 패키지 파일의 애플리케이션 매니페스트 파일에, 새로운 스타트업 페이지 URL이 기술되어 있는 경우에는, 당해 스타트업 페이지 URL이, 브라우저(209)에 통지된다. 또한, 프록시 서버(212)에 의해, 브라우저(209)로부터의 요구에 따라, 스타트업 페이지 파일과 그 스타트업 파일 내의 리소스 파일이 회답된다.
또한, 도 21의 스텝 S251 내지 S253에 있어서는, 도 17의 스텝 S221 내지 S223과 마찬가지로, 브라우저(209)에 의해, 스타트업 페이지 파일과 그 스타트업 파일 내의 리소스 파일이 요구되고, 렌더러(213)에 의해, 프록시 서버(212)로부터의 회답에 따라, 스타트업 페이지가 제시된다.
도 22의 스텝 S239 내지 S242에 있어서는, 도 18의 스텝 S209 내지 S212와 마찬가지로, 방송 미들웨어(205)에 의해, 방송 서버(105)로부터 배신되는 EFDT와 추가 리소스 파일이 처리된다. 또한, 프록시 서버(212)에 의해, 브라우저(209)로부터의 요구에 따라, 추가 리소스 파일이 회답된다.
또한, 도 22의 스텝 S254 내지 S257에 있어서는, 도 18의 스텝 S224 내지 S227과 마찬가지로, 브라우저(209)에 의해, 방송 경유로 배신되는 추가 리소스 파일의 제시 타이밍이 감시되고, 그 제시 타이밍으로 되었을 때, 추가 리소스 파일이 요구된다. 또한, 렌더러(213)에 의해, 프록시 서버(212)로부터의 회답에 따라, 추가 리소스 파일이 제시된다.
이와 같이 하여, 방송 서버(105)로부터 방송 경유로 배신되는 추가 리소스 파일이 제시된다. 한편, 추가 리소스 파일이, 통신 서버(106)로부터 통신 경유로 배신되는 경우, 이하와 같이 처리된다.
즉, 도 22의 스텝 S258에 있어서, 브라우저(209)는, 통신 경유로 배신되는 추가 리소스 파일의 제시 타이밍을 감시한다. 스텝 S259에 있어서, 브라우저(209)는, 스텝 S258의 감시 결과에 기초하여, 통신 경유로 배신되는 추가 리소스 파일의 제시 타이밍이 검지되었는지 여부를 판정한다.
스텝 S259에 있어서, 추가 리소스 파일의 제시 타이밍이 검지되지 않았다고 판정된 경우, 처리는, 스텝 S258로 복귀되고, 스텝 S258 내지 S259의 감시 처리가 반복된다. 그리고, 스텝 S259에 있어서, 추가 리소스 파일의 제시 타이밍이 검지되었다고 판정된 경우, 처리는, 스텝 S260으로 진행된다.
스텝 S260에 있어서, 브라우저(209)는, 스텝 S259의 처리의 (제시 타이밍 검지의) 검지 결과에 따라, 프록시 서버(212)에 대하여, 추가 리소스 파일을 요구한다.
스텝 S243에 있어서, 프록시 서버(212)는, 브라우저(209)로부터의 추가 리소스 파일의 요구에 따라, 인터넷(90)을 통하여 통신 서버(106)에 대하여, 추가 리소스 파일을 요구한다. 스텝 S244에 있어서, 프록시 서버(212)는, 스텝 S243의 요구에 따라, 인터넷(90)을 통하여 통신 서버(106)로부터 배신되는 추가 리소스 파일을 취득한다.
스텝 S245에 있어서, 프록시 서버(212)는, 스텝 S244의 처리에서 취득한 추가 리소스 파일을, 브라우저(209)에 회답한다. 이에 의해, 브라우저(209)는, 프록시 서버(212)로부터의 추가 리소스 파일을 취득할 수 있다.
스텝 S261에 있어서, 브라우저(209)는, 렌더러(213)를 제어하여, 프록시 서버(212)로부터 취득된 추가 리소스 파일을 제시한다. 이에 의해, 애플리케이션(의 스타트업 페이지)에, 추가 리소스의 정보가 추가되게 된다.
이상, 수신측의 처리의 흐름에 대하여 설명하였다.
(C) 통신 모드
마지막으로, 도 23 내지 도 26을 참조하여, 배신 모드로서, 통신 모드가 설정된 경우에 대하여 설명한다.
(통신 모드 시의 데이터의 흐름)
도 23은, 클라이언트 장치(20)(도 1)에 있어서, 통신 모드가 설정되었을 때 처리되는, 콘텐츠에 부수되는 애플리케이션에 관한 데이터의 흐름을 설명하는 도면이다. 또한, 도 23의 애플리케이션에 관한 데이터의 흐름은, 도 14에 도시한 방송 프로그램의 각 씬에 따라 제시되는 애플리케이션의 표시 내용(뷰의 내용)에 대응하고 있다.
도 23에 있어서, 클라이언트 장치(20)에서는, 상술한 도 15의 S11(방송 모드)과 마찬가지로, EFDT(Ver1.0)의 스타트업 패키지 URL에 따라, 패키지 모드에서 배신되는 스타트업 패키지 파일이 취득된다(S31).
이 스타트업 패키지 파일에는, 당해 스타트업 패키지 파일을 식별하는 스타트업 패키지 URL이 기술되는 것 외에, 애플리케이션 매니페스트 파일이 포함된다.
애플리케이션 매니페스트 파일에는, 스타트업 페이지 URL 외에, 배신 스케줄 정보로서, 각 리소스 파일의 파일 URL이 기술되어 있다. 클라이언트 장치(20)는, 이들 URL에 따라, 인터넷(90)을 통하여 통신 서버(106)에 액세스함으로써, 통신 경유로 배신되는, 스타트업 페이지 파일(HTML 문서 파일)과, 리소스 파일(Resource1, Resource2, Resource3)을 취득할 수 있다.
이에 의해, 씬 1(도 14)에 있어서는, 스타트업 페이지 파일(HTML 문서 파일)에 의해, 리소스 파일(Resource1, Resource2, Resource3)이 참조됨으로써, 애플리케이션의 1번째 뷰(도 14)가 제시된다.
씬 1로부터 씬 2로 천이하면, EFDT의 내용이 변경되고, 그 버전이 Ver1.0(v.1)으로부터 Ver2.0(v.2)으로 갱신된다. Ver2.0의 EFDT는, 씬 2(도 14)인 동안에 배신되는 EFDT이며, 스타트업 패키지 URL이 기술된다. 즉, 통신 모드에서는, 씬 2의 전단 파트와 후단 파트에서 제시되는 리소스 파일(Resource4, Resource5)이 모두 통신 경유로 배신되기 때문에, Ver2.0의 EFDT에는, 리소스 파일의 URL은 불필요로 된다.
그리고, Ver2.0의 EFDT의 스타트업 패키지 URL에 의해, Ver1.0의 EFDT에 따라 취득 완료 스타트업 패키지 파일이 참조되고(S32), 리소스 파일 URL에 의해, 통신 경유로 배신되는 리소스 파일(Resource4, Resource5)이 취득된다(S33, S34).
단, 통신 경유로 배신되는 리소스 파일(Resource4, Resource5)의 리소스 파일 URL은, 예를 들어 애플리케이션 매니페스트 파일의 배신 스케줄 정보의 각 리소스 파일(Resource4, Resource5)의 파일 URL을 사용할 수 있다.
이에 의해, 씬 2(도 14)의 전단 파트에서는, 스타트업 페이지 파일 자체는, 최초의 스타트업 페이지 파일과 동일하지만, 통신 경유로 배신되는 리소스 파일(Resource4)의 추가가 행해진 2번째 뷰(도 14)가 제시된다. 또한, 씬 2(도 14)의 후단 파트에서는, 스타트업 페이지 파일 자체는, 최초의 스타트업 페이지 파일과 동일하지만, 리소스 파일(Resource4)의 소거와, 통신 경유로 배신되는 리소스 파일(Resource5)의 추가가 행해진 3번째 뷰(도 14)가 제시된다.
또한, 씬 2로부터 씬 3으로 천이하는 동안에, EFDT의 버전이, Ver2.0(v.2)으로부터 Ver M(v.M)까지 순차적으로 갱신된다. Ver M의 EFDT는, 씬 3(도 14)인 동안에 배신되는 EFDT이며, 스타트업 패키지 URL만이 기술된다.
그리고, Ver M의 EFDT의 스타트업 패키지 URL에 의해, Ver1.0의 EFDT에 따라 취득 완료 스타트업 패키지 파일이 참조되고(S35), 리소스 파일 URL에 의해, 통신 경유로 배신되는 리소스 파일(Resource N)이 취득된다(S36).
단, 통신 경유로 배신되는 리소스 파일(Resource N)의 리소스 파일 URL은, 예를 들어 애플리케이션 매니페스트 파일의 배신 스케줄 정보의 각 리소스 파일의 파일 URL을 사용할 수 있다.
이에 의해, 씬 3에서는, 스타트업 페이지 파일 자체는, 최초의 스타트업 페이지 파일과 동일하지만, 통신 경유로 배신되는 리소스 파일(Resource N)의 추가가 행해진 N번째 뷰(도 14)가 제시된다.
이어서, 도 24 내지 도 26의 흐름도를 참조하여, 통신 모드가 설정된 경우에 있어서의 전송 시스템(1)(도 1)의 각 장치에서 실행되는 처리의 흐름을 설명한다.
(송신측의 처리의 흐름)
최초로, 도 24의 흐름도를 참조하여, 송신측 시스템(10)에 의해 실행되는, 통신 모드가 설정된 경우의 송신측의 처리의 흐름에 대하여 설명한다.
도 24의 스텝 S341 내지 S342에 있어서는, 도 16의 스텝 S301 내지 S302와 마찬가지로, 애플리케이션 서버(도 1)에 의해, 오서링 처리가 행해져, 애플리케이션을 구성하는 파일군이 생성된다.
도 24의 스텝 S421 내지 S427에 있어서는, 도 16의 스텝 S401 내지 S408과 마찬가지로, SCH/PKG 서버(104)(도 1)에 의해, 배신 스케줄의 결정과, EFDT의 생성과, 스타트업 패키지 파일의 생성의 처리가 행해지지만, 스타트업 페이지 파일과 그 스타트업 페이지 파일 내의 리소스 파일, 추가 리소스 파일의 전송처가, 방송 서버(105)가 아니라, 통신 서버(106)로 되는 점이 상이하다.
도 24의 스텝 S541 내지 S542에 있어서는, 도 16의 스텝 S501 내지 S502와 마찬가지로, 방송 서버(105)(도 1)에 의해, EFDT가 파일 모드에서, 스타트업 패키지 파일이 패키지 모드에서, 전송로(80)를 통하여 송신(일제 동보 배신)된다.
도 24의 스텝 S641 내지 S646은, 통신 서버(106)(도 1)에 의해 실행된다. 또한, 통신 서버(106)에 있어서는, 스텝 S446의 처리에서 전송된 스타트업 페이지 파일과 그 스타트업 페이지 파일 내의 리소스 파일과, 스텝 S447의 처리에서 전송된 추가 리소스 파일이 수신된다.
도 24의 스텝 S641 내지 S646에 있어서는, 도 20의 스텝 S621 내지 S622와 마찬가지로, 인터넷(90)을 통한 클라이언트 장치(20)로부터의 요구에 따라, 각종 파일이 배신된다.
스텝 S641에 있어서, 통신 서버(106)는, 인터넷(90)을 통하여, 클라이언트 장치(20)로부터 스타트업 페이지 파일이 요구되었는지 여부를 판정한다. 스텝 S641에 있어서, 스타트업 페이지 파일이 요구되지 않았다고 판정된 경우, 스텝 S641의 판정 처리가 반복된다.
한편, 스텝 S641에 있어서, 스타트업 페이지 파일이 요구되었다고 판정된 경우, 처리는, 스텝 S642로 진행된다. 스텝 S642에 있어서, 통신 서버(106)는, 스텝 S446의 처리에서 전송된 스타트업 페이지 파일(스텝 S341의 처리에서 생성된 스타트업 페이지 파일)을, 요구원인 클라이언트 장치(20)에 대하여, 인터넷(90)을 통하여 배신한다.
스텝 S643에 있어서, 통신 서버(106)는, 인터넷(90)을 통하여, 클라이언트 장치(20)로부터 스타트업 페이지 파일 내 리소스 파일이 요구되었는지 여부를 판정한다. 스텝 S643에 있어서, 스타트업 페이지 파일 내 리소스 파일이 요구되지 않았다고 판정된 경우, 스텝 S643의 판정 처리가 반복된다.
한편, 스텝 S643에 있어서, 스타트업 페이지 파일 내 리소스 파일이 요구되었다고 판정된 경우, 처리는, 스텝 S644로 진행된다. 스텝 S644에 있어서, 통신 서버(106)는, 스텝 S446의 처리에서 전송된 스타트업 페이지 파일 내 리소스 파일(스텝 S341의 처리에서 생성된 리소스 파일)을, 요구원인 클라이언트 장치(20)에 대하여, 인터넷(90)을 통하여 배신한다.
스텝 S645에 있어서, 통신 서버(106)는, 인터넷(90)을 통하여, 클라이언트 장치(20)로부터 추가 리소스 파일이 요구되었는지 여부를 판정한다. 스텝 S645에 있어서, 추가 리소스 파일이 요구되지 않았다고 판정된 경우, 스텝 S645의 판정 처리가 반복된다.
한편, 스텝 S645에 있어서, 추가 리소스 파일이 요구되었다고 판정된 경우, 처리는, 스텝 S646으로 진행된다. 스텝 S646에 있어서, 통신 서버(106)는, 스텝 S447의 처리에서 전송된 추가 리소스 파일(스텝 S341의 처리에서 생성된 리소스 파일)을, 요구원인 클라이언트 장치(20)에 대하여, 인터넷(90)을 통하여 배신한다.
이상, 송신측의 처리의 흐름에 대하여 설명하였다.
(수신측의 처리의 흐름)
이어서, 도 25 및 도 26의 흐름도를 참조하여, 클라이언트 장치(20)에 의해 실행되는, 통신 모드가 설정된 경우의 수신측의 처리의 흐름에 대하여 설명한다. 또한, 이 수신측의 처리가 실행되는 전제로서, 상술한 도 17 및 도 18과 마찬가지로, 클라이언트 장치(20)에서는, 방송 서버(105)로부터 배신되는 방송 프로그램이나, 통신 서버(106)로부터 배신되는 VOD 프로그램 등의 콘텐츠가 재생되어 있는 것으로 한다.
도 25의 스텝 S271 내지 S275에 있어서는, 도 17의 스텝 S201 내지 S205와 마찬가지로, 방송 미들웨어(205)에 의해, 방송 서버(105)로부터 배신되는 EFDT와 스타트업 패키지 파일이 처리되고, 스타트업 패키지 파일의 애플리케이션 매니페스트 파일에, 새로운 스타트업 페이지 URL이 기술되어 있는지 여부가 판정된다(S275).
스텝 S275에 있어서, 애플리케이션 매니페스트 파일에, 새로운 스타트업 페이지 URL이 기술되어 있다고 판정된 경우, 처리는, 스텝 S276으로 진행된다.
스텝 S276에 있어서, 프록시 서버(212)는, 스텝 S275의 판정 결과에 따라, 인터넷(90)을 통하여 통신 서버(106)에 대하여, 스타트업 페이지 파일을 요구한다. 스텝 S277에 있어서, 프록시 서버(212)는, 스텝 S276의 요구에 따라, 인터넷(90)을 통하여 통신 서버(106)로부터 배신되는 스타트업 페이지 파일을 취득한다.
스텝 S278에 있어서, 프록시 서버(212)는, 스타트업 패키지 파일의 애플리케이션 매니페스트 파일에 기술되는 스타트업 페이지 URL을, 브라우저(209)에 통지한다.
스텝 S291에 있어서, 브라우저(209)는, 스텝 S278의 처리에서 통지된 스타트업 페이지 URL에 따라, 프록시 서버(212)에 대하여, 스타트업 페이지 파일을 요구한다.
스텝 S279에 있어서, 프록시 서버(212)는, 브라우저(209)로부터의 스타트업 페이지 파일의 요구에 따라, 회답의 준비가 이루어져 있는 스타트업 페이지 파일을, 브라우저(209)에 회답한다. 이에 의해, 브라우저(209)는, 프록시 서버(212)로부터의 스타트업 페이지 파일을 취득할 수 있다.
스텝 S292에 있어서, 브라우저(209)는, 프록시 서버(212)에 대하여, 스타트업 페이지 파일 내의 리소스 파일을 요구한다.
스텝 S280에 있어서, 프록시 서버(212)는, 브라우저(209)로부터의 스타트업 페이지 파일 내의 리소스 파일의 요구에 따라, 인터넷(90)을 통하여 통신 서버(106)에 대하여, 스타트업 페이지 파일 내의 리소스 파일을 요구한다. 스텝 S281에 있어서, 프록시 서버(212)는, 스텝 S280의 요구에 따라, 인터넷(90)을 통하여 통신 서버(106)로부터 배신되는 스타트업 페이지 파일 내의 리소스 파일을 취득한다.
스텝 S282에 있어서, 프록시 서버(212)는, 스텝 S281의 처리에서 취득된 스타트업 페이지 파일 내의 리소스 파일을, 브라우저(209)에 회답한다.
스텝 S293에 있어서, 브라우저(209)는, 프록시 서버(212)로부터 취득된 스타트업 페이지 파일 및 그 스타트업 페이지 파일 내의 리소스 파일에 기초하여, 스타트업 페이지를 제시한다. 이에 의해, 애플리케이션이, 방송 프로그램 등의 콘텐츠와 함께 표시된다.
도 26의 스텝 S294 내지 S296은, 도 22의 스텝 S258 내지 S260과 마찬가지로, 브라우저(209)에 의해, 통신 경유로 배신되는 추가 리소스 파일의 제시 타이밍이 감시되고, 그 제시 타이밍으로 되었을 때, 추가 리소스 파일이 요구된다.
도 26의 스텝 S283 내지 S285는, 도 22의 스텝 S243 내지 S245와 마찬가지로, 프록시 서버(212)에 의해, 인터넷(90)을 통하여 통신 서버(106)로부터 추가 리소스 파일이 취득되어, 회답된다. 또한, 도 26의 스텝 S297은, 도 22의 스텝 S261과 마찬가지로, 렌더러(213)에 의해, 프록시 서버(212)로부터의 회답에 따라, 추가 리소스 파일이 제시된다. 이에 의해, 애플리케이션(의 스타트업 페이지)에, 추가 리소스의 정보가 추가되게 된다.
이상, 수신측의 처리의 흐름에 대하여 설명하였다.
<4. 시그널링의 예>
이어서, 도 27 내지 도 31을 참조하여, 시그널링의 포맷의 예를 설명한다.
(USD의 포맷)
도 27은, XML 형식의 USD 메타데이터의 포맷의 예를 도시하는 도면이다. 또한, 도 27에 있어서, 요소와 속성 중, 속성에는 「＠」가 부여되어 있다. 또한, 인덴트된 요소와 속성은, 그 상위의 요소에 대하여 지정된 것으로 된다. 이들 관계는, 후술하는 다른 시그널링의 포맷에서도 마찬가지로 된다.
bundleDescription 요소는, 루트 요소이며, userServiceDescription 요소(USD 요소)의 상위 요소로 된다. 이 userServiceDescription 요소는, serviceId 속성, atsc:serviceId 속성, atsc:fullMPDUri 속성, atsc:sTSIDUri 속성, name 요소, serviceLanguage 요소, atsc:capabilityCode 요소 및 deliveryMethod 요소의 상위 요소로 된다.
serviceId 속성과 atsc:serviceId 속성에는, 서비스 ID가 지정된다. atsc:fullMPDUri 속성에는, MPD 메타데이터를 참조하기 위한 URI가 지정된다. atsc:sTSIDUri 속성에는, S-TSID 메타데이터를 참조하기 위한 URI가 지정된다. 또한, S-TSID 메타데이터의 포맷의 상세는, 후술하는 도 28을 참조하여 설명한다.
name 요소에는, ATSC3.0의 서비스의 명칭이 지정된다. name 요소는, lang 속성의 상위 요소로 된다. lang 속성에는, ATSC3.0의 서비스의 명칭의 언어가 지정된다. serviceLanguage 요소에는, ATSC3.0의 서비스에서 이용할 수 있는 언어가 지정된다. atsc:capabilityCode 요소에는, 기능에 관한 코드가 지정된다.
deliveryMethod 요소에는, 데이터의 배신 방법에 관한 정보가 지정된다. deliveryMethod 요소는, atsc:broadcastAppService 요소 및 atsc:unicastAppService 요소의 상위 요소로 된다. atsc:broadcastAppService 요소는, basePattern 요소의 상위 요소이며, 방송 경유로의 배신에 관한 정보가 지정된다. atsc:unicastAppService 요소는, basePattern 요소의 상위 요소이며, 통신 경유로의 배신에 관한 정보가 지정된다.
(S-TSID의 포맷)
도 28은, XML 형식의 S-TSID 메타데이터의 포맷의 예를 도시하는 도면이다.
S-TSID 요소는, 루트 요소이며, RS 요소의 상위 요소로 된다. 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 요소에는, 소스 플로우 정보가 지정된다.
여기서, 도 29에는, 도 28의 S-TSID 메타데이터에 포함되는 SrcFlow 요소의 포맷이 도시되어 있다.
도 29의 SrcFlow 요소는, rt 속성, minBuffSize 속성, EFDT 요소, ContentInfo 요소 및 Payload 요소의 상위 요소로 된다.
minBuffSize 속성에는, 클라이언트 장치(20)가 필요로 하는 최소 버퍼 사이즈가 지정된다. EFDT 요소에는, 확장된 FDT(Extended FDT)에 관한 정보가 지정된다. ContentInfo 요소에는, 콘텐츠에 관한 정보가 지정된다.
Payload 요소는, codePoint 속성, formatID 속성, frag 속성, order 속성, srcFecPayloadID 속성 및 FECParams 속성의 상위 요소이며, 소스 플로우의 오브젝트를 저장하는 ROUTE 패킷의 페이로드에 관한 정보가 지정된다.
또한, formatID 속성의 값에 의해, 파일 모드(단일의 파일을 저장하는 구조) 또는 패키지 모드(복수의 파일을 동봉하는 구조)가 구별된다. 즉, Payload 요소의 속성인 codePoint 속성의 값은, 파일을 분할하여 운반하는 LCT 패킷 헤더의 CodePoint와 동등하게 된다. 이 CodePoint의 값에 의해, Payload 요소의 속성의 값의 조(Payload＠formatID, Payload＠frag, Payload＠order, Payload＠srcFecPayloadID의 값의 조)를 일의로 지정할 수 있도록 되어 있다.
즉, LCT 패킷의 TSI(Transport Session Identifier)의 값에 의해, S-TSID 중 해당되는 LCT 채널(세션)의 기술을 검색하고(S-TSID/RS/LS＠tsi) 또한 당해 LS의 SrcFlow/Payload＠codePoint의 값과, LCT 패킷 헤더의 CodePoint의 값이 매치되는 Payload 속성을 검색한다. 그리고, 검색된 Payload 속성의 속성으로서 기술되는 formatID 속성의 값에 의해, 그 LCT 패킷이 운반하는 파일이, 파일 모드인지, 혹은 패키지 모드인지가 구별되게 된다.
여기서, 도 30에는, 도 29의 SrcFlow 요소에 포함되는 EFDT 요소의 포맷이 도시되어 있다. 도 30의 EFDT 요소는, tsi 속성, idRef 속성, version 속성, maxExpiresDelta 속성, maxTransportSize 속성, FileTemplate 속성 및 FDTParameters 속성의 상위 요소로 된다.
EFDT 요소의 tsi 속성의 값으로 표시되는 ROUTE 프로토콜의 LCT 채널(세션)에는, EFDT(의 파일)과, 그 EFDT에 의해 기술되는 파일군이 전송된다. EFDT(의 파일)과, EFDT에 의해 참조되는 파일군이 전송되는 LCT 채널(세션)에 있어서, EFDT는, TOI(Transport Object Identifier)=0이 어사인되는 한편, 그 밖의 파일군의 TOI는, EFDT 내에 기술된다.
여기서, EFDT 요소는, 도 30에 도시한 구조를 갖고, 루트 요소는, FDT-Instance라고 불리며, FDT-Instance형을 갖고 있다. 이 FDT-Instance 중에는, 복수의 File 요소가 존재하고, 각각의 파일의 전송 제어 속성이 기술된다. 이 전송 제어 속성의 주된 것으로서는, 예를 들어 파일명인 Content-Location이나, 전송 상의 식별자인 TOI 등이 있다.
도 31에는, EFDT의 XML 스키마의 예가 도시되어 있다. 도 31에 있어서는, 프레임(A) 내에, 리소스 파일의 재송 주기(Retransmission-Cycle)의 속성(도 13)과, 리소스 파일의 재송 종료 일시(Retransmission-End)의 속성(도 13)이 정의되어 있다.
<5. 변형예>
상술한 설명으로서는, 디지털 방송의 규격으로서, 미국 등에서 채용되고 있는 방식인 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) 등이라고 칭해지는 경우가 있다. 또한, 시그널링이 XML 등의 마크업 언어에 의해 기술되는 경우에 있어서, 그들 요소나 속성의 명칭은 일례이며, 다른 명칭이 채용되도록 해도 된다. 단, 이들 명칭의 차이는, 형식적인 차이이며, 그들 요소나 속성의 실질적인 내용이 상이한 것은 아니다.
또한, 상술한 설명에서는, LLS 시그널링으로서, SLT 메타데이터를 설명하였지만, LLS 시그널링에는, EAT(Emergency Alerting Table)나 RRT(Region Rating Table) 등의 메타데이터가 포함되도록 해도 된다. EAT 메타데이터는, 긴급하게 고지할 필요가 있는 긴급 정보에 관한 정보를 포함한다. RRT 메타데이터는, 레이팅에 관한 정보를 포함한다.
또한, 애플리케이션은, HTML5 등의 마크업 언어나 JavaScript(등록 상표) 등의 스크립트 언어로 개발된 애플리케이션에 한하지 않고, 예를 들어 Java(등록 상표) 등의 프로그래밍 언어로 개발된 애플리케이션이어도 된다. 또한, 상술한 콘텐츠에는, 동화상이나 광고 외에, 예를 들어 전자 서적이나 게임, 음악 등, 모든 콘텐츠를 포함할 수 있다.
또한, 본 기술은, 전송로로서, 방송망 이외의 전송로, 즉 예를 들어 인터넷이나 전화망 등의 통신 회선(통신망) 등을 이용하는 것을 상정하여 규정되어 있는 소정의 규격(디지털 방송의 규격 이외의 규격) 등에도 적용할 수 있다.
<6. 컴퓨터의 구성>
상술한 일련의 처리는, 하드웨어에 의해 실행할 수도 있고, 소프트웨어에 의해 실행할 수도 있다. 일련의 처리를 소프트웨어에 의해 실행하는 경우에는, 그 소프트웨어를 구성하는 프로그램이, 컴퓨터에 인스톨된다. 도 32는, 상술한 일련의 처리를 프로그램에 의해 실행하는 컴퓨터의 하드웨어의 구성예를 도시하는 도면이다.
컴퓨터(1000)에 있어서, CPU(Central Processing Unit)(1001), ROM(Read Only Memory)(1002), RAM(Random Access Memory)(1003)은, 버스(1004)에 의해 서로 접속되어 있다. 버스(1004)에는, 또한 입출력 인터페이스(1005)가 접속되어 있다. 입출력 인터페이스(1005)에는, 입력부(1006), 출력부(1007), 기록부(1008), 통신부(1009) 및 드라이브(1010)가 접속되어 있다.
입력부(1006)는, 키보드, 마우스, 마이크로폰 등을 포함한다. 출력부(1007)는, 디스플레이, 스피커 등을 포함한다. 기록부(1008)는, 하드 디스크나 불휘발성 메모리 등을 포함한다. 통신부(1009)는, 네트워크 인터페이스 등을 포함한다. 드라이브(1010)는, 자기 디스크, 광디스크, 광자기 디스크, 또는 반도체 메모리 등의 리무버블 미디어(1011)를 구동한다.
이상과 같이 구성되는 컴퓨터(1000)에서는, CPU(1001)가, ROM(1002)이나 기록부(1008)에 기록되어 있는 프로그램을, 입출력 인터페이스(1005) 및 버스(1004)를 통하여, RAM(1003)에 로드하여 실행함으로써, 상술한 일련의 처리가 행해진다.
컴퓨터(1000)(CPU(1001))가 실행하는 프로그램은, 예를 들어 패키지 미디어 등으로서의 리무버블 미디어(1011)에 기록하여 제공할 수 있다. 또한, 프로그램은, 로컬 에어리어 네트워크, 인터넷, 디지털 위성 방송과 같은, 유선 또는 무선의 전송 매체를 통하여 제공할 수 있다.
컴퓨터(1000)에서는, 프로그램은, 리무버블 미디어(1011)를 드라이브(1010)에 장착함으로써, 입출력 인터페이스(1005)를 통하여, 기록부(1008)에 인스톨할 수 있다. 또한, 프로그램은, 유선 또는 무선의 전송 매체를 통하여, 통신부(1009)에서 수신하고, 기록부(1008)에 인스톨할 수 있다. 그 밖에, 프로그램은, ROM(1002)이나 기록부(1008)에 미리 인스톨해 둘 수 있다.
여기서, 본 명세서에 있어서, 컴퓨터가 프로그램에 따라 행하는 처리는, 반드시 흐름도로서 기재된 순서를 따라 시계열로 행해질 필요는 없다. 즉, 컴퓨터가 프로그램에 따라 행하는 처리는, 병렬적 혹은 개별적으로 실행되는 처리(예를 들어, 병렬 처리 혹은 오브젝트에 의한 처리)도 포함한다. 또한, 프로그램은, 하나의 컴퓨터(프로세서)에 의해 처리되는 것이어도 되고, 복수의 컴퓨터에 의해 분산 처리되는 것이어도 된다.
또한, 본 기술의 실시 형태는, 상술한 실시 형태에 한정되는 것은 아니며, 본 기술의 요지를 일탈하지 않는 범위에 있어서 다양한 변경이 가능하다.
또한, 본 기술은, 이하와 같은 구성을 취할 수 있다.
(1) 콘텐츠를 수신하는 수신부와,
상기 콘텐츠와 함께 전송되는, 상기 콘텐츠에 부수되는 애플리케이션의 일부인 하나 또는 복수의 리소스 파일의 배신에 관한 리소스 배신 정보를 취득하는 취득부와,
취득된 상기 리소스 배신 정보에 기초하여, 상기 리소스 파일의 배신에 따른 처리를 행하는 처리부를 구비하는 수신 장치.
(2) 상기 리소스 배신 정보는, 상기 리소스 파일별의 배신 스케줄에 관한 배신 스케줄 정보를 포함하고 있는 (1)에 기재된 수신 장치.
(3) 상기 배신 스케줄 정보는, 상기 리소스 파일별의 취득처를 나타내는 정보, 그리고 상기 리소스 파일별의 사이즈 및 배신 시각 중 적어도 한쪽에 관한 정보를 포함하고 있는 (2)에 기재된 수신 장치.
(4) 상기 리소스 배신 정보는, 시간대에 따라 배신 스케줄이 변경될 가능성이 있는 특정한 리소스 파일의 배신에 관한 전송 제어 정보를 포함하고 있는 (2)에 기재된 수신 장치.
(5) 상기 전송 제어 정보는, 상기 특정한 리소스 파일의 재송 주기 및 재송 종료 시각 중 적어도 한쪽에 관한 정보를 포함하고 있는 (4)에 기재된 수신 장치.
(6) 상기 콘텐츠의 비디오와 오디오의 데이터는, 스트리밍 파일 전송용 프로토콜인 ROUTE(Real-time Object Delivery over Unidirectional Transport) 세션으로 전송되고,
상기 배신 스케줄 정보는, ROUTE 세션으로 전송되는 스타트업 패키지 파일에 동봉되는 애플리케이션 매니페스트 파일에 포함되고,
상기 전송 제어 정보는, ROUTE 프로토콜의 제어 정보인 S-TSID(Service-based Transport Session Instance Description)에 의해 특정되는, ROUTE 세션으로 전송되는 EFDT(Extended FDT)에 포함되는 (4) 또는 (5)에 기재된 수신 장치.
(7) 수신 장치의 데이터 처리 방법에 있어서,
상기 수신 장치가,
콘텐츠와 함께 전송되는, 상기 콘텐츠에 부수되는 애플리케이션의 일부인 하나 또는 복수의 리소스 파일의 배신에 관한 리소스 배신 정보를 취득하고,
취득된 상기 리소스 배신 정보에 기초하여, 상기 리소스 파일의 배신에 따른 처리를 행하는 스텝을 포함하는 데이터 처리 방법.
(8) 상기 리소스 배신 정보는, 상기 리소스 파일별의 배신 스케줄에 관한 배신 스케줄 정보를 포함하고 있는 (7)에 기재된 데이터 처리 방법.
(9) 상기 배신 스케줄 정보는, 상기 리소스 파일별의 취득처를 나타내는 정보, 그리고 상기 리소스 파일별의 사이즈 및 배신 시각 중 적어도 한쪽에 관한 정보를 포함하고 있는 (8)에 기재된 데이터 처리 방법.
(10) 상기 리소스 배신 정보는, 시간대에 따라 배신 스케줄이 변경될 가능성이 있는 특정한 리소스 파일의 배신에 관한 전송 제어 정보를 포함하고 있는 (8)에 기재된 데이터 처리 방법.
(11) 상기 전송 제어 정보는, 상기 특정한 리소스 파일의 재송 주기 및 재송 종료 시각 중 적어도 한쪽에 관한 정보를 포함하고 있는 (10)에 기재된 데이터 처리 방법.
(12) 상기 콘텐츠의 비디오와 오디오의 데이터는, 스트리밍 파일 전송용 프로토콜인 ROUTE 세션으로 전송되고,
상기 배신 스케줄 정보는, ROUTE 세션으로 전송되는 스타트업 패키지 파일에 동봉되는 애플리케이션 매니페스트 파일에 포함되고,
상기 전송 제어 정보는, ROUTE 프로토콜의 제어 정보인 S-TSID에 의해 특정되는, ROUTE 세션으로 전송되는 EFDT에 포함되는 (10) 또는 (11)에 기재된 데이터 처리 방법.
(13) 콘텐츠에 부수되는 애플리케이션의 일부인 하나 또는 복수의 리소스 파일의 배신에 관한 리소스 배신 정보를 생성하는 생성부와,
상기 콘텐츠와 함께, 상기 리소스 배신 정보를 송신하는 송신부를 구비하는 송신 장치.
(14) 상기 리소스 배신 정보는, 상기 리소스 파일별의 배신 스케줄에 관한 배신 스케줄 정보를 포함하고 있는 (13)에 기재된 송신 장치.
(15) 상기 배신 스케줄 정보는, 상기 리소스 파일별의 취득처를 나타내는 정보, 그리고 상기 리소스 파일별의 사이즈 및 배신 시각 중 적어도 한쪽에 관한 정보를 포함하고 있는 (14)에 기재된 송신 장치.
(16) 상기 리소스 배신 정보는, 시간대에 따라 배신 스케줄이 변경될 가능성이 있는 특정한 리소스 파일의 배신에 관한 전송 제어 정보를 포함하고 있는 (14)에 기재된 송신 장치.
(17) 상기 전송 제어 정보는, 상기 특정한 리소스 파일의 재송 주기 및 재송 종료 시각 중 적어도 한쪽에 관한 정보를 포함하고 있는 (16)에 기재된 송신 장치.
(18) 상기 콘텐츠의 비디오와 오디오의 데이터는, 스트리밍 파일 전송용 프로토콜인 ROUTE 세션으로 전송되고,
상기 배신 스케줄 정보는, ROUTE 세션으로 전송되는 스타트업 패키지 파일에 동봉되는 애플리케이션 매니페스트 파일에 포함되고,
상기 전송 제어 정보는, ROUTE 프로토콜의 제어 정보인 S-TSID에 의해 특정되는, ROUTE 세션으로 전송되는 EFDT에 포함되는 (16) 또는 (17)에 기재된 송신 장치.
(19) 송신 장치의 데이터 처리 방법에 있어서,
상기 송신 장치가,
콘텐츠에 부수되는 애플리케이션의 일부인 하나 또는 복수의 리소스 파일의 배신에 관한 리소스 배신 정보를 생성하고,
상기 콘텐츠와 함께, 상기 리소스 배신 정보를 송신하는 스텝을 포함하는 데이터 처리 방법.
1: 전송 시스템
10: 송신측 시스템
20: 클라이언트 장치
80: 전송로
90: 인터넷
101: DASH 서버
102: 시그널링 서버
103: 애플리케이션 서버
104: SCH/PKG 서버
105: 방송 서버
106: 통신 서버
201: 처리부
202: 입력부
203: 메모리
204: 수신부
205: 방송 미들웨어
206: DASH 클라이언트
207: 디코더
208: 출력부
209: 브라우저
210: 통신부
211: 제어부
212: 프록시 서버
213: 렌더러
1000: 컴퓨터
1001: CPU

Claims (19)

  1. 콘텐츠를 수신하는 수신부와,
    상기 콘텐츠와 함께 전송되는, 상기 콘텐츠에 부수되는 애플리케이션의 일부인 하나 또는 복수의 리소스 파일의 배신에 관한 리소스 배신 정보를 취득하는 취득부와,
    취득된 상기 리소스 배신 정보에 기초하여, 상기 리소스 파일의 배신에 따른 처리를 행하는 처리부를 구비하는, 수신 장치.
  2. 제1항에 있어서, 상기 리소스 배신 정보는, 상기 리소스 파일별의 배신 스케줄에 관한 배신 스케줄 정보를 포함하고 있는, 수신 장치.
  3. 제2항에 있어서, 상기 배신 스케줄 정보는, 상기 리소스 파일별의 취득처를 나타내는 정보, 그리고 상기 리소스 파일별의 사이즈 및 배신 시각 중 적어도 한쪽에 관한 정보를 포함하고 있는, 수신 장치.
  4. 제2항에 있어서, 상기 리소스 배신 정보는, 시간대에 따라 배신 스케줄이 변경될 가능성이 있는 특정한 리소스 파일의 배신에 관한 전송 제어 정보를 포함하고 있는, 수신 장치.
  5. 제4항에 있어서, 상기 전송 제어 정보는, 상기 특정한 리소스 파일의 재송 주기 및 재송 종료 시각 중 적어도 한쪽에 관한 정보를 포함하고 있는, 수신 장치.
  6. 제4항에 있어서, 상기 콘텐츠의 비디오와 오디오의 데이터는, 스트리밍 파일 전송용 프로토콜인 ROUTE(Real-time Object Delivery over Unidirectional Transport) 세션으로 전송되고,
    상기 배신 스케줄 정보는, ROUTE 세션으로 전송되는 스타트업 패키지 파일에 동봉되는 애플리케이션 매니페스트 파일에 포함되고,
    상기 전송 제어 정보는, ROUTE 프로토콜의 제어 정보인 S-TSID(Service-based Transport Session Instance Description)에 의해 특정되는, ROUTE 세션으로 전송되는 EFDT(Extended FDT)에 포함되는, 수신 장치.
  7. 수신 장치의 데이터 처리 방법에 있어서,
    상기 수신 장치가,
    콘텐츠와 함께 전송되는, 상기 콘텐츠에 부수되는 애플리케이션의 일부인 하나 또는 복수의 리소스 파일의 배신에 관한 리소스 배신 정보를 취득하고,
    취득된 상기 리소스 배신 정보에 기초하여, 상기 리소스 파일의 배신에 따른 처리를 행하는 스텝을 포함하는, 데이터 처리 방법.
  8. 제7항에 있어서, 상기 리소스 배신 정보는, 상기 리소스 파일별의 배신 스케줄에 관한 배신 스케줄 정보를 포함하고 있는, 데이터 처리 방법.
  9. 제8항에 있어서, 상기 배신 스케줄 정보는, 상기 리소스 파일별의 취득처를 나타내는 정보, 그리고 상기 리소스 파일별의 사이즈 및 배신 시각 중 적어도 한쪽에 관한 정보를 포함하고 있는, 데이터 처리 방법.
  10. 제8항에 있어서, 상기 리소스 배신 정보는, 시간대에 따라 배신 스케줄이 변경될 가능성이 있는 특정한 리소스 파일의 배신에 관한 전송 제어 정보를 포함하고 있는, 데이터 처리 방법.
  11. 제10항에 있어서, 상기 전송 제어 정보는, 상기 특정한 리소스 파일의 재송 주기 및 재송 종료 시각 중 적어도 한쪽에 관한 정보를 포함하고 있는, 데이터 처리 방법.
  12. 제10항에 있어서, 상기 콘텐츠의 비디오와 오디오의 데이터는, 스트리밍 파일 전송용 프로토콜인 ROUTE 세션으로 전송되고,
    상기 배신 스케줄 정보는, ROUTE 세션으로 전송되는 스타트업 패키지 파일에 동봉되는 애플리케이션 매니페스트 파일에 포함되고,
    상기 전송 제어 정보는, ROUTE 프로토콜의 제어 정보인 S-TSID에 의해 특정되는, ROUTE 세션으로 전송되는 EFDT에 포함되는, 데이터 처리 방법.
  13. 콘텐츠에 부수되는 애플리케이션의 일부인 하나 또는 복수의 리소스 파일의 배신에 관한 리소스 배신 정보를 생성하는 생성부와,
    상기 콘텐츠와 함께, 상기 리소스 배신 정보를 송신하는 송신부
    를 구비하는, 송신 장치.
  14. 제13항에 있어서, 상기 리소스 배신 정보는, 상기 리소스 파일별의 배신 스케줄에 관한 배신 스케줄 정보를 포함하고 있는, 송신 장치.
  15. 제14항에 있어서, 상기 배신 스케줄 정보는, 상기 리소스 파일별의 취득처를 나타내는 정보, 그리고 상기 리소스 파일별의 사이즈 및 배신 시각 중 적어도 한쪽에 관한 정보를 포함하고 있는, 송신 장치.
  16. 제14항에 있어서, 상기 리소스 배신 정보는, 시간대에 따라 배신 스케줄이 변경될 가능성이 있는 특정한 리소스 파일의 배신에 관한 전송 제어 정보를 포함하고 있는, 송신 장치.
  17. 제16항에 있어서, 상기 전송 제어 정보는, 상기 특정한 리소스 파일의 재송 주기 및 재송 종료 시각 중 적어도 한쪽에 관한 정보를 포함하고 있는, 송신 장치.
  18. 제16항에 있어서, 상기 콘텐츠의 비디오와 오디오의 데이터는, 스트리밍 파일 전송용 프로토콜인 ROUTE 세션으로 전송되고,
    상기 배신 스케줄 정보는, ROUTE 세션으로 전송되는 스타트업 패키지 파일에 동봉되는 애플리케이션 매니페스트 파일에 포함되고,
    상기 전송 제어 정보는, ROUTE 프로토콜의 제어 정보인 S-TSID에 의해 특정되는, ROUTE 세션으로 전송되는 EFDT에 포함되는, 송신 장치.
  19. 송신 장치의 데이터 처리 방법에 있어서,
    상기 송신 장치가,
    콘텐츠에 부수되는 애플리케이션의 일부인 하나 또는 복수의 리소스 파일의 배신에 관한 리소스 배신 정보를 생성하고,
    상기 콘텐츠와 함께, 상기 리소스 배신 정보를 송신하는
    스텝을 포함하는, 데이터 처리 방법.
KR1020187021835A 2016-02-15 2017-02-01 수신 장치, 송신 장치 및 데이터 처리 방법 KR102656879B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JPJP-P-2016-026420 2016-02-15
JP2016026420 2016-02-15
PCT/JP2017/003531 WO2017141701A1 (ja) 2016-02-15 2017-02-01 受信装置、送信装置、及び、データ処理方法

Publications (2)

Publication Number Publication Date
KR20180113514A true KR20180113514A (ko) 2018-10-16
KR102656879B1 KR102656879B1 (ko) 2024-04-16

Family

ID=59625054

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020187021835A KR102656879B1 (ko) 2016-02-15 2017-02-01 수신 장치, 송신 장치 및 데이터 처리 방법

Country Status (6)

Country Link
US (1) US11336957B2 (ko)
JP (1) JPWO2017141701A1 (ko)
KR (1) KR102656879B1 (ko)
CA (1) CA3013426A1 (ko)
MX (2) MX2018009625A (ko)
WO (1) WO2017141701A1 (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11202314B2 (en) * 2019-06-18 2021-12-14 Sony Group Corporation Immediate retransmission scheme for real time applications
US11464054B2 (en) 2019-07-24 2022-10-04 Sony Group Corporation RTA contention collision avoidance
JP2022084136A (ja) * 2020-11-26 2022-06-07 株式会社東海理化電機製作所 無線通信装置、システムおよびプログラム

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100559006B1 (ko) * 1998-05-07 2006-03-10 마츠시타 덴끼 산교 가부시키가이샤 방송국 시스템 및 수신기
US20130007223A1 (en) * 2006-06-09 2013-01-03 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
KR20130046398A (ko) * 2010-06-04 2013-05-07 미쓰비시덴키 가부시키가이샤 방송 콘텐츠 송신장치 및 방송 콘텐츠 수신장치
KR20140002026A (ko) * 2011-04-05 2014-01-07 퀄컴 인코포레이티드 파일 전달 방법들을 이용한 ｉｐ 브로드캐스트 스트리밍 서비스 배포
KR20150035526A (ko) * 2012-06-25 2015-04-06 엘지전자 주식회사 양방향 서비스를 처리하는 장치 및 방법
JP2015180065A (ja) 2012-05-10 2015-10-08 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、及びプログラム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160164943A1 (en) * 2014-12-05 2016-06-09 Qualcomm Incorporated Transport interface for multimedia and file transport
US10129308B2 (en) * 2015-01-08 2018-11-13 Qualcomm Incorporated Session description information for over-the-air broadcast media data

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100559006B1 (ko) * 1998-05-07 2006-03-10 마츠시타 덴끼 산교 가부시키가이샤 방송국 시스템 및 수신기
US20130007223A1 (en) * 2006-06-09 2013-01-03 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
KR20130046398A (ko) * 2010-06-04 2013-05-07 미쓰비시덴키 가부시키가이샤 방송 콘텐츠 송신장치 및 방송 콘텐츠 수신장치
KR20140002026A (ko) * 2011-04-05 2014-01-07 퀄컴 인코포레이티드 파일 전달 방법들을 이용한 ｉｐ 브로드캐스트 스트리밍 서비스 배포
JP2015180065A (ja) 2012-05-10 2015-10-08 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、及びプログラム
KR20150035526A (ko) * 2012-06-25 2015-04-06 엘지전자 주식회사 양방향 서비스를 처리하는 장치 및 방법

Also Published As

Publication number Publication date
US20200053427A1 (en) 2020-02-13
MX2022015427A (es) 2023-01-11
MX2018009625A (es) 2018-09-11
CA3013426A1 (en) 2017-08-24
US11336957B2 (en) 2022-05-17
WO2017141701A1 (ja) 2017-08-24
KR102656879B1 (ko) 2024-04-16
JPWO2017141701A1 (ja) 2018-12-13

Similar Documents

Publication Publication Date Title
US11632578B2 (en) Apparatus and method for configuring control message in broadcasting system
US20210266629A1 (en) Reception apparatus, transmission apparatus, and data processing method
CN101217642A (zh) 发送预览内容的方法和接收预览内容的方法与装置
JP2022093660A (ja) 受信方法、及び、送信方法
CN107534793B (zh) 接收装置、传输装置以及数据处理方法
WO2018079295A1 (ja) 情報処理装置、及び、情報処理方法
KR20180113514A (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
KR102468131B1 (ko) 수신 장치, 송신 장치, 및 데이터 처리 방법
KR102491466B1 (ko) 수신 장치, 송신 장치, 및 데이터 처리 방법
KR20170141676A (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
JP2014060587A (ja) 端末装置

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant