KR20200000448A - 소프트웨어 활성화 및 라이센스 추적을 위한 시스템 및 방법 - Google Patents

Abstract

최종 사용자 컴퓨팅 장치(컴퓨터)에서 소프트웨어 활성화 및 상태 추적을 위한 시스템 및 방법은 소프트웨어 개발자에게 소프트웨어 배포 및 소프트웨어 활성화 사용 통계를 수집할 수 있는 유연하고 안전한 도구를 제공하기 위해 개발되었다. 이 방법은 다음과 같은 논리적 단계로 구성된다: (a) 획득 확정을 취득한다; (b) 라이센스를 요청한다; (c) 라이센스를 발급하고 최종 사용자에게 제공하되, 라이센스는 서버에 의해 개인 키로 보호되며 개인 키는 클라이언트에 저장되지 않는다; (d) 사용자 컴퓨터에 라이센스를 검증한다; (e) 사용자 컴퓨터에 라이센스를 저장한다; (f) 활성화 상태를 주기적으로 추적한다; (g) 사용자의 라이센스에 대한 다른 조치를 한다. 라이센스를 검증하는 것은 애플리케이션과 연관된 클라이언트에서 수정 없이 서버로부터 받은 라이센스를 확인하고 라이센스를 클라이언트에 저장하는 것을 포함한다.

Description

소프트웨어 활성화 및 라이센스 추적을 위한 시스템 및 방법

본 발명의 분야는 소프트웨어 활성화 시스템 및 방법에 관련된 것이다.

현재 다양한 관련 기술의 소프트웨어 활성화 방법이 존재한다. 대부분의 관련 소프트웨어 활성화 방법에는 인터넷 연결이 필요하다. 그러나 소프트웨어 활성화에 인터넷 연결을 사용하면 다양한 문제와 단점이 발생할 수 있다. 예를 들어, 제한되지는 않지만, 무단 (예 : 불법) 소프트웨어 사용 문제가 있다. 소프트웨어 활성화 방법이 종래 기술보다 더 정교해지지 않는 한, 보안 및 불법 소프트웨어 사용 방지의 종래 기술 문제는 소프트웨어 활성화 분야에 남아있을 것이다.

일부 관련 기술 접근법은, 잘못된 파라미터 정보를 포함하는 가짜 라이센스 파일을 생성하고, 라이센스의 검증을 수행하고, 그리고 라이센스 검증이 완료되면 잘못된 파라미터 정보를 올바른 파라미터 정보로 대체하는, 애플리케이션과 연관된 클라이언트를 포함하는 라이센스에 대한 검증 기술을 사용할 수 있다. 그러나 이 방법에는 여러 가지 문제점과 단점이 있을 수 있다. 예를 들어 제한되지는 않지만 가짜 라이센스 접근 방식은 라이센스 파일의 콘텐츠가 서버 측이 아닌 클라이언트의 머신에서 작성되는 것으로 가정한다. 따라서 키생성 앱(keygen app)이, 공급 업체 앱을 파괴할 필요없이, 공급 업체 앱과 동일한 방식으로 이러한 파일을 생성할 수 있다.

본 발명은 다음의 양태들에 관한 것이다: 최종 사용자를 위한 활성화 프로세스를 단순화한다; 활성화 프로세스의 각 단계에서 활성화 방법을 안전하게(secure) 하여 무단 (예 : 불법) 소프트웨어 사용을 방지한다; 새 컴퓨터에서 소프트웨어 재 활성화, 실수로 활성화 번호 손실 등의 예기치 않은 문제와 관련된 고객 지원 문의 횟수를 줄이기 위해 향후 활성화 상태를 추적한다.

활성화 프로세스의 제 1 단계는 애플리케이션을 획득하는 것이다. 애플리케이션의 획득은 구매, 경품 또는 공급 업체가 정의한 기타 방법을 통해 이루어질 수 있다. 사용자는 애플리케이션 획득 확정을 받아야 한다. 애플리케이션의 획득에 대한 이 확정은, 여기에 제한되는 것은 아니며, 다음과 같은 형태로 존재할 수 있다: (a) 활성화 키-예를 들어 소프트웨어 개발자가 제공 한 고유한 심볼 조합; 또는 (b) 특정 사용자에게 연결된 활성화 시스템의 데이터베이스에 있는 레코드.

이러한 애플리케이션의 획득은 다양한 방식으로 수행될 수 있다. 예를 들어 (이에 국한되지는 않음) 소프트웨어는 온라인 상점에서 소프트웨어를 구매할 수 있으며, OEM 공급 세트와 관련된 소프트웨어를 포함하여 CD, DVD 또는 USB 드라이브를 포함하지만 이에 국한되지 않는 물리적 매체로 전달이 발생할 수 있다. 이러한 각 애플리케이션의 획득 모드에는 획득 확정의 적합성 설정과 관련된 고유한 메커니즘이 있으며 또한 라이센스 발급 규칙도 있다.

획득 확정은 활성화 번호를 포함할 수 있다. 한쪽으로부터, 획득 확정은 인간 판독 가능할 수 있으며, 이는 가능한 정오표의 수를 감소시킬 수 있다. 다른 한편으로, 획득 확정은 무차별 검색을 방지하기에 충분히 길다. 또한, URL 별 활성화 체계가 개발되어 개발자가 사용자에게 이메일에서 또는 웹상의 버튼에 대한 선택 또는 클릭 동작을 포함하여 (여기에 한정되는 것은 아님) 사용자 동작으로 소프트웨어를 활성화할 수있는 옵션을 제공 할 수 있다.

특정 사용자와 관련된 활성화 시스템의 데이터베이스의 레코드는 하나 이상의 방식으로 개시될 수 있다. 예를 들어, 제한적이지 않지만, 활성화 시스템의 데이터베이스에 있는 레코드는 (a) 온라인 또는 오프라인 상점에서 소프트웨어를 구매한 후에 개시될 수 있다; 또는 (b) 활성화 시스템 관리자에 의해 수동으로 개시될 수 있다. 사용자는 소프트웨어 라이센스를 얻기 위해 식별 정보를 제공해야 한다. 식별 정보는, (a) 고유한 로그인 식별자 및 비밀번호 쌍; (b) 활성화 서버에 의해 제공된 보안 키로 보호되는 활성화 서버에 대한 보안 연결; 또는 (c) 사용자의 명확한 식별을 허용하는, 활성화 시스템의 관리자에 의해 정의된 방법을 포함할 수 있다.

활성화 시스템의 데이터베이스에서 레코드를 개시한 후 다음 단계는 라이센스 요청을 생성하는 것이다. 이 단계는 인터넷 연결이 필요하다. 본 예시적인 구현에 따르면, 프로토콜이 제공된다. 또한, 활성화 서버에서 데이터가 처리되는 방식에 대한 메커니즘도 제공된다. 사용자 컴퓨터로부터의 요청에는 다음 중 하나 이상을 포함하되 이에 국한되지 않는 다음 데이터가 포함될 수 있다: (a) 애플리케이션 번들 ID (예 : 특정 형식의 제품 이름); (b) 번들 버전 (예 : 제품 버전); (c) 현재 활성화를 위해 유지되는 추가 데이터 세트; (d) 사용자의 계정 식별자 (예 : 이메일 주소) (e) 고유한 컴퓨터 식별자에 대한 두 값; (f) 획득 확정; (g) 사용자의 이름과 성; (h) 보안을 강화하기 위한 무작위 데이터 블록; (i) 서버 측에서 데이터를 열기위한 비밀번호; 및 (j) 오류 메시지의 언어.

라이센스 요청이 생성되면, 세 번째 단계는 라이센스를 발급하여 사용자에게 전달하며, 라이센스는 서버에 의해 개인 키로 보호되며 개인 키는 클라이언트에 저장되지 않는다. 라이센스 요청을 받은 후 활성화 요청이 올바른 경우 서버가 라이센스를 발급하거나 그렇지 않으면 오류 메시지를 보낸다. 서버 응답에는 다음 정보가 포함된다: (a) 오류 코드 (예 : 성공한 경우 0); (b) 오류 메시지 또는 암호화된 라이센스; (c) 소프트웨어의 개인 키를 사용하여 생성된 라이센스 파일의 서명 또는 오류 메시지.

소프트웨어 라이센스가 최종 사용자의 컴퓨터로 전달된 후 소프트웨어 라이센스는 애플리케이션과 관련된 클라이언트에서 서버로부터 수정 없이 받은 라이센스를 확인하고 클라이언트에 라이센스를 저장하는 것에 의한 확인을 통과해야 한다. 라이센스 파일은 사용자 컴퓨터 파일 시스템의 특정 위치에 기입된다. 라이센스 유효성은 애플리케이션의 첫 번째 출시 후, 앱 설치 중, 앱의 평가판 기간이 끝난 후 첫 번째 출시 중에 또는 다른 적절한 상황에서 통상의 기술자에게 이해되는 바와 같이 검사된다. 라이센스 출처 검증 (예 : 공개 키에 의한 확인) 및 완전성의 확정이 완료된 후에도 사용자는 소프트웨어 작업을 계속할 수 있다.

활성화 상태는 주기적으로 활성화 서버로 전송된다. 보고 규칙은 개발자가 정의할 수 있다. 활성화 상태는 개발자가 정의한 다양한 조건 (예 : 재 활성화가 허용되는 경우 소프트웨어 재 활성화)에 따라 트리거될 수 있다.

예시적인 구현은 또한 원격으로 (예를 들어, 활성화 서버 측으로부터) 그리고 직접적으로 (예를 들어, 사용자에 의해 시작된) 라이센스를 비활성화 가능성에 관한 것이다.

도 1은 예시적인 구현에 따른 클라이언트 및 서버를 포함하는 프로토콜의 예시적인 프로세스를 도시한다.
도 2는 예시적인 구현에 따른 제 1 프로토콜에 대한 예를 도시한다.
도 3은 예시적인 구현에 따른 제 2 프로토콜에 대한 예를 도시한다.
도 4는 예시적인 구현에 따른 서버를 포함하는 프로토콜의 예시적인 프로세스를 도시한다.
도 5는 예시적인 구현에 따른 클라이언트를 포함하는 프로토콜의 예시적인 프로세스를 도시한다.
도 6은 일부 예시적인 구현에 적합한 예시적인 환경을 도시한다.
도 7은 일부 예시적인 구현에 사용하기 위해 외부 호스트와 연관된 예시적인 컴퓨팅 장치를 갖는 예시적인 컴퓨팅 환경을 도시한다.

본 명세서에 기술된 주제는 예시적인 구현에 의해 교시된다. 명확성을 위해 그리고 주제를 모호하게 하는 것을 피하기 위해 다양한 세부 사항이 생략되었다. 아래에 나타난 예들은 소프트웨어 활성화 및 라이센스 추적을 위한 구조 및 기능에 관한 것이다.

본 명세서에서 사용된 용어는 통상의 기술자에게 통상의 일반적인 의미를 갖는 것으로 이해된다. 용어는 예로서 정의될 수 있지만, 제공된 정의로 제한되지는 않는다. 예를 들어 (이에 국한되지는 않음) "사용자"(user) 또는 "최종 사용자"(end user)는 인가된(authorized) 방식으로 (예를 들어, 법적으로) 소프트웨어의 사본을 획득하고 컴퓨팅 장치에서 소프트웨어를 올바르게 작동하는, 개인과 같은 엔티티(entity)를 포함할 수 있다. 또한 "개발자" 또는 "공급 업체"(vendor)는 논리적으로 완성된 컴퓨터 프로그램과 같은 하나 이상의 소프트웨어 사본을 배포하는 개인 또는 법인(legal entity)과 같은 엔티티 일 수 있다. 또한, "소프트웨어 설치"는, 개발자가 의도 한 방식으로 컴퓨터 프로그램을 작동시키는 방식으로, 사용자와 연관된 사용자 컴퓨팅 장치 상에 배치된 컴퓨터 프로그램의 사본이다.

또한, "활성화"(activation)에는 소프트웨어 설치의 적법성을 확정하고(예 : 소프트웨어 설치가 인가되었는지 여부) 개발자가 설계한 어떠한 기능적 제한(있는 경우)을 제거하는 절차 또는 절차 세트를 포함할 수 있다. "평가판"(trial)은 사용자가 소프트웨어에 익숙해 지도록 제한된 기능을 갖춘 소프트웨어 설치 사용 유형을 포함할 수 있다. 또한, "획득 확정"(acquisition confirmation)은 사용자가 소프트웨어를 합법적으로 사용할 수 있는 권한 (예 : 인가)을 확정하는 디지털 엔티티이며, 획득 프로세스(예 : 구매, 경품 등) 후에 사용자에게 제공되어야한다.

또한, "활성화 번호"(activation number) 또는 "활성화 키"(activation key)는 획득 확정의 유형으로 사용되는 사람이 읽을 수 있는 조합 (예를 들어, 영숫자 기호) 일 수 있다. 또한, "라이센스"는 소프트웨어 설치가 특정 컴퓨터 장치에서 사용될 수 있는지를 식별하는데 사용되는 데이터를 포함하는 컴퓨터 파일을 포함할 수 있다. "라이센스 유형"에는 라이센스 생성 규칙 세트가 포함될 수 있으며, 이 규칙은 소프트웨어 사용 조건을 다르게 하기 위해 개발자에 의해 설정된다. 이러한 규칙에는, 여기에 제한되는 것은 아니며, 소프트웨어 사용 기간(예 : 1년, 6개월, 수명), 여러 가지 재 활성화, 제공될 특정 기능 등이 포함될 수 있다.

또한, "활성화 서버"(Activation Server) 또는 "서버"는 사용자의 컴퓨팅 장치에 대한 원격 컴퓨팅 장치이며 소프트웨어 설치 활성화를 위해 필요한 동작을 수행한다. 예시적인 구현에 따르면, 서버는 통상의 기술자에게 알려진 하드웨어를 포함할 수 있다. 또한 "번들 ID"(bundle ID)는 최종 사용자 컴퓨터의 운영 체제에서 읽을 수 있는 특수 형식의 애플리케이션 식별자(application identifier)이다.

예시적인 구현의 양태들은 최종 사용자를 위한 활성화 프로세스를 단순화하고; 활성화 프로세스의 각 단계에서 무단 (예 : 불법) 소프트웨어 사용을 방지하기 위해 활성화 방법을 안전하게(secure) 하고; 새로운 컴퓨터에서의 소프트웨어의 재-활성화, 실수로 활성화 번호 손실 등의 예기치 않은 문제와 관련된 고객 지원 문의 횟수를 줄이기 위해 향후 활성화 상태를 추적하는 것에 관련된다.

전술한 종래 기술의 보안 격차를 극복하기 위해, 예시적인 구현은 디지털 서명의 비대칭 방식에 관한 것이다. 보다 구체적으로, 예시적인 구현은 각 공급 업체 애플리케이션마다 고유한 키 쌍을 사용한다; 모든 공급 업체 앱에 통합된 공개 키와 서버 쪽에 안전하게 저장된 개인 키. 서버에 위치한 개인 키를 보호하기 위해, 예시적인 구현은 내부 서버에만 이용 가능한 격리된 스토리지 시스템(storage system)을 포함하지만 이에 제한되지 않는 다양한 기술 및 방법을 사용할 수 있으며, 여기서 서버는 인터넷에 연결되지 않으며, 암호화된 연결을 설정하기 위해 SSL을 사용하고 클라우드의 가상 격리 섹션의 권한 설정(provision)을 위한 AWS 가상 개인 클라우드(Virtual Private Cloud) 서비스를 사용한다.

불법 액세스로부터 보호하기 위한 네트워크 방화벽 사용

서버가 해당 요청을 수신하면, 서버는 라이센스 파일의 콘텐츠를 생성하고 고유하고 안전한 개인 키로 라이센스 파일에 서명한다. 따라서 서버는 디지털 서명을 만든다. 고유한 안전한 개인 키가 있는 서명된 라이센스 파일은 각 공급 업체 앱에 따라 다르다.

공급 업체 앱은 디지털 서명이 있는 라이센스 파일을 수신하여 이를 사용자의 머신 (클라이언트)에 저장한다. 악의적인 행위자 (예 : 해커)가 악의적인 행위를 시도할 경우 (예 : 라이센스 파일을 변경하려고 시도하거나 가짜 라이센스를 생성하려고 시도하는 경우), 이 라이센스 파일의 서명 확인(signature validation)이 공급 업체 앱 상에서 실패한다. 따라서 라이센스 파일의 콘텐츠가 유효하지 않게 되고 공급 업체 앱은 악의적인 시도 (예 : 공급 업체 앱을 크랙하려는 시도)를 견뎌낸다.

이들 및 다른 양태들을 달성하기 위해, 다양한 단계들이, 여기에 한정되는 것은 아니며, 도 1에 도시된 바와 같은 활성화 프로세스(100)에서 수행될 수 있다. 101에서, 사용자는 애플리케이션을 획득한다. 또한, 103에서, 사용자는 다양한 모드 중 하나에 의해 애플리케이션의 획득에 대한 확정을 수신한다. 애플리케이션의 각 획득 모드에는 라이센스 발급 규칙 세트 및 획득 확정의 준수(conformity)의 설정과 관련된 고유한 메커니즘이 있다. 획득 확정은 활성화 번호를 포함할 수 있고 사람이 읽을 수 있지만, 활성화 확정을 결정하기 위해 권한이 없는 당사자에 의한 무차별 검색을 방지하기에 충분히 길다. 또한, 예시적인 구현에 따른 URL 별 활성화 방식은 개발자가 사용자에게 사용자 동작으로 소프트웨어를 활성화하는 옵션을 제공하게 할 수 있다.

특정 사용자와 연관된 활성화 시스템의 데이터베이스의 레코드(record)는 105에서 시작될 수 있다. 사용자는 107에서 소프트웨어 라이센스를 얻기 위해 식별 정보를 제공해야 한다. 활성화 시스템의 데이터베이스에서 레코드가 시작된 후, 109에서 프로토콜에 의해 라이센스 요청이 생성된다. 프로토콜에 따라, 라이센스는 서버에서 생성되고 보안 개인 키로 서명된다. 라이센스 요청이 109에서 생성되면, 라이센스는 111에서 사용자에게 제공되고, 사용자는 113에서 디지털 서명으로 라이센스를 수신하고 라이센스 파일을 사용자 장치에 저장한다.

상술한 바와 같이 라이센스 요청이 수신된 후, 서버는 115에서 활성화가 올바른지 여부를 결정하고, 활성화 요청이 올바른 경우 119에서 라이센스를 발급하거나, 그렇지 않으면 117에서 오류 메시지를 전송한다. 소프트웨어 라이센스가 최종 사용자의 컴퓨터로 전달된 후, 119에서 확인(validation)을 통과해야 한다. 라이센스 파일은 사용자 컴퓨터 파일 시스템의 특정 위치에 기입된다. 애플리케이션이 실행되면 라이센스 유효성(validity)은, 서버에서 받은 라이센스를 수정함 없이, 121에서 검사된다; 서명된 라이센스 파일을 변경하거나 가짜 라이센스를 생성하려고 시도하면 이러한 시도는 공급 업체 측에서 실패하고 라이센스 파일의 콘텐츠가 유효하지 않게 되고, 그 결과 공급 업체 앱은 크랙되지 않는다. 라이센스 출처의 검증(verification) 및 완전성(completeness)을 확정(confirmation)한 후, 소프트웨어 설치가 완료되고 소프트웨어는 123에서 사용할 준비가 된다. 활성화 상태는 정기적으로 활성화 서버로 전송된다. 또한, 라이센스는 원격으로 또는 직접 비활성화 될 수 있다.

다양한 동작들에 대한 추가 세부 사항들이 아래에서 더 상세히 설명된다.

획득 확정의 취득(Obtaining an Acquisition Confirmation)

인가된 방식으로 (예 : 법적으로) 소프트웨어를 사용하려면 사용자는 획득 확정을 받아야 한다. 이러한 획득 확정은 여기에 한정되는 것은 아니며 다음을 포함하는 다양한 형태로 존재할 수 있다: (a) 활성화 키 (예를 들어, 소프트웨어 개발자에 의해 제공되는 심볼들의 고유한 조합); 또는 (b) 특정 사용자와 연결된 활성화 시스템 데이터베이스의 레코드. 획득을 완료한 후에는 사용자에게 획득 확정을 소프트웨어 라이센스로 교환하는 방법에 대한 지침이 제공되어야한다.

상술한 바와 같이, 사용자는 획득 확정 (예 : 활성화 번호)을 취득해야 한다. 소프트웨어 공급 업체는 하나 이상의 다른 활성화 번호 배포 옵션을 가질 수 있다:

직접 판매 (예 : 공급 업체 웹 사이트상에서의 온라인 판매 또는 공급 업체 소매점을 통한 직접 판매);

제3자 재판매자 또는 파트너를 통한 판매;

물리적 매체 (예 : CD, USB 스틱 또는 SD 카드) 상의 박스 버전 또는 온라인을 통한 배포

전술한 배포 방법은 획득 확정을 취득하는 상이한 방식 및 순서를 요구할 수 있다. 경우에 따라, 지불이 접수되자마자, 요구에 따라 획득 확정이 제공될 수 있다; 다른 경우에는 일부 물리적 매체에 전달할 대량의 사전 생성된 활성화 번호를 제공해야 할 수도 있다. 각 경우에, 공급 업체는 (예컨대, 마케팅 및 분석 목적을 위해) 활성화 번호가 생성되었던 조건(예를 들어 파트너, 마케팅 캠페인, 데이터, 카운트 및 다른 조건)과 연관된 추가 정보를 알아야 한다.

예시적인 구현은 획득 확정 생성의 적어도 3가지 기본 메커니즘을 포함한다:

URL에 의한 생성 - 획득 확정에 대한 각 요청이 활성화 서버와 연결된 특정 URL로 재지정(redirection)될 것이다. 완전하고 올바르게 구성된 요청의 경우 서버는 획득 확정으로 응답한다.

'대량'(bulk) 생성 - 서버는 소프트웨어 배포자에게 '그대로'(as is) 제공되거나 사용자를 통해 확산되는 유한 수량의 활성화 번호를 생성한다.

단일 생성 - 획득 확정을 생성하는 이 방법은 하나의 획득 확정을 생성해야 할 때와 같이 테스트 및 지원 목적으로 주로 사용된다.

획득 확정은 암호화 없이 서버에 의해 '그대로' 전송될 수 있다.

URL에 의한 생성(Generation by URL)

이 방법은 하나 이상의 획득 확정에 대한 요청을 포함한다. 이 방법은 온라인에서 직접 구매할 때 가장 많이 사용되지만 애플리케이션을 취득하는 다른 모드에서 사용할 수 있다. 도 2는 URL에 의한 생성에 기초하여 활성화 코드를 요청하는 프로세스의 예시적인 구현(200)을 도시한다. 도 2에서, 사용자 워크 스테이션(201), 지불 시스템(203) 및 활성화 서버(205)가 개시되어있다. 그러나 통상의 기술자라면 이해할 수 있는 바와 같이, 본 발명의 범위를 벗어나지 않은 채 다른 구현들로 대체 될 수 있다.

1. 사용자가 구매 페이지(예 : 개발자 웹 사이트 또는 타사 웹 리소스 또는 제품 구매 방식)를 방문한다. (207)

2. 사용자는 이름/성, 이메일 주소, 전화번호, 제품 수량, 소프트웨어 사용 기간 등과 같은 필수 정보를 제공한다. (207)

3. 구매가 성공하면, 청구 시스템은 특정 API에 의해 수집된 정보를 소프트웨어 공급 업체의 서버로 전송한다; 주문 정보는 활성화 서버에 저장되고 활성화 키가 생성된다 (209, 211a, 211b).

4. 사용자는 활성화 서버로부터 활성화 키를 취득한다. 활성화 키는 구매 페이지에 명시된/표시된 전자 메일로 전송된다. (213, 215)

5. 어떤 이유로 지불을 완료할 수 없는 경우, 사용자는 추가 조치(청구 정보 재입력, 은행 계좌 검사, 나중에 시도 등)에 대한 지시 사항과 함께 거래를 완료할 수 없다는 정보를 받는다. (217)

대량 생성(Bulk generation)

다른 예시적인 구현에서, 파트너: 물리적 미디어 (CD, USB)의 생산자, 제휴사, 재판매자에 대한 많은 코드를 제공하기 위해 '대량' 활성화가 사용될 수 있다.

이 예시적인 구현에서, 소프트웨어 공급 업체는 필요한 마케팅 파라미터 또는 계약 조건 (예를 들어, 500개의 라이센스가 Resell LLC에 제공되어 2017년 12월 25일까지 사용)으로 소정량의 활성화 번호 (예를 들어, 미리)를 생성 할 수 있다.

이 예시적인 구현에서, 빈 주문 레코드를 갖는 데이터베이스가 생성되고, 개발자는 활성화 번호의 특정 패턴을 명시할 수 있다. 애플리케이션은 최종 사용자에게 개인 데이터 (이름 및 전자 메일 주소)를 요구한다. 따라서 주문 레코드는 소프트웨어가 활성화된 후에 채워진다.

단일 생성(Single Generation)

이 옵션은 판촉 또는 테스트 목적뿐만 아니라 고객 지원을 위해 구현될 수 있다.

이 예시적인 구현에 따르면, 소프트웨어 공급 업체는 서버에 특수 관리자 패널을 통해 활성화 코드를 생성한 다음 이 코드를 고객 또는 필요한 당사자에게 전송한다. 그러면 주문 레코드가 관리자에 의해 채워진다.

활성화 시스템 데이터베이스에 레코드 생성(Creating a Record in Activation System's Database)

소프트웨어 획득 후 활성화 시스템의 데이터베이스에 레코드를 생성하는 동작은 다음과 같다. 사용자는 활성화 시스템에서 자신을 식별해야 한다. 이것은 다음 중 하나 이상의 방법으로 수행 할 수 있다 (단, 이에 한하지 않음):

고유한 로그인 및 비밀번호 정보 쌍을 제공함으로써;

활성화 서버에 의해 제공된 보안 키 (예를 들어, 암호화 됨)로 보호되는, 활성화 서버와의 보안 연결을 설정함으로써;

사용자의 명확한 식별을 가능하게 하는 (예를 들어, 제 3 자 서비스로부터 세션 식별자를 제공하거나 활성화 시스템 관리자에 의해 정의된 다른 파라미터를 제공하는 것에 의해), 활성화 서버와의 연결을 설정하고 파라미터를 전송함으로써.

사용자가 활성화 시스템에서 자신을 식별한 후 소프트웨어 획득에 대한 정보는 활성화 시스템 데이터베이스에 레코드로 저장된다.

라이센스 발급(Issuing a License)

사용자는 획득 확정을 받은 후, 제한 없이 소프트웨어를 사용하기 위한 라이센스를 요청해야한다.

라이센스 발급 프로세스는 각 유형의 획득 확정마다 유사하다. 차이점은 사용자가 라이센스를 받기 위해 획득 확정을 제공하는 방식에 있다:

애플리케이션 내에 활성화 번호를 입력함으로써;

URL 방식에 의해 애플리케이션을 활성화함으로써;

활성화 시스템상에서 인증(authentication)함으로써 :

고유한 로그인 및 비밀번호 쌍을 제공함으로써;

이전에 제공된 보안 키로 보호되는, 활성화 서버와의 보안 연결을 설정함으로써;

사용자의 명확한 식별을 허용하는 (예를 들어, 제 3 자 서비스로부터의 세션 식별자 또는 활성화 시스템 관리자에 의해 정의된 임의의 다른 파라미터를 제공함으로써), 활성화 서버와의 연결을 설정하고 파라미터를 전송함으로써.

라이센스 요청의 프로세스(300)는 다음과 같으며, 도 3에 도시된 바와 같다. 도 3에 도시된 바와 같이, 사용자 컴퓨팅 장치(예를 들어, 워크 스테이션)(301), 애플리케이션 측 동작 공간(303) (예를 들어, 사용자 제어 장치) 및 서버 측 공간(예를 들어, 데이터베이스를 갖는 서버)(305)이 제공된다. 작업에는 다음이 포함되지만 이에 국한되지는 않는다:

1. 사용자는 전술한 방법 중 하나에 의해 획득 확정을 제공한다. (307)

2. 소프트웨어가 라이센스 요청을 생성하고 라이센스 요청을 활성화 서버로 보낸다. (308)

3. 활성화 서버는, 이 획득 확정에 활성화가 허용되는지 검사한다 (예 : 활성화 서버는 데이터베이스의 활성화 번호 레코드에서 '활성화' 파라미터를 검색할 수 있다). (309)

4. 예(Yes)인 경우 (즉, 활성화가 허용되는 경우), 활성화 서버는 식별 정보에 기초하여 라이센스를 발급하고 (311), 라이센스 파일을 포함하는 애플리케이션에 응답을 전송한다. (317)

5. 라이센스 파일은 활성화 시스템의 애플리케이션 측에서 확인(validation)을 통과한다. (319)

6. 사용자에게 활성화가 성공되었음을 알린다. (321)

7. 활성화 서버가 활성화 프로세스 동안 에러가 발생했다고 판단하면 (예를 들어, 309에서 라이센스를 발급할 수 없고, 라이센스가 313에서 이전에 발급되지 않았을 경우), 활성화 서버는 에러 코드 및 메시지를 애플리케이션에 그리고 따라서 사용자에 다시 전송한다 (315). 반면에, 활성화 서버가 309에서 라이센스를 발급할 수 없지만 313 이전에서 라이센스를 발급한 것으로 결정하면 프로세스는 위에서 설명한 대로 317에서 이전에 발급된 라이센스를 계속 전송한다.

8. 소프트웨어는 오류를 해결하기 위한 추가 조치에 대한 지침과 함께 오류 유형을 사용자에게 알려준다 (예 : 활성화 코드의 유효성 검사, 고객 지원 문의 등). (323)

서버에 대한 요청의 수를 줄이고 사용자의 입력 요구 사항을 단순화하기 위해, 본 예시적인 구현에 따라 활성화 키에 대한 패턴 인식 시스템이 구현되었다. 보다 구체적으로, 활성화 키는 특정 패턴을 사용하여 생성되며, 이 패턴은 소프트웨어 설치에 의해 인식되며 특정 동작에 대해 소프트웨어 설치를 트리거한다. 예를 들어, 여기에 한정되는 것은 아니며, 특정 접미사(suffix)가 있는 활성화 키는 사용자에게 개인 데이터를 요청하는 양식의 출현(appearance of a form)을 개시할 수 있다. 공급 업체는 고유한 패턴 및 거동과 일치하도록 특정 패턴 및 소프트웨어 설치 거동을 설정할 수 있다.

소프트웨어가 활성화 서버에 등록된 후, 활성화 서버는 라이센스 서명을 위해 개인 키와 공개 키 쌍을 발급한다. 개인 키는 서버에 저장되며 라이센스가 애플리케이션으로 전송되기 전에 각 라이센스를 서명하는 데 사용된다. 공개 키는 활성화 시스템의 애플리케이션 측 부분에 통합되어 있으며 아래에 설명되는 것 같이 나중에 라이센스 서명을 검증하는 데 사용된다.

성공적인 활성화 요청이 발생한 후, 활성화 서버에 라이센스가 생성된다. 라이센스는 파라미터들 중 하나로서 다음의 애플리케이션 식별자를 기반으로 생성된 해시를 포함한다:

애플리케이션의 번들 ID;

네트워크 인터페이스 카드의 MAC 주소; 하드 디스크 드라이브 또는 솔리드 스테이트 드라이브; 마더 보드 식별자, 또는 통상의 기술자에게 알려진 다른 식별자; 운영 체제에서 사용자를 인가하는 데 사용되는 사용자 이름일 수 있지만 이에 국한되지 않는 사용자의 컴퓨팅 장치(예 : 하드웨어)의 하나 이상의 식별자; 및

라이센스에 포함될 임의로 생성된 문자열(string) (예: 'salt').

라이센스 파일을 최종 사용자에게 보내기 전에 라이센스 파일은 대칭 암호화 알고리즘으로 암호화되고, 활성화 서버에서 소프트웨어를 등록하는 동안 발급된 개인 키를 기반으로 서버 서명으로 서명된다.

재 활성화(Reactivation)

하드웨어 변경(예를 들어, 새로운 컴퓨터로 변경) 후에 소프트웨어 사용을 계속할 필요성으로 인한 지원 문의의 수를 감소시키기 위해, 예시적인 구현에 따른 재 활성화 시스템이 구현되었다.

활성화 번호가 발급될 때, 활성화 번호는 한정된 수의 활성화를 갖는다. 예를 들어, 어떤 이유로 사용자가 자신의 컴퓨터 장치에서 소프트웨어 설치를 비활성화하고 동일한 활성화 번호를 사용하여 동일한 컴퓨터 장치에서 소프트웨어를 다시 활성화하면 이전 라이센스가 발급된다.

한편, 사용자가 컴퓨팅 장치를 변경하더라도 여전히 동일한 활성화 번호를 사용하여 소프트웨어를 활성화할 수 있는 능력이 있다. 가능한 재 활성화 수에 대한 정보는 활성화 서버에 저장된다. 활성화 서버는 지정된 시간이 지나면 자동으로 하나의 추가 재 활성화를 자동으로 추가한다 (예 : 기본적으로 6개월이지만 이에 제한되지 않음). 결과적으로, 사용자는 컴퓨팅 장치 또는 운영 체제를 변경할 경우 소프트웨어를 다시 활성화 할 수 있다.

라이센스의 확인(Validation of License)

소프트웨어 설치가 제대로 작동하려면 사용자 컴퓨터에서 라이센스가 사용 가능한지 검사(check)하고 유효성(validity)을 검증해야 한다. 검증은 다음 파라미터의 검사로 구성된다: (a) 라이센스 출처 (예 : 올바른 서버에서 라이센스를 발급했는지 여부); (b) 이 컴퓨터에 라이센스가 발급되었는지 여부(예 : 라이센스가 올바른 컴퓨터에 발급되었는지 여부); 및 (c) 라이센스가 만료된 것이 아닌지 여부.

관련 기술에서, 검증 프로세스는 해커가 코드에 침입하여 애플리케이션을 크래킹하는데 필요한 정보를 수신할 수 있는 기간이다. 이 위험을 해결하기 위해 예시적인 구현에는 몇 가지 메커니즘이 포함된다.

라이센스 검사가 필요한 시점에서(이 시점은 개발자에 의해, 예를 들어, 애플리케이션의 시작, 업그레이드 또는 특정 동작 수행을 위해 정의될 수 있지만) 라이센스 검사가 시작되지 않았다면, 활성화 시스템의 애플리케이션 측은 라이센스를 수정함 없이 서버에서 받은 라인세스를 확인하고 클라이언트 측 또는 사용자, 컴퓨터에 확인된(validated) 라이센스를 저장한다. 내부 침입의 경우 권한이 없는 당사자 (예 : 해커)가 데이터를 얻지 못한다.

보다 구체적으로, 위에서 설명된 바와 같이, 전술한 관련 기술의 보안 문제를 극복하기 위해, 예시적인 구현은 디지털 서명의 비대칭 방식에 관한 것이다. 보다 구체적으로, 예시적인 구현은 각 공급 업체 애플리케이션마다 고유한 키 쌍을 사용한다: 모든 공급 업체 앱에 통합된 공개 키와 서버 측에 안전하게 저장된 개인 키.

서버가 해당 요청을 수신하면, 서버는 라이센스 파일의 콘텐츠를 생성하고, 고유하고 안전한 개인 키로 라이센스 파일에 서명한다. 따라서 서버는 디지털 서명을 생성한다. 고유한 안전한 개인 키가 있는 서명된 라이센스 파일은 모든 공급 업체 앱에 따라 다르다.

공급업체 앱은 디지털 서명과 함께 라이센스 파일을 수신하여 이를 사용자의 머신(machine) (예를 들어, 클라이언트)에 저장한다. 악의적인 행위자 (예 : 해커)가 악의적인 행위를 시도하면 (예 : 라이센스 파일을 변경하려고 시도하거나 가짜 라이센스를 생성하려고 시도하는 경우) 이 라이센스 파일의 서명 확인 공급 업체 앱 측에서 실패한다. 따라서 라이센스 파일의 내용이 유효하지 않게 되고 공급 업체 앱은 악의적인 시도 (예 : 공급 업체 앱을 크랙하려는 시도)를 물리친다.

따라서, 해커가 라이센스 데이터를 획득하는 것을 막을 필요가 없는데, 왜냐하면 상술한 바와 같이 해커가 라이센스 데이터를 획득하는 것이 불가능하기 때문이다. 라이센스 데이터는 각 머신마다 고유하게 생성되며 (예 : 네트워크 MAC 주소 또는 일련번호와 같은 머신 특정 식별 정보를 사용하여) 서버에 저장된 개인 키로 서명된다. 따라서 다른 머신에서 라이센스 데이터를 사용하거나 액세스할 수 없다.

라이센스 검사가 요구됨에 따라, 활성화 시스템의 애플리케이션 측 부분은 라이센스가 이용 가능한지를 결정하기 위해 사전 정의된 스토리지(storage)를 검사한다.

먼저, 활성화 시스템의 애플리케이션 측 부분은 전술한 바와 같이 애플리케이션 시스템의 애플리케이션 측 부분에 통합된 공개 키를 사용하여 서버 서명을 확인한다. 공개 키를 사용하여 서버 서명이 유효하게 판단되면 활성화 시스템은 대칭 암호 해독(symmetric decryption)을 위한 키를 받는다. 라이센스의 두 번째 부분은 이 암호 해독 키를 사용하여 암호 해독된다. 성공적인 암호 해독 결과 라이센스 정보가 수신된다.

다음 단계는 특정 컴퓨터에 대한 라이센스의 유효성을 검사하는 것이다. 이 검사를 수행하기 위해 활성화 시스템의 애플리케이션 측은 다음 파라미터를 사용하여 해시 문자열을 생성한다:

애플리케이션의 번들 ID

컴퓨팅 장치의 하나 이상의 식별자

라이센스에 저장된 문자열 'salt'.

생성된 해시 문자열은 라이센스에 저장된 문자열과 일치해야 한다. 일치하지 않으면 라이센스가 해당 특정 컴퓨터 및/또는 해당 특정 애플리케이션에 유효하지 않은 것으로 판단된다.

다음 단계로서, 활성화 시스템의 애플리케이션 측 부분은 라이센스 파라미터를 현재 시스템 및 애플리케이션 상태와 비교함으로써 라이센스가 만료되지 않았음 확정(confirm)하는 검사한다. 라이센스 유형에 따라 다음 파라미터가 비교될 수 있다:

a) 현재 시스템 시간과 라이센스 만료 시간;

b) 현재 시스템 시간과 라이센스 가입 종료 시간;

c) 현재 애플리케이션 버전과 라이센스 만료 버전;

d) 현재 애플리케이션 버전과 라이센스 베타 전용 플래그.

또한, 활성화 시스템의 애플리케이션 측 부분은 라이센스 확인을 위해 주기적으로 요청을 활성화 서버에 전송할 수 있다. 요청에는 활성화 식별자 및 사용자의 워크스테이션을 식별하는 데 필요한 정보가 포함될 수 있다. 라이센스가 여전히 유효한 것으로 판명되면 서버는 동일한 라이센스로 응답한다. 그러나 라이센스가 여전히 유효하지 않은 것으로 판명되면 서버는 오류 메시지로 응답한다. 이 방법은, 서버 시스템 시간에 따라 만료 시간이 확인되므로, 사용자 워크스테이션의 시스템 시간을 사용하여 라이센스 기간을 연장함으로써 조작을 방지한다.

애플리케이션 측 부분 보안(Application-side Part Security)

활성화 시스템의 애플리케이션 측 부분은 활성화 서버에 등록된 각각의 애플리케이션에 대해 고유하게 생성된다. 보안 목적으로, 활성화 시스템의 애플리케이션 측 부분의 프로그래밍 코드의 함수(function), 방법(method) 및 변수(variable)는 난독화된다 (예를 들어, 사람이 읽을 수 없도록 만들어 진다).

난독 처리할 함수에는 특수 마커가 표시되어 있으며 컴파일하는 동안 이름은 사전 정의된 알파벳에서 임의의 것으로 대체된다 (대개 영숫자(alphanumeric): 대문자 및 소문자 그리고 숫자 포함). 각 애플리케이션에 대해 난독화된 이름은 고유하다.

보안을 향상시키는 또 다른 메커니즘은 런타임 동안 메모리에서 목적지 주소를 변경하는 함수를 사용하는 것이다. 보다 구체적으로, 프로그램 코드를 컴파일하는 동안 라이센스 검증에 사용되는 함수들이 의도적으로 잘못된 파라미터를 반환하지만, 소프트웨어가 작동 중인 동안 해당 함수들은 메모리의 주소로 재지정(redirected)되며, 이는 올바른 파라미터를 반환하는 함수들을 포함한다. 이러한 함수들은 컴파일 중에 임의로 이름이 지정되므로 리버스 엔지니어링의 경우 소프트웨어 해커가 해당 함수들이 실제로 수행하는 작업을 결정할 수 없을 것이다. 이 메커니즘은 개발자가 정의한 대로 라이센스 검사가 필요한 시점에서도 구현될 수 있다.

예시적인 구현에 따르면, 개발자에게는 동작 동안 함수의 이름이 제공되지 않으며, 이 정보를 가질 필요는 없다. 예를 들어 (제한적으로는 아님) 개발자는 소프트웨어 프로그램 (예 : 코드)을 작성한 다음 애플리케이션이 컴파일될 때 함수가 의사 난수 (예 : 난독화)로 명명되므로, 보안 조치로 함수의 이름을 기반으로 함수를 결정하는 것은 가능하지 않다.

라이센스의 원격 비활성화(Remote Disabling License)

사용자가 환불을 요청하고 환불 요청이 승인되면, 사용자는 소프트웨어를 사용할 권리를 잃게 된다. 따라서 라이센스를 원격으로 취소하는 메커니즘이 필요하다. 이 메커니즘은, 사용자가 매월 또는 매년 소프트웨어 비용을 지급해야 하는 경우, 구독 요금제 계획을 처리하는 데에도 사용된다. 예를 들어, 사용자는 적극적인 취소의 표시를 제공하지 않고 소프트웨어를 단순히 갱신하지 않기로 선택할 수 있다.

환불 또는 미결재 가입(예: 갱신)으로 인해 라이센스가 서버에서 유효하지 않은 것으로 표시되면 라이센스도 활성화 시스템의 애플리케이션 부분에 표시되며, 사용자는 결제가 확정될 때까지 애플리케이션을 사용할 수 없다.

애플리케이션 측에서 라이센스 비활성화(Disabling License on the Application Side)

또한, 개발자는 애플리케이션 내에서 라이센스를 비활성화하는 기능을 추가할 수 있다. 사용자가 라이센스 비활성화를 시작한 후 활성화 시스템의 애플리케이션 측이 서버 측에 요청을 보낸다. 따라서 서버는 해당 특정 워크 스테이션에 대한 라이센스로 응답하며 이는 비활성화 된 것으로 표시된다. 이 절차는 사용자가 다른 워크스테이션에서 소프트웨어를 사용하려는 경우에 유용하다. 사용자는 첫 번째 워크스테이션에서 라이센스 비활성화를 시작하고 두 번째(예: 다른) 워크스테이션에서 애플리케이션을 활성화하는 데 필요한 단계를 반복 할 수 있다.

앱 스토어 영수증을 라이센스로 사용(Using App Store Recipt as License)

공급 업체가 애플리케이션을 판매하는 경우 (예: 애플 앱 스토어 및 다른 소스를 통해) 활성화 서버는 앱 스토어 영수증을 라이센스로 일치시킬 수 있다.

예를 들어 (이에 한정되는 것은 아님), 사용자는 앱 스토어 (예를 들어, 애플 앱 스토어)를 통해 애플리케이션을 구매했으며, 구매에 대한 정보는 공개 API를 통해 활성화 서버로 전송된다. 사용자가 컴퓨팅 장치에서 소프트웨어를 다시 활성화해야 하는 경우 소프트웨어 설치가 활성화된 것으로 인식되고 라이센스가 자동으로 발급된다.

프로세스 예(Example Process)

도 4는 예시적인 구현에 따라 서버에서 수행되는 프로세스(400)를 도시하고, 도 1 내지 3의 전술한 개시를 포함한다. 401에서, 사용자가 애플리케이션을 획득하고 다양한 모드 중 하나에 의해 애플리케이션의 획득의 확정을 수신한 후, 특정 사용자와 연관된 활성화 시스템의 데이터베이스의 레코드가 서버 측에서 시작된다. 또한, 403에서 서버는 소프트웨어 라이센스를 얻기 위해 사용자로부터 식별 정보 및 라이센스 요청을 수신한다. 활성화 시스템의 데이터베이스에서 레코드가 시작된 후, 라이센스에 대한 요청은 405에서 프로토콜에 의해 생성된다. 프로토콜에 따라 라이센스는 서버에서 생성되며 보안 개인 키로 서명된다. 109에서 라이센스 요청이 생성되면, 디지털 서명을 갖는 라이센스는 407에서 사용자에게 제공되고 라이센스 파일은 사용자 장치에 저장된다.

상술한 바와 같이 라이센스 요청이 수신된 후, 409에서 서버는 활성화가 올바른지 여부를 결정하고, 활성화 요청이 올바른 경우 413에서 라이센스를 발급하거나 그렇지 않으면 411에서 오류 메시지를 전송한다. 413에서, 소프트웨어 라이센스가 최종 사용자의 컴퓨터로 전달된 후, 서버에서 받은 라이센스를 수정하지 않고 415에서 확인을 통과해야 한다; 서명된 라이센스 파일을 변경하거나 가짜 라이센스를 생성하려고 시도하면 공급 업체 측에서 이러한 시도는 실패하고 라이센스 파일의 콘텐츠는 유효하지 않아 공급 업체 앱이 크랙되지 않는다. 라이센스 파일은 사용자 컴퓨터 파일 시스템의 특정 위치에 기입된다. 애플리케이션이 실행되면 라이센스 유효성이 415에서 검사된다. 라이센스 원본을 검증하고 완전성을 확정한 후 소프트웨어 설치가 완료되고 사용자가 소프트웨어를 사용할 수 있다. 활성화 상태는 활성화 서버에 의해 주기적으로 수신된다. 또한, 라이센스는 활성화 서버에 의해 원격으로 또는 직접 비활성화 될 수 있다

도 5는 예시적인 구현에 따라 서버에서 수행되는 프로세스(500)를 도시하고, 도 1 내지도 3의 전술한 개시를 포함한다. 501에서, 사용자는 애플리케이션을 획득한다. 또한, 503에서, 사용자는 다양한 모드 중 하나에 의해 애플리케이션의 획득에 대한 확정을 수신한다.

상술한 바와 같이, 애플리케이션의 각각의 획득 모드는 획득 확정의 준수 및 라이센스 발급 규칙 세트를 설정하는 것과 관련된 별개의 고유한 메커니즘을 갖는다. 획득 확정은 활성화 번호를 포함할 수 있고 사람이 읽을 수 있지만 무차별 검색을 방지하기에 충분히 길다. 또한, 예시적인 구현에 따른 URL 별 활성화 방식은 개발자가 사용자에게 사용자 동작으로 소프트웨어를 활성화하는 옵션을 제공할 수 있게 한다.

505에서, 사용자는 식별 정보 및 소프트웨어 라이센스를 얻기 위한 요청을 제공한다. 상술한 바와 같이 서버에 의해 라이센스 요청이 디지털 서명으로 생성되면, 사용자는 507에서 라이센스를 수신하고, 라이센스 파일은 사용자 장치에 저장된다.

라이센스 요청이 507에서 수신된 후, 서버는 활성화가 올바른지 여부를 결정하고, 활성화 요청이 올바른 경우 사용자는 513에서 라이센스의 발급을 수신하거나, 그렇지 않으면 511에서 에러 메시지를 수신한다. 513에서 최종 사용자의 컴퓨터에서 소프트웨어 라이센스를 받은 후 확인을 통과해야 한다. 라이센스는 서버에서 받은 라이센스를 수정하지 않고 사용자의 장치에 기입된다; 서명된 라이센스 파일을 변경하거나 가짜 라이센스를 생성하려고 시도하면 공급 업체 측에서 이 시도가 실패하고 라이센스 파일의 콘텐츠가 유효하지 않게 되어 공급업체 앱이 크랙되지 않는다. 라이센스 파일은 사용자 컴퓨터 파일 시스템의 특정 위치에 기록된다. 애플리케이션이 실행되면 라이센스 유효성이 검사된다. 라이센스 출처를 검증하고 완전성을 확정한 후 소프트웨어 설치가 완료되고 515에서 소프트웨어는 사용할 수 있는 상태가 된다. 활성화 상태는 주기적으로 활성화 서버로 전송된다. 또한, 서버에서 라이센스를 원격 또는 직접 비활성화 할 수 있다.

일부 예에서, 도 1 내지 도 5에 도시된 전술한 프로세스들이 다르거나 더 적거나 더 많은 블록들로 구현될 수 있다. 프로세스는 매체에 저장될 수 있고, 하나 이상의 컴퓨팅 장치의 하나 이상의 프로세서에 로딩되고, 컴퓨터로 구현되는 방법으로서 실행될 수 있는, 컴퓨터 실행 가능 명령어(instruction)로서 구현될 수 있다.

예시 환경(Example Environment)

도 6은 일부 예시적인 구현에 적합한 예시적인 환경을 도시한다. 환경(600)은 장치(605-645)를 포함하고, 각 장치는 예를 들어 네트워크(660)를 통해 (예를 들어, 유선 및/또는 무선 연결에 의해) 적어도 하나의 다른 장치에 통신 가능하게 연결된다. 일부 장치는 하나 이상의 저장 장치(630 및 645)에 통신 가능하게 연결될 수 있다.

하나 이상의 장치(605-645)의 예는 각각 도 7 및 도 8에서 후술되는 컴퓨팅 장치(705 및/또는 805)일 수 있다. 장치들(605-645)은 여기에 한정되는 것은 아니며, 컴퓨터(605)(예를 들어, 랩탑 컴퓨팅 장치), 모바일 장치(610) (예를 들어, 스마트 폰 또는 태블릿), 텔레비전(615), 차량 (620)과 관련된 장치, 서버 컴퓨터(625), 컴퓨팅 장치(635-640), 스토리지 장치(storage device)(630 및 645)를 포함할 수 있다.

일부 구현들에서, 장치들(605-620)은 도 3 내지 도 5와 관련하여 위에서 설명한 것 같은 서버와 연관될 수 있는 사용자 장치들(625-645)로 간주될 수 있다.

예를 들어, 비 제한적으로, 하나 이상의 장치들(625-645)에 의해 지원되는 네트워크상에 사용자 장치(605 또는 610)를 갖는 사용자는, 사용자 장치(625-645)를 사용하여 애플리케이션 획득, 라이센스 요청, 라이센스 수신을 수행하고 소프트웨어를 사용할 수 있다. 서버는 사용자 장치(605 또는 610)를 사용하여 도 1 내지 도 5와 관련하여 설명을 한 프로세스에 따라, 장치(625-645)를 사용하여 상술한 동작을 수행할 수 있다.

컴퓨팅 환경의 예(Example Computing Environment)

도 7은 일부 예시적인 구현에 사용하기 위해 외부 호스트와 연관된 예시적인 컴퓨팅 장치를 갖는 예시적인 컴퓨팅 환경을 도시한다. 컴퓨팅 환경(700)에서의 컴퓨팅 장치(705)는 하나 이상의 프로세싱 유닛, 코어 또는 프로세서(710), 메모리 (715) (예를 들어, RAM, ROM 등), 내부 스토리지(720) (예를 들어, 자기, 광학, 솔리드 스테이트 스토리지 및/또는 유기), 및/또는 I/O 인터페이스(725)를 포함하며, 이들 중 임의의 것은 정보를 전달하기 위해 통신 메커니즘 또는 버스(730)에 연결되거나 컴퓨팅 장치(705)에 내장될 수 있다.

컴퓨팅 장치(705)는 입력/사용자 인터페이스(735) 및 출력 장치/인터페이스(740)에 통신 가능하게 연결될 수 있다. 입력/사용자 인터페이스(735) 및 출력 장치/인터페이스(740) 중 하나 또는 둘 모두는 유선 또는 무선 인터페이스 일 수 있고 분리 가능할 수 있다. 입력/사용자 인터페이스(735)는 입력 (예를 들어, 버튼, 터치 스크린 인터페이스, 키보드, 포인팅/커서 제어, 마이크로폰, 카메라, 점자, 움직임 센서, 광학 리더 등)을 제공하는데 사용될 수 있는 임의의 장치, 컴포넌트(component), 센서 또는 인터페이스, 물리적 또는 가상 장치를 포함할 수 있다. 출력 장치/인터페이스(740)는 디스플레이, 텔레비전, 모니터, 프린터, 스피커, 점자 등을 포함할 수 있다. 일부 예시적인 구현에서, 입력/사용자 인터페이스(735) 및 출력 장치/인터페이스(740)는 컴퓨팅 장치(705)에 내장되거나 물리적으로 결합 될 수 있다. 다른 예시적인 구현에서, 다른 컴퓨팅 장치는 컴퓨팅 장치(705)를 위한 입력/사용자 인터페이스(735) 및 출력 장치/인터페이스(740)로서 기능하거나 그 기능을 제공 할 수 있다.

컴퓨팅 장치(705)의 예는 기동성이 아주 좋은 모바일 장치(highly mobile device)(예를 들어, 스마트 폰, 차량 및 기타 기계의 장치, 인간 및 동물이 착용하는 장치 등), 모바일 장치(예를 들어, 태블릿, 노트북, 랩탑, 개인용 컴퓨터, 휴대용 텔레비전, 라디오 등) 및 이동성을 위해 설계되지 않은 장치(예를 들어, 데스크탑 컴퓨터, 다른 컴퓨터, 정보 키오스크, 프로세서에 내장되고/되거나 그에 연결된 텔레비전, 라디오 등)를 포함하나 이에 제한되지는 않는다.

컴퓨팅 장치(705)는, 동일한 또는 다른 구성의 하나 이상의 컴퓨팅 장치를 포함하여 임의의 개수의 네트워크 연결된 컴포넌트들, 장치들 및 시스템들과의 통신을 위해, (예를 들어, I/O 인터페이스(725)를 통해) 외부 스토리지 장치(745) 및 네트워크(750)에 연결될 수 있다. 컴퓨팅 장치(705) 또는 임의의 연결된 컴퓨팅 장치는 서버, 클라이언트, 씬 서버(thin server), 범용 머신, 특수 목적 머신 또는 다른 라벨로서 기능을 하거나 이들의 서비스를 제공하거나 이들로 언급될 수 있다.

I/O 인터페이스(725)는 음성 및/또는 데이터 네트워크를 통한 무선 통신을 용이하게 하는 무선 통신 컴포넌트(미도시)를 포함할 수 있다. 무선 통신 컴포넌트는 하나 이상의 안테나를 갖는 안테나 시스템, 무선 시스템, 기저 대역 시스템 또는 이들의 임의의 조합을 포함할 수 있다. 무선 주파수(RF) 신호는 무선 시스템의 관리하에 안테나 시스템에 의해 무선으로 송수신 될 수 있다.

I/O 인터페이스(725)는, 컴퓨팅 환경(700)에서 적어도 모든 연결된 컴포넌트, 장치 및 네트워크로/로부터 정보를 통신하기 위한, 임의의 통신 또는 I/O 프로토콜 또는 표준 (예를 들어, 이더넷, 802.11x, 범용 시스템 버스, WiMax, 모뎀, 셀룰러 네트워크 프로토콜 등)을 사용하는 유서 및/또는 무선 인터페이스를 포함할 수 있다. 네트워크(750)는 임의의 네트워크 또는 네트워크의 조합 (예를 들어, 인터넷, 근거리 통신망, 광역망, 전화 네트워크, 셀룰러 네트워크, 위성 네트워크 등)일 수 있다.

컴퓨팅 장치(705)는 일시적 매체 및 비 일시적 매체를 포함하여 컴퓨터 사용 가능 또는 컴퓨터 판독 가능 매체를 사용 및/또는 사용하여 통신할 수 있다. 일시적 매체는 전송 매체 (예를 들어, 금속 케이블, 광섬유), 신호, 반송파 등을 포함한다. 비 일시적 매체에는 자기 매체 (예 : 디스크 및 테이프), 광학 매체 (예 : CD ROM, 디지털 비디오 디스크, 블루레이 디스크), 솔리드 스테이트 매체 (예 : RAM, ROM, 플래시 메모리, 솔리드 스테이트 스토리지) 및 기타 비휘발성 스토리지 또는 메모리가 포함될 수 있다.

컴퓨팅 장치(705)는 일부 예시적인 컴퓨팅 환경에서 기술, 방법, 애플리케이션, 프로세스 또는 컴퓨터 실행 가능 명령어를 구현하는 데 사용될 수 있다. 컴퓨터 실행 가능 명령어는 일시적 매체로부터 얻을 수 있고, 비 일시적 매체에서 저장되고 거기서 얻을 수 있다. 실행 가능한 명령어는 하나 이상의 프로그래밍, 스크립팅 및 기계 언어 (예 : C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript 등)에서 비롯 될 수 있다.

프로세서(들)(710)는 고유 환경(native environment) 또는 가상 환경에서 임의의 운영 체제 (OS) (미도시) 하에서 실행될 수 있다. 서로 다른 유닛들이 서로 통신하도록, OS와 통신하도록 그리고 다른 애플리케이션들(미도시)과 통신하도록 하는 유닛 간 통신 메커니즘(795), 로직 유닛(760), API (application programming interface) 유닛(765), 입력 유닛(770), 출력 유닛(775), 획득 확정 및 사용자 요청 검토 유닛(780), 라이센스 발급 결정 유닛(785), 라이센스 생성 유닛(790)을 포함하는 하나 이상의 애플리케이션이 사용될 수 있다. 예를 들어, 획득 확정 및 사용자 요청 검토 유닛(780), 라이센스 발급 결정 유닛(785) 및 라이센스 생성 유닛(790)은 도 1 내지 도 5에 도시된 하나 이상의 프로세스를 구현할 수 있다. 설명된 유닛 및 요소는 설계, 기능, 구성 또는 구현에서 다양할 수 있으며 제공된 설명으로 제한되지 않는다.

일부 예시적인 구현에서, API 유닛(765)이 정보 또는 실행 명령어를 수신한 후 하나 이상의 다른 유닛(예를 들어, 로직 유닛(760), 입력 유닛(770), 출력 유닛(775), 획득 확정 및 사용자 요청 검토 유닛(780), 라이센스 발급 결정 유닛(785) 및 라이센스 생성 유닛(790))과 통신할 수 있다.

예를 들어, 입력 유닛(770)이 애플리케이션을 획득하기 위한 명령어, 라이센스 요청, 또는 다른 그러한 사용자 상호 작용과 같은 사용자로부터 입력을 수신한 후, 입력 유닛(770)은 API 유닛(765)을 사용하여 데이터 획득 확정 및 사용자 요청 검토 유닛(780)과 통신할 수 있다. 예를 들어, 획득 확정 및 사용자 요청 검토 유닛(780)은 상술한 바와 같이 라이센스가 발급되어야 하는지에 관한 결정을 할 수 있다.

획득 확정 및 사용자 요청 검토 유닛(780)은 API 유닛(765)을 통해 라이센스 발급 결정 유닛(785)과 상호 작용하여 라이센스의 발급 여부에 대한 출력을 제공 할 수 있다. API 유닛(765)을 사용하여, 획득 확정 및 사용자 요청 검토 유닛(780)은 전술한 바와 같이, 라이센스 생성 유닛(790)과 상호 작용하여 라이센스를 생성하고 라이센스를 사용자에게 제공 할 수 있다.

일부 예에서, 로직 유닛(760)은 유닛들 간의 정보 흐름을 제어하고 API 유닛(765), 입력 유닛(770), 출력 유닛(775), 획득 확정 및 사용자 요청 검토 유닛(780), 라이센스 발급 결정(7850 및 라이센스 생성 유닛(790)에 의해 제공되는 서비스를 지시(direct)하도록 구성될 수 있다. 예를 들어, 하나 이상의 프로세스 또는 구현의 흐름은 로직 유닛(760)에 의해 단독으로 또는 API 유닛(765)과 함께 제어될 수 있다.

예시적인 구현은 다양한 이점 및 장점을 가질 수 있다. 예를 들어, 라이센스 활성화 및 검증 프로세스 중에 해커가 민감한 정보를 얻거나 애플리케이션을 사용할 위험과 소프트웨어 개발자의 정보 유출 위험을 줄이기 위해 보안 강화가 제공된다.

몇몇 예시적인 구현들이 도시되고 설명되었지만, 이 예시적인 구현들은 본 분야에 익숙한 사람들에게 본 명세서에 설명된 주제를 전달하기 위해 제공된다. 여기에 설명된 주제는 설명된 예시적인 구현으로 제한되지 않고 다양한 형태로 구현될 수 있음을 이해해야 한다. 본 명세서에 기술된 주제는 구체적으로 정의되거나 기술된 사항 없이 또는 설명되지 않은 다른 또는 상이한 요소 또는 사항으로 실시될 수 있다. 첨부된 청구 범위 및 그 균등물에 정의된 바와 같이 본 명세서에 기술된 주제를 벗어나지 않으면서 이러한 예시적인 구현에서 변경이 이루어질 수 있다는 것은 이 분야에 익숙한 자에게 이해될 것이다.

Claims (17)

1. 소프트웨어 활성화 및 라이센스 추적 방법으로서, 상기 방법은:
   (a) 소프트웨어의 획득과 연관된 획득 확정을 취득하여 상기 획득 확정을 소프트웨어 활성화 및 라이센싱과 연관된 서버에 제공하고;
   (b) 클라이언트가 상기 소프트웨어를 사용할 권한이 있도록 라이센스를 요청하되, 상기 라이센스는 서버에 의해 개인 키로 보안화되어 있고 상기 개인키는 상기 클라이언트에 저장되지 않고;
   (c) 상기 라이센스를 클라이언트에 발급 및 제공하고;
   (d) 상기 클라이언트에서 상기 라이센스를 검증하고;
   (e) 상기 클라이언트에서 상기 라이센스를 저장하고;
   (f) 주기적으로 상기 라이센스의 활성화 상태를 추적하고; 그리고,
   (g) 상기 라이센스의 상기 활성화 상태에 근거해서, 상기 클라이언트에서 상기 라이센스에 대한 조치를 수행함을 포함하며,
   상기 클라이언트에서 상기 라이센스를 검증함은 상기 애플리케이션과 연관된 클라이언트에서 상기 서버로부터 받은 상기 라이센스를 확인하고 상기 라이센스를 상기 클라이언트에 저장함을 포함하는,
   방법.
2. 제1항에 있어서,
   상기 획득 확정은 상기 서버와 연관된 데이터베이스의 레코드 및 활성화 키 중 적어도 하나를 포함하고,
   상기 서버는 상기 획득 확정을 상기 소프트웨어 라이센스와 바꾸기 위한 인스트럭션을 상기 사용자에게 제공하는,
   방법.
3. 제1항에 있어서,
   상기 획득 확정은 직접 판매, 제3자 재판매자를 통한 판매, 그리고 물리적 매체상의 박스 버전 혹은 온라인을 통한 배포 중 하나에 의해 취득되는,
   방법.
4. 제1항에 있어서,
   상기 획득 확정은, 상기 획득 확정을 생성하는 서버와 연관된 URL, 복수 개의 획득 확정의 대량 생성 및 상기 획득 확정의 단일 생성 중 적어도 하나에 의해 생성되는,
   방법.
5. 제4항에 있어서,
   상기 URL에 의해 생성된 상기 획득 확정은,
   상기 획득 확정을 취득하기 위한 웹페이지 액세스를 상기 사용자에게 제공하고;
   상기 사용자와 연관된 필요한 정보를 수신하고;
   상기 애플리케이션의 구매가 성공일 경우 상기 사용자의 상기 필요한 정보를 상기 서버에 제공하고 상기 획득 정보를 상기 사용자에게 제공하되, 상기 애플리케이션의 주문 정보는 상기 서버에 저장되고, 상기 획득 확정은 상기 서버에 의해 생성되고; 그리고,
   상기 애플리케이션의 구매가 성공이 아닐 경우, 상기 사용자에게 상기 애플리케이션의 구매가 성공하지 않았다는 표시를 제공함을 포함하는,
   방법.
6. 제1항에 있어서,
   상기 획득 확정은 암호화 없이 상기 사용자에게 제공되는,
   방법.
7. 제1항에 있어서,
   상기 방법은,
   고유한 로그인 및 비밀번호 정보 쌍을 제공하고, 보안 키로 보호된 서버와 보안 연결을 수립하고 그리고 상기 서버와 연결을 수립하여 상기 사용자를 식별하는 파라미터를 전송하는 것 중 적어도 하나에 의해 상기 획득 확정의 생성과 연관된 상기 서버에 레코드를 생성함을 더 포함하며,
   상기 사용자가 식별을 제공한 후, 상기 서버에 상기 애플리케이션의 획득에 대한 정보를 저장함을 포함하는,
   방법.
8. 제1항에 있어서,
   상기 (c) 및 상기 (d)는,
   상기 사용자로부터 상기 획득 확정을 수신하고;
   상기 클라이언트가 상기 라이센스 요청을 생성하여 상기 서버에 제공하고;
   상기 서버가 상기 획득 확정에 대해 활성화가 허락되었는지 여부를 결정하고;
   상기 활성화가 허락된 경우 상기 서버가 상기 사용자의 식별 정보에 근거해서 라이센스를 발급하고 상기 라이센스의 파일을 상기 사용자에게 제공함을 포함하는,
   방법.
9. 제1항에 있어서,
   상기 획득 확정은 상기 애플리케이션의 설치에 의해 인식되고, 상기 사용자가 정보를 상기 서버에 제공하도록 양식의 출현을 트리거할 특정 접미사를 갖는 패턴을 사용하여 생성된 하나 이상의 활성화 키를 포함하며,
   상기 애플리케이션의 공급 업체는 자신의 패턴에 근거해서 상기 패턴을 결정할 수 있는,
   방법.
10. 제1항에 있어서,
    상기 라이센스는 상기 애플리케이션의 번들 ID, 상기 클라이언트의 하나 이상의 식별자 및 임의로 생성된 문자열 중 적어도 하나와 연관된 파라미터들을 포함하여 생성되는,
    방법.
11. 제1항에 있어서,
    상기 검증은 상기 서버상에서 생성된 상기 라이센스의 검증을 수행함을 포함하며, 상기 라이센스는 디지털 서명을 생성하는 고유하고 안전한 개인 키로 서명되고, 상기 디지털 서명은 상기 클라이언트에서 상기 소프트웨어의 공개 키에 의해 추가로 검증되며, 상기 소프트웨어는 공급 업체 애플리케이션을 포함하는,
    방법.
12. 소프트웨어 활성화 및 라이센스 추적을 위한 동작을 수행하도록 구성된 비일시적인 컴퓨터 판독 가능한 매체로서, 상기 동작은,
    (a) 소프트웨어의 획득과 연관된 획득 확정을 취득하여 상기 획득 확정을 소프트웨어 활성화 및 라이센싱과 연관된 서버에 제공하고;
    (b) 클라이언트가 상기 소프트웨어를 사용할 권한이 있도록 라이센스를 요청하되, 상기 라이센스는 서버에 의해 개인 키로 보안화되어 있고 상기 개인키는 상기 클라이언트에 저장되지 않고;
    (c) 상기 라이센스를 클라이언트에 발급 및 제공하고;
    (d) 상기 클라이언트에서 상기 라이센스를 검증하고;
    (e) 상기 클라이언트에서 상기 라이센스를 저장하고;
    (f) 주기적으로 상기 라이센스의 활성화 상태를 추적하고; 그리고,
    (g) 상기 라이센스의 상기 활성화 상태에 근거해서, 상기 클라이언트에서 상기 라이센스에 대한 조치를 수행함을 포함하며,
    상기 클라이언트에서 상기 라이센스를 검증함은 상기 애플리케이션과 연관된 클라이언트에서 상기 서버로부터 받은 상기 라이센스를 확인하고 상기 라이센스를 상기 클라이언트에 저장함을 포함하는,
    비일시적인 컴퓨터 판독 가능한 매체.
13. 제12항에 있어서,
    URL에 의해 생성된 상기 획득 확정은,
    상기 획득 확정을 취득하기 위한 웹페이지 액세스를 상기 사용자에게 제공하고;
    상기 사용자와 연관된 필요한 정보를 수신하고;
    상기 애플리케이션의 구매가 성공일 경우 상기 사용자의 상기 필요한 정보를 상기 서버에 제공하고 상기 획득 정보를 상기 사용자에게 제공하되, 상기 애플리케이션의 주문 정보는 상기 서버에 저장되고, 상기 획득 확정은 상기 서버에 의해 생성되고; 그리고,
    상기 애플리케이션의 구매가 성공이 아닐 경우, 상기 사용자에게 상기 애플리케이션의 구매이 성공하지 않았다는 표시를 제공함을 포함하는,
    비일시적인 컴퓨터 판독 가능한 매체.
14. 제12항에 있어서,
    상기 획득 확정은 암호화 없이 상기 사용자에게 제공되는,
    비일시적인 컴퓨터 판독 가능한 매체.
15. 제12항에 있어서,
    상기 동작은,
    고유한 로그인 및 비밀번호 정보 쌍을 제공하고, 보안 키로 보호된 서버와 보안 연결을 수립하고 그리고 상기 서버와 연결을 수립하여 상기 사용자를 식별하는 파라미터를 전송하는 것 중 적어도 하나에 의해 상기 획득 확정의 생성과 연관된 상기 서버에 레코드를 생성함을 더 포함하며,
    상기 사용자가 식별을 제공한 후, 상기 서버에 상기 애플리케이션의 획득에 대한 정보를 저장함을 포함하는,
    비일시적인 컴퓨터 판독 가능한 매체.
16. 제12항에 있어서,
    상기 (c) 및 상기 (d)는,
    상기 사용자로부터 상기 획득 확정을 수신하고;
    상기 클라이언트가 상기 라이센스 요청을 생성하여 상기 서버에 제공하고;
    상기 서버가 상기 획득 확정에 대해 활성화가 허락되었는지 여부를 결정하고; 그리고
    상기 활성화가 허락된 경우 상기 서버가 상기 사용자의 식별 정보에 근거해서 라이센스를 발급하고 상기 라이센스의 파일을 상기 사용자에게 제공함을 포함하며,
    상기 획득 확정은, 상기 애플리케이션의 설치에 의해 인식되고, 상기 사용자가 정보를 상기 서버에 제공하도록 양식의 출현을 트리거할 특정 접미사를 갖는 패턴을 사용하여 생성된 하나 이상의 활성화 키를 포함하며,
    상기 애플리케이션의 공급 업체는 자신의 패턴에 근거해서 상기 패턴을 결정할 수 있는,
    비일시적인 컴퓨터 판독 가능한 매체.
17. 제12항에 있어서,
    상기 검증은 상기 서버상에서 생성된 상기 라이센스의 검증을 수행함을 포함하며, 상기 라이센스는 디지털 서명을 생성하는 고유하고 안전한 개인 키로 서명되고, 상기 디지털 서명은 상기 클라이언트에서 상기 소프트웨어의 공개 키에 의해 추가로 검증되며, 상기 소프트웨어는 공급 업체 애플리케이션을 포함하는,
    비일시적인 컴퓨터 판독 가능한 매체.
    

Images