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

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

Info

Publication number
KR102611253B1
KR102611253B1 KR1020177036843A KR20177036843A KR102611253B1 KR 102611253 B1 KR102611253 B1 KR 102611253B1 KR 1020177036843 A KR1020177036843 A KR 1020177036843A KR 20177036843 A KR20177036843 A KR 20177036843A KR 102611253 B1 KR102611253 B1 KR 102611253B1
Authority
KR
South Korea
Prior art keywords
application
data
cache
unit
processing
Prior art date
Application number
KR1020177036843A
Other languages
English (en)
Other versions
KR20180034332A (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 KR20180034332A publication Critical patent/KR20180034332A/ko
Application granted granted Critical
Publication of KR102611253B1 publication Critical patent/KR102611253B1/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/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/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0813—Multiuser, multiprocessor or multiprocessing cache systems with a network or matrix configuration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • 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/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/4355—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream involving reformatting operations of additional data, e.g. HTML pages on a television screen
    • 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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • 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/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and 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/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
    • 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/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/64—Addressing
    • H04N21/6405—Multicasting
    • 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/64—Addressing
    • H04N21/6408—Unicasting
    • 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/64322—IP
    • 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/812—Monomedia components thereof involving advertisement 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/8173—End-user applications, e.g. Web browser, game
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/31—Providing disk cache in a specific location of a storage system
    • G06F2212/314—In storage network, e.g. network attached cache

Abstract

수신 장치에 있어서, 애플리케이션 단위 또는 프리젠테이션ㆍ유닛 단위의 캐시 처리를 실행시켜, 완성도가 높은 애플리케이션 실행 처리를 가능하게 하는 장치, 방법을 제공한다. 수신 장치가, 송신 장치로부터 애플리케이션의 데이터 사이즈인 애플리케이션 사이즈와, 애플리케이션 링크 정보, 또한 애플리케이션 구성 요소인 프리젠테이션ㆍ유닛(PU) 각각의 데이터 사이즈를 기록한 시그널링 데이터를 수신한다. 수신 장치는 캐시 사이즈와, 애플리케이션이나, PU 각각의 데이터 사이즈를 비교하여, 캐시 가능한 애플리케이션 또는 PU를 캐시 대상 데이터로서 결정하고, 애플리케이션 또는 PU 단위의 캐시 처리를 실행한다.

Description

수신 장치, 송신 장치 및 데이터 처리 방법
본 개시는, 수신 장치, 송신 장치 및 데이터 처리 방법에 관한 것이다. 더욱 상세하게는, 예를 들어 방송파나 네트워크를 통한 데이터의 수신 또는 송신을 실행하는 수신 장치, 송신 장치 및 통신 데이터 대응의 데이터 처리 방법에 관한 것이다.
화상 데이터나 음성 데이터 등의 콘텐츠를 각 통신 사업자의 서비스 형태에 관계없이 배신(配信) 가능하게 한 데이터 배신 방식으로서 OTT(Over The Top)가 있다. OTT에 의한 배신 콘텐츠는 OTT 콘텐츠라고 불리고, 또한 OTT를 이용한 화상(비디오) 데이터의 배신 서비스는 OTT 비디오나 OTT-V(Over The Top Video)라고 불린다.
OTT-V에 따른 데이터 스트리밍 배신 규격으로서 DASH(Dynamic Adaptive Streaming over HTTP) 규격이 있다. DASH는, HTTP(HyperText Transfer Protocol)를 베이스로 한 스트리밍 프로토콜을 사용한 어댑티브(적응형) 스트리밍 배신에 관한 규격이다.
어댑티브(적응형) 스트리밍에서는, 방송국 등의 콘텐츠 배신 서버는, 데이터 배신처가 되는 각종 클라이언트에 있어서 콘텐츠 재생을 가능하게 하기 위해, 복수의 비트레이트의 동화상 콘텐츠의 세분화 파일과 이들의 속성 정보나 URL(Uniform Resource Locator)을 기술한 매니페스트ㆍ파일을 제작하여, 클라이언트에 제공한다.
클라이언트는, 매니페스트ㆍ파일을 서버로부터 취득하여, 자(自)장치의 표시부 사이즈나 이용 가능한 통신 대역에 따른 최적의 비트레이트 콘텐츠를 선택하고, 선택 콘텐츠를 수신하여 재생한다. 네트워크 대역의 변동에 따라서 비트레이트의 동적인 변경도 가능하고, 클라이언트측에서는, 상황에 따른 최적의 콘텐츠를 수시로 전환하여 수신하는 것이 가능해지고, 영상의 도중 끊김의 발생을 저감시킨 동화상 콘텐츠 재생이 실현된다. 또한, 어댑티브(적응형) 스트리밍에 대해서는, 예를 들어 특허문헌 1(일본 특허 공개 제2011-87103호 공보)에 기재되어 있다.
방송국이나 그 밖의 콘텐츠 서버 등의 송신 장치로부터, 텔레비전, PC, 휴대 단말기 등의 수신 장치에 대하여, 방송파 등에 의한 일방향 통신, 또는 인터넷 등의 네트워크를 통한 쌍방향 통신, 일방향 통신을 사용하여 방송 프로그램 등의 콘텐츠를 송수신하는 시스템에 관한 개발이나 규격화가, 현재, 왕성하게 진행되고 있다.
또한, 방송파 및 네트워크를 통한 데이터 배신을 실현하기 위한 기술을 개시한 종래 기술로서, 예를 들어 특허문헌 2(일본 특허 공개 제2014-057227호 공보)가 있다.
방송파 및 네트워크를 통한 데이터 배신 시스템에 관한 규격으로서, 현재, ATSC(Advanced Television System Committe) 3.0의 규격화가 진행 중이다.
ATSC3.0에서는, ATSC3.0 준거 물리층(ATSC-PHY)을 실장한 방송 배신용 디바이스(튜너 실장 디바이스) 상에 ATSC3.0 방송의 수신 처리 등을 실행하는 미들웨어를 실장시킴으로써, ATSC 방송용 제어 정보 등을 포함하는 시그널링 데이터를 수신하여, 시그널링 데이터에 의한 각종 제어를 가능하게 하는 구성을 검토하고 있다.
구체적으로는, 시그널링 데이터에 의한 제어에 의해, 인터넷 등에서 이용되고 있는 애플리케이션 프로그램, 소위 클라이언트 애플리케이션을 그대로 이용하여, 방송 콘텐츠의 출력 처리나, 방송파 등에 의해 제공되는 각종 애플리케이션을 이용한 데이터 처리를 실현 가능하게 하는 구성을 검토하고 있다.
예를 들어, 가정 내나 핫스폿에 설치된 방송 서비스의 수신 장치(전용 서버 외에도, PC, TV, 태블릿, 스마트폰 등)에 ATSC3.0 준거 물리층(ATSC-PHY), 및 ATSC3.0 방송 수신 미들웨어를 실장한다.
수신 장치에 있어서, ATSC3.0 방송 서비스를 수신한 후, 수신 장치의 재생 제어부나 애플리케이션 제어부 상에서 가동하는 애플리케이션(예를 들어 ATSC3.0 DASH 클라이언트 애플리케이션)을 이용하여, 방송 콘텐츠의 재생이나, 방송에서 배신되는 각종 애플리케이션을 실행하는 것이 가능해진다.
수신 장치에 있어서 애플리케이션을 실행하기 위해서는, 애플리케이션을 구성하는 각종 파일, 예를 들어 동화상 등의 화상 파일, 음성 파일 등을 유저 장치 내의 캐시(기억부)에 저장하는 캐시 처리가 필요해진다.
그러나, 수신 장치의 캐시(기억부)에 충분한 빈 용량이 없을 경우, 애플리케이션의 구성 파일 모두를 저장할 수 없는 경우가 발생한다.
애플리케이션 구성 파일의 일부를 캐시할 수 없는 채로, 애플리케이션을 실행하면, 캐시되지 않은 화상(동화상)이나 음성 데이터의 결락이나, 전혀 애플리케이션을 실행할 수 없다는 애플리케이션ㆍ에러가 발생하는 경우가 있다.
일본 특허 공개 제2011-87103호 공보 일본 특허 공개 제2014-057227호 공보
본 개시는, 예를 들어 상기 문제점을 감안하여 이루어진 것이며, 방송파 등을 통해 애플리케이션을 수신하여 실행하는 수신 장치에 있어서, 애플리케이션, 또는 애플리케이션 구성 요소 단위의 데이터 사이즈나 링크 정보를 취득한 캐시 처리에 의해, 소정의 애플리케이션 단위, 또는 애플리케이션 구성 요소 단위의 애플리케이션 실행을 가능하게 하는 수신 장치, 송신 장치 및 데이터 처리 방법을 제공한다.
또한, 본 개시의 일 실시 형태에서는, 애플리케이션 구성 요소의 데이터 사이즈 정보나, 링크 정보를 취득하여, 이들 취득 정보에 기초하여, 캐시 가능한 애플리케이션 또는 애플리케이션 구성 요소를 선택하여 캐시 처리를 행함으로써, 캐시 데이터에 기초하는 확실한 애플리케이션의 실행을 가능하게 하는 수신 장치, 송신 장치 및 데이터 처리 방법을 제공한다.
본 개시의 제1 측면은,
애플리케이션의 데이터 사이즈인 애플리케이션 사이즈와, 애플리케이션간의 링크 정보인 애플리케이션 링크 정보를 기록한 제1 시그널링 데이터를 수신하는 통신부와,
자장치의 기억부에 저장 가능한 데이터 사이즈인 캐시 사이즈와, 상기 제1 시그널링 데이터로부터 취득하는 링크 관계에 있는 각 애플리케이션의 데이터 사이즈를 비교하여, 캐시 가능한 하나 이상의 애플리케이션을 캐시 대상 애플리케이션으로서 결정하고, 애플리케이션 단위의 캐시 처리를 실행하는 데이터 처리부를 갖는 수신 장치에 있다.
또한, 본 개시의 제2 측면은,
애플리케이션 구성 데이터를 저장한 패킷과,
상기 애플리케이션의 데이터 사이즈인 애플리케이션 사이즈와, 애플리케이션간의 링크 정보인 애플리케이션 링크 정보를 기록한 제1 시그널링 데이터를 저장한 패킷을 생성하는 데이터 처리부와,
상기 데이터 처리부가 생성한 패킷을 송신하는 통신부
를 갖는 송신 장치에 있다.
또한, 본 개시의 제3 측면은,
수신 장치에 있어서 실행하는 데이터 처리 방법이며,
통신부가, 애플리케이션의 데이터 사이즈인 애플리케이션 사이즈와, 애플리케이션간의 링크 정보인 애플리케이션 링크 정보를 기록한 제1 시그널링 데이터를 수신하고,
데이터 처리부가, 자장치의 기억부에 저장 가능한 데이터 사이즈인 캐시 사이즈와, 상기 제1 시그널링 데이터로부터 취득하는 링크 관계에 있는 각 애플리케이션의 데이터 사이즈를 비교하여, 캐시 가능한 하나 이상의 애플리케이션을 캐시 대상 애플리케이션으로서 결정하고, 애플리케이션 단위의 캐시 처리를 실행하는 데이터 처리 방법에 있다.
또한, 본 개시의 제4 측면은,
송신 장치에 있어서 실행하는 데이터 처리 방법이며,
데이터 처리부가,
애플리케이션 구성 데이터를 저장한 패킷과,
상기 애플리케이션의 데이터 사이즈인 애플리케이션 사이즈와, 애플리케이션간의 링크 정보인 애플리케이션 링크 정보를 기록한 제1 시그널링 데이터를 저장한 패킷을 생성하고,
통신부가, 상기 데이터 처리부가 생성한 패킷을 송신하는 데이터 처리 방법에 있다.
본 개시의 또 다른 목적, 특징이나 이점은, 후술하는 본 개시의 실시예나 첨부하는 도면에 기초하여 보다 상세한 설명에 의해 명백해질 것이다. 또한, 본 명세서에 있어서 시스템이란, 복수의 장치의 논리적 집합 구성이며, 각 구성의 장치가 동일 하우징 내에 있는 것으로 제한되지는 않는다.
본 개시의 일 실시예 구성에 의하면, 수신 장치에 있어서, 애플리케이션 단위 또는 프리젠테이션ㆍ유닛 단위의 캐시 처리를 실행시켜, 완성도가 높은 애플리케이션 실행 처리를 가능하게 하는 장치, 방법이 실현된다.
구체적으로는, 수신 장치가, 송신 장치로부터 애플리케이션의 데이터 사이즈인 애플리케이션 사이즈와, 애플리케이션 링크 정보, 추가로 애플리케이션 구성 요소인 프리젠테이션ㆍ유닛(PU) 각각의 데이터 사이즈를 기록한 시그널링 데이터를 수신한다. 수신 장치는 캐시 사이즈와, 애플리케이션이나, PU 각각의 데이터 사이즈를 비교하여, 캐시 가능한 애플리케이션 또는 PU를 캐시 대상 데이터로서 결정하고, 애플리케이션 또는 PU 단위의 캐시 처리를 실행한다.
본 구성에 의해, 수신 장치에 있어서, 애플리케이션 단위 또는 프리젠테이션ㆍ유닛 단위의 캐시 처리를 실행시켜, 완성도가 높은 애플리케이션 실행 처리를 가능하게 하는 장치, 방법이 실현된다.
또한, 본 명세서에 기재된 효과는 어디까지나 예시이며 한정되는 것은 아니고, 또한 부가적인 효과가 있어도 된다.
도 1은, 본 개시의 처리를 실행하는 통신 시스템의 일 구성예에 대하여 설명하는 도면이다.
도 2는, 송신 장치의 송신 데이터에 대하여 설명하는 도면이다.
도 3은, 송신 장치 및 수신 장치의 프로토콜 스택의 예를 나타내는 도면이다.
도 4는, ROUTE 및 FLUTE에 관한 프로토콜 스택을 나타내는 도면이다.
도 5는, 수신 장치(클라이언트)(30)에 있어서의 데이터 출력예를 설명하는 도면이다.
도 6은, 각종 유저 정보를 이용한 출력 광고의 선택예에 대하여 설명하는 도면이다.
도 7은, 수신 장치의 구성예에 대하여 설명하는 도면이다.
도 8은, 애플리케이션의 구성예에 대하여 설명하는 도면이다.
도 9는, 애플리케이션의 구성과 링크에 대하여 설명하는 도면이다.
도 10은, 애플리케이션의 사이즈와, 캐시 사이즈의 대응예에 대하여 설명하는 도면이다.
도 11은, 애플리케이션의 사이즈와, 캐시 사이즈의 대응에 기초하는 캐시 대상 선택 처리예에 대하여 설명하는 도면이다.
도 12는, 시그널링 데이터에 기초하는 애플리케이션 취득 처리예에 대하여 설명하는 도면이다.
도 13은, USBD/USD에 있어서의 방송 배신 애플리케이션 관련 데이터의 기록예에 대하여 설명하는 도면이다.
도 14는, USBD/USD에 있어서의 방송 배신 애플리케이션 관련 데이터의 기록예에 대하여 설명하는 도면이다.
도 15는, AIT의 데이터 기록예에 대하여 설명하는 도면이다.
도 16은, S-TSID의 데이터 기록예에 대하여 설명하는 도면이다.
도 17은, S-TSID의 데이터 기록예에 대하여 설명하는 도면이다.
도 18은, S-TSID의 데이터 기록예에 대하여 설명하는 도면이다.
도 19는, 캐시 사이즈에 따른 캐시 처리의 처리 시퀀스에 대하여 설명하는 흐름도를 나타내는 도면이다.
도 20은, 수신 장치의 캐시 사이즈에 따른 캐시 처리의 구체예에 대하여 설명하는 도면이다.
도 21은, 수신 장치의 캐시 사이즈에 따른 캐시 처리의 구체적인 시퀀스에 대하여 설명하는 흐름도를 나타내는 도면이다.
도 22는, 수신 장치의 캐시 사이즈에 따른 캐시 처리 시에 참조하는 시그널링 데이터의 기술에 대하여 설명하는 도면이다.
도 23은, 수신 장치의 캐시 사이즈에 따른 캐시 처리의 구체예에 대하여 설명하는 도면이다.
도 24는, 수신 장치의 캐시 사이즈에 따른 캐시 처리의 구체적인 시퀀스에 대하여 설명하는 흐름도를 나타내는 도면이다.
도 25는, 수신 장치의 캐시 사이즈에 따른 캐시 처리 시에 참조하는 시그널링 데이터의 기술에 대하여 설명하는 도면이다.
도 26은, 수신 장치의 캐시 사이즈에 따른 캐시 처리의 구체예에 대하여 설명하는 도면이다.
도 27은, 수신 장치의 캐시 사이즈에 따른 캐시 처리의 구체적인 시퀀스에 대하여 설명하는 흐름도를 나타내는 도면이다.
도 28은, 수신 장치의 캐시 사이즈에 따른 캐시 처리 시에 참조하는 시그널링 데이터의 기술에 대하여 설명하는 도면이다.
도 29는, 수신 장치의 캐시 사이즈에 따른 캐시 처리의 구체예에 대하여 설명하는 도면이다.
도 30은, 수신 장치의 캐시 사이즈에 따른 캐시 처리의 구체적인 시퀀스에 대하여 설명하는 흐름도를 나타내는 도면이다.
도 31은, 수신 장치의 캐시 사이즈에 따른 캐시 처리 시에 참조하는 시그널링 데이터의 기술에 대하여 설명하는 도면이다.
도 32는, 수신 장치의 캐시 사이즈에 따른 캐시 처리의 구체예에 대하여 설명하는 도면이다.
도 33은, 수신 장치의 캐시 사이즈에 따른 캐시 처리의 구체적인 시퀀스에 대하여 설명하는 흐름도를 나타내는 도면이다.
도 34는, 수신 장치의 캐시 사이즈에 따른 캐시 처리 시에 참조하는 시그널링 데이터의 기술에 대하여 설명하는 도면이다.
도 35는, 수신 장치가 실행하는 처리에 대하여 설명하는 흐름도를 나타내는 도면이다.
도 36은, 수신 장치가 실행하는 처리에 대하여 설명하는 흐름도를 나타내는 도면이다.
도 37은, 수신 장치가 실행하는 처리에 대하여 설명하는 흐름도를 나타내는 도면이다.
도 38은, 수신 장치가 실행하는 처리에 대하여 설명하는 흐름도를 나타내는 도면이다.
도 39는, 수신 장치가 실행하는 처리에 대하여 설명하는 흐름도를 나타내는 도면이다.
도 40은, 수신 장치가 실행하는 처리에 대하여 설명하는 흐름도를 나타내는 도면이다.
도 41은, 수신 장치가 실행하는 처리에 대하여 설명하는 흐름도를 나타내는 도면이다.
도 42는, 수신 장치가 실행하는 처리에 대하여 설명하는 흐름도를 나타내는 도면이다.
도 43은, 수신 장치가 실행하는 애플리케이션 천이 처리예에 대하여 설명하는 도면이다.
도 44는, 수신 장치가 실행하는 애플리케이션 천이 처리예에 대하여 설명하는 도면이다.
도 45는, 서비스 워커(SW)를 이용한 처리에 대하여 설명하는 도면이다.
도 46은, 서비스 워커(SW)를 이용한 처리에 대하여 설명하는 도면이다.
도 47은, 서비스 워커(SW)를 이용한 처리에 대하여 설명하는 도면이다.
도 48은, 통신 장치인 송신 장치와 수신 장치의 구성예에 대하여 설명하는 도면이다.
도 49는, 통신 장치인 송신 장치와 수신 장치의 하드웨어 구성예에 대하여 설명하는 도면이다.
이하, 도면을 참조하면서 본 개시의 수신 장치, 송신 장치 및 데이터 처리 방법의 상세에 대하여 설명한다. 또한, 설명은 이하의 항목에 따라서 행한다.
1. 통신 시스템의 구성예에 대해서
2. 데이터 통신 프로토콜 FLUTE 및 ROUTE에 대해서
3. 송신 장치와 수신 장치가 실행하는 통신 처리예에 대해서
4. 수신 장치에 있어서의 애플리케이션을 적용한 데이터 출력예에 대해서
5. 수신 장치의 구성예와 처리예에 대해서
6. 애플리케이션의 구성예에 대해서
7. 애플리케이션의 캐시 처리에 대해서
8. 시그널링 데이터의 구성 및 시그널링 데이터를 적용한 캐시 대상 데이터 선택 처리에 대해서
9. 수신 장치의 캐시 사이즈(데이터 저장 허용 사이즈)에 따른 구체적인 처리예에 대해서
9-1. 수신 장치의 데이터 저장 허용 캐시 사이즈가 최소 사이즈(Minimum)이며, 하나의 프리젠테이션ㆍ유닛(PU)만 저장 가능한 경우의 처리예에 대해서
9-2. 수신 장치의 데이터 저장 허용 캐시 사이즈가 소 사이즈(Small)이며, 복수의 프리젠테이션ㆍ유닛(PU)이 저장 가능한 경우의 처리예에 대해서
9-3. 수신 장치의 데이터 저장 허용 캐시 사이즈가 중 사이즈(Medium)이며, 하나의 애플리케이션이 저장 가능한 경우의 처리예에 대해서
9-4. 수신 장치의 데이터 저장 허용 캐시 사이즈가 대 사이즈(Large)이며, 복수의 애플리케이션이 저장 가능한 경우의 처리예에 대해서
9-5. 수신 장치의 데이터 저장 허용 캐시 사이즈가 최대 사이즈(Maximum)이며, 복수의 애플리케이션이 저장 가능한 경우의 처리예에 대해서
10. 수신 장치에 있어서의 데이터 처리의 전체 시퀀스에 대해서
10-1. 수신 장치에 있어서의 방송 스트림 수신 처리의 전체 시퀀스
10-2. 수신 장치에 있어서의 방송 스트림 수신 처리의 상세 시퀀스
10-3. 수신 장치에 있어서의 시그널링의 수신, 해석 처리의 상세 시퀀스
10-4. 수신 장치에 있어서의 애플리케이션의 취득, 실행 처리의 상세 시퀀스
10-5. 수신 장치에 있어서의 방송 경유의 애플리케이션의 취득 처리의 상세 시퀀스
10-6. 수신 장치에 있어서의 프리젠테이션ㆍ유닛(PU) 단위의 캐시 처리의 상세 시퀀스
10-7. 수신 장치에 있어서의 애플리케이션 단위의 캐시 처리의 상세 시퀀스
10-8. 수신 장치에 있어서의 애플리케이션 또는 프리젠테이션ㆍ유닛(PU)간의 천이 처리 시퀀스
11. 애플리케이션 천이 처리의 구체예에 대해서
12. 서비스 워커(SW)를 이용한 캐시 제어 처리예에 대해서
13. 송신 장치와 수신 장치의 구성예에 대해서
14. 본 개시의 구성의 정리
[1. 통신 시스템의 구성예에 대해서]
먼저, 도 1을 참조하여 본 개시의 처리를 실행하는 통신 시스템의 일 구성예에 대하여 설명한다.
도 1에 도시한 바와 같이, 통신 시스템(10)은, 화상 데이터나 음성 데이터 등의 콘텐츠를 송신하는 통신 장치인 송신 장치(20)와, 송신 장치(20)가 송신하는 콘텐츠를 수신하는 통신 장치인 수신 장치(30)를 갖는다.
송신 장치(20)는, 구체적으로는, 예를 들어 주로 TV 프로그램 등을 송신하는 방송 서버(방송국)(21)나, 주로 광고 데이터를 송신하는 광고 서버(22), 각종 데이터를 송신하는 데이터 배신 서버(23) 등, 각종 콘텐츠(방송 프로그램, 광고, 기타 데이터)를 제공하는 측의 장치이다.
한편, 수신 장치(30)는, 일반 유저의 클라이언트 장치이며, 구체적으로는, 예를 들어 텔레비전(31), PC(32), 휴대 단말기(33) 등에 의해 구성된다.
또한, 도 1에는, 수신 장치의 대표예로서, 텔레비전(31), PC(32), 휴대 단말기(33)를 나타내고 있지만, 본 개시의 처리를 실행 가능한 수신 장치로서는, 그 밖에, 예를 들어 스마트폰, 태블릿 단말기, 스마트 시계, 웨어러블 디바이스 등, 각종 수신 장치가 포함된다.
또한, 도 1에서는, 송신 장치(20)의 예로서, 방송 서버(방송국)(21), 광고 서버(22), 데이터 배신 서버(23)를 구별하여 기재하고 있지만, 하나의 서버가 방송 프로그램, 광고, 기타 데이터를 모두 송신하는 구성으로 해도 된다.
예를 들어, 하나의 방송국이, 방송파를 통해 각종 프로그램, 광고, 애플리케이션, 기타 데이터를 배신하는 구성, 또는 하나의 서버가, 통신 네트워크를 통해 각종 프로그램, 광고, 애플리케이션, 기타 데이터를 배신하는 구성 등도 가능하다.
송신 장치(20)와 수신 장치(30)간의 데이터 통신은, 인터넷 등의 네트워크를 통한 쌍방향 통신, 일방향 통신, 또는 방송파 등에 의한 일방향 통신 중 적어도 어느 하나, 또는 양자를 이용한 통신으로서 행해진다.
송신 장치(20)로부터 수신 장치(30)에 대한 콘텐츠 송신은, 예를 들어 어댑티브(적응형) 스트리밍 기술의 규격인 MPEG-DASH 규격이나, MMT(MPEG Media Transport) 등, 다양한 포맷에 따라서 실행된다. 또한, 본 개시의 처리를 실행하는 경우, 데이터 배신 포맷은 한정되지 않는다.
MPEG-DASH 규격에는, 이하의 2개의 규격이 포함된다.
(a) 동화상이나 음성 파일의 관리 정보인 메타데이터를 기술하기 위한 매니페스트ㆍ파일(MPD: Media Presentation Description)에 관한 규격,
(b) 동화상 콘텐츠 전송용 파일 포맷(세그먼트ㆍ포맷)에 관한 규격,
송신 장치(20)로부터, 수신 장치(30)에 대한 콘텐츠 배신은, 상기 MPEG-DASH 규격에 따라서 실행한다.
송신 장치(20)는, 콘텐츠 데이터를 부호화하고, 부호화 데이터 및 부호화 데이터의 메타데이터를 포함하는 데이터 파일을 생성한다. 부호화 처리는, 예를 들어 MPEG에 있어서 규정되는 MP4 파일 포맷에 따라서 행해진다. 또한, 송신 장치(20)가 MP4 형식의 데이터 파일을 생성하는 경우의 부호화 데이터의 파일은 「mdat」, 메타데이터는 「moov」나 「moof」 등으로 불린다.
송신 장치(20)가 수신 장치(30)에 제공하는 콘텐츠는, 예를 들어 음악 데이터나, 영화, 텔레비전 프로그램, 비디오, 사진, 문서, 그림 및 도표 등의 영상 데이터나, 게임 및 소프트웨어 등, 각종 데이터이다.
송신 장치(20)의 송신 데이터에 대하여 도 2를 참조하여 설명한다.
MPEG-DASH 규격에 따라서 데이터 송신을 실행하는 송신 장치(20)는, 도 2에 도시한 바와 같이, 크게 나누어 이하의 복수 종류의 데이터 송신을 행한다.
(a) 시그널링 데이터(50)
(b) AV 세그먼트(60)
(c) 기타 데이터(ESG, NRT 콘텐츠 등)(70)
AV 세그먼트(60)는, 수신 장치에 있어서 재생하는 화상(Video)이나, 음성(Audio) 데이터, 즉, 예를 들어 방송국이 제공하는 프로그램 콘텐츠 등으로 구성된다. 예를 들어, 상술한 MP4 부호화 데이터(mdat)나, 메타데이터(moov, moof)에 의해 구성된다. 또한, AV 세그먼트는, DASH 세그먼트라고도 불린다.
한편, 시그널링 데이터(50)는, 프로그램표 등의 프로그램 예정 정보나, 프로그램 취득에 필요한 어드레스 정보(URL(Uniform Resource Locator) 등), 추가로 콘텐츠의 재생 처리에 필요한 정보, 예를 들어 코덱 정보(부호화 방식 등) 등을 포함하는 안내 정보, 애플리케이션 제어 정보 등의 각종 제어 정보에 의해 구성된다.
수신 장치(30)는, 이 시그널링 데이터(50)를, 재생 대상이 되는 프로그램 콘텐츠를 저장한 AV 세그먼트(60)의 수신에 선행하여 수신하는 것이 필요하다.
이 시그널링 데이터(50)는, 예를 들어 XML(Extensible Markup Language) 형식의 데이터로서 송신 장치(20)로부터 송신된다.
시그널링 데이터는, 수시로 반복 송신된다. 예를 들어 100msec마다 등, 빈번히 반복 송신된다.
이것은, 수신 장치(클라이언트)가, 언제든지 즉석에서 시그널링 데이터를 취득하는 것을 가능하게 하기 위함이다.
클라이언트(수신 장치)는, 수시로 수신 가능한 시그널링 데이터에 기초하여, 필요한 프로그램 콘텐츠의 액세스용 어드레스의 취득이나, 코덱 설정 처리 등, 프로그램 콘텐츠의 수신 및 재생에 필요한 처리를 지체없이 실행하는 것이 가능해진다.
기타 데이터(70)는, 예를 들어 ESG(Electronic Service Guide), NRT 콘텐츠 등이 포함된다.
ESG는, 전자 서비스 가이드(Electronic Service Guide)이며, 예를 들어 프로그램표 등의 안내 정보이다.
NRT 콘텐츠는 논리얼타임형 콘텐츠이다.
NRT 콘텐츠에는, 예를 들어 클라이언트인 수신 장치(30)의 브라우저 상에서 실행되는 각종 애플리케이션이나, 동화상, 정지 화상 등의 데이터 파일 등이 포함된다.
도 2에 나타내는 이하의 데이터, 즉,
(a) 시그널링 데이터(50)
(b) AV 세그먼트(60)
(c) 기타 데이터(ESG, NRT 콘텐츠 등)(70)
이들 데이터는, 예를 들어 데이터 통신 프로토콜: FLUTE(File Delivery over Uni-directional Transport)에 따라서 송신된다.
[2. 데이터 통신 프로토콜 FLUTE 및 ROUTE에 대해서]
데이터 통신 프로토콜: FLUTE(File Deliveryover Uni-directional Transport)는 멀티캐스트에 의해 전송하는 콘텐츠의 세션 관리를 행하는 프로토콜이다.
예를 들어 송신 장치인 서버측에서 생성되는 파일(URL과 버전으로 식별됨)은, FLUTE 프로토콜에 따라서, 수신 장치인 클라이언트에 송신된다.
수신 장치(클라이언트)(30)는, 예를 들어 기억부(클라이언트 캐시)에, 수신 파일의 URL 및 버전과 파일을 대응지어 축적한다.
동일한 URL에서 버전이 상이한 것은 파일의 내용이 갱신되어 있는 것으로 간주한다. FLUTE 프로토콜은 일방향 파일 전송 제어만을 행하는 것으로, 클라이언트에 있어서의 파일의 선택적인 필터링 기능은 없지만, FLUTE로 전송 제어하는 파일을 그 파일에 관련지어진 메타데이터를 이용하여, 클라이언트측에서 취사 선택함으로써, 선택적인 필터링을 실현하고, 유저의 기호를 반영한 로컬 캐시를 구성ㆍ갱신 관리하는 것이 가능해진다.
또한, 메타데이터는, FLUTE 프로토콜로 확장하여 내장할 수도 있고, 별도로 ESG(Electronic Service Guide) 등의 프로토콜로 기술할 수도 있다.
또한, FLUTE는, 당초 멀티캐스트에 있어서의 파일 전송 프로토콜로서 사양화되었다. FLUTE는, FDT와, ALC라고 불리는 스케일러블 파일 오브젝트의 멀티캐스트 프로토콜, 구체적으로는 그 빌딩 블록인 LCT나 FEC 컴포넌트의 조합에 의해 구성된다.
종래의 FLUTE는, 주로 비동기형 파일 전송에 이용하기 위해 개발되었지만, 현재, 방송파 및 네트워크를 통한 데이터 배신 시스템에 관한 규격화 단체인 ATSC(Advanced Television System Committe)에 있어서, 브로드캐스트 라이브 스트리밍에도 적용하기 쉽게 하기 위한 확장을 행하고 있다. 이 FLUTE의 확장 사양이 ROUTE(Real-Time Object Delivery over Unidirectional Transport)라고 불린다.
방송파 및 네트워크를 통한 데이터 배신 시스템에 관한 규격의 하나로서 현재, 표준화가 진행되고 있는 규격으로서 ATSC(Advanced Television System Committe) 3.0이 있다. 이 ATSC3.0은, ROUTE를 종래의 FLUTE 프로토콜로 치환하여, 시그널링 데이터나, ESG, 또는 비동기 파일, 동기형 스트림 등의 송신에 채용한 스택 구성을 규정하고 있다.
[3. 송신 장치와 수신 장치가 실행하는 통신 처리예에 대해서]
이어서, 송신 장치와 수신 장치가 실행하는 통신 처리예에 대하여 설명한다.
도 3은, 송신 장치 및 수신 장치의 프로토콜 스택의 예를 나타내는 도면이다.
도 3에 나타내는 예는, 이하 2개의 통신 데이터의 처리를 행하기 위한 2개의 프로토콜 스택을 갖는다.
(a) 브로드캐스트(멀티캐스트도 포함함) 통신(예를 들어 방송형 데이터 배신)
(b) 유니캐스트(브로드밴드) 통신(예를 들어 HTTP형의 P2P 통신)
도 3의 좌측이 (a) 브로드캐스트 통신(예를 들어 방송형 데이터 배신)에 대응하는 프로토콜 스택이다.
도 3의 우측이, (b) 유니캐스트(브로드밴드) 통신(예를 들어 HTTP형의 P2P 통신)에 대응하는 프로토콜 스택이다.
도 3의 좌측에 나타내는 (a) 브로드캐스트 통신(예를 들어 방송형 데이터 배신)에 대응하는 프로토콜 스택은, 하위 레이어로부터 순서대로, 이하의 레이어를 갖는다.
(1) 브로드캐스트 물리 레이어(Broadcast PHY)
(2) IP 멀티캐스트 레이어(IP Multicast)
(3) UDP 레이어
(4) ROUTE(=확장형 FLUTE) 레이어
(5) ESG, NRTcontent, DASH(ISO BMFF) 및 Video/Audio/CC
(6) 애플리케이션 레이어(Applications(HTML5(HyperText Markup Language 5))
또한, (2) IP 멀티캐스트 레이어(IP Multicast)의 상위 레이어로서 시그널링(Signaling) 레이어가 설정된다.
시그널링 레이어는, 먼저 도 2를 참조하여 설명한 시그널링 데이터(50)의 송수신에 적용되는 레이어이다. 시그널링 데이터에는, 프로그램표 등의 프로그램 예정 정보나, 프로그램 취득에 필요한 어드레스 정보(URL 등), 또한 콘텐츠의 재생 처리에 필요한 정보, 예를 들어 코덱 정보(부호화 방식 등) 등을 포함하는 안내 정보, 제어 정보 등이 포함된다.
시그널링 데이터는, 수신 장치(클라이언트)가 수신, 재생하는 AV 세그먼트의 액세스 정보나, 복호 처리 등의 수신 후의 처리에 필요한 안내 정보나 제어 정보를 포함하는 데이터이며, 송신 장치로부터 수시로 반복 송신되는 데이터이다.
시그널링 데이터에는, 정보에 따른 여러 가지 종류가 있다. 구체적으로는, 예를 들어 서비스 단위의 시그널링 데이터인 USD(유저 서비스 디스크립션(User Service Description))가 있다.
USD에는, 여러 가지 종류의 제어 정보가 포함된다. 대표적인 제어 정보로서, 콘텐츠(AV 세그먼트)에 대응하는 각종 안내 정보, 제어 정보를 저장한 매니페스트ㆍ파일을 갖는 시그널링 데이터인 MPD(미디어 프리젠테이션 디스크립션(Media Presentation Description))가 있다.
각종 시그널링 데이터는, 각각 수신 장치(클라이언트)에 있어서, 송신 장치로부터 송신되는 AV 세그먼트나 애플리케이션(애플리케이션 프로그램)의 수신, 재생 처리, 제어 처리에 필요한 데이터이며, 예를 들어 카테고리별로 개별 파일(메타파일)로서 설정되어, 송신 장치로부터 송신된다.
또한, (1) 브로드캐스트 물리 레이어(Broadcast PHY)의 상위 레이어로서 장래의 새로운 프로토콜의 이용 허용 레이어(Future Extensibility)가 설정되어 있다.
(1) 브로드캐스트 물리 레이어(Broadcast PHY)는, 브로드캐스트 통신을 실행하기 위한 예를 들어 방송계의 통신부를 제어하는 통신 제어부에 의해 구성되는 물리 레이어이다.
(2) IP 멀티캐스트 레이어(IP Multicast)는, IP 멀티캐스트에 따른 데이터 송수신 처리를 실행하는 레이어이다.
(3) UDP 레이어는, UDP 패킷의 생성, 해석 처리 레이어이다.
(4) ROUTE 레이어는, 확장형 FLUTE 프로토콜인 ROUTE 프로토콜에 따라서 전송 데이터의 저장이나 취출을 행하는 레이어이다.
ROUTE는, FLUTE와 동일하게, ALC라고 불리는 스케일러블 파일 오브젝트의 멀티캐스트 프로토콜이며, 구체적으로는 그 빌딩 블록인 LCT나 FEC 컴포넌트의 조합에 의해 구성된다.
도 4에, ROUTE 및 FLUTE에 관한 프로토콜 스택을 나타낸다.
(5) ESG, NRTcontent, DASH(ISO BMFF) 및 Video/Audio/CC는, ROUTE 프로토콜에 따라서 전송되는 데이터이다.
DASH 규격에 따른 동보(同報)형 배신 서비스는, MBMS(Multimedia Broadcast Multicast Service)라고 불린다. 이 MBMS를 LTE로 효율적으로 실현시키는 방식으로서 eMBMS(evolved Multimedia Broadcast Multicast Service)가 있다.
MBMS나 eMBMS는, 동보형 배신 서비스이며, 특정 에어리어 내에 위치하는 수신 장치인 복수의 유저 단말기(UE)에 대하여 공통의 베어러로 일제히 동일한 데이터, 예를 들어 영화 콘텐츠 등을 배신하는 서비스이다. MBMS나 eMBMS에 따른 동보 배신에 의해, 배신 서비스 제공 에어리어에 위치하는 다수의 스마트폰이나 PC, 또는 텔레비전 등의 수신 장치에, 동일한 콘텐츠를 동시에 제공할 수 있다.
MBMS 및 eMBMS는, 3GPP 파일 포맷(ISO-BMFF 파일, MP4 파일)에 따른 파일을, 전송 프로토콜 ROUTE 또는 FLUTE에 따라서 다운로드하는 처리에 대하여 규정하고 있다.
먼저 도 2를 참조하여 설명한 이하의 데이터, 즉,
(a) 시그널링 데이터(50)
(b) AV 세그먼트(60)
(c) 기타 데이터(ESG, NRT 콘텐츠 등)(70)
이들 데이터의 대부분은 ROUTE 프로토콜 또는 FLUTE 프로토콜에 따라서 송신된다.
(5) ESG, NRTcontent, DASH(ISO BMFF) 및 Video/Audio/CC는, ROUTE 프로토콜에 따라서 전송되는 데이터이다.
ESG는, 전자 서비스 가이드(Electronic Service Guide)이며, 예를 들어 프로그램표 등의 안내 정보이다.
NRTcontent는 논리얼타임형 콘텐츠이다.
전술한 바와 같이, NRT 콘텐츠에는, 예를 들어 클라이언트인 수신 장치의 브라우저 상에서 실행되는 각종 애플리케이션 파일, 동화상, 정지 화상 등의 데이터 파일 등이 포함된다.
Video/Audio/CC는, DASH 규격에 따라서 배신되는 비디오나 오디오 등, 재생 대상이 되는 실제 데이터이다.
(6) 애플리케이션 레이어(Applications(HTML5)는, ROUTE 프로토콜에 따라서 전송하는 데이터의 생성, 또는 해석, 그 밖에, 각종 데이터의 출력 제어 등을 실행하는 애플리케이션 레이어이며, 예를 들어 HTML5를 적용한 데이터 생성, 해석, 출력 처리 등을 행한다.
한편, 도 3의 우측에 나타내는, (b) 유니캐스트(브로드밴드) 통신(예를 들어 HTTP형의 P2P 통신)에 대응하는 프로토콜 스택은, 하위 레이어로부터 순서대로, 이하의 레이어를 갖는다.
(1) 브로드밴드 물리 레이어(Broaband PHY)
(2) IP 유니캐스트 레이어(IP Unicast)
(3) TCP 레이어
(4) HTTP 레이어
(5) ESG, Signaling, NRTcontent, DASH(ISO BMFF) 및 Video/Audio/CC
(6) 애플리케이션 레이어(Applications(HTML5))
(1) 브로드밴드 물리 레이어(Broaband PHY)는 브로드밴드 통신을 실행하는, 예를 들어 네트워크 카드 등의 통신부를 제어하는 디바이스 드라이버 등의 통신 제어부에 의해 구성되는 물리 레이어이다.
(2) IP 유니캐스트 레이어(IP Unicast)는, IP 유니캐스트 송수신 처리를 실행하는 레이어이다.
(3) HTTP 레이어는, HTTP 패킷의 생성, 해석 처리 레이어이다.
이 상위 레이어는, 도 3 좌측의 (a) 브로드캐스트 통신(예를 들어 방송형 데이터 배신)의 스택 구성과 동일하다.
또한, 송신 장치(서버)(20), 수신 장치(클라이언트)(30)는, 도 3의 2개의 처리계, 즉,
(a) 브로드캐스트 통신(예를 들어 방송형 데이터 배신)
(b) 유니캐스트(브로드밴드) 통신(예를 들어 HTTP형의 P2P 통신)
이들 2개의 통신 프로토콜 스택 중 적어도 어느 것에 따른 처리를 행한다.
도 3에 나타내는 프로토콜 스택에 있어서, ROUTE(FLUTE)에 따라서 멀티캐스트 전송되는 파일군의 속성(파일의 식별자인 URL을 포함함)은, ROUTE(FLUTE)의 제어 파일 내에 기술하는 것이 가능한가 하면, 파일 전송 세션을 기술하는 시그널링(Signaling) 데이터 중에 기술하는 것도 가능하다. 또한, 파일 전송 세션의 가일층의 상세 속성을 (엔드 유저로의 제시 용도에도 적용 가능한) ESG에 의해 기술할 수도 있다.
전술한 바와 같이, 방송파 및 네트워크를 통한 데이터 배신 시스템에 관한 규격의 하나로서 ATSC(Advanced Television System Committe) 3.0의 규격화가 진행되고 있다.
ATSC3.0에 있어서의 IP 베이스의 트랜스포트 스택의 표준화에 있어서, MPEG-DASH의 파일 포맷(ISO-BMFF 파일, MP4 파일)에 기초하는 파일을 FLUTE(File Delivery over Unidirectional Transport)를 확장한 ROUTE(Real-Time Object Delivery over Unidirectional Transport) 프로토콜에 의해 전송하는 방법이 제안되어, 표준 후보 방식으로서 설정되었다.
ROUTE 프로토콜을 적용함으로써, DASH 규격의 프래그먼트화된 MP4(fragmented MP4) 파일 시퀀스와, DASH 규격의 제어 정보(시그널링 데이터) 저장 메타파일인 MPD(Media Presentation Description)), 및 방송 배신을 위한 시그널링 데이터인,
USBD/USD(User Service Bunbdle Description/User Service Description),
S-TSID(Service based Transport Session Description),
등의시그널링 데이터 등을 전송할 수 있다.
USD는, 예를 들어 방송국, 또는 프로그램 등, 소정의 서비스 단위의 정보로 구성되고, 서비스를 수령하기 위한 액세스 정보(URL 등), 코덱 정보, 재생 타이밍 정보 등, 수신 장치에 있어서 서비스를 이용하기 위해 필요로 하는 정보로 구성된다. USBD는, USD의 다발(번들)이다.
S-TSID는, 각 서비스 단위의 부가 정보이며, USD에 기록되지 않은 부가적인 정보가 기록된다.
전술한 바와 같이, ROUTE 프로토콜은 FLUTE를 베이스로 하는 프로토콜이다. FLUTE에 있어서의 전송 제어 파라미터를 기술한 메타데이터 파일을 FDT(File Delivery Table)라고 칭하고, ROUTE에 있어서의 전송 제어 파라미터를 기술한 메타데이터 파일을 S-TSID(Service based Transport Session Description)라고 칭한다. S-TSID는 FDT의 수퍼세트이며 FDT를 포함한다.
ATSC3.0 서비스 레이어의 시그널링 데이터(SLS: Service Layer Signaling)로서 제안되어 있는 USBD/USD, S-TSID, MPD 등은 모두 ROUTE 세션에 의해 전송된다.
또한, ATSC3.0에 따른 방송 서비스에 있어서는, 상술한 ROUTE 프로토콜 외에도, MMT(MPEG Media Transport)를 적용한 통신도 이용 가능하다.
[4. 수신 장치에 있어서의 애플리케이션을 적용한 데이터 출력예에 대해서]
이어서, 방송 서버(21) 등의 송신 장치(20)로부터 다양한 프로그램 콘텐츠나, 애플리케이션 등의 데이터를 수신하여, 출력하는 수신 장치(클라이언트)(30)에 있어서의 데이터 출력예에 대하여 설명한다.
도 5는, 수신 장치(30)가, 방송 서버(21) 등의 송신 장치(20)로부터, 어떤 프로그램 콘텐츠를 수신하여, 수신 장치(30)의 표시부에 표시하고 있는 상태를 나타내고 있다.
방송 서버(21) 등의 송신 장치(20)는, 프로그램 배신과 함께, NRT 콘텐츠(논리얼타임 콘텐츠)로서, 날씨 정보를 표시하는 애플리케이션, 및 이 날씨 정보 표시 애플리케이션에 이용되는 각종 데이터 파일, 예를 들어 동화상, 정지 화상, 음성 등의 각종 데이터를 포함하는 데이터 파일을 수신 장치(30)에 제공한다.
이하에서는, 이들 애플리케이션 및 데이터 파일을 「리소스」라고 칭한다.
수신 장치(30)는, 송신 장치(20)로부터 수신한 「리소스」, 즉, 애플리케이션의 구성하는 데이터 파일을 이용하여, 도 5에 도시한 바와 같이, 프로그램 표시와 함께, 날씨 정보의 표시를 행할 수 있다.
이러한, 애플리케이션을 이용한 데이터 표시를 행하기 위해서는, 애플리케이션을 구성하는 모든 파일, 예를 들어
HTML(HyperText Markup Language) 파일,
동화상 파일,
음성 파일,
스타일 시트,
등의애플리케이션 구성 파일을 모두 취득하여, 수신 장치(30)의 기억부인 캐시부에 저장해두는 것이 필요하다.
그러나, 예를 들어 수신 장치의 캐시 용량이 부족하여, 일부 동화상 파일을 캐시할 수 없다는 상태가 발생하고, 이 상태에서 애플리케이션을 실행하면, 캐시되지 못한 동화상의 재생 영역이 공백이 된 불완전한 애플리케이션이 실행되는 사태가 발생한다.
이어서, 도 6을 참조하여, 수신 장치(30)가, 송신 장치(20)로부터 수신하는 애플리케이션을 광고 표시에 이용한 예에 대하여 설명한다.
수신 장치(30)에는, 도 6의 하부에 나타내는 타임 라인(시간축(t))에 따라서, 예를 들어 영화나 뉴스, 기타 방송 프로그램(메인 콘텐츠)과 광고가 교대로 출력된다.
유저가 선택한 어떤 채널의 프로그램 개시 시간을 t0이라 하면, 이하와 같이, 시간 추이에 따라서 방송 프로그램과 광고가 교대로 출력된다.
시간 t0 내지 t1: 광고
시간 t1 내지 t2: 방송 프로그램
시간 t2 내지 t3: 광고
시간 t3 내지 t4: 방송 프로그램
시간 t4 내지 t5: 광고
시간 t5 내지: 방송 프로그램
여기서, 수신 장치(30)에 출력되는 광고는, 송신 장치(20)가 송신하는 프로그램 콘텐츠와는 별도로 송신하는 애플리케이션을 이용하여 표시된다. 송신 장치(20)는, 다양한 유저에 따른 광고, 소위 타깃 광고를 표시하는 복수의 광고 애플리케이션을 NRT(논리얼타임) 콘텐츠로서 수신 장치(30)에 송신한다. 예를 들어,
(a) 아이들용 게임 광고 표시 애플리케이션
(b) 젊은이용 패션 아이템의 광고 애플리케이션
(c) 어른용 알코올 음료의 광고 애플리케이션
송신 장치(20)는, 예를 들어 이러한 다양한 유저(시청자)용 광고 애플리케이션을 수신 장치(30)에 대하여 송신한다.
수신 장치(30)는, 수신 장치(30)측에서 설정한 유저(시청자) 정보에 기초하여, 유저에 최적인 광고를 선택 취득하여, 출력한다.
유저 정보란, 예를 들어 유저(시청자)의 연령, 성별, 주소, 취미 기호 등, 다양한 정보이다.
이들 유저 정보는, 수신 장치의 기억부에 미리 등록된 정보를 사용한다.
또는, 프로그램 개시 시점에서, 유저(시청자)에게 유저 정보를 입력시켜, 이 입력 정보를 사용하는 구성으로 해도 된다.
수신 장치(30)가, 예를 들어 방송파를 통해 취득하는 애플리케이션은, 전술한 바와 같이, 각종 데이터 파일에 의해 구성된다. 즉, 전술한 바와 같이,
HTML(HyperText Markup Language) 파일,
동화상 파일,
음성 파일,
스타일 시트,
등의 복수의 애플리케이션 구성 파일을 모두 취득하여, 수신 장치(30)의 기억부인 캐시부에 저장한 후에, 애플리케이션의 실행을 개시함으로써, 완전한 광고 재생을 행할 수 있다.
애플리케이션 구성 파일의 캐시 처리를 확실하게 실행하기 위해서는, 수신 장치(30)는, 자장치의 캐시 빈 용량과, 취득 예정인 애플리케이션의 데이터 사이즈를 비교한 후에, 캐시 가능한 데이터를 선택적으로 취득하여 캐시 처리를 개시하는 것이 중요하다.
이러한 캐시 제어를 실행함으로써, 캐시 처리를 개시한 데이터는, 확실하게 수신 장치(30)의 캐시부(기억부)에 저장할 수 있다.
이러한 캐시 제어를 행하지 않고, 캐시 처리를 개시해버리면, 캐시 처리 도중에, 캐시부(기억부)가 넘쳐, 데이터 일부를 캐시할 수 없는 사태가 발생할 가능성이 있다.
본 개시의 수신 장치(30)는, 자장치의 캐시 빈 용량과, 취득 예정의 애플리케이션의 데이터 사이즈를 비교한 후에, 캐시 가능한 데이터를 선택적으로 취득하여 캐시 처리를 개시하는 캐시 제어를 실행한다.
이 캐시 제어 처리의 구체적인 구성에 대해서는 후술한다.
또한, 도 5, 도 6을 참조하여 설명한 애플리케이션의 예는 일례이며, 송신 장치(20)는, 수신 장치(30)에 대하여 제공하는 애플리케이션은, 도 5, 도 6을 참조하여 설명한 예 이외에도 다양한 애플리케이션이 있다.
예를 들어, 뉴스 정보 제공 애플리케이션, 야구 중계 시의 선수 정보 제공 애플리케이션, 여행 프로그램에 있어서의 지도 정보, 호텔 정보, 퀴즈, 앙케이트 처리 등을 실행하는 애플리케이션 등, 각종 애플리케이션이 있다.
[5. 수신 장치의 구성예와 처리예에 대해서]
이어서, 도 7 이하를 참조하여 수신 장치(30)의 구성예와 처리예에 대하여 설명한다.
또한, 수신 장치(30)는, 먼저 도 1을 참조하여 설명한 바와 같이, 텔레비전(31), PC(32), 휴대 단말기(33), 또는 그 밖에, 예를 들어 스마트폰, 태블릿 단말기, 스마트 시계, 웨어러블 디바이스 등, 각종 기기에 의해 구성된다.
도 7에 나타내는 수신 장치(30)는, 방송 서버나, 광고 서버 등의 송신 장치(20)로부터의 송신 데이터를 수신하는 미들웨어(110)와, 수신 데이터의 해석이나 캐시 처리를 실행하는 프록시 서버(120), 프로그램 재생이나 애플리케이션 실행에 의한 데이터 재생 처리를 실행하는 데이터 재생부(130)를 갖는다.
방송 서버나, 광고 서버 등의 송신 장치(20)는, 방송파나, 인터넷 등의 통신 네트워크를 통한 데이터 송신에 의해, 방송 콘텐츠 등을 포함하는 AV 세그먼트, 애플리케이션, 시그널링 데이터, 기타 데이터를 송신한다.
도 7에 나타내는 수신 장치(30)의 미들웨어(110)는, 송신 장치(20)로부터 방송파를 통한 제공 데이터를 수신하고, 해석한다.
미들웨어(110)는, 통신부(PHY/MAC)(111), 시그널링 데이터를 취득하는 시그널링 취득부(112), 시그널링 데이터를 해석하는 시그널링 해석부(113), 시그널링 데이터, 및 영상, 음성 등의 프로그램 콘텐츠 데이터나, 애플리케이션 등의 NRT 콘텐츠 등의 데이터 파일을 취득하는 세그먼트 취득부(114)를 갖는다.
미들웨어(110)가 수신한 데이터는, 프록시 서버(120)의 캐시 제어부(121)를 통해 캐시부(프록시 캐시)(122)에 저장된다. 프록시 서버(120)는, 또한 네트워크 경유로 송신 장치(20)로부터 취득한 데이터를 캐시부(122)에 저장한다.
프록시 서버(120)의 캐시 제어부(121)는, 데이터 재생부(130)의 재생 제어부(DASH Client)(131)나, 애플리케이션 제어부(132)로부터의 데이터 취득 요구를 입력하고, 요구 데이터를 데이터 재생부에 제공한다.
예를 들어, 캐시 제어부(121)는, 재생 제어부(DASH Client)(131)나, 애플리케이션 제어부(132)로부터의 데이터 취득 요구에 따른 어드레스 해결 처리 등을 행하여, 어드레스에 따른 데이터를 캐시부(121)로부터 취득하여, 데이터 재생부(130)의 재생 제어부(DASH Client)(131)나, 애플리케이션 제어부(132)로 출력한다. 또한, 캐시부(122)에 요구 데이터가 저장되지 않은 경우에는, 외부로부터 취득하여 제공하는 경우도 있다.
데이터 재생부(130)의 재생 제어부(DASH Client)(131)는, DASH(MPEG-DASH) 규격에 따라서 송신된 콘텐츠의 재생 제어를 실행한다.
전술한 바와 같이, MPEG-DASH 규격에는, 이하 2개 규격이 포함된다.
(a) 동화상이나 음성 파일의 관리 정보인 메타데이터를 기술하기 위한 매니페스트ㆍ파일(MPD: Media Presentation Description)에 관한 규격
(b) 동화상 콘텐츠 전송용 파일 포맷(세그먼트ㆍ포맷)에 관한 규격
송신 장치(20)로부터, 수신 장치(30)에 대한 콘텐츠 배신은, 상기 MPEG-DASH 규격에 따라서 실행된다.
콘텐츠는, 예를 들어 MPEG에 있어서 규정되는 MP4 파일 포맷에 따라서 소정 단위의 분할 데이터인 세그먼트(AV 세그먼트 등)로서 송신되고, 재생 제어부(DASH Client)(131)는, 매니페스트ㆍ파일(MPD)을 참조하여, 재생 대상 콘텐츠를 저장한 세그먼트를 취득하는 처리 등을 실행한다.
애플리케이션 제어부(132)는, 예를 들어 먼저 도 5, 도 6을 참조하여 설명한 일기 예보, 광고의 애플리케이션 등, 송신 장치(20)로부터 제공되는 애플리케이션의 실행, 개시, 종료 등의 제어를 행한다.
출력 제어부(133)는, 재생 제어부(131)나 애플리케이션 제어부(132)로부터 제공되는 프로그램 구성 데이터나 애플리케이션 실행용 데이터를 취득하여, 취득 데이터의 복호 처리나, 표시부로의 출력 처리 등을 실행한다.
또한, 재생 제어부(DASH Client)(131)나, 애플리케이션 제어부(132)는, 송신 장치(20)(방송 서버(21), 광고 서버(22) 등)가 송신하는 시그널링 데이터를 참조하여, 시그널링 데이터에 기술된 정보에 따라서 필요한 데이터를 프록시 서버(120)로부터 취득하여, 또한 시그널링 데이터에 기술된 정보에 따라서 재생 제어나 애플리케이션 제어를 실행한다.
먼저 도 2를 참조하여 설명한 바와 같이, 시그널링 데이터(50)는, 프로그램표 등의 프로그램 예정 정보나, 프로그램 취득에 필요한 어드레스 정보(URL(Uniform Resource Locator) 등), 또한 콘텐츠의 재생 처리에 필요한 정보, 예를 들어 코덱 정보(부호화 방식 등) 등을 포함하는 안내 정보, 애플리케이션 제어 정보 등의 각종 제어 정보에 의해 구성된다.
재생 제어부(DASH Client)(131)나, 애플리케이션 제어부(132)는, 시그널링 데이터(SLS: Service Layer Signaling)를 취득하여 취득한 시그널링 데이터에 기초하는 데이터 취득 처리나, 데이터 재생 제어나, 애플리케이션 실행 제어 등을 실행한다.
예를 들어, 애플리케이션 제어부(132)는, 애플리케이션 대응의 속성 정보나 제어 정보를 기록한 각종 시그널링 데이터에 기초하는 애플리케이션 제어를 실행한다. 구체적으로는, 예를 들어 ATSC3.0의 시그널링 데이터인 USBD/USD나, S-TSID, 또는 개개의 애플리케이션에 대응하는 속성 정보나 제어 정보를 기록한 애플리케이션ㆍ인포메이션ㆍ테이블(AIT: Application Information Table) 등을 이용한 애플리케이션 제어를 실행한다.
또한, 재생 제어부(DASH Client)(131)나, 애플리케이션 제어부(132)는, 프록시 서버(120)의 캐시부(122)에 저장된 데이터를 이용한 처리를 실행한다.
캐시부(122)에 저장되는 데이터는, 미들웨어(Client Local ATSC Middleware)(110)가 수신한 데이터나, 프록시 서버(120)가 네트워크를 통해 수신한 데이터이다.
미들웨어(110) 또는 프록시 서버(120)가 방송파 또는 통신 네트워크를 통해 취득하는 데이터는, 예를 들어 DASH-MPD 파일이나 DASH 세그먼트(segment) 파일, 기타 일반적인 애플리케이션 파일, 및 시그널링 데이터를 저장한 SLS(Service level Signaling) 파일 등이다.
이들은, 캐시 제어부(121)의 제어에 기초하여 캐시부(122)에 저장된다.
그 후, 캐시 제어부(121)는, 재생 제어부(DASH Client)(131)나, 애플리케이션 제어부(132)의 요구에 따라서, 캐시부(122)로부터 요구 데이터를 취득하여, 재생 제어부(DASH Client)(131)나, 애플리케이션 제어부(132)에 제공되고, 스트림의 렌더링이나, 애플리케이션의 실행 등의 데이터 재생 처리에 이용된다.
재생 제어부(DASH Client)(131)나, 애플리케이션 제어부(132)가, 세그먼트(segment) 파일, 기타 일반적인 애플리케이션 파일, 및 시그널링 데이터 파일의 취득을, 프록시 서버(120)의 캐시 제어부(121)에 대하여 요구(HTTP 리퀘스트)하면, 그것을 받은 프록시 서버(120)의 캐시 제어부(121)는, 캐시부(122)로부터 데이터 취득을 행한다. 또한, 캐시부(122)에 데이터가 없는 경우에는, 방송 또는 넷 경유에 의한 취득 처리를 행한다.
또한, 재생 제어(DASH Client)(131)나, 애플리케이션 제어부(132)는, 콘텐츠의 재생, 애플리케이션의 제어 정보 등을 기록한 시그널링 데이터를 취득한다. 이들은, 시그널링 취득부(SLS Signaling Retriever)(112)에 의해 취득된다.
예를 들어, USBD/USD나, AIT나, S-TSID, MPD 등의 각종 시그널링 데이터가 취득되어, 이용된다.
시그널링 취득부(SLS Signaling Retriever)(112)는, 통신부(ATSC 튜너: ATSC3.0 PHY/MAC)(111)를 통해 방송 수신하는 SLS LCT 패킷에 의해 운반되는 시그널링 데이터를 추출한다.
이들 시그널링 데이터는, 미들웨어(110)의 시그널링 취득부(112)에 의해 취득되고, 시그널링 해석부(SLS Signaling Parser)(113)에 있어서 해석된다.
시그널링 데이터에는, 예를 들어 프로그램 재생에 필요한 AV 세그먼트나, 애플리케이션의 실행에 필요한 각종 데이터 파일(리소스) 등을 취득하기 위한 어드레스 정보(URL)가 포함되고, 시그널링 해석부(113)는, 필요한 세그먼트나 리소스 파일을 취득하는 어드레스 정보(방송 배신 어드레스 정보)의 취득 처리 등을 행한다.
이 방송 배신 어드레스 정보에 기초하여, 원하는 파일이 저장된 LCT 패킷을 방송 스트림으로부터 취득하여, 취득 데이터가 프록시 서버(120)의 캐시부(122) 내로 전개된다.
또한, 프록시 서버(120)의 캐시 제어부(121)는, 애플리케이션의 취득, 캐시 처리 시에, 캐시부(122)의 캐시 가능한 데이터 용량을 확인하고, 또한 시그널링 데이터로부터 애플리케이션 사이즈나, 애플리케이션의 구성 요소 단위의 데이터 사이즈를 취득하여, 캐시 가능한 데이터를 선택하여 캐시 처리를 실행한다. 이 캐시 처리에 대해서는, 후단에서 상세하게 설명한다.
[6. 애플리케이션의 구성예에 대해서]
먼저 도 5, 도 6을 참조하여 설명한 바와 같이, 수신 장치(30)는, 송신 장치(20)로부터 예를 들어 방송파를 통해 각종 애플리케이션을 수신하고, 수신한 애플리케이션을 실행한다.
송신 장치(20)가 수신 장치(30)에 제공하는 애플리케이션의 구성예에 대해서, 도 8 이하를 참조하여 설명한다.
도 8에는, 하나의 애플리케이션(APP1)(200)의 구성예를 나타내고 있다.
애플리케이션(APP1)(200)은, 하나 이상의 프리젠테이션ㆍ유닛(PU: Presentation Unit)(210)에 의해 구성된다.
또한, 하나의 프리젠테이션ㆍ유닛(PU: Presentation Unit)은, 하나 또는 복수의 HTML(HyperText Markup Language) 파일(211)과, 이 HTML 파일을 이용하여 제시되는 데이터 파일(212)의 세트에 의해 구성된다.
구체적으로는, 예를 들어 하나의 프리젠테이션ㆍ유닛(PU)은, 이하의 구성 요소를 포함하는 유닛이다.
(1) 하나 또는 복수의 HTML 파일,
(2) 상기 HTML에 따라서 출력되는 화상(동화상, 정지 화상) 파일,
(3) 상기 HTML에 따라서 출력되는 음성 파일,
(4) 상기 HTML에 따른 데이터 출력 스타일을 규정한 스타일 시트 저장 파일.
예를 들어, 상기 구성 요소에 의해 하나의 프리젠테이션ㆍ유닛(PU)이 설정된다.
하나의 프리젠테이션ㆍ유닛(PU)에 속하는 데이터가 모두 취득되면, 그 프리젠테이션ㆍ유닛(PU)에 포함되는 HTML 문서에 의한 데이터 출력, 예를 들어 Web 페이지의 출력이 완전한 형태로 실행되는 것이 보증된다.
또한, 애플리케이션(APP1)(200)은, 하나 또는 복수의 프리젠테이션ㆍ유닛(PU: Peresentation Unit)에 의해 구성된다.
도 8에 나타내는 예에서는, 애플리케이션(APP1)(200)은 3개의 프리젠테이션ㆍ유닛(PU11(G1(그룹 1)) 내지 PU31(G3(그룹 3)))을 갖고 있다.
하나의 애플리케이션 내의 각 프리젠테이션ㆍ유닛(PU)은, 각각 상이한 그룹 ID(groupId)가 설정된다.
프리젠테이션ㆍ유닛(PU)의 구성 데이터(HDML 파일, 데이터 파일) 각각에는, 식별자로서 그룹 ID가 설정되고, 각각이 어느 PU에 속하는 데이터인지를 식별 가능한 구성으로 되어 있다.
또한, 프리젠테이션ㆍ유닛(PU11(G1) 내지 PU31(G3)) 사이에는 링크가 설정되는 경우가 있다. 도 8에 나타내는 예에서는, 프리젠테이션ㆍ유닛(PU11(G1))의 HTML 파일(211)로부터, 프리젠테이션ㆍ유닛(PU21(G2))의 HTML 파일로의 링크(213a)가 설정되어 있다.
또한, 프리젠테이션ㆍ유닛(PU11(G1))의 HTML 파일로부터, 프리젠테이션ㆍ유닛(PU31(G3))의 HTML 파일로의 링크(213b)가 설정되어 있다.
링크가 설정된 2개의 PU는, 예를 들어 링크원의 프리젠테이션ㆍ유닛(PU)의 실행 중에, 어떠한 이벤트를 트리거로 하여, 링크처의 프리젠테이션ㆍ유닛의 실행을 개시한다는 PU의 천이를 행하는 관계에 있다.
예를 들어 프리젠테이션ㆍ유닛(PU11(G1))의 HTML 문서에 의한 표시 데이터 중의 일부 영역, 예를 들어 태그 등의 아이콘의 표시 영역을 유저가 클릭하면, 이 클릭 처리가 천이 실행 이벤트로서 검출되어, 링크처의 프리젠테이션ㆍ유닛(PU21(G2))의 HTML 문서에 기초하는 표시 데이터가 표시된다는 처리가 행해진다.
천이 이벤트는, 유저 조작에 한정되지 않고, 예를 들어 애플리케이션ㆍ인포메이션ㆍ테이블(AIT) 등의 시그널링 데이터의 기술 등, 예를 들어 시간 경과에 기초하는 이벤트 등, 각종 이벤트가 있다.
또한, 애플리케이션의 표시 개시나, 표시 종료 등을 지정하는 컨트롤 코드, 기타 애플리케이션 제어 정보는, 애플리케이션 대응의 시그널링 데이터인 애플리케이션ㆍ인포메이션ㆍ테이블(AIT)에 기록되어 있으며, 수신 장치(30)의 애플리케이션 제어부(132)는, AIT의 기록 정보에 따라서 애플리케이션을 실행한다.
또한, AIT에는 특정 애플리케이션(APP)의 취득 정보(URL 등)나, 애플리케이션의 실행 형태를 규정한 컨트롤 코드, 예를 들어 자동 기동 처리(AUTOSTART)나, 프리패치(prefetch) 등의 각종 애플리케이션의 실행 형태 규정 정보인 컨트롤 코드도 기록되어 있다.
또한, 애플리케이션에는, 개별의 애플리케이션을 식별하는 식별자인 애플리케이션 ID가 설정된다.
AIT 등의 시그널링 데이터에는, 애플리케이션 ID와 함께, 그 애플리케이션에 관한 각종 정보, 예를 들어 애플리케이션 사이즈 정보나, 액세스 정보나 제어 정보 등이 기록된다.
AIT 등의 시그널링 데이터에 기록되는 정보의 상세에 대해서는 후단에서 설명한다.
도 8에 나타내는 바와 같이 애플리케이션 ID는,
(a) 조직 ID(orgId),
(b) 애플리케이션 본체 ID(appId),
이들 2개의 ID의 연결 데이터로서 구성된다.
조직 ID는, 애플리케이션을 제공하는 방송국이나, 애플리케이션의 제작자 등의 조직을 나타내는 식별자이다.
애플리케이션 본체 ID는, 애플리케이션 본체 각각에 대응지어 설정되는 식별자이다.
예를 들어 애플리케이션 ID의 전반의 조직 ID를 참조함으로써, 애플리케이션을 제공하는 방송국이나, 애플리케이션의 제작자 등의 조직을 확인하는 것이 가능해지고, 애플리케이션 ID의 후반의 애플리케이션 본체 ID를 참조함으로써, 하나의 조직이 제공하는 복수 애플리케이션 중 하나의 애플리케이션을 개별로 식별하는 것이 가능해진다.
또한, 애플리케이션의 구성 요소인 프리젠테이션ㆍ유닛(PU)에도, 개별의 프리젠테이션ㆍ유닛(PU)을 식별하는 식별자인 프리젠테이션ㆍ유닛 ID(PUID)가 설정된다.
상세한 것은 후술하지만, 프리젠테이션ㆍ유닛(PU)에 관한 액세스 정보 등의 속성 정보를 기록한 S-TSID 등의 시그널링 데이터에는, 프리젠테이션ㆍ유닛(PU)에 속하는 각 파일에 대응지어 프리젠테이션ㆍ유닛 ID(PUID)가 기록된다.
수신 장치(30)는, 방송국 등의 송신 장치(20)가 제공하는 시그널링 데이터인 S-TSID를 참조함으로써, 송신 장치(201)가 제공하는 각 파일이 어느 프리젠테이션ㆍ유닛(PU)에 속하는 파일인지를 식별할 수 있다.
또한, S-TSID에는, 각 프리젠테이션ㆍ유닛(PU) 단위의 데이터 사이즈도 기록된다.
S-TSID 등의 시그널링 데이터에 기록되는 정보의 상세에 대해서는 후단에서 설명한다.
도 8에 나타내는 바와 같이 프리젠테이션ㆍ유닛 ID(PUID)는
(a) 애플리케이션 본체 ID(appId),
(b) 그룹 ID(groupId),
이들 2개의 ID를 연결한 데이터로서 구성된다.
애플리케이션 본체 ID는, 이 프리젠테이션ㆍ유닛이 속하는 애플리케이션 본체에 대응지어 설정되는 식별자이다.
전술한 애플리케이션 ID의 구성 요소가 되는 「애플리케이션 본체 ID」와 동일한 값이 설정되게 된다.
그룹 ID는, 각 프리젠테이션ㆍ유닛(PU) 개별의 식별자이다. 하나의 애플리케이션에 복수의 프리젠테이션ㆍ유닛(PU)이 포함되는 경우, 각각 상이한 그룹 ID가 설정된다.
프리젠테이션ㆍ유닛 ID(PUID)의 전반의 애플리케이션 본체 ID를 참조함으로써, 이 프리젠테이션ㆍ유닛이 속하는 애플리케이션을 확인하는 것이 가능해지고, 프리젠테이션ㆍ유닛 ID(PUID)의 후반의 그룹 ID를 참조함으로써, 하나의 애플리케이션에 포함되는 복수의 프리젠테이션ㆍ유닛(PU)을 개별로 식별하는 것이 가능해진다.
도 8에는, 하나의 애플리케이션(APP1)만을 나타내고 있지만, 수신 장치(30)에 있어서 애플리케이션을 실행하는 경우, 복수의 애플리케이션을 이용한 처리를 행하는 경우도 있다.
구체적인 예에 대해서, 도 9를 참조하여 설명한다.
도 9에는, 이하 3개의 애플리케이션을 나타내고 있다.
(1) 애플리케이션 1(APP1)
(2) 애플리케이션 2(APP2)
(3) 애플리케이션 3(APP3)
도 9에 나타내는 점선 화살표는 링크 관계를 나타내고 있다.
링크는, 도 8을 참조하여 설명한 바와 같이, 각 애플리케이션 내의 프리젠테이션ㆍ유닛(PU) 사이에 설정되어 있음과 함께, 도 9에 나타내는 예에서는, 각 애플리케이션 사이에도 설정되어 있다.
애플리케이션 1 내지 3을 이용한 처리에 있어서, 최초로 기동되는 애플리케이션은 애플리케이션 1(APP1)이며, 그 중 하나의 프리젠테이션ㆍ유닛(PU11)의 HTML 문서가 최초로 기동되는 HTML 문서라고 하자.
또한, 어떤 애플리케이션의 실행 시에 최초로 이용되는 HTML 문서를 엔트리 문서라고 부른다.
도 9에 나타내는 예에서는, 애플리케이션 1(APP1)의 엔트리 문서는, 프리젠테이션ㆍ유닛(PU11)의 HTML 문서인, 즉, 도 9에 나타내는 엔트리 문서(221)이다.
애플리케이션 1(APP1)로부터, 애플리케이션 2(APP2)를 향하는 점선 화살표로 나타내는 링크는, 애플리케이션 1(APP1)의 실행 중에, 예를 들어 유저에 의한 화면 조작, 또는 시간 경과 등의 소정의 천이 이벤트의 발생에 기초하여 애플리케이션 2(APP2)를 기동하는 처리가 행해지는 것을 나타낸다.
이와 같이, 복수의 애플리케이션에 링크를 설정하여, 복수의 애플리케이션을 적용한 처리가 행해지는 경우도 있다.
또한, 애플리케이션간의 링크 관계나, 프리젠테이션ㆍ유닛(PU)간의 링크 관계에 관한 정보는, AIT나 S-TSID 등의 시그널링 데이터에 기록되어 있으며, 수신 장치(30)는, 이들 시그널링 데이터의 기술에 기초하여, 각 링크 관계를 파악하는 것이 가능해진다.
[7. 애플리케이션의 캐시 처리에 대해서]
수신 장치(30)에 있어서, 애플리케이션을 실행하기 위해서는, 애플리케이션의 구성 데이터를 수신 장치의 기억부(캐시부)에 저장(캐시)하는 것이 필요하다.
예를 들어, 도 7에 나타내는 캐시부(122)에, 실행 대상이 되는 애플리케이션의 구성 데이터(애플리케이션 리소스)를 저장하는 것이 필요하다.
애플리케이션을 실행하는 것은, 애플리케이션 제어부(130)이며, 애플리케이션 제어부(130)는, 애플리케이션 실행에 필요한 데이터(리소스)를 캐시부(122)로부터 취득하여 애플리케이션을 실행한다.
캐시부(122)에 필요한 데이터가 저장되지 않은 경우, 애플리케이션의 실행 에러가 발생할 가능성이 있다.
애플리케이션의 실행 타이밍까지 필요한 데이터를 캐시부(122)에 저장하는 것이 필요하지만, 캐시부(122)에 충분한 빈 용량이 없을 경우에는, 애플리케이션 구성 데이터를 모두 캐시부(122)에 저장할 수 없을 가능성도 있다.
본 개시의 구성에 있어서, 수신 장치(30)는, 캐시부(122)에 저장 가능한 데이터량(빈 용량)에 상당하는 캐시 사이즈와, 애플리케이션 사이즈 또는 프리젠테이션ㆍ유닛(PU) 사이즈를 비교하여, 프리젠테이션ㆍ유닛(PU) 단위 또는 애플리케이션 단위로, 캐시부(122)에 대한 데이터 저장 처리(캐시 처리)를 행한다.
적어도 프리젠테이션ㆍ유닛(PU) 단위로 캐시부(122)에 데이터가 저장되어 있으면, 프리젠테이션ㆍ유닛(PU)에 포함되는 HTML 문서를 적용한 데이터 출력은 완전한 형태로 실행되는 것이 보증된다.
이하, 수신 장치(30)에 있어서의 캐시 처리, 즉, 애플리케이션 단위 또는 프리젠테이션ㆍ유닛(PU) 단위로 캐시부(122)에 데이터를 저장하는 처리에 대하여 설명한다.
도 10은, 애플리케이션 및 프리젠테이션ㆍ유닛(PU)의 데이터 사이즈와, 수신 장치의 캐시 사이즈의 대응 관계의 일례에 대하여 설명하는 도면이다.
횡축이 데이터 사이즈 및 캐시 사이즈에 상당하는 축이다.
위로부터, 순서대로,
(A) 애플리케이션 사이즈
(B) 수신 장치의 캐시 사이즈
이들의 각 사이즈 설정예를 나타내고 있다.
(A) 애플리케이션 사이즈로서 나타내는 예는, 도 9를 참조하여 설명한 이하의 3개 애플리케이션의 각 사이즈를 나타내고 있다.
(1) 애플리케이션 1(APP1)
(2) 애플리케이션 2(APP2)
(3) 애플리케이션 3(APP3)
애플리케이션 1(APP1)의 데이터 사이즈는, S3이다.
애플리케이션 1(APP1)+애플리케이션 2(APP2)의 합계 데이터 사이즈는, S4이다.
애플리케이션 1(APP1) 내지 애플리케이션 3(APP3)의 합계 데이터 사이즈는, S5이다.
또한, 애플리케이션 1(APP1)은 3개의 프리젠테이션ㆍ유닛(PU)으로 구성되어 있다.
프리젠테이션ㆍ유닛(PU11)의 데이터 사이즈는, S1이다.
프리젠테이션ㆍ유닛(PU11)+프리젠테이션ㆍ유닛(PU12)의 합계 데이터 사이즈는, S2이다.
프리젠테이션ㆍ유닛(PU11) 내지 프리젠테이션ㆍ유닛(PU13)의 합계 데이터 사이즈는, S3이며, 애플리케이션 1(APP1)의 데이터 사이즈, S3에 일치한다.
한편, (B) 수신 장치의 캐시 사이즈의 예로서, 이하 5개의 캐시 사이즈를 나타내고 있다.
(1) 최소 사이즈(Minimum)
(2) 소 사이즈(Small)
(3) 중 사이즈(Medium)
(4) 대 사이즈(Large)
(5) 최대 사이즈(Maximum)
이들은, 예를 들어 휴대 단말기, PC 등, 송신 장치(20)가 제공하는 애플리케이션을 실행하는 각종 유저 장치로서의 수신 장치(30)의 이용 가능한 캐시 사이즈의 예이다.
(1) 최소 사이즈(Minimum)의 캐시의 저장(캐시) 가능한 데이터 사이즈, 즉, 캐시 사이즈는, S1 이상, S2 미만이다.
(2) 소 사이즈(Small)의 캐시의 저장(캐시) 가능한 데이터 사이즈, 즉, 캐시 사이즈는, S2 이상, S3 미만이다.
(3) 중 사이즈(Medium)의 캐시의 저장(캐시) 가능한 데이터 사이즈, 즉, 캐시 사이즈는, S3 이상, S4 미만이다.
(4) 대 사이즈(Large)의 캐시의 저장(캐시) 가능한 데이터 사이즈, 즉, 캐시 사이즈는, S4 이상, S5 미만이다.
(5) 최대 사이즈(Maximum)의 캐시의 저장(캐시) 가능한 데이터 사이즈, 즉, 캐시 사이즈는, S5 이상이다.
이러한 각종 캐시 사이즈를 갖는 수신 장치가, 송신 장치로부터 송신되는 3개의 애플리케이션을, 캐시부에 캐시(저장)하여, 실행하고자 하는 경우, 각각의 캐시 사이즈에 따라서, 캐시 대상을 선택할 필요가 있다.
이상적으로는, 애플리케이션 1 내지 애플리케이션 3의 모든 애플리케이션 구성 데이터 파일을 모두 저장할 것이 요망되지만, 이들 3개의 모든 애플리케이션을 저장 가능한 것은, (5) 최대 사이즈(Maximum)의 캐시만이다.
(1) 최소 사이즈(Minimum) 내지 (4) 대 사이즈(Large)의 캐시를 갖는 수신 장치는, 캐시 대상 데이터를 선택하여 캐시하는 처리를 행하는 것이 필요하다.
본 개시의 수신 장치의 캐시 대상 선택 처리는, 이하의 룰로 실행된다.
(룰 1) 캐시 사이즈가, 링크 관계에 있는 애플리케이션 모두를 저장 가능하면, 링크 관계에 있는 애플리케이션 모두를 저장(캐시)한다.
(룰 2) 캐시 사이즈가, 링크 관계에 있는 애플리케이션 모두를 저장 가능하지 않은 경우, 애플리케이션 단위 또는 프리젠테이션ㆍ유닛(PU) 단위로, 데이터를 저장(캐시) 한다.
(룰 3) 애플리케이션 단위의 애플리케이션 저장 우선 순위는, 초기 실행 애플리케이션으로부터의 링크 경로에 따른다.
(룰 4) 프리젠테이션ㆍ유닛(PU) 단위의 저장 우선 순위는, 엔트리 문서를 갖는 프리젠테이션ㆍ유닛(PU)으로부터의 링크 경로에 따른다.
수신 장치는, 상기 룰을 적용하여, 자장치의 캐시 사이즈와, 애플리케이션 사이즈 및 각 프리젠테이션ㆍ유닛(PU) 사이즈를 비교하여, 캐시 대상을 선택한다.
상기 룰에 따른 캐시 대상 선택 처리를 행한 경우, 도 10에 나타내는 5개의 캐시 사이즈에 따른 캐시 대상 데이터는, 이하의 설정이 된다.
(1) 최소 사이즈(Minimum)=프리젠테이션ㆍ유닛(PU11)
(2) 소 사이즈(Small)=프리젠테이션ㆍ유닛(PU11)+프리젠테이션ㆍ유닛(PU12)
(3) 중 사이즈(Medium)=애플리케이션(APP1)
(4) 대 사이즈(Large)=애플리케이션(APP1)+애플리케이션(APP2)
(5) 최대 사이즈(Maximum)=애플리케이션(APP1)+애플리케이션(APP2)+애플리케이션(APP3)
수신 장치는, 이들 캐시 대상 선택 처리 시에, 송신 장치(20)가 송신하는 시그널링 데이터인 AIT나 S-TSID를 참조한다.
이들 시그널링 데이터에는, 애플리케이션 단위의 정보, 프리젠테이션ㆍ유닛(PU) 단위의 정보가 기록되어 있다.
예를 들어, 먼저 도 8을 참조하여 설명한 애플리케이션 ID, 프리젠테이션ㆍ유닛 ID(PUID)에 대응지어, 각 애플리케이션, 각 PU의 사이즈 정보나, 링크 정보가 기록되어 있다.
ID 정보를 사용한 캐시 대상 선택 처리예에 대해서, 도 11을 참조하여 설명한다.
도 11에는, 도 10을 참조하여 설명한 이하 5개의 캐시 사이즈에 있어서의 캐시 대상 선택 처리예를 나타내고 있다.
(1) 최소 사이즈(Minimum)
(2) 소 사이즈(Small)
(3) 중 사이즈(Medium)
(4) 대 사이즈(Large)
(5) 최대 사이즈(Maximum)
(1) 최소 사이즈(Minimum)의 허용 캐시 사이즈를 갖는 수신 장치는, 엔트리 문서를 갖는 프리젠테이션ㆍ유닛(PU11)을 최우선의 캐시 대상 PU로서 선택한다.
엔트리 문서를 갖는 프리젠테이션ㆍ유닛(PU11)은, 시그널링 데이터(AIT, S-TSID)에 기초하여 판별할 수 있다.
엔트리 문서를 갖는 프리젠테이션ㆍ유닛(PU11)의 PUID를 갖는 파일을 캐시 대상으로서 선택하여 캐시 처리를 실행한다.
시그널링 데이터로서의 S-TSID에는, 프리젠테이션ㆍ유닛(PU)을 구성하는 파일 단위로, 각 파일의 그룹 ID가 기록되어 있다. 즉, 먼저 도 8을 참조하여 설명한 프리젠테이션ㆍ유닛 ID(PUID)를 구성하는 후반 ID로서 설정되는 그룹 ID가, 각 파일에 대응지어 기록되어 있다.
최소 사이즈(Minimum)의 허용 캐시 사이즈를 갖는 수신 장치는, 엔트리 문서를 갖는 프리젠테이션ㆍ유닛(PU11)의 ID(PUID)의 그룹 ID(groupId1)와 동일한 그룹 ID가, 시그널링 데이터(S-TSID)의 파일 리스트에 기록된 파일을 캐시 대상으로서 선택한다.
또한, 시그널링 데이터의 데이터 기록 구성의 상세에 대해서는 후단에서 설명한다.
(2) 소 사이즈(Small)의 허용 캐시 사이즈를 갖는 수신 장치는, 엔트리 문서를 갖는 프리젠테이션ㆍ유닛(PU11)을 최우선의 캐시 대상 PU로서 선택하고, 또한 이 엔트리 문서를 갖는 프리젠테이션ㆍ유닛(PU11)으로부터 링크처로서 지정되어 있는 제2 프리젠테이션ㆍ유닛(PU12)을 캐시 대상으로 할 수 있다.
전술한 바와 같이, 시그널링 데이터로서의 S-TSID에는, 프리젠테이션ㆍ유닛(PU)을 구성하는 파일 단위로, 각 파일의 그룹 ID가 기록되어 있다.
소 사이즈(Small)의 허용 캐시 사이즈를 갖는 수신 장치는,
엔트리 문서를 갖는 프리젠테이션ㆍ유닛(PU11)의 ID(PUID)의 그룹 ID(groupId1),
링크처의 프리젠테이션ㆍ유닛(PU12)의 ID(PUID)의 그룹 ID(groupId2),
이들 2개의 그룹 ID(groupId1 또는 groupId2) 중 어느 것과 일치하는 그룹 ID가 기록된 파일을, 시그널링 데이터(S-TSID)의 파일 리스트로부터 캐시 대상으로서 선택한다.
(3) 중 사이즈(Medium)의 허용 캐시 사이즈를 갖는 수신 장치는, 초기 실행 애플리케이션(APP1)을 구성하는 프리젠테이션ㆍ유닛(PU11 내지 PU13)을 모두 캐시 대상으로 할 수 있다.
먼저 도 8을 참조하여 설명한 바와 같이, 프리젠테이션ㆍ유닛(PU)에는 프리젠테이션ㆍ유닛 ID(PUID)가 설정되어 있고, 이 ID의 전반은, 애플리케이션 본체 ID에 의해 구성되며, 프리젠테이션ㆍ유닛(PU)이 속하는 애플리케이션이 식별 가능한 설정으로 되어 있다.
따라서, 수신 장치는, 시그널링 데이터로서의 S-TSID에 기록된 프리젠테이션ㆍ유닛(PU)의 리스트로부터, 프리젠테이션ㆍ유닛 ID(PUID)의 전반에 설정된 애플리케이션 본체 ID가, 엔트리 문서의 PU 애플리케이션 본체 ID와 동일값을 갖는 프리젠테이션ㆍ유닛을 캐시 대상으로서 선택하면 된다.
도 11에 나타내는 예에서는, 애플리케이션 본체 ID=appId1이 설정된 프리젠테이션ㆍ유닛(PU), 즉, PU11 내지 PU13에 속하는 파일을 캐시 대상으로서 선택한다.
(4) 대 사이즈(Large)의 허용 캐시 사이즈를 갖는 수신 장치는, 초기 실행 애플리케이션(APP1) 및 애플리케이션(APP1)의 링크처로서 설정된 또 하나의 애플리케이션(APP2)을 캐시 대상으로 할 수 있다.
(4) 대 사이즈(Large)의 허용 캐시 사이즈를 갖는 수신 장치는, 상술한 「(3) 중 사이즈(Medium)의 허용 캐시 사이즈를 갖는 수신 장치」와 동일한 처리에 의해, 애플리케이션(APP1)의 구성 파일을 모두 취득하고, 추가로 애플리케이션(APP1)의 링크처로서 설정된 또 하나의 애플리케이션(APP2)에 대해서, 애플리케이션 본체 ID(appId2)를 검색 키로 하여 애플리케이션 2(APP2)에 속하는 파일을 검색하여 캐시 대상으로 한다.
도 11에 나타내는 예에서는,
애플리케이션 본체 ID=appId1, 또는
애플리케이션 본체 ID=appId2,
이들 중 어느 것이 설정된 프리젠테이션ㆍ유닛(PU), 즉, PU11 내지 PU13, PU21 내지 PU23에 속하는 파일을 캐시 대상으로서 선택한다.
(5) 최대 사이즈(Maximum)의 허용 캐시 사이즈를 갖는 수신 장치는, 초기 실행 애플리케이션(APP1) 및 애플리케이션(APP1)의 링크처로서 설정된 또 하나의 애플리케이션(APP2), 또한 그 링크처로서 설정된 또 하나의 애플리케이션(APP3)을 모두 캐시 대상으로 할 수 있다.
(5) 최대 사이즈(Maximum)의 허용 캐시 사이즈를 갖는 수신 장치는, 상술한 「(4) 대 사이즈(Large)의 허용 캐시 사이즈를 갖는 수신 장치」와 동일한 처리에 의해, 애플리케이션(APP1)과, 애플리케이션(APP2)의 구성 파일을 모두 취득하고, 추가로 애플리케이션(APP2)의 링크처로서 설정된 또 하나의 애플리케이션(APP3)에 대해서, 애플리케이션 본체 ID(appId3)를 검색 키로 하여 애플리케이션 3(APP3)에 속하는 파일을 검색하여 캐시 대상으로 한다.
도 11에 나타내는 예에서는,
애플리케이션 본체 ID=appId1, 또는
애플리케이션 본체 ID=appId2, 또는
애플리케이션 본체 ID=appId3,
이들 중 어느 것이 설정된 프리젠테이션ㆍ유닛(PU), 즉, PU11 내지 PU13, PU21 내지 23, PU31 내지 33에 속하는 파일을 캐시 대상으로서 선택한다.
[8. 시그널링 데이터의 구성 및 시그널링 데이터를 적용한 캐시 대상 데이터 선택 처리에 대해서]
이어서, 도 12 이하를 참조하여, 송신 장치(20)가 수신 장치(30)에 제공하는 시그널링 데이터의 구성과, 수신 장치(30)에 있어서 실행하는 시그널링 데이터를 적용한 캐시 대상 데이터 선택 처리에 대하여 설명한다.
송신 장치(20)는, 송신 장치(20)가 수신 장치(30)에 애플리케이션을 송신함과 함께, 송신 애플리케이션의 액세스 정보나, 애플리케이션의 속성 정보, 제어 정보를 기록한 각종 시그널링 데이터를 수신 장치(30)에 제공한다.
송신 장치(20)가 수신 장치(30)에 제공하는 애플리케이션에 관한 시그널링 데이터로서는, 예를 들어 이하의 데이터가 있다.
(1) USBD/USD(User Service Bunbdle Description/User Service Description)
(2) S-TSID(Service based Transport Session Description),
(3) 애플리케이션ㆍ인포메이션ㆍ테이블(AIT: Application Information Table)
전술한 바와 같이, USD는, 예를 들어 방송국, 또는 프로그램 등, 소정의 서비스 단위의 정보로 구성되고, 서비스를 수령하기 위한 액세스 정보(URL 등), 코덱 정보, 재생 타이밍 정보 등, 수신 장치에 있어서 서비스를 이용하기 위해 필요한 정보로 구성된다. USBD는, USD의 다발(번들)이며, USD도 USBD도 내용적으로는 동일한 제어 정보를 저장한 시그널링 데이터이다. .
S-TSID는, 각 서비스 단위의 부가 정보이며, USD에 기록되지 않은 부가적인 정보가 기록된다.
전술한 바와 같이, ROUTE 프로토콜은 FLUTE를 베이스로 하는 프로토콜이다. FLUTE에 있어서의 전송 제어 파라미터를 기술한 메타데이터 파일을 FDT(File Delivery Table)라고 칭하고, ROUTE에 있어서의 전송 제어 파라미터를 기술한 메타데이터 파일을 S-TSID(Service based Transport Session Description)라고 칭한다. S-TSID는 FDT의 수퍼세트이며 FDT를 포함한다.
AIT는, 하나 또는 복수의 애플리케이션에 대응하여 설정된 애플리케이션 고유의 시그널링 데이터이며, 애플리케이션의 취득용 정보(URL)나, 애플리케이션 실행에 적용되는 제어 정보 등이 기록된다.
이들 시그널링 데이터의 구성과, 이들 시그널링 데이터를 이용한 캐시 대상 데이터의 선택 처리예에 대해서, 도 12 이하를 참조하여 설명한다.
도 12에는,
(1) USBD/USD
(2) AIT
(3) S-TSID
이들 일부 데이터와, 이들 데이터를 이용한 애플리케이션 취득 처리에 대하여 설명하는 도면이다.
또한, USBD/USD, AIT, S-TSID 등의 시그널링 데이터는, 송신 장치(20)로부터 수시로 반복 송신되고 있으며, 수신 장치는, 애플리케이션의 취득에 앞서, 이들 시그널링 데이터를 미리 취득한다. 또한, 취득한 시그널링 데이터를 참조하여 애플리케이션의 액세스 정보를 취득하여 애플리케이션을 취득한다.
애플리케이션은, 방송파, 또는 인터넷 등의 통신 네트워크를 통해 취득할 수 있다.
USBD에는,
(a) 방송파를 통해 애플리케이션이 제공되는 경우의 애플리케이션 취득용의 액세스 정보 구성 데이터인 방송파 대응 베이스 패턴,
(b) 통신 네트워크를 통해 애플리케이션이 제공되는 경우의 애플리케이션 취득용의 액세스 정보 구성 데이터인 통신 네트워크 대응 베이스 패턴, 이들 중 어느 것의 베이스 패턴이 기록된다.
도 12에 나타내는 USBD/USD에는, 애플리케이션이 방송파를 통해 송신되는 경우, 방송파에 대응하는 베이스 패턴 기록 영역(USD/deliveryMethod/atsc: BcAppService/basePattern)에 베이스 패턴이 기록된다.
한편, 애플리케이션이 통신 네트워크를 통해 송신되는 경우, 통신 네트워크에 대응하는 베이스 패턴 기록 영역(USD/deliveryMethod/atsc: UcAppService/basePattern)에 베이스 패턴이 기록된다.
수신 장치는, USBD 또는 USD에 어느 베이스 패턴이 기록되어 있느냐에 따라서, 애플리케이션이 방송파를 통해 송신되는지, 또는 인터넷 등의 통신 네트워크를 통해 송신되는지, 또는 방송파와 인터넷 등의 통신 네트워크의 양쪽을 통해 송신되는지를 판정할 수 있다.
또한, 애플리케이션 대응의 시그널링 데이터인 AIT에는, 특정 애플리케이션을 취득하기 위한 URI가 기록된다.
수신 장치는, 애플리케이션의 취득 처리를 위해, 먼저, 스텝 S11에 있어서, USBD(또는 USD)에 기록된 베이스 패턴을 참조하여, 애플리케이션이 방송파, 통신 네트워크 중 어느 쪽을 이용하여 배신되고 있는지를 확인함과 함께, AIT에 기록된 URI와, 베이스 패턴과 URI를 조합하여 애플리케이션의 액세스 정보(애플리케이션 취득용 어드레스)를 생성한다.
구체적으로는, 송신 장치로부터 송신되는 시그널링 데이터인 USD(유저ㆍ서비스ㆍ디스크립션)의 딜리버리 메소드(deliveryMethod)과, AIT의 애플리케이션 로케이션(ApplicationLocation)의 기술에 기초하여, 애플리케이션의 전송 경로(방송파/네트 통신)를 확인하고, 그 후, 어느 베이스 패턴과 URI를 조합하여 애플리케이션의 액세스 정보(애플리케이션 취득용 어드레스)를 생성한다.
애플리케이션이 통신 네트워크를 통해 배신되고 있다고 확인된 경우, 스텝 S21에 있어서, 생성된 액세스 정보(애플리케이션 취득용 어드레스)를 적용하여, 통신 네트워크를 통해 애플리케이션을 취득한다.
한편, 애플리케이션이 방송파를 통해 배신되고 있다고 확인된 경우, 스텝 S31에 있어서, 또 하나의 시그널링 데이터인 S-TSID를 취득하고,
AIT에 기록된 애플리케이션 로케이션(appLocation(URI)과 일치하는 로케이션 정보(RS/LS/ScFlw/EFDT/＠content-loc)를 갖는 파일의 파일 단위 정보를 검색한다.
S-TSID에는, 프리젠테이션ㆍ유닛(PU)을 구성하는 각 파일 단위의 정보가 기록되어 있다.
또한, S-TSID의 파일 단위 정보에 기록된 TOI(Transport Object Identifier)를 취득한다.
TOI(Transport Object Identifier)는, 송신 장치(20)로부터 송신되는 애플리케이션을 저장한 LCT 패킷의 패킷 헤더에 기록되는 패킷 식별자이다.
LCT 패킷의 패킷 헤더에는 패킷의 페이로드에 따른 식별자로서의 TOI가 기록된다.
수신 장치는, 스텝 S32에 있어서, S-TSID에 기록된 TOI에 기초하여 방송파에 의해 송신되는 LCT 패킷으로부터 목적으로 하는 애플리케이션에 포함되는 파일을 저장한 LCT 패킷을 선택하여 취득한다.
도 12의 (1)에 도시한 바와 같이, USBD/USD에는, 방송파 또는 통신 네트워크 대응의 애플리케이션 액세스 정보로서의 베이스 패턴이 기록된다.
방송파를 통한 NRT 콘텐츠로서 애플리케이션을 송신하는 것을 나타내는 USBD/USD의 기록 데이터의 구체예에 대하여 도 13, 도 14를 참조하여 설명한다.
도 13의 (1)은, 방송파를 통해 송신되는 NRT 서비스의 하나로서 방송파를 통한 NRT 애플리케이션 송신 서비스를 정의한 설정이다.
도면에 도시한 바와 같이, USBD/USD 내의 딜리버리 메소드(deliveryMethod)에 새롭게 방송파를 통한 NRT 애플리케이션 송신 서비스의 정의 영역(231)을 설정한다.
이 새로운 정의 영역에, 하나 이상(1 내지 N)의 방송에 의해 배신하는 NRT 애플리케이션의 베이스 패턴을 기록한다.
도 13의 (2)는, USBD/USD 내의 딜리버리 메소드(deliveryMethod) 내에 정의되어 있는 애플리케이션 송신 서비스 정의 영역(atsc: broadcastAppService) 내에 새롭게 방송파를 통한 NRT 애플리케이션 송신 서비스의 베이스 패턴 정의 영역(232)을 설정한 구성이다.
도 14의 (3)은, 베이스 패턴 그 자체를 기록하는 것이 아니라, 서비스 타입, 즉, 서비스 제공 형태가, 예를 들어 라이브 프로그램의 배신 등의 서비스인 리니어 타입의 서비스인지, 애플리케이션 배신을 포함하는 논리얼타임(NRT) 콘텐츠의 배신 서비스인지를 식별 가능한 플래그(0, 1)를 기록하는 설정이다.
USBD/USD 내의 딜리버리 메소드(deliveryMethod) 내에 정의되어 있는 애플리케이션 송신 서비스 정의 영역(atsc: broadcastAppService) 내에 상기 플래그의 기록 영역(233)을 설치한다.
수신 장치는, 예를 들어 이들 도 13, 도 14에 도시하는 (1) 내지 (3)의 기록 데이터를 참조함으로써, 방송 서비스에 의한 애플리케이션 배신이 실행되고 있는지 여부를 확인할 수 있다.
한편, 시그널링 데이터로서의 AIT(애플리케이션ㆍ인포메이션ㆍ테이블) 및 S-TSID에는, 먼저 도 10, 도 11을 참조하여 설명한 캐시 대상 데이터의 선택 처리를 행하기 위한 데이터가 기록된다.
도 15 및 도 16을 참조하여, AIT, S-TSID의 기록 데이터의 일례에 대하여 설명한다.
도 15는, AIT(애플리케이션ㆍ인포메이션ㆍ테이블)의 기록 데이터의 예를 나타내는 도면이다.
도 15에 나타내는 AIT는, 먼저 도 9, 도 10을 참조하여 설명한 3개의 애플리케이션(APP1 내지 APP3)에 대응하는 정보를 기록한 AIT의 일례이다.
AIT는 하나의 애플리케이션만의 정보를 기록한 설정도 가능하지만, 복수의 관련되는 애플리케이션의 정보를 통합하여 기록한 설정으로 할 수도 있다.
도 15에 나타내는 AIT에는,
애플리케이션 1(APP1)에 관한 정보의 기록 영역(241),
애플리케이션 2(APP2)에 관한 정보의 기록 영역(242),
애플리케이션 3(APP3)에 관한 정보의 기록 영역(243),
이들 정보 기록 영역이 포함된다.
각 애플리케이션 정보 기록 영역(241 내지 243)의 각각에는,
애플리케이션 ID(251),
애플리케이션 액세스 정보(appLocation(URI))(252),
애플리케이션 사이즈(253),
링크처 애플리케이션 정보(254),
이들 정보가 기록된다.
애플리케이션 ID(251)는, 먼저 도 8을 참조하여 설명한 애플리케이션 식별자이다.
즉, 조직 ID(orgId)와, 애플리케이션 본체 ID(appId)로 구성되는 애플리케이션 ID이다.
애플리케이션 액세스 정보(appLocation(URI))(252)는, 애플리케이션을 취득하기 위해 이용되는 URI이다. 먼저 도 12를 참조하여 설명한 바와 같이, USBD에 기록된 베이스 패턴과 함께 액세스 정보가 생성 가능해진다.
애플리케이션 사이즈(253)는, 하나의 애플리케이션에 포함되는 모든 구성 데이터의 총 데이터 사이즈이다.
예를 들어, 도 9에 나타내는 애플리케이션 1(APP1)의 경우, 3개의 프리젠테이션ㆍ유닛(PU11 내지 PU13)을 구성하는 파일의 총 사이즈가 기록된다. 도 10에 나타내는 예에서는, 애플리케이션 1(APP1)의 사이즈는 S1이며, 이 S1이, 애플리케이션 사이즈(253)로서 기록된다.
링크처 애플리케이션 정보(254)는, 먼저 도 9를 참조하여 설명한 애플리케이션간의 링크에 관한 정보이다. 구체적으로는, 링크처의 애플리케이션의 애플리케이션 ID가 기록된다.
또한, 링크처의 애플리케이션이 없는 경우에는, 기록되지 않는다.
이어서, 도 16을 참조하여, S-TSID의 기록 데이터에 대하여 설명한다.
전술한 바와 같이, S-TSID는, 서비스 단위의 전송 제어 파라미터를 기술한 메타데이터 파일이며, 서비스에 있어서 제공되는 다수의 파일의 파일 단위의 정보인 FDT(파일ㆍ딜리버리ㆍ테이블)를 포함하는 시그널링 데이터이다.
도 16에 나타내는 S-TSID는, 먼저 도 9, 도 10을 참조하여 설명한 3개의 애플리케이션(APP1 내지 APP3)에 대응하는 정보를 기록한 S-TSID의 일부만을 나타내고 있다.
또한, 도 16에는, 애플리케이션 1(APP1)에 속하는 2개의 프리젠테이션ㆍ유닛(PU11, PU12)에 대응하는 정보 기록 영역, 즉,
프리젠테이션ㆍ유닛(PU11) 대응 정보(262),
프리젠테이션ㆍ유닛(PU12) 대응 정보(263),
이들 정보 기록 영역만을 발출하여 나타내고 있다.
도 16에 나타내는 프리젠테이션ㆍ유닛(PU11, PU12)에 대응하는 정보 기록 영역 이하에, PU13, PU21 내지 PU23, PU31 내지 PU33의 정보가 기록된다.
도 16에 나타내는 S-TSID에는, 이하의 각 정보가 기록되어 있다.
프리젠테이션ㆍ유닛(PU)간 링크 정보(261),
프리젠테이션ㆍ유닛(PU11) 대응 정보(262),
프리젠테이션ㆍ유닛(PU12) 대응 정보(263).
프리젠테이션ㆍ유닛(PU)간 링크 정보(261)에는, 링크원의 프리젠테이션ㆍ유닛(PU)의 PUID와, 링크처의 프리젠테이션ㆍ유닛(PU)의 PUID가 기록된다.
또한, PUID는, 먼저 도 8을 참조하여 설명한 바와 같이, 프리젠테이션ㆍ유닛(PU)이 속하는 애플리케이션의 애플리케이션 본체 ID(appId)와, 동일 애플리케이션 내의 프리젠테이션ㆍ유닛을 개별로 식별 가능하게 한 그룹 ID(groupId)에 의해 구성된다.
또한, PUID를 구성하는 그룹 ID(groupId)는, 하나의 애플리케이션에 포함되는 프리젠테이션ㆍ유닛(PU)에 대하여, 예를 들어 1, 2, 3의 연번이 설정되고, 그룹 ID(groupId)=1의 PU가 엔트리 문서를 갖는 PU가 된다.
또한, 그 엔트리 문서를 갖는 최초의 파일(File)이 엔트리 문서로서의 HTML 문서에 상당하는 파일이다.
이 최초의 파일의 파일 단위 정보에, 프리젠테이션ㆍ유닛(PU11) 사이즈 정보가 기록된다.
도 16에 도시한 바와 같이, 프리젠테이션ㆍ유닛(PU11) 대응 정보(262)에는, 프리젠테이션ㆍ유닛(PU11)에 속하는 파일 단위의 정보가 기록된다.
최초의 파일 단위 정보에는, 이하의 각 정보가 기록되어 있다.
파일 엑세스 정보로서의 TOI 정보,
프리젠테이션ㆍ유닛(PU11) 구성 파일의 소속 그룹 정보(271),
프리젠테이션ㆍ유닛(PU11) 사이즈 정보(272).
2번째 이후의 파일 단위 정보에는,
파일 엑세스 정보로서의 TOI 정보,
프리젠테이션ㆍ유닛(PU11) 구성 파일의 소속 그룹 정보,
이들 정보가 기록된다.
또한, 프리젠테이션ㆍ유닛(PU12) 대응 정보(263)에는, 프리젠테이션ㆍ유닛(PU12)에 속하는 파일 단위의 정보가 기록된다.
최초의 파일 단위 정보에는, 이하의 각 정보가 기록되어 있다.
파일 엑세스 정보로서의 TOI 정보,
프리젠테이션ㆍ유닛(PU12) 구성 파일의 소속 그룹 정보(273),
프리젠테이션ㆍ유닛(PU12) 사이즈 정보(274).
이와 같이, S-TSID에는, 프리젠테이션ㆍ유닛(PU)을 구성하는 각 파일 단위의 정보가 기록되고, 이 파일 단위 정보 내에, 프리젠테이션ㆍ유닛의 ID나, 프리젠테이션ㆍ유닛의 사이즈 정보가 기록된다.
S-TSID의 파일 단위의 데이터 기록 영역인 FDT(파일ㆍ딜리버리ㆍ테이블)의 데이터 기록예를 도 17에 나타낸다.
도 17에 도시한 바와 같이, 파일 단위의 데이터 기록 영역인 FDT(파일ㆍ딜리버리ㆍ테이블)에는, 이하의 각 정보가 기록된다.
(a) 파일의 액세스 정보로서의 콘텐츠 로케이션(＠Content-Location)
(b) 송신 장치로부터 송신되는 LCT 패킷의 패킷 헤더에 기록되는 패킷 식별자인 TOI(Transport Object Identifier)
(c) 콘텐츠의 길이, 타입,
또한, 도면에 나타내는 데이터 기록 영역(281)에,
(d) 프리젠테이션ㆍ유닛 ID(PUID)
(e) 프리젠테이션ㆍ유닛(PU) 사이즈
이들 각 데이터가 기록된다.
또한, 도 16을 참조하여 설명한 바와 같이, S-TSID에는, 프리젠테이션ㆍ유닛(PU)간 링크 정보(261)가 기록된다.
이 구체적인 기록예에 대해서, 도 18을 참조하여 설명한다.
프리젠테이션ㆍ유닛(PU)간 링크 정보(261)는
S-TSID 내의 이하의 기록 영역, 즉,
RS/LS/ScFlw/ContentInfo
이하에 기록된다.
도 18은, 콘텐츠 정보(ContentInfo) 내에 기록되는 PU간 링크 정보의 예를 나타내는 도면이다.
예를 들어, 도 18의 데이터 기록 영역(282)에 도시한 바와 같은 설정으로, 프리젠테이션ㆍ유닛(PU)간 링크 정보가 기록된다.
링크원의 프리젠테이션ㆍ유닛 ID(PUID)
링크처의 프리젠테이션ㆍ유닛 ID(PUID)
데이터 기록 영역(282)에는, 이들 2개의 PUID를 기록하는 영역이 설정된다.
이어서, 도 19에 나타내는 흐름도를 참조하여, 수신 장치에 있어서 시그널링 데이터를 참조하여 실행하는 애플리케이션 취득 처리와, 캐시 대상 데이터의 선택 처리 시퀀스에 대하여 설명한다. 즉,
USBD/USD
AIT
S-TSIS
이들 시그널링 데이터를 적용한 애플리케이션 취득 처리와, 캐시 대상 데이터의 선택 처리이다.
또한, 도 19에 나타내는 플로우에 따른 처리는, 수신 장치(30)의 데이터 처리부에 있어서 실행되는 처리이다. 예를 들어, 도 19에 나타내는 처리 시퀀스를 기록한 프로그램에 따라서 실행된다. 또한, 도 19에 나타내는 처리 시퀀스를 실행하는 데이터 처리부는, 예를 들어 도 7에 나타내는 수신 장치(30)에 있어서의 시그널링 해석부(113)나, 캐시 제어부 등의 기능을 실행하는 데이터 처리부이다.
이하, 각 스텝의 처리에 대해서, 순차적으로 설명한다.
(스텝 S51)
수신 장치는, 스텝 S51에 있어서, 송신 장치로부터 송신되는 SLS(서비스 레벨 시그널링)로부터 AIT(애플리케이션ㆍ인포메이션ㆍ테이블)를 취득하여, 배신 애플리케이션에 관한 정보를 취득한다.
즉, 도 15를 참조하여 설명한 AIT(애플리케이션ㆍ인포메이션ㆍ테이블)를 취득하여, 배신 애플리케이션에 관한 정보를 취득한다.
구체적으로는, 예를 들어 애플리케이션 ID, 애플리케이션 사이즈 정보, 애플리케이션간 링크 정보 등을 취득한다.
(스텝 S52)
수신 장치는, 이어서, 스텝 S52에 있어서, 송신 장치로부터 송신되는 시그널링 데이터인 USD(유저ㆍ서비스ㆍ디스크립션)의 딜리버리 메소드(deliveryMethod)와, AIT의 애플리케이션 로케이션(ApplicationLocation)의 기술의 비교에 기초하여, 애플리케이션의 전송 경로(방송파/넷 통신)를 확인한다.
(스텝 S53)
이어서, 수신 장치는, 스텝 S53에 있어서, 송신 장치로부터 송신되는 시그널링 데이터인 AIT로부터 취득한 애플리케이션 사이즈 정보와, 애플리케이션간 링크 정보와, 수신 장치의 캐시 허용 사이즈에 기초하여, 캐시 가능한 데이터 범위를 결정한다.
예를 들어, 먼저 도 10 내지 도 18을 참조하여 설명한 처리에 따라서, 캐시 가능한 애플리케이션 구성 데이터 범위를 확인하여, 캐시 대상 데이터를 결정한다.
(스텝 S54)
이어서, 수신 장치는, 스텝 S54에 있어서, 하나의 애플리케이션 단위의 캐시가 가능한지 여부를 판정한다.
즉, 도 10, 도 11을 참조하여 설명한 캐시 사이즈가, 중 사이즈(Medium) 내지 최대 사이즈(Maximum)에 상당하는 것인지 여부를 판정한다.
스텝 S54에 있어서, 하나의 애플리케이션 단위의 캐시가 가능하다고 판정한 경우에는, 스텝 S55로 진행한다.
한편, 스텝 S54에 있어서, 하나의 애플리케이션 단위의 캐시가 불가능하다고 판정한 경우에는, 스텝 S56으로 진행한다.
(스텝 S55)
스텝 S54에 있어서, 하나의 애플리케이션 단위의 캐시가 가능하다고 판정한 경우에는, 수신 장치는, 스텝 S55에 있어서, AIT에 기술된 애플리케이션 사이즈 정보와, 애플리케이션간 링크 정보와, 수신 장치의 캐시 허용 사이즈에 기초하여 결정한 캐시 가능한 범위의 애플리케이션을 취득하여, 캐시 처리를 실행한다.
이 처리는, 도 10, 도 11을 참조하여 설명한 캐시 사이즈가, 중 사이즈(Medium) 내지 최대 사이즈(Maximum)에 상당하는 경우의 처리에 대응한다.
(스텝 S56)
한편, 스텝 S54에 있어서, 하나의 애플리케이션 단위의 캐시가 불가능하다고 판정한 경우에는, 수신 장치는, 스텝 S56에 있어서, S-TSID의 EFDT/FILE 요소에 기술된 프리젠테이션ㆍ유닛(PU) 사이즈와, 수신 장치의 캐시 허용 사이즈에 기초하여, 결정한 캐시 가능한 범위의 프리젠테이션ㆍ유닛을 취득하여, 캐시 처리를 실행한다.
이 처리는, 도 10, 도 11을 참조하여 설명한 캐시 사이즈가, 최소 사이즈(Minimum) 내지 소 사이즈(Small)에 상당하는 경우의 처리에 대응한다.
[9. 수신 장치의 캐시 사이즈(데이터 저장 허용 사이즈)에 따른 구체적인 처리예에 대해서]
이어서, 도 20 이하를 참조하여, 수신 장치의 캐시 사이즈(데이터 저장 허용 사이즈)에 따른 구체적인 처리예에 대하여 설명한다.
먼저 도 10, 도 11을 참조하여 설명한 이하 5개의 캐시 사이즈에 있어서의 캐시 대상 선택 처리예에 대해서, 순차적으로 설명한다.
(1) 최소 사이즈(Minimum)
(2) 소 사이즈(Small)
(3) 중 사이즈(Medium)
(4) 대 사이즈(Large)
(5) 최대 사이즈(Maximum)
또한, 애플리케이션 사이즈, 프리젠테이션ㆍ유닛(PU) 사이즈에 대해서도, 도 10, 도 11에 나타내는 설정인 것으로 하여 설명한다.
즉, 상기 5개의 캐시 사이즈에 따른 캐시 대상 데이터는, 이하의 설정이 된다.
(1) 최소 사이즈(Minimum)=프리젠테이션ㆍ유닛(PU11)
(2) 소 사이즈(Small)=프리젠테이션ㆍ유닛(PU11)+프리젠테이션ㆍ유닛(PU12)
(3) 중 사이즈(Medium)=애플리케이션(APP1)
(4) 대 사이즈(Large)=애플리케이션(APP1)+애플리케이션(APP2)
(5) 최대 사이즈(Maximum)=애플리케이션(APP1)+애플리케이션(APP2)+애플리케이션(APP3)
이하, 5개의 다른 사이즈의 데이터 저장 허용 캐시 사이즈를 갖는 수신 장치에 있어서의 처리예에 대해서, 순차적으로 설명한다.
또한, 이하에 설명하는 처리예는, 애플리케이션이 방송파를 통해 배신된 경우의 처리예이며, 수신 장치는, 방송파를 통해 애플리케이션을 구성하는 파일을 취득한다.
[9-1. 수신 장치의 데이터 저장 허용 캐시 사이즈가 최소 사이즈(Minimum)이며, 하나의 프리젠테이션ㆍ유닛(PU)만 저장 가능한 경우의 처리예에 대해서]
먼저, 도 20 이하를 참조하여, 수신 장치의 데이터 저장 허용 캐시 사이즈가 최소 사이즈(Minimum)이며, 하나의 프리젠테이션ㆍ유닛(PU)만 저장 가능한 경우의 처리예에 대하여 설명한다.
도 20은, 수신 장치의 데이터 저장 허용 캐시 사이즈가 최소 사이즈(Minimum)인 경우의, 캐시(저장) 대상 데이터를 설명하는 도면이다.
수신 장치는, 하나의 프리젠테이션ㆍ유닛(PU)만 저장 가능하다.
수신 장치가 실행하는 처리는, 애플리케이션(APP1)의 기동 후에 최초로 읽어들여지는 HTML 문서(엔트리 문서(221))와 리소스 파일로 구성되는 프리젠테이션ㆍ유닛(PU11)을 취득하고, 캐시하여 표시하는 처리가 된다.
도 21에는, 수신 장치가 방송파를 통해 애플리케이션을 취득하여, 캐시 처리를 행하고, 실행할 때까지의 처리 시퀀스를 설명하는 흐름도를 나타내고 있다.
또한, 도 22에는, 도 21에 나타내는 흐름도의 각 스텝의 처리 시에 이용되는 시그널링 데이터를 나타내고 있다.
(1) AIT
(2) S-TSID
이들 2개의 시그널링 데이터이다.
도 21에 나타내는 각 스텝 번호(S111 내지 S116)의 처리와, 도 22에 나타내는 동일한 스텝 번호(S111 내지 S116)의 처리는 동일한 처리이다. 도 22에 있어서는, 각 스텝의 처리 시에 참조하는 시그널링 데이터(AIT, S-TSID)의 기록 영역과 각 스텝 번호를 대응지어 나타내고 있다.
도 21 및 도 22를 참조하여, 각 스텝의 처리에 대해서, 순차적으로 설명한다.
(스텝 S111)
수신 장치는, 먼저, 스텝 S111에 있어서, 송신 장치로부터 송신되는 SLS(서비스 레벨 시그널링)로부터 AIT(애플리케이션ㆍ인포메이션ㆍ테이블), S-TSID를 취득한다.
(스텝 S112)
이어서, 수신 장치는, 스텝 S112에 있어서, AIT로부터, 배신 애플리케이션에 관한 정보의 취득, 확인을 행한다. 예를 들어, 이하의 처리를 행한다.
(1) 애플리케이션 로케이션(applicationLocation)으로부터, 엔트리 문서의 URL을 취득한다.
(2) 컨트롤 코드가 캐시 처리의 필요한 코드(AUTOSTART, Prefetch 등)로 설정되어 있음을 확인한다.
(3) 애플리케이션 ID를 취득한다.
(4) 애플리케이션 사이즈를 취득한다.
또한, 취득한 애플리케이션 사이즈와, 수신 장치의 캐시 가능한 캐시 사이즈를 비교한다.
본 예에서는, 캐시 사이즈=최소(Minimum)이며, 애플리케이션 사이즈보다 작아, 애플리케이션 전체의 캐시 처리는 할 수 없다고 판단한다.
(스텝 S113)
이어서, 수신 장치는, 스텝 S113에 있어서, S-TSID로부터, 엔트리 문서의 취득처 정보를 취득한다.
구체적으로는, 도 22의 스텝 S113에 도시한 바와 같이, S-TSID에 기록된 파일 단위의 정보에 기록된 콘텐츠 로케이션 정보(RS/LS/ScFlw/EFDT/content-location)와, AIT의 애플리케이션 로케이션(applicationLocation)이 일치하는 파일(FILE)을 검색하여, 그 취득처 정보를 취득한다.
전술한 바와 같이, S-TSID에는, 프리젠테이션ㆍ유닛(PU)을 구성하는 파일 단위의 정보가 기록되어 있다.
수신 장치는, AIT의 애플리케이션 로케이션(applicationLocation)이 일치하는 파일(FILE)을 검색하여, 그 취득처 정보로서, S-TSID의 파일 단위 정보에 기록된 TOI(Transport Object Identifier)를 취득한다.
TOI(Transport Object Identifier)는, 송신 장치(20)로부터 송신되는 애플리케이션을 저장한 LCT 패킷의 패킷 헤더에 기록되는 패킷 식별자이다.
LCT 패킷의 패킷 헤더에는 패킷의 페이로드에 따른 식별자로서의 TOI가 기록된다.
수신 장치는, S-TSID에 기록된 TOI에 기초하여 방송파에 의해 송신되는 LCT 패킷으로부터 목적으로 하는 애플리케이션에 포함되는 파일을 저장한 LCT 패킷을 선택하여 취득할 수 있다.
(스텝 S114)
이어서, 수신 장치는, 스텝 S114에 있어서, S-TSID로부터, 엔트리 문서를 포함하는 프리젠테이션ㆍ유닛(PU)과, S-TSID에 기록된 링크 정보를 찾아 얻어지는 프리젠테이션ㆍ유닛(PU)의 ID(PUID=애플리케이션 본체 ID+그룹 ID), 또한 각 프리젠테이션ㆍ유닛(PU)의 사이즈 정보(PUSize)를 취득한다.
도 22의 스텝 S114a에 도시한 바와 같이, 프리젠테이션ㆍ유닛 ID(PUID)는, 애플리케이션 본체 ID(appId)와, 그룹 ID(groupId)로 구성되어 있다.
애플리케이션 본체 ID(appId)는, 파일이 속하는 프리젠테이션ㆍ유닛(PU)이 속하는 애플리케이션에 설정된 애플리케이션 ID(조직 ID(orgId)+애플리케이션 본체 ID(appId))의 구성 데이터인 애플리케이션 본체 ID(appId)와 동일값이다.
또한, 도 22의 스텝 S114b에 도시한 바와 같이, 수신 장치는, S-TSID에 기록된 링크 정보를 취득한다.
수신 장치는, 이 링크 정보를 찾아 얻어지는 프리젠테이션ㆍ유닛(PU)의 ID(PUID=애플리케이션 본체 ID+그룹 ID), 또한 각 프리젠테이션ㆍ유닛(PU)의 사이즈 정보(PUSize)를 취득한다.
(스텝 S115)
이어서, 수신 장치는, 스텝 S115에 있어서, 수신 장치의 캐시 사이즈, 즉, 이용 가능한 캐시 사이즈와, 각 프리젠테이션ㆍ유닛(PU)의 데이터 사이즈를 비교하여, 캐시 대상으로 하는 프리젠테이션ㆍ유닛을 선택한다.
또한, 최우선 캐시 대상 PU는, 엔트리 문서를 갖는 프리젠테이션ㆍ유닛(예를 들어, PU11)이다.
그 다음 우선 캐시 대상 PU는, 엔트리 문서를 갖는 PU11의 링크처 PU, 예를 들어 PU12가 된다.
또한, PU12의 링크처 PU13이 다음 캐시 대상 PU로서 선택되고, 링크를 찾아, 순차적으로 캐시 대상 PU가 선택된다.
캐시 사이즈를 초과한 시점에서, 캐시 대상 PU의 선택이 완료된다.
구체적으로는, 예를 들어,
PU11사이즈≤캐시 사이즈<(PU11+PU12) 사이즈
인 경우에는, PU11만을 캐시 대상 PU로서 선택한다.
또한,
(PU11+PU12) 사이즈≤캐시 사이즈<(PU11+PU12+PU13) 사이즈
인 경우에는, PU11과 PU12를 캐시 대상 PU로서 선택한다.
이와 같이, PU의 총계 사이즈가, 캐시 사이즈에 도달할 때까지의 범위 내에서, 캐시 대상 PU를, 링크를 찾아 순차적으로 선택한다.
본 예의 경우에는,
PU11사이즈≤캐시 사이즈<(PU11+PU12) 사이즈
상기 식이 만족되고, PU11만을 캐시 대상 PU로서 선택한다.
(스텝 S116)
이어서, 수신 장치는, 스텝 S116에 있어서, 스텝 S115에서 결정한 캐시 대상의 프리젠테이션ㆍ유닛(PU)의 PUID와 같은 PUID를 갖는 파일을 취득하여, 캐시 처리를 실행하고, 엔트리 문서를 출력(표시)한다.
도 22의 스텝 S116에 도시한 바와 같이, S-TSID에 기록된 파일 단위의 정보로부터, 캐시 대상으로서 선택한 프리젠테이션ㆍ유닛(PU)의 PUID(PU11)와 동일한 PUID(PU11)를 갖는 파일을 선택하여, 이들 파일 단위 정보에 기록된 TOI에 기초하여 방송파로부터 해당 파일을 저장한 패킷을 선택 취득한다. 선택 취득한 파일을 캐시부에 저장(캐시)하는 처리를 실행하여, 그 후, 엔트리 문서로부터의 출력(표시) 처리를 개시한다.
이들 처리에 의해, 애플리케이션(APP1)의 하나의 프리젠테이션ㆍ유닛(PU11)에 속하는 모든 파일을 취득할 수 있다.
따라서, 하나의 프리젠테이션ㆍ유닛(PU)의 전체 구성 파일을 이용한 애플리케이션의 실행이 가능해지고, 프리젠테이션ㆍ유닛 단위의 완전한 형태에서의 데이터 재생이 가능해진다.
즉, 보다 완성도가 높은 애플리케이션 실행 처리가 실현된다.
[9-2. 수신 장치의 데이터 저장 허용 캐시 사이즈가 소 사이즈(Small)이며, 복수의 프리젠테이션ㆍ유닛(PU)이 저장 가능한 경우의 처리예에 대해서]
이어서, 도 23 이하를 참조하여, 수신 장치의 데이터 저장 허용 캐시 사이즈가 소 사이즈(Small)이며, 복수의 프리젠테이션ㆍ유닛(PU)이 저장 가능한 경우의 처리예에 대하여 설명한다.
도 23은, 수신 장치의 데이터 저장 허용 캐시 사이즈가 소 사이즈(Small)인 경우의, 캐시(저장) 대상 데이터를 설명하는 도면이다.
수신 장치는, 2개의 프리젠테이션ㆍ유닛(PU11과 PU12)을 저장 가능하다.
수신 장치가 실행하는 처리는, 애플리케이션(APP1)의 기동 후에 최초로 읽어들여지는 HTML 문서(엔트리 문서(221))와 리소스 파일로 구성되는 프리젠테이션ㆍ유닛(PU11), 또한 프리젠테이션ㆍ유닛(PU11)의 링크처로서 설정되어 있는 프리젠테이션ㆍ유닛(PU12)을 취득하고, 캐시하여 표시하는 처리가 된다.
또한, 프리젠테이션ㆍ유닛(PU11)의 링크처로서 설정되어 있는 프리젠테이션ㆍ유닛이 복수인 경우에는, 그들 복수의 링크처 PU를 취득한다.
도 24에는, 수신 장치가 방송파를 통해 애플리케이션을 취득하여, 캐시 처리를 행하고, 실행할 때까지의 처리 시퀀스를 설명하는 흐름도를 나타내고 있다.
또한, 도 25에는, 도 24에 나타내는 흐름도의 각 스텝의 처리 시에 이용되는 시그널링 데이터를 나타내고 있다.
(1) AIT
(2) S-TSID
이들 2개의 시그널링 데이터이다.
도 24에 나타내는 각 스텝 번호(S121 내지 S126)의 처리와, 도 25에 나타내는 동일한 스텝 번호(S121 내지 S126)의 처리는 동일한 처리이다. 도 25에 있어서는, 각 스텝의 처리 시에 참조하는 시그널링 데이터(AIT, S-TSID)의 기록 영역과 각 스텝 번호를 대응지어 나타내고 있다.
도 24 및 도 25를 참조하여 각 스텝의 처리에 대해서, 순차적으로 설명한다.
(스텝 S121)
수신 장치는, 먼저, 스텝 S121에 있어서, 송신 장치로부터 송신되는 SLS(서비스 레벨 시그널링)로부터 AIT(애플리케이션ㆍ인포메이션ㆍ테이블), S-TSID를 취득한다.
(스텝 S122)
이어서, 수신 장치는, 스텝 S122에 있어서, AIT로부터, 배신 애플리케이션에 관한 정보의 취득, 확인을 행한다. 예를 들어, 이하의 처리를 행한다.
(1) 애플리케이션 로케이션(applicationLocation)으로부터, 엔트리 문서의 URL을 취득한다.
(2) 컨트롤 코드가 캐시 처리의 필요한 코드(AUTOSTART, Prefetch 등)로 설정되어 있음을 확인한다.
(3) 애플리케이션 ID를 취득한다.
(4) 애플리케이션 사이즈를 취득한다.
또한, 취득한 애플리케이션 사이즈와, 수신 장치의 캐시 가능한 캐시 사이즈를 비교한다.
본 예에서는, 캐시 사이즈=소(Small)이며, 애플리케이션 사이즈보다 작아, 애플리케이션 전체의 캐시 처리는 할 수 없다고 판단한다.
(스텝 S123)
이어서, 수신 장치는, 스텝 S123에 있어서, S-TSID로부터, 엔트리 문서의 취득처 정보를 취득한다.
구체적으로는, 도 25의 스텝 S123에 도시한 바와 같이, S-TSID에 기록된 파일 단위의 정보에 기록된 콘텐츠 로케이션 정보(RS/LS/ScFlw/EFDT/content-location)와, AIT의 애플리케이션 로케이션(applicationLocation)이 일치하는 파일(FILE)을 검색하여, 그 취득처 정보를 취득한다.
(스텝 S124)
이어서, 수신 장치는, 스텝 S124에 있어서, S-TSID로부터, 엔트리 문서를 포함하는 프리젠테이션ㆍ유닛(PU)과, S-TSID에 기록된 링크 정보를 찾아 얻어지는 프리젠테이션ㆍ유닛(PU)의 ID(PUID=애플리케이션 본체 ID+그룹 ID), 또한 각 프리젠테이션ㆍ유닛(PU)의 사이즈 정보(PUSize)를 취득한다.
도 25의 스텝 S124a에 도시한 바와 같이, 프리젠테이션ㆍ유닛 ID(PUID)는, 애플리케이션 본체 ID(appId)와, 그룹 ID(groupId)로 구성되어 있다.
애플리케이션 본체 ID(appId)는, 파일이 속하는 프리젠테이션ㆍ유닛(PU)이 속하는 애플리케이션에 설정된 애플리케이션 ID(조직 ID(orgId)+애플리케이션 본체 ID(appId))의 구성 데이터인 애플리케이션 본체 ID(appId)와 동일값이다.
또한, 도 25의 스텝 S124b에 도시한 바와 같이, 수신 장치는, S-TSID에 기록된 링크 정보를 취득한다.
도 25의 스텝 S124c에 도시한 바와 같이, 수신 장치는, 이 링크 정보를 찾아 얻어지는 프리젠테이션ㆍ유닛(PU)의 ID(PUID=애플리케이션 본체 ID+그룹 ID), 또한 각 프리젠테이션ㆍ유닛(PU)의 사이즈 정보(PUSize)를 취득한다.
(스텝 S125)
이어서, 수신 장치는, 스텝 S125에 있어서, 수신 장치의 캐시 사이즈, 즉, 이용 가능한 캐시 사이즈와, 각 프리젠테이션ㆍ유닛(PU)의 데이터 사이즈를 비교하여, 캐시 대상으로 하는 프리젠테이션ㆍ유닛을 선택한다.
또한, 최우선의 캐시 대상 PU는, 엔트리 문서를 갖는 프리젠테이션ㆍ유닛(예를 들어, PU11)이다.
그 다음 우선의 캐시 대상 PU는, 엔트리 문서를 갖는 PU11의 링크처 PU, 예를 들어 PU12가 된다.
또한, PU12의 링크처 PU13이 다음 캐시 대상 PU로서 선택되고, 링크를 찾아, 순차적으로 캐시 대상 PU가 선택된다.
캐시 사이즈를 초과한 시점에서, 캐시 대상 PU의 선택이 완료된다.
구체적으로는, 예를 들어, PU11사이즈≤캐시 사이즈<(PU11+PU12) 사이즈
인 경우에는, PU11만을 캐시 대상 PU로서 선택한다.
또한, (PU11+PU12) 사이즈≤캐시 사이즈<(PU11+PU12+PU13) 사이즈
인 경우에는, PU11과 PU12를 캐시 대상 PU로서 선택한다.
이와 같이, PU의 총계 사이즈가, 캐시 사이즈에 도달할 때까지의 범위 내에서, 캐시 대상 PU를, 링크를 찾아 순차적으로 선택한다.
본 예의 경우에는,
(PU11+PU12) 사이즈≤캐시 사이즈<(PU11+PU12+PU13) 사이즈
가 만족되고, PU11과 PU12를 캐시 대상 PU로서 선택한다.
(스텝 S126)
이어서, 수신 장치는, 스텝 S126에 있어서, 스텝 S125에서 결정한 캐시 대상의 프리젠테이션ㆍ유닛(PU)의 PUID와 동일한 PUID를 갖는 파일을 취득하여, 캐시 처리를 실행하고, 엔트리 문서를 출력(표시)한다.
도 25의 스텝 S126a, S126b에 도시한 바와 같이, 수신 장치는, S-TSID에 기록된 파일 단위의 정보로부터, 캐시 대상 PU의 PUID와 동일한 PUID를 갖는 파일을 선택하여, 이들 파일 단위 정보에 기록된 TOI에 기초하여 방송파로부터 해당 파일을 저장한 패킷을 선택 취득한다. 선택 취득한 파일을 캐시부에 저장(캐시)하는 처리를 실행하여, 그 후, 엔트리 문서로부터의 출력(표시) 처리를 개시한다.
이들 처리에 의해, 애플리케이션(APP1)의 2개의 프리젠테이션ㆍ유닛(PU11, PU12)에 속하는 모든 파일을 취득할 수 있다.
따라서, 2개의 프리젠테이션ㆍ유닛(PU)의 전체 구성 파일을 이용한 애플리케이션의 실행이 가능해지고, 프리젠테이션ㆍ유닛 단위의 완전한 형태에서의 데이터 재생이 가능해진다.
즉, 보다 완성도가 높은 애플리케이션 실행 처리가 실현된다.
[9-3. 수신 장치의 데이터 저장 허용 캐시 사이즈가 중 사이즈(Medium)이며, 하나의 애플리케이션이 저장 가능한 경우의 처리예에 대해서]
이어서, 도 26 이하를 참조하여, 수신 장치의 데이터 저장 허용 캐시 사이즈가 중 사이즈(Medium)이며, 하나의 애플리케이션(App1)이 저장 가능한 경우의 처리예에 대하여 설명한다.
도 26은, 수신 장치의 데이터 저장 허용 캐시 사이즈가 중 사이즈(Medium)인 경우의, 캐시(저장) 대상 데이터를 설명하는 도면이다.
수신 장치는, 하나의 애플리케이션(APP1)을 저장 가능하다.
수신 장치가 실행하는 처리는, 애플리케이션(APP1)의 기동 후에 최초로 읽어들여지는 HTML 문서(엔트리 문서(221))와 리소스 파일로 구성되는 프리젠테이션ㆍ유닛(PU11)이 속하는 애플리케이션(APP1)의 구성 파일 모두를 취득하고, 캐시하여 표시하는 처리가 된다.
도 27에는, 수신 장치가 방송파를 통해 애플리케이션을 취득하여, 캐시 처리를 행하고, 실행할 때까지의 처리 시퀀스를 설명하는 흐름도를 나타내고 있다.
또한, 도 28에는, 도 27에 나타내는 흐름도의 각 스텝의 처리 시에 이용되는 시그널링 데이터를 나타내고 있다.
(1) AIT
(2) S-TSID
이들 2개의 시그널링 데이터이다.
도 27에 나타내는 각 스텝 번호(S131 내지 S135)의 처리와, 도 28에 나타내는 동일한 스텝 번호(S131 내지 S135)의 처리는 동일한 처리이다. 도 28에 있어서는, 각 스텝의 처리 시에 참조하는 시그널링 데이터(AIT, S-TSID)의 기록 영역과 각 스텝 번호를 대응지어 나타내고 있다.
도 27 및 도 28을 참조하여 각 스텝의 처리에 대해서, 순차적으로 설명한다.
(스텝 S131)
수신 장치는, 먼저, 스텝 S131에 있어서, 송신 장치로부터 송신되는 SLS(서비스 레벨 시그널링)로부터 AIT(애플리케이션ㆍ인포메이션ㆍ테이블), S-TSID를 취득한다.
(스텝 S132)
이어서, 수신 장치는, 스텝 S132에 있어서, AIT로부터, 배신 애플리케이션에 관한 정보의 취득, 확인을 행한다. 예를 들어, 이하의 처리를 행한다.
(1) 애플리케이션 로케이션(applicationLocation)으로부터, 엔트리 문서의 URL을 취득한다.
(2) 컨트롤 코드가 캐시 처리의 필요한 코드(AUTOSTART, Prefetch 등)로 설정되어 있음을 확인한다.
(3) 애플리케이션 ID를 취득한다.
(4) 애플리케이션 사이즈를 취득한다.
(5) 링크처 애플리케이션을 취득한다.
(6) 링크처 애플리케이션 사이즈를 취득한다.
또한, 취득한 애플리케이션 사이즈와, 수신 장치의 캐시 가능한 캐시 사이즈를 비교한다.
본 예에서는, 캐시 사이즈=중(Medium)이며, 애플리케이션(APP1)의 애플리케이션 사이즈보다 커서, 애플리케이션(APP1) 전체의 캐시 처리를 할 수 있다고 판단한다.
또한, 애플리케이션 사이즈에 링크처 애플리케이션 사이즈를 가산한 데이터 사이즈와, 수신 장치의 캐시 가능한 캐시 사이즈를 비교한다.
본 예에서는, 캐시 사이즈=중(Medium)이며, 이 캐시 사이즈는, 2개의 애플리케이션(APP1, APP2)의 애플리케이션 합계 사이즈보다 작아, 2개의 애플리케이션(APP1, APP2) 전체의 캐시 처리는 할 수 없다고 판단한다.
즉, 하나의 애플리케이션(APP1)의 캐시 처리를 실행하는 것으로 결정한다.
(스텝 S133)
이어서, 수신 장치는, 스텝 S133에 있어서, S-TSID로부터, 엔트리 문서의 취득처 정보를 취득한다.
구체적으로는, 도 28의 스텝 S133에 도시한 바와 같이, S-TSID에 기록된 파일 단위의 정보에 기록된 콘텐츠 로케이션 정보(RS/LS/ScFlw/EFDT/content-location)와, AIT의 애플리케이션 로케이션(applicationLocation)이 일치하는 파일(FILE)을 검색하여, 그 취득처 정보를 취득한다.
(스텝 S134)
이어서, 수신 장치는, 스텝 S134에 있어서, 엔트리 문서의 그룹(Group) 요소에 기술된 프리젠테이션ㆍ유닛 ID(PUID)로부터, 애플리케이션 본체 ID(appId)와, 그룹 ID(groupId)를 취득한다.
도 28의 스텝 S134에 도시한 바와 같이, 프리젠테이션ㆍ유닛 ID(PUID)는, 애플리케이션 본체 ID(appId)와, 그룹 ID(groupId)로 구성되어 있다.
애플리케이션 본체 ID(appId)는, 파일이 속하는 프리젠테이션ㆍ유닛(PU)이 속하는 애플리케이션에 설정된 애플리케이션 ID(조직 ID(orgId)+애플리케이션 본체 ID(appId))의 구성 데이터인 애플리케이션 본체 ID(appId)와 동일값이다.
(스텝 S135)
이어서, 수신 장치는, 스텝 S135에 있어서, 엔트리 문서의 PUID(애플리케이션 본체 ID(appId)+그룹 ID(groupId)) 중의 애플리케이션 본체 ID(appId)와 같은 애플리케이션 본체 ID(appId)를 갖는 파일을 취득하여, 캐시 처리를 실행하고, 출력(표시)한다.
도 28의 스텝 S135에 도시한 바와 같이, S-TSID에 기록된 파일 단위의 정보로부터, 엔트리 문서의 PUID를 구성하는 애플리케이션 본체 ID(appId)와 같은 애플리케이션 본체 ID(appId)를 갖는 파일을 취득하여, 캐시 처리를 실행하고, 출력(표시)한다.
이들 처리에 의해, 애플리케이션(APP1)에 속하는 모든 프리젠테이션ㆍ유닛(PU11, PU12, PU13)에 속하는 모든 파일을 취득할 수 있다.
따라서, 애플리케이션(APP1)에 속하는 모든 프리젠테이션ㆍ유닛(PU11, PU12, PU13)의 전체 구성 파일을 이용한 애플리케이션의 실행이 가능해지고, 애플리케이션 단위 및 프리젠테이션ㆍ유닛 단위의 완전한 형태에서의 데이터 재생이 가능해진다.
즉, 보다 완성도가 높은 애플리케이션 실행 처리가 실현된다.
[9-4. 수신 장치의 데이터 저장 허용 캐시 사이즈가 대 사이즈(Large)이며, 복수의 애플리케이션이 저장 가능한 경우의 처리예에 대해서]
이어서, 도 29 이하를 참조하여, 수신 장치의 데이터 저장 허용 캐시 사이즈가 대 사이즈(Large)이며, 복수의 애플리케이션(APP1, APP2)이 저장 가능한 경우의 처리예에 대하여 설명한다.
도 29는, 수신 장치의 데이터 저장 허용 캐시 사이즈가 대 사이즈(Large)인 경우의, 캐시(저장) 대상 데이터를 설명하는 도면이다.
수신 장치는, 2개의 애플리케이션(APP1, APP2)을 저장 가능하다.
수신 장치가 실행하는 처리는, 애플리케이션(APP1)의 기동 후에 최초로 읽어들여지는 HTML 문서(엔트리 문서(221))와 리소스 파일로 구성되는 프리젠테이션ㆍ유닛(PU11)이 속하는 애플리케이션(APP1)의 구성 파일, 또한 애플리케이션(APP1)의 링크처 애플리케이션인 애플리케이션(APP2)의 구성 파일 모두를 취득하고, 캐시하여 표시하는 처리가 된다.
도 30에는, 수신 장치가 방송파를 통해 애플리케이션을 취득하여, 캐시 처리를 행하고, 실행할 때까지의 처리 시퀀스를 설명하는 흐름도를 나타내고 있다.
또한, 도 31에는, 도 30에 나타내는 흐름도의 각 스텝의 처리 시에 이용되는 시그널링 데이터를 나타내고 있다.
(1) AIT
(2) S-TSID
이들 2개의 시그널링 데이터이다.
도 30에 나타내는 각 스텝 번호(S141 내지 S145)의 처리와, 도 31에 나타내는 동일한 스텝 번호(S141 내지 S145)의 처리는 동일한 처리이다. 도 31에 있어서는, 각 스텝의 처리 시에 참조하는 시그널링 데이터(AIT, S-TSID)의 기록 영역과 각 스텝 번호를 대응지어 나타내고 있다.
도 30 및 도 31을 참조하여 각 스텝의 처리에 대해서, 순차적으로 설명한다.
(스텝 S141)
수신 장치는, 먼저, 스텝 S141에 있어서, 송신 장치로부터 송신되는 SLS(서비스 레벨 시그널링)로부터 AIT(애플리케이션ㆍ인포메이션ㆍ테이블), S-TSID를 취득한다.
(스텝 S142)
이어서, 수신 장치는, 스텝 S142에 있어서, AIT로부터, 배신 애플리케이션에 관한 정보의 취득, 확인을 행한다. 예를 들어, 이하의 처리를 행한다.
(1) 애플리케이션 로케이션(applicationLocation)으로부터, 엔트리 문서의 URL을 취득한다.
(2) 컨트롤 코드가 캐시 처리의 필요한 코드(AUTOSTART, Prefetch 등)로 설정되어 있음을 확인한다.
(3) 애플리케이션 ID를 취득한다.
(4) 애플리케이션 사이즈를 취득한다.
(5) 링크처 애플리케이션을 취득한다.
(6) 링크처 애플리케이션 사이즈를 취득한다.
또한, 취득한 애플리케이션 사이즈와, 수신 장치의 캐시 가능한 캐시 사이즈를 비교한다.
본 예에서는, 캐시 사이즈=대(Large)이며, 애플리케이션(APP1)의 애플리케이션 사이즈보다 커서, 애플리케이션(APP1) 전체의 캐시 처리를 할 수 있다고 판단한다.
또한, 애플리케이션 사이즈에 링크처 애플리케이션 사이즈를 가산한 데이터 사이즈와, 수신 장치의 캐시 가능한 캐시 사이즈를 비교한다.
본 예에서는, 캐시 사이즈=대(Large)이며, 이 캐시 사이즈는, 2개의 애플리케이션(APP1, APP2)의 애플리케이션 합계 사이즈보다 커서, 2개의 애플리케이션(APP1, APP2) 전체의 캐시 처리를 할 수 있다고 판단한다.
또한, 링크처 애플리케이션(APP2)의 링크처 애플리케이션(APP3)의 사이즈를 취득하여, 3개의 애플리케이션의 총계 데이터 사이즈와, 캐시 사이즈와 비교한다.
본 예에서는, 캐시 사이즈는 3개의 애플리케이션의 총계 데이터 사이즈보다 작아, 3개의 애플리케이션 모든 저장(캐시)은 할 수 없다고 판단한다.
결과적으로, 2개의 애플리케이션(APP1, APP2)의 캐시 처리를 실행하는 것으로 결정한다.
(스텝 S143)
이어서, 수신 장치는, 스텝 S143에 있어서, S-TSID로부터, 초기 실행 애플리케이션(APP1)의 엔트리 문서의 취득처 정보를 취득한다.
구체적으로는, 도 31의 스텝 S143에 도시한 바와 같이, S-TSID에 기록된 파일 단위의 정보에 기록된 콘텐츠 로케이션 정보(RS/LS/ScFlw/EFDT/content-location)와, AIT의 애플리케이션 로케이션(applicationLocation)이 일치하는 파일(FILE)을 검색하여, 그 취득처 정보를 취득한다.
또한, 본 예에서는, AIT에 기록된 2개의 애플리케이션 로케이션(applicationLocation)이 일치하는 파일(FILE)을 검색하여, 그 취득처 정보를 취득한다.
(스텝 S144)
이어서, 수신 장치는, 스텝 S144에 있어서, 2개의 애플리케이션 각각의 엔트리 문서의 그룹(Group) 요소에 기술된 프리젠테이션ㆍ유닛 ID(PUID)로부터, 애플리케이션 본체 ID(appId)와, 그룹 ID(groupId)를 취득한다.
도 31의 스텝 S144에 도시한 바와 같이, 프리젠테이션ㆍ유닛 ID(PUID)는, 애플리케이션 본체 ID(appId)와, 그룹 ID(groupId)로 구성되어 있다.
애플리케이션 본체 ID(appId)는, 파일이 속하는 프리젠테이션ㆍ유닛(PU)이 속하는 애플리케이션에 설정된 애플리케이션 ID(조직 ID(orgId)+애플리케이션 본체 ID(appId))의 구성 데이터인 애플리케이션 본체 ID(appId)와 동일값이다.
본 예에서는, 도 31의 스텝 S144a, S144b에 도시한 바와 같이, 링크원과 링크처의 2개의 애플리케이션 ID(appId1, appId2)를 취득한다.
(스텝 S145)
이어서, 수신 장치는, 스텝 S145에 있어서, 엔트리 문서의 PUID(애플리케이션 본체 ID(appId)+그룹 ID(groupId)) 중의 애플리케이션 본체 ID(appId)와 같은 애플리케이션 본체 ID(appId)를 갖는 파일을 취득하여, 캐시 처리를 실행한다.
본 예에서는, 2개의 애플리케이션 ID(appId1, appId2)를 갖는 파일을 취득하여, 캐시 처리를 실행하고, 애플리케이션 1(APP1)의 엔트리 문서를 사용하여 애플리케이션의 실행을 개시한다.
도 31의 스텝 S145에 도시한 바와 같이, S-TSID에 기록된 파일 단위의 정보로부터, 엔트리 문서의 PUID(PUId11, PUId21)를 구성하는 애플리케이션 본체 ID(appId1, appId2)와 같은 애플리케이션 본체 ID(appId1, appId2)를 갖는 파일을 취득하여, 캐시 처리를 실행하고, 출력(표시)한다.
이들 처리에 의해, 애플리케이션(APP1)과, 링크처의 애플리케이션(APP2)에 속하는 모든 프리젠테이션ㆍ유닛(PU11, PU12, PU13, PU21, PU22, PU23)에 속하는 모든 파일을 취득할 수 있다.
이에 의해, 애플리케이션(APP1)에 속하는 모든 프리젠테이션ㆍ유닛(PU11, PU12, PU13)의 전체 구성 파일을 이용한 애플리케이션의 실행, 또한 애플리케이션(APP2)에 속하는 모든 프리젠테이션ㆍ유닛(PU21, PU22, PU23)의 전체 구성 파일을 이용한 애플리케이션의 실행이 가능해진다.
즉, 애플리케이션 단위 및 프리젠테이션ㆍ유닛 단위의 완전한 형태에서의 데이터 재생이 가능해진다.
즉, 보다 완성도가 높은 애플리케이션 실행 처리가 실현된다.
[9-5. 수신 장치의 데이터 저장 허용 캐시 사이즈가 최대 사이즈(Maximum)이며, 복수의 애플리케이션이 저장 가능한 경우의 처리예에 대해서]
이어서, 도 32 이하를 참조하여, 수신 장치의 데이터 저장 허용 캐시 사이즈가 최대 사이즈(Maximum)이며, 링크 관계가 설정된 3개 모든 애플리케이션(APP1, APP2, APP3)이 저장 가능한 경우의 처리예에 대하여 설명한다.
도 32는, 수신 장치의 데이터 저장 허용 캐시 사이즈가 최대 사이즈(Maximum)인 경우의, 캐시(저장) 대상 데이터를 설명하는 도면이다.
수신 장치는, 링크 관계가 설정된 3개 모든 애플리케이션(APP1, APP2, APP3)을 저장 가능하다.
수신 장치가 실행하는 처리는, 애플리케이션(APP1)의 기동 후에 최초로 읽어들여지는 HTML 문서(엔트리 문서(221))와 리소스 파일로 구성되는 프리젠테이션ㆍ유닛(PU11)이 속하는 애플리케이션(APP1)의 구성 파일, 또한 애플리케이션(APP1)의 링크처 애플리케이션인 애플리케이션(APP2), 또한 애플리케이션(APP2)의 링크처 애플리케이션인 애플리케이션(APP3)의 구성 파일 모두를 취득하고, 캐시하여 표시하는 처리가 된다.
도 33에는, 수신 장치가 방송파를 통해 애플리케이션을 취득하여, 캐시 처리를 행하고, 실행할 때까지의 처리 시퀀스를 설명하는 흐름도를 나타내고 있다.
또한, 도 34에는, 도 33에 나타내는 흐름도의 각 스텝의 처리 시에 이용되는 시그널링 데이터를 나타내고 있다.
(1) AIT
(2) S-TSID
이들 2개의 시그널링 데이터이다.
도 33에 나타내는 각 스텝 번호(S151 내지 S155)의 처리와, 도 34에 나타내는 동일한 스텝 번호(S151 내지 S155)의 처리는 동일한 처리이다. 도 34에 있어서는, 각 스텝의 처리 시에 참조하는 시그널링 데이터(AIT, S-TSID)의 기록 영역과 각 스텝 번호를 대응지어 나타내고 있다.
도 33 및 도 34를 참조하여 각 스텝의 처리에 대해서, 순차적으로 설명한다.
(스텝 S151)
수신 장치는, 먼저, 스텝 S151에 있어서, 송신 장치로부터 송신되는 SLS(서비스 레벨 시그널링)로부터 AIT(애플리케이션ㆍ인포메이션ㆍ테이블), S-TSID를 취득한다.
(스텝 S152)
이어서, 수신 장치는, 스텝 S152에 있어서, AIT로부터, 배신 애플리케이션에 관한 정보의 취득, 확인을 행한다. 예를 들어, 이하의 처리를 행한다.
(1) 애플리케이션 로케이션(applicationLocation)으로부터, 엔트리 문서의 URL을 취득한다.
(2) 컨트롤 코드가 캐시 처리의 필요한 코드(AUTOSTART, Prefetch 등)로 설정되어 있음을 확인한다.
(3) 애플리케이션 ID를 취득한다.
(4) 애플리케이션 사이즈를 취득한다.
(5) 링크처 애플리케이션을 취득한다.
(6) 링크처 애플리케이션 사이즈를 취득한다.
또한, 취득한 애플리케이션 사이즈와, 수신 장치의 캐시 가능한 캐시 사이즈를 비교한다.
본 예에서는, 캐시 사이즈=최대(Maximum)이며, 애플리케이션(APP1)의 애플리케이션 사이즈보다 커서, 애플리케이션(APP1) 전체의 캐시 처리를 할 수 있다고 판단한다.
또한, 애플리케이션 사이즈에 링크처 애플리케이션(APP2)의 사이즈를 가산한 데이터 사이즈와, 수신 장치의 캐시 가능한 캐시 사이즈를 비교한다.
본 예에서는, 캐시 사이즈=최대(Maximum)이며, 이 캐시 사이즈는, 2개의 애플리케이션(APP1, APP2)의 애플리케이션 합계 사이즈보다 커서, 2개의 애플리케이션(APP1, APP2) 전체의 캐시 처리를 할 수 있다고 판단한다.
또한, 링크처 애플리케이션(APP2)의 링크처 애플리케이션(APP3)의 사이즈를 취득하여, 3개의 애플리케이션의 총계 데이터 사이즈와, 캐시 사이즈를 비교한다.
본 예에서는, 캐시 사이즈는 3개의 애플리케이션의 총계 데이터 사이즈보다 커서, 3개의 애플리케이션 모든 저장(캐시)이 가능하다고 판단한다.
결과적으로, 링크 관계에 있는 3개 모든 애플리케이션(APP1, APP2, APP3)의 캐시 처리를 실행하는 것으로 결정한다.
(스텝 S153)
이어서, 수신 장치는, 스텝 S153에 있어서, S-TSID로부터, 엔트리 문서의 취득처 정보를 취득한다.
구체적으로는, 도 34의 스텝 S153에 도시한 바와 같이, S-TSID에 기록된 파일 단위의 정보에 기록된 콘텐츠 로케이션 정보(RS/LS/ScFlw/EFDT/content-location)와, AIT의 애플리케이션 로케이션(applicationLocation)이 일치하는 파일(FILE)을 검색하여, 그 취득처 정보를 취득한다.
또한, 본 예에서는, AIT에 기록된 3개의 애플리케이션 로케이션(applicationLocation)이 일치하는 파일(FILE)을 검색하여, 그 취득처 정보를 취득한다.
(스텝 S154)
이어서, 수신 장치는, 스텝 S154에 있어서, 3개의 애플리케이션 각각의 엔트리 문서의 그룹(Group) 요소에 기술된 프리젠테이션ㆍ유닛 ID(PUID)로부터, 애플리케이션 본체 ID(appId)와, 그룹 ID(groupId)를 취득한다.
도 34의 스텝 S154에 도시한 바와 같이, 프리젠테이션ㆍ유닛 ID(PUID)는, 애플리케이션 본체 ID(appId)와, 그룹 ID(groupId)로 구성되어 있다.
애플리케이션 본체 ID(appId)는, 파일이 속하는 프리젠테이션ㆍ유닛(PU)이 속하는 애플리케이션에 설정된 애플리케이션 ID(조직 ID(orgId)+애플리케이션 본체 ID(appId))의 구성 데이터인 애플리케이션 본체 ID(appId)와 동일값이다.
본 예에서는, 도 34의 스텝 S154a, S154b, S154c에 도시한 바와 같이, 링크 관계에 있는 3개의 애플리케이션 ID(appId1, appId2, appId3)를 취득한다.
(스텝 S155)
이어서, 수신 장치는, 스텝 S155에 있어서, 엔트리 문서의 PUID(애플리케이션 본체 ID(appId)+그룹 ID(groupId)) 중의 애플리케이션 본체 ID(appId)와 같은 애플리케이션 본체 ID(appId)를 갖는 파일을 취득하여, 캐시 처리를 실행한다.
본 예에서는, 3개의 애플리케이션 ID(appId1, appId2, appId3)를 갖는 파일을 취득하여, 캐시 처리를 실행하고, 애플리케이션 1(APP1)의 엔트리 문서를 사용하여 애플리케이션의 실행을 개시한다.
도 34의 스텝 S155에 도시한 바와 같이, S-TSID에 기록된 파일 단위의 정보로부터, 엔트리 문서의 PUID(PUId11, PUId21, PUId31)를 구성하는 애플리케이션 본체 ID(appId1, appId2, appId3)와 같은 애플리케이션 본체 ID(appId1, appId2, appId3)를 갖는 파일을 취득하여, 캐시 처리를 실행하고, 출력(표시)한다.
이들 처리에 의해, 링크 관계가 설정된 애플리케이션(APP1)과, 애플리케이션(APP2) 및 애플리케이션(APP3)에 속하는 모든 프리젠테이션ㆍ유닛(PU11, PU12, PU13, PU21, PU22, PU23, PU31, PU32)에 속하는 모든 파일을 취득할 수 있다.
이에 의해, 3개의 애플리케이션(APP1 내지 APP3)에 속하는 모든 프리젠테이션ㆍ유닛(PU11 내지 PU32)의 전체 구성 파일을 이용한 애플리케이션의 실행이 가능해진다.
즉, 애플리케이션 단위 및 프리젠테이션ㆍ유닛 단위의 완전한 형태에서의 데이터 재생이 가능해진다.
즉, 보다 완성도가 높은 애플리케이션 실행 처리가 실현된다.
[10. 수신 장치에 있어서의 데이터 처리의 전체 시퀀스에 대해서]
이어서, 도 35 이하에 나타내는 흐름도를 참조하여, 수신 장치가 실행하는 주요한 처리의 시퀀스에 대하여 설명한다.
도 35 이하에 나타내는 흐름도는, 수신 장치에 있어서 실행하는, 예를 들어 이하의 처리를 중심으로 하여 설명하는 흐름도이다.
(1) 방송 스트림의 수신 처리,
(2) 애플리케이션 구성 파일의 캐시 처리,
(3) 애플리케이션의 실행 및 애플리케이션간의 천이 처리
[10-1. 수신 장치에 있어서의 방송 스트림 수신 처리의 전체 시퀀스]
먼저, 도 35에 나타내는 플로우를 참조하여 수신 장치가 실행하는 방송 스트림의 수신 처리의 전체 시퀀스에 대하여 설명한다. 각 스텝의 처리에 대하여 설명한다.
(스텝 S201)
스텝 S201은, 수신 장치에 있어서 실행하는 선국 처리이다.
이것은, 수신 장치측의 유저에 의한 수신 채널(예를 들어 방송국) 선택 처리이다.
(스텝 S202)
스텝 S201에 있어서, 하나의 수신 채널이 선택되면, 스텝 S202에 있어서, 수신 장치는, 선택 채널에 따른 방송 스트림의 수신 처리를 실행한다.
이 처리의 상세에 대해서는, 도 36 이하의 플로우를 참조하여 후단에서 설명한다.
(스텝 S203)
스텝 S203은, 방송 스트림의 수신 종료의 판정 처리 스텝이다. 예를 들어 유저에 의한 수신 장치의 전원 오프 등의 처리를 트리거로 하여 스텝 S202의 방송 스트림 수신 처리를 종료한다.
방송 스트림의 수신 종료가 이루어지지 않은 경우에는, 스텝 S202의 방송 스트림의 수신 처리를 계속해서 실행한다.
[10-2. 수신 장치에 있어서의 방송 스트림 수신 처리의 상세 시퀀스]
이어서, 도 36에 나타내는 플로우를 참조하여 수신 장치가 실행하는 방송 스트림의 수신 처리의 상세 시퀀스에 대하여 설명한다. 각 스텝의 처리에 대하여 설명한다.
(스텝 S251)
수신 장치는, 방송 스트림의 수신 처리를 개시하면, 송신 장치로부터의 송신 패킷의 수신 처리를 개시한다.
또한, 수신 장치에 있어서 선택된 채널에 따라서 선택된 채널 대응의 데이터 저장 패킷을 선택하여 취득한다.
또한, 송신 장치가 송신하는 데이터는, 먼저 도 2 참조하여 설명한 바와 같이,
AV 세그먼트,
시그널링 데이터,
애플리케이션 등을 포함하는 NRT 데이터 등,
이들 각종 데이터가 있다.
또한, 시그널링 데이터에는, 먼저 설명한 USBD/USD, AIT, S-TSID 등, 여러 종류의 시그널링 데이터가 포함된다.
(스텝 S252)
수신 장치는, 수신 패킷의 패킷 헤더 정보 등을 참조하여, 수신 데이터가,
비디오, 음성, 자막 데이터 등의 AV 세그먼트인지,
애플리케이션 등의 NRT 데이터인지,
시그널링 데이터인지,
이들 중 어느 것인지를 판정한다.
수신 패킷이, 비디오, 음성, 자막 데이터 등의 AV 세그먼트를 저장한 패킷인 경우에는, 스텝 S253으로 진행한다.
수신 패킷이, 애플리케이션 등의 NRT 데이터를 저장한 패킷인 경우에는, 스텝 S254로 진행한다.
수신 패킷이, USBD/USD, AIT, S-TSID 등의 시그널링 데이터를 저장한 패킷인 경우에는, 스텝 S255로 진행한다.
(스텝 S253)
수신 패킷이, 비디오, 음성, 자막 데이터 등의 AV 세그먼트를 저장한 패킷인 경우에는, 스텝 S253에 있어서, 수신 패킷으로부터, 비디오, 음성, 자막 데이터 등을 취출하고, 소정의 복호 처리를 실행하여, 렌더링, 즉, 재생 출력 처리를 실행한다.
이 처리는, 예를 들어 방송 프로그램의 재생 출력 처리이다.
(스텝 S254)
수신 패킷이, 애플리케이션 등의 NRT 데이터를 저장한 패킷인 경우에는, 스텝 S254에 있어서, 시그널링 데이터에 기초하여 NRT 데이터를 수신하고, 축적하는 처리를 행한다.
또한, NRT 데이터가 애플리케이션인 경우에는, 먼저 설명한 바와 같이, USBD/USD, AIT, S-TSID 등의 시그널링 데이터의 기록 정보에 따라서, 저장(캐시) 데이터의 선택 처리를 수반하는 처리를 실행한다.
즉, 애플리케이션의 저장(캐시) 처리에 선행하여 애플리케이션 대응의 시그널링 데이터의 취득이 실행되고, 선행 취득한 시그널링 데이터의 기술에 따라서 애플리케이션의 선택적 취득, 캐시 처리가 실행되게 된다.
(스텝 S255)
수신 패킷이, USBD/USD, AIT, S-TSID 등의 시그널링 데이터를 저장한 패킷인 경우에는, 스텝 S255로 진행한다.
스텝 S255에서는, 시그널링 데이터의 수신, 해석 처리를 실행한다.
이 처리의 상세에 대해서는, 도 37의 플로우를 참조하여 후단에서 설명한다.
(스텝 S256)
스텝 S256에 있어서, 스텝 S255에 있어서의 시그널링 데이터의 해석 결과에 기초하여, 애플리케이션의 취득 처리가 필요한지 여부를 판정한다.
구체적으로는, 수신 장치가 애플리케이션의 취득 처리를 실행하는 설정으로 되어 있는지, 즉, 애플리케이션 취득 처리 플래그가 True로 설정되어 있는지 여부를 판정하는 처리를 행한다.
또한, 이 플래그 설정은, 스텝 S255에 있어서 시그널링 데이터로서 AIT를 수신한 경우에 설정된다. 상세에 대해서는, 후단에 있어서 도 37에 나타내는 플로우를 참조하여 설명한다.
플래그 설정이 애플리케이션 취득 처리를 실행하는 설정으로 되어 있는 경우에는, 스텝 S257로 진행한다.
애플리케이션의 취득을 행하는 설정이 아니라고 판정한 경우에는, 스텝 S202의 방송 스트림 수신 처리의 개시 위치로 복귀되고, 다음 패킷의 수신 처리, 즉, 스텝 S251 이하의 처리를 실행한다.
(스텝 S257)
스텝 S256에 있어서, 스텝 S255에 있어서의 시그널링 데이터의 해석 결과에 기초하여, 애플리케이션의 취득 처리가 필요하다고 판정한 경우에는, 스텝 S257로 진행하고, 애플리케이션의 취득 처리를 실행한다.
이 처리는, 먼저 설명한 USBD/USD, AIT, S-TSID 등의 시그널링 데이터의 기록 정보에 따른 애플리케이션의 취득 처리이며, 캐시 대상 데이터를 자장치의 캐시 용량에 따라서 선택하는 처리를 수반하는 처리이다.
이 처리에 대해서는, 도 38에 나타내는 플로우를 참조하여 후단에서 상세하게 설명한다.
[10-3. 수신 장치에 있어서의 시그널링의 수신, 해석 처리의 상세 시퀀스]
이어서, 도 37에 나타내는 플로우를 참조하여, 도 36의 스텝 S255에 있어서 실행하는 시그널링 데이터의 수신, 해석 처리의 상세 시퀀스에 대하여 설명한다.
이하, 각 스텝의 처리에 대하여 설명한다.
(스텝 S281)
먼저, 수신 장치는, 스텝 S281에 있어서, 수신한 시그널링 데이터가, 취득 대상이 되는 시그널링 데이터인지 여부를 판정한다.
미취득의 시그널링 데이터나, 취득 완료라도 취득 완료 시그널링 데이터보다 새로운 버전의 갱신된 시그널링 데이터를 수신한 경우 등에는, 취득 대상의 시그널링 데이터라고 판정하여 스텝 S282로 진행한다.
(스텝 S282)
스텝 S282에 있어서, 수신 장치는, 시그널링 데이터를 취득한다.
또한, 먼저 설명한 바와 같이, 시그널링 데이터에는, 여러 종류가 있다.
예를 들어, USBD/USD, AIT, S-TSID 등의 시그널링 데이터, 또한 AV 스트림 대응의 시그널링 데이터인 MPD 등, 여러 종류의 시그널링 데이터가 있다.
(스텝 S283)
이어서, 수신 장치는, 스텝 S283에 있어서, 수신한 시그널링 데이터가, 애플리케이션에 대응하는 제어 정보 등을 기록한 AIT(애플리케이션ㆍ인포메이션ㆍ테이블)인지 여부를 판정한다.
AIT인 경우에는, 스텝 S284로 진행한다.
AIT 이외의 시그널링 데이터인 경우에는, 스텝 S285로 진행한다.
(스텝 S284)
스텝 S283에 있어서, 수신한 시그널링 데이터가, 애플리케이션에 대응하는 제어 정보 등을 기록한 AIT(애플리케이션ㆍ인포메이션ㆍ테이블)라고 판정한 경우, 수신 장치는, 스텝 S284에 있어서, 애플리케이션의 취득 처리를 실행하는 설정, 즉, 애플리케이션 취득 처리 플래그를 True로 하는 처리를 행한다.
(스텝 S285)
한편, 스텝 S283에 있어서, 수신한 시그널링 데이터가, 애플리케이션에 대응하는 제어 정보 등을 기록한 AIT(애플리케이션ㆍ인포메이션ㆍ테이블)가 아니라, 그 밖의 시그널링 데이터라고 판정한 경우, 수신 장치는, 스텝 S285로 진행하고, 수신한 AIT 이외의 시그널링 데이터의 해석, 및 수신 시그널링 데이터에 따른 처리를 실행한다.
[10-4. 수신 장치에 있어서의 애플리케이션의 취득, 실행 처리의 상세 시퀀스]
이어서, 도 38에 나타내는 플로우를 참조하여, 도 36의 스텝 S257에 있어서 실행하는 애플리케이션의 취득, 실행 처리의 상세 시퀀스에 대하여 설명한다.
이하, 각 스텝의 처리에 대하여 설명한다.
(스텝 S301)
먼저, 수신 장치는, 스텝 S301에 있어서, 취득한 AIT로부터, 애플리케이션에 대한 처리 형태를 규정한 컨트롤 코드(ctrlCode) 정보를 취득하여, 컨트롤 코드가 애플리케이션의 캐시 처리를 필요로 하는 코드 인지 여부를 판정한다.
캐시 처리가 필요한 코드는, 예를 들어 애플리케이션의 즉시 실행을 지정한 코드인 (AUTOSTART), 또는 애플리케이션을 사전 취득하고, 그 후, 소정 시간에 실행시키는 코드인 (PREFETCH) 등이 있다.
AIT에 기록된 컨트롤 코드가, 이들 애플리케이션의 캐시 처리를 필요로 하는 코드인 것을 확인하면, 스텝 S302로 진행한다.
또한, 이들, 캐시 처리가 필요한 코드가 아닌 경우에는, 스텝 S302 이하의 처리는 실행되지 않고, 기록 코드에 따른 처리가 실행되게 된다.
(스텝 S302)
수신 장치는, AIT에 기록된 컨트롤 코드가, 애플리케이션의 캐시 처리를 필요로 하는 코드인 것을 확인하면, 스텝 S302에 있어서, AIT로부터, 애플리케이션의 취득처 URI를 판독한다.
즉, 먼저 도 15를 참조하여 설명한 AIT 기록 정보 중의 애플리케이션 액세스 정보(appLocation(URI))이다.
(스텝 S303 내지 S304)
이어서, 수신 장치는, 스텝 S303에 있어서, 또 하나의 시그널링 데이터인 USD(또는 USBD)를 참조하여, 애플리케이션이 방송파 또는 통신 네트워크 중 어느 것을 통해 송신되는지를 확인한다.
이것은, 먼저 도 12를 참조하여 설명한 처리이며, 도 12에 나타내는 USD(USBD)에 기록된 베이스 패턴 정보를 참조하여 확인한다.
도 12에 나타내는 USD(USBD)에는, 애플리케이션이 방송파를 통해 송신되는 경우, 방송파에 대응하는 베이스 패턴 기록 영역(USD/deliveryMethod/atsc: BcAppService/basePattern)에 베이스 패턴이 기록된다.
한편, 애플리케이션이 통신 네트워크를 통해 송신되는 경우, 통신 네트워크에 대응하는 베이스 패턴 기록 영역(USD/deliveryMethod/atsc: UcAppService/basePattern)에 베이스 패턴이 기록된다.
수신 장치는, USD에 어느 쪽 베이스 패턴이 기록되어 있는지에 의해, 애플리케이션이 방송파를 통해 송신되는지, 인터넷 등의 통신 네트워크를 통해 송신되는지를 판정할 수 있다.
애플리케이션이 방송파를 통해 송신되는 것이 확인된 경우에는, 스텝 S305로 진행한다.
한편, 애플리케이션이 인터넷 등의 통신 네트워크를 통해 송신되는 것이 확인된 경우에는, 스텝 S306으로 진행한다.
(스텝 S305)
애플리케이션이 방송파를 통해 송신되는 것이 확인된 경우에는, 스텝 S305로 진행하고, 스텝 S305에 있어서, 방송파를 통한 애플리케이션 취득 처리를 실행한다.
이 처리에 대해서는, 후단에서 도 39에 나타내는 플로우를 참조하여 상세하게 설명한다.
(스텝 S306)
한편, 애플리케이션이 인터넷 등의 통신 네트워크를 통해 송신되는 것이 확인된 경우에는, 스텝 S306으로 진행하고, 스텝 S306에 있어서, 통신 네트워크를 통한 애플리케이션 취득 처리를 실행한다.
(스텝 S307)
스텝 S305 또는 스텝 S306에 있어서 애플리케이션의 취득 처리가 행해진 후, 수신 장치는, 스텝 S307에 있어서 애플리케이션을 실행한다.
또한, 애플리케이션의 실행 타이밍 등은, 애플리케이션 대응의 AIT에 기록되어 있으며, 수신 장치는, AIT의 기술에 따라서 애플리케이션의 실행 제어를 행한다.
[10-5. 수신 장치에 있어서의 방송 경유의 애플리케이션 취득 처리의 상세 시퀀스]
이어서, 도 39에 나타내는 플로우를 참조하여, 도 38의 스텝 S305에 있어서 실행하는 방송 경유에서의 애플리케이션의 취득 처리의 상세 시퀀스에 대하여 설명한다.
이하, 각 스텝의 처리에 대하여 설명한다.
(스텝 S321)
먼저, 수신 장치는, 스텝 S321에 있어서, 수신 장치의 이용 가능한 캐시 사이즈를 취득한다.
(스텝 S322)
이어서, 수신 장치는, 스텝 S322에 있어서, 취득 예정의 애플리케이션 데이터 사이즈, 즉, 애플리케이션 사이즈를 취득한다.
애플리케이션 사이즈는, 먼저 도 12를 참조하여 설명한 바와 같이 AIT에 기록되어 있다. 도 12에 나타내는 애플리케이션 사이즈(253)(＠appSize)이다.
수신 장치는, 취득 예정의 애플리케이션에 대응하는 AIT를 참조하여, 애플리케이션 사이즈를 판독한다.
(스텝 S323)
이어서, 수신 장치는, 스텝 S323에 있어서, 수신 장치의 이용 가능한 캐시 사이즈와, 애플리케이션 사이즈를 비교한다.
캐시 사이즈가, 애플리케이션 사이즈보다 작은 경우에는, 스텝 S324로 진행한다.
한편, 캐시 사이즈가, 애플리케이션 사이즈 이상인 경우에는, 스텝 S325로 진행한다.
(스텝 S324)
스텝 S323에 있어서의 사이즈 비교 처리에 있어서, 캐시 사이즈가, 애플리케이션 사이즈보다 작다고 판정한 경우에는, 스텝 S324로 진행하고, 프리젠테이션ㆍ유닛(PU) 단위의 캐시 처리를 실행한다.
이 처리는, 먼저 도 20 내지 도 25를 참조하여 설명한 처리, 즉, 캐시 사이즈가 최소 사이즈(Minimum) 또는 소 사이즈(Small)인 경우의 처리에 상당하는 처리이다.
(스텝 S325)
한편, 스텝 S323에 있어서의 사이즈 비교 처리에 있어서, 캐시 사이즈가, 애플리케이션 사이즈 이상이라고 판정한 경우에는, 스텝 S325로 진행하고, 애플리케이션 단위의 캐시 처리를 실행한다.
이 처리는, 먼저 도 26 내지 도 34를 참조하여 설명한 처리, 즉,
캐시 사이즈가 중 사이즈(Medium) 또는 대 사이즈(Large) 또는 최대 사이즈(Maximum)인 경우의 처리에 상당하는 처리이다.
[10-6. 수신 장치에 있어서의 프리젠테이션ㆍ유닛(PU) 단위의 캐시 처리의 상세 시퀀스]
이어서, 도 40에 나타내는 플로우를 참조하여, 도 39의 스텝 S324에 있어서 실행하는 프리젠테이션ㆍ유닛(PU) 단위의 캐시 처리의 상세 시퀀스에 대하여 설명한다.
이하, 각 스텝의 처리에 대하여 설명한다.
(스텝 S341)
먼저, 수신 장치는, 스텝 S341에 있어서, 송신 장치로부터 송신되는 시그널링 데이터인 S-TSID로부터, 엔트리 문서를 포함하는 프리젠테이션ㆍ유닛(PU)과, 이 PU로부터 링크하는 프리젠테이션ㆍ유닛(PU)의 ID(PUID)를 취득한다.
수신 장치는, 먼저 도 16을 참조하여 설명한 S-TSID에 있어서의 프리젠테이션ㆍ유닛간 링크 정보(261)를 참조하여, 링크 관계에 있는 PU의 ID를 취득한다.
(스텝 S342)
이어서, 수신 장치는, 수신 장치의 캐시 사이즈, 즉, 이용 가능한 캐시 사이즈와, 각 프리젠테이션ㆍ유닛(PU)의 데이터 사이즈를 비교하여, 캐시 대상으로 하는 프리젠테이션ㆍ유닛을 선택한다.
또한, 최우선 캐시 대상 PU는, 엔트리 문서를 갖는 프리젠테이션ㆍ유닛(예를 들어, PU11)이다.
그 다음 우선 캐시 대상 PU는, 엔트리 문서를 갖는 PU11의 링크처 PU, 예를 들어 PU12가 된다.
또한, PU12의 링크처 PU13이 다음 캐시 대상 PU로서 선택되고, 링크를 찾아, 순차적으로 캐시 대상 PU가 선택된다.
캐시 사이즈를 초과한 시점에서, 캐시 대상 PU의 선택이 완료된다.
구체적으로는, 예를 들어
PU11사이즈≤캐시 사이즈<(PU11+PU12) 사이즈
인 경우에는, PU11만을 캐시 대상 PU로서 선택한다.
또한, (PU11+PU12) 사이즈≤캐시 사이즈<(PU11+PU12+PU13) 사이즈
인 경우에는, PU11과 PU12를 캐시 대상 PU로서 선택한다.
이와 같이, PU의 총계 사이즈가, 캐시 사이즈에 도달할 때까지의 범위 내에서, 캐시 대상 PU를, 링크를 찾아 순차적으로 선택한다.
(스텝 S343)
이어서, 수신 장치는, 스텝 S342에서 결정한 캐시 대상 프리젠테이션ㆍ유닛(PU)을 취득하여, 캐시부(기억부)에 캐시(저장)한다.
그 후, 도 38의 플로우에 나타내는 스텝 S307에 있어서, 저장된 프리젠테이션ㆍ유닛을 이용하여 애플리케이션이 실행된다.
또한, 이 도 40에 나타내는 플로우에 따른 처리는, 먼저 도 20 내지 도 25를 참조하여 설명한 처리, 즉, 캐시 사이즈가 최소 사이즈(Minimum) 또는 소 사이즈(Small)인 경우의 처리에 상당하는 처리이다.
먼저 설명한 바와 같이, 하나의 프리젠테이션ㆍ유닛(PU: Peresentation Unit)은, 하나 또는 복수의 HTML(HyperText Markup Language)을 이용하여 제시되는 데이터의 세트에 의해 구성된다.
구체적으로는, 하나의 프리젠테이션ㆍ유닛(PU)은 이하의 구성 요소를 포함하는 유닛이다.
(1) 하나 또는 복수의 HTML 파일,
(2) 상기 HTML에 따라서 출력되는 화상(동화상, 정지 화상) 파일,
(3) 상기 HTML에 따라서 출력되는 음성 파일,
(4) 상기 HTML에 따른 데이터 출력 스타일을 규정한 스타일 시트 저장 파일.
예를 들어, 상기 구성 요소에 의해 하나의 프리젠테이션ㆍ유닛(PU)이 설정된다.
하나의 프리젠테이션ㆍ유닛(PU)에 속하는 데이터가 모두 취득되면, 그 프리젠테이션ㆍ유닛(PU)에 포함되는 HTML 문서에 의한 데이터 출력, 예를 들어 Web 페이지의 출력이 완전한 형태로 실행되는 것이 보증된다.
[10-7. 수신 장치에 있어서의 애플리케이션 단위의 캐시 처리의 상세 시퀀스]
이어서, 도 41에 나타내는 플로우를 참조하여, 도 39의 스텝 S325에 있어서 실행하는 애플리케이션 단위의 캐시 처리의 상세 시퀀스에 대하여 설명한다.
이하, 각 스텝의 처리에 대하여 설명한다.
(스텝 S361)
먼저, 수신 장치는, 스텝 S361에 있어서, 송신 장치로부터 송신되는 시그널링 데이터인 AIT로부터, 초기 실행 애플리케이션과, 그 애플리케이션의 링크처 애플리케이션의 정보를 취득한다.
수신 장치는, 예를 들어 먼저 도 15를 참조하여 설명한 AIT에 있어서의 링크처 애플리케이션 정보(254)를 참조하여, 링크 관계에 있는 애플리케이션의 정보를 취득한다.
(스텝 S362)
이어서, 수신 장치는, 수신 장치의 캐시 사이즈, 즉, 이용 가능한 캐시 사이즈와, 각 애플리케이션의 데이터 사이즈를 비교하여, 캐시 대상으로 하는 애플리케이션을 선택한다.
또한, 최우선 캐시 대상 애플리케이션은, AIT에 의해 지정된 초기 기동 애플리케이션(예를 들어, APP1)이다.
그 다음 우선 캐시 대상 애플리케이션은, 초기 기동 애플리케이션 1(APP1)의 링크처 애플리케이션, 예를 들어 APP2가 된다.
또한, 애플리케이션 2(APP2)의 링크처 애플리케이션 3(APP3)이 다음 캐시 대상 애플리케이션으로서 선택되고, 링크를 찾아, 순차적으로 캐시 대상 애플리케이션이 선택된다.
캐시 사이즈를 초과한 시점에서, 캐시 대상 애플리케이션의 선택이 완료된다.
구체적으로는, 예를 들어
애플리케이션 1(APP1) 사이즈≤캐시 사이즈<(애플리케이션 1(APP1)+애플리케이션 2(APP2)) 사이즈
인 경우에는, 애플리케이션 1(APP1)만을 캐시 대상 PU로서 선택한다.
또한, 애플리케이션 1(APP1)+애플리케이션 2(APP2)) 사이즈≤캐시 사이즈<(애플리케이션 1(APP1)+애플리케이션 2(APP2)+애플리케이션 3(APP3)) 사이즈
인 경우에는, 애플리케이션 1(APP1)과, 애플리케이션 2(APP2)를 캐시 대상 PU로서 선택한다.
이와 같이, 애플리케이션의 총계 사이즈가, 캐시 사이즈에 도달할 때까지의 범위 내에서, 캐시 대상 애플리케이션을, 링크를 찾아 순차적으로 선택한다.
(스텝 S363)
이어서, 수신 장치는, 스텝 S362에서 결정한 캐시 대상 애플리케이션을 취득하여, 캐시부(기억부)에 캐시(저장)한다.
그 후, 도 38의 플로우에 나타내는 스텝 S307에 있어서, 저장된 애플리케이션을 이용하여 애플리케이션이 실행된다.
또한, 이 도 41에 나타내는 플로우에 따른 처리는, 먼저 도 26 내지 도 34를 참조하여 설명한 처리, 즉, 캐시 사이즈가 중 사이즈(Medium) 또는 대 사이즈(Large) 또는 최대 사이즈(Maximum)인 경우의 처리에 상당하는 처리이다.
먼저 설명한 바와 같이, 하나의 애플리케이션에는 하나 이상의 프리젠테이션ㆍ유닛(PU: Peresentation Unit)이 포함된다. 프리젠테이션ㆍ유닛(PU)은,
(1) 하나 또는 복수의 HTML 파일,
(2) 상기 HTML에 따라서 출력되는 화상(동화상, 정지 화상) 파일,
(3) 상기 HTML에 따라서 출력되는 음성 파일,
(4) 상기 HTML에 따른 데이터 출력 스타일을 규정한 스타일 시트 저장 파일.
예를 들어, 상기 구성 요소에 의해 구성된다.
하나의 프리젠테이션ㆍ유닛(PU)에 속하는 데이터가 모두 취득되면, 그 프리젠테이션ㆍ유닛(PU)에 포함되는 HTML 문서에 의한 데이터 출력, 예를 들어 Web 페이지의 출력이 완전한 형태로 실행될 것이 보증된다.
본 개시의 캐시 처리는, 애플리케이션 단위 또는 프리젠테이션ㆍ유닛(PU) 단위로 캐시 처리를 실행한다.
즉, 최소 캐시 단위는, 프리젠테이션ㆍ유닛(PU)이며, PU를 구성하는 데이터의 일부가 캐시되지 않는다는 사태를 발생시키는 일이 없다.
따라서, 프리젠테이션ㆍ유닛(PU)에 포함되는 HTML 문서에 의한 완성된 데이터 출력이 실행된다.
[10-8. 수신 장치에 있어서의 애플리케이션 또는 프리젠테이션ㆍ유닛(PU)간의 천이 처리 시퀀스]
이어서, 도 42에 나타내는 플로우를 참조하여, 애플리케이션 실행 중에 발생하는 애플리케이션 또는 프리젠테이션ㆍ유닛(PU)간의 천이 처리 시퀀스에 대하여 설명한다.
이하, 각 스텝의 처리에 대하여 설명한다.
(스텝 S501 내지 S502)
이하에 있어서 설명하는 처리는, 수신 장치에 있어서 소정의 애플리케이션을 실행 중에 행해지는 처리이다.
수신 장치는, 스텝 S501에 있어서 천이 이벤트를 대기한다.
또한, 여기에서 천이란, 실행 중인 애플리케이션으로부터 링크처 애플리케이션으로의 천이인 애플리케이션간 천이, 또는 실행 중인 프리젠테이션ㆍ유닛(PU)으로부터 링크처의 프리젠테이션ㆍ유닛(PU)으로의 천이인 PU간 천이 중 어느 것이다.
또한, 천이 이벤트는, 예를 들어 AIT의 제어 정보, 또는 예를 들어 유저의 조작에 기초하여 발생하는 링크처로의 천이를 지시하는 이벤트이다.
수신 장치는, 천이 이벤트를 검출하면 스텝 S503으로 진행한다.
(스텝 S503)
수신 장치는, 천이 이벤트의 검출에 따라서, 스텝 S503에 있어서, 천이처의 애플리케이션 또는 프리젠테이션ㆍ유닛(PU)이 캐시 완료인지 여부를 판정한다.
캐시 완료인 경우에는, 스텝 S504로 진행한다.
한편, 캐시 완료가 아닌 경우에는, 스텝 S505로 진행한다.
(스텝 S504)
스텝 S503에 있어서, 천이처의 애플리케이션 또는 프리젠테이션ㆍ유닛(PU)이 캐시 완료라고 판정한 경우에는, 스텝 S504에 있어서, 천이처의 애플리케이션 또는 프리젠테이션ㆍ유닛(PU)을 캐시부로부터 취득하여 실행한다.
(스텝 S505)
한편, 스텝 S503에 있어서, 천이처의 애플리케이션 또는 프리젠테이션ㆍ유닛(PU)이 캐시 완료가 아니라고 판정한 경우에는, 스텝 S505에 있어서, 천이 형태가, 이하의 어느 것인지를 확인한다.
(a) 애플리케이션 내의 프리젠테이션ㆍ유닛(PU)간의 천이,
(b) 애플리케이션간의 천이.
(a) 애플리케이션 내의 프리젠테이션ㆍ유닛(PU)간의 천이인 경우에는, 스텝 S506으로 진행한다.
한편, (b) 애플리케이션간의 천이인 경우에는, 스텝 S507로 진행한다.
(스텝 S506)
스텝 S505에 있어서, 천이 이벤트가, (a) 애플리케이션 내의 프리젠테이션ㆍ유닛(PU)간의 천이인 경우에는, 스텝 S506에 있어서, 천이처의 프리젠테이션ㆍ유닛(PU)의 캐시 처리를 실행한다.
이 처리는, 먼저 도 40을 참조하여 설명한 프리젠테이션ㆍ유닛(PU) 단위의 캐시 처리와 동일한 처리이다.
이 캐시 처리를 실행한 후, 저장한 프리젠테이션ㆍ유닛(PU)을 캐시부로부터 취득하여 실행한다.
(스텝 S507)
한편, 스텝 S505에 있어서, 천이 이벤트가, (b) 애플리케이션간의 천이인 경우에는, 스텝 S507에 있어서, 천이처의 애플리케이션을 취득하여 캐시 처리를 실행하고, 그 후, 캐시 애플리케이션을 실행한다.
이 처리는, 먼저 도 38을 참조하여 설명한 애플리케이션의 취득, 실행 처리와 동일한 처리이다.
이와 같이, 링크처의 애플리케이션 또는 프리젠테이션ㆍ유닛(PU)이 캐시되지 않은 경우에 있어서도, 링크처에 따라서 캐시 대상을 애플리케이션 또는 프리젠테이션ㆍ유닛(PU) 단위로 한 캐시 처리를 실행한다.
[11. 애플리케이션 천이 처리의 구체예에 대해서]
이어서, 도 42에 나타내는 흐름도를 참조하여 설명한 애플리케이션의 천이 처리의 구체예에 대하여 설명한다.
도 43, 도 44를 참조하여, 이하 2개의 천이 처리예에 대하여 설명한다.
(예 1) 프로그램 재생과 함께 실행되는 프로그램 연동 애플리케이션으로부터 CM 애플리케이션으로의 천이 처리예
(예 2) 프로그램 재생 애플리케이션으로부터 CM 애플리케이션으로의 천이 처리예
먼저, 도 43을 참조하여,
(예 1) 프로그램 재생과 함께 실행되는 프로그램 연동 애플리케이션으로부터 CM 애플리케이션으로의 천이 처리예
에 대하여 설명한다.
도 43에는, 수신 장치가 선택한 채널에 대응하여, 송신 장치가 방송파를 통해 제공하는 이하 4개의 데이터를 나타내고 있다.
(a) 화상(Video)
(b) 음성(Audi)
(c) NRT(애플리케이션(APP))
(d) 시그널링 데이터
수신 장치는, 도 43에 나타내는 스텝 S701 내지 S707의 처리를 실행한다.
각 처리 스텝에 대해서, 순차적으로 설명한다.
(스텝 S701)
먼저, 수신 장치는, 스텝 S701에 있어서, 송신 장치가 송신하는 시그널링 데이터를 수신한다.
시그널링 데이터에는, 여러 종류가 있고, USBD/USD, AIT, S-TSID, 또한 프로그램 재생에 이용되는 MPD 등이 있다.
수신 장치는, 이들 시그널링 데이터를 수신한다.
(스텝 S702)
이어서, 수신 장치는, 스텝 S702에 있어서, 수신한 시그널링 데이터를 해석하고, 해석 결과에 기초하여 프로그램 구성 데이터인 AV 세그먼트, 애플리케이션 리소스 등의 액세스 정보 등, 프로그램 재생이나 애플리케이션의 실행에 필요한 정보를 취득한다.
(스텝 S703)
이어서, 수신 장치는, 스텝 S703에 있어서, 스텝 S702에서 취득한 시그널링 데이터 해석 정보에 기초하여, 프로그램을 구성하는 AV 세그먼트나 애플리케이션 리소스 등의 데이터 취득 처리, 캐시 처리를 실행한다.
본 예에서는, 프로그램 재생에 필요한 AV 세그먼트 및 프로그램 재생과 함께 실행시키는 프로그램 연동 애플리케이션(APP1), 또한 프로그램 연동 애플리케이션(APP1)의 링크처(천이처) 애플리케이션인 CM 애플리케이션(CM APP)을 취득하여, 캐시부에 저장한다.
(스텝 S704)
수신 장치는, 스텝 S704에 있어서, 방송파를 통해 취득한 AV 세그먼트를 사용하여 프로그램 재생을 행하고, 또한 프로그램 재생과 병행하여 프로그램 연동 애플리케이션(APP1)을 실행한다.
예를 들어, 일례로서, 프로그램이 야구 중계이며, 프로그램 연동 애플리케이션(APP1)은 참가 선수의 선수 정보 제공 애플리케이션 등의 조합 등이 있다.
(스텝 S705)
이어서, 수신 장치에 대하여, 시그널링 데이터에 의한 이벤트 통지가 이루어진다.
이 이벤트 통지는, 실행 애플리케이션의 전환을 요구하는 이벤트 통지로, 즉, 애플리케이션간 천이 통지 이벤트이다.
(스텝 S706)
수신 장치는, 이 애플리케이션 천이 이벤트의 검출에 따라서, 애플리케이션의 천이 처리를 실행한다.
이 처리의 구체적인 처리 시퀀스는, 도 42에 나타내는 흐름도에 따른 처리가 된다.
여기서, 천이처의 애플리케이션은, CM 애플리케이션(CM APP)인 것으로 한다.
(스텝 S707)
수신 장치는, 스텝 S707에 있어서, 미리 저장되어 있는 CM 애플리케이션(CM APP)을 이용하여 CM의 재생 처리를 개시한다.
예를 들어, 여기에서 재생하는 CM 애플리케이션은, 먼저 도 6을 참조하여 설명한 바와 같이, 시청자에 따른 CM으로서 설정할 수 있다.
송신 장치가, 다양한 시청자에 대응한 다른 CM 애플리케이션을 송신하는 구성으로서, 수신 장치측에서, 미리 등록한 유저 정보에 따라서 수신하는 CM 애플리케이션을 선택하여 저장한다.
이러한 애플리케이션의 선택 취득 처리를 실행함으로써, 유저(시청자)의 연령, 성별, 기호 등에 따른 최적인 유저 대응 CM을 표시하는 것도 가능해진다.
이어서, 도 44를 참조하여,
(예 2) 프로그램 재생 애플리케이션으로부터 CM 애플리케이션으로의 천이 처리예
에 대하여 설명한다.
도 44에도, 도 43과 동일하게, 수신 장치가 선택한 채널에 대응하여, 송신 장치가 방송파를 통해 제공하는 이하 4개의 데이터를 나타내고 있다.
(a) 화상(Video)
(b) 음성(Audi)
(c) NRT(애플리케이션(APP))
(d) 시그널링 데이터
수신 장치는, 도 44에 나타내는 스텝 S801 내지 S807의 처리를 실행한다.
각 처리 스텝에 대해서, 순차적으로 설명한다.
(스텝 S801)
먼저, 수신 장치는, 스텝 S801에 있어서, 송신 장치가 송신하는 시그널링 데이터를 수신한다.
시그널링 데이터에는, 여러 종류가 있고, USBD/USD, AIT, S-TSID, 또한 프로그램 재생에 이용되는 MPD 등이 있다.
수신 장치는, 이들 시그널링 데이터를 수신한다.
(스텝 S802)
이어서, 수신 장치는, 스텝 S802에 있어서, 수신한 시그널링 데이터를 해석하고, 해석 결과에 기초하여 프로그램 구성 데이터인 AV 세그먼트, 애플리케이션의 애플리케이션 리소스 등의 액세스 정보 등, 프로그램 재생이나 애플리케이션의 실행에 필요한 정보를 취득한다.
(스텝 S803)
이어서, 수신 장치는, 스텝 S803에 있어서, 스텝 S702에서 취득한 시그널링 데이터 해석 정보에 기초하여, 프로그램을 구성하는 AV 세그먼트나 애플리케이션 리소스 등의 데이터 취득 처리, 캐시 처리를 실행한다.
본 예에서는, 프로그램 재생에 필요한 AV 세그먼트 및 프로그램 재생 처리를 실행하는 프로그램 재생 애플리케이션(APP1), 또한 프로그램 재생 애플리케이션(APP1)의 링크처(천이처) 애플리케이션인 CM 애플리케이션(CM APP)을 취득하여, 캐시부에 저장한다.
(스텝 S804)
수신 장치는, 스텝 S804에 있어서, 방송파를 통해 취득한 AV 세그먼트와 프로그램 재생 애플리케이션(APP1)을 사용하여 프로그램 재생을 행한다.
(스텝 S805)
이어서, 수신 장치는, 예를 들어 AIT 등의 시그널링 데이터, 또는 유저의 조작(리모컨 조작) 등에 의한 이벤트를 검출한다.
이 이벤트는, 실행 애플리케이션의 전환을 요구하는 이벤트이다. 즉, 애플리케이션간 천이 통지 이벤트이다.
(스텝 S806)
수신 장치는, 이 애플리케이션 천이 이벤트의 검출에 따라서, 애플리케이션의 천이 처리를 실행한다.
이 처리의 구체적인 처리 시퀀스는, 도 42에 나타내는 흐름도에 따른 처리가 된다.
여기서, 천이처의 애플리케이션은, CM 애플리케이션(CM APP)인 것으로 한다.
(스텝 S807)
수신 장치는, 스텝 S807에 있어서, 미리 저장되어 있는 CM 애플리케이션(CM APP)을 이용하여 CM의 재생 처리를 개시한다.
이 예에 있어서도, CM 애플리케이션은, 먼저 도 6을 참조하여 설명한 바와 같이, 시청자에 따른 CM으로서 설정할 수 있다.
송신 장치가, 다양한 시청자에 대응한 다른 CM 애플리케이션을 송신하는 구성으로서, 수신 장치측에서, 미리 등록한 유저 정보에 따라서 수신하는 CM 애플리케이션을 선택하여 저장한다.
이러한 애플리케이션의 선택 취득 처리를 실행함으로써, 유저(시청자)의 연령, 성별, 기호 등에 따른 최적인 유저 대응 CM을 표시하는 것도 가능해진다.
[12. 서비스 워커(SW)를 이용한 캐시 제어 처리예에 대해서]
이어서, 서비스 워커(SW)를 이용하여 애플리케이션의 캐시 제어를 행하는 처리예에 대하여 설명한다.
먼저, 서비스 워커(SW: Service Worker)의 개요에 대해서, 도 45 내지 도 47을 참조하여 설명한다.
서비스 워커(SW)는, 방송 서버나, 광고 서버 등의 송신 장치(20)로부터 수신 장치(30)에 제공된다.
서비스 워커(SW)는, 수신 장치(클라이언트)(30)에 있어서 실행되는 애플리케이션이나, 애플리케이션의 실행 시에 이용되는 데이터 파일 등의 취득 처리나, 기억부(캐시)에 대한 저장 처리, 또한 갱신 처리, 삭제 처리 등을 실행하는 프로그램이다. 구체적으로는, 예를 들어 JavaScript(등록 상표)에 의해 구성된다.
서비스 워커(SW)는, 예를 들어 송신 장치(20)가 제공하는 방송 프로그램(방송 콘텐츠)에 대응하여 설정되고, 송신 장치(20)로부터 수신 장치(30)에 제공되는 애플리케이션의 제어 및 관리 프로그램으로서, 수신 장치(30)에 제공된다.
서비스 워커(SW), 애플리케이션 및 애플리케이션의 실행 시에 이용되는 데이터 파일, 이들은, 예를 들어 먼저 도 2, 도 3을 참조하여 설명한 NRT 콘텐츠(논리얼타임 콘텐츠)로서, 송신 장치(20)로부터 수신 장치(30)에 제공된다.
또는, 방송 프로그램을 배신하는 서버와는 다른 데이터 제공 서버가, 서비스 워커(SW), 애플리케이션 및 애플리케이션의 실행 시에 이용되는 데이터 파일을 수신 장치(30)에 제공하는 구성으로 해도 된다.
서비스 워커(SW)는, 예를 들어 수신 장치(30)에 있어서 웹페이지 등의 열람 처리를 실행하기 위해 이용되는 프로그램인 브라우저를 이용하여 정보 표시를 실행하는 애플리케이션 등의 관리(취득, 유지, 갱신, 삭제 등) 처리 등을 실행한다.
서비스 워커(SW)를 이용한 처리의 구체예(사용례)에 대해서, 도 45, 도 46을 참조하여 설명한다.
도 45는, 수신 장치(30)가, 방송 서버(21) 등의 송신 장치(20)로부터, 어떤 프로그램 콘텐츠를 수신하고, 수신 장치(30)의 표시부에 표시하고 있는 상태를 나타내고 있다.
방송 서버(21) 등의 송신 장치(20)는, 프로그램 배신과 함께, NRT 콘텐츠(논리얼타임 콘텐츠)로서, 날씨 정보를 표시하는 애플리케이션, 및 이 날씨 정보 표시 애플리케이션에 이용되는 각종 데이터 파일, 예를 들어 동화상, 정지 화상, 음성 등의 각종 데이터를 포함하는 데이터 파일(리소스)을 수신 장치(30)에 제공한다.
방송 서버(21)는, 또한 이들 「리소스」를 관리하는 리소스 관리 프로그램으로서, 서비스 워커(SW)를, 역시 NRT 콘텐츠(논리얼타임 콘텐츠)로서 수신 장치(30)에 제공한다.
수신 장치(30)는, 송신 장치(20)로부터 수신한 「리소스」, 즉, 애플리케이션 및 데이터 파일을 이용하여, 도 45에 도시한 바와 같이, 프로그램 표시와 함께, 날씨 정보의 표시를 행할 수 있다.
이러한, 애플리케이션을 이용한 데이터 표시는, 지금까지의 데이터 배신 구성에서는, 애플리케이션이 제공되는 프로그램의 종료와 함께 실행할 수 없게 되어버린다.
이것은, 날씨 정보 표시 애플리케이션 등의 리소스는, 프로그램 수신 중에는, 수신 장치(30)에 있어서 이용 가능한 설정, 예를 들어 일시 기억 캐시에 저장되어, 이용 가능한 상태로 설정되지만, 프로그램 종료, 또는 유저가 채널을 전환하면, 이들 캐시 데이터가 소거, 또는 액세스 불가능한 상태로 설정되어버리기 때문이다.
서비스 워커(SW)는, 이러한 프로그램 대응의 애플리케이션이나 데이터를, 프로그램 종료 후나, 채널 전환 후, 또는 방송의 비수신 상태, 네트워크 비접속 상태 등의 오프라인 상태라도 이용 가능하게 하기 위한 리소스 관리 프로그램으로서 기능한다.
도 46에 도시한 바와 같이, 날씨 정보 표시 애플리케이션을, 이 애플리케이션을 제공한 프로그램의 종료 후나, 다른 채널로 전환한 후, 또는 데이터 수신을 실행하지 않은 오프라인 상태라도, 이용하는 것이 가능해진다. 즉, 날씨 정보를 수신 장치(30)의 표시부에 표시하여 열람하는 것이 가능해진다.
또한, 날씨 정보 표시 애플리케이션은, 예를 들어 브라우저 상에서 표시되는 프로그램이다.
이 날씨 정보 표시 애플리케이션은, 서비스 워커(SW)의 제어에 의해, 수신 장치(30)의 기억부(캐시)에 저장된다. 예를 들어 유저에 의한 표시 요구 등의 리퀘스트(이벤트)가 있으면, 서비스 워커(SW)의 제어에 의해, 기억부(캐시)로부터 판독되어, 표시부에 표시된다.
또한, 애플리케이션 등의 리소스를 저장하는 기억부(캐시)는, 수신 장치(30)의 전원이 오프가 되어도 저장 데이터가 소거되지 않는 불휘발성 메모리로 하는 것이 바람직하다.
이와 같이, 서비스 워커(SW)를 이용함으로써, 각종 프로그램 대응 애플리케이션을, 프로그램의 표시, 비표시와 관계없이 이용하는 것이 가능해진다.
또한, 서비스 워커(SW)는, 예를 들어 어떤 프로그램 대응의 리소스(애플리케이션 및 애플리케이션 관련 데이터) 단위마다 설정되고, 리소스와 함께, 또는 리소스 송신에 전후하여 송신 장치(20)로부터 수신 장치(30)에 제공된다.
서비스 워커(SW)는, 각 프로그램 대응의 설정으로 할 수도 있지만, 복수 프로그램을 포함하는 특정 채널 대응의 리소스에 대하여 공통으로 이용 가능하게 한 서비스 워커(SW)를 설정할 수도 있다.
서비스 워커(SW)과, 서비스 워커(SW)에 의해 관리되는 리소스(애플리케이션 및 애플리케이션 관련 데이터)는, 수신 장치(30)의 기억부(캐시)에 저장된다.
이 서비스 워커(SW)를 이용하여 캐시 제어 처리를 실행시키는 구성으로 할 수 있다.
즉, 먼저, 도 40에 나타내는 흐름도를 참조하여 설명한 프리젠테이션ㆍ유닛(PU) 단위의 캐시 처리나, 도 41을 참조하여 설명한 애플리케이션 단위의 캐시 제어 처리를 실행시키는 구성으로 할 수 있다.
도 47은, 서비스 워커(SW)를 이용한 처리의 일례를 설명하는 도면이다.
도 47에는, 수신 장치(30)가 송신 장치(20)로부터 리소스로서의 웹페이지(예를 들어 도 45, 도 46에 나타내는 날씨 정보 표시 페이지)를 취득하여 수신 장치(30)의 기억부(캐시)에 저장하여 이용하는 시퀀스의 일례를 나타내고 있다.
또한, 웹페이지는, 소정의 웹페이지 표시 애플리케이션과, 표시용 데이터에 의해 구성되는 리소스를 이용하여 표시된다.
도 47에는, 수신 장치 내의 브라우저(450)의 구성 요소로서 표시 처리부(451), 서비스 워커(SW)(452), 캐시(기억부)(453)를 나타내고 있다.
스텝 S851 내지 S852는, 수신 장치(30)에 의한 송신 장치(20)에 대한 첫회 엑세스 처리에 의한 리소스(웹페이지) 취득 처리이다.
이것은, 예를 들어 방송 서버 등이 송신하는 NRT 콘텐츠로부터 취득된다.
이 리소스 취득 처리 시에 서비스 워커(SW)를 적용하여, 캐시 사이즈와 애플리케이션 사이즈나 프리젠테이션ㆍ유닛(PU) 사이즈에 따른 리소스 취득 처리를 실행시킨다.
즉, 최소 캐시 사이즈를 프리젠테이션ㆍ유닛(PU)으로 한 캐시 처리를 실행한다.
이 캐시 처리에 의한 리소스 취득 후, 표시 처리부(451)에 의해, 애플리케이션 실행에 의한 웹페이지(455)가, 수신 장치(30)의 표시부에 표시된다. 이 표시는, 이 웹페이지를 제공하고 있는 프로그램에 함께 표시되고 있는 상태이며, 앞서 도 45를 참조하여 설명한 표시 상태에 상당한다.
그 후, 프로그램 종료 후, 또는 채널 전환 후, 또는 오프라인 설정 상태에 있어서, 스텝 S855에 있어서, 유저가 Web 페이지의 열람 요구를 행한다.
서비스 워커(SW)(452)는, 이 열람 요구의 입력을 페치 이벤트로서 검출하고, 페치 이벤트 검출에 따라서, 스텝 S856에 있어서, 리소스(웹페이지)를 기억부(캐시)로부터 취득한다.
표시 처리부(451)는, 스텝 S857에 있어서, 웹페이지(456)를 표시한다.
이 웹페이지 표시 처리는, 프로그램 종료 후, 또는 채널 전환 후, 또는 오프라인 설정 상태에 있어서의 표시 처리이며, 먼저 도 46을 참조하여 설명한 표시 상태에 상당한다.
이와 같이, 서비스 워커(SW)를 이용함으로써, 각종 애플리케이션 등의 프로그램을, 프로그램의 표시, 비표시와 무관계로 이용하는 것이 가능해지고, 예를 들어 프로그램 부속의 표시 정보로서 설정된 웹페이지를 프로그램과 무관계로, 임의의 타이밍에 표시하는 등의 처리가 가능해진다.
이와 같이, 서비스 워커(SW)는, 예를 들어 웹페이지, HTML 페이지, JavaScript(등록 상표) 등을 구성 요소로 한 애플리케이션이나 프로그램, 애플리케이션 등에 이용되는 데이터 등을 포함하는 리소스의 취득, 보존, 갱신, 삭제 등의, 리소스 관리를 실행한다.
리소스가 보존되는 기억부(캐시)는, 통상의 로컬/일시적인 캐시와는 달리, 애플리케이션이 가동하고 있지 않아도, 데이터가 보존된다.
웹페이지 표시 프로그램인 브라우저의 1종의 프록시 서버가 실장되고, 언제나, 필요할 때에 프록시 서버를 액세스하여 웹페이지를 취득하여 표시 가능하게 한 이미지이다.
또한, 서비스 워커(SW) 자체도 캐시에 저장(인스톨)된다. 서비스 워커(SW)가, 수신 장치에 인스톨되면, 이 서비스 워커(SW)의 관리 대상으로 하는 리소스에 대해서, 각종 제어가 가능해진다.
예를 들어, 리소스로의 액세스 리퀘스트(리소스로의 페치 리퀘스트)에 따라서, 브라우저측의 처리(로컬 캐시나 네트워크로부터의 리소스의 취득)가 시작되기 전에, 서비스 워커(SW)의 처리가 개시되고, 캐시로부터의 리소스의 제공이 행해진다.
또한, 서비스 워커(SW)는, JavaScirpt(등록 상표)로 제공되기 때문에, 다양한 수속을 도입하는 것이 가능하고, 캐시의 리소스 일부의 갱신 등 캐시 제어에 관한 유연한 처리 기술이 가능해졌다.
또한, 서비스 워커(SW) 자체도 갱신 가능하다. 서비스 워커(SW)는, 송신 장치(20)로부터 제공되지만, 이 서비스 워커(SW)의 헤더 정보(HTTP Cache-Control)에 갱신 일시 정보나 갱신 데이터의 액세스 정보 등, 갱신 처리에 필요한 각종 정보가 기록되고, 이 헤더 정보에 기초하여 갱신 처리가 실행된다.
예를 들어, 헤더에 설정된 사용 기한 등에 기초하여, 사용 기한이 되면, 수신 장치(30)는, 새로운 버전의 서비스 워커(SW)의 취득 처리를 실행하여, 캐시에 저장된 구버전의 SW를 치환하는 갱신 처리를 행한다.
수신 장치(30)는, 서비스 워커(SW)를 이용하여, 임의의 타이밍에서, 예를 들어 도 45, 도 46을 참조하여 설명한 바와 같은 날씨 정보 표시 애플리케이션 등의 애플리케이션이나 프로그램, 즉, 서비스 워커(SW)의 관리 대상인 애플리케이션이나 프로그램을 실행하는 것이 가능해진다.
[13. 송신 장치와 수신 장치의 구성예에 대해서]
이어서, 통신 장치인 송신 장치(서버)(20)와, 수신 장치(클라이언트)(30)의 장치 구성예에 대해서, 도 48, 도 49를 참조하여 설명한다.
도 48에는, 송신 장치(서버)(20)와, 수신 장치(클라이언트)(30)의 구성예를 나타내고 있다.
송신 장치(서버)(20)는, 데이터 처리부(751), 통신부(752), 기억부(753)를 갖는다.
수신 장치(클라이언트)(30)는, 데이터 처리부(771), 통신부(772), 기억부(773), 입력부(774), 출력부(775)를 갖는다.
송신 장치(서버)(20)의 데이터 처리부(751)는, 데이터 배신 서비스를 실행하기 위한 각종 데이터 처리를 실행한다. 예를 들어 데이터 배신 서비스의 구성 데이터의 생성이나 송신 제어를 행한다. 또한, 데이터 처리부(751)는, 수신 장치(클라이언트)(30)에 제공하는 AV 세그먼트, 애플리케이션, 그 밖의 각종 데이터나, 시그널링 데이터의 생성, 송신 처리를 행한다.
통신부(752)는, AV 세그먼트 외에도, 애플리케이션, 그 밖의 각종 데이터, 시그널링 데이터 등의 배신 등의 통신 처리를 행한다.
기억부(753)는, 배신 대상으로 하는 AV 세그먼트, 애플리케이션, 애플리케이션에 의해 이용되는 데이터, 시그널링 데이터 등이 저장된다.
또한, 기억부(753)는, 데이터 처리부(751)가 실행하는 데이터 처리의 워크 에어리어로서 이용되고, 또한 각종 파라미터의 기억 영역으로서도 이용된다.
송신 장치(20)가 실행하는 구체적인 처리는, 예를 들어 이하의 처리이다.
데이터 처리부(751)는, 애플리케이션 구성 데이터를 저장한 패킷과, 애플리케이션의 데이터 사이즈인 애플리케이션 사이즈와, 애플리케이션간의 링크 정보인 애플리케이션 링크 정보를 기록한 제1 시그널링 데이터(AIT)를 저장한 패킷, 또한 애플리케이션의 구성 요소인 프리젠테이션ㆍ유닛의 데이터 사이즈와, 프리젠테이션ㆍ유닛간의 링크 정보를 기록한 제2 시그널링 데이터(S-TSID)를 저장한 패킷 등을 생성한다.
통신부(752)는, 데이터 처리부(751)가 생성한 이들 패킷을 송신하는 처리 등을 실행한다.
한편, 수신 장치(클라이언트)(30)는, 데이터 처리부(771), 통신부(772), 기억부(773), 입력부(774), 출력부(775)를 갖는다.
통신부(772)는, 송신 장치(서버)(20)로부터 배신되는 데이터, 예를 들어 AV 세그먼트나 애플리케이션, 애플리케이션에 의해 이용되는 데이터, 시그널링 데이터 등을 수신한다.
데이터 처리부(771)는, 통신 데이터 처리, 시그널링 데이터 해석 처리, 데이터 캐시 제어 처리, 재생 제어 처리, 애플리케이션 제어 처리 등, 예를 들어 먼저 설명한 실시예에 따른 처리 등을 실행한다.
구체적으로는, 애플리케이션이나, 프리젠테이션ㆍ유닛(PU) 단위의 캐시 제어, 애플리케이션 실행 제어 등을 실행한다.
유저의 지시 커맨드, 예를 들어 채널 선택, 애플리케이션 기동, 애플리케이션 천이 등의 각종 커맨드는 입력부(774)를 통해 입력된다.
재생 데이터는 표시부나 스피커 등의 출력부(775)로 출력된다.
기억부(773)는 AV 세그먼트, 애플리케이션, 애플리케이션에 의해 이용되는 데이터, 시그널링 데이터 등이 저장된다.
또한, 기억부(773)는, 데이터 처리부(771)가 실행하는 데이터 처리의 워크 에어리어로서 이용되고, 또한 각종 파라미터의 기억 영역으로서도 이용된다.
수신 장치(30)가 실행하는 구체적인 처리는, 예를 들어 이하의 처리이다.
통신부(772)는, 애플리케이션의 데이터 사이즈인 애플리케이션 사이즈와, 애플리케이션간의 링크 정보인 애플리케이션 링크 정보를 기록한 제1 시그널링 데이터(AIT)나, 애플리케이션의 구성 요소인 프리젠테이션ㆍ유닛의 데이터 사이즈를 기록한 제2 시그널링 데이터(S-TSID) 등을 수신한다.
또한, 데이터 처리부(771)는, 자장치의 기억부(773)에 저장 가능한 데이터 사이즈인 캐시 사이즈와, 제1 시그널링 데이터(AIT)로부터 취득하는 링크 관계에 있는 각 애플리케이션의 데이터 사이즈를 비교하여, 캐시 가능한 하나 이상의 애플리케이션을 캐시 대상 애플리케이션으로서 결정하고, 애플리케이션 단위의 캐시 처리를 실행한다.
또한, 데이터 처리부(771)는, 캐시 사이즈가, 하나의 애플리케이션의 데이터 사이즈보다 작은 경우, 제2 시그널링 데이터(S-TSID)를 참조하고, 프리젠테이션ㆍ유닛의 데이터 사이즈와, 캐시 사이즈를 비교하여, 캐시 사이즈 이하의 하나 이상의 프리젠테이션ㆍ유닛을 캐시 대상으로서 결정하고, 프리젠테이션ㆍ유닛 단위의 캐시 처리를 실행한다.
도 49는, 송신 장치(20), 수신 장치(30)로서 적용 가능한 통신 장치의 하드웨어 구성예를 나타내고 있다.
CPU(Central Processing Unit)(801)는, ROM(Read Only Memory)(802) 또는 기억부(808)에 기억되어 있는 프로그램에 따라서 각종 처리를 실행하는 데이터 처리부로서 기능한다. 예를 들어, 상술한 실시예에 있어서 설명한 시퀀스에 따른 처리를 실행한다. RAM(Random Access Memory)(803)에는, CPU(801)가 실행하는 프로그램이나 데이터 등이 기억된다. 이들의 CPU(801), ROM(802) 및 RAM(803)은, 버스(804)에 의해 서로 접속되어 있다.
CPU(801)는 버스(804)를 통해 입출력 인터페이스(805)에 접속되고, 입출력 인터페이스(805)에는, 각종 스위치, 키보드, 마우스, 마이크로폰 등을 포함하는 입력부(806), 디스플레이, 스피커 등을 포함하는 출력부(807)가 접속되어 있다. CPU(801)는, 입력부(806)로부터 입력되는 명령에 대응하여 각종 처리를 실행하고, 처리 결과를, 예를 들어 출력부(807)로 출력한다.
입출력 인터페이스(805)에 접속되어 있는 기억부(808)는, 예를 들어 하드 디스크 등을 포함하고, CPU(801)가 실행되는 프로그램이나 각종 데이터를 기억한다. 통신부(809)는, 인터넷이나 로컬 에어리어 네트워크 등의 네트워크를 통한 데이터 통신의 송수신부, 또한 방송파의 송수신부로서 기능하여, 외부 장치와 통신한다.
입출력 인터페이스(805)에 접속되어 있는 드라이브(810)는, 자기 디스크, 광 디스크, 광자기 디스크, 또는 메모리 카드 등의 반도체 메모리 등의 리무버블 미디어(811)를 구동하여, 데이터의 기록 또는 판독을 실행한다.
또한, 데이터의 부호화 또는 복호는, 데이터 처리부로서의 CPU(801)의 처리로서 실행 가능하지만, 부호화 처리 또는 복호 처리를 실행하기 위한 전용 하드웨어로서의 코덱을 구비한 구성으로 해도 된다.
[14. 본 개시의 구성 마무리]
이상, 특정 실시예를 참조하면서, 본 개시의 실시예에 대하여 상세하게 설명하였다. 그러나, 본 개시의 요지를 일탈하지 않는 범위에서 당업자가 실시예의 수정이나 대용을 할 수 있는 것은 자명하다. 즉, 예시라는 형태로 본 발명을 개시한 것이며, 한정적으로 해석되어서는 안된다. 본 개시의 요지를 판단하기 위해서는, 특허 청구범위의 란을 참작해야 한다.
또한, 본 명세서에 있어서 개시한 기술은, 이하와 같은 구성을 취할 수 있다.
(1) 애플리케이션의 데이터 사이즈인 애플리케이션 사이즈와, 애플리케이션간의 링크 정보인 애플리케이션 링크 정보를 기록한 제1 시그널링 데이터를 수신하는 통신부와,
자장치의 기억부에 저장 가능한 데이터 사이즈인 캐시 사이즈와, 상기 제1 시그널링 데이터로부터 취득하는 링크 관계에 있는 각 애플리케이션의 데이터 사이즈를 비교하여, 캐시 가능한 하나 이상의 애플리케이션을 캐시 대상 애플리케이션으로서 결정하고, 애플리케이션 단위의 캐시 처리를 실행하는 데이터 처리부를 갖는 수신 장치.
(2) 상기 제1 시그널링 데이터는,
링크원 애플리케이션 ID와, 링크처 애플리케이션 ID의 대응 데이터를, 애플리케이션 링크 정보로서 기록하고,
또한, 각 애플리케이션 ID에 대응지어 애플리케이션 사이즈를 기록한 구성이며,
상기 데이터 처리부는,
상기 제1 시그널링 데이터의 애플리케이션 링크 정보로부터, 링크원 애플리케이션 ID와, 링크처 애플리케이션 ID를 취득하고,
취득한 각 애플리케이션 ID에 대응하여 기록된 애플리케이션 사이즈 정보를 취득하여, 캐시 가능한 하나 이상의 애플리케이션을 캐시 대상 애플리케이션으로서 결정하는, (1)에 기재된 수신 장치.
(3) 상기 데이터 처리부는,
링크 관계에 있는 복수의 애플리케이션이 존재하는 경우,
초기 실행 애플리케이션을 최우선의 캐시 대상 애플리케이션으로서 선택하고, 이하, 상기 초기 실행 애플리케이션으로부터의 링크 순서에 따라서, 캐시 대상 애플리케이션을 순차적으로 선택하는, (1) 또는 (2)에 기재된 수신 장치.
(4) 상기 애플리케이션 ID는, 조직 ID와, 애플리케이션 본체 ID가 포함된 식별자인, (2) 또는 (3)에 기재된 수신 장치.
(5) 상기 제1 시그널링 데이터는, 애플리케이션 단위의 정보를 기록한 애플리케이션ㆍ인포메이션ㆍ테이블(AIT: Application Information Table)인, (1) 내지 (4) 중 어느 것에 기재된 수신 장치.
(6) 상기 통신부는,
상기 제1 시그널링 데이터를, 방송파를 통해 수신하는, (1) 내지 (5) 중 어느 것에 기재된 수신 장치.
(7) 상기 애플리케이션은, 광고 출력 처리를 실행하는 애플리케이션인, (1) 내지 (6) 중 어느 것에 기재된 기재된 수신 장치.
(8) 상기 수신부는,
애플리케이션의 구성 요소인 프리젠테이션ㆍ유닛의 데이터 사이즈를 기록한 제2 시그널링 데이터를 수신하고,
상기 데이터 처리부는,
상기 캐시 사이즈가, 하나의 애플리케이션의 데이터 사이즈보다 작은 경우,
상기 제2 시그널링 데이터를 참조하여, 상기 프리젠테이션ㆍ유닛의 데이터 사이즈와, 상기 캐시 사이즈를 비교하고,
캐시 사이즈 이하의 하나 이상의 프리젠테이션ㆍ유닛을 캐시 대상으로서 결정하여, 프리젠테이션ㆍ유닛 단위의 캐시 처리를 실행하는, (1) 내지 (7) 중 어느 것에 기재된 수신 장치.
(9) 상기 프리젠테이션ㆍ유닛은,
하나 또는 복수의 HTML(HyperText Markup Language) 문서와, 해당 HTML 문서를 적용하여 출력되는 데이터 파일에 의해 구성되는 데이터의 집합인, (8)에 기재된 수신 장치.
(10) 상기 제2 시그널링 데이터는,
링크원 프리젠테이션ㆍ유닛 ID와, 링크처 프리젠테이션ㆍ유닛 ID의 대응 데이터를, 프리젠테이션ㆍ유닛 링크 정보로서 기록하고,
또한, 각 프리젠테이션ㆍ유닛 ID에 대응지어 프리젠테이션ㆍ유닛 사이즈를 기록한 구성이며,
상기 데이터 처리부는,
상기 제2 시그널링 데이터의 프리젠테이션ㆍ유닛 링크 정보로부터, 링크원 프리젠테이션ㆍ유닛 ID와, 링크처 프리젠테이션ㆍ유닛 ID를 취득하고,
취득한 각 프리젠테이션ㆍ유닛 ID에 대응하여 기록된 프리젠테이션ㆍ유닛 사이즈 정보를 취득하여, 캐시 가능한 하나 이상의 프리젠테이션ㆍ유닛을 캐시 대상 애플리케이션으로서 결정하는, (8) 또는 (9)에 기재된 수신 장치.
(11) 상기 데이터 처리부는,
링크 관계에 있는 복수의 프리젠테이션ㆍ유닛이 존재하는 경우,
엔트리 문서를 포함하는 프리젠테이션ㆍ유닛을 최우선의 캐시 대상 프리젠테이션ㆍ유닛으로서 선택하고, 이하, 상기 엔트리 문서를 포함하는 프리젠테이션ㆍ유닛으로부터의 링크 순서에 따라서, 캐시 대상 프리젠테이션ㆍ유닛을 순차적으로 선택하는, (8) 내지 (10) 중 어느 것에 기재된 수신 장치.
(12) 상기 프리젠테이션ㆍ유닛 ID는, 프리젠테이션ㆍ유닛이 속하는 애플리케이션을 식별 가능하게 한 애플리케이션 본체 ID와, 소속 애플리케이션 내의 프리젠테이션ㆍ유닛을 개별로 식별 가능하게 한 그룹 ID를 포함하는 ID인, (10) 또는 (11)에 기재된 수신 장치.
(13) 상기 제2 시그널링 데이터는, 애플리케이션을 구성하는 프리젠테이션ㆍ유닛에 포함되는 파일 단위의 정보를 기록한 S-TSID인, (8) 내지 (11) 중 어느 것에 기재된 수신 장치.
(14) 상기 제2 시그널링 데이터에는, 프리젠테이션ㆍ유닛에 포함되는 파일 단위의 정보가 기록되고,
파일 단위 정보의 각각에는, 파일이 속하는 프리젠테이션ㆍ유닛에 설정된 그룹 ID가 대응지어 기록되어 있으며,
상기 데이터 처리부는,
그룹 ID에 기초하여, 캐시 대상 파일의 선택 처리를 실행하는, (8) 내지 (13) 중 어느 것에 기재된 수신 장치.
(15) 상기 통신부는,
상기 제2 시그널링 데이터를, 방송파를 통해 수신하는, (8) 내지 (14) 중 어느 것에 기재된 수신 장치.
(16) 애플리케이션 구성 데이터를 저장한 패킷과,
상기 애플리케이션의 데이터 사이즈인 애플리케이션 사이즈와, 애플리케이션간의 링크 정보인 애플리케이션 링크 정보를 기록한 제1 시그널링 데이터를 저장한 패킷을 생성하는 데이터 처리부와,
상기 데이터 처리부가 생성한 패킷을 송신하는 통신부
를 갖는 송신 장치.
(17) 상기 데이터 처리부는, 또한
애플리케이션의 구성 요소인 프리젠테이션ㆍ유닛의 데이터 사이즈와, 프리젠테이션ㆍ유닛간의 링크 정보를 기록한 제2 시그널링 데이터를 저장한 패킷을 생성하고,
상기 통신부는, 상기 제2 시그널링 데이터를 저장한 패킷을 송신하는, (16)에 기재된 송신 장치.
(18) 상기 프리젠테이션ㆍ유닛은,
하나 또는 복수의 HTML(HyperText Markup Language) 문서와, 해당 HTML 문서를 적용하여 출력되는 데이터 파일에 의해 구성되는 데이터의 집합인, (17)에 기재된 송신 장치.
(19) 수신 장치에 있어서 실행하는 데이터 처리 방법이며,
통신부가, 애플리케이션의 데이터 사이즈인 애플리케이션 사이즈와, 애플리케이션간의 링크 정보인 애플리케이션 링크 정보를 기록한 제1 시그널링 데이터를 수신하고,
데이터 처리부가, 자장치의 기억부에 저장 가능한 데이터 사이즈인 캐시 사이즈와, 상기 제1 시그널링 데이터로부터 취득하는 링크 관계에 있는 각 애플리케이션의 데이터 사이즈를 비교하여, 캐시 가능한 하나 이상의 애플리케이션을 캐시 대상 애플리케이션으로서 결정하고, 애플리케이션 단위의 캐시 처리를 실행하는 데이터 처리 방법.
(20) 송신 장치에 있어서 실행하는 데이터 처리 방법이며,
데이터 처리부가,
애플리케이션 구성 데이터를 저장한 패킷과,
상기 애플리케이션의 데이터 사이즈인 애플리케이션 사이즈와, 애플리케이션간의 링크 정보인 애플리케이션 링크 정보를 기록한 제1 시그널링 데이터를 저장한 패킷을 생성하고,
통신부가, 상기 데이터 처리부가 생성한 패킷을 송신하는 데이터 처리 방법.
또한, 명세서 중에 있어서 설명한 일련의 처리는 하드웨어 또는 소프트웨어, 또는 양자의 복합 구성에 의해 실행하는 것이 가능하다. 소프트웨어에 의한 처리를 실행하는 경우에는, 처리 시퀀스를 기록한 프로그램을, 전용 하드웨어에 내장된 컴퓨터 내의 메모리에 인스톨하여 실행시키거나, 또는 각종 처리가 실행 가능한 범용 컴퓨터에 프로그램을 인스톨하여 실행시키는 것이 가능하다. 예를 들어, 프로그램은 기록 매체에 미리 기록해둘 수 있다. 기록 매체로부터 컴퓨터에 인스톨하는 것 외에도, LAN(Local Area Network), 인터넷이라는 네트워크를 통해 프로그램을 수신하고, 내장된 하드 디스크 등의 기록 매체에 인스톨할 수 있다.
또한, 명세서에 기재된 각종 처리는, 기재에 따라서 시계열로 실행될 뿐만 아니라, 처리를 실행하는 장치의 처리 능력 또는 필요에 따라서 병렬적으로 또는 개별로 실행되어도 된다. 또한, 본 명세서에 있어서 시스템은, 복수 장치의 논리적 집합 구성이며, 각 구성의 장치의 동일 하우징 내에 있는 것에 제한되지는 않는다.
이상, 설명한 바와 같이, 본 개시의 일 실시예 구성에 의하면, 수신 장치에 있어서, 애플리케이션 단위 또는 프리젠테이션ㆍ유닛 단위의 캐시 처리를 실행시켜, 완성도가 높은 애플리케이션 실행 처리를 가능하게 하는 장치, 방법이 실현된다.
구체적으로는, 수신 장치가, 송신 장치로부터 애플리케이션의 데이터 사이즈인 애플리케이션 사이즈와, 애플리케이션 링크 정보, 또한 애플리케이션 구성 요소인 프리젠테이션ㆍ유닛(PU) 각각의 데이터 사이즈를 기록한 시그널링 데이터를 수신한다. 수신 장치는 캐시 사이즈와, 애플리케이션이나, PU 각각의 데이터 사이즈를 비교하여, 캐시 가능한 애플리케이션 또는 PU를 캐시 대상 데이터로서 결정하고, 애플리케이션 또는 PU 단위의 캐시 처리를 실행한다.
본 구성에 의해, 수신 장치에 있어서, 애플리케이션 단위 또는 프리젠테이션ㆍ유닛 단위의 캐시 처리를 실행시켜, 완성도가 높은 애플리케이션 실행 처리를 가능하게 하는 장치, 방법이 실현된다.
10: 통신 시스템
20: 송신 장치
21: 방송 서버
22: 광고 서버
23: 데이터 배신 서버
30: 수신 장치
31: TV
32: PC
33: 휴대 단말기
50: 시그널링 데이터
60: AV 세그먼트
70: 기타 데이터
110: 미들웨어
111: 통신부(PHY/MAC)
112: 시그널링 취득부
113: 시그널링 해석부
114: 세그먼트 취득부
120: HTTP프록시 서버
121: 캐시 제어부
122: 캐시부
130: 데이터 재생부
131: 재생 제어부
132: 애플리케이션 제어부
133: 출력 제어부
200: 애플리케이션
210: 프리젠테이션ㆍ유닛(PU)
211: HTML 파일
212: 데이터 파일
213: 링크
221: 엔트리 문서
450: 브라우저
451: 표시 처리부
452: 서비스 워커(SW)
453: 캐시
455, 456: 웹페이지
751: 데이터 처리부
752: 통신부
753: 기억부
771: 데이터 처리부
772: 통신부
773: 기억부
774: 입력부
775: 출력부
801: CPU
802: ROM
803: RAM
804: 버스
805: 입출력 인터페이스
806: 입력부
807: 출력부
808: 기억부
809: 통신부
810: 드라이브
811: 리무버블 미디어

Claims (21)

  1. 제1 시그널링 데이터를 수신하도록 구성된 통신부 - 상기 제1 시그널링 데이터는,
    복수의 애플리케이션의 링크 순서를 나타내는 링크 정보; 및
    각 애플리케이션에 대해, 대응 애플리케이션의 데이터 사이즈를 나타내는 애플리케이션 사이즈 정보를 포함함 -; 및
    처리부 - 상기 처리부는,
    수신 장치의 메모리에서 이용가능한 캐시 사이즈, 각 애플리케이션의 데이터 사이즈 및 상기 애플리케이션들의 링크 순서에 따라 애플리케이션들로부터 하나 이상의 캐시 대상 애플리케이션을 결정하고;
    상기 메모리에서 결정된 하나 이상의 캐시 대상 애플리케이션을 캐시하기 위해 캐시 처리를 실행하도록 구성됨 -
    를 포함하는 수신 장치.
  2. 제1항에 있어서, 상기 링크 정보는 링크처 애플리케이션 ID와 관련되어 기록된 링크원 애플리케이션 ID를 포함하고, 상기 링크원 애플리케이션 ID는 제1 애플리케이션을 사양화하고, 상기 링크처 애플리케이션 ID는 제2 애플리케이션을 사양화하고, 상기 제2 애플리케이션의 기동은 상기 제1 애플리케이션이 실행되는 동안 수행되고,
    각 애플리케이션의 데이터 사이즈는 대응 애플리케이션을 사양화하는 애플리케이션 ID와 관련되어 기록되고,
    상기 처리부는,
    상기 링크 정보로부터, 링크원 애플리케이션 ID와, 링크처 애플리케이션 ID를 취득하고;
    애플리케이션 사이즈 정보부터 상기 링크원 애플리케이션 ID에 의해 사양화된 제1 애플리케이션의 제1 데이터 사이즈 및 상기 링크처 애플리케이션 ID에 의해 사양화된 제2 애플리케이션의 제2 데이터 사이즈를 취득하고;
    상기 제1 데이터 사이즈 및 상기 제2 데이터 사이즈에 따라 상기 하나 이상의 캐시 대상 애플리케이션에서 상기 제1 애플리케이션 또는 상기 제2 애플리케이션을 포함할지를 결정하도록 더 구성되는, 수신 장치.
  3. 제1항에 있어서, 상기 처리부는,
    상기 애플리케이션들의 링크 순서에 따라 애플리케이션들로부터 초기 실행 애플리케이션을 최우선의 캐시 대상 애플리케이션으로서 선택하고,
    이어서, 상기 애플리케이션들의 링크 순서에 따라 상기 하나 이상의 캐시 대상 애플리케이션에서 상기 초기 실행 애플리케이션 후에 하나 이상의 다음 애플리케이션을 포함할지를 결정하도록 구성되는 수신 장치.
  4. 제2항에 있어서, 상기 애플리케이션들 중 특정 하나의 애플리케이션 ID는, 조직 ID와, 애플리케이션 본체 ID가 포함된 식별자인 수신 장치.
  5. 제1항에 있어서, 상기 제1 시그널링 데이터는, 애플리케이션의 정보를 기록한 애플리케이션ㆍ인포메이션ㆍ테이블(AIT: Application Information Table)인 수신 장치.
  6. 제1항에 있어서, 상기 통신부는,
    상기 제1시그널링 데이터를, 방송파를 통해 수신하도록 구성되는 수신 장치.
  7. 제1항에 있어서, 상기 애플리케이션들 중 하나는, 광고 출력 처리를 실행하는 애플리케이션인 수신 장치.
  8. 제1항에 있어서, 상기 통신부는, 제2 시그널링 데이터를 수신하도록 더 구성되고, 상기 제2 시그널링 데이터는, 상기 애플리케이션들로부터 특정 애플리케이션의 구성 요소인 프리젠테이션ㆍ유닛의 각각에 대해, 대응하는 프리젠테이션ㆍ유닛의 데이터 사이즈를 나타내는 프리젠테이션ㆍ유닛의 데이터 사이즈 정보를 포함하고,
    상기 처리부는, 특정 애플리케이션을 저장하기에 불충분한 캐시 사이즈에 응답하여:
    각 프리젠테이션ㆍ유닛의 캐시 사이즈 및 데이터 사이즈에 따라 하나 이상의 캐시 대상 프리젠테이션ㆍ유닛을 결정하고;
    상기 메모리에서 결정된 하나 이상의 캐시 대상 프리젠테이션ㆍ유닛을 캐시하기 위해 캐시 처리를 실행하도록 더 구성되는 수신 장치.
  9. 제8항에 있어서, 상기 프리젠테이션ㆍ유닛들 중 적어도 하나는,
    하나 또는 복수의 HTML(HyperText Markup Language) 문서와, 해당 HTML 문서를 적용하여 출력되는 데이터 파일에 의해 구성되는 데이터의 집합인 수신 장치.
  10. 제8항에 있어서, 상기 제2 시그널링 데이터는, 링크처 프리젠테이션ㆍ유닛 ID와 관련되어 기록된 링크원 프리젠테이션ㆍ유닛 ID를 나타내는 프리젠테이션ㆍ유닛 링크 정보를 포함하고,
    각 프리젠테이션ㆍ유닛의 데이터 사이즈는 대응하는 프리젠테이션ㆍ유닛을 사양화하는 프리젠테이션ㆍ유닛 ID와 관련되어 기록되고,
    상기 처리부는,
    상기 프리젠테이션ㆍ유닛 링크 정보로부터 상기 링크원 프리젠테이션ㆍ유닛 ID와 상기 링크처 프리젠테이션ㆍ유닛 ID를 취득하고;
    프리젠테이션ㆍ유닛 사이즈 정보로부터 상기 링크원 프리젠테이션ㆍ유닛 ID에 의해 사양화된 제1 프리젠테이션ㆍ유닛의 제3 데이터 사이즈 및 상기 링크처 프리젠테이션ㆍ유닛 ID에 의해 사양화된 제2 프리젠테이션ㆍ유닛의 제4 데이터 사이즈를 취득하고;
    상기 제3 데이터 사이즈 및 제4 데이터 사이즈에 따라 하나 이상의 캐시 대상 프리젠테이션ㆍ유닛에서 상기 제1 프리젠테이션ㆍ유닛 또는 상기 제2 프리젠테이션ㆍ유닛을 포함하는지를 결정하도록 더 구성되는 수신 장치.
  11. 제8항에 있어서, 상기 처리부는,
    상기 프리젠테이션ㆍ유닛들 중 엔트리 문서를 포함하는 초기 프리젠테이션ㆍ유닛을 최우선의 캐시 대상 프리젠테이션ㆍ유닛으로서 선택하고,
    이어서, 프리젠테이션ㆍ유닛의 링크 순서에 따라서, 하나 이상의 캐시 대상 프리젠테이션ㆍ유닛에서 초기 프리젠테이션ㆍ유닛 이후 하나 이상의 다음 프리젠테이션ㆍ유닛을 포함할지를 결정하도록 더 구성되는 수신 장치.
  12. 제10항에 있어서, 상기 프리젠테이션ㆍ유닛들 중 특정 하나의 프리젠테이션ㆍ유닛 ID는, 특정 애플리케이션을 사양화하는 애플리케이션 본체 ID와, 프리젠테이션ㆍ유닛들 중 특정 하나를 사양화하는 그룹 ID를 포함하는 수신 장치.
  13. 제8항에 있어서, 상기 제2 시그널링 데이터는, 특정 애플리케이션에 대응하는 프리젠테이션ㆍ유닛에 포함되는 파일 단위의 정보가 기록되는 S-TSID인 수신 장치.
  14. 제8항에 있어서, 상기 제2 시그널링 데이터에는, 프리젠테이션ㆍ유닛에 포함되는 파일 단위의 정보가 기록되고,
    각 정보에는, 프리젠테이션ㆍ유닛들 중 특정 하나를 사양화하는 대응 파일 및 대응 그룹 ID가 관련되어 기록되며,
    상기 처리부는, 그룹 ID에 기초하여, 캐시 대상 파일의 선택 처리를 실행하는 수신 장치.
  15. 제8항에 있어서, 상기 통신부는,
    상기 제2 시그널링 데이터를, 방송파를 통해 수신하도록 구성되는 수신 장치.
  16. 애플리케이션 구성 데이터를 포함하는 제1 패킷과 제1 시그널링 데이터를 포함하는 제2 패킷을 생성하도로 구성되는 처리부 - 상기 제1 시그널링 데이터는,
    복수의 애플리케이션의 링크 순서를 나타내는 링크 정보, 및
    각 애플리케이션에 대해, 대응 애플리케이션의 데이터 사이즈를 나타내는 애플리케이션 사이즈 정보를 포함함 -; 및
    상기 제1 패킷 및 제2 패킷을 송신하도록 구성되는 통신부
    를 포함하는 송신 장치.
  17. 제16항에 있어서, 상기 처리부는 제2 시그널링 데이터를 포함하는 제3 패킷을 생성하도록 더 구성되고, 상기 제2 시그널링 데이터는,
    상기 애플리케이션들로부터 특정 애플리케이션의 구성 요소인 프리젠테이션ㆍ유닛 각각에 대해, 대응하는 프리젠테이션ㆍ유닛의 데이터 사이즈를 나타내는 프리젠테이션ㆍ유닛 데이터 사이즈, 및
    프리젠테이션ㆍ유닛의 액세스 순서를 나타내는 프리젠테이션ㆍ유닛 링크 정보를 포함하고,
    상기 통신부는, 제3 패킷을 송신하도록 구성되는 송신 장치.
  18. 제17항에 있어서, 상기 프리젠테이션ㆍ유닛들 중 적어도 하나는,
    하나 또는 복수의 HTML(HyperText Markup Language) 문서와, 해당 HTML 문서를 적용하여 출력되는 데이터 파일에 의해 구성되는 데이터의 집합인 송신 장치.
  19. 수신 장치에 의해 실행되는 데이터 처리 방법이며,
    상기 수신 장치의 통신부가, 제1 시그널링 데이터를 수신하는 단계 - 상기 제1 시그널링 데이터는,
    복수의 애플리케이션의 링크 순서를 나타내는 링크 정보; 및
    각 애플리케이션에 대해, 대응 애플리케이션의 데이터 사이즈를 나타내는 애플리케이션 사이즈 정보를 포함함 -;
    상기 수신 장치의 처리부가, 상기 수신 장치의 메모리에서 이용가능한 캐시 사이즈, 각 애플리케이션의 데이터 사이즈 및 애플리케이션들의 링크 순서에 따라 애플리케이션들로부터 하나 이상의 캐시 대상 애플리케이션을 결정하는 단계; 및
    상기 수신 장치의 처리부가, 상기 메모리에서 결정된 하나 이상의 대상 애플리케이션을 캐시하기 위해 캐시 처리를 실행하는 단계
    를 포함하는 데이터 처리 방법.
  20. 송신 장치에 의해 실행되는 데이터 처리 방법이며,
    상기 송신 장치의 처리부가, 애플리케이션 구성 데이터를 포함하는 제1 패킷과, 제1 시그널링 데이터를 포함하는 제2 패킷을 생성하는 단계 - 상기 제1 시그널링 데이터는,
    복수의 애플리케이션의 링크 순서를 나타내는 링크 정보와,
    각 애플리케이션에 대해, 대응 애플리케이션의 데이터 사이즈를 나타내는 애플리케이션 사이즈 정보를 포함함 -;
    상기 송신 장치의 통신부가, 상기 제1 패킷 및 제2 패킷을 송신하는 단계
    를 포함하는 데이터 처리 방법.
  21. 제19항에 있어서,
    제2 시그널링 데이터를 수신하는 단계 - 상기 제2 시그널링 데이터는,
    애플리케이션들로부터 특정 애플리케이션의 구성 요소인 각 프리젠테이션ㆍ유닛에 대해, 대응 프리젠테이션ㆍ유닛의 데이터 사이즈를 나타내는 프리젠테이션ㆍ유닛 데이터 사이즈 정보와,
    프리젠테이션ㆍ유닛의 액세스 순서를 나타내는 프리젠테이션ㆍ유닛 링크 정보를 포함함 -;
    특정 애플리케이션을 저장하기에 불충분한 캐시 사이즈에 응답하여:
    각 프리젠테이션ㆍ유닛의 캐시 사이즈, 데이터 사이즈 및 프리젠테이션ㆍ유닛의 액세스 순서에 따라 하나 이상의 캐시 대상 프리젠테이션ㆍ유닛을 결정하는 단계; 및
    상기 메모리에서 결정된 하나 이상의 캐시 대상 프리젠테이션ㆍ유닛을 캐시하도록 캐시 처리를 실행하는 단계
    를 더 포함하는 데이터 처리 방법.
KR1020177036843A 2015-07-23 2016-07-04 수신 장치, 송신 장치 및 데이터 처리 방법 KR102611253B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2015145494 2015-07-23
JPJP-P-2015-145494 2015-07-23
PCT/JP2016/069752 WO2017014034A1 (ja) 2015-07-23 2016-07-04 受信装置、送信装置、およびデータ処理方法

Publications (2)

Publication Number Publication Date
KR20180034332A KR20180034332A (ko) 2018-04-04
KR102611253B1 true KR102611253B1 (ko) 2023-12-08

Family

ID=57833882

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020177036843A KR102611253B1 (ko) 2015-07-23 2016-07-04 수신 장치, 송신 장치 및 데이터 처리 방법

Country Status (8)

Country Link
US (1) US10820041B2 (ko)
EP (1) EP3327576A4 (ko)
JP (1) JPWO2017014034A1 (ko)
KR (1) KR102611253B1 (ko)
CN (1) CN107851072B (ko)
CA (1) CA2987903A1 (ko)
MX (1) MX2018000649A (ko)
WO (1) WO2017014034A1 (ko)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10938878B2 (en) * 2017-05-16 2021-03-02 Red Hat, Inc. Separate cache servers for storing objects in different dedicated size ranges
CN110891246B (zh) * 2018-09-11 2022-07-05 成都鼎桥通信技术有限公司 一种组播媒体数据的处理方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060080474A1 (en) * 2002-10-09 2006-04-13 Matsushita Electric Industrial Co., Ltd. Information processor
US20070174356A1 (en) * 2004-02-10 2007-07-26 Matsushita Electric Industrial Co., Ltd. Program execution device, program execution method, and program
US20140075472A1 (en) * 2011-05-20 2014-03-13 Nippon Hoso Kyokai Cooperative communication/broadcasting system, application management server, receiver, reception method for receiver, and application management method for application management server
WO2014057833A1 (ja) * 2012-10-10 2014-04-17 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、及び、プログラム
US20160182977A1 (en) 2014-12-19 2016-06-23 Telefonaktiebolaget L M Ericsson (Publ) User interaction with advertisements on hybrid terminals

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8347343B2 (en) 2008-11-18 2013-01-01 Lg Electronics Inc. Method for receiving a broadcast signal
JP2011087103A (ja) 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供
JP6043089B2 (ja) * 2011-05-20 2016-12-14 日本放送協会 放送通信連携受信装置
US9838741B2 (en) * 2011-08-10 2017-12-05 Lg Electronics Inc. Method for transmitting broadcast service, method for receiving broadcast service, and apparatus for receiving broadcast service
US9288554B2 (en) * 2011-09-23 2016-03-15 Lg Electronics Inc. Method for receiving broadcast service and reception device thereof
CN103988210B (zh) * 2011-12-21 2018-04-03 索尼公司 信息处理设备、服务器设备、信息处理方法、以及服务器处理方法
MX2013014956A (es) * 2012-05-10 2014-02-27 Sony Corp Dispositivo de recepcion, metodo de recepcion, dispositivo de transmision, metodo de transmision y programa.
US9154840B2 (en) * 2012-07-31 2015-10-06 Sony Corporation Reception apparatus, reception method, transmission apparatus, and transmission method
JP6348251B2 (ja) 2012-09-13 2018-06-27 サターン ライセンシング エルエルシーＳａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ 端末装置、受信方法、およびプログラム
CN103905147B (zh) * 2012-12-28 2017-03-22 联芯科技有限公司 数据处理方法、发送设备、接收设备和通信系统
JP6118243B2 (ja) 2013-12-27 2017-04-19 日立マクセル株式会社 放送受信装置及び携帯情報端末
WO2015104743A1 (ja) 2014-01-07 2015-07-16 ソニー株式会社 情報処理装置および情報処理方法
JP5725235B1 (ja) 2014-04-22 2015-05-27 ソニー株式会社 受信装置及び受信方法、並びに、送信装置及び送信方法
JP5725242B1 (ja) 2014-06-04 2015-05-27 ソニー株式会社 送信装置及び送信方法、並びに受信装置並びに受信方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060080474A1 (en) * 2002-10-09 2006-04-13 Matsushita Electric Industrial Co., Ltd. Information processor
US20070174356A1 (en) * 2004-02-10 2007-07-26 Matsushita Electric Industrial Co., Ltd. Program execution device, program execution method, and program
US20140075472A1 (en) * 2011-05-20 2014-03-13 Nippon Hoso Kyokai Cooperative communication/broadcasting system, application management server, receiver, reception method for receiver, and application management method for application management server
WO2014057833A1 (ja) * 2012-10-10 2014-04-17 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、及び、プログラム
US20160182977A1 (en) 2014-12-19 2016-06-23 Telefonaktiebolaget L M Ericsson (Publ) User interaction with advertisements on hybrid terminals

Also Published As

Publication number Publication date
US20180124454A1 (en) 2018-05-03
WO2017014034A1 (ja) 2017-01-26
CN107851072B (zh) 2021-03-12
EP3327576A4 (en) 2018-12-12
MX2018000649A (es) 2018-04-24
US10820041B2 (en) 2020-10-27
CN107851072A (zh) 2018-03-27
KR20180034332A (ko) 2018-04-04
EP3327576A1 (en) 2018-05-30
CA2987903A1 (en) 2017-01-26
JPWO2017014034A1 (ja) 2018-05-10

Similar Documents

Publication Publication Date Title
JP6583281B2 (ja) 受信装置、送信装置、およびデータ処理方法
CN109937575A (zh) 中断经不可侵犯清单协议提供的流传输内容的系统和方法
US11410199B2 (en) Reception apparatus, transmission apparatus, and data processing method
KR102499231B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
US11115335B2 (en) Information processing device and information processing method
US11025352B2 (en) Reception device, transmission device, and data processing method
US20160294903A1 (en) Method and device for pushing resources to mobile communication terminal by smart television
KR102460356B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
KR102611253B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
KR102460444B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
JP6597604B2 (ja) 受信装置、送信装置、データ通信方法、およびデータ処理方法

Legal Events

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