KR100949657B1 - 유연한 권리 템플릿을 이용하여 권리 관리 시스템에서디지털 컨텐츠에 대한 서명된 권리 라벨(ｓｒｌ)을 얻기 - Google Patents

Abstract

컨텐츠가 컨텐츠 키(CK)에 따라 암호화되어 결국 (CK(content))가 되고, 컨텐츠 키(CK)는 라이센스 서버에 대한 공개키(PU-RM)에 따라 보호된다. 권리 데이터는 컨텐츠와 연관된 권리 템플릿으로부터 검색되고, 검색된 권리 데이터를 변형하기 위한 규칙들이 검색된 권리 템플릿으로부터 검색된다. 권리 템플릿으로부터의 검색된 권리 데이터는 규칙에 따라 변형되고, 권리 데이터 및 보호된 컨텐츠 키(CK)는 서명하기 위한 라이센스 서버에 권리 라벨로서 제출된다. 그러므로, 라이센스 서버는 권리 라벨을 확인하고, 유효하다면, (PU-RM)에 대응하는 개인키(PR-RM) 및 결과적으로 서명된 권리 라벨(SRL)로 나타나는 권리 데이터에 적어도 부분적으로 기초하여 디지털 서명을 생성하고, SRL를 리턴한다.

권리 관리 시스템, 인터넷, 권리 템플릿, 서명된 권리 라벨, 라이센스 서버

Description

유연한 권리 템플릿을 이용하여 권리 관리 시스템에서 디지털 컨텐츠에 대한 서명된 권리 라벨(ＳＲＬ)을 얻기{USING A FLEXIBLE RIGHTS TEMPLATE TO OBTAIN A SIGNED RIGHTS LABEL(SRL) FOR DIGITAL CONTENT IN A RIGHTS MANAGEMENT SYSTEM}

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

도 2는 본 발명이 구현될 수 있는 다양한 컴퓨팅 디바이스를 가지는 네트워크 환경의 예를 나타내는 블록도.

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

도 4는 권리 관리된 디지털 컨텐츠를 발행하기 위한 본 발명에 따른 방법의 양호한 실시예의 플로우차트를 제공한 도면.

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

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

도 6a 및 6b는 권리 관리된 디지털 컨텐츠를 라이센싱하기 위한 본 발명에 따른 방법의 양호한 실시예의 플로우차트를 제공한 도.

도 7은 신뢰-기반 시스템의 예의 시행 아키텍쳐를 도시한 블록도.

도 8은 사용자가 본 발명의 하나의 실시예에 따라 오프-라인 발행을 수행하도록 허용하는 RM 서버에 의해 발행되는 인증서를 도시한 블록도.

도 9는 본 발명의 하나의 실시예에 따라 권리 라벨에 통합되는 정보를 지정하는 권리 템플릿을 도시한 블록도.

도 10은 도 9의 권리 템플릿을 생성할 때 수행되는 핵심 단계들을 도시하고 본 발명의 하나의 실시예에 따라 권리 템플릿에 기초하여 도 4a의 서명된 권리 라벨을 생성하는 플로우차트.

도 11은 본 발명의 하나의 실시예에 따라 유연한 권리 템플릿을 생성하고 채용할 때 수행되는 핵심 단계들을 도시한 플로우차트.

<도면의 주요 부분에 대한 부호의 설명>

302 : 컨텐츠 준비 애플리케이션

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

306 : RM 클라이언트 API

308 : 서명된 권리 라벨

310 : 권리 관리된 디지털 컨텐츠

330 : 통신 네트워크

320 : RM 서버

본 발명은 권리 관리(RM) 시스템에 관한 것이다. 특히, 본 발명은 그러한 RM 시스템에서 유연한 권리 템플릿을 이용하여 하나의 디지털 컨텐츠에 대해 라이센스 서버로부터 서명된 권리 라벨(SRL)을 얻을 때 수행되는 단계들에 관한 것이다.

권리 관리 및 시행은 디지털 오디오, 디지털 비디오, 디지털 텍스트, 디지털 데이터, 디지털 멀티미디어 등과 같이 하나 이상의 사용자들에게 배포될 수 있는 디지털 컨텐츠와 관련하여 매우 바람직하다. 디지털 컨텐츠는 예를 들면 텍스트 문서와 같이 정적이거나, 라이브 이벤트의 스트리밍된 오디오/비디오와 같이 스트리밍될 수도 있다. 전형적인 배포 모드는 자기(플로피) 디스크, 자기 테이프, 광(컴팩트) 디스크(CD) 등과 같은 유형의 디바이스 및 전자 게시판, 전자 네트워크, 인터넷 등과 같은 무형의 미디어를 포함한다. 사용자에 의해 수신될 때, 그러한 사용자는 퍼스널 컴퓨터 등에서 미디어 플레이어와 같은 적절한 렌더링 디바이스의 도움을 받아 디지털 컨텐츠를 렌더링하거나 "플레이"한다.

하나의 시나리오에서, 저자, 발행인, 방송사 등과 같은 컨텐츠 소유자 또는 권리 소유자는 라이센스 요금 또는 일부 다른 보상과 교환하여 다수의 사용자 또는 수령자들 각각에게 그러한 디지털 컨텐츠를 배포하기를 원한다. 그러한 시나리오에서, 컨텐츠는 노래, 노래 앨범, 영화 등일 수 있고, 배포의 목적은 라이센스 요금을 생성하는 것이다. 그러한 컨텐츠 소유자는 기회가 주어진다면 사용자가 그렇게 배포된 디지털 컨텐츠로 할 수 있는 것을 제한하기를 원할 수 있다. 예를 들 어, 컨텐츠 소유자는 사용자가 그러한 컨텐츠를 복사하여 제2 사용자에게 재배포하는 것을, 적어도 컨텐츠 소유자가 그러한 제2 사용자로부터 라이센스 요금을 거절하는 방식으로, 제한하기를 원한다.

뿐만 아니라, 컨텐츠 소유자는 사용자에게 다른 라이센스 요금으로 다른 타입의 사용 라이센스를 구입하는 유연성을 제공하기를 원하고, 동시에 실제로 구매된 어느 타입의 라이센스든 그 조건으로 사용자를 유지하기를 원한다. 예를 들어, 컨텐츠 소유자는 배포된 디지털 컨텐츠가 단지 제한된 회수만큼, 특정 전체 시간 동안만, 단지 특정 타입의 머신에서만, 단지 특정 타입의 미디어 플레이어에서만, 단지 특정 타입의 이용자에 의해서만 플레이되기를 원할 수도 있다.

다른 시나리오에서, 회사의 직원과 같은 컨텐츠 개발자는 회사내의 하나 이상의 다른 직원들 또는 회사 외부의 다른 개인들에게 그러한 디지털 컨텐츠를 배포하기를 원하지만, 다른 사람들이 상기 컨텐츠를 렌더링하는 것을 막고 싶어할 수 있다. 여기에서, 컨텐츠의 배포는 라이센스 요금 또는 일부 다른 보상과 교환하는 넓은 범위에 걸친 배포와는 달리, 비밀 또는 제한적인 방식으로 공유하는 조직 범위의 컨텐츠에 훨씬 더 가깝다. 그러한 시나리오에서, 컨텐츠는 사무실 세팅내에서 교환될 수 있는 것과 같이 문서 프리젠테이션, 스프레드시트, 데이터베이스, 이메일 등일 수 있고, 컨텐츠 개발자는 컨텐츠가 사무실 설정 내에서 유지되고 예를 들면 경쟁사 또는 적들과 같은 비인가된 개인들에 의해 렌더링되지 않도록 보장하기를 원한다. 또한, 그러한 컨텐츠 개발자는 수신자들이 그러한 배포된 디지털 컨텐츠로 할 수 있는 것을 제한하기를 원한다. 예를 들면, 컨텐츠 소유자는 사용자 가 그러한 컨텐츠를, 적어도 컨텐츠를 렌더링하도록 허가된 개인들의 한계 외부에서 컨텐츠를 노출시키는 방식으로, 제2 사용자에게 복사하고 재배포하는 것을 제한하기를 원할 것이다.

뿐만 아니라, 컨텐츠 개발자는 다양한 수신자들에게 다른 레벨의 렌더링 권리들을 제공하기를 원한다. 예를 들어, 컨텐츠 개발자는 보호된 디지털 컨텐츠가 하나의 클래스의 개인들에게는 볼 수는 있지만 프린트는 불가능하도록 하고 다른 클래스의 개인들에게는 볼 수도 있고 프린트도 가능하도록 하기를 원할 수 있다.

그러나, 어느 시나리오든, 배포가 발생된 후, 그러한 컨텐츠 소유자/개발자는 디지털 컨텐츠에 대한 제어권을 거의 가지지 못한다. 이것은 실제로 모든 퍼스널 컴퓨터가 그러한 디지털 컨텐츠의 정확한 디지털 복사를 수행하고 그러한 정확한 디지털 복사본을 기록가능한 자기 또는 광 디스크에 다운로딩하거나 그러한 정확한 디지털 복사본을 인터넷과 같은 네트워크를 통해 임의의 목적지에 전송하는데 필요한 소프트웨어 및 하드웨어를 포함하고 있다는 사실을 감안하면 특히 문제이다.

물론, 컨텐츠가 배포되는 거래의 일부로서, 컨텐츠 소유자/개발자는 디지털 컨텐츠의 이용자/수신자가 그러한 디지털 컨텐츠를 환영받지 못하는 방식으로 재배포하지 않도록 요구할 수 있다. 그러나, 그러한 약속은 쉽게 할 수 있고 쉽게 깨질 수 있다. 컨텐츠 소유자/개발자는 일반적으로 암호화 및 암호화 해제를 포함하여, 수개의 주지된 보안 디바이스 중 임의의 하나를 통해 그러한 재배포를 방지하려고 시도한다. 그러나, 그다지 단호하지 않은 사용자가 암호화된 디지털 컨텐츠 를 암호 해제하고 그러한 디지털 컨텐츠를 암호화되지 않은 형태로 저장한 후 이를 재배포하는 것을 방지하는 것은 거의 가능성이 없다.

따라서, 임의의 형태의 디지털 컨텐츠의 제어된 렌더링 또는 플레이를 허용하는 권리 관리 및 시행 아키텍쳐 및 방법을 제공하는 것이 필요하고, 여기에서 그러한 제어는 유연하고 그러한 디지털 컨텐츠의 컨텐츠 소유자/개발자에 의해 정의가능하여야 할 것이다. 보다 구체적으로, 특히 문서들이 정의된 개인 그룹 또는 개인 클래스 간에 공유되어야 하는 사무실 또는 조직 환경 등에서 그러한 제어된 렌더링을 허용하고 용이하게 하는 아키텍쳐에 대한 필요성이 존재한다. 보다 구체적으로, 그러한 환경내에서 디지털 컨텐츠의 발행자에게, 그러한 디지털 컨텐츠와 관련된 사용자 및 그러한 사용자의 권리를 지정하는 사전 정의된 템플릿(상기 템플릿은 본질적으로 유연하다)을 제공하는 아키텍쳐가 필요하다.

본 발명은 라이센스 서버가 컨텐츠에 대응하는 디지털 라이센스를 컨텐츠를 렌더링하기 원하는 하나 이상의 사용자들에게 발행할 수 있도록 하는 디지털 컨텐츠를 발행하는 시스템 및 방법을 제공함으로써 본 기술분야의 상기 언급된 요구들을 만족시킨다.

하나의 방법에서, 컨텐츠는 컨텐츠 키(CK)에 따라 암호화되어 결국 (CK(content))가 되고, 컨텐츠 키(CK)는 라이센스 서버에 대한 공개키(PU-RM)에 따라 보호된다. 권리 데이터는 컨텐츠와 연관될 권리 템플릿으로부터 검색되고, 검색된 권리 데이터를 변형하기 위한 규칙들 또한 검색된 권리 템플릿으로부터 검색 된다. 권리 템플릿으로부터의 검색된 권리 데이터는 규칙에 따라 변형되고, 권리 데이터 및 보호된 컨텐츠 키(CK)는 서명하기 위하여 라이센스 서버에 권리 라벨로서 제출된다. 이리하여, 라이센스 서버는 권리 라벨을 확인하고, 유효하다면, (PU-RM)에 대응하는 개인키(PR-RM)에 기초하고, 결과적으로 서명된 권리 라벨(SRL)로 나타나는 권리 데이터에 적어도 부분적으로 기초하여 디지털 서명을 생성하고, SRL를 리턴한다.

리턴된 SRL이 수신되고 (CK(content))와 연관되어 컨텐츠 패키지를 형성하고, 컨텐츠 패키지는 하나 이상의 사용자들에게 배포된다. 그러므로, 컨텐츠를 렌더링하기를 바라는 사용자는 컨텐츠 패키지로부터 SRL을 검색하고, 컨텐츠에 대응하는 라이센스에 대한 요구의 일부로서 검색된 SRL을 라이센스 서버에 제출한다. 라이센스 서버는 (PU-RM)에 기초하고, 보호된 권리 데이터에 적어도 부분적으로 기초하여 SRL의 서명을 검증하고, SRL의 권리 데이터에 액세스하며, 이를 검토하여 사용자에게 라이센스의 자격이 주어지는지 여부를 결정하고, 그렇다면 사용자에게 라이센스를 발행하며, 여기에서 라이센스는 사용자에게 액세스가능한 보호된 형태의 (CK)를 포함한다.

다른 방법에서, 복수의 라이센스 서버가 컨텐츠에 대응하는 디지털 라이센스를 발행하도록 인에이블된다. 특히, 라이센스를 발행하도록 인에이블될 수 있는 각 라이센스 서버의 공개키(PUx-RM)는 권리 템플릿의 권리 데이터로부터 검색되고, 컨텐츠 키(CK)는 각 인에이블된 라이센스 서버에 대한 공개키(PUx-RM)에 따라 보호되어, 각 인에이블된 라이센스 서버에 대해 (PUx-RM(CK))로 나타난다. 그러므로, 권리 데이터 및 각 인에이블된 라이센스 서버에 대한 (PUx-RM(CK))는 권리 라벨로서 라이센스 서버에 제출되어, 그럼으로써 서명한다. 컨텐츠를 렌더링하기를 원하는 사용자는 결과적인 SRL을 검색하고, 컨텐츠에 대응하는 라이센스에 대한 요구의 일부로서 검색된 SRL을 인에이블된 라이센스 서버의 하나에 제출된다. 그런 다음, 인에이블된 라이센스 서버는 SRL을 검증하고, SRL의 권리 데이터를 액세스하며, 이를 검토하여 사용자가 라이센스에 대해 권한이 있는지를 결정하고, 그렇다면 그러한 라이센스 서버에 대응하는 권리 데이터로부터 (PUx-RM(CK))를 검색하며, 그로부터 (CK)를 검색하고, 라이센스를 사용자에게 발행하며, 여기에서 라이센스는 사용자에게 액세스가능한 보호된 형태로 (CK)를 포함한다.

또 다른 방법에서, 복수의 발행 서버의 식별이 권리 데이터로부터 검색되고, 복수의 발행 서버들 중 하나가 선택된다. 그러므로, 권리 데이터 및 보호된 컨텐츠 키(CK)는 권리 라벨로서 선택된 발행 서버에 제출되고, 그럼으로써 서명한다.

또 다른 방법에서, 권리 템플릿은 컨텐츠와 연관된 권리 데이터 및 권리 데이터를 변형하기 위한 규칙을 권리 템플릿 내에서 정의하고, 규칙에 기초하여 변형되지 않는 권리 데이터의 일부를 식별함으로써 생성된다. 식별된 부분들 중 적어도 일부가 표시되고, 권리 템플릿이 표시된 부분에 기초하여 서명되어 디지털 서명을 생성한다. 그러므로, 컨텐츠를 발행하는 발행자는 규칙에 따라 템플릿의 권리 데이터를 변형하지만, 템플릿의 표시된 부분을 변형하지 않을 것으로 예상되며, 따라서 디지털 서명이 검증되는 것을 방지해서는 안된다.

본 발명의 다른 특징들은 첨부된 도면과 조합하여 취해진 본 발명의 실시예 의 이하의 상세한 설명으로부터 더 명백하게 될 것이다.

컴퓨팅 디바이스의 예

도 1 및 이하의 설명은 본 발명이 구현될 수 있는 적합한 컴퓨팅 환경의 간단한 일반적인 설명을 제공하려는 것이다. 그러나, 핸드헬드, 휴대용 및 모든 종류의 다른 컴퓨팅 디바이스가 본 발명과 관련하여 이용하기 위해 고려될 수 있다는 것은 자명하다. 일반 목적 컴퓨터가 이하에 설명되지만, 이것은 단지 하나의 예에 불과하고, 본 발명은 네트워크 서버 상호동작성 및 상호작용을 가지는 씬 클라이언트만을 필요로 한다. 그러므로, 본 발명은 매우 적은 또는 최소의 클라이언트 리소스들이 포함되는 네트워킹된 호스팅된 서비스의 환경, 예를 들면 씬 디바이스가 단지 브라우저 또는 월드 와이드 웹으로의 인터페이스로서만 기능하는 네트워킹된 환경에서 구현될 수 있다.

요구되지는 않지만, 본 발명은 개발자에 의해 사용하기 위해, 애플리케이션 프로그래밍 인터페이스(API)를 통해 구현되거나, 클라이언트 워크스테이션, 서버 또는 다른 디바이스들과 같은 하나 이상의 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터-실행가능 명령의 일반적인 컨텍스트로 기술되는 네트워크 브라우징 소프트웨어내에 포함될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상적인 데이터 타입을 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등을 포함한다. 통상, 프로그램 모듈의 기능은 다양한 실시예에 원하는 대로 조합되거나 분산될 수 있다. 더구나, 본 기술분야의 숙련자라면, 본 발명이 다른 컴퓨터 시스템 구성으로 실시될 수 있다는 것을 잘 알고 있을 것이다. 본 발명으로 이용하기에 적합한 다른 주지된 컴퓨팅 시스템, 환경 및/또는 구성은 퍼스널 컴퓨터(PC), 자동화된 텔러 머신, 서버 컴퓨터, 핸드헬드 또는 랩탑 디바이스, 멀티-프로세서 시스템, 마이크로프로세서-기반 시스템, 프로그램가능한 소비자 전자장치, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 등을 포함하고, 이들로 제한되지 않는다. 본 발명은 통신 네트워크 또는 다른 데이터 송신 매체를 통해 링크되는 원격 처리 디바이스에 의해 태스크들이 수행되는 분산 컴퓨팅 환경에서 실시될 수도 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 디바이스를 포함하여 로컬 및 원격 컴퓨터 저장매체에 배치될 수 있다.

상기 명백해진 바와 같이, 컴퓨팅 시스템 환경(100)은 단지 적절한 컴퓨팅 환경의 하나의 예에 불과하고 본 발명의 이용이나 기능의 범주에 관해 어떠한 제한을 암시하려고 하는 것은 아니지만, 도 1은 본 발명이 구현될 수 있는 적절한 컴퓨팅 시스템 환경(100)의 예를 예시하고 있다. 또한, 컴퓨팅 환경(100)은 예로 든 오퍼레이팅 환경(100)에 예시된 컴포넌트의 임의의 하나 또는 조합에 관련하여 어떠한 의존성 또는 요구조건을 가지고 있는 것으로서 해석되어서는 안 된다.

도 1을 참조하면, 본 발명을 구현하기 위한 시스템 예는 컴퓨터(110) 형태의 일반 목적 컴퓨팅 디바이스를 포함한다. 컴퓨터(110)의 컴포넌트는 처리 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 포함하는 다양한 시스템 컴포넌트를 처리 유닛(120)에 결합시키는 시스템 버스(121)를 포함하고, 이들로 제한되지는 않는다. 시스템 버스(121)는 메모리 버스 또는 메모리 컨트롤러, 주변장치 버스, 및 다양한 버스 아키텍쳐들 중 임의의 것을 이용하는 로컬 버스를 포함하는 수개의 타입의 버스 구조 중 하나가 될 수 있다. 예를 들어, 그러한 아키텍쳐는 ISA 버스, MCA 버스, EISA 버스, VESA 로컬 버스, 메자닌(Mezzanine) 버스로도 알려진 PCI 버스를 포함하고, 이들로 제한되지는 않는다.

컴퓨터(110)는 통상 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터(110)에 의해 액세스될 수 있는 임의의 가용한 매체가 될 수 있고, 휘발성 및 비휘발성 매체, 제거가능 및 제거 불가능 매체를 모두 포함한다. 예를 들어, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함하고, 이들로 제한되지 않는다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보 저장을 위한 임의의 방법이나 기술로 구현되는 휘발성 및 비휘발성, 제거가능 및 제거 불가능 매체를 모두 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD 또는 다른 광학 디스크 저장장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치 또는 다른 자기 저장장치 디바이스, 또는 원하는 정보를 저장하는데 이용될 수 있고 컴퓨터(110)에 의해 액세스될 수 있는 임의의 다른 매체를 포함하고, 이들로 제한되지는 않는다. 통신 매체는 통상 컴퓨터 판독가능한 명령, 데이터 구조, 프로그램 모듈 또는 다른 데이터를 반송파와 같은 변조 데이터 신호 또는 다른 전송 메카니즘으로 실시하고, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 정보를 신호로 인코딩하는 것과 같은 방식으로 설정되거나 변경되는 하나 이상의 특징을 구비하는 신호를 의미한다. 예를 들면, 통신 매체는 유선 네트워크 또는 직접-유선 접속과 같은 유선 매체 및 음향, 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)는 통 상 인터페이스(140)와 같은 제거 불가능 메모리 인터페이스를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광 디스크 드라이브(155)는 통상 인터페이스(150)와 같이 제거가능 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.

상기 설명되고 도 1에 예시된 드라이브 및 그 연관 컴퓨터 저장 매체는 컴퓨터(110)에 대해 컴퓨터 판독가능한 명령, 데이터 구조, 프로그램, 모듈 및 데이터의 저장을 제공한다. 도 1에서, 예를 들면, 하드 디스크 드라이브(141)는 오퍼레이팅 시스템(144), 애플리케이션 프로그램(145), 다른 프로그램 모듈(146) 및 프로그램 데이터(147)를 저장하는 것으로서 예시된다. 유의할 점은 이들 컴포넌트들은 오퍼레이팅 시스템(134), 애플리케이션 프로그램(135), 다른 프로그램 모듈(136) 및 프로그램 데이터(137)와 동일하거나 또는 상이할 수도 있다는 점이다. 오퍼레이팅 시스템(144), 애플리케이션 프로그램(145), 다른 프로그램 모듈(146), 및 프로그램 데이터(147)는 최소한 다른 복제물이라는 것을 예시하도록 다른 숫자가 주어진다. 사용자는 키보드(162), 및 통상 마우스, 트랙볼 또는 터치 패드로 지칭되는 포인팅 디바이스(161)와 같은 입력 디바이스를 통해 컴퓨터(110)에 명령과 정보를 입력한다. 다른 입력 디바이스(도시되지 않음)는 마이크로폰, 조이스틱, 게임 패드, 위성 디시(dish), 스캐너 등을 포함할 수 있다. 이들 및 다른 입력 디바이스들은 시스템 버스에 결합되는 사용자 입력 인터페이스(160)를 통해 처리 유닛(120)에 종종 접속되고, 병렬 포트, 게임 포트 또는 범용 병렬 버스(USB)와 같은 다른 인터페이스 및 버스 구조에 의해 접속될 수도 있다.

모니터(191) 또는 다른 타입의 디스플레이 디바이스는 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)에 접속된다. 노스브리지(Northbridge)와 같은 그래픽 인터페이스(182)는 시스템 버스(121)에 접속될 수 있다. 노스브리지는 CPU 또는 호스트 처리 유닛(120)과 통신하는 칩셋이고 가속 그래픽 포트(AGP) 통신에 대한 책임을 담당한다. 하나 이상의 그래픽 처리 유닛(GPU, 184)는 그래픽 인터페이스(182)와 통신한다. 이러한 측면에서, GPU(184)는 일반적으로 레지스터 저장장치와 같은 온-칩 메모리 저장장치를 포함하고, GPU(184)는 비디오 메모리(186)와 통신한다. 그러나, GPU(184)은 단지 하나의 코프로세서의 예에 불과하고, 다양한 코프로세싱 디바이스가 컴퓨터(110)에 포함될 수 있다. 모니터(191) 또는 다른 타입의 표시 디바이스가 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)에 접속되고, 비디오 인터페이스(190)는 비디오 메모리(186)와 통신한다. 모니터(191)뿐만 아니라, 컴퓨터는 출력 주변장치 인터페이스(195)를 통해 접속될 수 있는 스피커(197) 및 프린터(196)와 같은 다른 주변장치 출력 디바이스를 포함할 수 있다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용하여 네트워킹되거나 분산된 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 디바이스 또는 다른 공통 네트워크 노드일 수 있고, 도 1에는 메모리 저장 디바이스(181)만이 예시되어 있지만, 통상 퍼스널 컴퓨터(110)와 관련하여 상기 설명한 구성요소들 중 다수 또는 모두를 포함한다. 도 1에 도시된 논리적 접속은 로컬 영역 네트워크(LAN, 71) 및 와이드 영역 네트워크(WAN, 173)를 포함하지만, 다른 네트워크를 포함할 수도 있다. 그러한 네트워킹 환경은 사무실, 기업-와이드 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔한 것이다.

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

본 기술분야의 통상의 기술자라면, 컴퓨터(110) 또는 다른 클라이언트 디바이스는 컴퓨터 네트워크의 일부로서 배치될 수 있다는 것을 잘 알고 있을 것이다. 이러한 측면에서, 본 발명은 임의의 개수의 메모리 또는 저장 유닛을 가지는 임의의 컴퓨터 시스템, 및 임의의 개수의 저장 유닛 또는 볼륨에 걸쳐 발생하는 임의의 개수의 애플리케이션 및 프로세스에 관련된다. 본 발명은 원격 또는 로컬 저장장치를 가지는, 네트워크 환경에 배치되는 서버 컴퓨터 및 클라이언트 컴퓨터를 구비하는 환경에 적용할 수 있다. 본 발명은 또한 프로그래밍 언어 기능, 번역 및 실 행 성능을 가지는 단독 컴퓨팅 디바이스에 적용할 수도 있다.

분산된 컴퓨팅은 컴퓨팅 디바이스와 시스템들간의 직접 교환에 의해 컴퓨터 리소스 및 서비스의 공유를 용이하게 한다. 이들 리소스 및 서비스들은 정보 교환, 캐시 저장, 및 파일에 대한 디스크 저장을 포함한다. 분산된 컴퓨팅은 네트워크 연결성을 활용하고, 클라이언트들이 그 집합적 힘을 레버리지할 수 있도록 하여 전체 기업에게 이익을 줄 수 있다. 이러한 측면에서, 다양한 디바이스들이 신뢰받는 그래픽스 파이프라인(들)에 대해 본 발명의 인증 기술을 포함하도록 상호작용하는 애플리케이션, 오브젝트 또는 리소스들을 가질 수 있다.

도 2는 네트워킹되거나 분산된 컴퓨팅 환경 예의 개략도를 제공하고 있다. 분산된 컴퓨팅 환경은 컴퓨팅 오브젝트(10a, 10b, 등) 및 컴퓨팅 오브젝트 또는 디바이스(110a, 110b, 110c, 등)를 포함한다. 이들 오브젝트들은 프로그램, 메소드, 데이터 저장소, 프로그램가능한 로직 등을 포함한다. 오브젝트들은 PDA, 텔레비전, MP3 플레이어, 텔레비전, 퍼스널 컴퓨터, 등과 같은 동일하거나 다른 디바이스들의 일부를 포함할 수 있다. 각 오브젝트는 통신 네트워크(14)를 통해 다른 오브젝트와 통신할 수 있다. 이러한 네트워크는 도 2의 시스템에 서비스를 제공하는 다른 컴퓨팅 오브젝트 및 컴퓨팅 디바이스를 자체적으로 포함할 수 있다. 본 발명의 하나의 양태에 따르면, 각 오브젝트(10 또는 110)는 신뢰받는 그래픽스 파이프라인(들)에 대해 본 발명의 인증 기술을 요구하는 애플리케이션을 포함할 수 있다.

또한, 참조부호 110c와 같은 오브젝트는 다른 컴퓨팅 디바이스(10 또는 110) 상에 호스팅될 수 있다는 것은 자명하다. 그러므로, 도시된 물리적 환경이 접속된 디바이스들을 컴퓨터로서 도시하고 있지만, 그러한 예시는 단지 예에 불과하고, 다르게는 물리적 환경은 PDA, 텔레비전, MP3 플레이어, 등, 인터페이스, COM 오브젝트 등과 같은 소프트웨어 오브젝트와 같은 다양한 디지털 디바이스를 포함하는 것으로 도시되거나 기술될 수 있다.

분산된 컴퓨팅 환경을 지원하는 다양한 시스템, 컴포넌트 및 네트워크 구성이 있다. 예를 들어, 컴퓨팅 시스템은 유선 또는 무선 시스템, 로컬 네트워크 또는 넓게 분산된 네트워크에 의해 함께 접속될 수 있다. 일반적으로, 다수의 네트워크들은 넓게 분산된 컴퓨팅에 대한 인프라구조를 제공하고 다수의 다른 네트워크들을 포함하는 인터넷에 결합된다.

홈 네트워킹 환경에서, 전력 라인, 데이터(무선 또는 유선 모두), 음성(예를 들면, 전화) 및 오락 미디어와 같은 고유 프로토콜을 각각 지원하는 적어도 4개의 다른 네트워크 트랜스포트 미디어가 있다. 조명 스위치 및 가전제품과 같은 대부분의 홈 제어 디바이스들은 연결을 위해 전력 라인을 이용할 수 있다. 데이터 서비스들은 홈을 브로드밴드(예를 들면, DSL 또는 케이블 모뎀 중 하나)로서 입력하고, 무선(예를 들면, HomeRF 또는 802.11b) 또는 유선(예를 들면, 홈 PNA, Cat 5, 심지어 전력 라인) 연결 중 하나를 이용하여 홈내에서 액세스가능하다. 음성 트래픽은 홈을 유선(예를 들면, Cat 3) 또는 무선(예를 들면, 셀 전화) 중 하나로 입력하고, Cat 3 배선을 이용하여 홈내에 분산될 수 있다. 오락 미디어는 위성 또는 케이블 중 하나를 통해 홈을 입력하고, 통상 동축 케이블을 이용하여 홈내에 분산된다. IEEE 1394 및 DVI는 미디어 디바이스의 클러스터에 대한 디지털 인터커넥트 로서 대두되고 있다. 모든 이들 네트워크 환경 및 프로토콜 표준으로서 대두되고 있는 다른 것들이 상호 접속되어 인터넷을 통해 외부 세계에 접속되는 인트라넷을 형성한다. 요약하면, 다양한 다른 소스가 데이터의 저장 및 송신을 위해 존재하고, 결과적으로 장래에는, 컴퓨팅 디바이스가 데이터 처리 파이프라인의 모든 부분에서 컨텐츠를 보호하는 방법들을 필요로하게 될 것이다.

인터넷은 통상 컴퓨터 네트워킹 분야에서 공지되어 있는 TCP/IP 프로토콜 슈트(suite)를 활용하는 네트워크 및 게이트웨이의 집합을 지칭한다. TCP/IP는 "트랜스포트 제어 프로토콜/인터페이스 프로그램"에 대한 두문자어이다. 인터넷은 사용자들이 상호작용하고 네트워크를 통해 정보를 공유할 수 있게 하는 네트워킹 프로토콜을 실행하는 컴퓨터에 의해 상호접속된 지리적으로 분산된 원격 컴퓨터 네트워크의 시스템으로서 기술될 수 있다. 그러한 광범위한 정보 공유로 인해, 인터넷과 같은 원격 네트워크들은 개발자들이 실질적으로 제한없이, 전용 동작이나 서비스를 수행하기 위한 소프트웨어 애플리케이션을 설계할 수 있는 오픈 시스템으로 더 발전했다.

그러므로, 네트워크 인프라구조는 클라이언트/서버, 피어-투-피어, 또는 하이브리드 아키텍쳐와 같은 네트워크의 토폴리지의 호스트를 가능하게 한다. "클라이언트"는 하나의 클래스 또는 그룹이 관련되지 않은 다른 클래스 또는 그룹의 서비스를 이용하는 클래스 또는 그룹의 멤버이다. 그러므로, 컴퓨팅에서, 클라이언트는 다른 프로그램에 의해 제공되는 서비스를 요구하는 프로세스, 즉 개략적으로는 명령 또는 태스크 세트이다. 클라이언트 프로세스는 다른 프로그램 또는 서비 스 자체에 관한 임의의 동작 세부사항을 반드시"알"필요도 없이 요구된 서비스를 활용한다. 클라이언트/서버 아키텍처, 특히 네트워킹된 시스템에서, 클라이언트는 통상 다른 컴퓨터, 예를 들면 서버에 의해 제공되는 공유된 네트워크 리소스에 액세스하는 컴퓨터이다. 도 2의 예에서, 컴퓨터(110a, 110b, 등)는 클라이언트로 생각될 수 있고, 컴퓨터(10a, 10b, 등)는 서버로서 생각될 수 있으며, 서버(10a, 10b, 등)는 클라이언트 컴퓨터(110a, 110b, 등)에서 복사되는 데이터를 유지한다.

서버는 인터넷과 같은 원격 네트워크를 통해 액세스가능한 원격 컴퓨터 시스템이다. 클라이언트 프로세스는 제1 컴퓨터 시스템에서 액티브하고, 서버 프로세스는 통신 미디어를 통해 서로 통신하는 제2 컴퓨터 시스템에서 액티브함으로써, 분산된 기능을 제공하고, 복수의 클라이언트들이 서버의 정보-수집 성능을 활용할 수 있게 한다.

클라이언트 및 서버는 프로토콜 레이어에 의해 제공되는 기능을 활용하여 서로와 통신한다. 예를 들면, 하이퍼텍스트-전달 프로토콜(HTTP)은 월드 와이드 웹(WWW)과 관련하여 이용되는 공통 프로토콜이다. 통상, 범용 리소스 로케이터(URL) 또는 인터넷 프로토콜(IP)과 같은 컴퓨터 네트워크 어드레스는 서로에게 서버 또는 클라이언트 컴퓨터들을 식별하는데 이용된다. 네트워크 어드레스는 범용 리소스 로케이터 어드레스로서 지칭될 수 있다. 예를 들면, 통신은 통신 매체를 통해 제공될 수 있다. 특히, 클라이언트 및 서버는 높은-용량 통신을 위해 TCP/IP 접속을 통해 서로에게 결합될 수 있다.

그러므로, 도 2는 본 발명이 채용될 수 있는, 네트워크/버스를 통해 클라이 언트 컴퓨터와 통신하는 서버를 구비하는 네트워킹되거나 분산된 환경의 예를 예시하고 있다. 더 상세하게는, 다수의 서버(10a, 10b, 등)는 휴대용 컴퓨터, 핸드헬드 컴퓨터, 씬 클라이언트, 네트워킹된 장비, 또는 VCR, TV, 오븐, 조명, 히터 등과 같은 다른 디바이스와 같은 다수의 클라이언트 또는 원격 컴퓨팅 디바이스(110a, 110b, 110c, 110d, 110e, 등)에, LAN, WAN, 인트라넷, 인터넷 등일 수 있는 통신 네트워크/버스(14)를 통해 상호접속된다. 그러므로, 본 발명은 신뢰받은 소스로부터 안전한 컨텐츠를 처리하고, 저장하거나 렌더링하는 것이 바람직한 임의의 컴퓨팅 디바이스에 적용할 수도 있다.

통신 네트워크/버스(14)가 인터넷인 네트워크 환경에서, 예를 들면, 서버(10)는 클라이언트(110a, 110b, 110c, 110d, 110e, 등)가 HTTP와 같은 다수의 주지된 프로토콜 중 어느 하나를 통해 통신하는 웹 서버일 수 있다. 서버(10)는 분산된 컴퓨팅 환경의 특성으로서, 클라이언트(110)로서 기능할 수 있다. 통신은 적절한 경우에 유선 또는 무선일 수 있다. 클라이언트 디바이스(110)는 통신 네트워크/버스(14)를 통해 통신하거나 그렇지 않을 수도 있고, 그것과 연관된 독립적인 통신을 가질 수 있다. 예를 들어, TV 또는 VCR의 경우에, 그 제어에 네트워킹된 양태가 있거나 없을 수도 있다. 각 클라이언트 컴퓨터(110) 및 서버 컴퓨터(10)는 다양한 애플리케이션 프로그램 모듈 또는 오브젝트(135), 및 파일이 저장되거나 파일의 일부(들)가 다운로드되거나 이동되는 다양한 타입의 저장 요소 또는 오브젝트로의 접속 또는 액세스를 구비하고 있다. 그러므로, 본 발명은 컴퓨터 네트워크/버스(14)와 액세스하고 상호작용할 수 있는 클라이언트 컴퓨터(110a, 110b, 등) 및 클라이언트 컴퓨터(110a, 110b, 등) 및 다른 디바이스(111) 및 데이터베이스(20)와 상호작용하는 서버 컴퓨터(10a, 10b, 등)를 구비하는 컴퓨터 네트워크 환경에서 활용될 수 있다.

권리 관리(RM) 개요

주지된 바와 같이, 도 7를 참조하면, 권리 관리(RM) 및 시행은 사용자들에게 배포되는 디지털 오디오, 디지털 비디오, 디지털 텍스트, 디지털 데이터, 디지털 멀티미디어, 등과 같은 디지털 컨텐츠(12)와 관련하여 매우 바람직하다. 사용자에 의해 수신된 경우, 그러한 사용자가 퍼스널 컴퓨터(14) 등의 미디어 플레이어와 같은 적절한 렌더링 디바이스의 도움으로 디지털 컨텐츠를 렌더링하거나 "플레이한다".

통상, 그러한 디지털 컨텐츠(12)를 배포하는 컨텐츠 소유자 또는 개발자(이하에서는 '소유자')는 사용자가 그러한 배포된 디지털 컨텐츠(12)로 할 수 있는 것을 제한하기를 원한다. 예를 들어, 컨텐츠 소유자는 사용자가 제2 사용자에게 그러한 컨텐츠(12)를 복사하여 재배포하는 것을 제한하거나, 배포된 디지털 컨텐츠(12)가 단지 제한된 회수만큼, 특정 전체 시간 동안만, 특정 타입의 머신에서만, 특정 타입의 미디어 플레이어에서만, 특정 타입의 사용자에 의해서만 플레이될 수 있도록 허용하기를 바랄 수 있다.

그러나, 배포가 발생한 후, 그러한 컨텐츠 소유자는 디지털 컨텐츠(12)에 대해 거의 제어권을 가지지 못한다. RM 시스템(10)은 임의의 형태의 디지털 컨텐츠(12)의 제어된 렌더링 또는 플레이를 허용하고, 그러한 제어는 유연하여 그러한 디 지털 컨텐츠의 컨텐츠 소유자에 의해 정의가능하다. 통상, 컨텐츠(12)는 임의의 적절한 배포 채널을 통해 패키지(13)의 형태로 사용자에게 배포된다. 배포된 디지털 컨텐츠 패키지(13)는 컨텐츠를 식별하는 다른 정보, 그러한 컨텐츠에 대해 라이센스를 획득하는 방법 등 뿐만 아니라 대칭 암호화/암호해제 키(KD, 즉 (KD(CONTENT)))로 암호화되는 디지털 컨텐츠(12)를 포함할 수 있다.

신뢰-기반 RM 시스템(10)은 디지털 컨텐츠(12)의 소유자가 그러한 디지털 컨텐츠(12)가 사용자의 컴퓨팅 디바이스(14) 상에서 렌더링되도록 허가되기 이전에 만족되어야 하는 라이센스 규칙을 지정할 수 있게 한다. 그러한 라이센스 규칙들은 상기 언급된 일시적 요구조건을 포함할 수 있고, 사용자/사용자의 컴퓨팅 디바이스(14, 이하에서는 상황이 다르게 요구되지 않는 한 그러한 용어들은 상호교환가능함)가 컨텐츠 소유자 또는 그 에이전트로부터 획득해야 하는 디지털 라이센스(16)내에 실시될 수 있다. 그러한 라이센스(16)는 사용자의 컴퓨팅 디바이스에 의해 암호해제 가능한 키에 따라 암호화된 디지털 컨텐츠를 암호해제하기 위한 암호해제 키(KD)를 포함한다.

하나의 디지털 컨텐츠(12)에 대한 컨텐츠 소유자는 사용자의 컴퓨팅 디바이스(14)가 라이센스(16)에서 그러한 컨텐츠 소유자에 의해 지정된 규칙 및 조건을 지킬 것이다, 즉 라이센스(16)내의 규칙 및 조건이 만족되는 경우에만 디지털 컨텐츠(12)가 렌더링될 것이라는 것을 신뢰해야 한다. 바람직하게는, 사용자 컴퓨팅 디바이스(14)는 디지털 컨텐츠(12)와 연관된 라이센스(16)내에 실시되고 사용자에 의해 얻어진 라이센스 규칙을 따르지 않고서는 디지털 컨텐츠(12)를 렌더링하지 않 는 신뢰받는 컴포넌트 또는 메커니즘(18)을 구비한다.

신뢰받는 컴포넌트(18)는 통상 다른 것들 중에서, 라인센스(16)가 유효한지를 결정하고, 그러한 유효한 라이센스(16)내에서 라이센스 규칙 및 조건을 검토하며, 검토된 라이센스 규칙 및 조건에 기초하여 요구하는 사용자가 요구된 디지털 컨텐츠(12)를 원하는 방식대로 렌더링할 권리를 가지고 있는지 여부를 결정하는 라이센스 평가기(20)를 가지고 있다. 자명한 바와 같이, 라이센스 평가기(20)는 RM 시스템(10)에서 신뢰되어 라이센스(16)의 규칙 및 조건에 따라 디지털 컨텐츠(12)의 소유자의 희망을 수행하고, 사용자는 임의의 목적, 또는 사악한 다른 의도로 그러한 신뢰받은 요소를 쉽게 변경할 수 없어야 한다.

자명한 바와 같이, 라이센스(16)의 규칙 및 조건들은 사용자가 누구인지, 사용자가 어디에 있는지, 사용자가 어떤 타입의 컴퓨팅 디바이스를 이용하고 있는지, 어떤 렌더링 애플리케이션이 RM 시스템을 호출하고 있는지, 일자, 시간, 등을 포함하여 수개의 인자들 중 임의의 것에 기초하여 사용자가 디지털 컨텐츠(12)를 렌더링할 권리를 가지고 있는지 여부를 지정할 수 있다. 뿐만 아니라, 라이센스(16)의 규칙 및 조건들은 라이센스(16)를 선정된 회소의 플레이, 또는 선정된 플레이 시간, 등으로 제한할 수도 있다.

규칙 및 조건은 라이센스(16)에서 임의의 적절한 언어 및 구문에 따라 지정될 수 있다. 예를 들어, 언어는 단지 만족되어야 할 속성 및 값만을 지정하거나(예를 들면, DATE는 X보다 나중이어야 한다), 지정된 스크립트에 따라 함수의 성능을 요구할 수도 있다(예를 들면, IF DATE가 X보다 크면, THEN DO...).

라이센스 평가기(20)가 라이센스(16)가 유효하고 사용자가 규칙 및 조건을 만족시킨다고 결정한 경우에, 디지털 컨텐츠(12)가 렌더링될 수 있다. 특히, 컨텐츠(12)를 렌더링하기 위해, 암호해제 키(KD)가 라이센스(12)로부터 얻어져 컨텐츠 패키지(13)로부터 (KD(CONTENT))에 적용되어, 실제 컨텐츠(12)로 나타나게 된 후 실제로 실제 컨텐츠(12)가 렌더링된다.

디지털 컨텐츠의 발행

도 3은 디지털 컨텐츠를 발행하기 위한 본 발명에 따른 시스템 및 방법의 양호한 실시예의 기능 블록도이다. "발행"이 본 명세서에 이용되는 경우, 이는 애플리케이션 또는 서버가 권리 및 조건이 발생될 수 있는 대상뿐만 아니라 실체가 그 컨텐츠에 대해 발행할 수 있는 권리 및 조건의 세트를 신뢰된 실체와 확립하는데 따르는 프로세스를 지칭한다. 본 발명에 따르면, 발행 프로세스는 디지털 컨텐츠를 암호화하고, 컨텐츠의 저자가 컨텐츠의 모든 가능한 사용자에 대해 의도했던 지속적이고 시행할 수 있는 권리를 연관시키는 것을 포함한다. 이러한 프로세스는 컨텐츠의 저자에 의해 의도하지 않는 경우에는 임의의 권리 또는 컨텐츠로의 액세스를 금지하는 안전한 방식으로 수행될 수 있다.

본 발명의 양호한 실시예에서, 3개의 실체들은 특히 안전한 디지털 컨텐츠를 발행하도록 채용될 수 있다. 이들은 클라이언트(300) 상에서 실행되고 발행을 위해 컨텐츠를 준비시키는 컨텐츠 준비 애플리케이션(302), 클라이언트 디바이스(300) 상에 상주하는 권리 관리(RM) 애플리케이션 프로그램 인터페이스(API, 306), 및 통신 네트워크(330)를 통해 클라이언트(300)에 통신가능하게 결합되는 RM 서버 (320)이다. 본 발명의 양호한 실시예에서, 통신 네트워크(330)가 전용 인트라넷과 같은 임의의 로컬 또는 와이드 영역 네트워크일 수 있지만, 통신 네트워크(330)는 인터넷을 포함한다.

컨텐츠 준비 애플리케이션(302)은 디지털 컨텐츠를 생성하는 임의의 애플리케이션일 수 있다. 예를 들어, 애플리케이션(302)은 디지털 텍스트 파일, 디지털 음악, 비디오 또는 다른 그러한 컨텐츠를 생성하는 워드 프로세서 또는 다른 발행기일 수 있다. 컨텐츠는 예를 들어 라이브 또는 테이핑된 이벤트의 스트리밍된 오디오/비디오와 같은 스트리밍된 컨텐츠를 포함할 수 있다. 본 발명에 따르면, 컨텐츠 준비 애플리케이션은 그 사용자를 초대하여 사용자가 제공하는 키를 이용하여 컨텐츠를 암호화한다. 애플리케이션(302)은 키를 이용하여 디지털 컨텐츠를 암호화함으로써 암호화된 디지털 컨텐츠 파일(304)을 형성한다. 클라이언트 애플리케이션은 또한 사용자를 초대하여 디지털 컨텐츠 파일(304)에 대해 권리 데이터를 제공한다. 권리 데이터는 디지털 컨텐츠에서 권리를 가지는 각 실체에 대한 각 주체를 포함한다. 그러한 실체는 예를 들면, 개인, 개인 클래스, 또는 디바이스일 수 있다. 각각의 그러한 실체에 대해, 권리 데이터는 그 실체가 컨텐츠에서 가지는 권리 리스트, 및 이들 권리들 중 임의의 하나 또는 모두에 대해 부과되는 임의의 조건들을 포함한다. 그러한 권리들은 디지털 컨텐츠를 읽고, 편집하며, 복사하고, 인쇄하는 등의 권리를 포함한다. 또한, 권리는 포괄적이거나 배타적일 수 있다. 포괄적인 권리들은 지정된 사용자가 컨텐츠에서 지정된 권리를 가지고 있다는 것을 나타낸다(예를 들면, 사용자가 디지털 컨텐츠를 편집할 수 있다). 배타적인 권리 는 지정된 사용자가 지정된 것을 제외하고는 컨텐츠에 대해 모든 권리를 가지고 있다는 것을 나타낸다(예를 들면, 사용자는 이를 복사하는 것을 제외하는 디지털 컨텐츠로 무엇이든지 할 수 있다.).

본 발명의 하나의 실시예에 따르면, 클라이언트 API(306)는 암호화된 디지털 컨텐츠 및 권리 데이터를 RM 서버(320)에 패싱할 수 있다. 이하에 상세하게 설명되는 프로세르를 이용하여, RM 서버(320)는 사용자에게 할당된 권리를 시행할 수 있는지 여부를 결정하고, 그렇다면, RM 서버(320)는 권리 데이터를 서명하여 서명된 권리 라벨(SRL, 308)을 형성한다. 그러나, 일반적으로, 임의의 신뢰받는 실체는 양호하게는 RM 서버(320)에 의해 신뢰받는 키를 이용하여 권리 데이터를 서명할 수 있다. 예를 들어, 클라이언트는 RM 서버(320)에 의해 제공되는 키를 이용하여 권리 데이터에 서명할 수 있다.

권리 라벨(308)은 권리 기술, 암호화된 컨텐츠 키, 및 권리 기술 및 암호화된 컨텐츠 키 상의 디지털 서명을 나타내는 데이터를 포함할 수 있다. RM 서버가 권리 라벨에 서명했다면, 서명된 권리 라벨(308)을 클라이언트 API(306)를 통해 다시 클라이언트에 패싱하고, 클라이언트 API(306)는 서명된 권리 라벨(308)을 클라이언트 디바이스(300)에 저장한다. 그리고나서, 컨텐츠 준비 애플리케이션(302)은 서명된 권리 라벨(308)을 암호화된 디지털 컨텐츠 파일(304)과 연관시킨다. 예를 들어, SRL(308)이 암호화된 디지털 컨텐츠 파일과 결부되어 권리 관리된 컨텐츠 파일(310)을 형성한다. 그러나, 일반적으로는, 권리 데이터는 디지털 컨텐츠와 조합될 필요는 없다. 예를 들어, 권리 데이터는 주지된 위치에 저장될 수 있고, 저장 된 권리 데이터에 대한 참조가 암호화된 디지털 컨텐츠와 조합될 수 있다. 참조는 권리 데이터가 저장된 장소(예를 들면, 권리 데이터를 포함하는 데이터 저장소)를 나타내는 식별자, 및 그 특정 저장 위치에서 그 특정 권리 데이터에 대응하는(예를 들어, 관심사가 되는 특정 권리 데이터를 포함하는 파일을 식별하는) 식별자를 포함할 수 있다. 그리고나서, 권리 관리된 컨텐츠(310)는 어느 곳에 있는 어떤 사람에게도 전달될 수 있고, 컨텐츠를 소비할 권리를 가지는 실체들만이 단지 그들에게 할당된 권리에 따라서만 컨텐츠를 소비할 수 있다.

도 4는 권리 라벨은 RM 서버에 의해 서명되는 권리 관리된 디지털 컨텐츠를 발행하기 위한 본 발명에 따른 방법의 예(400)의 플로우차트이다. 그러나, 이러한 실시예는 단지 예에 불과하고 권리 라벨은 일반적으로 임의의 신뢰된 실체에 의해 서명될 수 있다는 것은 자명하다. 일반적으로, 디지털 컨텐츠를 발행하기 위한 본 발명에 따른 방법은 컨텐츠 키(CK)를 이용하여 디지털 컨텐츠를 암호화하는 단계, 디지털 컨텐츠와 연관된 권리 기술을 생성하는 단계, RM 서버에 대한 공개키(PU-RM)에 따라 컨텐츠 키(CK)를 암호화하여 결과적으로 (PU-RM(CK))가 되는 단계, 및 권리 기술 및 (PU-RM(CK))의 조합 상에 (PU-RM)에 대응하는 개인키(PR-RM)에 기초하여 디지털 서명을 생성하는 단계를 포함할 수 있다.

단계 402에서, 애플리케이션(302)은 디지털 컨텐츠를 암호화하는데 이용되는 컨텐츠 키(CK)를 생성한다. 바람직하게는, 일반적으로 디지털 컨텐츠를 암호화하는데 임의의 키가 이용될 수 있지만, 컨텐츠 키(CK)는 대칭 키이다. 종종 "비밀키"알고리즘으로도 지칭되는 대칭키 알고리즘은 동일한 키를 이용하여 메시지를 암 호화하던 것처럼 메시지를 암호해제한다. 그 때문에, (CK)가 비밀로 유지되는 것이 바람직하다. 전송자와 수신자 사이에서 (CK)를 공유하는 것은 그러한 (CK)의 비인가된 개입(interception)을 방지하기 위해 매우 주의깊게 수행되어야 한다. (CK)는 암호화기 및 암호해제기 사이에 공유되므로, (CK)는 임의의 암호화된 메시지가 송신되기 이전에 통신되는 것이 바람직하다.

수개의 대칭키 생성 알고리즘은 본 기술분야에 공지되어 있다. 임의의 대칭 알고리즘이 이용될 수 있다는 것은 자명하지만, 양호한 실시예에서는, 데이터 암호화 표준(DES)이 채용된다. 그러한 대칭 키 알고리즘의 예는 트리플-DES, 국제 데이터 암호화 알고리즘(IDEA), 캐스트, 캐스트-128, RC4, RC5, 및 스킵잭(SkipJack)을 포함하고, 이들로 제한되지 않는다.

단계 404에서, 애플리케이션(302)은 대칭 컨텐츠 키(CK)로 디지털 컨텐츠를 암호화하여 암호화된 디지털 컨텐츠(304)를 형성하고, 이는 표시법(CK(content))을 이용하여 기록된다. 애플리케이션(302)을 이용하는 저자는 디지털 컨텐츠와 연관된 권리 데이터를 생성할 수 있다. 권리 데이터는 컨텐츠를 소비하는 권한이 주어진 실체 리스트, 및 그러한 권리들에 부여되는 임의의 조건과 함께 각 실체가 컨텐츠에 대해 가지는 특정 권리를 포함할 수 있다. 그러한 권리는 예를 들어 컨텐츠를 보고, 컨텐츠를 프린트하는 것 등을 포함할 수 있다. 애플리케이션(302)은 권리 데이터를 API(306)에 제공한다. XML/XrML 포맷으로 된 권리 데이터의 한 예가 부록 1로서 여기에 첨부되어 있다.

단계 406에서, API(306)는 제2 암호화 키(DES1)를 생성하여 컨텐츠 키(CK)를 암호호하는데 이용된다. 바람직하게는, (DES1)은 또한 대칭키이다. 단계 408에서, API(306)는 (DES1)로 (CK)를 암호화하여 결론적으로 (DES1(CK))가 된다. 단계 410에서, API(306)는 (CK)를 폐기하고, 결과는 (CK)는 (DES1(CK))를 암호해제함으로써만 얻어질 수 있다는 것이다. (CK(content))가 중앙 RM 서버(320)에 보호되고 컨텐츠에 대한 모든 "라이센스 요구"가 권리 데이터에 따라 중심적으로 수행되는 것을 보장하기 위해, API(306)는 단계 412에서, 제공된 RM 서버(320)를 접촉하고 그 공개키(PU-RM)를 검색한다. 단계 414에서, API(306)는 (PU-RM)으로 (DES1)을 암호화하여 결국 (PU-RM(DES1))이 된다. 그러므로, (CK)는 (PU-RM)으로 보호되어, (CK(content))를 암호해제하는데 필요한 것과 같이, RM 서버(320)가 (CK)에 액세스할 수 있는 유일한 실체라는 것을 보장한다. 단계 416에서, API(306)는 (DES1)로 권리 데이터(즉, 권한이 주어진 실체의 리스트 및 리스트에서 각 권한이 주어진 실체와 연관된 각 권리 및 조건)를 암호화하여 결국 (DES1(rightsdata))가 된다.

단순화되고 아마 바람직한 실시예에서, (CK)가 권리 데이터를 직접 암호화하는데 이용되어 결국 (CK(rightsdata))가 되고, 그럼으로써 (DES1)의 이용을 완전하게 중지할 수 있다. 물론, 그러한 경우에, (PU-RM(DES1))은 대신에 (PU-RM(CK))가 된다. 그러나, (DES1)을 이용하여 권리 데이터를 암호화하는 것은 그러한 (DES1)이 RM 서버에 대해 변경될 수 있는 임의의 특정 알고리즘에 일치하게 할 수 있게 하는데 반해, (CK)는 RM 서버와 무관한 실체에 의해 지정되어 그에 대해 변경가능하지 않은 것이 될 수 있다.

단계 418에서, 컨텐츠 보호 애플리케이션(302)은 (PU-RM(DES1)) 및 (DES1(rightsdata)) 또는 (CK(rightdata))를 서명을 위한 권리 라벨로서 RM 서버(320)에 제출할 수 있다. 다르게는, 클라이언트 자체는 권리 데이터를 서명할 수 있다. 권리 데이터가 서명을 위해 서버에 제출되고 있는 경우, 단계 420에서, RM 서버(320)는 권리 데이터에 액세스하여 제출된 권리 라벨에서 권리 및 조건을 시행할 수 있는지를 검증한다. RM 서버(320)가 권리 데이터를 시행할 수 있는지를 검증하기 위해, RM 서버(320)는 (PR-RM)을 (PU-RM(DES1))에 적용하여 결국 (DES1)이 되고, 그리고나서 (DES1)을 (DES1(rightsdata))에 적용하여 결국 권리 데이터가 암호해제된 상태가 된다. 그러면, 서버(320)는 임의의 정책 체크를 수행하여 권리 데이터에 지정된 사용자, 권리 및 조건들이 서버(320)에 의해 시행되는 임의의 정책 내에 있는지를 검증한다. 서버(320)는 (PU-RM(DES1)) 및 (DES1(rightsdata))를 포함하는 원래 제출된 권리 라벨을 서명하여 결국 서명된 권리 라벨(SRL, 308)이 되게 하고, 서명은 RM 서버(320)의 개인키(PR-RM)에 기초하고 있으며, SRL(308)을 다시 API(306)에 리턴하고, 그리고나서 리턴된 SRL(308)을 클라이언트 애플리케이션(302)에 제공한다.

SRL(308)은 디지털로 서명된 문서로서, 손으로 조작하기 힘들게 한다. 추가적으로, SRL(308)은 컨텐츠를 암호화하는데 이용되는 실제 키 타입 및 알고리즘과 무관하지만 이것이 보호하고 있는 컨텐츠에 강력한 1-1 관계를 유지한다. 이제 도 4a를 참조하면, 본 발명의 하나의 실시예에서, SRL(308)은 다른 것들 중에서 아마도 컨텐츠의 ID를 포함하는 SRL(308)의 기반인 컨텐츠에 관한 정보; (PU-RM(DES1)), 및 네트워크 상의 RM 서버를 로케이팅하기 위한 URL과 같은 참고 정보 및 URL이 실패하는 경우에 대체 정보를 포함하여 SRL(308)을 서명하는 RM 서버에 관한 정보; SRL(308) 자체를 기술하는 정보; (DES1(rightsdata)); (DES1(CK)); 및 S(PR-RM)을 포함할 수 있다. XML/XrML로 된 샘플 SRL(308)이 부록 2로서 여기에 첨부되어 있다.

신뢰된 실체가 권리 데이터를 서명하여 서명된 권리 라벨(308)을 생성하는 것을 보장함으로써, RM 서버는 권리 라벨(308)의 권리 데이터에 기술된 대로 발행자에 의해 제시된 조항들에 따라 컨텐츠에 대한 라이센스를 발행할 것이라는 것을 나타낸다. 자명한 바와 같이, 사용자는 특히 라이센스가 컨텐츠 키(CK)를 포함하고 있는 한 컨텐츠를 렌더링하는데 라이센스를 획득하는 것이 필요하다. 사용자가 암호화된 컨텐츠에 대한 라이센스를 얻기 원하는 경우에, 사용자는 컨텐츠에 대한 SR(308) 및 사용자의 자격증명을 증명하는 인증서를 포함하는 라이센스 요구를 RM 서버(320) 또는 다른 라이센스 발행 실체에 제공할 수 있다. 그러면, 라이센스 발행 실체는 (PU-RM(DES1)) 및 (DES1(rightsdata))를 암호해제하여 권리 데이터를 생성하고, 저자(있는 경우)에 의해 라이센스 요구 실체에 부여되는 모든 권리를 리스팅하며, 단지 그러한 특정 권리만을 가지는 라이센스를 구성한다.

바람직하게는, 애플리케이션(302)이 SRL(308)을 수신할 때, 그러한 애플리케이션(302)이 대응하는 (CK(content))(304)로 서명된 권리 라벨(308)을 결부시켜 권리 관리된 디지털 컨텐츠를 형성한다. 다르게는, 권리 데이터는 암호화된 디지털 컨텐츠에 제공되는 그 위치를 참조하여 주지된 위치에 저장될 수 있다. 그러므로, RM-인에이블된 렌더링 애플리케이션은 렌더링 애플리케이션이 렌더링하려고 시도하 는 컨텐츠의 조각을 통해 서명된 권리 라벨(308)을 발견할 수 있다. 이러한 발견이 렌더링 애플리케이션을 트리거링하여 RM 라이센스 서버(320)에 대한 라이센스 요구를 개시시킨다. 발행 애플리케이션(302)은 예를 들면 URL을 RM 라인센스 서버(320)에 저장하거나, RM 라이센스 서버(320)는 그것을 서명하기 이전에 그 자신의 URL을 메타데이터의 일부로서 권리 라벨에 내장시켜, 렌더링 애플리케이션에 의해 호출된 RM 클라이언트 API(306)가 정확한 RM 라이센스 서버(320)를 식별할 수 있다. 바람직하게는, 예를 들며 s글로벌 고유 식별자(GUID)와 같은 고유 식별자가 서명되기 전에 권리 라벨에 넣어진다.

본 발명의 양호한 실시예에서, 단순한 오브젝트 액세스 프로토콜(SOAP)이 컨텐츠 보호 애플리케이션(302) 또는 렌더링 애플리케이션과 RM 서버(320)간의 통신을 위해 이용될 수 있다. 추가적으로, 애플리케이션(302)과 같은 애플리케이션이 RM 프로토콜의 클라이언트 측을 구현하도록 요구되지 않고 단지 로컬 API 호출을 수행할 수 있도록 API(306)와 같은 API 라이브러리가 제공될 수 있다. 바람직하게는, 권리 기술 및 다른 데이터에 대해 임의의 적절한 포맷이 이용될 수 있다는 것은 자명하지만, XrML, XML 언어는 디지털 컨텐츠에 대한 권리 기술, 라이센스 및 권리 라벨을 기술하는데 이용된다.

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

도 5는 권리 관리된 디지털 컨텐츠를 라이센싱하기 위한 본 발명에 따른 시스템 및 방법의 양호한 실시예의 기능 블록도이다. "라이센싱"이란 용어는 본 명세서에서 애플리케이션이나 서비스가 라이센스내에 명명된 실체가 라이센스에 지정 된 조항에 따라 컨텐츠를 소비할 수 있도록 하는 라인세스를 요구하고 수신하는데 따르는 프로세스를 지칭한다. 라이센싱 프로세스로의 입력은 라이센스가 요구되고 있는 컨텐츠와 연관된 서명된 권리 라벨(SRL, 308), 및 라이센스가 요구되고 있는 실체(들)의 공개키 인증서(들)를 포함할 수 있다. 유의할 점은, 라이센스를 요구하는 실체는 반드시 라이센스가 요구되고 있는 실체일 필요는 없다는 점이다. 통상, 라이센스는 SRL(308)로부터의 권리 기술, 암호화된 컨텐츠를 암호해제할 수 있는 암호화된 키, 및 권리 기술 및 암호화된 키 상의 디지털 서명을 포함한다. 디지털 서명은 명명된 실체 및 권리가 합법적이라는 것을 확인한다.

애플리케이션(302)이 권리 관리된 컨텐츠(310)를 소비하는 하나의 방법은 클라이언트 API(306)가 권리 관리된 컨텐츠(310)의 서명된 권리 라벨(308)을 통신 네트워크(330)를 통해 RM 서버(320)에 포워딩하는 것이다. RM 서버(320)의 위치는 예를 들면 SRL(308)의 참조 정보에서 발견될 수 있다. 그러한 실시예에서, RM 라이센싱 서버(320)는 이하에 상세하게 설명되는 프로세스를 통해, 권리 라벨의 권리 기술을 이용하여, 라이센스를 발생할 수 있는지 여부를 결정하고, 그렇다면, 라이센스를 포함하는 권리 기술을 도출한다. 상기 설명된 바와 같이, 권리 라벨(308)은 RM 서버(320)의 공개키(PU-RM)(즉, (PU-RM(CK)))에 따라 암호화된 컨텐츠 키(CK)를 포함할 수 있다. 라이센스를 발행하는 프로세스에서, RM 서버(320)는 이 값을 안전하게 암호해제하여 (CK)를 얻는다. RM 서버(320)는 라이센스 요구에서 패스 업되는 공개키 인증서의 공개키(PU-ENTITY)를 이용하여 (CK)를 재암호화한다(즉, (PU-ENTITY(CK))). 새롭게 암호화된 (PU-ENTITY(CK))는 서버(320)가 라이센스 에 놓는 것이다. 그러므로, 연관된 개인키(PR-ENTITY)의 홀더만이 (PU-ENTITY(CK))로부터 (CK)를 복원할 수 있으므로, 라이센스는 (CK)를 노출시킬 위험성이 없이 호출자에게 리턴될 수 있다. 그리고나서, 클라이언트 API(306)는 (CK)를 이용하여 암호화된 컨텐츠를 암호해제함으로써 암호해제된 디지털 컨텐츠(312)를 형성한다. 그리고나서, 클라이언트 애플리케이션(302)은 라이센스에 제공되는 권리에 따라 암호해제된 디지털 컨텐츠(312)를 이용할 수 있다.

다르게는, 예를 들어 발행(publishing) 클라이언트와 같은 클라이언트는 그 자신의 라이센스를 발행하여 컨텐츠를 소비한다. 그러한 실시예에서, 적절한 환경하에서 디지털 컨텐츠를 암호해제하는데 필요한 키(들)를 클라이언트에게 제공하는 클라이언트 컴퓨터 상에서 운용될 수 있다.

도 6a 및 6b는 권리 관리된 디지털 컨텐츠를 라이센싱하기 위한 본 발명에 따른 방법(600)의 양호한 실시예의 플로우차트를 제공하고 있다. 본 발명에 따르면, 요구하는 실체는 하나 이상의 잠재적인 라이센스를 받는 사람을 대신하여 라이센스 요구를 제출할 수 있다. 요구하는 실체는 잠재적인 라이센스를 받는 사람 중 하나이거나 또는 아닐 수도 있다. 잠재적인 라이센시(라이센스를 받는 사람)는 사람, 그룹, 디바이스 또는 컨텐츠를 임의의 형태로 소비할 수 있는 임의의 다른 그러한 실체일 수 있다. 라이센스 요구 처리가 클라이언트 상에서 수행될 수 있고 라이센스가 클라이언트에 의해 바로 발행될 수 있다는 것은 자명하지만, 방법(600)은 RM 서버가 라이센스 요구를 처리하는 실시예를 참조하여 설명된다.

단계 602에서, 예를 들면 RM 서버와 같은 라이센스 발행 실체는 라이센스 요 구를 수신한다. 바람직하게는, 라이센스 요구는 공개키 인증서 또는 하나 이상의 요구된 라이센시들 각각에 대한 주체 중 하나를 포함한다.

단계 604에서, 요구하는 실체(즉, 라이센스 요구를 수행하는 실체)가 인증된다. 본 발명의 하나의 실시예에 따르면, 라이센스 발행 실체는 요구하는 실체의 주체를 결정하기 위해 프로토콜(예를 들면, 시도-응답)을 이용하도록 구성되거나, 요구하는 실체의 인증을 요구하지 않도록(또한 "익명 인증을 허용하는"것으로 알려짐) 구성될 수 있다. 인증이 요구되는 경우, 임의의 타입의 인증 스킴(예를 들면, 상기 언급한 시도-응답 스킴, MICROSOFT.NET, PASSPORT, WINDOWS 허가, x509 등과 같은 사용자-아이디-및-패스워드 스킴)이 이용될 수 있다. 바람직하게는, 통합된 정보 시스템에 의해 지원되는 임의의 프로토콜 인증 스킴을 지원할 뿐만 아니라 익명 인증이 허용된다. 인증 단계의 결과는 예를 들면, "익명"주체(익명 인증에 대해) 또는 개인전 계정 주체와 같은 주체이다. 라인센스 요구가 임의의 이유로 인해 인증될 수 없다면, 에러가 리턴되고 라이센스가 부여되지 않는다.

단계 606에서, 인증된 실체가 허가되고, 즉 단계 608에서 인증된 실체가 라이센스를 (자신을 위해 또는 다른 실체를 위해) 요구하도록 허용될지 여부를 결정된다. 바람직하게는, 라이센스 발행 실체는 라이센스를 요구하도록 허용되는(또는 허용되지 않는) 실체 리스트를 저장한다. 양호한 실시예에서, 이러한 주체들의 리스트내의 주체는 라이센스가 요구되고 있는 실체의 주체라기 보다는 요구를 하는 실체의 주체이지만, 어느 쪽이든 가능하다. 예를 들어, 개인 계정 주체는 라이센스 요구를 직접 하도록 허용되지 않지만, 신뢰된 서버 프로세스는 그러한 실체 대 신에 라이센스 요구를 할 수도 있다.

본 발명에 따르면, 라이센스 요구는 공개키 인증서 또는 각 잠재적인 라이센시에 대한 주체 중 하나를 포함할 수 있다. 라이센스가 단지 하나의 라이센시에 의해 요구되는 경우, 단지 하나의 인증서 또는 주체가 명명된다. 라이센스가 복수의 라이센시에 의해 요구되는 경우, 인증서 또는 주체가 각 잠재적인 라이센시에 대해 명명될 수 있다.

바람직하게는, 라이센스 발행 실체는 각 유효 라이센시에 대한 공개키 인증서를 가지고 있다. 그러나, 애플리케이션(302)은 주어진 사용자에 대한 라이센스를 생성하기를 원하지만, 애플리케이션(302)은 그 사용자에 대한 공개키 인증서에 액세스하지 못할 수도 있다. 그러한 상황에서, 애플리케이션(302)은 라이센스 요구시 사용자의 주체를 지정할 수 있고, 결과적으로 라이센스 발행 실체는 디렉토리 서비스에서 룩업을 수행하고 적절한 사용자의 공개키 인증서를 리턴하는 등록된 인증서 플러그-인 모듈을 유발할 수 있다.

단계 608에서, 발행 실체가 공개키 인증서가 라이센스 요구에 포함되지 않은 것으로 결정하면, 발행 실체는 지정된 주체를 이용하여, 적절한 공개키 인증서에 대해 디렉토리 서비스 또는 데이터베이스에서 룩업을 수행한다. 단계 610에서, 발행 실체가 인증서가 디렉토리내에 있는 것으로 결정하면, 단계 612에서 인증서가 검색된다. 양호한 실시예에서, 인증서 플러그-인은 디렉토리 액세스 프로토콜을 통해 디렉토리 서비스로부터 공개키 인증서를 검색하는데 이용된다. 인증서가 주어진 잠재적인 라이센시에 대해 요구 또는 디렉토리 어디에서도 발견될 수 없다면, 라이센스 서버는 그 잠재적인 라이센시에 대한 라이센스를 생성하지 않으며, 단계 614에서, 에러가 요구하는 실체로 리턴된다.

라이센스 발행 실체가 적어도 하나의 잠재적인 라이센시에 대한 공개키 인증서를 가지고 있다고 가정하면, 단계 616에서, 발행 실체는 라이센시 인증서의 신뢰성을 검증한다. 바람직하게는, 발행 실체는 신뢰된 인증서 발행자 인증서의 세트로 구성되고, 라이센시 인증서의 발행자가 신뢰된 발행자의 리스트에 있는지 여부를 결정한다. 단계 616에서, 라이센시 인증서의 발행자가 신뢰된 발행자의 리스트에 없는 것으로 발행 실체가 결정하는 경우, 요구는 그 라이센시에 대해 실패하고, 에러가 단계 614에서 생성된다. 그러므로, 그 인증서가 신뢰된 발행자에 의해 발행되지 않는 임의의 잠재적인 라이센시가 라이센스를 받지 않을 것이다.

추가적으로, 발행 실체는 양호하게는 신뢰된 발행자 인증서로부터 개별적인 라이센시 공개키 인증서에 이르는 인증서 체인에서 모든 실체에 대한 디지털 서명 검증을 수행한다. 체인에서 디지털 서명을 검증하는 프로세스는 주지된 알고리즘이다. 주어진 잠재적인 라이센시에 대한 공개키 인증서가 검증되지 못하거나 체인의 인증서가 검증되지 못한다면, 잠재적인 라이센시가 신뢰되지 못하고, 따라서 라이센스는 그 잠재적인 라이센시에게 발행되지 않는다. 그렇지 않으면, 단계 618에서, 라이센스가 발행될 수 있다. 프로세스는 라이센스가 요구된 모든 실체들이 처리될 때까지 단계 620에서 반복한다.

도 6b에 도시된 바와 같이, 라이센스 발행 실체는 계속해서 라이센스 요구에서 수신되는 서명된 권리 라벨(308)을 검증한다. 양호한 실시예에서, 발행 실체는 권리 라벨 플러그-인, 및 발행 실체에 의해 서명되는 모든 권리 라벨의 마스터 복사본을 서버 상에 저장하는 백-엔드 데이터베이스를 이용할 수 있다. 권리 라벨은 공포시 이들에 배치되는 GUID에 의해 식별된다. 라이센스 시간(단계 622)에서, 발행 실체는 라이센스 요구에 입력된 권리 라벨을 파싱하여 그 GUID를 검색한다. 그리고나서, 이러한 GUID를 권리 라벨 플러그-인에 패스하고, 이는 데이터베이스에 대해 질의를 발행하여 마스터 권리 라벨의 복사본을 검색한다. 마스터 권리 라벨은 라이센스 요구에서 송신된 권리 라벨의 복사본보다 더 최근일 수 있고, 이하의 단계에서 요구에 이용되는 권리 라벨이다. GUID에 기초하여 데이터베이스에 어떠한 권리 라벨도 발견되지 않는다면, 발행 실체는 단계 624에서 그 정책을 체크하여, 요구의 권리 라벨에 기초하여 라이센스를 발행하도록 허용되어 있는지 여부를 결정한다. 정책이 이것을 허용하지 않는다면, 라이센스 요구는 단계 626에서 실패하고 단계 628에서 에러가 API(306)에 리턴될 것이다.

단계 630에서, 라이센스 발행 실체는 권리 라벨(308)을 검증한다. 권리 라벨 상의 디지털 서명이 검증되고, 라이센스 발행 실체가 권리 라벨의 발행자(권리 라벨을 서명한 실체)가 아니라면, 라이센스 발행 실체는 권리 라벨의 발행자가 다른 신뢰된 실체(예를 들면, 라이센스 발행 실체가 키 요소(material)를 공유할 수 있도록 되어 있는 실체)인지 여부를 결정한다. 권리 라벨이 검증되지 못한거나 신뢰된 실체에 의해 발행되지 못한다면, 라이센스 요구는 단계 626에서 실패하고 에러가 단계 628에서 API(306)에 리턴될 것이다.

모든 검증이 발생한 후, 라이센스 발행 실체는 권리 라벨(308)을 각 승인된 라이센시에 대한 라이센스로 번역한다. 단계 632에서, 라이센스 발행 실체는 각 라이센시에 발행될 라이센스에 대한 각 권리 기술을 생성한다. 각 라이센스시에 대해, 발행 실체는 권리 라벨의 권리 기술에 명명된 주체에 대한, 그 라이센시의 공개키 인증서에 명명된 주체를 평가한다. 권리 기술은 모든 권리 또는 권리 세트에, 라이센스의 그 권리 또는 권리 세트를 작용할 수 있는 주체 세트를 할당한다. 이러한 라이센시의 주체가 연관되는 모든 권리 또는 권리 세트에 대해, 그 권리 또는 권리 세트가 라이센스에 대한 새로운 데이터 구조에 복사된다. 결과적인 데이터 구조는 특정 라이센시에 대한 라이센스의 권리 기술이다. 이러한 프로세스의 일부로서, 라이센스 발행 실체는 권리 라벨의 권리 기술에서 권리 또는 권리 세트의 임의의 것과 연관될 수 있는 임의의 선조건을 평가한다. 예를 들어, 권리는 라이센스 발행 실체가 지정된 시간 후에 라이센스를 발행하는 것을 제한하는 이것과 연관된 시간 선조건을 가질 수 있다. 이 경우에, 발행 실체는 현재 시간을 체크할 필요가 있고, 선조건에 지정된 시간을 경과했다면, 발행 실체는 라이센시의 주체가 그 권리가 연관되었더라도 라이센시에게 그 권리를 발행할 수 없을 것이다.

단계 636에서, 발행 실체는 권리 라벨(308)로부터 (PU-RM(DES1)) 및 (DES1(CK))를 취하여, (PR-RM)을 적용하고 (CK)를 얻는다. 그리고나서, 발행 실체는 (PU-ENTITY)를 이용하여 (CK)를 재암호화하여 라이센시의 공개키 인증서가 (PU-ENTITY(CK))가 되게 한다. 단계 638에서, 발행 실체는 생성된 권리 기술과 (PU-ENTITY(CK))와 연관시키고 (PR-RM)을 이용하여 결과적인 데이터 구조를 디지털로 서명한다. 이러한 서명된 데이터 구조는 이러한 특정 라이센시에 대한 라이센스이 다.

단계 640에서, 발행 실체가 특정 요구에 대해 생성한 라이센스가 더 이상 없는 것으로 결정된 경우, 제로개 이상의 라이센스를 생성할 것이다. 생성된 라이센스는 그 라이센스와 연관된 인증서 체인(그 인증서를 발행한 인증서뿐만 아니라 서버 자신의 공개키 인증서 등)과 함께, 단계 642에서 요구하는 실체로 리턴된다.

본 발명에 따른 시스템의 하나의 실시예에서, 복수의 라이센서 키들이 이용될 수 있다. 그러한 실시예에서, 권리 라벨(308)을 통해 암호화되어 라이센스로 이동하는 컨텐츠 키(CK)는 실제로 임의의 데이터일 수 있다. 하나의 특정 유용한 변동은 권리 기술의 다른 권리 또는 다른 주건(principal)과 각각 연관된 복수의 분리되고 암호화된 컨텐츠 키(CK)를 이용하는 것이다. 예를 들어, 앨범 상의 노래의 디지털 버전은 다른 키(CK)로 모두 암호화될 수 있다. 이들 키들(CK)은 동일한 권리 라벨에 포함되지만, 하나의 주건은 노래들 중 하나를 플레이할 권리를 가지고(예를 들어, 그는 그의 라이센스에서 하나의 키를 얻을 권리만을 가지고 있다), 한편 제2 주건은 모든 노래를 플레이할 권리를 가질 수 있다(그녀는 그녀의 라이센스에서 모든 키를 가질 권리를 가진다).

바람직하게는, 본 발명에 따른 시스템은 발행(publishing) 애플리케이션/사용자들이 권리 라벨(308)의 라이센스 그룹 또는 클래스를 명명할 수 있게 한다. 그러한 실시예에서, 라이센스 발행 실체는 권리 라벨에 명명된 임의의 그룹/클래스를 평가하여, 현재의 라이센시 주체가 그 그룹 클래스의 멤버인지를 결정한다. 명명된 그룹/클래스의 멤버십이 발견되면, 발행 실체는 그룹/클래스와 연관된 권리 또는 권리 세트를 라이센스에 대해 이용되는 권리 기술 데이터 구조에 부가할 수 있다.

본 발명의 바람직한 실시예에서, RM 서버의 발행(publish) 및 라이센스 프로토콜 인터페이스는 호출 애플리케이션 또는 사용자의 인증 및 허가를 지원하고, RM 서버에 대한 관리 콘솔은 관리자가 라이센싱 및 발행(publishing) 인터페이스에 대한 액세스 제어 리스트를 생성할 수 있도록 허용한다. 이것은 서버의 고객이 사용자/애플리케이션이 다른 발행(publish)하거나 라이센싱하거나 또는 둘 다를 수행하도록 허용되는 정책을 적용할 수 있게 한다.

서명된 권리 라벨(308)의 자기-발행

본 발명의 하나의 실시예에서, SRL(308)은 요구하는 사용자 자체에 의해 서명될 수 있다. 따라서, 사용자는 연관된 컨텐츠에 대한 SRL(308)을 얻기 위해 RM 서버(320)에 접촉할 필요는 없다. 결과적으로, 자기-발행은 오프-라인 발행으로 지칭될 수 있다. 그러한 실시예에서, 사용자는 그러한 자기-발행된 SRL(308)에 기초하여 라이센스를 요구하기 위해서는 RM 서버(320)에 접촉할 필요가 있다. 발행 실체는 그 자신의 라이센스를 발행하도록 인에이블된다는 것은 자명하다.

특히, 도 8을 참조하면, 본 실시예에서, 사용자는 RM 서버(320)로부터 공개키(PU-CERT) 및 사용자의 공개키(PU-ENTITY)에 따라 암호화되어 결국 (PU-ENTITY (PR-CERT))가 되는 대응하는 개인키(PR-CERT)를 포함하는 RM 인증서(810)를 수신함으로써, 자기-발행하도록 우선 준비된다. 이하에 더 상세하게 설명되는 바와 같이, 인증서는 그러한 RM 서버(320)가 동일한 것을 검증할 수 있도록 RM 서버(320) 의 개인키(PR-RM)에 의해 서명되어야 한다. 자명한 바와 같이, RM 인증서(810)는 사용자가 자기-발행하도록 허가한다. 또한 자명한 바와 같이, 키 쌍(PU-CERT, PR-CERT)은 (PU-ENTITY, PR-ENTITY)로부터 분리되고, 자기-발행을 위해 특정하게 채용된다. 유의할 점은, RM 인증서(810)는 사용자의 공개키(PU-ENTITY)만을 포함하고 RM 서버(320)의 개인키(PR-RM)에 의해 서명되어 그러한 RM 서버(320)가 동일한 것을 검증하는 어느 경우든 키 쌍(PU-CERT, PR-CERT)이 없이도 가능하다는 점이다.

자기-발행은 사용자가 수행되는 단계들에 대해 실질적으로 RM 서버(320)를 대신한다는 점에서 도 4에 도시된 바와 같이 발행하는 것과 다르다. 중요한 것은, 사용자는 RM 인증서(810)로부터 얻어진 바와 같이 (PR-CERT)로 (PU-RM(DES1)) 및 (DES1(rightsdata))를 포함하는 제출된 권리 라벨에 서명하여(즉, S(PR-CERT)), 결국 서명된 권리 라벨(SRL, 308)이 되게 한다. 자명한 바와 같이, 사용자는 그러한 RM 인증서(810)로부터 (PU-ENTITY(PR-CERT))를 얻고 거기에 (PR-ENTITY)를 적용함으로써, RM 인증서(810)로부터 (PR-CERT)를 얻는다. 그렇지만, 유의할 점은, 사용자는 특히 사용자가 (PR-RM)이 (PU-RM(DES1))에 적용하도록 하지 못하게 하는 한, RM 서버(320)는 제출된 권리 라벨의 권리를 시행할 수 있다는 점이다. 따라서, RM 서버(320) 자체는 라이센스가 자기-발행된 SRL(308)에 기초하여 요구될 때 검증을 수행해야 한다.

일단 사용자가 SRL(308)을 자기-발행한 경우, 사용자는 동일한 것을 생성하도록 채용되는 그러한 자기-발행된 SRL(308) 및 RM 인증서(810)를 컨텐츠에 연관시키고, SRL(308) 및 RM 인증서(810)를 가지는 그러한 컨텐츠가 다른 사용자에게 배 포된다. 그런 후, 다른 사용자가 도 6a 및 6b에 도시된 바와 거의 동일한 방식으로 RM 서버(320)로부터 컨텐츠에 대한 라이센스를 요구하고 획득한다. 여기에서, 라이센스-요구 사용자는 컨텐츠에 연관되는 대로 자기-발행된 SRL(308) 및 RM 인증서(810)를 모두 RM 서버(320)에 제출한다. 그리고나서, RM 서버(320)는 대응하는 (PU-RM)에 기초하여 RM 인증서(810)의 S(PR-RM)을 검증하고, RM 인증서(810)로부터 (PU-CERT)를 얻는다. 그리고나서, RM 서버(320)는 얻어진 (PU-CERT)에 기초하여 SRL(308)의 S(PR-CERT)를 검증하고, 이전과 같이 계속된다. 그러나, 유의할 점은, 사용자는 RM 서버(320)가 SRL(308)의 권리를 시행할 수 있다는 것을 검증하지 못하므로, 상기 제시되었던 바와 같이, RM 서버(320) 자체는 이때 검증을 수행해야 한다는 점이다.

권리 템플릿

상기 제시된 바와 같이, 사용자에게는 사용자 또는 사용자 클래스를 정의하고, 각 정의된 사용자 또는 사용자 클래스에 대한 권리를 정의한 후 임의의 이용 조건을 정의함으로써 권리 라벨의 대부분의 임의의 다양한 또는 여러 종류의 권리 데이터를 생성할 수 있는 자유가 주어진다. 그러나, 중요한 것은, 특히 동일한 사용자 또는 사용자 클래스, 권리 및 조건들이 다른 컨텐츠에 대해 반복적으로 정의되는 경우에, 복수의 권리 라벨에 대해 권리 데이터를 반복적으로 정의하는 것은 성가시고 반복적일 수 있다. 그러한 상황은, 예를 들면 사용자가 특정 정의된 사용자 팀들과 공유되어야 하는 다른 컨텐츠를 반복적으로 발행하고 있는 회사 또는 사무실 환경에서 발생할 수 있다. 그러한 상황에서, 그리고 본 발명의 하나의 실 시예에서, 사용자가 권리 라벨을 생성하는 것과 관련하여 반복적으로 채용할 수 있는 권리 템플릿이 생성되고, 여기에서 권리 템플릿은 이미 그 안에 선정된 사용자 세트 또는 사용자 클래스, 각 정의된 사용자 또는 사용자 클래스에 대한 선정된 권리, 및 선정된 이용 조건을 포함한다.

본 발명의 하나의 실시예에서, 그리고 도 9를 이제 참조하면, 권리 템플릿(900)는 권리 라벨에 있는 것과 실질적으로 동일한 권리 데이터를 가지고 있다. 그러나, (DES1) 및/또는 (CK)가 컨턴트가 발행될 때까지는 알지 못하므로, 권리 라벨의 경우와 마찬가지로, 권리 데이터는 그러한 (DES1) 또는 (CK)에 따라 암호화될 수 없다. 본 발명의 하나의 실시예에서, 암호화되지 않은 권리 데이터를 가지는 권리 템플릿(900)은 도 4의 단계 416에서 (DES1)로 권리 데이터를 암호화하는 동안에 제출되어, (DES1(rightsdata)) 또는 (CK(rightsdata))를 생성한다. 물론, 권리 데이터가 그렇게 암호화되기 이전에 제출된 권리 템플릿(900)으로부터 검색된다.

RM 서버(320) 및 공개키(PU-RM)는 권리 템플릿이 구성되는 때에 주지되어 있다는 것이 사실일 수도 아니면 그렇지 않을 수도 있다. 또한, 알려져 있는 경우라도, 각각이 그 자신의 (PU-RM)을 가지는 하나 이상의 RM 서버(320)가 있다는 것이 사실일 수도 그렇지 않을 수도 있다. 그럼에도 불구하고, RM 서버(320) 및 그 공개키(PU-RM)은 권리 템플릿이 구성되는 때에 알려져 있고 단지 하나의 RM 서버(320)만이 채용되거나 단지 하나의 RM 서버(320)가 권리 템플릿(900)과 관련하여 채용될 수 있는 경우에, 그러한 권리 템플릿은 그 공개키(PU-RM)를 포함하여 권리 템플릿(900)로부터 기인하는 권리 라벨에 서명하는 RM 서버에 관한 정보를 그 내부 에 포함할 수 있다. 그러한 (PU-RM)은 SRL(308)에서 (DES1) 또는 (CK)를 암호화하여 (PU-RM(DES1)) 또는 (PU-RM(CK))가 되는 것으로 나타나고 있지만, 권리 라벨의 경우와 같이, 컨텐츠가 발행되기 전까지는 (DES1) 및/또는 (CK)가 알려져 있지 않으므로 권리 템플릿(900)의 (PU-RM)이 그러한 (DES1) 또는 (CK)를 암호화할 수 없다는 것은 자명하다. 본 발명의 하나의 실시예에서, 암호화되지 않은 (PU-RM)을 가지는 권리 템플릿(900)는 도 4의 단계 414에서 (PU-RM)으로 (DES1)을 암호하하는 과정에서 제출되어 (PU-RM(DES1))을 생생하거나 (PU-RM(CK))를 생성하는 과정에 있다. 물론, (PU-RM)은 채용되기 이전에 제출된 권리 템플릿(900)으로부터 검색된다.

또한, 상기 언급된 경우에도, 권리 템플릿에 포함되는 RM 서버에 대한 다른 정보는 네트워크 상에서 RM 서버를 로케이팅하기 위한 URL과 같은 참조 정보, 및 URL이 실패하는 경우 대체(fall-back) 정보를 포함할 수 있다. 어느 경우든, 권리 템플릿은 다른 것들 중에서 권리 템플릿(900) 자체를 기술하는 정보를 포함한다. 유의할 점은, 권리 템플릿은 컨텐츠 및/또는 암호화 키(CK) 및 (DES1)에 관련된 권리 라벨에 나타나는 정보와 같은 발행되어야 하는 컨텐츠와 관련된 정보를 위한 공간을 제공하고, 이러한 공간은 권리 템플릿의 실증(instantiation)이 권리 라벨로 실질적으로 변환되지 않는 경우에는 필요하지 않다.

지금까지 개시된 권리 템플릿(900)은 주로 사용자의 편의를 위한 것이지만, 어떤 경우에, 사용자는 권리 라벨에서 권리 데이터를 정의하는 무제한의 자유를 가지지 않는다는 것은 자명하며, 권리 템플릿(900)은 생성될 수 있는 권리 라벨의 범 주 또는 타입을 제한하는데 이용될 수 있다. 예를 들면, 특히 회사 또는 사무실 환경의 경우에, 특정 사용자가 항상 특정 사용자 클래스에만 컨텐츠를 발행할 수 있다는 것이나, 사용자는 특정 사용자 클래스에 컨텐츠를 발행할 수 없다는 것을 정책으로서 선정의될 수 있다. 어느 경우든, 본 발명의 하나의 실시예에서, 그러한 정책은 하나 이상의 권리 템플릿(900)에서 선정된 권리 데이터로서 실시되고, 사용자는 컨텐츠를 발행할 때 권리 라벨을 생성하기 위해 그러한 권리 템플릿을 채용하도록 제한될 수 있다. 특히, 사용자에 대한 발행 정책을 지정하는 사용자에게 가용한 권리 템플릿 또는 권리 템플릿 그룹은 본 발명의 사상 및 범주에서 벗어나지 않고서도 임의의 특정 타입의 발행 정책을 지정할 수도 있다.

제한된 사용자 등에 대해 권리 템플릿(900)을 지정하기 위해, 도 10을 참조하면, 관리자 등은 선정된 권리 데이터를 정의하고(단계 1001), 특정 RM 서버(320)와 관련된 정보와 같은 필요하고 적절한 임의의 다른 데이터를 정의함으로써(단계 1003), 권리 템플릿(900)을 사실상 구성한다. 중요한 것은, 제한된 사용자 등에 의해 이용하기 위한 권리 템플릿을 실효시키기 위해서는, 권리 템플릿(900)이 공식화되어야 한다. 즉, 권리 템플릿(900)은 제한된 사용자 등이 채용할 수 있는 권리 템플릿으로 인식 가능해져야 한다. 따라서, 본 발명의 하나의 실시예에서, 관리자 등에 의해 구성되는 권리 템플릿은 서명하기 위해 RM 서버(320)에 제출되고, 그러한 서명은 권리 템플릿을 공식화시킨다(단계 1005).

유의할 점은, 그러한 정보가 실제로 권리 템플릿(900)에 존재하는 경우에 서명하는 RM 서버(320)가 그 정보가 권리 템플릿(900)내에 있는 RM 서버(320)라는 점 이다. 또한, 유의할 점은, RM 서버(320)는 임의의 필요한 체크를 하는 경우에만 권리 템플릿(900)을 서명하건, 전혀 어떠한 체크도 하지 않고 서명할 수도 있다는 점이다. 마지막으로 유의할 점은, RM 서버로부터의 템플릿 서명 S(PR-RM-T)(-T는 서명이 ORT(900)에 대한 것이라는 것을 나타낸다)는 적어도 권리 템플릿(900)의 선정된 권리 데이터에 기초해야 하지만, 본 발명의 사상 및 범주에서 벗어나지 않고 다른 정보에 기초할 수도 있다는 점이다. 이하에 제시되는 바와 같이, 서명 S(PR-RM-T)는 권리 라벨에 통합되고 그와 관련되어 검증되며, 따라서 서명이 기초하고 있는 것은 어떤 것이든 권리 라벨에 변경되지 않는 형태로 통합될 것이다.

RM 서버(320)가 권리 템플릿(900)에 서명하고 이를 관리자 등에게 리턴할 때, 관리자는 S(PR-RM-T)를 가지는 서명되고 이제는 공식적인 권리 템플릿(900)을 수신하고(단계 1007), 공식적인 권리 템플릿(ORT, 900)을 하나 이상의 사용자들에게 이용을 위해 포워딩한다(단계 1009). 따라서, 사용자가 ORT(900)에 기초하여 컨텐츠를 발행하기 위해서, 사용자는 ORT(900)를 검색하고(단계 1011), 컨텐츠에 관한 정보, 적절한 키 정보, (DES1) 또는 (CK)에 의해 암호화되어 결국 (DES1(rightsdata)) 또는 (CK(rightsdata))가 되는 ORT(900)로부터의 권리 데이터, 및 ORT(900)로부터의 임의의 다른 정보와 같이, 임의의 필요한 정보를 제공함으로써 ORT(900)에 기초하여 권리 라벨을 구성한다(단계 1013). 중요한 것은, 사용자는 권리 라벨과 함께 ORT(900)로부터의 서명 S(PR-RM-T)를 포함한다.

그런 다음, 이전과 같이, 사용자는 권리 라벨을 서명을 위해 RM 서버(320)에 제출한다(단계 1015). 여기에서, 그러나, RM 서버(320)는 S(PR-RM-T)가 그 내부에 서 검증되지 않는다면 제출된 권리 라벨에 서명하지 않을 것이다. 즉, RM 서버(320)는 그러한 제출된 권리 라벨이 ORT(900)로부터의 서명 S(PR-RM-T)를 포함하지 않는다면, 제출된 권리 라벨에 서명하는 것을 거절함으로써, 사용자가 ORT(900) 상의 제출된 권리 라벨에 기초해야 한다는 것을 시행한다. 특히, RM 서버(320)는 그러한 S(PR-RM-T) 및 제출된 권리 라벨로부터 그러한 서명이 기초하고 있는 어떤 정보든지를 검색하고, 그리고나서 그러한 서명을 (PU-RM)에 기초하여 검증한다. 유의할 점은, 제출된 권리 라벨의 권리 데이터는 (DES1)(즉, (DES1(rightsdata)) 또는 (CK)(즉, (CK(rightsdata))에 따라 암호화된다는 점이다. 따라서, RM 서버(320)는 제출된 권리 라벨의 권리 데이터에 기초하여 서명을 검증할 수 있기 위해서는 우선 도 7와 관련하여 상기 제시되었던 암호화된 권리 데이터를 암호해제해야 한다.

일단 검증되면, RM 서버(320)는 S(PR-RM-L)로 제출된 권리 라벨을 서명하여 이전과 같이 SRL(308)을 생성한다(여기에서, -L은 서명이 SRL(308)에 대한 것이라는 것을 나타낸다). 여기에서, S(PR-RM-L)은 S(PR-RM-T)를 대신하거나 그러한 S(PR-RM-T)에 부가될 수도 있다. 부가되는 경우에, S(PR-RM-L)은 S(PR-RM-T)에 부분적으로 기초하고 있다. 유의할 점은, (PR-RM)이 S(PR-RM-T) 및 S(PR-RM-L) 모두를 생성하도록 채용되거나, 다른 (PR-RM)이 S(PR-RM-T) 및 S(PR-RM-L) 각각에 대해 채용될 수 있다는 점이다. RM 서버(320)가 권리 라벨에 서명하고 SRL(308)을 사용자에게 리턴할 때, 사용자는 S(PR-RM-L)을 가지는 SRL(308)을 수신하고(단계 1017) 및 진행하여, 이전과 같이, 이를 발행되는 컨텐츠에 연관시킨다.

유연한 권리 템플릿

ORT(900)의 서명 S(PR-RM-T)는 적어도 부분적으로는 ORT(900)의 선정된 권리 데이터에 기초하고 있는 경우, SRL(308)내에 있는 것처럼 보이는 그러한 권리 데이터는 변형되거나 가변될 수 없다. 그렇지 않으면, SRL(308)에 나타나는 S(PR-RM-T)는 검증되지 않을 것이다. 그럼에도 불구하고, 본 발명의 하나의 실시예에서, ORT(900)내의 권리 데이터는 ORT(900)와 함께 포함되는 소정 규칙내에서 가변될 수 있다. 예를 들어, 규칙들은 SRL(308)에 포함되는 2가지 세트의 권리 데이터 중 하나를 지정하거나, 다른 것들의 세트 중에서의 선택을 허용한다. 자명한 바와 같이, 규칙은 본 발명의 사상 및 범주에서 벗어나지 않는 임의의 적절한 구문으로 제시되는 임의의 특별한 규칙일 수 있다. 여기에서, 규칙들은 권리 라벨이 생성되는 때에 사용자에 대한 적절한 규칙 인터프리터(interpreter)에 의해 해석된다. 권리 데이터는 가변될 수 있지만, 규칙은 마찬가지로 가변되지 않으며, 따라서 ORT(900)에 대한 템플릿 서명 S(PR-RM-T)는 적어도 부분적으로는 규칙에 기초하고 있지만 권리 데이터 자체에는 기초하지 않는다. 그렇다면, ORT(900)와 함께 포함되는 규칙들은 SRL(308)도 함께 포함되어야 한다.

본 발명의 하나의 실시예에서, ORT(900)의 선정된 권리 데이터는 상기 제시된 바와 같이, 부분적으로는 고정되어 있고 가변되지 않고, 부분적으로는 가변적이고 유연하며 규칙-구동된다. 여기에서, ORT(900)에 대한 템플릿 서명 S(PR-RM-T)은 권리 데이터의 고정된 부분의 적어도 하나에 적어도 부분적으로 기초하고 있고, 규칙 데이터의 유연한 부분의 규칙에 적어도 부분적으로 기초하고 있다.

ORT(900)와 같은 권리 템플릿의 유연성은 이하에 제시된 바와 같이 수개의 방법들 중 임의의 하나로 표현될 수 있다.

상기 제시되고 도 4a와 관련하여 알 수 있는 바와 같이, ORT(900)는 하나 이상의 특정 사용자 또는 사용자 그룹 각각 및 그에 대한 권리를 지정하고, 여기에서 그러한 사용자들은 그러한 SRL(308)에 기초하여 라이센스(16)를 얻을 수 있다. 그러나, 그러한 ORT(900)는 특히 그러한 ORT(900)에 기초하여 SRL(308)을 발행할 때 발행자에게 그러한 사용자, 그러한 권리, 임의의 관련된 조건 등을 지정하는 것과 관련된 임의의 옵션을 허용하지 않는다. 즉, 지금까지 개시된 ORT(900)는 ORT(900)에 기초한 라이센스(16)를 얻을 수 있는 그러한 사용자, 라이센스(16)내에서 지정될 수 있는 그러한 사용자들의 권리, 라이센스(16)에 지정되어야 하고 그러한 권리를 채용하기 위해 그러한 사용자가 만족시켜야 하는 조건들을 정의할 때 임의의 유연성을 발행자에게 허용하지 않는다.

따라서, 본 발명의 하나의 실시예에서, 발행자가 ORT(900)에 기초하여 발행하는 동안에 그러한 사용자, 권리 및 조건을 선택할 때 채용될 수 있는 대응하는 규칙뿐만 아니라 임의의 요구되는 사용자 서브셋, 각 사용자에 대한 임의의 요구되는 라이센스 권리의 서브셋, 및 권리에 대한 임의의 요구되는 조건 서브셋을 그 내부에 지정함으로써 ORT(900)가 유연하게 된다. 규칙과 함께 그러한 사용자, 권리, 및 조건을 나타내는 의사-코드가 이하와 같이 나타난다.

<RIGHTS TEMPLATE>

...

<USERS, RIGHTS, CONDITIONS>

<USERS>

<DEFINITION OF ALLOWED USERS>

...

</DEFINITION OF ALLOWED USERS>

<RULES>

...

</RULES>

</USERS>

<RIGHTS>

<DEFINITION OF ALLOWED RIGHTS>

...

</DEFINITION OF ALLOWED RIGHTS>

<RULES>

...

</RULES>

</RIGHTS>

<CONDITIONS>

<DEFINITION OF ALLOWED CONDITIONS>

...

</DEFINITION OF ALLOWED CONDITIONS>

<RULES>

...

</RULES>

</CONDITIONS>

</USERS, RIGHTS, CONDITIONS>

...

</RIGHTS TEMPLATE>

예를 들면, 사용자에 대해, ORT(900)는 발행자가 조직내의 임의의 사용자, 또는 선정된 그룹내의 조직내의 사용자들만, 또는 단지 지정된 개별적인 사용자들만, 또는 그 조합을 지정할 수 있게 한다. 마찬가지로, ORT(900)는 발행자가 임의의 사용자 또는 사용자 그룹을 지정할 수 있게 하지만, 조직내의 어떤 다른 이용자도 그러한 라이센스(16)를 얻을 수 없는 경우에, 라이센스(16)를 얻을 수 있는 '최종 사람'으로서 발행자가 특정 관리 이용자를 지정하는 것이 필요하다.

권리 및 조건들에 대해, ORT(900)는 발행자가 모든 권리를 특정 사용자 또는 사용자 그룹에 부여하도록 허용하거나, 특정 사용자 또는 사용자 그룹을 특정 권리로 제한하거나, 다른 사용자가 모든 권리를 얻을 수 있는 한 하나의 사용자를 특정 권리로 제한하거나, 또는 이들의 조합도 가능하다. 마찬가지로, ORT(900)는 발행자가 예를 들면 상기 언급된 최종 사람 사용자와 같이 특정 사용자 또는 사용자 그룹에게 모든 권리를 부여하는 것이 필요하다. 유사하게, ORT(900)는 제1 타입의 사용자에 대한 권리가 제1 방식으로 조절되고 제2 타입의 사용자에 대한 동일한 권리가 제2 방식으로 조절되는 것이 필요하다. 자명한 바와 같이, ORT(900)에서 사용자, 권리, 조건 등을 지정하는 방식은 본 발명의 사상 및 범주에서 벗어나지 않고서 임의의 방식일 수 있다.

상기 제시되고 도 4a 및 9와 관련하여 알 수 있는 바와 같이, 그로부터 도출된 ORT(900) 및 SRL(308)은 하나 이상의 특정 사용자 또는 사용자 그룹의 각각 및 그 권리를 지정할 수 있고, 그러한 사용자들은 그러한 SRL(308)에 기초하여 라이센스(16)를 얻을 수 있다. 그러나, 그러한 ORT(900)는 특히 마찬가지로 하나 이상의 사용자 또는 사용자 그룹 각각을 지정하지 않고, 그러한 사용자는 ORT(900)를 이용하여 발행할 수 있다. 즉, 지금까지 개시된 ORT(900)는 그러한 ORT(900)를 이용하여 발행하는 사용자에 관한 임의의 선택성을 허용하지 않는다.

따라서, 본 발명의 하나의 실시예에서, ORT(900)를 채용하여 발행할 수 있는 하나 이상의 사용자 또는 사용자 그룹의 각각을 지정함으로써, ORT(900)가 유연하게 되고, 발행자가 ORT(900)를 채용하여 발행하기를 원하는 것을 보장하는 방법을 제시하는 대응하는 규칙은 실제로 ORT(900) 내에서 발행자 지정되고, 따라서 그러한 ORT(900)에 기초하여 발행하도록 ORT(900)에 의해 허용된다. 발행하도록 허용되는 그러한 사용자를 나타내는 의사 코드는 이하와 같다.

<RIGHTS TEMPLATE>

...

<USERS ALLOWED TO PUBLISH>

<DEFINITION OF ALLOWED USERS>

...

</DEFINITION OF ALLOWED USERS>

<RULES>

...

</USERS ALLOWED TO PUBLISH>

...

</RIGHTS TEMPLATE>

그러므로, 하나의 예로서, 회사의 자금부서는 생성된 특정 자금 ORT(900)를 가질 수 있고, 여기에서 특정 자금 ORT(900)는 그러한 자금 부서의 모든 멤버 및 회사의 회계부의 모든 멤버들이 그러한 자금 ORT(900)를 이용할 수 있도록 지정한다. 마찬가지로, 회사의 법무 부서는 생성된 특정 법적 ORT(900)를 가질 수 있고, 여기에서 특정 법적 ORT(900)는 변호사인 그러한 법무 부서의 모든 멤버들이 그러한 법적 ORT(900)를 이용할 수 있도록 지정한다.

여기에서, 유의할 점은, 대응하는 규칙은 잠재적인 발행자가 ORT(900)에 구체적으로 리스트되거나 잠재적인 발행자가 ORT(900)에 구체적으로 리스트된 그룹의 멤버인 것이 필요하다는 점이다. 다르게는, 대응하는 규칙은 잠재적인 발행자가 ORT(900)내에 구체적으로 리스트되고 잠재적인 발행자는 ORT(900)에 구체적으로 리스트된 그룹의 멤버이거나, 잠재적인 발행자는 다른 더 복잡한 조건을 만족시키는 것이 필요하다. 자명한 바와 같이, 대응하는 규칙은 본 발명의 사상 및 범주에서 벗어나지 않는 임의의 적절한 규칙일 수 있다.

상기 설명되고 도 4a와 관련하여 알 수 있는 바와 같이, SRL(308)은 (DES1) 또는 (CK)를 암호화하여 (PU-RM(DES1)) 또는 (PU-RM(CK))를 생성하는 RM 서버(320)의 공개키를 포함하고, 그럼으로써 그러한 RM 서버(320)만이 라이센스를 요구하는 사용자에게 바행하는 동안에 (DES1) 또는 (CK)를 액세스할 수 있다. 대응하여, 도 9와 관련하여 보여지는 ORT(900)는 그러한 (PU-RM)을 포함하고, 그러한 ORT(900)의 이용은 결국 RM 서버(320)에 구체적으로 묶여지는 SRL(308)이 되고 또한 결국 그러한 RM 서버(320)에 구체적으로 묶여지는 라이센스(16)가 된다.

따라서, 본 발명의 하나의 실시예에서, 그러한 ORT(900)에 기초하여 권리 라벨을 구성할 때 그 대응하는 (PUx-RM)을 통해 하나 이상의 그러한 다른 RM 서버(320)를 선택하는 방법을 지정하는 대응하는 규칙뿐만 아니라, 수개의 다른 RM 서버(320) 각각의 공개키(PUx-RM)를 그 내부에 포함함으로써 ORT(900)가 유연하게 된다. 규칙과 함께 라이센싱하도록 허용되는 그러한 RM 서버(320)를 나타내는 의사 코드가 이하와 같이 나타난다.

<RIGHTS TEMPLATE>

...

<LICENSING SERVERS>

<SERVER 1>

<NAME>

...

</NAME>

<ADDRESS>

...

</ADDRESS>

<PUBLIC KEY>

...

</PUBLIC KEY>

</SERVER 1>

<SERVER 2>

<NAME>

...

</NAME>

<ADDRESS>

...

</ADDRESS>

<PUBLIC KEY>

...

</PUBLIC KEY>

</SERVER 2>

...

<RULES>

...

</RULES>

</LICENSING SERVERS>

...

</RIGHTS TEMPLATE>

예를 들어, ORT(900)는 각각 제1, 제2 및 제3 RM 서버(320)에 대응하는 공개키(PU1-RM), (PU2-RM) 및 (PU3-RM), 및 그러한 ORT(900)로부터 도출된 권리 라벨이 그러한 제1, 제2 및 제3 RM 서버(320)의 임의의 하나 또는 모두를 포함할 수 있는 것을 지정하는 규칙을 지정할 수 있다. 여기에서, 유의할 점은, 그러한 제1, 제2 및 제3 RM 서버(320)는 발행자 조직내 및/또는 발행자의 조직 외부의 RM 서버(320)일 수 있다. 후자의 경우에, 발행자 조직 외부의 사용자들에게는 그러한 사용자가 특정 RM 서버(320)의 임의의 하나로부터 라이센스(16)를 얻는 권리를 가지는 경우에 그러한 발행자에 의해 발행되는 컨텐츠(12)로의 액세스가 제공될 수 있다.

이제 자명한 바와 같이, SRL(308)로 나타나는 ORT(900)로부터 각 특정 (PUx-RM)을 선택하는 경우의 발행자는 (CK) 또는 (DES1)(이하에서는, '(CK)'또는 그 등가) 중 하나를 암호화하는 것으로 그러한 (PUx-RM)을 SRL(308)내에 실제 배치한다. 하나의 예로서, 발행자가 ORT(900)로부터 (PU1-RM) 및 (PU3-RM)을 선택하는 경우, 결과적인 SRL(308)은 (PU1-RM(CK)) 및 (PU3-RM(CK)) 모두를 포함할 것이다. 결과적으로, 사용자는 제1 또는 제3 RM 서버(320) 중 어느 하나로부터 라이센스(16)를 얻도록 허용되어, 그러한 사용자는 그러한 RM 서버(320)로부터 그러한 라이센스(16)를 얻을 권한을 가지고 있다고 추정한다.

유사한 방식으로, 상기 제시되고 도 9와 관련되어 알 수 있는 ORT(900)는 발행 동안에 그러한 ORT(900)에 기초하여 SRL(308)을 제공할 수 있는 특정 RM 서버(320)를 지정하지 않는다. 따라서, 본 발명의 하나의 실시예에서, 그러한 ORT(900)에 기초하여 권리 라벨을 구성할 때 그 대응하는 (PUx-RM)을 통해 RM 서버(320) 중에서 선택하는 방법을 지정하는 대응하는 규칙뿐만 아니라, 발행하도록 채용될 수 있는 하나 이상의 특정 RM 서버(320)의 각각의 공개키(PUx-RM)를 그 내부에 포함함으로써 ORT(900)가 유연하게 된다. 상기와 유사하게, 규칙과 함께 발행하도록 허용되는 그러한 RM 서버(320)를 나타내는 의사-코드가 이하와 같이 나타난다.

<RIGHTS TEMPLATE>

...

<PUBLISHING SERVERS>

<SERVER 1>

<NAME>

...

</NAME>

<ADDRESS>

...

</ADDRESS>

<PUBLIC KEY>

...

</PUBLIC KEY>

</SERVER 1>

<SERVER 2>

<NAME>

...

</NAME>

<ADDRESS>

...

</ADDRESS>

<PUBLIC KEY>

...

</PUBLIC KEY>

</SERVER 2>

...

<RULES>

...

</RULES>

</PUBLISHING SERVERS>

...

</RIGHTS TEMPLATE>

예를 들어, ORT(900)는 상기 언급된 제1, 제2 및 제3 RM 서버(320)에 각각 대응하는 상기 언급된 공개키(PU1-RM), (PU2-RM) 및 (PU3-RM), 및 권리 라벨이 단지 그러한 제1, 제2 또는 제3 RM 서버(320)에 의해서만 그러한 ORT(900)로부터 도출될 수 있다는 것을 지정하는 규칙을 지정할 수 있다. 다르게는, 규칙은 제1 RM 서버가 가용한 경우에 채용될 수 있다는 것을 지정하고, 그 경우에, 제2 또는 제3 RM 서버(320)가 채용될 수 있는 것도 가능하다. 이전과 같이, 그러한 제1, 제2 및 제3 RM 서버(320)는 발행자의 조직 내부 및/또는 발행자의 조직 외부의 RM 서버(320)일 수 있다.

그러한 ORT(900)에 기초하여 발행하도록 채용될 수 있는 ORT(900)내의 RM 서버(320)의 리스트는 특히 그러한 리스트가 그러한 SRL(308)에 이용하지 않는 한, 그러한 ORT(900)로부터 도출된 SRL(308)에 반드시 나타날 필요는 없다. 그러나, 그러한 리스트는 그럼에도 불구하고, 본 발명의 사상 및 범주에서 벗어나지 않고서도 그러한 SRL(308)에 나타날 수 있다.

유의할 점은, 지금까지 개시된 ORT(900)는 여기에 바로 제시된 정보를 포함하고, 그럼으로써, 그러한 정보를 변경하는 유일한 방법은 ORT(900)를 변경하는 것이다. 그러나, 그러한 정보를 더 신속한 방식으로 그러한 정보를 변경할 필요가 있다는 것은 자명하다. 예를 들어, 특정 사용자가 조직의 하나 이상의 ORT(900)내 에 구체적으로 더 이상 리스트되지 않는 경우에, 특히, 조직이 매우 크고 사용자가 그러하 s조직의 수백 또는 심지어 수천개의 그러한 ORT(900)에 리스트될 수 있는 경우에, 각 ORT(900)를 편집하여 사용자를 그로부터 제거하는 것이 귀찮은 것일 수 있다. 마찬가지로, 특정 RM 서버(320)가 조직의 하나 이상의 ORT(900)에서 라이센스(16)의 발행자로서 부가될 수 있는 경우에, 각 ORT(900)를 편집하여 RN 서버(320)를 거기에 부가하는 것은 귀찮은 것일 수 있다.

따라서, 본 발명의 하나의 실시예에서, 변경하기 쉬운 정보와 같은 특정 정보는 ORT(900)에 직접 나타날 필요가 없으나, 대신에 그러한 정보가 얻어질 수 있는 위치에 대한 참조로서 ORT(900)내에 표현될 수 있다. 그러한 참조는 예를 들면 포인터 등이 될 수 있다. 그러한 참조를 포함하는 의사-코드는 이하와 같이 나타난다.

<RIGHTS TEMPLATE>

...

<LICENSING SERVERS>

<SERVER 1>

[REFERENCE TO SERVER 1 INFORMATION]

</SEVER 1>

<SERVER 2>

[REFERENCE TO SERVER 2 INFORMATION]

</SEVER 2>

...

</LICENSING SERVERS>

...

</RIGHTS TEMPLATE>

물론, 그러한 참조를 통해 얻어지는 그러한 정보는 필요한 경우에 ORT(900)로부터 도출되는 SRL(308)에 직접 나타난다. 그러한 정보가 얻어지는 위치는 그러한 위치내의 정보를 변경하려고 시도하기를 원하는 악의적인 실체에 쉽게 접근될 수 없는 안전한 위치이어야 한다는 것은 자명하다.

자명한 바와 같이, ORT(900)내에서 참조되는 정보는 본 발명의 사상 및 범주에서 벗어나지 않는 임의의 적절한 정보일 수 있다. 예를 들면, 참조되는 그러한 정보는 발행자가 발행하는데 이용할 수 있는 특정 RM 서버(320)에 대한 공개키, 발행자가 발행하는데 이용할 수 있는 모든 RM 서버(320)에 대한 공개키 리스트, 그로부터 도출된 ORT(900) 및 SRL(308)에서 상기 언급된 최종 사람 사용자가 되는 특정 사용자, 그로부터 도출된 ORT(900) 및 SRL(308)의 모든 사용자의 리스트, 특정 사용자에 대한 권리 리스트, 특정 권리에 대한 조건 리스트, 등을 포함할 수 있다.

본 발명의 다른 실시예에서, 변경하기 쉬운 것들과 같은 특정 정보들은 와일드카드, 변수, 등을 통해 ORT(900)에 나타날 수 있다. 그러므로, 하나의 예로서, 각 사용자를 회사 ABC에서 개별적으로 지정하기 보다는, ORT(900)는 '^*@ABC'와 같은 용어를 통해 모든 그러한 사용자를 간단하게 지정할 수 있고, 여기에서 '^*'는 모든 사용자에 대한 와일드카드이고 '@ABC'는 회사 ABC를 나타낸다. 그러한 와일드카드를 포함하는 의사-코드는 이하와 같이 표시된다.

<RIGHTS TEMPLATE>

...

<USERS ALLOWED TO PUBLISH>

<DEFINITION OF ALLOWED USERS>

^*@ABC

</DEFINITION OF ALLOWED USERS>

...

</USERS ALLOWED TO PUBLISH>

...

</RIGHTS TEMPLATE>

유사한 타입의 와일드카드 이용은 즉, 회사 XYZ의 엔지니어링 부서에서 M으로 시작으로 사용자 이름을 가지는 모든 사용자를 나타내는 'M^*@engineering@XYZ', 즉 회사 PDQ의 연구 부서에서 프로젝트 X에 대한 모든 사용자들을 나타내는 '^*@projectx@research@PDQ'를 포함할 수 있다. 또한, 그러한 와일드카드, 변수 등을 통해 얻어지는 정보는 필요한 경우에 ORT(900)로부터 도출되는 SRL(308)에 직접 나타난다.

통상, ORT(900)에 기초하여 SRL(308)을 구성할 때, 그 서명 S(PR-RM-T)를 포 함하는 ORT(900)는 권리 라벨내에 배치되고, 그럼으로써 참조, 변수 및 와일드카드를 대체하고 다르게는 권리 데이터를 가변될 수 있는 ORT(900)내에 포함시키는 것을 통해 권리 라벨내에서 변형될 수 있다. 그런 후, 도 6a 및 6b와 관련하여 제시된 바와 같이, 변형된 권리 데이터를 그 안에서 가지는 권리 라벨은 서명하기 위한 적절한 RM 서버(320)에 제출되어 SRL(308)을 생성한다. 그러한 SRL(308)의 의사 코드 표현은 이하와 같다.

<SIGNED RIGHTS LABEL>

...

<TEMPLATE>

[TEMPLATE INFO]

<TEMPLATE SIGNATURE/>

</TEMPLATE>

...

[RIGHTS LABEL INFORMATION]

<RIGHTS LABEL SIGNATURE/>

...

</SIGNED RIGHTS LABEL>

그러므로, 상기 언급된 바와 같이, SRL(308)에 나타나는 ORT(900)의 서명 S(PR-RM-T)는 가변되지 않는 ORT(900)의 권리 데이터의 적어도 일부 부분에 기초해야 한다. 그렇지 않으면, 그러한 서명 S(PR-RM-T)는 그러한 ORT(900)로부터 도출된 SRL(308) 에 나타날 때 그러한 권리 데이터를 검증하지 않을 것이다. 그러나, 임의의 선정된 배열이 없는 경우, 서명 S(PR-RM-T)를 검증하려고 시도하는 검증자는 서명이 기초하고 있는 비-가변 부분이 실제 권리 데이터의 어느 부분인지 알지 못하며, 따라서 실제로 서명을 검증하는 방법을 알지 못한다.

따라서, 본 발명의 하나의 실시예에서, 권리 데이터가 ORT(900)에 나타나고 따라서 확장가능한 마크업 언어(XML) 포맷과 같은 태깅된 포맷으로 SRL(308)에 나타나며, 여기에서 서명 S(PR-RM-T)에 대한 기초가 되는 권리 데이터의 각 부분은 그럼으로써 마크된다. 예를 들면, 기초가 되는 권리 데이터의 각 부분은 특별한 태그로 마크될 수 있거나 특별한 속성을 가지는 태그로 마크될 수 있다. 마크된 부분을 가지는 그러한 ORT(900)를 나타내는 의사-코드는 아래와 같다.

<RIGHTS TEMPLATE>

...

<PUBLISHING SERVERS>

<SERVER 1, marked=yes>

...

</SERVER 1>

<SERVER 2>

...

<SERVER 2>

...

<RULES, marked=yes>

...

</RULES>

</PUBLISHING SERVERS>

...

</RIGHTS TEMPLATE>

이제 자명한 바와 같이, SRL(308)의 서명 S(PR-RM-T)를 검증하기 위해서는, 검증자는 서명 S(PR-RM-T)에 대한 기초가 되는 것으로 마크되는 SRL(308)의 권리 데이터의 각 부분을 식별하고, 그러한 마크된 부분을 검색하여 이를 적절하게 연관시켜 서명 블록을 형성하고, 그러한 서명 블록을 채용하여 서명 S(PR-RM-T)를 검증할 필요가 있다. 물론, 마크된 부분을 연관시키는 것은 본 발명의 사상 및 범주에서 벗어나지 않는 임의의 적절한 방식으로 수행될 수 있다. 예를 들어, 그러한 연관은 SRL(308)내의 각 마크된 부분의 나타남 순서에 의해서이다.

개시된 유연한 ORT(900)에 대해, 이제 도 11을 참조하면, 거기에 기초한 SRL(308) 및 라이센스(16)의 생성은 이하와 같은 방식으로 수행될 수 있다. 예비적으로, ORT(900)는 조직 내의 적절한 실체에 의해 자체적으로 저작되고, ORT(900)가 그러한 ORT(900)에 기초하여 발행하기를 원하는 임의의 발행자에게 잠재적으로 액세스가능하도록 데이터베이스 등의 내부에 적절하게 배치된다(단계 1101). 예를 들어, 그러한 ORT(900)는 회사 WBPA의 법무 부서의 임의의 사용자에게 권리를 부여 하고(즉, ^*@legal@WBPA), 발행자가 그러한 각 사용자에 대한 임의의 권리 및 각 권리에 대한 임의의 조건을 지정하도록 허용하며, 그러한 법무 부서의 모든 실행 멤버들(즉, ^*@exec@legal@WBPA)을 그러한 ORT(900)에 기초하여 발행할 수 있는 것으로 정의하며, 각 공개키(PU1-RM), (PU2-RM), (PU3-RM)에 의해 실별되는 라이센스(16)를 발행하기 위한 3가지 특정 RM 서버(320)를 지정할 수도 있다. 데이터베이스 등에 저장되는 ORT(900)는 상기와 유사한 방식으로, ORT(900)의 특징의 기술을 제시하는 기술부(decriptive portion)를 포함한다. ORT(900)를 저작하는 동안에, 그 저자는 변형되어서는 안되는 권리 데이터의 부분에 적절하게 마크하고 권리 데이터의 그러한 마크된 부분에 기초하여 ORT(900)를 서명함으써 결국 그러한 ORT(900)에 포함되는 디지털 서명이 된다.

그런 다음, 저자는 일부 종류의 컨텐츠(12)를 기안하고 그러한 저작된 컨텐츠(12)를 발행하기로 결심한다(단계 1103). 따라서, 발행자로서 행동하고 있는 그러한 저자는 컨텐츠 키(CK)로 컨텐츠(12)를 암호화하고(단계 1105), 상기 언급된 데이터베이스 등에서 관심사가 되는 하나 이상의 ORT(900)를 탐색하며, 각 ORT(900)의 기술부에 추정적으로 기초하여 저자/발행자가 이용하기 위한 적절한 ORT(900)를 선택한다(단계 1107). 본 발명의 하나의 실시예에서, 데이터베이스 등의 각 ORT(900)가 발행자에게 표시되지만, 발행자가 ORT(900)내에서 이들 이용할 수 있는 것으로 정의되는 경우에만 그렇다. 그러므로, 상기 제시된 ORT(900)의 예에 대하여, 그러한 ORT(900)는 그러한 발행자가 회사 WBPA의 법무 부서의 실행 멤 버인 경우에만 발행자에게 나타나고, 대응하여 발행자는 그러한 발행자가 회사 WBPA의 법무 부서의 실행 멤버인 경우에만 ORT(900)를 이용할 수 있다. 그렇지 않으면, 다른 ORT(900)가 그러한 발행자의 발행 수요를 만족한다고 가정하여 발행자는 다른 ORT(900)를 이용해야 한다.

이제, 상기 제시된 ORT(900)의 예가 발행자에 의해 사실상 이용가능한 것으로 추정하면, ORT(900)는 발행자에게 제공되고, 발행자에게는 ORT(900)에 지워지는 규칙 및 제한에 일치하여 권리 데이터를 변형할 기회가 주어진다(단계 1109). 그러므로, 상기 제시된 ORT(900)의 예에 기초하여, 발행자는 권리의 수취인으로서 회사 WBPA의 법무 부서의 하나 이상의 사용자들 중 임의의 하나를 선택할 수 있고, 각 사용자에 대한 임의의 권리 및 각 권리에 대한 임의의 조건을 선택할 수 있다.

일단 저자가 권리 데이터를 ORT(900)로부터 변형하는 것을 종료한다면, 발행자는 상기 제시되었던 것과 유사한 방식으로 그러한 변형된 권리 데이터에 기초하여 발행한다(단계 1111). 여기에서, (PU1-RM), (PU2-RM) 및 (PU3-RM) 각각에 따라 암호화되어 (PU1-RM(CK)), (PU2-RM(CK)) 및 (PU3-RM(CK))를 생성하는 컨텐츠 키(CK) 및 다른 데이터와 함께, ORT(900)로부터의 변형된 권리 데이터 및 ORT(900)로부터의 서명이 권리 라벨에 배치되고, 권리 라벨이 서명을 위해 적절한 RM 서버에 전송되어 그에 기초한 SRL(308)을 생성한다는 것은 자명하다. 그런 다음, 발행자는 SRL(308) 및 암호화된 컨텐츠(12)를 연관시켜 패키지(13)를 형성하고, 암호화된 컨텐츠(12)를 가지는 패키지(13)를 하나 이상의 사용자에게 정당하게 배포한다(단계 1113).

패키지(13)를 수신하고 컨텐츠(12)를 렌더링하기 원하는 경우, 특정 사용자는 패키지(13)의 SRL(308) 및 적절한 인증서를, 각 공개키(PU1-RM), (PU2-RM) (PU3-RM)에 의해 식별된 바와 같이 ORT(900)를 통해 SRL(308)에서 지정된 3개의 특정 라이센스-발행(issuing) RM 서버(320) 중 하나에 제공하고(단계 1115), 적절한 경우에 사용자는 RM 서버(320)로부터 라이센스(16)를 수신한다(단계 1117). 자명한 바와 같이, 권리 부여 RM 서버(320)는 SRL(308)의 서명이 검증되는 경우에만, 그리고 SRL(308)에 배치된 ORT(900)의 서명이 검증되는 경우에만 그러한 라이센스를 발행하고, 여기에서 ORT(900)의 서명은 SRL(308)내에서 적절하게 마크된 권리 데이터에 대해 검증된다. 또한, 자명한 바와 같이, 권리 부여 RM 서버(320)는 SRL(308)내의 (PUx-RM(CK))를, (CK)를 암호화하여 (PU-USER(CK))를 형성하는 사용자의 공개키(PU-USER)로 대체하고, 여기에서 (PU-USER)는 제공된 인증서로부터 얻어진다. 물론, 라이센스(16)가 사용자에게 권리를 부여하여 원하는 방식으로 컨텐츠(12)를 렌더링한다고 추정하면, 사용자는 실제로 그러한 라이센스(16)에 기초하여 그러한 컨텐츠(12)를 렌더링한다.

결론

본 발명과 관련하여 수행되는 프로세스를 실시하는데 필요한 프로그래밍은 비교적 직접적이고, 관련 프로그래밍 공중에게 명백한 것이다. 따라서, 그러한 프로그래밍은 여기에 첨부하지 않는다. 임의의 특정 프로그래밍은 본 발명의 사상 및 범주에서 벗어나지 않고서 본 발명을 실시하도록 채용될 수 있다.

그러므로, 서명된 권리 라벨을 통해 디지털 컨텐츠 및 서비스에 대한 이용 라이센스를 발행하기 위한 시스템 및 방법을 설명했다. 본 기술분야의 숙련자라면, 본 발명의 양호한 실시예에 다수의 변경 및 변형이 가해질 수 있다는 것과, 그러한 변경 및 변형이 본 발명의 사상에서 벗어나지 않고서도 만들어질 수 있다는 것은 자명하다. 그러므로, 첨부된 특허청구의 범위는 본 발명의 사상 및 범주에 드는 모든 그러한 등가 변동을 포함하려는 것이다.

상기 설명에서, 본 발명은 임의의 형태의 디지털 컨텐츠(12)의 제어된 렌더링 또는 플레이를 허용하는 새롭고 유용한 아키텍쳐 및 방법을 포함하고, 그러한 제어는 유연하여 그러한 디지털 컨텐츠(12)의 컨텐츠 소유자/개발자에 의해 정의가능하다는 것을 알 수 있다. 그러한 아키텍쳐는 정의된 개인 그룹 또는 개인 클래스에서 문서가 공유되어야 하는 사무실 또는 회사 환경에서 특히 그러한 제어된 렌더링을 허용하고 용이하게 한다. 아키텍쳐는 그러한 환경내의 디지털 컨텐츠(12)의 발행자에게 사용자 및 그러한 디지털 컨텐츠에 대한 그러한 사용자의 권리를 지정하는 선정된 템플릿/ORT(900)를 제공하며, 템플릿/ORT(900)는 사실상 유연하다.

본 발명은 라이센스 서버가 컨텐츠에 대응하는 디지털 라이센스를 컨텐츠를 렌더링하기 원하는 하나 이상의 사용자들에게 발행할 수 있도록 하는 디지털 컨텐츠를 발행하는 시스템 및 방법을 제공하여 본 기술분야에서의 다양한 요구를 충족시킨다.

<부록 1>

권리 데이터 샘플

<부록 2>

서명된 권리 라벨(308, SRL)의 예

Claims (13)

1. 라이센스 서버가 컨텐츠에 대응하는 디지털 라이센스를, 상기 컨텐츠를 렌더링하기 원하는 하나 이상의 사용자에게 발행할 수 있도록 하는 디지털 컨텐츠 발행 방법으로서,

   컨텐츠 키(CK)에 따라 상기 컨텐츠를 암호화하여 암호화된 컨텐츠(CK(content))를 생성하는 단계;

   상기 라이센스 서버에 대한 공개키(PU-RM)에 따라 상기 컨텐츠 키(CK)를 보호하는 단계;

   사전 정의된 사용자 세트, 각각의 정의된 사용자에 대한 사전 정의된 권리 및 사전 정의된 사용 조건을 식별하는 정보를 포함하며, 복수의 컨텐츠 조각에 대한 권리들을 정의하는데 있어서 반복적으로 사용되도록 적용되는 권리 템플릿을 검색하는 단계;

   검색된 상기 권리 템플릿으로부터 상기 컨텐츠와 연관되는 권리 데이터를 검색하는 단계;

   검색된 상기 권리 템플릿으로부터 검색된 상기 권리 데이터를 변형하기 위한 규칙을 검색하는 단계;

   상기 규칙에 따라 상기 권리 템플릿으로부터 검색된 상기 권리 데이터를 변형하는 단계;

   상기 권리 데이터 및 상기 보호된 컨텐츠 키(CK)를 권리 라벨로서 서명을 위해 상기 라이센스 서버에 제출하고, 상기 라이센스 서버가 상기 권리 라벨을 확인하고, 유효하다면 상기 라이센스 서버에 대한 공개키(PU-RM)에 대응하는 개인키(PR-RM)에 기초하여 또한 적어도 부분적으로는 권리 데이터에 기초하여 디지털 서명을 생성함으로써 서명된 권리 라벨(SRL)을 생성하며, 상기 SRL을 리턴하는 단계;

   상기 리턴된 SRL을 수신하고 상기 수신된 SRL과 상기 암호화된 컨텐츠(CK(content))를 연관시켜 컨텐츠 패키지를 형성하는 단계; 및

   상기 컨텐츠 패키지를 상기 하나 이상의 사용자들에게 배포하고, 그럼으로써 상기 컨텐츠를 렌더링하기 원하는 사용자는 상기 컨텐츠 패키지로부터 상기 SRL을 검색하고 검색된 상기 SRL을 상기 컨텐츠에 대응하는 상기 라이센스에 대한 요청의 일부로서 상기 라이센스 서버에 제출하며, 그럼으로써 상기 라이센스 서버는 상기 라이센스 서버에 대한 공개키(PU-RM)에 기초하여 또한 보호된 권리 데이터에 적어도 부분적으로 기초하여 상기 SRL의 서명을 검증하고, 상기 SRL의 권리 데이터에 액세스하여 이를 검토함으로써 상기 사용자가 상기 라이센스에 대한 권한이 부여되었는지 여부를 결정하며, 권한이 부여된 경우에는 상기 사용자에게 상기 라이센스를 발행하는 단계 - 상기 라이센스는 상기 사용자에게 액세스 가능한 보호된 형태의 컨텐츠 키(CK)를 포함함 -

   를 포함하는 디지털 컨텐츠 발행 방법.
2. 제1항에 있어서,

   사용자 세트, 각 사용자에게 부여된 임의의 권리 및 각 권리에 대한 임의의 조건을 포함하는 상기 검색된 권리 템플릿으로부터 권리 데이터를 검색하고, 상기 사용자, 권리 및 상기 권리 데이터의 조건을 변형하기 위해 검색된 상기 권리 템플릿으로부터 규칙들을 검색하는 단계; 및

   상기 규칙들에 따라 상기 권리 템플릿으로부터 상기 사용자, 권리 및 상기 권리의 조건을 변형하는 단계

   를 포함하는 디지털 컨텐츠 발행 방법.
3. 제2항에 있어서,

   상기 권리 데이터로부터 제거되지 않는 사용자를 포함하는 검색된 상기 권리 템플릿으로부터 권리 데이터를 검색하는 단계를 포함하는 디지털 컨텐츠 발행 방법.
4. 제1항에 있어서,

   상기 권리 템플릿은 상기 권리 템플릿을 이용하여 발행할 수 있는 하나 이상의 사용자를 지정하고, 상기 방법은 특정 사용자가 상기 사용자들 중 그러한 권리 템플릿을 이용하여 발행할 수 있는 사용자인 것으로 지정된 경우에만 상기 특정 사용자가 상기 권리 템플릿을 검색하는 단계를 포함하는 디지털 컨텐츠 발행 방법.
5. 제1항에 있어서,

   검색된 상기 권리 템플릿으로부터 상기 컨텐츠와 연관된 권리 데이터를 검색하는 단계 - 검색된 상기 권리 데이터는 다른 곳에 저장된 정보에 대한 참조를 포함함 -;

   상기 참조에 기초하여 상기 다른 곳에 저장된 정보를 검색하는 단계; 및

   상기 권리 템플릿으로부터의 검색된 상기 권리 데이터를 변형하여 상기 참조를 검색된 상기 정보로 대체하는 단계

   를 포함하는 디지털 컨텐츠 발행 방법.
6. 제1항에 있어서,

   검색된 상기 권리 템플릿으로부터 상기 컨텐츠와 연관된 권리 데이터를 검색하는 단계 - 검색된 상기 권리 데이터는 변수를 통해 표현된 정보를 포함함 -; 및

   상기 권리 템플릿으로부터 검색된 상기 권리 데이터를 변형하여 상기 변수를 그에 대응하는 하나 이상의 정보 조각으로 대체하는 단계

   를 포함하는 디지털 컨텐츠 발행 방법.
7. 제6항에 있어서,

   검색된 상기 권리 템플릿으로부터 상기 컨텐츠와 연관된 권리 데이터를 검색하는 단계 - 검색된 상기 권리 데이터는 변수를 통해 표현되는 사용자 클래스를 포함함 -; 및

   상기 권리 템플릿으로부터 상기 검색된 권리 데이터를 변형하여 상기 변수를 그러한 변수를 통해 표현되는 클래스의 하나 이상의 사용자들로 대체하는 단계

   를 포함하는 디지털 컨텐츠 발행 방법.
8. 복수의 라이센스 서버가 컨텐츠에 대응하는 디지털 라이센스를, 상기 컨텐츠를 렌더링하기 원하는 하나 이상의 사용자에게 발행할 수 있도록 하는 디지털 컨텐츠 발행 방법으로서,

   컨텐츠 키(CK)에 따라 상기 컨텐츠를 암호화하여 암호화된 컨텐츠(CK(content))를 생성하는 단계;

   사전 정의된 사용자 세트, 각각의 정의된 사용자에 대한 사전 정의된 권리 및 사전 정의된 사용 조건을 식별하는 정보를 포함하며, 복수의 컨텐츠 조각에 대한 권리들을 정의하는데 있어서 반복적으로 사용되도록 적용되는 권리 템플릿을 검색하는 단계;

   검색된 상기 권리 템플릿으로부터 상기 컨텐츠와 연관되는 권리 데이터를 검색하는 단계;

   상기 권리 데이터로부터, 상기 라이센스를 발행하도록 인에이블되는 각 라이센스 서버의 공개키(PUx-RM)를 검색하는 단계;

   인에이블된 상기 각 라이센스 서버의 공개키(PUx-RM)에 따라 상기 컨텐츠 키(CK)를 보호하여 각 인에이블된 라이센스 서버에 대해 보호된 컨텐츠 키(PUx-RM(CK))를 생성하는 단계;

   상기 권리 데이터 및 인에이블된 라이센스 서버 각각에 대한 보호된 컨텐츠 키(PUx-RM(CK))를 권리 라벨로서 서명을 위해 상기 라이센스 서버에 제출하고, 상기 라이센스 서버가 상기 권리 라벨을 확인하고, 유효하다면 상기 권리 데이터에 적어도 부분적으로 기초하여 디지털 서명을 생성하여 서명된 권리 라벨(SRL)을 생성하며, 상기 SRL을 리턴하는 단계;

   리턴된 상기 SRL을 수신하고 그러한 수신된 SRL과 암호화된 컨텐츠(CK(content))를 연관시켜 컨텐츠 패키지를 형성하는 단계; 및

   상기 컨텐츠 패키지를 상기 하나 이상의 사용자들에게 배포하고, 그럼으로써 상기 컨텐츠를 렌더링하기 원하는 사용자는 상기 컨텐츠 패키지로부터 상기 SRL을 검색하고 상기 검색된 SRL을 상기 컨텐츠에 대응하는 라이센스에 대한 요구의 일부로서 상기 인에이블된 라이센스 서버 중 하나에 제출하며, 그럼으로써 상기 인에이블된 라이센스 서버는 상기 SRL을 검증하고, 상기 SRL의 상기 권리 데이터에 액세스하여 이를 검토함으로써 상기 사용자가 상기 라이센스에 대한 권한이 부여되었는지 여부를 결정하며, 권한이 부여된 경우에는 그러한 라이센스 서버에 대응하는 상기 권리 데이터로부터 상기 보호된 컨텐츠 키(PUx-RM(CK))를 검색하고 그로부터 컨텐츠 키(CK)를 검색하며, 상기 사용자에게 상기 라이센스를 발행하는 단계- 상기 라이센스는 상기 사용자에게 액세스 가능한 보호된 형태의 컨텐츠 키(CK)를 포함함 -

   를 포함하는 디지털 컨텐츠 발행 방법.
9. 제8항에 있어서,

   검색된 상기 권리 데이터는 상기 SRL을 발행하기 위한 복수의 라이센스 서버를 식별하고, 상기 방법은,

   상기 권리 데이터로부터 상기 복수의 라이센스 서버를 검색하는 단계;

   상기 복수의 라이센스 서버들 중 하나를 선택하는 단계; 및

   상기 권리 데이터 및 보호된 상기 컨텐츠 키(CK)를 권리 라벨로서 서명을 위해 상기 선택된 라이센스 서버에 제출하는 단계

   를 포함하는 디지털 컨텐츠 발행 방법.
10. 라이센스 서버가 컨텐츠에 대응하는 디지털 라이센스를 상기 컨텐츠를 렌더링하기 원하는 하나 이상의 사용자에게 발행할 수 있도록 하는 디지털 컨텐츠 발행 방법으로서,

    컨텐츠 키(CK)에 따라 상기 컨텐츠를 암호화하여 암호화된 컨텐츠(CK(content))를 생성하는 단계;

    상기 라이센스 서버에 대한 공개키(PU-RM)에 따라 상기 컨텐츠 키(CK)를 보호하는 단계;

    사전 정의된 사용자 세트, 각각의 정의된 사용자에 대한 사전 정의된 권리 및 사전 정의된 사용 조건들을 식별하는 정보를 포함하며, 복수의 컨텐츠 조각에 대한 권리들을 정의하는데 있어서 반복적으로 사용되도록 적용되는 권리 템플릿을 검색하는 단계;

    상기 검색된 권리 템플릿으로부터 상기 컨텐츠와 연관되는 권리 데이터를 검색하는 단계;

    상기 권리 데이터로부터 복수의 발행 서버의 식별을 검색하는 단계;

    상기 복수의 발행 서버 중 하나를 선택하는 단계;

    상기 권리 데이터 및 보호된 상기 컨텐츠 키(CK)를 권리 라벨로서 서명을 위해, 선택된 상기 발행 서버에 제출하고, 상기 발행 서버가 상기 권리 라벨을 확인하고, 유효하다면 상기 권리 데이터에 적어도 부분적으로 기초하여 디지털 서명을 생성함으로써 서명된 권리 라벨(SRL)을 생성하며, 상기 SRL을 리턴하는 단계;

    리턴된 상기 SRL을 수신하고 그러한 수신된 SRL과 암호화된 컨텐츠 키(CK(content))를 연관시켜 컨텐츠 패키지를 형성하는 단계; 및

    상기 컨텐츠 패키지를 상기 하나 이상의 사용자들에게 배포하고, 그럼으로써 상기 컨텐츠를 렌더링하기 원하는 사용자는 상기 컨텐츠 패키지로부터 상기 SRL을 검색하고 검색된 상기 SRL을 상기 컨텐츠에 대응하는 라이센스에 대한 요청의 일부로서 상기 라이센스 서버에 제출하며, 그럼으로써 상기 라이센스 서버는 상기 라이센스 서버에 대한 공개키(PU-RM)에 기초하여 또한 보호된 상기 권리 데이터에 적어도 부분적으로 기초하여 상기 SRL의 서명을 검증하고, 상기 SRL의 권리 데이터에 액세스하여 이를 검토함으로써 상기 사용자가 상기 라이센스에 권한이 부여되었는지 여부를 결정하며, 권한이 부여된 경우에는 상기 사용자에게 상기 라이센스를 발행하는 단계- 상기 라이센스는 상기 사용자에게 액세스 가능한 보호된 형태의 컨텐츠 키(CK)를 포함함 -

    를 포함하는 디지털 컨텐츠 발행 방법.
11. 라이센스 서버가 컨텐츠를 렌더링하기 원하는 하나 이상의 사용자들에게 상기 컨텐츠에 대응하는 디지털 라이센스를 발행할 수 있도록 디지털 컨텐츠가 발행되어야 할 권리 템플릿을 생성하는 방법으로서,

    상기 권리 템플릿 내에, 사전 정의된 사용자 세트, 복수의 컨텐츠 조각과 연관되는 각각의 정의된 사용자에 대한 사전 정의된 권리 데이터 및 상기 권리 데이터를 변형하기 위한 규칙들을 정의하는 단계 - 상기 권리 템플릿은 복수의 컨텐츠 조각에 대한 권리들을 정의하는데 있어서 반복적으로 사용되도록 적용됨 -;

    상기 규칙들에 기초하여 변형되지 않는 상기 권리 데이터의 부분들을 식별하고 식별된 상기 부분들 중 적어도 일부를 마킹 속성 세트를 갖는 태그로 마킹하는 단계; 및

    상기 권리 템플릿의 마킹된 상기 부분들에 기초하여 상기 권리 템플릿을 서명하여 디지털 서명을 생성하는 단계 - 상기 디지털 서명을 생성하는 단계에 의해, 상기 컨텐츠를 발행하는 발행자는 상기 규칙들에 따라 상기 템플릿의 권리 데이터를 변형할 수 있으나 상기 템플릿의 마킹된 부분들을 변형하지는 않아 디지털 서명이 검증되는 것을 방해하지 않음 -

    를 포함하는 권리 템플릿 생성 방법.
12. 삭제
13. 삭제

Images