KR20030096248A

KR20030096248A - 자원들의 사용을 관리하기 위한 시스템에서의 자원의상태를 추적하기 위한 방법과 장치

Info

Publication number: KR20030096248A
Application number: KR10-2003-7009976A
Authority: KR
Inventors: 왕진; 데마티니토마스; 첸에디; 길리암찰스피.; 햄마누엘; 라오귈러모; 랄리마이클; 타탄; 타다연비잔
Original assignee: 콘텐트가드 홀딩즈 인코포레이티드
Priority date: 2001-06-07
Filing date: 2002-06-07
Publication date: 2003-12-24
Also published as: EP1399796A2; WO2002101493A2; WO2002101975A1; ATE332527T1; DE60212969D1; CA2432317A1; JP2004530986A; EP1399796A4; JP5095854B2; EP1399796B2; DE60212969T3; CA2432317C; JP2009015875A; MXPA03011332A; CA2432283A1; KR100604715B1; WO2002101493A3; JP4520736B2; KR100621318B1; EP1302019A1

Abstract

사용 권리들에 따라 보호된 자원에 접근을 허락하기 위한 시스템에서의 보호된 자원의 상태를 관리하기 위한 방법과 시스템. 사용 권리들은 보호된 자원에 통합된 상태를 나타내는 적어도 하나의 상태 변수를 구비한다. 상태 변수와 관련된 메시지는 자원 제어기로부터 인터페이스 프레임워크로 전달된다. 자원 제어기는 사용 권리의 집행에 의해 자원의 사용을 제어하기 위하여 자원에 연결된다. 상태 변수의 값을 추적하도록 작동하는 상태 제어기는 프레임워크 속으로 로드되고 상기 메시지에 따라서 상태 변수의 값을 처리하도록 지시된다. 예를 들면, 메시지는 상태 변수의 현재 값의 질의가 될 수 있다.

Description

자원들의 사용을 관리하기 위한 시스템에서의 자원의 상태를 추적하기 위한 방법과 장치{Method and apparatus for tracking status of resource in a system for managing use of the resources}

관련된 기술의 설명

[0003] 전자 수단들, 그리고 특히 인터넷을 통한 디지털 저작물(즉, 컴퓨터들로 읽을 수 있는 형식들의 문서들 또는 다른 콘텐트)의 광범한 배포를 방해하는 가장 중요한 문제점들 중 하나는 디지털 저작물의 배포 및 사용동안 콘텐트 소유자들의 지적 재산 권리를 집행하기 위한 현재 능력의 결여이다. 이 문제를 해결하기 위한 노력들은 “지적 재산권 관리”(“IPRM”), “디지털 재산권 관리”(“DPRM”), “지적 재산 관리”(“IPM”), “권리 관리”(“RM”) 및 “전자 저작권 관리”(“ECM”)라 칭해지며, 여기에서는 한 데 뭉뚱그려 “디지털 권리 관리(DRM)”라 언급된다. DRM 시스템에 영향을 미칠 것으로 여겨지는 많은 문제들이 있다. 예를 들면, 인증(authentication), 권한 부여(authorization), 회계(accounting), 지불(payment) 및 재무의 청산(financial clearing), 권리명세(rights specification), 권리확인(rights verification), 권리집행(rights enforcement) 및 문서 보호 문제들이 제기될 필요가 있다. 참조에 의해 그 개시내용들이 여기에 통합되는 미합중국 특허들 5,530,235, 5,634,012, 5,715,403, 5,638,443 및 5,629,940은 이 문제들을 제기하는 DRM 시스템을 개시한다.

[0004] 예를 들어, 미합중국 특허 5,634,012는 디지털 문서들의 배포를 제어하기 위한 시스템을 개시한다. 각 렌더링 기기(rendering device)는 그와 함께 통합된 저장소를 가진다. 사용 처리 단계들의 미리 정해진 세트(set)는 문서와 연관된 사용 권리들을 집행하기 위해 저장소들(repositories)이 사용하는 프로토콜을 정의한다. 사용 권리들은 문서의 콘텐트와 함께 존속한다. 사용 권리들은 콘텐트의 오로지 보기, 한번 사용, 배포, 그리고 그러한 종류의 다른 것 따위의 다양한 사용 방식을 특정한다. 사용 권리들과 일치하여 콘텐트에 접근을 허용하기에 앞서요금의 지불, 동일성의 증명 또는 다른 조건들과 같은 전제 조건들이 요구될 수 있다. 한번 전제 조건들이 만족되면 콘텐트에 대한 접근이 허가된다. 조건부 접근의 개념은 접근 제어 응용 프로그램들에서 또한 잘 알려져 있다. 예를 들면, 로그인 네임(login name)과 패스워드(password)의 입력에 의해 네트워크 자원들에 접근을 허가하는 것은 알려져 있다.

[0005] 조건부 접근의 개념은 접근 제어와 DRM 시스템들 둘 모두의 기초이다. 전형적인 전제 조건, 즉 접근 허용을 위한 조건은 주어진 자원에 대한 접근 권리들과 조건들의 세트와 함께 권한을 부여받은 사용자들의 리스트를 정의한다. 주어진 자원과 통합된 전제 조건들은 어떤 정해진 사용자들과 통합된 자원들로 정의될 수 있다. 이는 “역할 기반(role-based)” 접근 제어로 알려져 있다. 전제 조건들은 또한 “규칙 기반(rule-based)” 접근 제어로 알려진 방법에서의 규칙들에 의해 정의될 수 있다. 전제 조건들의 두 형태들 모두는 접근 제어 리스트로 표현되며, 어떤 언어 또는 데이터 구조에서 정의된 자원들의 세트 또는 규칙들이다.

[0006] 조건부 접근은 전형적으로 대부분의 시스템들에 어떤 정해진 조건들이 충족 및/또는 확인된 후에 주체(예를 들면, 사람, 시스템 또는 프로세스)에게 보호된 자원들에 대해 접근을 허락하는 권한부여 처리의 수단으로 주어진다.

저작권 경고

기술분야

[0002] 본 발명은 컴퓨터 시스템에서의 자원들의 관리에 관련된 것이다. 보다 상세하게는, 본 발명은 디지털 콘텐트(digital content), 그리고 보호된 자원들과 통합된(associated with) 사용 권리들(usage rights)과 같은 보호된 자원들의 상태의 추적을 위한 방법 및 장치에 관련된 것이다.

[0009] 본 발명은 바람직한 실시예와 첨부된 도면들을 통해 기술된다.

[0010] 도 1은 바람직한 실시예의 컴퓨터 구성의 블록도;

[0011] 도 2는 종래의 접근 제어 방식의 상태의 개략도;

[0012] 도 3은 바람직한 실시예의 상태의 개략도;

[0013] 도 4는 바람직한 실시예의 조건/권리의 개략도;

[0014] 도 5는 바람직 실시예의 권리들의 상태의 개략도이고;

[0015] 도 6은 권리들 프레임워크의 상태의 상세를 가지는 바람직한 실시예의 상태관리자의 개략도이고;

[0016] 도 7은 자원 관리자의 상세를 가지는 상태 관리자의 개략도이다.

[0007] 본 발명의 제 1양상은 사용 권리들에 따라 보호된 자원에 대하여 접근을 허가하기 위한 시스템에서의 보호된 자원의 상태를 관리하기 위한 시스템이다. 상기 사용 권리들은 통합된 보호된 자원(associated protected resource)의 상태들을 나타내는 상태 변수들을 포함한다. 상기 시스템은 적어도 부분적으로 상태 변수에 의해 정의되는 사용 권리와 통합된 보호된 자원, 사용 권리의 집행에 의해 상기 자원의 사용을 제어하기 위해 상기 자원에 연결된 자원제어기, 상태 변수의 값을 추적하기 위해 작동하는 상태 제어기 및 상기 자원 관리기로부터 상기 상태 변수와 관련된 메시지(message)를 수신하기 위해 작동하고, 상기 상태 제어기를 로드(load)하고, 상기 상태 제어기에 상기 메시지와 일치하여 상태 변수의 값을 제어하도록 명령하는 인터페이스 프레임워크(interface framework)를 포함한다.

[0008] 본 발명의 제 2양상은 사용 권리들에 따라 보호된 자원에 대하여 접근을 허가하기 위한 시스템에서의 보호된 자원의 상태를 관리하기 위한 방법으로서, 상기 사용 권리는 통합된 보호된 자원(associated protected resource)의 상태들을 나타내는 상태 변수들을 포함한다. 상기 방법은 상태 변수와 관련된 메시지를 사용 권리 집행에 의해 상기 자원의 사용을 제어하기 위해 상기 자원에 연결된 자원 관리기로부터 인터페이스 프레임워크로 전송하는 단계, 상태 변수의 값을 추적하기 위해 작동하는 상태 제어기를 상기 프레임워크에 로딩(loading)하는 단계 및 상기 메시지와 일치하여 상태 변수의 값을 제어하도록 상기 상태 제어기에 명령하는 단계를 포함한다.

[0017] 다른 형태들의 자원들은 권리 외의 사용으로부터 자원들을 보호하기 위해 다른 형태의 조건들과 다른 메카니즘들(mechanisms)을 필요로 한다. 바람직한 실시예에서의 조건들과 권리들은 보호된 자원들의 전체 라이프 사이클(life cycle)의 부분이다. 이는 권리들의 조건들이 접근을 허용하기에 앞서 바로 평가되는 것이 아니고, 자원의 실제 소비 동안 또한 평가되는 것을 의미한다. 추가적으로, 조건들은 보호된 자원과 보호된 자원의 상태 둘 모두와 통합된다. 보호된 자원의 다양한 상태들과 통합한 조건들은 콘텐트 소유자들 또는 서비스 제공자들에게 다른 형태의 자원들의 보호를 위한 융통성 있는 방법을 제공한다. 자원들은 디지털 콘텐트, 하드웨어, 소프트웨어 프로그램들, 메모리 스페이스(memory space), 상품(goods), 서비스들(services, 웹서비스들 포함), 시간, 요금들, 사용 권리들 또는 인가(license)가 될 수 있다.

[0018] 사용 권리들은 사용 방식들을 특정한다. 예를 들면, 사용의 한 방식은 특정된 시간동안 특정된 방식으로 한 아이템(item)을 사용하기 위한 능력을 포함할 수 있다. 게다가, 사용 권리들은 배포 권리들과 같은 권리들의 이양을 상술할 수 있고, 사용 권리들을 다른 것에 허가하거나 사용 권리들의 파생을 허락할 수 있다. 바람직한 실시예에서 조건들과 권리들은 자원들의 사용 방식들을 정의하기 위해 통합될 수 있다. 따라서, 조건들과 권리들은 바람직한 실시예에서 하나의 존재로서 언급된다. 그러나, 조건들과 권리들은 별도로 존재할 수 있다.

[0019] 바람직한 실시예는 보호된 자원들의 사용 또는 소비 전에, 사용 또는 소비동안 그리고 사용 또는 소비 후에 권리들의 조건들을 검증하고 확인한다. 각 권리의 현재 상태와 히스토리가 기록될 수 있도록 그리고 후에 사용될 수 있도록 하기 위해 권리들 및 통합된 조건들은 상태로서 기술될 수 있다. “상태 변수들”은 잠재적으로 동적 조건들을 추적한다. 상태 변수들은 자원 또는 다른 동적 조건들의 상태를 나타내는 값들을 가지는 변수들이다. 상태 변수들은 추적될 수 있고, 상태 변수들의 값은 조건에 사용될 수 있다. 예를 들면, 하나의 자원으로서, 하나의 사용 권리는 콘텐트를 보기 위한 권리가 될 수 있고, 하나의 조건은 사용 권리가 실행될 때 다른 사용자들이 그 네트워크에 접속하지 않는 것이 될 수 있다. 이 예에서, 적당한 상태의 값이 다른 사용자들이 로그 인 한 것을 가리킬 때, 그 조건은 더 이상 만족되지 않고 그 콘텐트는 보여질 수 없거나 보여지는 것이 종료된다.

[0020] 도 1은 바람직한 실시예의 컴퓨터 구성(10)을 나타낸다. 조건들(80)은 아래에서 상세히 기술되며, 아이템의 배포자, 콘텐트 서비스 제공자, 기업 관리자 또는 디지털 콘텐트와 같은 자원들에 대한 접근을 제어하기를 원하는 어떠한 다른 당사자들과 관련 있는 준비 응용프로그램(70)을 가지고서 준비될 수 있다. XrML^TM에서와 같은 문법은 조건들(80)을 특정하기 위해 사용될 수 있다. 그러나, 조건들(80)은 다른 방식으로 특정될 수 있다. 사용자는 컴퓨터 또는 사용자와 관련있는 다른 기기들을 포함하는 클라이언트 환경(30)에서 일한다. 렌더링 엔진(rendering engine) 또는 다른 응용프로그램과 같은 소프트웨어 응용프로그램(12)은 클라이언트 환경(30)에 설치될 수 있다. 상태 관리자(40)는 이하에서 설명되는 방식에서 보호된 자원(들)(100)과 파생된 자원(들)(100a)에 대한 접근을 제어한다.

[0021] 바람직한 실시예에서는 컴퓨터 장치인 상태 관리자(40)는 자원(100)과 파생된 자원(100a)에 대한 접근의 보호 측면들을 처리하고, 특히 상태 관리자(40)는 암호적 서명과 같은 서명들을 검증하거나 확인하는 것 또는 알려진 방식의 메시지의 특징들에 대한 다른 확인들에 의해 메시지들을 인증할 것이다. 상태 관리자(40)는 자원 관리자(42)와 조건 확인자(44)를 포함한다. 자원 관리자(42)는 자원 등록, 자원 변형 및 자원 종료에 책임이 있다. "변형"은 자원(100)으로부터 파생된 자원(100a)을 이끌어내기 위해 언급된다. 도 7에 나타낸 바와 같이, 변형은 자원 관리자(42)의 자원 변형 모듈(48)에 의해 성취된다. 예를 들면, 자원이 이미지 또는 그와 같은 것을 나타내는 암호화된 파일인 경우 파생된 자원(100a)은 그 자체의 깨끗한 이미지와 그 이미지를 담고 있는 메모리의 주소를 포함할 수 있다. 자원 등록동안 그 이미지를 담고 있는 메모리 주소는 자원관리자(42)의 자원 저장소(46)에 기록되어지고, 그래서 그 메모리에 대한 어떠한 접근, 즉, 파생된 자원(100a)에 대한 어떠한 접근도 추적되어진다. 이에 더하여, 추적 표시들(워터마크(watermark)와 같은)은 그 이미지에 삽입될 수 있고, 그래서 그 것은 언제든지 추적될 수 있다.

[0022] 조건 확인자(44)는 설정된 조건들을 검사하고 권리들의 상태 즉, 아래에 기술되는 것과 같은, 주어진 권리에 대한 상태 변수들의 현재 값의 모음을 관리한다. 조건 확인자(44)는 파생된 자원(100a)을 제어하기 위해 아래에서 보다 상세히 기술되는 바와 같은 자원 관리자(42)와 상호 작용한다. 권리의 현재상태(44b)가 더 이상 유효하지 않을 때, 즉, 권리들의 권한부여된 상태(44a)에 일치하지 않을 때 아래에서 보다 상세하게 기술되는 바와 같이 조건 확인자(44)는 자원 관리자(42)에게 모든 파생된 자원들(100a)을 삭제(또는 기능을 억제)하도록 요구하거나 파생된 자원들(100a)의 사용이 더 이상 허용되지 않는다는 통지를 하도록 요구한다. 상태 관리자(40) 또한 아래에서 자세히 기술되는 권리들의 상태 프레임워크(20), 상태 제어기(22) 및 상태 확인자(24)를 포함한다.

[0023] 보호된 자원(100)에 대한 접근은 조건들(80)을 기초로 한다. 이 형태의 조건은 하나의 접근 조건 또는 “전제 조건”으로 언급된다. 그러나, 자원(100)과 자원(100)의 상태 둘 모두와 통합하는 조건들에 의해, 그것의 라이프 사이클 동안 다양한 단계들에서 자원(100)을 보호하는 것이 가능해진다. 자원(100)은 사용자에 대한 접근이 허가되기 전에, 접근이 허가되었을 때, 자원(100)의 실제사용동안 및 자원(100)의 사용 후에도 보호될 수 있다. 보호된자원의 전체의 라이프사이클과 통합되는 조건들(80)은 데이터 구조들, 일련의 규칙들 또는 XrML^TM와 같은 언어를 포함하는 문법의 사용에 의해 표현되어질 수 있다. 바람직한 실시예는 조건들을 표현하기 위해 XrML^TM과 같은 언어를 사용한다.

[0024] 자원(100)을 보호하기 위해, 조건들(80)은 자원(100) 그 자체 또는 보호된 자원(100)이 접근되고 사용되는, 클라이언트의 환경(30)의 응용 프로그램(12)과 같은 어떠한 실행환경에서 만든 그러한 자원들을 포함하는 유형 또는 무형의 어떠한 다른 자원들 어느 쪽에나 부과될 수 있다.

[0025] 조건들(80)은 주체들로서 접근이 허용되고 그리고 보호된 자원(100)을 사용하는 사용자 또는 사용자들 그룹과 동일성이 있게 될 수 있다. 조건들(80)의 예들은 아래에 나타냈듯이 XrML^TM언어로 표현된다. 예 A는 보호된 디지털 콘텐트 “XrML 책”을 보기 위한 권리가 주어진 “Edgar”라는 주체에 통합된 조건을 나타낸다. 예 B는 주체들의 그룹, 즉, 보호된 디지털 저작물 “XrML 책”을 프린트하기 위한 권리가 주어진 “콘텐트가드 종업원”범주 하의 모든 사람들에 통합된 조건을 나타낸다.

예 A:

</inventory>

<grant>

<view/>

</grant>

</license>

예 B:

</inventory>

<grant>

</grant>

</license>

[0026] 조건들(80)은 어떤 표제와 같은 어떤 재산들 또는 보안 허가(security clearance)와 같은 권리들을 소유하여야 하는 주체들의 조건들이 될 수 있다. 예 C는 주체들이 관리자의 상징을 소유하여야 한다는 조건을 나타낸다.

예 C:

</inventory>

<grant>

<badge>

<title>Manager</title>

</badge>

<view/>

</grant>

</license>

[0027] 조건들(80)은 보호된 아이템에 대하여 접근하기 위한 시간 간격의 조건들이 될 수 있다. 아래의 예 D는 주체(principal)로서 키 홀더(key holder) “에드가”가 2002년 5월 29일 이전이 아니고 2003년 5월 29일 이후가 아닐 때 콘텐트 “XrML 책”을 볼 수 있는 조건들을 나타낸다.

예 D:

</inventory>

<grant>

<view/>

</validitylnterval>

</grant>

</license>

[0028] 조건들(80)은 콘텐트의 접근을 위해 사용되는 주체 또는 자원의 물리적 위치와 관련될 수 있다. 아래의 예 E는 현재 미국에 있는 누구나가 콘텐트 “XrML 책”을 프린트 할 수 있는 조건을 나타낸다.

예 E:

</inventory>

<grant>

</territory>

</grant>

</license>

[0029] 조건들(80)은 접근하기 위해 주체(principal)가 지불해야만 할 요금을 특정할 수 있다. 아래의 예 F는 $3.10의 요금의 지불로 누구나 콘텐트 “XrML 책”을 프린트 할 수 있는 조건을 나타낸다. 아래의 예 H는 누구나 시간당 $10.00의 요금 지불로 콘텐트 “XrML 책”을 볼 수 있는 조건을 나타낸다.

예 F:

</inventory>

<grant>

<fee>

</paymmentFlat>

<to>

<aba>

</aba>

</to>

</fee>

</grant>

</license>

예 G:

</inventory>

<grant>

<fee>

</paymentPerUse>

</fee>

</grant>

</license>

예 H:

</inventory>

<grant>

<view/>

<fee>

</paymementMetered>

<to>

<aba>

</aba>

</to>

</fee>

</grant>

</license>

[0030] 아래의 예 I는 누구나 그 콘텐트를 프린트할 수 있으나 프린트 권리의 실행은 프린팅 전에 추적 서비스에 의해 추적되어질 것이라는 조건을 나타낸다.

예 I:

</inventory>

<grant>

<uddi>

</serviceKey>

</uddi>

</serviceParam>

</trackReport>

</grant>

</license>

[0031] 조건들(80)은 또한 자원(100)이 소비되는 시스템 상의 조건들이 될 수 있다. 예를 들면, 조건(80)은 그 시스템이 공인된 보안 메카니즘(authorized security mechanism) 또는 다른 특정한 하드웨어 또는 소프트웨어를 가지거나 또는 특정한 최대 수의 사용자들이 로그온 되는 것을 요구할 수 있다.

[0032] 조건들(80)은 저장소나 콘텐트와 같은 자원(100)이 존재하는 다른 장치들을 특정할 수 있다. 조건들(80)은 주체(principal)가 보호된 자원들(100)을 사용하기 전에 반드시 획득해야 하는 승인 통지에 관련될 수 있다. 조건들(80)은 자원(100) 사용 전 또는 후에 통지를 요구할 수 있다. 조건들(80)은 보호된 자원(100) 또는 다른 자원들과 관련된 이전의 권리들을 특정할 수 있다. 조건들(80)은 또한 조건을 확인하기 위한 방법과 같은 다른 조건들(80)에 부과되어질 수 있다.

[0033] 물론, 조건들(80)은 위의 예들에 한정되지 않고, 전제 조건들, 듀어링 접근 조건들, 후 조건들 또는 다른 조건들로서 보호된 자원(100)에 대한 권리에 통합된 어떠한 제한, 의무 또는 요구가 될 수 있다. 또한, 위의 예들은 비록 XrML^TM을 이용하여 나타내었지만 조건들은 XrML로 또는 XrML에 의해 제한되지 않고 다른 방식으로 표현되어질 수 있다.

[0034] 도 4는 바람직한 실시예에 따라 조건(80)을 개략적으로 나타낸 것이다. 조건(80)은 암묵적으로 또는 명시적으로 표현될 수 있는 자원 지정(82)을 포함한다. 예를 들면, 위의 예 A에서, 자원 지정(82)은 “디지털 저작물”요소들의 “라이센스파트아이디(licensePartID)” 속성에 의해 지시되어진다. 조건(80)은 또한 상태 변수들(84)과 상태 변수들(84)의 값들이 어떻게 얻어지는 가를 나타내는 방법 명세(method specification, 86)를 포함한다. 방법 명세(86)는 상태 변수들(84)의 값이 저장되는 장소(들)(아래에 기술된 조건을 처리하는 원격 상태 제어기에서와 같은)와, 조건이 관리되는 곳의 상태 제어기(state controller)와 통신하기 위한 통신 규약과, 그리고 값(서비스 매개변수들 등과 같은)을 얻기 위해 필요한 어떠한 매개변수들을 포함할 수 있다. 선택적으로, 상기 방법은 시스템에 하드-코디드(hard-coded)될 수 있고 방법 명세(86)는 생략될 수 있다.

[0035] 위에서 알려진 바와 같이, 상태 변수들(84)은 조건(80)의 상태들을 나타낸다. 각 상태 변수(44)는 어떠한 순간에라도 때를 맞춰 주체, 권리 및 자원을 위한 대응되는 값을 가진다. 위에 써놓은 바와 같이, 주어진 권리의 상태 변수들의 현재 값들의 모음은 여기에서는 “권리들의 상태”로 언급된다. 도 5는 조건(80), 조건(80)의 상태 변수들(84)을 위한 현재 값들(52)을 포함하는 바람직한 실시예의 권리들의 상태(50)를 나타낸다. 방법 명세(56)는 그 것으로부터 값이 얻어지는 원천(source)을 잠재적으로 포함하는 상태 변수들(84)의 현재 값들(52)을 얻기 위해 사용되는 방법, 자격 증명의 디지털 서명과, 요청의 세션 아이디(session ID) 및 어떠한 다른 적당한 정보를 나타낸다. 방법 명세(56)는 방법 명세(86)와 중복으로 고려될 수 있으며 단지 그것의 되풀이일 수 있다는 것을 알아야 한다. 그러나, 어떤 사례에서, 실제로 얻은 값들(52)이 사용되는 방법 명세(56)는 조건(80)에서 사용하기 위해 제안되는 방법 명세(86)와 다를 수 있다.

[0036] 권리를 위한 조건(80)을 나타내기 위해 권리들의 상태(50)를 사용하는 것은 조건을 확인하기 위해 필요한 모든 정보들은 즉시 접근할 수 있으므로 조건들(80) 확인의 과정을 단순화한다. 권리들의 상태(50)는 만들어지고 그 다음에 대응되는 조건(80)이 평가되어지고 확인될 때에 언제나 사용된다. 각 권리들의 상태(50)는 상태 변수들(84)의 값들(52)을 확인하기 위해 필요한 모든 정보를 포함할 수 있다.

[0037] 인증된 주체는 사용자의 진정함을 확인하는 시스템에 의해 처리된 사용자이다. 예를 들어 사용자가 사용자 이름과 패스워드로 성공적으로 로그-인 할 때, 그 사용자는 인증된 주체 또는 바로 “주체(principal)”가 된다. 주어진 권리들의 세트를 위한 조건(80)은 보호된 자원(100)에 접근하는 것이 주체에게 허용된 상태에서 요구된 상태들의 변수 값들의 세트로 정의된다. 인증된 주체가 보호된 자원(100)에 접근하기를 원할 때, 시스템 상태는 “본래의 상태(original state)”에서 “권한 부여된 상태(authorized state)”로 변한다.

[0038] 일단 시스템이 한 번 권한 부여된 상태이면, 주체는 권한 부여된 작업을 위해 보호된 자원(100)에 접근할 수 있다. 많은 경우에, 보호된 자원에 실제로 접근하는 주체는 인증된 주체 그 자체는 아니다. 예를 들면, 접근은 렌더링 애플리케이션(rendering application), 서비스, 또는 그와 유사한 것과 같은 그러한 다른 인증된 주체에게 위임될 수 있다. 보호된 자원(100)이 접근되어지고 소비되는 동안, 초기 접근을 허용하기 위한 전제 조건들(80)의 세트는 연속된 접근의 권한 부여를 위해 더 이상 적용되지 않을 것이다. 또한, 보호된 자원(100)을 소비하는 것은 자원을 임시의 세트, 즉, 파생된 자원들(100a)로 변형할 것이고, 그 것으로부터 원래의 자원들에 부과된 접근 조건들(80)은 또한 파생된 자원들(100a)에 적용할 수 없게 된다. 자원(100)과 그 것의 파생된 자원(100a)에 대한 접근이 이루어지고 있는 동안 자원(100)과 그 것의 파생된 자원(100a)을 보호하기 위해, 바람직한 실시예는 아래에 상세히 기술되는 “듀어링-접근 조건들(during-access conditions) ”이라 불리는 권한 부여와 보호를 위한 개념을 사용한다.

[0039] 종래의 시스템에서, 자원들은 두 상태들 중 하나의 상태로 있다. 도 2에 나타낸 바와 같이, 자원(100)이 비활성일 때, 시스템은 전제 조건들이 만족될 때까지 본래의 상태(102)로 있다. 전제 조건들이 만족될 때, 자원(100)이 활성화 되고, 그 때에는 시스템은 권한 부여된 또는 활성화 상태(104)로 들어간다. 자원들에 대한 제어를 증가시키기 위해, 바람직한 실시예는 “본래의 상태(original state)”와 “권한 부여된 상태(authorized state)”에 더하여 두 가지의 부가적인 상태들을 정의한다. 도 3에 나타낸 바와 같이 보호된 자원(100)의 사용 또는 접근동안, 시스템 상태는 다음 상태들: 본래의 상태(102, original state), 권한 부여된 상태(104, authorized state), 사용 상태(106, usage state) 및 끝 상태(108, end state)를 통하여 변할 것이다. 각 상태에서, 그 다음 상태로 진행하기 위해 또는 같은 상태를 연속하기 위해 조건들(80)이 정의될 수 있다. 도 1에 관하여 위에서 설명한 바와 같이, 조건들(80)은 어떠한 필요한 사용자 인터페이스(user interface)와 편집 성능들을 구비하는 준비 응용프로그램(preparationapplication, 70)을 사용하여 정의 및 준비될 수 있다. 권한 부여된 상태로 들어가기 위해 만족해야할 필요가 있는 조건들(80)은 “전제 조건들”이라 불린다. 자원(100)의 사용동안 만족되어야할 필요가 있는 조건들(80)은 “듀어링 접근 조건들”로 불리고 사용의 끝에 요구되어지는 조건들(80)은 “후 조건들(post-conditions)”이라 불린다. 조건 확인자(44)는 각 상태를 위해 필수의 조건들(80)을 발동할 수 있다.

[0040] 듀어링 접근 조건들은 원래의 자원(100)으로부터 그 자체 및 인증된 주체에 의해 접근되고 소비되는 동안의 어떠한 파생된 자원들(100a)로 보내진다. 예를 들면, 자원이 권한 부여된 작업 “보기”동안 클라이언트 환경(30)의 화면 상에 디스플레이되는 하나의 문서라면, 그러면 파생된 자원들(100a)은 문서의 데이터, 문서의 표현 포맷 및 디스플레이된 창들 각각을 담는 메모리를 포함할 것이다. 파생된 자원들(100a)은 듀어링 접근 조건들의 세트에 의해 모두 보호될 것이다. 달리 표현하면, 주체는 듀어링 접근 조건들이 오직 만족되는 동안만 파생된 자원들에 대한 접근을 할 수 있을 것이다. 듀어링 접근 조건들은 다른 조건들(80)과 같은 방식으로 정의될 수 있다.

[0041] 다른 하나의 예는 보호된 자원(100)인 서비스를 요청하는, 응용프로그램(12)과 같은, 응용프로그램에 대한 것이다. 한 번 요청이 권한 부여되면, 서비스를 실행하는 응용프로그램은 파생된 자원으로 고려될 것이고 서비스가 실행되는 동안 듀어링 접근 조건들의 세트의 지배를 받는다. 권리들의 권한 부여된 상태(44a)를 정의하는 듀어링 접근 조건들은 아래에 n 상세로 기술된 방식에서 권리들의 현재상태(44b)에 적용된다. 한번 요청된 작업이 완성되면, 강제로 또는 자발적으로, 듀어링 접근 조건들에 의해 보호되는 모든 파생된 자원들(100a)은 지워지고(또는 불능케 되고(disabled)) 시스템 상태는 후 접근 조건들의 세트에 의해 마지막 상태로 옮아간다.

[0042] 자원의 사용 또는 접근 후, 또는 자원의 사용 또는 접근 동안 조건들(80)은 변경되거나 변경되지 않는다. 자원의 사용 후 또는 사용동안 변하는 조건들이 “상태를 가지는 조건들(stateful conditions)”이라 불리는 반면에, 변하지 않는 상태를 가지는 그러한 조건들은 “상태가 없는 조건들(stateless conditions)”이라 불린다. 전제 조건들(80)은 일반적으로 상태가 없는 조건들(80)이고, 보호된 문서에 대한 접근을 제어하기 위 해 사용된다. 듀어링 접근 조건들과 후 접근 조건들은 일반적으로 상태가 있는 조건들(80)이다. 이들은 보호된 자원(100)의 유효기간(lifetime)을 제어하기 위해 사용된다. (예를 들면, 네트워크에 접속한(logged into) 사용자들의 특정 수가 한 번 초과되면 보호된 자원(100)은 더 이상 접근되지 않는다.) 보호된 자원(100)의 다른 단계들과 통합되는 이러한 확장된 형태의 조건들(80)을 가지는, 바람직한 실시예는 보호된 자원(100)의 사용을 인증하기 위한 그리고 자원을 보호하고 자원이 사용되는 동안 자원을 추적하기 위한 메카니즘(mechanism)을 제공한다.

[0043] 도 3에 나타낸 바와 같이 그리고 도 1의 요소들과 관련하여, 바람직한 실시예와 일치하여 시스템은 3단계들을 통해 진척한다. 접근 권한 부여 단계(302)는 상태관리자(40)가 전제 조건들이 만족되는가를 확인하는 것을 통해 권한이 주어진 작업을 위해 인증된 주체에게 보호된 자원에 접근하기 위한 권리를 주는 단계이다. 자원 보호 단계(304)는 듀어링 접근 조건들이 만족한 상태로 남아있는 것을 확인하는 것에 의해 자원들이 사용되는 동안 상태 관리자(40)가 자원(100)과 그것의 파생된 자원들(100a)을 보호하는 단계이다. 작업 종료 단계(306)는 후 접근 조건들이 만족될 때 또는 그렇지 않으면 듀어링 접근 조건들이 만족되는 상태가 그칠 때 상태 관리자(40)가 주어진 작업을 위한 보호된 자원(100)과 파생된 자원(100a)의 사용을 끝내는 단계이다.

[0044] 순환 상태들에서, 같은 자원(100)에 다중 접근이 주어지는 상태에서, 후 조건은 다음 사이클의 전제 조건과 같을 수 있다. 그러한 경우, 무한 루프 상태들을 방지하기 위한 비정적 매개변수가 사용될 수 있다. 예를 들면 시간 의존 조건 또는 인간의 개입과 같은 외부 존재에 의해 변형되거나 부과되는 조건들이다.

[0045] 접근 권한 부여는 권한 부여된 작업을 위한 인증된 주체가 보호된 자원(100)에 접근하기 위한 권리(들)를 준다. 전제 조건들은 평가, 즉, 권리들의 상태를 기반으로 하여 집행된다. 만약 집행이 성공하면, 자원(100)과 어떠한 파생된 자원들(100a)은 단계 406에서 권한 부여된 상태로 들어가고 듀어링 접근 조건들은 집행되기 시작한다.

[0046] 위에서 설명된 것과 같이, 자원 보호는 듀어링 접근 조건들의 세트의 집행에 의해 초기의 보호된 자원(100)과 그것의 파생된 자원(100a) 둘 모두를 보호한다. 접근 권한 부여된 상태로부터 돌아오는 권한 부여된 상태는 권한 부여된 작업동안 집행되는 듀어링 접근 조건들의 리스트를 담고 있다. 강제적(mandatory)시스템에서 모든 파생된 자원들(100a)은 파생된 자원들(100a)이 생성되고 사용될 때 자원 관리자(42)의 자원 저장소(46)(도 7과 아래의 기술내용을 보라)에 등록될 수 있다. 만약 어떠한 듀어링 접근 조건들이 무효가 되면 자원 관리자(42)는 응용프로그램(12)에 의한 보호된 자원(100)과 파생된 자원들(100a)에 대한 접근을 불능으로 만들 것이다.

[0047] 권한을 부여 받은 작업의 종료는 후 조건들(만약 어느 것이라도 존재한다면)의 세트를 실행한다. 후 조건들의 실행은 권리들의 상태를 영원히 변형할 수 있고 그리고 자원(100)에 접근하기 위한 다음 번 요청에 영향을 미친다. 예를 들면, 만약 후 조건이 실행 제한이 도달된 후의 자원(100)에 대한 접근의 제거라면, 제한이 도달될 때 자원(100)은 삭제되거나 접근을 불능으로 만드는 어떤 다른 조치가 취해진다. 작업 종료는 자원 종료를 포함할 수 있다. 자원 관리자(42)는 작업이 강제로 종료되든 그렇지 않든 작업이 끝났을 때 또는 응용프로그램이 자발적으로 작업을 끝낼 때 파생된 자원들(100a)을 삭제(불능으로)할 수 있다. 파생된 자원(100a)의 삭제(또는 불능)는 자원(100)의 보호 과정상 중요하다. 조건 확인자(44)는 보호된 자원(100)의 사용에 관계하고 후 조건들의 세트를 집행한다. 시스템 상태의 변경의 결과에 따라 만약 자원(100)이 쓸모없게 된다면 조건 확인자(44)는 보호된 자원(100)을 무효로(불능케) 할 것이다.

[0048] 권리의 상태는 자원(100)의 사용동안 변경될 것이고 그러므로, 권리들의 상태의 유지, 경신 및 회복의 필요가 있다. 위에서 설명했듯이, 조건확인자(44)는 권리들에 통합된 조건들(80)을 확인하기 위해 권리들의 현재 상태(44b)에 접근한다. 자원들(100)이 사용되거나 접근되는 동안, 조건 확인자(44)는 듀어링 조건들의 세트를 검사하고, 권리들의 현재 상태(44b)를 관리한다. 조건 확인자(44)는 파생된 자원(100a)을 제어하기 위해 자원 관리자(42)와 상호 작용한다. 권리들의 현재상태가 더 이상 유효하지 않을 때, 즉, 듀어링 접근 조건들을 더 이상 만족하지 않을 때 듀어링 조건 확인자(44)는 자원 관리자(42)에게 모든 파생된 자원들(100a)을 삭제(또는 불능케)하도록 요청하거나 응용프로그램에게 파생된 자원들(100a)의 사용이 더 이상 허용되지 않음을 통지하도록 요청한다. 조건(80)을 나타내기 위해 권리들의 상태를 사용하는 것은 특정한 조건(80)을 확인하기 위해 필요한 모든 정보는 즉시 활용할 수 있는 것이기 때문에 조건들(80) 확인의 처리를 단순화 한다.

[0049] 도 1과 도 6에 나타낸 바와 같이, 상태 관리자(40)는 또한 조건 확인자(44)에게 API를 제공하고 상태 제어기(22)와 상태 확인자(24)에게 플러그-인 하부구조를 제공하는 권리들의 상태 프레임워크(20, state of rights framework)를 포함한다. 프레임 워크(20)는 복수의 상태 제어기들(22)과 확인자들(24) 사이에서 통신과 작업들의 조정을 다룬다.

[0050] 각 상태 제어기(22)는 상태를 관리하는, 즉, 주어진 상태 변수의 값을 추적하는 하나의 구성요소이다. 상태 제어기(22)의 기본 구조는 권리들 상태의 프레임워크(20)에 의해 정의되는 APIs와 영속하는 저장소들 또는 저장하기 위한 서비스들과 상호 작용하기 위한 규약 및 상태 변수의 현재 값과 상태변수의 히스토리를 경신하고 질의하는 것을 처리하는 소프트웨어 성분으로 이루어져 있다. 따라서 상태 변수를 관리하는 지속 저장소 또는 서비스의 위치는 권리들의 상태 프레임워크(20)에 대해 투명(transparent)하다.

[0051] 각 상태 확인자(24)는 상태 변수의 값을 확인하는 하나의 구성요소이다. 각 상태 확인자(24)는 상태 확인과 권한들 프레임워크(20)의 API(20c) 감시에 의해 정의되는 인터페이스들의 집합(set)을 구현하는 소프트웨어 구성요소를 포함한다. 상태 제어기(22)와 같이 상태 확인자(24)는 국부적으로 또는 원격적으로 작용할 것이다.

[0052] 도 6에 나타낸 바와 같이 권리들 상태의 프레임워크(20)는 권리들의 값들의 상태를 초기화, 질의, 경신 및 전송하기 위한 인터페이스들의 세트인 상태 조작 API(20b)를 포함한다. 위에서 언급된 바와 같이, 조건(80)을 위한 기본 구조는 상태 변수들과 상태 변수들의 현재 값을 얻기 위해 필요한 방법(a method)을 포함한다.

[0053] 상태 변수들과 같이, 상기 값들은 데이터 구조 또는 현재 값을 기술하는 XrML^TM권리들 언어와 같은 문법에 의해 표현되어질 수 있다. 바람직한 실시예는 상태 변수들을 정의하기 위해서 XrML^TM을, 상태 변수들의 값을 정의하기 위해서 그것의 확장들을 사용한다. 그러나 상태 변수들과 그 값들의 표현은 제한되거나 XrML^TM에 의해 제한되지 않는다. 다음의 예는 XrML^TM을 사용하여 상태 변수가 어떻게 정의될 수 있는지를 보여준다.

예 5:

<sx:stateReference>

<uddi>

<uuid>1F8903B0-FC03-4c5b-A445-AAFCCEC011111</uuid>

</serviceKey>

</uddi>

</sx:stateReference>

<sx:exerciseLimit>9</sx:exerciseLimit

[0054] 위의 예는 프린터 되어지는 자원의 복사가 9번을 넘지 않을 것을 허락하는 프린트 권리의 상태 변수를 기술한다. 조건과 통합된 값은 실행 제한의 예에서의 수(a number)와 같이 단순해 질 수 있거나, 승인 요청의 예에서의 불 값(a boolean value) “예” 또는 “아니오”가 될 수 있다. 그 값은 아래의 예 K에 나타낸 바와 같이 서비스 또는 구성요소에 의해 저장 및 관리되어질 수 있다.

예 K:

<play/>

<sx:stateReference>

<uddi>

<uuid>1F8903B0-FC03-4c5b-A445-AAFCCEC011111</uuid>

</serviceKey>

</uddi>

</sx:stateReference>

</validitylntervalFloating>

[0055] 예 K는 “플레이(play)” 권리의 부동 간격(floating interval)과 통합된 상태를 나타낸다. 이 예에서, 상태 변수는 조건과 통합된 실제 값을 담고 있지 않다. 오히려, 상태 제어기(22)로 작용하는 원격 서비스(상태참조(stateReference))는 그 값을 관리하는 것의 하나이고 상태 변수를 위한 표현으로는 분명하지 않다.

[0056] 상태 조작 API(20b)는 상태 변수의 값들을 질의하기 위한 질의 인터페이스를 포함한다. 상태 변수의 값에 대한 질의는 묻고자 하는 상태 변수와 응답의 값 형식(value-type)을 포함하는 입력을 요구한다. 상태 질의에 대한 응답 값은 상태 값, 상태 히스토리 또는 둘 모두일 수 있다.

[0057] 아래의 예 L에서, 상태 변수의 값 “실행제한(exerciseLimit)”은 “프린트(print)” 권리와 통합되었다.

예 L:

<! State or the exerciseLimit condition for a print rights >

<sx:stateReferenc>

<uddi>

<uuid>1F8903B0-FC03-4c5b-A445-AAFCCEC011111</uuid>

</serviceKey>

</uddi>

</sx:stateReference>

<sx:exerciseLimit/>

<! Request for a specific response type>

</stateQuery>

[0058] 질의를 처리하기 위하여, 권리들의 상태 프레임워크(20)는 어떤 상태 제어기(22)가 이 요청에 책임이 있는지를 결정할 것이고, 그 다음에 위치를 정하고, 인증하고 그리고 특정한 상태 제어기(22)를 로드하고 처리를 위해 상태제어기(22)로 그 요청을 보낸다. 상태 제어기(22)는 국지적 또는 원격적(local or remote)일 수 있다. 한번 요청이 처리되면 응답은 권리들의 상태 프레임워크(20)를 통해 요청자에게 되돌아온다. 다음의 예 1은 그 응답을 기술한다.

예 M:

<! Response to the following query request>

<sx:stateReference>

<uddi>

<uuid>1F8903B0-FC03-4c5b-A445-AAFCCEC011111 </uuid>

</serviceKey>

</uddi>

</sx:stateReference>

<sx:exerciseLimit>9</sx:exerciseLimt>

</stateQuery>

<! State value returned from state query>

<! Digital signature of the credential>

<dsig:signature>

...

</dsig: signature>

</stateResponse>

[0059] 질의 응답은 원래의 질의, 만약 이용할 수 있다면 질의된 상태 변수의 현재 값, 상태 변수의 현재 상태들 또는 상태 히스토리, 동일성 증명(an identification), 세션 아이디(a session id) 및 응답의 디지털 서명을 담고 있다. 디지털 서명은 응답의 무결성을 보장하는데 사용될 수 있다.

[0060] 상태는 오직 상태 질의의 응답이 유효한 상태에서 “세션 아이디(sessionID)”로 제공된 상태 질의의 이전 응답을 기초로 경신될 수 있다. 바람직한 실시예에서는 요청을 구분하기 위해 세션 아이디가 사용되지만, 어떠한 다른 동일성증명도 질의와 경신에 어울리도록 사용될 수 있다. 그래서, 상태 관리자(40)는 상태 변수 값을 얻기 위한 상태 변수의 현재 값과 목적 상태 변수의 경신을 위한 세션 아이디를 질의하여야한 한다. 상태 변수 값의 경신은 상태 변수의 현재 값을 새로운 값으로 변경할 것이다.

[0061] 상태 변수 값의 경신에 부과될 수 있는 많은 구속들이 있다. 예를 들면, 상태 변수에 통합된 권리들은 경신 요청 전에 반드시 여전히 유효하여야만 한다. 경신후의 상태 변수의 새로운 값은 상태 변수로 허용되는 유효한 값이어야만 한다는 것이 다른 구속이 될 수 있다. 예를 들어 만약 최대 프린트 카피(상태 변수)가 4이고 현재 프린트 카피가 3(상태 변수의 현재 값)이라면 2번 더 카피(경신 값)하기 위한 요청은 경신 후의 상태 변수 값이 허용되지 않는 값이기 때문에 거절될 것이다. 부가적으로, 경신을 위한 요청을 만드는 주체(principal) 또는 응용프로그램(application)은 그렇게 하기 위한 권한을 부여받은 상태이어야만 한다. 권리들의 상태 프레임워크(20)는 신원확인, 인증 및 경신 요청을 처리하기 위한 상태 제어기(22)를 로드할 것이다. 아래의 예 M은 상태 값 경신을 위한 요청의 예이다.

예 M:

<! Update on the previous query value. If the query does not match with >

<! The current value of the state variable the update request will be fail >

<sx:stateReference>

<uddi>

<uuid>1F8903B0-FC03-4c5B-A445-AAFCCEC011111</uuid>

</serviceKey>

</uddi>

</sx:stateReference>

<sx:notMoreThan>9</sx:notMoreThan>

<! Session Id is implementation specific to match the updated request >

< and the previous query. Any other identification scheme can be used instead >

</stateController>

<dsig:signature>

...

</dsig:signature>

</stateQuery>

</stateUpdate>

[0062] 상태 값 전송은 상태 관리의 기간들에서 상태 값 경신과 유사하다. 둘 간의 주요 차이점은 상태 변수를 위한 상태 히스토리가 어떻게 유지되는가에 있다. 한번 상태가 전송되면, 상태 변수의 현재 값과 그것의 히스토리는 전송에 따라 경신된다. 그 자체의 상태들이 전송된 권리들이 그 상태 전송의 결과로서 종료되면, 그 전송은 완전한 전송, 그렇지 않으면 부분 전송이라 불린다. 상태 값 전송은 상태 값 경신과 같은 구속을 가질 수 있다. 상태 값의 전송에 포함된 요소들은 전송이 발생되기 전에 권한 부여되어질 수 있다.

[0063] 상태 관리자(40)는 또한 일군의 상태 확인자들(24)을 관리하고, 각 상태 변수를 개별적으로 검증하는 응용프로그램에게 일군의 인터페이스들을 권리의 상태를 나타내는 세트로서 제공한다. 권리들의 상태가 주어진 권리에 통합된 상태 변수들의 현재 값들의 모음임을 상기하라. 권리들의 상태 프레임워크(20)는 각 상태 변수들을 위해 적당한 상태 확인자(24)를 선택 및 로드할 것이다. 한번 상태 확인자(24)가 선택되고 로드되면, 권리들의 상태 프레임워크(20)는 요청을 목표 상태 확인자(24)에게 보내고 응답 메시지로서의 결과를 기다린다. 상태 관리자(40)는 모든 상태 확인자(24)를 한 번에 동시에 실행하거나 상태 변수들과 시스템 구성 간의 의존성에 의존하여 그들을 연속적으로 실행할 것이다.

[0064] 상태 확인자(24)는 상태 질의 응답에서 주어진 상태 변수 값을 확인한다. 상태 변수의 확인을 위한 요청이 수신되면, 권리들의 상태 프레임워크(20)는 상태 질의 응답을 검사하고 그 다음 에 선택하고, 인증하고 그리고 적당한 상태 확인자(24)를 로드하고 상태 확인자(24)에게 상태 질의 응답을 보낸다. 구성가능한 정책과 상태 질의에 저장된 정보를 기초로 하여 상태 확인자(24)는 상태 질의 및 응답 둘 모두에 저장된 정보를 받아들이거나 거부(challenge)를 한다. 상태 질의 및 응답에 저장된 정보가 한번 확인 되면, 확인 과정은 가능한(또는 허용된) 상태 변수의 값들의 세트를 가지는 상태 변수의 현재 값과 비교하여 단순해질 수 있다. 각 상태 확인자(24)는 권리들의 상태 프레임워크(20)에 의해 정의되는 인터페이스들의 세트에 권리를 주는 소프트웨어 구성요소를 포함할 수 있다. 상태 확인자(24)는 국지적 또는 원격적으로(locally or remotely) 작동될 것이다.

[0065] 바람직한 실시예는 퍼스널 컴퓨터들, 서버들, 워크스테이션들, 피디에이들, 씬 클라이언트들(thin clients) 및 그와 유사한 것들과 같은 다양한 기기들을 활용할 수 있다. 예를 들면, 클라이언트 환경은 이동 전화기 또는 PDA와 같은 핸드 헬드 기기일 수 있다. 통신을 위한 다양한 채널들이 사용될 수 있다. 그 위에, 다양한 기능들이 하나의 기기에 통합될 수 있다. 공개된 기능의 기기들과 모듈들은 명확화를 위해 기능별로 분리된다. 그러나, 다양한 기능들은 하드웨어 및/또는 소프트웨어 모듈들 및 기기들과 같이 어떠한 방식으로 결합되거나 분리될 수 있다. 다양한 기능들의 모듈들과 기기들은 분리되거나 결합된 유틸리티(utility)를 가진다.

[0066] 다양한 기록들, 메시지들, 요소들 및 그들의 부분들은 같은 기기 또는 다른 기기들에 저장될 수 있다. 다양한 링크들, 참조들, 명세들 및 그와 유사한 것은 요소들과 결합하기 위해 사용되어질 수 있다. 어떠한 형식의 자원에 접근하는 것도 통제될 수 있다. 상태 변수들의 값들을 추적하기 위한 어떠한 메카니즘도 사용될 수 있다.

[0067] 본 발명은 바람직한 실시예와 예들을 통해 기술되었다. 그러나, 첨부의 청구항들 및 법적으로 그와 동등한 것들에 의해 정의되는 바와 같은 본 발명의 범위를 벗어나지 않고 다양한 변형들이 만들어질 수 있다.

Claims

사용 권리들에 따라 보호된 자원에 대하여 접근을 허가하기 위한 시스템에서의 보호된 자원의 상태를 관리하기 위한 시스템으로서, 상기 사용 권리들은 통합된 보호된 자원(associated protected resource)의 상태들을 나타내는 상태 변수들을 포함하며, 상기 시스템은,

적어도 부분적으로 상태 변수에 의해 정의된 사용 권리에 통합된 보호된 자원;

사용 권리의 집행에 의해 상기 자원의 사용을 제어하기 위해 상기 자원에 연결된 자원 제어기;

상태 변수의 값을 추적하기 위해 작동하는 상태 제어기; 및

상기 자원 관리기로부터 상기 상태 변수에 관련된 메시지를 수신하고, 상기 상태 제어기를 로드하고, 상기 메시지에 따라 상태 변수의 값을 조작하도록 상기 상태 제어기에 지시하도록 작동하는 인터페이스 프레임워크를 포함하는 것을 특징으로 시스템.
제 1항에 있어서, 상기 메시지는 값 질의(value query)이고 상기 인터페이스 프레임워크는 상기 상태 제어기에 상기 상태 변수의 현재 값을 검색하여 그 값을 질의 응답(query response)으로서 반환하라고 지시하도록 작동하는 것을 특징으로 하는 시스템.
제 1항에 있어서, 상기 질의 응답은 현재 값, 질의 및 아이디(ID) 메카니즘을 포함하는 것을 특징으로 하는 시스템.
제 3항에 있어서, 상기 자원 제어기는 상기 상태 변수의 저장된 값을 상기 현재 값을 가지고 경신하도록 작동하는 것을 특징으로 하는 시스템.
제 1항에 있어서, 복수의 상태 변수들에 대응되는 복수의 상태 제어기들이 구비되는 것을 특징으로 하는 시스템.
제 1항에 있어서, 보호된 자원의 사용 권리를 실행하기 위한 적어도 하나의 파생된 자원을 더 포함하고, 상기 상태 변수들은 상기 보호된 자원으로 전달되는 것을 특징으로 하는 시스템.
제 2항에 있어서, 상기 질의 응답을 확인하기 위해 상기 질의 응답에 대해 논리(logic)를 적용하도록 작동하는 상태 확인자를 더 포함하는 것을 특징으로 하는 시스템.
제 4항에 있어서, 상기 자원 제어기는 저장된 값에 반하는 사용 권리의 조건들을 집행하도록 작동하는 조건 확인자를 포함하는 것을 특징으로 하는 시스템.
사용 권리들에 따라 보호된 자원에 대하여 접근을 허가하기 위한 시스템에서의 보호된 자원의 상태를 관리하기 위한 방법으로서, 상기 사용 권리는 통합된 보호된 자원(associated protected resource)의 상태들을 나타내는 상태 변수들을 포함하며, 상기 방법은,

상기 상태 변수와 관련된 메시지를 자원 제어기로부터 인터페이스 프레임워크로 전송하는 단계로서, 상기 자원 제어기는 상기 자원에 연결되어 사용 권리의 집행에 의해 상기 자원의 사용을 제어하는 단계;

상기 상태 변수의 값을 추적하도록 작동하는 상태 제어기를 상기 프레임워크 속으로 로딩하는 단계; 및

상기 상태 제어기에 상기 메시지에 따라 상기 상태 변수의 값을 조작하도록 지시하는 단계를 포함하는 것을 특징으로 하는 방법.
제 9항에 있어서, 상기 메시지는 값 질의(value query)이고 상기 지시 단계는 상기 상태 제어기에 상기 상태 변수의 현재 값을 검색하여 그 값을 질의 응답(query response)으로서 반환하라고 지시하는 단계를 구비하는 것을 특징으로 하는 방법.
제 9항에 있어서, 상기 질의 응답은 상기 현재 값, 상기 질의 및 아이디(ID) 메커니즘을 구비하는 것을 특징으로 하는 방법.
제 11항에 있어서, 상기 자원 제어기 내의 상기 상태 변수의 저장값을 상기 현재 값을 가지고서 경신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제 9항에 있어서, 보호된 자원의 사용 권리를 행사하기 위해 적어도 하나의 파생 자원을 파생시키고, 상기 상태변수들을 상기 보호된 자원으로 전송하는 단계를 더 구비하는 것을 특징으로 하는 방법.
제 9항에 있어서, 상기 질의 응답을 확인하기 위해 상기 질의 응답에 대해 논리(logic)를 적용하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제 12항에 있어서, 상기 저장된 값을 기반으로 하여 상기 사용 권리의 조건들을 실행하는 단계를 더 포함하는 것을 특징으로 하는 방법.