KR102134597B1

KR102134597B1 - 불투명 사용자 데이터를 시그널링하기 위한 방법

Info

Publication number: KR102134597B1
Application number: KR1020187029517A
Authority: KR
Inventors: 시우 엔지; 키란 무케시 미스라; 사친 지. 데시판데; 크리스토퍼 앤드류 세갈
Original assignee: 샤프 가부시키가이샤
Priority date: 2016-03-01
Filing date: 2017-03-01
Publication date: 2020-07-16
Also published as: CA3021346C; MX2018012768A; CN109275035A; CN108702548A; KR20180107781A; CA3015749C; US20190069043A1; CA3015749A1; KR20180115803A; MX2018010333A; WO2017150607A1; CA3021346A1; US10506302B2; US20190200100A1

Abstract

디바이스는 워터마크들을 이용하여 정보를 시그널링하도록 구성될 수 있다. 디바이스는 멀티미디어 콘텐츠와 연관된 자원의 주소와 연관된 식별자를 결정하고 이 식별자를 멀티미디어 콘텐츠를 나타내는 신호에 임베딩하도록 구성될 수 있다. 디바이스는, 멀티미디어 신호를 수신하고, 멀티미디어 신호로부터 자원의 주소와 연관된 식별자를 파싱하고, 식별자를 포함하는 질의를 생성하고, 질의에 응답하여 보충 콘텐츠를 수신하도록 구성될 수 있다.

Description

불투명 사용자 데이터를 시그널링하기 위한 방법{METHOD FOR SIGNALING OPAQUE USER DATA}

본 개시내용은 대화형 텔레비전 분야에 관한 것이다.

디지털 미디어 재생 능력은, 소위 "스마트" 텔레비전을 포함한 디지털 텔레비전, 셋탑 박스, 랩탑 또는 데스크탑 컴퓨터, 태블릿 컴퓨터, 디지털 기록 디바이스, 디지털 미디어 재생기, 비디오 게임 디바이스, 소위 "스마트" 폰을 포함한 셀룰러 전화, 전용 비디오 스트리밍 디바이스 등을 포함하는, 다양한 디바이스들 내에 통합될 수 있다. 디지털 미디어 콘텐츠(예를 들어, 비디오 및/또는 오디오 프로그래밍, 및 애플리케이션 기반의 강화)는, 예를 들어, 공중파 텔레비전 제공자 또는 방송사, 위성 텔레비전 제공자, 케이블 텔레비전 제공자, 소위 스트리밍 서비스 제공자를 포함한 온라인 미디어 서비스 제공자 등을 포함한, 복수의 소스로부터 발생 및/또는 배포될 수 있다. 디지털 미디어 콘텐츠는, 인터넷 프로토콜(IP) 네트워크 등의 양방향 네트워크 및 디지털 방송 네트워크 등의 단방향 네트워크를 포함한, 패킷 교환형 네트워크를 통해 전달될 수 있다.

디지털 미디어 콘텐츠는, 전송 표준에 따라 소스로부터 수신기 디바이스(예를 들어, 디지털 텔레비전 또는 스마트 폰)로 전송될 수 있다. 전송 표준의 예로서는, DVB(Digital Video Broadcasting) 표준, ISDB(Integrated Services Digital Broadcasting Standards) 표준, 및 예를 들어 ATSC 2.0 표준을 비롯한 ATSC(Advanced Television Systems Committee)에 의해 개발된 표준이 포함된다. ATSC는 현재 소위 ATSC 3.0 표준 스위트를 개발하고 있는 중이다. 전송 표준은 전송을 위해 디지털 미디어 콘텐츠를 캡슐화하기 위한 메커니즘을 정의할 수 있고, 디지털 미디어 콘텐츠와 연관된 정보를 시그널링하기 위한 메커니즘을 정의할 수 있다. 디지털 미디어 콘텐츠와 연관된 정보를 시그널링하기 위한 현재의 기술은 이상적이지 않을 수 있다.

일반적으로, 본 개시내용은 자원 식별자를 시그널링하기 위한 기술을 설명한다. 특히, 본 개시내용은 워터마크를 이용하여 자원 식별자를 시그널링하기 위한 예시적인 기술을 설명한다. 본 명세서에서 설명된 기술들은 자원 식별자가 워터마크를 이용하여 시그널링될 때 보안을 증가시키는데 이용될 수 있다. 본 명세서에서 설명된 기술들은 멀티미디어 프레젠테이션의 재배포에 특히 유용할 수 있다. 일부 예에서 본 개시내용의 기술들이 현재 개발중인 것들을 포함한 ATSC 표준에 관하여 설명되지만, 본 명세서에서 설명된 기술들은 일반적으로 임의의 전송 표준에 적용가능하다는 점에 유의해야 한다. 예를 들어, 본 명세서에서 설명된 기술들은, 일반적으로, DVB 표준, ISDB 표준, ATSC 표준, DTMB(Digital Terrestrial Multimedia Broadcast) 표준, DMB(Digital Multimedia Broadcast) 표준, HbbTV(Hybrid Broadcast and Broadband Television) 표준, 및 기타의 비디오 인코딩 표준들 중 임의의 것에 적용가능하다. 또한, 참조에 의한 문서의 포함은 설명의 목적을 위한 것이며 본 명세서에서 사용된 용어와 관련하여 모호성을 제한 및/또는 생성하도록 해석되어서는 안 된다는 점에 유의해야 한다. 예를 들어, 하나의 포함된 참조가 또 다른 포함된 참조와는 상이한 용어의 정의를 제공하거나 및/또는 그 용어가 본 명세서에서 사용되는 경우, 그 용어는 각각의 해당 정의를 광범위하게 포함하는 방식으로 및/또는 특정한 정의들 각각을 대안적 방식으로 포함하는 방식으로 해석되어야 한다.

본 발명의 한 양태는 보충 콘텐츠를 요청하기 위한 방법으로서, 멀티미디어 신호를 수신하는 단계; 상기 멀티미디어 신호로부터 워터마크 메시지를 추출하는 단계; 상기 워터마크 메시지로부터 권한 컴포넌트의 일부를 지시하는 신택스 요소를 파싱하는 단계; 상기 워터마크 메시지로부터 경로 컴포넌트를 지시하는 신택스 요소를 파싱하는 단계; 및 상기 권한 컴포넌트의 일부 및 상기 경로 컴포넌트를 포함하는 자원 식별자를 형성함으로써 보충 콘텐츠에 대한 요청을 구성하는 단계를 포함한다.

본 발명의 한 양태는 하나 이상의 프로세서를 포함하는 디바이스로서, 상기 하나 이상의 프로세서는 : 멀티미디어 신호로부터 워터마크 메시지를 추출하고; 상기 워터마크 메시지로부터 권한 컴포넌트의 일부를 지시하는 신택스 요소를 파싱하며; 상기 워터마크 메시지로부터 경로 컴포넌트를 지시하는 신택스 요소를 파싱하며; 상기 권한 컴포넌트의 일부 및 상기 경로 컴포넌트를 포함하는 자원 식별자를 형성함으로써 보충 콘텐츠에 대한 요청을 구성하도록 구성된다.

본 발명의 한 양태는 워터마크 메시지의 페이로드에서 불투명 사용자 데이터(opaque user data)를 시그널링하기 위한 방법으로서, 정보에 대해 요구되는 데이터 단편(data fragment)들의 수를 결정하는 단계; 상기 정보에 대해 요구되는 데이터 단편들의 수에 기초하여 메시지 블록 유형을 식별하는 신택스 요소를 시그널링하는 단계; 및 상기 메시지 블록 페이로드의 길이를 지시하는 신택스 요소 ―메시지 블록 페이로드의 길이를 지시하는 신택스 요소의 비트수는 메시지 블록 유형에 기초함― 를 시그널링하는 단계를 포함한다.

도 1은 본 개시내용의 하나 이상의 기술을 구현할 수 있는 시스템의 한 예를 나타내는 블록도이다.
도 2는 본 개시내용의 하나 이상의 기술을 구현할 수 있는 셋탑 박스의 한 예 및 수신기 디바이스의 한 예를 나타내는 블록도이다.
도 3a는 본 개시내용의 하나 이상의 기술에 따른 자원 식별자를 시그널링하는 한 예를 나타내는 통신 흐름도이다.
도 3b는 본 개시내용의 하나 이상의 기술에 따른 자원 식별자를 시그널링하는 한 예를 나타내는 통신 흐름도이다.
도 4는 본 개시내용의 하나 이상의 기술에 따른 자원 식별자 정보를 시그널링하는 한 예를 나타내는 플로차트이다.
도 5는 본 개시내용의 하나 이상의 기술에 따른 자원 식별자 정보를 파싱하는 한 예를 나타내는 플로차트이다.

컴퓨팅 디바이스 및/또는 전송 시스템은 하나 이상의 추상화 계층을 포함하는 모델에 기초할 수 있고, 여기서 각각의 추상화 계층의 데이터는, 특정한 구조, 예를 들어, 패킷 구조, 변조 방식 등에 따라 표현된다. OSI(Open Systems Interconnection) 모델은, 애플리케이션 계층, 프리젠테이션 계층, 세션 계층, 트랜스포트 계층, 네트워크 계층, 데이터 링크 계층, 및 물리 계층을 포함한 7-계층 스택 모델을 정의한다. 스택 모델(예를 들어, 콘텐츠 전달 프로토콜 모델) 내의 계층들을 기술하는 것과 관련하여 상위 및 하위라는 용어의 사용은 최상위 계층인 애플리케이션 계층 및 최하위 계층인 물리 계층에 기초할 수 있다는 점에 유의해야 한다. 또한, 일부 경우에, "계층 1" 또는 "L1"이라는 용어는 물리 계층을 지칭하기 위해 사용될 수 있고, "계층 2" 또는 "L2"는 링크 계층을 지칭하기 위해 사용될 수 있으며, "계층 3" 또는 "L3" 또는 "IP 계층"은 네트워크 계층을 지칭하기 위해 사용될 수 있다. 물리 계층이란 일반적으로 전기 신호가 디지털 데이터를 형성하는 계층을 말할 수 있다. 예를 들어, 물리 계층이란, 변조된 무선 주파수(RF) 심볼들이 디지털 데이터의 프레임을 형성하는 방법을 정의하는 계층을 말할 수 있다. 링크 계층이라고도 하는 데이터 링크 계층은, 전송측에서의 물리 계층 처리 이전으로서 수신측에서의 물리 계층 수신 이후에 이용되는 추상화를 지칭할 수 있다. 전송측과 수신측은 논리적 역할이며 단일의 디바이스가 한 순간에서는 전송측으로서 또 다른 순간에서는 수신측으로서 모두 동작할 수 있다는 점에 유의해야 한다. 네트워크 계층이란 일반적으로 논리적 어드레싱이 발생하는 계층을 말할 수 있다. 즉, 네트워크 계층은 일반적으로, 데이터 패킷이 네트워크 내의 특정한 노드(예를 들어, 컴퓨팅 디바이스)에 전달될 수 있도록 어드레싱 정보(예를 들어, 인터넷 프로토콜(IP) 주소)를 제공할 수 있다. 트랜스포트 계층, 세션 계층, 프리젠테이션 계층 및 애플리케이션 계층 각각은, 사용자 애플리케이션에서 이용하기 위해 데이터가 전달되는 방법을 정의할 수 있다.

디지털 미디어 콘텐츠와 관련하여, 워터마킹이란 일반적으로 정보를 비디오 및/또는 오디오 신호에 임베딩하는 프로세스를 말할 수 있다. 즉, 일부 예에서, 워터마킹은 상위 계층 신호로부터(예를 들어, 멀티미디어 데이터의 프리젠테이션 또는 렌더링을 가능하게 하는 신호로부터) 보충 데이터가 추출되게 할 수 있다. 워터마크는 재배포 시나리오에서 유용할 수 있다. 재배포 시나리오의 한 예는 디바이스가 멀티미디어 신호(예를 들어, 비디오 및/또는 오디오 신호)를 수신하고 멀티미디어 신호로부터 임베딩된 정보를 복구하는 상황을 포함할 수 있다. 예를 들어, 수신기 디바이스(예를 들어, 디지털 텔레비전)는 멀티미디어 인터페이스(예를 들어, HDMI(High Definition Multimedia Interface) 등)로부터 압축되지 않은 비디오 신호를 수신할 수 있고, 수신기 디바이스는 압축되지 않은 비디오 신호로부터 임베딩된 정보를 복구할 수 있다. 일부 경우에, 소위 멀티-채널 비디오 프로그램 배포자(MVPD)(예를 들어, 케이블 TV 서비스 운영자, 위성 텔레비전 서비스 운영자, 인터넷 프로토콜 텔레비전(IPTV) 서비스 운영자 등)가 수신기 디바이스와 콘텐츠 제공자(예를 들어, 지역 네트워크 제휴사) 사이에서 중재자 역할을 할 때 재배포 시나리오가 발생할 수 있다. 이들 경우에, 셋탑 박스는, 특정한 물리 계층, 링크 계층, 및/또는 네트워크 계층을 통해 멀티미디어 서비스 데이터 스트림을 수신하고 압축되지 않은 멀티미디어 신호를 수신기 디바이스에 출력할 수 있다. 따라서, 재배포 시나리오에서, 수신기 디바이스는 콘텐츠 전달 프로토콜 모델의 하위 계층에 액세스하지 않고 멀티미디어 신호를 수신할 수 있다. 일부 예에서, 재배포 시나리오는, 셋탑 박스 또는 홈 미디어 서버가 가정내 비디오 배포기로서 역할하고 데이터를 (예를 들어, 로컬 유선 또는 무선 네트워크를 통해) 접속된 디바이스들(예를 들어, 스마트 폰, 태블릿 등)에 서비스하는 상황을 포함할 수 있다는 점에 유의해야 한다.

워터마킹은, 수신기 디바이스가, 멀티미디어 콘텐츠가 어떻게 배포되는지에 관계없이, 보충 콘텐츠(예를 들어, 비상상황 메시지, 대체 오디오 트랙, 애플리케이션 데이터, 폐쇄 자막 데이터 등)를 회수할 수 있도록 보장하는데 유용할 수 있다. 일부 경우에, 콘텐츠 제공자는 콘텐츠가 시청자에게 렌더링될 때 보충 콘텐츠가 이용가능도록 보장하기를 원할 수 있다. 예를 들어, 로컬 네트워크 제휴사는 비디오 신호에 워터마크를 임베딩하여 수신기 디바이스가 로컬 텔레비전 프리젠테이션(예를 들어, 로컬 뉴스 브로드캐스트)과 연관된 보충 정보를 회수하고 그에 따라 보충 콘텐츠를 시청자에게 프리젠팅할 수 있도록 보장할 수 있다. 또한, 어떤 경우에는, MVPD는 콘텐츠 제공자로부터 나오는 콘텐츠를 강화하기 위해(예를 들어, 타겟팅된 보충 광고를 제공하기 위해) 비디오 신호에 워터마크를 임베딩할 수 있다.

본 명세서에서 사용될 때, 수신기 디바이스라는 용어는 비디오 및/또는 오디오 신호를 수신할 수 있고 시각 및 청각 데이터가 수신된 신호로부터 렌더링되도록 할 수 있는 디바이스(예를 들어, 압축되지 않은 멀티미디어 신호를 수신하는 디지털 텔레비전)를 지칭할 수 있다는 점에 유의해야 한다. 또한, 셋탑 박스라는 용어는, 멀티미디어 서비스 데이터 스트림(예를 들어, 공중파 방송, 케이블 텔레비전 서비스, 위성 텔레비전 서비스, 소위 OTT(over the top) 텔레비전 서비스 등) 및 수신기 디바이스에 의해 프리젠팅하기 위해 렌더링될 수 있는 비디오 및/또는 오디오 신호를 출력하도록 구성된 디바이스를 지칭할 수 있다. 수신기 디바이스 및 셋탑 박스의 이러한 예시적인 정의는 본 명세서에 설명된 기술들의 범위를 제한하도록 해석되어서는 안 된다는 점에 유의해야 한다. 예를 들어, 단일의 디바이스가 셋탑 박스 및 수신 디바이스의 기능을 수행하도록 구성될 수 있다. 즉, 예를 들어, 디지털 텔레비전은 멀티미디어 서비스 데이터 스트림을 수신하고 압축해제된 멀티미디어 신호를 추출하여 그로부터 멀티미디어 콘텐츠를 렌더링하는 하위 계층 처리를 수행하도록 구성될 수 있다. 또한, 본 명세서에서 설명된 기술들은 멀티미디어 콘텐츠가 기술되는 방식에 관계없이 워터마크에 일반적으로 적용될 수 있다. 예를 들어, 본 명세서에서 설명된 기술들은 물리적 매체(예를 들어, 광 디스크)를 이용하여 배포된 멀티미디어 콘텐츠에 포함된 워터마크에 적용될 수 있다.

일부 예에서, 워터마크는 자원 식별자를 시그널링할 수 있다. 본 명세서에서 사용될 때, 자원 식별자는, URI, URL, URN(Universal Resource Name), 이들의 조합, 및/또는 이들의 컴포넌트들을 포함할 수 있다. 그 전체내용이 참조로 본 명세서에 포함되는 Request for Comments (RFC) 3986 IETF: "Uniform Resource Identifiers (URI): Generic Syntax," RFC 3986, January, 2005에서 설명되는 바와 같이, URI는 일반적으로 다음과 같은 포멧에 따라 배열된 컴포넌트 부분들을 갖는 것으로서 기술될 수 있다 :

scheme://authority/path

상기 예에서, scheme 컴포넌트는 정의된 스킴(예를 들어, HTTP, HTTP Secure(HTTPS), 파일 전송 프로토콜(FTP) 등)을 포함할 수 있고, authority 컴포넌트는, 호스트, 예를 들어 등록된 명칭(예를 들어, 도메인 명칭)에 의해 식별되는 호스트를 포함할 수 있고, path 컴포넌트는 특정한 자원을 식별하기 위한 경로 세그먼트들의 시퀀스를 포함할 수 있다.

현재 개발중인 전송 표준을 포함한 전송 표준들은, 준수하는 디바이스들이 데이터를 추출할 수 있는 워터마크 방출 프로토콜 및 그로부터 추출될 수 있는 데이터의 유형을 명시할 수 있다. 현재 개발중인 ATSC 3.0 표준 스위트의 양태들은, ATSC 3.0 표준의 공개된(즉, "최종" 또는 "채택된") 버전에 포함시키기 위한 제안된 양태들을 포함할 수 있는 Candidate Standards에서 기술되어 있다. 그 전체내용이 참조로 본 명세서에 포함되는 ATSC Candidate Standard: Video Watermark Emission (A/335), Doc. S33-156r1, 30 November 2015 (이하 "A/335")는, ATSC 3.0 시스템 내에서 이용하기 위한 비디오 워터마크에 대한 방출 포멧의 구체적인 제안된 양태들을 기술한다. 그 전체내용이 참조로 본 명세서에 포함되는 ATSC Candidate Standard: Audio Watermark Emission (A/334), Doc. S33-160r4, 19 August 2016 (이하 "A/334")는, ATSC 3.0 시스템 내에서 이용하기 위한 오디오 워터마크에 대한 방출 포멧의 구체적인 제안된 양태들을 기술한다. 또한, 그 전체내용이 참조로 본 명세서에 포함되는 ATSC Candidate Standard: Content Recovery (A/336), Doc. S33-178r2, 15 January 2016, and its subsequent revisions, including Doc. S33-3-327r7, 12 September 2016 (이하, 집합적으로 "A/336"라고 언급됨)는, 소정의 시그널링 정보가 오디오 워터마크 페이로드, 비디오 워터마크 페이로드, 및 오디오 트랙의 사용자 영역에서 운반될 수 있는 방법, 및 재배포 시나리오에서 보충 콘텐츠를 액세스하기 위해 이 정보가 이용될 수 있는 방법을 명시한다.

A/335에 따르면, 비디오 워터마크는 비디오 프레임의 상단 라인들의 루마 값(luma value)에 데이터 신호를 임베딩할 수 있다. 비디오 프레임의 상단 라인들은 통상적으로 디스플레이되지 않으므로 이 경우 워터마크가 시청자에게 인지되지 않을 수 있다는 점에 유의해야 한다. A/336은 비디오 워터마크 페이로드가 하나 이상의 유형의 메시지를 포함할 수 있는 경우를 기술한다. 표 1은, 문서 S33-178r2, 15 January 2016 of A/336 (이하 "A/336r2"에서 제공되는 비디오 워터마크 페이로드에 포함된 메시지에 대한 신택스를 제공한다.

[표 1]

A/336r2는 각각의 신택스 요소들, wm_message_id, wm_message_block_length, wm_message_version, fragment_number, last_fragment, wm_message_bytes(), message_CRC_32, 및 CRC_32에 대해 다음과 같은 정의를 제공한다. 표 1 및 본 개시내용에 포함된 다른 표들에서, uimsbf는, 최상위 비트가 먼저 전송되는, 부호없는 정수를 지칭할 수 있다는 점에 유의해야 한다. 또한, 일부 예에서, wm_message_id, wm_message_block_length, wm_message_version, fragment_number, 및 last_fragment는, 워터마크 메시지의 헤더를 형성하는 것이라고 지칭될 수 있고, wm_message_bytes()는 워터마크 메시지의 인스턴스라고 지칭될 수 있다는 점에 유의해야 한다.

wm_message_id ― 이 8비트 값은, 아래의 표 [2]에 따라 코딩된, 메시지 블록에서 운반된 데이터 바이트들의 신택스 및 의미를 고유하게 식별한다.

[표 2]

wm_message_block_length ― 이 8비트 값은 이 필드 직후에 오고 CRC_32 필드를 포함한 CRC_32 필드까지의 wm_message_block()의 남은 바이트 수를 명시한다.

wm_message_version ― 이 4비트 값은 wm_message() 내의 임의의 것이 변경될 때에만 증가하고, 그 값이 15에 도달한 후에는 0으로 되돌아 온다. 수신 디바이스 내의 워터마크 프로세서는 wm_message_version을 이용하여 중복된 내용을 폐기할 것으로 기대된다. 비디오 신호는 전달의 안정성을 향상시키기 위해 동일한 wm_message()의 반복된 인스턴스를 포함할 수 있다.

fragment_number ― 이 2비트 값은 현재의 메시지 단편의 번호에서 1을 뺀 수를 명시한다. 예를 들어, fragment_number의 '00' 값은 wm_message_block()이 메시지의 첫 번째(또는 유일한) 단편을 운반한다는 것을 지시하고, '01'의 fragment_number 값은 wm_message_block()이 메시지의 두 번째 단편을 운반한다는 것을 지시한다. fragment_number의 값은 last_fragment의 값보다 작거나 같다.

last_fragment ― 이 2비트 값은 완전한 wm_message()를 전달하는데 이용되는 마지막 단편의 단편 번호를 명시한다. last_fragment의 '00' 값은 단편화가 이용되지 않는다는 것을 지시한다(내부에 포함된 wm_message()는 완전함). last_fragment의 '01' 값은 wm_message()가 2개 부분으로 전달된다는 것을 지시하고, '10' 값은 wm_message()가 3개 부분으로 전달된다는 것을 지시하며, '11' 값은 4개의 부분으로 전달된다는 것을 지시한다. fragment_number and last_fragment 값들의 쌍은 "N의 부분 M"를 시그널링하는 것으로 간주될 수 있다.

wm_message_bytes() ― last_fragment의 값이 0 일 때, wm_message_bytes()는 wm_message_id 값에 의해 식별되는 워터마크 메시지의 완전한 인스턴스이다. last_fragment의 값이 0이 아닐 때, wm_message_bytes()는 그 워터마크 메시지의 단편이며, 여기서, 각각의 단편은 [A/336r2의] 섹션 5.1.2에 주어진 규칙에 따라 구성된다. 주어진 wm_message_id 및 wm_message_fragment_version 번호에 의해 wm_message_block()의 모든 인스턴스들의 연결은, 그 wm_message_id와 연관된 완전한 wm_message()가 된다.

message_CRC_32 ― 메시지가 2개 이상의 단편으로 전송될 때(예를 들어, last_fragment> 0), (단편화 이전의) 완전한 메시지를 커버하는 32비트[Cyclic Redundancy Check(CRC)]가 단편화된 메시지의 마지막 단편에서 제공되어야 한다. message_CRC_32 필드는 비단편화된 메시지(예를 들어, last_fragment의 값이 0 일 때) 또는 마지막이 아닌 임의의 단편(예를 들어, fragment_number ≠ last_fragment)에는 존재하지 않아야 한다. message_CRC_32는, 존재할 때, 전체 재조립된 메시지 페이로드를 처리한 후에, 그 전체내용이 참조로 본 명세서에 포함되는, ISO/IEC 13818-1 [ISO: "ISO/IEC IS 13818-1(2013) (E), International Standard, Information technology - Generic coding of moving pictures and associated audio information: systems," Annex A에서 정의된 디코더 내의 레지스터들의 제로 출력을 제공하는 CRC 값을 포함해야 한다. 생성 다항식은, 1 + x + x² + x⁴ + x⁵ + x⁷ + x⁸ + x¹⁰ + x¹¹ + x¹² + x¹⁶ + x²² + x²³ + x²⁶이다.

CRC_32 ― 이 32비트 필드는 전체 메시지 블록을 처리한 후에 ISO/IEC 13818-1, Annex A에서 정의된 디코더 내의 레지스터들의 제로 출력을 제공하는 CRC 값을 포함해야 한다. 생성 다항식은, 1 + x + x² + x⁴ + x⁵ + x⁷ + x⁸ + x¹⁰ + x¹¹ + x¹² + x¹⁶ + x²² + x²³ + x²⁶이다.

표 3은 문서 S33-3-327r7, 12 September 2016 of A/336 (이하, "A/336r7")에서 제공되는 바와 같은 비디오 워터마크 페이로드에 포함된 메시지에 대한 신택스를 제공한다.

[표 3]

A/336r7에서, 각각의 신택스 요소 wm_message_block_length 및 wm_message_version에 대한 정의는 표 1에 관하여 상기에서 제공되는 것과 유사하다. A/336r7은, 각각의 신택스 요소 wm_message_id, fragment_number, last_fragment, wm_message_bytes(), message_CRC_32, 및 CRC_32에 대해 다음과 같은 정의를 제공한다.

wm_message_id ― 이 8비트 값은, 아래의 표 [4]에 따라 코딩된, 메시지 블록에서 운반된 데이터 바이트들의 신택스 및 의미를 고유하게 식별한다.

[표 4]

fragment_number ― 이 2비트 또는 8비트 값은 현재의 메시지 단편의 번호에서 1을 뺀 수를 명시한다. (wm_message_id & 0x40) == 0 일 때, 즉, 비트 6이 값 '0'일 때, fragment_number는 2비트 길이가 되어야 한다. (wm_message_id & 0x40) == 1 일 때, 즉, 비트 6이 값 '1'일 때, fragment_number는 8비트 길이가 되어야 한다. 예를 들어, fragment_number의 '0' 값은 wm_message_block()이 메시지의 첫 번째(또는 유일한) 단편을 운반한다는 것을 지시하고, '1'의 fragment_number 값은 wm_message_block()이 메시지의 두 번째 단편을 운반한다는 것을 지시한다. fragment_number의 값은 last_fragment의 값보다 작거나 같다.

last_fragment ― 이 2비트 또는 8비트 값은 완전한 워터마크 메시지를 전달하는데 이용되는 마지막 단편의 단편 번호를 명시해야 한다. (wm_message_id & 0x40) == 0)일 때, 즉, 비트 6이 값 '0'일 때, last_fragment는 2비트 길이가 되어야 한다. (wm_message_id & 0x40) == 1 일 때, 즉, 비트 6이 값 '1'일 때, last_fragment는 8비트 길이가 되어야 한다. last_fragment의 제로 값은 분할이 이용되지 않는다는 것을 지시한다(내부에 포함된 워터마크 메시지는 완전함). last_fragment의 값 1은 wm_message()가 2개 부분으로 전달된다는 것을 지시하고, 값 2는 워터마크 메시지가 3개 부분으로 전달된다는 것을 지시하며, 값 3은 4개 부분으로 전달된다는 것을 지시한다. 값들 fragment_number와 last_fragment의 쌍은 "N의 부분 M"을 시그널링하는 것으로 간주될 수 있다.

wm_message_bytes() ― last_fragment의 값이 0 일 때, wm_message_bytes()는 wm_message_id의 값에 의해 식별되는 워터마크 메시지의 완전한 인스턴스가 된다. last_fragment의 값이 0이 아닐 때, wm_message_bytes()는 그 워터마크 메시지의 단편이 된다. wm_message_id 및 wm_message_fragment_version 번호에 의해 wm_message_block()의 모든 인스턴스들의 연결은 그 wm_message_id와 연관된 완전한 워터마크 메시지가 된다.

message_CRC_32 ― 메시지가 2개 이상의 단편으로 전송될 때(예를 들어, last_fragment> 0), (분할 이전의) 완전한 메시지를 커버하는 32비트 CRC가 단편화된 메시지의 마지막 단편에 제공되어야 한다. message_CRC_32 필드는 비단편화된 메시지(예를 들어, last_fragment의 값이 0 일 때) 또는 마지막이 아닌 임의의 단편(예를 들어, fragment_number ≠ last_fragment)에는 존재하지 않아야 한다. message_CRC_32는, 존재할 때, 표 [5]에 명시된 바와 같이 wm_message_id와 wm_message_bytes(i)를 연결함으로써 형성된 전체의 재조립된 메시지 페이로드를 처리한 후 ISO/IEC 13818-1, Annex A에서 정의된 디코더 내의 레지스터들의 제로 출력을 제공하는 CRC 값을 포함해야 한다.

생성 다항식은 1 + x + x² + x⁴ + x⁵ + x⁷ + x⁸ + x¹⁰ + x¹¹ + x¹² + x¹⁶ + x²² + x²³ + x²⁶이어야 한다.

[표 5]

표 5와 관련하여, wm_message_block()은 추가 처리되기 전에 재조립하고자 하는 워터마크 메시지의 단편을 전달할 수 있다. 아래의 표 5에 명시된 wm_message() 데이터 구조는 재조립된 단편들을 나타낸다. 표 5의 wm_message_id, last_fragment, 및 message_CRC_32의 정의는, wm_message_block()에 대해 상기에서 명시된 바와 같아야 한다. wm_message_bytes(i) 필드는 (0부터 카운팅되는) 메시지의 i번째 단편에 포함된 wm_message_bytes()를 나타낸다.

CRC_32 ― 이 32비트 필드는 전체 메시지 블록을 처리한 후에 ISO/IEC 13818-1, Annex A에서 정의된 디코더 내의 레지스터들의 제로 출력을 제공하는 CRC 값을 포함해야 한다. 생성 다항식은 1 + x + x² + x⁴ + x⁵ + x⁷ + x⁸ + x¹⁰ + x¹¹ + x¹² + x¹⁶ + x²² + x²³ + x²⁶이어야 한다.

표 1-2 및 표 3-4를 참조하면, A/336은 비디오 워터마크 페이로드가 uri_message()를 포함할 수 있는 경우를 기술한다. uri_message()는 URI(Universal Resource Indentifier) 메시지를 참조할 수 있고 다양한 유형의 URI를 전달하는 데 이용될 수 있다. 표 6은 A/336에서 제공된 uri_message()의 신택스를 제공한다.

[표 6]

A/336은 신택스 요소들 uri_type, uri_strlen 및 URI_string()에 대해 다음과 같은 정의를 제공한다.

uri_type ― 표 [7]에서 주어진 인코딩에 따라, 추종하는 URI의 유형을 식별하는 8비트의 부호없는 정수 필드.

[표 7]

uri_strlen ― 추종하는 uri_string() 내의 문자 수를 시그널링하는 8비트 부호없는 정수. uri_strlen 필드의 값은 1X 비디오 워터마크 방출 포맷(1X 시스템)의 경우 [A/336r2에서 86, A/336r7에서 78]보다 작거나 같아야 하고, [A/335에서 제공되는] 2X 비디오 워터마크 방출 포맷(2X 시스템)의 경우[A/336r2의 206 및 A/336r7의 198]보다 작거나 같아야 한다.

URI_string() ― 그 값들이 RFC 3986에 의해 URI(Uniform Resource Identifier)에 대해 허용된 것들로 제한되는 문자들로 구성된 URI. 문자열의 길이는 uri_strlen의 값에 의해 주어진다. 캐릭터 문자열은, URI가 단편들로 전송되는 경우 재조립 후, RFC 3986에 따른 유효한 URI이어야 한다.

표 6과 관련하여, URI_string()은 RFC 3986에 제공된 임의의 유효한 URI를 포함할 수 있고, 따라서, 완전한 URL(Universal Resource Locator)을 포함할 수 있으며, 권한 컴포넌트의 가능한 값들에 관하여 제한되지 않는다는 점에 유의해야 한다. URI의 권한 컴포넌트는 아래에서 더 상세히 설명된다.

표 1-2 및 표 3-4를 참조하면, A/336은 비디오 워터마크 페이로드가 emergency_alert_message()를 포함할 수 있는 경우를 설명한다. emergency_alert_message()는 비디오 워터마크에서 비상상황 정보의 전달을 지원한다. 표 8은 A/336에서 제공된 emergency_alert_message()의 신택스를 제공한다.

[표 8]

A/336은 각각의 신택스 요소들 CAP_message_ID_length, CAP_message_ID, CAP_message_url_length, CAP_message_url, 만료, 긴급도, severity_certainty에 대해 다음과 같은 정의를 제공한다. 표 8에서 및 포함된 다른 표들에서 bslbf는, 좌측 비트부터 먼저, 비트 문자열을 지칭할 수 있다는 점에 유의해야 한다.

CAP_message_ID_length ― 이 8비트 부호없는 정수 필드는 CAP_message_ID 필드의 길이를 바이트 단위로 나타낸다.

CAP_message_ID ― 이 문자열은, 그 전체내용이 참조로 본 명세서에 포함되는, [OASIS: "Common Alerting Protocol" Version 1.2, 1 July 2010에서 정의된 CAP 메시지의 ID를 제공한다. 이것은, CAP_message_url에 의해 지시되는 [Common Alerting Protocol(CAP)] 메시지의 cap.alert.identifier 요소 값이어야 한다.

CAP_message_url_length ― 이 8비트 부호없는 정수 필드는 CAP_message_url 필드의 길이를 바이트 단위로 제공한다.

CAP_message_url ― 이 문자열은 CAP 메시지를 회수하는데 이용될 수 있는 URL을 제공해야 한다.

만료(expires) ― 이 파라미터는, International Atomic Time (TAI) 1970년 1월 1일 00시 00분 00초 이후의 초(second)의 개수의 32비트 카운트로서 인코딩된, CAP 메시지 내의 임의의 <info> 요소의 가장 최근의 만료 날짜 및 시간을 지시해야 한다.

긴급도 ― '1'로 설정되면, 이 플래그는 CAP 메시지 내의 가장 긴급한 <info> 요소의 긴급도가 "즉시"라는 것을 지시해야 한다. '0'으로 설정되면, 기타의 것을 지시할 것이다.

severity_certainty ― 이것은 확실성 및 심각도의 요구되는 CAP 요소들의 값들로부터 도출된 4비트 필드 코드이다.

표 8과 관련하여, CAP_message_url은 특정한 권한으로 제한되지 않는다는 점에 유의해야 한다. 전술된 바와 같이, 표 6과 관련하여, URI_string()도 역시 특정한 권한으로 제한되지 않는다. 이하에서 더 상세히 설명되는 바와 같이, 워터마크에서 시그널링될, 잠재적인 권한을 포함한, 잠재적인 값들과 관련하여, 제한되지 않는 URI를 인에이블하는 것은, 수신기 디바이스에 보안 위험을 초래할 수 있다.

A/334에 따르면, 오디오 워터마크는 데이터 신호를 선형 펄스 코드 변조(PCM; Linear Pulse Code Modulation) 오디오 신호에 임베딩할 수 있다. 오디오 워터마크는 시청자에게 인지될 수 없다는 점에 유의해야 한다. A/336은 오디오 워터마크 페이로드가 하나 이상의 유형의 메시지를 포함할 수 있는 경우를 기술한다. 표 9는 A/336r7에서 제공되는 오디오 워터마크 페이로드에 포함된 메시지 신택스를 제공한다. 표 9에 나타낸 바와 같이, small_domain()에 대한 신택스는 표 10에서 제공되고 large_domain()에 대한 신택스는 표 11에서 제공된다.

[표 9]

[표 10]

[표 11]

A/336r7은, 각각의 신택스 요소들 domain_type, server_field, interval_field, 및 query_field에 대해 다음과 같은 정의를 제공한다. domain_type ― 이 1비트 값은 페이로드 정보가 small_domain() 또는 large_domain()에 대한 것인지를 명시한다.

server_field ― 이 필드는 서버 코드(Server Code)를 포함한다. 서버 코드 값은 ATSC에 의해 지정된 등록 기관에 의해 발행된 할당에 따라 설정되어야 한다.

interval_field ― 이 필드는 간격 코드(Interval Code)를 포함한다.

query_flag ― 이 필드는 동적 이벤트(Dynamic Event)가 이용가능한 때를 시그널링한다. VP1 오디오 워터마크 세그먼트 내의 VP1 페이로드들 사이 또는 VP1 비디오 워터마크 세그먼트 내의 연속적인 VP1 메시지 그룹들 사이에서의 이 필드의 값에서의 변경은, (그 전체내용의 참조로 본 명세서에 포함되는 A/337 [ATSC: "Application Signaling and Triggers," Document A/337, Advanced Television Systems Committee, S33-3-27r3-WD-App-Signaling에서 정의된]) 동적 이벤트가 동적 이벤트 HTTP 서버로부터 이용가능하다는 것을 지시한다.

표 12는 서버 코드 및 간격 코드의 범위를 도메인 유형(domain type)의 함수로서 제공한다.

[표 12]

표 2 및 표 4를 참조하면, A/336은 비디오 워터마크 페이로드가 vp1_message()를 포함할 수 있는 경우를 기술한다. 비디오 워터마크 페이로드에 포함된 vp1_message()는 표 9에서 제공된 신택스에 기초할 수 있다. 따라서, A/336에서, 오디오 워터마크와 비디오 워터마크 각각은 vp1_payloads()를 이용하여 도메인을 시그널링할 수 있다. 도메인은 전술된 바와 같이 자원 식별자를 포함할 수 있다. 전술된 바와 같이, 재배포 시나리오는 수신기 디바이스가 멀티미디어 신호를 수신하고 멀티미디어 신호로부터 임베딩된 정보를 복구하는 상황을 포함할 수 있다. 일부 예에서, 워터마크에 임베딩된 URI는 수신기 디바이스가 서버(들)에 접속하여 서비스 관련 표 등의 추가 데이터를 다운로드하게 할 수 있다. 일부 경우에, 이러한 표는 수신기에게 인터넷으로부터 추가 데이터 및/또는 애플리케이션을 회수하도록 명령할 수 있다. 복구 프로세스란, 재배포 시나리오에서 수신기 디바이스가 워터마크를 이용하여 보충 콘텐츠에 액세스하는 프로세스를 지칭할 수 있다. 예를 들어 복구 프로세스는, 스마트 텔레비전이 워터마크에서 시그널링된 URL을 이용하여 문서를 다운로드하는데 이용하는 프로세스를 포함할 수 있다.

A/336은, 프리젠팅되는 서비스에 관한 시그널링 데이터를 포함하는 파일에 대한 HTTP GET 또는 HTTPS GET 요청의 발행을 통해 파일 서버에 대해 데이터 요청이 이루어질 수 있는 경우를 기술한다. 이 파일은 복구 파일이라고 지칭될 수 있고, 보충 시그널링 및 콘텐츠를 위해 시그널링 정보에 액세스하는데 이용할 수 있는 URL을 포함할 수 있다. A/336에 따라, 복구 파일은 JSON(JavaScript Object Notation) 문서이어야 한다. 간결성을 위해, A/336 복구 파일 포멧에 대한 규범적인 JSON 스키마는 여기서는 제공되지 않지만, A/336의 Annex B를 참조한다. A/336에서 각각의 VP1 페이로드는 시그널링 데이터를 포함한 오직 하나의 복구 파일에만 대응한다는 점에 유의해야 한다.

A/336에 따르면, 수신기 디바이스가 오디오 워터마크 또는 비디오 워터마크로 VP1 메시지를 수신할 때, 복구 파일에 대응하는 URL은 다음과 같은 URL 템플릿을 이용하여 VP1 페이로드로부터 구성되어야 한다 :

http[s]://{hostName}/a336/rdt/{subdName}/{serverCode}-{intervalCode}.rdt

여기서,

대괄호 [..] 안의 항목은 선택사항적인 문자열을 나타내고;

중괄호 {..} 안의 항목은 명명된 요소를 나타내며;

질의가 HTTP를 이용할 때 요청은 접두사 http를 이용해야 하고;

질의가 HTTPS를 이용할 때 요청은 접두사 https를 이용해야 한다.

또한, A/336에 따르면,

여기서, serverCode1, serverCode2, serverCode3, 및 serverCode4는, 2개-문자 대문자-전용 16진 값들로서 표현된, (최상위 비트에서 다음 바이트 경계까지 제로로 패딩된) VP1 페이로드의 server_field의 최하위-대-최상위 바이트들을 각각 의미한다.

A/336에 따르면, intervalCode 요소는 대문자-전용 16진 값(domain_type=0인 VP1 페이로드의 경우 길이가 6문자이고, domain_type=1인 VP1 페이로드의 경우 길이가 8문자임)으로 표현된, (최상위 비트에서 다음 바이트 경계까지 제로로 패딩된) VP1 페이로드의 interval_field의 값이어야 한다. 또한, A/336은 명시되지 않은 IP 주소(IPv4 주소의 경우 0.0.0.0/32 또는 IPv6 주소의 경우 ::/128)에 대한 {hostName}의 DNS 결정이 그 코드 도메인에 대해 복구 프로토콜이 지원되지 않는다는 것을 지시하는 경우 및 명시되지 않은 주소에 대해 복구 파일 요청이 발행되지 않아야 하는 경우를 제공한다. 따라서, VP1 페이로드는 자원 식별자를 시그널링할 수 있다.

따라서, A/336에서, 소형 도메인의 경우, 서버 코드 값 07ABCDEF와 간격 코드 0001ABCD를 갖는 복구 파일에 대응하는 URL은 다음과 같이 구성될 수 있다 :

http[s]://a336.EF.CD.AB.07.0.vp1.tv/a336/rdt/07AB/CD/EF/07ABCDEF-01ABCD.rdt

대형 도메인의 경우, 서버 코드 값 07ABCD와 간격 코드 01ABCDEF를 갖는 복구 파일에 대응하는 URL은 다음과 같이 구성될 수 있다 :

http[s]://a336.CD.AB.07.1.vp1.tv/a336/rdt/07AB/CD/07ABCD-01ABCDEF.rdt

전술된 바와 같이, 일부 경우에, 수신기 디바이스는 멀티미디어 신호의 특정한 소스와는 독립적으로 워터마크를 처리할 수 있다. 예를 들어, 수신기 디바이스는, 워터마크가 정당한 방식으로(예를 들어, 콘텐츠 제공자로부터) 생성되었는지 또는 의도하지 않은 또는 심지어 악의적인 방식으로 생성되었는지에 관계없이, HDMI 입력을 통해 수신된 임의의 비디오 신호로부터 워터마크를 추출할 수 있다. 전술된 바와 같이, 워터마크에 임베딩된 URI는 수신기 디바이스가 서비스 관련 표 등의 추가 데이터를 다운로드하기 위해 서버(들)에 접속하게 할 수 있다. 일부 경우에, 이러한 표는 수신기에게 인터넷으로부터 추가 데이터 및/또는 애플리케이션을 회수하도록 명령할 수 있다. 일부 경우에, 악의적으로 생성된 워터마크는 수신기 디바이스가 악성 애플리케이션(예를 들어, 바이러스, 스파이웨어 등)을 다운로드하게 할 수 있다. 본 명세서에서 설명된 기술들은 수신기 디바이스가 워터마크를 통해 액세스하는 URI에 관하여 보안을 증가시키는데 이용될 수 있다.

본 명세서에 설명된 기술들이 ATSC Candidate Standards에 따라 생성된 워터마크와 관련하여 본 명세서의 예들에서 설명되지만, 본 명세서에서 설명된 기술들은 자원 식별자와 연관된 정보를 포함하는 워터마크에 일반적으로 적용가능하다는 점에 유의해야 한다. 이하에서 더 상세히 설명되는 바와 같이, 본 명세서에 설명된 기술들은 보충 콘텐츠로의 액세스를 제공하는데 이용될 수 있는 메시지를 형성하는데 있어서 콘텐츠 제공자에게 유연성을 제공하는데 이용될 수 있고 재배포 시나리오에서 워터마크 채널을 이용하여 중요한 메시지가 안전하게 전달되도록 할 수 있다.

도 1은 본 개시내용에서 설명된 하나 이상의 기술을 구현할 수 있는 시스템의 한 예를 나타내는 블록도이다. 시스템(100)은 본 명세서에서 설명된 기술들에 따라 데이터를 전달하도록 구성될 수 있다. 도 1에 나타낸 예에서, 시스템(100)은, 하나 이상의 셋탑 박스(102A-102N), 텔레비전 서비스 네트워크(104), 텔레비전 서비스 제공자 사이트(106), 광역 네트워크(112), 하나 이상의 콘텐츠 제공자 사이트(114A-114N), 하나 이상의 데이터 제공자 사이트(116A-116N), 및 등록 기관 사이트(117)를 포함한다. 또한, 도 1에 나타낸 바와 같이, 각각의 수신기 디바이스(103)(단 하나만 도시됨)는 하나 이상의 셋탑 박스 중 하나와 통신할 수 있다. 시스템(100)은 소프트웨어 모듈을 포함할 수 있다. 소프트웨어 모듈은 메모리에 저장되고 프로세서에 의해 실행될 수 있다. 시스템(100)은 하나 이상의 프로세서와 복수의 내부 및/또는 외부 메모리 디바이스를 포함할 수 있다. 메모리 디바이스의 예로서는, 파일 서버, 파일 전송 프로토콜(FTP) 서버, NAS(Network Attached Storage) 디바이스, 로컬 디스크 드라이브, 또는 데이터를 저장할 수 있는 기타 임의의 유형의 디바이스나 저장 매체가 포함된다. 저장 매체는, Blu-ray 디스크, DVD, CD-ROM, 자기 디스크, 플래시 메모리, 기타 임의의 적절한 디지털 저장 매체를 포함할 수 있다. 본 명세서에서 설명된 기술들이 부분적으로 소프트웨어로 구현될 때, 디바이스는 소프트웨어를 위한 명령어들을 적절한 비일시적인 컴퓨터-판독가능한 매체에 저장하고 하나 이상의 프로세서를 이용하여 하드웨어로 명령어들을 실행할 수 있다.

시스템(100)은, 예를 들어, 텔레비전 프로그램, 영화, 라이브 스포츠 이벤트 등의 디지털 미디어 콘텐츠, 및 이와 연관된 데이터 및 애플리케이션과 멀티미디어 프리젠테이션(예를 들어, 자막 서비스)이 수신기 디바이스(103) 등의 하나 이상의 컴퓨팅 디바이스에 배포되고 렌더링되는 것을 허용하도록 구성될 수 있는 시스템의 한 예를 나타낸다. 도 1에 나타낸 예에서, 셋탑 박스들(102A-102N)은 텔레비전 서비스 제공자 사이트(106)로부터 데이터를 수신하도록 구성된 임의의 디바이스를 포함할 수 있다. 예를 들어, 셋탑 박스들(102A-102N)은 유선 및/또는 무선 통신을 위한 장비를 갖출 수 있고, 소위 스마트 텔레비전, 셋탑 박스, 및 디지털 비디오 레코더를 포함한 텔레비전을 포함할 수 있다. 또한, 셋탑 박스들(102A-102N)은, 데스크탑, 랩탑, 또는 태블릿 컴퓨터, 게임 콘솔, 예를 들어 스마트 폰, 셀룰러 전화기 및 텔레비전 서비스 제공자 사이트(106)로부터 데이터를 수신하도록 구성된 개인용 게임 디바이스를 포함한 모바일 디바이스들을 포함할 수 있다. 수신기 디바이스(103)는 셋탑 박스로부터 멀티미디어 신호를 수신하도록 구성된 임의의 디바이스를 포함할 수 있고 셋탑 박스와는 별개의 디바이스일 수도 있고 셋탑 박스의 일부로서 통합될 수도 있다. 시스템(100)은 별개의 사이트를 갖는 것으로 도시되어 있지만, 이러한 예시는 설명의 목적을 위한 것이며 시스템(100)을 특정한 물리적 아키텍쳐로 제한하고자 하는 것이 아니라는 점에 유의해야 한다. 시스템(100) 및 여기에 포함된 사이트의 기능은, 하드웨어, 펌웨어 및/또는 소프트웨어 구현의 임의의 조합을 이용하여 실현될 수 있다.

텔레비전 서비스 네트워크(104)는, 텔레비전 서비스를 포함할 수 있는 디지털 미디어 콘텐츠가 배포 및/또는 재배포될 수 있게 하도록 구성된 네트워크의 한 예이다. 예를 들어, 텔레비전 서비스 네트워크(104)는, MVPD에 의해 유지되는 네트워크를 포함할 수 있고, 예를 들어, 공중용 또는 가입-기반의 공중파 텔레비전 네트워크, 공중용 또는 가입-기반의 위성 텔레비전 서비스 제공자 네트워크, 공중용 또는 가입-기반의 케이블 텔레비전 제공자 네트워크 및/또는 OTT 또는 인터넷 서비스 제공자 네트워크를 포함할 수 있다. 일부 예에서, 텔레비전 서비스 네트워크(104)는 주로 텔레비전 서비스가 제공될 수 있게 하는데 이용될 수 있지만, 텔레비전 서비스 네트워크(104)는 또한, 본 명세서에서 설명된 통신 프로토콜들의 임의의 조합에 따라 다른 유형의 데이터 및 서비스가 제공될 수 있게 할 수 있다는 점에 유의해야 한다. 또한, 일부 예에서, 텔레비전 서비스 네트워크(104)는 텔레비전 서비스 제공자 사이트(106)와 셋탑 박스들(102A-102N) 중 하나 이상 사이의 양방향 통신을 가능하게 할 수 있다는 점에 유의해야 한다. 텔레비전 서비스 네트워크(104)는, 무선 및/또는 유선 통신 매체의 임의의 조합을 포함할 수 있다. 텔레비전 서비스 네트워크(104)는, 동축 케이블, 광섬유 케이블, 꼬인 쌍 케이블, 무선 전송기 및 수신기, 라우터, 스위치, 리피터, 기지국, 또는 다양한 디바이스와 사이트 사이의 통신을 가능하게 하는데 유용할 수 있는 기타 임의의 장비를 포함할 수 있다. 텔레비전 서비스 네트워크(104)는 하나 이상의 통신 프로토콜들의 조합에 따라 동작할 수 있다. 통신 프로토콜은 전용 양태를 포함하거나 및/또는 표준화된 통신 프로토콜을 포함할 수 있다. 표준화된 통신 프로토콜의 예로서는, DVB 표준, ATSC 표준, ISDB 표준, DTMB 표준, DMB 표준, DOCSIS(Data Over Cable Service Interface Specification) 표준, HbbTV 표준, SCTE(Society of Cable Telecommunications Engineers) 표준, W3C 표준, 및 UPnP 표준이 포함된다.

도 1을 다시 참조하면, 텔레비전 서비스 제공자 사이트(106)는, 텔레비전 서비스 네트워크(104)를 통해 텔레비전 서비스를 배포하도록 구성될 수 있다. 예를 들어, 텔레비전 서비스 제공자 사이트(106)는, 하나 이상의 방송국, 케이블 텔레비전 제공자, 위성 텔레비전 제공자, 또는 인터넷-기반의 텔레비전 제공자를 포함할 수 있다. 즉, 텔레비전 서비스 제공자 사이트(106)는 MVPD에 의해 유지되는 사이트일 수 있다. 예를 들어, 도 1에 나타낸 바와 같이, 텔레비전 서비스 제공자 사이트(106)는 예를 들어 텔레비전 콘텐츠를 재배포하도록 구성될 수 있고, 텔레비전 서비스 제공자 사이트(106)는 MVPD에 의한 사이트 유지를 포함할 수 있으며, 하나 이상의 콘텐츠 제공자 사이트(114A-114N)로부터의 하나 이상의 콘텐츠 피드(content feed)를 수신할 수 있다. 콘텐츠 제공자 사이트(114A-114N)는 멀티미디어 콘텐츠를 생성할 수 있는 사이트의 예를 나타낸다. 예를 들어, 콘텐츠 제공자 사이트는, 텔레비전 서비스 제공자 사이트(106)에 멀티미디어 파일 및/또는 스트림을 제공하도록 구성된 하나 이상의 스튜디오 콘텐츠 서버를 갖는 스튜디오를 포함할 수 있다. 한 예에서, 콘텐츠 제공 사이트는 텔레비전 방송국(예를 들어, 전국 방송사 사이트, 지역 제휴사 등)을 포함할 수 있고, 물리적 전송 메커니즘을 통해 텔레비전 프로그램을 텔레비전 서비스 제공자 사이트(106)에 제공하도록 구성될 수 있다. 물리적 전송 메커니즘은, 위성 업링크 및/또는 다운링크 메커니즘, 방송 전송, 및 이들의 조합을 포함할 수 있다. 한 예에서, 텔레비전 서비스 제공자 사이트(106)는 케이블 텔레비전 서비스 사이트를 포함할 수 있고, 텔레비전 서비스 제공자 사이트(106)는 텔레비전 방송을 지역 텔레비전 방송국으로부터 텔레비전 서비스 네트워크(104)를 통해 셋탑 박스들(102A-102N)에 재배포할 수 있다. 또한, 도 1에 나타낸 바와 같이, 텔레비전 서비스 제공자 사이트(106)는 광역 네트워크(112)와 통신할 수 있고, 콘텐츠 제공자 사이트(114A-114N)로부터 데이터를 수신하고 또한 광역 네트워크(112)를 통해 데이터 제공자 사이트(116A-116N)로부터 데이터를 수신하도록 구성될 수 있다. 일부 예에서, 텔레비전 서비스 제공자 사이트(106)는 텔레비전 스튜디오를 포함할 수 있고, 그로부터 콘텐츠가 나올 수 있다는 점에 유의해야 한다. 한 예에서, 콘텐츠 제공자 사이트(114A-114N)는 IP 스위트(suite)를 이용하여 멀티미디어 콘텐츠를 제공하도록 구성될 수 있다. 예를 들어, 콘텐츠 제공자 사이트는, RTP(Real Time Protocol), RTSP(Real Time Streaming Protocol) 또는 HTTP(Hyper-Text Transfer Protocol)에 따라 수신기 디바이스 및/또는 텔레비전 서비스 제공자 사이트(106)에 멀티미디어 콘텐츠를 제공하도록 구성될 수 있다.

도 1에 나타낸 예에서, 텔레비전 서비스 제공자 사이트(106)는 서비스 배포 엔진(108) 및 데이터베이스(110)를 포함한다. 서비스 배포 엔진(108)은, 예를 들어, 멀티미디어 콘텐츠, 대화형 애플리케이션, 및 메시지를 포함한 데이터를 수신하고, 텔레비전 서비스 네트워크(104)를 통해 셋탑 박스들(102A-102N)에 데이터를 배포하도록 구성될 수 있다. 예를 들어, 서비스 배포 엔진(108)은, 전술된 전송 표준들 중 하나 이상(예를 들어, ATSC 표준)의 양태에 따라 텔레비전 서비스를 수신하도록 구성될 수 있다. 데이터베이스(110)는, 예를 들어, 설명 데이터 및 실행가능한 대화형 애플리케이션을 포함한, 예를 들어, 멀티미디어 콘텐츠 및 이와 연관된 데이터를 포함하는 데이터를 저장하도록 구성된 저장 디바이스를 포함할 수 있다. 예를 들어, 스포츠 이벤트는 통계 업데이트를 제공하는 대화형 애플리케이션과 연관될 수 있다. 멀티미디어 콘텐츠와 관련된 데이터는, 예를 들어 HTML(Hypertext Markup Language), 동적 HTML, XML(Extensible Markup Language), 및 JSON 등의 정의된 데이터 포멧에 따라 포멧팅될 수 있고, 셋탑 박스들(102A-102N) 및/또는 대응하는 수신기 디바이스(103)가 예를 들어 데이터 제공자 사이트들(116A-116N) 중 하나로부터의 데이터에 액세스할 수 있게 하는 URL 및 URI를 포함할 수 있다. 일부 예에서, 텔레비전 서비스 제공자 사이트(106)는, 저장된 멀티미디어 콘텐츠에 대한 액세스를 제공하고 멀티미디어 콘텐츠를 텔레비전 서비스 네트워크(104)를 통해 셋탑 박스들(102A-102N) 중 하나 이상에 배포하도록 구성될 수 있다. 예를 들어, 데이터베이스(110)에 저장된 멀티미디어 콘텐츠(예를 들어, 음악, 영화 및 텔레비전(TV) 쇼)는 소위 온-디맨드 방식으로 텔레비전 서비스 네트워크(104)를 통해 사용자에게 제공될 수 있다.

광역 네트워크(112)는 패킷-기반 네트워크를 포함할 수 있고 하나 이상의 통신 프로토콜들의 조합에 따라 동작할 수 있다. 표준화된 통신 프로토콜의 예로서는, GSM(Global System Mobile Communications) 표준, CDMA(Code Division Multiple Access) 표준, 3GPP(Third Generation Partnership Project) 표준, ETSI(European Telecommunications Standards Institute) 표준, European 표준(EN), IP 표준, Wireless Application Protocol(WAP) 표준, 및 예를 들어 IEEE 802 표준들 중 하나 이상(예를 들어, Wi-Fi) 등의 IEEE(Institute of Electrical and Electronics Engineers) 표준들이 포함될 수 있다. 광역 네트워크(112)는 무선 및/또는 유선 통신 미디어의 임의의 조합을 포함할 수 있다. 광역 네트워크(112)는, 동축 케이블, 광섬유 케이블, 꼬인 쌍 케이블, Ethernet 케이블, 무선 전송기 및 수신기, 라우터, 스위치, 리피터, 기지국, 또는 다양한 디바이스와 사이트 사이의 통신을 가능하게 하는데 유용할 수 있는 기타 임의의 장비를 포함할 수 있다. 한 예에서, 광역 네트워크(112)는 인터넷을 포함할 수 있다.

데이터 제공자 사이트(116A-116N)는, 광역 네트워크(112)를 통해 수신기 디바이스(103) 및/또는 텔레비전 서비스 제공자 사이트(106)에 하이퍼텍스트 기반 콘텐츠 등을 포함하는 데이터를 제공하도록 구성될 수 있다. 데이터 제공자 사이트(116A-116N)는 하나 이상의 웹 서버를 포함할 수 있다. 또한, 데이터 제공자 사이트(116A-116N)는, 전술된 데이터베이스(110)와 유사할 수 있는, 하나 이상의 데이터베이스를 포함할 수 있다. 데이터 제공자 사이트(116A-116N)에 의해 제공되는 데이터는, 예를 들어, HTML, 동적 HTML, XML, 및 JSON 등의 데이터 포멧에 따라 정의될 수 있다. 데이터 제공자 사이트의 한 예로서는, 미국 특허청(US Patent and Trademark Office) 웹 사이트가 포함된다. 일부 예에서, 데이터 제공자 사이트(116A-116N)에 의해 제공되는 데이터는 재배포 시나리오에 이용될 수 있다는 점에 유의해야 한다. 또한, 일부 예에서, 데이터 제공자 사이트(116A-116N)에 의해 제공되는 데이터는 소위 세컨드 스크린 또는 컴패니언 디바이스 애플리케이션(second screen or companion device application)에 이용될 수 있다. 예를 들어, 수신기 디바이스와 통신하는 컴패니언 디바이스(들)는 수신기 디바이스 상에 프리젠팅 중인 텔레비전 프로그래밍과 연계하여 웹 사이트를 디스플레이할 수 있다. 데이터 제공자 사이트(116A-116N)에 의해 제공된 데이터는 오디오 및 비디오 콘텐츠를 포함할 수 있다는 점에 유의해야 한다. 예를 들어, 데이터 제공자 사이트(116A-116N)는, 텔레비전 네트워크 웹사이트(예를 들어, NBC.com), 광고 서버 등을 포함할 수 있다. 이러한 방식으로, 데이터 및 콘텐츠는 복수의 사이트에 의해 교환가능한 방식으로 제공될 수 있다. 예를 들어, 텔레비전 네트워크 웹사이트는 텔레비전 프로그램의 1차 프리젠테이션 동안 비디오 콘텐츠 및 데이터를 제공할 수 있고, 광고 서버는 광고 방송 동안에 비디오 콘텐츠 및 데이터(예를 들어, 팝업 윈도우)를 제공할 수 있다. 또한, 한 예에서, 데이터 제공자 사이트(116A-116N)는, 본 명세서에서 설명된 기술들 중 하나 이상에 따라 애플리케이션 및/또는 애플리케이션을 기술하는 데이터 요소들을 포함하는 데이터 또는 문서들을 생성하도록 구성될 수 있다.

등록 기관 사이트(117)는, 질의에 응답하여 데이터 제공자 사이트들(116A-116N) 중 하나에 대응하는 IP 주소를 제공하도록 구성될 수 있다. 예를 들어, 이하에서 상세히 설명하는 바와 같이, 수신기 디바이스는 방송사 식별자와 연관된 IP 주소를 등록 기관 사이트(117)에 질의할 수 있다. 또한, 등록 기관 사이트(117)는 요청을 데이터 제공자 사이트들(116A-116N) 중 하나에 포워딩하도록 구성될 수 있다. 예를 들어, 이하에서 상세히 설명되는 바와 같이, 수신기 디바이스는 방송사 식별자를 포함하는 URI를 이용하여 보충 콘텐츠를 요청할 수 있다. 이 요청은 등록 기관 사이트(117)로 보내질 수 있고, 등록 기관 사이트(117)는 방송사 식별자의 값에 기초하여 데이터 제공자 사이트들(116A-116N) 중 특정한 하나에 그 요청을 포워딩할 수 있다.

전술된 바와 같이, 서비스 배포 엔진(108)은, 예를 들어, 멀티미디어 콘텐츠, 대화형 애플리케이션, 및 메시지를 포함하는 데이터를 수신하고, 데이터를 텔레비전 서비스 네트워크(104)를 통해 셋탑 박스들(102A-102N)에 배포하도록 구성될 수 있다. 예를 들어, 서비스 배포 엔진(108)은 하나 이상의 데이터 스트림을 수신하고 전용 신호를 출력하여 셋탑 박스들(102A-102N)에 콘텐츠를 배포하도록 구성될 수 있다. 데이터 스트림이란 일반적으로 하나 이상의 데이터 패킷들의 세트로 캡슐화된 데이터를 말할 수 있다.

전술된 바와 같이, 재배포 시나리오의 예는 수신기 디바이스가 셋탑 박스로부터 멀티미디어 신호를 수신하고 멀티미디어 신호로부터 임베딩된 정보를 복구하는 상황을 포함할 수 있다. 도 2는 본 개시내용의 하나 이상의 기술을 구현할 수 있는 셋탑 박스의 한 예와 및 수신기 디바이스의 한 예를 나타내는 블록도이다. 셋탑 박스(200)는 통신 네트워크로부터 데이터를 수신하고 멀티미디어 콘텐츠를 나타내는 신호를 출력하도록 구성될 수 있는 컴퓨팅 디바이스의 한 예이다. 수신기 디바이스(300)는, 멀티미디어 콘텐츠를 나타내는 신호를 수신하고 수신된 신호로부터 시각적 및 청각적 데이터가 렌더링되게 하고, 또한 본 개시내용의 하나 이상의 기술에 따라 수신된 신호로부터 워터마크를 추출하도록 구성될 수 있는 컴퓨팅 디바이스의 한 예이다. 도 2에 나타낸 예에서, 셋탑 박스(200) 및 수신기 디바이스(300)는 예시의 목적을 위해 분리된 별개의 디바이스로서 도시되어 있다. 다른 예에서, 셋탑 박스(200) 및 수신기 디바이스(300)는 단일의 디바이스로서 통합될 수 있다는 점에 유의해야 한다. 도 2에 나타낸 예에서, 셋탑 박스(200)는, 예를 들어 전술된 텔레비전 서비스 네트워크(104) 등의, 텔레비전 네트워크를 통해 데이터를 수신하도록 구성된다. 다른 예에서, 셋탑 박스(200)는 추가로 또는 대안으로서 광역 네트워크를 통해 데이터를 수신하도록 구성될 수 있다는 점에 유의해야 한다.

도 2에 나타낸 바와 같이, 셋탑 박스(200)는, 중앙 처리 유닛(들)(202), 시스템 메모리(204), 시스템 인터페이스(210), 데이터 추출기(212), 오디오 디코더(214), 비디오 디코더(216), 멀티미디어 인터페이스(218), I/O 디바이스(들)(220), 및 워터마크 삽입기(222)를 포함한다. 또한 도 2에 나타낸 바와 같이, 시스템 메모리(204)는 운영 체제(206) 및 애플리케이션(208)을 포함한다. 중앙 처리 유닛(들)(202), 시스템 메모리(204), 시스템 인터페이스(210), 데이터 추출기(212), 오디오 디코더(214), 비디오 디코더(216), 멀티미디어 인터페이스(218), I/O 디바이스(들)(220), 및 워터마크 삽입기(222) 각각은, 컴포넌트간 통신을 위해 (물리적으로, 통신가능하게, 및/또는 동작적으로) 상호접속될 수 있고, 하나 이상의 마이크로프로세서, 디지털 신호 프로세서(DSP), 주문형 집적 회로(ASIC), 필드프로그래머블 게이트 어레이(FPGA), 개별 로직, 소프트웨어, 하드웨어, 펌웨어 또는 이들의 임의의 조합 등의, 다양한 적절한 회로 중 임의의 것으로서 구현될 수 있다. 셋탑 박스(200)가 별개의 기능 블록들을 갖는 것으로 도시되었지만, 이러한 예시는 설명적인 목적을 위한 것이며 셋탑 박스(200)를 특정한 하드웨어 아키텍쳐로 제한하지 않는다는 점에 유의해야 한다. 셋탑 박스(200)의 기능은, 하드웨어, 펌웨어 및/또는 소프트웨어 구현들의 임의의 조합을 이용하여 실현될 수 있다.

CPU(들)(202)는 셋탑 박스(200)에서의 실행을 위한 기능을 구현하고 및/또는 명령어들을 처리하도록 구성될 수 있다. CPU(들)(202)는 단일 및/또는 멀티 코어 중앙 처리 유닛들을 포함할 수 있다. CPU(들)(202)는 본 명세서에서 설명된 하나 이상의 기술을 구현하기 위해, 명령어, 코드 및/또는 데이터 구조를 회수하고 처리할 수 있다. 명령어들은, 시스템 메모리(204) 등의 컴퓨터 판독가능한 매체 상에 저장될 수 있다. 시스템 메모리(204)는 비일시적인 또는 실체적(tangible) 컴퓨터-판독가능한 저장 매체로서 기술될 수 있다. 일부 예에서, 시스템 메모리(204)는 임시적 및/또는 장기적 저장을 제공할 수 있다. 일부 예에서, 시스템 메모리(204) 또는 그 일부는 비휘발성 메모리로서 기술될 수 있고, 다른 예에서는 시스템 메모리(204)의 일부는 휘발성 메모리로서 기술될 수 있다. 시스템 메모리(204)는 동작 동안에 셋탑 박스(200)에 의해 이용될 수 있는 정보를 저장하도록 구성될 수 있다. 시스템 메모리(204)는, CPU(들)(202)에 의한 실행을 위한 프로그램 명령어들을 저장하는데 이용될 수 있고, 프로그램 실행 동안에 정보를 임시적으로 저장하기 위해 셋탑 박스(200) 상에서 실행중인 프로그램들에 의해 이용될 수 있다. 또한, 셋탑 박스(200)가 디지털 비디오 레코더의 일부로서 포함되는 예에서, 시스템 메모리(204)는 수 많은 비디오 파일을 저장하도록 구성될 수 있다.

애플리케이션(208)은, 셋탑 박스(200) 내에 구현되거나 셋탑 박스(200)에 의해 실행되는 애플리케이션들을 포함할 수 있고, 셋탑 박스(200)의 컴포넌트들 내에 구현되거나 포함될 수 있고, 이들에 의해 동작가능하고, 이들에 의해 실행되며, 및/또는 이들에 동작적으로/통신가능하게 결합될 수 있다. 애플리케이션(208)은 셋탑 박스(200)의 CPU(들)(202)로 하여금 특정한 기능들을 수행하게 할 수 있는 명령어들을 포함할 수 있다. 애플리케이션(208)은 for-loop들, while-loop들, if-구문들, do-loop들 등의 컴퓨터 프로그래밍 구문으로 표현되는 알고리즘을 포함할 수 있다. 애플리케이션(208)은 명시된 프로그래밍 언어를 이용하여 개발될 수 있다. 프로그래밍 언어의 예로서는, Java™, Jini™, C, C++, Objective C, Swift, Perl, Python, PhP, UNIX Shell, Visual Basic 및 Visual Basic Script가 포함된다. 도 2에 나타낸 바와 같이, 애플리케이션(208)은 운영 체제(206)와 연계하여 실행될 수 있다. 즉, 운영 체제(206)는, 애플리케이션(208)과 CPU(들)(202) 및 셋탑 박스(200)의 기타의 하드웨어 컴포넌트들과의 상호작용을 가능하게하도록 구성될 수 있다. 운영 체제(206)는, 셋탑 박스, 디지털 비디오 레코더, 텔레비전 등에 설치되도록 설계된 운영 체제일 수 있다. 본 명세서에서 설명된 기술들은 소프트웨어 아키텍처들의 임의의 조합 및 모든 조합을 이용하여 동작하도록 구성된 디바이스들에 의해 이용될 수 있다는 점에 유의해야 한다.

시스템 인터페이스(210)는 셋탑 박스(200)의 컴포넌트들 사이의 통신을 가능하게 하도록 구성될 수 있다. 한 예에서, 시스템 인터페이스(210)는, 데이터가 하나의 피어 디바이스로부터 다른 피어 디바이스로 또는 저장 매체로 전송될 수 있게 하는 구조를 포함한다. 예를 들어, 시스템 인터페이스(210)는, AGP(Accelerated Graphics Port) 기반 프로토콜, PCI Special Interest Group에 의해 유지되는 PCI Express™ (PCIe) 버스 명세 등의, PCI(Peripheral Component Interconnect) 버스 기반 프로토콜, 또는 피어 디바이스들을 상호접속하는데 이용될 수 있는 기타 임의의 형태의 구조(예를 들어, 전용 버스 프로토콜)을 지원하는 칩셋을 포함할 수 있다. 전술된 바와 같이, 셋탑 박스(200)는, 텔레비전 서비스 네트워크를 통해 데이터를 수신하도록 구성된다. 전술된 바와 같이, 텔레비전 서비스 네트워크는 통신 표준에 따라 동작할 수 있다. 통신 표준은, 예를 들어, 물리적 시그널링, 어드레싱, 채널 액세스 제어, 패킷 속성, 및 데이터 처리 등의 통신 속성(예를 들어, 프로토콜 계층)을 정의할 수 있다. 도 2에 나타낸 예에서, 데이터 추출기(212)는 신호로부터 비디오, 오디오, 및 데이터를 추출하도록 구성될 수 있다. 신호는 전용의 및/또는 표준화된 양태에 따라 정의될 수 있다. 데이터 추출기(212)는 전술된 텔레비전 서비스 제공자 사이트(106)에 의해 생성된 신호로부터 비디오, 오디오 및 데이터를 추출하도록 구성될 수 있다.

데이터 패킷은, CPU(들)(202), 오디오 디코더(214), 및 비디오 디코더(216)에 의해 처리될 수 있다. 오디오 디코더(214)는 오디오 패킷을 수신하고 처리하도록 구성될 수 있다. 예를 들어, 오디오 디코더(214)는 오디오 코덱의 양태들을 구현하도록 구성된 하드웨어 및 소프트웨어의 조합을 포함할 수 있다. 즉, 오디오 디코더(214)는 오디오 패킷을 수신하고 오디오 데이터 신호를 출력하도록 구성될 수 있다. 오디오 데이터는, Dolby 및 Digital Theater Systems에서 개발된 것들 등의 다중-채널 포멧을 이용하여 코딩될 수 있다. 오디오 데이터는 오디오 압축 포멧을 이용하여 코딩될 수 있다. 오디오 압축 포멧의 예로서는, MPEG(Motion Picture Experts Group) 포멧, AAC(Advanced Audio Coding) 포멧, DTS-HD 포멧, 및 Dolby Digital(AC-3) 포멧이 포함된다. 비디오 디코더(216)는 비디오 패킷을 수신하고 처리하도록 구성될 수 있다. 예를 들어, 비디오 디코더(216)는 비디오 코덱의 양태들을 구현하는데 이용되는 하드웨어와 소프트웨어의 조합을 포함할 수 있다. 한 예에서, 비디오 디코더(216)는, ITU-T H.262 또는 ISO/IEC MPEG-2 Visual, ISO/IEC MPEG-4 Visual, (ISO/IEC MPEG-4 AVC라고도 알려진) ITU-T H.264, 및 HEVC(High-Efficiency Video Coding) 등의, 임의의 개수의 비디오 압축 표준에 따라 인코딩된 데이터를 디코딩하도록 구성될 수 있다. 콘텐츠 제공자로부터 텔레비전 서비스 제공자 사이트(106)에서 수신된 비디오 데이터 및 오디오 데이터는 하나의 포멧에 따라 디코딩될 수 있고 MVPD의 전용 포멧을 포함한 또 다른 포멧에 따라 재-인코딩될 수 있다는 점에 유의해야 한다.

I/O 디바이스(들)(220)는 셋탑 박스(200)의 동작 동안에 입력을 수신하고 출력을 제공하도록 구성될 수 있다. 즉, I/O 디바이스(들)(220)는 사용자로 하여금 렌더링될 멀티미디어 콘텐츠를 선택할 수 있게 할 수 있다. 입력은, 예를 들어, 푸시-버턴 원격 제어기, 터치 감지 스크린을 포함하는 디바이스, 움직임-기반 입력 디바이스, 오디오-기반 입력 디바이스, 또는 사용자 입력을 수신하도록 구성된 기타 임의의 유형의 입력 디바이스 등의 입력 디바이스로부터 생성될 수 있다. I/O 디바이스(들)(220)는, 예를 들어 USB(Universal Serial Bus) 프로토콜, Bluetooth, ZigBee, 또는 예를 들어, 전용 적외선 통신 프로토콜과 같은 전용 통신 프로토콜 등의, 표준화된 통신 프로토콜을 이용하여, 셋탑 박스(200)에 동작적으로 결합될 수 있다.

전술된 바와 같이, 일부 예에서, MVPD는 콘텐츠 제공자로부터 나오는 콘텐츠를 강화하기 위해 비디오 신호에 워터마크를 임베딩할 수 있다. 도 2에 나타낸 예에서, 셋탑은 본 개시내용을 위한 하나 이상의 기술에 따라 멀티미디어 신호에 워터마크를 임베딩하도록 구성될 수 있는 워터마크 삽입기(222)를 포함한다. 워터마크 삽입기(222)가 멀티미디어 신호에 워터마크를 어떻게 임베딩할 수 있는지의 예는 이하에서 더 상세히 설명된다. 전술된 바와 같이, 수신기 디바이스는 멀티미디어 인터페이스로부터 멀티미디어 신호(예를 들어, 압축되지 않은 비디오 신호)를 수신할 수 있다. 멀티미디어 인터페이스(218)는 멀티미디어 신호를 수신기 디바이스(300)에 출력하도록 구성된다. 멀티미디어 인터페이스(218)는, 예를 들어, HDMI 포멧, DisplayPort 포멧, 및 기타의 디지털 또는 아날로그 포멧(예를 들어, 컴포넌트 비디오 포멧)을 포함한, 정의된 멀티미디어 신호 포멧에 따라 멀티미디어 신호를 출력하도록 구성될 수 있다. 또한, 일부 예에서, 멀티미디어 인터페이스(218)는 무선 신호 포멧(예를 들어, WirelessHD 등)에 따라 멀티미디어 신호를 출력하도록 구성될 수 있다는 점에 유의해야 한다. 본 명세서에 설명된 기술들은 수신기 디바이스가 멀티미디어 데이터를 수신하는 방법에 관계없이 일반적으로 적용가능하다는 점에 유의해야 한다.

다시 도 2를 참조하면, 수신기 디바이스(300)는, 디스플레이 시스템(302), 오디오 출력 시스템(304), 워터마크 프로세서(310), 및 네트워크 인터페이스(312)를 포함한다. 디스플레이 시스템(302), 오디오 출력 시스템(304), 워터마크 프로세서(310), 및 네트워크 인터페이스(312) 각각은, 컴포넌트간 통신을 위해 (물리적으로, 통신가능하게, 및/또는 동작적으로) 상호접속될 수 있고, 하나 이상의 마이크로프로세서, 디지털 신호 프로세서(DSP), 주문형 집적 회로(ASIC), 필드 프로그래머블 게이트 어레이(FPGA), 개별 로직, 소프트웨어, 하드웨어, 펌웨어, 또는 이들의 임의의 조합 등의 다양한 적절한 회로 중 임의의 것으로서 구현될 수 있다. 수신기 디바이스(300)가 별개의 기능 블록을 갖는 것으로 예시되어 있지만, 이러한 예시는 설명의 목적을 위한 것이며 수신기 디바이스를 특정한 하드웨어 아키텍쳐로 제한하지 않는다는 점에 유의해야 한다. 수신기 디바이스의 기능들은, 하드웨어, 펌웨어 및/또는 소프트웨어 구현들의 임의의 조합을 이용하여 실현될 수 있다. 또한, 수신기 디바이스(300)는 셋탑 박스(200)에 포함된 기능 블록들과 유사한 기능을 갖는 기능 블록들을 포함할 수 있다는 점에 유의해야 한다. 예를 들어, 수신기 디바이스(300)는, 중앙 처리 유닛(들), 시스템 메모리, 시스템 인터페이스, 데이터 추출기, 오디오 디코더, 비디오 디코더, 멀티미디어 인터페이스, 및/또는 I/O 디바이스(들) 중 하나 이상을 포함할 수 있다. 예를 들어, 수신기 디바이스(300)가 디지털 텔레비전을 포함하는 경우, 수신기 디바이스(300)는 통신 네트워크로부터 데이터를 수신하고 데이터(예를 들어, 공중파 방송)를 수신하고 셋탑 박스(200)로부터 멀티미디어 신호를 수신하는 것 외에 멀티미디어 콘텐츠를 나타내는 신호를 추출하도록 구성될 수 있다. 이 경우에, 수신기 디바이스(300)는 통신 네트워크로부터 데이터를 수신하고 셋탑 박스(200)와 관련하여 전술된 것과 유사한 방식으로 멀티미디어 콘텐츠를 나타내는 신호를 추출하도록 구성될 수 있다. 간결성을 위해, 통신 네트워크로부터 데이터를 수신하고 멀티미디어 콘텐츠를 나타내는 신호를 추출하도록 구성된 이러한 기능 블록들의 설명은 수신기 디바이스(300)에 관해서는 반복되지 않는다.

디스플레이 시스템(302)은 디스플레이를 위한 비디오 데이터를 회수하고 처리하도록 구성될 수 있다. 예를 들어, 디스플레이 시스템(302)은 비디오 신호로부터 픽셀 데이터를 수신하고 시각적 프리젠테이션을 위해 데이터를 출력할 수 있다. 또한, 디스플레이 시스템(302)은, 비디오 데이터, 예를 들어, 그래픽 사용자 인터페이스와 연계하여, 그래픽을 출력하도록 구성될 수 있다. 디스플레이 시스템(302)은, 액정 디스플레이(LCD), 플라즈마 디스플레이, 유기 발광 다이오드(OLED) 디스플레이, 또는 사용자에게 비디오 데이터를 프리젠팅할 수 있는 또 다른 유형의 디스플레이 디바이스 등의 다양한 디스플레이 디바이스 중 하나를 포함할 수 있다. 디스플레이 디바이스는, 표준 해상도 콘텐츠, 고선명 콘텐츠, 또는 초고화질 콘텐츠를 디스플레이하도록 구성될 수 있다. 또한, 일부 예에서, 디스플레이 디바이스는 오버스캔 모드에 따라 동작하도록 구성될 수 있다. 오디오 출력 시스템(304)은 오디오 데이터를 렌더링하도록 구성될 수 있다. 예를 들어, 오디오 출력 시스템(304)은, 오디오 프로세서, 디지털-대-아날로그 변환기, 증폭기, 및 스피커 시스템을 포함할 수 있다. 스피커 시스템은, 헤드폰, 통합 스테레오 스피커 시스템, 멀티-스피커 시스템, 또는 서라운드 사운드 시스템 등의 다양한 스피커 시스템 중 임의의 것을 포함할 수 있다.

워터마크 프로세서(310)는 본 명세서에서 설명된 하나 이상의 기술에 따라 멀티미디어 데이터 신호로부터 워터마크를 추출하도록 구성될 수 있다. 워터마크 프로세스가 어떻게 멀티미디어 신호에 임베딩된 워터마크를 추출할 수 있는지의 예는 이하에서 더욱 상세하게 설명된다. 네트워크 인터페이스(312)는 수신기 디바이스(300)가 근거리 통신망 및/또는 광역 네트워크를 통해 데이터를 송수신할 수 있게 하도록 구성될 수 있다. 네트워크 인터페이스(312)는, Ethernet 카드, 광 트랜시버, 무선 주파수 트랜시버, 또는 정보를 전송 및 수신하도록 구성된 기타 임의의 유형의 디바이스 등의 네트워크 인터페이스 카드를 포함할 수 있다. 네트워크 인터페이스(312)는, 네트워크에서 이용되는 물리적 및 미디어 액세스 제어(MAC) 계층에 따라 물리적 시그널링, 어드레싱, 및 채널 액세스 제어를 수행하도록 구성될 수 있다. 전술된 바와 같이, 워터마크에 임베딩된 URI를 포함하는 URI는 수신기 디바이스가 서버(들)에 접속하여 추가 데이터를 다운로드하게 할 수 있다. 네트워크 인터페이스(312)는, 워터마크 프로세서(310)로부터 수신된 것들을 포함한 URI들을 수신하고 URI들에서 식별된 서버(들)에 접속하도록 구성될 수 있다.

전술된 바와 같이, 콘텐츠 제공자 사이트(예를 들어, 콘텐츠 제공자 사이트(114N)), 텔레비전 제공자 사이트(예를 들어, 텔레비전 제공자 세트), 또는 셋탑 박스(예를 들어, 셋탑 박스(200))에 포함된 워터마크 삽입기를 포함한 워터마크 삽입기는 멀티미디어 신호에 워터마크를 임베딩하도록 구성될 수 있다. 또한, 워터마크 삽입기는, 전술된 scheme://authority/path 포멧에 따라 배열된 컴포넌트 부분들을 갖는 URI를 포함한, 자원 식별자와 연관된 정보를 포함하는 워터마크를 생성하도록 구성될 수 있다.

한 예에서, 이하에서 더 상세히 설명되는 바와 같이, 권한 컴포넌트는 신뢰받는 도메인 네임 서버(DNS) 루트 도메인을 포함할 수 있다. 한 예에서, 권한 컴포넌트는 방송사 식별자를 포함할 수 있다. 한 예에서, 방송사 식별자는 등록 기관에 의해 발급된 고유 식별자를 포함할 수 있다. 한 예에서, 등록 기관은, 전송 표준(예를 들어, ATSC 등)을 개발하는 기관, 또는 다른 정부 기관(예를 들어, 연방 통신 위원회(FCC, Federal Communications Commission) 등)을 포함할 수 있다. 등록 기관은 발행된 방송사 식별자들의 목록을 유지할 수 있다. 방송사 식별자의 예는 이하에서 더 상세하게 설명된다. 또한, 일부 예에서, 수신기 디바이스는, 방송사 식별자를, 특정한 루트 도메인, 예를 들어, 등록 기관과 연관된 신뢰받는 루트 도메인과 결합함으로써 자원 식별자를 생성하도록 구성될 수 있다. 따라서, 일부 예에서, 워터마크 삽입기는 다음과 같은 자원 식별자 포멧에 기초하여 자원 식별자들을 포함하는 워터마크를 생성하도록 구성될 수 있다 :

scheme://{registration authority root}/{broadcaster identifier}/path

또는

scheme://{broadcaster identifier}.{registration authority root}/path

일부 예에서, {등록 기관 루트}는 신뢰받는 DNS를 포함하고, 일부 예에서는, 워터마크 데이터로부터 도출될 수 없다. 한 예에서, {등록 기관 루트}는 수신기 디바이스에 저장될 수 있다. 일부 예에서, {등록 기관 루트}의 값은 업데이트되거나 수정될 수 있다. 한 예에서, 등록 기관만이 {등록 기관 루트}를 업데이트할 수 있다. 이러한 방식으로, {등록 기관 루트}의 보안이 유지될 수 있다.

또한, 일부 예에서, 워터마크 삽입기는, 권한 컴포넌트의 일부가 워터마크 메시지의 헤더의 일부로서 시그널링되고, 경로 컴포넌트의 일부 또는 전부(예를 들어, 자원 특유의 캐릭터 문자열)가 워터마크 메시지의 한 인스턴스의 일부로서 시그널링되도록 구성될 수 있다. 또한, 일부 예에서, 경로 컴포넌트의 일부 또는 전부는 워터마크 메시지의 헤더에서 시그널링될 수 있다. 따라서, 일부 예에서, 워터마크 삽입기는 다음과 같은 자원 식별자 포멧에 기초하여 자원 식별자들을 포함하는 워터마크를 생성하도록 구성될 수 있다 :

scheme:// {broadcaster identifier}, {registration authority root}/uri_string_i ()

또는

scheme://{broadcaster identifier}. {registration authority root}/uri_string_h()/uri_string_i()

여기서 {방송사 식별자}는 워터마크 메시지 헤더에서 시그널링되고 uri_string_h()는 워터마크 메시지 헤더에서 시그널링되며 uri_string_i()는 워터마크 메시지의 한 인스턴스에서 시그널링된다.

이하에서 더 상세히 설명되는 바와 같이, 수신기 디바이스는 {등록 기관 루트}에 대응하는 서버에 {방송사 식별자}를 제공할 수 있고 {등록 기관 루트}에 대응하는 서버는 {방송사 식별자}와 연관된 IP 주소를 제공하고 및/또는 {방송사 식별자}와 연관된 IP 주소와 연관된 서버에 요청을 포워딩할 수 있다. 이러한 방식으로, 수신기 디바이스는 신뢰받는 서버를 통해 보충 콘텐츠를 수신할 수 있다.

전술된 바와 같이, 표 6 및 표 8과 관련하여, A/336에서, uri_message() 및 emergency_alert_message()는 자원 식별 정보를 포함할 수 있다. 일부 예에서, 워터마크 삽입기는 uri_message() 또는 emergency_alert_message()에 포함된 자원 식별 정보가 다음과 같은 포멧에 따라 시그널링되도록 구성될 수 있다 :

여기서,

한 예에서, {BSID_code}는 wm_message_block() 헤더에서 전송되는 16비트 broadcaster_id의 4문자 16진 표현이며, 16비트 broadcaster_id는 ATSC 등록 기관에 의해 발행된 고유 식별자이다.

한 예에서, atsc3.tv는 ATSC 등록 기관과 연관된 신뢰받는 DNS의 호스트 명칭이다.

{wm_message_id_code}는, 한 예에서, wm_message_block() 헤더에서 전송되는 8비트 wm_message_id의 2문자 16진 표현이다. 한 예에서, URI 메시지의 경우 {wm_message_id_code}의 값은 "03"과 같을 수 있다. 한 예에서, 비상상황 경보 메시지의 경우 {wm_message_id_code}의 값은 "06"과 같을 수 있다.

한 예에서, {uri_type_code}는 8비트 uri_type의 2문자 16진 표현이다; 일부 경우에 정의된 uri_type을 갖지 않는 비상상황 경보 메시지의 경우, CAP_message_ID가 대신 이용되어야 한다. 전술된 바와 같이, 일부 예에서, CAP_message_ID는 다중 바이트 길이를 가질 수 있으며, 따라서, 일부 경우에, 결과 {CAP_message_id_code}는 복수의 2문자 16진 코드를 가질 수 있다.

uri_string()은, 한 예에서, 다양한 워터마크 메시지에서 정의된 캐릭터 문자열이다.

표 13은 본 명세서에서 설명된 하나 이상의 기술에 따라 워터마크 페이로드에 포함된 uri_message()의 헤더에 대한 예시적인 신택스를 제공한다. 표 13에 나타낸 예에서, 각각의 신택스 요소 wm_message_id, wm_message_block_length, wm_message_version, fragment_number, last_fragment, wm_message_bytes(), message_CRC_32, 및 CRC_32는, 일부 예에서, 표 1에 관하여 위에서 제공된 정의에 기초한 정의를 가질 수 있다.

[표 13]

표 13을 참조하면, broadcaster_id 신택스 요소는 다음과 같은 정의에 기초할 수 있다 :

broadcaster_id ― 이 16비트 부호없는 정수 필드는 방송사를 고유하게 식별해야 한다. ID는 ATSC 3.0 등록 기관에 의해 발급되어야 한다.

표 13에 도시된 예에서, broadcaster_id가 제1 단편에 포함되는 것으로 도시되어 있지만, 다른 예에서, broadcaster_id는 추가적인 단편들에 존재할 수 있다는 점에 유의해야 한다. 다른 예에서, broadcaster_id는 또한, wm_message_bytes() 등의 메시지 본문 내에 존재할 수도 있다.

표 14는 본 명세서에 설명된 하나 이상의 기술에 따른 uri_message()의 한 인스턴스에 대한 예시적인 신택스를 제공한다. 표 14에서, 신택스 요소 uri_type 및 uri_strlen은, 일부 예에서, 표 6과 관련하여 위에서 제공된 정의에 기초한 정의를 가질 수 있다.

[표 14]

표 14를 참조하면, 신택스 요소 URI_string()은 일부 예에서 다음과 같은 예시적인 정의에 기초할 수 있다 :

URI_string() ― 그 값들이 RFC 3986에 의해 URI(Uniform Resource Identifier)에 대해 허용된 것들로 제한되는 문자들로 구성된 URI. 문자열의 길이는 uri_len의 값에 의해 주어진다. 캐릭터 문자열은, URI가 단편들로 전송된 경우 재조립후, RFC 3986에 따라 경로, 질의, 및 단편의 URI 신택스 컴포넌트들만 포함해야 한다. URI_string()은 다음과 같이 HTTPS 요청을 구성하는데 이용된다 :

이러한 방식으로, URI_string()으로부터 수신기 디바이스에 의해 도출될 수 있는 자원 식별자의 잠재적인 값은, 수신기 디바이스에 의해 유효성검증될 수 있는 특정한 기관들로 제한될 수 있고, 따라서 수신기 디바이스가 알려지지 않은 소스로부터 악의적인 데이터를 다운로드하는 것을 방지할 수 있다.

표 3 및 표 4를 참조하면, A/336r7은 비디오 워터마크 페이로드가 uri_message()를 포함할 수 있는 경우를 기술한다. 표 15A 내지 15C는 본 명세서에서 설명된 하나 이상의 기술에 따른 uri_message()의 한 인스턴스에 대한 예시적인 신택스를 제공한다.

[표 15A]

[표 15B]

[표 15C]

표 15A 내지 표 15C 각각에서, 신택스 요소 uri_type은 표 6에 관하여 위에서 제공된 정의에 기초할 수 있다. 표 15A 및 표 15B 각각에서, 신택스 요소 ans_id는 다음과 같은 정의에 기초할 수 있다 :

ans_id ― 이 8비트 필드는 인가된 ATSC 3.0 네임 서버(ANS)의 식별자 코드를 지시해야 한다.

따라서, ans_id는 표 16과 관련하여 후술되는 바와 같이 {code_type}의 한 예일 수 있다. 표 15A를 참조하면, 신택스 요소들 bsid 및 URI_string()은 일부 예에서 다음과 같은 예시적인 정의에 기초할 수 있다 : bsid ― 이 16비트 식별자는 서비스와 연관된 방송 스트림의 BSID를 지시해야 한다. 그 고유성은 ans_id 필드에 의해 지시되는 명칭 서버 이내를 범위로 한다.

URI_string() ― 그 값들이 RFC 3986에 의해 URI(Uniform Resource Identifier)에 대해 허용된 것들로 제한되는 문자들로 구성된 URI. 문자열의 길이는 uri_strlen의 값에 의해 주어진다. 캐릭터 문자열은, URI가 단편들로 전송된 경우 재조립후, RFC 3986에 따른 유효한 URL이어야 하고, RFC 3986에 따라 경로, 질의, 및 단편의 URI 신택스 컴포넌트들만 포함해야 한다. URI_string()은 다음과 같이 HTTPS 요청을 구성하는데 이용된다 :

여기서,

{bsidCode}는 16비트 bsid의 4문자 16진 표현이다

{ansidCode}는 8비트 ans_id의 2문자 16진 표현이다.

표 15B를 참조하면, 신택스 요소 ans_strien_minus1, ans_string, uri_strlen, 및 URI_string()은 일부 예에서 다음과 같은 예시적인 정의에 기초할 수 있다 :

ans_strlen_minus1 ― 이 8비트 부호없는 정수에 1을 더한 값은 ans_string()의 길이를 지시한다.

ans_string ― 이 UTF-8 인코딩된 캐릭터 문자열은 서비스에 대한 고유 식별자이고, 그 고유성은 ans_id 필드에 의해 지시된 명칭 서버 이내를 범위로 한다.

uri_strlen ― 추종하는 uri_string() 내의 문자 수를 시그널링하는 8비트 부호없는 정수. ans_strlen_minus1 +1과 uri_strlen 필드의 조합된 값은, 1X 비디오 워터마크 방출 포멧(1X 시스템)의 경우 84 이하이어야 하고, 2X 비디오 워터마크 방출 포멧(2X 시스템)의 경우 204 이하이어야 한다[A/335에서 제공됨].

여기서

{ansidCode}는 8비트 ans_id의 2문자 16진 표현이다

표 15C를 참조하면, 신택스 요소 ans_string은 표 15B에 대해 위에서 제공된 정의에 기초할 수 있고, 신택스 요소들 ans_id, ans_strlen_minus1, uri_strlen, 및 URI_string()은 일부 예에서 다음과 같은 예시적인 정의에 기초할 수 있다:

ans_id ― 이 4비트 필드는 인가된 ATSC 3.0 네임 서버(ANS)의 식별자 코드를 지시해야 한다.

ans_strleng_minus1 ― 이 4비트 부호없는 정수에 1을 더한 값은 ans_string()의 길이를 지시해야 한다.

uri_strlen ― 추종하는 uri_string() 내의 문자 수를 시그널링하는 8비트 부호없는 정수. ans_strlen_minus1 +1과 uri_strlen 필드의 조합된 값은, 1X 비디오 워터마크 방출 포멧(1X 시스템)의 경우 85 이하이어야 하고, 2X 비디오 워터마크 방출 포멧(2X 시스템)의 경우 205 이하이어야 한다[A/335에서 제공됨].

URI_string() ― 그 값들이 RFC 3986 [8]에 의해 URI(Uniform Resource Identifier)에 대해 허용된 것들로 제한되는 문자들로 구성된 URI. 문자열의 길이는 uri_strlen의 값에 의해 주어진다. 캐릭터 문자열은, URI가 단편들로 전송된 경우 재조립후, RFC 3986 [8]에 따른 유효한 URL이어야 하고, RFC 3986 [8]에 따라 경로, 질의, 및 단편의 URI 신택스 컴포넌트들만 포함해야 한다. URI_string()은 다음과 같이 HTTPS 요청을 구성하는데 이용된다 :

여기서,

{ansidCode}는 4비트 ans_id의 1문자 16진 표현이다

이러한 방식으로, uri_message()는 인가된 ANS의 식별자 코드를 지시할 수 있고, 여기서, 식별자 코드는 HTTP(S) 요청을 구성하는데 이용된다. 이러한 방식으로, 표 15A 내지 표 15C에 나타낸 예들은 워터마크 삽입기가 다음과 같은 자원 식별자 포멧 : scheme : // {service_identifier}.{code_type}.{registration authority root}/path에 기초하여 자원 식별자들을 포함하는 워터마크를 생성하도록 구성될 수 있는 예들을 제공한다. 표 16은 본 명세서에 설명된 하나 이상의 기술에 따른 uri_message()의 한 인스턴스에 대한 예시적인 신택스를 제공한다.

[표 16]

표 16에서, 신택스 요소 uri_type은 표 6과 관련하여 위에서 제공된 정의에 기초할 수 있고, 신택스 요소들 domain_code, entity_strlen, entity_string(), uri_strlen, 및 URI_string()은, 일부 예에서 다음과 같은 예시적인 정의에 기초할 수 있다 : domain_code ― 이 8비트 부호없는 정수는 한 예에서는 표 17A에 따라 또는 한 예에서는 표 17B에 따라 URL 구성에 이용될 도메인을 식별하는 식별자 코드를 지시한다.

[표 17A]

[표 17B]

한 예에서, 표 17A 및 표 17B의 보류된 값은 또 다른 유형의 도메인 문자열과 연관될 수 있다. 예를 들어, 포멧 "x.atsc.org"을 갖는 도메인 문자열, 여기서, x는 정수이거나 영숫자를 포함하는 문자열이다.

상기 설명은 또 다른 대안적인 예에서 domain_code 신택스 요소에 8비트를 이용하지만, domain_code 신택스 요소에 대해 상이한 비트수가 이용될 수도 있다. 예를 들어, 4비트, 12비트, 또는 16비트가 domain_code에 대해 이용될 수 있다.

한 예에서, domain_code가 4비트를 이용한다면, uri_type 필드는, uri_type과 domain_code 필드가 함께 1바이트를 차지하게끔 4비트만을 이용하도록 수정될 수 있다. 또 다른 예에서, domain_code가 12비트를 이용한다면, 필드들의 바이트 정렬을 용이하게하기 위해 domain_code 필드 후에 4비트의 보류된 필드가 전송될 수 있다.

entity_strlen ― 추종하는 entity_string()의 문자 수를 시그널링하는 8비트 부호없는 정수.

한 예에서, 필드 entity_strlen가 필드 entity_strlen_minus1로서 대신에 시그널링될 수 있다.

이 경우, 의미는 다음과 같을 수 있다 :

entity_strlen_minus1 ― 1을 더한 값이 추종하는 entity_string()의 문자 수를 시그널링하는 8비트 부호없는 정수

다른 예에서, -2, -3 또는 -4 인코딩이 entity_string()의 길이를 지시하는데 이용될 수 있다.

이들 각각의 경우에서, entity_string()의 길이를 지시하기 위해 시그널링되는 신택스 요소는 다음 중 하나일 수 있다 :

entity_strlen_minus2 ― 2를 더한 값이 추종하는 entity_string()의 문자 수를 시그널링하는 8비트 부호없는 정수

entity_strlen_minus3 ― 3을 더한 값이 추종하는 entity_string()의 문자 수를 시그널링하는 8비트 부호없는 정수

entity_strlen_minus4 ― 4를 더한 값이 추종하는 entity_string()의 문자 수를 시그널링하는 8비트 부호없는 정수

일부 경우에는, 가장 짧은 최상위 레벨 도메인이 2문자일 수 있고 마침표('.')가 하나의 문자를 필요로 하며 가장 짧은 제2 레벨 도메인이 적어도 1 문자일 수 있으므로, 마이너스 4 시그널링이 선호될 수 있다는 점에 유의해야 한다.

entity_string() ― 이 문자열은 적어도 최상위 레벨 도메인과 제2 레벨 도메인으로 구성된 IANA-등록된 도메인 명칭이어야 한다. 더 높은 레벨 도메인들이 존재할 수 있다. 마침표 문자(".")는 최상위 레벨, 제2 레벨, 및 임의의 더 높은 레벨 도메인들 사이에 포함되어야 한다. entity_string()의 길이는 entity_strlen의 값에 의해 주어진다.

uri_strlen ― 추종하는 uri_string() 내의 문자 수를 시그널링하는 8비트 부호없는 정수. entity_strlen과 uri_strlen 필드의 조합된 값은, 1X 비디오 워터마크 방출 포멧(1X 시스템)의 경우 84 이하이어야 하고, 2X 비디오 워터마크 방출 포멧(2X 시스템)의 경우 204 이하이어야 한다[A/335에서 제공됨].

URI_string() ― 그 값들이 RFC 3986에 의해 URI(Uniform Resource Identifier)에 대해 허용된 것들로 제한되는 문자들로 구성된 URI. 문자열의 길이는 uri_strlen의 값에 의해 주어진다.

수신기는 다음과 같은 절차에 의해 참조된 콘텐츠를 회수하는데 이용할 URL을 형성할 것으로 예상된다. URL은 domain_string 문자열 뒤에 "/"이 오고 그 다음 URI_string 문자열이 오는 엔티티 문자열을 추가함으로써 구성된다. URL은, 단편들로 전송된 경우 재조립후, RFC 3986에 따른 유효한 URL이어야 하고, RFC 3986에 따라 경로, 질의, 및 단편의 URI 신택스 컴포넌트들만 포함해야 한다. URI_string()은 다음과 같이 HTTPS 요청을 구성하는데 이용된다 :

표 18은 본 명세서에서 설명된 하나 이상의 기술에 따라 emergency_alert_message()의 한 인스턴스에 대한 예시적인 신택스를 제공한다. 표 18에서, 신택스 요소들 CAP_message_ID_length, CAP_message_ID, CAP_message_url_length, 만료(expires), 긴급도(urgency), severity_certainty는, 일부 예에서, 표 8과 관련하여 위에서 제공된 정의에 기초한 정의들을 가질 수 있다.

[표 18]

표 18을 참조하면, 신택스 요소 CAP_message_url은, 일부 예에서, 다음과 같은 정의에 기초할 수 있다 :

CAP_message_url ― 이 문자열은 CAP 메시지를 회수하는데 이용될 수 있는 URL을 제공해야 한다. CAP_message_url은 RFC 3986에 따라 경로, 질의, 및 단편의 URI 신택스 컴포넌트들만을 포함해야 한다. CAP_message_url은 다음과 같이 HTTPS 요청을 구성하는데 이용된다 :

이러한 방식으로, CAP_message_url로부터 수신기 디바이스에 의해 도출될 수 있는 자원 식별자의 잠재적인 값은, 수신기 디바이스에 의해 유효성검증될 수 있는 특정한 기관들로 제한될 수 있고, 따라서 수신기 디바이스가 알려지지 않은 소스로부터 악의적인 데이터를 다운로드하는 것을 방지할 수 있다.

전술된 바와 같이, 워터마크 삽입기는 다음과 같은 자원 식별자 포멧들 중 하나 이상에 기초하여 자원 식별자들을 포함하는 워터마크를 생성하도록 구성될 수 있다 :

scheme://{registration authority root}/{broadcaster identifier}/path

scheme://{broadcaster identifier}.{registration authority root}/path

scheme://{broadcaster identifier}.{registration authority root}/uri_string_i ()

scheme://{broadcaster identifier}.{registration authority root}/uri_string_h()/uri_string_i()

일부 예에서, 등록 기관의 국가 및/또는 방송사의 국가와 연관된 정보를 자원 식별자에 포함시키는 것이 유용할 수 있다. 즉, 일부 예에서, 국가 정보를 {방송국 식별자} 및/또는 {등록 기관 루트}에 포함시키는 것이 유용할 수 있다. 한 예에서, 국가 정보는 국가 코드를 포함할 수 있다. 일부 예에서, {방송사 식별자} 및/또는 {등록 기관 루트}에 다른 유형의 코드를 포함시키는 것이 유용할 수 있다는 점에 유의해야 한다. 다른 유형의 코드의 예는, URL 구성 코드, 도메인 코드, 역참조 코드, 로컬 서버 코드 등을 포함한다. 전술된 바와 같이, {방송사 식별자}는 {BSID_code}를 포함할 수 있고 {등록 기관 루트}는 atsc3.tv일 수 있다, 즉, ATSC 등록 기관과 연관된 신뢰받는 DNS의 호스트 명칭일 수 있다. 따라서, 등록 기관의 국가 및/또는 방송사의 국가와 연관된 정보가 자원 식별자에 포함되는 예에서, 워터마크 삽입기는, uri_message() 또는 emergency_alert_message에 포함된 자원 식별 정보가 다음과 같은 포멧에 따라 시그널링되도록 구성될 수 있다:

다른 유형의 코드가 자원 식별자에 포함되는 예에서, 워터마크 삽입기는, uri_message() 또는 emergency_alert_message()에 포함된 자원 식별 정보가 다음과 같은 포멧에 따라 시그널링되도록 구성될 수 있다 :

국가 코드는 특정한 국가를 고유하게 식별하는 정의된 세트의 값들, 예를 들어, 예를 들어 표준화된 국가 코드 세트에 기초할 수 있다. 표준화된 국가 코드 세트의 예는, ISO 3166 Country Code Collection Standards에 정의된 국가 코드 세트를 포함한다. 참조로 본 명세서에 포함되는 ISO 3166-2:2013, Codes for the representation of names of countries and their subdivisions - Part 2: Country subdivision code는 예시적인 국가 코드를 제공한다. {country_code}는 ISO 3166-2 : 2013에 포함된 국가 코드에 기초할 수 있다.

표 14 및 표 18을 참조하면, 신택스 요소 URI_string() 및 CAP_message_url은, 일부 예에서, 방송사 및/또는 등록 기관의 국가 정보가 URI에 포함되는 경우, 다음과 같은 예시적인 정의에 기초할 수 있다 :

{BSID_code} 및 {country_code}는 다음과 같은 예시적인 정의에 기초할 수 있다:

한 예에서, {BSID_code}는 방송사가 운영하는 국가 및/또는 지역의 적절한 ATSC 등록 기관에 의해 발행된 고유한 방송사 식별자의 4문자 16진 표현이다.

한 예에서, {country_code}는 적절한 ATSC 등록 기관이 운영하는 국가 및/또는 지역의 2문자 표현이다. 한 예에서, 2문자 국가 코드는 ISO 3166-2의 국제 지정에 따른다.

{BSID_code} 및 {country_code}의 예시적인 정의에 관해, 한 예에서, {BSID_code} 및 {country_code} 양쪽 모두는 표 13에 관해 전술된 신택스 요소 broadcaster_id로부터 결정될 수 있다. 이 예에서, 신택스 요소 broadcaster_id는 다음과 같은 예시적인 정의에 기초할 수 있다.

broadcaster_id ― 이 16비트 부호없는 정수 필드는 적절한 등록 기관이 운영되는 방송사 및 국가를 고유하게 식별해야 한다.

ID는 ATSC 3.0이 이용되는 국가의 ATSC 3.0 등록 기관에 의해 발행될 것으로 예상된다.

한 예에서, 16비트 broadcaster_id는, 2개의 부분 : 국가 코드를 포함하는 제1 부분 및 운영 국가의 적절한 ATSC 등록 기관에 의해 발행된 고유한 방송사 식별자를 포함하는 제2 부분을 포함할 수 있다. 한 예에서, broadcaster_id의 제1 부분은 ISO 3166-2에 기초한 2문자 국가 코드에 대응하는 가변 길이 코드 워드를 포함할 수 있다. 한 예에서, broadcaster_id의 제1 부분은 ISO 3166-2에 기초한 2문자 국가 코드에 대응하는 고정 길이 코드 워드를 포함할 수 있다.

전술된 예시적인 URI에서, 캐릭터 문자열 "a336"은 더 일반적으로 {usage} 컴포넌트의 한 예를 나타낼 수 있으며, 여기서 {usage}는 다음과 같이 정의될 수 있다는 점에 유의해야 한다 :

{usage}는 특정한 http 또는 https 요청 구조가 준수하는 특정한 ATSC 표준을 지시하는 캐릭터 문자열이다.

또한, 일부 예에서, 전술된 URI의 컴포넌트들의 순서는 바뀔 수 있다, 예를 들어, {usage}는 {BSID_code} 이전에 URI 내에 포함될 수 있다는 점에 유의해야 한다.

전술된 바와 같이, A/336에서, vp1_payload()는 오디오 워터마크 또는 비디오 워터마크에 포함될 수 있다. 표 19는 본 명세서에서 설명된 하나 이상의 기술에 따라 vp1_payload()의 한 인스턴스에 대한 예시적인 신택스를 제공한다. 표 19에 나타낸 바와 같이, small_domain()에 대한 신택스는 표 20에서 제공되고 large_domain()에 대한 신택스는 표 21에서 제공된다. 표 19 내지 표 21에서, 신택스 요소들 domain_type, interval_field, 및 query_flag는 표 9 내지 표 11과 관련하여 위에서 제공된 정의에 기초할 수 있고, ans_id는 표 15C와 관련하여 위에서 제공된 예시적인 정의에 기초할 수 있다. 이러한 방식으로, 일부 예에서, {code_type}은 다양한 유형의 워터마크 메시지들에 공통적일 수 있다는 점에 유의해야 한다. 이러한 공통성은 수신기 디바이스에서 자원 식별자의 파싱을 단순화할 수 있다.

[표 19]

[표 20]

[표 21]

표 19 내지 표 21에 나타낸 예에서, server_field는 아래에서 제공된 예시적인 정의에 기초할 수 있고, 도메인 유형의 함수로서의 Server Code 및 Interval Code의 예시적인 범위는 표 22에 기초할 수 있다.

server_field ― 이 필드는 서버 코드(Server Code)를 포함한다. 서버 코드 값은 ans_id에 의해 식별된 인가된 ATSC 3.0 명칭 서버에 의해 발행된 할당에 따라 설정되어야 한다.

[표 22]

전술된 바와 같이, A/336에 따르면, 복구 파일에 대응하는 URL은 다음과 같은 URL 템플릿을 이용하여 VP1 페이로드로부터 구성되어야 한다 :

http[s]://{hostName}/a336/rdt/{subdName}/{serverCode} - {intervalCode}.rdt

표 19 내지 표 22에 설명된 예에서, intervalCode는 전술된 바와 같이 도출될 수 있고, 한 예에서 요소들 hostName, subdName, 및 serverCode는 다음과 같이 도출될 수 있다 :

여기서, ansidCode는 단일-문자 대문자 16진 값으로 표현된 4비트 ans_id를 의미하고, serverCode1, serverCode2, serverCode3, 및 serverCode4는, 2개-문자 대문자-전용 16진 값들로서 표현된, (최상위 비트에서 다음 바이트 경계까지 제로로 패딩된) VP1 페이로드의 server_field의 최하위-대-최상위 바이트들을 각각 의미할 수 있다.

여기서, ansidCode는 단일-문자 대문자 16진 값으로 표현된 4비트 ans_id를 의미할 수 있고, serverCode1, serverCode2, 및 serverCode3은, 2개-문자 대문자-전용 16진 값들로서 표현된, (최상위 비트에서 다음 바이트 경계까지 제로로 패딩된) VP1 페이로드의 server_field의 최하위-대-최상위 바이트들을 각각 의미할 수 있다.

따라서, 본 명세서에서 설명된 기술에 따르면, 6의 ansidCode에 대해, 소형 도메인의 경우, 서버 코드 값 07ABCDEF 및 간격 코드 0001ABCD를 갖는 복구 파일에 대응하는 URL은 다음과 같이 구성될 수 있다 : http[s]://a336.EF.CD.AB.07.0.6.vp1.tv/a336/rdt/07AB/CD/EF/07ABCDEF-01ABCD.rdt

및 대형 도메인의 경우 서버 코드 값 07ABCD 및 간격 코드 01ABCDEF를 갖는 복구 파일에 대응하는 URL은 다음과 같이 구성될 수 있다 : http[s]://a336.CD.AB.07.1.6.vp1.tv/a336/rdt/07AB/CD/07ABCD-01ABCDEF.rdt

이러한 방식으로, 공통 요소 명칭 서버, 예를 들어 ansidCode가 소형 도메인과 대형 도메인 양쪽 모두에 대해 시그널링될 수 있고 소형 및 대형 도메인들 양쪽 모두에 대해 server_code가 4비트 감소된다.

표 4를 참조하면, A/336r7은 신택스 요소 wm_message_id가 사용자 개인적 메시지를 식별할 수 있는 경우를 제공한다. 사용자 개인적 메시지는 관리되는 방식으로 불투명 사용자 데이터의 전달을 지원할 수 있다. 표 23은 사용자 개인적 메시지 user_private_message()에 대해 제안된 신택스의 한 예를 제공한다.

[표 23]

표 23에서, 신택스 요소들 domain_length, domain, payload_length, 및 payload는 다음과 같은 예시적인 정의에 기초할 수 있다 :

domain_length ― 이 8비트 부호없는 정수 필드는 바이트 단위로 도메인 필드의 길이를 지시해야 한다.

domain ― 이 가변 길이 필드는 Section 2.1 of IETF RFC 4151 [IETF: "The 'tag' URI Scheme", RFC 4151, October, 2005]에 정의된 taggingEntity 토큰, 예를 들어, "atsc.org,2016"을 따라야 한다. taggingEntity 토큰의 authorityName의 등록자는 페이로드 필드의 내용을 정의해야 한다.

payload_length ― 이 8비트 부호없는 정수 필드는 바이트 단위로 페이로드 필드의 길이를 지시해야 한다.

payload ― 이 가변 길이 필드는 본 명세서에서 정의되지 않은 데이터를 포함한다.

예시적인 사용자 개인적 메시지는 content_id_message 내에 포함되거나 wm_message_id 값을 갖는 별개의 워터마크 메시지로서 전송될 수 있으며, 여기서 최대 4개의 단편으로 전송되는 것이 허용된다는 점에 유의해야 한다. 예를 들어, 표 4를 참조하면, wm_message_id가 0x80-0xBF 범위의 값을 가질 때, 최대 4개의 단편을 가지는 것이 허용된다. 또한, 사용자 개인적 메시지는 wm_message_id 값을 갖는 별도의 워터마크 메시지로서 전송될 수 있고, 여기서 최대 256개의 단편으로 전송되는 것이 허용된다. 예를 들어, 표 4를 참조하면, wm_message_id가 0xC0-0xFF의 범위 내의 값을 가질 때. 다른 예에서, wm_message_id의 다른 값들은 각각 사용자 개인적 메시지에 대해 최대 크기 4개의 단편 및 최대 크기 256개의 단편을 지시할 수 있다는 점에 유의해야 한다.

표 23에 나타낸 예시적인 user_private_message()에서, payload_length는 8비트이며, 따라서, 0 내지 255의 범위일 수 있다. 따라서, 표 23의 payload_length는 255 바이트보다 큰 사용자 개인적 페이로드를 시그널링할 수 없고, 따라서, 최대 크기 256개 단편을 갖는 사용자 개인적 메시지를 수용할 수 없다. 한 예에서, 본 명세서에서 설명된 기술에 따르면, payload_length는 다음과 같은 정의에 기초할 수 있다 :

payload_length ― 이 16비트 부호없는 정수 필드는 바이트 단위로 페이로드 필드의 길이를 지시해야 한다.

표 24는 본 개시내용의 하나 이상의 기술에 따른 사용자 개인적 메시지 user_private_message()에 대한 신택스의 한 예를 제공한다.

[표 24]

표 24에서, 신택스 요소들 domain_length, domain, 및 payload는 표 23에 관하여 제공된 정의에 기초할 수 있다. 신택스 요소 payload_length는 다음과 같은 예시적인 정의에 기초할 수 있다.

payload_length ― 이 필드는 바이트 단위로 페이로드 필드의 길이를 지시해야 한다.

이 필드는, 이 user_private_message가 content_id_message()(0x01과 동일한 wm_message_id)의 ID_Value 필드로서 포함되거나 4개 단편까지의 최대 크기를 갖는 사용자 개인적 메시지를 지시하는 wm_message_id를 갖는 wm_message_block() 내에서 시그널링될 때 8비트 부호없는 정수이다.

이 필드는, 이 user_private_message가 256개 단편까지의 최대 크기를 갖는 사용자 개인적 메시지를 지시하는 wm_message_id를 갖는 wm_message_block() 내에서 시그널링될 때 14비트 부호없는 정수이다.

이러한 방식으로, 표 24에 나타낸 예는 0xC0-0xFF(예를 들어, 0xFF)의 wm_message_id가 이용되는 경우 더 큰 payload_length를 허용한다. payload_length에 대한 14비트의 길이는 2X 비디오 워터마크 시스템에 의해 지원되는 최대 용량과 지원되는 최대 단편 수에 기초한다는 점에 유의해야 한다. 일부 예에서, 표 24에 나타낸 예에서의 payload_length는, user_private_message가 256개 단편까지의 최대 크기를 갖는 사용자 개인적 메시지를 지시하는 wm_message_id를 갖는 wm_message_block() 내에서 시그널링되는 경우에 16비트일 수 있다는 점에 유의해야 한다.

한 예에서, 별개의 사용자 개인적 메시지가 시그널링될 수 있다. 예를 들어, 4개의 단편까지의 최대 크기를 갖는 사용자 개인적 메시지를 지시하는 wm_message_id에 대해 user_private_message_short가 시그널링될 수 있고, 256개의 단편까지의 최대 크기를 갖는 사용자 개인적 메시지를 지시하는 wm_message_id에 대해 user_private_message_long이 시그널링될 수 있다. 이 예에서, user_private_message_short는 8비트를 갖는 payload_length를 포함할 수 있고, user_private_message_long은 14비트(또는 일부 예에서는 16비트)를 갖는 payload_length를 포함할 수 있다.

또한, 상기 예시적인 사용자 개인적 메시지들 중 임의의 것에 있어서, domain_length 및 payload_length는 마이너스 1 코딩(minus one coding)으로 인코딩될 수 있다는 점에 유의해야 한다. 즉, 예를 들어, domain_length와 payload_length는 각각 다음과 같은 신택스 요소들로 대체될 수 있다 :

domain_length_minus1 ― 이 8비트 부호없는 정수 필드에 1을 더한 값은 바이트 단위로 도메인 필드의 길이를 지시한다.

payload_length_minus1 ― 이 필드는 바이트 단위로 페이로드 필드의 길이를 지시해야 한다.

이 필드는, 이 user_private_message가 content_id_message()(0x01과 동일한 wm_message_id)의 ID_Value 필드로서 포함되거나 4개 단편까지의 최대 크기를 갖는 사용자 개인적 메시지를 지시하는 wm_message_id를 갖는 wm_message_block() 내에서 시그널링될 때 8비트 부호없는 정수에 1을 더한 값이다.

이 필드는, 이 user_private_message가 256개 단편까지의 최대 크기를 갖는 사용자 개인적 메시지를 지시하는 wm_message_id를 갖는 wm_message_block() 내에서 시그널링될 때 14비트[또는 일부 예에서는 16비트] 부호없는 정수에 1을 더한 값이다.

이러한 방식으로, 본 명세서에서 설명된 디바이스들은 본 명세서에서 설명된 예시적인 사용자 개인적 메시지에 따라 워터마크 메시지의 가변 길이 페이로드에서 정보를 시그널링 및/또는 파싱하도록 구성될 수 있다.

도 3a 및 도 3b는 본 개시내용의 하나 이상의 기술에 따른 자원 식별자를 시그널링하는 한 예를 나타내는 통신 흐름도이다. 도 3a는 콘텐츠 제공자 사이트(114A)가 배포를 위해 텔레비전 서비스 제공자 사이트(106)에 콘텐츠 피드를 전송하기 전에 콘텐츠 피드에서 워터마크를 임베딩하는 예를 나타낸다. 또한, 도 3a는 등록 기관 사이트(117)가 데이터 제공자 사이트(116A)와 연관된 IP 주소를 제공하기 위해 왕복(round trip) 메커니즘을 이용하는 예를 나타낸다.

도 3b는 콘텐츠 제공자 사이트(114A)가 배포를 위해 텔레비전 서비스 제공자 사이트(106)에 콘텐츠 피드를 전송한 후에 워터마크가 임베딩되는 예를 나타낸다. 도 3b에 나타낸 예에서, 셋탑 박스(200)는 압축되지 않은 멀티미디어 신호에 워터마크를 임베딩한다. 또한, 도 3b는, 등록 기관 사이트(117)가 포워딩 메커니즘을 이용하여 수신기 디바이스(300)와 연관된 주소를 갖는 데이터 제공자 사이트(116A)와 연관된 IP 주소를 제공함으로써 데이터 제공자 사이트(116A)가 수신기 디바이스(300)에 대한 요청을 이행할 수 있게 하는 예를 나타낸다. 왕복 메커니즘은 수신기 디바이스의 사용자에 대한 추가적인 프라이버시 계층을 제공할 수 있고, 포워딩 메커니즘은 수신기 디바이스(300)가 보충 콘텐츠를 수신하여 더 적은 레이턴시로 렌더링하는 것을 허용할 수 있다는 점에 유의해야 한다. 일부 예에서, 수신기 디바이스(300)는 사용자가 왕복 또는 포워드 메커니즘이 이용되는지를 설정할 수 있도록 구성될 수 있다.

도 3a를 참조하면, 콘텐츠 제공자 사이트(114A)는 멀티미디어 신호에 워터마크를 삽입한다. 멀티미디어 신호에 워터마크를 삽입하는 것은, 일부 예에서, 워터마크 방출 포멧(예를 들어, 전술된 A/334 및/또는 A/335 등)에 기초하여 멀티미디어 신호에 디지털 데이터를 임베딩하는 것을 포함할 수 있다. 콘텐츠 제공자 사이트(114A)는 임베딩된 디지털 데이터를 이용하여 URI의 부분들을 시그널링할 수 있다. 임베딩된 디지털 데이터를 이용하는 URI의 부분들을 시그널링하는 것은, 정의된 워터마크 신택스(예를 들어, 표 1 내지 표 20에서 제공된 신택스)에 따라 데이터를 시그널링하는 것을 포함할 수 있다. 한 예에서, 정의된 워터마크 신택스는 식별자를 포함할 수 있다. 예를 들어, 정의된 워터마크 신택스는 전술된 바와 같이 방송사 식별자를 포함할 수 있다. 콘텐츠 제공자 사이트(114A)는 임베딩된 워터마크를 포함하는 콘텐츠 피드를 배포를 위해 텔레비전 서비스 제공자 사이트(106)에 전송한다. 텔레비전 서비스 제공자 사이트(106)는 물리적 전송 프로토콜에 따라 셋탑 박스(200)에 콘텐츠 피드를 전송한다. 셋탑 박스(200)는 물리적 전송을 수신한다. 셋탑 박스(200)는 물리적 전송으로부터 멀티미디어 데이터 스트림을 추출한다. 예를 들어, 셋탑 박스(200)는, 전술된 바와 같이, 물리 계층, 링크 계층, 및 네트워크 계층 처리를 수행할 수 있다. 셋탑 박스(200)는 추출된 멀티미디어 데이터 스트림으로부터 멀티미디어 신호를 디코딩한다. 셋탑 박스(200)는 전술된 기술들에 따라 추출된 멀티미디어 데이터 스트림으로부터 멀티미디어 신호를 디코딩할 수 있다(예를 들어, 셋탑 박스(200)는 HEVC 준수 비트 스트림으로부터 비디오 신호를 디코딩할 수 있다).

도 3a를 다시 참조하면, 셋탑 박스(200)는 임베딩된 워터마크를 포함하는 압축되지 않은 멀티미디어 신호를 수신기 디바이스에 전송한다. 수신기 디바이스(300)는 임베딩된 워터마크를 포함하는 압축되지 않은 멀티미디어 신호를 수신한다. 수신기 디바이스(300)는 임베딩된 워터마크를 추출한다. 워터마크를 추출하는 것은, 일부 예에서, 워터마크 방출 포멧(예를 들어, 전술된 A/334 및/또는 A/335 등)에 기초하여 디지털 데이터를 회수하는 것을 포함할 수 있다. 수신기 디바이스(300)는 추출된 디지털 데이터로부터 URI를 형성한다. URI 추출된 디지털 데이터로부터 URI를 형성하는 것은, 정의된 워터마크 신택스(예를 들어, 상기 표들 중 임의의 것에 제공된 신택스)에 따라 데이터를 파싱하는 것을 포함할 수 있다. 한 예에서, 정의된 워터마크 신택스는 URI 권한 컴포넌트의 일부를 포함할 수 있다. 예를 들어, 정의된 워터마크 신택스는 전술된 바와 같이 방송사 식별자를 포함할 수 있다. 또한, 정의된 워터마크 신택스는 서비스 식별자 및 코드 유형을 포함할 수 있다. 한 예에서, 수신기 디바이스(300)는 URI 권한 컴포넌트의 일부로서 등록 기관 루트를 갖는 방송사 식별자를 부가함으로써 URI를 형성할 수 있다. 전술된 바와 같이, 등록 기관 루트는 신뢰받는 DNS를 식별할 수 있다. 도 3a에 나타낸 예에서, 등록 기관 루트는 등록 기관 사이트(117)를 식별한다.

도 3a에 나타낸 예에서, 수신기 디바이스(300)는 방송사 식별자에 대응하는 IP 주소를 등록 기관 사이트(117)에 질의한다. 등록 기관 사이트(117)는 응답 내의 방송사 식별자에 대응하는 IP 주소를 제공한다. 일부 예에서, 콘텐츠 제공자 사이트(114A-114N) 및/또는 데이터 제공자 사이트(116A-116N)의 운영자는 고유한 방송사 식별자와 연관되기 위해 등록 기관 사이트에 등록할 수 있다. 수신기 디바이스(300)는 데이터 제공자 사이트(116A)에게 보충 콘텐츠를 요청한다. 즉, 이 예에서, 데이터 제공자 사이트(116A)는 방송 스트림 식별자(BSID)와 연관된다. 수신기 디바이스(300)는 데이터 제공자 사이트(116A)로부터 보충 콘텐츠를 포함하는 응답을 수신한다. 수신기 디바이스(300)는 보충 콘텐츠를 렌더링한다(예를 들어, 스포츠 이벤트와 연관된 라이브 통계 등을 디스플레이한다).

도 3b를 참조하면, 콘텐츠 제공자 사이트(114A)는 콘텐츠 피드를 배포를 위해 텔레비전 서비스 제공자 사이트(106)에 전송한다. 텔레비전 제공자 사이트(106)는 물리적 전송 프로토콜에 따라 셋탑 박스(200)에 콘텐츠 피드를 전송한다. 셋탑 박스(200)는 물리적 전송을 수신한다. 셋탑 박스(200)는 물리적 전송으로부터 멀티미디어 데이터 스트림을 추출한다. 셋탑 박스(200)는 추출된 멀티미디어 데이터 스트림으로부터 멀티미디어 신호를 디코딩한다. 셋탑 박스(200)는 멀티미디어 신호에 워터마크를 삽입한다. 셋탑 박스(200)는 전술된 기술들 중 하나 이상에 따라 멀티미디어 신호에 워터마크 신호를 삽입할 수 있다. 셋탑 박스(200)는 임베딩된 워터마크를 포함하는 압축되지 않은 멀티미디어 신호를 수신기 디바이스(300)에 전송한다. 수신기 디바이스(300)는 임베딩된 워터마크를 포함하는 압축되지 않은 멀티미디어 신호를 수신한다. 수신기 디바이스(300)는 임베딩된 워터마크를 추출한다. 수신기 디바이스(300)는 추출된 디지털 데이터로부터 URI를 형성한다. 수신기 디바이스는 전술된 기술에 따라 추출된 디지털 데이터로부터 URI를 형성할 수 있다. 도 3b에 나타낸 예에서, 수신기 디바이스(300)는 보충 콘텐츠에 대한 요청을 방송사 식별자에 대응하는 IP 주소에 포워딩할 것을 등록 기관 사이트(117)에게 요청한다. 등록 기관 사이트(117)는 방송사 식별자에 대응하는 IP 주소를 결정하고 그 요청을 데이터 제공 사이트(116A)에 포워딩한다. 즉, 이 예에서, 데이터 제공자 사이트(116A)는 BSID와 연관된다. 수신기 디바이스(300)는 데이터 제공자 사이트(116A)로부터 보충 콘텐츠를 포함하는 응답을 수신한다. 수신기 디바이스(300)는 보충 콘텐츠를 렌더링한다(예를 들어, 스포츠 이벤트와 연관된 라이브 통계 등을 디스플레이한다).

도 4는 본 개시내용의 하나 이상의 기술에 따른 자원 식별자 정보를 시그널링하는 한 예를 나타내는 플로차트이다. 도 4는 텔레비전 서비스 제공자 사이트(106)와 관련하여 설명되었지만, 도 4와 관련하여 설명된 기술들은 본 명세서에서 설명된 컴포넌트들의 임의의 조합에 의해 수행될 수 있다는 점에 유의해야 한다. 도 4에 나타낸 바와 같이, 텔레비전 서비스 제공자 사이트(106)는 멀티미디어 신호를 수신한다(402). 텔레비전 서비스 제공자 사이트(106)는 보충 콘텐츠와 연관된 자원을 결정한다(404). 예를 들어, 텔레비전 서비스 제공자 사이트(106)는, 멀티미디어와 연관된 애플리케이션이 특정한 애플리케이션 서버에 의해 호스팅되는지를 결정할 수 있다. 텔레비전 서비스 제공자 사이트(106)는 자원의 주소와 연관된 식별자를 결정한다(406). 예를 들어, 텔레비전 서비스 제공자 사이트(106)는 애플리케이션을 호스팅하는 서버의 IP 주소가 특정한 방송 식별자와 연관되어 있다고 결정할 수 있다. 텔레비전 서비스 제공자 사이트(106)는 식별자를 포함하는 데이터를 생성한다(408). 예를 들어, 텔레비전 서비스 제공자 사이트(106)는 전술된 예시적인 신택스 구조들 중 하나 이상에 따라 데이터를 생성할 수 있다. 텔레비전 서비스 제공자 사이트(106)는 멀티미디어 신호에 데이터를 임베딩한다(410). 예를 들어, 텔레비전 서비스 제공자 사이트(106)는, 전술된 예시적인 명시된 워터마크 방출을 포함한, 명시된 워터마크 방출에 따라 멀티미디어 신호에 데이터를 임베딩할 수 있다. 예를 들어, 텔레비전 서비스 제공자 사이트(106)는 임베딩된 데이터를 갖는 멀티미디어 신호를 포함하는 콘텐츠를 전송한다(412). 예를 들어, 텔레비전 서비스 제공자 사이트(106)는, 예를 들어, 텔레비전 서비스 네트워크(104)를 포함한, 텔레비전 서비스 네트워크를 통해 데이터를 전송할 수 있다. 이러한 방식으로, 텔레비전 서비스 제공자 사이트(106)는 자원 식별자와 연관된 정보를 시그널링하도록 구성된 디바이스의 한 예를 나타낸다.

도 5는 본 개시내용의 하나 이상의 기술에 따라 자원으로부터 보충 콘텐츠를 회수하는 한 예를 나타내는 플로차트이다. 도 5가 수신기 디바이스(300)와 관련하여 설명되었지만, 도 5와 관련하여 설명된 기술들은 본 명세서에서 설명된 컴포넌트들의 임의의 조합에 의해 수행될 수 있다는 점에 유의해야 한다. 도 5에 나타낸 바와 같이, 수신기 디바이스(300)는 멀티미디어 신호를 수신한다(502). 한 예에서, 멀티미디어 신호는 멀티미디어 인터페이스를 통해 수신된 신호를 포함할 수 있다. 수신기 디바이스(300)는 수신된 멀티미디어 신호로부터 데이터를 추출한다(504). 한 예에서, 멀티미디어 신호 내의 데이터는 명시된 워터마크 방출에 따라 임베딩될 수 있다. 수신기 디바이스(300)는 추출된 데이터로부터 식별자를 파싱한다(506). 한 예에서, 식별자는 자원의 주소와 연관될 수 있다. 예를 들어, 특정한 방송 식별자는 애플리케이션을 호스팅하는 서버의 IP 주소와 연관될 수 있다. 수신기 디바이스(300)는 전술된 예시적인 신택스 구조들 중 하나 이상에 따라 데이터를 파싱할 수 있다. 수신기 디바이스(300)는 신뢰받는 사이트에 질의한다(508). 예를 들어, 전술된 바와 같이, 수신기 디바이스는 식별자 및 등록 기관 사이트 루트 도메인을 포함하는 URI를 형성할 수 있다. 수신기 디바이스(300)는 질의에 응답하여 식별자에 대응하는 사이트로부터 보충 콘텐츠를 수신한다(510). 수신기 디바이스(300)는 보충 콘텐츠를 렌더링한다(512). 예를 들어, 수신기 디바이스(300)는 애플리케이션이 디스플레이되게 할 수 있다. 이러한 방식으로, 수신기 디바이스는 자원으로부터 보조 콘텐츠를 회수하도록 구성된 디바이스의 한 예를 나타낸다.

하나 이상의 예에서, 설명된 기능들은, 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 조합으로 구현될 수 있다. 소프트웨어로 구현되는 경우, 기능들은 컴퓨터 판독가능한 매체 상의 하나 이상의 명령어 또는 코드로서 저장되거나 전송될 수 있고 하드웨어-기반 처리 유닛에 의해 실행될 수 있다. 컴퓨터-판독가능한 매체는, 데이터 저장 매체 등의 실체적 매체, 또는, 예를 들어, 통신 프로토콜에 따라, 한 장소로부터 다른 장소로의 컴퓨터 프로그램의 전송을 가능하게 하는 임의의 매체를 포함하는 통신 매체에 대응하는 컴퓨터 판독가능한 저장 매체를 포함할 수 있다. 이러한 방식으로, 컴퓨터 판독가능한 매체는 일반적으로, (1) 비일시적인 실체적 컴퓨터 판독가능한 저장 매체 또는 (2) 신호 또는 반송파 등의 통신 매체에 대응할 수 있다. 데이터 저장 매체는, 본 개시내용에서 설명된 기술들의 구현을 위한 명령어들, 코드 및/또는 데이터 구조를 회수하기 위해 하나 이상의 컴퓨터 또는 하나 이상의 프로세서에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있다. 컴퓨터 프로그램 제품은 컴퓨터 판독가능한 매체를 포함할 수 있다.

제한이 아닌 예로서, 이러한 컴퓨터-판독가능한 저장 매체는, RAM, ROM, EEPROM, CD-ROM 또는 기타의 광 디스크 저장소, 자기 디스크 저장소, 또는 기타의 자기 저장 디바이스, 플래시 메모리, 또는 원하는 프로그램 코드를 명령어나 데이터 구조 형태로 저장하는데 이용될 수 있고 컴퓨터에 의해 엑세스될 수 있는 기타 임의의 매체를 포함할 수 있다. 또한, 임의의 접속은 적절하게 컴퓨터 판독가능한 매체라고 명명된다. 예를 들어, 명령어들이, 동축 케이블, 광섬유 케이블, 꼬인 쌍선, 디지털 가입자 회선(DSL), 또는 적외선, 라디오 및 마이크로파 등의 무선 기술을 이용하여, 웹사이트, 서버 또는 기타의 원격 소스로부터 전송된다면, 동축 케이블, 광섬유 케이블, 꼬인 쌍선, DSL, 또는 적외선, 라디오 및 마이크로파 등의 무선 기술은 매체의 정의에 포함된다. 그러나, 컴퓨터-판독가능한 저장 매체 및 데이터 저장 매체는, 접속, 반송파, 신호, 또는 다른 일시적인 매체를 포함하지 않고, 그 대신에, 비일시적인, 실체적 저장 매체와 관련된다는 것을 이해해야 한다. 본 명세서에서 사용될 때, 디스크(disk 및 disc)는 컴팩트 디스크(CD), 레이저 디스크, 광 디스크, 디지털 범용 디스크(DVD), 플로피 디스크, 및 블루레이 디스크를 포함하며, 대개 디스크(disk)는 데이터를 자기적으로 재생하는 반면, 디스크(disc)는 데이터를 레이저에 의해 광학적으로 재생한다. 상기의 조합은 또한 컴퓨터-판독가능한 매체의 범위 내에 포함되어야 한다.

명령어들은, 하나 이상의 디지털 신호 프로세서(DSP), 범용 마이크로프로세서, 주문형 집적 회로(ASIC), 필드 프로그래머블 로직 어레이(FPGA), 또는 기타의 균등한 집적 또는 개별 논리 회로 등의, 하나 이상의 프로세서에 의해 실행될 수 있다. 따라서, 여기서 사용되는 용어 "프로세서"란, 전술된 구조 또는 여기에 설명된 기술의 구현에 적합한 기타 임의의 구조를 말할 수도 있다. 또한, 일부 양태에서, 본 명세서에서 설명된 기능은 인코딩 및 디코딩을 위해 구성된 전용 하드웨어 및/또는 소프트웨어 모듈 내에 제공되거나, 결합된 코덱에 통합될 수 있다. 또한, 본 기술들은 하나 이상의 회로 또는 로직 요소에서 완전히 구현될 수 있다.

본 개시내용의 기술들은, 무선 핸드셋, 집적 회로(IC) 또는 IC 세트(예를 들어, 칩 세트)를 포함한 다양한 디바이스 또는 장치에서 구현될 수 있다. 개시된 본 기술을 수행하도록 구성된 디바이스의 기능적 양태를 강조하기 위해 본 개시내용에서는 다양한 컴포넌트, 모듈 또는 유닛이 설명되지만, 반드시 상이한 하드웨어 유닛에 의한 구현을 요구하지는 않는다. 오히려, 전술된 바와 같이, 다양한 유닛들은, 적절한 소프트웨어 및/또는 펌웨어와 연계하여, 코덱 하드웨어 유닛에서 결합되거나 전술된 하나 이상의 프로세서를 포함하는 연동 하드웨어 유닛들의 집합에 의해 제공될 수 있다.

또한, 전술된 실시예들 각각에 이용된 기지국 디바이스 및 단말 디바이스의 각각의 기능 블록 또는 다양한 피쳐들은, 전형적으로 집적 회로 또는 복수의 집적 회로인, 회로에 의해 구현되거나 실행될 수 있다. 본 명세서에서 설명된 기능들을 실행하도록 설계된 회로는, 범용 프로세서, 디지털 신호 프로세서(DSP), 애플리케이션 특유의 또는 범용 애플리케이션 집적 회로(ASIC), 필드 프로그래머블 게이트 어레이(FPGA), 또는 기타의 프로그래머블 로직 디바이스들, 개별 게이트들 또는 트랜지스터 로직, 또는 개별 하드웨어 컴포넌트, 또는 이들의 조합을 포함할 수 있다. 범용 프로세서는, 마이크로프로세서이거나, 대안으로서 프로세서는, 종래의 프로세서, 제어기, 마이크로제어기 또는 상태 머신일 수 있다. 전술된 범용 프로세서 또는 각각의 회로는 디지털 회로에 의해 구성될 수도 있고, 아날로그 회로에 의해 구성될 수도 있다. 또한, 반도체 기술의 진보에 의해 현재의 집적 회로를 대체하는 집적 회로 제작 기술이 출현하면, 이 기술에 의한 집적 회로도 역시 이용될 수 있다.

다양한 예들이 설명되었다. 이들 및 다른 예들은 이하의 청구항들의 범위 내에 있다.

<개요>

본 개시내용의 한 예에 따르면, 워터마크 메시지의 가변 길이 페이로드에서 정보를 시그널링하기 위한 방법은, 정보에 대해 요구되는 데이터 단편들의 수를 결정하는 단계, 메시지 블록 유형을 식별하는 신택스 요소를 시그널링하는 단계, 및 메시지 블록 페이로드의 길이를 지시하는 신택스 요소를 시그널링하는 단계를 포함하고, 메시지 블록 페이로드의 길이를 지시하는 신택스 요소의 비트 수는 메시지 블록 유형에 기초한다.

본 개시내용의 또 다른 예에 따르면, 워터마크 메시지의 가변 길이 페이로드에서 정보를 시그널링하기 위한 디바이스는 하나 이상의 프로세서를 포함하고, 이 하나 이상의 프로세서는, 정보에 대해 요구되는 데이터 단편들의 수를 결정하고, 메시지 블록 유형을 식별하는 신택스 요소를 시그널링하며, 메시지 블록 페이로드의 길이를 지시하는 신택스 요소를 시그널링하도록 구성되고, 메시지 블록 페이로드의 길이를 지시하는 신택스 요소의 비트 수는 메시지 블록 유형에 기초한다.

본 개시내용의 또 다른 예에 따르면, 비일시적인 컴퓨터-판독가능한 저장 매체는 저장된 명령어들을 포함하고, 이 명령어들은, 실행시에, 디바이스의 하나 이상의 프로세서로 하여금, 정보에 대해 요구되는 데이터 단편들의 수를 결정하고, 메시지 블록 유형을 식별하는 신택스 요소를 시그널링하며, 메시지 블록 페이로드의 길이를 지시하는 신택스 요소를 시그널링하게 하고, 여기서, 메시지 블록 페이로드의 길이를 지시하는 신택스 요소의 비트 수는 메시지 블록 유형에 기초한다.

본 개시내용의 또 다른 예에 따르면, 정보에 대해 요구되는 데이터 단편들의 수를 결정하기 위한 수단, 메시지 블록 유형을 식별하는 신택스 요소를 시그널링하기 위한 수단, 및 메시지 블록 페이로드의 길이를 지시하는 신택스 요소를 시그널링하기 위한 수단을 포함하고, 메시지 블록 페이로드의 길이를 지시하는 신택스 요소의 비트 수는 메시지 블록 유형에 기초한다.

하나 이상의 예의 상세사항은 첨부된 도면 및 이하의 설명에서 개시된다. 다른 피쳐들, 목적들, 및 이점들은, 상세한 설명 및 도면, 및 청구항들로부터 명백해질 것이다.

<상호 참조>

본 정규 출원은, 그 전체 내용이 참조로 본 명세서에 포함되는, 2016년 3월 1일자의 가출원 제62/302,133호, 2016년 5월 9일자의 가출원 제62/333,683호, 2016년 6월 23일자의 가출원 제62/353,617호, 2016년 9월 27일 가출원 제62/400,603호, 및 2016년 10월 14일자의 가출원 제62/408,614호에 대해 35 U.S.C. § 119하에서 우선권을 주장한다.

Claims

워터마크 메시지의 페이로드에서 불투명 사용자 데이터(opaque user data)를 시그널링하기 위한 방법으로서,
상기 페이로드에 대해 요구되는 데이터 단편들의 수를 결정하는 단계;
상기 페이로드에 대해 요구되는 데이터 단편들의 수에 기초하여, 메시지 블록 유형을 식별하는 제1 신택스 요소를 시그널링하는 단계; 및
상기 페이로드의 길이를 지시하는 제2 신택스 요소를 시그널링하는 단계 ― 상기 제2 신택스 요소의 비트 수는 상기 메시지 블록 유형에 기초함 ―
를 포함하고,
상기 제2 신택스 요소의 비트 수는, 제1 메시지 블록 유형에 대해서는 8이고, 제2 메시지 블록 유형에 대해서는 14인, 방법.
삭제
제1항에 있어서, 상기 제1 메시지 블록 유형은 4개 단편의 최대 메시지 블록 페이로드를 허용하는, 방법.
제1항에 있어서, 상기 제2 메시지 블록 유형은 256개 단편의 최대 메시지 블록 페이로드를 허용하는, 방법.