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

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

Info

Publication number
KR20170074874A
KR20170074874A KR1020177010488A KR20177010488A KR20170074874A KR 20170074874 A KR20170074874 A KR 20170074874A KR 1020177010488 A KR1020177010488 A KR 1020177010488A KR 20177010488 A KR20177010488 A KR 20177010488A KR 20170074874 A KR20170074874 A KR 20170074874A
Authority
KR
South Korea
Prior art keywords
service
data
token
receiving apparatus
processing
Prior art date
Application number
KR1020177010488A
Other languages
English (en)
Other versions
KR102460099B1 (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 KR20170074874A publication Critical patent/KR20170074874A/ko
Application granted granted Critical
Publication of KR102460099B1 publication Critical patent/KR102460099B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/14—Arrangements for conditional access to broadcast information or to broadcast-related services
    • H04H60/15—Arrangements for conditional access to broadcast information or to broadcast-related services on receiving information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/13—Arrangements for device control affected by the broadcast information
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/907—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86—Arrangements characterised by the broadcast information itself
    • H04H20/91—Arrangements characterised by the broadcast information itself broadcasting computer programmes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/35—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
    • H04H60/45—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying users
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9566—URL specific, e.g. using aliases, detecting broken or misspelled links
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H40/00—Arrangements specially adapted for receiving broadcast information
    • H04H40/18—Arrangements characterised by circuits or components specially adapted for receiving
    • H04H40/27—Arrangements characterised by circuits or components specially adapted for receiving specially adapted for broadcast systems covered by groups H04H20/53 - H04H20/95

Abstract

각각의 수신 장치에 최적화된 데이터 관리를 실행하는 서비스 워커(SW)의 선택 취득 및 이용 처리를 가능하게 하는 장치, 방법을 제공한다. 수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)로부터, 특정 클래스의 SW를 선택 취득하여 이용 가능하게 하였다. 예를 들어, 수신 장치에 있어서의 애플리케이션 이용 상황에 따라 선택되는 클래스 대응의 SW의 이용을 실현한다. 수신 장치는, 특정 클래스의 SW의 액세스 정보를 효율적으로 검색 가능하게 하기 위한 토큰을 기록한 시그널링 데이터를 이용하여 특정 클래스의 SW의 액세스 정보를 취득하여 SW를 취득한다.

Description

수신 장치, 송신 장치 및 데이터 처리 방법 {RECEPTION DEVICE, TRANSMISSION DEVICE, AND DATA PROCESSING METHOD}
본 개시는 수신 장치, 송신 장치 및 데이터 처리 방법에 관한 것이다. 더욱 상세하게는, 예를 들어 방송파나 네트워크를 통한 데이터의 송신 또는 수신을 실행하는 수신 장치, 송신 장치, 및 통신 데이터에 대한 데이터 처리 방법에 관한 것이다.
방송국이나 콘텐츠 서버 등, 콘텐츠를 제공하는 송신 장치로부터, 텔레비전, PC, 휴대 단말기 등의 수신 장치에 대하여, 방송파 등에 의한 일방향 통신, 혹은 인터넷 등의 네트워크를 통한 쌍방향 통신, 일방향 통신에 의해, 방송 프로그램 등의 콘텐츠를 송수신하는 시스템에 대한 개발이나 규격화가, 현재 활발하게 진행되고 있다.
또한, 방송파 및 네트워크를 통한 데이터 배신을 실현하기 위한 기술을 개시한 종래 기술로서, 예를 들어 특허문헌 1(일본 특허 공개 제2014-057227호 공보)이 있다.
방송파 및 네트워크를 통한 데이터 배신 시스템에 관한 규격의 하나로서 ATSC(Advanced Television System Committe) 3.0의 규격화가 진행되고 있다.
ATSC 3.0에서는, 다운로드형의 애플리케이션 배신 관리용 패키징 방식, 그리고 오프라인의 애플리케이션 등록ㆍ갱신 관리 방식이 아직 검토 단계에 있다.
한편, WWW(World Wide Web) 이용 기술의 국제적 표준화 단체인 W3C(World Wide Web Consortium)는, 클라이언트에 있어서의 편리한 애플리케이션의 이용을 실현하기 위해 이용하는 제어 프로그램 등을 포함하는 서비스 워커(SW: Service Worker)의 사양을 책정 중이다.
이 서비스 워커(SW)의 프레임워크를, 방송 콘텐츠의 수신 장치인 클라이언트에 있어서 유효하게 이용하는 것을 실현하기 위해서는, 방송 배신되는 애플리케이션 파츠나, 서비스 워커(SW) 자체의 배신 관리를 효과적으로 실장할 수 있도록 하는 것이 과제가 된다.
일본 특허 공개 제2014-057227호 공보
본 개시는, 상술한 서비스 워커(SW)의 프레임워크를, 방송 콘텐츠의 수신 장치인 클라이언트에 있어서 유효하게 이용하는 것을 실현하는 수신 장치, 송신 장치 및 데이터 처리 방법을 제공하는 것을 목적으로 한다.
또한, 구체적으로는, 수신 장치(클라이언트)의 실행 환경이나 기억 용량 등의 각종 리소스의 제약을 고려하여, 수신 장치측의 유저의 기호 정보나, 기억 영역 용량 외 런타임 환경 제약, 로컬 네트워크 부하 등의 여러 가지 클라이언트 환경 속성을 참조함으로써, 미세한 캐시 대상인 애플리케이션(파츠)의 캐시 제어를 실현하는 수신 장치, 송신 장치 및 데이터 처리 방법을 제공하는 것을 목적으로 한다.
본 개시의 제1 측면은,
수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)로부터, 특정 클래스의 서비스 워커(SW)를 선택 취득하여 이용하는 데이터 처리부를 갖는 수신 장치에 있다.
또한, 본 개시의 제2 측면은,
수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)를 송신하는 송신 장치에 있다.
또한, 본 개시의 제3 측면은,
수신 장치에 있어서 실행하는 데이터 처리 방법이며,
상기 수신 장치의 데이터 처리부가, 수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)로부터, 특정 클래스의 서비스 워커(SW)를 선택 취득하여 이용하는 데이터 처리 방법에 있다.
또한, 본 개시의 제4 측면은,
송신 장치에 있어서 실행하는 데이터 처리 방법이며,
수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)를 송신하는 데이터 처리 방법에 있다.
본 개시의 또 다른 목적, 특징이나 이점은, 후술하는 본 개시의 실시예나 첨부하는 도면에 기초한 보다 상세한 설명에 의해 밝혀질 것이다. 또한, 본 명세서에 있어서 시스템이란, 복수의 장치의 논리적 집합 구성이며, 각 구성의 장치가 동일 하우징 내에 있는 것에 제한되지는 않는다.
본 개시의 일 실시예의 구성에 따르면, 각각의 수신 장치에 최적화된 데이터 관리를 실행하는 서비스 워커(SW)의 선택 취득 및 이용 처리를 가능하게 하는 장치, 방법이 실현된다.
구체적으로는, 예를 들어 수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)로부터, 특정 클래스의 SW를 선택 취득하여 이용 가능하게 하였다. 예를 들어, 수신 장치에 있어서의 애플리케이션 이용 상황에 따라 선택되는 클래스 대응의 SW의 이용을 실현한다. 수신 장치는, 특정 클래스의 SW의 액세스 정보를 효율적으로 검색 가능하게 하기 위한 토큰을 기록한 시그널링 데이터를 이용하여 특정 클래스의 SW의 액세스 정보를 취득하여 SW를 취득한다.
본 구성에 의해, 각각의 수신 장치에 최적화된 데이터 관리를 실행하는 서비스 워커(SW)의 선택 취득 및 이용 처리를 가능하게 하는 장치, 방법이 실현된다.
또한, 본 명세서에 기재된 효과는 어디까지나 예시이지 한정되는 것은 아니며, 또한 부가적인 효과가 있어도 된다.
도 1은 본 개시의 처리를 실행하는 통신 시스템의 일 구성예에 대하여 설명하는 도면이다.
도 2는 송신 장치의 송신 데이터에 대하여 설명하는 도면이다.
도 3은 송신 장치 및 수신 장치의 프로토콜 스택의 예를 도시하는 도면이다.
도 4는 서비스 워커(SW)를 이용한 처리의 구체예(사용례)에 대하여 설명하는 도면이다.
도 5는 서비스 워커(SW)를 이용한 처리의 구체예(사용례)에 대하여 설명하는 도면이다.
도 6은 서비스 워커(SW)를 이용한 처리의 일례를 설명하는 도면이다.
도 7은 수신 장치의 구성예에 대하여 설명하는 도면이다.
도 8은 애플리케이션의 취득 및 실행, 또한 서비스 워커(SW)의 취득과 등록 처리의 시퀀스에 대하여 설명하는 도면이다.
도 9는 애플리케이션의 취득 및 실행, 또한 서비스 워커(SW)의 취득과 등록 처리의 시퀀스에 대하여 설명하는 도면이다.
도 10은 애플리케이션의 취득 및 실행, 또한 서비스 워커(SW)의 취득과 등록 처리의 시퀀스에 대하여 설명하는 도면이다.
도 11은 토큰을 이용한 데이터 취득 처리 시퀀스에 대하여 설명하는 도면이다.
도 12는 토큰을 이용한 데이터 취득 처리 시퀀스에 대하여 설명하는 도면이다.
도 13은 시그널링 데이터(메타데이터)의 구성예에 대하여 설명하는 도면이다.
도 14는 시그널링 데이터(메타데이터)의 구성예에 대하여 설명하는 도면이다.
도 15는 시그널링 데이터(메타데이터)에 대한 토큰 설정예에 대하여 설명하는 도면이다.
도 16은 시그널링 데이터(메타데이터)에 대한 토큰 설정예에 대하여 설명하는 도면이다.
도 17은 시그널링 데이터(메타데이터)에 대한 토큰 설정예에 대하여 설명하는 도면이다.
도 18은 서비스 워커(SW)의 갱신 처리 시퀀스에 대하여 설명하는 도면이다.
도 19는 서비스 워커(SW)의 갱신 처리 시퀀스에 대하여 설명하는 도면이다.
도 20은 서비스 워커(SW)에 의한 수신 장치의 기억부(영속 캐시)의 제어 처리 시퀀스에 대하여 설명하는 도면이다.
도 21은 서비스 워커(SW)에 의한 수신 장치의 기억부(영속 캐시)의 제어 처리 시퀀스에 대하여 설명하는 도면이다.
도 22는 푸시형 토큰 적용 데이터 선택 취득 처리 시퀀스에 대하여 설명하는 도면이다.
도 23은 푸시형 토큰 적용 데이터 선택 취득 처리 시퀀스에 대하여 설명하는 도면이다.
도 24는 푸시형 처리에 있어서의 서비스 워커 갱신 처리 시퀀스에 대하여 설명하는 도면이다.
도 25는 송신 장치로부터 송신되는 시그널링 데이터(메타데이터)의 구성예를 도시하는 도면이다.
도 26은 서비스 프래그먼트(Service Fragment)의 구성예에 대하여 설명하는 도면이다.
도 27은 USD(유저 서비스 디스크립션)의 전체 구성예에 대하여 설명하는 도면이다.
도 28은 시그널링 데이터를 구성하는 USD(유저 서비스 번들 디스크립션) 이하의 계층 구성예를 도시하는 도면이다.
도 29는 스케줄 디스크립션(Schedule Description) 요소 이하의 시그널링 데이터 구성을 도시하는 도면이다.
도 30은 필터 디스크립션 레퍼런스(filter Description Reference)에 의해 특정되는 필터 디스크립션(filter Description) 요소의 데이터 구성에 대하여 설명하는 도면이다.
도 31은 시그널링 데이터를 구성하는 USD(유저 서비스 번들 디스크립션) 이하의 계층 구성예를 도시하는 도면이다.
도 32는 파일 전송을 FLUTE 프로토콜에 따라 실행하는 경우에, 딜리버리 메소드(deliveryMethod) 요소에 설정되는 FLUTE에 대한 참조 정보의 예를 도시하는 도면이다.
도 33은 파일 전송을 FLUTE 프로토콜에 따라 실행하는 경우에, 딜리버리 메소드(deliveryMethod) 요소에 설정되는 FLUTE에 대한 참조 정보의 예를 도시하는 도면이다.
도 34는 파일 전송을 ROUTE 프로토콜에 따라 실행하는 경우에, 딜리버리 메소드(deliveryMethod) 요소에 설정되는 FLUTE에 대한 참조 정보의 예를 도시하는 도면이다.
도 35는 파일 전송을 ROUTE 프로토콜에 따라 실행하는 경우에, 딜리버리 메소드(deliveryMethod) 요소에 설정되는 FLUTE에 대한 참조 정보의 예를 도시하는 도면이다.
도 36은 FDT-Instance 요소의 속성, 혹은 File 요소의 속성에 토큰을 기록하는 구성에 대하여 설명하는 도면이다.
도 37은 FDT 인스턴스 대응의 애트리뷰트(속성)(Attribute)와, 파일 대응의 애트리뷰트(속성)(Attribute)의 상세 구성을 설명하는 도면이다.
도 38은 ROUTE로 규정하고 있는 LSID 이하의 데이터 구성을 도시하는 도면이다.
도 39는 EFDT 요소 단위의 애트리뷰트(속성)(Attribute) 데이터 요소, 파일(File) 단위의 애트리뷰트(속성)(Attribute) 데이터 요소의 상세에 대하여 설명하는 도면이다.
도 40은 서비스 워커(SW)에 의한 수신 장치의 기억부(영속 캐시)의 제어 처리 시퀀스에 대하여 설명하는 도면이다.
도 41은 서비스 워커(SW)에 의한 수신 장치의 기억부(영속 캐시)의 제어 처리 시퀀스에 대하여 설명하는 도면이다.
도 42는 통신 장치인 송신 장치와 수신 장치의 구성예에 대하여 설명하는 도면이다.
도 43은 통신 장치인 송신 장치와 수신 장치의 하드웨어 구성예에 대하여 설명하는 도면이다.
이하, 도면을 참조하면서 본 개시의 수신 장치, 송신 장치 및 데이터 처리 방법의 상세에 대하여 설명한다. 또한, 설명은 이하의 항목에 따라 행한다.
1. 통신 시스템의 구성예에 대하여
2. 데이터 통신 프로토콜 FLUTE 및 ROUTE에 대하여
3. 송신 장치와 수신 장치가 실행하는 통신 처리예에 대하여
4. 서비스 워커(SW)에 대하여
5. 수신 장치에 있어서의 애플리케이션의 취득 및 실행예에 대하여
6. 서비스 워커(SW)의 클래스 분류와, 클래스 분류된 서비스 워커(SW)의 선택 취득용 정보의 통지(시그널링) 처리에 대하여
7. 서비스 워커(SW)의 배신과 캐시 제어 처리에 대하여(폴링형의 처리예)
7.1. 방송 스트림 부수 애플리케이션으로부터의 서비스 워커(SW)의 취득, 등록 처리에 대하여
7.2. 서비스 워커(SW)에 대한 클래스 설정에 대하여
7.3. 토큰을 적용하여 특정 클래스의 서비스 워커(SW)의 취득 처리를 효율화한 구성에 대하여
7.4. 서비스 워커(SW)의 갱신 처리에 대하여
7.5. 서비스 워커(SW)에 의한 수신 장치의 기억부(영속 캐시)의 제어 처리에 대하여
8. 서비스 워커(SW)의 배신과 캐시 제어 처리에 대하여(푸시형의 처리예)
8.1. 방송 스트림 부수 애플리케이션으로부터의 서비스 워커(SW)의 취득, 등록 처리에 대하여
8.2. 토큰을 적용하여 수신 장치의 데이터 취득 처리를 효율화한 구성에 대하여
8.3. 서비스 워커(SW)의 갱신 처리에 대하여
8.4. 서비스 워커(SW)에 의한 수신 장치의 기억부(영속 캐시)의 제어 처리에 대하여
9. 토큰을 기술하는 시그널링 데이터(메타데이터)의 구성에 대하여
9.1. 시그널링 데이터(메타데이터)를 구성하는 OMA-ESG에 대한 토큰 기록예에 대하여
9.2. 시그널링 데이터(메타데이터)를 구성하는 USD에 대한 토큰 기록예에 대하여
9.3. 시그널링 데이터(메타데이터)를 구성하는 FLUTE(ROUTE) 파라미터 레이어에 대한 토큰 기록예에 대하여
10. 서비스 워커(SW)가 이용 가능한 API에 의한 캐싱의 최적화 처리예에 대하여
11. 송신 장치와 수신 장치의 구성예에 대하여
12. 본 개시의 구성의 정리
[1. 통신 시스템의 구성예에 대하여]
우선, 도 1을 참조하여 본 개시의 처리를 실행하는 통신 시스템의 일 구성예에 대하여 설명한다.
도 1에 도시하는 바와 같이, 통신 시스템(10)은, 화상 데이터나 음성 데이터 등의 콘텐츠를 송신하는 통신 장치인 송신 장치(20)와, 송신 장치(20)가 송신하는 콘텐츠를 수신하는 통신 장치인 수신 장치(30)를 갖는다.
송신 장치(20)는, 구체적으로는, 예를 들어 방송국(21)이나 콘텐츠 서버(22) 등, 콘텐츠를 제공하는 측의 장치이다.
한편, 수신 장치(30)는, 일반 유저의 클라이언트 장치이며, 구체적으로는, 예를 들어 텔레비전(31), PC(32), 휴대 단말기(33) 등에 의해 구성된다.
송신 장치(20)와 수신 장치(30) 사이의 데이터 통신은, 인터넷 등의 네트워크를 통한 쌍방향 통신, 일방향 통신, 혹은 방송파 등에 의한 일방향 통신의 적어도 어느 것, 혹은 양자를 이용한 통신으로서 행해진다.
송신 장치(20)로부터 수신 장치(30)에 대한 콘텐츠 송신은, 예를 들어 어댑티브(적응형) 스트리밍 기술의 규격인 MPEG-DASH 규격에 따라 실행된다.
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)에 의해 구성된다.
한편, 시그널링 데이터(50)는, 프로그램표 등의 프로그램 예정 정보나, 프로그램 취득에 필요한 어드레스 정보(URL(Uniform Resource Locator) 등), 나아가 콘텐츠의 재생 처리에 필요한 정보, 예를 들어 코덱 정보(부호화 방식 등) 등을 포함하는 안내 정보, 제어 정보에 의해 구성된다.
수신 장치(30)는, 이 시그널링 데이터(50)를, 재생 대상으로 되는 프로그램 콘텐츠를 저장한 AV 세그먼트(60)의 수신에 선행하여 수신하는 것이 필요하게 된다.
이 시그널링 데이터(50)는, 예를 들어 XML(Extensible Markup Language) 형식의 데이터로서, 스마트폰이나 텔레비전 등의 유저 단말기인 수신 장치(클라이언트)에 송신된다.
전술한 바와 같이, 시그널링 데이터는 수시로 반복하여 송신된다. 예를 들어 100msec마다 등, 빈번하게 반복 송신된다.
이것은, 수신 장치(클라이언트)가 언제라도 바로 시그널링 데이터를 취득하는 것을 가능하게 하기 위해서이다.
클라이언트(수신 장치)는, 수시로, 수신 가능한 시그널링 데이터에 기초하여, 필요한 프로그램 콘텐츠의 액세스용 어드레스의 취득이나, 코덱 설정 처리 등, 프로그램 콘텐츠의 수신 및 재생에 필요한 처리를 지체없이 실행하는 것이 가능하게 된다.
그 밖의 데이터(70)는, 예를 들어 ESG(Electronic Service Guide), NRT 콘텐츠 등이 포함된다.
ESG는, 전자 서비스 가이드(Electronic Service Guide)이며, 예를 들어 프로그램표 등의 안내 정보이다.
NRT 콘텐츠는 논 리얼타임형 콘텐츠이다.
NRT 콘텐츠에는, 예를 들어 클라이언트인 수신 장치(30)의 브라우저 상에서 실행되는 여러 가지 애플리케이션 파일, 동화상, 정지 화상 등의 데이터 파일 등이 포함된다.
후술하는 애플리케이션 등의 제어 프로그램으로서 이용되는 서비스 워커(Service Worker)도, NRT 콘텐츠에 포함된다.
도 2에 도시하는 이하의 데이터, 즉
(a) 시그널링 데이터(50)
(b) AV 세그먼트(60)
(c) 그 밖의 데이터(ESG, NRT 콘텐츠 등)(70)
이들 데이터는, 예를 들어 데이터 통신 프로토콜: FLUTE(File Delivery over Uni-directional Transport)에 따라 송신된다.
[2. 데이터 통신 프로토콜 FLUTE 및 ROUTE에 대하여]
데이터 통신 프로토콜: FLUTE(File Delivery over Uni-directional Transport)는 멀티캐스트에 의해 전송하는 콘텐츠의 세션 관리를 행하는 프로토콜이다.
예를 들어 송신 장치인 서버측에서 생성되는 파일(URL과 버전으로 식별됨)은, FLUTE 프로토콜에 따라, 수신 장치인 클라이언트에 송신된다.
수신 장치(클라이언트)(30)는, 예를 들어 수신 장치(클라이언트)(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이 있다. 이 ATSC 3.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))
또한, (2) IP 멀티캐스트 레이어(IP Multicast)의 상위 레이어로서 Signaling(시그널링) 레이어가 설정된다.
시그널링 레이어는, 앞서 도 2를 참조하여 설명한 시그널링 데이터(50)의 송수신에 적용되는 레이어이다. 시그널링 데이터에는, 프로그램표 등의 프로그램 예정 정보나, 프로그램 취득에 필요한 어드레스 정보(URL 등), 나아가 콘텐츠의 재생 처리에 필요한 정보, 예를 들어 코덱 정보(부호화 방식 등) 등을 포함하는 안내 정보, 제어 정보 등이 포함된다.
또한, (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 컴포넌트의 조합에 의해 구성된다.
(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 콘텐츠에는, 예를 들어 클라이언트인 수신 장치의 브라우저 상에서 실행되는 여러 가지 애플리케이션 파일, 동화상, 정지 화상 등의 데이터 파일 등이 포함된다. 또한, 후술하는 애플리케이션 등의 제어 프로그램으로서 이용되는 서비스 워커(Service Worker(SW))도, 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에 의해 기술할 수도 있다.
[4. 서비스 워커(SW)에 대하여]
이어서, 송신 장치(서버)(20)가 제공하고, 주로 수신 장치(클라이언트)(30)에 있어서 이용되는 서비스 워커(SW: Service Worker)에 대하여 설명한다.
서비스 워커(SW)는, 방송 서버(21)나, 데이터 배신 서버(22) 등의 송신 장치(20)로부터 수신 장치로 제공된다.
서비스 워커(SW)는, 수신 장치(클라이언트)(30)에 있어서 실행되는 애플리케이션(=애플리케이션 프로그램)이나, 애플리케이션의 실행 시에 이용되는 데이터 파일 등의 취득 처리나, 기억부(캐시)에 대한 저장 처리, 나아가 갱신 처리, 삭제 처리 등을 실행하는 프로그램이다. 구체적으로는, 예를 들어 JavaScript(등록 상표)에 의해 구성된다.
서비스 워커(SW)는, 예를 들어 방송 서버(21)나, 데이터 배신 서버(22) 등의 송신 장치(20)가 제공하는 방송 프로그램(방송 콘텐츠)에 대응하여 설정되고, 송신 장치(20)로부터 수신 장치(30)로 제공되는 애플리케이션의 제어 및 관리 프로그램으로서, 수신 장치(30)로 제공된다.
서비스 워커(SW), 애플리케이션, 및 애플리케이션의 실행 시에 이용되는 데이터 파일, 이것들은, 예를 들어 앞서 도 2, 도 3을 참조하여 설명한 NRT 콘텐츠(논 리얼타임 콘텐츠)로서, 송신 장치(20)로부터 수신 장치(30)로 제공된다.
혹은, 방송 프로그램을 배신하는 서버와는 다른 데이터 제공 서버가, 서비스 워커(SW), 애플리케이션, 및 애플리케이션의 실행 시에 이용되는 데이터 파일을 수신 장치(30)에 제공하는 구성으로 해도 된다.
서비스 워커(SW)는, 예를 들어 수신 장치(30)에 있어서 Web 페이지 등의 열람 처리를 실행하기 위해 이용되는 프로그램인 브라우저를 이용하여 정보 표시를 실행하는 애플리케이션 등의 관리(취득, 유지, 갱신, 삭제 등) 처리 등을 실행한다.
서비스 워커(SW)를 이용한 처리의 구체예(사용례)에 대하여, 도 4, 도 5를 참조하여 설명한다.
도 4는, 수신 장치(30)가, 방송 서버(21) 등의 송신 장치(20)로부터, 어떠한 프로그램 콘텐츠를 수신하고, 수신 장치(30)의 표시부에 표시하고 있는 상태를 도시하고 있다.
방송 서버(21) 등의 송신 장치(20)는, 프로그램 배신과 함께, NRT 콘텐츠(논 리얼타임 콘텐츠)로서, 날씨 정보를 표시하는 애플리케이션, 및 이 날씨 정보 표시 애플리케이션에 이용되는 여러 가지 데이터 파일, 예를 들어 동화상, 정지 화상, 음성 등의 여러 가지 데이터를 포함하는 데이터 파일을 수신 장치(30)에 제공한다.
이하에서는, 이들 애플리케이션 및 데이터 파일을 「리소스」라고 칭한다.
방송 서버(21)는, 또한 이들 「리소스」를 관리하는 리소스 관리 프로그램으로서, 서비스 워커(SW)를, 역시 NRT 콘텐츠(논 리얼타임 콘텐츠)로서 수신 장치(30)에 제공한다.
수신 장치(30)는, 송신 장치(20)로부터 수신한 「리소스」, 즉 애플리케이션 및 데이터 파일을 이용하여, 도 4에 도시하는 바와 같이, 프로그램 표시와 함께, 날씨 정보의 표시를 행할 수 있다.
이러한 애플리케이션을 이용한 데이터 표시는, 이제까지의 데이터 배신 구성으로는, 애플리케이션이 제공되는 프로그램의 종료와 함께 실행할 수 없게 되어 버린다.
이것은, 날씨 정보 표시 애플리케이션 등의 리소스는, 프로그램 수신 중에는, 수신 장치(30)에 있어서 이용 가능한 설정, 예를 들어 일시 기억 캐시에 저장되어, 이용 가능한 상태로 설정되지만, 프로그램 종료, 혹은 유저가 채널을 전환하면, 이들의 캐시 데이터가 소거, 혹은 액세스 불가능한 상태로 설정되어 버리기 때문이다.
서비스 워커(SW)는, 이러한 프로그램 대응의 애플리케이션이나 데이터를, 프로그램 종료 후나, 채널 전환 후, 혹은 방송의 비수신 상태, 네트워크 비접속 상태 등의 오프라인 상태에서도 이용 가능하게 하기 위한 리소스 관리 프로그램으로서 기능한다.
도 5에 도시하는 바와 같이, 날씨 정보 표시 애플리케이션을, 이 애플리케이션을 제공한 프로그램의 종료 후나, 다른 채널로 전환한 후, 혹은 데이터 수신을 실행하지 않은 오프라인 상태에서도 이용하는 것이 가능하게 된다. 즉 날씨 정보를 수신 장치(30)의 표시부에 표시하여 열람하는 것이 가능하게 된다.
또한, 날씨 정보 표시 애플리케이션은, 예를 들어 브라우저 상에서 표시되는 프로그램이다.
이 날씨 정보 표시 애플리케이션은, 서비스 워커(SW)의 제어에 의해, 수신 장치(30)의 기억부(영속 캐시)에 저장된다. 예를 들어 유저에 의한 표시 요구 등의 리퀘스트(이벤트)가 있으면, 서비스 워커(SW)의 제어에 의해, 기억부(영속 캐시)로부터 판독되어, 표시부에 표시된다.
또한, 애플리케이션 등의 리소스를 저장하는 기억부(영속 캐시)는, 수신 장치(30)의 전원이 오프로 되어도 저장 데이터가 소거되지 않는 불휘발성 메모리로 하는 것이 바람직하다.
이와 같이, 서비스 워커(SW)를 이용함으로써, 여러 가지 프로그램 대응 애플리케이션을, 프로그램의 표시, 비표시와 상관없이 이용하는 것이 가능하게 된다.
또한, 서비스 워커(SW)는, 예를 들어 어떠한 프로그램 대응의 리소스(애플리케이션 및 애플리케이션 관련 데이터) 단위마다 설정되어, 리소스와 함께, 혹은 리소스 송신에 전후하여 송신 장치(20)로부터 수신 장치(30)로 제공된다.
서비스 워커(SW)는, 각 프로그램 대응의 설정으로 할 수도 있지만, 복수 프로그램을 포함하는 특정한 채널 대응의 리소스에 대하여, 공통으로 이용 가능하게 한 서비스 워커(SW)를 설정할 수도 있다.
서비스 워커(SW)와, 서비스 워커(SW)에 의해 관리되는 리소스(애플리케이션 및 애플리케이션 관련 데이터)는, 수신 장치(30)의 기억부(영속 캐시)에 저장된다.
도 6은, 서비스 워커(SW)를 이용한 처리의 일례를 설명하는 도면이다.
도 6에는, 수신 장치(30)가 송신 장치(20)로부터 리소스로서의 Web 페이지(예를 들어 도 4, 도 5에 도시하는 날씨 정보 표시 페이지)를 취득하여 수신 장치(30)의 기억부(영속 캐시)에 저장하여 이용하는 시퀀스의 일례를 도시하고 있다.
또한, Web 페이지는, 소정의 Web 페이지 표시 애플리케이션과, 표시용 데이터에 의해 구성되는 리소스를 이용하여 표시된다.
도 6에는, 수신 장치 내 출력 제어부(90)의 구성 요소로서 표시 처리부(91), 서비스 워커(SW)(92), 캐시(기억부)(93)를 도시하고 있다.
스텝 S101 내지 S102는, 수신 장치(30)에 의한 송신 장치(20)에 대한 첫회 액세스 처리에 의한 리소스(Web 페이지) 취득 처리이다.
이것은, 예를 들어 방송 서버 등이 송신하는 NRT 콘텐츠로부터 취득된다.
이 취득 처리 후, 표시 처리부(91)에 의해, Web 페이지(95)가, 수신 장치(30)의 표시부에 표시된다. 이 표시는, 이 Web 페이지를 제공하고 있는 프로그램과 함께 표시되어 있는 상태이며, 앞서 도 3을 참조하여 설명한 표시 상태에 상당한다.
이 표시 기간에 있어서, 예를 들어 유저에 의한 지시로서 리소스(Web 페이지)의 등록(인스톨) 요구가 이루어지면, 스텝 S103에 있어서, 서비스 워커(SW)(92)가, 리소스(Web 페이지)의 등록(인스톨) 처리를 개시한다.
구체적으로는, 스텝 S104에 나타내는 바와 같이 리소스를 캐시(93)에 전달하여, 기억부(영속 캐시)에 저장하는 처리를 행한다.
그 후, 프로그램 종료 후, 혹은 채널 전환 후, 혹은 오프라인 설정 상태에 있어서, 스텝 S105에 있어서, 유저가 Web 페이지의 열람 요구를 행한다.
서비스 워커(SW)(92)는, 이 열람 요구의 입력을 페치 이벤트로서 검출하고, 페치 이벤트 검출에 따라, 스텝 S106에 있어서, 리소스(Web 페이지)를 기억부(영속 캐시)로부터 취득한다.
표시 처리부(91)는, 스텝 S107에 있어서, Web 페이지(96)를 표시한다.
이 Web 페이지 표시 처리는, 프로그램 종료 후, 혹은 채널 전환 후, 혹은 오프라인 설정 상태에 있어서의 표시 처리이며, 앞서 도 5를 참조하여 설명한 표시 상태에 상당한다.
이와 같이, 서비스 워커(SW)를 이용함으로써, 여러 가지 프로그램 대응 애플리케이션을, 프로그램의 표시, 비표시와 상관없이 이용하는 것이 가능하게 되고, 예를 들어 프로그램 부속의 표시 정보로서 설정된 Web 페이지를 프로그램과 상관없이, 임의의 타이밍에 표시하는 등의 처리가 가능하게 된다.
이와 같이, 서비스 워커(SW)는, 예를 들어 Web 페이지, HTML 페이지, JavaScript(등록 상표) 등을 구성 요소로 한 애플리케이션이나, 애플리케이션에 이용되는 데이터 등을 포함하는 리소스의 취득, 보존, 갱신, 삭제 등의 리소스 관리를 실행한다.
리소스가 보존되는 기억부(캐시)는, 저장 데이터를 영속적으로 보존하는 기억부(캐시)이며, 통상의 로컬/템퍼러리 캐시와는 달리, 애플리케이션이 가동하고 있지 않아도 데이터가 보존된다.
Web 페이지 표시 프로그램인 브라우저에 1종의 프록시 서버가 실장되어, 언제라도, 필요할 때 프록시 서버를 액세스하여 Web 페이지를 취득하여 표시 가능으로 한 이미지이다.
또한, 서비스 워커(SW) 자신도 영속 캐시에 저장(인스톨)된다. 서비스 워커(SW)가 수신 장치에 인스톨되면, 이 서비스 워커(SW)가 관리 대상으로 하는 리소스에 대하여, 여러 가지 제어가 가능하게 된다.
예를 들어, 리소스에 대한 액세스 리퀘스트(리소스에 대한 페치 리퀘스트)에 따라, 브라우저측의 처리(로컬 캐시나 네트워크로부터의 리소스의 취득)가 시작되기 전에, 서비스 워커(SW)의 처리가 개시되고, 영속 캐시로부터의 리소스의 제공이 행해진다.
또한, 서비스 워커(SW)는, JavaScirpt(등록 상표)로 제공되기 때문에, 다양한 수속을 도입하는 것이 가능하고, 영속 캐시의 리소스의 일부 갱신 등 캐시 제어에 대한 유연한 처리 기술이 가능하게 되어 있다.
또한, 서비스 워커(SW) 자신도 갱신 가능하다. 서비스 워커(SW)는, 송신 장치(20)로부터 제공되지만, 이 서비스 워커(SW)의 헤더 정보(HTTP Cache-Control)에 갱신 일시 정보나 갱신 데이터의 액세스 정보 등, 갱신 처리에 필요한 각종 정보가 기록되고, 이 헤더 정보에 기초하여 갱신 처리가 실행된다.
예를 들어, 헤더에 설정된 사용 기한 등에 기초하여, 사용 기한이 도래하면, 수신 장치(30)는, 새로운 버전의 서비스 워커(SW)의 취득 처리를 실행하여, 캐시에 저장된 구 버전의 SW를 치환하는 갱신 처리를 행한다.
[5. 수신 장치에 있어서의 애플리케이션의 취득 및 실행예에 대하여]
상술한 바와 같이, 수신 장치(30)는, 서비스 워커(SW)를 이용하여, 임의의 타이밍에, 예를 들어 도 4, 도 5를 참조하여 설명한 바와 같은 날씨 정보 표시 애플리케이션 등의 애플리케이션, 즉 서비스 워커(SW)의 관리 대상인 애플리케이션을 실행하는 것이 가능하게 된다.
수신 장치(30)측의 유저는, 임의의 타이밍에 애플리케이션을 실행함으로써, 날씨 정보 표시 페이지나, 여러 가지 Web 페이지를 언제라도 열람하는 것이 가능하게 된다.
도 7을 참조하여, 수신 장치(30)에 있어서의 애플리케이션 실행 구성에 대하여 설명한다.
도 7에는, 예를 들어 날씨 정보 표시 애플리케이션 등의 서비스 워커(SW) 관리 애플리케이션을 실행하는 수신 장치(30)의 일부 구성으로서, 주로 애플리케이션의 취득이나 실행에 적용하는 구성예를 도시하고 있다.
도 7에 도시하는 바와 같이, 수신 장치(30)는 미들웨어(110), HTTP 프록시 서버(120), 출력 제어부(130)를 갖는다.
미들웨어(110)는, 방송 서버(21)의 제공 데이터를 수신하고, 해석한다.
미들웨어(110)는, 통신부(PHY/MAC)(111), 시그널링 데이터를 취득하는 시그널링 취득부(112), 시그널링 데이터를 해석하는 시그널링 해석부(113), 시그널링 데이터, 및 영상, 음성 등의 프로그램 콘텐츠 데이터나, 애플리케이션 등의 NRT 콘텐츠 등의 데이터 파일을 취득하는 파일 취득부(114)를 갖는다.
미들웨어(110)가 수신한 데이터는, 프록시 서버(120)의 캐시부(프록시 캐시)(121)에 저장된다. 프록시 서버(120)는, 추가로 네트워크 경유로 데이터 배신 서버(22)로부터 취득한 데이터를 캐시부(프록시 캐시)(122)에 저장한다.
프록시 서버(120)는, 출력 제어부(130)로부터의 데이터 요구를 어드레스 해결부(123)에 입력하고, 요구된 데이터를 캐시부(프록시 캐시)(121, 122) 또는 외부로부터 취득하여 제공한다.
출력 제어부(130)는, 예를 들어 날씨 정보 표시 애플리케이션 등의 서비스 워커(SW) 관리 애플리케이션을 실행하는 데이터 처리부이다. 예를 들어 브라우저 상에서 Web 페이지의 표시 처리 등을 실행한다.
출력 제어부(130)는, 표시 데이터(HTML/JavaScript(등록 상표) 등) 취득&해석부(131), 표시 처리부(Renderer)(132)를 갖는다.
출력 제어부(130)는, 프록시 서버(Client Local HTTP Proxy Server)(120)를 통하여, 방송계 수신 스택이 실장된 미들웨어(Client Local ATSC Middleware)(110)나, 혹은 네트워크계 송수신 처리를 행하는 통상의 네트워크 스택을 통하여 애플리케이션 및 파츠(HTML 페이지나 JavaScript)를 취득하여 제시한다.
또한, 수신 장치(30)에 LAN 등의 네트워크를 통하여 접속된 외부 장치(150)의 출력 제어부(141)에 있어서 애플리케이션 및 파츠(HTML 페이지나 JavaScript)를 전송하여, 외부 장치(140)에 있어서 애플리케이션을 실행하는 것도 가능하다.
출력 제어부(130)는, 기억부(영속 캐시)(133)에 전술한 서비스 워커(SW)나, 서비스 워커(SW)의 관리 대상으로 되는 리소스(애플리케이션 및 애플리케이션 관련 데이터)를 저장하고, 임의의 타이밍에 기억부(영속 캐시)에 저장된 서비스 워커(SW)나 리소스를 이용한 처리를 실행할 수 있다.
예를 들어 앞서 도 4, 도 5를 참조하여 설명한 바와 같이, 임의의 타이밍에 애플리케이션을 이용한 여러 가지 데이터 출력을 행할 수 있다. 또한, 출력 제어부(130)는, 필요에 따라, 서비스 워커(SW)나, 리소스(애플리케이션 및 애플리케이션 관련 데이터)의 갱신 처리나 삭제 처리 등을 행한다.
외부 장치(140)의 출력 제어부(141)도 마찬가지이며, 외부 장치(140)의 기억부(영속 캐시)(142)에 서비스 워커(SW)나, 리소스(애플리케이션 및 애플리케이션 관련 데이터)를 저장하고, 임의의 타이밍에 서비스 워커(SW)나 애플리케이션을 이용한 여러 가지 데이터 처리를 행한다. 또한, 필요에 따라, 서비스 워커(SW)나, 리소스(애플리케이션 및 애플리케이션 관련 데이터)의 갱신 처리나 삭제 처리 등을 행한다.
또한, 도 7에 도시하는 모델에서는, 출력 제어부(130, 140)는 외부와의 액세스를 행하는 경우, 반드시 프록시 서버(120)를 통하여 액세스하기 때문에, 애플리케이션 등의 리소스를 방송 경유로 취득하였는지, 네트워크 경유로 취득하였는지를 구별하는 일이 없다. 즉 네트워크 투과성이 제공된다.
출력 제어부(130)로부터의 데이터 요구에 따른 데이터 취득, 제공 처리예에 대하여 설명한다.
예를 들어, 출력 제어부(130)가, 애플리케이션을 구성하는 HTML 페이지 혹은 JavaScript(등록 상표)의 취득을 요구하면(HTTP 리퀘스트), 그것을 받은 프록시 서버(120)는, 어드레스 해결부(Broadcast/Broadband Address Resolver)(123)에 있어서 방송 수신 스택을 통하여 취득할지, 네트워크 경유로 취득할지의 판단을 행한다.
이 판단의 재료가 되는 정보는, 시그널링 해석부(113)에 의한 시그널링 데이터의 해석 결과로부터 얻어진다.
시그널링 해석부(Signaling Parser)(113)는, 시그널링 취득부(Signaling Retriever)(112)에 대하여, ATSC 3.0의 시그널링 데이터에 포함되는 메타데이터인 USBD(USD, SDP 등)의 취득 요구를 행한다.
시그널링 해석부(Signaling Parser)(113)는, 통신부(ATSC 튜너: ATSC 3.0 PHY/MAC)(111)를 통하여 방송 수신하는 시그널링 데이터 저장 LCT 패킷에 의해 전송되는 시그널링 데이터에 포함되는 메타데이터를 추출한다.
또한, 시그널링 해석부(Signaling Parser)(113)는, 애플리케이션 구성 요소(파츠)의 취득 요구에 포함되는 URL에 기초하여, 시그널링 데이터(메타데이터)로부터, 요구 파일을 취득하기 위한 방송 배신 어드레스 정보를 해결한다. 애플리케이션 구성 요소(파츠)가 방송 배신 대상 데이터라고 판정되면, 그 방송 배신 어드레스 정보를 바탕으로, 파일 취득부(File Retriever)(114)가 원하는 파일이 저장된 파일 저장 LCT 패킷을 방송 스트림으로부터 취득하고, 캐시부(프록시 캐시)(121) 내에 저장한다.
프록시 서버(120)는, 캐시된 파일을 출력 제어부(130)에 (HTTP의 리스펀스로서) 회신한다. 애플리케이션 파츠의 취득 요구에 포함되는 URL이, 시그널링 데이터에 포함되는 메타데이터에 설정되어 있지 않으면, 프록시 서버(120)는, 통상의 네트워크 스택을 통하여, 데이터 배신 서버(22)로부터 파일을 취득한다.
[6. 서비스 워커(SW)의 클래스 분류와, 클래스 분류된 서비스 워커(SW)의 선택 취득용 정보의 통지(시그널링) 처리에 대하여]
앞서 설명한 바와 같이, 서비스 워커(SW)는, 송신 장치(20)로부터 수신 장치(30)로 제공되고, 수신 장치(클라이언트)(30)에 있어서 실행되는 애플리케이션이나, 애플리케이션의 실행 시에 이용되는 데이터 파일 등의 취득 처리나, 기억부(캐시)에 대한 저장 처리, 나아가 갱신 처리, 삭제 처리 등을 실행하는 프로그램이다.
서비스 워커(SW)는, 예를 들어 프로그램 대응의 애플리케이션이나 데이터를, 프로그램 종료 후나, 채널 전환 후, 혹은 방송의 비수신 상태, 네트워크 비접속 상태 등의 오프라인 상태에서도 이용 가능하게 하는 리소스 관리 프로그램으로서 기능한다.
또한, 서비스 워커(SW)를 적용함으로써, 서비스 워커(SW) 관리 데이터로서 설정된 신규의 혹은 갱신된 애플리케이션이나, 동화상, 정지 화상 등의 데이터 파일을 수시로 취득하는 처리가 가능하다.
즉, 서비스 워커(SW)는 수신 장치(30)에 있어서 취득 가능한 여러 가지 데이터의 취득 제어도 실현한다.
이 서비스 워커(SW)를 클래스 분류하고, 수신 장치가, 복수 클래스의 서비스 워커(SW) 중 하나를 선택하여 취득하고, 이것을 적용함으로써, 예를 들어 수신 장치측의 유저 기호 등에 따른 서비스 워커 관리 데이터(리소스)의 취득(캐싱)을 실현하는 것이 가능하다.
즉, 수신 장치는, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)로부터, 특정 클래스의 서비스 워커(SW)를 선택 취득하여 이용한다.
예를 들어, 수신 장치에 있어서의 데이터 처리 상황에 따라 특정 클래스의 서비스 워커(SW)를 선택 취득하여 이용한다. 데이터 처리 상황은, 예를 들어 수신 장치에 있어서의 애플리케이션 또는 데이터의 이용 상황이다.
이와 같이, 복수 클래스의 서비스 워커(SW)로부터 특정 클래스의 서비스 워커(SW)를 선택 취득하여 이용 가능하게 함으로써, 클래스(종류)에 따라 상이한 복수의 캐싱 폴리시를 반영한 처리가 가능하게 된다.
수신 장치(30)는, 동시에 배신되는 복수의 클래스의 서비스 워커(SW) 중에서, 수신 장치(30)에 있어서 최적인 클래스의 서비스 워커(SW)를 선택하여 취득한다.
이 처리를 위해서는, 예를 들어 수신 장치(30)의 브라우저 상에서 가동하는 클라이언트 애플리케이션이 최적의 서비스 워커(SW)를 선택하여, 등록할 수 있도록 하는 것이 필요하게 된다.
상기 처리를 실현시키는 하나의 구성으로서, 서비스 워커(SW)에 설정된 클래스의 각각이, 어떠한 데이터를 선택 취득하는 설정인지, 즉 어떠한 캐싱 폴리시를 반영한 클래스의 서비스 워커(SW)인지를 수신 장치(30)에 통지하기 위한 시그널링 데이터(메타데이터)를 이용하는 구성이 있다.
예를 들어, 시그널링 데이터의 하나인 USD를 적용하여 SW의 클래스(캐싱 폴리시를 반영하는 클래스)를 통지한다.
또한, 여기서 말하는 캐싱 폴리시의 클래스란, 예를 들어 수신 장치(30)측의 엔드 유저의 애플리케이션 실행 이력 등으로부터 해석되는 기호를 반영한 클래스 등이다. 구체적으로는 예를 들어 이하와 같은 클래스를 설정하여, 수신 장치에 그 클래스의 서비스 워커(SW)를 선택 취득시켜 적용시키는 구성이 가능하다.
(1) 네트워크 부하나 요금이 고가가 되어도 고화질판 스트림을 선호하는 유저인 경우,
캐시 대상의 스트림의 후보가 복수인 경우(고화질, 중화질, 저화질판 등), 고화질판 스트림만을 캐시하도록 기술된 서비스 워커(SW)를 선택할 수 있도록 한다.
(2) 재생 품질에 문제가 있고 신선도가 상실되어도 고화질판을 선호하는 유저인 경우,
캐시 대상의 스트림이, 당일 저녁까지는, 네트워크 경유의 저품질판으로 배신되고, 밤까지 기다리면 더 고화질판이 방송 배신되는 경우에, 방송 배신 고화질판을 캐시하도록 기술된 클래스의 서비스 워커(SW)를 선택할 수 있도록 한다.
(3) 반대로, 품질에는 구애되지 않고, 어쨌든 빨리 보고 싶어하는 경향이 있는 유저인 경우,
이 케이스의 경우, 네트워크 경유의 저품질판을 캐시하도록 기술된 클래스의 서비스 워커(SW)를 선택할 수 있도록 한다.
클래스별 서비스 워커(SW)를 선택 취득하여 이용함으로써, 수신 장치(클라이언트)의 실행 환경이나 기억 용량 등의 각종 리소스의 제약 등도 고려한 최적의 데이터 취득, 관리를 실현할 수 있다. 수신 장치측의 유저의 기호 정보나, 기억 영역 용량 외 런타임 환경 제약, 로컬 네트워크 부하 등의 여러 가지 클라이언트 환경 속성을 참조하여 이용하는 서비스 워커(SW)의 클래스를 결정함으로써, 세심하게 캐시 대상인 애플리케이션(파츠)의 캐시 제어가 실현된다.
또한, 클래스 분류된 서비스 워커(SW)를 선택 취득하기 위해서는, 시그널링 데이터가 이용된다.
예를 들어, USD 등의 시그널링 데이터를 사용하여, 서비스 워커(SW)의 클래스를 수신 장치(30)에 통지하고, 수신 장치(30)가 시그널링 데이터에 기초하여, 자장치에 최적인 서비스 워커(SW)를 선택 취득함으로써, 상기한 바와 같이, 수신 장치(30)측의 상황이나 유저의 기호에 따른 최적의 데이터를 수신 장치(30)가 취득(캐싱)하는 것이 가능하게 된다.
[7. 서비스 워커(SW)의 배신과 캐시 제어 처리에 대하여(폴링형의 처리예)]
이어서, 서비스 워커(SW)의 배신과 캐시 제어 처리에 대하여 설명한다.
서비스 워커(SW), 혹은 서비스 워커(SW)의 관리 대상으로 되는 애플리케이션이나 애플리케이션에 적용하는 데이터를 포함하는 리소스는, 예를 들어 수신 장치(30)에 실장된 브라우저로부터의 취득 요구를 계기로 하여 폴링형으로 취득 처리를 행하는 구성과, 브라우저로부터의 취득 요구에 상관없이 취득하여 브라우저에 제공하는 푸시형의 2개의 형태가 있다.
이하, 이들 처리 형태, 즉
(A) 폴링형 데이터 취득 처리예
(B) 푸시형 데이터 취득 처리예
상기 (A), (B)의 2개의 처리 형태에 대하여, 순차적으로 설명한다.
우선, 폴링형 데이터 취득 처리를 행하는 경우의 처리예에 대하여 설명한다.
[7.1. 방송 스트림 부수 애플리케이션으로부터의 서비스 워커(SW)의 취득, 등록 처리에 대하여]
우선, 서비스 워커(SW)를, 송신 장치(20)로부터 수신 장치(30)로 송신되는 방송 스트림에 부수되는 애플리케이션을 이용하여 취득하고, 등록하는 처리예에 대하여 설명한다.
수신 장치(클라이언트)(30)는, 수신 장치(30)에 있어서 실행 중인 방송 스트림 재생 애플리케이션(브라우저 혹은 네이티브 환경에서 실행됨)의 처리에 의해, 취득 대상으로 하는 애플리케이션의 URL을 취득한다.
예를 들어, 특정한 프로그램의 방송 스트림에는, 애플리케이션을 기동하기 위한 URL 통지하는 트리거 정보가 포함되고, 재생 애플리케이션은, 이 트리거 정보에 기초하여 애플리케이션을 취득하기 위한 URL을 취득할 수 있다.
수신 장치(30)는, 이 URL을 이용하여 방송 스트림 중에서 URL에 의해 특정되는 애플리케이션을 추출하거나, 혹은 네트워크 경유로 애플리케이션을 취득하고, 브라우저 상에서 그 애플리케이션을 실행한다.
애플리케이션은, 이 애플리케이션 자신을 관리 대상으로서 설정한 서비스 워커(SW)[SW.js]의 취득 처리와 등록 처리를 행한다. SW.js의 js는 JavaScript(등록 상표)를 의미한다.
이 애플리케이션의 취득 및 실행, 나아가 서비스 워커(SW)의 취득과 등록 처리의 시퀀스에 대하여, 도 8 내지 도 10에 도시하는 시퀀스도를 참조하여 설명한다.
도 8 내지 도 10에는, 좌측으로부터, 이하의 각 구성 요소를 도시하고 있다.
(a) 송신 장치(20)인 방송 서버
(b) 송신 장치(20)인 데이터 배신 서버
(c) 수신 장치(30)의 구성 요소인 미들웨어
(d) 수신 장치(30)의 구성 요소인 프록시 서버
(e) 수신 장치(30)의 구성 요소인 출력 제어부
도 8 내지 도 10의 시퀀스도에 도시하는 각 스텝의 처리에 대하여, 순차적으로 설명한다.
또한, 도 8 내지 도 10의 처리 시퀀스의 개시 전에, 수신 장치(30)의 출력 제어부에서는, 네이티브의 스트림 재생 애플리케이션, 혹은 브라우저 상의 스트림 재생 애플리케이션이 기동되어 있는 것으로 한다.
(스텝 S211)
우선, 수신 장치(30)의 구성 요소인 출력 제어부는, 방송 콘텐츠 스트림의 DASH 스트리밍의 제어 파일인 MPD에 기술된 콘텐츠 저장 세그먼트의 액세스 정보인 세그먼트 URL을 취득하여, 취득한 세그먼트 URL을 사용하여 방송 콘텐츠를 저장한 콘텐츠 세그먼트 파일의 취득 요구를 실행한다.
전술한 바와 같이, 송신 장치(20)로부터 수신 장치(30)에 대한 콘텐츠 송신은, 예를 들어 어댑티브(적응형) 스트리밍 기술의 규격인 MPEG-DASH 규격에 따라 실행된다.
MPEG-DASH 규격에 따라 데이터 송신을 실행하는 송신 장치(20)는, 앞서 도 2를 참조하여 설명한 바와 같이, 크게 나누어 이하의 복수 종류의 데이터의 송신을 행한다.
(a) 시그널링 데이터(50)
(b) AV 세그먼트(60)
(c) 그 밖의 데이터(ESG, NRT 콘텐츠 등)(70)
AV 세그먼트(60)는, 수신 장치에 있어서 재생하는 화상(Video)이나, 음성(Audio) 데이터, 즉 예를 들어 방송국이 제공하는 프로그램 콘텐츠 등에 의해 구성된다. 예를 들어, 상술한 MP4 부호화 데이터(mdat)나, 메타데이터(moov, moof)에 의해 구성된다.
시그널링 데이터(50)는, 프로그램표 등의 프로그램 예정 정보나, 프로그램 취득에 필요한 어드레스 정보(URL 등), 나아가 콘텐츠의 재생 처리에 필요한 정보, 예를 들어 코덱 정보(부호화 방식 등) 등을 포함하는 안내 정보, 제어 정보에 의해 구성된다.
그 밖의 데이터(70)는, 예를 들어 ESG(Electronic Service Guide), NRT 콘텐츠 등이 포함된다.
ESG는, 전자 서비스 가이드(Electronic Service Guide)이며, 예를 들어 프로그램표 등의 안내 정보이다.
NRT 콘텐츠는 논 리얼타임형 콘텐츠이다.
NRT 콘텐츠에는, 예를 들어 클라이언트인 수신 장치의 브라우저 상에서 실행되는 여러 가지 애플리케이션 파일, 동화상, 정지 화상 등의 데이터 파일 등이 포함된다. 서비스 워커(SW)도 NRT 콘텐츠에 포함된다.
(MPD: Media Presentation Description)은, 동화상이나 음성 파일의 관리 정보인 메타데이터를 기술하기 위한 매니페스트 파일이다. 구체적으로는, 예를 들어 방송국이 배신하는 프로그램 콘텐츠의 배신 개시 시간 정보나, AV 세그먼트에 대한 액세스 정보 등이 기록된다.
수신 장치(30)의 출력 제어부는, 스텝 S211에 있어서, 방송 콘텐츠 스트림의 DASH 스트리밍의 제어 파일인 MPD에 기술된 콘텐츠 저장 세그먼트의 액세스 정보인 세그먼트 URL을 취득하여, 취득한 세그먼트 URL을 사용하여 콘텐츠 세그먼트 파일의 취득 요구를 프록시 서버에 대하여 실행한다.
(스텝 S212 내지 S213)
이어서, 수신 장치(30)의 프록시 서버는, 스텝 S212에 있어서, 세그먼트 URL로 식별되는 콘텐츠 세그먼트 파일이 프록시 서버가 관리하는 캐시에 저장되어 있으면, 캐시로부터 콘텐츠 세그먼트 파일을 취득하여 취득한 파일을 리스펀스로서 출력 제어부에 회신한다.
한편, 수신 장치(30)의 프록시 서버는, 스텝 S213에 있어서, 세그먼트 URL로 식별되는 콘텐츠 세그먼트 파일이 프록시 서버가 관리하는 캐시에 저장되어 있지 않다고 판정된 경우에는, 콘텐츠 세그먼트 파일의 취득 요구를 미들웨어에 출력한다.
(스텝 S214)
스텝 S214의 처리는, 방송 서버(21)에 의해 계속적으로 실행되는 처리를 나타내고 있다. 방송 서버(21)는, 프로그램 콘텐츠의 배신과 함께, 배신 콘텐츠에 관한 제어 정보, 관리 정보 등을 포함하는 시그널링 데이터(메타데이터 등)를 수신 장치(30)에 계속적으로 제공한다.
(스텝 S215)
스텝 S215의 처리는, 스텝 S213에 있어서, 프록시 서버로부터 콘텐츠 세그먼트 파일의 요구가 발생한 경우에, 미들웨어가 실행한다.
미들웨어는, 방송 서버(21)로부터 수신하는 시그널링 데이터(메타데이터)에 기초하여, 프록시 서버로부터 취득 요구가 있는 콘텐츠 세그먼트 파일이 방송에 의해 수신 가능한지 여부를 판정하고, 판정 정보를 프록시 서버에 통지한다.
(스텝 S216)
프록시 서버는, 미들웨어로부터 콘텐츠 세그먼트 파일이 방송에 의해 수신 가능하다는 통지를 받으면, 세그먼트 파일의 프록시 서버 관리 캐시로의 전개(저장)를 대기한다.
한편, 미들웨어로부터 콘텐츠 세그먼트 파일이 방송에 의해 수신 불가능하다는 통지를 받으면, 세그먼트 파일의 네트워크 경유에서의 취득 요구를 데이터 배신 서버(22)에 대하여 실행한다.
(스텝 S217 내지 S218)
스텝 S217 내지 S218의 처리는, 프록시 서버로부터 취득 요구가 있는 콘텐츠 세그먼트 파일이 방송에 의해 수신 가능한 경우에 실행되는 처리이다.
이 경우, 방송 서버(21)는, 스텝 S217에 있어서, 콘텐츠 세그먼트 파일을 방송파에 의해 송신한다.
수신 장치(30)의 미들웨어는, 스텝 S218에 있어서, 방송 서버(21)로부터 송신된 세그먼트 파일을 수신하여, 프록시 서버의 관리 캐시에 전개(저장)한다.
(스텝 S219)
스텝 S219의 처리는, 프록시 서버로부터 취득 요구가 있는 콘텐츠 세그먼트 파일이 방송에 의해 수신 불가능인 경우에 실행되는 처리이다.
이 경우, 데이터 배신 서버(22)는, 스텝 S219에 있어서, 수신 장치(30)로부터 요구된 콘텐츠 세그먼트 파일을 수신 장치(30)에 대하여 송신한다.
수신 장치(30)의 프록시 서버는, 송신된 세그먼트 파일을 수신하여, 프록시 서버의 관리 캐시에 전개(저장)한다.
(스텝 S220)
방송 서버(21), 또는 데이터 배신 서버(22)로부터 취득되어 프록시 서버 관리 캐시 내에 저장된 콘텐츠 세그먼트 파일은, 스텝 S220에 있어서, 프록시 서버로부터, 출력 제어부에 제공된다.
(스텝 S221)
스텝 S221에 있어서, 수신 장치(30)의 출력 제어부는, 프록시 서버로부터 취득한 콘텐츠의 재생을 개시한다.
또한, 콘텐츠 재생 시에 콘텐츠에 포함되는 트리거 정보를 취득하고, 트리거 정보에 기록된 콘텐츠 대응의 애플리케이션의 액세스 정보인 애플리케이션 URL을 트리거 정보로부터 취득하여, 취득한 애플리케이션 URL을 적용한 애플리케이션 취득 요구를 프록시 서버에 대하여 실행한다.
(스텝 S223)
스텝 S223의 처리는, 스텝 S221에 있어서 재생 중인 콘텐츠(예를 들어 방송 프로그램)에 대하여 설정된 애플리케이션의 취득과 실행 처리이다.
스텝 S223에서는, 스텝 S212 내지 S219의 처리(처리(A-1 내지 A-2))와 마찬가지의 처리를, 애플리케이션 파일에 대하여 실행한다.
즉, 스텝 S212 내지 S219의 처리 중에 나타내는 「세그먼트 파일」을 「애플리케이션 파일」로 치환한 처리를 실행하고, 방송 서버(21), 또는 데이터 배신 서버(22)로부터 애플리케이션 파일을 취득하여 프록시 서버의 관리 캐시에 저장한다. 또한, 이미 프록시 서버의 관리 캐시에 목적으로 하는 애플리케이션 파일이 전개(저장)되어 있는 경우에는, 새로운 취득 처리는 불필요하다.
(스텝 S224)
방송 서버(21), 또는 데이터 배신 서버(22)로부터 취득되어 프록시 서버 관리 캐시 내에 저장된 애플리케이션 파일은, 스텝 S224에 있어서, 프록시 서버로부터, 출력 제어부에 제공된다.
(스텝 S225)
스텝 S225에 있어서, 수신 장치(30)의 출력 제어부는, 프록시 서버로부터 취득한 애플리케이션을 실행한다.
예를 들어, 프로그램 콘텐츠의 표시와 함께 Web 페이지의 표시 처리 등이 실행된다. 또한, 처리 내용은, 애플리케이션에 따라 상이한 것이며, 반드시 데이터 표시가 실행된다고는 할 수 없다.
(스텝 S226)
스텝 S226의 처리는, 스텝 S225에 있어서 실행 중인 애플리케이션의 제어 하에서 실행되는 처리이며, 서비스 워커(SW)의 취득과 실행 처리이다.
스텝 S226에서는, 스텝 S212 내지 S219의 처리(처리(A-1 내지 A-2))와 마찬가지의 처리를, 서비스 워커(SW) 파일에 대하여 실행한다.
즉, 스텝 S212 내지 S219의 처리 중에 나타내는 「세그먼트 파일」을 「서비스 워커 파일」로 치환한 처리를 실행하고, 방송 서버(21), 또는 데이터 배신 서버(22)로부터 서비스 워커 파일를 취득하여 프록시 서버의 관리 캐시에 저장한다. 또한, 이미 프록시 서버의 관리 캐시에 목적으로 하는 서비스 워커 파일이 전개(저장)되어 있는 경우에는, 새로운 취득 처리는 불필요하다.
(스텝 S227)
방송 서버(21), 또는 데이터 배신 서버(22)로부터 취득되어 프록시 서버 관리 캐시 내에 저장된 서비스 워커 파일은, 스텝 S227에 있어서, 프록시 서버로부터, 출력 제어부에 제공된다.
(스텝 S228)
스텝 S228에 있어서, 수신 장치(30)의 출력 제어부는, 프록시 서버로부터 취득한 서비스 워커의 등록 처리를 실행한다.
구체적으로는, 서비스 워커(SW)를 기억부(영속 캐시)에 저장하는 처리를 실행한다.
[7.2. 서비스 워커(SW)에 대한 클래스 설정에 대하여]
전술한 바와 같이 서비스 워커(SW)를 클래스 분류하여, 수신 장치에 있어서 소정 클래스의 서비스 워커(SW)를 선택 취득하여 적용함으로써, 예를 들어 수신 장치(30)측의 유저 기호에 따른 애플리케이션이나 데이터를 취득하여 실행, 재생하는 것이 가능하게 된다.
송신 장치(20)는, 여러 가지 상이한 클래스의 서비스 워커(SW)를 동시에 병렬 배신하고, 수신 장치(30)는, 이들 복수 클래스의 서비스 워커(SW)로부터 하나의 클래스의 서비스 워커(SW)를 선택 취득하는 필터링 처리를 행하게 된다.
수신 장치(30)에 있어서 실행되는 애플리케이션, 혹은 서비스 워커(SW)가, 수신 장치(30)의 미들웨어에 대하여, 신규 취득하는 서비스 워커(SW)에 대한 필터링 정보를 설정한다. 즉 어느 클래스의 서비스 워커(SW)를 취득해야 하느냐 하는 서비스 워커(SW) 클래스 설정을 행한다.
수신 장치(30)의 미들웨어는, 서비스 워커(SW) 클래스 설정 정보에 기초하여, 필터링 처리를 실행하고, 송신 장치(20)가 송신하는 여러 가지 클래스의 서비스 워커(SW)로부터 지정된 클래스의 서비스 워커(SW)만을 선택 취득한다.
서비스 워커(SW) 클래스의 세트는, 예를 들어 프록시 서버 상의 서버 사이드 스크립트에 대하여 ajax를 사용하여 요구를 전달하는 등에 의해 실장된다.
또한, 시그널링 데이터(메타데이터)에 기록된 모든 파일 URL 중에서 원하는 파일 URL을 검색하고, 선택 취득하는 처리가 번잡(부하가 걸리는 처리로 될 가능성이 있음)하게 되므로, 프리필터링 처리를 행하는 것이 바람직하다.
프리필터링이란, 예를 들어 목적으로 하는 파일(예를 들어 지정 클래스의 서비스 워커(SW) 파일)의 URL을 시그널링 데이터 중에서 검색할 때의 검색 범위를 특정(스코프(scoping))하는 처리 등이다.
구체적으로는, 예를 들어 특정한 애플리케이션의 제공원인 채널 제공자(방송국)의 시그널링 데이터에서만 목적으로 하는 파일 URL을 찾을 수 있도록 해 두는 것 등의 처리이다.
이 처리에는, 후술하는 검색 스코프 토큰이 이용된다.
서비스 워커(SW) 클래스의 세트가 이루어진 후, 방송 시그널링 데이터를 수신한 미들웨어는, 설정된 서비스 워커(SW) 클래스에 기초하여, 시그널링 데이터 중에 해당하는 서비스 워커(SW) 클래스에 대응하는 파일 배신 세션이 있는지 여부를 판정한다. 또한, 수신 스케줄링을 행하여, 지정된 서비스 워커(SW)가 방송 경유로 배신되면, 필터링 모듈에 의해, 서비스 워커(SW)를 자동적으로 선택 취득하여 로컬 프록시 서버의 캐시에 전개하는 것이 가능하게 된다. 이들 프록시 서버 캐시에 전개된 파일에 대해서는, 클라이언트의 애플리케이션으로부터의 요구에 대하여 바로 응답하는 것이 가능하게 된다.
도 11 내지 도 12에 도시하는 시퀀스도를 참조하여, 서비스 워커(SW)의 클래스 설정 처리와, 서비스 워커(SW) 취득 처리 시퀀스에 대하여 설명한다.
도 11 내지 도 12에는, 좌측으로부터, 이하의 각 구성 요소를 도시하고 있다.
(a) 송신 장치를 구성하는 방송 서버
(b) 송신 장치를 구성하는 데이터 배신 서버
(c) 수신 장치의 미들웨어
(d) 수신 장치의 출력 제어부에서 실행되는 서비스 워커
(e) 수신 장치의 출력 제어부에서 실행되는 애플리케이션
도 11 내지 도 12의 시퀀스도에 도시하는 각 스텝의 처리에 대하여, 순차적으로 설명한다.
(스텝 S251)
스텝 S251의 처리는, 수신 장치의 출력 제어부에서 실행되는 애플리케이션에 의해 실행된다.
애플리케이션이, 서비스 워커(SW) 클래스의 설정 요구를 미들웨어에 대하여 실행한다.
구체적으로는, 예를 들어 도 7에 도시하는 미들웨어(110)의 시그널링 해석부(113)에 대하여, 시그널링 데이터에 포함되는 어느 클래스의 서비스 워커(SW) 액세스 정보를 검출해야 할지를 나타내는 토큰 정보를 통지하여, 시그널링 해석부(113)에 검출해야 할 클래스의 서비스 워커(SW) 액세스 정보를 판별 가능한 상태로 설정한다.
또한, 애플리케이션은, 예를 들어 수신 장치(클라이언트)의 환경 속성(상태 정보)이나, 애플리케이션이나 재생 데이터의 이용 이력의 통계 정보에 기초하여, 최적의 클래스를 결정한다. 이 클래스 결정 알고리즘은, 애플리케이션 자신이 유지해도 되고, 애플리케이션이 이용 가능한 프로그램이나 API를 이용하여 취득하는 구성으로 해도 된다.
(스텝 S252 내지 S253)
스텝 S252 내지 S253의 처리는, 수신 장치의 출력 제어부에서 실행되는 애플리케이션 및 서비스 워커에 의해 실행된다.
미들웨어에 대한 서비스 워커(SW) 클래스의 설정 처리는, 스텝 S251에서 설명한 바와 같이, 애플리케이션의 처리로서 실행해도 되지만, 서비스 워커(SW)의 처리로서 실행해도 된다.
스텝 S252 내지 S253의 처리는, 미들웨어에 대한 서비스 워커(SW) 클래스의 설정 처리를 서비스 워커(SW)의 처리로서 실행하는 경우에 행해진다.
우선, 스텝 S252에 있어서, 애플리케이션이, 서비스 워커(SW)의 등록 처리를 실행하고, 서비스 워커(SW)의 처리를 개시한다.
등록 처리에 의해 서비스 워커(SW)는, 기억부(영속 캐시)에 저장되어, 언제라도 이용 가능한 상태로 된다.
이어서, 등록된 서비스 워커(SW)가, 서비스 워커(SW) 클래스의 설정 요구를 미들웨어에 대하여 실행한다.
서비스 워커(SW) 클래스의 설정은, 스텝 S251의 처리와 마찬가지의 처리이다. 즉, 예를 들어 도 7에 도시하는 미들웨어(110)의 시그널링 해석부(113)에 대하여, 시그널링 데이터에 포함되는 어느 클래스의 서비스 워커(SW) 액세스 정보를 검출해야 할지를 나타내는 토큰 정보를 통지하여, 시그널링 해석부(113)에 검출해야 할 클래스의 서비스 워커(SW) 액세스 정보를 판별 가능한 상태로 설정한다.
(스텝 S254)
스텝 S254의 처리는, 방송 서버에 의해 계속적으로 실행되고 있는 시그널링 데이터의 송신 처리이다.
이 시그널링 데이터에는, 예를 들어 여러 가지 클래스 대응의 서비스 워커(SW)를 취득하기 위한 액세스 정보가 기록되어 있다.
(스텝 S255)
스텝 S255의 처리는, 수신 장치(30)의 미들웨어의 처리이다. 즉 데이터 수신 및 수신 데이터의 해석 등의 처리를 행하는 미들웨어의 처리이다. 미들웨어는, 애플리케이션 또는 서비스 워커(SW)로부터 통지된 서비스 워커(SW) 클래스를 설정하고, 설정한 서비스 워커(SW) 클래스에 기초하여, 시그널링 데이터로부터 설정된 클래스의 서비스 워커(SW)의 액세스 정보 검출을 행한다.
(스텝 S256)
또한, 수신 장치(30)의 미들웨어는, 스텝 S256에 있어서, 시그널링 데이터로부터 취득한 액세스 정보에 기초하여, 취득 대상 파일의 배신 스케줄 정보를 취득하고, 이것들을 사용한 서비스 워커(SW) 저장 파일 취득 처리를 개시한다.
(스텝 S257)
스텝 S257의 처리는, 방송 서버에 의해 계속적으로 실행되고 있는 각종 파일의 송신 처리이다.
송신 파일에는, 애플리케이션, 애플리케이션 실행 시에 이용되는 데이터 파일 등의 애플리케이션 관련 데이터, 나아가 서비스 워커(SW) 등이 포함된다.
(스텝 S258)
스텝 S258의 처리는, 수신 장치(30)의 미들웨어의 처리이다. 미들웨어는, 방송 서버의 송신 파일로부터, 취득 대상으로 되는 파일을 선택 취득하고, 취득 파일을 프록시 서버의 관리 캐시에 전개(저장)한다.
이와 같이, 수신 장치의 미들웨어에 취득해야 할 서비스 워커(SW)의 클래스 설정을 실행함으로써, 설정된 클래스 대응의 서비스 워커(SW)를 선택적으로 취득하는 것이 가능하게 된다.
[7.3. 토큰을 적용하여 특정 클래스의 서비스 워커(SW)의 취득 처리를 효율화한 구성에 대하여]
이어서, 수신 장치에 있어서의 취득 데이터의 취득, 선택 처리를 효율화한 구성에 대하여 설명한다.
구체적으로는, 토큰을 적용하여 특정 클래스의 서비스 워커(SW)의 취득 처리를 효율화한 구성에 대하여 설명한다.
송신 장치(20)로부터 송신되는 서비스 워커(SW)는 여러 가지 클래스의 서비스 워커(SW)이며, 수신 장치(30)는, 이들 다수의 클래스의 서비스 워커(SW)로부터 특정 클래스의 서비스 워커(SW)만을 선택 취득하는 처리가 필요하게 된다.
그러나, 방송파를 통하여 제공되는 서비스 워커(SW)나, 애플리케이션 및 데이터 파일은, 개개의 프로그램에 대응하여 설정되어, 송신 장치(20)가 송신하는 파일수는 방대한 수가 될 것으로 예상된다.
수신 장치(30)는, 이들 방대한 수의 송신 파일로부터, 자장치에 최적인 클래스의 서비스 워커(SW)를 선택하여 취득할 필요가 있다.
이 파일 선택 처리를 효율적으로 실행하기 위한 구성에 대하여, 이하에 설명한다.
서비스 워커(SW)는, 예를 들어 NRT 콘텐츠로서 방송파를 통하여 순차적으로 송신된다.
또한, 서비스 워커(SW) 등의 파일을 취득하기 위해 필요한 액세스 정보인 파일 대응의 URL이나 각 파일의 송신 타이밍 정보 등이 시그널링 데이터(메타데이터)에 기록되어 수신 장치(30)에 제공된다.
수신 장치(30)는, 시그널링 데이터(메타데이터)를 해석하여, 취득해야 할 파일의 URL이나 송신 타이밍 등을 알 수 있다.
시그널링 데이터(메타데이터)는, 예를 들어 하나의 채널이나 하나의 프로그램을 하나의 서비스 단위로서, 각 서비스 단위의 여러 가지 정보(메타데이터)를 기록하는 구성을 갖고 있다.
예를 들어, 도 13에 도시하는 바와 같이,
서비스 A의 기술을 갖는 메타데이터,
서비스 B의 기술을 갖는 메타데이터,
서비스 C의 기술을 갖는 메타데이터,
이와 같이 서비스 단위(프로그램 단위나 채널 단위)의 메타데이터가 기술되어 있다.
또한, 각 서비스 단위의 메타데이터는, 하위의 메타데이터로서 파일 전송 세션 단위의 메타데이터를 갖는다.
파일 전송 세션 단위의 메타데이터에는, 각 세션에 있어서 전송되는 파일의 액세스 정보가 기록된다.
수신 장치(30)는, 이 액세스 정보를 이용하여, 앞서 도 7을 참조하여 설명한 시그널링 해석부(113), 어드레스 해결부(123)의 처리에 의해 취득하고, 필요한 파일의 URL에 매치하는 파일 액세스 정보를 취득하여, 파일을 취득할 수 있다.
그러나, 수신 장치(30)는, 필요한 파일의 액세스 정보가, 시그널링 데이터의 어느 메타데이터에 기록되어 있는지를 알 수 없다.
따라서, 시그널링 데이터에 기록된 액세스 정보를 모두 검색 대상으로서 조사할 필요가 있으며, 검색 시간에 많은 시간을 요하게 된다.
이 해결책으로서, 시그널링 데이터에 검색 범위를 한정하기 위한 토큰이나 URL을 기록하는 구성으로 한 예에 대하여, 도 14를 참조하여 설명한다.
토큰이나 URL은, 수신 장치(30)의 취득 예정 데이터에 관한 액세스 정보(메타데이터)를 효율적으로 검색하기 위한 검색 보조 정보이다.
예를 들어, 특정한 클래스의 서비스 워커(SW)나, 특정한 클래스의 서비스 워커(SW)의 관리 대상으로 되는 데이터인 리소스(애플리케이션 앱 관련 데이터)에 관한 액세스 정보를 효율적으로 검색하기 위한 검색 보조 정보이다.
도 14는, 도 13과 마찬가지의 시그널링 데이터(메타데이터)의 구성예를 도시하고 있다. 전술한 바와 같이, 시그널링 데이터(메타데이터)는, 예를 들어 하나의 채널이나 하나의 프로그램을 하나의 서비스 단위로서, 각 서비스 단위의 여러 가지 정보(메타데이터)를 기록하는 구성을 갖고 있다.
도 14에 도시하는 바와 같이,
서비스 A의 기술을 갖는 메타데이터,
서비스 B의 기술을 갖는 메타데이터,
서비스 C의 기술을 갖는 메타데이터,
이와 같이 서비스 단위(프로그램 단위나 채널 단위)의 메타데이터가 기술되어 있다.
또한, 각 서비스 단위의 메타데이터는, 하위의 메타데이터로서 파일 전송 세션 단위의 메타데이터를 갖는다.
도 14에 도시하는 예에서는, 서비스 A의 기술을 갖는 메타데이터(151)에, 토큰 <SW-Scope>의 기술이 포함된다.
또한, 메타데이터(151)에 포함되는 하위의 세션 단위의 메타데이터인 파일 전송 세션(2)의 기술을 갖는 메타데이터(152)와, 파일 전송 세션(3)의 기술을 갖는 메타데이터(154)에는, 토큰 <SW-Class>와 파일 URL의 기술이 포함된다.
또한, 메타데이터(151)에 포함되는 하위의 세션 단위의 메타데이터인 파일 전송 세션(1)의 기술을 갖는 메타데이터(153)에는, 파일 URL의 기술이 포함된다.
이들 <SW-Scope>, <SW-Class>나 파일 URL이, 수신 장치에 있어서 취득 파일의 액세스 정보를 효율화하기 위해 적용되는 토큰으로서 기술되는 데이터이다.
메타데이터(151)에 기록되는 토큰 <SW-Scope>는, 검색 대상으로 하는 액세스 정보를 기록한 메타데이터의 검색 범위를 한정하기 위해 이용되는 토큰이며,
「서비스 워커(SW) 검색 스코프 토큰」이다.
또한, 메타데이터(152)에 기록되는 토큰 <SW-Class>는, 특정한 SW의 관리, 또는 갱신 대상으로 되는 파일(캐시 대상 파일)에 관한 URL 정보가 통합하여 기록되어 있음을 나타내는 토큰이며,
「서비스 워커(SW) 클래스 지정 토큰」이다.
또한, 이들 토큰은, 모두 특정한 서비스 워커(SW) 대응의 토큰으로서 설정되어 있다.
「서비스 워커(SW) 검색 스코프 토큰 <SW-Scope>」는, 취득해야 할 특정 클래스의 서비스 워커(SW)의 파일 액세스 정보가, 이 토큰이 기록된 메타데이터, 또는 그 하위의 메타데이터 중에 기록되어 있음을 나타내는 토큰이다.
수신 장치(30)는, 이 토큰이 기록된 메타데이터를 선택하고, 이 메타데이터, 및 이 메타데이터의 하위의 메타데이터를 검색 범위로서 검색을 행하면, 수신 장치가 취득해야 할 클래스의 서비스 워커(SW) 파일의 액세스 정보를 효율적으로 취득할 수 있다.
즉, 그 밖의 메타데이터를 검색 대상으로부터 제외하는 것이 가능하게 되고, 검색 범위를 한정함으로써, 검색 효율을 높이는 것이 가능하게 된다.
또한, 「서비스 워커(SW) 클래스 지정 토큰 <SW-Class>」는, 예를 들어 수신 장치의 취득 대상으로 되는 클래스의 서비스 워커(SW) 파일의 액세스 정보가, 이 토큰이 기록된 메타데이터 중에 통합하여 기록되어 있음을 나타내는 특정한 서비스 워커(SW)의 관리 대상 파일군(그룹)을 나타내는 토큰이다.
수신 장치(30)는, 이 토큰이 기록된 메타데이터를 선택하고, 이 메타데이터에 기록된 액세스 정보만을 취득하면, 수신 장치가 취득해야 할 클래스의 서비스 워커(SW) 파일의 액세스 정보를 효율적으로 취득할 수 있다.
이와 같이, 토큰이나 URL은, 수신 장치(30)의 취득 예정 데이터에 관한 액세스 정보(메타데이터)를 효율적으로 검색하기 위한 검색 보조 정보로서 설정된다.
또한, 도 14에 도시하는 바와 같이, 서비스 워커(SW) 검색 스코프 토큰을, 시그널링 데이터의 서비스 단위의 기술 파트에 배치하고, 서비스 워커(SW) 클래스 지정 토큰을, 시그널링 데이터의 파일 전송 세션의 기술 파트에 배치하는 구성이 검색 효율을 높이는 토큰 설정예의 하나이다.
이 구성을 취함으로써, 수신 장치(클라이언트)에 있어서 시그널링 데이터를 수신한 경우의 액세스 정보 취득을 보다 효율적으로 행하는 것이 가능하게 된다.
수신 장치(30)는, 서비스 워커(SW) 검색 스코프 토큰을 갖는 서비스 기술군을 선택적으로 추출한 후, 그들에 관련지어지는 파일 전송 세션 기술을 추출하고, 서비스 워커(SW) 클래스 지정 토큰 혹은 파일 URL에 매치하는 파일 전송 어드레스(방송 스트림 상에서 전송되는 실제의 파일을 취득하는 데 필요한 어드레스 파라미터)를 검색하여 원하는 파일을 취득한다.
송신 장치(20)로부터 수신 장치(30)로 송신되는 시그널링 데이터(메타데이터)는, 도 14에 도시하는 바와 같이 계층 구성을 갖는데, 더욱 구체적인 시그널링 데이터(메타데이터)의 구성예와, 토큰의 설정예에 대하여, 도 15 내지 도 17을 참조하여 설명한다.
도 15에 도시하는 (1) 토큰 설정예 1에 기초하여, 송신 장치(20)로부터 수신 장치(30)로 송신되는 시그널링 데이터(메타데이터)의 계층 구성 설정예에 대하여 설명한다.
도 15의 (1)에 도시하는 시그널링 데이터(메타데이터)는, 최상위가 프로그램이나 채널 단위로 설정되는 서비스 단위의 메타데이터(Service)이다.
이 서비스 단위 메타데이터의 하위에 콘텐츠 단위의 메타데이터(Content)가 설정된다.
서비스 단위의 메타데이터(Service), 또는 콘텐츠 단위의 메타데이터(Content)의 하위에는, 배신 스케줄이나 액세스 정보를 기술한 메타데이터(Schedule&Access)가 설정된다.
또한, 메타데이터(Schedule&Access)의 하위에 USD(유저 서비스 디스크립션) 메타데이터가 설정된다.
또한, USD는, 예를 들어 배신 메소드에 관한 정보를 저장하고, 예를 들어 이하의 시그널링 데이터를 포함한다.
SDP(세션 디스크립션)
FDD(파일 딜리버리 디스크립션)
RFD(리페어 플로우 디스크립션)
SD(스케줄 디스크립션)
또한, USD는, 콘텐츠(AV 세그먼트)에 대응하는 여러 가지 안내 정보, 제어 정보를 저장한 매니페스트 파일을 갖는 시그널링 데이터로서,
MPD(미디어 프리젠테이션 디스크립션)
를 포함한다.
USD 메타데이터의 하위에, ROUTE 프로토콜에 따라 배신되는 구체적인 배신 데이터 정보, 예를 들어 실제로 배신되는 파일 개별의 전송 파라미터 등을 기록한 ROUTE 메타데이터가 설정된다.
도 15의 (1)에 도시하는 토큰 설정예 1은,
서비스 메타데이터(161)에, 「서비스 워커(SW) 검색 스코프 토큰 <SW-Scope>」를 기록하고 있다.
수신 장치(30)는, 이 토큰에 따라 취득 예정 클래스의 서비스 워커(SW) 파일의 URL이나 액세스 정보의 검색 범위를 한정할 수 있다. 즉, 도면의 점선 프레임으로 나타내는 검색 범위를 설정하여 취득 예정 파일의 URL이나 액세스 정보의 검색을 행할 수 있다.
또한, 최하층의 ROUTE 메타데이터(162, 163)에, 「서비스 워커(SW) 클래스 지정 토큰 <SW-Class>」가 기록되어 있다.
수신 장치(30)는, 이 토큰에 따라, 이 메타데이터(162, 163)에 특정 클래스의 서비스 워커(SW)나, 관리 리소스 파일의 URL이나 액세스 정보가 기록되어 있는 것을 알 수 있다.
도 15의 (2)에 도시하는 토큰 설정예 2는,
콘텐츠 메타데이터(164)에, 「서비스 워커(SW) 검색 스코프 토큰 <SW-Scope>」를 기록하고 있다.
수신 장치(30)는, 이 토큰에 따라 검색 범위를 한정할 수 있다. 즉, 도면의 점선 프레임으로 나타내는 검색 범위를 설정하여 취득 예정 파일의 URL이나 액세스 정보의 검색을 행할 수 있다.
또한, 최하층의 ROUTE 메타데이터(165)에, 「서비스 워커(SW) 클래스 지정 토큰 <SW-Class>」가 기록되어 있다.
수신 장치(30)는, 이 토큰에 따라, 이 메타데이터(165)에 특정 클래스의 서비스 워커(SW)나, 관리 리소스를 구성하는 그룹의 취득 예정 파일의 URL이나 액세스 정보가 기록되어 있는 것을 알 수 있다.
도 16의 (3)에 도시하는 토큰 설정예 3은,
스케줄&액세스 메타데이터(166)에, 「서비스 워커(SW) 검색 스코프 토큰 <SW-Scope>」를 기록하고 있다.
수신 장치(30)는, 이 토큰에 따라 취득 예정 클래스의 서비스 워커(SW) 파일의 URL이나 액세스 정보의 검색 범위를 한정할 수 있다. 즉, 도면의 점선 프레임으로 나타내는 검색 범위를 설정하여 검색을 행할 수 있다.
또한, 최하층의 ROUTE 메타데이터(167)에, 「서비스 워커(SW) 클래스 지정 토큰 <SW-Class>」가 기록되어 있다.
수신 장치(30)는, 이 토큰에 따라, 이 메타데이터(167)에 특정 클래스의 서비스 워커(SW)나 관리 리소스를 구성하는 그룹의 취득 예정 파일의 URL이나 액세스 정보가 기록되어 있는 것을 알 수 있다.
도 17의 (4)에 도시하는 토큰 설정예 4는,
USD 메타데이터의 하위에 설정된 스케줄 디스크립션 메타데이터(168)에, 「서비스 워커(SW) 검색 스코프 토큰 <SW-Scope>」를 기록하고 있다.
수신 장치(30)는, 이 토큰에 따라 검색 범위를 한정할 수 있다. 즉, 도면의 점선 프레임으로 나타내는 검색 범위를 설정하여 취득 예정 파일의 URL이나 액세스 정보의 검색을 행할 수 있다.
또한, 최하층의 ROUTE 메타데이터(169)에, 「서비스 워커(SW) 클래스 지정 토큰 <SW-Class>」가 기록되어 있다.
수신 장치(30)는, 이 토큰에 따라, 이 메타데이터(169)에 특정한 서비스 워커(SW)나, 관리 리소스를 구성하는 그룹의 취득 예정 파일의 URL이나 액세스 정보가 기록되어 있는 것을 알 수 있다.
도 15 내지 도 17을 참조하여 시그널링 데이터에 대한 토큰의 설정예에 대하여 복수의 예를 설명하였지만, 이 밖에도 여러 가지 형태에서의 토큰 설정이 가능하다.
수신 장치(30)는, 시그널링 데이터에 포함되는 토큰에 기초하여, 취득해야 할 파일의 URL이나 액세스 정보를 효율적으로 취득하는 것이 가능하게 된다.
수신 장치(30)는, 예를 들어 방송 데이터를 수신하는 미들웨어에, 상술한 검색 범위의 한정이나, 검색 대상 파일의 그룹 특정 등의 필터링 처리에 적용하는 토큰을 검출하기 위한 토큰 검출용 토큰 정보를 통지(세트)하고, 세트된 토큰 정보에 따라, 송신 장치(20)로부터 송신되는 시그널링 데이터를 해석하여 토큰을 검출하고, 검출한 토큰을 이용한 효율적인 검색 처리를 행하여, 기억부(영속 캐시)에 저장하는 파일의 취득에 필요한 URL 정보나 액세스 정보, 배신 스케줄 정보 등을 취득한다. 또한, 시그널링 데이터에는 파일 URL과 함께, 각 파일의 배신 스케줄 정보도 기록되어 있다.
미들웨어에 대한 토큰 정보의 세트 처리는, 예를 들어 프록시 서버 상의 서버 사이드 스크립트에 대하여 ajax를 사용하여 요구를 출력함으로써 실행할 수 있다.
또한, 토큰 정보의 세트 형태로서는, 이하의 설정 형태가 있다.
(1) 서비스 워커(SW) 클래스 지정 토큰(SW-Class)
(2) 서비스 워커(SW) 검색 스코프 토큰(SW-Scope)+서비스 워커(SW) 클래스 지정 토큰(SW-Class)
또한, 구체적인 설정 파라미터로서는, 예를 들어 서비스 워커(SW) 클래스 식별자 등이 사용된다. 또한, 특정 클래스 대응의 서비스 워커(SW)의 파일 URL을 사용해도 된다.
또한, 특정 클래스의 서비스 워커(SW)의 관리 데이터인 리소스의 선택 취득도 함께 행하는 경우에는, 이들 리소스의 파일 URL을 토큰과 함께 파라미터 지정해도 된다.
[7.4. 서비스 워커(SW)의 갱신 처리에 대하여]
이어서, 수신 장치(30)에 저장된 서비스 워커(SW)의 갱신 처리에 대하여 설명한다.
수신 장치(30)에 의해 취득된 서비스 워커(SW)는 수신 장치의 기억부(영속 캐시)에, 서비스 워커(SW)의 관리 대상으로 되는 리소스(애플리케이션 및 애플리케이션 관련 데이터)와 함께 저장되어, 언제라도 이용 가능한 설정으로 된다.
이 서비스 워커(SW)에는, 이용 기한을 정할 수 있고, 수신 장치(30)는, 필요에 따라, 수신 장치가 유지하는 이용 기한이 도래한 서비스 워커(SW)를 새로운 서비스 워커(SW)로 치환하는 서비스 워커(SW) 갱신 처리를 행할 수 있다.
서비스 워커(SW)는, 예를 들어 소정의 콘텐츠(프로그램)에 대응하여 설정된 애플리케이션을 사용한 취득 요구에 의해, 방송 서버(21), 혹은 데이터 배신 서버(22) 등의 송신 장치(20)로부터 취득된다.
예를 들어, 이 취득 처리 시에(방송 경유의 경우도 네트워크 경유의 경우도), 서비스 워커(SW)의 제공 처리 시에 송신 장치(20)로부터 수신 장치(30)에 대한 통신 데이터인 「HTTP 리스펀스 헤더: Cache-control」에 서비스 워커(SW) 자신의 유효 기한을 지정할 수 있다.
예를 들어, 소정의 콘텐츠(프로그램)에 대응하여 설정된 애플리케이션의 처리에 의해 실행되는 서비스 워커 등록 처리에 의해, 수신 장치(30)의 기억부(영속 캐시)에 저장된 서비스 워커(SW)는, 예를 들어 수신 장치의 출력 제어부에 있어서 실행되는 브라우저에 의해, 유효 기한의 확인 처리나, 갱신 처리가 실행된다.
브라우저는, 수신 장치(30)의 기억부(영속 캐시)에 저장된 복수의 서비스 워커(SW)의 각각에 대하여, 유효 기한을 확인하고, 유효 기한이 되면 자동적으로 로컬 프록시 서버에 대한 취득 리퀘스트를 행하여, 내용이 갱신되었으면 서비스 워커(SW)를 재등록, 즉 갱신 처리를 실행한다.
혹은, 브라우저가 설정한 일정 기한(예를 들어 1일에 1회 등)이 지나면 자동적으로 서비스 워커(SW)에 대하여 로컬 프록시 서버에 대한 취득 리퀘스트를 행하여, 내용이 갱신되었으면 재등록하는 처리가 이루어진다.
도 18 내지 도 19에 도시하는 시퀀스도를 참조하여, 서비스 워커(SW)의 갱신 처리 시퀀스에 대하여 설명한다.
도 18 내지 도 19에는, 좌측으로부터, 이하의 각 구성 요소를 도시하고 있다.
(a) 송신 장치를 구성하는 방송 서버
(b) 송신 장치를 구성하는 데이터 배신 서버
(c) 수신 장치의 미들웨어
(d) 수신 장치의 출력 제어부에서 실행되는 브라우저
또한,
(e) 수신 장치의 출력 제어부에서 실행되는 브라우저 상에서 실행되는 서비스 워커(SW)
이들 각 구성 요소를 도시하고 있다.
도 18 내지 도 19의 시퀀스도에 도시하는 각 스텝의 처리에 대하여, 순차적으로 설명한다.
(스텝 S271)
스텝 S271의 처리는, 방송 서버에 의해 계속적으로 실행되고 있는 시그널링 데이터의 송신 처리이다.
이 시그널링 데이터에는, 예를 들어 앞서 도 14 내지 도 17을 참조하여 설명한 토큰이 설정되어 있다.
(스텝 S272)
스텝 S272의 처리는, 수신 장치(30)의 미들웨어의 처리이다. 즉 데이터 수신 및 수신 데이터의 해석 등의 처리를 행하는 미들웨어의 처리이다. 미들웨어는, 애플리케이션 또는 서비스 워커(SW)로부터 통지된 토큰 정보를 설정하고, 설정한 토큰 정보에 기초하여, 시그널링 데이터로부터의 토큰(혹은 파일 URL) 검출을 실행한다.
(스텝 S273)
스텝 S273의 처리는, 방송 서버에 의해 계속적으로 실행되고 있는 각종 파일의 송신 처리이다.
송신 파일에는, 애플리케이션, 애플리케이션 실행 시에 이용되는 데이터 파일 등의 애플리케이션 관련 데이터, 나아가 서비스 워커(SW) 등이 포함된다.
(스텝 S274)
스텝 S274의 처리는, 수신 장치(30)의 미들웨어의 처리이다. 미들웨어는, 방송 서버의 송신 파일로부터, 취득 대상으로 되는 파일을 선택 취득하고, 취득 파일을 프록시 서버의 관리 캐시에 전개(저장)한다.
이 캐시 데이터에는, 애플리케이션, 애플리케이션 실행 시에 이용되는 데이터 파일 등의 애플리케이션 관련 데이터, 나아가 서비스 워커(SW) 등이 포함된다.
서비스 워커(SW)에는, 수신 장치(30)가 유지하고 있는 서비스 워커(SW)의 갱신 버전도 포함된다.
(스텝 S275)
스텝 S275는, 수신 장치의 출력 제어부에서 실행되는 브라우저의 처리이다.
브라우저는, 수신 장치(30)의 기억부(영속 캐시)에 저장된 복수의 서비스 워커(SW)의 각각에 대하여, 유효 기한을 확인하고, 유효 기한이 되면 자동적으로 로컬 프록시 서버에 대한 취득 리퀘스트를 행한다.
혹은, 브라우저가 설정한 일정 기한(예를 들어 1일에 1회 등)이 지나면 자동적으로 서비스 워커(SW)에 대하여 로컬 프록시 서버에 대한 취득 리퀘스트를 행한다.
(스텝 S276)
스텝 S276의 처리는, 수신 장치(30)의 미들웨어의 처리이다. 미들웨어는, 프록시 서버의 관리 캐시에, 브라우저로부터 취득 요구가 있는 갱신된 서비스 워커(SW)의 검색을 행하여, 검출된 경우, 갱신된 서비스 워커(SW)를 브라우저에 출력한다.
(스텝 S277)
스텝 S277은, 수신 장치의 출력 제어부에서 실행되는 브라우저의 처리이다.
브라우저는, 프록시 서버로부터 수령한 갱신 후의 서비스 워커(SW)를 등록한다. 즉, 기억부(영속 캐시)에 저장한다.
(스텝 S278)
스텝 S278은, 수신 장치의 출력 제어부에서 실행되는 서비스 워커(SW)의 처리이다. 여기서는, 새롭게 등록된 갱신 후의 서비스 워커(SW)의 처리를 나타내고 있다.
갱신 후의 서비스 워커(SW)는, 필요에 따라, 토큰 정보의 설정 요구를 미들웨어에 대하여 실행한다.
토큰 정보의 설정은, 전술한 도 11의 스텝 S251의 처리와 마찬가지의 처리이다. 즉, 예를 들어 도 7에 도시하는 미들웨어(110)의 시그널링 해석부(113)에 대하여, 시그널링 데이터에 포함되는 어느 클래스의 서비스 워커(SW) 액세스 정보를 검출해야 할지를 나타내는 토큰 정보를 통지하여, 시그널링 해석부(113)에 검출해야 할 클래스의 서비스 워커(SW)의 액세스 정보를 판별 가능한 상태로 설정한다.
(스텝 S279)
스텝 S279의 처리는, 수신 장치(30)의 미들웨어의 처리이다. 즉 데이터 수신 및 수신 데이터의 해석 등의 처리를 행하는 미들웨어의 처리이다. 미들웨어는, 갱신 후의 서비스 워커(SW)로부터 통지된 토큰 정보를 설정하고, 설정한 토큰 정보에 기초하여, 시그널링 데이터로부터의 토큰(혹은 파일 URL) 검출을 실행한다.
[7.5. 서비스 워커(SW)에 의한 수신 장치의 기억부(영속 캐시)의 제어 처리에 대하여]
이어서, 수신 장치(30)에 저장된 서비스 워커(SW)에 의한 수신 장치의 기억부(영속 캐시)의 제어 처리에 대하여 설명한다.
수신 장치(30)에 저장된 서비스 워커(SW)는, 관리 대상의 리소스, 즉 애플리케이션이나 애플리케이션 관련 데이터를 관리 처리의 하나로서, 이들 리소스가 저장된 기억부(영속 캐시)의 제어, 즉 캐시 제어를 실행한다.
우선, 서비스 워커(SW)는, 소정의 이벤트 검출에 따라, 자신을 최초로 기동한 애플리케이션에 필요한 파일을, 수신 장치(30)의 기억부(영속 캐시)에 저장한다.
서비스 워커(SW)에 의한 리소스 저장의 트리거로 되는 이벤트를 수취하는 타이밍은, 서비스 워커(SW)의 등록 처리 또는 재등록(갱신) 처리 시이다. 이들 시점에서 서비스 워커(SW)는, 등록(install) 이벤트를 수령한다.
그 밖에, 애플리케이션이 HTML 페이지나 JavaScript(등록 상표)를 요구하는 시점(페치(fetch) 이벤트를 수령), 혹은 서비스 워커(SW) 자신이 생성한 타이머에 의해 재기동되는 시점 등에 상기 리소스 저장 처리의 트리거로 되는 이벤트를 수령한다.
서비스 워커(SW)가 기억부(영속 캐시)에 전개한 애플리케이션(파츠군)은, 방송 스트림에 부수(동시)되어 기동될 뿐만아니라, 방송 스트림과는 독립적으로 클라이언트에 인스톨된 애플리케이션(오프라인 애플리케이션)으로서 기동하는 것이 가능하게 된다.
도 20 내지 도 21에 도시하는 시퀀스도를 참조하여, 서비스 워커(SW)에 의한 수신 장치의 기억부(영속 캐시)의 제어 처리 시퀀스에 대하여 설명한다.
도 20 내지 도 21에는, 좌측으로부터, 이하의 각 구성 요소를 도시하고 있다.
(a) 송신 장치를 구성하는 방송 서버
(b) 송신 장치를 구성하는 데이터 배신 서버
(c) 수신 장치의 미들웨어
(d) 수신 장치의 프록시 서버
(e) 수신 장치의 출력 제어부에서 실행되는 브라우저의 관리 하의 기억부(영속 캐시)
(f) 수신 장치의 출력 제어부가 실행하는 브라우저 상에서 실행되는 서비스 워커(SW)
(g) 수신 장치의 출력 제어부가 실행하는 브라우저 상에서 실행되는 애플리케이션
(h) 수신 장치의 출력 제어부에서 실행되는 네이티브 애플리케이션
이들 각 구성 요소를 도시하고 있다.
또한, 네이티브 애플리케이션은, 수신 장치(30)에서 실행되는 애플리케이션이지만, 서비스 워커(SW)의 관리 하에 있는 애플리케이션이 아니라, 예를 들어 콘텐츠(프로그램) 대응의 애플리케이션의 기동 처리 등에 사용되는 애플리케이션이다.
도 20 내지 도 21의 시퀀스도에 도시하는 각 스텝의 처리에 대하여, 순차적으로 설명한다.
(스텝 S301)
스텝 S301의 처리는, 네이티브 애플리케이션에 의한 콘텐츠(프로그램) 대응의 애플리케이션의 기동 처리이다.
상술한 바와 같이, 네이티브 애플리케이션은, 콘텐츠(프로그램) 대응의 애플리케이션의 기동 처리 등에 사용되는 애플리케이션이다.
콘텐츠(프로그램) 대응의 애플리케이션이, 예를 들어 프로그램 중에 내장된 트리거 정보에 기초하여 기동하는 설정인 경우에는, 이 네이티브 애플리케이션에 의한 기동 처리는 불필요하다.
(스텝 S302)
스텝 S302에 있어서, 기동된 애플리케이션이, 서비스 워커(SW)의 등록 처리를 실행한다.
등록 처리에 의해 서비스 워커(SW)는, 기억부(영속 캐시)에 저장되어, 언제라도 이용 가능한 상태로 된다.
이 서비스 워커(SW) 등록 처리는, 서비스 워커(SW) 자신으로부터는, 등록(install) 이벤트의 검출로서 파악되고, 서비스 워커(SW)는, 이 등록(install) 이벤트 검출을 계기로 하여, 스텝 S303의 캐시 제어를 개시한다.
(스텝 S303 내지 S305)
서비스 워커(SW)는, 등록(install) 이벤트를 검출하면, 스텝 S303에 있어서, 예를 들어 스크립트 기술에 따른 기억부(영속 캐시)의 제어를 개시한다.
구체적으로는, 특정 클래스의 서비스 워커(SW), 또는 특정 클래스의 서비스 워커(SW)의 관리 대상으로 되는 리소스(애플리케이션이나 애플리케이션 관련 데이터)의 취득, 캐시 전개(저장) 처리를 개시한다.
또한, 특정 클래스의 서비스 워커(SW), 또는 특정 클래스의 서비스 워커(SW)의 관리 대상으로 되는 리소스(애플리케이션이나 애플리케이션 관련 데이터)는, 스텝 S304에 있어서, 방송 서버, 데이터 배신 서버 등의 송신 장치로부터 계속적으로 송신된다.
스텝 S304에서는, 앞서 도 8 내지 도 9를 참조하여 설명한 리소스 송수신 처리에 있어서의 도 8 내지 도 9(A-1 내지 A-2)의 각 스텝의 세그먼트 파일에 대한 처리를, 리소스에 대한 처리로 치환한 처리가 실행된다.
송신 데이터는, 스텝 S305에 있어서, 프록시 서버의 관리 캐시를 통하여, 기억부(영속 캐시)에 전개(저장)된다.
(스텝 S306 내지 S309)
스텝 S306에 있어서, 애플리케이션이 애플리케이션 파츠, 예를 들어 애플리케이션의 실행에 필요한 동화상 파일이나 정지 화상 파일, 혹은 JavaScript(등록 상표) 프로그램, 음성 데이터 등의 애플리케이션 관련 데이터를 서비스 워커(SW)에 요구한다.
이 요구 처리는, 서비스 워커(SW)에 있어서의 페치(fetch) 이벤트 검출에 상당한다.
스텝 S307 내지 S309에 있어서, 서비스 워커(SW)는, 요구된 파츠를 기억부(영속 캐시)로부터 취득하여, 애플리케이션에 제공한다.
(스텝 S310 내지 S311)
스텝 S310 내지 S311의 처리는, 서비스 워커(SW)에 의한 액티베이트(activate) 이벤트 검출 시의 처리이다.
액티베이트(activate) 이벤트는, 예를 들어 유저에 의한 리소스의 삭제 요구의 입력이 실행된 경우, 혹은 애플리케이션의 유효 기한이 끝난 경우 등에 검출된다.
서비스 워커(SW)가, 액티베이트(activate) 이벤트를 검출하면, 예를 들어 스크립트 기술에 따른 기억부(영속 캐시)의 제어를 개시한다.
구체적으로는, 특정 클래스의 서비스 워커(SW), 또는 특정 클래스의 서비스 워커(SW)의 관리 대상으로 되는 리소스(애플리케이션이나 애플리케이션 관련 데이터)의 삭제 처리 등을 행한다.
(스텝 S312 내지 S315)
스텝 S312 내지 S315의 처리는, 서비스 워커(SW)에 의한 타이머 이벤트 검출 시의 처리이다.
타이머 이벤트는, 예를 들어 애플리케이션의 유효 기한이 끝난 경우, 갱신 기한이 도래한 경우 등에 검출된다.
타이머 이벤트에 따른 처리로서는, 예를 들어 캐시 리소스의 삭제, 혹은 갱신 리소스나 추가 리소스의 취득 처리 등이 있다.
스텝 S313은, 타이머 이벤트에 따른 캐시 리소스의 삭제 처리의 시퀀스이다.
스텝 S314 내지 S315는, 타이머 이벤트에 따른 갱신 리소스나 추가 리소스의 취득 처리의 시퀀스를 나타내고 있다.
또한, 스텝 S314에서는, 앞서 도 8 내지 도 9를 참조하여 설명한 리소스 송수신 처리에 있어서의 도 8 내지 도 9(A-1 내지 A-2)의 각 스텝의 세그먼트 파일에 대한 처리를, 리소스에 대한 처리로 치환한 처리가 실행된다.
[8. 서비스 워커(SW)의 배신과 캐시 제어 처리에 대하여(푸시형의 처리예)]
전술한 바와 같이, 서비스 워커(SW), 혹은 서비스 워커(SW)의 관리 대상으로 되는 애플리케이션이나 애플리케이션에 적용하는 데이터를 포함하는 리소스는, 예를 들어 수신 장치(30)에 실장된 브라우저로부터의 취득 요구를 계기로 하여 폴링형으로 취득 처리를 행하는 구성과, 브라우저로부터의 취득 요구에 상관없이 취득하여 브라우저에 제공하는 푸시형의 2개의 형태가 있다.
도 8 내지 도 21을 참조하여 설명한 처리는, 수신 장치(30)에 실장된 브라우저로부터의 취득 요구를 계기로 하여 서비스 워커(SW)나 그의 관리 리소스(애플리케이션 및 애플리케이션 관련 데이터)의 취득을 행하는 폴링형의 처리예이다.
이하, 브라우저로부터의 취득 요구에 상관없이, 서비스 워커(SW)나 그의 관리 리소스(애플리케이션 및 애플리케이션 관련 데이터)를 취득하여 브라우저에 제공하는 푸시형의 처리예에 대하여 설명한다.
[8.1. 방송 스트림 부수 애플리케이션으로부터의 서비스 워커(SW)의 취득, 등록 처리에 대하여]
푸시형 처리에 있어서도, 방송 서버(21)로부터 제공되는 콘텐츠(프로그램) 대응의 애플리케이션을 이용한 서비스 워커(SW)의 취득, 등록 시퀀스는, 앞서 도 8 내지 도 10을 참조하여 설명한 폴링형의 처리예와 마찬가지의 처리로 된다.
[8.2. 토큰을 적용하여 수신 장치의 데이터 취득 처리를 효율화한 구성에 대하여]
앞서 도 11 내지 도 12를 참조하여 설명한 폴링형 토큰 이용 처리에서는, 콘텐츠 부수 애플리케이션, 혹은 서비스 워커(SW)가, 취득해야 할 리소스나 서비스 워커(SW)를 포함하는 파일을 미들웨어에 있어서 필터링 취득하기 위한 토큰 정보(혹은 파일 URL)를 세트하는 처리를 실행하는 것으로서 설명하였다.
이 시나리오는, 미들웨어에 대하여 토큰 정보(혹은 파일 URL)에 의해 특정되는 파일을, 로컬 HTTP 프록시 서버의 캐시에 전개(저장)하도록 요구하는 것이다.
그러나, 토큰 정보의 설정 요구를 한 애플리케이션이나 서비스 워커(SW)는, 프록시 서버의 캐시에, 토큰에 따라 선택된 파일이 전개(저장)되었는지 여부를 수동적으로 검지할 수 없다.
즉, 도 11 내지 도 12를 참조하여 설명한 시퀀스는, 브라우저(애플리케이션)측으로부터의 폴링형에서 애플리케이션 파츠나 서비스 워커(SW)의 프록시 서버로부터의 인입을 행하는 모델이다.
전술한 폴링형 처리의 설명에서는, 서비스 워커(SW)의 캐시 유효 기한이나, 타이머, 미리 정한 폴링 주기 등을, 폴링을 행하는 계기로 하는 방법을 설명하였다.
이 처리는, 캐시 유효 기한/타이머/폴링 주기 등이 길면, 프록시 서버의 캐시에서 갱신이 행해지면 바로 브라우저측에 인입한다고 하는, 설정된 시간 간격의 입도에 의존하지 않는 인입 타이밍 제어가 불가능하다고 하는 문제가 있다.
또한, 타이밍 정밀도를 높이기 위해 시간 간격을 짧게 하면, 문의 요구가 빈번해져, 쓸데없는 부하를 높이게 된다.
이 문제를 해소하기 위해, 이하에 설명하는 푸시형 처리에서는, 브라우저측으로부터 토큰 정보(혹은 파일 URL)의 설정 요구를 행함과 동시에, 미들웨어의 관리 캐시에 대한 데이터 전개(저장)가 실행된 경우에, 캐시 전개를 브라우저측에 통지시키는 푸시 API 등을 이용한 푸시형 이벤트 통지 기구를 이용한 처리로 하고 있다.
이 푸시형 토큰 적용 데이터 선택 취득 처리 시퀀스에 대하여, 도 22 내지 도 23의 시퀀스도를 참조하여 설명한다.
도 22 내지 도 23에는, 좌측으로부터, 이하의 각 구성 요소를 도시하고 있다.
(a) 송신 장치를 구성하는 방송 서버
(b) 송신 장치를 구성하는 데이터 배신 서버
(c) 수신 장치의 미들웨어
(d) 수신 장치의 출력 제어부에서 실행되는 서비스 워커
(e) 수신 장치의 출력 제어부에서 실행되는 애플리케이션
도 22 내지 도 23의 시퀀스도에 도시하는 각 스텝의 처리에 대하여, 순차적으로 설명한다.
(스텝 S321)
스텝 S321의 처리는, 수신 장치의 출력 제어부에서 실행되는 애플리케이션에 의해 실행된다.
애플리케이션이, 토큰 정보의 설정 요구를 미들웨어에 대하여 실행한다.
구체적으로는, 예를 들어 도 7에 도시하는 미들웨어(110)의 시그널링 해석부(113)에 대하여, 시그널링 데이터에 포함되는 어느 클래스의 서비스 워커(SW) 액세스 정보를 검출해야 할지를 나타내는 토큰 정보를 통지하여, 시그널링 해석부(113)에 검출해야 할 클래스의 서비스 워커(SW)의 액세스 정보를 판별 가능한 상태로 설정한다.
구체적으로는, 예를 들어 서비스 워커(SW) 식별자 등을 토큰 정보로서 통지하여, 설정한다.
이 스텝 S321의 처리에 병행하여, 애플리케이션, 미들웨어 사이, 및 미들웨어와 송신 장치(방송 서버, 데이터 배신 서버) 사이에 있어서, 스텝 S321a, S321b에 나타내는 이벤트 등록, 승낙 처리를 실행한다.
이것은, 송신 장치(방송 서버, 데이터 배신 서버)로부터 수신 장치로 송신된 데이터(애플리케이션, 애플리케이션 관련 데이터, 서비스 워커(SW) 등)가, 미들웨어의 프록시 서버 관리 캐시에 전개(저장)된 경우에, 애플리케이션에 통지하는 처리의 실행을 각 장치 또는 구성부가 승낙하여 실행하는 것을 확인하는 처리이다.
(스텝 S322 내지 S323)
스텝 S322 내지 S323의 처리는, 수신 장치의 출력 제어부에서 실행되는 애플리케이션 및 서비스 워커에 의해 실행된다.
미들웨어에 대한 토큰 정보의 설정 처리는, 스텝 S321에서 설명한 바와 같이, 애플리케이션의 처리로서 실행해도 되지만, 서비스 워커(SW)의 처리로서 실행해도 된다.
스텝 S322 내지 S323의 처리는, 미들웨어에 대한 토큰 정보의 설정 처리를 서비스 워커(SW)의 처리로서 실행하는 경우에 행해진다.
우선, 스텝 S322에 있어서, 애플리케이션이, 서비스 워커(SW)의 등록 처리를 실행하고, 서비스 워커(SW)의 처리를 개시한다.
등록 처리에 의해 서비스 워커(SW)는, 기억부(영속 캐시)에 저장되어, 언제라도 이용 가능한 상태로 된다.
이어서, 등록된 서비스 워커(SW)가, 토큰 정보의 설정 요구를 미들웨어에 대하여 실행한다.
토큰 정보의 설정은, 스텝 S321의 처리와 마찬가지의 처리이다. 즉, 예를 들어 도 7에 도시하는 미들웨어(110)의 시그널링 해석부(113)에 대하여, 시그널링 데이터에 포함되는 어느 클래스의 서비스 워커(SW) 액세스 정보를 검출해야 할지를 나타내는 토큰 정보를 통지하여, 시그널링 해석부(113)에 검출해야 할 클래스의 서비스 워커(SW)의 액세스 정보를 판별 가능한 상태로 설정한다.
이 스텝 S322 내지 S323의 처리가 실행되는 경우에는, 이들 처리에 병행하여, 애플리케이션, 미들웨어 사이, 및 미들웨어와 송신 장치(방송 서버, 데이터 배신 서버) 사이에 있어서, 스텝 S323a, S323b에 나타내는 이벤트 등록, 승낙 처리를 실행한다.
이것은, 송신 장치(방송 서버, 데이터 배신 서버)로부터 수신 장치로 송신된 데이터(애플리케이션, 애플리케이션 관련 데이터, 서비스 워커(SW) 등)가, 미들웨어의 프록시 서버 관리 캐시에 전개(저장)된 경우에, 애플리케이션에 통지하는 처리의 실행을 각 장치 또는 구성부가 승낙하여 실행하는 것을 확인하는 처리이다.
(스텝 S324)
스텝 S324의 처리는, 방송 서버에 의해 계속적으로 실행되고 있는 시그널링 데이터의 송신 처리이다.
이 시그널링 데이터에는, 예를 들어 앞서 도 14 내지 도 17을 참조하여 설명한 토큰이 설정되어 있다.
(스텝 S325)
스텝 S325의 처리는, 수신 장치(30)의 미들웨어의 처리이다. 즉 데이터 수신 및 수신 데이터의 해석 등의 처리를 행하는 미들웨어의 처리이다. 미들웨어는, 애플리케이션 또는 서비스 워커(SW)로부터 통지된 토큰 정보를 설정하고, 설정한 토큰 정보에 기초하여, 시그널링 데이터로부터의 토큰(혹은 파일 URL) 검출을 실행한다.
또한, 수신 장치(30)의 미들웨어는, 토큰(혹은 파일 URL)에 기초하여, 취득 대상 파일을 결정하고, 선택 파일의 배신 스케줄 정보에 따라 파일 취득 처리를 개시한다.
(스텝 S326)
스텝 S326의 처리는, 방송 서버에 의해 계속적으로 실행되고 있는 각종 파일의 송신 처리이다.
송신 파일에는, 애플리케이션, 애플리케이션 실행 시에 이용되는 데이터 파일 등의 애플리케이션 관련 데이터, 나아가 서비스 워커(SW) 등이 포함된다.
(스텝 S327 내지 S328)
스텝 S327의 처리는, 수신 장치(30)의 미들웨어의 처리이다. 미들웨어는, 방송 서버의 송신 파일로부터, 취득 대상으로 되는 파일을 선택 취득하고, 취득 파일을 프록시 서버의 관리 캐시에 전개(저장)한다.
이 스텝 S327의 처리가 실행될 때, 스텝 S328a 내지 S328d에 나타내는 이벤트 통지 처리가 각 장치, 각 구성부 사이에서 실행된다.
이것은, 송신 장치(방송 서버, 데이터 배신 서버)로부터 수신 장치로 송신된 데이터(애플리케이션, 애플리케이션 관련 데이터, 서비스 워커(SW) 등)가, 미들웨어의 프록시 서버 관리 캐시에 전개(저장)되었음을, 애플리케이션 또는 서비스 워커(SW)에 통지하는 처리이다.
또한, 도면에는, 스텝 S328a 내지 S328d의 4개의 이벤트 통지 라인을 도시하고 있지만, 스텝 S328a, S328b에 대해서는, 데이터 송신을 실행한 어느 장치가 이벤트 통지를 실행하면 된다.
또한, 스텝 S328c, S328d의 미들웨어로부터의 통지 처리는, 토큰 정보 설정 요구의 발행원, 즉 애플리케이션 또는 서비스 워커(SW) 중 어느 것에 대해서만 실행하면 된다.
상술한 처리 시퀀스에 있어서, 푸시 API에 의한 토큰(혹은 파일 URL) 설정, 그리고 푸시 이벤트 의뢰의 이벤트는, ATSC 3.0 클라이언트 방송 미들웨어 상에 실장되는 푸시 이벤트 서버(퍼블리셔)에 등록된다. 푸시 이벤트 서버는, 필요에 따라, 네트워크 경유로, 송신 장치에 대하여, 푸시 이벤트 의뢰의 이벤트를 등록한다.
미들웨어는, 설정된 토큰(혹은 파일 URL)에 의해 필터링된 데이터가 프록시 서버 상에 전개되면, 푸시 이벤트를 푸시 이벤트 클라이언트(애플리케이션 혹은 서비스 워커(SW))에 통지한다.
브라우저측에서는, 이벤트를 받으면 바로 취득 요구(브라우저 캐시로의 인입)를 행할 수 있기 때문에, 이에 의해, 방송 경유로 클라이언트측에 파일이 축적되면 바로 브라우저측에서 이용하는 것이 가능하게 된다. 또한, 푸시 이벤트를 네트워크 경유로 송수신할 수 있도록 하는 것은, 클라이언트 방송 미들웨어가 당해 파일 전송 스트림으로 튜닝되어 있지 않은 경우라도, 클라이언트측에서 파일 전송의 사실을 검지할 수 있도록 하기 위함이다.
[8.3. 서비스 워커(SW)의 갱신 처리에 대하여]
이어서, 푸시형 처리를 실행하는 경우의 서비스 워커(SW)의 갱신 처리에 대하여 설명한다.
전술한 바와 같이, 서비스 워커(SW)에는, 이용 기한을 정할 수 있고, 수신 장치(30)는, 필요에 따라, 수신 장치가 유지하는 이용 기한이 도래한 서비스 워커(SW)를 새로운 서비스 워커(SW)로 치환하는 서비스 워커(SW) 갱신 처리를 행할 수 있다.
폴링형 서비스 워커(SW) 갱신 처리 시퀀스는, 앞서 도 18 내지 도 19를 참조하여 설명한 시퀀스로 된다.
푸시형 처리에서는, 미들웨어의 관리 캐시에 대하여 갱신 서비스 워커(SW)의 전개(저장)가 실행된 경우에, 캐시 전개를 브라우저측에 통지시키는 푸시 API 등을 이용한 푸시형 이벤트 통지 기구를 이용한 처리를 행한다.
푸시형 처리에 있어서의 서비스 워커 갱신 처리 시퀀스에 대하여, 도 24를 참조하여 설명한다.
도 24에는, 좌측으로부터, 이하의 각 구성 요소를 도시하고 있다.
(a) 송신 장치를 구성하는 방송 서버
(b) 송신 장치를 구성하는 데이터 배신 서버
(c) 수신 장치의 미들웨어
(d) 수신 장치의 출력 제어부에서 실행되는 브라우저
또한,
(e) 수신 장치의 출력 제어부에서 실행되는 브라우저 상에서 실행되는 서비스 워커(SW)
이들 각 구성 요소를 도시하고 있다.
도 24의 시퀀스도에 도시하는 각 스텝의 처리에 대하여, 순차적으로 설명한다.
또한, 도 24의 시퀀스의 개시 이전에, 이미 앞서 설명한 도 22에 도시한 것과 마찬가지의 각 장치, 구성부 사이에서, 이벤트 등록, 승낙 처리가 실행되어 있는 것으로 한다.
즉, 애플리케이션, 미들웨어 사이, 및 미들웨어와 송신 장치(방송 서버, 데이터 배신 서버) 사이에 있어서, 예를 들어 도 22에 도시하는 스텝 S321a, S321b에 나타내는 이벤트 등록, 승낙 처리가 실행되어 있다.
이것은, 송신 장치(방송 서버, 데이터 배신 서버)로부터 수신 장치로 송신된 데이터(애플리케이션, 애플리케이션 관련 데이터, 서비스 워커(SW) 등)가, 미들웨어의 프록시 서버 관리 캐시에 전개(저장)된 경우에, 애플리케이션에 통지하는 처리의 실행을 각 장치 또는 구성부가 승낙하여 실행하는 것을 확인하는 처리이다.
도 24에 도시하는 시퀀스는, 이들 이벤트 등록, 승낙 처리가 실행된 후의 처리에 상당한다.
도 24의 시퀀스도에 도시하는 각 스텝의 처리에 대하여, 순차적으로 설명한다.
(스텝 S351)
스텝 S351a 내지 S351d는, 송신 장치(방송 서버, 데이터 배신 서버)로부터 수신 장치로 송신된 데이터(본 예에서는 갱신 서비스 워커(SW))가, 미들웨어의 프록시 서버 관리 캐시에 전개(저장)되었음을, 애플리케이션 또는 서비스 워커(SW)에 통지하는 처리이다.
또한, 도면에는, 스텝 S351a 내지 S351d의 4개의 이벤트 통지 라인을 도시하고 있지만, 스텝 S351a, S351b에 대해서는, 데이터 송신을 실행한 어느 장치가 이벤트 통지를 실행하면 된다.
또한, 스텝 S351c, S351d의 미들웨어로부터의 통지 처리는, 애플리케이션 또는 서비스 워커(SW) 중 어느 것에 대해서만 실행하면 된다.
(스텝 S352)
스텝 S352는, 수신 장치의 출력 제어부에서 실행되는 브라우저의 처리이다.
브라우저는, 이벤트 통지에 기초하여, 갱신 서비스 워커(SW)의 로컬 프록시 서버에 대한 취득 리퀘스트를 행한다.
(스텝 S353)
스텝 S353의 처리는, 수신 장치(30)의 미들웨어의 처리이다. 미들웨어는, 프록시 서버의 관리 캐시에, 브라우저로부터 취득 요구가 있는 갱신된 서비스 워커(SW)의 검색을 행하여, 검출된 경우, 갱신된 서비스 워커(SW)를 브라우저에 출력한다.
(스텝 S354)
스텝 S354는, 수신 장치의 출력 제어부에서 실행되는 브라우저의 처리이다.
브라우저는, 프록시 서버로부터 수령한 갱신 후의 서비스 워커(SW)를 등록한다. 즉, 기억부(영속 캐시)에 저장한다.
(스텝 S355)
스텝 S355는, 수신 장치의 출력 제어부에서 실행되는 서비스 워커(SW)의 처리이다. 여기서는, 새롭게 등록된 갱신 후의 서비스 워커(SW)의 처리를 나타내고 있다.
갱신 후의 서비스 워커(SW)는, 필요에 따라, 토큰 정보의 설정 요구를 미들웨어에 대하여 실행한다.
토큰 정보의 설정은, 전술한 도 11의 스텝 S251의 처리와 마찬가지의 처리이다. 즉, 예를 들어 도 7에 도시하는 미들웨어(110)의 시그널링 해석부(113)에 대하여, 시그널링 데이터에 포함되는 어느 클래스의 서비스 워커(SW) 액세스 정보를 검출해야 할지를 나타내는 토큰 정보를 통지하여, 시그널링 해석부(113)에 검출해야 할 클래스의 서비스 워커(SW)의 액세스 정보를 판별 가능한 상태로 설정한다.
또한, 이 스텝 S355의 처리에 병행하여, 스텝 S355a에 나타내는 이벤트 등록/승낙 처리를 실행한다. 이것은, 토큰 정보에 따른 데이터가 미들웨어의 프록시 서버에 전개(저장)된 경우에, 서비스 워커(SW) 또는 애플리케이션에 통지시키기 위한 처리이다.
(스텝 S356)
스텝 S356의 처리는, 수신 장치(30)의 미들웨어의 처리이다. 즉 데이터 수신 및 수신 데이터의 해석 등의 처리를 행하는 미들웨어의 처리이다. 미들웨어는, 갱신 후의 서비스 워커(SW)로부터 통지된 토큰 정보를 설정하고, 설정한 토큰 정보에 기초하여, 시그널링 데이터로부터의 토큰(혹은 파일 URL) 검출을 실행한다.
[8.4. 서비스 워커(SW)에 의한 수신 장치의 기억부(영속 캐시)의 제어 처리에 대하여]
푸시형 처리에 있어서도, 수신 장치(30)에 저장된 서비스 워커(SW)에 의한 수신 장치의 기억부(영속 캐시)의 제어 처리 시퀀스는, 앞서 도 20 내지 도 21을 참조하여 설명한 폴링형의 처리예와 마찬가지의 처리로 된다.
[9. 토큰을 기술하는 시그널링 데이터(메타데이터)의 구성에 대하여]
우선, 도 14 내지 도 17을 참조하여 설명한 바와 같이, 예를 들어 방송 서버(21) 등의 송신 장치(20)로부터 송신되는 시그널링 데이터(메타데이터)에는, 수신 장치(30)에 있어서의 취득 데이터의 선택을 효율화하기 위한 토큰(혹은 URL)이 기술되어 있다.
이하, 시그널링 데이터(메타데이터)에 대한 토큰(혹은 URL)의 구체적인 기록 구성예에 대하여 설명한다.
도 25는, 예를 들어 방송 서버(21) 등의 송신 장치(20)로부터 송신되는 시그널링 데이터(메타데이터)의 구성예를 도시하는 도면이다.
시그널링 데이터(메타데이터)는, 도 25에 도시하는 바와 같이, 이하의 3개의 레이어를 갖는다.
(1) 서비스 레이어(OMA-ESG)
(2) 파일 전송 세션 레이어(3GPP-MBMS-USD)
(3) FLUTE(ROUTE) 파라미터 레이어(FLUTE(ROUTE))
(1) 서비스 레이어는, 특히 유저 제시를 목적으로 한 서비스나 콘텐츠의 속성 정보를 기술하는 레이어이다.
(2) 파일 전송 세션 레이어는, 파일의 전송 파라미터 등을 기술하는 레이어이다.
(3) FLUTE(ROUTE) 파라미터 레이어는, FLUTE(ROUTE) 프로토콜 대응의 파라미터를 기술하는 레이어이다.
(1) 서비스 레이어는, 소위 프로그램표 등을 기록하는 OMA-ESG(Open Mobile Alliance-Electronic Service Guide) 이하에, 예를 들어 이하의 속성 정보(요소) 기록 영역(프래그먼트)이 설정되어 있다.
(a) 서비스 프래그먼트(Service Fragment)
(b) 콘텐츠 프래그먼트(Content Fragment)
(c) 인터랙티비티 데이터 프래그먼트(InteractivityData Fragment)
(d) 스케줄 프래그먼트(Schedule Fragment)
(e) 액세스 프래그먼트(Access Fragment)
이들은 각각 상이한 종류의 속성 정보를 기록하는 영역으로서 구분되어 있다.
또한, OMA-ESG에는, 이 밖에도 복수의 속성 정보(요소) 기록 영역(프래그먼트)이 설정되지만, 상기 (a) 내지 (e)의 속성 정보(요소) 기록 영역(프래그먼트)을 전술한 토큰의 기록 영역으로서 설정한 예에 대하여, 후단에서 설명한다.
또한, 도면에 도시하는 화살표는, 각 속성 정보(요소) 기록 영역(프래그먼트) 사이의 참조 관계를 나타내고 있다.
예를 들어 (a) 서비스 프래그먼트로부터 (d) 스케줄 프래그먼트로 연장되는 화살표는, (a) 서비스 프래그먼트에 기록된 개개의 서비스(예를 들어 채널이나 프로그램) 대응의 배신 스케줄 정보가 (d) 스케줄 프래그먼트에 기록되어 있음을 나타낸다.
또한, 파일 전송 세션 레이어는, 서비스 단위의 시그널링 데이터인 USD(유저 서비스 디스크립션) 이하에 예를 들어 이하의 속성 정보(요소) 기록 영역(프래그먼트)이 설정되어 있다.
(f) 스케줄 프래그먼트(Schedule Fragment)
(g) 필터 디스크립션 프래그먼트(FilterDescription Fragment)
USD(유저 서비스 디스크립션)에는, 이 밖에도 복수의 속성 정보(요소) 기록 영역(프래그먼트)이 설정되지만, 상기 (f) 내지 (g)의 속성 정보(요소) 기록 영역(프래그먼트)을 전술한 토큰의 기록 영역으로서 설정한 예에 대하여, 후단에서 설명한다.
[9.1. 시그널링 데이터(메타데이터)를 구성하는 OMA-ESG에 대한 토큰 기록예에 대하여]
앞서 도 25를 참조하여 설명한 바와 같이,
시그널링 데이터(메타데이터)는, 도 25에 도시하는 바와 같이, 이하의 3개의 레이어를 갖는다.
(1) 서비스 레이어(OMA-ESG)
(2) 파일 전송 세션 레이어(3GPP-MBMS-USD)
(3) FLUTE(ROUTE) 파라미터 레이어(FLUTE(ROUTE))
우선, (1) 서비스 레이어(OMA-ESG)에 대한 토큰 기록예에 대하여 설명한다.
서비스 레이어(OMA-ESG)에 설정되는 속성 정보(요소) 기록 영역(프래그먼트) 중 토큰을 저장하는 데 어울리는 프래그먼트에는, 전술한 바와 같이, 이하의 속성 정보(요소) 기록 영역(프래그먼트)이 있다.
(a) 서비스 프래그먼트(Service Fragment)
(b) 콘텐츠 프래그먼트(Content Fragment)
(c) 인터랙티비티 데이터 프래그먼트(InteractivityData Fragment)
(d) 스케줄 프래그먼트(Schedule Fragment)
(e) 액세스 프래그먼트(Access Fragment)
(a) 서비스 프래그먼트(Service Fragment)는, 채널이나 스트리밍 서비스라고 하는 서비스 레이어의 속성을 기술하는 프래그먼트이다.
(b) 콘텐츠 프래그먼트(Content Fragment)는, 서비스 프래그먼트(Service Fragment)를 구성하는 각각의 콘텐츠(서비스가 채널을 기술하는 경우에는 프로그램 등의 단위)를 기술하는 프래그먼트이다.
(d) 스케줄 프래그먼트(Schedule Fragment)는, 서비스(Service), 콘텐츠(Content), 인터랙티비티 데이터(InteractivityData)를 시간축 상(프로그램 배신 스케줄, 프로그램 제시 스케줄 등)에 매핑하기 위한 프래그먼트이다.
(e) 액세스 프래그먼트(Access Fragment)는, 스케줄(Schedule) 프래그먼트의 배신 스케줄과 함께 실제의 파일이나 스트림의 어드레스를 기술하기 위한 프래그먼트이다.
이들 각각의 속성 정보(요소) 기록 영역(프래그먼트)에는, 여러 가지 데이터를 기록 가능한 확장 영역인 프라이베이트 익스텐션(PrivateExtension) 요소가 설정되어 있다.
예를 들어, OMA와는 상이한 표준화 단체에 있어서, 이 스키마 정의를 이용하여 기능 요소를 추가하기 위해 새로운 요소가 필요하게 된 경우에는, 이 확장 영역 하에, 여러 가지 요소를 추가 규정할 수 있다. 단, OMA 자신이 스키마를 확장하는 경우, 혹은 다른 표준화 단체 자신이 전체 스키마를 변경할 수 있는 경우에는 추가 요소 그 자체를 프라이베이트 익스텐션(PrivateExtension) 요소 상에 저장하도록 정의된다.
예를 들어, (a) 서비스 프래그먼트(Service Fragment)는, 도 26에 도시하는 구성을 갖는다.
도 26에 도시하는 바와 같이, 프라이베이트 익스텐션(PrivateExtension) 데이터 기록 영역(201)의 하위에 토큰 기록 영역(202)을 설정할 수 있다.
이것은, 예를 들어 앞서 도 15를 참조하여 설명한 도 15의 (1) 토큰 설정예 1에 도시하는 서비스 메타데이터(161)에, 「서비스 워커(SW) 검색 스코프 토큰 <SW-Scope>」를 기록하는 경우의 예에 대응한다.
도 26에 도시하는 토큰 기록 영역(202)에는, 토큰을 예를 들어, XML 데이터로서 기록한다.
토큰의 XML 스키마 정의는, 예를 들어 이하의 설정으로 한다.
<xs:element name="SWClass" type="xs:string" xmlns: xs="http://www.w3.org/2001/XMLSchema"/>
상기 설정의 문자열 표현으로서 인코딩한다.
또한, 서비스 프래그먼트(Service Fragment)의 XML 인스턴스의 예는, 예를 들어 이하의 설정으로 된다.
<Service>
…
<PrivateExt>
<SWClass> SW 클래스의 문자열 </SWClass>
</PrivateExt>
</Service>
[9.2. 시그널링 데이터(메타데이터)를 구성하는 USD에 대한 토큰 기록예에 대하여]
앞서 도 25를 참조하여 설명한 바와 같이,
시그널링 데이터(메타데이터)는, 도 25에 도시하는 바와 같이, 이하의 3개의 레이어를 갖는다.
(1) 서비스 레이어(OMA-ESG)
(2) 파일 전송 세션 레이어(3GPP-MBMS-USD)
(3) FLUTE(ROUTE) 파라미터 레이어(FLUTE(ROUTE))
이하, (2) 파일 전송 세션 레이어(3GPP-MBMS-USD)에 토큰을 기록하는 예에 대하여 설명한다.
서비스 단위의 시그널링 데이터인 USD(유저 서비스 디스크립션)에 설정되는 속성 정보(요소) 기록 영역(프래그먼트) 중 토큰을 저장하는 데 어울리는 프래그먼트에는, 전술한 바와 같이, 이하의 속성 정보(요소) 기록 영역(프래그먼트)이 있다.
(f) 스케줄 프래그먼트(Schedule Fragment)
(g) 필터 디스크립션 프래그먼트(FilterDescription Fragment)
USD(유저 서비스 디스크립션)는 서비스를 구성하는 트랜스포트 세션의 속성을 저장하는 허브적인 요소이다.
USD(유저 서비스 디스크립션)의 전체 구성예를 도 27에 도시한다.
USD(유저 서비스 번들 디스크립션)(210)는, 복수의 USD(유저 서비스 디스크립션)(211)의 집합이다.
도 27에 도시하는 백색 마름모꼴 화살표는, 백색 화살표측의 요소가 접속 요소를 포함하는(include) 것을 의미한다.
통상, 화살표는 참조(reference) 관계를 나타낸다.
USD(유저 서비스 디스크립션)(211)의 하위에는,
스케줄(Schedule) 요소(212)가 설정된다. 또한, 요소는 프래그먼트와 동의이다.
스케줄(Schedule) 요소(212) 차례에, 스케줄 디스크립션(Schedule Description) 요소(213), 나아가 그 하위에 필터 디스크립션(Filter Description) 요소(214)가 설정된다.
USD 요소(211) 하의 스케줄(Schedule) 요소(212)는, 트랜스포트 세션의 배신 스케줄을 기술한다. 이 스케줄(Schedule) 요소(212)로부터 참조되는 스케줄 디스크립션(Schedule Description) 요소(213)로부터, 이 스케줄로 배신되는 서비스(스트림 세션이나 파일 세션)를 선택적으로 취득할 때 이용할 필터링에 이용하는 파라미터를 저장하는 필터 디스크립션(FilterDescription) 요소(214)를 참조시킬 수 있다.
도 28에, 시그널링 데이터를 구성하는 USD(유저 서비스 번들 디스크립션)(210) 이하의 계층 구성예를 도시한다.
USD(유저 서비스 번들 디스크립션)(210) 이하,
USD(유저 서비스 디스크립션) 요소(211),
스케줄(Schedule) 요소(212)
이들 각 요소가 설정된다.
스케줄(Schedule) 요소(212) 중에, 스케줄 디스크립션(Schedule Description) 요소(213)의 식별 정보로서의 스케줄 디스크립션 URI(212a)가 기록된다.
이 스케줄 디스크립션 URI(212a)에 기초하여, 스케줄 디스크립션(Schedule Description) 요소(213)가 특정된다.
또한, USD(유저 서비스 디스크립션) 요소(211) 이하에 설정되는 딜리버리 메소드(deliveryMethod) 요소에는 FLUTE(ROUTE)에 대한 참조 정보가 저장된다. 이 구성에 대해서는 후술한다.
도 29는, 스케줄 디스크립션(Schedule Description) 요소(213) 이하의 시그널링 데이터 구성을 도시하는 도면이다.
스케줄 디스크립션(Schedule Description) 요소(213) 이하에, 애트리뷰트(속성)(Attribute) 데이터(222)가 설정되고, 애트리뷰트(속성)(Attribute) 데이터(222) 내에, 특정한 필터 디스크립션 요소를 식별하기 위한 식별 정보인 필터 디스크립션 레퍼런스(filter Description Reference)(223)가 기록된다.
또한, 스케줄 디스크립션(Schedule Description) 요소(213) 이하에 기록되는 하나의 애트리뷰트(속성)(Attribute) 데이터(224)에, 특정한 필터를 식별하기 위한 식별 정보인 필터 ID(filter ID)(225)가 기록된다.
도 30은, 필터 디스크립션 레퍼런스(filter Description Reference)(223)에 의해 특정되는 필터 디스크립션(filter Description) 요소(231)의 데이터 구성을 도시하고 있다.
필터 디스크립션(filter Description) 요소(231) 이하에는, 각 필터 대응의 데이터를 설정하는 필터 데이터(filterData) 요소(232)가 설정된다.
또한, 필터 데이터(filterData) 요소(232)의 애트리뷰트(속성)(attribute)(233)에는, 도 29의 데이터 구성에 도시하는 필터 ID(filter ID)(225)에 대응하는 id 데이터(234)가 기록된다.
또한, 필터 데이터(filterData) 요소(232) 이하의 데이터 기록 영역에 상술한 토큰(235)을 기록한다.
이것은, 예를 들어 앞서 도 17을 참조하여 설명한 도 17의 (4) 토큰 설정예 4에 도시하는 스케줄 디스크립션(168)에, 「서비스 워커(SW) 검색 스코프 토큰 <SW-Scope>」를 기록하는 경우의 예에 대응한다.
토큰(235)은, 예를 들어 XML 데이터로서 기록한다.
토큰의 XML 스키마 정의는, 예를 들어 이하의 설정으로 한다.
<xs:element name="SWClass" type="xs:string" xmlns: xs="http://www.w3.org/2001/XMLSchema"/>
로서, 문자열 표현으로서 인코딩한다.
또한, 필터 디스크립션(filterDescription) 프래그먼트의 XML 인스턴스의 예는, 예를 들어 이하의 설정으로 된다.
<filter Description>
…
<filterData>
<SWClass> SW 클래스의 문자열 </SWClass>
</filterData>
</filterDescription>
[USD로부터 FLUTE/ROUTE로의 참조 처리예에 대하여]
수신 장치(30)가, 토큰을 이용하여 선택 취득하는 데이터는, 애플리케이션, 및 애플리케이션 관련 데이터, 혹은 서비스 워커(SW) 등의 파일이며, 이들은 FLUTE/ROUTE 프로토콜에 따라 전송된다.
수신 장치(30)는, 예를 들어 상술한 시그널링 데이터인 USD 등에 기재된 토큰에 기초하여, FLUTE/ROUTE 프로토콜에 따라 전송되는 파일을 식별하여 취득하는 것이 필요하게 된다.
이하, 이 처리를 위한 구성에 대하여, 도 31 이하를 참조하여 설명한다.
도 31은, 앞서 도 28을 참조하여 설명한 것과 마찬가지로, 시그널링 데이터를 구성하는 USD(유저 서비스 번들 디스크립션)(210) 이하의 계층 구성예를 도시하는 도면이다.
USD(유저 서비스 번들 디스크립션)(210) 이하,
USD(유저 서비스 디스크립션) 요소(211),
스케줄(Schedule) 요소(212)
이들 각 요소가 설정된다.
USD(유저 서비스 디스크립션) 요소(211) 이하에 설정되는 딜리버리 메소드(deliveryMethod) 요소(241)에 FLUTE(ROUTE)에 대한 참조 정보가 저장된다.
도 32는, 파일 전송을 FLUTE 프로토콜에 따라 실행하는 경우에, 딜리버리 메소드(deliveryMethod) 요소(241)에 설정되는 FLUTE에 대한 참조 정보의 예를 도시하는 도면이다.
도 32에 도시하는 바와 같이, 딜리버리 메소드(deliveryMethod) 요소(241) 이하에 설정되는 애트리뷰트(속성)(Attribute)(242) 중, 세션 디스크립션 URI(sessionDescriptionURI) 속성(243)으로부터 참조되는 SDP로서, 도 32에 도시하는 이하의 정보가 기록된다.
v=…
o=…
s=…
t=…
a=ATSC-mode: Frequency PipeID(BBPStreamID) {주파수와 그 주파수 내의modulation/coding 파라미터 등이 상이한 전송 파이프의 ID}
a=flute-tsi: (TSI-TransportSessionIdentifier)
s=sourceFilter: IN IP4 IP Address(소스 IP 어드레스)
m=APPLICATION port(포트 번호) FLUTE/UDP
c=IN IP4 IPAddress(데스티네이션 IP 어드레스)
이 정보에 따라 특정되는 파일 특정 구성을 도 33에 도시한다.
FLUTE(ROUTE) 프로토콜에 의해 전송되는 파일은, 모두 IP 패킷 상의 UDP 패킷 상의 LCT 패킷에 저장되어 전송된다.
FLUTE의 경우에는, SDP로 지시되는 소스 IP 어드레스(SourceIPAddress), 데스티네이션 IP 어드레스(DestinationIPAddress), 포트 번호(Port), TSI로 특정된다. 이것은 FLUTE 세션 단위로 실행된다.
소스 IP 어드레스(SourceIPAddress), 데스티네이션 IP 어드레스(DestinationIPAddress)가 IP 패킷의 특정에, 포트 번호(Port)가 UDP 패킷의 특정에, TSI가 LCT 패킷열의 특정에 이용된다.
또한, LCT 패킷에 저장되는 TOI(TransportObjectIdentifier)에 의해 원하는 파일이 특정된다.
TOI가 0인 LCT 패킷에는 FDT(File Description Table)가 저장되고, 동일한 TSI로 특정되는 트랜스포트 세션 내의 다른 파일 오브젝트에 대하여, 각각의 파일 URL(FDT-Instance/File/＠ContentLocatoin에 저장)과, 대응하는 TOI(FDT-Instance/File/＠TOI에 저장)의 관계가 해결된다.
한편, 도 34는, 파일 전송을 ROUTE 프로토콜에 따라 실행하는 경우에, 딜리버리 메소드(deliveryMethod) 요소(241)에 설정되는 FLUTE에 대한 참조 정보의 예를 도시하는 도면이다.
도 34에 도시하는 바와 같이, 딜리버리 메소드(deliveryMethod) 요소(241) 이하에 설정되는 애트리뷰트(속성)(Attribute)(242) 중, 세션 디스크립션 URI(sessionDescriptionURI) 속성(243)으로부터 참조되는 SDP로서, 도 34에 도시하는 이하의 정보가 기록된다.
v=…
o=…
s=…
t=…
a=ATSC-mode: Frequency PipeID(BBPStreamID) {주파수와 그 주파수 내의 modulation/coding 파라미터 등이 상이한 전송 파이프의 ID}
s=sourceFilter: IN IP4 IP Address(소스 IP 어드레스)
m=APPLICATION port(포트 번호) ROUTE/UDP
c=IN IP4 IP Address(데스티네이션 IP 어드레스)
이들 정보에 따라 특정되는 파일 특정 구성을 도 35에 도시한다.
ROUTE의 경우에는, SDP로 지시되는 소스 IP 어드레스(SourceIPAddress), 데스티네이션 IP 어드레스(DestinationIPAddress), 포트 번호(Port)로 특정된다. 이것은, ROUTE 세션 단위로 실행된다.
소스 IP 어드레스(SourceIPAddress), 데스티네이션 IP 어드레스(DestinationIPAddress)가 IP 패킷의 특정에, Port 번호가 UDP 패킷의 특정에 이용된다.
ROUTE 세션에는, LCT 패킷의 TSI가 0이고 TOI가 0인 LCT 패킷에 LSID(LCT Session Instance Description)가 저장되고, ROUTE 세션 내의 다른 트랜스포트 세션(LCT 패킷의 TSI로 특정됨)에 대한 속성이 저장된다. LSID의 TransportSession/SourceFlow/EFDT/File 요소의 속성인 ContentLocation 속성과 TOI 속성에 의해 파일 URL과 대응하는 TOI와의 관계가 해결된다.
클라이언트 미들웨어는, FLUTE의 FDT(FDT-Instance) 혹은 ROUTE의 LSID를 퍼스(해석)하여 그 파일 전송 세션에서 전송되는 파일 URL을 알 수 있다.
[9.3. 시그널링 데이터(메타데이터)를 구성하는 FLUTE(ROUTE) 파라미터 레이어에 대한 토큰 기록예에 대하여]
앞서 도 25를 참조하여 설명한 바와 같이,
시그널링 데이터(메타데이터)는, 도 25에 도시하는 바와 같이, 이하의 3개의 레이어를 갖는다.
(1) 서비스 레이어(OMA-ESG)
(2) 파일 전송 세션 레이어(3GPP-MBMS-USD)
(3) FLUTE(ROUTE) 파라미터 레이어(FLUTE(ROUTE))
이하, (3) FLUTE(ROUTE) 파라미터 레이어(FLUTE(ROUTE))에 토큰을 기록하는 예에 대하여 설명한다.
FLUTE(ROUTE) 파라미터 레이어에 있어서, 토큰을 저장하는 데 어울리는 요소에는, FLUTE 파일 전송 세션 전체를 기술하는 FDT 인스턴스(FDT-Instance) 요소, 혹은 그 세션 중에서 운반되는 개개의 파일의 속성을 기술하는 파일(File) 요소가 있다.
예를 들어 파일(File) 요소의 속성인 콘텐츠 로케이션(Content-Location) 속성에, 파일 URL이 저장된다.
이 FDT-Instance 요소의 속성, 혹은 File 요소의 속성에 토큰을 기록하는 구성에 대하여, 도 36 이하를 참조하여 설명한다.
도 36은, 시그널링 데이터를 구성하는 FLUTE(ROUTE) 파라미터 레이어 내의 FDT 인스턴스 요소 이하의 데이터 저장 구성을 도시하는 도면이다.
FDT 인스턴스(FDT Instance) 요소(301) 이하에,
FDT 인스턴스 대응의 애트리뷰트(속성)(Attribute)(302),
파일(File) 요소(303)가 설정된다.
또한, 파일(File) 요소(303) 이하에,
파일 대응의 애트리뷰트(속성)(Attribute)(304)가 설정된다.
FDT 인스턴스 대응의 애트리뷰트(속성)(Attribute)(302)와,
파일 대응의 애트리뷰트(속성)(Attribute)(304),
이들의 상세 구성을 도 37에 도시한다.
도 37에 도시하는 바와 같이, 이들 애트리뷰트(속성) 기록 영역에는, 규정의 속성(Attribute) 정보의 기록 영역 외에, 자유로운 데이터를 저장 가능한 데이터 기록 필드(any)가 설정된다.
이 데이터 기록 필드(any)(311, 312)에 토큰을 기록한다.
이 토큰 기록예는, 예를 들어 앞서 도 15를 참조하여 설명한 도 15의 (1) 토큰 설정예 1에 도시하는 최하층의 ROUTE 메타데이터(162, 163)에, 「서비스 워커(SW) 클래스 지정 토큰 <SW-Class>」를 기록하는 경우의 예에 대응한다.
또한, 파일 대응의 애트리뷰트(속성)(Attribute)(304) 내의 이미 결정된 콘텐츠 로케이션(Content-Location) 기록 영역에는 파일 URL이 기록된다.
FDT 인스턴스 대응의 애트리뷰트(속성)(Attribute)(302)와, 파일 대응의 애트리뷰트(속성)(Attribute)(304) 내의 데이터 기록 필드(any)(311, 312)에 기록하는 토큰은, 예를 들어 XML 데이터로서 기록한다.
토큰의 XML 스키마 정의는, 예를 들어 이하의 설정으로 한다.
<xs:attribute name="SWClass" type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema"/>
상기 설정의 문자열 표현으로서 인코딩한다.
토큰을 도 37의 (a)에 도시하는 바와 같이, FDT 인스턴스(FDT-Instance) 요소에 저장한 경우의 XML 인스턴스의 예는, 예를 들어 이하의 설정으로 된다.
<FDT-Instance‥SWClass="SW 클래스의 문자열"…>
…
</FDT-Instance>
또한, FDT 인스턴스(FDT-Instance) 요소의 속성에 예를 들어 「서비스 워커(SW) 검색 스코프 토큰 <SW-Scope>」가 배치된 경우에는, 이 파일 전송 세션 중의 파일의 어느 것에 원하는 서비스 워커(SW) 관련 파일이 저장되어 있음을 나타낸다.
한편, 「서비스 워커(SW) 클래스 지정 토큰 <SW-Class>」가 배치된 경우에는, 이 파일 전송 세션 중 모든 파일이 원하는 서비스 워커(SW) 관련 파일임을 나타낸다.
토큰을 도 37의 (b)에 도시하는 바와 같이, 또한 파일(File) 요소에 저장한 경우의 XML 인스턴스의 예는, 이하와 같이 된다.
<FDT-Instance>
…
<File… SWClass="SW 클래스의 문자열"…>
…
</FDT-Instance>
파일(File) 요소의 속성에는, 「서비스 워커(SW) 클래스 지정 토큰 <SW-Class>」만이 배치 가능하며, 이 파일이 원하는 서비스 워커(SW) 관련 파일임을 나타낸다.
한편, ROUTE에 대해서는, ROUTE로 규정하고 있는 시그널링 데이터로서의 LSID 중에 FLUTE로 규정하고 있는 File 요소가 저장된다.
도 38에 ROUTE로 규정하고 있는 LSID 이하의 데이터 구성을 도시한다.
도 38에 도시하는 바와 같이,
LSID 요소(351),
트랜스포트 세션(TransportSession) 요소(352),
소스 플로우(SourceFlow) 요소(353),
EFDT 요소(354),
파일(File) 요소(355),
이들의 계층 설정으로 된다.
이 때문에, 서비스 워커(SW) 토큰(SW 검색 스코프 토큰, SW 클래스 지정 토큰)을 저장하는 데 어울리는 요소로서는, 이하의 요소가 있다.
(a) EFDT 요소(354) 단위의 애트리뷰트(속성)(Attribute) 데이터 요소(361),
(b) 파일(file)(355) 단위의 애트리뷰트(속성)(Attribute) 데이터 요소(362),
(c) EFDT 요소(354) 단위의 애플리케이션 식별자(ApplicationIdentifier) 요소(363)
이들 각 요소가 후보로 된다.
(a) EFDT 요소(354) 단위의 애트리뷰트(속성)(Attribute) 데이터 요소(361),
(b) 파일(File)(355) 단위의 애트리뷰트(속성)(Attribute) 데이터 요소(362),
이들의 상세 구성을 도 39에 도시한다.
도 39에 도시하는 바와 같이, 이들 애트리뷰트(속성) 기록 영역에는, 규정의 속성(Attribute) 정보의 기록 영역 외에, 자유로운 데이터를 저장 가능한 데이터 기록 필드(any)가 설정된다.
이 데이터 기록 필드(any)(371, 372)에 토큰을 기록한다.
이 토큰 기록예는, 예를 들어 앞서 도 15를 참조하여 설명한 도 15의 (1) 토큰 설정예 1에 나타내는 최하층의 ROUTE 메타데이터(162, 163)에, 「서비스 워커(SW) 클래스 지정 토큰 <SW-Class>」를 기록하는 경우의 예에 대응한다.
또한, 파일 대응의 애트리뷰트(속성)(Attribute)(362) 내의 이미 결정된 콘텐츠 로케이션(Content-Location) 기록 영역에는 파일 URL이 기록된다.
토큰을 도 39의 (a)에 도시하는 바와 같이, EFDT 인스턴스(EFDT-Instance) 요소에 저장한 경우의 XML 인스턴스의 예는, 예를 들어 이하의 설정으로 된다.
<LSID>
…
<TransportSession>
…
<SourceFlow>
…
<EFDT…SWClass="SW 클래스의 문자열"…>
…
</EFDT>
…
</SourceFlow>
…
</TransportSession>
…
</LSID>
또한, 토큰을, 도 38에 도시하는 EFDT 요소(354) 단위의 애플리케이션 식별자(ApplicationIdentifier) 요소(363)에 저장한 경우의 XML 인스턴스의 예는, 이하와 같이 된다.
<LSID>
…
<TransportSession>
…
<SourceFlow>
…
<ApplicationIdentifier> SW 클래스의 문자열 <ApplicationIdentifier>
…
</SourceFlow>
…
</TransportSession>
…
</LSID>
LSID/TransportSession/SourceFlow/ApplicationIdentifier 요소에 「서비스 워커(SW) 검색 스코프 토큰 <SW-Scope>」가 배치된 경우에는, 이 파일 전송 세션 중의 파일의 어느 것에 원하는 서비스 워커(SW) 관련 파일이 저장되어 있음을 나타낸다.
한편, 「서비스 워커(SW) 클래스 지정 토큰 <SW-Class>」가 배치된 경우에는, 이 파일 전송 세션 중 모든 파일이 원하는 서비스 워커(SW) 관련 파일임을 나타낸다.
또한, 토큰을 도 39의 (b)에 도시하는 바와 같이, 파일(File) 요소에 저장한 경우의 XML 인스턴스의 예는, 예를 들어 이하의 설정으로 된다.
<EFDT>
…
<File…SWClass="SW 클래스의 문자열"…>
…
</EFDT>
또한, 파일(File) 요소의 속성에는, 「서비스 워커(SW) 클래스 지정 토큰 <SW-Class>」만이 배치 가능하며, 이 파일이 원하는 서비스 워커(SW) 관련 파일임을 나타낸다.
[10. 서비스 워커(SW)가 이용 가능한 API에 의한 캐싱의 최적화 처리예에 대하여]
이어서, 수신 장치(30)에 있어서 실행하는 서비스 워커(SW)가 이용 가능한 API에 의한 캐싱의 최적화 처리예에 대하여 설명한다.
전술한 실시예는, 서비스 워커(SW)를 클래스 분류하여, 서비스 워커(SW) 자체를 캐싱 폴리시마다 준비하는 모델이다.
이 모델은, 폴리시의 종류가 적은 경우에는, 효과가 있지만, 클라이언트의 환경에 따른 매우 세심한 제어를 행할 수 있도록 하는 경우에는, 서비스 워커(SW)의 종류(클래스)가 방대해질 우려가 있다. 이 문제에 대처하기 위해, 서비스 워커(SW)는 가능한 한 공통의 것(많아도 수 종류)을 준비하여, 서비스 워커(SW)의 로직 중에서 수신 장치(클라이언트)의 환경 속성을 취득할 API를 적용하여 캐싱의 최적화를 실현하는 것도 가능하다.
즉, API를 적용하여 애플리케이션 실행 환경의 상태 정보나 유저의 시청 정보의 통계 데이터 등을 참조하면서, 캐싱 폴리시를 선택할 수 있도록 하는 실장 모델이다.
도 40 내지 도 41에 도시하는 시퀀스도를 참조하여, API를 적용하여 애플리케이션 실행 환경의 상태 정보나 유저의 시청 정보의 통계 데이터 등을 참조하면서, 캐싱 폴리시를 선택하고, 수신 장치의 기억부(영속 캐시)의 제어 처리 시퀀스에 대하여 설명한다.
도 40 내지 도 41에는, 좌측으로부터, 이하의 각 구성 요소를 도시하고 있다.
(a) 송신 장치를 구성하는 방송 서버
(b) 송신 장치를 구성하는 데이터 배신 서버
(c) 수신 장치의 미들웨어
(d) 수신 장치의 프록시 서버
(e) 수신 장치의 출력 제어부에서 실행되는 브라우저의 관리 하의 기억부(영속 캐시)
(f) 수신 장치의 출력 제어부가 실행하는 브라우저 상에서 실행되는 서비스 워커(SW)
(g) 수신 장치의 출력 제어부가 실행하는 브라우저 상에서 실행되는 애플리케이션
(h) 수신 장치의 출력 제어부에서 실행되는 네이티브 애플리케이션
이들 각 구성 요소를 도시하고 있다.
또한, 네이티브 애플리케이션은, 수신 장치(30)에서 실행되는 애플리케이션이지만, 서비스 워커(SW)의 관리 하에 있는 애플리케이션이 아니라, 예를 들어 콘텐츠(프로그램) 대응의 애플리케이션의 기동 처리 등에 사용되는 애플리케이션이다.
도 40 내지 도 41의 시퀀스도에 도시하는 각 스텝의 처리에 대하여, 순차적으로 설명한다.
(스텝 S401)
스텝 S401의 처리는, 네이티브 애플리케이션에 의한 콘텐츠(프로그램) 대응의 애플리케이션의 기동 처리이다.
상술한 바와 같이, 네이티브 애플리케이션은, 콘텐츠(프로그램) 대응의 애플리케이션의 기동 처리 등에 사용되는 애플리케이션이다.
콘텐츠(프로그램) 대응의 애플리케이션이, 예를 들어 프로그램 중에 내장된 트리거 정보에 기초하여 기동하는 설정인 경우에는, 이 네이티브 애플리케이션에 의한 기동 처리는 불필요하다.
(스텝 S402)
스텝 S402에 있어서, 기동된 애플리케이션이, 서비스 워커(SW)의 등록 처리를 실행한다.
등록 처리에 의해 서비스 워커(SW)는, 기억부(영속 캐시)에 저장되어, 언제라도 이용 가능한 상태로 된다.
이 서비스 워커(SW) 등록 처리는, 서비스 워커(SW) 자신으로부터는, 등록(install) 이벤트의 검출로서 파악되고, 서비스 워커(SW)는, 이 등록(install) 이벤트 검출을 계기로 하여, 스텝 S403의 캐시 제어를 개시한다.
(스텝 S403 내지 S405 및 스텝 S501)
서비스 워커(SW)는, 등록(install) 이벤트를 검출하면, 스텝 S403에 있어서, 예를 들어 스크립트 기술에 따른 기억부(영속 캐시)의 제어를 개시한다.
구체적으로는, 특정 클래스의 서비스 워커(SW), 또는 특정 클래스의 서비스 워커(SW)의 관리 대상으로 되는 리소스(애플리케이션이나 애플리케이션 관련 데이터)의 취득, 캐시 전개(저장) 처리를 개시한다.
이 스텝 S403 내지 S405의 처리 시에는, 스텝 S501에 있어서, API를 적용하여 얻어진 최적 파일 선택 정보에 따른 파일 취득 처리 및 캐시 전개가 실행된다.
API를 적용하여 얻어지는 최적 파일 선택 정보는, 예를 들어 애플리케이션 실행 환경의 상태 정보나 유저의 시청 정보 통계 데이터 등에 기초하여 얻어지는 정보이다.
또한, 특정 클래스의 서비스 워커(SW), 또는 특정 클래스의 서비스 워커(SW)의 관리 대상으로 되는 리소스(애플리케이션이나 애플리케이션 관련 데이터)는, 스텝 S404에 있어서, 방송 서버, 데이터 배신 서버 등의 송신 장치로부터 계속적으로 송신된다.
스텝 S404에서는, 앞서 도 8 내지 도 9를 참조하여 설명한 리소스 송수신 처리에 있어서의 도 8 내지 도 9(A-1 내지 A-2)의 각 스텝의 세그먼트 파일에 대한 처리를, 리소스에 대한 처리로 치환한 처리가 실행된다.
송신 데이터는, 스텝 S405에 있어서, 프록시 서버의 관리 캐시를 통하여, 기억부(영속 캐시)에 전개(저장)된다.
(스텝 S406 내지 S409)
스텝 S406에 있어서, 애플리케이션이 애플리케이션 파츠, 예를 들어 애플리케이션의 실행에 필요한 동화상 파일이나 정지 화상 파일, 혹은 JavaScript(등록 상표) 프로그램, 음성 데이터 등의 애플리케이션 관련 데이터를 서비스 워커(SW)에 요구한다.
이 요구 처리는, 서비스 워커(SW)에 있어서의 페치(fetch) 이벤트 검출에 상당한다.
스텝 S407 내지 S409에 있어서, 서비스 워커(SW)는, 요구된 파츠를 기억부(영속 캐시)로부터 취득하여, 애플리케이션에 제공한다.
이 스텝 S407 내지 S409의 처리 시에는, 스텝 S501에 있어서, API를 적용하여 얻어진 최적 파일 선택 정보에 따른 파일 취득 처리가 실행된다.
API를 적용하여 얻어지는 최적 파일 선택 정보는, 예를 들어 애플리케이션 실행 환경의 상태 정보나 유저의 시청 정보 통계 데이터 등에 기초하여 얻어지는 정보이다.
(스텝 S410 내지 S411)
스텝 S410 내지 S411의 처리는, 서비스 워커(SW)에 의한 액티베이트(activate) 이벤트 검출 시의 처리이다.
액티베이트(activate) 이벤트는, 예를 들어 유저에 의한 리소스의 삭제 요구의 입력이 실행된 경우, 혹은 애플리케이션의 유효 기한이 끝난 경우 등에 검출된다.
서비스 워커(SW)가, 액티베이트(activate) 이벤트를 검출하면, 예를 들어 스크립트 기술에 따른 기억부(영속 캐시)의 제어를 개시한다.
구체적으로는, 특정 클래스의 서비스 워커(SW), 또는 특정 클래스의 서비스 워커(SW)의 관리 대상으로 되는 리소스(애플리케이션이나 애플리케이션 관련 데이터)의 삭제 처리 등을 행한다.
이 스텝 S410 내지 S411의 처리 시에는, 스텝 S502에 있어서, API를 적용하여 얻어진 최적 파일 선택 정보에 따른 파일 삭제가 실행된다.
API를 적용하여 얻어지는 최적 파일 선택 정보는, 예를 들어 애플리케이션 실행 환경의 상태 정보나 유저의 시청 정보 통계 데이터 등에 기초하여 얻어지는 정보이다.
(스텝 S412 내지 S415)
스텝 S412 내지 S415의 처리는, 서비스 워커(SW)에 의한 타이머 이벤트 검출 시의 처리이다.
타이머 이벤트는, 예를 들어 애플리케이션의 유효 기한이 끝난 경우, 갱신 기한이 도래한 경우 등에 검출된다.
타이머 이벤트에 따른 처리로서는, 예를 들어 캐시 리소스의 삭제, 혹은 갱신 리소스나 추가 리소스의 취득 처리 등이 있다.
이 스텝 S412 내지 S415의 처리 시에는, 스텝 S502에 있어서, API를 적용하여 얻어진 최적 파일 선택 정보에 따른 파일 삭제 또는 취득 처리 및 캐시 전개가 실행된다.
API를 적용하여 얻어지는 최적 파일 선택 정보는, 예를 들어 애플리케이션 실행 환경의 상태 정보나 유저의 시청 정보 통계 데이터 등에 기초하여 얻어지는 정보이다.
스텝 S413은, 타이머 이벤트에 따른 캐시 리소스의 삭제 처리의 시퀀스이다.
스텝 S414 내지 S415는, 타이머 이벤트에 따른 갱신 리소스나 추가 리소스의 취득 처리의 시퀀스를 나타내고 있다.
또한, 스텝 S414에서는, 앞서 도 8 내지 도 9를 참조하여 설명한 리소스 송수신 처리에 있어서의 도 8 내지 도 9(A-1 내지 A-2)의 각 스텝의 세그먼트 파일에 대한 처리를, 리소스에 대한 처리로 치환한 처리가 실행된다.
[11. 송신 장치와 수신 장치의 구성예에 대하여]
이어서, 통신 장치인 송신 장치(서버)(20)와, 수신 장치(클라이언트)(30)의 장치 구성예에 대하여, 도 42, 도 43을 참조하여 설명한다.
도 42에는, 송신 장치(서버)(20)와, 수신 장치(클라이언트)(30)의 구성예를 도시하고 있다.
송신 장치(서버)(20)는, 데이터 처리부(751), 통신부(752), 기억부(753)를 갖는다.
수신 장치(클라이언트)(30)는, 데이터 처리부(771), 통신부(772), 기억부(773), 입력부(774), 출력부(775)를 갖는다.
데이터 처리부에는 통신 데이터 처리부(771a), 재생 처리부(771b)가 포함된다.
송신 장치(서버)(20)의 데이터 처리부(751)는, 데이터 배신 서비스를 실행하기 위한 각종 데이터 처리를 실행한다. 예를 들어 데이터 배신 서비스의 구성 데이터의 생성이나 송신 제어를 행한다. 또한, 데이터 처리부(751)는, 수신 장치(클라이언트)(30)에 제공하는 애플리케이션, 서비스 워커(SW), 그 밖의 여러 가지 데이터나, 시그널링 데이터의 생성, 송신 처리를 행한다.
통신부(752)는, AV 세그먼트 외에, 애플리케이션, 서비스 워커(SW), 그 밖의 여러 가지 데이터, 시그널링 데이터 등의 배신 등의 통신 처리를 행한다.
기억부(753)는 배신 대상으로 하는 AV 세그먼트, 애플리케이션, 서비스 워커(SW), 애플리케이션에 의해 이용되는 데이터, 시그널링 데이터 등이 저장된다.
또한, 기억부(753)는, 데이터 처리부(751)가 실행하는 데이터 처리의 워크 에어리어로서 이용되고, 또한 각종 파라미터의 기억 영역으로서도 이용된다.
한편, 수신 장치(클라이언트)(30)는, 데이터 처리부(771), 통신부(772), 기억부(773), 입력부(774), 출력부(775)를 갖는다.
통신부(772)는, 송신 장치(서버)(20)로부터 배신되는 데이터, 예를 들어 AV 세그먼트나 애플리케이션, 서비스 워커(SW), 애플리케이션에 의해 이용되는 데이터, 시그널링 데이터 등을 수신한다.
데이터 처리부(771)는, 통신 데이터 처리부(771a), 재생 처리부(771b)를 가지며, 예를 들어 앞서 설명한 실시예에 따른 처리 등을 실행한다.
구체적으로는, 애플리케이션이나 API, 나아가 서비스 워커(SW)를 이용한 데이터 처리 등을 실행한다.
유저의 지시 커맨드, 예를 들어 채널 선택, 애플리케이션 기동, 인스톨 등의 여러 가지 커맨드는 입력부(774)를 통하여 입력된다.
재생 데이터는 표시부나 스피커 등의 출력부(775)에 출력된다.
기억부(773)는 AV 세그먼트, 서비스 워커(SW), 애플리케이션, 애플리케이션에 의해 이용되는 데이터, 시그널링 데이터 등이 저장된다.
또한, 기억부(773)는, 데이터 처리부(771)가 실행하는 데이터 처리의 워크 에어리어로서 이용되고, 또한 각종 파라미터의 기억 영역으로서도 이용된다.
도 43은, 송신 장치(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)의 처리로서 실행 가능하지만, 부호화 처리 혹은 복호 처리를 실행하기 위한 전용 하드웨어로서의 코덱을 구비한 구성으로 해도 된다.
[12. 본 개시의 구성의 정리]
이상, 특정한 실시예를 참조하면서, 본 개시의 실시예에 대하여 상세히 해석하였다. 그러나, 본 개시의 요지를 일탈하지 않는 범위에서 당업자가 실시예의 수정이나 대용을 이룰 수 있는 것은 자명하다. 즉, 예시라고 하는 형태로 본 발명을 개시한 것이며, 한정적으로 해석되어서는 안된다. 본 개시의 요지를 판단하기 위해서는, 특허청구범위란을 참작해야 한다.
또한, 본 명세서에 있어서 개시한 기술은, 이하와 같은 구성을 취할 수 있다.
(1) 수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)로부터, 특정 클래스의 서비스 워커(SW)를 선택 취득하여 이용하는 데이터 처리부를 갖는 수신 장치.
(2) 상기 데이터 처리부는,
수신 장치에 있어서의 데이터 처리 상황에 따라 특정 클래스의 서비스 워커(SW)를 선택 취득하는 (1)에 기재된 수신 장치.
(3) 상기 데이터 처리 상황은, 수신 장치에 있어서의 애플리케이션 또는 데이터의 이용 상황인 (2)에 기재된 수신 장치.
(4) 상기 서비스 워커(SW)는, 관리 대상 데이터로서 애플리케이션, 또는 화상, 또는 음성, 적어도 어느 데이터 파일을 포함하는 (1) 내지 (3) 중 어느 하나에 기재된 수신 장치.
(5) 상기 데이터 처리부는,
송신 장치가 송신하는 메타데이터인 시그널링 데이터로부터, 특정 클래스의 서비스 워커(SW)의 액세스 정보를 취득하고, 취득한 액세스 정보를 이용하여, 서비스 워커(SW)를 취득하는 (1) 내지 (4) 중 어느 하나에 기재된 수신 장치.
(6) 상기 시그널링 데이터에는, 특정 클래스의 서비스 워커(SW)의 액세스 정보를 효율적으로 검색하기 위한 검색 보조 정보인 토큰이 기록되고,
상기 데이터 처리부는,
토큰을 이용한 액세스 정보 검색 처리를 실행하는 (5)에 기재된 수신 장치.
(7) 상기 토큰은,
특정 클래스의 서비스 워커(SW)의 액세스 정보의 검색 범위를 한정 가능하게 한 서비스 워커(SW) 검색 스코프 토큰인 (6)에 기재된 수신 장치.
(8) 상기 토큰은, 특정 클래스의 서비스 워커(SW)의 액세스 정보가 기록되어 있음을 나타내는 서비스 워커(SW) 클래스 지정 토큰인 (6)에 기재된 수신 장치.
(9) 상기 시그널링 데이터는,
(a) 유저 제시를 목적으로 한 서비스 또는 콘텐츠의 속성 정보를 기술하는 서비스 레이어,
(b) 파일 전송 파라미터를 기술한 파일 전송 세션 레이어,
(c) FLUTE(ROUTE) 프로토콜 대응의 파라미터를 기술한 FLUTE(ROUTE) 파라미터 레이어,
상기 (a) 내지 (c)의 레이어를 갖고,
적어도 (a) 내지 (c)의 어느 레이어에 토큰이 기록된 구성인 (6) 내지 (8) 중 어느 하나에 기재된 수신 장치.
(10) 상기 데이터 처리부는, 상기 서비스 레이어, 또는 상기 파일 전송 세션 레이어, 또는 상기 FLUTE(ROUTE) 파라미터 레이어에 기록된 토큰을 취득하는 (9)에 기재된 수신 장치.
(11) 상기 수신 장치의 데이터 처리부에 있어서 실행되는 애플리케이션은, 수신 데이터의 처리를 실행하는 미들웨어에 대하여, 상기 토큰을 검출하기 위한 토큰 정보의 설정 요구를 실행하고,
상기 미들웨어는, 토큰 정보 설정 요구에 따라 설정한 토큰 정보에 기초하여, 토큰 검출을 행하는 (1) 내지 (10) 중 어느 하나에 기재된 수신 장치.
(12) 상기 수신 장치의 데이터 처리부에 있어서 실행되는 데이터 관리 프로그램인 서비스 워커(SW)는, 수신 데이터의 처리를 실행하는 미들웨어에 대하여, 상기 토큰을 검출하기 위한 토큰 정보의 설정 요구를 실행하고,
상기 미들웨어는, 토큰 정보 설정 요구에 따라 설정한 토큰 정보에 기초하여, 토큰 검출을 행하는 (1) 내지 (11) 중 어느 하나에 기재된 수신 장치.
(13) 상기 토큰은,
특정한 서비스 워커(SW)의 관리 대상으로 되는 데이터에 대응하는 액세스 정보의 검색 처리를 효율화하기 위한 정보이며,
상기 데이터 처리부는,
상기 서비스 워커(SW)의 갱신에 따라, 상기 미들웨어에 대하여, 새로운 토큰 정보의 설정 요구를 행하는 (12)에 기재된 수신 장치.
(14) 수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)를 송신하는 송신 장치.
(15) 상기 송신 장치는,
수신 장치에 있어서, 특정 클래스의 서비스 워커(SW)의 액세스 정보를 효율적으로 검색하기 위한 검색 보조 정보인 토큰을 기록한 메타데이터인 시그널링 데이터를 송신하는 (14)에 기재된 송신 장치.
(16) 상기 토큰은,
특정 클래스의 서비스 워커(SW)의 액세스 정보의 검색 범위를 한정 가능하게 한 서비스 워커(SW) 검색 스코프 토큰, 또는
특정 클래스의 서비스 워커(SW)의 액세스 정보가 기록되어 있음을 나타내는 서비스 워커(SW) 클래스 지정 토큰인 (15)에 기재된 송신 장치.
(17) 수신 장치에 있어서 실행하는 데이터 처리 방법이며,
상기 수신 장치의 데이터 처리부가, 수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)로부터, 특정 클래스의 서비스 워커(SW)를 선택 취득하여 이용하는 데이터 처리 방법.
(18) 송신 장치에 있어서 실행하는 데이터 처리 방법이며,
수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)를 송신하는 데이터 처리 방법.
또한, 명세서 중에 있어서 설명한 일련의 처리는 하드웨어 또는 소프트웨어, 혹은 양자의 복합 구성에 의해 실행하는 것이 가능하다. 소프트웨어에 의한 처리를 실행하는 경우에는, 처리 시퀀스를 기록한 프로그램을, 전용 하드웨어에 내장된 컴퓨터 내의 메모리에 인스톨하여 실행시키거나, 혹은 각종 처리가 실행 가능한 범용 컴퓨터에 프로그램을 인스톨하여 실행시키는 것이 가능하다. 예를 들어, 프로그램은 기록 매체에 미리 기록해 둘 수 있다. 기록 매체부터 컴퓨터에 인스톨하는 것 외에, LAN(Local Area Network), 인터넷과 같은 네트워크를 통하여 프로그램을 수신하고, 내장된 하드디스크 등의 기록 매체에 인스톨할 수 있다.
또한, 명세서에 기재된 각종 처리는, 기재에 따라 시계열로 실행될 뿐만 아니라, 처리를 실행하는 장치의 처리 능력 혹은 필요에 따라 병렬적으로 혹은 개별적으로 실행되어도 된다. 또한, 본 명세서에 있어서 시스템이란, 복수의 장치의 논리적 집합 구성이며, 각 구성의 장치가 동일 하우징 내에 있는 것에 한정되지는 않는다.
<산업상 이용가능성>
이상, 설명한 바와 같이, 본 개시의 일 실시예의 구성에 따르면, 각각의 수신 장치에 최적화된 데이터 관리를 실행하는 서비스 워커(SW)의 선택 취득 및 이용 처리를 가능하게 하는 장치, 방법이 실현된다.
구체적으로는, 예를 들어 수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)로부터, 특정 클래스의 SW를 선택 취득하여 이용 가능하게 하였다. 예를 들어, 수신 장치에 있어서의 애플리케이션 이용 상황에 따라 선택되는 클래스 대응의 SW의 이용을 실현한다. 수신 장치는, 특정 클래스의 SW의 액세스 정보를 효율적으로 검색 가능하게 하기 위한 토큰을 기록한 시그널링 데이터를 이용하여 특정 클래스의 SW의 액세스 정보를 취득하여 SW를 취득한다.
본 구성에 의해, 각각의 수신 장치에 최적화된 데이터 관리를 실행하는 서비스 워커(SW)의 선택 취득 및 이용 처리를 가능하게 하는 장치, 방법이 실현된다.
10: 통신 시스템
20: 송신 장치
21: 방송 서버
22: 데이터 배신 서버
30: 수신 장치
31: TV
32: PC
33: 휴대 단말기
50: 시그널링 데이터
60: AV 세그먼트
70: 그 밖의 데이터
110: 미들웨어
111: 통신부(PHY/MAC)
112: 시그널링 취득부
113: 시그널링 해석부
114: 파일 취득부
120: HTTP 프록시 서버
121, 122: 캐시부
123: 어드레스 해결부
130: 출력 제어부
131: 표시 데이터(HTML/JavaScript(등록 상표) 등) 취득&해석부
132: 표시 처리부(Renderer)
133: 기억부(영속 캐시)
140: 외부 장치
141: 출력 제어부
142: 기억부(영속 캐시)
751: 데이터 처리부
752: 통신부
753: 기억부
771: 데이터 처리부
772: 통신부
773: 기억부
774: 입력부
775: 출력부
801: CPU
802: ROM
803: RAM
804: 버스
805: 입출력 인터페이스
806: 입력부
807: 출력부
808: 기억부
809: 통신부
810: 드라이브
811: 리무버블 미디어

Claims (18)

  1. 수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)로부터, 특정 클래스의 서비스 워커(SW)를 선택 취득하여 이용하는 데이터 처리부를 갖는, 수신 장치.
  2. 제1항에 있어서, 상기 데이터 처리부는,
    수신 장치에 있어서의 데이터 처리 상황에 따라 특정 클래스의 서비스 워커(SW)를 선택 취득하는, 수신 장치.
  3. 제2항에 있어서, 상기 데이터 처리 상황은, 수신 장치에 있어서의 애플리케이션 또는 데이터의 이용 상황인, 수신 장치.
  4. 제1항에 있어서, 상기 서비스 워커(SW)는, 관리 대상 데이터로서 애플리케이션, 또는 화상, 또는 음성, 적어도 어느 데이터 파일을 포함하는, 수신 장치.
  5. 제1항에 있어서, 상기 데이터 처리부는,
    송신 장치가 송신하는 메타데이터인 시그널링 데이터로부터, 특정 클래스의 서비스 워커(SW)의 액세스 정보를 취득하고, 취득한 액세스 정보를 이용하여, 서비스 워커(SW)를 취득하는, 수신 장치.
  6. 제5항에 있어서, 상기 시그널링 데이터에는, 특정 클래스의 서비스 워커(SW)의 액세스 정보를 효율적으로 검색하기 위한 검색 보조 정보인 토큰이 기록되고,
    상기 데이터 처리부는,
    토큰을 이용한 액세스 정보 검색 처리를 실행하는, 수신 장치.
  7. 제6항에 있어서, 상기 토큰은,
    특정 클래스의 서비스 워커(SW)의 액세스 정보의 검색 범위를 한정 가능하게 한 서비스 워커(SW) 검색 스코프 토큰인, 수신 장치.
  8. 제6항에 있어서, 상기 토큰은, 특정 클래스의 서비스 워커(SW)의 액세스 정보가 기록되어 있음을 나타내는 서비스 워커(SW) 클래스 지정 토큰인, 수신 장치.
  9. 제6항에 있어서, 상기 시그널링 데이터는,
    (a) 유저 제시를 목적으로 한 서비스 또는 콘텐츠의 속성 정보를 기술하는 서비스 레이어,
    (b) 파일 전송 파라미터를 기술한 파일 전송 세션 레이어,
    (c) FLUTE(ROUTE) 프로토콜 대응의 파라미터를 기술한 FLUTE(ROUTE) 파라미터 레이어,
    상기 (a) 내지 (c)의 레이어를 갖고,
    적어도 (a) 내지 (c) 중 어느 레이어에 토큰이 기록된 구성인, 수신 장치.
  10. 제9항에 있어서, 상기 데이터 처리부는, 상기 서비스 레이어, 또는 상기 파일 전송 세션 레이어, 또는 상기 FLUTE(ROUTE) 파라미터 레이어에 기록된 토큰을 취득하는, 수신 장치.
  11. 제1항에 있어서, 상기 수신 장치의 데이터 처리부에 있어서 실행되는 애플리케이션은, 수신 데이터의 처리를 실행하는 미들웨어에 대하여, 상기 토큰을 검출하기 위한 토큰 정보의 설정 요구를 실행하고,
    상기 미들웨어는, 토큰 정보 설정 요구에 따라 설정한 토큰 정보에 기초하여, 토큰 검출을 행하는, 수신 장치.
  12. 제1항에 있어서, 상기 수신 장치의 데이터 처리부에 있어서 실행되는 데이터 관리 프로그램인 서비스 워커(SW)는, 수신 데이터의 처리를 실행하는 미들웨어에 대하여, 상기 토큰을 검출하기 위한 토큰 정보의 설정 요구를 실행하고,
    상기 미들웨어는, 토큰 정보 설정 요구에 따라 설정한 토큰 정보에 기초하여, 토큰 검출을 행하는, 수신 장치.
  13. 제12항에 있어서, 상기 토큰은,
    특정한 서비스 워커(SW)의 관리 대상으로 되는 데이터에 대응하는 액세스 정보의 검색 처리를 효율화하기 위한 정보이며,
    상기 데이터 처리부는,
    상기 서비스 워커(SW)의 갱신에 따라, 상기 미들웨어에 대하여, 새로운 토큰 정보의 설정 요구를 행하는, 수신 장치.
  14. 수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)를 송신하는, 송신 장치.
  15. 제14항에 있어서, 상기 송신 장치는,
    수신 장치에 있어서, 특정 클래스의 서비스 워커(SW)의 액세스 정보를 효율적으로 검색하기 위한 검색 보조 정보인 토큰을 기록한 메타데이터인 시그널링 데이터를 송신하는, 송신 장치.
  16. 제15항에 있어서, 상기 토큰은,
    특정 클래스의 서비스 워커(SW)의 액세스 정보의 검색 범위를 한정 가능하게 한 서비스 워커(SW) 검색 스코프 토큰, 또는
    특정 클래스의 서비스 워커(SW)의 액세스 정보가 기록되어 있음을 나타내는 서비스 워커(SW) 클래스 지정 토큰인, 송신 장치.
  17. 수신 장치에 있어서 실행하는 데이터 처리 방법이며,
    상기 수신 장치의 데이터 처리부가, 수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)로부터, 특정 클래스의 서비스 워커(SW)를 선택 취득하여 이용하는, 데이터 처리 방법.
  18. 송신 장치에 있어서 실행하는 데이터 처리 방법이며,
    수신 장치에 있어서 이용되는 데이터 관리 프로그램이며, 상이한 데이터 관리 타입을 갖는 복수의 클래스 대응의 서비스 워커(SW)를 송신하는, 데이터 처리 방법.
KR1020177010488A 2014-10-28 2015-10-21 수신 장치, 송신 장치 및 데이터 처리 방법 KR102460099B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2014219659 2014-10-28
JPJP-P-2014-219659 2014-10-28
PCT/JP2015/079645 WO2016067988A1 (ja) 2014-10-28 2015-10-21 受信装置、送信装置、およびデータ処理方法

Publications (2)

Publication Number Publication Date
KR20170074874A true KR20170074874A (ko) 2017-06-30
KR102460099B1 KR102460099B1 (ko) 2022-10-31

Family

ID=55857329

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020177010488A KR102460099B1 (ko) 2014-10-28 2015-10-21 수신 장치, 송신 장치 및 데이터 처리 방법

Country Status (8)

Country Link
US (1) US10880024B2 (ko)
EP (1) EP3214844A4 (ko)
JP (1) JP6583281B2 (ko)
KR (1) KR102460099B1 (ko)
CN (1) CN107113471A (ko)
CA (1) CA2964719C (ko)
MX (1) MX2017005212A (ko)
WO (1) WO2016067988A1 (ko)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180007307A1 (en) * 2016-07-02 2018-01-04 Qualcomm Incorporated Distributed Implementation Architecture for Broadcast Receiver
CN108287737B (zh) * 2017-07-13 2021-08-17 阿里巴巴（中国）有限公司 Service Worker启动方法、装置及电子设备
CN109688179B (zh) * 2017-10-19 2021-06-22 华为技术有限公司 通信方法和通信装置
US11064039B2 (en) 2018-11-14 2021-07-13 Citrix Systems, Inc. Systems and methods for push notification service for SaaS applications
CN111417130B (zh) * 2019-01-07 2022-04-08 中国移动通信有限公司研究院 一种数据处理方法及设备
PL3737108T3 (pl) 2019-05-10 2021-12-20 Jt International S.A. Konfigurowanie osobistego urządzenia obliczeniowego do komunikacji z urządzeniem do wytwarzania aerozolu
EP3965603B1 (en) 2019-05-10 2023-05-10 JT International S.A. Configuring a personal computing device for communication with an aerosol generation device
US11422829B1 (en) 2021-11-17 2022-08-23 Morgan Stanley Services Group Inc. Systems and methods for resilient service worker bridge

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040158859A1 (en) * 2002-12-13 2004-08-12 Canon Kabushiki Kaisha Digital television receiver and GUI changing method for digital television receiver
JP2014057227A (ja) 2012-09-13 2014-03-27 Sony Corp コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
US20140201796A1 (en) * 2011-08-10 2014-07-17 Lg Electronics Inc. Method for transmitting broadcast service, method for receiving broadcast service, and apparatus for receiving broadcast service

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4446286C1 (de) * 1994-12-23 1996-06-20 Siemens Ag Responsives System zur Signalverarbeitung sowie Verfahren zur Herstellung eines responsiven Systems
KR100998687B1 (ko) * 2006-09-13 2010-12-10 각고호우징 게이오기주크 방송 콘텐츠 전송장치 및 방송 콘텐츠 전송방법
EP2146528A1 (en) 2008-07-15 2010-01-20 Gemplus Method for accessing a service offered from a token, corresponding token and system
CA2744183C (en) * 2008-11-18 2014-05-27 Lg Electronics Inc. Non-real time service processing method and broadcast receiver
CN102053984A (zh) * 2009-11-10 2011-05-11 杜卓 信息检索查询与信息发布的系统及方法
CN103222248B (zh) * 2010-09-28 2016-02-03 英国电讯有限公司 多类别数据传输的方法和装置
TWI545955B (zh) * 2011-04-28 2016-08-11 Sony Corp Signal receiving apparatus and method, a signal transmission apparatus and method, and program
US9151630B2 (en) 2011-07-05 2015-10-06 Aisin Aw Co., Ltd. Evaluation indication system, evaluation indication method and computer-readable storage medium
US9264648B2 (en) * 2012-10-09 2016-02-16 Sony Corporation Receiving device, receiving method, transmitting device, and transmitting method
JP6247309B2 (ja) * 2012-11-28 2017-12-13 エルジー エレクトロニクス インコーポレイティド 双方向サービスを処理する装置及び方法
WO2016018077A1 (ko) * 2014-07-30 2016-02-04 엘지전자 주식회사 방송 전송 장치, 방송 수신 장치, 방송 전송 장치의 동작 방법 및 방송 수신 장치의 동작 방법
WO2016036077A1 (ko) * 2014-09-02 2016-03-10 엘지전자 주식회사 방송 수신 장치, 방송 수신 장치의 동작 방법, 방송 수신 장치와 연동하는 연동 장치 및 연동 장치의 동작 방법
EP3206392A4 (en) * 2014-10-12 2018-04-04 LG Electronics Inc. Device for transmitting broadcast signal, device for receiving broadcast signal, method for transmitting broadcast signal, and method for receiving broadcast signal
WO2016060410A1 (ko) * 2014-10-14 2016-04-21 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
JP5880678B2 (ja) 2014-12-25 2016-03-09 株式会社三洋物産 遊技機
US20170209867A1 (en) * 2016-01-27 2017-07-27 Size Reduction Specialists Corp. Plastic granulator stationary cutting segment

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040158859A1 (en) * 2002-12-13 2004-08-12 Canon Kabushiki Kaisha Digital television receiver and GUI changing method for digital television receiver
US20140201796A1 (en) * 2011-08-10 2014-07-17 Lg Electronics Inc. Method for transmitting broadcast service, method for receiving broadcast service, and apparatus for receiving broadcast service
JP2014057227A (ja) 2012-09-13 2014-03-27 Sony Corp コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム

Also Published As

Publication number Publication date
JPWO2016067988A1 (ja) 2017-08-03
EP3214844A1 (en) 2017-09-06
WO2016067988A1 (ja) 2016-05-06
US20170317773A1 (en) 2017-11-02
MX2017005212A (es) 2017-07-27
KR102460099B1 (ko) 2022-10-31
EP3214844A4 (en) 2018-05-30
JP6583281B2 (ja) 2019-10-02
CA2964719A1 (en) 2016-05-06
CN107113471A (zh) 2017-08-29
US10880024B2 (en) 2020-12-29
CA2964719C (en) 2023-03-07

Similar Documents

Publication Publication Date Title
JP6583281B2 (ja) 受信装置、送信装置、およびデータ処理方法
US11025352B2 (en) Reception device, transmission device, and data processing method
WO2009042961A2 (en) Content-triggered customizations for mobile clients
CN107615774B (zh) 接收装置、发送装置及数据处理方法
CA2964721C (en) Reception apparatus, transmission apparatus, and data processing method
CN107079196B (zh) 接收设备、发送设备和数据处理方法
JP6544352B2 (ja) 受信装置、及び、受信方法
KR102611253B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법

Legal Events

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