KR101722868B1

KR101722868B1 - 소프트웨어 애플리케이션 프로그램 인터페이스들(api들)을 보안 인증하기 위한 챌린지-응답 시스템을 포함하는 비즈니스 방법

Info

Publication number: KR101722868B1
Application number: KR1020157014437A
Authority: KR
Inventors: 에릭 제이. 스프렁크; 마크 지. 데피에트로; 알렉산더 메드빈스키; 폴 모로니; 신 치우
Original assignee: 제너럴 인스트루먼트 코포레이션
Priority date: 2012-10-29
Filing date: 2013-10-29
Publication date: 2017-04-05
Also published as: US20140123220A1; KR20150081328A; EP2901349A1; WO2014070800A1; CA2899385A1; US9197910B2; US9027159B2; MX355757B; AU2013338059B2; BR112015009690A8; US9172981B2; BR112015009690A2; US20140123321A1; US20140123172A1; MX2015005454A; US20140123242A1; CA2899385C; AU2013338059A1

Abstract

소프트웨어 애플리케이션 프로그램 인터페이스들(API들)을 보안 인증하기 위한 시스템은 관련된 당사자들이 지적 재산(IP)에 대한 권리들 및 대응하는 의무들을 포함하는 시스템을 사용하도록 라이선싱되었는지를 검증하기 위해 제공되는 핸드쉐이크 프로토콜을 포함한다. 핸드쉐이크는 여러 단계를 포함하는 챌린지-응답 프로토콜이다. 먼저, 청구자는 API를 통해 함수에 대한 액세스를 요청하는 요청을 확인자에게 전송한다. 확인자는 청구자에게 전송되는 챌린지를 출력함으로써 요청에 반응한다. 챌린지는 또한 확인자에 의해 보유되어, 청구자의 응답을 확인하기 위한 그의 내부 계산에서 사용된다. 이어서, 청구자는 훅 IP로서 알려진 라이선스에 따르는 컴포넌트들을 이용하여 챌린지를 처리하고, 확인자에게 응답을 발행한다. 확인자는 청구자로부터의 아마도 올바른 후보 응답과 올바른 것으로 알려진 타겟 응답을 비교하고, 일치가 발생하는 경우에 확인자는 청구자가 API에 액세스하는 것을 허가한다.

Description

소프트웨어 애플리케이션 프로그램 인터페이스들(API들)을 보안 인증하기 위한 챌린지-응답 시스템을 포함하는 비즈니스 방법{BUSINESS METHOD INCLUDING CHALLENGE-RESPONSE SYSTEM TO SECURELY AUTHENTICATE SOFTWARE APPLICATION PROGRAM INTERFACES (APIs)}

<관련 출원들의 배경 상호 참조>

본원은 둘 다 2012년 10월 29일자로 출원되고 둘 다 그들 전체가 본 명세서에 참고로 인용되는 이전에 출원된 미국 가출원 제61/719,923호 및 제61/719,928호로부터 35 U.S.C.§119(e)에 따라 우선권을 주장한다.

<기술분야>

본 발명은 애플리케이션 프로그램 인터페이스들(API들)을 통한 소프트웨어 능력들에 대한 액세스의 보안 인증에 관한 것이다. 구체적으로, 본 발명은 훅(Hook) IP로서 알려진 개념을 이용하여 소프트웨어 API 사용 및 인증을 가능하게 하기 위한 체제의 사용에 관한 것이다.

I. 훅 IP - 일반 정의

훅 IP(Hook IP)는 종종 신뢰 형성 메커니즘(trust establishment mechanism)의 일부로서 종종 일부 특허 기술에 대한 액세스를 가능하게 하기 위한 방법을 제공한다. 이것은 디지털 권리 관리(DRM; Digital Rights Management)와 같은 소프트웨어 기능 또는 API를 구현하기를 원하는 누군가가 특정 "훅 IP" 특허들에 의해 커버되는 방식으로 그러한 구현을 행해야 한다는 것을 의미한다. 그러한 훅 IP 라이선스를 획득하는 조건은 특허들은 물론, 잠재적 영업 비밀 및 저작권과 같은 다른 지적 재산(IP)에 관한 라이선스의 조건을 따르는 것이다. 전술한 라이선싱된 IP는 다른 비즈니스 의무들 내에 "훅(hook)"되며, 따라서 "훅 IP"라는 명칭을 갖는다. 라이선스 제공자는 예를 들어 오픈 소스 라이선스에 따라 쉽게 입수될 수 있는 소프트웨어를 커버하는 저작권 또는 리버스 엔지니어링(reverse engineer)될 수 있는 영업 비밀에만 의존해야 하는 것이 아니라, 특허들을 이용함으로써 특허 침해를 근거로 하여 라이선스를 위반하는 "불법" 구현에 대해 법적 조치를 강구하기 위해 특허가 만료되는 훅 IP 전의 잠재적인 20년의 기간을 갖는다.

그러한 훅 IP를 이용하는 시스템의 하나의 공지된 예는 DVB-CSA(Digital Video Broadcast(DVB) Common Scrambling Algorithm)이고, 이는 현재 ETSI(European Television Standards Institute)에 의해 표준화되었으며, 특허들을 라이선싱하고 자신들의 칩 설계에 있어서 알고리즘의 무결성을 유지하는 것에 동의하는 승인된 조건부 액세스 시스템(CAS; conditional access system) 판매자들에게만 라이선싱되는 특허 요소들을 포함한다.

II. 훅 IP - 공지된 사용들

과거에 "훅 IP"라는 용어는 전송 보호를 위해 미디어 콘텐츠(예로서, 비디오 또는 오디오 또는 데이터)의 암호화와 연계하여 훅 IP를 사용하는 라이선싱 스킴에서의 특허들 또는 다른 기술적 지적 재산(IP)의 사용을 의미하도록 정의되었다. 훅 IP라는 용어는 1990년대 후반에 보안 분야에서 일반적으로 공지되었다. 이러한 개념의 일부 공지 구현들은 다음과 같다:

(1) 1994년경에 시작된 DVB(Digital Video Broadcasting) 시스템. 이 시스템은 비디오 스트림들을 효율적으로 암호화하기 위한 CSA(Common Scrambling Algorithm) 암호화 알고리즘을 커버하는 2개의 특허에 의해 커버되었다. 시스템 소스는 미디어 콘텐츠를 케이블, 위성 또는 지상파 신호 경로를 통해 수신기 셋톱 박스에 제공하는 케이블 헤드엔드 또는 위성 업링크였다.

(2) 1996년경에 시작된 DVD-CCA(Digital Video Disk Copy Control Association) 시스템. 이 시스템은 DVD 콘텐츠의 암호화를 제공하는 영업 비밀로서 라이선싱된 CSS(Content Scrambling System) 알고리즘을 사용하였다. 이 시스템은 DVD 플레이어를 이용하여 동작하였다.

(3) 1998년경에 시작된 DTLA(Digital Transmission Licensing Administrator) 시스템. 이 시스템은 특허는 물론, DLNA(Digital Living Network Alliance) 및 1394 파이어와이어 콘텐츠의 암호화를 제공하는 영업 비밀 ECC(Elliptic Curve Cryptography) PKI(Public Key Infrastructure)에 의해 커버되는 암호화 프로토콜을 제공하였다. 이 시스템은 파이어와이어 또는 TCPIP(Transmission Control Protocol/Internet Protocol) 인터페이스를 통해 네트워크 수신기로 송신하는 네트워크 송신기를 이용하여 동작하였다.

(4) 1999년경에 시작된 CPRM(Content Protection for Recordable Media) 엔티티. 이 시스템은 미디어 상의 콘텐츠를 암호화하는 데 사용되는 크립토메리아 암호(Cryptomeria Cipher) 및 팩시밀리 키를 커버한다. 이 시스템은 SD 카드와 같은 이동식 매체를 이용하여 동작하였다.

(5) 2000년경에 시작된 Cable Labs CableCard. 이 시스템은 CableCard 인터페이스의 암호화를 제공하는 2개의 모토롤라 DFAST(Download-Fast) 특허에 의해 커버되었다. 이 시스템은 셋톱 박스에 액세스하기 위한 Cablecard 인터페이스 PCMCIA를 이용하여 동작하였다.

(6) 2000년경에 시작된 DCP(Digital Content Protection) 시스템. 이 시스템은 HDMI(High-Definition Multimedia Interface) 암호화를 제공함으로써 HDCP(High-Bandwidth)의 2개의 버전을 커버한다. 이 시스템은 셋톱 박스로부터 HDMI 인터페이스를 통해 디지털 비디오 디스플레이에 이르는 인터페이스를 제공한다.

(7) 2004년경에 시작된 CMLA(Content Management License Administrator) 시스템. 이 시스템은 특허가 아니라 RSA PKI에 대한 영업 비밀들에 의해 커버되는 것을 생각되며, 무선 장치들에 대한 암호화를 제공한다. 이 시스템은 셀룰러 네트워크를 통한 셀폰 콘텐츠의 전달을 가능하게 한다.

(8) 2005년경에 시작된 AACS(Advanced Access Content System) 시스템. 이 시스템은 블루레이 디스크들(Blu-ray disks)에 대한 암호화를 커버하는 침해 추적 특허들(traitor tracing patents)에 의해 커버되는 것으로 생각된다. 이 시스템은 블루레이 플레이어에 의한 재생을 위해 인식될 블루레이 디스크들의 암호화를 가능하게 한다.

전술한 (5)의 CableCard 시스템을 제외하고는, 훅 IP 라이선스 배열들에 대한 리스트 (1)-(8)에 포함된 IP의 상세들은 공지되지 않았으며, 임의의 또는 모든 특허들, 영업 비밀들 또는 저작권들을 포함할 수 있다. CableCard 시스템 (5)의 경우, CableLabs는 CableCard 복제 방지의 라이선싱 체제(licensing regime)를 위해 모토롤라 훅 IP를 사용하였다. 모토롤라는 이러한 목적을 위해 1989년 8월 22일자로 허여된 미국 특허 제4,860,353호("DFAST1")를 기부하였다. DFAST1은 그 당시에 6년의 만료전 잔여 수명을 가졌다. CableCard에 대한 CableLabs의 제어의 기간을 증가시키기 위한 소망은 2000년 11월 21일자로 출원되어 미국 특허 제6,961,427호로서 허여된 모토롤라의 발명 "DFAST2"를 낳았다. DFAST2는 2020년 11월 21일자로 만료되며, 이는 CableCard에 대한 20년의 총 수명을 생성하고, 2013년 현재 8년이 남았다.

III. 훅 IP - 생태계 및 비즈니스 제어들과 관련된 정의

본 명세서에서 "생태계(Ecosystem)"라는 용어는 상호 이익을 위해 함께 작용하는 비즈니스, 기술 및 라이선싱 상호관계들의 세트를 의미하는 데 사용된다. 생태계가 훅 IP를 포함하거나 포함하지 않을 수 있지만, 본 명세서에서의 우리의 사용은 훅 IP를 포함하는 생태계들만을 포함한다. 생태계는 비즈니스 관점에서 번창하기 위해서는 규칙들을 가져야 한다. 그러한 규칙들은 생태계 행위자(Actor)들이 참여해야 하는 긍정적 거동들은 물론, 바람직하지 않고 금지되는 부정적 거동들을 지배해야 한다. 그리고, 잘못된 거동이 불가피하므로, 부적절하게 거동하는 행위자들을 훈육하는 수단이 필요하다.

생태계의 "설립자들(Founders)"은 통상적으로 생태계 안정성을 생성하고 유지하는 데에 공동의 관심을 갖는다. "설립자들"이라는 용어가 사용되는데, 그것은 생태계 운영자들이 통상적으로 생태계에 대한 조기 입장자들(early entrants) 또는 생태계에서 공격적으로 경쟁하는 엔티티들이기 때문이다.

설립자들의 자원들의 풀링(pooling)에 의해 "라이선싱 엔티티"를 형성하여, 그들이 생성하기를 원하는 생태계를 관리하고 감시하는 좁은 목적의 "라이선싱 엔티티"를 형성할 수 있다. 설립자들 및 그들의 지시에 따르는 라이선싱 엔티티는 통상적으로 그들이 지배하는 생태계 내의 모든 행위자 참여자들에 대해 강요하거나 부과하기를 원하는 제어들 또는 생태계 규칙들의 리스트를 가지며, 그들의 목표는 모든 참여자들에게 서로 유리한 안정적인 생태계의 촉진이다. 이하, 라이선싱 엔티티는 본 명세서에서 설립자들에 대한 프록시로서 참조될 것이다.

라이선싱 엔티티에 의해 부과되는 제어들은 (1) 비즈니스 제어들뿐만 아니라 (2) 기술적 제어들도 포함한다. 비즈니스 제어들 (1)은 지적 재산(IP) 소유권, 또는 부적절한 거동에 대한 법적 책임, 제3자 손상들 또는 결과적인 손상들을 유발할 수 있는 다른 법적 규제들을 포함할 수 있다. IP 소유권은 라이선싱 엔티티에 의해 판단되는 바와 같은 라이선싱 엔티티 솔루션들을 실시하기 위한 권리, 즉 또 하나의 비즈니스 제어를 허가하는 데에도 사용될 수 있다. 최종 비즈니스 제어는 라이선싱 엔티티에 의해 적절한 것으로 간주될 때 당사자의 나쁜 거동을 금지 또는 배제하기 위한 능력을 제공한다는 점에서 권리를 허가하는 능력을 따른다. 기술적 제어들 (2)는 피할 수 있는 기술적 공격, 예를 들어, 인코딩의 해독 또는 IP 권리 획득을 방지하기 위한 시스템의 중요한 생태계 전체 구현(Ecosystem-wide implementation) "강건성 규칙들(robustness rules)"을 포함하며, 이들이 없을 경우에 생태계는 그의 기본적은 생존 능력을 잃을 수 있다. 기술적 규칙들은 행위자 장치들 또는 소프트웨어가 라이선싱 합의의 조건에 따라 준수해야 하는 기술 설계 규칙들을 포함할 수 있는 "준수 규칙들(compliance rules)"도 포함한다.

비즈니스 제어들은 훅 IP의 사용에서 기술적 제어들보다 중요하다. 훅 IP 기술은 사실상 이러한 비즈니스 목적들에 대한 부수적인 문제이며, 훅 IP의 신중한 사용과 더불어, 비즈니스 의무들은 본 명세서에서 후술하는 바와 같이 훅 IP 시스템의 실시를 가능하게 한다.

IV. 전통적인 훅 IP - 문제 및 솔루션들

특허 라이선싱에 기초하는 전술한 훅 IP의 일반 정의에 이어지는 종래 기술의 훅 IP에 대한 여러 가지 일반 설명이 아래에 제공된다. 기술적 문제로 인해 각각의 훅 IP 솔루션이 추진된다. 전통적인 훅 IP 문제 및 솔루션들이 아래에서 모두 분석된다.

A. 문제 1 - 보안 전송 문제

문제 1은 보안 전송 문제, 또는 소정의 자산을 보호하는 데 필요한 암호화를 제공할 필요성이다. 암호화는 해독자들과 암호자들 사이에 상호 신뢰를 형성하는 것에 기초한다. "라이선싱 엔티티"는 종종 기술적 "문제 1"을 해결해야 하는 DVB(Digital Video Broadcast)와 같은 표준 단체 또는 CableLabs 또는 DVD-CCA(Digital Video Disk Copy Control Association)와 같은 산업 컨소시엄 표준 단체이다.

문제 1과 무관하게, 라이선싱 엔티티는 그가 참여자들에게 강제 또는 부과하기를 원하는 제어들을 갖는다. 라이선싱 엔티티는 완전히 법적 구속력을 갖는, 법적으로 라이선싱되는 방식으로 모든 생태계 참여자들에 대해 제어들을 강제하는 수단을 추구하며, 잘못된 거동의 경우에 집행을 제공한다. 이러한 상황에서의 훅 IP의 역할은 나쁜 행위자들 또는 불법 구현들 자체를 반드시 방지하는 것이 아니라, 라이선싱 엔티티에 의해 불법 구현이 발견되는 경우에 특허 침해 집행 수단을 생성하는 것이다.

문제 1은 아마도 EPT(Existing Patent Technology) 및/또는 PPT("Potentially Patentable Technology")를 이용하는 4개의 상이한 기술적 솔루션을 갖는다. EPT 또는 PPT가 (존재할 경우에) 얼마나 많이 사용되는지에 따라, 상이한 정도의 비즈니스 IP 보호가 달성된다. 문제 1에 대한 솔루션 1 - 솔루션 4에 의해 제공되는 비즈니스 보호의 상세들이 아래에서 설명된다.

B. 솔루션 1

솔루션 1은 만료된 특허들, 즉 EPT 또는 PPT에 의해 커버되는 기술을 이용한다. 솔루션 1의 사용을 선택하는 라이선싱 엔티티는 라이선시들(Licensees)에 대한 그의 허가들을 위한 계약 고려 사항으로서 영업 비밀 또는 저작권만을 이용할 수 있다. 그러나, 영업 비밀들은 그들의 집행을 무효화하는 당사자의 리버스 엔지니어링에 의해 법적으로 극복될 수 있다. 저작권들도 저작권 자료를 의도적으로 회피하고 실시 엔티티로서의 저작권 자료의 가치를 무효화하기 위한 독립적인 소프트웨어 리코딩을 통해 법적으로 회피될 수 있다. 솔루션 1 체제는 실시할 특허권 없이는 경쟁 세계에서 매우 적은 생존력을 가지며, 자산의 보호에 있어서 실질적으로 효과가 없을 수 있다.

C. 솔루션 2

솔루션 2는 어떠한 EPT(Existing Patented Technology)도 사용하지 않지만, 미래 허가의 알려지지 않은 기회를 갖는 특허를 신청하기 위한 PPT(Potentially Patentable Technology) 또는 충분한 발명적 내용을 포함할 수 있다. 라이선싱 엔티티가 솔루션 2의 사용을 선택하는 경우, 라이선싱 엔티티가 그의 제어를 유효하게 실시할 수 있는지를 알지 못하는 불확실한 다년의 지연 기간이 존재한다. 이러한 불확실한 기간 동안, 솔루션 2는 전술한 솔루션 1의 특성들을 가지며, 자산의 보호에 있어서 덜 효과적이다.

D. 솔루션 3

솔루션 3은 EPT(Existing Patented Technology)를 사용한다. 라이선싱 엔티티가 솔루션 3의 사용을 선택하는 경우, EPT는 특허 라이선싱을 통해 솔루션 3을 실시하기 위해 즉시 이용 가능하다. 계류중인 특허 출원과 관련된 어떠한 지연 또는 불확실성도 존재하지 않는다. 그러나, EPT의 실시 유용성은 특허들이 만료되기 전의 허가 기간으로 제한된다. EPT가 라이선싱 엔티티의 EPT 사용의 결정 시에 유효한 경우, 20년의 특허 기간은 출원시에 시작되므로, 특허는 아마도 수년 동안 허가되었고, 아마도 평균 8-12년만이 남는다. EPT 특허들이 만료되면, 솔루션 3은 전술한 솔루션 1의 부정적인 특성들을 가지거나, 더 악화되는데, 그 이유는 소정의 저작권 또는 영업 비밀 보호가 솔루션 1에서 남을 수 있고, 라이선싱 엔티티가 추구하는 자산을 보호하는 데에 효과적이지 못할 것이기 때문이다. 따라서, 솔루션 3은 짧은 유용한 수명을 가질 수 있다. 예로서 남은 1년 또는 2년의 매우 짧은 수명은 라이선싱 엔티티의 실시 목적의 관점에서 솔루션 3을 가치없게 만들 것이다.

E. 솔루션 4

솔루션 4는 EPT와 PPT의 혼합을 사용한다. 라이선싱 엔티티가 솔루션 4의 사용을 선택하는 경우, EPT는 계류중인 특허 출원과 관련된 지연 또는 불확실성 없이 특허 라이선싱을 실시하기 위해 즉시 이용될 수 있다. EPT의 초기 실시 유용성은 길거나 짧을 수 있는 그의 특허(들)의 수명으로 제한된다. 또한, PPT 특허 출원 제출 타이밍은 EPT의 만료 전에 특허로서 허여되도록 제어되어야 한다. 특허청에서의 적당한 소송 시간을 허용하기 위해 수년의 오버랩이 필요할 수 있다. 그러나, 소망은 PPT의 수명을 EPT에 이어서 가능한 한 오래 연장하기 위해 PPT를 가능한 한 늦게 출원하는 것이다. 8-12년의 EPT의 평균 수명 및 PPT의 출원이 동시에 주어지면, 라이선싱 엔티티의 총 실시 기간은 28-32년의 범위 내일 것이다.

솔루션 1 - 솔루션 4를 비교할 때, 솔루션 4는 통상적으로 특허 실시가 유효한 경우에 라이선싱 엔티티에 대한 최상의 보호를 제공할 것이다. 솔루션 3은 관련 특허들에 대해 차선의 보호를 제공한다. 솔루션 2는 매우 추론적이며, PPT가 허가될 때까지 라이선싱 엔티티에 대한 제한적인 확실한 비즈니스 제어를 갖는다. 솔루션 1은 어떠한 특허 보호도 유효하지 않은 최소의 유용성을 제공한다.

V. 전통적인 훅 IP 장치들: 소스-채널-목적지

전술한 훅 IP의 이전의 사용들에서, 라이선싱 엔티티는 훅 IP를 문제 1에 대한 솔루션으로 사용하여 "보안 콘텐츠 전송"을 제공한다. 모든 이러한 종래 기술 예의 사례들은 "문제 1"을 동일한 방식으로 해결하였다. 첫째, 귀중한 콘텐츠는 소스로부터 목적지로 안전하게 이동되어야 하였다. 둘째, 소스 및 목적지는 항상 통신 채널에 의해 접속되는 2개의 상이한 물리 장치였다.

소스 및 목적지 물리 장치들이 채널에 의해 접속되었지만, 시스템 내의 각각의 요소의 특성은 변경되었다. 소스는 예를 들어 DVB 구현과 관련하여 목적지로부터 수천 마일 떨어진 것으로부터 예를 들어 DVD CCA 또는 CPRM과 같은 시스템들에서 수 인치 떨어진 것까지 달리 하였다. 소스는 암호화가 이루어지는 신뢰 포인트(trusted point)를 제공하였다. 채널은 신뢰되지 않았으며, 공기를 통과하는 무선 신호 또는 긴 와이어, 또는 저장 장치에 기록된 디지털 비트들일 수 있었다. 목적지는 해독을 위한 신뢰되는 장소를 제공하였으며, 이러한 장소에서 콘텐츠가 저장되었거나, 사용자에게 표시됨으로써 사용되었다.

도 1은 이전의 훅 IP 시스템들에 대해 설명된 소스-채널-목적지 시스템을 나타낸다. 소스(100)는 소스가 훅 IP 라이선스 합의에 서명한 때 암호화를 통해 자산을 제공한다. 이어서, 목적지(102)는 목적지가 훅 IP 라이선스 합의에 서명한 때 자산을 해독하고, 해독된 자산을 사용을 위해 제공한다. 도시된 바와 같이, 암호화 및 해독은 훅 IP 라이선스에 단단하게 결합된다.

VI. 전통적인 훅 IP - 요약

전술한 종래 기술의 훅 IP 상황은 기술 제약의 실시 및 무권리자들에 의한 기술의 사용의 방지를 위해 특허 또는 다른 IP의 행사를 허용하는 방식으로 라이선싱 엔티티에 의해 지시되는 조건들의 리스트에 합의하도록 라이선시들을 강제하기 위해 문제 1에 대한 기술적 솔루션을 이용하는 비즈니스 목표들의 세트로서 요약될 수 있다. 라이선시들은 물론, 불법 구현자들도 훅 IP를 사용하는 시스템에서의 암호화의 고유 특성으로 인해 훅 IP를 사용하는 것이 필요하였다. 훅 IP는 기본적으로 암호화 보호와 강제로 "동승"하였다. 선택된 암호화가 적당히 강하고, 회피될 수 없는 범위에서, 당사자는 귀중한 콘텐츠를 획득하기 위해 암호화 비밀들에 액세스해야 하였다. 훅 IP는 콘텐츠에 대한 비즈니스 보호를 더 제어하고 제공하기 위해 암호화 보호에 부가되었다. 암호화와 훅 IP 사이의 이러한 결합이 없을 경우, 스킴은 붕괴되었다.

I. 문제 설명

이전의 시스템들과 달리, 본 발명의 실시예들은 훅 IP의 근거가 되는 콘텐츠 암호화가 존재하지 않는 상황에서, 전술한 훅 IP 생태계의 비즈니스 목표들을 어떻게 달성할지에 대한 문제를 해결한다. 즉, 해결되는 문제는 문제 1이 아니다.

본 발명의 실시예들이 해결하는 추가 문제는 예를 들어 소프트웨어가 컴퓨팅 클라우드와 함께 또는 그 안에서 사용될 때, 통상적으로, 사전 결정된 하드웨어 장치들과 관련되지 않은 API를 통해, 소프트웨어가 사용되는 시스템을 어떻게 제공할지에 대한 문제이다.

또한, 보안 전송할 귀중한 콘텐츠 자산이 존재하지 않지만, 실시 가능한 비즈니스 규칙들을 갖는 서로 이로운 안정된 생태계를 형성하기 위한 소망이 여전히 존재하는 사례를 고려한다. 이러한 사례는 상황이 한 당사자로부터 다른 당사자로 전송할 어떠한 비디오 또는 오디오 또는 다른 자산도 포함하지 않을 수 있지만, 여하튼 훅 IP를 사용하고 생태계를 형성하는 것이 여전히 필요한 사례이다. 어떠한 귀중한 콘텐츠도 없는 다른 상황은 대상 콘텐츠 자산이 특허, 저작권 또는 영업 비밀을 포함하는 IP에 의해 전혀 커버되지 않을 때, 즉 암호화된 전송을 보장할 만큼 충분히 귀중하지 않을 때 발생할 수 있다. 어떠한 귀중한 콘텐츠도 없는 어느 경우에나, 전송할 콘텐츠 자체가 여전히 존재하지 않을 수 있거나, 어떠한 콘텐츠의 암호화도 존재하지 않는 경우에도, 훅 IP 사용의 동일한 비즈니스 이익들이 요구되는 것으로 가정된다.

이전의 훅 IP 사례들에서, 보호되는 귀중한 콘텐츠에 대한 액세스는 라이선시들이 라이선싱 체제에 가입하게 하는 동기 요인이었다. 당사자들은 액세스를 획득하기를 원했으며, 콘텐츠가 암호화되면 액세스가 가능하였다. 그들은 여전히 라이선스에 서명해야 하였다. 이것의 비즈니스 효과를 어떻게 달성할지는 암호화가 존재하지 않고 콘텐츠가 귀중하지 않을 수 있을 때 동기 요인을 필요로 한다. 생태계 참여자들은 그들을 라이선싱 체제에 가입하도록 격려하기 위한 동기를 필요로 한다.

II. 새로운 실시예들의 요약

본 발명의 실시예들은 전술한 문제들을 해결할 수 있는 시스템을 제공한다. 새로운 시스템은 준수 및 강건성 규칙들, 법적 책무 등을 포함하는 이전의 훅 IP 체제들의 이익들도 제공한다. 새로운 시스템은 또한 여전히 종래 기술의 훅 IP 구현들에서 사용되는 것과 같은 특허된 시스템을 이용하여 실시 가능할 수 있다. 바람직하게, 그러한 새로운 훅 IP 시스템은 위의 솔루션 4에서 설명된 바와 같이 기존의 특허 기술은 물론, 미래의 특허 기술도 포함할 수 있다.

이를 달성할 수 있는 본 발명의 실시예들의 시스템은 훅 IP를 이용하는 새로운 핸드쉐이크(handshake) 프로토콜을 포함한다. 시스템은 (1) 라이선싱 엔티티; (2) 행위자 A1, A2 등; (3) 행위자들에게 부과되는 비즈니스 의무; 및 (4) 행위자들에 의해 구현되는 함수 F1, F2 등을 포함하는 일반화된 훅 IP 생태계에서 더 제공된다. 라이선싱 엔티티는 훅 IP의 특허권에 대한 액세스를 제어하며, 생태계에 비즈니스 규칙들을 부과하는 것을 담당한다. 행위자들은 생태계 내의 원하는 참여자들이며, 라이선싱 엔티티가 제어하기를 원하는 하드웨어 또는 소프트웨어 제품들을 조작한다. 라이선싱 엔티티에 의해 부과되는 의무는 특허권 또는 다른 IP 권리를 포함할 것이다. 함수들은 핸드쉐이킹의 발생을 가능하게 하기 위해 행위자들에 의해 구현된다.

III. 핸드쉐이크 챌린지-응답 프로토콜의 요약

본 발명의 실시예들은 관련된 당사자들이 훅 IP를 사용하도록 라이선싱되었는지를 검증하기 위해 제공되는 핸드쉐이크 프로토콜을 포함한다. 핸드쉐이크는 여러 가지 챌린지/응답(Challenge/Response) 프로토콜 중 하나이며, 아래의 단계들을 포함한다. 먼저, 청구자(Claimant)는 API를 통해 데이터를 전송하기 위해 액세스를 요청하는 요청을 확인자(Verifier)에게 전송한다. 청구자 및 확인자는 클라우드 저장 장치와 같은 임의의 데이터 저장 컴포넌트들일 수 있거나, 케이블 시스템 셋톱 박스, 미들웨어 또는 CAS와 같은 더 특정한 장치들일 수 있다. 확인자는 청구자에게 전송되는 챌린지를 출력함으로써 요청에 반응한다. 챌린지는 또한 확인자에 의해 보유되어, 청구자의 응답을 확인하기 위한 그의 내부 계산에서 사용된다. 이어서, 청구자는 훅 IP를 이용하여 챌린지를 처리하고, 확인자에게 역전송되는 응답을 발행한다. 확인자는 청구자로부터의 아마도 올바른 후보 응답(possibly-correct Candidate Response)과, 그가 보유된 챌린지를 이용하여 처음 계산한 올바른 것으로 알려진 타겟 응답(known-correct Target Response)을 비교하고, 일치(match)가 발생하는 경우에 확인자는 청구자가 API에 액세스하는 것을 허가한다.

본 발명의 추가 상세들이 첨부 도면들을 이용하여 설명된다.
도 1은 소스로부터 목적지로 소프트웨어에 액세스하는 데 사용되는 훅 IP 라이선스를 갖는 종래 기술의 시스템을 나타낸다.
도 2는 청구자와 확인자 사이에서 소프트웨어를 인증하기 위해 제공되는 핸드쉐이크 절차를 갖는 본 발명에 따른 생태계를 나타낸다.
도 3은 훅 IP 라이선싱 체제가 알파 행위자로부터 베타 행위자로 어떻게 풀 스루(pull through)될 수 있는지를 나타낸다.
도 4는 단일의 제1 훅 IP 라이선싱 체제가 알파, 베타 및 감마 행위자를 포함하는 다수의 행위자를 통해 어떻게 풀 스루될 수 있는지를 나타낸다.
도 5는 도 4와 등가인 더 간결한 심벌을 제공한다.
도 6은 도 5의 심벌을 이용하여 도 5보다 복잡한 라이선스 체제를 나타낸다.
도 7은 도 6의 생태계에 대한 행위자들, 함수들 및 훅 IP를 형성하는 표를 나타낸다.
도 8은 케이블 시스템으로부터의 컴포넌트들을 갖는 예시적인 생태계의 컴포넌트들을 나타낸다.

I. 새로운 훅 IP 시스템 - 개요

이를 달성할 수 있는 본 발명의 실시예의 시스템은 훅 IP를 이용하는 새로운 핸드쉐이크 프로토콜을 포함한다. 이 시스템은 아래의 것들을 포함하는 일반화된 훅 IP 생태계에서 더 제공된다:

(1) 훅 IP의 특허권에 대한 액세스를 제어하고, 모든 생태계 참여자들에게 비즈니스 규칙들을 부과하는 것을 담당하는 라이선싱 엔티티.

(2) 생태계 내의 참여자이기를 원하는 행위자 A1, A2 등. 행위자들은 훅 IP 특허권에 대한 액세스를 필요로 하는 제품들 또는 서비스들을 제공함으로써 그 생태계 내에서의 상거래에 참여하기를 원하는 엔티티들이다. 라이선싱 엔티티는 모든 행위자들이 훅 IP를 사용하고 모든 필요한 비즈니스 규칙들을 실시할 수 있기 위해 라이선시들로서 가입하기를 원할 것이다.

(3) 라이선싱 엔티티가 모든 행위자들에게 부과하는, 특허권, 강건성 규칙, 준수 규칙 등을 포함할 수 있는 비즈니스 의무들.

(4) 시스템 내에 존재하고, 행위자(들)에 의해 구현되는 함수 F1, F2 등. 함수들은 하드웨어, 예를 들어 MPEG 압축 해제(decompression) 칩에서 구현될 수 있다. 함수들은 소프트웨어, 예를 들어 미들웨어 API를 통해 전달되는 바와 같은 셋톱 박스 상에서 실행되는 CAS(Conditional Access System) 소프트웨어에서 구현될 수도 있다.

먼저, 핸드쉐이크 프로토콜이 설명되고, 이어서 라이선싱 엔티티에 의해 훅 IP 기술을 이용하는 생태계 제어의 그의 목표들을 달성하기 위한 이용 방법들이 설명될 것이다.

II. 핸드쉐이크 프로토콜 - 챌린지/응답 프로토콜들

핸드쉐이크는 관련 당사자들이 훅 IP를 사용하도록 라이선싱되었는지를 검증하기 위해 제공된다. 핸드쉐이크는 여러 가지 챌린지/응답 프로토콜 중 하나이며, 아래의 단계들을 포함한다.

(1) 먼저, 청구자가 확인자에게 요청을 전송함으로써 핸드쉐이크를 시작한다. 청구자는 본질적으로 요청을 전송하여 핸드쉐이크 프로토콜을 시작함으로써 라이선싱 체제의 멤버이기를 청구할 것이다.

(2) 확인자는 청구자에게 전송되는 챌린지를 출력함으로써 요청에 반응한다. 챌린지는 또한 확인자에 의해 보유되어, 청구자의 응답을 확인하기 위한 그의 내부 계산에서 사용된다. 보유된 챌린지는 훅 IP 및 관리 정보(Administrative Info)를 이용하여 처리되어, 청구자로부터의 응답을 검증하기 위해 확인자의 메모리 내에 유지되는 타겟 응답을 생성한다. 관리 정보는 청구자의 고유 ID, 고유 명칭, 또는 명칭 중 하나 이상을 포함할 수 있다. 관리 정보는 챌린지의 일부로서 청구자에게 전송될 수 있거나, 라이선시로서의 그들의 통지에 기초하여 청구자에게 이미 제공되었다. 확인을 위해 확인자에 의해 준비된 타겟 응답은 청구자에 의해 액세스될 수 없으며, 청구자가 훅 IP를 사용하도록 라이선싱되고 관리 정보도 소유한다는 것을 지시하기 위해 챌린지에 대한 청구자의 응답에 기초하여 나중에 입증될 것이다.

(3) 이어서, 청구자는 훅 IP를 이용하여 챌린지를 처리하고, 확인자에게 역전송되는 응답을 발행한다. 청구자는 관리 정보, 챌린지 및 훅 IP를 이용하여, 후보 응답을 처리하고 생성한다. 후보 응답이 타겟 응답과 동일할 때, 청구자는 훅 IP 및 관리 정보를 올바르게 소유한다는 것이 입증된다.

(4) 확인자는 청구자로부터의 아마도 올바른 후보 응답과, 그가 보유된 챌린지를 이용하여 처음 계산한 올바른 것으로 알려진 타겟 응답을 비교한다. 청구자가 라이선싱 체제의 멤버라는 확인자의 결론의 강도는 아래의 연동 컴포넌트들의 스트링(string of interlocked components): (a) 후보 응답이 훅 IP 및 관리 정보 없이 생성될 수 없는 정도; (b) 사용되는 훅 IP 기술을 우회하거나 회피하기 어려운 정도; (c) 훅 IP가 후보 응답 강도의 추가 최대화를 가능하게 하는 암호 단방향 또는 단방향 트랩 도어 함수를 이용하는 정도에 의존한다. 상기 함수는 SHA(Secure Hash Algorithms)와 같은 알고리즘들을 이용하는 키잉된 해시(keyed hash), 또는 RSA, DSA(Digital Signature Algorithm), ECDSA(El Gamal or Elliptic Curve DSA)와 같은 비대칭 디지털 서명을 포함할 수 있다.

확인자는 비교 동안 후보 응답이 (1) 타겟 응답과 동일한지 또는 (2) 타겟 응답과 동일하지 않은지를 결정할 수 있다. 타겟 응답이 (1) 후보 응답과 동일한 경우, 확인자는 청구자 및 확인자 양자가 동일한 훅 IP 및 관리 정보를 소유한다는 것을 알게 된다. 확인자는 청구자가 훅 IP를 불법 소유하는지를 알 수 없다. 청구자의 소유가 불법이고 라이선싱되지 않았지만, 청구자가 진행하는 경우, 청구자는 임의의 기반 특허 기술의 특허 침해를 범할 것이다. 타겟 응답이 동일한 경우, 청구자가 라이선싱되었는지의 여부에 관계없이, 확인자는 그의 함수의 수행을 시작하여, 요청 청구자가 그의 인터페이스 또는 API를 통해 액세스하는 것을 가능하게 할 것이다. 타겟 응답이 (2) 동일하지 않은 경우, 확인자는 청구자를 신뢰성 없는 것으로 간주하고, 청구자가 그의 인터페이스 또는 API를 통해 액세스하는 것을 가능하게 하기 위한 확인자의 함수의 수행을 거절한다. 동일한 타겟 및 후보 응답들이 존재하지 않는 경우, 청구자는 올바른 훅 IP를 갖지 않고, 라이선싱 엔티티의 체제의 멤버가 아닌 것으로 가정된다.

시스템은 일부 실시예들에서 확인자가 다수의 청구자 간의 차이를 아는 것을 가능하게 하며, 청구자들 중 일부는 핸드쉐이크 프로토콜을 통과했을 수 있고, 일부는 실패했을 수 있다.

확인자는 그러한 프로세스가 특정 실시예에 의해 가능한 경우에 청구자의 실패한 핸드쉐이크를 라이선싱 엔티티에 통지할 수 있다. 이것은 라이선싱 체제 내의 선량한 지위의 멤버가 아니면서 훅 IP를 실시한 것으로 나중에 밝혀진 임의의 당사자에 대한 특허 침해 집행을 가능하게 할 것이다. 이러한 기본 시스템의 경우에는 청구자 또는 확인자가 다른 당사자가 라이선싱 체제 내의 유효하게 라이선싱된 참여자인지를 직접 아는 것이 블가능하다는 점에 유의한다. 따라서, 의문이 존재하고, 절차가 적절한 경우, 확인자는 핸드쉐이킹과 별개인 프로세스에서 청구자의 라이선싱 계약 상태를 요청하는 것이 필요할 것이다. 이것이 바람직한 이유는 특허 침해 당사자들을 조기에 잠재적으로 적발할 수 있기 때문이며, 이는 생태계 상에서 라이선싱 체제를 실시하는 것을 담당하는 라이선싱 엔티티에게 중요하다. 이를 행하기 위해 통상적으로 다른 데이터, 예를 들어 라이선싱된 확인자가 청구자의 라이선스 상태에 관하여 아마도 원격적인 라이선싱 엔티티에 조회할 수 있는 신뢰성 있는 청구자 식별 수단이 필요하다. 라이선싱 확인은 불법 청구자들이 라이선싱 엔티티에 대한 응답을 위조하는 것을 방지하기 위한 보안 수단도 포함할 수 있다.

본 발명의 일 변형은 핸드쉐이크 프로토콜이 청구자 및 확인자 양자에 의해 소유되는 공유 비밀 값을 설정하는 데에도 사용되는 경우이다. 상기 공유 비밀 값은 암호화의 설정에서 암호화 키 또는 암호 컴포넌트로서 또는 핸드쉐이크 프로토콜의 성공적인 완료 후에 API 트랜잭션들에서 청구자 및/또는 확인자에 의해 사용하기 위한 인증자로서 사용될 수 있다. 본 발명의 추가 변형은 포스트-핸드쉐이크(post-Handshake) API 호출들이 상기 공유 비밀 키를 이용하여 인증되거나 그에 의해 완전히 암호화되는 경우를 포함한다.

도 2는 청구자-확인자 핸드쉐이킹 프로세스를 나타내는 도면이다. 이 시스템은 청구자(200) 및 확인자(210)를 도시한다. 청구자(200) 및 확인자(210)는 각각 프로세서 및 프로세서로 하여금 핸드쉐이크 프로세스를 따르게 하기 위한 코드를 저장하는 메모리를 포함한다. 청구자(200) 및 확인자(210)의 내부 컴포넌트들은 핸드쉐이킹을 가능하게 하는 코드 모듈들을 나타낸다. 도시된 바와 같이, 청구자(200)는 처음에 확인자(210)의 블록 212로 전송되는 요청(202)을 생성하며, 이어서 이 블록은 청구자(200)에게 전송되는 챌린지를 생성할 것이다. 이어서, 청구자(200)의 챌린지 생성기 모듈(204)은 그가 서명된 라이선스에 따라 권리를 갖는 훅 IP에 관한 정보를 갖는 응답을 생성한다. 일부 사례들에서, 모듈(204)은 챌린지에 대해 메모리(206)에 저장되는 관리 정보(206)를 포함해서, 챌린지에 필요한 함수 F에 대한 데이터를 더 제공한다. 이어서, 단계 216에서, 확인자는 모듈(214)에서 챌린지와 그가 생성한 타겟 응답을 비교한다. 타겟 응답은 확인자가 청구자(200)가 훅 IP에 따라 권리를 갖는다는 것을 보증하기 위해 챌린지와 함께 필요한 훅 IP 라이선스 정보를 이용하여 챌린지를 처음 생성할 때 모듈(214)에서 생성되었다. 비교기 모듈(214)은 일치가 검출되었는지에 관한 결정을 출력하며, 모듈들(218, 220)은 일치가 발생하였는지에 의존하는 함수를 제공하고, 따라서 모듈(222)은 적절한 응답을 청구자(200)에게 역으로 제공할 수 있다.

예: 케이블 셋톱 박스 시스템에서의 챌린지-응답 프로토콜

이 예에서, 시스템 아키텍처는 셋톱 박스 또는 유사한 장치, 운영 체제 및 미들웨어, 및 미들웨어 상부에서 실행되어 셋톱 박스 액세스를 위한 콘텐츠를 제공하는 애플리케이션들을 포함하며, 애플리케이션들은 잠재적으로 클라우드 메모리 장치들 내에 위치한다. 셋톱 장치는 디지털 콘텐츠의 해독을 수행하는 시스템 온 칩(SoC; System on a Chip)을 포함한다. 암호화된 키들이 ROM에 저장된 소프트웨어에 의해 셋톱의 SoC에 제공된다. 셋톱 장치에 의해 액세스되는 모든 애플리케이션 프로그램들은 미들웨어의 상부에서 실행된다. 셋톱 박스 또는 다른 로컬 하드웨어 자원들에 의한 애플리케이션들에 대한 액세스는 미들웨어에 대한 API 호출들에 의해 행해진다. 사용자에 대한 다양한 서비스들은 디지털 콘텐츠(예로서, 비디오 및 오디오)를 해독하고 액세스하기 위한 허가들 및 (암호화된 형태의) 암호 키들의 획득을 담당하는 CAS 클라이언트를 포함한다. 특정 장치가 특정 멀티미디어 서비스에 대해 허가된 것으로 결정한 후, CAS 클라이언트는 암호화된 키들을 미들웨어 계층에 대한 API 호출들을 통해 하드웨어로 전송할 것이다. 결과적으로, 셋톱의 SoC 하드웨어는 디지털 콘텐츠의 해독, 압축 해제 및 렌더링을 시작할 것이다.

이러한 예시적인 시스템의 제1 변형에서는, CAS 클라이언트 API의 보안 인증을 보증하기 위해 CAS 클라이언트와 미들웨어 사이에 "챌린지-응답" API 메커니즘이 제공된다. 미들웨어가 아니라 제1의 예시적인 시스템 내의 CAS가 "챌린지"를 제어한다. 그러한 절차는 사용자가 셋톱을 특정 채널로 튜닝한 후에 시작된다. 이어서, 미들웨어는 원하는 채널에 대응하는 콘텐츠를 해독하기 위해 CAS 지원에 대한 요청을 제출한다. 그러한 요청을 허가하기 전에, CAS 앱은 CAS에 의해 이전에 사용되지 않았던 비반복 수치 값(non-repeating numerical value)의 난수일 수 있는 "챌린지"를 반환한다. 미들웨어는 챌린지 값에 대해 함수를 계산함으로써 응답하며, 그러한 함수는 특허되었고, 본 명세서에서 훅 IP로서 지칭된다. 이어서, CAS 앱은 미들웨어로부터의 응답을 확인하고, CAS 서비스들이 가능해졌다는 확인 신호(acknowledgement)를 반환한다. CA 앱은 CA API들에 대한 액세스를 허가한 후, 미들웨어에 대한 대응하는 API 호출들을 행함으로써 SoC에 의해 사용할 암호화된 키들을 계속해서 제공한다.

시스템은 암호화 및 해독 키들과 별개인 장치에서 실행되는 모든 애플리케이션들 및 미들웨어의 보안 제어를 제공한다. 특정 API 자원들에 액세스하기 위해, 애플리케이션 또는 미들웨어 제공자는 먼저 비즈니스 합의에 서명하고, 챌린지/응답을 위한 비밀 훅 IP 알고리즘을 획득해야 한다.

대안적인 시스템 예에서는, API들의 흐름이 반전되고, 미들웨어가 "챌린지"를 발행한다. 먼저, 이러한 대안 시스템에서, 전과 같이, 절차는 사용자가 셋톱 박스를 특정 채널로 튜닝한 후에 시작된다. CAS는 해독 키들을 로딩하기 위해 CAS에 의해 사용될 콘텐츠 해독 API들에 액세스하기 위한 요청을 미들웨어에 제출한다. 그러한 요청을 허가하기 전에, 미들웨어는 비반복 수치 값의 난수일 수 있는 "챌린지"를 반환한다. CAS는 챌린지 값에 대해 함수를 계산함으로써 응답하며, 그러한 함수는 훅 IP로서 특허되었다. 이어서, 미들웨어는 CAS로부터의 응답을 확인하고, 해독 API들이 가능해졌다는 확인 신호를 반환한다. 미들웨어는 CAS가 그가 허가되었다는 것을 입증하기 위해 미들웨어에 후속하여 전송할 수 있는 "API 핸들"도 반환한다.

어느 한 예의 사례에서 전달될 채널에 대한 콘텐츠는 케이블 헤드엔드로부터 올 수 있으며, 콘텐츠 키들도 케이블 헤드엔드에 의해 CAS로 전달된다. 이어서, CAS는 헤드엔드로부터 오고 암호화된 콘텐츠 해독 키들을 미들웨어를 통해 셋톱 박스의 SoC로 전송한다. 훅 IP 기반 허가는 챌린지-응답 시나리오를 이용하여 성공했으므로, 미들웨어는 암호화된 키들을 API 핸들과 함께 SoC로 전송할 것이다. 이어서, 셋톱 박스의 사용자는 암호화된 콘텐츠를 채널 상에서 볼 수 있다.

본 명세서에서 "시스템 B"로서 식별되는 예시적인 시스템들의 일 변형에서, 응답은 아래와 같이 함수 "F()"에서 계산되는 챌린지와 함께 앱-클래스(App-Class)를 포함한다.

응답 = F(챌린지, 앱-클래스)

함수 F()는 "챌린지"뿐만 아니라, 모두가 API들의 상이한 세트들에 액세스하는 애플리케이션 클래스도 포함한다. 함수 F()를 계산하기 위해, 애플리케이션은 특정 앱-클래스와 관련된 비밀 파라미터들을 알아야 한다. CAS 애플리케이션들은 한 세트의 비밀 파라미터들을 제공받으며, 사용자 비공개 데이터에 대한 액세스를 갖는 애플리케이션들은 상이한 세트의 비밀 파라미터들을 갖는다. 애플리케이션 제공자는 특정 앱-클래스에 대한 비즈니스 합의에 서명할 것이고, 이어서 대응하는 비밀 파라미터들을 획득할 것이고, 응답을 계산할 수 있을 것이다.

추가 변형에서 "시스템 C"라고 하는 시스템이 존재하며, 여기서는 애플리케이션들의 특정 클래스에 대해 챌린지-응답을 수행하는 것에 더하여, 미들웨어는 특정 장치에 대한 허가들 또는 제한들을 검사해야 한다. 이러한 시스템에서, 애플리케이션들의 동일 클래스의 사례들은 상이한 물리 장치들 내의 상이한 API들에 대한 액세스를 가질 수 있다. 챌린지-응답을 수행하고, 애플리케이션들의 특정 클래스를 식별하는 것에 더하여, 미들웨어는 특정 장치에 대한 허가들 또는 제한들을 검사해야 한다. 이러한 추가적인 장치 검사는 객체로부터의 허가들 또는 외부 서버로부터의 파일을 탐색하기 위해 미들웨어 밖의 외부 서비스에 대한 요청을 필요로 할 수 있다.

III. 관리 정보, 비밀 파라미터들 및 후속 암호화

위에서 부분적으로 지시된 바와 같이, 챌린지-응답 프로토콜 시스템이 API 인증에 대한 적절한 보안을 제공하는 것을 보증하기 위한 수단(measure)들이 제공될 수 있다. 먼저, 단지 임의로 생성된 수보다 많이 포함하는 청구자로부터의 응답을 검증하기 위해 확인자의 메모리 내에 유지되는 타겟 응답을 생성하기 위해 관리 정보가 보유될 수 있다. 지시된 바와 같이, 관리 정보는 청구자의 고유 ID, 고유 명칭, 또는 명칭 중 하나 이상을 포함할 수 있다. 관리 정보는 챌린지의 일부로서 청구자에게 전송될 수 있거나, 라이선시로서의 그들의 통지에 기초하여 청구자에게 이미 제공되었다.

시스템은 소프트웨어 인스턴스화들(software instantiations)에 대한 비일시적인 식별자들 또는 퍼스낼리티들(personalities)의 할당을 요구하여, 일련 번호가 물리 객체를 라벨링하는 방식과 유사한 고유하고 분명한 식별자를 소프트웨어에 제공함으로써 관리 정보에 더 추가할 수 있다. 또한, 예시적인 상황에서 지시된 바와 같이, 챌린지에 대한 응답은 앱-클래스를 포함하는 함수일 수 있다. 지시된 바와 같이, API를 통해 액세스 가능한 애플리케이션 제공자가 특정 앱-클래스에 대한 비즈니스 합의에 서명할 수 있으며, 이어서 대응하는 비밀 파라미터들을 획득하여 응답을 계산할 수 있을 것이다.

추가 보호로서, 완료된 챌린지-응답에 이어서, 데이터가 챌린지-응답 전에 암호화되지 않은 경우에도 데이터의 후속 암호화가 제공될 수 있다. 챌린지-응답 후의 암호화는 더 효율적인 동작을 가능하게 할 수 있는데, 이는 챌린지-응답 후에 더 많은 데이터가 API를 통해 요청될 때 암호화가 챌린지-응답 절차가 이미 발생하였고 청구자가 훅 IP에 따라 확인된 라이선스를 갖고 있다는 것을 의미함에 따라 다른 챌린지-응답 시나리오가 필요하지 않기 때문이다.

IV. 행위자들 및 함수들을 제어하기 위한 핸드쉐이크 프로토콜

전술한 바와 같은 핸드쉐이크 함수가 주어지면, 공통 라이선싱 체제에 따라 모두 제어되는 함수들 및 행위자들을 포함하는 엔티티들의 생태계가 구성될 수 있다. 이것은 훅 IP가 생태계 내의 바람직한 함수 F1, F2 등의 세트에 대해 의무적이게 함으로써 행해지며, 라이선싱 엔티티가 제어하기를 원하는 생태계 행위자들은 이러한 함수 F1, F2 등에 소정의 방식으로 액세스하기 위한 그들의 소망에 의해 동기 부여된다.

함수 F1, F2 등에 대해, 행위자들과의 일련의 링크들이 아래와 같이 핸드쉐이크를 이용하여 생성된다. 먼저, 핸드쉐이크는 함수 F가 임의의 행위자에 의해 이용 가능하게 되는지의 여부를 제어한다. F를 원하는 행위자들은 핸드쉐이크에 의해 요구되는 훅 IP를 필요로 한다. 훅 IP는 라이선싱 엔티티로부터의 라이선스를 요구할 것이다. 이어서, 라이선스는 라이선싱 엔티티가 생태계를 통해 실시하기를 원하는 다른 조건들을 전달할 것이다.

다수의 행위자 A1 및 A2가 단일 함수 F1 또는 다수의 개별 함수 F1 및 F2를 요구할 수 있다. 행위자들 A의 경우, 어느 함수가 귀중하고 어느 함수가 귀중하지 않은지가 관점의 문제일 것이다. 예를 들어, 2개의 행위자 A1 및 A2는 각각 상이한 함수 F1 및 F2를 가질 수 있고, 이들 각각의 행위자는 나머지 행위자에 대해 필요하고 귀중한 것으로 간주된다. 그러한 경우에, A1은 F1에 대한 확인자로서 작용하고 A2는 청구자로서 작용할 수 있으며, A2는 F2에 대한 확인자로서 작용하고 A1은 청구자로서 작용할 수 있다. 모든 경우들에서, 일부 함수 F를 필요로 하는 당사자는 핸드쉐이크 청구자 역할을 통해 그의 요구를, 그러한 함수 F를 갖는 다른 당사자에게 표현하며, 이 다른 당사자는 핸드쉐이크 확인자로서의 자신의 역할을 통해 F에 대한 요구를 충족시키는 자신의 능력을 표현한다.

행위자들 A의 모두가 주어진 함수 F에 대한 액세스를 원하거나 필요로 하지는 않을 수 있으며, 이는 결국 라이선싱 엔티티가 생태계 행위자들의 전체적인 다양한 세트로 하여금 단일 함수 F를 수용하게 할 수 없다는 것을 의미한다. 결과적으로, 생태계는 둘 이상의 행위자 및 함수를 포함할 수 있으며, 라이선싱 엔티티는 그들을 제어할 핸드쉐이크 훅 IP를 구성해야 한다. 상이한 수의 행위자들 및 함수들을 포함하는 다양한 사례들이 아래에 설명된다.

A. 축퇴 사례(Degenerate Case): 하나의 행위자, 임의 수의 함수

본 발명의 실시예들에 대한 생태계는 서로의 함수(들) F를 사용하려고 하는 상이한 행위자들 사이의 상호작용에 의존한다. 핸드쉐이크는 하나의 청구자 행위자의 소프트웨어 또는 장치가 다른 확인자 행위자의 소프트웨어 또는 장치에게 그에 대해 함수 F를 수행할 것을 요청할 때 발생한다. 하나의 행위자만이 존재하는 경우, 이러한 상황은 충족되지 못하며, 축퇴 사례가 발생한다. 단일 행위자 A1이 훅 IP를 이용하여 그 자신과 핸드쉐이크를 수행하는 것은 무의미하다. 따라서, 단일 행위자 사례는 축퇴되고, 동작하지 않을 것이며, 따라서 이 사례는 더 이상 다뤄지지 않는다. 일반적으로, 단일 행위자가 모든 것을 소유하는 경우, 그가 그 자신에게 어떤 것에 대한 허가를 요청할 필요가 전혀 없다.

B. 사례 1: 다수의 행위자, 단일 함수

본 발명의 이 실시예에서, 라이선싱 엔티티는 단일 함수 F1에 액세스하기를 요구하는 다수의 행위자를 제어한다. 이것은 F1을 소유하거나 구현하는 행위자 A1에 부과되는 라이선스 합의로부터 시작함으로써 달성된다. 이어서, F1의 바람직함(desirability)은 라이선싱 체제를 F1의 모든 다른 간접 사용자들에게 전송하며, 따라서 라이선싱 체제를 확산시킨다. 행위자 A1만이 F1을 구현하고, F1의 다른 사용자들은 핸드쉐이크 프로토콜을 통해, 통상적으로 인터페이스 또는 API를 통해 그들에 대해 함수 F1을 수행하도록 A1에게 요청함으로써 F1을 간접적으로 사용하며, 요청자는 핸드쉐이크 청구자로서 작용하고, 행위자 A1은 핸드쉐이크 확인자로서 작용한다는 점에 유의한다.

이러한 실시예의 경우, 라이선싱 체제에 가입하기 위한 첫 번째 행위자인 "알파 행위자(Alpha Actor)"가 항상 존재해야 한다. 알파 행위자는 다른 "베타 행위자(Beta Actor)" 장치들 또는 소프트웨어에 대해 그의 함수 F1을 수행하기 위해 핸드쉐이크 및 훅 IP를 요구하도록 그의 소프트웨어 및 장치를 설계할 것이다. 이러한 제1 알파 행위자는 본질적으로, 첫 번째이고, F1에 대한 베타 행위자 액세스의 조건으로서 훅 IP 핸드쉐이크를 사용함으로써 라이선싱 체제를 부트 스트랩(boot strap)한다. 따라서, 상기 제1 알파 행위자에 인터페이스하는 소프트웨어 또는 장치들을 구현하는 모든 후속 베타 행위자들은 이러한 동일한 훅 IP 및 핸드쉐이크를 사용해야 하며, 법적으로 그렇게 하기 위해 라이선싱 체제에 가입해야 한다.

도 3은 베타 행위자들이 알파 행위자로부터의 F1과 같은 함수에 대한 그들의 필요에 기초하여 훅 IP를 요구하는 것에 풀링(pull)되는 능력을 나타낸다. 생태계 내의 인터페이싱 알파 행위자는 다른 베타 행위자들을 라이선싱 체제에 또한 가입하도록 푸시(push)하는 시장 힘을 생성할 수 있다. 도 3은 도 2에서와 같은 확인자일 수 있는 알파 행위자(300)는 물론, 도 2의 청구자일 수 있는 베타 행위자(302)도 포함한다. 알파 행위자(300)는 함수 F1에 대한 훅 IP1 라이선싱 권리를 제어한다. 베타 행위자(302)는 원하는 비즈니스를 위해 액세스가 이루어질 수 있도록 훅 IP1에 대한 라이선스의 서명으로 그를 풀링하는 함수 F1에 대한 비즈니스 소망을 갖는다. 베타 행위자(302)는 F1과 별개인 다른 함수 F2, F3 등을 더 제어한다. 이어서, 함수 F2 및 F3는 라이선스 훅 IP1을 발전시키거나 훅 IP2 및 훅 IP3 등에 대한 그들 자신의 개별 라이선스들을 생성할 수 있는 생태계 내로 풀링될 수 있다.

C. 사례 2: 다수의 행위자, 다수의 함수

우리는 위에서 라이선싱 체제가 어떻게 알파 행위자를 통해 알파 행위자의 함수 F1을 통해 배타 행위자들의 세트로 전파될 수 있는지를 보았다. 라이선싱 엔티티가 라이선싱 체제에 따라 모두 갖기를 원하는 생태계 내의 다수의 함수 F1, F2 등 및 다수의 행위자 A1, A2 등도 존재할 수 있다. 동일한 또는 상이한 훅 IP가 상이한 함수 F1, F2 등에 대해 사용될 수 있다. 아래에 설명되는 바와 같이 다수의 행위자 및 다수의 함수를 제공하기 위해 2개의 상이한 훅 IP 방법이 이용 가능하다.

i. 사례 2A: 병렬 라이선스 체제 전파

훅 IP는 함수 F1, F2 등 및 행위자 A1, A2 중 하나 이상을 갖는 생태계 내에 병렬로 모두 한 번에 삽입될 수 있다. 모든 행위자들이 라이선싱 체제에 직접 가입하는 것에 동의할 수 있는 한, 그들을 간접적으로 강제하는 것이 필요하지 않을 수 있다. 그러한 경우에, 베타 행위자들에 대한 시장 연동 압력(marketplace interoperability pressure)을 생성하기 위한 알파 행위자가 존재하는 것은 필요하지 않다. 그러나, IP 라이선시들이 기술 라이선스에 기꺼이 가입하고 로열티를 지불하는 그러한 협력적이고 충돌 없는 생태계는 경쟁 세계에서 발생할 가능성이 없다.

ii. 사례 2B: 캐스케이드 라이선스 체제 전파

이 실시예에서, 생태계는 하나의 함수 F1 및 하나 이상의 알파 행위자를 가지며, 이것은 아래와 같이 라이선싱 체제를 단지 알파 행위자들을 너머 베타 및 감마 행위자들로 전파하는 데 사용된다. F1은 하나의 알파 행위자 장치 또는 소프트웨어에서 구현되며, F1은 핸드쉐이크가 완료되고, 훅 IP가 F1을 요청하는 베타 행위자 내에 존재한다는 것을 확인할 때까지 동작하지 않을 것이다. 라이선스를 전파하기 위한 단계들은 다음과 같다:

1. 먼저, F1을 구현하거나 소유하기를 원하는 모든 알파 행위자들이 라이선싱 체제에 가입한다. 라이선싱 엔티티로부터의 알파 행위자의 라이선스는 그에게 라이선싱된 훅 IP 및 핸드쉐이크를 사용하는 API만을 통해 F1을 제공하도록 강요한다.

2. 라이선싱 체제는 F1에 대한 상기 A1 인터페이스 또는 API를 통해 F1을 사용하기를 원하는 모든 베타 행위자들에 대해 "풀 스루"(또는 부과)된다.

3. 라이선싱 체제의 조건들 내에는 그에 따라 라이선싱되는 베타 행위자들에 대한 의무가 배치되어, 그러한 베타 행위자가 A2의 API를 통해 F2를 요청하는 다른 "감마" 행위자에 대해 다른 함수 F2를 수행하기 전에 핸드쉐이크 프로토콜의 성공적인 완료를 요구한다.

4. 함수 F2에 대한 핸드쉐이크 프로토콜 액세스에서 훅 IP를 사용하기 위한 이러한 요건은 함수 F2를 사용하기 위해 라이선스를 취하는 임의의 감마 행위자에 대해 부과된다. 알파 행위자의 F1은 베타 행위자의 F2로 "핸드쉐이크 및 그의 훅 IP를 풀 스루"하고, 이어서 그들은 F2의 사용을 원하는 감마 행위자들로 전파된다.

5. 유사한 수단이 라이선싱 체제를 F2, F3 등을 통해 임의 수의 함수들 및 행위자들로 전파할 수 있다.

이러한 캐스케이드 효과는 알파 행위자들의 소그룹에 의해 구현되는 단일 생태계 함수 F1의 유용성이 많은 베타, 감마, 기타 행위자를 포함하는 잠재적으로 매우 크고 다양한 생태계 전체에 훅 IP 및 라이선싱 체제에 대한 의무를 확산시키는 것을 가능하게 한다. 훅 IP의 알파 행위자 사용은 다른 행위자들이 라이선싱 체제에 가입하도록 강제한다.

도 4는 이러한 개념이 알파 행위자들(400)로부터 베타 행위자들(402)로, 감마 행위자들(404)로 기타 등등으로 무한히 확장된다는 것을 보여준다. 베타 행위자(402)는 그가 알파 행위자(400)에 의해 구현되는 F1 함수들의 사용자가 되기를 원함으로써 생태계 내로 풀링될 것이다. 유사하게, 감마 행위자들은 베타 행위자들의 F2 함수들을 사용하기 위한 그들의 소망을 통해 풀링될 것이며, 기타 등등일 것이다. 동일한 훅 IP1 라이선스가 생태계를 증대시키기 위해 각각에 대해 사용될 것이다. 임의로 복잡한 생태계들이 이러한 방식으로 라이선싱 체제에 종속될 수 있다.

도 5는 앞으로의 도면들에서의 더 복잡한 시나리오들의 추가 예시를 가능하게 하기 위한 도 4의 심벌의 압축을 나타낸다. 도 5에서의 심벌은 도 5의 컴포넌트들(500, 502, 504)을 갖는 도 4와 동일한 시나리오가 도 4의 더 상세한 심벌들(400, 402, 404)을 대체하는 것을 나타낸다. 도 5는 후속 행위자의 요구가 그러한 요구를 충족시킬 수 있는 함수에 따라 숫자로 라벨링된 우측으로부터 그 행위자 내로 들어가는 것을 더 잘 나타낸다. 함수 F1이 요구 N1에서 요구되고, 기타 등등이다. 함수 F의 제공은 행위자 심벌로부터 좌측으로 나간다. 따라서, 하나의 행위자의 함수들은 다른 행위자의 요구들에 연결된다. 라이선싱 체제(510)는 생태계에서의 그의 착수 역할을 나타내기 위해 "F0"으로 라벨링되며, 따라서 훅 IP1(HIP1)에 대한 알파 행위자 A1의 요구는 "N0"으로 넘버링된다.

도 6은 행위자가 (좌측으로부터 연결되는) 다수의 요구 및 (우측으로부터 연결되는) 다수의 함수를 가질 수 있다는 것을 보여준다. 도 6은 더 복잡한 생태계를 그리고 각각 601-606으로 라벨링된 바와 같이 6개의 행위자 A1-A6의 생태계를 통해 단일 라이선싱 체제를 확산시키기 위해 단일 훅 IP 라이선스 HIP1 대신에 다양한 타입의 훅 IP("HIP") HIP1-9를 사용하는 것을 예시하기 위해 도 5의 간결한 심벌을 사용한다.

도 6의 의도는 복잡한 생태계를 예시하는 것이므로, A1-A6 내의 각각의 행위자가 그가 구현하고 API를 통해 다른 행위자들에게 제공하는 하나의 함수에 대해 핸드쉐이크 확인자(또는 실시자)로서 작용할 수 있고, 또한 그가 상이한 API를 통해 요구하는 다른 함수에 대해 핸드쉐이크 청구자일 수 있는 사례가 다루어진다. A1-A6 내의 주어진 행위자는 또한 그가 소유하는 함수에 대한 확인자 및 다른 행위자들이 소유하는 다른 함수들에 대한 청구자일 수 있다. 본 발명은 상이한 컴퓨팅 플랫폼들 상에서 또는 단일 플랫폼 상에서 또는 플랫폼들의 클라우드 구현 상에서에 관계없이 함수들을 API들을 통해 많은 다른 행위자에게 제공하는 상이한 행위자들로부터의 소프트웨어를 포함하는 임의로 복잡한 시나리오들로 자연스럽게 확장된다는 것을 알 수 있다.

도 6의 시스템은 복잡성이 최악인 사례의 시나리오일 수 있다. 그러나, 상이한 타입의 훅 IP가 상이한 "방향들"에서 사용되는 경우에, 즉 A1이 A2로부터의 F2를 원할 때 HIPX가 사용되지만, A2가 A1으로부터의 F1을 원할 때 HIPY가 사용되는 경우에, 훨씬 더 복잡할 수 있다. 본 발명의 실시예들의 일부인 그러한 복잡한 생태계들의 무한한 변형들이 존재한다.

도 6의 생태계의 동작이 아래와 같이 설명된다:

1. 먼저, 601-606으로 라벨링된 6개의 행위자 A1-A6 각각은 적어도 그들의 생태계 내의 존재에 대한 경제적 이익 및 목적인 그 자신의 귀중한 함수(들) F1-F6를 갖는다. 일부 행위자들은 둘 이상의 함수를 갖는데, 예를 들어 행위자 A1은 F1A 및 F1B를 갖는다. 일부 행위자들의 함수들은 다수의 다른 행위자에 의해 사용될 수 있는데, 예를 들어 행위자 A3의 F3는 행위자 A4 및 행위자 A6 양자에 의해 HIP5를 통해 사용된다. 일부 행위자들은 또한 다수의 요구를 가질 수 있는데, 이는 그들이 좌측의 둘 이상의 다른 행위자에 접속된다는 것을, 예를 들어 A4가 F2A를 위해 A2에 그리고 F3를 위해 A3에 접속된다는 것을 의미한다.

2. 이어서, 라이선싱 엔티티로부터 시작하여, 알파 행위자 A1이 라이선싱 체제에 가입하도록 설득된다. A1에 의해 서명된 라이선스는 그에게 그의 함수 F1A에 대해 제1 형태의 훅 IP HIP1을 그리고 그의 함수 F2B에 대해 제2 형태 HIP2를 사용하도록 강제한다. A1은 임의의 인터페이스를 통해 A1의 각각의 귀중한 함수들 F1A 및 F1B에 대한 액세스를 허용하기 전에, A1은 임의의 요청자 청구자와의 핸드쉐이크에서 적절한 훅 IP를 사용한다.

3. 이어서, HIP1 및 HIP2의 알파 행위자 A1의 사용은 행위자 A2 및 A3를 라이선싱 체제 내로 풀링한다. HIP1은 A2가 함수 F1A에 액세스하는 데 필요하다. HIP2는 A3가 함수 F1B에 액세스하는 데 필요하다.

4. 이어서, 라이선싱 체제는 아래와 같이 요청 당사자가 F2A 또는 F2B 또는 F3에 액세스하려고 시도할 때 행위자 A2 및 A3가 HIP3, HIP4 또는 HIP5를 사용하도록 강제한다. HIP3는 A3가 함수 F2B에 액세스하는 데 필요하다. HIP4는 A4가 함수 F2A에 액세스하는 데 사용된다. HIP5는 A4 또는 A6가 함수 F3에 액세스하는 데 필요하다.

5. 또한, 라이선싱 체제는 요청 당사자가 F4A 또는 F4B에 액세스하려고 시도할 때 행위자 A4가 HIP6 또는 HIP7을 사용하도록 강제한다. HIP6는 A5가 함수 F4A에 액세스하는 데 사용된다. HIP7은 A6가 함수 F4B에 액세스하는 데 사용된다. 추가 행위자들이 A5로부터의 F5 또는 A6로부터의 F6를 필요로 하는 경우, HIP8 및 HIP9을 사용하기 위한 유사한 의무들이 각각 A5 및 A6에게 주어질 수 있다.

따라서, 생태계 행위자에 의해 서명된 라이선싱 체제 계약들은 그에게 선택된 훅 IP를 사용하여 도 6에 도시된 바와 같은 함수들을 구현하도록 강제한다. 그러한 계약들은 행위자가 API를 통해 일부 다른 행위자에 대해 청구자로서 작용할 때 하나의 형태의 훅 IP를 그리고 상이한 API를 통해 일부 상이한 다른 행위자에 대해 확인자로서 작용할 때 다른 형태의 훅 IP를 사용하도록 강제할 수 있다. 도 7은 도 6에서 구현된 함수들 및 의무들을 표 형태로 나타낸다.

도 6-7에 도시된 프로세스 및 개념은 무한히 확장되어, 라이선싱 엔티티, 모든 행위자들, 그들이 생태계에 제공하는 모든 행위자의 함수들 사이의 법적 의무 관계들의 임의 세트를 구현하기 위해 다른 행위자들을 라이선싱 체제 내로 풀링할 수 있으며, 이는 다양한 상이한 타입의 훅 IP를 이용하여 달성된다.

도 6에 도시된 복잡한 생태계들에는 9개의 상이한 타입의 훅 IP가 도시된다는 점에 유의한다. 훅 IP의 정확한 기술 특성에 따라, 그러한 생태계에 대한 9개의 변형을 쉽게 생성하는 것은 쉽거나 어려울 수 있다. 대안으로서, 전술한 "관리 정보"는 임의 수의 변형을 생성하기 위해 단일 타입의 훅 IP와 함께 사용될 수 있다. 일례는 관리 정보가 16 비트 데이터 필드와 같은 "훅 IP 타입" 데이터 아이템을 포함하는 경우이다. 그러한 훅 IP 타입은 동일한 기본 타입의 훅 IP의 65,536개의 상이한 변형을 쉽게 허용할 것이다.

그러한 접근법의 유일한 단점은 라이선싱 체제 내의 임의의 라이선시가 그들이 훅 IP 타입 필드를 변경하는 경우에 모든 그러한 변형들에 대한 액세스를 고유하게 갖는다는 것이다. 그러한 변경은 그들이 서명한 라이선스의 계약 위반일 수 있지만, 특허 침해를 구성하지는 않을 수 있다. 따라서, 각각의 상이한 타입의 훅 IP가 상이한 특허에 의해 제어되고, 각각의 상이한 특허가 그를 사용하는 임의의 당사자에게 상이한 특허권을 요구하는 것이 더 신뢰성 있다. 이것은 요구될 수 있는 많은 수의 유사한 특허들이 주어지는 경우에는 실제로 구현하기 어려울 수 있다.

관리 정보는 추가된 보안 특성들에 대한 암호화 키들 또는 더 복잡한 제어 시나리오들을 인스턴스화하는 데 사용되는 다른 제어 데이터의 자격 리스트들도 포함할 수 있다. 관리 정보 필드를 이용하여, 라이선싱 엔티티는 생태계에 대한 광범위한 거친 또는 미세한 입자 제어 메커니즘들을 생성할 수 있다.

예: CAS/DRM 제공자를 갖는 케이블 시스템에서의 행위자 함수 전파

우리는 이제 구체적인 방식으로 전파하는 행위자들 및 함수들을 갖는 위의 개념들을 설명하며, 본 예는 예로서 케이블 셋톱 박스 및 그의 소프트웨어를 이용한다. 본 예에서, 아래의 참여자들의 리스트는 케이블 운영자의 판매자 생태계 내에 포함된다: (1) "라이선싱 엔티티"와 등가인 라이선스 엔티티(LICENT). LICENT는 강건성 규칙들, 준수 규칙들, 벌칙 조항들 및 법적 책임을 포함하는 라이선싱 체제(LICREG)를 전체 생태계에 부과한다. LICREG는 행위자들이 적절한 경우에 핸드쉐이크 청구자들 또는 확인자들로서 작용하기 위한 권리를 포함한다. LICENT는 LICREG를 상이한 당사자들로 전파하는 데 사용할 훅 IP "X", "Y" 및 "Z"(HIPX, HIPY 및 HIPZ)를 라이선싱할 권리를 갖는다. HIPX, HIPY 및 HIPZ는 핸드쉐이크에서 사용되는 암호 단방향 함수에 기초한다. (2) CAS 및 DRM(CASDRM)은 "알파 행위자"로도 알려진 "행위자 1"을 제공한다. (3) 케이블 미들웨어(MIDDLEWARE)는 "행위자 2" 또는 "베타 행위자"를 제공한다. (4) 가이드 판매자는 "행위자 4", 즉 "감마 행위자"를 제공한다. 셋톱 박스 브라우저(BROWSER)는 "행위자 5", 즉 "델타 행위자"를 제공한다.

본 예에서, 동작은 아래의 순서로 진행된다:

1. LICENT는 행위자 1, 즉 CASDRM으로 하여금 LICREG에 가입함으로써 알파 행위자가 되도록 설득한다. CASDRM은 HIPX를 핸드쉐이크 확인자로서 사용할 것이고, 임의의 청구자 역할을 위해 어떠한 역할 또는 훅 IP도 갖지 않는다. CASDRM이 이제 라이선시라는 사실은 핸드쉐이크를 사용하고 HIPX를 사용하고 LICREG를 요구하는 CASDRM API의 확인자로서의 훈련 없이는 어느 누구도 생태계 내의 CASDRM 함수들에 대한 액세스를 획득하지 못한다는 사실과 함께 공개 지식이 된다.

2. 이어서, LICENT는 LICREG를 누군가에게 제공한다.

3. 미들웨어 및 가이드 양자는 그들 양자가 CASDRM의 함수들에 액세스하는 것이 필요하다는 것을 알게 된다. 미들웨어 및 가이드 양자는 LICREG에 가입하여 그러한 CASDRM 액세스를 획득한다. 미들웨어 및 가이드의 새로운 LICREG는 그들에게 청구자로서의 CASDRM 액세스에 대한 HIPX의 사용을 허가하며, 그들이 미들웨어 또는 가이드의 함수들에 액세스하려고 하는 임의의 당사자에 대한 확인자로서 HIPY를 사용하기 위한 의무도 포함한다. 미들웨어 및 가이드 양자가 라이선시들이라는 사실은 핸드쉐이크를 사용하고 HIPY를 사용하고 LICREG를 요구하는 미들웨어 또는 가이드 API들의 청구자들로서의 훈련 없이는 어느 누구도 생태계 내의 미들웨어 또는 가이드 함수들에 대한 액세스를 획득하지 못한다는 사실과 함께 공개 지식이 된다. 미들웨어 및 가이드 양자는 청구자들로서 CASDRM에 액세스할 때 HIPX를 사용할 것이며, 임의의 다른 당사자가 그들의 함수들에 액세스하려고 시도할 때 확인자들로서 HIPY를 사용할 것이다.

4. 가이드는 이제 그가 미들웨어는 물론, CASDRM의 함수들에 액세스하는 것이 필요하다는 것을 알게 된다. 가이드는 추가적인 LICREG 조건들에 가입하여 미들웨어에 대한 그러한 추가적인 액세스를 획득하며, 그러한 허가는 가이드가 HIPY를 핸드쉐이크 청구자로서 사용하여 미들웨어에 액세스하는 것을 가능하게 한다. 가이드의 LICREG는 그가 가이드 데이터를 가이드의 프로그램 가이드 애플리케이션으로 소싱하기 위한 임의의 당사자 가이드 사용들을 위해 HIPY를 확인자로서 사용하기 위한 추가 의무들을 포함한다. HIPY에 가입하는 가이드는 가이드를 제공하는 프로그램 가이드 데이터 제공자를 생태계 내로 끌어들일 것인데, 이는 가이드가 청구자로서의 HIPY에 대해서도 라이선싱된 제공자만을 선택할 수 있기 때문이다. 가이드 데이터 제공자의 선택은 LICREG에 종속하는데, 이는 가이드가 LICREG에 종속하기 때문이다.

5. 브라우저는 그가 미들웨어의 함수들에 액세스하는 것이 필요하다는 것을 알게 된다. 브라우저는 LICREG에 가입하여 HIPY 청구자로서 그러한 액세스를 획득한다. 브라우저의 LICREG는 그가 브라우저가 액세스하는 임의의 웹사이트에 대해 HIPZ를 사용하기 위한 추가 의무들을 포함한다. 이것은 브라우저로부터 액세스 가능한 모든 웹사이트 소스들을 생태계 내로 끌어들일 것이다. 웹사이트 소스들은 LICREG에 종속하지 않을 수 있다. 그러한 웹사이트 소스들의 선택은 LICREG에 종속하는데, 그 이유는 브라우저가 LICREG에 종속하기 때문이다.

순수한 결과는 LICENT가 생태계를 매우 광범위하게 제어한다는 것이다. 이러한 제어는 생태계 행위자 CASDRM, 미들웨어, 가이드 및 브라우저를 포함할 뿐만 아니라, 더 적은 범위로는 가이드 데이터의 제공자 및 심지어는 브라우저를 통해 액세스 가능한 웹사이트들도 포함한다.

그러한 제어 정도는 양호한 장기 전략을 위해서는 바람직하지 않을 수 있다. 예를 들어, 제어되는 생태계의 더 명목적인 버전은 브라우저, 웹사이트들 및 가이드 데이터 제공자에 대한 임의의 제어들을 생략할 수 있다. 이러한 공격적인 예는 본 명세서에서의 기술들을 이용하여 생태계에 대해 얼마나 포괄적인 제어들이 설정될 수 있는지를 나타내며, 이는 행위자 CASDRM, 미들웨어, 가이드, 브라우저, 가이드에 대한 가이드 데이터의 제공자 및 브라우저를 통해 액세스 가능한 웹사이트들에 대해 설명된 계약 의무들을 부과할 것이다.

도 8은 이러한 예시적인 제어되는 생태계의 도면을 제공한다. 도 8에 도시된 바와 같이, 가이드 데이터 제공자(810) 및 웹사이트들(812)은 CASDRM(802), 미들웨어(804), 가이드(806) 또는 브라우저(808)와 같이 그렇게 완전히 생태계의 계약 의무들 내로 끌어 들여지지 않는다. 그들은 브라우저(808) 및 가이드(806)가 그들과 함께 어떻게 동작할지에 관하여 라이선싱 체제(800) 의무들을 갖지만, 그들은 생태계를 임의의 다른 당사자들로 더 전파하기 위한 의무들을 갖지 않을 것이다.

도 8에 더 도시된 바와 같이, 상이한 행위자들은 LICREG로부터 상이한 권리들을 필요로 한다. CASDRM은 HIPX 확인자 라이선시 전용이다. 미들웨어는 청구자로서 HIPX에 대해 그리고 확인자로서 HIPY에 대해 LICREG 라이선스들을 갖는다. 가이드는 청구자로서 HIPX에 대해 그리고 확인자 및 청구자 양자로서 HIPY에 대해 LICREG 라이선스들을 갖는다. 브라우저는 청구자로서 HIPY에 대해 그리고 확인자로서 HIPZ에 대해 LICREG 라이선스들을 갖는다. 가이드 데이터 제공자는 청구자로서 HIPY에 대해 LICREG 라이선스를 갖는다. 브라우저에 의해 액세스되는 웹사이트들은 그러한 옵션이 선택되는 경우에만 HIPZ에 대한 LICREG 라이선스를 갖는다.

본 시스템, 방법 및 기기가 위에서 구체적으로 설명되었지만, 이것은 통상의 기술자에게 시스템, 방법 및/또는 기기를 어떻게 실시하고 이용할지를 교시하기 위한 것일 뿐이다. 많은 추가적인 변경들은 아래의 청구항들에 의해 정의된 바와 같은 시스템, 방법 및/또는 기기의 범위 내에 속할 것이다.

Claims

삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
복수의 행위자(Actor) 사이의 데이터의 보안 전송을 위한 핸드쉐이크를 제공하기 위한 방법으로서,
각각의 행위자는 프로세서 및 상기 프로세서로 하여금 상기 방법의 단계들을 수행하는 것을 가능하게 하는 코드를 저장하기 위한 메모리를 포함하고,
상기 방법은,
핸드쉐이킹에 대한 챌린지를 제1 행위자로부터 제2 행위자로 제공하는 단계;
상기 제1 행위자에서 제2 행위자로부터 상기 챌린지에 대한 응답을 수신하는 단계 - 상기 응답은 상기 챌린지에 대한 함수 IPF1으로서 계산되고, 상기 함수 IPF1은 상기 제1 행위자에 의해 제어되고 상기 제2 행위자가 권리를 획득한 훅 IP1으로서 지칭되는 지적 재산(IP) 권리들을 라이선싱하기 위한 제1 라이선스 합의에 대한 액세스로부터 수신되는 데이터에 기초하여 계산됨 -;
상기 제1 행위자를 이용하여 상기 응답을 확인하는 단계; 및
상기 제2 행위자의 상기 지적 재산의 사용을 허가하는 확인 신호를 상기 제1 행위자로부터 반환하는 단계
를 포함하는 방법.
제13항에 있어서,
제2 행위자로부터 제3 행위자로 챌린지를 제공하는 단계;
상기 제2 행위자에서 상기 챌린지에 대한 응답을 제3 행위자로부터 수신하는 단계 - 상기 응답은 상기 챌린지에 대한 함수 IPF2로서 계산되고, 상기 함수 IPF2는 상기 제2 행위자에 의해 제어되고 상기 제3 행위자가 권리를 획득한 훅 IP2로서 지칭되는 지적 재산(IP) 권리들을 라이선싱하기 위한 제2 라이선스 합의에 대한 액세스로부터 수신되는 데이터에 기초하여 계산됨 -;
상기 제2 행위자를 이용하여 상기 응답을 확인하는 단계; 및
상기 제3 행위자의 상기 지적 재산의 사용을 허가하는 확인 신호를 상기 제2 행위자로부터 반환하는 단계
를 더 포함하는 방법.
제14항에 있어서,
제1 행위자로부터 제3 행위자로 챌린지를 제공하는 단계;
상기 제1 행위자에서 상기 챌린지에 대한 응답을 제3 행위자로부터 수신하는 단계 - 상기 응답은 상기 챌린지에 대한 함수 IPF1으로서 계산되고, 상기 함수 IPF1은 상기 제1 행위자에 의해 제어되고 상기 제3 행위자가 권리를 획득한 훅 IP1으로서 지칭되는 지적 재산(IP) 권리들을 라이선싱하기 위한 제2 라이선스 합의에 대한 액세스로부터 수신되는 데이터에 기초하여 계산됨 -;
상기 제1 행위자를 이용하여 상기 응답을 확인하는 단계; 및
상기 제3 행위자의 상기 지적 재산의 사용을 허가하는 확인 신호를 상기 제1 행위자로부터 반환하는 단계
를 더 포함하는 방법.
제13항에 있어서,
제2 행위자로부터 제3 행위자로 챌린지를 제공하는 단계;
상기 제2 행위자에서 상기 챌린지에 대한 응답을 제3 행위자로부터 수신하는 단계 - 상기 응답은 상기 챌린지에 대한 함수 IPF1으로서 계산되고, 상기 함수 IPF1은 상기 제1 행위자에 의해 제어되고 상기 제3 행위자가 권리를 획득한 상기 제1 라이선스 합의 훅 IP1으로부터 수신되는 데이터에 기초하여 계산됨 -;
상기 제2 행위자를 이용하여 상기 응답을 확인하는 단계; 및
상기 제3 행위자의 상기 지적 재산의 사용을 허가하는 확인 신호를 상기 제2 행위자로부터 반환하는 단계
를 더 포함하는 방법.
제13항에 있어서,
상기 제1 라이선스 합의에 의해 제어되는 상기 지적 재산 권리들은 적어도 하나의 특허를 포함하는 방법.
제13항에 있어서,
상기 제1 라이선스 합의에 의해 제어되는 상기 지적 재산 권리들은 제1 특허 및 상기 제1 특허의 만료 일자를 적어도 10년 초과하는 만료 기간을 갖는 제2 특허를 포함하는 방법.
제15항에 있어서,
상기 훅 IP1은 상기 함수 IPF2가 함수 IPF1과 동일한 라이선스 합의에 의해 제어되는 것을 요구하는 방법.
제13항에 있어서,
상기 행위자들은 CAS(Conditional Access System), 미들웨어, 브라우저, 가이드, 가이드 데이터 제공자 웹사이트들(Guide Data Provider Web Sites) 및 셋톱 박스 중 하나 이상을 포함할 수 있는 방법.