KR102030643B1

KR102030643B1 - 전자 라이센스 관리

Info

Publication number: KR102030643B1
Application number: KR1020177003554A
Authority: KR
Inventors: 리차드 지. 캐닝스; 다이앤 케이. 핵본; 산자이 제야쿠마르; 재스퍼 에스. 린; 데베쉬 파레크; 칼 로센; 마크 디. 워맥
Original assignee: 구글 엘엘씨
Priority date: 2010-05-19
Filing date: 2011-05-19
Publication date: 2019-10-10
Also published as: US10007960B2; CA2797131C; AU2011255512A1; CN105760716A; CN105760716B; US20150149363A1; US8966655B2; CA2797131A1; AU2011255512B2; US20120023596A1; US20110289003A1; CN103038775A; CN103038775B; KR20170019476A; KR20130114593A; WO2011146785A1; KR101709720B1

Abstract

일 양태에서, 이 출원은 소프트웨어 애플리케이션의 라이센스 상태를 판단하기 위한 방법을 설명한다. 본 방법은 상기 소프트웨어 애플리케이션이 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부에 대한 표시를 획득하기 위해, 라이센스 상태 요청을 수신하는 단계를 포함한다. 본 발명은 또한 사용자 아이덴티티 정보 및/또는 디바이스 아이덴티티 정보에 상응하는 아이덴티티 정보를 식별하는 단계를 포함한다. 본 방법은 상기 라이센스 상태 요청으로부터 생성된 통신과 상기 아이덴티티 정보를 라이센싱 서비스로 전송하는 단계를 포함하고, 상기 통신은 상기 소프트웨어 애플리케이션에 연관된 상기 아이덴티티 정보 및 라이센싱 정보에 적어도 부분적으로 기초하여, 상기 표시를 생성하기 위해 상기 라이센싱 서비스에 의해 사용된다. 본 발명은 또한 상기 표시를 포함하는 라이센스 상태 응답을, 상기 라이센싱 서비스로부터 수신하는 단계를 포함한다. 본 방법은 또한 상기 소프트웨어 애플리케이션에 의한 처리를 위하여, 상기 라이센스 상태 응답을 상기 소프트웨어 애플리케이션에 전송하는 단계를 포함한다.

Description

전자 라이센스 관리{ELECTRONIC LICENSE MANAGEMENT}

본 출원은 미국 출원 번호 61/346,452호에 대한 우선권을 미국 특허법(35U.S.C) 119(e)항 하에 주장하며, 이 미국 출원의 모든 내용은 본 명세서에 포함된다.

본 출원은 소프트웨어 애플리케이션들과 같은 전자 매체 제품(electronic media product)들에 대한 액세스 및 권리를 관리하는 것에 관한 것이다.

소프트웨어는 만들기는 어려운 반면, 카피하기는 쉽다. 좋은 소프트웨어 애플리케이션을 만드는 것은 종종 수백 또는 수천 시간이 걸릴 수도 있지만, 일반 컴퓨터를 갖고 있는 비도덕적인 사용자들은 때때로 그 동일한 작업 제품을 수초내에 카피할 수 있다. 저작권법이 법적 보호의 조치(measure)를 제공하지만, 이것은 비인증된 단체(party)들이 퍼블리셔의 소프트웨어에 대한 카피본을 만드는 것을 직접적으로 방지할 수 없다. 따라서 많은 경우, 저작권 보호만으로는 만족스럽지 못할 수도 있다.

일부 소프트웨어 퍼블리셔들은 예컨대, 카피 보호 스키마들 또는 다양한 DRM(Digital Right Management) 시스템들을 사용하여, 자신의 소프트웨어 및 다른 콘텐츠들의 인증되지 않은 카피를 단념(deter)시키는 기술적 장애물들을 구현하고 있다. 카피 보호 스키마의 일 예시는, 예를 들어 3자들이 애플리케이션 스토어를 통해 판매할 수 있는 소프트웨어 애플리케이션들의 비인증된 카피를 보호하기 위해 사용될 수 있는 포워드 락킹(forward locking)으로서 알려져 있다. 포워드 락킹 방식을 사용하면, 클라이언트 디바이스는 애플리케이션 스토어로부터의 요청된 소프트웨어를, 그 애플리케이션 바이너리(binary)들이 사용자에 의해 쉽게 액세스될 수 없는 디바이스상의 보호된 공간에 다운로드한다. 이러한 방식은 자신의 설치 사이즈(installation size)를 많이 증가시킬 수 있는 일부 애플리케이션들(예컨대, 게임)에 대한 비-실행가능 리소스들을 복제하는 것에 관련될 수 있다. 그보다 더 중요한 것은, 이러한 방식은, 특정 상황에서, 개발 목적으로 "언락(unlock)"되어진 디바이스(예컨대, 스마트폰) 상에서, 디바이스의 카피 오프(copy off)되어지는 쉬운 애플리케이션 바이너리들을 남겨두어서, 극복될 수 있다.

본 명세서는 소프트웨어 애플리케이션 또는 유사한 디지털 아이템의 현재 라이센스 상태를 검증하기 위한 시스템들 및 기술들을 설명한다. 애플리케이션의 라이센스 상태는 그 애플리케이션을 사용하려고 시도하는 특정 사용자 또는 특정 디바이스에 링크될 수 있고, 일부 경우에는, 특정 사용자 또는 디바이스가 애플리케이션을 계속 사용하도록 허용되었는지 여부를 제어하는데 사용될 수 있다. 예를 들어, 사용자가 부적절한 채널(improper channel)을 통해(예컨대, 그 애플리케이션을 퍼블리셔로부터 구매하지 않고 친구로부터 카피함으로써) 그 애플리케이션을 획득한 경우, 그 사람의 라이센스 상태는 사용자가 라이센스 받은 사용자(licensed user)가 아닌 것을 나타낼 수 있다. 결국, 이 애플리케이션은 적절한 방식(예컨대, 라이센스 받은 사용자들만 이용할 수 있는 특정 기능을 이용하지 못하게 함으로써)으로 응답할 수 있다.

일부 구현예들에서, 여기에서 설명된 기술들은 예를 들어, 신뢰할 수 있는 기관(trusted organization)에 의해 운영되는 애플리케이션 마켓(application market)을 통해 제공되는 소프트웨어를 보호하기 위해 사용될 수 있다. 신뢰할 수 있는 기관은 또한 마켓에 제공되어 있는 소프트웨어를 위한 라이센싱 서비스로의 액세스를 제공할 수 있다. 임의 명의 소프트웨어 퍼블리셔들이 자신의 애플리케이션들을 애플리케이션 마켓에 제공할 수 있고, 그 애플리케이션들은 다양한 사용자에 의해 구매될 수 있거나 배포될 수 있다. 일부 경우, 그 애플리케이션 마켓에 액세스하고자 하는 사용자들은 애플리케이션 마켓을 통해 제공되어 있는 애플리케이션을 구매하거나 브라우징하기 위해 사용자의 클라이언트 디바이스상에서 실행하는 마켓플레이스 클라이언트(marketplace client)를 사용할 수 있다.

이러한 시스템을 사용하여 자신의 소프트웨어를 제공하는 소프트웨어 퍼블리셔들은 자신의 애플리케이션의 저작권 침해(piracy)를 방지하고자 할 수 있다. 예를 들어, 퍼블리셔의 애플리케이션의 카피본 대부분이 애플리케이션 마켓을 통해 합법적으로 구매, 라이센싱, 및 배포된다 하더라도, 다른 잠재적 비인증된 카피본들이 존재할 수 있다. 이런 이유로, 퍼블리셔들이 합법적으로 라이센싱된 카피본들과 불법적으로 라이센스 되지 않은 카피본들 간을 구별할 수 있는 편리한 방식을 원할 수도 있다.

여기에서 설명된 기술들에 따라서, 클라이언트 디바이스에서 실행중인 애플리케이션은 라이센싱 서버를 쿼리함으로써 그 애플리케이션의 현재 라이센스 상태(예컨대, 특정 사용자 및/또는 디바이스가 그 애플리케이션의 사용에 대해 라이센스를 얻었는지 여부)를 요청할 수 있다. 라이센싱 서버는 이 라이센스 상태(예컨대, 그들의 등록된 계정 중 하나에 의한 특정 사용자, 및/또는 특정 디바이스가 애플리케이션의 사용에 대해 라이센스 되었거나, 라이센스 되지 않았음)을 응답할 수 있으며, 이로써 그 애플리케이션의 합법적인 카피본 및 불법적인 카피본 간의 구별(distiction)을 제공한다. 라이센스 체크 기술들은 예를 들어, 애플리케이션이 실행되었을 때 활성화될 수 있고, 애플리케이션의 추가 사용은 그 라이센스 체크의 결과에 기초하여 판단될 수 있다. 일부 구현예들에서, 라이센스 체크가 그 애플리케이션이 적절하게 라이센스 되지 않았다는 것을 나타내면, 그 애플리케이션은 스스로 강제 종료(shut down)하거나 애플리케이션의 전체 기능의 제한된 서브셋만을 제공할 수 있다.

하나의 일반적인 양태에서, 이 출원은 소프트웨어 애플리케이션의 라이센스 상태를 판단하기 위한 컴퓨터로 구현되는 방법을 설명한다. 본 방법은 클라이언트 컴퓨팅 디바이스에서 실행중인 라이센싱 클라이언트에서 클라이언트 컴퓨팅 디바이스에서 실행중인 소프트웨어 애플리케이션으로부터, 상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부에 대한 표시(indication)를 획득하기 위해, 라이센스 상태 요청을 수신하는 단계를 포함한다. 본 발명은 또한 상기 라이센싱 클라이언트를 사용하여, 클라이언트 컴퓨팅 디바이스의 사용자에 상응하는 사용자 아이덴티티 정보와 상기 클라이언트 디바이스에 상응하는 디바이스 아이덴티티 정보로 구성된 적어도 하나의 그룹에 상응하는 아이덴티티 정보를 식별하는 단계를 포함할 수 있다. 본 방법은 상기 라이센스 상태 요청으로부터 생성된 통신과 상기 아이덴티티 정보를 상기 클라이언트 컴퓨팅 디바이스로부터 원격되어 동작하는 라이센싱 서비스로 전송하는 단계를 포함하고, 상기 통신은 상기 소프트웨어 애플리케이션에 연관된 상기 아이덴티티 정보 및 라이센싱 정보에 적어도 부분적으로 기초하여, 상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부에 대한 표시를 생성하기 위해 상기 라이센싱 서비스에 의해 사용된다. 본 발명은 또한 상기 라이센싱 클라이언트로, 상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부에 대한 표시를 포함하는 라이센스 상태 응답을, 상기 라이센싱 서비스로부터 수신하는 단계를 포함할 수 있다. 본 방법은 또한 상기 소프트웨어 애플리케이션에 의한 처리를 위하여, 상기 라이센스 상태 응답을 상기 소프트웨어 애플리케이션에 전송하는 단계를 포함할 수 있다.

다른 일반적인 양태에서, 본 출원은 소프트웨어 애플리케이션의 라이센스 상태를 획득하기 위한 컴퓨터로 구현되는 시스템을 설명한다. 본 시스템은 소프트 애플리케이션 및 라이센싱 클라이언트를 실행하도록 마련(arrange)된 클라이언트 컴퓨팅 디바이스를 포함할 수 있다. 또한, 본 시스템은 라이센싱 서비스를 실행하도록 마련된 라이센싱 서버 시스템을 포함할 수 있다. 소프트웨어 애플리케이션은 상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부에 대한 표시를 상기 라이센싱 서비스로부터 획득하기 위해, 라이센스 상태 요청을 생성하고, 상기 라이센스 상태 요청을 상기 라이센싱 클라이언트에 제공하도록 구성될 수 있다. 상기 라이센싱 클라이언트는 상기 소프트웨어 애플리케이션으로부터 상기 라이센스 상태 요청을 수신하고, 상기 클라이언트 컴퓨팅 디바이스의 사용자에 상응하는 사용자 아이덴티티 정보와 상기 클라이언트 컴퓨팅 디바이스에 상응하는 디바이스 아이덴티티 정보로 구성되는, 적어도 하나의 그룹에 상응하는 아이덴티티 정보를 식별하고, 상기 라이센스 상태 요청 및 상기 아이덴티티 정보로부터 생성된 통신을 상기 라이센싱 서비스에 전송하도록 구성될 수 있다. 상기 라이센싱 서비스는 상기 라이센싱 클라이언트로부터 상기 통신을 수신하고, 상기 소트프웨어 애플리케이션에 연관된 상기 아이덴티티 정보와 라이센싱 정보에 적어도 부분적으로 기초하여, 상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부를 판단하고, 상기 소프트 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부에 대한 표시를 포함하는 라이센스 상태 응답을 생성하고, 및 상기 라이센스 상태 응답을 상기 라이센싱 클라이언트에 전송하도록 구성될 수 있다. 상기 라이센싱 클라이언트는 상기 라이센싱 서비스로부터 상기 라이센스 상태 응답을 수신하고, 상기 라이센스 상태 응답을 상기 소프트웨어 애플리케이션에 제공하도록 더 구성될 수 있다. 상기 소프트웨어 애플리케이션은 상기 라이센싱 클라이언트로부터 상기 라이센스 상태 응답을 수신하고, 상기 라이센스 상태 응답을 처리하도록 더 구성될 수 있다.

다른 일반적인 양태에서, 본 출원은 컴퓨터로 구현되는 방법을 설명하는데, 이 방법은 라이센싱 서버 시스템상에서 실행중인 라이센싱 서비스에서 상기 라이센싱 서버 시스템으로부터 원격되어 동작하는 클라이언트 컴퓨팅 디바이스상에서 실행중인 라이센싱 클라이언트로부터, 상기 클라이언트 컴퓨팅 디바이스상에서 실행중인 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부를 판단하기 위한 요청을 수신하는 단계를 포함한다. 상기 요청은 사용자 아이덴티티 정보와 디바이스 아이덴티티 정보로 구성되는, 적어도 하나의 그룹에 상응하는 아이덴티티 정보를 포함할 수 있다. 본 방법은 또한 애플리케이션 마켓플레이스를 통한 상기 소프트웨어 애플리케이션의 구매와 연관된 구매 레코드들을 포함하는 라이센싱 정보를 액세스하는 단계를 포함할 수 있다. 본 방법은 또한 상기 라이센싱 정보 및 상기 아이덴티티 정보에 적어도 부분적으로 기초하여, 상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부에 대한 표시를 생성하는 단계를 포함한다. 본 방법은 또한 상기 클라이언트 컴퓨팅 디바이스에 의한 처리를 위해, 상기 표시를 상기 클라이언트 컴퓨팅 디바이스에 전송하는 단계를 포함할 수 있다.

특정 경우, 다양한 애플리케이션들은 하나 이상의 후술하는 이점들을 제공할 수 있다. 여기에서 설명된 라이센싱 방식은 소프트웨어 퍼브리셔들이 구현하기는 상대적으로 쉬운 반면, 사용자들이 크랙(crack)하기는 상대적으로 어려울 수 있다. 이런 이유로, 소프트웨어 퍼블리셔들은 애플리케이션-특정 카피 보호 스키마(application-specific copy protection scheme)들을 개발하기 보다는 애플리케이션에 설계되는 기능을 포함시키기 위해 자신의 애플리케이션들을 코딩하는데 더 많은 시간을 들일 수 있게 할 수 있다. 또한, 라이센싱 방식은 소프트웨어 퍼블리셔들이 그들이 선택하는 임의의 방식으로 구성가능한 라이센싱 정책들을 실시(enforce)할 수 있도록, 유연적이다. 또한, 라이센스 체크 기능은 특정 구현예들에서 애플리케이션의 크기를 현저하게 증가시키지 않을 수 있다.

하나 이상의 실시예에 대한 상세 내용은 첨부한 도면 및 이하 상세한 설명에서 개시된다. 다른 특징 및 이점들은 상세한 설명과 도면, 및 청구범위로부터 명백해질 것이다.

도 1은 소프트웨어 애플리케이션들을 배포하고, 그 애플리케이션들 각각의 라이센스 상태를 체크하기 위하 시스템의 개념도이다.
도 2는 소프트웨어 애플리케이션의 라이센스 상태를 체크하기 위한 다층 시스템(multi-tiered system)의 개념도이다.
도 3은 예시적 라이센스 체크 및 응답을 나타내는 다이어그램이다.
도 4는 소프트웨어 애플리케이션의 라이센스 상태를 요청 및 처리하기 위한 프로세스의 스윔-레인(swim-lane) 다이어그램이다.
도 5는 본 명세서에서 설명된 라이센스 상태 체크 시스템들과 프로세스들이 이용할 수 있는 예시적 상태 코드들을 구비한 테이블들을 나타낸다.
도 6은 본 명세서에서 설명된 기술들을 구현하는데 사용될 수 있는 컴퓨터 디바이스 및 모바일 컴퓨터 디바이스의 예시를 나타낸다.
여러 도면에서 유사한 참조 기호는 유사한 요소들을 가리킨다.

본 명세서는 라이센스 되지 않은 사용자들 및/또는 디바이스들에 의한 애플리케이션의 비인증된 사용들로부터, 중앙 애플리케이션 스토어 또는 앱 스터어를 통해 배포되어 판매되는 소프트웨어 애플리케이션들을 보호하기 위한 시스템들 및 기술들을 설명한다. 이 시스템들 및 기술들은, 애플리케이션이 사용자 및/또는 디바이스에 대해 적합하게 라이센싱되었는지 여부를 식별하기 위해 사용자 또는 디바이스에 대한 정보를 구매 레코드들의 세트와 비교함으로써 애플리케이션의 현재 라이센스 상태를 체크하는 라이센싱 스키마를 사용하고, 적절한 처리를 위하여 애플리케이션의 라이센스 상태를 애플리케이션에 리턴한다. 예를 들어, 라이센스 상태 체크가 현재 사용자가 애플리케이션을 사용하기 위해 라이센스 되지 않았다는 것을 나타낼 때, 애플리케이션은 라이센스 받은 사용자들만 이용할 수 있는 특정 특징들을 이용하지 못할 수도 있다. 일부 경우에, 여기에서 설명된 라이센싱 스키마가 앱 스토어를 통해 제공되어 있는 다른 디지털 콘텐츠를 보호하기 위해 사용될 수도 있다.

이러한 기능은 복수의 다른 소프트웨어 퍼블리셔를 위한 앱 스토어를 운영하는 단일 소프트웨어 배포 서비스에 의해 제공될 수 있다. 퍼블리셔들 각각이 자신의 검증 시스템들을 확립하거나 이러한 시스템들을 운영하지 않아도, 공정하고 편리하게 라이센싱 보호를 획득할 수 있도록 하기 위해, 라이센싱 시스템은 자신과 상호동작하기 위한 가이드라인들을 퍼블리시할 수 있다. 오히려, 퍼블리셔들은 앱 스토어에 제시(presentation)하기에 공정한 표준 방식으로 자신의 애플리케이션들을 업로드할 수 있고, 퍼블리셔들을 위해 구현된 라이센싱 제한 사항들과 퍼블리셔들에게 보고될 라이센싱 발행물(issue)들에 관한 정보를 가질 수 있다.

소프트웨어 퍼블리셔들은 자신의 애플리케이션들, 또는 앱들을 적절한 메타데이터(예컨대, 가격 책정(pricing), 텍스트 설명, 아이콘들, 애플리케이션을 다운받은 사용자들로부터 결제 금액을 입금받기 위한 계좌 번호 등)와 함께 앱 스토어에 업로드할 수 있다. 이러한 퍼블리셔들은 조합된 법적 및 기술적 라이센싱 방식을 이용하여 자신의 앱들에 대한 저작권 침해를 제한하고자 할 수 있다. 본 방식의 기술적 측면에서는 소프트웨어의 라이센스 되지 않은 사용에 대해 제한 사항들을 행사할 수 있는 반면, 본 방식의 법적 측면에서는 기술적 제한과 일치하는 법률 조건(legal terms)에서 소프트웨어를 사용할 수 있는 상응하는 권리를 정의할 수 있다. 퍼블리셔들은 기술적 및 법적 제한 사항 중 하나 또는 둘 모두를 정의하기 위한 옵션들의 메뉴로부터 선택(예컨대, 알려진 공개 소스 라이센싱 시스템들과 같은, 특정 잘 알려진 및 표준 라이센싱 시스템들로부터 선택함으로써)할 수 있고, 및/또는 예를 들어, 자신의 라이센싱 언어를 제공함으로써 이러한 제한 사항들을 스스로 완전하게 정의할 수 있다.

아래에서 보다 자세하게 설명되는 바와 같이, 신뢰할 수 있는 라이센싱 서비스는 예컨대, 사용자가 클라이언트 디바이스상에서 애플리케이션의 구동을 허여받기 전에, 애플리케이션의 라이센스 상태를 체크함으로써 퍼블리셔들이 자신의 애플리케이션들로의 액세스를 제어할 수 있는 안전한 방식을 제공할 수 있다. 애플리케이션이 라이센싱 서버에서 라이센스 상태를 체크할 때, 라이센싱 서버는 라이센스 상태 응답이 라이센싱 서버에 의해 실제로 생성되었다는 것을 확인하는데 사용될 수 있는 개인키(private key)를 사용하여 라이센스 상태 응답을 서명할 수 있다. 이 개인키는 애플리케이션 또는 퍼블리셔들의 계정과 고유하게 관련된 공용/개인 키 쌍(public/private key pair)의 일부일 수 있다. 애플리케이션은 자신의 컴파일된 바이너리에 상응하는 개인키를 포함할 수 있고, 라이센스 상태 응답의 무결성(integrity)을 검증하기 위하여 공용/개인 키 쌍을 사용할 수 있다.

퍼블리셔들이 애플리케이션에 라이센싱 능력들을 통합시키도록 지원하기 위해, 라이센싱 서비스를 운영하거나 그 라이센싱 서비스로의 액세스를 제공하는 신뢰할 수 있는 기관(예컨대, 앱 스토어를 운영하고 있는 같은 기관)이 애플리케이션에 내장(embed)될 수 있는 코드 라이브러리(code library)를 제공할 수 있다. 본 명세서에 LVL(License Verification Library)로 설명되는 코드 라이브러리는 사용자의 클라이언트 디바이스상에서 동작하는 마켓플레이스 클라이언트와의 라이센싱-관련 통신을 처리할 수 있고, 결국 마켓플레이스 클라이언트는 원격 라이센싱 서버상에 동작하는 라이센싱 서비스와 통신할 수 있다. 내장된 LVL을 사용하여, 애플리케이션은 라이센싱 체커 메소드를 호출하고, 원격 라이센싱 서버로부터의 서명된 응답으로 라이센스 상태를 수신하는 콜백을 구현함으로써 자신의 현재 라이센스 상태를 판단할 수 있다.

도 1은 소프트웨어 애플리케이션들을 배포하고, 애플리케이션들 각각의 라이센스 상태를 체크하기 위한 시스템(100)의 개념도이다. 이 시스템에서, 클라이언트 디바이스(102)는 예컨대, 앱 스토어와 같은 애플리케이션 마켓(106)을 운영하는 서버(104)와 통신한다. 이러한 통신은 임의의 적절한 네트워크(예컨대, 인터넷, LAN, WAN, 무선 브로드밴드, 또는 그것들의 임의 조합)를 통해 행해질 수 있다. 클라이언트 디바이스(102)가 스마트폰으로 묘사되었지만, 다른 유형의 클라이언트 디바이스들(예컨대, 데이스탑 컴퓨터, 랩탑 컴퓨터, 넷북, 태블렛, 셋-탑 박스 등)도 서버(104)와 통신할 수 있다. 마찬가지로, 서버(104)는 독립형(stand-alone) 서버로 묘사되어 있지만, 서버(104)는 서버들의 클러스터, 서버 팜, 또는 애플리케이션 마켓(106)을 운영하는데 사용되는 서버들의 다른 그룹들을 나타낼 수 있다. 일부 구현예들에서, 서버(104)는 본 명세서에서 설명된 라이센싱 서비스들을 제공하는 신뢰할 수 있는 기관에 의해 운영될 수 있다.

클라이언트 디바이스(102)는 디바이스에 다양한 유형의 기능들을 제공하는 임의 갯수의 소프트웨어 애플리케이션, 또는 앱들을 실행하도록 구성될 수 있다. 앱의 한 유형은 애플리케이션 마켓(106)과의 연결 및 상호동작을 제공하는 마켓플레이스 클라이언트 앱일 수 있다. 마켓플레이스 클라이언트 앱은 신뢰할 수 있는 기관에 연관될 수 있고, 애플리케이션 마켓(106)에 액세스하기 위한 목적으로 신뢰할 수 있는 기관에 의해 제공될 수 있다. 마켓플레이스 클라이언트 앱을 사용하여, 클라이언트 디바이스(102)의 사용자는 애플리케이션 마켓(106)을 브라우징하거나 애플리케이션 마켓(106)을 통해 퍼블리시되어 있는 특정 앱들을 탐색할 수 있다.

일반적인 마켓플레이스 거래에서, 사용자는 예컨대 애플리케이션 마켓(106)을 탐색하거나 브라우징함으로써, 관심있는 앱을 식별할 수 있다. 화살표 A로 도시되어 있는 것처럼, 클라이언트 디바이스(102)는 예컨대, 디바이스에서 실행중인 마켓플레이스 클라이언트 앱으로부터의 애플리케이션 구매 요청(108)을 애플리케이션 마켓(106)에 전송할 수 있다. 애플리케이션 마켓(106)은 예컨대, 사용자에게 앱 사용 요금을 청구하고 그 구매를 기록(document)함으로써(예컨대, 거래의 전자 기록을 생성함으로써) 그 거래를 처리할 수 있다. 거래에 대한 전자 레코드는 애플리케이션을 구매한 사용자가 그 애플리케이션의 라이센스 받은 사용자인지를 검증하기 위해 나중에 사용될 수 있다. 이어, 애플리케이션 마켓(106)은 화살표 B로 도시된 것처럼, 요청된 애플리케이션 바이너리들(110)을 클라이언트(102)에 배달할 수 있다.

상술된 바와 같이, 클라이언트 디바이스(102)의 사용자는 또한 불법 채널을 통해 애플리케이션 바이너리들(110)을 획득할 수도 있다. 예를 들어, 애플리케이션 바이너리들(application binaries; 110)은 소프트웨어 퍼블리셔들에 의해 카피 및/또는 재배포하는 것에 대해 인증되지 않은 사용자들에 의해 카피 및/또는 재배포될 수 있다. 이러한 경우, 소프트웨어 퍼블리셔는 자신의 앱들의 라이센스 되지 않은 사용을 컨트롤하기가 다소 어려울 수 있다.

이런 이유로, 여기에서 설명된 기술들에 따르면, 소프트웨어 퍼블리셔는 앱의 특정 카피본을 그 앱을 실행시키려고 시도하는 사용자에 의해 적절하게 라이센싱되었는지 여부를 판단하기 위해 라이센스 상태 체크 시스템을 사용할 수 있다. 예를 들어, 그 앱을 실행시키려고 시도하는 사용자가 애플리케이션 마켓(106)을 통해 해당 앱을 구매하지 않았으면, 해당 앱은 그 사용자에 대해 라이센스 되지 않은 것으로 간주될 수 있다. 라이센스 상태 체크 시스템은 또한 또는 대안적으로 특정 디바이스가 앱을 실행하기 위해 라이센싱되었는지 여부를 판단하기 위해 사용될 수도 있다. 예를 들어, 소프트웨어 퍼블리셔는 앱의 라이센스를 특정 디바이스에 연결지어 놓아서, 복수의 디바이스를 소지한 사용자가 실제로 라이센싱된 하나 이상의 디바이스에서만 그 앱을 사용하도록 허용할 수 있다. 대안적으로, 디바이스는 로그인되는 계정에 연결지어질 수 있고, 라이센스가 그 계정에 연관될 수 있게 하여, 특정 사용자는 복수의 디바이스에서 앱을 실행시킬 수 있지만, 그 사용자외의 다른 사람은 디바이스들 상에서 동일한 앱을 실행할 수 없게 할 수 있다(그들이 제1 사용자로서 로그인되어 있거나, 다른 계정이 또한 앱을 사용하기 위해 라이센스 되지 않는 경우는 제외함).

아래에서 보다 자세하게 설명될 것처럼, 여기에서 설명되는 라이센스 상태 체크 시스템을 이용하는 애플리케이션은, 화살표 C로 도시된 것처럼, 라이센싱 체크 요청(112)을 라이센싱 체커 서비스(116)를 제공하는 서버(104)로 전송한다. 일 예시로서, 애플리케이션이, 라이센스 체크 요청(112)으로 하여금 애플리케이션이 개시(launch)하는 즉시 발행되도록 하는 명령어들을 포함할 수 있다. 일부 구현예들에서, 애플리케이션 스스로는 서버(104)와 직접 통신하지 않을 수 있고, 대신에 클라이언트 디바이스(102)에서 실행중인 마켓플레이스 클라이언트와 통신할 수 있다. 마켓플레이스 클라이언트는 애플리케이션 마켓(206)과 연관될 수 있고, 애플리케이션 마켓(206)으로의 액세스를 제공할 수 있다. 마켓플레이스 클라이언트는 라이센스 체크 요청(112)을 라이센스 체커 서비스(116)에 전송하고, 라이센스 체커 서비스(116)로부터 전송되는 임의 응답을 수신하도록 구성될 수 있다. 따라서 마켓플레이스 클라이언트는 디바이스상에 복수의 앱들 각각에 대한 라이센스 상태의 체크를 용이하게 하는 역할을 할 수 있으며, 애플리케이션 중 하나가 실행될 때마다 또는 각각의 앱에 의해 결정된 다른 적절한 시간에 호출될 수 있다.

라이센스 체크 요청(112)은 임의의 적절한 네트워크(예컨대, 인터넷, LAN, WAN, 무선 브로드밴드, 또는 이것들의 임의 조합)을 통해 서버(104)에 전달될 수 있다. 서버(104)는 애플리케이션 마켓(106)과 라이센스 체커 서비스(116) 모두를 운영하는 것으로 묘사되었지만, 애플리케이션 마켓(106)과 라이센스 체커 서비스(116)의 기능이 다른 서버들상에서 운영될 수도 있다는 것이 이해되어야만 한다. 더욱이, 애플리케이션 마켓(106)과 라이센스 체커 서비스(116) 각각의 기능은 더 분할되어, 적절한 수의 다른 서버들상에서 예컨대, 추가 네트워크 디바이스 전체에 대해 네트워크 트래픽 부하를 분산시키기 위해, 운영될 수도 있다.

라이센스 체크 요청(112)은 라이센스 체커 서비스(116)가 애플리케이션이 애플리케이션을 실행시키려고 시도하는 현재 사용자 또는 디바이스에 대해 적합하게 라이센싱되었는지 여부를 판단할 수 있게 하는 다양한 유형의 데이터를 포함할 수 있다. 예를 들어, 라이센스 체크 요청(112)은 사용자가 실행시키려고 시도하는 특정 애플리케이션을 특정하는 애플리케이션 식별자(예컨대, 패키지명)를 포함할 수 있다. 라이센스 체크 요청(112)은 또한 애플리케이션이 추후 라이센스 체커 서비스(116)로부터 수신한 임의 응답을 검증하는데 사용할 수 있는 랜덤 번호, 또는 논스(nonce)를 포함할 수도 있다.

이러한 유형의 데이터와 다른 애플리케이션-특정 정보 모두는 애플리케이션 스스로에 의해 식별되거나 생성될 수 있다. 그러나 일부 경우, 애플리케이션은 애플리케이션이 특정 사용자 또는 디바이스에 대해 적절하게 라이센싱되었는지 여부를 판단하는데 유용할 수 있는, 다른 유형의 데이터에 액세스할 충분한 허가(permission)를 가지지 않을 수 있다. 이런 이유로, 일부 구현예들에서, 애플리케이션은 논스, 애플리케이션 식별자, 및/또는 임의의 다른 관련 애플리케이션-특정 정보를 클라이언트 디바이스(102)상에서 실행중인 마켓플레이스 클라이언트에게 제공할 수 있고, 마켓플레이스 클라이언트는 라이센스 체크 요청(112)에 포함되어야 하는 사용자 및 디바이스에 대한 추가 정보를 수집할 수 있다. 일부 경우, 마켓플레이스 클라이언트는 애플리케이션보다 큰 허가를 가질 수 있고, 추가 디바이스-및/또는 사용자-특정 정보에 액세스할 수 있다. 예를 들어, 마켓플레이스 클라이언트는 디바이스의 사용자의 프라이머리(primary) 계정 사용자명, 디바이스와 연관된IMSI(International Mobile Subscriber Identity), 및 다른 디바이스-및/또는 사용자-특정 정보를 식별할 수 있다.

일부 구현예들에서, 애플리케이션은 라이센스 체크를 개시하기 위해, 예를 들어, 원격 IPC(Inter-Process Communication)를 통해 마켓플레이스 클라이언트를 호출할 수 있고, 마켓플레이스 클라이언트는 라이센스 체크 요청(112)에 포함된 추가 정보를 모을 수 있다. 마켓플레이스 클라이언트는 이어 라이센스 체크 요청(112)을 애플리케이션을 대신하는 라이센스 체커 서비스(116)에 전송할 수 있는데, 라이센스 체크 요청(112)은 애플리케이션 또는 마켓플레이스 클라이언트에 의해 모아진 정보의 조합을 포함할 수 있다. 상술된 구현예에서, 네트워크 연결 및 라이센싱-관련 APIs는 애플리케이션 대신 마켓플레이스 클라이언트에 의해 관리될 수 있다. 이러한 구현예들에서, 애플리케이션 스스로는 라이센스 서버로의 네트워크 연결들을 관리할 필요가 없거나 특정 라이센싱-관련 APIs를 알고 있을 필요가 없으며, 이로써 애플리케이션 코드는 보다 특별하게 설계된 특정 기능에 대해 더욱 특별하게 집중할 수 있다(따라서 퍼블리셔를 위해서는 개발을 간단하게 하고, 애플리케이션의 사이즈를 줄일 수도 있는데, 이는 복수의 애플리케이션이 이 부담(burden)을 완화시키고, 그 부담이 단일 라이센스 체크 시스템을 대신하여 부담지어질 때에 관련될 수 있음).

라이센스 체크 요청(112)이 수신되는 즉시, 라이센스 체커 서비스(116)는 사용자의 아이덴티티가 그 요청에 있는 정보로부터 특정 레벨의 신뢰도를 확립할 수 있는지 여부를 판단하기 위해 상기 요청을 평가할 수 있다. 일부 구현예들에서, 사용자가 특정 레벨의 신뢰도(예컨대, 80% 확률)로 식별될 수 있다면, 라이센스 체킹이 후술되는 것과 같이 계속될 수 있지만, 신뢰도 레벨이 임계보다 낮으면, 라이센스 체킹이 종료되거나, 및/또는 프로그램적 응답을 제공할 수 있게 하기 위해, 신뢰 임계(confidence threshold)를 사용할 수 있다. 도달되지 않은 임계 신뢰도 레벨에 대한 프로그램적 응답의 예시는 오류 코드를 생성하는 것, 또는 응답으로 기본(default) 라이센스 상태(예컨대, "라이센스 되지 않음(unlicensed)")를 전송하는 것을 포함할 수 있다.

신뢰도 레벨은 상기 요청에 있는 정보에 직접적 또는 간접적으로 상응하는 인자들에 기초할 수 있다. 예를 들어, 디바이스에 연관된 사용자 이름은 사용자를 식별하기 위한 직접 인자이지만, 지리적 식별자(예컨대, IP 주소, 디바이스로부터 읽혀진 GPS, 또는 셀 타워 또는 다른 액세스 포인트 위치들에 의해 정해지는 디바이스의 현재 지리적 위치)는 간접 인자로 고려될 수 있다. 다른 사용자 식별 인자들이 다양한 구현예들에서 동등하게 또는 동등하지 않게 가중될 수 있다. 예를 들어, 모든 인자들이 동일하게 가중되어 있는 예시의 경우에는, 애플리케이션의 사용자가 특정 사람이라고 시사(suggest)하는 5인자 중 4개로, 시스템은 사용자가 그 사람이라는 80% 신뢰도를 가질 수 있다. 다른 예시들에서, 다른 인자들이 예를 들어, 사용자의 아이덴티티를 판단하는데 그 인자가 얼마나 상관되는지에 따라서, 다르게 가중될 수 있다.

일부 구현예들에서, 요청은 클라이언트 디바이스의 진짜로 확인된(authenticated) 사용자에 연관되는 토큰(token)을 포함할 수 있다. 예를 들어, 사용자와 연관된 정보는 라이센싱 서비스 또는 3자 확인 서버스(third-party authenticatation service) 중 하나에 의해 진짜임이 확인될 수 있고, 이러한 진실성(authenticity)은 토큰 형태로 표현될 수 있다. 토큰은 클라이언트 디바이스상에 저장될 수 있고, 라이센스 체크 요청에 포함되기 위해, 애플리케이션 또는 마켓플레이스 클라이언트 중 하나에 의해 액세스될 수 있다. 이러한 토큰의 내용물(inclusion)은 사용자 아이덴티티의 강한 직접 표시자로 고려될 수 있고, 따라서 다른 직접 또는 간접 표시자들과의 관련에 큰 값으로 가중될 수 있다. 일부 구현예들에서, 이러한 토큰의 내용물은 사용자 아이덴티티의 결정 요인(determinative)으로 고려될 수 있다.

라이센스 체커 서비스(116)가 사용자의 아이덴티티를 충분한 레벨의 신뢰도를 갖는 것으로 판단할 수 있으면, 사용자의 아이덴티티는 애플리케이션을 위한 구매 레코드들에 대해 체크될 수 있고, 라이센스 체커 서비스(116)는 라이센스 체크 요청(118)을 리턴할 수 있는데, 이어 마켓플레이스 클라이언트는 IPC 콜백을 통해 애플리케이션에 리턴할 수 있다. 예를 들어, 만약 식별된 사용자가 구매 레코드에 있는 사용자와 매치하면, 라이센스 체커 서비스(116)는 "라이센싱됨(licensed)" 응답을 리턴할 수 있다. 그렇지 않으면, "라이센스 되지 않음" 응답이 리턴될 수 있다. 일부 구현예들에서, 라이센스 체커 서비스(116)는 대안적 또는 추가적으로 디바이스-특정 정보에 기초하여 상기 요청을 평가할 수 있고, 애플리케이션이 특정 디바이스에 대해 적절하게 라이센싱되었는지 여부를 판단하기 위해 구매 레코드들에 대해 디바이스 아이덴티티를 체크할 수 있다.

라이센스 체크 응답(118)의 무결성을 보장하기 위해, 그 응답은 개인키를 사용하여 라이센스 체커 서비스(116)에 의해 서명되거나 암호화될 수 있다. 개인키는 퍼블리셔 개정 또는 애플리케이션에 대해 특정될 수 있고, 소프트웨어 퍼블리셔에 의해 발행 또는 생성될 수 있는 공용키/개인키 쌍의 일부일 수 있다. 이 키 쌍이 퍼블리셔에 의해 생성되는 구현예에서는, 퍼블리셔는 라이센스 체크 응답을 서명하는데 사용하기 위해 그 개인키를 라이센스 서버에 업로드할 수 있다.

일부 구현예들에서, 신뢰할 수 있는 기관은 각 퍼블리셔 계정에 대해 라이센싱 키 쌍을 생성할 수 있고, 퍼블리셔 계정의 프로파일 페이지에 그 공용키를 노출시킬 수 있다. 이어, 퍼블리셔는 그 공용키와 애플리케이션 소스 코드에 내장된 공용키를 카피하며, 공용키는 애플리케이션 패키지 내에 컴파일될 수 있다. 개인키는 신뢰할 수 있는 기관에 의해 유지될 수 있으며, 그 기관은 연관된 퍼블리셔 계정에 의해 퍼블리시된 애플리케이션들에 대한 라이센스 응답을 서명하기 위해 그 개인키를 사용할 수 있다. 예를 들어, 라이센스 체크 요청이 수신될 때, 라이센스 체커 서비스(116)는 애플리케이션의 라이센스 상태가 요청되었는지 여부를 판단할 수 있고, 그 라이센스 응답을 서명하는데 사용하기 위해 그 특정 애플리케이션에 연관된 개인 키를 식별할 수 있다.

이어, 라이센스 체커 서비스(116)는 라이센스 체크 요청(118)을 서명할 수 있고, 클라이언트 디바이스(102)에 그 응답을 전송할 수 있다. 이어, 서명된 라이센스 응답은 애플리케이션 패키지에 포함되는 공용키를 사용하여 애플리케이션에 의해 암호 해제될 수 있다. 이 방식으로 공용/개시 키 쌍을 사용하여, 애플리케이션이 라이센스 체크 요청(118)이 변조(tamper)되거나 또는 위조(spoof)되었는지 여부를 검출하도록 함으로써, 라이센스 상태 체크 쿼리 절차의 무결성을 보장한다.

유효한 라이센스 체크 응답(118)(예를 들어, 위조되지 않은 라이센스 체크 응답)이 수신되는 즉시, 애플리케이션은 응답의 내용에 기초하여 임의의 적절한 액션을 취할 수 있다. 이러한 액션들은 애플리케이션이 특정 응답을 수신했을 때, 어떻게 반응할지를 제어하는 정책(policy)에 컴파일될 수 있다. 예를 들어, 그 응답이 사용자가 그 애플리케이션을 사용하기 위해 적절하게 라이센싱되었다는 것을 나타내면, 애플리케이션은 통상과 같은 실행을 계속하도록 프로그램될 수 있다. 반면에, 그 응답이 사용자가 애플리케이션을 사용하기 위해 라이센스 되지 않았다는 것을 나타내면, 애플리케이션은 다르게 프로그램된 응답(예컨대, 애플리케이션의 비인증된 사용이 금지되어 있다는 것을 사용자에게 알리고, 사용자가 라이센스를 획득할 수 있게 하는 링크 또는 다른 메카니즘을 제공함)을 수행할 수 있다. 또한, 애플리케이션이 스스로 강제 종료되어, 애플리케이션의 모든 추가 사용을 방지할 수 있다.

일부 경우에, 정책은 또한 예컨대, 서버 오류에 기인하여 애플리케이션이 검증되지 않은 응답을 수신했을 때, 또는 예컨대, 디바이스가 오프라인이여서, 애플리케이션이 아무런 응답을 수신하지 않을 때, 애플리케이션이 어떻게 반응해야 하는지를 제어할 수 있다. 이러한 경우, 정책은 과거 라이센스 체크 응답에 기초하여 적절한 액션을 결정할 수 있다. 예를 들어, 애플리케이션이 이전에 10개의 라이센스 체크 요청들을 발행하였고, 사용자 및/또는 디바이스가 그 애플리케이션을 사용하기 위해 라이센싱되었다는 것을 나타내는 10개의 라이센스 체크 응답을 수신하였으면, 정책은 검증되지 않은 응답 또는 이상(anomaly)으로 응답 부족을 무시할 수 있고, 애플리케이션은 통상적인 실행을 계속할 수 있도록 허용될 수 있다. 마찬가지로, 애플리케이션이 사용자 및/또는 디바이스가 그 애플리케이션을 사용하기 위해 라이센스 되지 않았다는 것을 나타내는 10개의 라이센스 체크 응답을 수신하였다면, 정책은 애플리케이션의 추가 실행이 불가능할 수 있다.

다른 맞춤형 제약(customized constraint)들도 또한 또는 대안적으로 정책에 포함될 수 있다. 예를 들어, 응답이 애플리케이션이 적합하게 라이센스되지 않았다는 것을 나타낼 때, 애플리케이션은 실행을 계속할 수 있지만, 라이센스 되지 않은 사용자에게 제한된 기능(예컨대, 라이센스 받은 사용자들만 이용할 수 있는 특징들을 이용할 수 없게 함으로써)만을 제공할 수 있다. 따라서 애플리케이션은 사용자에게 전체-기능 프리미엄 모드(full-featured premium mode)로 업그레이드하기 위한 액션들을 행할 수 있는 기회를 제공하는, "프리미엄(freemium)" 배포 모델의 무료 모드와 같은 것을 운영할 수 있다. 다른 예시로서, 애플리케이션은 완전하게 또는 부분적으로 이용할 수 없게 하기 전에, 특정 수의 라이센스 되지 않은 사용(예컨대, 사용자가 애플리케이션이 구매할만한 가치가 있는지 여부를 테스트하도록)을 허용할 수 있다. 다른 경우에, 애플리케이션은 그 애플리케이션이 라이센스 되지 않았더라도, 기능의 전부 또는 일부를 사용할 수 있게 하는 시험 기간(trial period)(예컨대, 7일)을 제공할 수 있다. 이러한 및 다른 유형의 제약들은 퍼블리셔가 적절하다고 생각하는 어떤 방식으로든, 라이센스 체크 응답으로 리턴되는 라이센스 상태를 처리할 수 있는 소프트웨어 퍼블리셔에 의해 확립될 수 있다.

일부 구현예들에서, 디바이스상에서 실행중인 운영 체계는 대안적으로 또는 선택적으로 라이센스 체커 서비스(116)로부터 전송된 라이센스 체크 응답을 수신하고 그 라이센스 체크 응답에 반응하도록 구성될 수 있다. 이러한 구현예들에서는, 운영 체계가 유효 라이센스 체크 응답(118)을 수신하는 즉시, 적절한 액션들을 개시할 수 있는데, 이는 상술된 바와 같이 애플리케이션이 반응하는 방식과 유사하다. 예를 들어, 애플리케이션이 클라이언트 디바이스에서의 사용에 대해 라이센스 되지 않았다는 것을 나타내는 라이센스 체크 요청(118)을 수신하는 즉시, 운영 체계는 그 애플리케이션을 종료할 수 있다.

도 2는 소프트웨어 애플리케이션의 라이센스 상태를 체크하기 위한 다층 시스템(multi-tiered system)의 개념도이다. 시스템(200)에서, 마이앱(205)으로 명명된 앱과 마켓플레이스 클라이언트(210)는 클라이언트 디바이스에 상주하여 실행한다. 마켓플레이스 클라이언트(210)는 클라이언트 디바이스에서 구동중인 마이앱(205)의 라이센스 상태를 판단하기 위해, 클라이언트 디바이스로부터 원격적으로 실행하는 라이센싱 서버(215)와 통신하도록 구성될 수 있다. 마이앱(205)의 라이센스 상태를 체크하기 위해, 애플리케이션은 라이센스 체크 요청을 원격 IPC(240)를 통해 마켓플레이스 클라이언트(210)로 전달하고, 결국 마켓플레이스 클라이언트(210)는 라이센싱 서버(215)에 마이앱(205)의 라이센스 상태를 쿼리할 수 있다.

마이앱(205)은 예컨대, LVL(220)과 같은 라이센싱 라이브러리, 메인 액티비티 모듈(225), 및 공용키(230)를 포함시키기 위해 소프트웨어 퍼블리셔에 의해 컴파일될 수 있다. 일반적으로, LVL(220)은 여기에서 설명된 것처럼 다양한 라이센싱 체크 기술들을 실행하기 위해 이용될 수 있고, 메인 액티비티 모듈(225)은 앱의 프라이머리 기능에 관련된 명령어들을 포함할 수 있고, 공용키(230)는 라이센싱 서버(215)로부터의 마이앱(205)에 의해 수신되는 라이센스 응답을 검증하기 위해 사용될 수 있다. 일부 구현예들에서, 소프트웨어 퍼블리셔들은 비도덕적인 사용자들이 애플리케이션 또는 LVL을 바꾸거나 또는 변조하는 것을 더 어렵게 할 수는, 애플리케이션의 불명료화(obfuscation) 또는 바이너리 패키지들을 수행할 수 있다.

LVL(220)은 라이센싱 서비스를 운영하는 신뢰할 수 있는 기관에 의해 개발되고 유지관리될 수 있으며, 자신의 애플리케이션들 내에 라이센스 체킹의 구현을 간단하게 하기 위해, 소프트웨어 퍼블리셔들에게 제공될 수 있다. LVL(220)은 라이센싱 상태 쿼리 동안 수행된 기능의 모두 또는 일부를 처리(예컨대, 라이센스 상태 요청들을 개시하기 위해 마켓플레이스 클라이언트(210)에 접촉하고, 상기 라이센스 상태 요청들에 대한 임의 응답을 검증하고 승인함)하는 내부 클래스들을 포함할 수 있다. LVL(220)은 또한 소프트웨어 퍼블리셔들이, 적절한 라이센싱 정책들을 정의하고 라이센스 상태 요청들에 대한 응답에 기초하여 애플리케이션으로의 액세스 컨트롤을 관리하는, 맞춤형 코드(customized code)를 삽입할 수 있게 하는 하나 이상의 인터페이스를 노출시킬 수 있다.

일부 구현예들에서, LVL(220)은 애플리케이션의 현재 라이센스 상태에 대한 요청들을 용이하게 하는 API를 포함할 수 있다. API에 대한 호출은 하나 이상의 파라미터들을 수용할 수 있다. 예를 들어, API 호출은 애플리케이션에 의해 생성된 랜덤 번호를 수용할 수 있는데, 이 랜덤 번호는 임의의 리턴된 라이센스 응답을 승인하는데 사용될 수 있다. API 호출은 또한 애플리케이션 마켓으로부터 목록(manifest)에 정의되는 것과 같은 애플리케이션 패키지명과 같은 애플리케이션 식별자 파라미터를 수용할 수 있는데, 이 애플리케이션 식별자 파라미터는 라이센싱 서비스가 애플리케이션을 식별할 수 있게 한다. API 호출은 또한 상기 목록에 정의된 것과 같은 애플리케이션 버전 코드 파라미터를 수용할 수 있다. API는 또한 라이센싱 서버(215)로부터의 비동기 응답을 처리하는 대표 기능을 제공할 수 있는 콜백 함수(callback function)를 수신할 수 있다.

메인 액티비티 모듈(225)은 애플리케이션의 프라이머리 기능에 관련된 명령어들을 포함할 수 있고, LVL(220)에 대한 하나 이상의 호출을 포함할 수 있다. 예를 들어, 앱의 기동준비(startup) 동안, 메인 액티비티 모듈(225)은 라이센스 상태 요청로 하여금 실행되게 하기 위해, LVL(220)에 대한 얼리 콜(early call)을 포함할 수 있다. 메인 액티비티 모듈(225)은 또한 또는 대안적으로 기동준비가 아닌 특정 실행 지점들에서의 라이센스 상태 요청을 실행하기 위하여 LVL(220)에 대한 다른 호출을 포함할 수 있다. 예를 들어, 특정 게임 애플리케이션은 라이센스 되지 않은 사용자들로 하여금 그 게임의 처음 3개 레벨까지는 플레이할 수게 하지만, 그 이후 레벨로 진행하기 위해서는 라이센스를 요청할 수 있다. 이러한 경우, 메인 액티비티 모듈(225)은 사용자가 처음 3개 레벨을 지난 임의 레벨에 액세스하려고 시도할 때, LVL(220)에 대한 호출을 포함할 수 있다.

라이센싱 서버(215)는 예컨대, 마이앱(205)과 같은 애플리케이션이 그 애플리케이션을 실행시키려고 시도하는 사용자 또는 디바이스에 대해 라이센스 되었는지 여부를 판단하기 위하여 신뢰할 수 있는 라이센싱 서버로서 동작할 수 있다. 상술한 바와 같이, 마이앱(205)은 라이센싱 서버로부터의 라이센스 상태 응답에 기초하여, 애플리케이션의 추가 사용을 허용 또는 불허용(disallow)하는 로직을 포함하거나, 애플리케이션의 퍼블리셔들에 의해 특정된 방식으로 그 응답을 처리하는 다른 로직을 포함할 수 있다. 이런 이유로, 라이센싱 서버(215)의 역할은 사용자에 대한 라이센스 상태를 제공하는 것일 수 있지만, 애플리케이션 스스로는 서버를 쿼리하고 애플리케이션으로의 액세스를 조건적으로 허락하는 역할을 수행한다.

라이센싱 서버(215)는 여기에서 설명된 라이센싱 기능들에 관련된 다양한 정보를 유지관리할 수 있다. 예를 들어, 라이센싱 서버(215)는 정보를 포함할 수 있는데, 그 정보의 예로는 애플리케이션 마켓플레이스에서 소프트웨어 애플리케이션들을 퍼블리시하는 다양한 퍼블리셔들에 관련된 퍼블리셔 데이터(245), 애플리케이션 마켓플레이스에 제공된 소프트웨어 애플리케이션들에 상응하는 앱 리스팅 데이터(250), 및 애플리케이션 마켓플레이스를 통해 판매된 애플리케이션들 또는 다른 제품들에 관련된 거래들을 설명하는 구매 레코드들 데이터(255)가 있다. 라이센싱 서버(215)가 적절한 개인키(235)로 응답을 서명할 수 있게 하기 위해, 퍼블리셔 데이터(245)와 앱 리스팅 데이터(250)는 예를 들어, 라이센스 체크를 요청하는 애플리케이션에 퍼블리셔를 링크시키는데 사용될 수 있다.

일부 구현예들에서, 사용자(예컨대, 시스템에 등록된 사용자 계정을 통해)가 애플리케이션을 구매했던 것으로 기록되어 있거나, 또는 애플리케이션이 무료로 사용할 수 있으면, 라이센싱 서버(215)는 사용자가 라이센싱된 것으로 여길 수 있다. 사용자를 적합하게 식별하고, 라이센스 상태를 판단하기 위해, 서버는 라이센스 상태 요청의 형태로 마켓플레이스 클라이언트(210)로부터의 애플리케이션 및 사용자에 대한 정보를 수신할 수 있다. 예를 들어, 라이센스가 특정 사용자 대신에 디바이스에 연결되어 있는 구현예에서는, 라이센스 상태 요청이 그 애플리케이션을 실행시키려고 시도하는 디바이스에 대한 정보를 추가적 또는 대안적으로 포함할 수 있다. 이러한 애플리케이션-, 사용자-, 및/또는 디바이스-특정 정보는 애플리케이션, 마켓플레이스 클라이언트(210), 또는 이 둘의 조합에 의해 모아질 수 있다. 이어, 이 정보는 애플리케이션을 실행시키려고 시도하는 특정 사용자 또는 디바이스를 식별하기 위해 사용될 수 있고, 그 정보는 그 애플리케이션이 식별된 사용자 또는 디바이스에 의해 또는 사용자 또는 디바이스를 위해 애플리케이션 마켓플레이스를 통해 구매되었는지 여부를 판단하기 위해, 구매 레코드들 데이터(255)와 비교될 수 있다.

도시된 구현예에 따르면, 마이앱(205)이 직접적으로 라이센싱 서버(215)를 쿼리하지 않지만, 그 대신 라이센스 요청을 개시하기 위해 원격 IPC(240)를 통해 마켓플레이스 클라이언트(210)를 호출한다. 다른 구현예들에서, 애플리케이션은 예컨대, LVL(220)에, 애플리케이션이 직접적으로 라이센싱 서버(215)를 쿼리할 수 있게 하는 로직을 포함할 수 있다. 라이센스 요청은 라이센싱 서버(215)가 애플리케이션의 라이센스 상태를 판단할 수 있게 하는, 다양한 유형의 애플리케이션-특정, 사용자-특정, 및/또는 디바이스-특정 정보를 포함할 수 있다. 예를 들어, 마이앱(205)은 마켓플레이스 클라이언트(210)에 대한 원격 IPC 호출에 자신의 패키지명과 논스를 전달할 수 있다. 마이앱(205)은 마켓플레이스 클라이언트(210)로부터 마이앱(205)에 대해 비동기적으로 리턴될 수 있는 라이센싱 서버(215)로부터의 응답을 통해 콜백을 발행할 수 있다.

일부 구현예들에서, 마켓플레이스 클라이언트(210)는 마이앱(205)에 대한 허가보다 더 큰 허가들을 가질 수 있고, 따라서 사용자 및/또는 디바이스에 대한 추가 정보(예컨대, 디바이스의 프라이머리 계정 사용자명, IMSI, 및 다른 정보)를 수집할 수 있다. 이어, 마켓플레이스 클라이언트(210)는 마이앱(205)를 대신하여 라이센싱 서버(215)에 라이센싱 체크 요청을 전송할 수 있다.

라이센스 체크 요청을 수신하는 즉시, 라이센싱 서버(215)는 사용자의 및/또는 디바이스의 아이덴티티를 충분한 레벨의 신뢰도로 확립하기 위한 시도로, 사용자, 디바이스, 및 애플리케이션에 대한 임의의 적절한 가용 정보를 사용하여 상기 요청을 평가할 수 있다. 만약 사용자의 및/또는 디바이스의 아이덴티티가 확립될 수 있으면, 이어 라이센싱 서버(215)는 애플리케이션에 대한 구매 레코드들(255)에 대해 아이덴티티를 체크하여, 라이센스 응답을 리턴할 수 있으며, 이어 마켓플레이스 클라이언트(210)는 IPC 콜백을 통해 애플리케이션으로 리턴할 수 있다.

라이센스 쿼리들의 무결성을 보장하기 위해, 라이센싱 서버(215)는 개인키(235)를 사용하여 라이센스 응답 데이터를 서명할 수 있는데, 이 개인키는 서버와 애플리케이션 퍼블리셔 사이에서 공유될 수 있는 RSA 키 쌍의 일부일 수 있다. 일부 구현예에서, 라이센싱 서비스는 퍼블리셔 계정 각각에 대해 라이센싱 키 쌍을 생성할 수 있고, 계정의 프로파일 페이지에 그 공개키를 노출시킬 수 있다. 이어, 퍼블리셔는 상기 공개키와 애플리케이션 소스 코드 내에 내장된 공개키를 카피할 수 있다. 소스 코드가 컴파일되는 즉시, 공개키(230)는 애플리케이션 마켓플레이스상에서 퍼블리시될 수 있는 애플리케이션에 내장된다. 라이센싱 서버(215)는 개인키(235)를 내부적으로 유지하고, 그 계정에서 퍼블리시된 애플리케이션들에 대한 라이센스 응답들을 서명하기 위해 그 개인키를 사용할 수 있다.

애플리케이션이 개인키(235)로 서명되어진 응답을 수신하면, 데이터를 검증하기 위해 내장된 공용키(230)를 사용할 수 있다. 라이센싱 서비스에서의 공용키 암호방식 사용은 애플리케이션이 변조되거나 위조된 응답들을 검출할 수 있게 한다.

도 3은 예시적 라이센스 체크 및 응답을 나타내는 다이어그램이다. 상술된 라이센스 상태 체크 기술들의 이전 예시들에서는, 애플리케이션이 그 애플리케이션의 라이센스 상태를 확인하고자 했을 때는 언제든지, 애플리케이션은 마켓플레이스를 통해 라이센싱 서버를 쿼리하였다. 도 3에 도시된 바와 같이, 애플리케이션은 또한 라이센싱 시스템의 성능을 향상시키기 위해 캐싱 메카니즘을 사용할 수 있다. 이러한 구현예들은, 예를 들어 라이센싱 서버로의 액세스가 가능하지 않거나 편리하지 않은 경우에, 애플리케이션이 라이센스 상태를 요청할 때마다 사용될 수 있다. 예를 들어, 디바이스가 네크워크 연결을 가지고 있지 않거나 라이센싱 서버가 오프라인이여서, 디바이스가 라이센싱 서버와 통신할 수 없을 때, 캐싱이 사용될 수 있다. 이러한 예시에서, 애플리케이션은 캐쉬된 라이센스 상태 정보에 기초하여 기능하도록 여전히 허용될 수 있다.

도 2와 관련하여 상술된 바와 같이, 하나 이상의 라이센스 체크가 애플리케이션의 메인 액티비티 모듈(305)에 추가될 수 있다. 예를 들어, 애플리케이션은 애플리케이션의 onCreate() 메소드에 라이센스 체크를 포함하여, 사용자가 애플리케이션을 개시하였을 때, 라이센스 체크가 인보크되게 할 수 있다. 라이센스 체크들은 또한 다른 특정 실행 지점들에 추가될 수 있다. 예를 들어, 일부 구현예들은 다른 애플리케이션들이 실행할 수 있게 하는 다수의 액티비티 모듈을 포함할 수 있다. 이러한 경우, 라이센스 체크는 또한 애플리케이션이 사용자에 의해 직접적으로 개시되지 않았더라도, 그 애플리케이션이 적절하게 라이센싱되었다는 것을 보장하기 위해 애플리케이션의 액티비티 모듈에 포함될 수 있다.

라이센스 체크는 2개의 프라이머리 인터페이스-라이센스 체커 인터페이스(310)와 라이센스 체커 콜백 인터페이스(315)를 이용할 수 있다. 라이센스 체커 인터페이스(310)는 라이센스 체크를 개시하기 위한 메소드에 대한 호출을 포함할 수 있다. 예를 들어, LVL에서, 이것은 애플리케이션이 구성하는 LicenseChecker 객체의 checkAccess() 메소드에 대한 호출일 수 있다.

라이센스 체커 콜백 인터페이스(315)는 라이센스 체크에 대한 결과를 리턴하는 콜백을 포함할 수 있다. 인터페이스는 2개의 메소드, allow() 및 dontAllow()를 선언할 수 있는데, 이는 라이센스 체크에 대한 결과에 기초하여 LVL에 의해 인보크될 수 있다. 2개의 메소드는 그 애플리케이션에 대한 사용자 액세스의 허용 또는 불허용하기 위한 임의의 적절한 로직을 사용하여 구현될 수 있다. 추가 applicationError() 메소드는 또한 라이센스 체크 동안 던져진(throw) 임의의 애플리케이션 오류들을 처리하도록 선언될 수 있다.

다이어그램에 도시된 것처럼, 애플리케이션의 메인 애티비티 모듈(305)에 있는 코드는 라이센스 체커(310)와 라이센스 체커 콜백(315) 객체를 예시한다. 라이센스 체커(310)를 구성할 때, 코드는 애플리케이션 내용, 사용되어질 정책, 및 라이센싱을 위한 퍼블리셔의 공용키를 포함하는 파라미터들을 전달할 수 있다.

이어, 코드는 라이센스 체커(310)의 checkAccess() 메소드를 호출한다. 이 메소드는 로컬적으로 캐쉬된 유효 라이센스 응답이 있는지 여부를 판단하기 위해 정책(325)을 액세스할 수 있다(320). 만약 로컬적으로 캐쉬된 유효 라이센스 응답이 있으면, checkAccess() 메소드는 라이센스 체커 콜백(315)에 있는 allow() 메소드를 호출할 수 있다. 그러나 그렇지 않으면, 라이센스 체커(310)는 라이센싱 서버에 전송되는 라이센스 체크 요청을 개시할 수 있다.

응답이 라이센싱 서버로부터 수신될 때, 라이센스 체커(310)는 라이센스 승인자(330)를 생성하는데, 이 라이센스 승인자는 서명된 라이센스 데이터를 검증할 수 있고, 응답으로부터 다양한 정보를 추출할 수 있다. 정보는 라이센스가 사용자에게 유효한지를 판단하기 위해, 추가 평가를 위하여 정책으로 전달될 수 있다(335). 만약, 라이센스가 유효한 것으로 판단되면, 정책(325)은 그 응답을 캐쉬하고, 라이센스 체커 콜백(315)의 allow() 메소드를 호출할 수 있는 승인자(330)를 통지할 수 있다. 만약, 라이센서가 유효하지 않은 것으로 판단되면, 정책(325)은 승인자(330)에게 통지할 수 있고, 그 승인자는 라이센스 체커 콜백(315)의 dontAllow() 메소드를 호출할 수 있다. 일부 구현예들에서, 유효 또는 무효 중 한 라이센스 상태는 암호화되어 컴퓨팅 디바이스상에 로컬적으로 예컨대, 캐쉬에 저장될 수 있다. 애플리케이션 오류의 경우, 예컨대, 애플리케이션이 무효 패키지 게임의 라이센스를 체크하려고 시도할 때, 라이센서 체커(310)는 라이센스 체커 콜백의 applicationError() 메소드에 오류 응답을 전달할 수 있다.

상술된 바와 같이, 캐쉬된 라이센스 정보로, checkAccess() 메소드에 대한 후속 호출이 라이센싱 서버에 접촉하기 대신에 캐쉬된 라이센스 정보를 액세스할 수 있다. 일부 구현예들에서, 캐쉬된 라이센스 데이터는 정책(325)에 의해 정의되는 것과 같은 특정 상황에 이용될 수 있다. 예를 들어, checkAccess() 메소드가 호출되지만, 컴퓨터 디바이스가 라이센싱 서버와의 연결성이 없을 때,오류 메시지는 라이센싱 클라이언트에서 애플리케이션으로 리턴될 수 있다. 결국, 애플리케이션은 캐쉬된 라이센스 상태 정보를 검색할 수 있다.

일부 구현예들에서, 정책(325)은 오래된(stale) 라이센스 상태 정보들이 사용되지 못하게 하는 캐싱 타임아웃 정보를 포함할 수 있다. 예를 들어, 정책(325)은 특정 기간(예컨대, 1주일) 동안 저장된 캐쉬된 라이센스 상태 정보를 지울 수 있다. 다른 구현예들에서, 캐쉬된 라이센스 상태 정보는 더 오랜 기간 동안 유지될 수도 있지만, 정책(325)은 너무 오래된 캐쉬된 데이터를 무시할 수 있다. 캐쉬된 데이터가 너무 오래됐는지에 대한 판단은 그 캐쉬된 데이터가 액세스되는 이유에 따라 달라질 수 있다. 예를 들어, 네트워크 연결의 부재로 인해 액세스되는 캐쉬된 데이터는 최대 1주일 동안 유효한 것으로 여겨질 수 있지만, 시스템의 성능을 향상하기 위해 액세스되는 캐쉬된 데이터는, 예를 들어 최대 한시간 동안 또는 특정 사용자 세션(user session) 동안 유효한 것으로 여겨질 수 있다.

도 4는 소프트웨어 애플리케이션의 라이센스 상태를 요청하고 처리하기 위한 프로세스(400)의 스윔-레인 다이어그램이다. 프로세스(400)는 예를 들어, 도 2에 도시된 다층 시스템(200)에 의해 구현될 수 있다. 표시의 명료화를 위하여, 후술하는 설명은 프로세스(400)를 설명하는 근거로서 다층 시스템(200)을 사용한다. 그러나 다른 시스템 또는 시스템들의 조합도 프로세스를 수행하는데 사용될 수 있다.

일반적으로, 프로세스(400)는 클라이언트 디바이스상에서 실행중인 애플리케이션의 라이센스 상태를 검증하는데 사용될 수 있고, 그 애플리케이션이 실행하는 동안 임의 적절한 지점에서 호출될 수 있다. 애플리케이션은 예컨대, 자바(JAVA)의 소스 랜덤 기능을 사용함으로써, 보안 랜덤 번호 R을 생성할 수 있고(405), 추가 참조를 위한 그 값을 저장할 수 있다. 이어, 애플리케이션은 예컨대, 라이센스 검증 라이브러리에 있는 checkLicense() 메소드를 호출하고 R과 callbackFunction 파라미터들을 전달함으로써, 애플리케이션의 라이센스 상태를 체크하기 위한 호출을 개시할 수 있다(410). 추가적 또는 대안적 애플리케이션-특정 파라미터들이 또한 checkLicense() 메소드로 전달될 수 있다. 이어, checkLicense() 메소드는 예컨대, 인텐트(intent) 또는 바인더 또는 다른 적절한 메카니즘을 사용하여 클라이언트 디바이스상에 실행중인 마켓플레이이 클라이언트 애플리케이션을 호출할 수 있다.

마켓플레이스 클라이언트 애플리케이션은 인텐트를 수신할 수 있고(415), 사용자 및/또는 디바이스에 연관된 정보를 모으려고 시도할 수 있다(420). 예를 들어, 마켓플레이스 클라이언트 애플리케이션은 중앙 사인온 서비스 (central sign-on service) 사용자명, 폰 번호(MSISDN), IMSI, 모바일 디바이스 식별자, 또는 다른 적절한 사용자- 또는 디바이스-특정 정보를 식별할 수 있다. 이 정보는 아이덴티티 정보로 일컬어질 수도 있다. 일부 구현예에서, 아이덴티티 정보는 마켓 API 서버에 의해 신뢰되지 않을 수 있고, 그래서 사용자 또는 디바이스의 아이덴티티는 여전히 확실하지 않을 수 있다. 대신에, 이 정보는 사용자 또는 디바이스의 아이덴티티를 판단하려고 시도할 때, 마켓 API 서버가 사용할 수 있는 신호들로서 여겨질 수 있다.

마켓플레이스 클라이언트 애플리케이션은 R, 애플리케이션명, 및 아이덴티티 정보를 전달하면서, 예컨대, HTTPS를 통해 체크 라이센스 포스트(check license post)를 마켓 API 서버로 전송할 수 있다(425). 일부 구현예들에서, 프록시 서버들이 트랜스미션의 암호화되지 않은 부분에 MSISDN 정보를 부가하는데 사용될 수 있는데, MSISDN 정보는 마켓 API 서버에 의해 사용될 수 있는 더 많은 사용자 아이덴티티 신호들을 제공할 수 있다.

체크 라이센스 포스트를 수신하는 즉시, 마켓 API 서버는 그 포스트에 포함된 정보의 모두 또는 일부를 기록할 수 있는데, 이는 비도덕적인 사용자 아이덴티티 정보를 식별하는데 도움을 주기 위해 추후 사용될 수 있다. 시간이 지나면, 마켓 API 서버에 의해 수신된 많은 불규칙한 신호들은 가짜(fraud)를 식별하는데 사용될 수 있다. 예를 들어, 마켓 API 서버는 클라이언트 애플리케이션이 실행되고 있는 컴퓨터 디바이스들 사이의 연관성(association)들과 애플리케이션을 실행하고 있는 사용자들과 연관된 아이덴티티 정보를 유지관리할 수 있다. 마켓 API 서버는 또한 사용자가 그 애플리케이션을 실행시키고 있는 디바이스의 개수와 아이덴티티를 계속 추적할 수 있다. 일부 구현예들에서, 특정 사용자 아이덴티티가 가짜로 표시될 수 있는 다른 클라이언트 디바이스들상에서 특정 개수의 애플리케이션 실행과 연관된다면, 사용자 아이덴티티는 특정 애플리케이션에 대해 라이센스 받은 사용자로서 무효화될 수 있다. 다른 가짜-방지 메카니즘(fraud-prevention mechanism)들이 또한 마켓 API 서버에 의해 구현될 수 있고, 시간이 지나면 마켓 API 서버에서 수신된 아이덴티티 정보에 기초할 수 있다.

마켓 API 서버는 예컨대, 애플리케이션명이 그 사용자 아이덴티티 정보에 연관된 사용자에게 등록되었는지를 체크함으로써, 사용자 및/또는 디바이스가 그 애플리케이션을 사용하기에 유효한 라이센스를 가지고 있다는 것을 확인할 수 있다(430). 마켓 API 서버는 또한 사용자의 아이덴티티에 관련된 신뢰도 레벨을 확립할 수 있다(435). 예를 들어, 마켓 API 서버는 사용자가 자신이라고 주장하는 것에 대한 신뢰도 레벨을 판단하기 위해 이전에 수신된 포스트들로부터 저장된 데이터와 사용자 아이덴티티 정보를 분석할 수 있다.

애플리케이션이 사용자 아이덴티티 정보에 있는 사용자에게 등록되어 있고, 마켓 API 서버가 특정 레벨의 확률로, 그 사용자가 자신이라고 주장하는 것을 신뢰할 수 있으면, 마켓 API 서버는 리턴 메시지 "라이센싱됨"을 생성할 수 있다. 이 반대의 경우라면, 마켓 API 서버는 리턴 메시지 "라이센싱 되지 않음"을 생성할 수 있다. 이어, 리턴 메시지는 예를 들어, 애플리케이션명, R, 패키지명, 사용자와 연관된 시스템 ID, 및/또는 타임 스탬프(timestamp)를 포함하는 추가 정보와 조합될 수 있다. 마켓 API 서버는 퍼블리셔와 연관된 개인키를 사용하여 그 리턴 메시지와 임의 추가 정보를 서명할 수 있다(440).

이어, 서명된 데이터 또는 서명(signature)이 마켓플레이스 클라이언트로 리턴될 수 있고, 결국 마켓플레이스 클라이언트는 그 서명된 결과를 클라이언트 애플리케이션에 리턴할 수 있다(445). 예를 들어, 마켓플레이스 클라이언트는 클라이언트 애플리케이션에 서명된 결과를 리턴하기 위해 파라미터들로서 전달된 서명과 서명된 데이터로 콜백 함수를 호출할 수 있다.

이어, 클라이언트 애플리케이션은 인텐트 결과를 통해 서명된 결과를 수신할 수 있고(450), 공용키를 사용하여 그 서명된 결과를 암호 해제할 수 있다(455). 공용키는 애플리케이션이 컴파일될 때, 클라이언트 애플리케이션에 내장될 수 있고, 서명된 결과의 무결성을 검증하기 위해 사용될 수 있다. 또한, 클라이언트 애플리케이션은 서명된 데이터에 있는 리턴된 값들을 비교할 수 있다(460). 예를 들어, 애플리케이션은 리턴된 R이 프로세스를 시작할 때 생성된 랜덤 번호와 매치하는지를 검증하기 위해, 리턴된 R을 비교할 수 있다.

응답이 마켓 API 서버로부터의 유효 응답이라고 검증되는 즉시, 클라이언트 애플리케이션은 이어 라이센스 상태 결과에 대해 반응하는 방법(예컨대, 정책에 기초하여)을 결정할 수 있다. 예를 들어, 만약 리턴 메시지가 그 애플리케이션이 라이센싱되었다는 것을 나타내면, 애플리케이션은 모든 기능을 제공할 수 있고, 만약 리턴 메시지가 그 애플리케이션이 라이센스 되지 않았다는 것을 나타내면, 제한된 기능을 제공하거나 어떤 기능도 제공하지 않을 수 있다. 일부 구현예들에서, 클라이언트 애플리케이션은 그 애플리케이션과 연관된 정책에 기초하여 적절한 액션을 판단하기 위해, 그것의 자체 신호들과 함께 서명된 결과에 있는 정보를 사용할 수 있다.

도 5는 상술된 라이센스 상태 체크 시스템들과 프로세스들에 의해 이용될 수 있는 예시적 상태 코드들을 갖는 테이블들을 나타낸다. 테이블(500)은 클라이언트 애플리케이션에 대한 마켓플레이스 클라이언트로부터의 응답에 포함될 수 있는 예시적 상태 코드들을 나타낸다. 테이블(500)에 있는 상태 코드들은 클라이언트 애플리케이션에 의한 라이센스 상태 체크가 개시된 후에 발생된 오류와, 라이센싱 서버가 라이센스 상태 체크 요청을 수신한 적이 없기 때문에 마켓플레이스 클라이언트에 의해 서명되지 않고 리턴된 오류들을 모두 포함한다. 클라이언트 애플리케이션은 클라이언트 애플리케이션에 의해 정의된 정책에 따라서 이러한 또는 다른 상태 코드들을 처리하도록 구성될 수 있다.

테이블(500)은 라이센스 상태 체크 요청에 응답하여 라이센스 서버로부터의 클라이언트 애플리케이션에 리턴될 수 있는 예시적 상태 코드들을 나타낸다. 달리 언급이 없으면, 클라이언트 애플리케이션이 그 응답이 라이센스 서버로부터 왔다는 것을 검증할 수 있도록 하기 위해, 상기 코드들은 서명된다. 클라이언트 애플리케이션은 상술되어진 바와 같이, 클라이언트 애플리케이션에 의해 정의된 정책에 따라 이러한 또는 다른 상태 코드들을 처리하도록 구성될 수 있다.

도 6은 본 명세서에서 설명된 기술들에 사용될 수 있는 일반적인 컴퓨터 디바이스(600)와 일반적인 모바일 컴퓨터 디바이스(650)의 예시를 나타낸다. 컴퓨팅 시스템(600)은 랩탑, 데스크탑, 워크스테이션, PDA(Personal Digital Assistant), 서버, 블레이드(blade) 서버, 메인프레임, 및 그 밖의 적절한 컴퓨터들과 같은 다양한 형태의 디지털 컴퓨터를 나타내기 위해 사용된다. 컴퓨팅 디바이스(650)는 PDA, 셀룰라 전화, 스마트폰, 및 그 밖의 유사한 컴퓨팅 디바이스와 같은 다양한 형태의 모바일 디바이스를 나타내기 위해 사용된다. 본 명세서에서 나타낸 구성요소, 그들의 접속 및 관계, 및 그들의 기능들은 단지 예시적인 것을 의미하고, 본 명세서에서 설명하거나 및/또는 청구된 구현예들을 제한하는 것을 의미하지 않는다.

컴퓨팅 디바이스(600)는 프로세서(602), 메모리(604), 저장 디바이스(606), 메모리(604)와 고속 확장 포트(610)에 접속하는 고속 인터페이스(608), 및 저속 버스(614)와 저장 디바이스(606)에 접속하는 저속 인터페이스(612)를 포함한다. 각 구성요소(602, 604, 606, 608, 610, 및 612)는 다양한 버스들을 사용하여 서로 접속되고, 공통 마더보드에 탑재되거나 또는 적절한 경우 다른 방식으로 탑재될 수 있다. 프로세서(602)는 컴퓨팅 디바이스(600) 내에서 실행하기 위한 인스트럭션을 처리할 수 있으며, 이러한 인스트럭션에는, 고속 인터페이스(608)에 연결된 디스플레이(616)와 같은 외장 입/출력 디바이스 상에서 GUI용 그래픽 정보를 디스플레이하기 위해, 메모리(604) 또는 저장 디바이스(606)에 저장되는 인스트럭션이 포함된다. 다른 구현예에서, 다중 프로세서 및/또는 다중 버스는 적절한 경우, 다중 메모리 및 메모리 타입과 함께 사용될 수 있다. 또한, 다중 컴퓨팅 디바이스(600)는 각 디바이스가 필요 동작의 부분을 제공하는 형태(예를 들어, 서버 뱅크, 블레이드 서버의 그룹, 또는 다중 프로세서 시스템)로 접속될 수 있다.

메모리(604)는 컴퓨팅 디바이스(600) 내에 정보를 저장한다. 일 구현예에서, 메모리(604)는 휘발성 메모리 유닛 또는 유닛들이다. 또 다른 구현예서, 메모리(604)는 비휘발성 메모리 유닛 또는 유닛들이다. 또한, 메모리(604)는 마그네틱 또는 광 디스크와 같은 다른 형태의 컴퓨터 판독가능 매체일 수 있다.

저장 디바이스(606)는 컴퓨팅 디바이스(600)를 위한 대용량 저장소(mass storage)를 제공할 수 있다. 일 구현예에서, 저장 디바이스(606)는 플로피 디스크 디바이스, 하드 디스크 디바이스, 광 디스크 디바이스, 테이프 디바이스, 플래쉬 메모리 또는 다른 유사한 고체 상태 메모리 디바이스, 또는 저장 영역 네트워크 또는 다른 구성에 존재하는 디바이스를 포함하는 디바이스 어레이일 수 있다. 컴퓨터 프로그램 제품은 정보 캐리어(information carrier) 내에 유형적으로 구체화될 수 있다. 또한, 컴퓨터 프로그램 제품은 실행될 때, 상술한 것과 같은 하나 이상의 방법을 수행하는 인스트럭션을 포함할 수 있다. 정보 캐리어는 메모리(604), 저장 디바이스(606), 또는 프로세서(602) 상의 메모리와 같은 컴퓨터- 또는 기계-판독가능 매체이다.

저속 제어부(612)가 저대역-집약적 동작(lower bandwidth-intensive operations)을 관리하는 반면, 고속 제어부(608)는 컴퓨팅 디바이스(900)에 대한 대역-집약적 동작을 관리한다. 이러한 기능들의 배치는 단지 예시적인 것이다. 일 구현예에서, 고속 제어부(608)는 메모리(604), 디스플레이(616)(예를 들어, 그래픽 프로세서 또는 가속기를 통함)에 연결되고, 다양한 확장 카드(도시되지 않음)을 수용할 수 있는 고속 확장 포트(610)에 연결된다. 일부 구현예에서는, 저속 제어부(612)는 저장 디바이스(606) 및 저속 확장 포트(614)에 연결된다. 다양한 통신 포트(예를 들어, USB, 블루투스, 이더넷, 무선 이더넷)를 포함할 수 있는 저속 확장 포트는 키보드, 포인팅 디바이스, 스캐너와 같은 하나 이상의 입/출력 디바이스들에 연결되거나, 또는 예컨대 네트워크 어댑터를 통하여, 스위치나 라우터와 같은 네트워킹 디바이스에 연결될 수 있다.

컴퓨팅 디바이스(600)는 도면에 도시된 바와 같이, 복수의 다른 형태로 구현될 수 있다. 예를 들어, 컴퓨팅 디바이스(600)는 표준 서버(620)로 구현되거나 이러한 서버들의 그룹에서 여러 번(multiple time) 구현될 수 있다. 또한, 컴퓨팅 디바이스(600)는 랙 서버 시스템(624)의 부분으로서 구현될 수 있다. 이에 더하여, 컴퓨팅 디바이스(600)는 랩탑 컴퓨터(622)와 같은 개인용 컴퓨터내에 구현될 수 있다. 선택적으로, 컴퓨팅 디바이스(600)로부터의 구성요소는 디바이스(650)와 같은 모바일 디바이스(도시되지 않음) 내 다른 구성요소와 조합될 수 있다. 이러한 디바이스 각각은 하나 이상의 컴퓨팅 디바이스(600, 650)를 포함하고, 전체 시스템은 서로 통신하는 다중 컴퓨팅 디바이스(600, 650)로 구성될 수 있다.

컴퓨팅 디바이스(650)는 여러 구성요소 중에서 프로세서(652), 메모리(664), 디스플레이(654)와 같은 입/출력 디바이스, 통신 인터페이스(666), 및 트랜스시버(668) 등을 포함한다. 또한, 디바이스(650)에는 추가적인 저장소를 제공하기 위하여, 마이크로 드라이브 또는 다른 디바이스와 같은 저장 디바이스가 제공될 수 있다. 구성요소(650, 652, 664, 654, 666, 및 668) 각각은 다양한 버스를 이용하여 서로 접속되고, 구성요소의 몇몇은 공통의 마더보스에 탑재되거나 적절한 다른 방법으로 탑재될 수 있다.

프로세서(652)는 컴퓨팅 디바이스(650) 내에서 인스트럭션을 실행하며, 이 인스트럭션에는 메모리(664)에 저장된 인스트럭션이 포함된다. 프로세서는 개별적이고 다중의 아날로그 및 디지털 프로세서를 포함하는 칩들의 칩 세트로서 구현될 수 있다. 프로세서는, 예를 들어, 사용자 인터페이스의 컨트롤, 디바이스(650)에 의해 실행되는 애플리케이션, 및 컴퓨팅 디바이스(650)에 의한 무선 통신과 같은 디바이스(650)의 다른 구성요소들 사이에 조정을 제공할 수 있다.

프로세서(652)는 제어 인터페이스(658) 및 디스플레이(654)에 연결된 디스플레이 인터페이스(656)를 통해 사용자와 통신할 수 있다. 디스플레이(654)는, 예를 들어, TFT LCD(Thin-Film-Tansistor Liquid Crystal Display) 또는 OLED(Organic Light Emitting Diode) 디스플레이, 또는 다른 적절한 디스플레이 기술일 수 있다. 디스플레이 인터페이스(656)는 그래픽 및 다른 정보를 사용자에게 나타내기 위해 디스플레이(654)를 구동하는 적절한 회로를 포함할 수 있다. 제어 인터페이스(658)는 사용자로부터 명령들을 수신하고, 프로세서(652)에 제출하기 위해 그 명령들을 변환한다. 더욱이, 확장 인터페이스(662)는 디바이스(650)와 다른 디바이스들 간에 근거리 통신이 가능하도록 하기 위해, 프로세서(652)와의 통신에 제공될 수 있다. 확장 인터페이스(662)는, 예를 들어, 일부 구현예에서는 유선 통신을 제공하고 다른 구현예에서 무선 통신을 제공하며, 또한 다중 인터페이스가 사용될 수 있다.

메모리(664)는 컴퓨팅 디바이스(650) 내에 정보를 저장한다. 메모리(664)는 컴퓨터 판독가능 매체 또는 미디어, 휘발성 메모리 유닛 또는 유닛들, 또는 비휘발성 메모리 유닛 또는 유닛들 중 하나 이상으로서 구현될 수 있다. 또한, 확장 메모리(674)가 제공되어, 예를 들어 SIMM(Single In Line Memory Module) 카드 인터페이스를 포함하는 확장 인터페이스(672)를 통해 디바이스(650)에 접속될 수 있다. 이러한 확장 메모리(674)는 디바이스(650)를 위한 여분의 저장 공간을 제공할 수 있고, 또한 애플리케이션 또는 디바이스(650)를 위한 다른 정보를 저장할 수 있다. 특히, 확장 메모리(674)는 상술된 프로세스를 실행하거나 보조하기 위한 인스트럭션을 포함하고, 또한 보안 정보를 포함할 수 있다. 따라서 예를 들어, 확장 메모리(674)는 디바이스(650)용 보안 모듈(security module)로서 제공될 수 있고, 디바이스(650)의 안전한 사용을 가능하게 하는 인스트럭션로 프로그램될 수 있다. 더욱이, 보안 애플리케이션은, 해킹할 수 없는 방식(non-hackable manner)으로 SIMM 카드 상에 식별 정보를 위치시킨 것과 같은 추가적 정보와 함께 SIMM 카드를 통해 제공될 수 있다.

메모리는 아래에서 논의되는 것과 같이 예를 들어, 플래시 메모리 및/또는 NVRAM 메모리를 포함할 수 있다. 일 구현예에서, 컴퓨터 프로그램 제품은 정보 캐리어에 유형적으로 구체화된다. 컴퓨터 프로그램 제품은 실행될 때, 상술된 것과 같은 하나 이상의 방법을 수행하는 인스트럭션을 포함한다. 정보 캐리어는 메모리(664), 확장 메모리(674), 또는 프로세서(652) 상의 메모리이다.

디바이스(650)는 디지털 신호 처리 회로를 필요에 따라 포함하는 통신 인터페이스(666)를 통해 무선으로 통신할 수 있다. 통신 인터페이스(666)는 GSM 음성 호, SMS, EMS, 또는 MMS 메시징, CDMA, TDMA, PDC, WCDMA, CDMA2000, 또는 GPRS 등과 같은 다양한 모드 또는 프로토콜 하에서의 통신을 제공할 수 있다. 이러한 통신은 예를 들어, 무선-주파수 트랜스시버(668)를 통해 수행될 수 있다. 또한, 단거리(short range) 통신은 예를 들어, 블루투스, WiFi, 또는 다른 이러한 트랜스시버(도시되지 않음)를 사용하여 수행될 수 있다. 이에 더하여, GPS(Global Position System) 수신기 모듈(670)은 추가적인 네비게이션- 및 위치- 관련 무선 데이터를 디바이스(650)에 제공할 수 있으며, 이 무선 데이터는 디바이스(650)에서 실행중인 애플리케이션에 의해 적절하게 사용될 수 있다.

또한, 디바이스(650)는 사용자로부터의 발화 정보(spoken information)를 수신하고, 그 발화 정보를 사용가능한 디지털 정보로 변환하는 오디오 코덱(660)을 이용하여, 청취가능하게(audibly) 통신할 수 있다. 또한, 오디오 코덱(660)은 예를 들어, 디바이스(650)의 핸드셋 내의 스피커를 통하는 것과 같이 해서, 사용자가 들을 수 있는 음성을 생성한다. 이러한 음성은 음성 전화 호로부터의 음성을 포함할 수 있고, 녹음된 음성(예를 들어, 음성 메시지, 음악 파일 등)은 포함할 수 있고, 또한 디바이스(650) 상에서 동작하는 애플리케이션에 의해 생성된 음성을 포함할 수 있다.

컴퓨팅 디바이스(650)는 도면에 도시된 바와 같이, 복수의 다양한 형태로 구현될 수 있다. 예를 들어, 컴퓨팅 디바이스(650)는 셀룰러 전화(680)로서 구현될 수 있다. 또한, 컴퓨팅 디바이스(650)는 스마트폰(682), PDA, 또는 다른 유사한 모바일 디바이스의 일부로서 구현될 수 있다.

부가적으로, 컴퓨팅 디바이스(600 또는 650)는 USB(Universal Serial Bus) 플래시 드라이브를 포함할 수 있다. USB 플래시 드라이브는 운영 체계 및 다른 애플리케이션들을 저장할 수 있다. USB 플래시 드라이브는 예를 들어, 다른 컴퓨팅 디바이스의 USB 포트에 삽입할 수 있는 USB 커넥터 또는 무선 트랜스미터와 같은 입력/출력 구성요소들을 포함할 수 있다.

본 명세서에 기재된 시스템의 다양한 구현예와 기술은 디지털 전자 회로, 집적 회로, 특별하게 설계된 ASICs(Application Specific Intergrated Circuit), 컴퓨터 하드웨어, 펌웨어, 소프트웨어, 및/또는 그것의 조합물로 실현될 수 있다. 이러한 다양한 구현예는 하나 이상의 컴퓨터 프로그램으로 된 구현예를 포함하며, 이 컴퓨터 프로그램은 적어도 하나의 프로그램 가능한 프로세서를 포함하는 프로그램 가능한 시스템에서 실행가능하고 및/또는 해석가능하다. 또한, 전용 또는 범용 프로세서일 수 있는 이 프로그램 가능한 프로세서는 데이터와 인스트럭션을 송수신하기 위해, 저장 시스템, 적어도 하나의 입력 디바이스 및 적어도 하나의 수신 디바이스에 연결된다.

컴퓨터 프로그램(또한 프로그램, 소프트웨어, 소프트웨어 애플리케이션, 또는 코드로 알려짐)은 프로그램 가능한 프로세서를 위한 기계 인스트럭션을 포함하고, 고레벨 절차 및/또는 오브젝트 지향 프로그램 언어(object-oriented programming language) 및/또는 어셈블리/기계 언어로 구현될 수 있다. 본 명세서에서 사용되는 바와 같이, 용어 "기계 판독가능 매체(machine-readable medium)"와 "컴퓨터 판독가능 매체(computer-readable medium)"는 기계 인스트럭션 및/또는 데이터를 프로그램 가능한 프로세서에 제공하기 위해 이용되는 임의의 컴퓨터 프로그램 제품, 장치, 및/또는 디바이스(예를 들어, 마그네틱 디스크, 광학 디스크, 메모리, PLDs(Programmable Logic Devices))를 가리키며, 기계 판독가능 신호와 같은 기계 인스트럭션을 수신하는 기계 판독가능 매체를 포함한다. 용어 "기계 판독가능 신호(machine-readable signal)"는 기계 인스트럭션 및/또는 데이터를 프로그램 가능한 프로세서에 제공하기 위해 사용되는 임의의 신호를 가리킨다.

사용자와의 상호 동작을 제공하기 위하여, 본 명세서에 기술된 시스템과 기술은, 정보를 사용자에게 디스플레이하기 위한 디스플레이 디바이스(예를 들어, CRT(cathode ray tube) 또는 LCD 모니터)와 사용자가 컴퓨터에 입력을 제공할 수 있는 키보드 및 포인팅 디바이스(예를 들어, 마우스 또는 트랙볼)를 구비한 컴퓨터상에서 구현될 수 있다. 사용자와의 상호 동작을 제공하기 위하여 다른 종류의 디바이스가 또한 사용될 수 있다; 예를 들어, 사용자에게 제공되는 피드백(feedback)은 임의의 형태의 감각 피드백(예를 들어, 시각 피드백, 청각 피드백 또는 촉각 피드백)일 수 있고, 사용자로부터의 입력은 음향(acoustic), 음성(speech) 또는 촉각(tactile) 입력을 포함하는 임의의 형태로 수신될 수 있다.

본 명세서에서 설명한 시스템과 기술은, 백앤드(back end) 구성요소(예를 들어, 데이터 서버와 같은), 또는 미들웨어 구성요소(예를 들어, 애플리케이션 서버), 또는 프론트 앤드(front end) 구성요소(예를 들어, 본 명세서에서 설명된 시스템 및 기술의 구현예와 사용자가 상호 동작할 수 있는 그래픽 사용자 인터페이스 또는 웹브라우저를 구비한 클라이언트 컴퓨터), 또는 이러한 백앤드, 미들웨어, 또는 프론트 앤드 구성요소들의 임의의 조합을 포함하는 컴퓨팅 시스템으로 구현될 수 있다. 시스템의 구성요소는 디지털 데이터 통신의 임의의 형태 또는 매체(예를 들어, 통신 네트워크)에 의해 상호 접속될 수 있다. 통신 네트워크의 예로서, 근거리 네트워크(LAN), 광역 네트워크(WAN), 및 인터넷이 있다.

컴퓨팅 시스템은 클라이언트와 서버를 포함할 수 있다. 클라이언트와 서버는 보통 서로 떨어져 있으며, 일반적으로는 통신 네트워크를 통하여 상호 동작한다. 클라이언트와 서버의 관계는 각각의 컴퓨터상에서 실행되고 상호 클라이언트-서버 관계를 갖는 컴퓨터 프로그램에 의하여 발생한다.

많은 구현예들이 자세하게 상술되었지만, 다른 변혀예들도 가능하다. 또한, 본 명세서에서 설명된 시스템들 및 방법들을 수행하기 위해 다른 메카니즘들이 사용될 수 있다. 이에 더하여, 도면에서 묘사된 로직 흐름은 희망하는 결과를 달성하기 위해, 도시된 특정 순서 또는 시계열적 순서을 요구하지 않을 수 있다. 다른 단계들이 제공되거나, 그로부터 단계들이 제거될 수 있으며, 다른 구성요소들이 설명된 시스템에 추가되거나 그로부터 제거될 수 있다. 따라서 다른 구현예들은 후술하는 청구범위의 범위 내에 속한다.

106: 애플리케이션 마켓
108: 애플리케이션 구매 요청
110: 애플리케이션 바이너리
112: 라이센스 체크 요청
116: 라이센스 체커
118: 라이센스 체크 응답

Claims

컴퓨터로 구현되는, 소프트웨어 애플리케이션의 라이센스 상태를 판단하기 위한 방법으로서, 본 방법은
클라이언트 컴퓨팅 디바이스에서 실행되는 라이센싱 클라이언트에서, 상기 라이센싱 클라이언트와는 별개인 상기 클라이언트 컴퓨팅 디바이스 상의 소프트웨어 애플리케이션으로부터, 상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지의 여부에 대한 표시(indication)를 획득하기 위한 라이센스 상태 요청을 수신하는 단계, 상기 클라이언트 컴퓨팅 디바이스는 다수의 소프트웨어 애플리케이션 퍼블리셔들로부터의 소프트웨어 애플리케이션들을 배포하는 온라인 애플리케이션 마켓에서 상기 소프트웨어 애플리케이션을 획득하였으며;
상기 라이센싱 클라이언트를 사용하여, 상기 클라이언트 컴퓨팅 디바이스 또는 상기 클라이언트 컴퓨팅 디바이스의 사용자 중 적어도 하나를 식별하는 아이덴티티 정보를 식별하는 단계;
상기 라이센싱 클라이언트가 상기 소프트웨어 애플리케이션으로부터 상기 라이센스 상태 요청을 수신함에 응답하여, 상기 클라이언트 컴퓨팅 디바이스로부터, 상기 클라이언트 컴퓨팅 디바이스로부터 원격으로(remotely) 동작하는 라이센싱 서비스(licensing service)로, 상기 클라이언트 컴퓨팅 디바이스 또는 상기 클라이언트 컴퓨팅 디바이스의 사용자 중 적어도 하나를 식별하는 아이덴티티 정보를 포함하는 제 1 통신을 전송하는 단계, 상기 라이센싱 서비스는 상기 제 1 통신에 포함된 아이덴티티 정보 및 상기 소프트웨어 애플리케이션과 연관된 라이센싱 정보에 적어도 부분적으로 기초하여, 상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부에 대한 표시를 생성하며;
상기 라이센싱 클라이언트에 의해, 상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부에 대한 표시를 포함하는 라이센스 상태 응답을 상기 라이센싱 서비스로부터 수신하는 단계; 및
상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부에 대한 표시를 포함하는 라이센스 상태 응답에 기초하여, 상기 소프트웨어 애플리케이션에 의한 처리를 위하여 상기 클라이언트 컴퓨팅 디바이스로부터 상기 소프트웨어 애플리케이션으로, 제 2 통신을 전송하는 단계를 포함하며,
상기 라이센싱 서비스는 상기 온라인 마켓 애플리케이션과 관련되며, 상기 라이센싱 서비스 및 상기 온라인 마켓 애플리케이션은 상기 다수의 소프트웨어 애플리케이션 퍼블리셔들 중 적어도 일부에 대해 독립적인 엔티티에 의해 운영되는 것을 특징으로 하는 방법.
청구항 1에 있어서,
상기 소프트웨어 애플리케이션에 의한 처리는,
상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스 상에서의 사용에 대해 라이센스 되지 않았음을 상기 제 2 통신으로부터 식별함에 따라, 상기 소프트웨어 애플리케이션의 적어도 일부분을 이용하지 못하게(disabling)하는 단계를 포함하는 방법.
삭제
청구항 1에 있어서,
상기 소프트웨어 애플리케이션과 연관된 상기 라이센싱 정보는, 상기 온라인 애플리케이션 마켓을 통해 상기 소프트웨어 애플리케이션을 구매했던 사용자들을 나타내는 구매 레코드들을 포함하는 방법.
청구항 1에 있어서,
상기 소프트웨어 애플리케이션으로 전송되는 상기 제 2 통신은 라이센스 상태 응답이고, 상기 라이센스 상태 응답은 공용-개인키 쌍(public-private key pair)의 일부인 개인키를 사용하여 암호화되고,
상기 소프트웨어 애플리케이션에 의한 처리는 상기 공용-개인키 쌍의 일부인 공용키를 이용하여 상기 라이센스 상태 응답을 암호 해제하는 단계를 포함하는 방법.
삭제
청구항 1에 있어서,
상기 아이덴티티 정보는, 상기 라이센싱 클라이언트에 의해 액세스가능하지만 상기 소프트웨어 애플리케이션에 의해 액세스불가능한 정보를 포함하는 방법.
청구항 1에 있어서,
상기 소프트웨어 애플리케이션에 의한 처리는
상기 제 2 통신으로부터 상기 표시를 추출하는 것과,
상기 표시를 상기 클라이언트 컴퓨팅 디바이스의 저장소에 저장하는 것을 포함하는 방법.
청구항 8에 있어서,
상기 라이센싱 클라이언트에 의해, 상기 소프트웨어 애플리케이션으로부터 제2 라이센스 상태 요청을 수신하는 단계,
상기 라이센싱 클라이언트를 사용하여, 상기 라이센싱 서비스가 상기 제2 라이센스 상태 요청을 처리하기 위해 이용불가능한지를 판단하는 단계, 및
상기 제2 라이센스 상태 요청의 실패(failure)를 나타내는 메시지를 상기 소프트웨어 애플리케이션에 전송하는 단계를 더 포함하고,
상기 소프트웨어 애플리케이션은 상기 메시지를 수신할 시, 저장된 표시를 검색하고, 상기 저장된 표시에 기초하여 상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부를 판단하는 방법.
명령어들이 저장된 비일시적 컴퓨터 판독가능 저장 매체로서, 상기 명령어들은 하나 이상의 프로세싱 디바이스들에 의해 실행될 때, 상기 프로세싱 디바이스들로 하여금 동작들을 수행하도록 하며, 상기 동작들은:
클라이언트 컴퓨팅 디바이스에서 실행되는 라이센싱 클라이언트에서, 상기 라이센싱 클라이언트와는 별개인 상기 클라이언트 컴퓨팅 디바이스 상의 소프트웨어 애플리케이션으로부터, 상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지의 여부에 대한 표시를 획득하기 위한 라이센스 상태 요청을 수신하는 동작, 상기 클라이언트 컴퓨팅 디바이스는 다수의 소프트웨어 애플리케이션 퍼블리셔들로부터의 소프트웨어 애플리케이션들을 배포하는 온라인 애플리케이션 마켓에서 상기 소프트웨어 애플리케이션을 획득하였으며;
상기 라이센싱 클라이언트를 사용하여, 상기 클라이언트 컴퓨팅 디바이스 또는 상기 클라이언트 컴퓨팅 디바이스의 사용자 중 적어도 하나를 식별하는 아이덴티티 정보를 식별하는 동작;
상기 라이센싱 클라이언트가 상기 소프트웨어 애플리케이션으로부터 상기 라이센스 상태 요청을 수신함에 응답하여, 상기 클라이언트 컴퓨팅 디바이스로부터, 상기 클라이언트 컴퓨팅 디바이스로부터 원격으로(remotely) 동작하는 라이센싱 서비스(licensing service)로, 상기 클라이언트 컴퓨팅 디바이스 또는 상기 클라이언트 컴퓨팅 디바이스의 사용자 중 적어도 하나를 식별하는 아이덴티티 정보를 포함하는 제 1 통신을 전송하는 동작, 상기 라이센싱 서비스는 상기 제 1 통신에 포함된 아이덴티티 정보 및 상기 소프트웨어 애플리케이션과 연관된 라이센싱 정보에 적어도 부분적으로 기초하여, 상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부에 대한 표시를 생성하며;
상기 라이센싱 클라이언트에 의해 상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부에 대한 표시를 포함하는 라이센스 상태 응답을, 상기 라이센싱 서비스로부터 수신하는 동작; 및
상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부에 대한 표시를 포함하는 라이센스 상태 응답에 기초하여, 상기 소프트웨어 애플리케이션에 의한 처리를 위하여 상기 클라이언트 컴퓨팅 디바이스로부터 상기 소프트웨어 애플리케이션으로, 제 2 통신을 전송하는 동작을 포함하며,
상기 라이센싱 서비스는 상기 온라인 마켓 애플리케이션과 관련되며, 상기 라이센싱 서비스 및 상기 온라인 마켓 애플리케이션은 상기 다수의 소프트웨어 애플리케이션 퍼블리셔들 중 적어도 일부에 대해 독립적인 엔티티에 의해 운영되는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 저장 매체.
청구항 10에 있어서,
상기 소프트웨어 애플리케이션에 의한 처리는,
상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스 상에서의 사용에 대해 라이센스 되지 않았음을 상기 제 2 통신으로부터 식별함에 따라, 상기 소프트웨어 애플리케이션의 적어도 일부분을 이용하지 못하게(disabling)하는 것을 포함하는 비일시적 컴퓨터 판독가능 저장 매체.
삭제
청구항 10에 있어서,
상기 소프트웨어 애플리케이션과 연관된 상기 라이센싱 정보는 상기 온라인 애플리케이션 마켓을 통해 상기 소프트웨어 애플리케이션을 구매했던 사용자들을 나타내는 구매 레코드들을 포함하는 비일시적 컴퓨터 판독가능 저장 매체.
청구항 10에 있어서,
상기 소프트웨어 애플리케이션으로 전송되는 상기 제 2 통신은 라이센스 상태 응답이고, 상기 라이센스 상태 응답은 공용-개인키 쌍(public-private key pair)의 일부인 개인키를 사용하여 암호화되고,
상기 소프트웨어 애플리케이션에 의한 처리는 상기 공용-개인키 쌍의 일부인 공용키를 이용하여 상기 라이센스 상태 응답을 암호 해제하는 것을 포함하는 비일시적 컴퓨터 판독가능 저장 매체.
삭제
청구항 10에 있어서,
상기 아이덴티티 정보는 상기 소프트웨어 애플리케이션에 의해 액세스불가능한 정보를 포함하는 비일시적 컴퓨터 판독가능 저장 매체.
청구항 10에 있어서,
상기 소프트웨어 애플리케이션에 의한 처리는
상기 제 2 통신으로부터 상기 표시를 추출하는 것과, 그리고
상기 표시를 상기 클라이언트 컴퓨팅 디바이스의 저장소에 저장하는 것을 포함하는 비일시적 컴퓨터 판독가능 저장 매체.
청구항 17에 있어서,
상기 동작들은:
상기 라이센싱 클라이언트에 의해 상기 소프트웨어 애플리케이션으로부터 제2 라이센스 상태 요청을 수신하는 동작,
상기 라이센싱 클라이언트를 사용하여, 상기 라이센싱 서비스가 상기 제2 라이센스 상태 요청을 처리하기 위해 이용불가능한지를 판단하는 동작, 및
상기 제2 라이센스 상태 요청의 실패(failure)를 나타내는 메시지를 상기 소프트웨어 애플리케이션에 전송하는 동작을 더 포함하고,
상기 소프트웨어 애플리케이션은 상기 메시지를 수신할 시, 저장된 표시를 검색하고, 상기 저장된 표시에 기초하여 상기 소프트웨어 애플리케이션이 상기 클라이언트 컴퓨팅 디바이스에서의 사용에 대해 라이센스 되었는지 여부를 판단하는 비일시적 컴퓨터 판독가능 저장 매체.
삭제