KR102637023B1

KR102637023B1 - 수신 장치, 송신 장치, 및 데이터 처리 방법

Info

Publication number: KR102637023B1
Application number: KR1020187013711A
Authority: KR
Inventors: 야스아키 야마기시; 다츠야 이가라시
Original assignee: 소니그룹주식회사
Priority date: 2015-11-25
Filing date: 2016-11-11
Publication date: 2024-02-16
Also published as: AU2021202436A1; KR20240025698A; AU2021202436B2; AU2016360190A1; CN108293148B; JPWO2017090457A1; CA3003683A1; US20180288468A1; EP3383054B1; EP3383054A1; MX2018006174A; WO2017090457A1; EP3383054A4; US11575961B2; CN108293148A; KR20180088383A; US20210266629A1; US10986397B2

Abstract

본 기술은, 복수의 서비스에 있어서 재이용되는 리소스를 공유할 수 있도록 하는 수신 장치, 송신 장치 및 데이터 처리 방법에 관한 것이다. 수신 장치는, 콘텐츠를 수신하고, 콘텐츠와 함께 전송되는 제어 정보로서, 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되는 리소스인지 여부를 나타내는 리소스 공유 정보를 포함하는 제어 정보에 기초하여, 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되도록, 리소스의 기억 장치로의 기억을 제어한다. 본 기술은, 예를 들어 ATSC 3.0에 대응한 텔레비전 수상기에 적용할 수 있다.

Description

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

본 기술은, 수신 장치, 송신 장치, 및 데이터 처리 방법에 관한 것으로, 특히, 복수의 서비스에 있어서 재이용되는 리소스를 공유할 수 있도록 한 수신 장치, 송신 장치 및 데이터 처리 방법에 관한 것이다.

클라이언트 장치에 있어서, 특정한 서비스에 부수되는 애플리케이션의 파일에 대한 액세스의 퍼포먼스를 향상시키기 위해서는, 로컬 캐시에 미리 필요한 파일을 캐시해 둘 필요가 있다.

예를 들어, 현재 책정이 진행되고 있는 미국의 차세대 방송 규격인 ATSC(Advanced Television Systems Committee) 3.0에서는, 방송 경유 또는 통신 경유를 통해 취득되는 모든 파일이, 클라이언트 장치에 있어서의 로컬 파일 시스템상의 로컬 캐시에 일단 축적되어, 스트림의 렌더러나 애플리케이션에 제공되는 모델이 상정되어 있다. 단, 로컬 파일 시스템으로서는, 예를 들어 온 메모리(On Memory)나 SSD(Solid State Drive) 등의 파일 시스템, 또는 특별한 데이터베이스 등이 사용된다.

이들 로컬 캐시상의 파일은, 어떤 한정된 기간 캐시에 유지된 후에, 파일에 부수된 HTTP(Hypertext Transfer Protocol) 헤더의 캐시 컨트롤 헤더(Cache Control Header)의 파라미터에 기초하여 소거된다. 단, 이와 같은 처리가 행해지는 것은, ROUTE(Real-time Object Delivery over Unidirectional Transport) 프로토콜의 배신 모드의 일종인 엔티티 모드로 되는 경우이다.

일반적으로, 클라이언트 장치의 튜너나 기억 리소스의 제한으로부터, 모든 수신 가능한 방송파상의 파일을 캐시할 수 없기 때문에, 그 시점에서, 선국하고 있는 서비스에 필요한 파일군만을 취득하여 캐시하고, 서비스(채널)가 전환된 경우에는, 즉시 기억 리소스가 해방된다고 하는 동작이 상정된다.

또한, 방송 프로그램이나 광고 등의 콘텐츠를, 방송국의 방송 서버로부터 일방향의 방송 경유를 통해, 혹은 통신 서버로부터 쌍방향의 통신 경유를 통해, 클라이언트 장치에 배신하기 위한 기술 개발이나 규격화가 현재 왕성하게 진행되고 있다. 이러한 방송 경유 또는 통신 경유를 통해서 데이터 배신을 실현하는 기술로서는, 예를 들어 특허문헌 1에 개시되어 있는 기술이 알려져 있다.

일본 특허공개 제2014-57227호 공보

여기서, 어떤 서비스에서 전송되는 파일 중, 예를 들어 어느 서비스에서도 공통으로 이용되는, 광고의 콘텐츠 등의 파일을, 복수의 서비스 중에서 공유할 수 있으면, 캐시의 기억 영역이나 배신 대역 등을 유효하게 이용할 수 있다. 그로 인해, 복수의 서비스에 있어서 재이용되는 리소스를 공유하기 위한 제안이 요청되고 있다.

본 기술은 이와 같은 상황을 감안하여 이루어진 것이며, 복수의 서비스에 있어서 재이용되는 리소스를 공유할 수 있도록 하는 것이다.

본 기술의 제1 측면의 수신 장치는, 콘텐츠를 수신하는 수신부와, 상기 콘텐츠와 함께 전송되는 제어 정보로서, 상기 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되는 리소스인지 여부를 나타내는 리소스 공유 정보를 포함하는 상기 제어 정보에 기초하여, 상기 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되도록, 상기 리소스의 기억 장치로의 기억을 제어하는 제어부를 구비하는 수신 장치이다.

본 기술의 제1 측면의 수신 장치는, 독립한 장치여도 되고, 하나의 장치를 구성하고 있는 내부 블록이어도 된다. 또한, 본 기술의 제1 측면의 데이터 처리 방법은, 전술한 본 기술의 제1 측면의 수신 장치에 대응하는 데이터 처리 방법이다.

본 기술의 제1 측면의 수신 장치, 및 데이터 처리 방법에 있어서는, 콘텐츠가 수신되고, 상기 콘텐츠와 함께 전송되는 제어 정보로서, 상기 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되는 리소스인지 여부를 나타내는 리소스 공유 정보를 포함하는 상기 제어 정보에 기초하여, 상기 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되도록, 상기 리소스의 기억 장치로의 기억이 제어된다.

본 기술의 제2 측면의 송신 장치는, 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되는 리소스인지 여부를 나타내는 리소스 공유 정보를 포함하는 제어 정보를 생성하는 생성부와, 상기 콘텐츠와 함께, 상기 제어 정보를 송신하는 송신부를 구비하는 송신 장치이다.

본 기술의 제2 측면의 송신 장치는, 독립된 장치여도 되고, 하나의 장치를 구성하고 있는 내부 블록이어도 된다. 또한, 본 기술의 제2 측면의 데이터 처리 방법은, 전술한 본 기술의 제2 측면의 송신 장치에 대응하는 데이터 처리 방법이다.

본 기술의 제2 측면의 송신 장치 및 데이터 처리 방법에 있어서는, 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되는 리소스인지 여부를 나타내는 리소스 공유 정보를 포함하는 제어 정보가 생성되고, 상기 콘텐츠와 함께, 상기 제어 정보가 송신된다.

본 기술의 제1 측면, 및 제2 측면에 의하면, 복수의 서비스에 있어서 재이용되는 리소스를 공유할 수 있다.

또한, 여기에 기재된 효과는 반드시 한정되는 것이 아니라, 본 개시 중에 기재된 어느 하나의 효과여도 된다.

도 1은, 본 기술을 적용한 전송 시스템의 일 실시 형태의 구성을 나타내는 도면이다.
도 2는, 본 기술의 IP 전송 방식의 프로토콜 스택 예를 나타내는 도면이다.
도 3은, ROUTE/FLUTE의 구조를 나타내는 도면이다.
도 4는, ROUTE의 상세한 구조를 나타내는 도면이다.
도 5는, 캐시 쿼터 도메인의 개요를 나타내는 도면이다.
도 6은, 쿼터 도메인 식별자의 배치예를 나타내는 도면이다.
도 7은, 쿼터 도메인 식별자의 지정 방법을 나타내는 도면이다.
도 8은, 쿼터 도메인 식별자의 지정과 파일 캐시의 관계를 나타내는 도면이다.
도 9는, 광고 삽입의 흐름을 설명하는 도면이다.
도 10은, 수신측의 상위층에 있어서의 처리의 흐름을 나타내는 도면이다.
도 11은, MPD 메타데이터의 Period 요소의 xlink:href 속성의 기술(記述)의 예를 나타내는 도면이다.
도 12는, MPD 메타데이터에 의한 시계열의 광고 삽입 제어를 설명하는 도면이다.
도 13은, MPD 메타데이터의 기술의 예를 나타내는 도면이다.
도 14는, MPD 메타데이터의 기술의 예를 나타내는 도면이다.
도 15는, SLT의 포맷의 예를 나타내는 도면이다.
도 16은, USBD의 포맷의 예를 나타내는 도면이다.
도 17은, S-TSID의 포맷의 예를 나타내는 도면이다.
도 18은, SrcFlow의 포맷의 예를 나타내는 도면이다.
도 19는, AST의 포맷의 예를 나타내는 도면이다.
도 20은, AST의 포맷의 예를 나타내는 도면이다.
도 21은, AST의 포맷의 예를 나타내는 도면이다.
도 22는, Ad/DASH 서버의 구성예를 나타내는 도면이다.
도 23은, 방송 서버의 구성예를 나타내는 도면이다.
도 24는, 통신 서버의 구성예를 나타내는 도면이다.
도 25는, 클라이언트 장치의 구성예를 나타내는 도면이다.
도 26은, 송신측의 처리의 흐름을 설명하는 흐름도이다.
도 27은, 수신측의 처리의 흐름을 설명하는 흐름도이다.
도 28은, 수신측의 처리의 흐름을 설명하는 흐름도이다.
도 29는, 컴퓨터의 구성예를 나타내는 도면이다.

이하, 도면을 참조하면서 본 기술의 실시 형태에 대하여 설명한다. 또한, 설명은 이하의 순서로 행하도록 한다.

1. 시스템의 구성

2. 캐시 쿼터 도메인의 개요

3. 애플리케이션의 응용예

4. 시그널링의 예

5. 각 장치의 구성

6. 각 장치에 의해 실행되는 처리의 흐름

7. 변형예

8. 컴퓨터의 구성

<1. 시스템의 구성>

(전송 시스템의 구성)

도 1은, 본 기술을 적용한 전송 시스템의 일 실시 형태의 구성을 나타내는 도면이다. 또한, 시스템이란, 복수의 장치가 논리적으로 집합된 것을 의미한다.

도 1에 있어서, 전송 시스템(1)은, Ad/DASH 서버(10), 방송 서버(20), 통신 서버(30), 및 클라이언트 장치(40)로 구성된다.

Ad/DASH 서버(10)는, MPEG-DASH(Dynamic Adaptive Streaming over HTTP)에 대응한 배신 서비스를 행하기 위한 서버이다. 여기서, MPEG-DASH는, OTT-V(Over The Top Video)에 따른 스트리밍 배신 규격으로서, HTTP(Hypertext Transfer Protocol)를 베이스로 한 스트리밍 프로토콜을 사용한 어댑티브 스트리밍 배신에 관한 규격이다.

이 MPEG-DASH의 규격에서는, 동화상이나 음성의 파일 관리 정보인 메타데이터를 기술(記述)하기 위한 매니페스트 파일과, 동화상의 콘텐츠를 전송하기 위한 파일 포맷이 규정되어 있다. 또한, 전자의 매니페스트 파일은, MPD(Media Presentation Description)라 칭해진다. 또한, 후자의 파일 포맷은, 세그먼트 포맷이라고도 칭해진다.

Ad/DASH 서버(10)는, 프로그램의 콘텐츠 세그먼트(이하, 'DASH 세그먼트'라고도 함)나, 광고의 콘텐츠 세그먼트(이하, 'Ad 세그먼트'라고도 함)의 파일을 생성하고, 방송 서버(20) 또는 통신 서버(30)에 송신한다. 또한, Ad/DASH 서버(10)는, MPD 메타데이터를 생성하고, 방송 서버(20) 또는 통신 서버(30)에 송신한다.

또한, Ad/DASH 서버(10)는, 애플리케이션을 생성하고, 방송 서버(20) 또는 통신 서버(30)에 송신한다. 이 애플리케이션으로서는, 예를 들어 스크립트(Script)를 실행 가능한 스크립트 애플리케이션이 포함된다. 또한, 스크립트 애플리케이션은, 예를 들어 HTML5(HyperText Markup Language 5) 등의 마크업 언어나, JavaScript(등록상표) 등의 스크립트 언어로 개발된 애플리케이션으로 할 수 있다.

방송 서버(20)는, ATSC 3.0 등의 디지털 방송의 규격에 준거한 데이터 전송을 행하는 것이 가능한 송신기이다. 방송 서버(20)는, Ad/DASH 서버(10)로부터 송신되어 오는 DASH 세그먼트나 Ad 세그먼트, MPD 메타데이터, 애플리케이션의 파일을 처리하고, 시그널링과 함께, 전송로(80)를 통해 송신(일제 동보 배신)한다.

또한, 방송 서버(20)에는, NRT 콘텐츠가 입력된다. NRT 콘텐츠는, NRT(Non Real Time) 방송에 의해 전송되는 콘텐츠로서, 클라이언트 장치(40)의 스토리지에 일단 축적된 후에 재생이 행해진다. 방송 서버(20)는, 거기에 입력되는 NRT 콘텐츠의 파일을 처리하고, 전송로(80)를 통해 송신(일제 동보 배신)한다.

통신 서버(30)는, 인터넷(90)에 접속된 클라이언트 장치(40)로부터의 요구에 응답하여, 인터넷(90)을 통해 각종 데이터를 제공하는 서버이다. 통신 서버(30)는, Ad/DASH 서버(10)로부터 송신되어 오는 DASH 세그먼트나 Ad 세그먼트, MPD 메타데이터, 애플리케이션의 파일을 처리한다. 그리고, 통신 서버(30)는, 클라이언트 장치(40)로부터의 요구에 응답하여, 인터넷(90)을 통해 각종 파일을 송신한다.

클라이언트 장치(40)는, ATSC 3.0 등의 디지털 방송의 규격에 준거한 전송 데이터를 수신 가능한 수신기이다. 예를 들어, 클라이언트 장치(40)는, 텔레비전 수상기나 셋톱 박스 등의 고정 수신기, 혹은 스마트폰이나 휴대 전화기, 태블릿형 컴퓨터 등의 모바일 수신기이다. 클라이언트 장치(40)는, 예를 들어 차량용 TV 등의 자동차에 탑재되는 기기여도 된다.

클라이언트 장치(40)는, 방송 서버(20)로부터 전송로(80)를 통해 송신(일제 동보 배신)되어 오는, DASH 세그먼트나 Ad 세그먼트, 시그널링, MPD 메타데이터, 애플리케이션, NRT 콘텐츠 등의 파일을 수신하여 처리함으로써, 방송 프로그램이나 광고 등의 콘텐츠의 영상이나 음성을 출력한다.

또한, 클라이언트 장치(40)는, 통신 기능을 갖는 경우, 인터넷(90)을 통해 통신 서버(30)에 액세스하고, 각종 파일을 취득할 수 있다. 예를 들어, 클라이언트 장치(40)는, 통신 서버(30)로부터 인터넷(90)을 통해 송신(적응적으로 스트리밍 배신)되는, DASH 세그먼트나 Ad 세그먼트, MPD 메타데이터 등의 파일을 수신하여 처리함으로써, VOD(Video On Demand) 프로그램이나 광고 등의 콘텐츠의 영상이나 음성을 출력한다.

또한, 전송 시스템(1)에 있어서, 전송로(80)는, 지상파(지상파 방송) 외에, 예를 들어 방송위성(BS: Broadcasting Satellite)이나 통신위성(CS: Communications Satellite)을 이용한 위성 방송, 혹은 케이블을 사용한 유선 방송(CATV) 등이어도 된다.

또한, ATSC 3.0은, 현재 책정이 진행되고 있는 미국의 차세대 방송 규격이다. ATSC 3.0에서는, 전송 방식으로서, 현재 널리 보급하고 있는 MPEG2-TS(Transport Stream) 방식이 아니라, 통신 분야에서 사용되고 있는 IP(Internet Protocol) 패킷을 디지털 방송에 사용한 IP 전송 방식을 도입함으로써, 보다 고도의 서비스를 제공하는 것이 상정되어 있다.

(본 기술의 프로토콜 스택)

도 2는, 본 기술의 IP 전송 방식의 프로토콜 스택의 예를 나타내는 도면이다.

도 2에 있어서, 가장 하위의 계층은, 물리층(Physical Layer)으로 된다. ATSC 3.0 등의 IP 전송 방식의 디지털 방송에서는, 일방향의 방송을 이용한 전송으로 한정되지 않고, 일부의 데이터를, 쌍방향의 통신을 이용하여 전송하는 경우가 있지만, 방송을 이용하는 경우, 그 물리층(Broadcast)은, 서비스(채널)를 위해 할당된 방송파의 주파수 대역이 대응하게 된다.

물리층(Broadcast)의 상위의 계층은, IP층으로 된다. IP층은, 통신의 계층 모델에 있어서의 네트워크층에 상당하는 것이며, IP 어드레스에 의해 IP 패킷이 특정된다. IP층에 인접하는 상위 계층은, 통신의 계층 모델에 있어서의 트랜스포트층에 상당하는 UDP(User Datagram Protocol)층으로 되고, 또한 그 상위의 계층은, ROUTE(Real-time Object Delivery over Unidirectional Transport) 또는 MMTP(MPEG Media Transport Protocol)로 된다.

또한, UDP층의 상위의 계층, 즉 UDP 패킷을 포함하는 IP 패킷에는, SLT 메타데이터가 저장되고, 전송된다. SLS 메타데이터는, 서비스의 선국에 필요한 정보(선국 정보) 등, 방송 네트워크에 있어서의 스트림이나 서비스의 구성을 나타내는 기본 정보를 포함하는 LLS(Link Layer Signaling) 시그널링이다. 또한, LLS 시그널링은, SLS(Service Layer Signaling) 시그널링에 선행하여 취득되는 시그널링으로서, LLS 시그널링에 포함되는 정보에 따라 SLS 시그널링이 취득된다.

ROUTE는, 스트리밍 파일 전송용 프로토콜로서, FLUTE(File Delivery over Unidirectional Transport)를 확장한 것이다. 또한, ROUTE의 상세한 내용은, 도 3 및 도 4를 참조하여 후술한다.

ROUTE에 인접하는 상위 계층 중, 일부의 계층은, 시그널링(ROUTE specific Signaling)과 NRT 콘텐츠(NRT Files)로 된다. 이 시그널링은, SLS 시그널링으로서, 예를 들어 USBD(User Service Bundle Description), S-TSID(Service-based Transport Session Instance Description), MPD(Media Presentation Description), AST(Application Signaling Table) 등의 메타데이터가 포함된다.

USD 메타데이터는, 다른 메타데이터의 취득처 등의 정보를 포함한다. S-TSID 메타데이터는, LSID(LCT Session Instance Description)를 ATSC 3.0용으로 확장한 것으로서, ROUTE 프로토콜의 제어 정보이다. MPD 메타데이터는, 전술한 바와 같이, 스트리밍 배신되는 동화상이나 음성의 파일의 관리 정보이다. AST는, 애플리케이션의 제어 정보이다.

또한, NRT 콘텐츠는, ROUTE 세션에 의해(을 통해) 전송되는 콘텐츠의 일례이며, 예를 들어 애플리케이션이나 전자 서비스 가이드(ESG: Electronic Service Guide) 등의 콘텐츠가, ROUTE 세션에 의해 전송되도록 해도 된다.

ROUTE에 인접하는 상위 계층 중, 전술한 계층 이외의 다른 계층은, DASH 세그먼트(ISO BMFF)로 된다. 또한, DASH 세그먼트(ISO BMFF)에 인접하는 상위 계층은, DASH 플레이어/디코더로 된다. 즉, 트랜스포트 프로토콜로서 ROUTE를 사용하는 경우에는, 방송 프로그램 등의 콘텐츠를 구성하는 서비스 컴포넌트(비디오나 오디오, 자막 등)의 스트림 데이터가, ISO BMFF(ISO Base Media File Format)의 규격에 준한 DASH 세그먼트 단위로, ROUTE 세션에 의해 전송된다.

한편, MMTP는, 스트리밍 파일을 전송하기 위한 프로토콜이다. MMTP에 인접하는 상위 계층 중, 일부의 계층은, 시그널링(MMTP specific Signaling)으로 된다. 이 시그널링으로서는, 예를 들어 USBD(User Service Bundle Description)이나 MPT(MMT Package Table) 등의 메타데이터가 포함된다.

또한, MMTP에 인접하는 상위 계층 중, 시그널링 이외의 계층은, MPU(Media Processing Unit)(ISO BMFF)로 된다. 또한, MPU(ISO BMFF)에 인접하는 상위 계층은, DASH 플레이어/디코더로 된다. 즉, 트랜스포트 프로토콜로서 MMT를 사용하는 경우에는, 방송 프로그램 등의 콘텐츠를 구성하는 서비스 컴포넌트(비디오나 오디오, 자막 등)의 스트림 데이터가, ISO BMFF(ISO Base Media File Format)의 규격에 준한 MPU 단위로, MMTP 세션에 의해 전송된다.

이와 같이, 도 2의 프로토콜 스택에 있어서는, 트랜스포트 프로토콜로서, ROUTE와 MMTP가 병기되어 있기 때문에, 일방향의 방송계 스트리밍 배신에서는, DASH 세그먼트(ISO BMFF)의 파일을 전송하는 ROUTE 프로토콜이거나, 혹은 MPU(ISO BMFF)의 파일을 전송하는 MMTP 중 어느 한쪽의 프로토콜을 사용하게 된다.

또한, 쌍방향의 통신을 이용하는 경우, 그 물리층(Broadband)의 상위의 계층은, 네트워크층에 상당하는 IP층으로 된다. 또한, IP층에 인접하는 상위 계층은, 트랜스포트층에 상당하는 TCP(Transmission Control Protocol)층으로 되고, 또한, TCP층에 인접하는 상위 계층은, 애플리케이션층에 상당하는 HTTP층으로 된다. 즉, 이들 계층에 의해, 인터넷(90) 등의 네트워크에서 가동하는 TCP/IP 등의 프로토콜이 실장된다.

HTTP층에 인접하는 상위 계층 중, 일부의 계층은, 시그널링(All Signaling Objects)과 NRT 콘텐츠(NRT Files)로 된다. 이 시그널링으로서는, 전술한 ROUTE나 MMTP에 의해 전송되는 시그널링 등, 모든 시그널링이 포함된다. 또한, NRT 콘텐츠는, 통신 경유로 취득되는 콘텐츠의 일례이며, 예를 들어 애플리케이션 등의 콘텐츠가 전송되도록 해도 된다.

HTTP층에 인접하는 상위 계층 중, 전술한 계층 이외의 다른 계층은, DASH 세그먼트(ISO BMFF)로 되고, 또한, 이 DASH 세그먼트(ISO BMFF)에 인접하는 상위 계층은, DASH 플레이어/디코더로 된다. 즉, 쌍방향의 통신계의 스트리밍 배신에서는, VOD 프로그램 등의 콘텐츠를 구성하는 서비스 컴포넌트(비디오나 오디오, 자막 등)의 스트림 데이터가, ISO BMFF의 규격에 준한 DASH 세그먼트 단위로 전송되게 된다.

또한, 일방향의 방송의 ROUTE나 MMTP 등의 프로토콜, 쌍방향의 통신 TCP/IP 프로토콜 등을 사용함으로써 애플리케이션(Applications)을 전송할 수 있다. 예를 들어, 이 애플리케이션은, HTML5나 JS(JavaScript(등록상표)) 등에 의해 개발된 애플리케이션으로 할 수 있다.

또한, 도 2에 있어서, ROUTE의 일부에, HTTP 프록시(HTTP Proxy)가 기술되어 있는 것은, 애플리케이션에 의해, DASH 세그먼트(ISO BMFF)의 파일을 취득하는 경우에, 클라이언트 장치(40)에 실장된 방송 미들웨어가, HTTP 서버로서 기능하는 실장을 상정하고 있기 때문이다. 또한, 도 2에 있어서는, 콘텐츠 보호의 시큐리티 프레임 워크로서, W3C(World Wide Web Consortium)와 MPEG(Moving Picture Experts Group)에 준거한 EME/CENC(Encrypted Media Extension/Common Encryption Scheme)를 채용하고 있기 때문에, DASH 세그먼트(ISO BMFF)와, MPU(ISO BMFF)의 일부에, EME/CENC로 기술되어 있다.

또한, LLS 시그널링으로서의 SLT 메타데이터나, SLS 시그널링으로서의 USBD, S-TSID, MPD, AST 등의 메타데이터는, XML(Extensible Markup Language) 등의 마크업 언어에 의해 기술된다.

이상과 같이, 본 기술의 IP 전송 방식의 프로토콜 스택에 있어서는, 일방향의 방송계의 계층과, 쌍방향의 통신계의 계층의 일부가 공통의 프로토콜로 되어, 일방향의 방송과 쌍방향의 통신을 통해, 콘텐츠를 구성하는 서비스 컴포넌트의 스트림 데이터를, ISO BMFF의 규격에 준한 DASH 세그먼트 단위로 전송할 수 있다. 그로 인해, 일방향의 방송계의 스트리밍 배신과, 쌍방향의 통신계의 스트리밍 배신의 양쪽을 행하는 경우에 있어서, 상위 계층의 프로토콜이 공통화되어 있기 때문에, 예를 들어 방송 서버(20)나 클라이언트 장치(40)에서는, 실장의 부담이나 처리의 부담을 경감시킬 수 있다.

(ROUTE의 구조)

도 3은, ROUTE의 구조를 나타내는 도면이다. 단, 도 3에는, ROUTE와의 비교를 위해, FLUTE에 대해서도 기술하고 있다.

FLUTE는, ALC(Asynchronous Layered Coding)라 불리는 스케일러블 파일 오브젝트의 멀티캐스트 프로토콜, 구체적으로는, 그 빌딩 블록인 LCT(Layered Coding Transport)나 FEC(Forward Error Correction) 컴포넌트의 조합에 의해 구성된다.

여기서, ALC는, 임의의 바이너리 파일을 일방향으로 멀티캐스트 전송하기에 적합한 프로토콜이다. 즉, ALC는, 고신뢰의 비동기형 일대다의 방송형 프로토콜로서 개발된 것이지만, LCT와 FEC를 이용하고 있으며, 대상 파일에 FEC를 거쳐 LCT 패킷에 저장하고, IP 멀티캐스트상에서 전송하는 경우에는, UDP 패킷과 IP 패킷에 저장한다.

FLUTE에서의 트랜스포트 세션은, 송신원 IP 어드레스의 스코프로 유니크한 TSI(Transport Session Identifier)에 의해 식별된다. FLUTE에서는, 트랜스포트 세션마다, 또는 파일마다 FEC의 방식을 변경할 수 있다. 또한, FLUTE는, 트랜스포트 세션마다 전송되는 FDT(File Delivery Table)라 칭해지는 XML 형식의 전송 제어 정보가 도입되어 있다.

LCT 패킷에 저장된 FEC 인코딩 심볼과 동일한 트랜스포트 세션 내에서 전송되는 FDT 파일에, 대상 파일의 기본 속성과 전송 제어 파라미터를 기술한다. FDT는, 대상 파일의 식별자와 대응하는 FEC 인코딩 심볼 열이 저장된 LCT 패킷 열과의 매핑을 정의하고, 나아가 개개의 파일 내용 MIME 타입이나 사이즈, 전송 부호화 방식, 메시지 다이제스트, FEC 디코드에 필요한 파라미터 등을 저장할 수 있다. 또한, FDT 자신에도 FEC를 적용하는 것이 가능하며, 자신의 FEC 파라미터 등은 별도 LCT의 레이어로 전송하게 된다.

그런데, ROUTE는, FLUTE의 확장으로 되지만, 그 차분으로서는, 주로 오브젝트 번들과 미디어 어웨어 프래그먼테이션을 들 수 있다. 도 4에는, ROUTE의 상세한 구조를 나타내고 있다.

ROUTE에서의 오브젝트 번들의 특징은, 서로 다른 사이즈의 소스 블록으로 이루어지는 비디오나 오디오의 스트림을 번들하여, 하나의 슈퍼 오브젝트로서 구성하고, 그것을 기초로 FEC 리페어 스트림을 생성하는 방법과, 소스 스트림과 리페어 스트림의 관계 통지를 프로토콜 레벨로 서포트하고 있는 데 있다.

일반적으로, 오디오 스트림 등은, 단위 시간당 데이터양(데이터 오브젝트)이 작기 때문에, 비디오 스트림과 비교하여, 작은 소스 오브젝트 사이즈로 된다. 이들 소스 오브젝트 사이즈가 서로 다른 스트림에 대해서, 동일한 FEC 방식으로 스트림마다 리페어 심볼을 생성하면, 소스 오브젝트 사이즈의 대소에 따라 에러에 대한 감수성이 상이해진다.

ROUTE에서는, 복수의 레이트가 서로 다른 소스 스트림으로부터 소스 블록을 잘라내어 슈퍼 오브젝트를 구성하고, 그것을 기초로 생성되는 FEC 리페어 심볼에 의해 리페어 스트림을 구성할 수 있다. 즉, 서로 다른 종류의 소스 스트림에 걸쳐 리페어 스트림이 생성된다. 여기서, 소스 심볼로 이루어지는 소스 스트림과, 리페어 심볼로 이루어지는 리페어 스트림과, ROUTE 세션 내의 다른 LCT 세션으로서 전송할 수 있다.

복수의 소스 스트림으로부터 잘라낸 소스 블록으로부터, 어떻게 슈퍼 오브젝트를 구성하여 FEC 스트림을 생성하는지에 대한 정보(제어 정보)가, LSID(FDT)를 확장한 S-TSID 메타데이터에 기술된다. 수신기측에서는, 이 S-TSID 메타데이터에 기술된 정보에 기초하여, ROUTE 세션을 통해 전송되는 LCT 패킷 열로부터, 슈퍼 오브젝트를 복원하여, 대상의 파일을 추출할 수 있다.

일반적으로, 방송 스트림은, 송신기측에서, 서비스를 구성하는 모든 스트림을 다중화하여 송신하고, 수신기측에서, 자신에게 필요한 스트림을 취사 선택하는 모델이다. 따라서, 송신기측에서, 서비스를 구성하는 모든 스트림으로 이루어지는 슈퍼 오브젝트를 구성하여, 수신기측에서 슈퍼 오브젝트를 복원하고 나서, 필요한 스트림을 취사 선택한다는 처리 모델의 적용이 가능한 유스케이스에 있어서는, ROUTE에 의해 실현되는 FEC 구성 방법이 유효하다.

이상, FLUTE의 확장인 ROUTE에 대하여 설명하였다.

<2. 캐시 쿼터 도메인의 개요>

그런데, 클라이언트 장치(40)에 있어서, 방송 프로그램 등의 특정한 서비스에 부수되는 애플리케이션에 대한 액세스의 퍼포먼스를 향상시키기 위해서는, 로컬 캐시에 미리 필요한 파일을 캐시해 둘 필요가 있다. 예를 들어, ATSC 3.0에서는, 방송 경유 또는 통신 경유로 취득되는 모든 파일이, 클라이언트 장치(40)에 있어서의 로컬 파일 시스템상의 로컬 캐시에 일시 축적되어, 스트림의 렌더러나 애플리케이션에 제공되는 모델이 상정되어 있다.

또한, 클라이언트 장치(40)에 있어서는, 튜너나 기억 리소스의 제한으로부터, 모든 수신 가능한 방송파상의 파일을 캐시할 수는 없기 때문에, 그 시점에서 선국하고 있는 서비스에 필요한 파일군만을 취득하여 캐시하고, 서비스(채널)가 전환된 경우에는, 즉시 기억 리소스를 해방한다고 하는 동작이 상정되어 있다.

한편, 어떤 서비스에 의해 전송되는 파일 중, 예를 들어 어느 서비스에서도 공통으로 이용되는, 광고의 콘텐츠 등의 파일을, 복수의 서비스 중에서 공유할 수 있으면, 캐시의 기억 영역이나 배신 대역 등을 유효하게 이용할 수 있는 등의 장점이 있다. 그로 인해, 복수의 서비스에 있어서 재이용되는 리소스를 공유하기 위한 제안이 요청되고 있지만, 본 기술에서는, 캐시 쿼터 도메인(Cache Quota Domain)의 개념을 도입하고, 캐시 쿼터 도메인을 식별하는 쿼터 도메인 식별자를 시그널링으로서 전송함으로써, 클라이언트 장치(40)에서, 복수의 서비스에 있어서 재이용되는 리소스를 공유할 수 있도록 한다.

(캐시 쿼터 도메인의 개요)

도 5는, 캐시 쿼터 도메인의 개요를 나타내는 도면이다.

캐시 쿼터 도메인은, 재이용되는 리소스를 공유하기 위한 도메인(그룹)이다. 도 5에 있어서는, 서비스 A, 서비스 B, 및 서비스 C가, 쿼터 도메인 1에 속하고, 서비스 X, 및 서비스 Y가, 쿼터 도메인 2에 속하는 경우를 예시하고 있다. 또한, 도 5의 로컬 캐시의 기억 영역은, 후술하는 도 25의 로컬 캐시(404)의 영속 캐시(404B)에 상당하는 것이다.

이 경우에, 클라이언트 장치(40)에서는, 쿼터 도메인 1에 속하는 서비스 A 내지 C에 의해 공유되는 애플리케이션이나 DASH 세그먼트 등의 파일이, 로컬 캐시의 쿼터 도메인 1에 할당된 기억 영역에 캐시된다. 즉, 쿼터 도메인 1(의 쿼터 도메인 식별자)에 의해 식별되는 로컬 캐시의 기억 영역에, 쿼터 도메인 1에 속하는 서비스에 의해 공유되는 파일이 캐시되므로, 쿼터 도메인 1에 속하는 서비스에서는, 당해 기억 영역의 파일을 취득하여, 처리(재생)할 수 있다.

한편, 쿼터 도메인 2에 속하는 서비스 X 및 Y에 의해 공유되는 애플리케이션이나 DASH 세그먼트, 피리어드 파일 등의 파일이, 로컬 캐시의 쿼터 도메인 2에 할당된 기억 영역에 캐시된다. 즉, 쿼터 도메인 2(의 쿼터 도메인 식별자)에 의해 식별되는 로컬 캐시의 기억 영역에, 쿼터 도메인 2에 속하는 서비스에 의해 공유되는 파일이 캐시되므로, 쿼터 도메인 2에 속하는 서비스에서는, 당해 기억 영역의 파일을 취득하여, 처리(재생)할 수 있다.

단, 각 서비스는, 자신이 속하는 쿼터 도메인을 너머, 다른 쿼터 도메인의 리소스에 액세스할 수는 없다. 예를 들어, 쿼터 도메인 1에 속하는 서비스 A 내지 C는, 쿼터 도메인 2의 리소스에 액세스할 수는 없고, 쿼터 도메인 2에 속하는 서비스 X 및 Y는, 쿼터 도메인 1의 리소스에 액세스할 수는 없다.

이와 같이, 캐시 쿼터 도메인의 개념을 도입함으로써, 각 쿼터 도메인에 속하는 서비스에서는, 자신이 속하는 쿼터 도메인 내의 리소스를 공유하여 이용(재이용)하는 것이 가능해진다.

예를 들어, 단일의 방송국에 의해 제공되는 복수의 서비스, 혹은 복수의 방송국으로부터 조직되는 방송국 연합에 의해 제공되는 복수의 서비스 등이, 동일한 캐시 쿼터 도메인에 속함으로써, 캐시 쿼터 도메인마다, 복수의 서비스가, 리소스(파일)를 공유하게 된다.

(쿼터 도메인 식별자의 배치예)

도 6은, 쿼터 도메인 식별자의 배치예를 나타내는 도면이다.

캐시 쿼터 도메인을 식별하는 쿼터 도메인 식별자는, 방송파의 각 레이어에 의해 전송되는 시그널링에 의해 전송할 수 있다. 즉, 시그널링에 있어서, 대상의 서비스가 속하는 캐시 쿼터 도메인의 쿼터 도메인 식별자를 지정 가능한 속성(또는 요소)을 추가함으로써, 클라이언트 장치(40)에서는, 시그널링에 포함되는 쿼터 도메인 식별자에 기초하여, 동일한 캐시 쿼터 도메인에 속하는 서비스 중에서, 리소스(파일)를 공유시킬 수 있다.

도 6에 도시한 바와 같이, 쿼터 도메인 식별자는, IP/UDP 패킷의 페이로드에 저장되는, LLS 시그널링인 SLT 메타데이터, 또는 IP/UDP 패킷의 페이로드에 저장되는, LCT 세션을 통해 전송되는 SLS 시그널링인 USBD 메타데이터, S-TSID 메타데이터, 혹은 AST 메타데이터를 확장함으로써, 거기에 배치할 수 있다.

(A) SLT 메타데이터에 배치하는 경우

캐시 쿼터 도메인의 쿼터 도메인 식별자가, SLT 메타데이터의 확장에 의해 지정되는 경우, SLT 메타데이터는, 복수의 서비스의 속성을 지정 가능하므로, 대상의 서비스 속성으로서, 쿼터 도메인 식별자를 지정 가능한 속성(또는 요소)을 추가하게 된다. 여기서는, 예를 들어 SLT 메타데이터의 service 요소에, quotaDomain 속성을 정의함으로써, 대상의 서비스가 속하는 캐시 쿼터 도메인의 쿼터 도메인 식별자를 지정하는 것이 가능해진다.

예를 들어, 서비스 A 내지 Z가 제공되는 경우에, SLT 메타데이터에서는, 서비스 A 내지 C의 서비스 ID가 지정된 service 요소의 quotaDomain 속성으로서, 쿼터 도메인 1(도 5)의 쿼터 도메인 식별자가 지정되도록 한다. 또한, 이 SLT 메타데이터에서는, 서비스 X 및 Y의 서비스 ID가 지정된 service 요소의 quotaDomain 속성으로서, 쿼터 도메인 2(도 5)의 쿼터 도메인 식별자가 지정되도록 한다.

이와 같이, SLT 메타데이터에 있어서, service 요소에, quotaDomain 속성을 정의함으로써, 서비스 단위로 쿼터 도메인 식별자를 지정하는 것이 가능해진다.

(B) USBD 메타데이터에 배치하는 경우

캐시 쿼터 도메인의 쿼터 도메인 식별자가, USBD 메타데이터의 확장에 의해 지정되는 경우, USBD 메타데이터의 USD 요소에, quotaDomain 속성을 정의함으로써, 대상의 서비스가 속하는 캐시 쿼터 도메인의 쿼터 도메인 식별자를 지정하는 것이 가능해진다.

예를 들어, 서비스 A 내지 Z가 제공되는 경우에, 서비스 A 내지 C의 USBD 메타데이터에서는, USD 요소의 quotaDomain 속성으로서, 쿼터 도메인 1(도 5)의 쿼터 도메인 식별자가 지정되도록 한다. 또한, 예를 들어 서비스 X 및 Y의 USBD 메타데이터에서는, USD 요소의 quotaDomain 속성으로서, 쿼터 도메인 2(도 5)의 쿼터 도메인 식별자가 지정되도록 한다.

이와 같이, USBD 메타데이터에 있어서, USD 요소에, quotaDomain 속성을 정의함으로써, 서비스 단위로 쿼터 도메인 식별자를 지정하는 것이 가능해진다.

(C) S-TSID 메타데이터에 배치하는 경우

캐시 쿼터 도메인의 쿼터 도메인 식별자가, S-TSID 메타데이터의 확장에 의해 지정되는 경우, S-TSID 메타데이터의 RS 요소의 LS 요소의 srcFlow 요소의 ContentInfo 요소에, quotaDomain 속성을 정의함으로써, 대상의 LCT 세션이 속하는 캐시 쿼터 도메인의 쿼터 도메인 식별자를 지정하는 것이 가능해진다.

이와 같이, S-TSID 메타데이터에 있어서, RS 요소의 LS 요소의 srcFlow 요소의 ContentInfo 요소에, quotaDomain 속성을 정의함으로써, LCT 세션 단위로 쿼터 도메인 식별자를 지정하는 것이 가능해진다.

(D) AST 메타데이터에 배치하는 경우

캐시 쿼터 도메인의 쿼터 도메인 식별자가, AST 메타데이터의 확장에 의해 지정되는 경우, AST 메타데이터의 Application 요소의 applicationSpecificDescriptor 요소의 atsc:atscDescriptor 요소에, quotaDomain 속성을 정의함으로써, 대상의 애플리케이션이 속하는 캐시 쿼터 도메인의 쿼터 도메인 식별자를 지정하는 것이 가능해진다.

이와 같이, AST 메타데이터에 있어서, Application 요소의 applicationSpecificDescriptor 요소의 atsc:atscDescriptor 요소에, quotaDomain 속성을 정의함으로써, 애플리케이션 단위로 쿼터 도메인 식별자를 지정하는 것이 가능해진다.

이상과 같이, SLT 메타데이터, USBD 메타데이터, S-TSID 메타데이터, 또는, AST 메타데이터를 확장하여, 쿼터 도메인 식별자를 지정함으로써, 동일한 캐시 쿼터 도메인 내에서, 서비스 단위, LCT 세션 단위, 또는 애플리케이션 단위로 리소스(파일)를 공유시킬 수 있다.

즉, 도 7에 도시한 바와 같이, 각 서비스는, 1개 또는 복수의 LCT 세션으로 구성되고, 각 LCT 세션에서는, 예를 들어 DASH 세그먼트나 애플리케이션의 파일, 임의의 파일 등이 전송되어 있다.

여기서, 도 7에 도시한 바와 같이, 서비스 단위로 리소스를 공유시키고 싶은 경우에는, SLT 메타데이터의 서비스 엔트리(서비스마다의 기본 속성)를 확장하거나, 또는 USBD 메타데이터의 서비스마다의 속성을 확장하여, quotaDomain 속성을 정의하도록 한다. 즉, 대상의 서비스에 의해 전송되는 파일에 대해서, 그들 파일이 저장되는 로컬 캐시의 기억 영역을 식별하기 위한 쿼터 도메인 식별자가, SLT 메타데이터 또는 USBD 메타데이터의 quotaDomain 속성에 의해 지정되는 문자열에 상당하게 된다. 또한, 이 경우의 파일은, 예를 들어 DASH 세그먼트, 피리어드 파일, 또는 애플리케이션 등의 파일로서, 방송 경유로 취득되는 파일뿐만 아니라, 통신 경유로 취득되는 파일도 포함되는 것이다.

단, SLT 메타데이터 또는 USBD 메타데이터의 quotaDomain 속성에 의해, 서비스 레벨로, 캐시 쿼터 도메인(예를 들어, 쿼터 도메인 1)이 지정된 경우에, 대상의 서비스에 속하는 LCT 세션을 통해 전송되는 모든 파일에 대하여, 로컬 캐시(의 영속 캐시)에 캐시하는 것이 지시된 경우에는, 모든 파일이, 로컬 캐시의 캐시 쿼터 도메인(예를 들어, 쿼터 도메인 1)에 할당된 기억 영역에 캐시된다(도 8의 A(B)).

또한, 상세는, 도 15의 SLT 메타데이터의 포맷을 참조하여 후술하지만, SLT 메타데이터의 service 요소에는, SLS 시그널링의 로케이션 정보가 지정된다. 그리고, 이 로케이션 정보는, SLS 시그널링이 방송 경유로 취득되는 경우에는, BroadcastSvcSignaling 요소에 의해 지정되고, SLS 시그널링이 통신 경유로 취득 되는 경우에는, SvcInetUrl 요소에 의해 지정된다. 예를 들어, USBD 메타데이터는, SLT 메타데이터의 service 요소의 로케이션 정보에 따라서, 방송 경유 또는 통신 경유로 취득된다.

또한, 도 7에 도시한 바와 같이, LCT 세션 단위로 리소스를 공유시키고 싶은 경우에는, S-TSID 메타데이터의 LCT 세션마다의 속성을 확장하여, quotaDomain 속성을 정의하도록 한다. 즉, 대상의 LCT 세션을 통해 전송되는 파일에 대해서, 그들 파일이 저장되는 로컬 캐시의 기억 영역을 식별하기 위한 쿼터 도메인 식별자가, S-TSID 메타데이터의 quotaDomain 속성에 의해 지정되는 문자열에 상당하게 된다. 또한, 이 경우의 파일은, 예를 들어 DASH 세그먼트, 피리어드 파일, 또는 애플리케이션 등의 파일이다.

단, S-TSID 메타데이터의 quotaDomain 속성에 의해, LCT 세션 레벨로 캐시 쿼터 도메인(예를 들어, 쿼터 도메인 1)이 지정된 경우에는, 대상의 LCT 세션이 속하는 서비스가, 캐시 쿼터 도메인(예를 들어, 쿼터 도메인 1)에 속해 있다고 인식된다.

그리고, 캐시 쿼터 도메인(예를 들어, 쿼터 도메인 1)이 지정된 LCT 세션을 통해 전송되는 파일에 대하여, 로컬 캐시(의 영속 캐시)에 캐시하는 것이 지시된 경우에는, 그들 파일이, 로컬 캐시의 캐시 쿼터 도메인(예를 들어, 쿼터 도메인 1)의 기억 영역에 캐시된다(도 8의 C1). 한편, 캐시 쿼터 도메인(예를 들어, 쿼터 도메인 1)이 지정된 LCT 세션과 동일한 서비스에 속하는 LCT 세션이더라도, 캐시 쿼터 도메인(예를 들어, 쿼터 도메인 1)이 지정되어 있지 않은 LCT 세션에 대해서는, 영속 캐시의 대상외로 된다(도 8의 C2).

또한, 상세는, 도 16의 USBD 메타데이터의 포맷을 참조하여 후술하지만, USBD 메타데이터의 USD 요소의 STSIDUri 속성에는, S-TSID 메타데이터의 취득처를 나타내는 URI(Uniform Resource Identifier)가 지정된다. 그리고, 이 URI에 따라서, S-TSID 메타데이터가 취득된다.

또한, 도 7에 도시한 바와 같이, 애플리케이션 단위로 리소스를 공유시키고 싶은 경우에는, AST 메타데이터의 애플리케이션마다의 속성을 확장하여, quotaDomain 속성을 정의하도록 한다. 즉, 대상의 AST 메타데이터의 기술 대상으로 하는 애플리케이션의 파일이 저장되는 로컬 캐시의 기억 영역을 식별하기 위한 쿼터 도메인 식별자가, AST 메타데이터의 quotaDomain 속성에 의해 지정되는 문자열에 상당하게 된다.

단, AST 메타데이터의 quotaDomain 속성에 의해, 애플리케이션 레벨로, 캐시 쿼터 도메인(예를 들어, 쿼터 도메인 1)이 지정된 경우에는, 대상의 애플리케이션이 속하는 서비스가, 캐시 쿼터 도메인(예를 들어, 쿼터 도메인 1)에 속해 있다고 인식된다.

그리고, 캐시 쿼터 도메인(예를 들어, 쿼터 도메인 1)이 지정된 애플리케이션의 파일에 대하여, 로컬 캐시(의 영속 캐시)에 캐시하는 것이 지시된 경우에는, 그들 파일이, 로컬 캐시의 캐시 쿼터 도메인(예를 들어, 쿼터 도메인 1)의 기억 영역에 캐시된다(도 8의 D). 한편, 캐시 쿼터 도메인(예를 들어, 쿼터 도메인 1)이 지정된 애플리케이션과 동일한 서비스에 속하는 애플리케이션이더라도, 캐시 쿼터 도메인(예를 들어, 쿼터 도메인 1)이 지정되어 있지 않은 애플리케이션에 대해서는, 영속 캐시의 대상외로 된다.

이상과 같이, 캐시 쿼터 도메인의 개념을 도입하여, 캐시 쿼터 도메인을 식별하는 쿼터 도메인 식별자(리소스 공유 정보)를 SLT, USBD, S-TSID, AST 등의 메타데이터(제어 정보)에 포함해서 전송함으로써, 클라이언트 장치(40)에서는, 동일한 캐시 쿼터 도메인에 속하는 서비스에 포함되는 파일(리소스)을, 로컬 캐시(의 영속 캐시)에 유지하여, 서비스 단위, LCT 세션 단위, 또는 애플리케이션 단위로 공유시키는 것이 가능해진다.

<3. 애플리케이션의 응용예>

다음으로, 도 9 내지 도 14를 참조하여, 제1 콘텐츠(방송 프로그램)와 함께 전송되는 애플리케이션에 의해, 제2 콘텐츠(광고)의 삽입을 행하는 시스템에 있어서, 캐시 쿼터 도메인을 실장하는 경우에 대하여 설명한다. 또한, 당해 애플리케이션은, 스크립트(Script)를 실행함으로써, 광고 삽입 제어(Ad-Insertion)를 행하는 것이기 때문에, 이하, 스크립트 애플리케이션(Script App)이라 칭하여 설명한다.

(광고 삽입의 흐름)

도 9는, 광고 삽입의 흐름을 설명하는 도면이다.

도 9에 있어서는, 클라이언트 장치(40)에서, 방송 프로그램(BP1, BP2)의 사이에 재생되는 디폴트 광고(TV1_Ad) 대신에 유저에게 적합한 광고(TV2_Ad)가 삽입되는 경우의 예를 나타내고 있다.

도면 중의 좌측으로부터 우측의 방향을 시간 방향으로 한 경우에 있어서, 방송 프로그램 BP1이 재생되는 시각 t1 내지 시각 t2와, 방송 프로그램 BP2가 재생되는 시각 t3 내지 시각 t4 사이의 시각 t2 내지 시각 t3에서는, 통상은 실시간으로 취득되는 광고 Ad1이 재생된다.

또한, 이 예에서는, 디폴트 광고 Ad1과, 삽입용 광고 Ad2의 2종류의 광고가 준비되어 있지만, 광고 Ad2는, 시각 t1 내지 시각 t2에서 방송 프로그램 BP1-1이 재생되고 있을 때, 즉, 광고의 삽입 구간보다도 시간적으로 앞에, 방송 경유 또는 통신 경유로 취득되고, 로컬 캐시(의 영속 캐시)에 캐시되어 있다.

클라이언트 장치(40)에서는, 방송 프로그램 BP1-2의 장면으로 되었을 때, 영상에 유저에 대한 질문이 중첩 표시된다. 그리고, 클라이언트 장치(40)는, 질문에 대한 유저의 회답에 응답하여, 당해 유저에게 적합한 광고를 표시시킨다. 예를 들어, 클라이언트 장치(40)에서는, 유저가 질문에 대해서 회답을 한 경우에는, 당해 회답에 응답한 삽입용 광고 Ad2가, 로컬 캐시(의 영속 캐시)로부터 판독되고, 디폴트 광고 Ad1을, 유저에게 적합한 광고 Ad2로 대체하여 재생하게 된다.

이와 같이, 유저에 의해 시청될 가능성이 있는 광고를, 클라이언트 장치(40)의 로컬 캐시(의 영속 캐시)에 캐시해 둠으로써, 그 캐시되어 있던 광고를 이용하여, 유저에게 적합한 광고를 표시시킬 수 있다.

또한, 도 9의 광고 삽입의 예에서는, 유저의 입력 조작에 응답하여, 당해 유저에게 적합한 광고의 콘텐츠가 선택되는 예를 나타냈지만, 이와 같은 유저 사이에서의 정보의 교환(인터랙션) 외에, 예를 들어 유저의 프리퍼런스나 프로파일 등의 미리 설정된 유저의 특성에 관한 정보(예를 들어, 성별이나 연령, 거주 지역 등) 등을 이용하여, 광고의 콘텐츠가 선택되도록 해도 된다.

그런데, 이동체 통신 시스템의 표준화 프로젝트인 3GPP(Third Generation Partnership Project)나, DASH-IF(Industry Forum)에 있어서는, MPEG-DASH에 의해 규정되어 있는, Period 요소의 XLink에 의한 퍼스널라이즈된 광고 삽입 제어(Ad-Insertion)의 실현 방법이 답습되고 있지만, ATSC 3.0에 있어서도, 이 광고 삽입 제어의 실현 방법이 답습되는 것이 상정되어 있다. 또한, XLink는, XML 문서끼리의 링크를 정의하기 위한 사양으로서, W3C(World Wide Web Consortium)에 의해 권고되어 있다.

이 광고 삽입 제어에서는, MPD 메타데이터의 광고 삽입 구간에 대응하는 Period 요소를 포함하는 파일을 미리 준비해 두고, 광고의 콘텐츠 스트림에 대응하는 세그먼트를 지정하는 Period 요소를, 유저의 특성(예를 들어, 유저 프리퍼런스 등)에 응답하여 동적으로 변경하는 방식을 채용하고 있다. 이와 같은 광고 삽입 제어에 대응한 클라이언트 장치(40)가, 도 10에 도시되어 있다.

도 10에 있어서, 클라이언트 장치(40)는, 애플리케이션/코덱 기능과, DASH 클라이언트 기능과, 트랜스포트 스택/HTTP 서버 기능을 갖고 있다. 또한, 트랜스포트 스택/HTTP 서버 기능에는, XLink 리졸버(XLink Resolver)와, HTTP 프록시 캐시(HTTP Proxy Cache)의 기능이 포함된다. 단, XLink 리졸버의 기능은, 통신 서버(30)의 HTTP 서버가 갖도록 해도 된다.

여기서, 클라이언트 장치(40)에 있어서, SLS 시그널링으로서 전송되는 MPD 메타데이터가 수신된 경우, MPD 메타데이터는, HTTP 프록시 캐시에 의해 취득되고, DASH 클라이언트에 통지된다(S51). 이 MPD 메타데이터에는, Period 요소의 xlink:href 속성으로서, 클라이언트 장치(40) 또는 통신 서버(30)의 HTTP 서버상에서 가동하는 XLink 리졸버에 의해 해결되는 URL(Uniform Resource Locator)이 지정되어 있다.

구체적으로는, 도 11에 도시한 바와 같이, MPD 메타데이터에 기술된 Period 요소인 A1(Ad Break #1), M1(Main Program), A2(Ad Break #2), M2(Main Program), A3(Ad Break #3), M3(Main Program) 중, A1(Ad Break #1)인 Period 요소에 주목하면, xlink:href 속성의 URL로서, "http://adservice.com/adp-1?user=$groupID$"가 기술되어 있다.

또한, A2(Ad Break #2) 또는 A3(Ad Break #3)에 있어서도, xlink:href 속성의 URL로서, "http://adservice.com/adp-1?user=$groupID$"가 기술되어 있으며, A1(Ad Break #1)과 마찬가지로 처리되도록 한다.

도 10의 설명으로 되돌아가서, 클라이언트 장치(40)에 있어서는, 이 URL의 groupID의 파라미터 부분에, 유저를 특정하는 값을 삽입하여, 클라이언트 장치(40) 또는 통신 서버(30)의 HTTP 서버상의 XLink 리졸버에, HTTP 리퀘스트를 발행하게 된다(S52). 예를 들어, "http://adservice.com/adp-1?user=classA"와 같이, groupID의 값이 삽입된 URL이, XLink 리졸버에 통지된다.

클라이언트 장치(40) 또는 통신 서버(30)의 XLink 리졸버는, DASH 클라이언트로부터, groupID의 값이 삽입된 URL이 통지되면, groupID에 의해 지정되는 특정한 유저(예를 들어, classA의 유저)용으로 생성된 URL을 포함하는 Period 요소의 파일(이하, '피리어드 파일'이라고 함)을, DASH 클라이언트에 회신한다(S53). 이 Period 요소에 포함되는 URL은, 일방향의 방송 경유인 경우의 ROUTE 프로토콜이나, 쌍방향의 통신 경유인 경우의 HTTP 프로토콜에 의해 배신되는 세그먼트의 URL(세그먼트 URL)로 된다.

그리고, 클라이언트 장치(40)에 있어서는, DASH 클라이언트와 HTTP 프록시 캐시가, 스텝 S53의 처리에 의해 취득된 피리어드 파일의 Period 요소에 응답하여, 세그먼트의 리퀘스트나 딜리버리 등의 교환을 행함으로써, 당해 Period 요소의 세그먼트 URL에 응답한 세그먼트가 취득된다(S54).

이와 같이 하여 취득되는 세그먼트에 응답한 광고의 콘텐츠가, 광고의 삽입 구간(예를 들어, 도 9의 시각 t2 내지 시각 t3의 구간)에서 재생되게 된다.

보다 구체적으로는, 도 12에는, 00:00:00 내지 00:15:00의 사이에, M1(Main Program)이 재생되고, 00:15:00 내지 00:30:00의 사이에, M2(Main Program)가 재생되며, 00:30:00 내지 00:42:00의 사이에, M3(Main Program)이 재생되는 경우에 있어서, M1의 재생보다도 시간적으로 앞에 A1(Ad Break #1)이 삽입되고, M1과 M2의 사이에 A2(Ad Break #2)가 삽입되며, M2와 M3의 사이에, A3(Ad Break #3)이 삽입될 때의 광고 삽입 제어를 예시하고 있다.

이 예에서는, A1(Ad Break #1)로서, 3종류의 광고가 준비되어 있으며, 예를 들어 30대 남성이나 60대 여성 등의 유저의 특성(예를 들어, 유저 프리퍼런스 등)에 따라서, 재생되는 광고의 내용이 동적으로 변화하게 된다. 마찬가지로, A2(Ad Break #2)와 A3(Ad Break #3)으로서도 복수의 광고가 준비되어 있으며, 유저의 특성에 응답한 광고가 재생되게 된다.

또한, 도 10에 있어서는, 클라이언트 장치(40) 또는 통신 서버(30)의 HTTP 서버상에서, XLink 리졸버가 가동되는 예를 설명하였지만, 클라이언트 장치(40)에 있어서는, 스크립트 애플리케이션이, XLink 리졸버의 역할을 담당하도록 할 수 있다.

즉, DASH 클라이언트가, MPD 메타데이터를 파싱(구문 해석)함으로써, 광고 삽입용 Period 요소의 xlink:href 속성의 URL을 검출한 경우에, 바로 HTTP 리퀘스트를, HTTP 서버상에서 가동하는 XLink 리졸버에 송신하는 것이 아니라, 그 URL을, 스크립트 애플리케이션에 통지하도록 한다.

스크립트 애플리케이션은, DASH 클라이언트로부터 URL이 통지되면(XLink의 해결이 요구되면), 당해 URL의 패스 부분이나 쿼리 문자열에 반영되어 있는 광고 삽입 구간을 식별하기 위한 정보에 기초하여, 그 구간에 대응하는 광고의 콘텐츠(Ad 세그먼트)의 삽입 후보 중, 대상의 유저에게 적합한 광고의 콘텐츠(Ad 세그먼트)를 선택한다.

그리고, 스크립트 애플리케이션은, 선택한 광고의 콘텐츠(Ad 세그먼트)에 대응하는 Period 요소를 포함하는 피리어드 파일을 생성하고, DASH 클라이언트에 응답한다. 예를 들어, 이 피리어드 파일의 Period 요소는, groupID에 의해 지정되는 특정한 유저(예를 들어, classA의 유저)용으로 생성된 URL을 포함하고, 이 세그먼트 URL의 리스트에 기초하여, Ad 세그먼트군을 재생하면, 광고의 콘텐츠가 재생되게 된다.

여기서, 유저에게 적합한 광고의 콘텐츠 선택이지만, 예를 들어 클라이언트 장치(40)에 의해 관리되는 유저 프리퍼런스 등에 응답하여 행해지는 경우도 있으며 유저 사이에서 정보의 교환(인터랙션)을 행하여, 수시 취득되는 정보에 응답하여 행해지도록 해도 된다. 예를 들어, 전술한 도 9의 광고 삽입의 예에서는, 유저의 입력 조작에 응답하여, 당해 유저에게 적합한 광고의 콘텐츠가 선택되어 있다.

이와 같이, 클라이언트 장치(40)측에서, MPD 메타데이터의 Period 요소의 XLink의 해결이 행해지도록 함으로써, 통신 서버(30)의 HTTP 서버상에서 가동하는 XLink 리졸버에, XLink의 해결을 의뢰할 필요가 없어지게 된다.

그로 인해, 통신 서버(30)의 XLink 리졸버에 의해 XLink의 해결을 행하도록 한 경우에는, 광고 삽입 구간의 직전에, 인터넷(90)에 접속된 다수의 클라이언트 장치(40)로부터의 액세스가, 통신 서버(30)에 집중하는 것이 상정되지만, 클라이언트 장치(40)의 XLink 리졸버에 의해 XLink의 해결을 행함으로써, XLink의 해결의 트랜잭션 처리 부하 증가의 해소를 도모할 수 있다.

또한, 클라이언트 장치(40)에서는, 스크립트 애플리케이션에 의해, 광고 삽입 구간보다도 시간적으로 앞에, 방송 경유 또는 통신 경유로 취득되는 광고의 콘텐츠(Ad 세그먼트)의 후보를, 로컬 캐시(의 영속 캐시)에 캐시해 둠으로써, 광고 삽입 제어에 의한 광고 삽입의 확실성을 담보할 수 있다. 예를 들어, 광고의 콘텐츠(Ad 세그먼트)를 통신 경유로 취득하는 경우에는, 인터넷(90)의 통신 상황 등에 의해, 광고의 콘텐츠(Ad 세그먼트)를 취득할 수 없음도 상정되지만, 미리 캐시해 두면, 광고 삽입 제어에 의한 광고 삽입의 확실성을 높일 수 있다.

또한, 본 기술에서는, 캐시 쿼터 도메인의 개념을 도입하고, 클라이언트 장치(40)에 있어서, 복수의 서비스 중에서 재이용되는 광고의 콘텐츠(Ad 세그먼트)의 파일을 공유할 수 있도록 하고 있기 때문에, 로컬 캐시(의 영속 캐시)에 캐시되는 광고의 콘텐츠(Ad 세그먼트)의 후보의 재이용성을 높여, 보다 확실하게 광고 삽입 제어에 의한 광고 삽입을 행할 수 있다.

(MPD의 기술의 예)

다음으로, 도 13 및 도 14를 참조하여, XML 형식의 MPD 메타데이터의 기술(記述)의 예에 대하여 설명한다.

또한, MPD 메타데이터에서는, Period 요소, AdaptationSet 요소, 및Representation 요소가 계층 구조로 기술되어 있다. Period 요소는, 콘텐츠 등의 서비스의 구성을 기술하는 단위로 된다. 또한, AdaptationSet 요소와, Representation 요소는, 비디오나 오디오, 자막 등의 서비스 컴포넌트의 스트림마다 이용되고, 각각의 스트림의 속성을 기술할 수 있도록 되어 있다.

도 13의 MPD 메타데이터의 기술의 예에서는, 본편의 Period 요소와, 광고(Ad)의 Period 요소가 기술되어 있다.

본편의 Period 요소에는, 본편의 콘텐츠(MP4 형식의 동화상 파일)의 재생을 관리하기 위한 정보가 기술되어 있다. 단, AssetIdentifier 요소의 schemeIdUri 속성과 value 속성에는, EIDR(Entertainment Identifier Registry)에 대응한 ID가 부여되어 있다.

한편, 광고(Ad)의 Period 요소에는, 디폴트 광고의 콘텐츠(MP4 형식의 동화상 파일)의 재생을 관리하기 위한 정보와 함께, Period 요소의 xlink:href 속성에 URL이 기술되어 있다(도면 중의 A). 이 URL이, 통신 서버(30)의 HTTP 서버상에서 가동하는 XLink 리졸버에 통지됨으로써, 삽입용 광고가 취득되고, 디폴트 광고가, 삽입용 광고로 대체된다.

도 14의 MPD 메타데이터의 기술의 예에 있어서도, 본편의 Period 요소와, 광고(Ad)의 Period 요소가 기술되어 있다.

본편의 Period 요소에는, 본편의 콘텐츠(MP4 형식의 동화상 파일)의 재생을 관리하기 위한 정보가 기술되어 있다.

한편, 광고(Ad)의 Period 요소에는, 디폴트 광고 콘텐츠(MP4 형식의 동화상 파일)의 재생을 관리하기 위한 정보와 함께, Period 요소의 xlink:href 속성에 URL이 기술되어 있다(도면 중의 A). 여기서는, groupID의 값이 삽입된 URL이, 클라이언트 장치(40)의 HTTP 서버상에서 가동하는 XLink 리졸버에 통지됨으로써, groupID에 의해 지정되는 특정한 유저에게 적합한 광고가 취득되고, 디폴트 광고가, 유저에게 적합한 광고로 교체된다. 또한, 도면 중의 A에 있어서, "urn:atsc:ad-insertion"은, 광고 삽입 제어의 해결을, 로컬(클라이언트 장치(40))로 실행되는 스크립트(스크립트 애플리케이션)에 의뢰해야만 함을 나타내는 것이지만, 그 상세한 내용은 후술하도록 한다.

또한, 전술한 설명에서는, 광고의 콘텐츠를 일례로 설명하고, 캐시 쿼터 도메인을 사용하여, 복수의 서비스 중에서, 광고의 콘텐츠(Ad 세그먼트)의 파일을 공유할 수 있도록 하였지만, 본 기술은, 광고 이외의 다른 콘텐츠에 적용할 수도 있다. 또한, 파일은, 콘텐츠의 리소스 일례이며, 클라이언트 장치(40)가 처리 가능한 데이터이면, 모든 데이터를 대상으로 할 수 있다.

<4. 시그널링의 예>

다음으로, 도 15 내지 도 21을 참조하여, 캐시 쿼터 도메인을 식별하는 쿼터 도메인 식별자를 전송하는 시그널링의 포맷의 예를 설명한다.

(SLT의 포맷)

도 15는, XML 형식의 SLT 메타데이터의 포맷의 예를 나타내는 도면이다. 또한, 도 15에 있어서, 요소와 속성 중, 속성에는 「＠」가 부여되어 있다. 또한, 인덴트된 요소와 속성은, 그 상위의 요소에 대해서 지정된 것으로 된다. 이들 관계는, 후술하는 다른 시그널링의 포맷에서도 마찬가지로 된다.

SLT 요소는, 루트 요소로서, bsid 속성, sltCapabilities 속성, sltInetUrl 요소, 및 Service 요소의 상위 요소로 된다.

bsid 속성에는, 브로드캐스트 스트림 ID가 지정된다. sltCapabilities 속성에는, 필요한 기능에 관한 정보가 지정된다.

sltInetUrl 요소에는, ESG나 SLS 시그널링을 취득하기 위한 베이스 URL이 지정된다. sltInetUrl 요소는, urlType 속성의 상위 요소로 된다. urlType 속성에는, 베이스 URL로 이용 가능한 파일의 종류가 지정된다.

Service 요소에는, 1개 또는 복수의 서비스에 관한 정보가 지정된다. Service 요소는, serviceId 속성, sltSvcSeqNum 속성, protected 속성, majorChannelNo 속성, minorChannelNo 속성, serviceCategory 속성, shortServiceName 속성, hidden 속성, broadbandAccessRequired 속성, svcCapabilities 속성, quotaDomain 속성, BroadcastSvcSignaling 요소, 및 svcInetUrl 요소의 상위 요소로 된다.

serviceId 속성에는, 서비스 ID가 지정된다. sltSvcSeqNum 속성에는, SLT 메타데이터의 버전에 관한 정보가 지정된다. protected 속성에는, 서비스의 보호를 나타내는 암호화 정보가 지정된다.

majorChannelNo 속성에는, 메이저 채널 번호가 지정된다. minorChannelNo 속성에는, 마이너 채널 번호가 지정된다. serviceCategory 속성에는, 서비스의 카테고리가 지정된다. shortServiceName 속성에는, 쇼트 서비스명이 지정된다.

hidden 속성에는, 서비스가, 숨겨진 서비스인지 여부가 지정된다. broadbandAccessRequired 속성에는, 인터넷(90) 등의 통신 회선에 액세스할 필요가 있는지 여부가 지정된다. svcCapabilities 속성에는, 디코드에 필요한 기능 등의 정보가 지정된다.

quotaDomain 속성에는, 대상의 서비스가 속해 있는 캐시 쿼터 도메인의 쿼터 도메인 식별자가 지정된다. 동일한 캐시 쿼터 도메인에 속하는 서비스에서는, 로컬 메모리에 캐시되는 리소스(파일)가 공유되게 된다.

BroadcastSvcSignaling 요소에는, SLS 시그널링이 방송 경유로 취득되는 경우에, 당해 SLS 시그널링의 취득처에 관한 정보가 지정된다. BroadcastSvcSignaling 요소는, slsProtocol 속성, slsMajorProtocolVersion 속성, slsMinorProtocolVersion 속성, slsPlpId 속성, slsDestinationIpAddress 속성, slsDestinationUdpPort 속성, 및 slsSourceIpAddress 속성의 상위 요소로 된다.

slsProtocol 속성에는, SLS 시그널링 프로토콜에 관한 정보가 지정된다. slsMajorProtocolVersion 속성에는, SLS 시그널링 프로토콜의 메이저 버전 번호가 지정된다. slsMinorProtocolVersion 속성에는, SLS 시그널링 프로토콜의 마이너 버전 번호가 지정된다.

slsPlpId 속성에는, SLS 시그널링이 전송되는 PLP(Physical Layer Pipe)의 ID가 지정된다. slsDestinationIpAddress 속성에는, SLS 시그널링의 수신처(destination)의 IP 어드레스가 지정된다. slsDestinationUdpPort 속성에는, SLS 시그널링의 수신처(destination)의 포트 번호가 지정된다. slsSourceIpAddress 속성에는, SLS 시그널링의 송신원(source)의 IP 어드레스가 지정된다.

svcInetUrl 요소에는, SLS 시그널링이 통신 경유로 취득되는 경우에, 당해SLS 시그널링의 취득처의 URL이 지정된다. svcInetUrl 요소는, urlType 속성의 상위 요소로 된다. urlType 속성에는, 이 URL로 이용 가능한 파일의 종류가 지정된다.

또한, 도 15에 있어서, 출현 수(Use)이지만, "1"이 지정된 경우에는 그 요소 또는 속성은 반드시 1개만 지정되고, "0..1"이 지정된 경우에는, 그 요소 또는 속성을 지정할지 여부는 임의이다. 또한, "1..N"이 지정된 경우에는, 그 요소 또는 속성은 1 이상 지정되고, "0..N"이 지정된 경우에는, 그 요소 또는 속성을 1 이상 지정할지 여부는 임의이다.

또한, Data Type으로서, "unsignedShort" 또는 "unsignedByte"가 지정된 경우, 그 요소 또는 속성의 값이, 정수형임을 나타내고 있다. Data Type으로서, "string"이 지정된 경우에는, 그 요소 또는 속성의 값이, 문자열형임을 나타내고, "anyURI"이 지정된 경우, 그 요소 또는 속성의 값이, URI의 형식을 한 문자열임을 나타내고 있다. Data Type으로서, "boolean"이 지정된 경우에는, 그 요소 또는 속성이 불 방식임을 나타내고 있다. 또한, Data Type으로서, "language"가 지정된 경우, 그 요소 또는 속성의 값이, xml:lang 속성의 값으로서 유효한 것임을 나타내고, "dateTime"이 지정된 경우, 그 요소 또는 속성의 값이, 특정한 일시임을 나타내도록 한다.

(USBD의 포맷)

도 16은, XML 형식의 USBD 메타데이터의 포맷의 예를 나타내는 도면이다.

bundleDescription 요소는, 루트 요소로서, userServiceDescription 요소(USD 요소)의 상위 요소로 된다. 이 userServiceDescription 요소는, globalServiceID 속성, serviceId 속성, serviceStatus 속성, fullMPDUri 속성, sTSIDUri 속성, quotaDomain 속성, name 요소, serviceLanguage 요소, capabilityCode 요소, deliveryMethod 요소의 상위 요소로 된다.

globalServiceID 속성에는, 글로벌 서비스 ID가 지정된다. serviceId 속성에는, 서비스 ID가 지정된다. serviceStatus 속성에는, 서비스의 스테이터스에 관한 정보가 지정된다. fullMPDUri 속성에는, MPD 메타데이터를 참조하기 위한 URI가 지정된다. sTSIDUri 속성에는, S-TSID 메타데이터를 참조하기 위한 URI가 지정된다.

name 요소에는, ATSC 3.0의 서비스 명칭이 지정된다. name 요소는, lang 속성의 상위 요소가 된다. lang 속성에는, ATSC 3.0의 서비스 명칭 언어가 지정된다. serviceLanguage 요소에는, ATSC 3.0의 서비스에서 이용할 수 있는 언어가 지정된다. capabilityCode 요소에는, 기능에 관한 코드가 지정된다.

deliveryMethod 요소에는, 데이터의 배신 방법에 관한 정보가 지정된다. deliveryMethod 요소는, broadcastAppService 요소 및 unicastAppService 요소의 상위 요소로 된다. broadcastAppService 요소는, basePattern 요소의 상위 요소로서, 방송 경유에서의 배신에 관한 정보가 지정된다. unicastAppService 요소는, basePattern 요소의 상위 요소로서, 통신 경유에서의 배신에 관한 정보가 지정된다.

(S-TSID의 포맷)

도 17은, S-TSID 메타데이터의 포맷의 예를 나타내는 도면이다.

S-TSID 요소는, 루트 요소로서, serviceId 속성 및 RS 요소의 상위 요소로 된다. serviceId 속성에는, 서비스 ID가 지정된다.

RS 요소에는, ROUTE 세션에 관한 정보가 지정된다. RS 요소는, bsid 속성, sIpAddr 속성, dIpAddr 속성, dport 속성, PLPID 속성, 및 LS 요소의 상위 요소로 된다.

bsid 속성에는, 브로드캐스트 스트림 ID가 지정된다. sIpAddr 속성에는, 송신원(source)의 IP 어드레스가 지정된다. dIpAddr 속성에는, 수신처(destination)의 IP 어드레스가 지정된다. dport 속성에는, 수신처(destination)의 포트 번호가 지정된다. PLPID 속성에는, ROUTE 세션의 PLP의 ID가 지정된다.

LS 요소에는, LCT 세션에 관한 정보가 지정된다. LS 요소는, tsi 속성, PLPID 속성, bw 속성, startTime 속성, endTime 속성, SrcFlow 요소, 및 RprFlow 요소의 상위 요소로 된다.

tsi 속성에는, TSI가 지정된다. PLPID 속성에는, PLP의 ID가 지정된다. bw 속성에는, 대역폭이 지정된다. startTime 속성과 endTime 속성에는, 개시 일시와 종료 일시가 지정된다. SrcFlow 요소에는, 소스 플로우 정보가 지정된다. 또한, 이 SrcFlow 요소의 상세한 내용은, 도 18을 참조하여 후술한다. RprFlow 요소에는, 리페어 플로우 정보가 지정된다.

(SrcFlow 요소의 포맷)

도 18은, 도 17의 S-TSID 메타데이터에 포함되는 SrcFlow 요소의 포맷 예를 나타내는 도면이다.

SrcFlow 요소는, rt 속성, minBuffSize 속성, EFDT 요소, ContentInfo 요소, 및 Payload 요소의 상위 요소로 된다. minBuffSize 속성에는, 클라이언트 장치(40)가 필요로 하는 최소 버퍼 사이즈가 지정된다.

EFDT 요소에는, 확장된 FDT(Extended FDT)에 관한 정보가 지정된다. ContentInfo 요소에는, 콘텐츠에 관한 정보가 지정된다. ContentInfo 요소는, quotaDomain 속성의 상위 요소로 된다.

quotaDomain 속성에는, 대상의 LCT 세션을 포함하는 서비스가 속해 있는 캐시 쿼터 도메인의 쿼터 도메인 식별자가 지정된다. 동일한 캐시 쿼터 도메인에 속하는 서비스에서는, 로컬 메모리에 캐시되는 리소스(파일)가 공유되게 된다.

Payload 요소는, codePoint 속성, formatID 속성, frag 속성, order 속성, srcFecPayloadID 속성, 및 FECParams 속성의 상위 요소로서, 소스 플로우의 오브젝트를 저장하는 ROUTE 패킷의 페이로드에 관한 정보가 지정된다.

(AST의 포맷)

도 19 내지 도 21은, AST 메타데이터의 포맷의 예를 나타내는 도면이다.

ApplicationList 요소는, 루트 요소로서, Application 요소 및 ApplicationReference 요소의 상위 요소로 된다.

Application 요소에는, 애플리케이션에 관한 정보가 지정된다. Application 요소는, appName 요소, applicationIdentifier 요소, applicationDescriptor 요소, applicationUsageDescriptor 요소, applicationBoundary 요소, applicationTransport 요소, applicationLocation 요소, 및 applicationSpecificDescriptor 요소의 상위 요소로 된다.

appName 요소는, Language 속성의 상위 요소로서, 애플리케이션의 명칭이 지정된다. applicationIdentifier 요소는, orgID 요소 및 appID의 상위 요소로서, 애플리케이션의 애플리케이션 ID가 지정된다.

applicationDescriptor 요소는, type 요소, controlCode 요소, visibility 요소, serviceBound 요소, priority 요소, version 요소, icon 요소, 및 storageCapabilities 요소의 상위 요소로서, 대상의 애플리케이션 프로퍼티에 관한 정보가 지정된다.

applicationUsageDescriptor 요소는, ApplicationUsage 요소의 상위 요소로서, 애플리케이션의 Usage 타입에 관한 정보가 지정된다. applicationBoundary 요소에는, 애플리케이션의 바운더리에 관한 정보가 지정된다. applicationTransport 요소에는, 애플리케이션의 트랜스포트 프로토콜에 관한 정보가 지정된다.

트랜스포트 타입이, HTTP의 경우에는, URLBase 요소 및 URLExtension 요소가 배치되고, URL이 지정된다. URLExtension 요소에는, 확장 URL이 지정된다. 또한, 트랜스포트 타입이 ROUTE의 경우에는, atsc:ROUTESessionInfo 요소(LCTSession 요소, tsi 속성, plpID 속성을 포함함), broadcastStreamId 속성, plpID 속성, sourceIpAddress 속성, destinationIpAddress 속성, 및 destinationPort 속성이 배치되고, ROUTE 세션에 관한 정보가 지정된다.

applicationLocation 요소에는, 애플리케이션의 로케이션 정보가 지정된다. applicationSpecificDescriptor 요소에는, 애플리케이션의 기술자가 배치된다. 이 기술자로서는, DVB(Digital Video Broadcasting)에 대응한 dvbDescriptor, HTML(HyperText Markup Language)에 대응한 htmlDescriptor, ATSC에 대응한 atscDescriptor, 또는 그 밖의 규격에 대응한 otherDescriptor가 선택적으로 배치된다.

atsc:atscDescriptor 요소는, quotaDomain 속성, size 요소, requiredCapabilities 요소, icon 요소, ApplicationRecordingDescriptor 요소, timeSlotInfo 요소, contentLinkage 요소, contentItem 요소 및graphicConstraintsDescriptor의 상위 요소로서, ATSC(ATSC 3.0)에 관한 정보가 지정된다.

quotaDomain 속성은, 대상의 애플리케이션을 포함하는 서비스가 속해 있는 캐시 쿼터 도메인의 쿼터 도메인 식별자가 지정된다. 동일한 캐시 쿼터 도메인에 속하는 서비스에서는, 로컬 메모리에 캐시되는 리소스(파일)가 공유되게 된다.

단, icon 요소는, filename 속성, size 속성, 및 aspectRatio 속성을 포함한다. 또한, ApplicationRecordingDescriptor 요소는, scheduled_recording_flag 요소, trick_mode_aware_flag 요소, time_shift_flag 요소, dynamic_flag 요소, av_synced_flag 요소, initiating_replay_flag 요소, 및 storage_properties 요소를 포함한다. 또한, timeSlotInfo 요소는, timeslot_type 요소, timeslot_start 요소, timeslot_length 요소, acquisition_time 요소, 및 repeat_period 요소를 포함한다.

또한, contentItem 요소는, location 속성, contentLinkage 속성, updatesAvailable 속성, size 속성, 및 timeSlotInfo 요소를 포함한다. 이 timeSlotInfo 요소는, timeslot_type 요소, timeslot_start 요소, timeslot_length 요소, acquisition_time 요소, 및 repeat_period 요소를 포함한다. graphicConstraintsDescriptor 요소는, can_run_without_visible_ui 요소, handles_configuration_changed 요소, handles_externally_controlled_video 요소, graphics_configuration_byte 요소, 및 screenPosition 요소를 포함한다.

또한, 도 15 내지 도 21을 참조하여 설명한 SLT 메타데이터, USBD 메타데이터, S-TSID, 및 AST 메타데이터의 포맷은 일례로서, 예를 들어 다른 요소나 속성을 추가하는 등, 그 일부를 변경한 포맷이 채용되도록 해도 된다. 또한, SLT 메타데이터, USBD 메타데이터, S-TSID, 및 AST 메타데이터는, XML 형식으로 한정되지 않으며, 다른 마크업 언어에 의해 기술해도 되고, 혹은 섹션 형식이어도 된다.

또한, SLT 메타데이터, USBD 메타데이터, S-TSID, 및 AST 메타데이터 등의 시그널링을 확장함으로써 추가되는 quotaDomain 속성에 의해 지정되는 쿼터 도메인 식별자는, 1종류의 메타데이터에 포함하도록 해도 되고, 복수 종류의 메타데이터에 포함하도록 해도 된다. 또한, 복수의 서비스가 제공되는 경우에, 서비스마다 서로 다른 종류의 메타데이터에, quotaDomain 속성에 의해 지정되는 쿼터 도메인 식별자가 기술되도록 해도 된다. 또한, 전술한 각 메타데이터의 포맷의 예에서는, 쿼터 도메인 식별자가, quotaDomain 속성에 의해 지정되는 경우를 일례로 설명하였지만, 쿼터 도메인 식별자는, 속성에 한정되지 않으며, 예를 들어 요소나, 텍스트로서 기술된 정보 등에 의해 지정되게 해도 된다.

<5. 각 장치의 구성>

다음으로, 도 22 내지 도 25를 참조하여, 도 1의 전송 시스템(1)에서의, 송신측의 Ad/DASH 서버(10), 방송 서버(20), 및 통신 서버(30)와, 수신측의 클라이언트 장치(40)의 구성에 대하여 설명한다.

(Ad/DASH 서버의 구성)

도 22는, 도 1의 Ad/DASH 서버(10)의 구성예를 나타내는 도면이다.

도 22에 있어서, Ad/DASH 서버(10)는, 수신부(101), Ad/DASH 세그먼트 생성부(102), 스크립트 애플리케이션 생성부(103), MPD 생성부(104), 처리부(105), 및 송신부(106)로 구성된다.

수신부(101)는, 외부의 서버(도시생략) 등으로부터 스트리밍 배신용 데이터를 수신하고, Ad/DASH 세그먼트 생성부(102), 스크립트 애플리케이션 생성부(103), 및 MPD 생성부(104)에 공급한다.

Ad/DASH 세그먼트 생성부(102)는, 수신부(101)로부터 공급되는 데이터에 기초하여, Ad 세그먼트 및 DASH 세그먼트를 생성하고, 처리부(105)에 공급한다.

여기서, Ad 세그먼트는, 광고의 콘텐츠를 처리하여 얻어지는 세그먼트 파일이다. 또한, DASH 세그먼트는, 중계 장소로부터 전송로나 통신 회선을 통해 보내져 오는 라이브 콘텐츠(예를 들어, 스포츠 중계 등의 생방송 프로그램)나, 스토리지에 축적된 수록 완료의 콘텐츠(예를 들어, 드라마 등의 사전 수록 프로그램) 등의 콘텐츠를 처리하여 얻어지는 세그먼트 파일이다. 또한, Ad 세그먼트는, DASH 세그먼트의 일종이라고도 할 수 있지만, 여기서는, 설명의 편의상, Ad 세그먼트와 DASH 세그먼트를 구별하여 설명한다.

스크립트 애플리케이션 생성부(103)는, 수신부(101)로부터 공급되는 데이터에 기초하여, 스크립트 애플리케이션을 생성하고, 처리부(105)에 공급한다. 여기서, 스크립트 애플리케이션은, 스크립트(Script)를 실행 가능한 애플리케이션이다. 이 스크립트 애플리케이션은, 예를 들어 HTML5 등의 마크업 언어나, JavaScript(등록상표) 등의 스크립트 언어로 개발된 애플리케이션으로 할 수 있다.

MPD 생성부(104)는, 수신부(101)로부터 공급되는 데이터에 기초하여, MPD 메타데이터를 생성하고, 처리부(105)에 공급한다. 여기서, MPD 메타데이터에는, 프로그램이나 광고 등의 콘텐츠에 대응한 Period 요소가 기술되지만, 그 상세한 내용은 후술한다.

처리부(105)는, Ad/DASH 세그먼트 생성부(102)로부터 공급되는 Ad 세그먼트 및 DASH 세그먼트와, 스크립트 애플리케이션 생성부(103)로부터 공급되는 스크립트 애플리케이션과, MPD 생성부(104)로부터 공급되는 MPD 메타데이터에 대해서, 필요한 처리를 실시하고, 송신부(106)에 공급한다.

송신부(106)는, 처리부(105)로부터 공급되는 데이터를, 방송 서버(20) 또는 통신 서버(30)에 송신한다. 또한, 여기에서는, Ad 세그먼트 및 DASH 세그먼트, 스크립트 애플리케이션, 및 MPD 메타데이터의 데이터(파일) 중, 방송 경유로 배신되는 데이터가 방송 서버(20)에 송신되고, 통신 경유로 배신되는 데이터가 통신 서버(30)에 송신된다.

Ad/DASH 서버(10)는, 이상과 같이 구성된다.

(방송 서버의 구성)

도 23은, 도 1의 방송 서버(20)의 구성예를 나타내는 도면이다.

도 23에 있어서, 방송 서버(20)는, 수신부(201), 시그널링 생성부(202), 처리부(203), 및 송신부(204)로 구성된다.

수신부(201)는, Ad/DASH 서버(10)로부터 송신되어 오는, Ad 세그먼트 및 DASH 세그먼트, 스크립트 애플리케이션, 및 MPD 메타데이터를 수신하고, 처리부(203)에 공급한다. 단, 여기서는, Ad 세그먼트 및 DASH 세그먼트, 스크립트 애플리케이션, 및 MPD 메타데이터의 전부가, Ad/DASH 서버(10)로부터 제공되는 것으로는 한정되지 않고, 방송 경유로 배신되는 데이터(파일)만이 제공되고, 수신부(201)에 의해 수신된다.

또한, 수신부(201)는, 외부의 서버(도시생략) 등으로부터 NRT 콘텐츠의 데이터(파일)를 수신하고, 처리부(203)에 공급한다.

시그널링 생성부(202)는, 시그널링을 생성하고, 처리부(203)에 공급한다. 여기서, 시그널링에는, SLT 메타데이터 등의 LLS 시그널링과, USBD 메타데이터, S-TSID 메타데이터, 및 AST 메타데이터 등의 SLS 시그널링이 포함된다. 또한, 복수의 서비스에 의해 리소스(파일)를 공유시키는 경우에는, SLT 메타데이터, USBD 메타데이터, S-TSID 메타데이터, 또는 AST 메타데이터에 정의된 quotaDomain 속성에, 대상의 캐시 쿼터 도메인의 쿼터 도메인 식별자가 지정되게 된다.

처리부(203)는, 수신부(201)로부터 공급되는 Ad 세그먼트 및 DASH 세그먼트, 스크립트 애플리케이션, MPD 메타데이터, 및 NRT 콘텐츠와, 시그널링 생성부(202)로부터 공급되는 시그널링에 대해서, 필요한 처리를 실시하고, 송신부(204)에 공급한다. 여기에서는, 예를 들어 Ad 세그먼트 및 DASH 세그먼트, 스크립트 애플리케이션, NRT 콘텐츠, 및 SLS 시그널링(USBD 메타데이터나 MPD 메타데이터 등)을 포함하는 LCT 세션의 데이터를 페이로드에 저장한 IP/UDP 패킷과, LLS 시그널링(SLT 메타데이터 등)의 데이터를 페이로드에 저장한 IP/UDP 패킷을 생성하기 위한 처리 등이 행해진다.

송신부(204)는, 처리부(203)로부터 공급되는 데이터에 대응하는 방송파(디지털 방송 신호)를, 안테나(211)에 의해, 전송로(80)를 통해 송신(일제 동보 배신)한다.

방송 서버(20)는, 이상과 같이 구성된다.

(통신 서버의 구성)

도 24는, 도 1의 통신 서버(30)의 구성예를 나타내는 도면이다.

도 24에 있어서, 통신 서버(30)는, 수신부(301), 피리어드 파일 생성부(302), 처리부(303), 및 통신부(304)로 구성된다.

수신부(301)는, Ad/DASH 서버(10)로부터 송신되어 오는, Ad 세그먼트 및 DASH 세그먼트, 스크립트 애플리케이션, 및 MPD 메타데이터를 수신하고, 처리부(303)에 공급한다. 단, 여기서는, Ad 세그먼트 및 DASH 세그먼트, 스크립트 애플리케이션, 및 MPD 메타데이터의 전부가, Ad/DASH 서버(10)로부터 제공되는 것으로는 한정되지 않고, 통신 경유로 배신되는 데이터(파일)만이 제공되고, 수신부(301)에 의해 수신된다.

처리부(303)는, 통신부(304)에 의해 수신된 클라이언트 장치(40)로부터의 요구(XLink의 해결 요구)에 응답하여, 수신부(301)로부터 공급되는 데이터를 처리하고, 통신부(304)에 공급한다. 통신부(304)는, 클라이언트 장치(40)로부터의 요구에 응답하여, 처리부(303)로부터 공급되는 데이터(Ad 세그먼트 및 DASH 세그먼트, 스크립트 애플리케이션, 및 MPD 메타데이터 중 적어도 하나의 데이터)를, 인터넷(90)을 통해 당해 데이터의 요구원의 클라이언트 장치(40) 앞으로 송신한다.

처리부(303)는, 통신부(304)에 의해 수신된 클라이언트 장치(40)로부터의 요구에 응답하여, 피리어드 파일의 생성을, 피리어드 파일 생성부(302)에 요구한다. 피리어드 파일 생성부(302)는, 처리부(303)로부터의 요구에 응답하여, 클라이언트 장치(40)를 사용하고 있는 유저(의 특성)에 응답한 Period 요소를 포함하는 피리어드 파일을 생성하고, 처리부(303)에 공급한다.

처리부(303)는, 피리어드 파일 생성부(302)로부터 공급되는 피리어드 파일을 처리하고, 통신부(304)에 공급한다. 통신부(304)는, 처리부(303)로부터 공급되는 피리어드 파일을, 인터넷(90)을 통해 XLink의 해결 요구의 요구원의 클라이언트 장치(40) 앞으로 송신한다.

통신 서버(30)는, 이상과 같이 구성된다.

(클라이언트 장치의 구성)

도 25는, 도 1의 클라이언트 장치(40)의 구성예를 나타내는 도면이다.

도 25에 있어서, 클라이언트 장치(40)는, 제어부(401), 수신부(402), 방송 미들웨어(403), 로컬 캐시(404), 브라우저(405), 출력부(406), 및 통신부(407)로 구성된다.

제어부(401)는, 클라이언트 장치(40)의 각 부의 동작을 제어한다.

수신부(402)는, 안테나(411)에 의해, 방송 서버(20)로부터 전송로(80)를 통해 송신(일제 동보 배신)되어 오는 방송파(디지털 방송 신호)를 수신하여 처리하고, 그것에 의해 얻어지는 데이터를, 방송 미들웨어(403)에 공급한다. 또한, 수신부(402)는, 튜너 등으로 구성된다.

방송 미들웨어(403)는, 수신부(402)로부터 공급되는 데이터를 처리하고, 제어부(401) 또는 로컬 캐시(404)에 공급한다. 여기서, 처리 대상의 데이터 중, Ad 세그먼트 및 DASH 세그먼트, 스크립트 애플리케이션, 및 MPD 메타데이터는, 로컬 캐시(404)에 공급된다. 또한, 시그널링은, 제어부(401)에 공급된다.

제어부(401)는, 캐시 제어부(401A) 및 재생 제어부(401B)를 포함한다. 캐시 제어부(401A)는, 방송 미들웨어(403)로부터 공급되는 시그널링이나, 브라우저(405)로부터의 요구 등에 기초하여 로컬 캐시(404)를 제어한다. 또한, 재생 제어부(401B)는, 방송 미들웨어(403)로부터 공급되는 시그널링 등에 기초하여 브라우저(405)를 제어한다.

로컬 캐시(404)는, 예를 들어 온 메모리(On Memory)나 SSD(Solid State Drive) 등의 로컬 파일 시스템상에서 실현된다.

로컬 캐시(404)는, 캐시 제어부(401A)로부터의 제어에 따라서, 방송 미들웨어(403)로부터 공급되는 데이터(파일)를 캐시한다. 이 로컬 캐시(404)에는, Ad 세그먼트 및 DASH 세그먼트, 스크립트 애플리케이션, 및 MPD 메타데이터 등의 데이터가 캐시된다. 또한, 로컬 캐시(404)는, 통상 캐시(404A) 및 영속 캐시(404B)를 포함한다.

여기서, 통상 캐시(404A)는, 통상의 캐시로서, 거기에 캐시된 데이터는, 적당한 시간(그다지 길지 않은 시간)을 경과한 후에 소거된다. 한편, 영속 캐시(404B)는, 특별한 캐시로서, 거기에 캐시되는 데이터는, 우선적인 영속성을 갖고, 통상 캐시(404A)에 캐시되는 데이터보다도 오랜 시간 캐시되게 된다.

캐시 제어부(401A)는, 방송 미들웨어(403)로부터의 시그널링(에 포함되는 SLT 메타데이터, USBD 메타데이터, S-TSID 메타데이터, 또는 AST 메타데이터에 정의된 quotaDomain 속성)에, (캐시 쿼터 도메인의) 쿼터 도메인 식별자가 지정되어 있는 경우로서, 브라우저(405)(의 스크립트 실행부(405A))로부터, 대상의 Ad 세그먼트나 DASH 세그먼트 등의 영속 캐시(404B)로의 인입 요구가 있었을 때, 대상의 Ad 세그먼트나 DASH 세그먼트 등(의 파일)을, 통상 캐시(404A)로부터 영속 캐시(404B)에 인입한다.

이에 의해, 영속 캐시(404B)에 캐시되는 Ad 세그먼트나 DASH 세그먼트 등의 파일군은, 쿼터 도메인 식별자에 의해 결부되어 있으므로, 동일한 캐시 쿼터 도메인에 속하는 복수의 서비스에 있어서, Ad 세그먼트나 DASH 세그먼트 등의 파일을 공유하는 것이 가능해진다.

브라우저(405)는, HTML5나 JavaScript(등록상표) 등에 대응한 브라우저이다. 브라우저(405)는, 재생 제어부(401B)로부터의 제어에 따라서, 로컬 캐시(404)로부터 판독한 데이터(파일)를 처리한다. 브라우저(405)는, 스크립트 실행부(405A) 및 DASH 클라이언트(405B)를 포함한다.

스크립트 실행부(405A)는, JavaScript(등록상표) 등의 스크립트 언어로 기술된 스크립트를 실행할 수 있다. 예를 들어, 스크립트 실행부(405A)는, 로컬 캐시(404)(의 통상 캐시(404A) 또는 영속 캐시(404B))로부터 스크립트 애플리케이션을 판독하여, 실행할 수 있다.

또한, 스크립트 실행부(405A)는, 스크립트 애플리케이션에 기술된 CacheStorage API(Application Programming Interface)를 실행함으로써, 캐시 제어부(401A)에 의한 로컬 캐시(404)의 제어를 실행시킨다. 또한, CacheStorage API의 상세한 내용에 대해서는 후술한다. 또한, 스크립트 실행부(405A)는, DASH 클라이언트(405B)로부터의 XLink의 해결 요구에 응답하여, 유저 프리퍼런스 등에 따른 피리어드 파일을 생성하고, DASH 클라이언트(405B)에 응답한다.

DASH 클라이언트(405B)는, 로컬 캐시(404)(의 통상 캐시(404A))로부터 MPD 메타데이터(의 파일)를 판독하여 파싱(구문 해석)한다. DASH 클라이언트(405B)는, MPD 메타데이터의 해석 결과에 따라서, 로컬 캐시(404)(의 통상 캐시(404A) 또는 영속 캐시(404B))로부터, Ad 세그먼트 또는 DASH 세그먼트(의 파일)를 판독하여 재생한다.

DASH 클라이언트(405B)에 의해 재생된 Ad 세그먼트 또는 DASH 세그먼트의 데이터는, 출력부(406)에 공급된다. 출력부(406)는, 재생 제어부(401B)로부터의 제어에 따라서, DASH 클라이언트(405B)로부터 공급되는 데이터를 출력한다. 이에 의해, 방송 프로그램이나 광고 등의 콘텐츠가 재생되고, 그 영상이나 음성이 출력되게 된다.

통신부(407)는, 제어부(401)로부터의 제어에 따라서, 인터넷(90)을 통해 통신 서버(30)와 데이터의 교환을 행한다. 통신부(407)에 의해 수신되는 데이터 중, Ad 세그먼트 및 DASH 세그먼트, 스크립트 애플리케이션, 및 MPD 메타데이터는, 로컬 캐시(404)에 공급된다. 또한, 시그널링은 제어부(401)에 공급된다. 이들 통신 경유로 취득된 데이터에 대한 처리는, 전술한 방송 경유로 취득된 데이터와 마찬가지이기 때문에, 그 설명은 생략한다.

클라이언트 장치(40)는, 이상과 같이 구성된다.

<6. 각 장치에 의해 실행되는 처리의 흐름>

다음으로, 도 26 내지 도 28의 흐름도를 참조하여, 도 1의 전송 시스템(1)의 각 장치에 의해 실행되는 처리의 흐름에 대하여 설명한다.

(송신측의 처리의 흐름)

우선, 도 26의 흐름도를 참조하여, 송신측의 Ad/DASH 서버(10), 방송 서버(20), 및 통신 서버(30)에 의해 실행되는 처리의 흐름을 설명한다.

또한, 도 26에 있어서, 스텝 S101 내지 S106의 처리는, Ad/DASH 서버(10)에 의해 실행되고, 스텝 S201 내지 S205의 처리는, 방송 서버(20)에 의해 실행되며, 스텝 S301 내지 S302의 처리는, 통신 서버(30)에 의해 실행된다.

스텝 S101에 있어서, Ad/DASH 서버(10)의 Ad/DASH 세그먼트 생성부(102)는, Ad 세그먼트 및 DASH 세그먼트를 생성한다. 또한, 스텝 S102에 있어서, Ad/DASH 서버(10)의 송신부(106)는, 스텝 S101의 처리에 의해 생성된 Ad 세그먼트 및 DASH 세그먼트를, 방송 서버(20)에 송신한다.

여기서, Ad 세그먼트는, 광고의 콘텐츠를 처리하여 얻어지는 세그먼트 파일이다. 또한, DASH 세그먼트는, 방송 프로그램의 콘텐츠를 처리하여 얻어지는 세그먼트 파일이다. 여기서는, 설명의 편의상, Ad 세그먼트와 DASH 세그먼트가 동시에 생성되는 경우를 설명하지만, 이들 세그먼트는, 다른 타이밍에 생성되도록 해도 된다.

스텝 S201에 있어서, 방송 서버(20)의 시그널링 생성부(202)는, 시그널링을 생성한다. 스텝 S202에 있어서, 방송 서버(20)의 송신부(204)는, 스텝 S201의 처리에 의해 생성된 시그널링을, 전송로(80)를 통해 송신(일제 동보 배신)한다.

여기서, 시그널링으로서는, SLT 메타데이터 등의 LLS 시그널링과, USBD 메타데이터 등의 SLS 시그널링이 생성된다. 또한, 복수의 서비스 중에서, 리소스(파일)를 공유시키는 경우에는, SLT 메타데이터, USBD 메타데이터, S-TSID 메타데이터, 또는 AST 메타데이터에 정의된 quotaDomain 속성에, 대상의 캐시 쿼터 도메인의 쿼터 도메인 식별자가 지정되게 된다.

또한, 방송 서버(20)에 있어서는, 스텝 S202의 처리에 의해 송신된 Ad 세그먼트 및 DASH 세그먼트가, 수신부(201)에 의해 수신된다. 그리고, 스텝 S203에 있어서, 방송 서버(20)의 송신부(204)는, Ad/DASH 서버(10)에 의해 생성된 Ad 세그먼트 및 DASH 세그먼트를, 전송로(80)를 통해 송신(일제 동보 배신)한다.

스텝 S103에 있어서, Ad/DASH 서버(10)의 스크립트 애플리케이션 생성부(103)는, 스크립트 애플리케이션을 생성한다. 스텝 S104에 있어서, Ad/DASH 서버(10)의 송신부(106)는, 스텝 S103의 처리에 의해 생성된 스크립트 애플리케이션을, 방송 서버(20)에 송신한다.

방송 서버(20)에 있어서는, 스텝 S104의 처리에 의해 송신된 스크립트 애플리케이션이, 수신부(201)에 의해 수신된다. 그리고, 스텝 S204에 있어서, 방송 서버(20)의 송신부(204)는, Ad/DASH 서버(10)에 의해 생성된 스크립트 애플리케이션을, 전송로(80)를 통해 송신(일제 동보 배신)한다.

스텝 S105에 있어서, Ad/DASH 서버(10)의 MPD 생성부(104)는, MPD 메타데이터를 생성한다. 스텝 S106에 있어서, Ad/DASH 서버(10)의 송신부(106)는, 스텝 S105의 처리에 의해 생성된 MPD 메타데이터를, 방송 서버(20)에 송신한다.

여기서, MPD 메타데이터에 있어서는, 방송 프로그램과 광고의 Period 요소가 기술되지만, 예를 들어 광고의 Period 요소에는, xlink:href 속성으로서, "urn:atsc:ad-insertion:abc:1234"인 URL이 기술되도록 한다. 단, 이 URL에 있어서, "urn:atsc:ad-insertion"은, 광고 삽입 제어의 해결을, 로컬(클라이언트 장치(40))로 실행되는 스크립트(스크립트 애플리케이션)에 의뢰해야 함을 나타내도록 한다.

즉, MPEG-DASH의 규정에서는, 통상의 "http:"로부터 개시되는 문자열로 이루어지는 URL을, MPD 메타데이터의 Period 요소의 xlink:href 속성에 기술함으로써, 클라이언트 장치(40)는, 이 "http:…"로 지정되는, 인터넷(90)상의 통신 서버(30)에 문의하게 된다. 그리고, 클라이언트 장치(40)는, 통신 서버(30)로부터의 응답으로서, 피리어드 파일을 수신하고, 당해 피리어드 파일에 포함되는 Period 요소의 내용에 기초하여, 광고의 콘텐츠(Ad 세그먼트)를 재생하게 된다.

그 한편, 이 예에서는, "http:"로부터 개시되는 문자열로 이루어지는 URL이 아니라, "urn:atsc:ad-insertion"로부터 개시되는 문자열로 이루어지는 URN(Uniform Resource Name)을, MPD 메타데이터의 Period 요소의 xlink:href 속성에 기술하도록 한다. 이에 의해, 클라이언트 장치(40)에서는, MPD 메타데이터를 파싱(구문 해석)했을 때, "urn:atsc:ad-insertion"으로 개시되는 문자열이 지정된 xlink:href 속성을 갖는 Period 요소가 검출된 경우에는, HTTP 리퀘스트를 발행하는 것이 아니라, 동시에 실행되고 있는 스크립트 애플리케이션에 대해서, XLink의 해결(Period 요소의 해결)을 재촉하는 이벤트를 발행하게 된다.

또한, 이 예에서는, MPD 메타데이터에 있어서, Period 요소의 xlink:href 속성에, "urn:atsc:ad-insertion"로부터 개시되는 문자열로 이루어지는 URN이 지정 되는 경우를 주로 설명하지만, 전술한 바와 같이, "http://adservice.com/adp-1?user=$groupID$" 등의 URL을 지정하고, groupID에 의해 특정한 유저가 지정되도록 해도 된다.

방송 서버(20)에 있어서는, 스텝 S106의 처리에 의해 송신된 MPD 메타데이터가, 수신부(201)에 의해 수신된다. 그리고, 스텝 S205에 있어서, 방송 서버(20)의 송신부(204)는, Ad/DASH 서버(10)에 의해 생성된 MPD 메타데이터를, 전송로(80)를 통해 송신(일제 동보 배신)한다.

또한, 설명의 편의상, 스텝 S202 내지 S205에 있어서는, 시그널링, Ad 세그먼트 및 DASH 세그먼트, 스크립트 애플리케이션, 및 MPD 메타데이터가, 서로 다른 타이밍에 송신되는 것으로서 설명하였지만, 이들 데이터는, 방송 스트림에 포함되고, 송신되게 된다.

통신 서버(30)에 있어서는, 인터넷(90)을 통해 클라이언트 장치(40)로부터 송신되어 오는, XLink의 해결 요구가 통신부(304)에 의해 수신된다. 그리고, 스텝 S301에 있어서, 통신 서버(30)의 피리어드 파일 생성부(302)는, 피리어드 파일을 생성한다. 스텝 S302에 있어서, 통신 서버(30)의 통신부(304)는, 스텝 S301의 처리에 의해 생성된 피리어드 파일을, 인터넷(90)을 통해 XLink의 해결 요구의 송신원의 클라이언트 장치(40) 앞으로 송신한다.

또한, 이와 같이, 클라이언트 장치(40)로부터 통신 서버(30)에 대해서, XLink의 해결 요구가 송신되는 것은, "http:"로부터 개시되는 문자열로 이루어지는 URL이, MPD 메타데이터의 Period 요소의 xlink:href 속성에 기술된 경우이다.

이상, 송신측의 처리의 흐름에 대하여 설명하였다.

(수신측의 처리의 흐름)

다음으로, 도 27 및 도 28의 흐름도를 참조하여, 수신측의 클라이언트 장치(40)에 의해 실행되는 처리의 흐름을 설명한다.

또한, 도 27 및 도 28에 있어서, 스텝 S401 내지 S408의 처리는, 방송 미들웨어(403)에 의해 실행되고, 스텝 S421 내지 S423의 처리, 및 스텝 S441 내지 S443의 처리는, 로컬 캐시(404)(통상 캐시(404A), 영속 캐시(404B))를 제어하는 캐시 제어부(401A)에 의해 실행된다. 또한, 스텝 S461 내지 S466의 처리는, 브라우저(405)의 스크립트 실행부(405A)에 의해 실행되고, 스텝 S481 내지 S490의 처리는, 브라우저(405)의 DASH 클라이언트(405B)에 의해 실행된다.

스텝 S401에 있어서, 방송 미들웨어(403)는, 수신부(402)를 통해, 방송 서버(20)로부터 전송로(80)를 통해 송신되어 오는 시그널링을 수신한다. 스텝 S402에 있어서, 방송 미들웨어(403)는, 스텝 S401의 처리에 의해 수신된 시그널링을 처리한다.

여기서, 시그널링으로서는, SLT 메타데이터 등의 LLS 시그널링과, USBD 메타데이터 등의 SLS 시그널링이 처리된다. 또한, 복수의 서비스 중에서, 리소스(파일)를 공유시키는 경우에는, SLT 메타데이터, USBD 메타데이터, S-TSID 메타데이터, 또는 AST 메타데이터에 정의된 quotaDomain 속성에, 대상의 캐시 쿼터 도메인의 쿼터 도메인 식별자가 지정되어 있으므로, 이 캐시 쿼터 도메인에 속하는 서비스가 인식되게 된다.

스텝 S403에 있어서, 방송 미들웨어(403)는, 수신부(402)를 통해, 방송 서버(20)로부터 전송로(80)를 통해 송신되어 오는 Ad 세그먼트 및 DASH 세그먼트를 수신한다. 스텝 S404에 있어서, 방송 미들웨어(403)는, 스텝 S403의 처리에 의해 수신된 Ad 세그먼트 및 DASH 세그먼트를, 로컬 캐시(404)에 전송한다.

스텝 S421에 있어서, 캐시 제어부(401A)는, 스텝 S404의 처리에 의해 전송되어 오는 Ad 세그먼트 및 DASH 세그먼트(의 파일)를, 로컬 캐시(404)의 통상 캐시(404A)에 캐시한다.

이 경우, Ad 세그먼트 및 DASH 세그먼트(의 파일)는, 통상 캐시(404A)에 캐시되어 있으므로, 이대로의 상태가 계속되면, 적당한 시간(그다지 길지 않은 시간)의 경과 후, 소거되게 된다. 또한, 여기서는, 설명의 편의상, Ad 세그먼트와 DASH 세그먼트(의 파일)각 동시에 저장되는 경우를 설명하고 있지만, 이들 세그먼트(의 파일)는, 다른 타이밍에 저장되도록 해도 된다.

스텝 S405에 있어서, 방송 미들웨어(403)는, 수신부(402)를 통해, 방송 서버(20)로부터 전송로(80)를 통해 송신되어 오는 스크립트 애플리케이션을 수신한다. 스텝 S406에 있어서, 방송 미들웨어(403)는, 스텝 S405의 처리에 의해 수신된 스크립트 애플리케이션을, 로컬 캐시(404)에 전송한다.

스텝 S422에 있어서, 캐시 제어부(401A)는, 스텝 S406의 처리에 의해 전송되어 오는 스크립트 애플리케이션을, 로컬 캐시(404)의 통상 캐시(404A)에 캐시한다. 이 경우, 스크립트 애플리케이션은, 통상 캐시(404A)에 캐시되어 있으므로, 이대로의 상태가 계속되면, 적당한 시간(그다지 길지 않은 시간)의 경과 후, 소거되게 된다.

스텝 S461에 있어서, 스크립트 실행부(405A)는, 스텝 S422의 처리에 의해 통상 캐시(404A)에 캐시된 스크립트 애플리케이션을, 로컬 캐시(404)로부터 취득하고, 당해 스크립트 애플리케이션을 실행한다.

스텝 S462에 있어서, 스크립트 실행부(405A)는, 스크립트 애플리케이션의 실행(스텝 S461의 처리)에 응답하여, 캐시 제어부(401A)에 대해서, Ad 세그먼트의 영속 캐시(404B)로의 인입을 요구한다.

여기서, Ad 세그먼트의 영속 캐시(404B)로의 인입 지시는, 예를 들어 스크립트 애플리케이션에 기술되는, 하기 CacheStorage API를 실행함으로써 행해진다.

Interface Cache {

Promise <void> fetchPeriod(xmlElement);

}

단, 상기 API에 있어서, fetchPeriod 메소드는, 영속 캐시(404B)로의 인입 지시에 사용된다. 또한, fetchPeriod 메소드의 인수인 xmlElement에 의해 지정되는 Period 요소 중에 기술되는 세그먼트 URL에 의해 지정되는 세그먼트 파일(Ad 세그먼트의 파일)이, 영속 캐시(404B)에 저장되는 대상의 파일로 된다.

또한, 스크립트 애플리케이션에는, 하기의 CacheStorage API가 기술되도록 해도 된다.

Interface Cache {

Promise <void> fetchFile(url);

}

단, 상기 API에 있어서, fetchFile 메소드는, 영속 캐시(404B)로의 인입 지시에 사용된다. 또한, fetchFile 메소드의 인수인 url에 의해 지정되는 세그먼트 파일(Ad 세그먼트의 파일)이, 영속 캐시(404B)에 저장되는 대상의 파일로 된다.

스텝 S441에 있어서, 캐시 제어부(401A)는, 스텝 S462의 처리 인입 요구에 응답하여, 삽입 후보의 Ad 세그먼트(의 파일)를, 로컬 캐시(404)의 통상 캐시(404A)로부터, 영속 캐시(404B)에 인입한다. 이에 의해, 로컬 캐시(404)의 영속 캐시(404B)에는, 통상 캐시(404A)로부터 인입된 Ad 세그먼트(의 파일)가 캐시된다(S442).

즉, 전송로(80)를 통해 방송 경유로 배신되는 파일군은, 통상 방송 미들웨어(403)에 의해, ROUTE 프로토콜이 종단된 후에, 로컬 캐시(404)의 통상 캐시(404A)(HTTP 프록시 캐시(파일 시스템))에 전개되어, 적당한 시간(그다지 길지 않은 시간)이 경과 후, 소거된다. 여기에서는, 예를 들어 ROUTE의 엔티티 모드의 파일 전송 시에 부가되는 HTTP 헤더에 기술되는 캐시 유효 기한 등에 의해 정해지는 시간이 경과 후, 파일이 소거된다.

한편, 로컬 캐시(404)의 영속 캐시(404B)는, HTTP 프록시 캐시 중, 특별한 영역으로서 취급되는 것이다. 즉, 이 영속 캐시(404B)에 전개되는 파일군은, 통상 캐시(404A)에 캐시되는 다른 파일군보다도, 우선적인 영속성을 갖고, 또한, 상기 「적당한 시간」이 경과해도 소거되지 않아, 로컬 캐시(404)에 미리 할당된 쿼터(quota: 할당량)에 도달할 때까지, 파일이 캐시되게 된다.

그리고, 영속 캐시(404B)에 캐시되는 파일군이 속하는 서비스는, SLT 메타데이터, USBD 메타데이터, S-TSID 메타데이터, 또는 AST 메타데이터에 정의된 quotaDomain 속성으로 지정된 쿼터 도메인 식별자에 의해 결부되어 있으므로, 동일한 캐시 쿼터 도메인에 속하는 복수의 서비스에 있어서, 특정한 파일(이 예에서는, Ad 세그먼트의 파일)을 공유하는 것이 가능해진다.

스텝 S407에 있어서, 방송 미들웨어(403)는, 수신부(402)를 통하여, 방송 서버(20)로부터 전송로(80)를 통해 송신되어 오는 MPD 메타데이터를 수신한다. 스텝 S408에 있어서, 방송 미들웨어(403)는, 스텝 S407의 처리에 의해 수신된 MPD 메타데이터를, 로컬 캐시(404)에 전송한다.

스텝 S423에 있어서, 캐시 제어부(401A)는, 스텝 S408의 처리에 의해 전송되어 오는 MPD 메타데이터를, 로컬 캐시(404)의 통상 캐시(404A)에 캐시한다. 이 경우, MPD 메타데이터는, 통상 캐시(404A)에 캐시되어 있으므로, 적당한 시간(그다지 길지 않은 시간)의 경과 후, 소거되게 된다.

스텝 S481에 있어서, DASH 클라이언트(405B)는, 스텝 S423의 처리에 의해 통상 캐시(404A)에 캐시된 MPD 메타데이터를, 로컬 캐시(404)로부터 취득하고, 당해 MPD 메타데이터를 파싱(구문 해석)한다.

스텝 S482에 있어서, DASH 클라이언트(405B)는, 스텝 S402나 S481의 처리 결과(SLT, USBD, S-TSID, MPD 등의 메타데이터의 처리 결과)에 따라서 취득되고, 통상 캐시(404A)에 캐시된 DASH 세그먼트를, 로컬 캐시(404)로부터 취득한다. 스텝 S483에 있어서, DASH 클라이언트(405B)는, 재생 제어부(401B)로부터의 제어에 따라서, 스텝 S482의 처리에 의해 취득된 DASH 세그먼트를 재생한다. 이에 의해, 클라이언트 장치(40)에서는, 방송 프로그램의 콘텐츠가 재생되게 된다.

스텝 S484에 있어서, DASH 클라이언트(405B)는, 광고를 삽입할지 여부를 판정한다. 스텝 S484에 있어서, 광고를 삽입하지 않는다고 판정된 경우, 처리는, 스텝 S482로 되돌아가서, 스텝 S482 내지 S484의 처리가 반복된다. 이 경우, 방송 프로그램의 콘텐츠 재생이 계속되게 된다. 한편, 스텝 S484에 있어서, 광고를 삽입한다고 판정된 경우, 처리는, 스텝 S485로 진행된다.

스텝 S485에 있어서, DASH 클라이언트(405B)는, 스텝 S481의 처리 결과에 응답하여, MPD 메타데이터에 포함되는 XLink의 해결을, 스크립트 실행부(405A)에 요구한다.

단, 여기서는, 스텝 S481의 처리에 의해, MPD 메타데이터의 Period 요소의 xlink:href 속성으로 지정되는 URL로부터, "urn:atsc:ad-insertion"으로부터 개시되는 문자열로 이루어지는 URN이 검출된 경우에, 스크립트 실행부(405A)에 의해 동시에 실행되고 있는 스크립트 애플리케이션에 대해서, XLink의 해결(Period 요소의 해결)을 재촉하는 이벤트를 발행하게 된다.

스텝 S463에 있어서, 스크립트 실행부(405A)는, 스텝 S485의 처리 XLink 해결 요구에 응답하여, 실행 중인 스크립트 애플리케이션의 스크립트 내의 로직에 의해 유저 프리퍼런스를 취득한다. 그리고, 스텝 S464에 있어서, 스크립트 실행부(405A)는, 스텝 S463의 처리에 의해 취득된 유저 프리퍼런스에 기초하여, 피리어드 파일을 생성한다.

여기서, 스크립트 실행부(405A)는, DASH 클라이언트(405B)로부터의 이벤트에 의해 통지되는 URL(예를 들어, "urn:atsc:ad-insertion:abc:1234"인 URL)에 기초하여, MPD 메타데이터에 삽입될 Period 요소를 포함하는 피리어드 파일을 생성한다. 또한, 유저 프리퍼런스로서는, 예를 들어 PDI(Preference Demographic and Interest)를 이용하도록 해도 된다. 이 PDI는, 특정한 서버로부터 제공되는 질문에 대한 유저의 회답을 나타내는 정보를 생성함으로써, 유저의 기호에 매치한 콘텐츠만이 재생(축적)되도록 하는 구조이다.

스텝 S465에 있어서, 스크립트 실행부(405A)는, 스텝 S464의 처리에 의해 생성된 피리어드 파일을, DASH 클라이언트(405B)에 응답한다.

또한, MPD 메타데이터의 Period 요소의 xlink:href 속성에, "http:"로부터 개시되는 문자열로 이루어지는 URL(예를 들어, "http://adservice.com/adp-1?user=$groupID$" 등의 URL)이 기술되어 있는 경우에는, 도면 중의 점선(「5」의 점선)으로 나타낸 바와 같이, XLink의 해결 요구가, 인터넷(90)을 통해 통신 서버(30)에 송신된다. 그리고, 도면 중의 점선(「6」의 점선)으로 나타낸 바와 같이, 통신 서버(30)로부터 송신되어 오는, XLink의 해결 요구에 응답한 피리어드 파일이 취득되게 된다.

스텝 S486에 있어서, DASH 클라이언트(405B)는, 스텝 S465의 처리에 의해 응답되는 피리어드 파일을 취득하고, 당해 피리어드 파일을 파싱(구문 해석)한다.

스텝 S487에 있어서, DASH 클라이언트(405B)는, 스텝 S486의 처리 결과에 따라서, 로컬 캐시(404)의 영속 캐시(404B)에 캐시된 Ad 세그먼트를 취득한다. 여기서는, 스텝 S486의 처리에 의해 Period 요소를 파싱함으로써, 대상의 Ad 세그먼트의 URL이 얻어지므로, 당해 URL에 따라서, 영속 캐시(404B)의 Ad 세그먼트가 취득된다. 그리고, 이 Ad 세그먼트의 파일은, 동일한 캐시 쿼터 도메인에 속하는 복수의 서비스 중에서 공유되고 있는 파일이기 때문에, Ad 세그먼트의 파일을 재이용할 수 있다.

스텝 S488에 있어서, DASH 클라이언트(405B)는, 재생 제어부(401B)로부터의 제어에 따라서, 스텝 S487의 처리에 의해 취득된 Ad 세그먼트를 재생한다. 이에 의해, 클라이언트 장치(40)에서는, 재생되는 콘텐츠가, 방송 프로그램으로부터 광고로 전환되게 된다(광고가 삽입됨).

스텝 S489에 있어서, DASH 클라이언트(405B)는, Ad 세그먼트의 재생(스텝 S488의 처리)이 완료되었는지 여부를 판정한다. 스텝 S489에 있어서, Ad 세그먼트의 재생이 완료되지 않았다고 판정된 경우, 처리는, 스텝 S488로 되돌아가서, Ad 세그먼트의 재생이 계속된다.

한편, 스텝 S489에 있어서, Ad 세그먼트의 재생이 완료되었다고 판정된 경우, 처리는 스텝 S490으로 진행된다. 스텝 S490에 있어서, DASH 클라이언트(405B)는, Ad 세그먼트의 재생 완료를, 스크립트 실행부(405A)에 통지한다.

스텝 S466에 있어서, 스크립트 실행부(405A)는, 스텝 S490의 Ad 세그먼트 재생 완료 통지에 따라서, 실행 중인 스크립트 애플리케이션에 의해, 캐시 제어부(401A)에 대해서, 재생 완료의 Ad 세그먼트의 영속 캐시(404B)로부터의 소거를 요구한다.

여기서, Ad 세그먼트의 영속 캐시(404B)로부터의 소거 지시는, 예를 들어 스크립트 애플리케이션에 기술되는, 하기의 CacheStorage API를 실행함으로써 행해진다.

Interface Cache {

Promise <void> deleteFile(url);

}

단, 상기 API에 있어서, deleteFile 메소드는, 영속 캐시(404B)로부터의 소거 지시에 사용된다. 또한, deleteFile 메소드의 인수인 url에 의해 지정되는 세그먼트 파일(Ad 세그먼트의 파일)이, 영속 캐시(404B)로부터 삭제되는 대상의 파일로 된다.

스텝 S443에 있어서, 캐시 제어부(401A)는, 스텝 S466의 처리 소거 요구에 응답하여, 재생 완료의 Ad 세그먼트(의 파일)를, 로컬 캐시(404)의 영속 캐시(404B)로부터 소거한다. 또한, 클라이언트 장치(40)에서는, Ad 세그먼트의 재생이 종료하면, 재생되는 콘텐츠가, 광고부터 방송 프로그램으로 전환되게 된다.

이상, 수신측의 처리의 흐름에 대하여 설명하였다.

<7. 변형예>

전술한 설명으로서는, 디지털 방송의 규격으로서, 미국 등에서 채용되고 있는 방식인 ATSC(특히, ATSC 3.0)를 설명하였지만, 본 기술은, 일본 등이 채용하는 방식인 ISDB(Integrated Services Digital Broadcasting)나, 유럽의 각국 등이 채용하는 방식인 DVB(Digital Video Broadcasting) 등에 적용하도록 해도 된다. 또한, 전술한 설명에서는, IP 전송 방식이 채용되는 ATSC 3.0을 예로 하여 설명하였지만, IP 전송 방식으로 한정되지 않으며, 예를 들어 MPEG2-TS(Transport Stream) 방식 등의 다른 방식에 적용하도록 해도 된다.

또한, 디지털 방송으로서는, 지상파 방송 외에, 방송위성(BS: Broadcasting Satellite)이나 통신위성(CS: Communications Satellite) 등을 이용한 위성 방송이나, 케이블 텔레비전(CATV) 등의 유선 방송 등에 적용할 수 있다.

또한, 전술한 도메인이나 시그널링 등의 명칭은, 일례로서, 다른 명칭이 사용되는 경우가 있다. 단, 이들 명칭의 차이는, 형식적인 차이로서, 대상의 도메인이나 시그널링 등의 실질적인 내용이 상이한 것은 아니다. 예를 들어, 캐시 쿼터 도메인(Cache Quota Domain)은, 캐시 쿼터 그룹(Cache Quota Group) 등의 마찬가지의 뉘앙스를 갖는 다른 명칭으로 불리는 경우가 있다. 또한, 예를 들어AST(Application Signaling Table)는, AIT(Application Information Table) 등이라 칭해지고, NRT(Non Real Time)는, LCC(Locally Cached Content) 등이라 칭해지는 경우가 있다. 또한, 시그널링이 XML 등의 마크업 언어에 의해 기술되는 경우에 있어서, 그들 요소나 속성의 명칭은 일례로서, 다른 명칭이 채용되도록 해도 된다. 단, 이들 명칭의 차이는, 형식적인 차이이며, 그들 요소나 속성의 실질적인 내용이 상이한 것은 아니다.

또한, 전술한 설명에서는, LLS 시그널링으로서, SLT 메타데이터를 설명하였지만, LLS 시그널링에는, EAT(Emergency Alerting Table)나 RRT(Region Rating Table) 등의 메타데이터가 포함되도록 해도 된다. EAT 메타데이터는, 긴급하게 고지 할 필요가 있는 긴급 정보에 관한 정보를 포함한다. RRT 메타데이터는, 레이팅에 관한 정보를 포함한다.

또한, 애플리케이션은, HTML5 등의 마크업 언어나 JavaScript(등록상표) 등의 스크립트 언어로 개발된 애플리케이션에 한정되지 않으며, 예를 들어 Java(등록상표) 등의 programming language로 개발된 애플리케이션이어도 된다. 또한, 전술한 콘텐츠에는, 동화상이나 광고 외에, 예를 들어 전자서적이나 게임, 음악 등, 모든 콘텐츠를 포함할 수 있다.

또한, 본 기술은, 전송로로서, 방송망 이외의 전송로, 즉, 예를 들어 인터넷이나 전화망 등의 통신 회선(통신망) 등을 이용하는 것을 상정하여 규정되어 있는 소정의 규격(디지털 방송의 규격 이외의 규격) 등에도 적용할 수 있다.

<8. 컴퓨터의 구성>

전술한 일련의 처리는, 하드웨어에 의해 실행할 수도 있고, 소프트웨어에 의해 실행할 수도 있다. 일련의 처리를 소프트웨어에 의해 실행하는 경우에는, 그 소프트웨어를 구성하는 프로그램이, 컴퓨터에 인스톨된다. 도 29는, 전술한 일련의 처리를 프로그램에 의해 실행하는 컴퓨터의 하드웨어의 구성예를 나타내는 도면이다.

컴퓨터(1000)에 있어서, CPU(Central Processing Unit)(1001), ROM(Read Only Memory)(1002), RAM(Random Access Memory)(1003)은, 버스(1004)에 의해 서로 접속되어 있다. 버스(1004)에는, 또한, 입출력 인터페이스(1005)가 접속되어 있다. 입출력 인터페이스(1005)에는, 입력부(1006), 출력부(1007), 기록부(1008), 통신부(1009), 및 드라이브(1010)가 접속되어 있다.

입력부(1006)는, 키보드, 마우스, 마이크로폰 등을 포함한다. 출력부(1007)는, 디스플레이, 스피커 등을 포함한다. 기록부(1008)는, 하드디스크나 불휘발성의 메모리 등을 포함한다. 통신부(1009)는, 네트워크 인터페이스 등을 포함한다. 드라이브(1010)는, 자기디스크, 광디스크, 광자기디스크, 또는 반도체 메모리 등의 리무버블 미디어(1011)를 구동한다.

이상과 같이 구성되는 컴퓨터(1000)에서는, CPU(1001)가, ROM(1002)이나 기록부(1008)에 기록되어 있는 프로그램을, 입출력 인터페이스(1005) 및 버스(1004)를 통해 RAM(1003)에 로드하여 실행함으로써, 전술한 일련의 처리가 행해진다.

컴퓨터(1000)(CPU(1001))가 실행하는 프로그램은, 예를 들어 패키지 미디어 등으로서의 리무버블 미디어(1011)에 기록해서 제공할 수 있다. 또한, 프로그램은, 로컬 에어리어 네트워크, 인터넷, 디지털 위성 방송 등의 유선 또는 무선의 전송 매체를 통해 제공할 수 있다.

컴퓨터(1000)에서는, 프로그램은, 리무버블 미디어(1011)를 드라이브(1010)에 장착함으로써, 입출력 인터페이스(1005)를 통해 기록부(1008)에 인스톨할 수 있다. 또한, 프로그램은, 유선 또는 무선의 전송 매체를 통해 통신부(1009)에 의해 수신하고, 기록부(1008)에 인스톨할 수 있다. 그 밖에, 프로그램은, ROM(1002)이나 기록부(1008)에, 미리 인스톨해 둘 수 있다.

여기서, 본 명세서에 있어서, 컴퓨터가 프로그램에 따라서 행하는 처리는, 반드시 흐름도로서 기재된 순서를 따라서 시계열로 행해질 필요는 없다. 즉, 컴퓨터가 프로그램에 따라서 행하는 처리는, 병렬적 혹은 개별로 실행되는 처리(예를 들어, 병렬 처리 혹은 오브젝트에 의한 처리)도 포함한다. 또한, 프로그램은, 하나의 컴퓨터(프로세서)에 의해 처리되는 것이어도 되고, 복수의 컴퓨터에 의해 분산 처리되는 것이어도 된다.

또한, 본 기술의 실시 형태는, 전술한 실시 형태로 한정되는 것이 아니라, 본 기술의 요지를 일탈하지 않는 범위에 있어서 다양한 변경이 가능하다.

또한, 본 기술은, 이하와 같은 구성을 취할 수 있다.

(1)

콘텐츠를 수신하는 수신부와,

상기 콘텐츠와 함께 전송되는 제어 정보로서, 상기 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되는 리소스인지 여부를 나타내는 리소스 공유 정보를 포함하는 상기 제어 정보에 기초하여, 상기 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되도록, 상기 리소스의 기억 장치로의 기억을 제어하는 제어부

를 구비하는 수신 장치.

(2)

상기 제어부는, 상기 제어 정보에 포함되는 상기 리소스 공유 정보가, 복수의 서비스 중에서 공유되는 리소스임을 나타내고 있는 경우, 공유되는 리소스인 공유 리소스를, 다른 리소스와 구별하여 기억시키는, 상기 (1)에 기재된 수신 장치.

(3)

상기 콘텐츠 및 상기 제어 정보는, 방송파에 의해 전송되고,

상기 서비스는, 디지털 방송의 서비스이며,

상기 제어 정보는, 상기 서비스를 제공하기 위한 시그널링인, 상기 (1) 또는 (2)에 기재된 수신 장치.

(4)

상기 시그널링은, 복수의 서비스의 속성을 지정 가능한 제1 시그널링이며,

상기 제1 시그널링은, 서비스 단위로 지정된 상기 리소스 공유 정보를 포함하는, 상기 (3)에 기재된 수신 장치.

(5)

상기 시그널링은, 서비스마다의 속성을 지정 가능한 제2 시그널링이며,

상기 제2 시그널링은, 대상의 서비스 내의 소정의 단위로 지정된 상기 리소스 공유 정보를 포함하는, 상기 (3)에 기재된 수신 장치.

(6)

상기 리소스 공유 정보는, 서비스 단위, 세션 단위, 또는 애플리케이션 단위로 지정되는, 상기 (5)에 기재된 수신 장치.

(7)

상기 콘텐츠의 리소스는, 소정의 형식의 파일이며,

상기 제어부는, 상기 콘텐츠와 함께 전송되는 애플리케이션의 동작에 대응하여, 공유 리소스의 파일을, 다른 리소스의 파일이 기억되는 제1 기억 영역과는 상이한 제2 기억 영역에 기억시키는, 상기 (2) 내지 (6) 중 어느 하나에 기재된 수신 장치.

(8)

상기 제어부는, 상기 애플리케이션의 동작에 대응하여, 상기 제2 기억 영역에 기억된 공유 리소스의 파일을 소거하는, 상기 (7)에 기재된 수신 장치.

(9)

상기 방송파는, IP(Internet Protocol) 전송 방식에 대응한 방송파이며,

상기 콘텐츠의 리소스의 파일 데이터는, UDP(User Datagram Protocol) 패킷을 포함하는 IP 패킷에 저장되어 전송되는, 상기 (3) 내지 (8) 중 어느 하나에 기재된 수신 장치.

(10)

상기 콘텐츠는, 광고의 콘텐츠를 포함하고,

상기 리소스 공유 정보는, 상기 광고의 콘텐츠의 리소스를 공유하는 복수의 서비스가 속하는 그룹을 식별하기 위한 식별 정보인, 상기 (1) 내지 (9) 중 어느 하나에 기재된 수신 장치.

(11)

수신 장치의 데이터 처리 방법에 있어서,

상기 수신 장치가,

콘텐츠를 수신하고,

상기 콘텐츠와 함께 전송되는 제어 정보로서, 상기 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되는 리소스인지 여부를 나타내는 리소스 공유 정보를 포함하는 상기 제어 정보에 기초하여, 상기 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되도록, 상기 리소스의 기억 장치로의 기억을 제어하는

스텝을 포함하는 데이터 처리 방법.

(12)

콘텐츠의 리소스가, 복수의 서비스 중에서 공유되는 리소스인지 여부를 나타내는 리소스 공유 정보를 포함하는 제어 정보를 생성하는 생성부와,

상기 콘텐츠와 함께, 상기 제어 정보를 송신하는 송신부

를 구비하는 송신 장치.

(13)

상기 콘텐츠 및 상기 제어 정보는, 방송파에 의해 전송되고,

상기 서비스는, 디지털 방송의 서비스이며,

상기 제어 정보는, 상기 서비스를 제공하기 위한 시그널링인, 상기 (12)에 기재된 송신 장치.

(14)

상기 제1 시그널링은, 서비스 단위로 지정된 상기 리소스 공유 정보를 포함하는, 상기 (13)에 기재된 송신 장치.

(15)

상기 제2 시그널링은, 대상의 서비스 내의 소정의 단위로 지정된 상기 리소스 공유 정보를 포함하는, 상기 (13)에 기재된 송신 장치.

(16)

상기 리소스 공유 정보는, 서비스 단위, 세션 단위, 또는 애플리케이션 단위로 지정되는, 상기 (15)에 기재된 송신 장치.

(17)

상기 콘텐츠의 리소스는, 소정의 형식의 파일인, 상기 (12) 내지 (16) 중 어느 하나에 기재된 송신 장치.

(18)

상기 방송파는, IP 전송 방식에 대응한 방송파이며,

상기 콘텐츠의 리소스의 파일 데이터는, UDP 패킷을 포함하는 IP 패킷에 저장되어 전송되는, 상기 (13) 내지 (17) 중 어느 하나에 기재된 송신 장치.

(19)

상기 콘텐츠는, 광고의 콘텐츠를 포함하고,

상기 리소스 공유 정보는, 상기 광고의 콘텐츠의 리소스를 공유하는 복수의 서비스가 속하는 그룹을 식별하기 위한 식별 정보인, 상기 (12) 내지 (18) 중 어느 하나에 기재된 송신 장치.

(20)

송신 장치의 데이터 처리 방법에 있어서,

상기 송신 장치가,

콘텐츠의 리소스가, 복수의 서비스 중에서 공유되는 리소스인지 여부를 나타내는 리소스 공유 정보를 포함하는 제어 정보를 생성하고,

상기 콘텐츠와 함께, 상기 제어 정보를 송신하는

스텝을 포함하는 데이터 처리 방법.

1: 전송 시스템
10: Ad/DASH 서버
20: 방송 서버
30: 통신 서버
40: 클라이언트 장치
80: 전송로
90: 인터넷
101: 수신부
102: Ad/DASH 세그먼트 생성부
103: 스크립트 애플리케이션 생성부
104: MPD 생성부
105: 처리부
106: 송신부
201: 수신부
202: 시그널링 생성부
203: 처리부
204: 송신부
301: 수신부
302: 피리어드 파일 생성부
303: 처리부
304: 통신부
401: 제어부
401A: 캐시 제어부
401B: 재생 제어부
402: 수신부
403: 방송 미들웨어
404: 로컬 캐시
404A: 통상 캐시
404B: 영속 캐시
405: 브라우저
405A: 스크립트 실행부
405B: DASH 클라이언트
406: 출력부
407: 통신부
1000: 컴퓨터
1001: CPU

Claims

수신 장치로서,
콘텐츠를 수신하는 수신부와,
상기 콘텐츠와 함께 전송되는 제어 정보로서, 상기 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되는 리소스인지 여부를 나타내는 리소스 공유 정보를 포함하는 상기 제어 정보에 기초하여, 상기 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되도록, 상기 리소스의 기억 장치로의 기억을 제어하는 제어부
를 구비하고,
상기 리소스 공유 정보는, 광고의 콘텐츠의 리소스를 공유하는 복수의 서비스가 속하는 그룹을 식별하는 식별 정보를 포함하는, 수신 장치.
제1항에 있어서,
상기 제어부는, 상기 제어 정보에 포함되는 상기 리소스 공유 정보가, 복수의 서비스 중에서 공유되는 리소스임을 나타내고 있는 경우, 공유되는 리소스인 공유 리소스를, 다른 리소스와 구별하여 기억시키는, 수신 장치.
제2항에 있어서,
상기 콘텐츠 및 상기 제어 정보는, 방송파에 의해 전송되고,
상기 서비스는, 디지털 방송의 서비스이며,
상기 제어 정보는, 상기 서비스를 제공하기 위한 시그널링인, 수신 장치.
제3항에 있어서,
상기 시그널링은, 복수의 서비스의 속성을 지정 가능한 제1 시그널링이며,
상기 제1 시그널링은, 서비스 단위로 지정된 상기 리소스 공유 정보를 포함하는, 수신 장치.
제3항에 있어서,
상기 시그널링은, 서비스마다의 속성을 지정 가능한 제2 시그널링이며,
상기 제2 시그널링은, 대상의 서비스 내의 소정의 단위로 지정된 상기 리소스 공유 정보를 포함하는, 수신 장치.
제5항에 있어서,
상기 리소스 공유 정보는, 서비스 단위, 세션 단위, 또는 애플리케이션 단위로 지정되는, 수신 장치.
제3항에 있어서,
상기 콘텐츠의 리소스는, 소정의 형식의 파일이며,
상기 제어부는, 상기 콘텐츠와 함께 전송되는 애플리케이션의 동작에 대응하여, 공유 리소스의 파일을, 다른 리소스의 파일이 기억되는 제1 기억 영역과는 상이한 제2 기억 영역에 기억시키는, 수신 장치.
제7항에 있어서,
상기 제어부는, 상기 애플리케이션의 동작에 대응하여, 상기 제2 기억 영역에 기억된 공유 리소스의 파일을 소거하는, 수신 장치.
제3항에 있어서,
상기 방송파는, IP(Internet Protocol) 전송 방식에 대응한 방송파이며,
상기 콘텐츠의 리소스의 파일 데이터는, UDP(User Datagram Protocol) 패킷을 포함하는 IP 패킷에 저장되어 전송되는, 수신 장치.
제1항에 있어서,
상기 콘텐츠는, 광고의 콘텐츠를 포함하는, 수신 장치.
수신 장치의 데이터 처리 방법에 있어서,
상기 수신 장치가,
콘텐츠를 수신하고,
상기 콘텐츠와 함께 전송되는 제어 정보로서, 상기 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되는 리소스인지 여부를 나타내는 리소스 공유 정보를 포함하는 상기 제어 정보에 기초하여, 상기 콘텐츠의 리소스가, 복수의 서비스 중에서 공유되도록, 상기 리소스의 기억 장치로의 기억을 제어하는
스텝을 포함하고,
상기 리소스 공유 정보는, 광고의 콘텐츠의 리소스를 공유하는 복수의 서비스가 속하는 그룹을 식별하는 식별 정보를 포함하는, 데이터 처리 방법.
송신 장치로서,
콘텐츠의 리소스가, 복수의 서비스 중에서 공유되는 리소스인지 여부를 나타내는 리소스 공유 정보를 포함하는 제어 정보를 생성하는 생성부 - 상기 리소스 공유 정보는, 광고의 콘텐츠의 리소스를 공유하는 복수의 서비스가 속하는 그룹을 식별하는 식별 정보를 포함함 -; 및
상기 콘텐츠와 함께, 상기 제어 정보를 송신하는 송신부
를 구비하는, 송신 장치.
제12항에 있어서,
상기 콘텐츠 및 상기 제어 정보는, 방송파에 의해 전송되고,
상기 서비스는, 디지털 방송의 서비스이며,
상기 제어 정보는, 상기 서비스를 제공하기 위한 시그널링인, 송신 장치.
제13항에 있어서,
상기 시그널링은, 복수의 서비스의 속성을 지정 가능한 제1 시그널링이며,
상기 제1 시그널링은, 서비스 단위로 지정된 상기 리소스 공유 정보를 포함하는, 송신 장치.
제13항에 있어서,
상기 시그널링은, 서비스마다의 속성을 지정 가능한 제2 시그널링이며,
상기 제2 시그널링은, 대상의 서비스 내의 소정의 단위로 지정된 상기 리소스 공유 정보를 포함하는, 송신 장치.
제15항에 있어서,
상기 리소스 공유 정보는, 서비스 단위, 세션 단위, 또는 애플리케이션 단위로 지정되는, 송신 장치.
제12항에 있어서,
상기 콘텐츠의 리소스는, 소정의 형식의 파일인, 송신 장치.
제13항에 있어서,
상기 방송파는, IP 전송 방식에 대응한 방송파이며,
상기 콘텐츠의 리소스의 파일 데이터는, UDP 패킷을 포함하는 IP 패킷에 저장되어 전송되는, 송신 장치.
제12항에 있어서,
상기 콘텐츠는, 광고의 콘텐츠를 포함하는, 송신 장치.
송신 장치의 데이터 처리 방법에 있어서,
상기 송신 장치가,
콘텐츠의 리소스가, 복수의 서비스 중에서 공유되는 리소스인지 여부를 나타내는 리소스 공유 정보를 포함하는 제어 정보를 생성하고,
상기 콘텐츠와 함께, 상기 제어 정보를 송신하는
스텝을 포함하고,
상기 리소스 공유 정보는, 광고의 콘텐츠의 리소스를 공유하는 복수의 서비스가 속하는 그룹을 식별하는 식별 정보를 포함하는, 데이터 처리 방법.
제1항에 있어서,
상기 식별 정보는, 캐시 도메인을 식별하는, 수신 장치.