KR102170008B1 - 제어된 애플리케이션 배포 기법 - Google Patents

Abstract

애플리케이션 발신자는 애플리케이션 발신자에 의해 제출된 배포 조건을 캡슐화하는 인가 토큰 및 애플리케이션의 개발자에 의해 제출된 애플리케이션 라이센스 사양을 사용하여 애플리케이션의 배포 및 사용을 제어할 수 있다. 애플리케이션 발신자는 애플리케이션 스토어를 액세스하고, 애플리케이션 수신자에 의한 사용을 위해 하나 이상의 애플리케이션을 선택하는 것, 하나 이상의 애플리케이션을 애플리케이션 수신자에 의한 사용을 위해 번들로 조합하는 것 및/또는 애플리케이션 수신자에 의한 사용을 위해 새 애플리케이션을 형성하도록 여러 애플리케이션을 조합하는 것과 같은 다양한 기능을 수행할 수 있다. 애플리케이션 수신자는 배포 조건에 의해 생성된 인가 토큰에 따라 애플리케이션을 활용할 수 있다.

Description

제어된 애플리케이션 배포 기법{CONTROLLED APPLICATION DISTRIBUTION}

기술 산업은 수축 포장된 소프트웨어(shrink-wrapped software)의 모델로부터 애플리케이션을 배포하는 것으로 진화하고 있다. 애플리케이션은 사용자로 하여금 애플리케이션을 사용자의 컴퓨터로 다운로드하게 하는 로케이션(location) 또는 링크(link)를 제공함으로써 사용자에게 배포될 수 있다. 애플리케이션은 사용자가 이용가능한 소프트웨어 제품에 의해 서비스가 제공되게 함으로써 배포될 수도 있다. 서비스 전달(service delivery)의 한 예는 소프트웨어 제품이 통신 네트워크를 통해 사용자에 의해 액세스가능한 원격 서버 상에서 중앙식으로 호스트되는(centrally hosted) "서비스로서의 소프트웨어"(Software as a Service: SaaS) 모델이다. 애플리케이션 배포 모델은 애플리케이션을 사용하기 위해서 애플리케이션 스토어(application store)에 돈이나 다른 형태의 가치를 지불하는 개인을 전형적으로 수반한다. 전형적으로, 애플리케이션 스토어는 라이센스 지불(license payment)의 형태로 애플리케이션의 개발자에게 트랜잭션 총액(transaction total)의 일정 비율을 넘겨 준다. 많은 애플리케이션 스토어에서, 사용자가 애플리케이션 스토어에서 행하는 구매(purchase)는 사용자의 신원(identity)과 대조하여 기록된다. 예를 들어, 애플리케이션을 구매하기 위해서 계정(account)을 생성하거나 기존의 계정에 서명접속하도록(sign) 사용자가 요구받는 것은 이례적인 것이 아니다. 이유가 달라질 수는 있겠지만, 이는 누가 애플리케이션을 사용할 자격이 있는지 추적하고 사용자의 라이센스 권리를 추적하기 위해서 흔히 행해진다.

전술된 종래의 배포 모델들은 자신의 즐거움 또는 자신의 생산성 필요를 위해 애플리케이션의 사용을 구매하고 있는 개인에 대해 제대로 작동할 수 있다. 그러나, 전형적인 애플리케이션 스토어에 의해 제공되는 개별화된 애플리케이션 구매 경험은 협력적 환경을 용이하게 하지 않는다. 예를 들어, 건축가의 클라이언트는 클라이언트로 하여금 건축가가 클라이언트와 공유하기를 원할지도 모르는 계획을 보거나 편집하게 하는 하나 이상의 애플리케이션을 이전에 구입하지 않았을 수 있다. 이에 대한 다양한 이유가 있을 수 있으나, 전형적으로, 클라이언트는 건축가와의 협력 외에 애플리케이션을 구매할 필요가 없을 것이다. 다른 예에서, 사용자는 다수의 회사가 관여되는 프로젝트에 관해 일하며 다른 회사들이 특정한 프로젝트 관리 애플리케이션을 사용하기를 바랄 수 있다. 그 회사들은 그 사용자와 협력하기 위해서 어느 애플리케이션이 필요한지에 대해 정보입각 판정(informed decision)을 행할 경험이나 전문지식을 갖지 않을 수 있다.

종래의 애플리케이션 마켓플레이스(application marketplace)들은 전술한 문제점에 대한 다양한 해결책을 제공하나, 각각은 한정적이다. 예를 들어, 각 사용자는 간단히 애플리케이션을 스스로 구입할 수 있으나, 앞서 설명한 바와 같이, 사용자의 경험 및 전문지식은 애플리케이션을 구매하는 것의 가치에 의문을 가져온다. 또한, 애플리케이션의 사용자는 단기간의 시간 동안 사용될지도 모르는 애플리케이션을 구매하기 위해서 계정을 생성하거나 재무 정보를 애플리케이션 스토어에 입력하기를 원하지 않을 수 있다. 특정한 회사를 위해 애플리케이션의 다수의 라이센스가 구입되는 다른 해결책들도 존재하나, 이 해결책들은 전형적으로 각 사용자가 기업 주소록에 이미 있는 경우에 작동할 뿐이다. 결과적으로, 이 접근법은 회사 경계를 가로질러서는 제대로 작동하지 않을 수 있다. 끝으로, 개발자는 다수의 사용자로 하여금 개발자에 의해 제공되는 웹 사이트를 통해 다른 이를 위해 애플리케이션을 구입할 수 있게 할 수도 있다. 그러나, 이 접근법은 각 개발자 하나하나의 측에서 애플리케이션 마켓플레이스를 만드는 상당한 개발 노력을 요구한다.

본 문서에서 행해진 개시는 바로 이 고려사항 및 다른 고려사항에 관해서 제시되는 것이다.

애플리케이션을 배포하는 메커니즘(mechanism)을 위한 개념 및 기술이 본 문서에서 기술된다. 본 문서에서 개시된 몇몇 개념 및 기술에 따르면, 애플리케이션 발신자(application sender)는 애플리케이션 수신자(application receiver)에 의해 사용될 하나 이상의 애플리케이션을 선택하기 위해 애플리케이션 스토어를 액세스할 수 있다. 애플리케이션 스토어는 애플리케이션을 애플리케이션 수신자에게 공급하고 라이센싱하기 위한 클리어링하우스(clearinghouse)일 수 있다. 애플리케이션 발신자는 선택된 애플리케이션 중 하나 이상을 위한 배포 조건(distribution terms)을 제출할 수 있다. 배포 조건은 애플리케이션 수신자가 애플리케이션을 사용할 권리를 확보할 수 있는 시간, 애플리케이션 수신자가 애플리케이션을 얼마나 오래 사용할 수 있는지를 나타내는 시간, 애플리케이션 수신자의 신원 및/또는 애플리케이션을 사용하도록 인가된(authorized) 사람의 수를 포함할 수 있으나 이에 한정되지는 않는다. 애플리케이션 발신자는 애플리케이션 스토어에 의해 제공되는 인터페이스(interface) 또는 애플리케이션 발신자의 컴퓨팅 시스템(computing system) 상의 실행가능 프로그램(executable program)과 같은 다양한 기술을 사용하여 배포 조건을 제출하거나 수정할 수 있다.

애플리케이션 스토어는 배포 조건이 애플리케이션 라이센스 사양(application license specification)에 개진된 조항을 준수함을 확인할 수 있다. 애플리케이션 라이센스 사양은 애플리케이션의 개발자에 의해 제공될 수 있거나 애플리케이션을 제공하는 애플리케이션 스토어와 같은 다른 소스(source)에 의해 제공될 수 있다. 애플리케이션 스토어는 인가 토큰(authorization token)을 생성하기 위해 배포 조건을 사용할 수 있다. 인가 토큰은 애플리케이션의 개발자에 의해 제공된 애플리케이션 라이센스 사양 및 애플리케이션 발신자에 의해 제공된 배포 조건을 캡슐화할(encapsulate) 수 있다. 그리고 애플리케이션 스토어는 수신자 라이센스(receiver license)를 생성할 수 있는데, 이는 애플리케이션 수신자에 의한 애플리케이션의 사용을 제어하는 라이센스이다.

수신자 라이센스는 애플리케이션 개발자에 의해 제공된 애플리케이션 라이센스 사양, 애플리케이션 스토어에 의해 추가된 제한 또는 조건, 그리고/또는 애플리케이션 발신자에 의해 제공된 배포 조건을 나타낼 수 있다. 몇몇 구현에서, 애플리케이션 발신자는 한 개보다 많은 애플리케이션, 동일한 애플리케이션의 다수의 인스턴스 또는 이들의 다양한 조합으로의 애플리케이션 수신자의 액세스를 제어하기 위해 인가 토큰을 사용할 수 있다. 몇몇 구현에서, 애플리케이션 수신자는 애플리케이션에 대해 대가를 지불할 것을 요구받지 않을 수 있거나, 상이한 액수를 지불하도록 요구받을 수 있거나, 애플리케이션을 획득하기 위해 상이한 유형의 가치를 사용할 수 있다.

애플리케이션 발신자는 애플리케이션 수신자에게 애플리케이션을 사용할 것을 허락하도록 의도된 통신(communication)을 애플리케이션 수신자에게 송신할 수 있다. 몇몇 사용에서, 그 통신은 인가 토큰을 이용할 수 있다. 애플리케이션 수신자는 애플리케이션에 대한 액세스를 얻기 위해 애플리케이션 스토어에 인가 토큰과 연관된 정보를 제출할 수 있다. 애플리케이션 발신자로부터 애플리케이션 수신자로의 통신은 암호, 개인 식별 번호(personal identification number), 애플리케이션(들)의 식별 및/또는 애플리케이션을 이용할 수도 있다.

전술된 대상(subject matter)은 컴퓨터 제어식(computer-controlled) 장치, 컴퓨터 프로세스(computer process), 컴퓨팅 시스템으로서, 또는 컴퓨터 판독가능 저장 매체(computer-readable storage medium)와 같은 제조품(article of manufacture)으로서 구현될 수도 있다는 점이 인식되어야 한다. 이들 및 다양한 다른 특징이 이하의 상세한 설명의 읽기 및 관련된 도면의 검토로부터 명백할 것이다.

이 개요는 상세한 설명에서 추가적으로 후술되는 개념들 중 선택된 것을 단순화된 형태로 소개하기 위해 제공된다. 이 개요는 본 문서에 개시된 개념 및 기술의 주요 특징 또는 필수적인 특징을 식별하고자 의도된 것이 아니고, 이 개요는 청구된 대상(claimed subject matter)의 범주를 한정하기 위해 사용되도록 의도된 것도 아니다. 나아가, 청구된 대상은 이 개시의 임의의 부분에 언급된 임의의 또는 모든 난점을 해결하는 구현에 한정되지 않는다.

도 1은 본 문서에서 개시된 다양한 실시예를 구현하기 위해 사용될 수 있는 하나의 예시적 운영 환경을 도시하는 시스템 다이어그램(system diagram)이다.
도 2는 몇몇 실시예에 따라, 다수의 애플리케이션이 번들화되는(bundled) 제2 예시적 운영 환경을 도시하는 시스템 다이어그램이다.
도 3a 및 도 3b는 몇몇 실시예에 따라, 애플리케이션 발신자에 의해 제어될 수 있는 예시적인 애플리케이션 포맷을 보여주는 소프트웨어 아키텍처 다이어그램이다.
도 4는 몇몇 실시예에 따라, 애플리케이션 수신자에 의한 사용을 위해 다수의 애플리케이션을 번들화하는 라이센싱 메커니즘(licensing mechanism)을 보여주는 시스템 다이어그램이다.
도 5는 몇몇 실시예에 따라, 애플리케이션 수신자에 의한 사용을 위해 인가 토큰을 조합하는 다수의 애플리케이션 발신자를 보여주는 시스템 다이어그램이다.
도 6은 몇몇 실시예에 따라, 개발자가 어떻게 애플리케이션 라이센스(application license)를 제어할 수 있는지를 보여주는 시스템 다이어그램 및 사용자 인터페이스(user interface)("UI")이다.
도 7은 몇몇 실시예에 따라, 인가 토큰을 사용하여 애플리케이션 배포를 제어하는 예시적인 방법을 보여주는 블록 다이어그램(block diagram)이다.
도 8은 몇몇 실시예에 따라, 애플리케이션들을 번들화하는 예시적인 방법을 보여주는 블록 다이어그램이다.
도 9는 본 문서에서 제시된 실시예의 양상을 구현할 수 있는 컴퓨터 시스템을 위한 예시적 컴퓨터 하드웨어 및 소프트웨어 아키텍처를 도시하는 컴퓨터 아키텍처 다이어그램이다.

이하의 상세한 설명은 애플리케이션을 배포하는 개념 및 기술로 지향된다. 본 문서에서 개시된 몇몇 개념 및 기술에 따르면, 애플리케이션 발신자는 인가 토큰을 사용하여 애플리케이션의 배포 및 사용을 제어할 수 있다. 인가 토큰은 인가 토큰과 연관된 하나 이상의 애플리케이션에 대한 액세스를 얻어 이를 사용하기 위해 애플리케이션 수신자에 의해 사용될 수 있다. 인가 토큰을 생성하기 위해, 애플리케이션 발신자는 애플리케이션 스토어를 액세스하고 애플리케이션 수신자에 의한 사용을 위해 하나 이상의 애플리케이션을 선택할 수 있다. 애플리케이션 발신자는 애플리케이션 스토어에 배포 조건의 세트(set) 및 만약 요구된다면 지불을 제출할 수 있다. 제출되면, 애플리케이션 발신자는 인가 토큰을 수신할 수 있다. 인가 토큰은 애플리케이션 라이센스 사양, 애플리케이션 스토어에 의해 제공되는 임의의 제한, 그리고 배포 조건을 캡슐화할 수 있다. 이 정보는 인가 토큰 내에 또한 캡슐화될 수 있는 수신자 라이센스를 생성하기 위해 사용될 수 있다. 수신자 라이센스는 애플리케이션 수신자로의 애플리케이션의 배포의 사용을 제어한다. 본 문서에 기술된 개념 및 기술은 어떠한 특정한 유형의 배포 모델에도 한정되지 않는다는 점이 이해되어야 한다. 예를 들어, 애플리케이션은 사용자에 의해 사용되는 로컬 컴퓨터(local computer)로 다운로드될 수 있다. 다른 예에서, 애플리케이션은 SaaS 모델 하의 서비스로서 전달될 수 있다.

본 문서에 기술된 개념 및 기술의 몇몇 구현은 여러 개인 간의 협력을 가능하게 하거나 향상시킬 수 있다. 예를 들어, 애플리케이션 발신자는 다른 개인인 애플리케이션 수신자와 협력할 필요가 있는 조직 내의 개인일 수 있다. 협력적인 노력의 일부로서, 애플리케이션 수신자는 특정 애플리케이션을 사용할 필요가 있을 수 있다. 몇몇 구성에서, 애플리케이션 발신자는 애플리케이션 스토어를 액세스하고 애플리케이션 수신자에 의한 사용을 위한 애플리케이션을 선택한다. 애플리케이션 발신자는 배포 조건의 세트(애플리케이션은 이에 따라 배포될 것임)를 애플리케이션 스토어에 제출할 수 있다. 애플리케이션 발신자는 그 후에 인가 토큰을 수신할 수 있다.

애플리케이션 발신자는 애플리케이션을 사용할 권리가 확보되었음을 나타내는 통신을 애플리케이션 수신자에 발신할 수 있다. 그 통신은 인가 토큰과 만약 있다면 추가적인 정보(애플리케이션의 액세스를 얻기 위해 애플리케이션 수신자가 사용함)를 포함할 수 있다. 다른 구현에서, 그 통신은 인가 토큰을 포함하지 않을 수 있는데, 오히려 어떻게 인가 토큰을 취득할지(retrieve)에 대한 명령어를 포함할 수 있다. 추가의 구현에서, 애플리케이션 수신자는 인가 토큰을 결코 수신하지 않을 수 있다. 협력적인 작업이 완료되면, 또는 다른 이유로, 애플리케이션 발신자는 애플리케이션 수신자가 애플리케이션을 사용하는 능력을 철회하기(revoke) 위해 배포 조건을 수정할 수 있다. 몇몇 구성에서, 배포 조건을 수정할 필요 없이 배포 조건은 애플리케이션의 사용을 철회하도록 구성될 수 있다. 예를 들어, 배포 조건은 애플리케이션 수신자가 애플리케이션을 사용할 수 있는 시간을 포함할 수 있다. 이 예에서, 애플리케이션을 사용할 능력을 철회하도록 배포 조건이 이미 구성되었기 때문에 애플리케이션 발신자는 사용권을 철회하기 위해 배포 조건을 수정할 필요가 없을 수 있다. 추가의 예에서, 배포 조건은 문서가 프린트될 수 있는 횟수와 같은 소모성(consumable) 권리의 세트를 수립할 수 있다.

본 문서에 기술된 대상은 컴퓨터 시스템 상의 운영 체제(operating system) 및 애플리케이션 프로그램의 실행과 함께 실행되는 프로그램 모듈의 일반적인 맥락(context)에서 제시되나, 당업자는 다른 구현이 다른 유형의 프로그램 모듈과 조합하여 수행될 수 있음을 인지할 것이다. 일반적으로, 프로그램 모듈은 루틴, 프로그램, 컴포넌트, 데이터 구조, 그리고 다른 유형의 구조(특정한 작업을 수행하거나 특정한 추상적 데이터 유형을 구현함)를 포함한다. 더욱이, 당업자는 본 문서에 기술된 대상이 핸드헬드(hand-held) 디바이스, 다중프로세서(multiprocessor) 시스템, 마이크로프로세서 기반 또는 프로그램가능 가전기기, 미니컴퓨터, 메인프레임(mainframe) 컴퓨터 및 유사한 것을 포함하는 다른 컴퓨터 시스템 구성으로써 실시될 수 있음을 인식할 것이다.

이하의 상세한 설명에서, 본 문서의 일부분을 형성하고 구체적인 실시예 또는 예가 예시로서 도시된 첨부된 도면에 대한 언급이 행해진다. 여러 그림을 통틀어 유사한 번호가 유사한 구성요소를 나타내는 도면을 이제 참조하여, 애플리케이션을 배포하기 위한 컴퓨팅 시스템, 컴퓨터 판독가능 저장 매체 및 컴퓨터 구현된(computer-implemented) 방법론의 양상 및 다른 양상이 제시될 것이다.

이제 도 1을 참조하면, 본 문서에 제시된 다양한 실시예를 위한 운영 환경(100)의 양상이 기술될 것이다. 도 1에 도시된 운영 환경(100)은 애플리케이션 스토어(106)에서의 구매를 위해 이용가능하게 될 애플리케이션(104)을 개발하는 애플리케이션 개발자(102)를 포함한다. 본 문서에서 사용된 바와 같이, 애플리케이션이라는 용어는 컴퓨팅 디바이스 상에서의 사용을 위해 구성된 임의의 유형의 소프트웨어 프로그램을 나타낸다. 몇몇 구성에서, 본 문서에 기술된 개념 및 기술은 애플리케이션이 실행되는 컴퓨팅 디바이스의 유형에 한정되는 것은 아니지만, 애플리케이션은 무선 스마트폰(wireless smartphone) 또는 태블릿 컴퓨팅 디바이스(tablet computing device)와 같은 모바일 디바이스(mobile device) 상에서의 사용을 위해 특별히 설계된 프로그램을 포함할 수 있다. 본 문서에서 사용된 바와 같이, "구매"라는 용어는 애플리케이션을 사용할 권리가 허여되거나 애플리케이션을 사용할 능력이 수령되는 트랜잭션(transaction)을 나타낸다. 예를 들어, 구매는 라이센스 하에서 애플리케이션을 사용할 권리의 수령을 포함할 수 있다. 본 문서에서 사용된 바와 같이, "트랜잭션"은 둘 이상의 당사자를 수반하는 활동을 포함한다.

추가적으로, 몇몇 애플리케이션은 작은 소형 프로그램인 반면, 다른 애플리케이션은 더 큰 프로그램일 수 있는바, 본 문서에 기술된 개념 및 기술은 애플리케이션으로 명명된 임의의 특정한 크기의 프로그램에 한정되지 않는다. 또한, 몇몇 구성에서, 애플리케이션은 독립형(standalone) 프로그램일 수 있거나 다른 프로그램 내에서의 실행을 위해 구성된 프로그램일 수 있다. 본 문서에서 사용된 바와 같이, "애플리케이션 스토어"라는 용어는 다양한 로케이션(이로부터 애플리케이션(104)이 구매될 수 있음)을 포함할 수 있다. 예를 들어, 애플리케이션 스토어(106)는 워싱턴주 레드몬드의 마이크로소프트 사(Microsoft Corp.)에 의해 제공되는 윈도우즈 스토어(WINDOWS STORE), 캘리포니아주 쿠퍼티노의 애플 사(Apple Inc.)에 의해 제공되는 아이튠즈(ITUNES) 애플리케이션 스토어, 또는 캘리포니아주 마운틴 뷰의 구글 사(Google, Inc.)에 의해 제공되는 구글 플레이(GOOGLE PLAY) 애플리케이션 스토어일 수 있다.

애플리케이션 개발자(102)는 애플리케이션(104)이 배포되는 조건을 정의하기를 원할 수 있다. 애플리케이션 개발자(102)는 애플리케이션 라이센스 사양(108)을 애플리케이션 스토어(106)에 제공할 수 있다. 애플리케이션 라이센스 사양(108)은 애플리케이션(104)의 라이센싱 조건(licensing terms)을 포함할 수 있다. 본 개시는 임의의 특정한 유형의 라이센스에 한정되는 것은 아니라는 점에 유의하여야 한다. 예를 들어, 애플리케이션 개발자(102)는 GNU GPL, GNU LGPL, APACHE, BSD 및 기타 등등과 같은 오픈 소스 라이센스(open source license)를 사용할 수 있다. 다른 구현에서, 애플리케이션 개발자(102)는 전유적 라이센스(proprietary license)를 사용할 수 있다. 다른 구성에서, 애플리케이션 개발자(102)는 애플리케이션 스토어(106)에 의해 요구되거나 제공되는 라이센스를 사용할 수 있다. 본 문서에 기술된 개념 및 기술은 임의의 특정한 라이센스에 한정되는 것은 아니다. 애플리케이션 개발자(102)는 애플리케이션(104)을 애플리케이션 라이센스 사양(108)과 연관시키고 구매를 위해 애플리케이션 스토어(106) 내에 애플리케이션(104)을 둘 수 있다. 몇몇 구성에서, 애플리케이션 라이센스 사양(108)은 애플리케이션 스토어(106)에 의해 정정되거나 증강될 수 있다. 예를 들어, 애플리케이션 스토어(106)는 애플리케이션(104)에 대해 추가적인 제한을 둘 수 있다. 다른 구성에서, 애플리케이션 라이센스 사양(108)은 애플리케이션 스토어(106)에 캡슐화된 하드코드된 디폴트 라이센스(hardcoded default license), 또는 이의 조합일 수 있다.

애플리케이션 스토어(106) 내에 두어지면, 애플리케이션(104)은 다양한 사용자에 의한 구매를 위해 이용가능하게 될 수 있다. 금번에 개시된 대상의 구현에서, 애플리케이션 발신자(110)는 하나 이상의 애플리케이션 수신자(112A 내지 112N)(이하에서 애플리케이션 수신자(112A 내지 112N)는 집합적 및/또는 총칭적으로 "애플리케이션 수신자(112)"로, 또는 지명(designation)에 의해 개별적으로 "애플리케이션 수신자(112A)", "애플리케이션 수신자(112B)" 등등으로 지칭됨)에 의한 사용을 위해 애플리케이션(104)의 하나 이상의 사본(copy)에 대한 권리를 구매하기를 바랄 수 있다. 본 문서에 개시된 개념 및 기술이 임의의 특정 구현, 특징 또는 이점에 한정되는 것은 아니나, 애플리케이션 발신자(110)는 협력적 환경에서 일하는 경우 애플리케이션 수신자(112)를 위해 애플리케이션(104)의 하나 이상의 사본에 대한 권리를 구매하기를 원할 수 있다.

예를 들어, 애플리케이션 발신자(110)는 애플리케이션 수신자(112)에 의해 작업을 수행하도록 고용된 회사일 수 있다. 애플리케이션 수신자(112)에게 작업 산출물(work product)을 보이기 위해서, 애플리케이션 발신자(110)는 애플리케이션 수신자(112)에 의한 애플리케이션(104)의 한정된 사용을 가능하게 할 필요가 있을 수 있다. 다른 예에서, 애플리케이션 발신자(110) 및 애플리케이션 수신자(112)는 동일한 개체(entity)를 위한 프로젝트에서 일하고 있을 수 있다. 애플리케이션 발신자(110)는, 애플리케이션 수신자(112)와 협력하기 위해서 애플리케이션 수신자(112)에게 애플리케이션(104)을 사용할 것을 요구하는 영역에서의 전문지식을 가질 수 있다. 애플리케이션 발신자(110)는 애플리케이션 수신자(112)에 의한 사용을 위해 애플리케이션(104)을 코디네이트함(coordinating)으로써 협력적인 노력을 가능하게 할 수 있다.

애플리케이션 수신자(112)에 의한 사용을 위해 애플리케이션(104)을 구매하는 경우, 애플리케이션 발신자(110)는 애플리케이션 스토어(106)에 의해 애플리케이션(104)에 가해진 제한 및/또는 애플리케이션 라이센스 사양(108)에 서술되어 애플리케이션 개발자(102)에 의해 부과될 수 있는 임의의 한정 외에 애플리케이션(104)에 대한 어떤 수준의 제어(a level of control)가 요망됨을 판정할 수 있다. 본 문서에서 사용된 바와 같이, 어떤 "수준의 제어"라는 용어는 애플리케이션 발신자(110)의 요구 또는 희망에 따라 애플리케이션(104)의 배포 및/또는 사용을 어떤 방식으로 관리하는 애플리케이션 발신자(110)의 능력을 나타낸다.

애플리케이션 발신자(110)에게 어떤 수준의 제어를 제공하기 위해서, 애플리케이션 발신자(110)는 애플리케이션(104)에 대한 권리를 구매하는 것과 함께 배포 조건(114)의 세트를 제출할 수 있다. 앞서 간략히 언급된 바와 같이, 배포 조건(114)은 애플리케이션 수신자(112)(이를 위해 애플리케이션 발신자(110)가 애플리케이션(104)에 대한 권리를 구매하고 있음)의 신원, 애플리케이션 수신자(112)가 애플리케이션(104)을 사용할 수 있는 시간 및 애플리케이션 수신자(112)가 애플리케이션(104)에 대한 권리를 확보하여야 할 시간을 포함할 수 있으나 이에 한정되지는 않는다. 애플리케이션 발신자(104)는 애플리케이션(104)의 사용 및/또는 배포의 다양한 양상을 제어하기 위해 배포 조건(114)을 변경할 수 있다. 몇몇 구성에서, 애플리케이션 발신자(110)는 애플리케이션(104)의 사용을 수정하기 위해 배포 조건(114)을 수정할 수 있다.

배포 조건(114)은 애플리케이션 스토어(106)에 의해 애플리케이션(104)에 가해진 제한 및/또는 애플리케이션 라이센스 사양(108)에 의해 제어될 수 있다. 애플리케이션 라이센스 사양(108)은 애플리케이션(104)을 수정하기 위한 다양한 당사자의 능력을 한정할 수 있다. 예를 들어, 애플리케이션 라이센스 사양(108)은 애플리케이션(104)의 명칭이 변경될 수 없음을 요구할 수 있다. 다른 예에서, 애플리케이션 라이센스 사양(108)은 화상(imagery), 스크린샷 및 유사한 것을 변경하는 것과 같은, 애플리케이션 내의 다양한 특징의 수정을 한정할 수 있다.

구매를 완료하는 데에 필요한 임의의 정보나 데이터, 또는 만약 어떠한 것이든 요구되는 경우에는 애플리케이션 발신자(104)로부터의 지불의 수령 시에, 인가 토큰(116)이 생성된다. 인가 토큰(116)은 애플리케이션 스토어(106) 또는 다른 개체에 의해 생성될 수 있다. 예를 들어, 애플리케이션 스토어(106)는 배포 조건(114)을 지속시키고 이로부터 인가 토큰(116)을 생성할 수 있다. 인가 토큰(116)은 애플리케이션(104)을 배포 조건(114)과 연관시키기 위해 애플리케이션 스토어(106)에 의해 사용되는 데이터 또는 다른 형태의 정보일 수 있다. 하나의 구현에서, 인가 토큰(116)은 배포 조건(114)을 캡슐화할 수 있다. 다른 구현에서, 인가 토큰(116)은 애플리케이션 라이센스 사양(108)뿐만 아니라 애플리케이션 스토어(106)와 같은 다른 개체에 의해 제공되는 임의의 추가적인 제한 또는 조건도 캡슐화할 수 있다. 추가의 구현에서, 인가 토큰(116)은 애플리케이션 라이센스 사양(108), 배포 조건(114), 애플리케이션 스토어(106)에 의해 애플리케이션(104)에 가해진 제한, 또는 이들의 조합을 캡슐화할 수 있다.

몇몇 구성에서, 애플리케이션 발신자(110)는 새 배포 조건(114)을 제출하거나 현재 사용 중인 배포 조건(114)을 변경함으로써 인가 토큰(116)과 연관된 데이터를 변경할 수 있다. 인가 토큰(116)은 트랜잭션 또는 특정 사용자를 인증하기(authenticate) 위해 사용될 수 있는 데이터, 실행가능 코드(executable code), 하드웨어, 소프트웨어 또는 임의의 다른 기술일 수 있다. 인가 토큰(116)은 삭제될 때까지 영속적일 수 있거나 만료가 있는 일시적인 것일 수 있다.

애플리케이션 발신자(110)는 애플리케이션 수신자(112A 내지 112N)로의 통신 내에 인가 토큰(116)을 발신하여, 애플리케이션(104)의 사용이 애플리케이션 발신자(110)에 의해 확보되었음을 애플리케이션 수신자(112)에게 통지할 수 있다. 상이한 구현에서, 그 통신은 인가 토큰(116)을 포함하지 않을 수 있고, 오히려 어떻게 인가 토큰(116)을 취득할지에 관해 애플리케이션 수신자(112)로의 명령어를 포함할 수 있다. 본 문서에서 사용된 바와 같이, "통신"은 이메일(email), 인스턴트 메시지(instant message), 단문 시스템(Short Message System: SMS) 메시지를 포함하나 이에 한정되지 않는 임의의 유형의 전자 통신을 포함할 수 있다. 그 후에 애플리케이션 수신자(112)는 인가 토큰(116)을 사용하여 애플리케이션(104)의 사용을 획득하고자 애플리케이션 스토어(106)를 액세스하기 위해 네트워크(118)를 액세스할 수 있다. 본 문서에 기술된 개념 및 기술은 네트워크(118)를 위해 사용되는 임의의 특정한 유형의 네트워크에 한정되지 않는다는 점이 인식되어야 한다. 몇몇 구성에서, 네트워크(118)는 인터넷, 인트라넷(intranet), 엑스트라넷(extranet) 또는 이들의 다양한 조합을 포함할 수 있다.

본 개시는 애플리케이션 수신자(112)가 애플리케이션(104)을 사용할 액세스를 얻는 임의의 특정한 방식에 한정되지 않는다. 하나의 구성에서, 만약 애플리케이션(104)이 다운로드되는 소프트웨어인 경우, 애플리케이션 수신자(112)는 애플리케이션(104)을 다운로드하기 위해 애플리케이션 스토어(106)에 인가 토큰(116)을 제출할 것을 요구받을 수 있거나 애플리케이션을 실행하기 위해서 인가 토큰(116)을 사용할 것을 요구받을 수 있다. 다른 구성에서, 만약 애플리케이션(104)이 SaaS로서 배포되는 경우, 애플리케이션 수신자(112)는 애플리케이션(104)에 의해 제공되는 하나 이상의 서비스를 액세스하기 위해 토큰을 사용할 것을 요구받을 수 있다.

몇몇 구성에서, 애플리케이션 발신자(110)는 애플리케이션 스토어(106)와 유사한 방식으로 애플리케이션(104)으로의 액세스를 배포하고 제어할 수 있다. 예를 들어, 애플리케이션 발신자(110)는 애플리케이션 발신자(110)에 의해 사용되는 컴퓨팅 디바이스(도시되지 않음) 상에 애플리케이션(104)의 사본을 저장했을 수 있다. 이 예에서, 애플리케이션(104)이 사용을 위해 준비되어 있음을 애플리케이션 수신자(112)에게 통지하는 통신을 애플리케이션 수신자(112)가 수신하는 경우, 애플리케이션 수신자(112)는 도로 애플리케이션 발신자(110)에게 통신할 수 있다. 트랜잭션의 성공적인 완료 시에, 애플리케이션 수신자(112)는 애플리케이션 스토어(106) 대신에 애플리케이션 발신자(110)로부터 애플리케이션(104)을 수신할 수 있다.

몇몇 구성에서, 애플리케이션 개발자(102)에게 라이센스료(license fees)를 지불하는 것은 어떤 기준에 의해 제어되고 다양한 방식으로 수행될 수 있다. 하나의 구현에서, 애플리케이션 라이센스 사양(108)은 어떻게 라이센스료가 지불되는지 지정할 수 있다. 애플리케이션 라이센스 사양(108)은 값(price), 변제(reimbursement)의 시기뿐만 아니라 다른 조건들도 포함할 수 있다. 애플리케이션(104)은 마이크로소프트 아주어(Microsoft Azure) 상의 스토리지(storage)와 같은 하나 이상의 제3자 서비스를 활용할 수 있다. 그러한 경우에, 애플리케이션 라이센스 사양(108)은 지불하는 이가 발신자인지 또는 수령인인지, 그리고 아마도 어떤 임계(threshold)까지인지 정의할 수 있다. 몇몇 구성에서, 애플리케이션 발신자(110)는 애플리케이션 라이센스 사양(108)에 의해 수립된 지불 조건(payment terms)을 뒤엎는(override) 것이 가능할 수 있다.

몇몇 구현에서, 애플리케이션 라이센스 사양(108)은 수신자의 어떤 특성, 이를테면 그가 사는 나라 또는 그가 사용하는 소프트웨어와 같은 것에 기반하여 상이한 가격(price point)들을 정의할 수 있다. 예를 들어, 만약 애플리케이션 발신자(110) 또는 애플리케이션 수신자(112)가 개발자(102)에 의한 다른 애플리케이션을 이미 소유한 경우 애플리케이션 라이센스 사양(108)은 할인을 제공할 수 있다. 몇몇 구현에서, 만약 애플리케이션 발신자(110)가 일정한 수의 애플리케이션 수신자(112)를 위해 애플리케이션(104)을 구입하는 경우 애플리케이션(104)의 구매 가격(purchase price)은 할인될 수 있다. 몇몇 구성에서, 만약 애플리케이션 발신자(110)가 애플리케이션 라이센스 사양(108)에 의해 지정된 바와 같이 구매에서 어떤 쿠폰 코드(coupon code)를 제공하는 경우에 그러한 할인이 유효할 뿐일 수 있다. 다른 예에서, 애플리케이션 수신자(112) 중 하나가 특정 특징의 사용과 같은, 애플리케이션(104)과 연관된 어떤 행위(act)를 수행하는 경우에 애플리케이션(104)의 지불이 처리될 뿐일 수 있다. 이 지불 변형들 및 다른 지불 변형들은 본 개시의 범주 내에 있는 것으로 간주된다.

라이센스 지불은 다양한 방식으로 처리될 수 있다. 하나의 구성에서, 애플리케이션 발신자(110)가 애플리케이션(104)을 사용할 권리에 대해 애플리케이션 스토어(106)에 지불을 보내는 경우에 라이센스 지불은 처리될 수 있다. 다른 구성에서, 라이센스 지불은 차후에 처리될 수 있다. 예를 들어, 애플리케이션 수신자(112) 중 하나가 애플리케이션(104)을 사용하기 위해 애플리케이션 스토어(106)에 통신을 보내는 경우에 라이센스 지불은 처리될 수 있다. 본 문서에 기술된 개념 및 기술은 라이센스 지불의 임의의 특정한 구현에 한정되는 것은 아니고, 그 개념 및 기술은 지불을 요구하는 애플리케이션에 한정되는 것도 아니라는 점이 인식되어야 한다.

운영 환경(100)은 감사(audit)를 수행하는 애플리케이션 발신자(110)의 능력을 제공할 수도 있다. 애플리케이션 발신자(110)는 애플리케이션 수신자(112)가 애플리케이션(104)을 사용하는 올바른 당사자임을 확인하는 것을 포함하나 이에 한정되지 않는 다양한 이유로 감사를 수행하기를 바랄 수 있다. 애플리케이션 발신자(110)는 애플리케이션(104)을 사용할 권리에 대한 지불을 제출하는 당사자일 수 있으므로, 애플리케이션 발신자(110)는 애플리케이션(104)이 애플리케이션 발신자(110)에 의해 수립된 배포 조건(114)의 세트에 따라 배포되고 있게끔 하기를 원할 수 있다. 예를 들어, 애플리케이션 발신자(110)는 애플리케이션 수신자(112)의 리스트(list) 및 인가 토큰(116)의 상환(redemption)의 날짜를 포함하나 이에 한정되지 않는 다양한 정보를 제공받을 수 있다. 몇몇 경우에, 애플리케이션 수신자(112) 중 특정한 하나의 신원은 확실하지 않을 수 있다. 그런 구성에서, 다른 사용뿐만 아니라 감사의 수행에 도움이 되기 위해, 애플리케이션 발신자(110)는 애플리케이션(104)에 대한 액세스를 제공하기 전에 애플리케이션 수신자(112)의 개인적으로 식별가능한 정보(personally identifiable information)를 요구할 수 있다. 몇몇 구현에서, 애플리케이션 발신자(110)는 감사로부터 수신된 정보를 사용하여 애플리케이션 수신자(112) 중 하나 이상의 라이센스를 폐지하거나(retract) 철회하는 것이 가능할 수 있다.

애플리케이션 수신자(112A 내지 112N)가 애플리케이션 토큰(116)에 의해 캡슐화된 조건에 따라 트랜잭션을 완료하면, 애플리케이션 수신자(112)는 수신자 라이센스(119)를 수신할 수 있다. 몇몇 구성에서, 수신자 라이센스(119)의 조건은 애플리케이션 라이센스 사양(108), 배포 조건(114), 그리고/또는 애플리케이션 스토어(106)에 의해 부과된 제한에 기반하여 수립된다. 수신자 라이센스(119)는 애플리케이션 발신자(110)에 의해 제출된 배포 조건(114)을 나타내지 않는 라이센스와는 상이할 수 있다. 예를 들어, 배포 조건(114)은 애플리케이션 수신자(112)가 활용할 수 있는 서비스의 한정된 범위 또는 사용의 한정된 시간을 지정할 수 있는 반면, 애플리케이션 라이센스 사양(108)은 유사한 제한을 갖지 않을 수 있다.

또한, 수신자 라이센스(119)는 애플리케이션 수신자(112)로부터의 입력 없이 바뀔 수 있다. 예를 들어, 애플리케이션 발신자(110)는 애플리케이션(104)의 배포 조건(114)을 수정할 수 있다. 배포 조건(114)에서의 변화는 인가 토큰(116)을 수정할 수 있는데, 이는 결국 수신자 라이센스(119)를 수정할 수 있다. 몇몇 구성에서, 이는 애플리케이션(104)을 사용하는 애플리케이션 수신자(112)의 권리를 철회할 수 있다. 애플리케이션(104)을 사용하는 애플리케이션 수신자(112)의 권리 또는 능력은 다른 방식으로 철회될 수 있다. 한정으로서가 아니라 예로 들면, 애플리케이션 스토어(106)는 애플리케이션(104)을 사용하는 애플리케이션 수신자(112)의 권리를 수정할 수 있다. 애플리케이션 발신자(110)는 애플리케이션(104)의 사용을 철회하기 위해 인터페이스를 액세스할 수 있다. 이들 구성 및 다른 구성은 본 개시의 범주 내에 있는 것으로 간주된다.

애플리케이션 수신자(112)에 의한 애플리케이션(104)의 사용을 철회하는 이유는 달라질 수 있다. 예를 들어, 만약 애플리케이션(104)의 사용이 가입 기반으로 구매되는 경우, 트랜잭션에서 사용된 신용 카드의 만료는 장래의 지불을 보장하기 위해서 애플리케이션을 사용하는 권리가 철회됨을 요구할 수 있다. 다른 예는 애플리케이션 발신자(110)가 환불(이는 애플리케이션 수신자(112)의 수신자 라이센스(119)를 철회함)을 받을 수 있다는 것일 수 있다. 추가의 예는 애플리케이션 발신자(110)가 애플리케이션(104)의 한시적 사용(이는 이어서 시간의 만료 시에 철회되게 됨)을 구매했을 뿐일 수 있다는 것일 수 있다. 또 다른 예는 애플리케이션 발신자(110)가 100 텍스트 효과 생성됨과 같은 유한한 세트의 소모성요소(a finite set of consumables)를 위해 애플리케이션(104)의 사용을 구매했을 뿐일 수 있다는 것일 수 있다. 소모성요소가 사용된 후, 애플리케이션(104)의 사용은 철회될 수 있다. 다른 예에서, 애플리케이션 발신자(104)는 애플리케이션을 사용하는 애플리케이션 발신자(110)의 권리의 한시적 사용을 이전할 수 있다. 해당 시간이 만료한 후, 애플리케이션(104)을 사용하는 권리는 도로 애플리케이션 발신자(110)에게 복귀될 수 있다. 본 개시는 철회의 임의의 특정한 이유에 한정되지 않는다는 점이 이해되어야 한다.

전술된 바와 같이, 금번에 개시된 대상은 단일 애플리케이션의 제어에 한정되지 않는다. 본 문서에 기술된 다양한 개념 및 기술은 다수의 애플리케이션을 제어하기 위해 사용될 수 있다. 예를 들어, 도 2는 여러 애플리케이션이 번들화될 수 있는 다른 예시적 운영 환경(200)을 도시한다. 도 2의 운영 환경(200)에서, 애플리케이션 발신자(110)는 애플리케이션 수신자(112)에 의한 사용을 위해 애플리케이션 그룹(104A 내지 104N) 내 다수의 애플리케이션을 지정하였다. 운영 환경(200)에서, 애플리케이션 발신자(110)는 애플리케이션 그룹(104A 내지 104N)을 번들화하였다. 애플리케이션 그룹(104A 내지 104N)은 다수의 애플리케이션(104)을 포함한다. 본 문서에 기술된 개념 및 기술은 임의의 특정한 이점에 한정되지는 않으나, 애플리케이션 그룹(104A 내지 104N)을 번들화하는 것은 다양한 이점을 제공할 수 있다. 예를 들어, 애플리케이션 수신자(112)로 하여금 애플리케이션 그룹(104A 내지 104N)을 형성하는 애플리케이션 각각을 개별적으로 구매하게 강요하는 대신에, 애플리케이션 수신자(112)는 단일의 트랜잭션에서 애플리케이션 그룹(104A 내지 104N)을 사용하는 권리를 수신할 수 있다. 애플리케이션 수신자(112)는 별개의 라이센스에 합의하는 것, 별개의 지불을 행하는 것, 또는 하나의 애플리케이션과 연관된 트랜잭션을 마치고 나서 다른 애플리케이션을 수반하는 트랜잭션으로 진행하는 것이 필요하지 않을 수 있다.

애플리케이션(104A 내지 104N)은 도 3a 및 도 3b에 예로서 보여진 다양한 방식으로 번들화될 수 있다. 도 3a에서, 애플리케이션(104A 내지 104C)이 단일 유닛(unit)으로서 동작하도록 애플리케이션(104A 내지 104C)의 기능성은 링크된다(linked). 예를 들어, 애플리케이션(104A 내지 104C) 중 각 애플리케이션은, 애플리케이션(104A 내지 104C) 중 다른 애플리케이션과 조합되는 경우 기능적으로 필요하거나 원하는 것을 제공할 수 있는 하나 이상의 기능을 수행할 수 있다. 다른 구현에서, 애플리케이션 발신자(110)는 애플리케이션 그룹(104A 내지 104N) 내의 상이한 애플리케이션에 대한 갖가지 수준의 액세스를 구매했을 수 있다. 예를 들어, 특정한 목적을 달성하는 데에 애플리케이션(104A)의 완전한 사용(full use)이 필요할 수 있는 반면에, 애플리케이션(104B)의 사용 중 약간만 또는 애플리케이션(104B)의 시험 사용(trail use)이라도 필요할 수 있다. 다른 구현에서, 애플리케이션은 새 애플리케이션을 형성하도록 통합되거나(integrated) 전부터 존재하는 애플리케이션 내에 통합될 수 있는데, 도 3b에 예로서 보여진다. 애플리케이션(104A)의 기능성은 애플리케이션(104B) 및 애플리케이션(104C)의 기능성에 의해 향상되거나 아니면 증강될 수 있다. 몇몇 구성에서, 애플리케이션(104A 내지 104N)을 번들화하는 능력은 각각의 특정한 애플리케이션을 위한 애플리케이션 라이센스 사양(208A 내지 208N)에 기반할 수 있다.

도 3a 및 도 3b에 예시된 바와 같이, 다양한 애플리케이션의 기능성은 다른 애플리케이션과 함께 증강되거나 합쳐질(joined) 수 있거나, 다른 것은 그것의 기능성이 다른 애플리케이션 내에 통합될 수 있다. 본 문서에 기술된 개념 및 기술의 몇몇 구현에서, 다양한 애플리케이션을 사용하는 데에 요구되는 라이센스는 서로 안에 통합될 수 있고 단일의 인가 토큰에 의해 서비스될 수 있다. 예를 들어, 애플리케이션(104A)에 대한 라이센스는 그것 내에 애플리케이션(104B 및 104C)에 대한 라이센스를 통합했을 수 있다. 그러므로, 이 구성에서, 애플리케이션 수신자(112)는 애플리케이션(104A)을 사용하는 권리를 입수하는 경우 별도의 트랜잭션에서 애플리케이션(104B 및 104C)에 대한 권리를 확보하는 것이 필요하지 않을 수 있는데, 애플리케이션(104A)에 대한 라이센스가 애플리케이션(104B 및 104C)에 대한 라이센스를 나타낸 것이기 때문이다.

다른 구성에서, 도 3a에 예로서 보여질 수 있는 바와 같이, 애플리케이션에 대한 라이센스는 함께 합쳐질 수 있다. 전술된 바와 같이, 애플리케이션(104A 내지 104C)은 기능적으로 조합되나 서로 안에 포함되지는 않는다. 그런 구현에서, 애플리케이션(104A 내지 104C)에 대한 라이센스는 합쳐지나 인가 토큰(116)의 사용을 통하여 집합적으로 승인될 수 있다. 예를 들어, 애플리케이션(104A 내지 104C)에 대한 라이센스는 단일한 형태로 사용자에게 디스플레이될 수 있다. 사용자는 배포 조건(114)을 수락하는 경우 결국 애플리케이션(104A 내지 104C)에 대한 라이센싱 조건을 묵시적으로 승인할 수 있다.

도 2로 돌아와서, 애플리케이션 발신자(110)는 애플리케이션(104)을 사용하는 능력을 애플리케이션 수신자(112)에게 허용하는 정보를 제공하는 통신을 애플리케이션 수신자(112)에게 보낼 수 있다. 이 구성에서, 단일 애플리케이션의 배포를 제어하는 것 대신에, 인가 토큰(116)은 애플리케이션 그룹(104A 내지 104N)의 배포를 제어하기 위해 사용될 수 있다. 그러므로, 이 구성에서, 애플리케이션 그룹(104A 내지 104N)이 번들화되는 경우, 인가 토큰(116)과 연관된 애플리케이션 라이센스 사양(108)은 애플리케이션 그룹(104A 내지 104N) 내의 애플리케이션 전부를 위한 라이센스 사양을 포함할 수 있는데, 도 2에서 애플리케이션 라이센스 사양(208A 내지 208N)으로 표현된다. 임의의 특정한 이유에 한정되는 것은 아니나, 애플리케이션 라이센스 사양(208A 내지 208N)을 단일 라이센스로 함께 번들화되게 하는 것은 애플리케이션 수신자(112)에 의한 애플리케이션 그룹(104A 내지 104N)의 사용의 편리함 및 또는 용이함을 증가시킬 수 있다.

몇몇 구성에서, 애플리케이션 수신자는 애플리케이션의 최종 사용자(end user)는 아니고, 오히려 애플리케이션을 다른 패키지(package) 내에 통합하는 사람 또는 개체이다. 예를 들어, 애플리케이션 수신자는 소매 시장에서의 판매를 위한 다수의 애플리케이션을 패키지하는 부가 가치 재판매자(Value Added Reseller: VAR)일 수 있다. 도 4는 애플리케이션 수신자가 판매를 위한 하나 이상의 애플리케이션을 패키지할 수 있는 시스템(400)의 예시이다.

도 4에 예시된 바와 같이, 애플리케이션 개발자(102A)는 애플리케이션 발신자(110)가 애플리케이션 수신자(112A)에 의한 사용을 위해 제공하기를 바라는 애플리케이션(104A)을 개발하였다. 시스템(400)에 의해 예시된 구현에서, 애플리케이션 수신자(112A)는 VAR이다. 애플리케이션 수신자(112A)는 애플리케이션(104A)에 대한 애플리케이션 라이센스 사양(108A)을 수신하고 애플리케이션(104A)을 애플리케이션 개발자(102B)에 의해 개발된 애플리케이션(104B)과 패키지한다. 전술된 바와 같이, 애플리케이션 라이센스 사양(108A)은 애플리케이션(104A)에 대해 제한을 둘 수 있다.

앞서 주어진 예 외에, 애플리케이션 라이센스 사양(108A)은 라이센스료의 구분(breakdown)을 제공할 수 있다. 예를 들어, 애플리케이션 수신자(112A)는 라이센스료의 특정 비율을 가질 수 있고 애플리케이션 스토어(106)는 특정 비율을 가질 수 있으며, 나머지는 애플리케이션 개발자(102A)에게 간다. 추가의 구성에서, 만약 애플리케이션 수신자(112A) 없이 애플리케이션(104A)의 직접 판매가 수행되는 경우 애플리케이션 라이센스 사양(108A)은 라이센스료 배당(license fee splits)을 제공할 수도 있다. 애플리케이션 라이센스 사양(108A)의 이들 예 및 다른 예는 본 개시의 범주 내에 있는 것으로 간주된다.

애플리케이션 수신자(112A)는 애플리케이션(104A) 및 애플리케이션(104B)의 조합이 애플리케이션 수신자(112B)에 의한 사용을 위해 이용가능함을 애플리케이션 수신자(112B)와 통신할 수 있다. 애플리케이션 수신자(112B)는 애플리케이션 스토어(106)와 인터페이스할 수 있고, 인가 토큰(116)의 유효화(validation) 또는 확인(verification)을 통해 애플리케이션(104A) 및 애플리케이션(104B)의 조합을 사용하기 위해 필요한 허가 및 소프트웨어를 수신할 수 있다.

도 4에 예로서 보여진 바와 같이, VAR, 가령 애플리케이션 수신자(112A)(또는 다른 개체)는 애플리케이션 수신자(112B)가 사용을 위해 한 개보다 많은 애플리케이션을 수신하는 더 용이하거나 더 효율적인 방식을 제공하는 것이 가능할 수 있다. 애플리케이션 수신자(112A)는 각각 애플리케이션(104A) 및 애플리케이션(104B)에 대응하는 애플리케이션 라이센스 사양(108A) 및 애플리케이션 라이센스 사양(108B)을 함께 번들화하고, 애플리케이션(104A 및 104B)을 사용하기 위해 애플리케이션 수신자(112B)에 의해 단일의 구매가 수행될 수 있는 트랜잭션을 가능하게 할 수 있다.

또한, 도 4의 시스템(400)은 구매를 위해 다양한 조합으로 다양한 애플리케이션을 조합하는 융통성(flexibility)을 VAR에게 제공할 수 있다. 추가적으로, VAR은 애플리케이션(104A 및 104B)의 조합의 배포 및 사용을 제어하기 위해 인가 토큰(116)을 사용할 수 있다. 그런 방식으로, 몇몇 구현에서, 본 문서에 기술된 개념 및 기술은 인가 토큰(116)의 단일 인스턴스(instance)의 사용을 통해 확보되는 사용권과 함께 다수의 애플리케이션의 조합을 제공함으로써 다수의 개발자의 상호작용을 가능하게 할 수 있다.

몇몇 구성에서, 하나보다 많은 애플리케이션 발신자(110)가 함께 작업하는 것이 유리할 수 있다. 도 5는 애플리케이션 수신자에 의한 애플리케이션의 사용을 제공하기 위해 리소스를 조합하는 다수의 애플리케이션 발신자(110A 및 110B)를 보여주는 예시적 시스템(500)이다. 애플리케이션 발신자(110A 및 110B)가 도 5에 예시된다. 도 5에 보여진 예시적인 구현에서, 애플리케이션 발신자(110A) 및 애플리케이션 발신자(110B)는 애플리케이션(104)에 대한 권리를 확보하였다. 애플리케이션 발신자(110A)는 애플리케이션(104)의 3개의 사용(또는 "자리(seat)")를 허용하는 권리를 확보하였고 애플리케이션 발신자(110B)는 애플리케이션(104)의 6개의 자리를 허용하는 권리를 확보하였다. 애플리케이션 수신자(112)는 8개의 자리를 사용할 필요가 있다. 그러므로, 애플리케이션 발신자(110A)도 애플리케이션 발신자(110B)도 애플리케이션 수신자(112)에 의해 요구되는 8개의 자리를 개별적으로 제공할 수는 없다.

따라서, 이 구성에서, 애플리케이션 발신자(110A)는 애플리케이션 스토어(106)에서 애플리케이션 발신자(110B)에 의해 확보된 자리와 자신의 자리의 사용을 조합할 수 있다. 애플리케이션 수신자(112)는 애플리케이션 수신자(112)가 애플리케이션 발신자(110A)와 연관된 인가 토큰(116A) 및 애플리케이션 발신자(110B)와 연관된 인가 토큰(116B)을 사용하는 권리를 가짐을 애플리케이션 스토어(106)과 통신할 수 있다. 조합된 인가 토큰(116A 및 116B)과의 자리의 개수가 애플리케이션(112)에 의해 요구되는 개수를 초과하기 때문에, 애플리케이션 수신자(112)는 애플리케이션 발신자(110A) 및 애플리케이션 발신자(110B)에 의해 수립된 조건 하에 애플리케이션(104)의 사용을 확보하는 것이 가능하다. 전술된 바와 같이, 이 조건은 사용을 위해 허용된 시간, 애플리케이션이 다운로드될 수 있는 시간은 물론, 애플리케이션(104)의 개발자에 의해 개진된 라이센싱 조건을 포함할 수 있다.

도 6은 애플리케이션 라이센스 사양(108)의 조건을 지정함으로써 개발자가 어떻게 애플리케이션 라이센스를 제어할 수 있는지 예시하는 시스템 다이어그램 및 사용자 인터페이스("UI")이다. 시스템(600)은 라이센싱 조건이 애플리케이션(104) 내에 포함될 수 있는 예시적인 방식을 보여준다. 시스템(600)은 개발자(102)가 개발하였거나 현재 개발 중인 애플리케이션(104)을 포함한다. 본 개시는 애플리케이션 라이센스 사양(108)의 조건을 지정하기 위한 시스템(600)의 사용에 한정되지 않는다는 점이 이해되어야 한다. 한정으로서가 아니라 예로 들면, 애플리케이션 개발자(102)는 애플리케이션(104) 패키지 내에 직접 조건을 지정할 수 있는데, 이를테면 애플리케이션(104)과 연관된 명시목록(manifest)과 같은 것이다. 개발 중에, 애플리케이션 개발자(102)는 어떤 라이센싱 조건이 애플리케이션(104)에 적용되기를 바랄 수 있다. 임의의 특정한 유형의 라이센스에 한정되는 것은 아니나, 이 조건은 사용할 권리, 복사할 권리, 배포할 권리는 물론, 사용자에게 가해진 어떤 사용 의무 또는 제약을 포함할 수 있다.

시스템(600)에서, 애플리케이션 개발자(102)는 라이센스 UI(602)를 제시받을 수 있다. 라이센스 UI(602)는 애플리케이션 개발자(102)로부터 입력을 수신하는 것을 가능하게 할 수 있는 하나 이상의 체크 박스(check box) 또는 다른 유형의 UI 컨트롤을 가질 수 있다. 라이센스 UI(602)에서, 몇몇 예시적인 입력은 애플리케이션을 재라이센스하는(sublicense) 최종 사용자의 권리, 수익(가령, 로열티)이 어떻게 평가될(assessed) 것인지, 애플리케이션(104)이 다른 애플리케이션과 임베드될(embedded) 수 있는지 여부, 애플리케이션(104)이 애플리케이션 개발자(102)에 의해 개발된 다른 애플리케이션과 함께 리스트될(listed) 것인지, 당사자가 애플리케이션(104)에 다시 브랜드를 붙일(rebrand) 수 있는지, 또는 애플리케이션(104)의 사용과 연관된 소모성요소의 한도(quota)를 포함한다. 본 문서에 기술된 개념 및 기술은 라이센스 UI(602)의 임의의 특정한 라이센싱 조건 또는 구현에 한정되지 않는다는 점이 인식되어야 한다.

라이센스 UI(602)는 애플리케이션 개발자(102)에 의해 입력된 라이센싱 조건을 수신하도록 구성된다. 애플리케이션 스토어(106)는 라이센스 UI(602)에 입력된 라이센싱 조건을 수신한다. 애플리케이션 수신자(112)가 애플리케이션(104)을 사용하는 권리를 확보하는 경우, 라이센스 UI(602)로부터 수신된 라이센싱 조건은 인가 토큰(116) 내에 통합될 수 있다. 다른 구현에서, 애플리케이션(104)을 포함하는 이진(binary) 패키지가 애플리케이션 라이센스 사양(108)을 포함할 수도 있다. 추가의 예에서, 애플리케이션 라이센스 사양(108)은 애플리케이션 스토어(106) 내에 애플리케이션(104)과는 별도로 저장될 수 있다. 전술된 바와 같이, 애플리케이션 발신자(110)가 배포 조건(114)을 정의하는 경우, 배포 조건(114)은 애플리케이션 라이센스 사양(108)에 의해 제한될 수 있다.

이제 도 7로 나아가면, 하나의 예시적 실시예에 따라, 애플리케이션을 배포하는 메커니즘을 제공하는 방법(700)의 양상이 예시된다. 애플리케이션을 배포하는 메커니즘을 제공하기 위해 방법(700)의 다양한 구현이 사용될 수 있다. 본 문서에 개시된 방법(700) 및 다른 방법의 동작들은 반드시 임의의 특정한 순서로 제시되는 것은 아니라는 점 및 대안적인 순서(들)의 동작들 중 몇몇 또는 전부의 수행이 가능하고 고려된다는 점이 이해되어야 한다. 동작들은 설명 및 예시의 용이성을 위해 보여진 순서로 제시되었다. 부기된 청구항의 범주로부터 벗어나지 않고 동작들이 추가, 생략 및/또는 동시에 수행될 수 있다. 예시된 방법은 언제라도 종료될 수 있고 그 전체로서 수행될 필요는 없다는 점이 또한 이해되어야 한다.

방법의 몇몇 또는 모든 동작 및/또는 실질적으로 균등한 동작은 본 문서에 정의된 바와 같이, 컴퓨터 저장 매체 상에 포함된 컴퓨터 판독가능 명령어의 실행에 의해 수행될 수 있다. 설명 및 청구항에서 사용된 바와 같은 "컴퓨터 판독가능 명령어"라는 용어 및 이의 변형은 루틴, 애플리케이션, 애플리케이션 모듈, 프로그램 모듈, 프로그램, 컴포넌트, 데이터 구조, 알고리즘 및 유사한 것을 포함하도록 본 문서에서 포괄적으로 사용된다. 컴퓨터 판독가능 명령어는 단일 프로세서(single-processor) 또는 다중 프로세서(multiprocessor) 시스템, 미니 컴퓨터, 메인프레임 컴퓨터, 개인용 컴퓨터, 핸드헬드 컴퓨팅 디바이스, 마이크로프로세서 기반 프로그램가능 가전기기, 이들의 조합, 그리고 유사한 것을 포함하는 다양한 시스템 구성 상에 구현될 수 있다.

그러므로, 본 문서에 기술된 논리적(logical) 동작은 (1) 컴퓨팅 시스템 상에서 실행되는 컴퓨터 구현된 행위 또는 프로그램 모듈의 시퀀스(sequence)로서 및/또는 (20) 컴퓨팅 시스템 내의 상호연결된 머신(machine) 논리 회로 또는 회로 모듈로서 구현된다는 점이 인식되어야 한다. 구현은 컴퓨팅 시스템의 성능 및 다른 요구사항에 따른 선택의 문제이다. 이에 따라, 본 문서에 기술된 논리적 동작은 상태, 동작, 구조적 디바이스, 행위 또는 모듈로서 다양하게 지칭된다. 이들 동작, 구조적 디바이스, 행위 및 모듈은 소프트웨어로, 펌웨어로, 특수 목적 디지털 논리로, 그리고 이들의 임의의 조합으로 구현될 수 있다.

도 7로 나아가면, 방법(700)이 시작하여 동작(702)으로 진행하는데, 여기서 애플리케이션(104)을 배포하기 위해 입력이 수신된다. 임의의 특정한 출처(origin)에 한정되는 것은 아니나, 애플리케이션(104)을 배포하기 위한 입력은 애플리케이션 발신자(110)에 의해 생성될 수 있다. 애플리케이션 발신자(110)는 하나 이상의 애플리케이션 수신자(112A 내지 112N)와 협력하기 위해서 애플리케이션 스토어(106)에 배포를 위해 위치된(located) 애플리케이션(104)이 필요하거나 요망됨을 판정할 수 있다. 몇몇 구성에서, 애플리케이션 발신자(110)는 애플리케이션 스토어(106)를 액세스하고 애플리케이션(104)을 선택할 수 있다. 다른 구성에서, 애플리케이션 발신자(110)는 시스템을 액세스하고 하나 이상의 애플리케이션에 의해 제공될 기능적 기준을 입력할 수 있다. 그리고 전술된 시스템은 입력을 처리하고 배포를 위해, 애플리케이션 발신자(110)에 의해 개진된 기능적 기준을 충족시키는 하나 이상의 애플리케이션을 선택할 수 있다.

동작(702)으로부터, 방법(700)은 동작(704)으로 진행하는데, 여기서 배포 조건(114)이 수신된다. 배포 조건(114)은 애플리케이션 수신자(112)의 신원, 애플리케이션 수신자(112)가 애플리케이션(104)을 사용하는 권리 및 능력을 확보할 수 있는 기간(timeframe), 또는 애플리케이션 수신자(112)가 애플리케이션(104)을 사용할 수 있는 기간을 포함할 수 있으나 이에 한정되지는 않는다. 배포 조건(114)은 애플리케이션 발신자(110) 또는 다른 개체에 의해 생성될 수 있다. 하나의 예에서, 애플리케이션 발신자(110) 및 애플리케이션 수신자(112)는 다양한 기준(이에 따라 애플리케이션 발신자(110) 및 애플리케이션 수신자(112)가 일함)을 수립한 조직을 위해 일할 수 있다. 그러므로, 이 예에서, 배포 조건(114)은 애플리케이션 발신자(110) 및 애플리케이션 수신자(112) 간 협력을 증진하거나 운용하기 위해서 그 개체에 의해 생성될 수 있다. 본 문서에 기술된 개념 및 기술은 배포 조건(114)의 어떠한 특정한 소스 또는 유형에도 한정되지 않는다는 점이 이해되어야 한다.

동작(704)으로부터, 방법(700)은 동작(706)으로 진행하는데, 여기서 배포 조건(114)이 확인된다. 애플리케이션 스토어(106)는, 스토어 정책과 같은, 애플리케이션 스토어(106)의 지정된 제한 및 애플리케이션 라이센스 사양(108)의 지정된 제한에 대비하여 배포 조건(114)의 어떤 수준의 확인을 가질 수 있는 한편, 추가의 사용자 특정 체크(user-specific check)가 이루어질 수 있다. 동작(706)에서, 애플리케이션 수신자(112)에 관해 정보가 획득된다. 그 정보는 애플리케이션 수신자(112)가 전에 애플리케이션(104)을 소유하였는지, 애플리케이션 수신자(112)가 애플리케이션 개발자(102)가 배포하기를 바라는 나라 출신인지, 그리고 유사한 것을 포함할 수 있으나 이에 한정되지는 않는다.

몇몇 구현에서, 애플리케이션(104)을 사용하기 위한 요청을 제출하기 전에 애플리케이션 수신자(112)는 인간 판독가능한(human-readable) 개인적 명칭 또는 사용의 정당성과 같은 추가 정보를 제공할 수 있거나 제공하지 않을 수 있다. 이들 구현에서, 특정한 애플리케이션 수신자(112)가 제공하는 임의의 정보 외에, 그 애플리케이션 수신자(112)의 신원이 애플리케이션 발신자(110)에게 송신될 수 있다. 그리고 애플리케이션 발신자(110)는 이 정보를 검토하고 인가 토큰(116)과 함께 특정한 애플리케이션 수신자(112)를 위한 수신자 라이센스(119)를 만들어낼 수 있다. 예를 들어, 애플리케이션 발신자(110)는 한 팀에게 그 팀이 소셜 분석 도구(social analysis tool)의 가장 알맞은 사용자를 위해 애플리케이션(104)의 5개의 라이센스를 취득하였음을 알리는 그룹 이메일(group email)을 발신할 수 있다. 이 예에서, 애플리케이션 수신자(112)는 애플리케이션(104)의 사용을 요청할 수 있다. 애플리케이션 발신자(110)는 애플리케이션(104)의 사용을 요청하는 애플리케이션 수신자(112) 중 어느 다섯이 애플리케이션(104)을 사용할 수 있는지 판정하기 위해 애플리케이션 수신자(112)에 의해 제공된 정보를 사용할 수 있다.

다른 예에서, 애플리케이션 라이센스 사양(108)은 애플리케이션(104)의 사용이 인가 토큰(116)에 의해 지정되거나 배포 조건(114)의 수령 당시에 알려진 개인을 위해 수립될 뿐이어야 함을 요구할 수 있다. 몇몇 구현에서, 이 요구를 가능하게 하기 위해, 애플리케이션 수신자(112)는 애플리케이션 스토어(106)에 알려진 신원 및 사용자이름(username)으로써 서명접속할 것을 요구받을 수 있다. 추가의 주입에서, 인가 토큰(116)은 애플리케이션 수신자(112)가 수신자 라이센스(119)를 허여받기 위해 특정한 암호 또는 PIN이 입력되어야 함을 요구할 수 있다. 그리고 이 정보는 인가 토큰(116) 내에서 송신되는 바와 같은 배포 조건(114)에 대해 비교될 수 있다.

만약 애플리케이션 라이센스 사양(108)이 애플리케이션(104)으로 하여금 배포 조건(114)에 따라 배포되게 하는 경우, 방법(700)은 동작(708)으로 진행되는데, 여기서 인가 토큰(116)이 생성되어 애플리케이션 발신자(110)에 송신된다. 인가 토큰(116)은 애플리케이션 라이센스 사양(108) 내에 식별된 조건, 배포 조건(114) 및 애플리케이션 스토어(106)에 의해 추가된 임의의 제한을 캡슐화할 수 있다. 또한, 인가 토큰(116)은 인가 토큰(119)에 의해 캡슐화된 정보에 따라 생성된 수신자 라이센스(119)를 캡슐화할 수도 있다. 인가 토큰(116)은 애플리케이션(104)의 배포를 제어하기 위해 애플리케이션 발신자(110)에 의해 사용될 수 있다. 추가의 구현에서, 수신자 라이센스(119)는 애플리케이션 수신자(112)에 의한 애플리케이션(104)의 사용이 인가될 때까지 생성되지 않을 수 있다.

전술된 바와 같이, 인가 토큰(116)은 소프트웨어, 하드웨어, 암호, 또는 다른 형태의 정보 또는 기술일 수 있는데, 본 문서에 기술된 개념 및 기술은 인가 토큰(116)을 위한 임의의 특정한 형태에 한정되지는 않는다. 인가 토큰(116)이 생성되어서, 배포 조건(114) 하에서 애플리케이션 발신자(110)에 의한 애플리케이션(104)의 성공적인 구매를 나타내면, 애플리케이션 발신자(110)는 애플리케이션 수신자(112)에게 통신을 보내어 애플리케이션 수신자(112)로 하여금 애플리케이션(104)을 액세스하고 사용하게 하는 정보를 제공할 수 있다. 애플리케이션(104)의 구매에 관한 트랜잭션은 앞서 제공된 구성이 아닌 방식으로 발생할 수 있다는 점이 이해되어야 한다. 예를 들어, 배포 조건(114) 또는 인가 토큰(116)은 애플리케이션(104)을 사용할 수 있기 전에 애플리케이션 수신자(112)가 애플리케이션 스토어(106)에 어떤 형태의 지불을 송부하여야(remit) 함을 지정할 수 있다.

방법(700)은 동작(710)으로 진행하는데, 여기서 애플리케이션(104)의 사용을 요청하는 애플리케이션 수신자(112) 중 하나 이상으로부터 통신이 수신된다. 그 통신은, 애플리케이션 수신자(112)가 인가 토큰(116)에 따라 제공하도록 요구받을 수 있는 다른 정보와 함께, 인가 토큰(116)이 애플리케이션 수신자(112)에게 송신되었던 경우에는 인가 토큰(116)을 포함할 수 있다.

동작(710)으로부터, 방법(700)은 동작(712)으로 진행되는데, 여기서 인가 토큰(116)에 따라 트랜잭션이 확인된다. 예를 들어, 인가 토큰(116)은 그 통신을 제출하는 당사자가 애플리케이션(104)을 수신할 올바른 당사자임을 확인하기 위해서 애플리케이션 수신자(112)가 제시하여야 하는 어떤 식별 요구를 가질 수 있다. 다른 구현에서, 인가 토큰(116)은 확인된 정보일 수 있다. 예를 들어, 몇몇 구성에서, 그 통신을 제출하는 당사자는 인가 토큰(116)의 소유를 할 수 있다. 인가 토큰(116)은 자가확인(self-verifying) 데이터일 수 있다. 다른 구성에서, 그 통신을 수신하는 개체는 애플리케이션 발신자(110)와 통신하며 그 통신을 제출하는 개체를 애플리케이션 발신자(110)가 확인할 것을 요청할 수 있다.

인가 토큰(116)의 확인에 응답하여, 방법(700)은 동작(712)으로부터 동작(714)으로 진행하는데, 여기서 배포 조건(114)은 수신되어 통신을 보낸 개체에 통신된다. 몇몇 구성에서, 배포 조건(114)은 그 통신을 보낸 개체에 의해 합의될 것이 필요할 수 있다. 다른 구성에서, 애플리케이션 라이센스 사양(108)의 조건을 포함할 수 있는 배포 조건은 사전승인될(pre-approved) 수 있다. 동작(714)으로부터, 방법(700)은 애플리케이션(104)이 배포 조건(114) 하에서 사용을 위해 이용가능하게 되는 동작(716)으로 진행된다. 그리고 방법(700)은 종료한다.

전술된 바와 같이, 애플리케이션(104A)은 하나 이상의 애플리케이션(104B 내지 104B)와 조합되거나 번들화되고 애플리케이션 수신자(112)에게 배포될 수 있다. 도 8은 예시적 실시예에 따라, 애플리케이션을 번들화하는 방법(800)의 양상을 예시한다. 방법(800)은 시작하여 동작(802)으로 진행하는데, 여기서 번들화될 애플리케이션이 식별된다. 본 문서에서 사용된 바와 같이, "번들"은 다양한 방식으로 하나 이상의 애플리케이션의 임의의 조합을 포함할 수 있다. 예를 들어, 인가 토큰(116)을 위한 애플리케이션 라이센스 사양(108) 및 배포 조건(114) 하에서 애플리케이션 수신자(112)에 의한 사용을 위해 여러 애플리케이션이 함께 번들화되고 이용가능하게 될 수 있다. 다른 예에서, 앞서 도 3a 및/또는 도 3b에 예로서 기술된 방식으로 여러 애플리케이션이 조합될 수 있다.

동작(802)으로부터, 방법(800)은 동작(804)로 진행하는데, 여기서 배포 조건이 수신된다. 전술된 바와 같이, 배포 조건은 애플리케이션 발신자(110)를 포함하나 이에 한정되지 않는 다양한 소스로부터 비롯될 수 있다. 동작(806)으로부터, 방법(800)은 동작(806)으로 진행하는데, 여기서 여러 애플리케이션을 위한 라이센스 사양이 취득된다. 본 문서에 기술된 개념 및 기술은 그렇게 한정된 것은 아니나, 다양한 라이센스 사양에 의해 개진된 요구를 충족시키면서 애플리케이션 중 하나 이상이 배포 조건(114)에 따라 배포될 수 있게끔 하기 위해서 애플리케이션 중 하나 이상의 라이센스 사양을 취득하는 것이 필요할 수 있다.

동작(808)에서, 배포 조건은 애플리케이션의 라이센싱 조건에 의해 허용가능한 것으로 확인된다. 동작(808)으로부터, 방법(800)은 동작(810)으로 진행하는데, 여기서 애플리케이션은 애플리케이션 수신자(112)로의 배포를 위한 어떤 방식으로 번들화된다. 동작(810)으로부터 동작(800)은 종료한다.

도 9는 전술된 소프트웨어 컴포넌트를 실행하는 것이 가능한 디바이스를 위한 예시적 컴퓨터 아키텍처(900)이다. 그러므로, 도 9에 예시된 컴퓨터 아키텍처(900)는 서버 컴퓨터(server computer), 모바일 전화(mobile phone), PDA, 스마트 전화(smart telelphone), 데스크톱 컴퓨터(desktop computer), 넷북 컴퓨터(netbook computer), 태블릿 컴퓨터(tablet computer) 및/또는 랩톱 컴퓨터(laptop computer)를 위한 아키텍처를 예시한다. 컴퓨터 아키텍처(900)는 본 문서에 제시된 소프트웨어 컴포넌트의 임의의 양상을 실행하기 위해 활용될 수 있다. 예를 들어, 컴퓨터 아키텍처(900)는 애플리케이션 스토어(106)를 구현하기 위해 사용될 수 있다.

도 9에 예시된 컴퓨터 아키텍처(900)은 중앙 처리 유닛(central processing unit)("CPU")(902), 시스템 메모리(904)(랜덤 액세스 메모리(random access memory)(906)("RAM") 및 판독 전용 메모리(read-only memory)("ROM")(908)를 포함함), 그리고 메모리(904)를 CPU(902)에 커플링하는 시스템 버스(910)를 포함한다. 이를테면 기동(startup) 중에 컴퓨터 아키텍처(900) 내의 구성요소 간에 정보를 전송하는 데에 도움을 주는 기본 루틴을 포함하는 기본 입출력 시스템(basic input/output system)이 ROM(908) 내에 저장된다. 컴퓨터 아키텍처(900)는 도 1의 인가 토큰(116), 애플리케이션 라이센스 사양(108), 또는 애플리케이션(104)을 저장하기 위한 대용량 저장 디바이스(mass storage device)(912)를 더 포함한다.

대용량 저장 디바이스(912)는 버스(910)에 연결된 대용량 저장 제어기(도시되지 않음)를 통해 CPU(902)에 연결된다. 대용량 저장 디바이스(912) 및 그것의 연관된 컴퓨터 판독가능 매체는 컴퓨터 아키텍처(900)를 위한 비휘발성 스토리지(non-volatile storage)를 제공한다. 본 문서에 포함된 컴퓨터 판독가능 매체의 설명이 하드 디스크 또는 CD-ROM 드라이브와 같은 대용량 저장 디바이스를 나타내나, 컴퓨터 판독가능 매체는 컴퓨터 아키텍처(900)에 의해 액세스될 수 있는 임의의 이용가능한 컴퓨터 저장 매체 또는 통신 매체일 수 있다는 점이 당업자에 의해 인식되어야 한다.

통신 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 또는 반송파(carrier wave) 또는 다른 전송 메커니즘(transport mechanism)과 같은 변조된 데이터 신호 내의 다른 데이터를 포함하고 임의의 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 신호 내에 정보를 인코딩하기 위한 방식으로 그것의 특성 중 하나 이상이 변경되거나 설정된 신호를 의미한다. 한정이 아니라 예로서, 통신 매체는 유선 네트워크(wired network) 또는 직접 배선 연결(direct-wired connection)과 같은 유선 매체 및 음향(acoustic), RF, 적외선(infrared) 및 다른 무선 매체와 같은 무선 매체를 포함한다. 위의 것 중 임의의 것의 조합이 컴퓨터 판독가능 매체의 범주 내에 포함될 수도 있다.

한정이 아니라 예로서, 컴퓨터 저장 매체들은 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보의 저장을 위해 임의의 방법 또는 기술로 구현된 휘발성(volatile) 및 비휘발성(non-volatile), 탈착가능(removable) 및 비탈착가능(non-removable) 매체들을 포함할 수 있다. 예를 들어, 컴퓨터 매체는 RAM, ROM, EPROM, EEPROM, 플래시 메모리(flash memory) 또는 다른 솔리드 스테이트 메모리(solid state memory) 기술, CD-ROM, 디지털 다기능 디스크(digital versatile disk)("DVD"), HD-DVD, BLU-RAY, 또는 다른 광학 스토리지(optical storage), 자기 카세트, 자기 테이프, 자기 디스크 스토리지(magnetic disk storage) 또는 다른 자기 스토리지 디바이스, 또는 원하는 정보를 저장하기 위해 사용될 수 있고 컴퓨터 아키텍처(900)에 의해 액세스될 수 있는 임의의 다른 매체를 포함하나 이에 한정되지는 않는다. 청구항에서, "컴퓨터 저장 매체"라는 구(phrase)와 이의 변형은 파동 또는 신호 자체 및/또는 통신 매체를 포함하지 않는다.

다양한 실시예에 따르면, 컴퓨터 아키텍처(900)는 네트워크(118)와 같은 네트워크를 통해 원격 컴퓨터로의 논리적 연결을 사용하여 네트워킹된 환경(networked environment)에서 동작할 수 있다. 컴퓨터 아키텍처(900)는 버스(910)에 연결된 네트워크 인터페이스 유닛(network interface unit)(916)을 통해 네트워크(118)에 연결될 수 있다. 네트워크 인터페이스 유닛(916)은 다른 유형의 네트워크 및 원격 컴퓨터 시스템에 연결되기 위해 활용될 수도 있다는 점이 인식되어야 한다. 컴퓨터 아키텍처(900)는 키보드(keyboard), 마우스(mouse) 또는 전자 스타일러스(electronic stylus)를 포함하는 다수의 다른 디바이스로부터 입력을 수신하여 처리하기 위한 입출력 제어기(input/output controller)(918)를 포함할 수도 있다. 유사하게, 입출력 제어기(918)는 디스플레이 스크린(display screen), 프린터(printer) 또는 다른 유형의 출력 디바이스에 출력을 제공할 수 있다.

본 문서에 기술된 소프트웨어 컴포넌트는 CPU(902) 내에 로드되어(loaded) 실행되는 경우 CPU(902) 및 전체 컴퓨터 아키텍처(900)를 범용 컴퓨팅 시스템으로부터 본 문서에서 제시된 기능성을 가능하게 하도록 맞춤화된 특수 목적 컴퓨팅 시스템으로 변환할 수 있다는 점이 인식되어야 한다. CPU(902)는 개별적으로 또는 집합적으로 임의의 개수의 상태를 취할 수 있는 임의의 개수의 트랜지스터 또는 다른 개별 회로 소자(discrete circuit element)로부터 구성될 수 있다. 더욱 구체적으로, 본 문서에 개시된 소프트웨어 모듈 내에 포함된 실행가능 명령어에 응답하여 CPU(902)는 유한 상태 머신(finite-state machine)으로서 동작할 수 있다. 이 컴퓨터 실행가능(computer-executable) 명령어는 어떻게 CPU(902)가 상태들 간에 전이하는지(transition)를 지정하고 이로써 CPU(902)를 구성하는 트랜지스터 또는 다른 개별 하드웨어 소자를 변환하는 것에 의해 CPU(902)를 변환할 수 있다.

본 문서에 제시된 소프트웨어 모듈을 인코딩하는 것은 본 문서에 제시된 컴퓨터 판독가능 매체의 물리적 구조를 변환할 수도 있다. 이 설명의 상이한 구현들에서, 물리적 구조의 구체적 변환은 다양한 인자에 달려 있을 수 있다. 그러한 인자의 예는 컴퓨터 판독가능 매체를 구현하기 위해 사용된 기술, 컴퓨터 판독가능 매체가 일차적(primary) 또는 이차적(secondary) 스토리지로 특징지어지는지 여부, 그리고 유사한 것을 포함할 수 있으나 이에 한정되지 않는다. 예를 들어, 만약 컴퓨터 판독가능 매체가 반도체 기반 메모리로 구현되는 경우, 본 문서에 개시된 소프트웨어는 반도체 메모리의 물리적 상태를 변환시킴으로써 컴퓨터 판독가능 매체 상에 인코딩될 수 있다. 예를 들어, 소프트웨어는 반도체 메모리를 구성하는 트랜지스터, 커패시터 또는 다른 개별 회로 소자의 상태를 변환할 수 있다. 소프트웨어는 그러한 컴포넌트의 물리적 상태를 데이터를 그 위에 저장하기 위해서 변환할 수 있다.

다른 예로서, 본 문서에 개시된 컴퓨터 판독가능 매체는 자기 또는 광학 기술을 사용하여 구현될 수 있다. 그러한 구현에서, 본 문서에 제시된 소프트웨어는 자기 또는 광학 매체의 물리적 상태를, 소프트웨어가 그 안에 인코딩되는 경우에 변환할 수 있다. 이 변환은 주어진 자기 매체 내의 특정한 위치의 자기적 특성을 바꾸는 것을 포함할 수 있다. 이 변환은 또한 주어진 광학 매체 내의 특정한 위치의 물리적 특징 또는 특성을 바꾸어 그 위치의 광학 특성을 변경하는 것을 포함할 수 있다. 상술한 예들은 단지 이 설명을 용이하게 하기 위해 제공되며, 본 설명의 범주 및 사상으로부터 벗어나지 않고 물리적 매체의 다른 변환이 가능하다.

이상에 비추어 볼 때, 본 문서에 제시된 소프트웨어 컴포넌트를 저장하고 실행하기 위해서 컴퓨터 아키텍처(900) 내에서 다수의 유형의 물리적 변환이 일어날 수 있다는 점이 인식되어야 한다. 컴퓨터 아키텍처(900)는 다른 유형의 컴퓨팅 디바이스(핸드헬드 컴퓨터, 임베드된 컴퓨터 시스템, 개인용 디지털 보조기기, 그리고 당업자에게 알려진 다른 유형의 컴퓨팅 디바이스를 포함함)를 포함할 수 있다는 점이 또한 인식되어야 한다. 컴퓨터 아키텍처(900)는 도 9에 도시된 컴포넌트 전부를 포함하지 않을 수 있거나, 도 9에 명시적으로 도시되지 않은 다른 컴포넌트를 포함할 수 있거나, 도 9에 도시된 것과는 완전히 상이한 아키텍처를 활용할 수 있다는 점이 또한 고려된다.

상술한 바에 기반하여, 애플리케이션을 배포하기 위한 개념 및 기술이 본 문서에 개시되었다는 점이 인식되어야 한다. 본 문서에 제시된 대상은 컴퓨터 구조적 특징, 방법론적이고 변환적인 행위, 특정 컴퓨팅 기계(machinery) 및 컴퓨터 판독가능 매체에 특정한 언어로 기술되었으나, 부기된 청구항에 정의된 발명은 반드시 본 문서에 기술된 특정 특징, 행위 또는 매체에 한정되는 것은 아니라는 점이 이해될 것이다. 오히려, 특정 특징, 행위 및 매체는 청구항을 구현하는 예시적 형태로서 개시된다.

전술된 대상은 단지 예시로서 제공되며 한정적인 것으로 해석되어서는 안 된다. 보여지고 기술된 예시적 실시예 및 적용을 따르지 않고, 또 이하의 청구항에 개진된 본 발명의 진정한 사상 및 범주로부터 벗어나지 않고, 본 문서에 개시된 대상에 대해 다양한 수정 및 변경이 행해질 수 있다.

Claims (18)

1. 애플리케이션을 배포하는 방법으로서,
   컴퓨터에 의해, 애플리케이션 수신자(application receiver)에 의해 사용될 애플리케이션의 선택을 애플리케이션 발신자(application sender)로부터 수신하는 단계 - 상기 애플리케이션은 자신과 연관된 애플리케이션 라이센스 사양(application license specification)을 가짐 - 와,
   상기 컴퓨터에 의해, 상기 애플리케이션이 배포될 배포 조건을 상기 애플리케이션 발신자로부터 수신하는 단계와,
   상기 애플리케이션 발신자로부터 수신한 상기 배포 조건을 상기 애플리케이션 라이센스 사양에 대해 분석해서, 상기 애플리케이션 라이센스 사양이 상기 배포 조건에 따라서 상기 애플리케이션 수신자로의 상기 애플리케이션의 배포를 허용하는지 확인하는 단계와,
   상기 애플리케이션 라이센스 사양이 상기 배포 조건에 따라서 상기 애플리케이션 수신자로의 상기 애플리케이션의 상기 배포를 허용함을 확인하면, 상기 애플리케이션 발신자로부터의 상기 애플리케이션 라이센스 사양 및 상기 배포 조건에 기초해서 상기 애플리케이션의 상기 배포를 제어하기 위해 인가 토큰(authroization token)을 생성하고, 상기 인가 토큰을 상기 애플리케이션 발신자에게 발신하는 단계
   를 포함하는 방법.
2. 제1항에 있어서,
   상기 인가 토큰은 상기 애플리케이션 라이센스 사양, 상기 배포 조건, 또는 상기 애플리케이션을 제공하는 애플리케이션 스토어(application store)에 의해 상기 애플리케이션에 대해 가해진 제한을 캡슐화하는(encapsulate),
   방법.
3. 제1항에 있어서,
   상기 애플리케이션 라이센스 사양은 상기 애플리케이션의 개발자에 의해 제공되거나 상기 애플리케이션을 제공하는 애플리케이션 스토어에 캡슐화된 하드코드된 디폴트(hardcoded default)인,
   방법.
   
4. 제1항에 있어서,
   상기 인가 토큰에 기초해서 수신자 라이센스를 생성하는 단계
   를 더 포함하는 방법.
   
5. 제1항에 있어서,
   상기 애플리케이션을 사용하기 위한 요청을 포함하는 통신을 상기 애플리케이션 수신자로부터 수신하는 단계
   를 더 포함하는 방법.
   
6. 제5항에 있어서,
   상기 애플리케이션 수신자로부터의 상기 통신은 상기 인가 토큰을 포함하는
   방법.
   
7. 제6항에 있어서,
   상기 인가 토큰 및 상기 애플리케이션 수신자와 연관된 정보를 확인함으로써, 상기 애플리케이션을 사용하기 위한 요청이 상기 배포 조건하에서 허용되는 것인지 확인하는 단계
   를 더 포함하는 방법.
   
8. 제7항에 있어서,
   상기 인가 토큰 및 상기 애플리케이션 수신자와 연관된 상기 정보를 확인하는 것에 응답해서, 상기 애플리케이션 수신자에게 상기 애플리케이션을 송신하는 단계
   를 더 포함하는 방법.
   
9. 제6항에 있어서,
   상기 애플리케이션 수신자로부터의 상기 통신은 상기 애플리케이션과 연관된 제2 인가 토큰을 사용하는 요청을 더 포함하고,
   상기 인가 토큰 및 상기 제2 인가 토큰은 상기 애플리케이션 수신자가 사용할 수 있는 상기 애플리케이션의 자리(seat)의 수와 관련되는
   방법.
   
10. 제1항에 있어서,
    상기 애플리케이션 수신자에 의한 상기 애플리케이션의 사용을 철회하는 단계를 더 포함하는
    방법.
    
11. 제1항에 있어서,
    상기 인가 토큰은 암호, 상기 애플리케이션을 사용할 기간(timeframe), 상기 애플리케이션이 상기 애플리케이션 수신자로 배포될 준비가 되어 있다는 통신, 또는 개인 식별 번호를 캡슐화하는,
    방법.
    
12. 컴퓨터로서,
    하드웨어 프로세서와,
    상기 하드웨어 프로세서와 통신하는 컴퓨터 판독가능 저장 매체
    를 포함하되,
    상기 컴퓨터 판독가능 저장 매체에는 컴퓨터 실행가능 명령어가 저장되어 있고,
    상기 컴퓨터 실행가능 명령어는 상기 하드웨어 프로세서에 의해 실행되는 경우 상기 하드웨어 프로세서로 하여금,
    애플리케이션 수신자에 의해 사용될 애플리케이션의 선택을 애플리케이션 발신자로부터 수신하게 하고 - 상기 애플리케이션은 자신과 연관된 애플리케이션 라이센스 사양을 가짐 - ,
    상기 애플리케이션이 배포될 배포 조건을 상기 애플리케이션 발신자로부터 수신하게 하며 - 상기 배포 조건은, 상기 애플리케이션을 사용할 때 상기 애플리케이션 발신자가 상기 애플리케이션 수신자가 갖는 것을 허용하는 제어 레벨을 포함함 - ,
    상기 애플리케이션 발신자로부터 수신한 상기 배포 조건을 상기 애플리케이션 라이센스 사양에 대해 분석해서, 상기 애플리케이션 라이센스 사양이 상기 배포 조건에 따라서 상기 애플리케이션 수신자로의 상기 애플리케이션의 배포를 허용하는지 확인하게 하고,
    상기 애플리케이션 라이센스 사양이 상기 배포 조건에 따라서 상기 애플리케이션 수신자로의 상기 애플리케이션의 배포를 허용함을 확인하면, 상기 배포 조건 및 상기 애플리케이션 라이센스 사양을 캡슐화하는 인가 토큰을 생성하게 하고,
    상기 인가 토큰을 상기 애플리케이션 발신자에게 발신하게 하는
    컴퓨터.
    
13. 제12항에 있어서,
    상기 컴퓨터 실행가능 명령어는 상기 하드웨어 프로세서에 의해 실행되는 경우 상기 하드웨어 프로세서로 하여금 또한,
    상기 인가 토큰을 상기 애플리케이션과 연관된 라이센스와 연관시키게 하는
    컴퓨터.
    
14. 제12항에 있어서,
    상기 컴퓨터 실행가능 명령어는 상기 하드웨어 프로세서에 의해 실행되는 경우 상기 하드웨어 프로세서로 하여금 또한,
    상기 인가 토큰을 사용하는 통신의 수신시나 또는 상기 애플리케이션 발신자에 의한 지불시에 상기 애플리케이션의 개발자에게 라이센스 지불을 송신하게 하는
    컴퓨터.
    
15. 제12항에 있어서,
    상기 컴퓨터 실행가능 명령어는 상기 하드웨어 프로세서에 의해 실행되는 경우 상기 하드웨어 프로세서로 하여금 또한,
    상기 애플리케이션을 사용하기 위한 요청을 포함하는 통신을 상기 애플리케이션 수신자로부터 수신하게 하는
    컴퓨터.
    
16. 제15항에 있어서,
    상기 컴퓨터 실행가능 명령어는 상기 하드웨어 프로세서에 의해 실행되는 경우 상기 하드웨어 프로세서로 하여금 또한,
    상기 애플리케이션과 연관된 제1 수신자 라이센스를 제2 애플리케이션과 연관된 제2 수신자 라이센스와 통합하게 하는
    컴퓨터.
    
17. 제16항에 있어서,
    상기 애플리케이션 및 상기 제2 애플리케이션은 번들화되어서(bundled), 제2 애플리케이션 수신자는 단일의 트랜잭션(transaction)에서 상기 애플리케이션 및 상기 제2 애플리케이션 모두를 사용할 권리를 수신하는
    컴퓨터.
    
18. 컴퓨터 실행가능 명령어가 저장된 컴퓨터 판독 가능 저장 매체로서,
    상기 컴퓨터 실행가능 명령어는 컴퓨터에 의해 실행되는 경우 상기 컴퓨터로 하여금
    애플리케이션 수신자에 의해 사용될 애플리케이션의 선택을 애플리케이션 발신자로부터 수신하게 하고 - 상기 애플리케이션은 자신과 연관된 애플리케이션 라이센스 사양을 가짐 - ,
    상기 애플리케이션이 배포될 배포 조건을 상기 애플리케이션 발신자로부터 수신하게 하며,
    상기 애플리케이션 발신자로부터 수신한 상기 배포 조건을 상기 애플리케이션 라이센스 사양에 대해 분석해서, 상기 애플리케이션 라이센스 사양이 상기 배포 조건에 따라서 상기 애플리케이션 수신자로의 상기 애플리케이션의 배포를 허용하는지 확인하게 하고,
    상기 애플리케이션 라이센스 사양이 상기 배포 조건에 따라서 상기 애플리케이션 수신자로의 상기 애플리케이션의 상기 배포를 허용함을 확인하면 인가 토큰을 생성하게 하고,
    상기 인가 토큰을 상기 배포 조건 및 상기 애플리케이션 라이센스 사양과 연관시키게 하며,
    상기 인가 토큰을 상기 애플리케이션 발신자에게 발신하게 하고,
    상기 애플리케이션을 사용하기 위한 요청을 애플리케이션 수신자로부터 수신하게 하며,
    상기 인가 토큰을 확인하게 하고,
    상기 인가 토큰이 확인되는 경우 상기 애플리케이션을 상기 애플리케이션 수신자가 이용할 수 있게 하는,
    컴퓨터 판독가능 저장 매체.

Images