KR102667167B1

KR102667167B1 - Drm 관련 정보의 전송 및 취득

Info

Publication number: KR102667167B1
Application number: KR1020207003928A
Authority: KR
Inventors: 다츠야 이가라시; 마크 아이어; 브랜트 캔델로레; 폴 하티
Original assignee: 소니그룹주식회사
Priority date: 2017-08-17
Filing date: 2018-08-09
Publication date: 2024-05-21
Also published as: US11336937B2; US10237597B2; US20200195990A1; US20210099744A1; EP3669546A4; MX2020001676A; US10897640B2; WO2019036263A1; US20190230393A1; KR20200036870A; US10602209B2; CA3072448A1; US20190058909A1; EP3669546A1

Abstract

수신 장치는 수신기 및 처리 회로를 포함한다. 수신 회로는 방송 스트림을 수신하도록 구성된다. 처리 회로는 방송 스트림으로부터 SLT(Service List Table)를 추출하도록 구성된다. SLT는 방송 스트림 내의 복수의 서비스 각각에 대한 서비스 정보를 포함한다. 처리 회로는 방송 스트림 내의 복수의 서비스에 대한 서비스 정보 내의 서비스 카테고리 정보에 기초하여 방송 스트림이 수신 장치에 의해 지원되는 DRM(Digital Rights Management) 서비스를 포함하는지 여부를 결정하도록 구성된다. 처리 회로는, 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함한다는 결정에 기초하여, 수신 장치와 연관되고 DRM 서비스에서 전달되는 DRM 관련 정보를 취득하도록 구성된다.

Description

DRM 관련 정보의 전송 및 취득

관련 출원에 대한 상호참조

본 출원은 2017년 8월 17일자로 출원된 미국 특허 출원 제15/680,068호의 우선권의 이익을 주장하며, 그 전체 내용이 참조로서 본 명세서에 포함된다.

기술분야

본 개시는 DRM(Digital Rights Management) 관련 정보의 전송과 취득을 위한 방법들 및 장치들에 관한 것이다.

텔레비전 방송은 기본 아날로그 지상파 방송 텔레비전으로부터 복잡한 디지털 방송 텔레비전 시스템들로 진화했다. 현재 개발중인 방송 표준들은 서비스 제공자들이 보호되지 않은 컨텐츠뿐만 아니라 보호된 컨텐츠도 제공하는 것을 허용하도록 기대된다. 그러나, 보호된 컨텐츠에 액세스하기 위한 권리들(예컨대, DRM 관련 정보)를 전달하기위한 효율적인 시그널링 및 전송 메커니즘이 필요하다.

전술한 "배경" 설명은 본 개시의 맥락을 일반적으로 제시하기 위한 것이다. 출원 시에 선행 기술로서의 자격이 되지 않을 수 있는 설명의 양태들뿐만 아니라, 본 배경 섹션에 설명된 범위까지의 발명자들의 작업은 본 발명에 대한 선행 기술로서 명백하거나 암시적으로 인정되지 않는다.

본 개시의 실시예에 따르면, 수신기 회로 및 처리 회로를 포함하는 수신 장치가 제공된다. 수신기 회로는 방송 스트림을 수신하도록 구성된다. 처리 회로는 방송 스트림으로부터 SLT(Service List Table)를 추출하도록 구성된다. SLT는 방송 스트림 내의 복수의 서비스 각각에 대한 서비스 정보를 포함한다. 처리 회로는 방송 스트림 내의 복수의 서비스에 대한 서비스 정보의 서비스 카테고리 정보에 기초하여 방송 스트림이 수신 장치에 의해 지원되는 디지털 권한 관리(Digital Rights Management)(DRM) 서비스를 포함하는지 여부를 결정하도록 구성된다. 또한, 처리 회로는, 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함한다는 결정에 기초하여, 수신 장치와 연관되고 DRM 서비스에서 전달되는 DRM 관련 정보를 취득하도록 구성된다.

본 개시의 실시예에 따르면, DRM(Digital Rights Management) 관련 정보를 취득하기 위한 수신 장치의 방법이 제공된다. 방법은, 방송 스트림을 수신하고, 방송 스트림으로부터 SLT(Service List Table)를 추출하는 단계를 포함한다. SLT(Service List Table)는 방송 스트림 내의 복수의 서비스 각각에 대한 서비스 정보를 포함한다. 방법은, 수신 장치의 처리 회로에 의해, 방송 스트림 내의 복수의 서비스에 대한 서비스 정보의 서비스 카테고리 정보에 기초하여 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함하는지 여부를 결정하는 단계를 포함한다. 또한, 방법은, 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함한다는 결정을 하는 단계에서의 결정에 기초하여, 수신 장치와 관련되고 DRM 서비스에서 전달되는 DRM 관련 정보를 취득하는 단계를 포함한다.

본 개시의 실시예에 따르면, 컴퓨터에 의해 실행될 때 컴퓨터가 DRM(Digital Rights Management) 관련 정보를 취득하기 위한 수신 장치의 방법을 수행하도록 야기하는 명령어들을 저장하는 비-일시적 컴퓨터 판독가능 매체가 제공된다. 방법은, 방송 스트림을 수신하고, 방송 스트림으로부터 SLT(Service List Table)를 추출하는 단계를 포함한다. SLT는 방송 스트림 내의 복수의 서비스 각각에 대한 서비스 정보를 포함한다. 방법은, 방송 스트림 내의 복수의 서비스에 대한 서비스 정보의 서비스 카테고리 정보에 기초하여 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함하는지 여부를 결정하는 단계를 포함한다. 또한, 방법은, 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함한다는 결정을 하는 단계에서의 결정에 기초하여, 수신 장치와 연관되고 DRM 서비스에서 전달되는 DRM 관련 정보를 취득하는 단계를 포함한다.

본 개시의 실시예에 따르면, SLT(Service List Table)를 생성하도록 구성되는 처리 회로를 포함하는 서비스 분배 시스템이 제공된다. SLT는 방송 스트림에서 전송될 복수의 서비스 각각에 대한 서비스 정보를 포함한다. 서비스 정보 각각은 복수의 서비스 각각에 대한 카테고리 정보를 포함한다. 처리 회로는, 전송을 위해 SLT 및 복수의 서비스를 포함하는 방송 스트림을 생성하도록 구성된다. 또한, 처리 회로는, 방송 스트림 내의 복수의 서비스 중 DRM 서비스에서의 DRM 관련 정보를 전달하도록 구성된다. DRM 서비스에 대한 SLT에 포함되는 서비스 카테고리 정보는 그것을 DRM Service로서 식별한다.

전술한 단락들은 일반적인 소개에 의해 제공되었으며, 이하의 청구항들의 범위를 제한하도록 의도되지 않는다. 설명된 실시예들은 추가적인 이점들과 함께, 첨부되는 도면들과 함께 취해진 다음의 상세한 설명을 참조하여 가장 잘 이해될 것이다.

첨부된 도면들과 함께 고려될 때 이하의 상세한 설명을 참조하여 더 잘 이해됨에 따라 본 개시의 더 완전한 이해 및 그것에 수반되는 많은 이점들이 쉽게 얻어질 것이다.
도 1은 예시적인 통신 시스템을 도시한다;
도 2는 예시적인 수신 장치를 도시한다;
도 3은 DRM 관련 정보를 취득하기 위한 예시적인 방법을 도시한다;
도 4는 지원되는 DRM 서비스가 이용가능한지 여부를 결정하기 위한 예시적인 방법을 도시한다;
도 5는 DRM 시스템 유형이 지원되는지 여부를 결정하기 위한 예시적인 방법을 도시한다;
도 6은 DRM 관련 정보를 전송하기 위한 예시적인 방법을 도시한다;
도 7은 컴퓨터의 하드웨어 구성의 예시를 도시한다.

본 개시는 많은 상이한 형태들의 실시예일 수 있으며, 이러한 실시예들의 본 개시가 원리들의 예시로서 고려되어야 하고 본 개시를 도시되고 설명된 구체적인 실시예들로 한정하도록 의도되지 않을 것임을 이해하면서, 도면들에 도시되고 본 명세서에서 상세한 구체적인 실시예들에서 설명될 것이다.

이제 유사한 참조 번호들이 몇몇 도면들에 걸쳐 동일하거나 대응하는 부분들을 지정하는 도면들을 참조하면, 이하의 설명은 DRM 관련 정보의 전송 및 취득에 관한 것이다. DRM 관련 정보는 DRM 라이센스, 복호화 키, 및/또는 다른 DRM 관련 파일들 또는 정보 중 하나 또는 그것들의 조합을 포함하거나 포함할 수 있다. 또한, DRM 관련 정보는, 예로서 ITU-R Recommendation BT.182-1에 정의된 바와 같이 EMM(Entitlement Management Message)의 컴포넌트들 중 하나 또는 그것들의 조합을 포함할 수 있으며, 이는 그 전체가 본 명세서에 참조로 포함된다. DRM 관련 정보는 암호화된 포맷으로 전달되는 권한 보호 서비스들 및/또는 컨텐츠에 액세스하는 데 사용된다. 권리 보호 서비스 및/또는 컨텐츠는 디지털 텔레비전 방송 신호를 통해 전달될 수 있다.

ATSC(Advanced Television Systems Committee)에서 현재 표준화 중인 ATSC 3.0 디지털 텔레비전 시스템은 MPEG-2 전송 스트림이 아닌 IP(Internet Protocol) 전송 메커니즘들을 사용하고 권리 보호된(예컨대, 암호화된) 서비스들을 지원한다. 서비스들은 전체적으로 사용자에게 제시되는 미디어 컴포넌트들(예컨대, 텔레비전 프로그램의 오디오 및 비디오 컴포넌트들)의 집합을 포함할 수 있다. 컴포넌트들은 다수의 미디어 유형들일 수 있고, 서비스는 연속적이거나 간헐적일 수 있으며, 서비스는 실시간이거나 비실시간일 수 있고, 실시간의 서비스는 일련의 텔레비전 프로그램들을 포함할 수 있다.

몇몇 서비스들은 선형의 실시간 방송 프로그래밍이며, 다른 서비스들은 "어플리케이션 기반"일 수 있으며, 이는 그 서비스로 튜닝할 때의 사용자 경험은 수신 장치가 예로서 방송사 정의의 다운로드된 HTML5 어플리케이션을 실행하는 것으로 결정된다는 것을 의미한다. SLT(Service List Table)는 서비스 제공자에 의해 제공되는 각각의 서비스의 특성들을 특정하고 수신 장치에게 그것이 해당 서비스의 컴포넌트들(예컨대, 오디오, 비디오, 캡션들 및/또는 어플리케이션들)에 액세스할 수 있는 방법 및 위치를 나타낸다.

수신 장치가 암호화된 서비스에 액세스하기 위해서, DRM 라이센스 및/또는 서비스를 복호화하는 데 필요한 임의의 다른 정보와 같은 DRM 관련 정보를 수신 장치로 전송하기 위한 시스템이 필요하다. 대부분의 수신 장치들(예컨대, 디지털 텔레비전 수신기들)은 인터넷에 연결될 수 있을 것으로 예상된다. 서비스 제공자들은 인터넷 기반 서버들을 통해 이러한 연결된 수신 장치들로 DRM 관련 정보를 전달할 수 있다. 그러나, 모든 수신 장치들이 인터넷 기반 서버들에 액세스할 수 있는 것은 아니다. 따라서, 이 정보를 위한 방송 전용 전달 방법이 필요하다.

또한, 방송 스트림 내의 DRM 관련 정보의 전송이 이하의 요건들을 해결할 경우, 수신 장치의 동작이 개선될 수 있다. 첫번째로, DRM을 지원하지 않는 수신 장치들(예컨대, 암호화된 서비스들을 디코딩 및 제시할 수 없는 장치들)은 방송 스트림 내의 DRM 관련 정보(예컨대, 유닛으로 지정된(unit-addressed) 라이센스 메시지들)의 존재에 의해 혼동되거나 부정적인 영향을 받지 않아야 한다. 예로서, DRM 관련 정보는 BA(Broadcaster Application)가 관심을 가질 NRT(Non-Real-Time) 파일이 아닌 DRM 관련 파일들로 인식될 수 있으며 수신 시 폐기되어야 한다. 둘째로, 수신 장치에 도착할 때 DRM 관련 정보의 최상위 레벨의 필터링을 허용하는 강력하고 확장가능한 방법이 특정될 수 있다. 예로서, 최상위 레벨의 필터링은, 수신 장치가, 지원되는 DRM 시스템과 연관되지 않은 DRM 관련 정보 및 수신 장치를 대상으로 하지 않는 DRM 관련 정보(예컨대, 디바이스 또는 유닛 ID와 매칭하지 않는 것들)를 필터링하는 데 필요한 과도한 CPU 사이클들을 피하는 것을 허용할 수 있다.

제1 요건에 대해, 서비스의 다른 컴포넌트들(예컨대, 비디오/오디오/캡션 미디어 세그먼트 및 초기화 세그먼트 파일들)과 함께 시그널링되는 NRT 파일들은 다운로드된 BA가 그것들을 필요로 할 것이라는 기대에서 수신 장치에 의해 다운로드 및 캐싱될 것으로 예상된다. 따라서, DRM 관련 정보를 포함하는 파일들이 그들을 수신하는 것에 관심이 없는 수신 장치에 의해 편리하게 무시되도록 허용하기 위해 편리한 방법이 필요하다. 그렇지 않으면, 많은 양의 어플리케이션 캐시 스토리지가 낭비될 수 있다.

DRM 관련 정보는, 페이 퍼 뷰(pay per view) 컨텐츠, 하나 이상의 구독 서비스들, (예컨대, 고화질(High-Definition) 컨텐츠를 초고화질(Ultra-High Definition) 컨텐츠로 변환하기 위한) 스케일러블(scalable) 컨텐츠를 위한 강화 레이어 등과 같은 고가의 서비스 및/또는 미디어를 복호화하기 위해 개별적인 수신 장치에 의해 사용될 수 있다. DRM 관련 정보는, 수신 장치의 사용자가 예컨대 방송사에 의해 정의된 바와 같은 몇몇의 요건을 만족시키는 경우 제공될 수 있다. 필요한 조건은, 설문지를 작성하거나, 이력 정보(예컨대, 시청 및/또는 브라우징 정보) 및/또는 인구 통계학적 정보(예컨대, 성별, 연령, 결혼 여부)를 공유하는 데에 동의하거나 고가의 서비스 및/또는 미디어의 제공자에게 지불하는 것일 수 있다.

도 1은 DRM 관련 정보의 전송 및 취득을 위한 예시적인 통신 시스템이다. 통신 시스템은 서비스 제공자(10) 및 수신 장치(20)를 포함하고, 일 실시예에 따른 디지털 텔레비전 방송 시스템에 대응한다.

일 실시예에서, 서비스 제공자(예컨대, 방송국 엔티티 또는 방송국)(10)는 데이터 스트림(예컨대, 방송 스트림) 내의 하나 이상의 서비스를 수신 장치(20)로 전송하도록 구성된 송신기를 갖는 송신 장치를 포함하는 서비스 분배 시스템이다. 송신기는, 예로서, 디지털 지상파 방송을 통해 데이터 스트림을 수신 장치(20)에 제공하도록 구성된다. 다른 예시들에서, 데이터 스트림은 디지털 지상파 방송, 휴대 전화 네트워크, 인터넷과 같은 광대역 네트워크, 케이블 네트워크, 및 위성 링크 중 하나 또는 그것들의 조합을 통해 수신 장치(20)로 전송될 수 있다. 서비스 분배 시스템은 데이터 스트림을 수신 장치(20)로 통신하기 위해 임의의 하나 또는 다양한 전송 기술들을 사용할 수 있다.

일 실시예에 따른 서비스 분배 시스템은 소스 인코더, 채널 인코더, 및 변조기를 포함한다. 소스 인코더는 소스로부터 수신된 오디오, 비디오, 시그널링, 제어, 또는 다른 데이터를 압축하기 위한 데이터, 오디오, 및 비디오 인코더를 포함한다. 채널 인코더는 압축된 및 시그널링 데이터를 랜덤화, 인터레이싱, 채널 코딩, 및 프레임 맵핑한다. 예로서, 채널 인코더는 많은 데이터 셀들을 OFDM(Orthogonal Frequency-Division Multiplexing) 심볼들 상으로 전달될 시퀀스들로 형성하는 프레임 빌더를 포함한다. 변조기(예컨대, 멀티플렉서)는 처리된 디지털 데이터를, 예로서, OFDM 심볼들(예컨대, 현재 표준화되고 있는 ATSC 3.0 Standard의 경우)일 수 있는 변조 심볼들로 변환한다. 이후, 다중화된 데이터는 주파수 도메인 신호를 시간 도메인 신호로 변환하는 IFFT(Inverse Fast Fourier Transformer)로 전달된다. 시간 도메인 신호는 심볼들 사이에서 GI(Guard Interval)를 생성하기 위해 가드 삽입 모듈로 공급되고, 이후 D/A(Digital-to-Analog) 변환기로 공급된다. 이후, 상향 변환(up-conversion), RF 증폭, 및 공중파 방송(over-the air broadcasting)이 방송 스트림을 전송하기 위해 수행된다.

다른 실시예들에서, 송신 장치 또는 수신 장치의 특정 구성요소들이 필수적이지 않을 수 있다. OFDM 송신기 및 수신기의 세부 사항들은, 예로서, 그 전체가 본 명세서에 참조로 포함되는 DVB-T2 Standard(ETSI EN 302 755), ATSC Standard A/322 - Physical Layer Protocol(Doc. A/322:2017), 및 ATSC Standard A/321 - System Discovery and Signaling(Doc. A/321:2016)에서 찾을 수 있다.

도 2는 보호된(예컨대, 암호화된) 서비스들 또는 컨텐츠에 액세스하도록 구성된 예시적인 수신 장치(20)를 도시한다. 수신 장치(20)는 텔레비전 세트, 셋톱 박스, 스마트 폰, 태블릿 컴퓨터, 랩탑, 휴대용 컴퓨터, 또는 텔레비전 컨텐츠를 수신하도록 구성된 임의의 다른 디바이스와 같은 고정 또는 모바일 디바이스일 수 있다. 또한, 수신 장치(20)는 이상에서 설명된 차량 또는 임의의 고정 또는 모바일 디바이스들에 통합된 디지털 텔레비전 수신기일 수 있다.

수신 장치(20)는 하나 이상의 서비스 제공자(10)로부터 데이터 스트림(예컨대, 방송 스트림)을 수신하도록 구성된 수신기 회로, 및 수신 장치(20)의 다양한 기능들을 수행하도록 구성된 처리 회로를 포함한다. 일 실시예에서, 튜너/복조기(202)는 방송 스트림을 포함하는 방송 방출들을 수신한다. 실시예에 따라, 수신 장치(20)는 대안적으로 또는 추가적으로 케이블 텔레비전 전송 또는 위성 방송을 수신하도록 구성될 수 있다. 튜너/복조기(202)는 디멀티플렉서(204)에 의해 디멀티플렉싱되거나 미들웨어에 의해 핸들링되고 오디오 및 비디오(A/V) 스트림들로 분리될 수 있는 데이터 스트림을 수신한다. 오디오는 오디오 디코더(210)에 의해 디코딩되고 비디오는 비디오 디코더(214)에 의해 디코딩된다. 또한, 비압축된 A/V 데이터는, 이용 가능한 경우, 비압축된 A/V 인터페이스(예컨대, HDMI 인터페이스)를 통해 수신될 수 있다.

수신 장치(20)는 일반적으로 하나 이상의 버스(예컨대, 버스(250))를 통해 워킹 메모리(240), 프로그램 메모리(242), 및 그래픽 서브시스템(244)에 결합된 CPU(238)와 같은 적어도 하나의 프로세서의 제어 하에서 동작한다. CPU(238)는 일 실시예에 따라 DRM 관련 정보, 및 DRM 관련 정보를 취득하기 위한 시그널링 정보를 수신한다. 그래픽 서브시스템(244)에 의해 출력된 그래픽은 합성기 및 비디오 인터페이스(260)에 의해 비디오 이미지와 결합되어 비디오 디스플레이 상에 디스플레이하기에 적합한 출력을 생성한다.

CPU(238)는 보호된 서비스들 또는 컨텐츠를 제시하는 것과 관련된 처리, 및 제시에 필요한 DRM 관련 정보의 취득을 포함하는 수신 장치(20)의 기능들을 수행하도록 동작한다. 또한, CPU(238)는, 예로서, 프로그램 메모리(242)에 저장된 브라우저를 사용하여, 어플리케이션(예컨대, HTML5 어플리케이션), BA(Broadcaster Applications) 등에 포함된 스크립트 객체들(제어 객체들)을 실행하도록 동작한다.

CPU(238)는 특정 실시예들에서 하나 이상의 기능들의 제어를 중앙집중화하기 위해 수신 장치(20)의 리소스들 중 임의의 하나 또는 그것들의 조합에 결합될 수 있다. 일 실시예에서, CPU(238)는 또한 튜너/복조기(202) 및 다른 텔레비전 리소스들을 포함하는 수신 장치(20)의 제어를 감독하도록 동작한다.

도 3은 방송 스트림으로부터 DRM 관련 정보를 취득하기 위한 수신 장치(20)의 예시적인 방법을 도시한다. 단계(S302)에서, 수신 장치(20)의 수신기 회로는 서비스 제공자(10)로부터 방송 스트림을 수신한다. 방송 스트림은 일 실시예에 따라 RF(Radio Frequency) 채널을 통해 방송된다. 방송 스트림은 방송 스트림과 연관된 채널의 사용자의 선택에 응답하여 수신될 수 있거나, 그렇지 않으면 수신 장치(20)의 처리 회로는 정보(예컨대, ESG(Electronic Service Guide) 데이터 또는 DRM 관련 정보)를 취득하기 위해 방송 스트림에 액세스한다.

단계(S304)에서, 수신 장치(20)의 처리 회로는 방송 스트림이 수신 장치(20)에 의해 지원되는 하나 이상의 DRM 서비스를 포함 하는지 여부를 결정한다. 단계(S304)에서 방송 스트림이 수신 장치(20)에 의해 지원되는 하나 이상의 DRM 서비스를 포함하는 것으로 결정되면, 수신 장치(20)의 처리 회로는 수신 장치(20)와 연관된 DRM 관련 정보를 단계(S306)에서 방송 스트림으로부터 취득한다. 방송 스트림이 수신 장치(20)에 의해 지원되는 DRM 서비스를 포함하지 않은 것으로 결정되면, 처리 회로는 방송 스트림으로부터 임의의 DRM 관련 정보를 취득하지 않는다.

도 4는 방송 스트림이 수신 장치(20)에 의해 지원되는 DRM 서비스를 포함하는지 여부를 결정하기 위한 예시적인 방법을 도시한다. 특정 실시예들에서, SLT(Service List Table)는 방송 스트림이 DRM 관련 정보를 포함하는지를 결정하기 위해 이용된다. SLT는 LLS(Low Level Signaling)에 포함될 수 있으며, 그 예시는 ATSC Proposed Standard A/331 - Signaling, Delivery, Synchronization, and Error Protection(Doc S33-174r7)에 설명되어 있고, 본 명세서에서 그 전체가 참조로서 포함된다. LLS 정보는 SLT, RRT(Rating Region Table), 시스템 시간(System Time) 단편, AEAT(Advanced Emergency Alert Table), 및 온스크린 메시지 통지(Onscreen Message Notification) 단편 중 하나 또는 그것들의 조합을 포함할 수 있다. LLS 정보는 이 기능에 전용인어드레스/포트로 IP 패킷들의 페이로드에서 운반된다.

DRM 서비스는 일 실시예에 따른 DRM 관련 정보를 제공한다. 또한, DRM 서비스는 SLT를 사용하여 식별될 수 있다. 예로서, DRM 서비스는 SLT에 정의된 Service Category 구성요소 또는 다른 구성요소들 또는 속성들을 사용하여 식별된다.

예시적인 SLT가 아래 표 1에 예시된다. SLT의 기능은 MPEG-2 시스템들의 PAT(Program Association Table), 및 ATSC Mobile DTV Standard A/153, Part 3(Doc. A/153 Part 3:2013)에서 찾아지는 FIC(Fast Information Channel)의 기능과 유사하며, 이는 그 전체가 본 명세서에 참조로서 포함된다. 방송 스트림의 방송 방출을 처음 접하는 수신 장치(20)에 대해, SLT는 수신 장치(20)가 수신할 수 있는 방송 스트림 내의 서비스들의 리스트를 그들의 채널 이름, 채널 번호 등과 함께 구축할 수 있도록 허용하는 빠른 채널 스캔을 지원한다. SLT는 시청자들에게 의미가 있고 채널 번호 또는 업/다운 선택을 통해 각각의 서비스의 초기 선택을 지원할 수 있는 서비스 리스트의 제공을 허용하는 정보와, 빠른 채널 스캔들 및 서비스 취득을 지원하기 위해 나열된 각각의 서비스를 위한 SLS(Service Layer Signaling)를 찾는 데에 필요한 정보를 포함한다.

표 1은 일 실시예에 따른 SLT의 구조를 정의한다. 표 1에서 정의된 구성요소들의 상이한 조합들은 다른 실시예들의 SLT를 위해 이용될 수 있다.

<예시적인 SLT XML 포맷>

이하의 텍스트는 일 실시예에 따른 SLT내의 구성요소들 및 속성들의 예시적인 시멘틱들을 특정한다.

SLT - SLT의 루트 구성요소

@bsid - 하나 이상의 16 비트 부호없는 정수들의 이러한 리스트는 원래의 방출 신호(들)의 방송 스트림 ID(들)를 식별한다. 각각의 @bsid의 값은 물리 계층의 L1-상세 시그널링(Detail Signaling)의 L1D_bsid에서 시그널링된 값과 동일하다. 예로서, 그 전체가 참조로서 포함되는, ATSC Standard A/322 - Physical Layer Protocol (Doc. A/322:2017)를 참조하면 된다. 서비스가 물리 계층에서 채널 본딩을 통해 전달되는 경우, 리스트는 본딩에 포함된 각각의 RF 방출의 BSID 값을 포함한다.

SLTCapabilities - 이 SLT 인스턴스의 모든 서비스들을 위한 컨텐츠를 디코딩하고 의미있게 제시하기 위해 필요한 기능들이다. SLTCapabilities 구성요소의 신텍스 및 시멘틱들은, 예로서, ATSC Standard A/332 - Service Announcement(Doc. A/332-2017)의 Content 단편 하에서 특정된 sa:Capabilities 구성요소와 동일하며, 이는 그 전체가 본 명세서에서 참조로서 포함된다.

SLTInetUrl - 이용가능한 경우, 광대역을 통해 이 SLT의 모든 서비스들에 대한 ESG 또는 SLS 파일들을 취득하기 위한 기본 URL.

@urlType - sltInetUrl(ESG 또는 SLS)에서 이용가능한 파일들의 유형. 값들은 표 2를 참조하라.

urlType	의미
0	ATSC 예약됨
1	서비스 계층 시그널링 서버의 URL(섹션 7에 특정된 바와 같이, 서비스 계층 시그널링에의 액세스를 제공).
2	ESG 서버의 URL(예로서, A/332, 섹션 5.5.2에 특정된 바와 같이, ESG 데이터로의 액세스를 제공)
3	서비스 사용 데이터 수집 보고 서버의 URL(예로서, 그 전체가 본 명세서에 참조로서 포함되는, ATSC Standard A/333 -Service Usage Reporting(Doc. A/333:2017)에서 특정되는 보고 서비스 사용에서의 사용을 위한)
4	동적 이벤트 웹소켓 서버의 URL(예로서, 그 전체가 본 명세서에서 참조로서 포함되는 ATSC Candidate Standard A/337 - Application Signaling(Doc. S33-215r3)에서 특정되는 WebSocket프로토콜을 통해 동적 이벤트로의 액세스를 제공)
다른 값들	ATSC 예약됨

<urlType을 위한 예시적인 코드 값들>

Service - 서비스 정보

@serviceId - 이 방송 영역의 범위 내에서 이 서비스를 고유하게 식별하는 16비트 정수.

@globalServiceId - 이 ATSC 3.0 서비스의 아이덴티티를 나타내는 글로벌 고유 URI 값. 이 속성은 연결을 제공하며, 그것의 값은 예로서, 이 서비스에 대한 ATSC Standard A/332에 정의된 ESG의 Service@globalServiceId 속성의 값과 동일하다. 이 속성은 선형 A/V, 선형 오디오 전용, 및 앱 기반 서비스들에 대해 존재한다. 일 실시예에서, 이 속성은, 예로서, 이하에 설명된 바와 같은 DRM 시스템 ID 시그널링의 경우에 DRM 서비스들에 더 존재할 것이다.

@sltSvcSeqNum - 이 정수는 위의 serviceId 속성과 동등한 서비스 ID를 갖는 SLT 서비스 정보의 시퀀스 번호를 나타낸다. sltSvcSeqNum 값은 각각의 서비스에 대해 0에서 시작하며 이 서비스 구성요소의 임의의 속성 또는 하위(child)가 변경될 때마다 1씩 증가한다. serviceId의 특정 값을 갖는 이전의 서비스 구성요소와 비교하여 어떠한 속성 또는 하위 구성요소 값들도 변경되지 않는 경우, sltSvcSeqNum이 증가하지 않는다. sltSvcSeqNum 필드는 최대 값에 도달한 이후 0으로 되돌아간다.

@protected - "true"로 설정될 때, 의미있는 제시에 필요한 하나 이상의 컴포넌트들이 DRM을 통해 보호됨을 나타낸다. "false"로 설정될 때, 서비스의 의미있는 제공에 필요한 컴포넌트들이 그렇게 보호되지 않음을 지시한다. 기본값은 "false"이다.

@majorChannelNo - 서비스의 "주요" 채널 번호를 나타내는 1 내지 999 범위의 정수. 주요 채널 번호들의 할당은, ATSC 3.0 방송의 라이센스 사용자에 의해 사용되는 2-부분의 채널 번호 조합들이 중첩하는 DTV 서비스 영역을 갖는 임의의 다른 그러한 라이센스 사용자에 의해 사용되는 것들과 상이할 것을 보장하기 위해, 예로서, 그 전체가 본 명세서에서 참조로서 포함되는 ATSC Standard A/65 - Program and System Information Protocol for Terrestrial Broadcast and Cable의 Annex B에 제공된 가이드라인들을 따른다. 둘 사이에 등가의 프로그래밍이 주어진다면, ATSC 3.0 방송 서비스는 DTV 서비스 영역 내에서 ATSC A/53 방송에서 사용되는 동일한 2-부분의 채널 번호 조합을 사용할 수 있음에 유의해야 한다. ESG 데이터 전달 서비스, EAS 리치 미디어 전송 서비스, 또는 DRM 서비스와 같이 시청자들에 의해 직접 선택되는 것으로 의도되지 않는 서비스들에 대해서는 @majorChannelNo의 지정이 요구되지 않는다.

@minorChannelNo - 서비스의 "부" 채널 번호를 나타내는 1 내지 999 범위의 정수. 이 번호는 ESG 데이터 전달 서비스, EAS 리치 미디어 전달 서비스, 또는 DRM 서비스와 같이 시청자들에 의해 직접 선택되는 것으로 의도되지 않는 서비스들에 대해서는 요구되지 않는다.

@serviceCategory - 이 서비스의 카테고리를 나타내는 8비트 정수. 일 실시예에서, 값은 표 3에 따라 코딩된다.

serviceCategory	의미
0	ATSC 예약됨
1	선형 A/V 서비스
2	선형 오디오 전용 서비스
3	앱 기반 서비스
4	ESG 서비스(프로그램 가이드)
5	EAS 서비스(비상 알림)
6	DRM 서비스(DRM 관련 정보)
Other values	ATSC 예약됨

<SLT.Service@serviceCategory를 위한 예시적인 코드 값들>

@shortServiceName - 서비스의 짧은 이름(최대 7개의 문자). 이 이름은 ESG 데이터 전달 서비스, 또는 EAS 리치 미디어 전달 서비스와 같이 시청자들에 의해 직접 선택되도록 의도되지 않는 서비스들에 대해서는 요구되지 않는다. 일 실시예에서, 이 이름은 이하에 설명된 바와 같이, 예로서, DRM 시스템 ID 시그널링의 경우에서 DRM 서비스들을 위해 요구된다.

@hidden - 존재하고 "true"로 설정되면, 서비스가 테스트 또는 독점 용도를 위해 의도되며, 일반적인 TV 수신기들에 의해 선택되도록 의도되지 않는 것을 나타내는 Boolean 값이다. 존재하지 않을 경우 기본값은 "false" 이다.

@broadbandAccessRequired - 서비스의 의미있는 제공을 만들기 위해 수신기에 대해 광대역 액세스가 요구됨을 지시하는 불리언(Boolean). 기본값은 false이다.

@essential -이 불리언 속성이 존재하면, 이는 이 서비스가 하나보다 많은 RF 채널을 통해 전달된 하나 보다 많은 부분을 가짐을 나타낸다. 이 속성이 존재하지 않으면, 이는 이 서비스의 모든 부분들이 이 RF 채널을 통해 전달됨을 나타낸다. 이 속성이 "true"로 설정될 때, 이는 이 서비스의 필수적인 부분이 이 방송 스트림을 통해 전달됨을 지시한다. 이 속성이 "false"로 설정될 때, 이는 이 서비스의 필수적이지 않은 부분이 이 방송 스트림을 통해 전달됨을 나타낸다. 이 불리언 속성이 "true"로서의 값으로 존재하면, "2"와 동등한 @type을 갖는 적어도 하나의 OtherBsid 구성요소가 이 서비스에 대해 존재한다. 존재하지 않으면 기본값은 없다.

SimulcastTSID - 존재하는 경우, 이 16비트 숫자는, 이 ATSC 3.0 서비스에서 방송되고 있는대로, 존재하면 SimulcastTSID@simulcastMajorChannelNo, 존재하지 않으면 Service@majorChannelNo, 및 존재하면 SimulcastTSID@simulcastMinorChannelNo, 존재하지 않으면 Service@minorChannelNo로 식별되는 가상 채널 상에서, 동일한 프로그래밍 컨텐츠를 운반하는 ATSC 1.0 방송 방출의 TSID 값을 참조한다. TSID는, ATSC A/65에서 사용되는 바와 같이, 그 전체가 참조로서 포함되는 ISO/IEC 13818-1(MPEG-2 Systems)에 특정되어 있다. 존재하지 않을 때, 이 서비스의 프로그래밍 컨텐츠는 로컬 방송 영역의 임의의 ATSC 1.0 가상 채널과 연관되지 않는다.

@simulcastMajorChannelNo - 존재하는 경우, 동일한 프로그래밍 컨텐츠를 운반하는 ATSC 1.0 방송 서비스의 "주요" 채널 번호를 나타내는 1 내지 999 범위의 정수. 존재하지 않는 경우, Service@majorChannelNo는 동일한 프로그래밍 컨텐츠를 전달하는 ATSC 1.0 방송 서비스의 "주요" 채널 번호를 나타낸다.

@simulcastMinorChannelNo - 존재하는 경우, 동일한 프로그래밍 컨텐츠를 전달하는 ATSC 1.0 방송 서비스의 "부" 채널 번호를 나타내는 1 내지 999 범위의 정수. 존재하지 않는 경우, Service@minorChannelNo는 동일한 프로그래밍 컨텐츠를 운반하는 ATSC 1.0 방송 서비스의 "부" 채널 번호를 나타낸다.

SvcCapabilities - 위의 @serviceId 속성과 동등한 서비스 ID를 갖는 서비스에 대한 컨텐츠를 디코딩하고 의미있게 제시하기 위해 요구되는 기능들. SvcCapabilities 구성요소의 신텍스 및 시멘틱들은, 예로서, ATSC 3.0 서비스 Announcement 사양 A/332의 Content 단편 하에서 특정된 sa:Capabilities 구성요소와 동일하다.

BroadcastSvcSignaling - 이 구성요소 및 이것의 속성들은 방송 시그널링 관련 정보를 제공한다. BroadcastSvcSignaling 하위 구성요소가 존재하지 않을 때, (a) 서비스 구성요소의 구성요소 SvcInetUrl(즉, Service.SvcInetUrl 구성요소)가 1(SLS 서버로의 URL)과 동등한 그것의 urlType 속성(즉, Service.SvcInetUrl@urlType) 값을 갖고서 존재하거나, (b) 구성요소 SLTInetUrl가 1(시그널링 서버로의 URL)과 동등한 그것의 urlType 속성(즉, SLT.SLTInetUrl@urlType) 값을 갖고서 SLT 루트 구성요소의 하위 구성요소(즉, SLT.SLTInetUrl)로서 존재한다. 후자의 경우, SLTInetUrl은 <service_id> 경로 용어(path term)를 지원하고, 여기서 service_id가 서비스 구성요소에 대한 @serviceId 속성(즉, Service@serviceId 속성)에 대응한다.

@slsProtocol - 예로서 표 4에 따라 코딩된, 이 서비스에 의해 사용되는 SLS의 전달 프로토콜의 유형을 나타내는 속성.

slsProtocol	의미
0	ATSC 예약됨
1	ROUTE
2	MMTP
other values	ATSC 예약됨

<SLT.Service.BroadcastSvcSignaling@slsProtocol을 위한 예시적인 코드 값들>

@slsMajorProtocolVersion - 이 서비스를 위한 SLS를 전달하는 데 사용되는 프로토콜의 주요 버전 번호. 기본값은 1이다.

@slsMinorProtocolVersion - 이 서비스를 위한 SLS를 전달하는 데 사용되는 프로토콜의 부 버전 번호. 기본값은 0이다.

@slsDestinationIpAddress - 이 서비스를 위한 SLS 데이터를 운반하는 패킷들의 도트식(dotted)-IPv4 목적지 어드레스를 포함하는 문자열. 신텍스는 예로서 그 전체가 참조로서 포함되는 RFC 3986의 섹션 3.2.2에 정의되어 있다.

@slsDestinationUdpPort - 이 서비스를 위한 SLS 데이터를 운반하는 패킷들의 포트 번호.

@slsSourceIpAddress - 이 서비스를 위한 SLS 데이터를 운반하는 패킷들의 도트식-IPv4 소스 어드레스를 포함하는 문자열. 신텍스는 예로서 RFC 3986 섹션 3.2.2에 정의되어 있다. 이 속성은 @slsProtocol의 값이 1일 때 존재한다.

SvcInetUrl - 이용가능한 경우, 광대역을 통해 이 서비스를 위한 ESG 또는 SLS 파일들에 액세스하기 위한 기본 URL.

@urlType - SvcInetUrl과 함께 이용가능한 파일들의 유형. 예시적인 값들에 대해서는 표 2를 참조하면 된다.

표 1에 예시된 바와 같이, SLT는 방송 스트림에 포함된 하나 이상의 서비스에 대한 서비스 정보를 포함한다. SLT는 SLT에 정의된 각각의 서비스에 대한 Service Category 구성요소를 포함한다. Service Category들의 기능은 상이한 유형들의 서비스들의 이용가능성을 수신 장치(20)로 시그널링하는 것이다.

일 실시예에서, DRM 서비스는 SLT에서 DRM 서비스 카테고리에 의해 식별된다. 예로서, 위의 표 3에 예시된 바와 같이, SLT.Service@serviceCategory의 코드 값 6은 DRM 서비스 카테고리에 대응한다. 예로서, 선형 A/V 서비스는 보통의 "TV 시청" 선형 방송 서비스이고, 앱 기반 서비스는 수신 장치(20)가 BA를 다운로드 및 개시함에 따라 서비스 제공자들에 의해 사용자 경험이 정의된 서비스이고, ESG 서비스는 수신 장치(20)에게 그 고유의 ESG 기능에 필요한 데이터를 제공하고, EAS 서비스는 수신 장치(20)에게 긴급 경보와 연관된 미디어(예컨대, 사진, 오디오, 비디오, 텍스트)로의 액세스를 제공한다. 방송 스트림에서 전달되는 선형 A/V 서비스, 선형 오디오 전용 서비스, 및/또는 앱 기반 서비스는 보호될 수 있거나, 보호된 컨텐츠를 포함할 수 있다. 방송 스트림에서 제공되는 하나 이상의 DRM 서비스는 보호된 서비스 또는 컨텐츠에 액세스하기 위해 수신 장치(20)가 필요로 하는 DRM 관련 정보를 전달할 수 있다.

또한, 특정 서비스 유형들은, 예로서, TV 원격 제어를 통해 사용자에 의해 직접 선택가능하지 않을 수 있다. 예로서 ESG, EAS, 및 DRM 서비스들은 사용자에 의해 직접 선택가능하지 않다.

이상 설명된 바와 같이, DRM 서비스 카테고리는 특정 실시예들에 따른 DRM 관련 정보의 전달을 나타내는 데 사용된다. SLT의 임의의 주어진 인스턴스에 정의된 0 이상의 서비스는 Service@serviceCategory "DRM Service"로 식별될 수 있다. 또한, 서비스 제공자(20)가 다수의 DRM 시스템들을 지원하는 경우를 지원하기 위해 하나보다 많은 DRM 서비스가 SLT에서 식별될 수 있다.

DRM 서비스가 SLT에 나열되어 있으면, 예로서 ATSC Proposed Standard A/331의 섹션 7.1.4에 정의된 바와 같이, 수신 장치(20)는 SLT.Service.BroadcastSvcSignaling에 주어진 좌표들을 사용하여, S-TSID(Service-based Transport Session Instance Description)를 포함하는, 이 DRM 서비스와 연관된 SLS 테이블들을 찾는다. S-TSID는 ROUTE(Real-time Object delivery over Unidirectional transport) 세션들의 좌표들, 및 DRM 서비스와 연관된 파일들을 운반한 구성 계측화된 코딩 전송(Layered Coding Transport)(LCT) 채널을 제공한다. 예로서, DRM 서비스의 경우, LCT 채널은 DRM 라이센스들과 같은 DRM 관련 정보 파일들을 운반할 수 있다.

DRM이 가능하지 않은 수신 장치는 "DRM Service" 유형의 서비스들을 무시할 것이므로, DRM 관련 정보 파일들을 전달하는 LCT 채널들과 연관된 전송 패킷들을 보지 않을 것이다. 이는, 수신 장치들을 "혼란스럽게"하거나 불필요하게 파일들을 다운로드하여 수신 장치의 메모리 내에 저장하게하지 않기 위한 요건들 중 하나를 만족시킨다.

도 4에 도시된 바와 같이, DRM 시스템을 지원하는 경우, 수신 장치(20)는 일 실시예에 따라 SLT에 기초하여 방송 스트림이 수신 장치(20)에 의해 지원되는 DRM 서비스를 포함하는지 여부를 결정한다. 단계(S402)에서, 수신 장치(20)의 처리 회로는 방송 스트림으로부터 SLT를 추출한다. 일 실시예에 따라 방송 스트림에서 LLS 정보로부터 SLT가 추출된다.

단계(S404)에서, 수신 장치(20)의 처리 회로는 SLT가 DRM 서비스에 대한 서비스 카테고리 정보를 포함하는지 여부를 결정한다. 예로서, 처리 회로는 방송 스트림 내의 복수의 서비스 각각에 대해 SLT에 포함된 서비스 카테고리 정보를 검사한다. 처리 회로는, 예로서, DRM 서비스에 대응하는 serviceCategory 값에 대한 각각의 SLT.Service@serviceCategory의 코드 값을 검사한다.

단계(S406)에서, 수신 장치(20)의 처리 회로는 방송 스트림에 포함되는 것으로 결정된 각각의 DRM 서비스가 수신 장치(20)에 의해 지원되는지 여부를 결정한다. 일 실시예에서, 수신 장치(20)의 처리 회로는 SLT가 수신 장치(20)에 의해 지원되는 DRM 서비스(예컨대, serviceCategory 값 6)에 대응하는 미리 결정된 serviceCategory 값을 포함한다는 결정에 기초하여, 방송 스트림이 지원되는 DRM 서비스를 포함한다고 결정한다.

단계(S406)에서 수신 장치(20)가 방송 스트림이 하나 이상의 지원되는 DRM 서비스를 포함한다고 결정하면, 단계(S408)에서 수신 장치(20)는 하나 이상의 지원되는 DRM 서비스로부터 DRM 관련 정보를 취득하고, 단계(S410)에서 DRM 관련 정보를 처리하고, 처리된 DRM 관련 정보를 이용하여 단계(S412)에서 방송 스트림의 하나 이상의 보호된 서비스 및/또는 컨텐츠를 제시한다. 단계(S410)에서의 처리는, CDM(Content Decryption Module)으로 전달하기 위해, DRM 관련 정보로부터 복호화 키를 추출하거나, 그렇지 않으면, 필요한 경우 DRM 관련 정보를 파싱하는 단계를 포함할 수 있다.

일 실시예에서, 단계(S406)에서의 결정은 상이한 DRM 시스템들(예컨대, Marlin DRM 시스템, Microsoft PlayReady DRM 시스템)이 예로서 하나 이상의 서비스 제공자(10)에 의해 사용될 때, 또는 하나 이상의 추가적인 DRM 시스템의 미래의 사용을 허용하기 위해 수행된다. 예로서, 동일한 서비스 제공자(10)는 상이한 DRM 기능들을 갖는 수신 장치(20)가 서비스 또는 컨텐츠에 액세스하도록 허용하기 위해 다수의 DRM 시스템들을 사용하여 보호되는 동일하거나 상이한 서비스 또는 컨텐츠를 제공할 수 있다. 다른 예시에서, 제1 서비스 제공자(10)는 제1 DRM 시스템을 사용하여 보호되는 제1 서비스 또는 컨텐츠를 제공하는 한편, 제2 서비스 제공자(10)는 제1 DRM 시스템과는 다른 제2 DRM 시스템을 사용하여 보호되는 서비스 또는 컨텐츠를 제공한다.

DRM 시스템 ID 시그널링은 일 실시예에 따라 방송 스트림 내에 제공되어 수신 장치(20)가 서비스 제공자(10)에 의해 이용되는 하나 이상의 DRM 시스템을 식별하도록 허용한다. DRM 시스템 ID 시그널링은 수신 장치들(20)이 지원되는 DRM 제공자와 연관되지 않은 DRM 관련 정보(예컨대, DRM 라이센스 파일들)를 폐기하고, 지원되는 DRM 제공자와 관련된 DRM 관련 정보를 처리하도록 허용한다. 또한, 수신 장치(20)가 다수의 DRM 시스템들을 지원하면, DRM 시스템 ID 시그널링은 수신 장치(20)가 처리를 위해 DRM 관련 파일들을 적절한 CDM으로 라우팅하는 것을 돕는다.

DRM 시스템 ID 시그널링은 방송 스트림 내의 하나 이상의 DRM 서비스와 연관된 적어도 하나의 DRM 시스템을 식별한다. 일 실시예에서, DRM 시스템 ID 시그널링은 SLT의 레벨에서 제공된다. DRM 시스템 ID는, 서비스 카테고리가 DRM 서비스일 때, SLT.Service@shortServiceName 문자열 또는 SLT.Service@globalServiceID 문자열과 같은 SLT의 필드들 중 하나에서 시그널링될 수 있다.

그러나, DRM 시스템 ID는 SLT의 다른 필드들에서 시그널링될 수 있다. SLT의 각각의 서비스 또는 DRM 서비스에 대해 새로운 DRM 시스템 ID 속성(예컨대, SLT.Service@DRMsystemID)가 추가될 수 있다. DRM 시스템 ID는 SLT의 상이한 Service Category 값들을 사용하여 시그널링될 수 있다. 예로서, Service Category 값 6은 제1 DRM 시스템과 연관된 DRM 서비스에 대응할 수 있고, Service Category 값 7은 제1 DRM 시스템과는 다른 제2 DRM 시스템과 연관된 DRM 서비스에 대응할 수 있다. 또한, 일 실시예에서, DRM 시스템 ID는 DRM 관련 정보(예컨대, 이하에서 설명되는 바와 같은 헤더 필드들)에서 시그널링되거나 그렇지 않으면 제공될 수 있다.

DRM 시스템 ID는, 그 전체가 본 명세서에 참조로서 포함되는 MPEG DASH(ISO/IEC 23009-1) 및 DASH-IF Guidelines for Implementation: Dash-IF Interoperability Points, Version 4.0에 따라 DASH Industry Forum에 의해 등록된 UUID(Universally Unique Identifier)에 의해 식별될 수 있다. 예로서, UUID 문자열 값 "5E629AF5-38DA-4063-8977-97FFBD9902D4"는 그 전체가 본 명세서에 참조로서 포함되는 Marlin Adaptive Streaming Specification - Simple Profile, V1.0에 대응한다. 그러나, 다른 고유 식별자들은 DRM 시스템 ID를 위해 사용될 수 있다.

일 실시예에서, SLT.Service@global ServiceID 문자열에서 시그널링될 때 DRM 시스템 ID의 포맷은 "urn:uuid:<uuid>"이다. 일 예시에서 <uuid>는 이상에서 설명된 바와 같이 DASH-IF에 등록될 수 있다. 또한, 일 실시예에서, UUID가 글로벌 서비스 ID의 경우에서와 같이 URI에 포함되는 경우, URI는 "urn:uuid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"로 정의되며, 여기서 각각의 "x"는 16진수이다.

도 5는, 상이한 DRM 시스템들이 이용될 수 있는 경우 SLT를 사용하여 하나 이상의 DRM 서비스가 지원되는지 여부를 결정하기 위한 예시적인 방법을 도시한다. 단계(S502)에서, 수신 장치(20)의 처리 회로는 SLT로부터 DRM 시스템 유형 정보(예컨대, DRM 시스템 ID)를 추출한다. 예로서, 처리 회로는 하나 이상의 DRM 서비스와 연관된 SLT에서 짧은 서비스 이름(예컨대, SLT.Service@shortServiceName 문자열) 또는 글로벌 서비스 식별자(예컨대, SLT.Service@globalServiceID 문자열)로부터 하나 이상의 DRM 서비스에 대한 DRM 시스템 유형 정보를 추출한다.

단계(S504)에서, 수신 장치(20)의 처리 회로는 추출된 DRM 시스템 유형 정보에서 식별된 DRM 시스템 유형이 수신 장치(20)에 의해 지원되는지 여부를 결정한다. 예로서, 수신 장치(20)의 처리 회로는 DRM 시스템 유형 정보(예컨대, UUID와 같은 DRM 시스템 ID)를 임의의 지원되는 DRM 시스템들의 DRM 시스템 ID와 비교한다. 처리 회로는 DRM 시스템 유형 정보에 나타난 DRM 시스템 ID와 임의의 지원되는 DRM 시스템들의 DRM 시스템 ID가 일치할 때 DRM 시스템이 지원된다고 결정한다.

단계(S504)에서 수신 장치(20)가, 방송 스트림이 지원되는 DRM 시스템과 연관된 하나 이상의 DRM 서비스를 포함하는 것으로 결정하면, 수신 장치(20)는 단계(S506)에서 하나 이상의 지원되는 DRM 서비스들로부터 DRM 관련 정보를 취득하고, 단계(S508)에서 DRM 관련 정보를 처리하고, 처리된 DRM 관련 정보(예컨대, DRM 관련 정보에 포함된 복호화 키)를 사용하여 단계(S510)에서 방송 스트림 내의 하나 이상의 보호된 서비스 및/또는 컨텐츠를 제시한다. 단계(S508)에서의 처리는 CDM으로 전달하기 위해, DRM 관련 정보로부터 암호 복호화 키를 추출하거나, 그렇지 않으면, 필요한 경우 DRM 관련 정보를 파싱하는 단계를 포함할 수 있다.

처리 회로는, 수신 장치(20)에 의해 지원되지 않는 DRM 제공자의 DRM 시스템 ID와 연관된 방송 스트림 내의 DRM 서비스들을 무시한다. 예로서, 수신 장치(20)가 하나의 DRM 시스템만을 지원하고, 지원되는 DRM 시스템의 DRM 시스템 ID와 연관된 SLT에 나열된 DRM 서비스들이 없으면, 수신 장치(20)는 방송 스트림에 임의의 DRM 서비스들을 모니터링하는 것에 이점이 없음을 알고 있다.

도 3에 대해 이상에서 설명된 바와 같이, 단계(S306)에서의 수신 장치(20)는, 방송 스트림이 하나 이상의 지원되는 DRM 서비스를 포함하는 것으로 결정되면, 수신 장치(20)에 대한 DRM 관련 정보를 취득한다. 일 실시예에서, DRM 관련 정보는 ROUTE 프로토콜에서 전달된다.

특정 실시예들에 따르면, NRT 파일들은 예로서 ATSC Proposed Standard A/331에 설명된 ROUTE 프로토콜에 의해 전달된다. ROUTE는 RFC 5775에 정의된 ALC(Asynchronous Layer Coding)와 RFC 5651에 정의된 LCT가 IP 패킷들로 단편화된 파일을 전달하는 데 사용되는, RFC 6726에 정의된 FLUTE(File Delivery over Unidirectional Transport)의 변형이다. RFC 6726, 5775 및 5651은 그 전체가 본 명세서에서 참조로 포함된다.

임의의 파일 객체의 전달은 TSI(Transport Session Identifier)를 포함하는 패킷 구조, 및 TSI 내에서 각각의 파일과 연관된 전송 객체 표시자(Transport Object Indicator)(TOI)를 포함한다. 각각의 LCT 채널은 IP 어드레스/포트 조합 및 TSI 값과 연관된다.

언급된 바와 같이, 특정 실시예들에 따르면, DRM 서비스로서 SLT에 정의된 서비스는 서비스에 대한 SLS 데이터를 운반하는 방송 패킷들의 목적지 IP 어드레스 및 포트를 제공하는 BroadcastSvcSignaling 구성요소를 포함한다. DRM 서비스에 대해, ROUTE 프로토콜이 사용된다(ROUTE를 나타내는 SLT.Service.BroadcastSvcSignaling@slsProtocol="1"). ROUTE 기반 서비스들의 경우, SLS 데이터는 참조된 IP 패킷들 내에서 LCT 채널에 의해 전달된다. SLS 단편들은 TSI=0인 전용 LCT 전송 채널 상에서 전달된다. SLS 테이블들 중 하나인 S-TSID는 서비스와 연관된 파일들을 운반하는 하나 이상의 ROUTE 세션을 식별한다. 각각의 ROUTE 세션은 하나 이상의 LCT 채널을 포함한다. 각각의 LCT 채널은 TSI의 고유 값과 연관된다. S-TSID는 EFDT(Extended File Description Table)를 또한 포함할 수 있다. 대안적으로, EFDT는 TOI의 특수 값인 값 0을 사용하여 개별적으로 전송될 수 있다. 후자의 방법은 RFC 6726에 정의된 바와 같은 FLUTE와 호환된다.

ROUTE는 EFDT(Extended File Description Table)를 URL(Content-Location/filename), (인터넷 미디어 유형(Internet Media Type) 또는 MIME 유형으로 알려진) Content-Type, Content-Length, Content-Encoding 및 기타 파라미터들을 포함하는 LCT 채널과 연관된 파일들에 관한 정보를 제공하는 FLUTE RFC 6726에 정의된 FDT(File Description Table)로의 확장으로서 정의한다.

파일들은 FDT 또는 EFDT 없이, 또는 ROUTE "엔티티 모드(Entity Mode)"를 사용하여 FDT/EFDT의 파일에 대해 일치하는 임의의 엔트리 없이 LCT 채널에서 전송될 수 있다. 엔티티 모드에서 파일 객체는 파일의 실제 컨텐츠에 선행하는 "엔티티 헤더" 부분을 포함하며, 이는 인터넷 클라이언트들이 인터넷 서버들로부터 HTTP GET 동작들을 통해 파일들을 검색할 때 수신된 엔티티 헤더와 유사하다. 엔티티 헤더 부분은 적어도 Content-Location을 포함하고, Content-Type 및 다른 항목들을 포함할 수 있다. 수신 장치(20)는 공통 TOI 값을 갖는 모든 패킷들을 조립함으로써 LCT 채널에서 파일 객체들을 수집할 수 있다. 패킷들의 재조립을 위해, 각각의 패킷은 start_offset라고 지칭되는 LCT 헤더 필드에서, 각각의 수신된 단편을 배치하기 위한 파일 버퍼 내의 위치를 지시한다.

많은 수의 수신 장치들(20)을 위해 개별적으로 준비된 DRM 관련 정보(예컨대, DRM 라이센스들)의 경우, 전달될 상이한 파일의 수는 DRM 관련 정보의 방송 전달에 의존하는 지리적 영역에서 거의 수신 장치(20)의 개수만큼 클 수 있다. 따라서 그 수는 매우 클 수 있으며(수십만), 결과적으로 FDT에 각각의 파일을 개별적으로 나열하는 것은 실용적이지 않을 수 있다.

파일 템플릿은 일련의 DRM 관련 정보 파일들의 전달을 위해 사용될 수 있다. RFC 6726의 FLUTE에 정의된 FDT-Instance 구성요소의 확장으로서 정의된 예시적인 "파일 템플릿"이 표 5에 예시된다.

구성요소 또는 속성 이름	사용	데이터 유형	설명
@efdtVersion	0..1	unsignedByte	이 확장된 FDT 인스턴스 복호화기의 버전.
@maxExpiresDelta	0..1	unsignedInt	연관된 EFDT의 만료 시간을 도출하는 데 사용되기 위한 시간 구간.
@maxTransportSize	0..1	unsignedInt	이 EFDT에 의해 설명되는 임의의 객체의 최대 전송 사이즈
@appContextIdList	0..1	afdt:uriList	하나 이상의 고유 어플리케이션 컨텍스트 식별자(Application Context Identifier)를 표시하는 URI들의 공백으로 구분되는 리스트(space-separated list)
@fileTemplate	0..1	string	파일 URL, 즉 FDT의 Content-Location 속성을 생성하기 위한 수단들을 설명
@filterCodes	0..1	afdt:listOfUnsignedInt	소스플로우의 모든 파일들에 적용되는 필터 코드들

<FDT-Instance 구성요소의 확장들>

이하의 텍스트는 일 실시예에 따른 FDT-Instance 구성요소로의 확장들에서 구성요소들 및 속성들의 시멘틱을 특정한다.

@efdtVersion - 이 EFDT 구성요소의 버전을 나타내는 8비트의 부호없는 정수 값. EFDT 구성요소가 업데이트될 때마다 버전이 1 모듈로 256(one modulo 256)만큼 증가한다. @version은 RFC 6726에서 특정된 FLUTE FDT의 ATSC 정의 확장이다.

@maxExpiresDelta - EFDT에 의해 설명된 객체를 운반하는 제1 ROUTE 패킷을 취득할 때 수신기에서 벽시계 시간(wall-clock time)에 추가될 때 연관된 EFDT의 만료 시간을 나타내는 초 단위의 시간 구간을 나타내는 32 비트 부호없는 정수 값. @maxExpiresDelta가 존재하지 않으면, EFDT의 만료 시간은 a) ROUTE 패킷의 EXT_TIME LCT 헤더 확장의 ERT 필드의 값과 b) 패킷 헤더를 파싱할 때의 현재 수신기 시간의 합으로 주어진다. @maxExpiresDelta는 RFC 6726에서 특정된 FLUTE FDT의 ATSC 정의 확장이다.

@maxTransportSize - 이 EFDT에 의해 설명되는 임의의 전달 객체의 바이트 단위의 최대 전송 사이즈를 나타내는 32 비트 부호없는 정수 값. 이 속성은 1) FDT-Instance@fileTemplate가 존재하는 경우, 또는 2) 이 EFDT의 하나 이상의 File 구성요소들이 @Transfer-Length 속성을 포함하지 않는 경우에 존재한다. @maxTransportSize가 존재하지 않으면, 최대 전송 사이즈가 시그널링되지 않는다.

@appContextIdList - 공백들로 구분된 고유 URI 값들의 리스트로, 존재하는 경우, 포함하는 구성요소들과 연관된 하나 이상의 어플리케이션 컨텍스트 식별자를 정의한다. 파일들은 다수의 어플리케이션 컨텍스트들과 연관될 수 있다. 어플리케이션 컨텍스트 식별자들은 그 전체가 본 명세서에 참조로 포함되는 ATSC Candidate Standard A/344(Doc. S34-230r4)에 정의된 바와 같이 방송사 어플리케이션들과 함께 사용하기 위해 파일들을 그룹핑하는 메커니즘을 제공한다.

확장된 FDT 구성요소인 FDT-Instance@appContextIdList의 속성으로서 포함된 임의의 어플리케이션 컨텍스트 식별자들은 FDT-Instance 데이터 구조의 하위들로 정의된 모든 파일들과 연관된다. File 구성요소인 File@appContextIdList의 리스트 속성에 정의된 임의의 어플리케이션 컨텍스트 식별자들은 그 파일에만 연관된다. 따라서, 특정 파일과 연관된 어플리케이션 컨텍스트 식별자들의 전체 집합은 두 리스트들: File@appContextIdList 및 FDT-Instance@appContextIdList의 합집합을 포함한다.

각각의 어플리케이션 컨텍스트 식별자는 파일들이 함께 그룹화되도록 허용하는 글로벌 고유 URI이다. 수신기들은 어플리케이션 컨텍스트 식별자를 사용하여 하나의 어플리케이션 컨텍스트 식별자로부터의 파일들의 그룹이 다른 어플리케이션 컨텍스트 식별자에 할당된 파일들의 그룹으로부터 완전히 분리되도록, 연관된 파일들로의 액세스를 제공한다. 파일은 다수의 어플리케이션 컨텍스트 식별자들과 연관될 수 있으며, 각각은 파일에 액세스하기 위한 상이한 URL을 낳는다. 이러한 방식으로 파일들은 어플리케이션들 사이에서 공유될 수 있다.

@fileTemplate - 존재하면, 파라미터 대체와 함께 이 EFDT에 의해 설명되는 전달 객체에 대한 파일 URL, 즉, Content-Location 속성을 도출하는 데 사용되는 문자열 값. 예로서, ATSC Proposed Standard A/331의 섹션 A.3.3.2.7에 더 설명되는 바와 같은 메커니즘은 @fileTemplate의 문자열 표현에서 패턴 '$TOI$'에 대한 전달 객체의 TOI 값을 대체하는 것을 포함한다. 도출된 Content-Location은, 예로서 방송 전달 리소스들에 대한 ATSC Proposed Standard A/331 섹션 A.3.3.2.7의 조항들을 준수하는 관련 URI(relative URI)이다. 이러한 수단에 의해, TOI와 파일 URL 사이의 일대일 맵핑이 생성된다. 또한, 이것은 소스 플로우의 각각의 전달 객체가 DASH 세그먼트인 이벤트에서, 세그먼트 번호가 객체의 TOI 값과 동등할 것임을 암시한다. LCT 채널이 일련의 DASH 미디어 세그먼트(Media Segment) 파일들을 운반할 때, @fileTemplate 속성이 EFDT에 존재한다.

@filterCodes -File@fileFilterCode 속성의 필터 코드들이 우선권을 갖는 경우인 File@fileFilterCode 속성이 존재하는 파일들을 제외하고서, EFDT에서 식별된 모든 파일들과 연관된 필터 코드들을 나타내는 32비트 부호없는 정수들의 공백으로 구분된 리스트.

파일 템플릿의 일 실시예에 따르면, 새로운 TOI를 갖는 LCT 패킷이 이 전송 세션에 대해 수신되면, 이후, 다음과 같이 새로운 File 엔트리와 함께 확장된 FDT 인스턴스가 생성된다:

TOI는 File@Content-Location을 생성하는데 사용된다. EFDT.FDT-Instance 구성요소에 존재하는 모든 다른 속성들은 파일에 적용 가능하다.

(RFC 5775에 따른) EXT_FTI 헤더 또는 (ATSC Proposed Standard A.331, 섹션 A.4.2.6.1에 따른) EXT_TOL 헤더는, 존재하면, 파일의 전송 객체 길이(Transport Object Length)(TOL)를 시그널링하는 데 사용된다. 확장된 FDT 인스턴스에 File@Transfer-Length 파라미터가 존재하지 않으면, EXT_TOL 헤더 또는 EXT_FTI 헤더가 존재한다. 전송 객체 길이(EXT_TOL 또는 EXT_FTI)를 포함하는 헤더가 각각의 패킷 헤더에 존재할 필요는 없음에 유의해야 한다. 방송사가 전송 시작 시에 전송 객체의 길이를 모르면, EXT_TOL 또는 EXT_FTI 헤더가 적어도 파일의 마지막 패킷에 포함되며 전송의 마지막 몇몇 패킷들에 포함되어야 한다.

존재하면, @maxExpiresDelta는 @Expires 속성의 값을 생성하는 데 사용된다. 수신기는 이 값을 현재 시간에 더하여 @Expires에 대한 값을 얻을 것으로 기대된다. 존재하지 않으면, ERT(Expected Residual Time)을 갖는 EXT_TIME 헤더가 확장된 FDT 인스턴스의 만료 시간을 추출하는 데 사용된다. 둘 다 존재하면, @Expires에 대한 유효 값을 생성하기 위해 두 값들 중 더 작은 값을 수신기의 현재 시간에 추가될 증가 시간 구간으로서 사용되어야 한다. @maxExpiresDelta과 EXT_TIME의 ERT 필드 모두가 존재하지 않으면, 확장된 FDT의 만료 시간은 확장된 FDT 인스턴스의 @Expires 속성에 의해 주어진다.

일 실시예에서, @fileTemplate 속성은 "$TOI$" 식별자를 포함한다. 이 전송 세션에서 TOI 번호를 사용하는 파라미터 대체 후에, @fileTemplate은 연관된 파일의 Content-Location 속성에 대응하는 유효한 URL이다. FDT-Instance.File 구성요소들에 나열된 임의의 파일들과 연관된 TOI 값들을 제외하고, @fileTemplate 속성은 TOI와 Content-Location 값 사이의 일대일 맵핑을 생성한다. 일련의 DASH 미디어 세그먼트들(Media Segments)을 식별하기 위해 @fileTemplate가 사용되면, 세그먼트 번호는 TOI 값과 등가이다.

각각의 파일에 대한 Content-Location URL은 파일을 형성하는 재조립된 패킷들과 연관된 TOI 값으로부터 생성된다. 예로서, "exampleFile$TOI$.mp4"의 @fileTemplate 문자열에 대해, TOI 값 556을 갖는 패킷들로부터 수집된 파일은 URL "exampleFile556.mp4"을 갖는 파일인 것으로 이해될 것이다.

이 프로토 타입을 따르는 둘러싸는(enclosing) '$' 문자들 내에서 각각의 식별자에 접미사가 붙을 수 있다.

%0[width]d

width 파라미터는 프린팅될 문자들의 최소 개수를 제공하는 부호없는 정수이다. 프린팅될 값이 이 개수보다 짧으면 결과는 0들로 채워진다. 결과가 더 크더라도 값은 줄어들지 않는다.

5의 폭을 사용하는 예시적인 @fileTemplate는:

fileTemplate="myVideo$TOI%05d$.mps"이고, 숫자 부분에 정확히 5개의 숫자를 갖는 파일 이름들을 야기한다. 이 템플릿을 사용하는 TOI=33에 대한 미디어 세그먼트(Media Segment) 파일 이름은 "myVideo00033.mps" 이다.

대체 프로세스의 적용이 유효 URI들을 야기하도록 @fileTemplate이 작성된다.

식별자들 외부의 문자열들은 RFC 3986에 따른 URI들 내에서 허용되는 문자들만을 포함한다.

$<Identifier>$	대체 파라미터	포맷
$$	이스케이프 시퀀스, 즉, "$$"는 비재귀적으로 하나의 "$"으로 대체된다.	적용할 수 없음
$TOI$	이 식별자는 TOI로 대체된다.	포맷 태그가 존재할 수 있다. 포맷 태그가 존재하지 않으면, width=1인 기본 포맷 태그가 사용된다.

<파일 템플릿들을 위한 예시적인 식별자들>

파일 템플릿 URL은 전송 세션에서 주어진 파일(예컨대, 이진 파일, XML 파일, zip 파일, 또는 다른 압축된 아카이브 파일)에 대한 TOI의 값으로 대체되는 "$TOI$"라고 지칭되는 식별자를 포함한다. 예로서, FDT가 "MarlinLicense$TOI%10d$.bin"으로서 정의된 fileTemplate을 포함하면, TOI 값 2155872260를 갖는 패킷들로부터 재조립된 파일은 파일 MarlinLicense2155872260.bin임이 이해될 것이다. TOI 값 2와 연관된 파일은 MarlinLicense0000000002.bin일 것이다. 이 파일들은 일 실시예에 따른 DRM 관련 정보를 포함한다.

많은 수의 순차 파일들이 ROUTE 전송에서 전달되고 정의될 수 있도록 허용하는 편리한 방법인 것에 더하여, TOI 값이 수신 장치(20)와 연관되는 디바이스 ID 또는 다른 고유 식별자(예컨대, MAC[Media Access Control] 어드레스)와 관련되도록 DRM 제공자에 의해 정의되면, 이 코딩의 추가적인 이점이 얻어질 수 있다. 이 경우, 수신 장치들(20)은 LCT 채널 내의 TOI 값이 그 유닛의 디바이스 ID(또는 다른 고유 식별자)의 모든 또는 특정 비트들과 일치하지 않는 임의의 DRM 관련 정보 파일을 폐기할 수 있다. 예로서, TOI 값이 32 비트이고 유닛의 디바이스 ID가 32 비트 이상이면, 유닛의 디바이스 ID의 최하위 31 비트가 필터링을 위해 사용될 수 있다. 다른 실시예들에서, 다른 미리 결정된 개수의 최하위 비트들이 사용될 수 있다. 이 예시에서 최하위 31 비트들의 사용은, 디바이스 ID의 하위 31 비트들이 0인 유닛들에 대해 TOI=0의 사용이 회피되도록 허용한다. 이 빠른 필터링은 수신 장치들(20)이 많은 CPU 사이클들을 절약하도록 허용할 수 있다.

FDT-Instance@fileTemplate 속성이 사용될 수 있는 방법의 예시는 다음과 같다. DRM 제공자는 유닛 지정된 DRM 관련 정보 파일들의 전달을 위해 이하의 규칙들을 특정할 수 있다. 이 예시는 디바이스 ID가 32비트 이상이라고 가정한다: (a) 디바이스를 대상으로 하는 파일들은 디바이스 ID의 31개의 최하위 비트들과 동일한 TOI 값들을 사용할 것이다; 예외로 (b) 디바이스 ID의 31개의 최하위 비트들이 0이면, TOI 값 2147483648(0x80000000)이 사용된다.

위에서의 TOI 값 2147483648(0x80000000) 또는 다른 미리 결정된 TOI 값의 사용은 TOI=0이 독립형 FDT들의 전달을 위해 예약되어(reserved) 있다는 사실을 고려하므로, 임의의 다른 파일 객체와 연관되거나 파일 템플릿에 의해 설명된 파일과 연관될 수 없다.

이러한 예시 파일들을 전달하는 데 사용될 수 있는 예시적인 FDT-Instance 구성요소는 이하와 같다:

위의 예시에서, "fileTemplate"로 시작하는 라인의 "%10d"는 TOI 숫자 필드에 대해 10개의 숫자의 사용을 지정한다. 그러나, 다른 실시예들에서 상이한 개수의 숫자들이 지정될 수 있다. 또한, "<File Content Type" 및 "Content-Location"으로 시작하는 라인들은 최하위 31 비트들이 0과 동등한 디바이스 ID들에 대해 TOI 값 2147483648의 사용을 정의한다.

디바이스 ID가 검사된 비트들(예컨대, 31 비트들)의 수보다 긴 경우, 주어진 파일은, 하위 31 비트들 또는 다른 미리 결정된 비트들이 TOI 값(또는 파일이름의 숫자 필드)에 일치하는 다수의 수신 장치들(20)에 대한 라이센스들을 포함할 수 있다. 전체 디바이스 ID는 파일 자체 내에 포함될 수 있고, 수신 장치(20)는 자신의 디바이스 ID에 대응하지 않는 임의의 DRM 관련 정보를 폐기할 수 있다. 상이한 개수들의 검사된 비트들이 상이한 실시예들에서 사용될 수 있다. 예로서, 16개의 검사된 비트들의 경우, 수신 장치(20)는 (파일 컨텐츠들을 검사함으로써) 처리되는 파일이 자신의 디바이스 ID를 포함하는지 여부를 결정하기 전에 파일들의 99.998%(65536 중에서 65535)를 폐기할 수 있다.

일 실시예에서, 위에서 설명된 바와 같이 DRM 관련 정보와 함께 전달된 헤더 필드들은 FDT-Instance(확장된 FDT)의 엔트리들을 사용하는 대신, 수신 장치(20)에 대한 DRM 관련 정보를 취득하는 데 사용될 수 있다. 예로서, ATSC Proposed Standard A/331은 파일 자체의 컨텐츠들에 선행하여, 파일의 HTTP 헤더 필드들이 전달에 포함되는 방법으로 Entity Mode를 설명한다.

일 실시예에 따르면, 엔티티 모드(Entity Mode)에서의 전달 객체는 HTTP/1.1에서의 표현과 유사하고 그것의 데이터는 HTTP 메시지의 페이로드 바디에 포함된다. 전달 객체는, 그 전체가 본 명세서에 참조로 포함되는 RFC 7231의, 예로서, 섹션들 3.1, 3.3 및 7에 각각 정의된 바와 같은 표현 헤더 필드들, 페이로드 헤더 필드들, 및 응답 헤더 필드들 중 하나 이상에 대응하는 "엔티티 헤더들(entity headers)"의 형태로 메타 데이터에 의해 설명된다.

헤더 필드들은 클라이언트로부터의 HTTP GET 요청에 응답하여 파일을 전달할 때 HTTP 서버가 포함할 수 있는 이러한 구성요소들 중 임의의 것을 포함할 수 있다. HTTP 헤더 필드들은 Content-Location, Content-Type, Content-Encoding, 및 Content-Length 중 하나 또는 그것들의 조합을 포함할 수 있다.

DRM 관련 정보 파일들이 방송 스트림에서 분배되는 경우, 예로서, ATSC Proposed Standard A/331에 설명된 바와 같은 ROUTE 프로토콜이 사용될 수 있다. 엔티티 모드(Entity Mode)가 사용되는 경우, FDT-Instance(확장된 FDT)의 엔트리들이 생략될 수 있다. 대신, 수신 장치(20)가 주어진 TOI 값과 연관된 패킷들을 수집함에 따라 파일들이 재구성된다. 객체의 적어도 헤더 부분이 수집된 후, 수신 장치(20)가 파일이 그 자신에 연관되는지 아니면 다른 것에 연관되는지를 즉시 결정할 수 있는 그러한 방식으로 정의될 수 있는 Content-Location(파일 이름)를 찾기 위해 헤더 필드들은 검사될 수 있다. 예로서, 전체 디바이스 ID는 파일 이름의 알려진 위치(예컨대, "." 및 파일이름 확장자에 선행하는 마지막 12개의 문자들) 내에 존재하도록 정의될 수 있다. 다른 HTTP 헤더 필드들, 예로서 쿠키(Cookie) 필드도 잠재적으로 이 기능을 제공할 수 있다.

일 실시예에서, 방송 스트림에서의 시그널링은, DRM 가능한 수신 장치(20)에게, 일 실시예에 따른 하루 중 특정 시간 기간 동안 DRM 관련 정보가 방송 스트림 내에(예컨대, SLT에서 시그널링된 DRM 서비스에서) 있거나 존재할 것임을 나타낸다. "분배 윈도우"가 DRM 서비스에 대한 SLS에 포함될 수 있다. "분배 윈도우"는, 그 전체가 본 명세서에 참조로서 포함되는 ATSC Candidate Standard A/337 - Application Signaling(Doc. S33-215r3)에 정의된 DWD(Distribution Window Description) 시그널링 테이블의 하나 이상의 구성요소를 포함할 수 있다. DWD는, 수신 장치(20)에 관심을 가질 수 있는 특정 파일들이 하루 중 특정된 시간에 시작하고 하루 중 다른 특정된 시간에 종료하는 방송 방출에 존재할 것임을 나타낸다.

이상에서 설명된 바와 같이, 주어진 DRM 시스템을 지원하기 위한 DRM 관련 정보는 SLT에서 DRM 서비스로서 시그널링될 수 있고, 그 시스템에 대한 DRM 시스템 ID는 그 특정 DRM 서비스와 연관될 수 있다. 또한, 특정 DRM 서비스에 대한 DRM 관련 정보 전달에 관한 정보를 제공하기 위해 DWD를 포함하는 SLS 테이블들이 전송될 수 있다.

분배 윈도우 자체는 상당히 클 수 있으며, 예컨대, 매일 오전 1시부터 6시까 지 지속될 수 있다. 이 5시간 윈도우 동안, 방송 영역의 각각의 유닛에 대한 DRM 관련 정보가 전송될 수 있다. 수신 장치(20)가 전체 윈도우 기간 동안 DRM 서비스를 모니터링할 필요를 피할 수 있다면 바람직할 것이다. 따라서, 일 실시예에서, DRM 제공자는 분배 윈도우가 사용될 때 동작을 최적화하기 위해 힌트를 수신 장치(20)에 제공한다:

일 실시예에서, 각각의 수신 장치(20)는, 수신 장치(20)와 연관된 그것의 디바이스 ID 또는 다른 고유 식별자에 의존하는 알고리즘에 기초하여 0.0과 1.0 사이의 수를 계산한다. 임의의 적합한 알고리즘이 가능하다. 일 예시는 디바이스 ID의 미리 결정된 수의 최하위 비트들(예컨대, 최하위 16 비트들)을 이진 소수(binary fraction)로서 사용하는 것이다.

수신 장치(20)는 계산된 수를 취하고, 그에 따라, 분배 윈도우를 정제하기 위한 지표(guidance)로서 사용한다. 예로서, 결과적인 수가 0.5인 경우, 수신 장치(20)는 분배 윈도우를 통해 중간에 DRM 서비스 모니터링하는 것을 시작할 수 있다. 결과적인 수가 0.99이면, 수신 장치(20)는 윈도우 기간의 끝 근처에서 모니터링을 시작할 수 있다. 방송사는 전체 세트가 전송된 때까지 윈도우의 끝을 지나서 DRM 관련 정보(예컨대, 라이센스 메시지들의 형태의 DRM 라이센스들)를 계속 전송할 수 있다. 또한, 일 실시예에서, 수신 장치(20)는 필요한 DRM 관련 정보(예컨대, 라이센스 또는 업데이트)가 수신되었다는 CDM으로부터의 피드백을 수신하고, 그에 의해 메시지들의 추가 처리가 종료될 수 있다(예컨대, 하루 동안, 또는 더 길게).

도 6은 일 실시예에 따라 서비스 제공자(10)의 서비스 분배 시스템의 동작을 보여주는 흐름도이다. 단계(S602)에서, 서비스 분배 시스템의 처리 회로는, 예로서 표 1의 신텍스에 따른 SLT를 포함하는 LLS 데이터와 같은 DRM 관련 정보 및/또는 DRM 서비스 시그널링 정보를 생성한다. 이상에서 설명된 바와 같이, SLT는 데이터 스트림(예컨대, 방송 스트림)이 DRM 관련 정보를 전달하기 위한 하나 이상의 DRM 서비스를 포함하는지 여부를 나타낼 수 있다. 서비스 분배 시스템의 처리 회로는, 예로서 이상에서 설명된 바와 같이, 수신 장치(20)에 의한 DRM 관련 정보의 취득을 용이하게 하기 위해 DRM 시스템 ID 정보, FDT 인스턴스들, HTTP 헤더 정보, 분배 윈도우 정보, 및/또는 임의의 다른 정보도 생성할 수 있다.

단계(S604)에서, 서비스 분배 시스템의 처리 회로는 IP 패킷들을 생성한다. IP 패킷들의 페이로드들은 단계(S602)에서 생성된 DRM 서비스 시그널링 정보 및 DRM 관련 정보 중 어느 하나 또는 그것들의 조합을 포함한다. IP 패킷들은 미리 결정된 어드레스 및 목적지 포트를 갖는다. 그 후, 단계(S604)에서, 서비스 분배 시스템의 송신기는 IP 패킷들을 전송한다. 예로서, 송신기는 디지털 텔레비전 지상파 방송 채널을 통해 IP 패킷들을 포함하는 방송 스트림을 전송한다.

도 7은 수신 장치 및 서비스 분배 시스템 중 어느 하나 또는 그것들의 조합의 기능들을 수행하도록 구성될 수 있는 컴퓨터의 하드웨어 구성의 예시를 보여주는 블록도이다. 예로서, 일 실시예에서, 컴퓨터는 수신 장치(20) 및/또는 서비스 분배 장치에 대해 본 명세서에 설명된 기능들 중 하나 또는 그것들의 조합을 수행하도록 구성된다.

도 7에 도시된 바와 같이, 컴퓨터는 하나 이상의 버스(708)를 통해 서로 상호 연결된 CPU(702), ROM(Read Only Memory)(704), 및 RAM(Random Access Memory)(706)을 포함한다. 하나 이상의 버스(708)는 입력-출력 인터페이스(710)와 더 연결된다. 입력-출력 인터페이스(710)는 키보드, 마우스, 마이크로폰, 원격 컨트롤러 등에 의해 형성된 입력부(712)와 연결된다. 입력-출력 인터페이스(710)는 오디오 인터페이스, 비디오 인터페이스, 디스플레이, 스피커 등에 의해 형성된 출력부(714); 하드 디스크, 비-휘발성 메모리, 또는 다른 비-일시적 컴퓨터 판독가능 저장 매체에 의해 형성된 기록부(716); 네트워크 인터페이스, 모뎀, USB 인터페이스, 파이어 와이어 인터페이스 등에 의해 형성된 통신부(718); 자기 디스크, 광 디스크, 광 자기 디스크, 반도체 메모리 등과 같은 이동식 매체(722)를 구동하기 위한 드라이브(720)를 포함한다.

일 실시예에 따르면, CPU(702)는 입력-출력 인터페이스(710) 및 버스(708)를 통해 기록부(716)에 저장된 프로그램을 RAM(706)에 로딩한 후에, 수신 장치(20) 및/또는 서비스 분배 장치에 대해 본 명세서에서 설명된 기능들 중 하나 또는 그것들의 조합의 기능을 제공하도록 구성된 프로그램을 실행한다.

도 26 및 도 7에 도시된 구조 예시들 중 어느 하나에 의해 예시된 위의 하드웨어 설명은, 예로서 도 3 내지 도 6을 참조하여 위에서 설명된 알고리즘을 수행하도록 프로그래밍 또는 구성되는 특화된 대응 구조를 구성하거나 포함한다. 예로서, 도 3 내지 도 5에 도시된 알고리즘들 중 임의의 하나 또는 그것들의 조합은 도 2에 도시된 단일 디바이스에 포함된 회로에 의해 완전히 수행될 수 있다.

전술한 설명의 특징들을 포함하는 시스템은 수많은 장점들을 제공한다. 특히, 본 명세서에 설명된 방법론들은 DRM 불가능한 수신 장치들 또는 특정 DRM 시스템들을 지원하지 않는 수신 장치들의 동작을 방해하지 않으면서, 보호된 서비스들에 액세스하기 위해 DRM 가능 수신 장치들에 대한 DRM 관련 정보를 전송 및 취득하기 위해 채용될 수 있다.

명백하게, 이상의 교시들의 관점에서 많은 수정들 및 변형들이 가능하다. 따라서, 첨부된 청구항들의 범위 내에서 본 개시는 본 명세서에서 구체적으로 설명된 것과 다르게 실시될 수 있음이 이해될 것이다.

따라서, 전술한 논의는 단지 본 개시의 예시적인 실시예들을 개시하고 설명한다. 본 기술분야의 통상의 기술자에 의해 이해될 수 있을 것과 같이, 본 개시는 그 사상 또는 본질적인 특성들을 벗어나지 않고 다른 특정 형태들로 구현될 수 있다. 따라서, 본 개시는 예시적인 것으로 의도되지만, 다른 청구항들뿐만 아니라 본 개시의 범위를 제한하는 것은 아니다. 본 명세서의 교시들의 임의의 용이하게 식별 가능한 변형들을 포함하는 본 개시는 진보한 주제가 공중에 전용되지 않도록 전술한 청구항 용어의 범위를 부분적으로 정의한다.

이상의 개시는 이하에 나열된 실시예들도 포함한다.

(1) 방송 스트림을 수신하도록 구성되는 수신기 회로; 및 처리 회로를 포함하고, 처리 회로는 방송 스트림 내의 복수의 서비스 각각에 대한 서비스 정보를 포함하는 SLT(Service List Table)을 방송 스트림으로부터 추출하고, 방송 스트림의 복수의 서비스에 대한 서비스 정보 내의 서비스 카테고리 정보에 기초하여, 방송 스트림이 수신 장치에 의해 지원되는 DRM(Digital Rights Management) 서비스를 포함하는지 여부를 결정하고, 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함한다는 결정에 기초하여, 수신 장치와 관련되고 DRM 서비스에서 전달되는 DRM 관련 정보를 취득하도록 구성되는, 수신 장치.

(2) 처리 회로는, 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함하는 것으로 결정되면, 방송 스트림으로부터, DRM 서비스에 대해 서비스 정보에 포함되는 방송 시그널링 관련 정보에 기초하여 DRM 서비스와 연관된 SLS(Service Layer Signaling)를 추출하고; 추출된 SLS에 기초하여 방송 스트림 내의 LCT(Layered Coding Transport) 채널로부터 DRM 관련 정보를 취득하도록 구성되는, 특징 (1)에 따른 수신 장치.

(3) 처리 회로는, 수신 장치의 고유 식별자의 미리 결정된 수의 최하위 비트들에 일치하는 TOI(Transport Object Indicator)와 연관되는 LCT 채널으로부터의 DRM 관련 정보 파일을 취득하도록 구성되는, 특징 (2)에 따른 수신 장치.

(4) 처리 회로는, DRM 관련 정보 파일들과 함께 전달되는 헤더 필드들에 기초하여 방송 스트림의 LCT(Layered Coding Transport) 채널에서 전달되는 DRM 관련 정보 파일들을 필터링하고; 필터링된 DRM 관련 정보를 취득하도록 구성되는, 특징들 (1) 내지 (3) 중 어느 하나에 따른 수신 장치.

(5) DRM 서비스에 대한 서비스 정보는 DRM 시스템 식별 정보를 포함하고, 처리 회로는, 서비스 정보에 포함되는 서비스 카테고리 정보 및 DRM 시스템 식별 정보에 기초하여, 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함하는지 여부를 결정하도록 구성되는, 특징들 (1) 내지 (4) 중 어느 하나에 따른 수신 장치.

(6) DRM 시스템 식별 정보는 SLT 내의 DRM 서비스의 짧은 서비스 이름 또는 글로벌 서비스 식별자로서 식별되는, 특징들 (1) 내지 (5) 중 어느 하나에 따른 수신 장치.

(7) 복수의 서비스는 선형 A/V 서비스를 포함하고, 처리 회로는, 취득된 DRM 관련 정보를 사용하여 선형 A/V 서비스, 또는 선형 A/V 서비스의 적어도 하나의 컴포넌트를 복호화하도록 구성되는, 특징들 (1) 내지 (6) 중 어느 하나에 따른 수신 장치.

(8) DRM 관련 정보는 수신 장치의 고유 식별자와 연관되는, 특징들 (1) 내지 (7) 중 어느 하나에 따른 수신 장치.

(9) 처리 회로는, 방송 스트림에 포함되는 스케줄링 정보에 기초하여 DRM 서비스에 대한 분배 윈도우를 결정하고, 결정된 분배 윈도우 및 수신 장치의 고유 식별자에 기초하여 DRM 서비스의 모니터링을 시작할 시간을 결정하도록 구성되는, 특징 (8)에 따른 수신 장치.

(10) DRM(Digital Rights Management) 관련 정보를 취득하기 위한 수신 장치의 방법으로서, 방송 스트림을 수신하는 단계; 방송 스트림으로부터, 방송 스트림 내의 복수의 서비스 각각에 대한 서비스 정보를 포함하는 SLT(Service List Table)를 추출하는 단계; 수신 장치의 처리 회로에 의해, 방송 스트림 내의 복수의 서비스에 대한 서비스 정보 내의 서비스 카테고리 정보에 기초하여, 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함하는지 여부를 결정하는 단계; 및 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함한다는 결정하는 단계의 결정에 기초하여, 수신 장치와 연관되고 DRM 서비스에서 전달되는 DRM 관련 정보를 취득하는 단계를 포함하는 방법.

(11) DRM 관련 정보를 취득하는 단계는 방송 스트림으로부터, DRM 서비스에 대해 서비스 정보에 포함되는 방송 시그널링 관련 정보에 기초하여 DRM 서비스와 연관되는 SLS(Service Layer Signaling)를 추출하는 단계; 및 추출된 SLS에 기초하여 방송 스트림의 LCT(Layered Coding Transport) 채널로부터 DRM 관련 정보를 취득하는 단계를 포함하는, 특징 (10)에 따른 방법.

(12) LCT 채널로부터 DRM 관련 정보를 취득하는 단계는 수신 장치의 고유 식별자의 미리 결정된 수의 최하위 비트들에 일치하는 TOI(Transport Object Indicator)와 연관되는 LCT 채널로부터의 DRM 관련 정보 파일을 취득하는 단계를 포함하는, 특징 (11)에 따른 방법.

(13) DRM 관련 정보를 취득하는 단계는 DRM 관련 정보 파일들과 함께 전달되는 헤더 필드들에 기초하여 방송 스트림의 LCT(Layered Coding Transport) 채널에서 전달되는 DRM 관련 정보 파일들을 필터링하는 단계; 및 필터링의 결과에 기초하여 DRM 관련 정보를 취득하는 단계를 포함하는, 특징들 (10) 내지 (12) 중 어느 하나에 따른 방법.

(14) DRM 서비스에 대한 서비스 정보가 DRM 시스템 식별 정보를 포함하고, 결정하는 단계는, 서비스 정보에 포함되는 서비스 카테고리 정보 및 DRM 시스템 식별 정보에 기초하여, 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함하는지 여부를 결정하는 단계를 포함하는, 특징들 (10) 내지 (13) 중 어느 하나에 따른 방법.

(15) DRM 시스템 식별 정보가 SLT 내의 DRM 서비스의 짧은 서비스 이름 및 글로벌 서비스 식별자로서 식별되는, 특징들 (10) 내지 (14) 중 어느 하나에 따른 방법.

(16) 복수의 서비스는 선형 A/V 서비스를 포함하고, 방법은 취득된 DRM 관련 정보를 사용하여, 선형 A/V 서비스, 또는 선형 A/V 서비스의 적어도 하나의 컴포넌트를 복호화하는 단계를 더 포함하는, 특징들 (10) 내지 (15) 중 어느 하나에 따른 방법.

(17) DRM 관련 정보는 수신 장치의 고유 식별자와 연관되는, 특징들 (10) 내지 (16) 중 어느 하나에 따른 방법.

(18) 방송 스트림에 포함되는 스케줄링 정보에 기초하여 DRM 서비스에 대한 분배 윈도우를 결정하는 단계, 및 결정된 분배 윈도우 및 수신 장치의 고유 식별자에 기초하여 DRM 서비스의 모니터링을 시작할 시간을 결정하는 단계를 더 포함하는, 특징 (17)에 따른 방법.

(19) 컴퓨터에 의해 실행될 때 컴퓨터가 DRM(Digital Rights Management) 관련 정보를 취득하기 위한 수신 장치의 방법을 수행하도록 야기하는 명령어들을 저장하는 비-일시적 컴퓨터 판독가능 매체로서, 방법은 방송 스트림을 수신하는 단계; 방송 스트림으로부터, 방송 스트림 내의 복수의 서비스 각각에 대한 서비스 정보를 포함하는 SLT(Service List Table)를 추출하는 단계; 방송 스트림 내의 복수의 서비스에 대한 서비스 정보의 서비스 카테고리 정보에 기초하여, 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함하는지 여부를 결정하는 단계; 및 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함한다는 결정하는 단계에서의 결정에 기초하여, 수신 장치와 연관되고 DRM 서비스에서 전달되는 DRM 관련 정보를 취득하는 단계를 포함하는 비-일시적 컴퓨터 판독가능 매체.

(20) DRM 관련 정보를 취득하는 단계는, 방송 스트림으로부터 DRM 서비스에 대해 서비스 정보에 포함되는 방송 시그널링 관련 정보에 기초하여 DRM 서비스와 연관되는 SLS(Service Layer Signaling)를 추출하는 단계; 및 추출된 SLS에 기초하여 방송 스트림에서 LCT(Layered Coding Transport) 채널로부터 DRM 관련 정보를 취득하는 단계를 포함하는, 특징 (19)에 따른 비-일시적 컴퓨터 판독가능 매체.

(21) LCT 채널로부터 DRM 관련 정보를 취득하는 단계가, 수신 장치의 고유 식별자의 미리 결정된 수의 최하위 비트들에 일치하는 TOI(Transport Object Indicator)와 연관되는 LCT 채널로부터의 DRM 관련 정보 파일을 취득하는 단계를 포함하는, 특징 (20)에 따른 비-일시적 컴퓨터 판독 가능 매체.

(22) DRM 관련 정보를 취득하는 단계가, DRM 관련 정보 파일들과 함께 전달되는 헤더 필드들에 기초하여 방송 스트림의 LCT(Layered Coding Transport) 채널에서 전달되는 DRM 관련 정보 파일들을 필터링하는 단계; 및 필터링의 결과에 기초하여 DRM 관련 정보를 취득하는 단계를 포함하는, 특징들 (19) 내지 (21) 중 어느 하나에 따른 비-일시적 컴퓨터 판독 가능 매체.

(23) DRM 서비스에 대한 서비스 정보를 DRM 시스템 식별 정보를 포함하고, 결정하는 단계는 서비스 정보에 포함되는 서비스 카테고리 정보 및 DRM 시스템 식별 정보에 기초하여, 방송 스트림이 수신 장치에 의해 지원되는 DRM 서비스를 포함하는지 여부를 결정하는 단계를 포함하는, 특징들 (19) 내지 (22) 중 어느 하나에 따른 비-일시적 컴퓨터 판독 가능 매체.

(24) DRM 시스템 식별 정보가 SLT 내의 DRM 서비스의 짧은 서비스 이름 또는 글로벌 서비스 식별자로서 식별되는, 특징들 (19) 내지 (23) 중 어느 하나에 따른 비-일시적 컴퓨터 판독 가능 매체.

(25) 복수의 서비스는 선형 A/V 서비스를 포함하고, 방법은 취득된 DRM 관련 정보를 사용하여 선형 A/V 서비스 또는 선형 A/V 서비스의 적어도 하나의 컴포넌트를 복호화하는 단계를 포함하는, 특징들 (19) 내지 (24) 중 어느 하나에 따른 비-일시적 컴퓨터 판독 가능 매체.

(26) DRM 관련 정보는 수신 장치의 고유 식별자와 연관되는, 특징들 (19) 내지 (25) 중 어느 하나에 따른 비-일시적 컴퓨터 판독 가능 매체.

(27) 방송 스트림에 포함되는 스키줄링 정보에 기초하여 DRM 서비스에 대한 분배 윈도우를 결정하는 단계, 및 결정된 분배 윈도우 및 수신 장치의 고유 식별자에 기초하여 DRM 서비스의 모니터링을 시작할 시간을 결정하는 단계를 더 포함하는, 특징들 (26)에 따른 비-일시적 컴퓨터 판독 가능 매체.

(28) 방송 스트림에서 전송될 복수의 서비스 각각에 대한 서비스 정보를 포함하는 SLT(Service List Table)를 생성하고, 서비스 정보 각각은 복수의 서비스 각각에 대한 카테고리 정보를 포함하고; 전송을 위해 SLT 및 복수의 서비스를 포함하는 방송 스트림을 생성하고; 방송 스트림 내의 복수의 서비스 중 DRM 서비스의 DRM 관련 정보를 전달하도록 구성되는 처리 회로를 포함하고, DRM 서비스에 대한 SLT에 포함되는 서비스 카테고리 정보는 DRM Service인 서비스 분배 시스템.

Claims

수신 장치에 있어서,
서비스 리스트 테이블(Service List Table)(SLT) 및 디지털 권한 관리(Digital Rights Management)(DRM) 데이터 서비스를 포함하는 방송 스트림을 수신하도록 구성되는 수신기 회로 - 상기 SLT는 상기 DRM 데이터 서비스에 대한 서비스 정보를 포함함 -; 및
처리 회로를 포함하고, 상기 처리 회로는,
상기 수신된 방송 스트림에 포함되는 상기 SLT로부터 상기 DRM 데이터 서비스에 대한 서비스 정보를 추출하고 - 상기 DRM 데이터 서비스에 대한 서비스 정보는 DRM 시스템 식별자를 포함함 -,
상기 SLT로부터 추출된, 상기 DRM 데이터 서비스에 대한 서비스 정보에 포함되는 상기 DRM 시스템 식별자가 상기 수신 장치에 의해 지원되는 DRM 시스템에 대응하고 상기 수신 장치의 사용자에 관한 하나 이상의 조건이 만족된다고 결정되면, 상기 DRM 데이터 서비스로부터 DRM 정보를 취득하도록
구성되는, 수신 장치.
제1항에 있어서,
상기 처리 회로는,
상기 DRM 데이터 서비스가, 상기 서비스 정보에 포함되는 서비스 카테고리 정보에 기초하여, 상기 방송 스트림에 포함된다고 결정하고,
상기 DRM 데이터 서비스가 상기 방송 스트림에 포함된다고 결정되고 상기 DRM 데이터 서비스에 대한 서비스 정보에 포함되는 상기 DRM 시스템 식별자가 상기 수신 장치에 의해 지원되는 상기 DRM 시스템에 대응하면, 상기 DRM 데이터 서비스로부터 상기 DRM 정보를 취득하도록
구성되는, 수신 장치.
제1항에 있어서,
상기 처리 회로는,
상기 방송 스트림으로부터, 상기 DRM 데이터 서비스에 대해 상기 서비스 정보에 포함되는 방송 시그널링 관련 정보에 기초하여 상기 DRM 데이터 서비스와 연관된 서비스 계층 시그널링(Service Layer Signaling)(SLS)을 추출하고;
상기 추출된 SLS에 기초하여 상기 방송 스트림 내의 계층화된 코딩 전송(Layered Coding Transport)(LCT) 채널로부터 상기 DRM 정보를 취득하도록
구성되는, 수신 장치.
제3항에 있어서,
상기 처리 회로는,
상기 수신 장치의 고유 식별자의 미리 결정된 수의 최하위 비트들에 일치하는 TOI(Transport Object Indicator)와 연관되는 상기 LCT 채널로부터의 DRM 정보 파일을 취득하도록
구성되는, 수신 장치.
제1항에 있어서,
상기 처리 회로는,
DRM 정보 파일들과 함께 전달되는 헤더 필드들에 기초하여 상기 방송 스트림의 LCT(Layered Coding Transport) 채널에서 전달되는 복수의 DRM 정보 파일들 중 하나를 취득하도록
구성되는, 수신 장치.
제1항에 있어서,
상기 DRM 시스템 식별자는 상기 DRM 시스템의 UUID(Universally Unique Identifier)를 나타내는, 수신 장치.
제1항에 있어서,
상기 방송 스트림은 선형 A/V 서비스를 포함하고,
상기 처리 회로는, 상기 취득된 DRM 정보를 사용하여, 상기 선형 A/V 서비스의 적어도 하나의 컴포넌트를 처리하도록 구성되는, 수신 장치.
제1항에 있어서,
상기 DRM 정보는 상기 수신 장치의 고유 식별자와 연관되는, 수신 장치.
디스플레이; 및
제1항에 따른 수신 장치
를 포함하는, 텔레비전.
DRM(Digital Rights Management) 정보를 취득하기 위한 수신 장치의 방법으로서,
SLT(Service List Table) 및 DRM 데이터 서비스를 포함하는 방송 스트림을 수신하는 단계 - 상기 SLT는 상기 DRM 데이터 서비스에 대한 서비스 정보를 포함함 -;
상기 수신 장치의 처리 회로에 의해, 상기 수신된 방송 스트림에 포함되는 상기 SLT로부터 상기 DRM 데이터 서비스에 대한 서비스 정보를 추출하는 단계 - 상기 DRM 데이터 서비스에 대한 서비스 정보는 DRM 시스템 식별자를 포함함 -; 및
상기 처리 회로에 의해, 상기 SLT로부터 추출된, 상기 DRM 데이터 서비스에 대한 서비스 정보에 포함되는 상기 DRM 시스템 식별자가 상기 수신 장치에 의해 지원되는 DRM 시스템에 대응하고 상기 수신 장치의 사용자에 관한 하나 이상의 조건이 만족된다고 결정되면, 상기 DRM 데이터 서비스로부터 DRM 정보를 취득하는 단계
를 포함하는, 방법.
제10항에 있어서,
상기 DRM 데이터 서비스가, 상기 서비스 정보에 포함되는 서비스 카테고리 정보에 기초하여, 상기 방송 스트림에 포함된다고 결정하는 단계를 추가로 포함하고,
상기 취득하는 단계는, 상기 DRM 데이터 서비스가 상기 방송 스트림에 포함된다고 결정되고 상기 DRM 데이터 서비스에 대한 서비스 정보에 포함되는 상기 DRM 시스템 식별자가 상기 수신 장치에 의해 지원되는 상기 DRM 시스템에 대응하면, 상기 DRM 데이터 서비스로부터 상기 DRM 정보를 취득하는 단계
를 포함하는, 방법.
제10항에 있어서,
상기 취득하는 단계는:
상기 방송 스트림으로부터, 상기 DRM 데이터 서비스에 대해 상기 서비스 정보에 포함되는 방송 시그널링 관련 정보에 기초하여 상기 DRM 데이터 서비스와 연관된 SLS(Service Layer Signaling)를 추출하는 단계; 및
상기 추출된 SLS에 기초하여 상기 방송 스트림 내의 LCT(Layered Coding Transport) 채널로부터 상기 DRM 정보를 취득하는 단계
를 포함하는, 방법.
제12항에 있어서,
상기 취득하는 단계는:
상기 수신 장치의 고유 식별자의 미리 결정된 수의 최하위 비트들에 일치하는 TOI(Transport Object Indicator)와 연관되는 상기 LCT 채널로부터의 DRM 정보 파일을 취득하는 단계
를 포함하는, 방법.
제10항에 있어서,
상기 취득하는 단계는:
DRM 정보 파일들과 함께 전달되는 헤더 필드들에 기초하여 상기 방송 스트림의 LCT(Layered Coding Transport) 채널에서 전달되는 복수의 DRM 정보 파일들 중 하나를 취득하는 단계
를 포함하는, 방법.
제10항에 있어서,
상기 DRM 시스템 식별자는 상기 DRM 시스템의 UUID(Universally Unique Identifier)를 나타내는, 방법.
제10항에 있어서,
상기 방송 스트림은 선형 A/V 서비스를 포함하고,
상기 방법은, 상기 취득된 DRM 정보를 사용하여, 상기 선형 A/V 서비스의 적어도 하나의 컴포넌트를 처리하는 단계를 추가로 포함하는, 방법.
제10항에 있어서,
상기 DRM 정보는 상기 수신 장치의 고유 식별자와 연관되는, 방법.
컴퓨터에 의해 실행될 때 상기 컴퓨터가 DRM(Digital Rights Management)을 취득하기 위한 수신 장치의 방법을 수행하도록 야기하는 명령어들을 저장하는 비-일시적 컴퓨터 판독가능 매체로서,
상기 방법은:
SLT(Service List Table) 및 DRM 데이터 서비스를 포함하는 방송 스트림을 수신하는 단계 - 상기 SLT는 상기 DRM 데이터 서비스에 대한 서비스 정보를 포함함 -;
상기 수신된 방송 스트림에 포함되는 상기 SLT로부터 상기 DRM 데이터 서비스에 대한 서비스 정보를 추출하는 단계 - 상기 DRM 데이터 서비스에 대한 서비스 정보는 DRM 시스템 식별자를 포함함 -; 및
상기 SLT로부터 추출된, 상기 DRM 데이터 서비스에 대한 서비스 정보에 포함되는 상기 DRM 시스템 식별자가 상기 수신 장치에 의해 지원되는 DRM 시스템에 대응하고 상기 수신 장치의 사용자에 관한 하나 이상의 조건이 만족된다고 결정되면, 상기 DRM 데이터 서비스로부터 DRM 정보를 취득하는 단계
를 포함하는, 비-일시적 컴퓨터 판독가능 매체.
제1항에 있어서,
상기 DRM 데이터 서비스에 대한 서비스 정보는 서비스 식별자, 주요 채널 번호, 부 채널 번호 및 서비스 카테고리 정보를 포함하는, 수신 장치.
삭제