KR102496890B1

KR102496890B1 - 정보 처리 장치, 클라이언트 장치, 및 데이터 처리 방법

Info

Publication number: KR102496890B1
Application number: KR1020197003080A
Authority: KR
Inventors: 야스아키 야마기시
Original assignee: 소니그룹주식회사
Priority date: 2016-08-19
Filing date: 2017-08-04
Publication date: 2023-02-08
Also published as: MX2019001568A; WO2018034172A1; JPWO2018034172A1; EP3503568A4; BR112019002867A2; KR20190039403A; CA3033735A1; US20210288735A1; EP3503568A1

Abstract

본 기술은, 보다 유연하게, 방송과 통신을 이용한 서비스의 운용을 행할 수 있도록 하는 정보 처리 장치, 클라이언트 장치, 및 데이터 처리 방법에 관한 것이다. 정보 처리 장치가, 콘텐츠의 리퀘스트에 대하여 당해 콘텐츠의 소스의 동일성을 식별하기 위한 식별 정보를 삽입함으로써, 보다 유연하게, 방송과 통신을 이용한 서비스의 운용을 행할 수 있게 된다. 본 기술은, 예를 들어, 가정 내 LAN 등의 네트워크에 접속되는 게이트웨이 장치나, 콘텐츠를 재생 가능한 클라이언트 장치에 적용할 수 있다.

Description

정보 처리 장치, 클라이언트 장치, 및 데이터 처리 방법

본 기술은, 정보 처리 장치, 클라이언트 장치, 및 데이터 처리 방법에 관한 것으로서, 특히, 보다 유연하게, 방송과 통신을 이용한 서비스의 운용을 행할 수 있도록 한 정보 처리 장치, 클라이언트 장치, 및 데이터 처리 방법에 관한 것이다.

근년, 방송 서비스를 고도화할 목적으로, 방송뿐만 아니라, 통신을 이용한 서비스에 관한 기술이 제안되고 있다(예를 들어, 특허문헌 1 참조).

일본 특허 공개 제2013-150089호 공보

그런데, 방송과 통신을 이용한 서비스의 운용을 행할 때, 인터넷 상의 통신 서버에 대하여 방송 서비스를 서비스 엔트리로 하여 액세스해 오는 디바이스와, 일반적인 인터넷 사이트를 서비스 엔트리로 하여 액세스하는 디바이스가 존재하는 경우가 상정된다.

그러한 경우에 있어서, 방송 사업자 등의 사업자로부터는, 그들 디바이스를 구별하여, 액세스의 통계를 관리하는 운용 등을 행하고 싶다는 요청이 있지만, 현 상황에서는, 그러한 요청에 따르기 위한 기술 방식은 확립되어 있지 않다.

본 기술은 이러한 상황을 감안하여 이루어진 것이며, 보다 유연하게, 방송과 통신을 이용한 서비스의 운용을 행할 수 있도록 하는 것이다.

본 기술의 제1 측면의 정보 처리 장치는, 콘텐츠의 리퀘스트에 대하여 당해 콘텐츠의 소스의 동일성을 식별하기 위한 식별 정보를 삽입하는 처리부를 구비하는 정보 처리 장치이다.

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

본 기술의 제1 측면의 정보 처리 장치, 및 데이터 처리 방법에 있어서는, 콘텐츠의 리퀘스트에 대하여 당해 콘텐츠의 소스의 동일성을 식별하기 위한 식별 정보가 삽입된다.

본 기술의 제2 측면의 클라이언트 장치는, 방송 경유 또는 통신 경유로 배신되는 콘텐츠를 전송하는 게이트웨이 장치와의 접속을 처리하는 처리부와, 상기 게이트웨이 장치로부터, 네트워크를 통하여 전송되어 오는 상기 콘텐츠를 재생하는 재생부를 구비하고, 상기 게이트웨이 장치는, 프록시로서의 기능을 갖고, 상기 처리부는, 상기 게이트웨이 장치로부터 상기 네트워크를 통하여 제공되는, 상기 프록시가 리퀘스트를 대기하는 IP 어드레스와 포트 번호에 관한 접속 정보에 기초하여, 상기 프록시와의 접속을 확립하는 클라이언트 장치이다.

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

본 기술의 제2 측면의 클라이언트 장치, 및 데이터 처리 방법에 있어서는, 방송 경유 또는 통신 경유로 배신되는 콘텐츠를 전송하는 게이트웨이 장치와의 접속이 처리되어, 상기 게이트웨이 장치로부터, 네트워크를 통하여 전송되어 오는 상기 콘텐츠가 재생된다. 또한, 상기 게이트웨이 장치가, 프록시로서의 기능을 갖고 있으며, 상기 게이트웨이 장치로부터 상기 네트워크를 통하여 제공되는, 상기 프록시가 리퀘스트를 대기하는 IP 어드레스와 포트 번호에 관한 접속 정보에 기초하여, 상기 프록시와의 접속이 확립된다.

본 기술의 제1 측면, 및 제2 측면에 의하면, 보다 유연하게, 방송과 통신을 이용한 서비스의 운용을 행할 수 있다.

또한, 여기에 기재된 효과는 반드시 한정되는 것은 아니며, 본 개시 중에 기재된 어느 효과여도 된다.

도 1은 본 기술을 적용한 전송 시스템의 일 실시 형태의 구성을 도시하는 도면이다.
도 2는 게이트웨이 장치의 구성예를 도시하는 도면이다.
도 3은 클라이언트 장치의 구성예를 도시하는 도면이다.
도 4는 수신측의 장치의 실장예를 설명하는 도면이다.
도 5는 수신측의 장치의 실장예를 설명하는 도면이다.
도 6은 본 기술의 IP 전송 방식의 프로토콜 스택의 예를 도시하는 도면이다.
도 7은 MPD 메타데이터의 상세를 설명하는 도면이다.
도 8은 MPD 메타데이터의 상세를 설명하는 도면이다.
도 9는 세그먼트 베이스를 이용하는 경우의 MPD 메타데이터의 예를 도시하는 도면이다.
도 10은 세그먼트 리스트를 이용하는 경우의 MPD 메타데이터의 예를 도시하는 도면이다.
도 11은 세그먼트 템플릿을 이용하는 경우의 MPD 메타데이터의 예를 도시하는 도면이다.
도 12는 MPD 메타데이터의 예를 도시하는 도면이다.
도 13은 본 기술의 확장 헤더의 예를 도시하는 도면이다.
도 14는 확장 헤더로서 삽입되는 식별 정보의 예를 도시하는 도면이다.
도 15는 HTTP 리퀘스트의 예를 도시하는 도면이다.
도 16은 확장 헤더가 삽입된 HTTP 리퀘스트의 예를 도시하는 도면이다.
도 17은 프록시의 발견·접속 처리와, 확장 헤더 삽입 처리의 일련의 흐름을 설명하는 흐름도이다.
도 18은 프록시의 발견·접속 처리와, 확장 헤더 삽입 처리의 일련의 흐름을 설명하는 흐름도이다.
도 19는 M-SEARCH 리퀘스트의 예를 도시하는 도면이다.
도 20은 M-SEARCH 리스폰스의 예를 도시하는 도면이다.
도 21은 디바이스 디스크립션 리퀘스트의 예를 도시하는 도면이다.
도 22는 디바이스 디스크립션 리스폰스의 예를 도시하는 도면이다.
도 23은 디바이스 디스크립션의 예를 도시하는 도면이다.
도 24는 프록시 대기 어드레스/포트 리퀘스트의 예를 도시하는 도면이다.
도 25는 프록시 대기 어드레스/포트 리스폰스의 예를 도시하는 도면이다.
도 26은 프록시 자동 구성 스크립트 파일의 예를 도시하는 도면이다.
도 27은 확장 헤더 삽입 처리의 상세를 설명하는 흐름도이다.
도 28은 통신 서버측의 HTTP 리퀘스트 대응 처리의 흐름을 설명하는 흐름도이다.
도 29는 컴퓨터의 구성예를 도시하는 도면이다.

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

1. 시스템의 구성

2. 본 기술의 개요

3. HTTP 리퀘스트 헤더의 확장 방법

4. 트랜스페어런트 프록시의 발견·접속 방법

5. 프록시의 발견·접속 처리와, 확장 헤더 삽입 처리의 흐름

6. 변형예

7. 컴퓨터의 구성

<1. 시스템의 구성>

(전송 시스템의 구성예)

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

도 1에 있어서, 전송 시스템(1)은 게이트웨이 장치(10), 클라이언트 장치(20-1 내지 20-N)(N: 1 이상의 정수), 방송 서버(40), 및 통신 서버(70)를 포함하여 구성된다.

전송 시스템(1)에 있어서, 게이트웨이 장치(10)와, 클라이언트 장치(20-1 내지 20-N)는, 엔드 유저택(宅)(2)에 구축된 가정 내 LAN(Local Area Network) 등의 네트워크(30)를 통하여 서로 접속되어, 통신을 행하는 것이 가능하다.

또한, 게이트웨이 장치(10)는 송신소(50)로부터, 방송 전송로(60)를 통하여 송신되는 방송파를 수신하는 기능과 함께, 인터넷(80)에 접속 가능한 통신 기능도 갖고 있다. 이에 의해, 게이트웨이 장치(10)는 인터넷(80)을 통하여, 통신 서버(70)와 서로 접속되어, 통신을 행하는 것이 가능하다.

게이트웨이 장치(10)는 예를 들어, 게이트웨이 기능을 제공하기 위한 전용 서버나, 통신 기능을 갖는 텔레비전 수상기나 셋톱 박스(STB: Set Top Box), 네트워크스토리지 등으로 구성된다.

게이트웨이 장치(10)는 송신소(50)를 통하여, 방송 서버(40)로부터 송신되어 오는 방송파를 수신하고, 방송파로부터 얻어지는 콘텐츠의 데이터를, 네트워크(30)에 접속된 클라이언트 장치(20-1 내지 20-N)로 송신(전송)한다.

또한, 게이트웨이 장치(10)는 인터넷(80)을 통하여, 통신 서버(70)로부터 송신되어 오는 콘텐츠의 데이터를 수신하고, 네트워크(30)에 접속된 클라이언트 장치(20-1 내지 20-N)로 송신(전송)한다.

또한, 게이트웨이 장치(10)의 상세한 구성은, 도 2를 참조하여 후술한다.

클라이언트 장치(20-1)는, 네트워크(30)를 통하여 게이트웨이 장치(10)로부터 송신(전송)되어 오는 콘텐츠를 수신하여 재생하는 수신기이다. 즉, 클라이언트 장치(20-1)는, 엔드 유저의 조작 등에 따라 게이트웨이 장치(10)를 통하여, 방송 경유 또는 통신 경유로 배신되는 콘텐츠를 재생할 수 있다.

클라이언트 장치(20-1)는, 텔레비전 수상기나 셋톱 박스 등의 고정 수신기, 또는, 스마트폰이나 휴대 전화기, 태블릿형 컴퓨터 등의 모바일 수신기이다.

클라이언트 장치(20-2 내지 20-N)는, 클라이언트 장치(20-1)와 마찬가지로, 가정 내에서 사용되는 고정 수신기 또는 모바일 수신기로 구성되고, 게이트웨이 장치(10)를 통하여, 방송 경유 또는 통신 경유로 배신되는 콘텐츠를 수신하여 재생한다.

또한, 이하의 설명에서는, 클라이언트 장치(20-1 내지 20-N)를, 특별히 구별할 필요가 없을 경우, 간단히, 클라이언트 장치(20)라고 칭하기로 한다. 또한, 클라이언트 장치(20)의 상세한 구성은, 도 3을 참조하여 후술한다.

방송 서버(40)는 예를 들어, 방송국 등의 방송 사업자에 의해 제공되는 서버이며, 송신소(50)에 설치되는 송출 설비와, 전용선 등의 소정의 회선을 통하여 접속된다.

방송 서버(40)는 프로그램이나 CM 등의 콘텐츠의 파일(데이터)이나 제어 정보(시그널링)를 처리하고, 그 결과 얻어지는 데이터를, 전용선을 통하여 송신소(50) 내의 송출 설비로 송신한다. 그리고, 송신소(50) 내의 송출 설비는, 방송 서버(40)로부터의 데이터에 대하여 필요한 처리(변조 처리 등)를 실시함으로써, 그 결과 얻어지는 방송파가, 방송 전송로(60)를 통하여, 엔드 유저택(2) 내의 게이트웨이 장치(10)에 의해 수신된다.

통신 서버(70)는 예를 들어, 방송국 등의 방송 사업자나 기타의 사업자에 의해 제공되는 서버이며, 인터넷(80)에 접속된다.

통신 서버(70)는 게이트웨이 장치(10)로부터의 리퀘스트에 따라, 프로그램이나 CM 등의 콘텐츠의 파일이나 제어 정보를 처리하고, 그 결과 얻어지는 데이터를, 인터넷(80)을 통하여 송신(스트리밍 배신)한다.

또한, 도 1의 전송 시스템에서는, 게이트웨이 장치(10)와 클라이언트 장치(20)가 엔드 유저택(2) 내에 배치되는 경우를 설명했지만, 게이트웨이 장치(10)는 엔드 유저택(2) 내에 한하지 않고, 예를 들어, 케이블 오퍼레이터의 헤드 엔드나, 모바일망의 기지국 등에 설치되도록 하여, 보다 광범위한 영역을 커버할 수 있도록 해도 된다.

즉, 예를 들어, 게이트웨이 장치(10)가 케이블 오퍼레이터의 헤드 엔드에 설치되는 경우, 클라이언트 장치(20)는 동일한 엔드 유저택내가 아니라, 케이블 텔레비전의 서비스를 계약하고 있는 각 엔드 유저택내에 설치되게 된다. 또한, 예를 들어, 게이트웨이 장치(10)가 모바일망의 기지국에 설치되는 경우, 클라이언트 장치(20)는 모바일 서비스를 계약하고 있는 엔드 유저가, 옥내 또는 옥외에서 소지하고 있는 디바이스가 된다.

또한, 클라이언트 장치(20)는 차량에 탑재되는 차량 탑재 기기여도 된다. 또한, 도 1의 전송 시스템(1)에 있어서, 네트워크(30) 또는 인터넷(80)에 접속되는 디바이스나 서버의 사이에서 행하여지는 통신은, 무선 통신 및 유선 통신은 물론, 무선 통신과 유선 통신이 혼재한 통신, 즉, 어떤 구간에서는 무선 통신이 행하여지고, 다른 구간에서는 유선 통신이 행하여지는 것이어도 된다.

(게이트웨이 장치의 구성)

도 2는, 도 1의 게이트웨이 장치(10)의 구성예를 도시하는 도면이다.

도 2에 있어서, 게이트웨이 장치(10)는 처리부(100), 튜너(101), 통신 I/F(102), 통신 I/F(103), 및 기억부(104)로 구성된다.

처리부(100)는 예를 들어, CPU(Central Processing Unit)나 마이크로프로세서 등으로 구성된다. 처리부(100)는 각종 연산 처리나, 각 부의 동작 제어 등의 처리를 행한다.

튜너(101)는 안테나를 통하여 수신된 방송파에 대하여 필요한 처리(복조 처리 등)를 실시하고, 그 결과 얻어지는 다중화 스트림을 처리부(100)에 공급한다. 처리부(100)는 튜너(101)로부터 공급되는 다중화 스트림을 처리하고, 그 결과 얻어지는 데이터를 통신 I/F(103)에 공급한다.

통신 I/F(102)는, 처리부(100)로부터의 제어에 따라서, 인터넷(80)에 접속된 통신 서버(70)에 콘텐츠의 배신을 요구한다. 통신 I/F(102)는, 통신 서버(70)로부터 배신되는 콘텐츠의 스트림을, 인터넷(80)을 통하여 수신하고, 처리부(100)에 공급한다. 처리부(100)는 통신 I/F(102)로부터 공급되는 콘텐츠의 스트림을 처리하고, 그 결과 얻어지는 데이터를, 통신 I/F(103)에 공급한다.

통신 I/F(103)는, 네트워크(30)에 접속된 클라이언트 장치(20)로부터 송신되어 오는 데이터를 수신하고, 처리부(100)에 공급한다. 또한, 통신 I/F(103)는, 처리부(100)로부터 공급되는 데이터를, 네트워크(30)를 통하여, 클라이언트 장치(20)로 송신한다.

또한, 통신 I/F(102)와 통신 I/F(103)는, 예를 들어, 통신 인터페이스 회로 등으로 구성된다. 또한, 도 2의 게이트웨이 장치(10)에 있어서는, 설명의 사정상, 통신 I/F(102)와 통신 I/F(103)를, 다른 블록으로서 설명했지만, 통신 I/F(102)와 통신 I/F(103)를 공통화하여, 하나의 통신 I/F로 해도 된다.

기억부(104)는 예를 들어, 반도체 메모리나 하드디스크 드라이브(HDD: Hard Disk Drive) 등으로 구성된다. 기억부(104)는 처리부(100)로부터의 제어에 따라서, 각종 데이터를 기억한다.

처리부(100)는 UPnP/SSDP 서버(111), 프록시 어플리케이션 매니저(112), 로컬 프록시(113), 및 SLS 처리계(114)를 포함한다.

UPnP/SSDP 서버(111)와, 프록시 어플리케이션 매니저(112)는, 게이트웨이 장치(10)에서 가동하는 서비스이며, 네트워크(30)에 접속되는 클라이언트 장치(20)와, 로컬 프록시(113)의 접속을 확립하기 위한 처리를 행한다.

또한, UPnP/SSDP 서버(111)와 프록시 어플리케이션 매니저(112)로 행하여지는 처리의 상세는, 도 17 및 도 18을 참조하여 후술한다. 또한, UPnP/SSDP 서버(111)는 웹 서버(로컬 웹 서버)의 기능을 갖도록 할 수 있다.

로컬 프록시(113)는 게이트웨이 장치(10)에서 가동하는 서비스이며, 네트워크(30)에 접속된 클라이언트 장치(20)로부터의 리퀘스트를, 인터넷(80)에 접속된 통신 서버(70)로 송신한다. 또한, 로컬 프록시(113)는 통신 서버(70)로부터의 콘텐츠의 스트림을, 인터넷(80)을 통하여 수신하고, 네트워크(30)에 접속된 클라이언트 장치(20)로 송신(전송)한다.

또한, 로컬 프록시(113)는 클라이언트 장치(20)로부터의 리퀘스트에 대하여 확장 헤더 삽입 처리를 행하는데, 그 처리의 상세는, 도 17, 도 18, 및 도 27 등을 참조하여 후술한다.

SLS 처리계(114)는 방송 경유 또는 통신 경유로 취득되는 제어 정보인 SLS(Service Layer Signaling)에 관한 처리를 행한다. 또한, SLS의 상세는, 도 6을 참조하여 후술한다. 또한, SLS 처리계(114)에서 행하여지는 처리의 상세는, 도 27을 참조하여 후술한다.

게이트웨이 장치(10)는 이상과 같이 구성된다.

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

도 3은, 도 1의 클라이언트 장치(20)의 구성예를 도시하는 도면이다.

도 3에 있어서, 클라이언트 장치(20)는 처리부(200), 통신 I/F(201), 표시부(202), 및 스피커(203)로 구성된다.

처리부(200)는 예를 들어, CPU나 마이크로프로세서 등으로 구성된다. 처리부(200)는 각종 연산 처리나, 각 부의 동작 제어 등의 처리를 행한다.

통신 I/F(201)는, 예를 들어, 통신 인터페이스 회로 등으로 구성된다.

통신 I/F(201)는, 처리부(200)로부터의 제어에 따라서, 네트워크(30)에 접속된 게이트웨이 장치(10)에 대하여 콘텐츠의 배신을 요구한다. 또한, 통신 I/F(201)는, 네트워크(30)를 통하여, 게이트웨이 장치(10)로부터 송신(전송)되어 오는 콘텐츠의 데이터를 수신하고, 처리부(200)에 공급한다.

처리부(200)는 통신 I/F(201)로부터 공급되는 콘텐츠의 데이터를 처리하고, 그 결과 얻어지는 데이터 중, 비디오 데이터를, 표시부(202)에 공급하고, 오디오 데이터를, 스피커(203)에 공급한다.

표시부(202)는 예를 들어, LCD(Liquid Crystal Display)나 OELD(Organic Electroluminescence Display) 등의 디스플레이로 구성된다. 표시부(202)는 처리부(200)로부터 공급되는 비디오 데이터에 대응하는 영상을 표시한다. 스피커(203)는 처리부(200)로부터 공급되는 오디오 데이터에 대응하는 음성을 출력한다.

또한, 표시부(202)가 터치 패널의 기능을 갖고 있는 경우에는, 당해 터치 패널에 대한 엔드 유저의 조작에 따른 조작 신호가 처리부(200)에 공급되고, 처리부(200)는 당해 조작 신호에 따른 처리를 행한다. 또한, 도 3에는 도시하지는 않았지만, 물리적인 버튼 등의 입력부를 설치하여, 당해 입력부에 대한 엔드 유저의 조작에 따른 조작 신호가, 처리부(200)에 공급되도록 해도 된다.

처리부(200)는 어플리케이션(211) 및 브라우저(212)를 포함한다. 어플리케이션(211) 및 브라우저(212)에 의해, 렌더러 기능이 제공된다.

어플리케이션(211)은 네트워크(30)에 접속되는 클라이언트 장치(20)가 게이트웨이 장치(10)에서 가동하는 로컬 프록시(113)와의 접속을 확립하기 위한 처리를 행한다. 또한, 어플리케이션(211)으로 행하여지는 처리의 상세는, 도 17 및 도 18을 참조하여 후술한다.

브라우저(212)는 통신 I/F(201)로부터 공급되는 콘텐츠의 데이터이며, 게이트웨이 장치(10)에 의해 방송 경유 또는 통신 경유로 수신된 데이터를 처리하고, 콘텐츠를 재생한다.

또한, 브라우저(212)는 DASH 플레이어로서의 기능을 갖는데, 그 상세는, 도 6을 참조하여 후술한다. 또한, 브라우저(212)에서 행하여지는 처리의 상세는, 도 17, 도 18, 및 도 27 등을 참조하여 후술한다.

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

(수신측의 장치의 실장예)

그런데, 도 1의 전송 시스템(1)에 있어서는, 게이트웨이 장치(10)가 방송 경유 또는 통신 경유로 송신측의 서버로부터 배신되는 데이터를, 수신측의 클라이언트 장치(20)에 전송하기 위한 역할을 담당하는 구성을 설명했지만, 그 역할을, 네트워크(30)에 접속된 클라이언트 장치(20) 중 어느 것이 담당하도록 한 구성을 채용할 수도 있다.

본 명세서에서는, 예를 들어, 엔드 유저택(2)에 있어서, 네트워크(30)에 접속된 복수의 클라이언트 장치(20) 중, 클라이언트 장치(20-1)가, 튜너 및 통신 I/F 등의 게이트웨이 장치(10)와 동일한 기능을 갖고, 방송 경유 및 통신 경유로 배신되는 콘텐츠의 데이터를 수신 가능한 경우를 상정한다.

이 경우에 있어서, 클라이언트 장치(20-2 내지 20-N)는, 게이트웨이로서 동작하는 클라이언트 장치(20-1)를 통하여, 방송 경유 또는 통신 경유로 배신되는 콘텐츠의 데이터를 수신할 수 있다. 단, 이 경우에도, 클라이언트 장치(20-2 내지 20-N)는, 게이트웨이 장치(10)에 접속하고, 방송 경유 또는 통신 경유로 배신되는 콘텐츠의 데이터를 수신하도록 해도 된다.

이들 관계를 통합하면, 도 4에 도시하는 바와 같이 된다. 즉, 도 4에 있어서, 게이트웨이 장치(10)는 도 2의 구성에 도시한 바와 같이, 튜너(101)와 함께, 처리부(100)로서, UPnP/SSDP 서버(111), 프록시 어플리케이션 매니저(112), 로컬 프록시(113), 및 SLS 처리계(114)를 포함하여 구성된다.

또한, 도 4에 있어서, 클라이언트 장치(20)에는, 렌더러 기능만을 갖는 일반 클라이언트 장치(20)와, 렌더러 기능뿐만 아니라, 게이트웨이 기능도 갖는 올인원형(All in One) 클라이언트 장치(20)의 2종류가 있다.

또한, 이하의 설명에서는, 적절히, 올인원 클라이언트 장치(20)를 「AOC(All in One Client)」라고도 기술하고, 일반 클라이언트 장치(20)를 「NC(Normal Client)」라고도 기술한다. 또한, 게이트웨이 장치(10)는 「GW(Gateway)」라고도 기술한다.

일반 클라이언트 장치(NC)(20)는, 도 3의 구성에 도시한 바와 같이, 어플리케이션(211) 및 브라우저(212)에 의한 렌더러 기능을 포함하여 구성된다. 한편, 올인원 클라이언트 장치(AOC)(20)는, 렌더러 기능 외에, 게이트웨이 장치(GW)(10)와 마찬가지로, 튜너(101), UPnP/SSDP 서버(111), 프록시 어플리케이션 매니저(112), 로컬 프록시(113), 및 SLS 처리계(114)에 의한 게이트웨이 기능을 포함하여 구성된다.

즉, 일반 클라이언트 장치(NC)(20)는, 게이트웨이 기능을 갖는 게이트웨이 장치(GW)(10), 또는 올인원 클라이언트 장치(AOC)(20)를 통하여, 송신측의 서버와 데이터를 교환하지만, 올인원 클라이언트 장치(AOC)(20)는, 자체가 게이트웨이 기능을 갖기 때문에, 단독으로, 송신측의 서버와 데이터를 교환할 수 있다.

보다 구체적으로는, 도 5에 도시한 바와 같은 관계로서 나타낼 수 있다.

도 5에 있어서, 일반 클라이언트 장치(NC)(20)는, 게이트웨이 장치(GW)(10) 또는 올인원 클라이언트 장치(AOC)(20)를 통하여, 방송 경유 또는 통신 경유의 데이터를 수신한다. 즉, 게이트웨이 장치(GW)(10)는, 일반 클라이언트 장치(NC)(20)에 대하여 게이트웨이 기능을 제공할 수 있다. 또한, 올인원 클라이언트 장치(AOC)(20)는, 일반 클라이언트 장치(NC)(20)에 대하여 게이트웨이 기능을 제공할 수 있다.

또한, 올인원 클라이언트 장치(AOC)(20)는, 게이트웨이 장치(GW)(10)로부터 게이트웨이 기능의 제공을 받고, 일반 클라이언트 장치(NC)(20)로서 기능할 수도 있지만, 통상은, 자체의 게이트웨이 기능을 사용하여, 방송 경유 또는 통신 경유의 데이터를 수신한다.

게이트웨이 장치(GW)(10)는, 게이트웨이로서 기능하고, 송신측의 서버로부터 방송 경유 또는 통신 경유로 배신되는 데이터를, 일반 클라이언트 장치(NC)(20) 또는 올인원 클라이언트 장치(AOC)(20)로 송신한다. 또한, 게이트웨이 장치(GW)(10)는, 일반 클라이언트 장치(NC)(20) 또는 올인원 클라이언트 장치(AOC)(20)로부터의 리퀘스트에 대하여 확장 헤더 삽입 처리를 실시하고, 그 결과 얻어지는 리퀘스트를, 통신 경유로 송신한다.

올인원 클라이언트 장치(AOC)(20)는, 게이트웨이로서 기능하고, 송신측의 서버로부터 방송 경유 또는 통신 경유로 배신되는 데이터를, 자체적으로 처리하거나, 또는 일반 클라이언트 장치(NC)(20)로 송신한다. 또한, 올인원 클라이언트 장치(AOC)(20)는, 자체적으로 처리한 리퀘스트, 또는 일반 클라이언트 장치(NC)(20)로부터의 리퀘스트에 대하여 확장 헤더 삽입 처리를 실시하고, 그 결과 얻어지는 리퀘스트를, 통신 경유로 송신한다.

또한, 수신측의 클라이언트 장치(20)에 대하여 송신측의 서버로부터의 데이터를 중계하는 게이트웨이 기능을 갖는 장치로서는, 방송 경유와 통신 경유의 데이터를, 동일한 장치로 처리해도 되고, 방송 경유의 데이터를 처리하는 장치와, 통신 경유의 데이터를 처리하는 장치가 상이하게 해도 된다. 예를 들어, 일반 클라이언트 장치(NC)(20)에 대한, 방송 경유의 데이터를, 게이트웨이 장치(GW)(10)가 처리하고, 통신 경유의 데이터를, 올인원 클라이언트 장치(AOC)(20)가 처리할 수 있다.

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

도 6은, 본 기술의 IP 전송 방식의 프로토콜 스택의 예를 도시하는 도면이다.

디지털 방송의 전송 방식으로서, 현 상황에서는, MPEG2-TS(Transport Stream) 방식이 널리 보급되어 있지만, 금후에는 통신의 분야에서 사용되고 있는 IP(Internet Protocol) 패킷을 디지털 방송에 사용한 IP 전송 방식이 보급되는 것이 상정되고 있다.

예를 들어, 차세대 지상파 방송 규격의 하나인 ATSC(Advanced Television Systems Committee)3.0에 있어서도, IP 전송 방식을 채용하여, 보다 고도의 서비스를 제공할 수 있도록 할 것이 기대되고 있다. 본 기술에 있어서도, ATSC3.0 등과 마찬가지로, IP 전송 방식을 채용할 수 있다.

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

물리층(Physical Layer)의 상위의 계층은, 데이터 링크층(Data Link Layer)으로 된다. 또한, 데이터 링크층의 상위의 계층은, IP(Internet Protocol)층과 UDP(User Datagram Protocol)층으로 된다. IP층과 UDP층은, 통신의 계층 모델에 있어서의 네트워크층과 트랜스포트층에 상당하는 층이며, IP 어드레스와 포트 번호에 의해, IP 패킷과 UDP 패킷이 특정된다.

여기서, ATSC3.0에서는, 제어 정보(시그널링)로서, LLS(Low Level Signaling)와 SLS(Service Layer Signaling)를 사용하는 것이 상정되어 있다. LLS는, SLS보다도 하위의 층에서 전송되는 제어 정보이다. SLS는, 서비스 단위의 제어 정보이다. 즉, ATSC3.0에서는, 트랜스포트층의 제어 정보가, LLS와 SLS의 2계층으로 전송된다.

LLS에는, SLT(Service List Table) 등의 메타데이터가 포함된다. SLT 메타데이터는, 서비스(채널)의 선국에 필요한 정보 등, 방송 네트워크에 있어서의 스트림이나 서비스의 구성을 나타내는 기본 정보를 포함한다. 이 SLT 메타데이터는, UDP 패킷을 포함하는 IP 패킷인 UDP/IP 패킷에 포함하여 전송된다. 단, SLT 메타데이터를 저장한 UDP/IP 패킷은, 특별한 IP 어드레스와 포트 번호로 전송되게 된다.

IP층과 UDP층에 인접하는 상위의 계층은, ROUTE(Real-time Object Delivery over Unidirectional Transport)로 된다. ROUTE는, 스트리밍 파일 전송용 프로토콜이며, FLUTE(File Delivery over Unidirectional Transport)를 확장한 것이다.

이 ROUTE 세션에 의해, 서비스별로, SLS의 파일(Signaling)이나, NRT(Non Real Time) 콘텐츠의 파일(NRT), DASH 세그먼트 파일(DASH) 등이 전송된다.

여기서, SLS는, 서비스 레벨의 제어 정보이며, 대상의 서비스에 속하는 컴포넌트의 탐색과 선택에 필요한 정보나 속성 등을 제공하는 것이다. SLS는, USBD(User Service Bundle Description), S-TSID(Service-based Transport Session Instance Description), MPD(Media Presentation Description) 등의 메타데이터를 포함한다.

USBD 메타데이터는, 다른 메타데이터의 취득처 등의 정보를 포함한다. 또한, USBD 메타데이터의 상세는, 도 14를 참조하여 후술한다.

S-TSID 메타데이터는, LSID(LCT Session Instance Description)를 ATSC3.0에 적합하게 확장한 것으로서, ROUTE 프로토콜의 제어 정보이다. 또한, S-TSID 메타데이터는, ROUTE 세션으로 전송되는 EFDT(Extended FDT)를 특정할 수 있다. EFDT는, FLUTE에서 도입되고 있던 FDT(File Delivery Table)를 확장한 것으로서, 전송용 제어 정보이다.

MPD 메타데이터는, MPEG-DASH에 준거한 스트리밍 배신을 행하기 위하여 사용되는, 비디오나 오디오의 파일 제어 정보이다. 또한, MPD 메타데이터의 상세는, 도 7 내지 도 11, 및 도 14 등을 참조하여 후술한다.

여기서, MPEG-DASH는, OTT-V(Over The Top Video)에 따른 스트리밍 배신 규격이며, HTTP(Hypertext Transfer Protocol)를 베이스로 한 스트리밍 프로토콜을 사용한 어댑티브 스트리밍 배신에 관한 규격이다.

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

또한, 트랜스포트 프로토콜로서, ROUTE를 사용하는 경우에는, 스트리밍의 파일 포맷으로서, MP4 파일 포맷을 사용할 수 있다. MP4 파일 포맷은, ISO/IEC 14496-12에서 규정되어 있는 ISO BMFF(ISO Base Media File Format)의 파생 포맷이다.

ROUTE 세션으로 전송되는 세그먼트는, 이니셜라이제이션 세그먼트(IS: Initialization Segment)와, 미디어 세그먼트(MS: Media Segment)로 구성된다. 이니셜라이제이션 세그먼트는, 데이터 압축 방식 등의 초기화 정보를 포함하고 있다. 또한, 미디어 세그먼트는, 비디오나 오디오, 자막의 스트림 데이터를 저장하고 있다. 즉, 이 미디어 세그먼트가, DASH 세그먼트(DASH 세그먼트 파일)에 상당하는 것이다.

이와 같이, 프로그램 등의 콘텐츠를 구성하는 서비스 컴포넌트(비디오나 오디오, 자막 등)의 스트림 데이터는, ISO BMFF의 규격에 준한 DASH 세그먼트 단위로, ROUTE 세션에 의해 전송되게 된다.

또한, NRT 콘텐츠는, 수신기의 스토리지에 일단 축적된 후에 재생이 행하여진다. 또한, NRT 콘텐츠 이외의 파일(예를 들어, 어플리케이션이나 전자 서비스 가이드(ESG: Electronic Service Guide)의 파일)가 ROUTE 세션으로 전송되게 해도 된다.

또한, LLS로서의 SLT 메타데이터나, SLS로서의 USBD, S-TSID, MPD 등의 메타데이터는, 예를 들어, XML(Extensible Markup Language) 등의 마크업 언어에 의해 기술된 텍스트 형식의 데이터로 할 수 있다.

한편, 쌍방향의 통신(Broadband)을 이용하는 경우, 그 물리층(Physical Layer)의 상위의 계층은, 데이터 링크층(Data Link Layer)으로 된다. 또한, 데이터 링크층의 상위의 계층은, 네트워크층에 상당하는 IP층으로 된다. IP층에 인접하는 상위 계층은, 트랜스포트층에 상당하는 TCP(Transmission Control Protocol)층으로 되고, 또한, TCP층에 인접하는 상위 계층은, 어플리케이션층에 상당하는 HTTP층으로 된다.

즉, 이들 계층에 의해, 도 1의 인터넷(80) 등의 통신 회선에서 가동하는 TCP/IP 등의 프로토콜이 실장된다.

HTTP층에 인접하는 상위 계층 중, 일부의 계층은, 제어 정보(Signaling)와, NRT 콘텐츠(NRT)로 된다. 이 제어 정보로서는, 상술한 ROUTE 세션으로 전송되는 제어 정보 등, 모든 제어 정보가 포함된다. 또한, NRT 콘텐츠는, 통신 경유로 취득되는 콘텐츠이며, 예를 들어, 어플리케이션이 포함된다.

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

이상과 같이, 본 기술의 IP 전송 방식의 프로토콜 스택에 있어서는, 일방향의 방송계의 계층과, 쌍방향의 통신계의 계층의 일부가 공통인 프로토콜이 되고, 일방향의 방송과 쌍방향의 통신에서, 콘텐츠를 구성하는 서비스 컴포넌트의 스트림 데이터를, ISO BMFF의 규격에 준한 DASH 세그먼트 단위로 전송할 수 있다.

그 때문에, 일방향의 방송계의 스트리밍 배신과, 쌍방향의 통신계의 스트리밍 배신의 양쪽을 행하는 경우에 있어서, 상위의 계층 프로토콜이 공통화되어 있기 때문에, 예를 들어, 클라이언트 장치(20), 방송 서버(40)나 통신 서버(70)에서는, 실장의 부담이나 처리의 부담을 경감할 수 있다.

(MPD 메타데이터의 상세)

이어서, 도 7 내지 도 11을 참조하여, SLS로서 전송되는 MPD 메타데이터의 상세를 설명한다.

MPD 메타데이터에는, Period 요소, AdaptationSet 요소, 및 Representation 요소가 계층 구조로 기술되어 있다.

예를 들어, 도 7에 도시하는 바와 같이, 루트 요소가 되는 MPD 요소 하에는, 시간의 단락을 나타내는 Period 요소가 있고, 또한, Period 요소 하에, 비디오나 오디오, 자막 등의 각각의 스트림(엘리멘터리 스트림)마다, AdaptationSet 요소를 배치하고, 각각의 스트림의 속성을 기술한다.

또한, AdaptationSet 요소 하에, 동일한 스트림(엘리멘터리 스트림)으로부터 파생되는, 레이트 등의 속성이 상이한 복수의 스트림별로, Representation 요소로 나누어, 각각의 레이트 등의 속성을 기술한다. 또한, Representation 요소는, 시간축 상에서, 복수의 세그먼트(Segment)로 분할된다.

클라이언트 장치(20)에서는, SLS로서 전송되는 MPD 메타데이터를 파싱하고, Representation 요소에 기술된 스트림으로 지정되는 레이트의 값을 참고로 해서, 클라이언트 장치(20)가 있는 네트워크 환경에 따른 최적의 스트림을 선택할 수 있게 되어 있다.

도 8에는, MPD 메타데이터에 있어서의, Period 요소와, AdaptationSet 요소와, Representation 요소의 관계를 상세하게 도시하고 있다.

또한, Representation 요소 하에는, Representation 요소가 다시 복수의 스트림으로 구성되는 경우에, 각각의 스트림 속성을 기술하기 위해서, SubRepresentation 요소를 배치할 수 있다.

여기서, MPD 메타데이터에 기술되는 세그먼트 파일은, URL(바이트 레인지)에 의해 특정된다. 세그먼트는, Representation 요소의 일부이며, 1개의 Representation 요소는, 이하 중 어느 것에 의해 구성된다.

(1) 1개나 그 이상의 세그먼트 리스트

(2) 1개의 세그먼트 템플릿

(3) 1개나 그 이상의 베이스 URL과 최대 1개의 세그먼트 베이스(이 경우에는 세그먼트 리스트도, 세그먼트 템플릿도 없다)

이하, 상기 (1) 내지 (3)에 대응하는 MPD 메타데이터의 기술예를 나타낸다.

도 9는, 세그먼트 베이스(SegmentBase)를 이용하는 경우의 MPD 메타데이터의 예를 도시하는 도면이다.

도 9에 도시하는 바와 같이, 세그먼트 베이스는, 1개의 Representation 요소에, 1개의 미디어 세그먼트(세그먼트)밖에 없는 경우에 이용된다. 도 9에 있어서, 초기화 정보의 바이트 열과 RAP(Random Access Points)의 바이트 열이, 파일의 처음의 834바이트 이내에 수렴되어 있다. 또한, 이 834바이트는, SegmentBase 요소의 indexRange 속성에 의해 기술된다.

도 10은, 세그먼트 리스트(SegmentList)를 이용하는 경우의 MPD 메타데이터의 예를 도시하는 도면이다.

도 10에 도시하는 바와 같이, 세그먼트 리스트는, 1개의 Representation 요소에, 복수의 세그먼트 URL이 배치되는 경우에 이용된다. 도 10의 Representation 요소에 있어서, SegmentList 요소에는, 재생 순서대로 배치되는 복수의 SegmentURL 요소가 열기된다.

SegmentURL 요소는, DASH 세그먼트 파일의 URL(그 파일 내의 바이트 레인지)에 의해 표현된다. 또한, SegmentList 요소의 처음에 배치되는 Initilization 요소에는, 초기화 정보를 저장한 파일(InitSegment)을 지시하고 있다.

도 11은, 세그먼트 템플릿(SegmentTemplate)을 이용하는 경우의 MPD 메타데이터의 예를 도시하는 도면이다.

도 11에 도시한 바와 같이, 세그먼트 템플릿은, 세그먼트 URL을 자동 생성할 때에 이용한다. 이 유스케이스의 전형적인 예로서는, 라이브 스트리밍이 있다. 즉, 세그먼트 템플릿에 있어서는, SegmentTemplate 요소에 기술되는 세그먼트 URL의 템플릿 중의 특별한 파라미터를 동적으로 치환해 감으로써, 완전한 세그먼트 URL의 리스트를 생성한다.

구체적으로는, SegmentTemplate 요소의 media 속성의 속성값으로서 기술되는 URL 중, "$Number$"의 부분이, 치환 파라미터(ReplacementParameter)에 상당하고, 당해 파라미터를, startNumber 속성의 값으로부터 개시하여, 순차 인크리먼트하면서 재기입함으로써 세그먼트 URL이 생성된다. 또한, 이 세그먼트 템플릿을 이용함으로써, MPD 메타데이터의 사이즈를 매우 작게 하는 것이 가능하게 된다.

<2. 본 기술의 개요>

그런데, 전송 시스템(1)에 있어서는, 콘텐츠의 배신측(방송 사업자)에 의해 관리되는 서버(예를 들어 통신 서버(70))에서, 어떤 콘텐츠에 대한 클라이언트 장치(20)로부터의 HTTP 리퀘스트의 이력에 의해, 액세스 통계(시청률)를 관리하는 운용이 상정된다. 또한, 본 명세서에서의 콘텐츠의 데이터는, DASH 세그먼트 파일의 시퀀스와 같은, 하나의 콘텐츠로부터 생성되는 청크화된 파일 시퀀스, 또는 프래그먼트 시퀀스에 의해 전송된다.

이러한 운용을 행하는 경우에, 청크화된 각각의 DASH 세그먼트에 대한 HTTP 리퀘스트를 기록할 때, 각각의 리퀘스트 간의 상관을 알기 어려우면, 동일한 콘텐츠에 대한 리퀘스트의 시퀀스인지 여부를 판단하기가 어렵다.

한편, HTTP 리퀘스트의 리퀘스트 헤더(이하, HTTP 리퀘스트 헤더라고 한다)에 기술되는 리퀘스트 URL의 내용을 해석하고, 동일한 패턴을 특정함으로써, HTTP 리퀘스트의 시퀀스를 관련짓는(통합하는) 것은 가능하기는 하다.

그러나, 그들 URL의 내용의 상관을 알기 쉬운 경우에는, 이 방법을 적용할 수 있지만, 동일한 콘텐츠의 데이터로부터 생성된 DASH 세그먼트 파일일지라도, MPD 메타데이터에 기술되는 AdaptationSet 요소나, Representation 요소의 구성 방법에 따라서는, 거기에 포함되는 세그먼트 URL(segmentUrl)이 각각, 전혀 상관이 없는 내용이 될 가능성이 있다.

그러한 구성을 기술한 MPD 메타데이터의 예를, 도 12에 도시하고 있다. 도 12의 MPD 메타데이터에 있어서는, Period 요소와, AdaptationSet 요소와, Representation 요소가 계층 구조를 이루고 있는데, Representation 요소에는, 세그먼트 리스트로서, 복수의 세그먼트 URL이 기술되어 있다.

이 세그먼트 URL은, BaseURL 요소의 값으로서 지정되는 베이스 URL과, SegmentURL 요소의 media 속성의 값으로서 지정되는 파일의 URL을 결합함으로써 완전한 URL이 얻어진다.

즉, 도 12의 MPD 메타데이터에 있어서는, 동일한 콘텐츠로부터 생성되는 2개의 Representation 요소의 계열이 기술되어, 한쪽 계열이, "http://cdn1.com/seg-201.mp4", "http://cdn1.com/seg-202.mp4",…가 되고, 다른 쪽 계열이, "http://cdn2.com/s101.mp4", "http://cdn2.com/s102.mp4",…가 된다.

또한, 이 예에서는, CDN(Content Delivery Network) 서비스를 이용하여, 동일한 콘텐츠를, 다른 CDN의 서버로부터, 배신원의 패스를 바꾸어서 배신하는 운용이 행하여지는 경우를 나타내고 있다.

여기서, "http://cdn1.com/seg-201.mp4"과 "http://cdn2.com/s101.mp4"의 관계 등으로부터는, 도 12의 2개의 Representation 요소에 기술된 계열마다의 DASH 세그먼트의 시퀀스가, 동일한 콘텐츠로부터 생성된 DASH 세그먼트의 시퀀스인 것을 유추하는 것은 용이하지 않다.

또한, 가령, 리퀘스트 URL의 내용에 상관이 있는 경우에도, HTTP 리퀘스트를 받은 통신 서버(70)에서는, 이전에 처리한 URL의 시퀀스를 항상 유지해 두고, 후속의 HTTP 리퀘스트의 리퀘스트 URL과의 비교를 행하고, 그 내용에 상관이 있으면, 그들을 동일한 콘텐츠로부터 생성되는 DASH 세그먼트라고 유추하여 기억하는 것과 같은 처리가 필요해진다.

또한, 여기서, 리퀘스트 URL의 내용에 상관이 있는 경우란, 예를 들어, "http://cdn1.com/seg-201.mp4", "http://cdn1.com/seg-202.mp4",…과 같이, 시계열순으로 배열되고, 어떤 부분이 규칙성이 있는 정수로서 인코딩되는 경우 등이다.

그러나, 이러한 운용을 행하는 경우, 통신 서버(70)측으로, 과거의 리퀘스트 URL의 이력(상태 정보)을 유지하는 부담이 커지고, 또한, 리퀘스트 URL의 비교나, 동일한 출원이 되는 콘텐츠(콘텐츠의 소스의 동일성)의 가능성의 유추 등이 쓸데 없는 처리 부하를 증가시키기 때문에, 스케일러빌리티를 손상시키게 된다. 따라서, 통신 서버(70)측에서, 리퀘스트 URL만에 의지하는 콘텐츠의 동일성의 유추를 행하고, 그 결과를 사용하여 액세스 통계의 기록을 행하는 것은 현실적이지는 못하다.

한편, 예를 들어, 현재 책정중인 ATSC3.0에 있어서는, 서비스를 제공하는 방송 사업자 등은, ATSC3.0의 방송 서비스(이하, ATSC3.0 서비스라고도 한다)로 배신되는 DASH 세그먼트에의 액세스 통계를, 다음과 같이 행하고 싶다는 요청이 있다.

즉, ATSC3.0 서비스(방송 서비스)를 서비스 엔트리로 하여 액세스해 오는 엔드 유저 디바이스(이하, ATSC3.0 엔드 디바이스라고도 한다)와, 그렇지 않은 일반적인 인터넷 사이트를 서비스 엔트리로 하여 액세스해 오는 엔드 유저 디바이스(이하, 일반 엔드 디바이스라고도 한다)를 구별하고, 또한, 기존의 CDN의 로깅의 기능을 이용하여, DASH 세그먼트에의 액세스 통계를 기록하고 싶다는 요청이 있다.

또한, 본 명세서에서의 ATSC3.0 엔드 디바이스에는, 일반 클라이언트 장치(NC)(20)와, 올인원 클라이언트 장치(AOC)(20)가 모두 해당할 가능성이 있다. 또한, 일반 엔드 디바이스에 대해서도, 일반 클라이언트 장치(NC)(20)와, 올인원 클라이언트 장치(AOC)(20)가 모두 해당할 가능성이 있다.

또한, 통신 서버(70)가 CDN의 서버로서 제공되도록 함으로써, 통신 서버(70)에 의해, 콘텐츠의 데이터(DASH 세그먼트 파일)의 배신이 행하여질 때에, 기존의 CDN의 로깅의 기능을 이용하여, DASH 세그먼트의 액세스 통계를 기록한다는 운용이 가능하게 된다. 본 명세서에서는, 기존의 CDN의 기능을 이용함으로써, 추가 비용을 최소한으로 억제할 수 있다.

이상과 같이, 방송 사업자 등의 사업자로부터는, ATSC3.0 엔드 디바이스와 일반 엔드 디바이스를 구별하고, 액세스의 통계를 관리하는 운용 등을 행하고 싶다는 요청이 있지만, 현 상황에서는, 그러한 요청에 따르기 위한 기술 방식은 확립되어 있지 않다.

그래서, 본 기술에서는, 방송과 통신을 이용한 서비스의 운용을 행하는 경우에 있어서, ATSC3.0 서비스(방송 서비스)를 도선(서비스 엔트리)으로 하여, 통신 경유로 액세스해 오는 ATSC3.0 엔드 디바이스(클라이언트 장치(20))를 식별 가능하게 함으로써, 보다 유연하게, 방송과 통신을 이용한 서비스의 운용을 행할 수 있도록 한다.

즉, 본 기술에서는, 방송 서비스를 서비스 엔트리로 하여, 통신 경유로 DASH 세그먼트에 대한 HTTP 리퀘스트가 송신되는 경우에, HTTP 리퀘스트 헤더에 대하여 당해 DASH 세그먼트의 근원이 되는 콘텐츠의 소스의 동일성을 식별하기 위한 식별 정보(이하, 소스 식별 정보라고 한다)가 삽입되도록 한다.

예를 들어, 동일한 콘텐츠일지라도, 예를 들어, 레이트 등의 속성이나, 방송 경유 또는 통신 경유 등의 배신 경로가 상이한 경우가 있고, 그러한 경우에도, 콘텐츠의 소스가 동일한 경우에는, 동일한 소스 식별 정보(소스의 동일성을 식별하는 식별자)가 부가되게 함으로써, 소스의 동일성을 식별할 수 있다.

이에 의해, 통신 서버(70)측에서는, HTTP 리퀘스트 헤더에 포함되는 소스 식별 정보를 기억해 두는 것만으로, 다른 서비스의 배신에 기인하는, DASH 세그먼트에 대한 HTTP 리퀘스트의 리퀘스트 URL 사이의 상관성을, HTTP 리퀘스트마다 처리할 필요가 없게 되어, 통신 서버(70)측의 처리 부하를 대폭으로 저감할 수 있다.

단, HTTP 리퀘스트에 대하여 이러한 특수한 헤더를 추가하는 처리는, 일반적인 DASH 클라이언트(DASH 플레이어)의 실장에 용이하게 추가할 수는 없다.

그래서, 본 기술에서는, ATSC3.0 서비스(방송 서비스)로 배신되는 DASH 세그먼트에 대한 HTTP 리퀘스트에 대해서는, 그들의 HTTP 리퀘스트를 모두, ATSC3.0의 프록시 서버(게이트웨이 장치(10)에서 가동하는 로컬 프록시(113))를 경유시키도록 한다. 이에 의해, 로컬 프록시(113) 상의 모듈이나 서버 사이드 스크립트 등에 의해, HTTP 리퀘스트 헤더에 대하여 확장 헤더(소스 식별 정보)를 용이하게 삽입할 수 있도록 된다.

또한, 이 로컬 프록시(113)는 TLS(Transport Layer Security) 등의 시큐어한 엔드-투-엔드 트랜잭션도 투과적으로 처리 가능한 투과형의 프록시(이하, 트랜스페어런트 프록시(Transparent Proxy)라 한다)로서 구성되도록 한다. 이에 의해, TLS 등의 엔드-투-엔드의 시큐어한 트랜스포트 세션으로 보호된(은폐된) DASH 세그먼트의 리퀘스트/리스폰스 트랜잭션에 대해서도 마찬가지로, 확장 헤더 삽입 처리를 행하는 것이 가능하게 된다.

또한, 트랜스페어런트 프록시에 관한 기술로서는, 이미 각종 기술이 제안되어 있어, 본 명세서에서는, 그들 공지된 기술을 사용할 수 있다.

<3. HTTP 리퀘스트 헤더의 확장 방법>

(확장 헤더의 예)

도 13은, 본 기술의 확장 헤더의 예를 도시하는 도면이다.

도 13에는, HTTP 리퀘스트 헤더의 확장의 일례로서, ATSC3.0 서비스의 경우의 확장 헤더의 기술예를 도시하고 있다.

도 13에 있어서, HTTP 리퀘스트 헤더의 범용 헤더에 확장하는 확장 헤더명은, 예를 들어, "ATSC3.0-Requset"로 된다. 여기서, 범용 헤더는, 리퀘스트나 리스폰스의 엔티티 바디가 아니라, 접속에 대하여 적용되는 헤더를 의미한다. 또한, 확장 헤더명을, 프라이빗 헤더로서 정의하는 경우에는, "X-ATSC3.0-Requset"로 할 수 있다.

확장 헤더의 값으로서는, 콘텐츠의 소스의 동일성을 식별하기 위한 소스 식별 정보가 배치된다. 이 소스 식별 정보에는, 서비스 ID(service-id), 콘텐츠 ID(contentId), MPD 메타데이터의 URL(mpd-uri), 및 시각 정보(broadcastTime) 등의 ATSC3.0 서비스의 배신 관련의 주된 속성을 포함할 수 있다.

서비스 ID는, ATSC3.0으로 규정되는 서비스를 식별하기 위한 ID(글로벌 서비스 ID)이다. 이 서비스 ID는, 필수적인 값으로 된다.

또한, ATSC3.0 규정의 서비스 ID(globalServiceId)의 상세는, 하기의 비특허문헌 1의 「Table 7.1 Semantics of the User Service Bundle Description Fragment for ROUTE/DASH」에 개시되어 있다. 즉, 서비스 ID로서는, USBD 메타데이터의 userServiceDescription 요소의 globalServiceID 속성의 값을 사용할 수 있다.

비특허문헌 1: ATSC Candidate Standard: Signaling, Delivery, Synchronization, and Error Protection(A/331) Doc. S33-174r15 January 2016

MPD 메타데이터의 URL은, USBD 메타데이터에 의해 참조되는 MPD 메타데이터의 절대 패스를 나타낸 URI(Uniform Resource Locator)이다. 이 URL은, 옵셔널한 값으로 된다.

또한, 상기 비특허문헌 1의 「Table 7.1 Semantics of the User Service Bundle Description Fragment for ROUTE/DASH」에 개시되어 있는 바와 같이, MPD 메타데이터의 URL로서는, USBD 메타데이터의 userServiceDescription 요소의 fullMPDUri 속성의 값을 사용할 수 있다.

시각 정보는, 콘텐츠가 실제로 방송된 시각을 나타내고 있다. 단, 방송 시각의 내용 선택은, 실장 의존으로 된다. 즉, 예를 들어, 방송 시각이, 콘텐츠의 배신 스케줄의 개시 시각인지, 또는 배신 스케줄의 개시부터 종료까지의 임의의 시각(HTTP 리퀘스트의 패킷이 도착한 시각)인지는, 운용에 따라서 설정된다. 이 시각 정보는, 옵셔널한 값으로 된다.

콘텐츠 ID는, 콘텐츠를 식별하는 ID이다. 이 콘텐츠 ID로서는, 예를 들어, "EIDR" 또는 "Ad-ID"를 지정할 수 있다. 여기서, "EIDR"는, Entertainment Identifier Registry의 약칭이며, 텔레비전 프로그램이나 영화의 콘텐츠를, 글로벌한 단일의 ID로 관리할 수 있다. "Ad-ID"는, Advertising ID의 생략이며, 광고용의 ID이다. 이 콘텐츠 ID는, 옵셔널한 값으로 된다.

여기서, 도 14에는, HTTP 리퀘스트에 대하여 확장 헤더로서 삽입되는 소스 식별 정보의 예를 도시하고 있다.

즉, 도 14에 있어서는, XML 형식의 USBD 메타데이터와 MPD 메타데이터의 기술예를 나타내고 있지만, 이들 메타데이터로부터 얻어지는 정보를, ATSC3.0 서비스의 배신 관련의 속성으로서, 소스 식별 정보에 포함할 수 있다.

예를 들어, USBD 메타데이터에 있어서는, userServiceDescription 요소의 globalServiceID 속성의 값으로부터, 서비스 ID(글로벌 서비스 ID)가 얻어지고, userServiceDescription 요소의 fullMPDUri 속성의 값으로부터, MPD 메타데이터의 URL이 얻어진다. 또한, 예를 들어, MPD 메타데이터에 있어서는, Period 요소의 AssetIdentifier 요소의 값으로부터, EIDR에 대응한 콘텐츠 ID가 얻어진다.

또한, 상세는 후술하겠지만, 확장 헤더 삽입 처리에 앞서, 소스 식별 정보를 저장한 매핑 데이터베이스를 미리 생성해 둠으로써, 확장 헤더 삽입 처리에서는, 매핑 데이터베이스를 참조함으로써, HTTP 리퀘스트에 삽입해야 할 소스 식별 정보를 취득하는 것이 가능하게 된다.

또한, USBD 메타데이터의 DeliveryMethod 요소에 기술되는 URL과, MPD 메타데이터의 Representation 요소에 기술되는 URL(세그먼트 URL)의 매칭을 행함으로써, 콘텐츠의 데이터(스트림)의 배신 경로가, 방송 경유인지, 또는 통신 경유인지를 특정할 수 있다. 또한, MPD 메타데이터에 있어서의 세그먼트 URL의 기술과 도출에 대해서는, 도 7 내지 도 11을 참조하여 상술한 바와 같다.

이어서, 도 15 및 도 16을 참조하여, HTTP 리퀘스트 헤더의 구체적인 예를 나타낸다. 본 명세서에서는, 먼저, 도 15를 참조하여, 확장 헤더 삽입 전의 HTTP 리퀘스트 헤더를 설명하고 나서, 도 16을 참조하여, 확장 헤더 삽입 후의 HTTP 리퀘스트 헤더를 설명한다.

(HTTP 리퀘스트)

도 15는, HTTP 리퀘스트의 예를 도시하는 도면이다.

도 15에 있어서는, 세그먼트 URL이, "http://a.com/a.mp4"의 경우에, 이 DASH 세그먼트 파일을 취득하기 위한 HTTP 리퀘스트의 예를 나타내고 있다.

이 HTTP 리퀘스트는, HTTP에서 정의되어 있는 메소드 중, GET 메소드를 이용하고 있다. HTTP 리퀘스트에서는, HOST에 의해, 호스트명(서버명)이 지정되고, GET 메소드에 의해, 리소스가 지정된다. 또한, "HTTP/1.1"는, HTTP의 버전을 나타내고 있다.

또한, HTTP 리퀘스트에서는, 1행째가 HTTP 리퀘스트행이 되고, 2행째 이후가 HTTP 헤더행, 즉, HTTP 리퀘스트 헤더로 된다. 또한, GET 메소드를 이용하는 경우, HTTP 바디부에는, 아무것도 기술되지 않는다.

(확장 헤더 삽입 후의 HTTP 리퀘스트)

도 16은, 확장 헤더가 삽입된 HTTP 리퀘스트의 예를 도시하는 도면이다.

도 16에 있어서는, 도 15의 HTTP 리퀘스트(HTTP 리퀘스트 헤더)에 대하여 확장 헤더로서, "atsc3.0-requset"인 확장 헤더명의 행이 추가되어 있다.

즉, 이 확장 헤더로서 추가되는 DASH 세그먼트 파일의 콘텐츠 속성은, 세그먼트 URL을 메인 키로 하여, 매핑 데이터베이스를 참조함으로써 얻어지는 소스 식별 정보를 포함한다. 구체적으로는, 서비스 ID, 콘텐츠 ID, MPD 메타데이터의 URL, 및 시각 정보 등의 소스 식별 정보가, 확장 헤더로서 추가되어 있다.

예를 들어, 도 16의 HTTP 리퀘스트의 확장 헤더에서는, USBD 메타데이터의 globalServiceID 속성의 값인 "urn:atsc:serviceId:NBCU-NFL-1"이, 서비스 ID(service-id)로서 지정되고, USBD 메타데이터의 fullMPDUri 속성의 값인 "http://a.com/a.mpd"가, MPD 메타데이터의 URL(mpd-uri)로서 지정되어 있다.

또한, 도 16의 HTTP 리퀘스트의 확장 헤더에서는, MPD 메타데이터의 AssetIdentifier 요소에 기술되는 EIDR인 "md:cid:EIDR:10.5240％2f0EFB-02CD-126E-8092-1E49-W"이, 콘텐츠 ID(contentId)로서 지정되어 있다. 또한, 도 16의 HTTP 리퀘스트의 확장 헤더에서는, 당해 콘텐츠의 방송 시각인 2016년 7월 4일(금) 23:54:58(그리니치 표준시)을 나타낸 "Fri, 04 Jul 2016 23:54:58 GMT"가, 시각 정보(broadcastTime)로서 지정되어 있다.

이상과 같이, 본 기술에서는, HTTP 리퀘스트에 대하여 확장 헤더로서, 소스 식별 정보를 삽입함으로써, 방송 서비스를 서비스 엔트리로 하여, 통신 경유로 DASH 세그먼트에 대한 HTTP 리퀘스트가 송신되는 경우에도, 콘텐츠의 소스의 동일성을 식별할 수 있도록 하고 있다.

또한, 본 명세서에서는, 디지털 방송의 규격으로서, 미국 등에서 채용되는 방식인 ATSC(특히 ATSC3.0)를 일례로 들어 설명했지만, 본 기술은, 일본 등이 채용하는 방식인 ISDB(Integrated Services Digital Broadcasting)나, 유럽의 각국 등이 채용하는 방식인 DVB(Digital Video Broadcasting) 등에 적용하게 해도 된다.

즉, 소스 식별 정보는, 콘텐츠의 소스의 동일성을 식별 가능한 정보이며, 방송 서비스(예를 들어, ATSC3.0 서비스 등)를 식별하기 위한 정보가 되므로, 여러가지 방송 방식에 적용할 수 있다. 단, 상술한 설명에서는, 소스 식별 정보로서, ATSC3.0 서비스를 전제로, 서비스 ID나 콘텐츠 ID 등을 예시 열거했지만, 그들에 한하지 않고, ISDB나 DVB 등의 규격마다, 보다 적합한 정보를 사용할 수 있다.

또한, 디지털 방송의 규격 이외에 규정된 정보를, 필요에 따라, 소스 식별 정보에 추가할 수도 있다. 예를 들어, 이동체 통신 시스템의 표준화 프로젝트인3GPP(Third Generation Partnership Project)로 규정된 정보를 추가할 수도 있다. 구체적으로는, 예를 들어, 소스 식별 정보로서, 3GPP-MBMS(Multimedia Broadcast Multicast Services)로 규정되는 요소나 속성을 추가할 수 있다.

<4. 트랜스페어런트 프록시의 발견·접속 방법>

그런데, 엔드 유저택(2) 내 이외에, 케이블 오퍼레이터의 헤드 엔드나, 모바일망의 기지국 등에 설치될 가능성이 있는, 게이트웨이 장치(10)(의 로컬 프록시(113))를 발견·접속하는 방법으로서는, 몇 가지의 방법이 상정된다.

예를 들어, 클라이언트 장치(20)에 있어서, 브라우저(212)의 인터넷 접속 설정의 메뉴에서, 수동으로 로컬 프록시(113)의 IP 어드레스나 포트 번호 등을 입력하는 방법이나, 프록시 설정 스크립트의 URL을 등록하는 방법, 또는 자동 설정에 의한 방법 등이 있다.

자동 설정의 방법으로서는, 예를 들어, DHCP(Dynamic Host Configuration Protocol) 서버를 사용하는 방법이나, WPAD(Web Proxy Auto Discovery)를 사용하는 방법 등이 있다. 또한, 프록시 설정 스크립트에 의한 자동 설정은, JavaScript(등록 상표) 등의 스크립트 언어로 기술된 프록시 자동 구성 스크립트 파일을 준비하고, 그 파일을 웹 서버 상에 배치하는 한편, 그 파일의 URL을, 브라우저(212)의 자동 설정의 스크립트 URL에 설정하면 된다.

WPAD를 사용하는 경우에는, 브라우저(212) 자체가, 프록시 설정용의 스크립트 파일의 위치(URL)를 자동적으로 검출하여 다운로드함으로써, 설정을 행할 수 있다. 또한, WPAD에서는, 일반적으로는, DHCP 서버의 DHCPINFORM 메시지를 사용하는 방법과, DNS(Domain Name System)를 사용한 방법에 의해, "wpad"라고 하는 이름을 갖는 엔트리를 찾고, 그것으로부터 프록시 설정 스크립트를 다운로드하는 방법이 실장되어 있다.

게이트웨이 장치(10)(의 로컬 프록시(113))의 발견에 있어서도, 동일한 방법을 사용할 수 있다. 로컬 프록시(113)에서는, HTTPS 프로토콜에 의한 시큐어한 엔드-투-엔드의 트랜스포트 세션을 포함하는 모든 세션을, 로컬 프록시(113)가 중개(탈취)할 수 있도록 한다. 일반적으로, 이러한 프록시가, 트랜스페어런트 프록시(투과 프록시)라 불리는 것은, 이미 기술한 바와 같다.

본 기술에서는, 클라이언트 장치(20)가 네트워크(30)에 있어서, 로컬 프록시(113)가 가동하고 있는 서버인 게이트웨이 장치(10)를 발견하고, 당해 로컬 프록시(113)가 리퀘스트를 대기하는 IP 어드레스와 포트 번호(이하, 프록시 대기 어드레스/포트라고도 한다)를 취득하는 방식을 제안한다.

그것을 위해서는, 클라이언트 장치(20)에서는, 로컬 프록시(113)에 대하여 프록시 대기 어드레스/포트를 문의하기 위한 Web API(Application Programming Interface)를 인식할 필요가 있다. 즉, 이 Web API는, 서비스를 호출하기 위한 인터페이스라고 할 수 있다.

여기서, 트랜스페어런트 프록시인 로컬 프록시(113)의 발견에, 유니버설 플러그 앤 플레이(UPnP: Universal Plug and Play)를 이용하는 경우, 로컬 프록시(113)의 발견과, 기능의 공개에는, SSDP(Simple Service Discovery Protocol)가 사용된다.

또한, UPnP은, 디바이스를 접속하는 것만으로, 대상의 네트워크에 참가하는 것을 가능하게 하는 프로토콜이다. 또한, SSDP은, UPnP에서 사용되는 프로토콜의 하나로, 네트워크 상의 디바이스의 탐색이나 응답을 행하기 위한 것이다.

일반적으로, SSDP에 있어서는, 공개되는 서비스를 발견할 때에 교환되는 디바이스 디스크립션으로서, 디바이스가 제공 가능한 기능이나 정보가 기술된 XML 형식의 파일이 사용된다. 이 파일에는, 대상의 디바이스 그 자체에 대하여 기술한 디바이스 디스크립션과, 대상의 디바이스 상에 실장된 각 서비스가 갖는 액션으로서의 서비스 디스크립션이 기술된다.

본 기술에서는, 로컬 프록시(113)의 디스크립션(예를 들어 서비스 디스크립션)에, 당해 로컬 프록시(113)가 리퀘스트를 대기하는 IP 어드레스와 포트 번호(프록시 대기 어드레스/포트)를 회답하는 Web API의 URL을 기술할 수 있도록 한다.

또한, 본 기술에서는, ATSC3.0 서비스 등의 방송 서비스에 대응하는 로컬 프록시(113)의 서비스를 발견하기 위한 프로토콜을 추가함으로써, 방송 서비스를 실장하지 않은 일반 클라이언트 장치(NC)(20)로, 브라우저(212)의 프록시로서, 프록시 대기 어드레스/포트를 설정할 수 있도록 한다.

즉, 방송 서비스를 실장하고 있지 않은 일반 클라이언트 장치(NC)(20)(스마트폰이나 태블릿형 컴퓨터 등의 일반 엔드 디바이스)의 브라우저(212)로, 어떤 스크립트(Web API)를 구동하면, 방송 서비스에 대응하는 서버인 게이트웨이 장치(10)를 발견하고, 거기에서 가동하는 로컬 프록시(113)의 프록시 대기 어드레스/포트를, 당해 브라우저(212)의 프록시로서 설정할 수 있도록 한다.

이하, 이러한, 게이트웨이 장치(10)에서 가동하는 로컬 프록시(113)의 발견과, 로컬 프록시(113)의 프록시 대기 어드레스/포트의 취득 시퀀스(프록시의 발견·접속 처리)를 상술한 HTTP 리퀘스트 헤더의 확장 시퀀스(확장 헤더 삽입 처리)와 아울러 설명한다.

또한, 본 명세서에서는, 네트워크 상의 디바이스의 탐색이나 응답을 행하는 프로토콜로서, SSDP을 일례로 들어 설명했지만, DIAL(Discovery and Launch) 등의 다른 프로토콜을 사용함으로써도, 동일한 기능을 실현할 수 있다. DIAL은, 네트워크 상에 있는 DIAL 대응의 디바이스를 UPnP에 의해 발견하고, 지정된 어플리케이션을 기동시키는 프로토콜이다.

<5. 프록시의 발견·접속 처리와, 확장 헤더 삽입 처리의 흐름>

(프록시의 발견·접속 처리와, 확장 헤더 삽입 처리)

도 17 및 도 18의 흐름도를 참조하여, 프록시의 발견·접속 처리와, 확장 헤더 삽입 처리의 일련의 흐름을 설명한다.

단, 도 17 및 도 18의 설명에서는, 도 19 내지 도 26에 나타낸 리퀘스트나 리스폰스 등의 메시지의 내용을 적절히 참조하면서 설명하기로 한다.

또한, 도 17 및 도 18의 설명에서는, 네트워크(30)에 접속되는 게이트웨이 장치(10)에는, IP 어드레스로서, "192.168.1.1"이 할당되어 있는 것으로 한다. 또한, 이 게이트웨이 장치(10)에서 가동하는 서비스 중, UPnP/SSDP 서버(111)에는, "12345"인 포트 번호, 프록시 어플리케이션 매니저(112)에는, "23456"인 포트 번호, 로컬 프록시(113)에는, "34567"인 포트 번호가 각각 할당되어 있는 것으로 한다.

또한, 도 17 및 도 18에 있어서, 스텝 S101 내지 S102의 처리와, 스텝 S111의 처리와, 스텝 S121 내지 S123의 처리는, 게이트웨이 장치(10)에 의해 실행된다. 한편, 스텝 S201 내지 S204의 처리와, 스텝 S211 내지 S212의 처리는, 클라이언트 장치(20)에 의해 실행된다.

도 17의 스텝 S201에 있어서, 어플리케이션(211)은 게이트웨이 장치(10)에서 가동하는 로컬 프록시(113)의 존재를 확인하기 위해서, 통신 I/F(201)를 통하여, 네트워크(30)에 접속된 디바이스(서버)에 대하여 M-SEARCH 리퀘스트를, 멀티캐스트로 송신한다.

도 19는, M-SEARCH 리퀘스트의 예를 도시하는 도면이다.

M-SEARCH 리퀘스트에는, 멀티캐스트의 IP 어드레스로서, "239.255.255.250"가 지정되고, 포트 번호로서, "1900"가 지정된다.

또한, 상술한 바와 같이, UPnP의 프로토콜로서, SSDP을 사용하므로, MAN에는, "ssdp:discover"가 지정된다. 또한, 탐색의 대상이, ATSC3.0에 대응한 프록시인 로컬 프록시(113)가 되므로, ST에는, "urn:atsc:proxy"가 지정된다.

도 17로 되돌아가서, 스텝 S201의 처리에서, 클라이언트 장치(20)에 의해 송신되는 M-SEARCH 리퀘스트는, 네트워크(30)에 접속된 게이트웨이 장치(10)에 의해 수신된다.

스텝 S101에 있어서, UPnP/SSDP 서버(111)는, 클라이언트 장치(20)로부터 수신한 M-SEARCH 리퀘스트에 따라, 디바이스 디스크립션 URL을 생성하고, M-SEARCH 리스폰스로서, 네트워크(30)를 통하여 클라이언트 장치(20)로 송신한다.

도 20은, M-SEARCH 리스폰스의 예를 도시하는 도면이다.

M-SEARCH 리스폰스에 있어서, LOCATION에는, 디바이스 디스크립션 URL로서, "http://192.168.1.1:12345/deviceDescription.xml"가 지정된다. 이 디바이스 디스크립션 URL은, XML 형식의 파일 URL이며, 이 파일은, 게이트웨이 장치(10)에서 가동하는 로컬 웹 서버가 처리한다.

즉, 게이트웨이 장치(10)에 있어서는, UPnP/SSDP 서버(111)가 로컬 웹 서버로서의 기능을 갖고 있으므로, 디바이스 디스크립션 URL에는, 게이트웨이 장치(10)에 할당된 IP 어드레스인 "192.168.1.1"과, 로컬 웹 서버로서의 UPnP/SSDP 서버(111)에 할당된 포트 번호인 "12345"가 기술된다.

도 17로 되돌아가서, 스텝 S101의 처리에서, 게이트웨이 장치(10)에 의해 송신되는 M-SEARCH 리스폰스는, M-SEARCH 리퀘스트를 송신한 클라이언트 장치(20)에 의해 수신된다.

스텝 S202에 있어서, 어플리케이션(211)은 게이트웨이 장치(10)로부터 수신한 M-SEARCH 리스폰스(의 디바이스 디스크립션 URL)에 기초하여, 네트워크(30)에 접속된 게이트웨이 장치(10)에서 가동하는 UPnP/SSDP 서버(111)에 대하여 디바이스 디스크립션을 요구한다.

도 21은, 디바이스 디스크립션 리퀘스트의 예를 도시하는 도면이다.

디바이스 디스크립션 리퀘스트에는, GET 메소드의 대상 리소스로서, "deviceDescripion.xml"인 디바이스 디스크립션이 기술된다. 또한, HOST에는, 호스트명으로서, "192.168.1.1:12345"가 기술된다.

즉, 디바이스 디스크립션 리퀘스트에서는, M-SEARCH 리스폰스에 기술된 내용에 따라, GET 메소드의 대상 리소스가, "deviceDescripion.xml"이 된다. 또한, 디바이스 디스크립션 리퀘스트에는, HOST로서, "192.168.1.1"인 게이트웨이 장치(10)의 IP 어드레스와, "12345"인 UPnP/SSDP 서버(111)(로컬 웹 서버)의 포트 번호가 기술된다.

도 17로 되돌아가서, 스텝 S202의 처리에서, 클라이언트 장치(20)에 의해 송신되는 디바이스 디스크립션 리퀘스트는, 네트워크(30)에 접속된 게이트웨이 장치(10)에 의해 수신된다.

스텝 S102에 있어서, UPnP/SSDP 서버(111)(로컬 웹 서버)는 클라이언트 장치(20)로부터 수신한 디바이스 디스크립션 리퀘스트에 따라, 디바이스 디스크립션을 생성하고, 리스폰스로서, 네트워크(30)를 통하여 클라이언트 장치(20)로 송신한다.

도 22 및 도 23은, 디바이스 디스크립션 리스폰스의 예를 도시하는 도면이다.

디바이스 디스크립션 리스폰스의 헤더에는, 도 22에 도시하는 바와 같이, 파일의 타입 등이 지정된다. 또한, 도 23에는, XML 형식의 디바이스 디스크립션의 내용이 도시되어 있다.

즉, 도 23의 디바이스 디스크립션에는, root 요소의 xmlns 속성으로서, "urn:schemas-upnp-org:device-1-0"가 기술되어, UPnP 준거의 디바이스 디스크립션임이 선언되어 있다.

serviceList 요소에는, 게이트웨이 장치(10)로 서포트되는 서비스의 일람이 기술된다. serviceList 요소에는, 1개 또는 복수의 service 요소가 기술된다.

service 요소에는, 서포트되는 서비스 중, 하나의 서비스에 관한 정보가 기술된다. service 요소는, serviceType 요소, serviceId 요소, SCPDURL 요소, 및 controlURL 요소 등의 상위 요소가 된다.

serviceType 요소에는, 서비스의 타입으로서, "urn:atsc:proxy"가 기술되어, ATSC3.0 서비스의 프록시 서비스인 것을 의미하고 있다.

serviceId 요소에는, 서비스 ID로서, "urn:UPnP:serviceId:1234"가 기술되어, 프록시 서비스의 서비스 ID를 나타내고 있다.

controlURL 요소에는, 프록시 대기 어드레스/포트 취득 Web API의 URL로서, "http://192.168.1.1:23456/getATSC3.0ProxyAddressPort"가 기술된다. 이 URL은, 로컬 프록시(113)가 리퀘스트를 대기하는 IP 어드레스와 포트 번호를 나타내는 프록시 대기 어드레스/포트를 취득하기 위한 Web API를 호출하기 위한 정보이다.

여기서, 통상, SCPDURL 요소에는, ACR 클라이언트 서비스에 관한 서비스 디스크립션의 어드레스가 기술되므로, HTTP로 규정되는 GET 메소드에 의해, 서비스 디스크립션이 취득된다. 그 경우에는, UPnP로 규정되는 SOAP(Simple Object Access Protocol)에 의해, controlURL 요소에 기술되는 URL에 대하여 액션의 메시지를 송부함으로써, 액션을 호출하게 된다.

한편, 본 기술에서는, 보다 간편하게 Web API를 호출할 수 있도록, UPnP의 규정과는 다른 방법으로, Web API의 URL을 주지하는 방법을 제안한다. 즉, 본 기술에서는, 도 23에 도시하는 바와 같이, SCPDURL 요소의 값으로서는 아무것도 기술하지 않고(SCPDURL 요소의 내용은 비워 두고), SCPDURL 요소에 아무것도 기술되어 있지 않은 경우에 한하여, controlURL 요소에, 직접, Web API의 URL을 기술할 수 있도록 하고 있다.

또한, controlURL 요소에, 직접, Web API의 URL을 기술하기 위한 조건으로서는, 상술한 바와 같은, SCPDURL 요소의 내용을 비우는 것 이외에, 예를 들어, controlURL 요소에, 더미의 문자열을 기술하게 해도 된다.

도 17로 되돌아가서, 스텝 S102의 처리에서, 게이트웨이 장치(10)에 의해 송신되는 디바이스 디스크립션 리스폰스는, 디바이스 디스크립션 리퀘스트를 송신한 클라이언트 장치(20)에 의해 수신된다.

스텝 S203에 있어서, 어플리케이션(211)은 게이트웨이 장치(10)로부터 수신한 디바이스 디스크립션 리스폰스(의 프록시 대기 어드레스/포트 취득 Web API의 URL)에 기초하여, 네트워크(30)에 접속된 게이트웨이 장치(10)에서 가동하는 프록시 어플리케이션 매니저(112)에 대하여 프록시 대기 어드레스/포트를 요구한다.

도 24는, 프록시 대기 어드레스/포트 리퀘스트의 예를 도시하는 도면이다.

프록시 대기 어드레스/포트 리퀘스트에는, GET 메소드의 대상 리소스로서, "getATSC3.0ProxyAddressPort"인 대상의 프록시 대기 어드레스/포트가 기술된다. 또한, HOST에는, 호스트명으로서, "192.168.1.1:23456"이 기술된다.

즉, 프록시 대기 어드레스/포트 리퀘스트에서는, 디바이스 디스크립션 리스폰스에 기술된 내용(controlURL 요소의 내용)에 따라, GET 메소드의 대상이, "getATSC3.0ProxyAddressPort"이 된다. 또한, 프록시 대기 어드레스/포트 리퀘스트에는, HOST로서, "192.168.1.1"인 게이트웨이 장치(10)의 IP 어드레스와, "23456"인 프록시 어플리케이션 매니저(112)의 포트 번호가 기술된다.

도 17로 되돌아가서, 스텝 S203의 처리에서, 클라이언트 장치(20)에 의해 송신되는 프록시 대기 어드레스/포트 리퀘스트는, 네트워크(30)에 접속된 게이트웨이 장치(10)에 의해 수신된다.

스텝 S111에 있어서, 프록시 어플리케이션 매니저(112)는, 클라이언트 장치(20)로부터 수신한 프록시 대기 어드레스/포트 리퀘스트에 따라, 프록시 대기 어드레스/포트를 생성하고, 리스폰스로서, 네트워크(30)를 통하여 클라이언트 장치(20)로 송신한다.

도 25는, 프록시 대기 어드레스/포트 리스폰스의 예를 도시하는 도면이다.

프록시 대기 어드레스/포트 리스폰스의 바디부에는, 프록시 대기 어드레스/포트로서, "192.168.1.1:34567"이 기술되어 있다.

즉, 게이트웨이 장치(10)에 있어서, 로컬 프록시(113)가 프록시 서버로서의 기능을 갖고 있으므로, 당해 리스폰스의 바디부에는, 게이트웨이 장치(10)에 할당된 IP 어드레스인 "192.168.1.1"과, 로컬 프록시(113)에 할당된 포트 번호인 "34567"이 기술된다.

또한, 이 예에서는, Web API에의 리퀘스트(프록시 대기 어드레스/포트 리퀘스트)를 수취하는 것이, 프록시 어플리케이션 매니저(112)인 것으로 하여 설명하고 있지만, 로컬 프록시(113) 본체가, 당해 리퀘스트를 수취하고, 처리하게 해도 된다.

도 17로 되돌아가서, 스텝 S111의 처리에서, 게이트웨이 장치(10)에 의해 송신되는 프록시 대기 어드레스/포트 리스폰스는, 프록시 대기 어드레스/포트 리퀘스트를 송신한 클라이언트 장치(20)에 의해 수신된다.

도 18의 스텝 S204에 있어서, 어플리케이션(211)은 게이트웨이 장치(10)로부터 수신한 프록시 대기 어드레스/포트 리스폰스(의 IP 어드레스와 포트 번호)에 기초하여, 프록시 자동 구성 스크립트의 갱신과, 브라우저(212)의 기동(재기동)에 의한 구성 변경의 반영을 행한다.

즉, 클라이언트 장치(20)에 있어서, 어플리케이션(211)은 프록시 대기 어드레스/포트 리스폰스로부터, 프록시 대기 어드레스/포트로서 얻어지는 IP 어드레스와 포트 번호(ATSC3.0ProxyAddressPort(192.168.1.1:34567))에 의해, 프록시 자동 구성 스크립트 파일을 재기입한다.

도 26은, 프록시 자동 구성 스크립트 파일의 예를 도시하는 도면이다.

프록시 자동 구성 스크립트 파일은, 스크립트 언어로서, JavaScript(등록 상표)를 사용하여 기술할 수 있다.

도 26에 있어서는, FindProxyForURL 함수가 정의되고, 그 인수로서, url, host가 지정 가능하다. FindProxyForURL 함수에 있어서는, 조건 분기의 else문에, "PROXY 192.168.1.1:34567; DIRECT", 즉, 프록시 대기 어드레스/포트가 기술되어 있다. 즉, "192.168.1.1"는, 게이트웨이 장치(10)에 할당된 IP 어드레스이며, "34567"는, 로컬 프록시(113)에 할당된 포트 번호이다.

이 FindProxyForURL 함수에 의해, 서브넷 내의 특정한 호스트는 직접 외부와 접속하고, 그 이외의 호스트는, 게이트웨이 장치(10)에서 가동하는 로컬 프록시(113)를 통하여, 외부에 접속하게 된다. 단, 본 명세서에서의 호스트에는, 클라이언트 장치(20)가 포함된다.

즉, 클라이언트 장치(20)에서는, 어플리케이션(211)에 의해, 프록시 자동 구성 스크립트 파일이, 프록시 대기 어드레스/포트에 의해 재기입되고, 브라우저(212)가 기동(재기동)된다. 그리고, 당해 브라우저(212)가 참조하는 프록시 자동 구성 스크립트 파일에 의해, 프록시의 IP 어드레스와 포트 번호의 설정(자동 설정)이 행하여진다.

이에 의해, 클라이언트 장치(20)에 있어서, 브라우저(212)는 네트워크(30)를 통하여, 게이트웨이 장치(10)에서 가동하는 로컬 프록시(113)에 액세스하는 것이 가능하게 된다.

스텝 S211에 있어서, 브라우저(212)는 방송 서비스를 서비스 엔트리로 하여, 통신 경유로 콘텐츠의 배신을 받는 타이밍이 된 경우, DASH 세그먼트를, 네트워크(30)를 통하여, 게이트웨이 장치(10)에서 가동하는 로컬 프록시(113)에 요구한다.

즉, 브라우저(212)는 콘텐츠의 DASH 세그먼트를 재생하는 DASH 플레이어로서의 기능을 갖고 있으며, 일반 클라이언트 장치(20)(NC)의 브라우저(212)(DASH 플레이어)로부터의 리퀘스트(예를 들어, "http(s)://a.com/a.mp4"인 세그먼트 URL의 DASH 세그먼트 파일의 HTTP 리퀘스트)는 모두, 로컬 프록시(113)를 경유하게 된다.

스텝 S211의 처리에서, 클라이언트 장치(20)에 의해 송신되는, DASH 세그먼트의 HTTP 리퀘스트는, 게이트웨이 장치(10)에서 가동하는 로컬 프록시(113)에 의해 수신된다.

스텝 S121에 있어서, 로컬 프록시(113)는 클라이언트 장치(20)로부터 수신한 HTTP 리퀘스트에 대하여 확장 헤더를 삽입한다.

즉, 로컬 프록시(113)는 트랜스페어런트 프록시로서의 기능을 갖고, 확장 헤더 삽입 처리를 행함으로써, 클라이언트 장치(20)로부터의 HTTP 리퀘스트에 대하여 콘텐츠의 소스의 동일성을 식별하기 위한 소스 식별 정보(소스의 동일성을 식별하는 식별자)를 삽입한다. 이 확장 헤더 처리에서 삽입되는 소스 식별 정보로서, 예를 들어, ATSC3.0 서비스의 경우에는, 서비스 ID나 콘텐츠 ID, MPD 메타데이터의 URL, 시각 정보 등을 포함할 수 있는 것은 상술한 바와 같다.

또한, ATSC3.0 서비스에 대응한 확장 헤더 삽입 처리에 있어서는, 포획한 DASH 세그먼트 파일의 HTTP 리퀘스트에 대하여 확장 헤더를 삽입하기 전에, 미리 생성된 매핑 데이터베이스를 참조함으로써, 당해 HTTP 리퀘스트(의 URL)가 ATSC3.0 서비스로 배신된 MPD 메타데이터에 기술된 세그먼트 URL인지 여부를 확인하는 처리가 행하여진다. 이 처리의 상세는, 도 27의 흐름도를 참조하여 후술한다.

스텝 S122에 있어서, 로컬 프록시(113)는 스텝 S121의 처리(확장 헤더 삽입 처리)에서 얻어지는 HTTP 리퀘스트를, 통신 I/F(102)를 통하여, 인터넷(80)에 접속된 통신 서버(70)로 송신한다.

또한, 상세는, 도 28을 참조하여 후술하겠지만, 통신 서버(70)는 인터넷(80)을 통하여 게이트웨이 장치(10)로부터 송신되어 오는 HTTP 리퀘스트를 수신한다. 또한, 통신 서버(70)는 수신한 HTTP 리퀘스트에 기초하여, DASH 세그먼트 파일을, 인터넷(80)을 통하여, 게이트웨이 장치(10)로 송신한다.

여기서, 통신 서버(70)는 게이트웨이 장치(10)로부터 수신한 HTTP 리퀘스트 헤더에, 서비스 ID나 콘텐츠 ID, MPD 메타데이터의 URL, 시각 정보 등의 소스 식별 정보가 삽입되어 있기 때문에, 당해 소스 식별 정보를 확인함으로써 HTTP 리퀘스트가, ATSC3.0 서비스를 도선으로 하여 요구된 리퀘스트임을 인식할 수 있다.

통신 서버(70)에 의해 송신되는 DASH 세그먼트 파일은, 인터넷(80)에 접속된 게이트웨이 장치(10)에 의해 수신된다.

스텝 S123에 있어서, 로컬 프록시(113)는 통신 서버(70)로부터 수신한 DASH 세그먼트 파일을, 통신 I/F(103)를 통하여, 네트워크(30)에 접속된 클라이언트 장치(20)에 전송한다.

스텝 S123의 처리에서, 게이트웨이 장치(10)에 의해 전송되는 DASH 세그먼트 파일은, 네트워크(30)에 접속된 클라이언트 장치(20)에 의해 수신된다.

스텝 S212에 있어서, 브라우저(212)는 게이트웨이 장치(10)로부터 수신한 DASH 세그먼트 파일을 처리하고, DASH 플레이어에 의한 DASH 세그먼트 파일의 재생을 행한다. 이에 의해, 클라이언트 장치(20)에 있어서는, 통신 경유로 배신된 프로그램 등의 콘텐츠가 재생되게 된다.

이상, 프록시의 발견·접속 처리와, 확장 헤더 삽입 처리의 일련의 흐름을 설명하였다.

(확장 헤더 삽입 처리의 상세)

이어서, 도 27의 흐름도를 참조하여, 확장 헤더 삽입 처리의 상세를 설명한다.

도 27의 흐름도에 나타낸 처리는, 도 17 및 도 18의 프록시 발견·접속 처리와, 확장 헤더 삽입 처리 중, 확장 헤더 삽입 처리에 상당하는 처리이며, 도 18의 스텝 S121 내지 S123의 처리와, 스텝 S211 내지 S212의 처리에 대응하고 있다.

또한, 도 27에 있어서, 스텝 S151 내지 S154의 처리와, 스텝 S161 내지 S164의 처리는, 게이트웨이 장치(10)에 의해 실행된다. 또한, 스텝 S251 내지 S252의 처리는, 클라이언트 장치(20)에 의해 실행된다.

게이트웨이 장치(10)에 있어서는, 클라이언트 장치(20)로부터의 HTTP 리퀘스트에 대한 확장 헤더 삽입 처리에 앞서, 스텝 S151 내지 S153의 처리가 실행되어, SLS 처리계(114)에 의해, 매핑 데이터베이스가 생성되어, 기억부(104)에 기억된다.

구체적으로는, 스텝 S151에 있어서, SLS 처리계(114)는 다중화 스트림으로부터, ROUTE 세션으로 전송되는 SLS를 추출한다.

스텝 S152에 있어서, SLS 처리계(114)는 스텝 S151의 처리에서 얻어진 SLS를 파싱한다.

본 명세서에서는, USBD 메타데이터와 MPD 메타데이터가 해석되어, USBD 메타데이터의 globalServiceID 속성에 의해 기술되는 서비스 ID 및 fullMPDUri 속성에 의해 지정되는 URI(MPD 메타데이터의 URL), 그리고 MPD 메타데이터에 기술되는 콘텐츠 ID(EIDR나 Ad-ID) 및 세그먼트 URL이 얻어진다.

스텝 S153에 있어서, SLS 처리계(114)는 스텝 S152의 처리에서 얻어진 해석 결과에 기초하여, 매핑 데이터베이스를 생성한다. 이 매핑 데이터베이스는, 기억부(104)에 기억된다.

이 매핑 데이터베이스는, 클라이언트 장치(20)로부터의 HTTP 리퀘스트에 포함되는 URL이, ATSC3.0 서비스 중 어느 서비스의 DASH 세그먼트에 대응하는 것인지를 해결하기 위한 데이터베이스가 된다.

구체적으로는, 매핑 데이터베이스에서는, 세그먼트 URL을 메인 키로 하여, 서비스 ID, 콘텐츠 ID, MPD 메타데이터의 URL, 및 시각 정보가 대응지어져 있다. 즉, 이 매핑 데이터베이스는, 세그먼트 URL과, 소스 식별 정보의 대응 관계를 저장하고 있다. 또한, 메인 키로서는, 세그먼트 URL에 한하지 않고, 예를 들어, MPD 메타데이터의 BaseURL 요소에 의해 지정되는 베이스 URL 등, URL의 최초의 파트에 매치하는 문자열을 사용하게 해도 된다.

이 매핑 데이터베이스에 의해, SLS 처리계(114)는 클라이언트 장치(20)로부터의 HTTP 리퀘스트의 URL에 따른 속성(소스 식별 정보)을 로컬 프록시(113)에 제공할 수 있다. 바꾸어 말하면, 확장 헤더 삽입 처리를 행할 때, 이 매핑 데이터베이스를 참조함으로써, 확장 헤더를 삽입하기 전에, 대상의 HTTP 리퀘스트의 URL이, ATSC3.0 서비스로 배신된 MPD 메타데이터에 기술된 세그먼트 URL인지 여부를 확인할 수 있다.

여기서, 클라이언트 장치(20)에 있어서, 방송 서비스를 서비스 엔트리로 하여, 통신 경유로 콘텐츠의 배신을 받는 타이밍이 된 경우, 브라우저(212)는 DASH 세그먼트를, 네트워크(30)를 통하여, 게이트웨이 장치(10)에서 가동하는 로컬 프록시(113)에 요구한다(S251).

스텝 S251의 처리에서, 클라이언트 장치(20)에 의해 송신되는 DASH 세그먼트의 HTTP 리퀘스트는, 게이트웨이 장치(10)에서 가동하는 로컬 프록시(113)에 의해 수신된다.

스텝 S161에 있어서, 로컬 프록시(113)는 클라이언트 장치(20)로부터 수신한 HTTP 리퀘스트 헤더의 URL에 의한 조회를, SLS 처리계(114)에 요구한다.

스텝 S154에 있어서, SLS 처리계(114)는 로컬 프록시(113)로부터의 HTTP 리퀘스트 헤더의 URL에 의한 조회에 따라, 기억부(104)에 기억된 매핑 데이터베이스를 참조하고, 당해 HTTP 리퀘스트의 URL에 대응하는 속성(소스 식별 정보)을 회답한다.

여기서, 매핑 데이터베이스에는, 세그먼트 URL을 메인 키로 하여, 서비스 ID, 콘텐츠 ID, MPD 메타데이터의 URL, 및 시각 정보 등의 소스 식별 정보가 저장되어 있으므로, 클라이언트 장치(20)로부터의 HTTP 리퀘스트의 URL에 대응하는 세그먼트 URL에 대응지어진 소스 식별 정보가 취득되어, 당해 HTTP 리퀘스트 헤더의 URL에 대응하는 속성으로서 회답된다.

스텝 S162에 있어서, 로컬 프록시(113)는 클라이언트 장치(20)로부터 수신한 HTTP 리퀘스트 헤더에 대하여 확장 헤더로서, SLS 처리계(114)로부터 회답된 속성(소스 식별 정보)을 삽입한다. 이에 의해, 도 16에 도시한 바와 같이, HTTP 리퀘스트 헤더에는, 서비스 ID, 콘텐츠 ID, MPD 메타데이터의 URL, 및 시각 정보 등의 소스 식별 정보가 삽입되게 된다.

스텝 S163에 있어서, 로컬 프록시(113)는 확장 헤더가 삽입된 HTTP 리퀘스트를, 통신 I/F(102)를 통하여, 인터넷(80)에 접속된 통신 서버(70)로 송신한다.

또한, 통신 서버(70)에서 행하여지는 처리의 상세는, 도 28을 참조하여 후술하겠지만, 간단하게 설명하면 다음과 같이 된다. 즉, 통신 서버(70)는 인터넷(80)을 통하여 게이트웨이 장치(10)로부터 송신되어 오는 HTTP 리퀘스트를 수신한다. 그리고, 통신 서버(70)는 수신한 HTTP 리퀘스트에 따른 DASH 세그먼트 파일을, 인터넷(80)을 통하여, 게이트웨이 장치(10)로 송신한다.

스텝 S164에 있어서, 로컬 프록시(113)는 통신 서버(70)로부터 수신한 DASH 세그먼트 파일을, 통신 I/F(103)를 통하여, 네트워크(30)에 접속된 클라이언트 장치(20)에 전송한다.

스텝 S164의 처리에서, 게이트웨이 장치(10)에 의해 전송되는 DASH 세그먼트 파일은, 네트워크(30)에 접속된 클라이언트 장치(20)에 의해 수신된다.

클라이언트 장치(20)에서는, 브라우저(212)에 의해, 게이트웨이 장치(10)로부터 수신한 DASH 세그먼트 파일이 재생된다(S252). 이에 의해, 클라이언트 장치(20)에 있어서는, 통신 경유로 배신된 프로그램 등의 콘텐츠가 재생되게 된다.

이상, 확장 헤더 삽입 처리의 상세를 설명하였다.

이 확장 헤더 삽입 처리에서는, 게이트웨이 장치(10)에서 가동하는 로컬 프록시(113)에 의해, 클라이언트 장치(20)로부터의 HTTP 리퀘스트에, 확장 헤더(소스 식별 정보)가 삽입되기 때문에, 용이하게, HTTP 리퀘스트 헤더에 대하여 소스 식별 정보를 추가할 수 있다. 즉, 이러한 특수한 헤더를, HTTP 리퀘스트에 추가하는 처리는, 일반적인 DASH 플레이어(브라우저(212))의 실장에 용이하게 추가할 수는 없지만, HTTP 리퀘스트가, 로컬 프록시(113)를 경유하게 함으로써, 확장 헤더 삽입 처리를, 로컬 프록시(113) 상의 모듈이나 서버 사이드 스크립트 등에 의해, 용이하게 실장할 수 있다.

(HTTP 리퀘스트 대응 처리)

이어서, 도 28의 흐름도를 참조하여, 통신 서버(70)에 의해 실행되는 HTTP 리퀘스트 대응 처리의 흐름을 설명한다.

도 28의 흐름도에 나타낸 처리는, 도 17 및 도 18의 프록시 발견·접속 처리와, 확장 헤더 삽입 처리에 있어서의, 스텝 S122의 처리(로컬 프록시(113)의 HTTP 리퀘스트 전송 처리)에 대응하는 처리, 또는, 도 27의 확장 헤더 삽입 처리에 있어서의 스텝 S163의 처리(로컬 프록시(113)의 HTTP 리퀘스트 전송 처리)에 대응하는 처리가 된다.

스텝 S301에 있어서, 통신 서버(70)는 인터넷(80)을 통하여 게이트웨이 장치(10)(의 로컬 프록시(113))로부터 송신되어 오는 HTTP 리퀘스트를 수신한다.

스텝 S302에 있어서, 통신 서버(70)는 스텝 S301의 처리에서 얻어진 HTTP 리퀘스트를 처리한다.

여기서, HTTP 리퀘스트 헤더에는, 서비스 ID나 콘텐츠 ID, MPD 메타데이터의 URL, 시각 정보 등의 소스 식별 정보가 삽입되어 있다. 통신 서버(70)는 HTTP 리퀘스트 헤더에 삽입된 소스 식별 정보에 기초하여, 당해 HTTP 리퀘스트가, 방송 서비스를 도선으로 하여 요구된 리퀘스트임을 인식할 수 있다.

즉, 게이트웨이 장치(10)로부터의 HTTP 리퀘스트에, 확장 헤더로서의 소스 식별 정보가 삽입되어 있지 않은 경우, 통신 서버(70)에 있어서는, 예를 들어, "http(s)://a.com/a.mp4"인 세그먼트 URL의 DASH 세그먼트 파일의 HTTP 리퀘스트가, ATSC3.0 서비스 등의 방송 서비스를 도선(서비스 엔트리)으로 한 것인지 여부를 인식할 수는 없다.

한편, 게이트웨이 장치(10)로부터의 HTTP 리퀘스트에, 확장 헤더로서의 소스 식별 정보가 삽입되어 있는 경우, 통신 서버(70)는 서비스 ID나 콘텐츠 ID, MPD 메타데이터의 URL, 시각 정보 등으로부터, 당해 HTTP 리퀘스트가, ATSC3.0 서비스 등의 방송 서비스를 도선(서비스 엔트리)으로 한 것인지 여부를 인식하는 것이 가능하게 된다.

예를 들어, 방송과 통신을 이용한 사이멀 방송을 행하는 경우나, 방송과 통신으로 각각 전송되는 스트림을 결합하여 얻어지는 콘텐츠의 배신을 행하는 경우 등의, 방송과 통신을 이용한 서비스의 운용을 행하는 경우에, 클라이언트 장치(20)에서는, 방송 서비스를 서비스 엔트리로 하여, 통신 경유로 콘텐츠의 배신을 받는 타이밍이 발생할 때가 있다. 그리고, 이러한 경우에 있어서, 방송 사업자 등의 사업자로부터, 방송 서비스를 도선(서비스 엔트리)으로 하여, 통신 경유로 액세스해 오는 클라이언트 장치(20)를 식별하고 싶다는 요청이 있는데, 그 요청에 따를 수 있다. 예를 들어, 방송 사업자는, ATSC3.0 엔드 디바이스와 일반 엔드 디바이스를 구별하여, 액세스의 통계를 관리하는 운용을, 용이하게 행할 수 있다.

또한, 여기서는, 통신 서버(70)가 CDN의 서버로서 제공되도록 함으로써, 통신 서버(70)에 의해, 콘텐츠의 데이터(DASH 세그먼트 파일)의 배신이 행하여질 때에, 기존의 CDN의 로깅의 기능을 이용하여, DASH 세그먼트의 액세스 통계를 기록한다는 운용이 가능하게 된다. 또한, 통신 서버(70)가 기존의 CDN의 기능을 이용함으로써, 추가 비용을 최소한으로 억제할 수 있다. 또한, 예를 들어, 동일한 콘텐츠를, 다른 CDN의 서버로부터, 배신원의 패스를 바꾸어서 배신하는 운용을 행하는 경우에, 동일한 콘텐츠로부터 생성된 DASH 세그먼트의 시퀀스를, 용이하게 유추할 수 있다.

또한, 상기 「방송과 통신으로 각각 전송되는 스트림을 결합하여 얻어지는 콘텐츠의 배신을 행하는」 운용이란, 예를 들어, 방송 경유로, 베이스 레이어로서, 저품질의 비디오 스트림을 배신함과 함께, 통신 경유로 인핸스먼트 레이어로서, 베이스 레이어로서의 비디오 스트림을 강화하기 위한 부가 정보(상승의 비디오 스트림)를 배신하는 운용이 상당한다. 이에 의해, 클라이언트 장치(20)에서는, 베이스 레이어에 대응한 통상 품질의 영상(예를 들어 2K 해상도의 영상)을 재생할뿐만 아니라, 베이스 레이어와 인핸스먼트 레이어를 결합하여 얻어지는 고품질의 영상(예를 들어 4K 해상도의 영상)을 재생하는 것이 가능하게 된다.

스텝 S303에 있어서, 통신 서버(70)는 스텝 S301의 처리에서 얻어진 HTTP 리퀘스트에 따른 DASH 세그먼트 파일을, 인터넷(80)을 통하여 게이트웨이 장치(10)로 송신한다.

이상, 통신 서버(70)측의 HTTP 리퀘스트 대응 처리의 흐름을 설명하였다.

<6. 변형예>

(다른 방송 규격에의 적용)

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

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

(기타의 변형예)

또한, 상술한 제어 정보(시그널링) 등의 명칭은 일례이며, 다른 명칭이 사용되는 경우가 있다. 단, 이들 명칭의 차이는 형식적인 차이이며, 대상의 제어 정보나 패킷 등의 실질적인 내용이 다른 것은 아니다. 예를 들어, USBD(User Service Bundle Description)는 USD(User Service Description)라고 칭해지는 경우가 있다. 또한, 예를 들어, NRT(Non Real Time)는 LCC(Locally Cached Content) 등으로 칭해지는 경우가 있다.

또한, 제어 정보가, XML 등의 마크업 언어에 의해 기술되는 경우에 있어서, 그들 요소나 속성의 명칭은 일례이며, 다른 명칭이 채용되게 해도 된다. 단, 이들 명칭의 차이는 형식적인 차이이며, 그들의 요소나 속성의 실질적인 내용이 다른 것은 아니다.

또한, DASH 플레이어는, 예를 들어, HTML5(HyperText Markup Language 5) 등의 마크업 언어나 JavaScript(등록 상표) 등의 스크립트 언어로 개발된 어플리케이션 이외에, 예를 들어, Java(등록 상표) 등의 프로그래밍 언어로 개발된 어플리케이션으로 할 수 있다. 또한, 이 어플리케이션은, 브라우저에 의해 실행되는 어플리케이션에 한하지 않고, 소위 네이티브 어플리케이션으로서, 오퍼레이팅 시스템(OS: Operating System) 환경 등에서 실행되게 해도 된다.

또한, 어플리케이션은, 어떠한 정보를 명시적으로 표시할뿐만 아니라, 비표시로(백그라운드에서) 동작되게 해도 된다(엔드 유저에게 인식되지 않고 기동하게 해도 된다). 또한, 콘텐츠는, 동화상이나 음악 이외에, 예를 들어, 전자 서적이나 게임, 광고 등, 모든 콘텐츠를 포함할 수 있다.

<7. 컴퓨터의 구성>

상술한 일련의 처리는, 하드웨어에 의해 실행할 수도 있고, 소프트웨어에 의해 실행할 수도 있다. 일련의 처리를 소프트웨어에 의해 실행하는 경우에는, 그 소프트웨어를 구성하는 프로그램이 컴퓨터에 인스톨된다. 도 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의 컴퓨터(프로세서)에 의해 처리되는 것이어도 되고, 복수의 컴퓨터에 의해 분산 처리되는 것이어도 된다.

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

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

(1)

콘텐츠의 리퀘스트에 대하여, 당해 콘텐츠의 소스의 동일성을 식별하기 위한 식별 정보를 삽입하는 처리부를 구비하는

정보 처리 장치.

(2)

상기 처리부는, 방송 서비스를 서비스 엔트리로 하여, 통신 경유로 상기 리퀘스트가 송신되는 경우에, 상기 리퀘스트에 대하여 상기 식별 정보를 삽입하는

(1)에 기재된 정보 처리 장치.

(3)

상기 식별 정보는, 상기 콘텐츠의 배신원을 식별하기 위한 정보인

(1) 또는 (2)에 기재된 정보 처리 장치.

(4)

상기 식별 정보는, 상기 방송 서비스를 식별하는 식별자를 적어도 포함하는

(3)에 기재된 정보 처리 장치.

(5)

상기 식별 정보는, 상기 콘텐츠를 식별하는 식별자, 상기 콘텐츠의 재생을 제어하는 제어 정보의 취득처를 나타내는 정보, 및 상기 콘텐츠에 관한 시각 정보 중, 적어도 하나의 정보를 더 포함하는

(4)에 기재된 정보 처리 장치.

(6)

상기 처리부는, 프록시로서의 기능을 갖는

(1) 내지 (5) 중 어느 하나에 기재된 정보 처리 장치.

(7)

방송파를 수신하는 수신부와,

인터넷 상의 서버와 통신을 행하는 통신부

를 더 구비하고,

상기 처리부는,

상기 방송파로부터 얻어지는 제어 정보에 기초하여, 상기 식별 정보를 저장한 매핑 데이터베이스를 생성하고,

HTTP(Hypertext Transfer Protocol) 리퀘스트를 상기 서버로 송신하는 경우, 상기 매핑 데이터베이스로부터 얻어지는 상기 식별 정보를, 상기 HTTP 리퀘스트의 리퀘스트 헤더에 삽입하고,

상기 통신부는, 상기 HTTP 리퀘스트를, 상기 인터넷을 통하여, 상기 서버로 송신하는

(6)에 기재된 정보 처리 장치.

(8)

상기 정보 처리 장치는, 네트워크에 접속된 클라이언트 장치에 대하여 방송 경유 또는 통신 경유로 배신되는 콘텐츠를 전송하는 게이트웨이 장치이며,

상기 처리부는, 상기 클라이언트 장치로부터의 HTTP 리퀘스트를 상기 서버로 송신하는 경우, 상기 HTTP 리퀘스트의 리퀘스트 헤더에 상기 식별 정보를 삽입하는

(7)에 기재된 정보 처리 장치.

(9)

상기 정보 처리 장치는, 방송 경유 또는 통신 경유로 배신되는 콘텐츠를 재생하는 클라이언트 장치이며,

상기 처리부는, 상기 클라이언트 장치로부터의 HTTP 리퀘스트, 또는 네트워크에 접속된 다른 클라이언트 장치로부터의 HTTP 리퀘스트를 상기 서버로 송신하는 경우, 상기 HTTP 리퀘스트의 리퀘스트 헤더에 상기 식별 정보를 삽입하는

(7)에 기재된 정보 처리 장치.

(10)

상기 처리부는, 상기 클라이언트 장치와의 접속을 확립하는 경우에, 상기 프록시가 리퀘스트를 대기하는 IP 어드레스와 포트 번호에 관한 접속 정보를 상기 클라이언트 장치에 제공하는

(8)에 기재된 정보 처리 장치.

(11)

상기 클라이언트 장치는, 상기 프록시의 구성을 설정하기 위한 스크립트 파일 내용을, 상기 접속 정보에 의해 재기입하고, 당해 스크립트 파일을 실행함으로써, 상기 프록시와의 접속을 확립하는

(10)에 기재된 정보 처리 장치.

(12)

상기 처리부는, 상기 클라이언트 장치에 의해, 상기 접속 정보를 취득하기 위한 API(Application Programming Interface)가 실행된 경우에, 상기 접속 정보를 상기 클라이언트 장치에 제공하는

(11)에 기재된 정보 처리 장치.

(13)

상기 리퀘스트는, 시큐어한 프로토콜을 사용하여 통신이 행하여지고,

상기 프록시는, 투과형의 프록시(Transparent Proxy)인

(6) 내지 (12) 중 어느 하나에 기재된 정보 처리 장치.

(14)

정보 처리 장치의 데이터 처리 방법에 있어서,

상기 정보 처리 장치가,

콘텐츠의 리퀘스트에 대하여 당해 콘텐츠의 소스의 동일성을 식별하기 위한 식별 정보를 삽입하는 스텝을 포함하는

데이터 처리 방법.

(15)

방송 경유 또는 통신 경유로 배신되는 콘텐츠를 전송하는 게이트웨이 장치와의 접속을 처리하는 처리부와,

상기 게이트웨이 장치로부터, 네트워크를 통하여 전송되어 오는 상기 콘텐츠를 재생하는 재생부

를 구비하고,

상기 게이트웨이 장치는, 프록시로서의 기능을 갖고,

상기 처리부는, 상기 게이트웨이 장치로부터 상기 네트워크를 통하여 제공되는, 상기 프록시가 리퀘스트를 대기하는 IP 어드레스와 포트 번호에 관한 접속 정보에 기초하여, 상기 프록시와의 접속을 확립하는

클라이언트 장치.

(16)

상기 처리부는, 상기 프록시의 구성을 설정하기 위한 스크립트 파일 내용을, 상기 접속 정보에 의해 재기입하고, 당해 스크립트 파일을 실행함으로써, 상기 프록시와의 접속을 확립하는

(15)에 기재된 클라이언트 장치.

(17)

상기 처리부는, 상기 게이트웨이 장치로부터 상기 네트워크를 통하여 제공되는, 상기 접속 정보를 취득하기 위한 API를 실행함으로써, 상기 접속 정보를 취득하는

(16)에 기재된 클라이언트 장치.

(18)

상기 프록시는, 상기 클라이언트 장치로부터의 콘텐츠의 리퀘스트를, 인터넷 상의 서버로 송신하는 경우, 상기 리퀘스트에 대하여 당해 콘텐츠의 소스의 동일성을 식별하기 위한 식별 정보를 삽입하는

(17)에 기재된 클라이언트 장치.

(19)

상기 프록시는, 방송 서비스를 서비스 엔트리로 하여, 통신 경유로 상기 리퀘스트가 송신되는 경우에, 상기 리퀘스트에 대하여 상기 식별 정보를 삽입하는

(18)에 기재된 클라이언트 장치.

(20)

클라이언트 장치의 데이터 처리 방법에 있어서,

상기 클라이언트 장치가,

방송 경유 또는 통신 경유로 배신되는 콘텐츠를 전송하는 게이트웨이 장치와의 접속을 확립하는 경우에, 프록시로서의 기능을 갖는 상기 게이트웨이 장치로부터 네트워크를 통하여 제공되는, 상기 프록시가 리퀘스트를 대기하는 IP 어드레스와 포트 번호에 관한 접속 정보에 기초하여, 상기 프록시와의 접속을 확립하고,

상기 게이트웨이 장치로부터, 상기 네트워크를 통하여 전송되어 오는 상기 콘텐츠를 재생하는

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

1: 전송 시스템
10: 게이트웨이 장치
20-1 내지 20-N, 20: 클라이언트 장치
30: 네트워크
40: 방송 서버
50: 송신소
60: 방송 전송로
70: 통신 서버
80: 인터넷
100: 처리부
101: 튜너
102: 통신 I/F
103: 통신 I/F
104: 기억부
111: UPnP/SSDP 서버
112: 프록시 어플리케이션 매니저
113: 로컬 프록시
114: SLS 처리계
200: 처리부
201: 통신 I/F
202: 표시부
203: 스피커
211: 어플리케이션
212: 브라우저
1000: 컴퓨터
1001: CPU

Claims

방송 스트림으로부터 제어 정보를 취득하는 수신부 - 상기 제어 정보는 상기 방송 스트림의 세션으로부터 취득됨 -;
인터넷 상의 서버와 통신을 행하는 통신부; 및
콘텐츠의 세그먼트 정보를 포함하는 리퀘스트를 상기 서버로 송신하는 처리부 - 상기 처리부는 프록시로서의 기능을 갖고, 방송 서비스를 서비스 엔트리로 하여, 통신 경유로 상기 리퀘스트가 송신되는 경우에 당해 콘텐츠의 소스의 동일성을 식별하기 위한 식별 정보를 상기 리퀘스트에 삽입함 - 를 구비하고, 요청되는 상기 콘텐츠는 상기 식별 정보에 기초하여 상기 서버에 의해 결정될 수 있는
정보 처리 장치.
삭제
제1항에 있어서, 상기 식별 정보는, 상기 콘텐츠의 배신원을 식별하기 위한 정보인
정보 처리 장치.
제3항에 있어서, 상기 식별 정보는, 상기 방송 서비스를 식별하는 식별자를 적어도 포함하는
정보 처리 장치.
제4항에 있어서, 상기 식별 정보는, 상기 콘텐츠를 식별하는 식별자, 상기 콘텐츠의 재생을 제어하는 상기 제어 정보의 취득처를 나타내는 정보, 및 상기 콘텐츠에 관한 시각 정보 중, 적어도 하나의 정보를 더 포함하는
정보 처리 장치.
삭제
제1항에 있어서,
상기 처리부는,
방송파로부터 얻어지는 상기 제어 정보에 기초하여, 상기 식별 정보를 저장한 매핑 데이터베이스를 생성하고,
HTTP(Hypertext Transfer Protocol) 리퀘스트를 상기 서버로 송신하는 경우, 상기 매핑 데이터베이스로부터 얻어지는 상기 식별 정보를, 상기 HTTP 리퀘스트의 리퀘스트 헤더에 삽입하고,
상기 통신부는, 상기 HTTP 리퀘스트를, 상기 인터넷을 통하여, 상기 서버로 송신하는
정보 처리 장치.
제7항에 있어서, 상기 정보 처리 장치는, 네트워크에 접속된 클라이언트 장치에 대하여 방송 경유 또는 통신 경유로 배신되는 콘텐츠를 전송하는 게이트웨이 장치이며,
상기 처리부는, 상기 클라이언트 장치로부터의 HTTP 리퀘스트를 상기 서버로 송신하는 경우, 상기 HTTP 리퀘스트의 리퀘스트 헤더에 상기 식별 정보를 삽입하는
정보 처리 장치.
제7항에 있어서, 상기 정보 처리 장치는, 방송 경유 또는 통신 경유로 배신되는 콘텐츠를 재생하는 클라이언트 장치이며,
상기 처리부는, 상기 클라이언트 장치로부터의 HTTP 리퀘스트, 또는 네트워크에 접속된 다른 클라이언트 장치로부터의 HTTP 리퀘스트를 상기 서버로 송신하는 경우, 상기 HTTP 리퀘스트의 리퀘스트 헤더에 상기 식별 정보를 삽입하는
정보 처리 장치.
제8항에 있어서, 상기 처리부는, 상기 클라이언트 장치와의 접속을 확립하는 경우에, 상기 프록시가 리퀘스트를 대기하는 IP 어드레스와 포트 번호에 관한 접속 정보를 상기 클라이언트 장치에 제공하는
정보 처리 장치.
제10항에 있어서, 상기 클라이언트 장치는, 상기 프록시의 구성을 설정하기 위한 스크립트 파일 내용을, 상기 접속 정보에 의해 재기입하고, 당해 스크립트 파일을 실행함으로써, 상기 프록시와의 접속을 확립하는
정보 처리 장치.
제11항에 있어서, 상기 처리부는, 상기 클라이언트 장치에 의해, 상기 접속 정보를 취득하기 위한 API(Application Programming Interface)가 실행된 경우에, 상기 접속 정보를 상기 클라이언트 장치에 제공하는
정보 처리 장치.
제1항에 있어서, 상기 리퀘스트는, 시큐어한 프로토콜을 사용하여 통신이 행하여지고,
상기 프록시는, 투과형의 프록시(Transparent Proxy)인
정보 처리 장치.
정보 처리 장치에 의해 수행되는 데이터 처리 방법에 있어서,
상기 정보 처리 장치의 수신부에 의해, 방송 스트림으로부터 제어 정보를 취득하는 스텝 - 상기 제어 정보는 상기 방송 스트림의 세션으로부터 취득됨 -;
상기 정보 처리 장치의 통신부에 의해, 인터넷 상의 서버와 통신을 행하는 스텝; 및
상기 정보 처리 장치의 처리부에 의해, 콘텐츠의 세그먼트 정보를 포함하는 리퀘스트를 상기 서버로 송신하고 - 상기 처리부는 프록시로서의 기능을 가짐 -, 방송 서비스를 서비스 엔트리로 하여, 통신 경유로 상기 리퀘스트가 송신되는 경우에 당해 콘텐츠의 소스의 동일성을 식별하기 위한 식별 정보를 상기 리퀘스트에 삽입하는 스텝을 포함하고, 요청되는 상기 콘텐츠는 상기 식별 정보에 기초하여 상기 서버에 의해 결정될 수 있는
정보 처리 장치에 의해 수행되는 데이터 처리 방법.
방송 경유 또는 통신 경유로 배신되는 콘텐츠를 전송하는 게이트웨이 장치와의 접속을 처리하는 처리부와,
상기 게이트웨이 장치로부터, 네트워크를 통하여 전송되어 오는 상기 콘텐츠를 재생하는 재생부
를 구비하고,
상기 게이트웨이 장치는, 프록시로서의 기능을 갖고,
상기 처리부는, 상기 게이트웨이 장치로부터 상기 네트워크를 통하여 제공되는, 상기 프록시가 리퀘스트를 대기하는 IP 어드레스와 포트 번호에 관한 접속 정보에 기초하여, 상기 프록시와의 접속을 확립하고,
상기 게이트웨이 장치는,
방송 스트림으로부터 제어 정보를 취득하고 - 상기 제어 정보는 상기 방송 스트림의 세션으로부터 취득됨 -,
인터넷 상의 서버와 통신을 행하고,
콘텐츠의 세그먼트 정보를 포함하는 리퀘스트를 상기 서버로 송신하고, 방송 서비스를 서비스 엔트리로 하여, 통신 경유로 상기 리퀘스트가 송신되는 경우에 당해 콘텐츠의 소스의 동일성을 식별하기 위한 식별 정보를 상기 리퀘스트에 삽입하고, 요청되는 상기 콘텐츠는 상기 식별 정보에 기초하여 상기 서버에 의해 결정될 수 있는
클라이언트 장치.
제15항에 있어서, 상기 처리부는, 상기 프록시의 구성을 설정하기 위한 스크립트 파일 내용을, 상기 접속 정보에 의해 재기입하고, 당해 스크립트 파일을 실행함으로써, 상기 프록시와의 접속을 확립하는
클라이언트 장치.
제16항에 있어서, 상기 처리부는, 상기 게이트웨이 장치로부터 상기 네트워크를 통하여 제공되는, 상기 접속 정보를 취득하기 위한 API를 실행함으로써, 상기 접속 정보를 취득하는
클라이언트 장치.
삭제
클라이언트 장치의 데이터 처리 방법에 있어서,
상기 클라이언트 장치가,
방송 경유 또는 통신 경유로 배신되는 콘텐츠를 전송하는 게이트웨이 장치와의 접속을 확립하는 경우에, 프록시로서의 기능을 갖는 상기 게이트웨이 장치로부터 네트워크를 통하여 제공되는, 상기 프록시가 리퀘스트를 대기하는 IP 어드레스와 포트 번호에 관한 접속 정보에 기초하여, 상기 프록시와의 접속을 확립하고,
상기 게이트웨이 장치로부터, 상기 네트워크를 통하여 전송되어 오는 상기 콘텐츠를 재생하는
스텝을 포함하고,
상기 게이트웨이 장치는,
방송 스트림으로부터 제어 정보를 취득하고 - 상기 제어 정보는 상기 방송 스트림의 세션으로부터 취득됨 -,
인터넷 상의 서버와 통신을 행하고,
콘텐츠의 세그먼트 정보를 포함하는 리퀘스트를 상기 서버로 송신하고, 방송 서비스를 서비스 엔트리로 하여, 통신 경유로 상기 리퀘스트가 송신되는 경우에 당해 콘텐츠의 소스의 동일성을 식별하기 위한 식별 정보를 상기 리퀘스트에 삽입하고, 요청되는 상기 콘텐츠는 상기 식별 정보에 기초하여 상기 서버에 의해 결정될 수 있는
클라이언트 장치의 데이터 처리 방법.
제1항에 있어서,
상기 세그먼트 정보는 세그먼트 URL이고,
상기 제어 정보는 SLS이고,
상기 세션은 ROUTE 세션인
정보 처리 장치.
제14항에 있어서,
상기 세그먼트 정보는 세그먼트 URL이고,
상기 제어 정보는 SLS이고,
상기 세션은 ROUTE 세션인
정보 처리 장치에 의해 수행되는 데이터 처리 방법.
제15항에 있어서,
상기 세그먼트 정보는 세그먼트 URL이고,
상기 제어 정보는 SLS이고,
상기 세션은 ROUTE 세션인
클라이언트 장치.
제19항에 있어서,
상기 세그먼트 정보는 세그먼트 URL이고,
상기 제어 정보는 SLS이고,
상기 세션은 ROUTE 세션인
클라이언트 장치의 데이터 처리 방법.