KR20040076627A

KR20040076627A - 디지털 콘텐츠 권리 관리 아키텍처로의 ｄｒｍ 서버등록/부등록 방법

Info

Publication number: KR20040076627A
Application number: KR1020040012235A
Authority: KR
Inventors: 고스탈그레고리; 보우르네스티브; 크리시나스와미비나이
Original assignee: 마이크로소프트 코포레이션
Priority date: 2003-02-25
Filing date: 2004-02-24
Publication date: 2004-09-01
Also published as: US20080196091A1; BRPI0400335A; CO5550078A1; RU2004105509A; US20040168061A1; SG135945A1; IL160352A; TW200501705A; CA2457938A1; NZ531278A; RU2348073C2; US7308573B2; EP1455479B1; CA2457938C; MY144595A; EP1455479A1; ATE375646T1; MXPA04001728A; ZA200401306B; PL365549A1

Abstract

디지털 콘텐츠 권리 관리(DRM) 시스템은 DRM 기능을 수행하는 복수의 DRM 서버를 가지고 있고, 신입 DRM-E 서버는 등록 DRM-R 서버에 의해 DRM 시스템에 등록되어 신입 DRM-E 서버가 DRM 시스템 내에서 신뢰되도록 한다. DRM-E 서버는 제공 신원 증명(proffering identification) 및 공개 키(PU-E)를 포함하는 등록 요청을 DRM-R 서버에 전송한다. DRM-R 서버는 그 제공 신원 증명을 유효화하고, 상기 요청이 받아들여져야 하는 경우 그와 같은 DRM-E 서버를 DRM 시스템에 등록하기 위해 DRM-E 서버에 대해 (PU-E)를 가진 디지털 등록 증명서를 생성한다. 생성된 등록 증명서를 갖는 이제 등록되는 DRM-E 서버는 DRM 시스템 내에서 DRM 문서를 발행하는데에 그 등록 증명서를 이용할 수 있다.

Description

디지털 콘텐츠 권리 관리 아키텍처로의 ＤＲＭ 서버 등록/부등록 방법{ENROLLING/SUB-ENROLLING A DIGITAL RIGHTS MANAGEMENT (DRM) SERVER INTO A DRAM ARCHITECTURE}

다음의 미국 특허 출원은 본 출원의 요지와 관련된 기술 사상을 개시하였으며, 여기에 참고 문헌으로서 전체가 포함된다.

대리인 문서 번호 MSFT-1330로 2002년 6월 28일에 출원되고, 발명의 명칭이 "디지털 콘텐츠에 대한 서명된 권리 표시(SRL)의 획득 및 디지털 콘텐츠 권리 관리 시스템에서 SRL에 기초하여 콘텐츠에 대응하는 디지털 라이센스의 획득"(Obtaining a Signed Rights Label (SRL) for Digital Content and Obtaining a Digital License Corresponding to the Content Based on the SRL in a Digital Rights Management System)인 미국 특허 출원 제10/185,527호;

대리인 문서 번호 MSFT-1333으로 2002년 6월 28일에 출원되고, 발명의 명칭이 "디지털 콘텐츠 권리 관리 시스템에서 디지털 콘텐츠에 대한 서명된 권리 표시(SRL)를 획득하기 위한 권리 템플릿의 이용(Using a Rights Template to Obtain a Signed Rights Label (SRL) for Digital Content in a Digital Rights Management System)"인 미국 특허 출원 제10/185,278호;

대리인 문서 번호 MSFT-1343로 2002년 6월 28일에 출원되고, 발명의 명칭이 "디지털 콘텐츠 및 서비스에 대한 사용 라이센스를 발행하기 위한 시스템 및 방법"(Systems And Methods For Issuing Usage Licenses For Digital Content And Services)인 미국 특허 출원 제10/185,511호;

대리인 문서 번호 MSFT-1498로 __________자로 출원되고, 발명의 명칭이 "디지털 콘텐츠 권리 관리(DRM) 시스템에 따른 조직 내의 디지털 콘텐츠 발행"(Publishing Digital Content Within an Organization in Accordance with a Digital Rights Management (DRM) System)인 미국 특허 출원 제___________호;

대리인 문서 번호 MSFT-1569로 __________자로 출원되고, 발명의 명칭이 "디지털 콘텐츠 권리 관리(DRM) 시스템에 따른 조직 내의 디지털 콘텐츠 발행"(Publishing Digital Content Within an Organization in Accordance with a Digital Rights Management (DRM) System)인 미국 특허 출원 제________호; 및

대리인 문서 번호 MSFT-1537로 본 출원과 함께 __________자로 출원되고, 발명의 명칭이 "디지털 콘텐츠 권리 관리(DRM) 시스템에서 발행자에게 사용 라이센스를 오프라인으로 발행하기"(Issuing a Publisher Use License Off-Line in a Digital Rights Management (DRM) System)인 미국 특허 출원 제________호.

본 발명은 디지털 콘텐츠 권리 관리(DRM) 시스템에 관한 것이다. 특히, 본 발명은 사무실 또는 회사 등과 같은 조직 내에서 디지털 콘텐츠를 발행하는데 DRM 시스템을 사용하여, 조직 내에서의 콘텐츠의 제공 및 이용이 대응하는 사용 기간 또는 라이센스 기간에 맞게 한정될 수 있도록 하는 것에 관한 것이다. 특히, 본 발명은 이러한 DRM 시스템을 이루는 DRM 서버의 네트워크, 및 이 네트워크에 DRM 서버를 등록(enrolling) 또는 부등록(sub-enrolling)하는 방법에 관한 것이다.

디지털 콘텐츠 권리 관리 및 시행은 디지털 오디오, 디지털 비디오, 디지털 텍스트, 디지털 데이터, 디지털 멀티미디어 등과 같은 디지털 콘텐츠와 관련하여 매우 소망되는 사항으로서, 여기서 이와 같은 디지털 콘텐츠는 한 명 이상의 사용자에게 분배되어야 한다. 디지털 콘텐츠는 예컨대 텍스트 문서와 같이 정적(static)일 수 있고, 또는 라이브 이벤트의 스트리밍된 오디오/비디오와 같이 스트리밍될 수 있다. 일반적인 분배 방법은 자기 (플로피) 디스크, 자기 테이프, 광 (콤팩트) 디스크(CD) 등과 같은 유형의 장치들, 및 전자 게시판, 전자 네트워크, 인터넷 등과 같은 무형의 매체를 포함한다. 사용자에 의해 수신되면, 이와 같은 사용자는 퍼스널 컴퓨터 등에 있는 매체 플레이어와 같은 적절한 실행 장치(rendering device)의 도움으로 디지털 콘텐츠를 실행 또는 '플레이'한다.

작가, 출판사, 방송국 등과 같은 콘텐츠 소유권자 또는 권리 소유권자가 이러한 디지털 콘텐츠를 라이센스료 또는 어떤 다른 보상과 교환하여 많은 사용자 또는 수령자에게 분배하기를 원하는 상황을 생각해 보자. 이때, 이와 같은 상황에서, 콘텐츠는 노래, 노래 앨범, 영화 등일 수 있으며, 분배의 목적은 라이센스료를발생하는데 있다. 이와 같은 콘텐츠 소유권자는, 선택권이 주어진다면, 사용자가 분배된 디지털 콘텐츠로 할 수 있는 것을 제한하기를 원할 것이다. 예컨대, 콘텐츠 소유권자는 적어도 제2의 사용자로부터의 라이센스료를 콘텐츠 소유권자에게 지급하지 않아도 되는 방식으로 사용자가 그와 같은 콘텐츠를 제2의 사용자에게 카피 및 재분배하지는 못하게 하기를 원할 것이다.

또한, 콘텐츠 소유권자는 상이한 라이센스료로 상이한 종류의 사용 라이센스를 구입할 수 있는 융통성을 사용자에게 제공하면서 동시에 어떤 종류의 라이센스이건 간에 실제로 구입한 라이센스의 만료일까지는 사용자를 유지하기를 원할 수 있다. 예컨대, 콘텐츠 소유권자는 분배된 디지털 콘텐츠가, 예컨대, 제한된 횟수만큼만, 특정의 전체 시간 동안만, 특정의 종류의 기계 상에서만, 특정의 종류의 매체 플레이어로만, 특정의 종류의 사용자에 의해서만 플레이될 수 있게 하기를 원할 수 있다.

다른 상황으로, 조직 내의 종업원 또는 조직의 멤버와 같은 콘텐츠 개발자는 그와 같은 디지털 콘텐츠를 조직 내의 한명 이상의 다른 종업원 또는 멤버, 또는 조직 밖의 다른 개인들에 분배하기를 원하나, 타인들이 이 콘텐츠를 실행하지 못하게 하는 것을 원하는 경우를 생각해 보자. 여기서, 콘텐츠의 분배는 라이센스료 또는 어떤 다른 보상과 교환하는 대중적인 분배 방식과는 반대로 비밀스러운 또는 제한된 방식으로 조직에 기초한 콘텐츠 공유 방식과 보다 유사하다.

이때, 이와 같은 상황에서, 콘텐츠는 예컨대 사무실 환경 내에서 교환될 수 있는 문서 프리젠테이션, 스프레드시트, 데이터베이스, 이메일 등일 수 있고, 콘텐츠 개발자는 콘텐츠가 조직 또는 사무실 범위 내에 한정되고, 예컨대 경쟁자 또는 적대자와 같은 인증받지 않은 사람에 의해 실행될 수 없게 되는 것이 보장되기를 원할 수 있다. 또한, 이와 같은 콘텐츠 개발자는 수령자가 그와 같은 분배된 디지털 콘텐츠를 가지고 할 수 있는 것을 제한하기를 원한다. 예컨대, 콘텐츠 소유권자는, 적어도 콘텐츠를 실행하는 것이 허용된 개인의 범위 밖으로 콘텐츠가 노출되도록, 사용자가 제2의 사용자에게 그와 같은 콘텐츠를 카피 및 재분배하지 못하게 하는 것을 원한다.

또한, 콘텐츠 개발자는 상이한 수준의 실행 권리를 다양한 수령자들에게 제공하기를 원할 수 있다. 예컨대, 콘텐츠 개발자는 보호된 디지털 콘텐츠는 어떤 클래스의 개인들에게는 시청이 허용되지만 인쇄는 허용되지 않도록 하고, 다른 클래스의 개인들에게는 시청 및 인쇄가 모두 허용되도록 하기를 원할 수 있다.

그러나, 위의 두 상황 모두, 분배를 한 후, 그와 같은 콘텐츠 소유권자/개발자는 디지털 콘텐츠에 대해 거의 아무런 제어를 할 수 없다. 이는, 특히, 실제로 모든 퍼스널 컴퓨터는, 그와 같은 디지털 콘텐츠의 정확한 디지털 카피를 행하고 그와 같은 정확한 디지털 카피를 기록 가능 자기 또는 광 디스크로 다운로드하거나 인터넷과 같은 네트워크 상에서 그와 같은 정확한 디지털 카피를 어떤 목적지로 전송하는데 필요한 소프트웨어 및 하드웨어를 포함하고 있다는 사실을 감안할 때 특히 문제가 된다.

물론, 콘텐츠를 분배하는 거래의 일부로서, 콘텐츠 소유권자/개발자는 그와 같은 디지털 콘텐츠를 달갑지 않은 방식으로 재분배하지 않도록 약정할 것을 디지털 콘텐츠의 사용자/수령자에게 요구할 수도 있다. 그러나, 그러한 약정은 쉽게 이루어지고 쉽게 깨진다. 콘텐츠 소유권자/개발자는 통상 암호화 및 암호 해제를 포함하는 여러가지 알려진 보안 장치들을 통해 그와 같은 재분배를 방지하는 시도를 할 수 있다. 그러나, 다소 굳게 결심한 사용자가 암호화된 디지털 콘텐츠를 암호 해제하고, 그와 같은 디지털 콘텐츠를 암호화되지 않은 형태로 저장한 후 그 콘텐츠로 재분배하는 것을 방지할 수 있는 방법은 거의 없다.

그렇다면, 임의 형태의 디지털 콘텐츠의 제어된 실행 또는 플레이를 가능하게 하며, 이와 같은 제어가 융통성이 있고 그와 같은 디지털 콘텐츠의 콘텐츠 소유권자/개발자에 의해 정의 가능한 디지털 콘텐츠 권리 관리(DRM) 및 시행 아키텍처 및 방법을 제공하는 것이 필요하다. 특히, 정의된 그룹의 개인들 또는 등급의 개인들 사이에서 문서가 공유되어야 하는 사무실 또는 조직 환경 등에서 그와 같은 제어된 실행을 가능하게 하고 수월하게 하는 구조가 특히 필요하다. 특히, 승인 서버를 아키텍처에 등록하는 방법이 필요하다.

도 1은 본 발명이 구현될 수 있는 예시적이고 비제한적인 컴퓨팅 환경을 나타낸 블록도.

도 2는 본 발명이 구현될 수 있는 다양한 컴퓨팅 장치를 가진 예시적인 네트워크 환경을 나타낸 블록도.

도 3은 디지털 콘텐츠를 발행하기 위한 본 발명에 따른 시스템 및 방법의 바람직한 실시예의 기능 블록도.

도 4는 권리 관리된 디지털 콘텐츠를 발생하기 위한 본 발명에 따른 방법의 바람직한 실시예의 플로우챠트.

도 4a는 도 4의 방법에 의해 생성되는 서명된 권리 표시의 구조를 도시한 블록도.

도 5는 권리 관리된 디지털 콘텐츠를 라이센싱하기 위한 본 발명에 따른 시스템 및 방법의 바람직한 실시예의 블록도.

도 6a 및 도 6b는 권리 관리된 디지털 콘텐츠를 라이센싱하기 위한 본 발명에 따른 방법의 바람직한 실시예의 플로우챠트.

도 7은 본 발명의 일실시예에 따라 사용자가 오프라인 발행을 수행할 수 있도록 DRM 서버에 의해 사용자에게 발행된 증명서를 도시한 블록도.

도 8은 본 발명의 일실시예에 따라 발행 사용자가 오프 라인 발행된 콘텐츠를 제공하도록 하는 발행자 라이센스와 함께 도 7의 증명서를 나타낸 블록도.

도 9는 본 발명의 일실시예에 따라 도 8의 공개 라이센스를 획득하는데 발행 사용자에 의해 수행되는 중요 단계를 나타낸 플로우챠트.

도 10은 본 발명의 일실시예에 따라 대응 콘텐츠를 제공하기 위해 도 9의 획득된 발행 라이센스를 이용하기 위해 발행 사용자에 의해 수행되는 중요 단계를 나타낸 플로우챠트.

도 11은 신뢰 기반 시스템의 일 예의 시행 구조를 나타낸 블록도.

도 12는 예컨대 각각의 (신입) DRM 서버가 등록 증명서를 발행하는 다른 (등록) DRM 서버에 의해 아키텍처에 등록 또는 부등록되는, 본 발명의 아키텍처에 존재할 수 있는 복수의 DRM 서버를 나타낸 블록도.

도 13은 신입 DRM 서버에 의해 적어도 몇몇 경우에서 등록 DRM 서버에 제시된 보증 증명서와 함께 도 12의 등록 증명서를 도시한 블록도.

도 14 및 도 15는 신입 DRM 서버를 등록(도 14) 또는 부등록(도 15)하기 위해 도 13 및 도 14의 등록 및 신입 DRM 서버에 의해 수행되는 중요 단계를 도시한 흐름도.

<중요 도면 부호의 설명>

10a, 10b: 서버 오브젝트

100: 컴퓨팅 환경

110a: 컴퓨팅 장치

110c, 110d: 오브젝트

120: 처리 유닛

304: 암호화된 디지털 콘텐츠

306: DRM 클라이언트 API

320: DRM 서버

상기한 필요성은 적어도 부분적으로 본 발명에 의해 만족되며, 여기서 디지털 콘텐츠 권리 관리(DRM) 시스템은 DRM 기능을 수행하는 복수의 DRM 서버를 가지고 있고, 신규 DRM-E 서버는 등록 DRM-R 서버에 의해 그 시스템에 등록되어, 그 신규 DRM-E 서버는 상기 시스템 내에서 신뢰받게 된다. 본 발명에서, DRM-E 서버는 DRM 시스템 내에서 그와 같은 DRM-E 서버를 식별하기 위한 공개/개인 키 쌍(PU-E,PR-E)을 획득하고, 그 제공 식별자(proffering identification)를 획득하며, 제공 식별자 및 (PU-E)를 포함하는 등록 요청을 DRM-R 서버에 전송한다.

DRM-R 서버는 제공 식별자를 확인하고, 요청이 받아들여져야 한다면, DRM-E 서버가 그와 같은 DRM-E 서버를 DRM 시스템에 등록하도록, 디지털 등록 증명서를 생성한다. 생성된 등록 증명서는 적어도 부분적으로 (PU-E)에 기초한다. DRM-R 서버는 생성된 등록 증명서를 요청 DRM-E 서버로 반환하고, 지금 등록된 DRM-E 서버는 장래의 사용을 위해 반환된 등록 증명서를 적절한 위치에 저장한다. 등록 증명서를 가진 DRM-E 서버는 DRM 시스템 내에서 DRM 문서를 생성하는데 등록 증명서를 이용할 수 있다.

본 발명의 실시예의 다음의 상세한 설명뿐만 아니라 상기한 개요는 첨부 도면과 함께 읽을 때 보다 잘 이해된다. 본 발명을 보여주기 위한 목적으로, 본 발명의 바람직한 실시예가 도면에 도시되어 있다. 그러나, 이해되는 바와 같이, 본 발명은 도시된 정확한 장치 및 수단에 한정되지 않는다.

컴퓨터 환경

도 1 및 다음의 설명은 본 발명이 구현될 수 있는 적합한 컴퓨팅 환경의 간단한 일반 설명을 제공하기 위한 것이다. 그러나, 모든 종류의 핸드헬드(handheld), 휴대형 및 기타 다른 컴퓨팅 장치들이 본 발명과 관련하여 사용될 수 있다는 점을 이해해야 한다. 이하에서는 범용 컴퓨터가 설명되나, 이는 한가지 예에 불과하며, 본 발명은 네트워크 서버 상호운용성 및 상호작용성을 가진 씬 클라이언트(thin client)만을 필요로 한다. 따라서, 본 발명은 매우 적은 또는최소의 클라이언트 자원들이 포함된 네트워크 호스트 서비스의 환경에서, 예컨대 클라이언트 장치가 단지 월드와이드웹에의 브라우저 또는 인터페이스의 역할만을 하는 네트워크 환경에서 구현될 수 있다.

요구되지는 않지만, 본 발명은 개발자에 의해 사용되는 API(application programming interface)를 통해 구현될 수 있고, 그리고/또는 클라이언트 워크스테이션, 서버 또는 다른 장치와 같은 하나 이상의 컴퓨터에 의해 실행되는, 프로그램 모듈과 같은 컴퓨터로 실행 가능한 명령들의 일반적인 콘텍스트로 설명되는 네트워크 브라우징 소프트웨어 내에 포함될 수도 있다. 일반적으로, 프로그램 모듈은 특정 작업을 수행하거나 특정한 ADT(Abstract Data Type)를 구현하는 루틴, 프로그램, 오브젝트, 구성 요소, 데이터 구조 등을 포함한다. 일반적으로, 프로그램 모듈의 기능은 각종 실시예에서 원하는 대로 조합 또는 분배될 수 있다. 또한, 당업자는 본 발명이 다른 컴퓨터 시스템 구성으로 실시될 수 있음을 알게 될 것이다. 본 발명에 사용하기에 적합한 다른 잘 알려진 컴퓨팅 시스템, 환경 및/또는 구성으로, 퍼스널 컴퓨터(PC), 현금자동입출금기, 서버 컴퓨터, 핸드헬드 또는 랩탑 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 프로그래밍 가능한 일반 소비자용 전자 장치, 네트워크 PC, 미니컴퓨터, 메인 프레임 컴퓨터 등이 포함되나, 이에 한정되지 않는다. 본 발명은 또한 통신 네트워크 또는 다른 전송 매체를 통해 링크되는 원격 처리 장치들에 의해 작업이 수행되는 분산 컴퓨팅 환경에서 실시될 수도 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 기억 장치를 포함하는 로컬 및 원격 컴퓨터 기억 매체 내에 위치될 수 있다.

도 1에는 이와 같이 본 발명이 구현될 수 있는 적합한 컴퓨팅 시스템 환경(100)의 일예가 도시되어 있으며, 위에서 명확히 설명한 바와 같이, 컴퓨팅 시스템 환경(100)은 적합한 컴퓨팅 환경의 일예에 불과하며, 본 발명의 사용 또는 기능의 범위에 대한 어떠한 제한을 제시하는 것이 아니다. 컴퓨팅 환경(100)은, 예시적인 동작 환경(100)에 도시된 어느 하나의 구성 요소 또는 구성 요소들의 조합에 관하여 어떠한 종속성이나 요건을 가진 것으로 해석되어서는 안 된다.

도 1을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은 컴퓨터(11) 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 구성 요소는 처리 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 포함하여 각종 시스템의 구성 요소를 처리 유닛(120)에 연결하는 시스템 버스(121)를 포함하나, 이에 한정되지 않는다. 시스템 버스(121)는, 다양한 버스 아키텍처 중 어느 하나를 사용하는, 메모리 버스 또는 메모리 제어기, 주변 버스, 및 로컬 버스를 포함한 여러 종류의 버스 구조를 가질 수 있다. 예로서 그리고 제한 없이, 그와 같은 아키텍처는 ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA 버스(Enhanced ISA)버스, VESA(Video Electronics Standards Association) 버스, PCI(Peripheral Component Interconnect) 버스(메자닌(Mezzanine) 버스로도 알려짐)를 포함한다.

컴퓨터(110)는 일반적으로 다양한 컴퓨터로 판독 가능한 매체들을 포함한다. 컴퓨터로 판독 가능한 매체는 컴퓨터(110)에 의해 액세스될 수 있고 휘발성 및 비휘발성 매체와 소거 가능 및 제거 불가능 매체를 포함하는 이용 가능한 어떤 매체일 수 있다. 예로서 그러나 제한없이, 컴퓨터로 판독 가능한 매체는 컴퓨터 기억 매체 및 통신 매체를 포함할 수 있다. 컴퓨터 기억 매체는 컴퓨터로 판독 가능한 명령, 데이터 명령, 프로그램 모듈 또는 다른 데이터와 같은 정보의 저장을 위한 어떤 방법 또는 기술로 구현되는 휘발성인, 또는 비휘발성인, 그리고 소거 가능한 또는 제거 불가능한 매체를 포함한다. 컴퓨터 기억 매체는 원하는 정보를 저장하는데 사용될 수 있고 컴퓨터(110)에 의해 액세스될 수 있는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CDROM, DVD(digital versatile disk) 또는 다른 광 디스크 기억 장치, 자기 카세트, 자기 테이프, 자기 디스크 기억 장치 또는 다른 자기 기억 장치 장치, 또는 다른 매체를 포함하나, 이에 한정되지 않는다. 통신 매체는 일반적으로 컴퓨터 판독 가능 명령, 데이터 명령, 프로그램 모듈, 또는 캐리어 웨이브(carrier wave) 또는 다른 전송 메커니즘과 같은 변조된 데이터 신호의 다른 데이터를 구현한다. "변조된 데이터 신호"란 용어는 신호 내의 정보를 부호화하는 것과 같은 방식으로 설정 또는 변화된 특성들 중 하나 이상을 가진 신호를 의미한다. 예로서 그리고 제한 없이, 통신 매체는 유선 네트워크 또는 직접 유선 접속과 같은 유선 매체, 그리고 음향, RF, 적외선 및 다른 무선 매체와 같은 무선 매체를 포함한다. 상기 매체 중 어떤 매체의 조합도 컴퓨터 판독 가능 매체의 범위 내에 포함되어야 한다.

시스템 메모리(130)는 판독 전용 메모리(ROM)(131) 및 랜덤 액세스 메모리(RAM)(132)와 같은 휘발성 및/또는 비휘발성 메모리의 형태인 컴퓨터 기억 매체를 포함한다. 예컨대 컴퓨터 가동 시작시에 컴퓨터(110) 내의 요소들 사이에서의 정보 전송을 돕는 기본 루틴을 포함하는 기본 입력/출력 시스템(133)(BIOS)은 일반적으로 ROM(131)에 저장된다. RAM(132)은 일반적으로 처리 유닛(120)에 의해 즉시 액세스 가능하고 그 처리 유닛에 의해 현재 동작되고 있는 데이터 및/또는 프로그램 모듈을 포함한다. 예로서 그리고 제한 없이, 도 1은 운영 체제(134), 응용 프로그램(135), 다른 프로그램 모듈(136) 및 프로그램 데이터(137)를 보여준다.

컴퓨터(110)는 또한 다른 소거 가능/소거 불가능, 휘발성/비휘발성 컴퓨터 기억 매체를 포함할 수 있다. 단지 예로서, 도 1은 소거 불가능하고 비휘발성인 자기 매체로부터 판독하거나 그 자기 매체에 기록하는 하드 디스크 드라이브(141), 소거 가능하고 비휘발성인 자기 디스크(152)로부터 판독하거나 그 자기 디스크에 기록하는 자기 디스크 드라이브(151), 및 CD ROM 또는 다른 광학 매체와 같은 소거 가능하고 비휘발성인 광 디스크(156)로부터 판독하거나 그 광 디스크에 기록하는 광 디스크 드라이브(155)를 예시한다. 예시적인 동작 환경에서 사용될 수 있는 다른 소거 가능/소거 불가능한, 휘발성/비휘발성의 컴퓨터 기억 매체는 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테이프, 고체 상태의 RAM, 고체 상태의 ROM 등을 포함하나, 이에 한정되지 않는다. 하드 디스크 드라이브(141)는 일반적으로 인터페이스(14)와 같은 소거 불가능한 메모리 인터페이스를 통해 시스템 버스(121)에 접속되며, 자기 디스크 드라이브(151) 및 광 디스크 드라이브(155)는 일반적으로 인터페이스(150)와 같은 소거 가능한 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.

위에서 설명되고 도 1에 예시된 드라이브 및 이 드라이브와 연관된 컴퓨터기억 매체는 컴퓨터(110)용의 컴퓨터 판독 가능 명령, 데이터 명령, 프로그램 모듈 및 다른 데이터의 저장을 제공한다. 도 1에서, 예컨대, 하드 디스크 드라이브(141)는 운영 체제(144), 애플리케이션 프로그램(145), 다른 프로그램 모듈(146) 및 프로그램 데이터를 저장하는 것으로 예시되어 있다. 이들 구성 요소는 운영 체제(134), 애플리케이션 프로그램(135), 다른 프로그램 모듈(136) 및 프로그램 데이터(137)와 동일하거나 다를 수 있음에 주의하자. 운영 체제(144), 응용 프로그램(145), 다른 프로그램 모듈(146), 및 프로그램 데이터(147)는 여기서 최소한 이들이 상이한 카피임을 예시하기 위해 여기서 다른 번호가 주어졌다. 사용자는 키보드(162), 그리고 일반적으로 마우스, 트랙볼 또는 터치 패드라고도 하는 포인팅 장치(161)와 같은 입력 장치들을 통해 컴퓨터(110)에 명령 및 정보를 입력할 수 있다. 다른 입력 장치(도시되지 않음)로는 마이크로폰, 조이스틱, 게임 패드, 위성 접시, 스캐너 등이 포함될 수 있다. 이들 입력 장치 및 다른 입력 장치들은 종종 시스템 버스(121)에 접속된 사용자 입력 인터페이스(160)를 통해 처리 유닛(121)에 접속되나, 병렬 포트, 게임 포트 또는 USB(universal serial bus)와 같은 다른 인터페이스 및 버스 구조에 의해 접속될 수도 있다.

모니터(191) 또는 다른 종류의 디스플레이 장치가 또한 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)에 접속된다. 노쓰브리지(Northbridge)와 같은 그래픽 인터페이스(182)도 또한 시스템 버스(121)에 접속될 수 있다. 노쓰브리지는 CPU, 즉 호스트 처리 유닛(120)과 통신하는 칩셋이며, 가속 그래픽 포트(AGP) 통신을 담당한다. 하나 이상의 그래픽 처리유닛(GPU)(184)이 그래픽 인터페이스(182)와 통신할 수 있다. 이 점에 있어서, GPU(184)는 일반적으로 레지스터 기억 장치와 같은 온칩 메모리 기억 장치를 포함하며, GPU(184)는 비디오 메모리(186)와 통신한다. 그러나, GPU(184)는 코프로세서의 일예에 불과하며, 따라서 다양한 종류의 코프로세싱 장치가 컴퓨터(110) 내에 포함될 수 있다. 모니터(191) 또는 다른 종류의 디스플레이 장치가 또한 비디오 메모리(186)와 통신할 수 있는 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)에 접속된다. 모니터(191) 외에, 컴퓨터는 출력 주변 인터페이스(195)를 통해 접속될 수 있는 스피커(197) 및 프린터(196)와 같은 다른 주변 출력 장치를 포함할 수 있다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터에의 논리 접속을 이용하여 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어(peer) 장치 또는 다른 공통 네트워크 노드일 수 있고, 도 1에는 메모리 기억 장치(181)만이 예시되어 있지만 일반적으로 컴퓨터(110)와 관련하여 위에서 설명된 요소들 중 다수 또는 모두를 포함한다. 도 1에 나타낸 논리 접속은 LAN(local area network)(171) 및 WAN(wide area newtork)(173)을 포함하나, 다른 네트워크를 포함할 수도 있다. 이와 같은 네트워킹 환경은 사무실, 기업체 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔하다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워킹 환경에서 사용될 때, 컴퓨터(110)는 일반적으로 인터넷과 같은 WAN(173) 상으로 통신을 형성하기 위한 모뎀(172) 또는 다른 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 다른 적절한 메커니즘을 통해 시스템 버스(121)에 접속될 수 있다. 네트워크 환경에서, 컴퓨터(110)와 관련하여 도시된 프로그램 모듈, 또는 그 일부는 원격 메모리 기억 장치에 저장될 수 있다. 예로서 그리고 제한없이, 도 1은 원격 애플리케이션 프로그램(185)을 메모리 장치(181) 상에 존재하는 것으로 도시한다. 도시된 네트워크 접속은 예시적이며, 컴퓨터들 사이에 통신 링크를 형성하는 다른 수단이 사용될 수 있음을 이해하여야 한다.

당업자는 컴퓨터(110) 또는 다른 클라이언트 장치가 컴퓨터 네트워크의 일부로서 사용될 수 있음을 알 수 있다. 이 점에 있어서, 본 발명은 임의의 개수의 메모리 또는 기억 유닛을 가진 컴퓨터 시스템, 및 임의의 개수의 기억 유닛 또는 볼륨을 거쳐서 발생하는 임의의 개수의 애플리케이션 및 프로세스에 관한 것이다. 본 발명은 원격 또는 로컬 기억 장치를 가진, 네트워크 환경에 사용되는 서버 컴퓨터와 클라이언트 컴퓨터를 가진 환경에 적용할 수 있다. 본 발명은 또한 프로그래밍 언어 기능, 해석 및 실행 능력을 가진 단독 컴퓨팅 장치에 적용할 수 있다.

분산 컴퓨팅(distributed computing)은 컴퓨팅 장치와 시스템간의 직접적인 교환에 의해 컴퓨터 자원 및 서비스의 공유를 용이하게 한다. 이들 자원 및 서비스는 정보의 교환, 캐시 기억 장치, 및 파일용의 디스크 기억 장치를 포함한다. 분산 컴퓨팅은 네트워크 접속을 이용하며, 이는 전체 장비에 이익이 되도록 클라이언트들이 종합적인 파워를 잘 분배하도록 한다. 이 점에 있어서, 다양한 장치가 신뢰된 그래픽 파이프라인(들)을 위해 본 발명의 인증 기술을 포함하도록 상호작용할 수 있는 애플리케이션, 오브젝트 또는 자원을 가질 수 있다.

도 2는 예시적인 네트워크 또는 분산 컴퓨팅 환경의 개략도를 제공한다. 분산 컴퓨팅 환경은 컴퓨팅 오브젝트(10a, 10b 등)와 컴퓨팅 오브젝트 및 장치(110a, 110b, 110c 등)를 구비한다. 이들 오브젝트는 프로그램, 방법, 데이터 기억 장치, 프로그래머블 로직 등을 포함할 수 있다. 오브젝트는 PDA, 텔레비전, MP3 플레이어, 텔레비전, 퍼스널 컴퓨터 등과 같은 장치 또는 상이한 장치들의 부분들을 포함할 수 있다. 각각의 오브젝트는 통신 네트워크(14)를 통해 다른 오브젝트와 통신할 수 있다. 이 네트워크 자체는 도 2의 시스템에 서비스를 제공하는 다른 컴퓨팅 오브젝트 및 컴퓨팅 장치를 구비할 수 있다. 본 발명의 측면에 따라, 각각의 오브젝트(10 또는 110)는 신뢰된 그래픽 파이프라인(들)에 대해 본 발명의 인증 기술을 요구할 수 있는 애플리케이션을 포함할 수 있다.

또한, 100c와 같은 오브젝트는 다른 컴퓨팅 장치(10 또는 110) 상에 호스팅될 수 있음을 알 수 있다. 따라서, 도시된 물리적 환경은 컴퓨터로서의 접속 장치를 나타낼 수도 있지만, 이와 같은 예시는 예에 불과하며, 대안으로 PDA, 텔레비전, MP3 플레이어 등과 같은 각종 디지털 장치, 인터페이스, COM 오브젝트 등과 같은 소프트웨어 오브젝트를 구비하는 물리적 환경이 도시 또는 설명될 수 있다.

분산 컴퓨팅 환경을 지원하는 다양한 시스템, 구성 요소 및 네트워크 구성이 있다. 예컨대, 컴퓨팅 시스템들은 유선 또는 무선 시스템에 의해, 로컬 네트워크 또는 넓게 분산된 네트워크에 의해 함께 접속될 수 있다. 현재, 다수의 네트워크가 넓게 분산된 컴퓨팅을 위한 기반 구조를 제공하고 다수의 상이한 네트워크를 포함하는 인터넷에 접속된다.

홈 네트워킹 환경에서는, 전원 라인, 데이터(무선 및 유선), 음성(예컨대, 전화) 및 엔터테인먼트 매체와 같이 고유 프로토콜을 각각 지원할 수 있는 적어도 4 개의 이종의 네트워크 전송 매체가 있다. 광 스위치 및 애플리케이션과 같은 대부분의 홈 제어 장치는 접속을 위해 전원 라인을 사용할 수 있다. 데이터 서비스는 광대역(예컨대, DSL 또는 케이블 모뎀)으로서 가정에 들어갈 수 있고 무선(예컨대, HomeRF 또는 802.11b) 또는 유선(예컨대, Home PNA, Cat 5, 심지어 전원 라인) 접속을 이용하여 가정 내에서 액세스 가능하다. 음성 트래픽은 유선(예컨대, Cat 3) 또는 무선(예컨대, 셀 폰)으로 가정으로 들어갈 수 있고, Cat 3 배선을 이용하여 가정내에서 분산될 수 있다. 엔터테인먼트 매체는 위성 또는 케이블을 통해 가정으로 들어갈 수 있고 일반적으로 동축 케이블을 통해 가정 내에서 분산된다. IEEE 1394 및 DVI도 또한 매체 장치의 클러스터를 위한 디지털 상호 접속 방법으로서 새롭게 등장하고 있다. 이들 네트워크 환경 및 프로토콜 표준으로서 새롭게 등장할 수 있는 다른 환경 모두가 상호 접속되어, 인터넷을 통해 바깥 세상에 접속될 수 있는 인트라넷을 형성한다. 요컨대, 다양한 이종 소스들이 데이터의 기억 및 전송을 위해 존재하며, 따라서 이동 전송 컴퓨팅 장치는 데이터 처리 파이프라인의 모든 부분에서 콘텐츠를 보호하는 방식을 요구하게 된다.

'인터넷'은 일반적으로 컴퓨터 네트워킹 분야에서 잘 알려진 프로토콜의 TCP/IP 슈트(suite)를 이용하는 네트워크 및 게이트웨이의 집합을 말한다. TCP/IP는 "Transport Control Protocol/Interface Program"의 두문자어이다. 인터넷은사용자가 네트워크 상에서 정보에 영향을 미치고 또 정보를 공유하도록 하는 네트워킹 프로토콜을 컴퓨터가 실행함으로써 상호 접속되는 지리적으로 분산된 원격 컴퓨터 네트워크의 시스템으로서 설명될 수 있다. 이와 같이 넓게 분산된 정보 공유 때문에, 인터넷과 같은 원격 네트워크는 지금까지 일반적으로, 개발자가 특수화된 동작 또는 서비스를 수행하기 위한 소프트웨어 애플리케이션을 설계할 수 있는 거의 제한이 없는 오픈 시스템으로 진화하였다.

따라서, 네트워크 기반 구조는 클라이언트/서버, P2P(peer to peer), 또는 하이브리드 기반 구조와 같은 네트워크 토폴로지의 호스트를 가능하게 한다. "클라이언트"는 관련되지 않은 다른 등급 또는 그룹의 서비스를 사용하는 등급 또는 그룹의 멤버이다. 따라서, 컴퓨팅할 때에 클라이언트는 프로세스, 즉 다른 프로그램에 의해 제공되는 서비스를 요구하는 대략 한 세트의 명령 또는 작업이다. 클라이언트 프로세스는 다른 프로그램 또는 서비스 자체에 관한 세부적인 작업 사항을 알아야 할 필요 없이 요청된 서비스를 이용한다. 클라이언트/서버 기반 구조, 특히 네트워크 시스템에서, 클라이언트는 통상 다른 컴퓨터, 예컨대 서버에 의해 제공되는 공유 네트워크 자원을 액세스하는 컴퓨터이다. 도 2의 예에서, 컴퓨터(110a, 110b 등)는 클라이언트로서 생각될 수 있고, 컴퓨터(10a, 10b 등)는 서버로서 생각될 수 있고, 여기서 서버(10a, 10b 등)가 클라이언트 컴퓨터(110a, 110b 등)가 후에 복제할 데이터를 지니고 있다.

서버는 일반적으로 인터넷과 같은 원격 네트워크 상에서 액세스 가능한 원격 컴퓨터 시스템이다. 클라이언트 프로세스는 제1 컴퓨터 시스템에서 활성화되고 서버 프로세스는 제2 컴퓨터 시스템에서 활성화될 수 있으며, 이들은 통신 매체 상에서 서로 통신함으로써, 분산 기능을 제공하고 다중 클라이언트가 서버의 정보 수집 능력을 활용할 수 있도록 한다.

클라이언트 및 서버는 프로토콜 층에 의해 제공되는 기능을 이용하여 서로 통신한다. 예컨대, HTTP(Hypertext-Transfer Protocol)는 WWW(World Wide Web)와 관련하여 사용되는 공통 프로토롤이다. 일반적으로, URL(Universal Resource Locator) 또는 IP(Internet Protocol) 주소와 같은 컴퓨터 네트워크 주소는 서버 또는 클라이언트 컴퓨터를 서로 식별하는데 사용된다. 네트워크 주소는 URL 주소라고도 할 수도 있다. 예컨대, 통신이 통신 매체 상으로 제공될 수 있다. 특히, 클라이언트 및 서버는 고용량 통신을 위해 TCP/IP 접속을 통해 서로 접속될 수 있다.

이와 같이, 도 2는 서버가 본 발명에서 이용될 수 있는 네트워크/버스를 통해 클라이언트 컴퓨터와 통신하는 예시적인 네트워크 또는 분산 환경을 도시한다. 보다 상세하게, 본 발명에 따라 다수의 서버(10a, 10b 등)가 LAN, WAN, 인트라넷, 인터넷 등일 수 있는 통신 네트워크/버스(14)를 통해 휴대형 컴퓨터, 핸드헬드 컴퓨터, 씬(thin) 클라이언트, 네트워크 어플라이언스(networked appliance)와 같은 다수의 클라이언트 또는 원격 컴퓨팅 장치(110a, 110b, 110c, 110d, 110e 등), 또는 VCR, TV, 오븐, 라이트, 히터 등과 같은 다른 장치와 상호 접속된다. 이와 같이 본 발명은 모든 컴퓨팅 장치에 적용될 수 있고, 이 장치와 관련하여 신뢰된 소스로부터의 콘텐츠를 처리, 저장, 또는 보안 제공하는 것이 바람직하다.

통신 네트워크/버스(14)가 인터넷인 네트워크 환경에서, 서버(10)는 클라이언트(110a, 110b, 110c, 110d, 110e 등)가 HTTP와 같은 다수의 기존의 프로토콜 중 어떤 프로토콜을 통해 통신하는 웹 서버일 수 있다. 서버(10)는 또한 클라이언트(110)의 역할을 할 수 있으며, 이는 분산 컴퓨팅 환경의 특성일 수 있다. 통신은 적절하다면 유선 또는 무선일 수 있다. 클라이언트 장치(110)는 통신 네트워크/버스(14)를 통해 통신할 수 있거나 통신할 수 없으며, 그것과 연관된 독립된 통신을 가질 수 있다. 예컨대, TV 또는 VCR의 경우에, 그 제어에 대한 네트워크 측면이 있을 수 있거나 없을 수 있다. 각각의 클라이언트 컴퓨터(110) 및 서버 컴퓨터(10)에는 각종 애플리케이션 프로그램 모듈 또는 오브젝트(135)가 구비될 수 있고, 각종 종류의 기억 요소 또는 오브젝트에의 접속 또는 액세스가 구비되어 있으며, 이를 통해 파일이 저장되고 파일의 부분(들)이 그곳으로 다운로드 또는 이동될 수 있다. 따라서, 본 발명은 컴퓨터 네트워크/버스(14)에 액세스할 수 있고 그것과 상호 작용할 수 있는 클라이언트 컴퓨터(110a, 11ob 등), 그리고 클라이언트 컴퓨터(110a, 110b 등), 다른 장치(111) 및 데이터베이스(20)와 상호 작용할 수 있는 서버 컴퓨터(10a, 10b 등)를 가진 컴퓨터 네트워크 환경에서 사용될 수 있다.

디지털 콘텐츠 권리 관리(DRM) 개요

알려진 바와 같이, 그리고 이제 도 11을 참조하면, 디지털 콘텐츠 권리 관리(DRM) 및 시행은 디지털 오디오, 디지털 비디오, 디지털 텍스트, 디지털 데이터, 디지털 멀티미디어 등과 같은 디지털 콘텐츠(12)와 관련하여 매우 바람직하며, 여기서 이와 같은 디지털 콘텐츠(12)는 사용자에게 분배되는 것이다. 사용자에 의해 수신되면, 이와 같은 사용자는 퍼스널 컴퓨터(14) 등에 있는 매체 플레이어와 같은 적절한 공급 장치의 도움으로 디지털 콘텐츠를 실행 또는 '플레이'한다.

일반적으로, 이와 같은 디지털 콘텐츠(12)를 분배하는 콘텐츠 소유권자 또는 개발자(이하, '소유권자')는 사용자가 그와 같이 분배된 디지털 콘텐츠(12)를 가지고 할 수 있는 것을 제한하기를 원한다. 예컨대, 콘텐츠 소유권자는 사용자가 제2 사용자에게 그와 같은 콘텐츠(12)를 카피 및 재분배하지 못하게 하기를 원할 수 있고, 또는 분배된 디지털 콘텐츠(12)가 예컨대 제한된 회수만큼만, 특정의 전체 시간 동안만, 특정 종류의 머신 상에서만, 특정 종류의 매체 플레이어로만, 특정 종류의 사용자에 의해서만 플레이되기를 원할 수 있다.

그러나, 분배가 일어난 후, 그와 같은 콘텐츠 소유권자는 디지털 콘텐츠(12)를 거의 제어할 수 없다. 이때, DRM 시스템(10)은 디지털 콘텐츠(12)의 임의의 형태의 제어된 실행 또는 플레이를 가능하게 하며, 여기서 이와 같은 제어는 융통성이 있고 이와 같은 디지털 콘텐츠의 콘텐츠 소유권자에 의해 한정될 수 있다. 일반적으로, 콘텐츠(12)는 적절한 분배 채널을 통해 패키지(13)의 형태로 사용자에게 분배된다. 분배되는 디지털 콘텐츠 패키지(13)는 대칭적 암호/암호 해제 키(KD)(즉, (KD(CONTENT)))로 암호화된 디지털 콘텐츠(12)뿐만 아니라 콘텐츠를 식별하기 위한 다른 정보, 그와 같은 콘텐츠에 대한 라이센스를 획득하는 법을 알려주는 다른 정보 등을 포함할 수 있다.

신뢰-기반 DRM 시스템(10)은 디지털 콘텐츠(12)의 소유권자가 그와 같은 콘텐츠(12)가 사용자의 컴퓨팅 장치(14) 상에서 실행되는 것이 허용되기 전에 만족되어야 하는 라이센스 규칙을 기입하도록 한다. 이와 같은 라이센스 규칙은 상기 시간 요건을 포함할 수 있으며, 사용자/사용자의 컴퓨팅 장치(14)(이하, 두 용어들은 다른 사정이 없으면 서로 혼용이 가능함)가 콘텐츠 소유권자 또는 그 에이전트로부터 획득하여야 하는 디지털 라이센스 또는 사용 문서(이하, '라이센스')(16) 내에서 구현될 수 있다. 이와 같은 라이센스(16)는 또한 사용자의 컴퓨팅 장치에 의해 암호 해제 가능한 키에 따라 아마도 암호화된 디지털 콘텐츠를 암호 해제하기 위한 암호 해제 키(KD)를 포함한다.

디지털 콘텐츠(12)의 일부분에 대한 콘텐츠 소유권자는, 사용자의 컴퓨팅 장치(14)가 라이센스(16) 내에 그와 같은 콘텐츠 소유권자에 의해 기입되는 규칙 및 요건을 준수한다는 점, 즉 디지털 콘텐츠(12)가 라이센스(16) 내의 규칙 및 요건이 만족되지 않으면 제공되지 않는다는 점을 신뢰할 수 있어야만 한다. 바람직하게, 사용자의 컴퓨팅 장치(14)에는 디지털 콘텐츠(12)와 연계되고 사용자에 의해 획득되는 라이센스(16)내에 구현된 라이센스 규칙을 따르는 경우를 제외하고는 디지털 콘텐츠(12)가 실행되지 않게 하는 신뢰된 구성 요소 또는 메커니즘(18)이 제공된다.

신뢰된 구성 요소(18)는 일반적으로 라이센스(16)가 유효한지를 결정하는 라이센스 평가기(20)를 가지고 있고, 이와 같은 유효 라이센스(16) 내의 라이센스 규칙 및 요건을 검토하고, 검토된 라이센스 규칙 및 요건에 기초하여 요청한 사용자가 특히 추구하는 방식으로 요청된 디지털 콘텐츠(12)를 공급할 권리를 가지고 있는지를 결정한다. 이해되는 바와 같이, 라이센스 평가기(20)는 라이센스(16) 내의규칙 및 요건에 따라 디지털 콘텐츠(12)의 소유권자의 소망을 실현하기 위하여 DRM 시스템(1)내에서 신뢰되며, 사용자는 악의든 그렇지 않든 어떤 목적을 위해 그와 같은 신뢰된 요소를 쉽게 변경할 수 없어야 한다.

이해되는 바와 같이, 라이센스(16) 내의 규칙 및 요건은, 사용자가 누구인지, 사용자가 어디에 위치하는지, 사용자가 무슨 종류의 컴퓨팅 장치를 사용하고 있는지, 어떤 제공 애플리케이션이 DRM 시스템을 호출하고 있는지, 날짜, 시간 등을 포함해서 여러 인자들 중 어떤 인자에 기초하여 사용자가 디지털 콘텐츠(12)를 제공할 권리를 가지고 있는지를 지정할 수 있다. 또한, 라이센스(16)의 규칙 및 요건은 라이센스(16)를 예컨대, 미리 결정된 플레이 회수, 미리 결정된 플레이 시간으로 제한할 수 있다.

상기 규칙 및 요건은 적절한 언어 및 신택스에 따라 라이센스(16) 내에 지정될 수 있다. 예컨대, 언어는 만족되어야 하는 속성 및 값을 간단히 지정할 수 있고(DATE는 예컨대 X보다 늦어야 함), 또는 지정된 스크립트에 따라 기능의 수행을 요구할 수 있다(DATE가 X보다 크면 예컨대, ...를 행함).

라이센스 평가기(20)가, 라이센스(16)가 유효하고 사용자가 규칙 및 요건을 만족하는 것으로 결정할 때, 디지털 콘텐츠(12)가 공급될 수 있다. 특히, 콘텐츠(12)를 제공하기 위해 암호 해제 키(KD)가 라이센스(12)로부터 얻어지고, 콘텐츠 패키지(13)로부터의 (KD(CONTENT))에 적용되어 실제 콘텐츠(12)를 생성하고, 실제 콘텐츠(12)가 실제로 실행된다.

디지털 콘텐츠 발행

도 3은 디지털 콘텐츠를 발행하기 위한 시스템 및 방법의 기능 블록도이다. "발행(publishing)"은, 이 용어가 본 명세서에서 사용되는 바와 같이, 신뢰된 엔터티가 그 콘텐츠에 대해 발행할 수 있을 뿐만 아니라 그 권리 및 조건이 그 엔터티에게 발행될 수 있는 한 세트의 권한 및 조건을 신뢰된 엔터티와 함께 형성하기 위해 애플리케이션 또는 서비스가 따르는 프로세스를 말한다. 본 발명에 따라, 발행 프로세스는 디지털 콘텐츠를 암호화하는 동작, 및 콘텐츠의 저자가 콘텐츠의 잠재적 사용자들 모두에게 의도된 지속적으로 부과할 수 있는 권리들의 목록을 연관시키는 동작을 포함한다. 이 프로세스는 콘텐츠의 저자에 의해 의도되지 않는다면, 권리 중 특정 권리 또는 콘텐츠에의 액세스를 금지시키는 보안 방식으로 실시될 수 있다.

특히, 3 개의 엔터티, 즉 클라이언트(300) 상에서 실행되고 발행을 위해 콘텐츠를 준비하는 콘텐츠 준비 애플리케이션(302), 디지털 콘텐츠 권리 관리(DRM) 애플리케이션 프로그램 인터페이스(API)(306), 인터넷, 근거리 또는 광역 통신 네트워크, 또는 그 조합과 같은 통신 네트워크(330)를 통해 통신 가능하게 연결된 DRM 서버(320)가 안전한 디지털 콘텐츠를 발행하는데 이용된다.

콘텐츠 준비 애플리케이션(302)은 디지털 콘텐츠를 생성하는 애플리케이션들 중 아무 것이나 될 수 있다. 예컨대, 애플리케이션(302)은 워드프로세서, 또는 디지털 텍스트 파일, 디지털 음악, 비디오 또는 다른 그와 같은 콘텐츠를 생성하는 다른 발행자(publisher)일 수 있다. 콘텐츠는 또한, 예컨대 라이브 또는 테이프 이벤트의 스트리밍 오디오/비디오와 같은 스트리밍 콘텐츠를 포함할 수 있다. 애플리케이션(302)에는 디지털 콘텐츠를 암호화하기 위한 암호 키가 제공되고, 따라서 암호화된 디지털 콘텐츠 파일(304)이 형성되며, 사용자는 디지털 콘텐츠 파일(304) 내의 암호화된 콘텐츠와 밀접하게 연관될 권리 데이터를 제공한다. 권리 데이터는 디지털 콘텐츠에서 권리를 가진 각각의 엔터티에 대한 아이덴터티, 및 각각의 식별된 엔터티에 대한 한 세트의 권리 및 조건을 포함한다.

이와 같은 엔터티는 예컨대, 개인, 개인들의 클래스, 또는 장치일 수 있다. 그와 같은 권리는 디지털 콘텐츠를 판독, 편집, 복사, 인쇄 등을 할 권리를 포함할 수 있다. 조건은 시스템의 최소 요건, 날짜 및 시간 제한, 플레이 회수 등을 포함할 수 있다.

클라이언트 API(306)는 암호화된 디지털 콘텐츠 및 권리 데이터를 DRM 서버(320)에 전달한다. 이하에서 상세하게 설명되는 프로세스를 이용하여, DRM 서버(320)는 권리 데이터를 부과할 수 있는지를 결정하고, 부과할 수 있는 경우 DRM 서버(320)는 서명된 권리 표시(SRL)(308)를 형성하기 위해 권리 데이터에 서명한다. 그러나, 일반적으로, 어떤 신뢰된 엔터티는 바람직하게는 DRM 서버(320)에 의해 신뢰된 키를 이용하여 권리 데이터에 서명할 수 있다. 예컨대, 클라이언트는 DRM 서버(320)에 의해 그 클라이언트에 제공된 키를 이용하여 권리 데이터에 서명할 수 있다.

권리 표시(308)는 권리 설명을 나타내는 데이터, 암호화된 콘텐츠 키, 및 권리 설명 및 암호화된 콘텐츠 키에 대한 디지털 서명을 포함할 수 있다. DRM 서버(320)가 권리 표시에 서명한다면, 그 서버는 서명된 권리 표시(308)를 클라이언트 API(306)를 통해 클라이언트에게 다시 전달하며, API는 서명된 권리 표시(308)를 클라이언트 장치(300) 상에 저장한다. 또한, 콘텐츠 준비 애플리케이션(302)은 권리 관리된 콘텐츠 파일(310)을 형성하기 위해 예컨대 연결(concatenation)에 의해, 서명된 권리 표시(308)를 암호화된 디지털 콘텐츠 파일(304)과 연계시킨다. 그러나, SRL(308)는 콘텐츠 파일(310)을 형성하기 위해 콘텐츠 파일(304)로 연결(concatenation)된 SRL(308)로의 참조(reference)를 포함한 상태로, 콘텐츠 파일(304)로부터 분리되었지만 알려져 있는 위치에 저장될 수 있음에 주의하자.

이제, 도 4를 참조하면, 권리가 관리되는 디지털 콘텐츠를 발행하기 위한 한가지 방법이 도시되어 있다. 단계 402에서, 애플리케이션(302)은 디지털 콘텐츠를 암호화하는데 사용되는 콘텐츠 키(CK)를 생성한다. 디지털 콘텐츠를 암호화하는 데에는 어떤 키라도 사용될 수는 있지만 콘텐츠 키(CK)는 일반적으로 대칭 키이다. 알려진 바와 같이, 대칭 키는 암호화 및 암호 해제하는 대칭 키 알고리즘에 의해 이용된다. 따라서, (CK)는 송신자와 수신자 사이에서 공유될 때 잘 은폐되어야 한다.

단계 404에서,애플리케이션(302)은 암호화된 디지털 콘텐츠(304)[즉, (CK(content))]를 형성하기 위해 (CK)로 디지털 콘텐츠를 암호화한다. 또한, (CK(content))에 대응하는 권리 데이터가 콘텐츠 발행기에 의해 또는 다른 엔터티에 의해 생성된다. 그와 같은 권리 데이터는 관습화된 권리 데이터 또는 미리 정의된 템플릿으로부터 얻어지는 권리 데이터일 수 있음에 주의하자. 위에서 설명된바와 같이, 권리 데이터는 콘텐츠, 소비할 권리가 부여되게 되는 엔터티들의 리스트, 엔터티의 각각이 콘텐츠에 대해 소유하는 특정 권리, 및 그 권리에 부과될 수 있는 조건을 포함할 수 있다.

단계 406에서, API(306)는 콘텐츠 키(CK)를 암호화하는데 사용되는 제2 암호화 키(K2)를 생성한다. 바람직하게, (K2)도 대칭 키이다. 단계 408에서, API(306)는 (K2(CK))를 생성하기 위해 (CK)를 (K2)로 암호화한다. 단계 410에서, API(306)는 (CK)를 폐기하며, 그 결과 (CK)는 이제 (K2(CK))를 암호 해제해야만 획득될 수 있게 된다. (CK(content))는 중앙 DRM 서버(320)에 보호되고 콘텐츠에 대한 모든 "라이센스 요청"이 권리 데이터에 따라 중앙에서 행해지는 것을 보장하기 위해, 단계 412에서 API(306)는 제공된 DRM 서버(320)와 접촉하고, 그 공개 키(PU-DRM)를 검색한다. 단계 414에서, API(306)는 (PU-DRM(K2))를 생성하기 위해 (K2)를 (PU-DRM)로 암호화한다. 따라서, DRM 서버(320)가, (CK(content))를 암호 해제하는데 요구되는, (CK)를 액세스할 수 있는 유일한 엔터티인 것을 보장하기 위해, (CK)는 (PU-DRM)로 보호될 수 있다. 단계 416에서, API(306)는 (K2(rightsdata))를 생성하기 위해 권리 데이터(즉, 허가된 엔터티의 리스트, 및 리스트 내의 각각의 허가된 엔터티와 연계된 각각의 권리 및 조건)를 (K2)로 암호화한다.

다른 실시예에서, (CK)는 (CK(rightsdata))를 생성하기 위해 권리 데이터를 직접 암호화하는데 사용될 수 있고, (PU-DRM)는 (PU-DRM(CK))를 생성하기 위해 (CK)를 직접 암호화하는데 사용될 수 있어, (K2)의 사용보다 완전히 앞선다. 그러나, 권리 데이터 및 (CK)를 암호화하는데 (K2)를 사용하면, 그와 같은 (K2)는 DRM서버에 종속될 수 있는 어떤 특정 알고리즘을 따를 수 있지만, (CK)는 DRM 서버와는 독립된 엔터티에 의해 지정될 수 있고 그것에 그다지 종속되지 않을 수 있다.

단계 418에서, 콘텐츠 보호 애플리케이션(302)은 (PU-DRM(K2)) 및 (K2(rightsdata))를 서명을 위한 권리 표시로서 DRM 서버(320)에 제출된다. 또는, 클라이언트 자체는 후술되는 방식으로 권리 데이터에 서명할 수 있다. 권리 데이터가 서명을 위해 서버에 제출되고 있으면, 단계 420에서 DRM 서버(320)는 권리 데이터를 액세스하고, 제출된 권리 표시 내의 권리 및 조건을 부과할 수 있는지 여부를 검증한다. 권리 데이터를 부과할 수 있는지 여부를 검증하기 위해, DRM 서버(320)는 (PU-DRM)에 대응하는 개인 키(PR-DRM)를 (PU-DRM(K2))에 적용하여 (K2)를 얻고, 그 다음에 (K2)를 (K2(rightsdata))에 적용하여, 클리어(clear)에서 권리 데이터를 얻는다. 다음으로, 서버(320)는 권리 데이터에 기입된 사용자, 권리 및 조건이 서버(320)에 의해 부과되는 정책에 부합하는지 여부를 검증하기 위해 정책 체크를 행할 수 있다. 서버(320)는 서명된 권리 표시(SRL)(308)를 생성하기 위해 (PU-DRM(K2)) 및 (K2(rightsdata))를 포함하는 원래 제출된 권리 표시에 서명하고(여기서 서명은 DRM 서버(320)(PR-DRM)의 개인 키에 기초함), 서버(320)는 SRL(308)을 API(306)로 다시 반환하고, API는 반환된 SRL(308)을 클라이언트 애플리케이션(302)에 제공한다.

SRL(308)은 디지털적으로 서명된 문서이며, 이로 인해 탬퍼에 내성적(tamper-resistant)이다. 부가적으로, SRL(308)은 콘텐츠를 암호화하는데 사용되는 실제 키 종류 및 알고리즘에 관계없으나, 보호하고 있는 콘텐츠와 강한일대일 관계를 유지한다. 이제 도 4a를 참조하면, 본 발명의 일실시예에서, SRL(308)은, 아마도 콘텐츠의 ID를 포함하는, SRL(308)의 기초인 콘텐츠에 관한 정보; (PU-DRM(K2)), 및 네트워크 상의 DRM 서버를 찾는 URL 및 URL이 실패하면 폴 백(fall-back) 정보와 같은 참조(referral) 정보를 포함하는, SRL(308)에 서명하는 DRM 서버에 관한 정보; 및 SRL(308) 자체를 설명하는 정보; (K2(rightsdata)): (K2(CK)); 및 디지털 서명(S(PR-DRM))을 포함할 수 있다.

신뢰된 엔터티가 서명된 권리 표시(308)를 생성하기 위해 권리 데이터에 서명하는 것을 보장함으로써, DRM 서버(320)는 권리 표시(308)의 권리 데이터에 기재된 발행자에 의해 기재된 기간에 맞게 콘텐츠에 대한 라이센스를 발행하겠다고 주장하고 있다. 이해되는 바와 같이, 사용자는, 특히 라이센스가 콘텐츠 키(CK)를 포함하는 한, 콘텐츠를 제공하기 위해 라이센스를 획득해야 된다. 사용자가 암호화 콘텐츠에 대한 라이센스를 획득하기를 원할 때, 사용자는 콘텐츠에 대한 SRL(308)를 포함하는 라이센스 요청, 및 사용자의 신용도를 증명하는 증명서를 DRM 서버(320) 또는 다른 라이센스 발행 엔터티에게 제공할 수 있다. 라이센스 발행 엔터티는 권리 데이터를 생성하기 위해 (PU-DRM(K2)) 및 (K2(rightsdata))를 암호 해제할 수 있고, (존재하는 경우) 사용자에 의해 승인된 모든 권리를 라이센스 요청 엔터티에 기입할 수 있으며, 라이센스를 그 특정 권리들만으로 구성할 수 있다.

위에서 설명된 바와 같이, 애플리케이션(302)이 SRL(308)를 수신하면, 그와 같은 애플리케이션(302)은 서명된 권리 표시(308)를 대응 (CK(content))(304)와 연결하여 권리 관리된 디지털 콘텐츠를 형성한다. 또는, 권리 데이터는 알려진 위치에 저장되며, 암호화된 디지털 콘텐츠와 함께 그 위치에 대한 참조가 제공된다. 따라서, DRM이 가능한 실행 애플리케이션은 실행 애플리케이션이 실행하려고 하는 콘텐츠의 일부를 통해 서명된 권리 표시(308)를 발견할 수 있다. 발견하게 되면 실행 애플리케이션은 DRM 라이센싱 서버(320)에 대한 라이센스 요청을 개시한다. 발행 애플리케이션(302)은 예컨대 DRM 라이센싱 서버(320)에 URL을 저장할수 있으며, 또는 DRM 라이센싱 서버(320)는 메타데이터의 일부분으로서 자신의 URL을 권리 표시에 디지털적으로 서명하기 전에 그 권리 표시 내에 내장시킴으로써 제공 애플리케이션에 의해 호출된 DRM 클라이언트 API(306)는 제대로 DRM 라이센싱 서버(320)를 식별할 수 있다.

발행된 콘텐츠에 대한 라이센스 획득

이제 도 5를 참조하면, 권리 관리된 디지털 콘텐츠를 라이센싱하기 위한 시스템 및 방법이 도시되어 있다. "라이센싱"은, 이 용어가 본 명세서에서 사용되는 바와 같이, 라이센스 내에 특정된 엔터티가 라이센스에 기입된 기간에 따라 콘텐츠를 소비할 수 있도록 하는 라이센스를 요청 및 수신하기 위해, 애플리케이션 또는 서비스가 따르는 프로세스를 말한다. 라이센싱 프로세스에의 입력은, 라이센스가 요청되고 있는 콘텐츠에 연계되어 있는 서명된 권리 표시(SRL)(308), 및 라이센스가 요청되고 있는 엔터티(들)의 공개 키 증명서(들)를 포함할 수 있다. 라이센스를 요청하는 엔터티는 반드시 라이센스가 요청되고 있는 엔터티일 필요가 없음에 주의하자. 일반적으로, 라이센스는 SRL(308)로부터의 권리 설명, 암호화된 콘텐츠를 암호 해제할 수 있는 암호화 키, 및 합법성(legitimacy)을 주장하고템퍼링(tampering)을 방지하기 위한 권리 설명 및 암호화 키에 대한 디지털 서명을 포함한다.

예비적으로, 클라이언트 API(306)는 권리 관리된 콘텐츠(310)의 서명된 권리 표시(308)를 통신 네트워크(330)를 통해 DRM 서버(320)로 전송한다. 위에서 설명된 바와 같이, 권리 표시(308)는 DRM 서버(320)의 공개 키(PU-DRM)[즉, (PU-DRM(CK))]에 따라 암호화된 콘텐츠 키(CK)를 포함한다. 다음으로, 라이센스를 발행하는 프로세스에서, DRM 서버(320)는 (CK)를 획득하기 위해 (PR-DRM)를 (PU-DRM(CK))에 적용한다. 이때, 상기 서버는 (CK)[즉, (PU-ENTITY(CK))]를 재암호화하기 위해 라이센스 요청에서 포기된 공개 키 증명서 내의 공개 키(PU-ENTITY)를 사용한다. 다음으로, 새롭게 암호화된 (PU-ENTITY(CK))가 라이센스 내에 위치된다. 따라서, (PU-ENTITY)에 대응하는 개인 키(PR-ENTITY)의 보유자만이 (PU-ENTITY(CK))로부터 (CK)를 복원할 수 있으므로, 라이센스는 (CK)를 노출할 위험없이 호출자에게 반환될 수 있다. 이때, 클라이언트 API(306)는 암호 해제된 디지털 콘텐츠(312)를 형성하기 위해 암호화된 콘텐츠를 암호 해제하는데 (CK)를 사용한다. 다음으로, 클라이언트 애플리케이션(302)은 라이센스 내에 제공된 권리에 따라, 암호 해제된 디지털 콘텐츠(312)를 사용할 수 있다.

또는, 보다 상세하게 후술되는 바와 같이, 발행 클라이언트와 같은 클라이언트는 예컨대 콘텐츠를 소비하기 위하여 사용 라이센스를 자체적으로 발행할 수 있다.

이제, 도 6a 및 도 6b를 보면, 권리 관리된 디지털 콘텐츠를 라이센싱하기위한 방법이 도시되어 있다. 단계 602에서, DRM 서버(320)와 같은 라이센스 발행 엔터티는 요청된 한 명 이상의 라이센스 소유자의 각각에 대한 공개 키 증명서 또는 아이덴터티를 포함하고 있는 라이센스 요청을 수신한다. 아마도, 아이덴터티가 특정되면, DRM 서버(320)는 디렉토리, 데이터베이스 등으로부터 대응하는 공개 키 증명서를 획득할 수 있다. 라이센스가 한 명의 라이센스 소유자에 대해서만 요청되면, 하나의 증명서 또는 아이덴터티만이 지명된다. 라이센스가 복수의 라이센스 소유자에 대해 요청되면, 증명서 또는 아이덴터티는 각각의 잠재적인 라이센스 소유자에 대해 지명될 수 있다. 단계 604에서, 원하는 경우, 요청 엔터티(즉, 라이센스 요청을 행하는 엔터티)가 인증된다. 단계 606에서는, 다시 필요한 경우, 엔터티가 라이센스를 요청할 수 있는지가 결정된다.

단계 608에서, 발행 엔터티가 공개 키 증명서가 라이센스 요청에 포함되어 있지 않은 것으로 결정하면, 발행 엔터티는 적절한 공개 키 증명서에 대해 디렉토리 서비스 또는 데이터베이스에서 검색을 수행하기 위해 특정된 아이덴터티를 사용한다. 단계 610에서, 증명서가 디렉토리 내에 있는 것으로 발행 엔터티가 결정하면, 단계 612에서, 증명서가 검색된다. 소정의 잠재적인 라이센스 소유자에 대한 증명서가 요청 내에서 또는 디렉토리 내에서 발견될 수 없으면, 라이센스 서버는 그 잠재적인 라이센스 소유자에 대해 라이센스를 생성하지 않으며, 단계 614에서, 에러가 요청 엔터티로 반환된다.

DRM 서버(320)가 적어도 한명의 잠재적인 라이센스 소유자에 대한 공개 키 증명서를 가지고 있다고 가정하면, 단계 616에서, 그와 같은 DRM 서버(320)는 각각의 라이센스 소유자 증명서의 신뢰도가 유효하다고 한다. 유효화되지 않으면, DRM 서버(320)는 라이센스 소유자 증명서의 발행자가 신뢰된 발행자들의 리스트에 없는 것으로 결정한 뒤, 그 요청은 그 라이센스 소유자에 대해 실패하고 에러가 단계 614에서 발생된다. 따라서, 증명서가 신뢰된 발행자에 의해 발행되지 않은 잠재적인 라이센스 소유자는 라이센스를 수신하지 못하게 된다.

부가적으로, DRM 서버(320)는 바람직하게, 신뢰된 발행자 증명서로부터 개별적인 라이센스 공개 키 증명서로 진행하는 증명서 체인 내의 모든 엔터티에 대해 디지털 서명 유효화를 수행한다. 체인 내의 디지털 서명을 유효화하는 프로세스는 잘 알려진 알고리즘이다. 소정의 잠재적인 라이센스 소유자에 대한 공개 키 증명서가 유효화되지 않거나 체인 내의 증명서가 유효화되지 않으면, 잠재적인 라이센스 소유자는 신뢰되지 않으며, 따라서 라이센스는 그 잠재적인 라이센스 소유자에게 발행되지 않는다. 그렇지 않다면, 단계 618에서, 라이센스가 발행될 수 있다. 프로세스는 단계 620에서, 라이센스가 요청된 모든 엔터티가 처리될 때까지 반복된다.

도 6b에 도시된 바와 같이, DRM 서버(320)는 라이센스 요청으로 수신된 서명된 권리 표시(308)를 유효화하기 위해 진행한다. 일실시예에서, DRM 서버(320)는 서명된 권리 표시들 하나 하나의 마스터 카피를 가지고 있다. 라이센스 시간에서(단계 622), DRM 서버(320)는 마스터 권리 표시의 카피를 검색할 수 있다. 마스터 권리 표시는 라이센스 요청으로 전송된 권리 표시의 카피보다 최신일 수 있고, 따라서 요청된 라이센스를 생성하는데 이용되는 권리 표시가 되게 된다. 마스터 권리 표시가 발견되지 않으면, DRM 서버(320)는 단계 624에서,요청 내의 권리 표시에 기초하여 라이센스를 발행할지를 미리 정의된 정책에 따라 결정한다. 정책이 허용하지 않으면, 라이센스 요청은 단계 626에서 실패하고, 에러가 단계 628에서 API(306)로 반환된다.

단계 630에서, DRM 서버(320)는 SRL(308) 및 구체적으로는 그 디지털 서명을 유효화한다. SRL(308)이 유효화되지 않으면, 라이센스 요청은 단계 626에서 실패하고, 에러가 단계 628에서 API(306)으로 반환된다.

모든 유효화가 일어난 후, DRM 서버는 SRL(308)에 기초하여 각각의 승인된 라이센스에 대해 라이센스를 구성한다. 단계 632에서, DRM 서버(320)는 라이센스가 각각의 라이센스 소유자에게 발행되도록 각각의 권리 설명을 생성한다. 각각의 라이센스 소유자에 대해, DRM 서버(320)는 그 라이센스 소유자의 공개 키 증명서에서 거명된 아이덴터티를 권리 표시 내의 권리 설명에서 거명된 아이덴터티와 대조하여 평가한다. 단계 636에서, DRM 서버(320)는 SRL(308)로부터 (PU-DRM(K2)) 및 (K2(CK))를 획득하고, (PR-DRM)을 적용하여 (CK)를 획득한다. 다음으로, 발행 엔터티는 라이센스 소유자의 공개 키 증명서로부터의 (PU-ENTITY)를 사용하여 (CK)를 다시 암호화하여 (PU-ENTITY(CK))를 생성한다. 단계 638에서, DRM 서버(320)는 발생된 권리 설명을 (PU-ENTITY(CK))과 연결하고, (PR-DRM)[즉, S(PR-DRM)]를 사용하여 결과적인 데이터 구조에 디지털적으로 서명한다. 따라서, 서명된 데이터 구조가 이 특정 라이센스 소유자에 대한 라이센스가 된다.

단계 640에서, DRM 서버(320)는 특정 요청에 대해 생성시킬 더 이상의 라이센스가 없다고 결정한다. 다음으로, 발생된 라이센스는 단계 642에서 신뢰된 인가(authority)로 연결되는 적절한 증명서 체인과 함께 라이센스를 요청 엔터티로 반환된다.

서명된 권리 표시(308)의 자체 발행

본 발명의 일실시예에서, SRL(308)은 요청/발행 사용자 자체에 의해 서명될 수 있다. 따라서, 그와 같은 사용자는 콘텐츠의 연계된 부분에 대한 SRL(308)을 획득하기 위해 DRM 서버(320)와 접촉할 필요가 없다. 결과적으로 자체 발행도 또한 오프 라인 발행으로 불릴 수 있다. 그와 같은 실시예에서, 특히 자체 발행된 콘텐츠가 이제 DRM 보호되고 발행 사용자가 지금 보호된 콘텐츠를 실행하게 하는데 그와 같은 발행자 라이센스가 필요한 이상, 발행 사용자는 발행자 라이센스를 자체적으로 발생할 수 있어야 한다. 또한, 발행 사용자는 라이센스를 다른 사용자에게 발행하는 것도 가능할 수 있다는 점 역시 이해되어야만 한다.

특히, 이제 도 7를 참조하면, 이 실시예에서, (PU-ENTITY(PR-CERT))를 생성하기 위해 사용자 (PU-ENTITY)의 신뢰된 구성 요소(18)(도 11)에 직접적으로 또는 간접적으로 액세스 가능한 공개 키에 따라 암호화된 공개 키(PU-OLP) 및 대응 개인 키(PR-OLP)를 포함하고 있는 오프 라인 발행(OLP) 증명서(810)를 DRM 서버(320)로부터 수신함으로써, 오프라인 발행 사용자는 오프라인으로 발행하기 위해 먼저 준비된다. (PU-ENTITY)는 예컨대 신뢰된 구성 요소(18)의 공개 키일 수 있고, 또는 신뢰된 구성 요소(18)의 공개 키를 통해 액세스 가능한 사용자의 공개 키일 수 있음에 주의하자. OLP 증명서(810)가 DRM 서버(320)의 개인 키(PR-DRM)에 의해 서명되어야만 그와 같은 DRM 서버(320)는 그와 같은 OLP 증명서를 증명할 수 있게 되는데, 이 점은 뒤에서 보다 상세히 설명될 것이다.

또한, OLP 증명서(810)가 (PU-DRM)로부터 발행 사용자 또는 다른 사용자의 신뢰된 구성 요소(18)에 의해 신뢰된 인가(authority)까지의 증명서 체인을 포함해야만, 신뢰된 구성 요소(18)가 그와 같은 OLP 증명서(810) 및 그와 같은 OLP 증명서(810)와 연관된 다른 증명서 또는 라이센스를 검증할 수 있게 되는데, 이점은 뒤에서 보다 상세히 설명될 것이다. 간단히 말해서, 이해되는 바와 같이, 증명서의 체인이, 신뢰된 인가(authority)의 개인 키에 의해 서명되고 체인 내의 다음 증명서의 공개 키를 가진 루트 증명서로 시작된다. 다음으로, 체인 내의 각각의 중간 증명서는 체인 내의 이전 증명서의 공개 키에 대응하는 개인 키에 의해 서명되고, 체인 내의 다음 증명서의 공개 키를 갖는다. 마지막으로, 체인이 첨부되는 증명서 또는 라이센스는 체인 내의 최종 증명서의 공개 키에 대응하는 개인 키에 의해 서명된다.

따라서, 체인이 첨부된 증명서 또는 라이센스를 검증하기 위해, 신뢰된 인가(authority)의 개인 키에 대응하는 공개 키의 정보가 얻어지고, 신뢰된 인가(authority)의 그와 같은 공개 키가 체인 내의 루트 증명서의 서명을 검증하는데 이용된다. 루트 증명서 서명이 검증되면, 루트 증명서로부터의 공개 키가 얻어지고, 체인 내의 제1 중간 증명서의 서명을 검증하는데 이용된다. 이 프로세스는 모든 서명이 검증될 때까지 체인을 통해 연속적으로 반복되고, 그 다음에 체인 내의 마지막 중간 증명서로부터의 공개 키가 얻어지고, 체인이 첨부된 증명서 또는라이센스를 검증하는데 이용된다.

이해되는 바와 같이, OLP 증명서(810)는 오프 라인으로 발행되어야 하는 콘텐츠(304)와 콘텐츠(304)에 대해 라이센스를 생성하는 DRM 서버(320)간의 신뢰 체인 상의 링크를 생성한다. OLP 증명서(810)는 XML/XrML 언어 또는 다른 적합한 언어에 기초하여 생성될 수 있다.

또한, 이해되는 바와 같이, OLP 증명서(810) 및 첨부된 증명서 체인은 자체 발행할 발행 사용자를 인정(authorizing)한다. 또한, 이해될 수 있는 바와 같이, 키 쌍(PU-OLP, PR-OLP)은 (PU-ENTITY, PR-ENTITY)로부터 분리되고 자체 발행을 위해 구체적으로 이용된다. 키 쌍(PU-OLP, PR-OLP)은 없을 수도 있으며, 이 경우에 DRM 증명서(810)는 사용자의 공개 키 (PU-ENTITY)만을 포함하고, DRM 서버(320)의 개인 키(PR-DRM)에 의해 서명되어 그와 같은 DRM 서버(320)가 그것을 검증할 수 있게 된다는 점에 주의하자.

자체 발행은 본래 DRM 서버(320)에 의해 수행되는 단계들과 관련하여 사용자가 DRM 서버(320)를 대신한다는 점에서 도 4에 도시된 발행과는 다르다. 중요하게는, (PU-DRM(K2)) 및 (K2(rightsdata))를 포함하거나 (PU-DRM(CK)) 및 (CK(rightsdata))를 포함하는(후자는 도 7 및 도 8에 도시됨) 제출된 권리 표시에, 사용자는 DRM 증명서(810)로부터 얻어진 (PR-OLP)[즉, S(PR-OLP)]로 서명하여, 서명된 권리 표시(SRL)(308)를 생성한다. 일반적으로 OLP 증명서(810)를 사용할 때 신뢰된 구성 요소(18) 클라이언트는 부착된 증명서 체인에 기초하여 이를 증명한다. 이해되는 바와 같이, 사용자의 신뢰된 구성 요소(18)는 그와 같은 OLP증명서(810)로부터 (PU-ENTITY(PR-OLP))를 획득하고 (PR-ENTITY)를 이에 적용함으로써 OLP 증명서(810)로부터 (PR-OLP)를 획득한다. 그러나, 발행 사용자는 DRM 서버(320)가 자체 발행된 SRL(308) 내 이 권리들을 부과할 수 있는지 여부를 검증할 수 없다는 점에 주의하자. 따라서, DRM 서버(320) 자체는, 라이센스가 자체 발행된 SRL(308)에 기초하여 요청될 때, 검증을 수행해야 한다.

일단 발행 사용자가 SRL(308)을 자체 발행하면, 사용자는 그와 같이 자체 발행된 SRL(308)과 이를 생성하기 위해 이용된 OLP 증명서(810)를 콘텐츠(304)에 연결하며, SRL(308) 및 DRM 증명서(810)를 가진 이와 같은 콘텐츠(304)는 다른 사용자에게 권리 관리된 콘텐츠(310)로서 분배된다. 그 후, 다른 사용자가 도 6a 및 도 6b에 도시된 것과 실질적으로 동일한 방식으로 DRM 서버(320)로부터 콘텐츠(304/310)에 대한 라이센스를 요청하고 획득한다. 그러나, 여기서, 라이센스를 요청한 사용자는 상기 콘텐츠(304)에 연결(concatenation)된 자체 발행된 SRL(308) 및 OLP 증명서(810) 양자를 DRM 서버(320)에 제출한다. 다음으로, DRM 서버(320)는 대응하는 (PU-DRM)에 기초하여 OLP 증명서(810) 내의 S(PR-DRM)를 검증하고, DRM 증명서(810)로부터 (PU-OLP)를 획득한다. DRM 서버(320)는 획득된 (PU-CERT)에 기초하여 SRL(308) 내의 S(PR-OLP)를 검증하고 이전과 같이 계속한다. 그러나, 발행 사용자는 DRM 서버(320)가 SRL(308) 내의 권리들을 부과할 수 있는지 여부를 검증하지 못하였으므로, 위에서 설명된 바와 같이, DRM 서버(320) 자체는 이때 검증을 수행해야만 한다는 점에 주의하자.

역시, DRM 서버(320)는 아마도 자신을 신뢰하므로 OLP 증명서(810) 내의S(PR-DRM)를 검증하기만 하면 된다는 점에 주의하자. 따라서, OLP 증명서(810)로부터의 연관된 증명서 체인은, 물론 체인이 달리 필요하지 않다면, 예컨대 체인 자체가 적어도 부분적으로 S(PR-DRM)에 대한 기초가 되면, 그와 같은 OLP 증명서(810)와 함께 DRM 서버(320)에 반드시 전송될 필요는 없다.

그러나, 중요한 점은, 발행 사용자가 라이센스를 위해 DRM 서버(320)로 갈 필요없이 지금 보호되고 있는 콘텐츠(304/310)를 실행할 수 있어야 한다는 점이다. 달리 표현하면, OLP 증명서(810)에 기초한 DRM 서버(320)로 가지 않고 콘텐츠(304/310)를 오프라인으로 발행하는 발행 사용자는 DRM 서버(320)로 진행하지 않고 오프라인 방식으로 라이센스를 자체적으로 발행할 수 있어야만 그와 같은 사용자가 오프라인 발행된 콘텐츠(304/310)를 실행할 수 있게 된다. 따라서, 발행 사용자는 DRM 서버(320)에 접속하지 않고 자체 발행된 콘텐츠(310)를 가지고 계속 작업을 할 수 있다.

본 발명의 일실시예에서, 이제 도 8을 참조하면, 발행 사용자는 (PR-OLP)에 의해 서명되고 자체 발행된 SRL(308)에 기초하는, OLP 증명서(810) 및 그 증명서 체인을 포함하는 오프 라인 발행자 라이센스(820)를 자체적으로 발행한다. 생각컨대, 발행자 라이센스(820)는, 보다 작은 양의 액세스가 승인될 수도 있지만, 자체 발행된 콘텐츠(1210)에 대한 발행 사용자의 전체적인 액세스를 승인한다. 발행자 라이센스(820)는 다른 DRM 라이센스를 가진 경우에서와 같이 XML/XrML 언어 또는 다른 언어로 작성될 수 있다. 이해되는 바와 같이, 발행자 라이센스(820)는 (PU-ENTITY(CK))를 형성하기 위해 사용자의 컴퓨팅 장치(14)의 신뢰된 구성 요소(18)에의해 획득될 수 있는 (PU-ENTITY)에 따라 암호화되는 콘텐츠 키(CK)를 포함한다.

따라서, 발행자 라이센스(820)의 체인은 아마도 하나 이상의 중간 증명서를 통해 그와 같은 라이센스(820)로부터 OLP 증명서(810)로 그리고는 다시 신뢰된 인가(authority)로부터 루트 증명서로 진행한다. 사용자의 신뢰된 구성 요소(18)는 생각컨대 루트 증명서에 서명하는데 이용된 신뢰된 인가(authority)의 개인 키에 대응하는 공개 키를 획득할 수 있으므로, 신뢰된 구성 요소(18)는 자체적으로 그 증명서 체인을 통해 발행자 라이센스(820)를 검증할 수 있고, 검증시 그로부터 (PU-ENTITY(CK))를 획득할 수 있고 (PR-ENTITY)를 적용하여 (CK)를 획득할 수 있고, (CK)를 (CK(content))에 적용하여 실행하기 위한 콘텐츠(304)를 생성할 수 있다. 그 결과, 발행중인 사용자는 오프라인으로 남아 있으면서 오프라인으로 발행된 콘텐츠(310)를 가지고 작업을 계속할 수 있다.

상기한 바에 따라, 이제 도 9를 참조하면, 발행 사용자는 콘텐츠(304/310)를 오프라인 발행하고, 다음의 방식으로 그와 같은 콘텐츠(304/310)에 대해 오프 라인 발행자 라이센스(820)를 자체적으로 발행한다.

예비적으로, 이해되는 바와 같이, 콘텐츠(304)는 적절한 방식으로 개발되고 콘텐츠 키(CK)에 따라 암호화되고(단계 901), 발행 사용자는 적절한 정보{예컨대, (PU-DRM(CK)) 및 (CK(rightsdata))}를 가지고 콘텐츠(304)에 대한 권리 표시를 생성한다. 그 후, DRM 서버(320)로부터의 OLP 증명서(810)를 생각컨대 이미 소유하고 있는 발행 사용자는 그와 같은 OLP 증명서(810)를 획득하고(단계 905), 그 증명서를 루트 인가(root authority)로 다시 연결되는 증명서 체인들과 그 서명에 기초하여 검증한다(단계 907). 이해되는 바와 같이, 그와 같은 검증은 실제로 발행 사용자의 컴퓨팅 장치(14) 상의 신뢰된 구성 요소(18)에 의해 수행된다. 검증이 성공적이라고 가정하면, 발행 사용자/신뢰된 구성 요소(18)(이하, "발행 사용자")는 OLP 증명서(810)로부터 (PU-ENTITY(PR-OLP))를 검색하고(단계 909), (PR-ENTITY)를 (PU-ENITY(PR-OLP))에 적용하여 (PR-OLP)를 얻고(단계 911), 다음으로 생성된 권리 표시에 그와 같은 (PR-OLP)로 서명하여 SRL(308)을 생성한다(단계 913).

그후, 발행 사용자는 그와 같은 SRL(308) 및 이 SRL를 생성하는데 이용된 OLP 증명서(81)를 콘텐츠(304)에 연결하여 자체 발생 콘텐츠(310)를 형성하고(단계 915), 따라서 그와 같이 권리 관리된 콘텐츠(310)는 다른 사용자에게 분배될 수 있다. 그러나, 발행 사용자가 콘텐츠(310)를 계속 사용하거나 제공하기 위해, 그와 같은 발행 사용자는 대응하는 오프라인 발행자 라이센스(820)를 자체적으로 발행해야 한다.

따라서, 발행 사용자는 적절한 권리 데이터를 자체적으로 정의하고, (CK(rightsdata))를 발생하기 위해 콘텐츠 키(CK)에 따라 권리 데이터를 암호화함으로써 발행자 라이센스(820)를 생성한다. 여기서, 이와 같은 권리 데이터는 콘텐츠(310)로부터의 SRL(308)로부터 획득될 수 있거나, 자체 발행된 콘텐츠(310)에의 발행 사용자의 부분적 또는 전체적 액세스를 승인하는 어떤 디폴트 세트의 권리 데이터일 수 있거나, 다른 소스로부터 도출될 수 있음에 주의하자. 또한, 발행 사용자는 (PU-ENTITY)에 따라 콘텐츠 키(CK)를 암호화하여 (PU-ENTITY(CK))를 형성한다(단계 919). 다음으로, 이와 같은 (CK(rightsdata)) 및 (PU-ENTITY(CK))는 발행자 라이센스(820)로 포매팅되고(단계 921), OLP 증명서(810) 및 그 증명서의 체인이 첨부되며(단계 923), 그와 같은 발행자 라이센스(820)는 단계 911에서 얻어진 (PR-OLP)에 기초하여 서명된다(단계 925). 여기서, 콘텐츠(304)[즉, (CK(content))], 발행 라이센스(820), 및 OLP 증명서의 조합이 신뢰된 인가(authority)까지의 디지털 아이템의 체인(830)을 형성함에 주의한다.

발행 사용자가 발행된 콘텐츠(310)를 실행하기 위해, 이제 도 10을 참조하면, 그와 같은 발행 사용자는 DRM 서버(320)와 접촉할 필요가 없으나, 대신에 루트 증명서에 서명하기 위해 이용되었던 신뢰된 허가의 개인 키에 대응하는 공개 키를 획득하고(단계 1001), 루트 증명서를 검증하며(단계 1003), 다음으로 각각의 그와 같은 중간 증명서에 대해 이전 증명서로부터 공개 키를 획득하고 그와 같은 증명서의 서명을 검증하기 위해 그것을 이용함으로써 체인 내의 각각의 중간 증명서를 검증한다(단계 1005). 그후, 체인 내의 최종 증명서로부터의 (PU-DRM)이 OLP 증명서(810)[즉, S(PR-DRM)]의 서명을 검증하는 데에 이용되며(단계 1007), (PU-OLP)는 OLP 증명서(810)로부터 획득되고(단계 1009), 그와 같은 (PU-OLP)는 발행자 라이센스(820)[즉, S(PR-OLP)]의 서명을 검증하는 데에 이용된다(단계 1010).

일단 발행자 라이센스(820)가 검증되면, (CK(rightsdata)) 및 (PU-ENTITY(CK))가 라이센스로부터 검색되고(단계 1011), (PR-ENTITY)가 (PU-ENTITY(CK))에 적용되어 (CK)가 생성되고(단계 1013), (CK)가 (CK(rightsdata))에 적용되어 권리 데이터가 생성된다. 이제 이해되는 바와 같이, 그와 같은 권리 데이터를 추구되는 방식으로 실행되는 것이 허락되는지 여부를 결정하기 위해 권리데이터는 발행 사용자의 컴퓨팅 장치(14)의 신뢰된 구성 요소(18)에 의해 리뷰되고(단계 1017), 따라서 이와 같은 신뢰된 구성 요소(18)는 (CK)를 콘텐츠(310)로부터의 (CK(content))에 적용하여 콘텐츠를 생성하고(단계 1019), 그와 같은 콘텐츠는 실제 실행을 위해 적절한 실행 애플리케이션에 전송된다(단계 1021). 따라서, 도 10의 단계들은 사실상 신뢰된 인가(authority)로부터 콘텐츠(304)로의 디지털 아이템의 체인(830)을 가로지른다.

신뢰된 구성 요소(18)는 생각컨대, 권리 데이터를 먼저 리뷰하지 않고 그리고 어떤 권리 데이터가 허용될 수 있거나 허용될 수 없는지에 관계 없이 콘텐츠를 생성하기 위해 (CK)를 (CK(content))에 적용할 수 있으나, 이는 신뢰받으며, 그리고 권리 데이터를 리뷰하고 그리고 권리 데이터가 그와 같은 콘텐츠의 제공을 가능하게 한다는 것을 자체적으로 만족시킨 후에만 사실상 콘텐츠를 생성하도록 구성되어 있음에 주의하자. 다시 한번, 발행자 라이센스(820)를 가진 결과로서, 발행 사용자는 DRM 서버(320)가 접촉될 필요가 없는 한 오프라인을 유지하면서 오프라인으로 발행되는 콘텐츠(310)로 계속 작업을 한다.

DRM 서버의 등록 및 부등록

도 3에 도시된 아키텍처에서는, 단일 DRM 서버(320)만이 도시되어 있다. 그러나, 이해될 수 있는 바와 같이, 그와 같은 아키텍처는 다수의 DRM 서버(320)를 포함할 수 있다. 특히, 본 발명의 일실시예에서, 그와 같은 아키텍처는 DRM 서버(320)의 분산 네트워크를 포함하고 있다. 그와 같은 DRM 서버(320)의 각각은 어떤 특정 기능을 가질 수 있고, 본 발명의 사상 및 범위로부터 이탈하지 않고 적절한 방식으로 구성될 수 있다.

예컨대, 이제 도 12로 돌아가서, 특정 조직은 SRL(308)을 생성하기 위해 권리 표시에 서명하고, 라이센스(16)를 발행하고, 발행자 라이센스(820)를 승인하고, 컴퓨팅 장치(14)에 증명서를 발생할 목적으로 하나 이상의 사용자 레벨 DRM 서버(320)를 가질 수 있다. 각각의 그와 같은 사용자 레벨 DRM 서버(320)는 지리적으로 할당될 수 있고, 또는 예컨대 기능 또는 부하에 기초하여 할당될 수도 있다. 유사하게, 다수의 사용자 레벨 DRM 서버(320)를 감시하기 위해, 조직은 하나 이상의 관리 DRM 서버(320)를 가질 수 있다. 이와 같은 조직-기반 DRM 서버(320)는 원한다면 조직 방화벽 뒤에 위치될 수 있다.

조직-기반 DRM 서버(320) 외에, 간조직(間組織; inter-organization) DRM 기능을 수월하게 하는 초조직(超組織; trans-organization) DRM 서버(320)가 있을 수도 있다. 예컨대, 그와 같은 초조직 DRM 서버(320)는 한 쌍의 조직들이 특정 DRM 콘텐츠(12)를 공유할 수 있게 한다. 또한, 모든 다른 DRM 서버들(320)을 가능하게 하는 감시자 DRM 서버들(320)의 네트워크가 있을 수도 있다. 예컨대, 그와 같은 감시자 DRM 서버들(320)은 모든 다른 DRM 서버들(320)을 감시 및 유지할 수 있고, 앞서 설명된 증명서 체인에 대한 기초인 루트 또는 신뢰된 인가(authority)로 모든 다른 DRM 서버(320)가 연결될 수 있는 적절한 링크를 제공한다. 그와 같은 비조직(非組織)-기반 DRM 서버들(320)은 조직의 방화벽 뒤에 보통 위치하지 않는다.

중요한 점은, 도 12의 아키텍처의 각각의 DRM 서버(320)는 자신이 신뢰됨을증명할 수 있어야 한다는 점이다. 따라서 이제 상기한 증명서 체인에 대한 설명으로부터 이해되는 바와 같이, 각각의 DRM 서버(320)에는 아키텍처에 들어갈 때 도 13으로부터 알 수 있는 바와 같이 등록 증명서(1310)가 제공된다. 중요하게는, 본 발명의 일실시예에서, 등록 증명서(1310)는 아키텍처 내의 이미 다른 '등록' DRM 서버(320)(이하, "DRM-R 서버(320)")에 의해 신입 DRM 서버(320)(이하, "DRM-E 서버(320)")에 제공된다. 또한, 중요하게는, 등록 DRM 서버(320)의 등록 증명서(1310), 등록 DRM-R 서버(320)를 등록한 DRM 서버(320)의 등록 증명서(1310) 등을 포함하는 루트 DRM 서버(320)까지 거슬러 올라가는 증명서 체인(1320)이 등록 DRM-R 서버(320)로부터 제공된 등록 증명서(1310)에 첨부된다. 그와 같은 루트 DRM 서버(320)는 루트 또는 신뢰된 인가(authority)를 나타낼 수 있거나, 또는 증명서 체인(1320)은 루트 또는 신뢰된 인가(authority)에 도달하기 위해 확장될 수 있다. 이제 이해되는 바와 같이, 그와 같은 등록 증명서(1310)와 증명서 체인(1320)의 조합은 도 8에 도시된 것과 같이 발행 사용자에 등록 또는 입력된 DRM-E 서버(320)에 의해 제공되는 OLP 증명서(810)에 첨부되는 증명서 체인을 형성한다.

본 발명의 일실시예에서, DRM-R 서버(320)에 의해 DRM-E 서버(320)에 제공된 등록 증명서(1310)는 XrML 1.2 기반 증명서와 같은 형태이다. 이해될 수 있는 바와 같이, 그와 같은 종류의 증명서(1310)는 제3자에 의해 독립적으로 제공되지 않으며, 따라서 그와 같은 종류의 증명서(1310)는 그와 같은 증명서(1310)의 보유자에 대해 제3자에 의한 어떠한 종류의 독립된 보증도 나타내지 않는다.

본 발명의 일실시예에서, 특정 DRM-E 서버(320)가 아키텍처에 등록되는 방법은 등록 DRM-R 서버(320)가 신입 DRM-E 서버(320)를 신뢰할 이유를 알거나 그 이유를 가지고 있는지에 의존한다. 만일 그렇지 않다면, DRM-E 서버(320)는 자신이 신뢰할 만하고 DRM 아키텍처를 따를 것이라는 점을 DRM-R 서버(320)에게 증명해야 한다. 만일 그렇다면, DRM-E 서버(320)는 DRM-R 서버에 신뢰할 만한 지 여부 - 적어도 위와 동일한 정도로는 - 를 증명하도록 요구되어서는 안된다. 따라서, 신뢰하지 못하는/인식하지 못한 DRM-R 서버(320)는 DRM-E 서버(320)를 "등록"하고 인식하는/신뢰하는 DRM-R 서버(320)는 DRM-E 서버(320)를 "부등록"(sub-enrolling)한다.

전형적으로, DRM-R 서버(320)는, 인식/신뢰가 본 발명의 사상 및 범위로부터 이탈하지 않고 다른 상황으로부터 생길 수 있지만, 동일 조직에 의해 동작되거나 그 이익을 위해 동작되는 경우에는 DRM-E 서버(320)를 인식/신뢰한다. 따라서, 특정 DRM-E 서버(320)가 아키텍처에 등록되는 방법은 일반적으로 등록 DRM-R 서버(320)가 조직 기반인지 아니면 비조직 기반인지에 의존한다. 결과적으로, 비조직 기반의 DRM-R 서버(320)는 DRM-E 서버(320)를 등록하나, 조직 기반의 DRM-R 서버(320)는 DRM-E 서버(320)를 부등록한다.

등록

본 발명의 일실시예에서, 그리고 이제 도 14를 참조하면, 인식하지 못하는/신뢰하지 못하는 DRM-R 서버(320)는 DRM-E 서버(320)를 다음의 방식으로 등록한다.

예비적으로, 상기 인식하지 못하는/신뢰하지 못하는 DRM-R 서버(320)에 의해 등록되기를 원하는 DRM-E 서버(320)가 그와 같은 DRM-R 서버(320)에게 알려지지 않았음을 이해해야 한다. 따라서, 본 발명의 일실시예에서, 상기 DRM-E 서버(320)는 그와 같은 DRM-E 서버(320)를 기꺼이 보증하는 제3자로부터 보증 증명서(1330)를 획득해야 한다(단계 1401). 전형적으로, 이와 같은 제3자는 예컨대 미국 캘리포니아 마운틴 뷰의 VERISIGN 코포레이션과 같이 그와 같은 보증을 수행하기 위해 상기 DRM-R 서버(320)에 의해 신뢰된 독립된 증명서-발행 에이전트이다. 이와 같은 보증 증명서(1330)는 예컨대 X.509 증명서와 같은 형태일 수 있다. 상기 DRM-E 서버(320)를 보증하는 신뢰된 제3자에 의존하는 상기 DRM-R 서버(320)에서는, 상기 DRM-E 서버(320)의 어떤 나쁜 행동에 대한 그와 같은 DRM-R 서버(320)의 부담이 완화된다는 점에 주의하자.

이해되는 바와 같이 그리고 일반적으로 그러한 것처럼, 또한 도 13에서 알 수 있는 바와 같이, 보증 증명서(1330)는 공개 키(PU-V)와 대응하는 개인 키(PR-V)를 포함하며, 신뢰된 제3자에 의해 서명되고, 유효성 검증용의 알려진 루트로 연결되는 증명서 체인을 수반할 수 있다. 또한, 일반적으로 그러한 것처럼, 보증 증명서(1330) 내의 (PR-V)는 상기 보증 증명서(1330)의 기초인 보증 DRM-E 서버(320)에 액세스 가능한 방식으로 보호된다. 예컨대 그리고 도 13에서 알 수 있는 바와 같이,(PR-V)는 적절한 공개 키에 따라 암호화될 수 있다.

DRM 아키텍처 내에서, 신입 DRM-E 서버(320)는 고유 아이덴터티를 가지고 있어야 한다. 여기서, DRM 아이덴터티는 본 발명의 사상 및 범위로부터 이탈하지 않고 (PU-V, PR-V)와 일치할 수도 있지만, DRM 아이덴터티는 그와 같은 (PU-V, PR-V)과는 별개인 것음을 이해해야 한다. 따라서, 그와 같은 아이덴터티를 형성하기위해, 그와 같은 DRM-E 서버(320)는 새로운 공개/개인 키 쌍 (PU-E, PR-E)을 생성 또는 획득한다(단계 1403). 또한, DRM 아키텍처 내에서, 등록 DRM-E 서버(320)는 어떤 엔터티가 참여하려는 것의 인가를 취소할 수 있는지를 판단해야 한다. 따라서, 이와 같은 DRM-E 서버(320)는 아마도 자신의 공개 키를 통해 리스트 내의 각각의 그와 같은 취소 엔터티를 식별한다(단계 1405).

DRM-E 서버(320)는 그와 같은 DRM-E 서버가 실제로 단계 1401에서 획득된 보증 증명서(1330)를 소유하고 있음을 등록 DRM-R 서버(320)에 확정할 수 있어야 한다. 따라서, 상기 DRM-E 서버(320)는 소유권 표시로서 (PR-V(PU-E))를 생성하기 위해 (PU-E)를 암호화하는데 보증 증명서(1330)로부터의 (PR-V)를 이용하거나 소유권자 표시로서의 (PU-E)S(PR-V)를 생성하기 위해 (PU-E)에 (PR-V)로 서명한다. 어느 경우에도, (PU-E)를 암호 해제하거나 서명을 검증하는데 (PU-V)를 적용하면 (PR-V)의 소유권, 그에 따라 보증 증명서(1330)가 확정된다.

지금까지, DRM-E 서버(320)는 소유권 표시로서 보증 증명서(1330), (PU-E) 및 (PR-E), 취소 권한 리스트(revoking authority list), 및 (PR-V(PU-E)) 또는 (PU-E)S(PR-V)를 갖고 있다. 다음으로, 등록을 요청하기 위해, 이와 같은 DRM-E 서버(320)는 소유권 표시로서의 보증 증명서(1330), (PU-E), 취소 권한 리스트, 및 (PR-V(PU-E)) 또는 (PU-E)S(PR-V)를 DRM-R 서버(320)에 전송하고(단계 1409), DRM-R 서버(320)는 그와 같이 요청하는 DRM-E 서버(320)의 등록을 진행한다. 요청 또는 그 일부는 (PR-E)에 의해 서명된 증명서의 형태일 수 있음에 주의하자.

특히, DRM-R 서버(320)는 신뢰된 제3자에 의한 서명 및 알려진 루트로 연결하는 증명서 체인에 기초하여 보증 증명서(1330)를 유효화한다(단계 1411). 따라서, DRM-R 서버(320)는 DRM-E 서버(320)가 보증되었음을 확정한다. 또한, DRM-R 서버(320)는 요청으로부터의 (PU-V)를 적용하여 (PU-E)를 암호 해제하거나 서명을 검증함으로써 요청되고 있는 (PR-V)의 소유권, 이에 따른 보증 증명서(1330)를 확정함으로써, 소유권 표시를 검증한다. 또한, 중요하게는, DRM-R 서버(320)는 요청을 받아들일지를 결정하는데 필요한 커스텀 로직(custom logic)을 수행한다(단계 1413). 이와 같은 커스텀 로직은 본 발명의 사상 및 범위으로부터 이탈하지 않는 적절한 로직일 수 있고, 예컨대, DRM-E 서버(320) 및/또는 그 오퍼레이터에 대한 배경 체크, DRM-E 서버(320)가 현재 신뢰된 구성 요소(18) 및/또는 운영 체제 등을 가지고 있는지에 대한 결정, DRM-E 서버(320)가 취소 리스트 또는 다른 감시 리스트 상에 있는지에 대한 결정 등을 포함할 수 있다.

커스텀 로직이 요청이 받아들여지도록 하면 본 발명의 일실시예에서, DRM-R 서버(320)는 DRM-E 서버(320)에 대해 등록 증명서(1310)를 발생한다(단계 1415). 특히, 도 13에 도시된 바와 같이, DRM-R 서버(320)는 등록 증명서(1310) 내에,

- 공개 키(PU-R)와 같은 DRM-R 서버(320)의 식별자;

- (PU-E)와 같은 DRM-E 서버(320)의 식별자;

- 보증 증명서를 생성한 신뢰된 제3자, 보증 증명서(1330)로부터의 일련 번호, 및 보증 증명서(1330) 내의 식별된 발행자를 포함하는 보증 증명서(1330)로부터의 식별 표시;

- 예컨대 데이터 범위와 같이, 등록 증명서(1310)가 유효한 범위를 지정하는 유효 범위 정보;

- 취소 권한 리스트;

- (PU-R)에 대응하는 DRM-R 서버(320)의 개인 키(PR-R)에 기초한 서명;

- 기타 다른 적절한 정보

를 포함한다.

이와 같은 다른 적절한 정보는 증명서가 발행된 시간, 등록된 서버가 수행하도록 허가된 DRM 활동들의 종류 표시(예컨대, "모든 활동 수행가능", "활성화 설명만 가능", "권리 표시들에 서명하기만 가능", "콘텐츠 라이센의 발행만 가능" 또는 이들의 조합으로 표시된다), 및 DRM 활동을 수행하기 위한 허용된 시간 범위를 포함할 수 있으나 이에 한정되지 않는다. 허용된 시간 범위는 현재 시간이 증명서 체인 내에 등록 증명서(1310)를 포함하는 어떤 증명서를 받아들이기 위해 유효 범위 내에 있어야 한다는 점에서 유효 범위와 다르다는 사실에 주의하자. 대조적으로, 자(child) 증명서의 발행 시간은 DRM 활동을 수행하기 위해 모(parent) 증명서의 허용된 시간 범위 내에 속해야 한다.

이해되는 바와 같이, 등록 증명서(1310)를 생성할 때, DRM-R 서버(320)는 초기에 증명서 정보를 생성할 수 있고 그 다음에 커스텀 로직이 부가 정보를 생성하거나 기존의 정보를 수정하도록 할 수 있다. 이와 같은 커스텀 로직은 예컨대 DRM-R 서버(320)가 적절한 정보를 포함하는 것을 보장하거나, 또는 미리 정의된 DRM 아키텍처 정책을 부과할 수도 있다. 물론, 등록 증명서(1310)의 서명은 그와 같은 커스텀 로직이 수행된 후에 생성된다. 또한, 이해되는 바와 같이, DRM-R 서버(320)는 발생된 등록 증명서(1310)에, 신뢰된 루트 인가(authority)로 다시 연결되는 증명서 체인(1320)을 첨부하여, 발생된 등록 증명서(1310)가 그와 같은 증명서 체인(1320)에 기초하여 유효화될 수 있도록 한다.

특히, 등록 증명서(1310) 내에 위치하는, 보증 증명서(1330)로부터의 식별 표시가 항상 그와 같은 등록 증명서(1310)를 가지고 이동하게 되고 보증 증명서(1330)에의 다리 역할을 한다는 점에 주의하자. 따라서, 다시 한번 이와 같은 식별 표시는 DRM-R 서버(320)가 DRM-E 서버(320)를 보증하기 위해 보증 증명서(1330)의 신뢰된 제3자 발행자에 의존하고 있음을 세상에 보여주며, DRM-E 서버(320)의 어떤 나쁜 행동에 대하여도 그와 같은 DRM-R 서버(320)의 부담이 완화된다.

일단 DRM-R 서버(320)가 첨부된 증명서 체인(1320)을 가지고 등록 증명서(1310)를 성공적으로 발생하였으면, DRM-R 서버(320)는 증명서를 요청한 DRM-E 서버(320)로 반환하고(단계 1417), 이제 등록된 DRM-E 서버(320)는 그 증명서를 장래의 사용을 위해 적절한 위치에 저장한다(단계 1419). 위에서 암시된 바와 같이, 등록 증명서(1310) 내의 (PU-E) 및 대응 (PR-E)는, DRM-E 서버(320)가 SRL(308)을 생성하기 위해 권리 표시에 서명하고, OLP 증명서(810)를 발행하고, 그외에 DRM 아키텍처 내에 참여할 때, (PU-DRM) 및 (PR-DRM)로서 사용하게 되는 공개/개인 키 쌍이다. 따라서, 이와 같은 등록 증명서(1310) 및 증명서 체인(1320)의 조합은 그와 같은 OLP 증명서(810)등에 첨부된 증명서 체인을 형성한다.

부등록

본 발명의 일실시예에서, 이제 도 15를 참조하면, 인식하는/신뢰하는 DRM-R 서버(320)는 다음의 방식으로 DRM-E 서버(320)를 부등록한다.

예비적으로, 인식하는/신뢰하는 DRM-R 서버(320)에 의해 부등록되기를 원하는 DRM-E 서버(320)는, 인식 또는 신뢰가 완전하지 않을 수 있는 한, 여전히 그와 같은 DRM-R 서버(320)에 자신을 인식시키도록 요구된다는 점을 이해해야 한다. 그러나, 이와 같은 신분 증명 요건은, DRM-R 서버(320)가 DRM-E 서버의 어떤 인식/신뢰를 정말로 가지고 있는 한, 신뢰된 제3자에 의해 제공되어야 할만한 수준이 될 필요는 없다. 따라서, 본 발명의 일실시예에서, DRM-E 서버(320)는 DRM-R 서버(320)에 의해 인식가능하고 DRM-R 서버에 의해 받아들여질 것으로 기대되며 DRM-R 서버(320)의 만족시킬만한 수준으로 DRM-E 서버(320)를 식별시켜주는 어떤 종류의 신용 증명서(1340)(도 13)를 획득하거나 그 신용 증명서와 함께 제공된다.

DRM-R 및 DRM-E 서버(320)가 동일 조직 내에 있다면, 그와 같은 신용 증명서(1340)는 예컨대, 두 서버(320)가 공통 네트워크 상에 있으면 네트워크 ID와 같은 조직-기반 신용 증명서일 수 있고, 두 서버(320)가 공통 도메인을 공유하면 도메인 ID일 수 있다. 두 DRM-R 및 DRM-E 서버(320)가 동일 구조 내에 있지 않다면, 그와 같은 신용 증명서(1340)는 두 서버(320)가 공통 네트워크 상에 있으면 여전히 네트워크 ID일 수 있고, 두 서버(320)가 공통 도메인을 공유하면 도메인 ID일 수 있으며, 예컨대 제3자에 의해 발행되고 DRM-R 서버(320)에 의해 인식되는 신용 증명서와 같은 다른 신용 증명서일 수도 있다.

현재 상황에서, DRM-R 서버(320)는 DRM-E 서버(320)를 보증하는데 신뢰된 제3자를 의존하지 않으며, 따라서 DRM-E 서버(320)의 어떤 나쁜 행동에 대한 그와 같은 DRM-R 서버(320)의 부담은 완화되지 않는다. 그럼에도 불구하고, DRM-R 서버(320)가 실제로는 그와 같은 나쁜 행동을 수행하지 않을 거라는 DRM-E 서버(320)에 대한 인식 또는 신뢰에 기초하여 그와 같은 위험을 기꺼히 감수하게 될 것이다.

위에서와 같이, DRM 아키텍처 내에서, 신입 DRM-E 서버(320)는 고유 아이덴터티를 가져야 한다. 여기서, 본 발명의 사상 및 범위로부터 이탈하지 않으면서 DRM 아이덴터티가 신용 증명서와 일치할 수도 있지만, DRM 아이덴터티는 신용 증명서(1340)와 별개임이 이해되어야 한다. 따라서, 그와 같은 아이덴터티를 확정하기 위해, 그와 같은 DRM-E 서버(320)는 새로운 공개/개인 키 쌍(PU-E, PR-E)을 생성 또는 획득한다(단계 1503). 또한, 이전과 같이, DRM 아키텍처 내에서, 부등록 DRM-E 서버(320)는 어떤 엔터티가 참여하려는 것의 인가를 취소할 수 있는지를 판단해야 한다. 따라서, 그와 같은 DRM-E 서버(320)는 아마도 그 공개 키를 통해 리스트 내의 그와 같은 각각의 취소 엔터티를 식별한다(단계 1505).

지금까지, DRM-E 서버(320)는 신용 증명서(1340), (PU-E) 및 (PR-E), 및 취소 권한 리스트를 가지고 있다. 다음으로, 부등록을 요청하기 위해, 그와 같은 DRM-E 서버(320)는 신용 증명서(1340), (PU-E), 및 취소 권한 리스트를 DRM-R 서버(320)에 전송하고(단계 1507), DRM-R 서버(320)는 그와 같이 요청하는 DRM-E 서버(320)를 부등록하기 위해 진행한다. 이전과 같이, 요청 또는 그 일부는 (PR-E)에 의해 서명된 증명서의 형태일 수 있음에 주의하자.

특히, DRM-R 서버(320)는 어떤 로직 또는 자원이 필요하고 그와 같이 유효화하기 위해 이용가능한지에 기초하여 신용 증명서(1340)를 유효화한다(단계 1509). 따라서, DRM-R 서버(320)는 유효화된 신용 증명서(1340)에 기초하여 DRM-E 서버(320)가 DRM 아키텍처를 받아들이고 따르도록 신뢰되어야 한다고 확정하게 된다. 또한, 이전과 같이, DRM-R 서버(320)는 요청을 받아들일지를 판단하는데 필요한 어떤 커스텀 로직을 수행해야 한다(단계 1511).

커스텀 로직이 요청이 받아들여지도록 허락하면, 본 발명의 일실시예에서, DRM-R 서버(320)는 DRM-E 서버(320)에 대한 부등록 증명서(1310)를 발생한다(단계 1513). 특히, 도 13에 도시된 바와 같이, DRM-R 서버(320)는 부등록 증명서(1310) 내에,

- 공개 키(PU-R)와 같은 DRM-R 서버(320)의 식별자;

- (PU-E)와 같은 DRM-E 서버(320)의 식별자;

- 신용 증명서(1340) 또는 그에 대한 참조

- 예컨대 데이터 범위와 같은 부등록 증명서(1310)가 유효한 범위를 지정하는 유효 범위 정보;

- 취소 권한 리스트;

- (PU-R)에 대응하는 DRM-R 서버(320)의 개인 키(PR-R)에 기초한 서명

- 기타 다른 적절한 정보

를 포함한다.

이전과 같이, 부등록 증명서(1310)를 발생할 때, DRM-R 서버(320)는 초기에 증명서 정보를 발생할 수 있고, 그 다음에 커스텀 로직이 부가정보를 발생하거나 또는 기존의 정보를 수정하도록 한다. 또한, 부등록 증명서(1310)의 서명은 그와 같은 커스텀 로직이 수행된 후에 생성된다. 이전과 같이, DRM-R 서버(320)는 발생된 부등록 증명서(1310)에, 신뢰된 루트 인가(authority)로 연결되는 증명서 체인(1320)을 첨부하여, 발생된 부등록 증명서(1310)가 그와 같은 증명서 체인(1320)에 기초하여 유효화될 수 있도록 한다.

여기서, 신용 증명서(1340) 또는 그에 대한 참조는 특별히 필요한 것으로 생각되지 않으나, 그럼에도 불구하고 완전성을 위해 포함될 수 있음에 주의하자. 또한, 보증 증명서가 현재의 부등록 시나리오에서 요구되지 않는 한, 부등록 증명서(1310)는 보증 증명서(1330)로부터의 식별 표시를 포함하지 않음에 주의한다.

일단 DRM-R 서버(320)가 첨부된 증명서 체인(1320)를 가지고 부등록 증명서(1310)를 성공적으로 발생하였으면, DRM-R 서버(320)는 그 증명서 체인을 요청 DRM-E 서버(320)에 반환하고(단계 1515), 이제 부등록된 DRM-E 서버(320)는 그 증명서 체인을 장래의 사용을 위해 적절한 위치에 저장한다(단계 1517). 이전과 같이, 부등록 증명서(1310) 내의 (PU-E) 및 대응 (PR-E)는, DRM-E 서버(320)가 SRL(308)을 생성하기 위해 권리 표시에 서명하고, OLP 증명서(810)를 발행하고, 그 외에 DRM 아키텍처 내에 참여할 때, (PU-DRM) 및 (PR-DRM)로서 사용하는 공개/개인 키 쌍이다. 따라서, 그와 같은 부등록 증명서(1310)와 증명서 체인(1320)의 조합은 그와 같은 OLP 증명서(810) 등에 첨부되는 증명서 체인을 형성한다.

본 발명과 관련하여 수행되는 프로세스를 이루는데 필요한 프로그래밍은 비교적 용이하고 해당 프로그래밍 업계에서 명백하다. 따라서, 그와 같은 프로그래밍은 여기에 첨부되지 않는다. 본 발명의 사상 및 범위로부터 이탈하지 않고 본 발명을 실시하는데 어떤 특정 프로그래밍이 이용될 수도 있다.

본 발명에서, 디지털 콘텐츠 권리 관리(DRM) 및 시행 아키텍처 및 방법은 임의 형태의 디지털 콘텐츠의 제어된 실행 또는 플레이를 가능하게 하며, 여기서 그와 같은 제어는 융통성이 있고 그와 같은 디지털 콘텐츠의 콘텐츠 소유권자/개발자에 의해 정의 가능하다. 아키텍처는 특히 문서가 한정된 그룹의 개인들 또는 등급의 개인들 사이에서 공유되어야 하는 사무실 또는 조직 환경 등에서 그와 같은 제어된 실행을 가능하게 하고 용이하게 한다. 그와 같은 아키텍처는 승인 DRM 서버(320)를 그 아키텍처에 등록/부등록하는 메카니즘을 포함한다.

본 발명의 개념으로부터 이탈하지 않고 위에서 설명된 실시예들이 변경될 수 있음을 이해해야 한다. 예컨대, 라이센스 또는 권리 표시가 내부의 권리 데이터에 기초하여 서명되면, 그와 같은 권리 데이터는 반드시 암호화될 필요가 없다. 마찬가지로, 등록 또는 부등록 증명서(1310)를 요청 및 구성할 때, 취소 권한 리스트 및 다른 유사한 정보는 반드시 사용될 필요는 없다. 그러므로, 본 발명은 공개된 특정 실시예에 한정되지 않으며, 청구의 범위에 의해 정의되는 본 발명의 사상 및 범위 내에서의 변경을 포괄하도록 의도되었음을 이해해야 한다.

Claims

디지털 콘텐츠 권리 관리(DRM) 기능을 수행하는 복수의 DRM 서버를 가진 DRM 시스템과 협력하여, 신입 DRM-E 서버가 등록 DRM-R 서버에 의해 상기 시스템에 등록되도록 하여 상기 신입 DRM-E 서버가 상기 시스템 내에서 신뢰받도록 하는 방법에 있어서,

상기 DRM-E 서버가 상기 DRM 시스템 내에서 그와 같은 DRM-E 서버를 식별하기 위한 공개/개인 키 쌍(PU-E, PR-E)을 획득하는 단계;

상기 DRM-E 서버가 자신의 제공 신원 증명을 획득하는 단계;

상기 DRM-E 서버가 상기 제공 신원 증명 및 (PU-E)를 포함하는 등록 요청을 상기 DRM-R 서버에 전송하는 단계;

상기 DRM-R 서버가 상기 제공 신원 증명을 유효화하는 단계;

상기 요청이 받아들여져야 한다면, 상기 DRM-R 서버가 그와 같은 DRM-E 서버를 상기 DRM 시스템에 등록하기 위해 상기 DRM-E 서버에 대해 적어도 부분적으로 (PU-E)에 기초하는 디지털 등록 증명서를 생성하는 단계;

상기 DRM-R 서버가 상기 발생된 등록 증명서를 요청한 상기 DRM-E 서버로 반환하는 단계; 및

이제 등록된 상기 DRM-E 서버가 장래의 사용을 위해 상기 반환된 등록 증명서를 적절한 위치에 저장하는 단계를 포함하며,

상기 등록 증명서를 가진 상기 DRM-E 서버는 상기 DRM 시스템 내에서 DRM 문서를 발행하는 데에 상기 등록 증명서를 이용할 수 있는 방법.
제1항에 있어서,

상기 DRM-R 서버는 상기 DRM-E 서버를 신뢰하기 위한 기존의 근거를 갖고 있지 않으며,

상기 방법은, 상기 DRM-E 서버가 이러한 DRM-E 서버를 기꺼이 보증하는 자(party)로부터 공개 키(PU-V) 및 대응하는 개인 키(PR-V)를 포함하는 보증 증명서를 포함하는 자신의 제공 신원 증명을 획득하는 단계;

상기 DRM-E 서버가 상기 보증 증명서를 소유하고 있음을 보여주기 위해 상기 DRM-E 서버가 소유권 표시(ownership indicia)를 작성하는데 (PU-E) 및 (PR-V)를 이용하는 단계;

상기 DRM-E 서버가 상기 보증 증명서, (PU-E) 및 소유권 표시를 포함하는 등록 요청을 상기 DRM-R 서버에 전송하는 단계;

상기 DRM-R 서버가 상기 보증 증명서를 유효화하는 단계;

상기 DRM-R 서버가 상기 소유권 표시를 검증하는 단계;

상기 요청이 받아들여져야 한다면, 상기 DRM-R 서버가 그와 같은 DRM-E 서버를 상기 DRM 시스템에 등록하기 위해 상기 DRM-E 서버에 대해 적어도 부분적으로 상기 보증 증명서 및 (PU-E)에 기초하는 디지털 등록 증명서를 생성하는 단계를 포함하는 방법.
제2항에 있어서,

상기 DRM-E 서버가 그와 같은 보증을 수행하기 위해 상기 DRM-R 서버가 신뢰하고 신용하는 독립된 증명서 발행 에이전트로부터 상기 보증 증명서를 획득하는 단계를 포함하는 방법.
제2항에 있어서,

상기 DRM-E 서버가 X.509 보증 증명서를 획득하는 단계를 포함하는 방법.
제2항에 있어서,

싱기 DRM-E 서버가 상기 보증자에 의해 서명되고, 유효화를 위한 목적으로 알려진 루트로 연결되는 증명서의 체인을 수반하는 보증 증명서를 획득하는 단계; 및

상기 DRM-R 서버가 상기 DRM-E 서버가 보증되었음을 확정하기 위해 상기 보증자에 의한 서명 및 상기 증명서의 체인에 기초하여 상기 보증 증명서를 유효화하는 단계를 포함하는 방법.
제2항에 있어서,

상기 DRM-E 서버가 소유권 표시로서의 (PR-V(PU-E))를 생성하기 위해 (PU-E)를 암호화하는데 (PR-V)를 이용하는 단계 또는 소유권 표시로서의 (PU-E)S(PR-V)를 생성하기 위해 (PU-E)를 (PR-V)로 서명하는 단계 중 하나를 수행하는 단계; 및

상기 DRM-E 서버가 (PR-V) 및 이에 따른 보증 증명서를 소유하고 있음을 확정하기 위해, 상기 DRM-R 서버가, 요청으로부터의 (PU-V)를 적용하여 (PU-E)를 암호 해제하거나 서명을 증명함으로써, 소유권 표시를 검증하는 단계를 포함하는 방법.
제2항에 있어서,

상기 DRM-R 서버가 상기 DRM-E 서버의 식별자로서의 (PU-E), 상기 보증 증명서를 식별하는 식별 표시, 및 상기 DRM-R 서버의 개인 키에 기초하는 서명을 포함하는 등록 증명서를 생성함으로써, 상기 등록 증명서 내의 보증 증명서의 식별 표시는 상기 보증 증명서까지의 다리 역할을 하고, 상기 DRM-R 서버가 상기 DRM-E 서버를 보증하기 위해 상기 보증자를 신뢰하고 신용함을 보여주는 방법.
제7항에 있어서,

상기 DRM-R 서버가 자신의 식별자로서 상기 DRM-R 서버의 공개 키를 더 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법
제7항에 있어서,

상기 DRM-R 서버가 상기 등록 증명서가 유효한 범위를 지정하는 유효 범위 정보를 더 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법.
제1항에 있어서,

상기 DRM-R 서버는 상기 DRM-E 서버를 신뢰하기 위한 기존의 근거를 가지고 있고,

상기 방법은, 상기 DRM-E 서버가 상기 DRM-R 서버에 대해 인식 가능하고 그 DRM-R 서버에 의해 받아들여질 것으로 기대되는 신용 증명서를 구비하는 제공 신원 증명을 획득하는 단계;

상기 DRM-E 서버가 상기 DRM-R 서버에 상기 신용 증명서 및 (PU-E)를 포함하는 등록 요청을 전송하는 단계;

상기 DRM-R 서버가 상기 신용 증명서를 유효화하는 단계; 및

상기 요청이 받아들여져야 하는 경우 상기 DRM-R 서버가 그와 같은 DRM-E 서버를 상기 DRM 시스템에 등록하기 위해 상기 DRM-E 서버에 대해 적어도 부분적으로 상기 신용 증명서 및 (PU-E)에 기초하는 디지털 등록 증명서를 생성하는 단계를 구비하는 방법.
제10항에 있어서,

상기 DRM-E 서버가 네트워크 ID 또는 도메인 ID로 구성된 그룹으로부터 선택된 신용 증명서, 및 제3자에 의해 발행된 신용 증명서를 획득하는 단계를 포함하는 방법.
제10항에 있어서,

상기 DRM-R 서버가 상기 DRM-E 서버의 식별자로서의 (PU-E), 상기 신용 증명서를 식별하기 위한 식별 표시, 및 상기 DRM-R 서버의 개인 키에 기초하는 서명을 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법.
제12항에 있어서,

상기 DRM-R 서버가 자신의 식별자로서 상기 DRM-R 서버의 공개 키를 더 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법
제12항에 있어서,

상기 DRM-R 서버가 상기 등록 증명서가 유효한 범위를 지정하는 유효 범위 정보를 더 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법.
제1항에 있어서,

상기 DRM-R 서버가 상기 요청을 받아들일지 여부를 판단하기 위해 커스텀 로직을 수행하는 단계를 더 포함하는 방법.
제15항에 있어서,

상기 DRM-R 서버가, 상기 DRM-E 서버 및/또는 그 오퍼레이터에 대한 배경 체크의 수행, 상기 DRM-E 서버 및/또는 그 일부가 통용되는지에 대한 결정, 상기 DRM-E 서버가 취소 리스트 또는 감시 리스트 상에 있는지에 대한 결정, 및 그 조합으로 구성된 그룹으로부터 선택되는 커스텀 로직을 수행하는 단계를 포함하는 방법.
제1항에 있어서,

상기 DRM-R 서버가 상기 DRM-E 서버의 식별자로서의 (PU-E), 및 상기 DRM-R 서버의 개인 키에 기초하는 서명을 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법.
제17항에 있어서,

상기 DRM-R 서버가 자신의 식별자로서 상기 DRM-R 서버의 공개 키를 더 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법
제17항에 있어서,

상기 DRM-R 서버가 상기 등록 증명서가 유효한 범위를 지정하는 유효 범위 정보를 더 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법.
제17항에 있어서,

상기 DRM-R 서버가 상기 제공 신원 증명을 식별하기 위해 식별 표시를 더 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법.
제1항에 있어서,

상기 DRM-R 서버가 상기 등록 증명서 내의 정보의 적어도 일부를 생성하기 위해 커스텀 로직을 이용함으로써 상기 등록 증명서를 생성하는 단계를 포함하는 방법.
제1항에 있어서,

상기 DRM-R 서버가 신뢰된 루트 인가(authority)로 연결하는 증명서의 체인을 상기 발생된 등록 증명서에 첨부하여, 상기 발생된 등록 증명서가 그와 같은 증명서의 체인에 기초하여 유효화될 수 있도록 하는 단계를 포함하는 방법.
제1항에 있어서,

상기 DRM-E 서버가 상기 DRM 시스템 내의 그와 같은 DRM-E 서버의 등록을 취소하는 권한을 가진 적어도 하나의 엔터티를 취소 권한 리스트에서 식별하는 단계를 더 포함하고,

상기 DRM-E 서버가 제공 신원 증명, (PU-E) 및 상기 취소 권한 리스트를 포함하는 등록 요청을 상기 DRM-R 서버에 전송하는 단계를 포함하며,

상기 요청이 받아들여져야 하는 경우 상기 DRM-R 서버가 그와 같은 DRM-E 서버를 상기 DRM 시스템에 등록하기 위해 상기 DRM-E 서버에 대해 적어도 부분적으로 (PU-E) 및 상기 취소 권한 리스트에 기초하는 디지털 등록 증명서를 생성하는 단계를 포함하는 방법.
제23항에 있어서,

상기 DRM-E 서버가 자신의 공개 키를 통해 상기 취소 권한 리스트 내의 각각의 엔터티를 식별하는 단계를 포함하는 방법.
제23항에 있어서,

상기 DRM-R 서버가 상기 DRM-E 서버의 식별자로서의 (PU-E), 상기 요청으로부터의 취소 권한 리스트, 및 상기 DRM-R 서버의 개인 키에 기초하는 서명을 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법.
제1항에 있어서,

상기 DRM-R 서버가 XrML 등록 증명서를 생성하는 단계를 포함하는 방법.
디지털 콘텐츠 권리 관리(DRM) 기능을 수행하는 복수의 DRM 서버를 가진 DRM 시스템과 협력하여, 신입 DRM-E 서버가 등록 DRM-R 서버에 의해 상기 시스템에 등록되도록 하여 상기 신입 DRM-E 서버가 상기 시스템 내에서 신뢰받도록 하는 방법에 있어서,

상기 DRM-E 서버가 상기 DRM 시스템 내에서 그와 같은 DRM-E 서버를 식별하기 위한 공개/개인 키 쌍(PU-E, PR-E)을 획득하는 단계;

상기 DRM-E 서버가 자신의 제공 신원 증명을 획득하는 단계;

상기 DRM-E 서버가 상기 제공 신원 증명 및 (PU-E)를 포함하는 등록 요청을 상기 DRM-R 서버에 전송하고, 상기 DRM-R가 상기 제공 신원 증명을 유효화하며, 상기 요청이 받아들여져야 하는 경우 그와 같은 DRM-E 서버를 상기 DRM 시스템에 등록하기 위해 상기 DRM-E 서버에 대해 적어도 부분적으로 (PU-E)에 기초하는 디지털 등록 증명서를 생성하고, 요청한 상기 DRM-E 서버로 상기 발생된 등록 증명서를 반환하는 단계; 및

이제 등록된 상기 DRM-E 서버가 장래의 사용을 위해 상기 반환된 등록 증명서를 적절한 위치에 저장하는 단계를 포함하며,

상기 등록 증명서를 가진 상기 DRM-E 서버는 상기 DRM 시스템 내에서 DRM 문서를 발행하는데 상기 등록 증명서를 이용할 수 있는 방법.
제27항에 있어서,

상기 DRM-R 서버는 상기 DRM-E 서버를 신뢰하기 위한 기존의 근거를 갖고 있지 않으며,

상기 DRM-E 서버는 그와 같은 DRM-E 서버를 기꺼이 보증하는 상대방으로부터 공개 키(PU-V) 및 대응하는 개인 키(PR-V)를 포함하고 있는 보증 증명서를 포함하는 자신의 제공 신원 증명을 획득하는 단계;

상기 DRM-E 서버가 상기 보증 증명서를 소유하고 있음을 보여주기 위해 상기 DRM-E 서버가 소유권 표시를 작성하는 데에 (PU-E) 및 (PR-V)를 이용하는 단계;

상기 DRM-E 서버가 상기 보증 증명서, (PU-E) 및 소유권 표시를 포함하는 등록 요청을 상기 DRM-R 서버에 전송하고, 상기 DRM-R 서버가 상기 보증 증명서를 유효화하고, 상기 소유권 표시를 검증하고, 상기 요청이 받아들여져야 하는 경우 그와 같은 DRM-E 서버를 상기 DRM 시스템에 등록하기 위해 상기 DRM-E 서버에 대해 적어도 부분적으로 상기 보증 증명서 및 (PU-E)에 기초하는 디지털 등록 증명서를 생성하는 단계를 포함하는 방법.
제28항에 있어서,

상기 DRM-E 서버는 그와 같은 보증을 수행하기 위해 상기 DRM-R 서버가 신뢰하고 신용하는 독립된 증명서 발행 에이전트로부터 상기 보증 증명서를 획득하는 단계를 포함하는 방법.
제28항에 있어서,

상기 DRM-E 서버가 X.509 보증 증명서를 획득하는 단계를 포함하는 방법.
제28항에 있어서,

싱기 DRM-E 서버가 보증자에 의해 서명되고 유효화를 위한 목적으로 알려진 루트로 연결하는 증명서의 체인을 수반하는 보증 증명서를 획득하는 단계; 및

상기 DRM-R 서버가 상기 DRM-E가 보증되었음을 확정하기 위해 상기 보증자에 의한 서명 및 상기 증명서의 체인에 기초하여 상기 보증 증명서를 유효화하는 단계를 포함하는 방법.
제28항에 있어서,

상기 DRM-E 서버가 소유권 표시로서의 (PR-V(PU-E))를 생성하기 위해 (PU-E)를 암호화하는데 (PR-V)를 이용하는 단계, 또는 소유권 표시로서의 (PU-E)S(PR-V)를 생성하기 위해 (PU-E)를 (PR-V)로 서명하는 단계 중 하나를 수행하는 단계; 및

DRM-E 서버가 (PR-V) 및 그에 따른 보증 증명서를 소유하고 있음을 확정하기 위해, 상기 DRM-R 서버가 요청으로부터의 (PU-V)를 적용하여 (PU-E)를 암호 해제하거나 서명을 검증함으로써, 소유권 표시를 검증하는 단계를 포함하는 방법.
제28항에 있어서,

상기 지금 등록된 DRM-E 서버가 상기 DRM-R 서버의 식별자로서의 (PU-E), 상기 보증 증명서를 식별하는 식별 표시, 및 상기 DRM-R 서버의 개인 키에 기초하는 서명을 포함하는 반환된 등록 증명서를 저장함으로써, 상기 등록 증명서 내의 보증 증명서의 식별 표시는 상기 보증 증명서까지의 다리 역할을 하고, 상기 DRM-R 서버가 상기 DRM-E 서버를 보증하기 위해 상기 보증자를 신뢰하고 신용함을 보여주는 방법.
제33항에 있어서,

상기 DRM-E 서버가 그 식별자로서의 상기 DRM-R 서버의 공개 키를 더 포함하는 반환된 등록 증명서를 저장하는 단계를 포함하는 방법
제33항에 있어서,

상기 지금 등록된 DRM-E 서버가 상기 등록 증명서가 유효한 범위를 지정하는 유효 범위 정보를 더 포함하는 반환된 등록 증명서를 저장하는 단계를 포함하는 방법.
제27항에 있어서,

상기 DRM-R 서버는 상기 DRM-E 서버를 신뢰할만한 기존의 근거를 가지고 있고,

상기 DRM-E 서버가 상기 DRM-R 서버에 대해 인식 가능하고 그 DRM-R 서버에 의해 받아들여질 것으로 기대되는 신용 증명서를 포함하는 자신의 제공 신원 증명을 획득하는 단계;

상기 DRM-E 서버가 상기 DRM-R 서버에 상기 신용 증명서 및 (PU-E)를 포함하는 등록 요청을 전송하는 단계;

상기 DRM-R 서버가 상기 신용 증명서를 유효화하는 단계; 및

상기 요청이 받아들여져야 하는 경우, 그와 같은 DRM-E 서버를 상기 DRM 시스템에 등록하기 위해 상기 DRM-E 서버에 대해 적어도 부분적으로 상기 신용 증명서 및 (PU-E)에 기초하는 디지털 등록 증명서를 생성하는 단계를 포함하는 방법.
제36항에 있어서,

상기 DRM-E 서버가 네트워크 ID 또는 도메인 ID로 구성된 그룹으로부터 선택된 신용 증명서 및 및 제3자에 의해 발생된 신용 증명서를 획득하는 단계를 포함하는 방법.
제36항에 있어서,

상기 지금 등록된 DRM-E 서버가 상기 DRM-E 서버의 식별자로서의 (PU-E), 상기 신용 증명서를 식별하기 위한 식별 표시, 및 상기 DRM-R 서버의 개인 키에 기초하는 서명을 포함하는 반환된 등록 증명서를 저장하는 단계를 포함하는 방법.
제38항에 있어서,

상기 지금 등록된 DRM-E 서버가 그 식별자로서의 DRM-R 서버의 공개 키를 더 포함하는 반환된 등록 증명서를 저장하는 단계를 포함하는 방법.
제38항에 있어서,

상기 지금 등록된 DRM-E 서버가 상기 등록 증명서가 유효한 범위를 지정하는 유효 범위 정보를 더 포함하는 반환된 등록 증명서를 저장하는 단계를 포함하는 방법.
제27항에 있어서,

상기 지금 등록된 DRM-E 서버가 상기 DRM-E 서버의 식별자로서의 (PU-E), 및상기 DRM-R 서버의 개인 키에 기초하는 서명을 포함하는 반환된 등록 증명서를 저장하는 단계를 포함하는 방법.
제41항에 있어서,

이제 등록된 상기 DRM-E 서버가 자신의 식별자로서 DRM-R 서버의 공개 키를 더 포함하는 반환된 등록 증명서를 저장하는 단계를 포함하는 방법.
제41항에 있어서,

이제 등록된 상기 DRM-E 서버가 상기 등록 증명서가 유효한 범위를 지정하는 유효 범위 정보를 더 포함하는 반환된 등록 증명서를 저장하는 단계를 포함하는 방법.
제41항에 있어서,

이제 등록된 상기 DRM-E 서버가 상기 제공 신원 증명을 식별하기 위한 식별 표시를 더 포함하는 반환된 등록 증명서를 저장하는 단계를 포함하는 방법.
제27항에 있어서,

이제 등록된 상기 DRM-E 서버가 상기 생성된 등록 증명서가 증명서의 체인에 기초하여 유효화될 수 있도록 신뢰된 루트 인가(root authority)로 연결하는 그와 같은 인증서의 체인을 포함하는 반환된 등록 증명서를 저장하는 단계를 포함하는방법.
제27항에 있어서,

상기 DRM-E 서버가 상기 DRM 시스템 내의 그와 같은 DRM-E 서버의 등록을 취소하는 권한을 가진 적어도 하나의 엔터티를 취소 권한 리스트에서 식별하는 단계를 더 포함하고,

상기 DRM-E 서버가 상기 제공 신원 증명, (PU-E) 및 상기 취소 권한 리스트를 포함하는 등록 요청을 상기 DRM-R 서버에 전송하는 단계를 포함하며,

상기 요청이 받아들여져야 하는 경우 상기 DRM-R 서버가 그와 같은 DRM-E 서버를 상기 DRM 시스템에 등록하기 위해 상기 DRM-E 서버에 대해 적어도 부분적으로 (PU-E) 및 상기 취소 권한 리스트에 기초하는 디지털 등록 증명서를 생성하는 단계를 포함하는 방법.
제46항에 있어서,

상기 DRM-E 서버가 자신의 공개 키를 통해 상기 취소 권한 리스트 내의 각각의 엔터티를 식별하는 단계를 포함하는 방법.
제46항에 있어서,

이제 등록된 상기 DRM-E 서버가 상기 DRM-E 서버의 식별자로서의 (PU-E), 상기 요청으로부터의 취소 권한 리스트, 및 상기 DRM-R 서버의 개인 키에 기초하는서명을 포함하는 반환된 등록 증명서를 저장하는 단계를 포함하는 방법.
제27항에 있어서,

이제 등록된 상기 DRM-E 서버가 XrML 등록 증명서를 저장하는 반환된 등록 증명서를 저장하는 단계를 포함하는 방법.
디지털 콘텐츠 권리 관리(DRM) 기능을 수행하는 복수의 DRM 서버를 가진 DRM 시스템과 협력하여, 신입 DRM-E 서버가 등록 DRM-R 서버에 의해 상기 시스템에 등록되도록 함으로써 상기 신입 DRM-E 서버가 상기 시스템 내에서 신뢰받도록 하는 방법에 있어서,

상기 DRM-R 서버가 상기 DRM 시스템 내의 그와 같은 DRM-E 서버를 식별하기 위한 제공 신원 증명 및 DRM-E 서버의 공개 키(PU-E)를 포함하는 등록 요청을 상기 DRM-E 서버로부터 수신하는 단계;

상기 DRM-R가 상기 제공 신원 증명을 유효화하는 단계;

상기 요청이 받아들여져야 하는 경우, 상기 DRM-R 서버가 그와 같은 DRM-E 서버를 상기 DRM 시스템에 등록하기 위해 상기 DRM-E 서버에 대해 적어도 부분적으로 (PU-E)에 기초하는 디지털 등록 증명서를 생성하는 단계;

상기 DRM-R 서버가 상기 발생된 등록 증명서를 상기 요청 DRM-E 서버로 반환하고, 상기 지금 등록된 DRM-E 서버가 장래의 사용을 위해 상기 반환된 등록 증명서를 적절한 위치에 저장하는 단계를 포함하고,

상기 등록 증명서를 가진 상기 DRM-E 서버는 상기 DRM 시스템 내에서 DRM 문서를 발생하는 데에 상기 등록 증명서를 이용할 수 있는 방법.
제50항에 있어서,

상기 DRM-R 서버는 상기 DRM-E 서버를 신뢰하기 위한 기존의 근거를 갖고 있지 않으며,

상기 DRM-R 서버는 그와 같은 DRM-E 서버를 기꺼이 보증하는 자(party)로부터의 공개 키(PU-V) 및 대응 개인 키(PR-V)를 포함하는 보증 증명서를 구비하는 제공 신원 증명 및 (PU-E)를 갖는 등록 요청을 상기 DRM-E 서버로부터 수신하는 단계 - 여기서, 상기 DRM-E 서버가 상기 보증 증명서를 소유하고 있음을 보여주기 위해 상기 DRM-E 서버가 소유권 표시를 작성하는데 (PU-E) 및 (PR-V)를 이용하되, 상기 등록 요청은 상기 소유권 표시를 더 포함함 - ;

상기 DRM-R 서버가 상기 보증 증명서를 유효화하는 단계;

상기 DRM-R 서버가 상기 소유권 표시를 검증하는 단계;

상기 요청이 받아들여져야 하는 경우 상기 DRM-R 서버가 그와 같은 DRM-E 서버를 상기 DRM 시스템에 등록하기 위해 상기 DRM-E 서버에 대해 적어도 부분적으로 상기 보증 증명서 및 (PU-E)에 기초하는 디지털 등록 증명서를 생성하는 단계를 포함하는 방법.
제51항에 있어서,

상기 DRM-R 서버가 그와 같은 보증을 수행하기 위해 상기 DRM-R 서버가 신뢰하고 신용하는 독립된 증명서 발행 에이전트로부터의 보증 증명서를 포함하는 등록 요청을 DRM-E 서버로부터 수신하는 단계를 포함하는 방법.
제51항에 있어서,

상기 DRM-R 서버가 X.509 보증 증명서를 포함하는 등록 요청을 DRM-E 서버로부터 수신하는 단계를 포함하는 방법.
제51항에 있어서,

싱기 DRM-R 서버가 보증 상대에 의해 서명되고 유효화를 위한 목적으로 알려진 루트로 연결하는 증명서의 체인을 수반하는 보증 증명서를 포함하는 등록 요청을 상기 DRM-E 서버로부터 수신하는 단계; 및

상기 DRM-R 서버가 상기 DRM-E가 보증되었음을 확정하기 위해 상기 보증 상대에 의한 서명 및 상기 증명서의 체인에 기초하여 상기 보증 증명서를 유효화하는 단계를 포함하는 방법.
제51항에 있어서,

상기 DRM-E 서버가 소유권 표시로서의 (PR-V(PU-E))를 생성하기 위해 (PU-E)를 암호화하는데 (PR-V)를 이용하는 단계, 또는 소유권 표시로서의 (PU-E)S(PR-V)를 발생하기 위해 (PU-E)를 (PR-V)로 서명하는 단계 중 하나를 수행하는 단계; 및

상기 DRM-E 서버가 (PR-V) 및 이에 따른 보증 증명서를 소유하고 있음을 확정하기 위해, 상기 DRM-R 서버가 요청으로부터의 (PU-V)를 적용하여 (PU-E)를 암호 해제하거나 서명을 검증함으로써, 소유권 표시를 검증하는 단계를 포함하는 방법.
제51항에 있어서,

상기 DRM-R 서버가 상기 DRM-E 서버의 식별자로서의 (PU-E), 상기 보증 증명서를 식별하는 식별 표시, 및 상기 DRM-R 서버의 개인 키에 기초하는 서명을 포함하는 등록 증명서를 생성함으로써, 상기 등록 증명서 내의 보증 증명서의 식별 표시는 상기 보증 증명서까지의 다리 역할을 하고, 상기 DRM-R 서버가 상기 DRM-E 서버를 보증하기 위해 상기 보증자를 신뢰하고 신용함을 보여주는 방법.
제56항에 있어서,

상기 DRM-R 서버가 자신의 식별자로서 상기 DRM-R 서버의 공개 키를 더 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법
제56항에 있어서,

상기 DRM-R 서버가 상기 등록 증명서가 유효한 범위를 지정하는 유효 범위 정보를 더 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법.
제50항에 있어서,

상기 DRM-R 서버는 상기 DRM-E 서버를 신뢰하기 위한 기존의 근거를 가지고 있고,

상기 DRM-R 서버가 상기 DRM-R 서버에 대해 인식 가능하고 그 DRM-R 서버에 의해 받아들여질 것으로 기대되는 신용 증명서를 구비하는 제공 신원 증명 및 (PU-E)를 포함하는 등록 요청을 상기 DRM-E 서버로부터 수신하는 단계;

상기 DRM-R 서버가 상기 신용 증명서를 유효화하는 단계; 및

상기 요청이 받아들여져야 하는 경우, 상기 DRM-R 서버가 그와 같은 DRM-E 서버를 상기 DRM 시스템에 등록하기 위해 상기 DRM-E 서버에 대해 적어도 부분적으로 상기 신용 증명서 및 (PU-E)에 기초하는 디지털 등록 증명서를 생성하는 단계를 포함하는 방법.
제59항에 있어서,

상기 DRM-R 서버가 네트워크 ID 또는 도메인 ID로 구성된 그룹으로부터 선택된 신용 증명서 및 및 제3자에 의해 발행된 신용 증명서를 포함하는 등록 요청을 상기 DRM-E 서버로부터 수신하는 단계를 포함하는 방법.
제59항에 있어서,

상기 DRM-R 서버가 상기 DRM-E 서버의 식별자로서의 (PU-E), 상기 신용 증명서를 식별하기 위한 식별 표시, 및 상기 DRM-R 서버의 개인 키에 기초하는 서명을 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법.
제61항에 있어서,

상기 DRM-R 서버가 자신의 식별자로서 상기 DRM-R 서버의 공개 키를 더 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법
제61항에 있어서,

상기 DRM-R 서버가 상기 등록 증명서가 유효한 범위를 지정하는 유효 범위 정보를 더 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법.
제50항에 있어서,

상기 DRM-R 서버가 상기 요청을 받아들일지 여부를 판단하기 위해 커스텀 로직을 수행하는 단계를 더 포함하는 방법.
제64항에 있어서,

상기 DRM-R 서버가 상기 DRM-E 서버 및/또는 그 오퍼레이터에 대한 배경 체크의 수행, 상기 DRM-E 서버 및/또는 그 일부가 통용되는지에 대한 결정, 상기 DRM-E 서버가 취소 리스트 또는 감시 리스트 상에 있는지에 대한 결정, 및 그 조합으로 구성된 그룹으로부터 선택되는 커스텀 로직을 수행하는 단계를 포함하는 방법.
제50항에 있어서,

상기 DRM-R 서버가 상기 DRM-E 서버의 식별자로서의 (PU-E), 및 상기 DRM-R 서버의 개인 키에 기초하는 서명을 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법.
제66항에 있어서,

상기 DRM-R 서버가 자신의 식별자로서 상기 DRM-R 서버의 공개 키를 더 포함하는 등록 증명서를 발생하는 단계를 포함하는 방법.
제66항에 있어서,

상기 DRM-R 서버가 상기 등록 증명서가 유효한 범위를 지정하는 유효 범위 정보를 더 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법.
제66항에 있어서,

상기 DRM-R 서버가 상기 제공 신원 증명을 식별하기 위해 식별 표시를 더 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법.
제50항에 있어서,

상기 DRM-R 서버가 상기 등록 증명서 내의 정보의 적어도 일부를 발생하는 데에 커스텀 로직을 이용함으로써 상기 등록 증명서를 생성하는 단계를 포함하는방법.
제50항에 있어서,

상기 DRM-R 서버가 신뢰된 루트 인가(root authority)로 연결되는 증명서 체인을 상기 발생된 등록 증명서에 첨부하여, 상기 발생된 등록 증명서가 그와 같은 증명서 체인에 기초하여 유효화될 수 있도록 하는 단계를 포함하는 방법.
제50항에 있어서,

상기 DRM-R 서버가 상기 DRM 시스템 내의 그와 같은 DRM-E 서버의 등록을 취소하는 권한을 가진 적어도 하나의 엔터티를 식별하는 취소 권한 리스트를 더 포함하는 등록 요청을 상기 DRM-E 서버로부터 수신하는 단계 및,

상기 요청이 받아들여져야 하는 경우 상기 DRM-R 서버가 그와 같은 DRM-E 서버를 상기 DRM 시스템에 등록하기 위해 상기 DRM-E 서버에 대해 적어도 부분적으로 상기 취소 권한 리스트에 기초하는 디지털 등록 증명서를 생성하는 단계를 더 포함하는 방법.
제72항에 있어서,

상기 DRM-R 서버가 상기 DRM-E 서버의 식별자로서의 (PU-E), 상기 요청으로부터의 취소 권한 리스트, 및 상기 DRM-R 서버의 개인 키에 기초하는 서명을 포함하는 등록 증명서를 생성하는 단계를 포함하는 방법.
제50항에 있어서,

상기 DRM-R 서버가 XrML 등록 증명서를 발생하는 단계를 포함하는 방법.