KR20030085121A

KR20030085121A - 표준 렌더링엔진을 사용하는 디지털권 관리를 위한 시스템및 방법

Info

Publication number: KR20030085121A
Application number: KR10-2003-7009531A
Authority: KR
Inventors: 랄리마이클; 첸다니엘; 유흐시-쳉; 타탄
Original assignee: 콘텐트가드 홀딩즈 인코포레이티드
Priority date: 2001-01-17
Filing date: 2002-01-16
Publication date: 2003-11-03
Also published as: CN101783807A; CA2431428A1; EP1366403A4; CA2431428C; CN103780631A; AU2002241871B2; KR100609263B1; WO2002057865A2; JP2004518205A; WO2002057865A3; CN101783807B; JP4512119B2; CN1714356A; KR20050116907A; CN103780631B; JP4512153B2; CN102244674B; EP1366403A2; CN1714356B; MXPA03006267A

Abstract

개시된 내용은 표준 렌더링엔진을 사용하는 전자문서의 보안배포 및 소비를 위한 시스템 및 방법에 관한 것이다. 상기 문서에는 사용권이 통합될 수 있다. 서버는 적어도 하나의 문서를 컴퓨터에서 판독가능한 형식으로 저장하고 있다. 클라이언트는 부호화된 문서를 표현할 수 있는 렌더링엔진을 포함하는 표준 응용프로그램을 구비하고, 문서는 사용자의 조작에 의해 표현된다. 클라이언트와 서버는 통신 네트워크에 의해 연결되어 있다. 보안모듈은 요청된 적어도 하나의 서버상의 문서를 클라이언트로부터 제어하고, 문서 및 그 문서에 통합된 권리를 클라이언트에게 배달한다.

Description

표준 렌더링엔진을 사용하는 디지털권 관리를 위한 시스템 및 방법{SYSTEM AND METHOD FOR DIGITAL RIGHTS MANAGEMENT USING A STANDARD RENDERING ENGINE}

인터넷은 TCP/IP(transmission control protocol/internet protocol)로 알려진 표준 프로토콜을 운영하는 다양한 하드웨어 통신 연결수단에 의해 함께 연결된 컴퓨터들의 전세계 네트워크이다. 지난 수년이상 인터넷의 성장은 폭발적이고, 폭넓게 사용되는 ("브라우저들"로 알려진) 소프트웨어 툴(tool)들에 의해 대부분 보급되어 왔으며, 그것은 HTML(hypertext markup language) 표시 및 HTTP(hypertext transfer protocol) 항해를 허락한다. 브라우저들은 단순한 GUI(graphical user interface)가 인터넷상에서 교신하는 데 사용되도록 허락한다. 일반적으로 브라우저들은 인터넷, 즉 클라이언트 컴퓨터상의 콘텐트에 접촉하는 데 사용되는 컴퓨터상에 존재한다. HTTP는 TCP/IP의 최상층 성분이고, 유저들이 다양한 포맷들의 문서들에 대한 접근을 제공하는데, 이때 다양한 포맷들로는 HTML 및 더 최근에는 XML(extensible markup language) 및 XHTML(extensible hypertext markup language), XML로의 HTML의 재공식화로 알려진 표준 페이지 표시 언어들이다. HTML/HTTP를 사용하는 인터넷상의 서버들의 모음은 "World Wide Web" 또는 단순히 "Web"으로 알려져 왔다.

HTML, XHTML 및 쌍방향 프로그램밍 프로토콜들을 통해, 콘텐트의 저작자는 인터넷 웹서버상에 웹페이지의 형태로 콘텐트를 배치함으로써 콘텐트를 다른 사람들이 이용할 수 있게 만들 수 있다. 서버에서 네트워크 경로는 URL(Uniform Resource Locator)에 의해 인식되고, 일반적으로 웹브라우저를 운영하는 클라이언트는 URL를 사용함으로써 웹서버에 접근할 수 있다. 브라우저를 운영하는 클라이언트 컴퓨터는 인터넷을 통해 웹에 알려진 방식으로 URL요청을 발함으로써 웹서버에 저장된 웹페이지의 표현을 요청할 수 있다.

웹이 표준 프로토콜들 및 표준 렌더링엔진, 즉 브라우저의 렌더링엔진을 사용하기 때문에, 웹은 도처에 편재하여(ubiquitous) 왔다. 웹의 첫 번째 응용중의 하나는 콘텐트를 문서형태로 배포해 온 것이었다. 여기에서 사용되는 용어로서의 "문서"는 배포 혹은 전송되어야 하는 정보의 단위이고, 이것은 통신에 제한되지 않고, 책들, 잡지들, 정기 간행물들, 신문들, 다른 서류들, 소프트웨어, 사진들 및 다른 이미지들, 오디오 및 비디오 클립들(clips), 그리고 다른 멀티미디어 프레젠테이션들(presentations)을 포함한다. 문서는 종이에 인쇄된 형태로서, 저장매체상의 디지털 데이터로서 혹은 다양한 매체상에 다른 알려진 어떤 방법으로도 실시되어도좋다.

그러나, 디지털 문서들, 즉 컴퓨터에 의해 전자수단 및 특히 인터넷을 통하여 읽을 수 있는 형태의 서류들의 폭넓은 배포를 방해하는 가장 중요한 문제들 중의 하나는 이러한 디지털 문서들의 배포와 사용하는 동안 콘텐트 소유자들의 지적재산권 보호가 현재 부족하다는 것이다. 이러한 문제를 해결하기 위한 노력들은 "지적재산권 관리(IPRM)", "디지털재산권 관리(DPRM)", "지적재산 관리(IPM)", "권리 관리(RM)", 및 "전자 저작권 관리(ECM)"로 불리워지며, 여기서는 총체적으로 디지털권 관리(DRM)"로 언급하기로 한다.

인쇄문서들의 세계에서는, 저작자에 의해 창작된 작품은 일반적으로 발행인(출판업자)에게 제공되고, 그는 그 작품을 조판하여 다량의 사본들을 인쇄한다. 그리고 나서, 이 사본들이 배포자에 의해 서점들이나 혹은 다른 소매판로들로 보내지고, 그곳에서 마지막 사용자에 의해 구입되게 된다. 프린트물의 낮은 복사 품질과 높은 배포 비용은 대부분의 인쇄된 서류들의 불법적인 복사에서의 억제요인으로 작용하지만, 비보호 디지털 문서들을 복사, 변경 그리고 재배포하는 것은 너무 쉬워서 그렇게 하지 않을 수 없을 정도이다. 따라서 권한이 없이는 그들의 복사 및 배포를 더 어렵게 만드는 디지털 문서들을 보호 방법이 필요하다.

불행히도, 사람들이 전자적 문서들을 불법적으로 배포하는 것을 방지하거나 혹은 제지하는 것이, 근거리통신망(LANs), 인트라넷 및 인터넷과 같은 컴퓨터 네트워크상에 연결된 퍼스널 컴퓨터, 워크스테이션, 그리고 기타 수단과 같은 현재 일반 목적의 컴퓨팅 및 통신시스템 내에서는 어렵다는 것은 폭넓게 인식되어져 있다.불법적인 복사를 방지하려는 하드웨드적 해결책을 제공하려는 많은 시도들은 성공적이지 못했다. "광대역" 통신 기술(NII)의 확산은, 전장 동영상(full length motion pictures)와 같은 비디오 파일들을 포함하여, 대규모 문서들을 전자적으로 배포하는 것을 더욱 편리하게 해줄 것이고, 그래서 문서들의 불법적인 배포에 대한 나머지 방해물들까지도 제거할 것이다. 따라서, DRM 기술은 매우 유용하게 되도 있다.

두 가지의 기본적인 방안이 문서보호문제를 해결하기 위해 채용되어 왔다: 안전한 콘테이너와 신뢰받는 시스템이 바로 그것이다. "안전한 콘테이너"( 혹은 단지 부호화된 문서)는 권한조건 설정이 부합되고 저작권 기간(즉, 사용지불)이 유지될 때까지 문서콘텐츠가 부호화된 상태를 유지하는 방법을 제공한다. 다양한 조건과 기간이 문서제공자에게 검증된 후, 문서는 사용자에게 사용가능한 형태로 해제된다. IBM^TM및 InterTrust's^TMDigiboxes에 의한 암호화와 같은 상업적인 제품들이 이 범주에 속한다. 명확히는, 안전한 콘테이너를 통한 접근은 비보안된 경로를 통한 전달 과정에서 문서를 보호하는 해결책을 제공하지만, 불법적인 사용자가 해제된 문서들을 얻고, 그래서 그것이 콘텐트 소유자의 지적재산권에 위배하여 사용되고 재배포되는 것을 방지하는 메카니즘을 제공하지는 못한다.

암호화 메카니즘은 전형적으로 문서들을 부호화 (또는 암호화)하기 위해 사용되고, 그래서 공중으로 배포되어 저장되고, 궁극적으로는 권한이 부여된 사용자들에 의해 개인적으로 해독, 즉 복호화된다. 이것은 불안전한 매체에 문서를 저장하는동안뿐만 아니라 공중망 상에서 문서배포자로부터 권한이 부여된 사용자에게로 문서를 배달하는 동안에 기본적인 형태의 보호를 제공한다.

"신뢰받은 시스템" 접근에 있어서, 전체 시스템은 문서의 비인증된 사용 및 배포를 방지하는 데 책임이 있다. 신뢰받은 시스템의 구축은 일반적으로 안전한 프로세서, 안전한 저장장치 및 안전한 렌더링(rendering) 수단과 같은 새로운 하드웨어를 도입하는 것을 수반한다. 이것은 또한 신뢰받은 시스템상에 운용되는 모든 응용 소프트웨어가 신뢰받도록 인증될 것을 요구한다. 변경방지(tamper-proof)된 신뢰받는 시스템을 구축하는 것은 여전히 기존 기술에 대해서는 실제적인 도전이지만, 현 시장경향이 제시하는 것은 개방형 및 비신뢰된 시스템들 예컨대 웹에 접근하기 위해 브라우저를 사용하는 PC와 워크스테이션과 같은 시스템은 저작권으로 보호되는 문서들에 접근하는 데 사용되는 주력 시스템이 되는 것이다. 이런 의미에서, 대중적인 운용시스템들(즉, 윈도우^TM, 리눅스^TM, 유닉스)을 구비한 PC와 워크스테이션과 같은 현존하는 컴퓨팅 환경은 신뢰받은 시스템이 아니고, 그들의 구조를 의미 있게 변경하지 않는 한 신뢰받을 수 없다. 물론, 구조의 변경은 웹의 첫 번째 목적, 즉 유연성과 편리성을 해친다.

미국 특허 제5,715,403호는 여기에 참조로 게재되어 공개된 바와 같이, 디지털 문서들의 배포를 통제하는 시스템을 개시하고 있다. 각 렌더링 수단은 그 자신과 연관되어 있는 저장장치를 가진다. 사용권 레이블(label)은 디지털 콘텐트와 연관된다. 이 레이블은 콘텐트의 사용방식 및 그 사용방식을 실행하기 위한 정지조건들을 상세히 설명하는 사용권을 포함한다. 미국 특허 제5,052,040은 디지털 파일에 접두어형태로 부가된(prefixed) 레이블의 사용을 개시하는데, 그에 따르면 다른 사용자들은 같은 파일에 관한 특정의 부호화 능력 및 권리를 가질 수 있다.

두개의 기본적인 접근들은 웹상에서 문서를 배포하는 것을 제어하기 위해 이루어져 왔다. 그 첫 번째 접근은 사용자가 구독료를 지불한 다음에만 콘텐트에 대한 접근이 허여되는 구독이용기반형 서비스(the use of subscription based services)이다. 그러나, 구독료가 지불되고 서류가 브라우저에 의해 표현된 경우에, 사용자는 문서를 복사, 인쇄 및 변경할 수 있다. 즉, 발행인에 의한 문서의 모든 통제가 상실된다.

그 두 번째 접근은 독점의 포맷을 사용하는 것으로, 그 문서는 발행인의 권리를 보장하도록 강제된 렌더링엔진을 선택함에 의해 표현될 수 있을 뿐이다. 물론, 이러한 접근은 하나의 독점적 포맷의 사용을 요구하고, 복수의 대중적인 포맷들과 그 안에 통합된 풍부한 내용을 결합시키는 능력을 상실한다. 나아가, 이러한 접근은 사용자가 사용자의 컴퓨터상에 얻어지고 설치되지 않으면 안 되는 독점의 렌더링 응용프로그램을 사용하도록 요구하고, 안전한 방식으로 표현되기 위하여 각 포맷을 위한 렌더링 응용프로그램의 개발을 요구한다. 나아가, 문서들은 비표준적인 도구들을 사용하여 작성되거나 혹은 변환되지 않으면 안 된다.

나아가, 웹브라우저와 같은 표준적인 렌더링 엔진에 기능을 추가할 수 있는 다양한 알려진 메카니즘들이 있다. 예를 들어, 액티브엑스 콘트롤(ActiveX control)은 웹브라우저에 의해 자동으로 다운로드 되어 실행될 수 있다. 액티브엑스는 어떻게 애플리케이션이 정보를 공유해야 하는가의 규칙설정이고, 액티브엑스 콘트롤은 C, C++, 비쥬얼 베이직 및 자바를 포함한 다양한 프로그램 언어들로 개발될 수 있다.

액티브엑스 콘트롤은 자바애플릿과 유사하다. 그러나, 자바애플릿과는 달라서, 액티브엑스 콘트롤은 원도우^TM운영시스템에 완전한 액세스가 가능하다. 마이크로소프트^TM는 등록시스템을 개발해 왔고, 그래서 브라우저들은 다운로드하기 전에 액티브엑스 콘트롤을 인식하고 인증할 수 있다. 자바애플릿은 모든 플랫폼(platform)에서 운용할 수 있는 반면에, 액티브엑스 콘트롤은 현재로는 원도우 환경으로 제한되어 있다.

브이비스크립트(VBScript)라 불리는 스크립트 언어는 웹저작자들이 HTML 문서에 액티브엑스 콘트롤 및 다른 기능들을 다운로드하고 설치하도록 초기화하기 위하여 쌍방향적 요소를 집어넣을 수 있게 한다. 현재, 마이크로소프트의 웹브라우저인 인터넷 익스프롤러^TM는 자바, 자바스크립트 및 액티브엑스를 지원한다. 반면에, 넷스케이프의 네비게이터^TM브라우저는 단지 자바와 자바스크립트만을 지원하고, 그것의 플러그인(plug-in)들을 통해서 브이비스크립트 및 액티브엑스의 지원을 가능하게 한다. 그러나, 브라우저들을 위한 다양한 플러그인(plug-in) 및 애드온(add-on) 소프트웨어가 가용하다는 점은 사용자 경험을 더욱 복잡하게 만들고 웹이나 다른 개방된 네트워크상에서 신뢰성 있는 DRM 시스템을 구현함에 있어서 다양한 문제점을 야기한다.

VYOU.COM은 웹상에서 배포되는 문서들에서 지적재산권을 보호하기 위한 시스템을 개발해왔다. 이 시스템은 사용자의 웹브라우저에 소프트웨어 플러그인을 포함한다. 이 플러그인은 전용 포맷을 위한 전용의 렌더링 엔진을 포함하고, 그것에 의해 문서들이 표현되고 전송된다. 따라서, 문서들은 전용의 포맷으로 재포맷되지 않으면 안 되고, 적합한 최종 표현포맷을 위한 플러그인 렌더링엔진이 표준 브라우저 렌더링엔진을 대신하여 사용된다. 이러한 장치는 각 포맷마다의 렌더링 엔진의 개발을 요구한다. 그러므로, 이 시스템은 이행하기 어렵고 개방된 구조로서의 웹의 장점들을 상실한다.

웹의 확산 및 문서배포에서의 그것의 유용성은, 렌더링엔진들이 재작성될 필요없이, DRM 특징을 웹브라우저 및 다른 표준 렌더링엔진들에 적용하는 것을 바람직하게 한다. 그러나, 통상적인 DRM 기술들은 웹브라우저들 및 다른 표준 렌더링 엔진들에서 사용하도록 적용되기 쉽지 않은데, 왜냐하면 그들이 웹의 개방된 구조와는 상반되는 전용 포맷 및 렌더링엔진을 요구하기 때문이다. 웹브라우저들과 같은 응용프로그램들을 그들의 렌더링엔진들로부터 독립적으로 제어하는 것이 불가하다는 점은 DRM 특징들을 배포네트워크상에 적용하기 어렵게 만든다.

웹상에서 DRM 시스템을 실행하는 데 있어 다른 방해물(roadblock)때문에 사실상 전용 문서, 특히 전용 문서내의 제한된 권리를 위해 지불되는 요금은 상대적으로 적다. 예를 들어, 많은 경우에 있어, 전용 문서내의 제한된 권리를 위한 요금은 1달러보다 적을지도 모른다. 그런 경우에, 신용카드 수수료와 합해서 액세스 요금,거래 요금 등등을 포함한 비용은 완전한 문서비용에 비교해서 상대적으로 크다. 종종 "마이크로-트랜잭션(micro-transaction)"으로 언급되는 그런 상대적으로 작은 거래를 위해서, 대응하는 "마이크로페이먼트(micropayment)", 즉 상대적으로 작은 비용을 위한 신용카드의 사용은 실용적이지 못하다. 나아가, 각 신용카드거래는 개인적인 수수료로서 처리되고, 다양한 거래에 있어 큰 용량의 문서를 구입하는 고객은 수많은 작은 거래들을 발생시킬 것이고, 그것은 신용카드거래를 위해 효율적이지 못하다.

다양한 독점의 해결책들이 마이크로페이먼트 및 다른 지불을 인터넷상에서 취급하기 위하여 개발되어 왔다. 예를 들어, 사이버캐쉬 주식회사(CyberCash^TM, Inc.) 및 이페이먼트시스템 주식회사(ePayment Systems^TM, Inc.)은 각각 그런 해결책들을 제공한다. 또한, 인텔리센트(Intellicent^TM)는 마이크로페이먼트를 위한 독특한 해결책을 제공한다. 그러나, 이러한 해결책들은 DRM 환경에서는 통합되지 못한다.

본 발명은 디지털 콘텐트의 배포에 관한 것으로, 보다 상세하게는 인터넷 웹브라우저와 같은 표준 응용프로그램의 렌더링엔진에 의해 표현되는 보호된 문서들의 배포를 촉진시키기 위한 방법 및 장치에 관한 것이다.

본 발명은 바람직한 실시예 및 첨부된 도면을 참조하여 설명된다.

도 1은 DRM 기술을 사용하는 문서 배포 시스템의 블록도이고,

도 2는 본 발명의 바람직한 실시예에 따른 DRM 시스템의 개략도이고,

도 3은 서버가 보호된 클라이언트에 응답하도록 하는 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 4는 보호된 클라이언트에 접근하기 위한 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 5는 보안모듈을 설치하기 위한 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 6은 보안모듈을 비활성화하기 위한 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 7은 멀티풀 서버들에 클라이언트의 인증을 촉진하기 위한 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 8은 서비스가 클라이언트의 사용자 인터페이스의 제어를 허락하기 위한 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 9는 사용자 인터페이스 구성요소에 참조부호(reference)를 갖는 콘텐트의 블록도이고,

도 10은 클라이언트 특정의 워터마크(watermark)를 적용하기 위한 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 11은 거래정보를 수집하기 위한 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 12는 주소혼란을 위한 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 13은 HTTP 문서 전송용 비대칭 프로토콜을 사용하는 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 14는 소프트웨어의 동적 인증을 위한 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 15는 동적 가변형 부호화를 위한 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 16은 보안정보를 문서내에 삽입하기 위한 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 17은 사용권을 요청하는 URL에 근거하여 결정하기 위한 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 18은 필요한 렌더링 응용프로그램을 다운로드하기 위한 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이고,

도 19는 타임스탬핑 유효토큰(time stamping validation tokens)을 위한 본 발명의 바람직한 실시예에 따른 동작방법의 흐름도이다.

본 발명의 목적은 인터넷과 같은 네크워크상에서 문서의 배포를 촉진하기 위한 것이다. 본 발명의 일 면에 따르면, 그 자신(즉, 디지털문서)과 연관된 사용권을 가지는 디지털 문서를 배포하기 위한 시스템이다. 이 시스템은, 그 자신에 저장되는 적어도 하나의 디지털 문서를 갖는 서버, 콘텐트를 표현하기 위해 접근할 수 있는 렌더링 엔진을 포함하는 표준 응용프로그램을 가진 컴퓨터, 클라이언트와 서버에 연결되는 통신네트워크 및, 표준 응용프로그램에 상기 렌더링 엔진에 접근하기 위한 보안조건을 실행시키기 위해 부가되는 보안모듈을 포함한다.

본 발명은 바람직한 실시예를 참조하여 아래에서 설명한다. 본 발명은 다양하게 변형 실시할 수 있고, 그래서 바람직한 실시예로부터 아주 다르게 나타날 수 있다. 결과적으로, 여기에 개시된 특정한 구조적 기능적 세부사항은 단지 대표예에 불과하고 본 발명의 보호범위를 제한하는 것은 아니다.

도 1은 디지털 문서의 전자적 배포를 위한 시스템의 일 예를 나타낸 블록도이다. 저작자(110)는 원콘텐트(112)를 장착하여, 그것을 배포를 위해 배포자(120)에게 보낸다. 보편적으로, 저작자(110)는 콘텐트의 장착자이다. 그러나 여기에 사용된 "저작자"란 용어는 장착자, 소유자, 편집자 혹은 콘텐트를 제어하는 다른 존재 또는 그러한 존재들 중에 하나인 대리인(예를 들어, 출판인)일 수 있다. 또한, 저작자(110)는 문서를 배포자(120)와 같은 다른 관계자의 관련없이 직접 배포할 지도 모르고, 그래서 저작자 및 배포자는 동일한 사람일 수 있다. 그러나, 도 1에 개시된 기능의 분할이 더 효과적이고, 그래서 그것은 저작자(110)가 배포의 관리기능이 아니라 콘텐트 창조에 집중하도록 한다. 더욱이, 그러한 분할은 배포자(120)가 많은 저작자들(120)과 협력하도록 허용함으로써 경제규모를 촉진시킨다. 여기에서 사용된 용어 "문서"는 일반적으로 텍스트, 오디오, 혹은 다른 데이터와 같은 형태의 콘텐트에 관련되고, 이 콘텐트는 부호화, 포맷팅(formatting) 등을 포함한다. 여기에 사용된 용어 "콘텐트"는 일반적으로 문서의 기초가 되는 정보에 관한것이다. 그러나, 이러한 용어들은 의미가 중복되어서, 여기에서는 교체가능하게 사용된다.

배포자(120)는 요청시 문서를 사용자(130)에게 배포한다. 전형적인 전자 배포 모델(model)에 있어서, 콘텐트는 부호화된 형태의 문서로 배포된다. 배포자(120)는 콘텐트를 랜덤키(random key)로 부호화하고 나서, 랜덤키를 사용자(130)에게 해당하는 공용키(public key)로 부호화한다. 그 결과, 이 부호화된 서류는 오로지 특정한 사용자(130)에게만 적합하게 된다. 그래서, 사용자(130)는 랜덤키를 복호화하는 그들의 개인키(private key)를 사용할 수 있으며, 그것을 복호화 하는 데 사용하여 문서를 볼 수 있다.

문서를 위한 지불은 사용자(130) 및 특정한 문서를 보기 원하는 다른 사용자들로부터 요청들이 모아지는 정보센터(150)를 통하여 사용자(130)로부터 배포자(120)에게 건네진다. 정보센터(150)는 또한 직불거래, 신용카드거래, 혹은 다른 알려진 전자지불계획과 같은 지불정보를 모으고, 이 수집된 지불정보들을 하나의 묶음으로 하여 배포자(120)에게 전달한다. 물론, 정보센터(150)는 지불의 일부분을 상기 적시된 서비스를 위한 요금으로서 보유할 수 있다. 배포자(120)는 정보센터(150)로부터 지불묶음의 일부분을 배포서비스를 위해 보유하고, 지불(예를 들어 사용료)을 저작자(110)에게 전달할 수 있다. 배포자(120)는 문서 배포전에 하나의 문서를 위한 한 다발의 사용자 요청들을 기다릴 수 있다. 그런 경우, 하나의 부호화된 문서는 모든 요청 사용자들(130)에게 복호화되게 제작될 수 있다.

사용자(130)가 문서를 요청(또는 사용)할 때마다, 결산메세지(accountingmessage)가 회계서버(140)로 전송되고, 그것은 사용자(130)에 의한 각 요청이 배포자(120)에 의해 보내진 문서와 부합되는 지를 보증한다. 결산정보는 회계서버(140)에 의해 직접 배포자(120)로부터 보내진다. 어떤 불일치가 발생하면 정보센터(150)로 보고서가 전송되고, 그럼 그에 따라서 배포자(120)에게 형성된 지불묶음을 조정하게 된다. 이러한 결산 체계(accounting scheme)는 전자문서 배포에 있어서의 사기의 가능성을 줄이고, 시간에 의존한 사용허가를 취급하게 하며, 그것은 결과적으로 사용 기간 혹은 범위에 종속하여 변하는 요금이 생기게 된다. 회계서버(140) 및 정보센서(150)는 결합하여 거래 수집기(160)로 작용할 수 있으며, 그 기간을 초과한 복수의 거래들을 수집하고, 배포자(120)의 결산 오버헤드(overhead)를 줄이기 위하여 적합한 방법으로 배포자(120)에게 위탁하도록 기능한다. 도 1에 도시된 전자문서 배포의 모델은 여기에 개시된 본 발명의 바람직한 실시예의 전자문서 배포시스템에 적용될 수 있다. 나아가, 콘텐트는 상술한 바와 같이 사용권을 포함한다.

도 2는 본 발명의 바람직한 실시예에 따른 문서배포 시스템의 컴퓨터 구조의 개략도이다. 위에 적시한 바와 같이, 본 발명은 정보센터(clearinghouse)와 회계서버의 사용과 같은 효과적인 회계 및 요금지불을 위한 알려진 모델들에 관련하여 사용될 수 있다. 나아가, 본 발명은 다양한 상업 모델들과 관련하여 사용될 수 있다. 따라서, 배포를 회계감사하고, 지불의 효율성을 기하고, 문서를 창작하기 위한 장치에 대해서는 여기에서 상세하게 설명하지 않고, 설명을 단순화하기 위해 본 발명의 바람직한 실시예의 논의에서 생략하기로 한다.

도 2에 도시된 바와 같이, 디지털 콘텐트 배포 시스템(200)은 상술한 배포자(120)에 대응되는 배포서버(220) 및, 상술한 사용자(130)에 대응되는 클라이언트 컴퓨터(230)를 포함한다. 서버(220)와 클라이언트 컴퓨터(230)는 요구되는 기능들을 수행하도록 프로그램된 일반 목적의 컴퓨터들일 수 있다. 예를 들어, 서버(220)는 원도우NT 운용체제로 운용되고 아파치 혹은 다른 HTTP 서버와 같은 HTTP 서버 소프트웨어(226)를 포함하는 표준 서버 혹은 워크스테이션일 수 있다. 클라이언트(230)는 원도우 운용체제로 운용되는 개인용 컴퓨터일 수 있다. 바람직한 실시예에서는, 서버(220) 및 클라이언트(230)는 각각 인터넷, 더 상세하게는 웹과 같은 통신 네트워크(300)로 연결되어 있다. 따라서, 클라이언트(230)는 렌더링 엔진을 갖는 표준 응용프로그램으로서 브라우저(232)를 포함한다. 브라우저(232)는 마이크로소프트 인터넷 익스플로러 혹은 네스케이프 네비게이터와 같은 HTTP 종속(compliant) 브라우저일 수 있다. 여기에 사용된 상기 구 "표준 응용프로그램"은 문서 창작, 가시화 및 편집과 같은 업무를 수행하기 위해 설계된 응용프로그램에 관련되고, 렌더링 엔진을 가지고 있다. 표준 응용프로그램의 예로는 워드 프로세서, 웹브라우저, 편집기, 뷰어(viewer), 스프레드시트 프로그램(spreadsheet program), 데이터베이스 프로그램 등을 포함한다.

서버(220)는 그 안에 저장된 복수의 문서들(222)을 배포를 위해 웹페이지 형태로 구비한다. 문서(222)는 부호화된 포맷으로 저장될 수 있다. 여기에서 사용되는 용어 "부호화된"은 콘텐트의 접근가능성이 부분적으로나 완전하게 금지되는, 비대칭 또는 대칭 부호화 알고리즘, 스크램블링(scrambling) 알고리즘 등의 사용과같은 메카니즘에 의한 것에 관련된다. 서버(220)는 또한 디지털권 관리모듈(224)을 문서(22)의 특정한 것들과 통합된 사용권, 사용자들 및/또는 지불총액 혹은 다른 조건들을 저장하고 관리하기 위해 소프트웨어 형태로 포함한다. 디지털권 관리모듈(224)의 다른 기능은 아래에서 더욱 상세하게 설명하기로 한다. 배포 서버(220)는 서버설비 혹은 다른 그룹의 컴퓨터들의 일부분일 수 있고, 그것은 또한 도 2에 도시된 바와 같이 배포서버(220´)를 포함할 수 있다.

클라이언트(230)는 또한 사용자 인터페이스(UI) 모듈(234)과 연결모듈(236)을 각각 소프트웨어 형태로 그리고 브라우저(232)의 변경 없이 브라우저(232)에 적합하게 부착되는 형태로 구비한다. 예를 들어, UI 모듈(234) 및 연결모듈(236)은 플러그-인, 액티브엑스 콘트롤 형태로, 혹은 브라우저(232)의 코드 변경없이 브라우저의 렌더링 엔진에의 부착을 허락하는 다른 형태로 존재할 수 있다. 그런 부착은 아래에서 보다 상세하게 설명한다. 결합에 있어서, UI모듈(234)과 연결모듈(236)은 보안모듈을 구성하고, 그에 대해서는 아래에서 상세하게 설명하기로 한다. 보안모듈(237)은 클라이언트 컴퓨터(230)내에 상주하는 것으로 도시되었지만, 보안모듈(237)은 클라이언트측 요소와 서버측 요소를 포함할 수 있다는 것이 분명하다 할 것이다. 예를 들어, 후술될 DRM 모듈(224)은 보안모듈(237)의 서버측 요소일 수 있다.

디지털권 관리모듈(224)은 사용권의 레이블(label)을 저장하고 각 문서(222)에 통합된 권리가 어떤 것인지를 확인할 수 있는 서버측 요소이다. 이 권리는 또한 문서(222)에 대한 사용자의 접근요청, 정보센터 등을 통해 사용자에 의해 이루어진지불 및 기타 다른 조건의 확인에 근거하여 변경할 수 있다. 예를 들어, 사용자는 잘 알려진 바와 같이, 문서(222)를 보기 위한 하나의 요금 또는 동일한 문서(222)를 보고 인쇄하기 위한 더 많은 요금을 선택할 수 있다. 디지털권 관리모듈(224)은 또한 문서에 따른 적합한 권리목록을 통신 네트워크(330)를 통해서 후술되는 바와 같이 클라이언트(230)의 연결모듈(236)에 전달하도록 동작한다.

연결모듈(236)은 클라이언트측 요소일 수 있고, 그것은 UI모듈(234)이 브라우저(232)에 부착된 것을 검증함으로써 클라이언트(230)의 통합 환경을 검증하고, 클라이언트(230)의 사용자, 즉 콘텐트를 요청한 사람을 확인하고, 디지털권 관리모듈(224)에 의해 보내진 문서와 적합한 권리목록을 검색하고, 적합한 환경에서, 암호화된 검색문서들을 복호화 하고 필요한 서명 및/또는 키(key)를 발생시킨다. UI모듈(234)는 클라이언트측 요소로, 모니터가 사용자로부터 문서(222)의 콘텐트를 접속하도록 요청하고, 연결모듈(236)에 의해 검색된 권리목록에 근거하여 상기 요청을 허여하거나 거부한다. 나아가, UI모듈(234)은 브라우저(232)의 특정된 기능 및 후술될 방식으로 권리목록에 근거하여 클라이언트(230)의 운영체제를 비활성화할 수 있다. 이것은 운영체제 API와 인터페이싱하고 예를 들어 명령들을 가로막고 방향을 바꿈으로써 달성된다. 클라이언트(230)의 환경에서 실행되는 산업표준 렌더링 엔진은 변경되거나 또는 다른 방법으로, 사용자가 UI모듈(234)을 바이패스(bypass)하는 방식으로 보호 콘텐트에 접근하도록 허락하는 방식으로 타협하지는 않는다는 것을 연결모듈(236)이 검증한다.

본 발명은 웹과 같은 알려진 클라이언트/서버 네트워킹 구조과 관련하여 변경,회피 혹은 표준 클라이언트 소프트웨어, 서버 소프트웨어 및 렌더링 엔진을 바이패스하지 않고서 필요한 권한을 부여할 수 있다. 디지털권 관리모듈(224)은 존재하는 서버 소프트웨어(226)을 함께 서버(220)내에 설치된다. 위에 기술한 바와 같이, 디지털권 관리모듈(224)은 권리가 서버(220)에 존재하는 문서(222)와 통합되거나 나중에 서버에 저장되는 가를 확인한다. 예를 들어, 디지털권 관리모듈(224)은 프로그램할 수 있는 데이터베이스, 룩업 테이블(lookup table)을 가지며, 잘 알려진 방식으로 사용자의 식별사항(identity) 및 사용자에 의한 지불과 같은 각 문서(222)와 통합된 다양한 권리와 다른 변경 등을 포함한다. 디지털권 관리모듈(224)은 나아가 서버(22)의 운영체제 API와 서버 소프트웨어(226)가 단지 연결모듈(236) 및 UI모듈(234)과 같은 보안모듈(237)의 적당한 구성요소들을 가진 클라이언트들(230)로부터 응답을 일으키도록 인터페이싱한다. 또한, 디지털권 관리모듈(224)은 후술되는 데이터베이스(225)와 인터페이스하게 동작한다.

예를 들어, 디지털권 관리모듈(234)이 설치되면, 도 3에 도시된 처리가 수행된다. 새로운 DRM 시작 웹페이지, 혹은 다른 보안 인터페이스 디스플레이는 UI모듈(234)과 존재하는 서버 시작 웹페이지를 참조하여 만들어진다.(단계302) 서버(220)상의 웹사이트의 다양한 웹페이지들은 랜덤 레이블을 갖는 디렉토리나 다른 알려진 디렉토리에 위치될 수 있다.(단계304) 디지털권 관리모듈(224)은 이러한 디렉토리에 포인터(pointer)를 포함하도록 프로그램되고(단계306), 디지털권 관리모듈(224)은 이런 디렉토리의 URL을 부호화한다.(단계308) 시작 DRM 웹페이지는 수정되어 UI모듈(234)를 참조하고, UI모듈(234)은 연결모듈(236)에 명령을 하여부호화된 URL를 복호화 하여 원래 시작페이지 및 나머지 웹사이트에 대한 접근을 허락할 수 있다. (단계310) 클라이언트(230)가 UI모듈(234) 및 연결모듈(236)를 가지지 않는다면, 상기 URL은 복호화될 수 없고 그 결과 서버(220)상의 웹사이트에 접근할 수 없다.

대안으로, 연결모듈(236)은 서명을 생성하고 서버(220)에서의 URL 요청에 의해 그 서명을 서버(220)로 전송한다. 서버(220)상의 웹사이트로의 접근은 상기 서명이 존재하고 유효한 경우에 한하여 허락될 것이다. 이러한 대안에 있어서, 디지털권 관리모듈(224)은 상기 서명을 유효하게 하는 코드를 포함할 수 있다.

클라이언트 컴퓨터(230)의 사용자가 디지털권 관리모듈(224)을 가지는 서버(220)에 접근하려고 시도하면, 디지털권 관리모듈(224)은 상술한 바와 같이 클라이언트(230)상에 설치된 보안모듈(237) 및 UI모듈(234)의 구성요소들이 모두 요구되었는 지를 검증한다. 만약, 그렇지 않다면, 자바애플릿, 액티브엑스 콘트롤 등의 형식으로 된 DRM 시작 웹페이지내의 명령은 브라우저(234)가 아래에서 보다 상세하게 설명하는 방식으로 UI모듈(234)을 다운로드하여 설치하도록 지시한다. 다운로드는 통신 네트워크(300)에 연결된 서버(220) 또는 다른 서버로부터 수행될 수 있다. 그런 다운로드 및 설치는 통상적인 메카니즘을 사용하는 알려진 방식으로 이루어질 수 있으며, 사용자는 즉각적으로 설치를 허가하고 설치파일을 저장하는 장소와 같은 다른 필요한 정보를 입력할 수 있다. 연결모듈(236)은 UI모듈(234)내에 삽입되고, 동시에 혹은 분리된 다운로드과정 및 설치과정을 통하여 다운로드되고 설치될 수 있다. 물론, UI모듈(234)이 서버(220)상에 설치된 것으로 감지된다면, 상기 설치단계는 생략될 수 있다. 만약 UI모듈(234)이 클라이언트(230)상에 설치되지 않고, 사용자가 그런 설치를 허가하지 않는다면, 서버상의 문서에 대한 접근은 금지되거나 혹은 단지 자유롭게 배포가능하게 특정된 문서들로 제한된다.

상술한 바와 같이, UI모듈(234) 및 연결모듈(236)은 브라우저(232)의 코드변경 없이 그들이 브라우저(232)에 부착될 수 있는 형태로 된다. 모듈(module)에 관련하여 여기에서 사용되는 용어 "부착"은 브라우저(232)의 코드 변경 없이 브라우저에 연결되거나 결합될 수 있는 소프트웨어 모듈에 관한 것이다. 예를 들면, UI모듈(234) 및 연결모듈(236)은 네스케이프 네비게이터의 경우에 있어서의 플러그인 또는, 인터넷 익스폴로러의 경우에 있어서의 액티브엑스 콘트롤의 형식으로 된다. 그런 구성요소들을 개발하고 설치하는 메카니즘은 잘 알려져 있다.

서버(220)에 저장된 보호된 콘텐트를 접근하기 위한 과정이 문서(222)의 형식으로 도 4에 도시되어 있다. DRM 시작 웹페이지는 알려진 방식으로 그것의 URL을 통하여 접근된다.(단계402) DRM 시작 웹페이지는 UI모듈(234)을 원시작페이지 혹은 DRM 시작 웹페이지에 의해 참조된 페이지들에게 상술한 방법 중에 하나를 사용하여 전달한다.(단계404) UI모듈(234)은 브라우저(232)의 렌더링엔진의 다른 인스턴스(instance)를 생성하고, 원시작 웹페이지를 로드(load)하고, 운영체제가 브라우저창에 새로운 인스턴스를 표현하도록 알려진 기술을 사용하여 지시한다.(단계406) 새로운 인스턴스는 UI모듈(234)에 의해 연결모듈(236)을 통하여 서버(220)로부터 콘텐트를 검색하도록 명령한다.(단계408) 다시 말하면, 바람직한 실시예에서, UI모듈(234)은 브라우저(232)로부터 명령을 가로채서 그들을 연결모듈(236)을 통하여 재지시하게 된다. UI모듈(234)은 새로운 인스턴스가 안전한 비대칭 프로토콜을 사용하도록 연결모듈(236)을 통하여 아래에서 상세히 설명하는 바와 같이 지시한다. 그러므로, UI보호는 유효하고 모든 사용자 인터페이스 이벤트(event)들은 가로채서 제어될 수 있다.(단계410) 예를 들어, 사용자가 브라우저(232)의 표준 사용자 인터페이스를 통하여 "인쇄" 또는 "복사" 명령을 초기화했을 때, UI모듈(234)은 요청을 가로채고, 연결모듈(236)에서 받은 권리설정이 요청된 기능을 수행하도록 허락하고 있다면 대응을 허가한다.

더 상세하게는, 연결모듈(236)이 브라우저(232)의 렌더링엔진으로부터 요청을 받았을 때, 연결모듈(236)은 렌더링엔진이 UI모듈(234)에 의해 보호된다, 즉 UI모듈(236)이 첨부된다는 것과, 렌더링엔진은 변경되거나 그렇지 않을 경우 타협되거나 하지는 않는다는 점을 입증해준다. 그렇다면, 연결모듈(236)은 서버(220)의 디지털권 관리모듈(224)과 연결을 허락하고 서버(220)상의 원시작 웹페이지 및 웹페이지의 사용자를 위한 권리설정을 검색하는 데에 대한 허가를 협상한다. 그럼, 디지털권 관리모듈(224)은 서버(220)의 서버 소프트웨어(226)와 클라이언트(230)의 연결모듈(236) 사이의 연결을 초기화한다. 이 연결은 HTTP, HTTPS 또는 기타 다른 표준 혹은 독점의 연결 프로토콜과 같은 프로토콜을 사용하여 확립될 수 있다.

그런 다음 요청된 문서(222)는 검색되고 서버(220)상에서 부호화된 경우에는 문서(222)를 복호화하는 연결모듈(236)에 전달되며, 문서는 브라우저(232)의 렌더링엔진의 새로운 인스턴스에 복호화된 형태로 문서에 통합된 권리설정과 함께 전달된다. 다시 한번, 권리설정의 내용은 문서, 사용자의 신원사항, 사용자가 한 지불 혹은 기타 다른 적당한 변수에 기초하여 결정되어진다. 그럼, 연결모듈(236)은 권리설정을 UI모듈(234)로 전달하고, UI모듈은 권리설정에 근거하여 사용자에게 이용할 수 기능을 제한하도록 상술한 바와 같이 브라우저(236)의 렌더링엔진의 새로운 인스턴스를 제어하게 된다.

문서의 콘텐트는 이제 다른 웹페이지와 마찬가지로 브라우저(232)의 창에서 보여질 수 있다. 그러나, 브라우저(232)는 문서의 웹페이지로의 접근을 허락하지 않는데, 그것은 브라우저(232)가 UI모듈(234)이나 후술할 안전모듈(237)의 다른 구성요소에 의해 "포장되어(wrapped)" 있기 때문이다. UI모듈(234)은 브라우저(232)가 문서의 권리설정 범위 밖의 금지된 기능들을 실행하는 것을 방지한다.

본 바람직한 실시예는 브라우저, 워드프로세서 또는 기타 다른 응용 또는 표현 프로그램과 같은 응용프로그램의 표준 렌더링엔진을 이용한다. 본 바람직한 실시예는 응용프로그램과 인터페이스하고 응용프로그램과 문서사이에 문서로의 접근을 통제하도록 유지함으로써 달성된다. 따라서, 각 문서 포맷을 위한 독립된 독점적 렌더링 엔진은 요구되지 않는다. 나아가, 응용프로그램에 의해 지원되는 데이터 포맷은 본 발명에 의해 변경 없이 달성된다. 본 바람직한 실시예는 DRM 시스템이 TCP/IP 및 HTML를 표현하는 브라우저들의 사용과 같은 표준에의 적용을 수용하는 것으로 보여진다. 나아가, 본 바람직한 실시예는 DRM이 사용자에게 투명한 방식으로 시스템에 응용되는 것을 수용하는 다양한 기능성을 향상시킨다. 문서 배포시스템(200)의 운영방법의 몇몇 예들이 아래에 설명되어 있다.

첫 번째 예에서, 클라이언트 컴퓨터(230)는 그 안에 설치된 보안모듈(237)의 모든 요구된 구성요소들을 구비하고 있지 않다. 도 5에 도시된 바와 같이, 클라이언트 컴퓨터(230)는 하나 또는 그 이상의 문서(222)를 위한 배포서버(220)의 요청을 생성한다.(단계502) 배포서버(220)는 이 요청을 분석하여 요청내에 결여된 서명정보에 근거하여 (보안모듈(237)의 요소가 클라이언트 컴퓨터(230)에 로드되지 않는 것을 명령한다면), 클라이언트 컴퓨터(230)에 보호모듈(237)의 필수 구성요소를 로드하도록 응답을 보낸다.(단계504) 상술한 바와 같이, 보안모듈(237)은 클라이언트 컴퓨터(230)내에서 사용권을 실행시키는 기능을 한다. 단계504에서 보내진 응답은 콘텐트를 요청하는 클라이언트의 형태에 특정된다. 만약, 클라이언트 컴퓨터(230)상의 클라이언트 소프트웨어가 웹브라우저라면, 예를 들어 배포서버(220)는 배타적인 소프트웨어 요소를 포함하는 웹페이지라는 응답을 보낼 것이다. 예를 들면, 상기 소프트웨어 요소는 자바 스크립트 혹은 액티브 서버 페이지(Active Server Pages)와 같은 표준 형식일 수 있다. 또한, 응답, 즉 바람직한 실시예에서 웹페이지는 단계502에서 보내진 콘텐트를 위한 서명되지 않은 요청의 사본을 포함할 수 있다.

클라이언트 컴퓨터(230)는 웹페이지를 수신하고, 보안모듈(237)의 구성요소를 얻기 위한 장소에 대한 정보를 포함하는 소프트웨어 구성요소를 실행하여 구성요소들의 복사를 요청한다.(단계506) 클라이언트 컴퓨터(230)는 보안모듈(237)의 구성요소들을 받아서 설치한다.(단계508) 보안모듈(237)은 자동으로 실행되어 브라우저(232)내에서 운영되도록 구성되는데, 이것은 상기 예에서 상술한 메카니즘을 사용하여 이루어진다. 그럼 보안모듈(237)은 웹페이지내에 포함된 콘텐트(222)의 원요청의 사본을 읽어들이고, 상기 웹페이지가 보안모듈(237)을 불러들여 배포서버(220)에 디지털보안서명과 함께 요청을 재발송하게 된다.(단계510) 배포서버(220)는 서명된 요청을 받고서 요청상의 서명을 확인한다.(단계512) 이 요청이 보안모듈(237)에 의해 적합하게 서명되면, 배포서버(220)는 문서(222)를 클라이언트 컴퓨터(230)에 설치된 보안모듈(237)에 전달하여 사용권 및 문서(222의 콘텐트와 통합된 조건에 따라 브라우저(232)에 의해 표현하도록 한다. 도 5에 도시된 방법은 자동 예약 보안모듈이 클라이언트에게 사용자가 보안방식으로 콘텐트(222)를 표현하는 데 필요한 소프트웨어를 끊어짐 없이 그리고 투명하게 제공하도록 한다. 보안모듈(237)은 소프트웨어 에이젼트(agent)를 포함할 수 있는데, 이 소프트웨어 에어젼트는 단계508에서 렌더링엔진 혹은 클라이언트 컴퓨터(230)의 다른 구성요소들을 분석하고, 클라이언트 환경이 안전한지를 확인하도록 동작한다. 보안모듈(237)은 단계510에서 그런 확인후에 요청을 재전송할 수 있다.

도 6은 본 발명의 바람직한 실시예의 동작방법의 다른 예를 도시하고 있다. 보안모듈(237)은 문서(222)를 배포서버(220)로부터 검색하도록 한다.(단계602) 이 예에서, 문서(222)는 "순수한 콘텐트(clear content)", 즉 부호화되지 않거나 한편으로는 모호하거나 제한되지 않으며 어떤 사용제한들을 갖지 않는다. 문서(222)는 서버(220)에 의해 보안모듈(237)로 되돌아온다.(단계604) 왜냐하면, 문서(222)는 서명되지 않거나 부호화되지 않거나, 그렇지 않는 경우 보안모듈(237)에 의해 취급될 필요가 있는 콘텐트로서 기록되어 있지 않기 때문에, 보안모듈(237)은 자신이더 이상 필요치 않다는 것을 인식한다. 보안모듈(237)은 브라우저(232)에게 통지하고, 브라우저(232)는 서버(220)에 콘텐트의 원요청을 보냄으로써 직접 문서(222)를 요청한다.(단계606) 그런 다음 보안모듈(237)은 실행중인 구성요소로서의 자신을 제거하고 즉, 비활성화 시키고 클라이언트 컴퓨터(230)의 자원을 보존한다.(단계608) 브라우저(232)는 그럼 보안모듈(237)에 의해 원래 전송되었던 문서(222)의 요청을 다시 재출한다.(단계610) 그러면, 배포서버(220)는 문서(222)를 브라우저(232)에 직접 전달한다.(단계612)

보안을 유지하고 사용권을 실행하기 위하여, 콘텐트를 위한 모든 요청은 보안모듈(237)을 통하여 초기화된다. 그러나, 요청이 보안을 요구하지 않는 콘텐트를 돌려 보낼 때에는, 보안모듈(237)은 그것이 컴퓨터 자원을 이용하기 때문에 잠재적인 부담이 된다. 본 예에서, 보안모듈(237)이 필요로 되지 않는다면, 그것은 운영상태로부터 제거된다.

시스템(200)은 PKI 부호화 기술 또는 기타 다른 부호화, 암호화(ciphering) 혹은 워터마킹(watermarking) 기술을 사용할 수 있다. 물론, 각 기술은 콘텐트를 위해 요청을 한 클라이언트가 사용자 권한이 있는 지를 확인하는 것을 요구한다. 디지털 인증 혹은 서명은 확인의 목적으로 사용될 수 있다. 다시 말하면, 확인 목적으로 사용되는 전자메세지의 첨부는 메시지와 함께 전송된다. 디지털 인증 혹은 서명의 대부분의 일반적 사용은 메시지를 보내는 사용자가 요청한 자인지를 검증하고 수신자에게 응답을 부호화하는 수단, 예를 들어 부호화 키를 제공하는 것이다. 부호화된 메시지를 전송하기 원하는 개인은 써티피케잇 오써리티(CertificateAuthority; CA)로부터의 디지털인증을 응용할 수 있을 것이다. 상기 CA는 신청자의 공용키와 다양한 다른 식별정보를 포함하는 부호화된 디지털 인증을 발한다. 상기 CA는 자신의 공용키를 예를 들어 인터넷을 통하여 쉽게 이용할 수 있게 만든다. 부호화된 메시지의 수령인은 메시지에 첨부되는 디지털 인증을 부호화하기 위한 CA의 공용키(public key)를 사용하고, CA에 의해 발행되어 전송자의 공용키와 인증내에 포함된 식별정보를 얻을 때 그것을 검증한다. 이런 정보로, 수령인은 부호화된 응답을 보낼 수 있다. 디지털 인증의 대부분 폭넓게 사용되는 표준은 X.509이다.

이러한 식별과정은 각 서버에서 요청된 콘텐트를 되풀이 할 때 부담이 된다. 도 7은 복수의 서버에서 식별과정이 신속히 처리되는 바람직한 실시예의 동작방법의 다른 예를 도시하고 있다.

도 7에 도시된 바와 같이, 클라이언트 컴퓨터(230)는 문서(222)를 배포서버(220)로부터 요청한다.(단계702) PKI 부호화 기술이 사용된다고 가정하면, 요청은 "PrivateClient[request]"의 형태로 될 수 있고, 상기 요청은 그 내부에서 클라이언트 컴퓨터(230)의 개인키(private key)와 함께 부호화된다. 배포서버(220)는 요청 서명을 보고, 요청이 권한이 있는 클라이언트로부터 온 것이 아닌지를 확인하고, 단일의 "첼린지 토큰(challenge token)을 발생시켜 클라이언트 컴퓨터(230)에 귀환하게 한다.(단계704) 바람직한 실시예에서, 첼린지 토큰은 "PrivateServer[PrivateClient[request]]"의 형태로 될 수 있고, 상기 PS내에서 원 부호화된 요청은 배포서버(220)의 개인 키를 사용하여 다시 부호화된다.

클라이언트 컴퓨터(230)는 유일한 방법으로 첼린지를 변환, 즉 첼린지 토큰에 서명함으로써 시도에 응답한다.(단계706) 예를 들어, 변환은 배포서버(220)의 공용키와 함께 첼린지 토큰의 부호화 형태로 될 수 있다. 그런 경우에, 상기 변환은 "[PublicClient[PrivateServer[PrivateClient [request]]]"의 형태일 것이다. 클라이언트 컴퓨터(230)는 그럼 배포서버(220)에 변환된 첼린지 토큰과 함께 요청을 다시 제출한다.(단계708) 배포서버(220)는 변환을 인식, 즉 첼린지 토큰이 그 자신의 것인지를 인식하고서 클라이언트에게 증명을 발행하고, 요청된 문서(222)를 반환한다.(단계710)

많은 경우에 있어서, 배포서버(220)는 전술한 바와 같이 서버설비 또는 다른 관련된 컴퓨터들의 일부분이다. 그러므로, 이러한 세션(session)을 위한 다음 요청을 받는 서버가 사실상 "첼린지" 토큰을 생성한 서버와 같을 것이란 보증은 없다. 예를 들어, 다음 세션 요청은 배포서버(220´)에 의해 수신될지 모른다. 클라이언트 컴퓨터(230)는 동일한 첼린지 토큰을 재사용하여 다른 요청을 보내고, 그 요청은 배포서버(220´)에 의해 수신될 때(단계712), 배포서버(220´)는 첼린지 토큰의 서명을 찾고, 그 서명이 배포서버(220)에 속하는 것인지를 확인한다.(단계714) 배포서버(220)는 배포서버(220´)와 신뢰관계를 가지기 때문에, 배포서버(220´)는 배포서버(220)의 첼린지 토큰을 신뢰할 것이다. 특히, 배포서버(220´)는 클라이언트에 의해 수행된 첼린지 토큰의 변환을 평가하고 서버(220)를 첼린지 토큰의 발행자로서 인식함으로써 클라이언트에게 권한을 부여한다. 콘텐트(222´)는 배포서버(220´)로부터 클라이언트 컴퓨터(230)에 전달된다.(단계716)

이러한 운영방법에서, 다른 관련 서버들에 의해 지원되는 토큰은 요청을 받는 서버에 의해 존중된다. 상기 처리과정을 단순화하기 위하여, 키들은 다시 변환되지 않는다. 관련된 서버에서 앞의 키변환의 승인은 관련된 서버 그룹의 다른 서버가 권한부여과정의 속도를 높이기 위하여 사용된다.

전술한 바와 같이, 표준 렌더링 엔진의 사용은 DRM 시스템에 관해서는 상당한 정도의 복잡성을 보인다. 예를 들어, 브라우저를 렌더링엔진으로 사용할 때, 표준 사용자 인터페이스는 사본, 인쇄 명령들 및 DRM 시스템과 호환되는 필요하지 않는 다른 명령들을 포함한다. 그러한 명령들을 디스에이블시키는 것이 알려져 있는데, 그 경우 대부분 GUI들은 예컨대 윈도우 GUI는 디스에이블된 명령들에 대응되는 메뉴 선택들을 음영처리 할 것이다. 그러나, 이것은 종종 당황스럽고 그리고 금욕적으로 즐거운 것은 아니다. 나아가, 사용권의 선택 및 그것의 실행을 위한 조건들과 같은, 지불되는 요금과 같은 콘텐트 특정의 메뉴 선택들을 제공하는 것이 바람직하다. 나아가, 콘텐트 판매자는 독점 상표의 사용자 인터페이스 또는 다른 판매자와 일치하는 사용자 인터페이스를 표현하기를 원할 지도 모른다. 또한, 어떤 환경하에서는 프린트 버튼과 같은 메뉴선택들을 눈에 띄게 하는 것이 바람직할지도 모른다.

도 8은 콘텐트 특정 도구바들이 브라우저(232)의 사용자 인터페이스로서 표현되도록 허락하는 본 발명의 바람직한 실시예의 동작방법을 도시하고 있다. 문서(222)는 상술한 바와 같이 렌더링 응용프로그램과 호환되는 형태, 즉 본 바람직한 실시예에서는 웹페이지로 배포서버(220)상에 저장된다. 문서(222)는 도 9에서 상세하게 도시되어 있고, 소프트웨어 구성요소(220a)에 대한 참조부호(reference)A와 툴바 및 UI의 설명(220b)에 대한 참조부호B를 포함한다. 소프트웨어 요소(220a)는 자바애플릿, 액티브엑스 콘트롤 등의 형태일 수 있다. 콘텐트가 표현될 때, 소프트웨어 요소에 대한 참조부호는 브라우저, 즉 액티브엑스 콘트롤, 자바애플릿에 의해 인식된다.

도 8를 참조하면, 브라우저(232)는 문서(222)를 요청한다.(단계802) 브라우저(232)는 문서(222)를 표현하도록 시도하고, 그럼으로써 다음으로 참조부호A가 소프트웨어 요소(220a)를 실행하도록 한다.(단계804) 그럼 소프트웨어 요소(220a)는 그것을 불러냈던 문서(222)를 찾고, 툴바 및 UI의 설명(220b)에 대한 참조부호B를 확인한다.(단계806) 그리고나서, 소프트웨어 요소(220a)는 설명(220b)에 기초하여 플랫폼/브라우저 특정의 툴바 및 UI를 구축하려는 동작을 한다.(단계808) 소프트웨어 요소(220a)는 표준브라우저 UI 및 툴바를 제거하거나 감추고, 그들은 단계808에서 구축된 것들로 대체한다.(단계810) 이러한 조작방법은 웹사이트(본 경우에는 배포자의 서버(220))가 항해 동기, 보기, 외관을 지시하고, 그럼으로써 사용자의 브라우저에 부지, 최적화 버튼, 색상, 패턴, 애니메이션, 메뉴 및 툴바들을 만들도록 승인한다.

도 10은 클라이언트 특정 혹은 심지어는 사건 특정의 워터마크가 보안 및 목표추적을 위한 콘텐트에 적용할 수 있는 바람직한 실시예의 다른 동작방법을 도시하고 있다. 디지털 "워터마킹"의 개념은 일반적으로 잘 알려져 있고 콘텐트 소유자가 그래픽 및 오디오 파일들에 이러한 저작물에 대한 자신의 권리를 식별하는 데사용되는 정보를 삽입하도록 허락한다. 용어 "디지털 워터마크"는 양질의 레터헤드(letterhead) 및 어떤 화폐에 존재하는 전통적인 워터마크들로부터 시작되었다. 전통적인 워터마크들은 보편적으로 독자에게는 보이지 않지만, 빛에 조사되었을 때 종이의 제조자 혹은 레터헤드의 사용자의 이름 혹은 로고(logo)가 나타나게 한다. 유사하게는, 디지털 워터마크는 또한 질을 확인하고 권한을 보증하는 목적으로 기능한다. 디지털 워터마크를 담은 그래픽 혹은 오디오 파일은 콘텐트 소유자나 다른 정보에 관련하는 정보를 담을 수 있다. 디지털 워터마크는 콘텐트가 권한이 부여되지 않는 방식으로 인쇄되는 것과 같이 어떤 조건하에서 단지 눈으로 인지할 수 있을 뿐이다. 예를 들어, 그래픽 이미지에 있어 디지털 워터마크는 상을 변경하여 워터마크를 삽입하는 관계자에 의해 공급되는 디지털 정보를 제공한다. 워터마크는 스탠드-얼론(stand-alone)이나 플러그인 소프트웨어에 의해 보여질 수 있고, 예를 들어 저작권 소유자 또는 더 완전한 저작권 소유권 정보를 추적할 수 있는 독특한 식별코드를 나타낼 수 있다.

도 10에 도시된 바와 같이, 클라이언트 컴퓨터(230)는 문서를 배포서버(220)로부터 통신채널(300)을 통하여 요청한다.(단계1002) 배포서버(220)는 문서(222)를 보안모듈(237)에 배달한다.(단계1004) 문서(222)는 보안모듈(237)에 배달되었을 때 그 안에 장치된 워터마크를 가질 수도 그렇지 않을 수도 있다는 것에 주목하라. 보안모듈(237)은 문서(222)를 렌더링엔진, 본 바람직한 실시예에서는 브라우저(232)의 요청에 의해 상술한 방법으로 표현하기 위해 배달한다. 보안모듈(237)은 그런 다음 콘텐트(222)를 표현하는 데 사용되는 렌더링엔진의 인스턴스와 관련있는 인스턴스 특정 정보(instance-specific information)를 사용하여, 렌더링엔진의 인스턴스가 사용하는 원도우에 클라이언트 특정 워터마크(client-specific watermark)를 적용한다.(단계1008) 클라이언트 특정의 워터마크는 워터마킹을 위한 어떤 기법이나 알고리즘을 사용하여 적용될 수 있다. 클라이언트 특정의 워터마크는 또한 존재하는 워터마크에 더하여 적용될 수 있다. 이 클라이언트 특정의 워터마크 데이터는 저장되거나 어떤 방법으로 생성될 수 있다.

다른 경우에는, 워터마크가 클라이언트상에 적용되기 때문에, 그것은 그 클라이언트에 유일하고 그래서 추적될 수 있다. 배포서버(220)는 식별가능한 문서(222)를 모든 클라이언트들에게 배달할 수 있다.(그래서 서버측 실행충격을 최소화할 수 있다.) 그럼, 클라이언트는 예를 들어 이미지에 대한 반투명창을 사용하는 유일한 워터마크를 적용한다. 만약, 콘텐트의 소비자가 스크린 캡처(capture)나 콘텐트를 캡처하는 다른 권한 없는 메카니즘을 사용한다면, 캡처된 콘텐트는 목적을 탐지하고 실행하기 위해 사용자에게 유일한 ID로 워터마크된다.

도 11은 거래지불을 쉽게 수집하는 본 바람직한 실시예의 사용방법을 나타내고 있다. 클라이언트 컴퓨터(230)는 보안모듈(237)의 필수 구성요소들을 설치하기에 앞서, 문서(222)를 배포서버(220)로부터 요청한다.(단계1102) 배포서버(220)는 그럼 문서(222)가 보호되어 있고 클라이언트 컴퓨터(230)는 문서(222)를 표현할 보안모듈(237)이 필요하며, 보안모듈(237)을 어디에서 구할 수 있는 지를 클라이언트 컴퓨터(230)에게 알린다.(단계1104) 이 경우에, 보안모듈(237)은 거래수집기(160; 도1에 도시)와 통합된 컴퓨터로부터 구할 수 있다. 클라이언트 컴퓨터(230)는 거래 수집기(160)와 통합된 컴퓨터에 세션을 개방함으로써 보안모듈(237)의 필수 구성요소를 거래 수집기(160)로부터 요청한다.(단계1106) 거래 수집기(160)는 예를 들어 계산서 정보 등을 포함한 다양한 사용자 정보를 통상적인 방법으로 요청하고 수집한다.(단계1108)

거래 수집기(160)는 단일보안모듈(237)을 숨겨진 단일 공용개인쌍(public private pair) 혹은 클라이언트 컴퓨터(230)의 다른 식별표시를 가지고 발생시키고, 보안모듈(237)을 클라이언트 컴퓨터(230)로 복귀하게 한다.(단계1110) 보안모듈(237)은 브라우저(232) 또는 다른 제3의 렌더링 응용프로그램의 보호된 인스턴스를 생성하고, 그 주위의 접근보호를 실시하고, 보호된 콘텐트(222)를 배포서버(220)로부터 검색하고 표현하도록 지시한다.(단계1112) 배포서버(220)는 문서(222)가 보안모듈(237)과 함께 보호되어진 렌더링엔진에 의해 요청될 것이라는 것을 인식한다. 그러면, 문서(222)를 복귀시킨다.

보호된 렌더링 응용프로그램, 예를 들어 첨부된 보안모듈(237)을 가진 브라우저(232)는 보안모듈(237)에게 문서(222)를 표현하려고 한다는 것을 알린다. 보안모듈(237)은 디지털권이 문서(222)에 통합되어 있는 가를 분석하고, 거래 수집기(16)로 되돌아가 적당한 수수료를 기록한다.(단계1114) 거래 수집기(160)는 공용개인키(public private key)의 이러한 요구에 의해 접근된 많은 형식의 콘텐트에 대응하여 수행된 수많은 작은 거래들을 추적하고, 그래서 그들을 정기적으로 하나의 수수료로 합산하여 재정기구 또는 보안모듈(237)내에 표식(indicia)과 통합된다른 부분에 저장한다.

도 11의 방법은 사용자가 새로운 웹사이트에 로그온하여 거래를 시작하도록 승인한다. 사용자의 정보는 이미 신뢰성 있는 사이트(거래 수집자(160)와 같은)에 이미 파일로 존재한다면, 새로운 웹사이트는 신뢰성 있는 사이트를 통하여 사용자를 검증한다. 신뢰성 있는 사이트는 모든 거래들을 조정하고 그 결과를 정기적으로, 예를 들어 월마다 적합한 존재(entity)로 보낸다. 따라서, 거래(여러 차례의 작은 단위)를 취급하는 부담은 배포자 혹은 신용기관으로부터 수집자에게 이전되고, 그래서 거래의 총비용을 절감시킨다.

새로운 웹사이트는 사용자의 상세 정보를 획득해야하는 것은 아니고, 따라서 이런 점은 프라이버시 문제에 대한 관심을 줄이게 된다. 부가적으로, 그 새로운 웹사이트의 로그인 과정이 단순화 된다. 그 웹사이트는 신뢰된 사이트에 보내진 익명의 ID만을 사용하고 단지 그 신뢰된 사이트만이 사용자의 개인적이고 믿을만한 정보를 가지고 있기 때문에, 사용자 정보는 그 사용자가 거래하고 있는 그 새로운 웹사이트로부터는 보호된다.

본 발명의 바람직한 실시예의 다른 동작방법은 서버측 실행 구성요소의 필요 없이 보안을 위한 디렉토리 혼란(directory obfuscation)을 이용한다. 도 12에 도시한 바와 같이, 콘텐트 소유자 또는 문서(222)에 흥미를 갖는 다른 당사자는 배포서버(220)상에 서브디렉토리를 무작위 명칭이나 찾기에 어려운 다른 명칭으로 생성하여, 문서(222)의 보안위치로서 기능하게 한다.(단계1202) 관심있는 당사자는 보안모듈(237)과 문서(222)의 부호화된 형태의 새로운 보안위치에 참조부호를 갖는 웹페이지를 생성한다.(단계1204) 보호된 문서(222)는 그럼 웹페이지로 대체되고(단계1206), 보호된 문서(222)는 보안 디렉토리내로 이동된다.

클라이언트 컴퓨터(230)는 원래 드렉토리로부터 전술한 방식으로 문서(222)를 검색하라는 요청을 발한다.(단계1208) 그 내부에 부호화된 콘텐트의 비밀위치를 갖는 보안 웹페이지는 요구된 문서 대신에 돌아온다.(단계1210) 보안모듈(237)은 웹페이지에 의해 참조되는 콘텐트의 위치를 복호화하고, 그 보안위치로부터 문서(222)를 요청한다.(1212) 콘텐트는 보호된 렌더링엔진의 인스턴스를 생성하는 보안모듈(237), 예를 들어 본 바람직한 실시예에서는 브라우저(232)에 의해 배달되고, 문서(222)를 표시하게 된다.(단계1214)

상술한 조작방법은 서버측 실행을 요구하지 않고, 그래서 최대한의 보안이 필요하지 않은 한, 적당한 보안을 제공하는 저렴한 방식이다. 본 예에서, 콘텐트는 난수(혹은 의사난수)에 의해 결정된 주소를 가진 위치에 보안을 위해 저장된다. 그리고나서, 사용자가 거래를 시작할 때, 사용자는 부호화된 형태의 위치를 가진 HTML 페이지를 제공받는다. 이 보안구성요소는 위치를 복호화하고 클라이언트가 결코 그 위치를 알지 못하게 한다.

도 13은 보안에 관계된 주소를 이용하는 본 바람직한 실시예의 다른 동작방법을 표시한다. 클라이언트 컴퓨터(230)의 웹브라우저(232)는 배포서버(220)로부터 콘텐트를 요청한다.(단계1302) 배포서버(220)는 콘텐트 요청이 적절한 보안모듈(237)로부터 들어오지 않는 지를 확인하고(예를 들어 적절한 서명의 결핍에 의해), 그래서 클라이언트 컴퓨터(230)가 보안모듈(237)의 필수 구성요소들을 로드하도록 지시한다.(단계1304) 보안모듈(237)은 자식(child) HTML 렌더링엔진, 즉 브라우저(232)의 인스턴스를 기존 브라우저(232)의 인스턴스 안에 분화하고, 그래서 그 자식 HTML 렌더링엔진의 완전한 제어를 할 수 있다.(단계1306) 보안모듈(237)은 그럼 일반적인 HTTP 프로토콜과 주소를 통하는 대신에 보안모듈(237)에 설치된 비대칭 프로토콜을 통하여 콘텐트를 검색하라는 어린 인스턴스를 지시한다.(단계1308) 예를 들면, 비대칭 프로토콜은 그 안에 삽입된 액티브엑스 콘트롤을 가진 HTML이고 안전한 보안 통신 채널을 설치할 수 있다. 비대칭 프로토콜은 브라우저(232)가 다른 웹사이트를 통하여 콘텐트를 검색하도록 하고, 원하지 않거나 권한이 없는 사용자들로부터 접근을 방지하는 필터링 기술을 포함한다. 문서(222)는 표시된다.(단계1310).

예를 들어, 비대칭 프로토콜은 사용자의 주소를 사용자가 요청한 사용자인지 그리고 권한이 있는 지를 검증하기 위해 제 3자에게 전송할 수 있다. 비대칭 프로토콜은 브라우저(232)의 어린 인스턴스가 최고수준의 HTML 페이지를 지정된 보안 웹사이트를 통하여 요청할 수 있게 한다. 상위레벨 페이지가 로드된 후, 자식 인스턴스(child instance)는 상기 페이지의 모든 구성요소 부분들을 검색하는 데 주소 접미사(address prfix)를 사용할 수 있다. 비보호된 콘텐트는 표준 HTTP를 통하여 검색될 수 있다.

일반적으로, 보안은 HTML에서 표시를 위하여 다루어진다. 그러나, 본 실시예에서, 콘텐트는 독점의 비대칭 프로토콜을 사용하여 검색된다. 그러므로, HTML 렌더링 엔진의 단일 인스턴스는 콘텐트의 복합조각들을"당겨내는(pull)" 데 사용될 수 있다. 예로서, 표준 HTML 렌더링은 그 안에 액티브엑스 콘트롤을 포함하는 시작 웹페이지를 접근하는 데 사용될 수 있다. 이 제어는 어린 렌더링 엔진을 생성하고, 그것은 특정된 서버를 통하여 콘텐트를 검색하고, 그 결과 서버측에 접근하고, 필터링하는 기술 등을 포함하고 있다. 웹페이지(복합문서)는 다른 파일들과 이미지들에 참조부호를 가지는 것을 주목하라. 통상적으로, 단지 고수준 (HTML 페이지)는 보호되고, 그 참조부호는 보호되지 않는다. 그러나, 본 예에서는, 요청이 보안된 서버를 통해서 이루어지기 때문에, 고수준 및 그 참조부호들도 모두가 보안된다.

도 14는 본 발명의 바람직한 실시예에 따른 다른 조작방법을 표시하고 있다. 이 방법은, 코드가 의심받음직한 보안이 아닌 것으로 인증되지 않는 한, 플러그인과 다이나믹 링크 라이브러리(Dynamic Link Libraries; DLLs)와 같은 코드가 렌더링엔진내로 로드되는 것을 금지함으로써 보안을 제공한다. 이러한 방법은 인증이 사용자가 인증시 즉각적으로 인증되는 소프트웨어를 사용하는 것을 허락해야 하는 동적인 과정일 수 있다는 것을 나타낸다.

클라이언트 컴퓨터(230)의 보안모듈(237)은 렌더링 응용프로그램, 본 바람직한 실시예에서는 브라우저(232)의 인스턴스를 로드한다.(단계1402) 브라우저(232)는 제3자 추가를 프로그램 예컨대 DLL에 로드하도록 요청한다.(단계1404) 보안모듈(237)은 프로그램에 신뢰되어 인증된 제3자 추가 리스트를 포함하는 로컬 데이터베이스(225)에서 요청 및 질문을 가로챈다.(단계1406) 만약, 보안모듈(237)이 로드를 시도하고 있는 제3자 프로그램을 찾지 못한다면, 보안모듈(237)은 신뢰성 있는 서버가 인증된 신뢰성 있는 제3자 프로그램의 데이터베이스를 업데이트 하도록 접촉한다.(단계1408) 만약, 제3자 프로그램이 업데이트된 리스트에서 발견되지 않으면, 보안모듈(237)은 렌더링엔진내로의 제3자 프로그램의 로드를 허락한다.(단계1410) 만약 단계1406에서의 결정이 프로그램이 데이터베이스(224)내에 리스트됨으로써 인증된다면, 본 방법은 직접 단계1410으로 넘어간다. 만약 단계1408에서의 결정이 프로그램이 업데이트된 데이터베이스내에 인증된 것으로 존재하지 않으면, 로드는 금지된다.(단계1412)

렌더링 응용프로그램이 어떤 실행코드를 로드하기 원한다면 언제든지, 그것은 위태로운 보안을 피하기 위하여 승인, 즉 인증되어야 한다. 보안 구성요소의 적재시에 제3자 제품이 인증을 위한 준비가 없다면, 보안모듈내의 승인된 리스트내에 포함될 수 없을 것이다. 프로그램이 후에 승인된다면, 그 프로그램의 승인은 업데이트된 인증 데이터베이스, 예를 들어 데이터베이스(225)를 갖는 서버내로 로그인함으로써 업데이트된 리스트와 비교할 것이다.

도 15는 비디오 혹은 다른 큰 파일들의 형태의 콘텐트의 전송에 매우 적합한 본 바람직한 실시예의 조작방법을 표시하고 있다. 오버헤드(overhead)와 데이터 전송속도를 감소시키기 위하여 데이터부분을 부호화하는 것은 알려져 있는 반면, 아직까지 보안레벨을 제공하는 것은 알려져 있지 않다. 그러나, 도 15에 도시된 방법에서는, 데이터 스트림의 부호화율은 네트워크 잠복(latency), 연결속도 및 기타 요인들에 근거하여 적합하게 설정된다. 문서(222)는 클라이언트 컴퓨터(230)에 의해 요청된다. 배포서버(220)는 데이터베이스, 사용권, 또는 문서(222)와 통합된 기타 부호화 지시사항을 검사함으로써 사용할 부호화율이 얼마인지를 결정한다.(단계1504) 그런 정보는 디지털권 관리모듈(2)내에 저장된다. 예를 들면, 부호화 지시사항은 부호화가 특정된 퍼센트보다 더 크거나 혹은 특정된 퍼센트 범위내에 있을 지를 특정할 수 있다.

배포서버(200)는 데이터전송에 관련된 다양한 조건, 즉 문서(222)의 파일크기, 네트워크 잠복, 통신속도 등과 같은 것을 알려진 방식으로 모니터한다.(단계1506) 배포서버(220)는 단계1506에서 모니터된 조건들과 단계1504에서 결정된 부호화양에 근거하여 문서(222) 부분을 부호화한다.(단계1508) 단계1506 및 1508은 모든 문서(222)가 전송될 때까지 연속적이거나 간헐적으로 수행된다. 보안모듈(237)은 콘텐트를 부호화하고 그것을 렌더링 응용프로그램, 즉 본 바람직한 실시예에서는 브라우저(232)에 전달한다.

데이터 스트림의 가변적인 부분(퍼센트)은 부호화될 수 있다. 콘텐트는 시간간격이나 바이트크기에 근거하여 나누어질 수 있다. 예를 들어, 부호화된 10바이트, 비부호화된 90바이트처럼. 부호화 퍼센트는 적합하게 설정될 수 있다. 즉, 데이터 파일크기 및 다른 조건들에 따라서, 매번 부호화 퍼센트는 처리속도를 높이기 위하여 특정되는 값들 사이에서 변경할 수 있다.

서명 및 다른 보안정보를 HTTP 문서의 바디(body)내에 삽입하는 것은 알려져 있다. 그러나, 그런 실시는 보안 테그(tag)를 요구하고, 보안정보는 문서를 분석하지 않으면 안되기 때문에 운영하는 데 어려움이 있다. 그러나, 도 16에 도시된 본바람직한 실시예의 동작방법은 이러한 조작을 HTML 문서의 머리부분(header)를 보안정보를 운반하는 데 사용함으로써 단순화시킨다.

보안모듈(237)에 의해 발진된 브라우저(232)는 문서(222)를 배포서버(222)로부터 요청하고, 보안모듈(237)은 배포서버(220)에 표준 HTTP 또는 HTTPS 연결을 개시한다.(단계1602) 표준 HTTP 서버로서 기능하는 배포서버(22)는 다운로드하기 위한 문서(222)를 검색하거나 설정(build)한다. 특히, 디지털권 관리모듈(224) 혹은 배포서버(220)의 다른 보안모듈 구성요소는 요청하는 클라이언트를 HTTP 요청의 헤더내에 삽입된 보안정보를 분석하여 승인하고, 표준 HTTP 응답을 설정한다.

배포서버(220)는 보안정보를 HTTP 응답의 헤더내로 삽입한다.(단계1606) 예를 들면, 보안정보, 즉 서명은 HTML 문서내의 <Header> 테그의 속성일 수 있고, 아래와 같이 설정될 수 있다.

<Header> signature=13490680486724869 MY BOOK <Header/>

상기 예에 있어서, HTML 페이지의 타이틀은 "MY BOOK"이고, 그것은 표준 HTML 규칙에 따라 표시될 것이다. 서명은 헤더의 속성인 숫자이고, 표시되지 않을 것이나 보안목적을 위해 발췌될 수 있다. 응답은 클라이언트 컴퓨터(230)의 보안모듈(237)로 보내진다.(단계1608) 보안모듈(237)은 응답헤더내의 보안정보를 분석하고 문서(222)의 콘텐트를 보안정보에 기재되거나 그와 통합된 사용권에 따라 표현하기 위하여 브라우저(232)에 보낸다.(단계1610)

모든 보안정보는 헤더에 포함되기 때문에, 결과를 이끌어내는 DRM 시스템은 덜 방해되고 더 쉽게 운영된다. 또한, 새로운 보안테그 스키마(schema) 또는 다른 상세사항이 필요하지는 않다. 보안 구성요소는 단지 보안정보를 얻기 위하여 헤더내에서 찾는 기술이 필요할 뿐이다.

종종 콘텐트와 사용권은 동적이다. 예를 들어, 콘텐트는 시간마다 변화하고 사용권은 시간마다 변화하면서 콘텐트를 위한 요청이 어디에서 오는지에 의존될 수 있다. 예를 들어, 회사는 문서가 온사이트(on-site) 혹은 한편으로 보안 컴퓨터로부터 요청된다면, 고용인이 문서를 인쇄하거나 저장하게 되기를 원한다. 그러나, 동일한 고용인이 동일한 문서를 집으로부터 요청한다면, 단지 그 문서를 보도록 허용될지 모른다. 도 17은 주소와 이러한 발행을 전하는 URL 필터링을 제공하는 본 바람직한 실시예의 사용방법을 표시하고 있다.

보안모듈(237)을 갖는 클라이언트 컴퓨터(230)는 보안 문서(222)를 요청한다.(단계1702) 배포서버(220)는 콘텐트(222)의 정적 또는 동적 자원으로부터 정보를 수집하고, 알려진 방법으로 답변을 설정한다. 답변이 설정되어진 후에는, 보안모듈(237)의 서버측 구성요소는 데이터베이스(225)에 접근하고, URL의 일반적 표현을 사용권에 매핑(map)한다.(단계1706) 보안모듈(237)의 서버측 구성요소는 요청의 URL에 근거한 응답과 통합된 권리를 데이터베이스(225)내의 URL에 상응하는 권리를 선택함으로써 삽입한다.(단계1708) 그럼, 상기 응답은 클라이언트 컴퓨터(23)로 보안모듈(237)의 클라이언트측 구성요소의 통제하에서 삽입된 사용권에 따라서 요청된 콘텐트(222)를 표현하기 위해서 보내진다.

URL 주소와 디렉토리 주소가 사용되기 때문에, 동적인 콘텐트와 들어오는 요청 URL에 의해 인식되는 콘텐트는 적절하게 다루어질 수 있다. 디렉토리들은 고수준의 비밀성을 제공하기 위해서 필터링되고, 배포서버(220)상에 파일로서 저장되는 콘텐트는 URL이 서버에 저장된 파일에 접근하든지 그렇지 않든지 간에 권한이 없는 사용자에게 전달될 수는 없다. 두 형태의 필터들을 사용함에 의하여, 콘텐트 소유자는 어떤 콘텐트가 보호되어야 하고 어느 정도로 보호되어야 하는지를 결정하는 데 있어 유연성을 가진다. 나아가, HTML 문서의 헤드내에 보안 콘텐트를 배치하는 것은 동적인 콘텐트가 쉽게 다루어지는 것을 허용한다. 왜냐하면, 콘텐트의 바디는 보안을 위해 변경될 필요가 없고, 그래서 동적인 콘텐트가 신속하게 문서를 설정하도록 하는 것을 허용하기 때문이다.

콘텐트를 표현하는 데 종종 부딪히는 다른 문제는, 특히 인터넷상이나 다른 네트워크상에서 콘텐트를 배포할 때, 사용자가 항상 적합한 렌더링 응용프로그램을 가지지 않을 수 있다는 것이다. 예를 들어, PDF 파일을 다운로드할 때, 콘텐트 제공자는 종종 사용자에게 Adobe Acrobat Reader가 요구된다는 것을 경고하고, 심지어는 해당 소프트웨어를 다운로드하기 위한 링크(link)를 제공하기도 한다. 만약 사용자가 소프트웨어를 다운로드하지 않는다면, 그들은 콘텐트를 표현할 수 없다. 그러나, 소프트웨어를 다운로드하는 것은 뷰어(viewer) 부분에 관한 의미있는 행동, 즉 링크를 클릭하고, 다운로드용 디렉토리를 선택하고, 설치 소프트웨어를 실행하는 등을 요구한다. 많은 경우에 있어서, 사용자는 적합한 렌더링 응용프로그램을 설치하는 성가신 과정을 피하기 위하여 콘텐트를 다운로드하는 것을 피할 것이다. DRM 시스템에 있어서, 다기능 렌더링 응용프로그램의 수요는 보안요소가 새로이 설치된 렌더링 응용프로그램이 첨가되어 있지 않다면 보안 문제를 제기한다.

도 18은 적합한 렌더링 응용프로그램을 사용자에게 투명한 방법으로 제공하는 사용방법을 나타내고 있다. 클라이언트 컴퓨터(230)는 브라우저(232)에 의해 표현될 수 없는 파일 포맷으로 구성된 문서(222)를 요청한다.(단계1802) 문서(222)는 동일한 포맷의 파일로 포장되나 HTML 파일로 가장된다.(단계1804) 예를 들어, 원도우 운영 시스템은 파일 확장자에 의해 파일 형태를 식별한다. 그런 경우에, 파일, 예를 들어 PDF 파일은 "HTM" 확장자로 이름이 부여되어 클라이언트 컴퓨터(230)에 의해 HTML 파일로서 인식될 것이다.

파일은 클라이언트 컴퓨터(230)에서 다운로드되고 사용자 클라이언트 컴퓨터(230)가 HTML 파일로 인식하는 파일을 연다.(단계1806) 따라서, 브라우저(232)는 기정 HTML 뷰어로서 발진된다. 브라우저(232)는 HTML를 표현하기 시작하고 삽입된 응용프로그램, 즉 액티브액스 콘트롤 또는 자바애플릿과 같은 것에 대한 참조부호를 찾아낸다. 응용프로그램이 삽입된 브라우저(232)는 참조된 응용프로그램이 클라이언트 컴퓨터(230)에 설치되지 않았는지를 점검하여 찾아내도록 한다.(단계1810) 브라우저는 계속해서 파일에 있는 참조부호가 응용프로그램을 다운로드하도록 하고(단계1812), 그 결과 응용프로그램은 클라이언트 컴퓨터(230)에 설치되어, 상술한 바와 같이 보안모듈(237)에 첨가된다. 렌더링 응용프로그램으로 사용되는 어플리케이션은 보안모듈(237)에 의해 콘텐트를 HTML 파일내에서 검색하고 콘텐트를 표현하도록 유도된다.(단계1814)

새로운 파일형 확장자를 배포하는 결점은 만약 사용자가 당신의 데이터 파일들 중의 하나를 받는다면, 그 요청을 취급할 수 있는 등록된 응용프로그램이 존재하지않고, 그래서 사용자는 그 콘텐트를 가지고 작업을 계속할 수 없거나 새로운 응용프로그램을 수동으로 설치하지 않으면 안된다는 것이다. 그러나, 새로운 파일형식이 HTML 파일내에 포장된다면, 웹브라우저는 HTML 파일을 로드하고 자동으로 코드(자바스크립트, 등)를 찾는다. 만약, 그 코드가 클라이언트 플랫폼상에 등록된 응용프로그램을 찾는다면, 그 포함된 데이터를 해당 클라이언트 응용프로그램에 넘긴다. 만약, 그 데이터형식을 취급하는 응용프로그램을 찾지 못한다면, 그것은 브라우저를 불러서 사이트를 항해하면서 적합한 렌더링 응용프로그램을 다운로드하게 한다.

인터넷과 같은 네트워크상에서 콘텐트를 배포할 때의 다른 보안 문제는 해커(hacker)들이 메시지를 가로채고 보호된 콘텐트로의 접근을 하기 위해서 부호화 경로를 깨뜨리는 가능성에 있다. 그러나, 회피성 부호화는 종종 상대적으로 많은 시간(예를 들어 수초)를 요구하는데, 그것은 복잡한 소프트웨어 알고리즘을 실행하거나 난수를 발생시킬 필요성 때문이다. 도 19는 부호화 회피의 위험을 짧은 시간의 기간 후에 만료하는 토큰을 생성함으로써 감소시킨 본 발명의 바람직한 실시예의 동작방법을 표현하고 있다.

클라이언트 컴퓨터는 보안된 콘텐트(222)를 요청한다.(단계1902) 보안모듈(237)의 서버측 보안 구성요소가 권한 있는 클라이언트 컴퓨터(230)를 가지지 않는다고 가정하면, 배포서버(120)는 시간이 찍힌 첼린지 토큰을 발생시킨다.(단계1904) 클라이언트 컴퓨터(230)는 그 토큰을 수신하고 그것의 비유일한 공용키 개인키 쌍(public key private key pair)을 사용하여 요청을 추가하고 그것에 대해 알려진 방법으로 서명하고(단계1906), 서명된 토큰을 배포서버(220)에 돌려보낸다. 서명된 토큰을 수령하면, 배포서버(220)는 클라이언트 컴퓨터(230)의 서명을 검증하고 타임스탬프을 검사하여 토큰이 발생되었던 때 점검하여 확인한다.(단계1908) 토큰이 서명양식을 받기 전에 소정의 타임스탬프, 예를 들어 0.5초보다 더 발생된다면, 그 토큰은 더 이상 유효하지 않고, 비록 그 서명이 옳다고 하여도 콘텐트(222)로의 접근이 부인될 것이다.(단계1910)

그 타임스탬프는 서명의 유효기간이 얼마인지(일반적으로 적합한 서명을 허용하나 부호화 회피를 허락하지 않는 매우 짧은 시간) 또는 서명이 생성되었던 시간을 가르킨다. 만약, 권한 없는 자가 메시지를 가로채고, 메시지를 나중에 모방하려고 시도한다면, 서명은 만료하고 유효하지 않게 될 것이다.

본 발명은 인터넷, 근거리 통신망(LAN), 광대역 통신망(WAN), 직접적인 컴퓨터 연결 등과 같은 유형의 통신 네트워크상에서, 통신 하드웨어나 프로토콜을 사용하여 실행된다. 하드웨어 혹은 하드웨어의 결합은 다양한 클라이언트 및 서버를 위해 사용될 수 있다. 따라서, 여기에서 사용되는 용어 "클라이언트" 및 "서버"는 개인용 컴퓨터, 포터블 컴퓨터, 더미(dumb) 터미널, 씬(thin) 클라이언트, 휴대용 수단, 무선 전화기 혹은 그런 수단들의 결합과 같은 유형의 컴퓨팅 수단과 데이터 터미널에 관련된다. 다양한 클라이언트와 서버는 하나의 위치에서의 하나의 컴퓨터 또는 하나 혹은 다수의 위치에서의 다수의 컴퓨터들일 수 있다. 예를 들어, 서버는 다양한 위치에서 규모조정(scalability)을 용이하게 하기 위하여 공통위치설비(co-location facilities)내에 배치된 복수의 잉여 컴퓨터들로 구성된다. 거기에는 많은 클라이언트들과 많은 서버들이 있을 수 있다. 클라이언트는 물리적으로 같은 하드웨어상에 서버처럼 위치될 수 있다.

적합한 서버 또는 클라이언트 소프트웨어가 사용될 수 있고, 통신 프로토콜들이 사용될 수 있다. 통신은 전기케이블, 광섬유케이블, 또는 다른 케이블, 또는 무선주파수, 적외선 또는 다른 기술들을 이용하는 무선방식으로 이루어질 수 있다. 이 다양한 정보는 어떤 포맷으로 저장될 수 있고, 그래서 여기에 사용되는 용어 "데이터베이스"는 데이터베이스 파일, 룩업테이블 등과 같은 정보의 수집에 관한 것이다. 문서는 어떤 형태가 될 수 있고, 텍스트, 오디오 정보, 비디오 정보, 혹은 복수 형태의 콘텐트의 결합과 같은 어떤 형태의 콘텐트를 포함할 수 있다. 소프트웨어 구성요소로서 설명되는 상술한 본 발명의 부분들은 하드웨어로서 실시될 수 있다. 더욱이, 어떤 기능 블록(block)이 여기에서는 서로 분리되어 독립된 것으로 설명되기 때문에, 이러한 기능 블록들은 하나의 일반 목적 컴퓨터상에 통합되고 실행될 수 있으며, 또는 종래기술에서 알려진 바와 같이 부기능들로 분류된다. 권리설정은 하나 또는 그 이상의 권리나 문서의 사용을 통제하는 규칙일 수 있고, 어떤 적당한 형태일 수 있고, 문서 형태, 사용자의 식별사항, 사용자의 지불 등과 같은 다양한 변수에 근거할 수 있다. 다양한 소프트웨어 모듈은 클라이언트나 서버상에 위치될 수 있다. 예를 들면, 보안모듈은 하나 또는 복수의 구성요소들을 서버측 및/또는 클라이언트측에 상술한 다양한 기능들을 달성하기에 적합하게 포함할 수있다.

본 발명의 바람직한 실시예가 위에서 상세하게 설명한 것처럼, 본 발명의 다른 형태들, 즉 대체, 변화, 각색, 변형물이 동일하게 동작하고, 당업자에게 보여질 것이란 것을 인식해야 한다. 본 공개로 인한 특정 실시예에 의해 본 발명은 제한받지 않으며, 본 발명은 모든 그런 형태, 즉 대체, 변화, 각색 및 변형물들을 포용한다. 따라서, 본 발명의 진정한 보호범위는 첨부된 청구항들 및 법적 균등물에 의해 정의된다.

Claims

내부에 저장된 적어도 하나의 디지털 문서를 갖는 서버;

콘텐트에 접근하여 표현할 수 있는 렌더링엔진을 포함하는 표준 응용프로그램을 갖는 클라이언트 컴퓨터;

상기 클라이언트 및 상기 서버에 연결된 통신 네트워크; 및

상기 표준 응용프로그램에 적합하게 부착되어, 상기 렌더링엔진에 접근하기 위한 보안조건을 실행시키는 보안모듈을 포함하는 사용권이 통합된 디지털 문서를 배포하기 위한 시스템.
제1항에 있어서, 상기 보안조건은 상기 콘텐트와 함께 통합된 사용권을 포함하는 것을 특징으로 하는 시스템.
제2항에 있어서, 상기 사용권은 상기 콘텐트 및 사용방식을 실행하는 조건들의 사용방식을 특정하고 있는 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 보안모듈은 상기 클라이언트 컴퓨터가 요청된 콘텐트의 보안을 관리하기 위한 요청된 소정의 구성에 근거하여 보안 구성요소 소프트웨어를 놓치고 있는 지와, 상기 적어도 하나의 클라이언트 유닛이 상기 소정의 구성에 근거한 보안 구성요소 소프트웨어를 놓치고 있는 지를 결정하도록 동작하며, 상기 보안모듈은 상기 놓친 보안 구성요소 소프트웨어를 상기 클라이언트 컴퓨터에 제공하도록 동작하는 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 보안모듈은 상기 콘텐트를 점검하여, 요청된 콘텐트가 상기 보안모듈의 클라이언트측 구성요소를 요구하는 지를 결정하고, 상기 요청된 콘텐트가 클라이언트측 보안 구성요소를 요구하지 않는다면 상기 표준 응용프로그램으로부터 상기 클라이언트측 보안 구성요소를 분리하도록 동작하는 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 서버는 복수의 서버 컴퓨터들을 포함하고, 상기 보안모듈은 상기 클라이언트 컴퓨터가 하나 또는 그 이상의 키들을 유효 인증을 얻기 위하여 제1서버 컴퓨터와 교환하도록 동작하고, 상기 유효 인증은 상기 클라이언트 컴퓨터가 상기 클라이언트 컴퓨터와 어떤 상기 서버 컴퓨터들 사이에 더 이상의 키교환없이 안전하게 제2서버 컴퓨터와 통신하도록 허락하는 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 보안모듈은 상기 표준 응용프로그램의 사용자 인터페이스를 상기 서버에 의해 특정된 변수들에 따라서 정의하도록 동작하는 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 변수들은 버튼, 색상, 패턴, 애니메이션, 메뉴 및 툴바 중에서 적어도 하나를 설명하는 명세를 포함하는 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 모안모듈은 상기 렌더링엔진에 의해 표현된 이미지위에 클라이언트 특정 데이터에 근거한 워터마크를 첨가하는 것을 특징으로 하는 시스템.
제9항에 있어서, 상기 클라이언트 특정 데이터는 상기 표준 응용프로그램에 유일한 것을 특징으로 하는 시스템.
제9항에 있어서, 상기 클라이언트 특정 데이터는 상기 클라이언트 컴퓨터에 유일한 것을 특징으로 하는 시스템.
제1항에 있어서, 문서 배포에 관련한 거래를 관리하는 거래 수집기 시스템을 더 포함하고, 상기 보안모듈은 서버측 보안 구성요소를 포함하되 그것은 상기 클라이언트 컴퓨터를 상기 거래 수집기로 돌려서, 상기 클라이언트 컴퓨터가 콘텐트 요청할 때 및 상기 클라이언트측 보안 구성요소가 상기 클라이언트 컴퓨터에 설치되지 않을 때에 클라이언트측 보안 구성요소를 상기 거래 수집기에 대한 사용자 정보를 전달하기 위한 변화로 하여 받아들이며, 상기 거래 수집기는 상기 클라이언트 컴퓨터를 소정의 조건들에 근거하여 유효화시키고, 상기 클라이언트측 보안 구성요소는상기 서버에서 상기 클라이언트 컴퓨터를 확인하고 상기 서버가 상기 클라이언트측 컴퓨터와 거래에 관련된 정보를 상기 거래 수집기에게 보고하도록 허락하는 데 유일한 것을 특징으로 하는 시스템.
제12항에 있어서, 상기 요청은 디지털 콘텐트의 구입 요청이고, 상기 하나 또는 그 이상의 요구는 상기 디지털 콘텐트의 구입가격과 사용방법인 것을 특징으로 하는 시스템.
제13항에 있어서, 상기 디지털 콘텐트는 텍스트, 비디오, 음악, 소리, 및 멀티미디어 중에서 적어도 하나를 포함하는 것을 특징으로 하는 시스템.
제9항에 있어서, 상기 거래들에 관련한 상기 정보는 구입가격 정보를 포함하고, 상기 거래 수집기는 각 클라이언트 컴퓨터의 상기 구입가격 정보를 소정의 기간동안 추적하고 누적하는 것을 특징으로 하는 시스템.
제15항에 있어서, 각 거래는 상기 콘텐트 수집기에 의해 누축되는 미소 거래 요청(micro-transaction request)이고, 그 합계는 각 기간의 종기에 신용카드 회사에 전송되는 것을 특징으로 하는 시스템.
제12항에 있어서, 상기 서버는 상기 클라이언트 컴퓨터의 사용자 정보를 얻지못하는 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 서버는 디지털 콘텐트에 삽입된 연결 폴더를 포함하는 저장수단을 포함하고, 상기 폴더의 주소는 그 중에서 하나가 선택되고, 상기 클라이언트 컴퓨터가 콘텐트 요청을 상기 서버에 전송하고 상기 보안모듈이 상기 클라이언트 컴퓨터가 상기 콘텐트에 접근하도록 권한을 부여한 것을 표현할 때 상기 보안모듈이 상기 링크의 적어도 하나에 관련된 정보를 제공하도록 조작되는 지를 확인하기 어려운 것을 특징으로 하는 시스템.
제18항에 있어서, 상기 디지털 콘텐트는 책의 챕터(chapter)이고, 상기 요청은 상기 책의 챕터를 소정의 기간동안 빌리기 위한 요청인 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 보안모듈은 상기 디지털 콘텐트에 대한 참조부호를 포함하는 문서를 생성하고, 상기 렌더링엔진의 어린 인스턴스를 상기 문서를 표현하기 위해 생산하며, 상기 렌더링엔진의 어린 인스턴스는 상기 참조부호에 따라서 보안된 위치로부터 비대칭 프로토콜을 통하여 상기 콘텐트를 검색하도록 동작하는 것을 특징으로 하는 시스템.
제20항에 있어서, 상기 보안된 위치는 신뢰성 있는 서버 시스템인 것을 특징으로 하는 시스템.
제21항에 있어서, 상기 렌더링엔진은 웹브라우저인 것을 특징으로 하는 시스템.
제1항에 있어서, 신뢰성 있는 서버 시스템을 더 포함하고, 상기 보안모듈은 실행 코드의 보안정보를 점검하여 상기 실행 코드가 보안성으로 인증되는지를 확인하여 상기 클라이언트 컴퓨터에 로드되게 하고, 상기 실행 코드가 인증된다면 상기 실행 코드가 상기 클라이언트 컴퓨터에 설치되게 허락하며, 상기 실행코드가 인증되지 않으면 상기 서버는 상기 신용 사이트에 접속하여 상기 실행 코드가 상기 신용 사이트에 의해 인증되는 지를 검증하고 상기 실행코드가 권한이 있다면 상기 실행코드가 상기 클라이언트 컴퓨터에 설치되게 허락하는 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 보안모듈은 상기 서버로부터 상기 클라이언트 컴퓨터로 전송되는 데이터의 제1부분을 부호화하는 한편 상기 데이터의 제2부분이 상기 클라이언트 컴퓨터에 부호화없이 전송되게 동작하며, 데이터 스트림의 총 크기에 대한 상기 제1부분의 데이터 스트림 전송크기는 소정의 최대치보다 작고, 상기 데이터의 총크기에 대한 상기 제1부분의 크기의 비율은 상기 보안 구성요소에 의해 감시되는 통신변수에 근거하여 선택되는 것을 특징으로 하는 시스템.
제24항에 있어서, 상기 통신변수는 전송되는 총 데이터, 통신 네트워크 잠복, 및 통신속도 중에서 적어도 하나를 포함하는 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 보안모듈은 상기 클라이언트 컴퓨터로부터 상기 서버로의 요청에 관한 서명을 찾고, 상기 서명이 존재한다면 상기 서버로부터 상기 클라이언트 컴퓨터로 소프트웨어 에이젼트을 전송하도록 동작하며, 상기 소프트웨어 에이젼트은 상기 컴퓨터를 점검하여 상기 클라이언트 컴퓨터가 안전한 지를 결정하도록 동작하며, 상기 에이젼트이 상기 클라이언트 컴퓨터가 안정하다고 결정한다면 상기 요청은 서명되어 상기 서버로 돌아오는 것을 특징으로 하는 시스템.
제26항에 있어서, 상기 요청은 URL 요청인 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 보안 구성요소는 모든 보안정보를 상기 클라이언트 컴퓨터와 상기 서버 사이에서 전송된 문서의 헤더에 삽입하며, 상기 문서는 콘텐트의 보안정보를 포함하지 않는 바디(body)를 문서내에 갖는 것을 특징으로 하는 시스템.
제28항에 있어서, 상기 문서는 HTML 문서인 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 보안모듈은 상기 클라이언트 컴퓨터에 의해 만들어진 요청을 두 단계의 점검, 즉 상기 요청이 금지된 URL에 해당하는 지를 검검하는 제1스테이지 필터(stage filter)와 상기 요청이 금지된 디렉토리에 해당하는 지를 점검하는 제2스테이지 필터로 동작하며, 상기 요청이 금지된 URL 또는 상기 요청이 금지된 디렉토리에 해당한다면 상기 요청은 상기 서버에 의해 부인되는 것을 특징으로 하는 시스템.
제30항에 있어서, 상기 요청이 상기 서버에 의해 부인된다면, 상기 보안모듈은 상기 클라이언트 컴퓨터가 콘텐트를 전송하기 전에 적합한 접근권한을 표시하도록 동작하는 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 적어도 하나의 문서 요청에 응답하여, 상기 보안모듈은 파일명 확장자를 가지고 소정의 포맷으로 된 파일을 포장하도록 동작하고, 상기 파일명 확장자는 상기 소정의 포맷과 다른 포맷을 표현하지만 상기 렌더링엔진에 적합되게 되며, 상기 파일은 상기 파일내에 포함된 문서를 표현하기에 적합한 프로그램에 대한 참조부호를 포함하고, 상기 참조부호는 상기 렌더링엔진에 적합하게 되며, 상기 렌더링엔진은 상기 파일을 열고 상기 참조부호를 따라서 상기 콘텐트를 표현하기 위해서 상기 프로그램을 얻고 설치하도록 동작하는 것을 특징으로 하는 시스템.
제32항에 있어서, 상기 기설된 포맷은 HTML인 것을 특징으로 하는 시스템.
제32항에 있어서, 상기 파일은 상기 문서들 중에서 요청된 것의 콘텐트를 포함하는 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 보안모듈은 토큰을 상기 클라이언트 컴퓨터에 상기 클라이언트 컴퓨터로부터 상기 서버로 전송된 요청에 응답하여 돌려보내지도록 동작하며, 상기 토큰은 권한있는 서명이 유효하게 하는 시간길이를 표현하고 있는 타임스탬프을 포함하는 것을 특징으로 하는 시스템.
제1항에 있어서, 상기 서버는 복수의 관련된 서버 컴퓨터들을 포함하는 것을 특징으로 하는 시스템.
적어도 하나의 디지털 문서를 서버에 저장하는 단계;

통신 네트워크상에서 적어도 하나의 디지털 문서를 콘텐트를 표현하기 위해 접근이 가능한 렌더링엔진을 포함하는 표준 응용프로그램을 가진 클라이언트 컴퓨터로부터 요청하는 단계;

상기 렌더링엔진을 접근하기 위한 보안조건들을 보안조건들을 실행하기 위해 상기 표준 응용프로그램에 첨부되기에 적합한 상기 보안모듈에 의해 실행하는 단계를 포함하는, 사용권이 통합된 디지털 문서를 배포하는 방법.
제37항에 있어서, 상기 보안 조건들은 상기 콘텐트에 통합된 사용권을 포함하는 것을 특징으로 하는 방법.
제38항에 있어서, 상기 사용권은 상기 콘텐트 및 사용방법을 실행하는 조건들의 사용방법을 특정하고 있는 것을 특징으로 하는 방법.
제37항에 있어서, 상기 실행단계는 요청된 콘텐트의 보안을 관리하기 위해 요구되는 소정의 구성에 근거하여 상기 클라이언트 컴퓨터가 보안 구성요소 소프트웨어를 인지하지 못하는 것 및 상기 적어도 하나의 클라이언트 유닛이 상기 소정의 구성에 근거하여 보안 구성요소 소프트웨어를 인지하지 못하는 것을 결정하는 단계와, 상기 불인지되는 보안 구성요소 소프트웨어를 상기 클라이언트 컴퓨터에 제공하는 단계를 포함하는 것을 특징으로 하는 방법.
제37항에 있어서, 상기 실행단계는 요청된 콘텐트가 상기 보안모듈의 클라이언트측 요소를 요구하는지를 결정하는 단계와 상기 요청된 콘텐트가 클라이언트측 보안 구성요소를 요구하지 않는다면 상기 표준 응용프로그램으로부터 상기 클라이언트측 요소를 분리하는 것을 특징으로 하는 방법.
제37항에 있어서, 상기 서버는 복수의 서버 컴퓨터들을 포함하고, 상기 실행단계는 상기 클라이언트가 하나 또는 그 이상의 키를 유효화 인증을 얻기 위하여 제1서버 컴퓨터에서 교환하는 단계를 포함하며, 상기 유효화 인증은 상기 클라이언트 컴퓨터가 안전하게 제2서버 컴퓨터와 더 이상의 키변환없이 상기 클라이언트 컴퓨터와 상기 서버 컴퓨터들 사이에서 통신하도록 허락하는 것을 특징으로 하는 방법.
제37항에 있어서, 상기 실행단계는 상기 표준 응용프로그램의 사용자 인터페이스를 상기 서버에 의해 특정된 변수들에 따라서 정의하는 단계를 포함하는 것을 특징으로 하는 방법.
제37항에 있어서, 상기 변수는 버튼, 색상, 패턴, 애니메이션, 메뉴, 및 툴바 중에서 적어도 하나를 설명하는 명세를 포함하는 것을 특징으로 하는 방법.
제37항에 있어서, 상기 실행단계를 클라이언트 특정 데이터에 근거하여 클라이언트 특정 워터마크를 생성하는 단계와, 상기 렌더링엔진에 의해 표현된 이미지위에 관한 클라이언트 특정 워터마크를 첨가하는 단계를 포함하는 것을 특징으로 하는 방법.
제45항에 있어서, 상기 클라이언트 특정 데이터는 상기 표준 응용프로그램에 유일한 것을 특징으로 하는 방법.
제37항에 있어서, 상기 클라이언트 특정 데이터는 상기 클라이언트 컴퓨터에 유일한 것을 특징으로 하는 방법.
제37항에 있어서, 상기 실행단계는 상기 클라이언트를 서버측 보안 구성요소와 함께 문서배포에 관련한 거래를 관리하는 거래 수집기 시스템으로 방향을 돌려, 상기 클라이언트 컴퓨터가 문서요청을 하거나 상기 클라이언트측 보안 구성요소가 상기 클라이언트 컴퓨터에 설치되지 않은 경우 클라이언트측 보안 구성요소를 상기 거래 수집기에 사용자정보를 전달하기 위한 변화없이 검색하게 하는 단계 및, 상기 컴퓨터를 소정의 조건들에 근거하여 상기 거래 수집기에 의해 유효화시키는 단계를 포함하며, 상기 클라이언트측 보안 구성요소는 상기 서버에서 상기 클라이언트 컴퓨터를 식별하고 상기 서버가 상기 클라이언트측 컴퓨터와의 거래에 관련한 정보를 상기 거래 수집기에 보고하도록 허락하는 데 유일한 것을 특징으로 하는 방법.
제38항에 있어서, 상기 요청은 디지털 콘텐트의 구입요청이고, 상기 하나 또는 그 이상의 요구는 상기 디지털 콘텐트의 구입가격과 사용방법인 것을 특징으로 하는 방법.
제49항에 있어서, 상기 디지털 콘텐트는 적어도 하나의 텍스트, 비디오, 음악, 소리 및 멀티미디어를 포함하는 것을 특징으로 하는 방법.
제48항에 있어서, 상기 거래에 관련한 상기 정보는 구입가격 정보를 포함하고,상기 거래 수집기는 소정의 시간기간동안 각 클라이언트 컴퓨터마다 상기 구입가격 정보를 추적하여 누적하는 것을 특징으로 하는 방법.
제51항에 있어서, 각 거래는 상기 거래 수집기에 의해 누적되는 미소 거래 요청이고, 상기 총가치는 각 기간의 종기에 신용카드 회사로 전송되는 것을 특징으로 하는 방법.
제48항에 있어서, 상기 서버는 상기 클라이언트 컴퓨터의 상기 사용자 정보를 얻지 못하는 것을 특징으로 하는 방법.
제37항에 있어서, 상기 서버상에 디지털 콘텐트에 삽입된 연결 폴더를 저장하는 단계를 더 포함하고, 상기 폴더의 주소는 그 중에서 하나가 선택되고 확인하기 어려운 것이고, 상기 실행단계는 상기 클라이언트 컴퓨터가 콘텐트 요청을 상기 서버에 전송하고 상기 보안모듈이 상기 클라이언트 컴퓨터가 상기 콘텐트에 접근하도록 권한을 부여한 것을 표현할 때 상기 보안모듈이 상기 링크의 적어도 하나에 관련된 정보를 제공하는 단계를 포함하는 방법.
제54항에 있어서, 상기 디지털 콘텐트는 책의 챕터이고, 상기 요청은 상기 책의 챕터를 소정의 시간기간동안 빌리기 위한 요청인 것을 특징으로 하는 방법.
제37항에 있어서, 상기 실행단계는 상기 디지털 콘텐트에 대한 참조부호들을 포함하는 문서를 생성하는 단계와, 문서를 표현하기 위하여 상기 렌더링엔진의 어린 인스턴스를 만드는 단계 및, 상기 콘텐트를 비대칭 프로토콜을 통하여 상기 참조부호들에 따라서 상기 렌더링엔진의 상기 어린 인스턴스와 함께 보안된 위치로부터 검색하는 단계를 포함하는 것을 특징으로 하는 방법.
제56항에 있어서, 상기 보안위치는 신뢰성 있는 서버 방법인 것을 특징으로 하는 방법.
제57항에 있어서, 상기 렌더링엔진은 웹브라우저인 것을 특징으로 하는 방법.
제37항에 있어서, 상기 실행단계는 실행 코드의 보안정보를 점검하여 상기 실행 코드가 보안성으로 인증되는지를 확인하여 상기 클라이언트 컴퓨터에 로드되게 하는 단계와, 상기 실행 코드가 인증된다면 상기 실행 코드가 상기 클라이언트 컴퓨터에 설치되게 허락하는 단계와, 상기 실행코드가 인증되지 않으면 상기 서버는 상기 신용 사이트에 접속하여 상기 실행 코드가 상기 신용 사이트에 의해 인증되는 지를 검증하는 단계와, 상기 실행코드가 권한이 있다면 상기 실행코드가 상기 클라이언트 컴퓨터에 설치되게 허락하는 단계를 포함하는 것을 특징으로 하는 방법.
제37항에 있어서, 상기 실행단계는

상기 서버로부터 상기 클라이언트 컴퓨터로 전송되는 데이터의 제1부분을 부호화하는 한편 상기 데이터의 제2부분이 상기 클라이언트 컴퓨터에 부호화없이 전송되게 동작하는 단계를 포함하고, 데이터 스트림의 총 크기에 대한 상기 제1부분의 데이터 스트림 전송크기는 소정의 최대치보다 작고, 상기 데이터의 총크기에 대한 상기 제1부분의 크기의 비율은 상기 보안 구성요소에 의해 감시되는 통신변수에 근거하여 선택되는 것을 특징으로 하는 방법.
제60항에 있어서, 상기 통신변수는 전송되는 데이터의 총량, 통신네트워크 잠재, 및 상기 통신속도 중에서 적어도 하나를 포함하는 것을 특징으로 하는 방법.
제37항에 있어서, 상기 클라이언트 컴퓨터로부터 상기 서버로의 요청에 관한 서명을 찾는 단계와, 상기 서명이 존재한다면 상기 서버로부터 상기 클라이언트 컴퓨터로 소프트웨어 에이젼트을 전송하는 단계를 포함하고, 상기 소프트웨어 에이젼트은 상기 컴퓨터를 점검하여 상기 클라이언트 컴퓨터가 안전한 지를 결정하도록 동작하며, 상기 에이젼트이 상기 클라이언트 컴퓨터가 안정하다고 결정한다면 상기 요청은 서명되어 상기 서버로 돌아오는 것을 특징으로 하는 방법.
제62항에 있어서, 상기 요청은 URL 요청인 것을 특징으로 하는 방법.
제37항에 있어서, 상기 실행단계는 모든 보안정보를 상기 클라이언트 컴퓨터와상기 서버 사이에서 전송되는 문서의 헤더내에 삽입되는 단계를 포함하고, 상기 문서는 콘텐트용 보안정보를 포함하지 않는 바디를 상기 문서내에 갖는 것을 특징으로 하는 방법.
제64항에 있어서, 상기 문서는 HTML 문서인 것을 특징으로 하는 방법.
제37항에 있어서, 상기 실행단계는 상기 클라이언트 컴퓨터에 의해 형성된 요청이 금지된 URL에 해당하는 지를 결정하는 제1스테이지 필터(stage filter)점검단계와 상기 요청이 금지된 디렉토리에 해당하는 지를 결정하는 제2스테이지 필터점검단계를 포함하며, 상기 요청이 금지된 URL 또는 상기 요청이 금지된 디렉토리에 해당한다면 상기 서버에 상기 요청을 부인하라고 지시하는 것을 특징으로 하는 방법.
제66항에 있어서, 상기 실행단계는 상기 클라이언트 컴퓨터가 상기 요청이 상기 서버에 의해 부인된다면 콘텐트를 전송하기 전에 적합한 접근 권한을 표현하도록 하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제37항에 있어서, 상기 실행단계는 상기 보안모듈은 파일명 확장자를 가지고 소정의 포맷으로 된 파일을 포장하는 단계를 포함하고, 상기 파일명 확장자는 상기 소정의 포맷과 다른 포맷을 표현하지만 상기 렌더링엔진에 적합되게 되며, 상기 파일은 상기 파일내에 포함된 문서를 표현하기에 적합한 프로그램에 대한 참조부호를포함하고, 상기 참조부호는 상기 렌더링엔진에 적합하게 되며, 상기 렌더링엔진은 상기 파일을 열고 상기 참조부호를 따라서 상기 콘텐트를 표현하기 위해서 상기 프로그램을 얻어 설치하는 것을 특징으로 하는 방법.
제68항에 있어서, 상기 소정의 포맷은 HTML 인 것을 특징으로 하는 방법.
제68항에 있어서, 상기 파일은 상기 문서들 중에서 요청된 하나의 콘텐트를 포함하는 것을 특징으로 하는 방법.
제70항에 있어서, 상기 실행단계는 상기 클라이언트 컴퓨터로부터 상기 서버에 전송된 요청에 응답하여 토큰을 상기 클라이언트 컴퓨터에 돌려보내는 단계를 포함하고, 상기 토큰은 권한 서명이 유효화되는 시간의 길이를 표시하는 타임스탬프을 포함하는 것을 특징으로 하는 방법.
제37항에 있어서, 상기 서버는 복수의 관련된 서버 컴퓨터들을 포함하는 것을 특징으로 하는 방법.
헤더 테그들 사이에 정의 된 HTML 헤더

콘텐트를 포함하는 HTML 바디; 및

상기 헤더에 삽입되는 보안 정보를 포함하는 보안환경하에서 웹브라우저에 의해표현되기에 적합한 HTML 문서.
제73항에 있어서, 상기 바디는 콘텐트용 보안정보를 상기 문서내에 포함하지 않는 것을 특징으로 하는 HTML 문서.
제74항에 있어서, 상기 보안정보는 상기 헤더 속성 형식으로 된 것을 특징으로 하는 HTML 문서.