KR20140033209A

KR20140033209A - 임베디드 애플리케이션들의 과금

Info

Publication number: KR20140033209A
Application number: KR1020147002143A
Authority: KR
Inventors: 파행 캐세이; 샤론 벨로리
Original assignee: 이베이 인크.
Priority date: 2010-04-09
Filing date: 2011-04-07
Publication date: 2014-03-17
Also published as: WO2011127296A1; AU2011237500B2; US20110251921A1; AU2011237500A1; KR20130020887A; CA2796075A1

Abstract

여기에 설명된 다양한 실시예들은 제 3 자 개발자와 제 3 자 애플리케이션에 가입한 사용자 사이의 과금 트랜잭션을 자동으로 가능하게 하는 시스템들, 소프트웨어, 및 방법들 중 하나 이상을 포함한다. 몇몇 이러한 실시예들은 사용자에게 등록된 서빙 플랫폼 계좌 아래에 서브-계좌를 생성한다. 몇몇 실시예들은 제 3 자 애플리케이션과 연관된 과금 플랜을 저장하는 단계를 포함하고, 이 과금 플랜은 제 3 자 애플리케이션에 가입하기 위한 수수료를 정의한다.

Description

임베디드 애플리케이션들의 과금{FACILITATING BILLING OF EMBEDDED APPLICATIONS}

관련 출원

본 출원은 양자가 참조로 여기에 포함되는 2010년 4월 9일자로 출원된 미국 가특허 출원 제61/322,685호 및 2010년 9월 1일자로 출원된 미국 특허 출원 제12/874,017호의 우선권 이익을 주장한다.

본 출원은 일반적으로 전자 기반 상거래의 분야에 관한 것이다.

쌍방향 통신 매체로서 인터넷의 광범위한 수용으로, 공통 플랫폼상에서 구동하는 애플리케이션들의 배치가 인기가 증가하였다. 예를 들어, 온라인 시장은 시장내에서 대량 판매를 관리하기 위해 애플리케이션을 공통 플랫폼내에서 배치할 수도 있다. 이들 애플리케이션들 중 몇몇이 시장 자체에 의해 제공되는 반면에, 다른 것들은 제 3 자 소프트웨어 개발자들에 의해 기록되고 판매된다. 이들 애플리케이션들, 특히, 제 3 자 애플리케이션들에 가입하기 위해, 가입자들은 통상적으로 애플리케이션들에 대해 인터넷을 검색해야 한다. 애플리케이션의 사용에 대한 수입을 받아들이기 위해, 제 3 자 애플리케이션의 개발자는 일반적으로 과금 트랜잭션들을 적절하게 인증, 기록 및 처리하기 위해(예를 들어, 애플리케이션에 가입 또는 애플리케이션 구매), 과금 시스템을 제공해야 한다. 그 결과, 가입자들은 하나 보다 많은 개발자로부터 구매할 때 다수의 상이한 과금 시스템들과 잠재적으로 상호작용할 수도 있다.

또한, 이들 제 3 자 애플리케이션들에 대한 가입은 온라인 시장 외부(예를 들어, 웹 플랫폼 시장)에서 처리되고, 몇몇 판매자들은 지급 내역(payment details)을 갖는 제 3 자들(예를 들어, 제 3 자 소프트웨어 개발자들)을 신뢰하지 않을 수도 있다.

본 발명의 실시예들이 동일한 참조 부호들이 유사한 엘리먼트들을 나타내는 첨부한 도면들의 도면에서 제한이 아닌 예로서 예시된다.
도 1은 서빙 플랫폼에서 임베디드 애플리케이션들(embedded applications)의 과금을 가능하게 하기 위한 방법 및 시스템이 예시적인 실시예에 따라 구현될 수도 있는 시스템의 블록도이다.
도 2는 예시적인 실시예에 따른 애플리케이션 시장 플랫폼의 모듈들을 예시하는 블록도이다.
도 3은 예시적인 실시예에 따른, 과금 플랜(billing plan)을 나타내는 예시적인 데이터 구조를 예시하는 블록도이다.
도 4는 예시적인 실시예에 따른 과금 플랜의 수명주기(lifecycle)를 예시하는 상태도이다.
도 5는 예시적인 실시예에 따른, 애플리케이션 서빙 플랫폼에 의해 제공된 제 3 자 애플리케이션에 대해 사용자에게 청구하는 방법을 예시하는 플로우차트이다.
도 6은 예시적인 실시예에 따른, 사용자 계좌의 예시적인 구조를 예시하는 블록도이다.
도 7은 다양한 예시적인 실시예들에 따른, 가입자에게 과금하는데 수반되는 메시지들을 예시하는 메시지 도면이다.
도 8은 다양한 예시적인 실시예들에 따른, 가입자에게 과금하는데 수반되는 메시지들을 예시하는 다른 메시지 도면이다.
도 9는 다양한 예시적인 실시예들에 따른, 가입자에게 과금하는데 수반되는 메시지들을 예시하는 또 다른 메시지 도면이다.
도 10은 머신으로 하여금 여기에서 논의되는 임의의 하나 이상의 방법들을 수행하게 하는 세트 명령들이 실행될 수도 있는 컴퓨터 시스템의 예시적인 형태의 머신의 도식적 표현이다.

아래의 설명에서, 설명을 위해, 다수의 특정할 상세들이 몇몇 예시적인 실시예들의 완전한 이해를 제공하기 위해 설명된다. 그러나, 본 발명이 이러한 특정한 상세없이 실시될 수도 있다는 것이 당업자에게는 명백할 것이다. 또한, 널리 공지되어 있는 명령 인스턴스들, 프로토콜들, 구조들, 및 기법들은 상세히 나타내지 않았다.

애플리케이션 시장 플랫폼은, 제 3 자 애플리케이션들이 서빙 플랫폼(예를 들어, 전자 상거래 시장)내에서 주문 기능(custom functionality) 및 툴들을 제공할 수 있게 하는 프레임워크이다. 이들 툴들에 액세스하기 위해 사용자들이 서빙 플랫폼으로부터 벗어나기 보다는, 서빙 플랫폼은 제 3 자 개발자들이 제어되고 일관된 방식으로 서빙 플랫폼에 기여할 수 있게 한다. 이러한 노력은 서빙 플랫폼이 개발자 사회의 강도를 레버리징할 수 있게 하여 서빙 플랫폼상에서 구매 및 판매 경험을 강화시킨다.

서빙 플랫폼의 사용자들이 스케일링(scale)할 때, 사용자들은 완전하게 다른 환경 또는 서빙 플랫폼으로 이동할 필요없이 사용자들의 기존의 툴 세트에 애플리케이션들을 추가할 수도 있다. 예시를 위해, 사용자는 초기에는 서빙 플랫폼상에서 소수의 아이템들을 판매할 수도 있다. 이러한 시점에서, 사용자는 서빙 플랫폼에 의해 캐주얼 판매자(casual seller)로 보여질 수도 있다. 시간이 지나면서, 사용자는 서빙 플랫폼내에서 점점 더 인기를 얻을 수도 있어서, 사용자는 매달 다수의 트랜잭션들을 달성한다. 이러한 시점에서, 사용자는 서빙 플랫폼에 의해 파워 판매자(power seller)로 보여질 수도 있다. 이와 같이, 사용자는 재고품 관리 애플리케이션에 의해 이익을 얻을 수도 있다. 이러한 경우에서, 재고품 관리 애플리케이션을 제공하는 애플리케이션 시장 플랫폼은 서빙 플랫폼내에서 그 존재가 성장하고 있는 사용자를 지원하는 툴을 제공함으로써 사용자에게 이익을 준다.

제 3 자 개발자들에 대해, 애플리케이션 시장 플랫폼은 무엇보다도, 과금 및 지급 기능(billing and payment facilitates)을 제공함으로써 제 3 자 개발자에 대한 상당한 개발 작업의 부담을 완화시킨다. 과금 기능은 애플리케이션 시장 플랫폼으로 통합되어서, 서빙 플랫폼에 의해 제공된 기능에 부분적으로 기초하여 수수료를 발생시키는 플렉시블한 접근방식을 제공한다.

과금 플랜은 일반적으로 애플리케이션 시장 플랫폼에 의해 배치된 제 3 자 애플리케이션과 연관된 하나 이상의 수수료들을 지칭한다. 예시적인 실시예에서, 제 3 자 개발자는 제 3 자 애플리케이션에 대한 과금 플랜을 정의하고, 그 과금 플랜은 애플리케이션 시장 플랫폼에 제시(submit)한다. 몇몇 예시적인 실시예들에서, 제 3 자 개발자는 특정한 애플리케이션에 대한 하나 이상의 과금 플랜들을 제시할 수도 있다. 다른 실시예들에서, 과금 플랜은 예를 들어, 서빙 플랫폼내의 구매 사용자의 상황을 포함하는 임의의 수의 요인들에 의존하여, 다중의 수수료 플랜들로 파티셔닝(partition)될 수도 있다.

제 3 자 개발자가 과금 플랜을 애플리케이션 시장 플랫폼에 제시한 이후에, 애플리케이션 시장 플랫폼은 과금 플랜의 적어도 일부를 제 3 자 애플리케이션을 구매하는데 관심이 있는 사용자들이 볼 수 있게 한다. 예시적인 실시예에서, 사용자는 사용자가 제 3 자 애플리케이션에 가입할 시에 과금 플랜에 의해 설명된 수수료에 동의한다.

또한, 상술한 다양한 예시적인 실시예들에 관한 상세가 본 명세서에 첨부한 도면들을 참조하여 이제 논의될 것이다. 예시적인 실시예들이 시장 및 애플리케이션 시장 플랫폼에 관하여 논의되지만, 실시예들은 비시장(non-marketplace) 환경들(예를 들어, 공개 시스템 또는 소셜 네트워킹 시스템)에 적용될 수도 있다.

도 1은 공통 플랫폼에 의해 배치된 제 3 자 애플리케이션의 과금을 가능하게 하는 일 예시적인 실시예내의 클라이언트-서버 시스템(100)을 도시하는 네트워크 도면이다. 도 1은 클라이언트 서버 시스템(100)의 부분들 사이의 기본 관계를 도시한다.

이 예에서, 서빙 플랫폼(SP)(102)은 네트워크(104)(예를 들어, 인터넷 또는 광역 네트워크(WAN))를 통해 서버측 기능을 하나 이상의 클라이언트 머신들(110, 112 및 130)에 제공하는 네트워크 기반 시장을 형성한다. 도 1은 예를 들어, 웹 클라이언트(106)(예를 들어, 워싱턴주 레드몬드의 MICROSOFT사에 의해 개발된 INTERNET EXPLORER 브라우저와 같은 브라우저), 및 각각의 클라이언트 머신들(110 및 112)상에서 실행하는 프로그램적 클라이언트(programmatic client)(108)를 예시한다. 클라이언트 머신들(110 및 112)은 데이터를 뷰잉(viewing)하기 위한 연관된 디스플레이 디바이스들(134 및 136)(예를 들어, 모니터)을 갖는다.

애플리케이션 프로그램 인터페이스(API) 서버(114) 및 웹 서버(116)가 애플리케이션 시장 플랫폼(118)에 커플링되고, 프로그램적 및 웹 인터페이스들을 각각 제공한다. 그 결과, 애플리케이션 시장 플랫폼(118)은 하나 이상의 데이터베이스 서버들(124)을 통해 하나 이상의 데이터베이스(예를 들어, 126 및 128)에 커플링된다.

애플리케이션 시장 플랫폼(118)은 SP(102)상에서 제 3 자 애플리케이션(132)을 배치하기 위해 제 3 자 플랫폼(140)과 통합된다. 예시적인 실시예에서, 제 3 자 플랫폼(140), 제 3 자 애플리케이션(132) 및 애플리케이션 시장 플랫폼(118)은 표준의 소정의 인터페이스들을 구현할 수도 있거나 호출(call)할 수도 있다. 제 3 자측상에서, 제 3 자 애플리케이션(132)은 애플리케이션 시장 플랫폼(118)과의 인터페이스를 제공하기 위해 참여자 인터페이스(participant interface) 구현을 구현할 수도 있다. 애플리케이션 시장측상에서, 애플리케이션 시장 플랫폼(118)은 플랫폼 기능을 제 3 자 애플리케이션(132)에 제공하기 위해 애플리케이션 통합 서비스 인터페이스를 구현할 수도 있다.

도 2는 예시적인 실시예에 따른, 제 3 자 애플리케이션들에 대한 가입의 과금을 가능하게 하는데 사용된 애플리케이션 시장 플랫폼의 모듈들을 예시하는 블록도이다. 애플리케이션 시장 플랫폼(118)은 ID 맵퍼(mapper) 모듈(202), 과금 프로파일 모듈(204), 계좌 프로파일 모듈(206), 과금 모듈(208), 과금 플랜 검사 모듈(210), 애플리케이션 모듈(212), 사용 모듈(214), 및 애플리케이션 통합 인터페이스 모듈(216)을 포함할 수도 있다. 또한, 예시적인 실시예의 기능들을 위해 필요하지 않은 모듈들 및 컴포넌트들은 도시되지 않거나 설명되지 않는다.

ID 맵퍼 모듈(202)은 애플리케이션 시장 플랫폼(118) 및 제 3 자 개발자들 양자에 대해, 플렉시블 접근방식이 애플리케이션 시장 플랫폼(118)에 의해 저장된 과금 플랜들을 참조하게 한다. 아래에 어 상세히 설명하는 바와 같이, 애플리케이션 시장 플랫폼(118)은 과금 플랜이 애플리케이션 시장 플랫폼(118)에 제시될 때 생성되는 할당된 식별자에 기초하여 과금 플랜을 참조할 수도 있다. ID 맵퍼 모듈(202)은 제 3 자 개발자가 제시된 과금 플랜을 참조하는 추가의 식별자를 특정하게 한다. 이러한 방식으로, 애플리케이션 시장 플랫폼(118)은 할당된 식별자로 과금 플랜을 참조할 수도 있고, 제 3 자 개발자는 특정된 식별자로 동일한 과금 플랜을 참조할 수도 있다. 그 결과, 제 3 자 개발자들은 그 제 3 개발자들이 애플리케이션 시장 플랫폼(118) 외부의 시스템들에서 사용된 기존의 식별자들을 유지하게 함으로써 애플리케이션 시장 플랫폼과 기존의 과금 시스템들을 더욱 쉽게 통합할 수도 있다.

과금 프로파일 모듈(204)은 제 3 자 개발자들에 의해 제시된 과금 플랜들을 수신하고 저장한다. 과금 프로파일 모듈(204)은 과금 프로파일 모듈(204)에 의해 할당되거나 제 3 자 개발자에 의해 특정된 식별자에 기초하여 제시된 과금 플랜을 참조할 수도 있다. 더 후술되는 바와 같이(예를 들어, 도 3 참조), 과금 플랜은 제 3 자 애플리케이션의 비용에 관한 다양한 양태들을 설명하는 정보를 포함할 수도 있다. 예를 들어, 과금 플랜은 특정한 요금이 주기적 요금(periodic charge) 또는 1회 요금인지의 표시를 포함한다. 추가로, 과금 플랜은 다양한 통화들로 표현될 수 있는 바와 같은, 요금에 대한 비용(예를 들어, 거래 수수료 또는 서비스료)을 더 포함할 수도 있다. 또한, 과금 플랜은 예를 들어, 데이터베이스에 대한 각 문의에 대한 수수료와 같은 제 3 자 애플리케이션의 가입자의 사용에 대한 요금들을 설명할 수도 있다.

계좌 프로파일 모듈(206)은 제 3 자 애플리케이션들에 대한 가입에 관한 사용자 계좌들을 관리한다. 사용자가 제 3 자 애플리케이션에 가입할 때, 계좌 프로파일 모듈(206)은 가입된 제 3 자 애플리케이션에 특정한 계좌를 생성할 것이다. 생성된 계좌는 사용자 및 제 3 자 애플리케이션에 특정한 과금 정보를 홀딩한다. 예시적인 실시예들에서, (예를 들어, 클라이언트 머신들(110 또는 112)에서의) 각 사용자는 예를 들어, 사용자의 개인 정보를 포함하는 SP(102)의 계좌에 등록된다. 사용자가 애플리케이션 시장 플랫폼(118)에 의해 제공된 제 3 자 애플리케이션에 가입할 때, 계좌 프로파일 모듈(206)은 SP(102)의 계좌 아래에 서브-계좌를 생성할 수도 있다. 생성된 서브-계좌는 가입된 제 3 자 애플리케이션에 특정될 수도 있다. 서브-계좌는 예시적인 실시예에서, 아래에 논의되는 바와 같이, SP(102)의 계좌와 연관된 사용자의 개인 정보를 이어받을 수도 있다.

과금 모듈(208)은 과금 플랜에 의해 특정될 때 사용자와 제 3 자 개발자 사이의 주기적 또는 트리거링된 과금 트랜잭션들을 가능하게 한다. 예를 들어, 과금 플랜은 주기적 요금들에 대한 시간 성분(예를 들어, 1년 가입)을 포함하는 데이터 필드를 가질 수도 있다. 사용자가 이러한 데이터 필드를 포함하는 제 3 자 애플리케이션의 과금 플랜에 가입할 때, 과금 모듈(208)은 과금 플랜에 의해 특정된 각 주기에서 사용자와 제 3 자 개발자 사이에서, 계좌 프로파일 모듈(206)에 의해 저장되도록 과금 트랜잭션을 자동으로 트리거링할 수도 있다.

과금 플랜 검사 모듈(210)은 제시된 과금 플랜이 애플리케이션 시장 플랫폼(118)에 의해 정의된 기준을 충족시키는지를 확인한다. 아래에 더 상세히 설명되는 바와 같이, 제 3 자 개발자가 과금 플랜을 제시하면, 과금 플랜 검사 모듈(210)은 애플리케이션 시장 플랫폼(118)에 의해 설명된 바와 같이, 결정가능한 표준들을 충족시키면 과금 플랜을 인가할 수도 있다(예를 들어, 과금 플랜의 사용을 인가함). 예를 들어, 몇몇 예시적인 실시예들은 과금 플랜이 SP(102)의 사용자에게 디스플레이가능한 문자 필드들을 제공하게 할 수도 있다. 이러한 문자 필드의 인가를 예시하기 위해, 애플리케이션 시장 플랫폼(118)은 과금 플랜이 비어(obscene language)를 포함하지 않을 수도 있다는 정책을 제공할 수도 있다. 이러한 경우에서, 과금 플랜 검사 모듈(210)은 예를 들어, SP(102)의 관리자에 액세스가능한 구성에 의해 특정될 때, 애플리케이션 시장 플랫폼(118)에 의해 비어인 것으로 고려된 언어를 제시된 과금 플랜이 포함하지 않는다는 것을 과금 플랜 검사 모듈(210)이 결정하는 경우에 과금 플랜을 인가할 수도 있다.

애플리케이션 모듈(212)은 애플리케이션 시장 플랫폼(118)에 의해 배치된 제 3 자 애플리케이션을 수신하고 저장한다. 애플리케이션 모듈(212)은 제 3 자 애플리케이션들을 애플리케이션 데이터베이스(126)에 저장할 수도 있다.

사용 모듈(214)은 사용 기반 과금에 관한 이벤트들을 수신한다. 예를 들어, 제 3 자 애플리케이션은 사용 이벤트(예를 들어, 로그인, 데이터베이스 액세스, 또는 임의의 다른 애플리케이션 사용)를 사용 모듈(214)에 보고할 수도 있다. 사용 기반 과금 이벤트들의 수신에 응답하여, 사용 모듈(214)은 계좌 프로파일 모듈(206)에 의해 생성된 제 3 자 애플리케이션 특정 계좌에 과금 기록들을 기록한다.

애플리케이션 통합 인터페이스 모듈(216)은 프로그램적 인터페이스이다. 예를 들어, 제 3 자 플랫폼은 SP(102)에 의해 제공된 기능을 제공하기 위해 애플리케이션 통합 인터페이스 모듈(216)에 의해 제공된 기능을 인보크한다. 예를 들어, SP(102)는 SP(102)의 사용자의 상황을 리턴(return)하는 기능을 제공할 수도 있다. 상황은 사용자가 대량 판매자 또는 소량 판매자인지 여부를 나타낸다.

도 3은 과금 플랜(300)을 나타내는 예시적인 데이터 구조를 도시하는 도면이다. 제 3 자 플랫폼은 과금 플랜(300) 또는 그것의 몇몇 일부를 애플리케이션 시장 플랫폼(118)에 제시할 수도 있어서 도 1에 도시된 제 3 자 애플리케이션(132)과 연관된 과금 플랜을 정의한다.

개발자 애플리케이션 식별자(ID)(302)는 제 3 자 애플리케이션의 개발자를 식별한다. 몇몇 실시예들에서, 개발자 애플리케이션 ID(302)는 제 3 자 애플리케이션(132)이 애플리케이션 시장 플랫폼(118)에 초기에 제시될 때 제 3 자 애플리케이션(132)에 할당된 식별자(ID) 값에 매칭한다.

개발자 애플리케이션 명칭(304)은 개발자에 의해 제공된 제 3 자 애플리케이션의 명칭의 문자 표현이다. 개발자 애플리케이션 명칭(304)은 가입자에 대한 과금 계산표(billing statement)에 도시될 수도 있다.

개발자 플랜 식별자(ID)(306)는 애플리케이션 시장 플랫폼(118)이 제 3 자 플랫폼에 대한 메시지들(예를 들어, 신규 가입의 제 3 자 플랫폼에 통지하기 위한 메시지들)에 포함할 수도 있는 개발자 할당 식별자이다. 플랜 명칭(308) 및 플랜 설명(310)은 과금 플랜에 관하여 사용자에 대해 인간 판독가능한(human-readable) 정보를 제공하는 디스플레이 엘리먼트들이다. 예를 들어, 플랜 명칭(308) 필드는 과금 청구서에 포함될 수도 있고 과금 플랜의 명칭을 나타낸다.

플랜 설명(310)은 과금 플랜을 설명하는 인간 판독가능한 문자 필드이다. 예시적인 실시예에서, 애플리케이션 시장 플랫폼(118)은 과금 플랜을 보는 사용자에게 플랜 설명(310)을 디스플레이한다. 이러한 필드는 짧은 설명을 제공함으로써 사용자가 과금 플랜을 더 양호하게 이해하게 한다.

플랜 날짜 필드(312)는 과금 플랜이 가입에 이용가능한 시간 프레임을 나타낸다. 예를 들어, 플랜 날짜 필드(312)는 사용자가 과금 플랜에 가입할 수도 있는 시작 및 종료 날짜를 나타낼 수도 있다. 애플리케이션 시장 플랫폼(118)은 현재 날짜가 플랜 날짜 필드(312)에 의해 특정된 시간 범위내에 있을 때까지 사용자가 가입하는 것을 금지할 수도 있다.

플랜 타입 필드(314)는 과금 플랜이 과금가능하거나 과금가능하지 않은 플랜인지를 식별한다. 즉, 개발자는 과금 플랜(300)이 과금가능하지 않은 플랜이라는 것을 나타내는 값으로 플랜 타입 필드(314)를 설정함으로써 프리 플랜(free plan)을 나타내는 것을 선택할 수도 있거나, 과금 플랜(300)이 과금가능한 플랜이라는 것을 나타내는 값으로 플랜 타입 필드(314)를 설정함으로써 플랜이 적어도 하나의 요금을 포함한다는 것을 나타내는 것을 선택할 수도 있다.

반복 요금(recurring charge) 필드(316)는 제 3 자 애플리케이션(132)의 사용에 대한 반복 요금의 양을 나타낸다. 몇몇 실시예들에서, 반복 요금 필드(316)는 적용된 양의 통화를 나타낼 수도 있다. 반복 주기 필드(318)는 반복 요금 필드(316)에 의해 표현된 요금의 주기 또는 빈도를 나타낸다. 몇몇 실시예들에서, 반복 요금은 제 3 자 애플리케이션(132)의 사용자에 대한 매일, 매주, 격월,, 매월, 분기별, 연 2회, 매년 요금들, 또는 임의의 다른 주기적 요금을 나타낼 수도 있다.

1회 수수료 필드(320)는 과금 플랜이 1회 셋업(onetime setup) 수수료를 갖는다는 것을 나타낼 수도 있다. 1회 수수료 필드(320)는 또한, 과금 플랜이 가입의 수명 동안 1회 청구되는 1회 수수료를 갖는다는 것을 나타낼 수도 있다.

사용 필드(322)는 과금 플랜이 사용 기반 요금들을 포함하는지를 나타낸다. 과금 플랜이 사용 기반 요금들을 포함한다는 것을 사용 필드(322)가 나타내면, 사용 카테고리 필드(324) 및 사용 상세(usage details) 필드(326)는 사용 기반 요금들에 관한 추가 정보를 제공한다. 사용 카테고리 필드(324)는 제 3 자 애플리케이션이 어느 사용 카테고리 타입들을 사용하는지 나타낸다. 몇몇 실시예에서, 사용 카테고리 필드(324)는 다중의 서브-필드들을 포함할 수도 있다. 예를 들어, 사용 카테고리 필드(324)는 제 3 자 애플리케이션(132)이 제 3 자 애플리케이션 특정 계좌에 가입 수수료를 자동으로 청구하는 애플리케이션 시장 플랫폼(118)을 갖기 보다는 (예를 들어, 애플리케이션 통합 서비스 인터페이스를 통해) 가입 수수료를 전송하는 경우에 가입 요금을 나타내는 값을 포함할 수도 있다. 다른 예로서, 사용 카테고리 필드(324)는 제 3 자 애플리케이션(132)이 계좌 활동 사용 기록들(account activity usage records)을 애플리케이션 시장 플랫폼(118)으로 전송하는 경우에 플랜 사용 요금을 나타내는 값을 포함할 수도 있다. 다른 예로서, 사용 카테고리 필드(324)는 제 3 자 애플리케이션(132)이 넌-플랜(non-plan) 관련 계좌 활동(예를 들어, 온라인 시장에서, 우편 수수료)을 애플리케이션 시장 플랫폼(118)으로 전송하는 경우에 넌-플랜 사용 요금을 나타내는 값을 포함할 수도 있다.

사용 상세 필드(326)는 사용 요금들에 관한 하나 이상의 상세들을 제공한다. 몇몇 실시예들에서, 사용 상세 필드(326)는 사용자가 과금 플랜에 가입하기 이전에 사용자에게 디스플레이되도록 의도되는 인간 판독가능한 설명들을 포함할 수도 있다. 사용 상세 필드(326)는 마크업 태그(markup tag)들(예를 들어, , , , , , <ol>, <ul>, 또는 다른 유사한 마크업 태그들)을 더 포함할 수도 있다.

과금 플랜(300)의 필드들의 순서는 각 필드의 콘텐츠일 수 있기 때문에, 원하는 바에 따라 변화될 수 있다. 도 3은 단지 하나의 가능한 데이터 구조의 예이도록 의도되고, 당업자가 이해하는 바와 같이 다수의 다른 포맷들이 존재한다.

도 4는 사용자에 의한 사용을 위해 과금 플랜을 제시하고, 과금 플랜을 구성하며, 과금 플랜을 가능하게 하는 프로세스를 트랙킹하기 위해 사용되는 과금 플랜 수명주기(400)를 예시하는 상태도이다.

동작 402에서, 도 1의 애플리케이션 시장 플랫폼(118)은 개발자로 또한 칭하는 제 3 자 애플리케이션 개발자로부터 과금 플랜(예를 들어, 도 3의 과금 플랜(300))을 수신한다. 과금 플랜이 저장된 상태에 있는 동안, 애플리케이션 시장 플랫폼(118)은 개발자가 테스트(예를 들어, 애플리케이션을 가입 및 사용)하는 것을 허용하고, 애플리케이션 시장 플랫폼(118)에 의해 청구되지 않고 가입 흐름에서 과금 플랜에 변화를 만든다. 예시적인 실시예에서, 애플리케이션 시장 플랫폼(118)은 도 3의 개발자 애플리케이션 ID(302)가 과금 플랜에 가입한 사용자에 대응하면 과금 기록을 생성하지 않는다.

애플리케이션 시장 플랫폼(118)은 개발자가 (예를 들어, 제 3 자 애플리케이션(132)과의 사용을 위해) 과금 플랜(300)을 구성하도록 애플리케이션 시장 플랫폼(118)에 요청하는 것에 응답하여 동작 404에서 제시된 상태로 과금 플랜(300)을 이동시킨다. 애플리케이션 시장 플랫폼(118)은 과금 플랜이 제시된 상태에 있는 동안 개발자가 과금 플랜을 변경하는 것을 금지한다.

과금 플랜은 애플리케이션 시장 플랫폼(118)이 과금 플랜을 동작 406에서의 펜딩 상태(pending state)로 변화시키기 전까지 제시된 상태에서 유지된다. 이것은 예를 들어, 과금 플랜(300)의 구성의 개시시에 발생할 수도 있다. 과금 플랜이 펜딩 상태에 있는 동안, 도 2의 과금 플랜 검사 모듈(210)은 도 2에 과금 프로파일 모듈(204)에 저장된 과금 플랜을 구성한다. 몇몇 예시적인 실시예들에서, 도 2의 검사 모듈(210)은 제 3 자 애플리케이션(132)과의 사용을 위해 과금 플랜을 구성한다. 일례로서, 과금 플랜 검사 모듈(210)이 개발자에 의해 제공된 정보에서 에러를 찾으면, 애플리케이션 시장 플랫폼(118)은 개발자에게 통지하고, 과금 플랜은 개발자가 편집하도록 저장된 상태(예를 들어, 동작 402)로 다시 배치된다. 예시적인 실시예에서, 시장의 종업원은 제시된 정보를 수동으로 리뷰한다. 다른 예시적인 실시예에서, 리뷰의 적어도 일부는 (예를 들어, 애플리케이션 시장 플랫폼(118)에 의해) 자동으로 수행된다. 예를 들어, 애플리케이션 시장 플랫폼(118)은 부적합 언어(objectionable language)에 대해 또는 소정의 규칙들에 따라 과금 플랜을 분석할 수도 있다.

동작 408에서, 과금 플랜 검사 모듈(210)이 과금 플랜을 구성한 이후에 활성 상태가 과금 플랜에 적용된다. 몇몇 실시예들에서, 사용자들은 시각성 설정(예를 들어, 숨김(hdden) 또는 보임(visible))에 기초하여 그리고 플랜의 날짜 범위(예를 들어, 시작 날짜 및 종료 날짜)에 기초하여 플랜을 확인할 수 있거나 확인하지 못할 수 있다. 애플리케이션 시장 플랫폼(118)은 시각성 설정을 "숨김"으로 설정할 수도 있고, 최종 검증을 행하도록 개발자에게 제안할 수도 있다. 과금 플랜이 예상한 바와 같이 수행된다는 것을 개발자가 무리없이 충족하면, 개발자는 플랜을 "보임" 상태로 설정하도록 애플리케이션 시장 플랫폼(118)으로 요청을 전송할 수도 있다(예를 들어, 사용자 인터페이스를 통해 제어 입력을 전송). 보임 상태는 다른 사용자들이 제 3 자 애플리케이션에 가입하는 것을 허용한다.

도 5는 일 예시적인 실시예에 따른 과금 프로세스(500)를 도시하는 플로우차트이다. 동작 502에서, 도 1의 애플리케이션 시장 플랫폼(118)은 서비스로 또한 칭하는 제 3 자 애플리케이션에 가입하기 위한 사용자로부터의 가입 요청을 수신한다.

동작 504에서, 도 2의 계좌 프로파일 모듈(206)은 가입을 요청하는 사용자의 사용자-계좌 아래에 서브계좌를 생성한다.

사용자의 계좌 구조를 더 양호하게 설명하기 위해 잠시 초점을 전환하면, 도 6은 사용자 계좌의 예시적인 구조(600)를 예시하는 블록도이다. 도 6은 사용자-계좌(602)가 서브-계좌들(604, 606, 및 608)에 대한 부모 계좌(parent account)로서 작용한다는 것을 도시한다. 사용자-계좌(602)는 SP(102)(도 1 참조)내의 사용자의 계좌이다. 통상적으로, 사용자-계좌(602)는 사용자 프로파일(610)을 포함한다. 사용자 프로파일(610)은 예를 들어, 이메일 주소, 물리적 우편 주소, 사용자명(이름 및 성), 회사명, 전화 번호, 및 다른 개인 정보와 같은 사용자의 개인 정보를 포함할 수도 있다. 애플리케이션 시장 플랫폼(118)으로부터 제 3 자 애플리케이션에 가입한 사용자에 응답하여, 계좌 프로파일 모듈(206)(도 2 참조)은 제 3 자 애플리케이션의 가입 및 사용에 특정된 계좌 정보를 저장하기 위해 제 3 자 애플리케이션 계좌들(또한, 서브-계좌들이라 칭함)을 갖도록 사용자-계좌(602)를 연장할 수도 있다. 몇몇 예시적인 실시예들에서, 사용자 프로파일(610)에서의 정보는 계좌 프로파일 모듈(206)에 의해 사용자-계좌(602)로부터 서브-계좌(예를 들어, 604)로 풀링(pull)될 수도 있다. 다른 실시예들에서, 서브-계좌는 사용자-계좌(602)와 서브 계좌들(예를 들어, 604, 606 및 608) 사이의 자식-부모(child-parent) 관계에 기초하여, 레퍼런스에 의해 간접적으로 사용자 프로파일(610)을 포함한다. 각 신규 제 3 자 애플리케이션에 대해, 계좌 프로파일 모듈(206)은 제 3 자 애플리케이션에 대한 사용자의 가입의 계좌 정보를 홀딩하기 위해 개별 서브-계좌(예를 들어, 606 및 608)를 생성한다.

각 계좌(사용자-계좌 및 서브-계좌)는 다수의 식별자들을 포함할 수도 있다. 사용자-계좌(602)는 예를 들어, SP(102)내의 사용자의 사용자 식별자, 애플리케이션 시장에 의해 할당된 계좌 식별자, 또는 등록 이메일 주소의 임의의 조합에 의해 식별될 수도 있다. 그 결과, 서브-계좌들(예를 들어, 604, 606, 및 608)은 애플리케이션 시장 플랫폼(118)에 의해 할당된 자동 생성된 식별자(들)(예를 들어, 614, 616, 및 618 각각)에 의해 각각 식별될 수도 있다. 몇몇 실시예들에서, 서브-계좌에 대한 생성된 식별자는 가입에 대한 애플리케이션을 제공하는 제 3 자 개발자를 나타낼 수도 있다. 예를 들어, 식별자들(614 및 616)은 특정한 제 3 자 개발자에 대응할 수도 있는 프리픽스 X를 포함하고, 식별자(618)의 Y 프리픽스는 상이한 제 3 자 개발자에 대응할 수도 있다. 도 2의 애플리케이션 시장 플랫폼(118)은 제 3 자 개발자 프리픽스 식별자들을 자동으로 생성할 수도 있다.

다시 도 5를 참조하면, 동작 506은 제 3 자 애플리케이션으로부터 과금 이벤트를 수신하는 것을 수반한다. 예시적인 실시예에서, 제 3 자 애플리케이션은 과금 모듈(208)(도 2 참조)에 이들 트랜잭션을 보고함으로써 사용 및 또한 셋업 수수료, 1회 수수료, 및 심지어 반복 수수료에 대해 가입자들에게 청구할 수 있다(예를 들어, 가입자들로 하여금 청구되게 한다). 반복 수수료에 대해, 사용 요금을 전송하는 것은, 과금 모듈(208)이 제 3 자 개발자들을 위하여 주기적 요금을 관리하는 것에 대한 대안이다. 사용 기반 과금에 관여하기 위해, 도 2의 과금 프로파일 모듈(204)은 사용 기반 요금을 정의하는 제 3 자 개발자에 의해 제시된 과금 플랜을 수신한다.

동작 508은 도 2의 애플리케이션 시장 플랫폼(118)이 동작 504에서 생성된 서브-계좌에 과금 이벤트를 저장하는 것을 수반한다. 과금 이벤트는 제 3 자 애플리케이션에 의해 결정된 바와 같은, 가입자에게 청구될 양(예를 들어, 1회 수수료)을 명백하게 정의할 수도 있다. 다르게는, 과금 이벤트는 애플리케이션의 사용자의 사용에 기초하여 과금 이벤트를 설명할 수도 있다.

동작 510은 애플리케이션 시장 플랫폼(118)이 가입자에게 과금하는 것을 수반한다. 예시적인 실시예에서, 애플리케이션 시장 플랫폼(118)이 동작 506에서 과금 이벤트를 수신할 때 사용 기반 수수료가 과금된다. 다르게는, 애플리케이션 시장 플랫폼(118)은 반복 주기 필드(318)(도 3 참조)에 의해 정의된 주기에 따라 사용 기반 수수료를 주기적으로 과금할 수도 있다. 특정한 주기의 시작 또는 종료에서 사용 기반 수수료를 과금하는 예시적인 실시예들은 반복 주기에 기초하여 반복 비용을 또한 과금할 수도 있다.

도 7 내지 도 9는 가입자, 애플리케이션 시장 플랫폼, 제 3 자 플랫폼, 및 제 3 자 애플리케이션 사이의 메시지들(700, 800, 및 900)을 예시하는 메시지 도면들이다. 가입자는 SP(102)내에서 사용가능한 제 3 자 애플리케이션들을 구매하거나 그에 가입하기 위해 애플리케이션 시장 플랫폼을 사용하는 도 1의 SP(102)의 사용자를 칭한다.

특히, 도 7 내지 도 9는 애플리케이션 시장 플랫폼내의 가입자의 프로파일에 기초하여 가입자에게 과금하는 메시지들을 도시한다. 예를 들어, 전자 상거래 플랫폼으로서 서빙하는 서빙 플랫폼은 전자 상거래 플랫폼내의 판매량에 기초하여 "파워 판매자"로서 특정한 사용자들을 지정할 수도 있다. 여기서, 제 3 자 개발자는 "파워 판매자"에게 다른 수수료가 청구되지만 "캐주얼 판매자"에게 일 수수료를 청구하는 과금 플랜을 정의할 수도 있다.

도 7은 예시적인 실시예에 따른, SP(102)내에 저장된 사용자 정보에 기초하여 제 3 자 플랫폼(706)이 가입자(702)에게 청구할 수 있게 하는 일련의 메시지들(700)을 예시하는 메시지 도면이다. 도 7은 가입자(702)가 애플리케이션 시장 플랫폼(704)에 가입 메시지(710)를 전송함으로써 제 3 자 애플리케이션(708)에 가입한다는 것을 도시한다. 가입자(702)는 제 3 자 애플리케이션(708)에 의해 제공될 수도 있는 과금 플랜(예를 들어, 도 3의 과금 플랜(300) 참조)에 가입하는 것을 선택할 수도 있다.

가입 메시지(710)의 수신에 응답하여, 애플리케이션 시장 플랫폼(704)은 제 3 자 애플리케이션(708)에 의해 제공되는 바와 같이, 가입자(702)가 선택된 과금 플랜에 가입을 요청한다는 것을 나타내는 메시지(712)를 제 3 자 플랫폼(706)에 전송한다. 메시지(712)는 선택된 과금 플랜의 식별 및 가입자(702)의 식별을 포함할 수도 있다. 예시적인 실시예에서, 제 3 자 플랫폼(706)은 이들 식별들을 검증하고, 선택된 과금 플랜에 따라 가입자(702)가 제 3 자 애플리케이션(708)에 가입하는 것이 인가(예를 들어, 허용)된다는 것(예를 들어, 제 3 자 개발자와의 이전의 트랜잭션들에 기초하여, 가입자(702)가 완불하였다는 것)을 결정할 수도 있다. 가입자(702)의 성공적인 인가에 기초하여, 제 3 자 플랫폼(706)은 가입자(702)가 제 3 자 애플리케이션(708)에 가입하도록 인가된 애플리케이션 시장 플랫폼(704)으로 승인의 표시를 리턴할 수도 있다.

애플리케이션 시장 플랫폼(704)으로부터의 승인에 기초하여, 애플리케이션 시장 플랫폼(704)은 메시지(714)에 따라 가입자에게 속하는 SP(102)의 사용자-계좌 아래에 서브-계좌를 생성할 수도 있다.

제 3 자 개발자는 상이한 타입의 과금 플랜들을 정의할 수도 있다. 과금 플랜은 과금 시스템에 의해 레이팅(rate)(예를 들어, 설정 또는 제공)된 하나 이상의 수수료들 또는 제 3 자 개발자에 의해 레이팅된 하나 이상의 수수료들을 포함할 수도 있다. 가입 흐름에서, 가입자는 (예를 들어, 가입자에게 제공된 다중의 과금 플랜들 중에서) 과금 플랜을 선택할 수도 있다. 과금 플랜이 과금 시스템에 의해 레이팅된 수수료들을 포함하면, 레이트가 사전정의되고, 과금 시스템은 수수료를 계산할 수도 있다. 과금 플랜이 제 3 자 개발자에 의해 레이팅된 수수료들을 포함하면, 레이트는 애플리케이션의 사용 또는 사용자 속성들에 기초하여 제 3 자 개발자에 의해 결정될 수도 있다. 수수료가 사용자 속성들에 기초하여 제 3 자 개발자에 의해 레이팅되면, 과금 레이트는 상이한 가입자들에 대해 상이할 수도 있다(예를 들어, 낮은 양의 판매자들에 대해 특정한 과금 레이트 및 높은 양의 판매자들에 대해 다른 과금 레이트).

가입자(702)에 대한 적절한 과금 레이트를 결정하기 위해, 제 3 자 플랫폼(706)은 가입자(702)와 연관된 사용자 정보를 요청하는 메시지(716)를 전송할 수도 있다. 사용자 정보에 기초하여, 제 3 자 플랫폼(706)은 가입자(702)에 대한 적절한 과금 레이트를 결정할 수도 있고(예를 들어, 사용 데이터에 대해 API를 통해) 레이트를 패스한다. 예를 들어, 사용자 정보는 가입자(702)가 파워 판매자이라는 것을 나타낼 수도 있다. 따라서, 제 3 자 플랫폼(706)은 파워 판매자와 연관된 수수료에 기초하여 후속 사용 수수료 또는 반복 수수료를 기록할 수도 있다. 한편, 사용자 정보는 가입자(702)가 낮은 양의 판매자이라는 것을 나타낼 수도 있고, 그 결과, 상이한 레이트로 청구되어야 한다.

도 7은 가입자(702)가 메시지(718)에 의해 표시된 바와 같이, 제 3 자 애플리케이션(708)을 동작 또는 사용할 수도 있다는 것을 도시한다. 가입자의 사용에 응답하여, 제 3 자 애플리케이션(708)은 사용 기반 수수료를 기록하기 위한 메시지(722)를 제 3 자 플랫폼(706)에 전송할 수도 있다. 사용을 기록하기 위한 메시지(720)의 수신에 응답하여, 제 3 자 플랫폼(706)은 메시지(716)에서 이전에 선택된 레이트에 기초하여 가입자(702)에 대한 적절한 수수료를 결정할 수도 있고, 적절한 수수료를 메시지(722)에서 애플리케이션 시장 플랫폼(704)에 통신할 수도 있다. 애플리케이션 시장 플랫폼(704)은 서브-계좌 아래에 수수료를 저장할 수도 있고(예를 들어, 메시지 724), 적절한 시간(예를 들어, 즉시 또는 결정가능한 주기(예를 들어, 매달)에 기초하여)에 가입자(702)에게 과금할 수도 있다.

도 8은 애플리케이션 시장 플랫폼(804)에 저장된 가입자 정보에 기초하여 가입자(802)에게 청구하는 대안의 접근방식을 도시한다. 도 7의 메시지들(700)이 도 7의 가입자(702)가 또한 도 7의 제 3 자 애플리케이션(708)에 가입할 때 사용자 정보에 기초하여 과금 요금을 결정하는 반면에, 메시지들(800)은 가입자(802)에 의한 제 3 자 애플리케이션(808)의 각 사용을 기록한 이후에 과금 요금을 결정한다. 예시하기 위해, 제 3 자 애플리케이션(808)이 가입자(802)의 사용을 기록하기 위한 메시지(810)를 전송하는 것에 응답하여, 제 3 자 플랫폼(806)은 메시지(812)에서 애플리케이션 시장 플랫폼(804)으로부터 사용자 정보를 요청한다. 사용자 정보의 수신에 기초하여, 메시지(814)에서, 제 3 자 애플리케이션(806)은 가입자의 사용에 대한 적절한 레이트를 결정하고, 그 후, 사용 수수료를 추가하기 위해 메시지(816)를 애플리케이션 시장 플랫폼(804)에 전송한다. 이러한 접근방식은 가입자(802)가 제 3 자 애플리케이션(808)에 가입한 이후에 가입자(802)의 상황이 변화하는 경우에도 제 3 자 플랫폼(806)이 적절한 수수료를 자동을 결정하는 이점을 갖는다.

도 9는 몇몇 예시적인 실시예들에 따른, 애플리케이션 시장 플랫폼에 저장된 가입자 정보에 기초하여 가입자에게 청구하는 또 다른 접근방식을 도시한다. 도 7 및 도 8을 비교하여, 도 9의 제 3 자 플랫폼(906)은 애플리케이션 시장 플랫폼(904)에 저장된 사용자 정보(예를 들어, 가입자가 파워 판매자로서 적임인지 여부)에 기초하여 가입을 인가한다. 일 예시적인 실시예에서, 과금 플랜에 가입자(902)를 가입시키기 위한 애플리케이션 시장 플랫폼(904)으로부터의 요청의 수신에 응답하여, 제 3 자 애플리케이션(908)은 애플리케이션 시장 플랫폼(904)으로부터 가입자(902)에 대응하는 사용자 정보를 요청한다. 그 결과, 제 3 자 플랫폼(906)은 가입자가 과금 플랜의 소정의 요건들에 매칭하는지(예를 들어, 가입자가 파워 판매자인지)를 결정할 수도 있다. 이러한 접근방식은 각 과금 플랜이 사용자 정보의 각 가능한 속성에 대한 사용 요금을 정의하는, 복수의 과금 플랜들을 정의하기 보다는, 사용자 정보의 가능한 속성들에 기초하여 하나 이상의 사용 요금들을 포함하는 단일 과금 플랜을 제 3자 개발자가 정의할 수 있게 한다.

상기 명세서가 가입 모델에 관한 과금을 설명하지만, 다른 유사한 모델들이 예시적인 실시예들에 또한 제공될 수도 있다는 것에 유의한다. 예를 들어, 애플리케이션 시장 플랫폼은 1회 구매 과금 플랜들을 허용할 수도 있다. 또한, 애플리케이션 시장 플랫폼이 가입자, 제 3 자 개발자, 및 금융 기관 사이의 트랜잭션을 간단히 가능하게 할 수도 있다는 것에 유의한다. 이러한 경우에서, 애플리케이션 시장 플랫폼은 수수료의 교환을 직접적으로 처리하기 않거나 이에 대해 책임이 없다. 애플리케이션 시장 플랫폼은 단지 지불 처리를 가능하게 할 수도 있다. 예를 들어, 지불은 가입자의 주 지불 계좌(primary payment account)로부터 공제되고 제 3 자 개발자에 속하는 계좌로 송금된다. 다양한 예시적인 실시예들에서, 사용 요금에 대한 완불은 트랜잭션의 완료 이전에 수금된다. 다르게는, 완불 또는 일부 지불이 1회 지불(예를 들어, 사용자에 의해 개시됨)로 또는 정기적 지불 사이클(예를 들어, 매달 지불)의 일부로서 수금될 수도 있다.

예시적인 머신 아키텍처 및 머신-판독가능한 매체

도 10은 머신으로 하여금 여기에서 논의되는 임의의 하나 이상의 방법들을 수행하게 하는 명령들이 실행될 수도 있는 컴퓨터 시스템(1000)의 예시적인 형태의 머신의 블록도이다. 대안의 실시예에서, 머신은 독립형 디바이스로서 동작하거나 다른 머신들에 접속(예를 들어, 네트워킹)될 수도 있다. 네트워킹된 배치에서, 머신은 서버-클라이언트 네트워크 환경에서 서버 또는 클라이언트 디바이스들의 용량에서, 또는 피어 투 피어(peer-to-peer) (또는 분산) 네트워크 환경에서 피어 머신으로서 동작할 수도 있다. 머신은 개인 컴퓨터, 태블릿 PC, 셋-탑 박스(STB), 개인 휴대 보조 단말기(PDA), 셀룰러 전화, 웹 기구, 네트워크 라우터, 스위치 또는 브리지, 또는 그 머신에 의해 취해질 액션들을 특정하는 명령들(순차적 또는 다르게) 실행할 수 있는 임의의 머신일 수도 있다. 또한, 단일 머신만이 예시되지만, 용어 "머신"은 여기에 논의된 방법들 중 임의의 하나 이상을 수행하기 위해 명령들의 세트(또는 다중 세트)를 개별적으로 또는 함께 실행하는 머신들의 임의의 집합을 포함하는 것으로 취해져야 한다.

예시적인 컴퓨터 시스템(1000)은 버스(1008)를 통해 서로 통신하는 프로세서(1002)(예를 들어, 중앙 처리 유닛(CPU), 그래픽 처리 유닛(GPU), 또는 양자), 메인 메모리(1004) 및 정적 메모리(1006)를 포함한다. 컴퓨터 시스템(1000)은 비디오 디스플레이 유닛(1010)(예를 들어, 액정 디스플레이(LCD) 또는 음극선관(CRT))을 더 포함할 수도 있다. 컴퓨터 시스템(1000)은 영숫자 입력 디바이스(1012)(예를 들어, 키보드), 사용자 인터페이스(UI) 네비게이션 디바이스(1014)(예를 들어, 마우스), 디스크 드라이브 유닛(1016), 신호 생성 디바이스(1018)(예를 들어, 스피커) 및 네트워크 인터페이스 디바이스(1020)를 또한 포함한다.

머신-판독가능한 저장 매체

디스크 드라이브 유닛(1016)은 여기에 설명된 방법들 또는 기능들 중 임의의 하나 이상에 의해 활용되거나 이를 실시하는 명령들(1024)의 하나 이상의 세트들 및 데이터 구조들(예를 들어, 소프트웨어)이 저장된 머신-판독가능한 저장 매체(1022)를 포함한다. 명령들(1024)은 또한 컴퓨터 시스템(1000)에 의한 실행 동안 메인 메모리(1004) 및/또는 프로세서(1002)내에 완벽하게 또는 적어도 부분적으로 상주할 수도 있고, 메인 메모리(1004) 및 프로세서(1002)는 머신-판독가능한 매체를 또한 구성한다.

머신-판독가능한 저장 매체(1022)가 예시적인 실시예에서 단일 매체인 것으로 도시되어 있지만, 용어 "머신-판독가능한 저장 매체"는 하나 이상의 명령들(1024) 또는 데이터 구조들을 저장하는 단일 매체 또는 다중 매체(예를 들어, 집중 또는 분산 데이터베이스, 및/또는 연관된 캐시들 및 서버들)를 포함할 수도 있다. 용어 "머신-판독가능한 저장 매체"는 머신에 의한 실행을 위해 명령들을 저장하고, 인코딩하거나 반송할 수 있고, 머신으로 하여금 본 발명의 방법들 중 임의의 하나 이상을 수행하게 하거나, 이러한 명령들에 의해 활용되거나 연관되는 데이터 구조들을 저장하고, 인코딩하거나 반송할 수 있는 임의의 유형의(tangible) 매체를 포함하는 것으로 또한 취해져야 한다. 용어 "머신-판독가능한 저장 매체"는 그에 따라, 고체 상태 메모리들 및 광 및 자기 매체를 포함하지만 이에 제한되지 않는 것으로 취해져야 한다. 머신-판독가능한 저장 매체의 특수한 예들이 예로서, 반도체 메모리 디바이스들, 예를 들어, 소거가능 프로그래머블 판독 전용 메모리(EPROM), 전기적으로 소거가능한 프로그래머블 판독 전용 메모리(EEPROM), 및 플래시 메모리 디바이스들; 내부 하드 디스크들 및 착탈식 디스크들과 같은 자기 디스크들; 자기-광학 디스크들; 및 CD-ROM 및 DVD-ROM 디스크들을 포함하는 비휘발성 메모리를 포함한다. 더욱이, 머신-판독가능한 저장 매체는 비일시적 머신-판독가능한 저장 매체일 수도 있다.

송신 매체

명령들(1024)은 송신 매체를 사용하여 통신 네트워크(1026)를 통해 더 송신 또는 수신될 수도 있다. 명령들(1024)은 네트워크 인터페이스 디바이스(1020) 및 다수의 널리 공지된 전송 프로토콜들(예를 들어, 하이퍼텍스트 전송 프로토콜(HTTP))을 사용하여 송신될 수도 있다. 통신 네트워크들의 예들은, 로컬 영역 네트워크(LAN), 광역 네트워크(WAN), 인터넷, 모바일 전화 네트워크, 일반 전화 서비스(Plain Old Telephone Service; POTS) 네트워크들, 및 무선 데이터 네트워크들(예를 들어, WiFi 및 WiMax 네트워크들)을 포함한다. 용어 "송신 매체"는 머신에 의한 실행을 위해 명령들을 저장하고, 인코딩하거나 반송할 수 있는 임의의 무형의(intangible) 매체를 포함하는 것으로 취해져야 하고, 이러한 소프트웨어의 통신을 가능하게 하기 위한 디지털 또는 아날로그 통신 신호들 또는 다른 무형의 매체를 포함한다.

모듈들, 컴포넌트들 및 로직

특정한 실시예들이 로직 또는 다수의 컴포넌트들, 모듈들, 또는 메커니즘들(예를 들어, 이하 "컴포넌트들"로 통칭함)을 포함하는 것으로서 여기에 설명된다. 컴포넌트는 특정한 동작들을 수행할 수 있는 유형의 유닛이고 특정한 방식으로 구성 또는 배열될 수도 있다. 예시적인 실시예들에서, 하나 이상의 컴퓨터 시스템들(예를 들어, 독립형, 클라이언트 또는 서버 컴퓨터 시스템) 또는 컴퓨터 시스템의 하나 이상의 컴포넌트들(예를 들어, 프로세서 또는 프로세서들의 그룹)은 여기에 설명한 바와 같은 특정한 동작들을 수행하도록 동작하는 컴포넌트로서 소프트웨어(예를 들어, 애플리케이션 또는 애플리케이션 부분)에 의해 구성될 수도 있다.

다양한 실시예들에서, 컴포넌트는 기계적으로 또는 전자적으로 구현될 수도 있다. 예를 들어, 컴포넌트는 특정한 동작들을 수행하기 위해 영구적으로 구성되는 전용 회로 도는 로직(예를 들어, 특수용 프로세서)을 포함할 수도 있다. 컴포넌트는 특정한 동작들을 수행하기 위해 소프트웨어에 의해 임시로 구성되는 프로그래머블 로직 또는 회로(예를 들어, 범용 프로세서 또는 다른 프로그래머블 프로세서내에 포함됨)를 또한 포함할 수도 있다. 컴포넌트를 기계적으로, 전용의 영구적으로 구성된 회로에서, 또는 임시로 구성된 회로(예를 들어, 소프트웨어에 의해 구성됨)에서 구현할 지의 판정이 비용 및 시간 고려사항들에 의해 구동될 수도 있다는 것이 이해될 것이다.

따라서, 용어 "컴포넌트"는 특정한 방식으로 동작하고/하거나 여기에 설명된 특정한 동작들을 수행하기 위해 물리적으로 구성되고, 영구적으로 구성되거나(예를 들어, 배선됨(hardwired)) 임시적으로 구성되는(예를 들어, 프로그램됨) 엔터티인 유형의 엔터티를 포함하는 것으로 이해되어야 한다. 컴포넌트들이 임시적으로 구성되는(예를 들어, 프로그램되는) 실시예들을 고려하면, 컴포넌트들 각각은 임의의 일 시간의 경우에 구성되거나 예시될 필요는 없다. 예를 들어, 컴포넌트들이 소프트웨어를 사용하여 구성된 범용 프로세서를 포함하는 경우에, 범용 프로세서는 상이한 시간에 각각의 상이한 컴포넌트들로서 구성될 수도 있다. 그에 따라, 소프트웨어는 예를 들어, 일 시간의 경우에서 특정한 컴포넌트를 구성하고 상이한 시간의 경우에서 상이한 컴포넌트를 구성하도록 프로세서를 구성할 수도 있다.

컴포넌트들은 정보를 다른 컴포넌트들에 제공할 수 있고 다른 컴포넌트로부터 정보를 수신할 수 있다. 따라서, 설명한 컴포넌트들은 통신가능하게 커플링되는 것으로서 간주될 수도 있다. 다중의 이러한 컴포넌트들이 동시에 존재하는 경우에, 통신은 컴포넌트들을 접속하는 단일 송신을 통해(예를 들어, 적절한 회로들 및 버스들을 통해) 달성될 수도 있다. 다중의 컴포넌트들이 구성되거나 상이한 시간에 예시되는 실시예들에서, 이러한 컴포넌트들 사이의 통신은 예를 들어, 다중의 컴포넌트들이 액세스하는 메모리 구조들에서의 정보의 저장 및 검색을 통해 달성될 수도 있다. 예를 들어, 일 컴포넌트가 동작을 수행할 수도 있고, 통신가능하게 커플링된 메모리 디바이스에 그 동작의 출력을 저장할 수도 있다. 그 후, 다른 컴포넌트가 추후에, 저장된 출력을 검색 및 처리하기 위해 메모리 디바이스에 액세스할 수도 있다. 컴포넌트들은 또한, 입력 또는 출력 디바이스들과의 통신을 개시할 수도 있고, 자원(예를 들어, 정보의 집합)상에서 동작할 수 있다.

특정한 예시적인 실시예들이 여기에 설명되었지만, 다양한 변경물들 및 변동물들이 본 발명의 더 넓은 사상 및 범위를 벗어나지 않고 이들 실시예들에 대해 이루어질 수도 있다는 것이 명백할 것이다. 따라서, 명세서 및 도면들은 제한적인 개념 보다는 예시적인 것으로 간주된다. 본 명세서의 일부를 형성하는 첨부한 도면은 제한이 아닌 예시로서, 청구물이 실시될 수도 있는 특정한 실시예들을 도시한다. 당업자가 여기에 개시된 교시들을 실시할 수 있게 하기 위해 실시예들이 충분하게 상세히 설명되고 예시되었다. 다른 실시예들이 사용될 수도 있고 그로부터 유도될 수도 있어서, 구조적 및 논리적 대체물들 및 변경물들이 본 개시물의 범위를 벗어나지 않고 이루어질 수도 있다. 따라서, 상세한 설명은 제한하는 관점에서 취해지지 않고, 다양한 실시예들의 범위는 청구범위가 주어지는 등가물들의 전체 범위에 따라 첨부한 청구범위에 의해서만 정의된다.

발명의 주제의 이러한 실시예들은 단지 편의를 위해 및 사실 2개 이상이 개시되는 경우에 본 출원의 범위를 임의의 단일 발명 또는 발명적 개념으로 자발적으로 제한하는 것을 의도하지 않고 용어 "발명"에 의해 개별적으로 및/또는 통칭적으로 여기에서 지칭될 수도 있다. 따라서, 특정한 실시예들이 여기에 예시되고 설명되었지만, 동일한 목적을 달성하기 위해 적응된 임의의 장치가 도시된 특정한 실시예들에 대체될 수도 있다는 것을 이해해야 한다. 본 개시물은 다양한 실시예들의 임의의 및 모든 적응물들 또는 변경물들을 커버하는 것으로 의도된다. 상기 실시예들과, 여기에 구체적으로 설명하지 않은 다른 실시예들의 조합이 상기 설명을 리뷰할 때 당업자에게는 명백할 것이다. 또한, 구체적으로 다르게 언급하지 않으면, 용어들 "a" 또는 "an"은 특허 문헌들에서는 공통인 바와 같이, 하나의 경우 보다 많은 하나 이상을 포함하는 것으로 여기에서 사용된다. 마지막으로, 여기에서 사용되는 바와 같이, 접속사 "또는"은 다르게 구체적으로 언급하지 않으면 비배타적 "또는"을 칭한다.

Claims

애플리케이션 시장 플랫폼(application marketplace platform)에 의해 배치된 제 3 자 애플리케이션을 저장하도록 구성된 애플리케이션 모듈과,
상기 제 3 자 애플리케이션과 연관된 과금 플랜(billing plan)을 저장하도록 구성된 과금 프로파일 모듈－상기 과금 플랜은 상기 제 3 자 애플리케이션에 가입하기 위한 수수료를 정의함－과,
하나 이상의 프로세서들을 사용하여, 상기 과금 플랜에 따라 상기 제 3 자 애플리케이션에 가입하기 위한 사용자 요청의 수신에 응답하여 서브-계좌(sub-account)를 생성하도록 구성된 계좌 프로파일 모듈－상기 사용자 요청은 사용자의 디바이스로부터 수신되고, 상기 서브-계좌는 상기 애플리케이션 시장 플랫폼에서 상기 사용자의 사용자 계좌에 링크된 제 3 자 애플리케이션 계좌임－과,
상기 과금 플랜에 의해 정의된 상기 수수료에 따라 상기 서브-계좌와 개발자 계좌 사이의 과금 트랜잭션을 가능하게 하도록 구성된 과금 모듈을 포함하는
시스템.
제1항에 있어서,
상기 과금 플랜은 상기 제 3 자 애플리케이션의 사용에 기초하여 상기 사용자에 대한 비용을 나타내는 사용 수수료를 더 정의하는
시스템.
제1항에 있어서,
상기 제 3 자 애플리케이션으로부터, 상기 사용자에 의한 상기 제 3 자 애플리케이션의 사용을 나타내는 사용 정보를 수신하도록 구성된 사용 모듈을 더 포함하는
시스템.
제1항에 있어서,
상기 제 3 자 애플리케이션과 연관된 제 3 자 플랫폼에 의한 요청에 응답하여 사용자 정보를 제공하도록 구성된 애플리케이션 통합 인터페이스 모듈을 더 포함하고, 상기 사용자 정보는 적절한 수수료를 결정하기 위해 상기 제 3 자 애플리케이션에 의해 사용되는
시스템.
제4항에 있어서,
상기 사용자 정보는 상기 사용자가 대량 판매자(high-volume seller)라는 것을 나타내는
시스템.
제1항에 있어서,
상기 제 3 자 애플리케이션에 사용자 정보를 제공하도록 구성된 애플리케이션 통합 인터페이스 모듈을 더 포함하고, 상기 사용자 정보는 상기 과금 플랜에 따라 상기 제 3 자 애플리케이션에 가입하기 위한 상기 사용자에 의한 요청을 인가하기 위해 상기 제 3 자 애플리케이션에 의해 사용되는
시스템.
제1항에 있어서,
상기 과금 플랜을 인가하고, 상기 과금 플랜의 인가에 응답하여, 상기 과금 플랜을 구성하도록 구성된 과금 플랜 검사 모듈(billing plan vetting module)을 더 포함하는
시스템.
애플리케이션 시장 플랫폼으로부터 제 3 자 애플리케이션을 배치하는 단계와,
상기 제 3 자 애플리케이션과 연관된 과금 플랜을 저장하는 단계－상기 과금 플랜은 상기 제 3 자 애플리케이션에 가입하기 위한 수수료를 정의함－와,
머신의 하나 이상의 프로세서를 사용하여, 상기 과금 플랜에 따라 상기 제 3 자 애플리케이션에 가입하기 위한 사용자 요청의 수신에 응답하여 서브-계좌를 생성하는 단계－상기 사용자 요청은 사용자의 디바이스로부터 수신되고, 상기 서브-계좌는 상기 애플리케이션 시장 플랫폼에서 상기 사용자의 사용자 계좌에 링크된 제 3 자 애플리케이션 계좌임－와,
상기 과금 플랜에 의해 정의된 상기 수수료에 따라 상기 서브-계좌와 개발자 계좌 사이의 과금 트랜잭션을 가능하게 하는 단계를 포함하는
컴퓨터로 구현되는 방법.
제8항에 있어서,
상기 과금 플랜은 상기 제 3자 애플리케이션의 사용에 기초하여 상기 사용자에 대한 비용을 나타내는 사용 수수료를 더 정의하는
컴퓨터로 구현되는 방법.
제8항에 있어서,
상기 제 3 자 애플리케이션으로부터, 상기 사용자에 의한 상기 제 3 자 애플리케이션의 사용을 나타내는 사용 정보를 수신하는 단계를 더 포함하는
컴퓨터로 구현되는 방법.
제8항에 있어서,
제 3 자 플랫폼으로부터의 요청의 수신에 응답하여 상기 제 3 자 애플리케이션과 연관된 상기 제 3 자 플랫폼에 사용자 정보를 제공하는 단계를 더 포함하고, 상기 사용자 정보는 적절한 수수료를 결정하기 위해 상기 제 3 자 애플리케이션에 의해 사용되는
컴퓨터로 구현되는 방법.
제11항에 있어서,
상기 사용자 정보는 상기 사용자가 대량 판매자라는 것을 나타내는
컴퓨터로 구현되는 방법.
제8항에 있어서,
사용자 정보를 제 3 자 플랫폼에 제공하는 단계를 더 포함하고, 상기 사용자 정보는 상기 사용자가 상기 과금 플랜에 가입하는 것을 인가하기 위해 상기 제 3 자 플랫폼에 의해 사용되는
컴퓨터로 구현되는 방법.
제8항에 있어서,
정책(policy)에 기초하여 상기 과금 플랜을 인가하는 단계와,
상기 과금 플랜의 인가에 응답하여 상기 과금 플랜을 구성하는 단계를 더 포함하는
컴퓨터로 구현되는 방법.
머신의 하나 이상의 프로세서들에 의해 실행될 때, 상기 머신으로 하여금,
애플리케이션 시장 플랫폼으로부터 제 3 자 애플리케이션을 배치하는 것과,
상기 제 3 자 애플리케이션과 연관된 과금 플랜을 저장하는 것－상기 과금 플랜은 상기 제 3 자 애플리케이션에 가입하기 위한 수수료를 정의함－과,
상기 과금 플랜에 따라 상기 제 3 자 애플리케이션에 가입하기 위한 사용자 요청의 수신에 응답하여 서브-계좌를 생성하는 것－상기 사용자 요청은 사용자의 디바이스로부터 수신되고, 상기 서브-계좌는 상기 애플리케이션 시장 플랫폼에서 상기 사용자의 사용자 계좌에 링크된 제 3 자 애플리케이션 계좌임－과,
상기 과금 플랜에 의해 정의된 상기 수수료에 따라 상기 서브-계좌와 개발자 계좌 사이의 과금 트랜잭션을 가능하게 하는 것을 포함하는 동작들을 수행하게 하는 명령어들을 포함하는
비일시적 머신-판독가능한 저장 매체.
제15항에 있어서,
상기 과금 플랜은 상기 제 3자 애플리케이션의 사용에 기초하여 상기 사용자에 대한 비용을 나타내는 사용 수수료를 더 정의하는
비일시적 머신-판독가능한 저장 매체.
제15항에 있어서,
상기 동작들은 상기 제 3 자 애플리케이션으로부터 사용 정보를 수신하는 것을 더 포함하고, 상기 사용 정보는 상기 사용자에 의한 상기 제 3 자 애플리케이션의 사용을 나타내는
비일시적 머신-판독가능한 저장 매체.
제15항에 있어서,
상기 동작들은 요청의 수신에 응답하여 상기 제 3 자 애플리케이션과 연관된 상기 제 3 자 플랫폼에 사용자 정보를 제공하는 것을 더 포함하고, 상기 사용자 정보는 적절한 수수료를 결정하기 위해 상기 제 3 자 애플리케이션에 의해 사용가능한
비일시적 머신-판독가능한 저장 매체.
제15항에 있어서,
상기 사용자 정보는 상기 사용자가 대량 판매자라는 것을 나타내는
비일시적 머신-판독가능한 저장 매체.
제19항에 있어서,
상기 동작들은 사용자 정보를 제 3 자 플랫폼에 제공하는 것을 더 포함하고, 상기 사용자 정보는 사용자가 상기 과금 플랜에 가입하는 것을 인가하기 위해 상기 제 3 자 플랫폼에 의해 사용가능한
비일시적 머신-판독가능한 저장 매체.
제15항에 있어서,
상기 동작들은, 상기 제 3 자 애플리케이션에 의해 제시(submit)될 때 상기 과금 플랜을 수신하는 것과, 정책들의 세트에 기초하여 상기 과금 플랜을 인가하는 것을 더 포함하는
비일시적 머신-판독가능한 저장 매체.