KR20080031736A

KR20080031736A - 보안 콘텐츠를 위한 정책 업데이트 전달 방법

Info

Publication number: KR20080031736A
Application number: KR1020087000805A
Authority: KR
Inventors: 에두아르도 피. 올리베이라; 제임스 엠. 알코브; 앤더스 이. 클레메츠
Original assignee: 마이크로소프트 코포레이션
Priority date: 2005-07-12
Filing date: 2006-07-11
Publication date: 2008-04-10
Also published as: EP1902538A2; CN101218778A; JP2009501393A; CN101218778B; JP4851519B2; US7561696B2; RU2417532C2; EP1902538B1; MX2008000521A; US20070014413A1; KR101238477B1; EP1902538A4; WO2007008912A3; WO2007008912A2; RU2008101456A; BRPI0612713A2

Abstract

다양한 실시예에 있어서, 보안 콘텐츠의 주어진 단편을 위해 DRM(디지털 저작권 관리)정책 업데이트들과 같은 정책 업데이트들을 전송하거나 업데이트하는 것이 가능하다. 적어도 몇몇 실시예에 있어서는, 다양한 프로토콜들이 확장되어 정책 업데이트들을 표현하고 전송한다. 일 실시예에 있어서는, HTTP(Hyper Transport Protocol)가 정책 업데이트들을 전송하기 위해서 이용된다. 다른 실시예에서는, RTSP(Real Time Streaming Protocol)가 정책 업데이트 전송에 이용된다.

정책 업데이트(Policy updates), HTTP, RTSP

Description

보안 콘텐츠를 위한 정책 업데이트 전달 방법{DELIVERING POLICY UPDATES FOR PROTECTED CONTENT}

DRM(디지털 저작권 관리, Digital Rights Management)는 전자 기구 내의 디지털 미디어 콘텐츠의 사용을 제어 또는 제한하는 것과 같이 콘텐츠를 보호하는데 사용하는 기술을 지칭한다. DRM의 특징 중 하나는 미디어 콘텐츠를 주어진 기기나 장치 내로 제한할 수 있다는 것이다. 그러므로 콘텐츠의 특정 부분에 부속되고 그 콘텐츠와 연관된 권리와 제한을 정의하는 면허(license)는 통상 그 주어진 기기 또는 장치에 한한다. 그 결과, 사용자가 그 콘텐츠를 재생하기 위해 그 콘텐츠를 제거해서 다른 기기로 옮기는 것은 통상적으로 불가능하다.

DRM에 의해 보호되는 콘텐츠의 다른 특징으로는, ASF 파일과 같은 콘텐츠가 전체 파일에 적용되는 권리와 제한, 다시 말하면 한 정책을 오직 한 종류만 허용한다는 것이다. 예를 들면, 어떤 비디오 파일이 재생될 때 마이크로비전(microvision)이 아날로그 비디오로 출력되기 위해서 마이크로비전이 전체 파일에 대해서 필요하거나 또는 전혀 필요하지 않을 수 있다. 이러한 특정 종류의 파일들에 있어, 파일 중간 또는 스트림(stream) 도중에 그 콘텐츠와 관계된 정책을 바꿀 수 없다.

도 1은 본 발명의 일 실시예에 따른 프로토콜의 예시적인 등록 과정이다.

도 2는 본 발명의 일 실시예에 따른 프로토콜의 예시적인 근접 발견 과정이다.

도 3은 본 발명의 일 실시예에 따른 프로토콜의 예시적인 세션 설정 과정이다.

도 4는 본 발명의 일 실시예에 따른 프로토콜의 예시적인 데이터 전송 과정이다.

도 5는 본 발명의 일 실시예에 따른 스트리밍(streaming) 프로토콜의 양상이다.

도 6은 본 발명의 일 실시예에 따른 루트(root) 면허과 리프(leaf) 면허와 관련 있는 양상이다.

도 7은 본 발명의 일 실시예에 따른 방법의 각 단계들을 기술하는 논리 흐름도이다.

도 8은 본 발명의 일 실시예에 따른 루트(root) 면허와 리프(leaf) 면허의 통신를 도시한다.

도 9는 본 발명의 일 실시예에 따른 루트(root) 면허과 리프(leaf) 면허의 통신을 도시한다.

개요

이어서, "콘텐츠 보안과 면허 교환 프로토콜" 섹션이 제공되고, 진보된 기술이 채용될 수 있는 특정 시스템을 설명한다. 이에 이어, "RTSP" 섹션은 RSTP 환경 내에서의 진보된 기술을 이해할 수 있도록, 적어도 어느 정도의 내용을 RSTP에 익 숙하지 않은 독자에게 주는 "RTSP" 섹션이 제공된다.

이어서, "업데이트된 정책의 전송을 위한 연결 면허" 섹션이 제공되고, 면허 연결(chaining)이라는 개념과 진보된 환경(inventive context) 내에서의 연결된 면허가 어떻게 이용될 수 있는지 설명한다. 다음의 "HTTP를 이용한 업데이트된 정책의 전송" 섹션은 정책 업데이트들을 전송하기 위해 HTTP 환경(context) 내에서의 연결된 면허가 어떻게 이용되는 지를 설명한다. 다음으로 "루트(root)와 리프(Leaf) 면허를 전송을 위한 RTSP 이용" 섹션이 제공되고, 정책 업데이트들을 전송하기 위해 RTSP 환경(context) 내에서의 연결된 면허가 어떻게 이용되는 지를 설명한다.

콘텐츠 보안과 면허 전달 프로토콜

이하에서는, 디지털 링크를 통해 전송되는 콘텐츠 면허에 대한 보안 및 전송을 제공하는 예시적인 프로토콜에 대하여 논의할 것이다. 이 프로토콜은 다양한 기술들이 채용될 수 있는 예시적인 하나의 프로토콜을 구성하는 것이다. 특허받고자 하는 사상과 범주를 벗어나지 않고도, 다른 프로토콜들도 이용 가능하다는 것은 인정되고 이해될 수 있다.

아래의 기호는 다음과 같이 사용된다.

K {data} : 데이터는 비밀키 K에 의해서 암호화된다.

K [data] : 데이터는 비밀키 K에 의해서 서명된다.

{data}_Device : 데이터는 기기의 공용키에 의해서 암호화된다.

[data]_Device : 데이터는 기기의 개인키에 의해서 서명된다.

이 특별한 프로토콜에는 등록, 재확인, 근접 발견, 세션 설정, 그리고 데이터 전송이라는 5개의 주요 단계가 있다.

등록 절차에서는 송신기(예를 들어, 다른 기기로 전송될 콘텐츠가 있는 기기)가 의도하는 수신기(예를 들어, 콘텐츠 수신 예정인 기기)를 독특하고 안전하게 식별할 수 있다. 이러한 특정한 프로토콜에서, 송신기는 등록된 수신기에 대한 데이터베이스를 유지하여 적은 수의 미리 결정된 수신기만이 동시에 이용되도록 한다. 보안 콘텐츠의 광범위한 배포를 막기 위해서 등록 과정 동안 송신기는 근접 발견 과정을 이용해서 수신기가 네트워크상의 송신기 "가까이"에 위치해 있는 지를 확인한다.

재확인 과정은 수신기가 계속해서 송신기 근처에 있는 지를 확인하기 위해서 이용된다. 수신기가 등록되어 있지 않거나 과거의 예정된 기간 내에 재확인되지 않는 한 콘텐츠는 수신기에게 전송되지 않는다.

세션 설정 과정은 수신기들이 송신기로부터 콘텐츠를 요청(Request)할 때마다 이용된다. 송신기는 세션 평가 완료 전에 기기들이 등록하고 식별한다.

세션 설정 완료시, 요청(Request)된 콘텐츠의 데이터 전송이 안정적으로 이루어진다. 수신기는 동일 콘텐츠의 특정 부분을 검색하기 위해서 세션을 재사용할 수 있으나, 다른 콘텐츠의 검색을 위해서는 반드시 새로운 세션을 설정하여야 한다.

도 1 및 등록 과정 중 송신기와 수신기 간의 전송 메시지를 표시한 아래 표를 참고해서 등록 과정을 살펴본다.

메시지	값	설명
등록 요청(Request) 메시지	Ver	8-비트 프로토콜 버전
	Cert	수신기의 XML 디지털 인증
	Did	128-비트 시리얼 넘버
등록 응답 메시지	Ver	8-비트 프로토콜 버전
	{seed}Device	콘텐츠 암호 키 및 콘텐츠 통합 키를 추출하는데 이용되는 128-비트 시드
	SN	128-비트 시리얼 넘버
	Address	송신기의 들어오고 나가는 근접 패킷 소켓의 어드레스
	SId	128-비트 랜덤 세션 아이디
근접 발견 알고리즘		근접 발견 알고리즘은 밴드 밖에서 실행된다.

여기서, 수신기는 다른 정보와 함께 수신기의 디지털 인증서를 포함하고 있는 등록 요청(Request) 메시지를 전송한다. 송신기는 등록 요청(Request) 메시지에 대한 응답을 하면서 수신기의 인증서를 확인하고, 시드(seed) 및 랜덤 세션 아이디를 생성하고, 위에 명시된 형식의 등록 응답 메시지를 수신기로 반송한다. 그러면 수신기는 송신기의 서명을 확인하고, 세션 아이디를 추출하고, 그리고 도면상의 다른 동작들을 수행한다. 그러고 나서 수신기와 송신기는 이하에 기술된 근접 발견 과정에 진입할 수 있다.

재확인 과정은, 수신기가 데이터베이스에 미리 등록되었다는 점에서만 다를 뿐, 위에서 기술한 동일 과정이 수행된다.

도 2과 연관해서 근접 발견 과정에 관한 이하의 내용들을 살펴본다.

인접 발견 과정 중 수신기는 송신기로 근접 발견 초기화 메시지에 명시된 대로 세션 아이디를 포함하는 메시지를 전송한다. 송신기는 수신기에게 난스(Nounce, 128-비트 랜덤 값)을 포함하는 메시지를 보내고, 수신기가 콘텐츠 암호 키를 이용하여 암호화된 난스(Nounce)로 응답하는데 걸리는 시간을 측정한다. 마지막으로, 송신기는 수신기로 근접 발견 성공 여부를 표시하는 메시지를 전송한다.

수신기는 근접 발견이 성공할 때까지 이 과정을 반복할 수 있다. 이러한 특정 프로토콜이 IP에 기반을 둔 네트워크에서 사용될 때, 근접 발견 메시지들은 UDP를 통해 교환된다. 수신기는 등록 응답 메시지를 통해서 송신기의 어드레스를 얻는다. 근접 발견 초기화 메시지를 전송하는 UDP 패킷(Packet)의 수신 IP 헤더(Header)를 살펴봄으로써 수신기의 어드레스가 결정될 수 있기 때문에 수신기의 어드레스는 독립적으로 전송될 필요가 없다.

이하 표는 근접 발견 과정에서 교환되는 메시지에 관한 것이다.

근접 발견:

메지시	값	설명
근접 시작 메시지	SId	수신기에 의해 전송된 동일한 128-비트 세션 아이디 값
근접 시도 메시지	Seq	8-비트의 증가하는 연쇄 번호
	SId	동일한 128-비트 세션 아이디
	Nounce	128-비트 세션 아이디
근접 응답 메시지	Seq	송신기에 의해 결정되는 동일한 일련 번호
	SId	동일한 128-비트 세션 아이디
	KC{Nounce}	콘텐츠 암호 키를 이용해 암호화된 128-비트 난스(Nounce)
근접 결과 메시지	SId	동일한 128-비트 세션 아이 디
근접 결과 메시지	Result	등록 절차의 성공 여부를 표 시하는 상태 코드

도 3과 세션 설정 동안 교환되는 메시지에 관한 아래의 표와 관련된 세션 설정에 관한 이하의 내용을 살펴본다.

세션 설정:

메시지	값	설명
면허 요청(Request) 메시지	Ver	8-비트 프로토콜 버전
	Cert	수진자의 XML 디지털 인증서
	SN	128-비트 시리얼 숫자
	Action	콘텐츠에 대한 사용 요청 예:재생, 복사
	Rld	128-비트 랜덤 권리 아이디
	VCRL	수신기의 CRL(인증서 폐기 목록,certificate revocation list)
면허 응답 메시지	Ver	8-비트 프로토콜 버전
	CRL	송신기의 CRL(인증서 폐 기 목록,certificate revocation list). 수신기의 CRL보다 높은 버전을 가지고 있고 수신기의 구성요소가 전송 능력을 가지고 있는 경우에만 전송된다.
	License	KC(수신기의 공용키로 암호화)	128-비트 랜덤 콘텐츠 암호 키
		KI(수신기의 공용키로 암호화)	128-비트 랜덤 콘텐츠 통합키
		VCRL	송신기의 CRL의 버전
		RId	수신기에 의해 보내진 동일한 128-비트 랜덤 권리 아이디
		SN	128-비트 시리얼 숫자

이 예에서, 면허 요청(Request) 메시지는 수신기로부터 송신기로 전송되고, 위에 기술된 정보를 포함한다. 응답시, 송신기는 위에 기술된 정보를 포함하는 면허 응답 메시지를 전송한다.

이 특정 예에서는, 면허는 XMR 형식으로 표현되며 콘텐츠 암호 키, 콘텐츠 통합키, 송신기의 CRL(인증서 폐기 목록, certificate revocation list) 메시지, 그리고 128-비트 시리얼 숫자를 포함한다. 면허는 또한 원키 메시지 인증 코드(OMAC)를 이용하는 콘텐츠 통합키를 이용해서 연산된 인증 코드(OMAC)를 포함한다.

도 4와 연관해서 데이터 전송 과정에 관한 이하의 내용을 살펴본다. 세션 설정이 이루어지면, 데이터 전송은 콘트롤 프로토콜의 특정 방법(in a control protocol specific manner)을 통해 이루어진다. 데이터 전송 요청(Request)과 응답은 모두 반드시 콘트롤 프로토콜과 콘텐츠 유형에 대해서 구체적으로 정의되어야 한다. 이는 도 4에 개념적으로 나타나 있다.

발명의 실시예가 이용되는 전형적인 프로토콜의 개괄을 위해서 RTSP에 대해서 살펴본다.

RTSP

RTSP(The Real Time Streaming Protocol, 실시간 스트리밍 프로토콜)은 당업자가 이해할 수 있듯이 실시간 특성이 있는 데이터 전송(예: 스트리밍)을 제어하는 어플리케이션 레벨의 프로토콜(Application-level Protocol)이다. RTSP은 오디오, 비디오와 같은 실시간 데이터의 제어 및 주문형 전송을 가능하게 하는 확장 가능한 프레임워크(framework)를 제공한다. 데이터의 소스(source)는 라이브 데이터 공급들(live data feeds)와 저장된 클립들(clips)을 포함한다. 이 프로토콜은 다중 데이터 전송 세션들을 제어하기 위한 것이며, UDP, Multicast UDP, 그리고 TCP와 같은 전송 채널을 이용할 수 있는 수단을 제공하며, 또한 RTP에 기반을 둔 전송 메커니즘을 이용할 수 있는 수단을 제공한다.

RTSP는 오디오와 비디오 같은 연속 미디어(continuous media)에 대한 단일 또는 다중 시간 동기화된 스트림(a single or several time-synchronized streams)을 설정 및 제어한다. 비록 제어 스트림(control stream)을 통해 연속하는 미디어 스트림(stream)의 인터리빙(interleaving)이 가능하지만, 통상적으로 RTSP는 연속 스트림(continuous streams) 자체를 전송하지 않는다. 즉, RTSP는 다중미디어 서버(multimedia server)를 위한 네트워크 원격 조절기(network remote control)와 같은 역할을 한다.

제어되어야 할 일련의 스트림들(set of streams)은 표현 기술(presentation description)에 의해서 정의된다. RTSP에서는 RTSP 연결이라는 개념이 없다. 그 대신, 서버는 식별기에 의해서 레이블(label)된 세션을 유지한다. RTSP 세션은 TCP와 같은 전송 수준(transportaion)의 연결에 묶여 있지 않다. RTSP 세션 중에, RTSP 클라이언트는 RTSP 요청(Request)를 하기 위해서 신뢰성 있는 서버와의 전송 연결들을 닫거나 열 수 있다. 대신에, 당업자가 이해할 수 있듯이, RTSP는 UDP와 같은 무선 전송 프로토콜을 사용할 수 있다.

RTSP에 의해서 제어되는 스트림(stream)은 RTP를 이용하지만, RTSP의 작동은 연속 미디어(continuous media)를 전송하기 위해 사용되는 메커니즘에 의존하지 않는다.

도 5와 연관하여 클라이언트/수신기 (500)과 서버/송신기 (502) 간의 전형적인 RTSP의 요청/응답(requests/responses)의 교환을 살펴본다.

RTSP 요청/응답은 예비적으로 헤더(headers)를 가지고 있다. 다만, 간결한 명세서를 위해서 본 명세서에서는 헤더의 설명을 생략한다. RTSP에서는 클라이언트/수신기 (500)가 소위 기술 요청(DESCRIBE request)을 발신한다. 한편, 기술 요청은 서버 (502)로부터의 요청 URL을 이용해서 식별되는 시연 또는 미디어 객체에 대한 기술을 찾아내기 위해 사용된다. 서버 502는 세션 기술 프로토콜(SDP, SESSION DESCRIPTION PROTOCOL)을 통해 표현되는, 요청된 리소스에 대한 기술(a description of the requested resource)을 포함하여 응답한다. 이러한 기술 응답(SDP, DESCRIBE response)은 그것이 기술하는 리소스(resource)를 위한 모든 미디어 초기화 정보를 포함한다.

이후에, 클라이언트 (500)은 스트림(stream)된 미디어를 위해 사용되는 전송 메커니즘을 특정하는 URI에 대한 셋업 요청(setup request)을 전송한다. 도 5의 예에서, 셋업 요청은 오디오와 비디오 모두를 위해서 보내진다. 또한 클라이언트 (500) (client (500))은 셋업 요청 중 클라이언트(500)가 이용할 전송 파라미터(parameter)를 표시한다. 셋업 요청의 전송 헤더(header)는 데이터의 전송을 위해서 클라이언트(client)에 적합하도록 전송 파라미터(parameter)를 특정한다. 서버 502(server 502)로부터의 응답은 서버에 의해 특정된 전송 파라미터(parameter) 를 포함한다. 서버는 또한 셋업 요청에 대한 답에 세션 식별자를 생성한다.

이때, 클라이언트는 셋업(SETUP)에서 특정되는 메커니즘을 통해 서버의 데이터 전송을 시작하게 하는 재생(PLAY) 요청을 발신할 수 있다. 이 예에서, 재생(PLAY) 요청에 응답하여 서버는 오디오/비디오 콘텐츠 스트리밍을 시작할 수 있다. 이 예에서는, 당업자가 이해할 수 있듯이, 스트리밍 콘텐츠는 RTP 패킷을 이용해서 엔켑슐레이트(encapsulate)된다.

RTSP 프로토콜에는 PAUSE, TEARDOWN, GET_PARAMETER, REDIRECT, 그리고 RECORD의 포함하는 특성을 지닌 다른 방법들도 있다. RTSP에 대한 보다 나은 이해를 위해서는 http://www.ietf.org/rfc/rfc2326.txt에서 찾을 수 있는 the RTSP RFC, Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998 을 참고할 수 있다.

업데이트된 정책의 전송을 위한 연결 면허

실시예에서 기술된 바와 같이, 연결 면허의 개념은 정책 업데이트 과정에서 이용된다. 이 특정 실시예에서, 루트(root) 면허과 리프(leaf) 면허의 개념이 이용된다. 여기서, 클라이언트/수신기가 콘텐츠 키를 이용한 연속 전송의 정책 업데이트들을 복호화하기 위해서, 콘텐츠키 셋업 및 클라이언트/수신기로의 전송에 루트(root) 면허가 이용된다. 초기 콘텐츠키가 안전하게 클라이언트/수신기에 보내지면, 서버/송신기가 초기 전송된 콘텐츠키를 이용해서 연속 콘텐츠키를 암호화시키고, 이를 클라이언트/수신기에 보낼 수 있다. 초기에 전송된 콘텐츠 키를 이용 해서 클라이언트(client)는 연관된 정책 업데이트들을 복호화할 수 있다.

도 6과 연관해서 이러한 특정 방식(scheme)의 구동 방식이 어떻게 구현될 수 있는 지에 대한 예를 제공하기 위해 이하의 내용을 살펴본다. 이 특정한 실시예에서 도 6의 시스템은 공용 키 암호화 구동을 위한 1024-비트 RSA 키들과 대칭 암호화(symmetric cryptographic operations)을 위한 128-비트 AES 키들을 이용할 수 있도록 설정된다. 물론 이것은 하나의 실시예이며 청구항의 범위를 제한하는 것이 아니다.

이 실시예에서 클라이언트/수신기 (600)은 공용/개인 키 (650)을 가지고 있고 서버/송신기 (602)는 클라이언트/수신기의 공용키를 가지고 있다. 당 실시예에서 클라이언트/수신기의 공용키와 개인키는 각각 1024-비트 RSA키이다. 서버/송신기는 클라이언트/수신기의 공용키를 이용하면서 클라이언트/수신기의 공용키로 암호화된 초기의 콘텐츠키를 포함하는 루트 면허를 설정한다. 그 초기의 콘텐츠키는 128-비트 AES 콘텐츠키이다. 이 루트(root) 면허는 클라이언트/수신기로 전송된다. 암호화된 콘텐츠기가 {콘텐츠키1}CLIENT로 표현되고 있다. 클라이언트/수신기와 서버/송신기 간에 최초의 송수신이 도 6에 나타나 있고, 여기서 기술된 송수신이 발생하기 이전에 다른 송수신이 인식될 수 있다.

서버/송신기로부터 암호화된 키를 받으면서 클라이언트/수신기는 개인키를 이용해서 콘텐츠키를 복호화하고 이후의 이용을 위해서 복호화한 콘텐츠키를 안전하게 저장할 수 있다. 이하 발명의 상세한 설명에서, 최초의 콘텐츠키는 초기 콘텐츠키라고 일컫는다.

이제, 무엇이 일어나는지 살펴본다. 서버/송신기는 차후의 암호화 동작의 토대로서 역할을 하는 클라이언트/수신기에 키를 안전하게 전송한다. 보다 구체적으로, DRM으로 보호되는 콘텐츠의 특정 부분과 관련된 정책 업데이트가 스트리밍 중에 이루어지 것을 살펴본다. 이 경우, 서버/송신기는 업데이트된 정책을 포함하는 리프(leaf) 면허를 준비할 수 있다. 이러한 리프(leaf) 면허는 정책 업데이트 및 암호화된 버전의 콘텐츠키₂(content key₂)를 포함한다. 당 실시예에서는 콘텐츠키₂(content key₂)는 초기 콘텐츠키를 이용하여 암호화된 128-비트 AES 콘텐츠키이다. 기존의 클라이언트/수신기는 오직 128-비트 AES 콘텐츠키(예를 들어 초기 콘텐츠키)만을 이용한 암호화를 필요로 하므로, 기존의 클라이언트/수신기에 비해 1024-비트 RSA키 구동과 관련하여 클라이언트/수신기가 부담하는 계산의 복잡성과 비용이 줄어든다.

면허 및 면허 업데이트 표현을 위한 XMR 실시예를 이하에서 살펴본다.

면허 연결을 이용하는 목적 중 하나는 면허 업데이트 도중 작동되는 비대칭 키 동작의 수를 줄이는 것이다. 이러한 실시예에서는 권리와 제한을 전송하는 메커니즘으로서 루트(root) 면허 이용은 중요하지 않다. 그 결과 루트(root) 면허가 어떠한 권리들과 제한들을 전송하지 않으므로 루트(root) 면허는 매우 단순하다. 하지만, 적어도 몇몇의 실시들 중에서는, 루트(root) 면허가 권리와 제한을 수반하여 전송될 수 있는 것으로 인식될 수 있다.

이 실시예에서는, 업링크 KID 객체(Uplink KID Object)를 통해서 리프(leaf) 면허는 루트(root) 면허에 연결된다. 다음은 실시예에 따른 면허들에 존재하는 객체에 관한 것이다.

루트(root) 면허과 관련해서 다음은 재생(Playback)을 위한 루트(root) 면허에 존재하는 XMR 객체 셋(set)에 관한 것이다.

재생 정책 콘테이너 객체(Playback Policy Container Object)는 재생(Playback)이 이루어지기 위해서 반드시 존재해야 한다. 반면, 복사 동작(Copy Action)을 위한 루트(root) 면허는 재생 정책 콘테이너 객체(Playback Policy Container Object) 대신에 저작권 콘테이너 객체(Copy Right Container Object)를 포함하고 있어야만 한다.

이하는 복사를 위한 루트(root) 면허에 존재하는 XMR 객체 셋(set)이다.

이 실시예에서는 저작권 콘테이너 객체(Copy Right Container Object)는 복사(Copy)가 허용되기 위해서 반드시 존재해야 한다. 재생(Playback)에 대한 권리가 서명되었기 때문에 재생 정책 콘테이너 객체(Playback Policy Container Object)가 여전히 존재한다는 것을 주의하여야 한다.

특정 실시예에서의 리프(leaf) 면허와 관련해서 다음을 살펴본다. 리프(leaf) 면허는 XMR을 통해서 표현될 수 있는 모든 종류의 권리 또는 제한을 포함 할 수 있다. 연결된 리프(leaf) 면허가 연결되지 않은 리프(leaf) 면허와 다른 주된 점은 콘텐츠키의 암호화를 위한 대칭키의 이용과 업링크 KID 객체(Uplink KID Object)를 통한 다른 면허과의 연결에 있다.

재생(Playback)을 위한 리프(leaf) 면허의 예로 다음을 살펴본다.

콘텐츠키 객체(Content Key Object)는 반드시 0x0002(연결된 면허, Chained License)에 맞춰진 키 암호 타입(Key Encryption Cipher Type)과 0x001(AES CTR)에 맞춰진 대칭 암호 타입(Symmetric Cipher Type)을 포함하고 있어야 한다. 업링크 KID(Uplink KID)는 루트(root)의 KID에 맞춰진 업링크 KID 필드(Uplink KID field)를 포함하고 있어야 한다.

다음은 특정한 실시예에서의 복사(copy)를 위한 리프(leaf) 면허의 예이다.

이 실시예에서는 복사(Copy)가 작동하기 위해서는 반드시 저작권 콘테이너 객체(Copy Right Container Object)가 존재해야 한다. 허용 복사 수에 대해서 제한이 있다면 복사 수 제한 객체(Copy Count Restriction Object)가 존재한다. 복사(Copy) 대상 시스템에 제한이 있다면 복사 보호 수준 제한 객체(Copy Protection Level Restriction Object)가 존재한다. 재생(Playback)에 대한 권리는 항상 서명되어야 하기 때문에 재생 정책 콘테이너 객체(Playback Policy Container Object)는 항상 존재하여야 한다는 것을 주의해야 한다.

도 7은 실시예에 따른 방법의 단계를 기술한 논리 흐름도(flow diagram)이다. 당해 방법은 적절한 하드웨어, 소프트웨어, 펌웨어 또는 그것들의 조합과 연결되어서 이루어진다. 일 실시예에서 당해 방법은 위에서 기술되고 도시된 시스템과 연결되어 구현된다. 덧붙여, 이하에서는 서버/송신기와 클라이언트/수신기에 의해서 작동되는 각각의 몇몇 동작들이 기술된다. 서버/송신기와 클라이언트/수신기에 관한 예는 이미 기술한 바 있다.

Step (700)은 클라이언트/수신기의 공용키를 이용해서 초기 콘텐츠키를 암호화한다. 위에서 주어진 하나의 예에서 적절한 콘텐츠키가 함께 이용될 수 있다. Step (702)는 암호화된 초기 콘텐츠키를 포함하는 루트(root) 면허를 클라이언트/수신기에 전송한다. 이 단계의 수행을 위해서 모든 적절한 방법이 이용될 수 있다. 이하에서는 두 가지 다른 프로토콜을 기반으로 하는 두 개의 특정한 예를 다룬다. 이들은 실시예를 구성할 뿐이며, 특허받고자 하는 범위를 여기서 설명할 의 도가 아니라는 것이 인정되고 인식할 수 있다.

Step (704)는 서버/송신기에 의해서 전송된 루트(root) 면허를 받고 Step (706)는 암호화된 초기 콘텐츠키를 복호화한다. 이 실시예에서, 이 단계는 암호화된 초기 콘텐츠키를 복호화하기 위해서 클라이언트/수신기의 개인키를 이용해서 이루어진다.

Step (708)은 리프(leaf) 면허를 준비하고 초기 콘텐츠키를 이용해서 새로운 콘텐츠키를 암호화한다. Step (710)은 리프(leaf) 면허를 클라이언트/수신기에 전송한다. 리프 면허는 DRM으로 보호되는 콘텐츠를 위해서 정책 및 정책 업데이트들을 포함할 수 있고, 실제로 통상적으로 포함하고 있다는 것을 상기해야 한다. Step (708)와 Step (710)이 DRM으로 보호되는 일정 부분의 콘텐츠에 대해서 여러 번 이루어질 수 있다는 것을 이해할 수 있을 것이다. 즉, DRM으로 보호되는 일정 부분의 콘텐츠에 대해서 정책이 바뀔 때, 해당 리프(leaf) 면허가 준비되어 클라이언트/수신기로 보내진다.

Step (712)는 리프(leaf) 면허를 수신하고 Step (714)는 이전에 수신한 초기 콘텐츠키를 이용해서 새로운 콘텐츠키를 암호화한다. 이후 Step (716)은 콘텐츠를 암호화하고 리프(leaf) 면허에 포함되어 있는 정책을 업데이트하기 위해서 암호화된 새로운 콘텐츠키를 이용한다.

클라이언트/수신기에 의해 수신된 각각의 새로운 리프(leaf) 면허에 대해서 Step (712), Step (714), Step (716)이 이루어진다는 것을 이해할 수 있을 것이다.

HTTP 를 이용한 업데이트된 정책의 전송

루트(root) 면허 및 리프(leaf) 면허의 개념과 앞서 기술한 환경(context) 하에서의 활용 방법에 대해서 위에서 살펴보았으므로, HTTP를 활용한 루트(root) 면허와 리프(leaf) 면허의 전송 방식을 살펴본다.

DRM으로 보호되는 콘텐츠의 전송을 위해 HTTP가 이용될 때, 클라이언트(client)는 서버/송신기에 2개의 요청(Request)를 발신한다. 첫 번째로, 클라이언트는 루트(root) 면허를 추출하는 POST 요청(Request)를 발신한다. 두 번째로, 클라이언트는 DRM으로 보호되는 콘텐츠를 추출하는 GET 요청(Request)를 발신한다. HTTP에서 서버는 통상 클라이언트와의 송수신을 초기화할 수 없기 때문에 당 실시예에서는 클라이언트가 이 요청들(Requests)을 발신한다.

도 8와 연관해서 보다 구체적으로 살펴본다. 클라이언트가 루트(root) 면허를 받으려할 때, 클라이언트는 서버에 POST 요청(Request)을 발신한다. POST 요청은 위에서 살펴본 바와 같이 면허 요청 메시지(license request message)를 포함하고 있다. 이 송수신을 받으면 서버는 일 이상의 실시예에서 XMR으로 표현된 루트(root) 면허를 포함하는 면허 응답 메시지로 응답한다. 루트(root) 면허를 받고 그에 따라 처리하면서 클라이언트는 DRM으로 보호되는 콘텐츠를 요청하기 위해 Get 요청(Request)을 서버에 발신한다. 서버의 GET 요청에 응답하여, 서버는 하나 이상의 면허 응답 메시지로 인터리브(interleave)된 요청 콘텐츠의 조각들로 응답을 하며, 면허 응답 메시지는 DRM으로 보호되는 콘텐츠의 특정 부분과 관계되는 리프(leaf) 면허를 각각 포함하고 있다. 모든 적절한 메커니즘과 인터리 빙(interleaving) 기술이 서버 응답을 구성하는데 이용될 수 있다.

특정 환경(context)에서 일 실시예에 따라 다음을 살펴본다.

당 실시예에서 4-바이트 프레이밍 헤더(framing header)는 데이터를 엔켑슐레이트(encapsulate)하거나 블록(block)을 제어하기 위해서 이용된다. 프레이밍 헤더는 네트워크 바이트 순서로 1-바이트 ASCⅡ dollar sign(0x24), 1-바이트 블록 타입 식별자(block type identifier), 그리고 2-바이트 길이의 엔켑슐레이트된 데이터(encapsulated date)를 차례로 포함한다.

섹션(Sections)	필드(Fields)
헤더(Header)	8-비트 ASCⅡ dollar sign(0x24)
헤더(Header)	8-비트 블록 타입(block type)
데이터 길이	16-비트 엔켑슐레이트된(encapsulated) 데이터

콘트롤 블록(Control Block)은 ASCⅡ 'c' 문자(0x63)을 타입 식별자로 이용한다. 이 블록은 통상 면허 응답 메시지를 포함한다.

데이터 블록(Date Block)은 ASCⅡ 'd' 문자(0x63)를 타입 식별자로 이용한다. 이 블록은 미디어 데이터 앞에 위치하는 데이터 세그먼트 기술자(Data segment descriptor)를 포함한다.

데이터 세그먼트 기술자(Data segment descriptor)는 암호화되거나 되지 않은 콘텐츠와 연관된다. 기술자(descriptor) 안의 암호화된 플래그(flag)는 이 정보를 전송한다. 데이터 세그먼트 기술자(Data segment descriptor)가 암호화될 경우 데이터 세그먼트 기술자(Data segment descriptor)는 하나의 정책과 콘텐츠 암호키와 관련 있는 이미 전송된 파일의 일부분과 연관이 있다. 다시 말해, 콘텐츠 암호키와 정책은 세그먼트(segment) 내에서는 변화될 수 없다.

실시예와 관련해서, 전형적인 링크 암호를 이용한 HTTP 응답은 다음의 블록(block)들로 이루어져 있다.

1. 연결된 면허를 이용한 면허 응답 메시지를 전송하는 콘트롤 블록(control block) [＄c]

2. 하나 이상의 데이터 블록들(data blocks) [＄d]

파일 전송 중 키 또는 정책의 변화가 있는 경우 다음 단계가 추가된다.

3. 새로운 연결된 면허를 이용한 면허 응답 메시지를 전송하는 새로운

콘트롤 블록(control block) [＄c]

4. 하나 이상의 데이터 블록들(data blocks) [＄d]

3,4 단계는 키가 복수 개이거나 정책 변화가 있는 경우에만 복수 번 발생한다는 것에 주의하여야 한다.

루트( root )와 리프 ( leaf ) 면허를 전송하기 위한 RTSP 이용

루트(root) 면허와 리프(leaf) 면허의 개념과 HTTP를 이용한 이용 방법에 대해서 살펴보았으므로, 이제는 RTSP를 이용한 루트(root) 면허와 리프(leaf) 면허의 전송 방법에 대해서 살펴본다.

RTSP와 HTTP 간의 차이점은 RTSP가 HTTP에 비해서 확연하게 더 복잡하다는 것이다. 구체적으로, RTSP는 서버에 의해 초기화되는 요청(server-initiated request)에 대한 규약이 있으며, 이는 서버가 언제든지 클라이언트(client)에게 명령을 전송할 수 있도록 한다. 도 9와 연관해서 이러한 실시예를 살펴본다.

클라이언트/수신기가 DRM으로 보호되는 콘텐츠를 실행하려고 할 때, 클라이언트는 면허 요청 메시지를 포함하는 기술 요청(DESCRIBE request)을 전송한다. 이 메시지에 응하여, 서버는 면허 응답 메시지를 임베드(embed)하고 있는 SDP(Session Description Protocol)으로 응답한다. 당 실시예에서는 면허 응답 메시지는 XMR로 표현되는 루트(root) 면허를 포함한다.

이제 클라이언트(client)가 DRM으로 보호되는 콘텐츠를 수신하려고 할 때, 클라이언트는 스트림(stream)을 시작하기 위해서 서버로 Play 요청(request)을 전송한다. 언제든지 그 서버는 리프(leaf) 면허를 포함하는 면허 응답 메시지와 알림 요청(ANNOUNCE request)을 클라이언트로 전송한다.

실시예로 다음을 살펴본다. 우선 실시예에 따른 면허 요청 메시지를 포함하고 있는 아래의 기술 요청(DESCRIBR request)를 살펴본다.

DESCRIBE rtsp://eduardo01/file.wmv RTSP/1.0

Accept: application/sdp

CSeq: 1

Supported: com.microsoft.wmdrm-nd, com.microsoft.wm.eosmsg,

method.announce

Require: com.microsoft.wmdrm-nd

Content-Type : application/vnd.ms-wmdrm-license-request

Content-Length: 1078

License_Request_Message

당 실시예에서는 "Require: com.microsoft.wmdrm-nd"는 수신기가 서버를 어떤 특정 종류의 송신기일 것으로 예상하고 있다는 것을 의미한다. "Content-Type: application/vnd.ms-wmdrm-license-request"는 당 실시예에서 기술의 내용(the body of DESCRIBE)이 면허 요청 메시지를 포함하고 있다는 것을 의미한다.

에러가 없는 한, 송신기는 이하 기술되어 있는 면허 응답 메시지를 포함하는 SDP 기술(SDP description)을 이용해서 응답을 한다.

내용에 면허 요청 메시지를 포함하고 있는 기술 요청(DESCRIBE request)에 응하여, 서버는 면허 응답 메시지를 반환한다. 당 실시예에서 서버는 이하 기술되어 있는 다양한 파라메더(parameter) 및 면허 응답 메시지를 포함하고 있는 SDP 기술(SDP description)을 반환한다. 앞서 서술한 바와 같이 당 실시예에서는 면허 응답 메시지가 해당 콘텐츠에 적용되는 정책을 규정하는 XMR 면허를 전송한다.

일 실시예에 따른 면허 응답 메시지를 포함하는 SDP의 발췌를 살펴본다.

RTSP/1.0 200 OK

Last-Modified: Thu, 19 Dec 2002 15:36:18 GMT

Content-Length: 1891

Content-Type: application/sdp

CSeq: 1

Supported: com.microsoft.wmdrm-nd, com.microsoft.wm.eosmsg,

method.announce

SDP_Description

반환된 그 면허는 루트(root) 면허와 일치하며, 세션의 지속을 위해서 이용된다. 특정 리프(leaf) 면허는 아래 서술되어 있는 알림 요청(ANNOUNCE request)를 통해서 후에 반환된다.

실시예에 따르면, 송신기에 의해서 반환된 SDP는 RFC-2397 (http://www.ietf.org/rfc/rfc2397.txt)에 상술되어 있는 바와 같이, 데이터 URL에 인코드(encode)되어 있는 면허 응답 메시지를 포함하고 있다. 데이터 URL에 포함되어 있는 데이터는 반드시 Base64로 인코드되며, 그 MIME 타입은 "application/vnd.ms-wmdrm-license-response" 로 설정된다.

구문의 예로 다음을 살펴본다.

data:application/vnd.ms-wmdrm-license-response;base64,

AggAAAAAAAABOFhNUgAAAAAB+TTbzXCRwls+/jA4fQQYOwADAAEAAAEgAAMAAgAAADwAAQA DAAAAEgBkAAAAAAAAAAAAAQAMAAAAGKRuHVtXSJlLk7WPrQPe5X0AAQANAAAACgABAAMABAAAABoAAQAFAAAAEgBkAGQAZABkAGQAAwAJAAAApgABAAoAAACeajiAiUBMGrAGUAOIqMGBggABAAEAgC7VlQF54EzuYbTYKPbgBEK6nDXGtbV+bJKF+Cn2yd/FUaC4vTIOxkF/eQLx+FqvLCUMtxvRSw01dns9Ejt021se2T+IROiZA0t5pRuN13gq7JK9JKs+ZX8hKsEJFW0V7cyp9wdaCMh2esJ97r9agHlSxf0mAqcQ0jlQ5dtXlWx/AAEACwAAABwAAQAQZZaX5nGEUAV8w6p6BQr++Q==

당 실시예에서 해당 날짜까지 작업이 유지될 수 있게 하는 SDP키 관리 확장 내역(SDP Key management extensions specificaion)에 따라, 데이터 URL은 "a=key-mgmt" 속성을 이용해서 반드시 SDP 세션 레벨에 삽입되어야 한다. 구문은 다음과 같다.

a=key-mgmt : wmdrm-nd URL

URL 파라미터는 위에 기술된 데이터 URL이다.

스트림(stream) 과정 중에 업데이트된 정책들을 전송하는 알림 요청(ANNOUNCE request)의 이용에 대하서 살펴본다. 구체적으로, 아래의 알림 요청(ANNOUNCE request)의 발췌는 실시예에 따른 리프(leaf) 면허의 전송 방법을 표현한 것이다.

ANNOUNCE rtsp://eduardo01/file.wmv RTSP/1.0

CSeq: 27

Session: 8322364901836665746

Supported: com.microsoft.wmdrm-nd, com.microsoft.wm.eosmsg,

method.announce

Require: method.announce

Event-Type: 4000 wmdrm-nd-message

Content-Type : application/vnd.ms-wmdrm-license-response

Content-Length: 924

License_Response_Message

당 실시예에서 요청(request)의 내용(body)이 면허 응답 메시지를 포함한다는 것을 표시하기 위해서 "Content-Type : application/vnd.ms-wmdrm-license-response" 헤더가 이용되어야 한다. 당 실시예에서 이것이 DRM-ND 메시지를 전송하는 이벤트라는 것을 표시하기 위해서는 "Event-Type: 4000 wmdrm-nd-message" 헤더가 사용되어야 한다. 수신기는 면허 요청에 권리 아이디와 응답 메시지가 일치하는 지를 확인하면서 면허 응답을 처리하여야 한다. 에러가 없는 한 아래에 기술된 것과 같이 송신기에 200 OK 응답을 반환한다.

RTSP/1.0 200 OK CSeq: 27

Session: 8322364901836665746

Supported: com.microsoft.wmdrm-nd, com.microsoft.wm.eosmsg,

method.announce

기술 요청(DESCRIBE request)에 반환되는 면허는 루트(root) 면허에 해당하기 때문에, 수신기가 콘텐츠를 복호화할 수 있는 리프(leaf) 면허를 데이터 전송을 시작하기 전에 송신기가 반드시 전송해야 한다. 다시 말해, 수신기가 최초의 재생 요청(play request)을 전송하고 난 후, 송신기는 데이터 전송을 시작하기에 앞서 알림 요청(ANNOUNCE request) 안에 리프(leaf) 면허를 보내야 한다.

송신기가 알림(ANNOUNCE) 메시지를 전송하는 시점과 콘텐츠를 복호화하기 위한 새로운 면허가 필요한 시점 사이에는 뚜렷한 관계가 없다. 이것은 송신기가 관련 있는 보안 콘텐츠를 포함하는 패킷을 전송하기 전 또는 후에도, 송신기가 알림(ANNOUNCE)를 전송할 수 있다는 것을 의미한다. 당업자가 이해 가능한 것처럼, 보안 콘텐츠를 전송하는데 이용되는 방법은 RTP 패킷을 이용할 수 있다.

결론

위에서 기술한 다양한 실시예들에서 DRM 정책과 같은 정책 업데이트들이 보안 콘텐츠의 일정 부분에 대해서 전송되고 업데이트될 수 있다. 적어도 몇몇의 실시예에서는 다양한 프로토콜들이 확장되어 정책 업데이트들이 그 프로토콜에 의해서 표현되고 전송될 수 있게 해준다.

비록 발명이 구조적 특징들과 그리고/또는 방법론적 단계의 언어로 기술되었지만, 본 청구항에 의해 정의된 발명은 기술된 특정의 특징들과 단계들로 제한되지 않는다. 그보다는, 구체적인 특징 및 단계들은 청구된 발명을 구현하기 위한 바람직한 형태로서 개시된다.

Claims

컴퓨터로 구현되는 방법으로서,

의도된 수신기의 공용키를 이용해서 암호화된 초기 콘텐츠키를 포함하고, 상기 의도된 수신기에 스트림(stream)될 콘텐츠에 연관되는 루트(root) 면허를 구축하는 단계;

상기 루트(root) 면허를 상기 의도된 수신기에 전송하는 단계;

상기 루트(root) 면허와 연결되고 스트림되는 콘텐츠와 관련하여 업데이트되는 정책과 연관되는 하나 이상의 리프(leaf) 면허들을 준비하는 단계; 및

상기 의도된 수신기에 상기 하나 이상의 리프(leaf) 면허들을 전송하는 단계를 포함하고,

상기 하나 이상의 리프 면허들은 각각 상기 초기 콘텐츠키를 이용해서 암호화된 상이한 콘텐츠키를 포함하고, 상기 상이한 콘텐츠키가 보안 콘텐츠를 복호화하기 위해 상기 수신기에 의해서 이용되는 방법.
제1항에 있어서,

상기 초기 콘텐츠키가 상기 공용키보다 적은 비트를 가지는 방법.
제2항에 있어서,

상기 초기 콘텐츠키는 128-비트 AES키를 포함하는 방법.
제1항에 있어서,

상기 상이한 콘텐츠키는 상기 공용키보다 적은 비트를 가지는 방법.
제4항에 있어서,

상기 상이한 콘텐츠키는 128-비트 AES키를 포함하는 방법.
제1항에 있어서,

상기 루트(root) 면허과 상기 하나 이상의 리프(leaf) 면허들을 전송하는 단계들은 HTTP를 이용해서 이루어지는 방법.
제1항에 있어서,

상기 루트(root) 면허와 상기 하나 이상의 리프(leaf) 면허들을 전송하는 단계들은 HTTP를 이용해서 이루어지고, 상기 하나 이상의 리프(leaf) 면허들을 전송하는 단계는 상기 하나 이상의 리프(leaf) 면허들을 포함하는 데이터와 함께 보안 콘텐츠를 인터리빙(interleaving)하는 단계를 포함하는 방법.
제1항에 있어서,

상기 루트(root) 면허와 상기 하나 이상의 리프(leaf) 면허들을 보내는 단계 는 RTSP를 이용해서 이루어지는 방법.
컴퓨터로 구현되는 방법으로서,

수신기로 스트림될 보안 정보를 위한 루트(root) 면허를 요구하는 HTTP POST 요청(request)을 수신하는 단계;

상기 수신에 응하여 상기 수신기에 루트(root) 면허를 전송하는 단계;

보안 콘텐츠를 요구하는 HTTP GET 요청(request)을 수신하는 단계; 및

HTTP GET 요청(request)에 대한 상기 수신에 응하여 상기 루트(root) 면허에 연결된 하나 이상의 리프(leaf) 면허를 포함하는 데이터와 함께 인터리브(interleave)되는, 요청된 보안 콘텐츠의 세그먼트(segment)를 전송하는 단계

를 포함하는 방법.
제9항에 있어서,

상기 HTTP POST 요청(request)은 면허 요청 메시지를 포함하는 방법.
제9항에 있어서,

상기 루트(root) 면허를 전송하는 단계가 상기 수신기로 면허 응답 메시지를 보내는 것에 의해 이루어지는 방법.
제9항에 있어서,

상기 하나 이상의 리프(leaf) 면허를 포함하는 상기 데이터는 각각 하나 이상의 면허 응답 메시지로 이루어지는 방법.
컴퓨터로 구현되는 방법으로서,

수신기에 스트림될 보안 콘텐츠에 대한 루트(root) 면허를 요청하는 RTSP 기술 요청(RTSP DESCRIBE Request)을 받는 단계;

수신기에 루트(root) 면허를 전송하는 단계; 및

상기 루트(root) 면허에 연결되어 있는 하나 이상의 리프(leaf) 면허를 전송는 단계를 포함하고, 상기 하나 이상의 리프(leaf) 면허를 전송하는 단계 동안 이루어지는 단계

를 포함하는 방법.
제13항에 있어서,

상기의 기술 요청(DESCRIBE request)은 면허 요청 메시지를 포함하는 방법.
제13항에 있어서,

상기의 루트(root) 면허를 전송하는 단계는 루트(root) 면허를 포함하는 면허 응답 메시지를 임베드(embed)한 RTSP 세션 기술 프로토콜(RTSP SESSION DESCRIPTION PROTOCOL)를 전송하는 단계를 포함하는 방법.
제13항에 있어서,

상기 하나 이상의 리프(leaf) 면허를 전송하는 단계는 각각 하나 이상의 RTSP 알림 요청(RTSP ANNOUNCE request)을 이용해서 이루어지는 방법.
제13항에 있어서,

상기 하나 이상의 리프(leaf) 면허를 전송하는 단계는 각각 하나 이상의 RTSP 알림 요청(RTSP ANNOUNCE request)을 이용해서 이루어지고,

상기 RTSP 알림 요청(RTSP ANNOUNCE request)은 각각 면허 응답 메시지를 포함하는 방법.
제13항에 있어서,

상기 기술 요청(DESCRIBE request)은 면허 요청 메시지를 포함하고;

상기 루트(root) 면허를 전송하는 단계는 상기 루트(root) 면허를 포함하는 면허 응답 메시지를 임베드(embed)한 RTSP 세션 기술 프로토콜(RTSP SEESSION DESCRIPTION PROTOCOL,SDP)를 전송하는 단계를 포함하는 방법.
제13항에 있어서,

상기 루트(root) 면허를 전송하는 단계는 상기 루트(root) 면허를 포함하는 면허 응답 메시지를 임베드(embed)한 RTSP 세션 기술 프로토콜(RTSP SESSION DESCRIPTION PROTOCOL, SDP)를 전송하는 단계를 포함하고;

상기 하나 이상의 리프(leaf) 면허를 전송하는 단계는 각각 하나 이상의 RTSP 알림 요청(RTSP ANNOUNCE request)을 이용하여 이루어지는 방법.
제13항에 있어서,

상기 기술 요청(DESCRIBE request)은 면허 요청 메시지를 포함하고;

상기 루트(root) 면허를 전송하는 단계가 상기 루트(root) 면허를 포함하는 면허 응답 메시지를 임베드(embed)한 RTSP 세션 기술 프로토콜(RTSP SESSION DESCRIPTION PROTOCOL, SDP)을 전송하는 단계를 포함하고;

상기 하나 이상의 리프(leaf) 면허를 전송하는 단계는 각각 하나 이상의 RTSP 어나운스 요청(RTSP ANNOUNCE request)을 이용하여 이루어지는 방법.