KR20190029572A - 정보 처리 장치 및 정보 처리 방법 - Google Patents

정보 처리 장치 및 정보 처리 방법 Download PDF

Info

Publication number
KR20190029572A
KR20190029572A KR1020197000156A KR20197000156A KR20190029572A KR 20190029572 A KR20190029572 A KR 20190029572A KR 1020197000156 A KR1020197000156 A KR 1020197000156A KR 20197000156 A KR20197000156 A KR 20197000156A KR 20190029572 A KR20190029572 A KR 20190029572A
Authority
KR
South Korea
Prior art keywords
information
viewing history
information processing
content
compliant
Prior art date
Application number
KR1020197000156A
Other languages
English (en)
Inventor
야스아키 야마기시
Original Assignee
소니 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 소니 주식회사 filed Critical 소니 주식회사
Publication of KR20190029572A publication Critical patent/KR20190029572A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25891—Management of end-user data being end-user preferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/02—Arrangements for relaying broadcast information
    • H04H20/08—Arrangements for relaying broadcast information among terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/29—Arrangements for monitoring broadcast services or broadcast-related services
    • H04H60/31—Arrangements for monitoring the use made of the broadcast services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/61—Arrangements for services using the result of monitoring, identification or recognition covered by groups H04H60/29-H04H60/54
    • H04H60/66—Arrangements for services using the result of monitoring, identification or recognition covered by groups H04H60/29-H04H60/54 for using the result on distributors' side
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
    • H04H60/81—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself
    • H04H60/82—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself the transmission system being the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N17/00—Diagnosis, testing or measuring for television systems or their details
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44213—Monitoring of end-user related data
    • H04N21/44222—Analytics of user selections, e.g. selection of programs or purchase activity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/4508—Management of client data or end-user data
    • H04N21/4516—Management of client data or end-user data involving client characteristics, e.g. Set-Top-Box type, software version or amount of memory available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/4508—Management of client data or end-user data
    • H04N21/4532—Management of client data or end-user data involving end-user characteristics, e.g. viewer profile, preferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Multimedia (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Social Psychology (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Graphics (AREA)
  • Biomedical Technology (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
  • Circuits Of Receivers In General (AREA)

Abstract

본 기술은, 시청 이력에 관한 운용을 유연하게 행할 수 있도록 하는 정보 처리 장치 및 정보 처리 방법에 관한 것이다. 정보 처리 장치는, 디지털 방송의 콘텐츠의 시청 이력에 관한 시청 이력 정보이며, 콘텐츠를 재생한 기기가, 디지털 방송의 규격에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보를 포함하는 시청 이력 정보를 생성함으로써, 시청 이력에 관한 운용을 유연하게 행할 수 있다. 본 기술은, 예를 들어 시청 이력에 관한 운용의 대상으로 되는 기기에 적용할 수 있다.

Description

정보 처리 장치 및 정보 처리 방법
본 기술은 정보 처리 장치 및 정보 처리 방법에 관한 것이며, 특히 시청 이력에 관한 운용을 유연하게 행할 수 있도록 한 정보 처리 장치 및 정보 처리 방법에 관한 것이다.
방송 분야에서는, 유저에 의한 콘텐츠의 시청 이력을 수집하여 분석하는 등의, 시청 이력에 관한 운용이 행해지는 경우가 있다. 예를 들어 시청 이력을 정기적으로, 또는 필요할 때 전송하는 기술이 개시되어 있다(예를 들어 특허문헌 1 참조).
일본 특허 공개 제2009-278651호 공보
ATSC Candidate Standard: Service Usage Reporting(A/333) Doc. S33-170r316 May 2016 ATSC Candidate Standard: Signaling, Delivery, Synchronization, and Error Protection(A/331) Doc. S33-174r15 January 2016
그런데 시청 이력에 관한 운용을 행하기 위한 기술 방식이 확립되어 있지 않기 때문에, 시청 이력에 관한 운용을 유연하게 행하기 위한 제안이 요청되고 있었다.
본 기술은 이와 같은 상황을 감안하여 이루어진 것이며, 시청 이력에 관한 운용을 유연하게 행할 수 있도록 하는 것이다.
본 기술의 제1 측면의 정보 처리 장치는, 디지털 방송의 콘텐츠의 시청 이력에 관한 시청 이력 정보이며, 상기 콘텐츠를 재생한 기기가, 상기 디지털 방송의 규격에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보를 포함하는 상기 시청 이력 정보를 생성하는 시청 이력 처리부를 구비하는 정보 처리 장치이다.
본 기술의 제1 측면의 정보 처리 장치는 독립된 장치여도 되고, 하나의 장치를 구성하고 있는 내부 블록이어도 된다. 또한 본 기술의 제1 측면의 정보 처리 방법은, 상술한 본 기술의 제1 측면의 정보 처리 장치에 대응하는 정보 처리 방법이다.
본 기술의 제1 측면의 정보 처리 장치 및 정보 처리 방법에 있어서는, 디지털 방송의 콘텐츠의 시청 이력에 관한 시청 이력 정보이며, 상기 콘텐츠를 재생한 기기가, 상기 디지털 방송의 규격에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보를 포함하는 상기 시청 이력 정보가 생성된다.
본 기술의 제2 측면의 정보 처리 장치는, 디지털 방송의 콘텐츠의 시청 이력에 관한 시청 이력 정보이며, 상기 콘텐츠를 재생한 기기가, 상기 디지털 방송의 규격에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보를 포함하는 상기 시청 이력 정보를 수신하는 수신부와, 복수의 기기로부터의 상기 시청 이력 정보를 수집하고, 수집된 복수의 상기 시청 이력 정보를 상기 기기 정보에 따라 처리하는 처리부를 구비하는 정보 처리 장치이다.
본 기술의 제2 측면의 정보 처리 장치는 독립된 장치여도 되고, 하나의 장치를 구성하고 있는 내부 블록이어도 된다. 또한 본 기술의 제2 측면의 정보 처리 방법은, 상술한 본 기술의 제2 측면의 정보 처리 장치에 대응하는 정보 처리 방법이다.
본 기술의 제2 측면의 정보 처리 장치 및 정보 처리 방법에 있어서는, 디지털 방송의 콘텐츠의 시청 이력에 관한 시청 이력 정보이며, 상기 콘텐츠를 재생한 기기가, 상기 디지털 방송의 규격에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보를 포함하는 상기 시청 이력 정보가 수신되고, 복수의 기기로부터의 상기 시청 이력 정보가 수집되고, 수집된 복수의 상기 시청 이력 정보가 상기 기기 정보에 따라 처리된다.
본 기술의 제1 측면 및 제2 측면에 의하면, 시청 이력에 관한 운용을 유연하게 행할 수 있다.
또한 여기에 기재된 효과는 반드시 한정되는 것은 아니며, 본 개시 중에 기재된 어느 효과여도 된다.
도 1은 IP 전송 방식에 대응한 프로토콜 스택의 예를 도시하는 도면이다.
도 2는 IP 전송 방식에 대응한 전송 시스템의 구성을 도시하는 도면이다.
도 3은 현행의 CDM의 포맷의 예를 나타내는 도면이다.
도 4는 DeviceInfo의 상세한 내용을 설명하는 도면이다.
도 5는 본 기술을 적용한 전송 시스템의 일 실시 형태의 구성을 도시하는 도면이다.
도 6은 본 기술의 CDM의 포맷의 예를 나타내는 도면이다.
도 7은 ATSC 3.0 비대응 기기의 CDM의 기재예를 나타내는 도면이다.
도 8은 ATSC 3.0 비대응 기기의 CDM의 기재예를 나타내는 도면이다.
도 9는 CDM의 JSON 스키마의 예를 나타내는 도면이다.
도 10은 CDM의 JSON 스키마의 예를 나타내는 도면이다.
도 11은 CDM의 JSON 스키마의 예를 나타내는 도면이다.
도 12는 CDM의 JSON 스키마의 예를 나타내는 도면이다.
도 13은 UR 서버와 UR 클라이언트 사이의 프로토콜의 예를 도시하는 도면이다.
도 14는 UR 서버의 구성예를 도시하는 도면이다.
도 15는 SLT의 포맷의 예를 나타내는 도면이다.
도 16은 urlType 속성의 속성값의 예를 나타내는 도면이다.
도 17은 시청 이력 정보 대응 처리의 흐름을 설명하는 흐름도이다.
도 18은 시청 이력 정보 대응 처리의 흐름을 설명하는 흐름도이다.
도 19는 ATSC 3.0 대응 기기의 CDM의 기재예를 나타내는 도면이다.
도 20은 컴퓨터의 구성예를 도시하는 도면이다.
이하, 도면을 참조하면서 본 기술의 실시 형태에 대하여 설명한다. 또한 설명은 이하의 순서로 행하기로 한다.
1. 본 기술의 개요
2. 시스템의 구성
3. 본 기술의 시청 이력 정보(CDM)
4. Usage Reporting 장치 간의 프로토콜
5. 시청 이력 정보 대응 처리의 흐름
6. 변형예
7. 컴퓨터의 구성
<1. 본 기술의 개요>
디지털 방송의 전송 방식으로서, 현 상황에서는 MPEG2-TS(Transport Stream) 방식이 널리 보급되어 있지만, 앞으로는 통신의 분야에서 이용되고 있는 IP(Internet Protocol) 패킷을 디지털 방송에 이용한 IP 전송 방식이 보급될 것이 상정되어 있다. 예를 들어 차세대 지상파 방송 규격의 하나인 ATSC(Advanced Television Systems Committee) 3.0에 있어서도, IP 전송 방식을 채용하여 보다 고도의 서비스를 제공할 수 있도록 할 것이 기대되고 있다.
(프로토콜 스택의 예)
도 1은, IP 전송 방식에 대응한 프로토콜 스택의 예를 도시하는 도면이다.
도 1의 프로토콜 스택에 있어서, 물리층(PHY: Physical Layer)과 MAC층의 상위의 계층은 UDP/IP층으로 한다. UDP/IP층은 통신의 계층 모델에 있어서의 네트워크층과 트랜스포트층에 상당하는 층이며, IP 어드레스와 포트 번호에 의하여 IP 패킷과 UDP(User Datagram Protocol) 패킷이 특정된다.
여기서, ATSC 3.0에서는 시그널링으로서 LLS(Low Level Signaling)와 SLS(Service Layer Signaling)를 이용할 것이 상정되어 있다. LLS는 SLS보다도 하위의 층에서 전송되는 시그널링이다. SLS는 서비스 단위의 시그널링이다. 즉, ATSC 3.0에서는, 트랜스포트층의 시그널링이 LLS와 SLS의 2계층으로 전송된다.
LLS는 UDP/IP 패킷에 저장되어 전송된다. LLS에는 SLT(Service List Table) 등의 메타데이터가 포함된다. SLT 메타데이터는, 서비스(채널)의 선국에 필요한 정보 등, 방송 네트워크에 있어서의 스트림이나 서비스의 구성을 나타내는 기본 정보를 포함한다. 이 SLT 메타데이터는, UDP 패킷을 포함하는 IP 패킷인 UDP/IP 패킷에 포함하여 전송된다.
UDP/IP층에 인접하는 상위의 계층은 ROUTE(Real-time Object Delivery over Unidirectional Transport)로 한다. ROUTE는 스트리밍 파일 전송용 프로토콜이며, FLUTE(File Delivery over Unidirectional Transport)를 확장한 것이다.
이 ROUTE 세션에 의하여, 서비스(Service)별로 SLS의 파일(Service Signaling File)이나, DASH 세그먼트의 파일(Audio/Video/CC DASH File), LCC(Locally Cached Content)의 파일(LCC(NRT) File) 등이 전송된다.
SLS는 서비스 레벨의 시그널링이며, 대상 서비스에 속하는 컴포넌트의 탐색과 선택에 필요한 정보나 속성 등을 제공하는 것이다. SLS는 USBD(User Service Bundle Description), S-TSID(Service-based Transport Session Instance Description), MPD(Media Presentation Description) 등의 메타데이터를 포함한다.
USBD 메타데이터는 다른 메타데이터의 취득처 등의 정보를 포함한다.
S-TSID 메타데이터는 LSID(LCT Session Instance Description)를 ATSC 3.0용으로 확장한 것이며, ROUTE 프로토콜의 제어 정보이다. 또한 S-TSID 메타데이터는 ROUTE 세션으로 전송되는 EFDT(Extended FDT)를 특정할 수 있다. EFDT는 FLUTE에서 도입되고 있던 FDT(File Delivery Table)를 확장한 것이며, 전송용 제어 정보이다.
MPD 메타데이터는, MPEG-DASH에 준거한 스트리밍 배신을 행하기 위하여 이용되는, 비디오나 오디오의 파일의 제어 정보이다. 여기서, 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)의 파생 포맷이다. ISO BMFF는, 박스(Box)라 칭해지는 트리형 구조로 구성된다.
ROUTE 세션으로 전송되는 세그먼트는 이니셜라이제이션 세그먼트(IS: Initialization Segment)와 미디어 세그먼트(MS: Media Segment)로 구성된다. 이니셜라이제이션 세그먼트는 데이터 압축 방식 등의 초기화 정보를 포함하고 있다. 또한 미디어 세그먼트는 비디오나 오디오, 자막의 스트림 데이터를 저장하고 있다. 또한 이 미디어 세그먼트가 DASH 세그먼트(DASH 세그먼트 파일)에 상당하는 것이다.
또한 LLS로서의 SLT 메타 데이터와 SLS로서의 USBD, S-TSID, MPD 등의 메타데이터는, 예를 들어 XML(Extensible Markup Language) 등의 마크업 언어에 의하여 기재된 텍스트 형식의 데이터로 할 수 있다.
이와 같이, ROUTE 세션으로 전송되는, 비디오, 오디오 및 자막의 스트림과 SLS의 스트림과 LCC 콘텐츠의 스트림은 UDP/IP 패킷에 저장되어 전송된다. 또한 LCC 콘텐츠는 수신기의 스토리지에 일단 축적된 후에 재생이 행해진다. 또한 LCC 콘텐츠 이외의 파일(예를 들어 어플리케이션의 파일)이 ROUTE 세션으로 전송되도록 해도 된다.
(전송 시스템의 구성)
도 2는, IP 전송 방식에 대응한 전송 시스템의 구성을 도시하는 도면이다. 여기서는, IP 전송 방식의 일례로서, ATSC 3.0에 대응한 전송 시스템의 실장 모델을 설명한다. 또한 시스템이란, 복수의 장치가 논리적으로 집합된 것을 말한다.
도 2의 전송 시스템은 송신 시스템(10), 대응 클라이언트 장치(20) 및 비대응 클라이언트 장치(30)로 구성된다. 대응 클라이언트 장치(20)는 인터넷(60)을 통하여 송신 시스템(10)과 서로 접속된다. 또한 대응 클라이언트 장치(20)는 가정 내 LAN(Local Area Network) 등의 LAN(70)을 통하여 비대응 클라이언트 장치(30)와 서로 접속된다.
송신 시스템(10)은, 텔레비전 프로그램 등의 콘텐츠를 소정의 전송로를 통하여 배신하기 위한 시스템이다. 여기서, 전송로로서는 지상파 등의 방송 전송로 외에 인터넷(60) 등의 통신 전송로가 있다.
송신 시스템(10)은 텔레비전 프로그램 등의 콘텐츠를 ATSC 3.0에 준거한 데이터로서 처리하고, 디지털 방송의 방송파로서 중계국(50)을 통하여 복수의 대응 클라이언트 장치(20)에 송신(일제 동보 배신)한다. 또한 송신 시스템(10)은 텔레비전 프로그램 등의 콘텐츠를, 스트리밍 배신하기 위한 데이터로서 처리하고, 인터넷(60)을 통하여 대응 클라이언트 장치(20)에 송신(스트리밍 배신)한다.
대응 클라이언트 장치(20)는, ATSC 3.0에 준거한 데이터를 처리 가능한 전자 기기(ATSC 3.0 대응 기기)이다. 예를 들어 대응 클라이언트 장치(20)는, 텔레비전 수상기나 게이트웨이, 네트워크 스토리지, 셋톱 박스 등의 고정 수신기를 포함한다.
대응 클라이언트 장치(20)는 제어부(200), 방송 미들웨어(201), HTTP 프록시 서버(202), 브라우저(203) 및 통신 I/F(204-1, 204-2)로 구성된다.
제어부(200)는, 예를 들어 CPU(Central Processing Unit)나 마이크로프로세서 등으로 구성된다. 제어부(200)는 대응 클라이언트 장치(20)의 각 부의 동작을 제어한다.
방송 미들웨어(201)는, 방송계 수신 스택이 실장된 클라이언트 로컬 ATSC 미들웨어(Client Local ATSC Middleware)이다. 방송 미들웨어(201)는, 제어부(200)로부터의 제어에 따라, 송신 시스템(10)으로부터의 디지털 방송의 방송파를 수신하고, 방송파로부터 얻어지는 데이터를 처리한다.
방송 미들웨어(201)는 PHY·MAC 처리부(211), LLS 리트리버(212), LLS 파서(213), SLS 리트리버(214), SLS 파서(215) 및 세그먼트 리트리버(216)로 구성된다.
PHY·MAC 처리부(211)는, 예를 들어 튜너나 디모듈레이터 등으로 구성된다. PHY·MAC 처리부(211)는, 방송파로부터 얻어지는 물리층 프레임에 대한 처리를 행한다. 이 물리층 프레임의 데이터부로부터 ALP(ATSC Link-Layer Protocol) 패킷이 추출되고, 또한 ALP 패킷의 페이로드로부터 UDP/IP 패킷이 얻어진다.
LLS 리트리버(212)는, PHY·MAC 처리부(211)에서 처리된 데이터로부터, UDP/IP 패킷에 포함되는 LLS(SLT 메타데이터)를 취득하여 LLS 파서(213)에 공급한다. LLS 파서(213)는, LLS 리트리버(212)로부터의 LLS(SLT 메타데이터)에 대한 구문 해석을 행하고, 그 해석 결과를 SLS 리트리버(214)에 공급한다.
SLS 리트리버(214)는, LLS 파서(213)로부터의 LLS의 해석 결과에 기초하여, PHY·MAC 처리부(211)에서 처리된 데이터로부터, UDP/IP 패킷(에 포함되는 LCT 패킷)으로서 전송되는 ROUTE 세션의 스트림에 포함되는 SLS(USBD, S-TSID 등의 메타데이터)를 취득하여 SLS 파서(215)에 공급한다.
SLS 파서(215)는, SLS 리트리버(214)로부터의 SLS(USBD, S-TSID 등의 메타데이터)에 대한 구문 해석을 행하고, 그 해석 결과를 세그먼트 리트리버(216) 및 HTTP 프록시 서버(202)(의 프록시 캐시(221))에 공급한다.
세그먼트 리트리버(216)는, SLS 파서(215)로부터의 SLS의 해석 결과에 기초하여, PHY·MAC 처리부(211)에서 처리된 데이터로부터, UDP/IP 패킷(에 포함되는 LCT 패킷)으로서 전송되는 ROUTE 세션의 스트림에 포함되는 DASH 세그먼트 파일을 취득하여 HTTP 프록시 서버(202)(의 프록시 캐시(221))에 공급한다.
HTTP 프록시 서버(202)는, 대응 클라이언트 장치(20) 상에 실장된 클라이언트 로컬 HTTP 프록시 서버(Client Local HTTP Proxy Server)이다. HTTP 프록시 서버(202)는, 제어부(200)로부터의 제어에 따라, 방송계 수신 처리를 행하는 방송 미들웨어(201) 또는 통신계 수신 처리를 행하는 통신 I/F(204-1)에 의하여 수신된 DASH 세그먼트 파일이나 SLS의 파일을, 콘텐츠의 재생을 행하는 어플리케이션에 공급한다.
HTTP 프록시 서버(202)는 프록시 캐시(221), 프록시 캐시(222) 및 방송·통신 어드레스 리졸버(223)로 구성된다.
프록시 캐시(221)는, 방송 미들웨어(201)로부터의 DASH 세그먼트나 MPD 메타데이터의 파일을 취득한다. 프록시 캐시(222)는, 통신 I/F(204-1)에 의하여 수신된 DASH 세그먼트나 MPD 메타데이터의 파일을 취득한다. 또한 통신 I/F(204-1)는, 제어부(200)로부터의 제어에 따라, 인터넷(60)을 통하여, 송신 시스템(10)으로부터 스트리밍 배신된 데이터로서, DASH 세그먼트나 MPD 메타데이터의 파일을 수신한다.
방송·통신 어드레스 리졸버(223)는, ATSC 3.0 클라이언트 어플리케이션(예를 들어 DASH 클라이언트(231)나 DASH 클라이언트(311))으로부터의 요구에 따라, 프록시 캐시(221) 또는 프록시 캐시(222)에 의하여 취득된 DASH 세그먼트나 MPD 메타데이터의 파일을 브라우저(203) 또는 통신 I/F(204-2)에 공급한다.
구체적으로는, ATSC 3.0 클라이언트 어플리케이션이 DASH 세그먼트나 MPD 메타데이터의 파일 군을 요구(HTTP 리퀘스트)하면, 그것을 받은 HTTP 프록시 서버(202)에서는, 방송·통신 어드레스 리졸버(223)가 방송 경유로(방송 수신 스택을 통하여) 취득할지, 또는 통신 경유로(통신 수신 스택을 통하여) 취득할지의 판단을 행한다.
이 판단의 재료로 되는 정보는 SLS 파서(215)로부터 공급된다. 즉, SLS 파서(215)는 SLS 리트리버(214)에 대하여 USBD 메타데이터나 T-TSID 메타데이터 등의 취득 요구를 행한다. SLS 리트리버(214)는, PHY·MAC 처리부(211)를 통하여 수신되는 SLS의 LCT 패킷에 포함되는 시그널링 메타를 추출한다.
SLS 파서(215)는, ATSC 3.0 클라이언트 어플리케이션으로부터의 요구에 포함되는 URL(Uniform Resource Locator)로부터, LCT 패킷에 포함되는 시그널링 메타를 빼서, 대상으로 되는 파일 군을 취득하기 위한 방송 배신 어드레스 정보를 해결한다. 그리고 방송 경유로 배신되는 것을 알게 되면, 그 방송 배신 어드레스 정보에 기초하여, 세그먼트 리트리버(216)이, DASH 세그먼트 파일을 포함하는 LCT 패킷을, ROUTE 세션의 스트림으로부터 취득하여, HTTP 프록시 서버(202)의 프록시 캐시(221) 내에 전개한다.
HTTP 프록시 서버(202)는, 이와 같이 하여 프록시 캐시(221) 내에 전개된 파일 군을, ATSC 3.0 클라이언트 어플리케이션으로부터의 요구(HTTP 리퀘스트)에 대한 응답(HTTP 리스폰스)으로서 회신한다.
또한 ATSC 3.0 클라이언트 어플리케이션으로부터의 요구에 포함되는 URL이 LCT 패킷의 시그널링 메타에 존재하지 않는 경우에는, HTTP 프록시 서버(202)는, 프록시 캐시(222) 내에 전개된, 통신 수신 스택을 통하여 취득된 파일 군을, ATSC 3.0 클라이언트 어플리케이션으로부터의 요구(HTTP 리퀘스트)에 대한 응답(HTTP 리스폰스)으로서 회신한다.
브라우저(203)는, 예를 들어 HTML5(HyperText Markup Language 5)에 대응한 브라우저이다. 브라우저(203)는, 제어부(200)로부터의 제어에 따라, 방송·통신 어드레스 리졸버(223)로부터의 DASH 세그먼트나 MPD 메타데이터의 파일을 처리하고, 송신 시스템(10)으로부터 배신된 콘텐츠를 재생한다.
브라우저(203)는 DASH 클라이언트(231), 디코더(232) 및 렌더러(233)로 구성된다. 또한 DASH 클라이언트(231)는 MPD 리트리버(241), MPD 파서(242), 세그먼트 리트리버(243) 및 MP4 파서(244)로 구성된다.
DASH 클라이언트(231)는, 대응 클라이언트 장치(20) 상에 실장된 브라우저(203)에 의하여 실행되는 ATSC 3.0 클라이언트 어플리케이션(ATSC 3.0 DASH Client)이다. DASH 클라이언트(231)는, HTTP 프록시 서버(202)를 통하여, 방송 미들웨어(201) 또는 통신 I/F(204-1)에 의하여 수신된 DASH 세그먼트나 MPD 메타데이터의 파일을 처리한다. 또한 DASH 클라이언트(231)는 브라우저(203) 상에서 실행되는 어플리케이션에 한하지 않고, 소위 네이티브 어플리케이션으로서 제공되도록 해도 된다.
MPD 리트리버(241)는, HTTP 프록시 서버(202)(의 방송·통신 어드레스 리졸버(223))로부터 공급되는 데이터로부터 MPD 메타데이터의 파일을 취득하여 MPD 파서(242)에 공급한다. MPD 파서(242)는, MPD 리트리버(241)로부터의 MPD 메타데이터에 대한 구문 해석을 행하고, 그 해석 결과를 세그먼트 리트리버(243)에 공급한다.
세그먼트 리트리버(243)는, MPD 파서(242)로부터의 MPD 메타데이터의 해석 결과에 기초하여, HTTP 프록시 서버(202)(의 방송·통신 어드레스 리졸버(223))로부터 공급되는 데이터로부터 DASH 세그먼트 파일을 취득하여 MP4 파서(244)에 공급한다.
MP4 파서(244)는, 세그먼트 리트리버(243)로부터의 DASH 세그먼트 파일(세그먼트)에 대한 구문 해석을 행하고, 그 해석 결과를 DASH 세그먼트 파일과 함께 디코더(232)에 공급한다.
디코더(232)는, MP4 파서(244)로부터의 해석 결과에 따라, DASH 세그먼트 파일로부터 얻어지는 데이터의 디코딩을 행하고, 그 결과 얻어지는 복호 후의 데이터를 렌더러(233)에 공급한다. 렌더러(233)는 디코더(232)로부터의 복호 후의 데이터에 대하여 렌더링 처리를 행한다.
이 렌더링 처리에서 얻어지는 비디오 데이터에 대응하는 영상이 LCD(Liquid Crystal Display)나 OELD(Organic Electroluminescence Display) 등의 디스플레이에 표시되고, 오디오 데이터에 대응하는 음성이 스피커로부터 출력된다. 또한 디스플레이나 스피커는 대응 클라이언트 장치(20)가 구비하도록 해도 되고, 또는 외부의 장치가 구비하도록 해도 된다.
통신 I/F(204-2)는, 제어부(200)로부터의 제어에 따라, 가정 내 LAN 등의 LAN(70)을 통하여, 비대응 클라이언트 장치(30)와의 사이에서 데이터의 주고받기를 행한다. 또한 도 2에서는, 설명의 편의상 통신 I/F(204-2)는 통신 I/F(204-1)와 별개로 마련되는 것으로 하여 설명하고 있지만, 통신 I/F(204-1)와 통신 I/F(204-2)를 하나의 통신 인터페이스 회로로서 구성하도록 해도 된다.
예를 들어 통신 I/F(204-2)는, LAN(70)을 통하여 비대응 클라이언트 장치(30)로부터 콘텐츠의 배신이 요구된 경우, 그 요구를 HTTP 프록시 서버(202)(의 방송·통신 어드레스 리졸버(223))에 공급한다.
방송·통신 어드레스 리졸버(223)는 통신 I/F(204-2)로부터의 요구(HTTP 리퀘스트)에 따라, 프록시 캐시(221) 또는 프록시 캐시(222)에 의하여 취득된 DASH 세그먼트나 MPD 메타데이터의 파일을 통신 I/F(204-2)에 공급한다. 그리고 통신 I/F(204-2)는, 방송·통신 어드레스 리졸버(223)로부터의 DASH 세그먼트나 MPD 메타데이터의 파일을 LAN(70)을 통하여 비대응 클라이언트 장치(30)에 송신한다.
비대응 클라이언트 장치(30)는, ATSC 3.0에 준거한 데이터를 처리하지 못하는 전자 기기(ATSC 3.0 비대응 기기)이다. 예를 들어 비대응 클라이언트 장치(30)는 스마트폰이나 휴대 전화기, 태블릿형 컴퓨터 등의 모바일 수신기를 포함한다.
비대응 클라이언트 장치(30)는 제어부(300), 통신 I/F(301) 및 브라우저(302)를 포함하여 구성된다.
제어부(300)는, 예를 들어 CPU나 마이크로프로세서 등으로 구성된다. 제어부(300)는 비대응 클라이언트 장치(30)의 각 부의 동작을 제어한다.
통신 I/F(301)는, 예를 들어 통신 인터페이스 회로 등으로 구성된다. 통신 I/F(301)는 제어부(300)로부터의 제어에 따라, 가정 내 LAN 등의 LAN(70)을 통하여 대응 클라이언트 장치(20)와의 사이에서 데이터의 주고받기를 행한다.
예를 들어 통신 I/F(301)는, 대응 클라이언트 장치(20)에 대하여 콘텐츠의 배신을 요구하는 경우, 그 요구(HTTP 리퀘스트)를 LAN(70)을 통하여 대응 클라이언트 장치(20)에 송신한다. 이것에 의하여, 통신 I/F(301)는 LAN(70)을 통하여 대응 클라이언트 장치(20)로부터 송신되어 오는 DASH 세그먼트나 MPD 메타데이터의 파일을 수신하여 브라우저(302)에 공급한다.
브라우저(302)는, 예를 들어 HTML5에 대응한 브라우저이다. 브라우저(302)는, 제어부(300)로부터의 제어에 따라, 통신 I/F(301)로부터의 DASH 세그먼트나 MPD 메타데이터의 파일을 처리하고, 대응 클라이언트 장치(20)로부터 송신되어 오는 콘텐츠를 재생한다. 또한 대응 클라이언트 장치(20)로부터 송신되어 오는 콘텐츠는 송신 시스템(10)에 의하여 배신된 콘텐츠로 된다.
브라우저(302)는 DASH 클라이언트(311), 디코더(312) 및 렌더러(313)로 구성된다. 또한 DASH 클라이언트(311)는, MPD 리트리버(321), MPD 파서(322), 세그먼트 리트리버(323) 및 MP4 파서(324)로 구성된다.
DASH 클라이언트(311)는, 비대응 클라이언트 장치(30) 상에 실장된 브라우저(302)에 의하여 실행되는 ATSC 3.0 클라이언트 어플리케이션(ATSC 3.0 DASH Client)이다. DASH 클라이언트(311)는, 통신 I/F(301)에 의하여 수신된 DASH 세그먼트나 MPD 메타데이터의 파일을 처리한다. 또한 DASH 클라이언트(311)는, 브라우저(302) 상에서 실행되는 어플리케이션에 한하지 않고 소위 네이티브 어플리케이션으로서 제공되도록 해도 된다.
MPD 리트리버(321)는, 통신 I/F(301)로부터 공급되는 데이터로부터 MPD 메타데이터의 파일을 취득하여 MPD 파서(322)에 공급한다. MPD 파서(322)는, MPD 리트리버(321)로부터의 MPD 메타데이터에 대한 구문 해석을 행하고, 그 해석 결과를 세그먼트 리트리버(323)에 공급한다.
세그먼트 리트리버(323)는, MPD 파서(322)로부터의 MPD 메타데이터의 해석 결과에 기초하여, 통신 I/F(301)로부터 공급되는 데이터로부터 DASH 세그먼트 파일을 취득하여 MP4 파서(324)에 공급한다.
MP4 파서(324)는, 세그먼트 리트리버(323)로부터의 DASH 세그먼트 파일(세그먼트)에 대한 구문 해석을 행하고, 그 해석 결과를 DASH 세그먼트 파일과 함께 디코더(312)에 공급한다.
디코더(312)는, MP4 파서(324)로부터의 해석 결과에 따라, DASH 세그먼트 파일로부터 얻어지는 데이터의 디코딩을 행하고, 그 결과 얻어지는 복호 후의 데이터를 렌더러(313)에 공급한다. 렌더러(313)는, 디코더(312)로부터의 복호 후의 데이터에 대하여 렌더링 처리를 행한다.
이 렌더링 처리에서 얻어지는 비디오 데이터에 대응하는 영상이 LCD나 OELD 등의 디스플레이에 표시되고, 오디오 데이터에 대응하는 음성이 스피커로부터 출력된다. 또한 디스플레이나 스피커는 비대응 클라이언트 장치(30)가 구비하도록 해도 되고, 또는 외부의 장치가 구비하도록 해도 된다.
IP 전송 방식에 대응한 전송 시스템은 이상과 같이 구성된다.
이 전송 시스템에 있어서는, ATSC 3.0에 준거한 송신 시스템(10)으로부터 배신되는 콘텐츠를, ATSC 3.0 대응 기기인 대응 클라이언트 장치(20)뿐 아니라 ATSC 3.0 비대응 기기인 비대응 클라이언트 장치(30)도 재생하는 것이 가능해진다.
즉, 비대응 클라이언트 장치(30)는 ATSC 3.0에 준거한 데이터를 처리할 수는 없지만, ATSC 3.0 클라이언트 어플리케이션으로서의 DASH 클라이언트(311)을 탑재할 수는 있다. 그리고 이 DASH 클라이언트(311)에 의하여, 대응 클라이언트 장치(20)에서 얻어지는 DASH 세그먼트나 MPD 메타데이터의 파일을 처리함으로써, 송신 시스템(10)으로부터 배신되는 콘텐츠를 재생하는 것이 가능해진다.
또한 이때, ATSC 3.0 클라이언트 어플리케이션으로서의 DASH 클라이언트(231)나 DASH 클라이언트(311)측에서 보면, 반드시 대응 클라이언트 장치(20)의 HTTP 프록시 서버(202)를 통하여 외부로부터의 데이터에 액세스하게 된다. 또한 LAN(70) 상의 비대응 클라이언트 장치(30)로부터의 HTTP 리퀘스트가 모두 HTTP 프록시 서버(202)를 경유하도록 하기 위한 설정은, 예를 들어 WPAD(Web Proxy Auto-Discovery Protocol) 등을 이용하여 행해진다.
그 때문에, DASH 클라이언트(231)나 DASH 클라이언트(311)는, 처리 대상 파일 군을 방송 경유로 취득하고 있는 것인지, 또는 통신 경유로 취득하고 있는 것인지의 구별을 의식할 필요가 없기(네트워크의 투과성이 제공되기) 때문에, 어플리케이션의 가반성을 높일 수 있다. 그 결과로서, 클라이언트 장치를, 방송계 수신만에 특화하여 실장할 필요가 없고, 또한 방송계 수신과, 통신계 수신 중 어느 것을 이용하느냐에 구애되지 않는 실장으로 할 수 있다.
그런데 방송의 분야에서는, Usage Reporting으로서, 콘텐츠의 시청 이력을 수집하여 분석하는 등의, 시청 이력에 관한 운용이 행해지는 경우가 있다. 예를 들어 ATSC 3.0에 있어서도, 시청 이력 정보를 수집하기 위한 프로토콜이 검토 도상에 있다(예를 들어 비특허문헌 1 참조).
현 상황의 ATSC 3.0에서는, 시청 이력의 엔드 포인트로 되는 클라이언트 장치를 기기 ID에 의하여 식별하여, 개개의 클라이언트 장치별 시청 이력을 리포트하게 되어 있다. 여기서, 도 2에 도시한 전송 시스템의 구성, 게이트웨이로서의 대응 클라이언트 장치(20)(ATSC 3.0 대응 기기)에 실장되는 HTTP 프록시 서버(202)를 통하여, LAN(70) 상의 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기)가 ATSC 3.0의 프로토콜로 전송된 콘텐츠에 액세스하는 형태가 상정된다.
이와 같은 구성의 경우에는, 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기)의 시청 이력에 대해서도 리포트하게 되는데, 대응 클라이언트 장치(20)(ATSC 3.0 대응 기기)와 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기)를 구별하여 개개의 클라이언트 장치별 시청 이력을 리포트하는 것은 곤란하였다. 그 때문에, 대응 클라이언트 장치(20)(ATSC 3.0 대응 기기)와 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기)를 구별할 수 있도록 하여, 시청 이력에 관한 운용을 유연하게 행하기 위한 제안이 요청되고 있었다.
그래서, 본 기술에서는, 시청 이력 정보에, 콘텐츠를 재생한 클라이언트 장치가, 디지털 방송의 규격에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보를 포함시킴으로써, 당해 시청 이력 정보가, 대응 클라이언트 장치(20)(ATSC 3.0 대응 기기)와, 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기) 중 어느 것의 리포트인지를 식별할 수 있도록 한다.
즉, 본 기술에 있어서는, 예를 들어 게이트웨이로서의 대응 클라이언트 장치(20)(ATSC 3.0 대응 기기)에 실장되는 HTTP 프록시 서버(202)에 대하여 액세스해 오는 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기)로부터의 재생 대상 콘텐츠에 대한 HTTP 리퀘스트의 헤더 중의 기기 고유의 정보와, HTTP 리퀘스트의 송신원의 IP 어드레스가, 시청 이력 정보에 포함되도록 한다.
이것에 의하여, 도 2에 도시한, 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기)가 ATSC 3.0의 프로토콜로 전송된 콘텐츠(송신 시스템(10)에 의하여 배신된 콘텐츠)에 액세스하는 형태이더라도, 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기)의 시청 이력을 식별하는 것이 가능해진다. 그 결과로서, 시청 이력에 관한 운용을 유연하게 행하는 것이 가능해진다.
여기서, Usage Reporting으로서 리포트되는 시청 이력 정보에 대해서는, ATSC 3.0에서는, CDM(Consumption Data Message)의 구조로 이루어진다. 또한 CDM의 구조는 상술한 비특허문헌 1의 「Table 4.1 CDM Logical Structure」에 기재되어 있다.
(CDM의 구조예)
도 3은, 현 상황의 CDM의 포맷의 예를 나타내는 도면이다. 또한 CDM은, 텍스트 포맷의 일종인 JSON(JavaScript(등록 상표) Object Notation) 형식으로 기재된다.
protocolVersion에는 CDM의 프로토콜의 버전이 지정된다.
DeviceInfo에는 기기 정보(디바이스 정보)가 지정된다. 여기서, 현 상황의 CDM에서는 DeviceInfo의 속성값으로서 deviceID, deviceModel, deviceManufacturer, deviceOS, peripheralDevice가 규정되어 있다. 여기서, 도 4에는 DeviceInfo의 속성값의 상세한 내용이 나타나 있다. DeviceInfo는 각 기기에 대하여 하나만 기재된다.
deviceID는, 대상 기기의 식별자인 기기 ID가 지정된다. 단, 이 기기 ID를 의도적으로 숨기는 경우에는 "NOTREPORTED"가 기재된다.
deviceModel은, 대상 기기의 모델 번호가 지정된다. 단, 이 모델 번호는 벤더 고유의 포맷으로 한다. 또한 이 모델 번호를 의도적으로 숨기는 경우에는 "NOTREPORTED"가 기재된다.
deviceManufacturer는, 대상 기기의 벤더가 지정된다. 단, 이 벤더를 의도적으로 숨기는 경우에는 "NOTREPORTED"가 기재된다.
deviceOS는 대상 기기의 오퍼레이팅 시스템(OS: Operating System)의 버전이 지정된다. 이 버전을 의도적으로 숨기는 경우에는 "NOTREPORTED"가 기재된다.
peripheralDevice는, 대상 기기가 주변 기기인지 여부를 식별하기 위한 정보가 지정된다. 이 식별 정보를 의도적으로 숨기는 경우에는 "NOTREPORTED"가 기재된다.
도 3의 설명으로 되돌아가, AVService에는, 대상 기기에서 재생된 ATSC 3.0의 서비스 스트림에 관한 정보가 지정된다. AVService의 속성값으로서 serviceID, serviceType, reportInterval이 규정되어 있다.
serviceID에는, 대상 기기에서 재생된 서비스의 ID가 지정된다. 단, 이 서비스 ID는 글로벌하고 유니크한 값으로 된다. serviceType에는, 서비스 ID로 식별되는 서비스의 타입이 지정된다.
reportInterval의 속성값으로서 startTime, endTime, DestinationDeviceType, contentID, component, AppInterval이 규정되어 있다. 또한 contentID의 속성값으로서 type, cid가 규정되어 있다. 또한 component의 속성값으로서 componentType, componentRole, componentName, componentID, componentLang, startTime, endTime, SourceDeliveryPath가 규정되고, 또한 SourceDeliveryPath에는 속성값으로서 type, startTime, endTime이 규정되어 있다. 또한 AppInterval의 속성값으로서 appId, startTime, endTime, LifeCycle, Tags가 규정되어 있다.
이들 속성값에 의하여, 서비스 ID로 식별되는 서비스별로 시청 이력에 관한 정보를 기재할 수 있다.
단, DestinationDeviceType로서는 하기 값이 규정되어 있으며, 예를 들어 "0"이 지정된 경우에는 텔레비전 수상기에 의하여 대상 서비스가 시청된 것을 나타내고, "1"이 지정된 경우에는 텔레비전 수상기 이외의 기기(예를 들어 태블릿형 컴퓨터 등)에 의하여 대상 서비스가 시청된 것을 나타내고 있다.
0 - Content is presented on a Primary Device
1 - Content is presented on a Companion Device
2 - Content is sent to a Time-shift-buffer
3 - Content is sent to a Hard-drive
4 to 255 - Reserved
또한 contentID의 type으로서는 "EIDR" 또는 "Ad ID"를 지정할 수 있다. "EIDR"은 Entertainment Identifier Registry의 약기이며, 텔레비전 프로그램이나 영화의 콘텐츠를 글로벌한 단일 ID로 관리할 수 있다. "Ad ID"는 Advertising ID의 약기이며, 광고용 ID이다.
또한 SourceDeliveryPath의 type으로서는 하기 값이 규정되어 있으며, 예를 들어 "0"이 지정된 경우에는 대상 서비스 컴포넌트가 방송 경유로 배신된 것을 나타내고, "1"이 지정된 경우에는 대상 서비스 컴포넌트가 통신 경유로 배신된 것을 나타내고 있다.
0 - Broadcast delivery(content component is delivered by broadcast)
1 - Broadband delivery(content component is delivered by broadband)
2 - Time-shift-buffer source(content source is local time shift buffer)
3 - Hard-drive source(content source is local hard drive)
4 to 255 - Reserved
또한 도 3에 있어서, Cardinality라는 항목은 출현 수를 나타내고 있다. 예를 들어 "1"이 지정된 경우에는 그 요소 또는 속성은 반드시 하나만 지정된다. 또한, 예를 들어 "0..N"이 지정된 경우에는 그 요소 또는 속성을 1 이상 지정할지 여부는 임의이며, "1..N"이 지정된 경우에는 그 요소 또는 속성은 1 이상 지정된다.
<2. 시스템의 구성>
다음으로, 도 5를 참조하여 Usage Reporting에 대응한 전송 시스템의 구성에 대하여 설명한다.
(본 기술의 전송 시스템의 구성예)
도 5는, 본 기술을 적용한 전송 시스템의 일 실시 형태의 구성을 도시하는 도면이다.
도 5에 있어서는, 도 2와 마찬가지로, IP 전송 방식의 일례로서, ATSC 3.0에 대응한 전송 시스템의 실장 모델을 설명한다. 도 5의 전송 시스템에 있어서, 도 2의 전송 시스템과 대응하는 부분에는 동일한 부호가 붙여져 있으며, 그 설명은 반복되므로 적절히 생략하기로 한다.
즉, 도 5에 있어서, 송신 시스템(10)에는, 시청 이력 정보를 수집하는 UR(Usage Reporting) 서버(101)가 마련되어 있다. 또한 대응 클라이언트 장치(20)에는, 시청 이력 정보를 리포트하기 위한 기능(모듈)로서, HTTP 프록시 서버(202)에 UR 클라이언트(224) 및 HTTP 리퀘스트 핸들러(225)가 마련되어 있다.
이들 기능을 송신측의 송신 시스템(10)과 수신측의 대응 클라이언트 장치(20)에 추가함으로써, 대응 클라이언트 장치(20)의 브라우저(203)(의 DASH 클라이언트(231))에서의 콘텐츠의 재생 이력(시청 이력)이나, 비대응 클라이언트 장치(30)의 브라우저(302)(의 DASH 클라이언트(311))에서의 콘텐츠의 재생 이력(시청 이력)을 기록하고 리포트하는 것이 가능해진다.
대응 클라이언트 장치(20)의 HTTP 프록시 서버(202)에 있어서, UR 클라이언트(224)는, HTTP 리퀘스트 핸들러(225)로부터의 통지에 따라, 본 기술의 CDM의 구조로 이루어지는 시청 이력 정보를 생성하는 모듈이다.
HTTP 리퀘스트 핸들러(225)는, ATSC 3.0 클라이언트 어플리케이션(DASH 클라이언트(231)이나 DASH 클라이언트(311))으로부터의 요구(HTTP 리퀘스트)를 최초에 수신하여 해석하는 모듈이다.
이것에 의하여, UR 클라이언트(224)는, HTTP 리퀘스트 핸들러(225)로부터의 통지에 따라, 대응 클라이언트 장치(20)의 브라우저(203)(의 DASH 클라이언트(231))에서의 콘텐츠의 재생에 따른 시청 이력 정보나, 비대응 클라이언트 장치(30)의 브라우저(302)(의 DASH 클라이언트(311))에서의 콘텐츠의 재생에 따른 시청 이력 정보를 생성하게 된다.
즉, UR 클라이언트(224)는, HTTP 리퀘스트 핸들러(225)를 통하여 HTTP 리퀘스트의 트래픽을 감시함으로써, 대응 클라이언트 장치(20)의 내부에 실장된 DASH 클라이언트(231)와, 대응 클라이언트 장치(20)의 외부에 실장된 DASH 클라이언트(311)의 콘텐츠의 재생 이력(시청 이력)을 기록하는 것이 가능해진다.
여기서, 시청 이력 정보는 본 기술의 CDM의 구조로 이루어진다. 상술한 바와 같이, ATSC 3.0에서 규정된 CDM의 구조는, 기기 정보로서의 DeviceInfo 요소와, 그 기기에서 재생된 ATSC 3.0의 서비스 스트림에 관한 AVService 요소를 포함하고 있다.
본 기술에서는, CDM의 구조로서, 콘텐츠를 재생한 클라이언트 장치가, ATSC 3.0에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보(non3.0DeviceAttributes)를 포함함으로써, 대상 시청 이력 정보(CDM)가, 대응 클라이언트 장치(20)(ATSC 3.0 대응 기기)와 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기) 중 어느 것의 리포트인지를 식별할 수 있도록 한다.
즉, UR 클라이언트(224)는, HTTP 프록시 서버(202)에 대하여 액세스해 오는 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기)로부터의 재생 대상 콘텐츠에 대한 HTTP 리퀘스트의 헤더 중의 기기 고유의 정보와, HTTP 리퀘스트의 송신원의 IP 어드레스가, 시청 이력 정보(CDM)에 포함되도록 한다. 또한 본 기술의 CDM의 구조로 이루어지는 시청 이력 정보의 상세한 내용은, 도 6 내지 도 12를 참조하여 후술한다.
또한 UR 클라이언트(224)는, 소정의 타이밍에 시청 이력 정보를 통신 I/F(204-1)에 공급한다. 통신 I/F(204-1)는 UR 클라이언트(224)로부터의 시청 이력 정보를 인터넷(60)을 통하여 UR 서버(101)에 송신한다.
또한 UR 클라이언트(224)가 시청 이력 정보를 송신할 타이밍으로서는, 예를 들어 미리 정해진 간격으로 정기적으로 송신하거나, 또는 송신 시스템(10)으로부터 대응 클라이언트 장치(20)에 송신되는 시그널링이나, 비디오나 오디오의 워터마크 메시지에 포함되는 코멘트 등에 따라 송신하거나 할 수 있다.
UR 서버(101)는 인터넷(60)을 통하여, 대응 클라이언트 장치(20)(의 UR 클라이언트(224))로부터 송신되어 오는 시청 이력 정보를 수신한다. 또한 도 5에 있어서는, 설명의 편의상 1대의 대응 클라이언트 장치(20)만을 도시하고 있지만, 실제로는, UR 서버(101)에서는 복수의 대응 클라이언트 장치(20)(의 UR 클라이언트(224))로부터의 시청 이력 정보가 수신되어 복수의 시청 이력 정보가 수집된다.
UR 서버(101)는, 수집된 시청 이력 정보에 대하여 시청 이력의 분석이나 해석 등의 각종의 처리를 행한다. 예를 들어 UR 서버(101)는, 방송국별 시청 이력에 관한 시청 이력 리포트를 생성하여 각 방송국에 제공할 수 있다.
여기서, 본 기술의 CDM의 구조로 이루어지는 시청 이력 정보에는, 콘텐츠를 재생한 클라이언트 장치가, ATSC 3.0에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보(non3.0DeviceAttributes)가 포함되어 있다.
그 때문에, UR 서버(101)는, 대상 시청 이력 정보가, 대응 클라이언트 장치(20)(ATSC 3.0 대응 기기)와 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기) 중 어느 것의 리포트인지를 식별하여 시청 이력 리포트를 생성할 수 있다. 즉, 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기)가 ATSC 3.0의 프로토콜로 전송된 콘텐츠에 액세스하는 형태이더라도 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기)의 시청 이력을 식별하는 것이 가능해진다.
또한 도 3에 나타낸 현 상황의 CDM에 있어서는, DestinationDeviceType에 의하여, 텔레비전 수상기와 텔레비전 수상기 이외의 기기 중 어느 것에 의하여 대상 서비스 콘텐츠가 재생되었다는 것은 알 수 있지만, 본 기술의 CDM과 같이, 대응 클라이언트 장치(20)(ATSC 3.0 대응 기기)와 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기) 중 어느 것에 의하여 대상 서비스 콘텐츠가 재생되었다는 것까지는 알 수 없다.
본 기술의 전송 시스템은 이상과 같이 구성된다.
<3. 본 기술의 시청 이력 정보(CDM)>
다음으로, 도 6 내지 도 12를 참조하여 본 기술의 CDM의 구조로 이루어지는 시청 이력 정보의 상세에 대하여 설명한다.
(본 기술의 CDM의 구조예)
도 6은, 본 기술의 CDM의 포맷의 예를 나타내는 도면이다. 상술한 바와 같이 CDM은 JSON 형식으로 기재된다.
도 6의 CDM의 포맷은 상술한 CDM의 포맷(도 3)에 비하여, DeviceInfo의 속성값으로서 deviceID, deviceModel, deviceManufacturer, deviceOS, peripheralDevice 외에 non3.0DeviceAttributes가 추가되어 있는 점이 상이하다.
non3.0DeviceAttributes는, ATSC 3.0에 준거한 데이터를 처리 가능한 기기인지를 나타내는 속성이다. 이 non3.0DeviceAttributes에 의하여, 대상 CDM이 대응 클라이언트 장치(20)(ATSC 3.0 대응 기기)와 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기) 중 어느 것의 리포트인지를 식별하는 것이 가능해진다.
non3.0DeviceAttributes의 속성값으로서는 "schemeIdUri"와 value"의 세트를 지정할 수 있다. 예를 들어 "schemeIdUri"에 대하여 HTTP 리퀘스트의 유저 에이전트(UserAgent)의 헤더의 내용인 것을 식별하는 URI(Uniform Resource Identifier)로서 "urn:browserUserAgent"인 값을 정의함으로써, 유저 에이전트의 헤더에 저장되어 있는 문자열(정보)을 "value"의 값으로서 기재할 수 있다.
여기서, 비대응 클라이언트 장치(30)에 의하여 발행되는, 방송 서비스의 DASH 세그먼트 파일이나 애플리케이션 파일에 대한 HTTP 리퀘스트의 유저 에이전트의 헤더(HTTP 리퀘스트 헤더)에는, 유저 에이전트로서, 오퍼레이팅 시스템(OS)에 관한 정보나 모바일 단말기인지 여부를 나타내는 정보가 포함되어 있다. 또한 이 HTTP 리퀘스트는, HTTP로 정의되어 있는 메소드 중, GET메소드를 이용하고 있다.
예를 들어 유저 에이전트로서, "Mozilla/5.0(compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)"이 얻어지면, 비대응 클라이언트 장치(30)가 Windows(등록 상표)를 오퍼레이팅 시스템(OS)으로 하는 퍼스널 컴퓨터임을 알 수 있다.
또한, 예를 들어 유저 에이전트로서, "Mozilla/5.0(Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1(KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"이 얻어지면, 비대응 클라이언트 장치(30)가 Android(등록 상표)를 오퍼레이팅 시스템(OS)으로 하는 스마트폰임을 알 수 있다. 또한 당해 유저 에이전트에 있어서, "Mobile"의 기재가 없으면, 태블릿형 컴퓨터임을 알 수 있다.
또한 non3.0DeviceAttributes에 있어서, "schemeIdUri"에 대하여 HTTP 리퀘스트의 유저 에이전트의 헤더의 내용인 것을 식별하는 URI("urn:browserUserAgent") 외에, IP 어드레스의 내용인 것을 식별하는 URI로서, "urn:ipAddress"인 값을 정의함으로써, 로컬의 IP 어드레스를 "value"의 값으로서 기재할 수 있다.
예를 들어 "value"의 값으로서 "192.168.0.12"이 얻어지면, 비대응 클라이언트 장치(30)에 할당되어 있는 로컬의 IP 어드레스가 "192.168.0.12"인 것을 알 수 있다.
(본 기술의 CDM의 기재예)
다음으로, 도 7 및 도 8을 참조하여 본 기술의 CDM의 기재예를 설명한다. 또한 JSON 형식의 오브젝트는, 키와 값의 페어를 콜론(:)으로 쌍으로 하고, 이들 쌍을 콤마(,)로 구획하여 0개 이상 열거하고, 전체를 중괄호({})로 묶음으로서 표현된다.
(A) CDM의 기재예 1
도 7은, ATSC 3.0 비대응 기기 고유의 정보로서, 유저 에이전트에 관한 정보를 포함한 경우의 CDM의 기재예를 나타내는 도면이다. 또한 도 7에 있어서는, 설명의 간략화를 위하여 DeviceInfo의 속성값과 AVService의 속성값의 일부를 발췌하여 기재하고 있다.
도 7의 CDM에 있어서는, DeviceInfo의 속성값으로서 deviceID, deviceModel, deviceManufacturer, deviceOS, peripheralDevice, non3.0DeviceAttributes가 포함된다.
deviceID인 키에 대하여 "NOTREPORTED"인 값이 페어로 되어 지정되어 있다. 즉, 기기 ID가 의도적으로 숨겨져 있음을 나타내고 있다.
또한 deviceModel, deviceManufacturer, deviceOS, peripheralDevice에 대해서도 "NOTREPORTED"인 값이 각각 지정되어, 대상 기기의 모델 번호, 대상 기기의 제조원(벤더), 대상 기기의 오퍼레이팅 시스템(OS)의 버전, 및 대상 기기가 주변 기기인지 여부를 식별하기 위한 정보가 의도적으로 숨겨져 있음을 나타내고 있다.
non3.0DeviceAttributes의 속성값으로서 "schemeIdUri"와 "value"의 세트가 지정되어 있다. 여기서는, "schemeIdUri"에 대하여 HTTP 리퀘스트의 유저 에이전트의 헤더의 내용인 것을 식별하는 URI로서, "urn:browserUserAgent"인 값이 정의되고, 유저 에이전트의 헤더에 저장되어 있는 문자열(정보)이 "value"의 값으로서 기재되어 있다.
도 7의 예에서는, "value"의 값으로서 "Mozilla/5.0(Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1(KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"이라 기재되어 있어, 비대응 클라이언트 장치(30)가 Android(등록 상표)를 오퍼레이팅 시스템(OS)으로 하는 스마트폰인 것을 나타내고 있다.
AVService의 reportInterval에 있어서, ContentID의 속성값으로서, "type"와"cid"의 세트가 지정되어 있다. 여기서는, "type"에 대하여 "EIDR"인 값이 정의되고, EIDR의 포맷의 콘텐츠 식별자(CID: Content ID)인 "cid"의 값으로서 "10.5240/EA73-79D7-1B2B-B378-3A 73-M"이 설정되어 있음을 나타내고 있다.
Component의 속성값으로서 "componentType"이 지정되어 있다. 여기서는, "componentType"에 대하여 "1"인 값이 설정되어, 대상 컴포넌트가 비디오인 것을 나타내고 있다.
이상과 같이 도 7의 CDM의 기재예에서는, non3.0DeviceAttributes의 속성값으로 식별된, Android(등록 상표)를 오퍼레이팅 시스템(OS)으로 하는 스마트폰으로서의 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기)에 의하여 재생된 콘텐츠가, "10.5240/EA73-79D7-1B2B-B378-3A 73-M"인 EIDR 형식의 콘텐츠 식별자(CID)를 갖는 비디오의 콘텐츠인 것을 나타내고 있다.
(B) CDM의 기재예 2
도 8은, ATSC 3.0 비대응 기기 고유의 정보로서, 유저 에이전트에 관한 정보와 IP 어드레스를 포함한 경우의 CDM의 기재예를 나타내는 도면이다. 또한 도 8에 있어서도, 설명의 간략화를 위하여 DeviceInfo의 속성값과 AVService의 속성값의 일부를 발췌하여 기재하고 있는데, 도 7의 기재예와 대응하는 부분에 대해서는 그 설명은 생략하는 것으로 한다.
도 8의 CDM에 있어서는, non3.0DeviceAttributes의 속성값으로서 "schemeIdUri"와 "value"의 세트가 지정되어 있는데, 여기서는, "schemeIdUri"에 대하여 HTTP 리퀘스트의 유저 에이전트의 헤더의 내용인 것을 식별하는 URI("urn:browserUserAgent") 외에, IP 어드레스의 내용인 것을 식별하는 URI로서 "urn:ipAddress"인 값이 정의되고, IP 어드레스의 값이 "value"의 값으로서 기재되어 있다.
도 8의 예에서는, "value"의 값으로서 "192.168.0.12"라 기재되어 있어, 비대응 클라이언트 장치(30)에 할당되어 있는 로컬의 IP 어드레스가 "192.168.0.12"인 것을 나타내고 있다.
이상과 같이, 도 8의 CDM의 기재예에서는, non3.0DeviceAttributes의 속성값으로 식별된, Android(등록 상표)를 오퍼레이팅 시스템(OS)으로 하는 스마트폰이며, "192.168.0.12"인 로컬의 IP 어드레스가 할당된 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기)에 의하여 재생된 콘텐츠가, "10.5240/EA73-79D7-1B2B-B378-3A 73-M"인 EIDR 형식의 콘텐츠 식별자(CID)를 갖는 비디오의 콘텐츠인 것을 나타내고 있다.
또한 도 7 및 도 8에 있어서는, JSON 형식의 CDM의 기재예를 나타냈지만, 본 기술의 CDM의 기재 형식은 JSON 형식에 한정되지 않으며, 예를 들어 XML(Extensible Markup Language) 형식 등 다른 텍스트 형식의 데이터를 채용할 수도 있다.
또한 도 7 및 도 8에 있어서는, DeviceInfo의 속성값(deviceID 등)은 필수적인 값으로 되기 때문에, 의도적으로 숨기는 경우에는 "NOTREPORTED"가 기재되는 것으로 하였지만, DeviceInfo의 속성값이 임의의 값이 되도록 함으로써, 의도적으로 숨기는 경우에 DeviceInfo의 속성값 자체의 기재를 생략할 수도 있다.
(JSON 스키마의 예)
도 9 내지 도 12은, 본 기술의 CDM의 JSON 스키마의 예를 나타내는 도면이다.
도 9 내지 도 12의 JSON 스키마는, 도 6에 나타낸 본 기술의 CDM의 포맷에 대응하고 있다. 즉, 이 JSON 스키마는, ATSC 3.0에서 규정되어 있는 현 상황의 CDM을 확장한 본 기술의 CDM에 대응하고 있으며, 확장된 부분 이외의 구조는 현 상황의 CDM의 JSON 스키마의 구조와 마찬가지이다. 현 상황의 CDM의 JSON 스키마의 구조는 상술한 비특허문헌 1의 「Annex A: Schema」에 개시되어 있기 때문에, 여기서는 그 설명은 생략하기로 한다.
도 9 내지 도 12에 나타낸 CDM의 JSON 스키마 중, 도 9의 29 내지 44의 단락에는 DeviceInfo의 속성값으로서 non3.0DeviceAttributes가 정의되어 있다. 여기서는, 배열형으로 되는 non3.0DeviceAttributes의 속성값으로서 문자열형의"schemeIdUri"와 문자열형의"value"의 세트가 정의되어 있다. 단, 그러한 세트에 있어서, "schemeIdUri"는 필수적인 요소로 된다.
이와 같은 CDM의 JSON 스키마를 정의함으로써, 예를 들어 "schemeIdUri"에 대하여 "urn:browserUserAgent"인 값을 정의함으로써, HTTP 리퀘스트의 유저 에이전트의 정보를 "value"의 값으로서 기재할 수 있다. 또한, 예를 들어 "schemeIdUri"에 대하여 "urn:ipAddress"인 값을 정의함으로써, 로컬의 IP 어드레스를 "value"의 값으로서 기재할 수 있다.
<4. Usage Reporting 장치 간의 프로토콜>
(Usage Reporting 프로토콜의 예)
도 13은, 도 5에 도시한 UR 서버(101)와, 대응 클라이언트 장치(20)의 UR 클라이언트(224) 사이의 프로토콜의 예를 도시하는 도면이다.
대응 클라이언트 장치(20)에 있어서는, 방송 미들웨어(201)에 의하여 송신 시스템(10)으로부터의 LLS가 처리되어 SLT 메타데이터가 얻어지는데, 이 SLT 메타데이터에 UR 서버(101)의 URL이 포함되어 있다. 그리고 통신 I/F(204-1)는, SLT 메타데이터에 포함되는 UR 서버(101)의 URL에 따라 인터넷(60)을 통하여 UR 서버(101)에 액세스할 수 있다. 또한 SLT 메타데이터에서 주지되는 UR 서버(101)의 URL의 상세는 도 15 및 도 16을 참조하여 후술한다.
여기서는, HTTP 프록시 서버(202)의 UR 클라이언트(224)에 의하여 생성된 시청 이력 정보(CDM)가 인터넷(60)을 통하여 UR 서버(101)에 송신된다. 이 시청 이력 정보(CDM)는, HTTP 리퀘스트의 PUT메소드를 이용하여 보디부에 저장할 수 있다.
즉, 대응 클라이언트 장치(20)(UR 클라이언트(224))로부터, UR 서버(101)에 대해서는, 도 13에 나타낸 CDM 메시지의 형식으로 시청 이력 정보(CDM)를 송신할 수 있는데, 이 CDM 메시지에서는, 1행째의 리퀘스트행에, 메소드를 나타내는 「PUT」과, 지정된 URL의 디렉토리와 패스명을 나타내는 URI와, HTTP 버전을 나타내는 「HTTP/1.1」이 기재된다.
또한 CDM 메시지에 있어서, 2행째 내지 4행째의 헤더부에, 지정된 URL의 호스트명을 나타내는 「Host」와, 데이터의 형식이 지정되는 「Content-Type」과, 보디부의 길이가 지정되는 「Content-Length」가 기재된다. 그리고, 개행을 사이에 두고 6행째의 보디부에, JSON 형식으로 인코딩된 CDM 구조로 이루어지는 시청 이력 정보를 저장할 수 있다.
이와 같은 프로토콜에 따라, 대응 클라이언트 장치(20)(UR 클라이언트(224))로부터 송신되어 오는 시청 이력 정보(CDM)가 인터넷(60)을 통하여 UR 서버(101)에 의하여 수신되어 처리되게 된다. 또한 UR 서버(101)의 상세한 구성은 도 14를 참조하여 후술한다.
(UR 서버의 구성예)
도 14은, 도 5의 UR 서버(101)의 구성예를 도시하는 도면이다.
UR 서버(101)는 통신 I/F(111), CDM 기록부(112), CDM 분석부(113) 및 출력부(114)로 구성된다.
통신 I/F(111)는, 예를 들어 통신 인터페이스 회로 등으로 구성되며, 인터넷(60)을 통하여 대응 클라이언트 장치(20)와 데이터를 주고받기한다. 통신 I/F(111)는 인터넷(60)을 통하여, 복수의 대응 클라이언트 장치(20)로부터 송신되어 오는 시청 이력 정보를 수신하여, CDM 기록부(112)에 공급한다.
CDM 기록부(112)는, 예를 들어 하드 디스크(HDD: Hard Disk Drive)나 반도체 메모리 등으로 구성된다. CDM 기록부(112)는 통신 I/F(111)로부터의 시청 이력 정보를 기록한다. 이것에 의하여 복수의 대응 클라이언트 장치(20)로부터의 시청 이력 정보가 수집된다. 이 시청 이력 정보는, 도 6에 나타낸 본 기술의 CDM의 구조로 이루어진다.
CDM 분석부(113)는, 예를 들어 CPU나 마이크로프로세서 등으로 구성된다. CDM 분석부(113)는, CDM 기록부(112)에 기록되어 있는 시청 이력 정보를 판독하고, 판독된 시청 이력 정보를 분석한다. CDM 분석부(113)는, 시청 이력 정보의 분석 결과에 따라, 시청 이력에 관한 시청 이력 리포트를 생성하여 출력부(114)에 공급한다.
출력부(114)는, 예를 들어 출력 인터페이스 회로나, LCD 등의 디스플레이로 구성된다. 출력부(114)는 CDM 분석부(113)로부터의 시청 이력 리포트를 외부의 장치에 출력한다. 또한 출력부(114)가 디스플레이로 구성되는 경우에는, 당해 디스플레이에 시청 이력 리포트를 표시시키도록 해도 된다.
UR 서버(101)는 이상과 같이 구성된다.
(SLT 메타데이터의 구조예)
도 15는, XML 형식의 SLT 메타데이터의 포맷의 예를 나타내는 도면이다. 또한 도 15에 있어서, 요소와 속성 중, 속성에는 「＠」이 붙여져 있다. 또한 인덴트된 요소와 속성은 그 상위의 요소에 대하여 지정되게 된다.
단, SLT 메타데이터의 포맷에 대해서는, 하기 비특허문헌 2의 「Table 6.2 SLT XML Format」에 그 상세한 내용이 기재되어 있다. 그 때문에, 도 15의 포맷 예에서는, SLT 메타데이터 중, 특히 본 기술에 관계되는 부분을 발췌하여 기재하고 있다.
SLT 요소는 루트 요소이며, sltInetUrl 요소를 포함하고 있다. sltInetUrl 요소에는, 브로드캐스트 스트림 ID로 식별되는 주파수 대역(예를 들어 6㎒)별로, urlType 속성의 속성값으로 지정되는 URL 타입에 따른 URL을 지정할 수 있다.
여기서, 도 16에는 urlType 속성의 속성값의 예를 나타내고 있다.
urlType 속성으로서 "1"이 지정된 경우, sltInetUrl 요소에, SLS를 제공하는 시그널링 서버의 URL이 지정되는 것을 나타내고 있다. 또한 urlType 속성으로서 "2"이 지정된 경우, sltInetUrl 요소에, 전자 프로그램표(ESG: Electronic Service)를 제공하는 ESG 서버의 URL이 지정되는 것을 나타내고 있다.
또한 urlType 속성으로서 "3"이 지정된 경우에는, sltInetUrl 요소에, UR 서버(101)의 URL이 지정되는 것을 나타내고 있다. 즉, 도 5에 도시한 전송 시스템의 구성을 채용한 경우, Usage Reporting으로서 콘텐츠의 시청 이력에 관한 운용이 행해지므로, SLT 메타데이터의 sltInetUrl 요소에는 UR 서버(101)의 URL이 기재되고, urlType 속성으로서 "3"이 지정된다.
도 15의 설명으로 되돌아가, SLT 요소는 하나 또는 복수의 Service 요소를 포함하고 있다. Service 요소에는, 서비스 단위로 각 서비스에 관한 정보가 지정된다. 이 Service 요소는 svcInetUrl 요소를 포함하고 있다. svcInetUrl 요소에는, 서비스 ID로 식별되는 서비스별로 urlType 속성의 속성값으로 지정되는 URL 타입에 따른 URL을 지정할 수 있다.
여기서, svcInetUrl 요소의 urlType 속성의 속성값에 대해서도, 도 16에 나타낸 속성값이 지정된다. 즉, urlType 속성으로서 "3"이 지정된 경우에는, svcInetUrl 요소에 UR 서버(101)의 URL이 지정되게 된다.
이와 같이, UR 서버(101)의 URL을, 브로드캐스트 스트림 ID로 식별되는 주파수 대역별로 지정하는 경우에는, SLT 요소의 관리 하의 sltInetUrl 요소에 기재하면 된다. 또한 UR 서버(101)의 URL을, 서비스 ID로 식별되는 서비스별로 지정하는 경우에는, Service 요소의 관리 하의 svcInetUrl 요소에 기재하면 된다.
또한 도 15에 있어서, use의 항목은 출현 수를 나타내고 있다. 예를 들어 "0..N"이 지정된 경우에는, 그 요소 또는 속성을 하나 이상 지정할지 여부는 임의이다. 또한, 예를 들어 "1"이 지정된 경우에는 그 요소 또는 속성은 반드시 하나만 지정되고, "1..N"이 지정된 경우에는 그 요소 또는 속성은 하나 이상 지정된다.
또한 도 15에 있어서, Data Type이라는 항목은 데이터 형식을 나타내고 있다. 예를 들어 "anyURI"이 지정된 경우에는, 그 데이터는, URI의 형식을 한 문자열인 것을 나타내고 있다. 또한, 예를 들어 "unsignedByte"가 지정된 경우에는, 0부터 255까지의 정수인 것을 나타내고 있다.
<5. 시청 이력 정보 대응 처리의 흐름>
다음으로, 도 17 및 도 18의 흐름도를 참조하여, 도 5의 전송 시스템에 의하여 실행되는 시청 이력 정보 대응 처리의 흐름을 설명한다.
또한 도 17 및 도 18에 있어서, 스텝 S101의 처리는 송신 시스템(10)에 의하여 실행된다. 또한 스텝 S201 내지 S206과 S221 내지 S225의 처리는 대응 클라이언트 장치(20)에 의하여 실행된다. 또한 스텝 S301 내지 S302의 처리는 비대응 클라이언트 장치(30)에 의하여 실행된다.
도 17의 스텝 S301에 있어서, 비대응 클라이언트 장치(30)의 제어부(300)는 통신 I/F(301)을 제어하고, LAN(70)을 통하여 콘텐츠의 DASH 세그먼트 파일을 대응 클라이언트 장치(20)에 요구한다. 여기서는, 예를 들어 유저 조작에 의하여, 송신 시스템(10)으로부터 배신되는 텔레비전 프로그램 등의 콘텐츠의 재생이 지시된 경우에, 비대응 클라이언트 장치(30)로부터의 HTTP 리퀘스트가 저장된 IP 패킷이 대응 클라이언트 장치(20)에 통지된다.
대응 클라이언트 장치(20)에 있어서는, 비대응 클라이언트 장치(30)로부터의 HTTP 리퀘스트가 저장된 IP 패킷이 통신 I/F(204-2)에 의하여 수신되어, HTTP 프록시 서버(202)의 HTTP 리퀘스트 핸들러(225)에 공급된다.
스텝 S201에 있어서, HTTP 리퀘스트 핸들러(225)는, HTTP 리퀘스트가 저장된 IP 패킷의 송신원 어드레스(소스 어드레스)를 체크한다.
스텝 S202에 있어서, HTTP 리퀘스트 핸들러(225)는, 스텝 S201의 송신원 어드레스의 체크 결과에 따라, 당해 송신원 어드레스가 로컬 DASH 클라이언트로부터의 것인지 여부를 판정한다. 여기서는, DASH 클라이언트(311)이 탑재된 비대응 클라이언트 장치(30)에 할당된 IP 어드레스가 송신원 어드레스로 되므로, 당해 송신원 어드레스가 로컬 DASH 클라이언트로부터의 것으로 판정되고(S202의 「"예"」), 처리는 스텝 S203으로 나아간다.
또한 스텝 S202의 판정 처리에서, 송신원 어드레스가 로컬 DASH 클라이언트로부터의 것이 아니라고 판정된 경우에는, 필요한 처리가 행해진 후에 처리는 종료된다.
스텝 S203에 있어서, HTTP 리퀘스트 핸들러(225)는, 스텝 S202의 처리에서 판정 대상으로 된 송신원 어드레스를 UR 클라이언트(224)에 통지한다. 이것에 의하여, HTTP 프록시 서버(202)에 있어서는, HTTP 리퀘스트 핸들러(225)로부터의 송신원 어드레스가 UR 클라이언트(224)에 의하여 수신된다.
스텝 S221에 있어서, UR 클라이언트(224)는 비대응 클라이언트 장치(30)별로 관리되고 있는 CDM(의 DeviceInfo.non3.0DeviceAttributes)에 대하여 HTTP 리퀘스트 핸들러(225)로부터의 송신원 어드레스에 따른 IP 어드레스를 기록한다.
또한 스텝 S204에 있어서, HTTP 리퀘스트 핸들러(225)는, 스텝 S202의 처리에서 판정 대상으로 된 송신원 어드레스의 IP 패킷에 저장된 HTTP 리퀘스트 헤더로부터 유저 에이전트(UserAgent)의 문자열을 추출하여 UR 클라이언트(224)에 통지한다. 이것에 의하여, HTTP 프록시 서버(202)에 있어서는, HTTP 리퀘스트 핸들러(225)로부터의 유저 에이전트의 정보가 UR 클라이언트(224)에 의하여 수신된다.
스텝 S222에 있어서, UR 클라이언트(224)는, 비대응 클라이언트 장치(30)별로 관리되고 있는 CDM(의 DeviceInfo.non3.0DeviceAttributes)에 대하여 HTTP 리퀘스트 핸들러(225)로부터의 유저 에이전트의 정보를 기록한다. 이 유저 에이전트의 정보로서는, 예를 들어 오퍼레이팅 시스템(OS)에 관한 정보나 모바일 단말기인지 여부를 나타내는 정보가 포함되어 있다.
또한 송신원 어드레스(IP 어드레스)나 유저 에이전트의 정보는, 동일한 내용으로 되는 경우에는 반드시 반복 취득할 필요는 없으며, 취득 완료된 것을 재이용할 수 있다.
도 18의 스텝 S205에 있어서, HTTP 리퀘스트 핸들러(225)는, 송신 시스템(10)으로부터 배신되는 텔레비전 프로그램 등의 콘텐츠의 데이터이며, 방송 미들웨어(201)의 처리로 얻어지는 DASH 세그먼트 파일을 LAN(70)을 통하여 비대응 클라이언트 장치(30)에 전송한다.
스텝 S302에 있어서, 비대응 클라이언트 장치(30)의 DASH 클라이언트(311)는, 대응 클라이언트 장치(20)(의 HTTP 프록시 서버(202)의 HTTP 리퀘스트 핸들러(225))로부터 전송되어 오는 DASH 세그먼트 파일을 재생한다. 이것에 의하여, 비대응 클라이언트 장치(30)에서는, 송신 시스템(10)으로부터 배신되는 텔레비전 프로그램 등의 콘텐츠가 재생되고 유저에 의하여 시청되게 된다.
스텝 S206에 있어서, HTTP 리퀘스트 핸들러(225)는, 스텝 S205의 처리에서 비대응 클라이언트 장치(30)에 전송된 DASH 세그먼트 파일에 대응한 세그먼트 URL을 UR 클라이언트(224)에 통지한다. 이것에 의하여, HTTP 프록시 서버(202)에 있어서는, HTTP 리퀘스트 핸들러(225)로부터의 세그먼트 URL이 UR 클라이언트(224)에 의하여 수신된다.
스텝 S223에 있어서, UR 클라이언트(224)는, 비대응 클라이언트 장치(30)별로 관리되고 있는 CDM(의 AVService)에 대하여 HTTP 리퀘스트 핸들러(225)로부터의 세그먼트 URL에 대응하는 정보를 기록한다.
여기서는, 예를 들어 MPD 메타데이터를 참조함으로써, 세그먼트 URL에 대응하는 콘텐츠 ID(ContentID)를 취득할 수 있으므로, 당해 콘텐츠 ID를 CDM의 AVService.reportInterval.contentID에 기록할 수 있다. 또한 여기서는, 도 6에 나타낸 CDM의 구조에 포함되는 정보이면 콘텐츠 ID 이외의 정보를 기록할 수도 있다. 예를 들어 필요에 따라 처리된 시간을 CDM의 AVService.reportInterval.startTime(endTime)에 기록할 수 있다.
스텝 S224에 있어서, 제어부(200)는, CDM을 송신할 타이밍인지 여부를 판정한다. 이 판정 조건으로서는, 예를 들어 미리 정해진 간격으로 정기적으로 송신하기 위한 조건 외에, 송신 시스템(10)으로부터 대응 클라이언트 장치(20)에 송신되는 시그널링이나, 비디오나 오디오의 워터마크 메시지에 포함되는 코멘트 등에 따른 조건 등이 이용된다.
스텝 S224에 있어서, CDM을 송신할 타이밍이 아니라고 판정된 경우, 처리는 스텝 S221로 되돌아가 그 이후의 처리가 반복된다. 즉, 이 경우에는, 비대응 클라이언트 장치(30)로부터의 요구에 따라 DASH 세그먼트 파일이 전송됨과 함께, 그 재생 이력(시청 이력)이 계속해서 기록된다.
한편, 스텝 S224에 있어서, CDM을 송신할 타이밍이라고 판정된 경우, 처리는 스텝 S225로 나아간다. 스텝 S225에 있어서, UR 클라이언트(224)는, 스텝 S221 내지 S223의 처리에서 얻어지는, JSON 형식으로 인코딩된 CDM을 시청 이력 정보로서 인터넷(60)을 통하여 UR 서버(101)에 송신한다.
또한 여기서는, 통신 I/F(204-1)이, SLT 메타데이터로부터 얻어지는 UR 서버(101)의 URL에 따라 인터넷(60)을 통하여 UR 서버(101)에 액세스함으로써, UR 클라이언트(224)로부터의 시청 이력 정보(CDM)가 UR 서버(101)에 송신된다.
이것에 의하여, UR 서버(101)에 있어서는, 대응 클라이언트 장치(20)로부터의 시청 이력 정보(CDM)가 통신 I/F(111)에 의하여 수신된다. 또한 UR 서버(101)에 있어서는, 복수의 대응 클라이언트 장치(20)로부터 시청 이력 정보가 수신되어 복수의 시청 이력 정보가 수집된다.
스텝 S101에 있어서, UR 서버(101)의 CDM 분석부(113)는 수집된 시청 이력 정보(CDM)를 분석하여 시청 이력에 관한 시청 이력 리포트를 생성한다.
여기서, 시청 이력 정보(CDM)에는, 콘텐츠를 재생한 클라이언트 장치가, ATSC 3.0에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보(non3.0DeviceAttributes)가 포함되어 있다. 그 때문에, CDM 분석부(113)는, 대상 시청 이력 정보(CDM)가, 대응 클라이언트 장치(20)(ATSC 3.0 대응 기기)와 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기) 중 어느 것의 리포트인지를 식별하여 시청 이력 리포트를 생성할 수 있다.
이상, 시청 이력 정보 대응 처리의 흐름을 설명하였다.
<6. 변형예>
(ATSC 3.0 대응 기기의 CDM의 기재예)
상술한 설명에서는, 비대응 클라이언트 장치(30)가 대응 클라이언트 장치(20)를 통하여, ATSC 3.0의 프로토콜로 전송된 콘텐츠에 액세스하는 형태에 있어서, 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기)의 시청 이력을 식별하기 위하여 CDM의 DeviceInfo의 속성값에 non3.0DeviceAttributes를 추가하여, 비대응 클라이언트 장치(30)에 고유의 정보가 지정되도록 하고 있다.
여기서는, 대응 클라이언트 장치(20)(ATSC 3.0 대응 기기)의 시청 이력을 식별하기 위하여 CDM의 DeviceInfo의 non3.0DeviceAttributes에 대하여 대응 클라이언트 장치(20)에 고유의 정보가 지정되도록 해도 된다. 이 경우에는, 대응 클라이언트 장치(20)에 고유의 정보로서, HTTP 리퀘스트의 유저 에이전트에 포함되는 정보를 포함할 수 있다.
도 19에는, ATSC 3.0 대응 기기 고유의 정보로서, 유저 에이전트에 관한 정보를 포함한 경우의 CDM의 기재예를 나타내고 있다. 도 19에 있어서는, non3.0DeviceAttributes의 속성값으로서 "schemeIdUri"와 "value"의 세트가 지정되어 있다.
여기서는, "schemeIdUri"에 대하여, HTTP 리퀘스트의 유저 에이전트의 헤더의 내용인 것을 식별하는 URI로서 "urn:browserUserAgent"인 값이 정의되고, 유저 에이전트의 헤더에 저장되어 있는 문자열(정보)이 "value"의 값으로서 기재되어 있다. 이 "value"의 값으로서는, 예를 들어 오퍼레이팅 시스템(OS)에 관한 정보나, 모바일 단말기인지 여부를 나타내는 정보 등이 기재된다.
또한 대응 클라이언트 장치(20)(ATSC 3.0 대응 기기)에 있어서, HTTP 프록시 서버(202)에 대한, 브라우저(203)의 DASH 클라이언트(231)로부터의 HTTP 리퀘스트에는, 대응 클라이언트 장치(20)에 할당된 IP 어드레스는 포함되어 있지 않다. 그 때문에, 대응 클라이언트 장치(20)(ATSC 3.0 대응 기기)의 시청 이력 정보(CDM)에 IP 어드레스를 포함하지 않도록 함으로써, IP 어드레스를 포함하는 것이 가능한 비대응 클라이언트 장치(30)(ATSC 3.0 비대응 기기)의 시청 이력 정보(CDM)(예를 들어 도 8의 CDM의 기재예)와 구별하는 것이 가능해진다.
(다른 방송 규격에 대한 적용)
상술한 설명으로서는, 디지털 방송의 규격으로서 미국 등에서 채용되고 있는 방식인 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) 등의 유선 방송 등의 규격에 적용할 수 있다.
(그 외의 변형예)
또한 상술한 시그널링이나 패킷 등의 명칭은 일례이며, 다른 명칭이 이용되는 경우가 있다. 단, 이들 명칭의 차이는 형식적인 차이이며, 대상 시그널링이나 패킷 등의 실질적인 내용이 상이한 것은 아니다. 예를 들어 CDM에 있어서, ATSC 3.0에 준거한 데이터를 처리 가능한 기기인지를 나타내는 속성으로서, 「non3.0DeviceAttributes」를 정의하였지만, 다른 명칭을 이용하도록 해도 된다. 또한, 예를 들어 USBD(User Service Bundle Description)는 USD(User Service Description)라 칭해지는 경우가 있다. 또한, 예를 들어 LCC(Locally Cached Content)는 NRT(Non Real Time) 등이라 칭해지는 경우가 있다.
<7. 컴퓨터의 구성>
상술한 일련의 처리(도 17 및 도 18의 시청 이력 정보 대응 처리)는 하드웨어에 의하여 실행할 수도 있고 소프트웨어에 의하여 실행할 수도 있다. 일련의 처리를 소프트웨어에 의하여 실행하는 경우에는, 그 소프트웨어를 구성하는 프로그램이 컴퓨터에 인스톨된다. 도 20은, 상술한 일련의 처리를 프로그램에 의하여 실행하는 컴퓨터의 하드웨어의 구성예를 도시하는 도면이다.
컴퓨터(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)
상기 고유의 정보는 HTTP(Hypertext Transfer Protocol) 리퀘스트의 유저 에이전트에 포함되는 정보인,
(2)에 기재된 정보 처리 장치.
(4)
상기 고유의 정보는, 상기 HTTP 리퀘스트가 상기 비대응 기기로부터의 것인 경우, IP(Internet Protocol) 어드레스를 더 포함하는,
(3)에 기재된 정보 처리 장치.
(5)
상기 유저 에이전트는, 오퍼레이팅 시스템(OS: Operating System)에 관한 정보와, 모바일 단말기인지 여부를 나타내는 정보를 적어도 포함하고 있는,
(3) 또는 (4)에 기재된 정보 처리 장치.
(6)
상기 디지털 방송의 방송파를 수신하는 수신부와,
상기 방송파로부터 얻어지는, 상기 디지털 방송의 규격에 준거한 데이터를 처리하는 데이터 처리부와,
상기 비대응 기기로부터 송신되어 오는 HTTP 리퀘스트에 따라, 네트워크를 통하여 상기 데이터 처리부로부터의 상기 데이터를 상기 비대응 기기에 송신하는 통신부
를 더 구비하고,
상기 시청 이력 처리부는, 상기 비대응 기기에서 재생된 상기 콘텐츠의 시청 이력에 대하여, 상기 비대응 기기로부터의 HTTP 리퀘스트로부터 얻어지는 유저 에이전트에 포함되는 정보와, 상기 비대응 기기에 할당된 IP 어드레스를 관련지은 상기 시청 이력 정보를 생성하는,
(4)에 기재된 정보 처리 장치.
(7)
상기 시청 이력 처리부는 HTTP 프록시 서버의 모듈로서 실장되는
(3) 내지 (6) 중 어느 한 항에 기재된 정보 처리 장치.
(8)
상기 대응 기기 또는 상기 비대응 기기에 있어서, 상기 콘텐츠는 브라우저 상에서 재생되는
(2) 내지 (6) 중 어느 한 항에 기재된 정보 처리 장치.
(9)
상기 통신부는 상기 시청 이력 정보를 네트워크를 통하여, 상기 시청 이력 정보를 수집하는 시청 이력 서버에 송신하는,
(6)에 기재된 정보 처리 장치.
(10)
상기 데이터 처리부로부터의 상기 데이터를 재생하는 재생부를 더 구비하는,
(6) 내지 (9) 중 어느 한 항에 기재된 정보 처리 장치.
(11)
정보 처리 장치의 정보 처리 방법에 있어서,
상기 정보 처리 장치가,
디지털 방송의 콘텐츠의 시청 이력에 관한 시청 이력 정보이며, 상기 콘텐츠를 재생한 기기가, 상기 디지털 방송의 규격에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보를 포함하는 상기 시청 이력 정보를 생성하는 스텝을 포함하는
정보 처리 방법.
(12)
디지털 방송의 콘텐츠의 시청 이력에 관한 시청 이력 정보이며, 상기 콘텐츠를 재생한 기기가, 상기 디지털 방송의 규격에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보를 포함하는 상기 시청 이력 정보를 수신하는 수신부와,
복수의 기기로부터의 상기 시청 이력 정보를 수집하고, 수집된 복수의 상기 시청 이력 정보를 상기 기기 정보에 따라 처리하는 처리부
를 구비하는 정보 처리 장치.
(13)
상기 시청 이력 정보는 상기 기기 정보로서, 상기 디지털 방송의 규격에 대응한 대응 기기, 또는 상기 디지털 방송의 규격에 대응하고 있지 않은 비대응 기기 고유의 정보를 포함하는,
(12)에 기재된 정보 처리 장치.
(14)
상기 고유의 정보는, HTTP 리퀘스트의 유저 에이전트에 포함되는 정보인,
(13)에 기재된 정보 처리 장치.
(15)
상기 고유의 정보는, 상기 HTTP 리퀘스트가 상기 비대응 기기로부터의 것인 경우, IP 어드레스를 더 포함하는,
(14)에 기재된 정보 처리 장치.
(16)
상기 유저 에이전트는, 오퍼레이팅 시스템(OS)에 관한 정보와, 모바일 단말기인지 여부를 나타내는 정보를 적어도 포함하고 있는,
(13) 또는 (14)에 기재된 정보 처리 장치.
(17)
정보 처리 장치의 정보 처리 방법에 있어서,
상기 정보 처리 장치가,
디지털 방송의 콘텐츠의 시청 이력에 관한 시청 이력 정보이며, 상기 콘텐츠를 재생한 기기가, 상기 디지털 방송의 규격에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보를 포함하는 상기 시청 이력 정보를 수신하고,
복수의 기기로부터의 상기 시청 이력 정보를 수집하고, 수집된 복수의 상기 시청 이력 정보를 상기 기기 정보에 따라 처리하는
스텝을 포함하는 정보 처리 방법.
10: 송신 시스템
20: 대응 클라이언트 장치
30: 비대응 클라이언트 장치
50: 중계국
60: 인터넷
70: LAN
200: 제어부
201: 방송 미들웨어
202: HTTP 프록시 서버
203: 브라우저
204-1, 204-2: 통신 I/F
211: PHY·MAC 처리부
212: LLS 리트리버
213: LLS 파서
214: SLS 리트리버
215: SLS 파서
216: 세그먼트 리트리버
221 프록시 캐시
222: 프록시 캐시
223: 방송·통신 어드레스 리졸버
231: DASH 클라이언트
232: 디코더
233: 렌더러
241: MPD 리트리버
242: MPD 파서
243: 세그먼트 리트리버
244: MP4 파서
300: 제어부
301: 통신 I/F
302: 브라우저
311: DASH 클라이언트
312: 디코더
313: 렌더러
321: MPD 리트리버
322: MPD 파서
323: 세그먼트 리트리버
324: MP4 파서
1000: 컴퓨터
1001: CPU

Claims (17)

  1. 디지털 방송의 콘텐츠의 시청 이력에 관한 시청 이력 정보이며, 상기 콘텐츠를 재생한 기기가, 상기 디지털 방송의 규격에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보를 포함하는 상기 시청 이력 정보를 생성하는 시청 이력 처리부를 구비하는
    정보 처리 장치.
  2. 제1항에 있어서,
    상기 시청 이력 정보는 상기 기기 정보로서, 상기 디지털 방송의 규격에 대응한 대응 기기, 또는 상기 디지털 방송의 규격에 대응하고 있지 않은 비대응 기기 고유의 정보를 포함하는
    정보 처리 장치.
  3. 제2항에 있어서,
    상기 고유의 정보는 HTTP(Hypertext Transfer Protocol) 리퀘스트의 유저 에이전트에 포함되는 정보인
    정보 처리 장치.
  4. 제3항에 있어서,
    상기 고유의 정보는, 상기 HTTP 리퀘스트가 상기 비대응 기기로부터의 것인 경우, IP(Internet Protocol) 어드레스를 더 포함하는
    정보 처리 장치.
  5. 제3항에 있어서,
    상기 유저 에이전트는, 오퍼레이팅 시스템(OS: Operating System)에 관한 정보와, 모바일 단말기인지 여부를 나타내는 정보를 적어도 포함하고 있는
    정보 처리 장치.
  6. 제4항에 있어서,
    상기 디지털 방송의 방송파를 수신하는 수신부와,
    상기 방송파로부터 얻어지는, 상기 디지털 방송의 규격에 준거한 데이터를 처리하는 데이터 처리부와,
    상기 비대응 기기로부터 송신되어 오는 HTTP 리퀘스트에 따라, 네트워크를 통하여 상기 데이터 처리부로부터의 상기 데이터를 상기 비대응 기기에 송신하는 통신부
    를 더 구비하고,
    상기 시청 이력 처리부는, 상기 비대응 기기에서 재생된 상기 콘텐츠의 시청 이력에 대하여, 상기 비대응 기기로부터의 HTTP 리퀘스트로부터 얻어지는 유저 에이전트에 포함되는 정보와, 상기 비대응 기기에 할당된 IP 어드레스를 관련지은 상기 시청 이력 정보를 생성하는
    정보 처리 장치.
  7. 제6항에 있어서,
    상기 시청 이력 처리부는 HTTP 프록시 서버의 모듈로서 실장되는
    정보 처리 장치.
  8. 제6항에 있어서,
    상기 대응 기기 또는 상기 비대응 기기에 있어서, 상기 콘텐츠는 브라우저 상에서 재생되는
    정보 처리 장치.
  9. 제6항에 있어서,
    상기 통신부는 상기 시청 이력 정보를 네트워크를 통하여, 상기 시청 이력 정보를 수집하는 시청 이력 서버에 송신하는
    정보 처리 장치.
  10. 제6항에 있어서,
    상기 데이터 처리부로부터의 상기 데이터를 재생하는 재생부를 더 구비하는
    정보 처리 장치.
  11. 정보 처리 장치의 정보 처리 방법에 있어서,
    상기 정보 처리 장치가,
    디지털 방송의 콘텐츠의 시청 이력에 관한 시청 이력 정보이며, 상기 콘텐츠를 재생한 기기가, 상기 디지털 방송의 규격에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보를 포함하는 상기 시청 이력 정보를 생성하는 스텝을 포함하는
    정보 처리 방법.
  12. 디지털 방송의 콘텐츠의 시청 이력에 관한 시청 이력 정보이며, 상기 콘텐츠를 재생한 기기가, 상기 디지털 방송의 규격에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보를 포함하는 상기 시청 이력 정보를 수신하는 수신부와,
    복수의 기기로부터의 상기 시청 이력 정보를 수집하고, 수집된 복수의 상기 시청 이력 정보를 상기 기기 정보에 따라 처리하는 처리부
    를 구비하는 정보 처리 장치.
  13. 제12항에 있어서,
    상기 시청 이력 정보는 상기 기기 정보로서, 상기 디지털 방송의 규격에 대응한 대응 기기, 또는 상기 디지털 방송의 규격에 대응하고 있지 않은 비대응 기기 고유의 정보를 포함하는
    정보 처리 장치.
  14. 제13항에 있어서,
    상기 고유의 정보는 HTTP 리퀘스트의 유저 에이전트에 포함되는 정보인
    정보 처리 장치.
  15. 제14항에 있어서,
    상기 고유의 정보는, 상기 HTTP 리퀘스트가 상기 비대응 기기로부터의 것인 경우, IP 어드레스를 더 포함하는
    정보 처리 장치.
  16. 제14항에 있어서,
    상기 유저 에이전트는, 오퍼레이팅 시스템(OS)에 관한 정보와, 모바일 단말기인지 여부를 나타내는 정보를 적어도 포함하고 있는
    정보 처리 장치.
  17. 정보 처리 장치의 정보 처리 방법에 있어서,
    상기 정보 처리 장치가,
    디지털 방송의 콘텐츠의 시청 이력에 관한 시청 이력 정보이며, 상기 콘텐츠를 재생한 기기가, 상기 디지털 방송의 규격에 준거한 데이터를 처리 가능한 기기인지 여부를 나타내는 기기 정보를 포함하는 상기 시청 이력 정보를 수신하고,
    복수의 기기로부터의 상기 시청 이력 정보를 수집하고, 수집된 복수의 상기 시청 이력 정보를 상기 기기 정보에 따라 처리하는
    스텝을 포함하는 정보 처리 방법.
KR1020197000156A 2016-07-15 2017-06-30 정보 처리 장치 및 정보 처리 방법 KR20190029572A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2016140379 2016-07-15
JPJP-P-2016-140379 2016-07-15
PCT/JP2017/024103 WO2018012315A1 (ja) 2016-07-15 2017-06-30 情報処理装置、及び、情報処理方法

Publications (1)

Publication Number Publication Date
KR20190029572A true KR20190029572A (ko) 2019-03-20

Family

ID=60952416

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020197000156A KR20190029572A (ko) 2016-07-15 2017-06-30 정보 처리 장치 및 정보 처리 방법

Country Status (8)

Country Link
US (1) US20200053406A1 (ko)
EP (1) EP3487182A4 (ko)
JP (1) JPWO2018012315A1 (ko)
KR (1) KR20190029572A (ko)
BR (1) BR112019000345A2 (ko)
CA (1) CA3029413A1 (ko)
MX (1) MX2018016225A (ko)
WO (1) WO2018012315A1 (ko)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009278651A (ja) 2009-07-27 2009-11-26 Sony Corp 放送システム、並びに受信装置および受信方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070143776A1 (en) * 2005-03-01 2007-06-21 Russ Samuel H Viewer data collection in a multi-room network
US9203813B2 (en) * 2013-03-15 2015-12-01 Panasonic Intellectual Property Management Co., Ltd. Content distribution method, content distribution system, source device, and sink device

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009278651A (ja) 2009-07-27 2009-11-26 Sony Corp 放送システム、並びに受信装置および受信方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ATSC Candidate Standard: Service Usage Reporting(A/333) Doc. S33-170r316 May 2016
ATSC Candidate Standard: Signaling, Delivery, Synchronization, and Error Protection(A/331) Doc. S33-174r15 January 2016

Also Published As

Publication number Publication date
US20200053406A1 (en) 2020-02-13
EP3487182A1 (en) 2019-05-22
BR112019000345A2 (pt) 2019-04-16
CA3029413A1 (en) 2018-01-18
MX2018016225A (es) 2019-05-30
JPWO2018012315A1 (ja) 2019-05-16
WO2018012315A1 (ja) 2018-01-18
EP3487182A4 (en) 2019-05-22

Similar Documents

Publication Publication Date Title
CN108293148B (zh) 接收装置、发送装置以及数据处理方法
US8832750B2 (en) Media synchronization within home network using set-top box as gateway
JP7070630B2 (ja) 受信方法、及び、送信方法
CN103081507B (zh) 集成并处理到视频流中相关视频内容的嵌入式链接以提供广告信息
KR102332387B1 (ko) 수신 장치, 수신 방법, 송신 장치 및 송신 방법
KR102499231B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
KR102496890B1 (ko) 정보 처리 장치, 클라이언트 장치, 및 데이터 처리 방법
WO2018079295A1 (ja) 情報処理装置、及び、情報処理方法
KR102461599B1 (ko) 수신 장치, 수신 방법, 송신 장치, 및, 송신 방법
US11012761B1 (en) Techniques for replacement content signaling in advanced television systems committee (ATSC) 3.0 television
KR20190029572A (ko) 정보 처리 장치 및 정보 처리 방법
CA3071560C (en) Transmission apparatus, transmission method, reception apparatus, and reception method
KR102319932B1 (ko) 수신 장치 및 수신 방법, 재생 장치 및 재생 방법, 공급 장치 및 공급 방법, 그리고 프로그램
US9219931B2 (en) Method and apparatus for transmitting and receiving service discovery information in multimedia transmission system and file structure for the same
KR102600762B1 (ko) Atsc 3.0 기반의 방송 콘텐츠 전송 장치 및 방법과, 방송 콘텐츠 수신 장치 및 방법
US20230412858A1 (en) Obfuscating replaceable content in advanced television systems committee (atsc) 3.0 system
Whitaker et al. Progress Report of the Advanced Television Systems Committee
JP2009124428A (ja) コンテンツ配信方法および配信システム

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
WITB Written withdrawal of application