KR100964766B1 - 무선 가입자 빌링 및 배포 방법 및 장치 - Google Patents

Abstract

무선 가입자 빌링 시스템에서 빌링 요청들을 생성하고 빌링 요청들에 응답하기 위한 시스템들 및 방법들이 제시된다. 빌링 요청은 신뢰된 서비스에서 생성될 수 있다. 빌링 정보를 포함하는 빌링 요청은 무선 가입자 빌링 시스템으로 전달된다. 빌링 요청에 대한 검증 응답이 무선 가입자 빌링 시스템에서 생성되고 검증 응답은 신뢰된 서비스로 전달된다.

Description

무선 가입자 빌링 및 배포 방법 및 장치{WIRELESS SUBSCRIBER BILLING AND DISTRIBUTION}

본 발명은 일반적으로 원격 컴퓨팅 장치들 및 서버들 사이의 통신들에 관한 것이다. 더욱 상세하게는, 본 발명은 서버 및 원격 클라이언트 장치 사이에서 빌링 이벤트들의 생성 및 전송에 관한 것이다.

기술의 진보로 인해 더 작고 보다 강력한 개인 컴퓨팅 장치들이 제공되고 있다. 예를 들어, 작고, 가벼우며, 사용자들에 의해 용이하게 소지될 수 있는, 휴대용 무선 전화기들, 개인 정보 단말기들(PDAs) 및 페이징 장치들과 같은 무선 컴퓨팅 장치들을 포함하는 다양한 휴대용 개인 컴퓨팅 장치들이 현재 존재한다. 보다 상세하게는, 예를 들어, 휴대용 무선 전화기들은 또한 무선 네트워크들을 통해 음성 및 데이터 패킷들을 전달하는 셀룰러 전화기들을 포함한다. 또한, 이러한 많은 셀룰러 전화기들은 상대적으로 크게 증가된 컴퓨팅 능력들을 가지도록 제조되고 있으며, 이에 따라 소형 개인용 컴퓨터들 및 핸드-헬드 PDA들에 상당한 능력을 가지고 있다. 그러나, 이러한 더 작고 더 강력한 개인용 컴퓨팅 장치들은 전형적으로 매우 제한된 자원을 가지고 있다. 예를 들어, 스크린 크기, 이용가능한 메모리 및 파일 시스템 공간의 양, 입력 및 출력 능력들의 양 및 프로세싱 능력은 각각 장치 의 작은 크기, 특히 사용자 입력 유니트, 예를 들어, 키보드의 작은 크기에 의해 제한될 수 있다. 이러한 엄격한 자원 제약들로 인하여, 예를 들어, 종종 원격 개인용 컴퓨팅 장치들(클라이언트 장치들)에 상주하는 소프트웨어 애플리케이션들 및 다른 정보의 제한된 크기 및 양을 유지하는 것이 바람직하다.

몇몇 개인용 컴퓨팅 장치들은 이들의 로컬 컴퓨터 플랫폼에 설치되며 예컨대 장치별로 특정된 자원들에 대한 일반화된 호출들을 제공함으로써 이러한 장치들의 동작들을 단순화하기 위해 사용되는, 종종 런타임 환경들 및 소프트웨어 플랫폼들로서 지칭되는, 애플리케이션 프로그래밍 인터페이스들(APIs)을 이용한다. 또한, 몇몇 이러한 API들은 소프트웨어 개발자들에게 이러한 장치들을 통해 충분히 실행될 수 있는 소프트웨어 애플리케이션들을 개발할 수 있는 능력을 제공하도록 알려져 있다. 또한, 몇몇 이러한 API들은 컴퓨팅 장치 시스템 소프트웨어 및 소프트웨어 애플리케이션들 사이에 위치하여 동작하도록 알려져 있으며, 그 결과 컴퓨팅 장치의 컴퓨팅 기능은 소프트웨어 개발자가 특정한 컴퓨팅 장치 시스템 소스 코드를 가지고 있도록 요구함이 없이 소프트웨어 애플리케이션들에 대하여 이용가능하도록 이루어진다. 또한, 몇몇 API들은 안전한 암호 정보를 이용하여 이러한 개인용 장치들(즉, 클라이언트들) 및 원격 장치들(즉, 서버들) 사이에서의 안전한 통신들을 위한 메커니즘들을 제공하도록 알려져 있다.

이러한 API들의 예들로는 캘리포니아 샌디에고에 소재한 퀄컴사에 의해 개발된 무선 소프트웨어를 위한 바이너리 런타임 환경(BREW®)의 버전들이 있으며, 상기 예들 중 일부는 아래에서 보다 상세하게 설명된다. BREW®는 컴퓨팅 장치(예를 들어, 무선 셀룰러 폰)의 운영 시스템과 연동하여 동작할 수 있으며, 다른 특징들 중에서, 개인용 컴퓨팅 장치들에 대하여 특별히 발견되는 하드웨어 특징들에 대한 인터페이스들을 제공할 수 있다. BREW®는 또한 장치 자원들에 대한 요구들과 관련하여 그리고 BREW®를 포함하는 장치들에 대하여 소비자들에 의해 지불되는 가격과 관련하여 상대적으로 낮은 비용으로 이러한 개인용 컴퓨팅 장치들에 대하여 인터페이스들을 제공할 수 있다. BREW®의 추가적인 특징들은 무선 서비스 운영자들, 소프트웨어 개발자들 및 컴퓨팅 장치 소비자들에 대하여 다양한 이익들을 제공하는 BREW®의 엔드-투-엔드 소프트웨어 배포(distribution) 플랫폼을 포함한다. 적어도 하나의 이러한 현재 이용가능한 엔드-투-엔드 소프트웨어 배포 플랫폼은 서버-클라이언트 아키텍처를 통해 배포되는 로직을 포함하며, 여기서 서버는 예컨대 빌링(billing), 보안 및 애플리케이션 배포 기능을 수행하고, 클라이언트는 예컨대 애플리케이션 실행, 보안 및 사용자 인터페이스 기능을 수행한다.

관련된 기술에 대한 이전의 설명은 단지 API들의 몇몇 알려진 사용들을 개략적으로 살펴보고, 본 발명의 실시예들에서 사용될 수 있는, BREW® 플랫폼에 대하여 소개하기 위하여 의도된 것이다. 그러나, 본 발명은 특정한 구현, 동작 플랫폼 또는 환경에 제한되도록 해석되지 않는다.

무선 네트워크에서 빌링 요청들을 생성하여 처리하기 위한 시스템 및 방법에 관한 본 발명의 예시적인 실시예들이 제시된다.

이에 따라, 본 발명의 실시예는 신뢰된(trusted) 서비스에서 빌링 요청을 생성하는 단계; 빌링 정보를 포함하는 빌링 요청을 무선 가입자 빌링 시스템으로 전달하는 단계; 무선 가입자 빌링 시스템에서 빌링 요청에 대한 검증(validation) 응답을 생성하는 단계; 및 신뢰된 서비스로 검증 응답을 전달하는 단계를 포함하는 방법을 포함할 수 있다.

본 발명의 다른 실시예는 신뢰된 서비스로부터 빌링 요청을 수신하고 신뢰된 서비스를 인증하도록 구성된 무선 가입자 빌링 시스템에 있는 서비스 값 빌링(SVB: service value billing) 모듈; 및 빌링 요청에 응답하여 검증 응답을 생성하도록 구성된 검증 로직을 포함하는 장치를 포함할 수 있다.

본 발명의 다른 실시예는 무선 가입자 빌링 시스템에서 신뢰된 서비스로부터의 빌링 정보를 포함하는 빌링 요청을 수신하기 위한 수단; 무선 가입자 빌링 시스템에서 빌링 요청에 대한 검증 응답을 생성하기 위한 수단; 및 신뢰된 서비스로 검증 응답을 전달하기 위한 수단을 포함하는 시스템을 포함할 수 있다.

본 발명의 다른 실시예는 무선 가입자 빌링 시스템에서 빌링 요청들을 처리하기 위한 컴퓨터 프로그램이 저장된 컴퓨터-판독가능 매체를 포함할 수 있으며, 상기 컴퓨터 프로그램은, 실행될 때, 컴퓨팅 장치가 신뢰된 서비스로부터 빌링 요청을 수신하는 단계 - 빌링 요청은 무선 가입자 빌링 시스템에 대한 빌링 정보를 포함함 -; 무선 가입자 빌링 시스템에서 빌링 요청에 대한 검증 응답을 생성하는 단계; 및 신뢰된 서비스로 검증 응답을 전달하는 단계를 포함하는 프로세스를 수행하도록 하는 명령들을 포함한다.

본 발명의 또다른 실시예는 무선 가입자 빌링 시스템에서 멀티-파티(multi-party) 빌링 이벤트들을 처리하는 방법을 포함할 수 있으며, 상기 방법은 제공자 요금(fee) 및 수취인(payee)과 거래와 관련된 적어도 하나의 소스 요금 및 수취인을 포함하는 빌링 이벤트를 생성하는 단계; 및 제공자 수취인 및 적어도 하나의 소스 수취인에 대한 지불을 배포하기 위해 상기 거래를 처리하는 단계를 포함한다.

본 발명의 실시예들의 특징들 및 장점들은 아래의 상세한 설명 및 도면으로부터 보다 명백해질 것이다.

도 1은 본 발명의 적어도 하나의 실시예에 따른 클라이언트 장치들 및 서버들을 지원하는 무선 네트워크 아키텍처에 대한 다이어그램이다.

도 2는 본 발명의 적어도 하나의 실시예에 따른 클라이언트 장치들 및 서버들을 지원하는 무선 네트워크 아키텍처에 대한 보다 상세한 다이어그램이다.

도 3은 본 발명의 적어도 하나의 실시예에 따른 애플리케이션 값 빌링 시스템의 시스템 레벨 일러스트레이션(illustration)이다.

도 4는 본 발명의 적어도 하나의 실시예에 따른 서비스 값 빌링 시스템의 시스템 레벨 일러스트레이션이다.

도 5는 본 발명의 적어도 하나의 실시예에 따른 그룹 배포 시스템의 시스템 레벨 일러스트레이션이다.

도 6은 본 발명의 적어도 하나의 실시예에 따른 시스템 엘리먼트들을 포함하는 대안적인 구매 프로세스의 시스템 레벨 일러스트레이션이다.

도 7은 본 발명의 적어도 하나의 실시예에 따른 멀티-파티 지불(settlement) 및 CRM 시스템의 시스템 레벨 일러스트레이션이다.

도 8-11은 본 발명의 실시예들에 따른 방법들을 도시하는 플로우차트들이다.

본 발명의 양상들은 본 발명의 특정한 실시예들과 관련하여 다음의 설명 및 관련된 도면에서 제시된다. 대안적인 실시예들은 본 발명의 범위를 벗어남이 없이 고안될 수 있다. 추가적으로, 본 발명의 잘-알려진 엘리먼트들에 대하여는 본 발명의 관련된 세부사항들을 불명확하게 하지 않도록 하기 위해 상세하게 설명되지 않거나 생략될 것이다.

"예시적인(exemplary)"이라는 단어는 여기서 "예시, 실례 또는 예해로서 제공되는" 것을 의미하도록 사용된다. "예시적인"으로 여기에서 설명되는 실시예 또는 설계는 반드시 다른 실시예들 또는 설계들보다 우선적이거나 또는 바람직한 것으로 해석되지 않는다. 이와 비슷하게, "본 발명의 실시예들"이라는 용어는 본 발명의 모든 실시예들이 논의된 특징, 장점 또는 동작 모드를 포함하는 것을 요구하지는 않는다.

또한, 많은 실시예들은 예컨대 컴퓨팅 장치의 엘리먼트들에 의해 수행되는 동작들의 시퀀스들과 관련하여 설명된다. 여기에서 설명되는 다양한 동작들은 특정한 회로들(예를 들어, 애플리케이션 특정 집적 회로들(ASICs))에 의해, 하나 이상의 프로세서들에 의해 실행되는 프로그램 명령들에 의해, 또는 이들 모두의 결합에 의해 수행될 수 있다. 추가적으로, 여기서 설명되는 이러한 동작들의 시퀀스는 실행시에 관련된 프로세서가 여기에 설명된 기능을 수행하도록 하는 컴퓨터 명령들 의 대응하는 세트를 저장하는 임의의 형태의 컴퓨터 판독가능 저장 매체 내에서 구현되도록 고려될 수 있다. 그리하여, 본 발명의 다양한 양상들은 다수의 상이한 형태들로 구현될 수 있으며, 이러한 형태들 모두는 청구되는 대상의 범위 내에 있는 것으로 간주된다. 또한, 여기에 설명된 실시예들 각각에 대하여, 임의의 이러한 실시예들의 대응하는 형태는 예컨대 설명된 동작을 수행하도록 "구성된 로직"으로서 설명될 수 있다.

본 발명의 하나 이상의 실시예들은 컴퓨팅 장치에서 실행되는 런타임 환경(예를 들어, API)과 관련하여 이용될 수 있다. 하나의 이러한 런타임 환경으로는 이전에 논의된 무선 소프트웨어를 위한 바이너리 런타임 환경(BREW®)이 있다. 그러나, 본 발명의 하나 이상의 실시예들은 예컨대 무선 클라이언트 컴퓨팅 장치에서의 애플리케이션들의 실행을 제어하도록 동작하는 다른 타입들의 런타임 환경들 또는 플랫폼들을 통해 이용될 수 있다.

추가적으로, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 배포되고 실행되는 애플리케이션 파일 타입이 설명의 단순화를 위해 여기에서 설명될 수 있다는 것을 이해할 것이다. 그러나, "애플리케이션"은 또한 오브젝트 코드, 스크립트들, 자바 파일, 북마크 파일(또는 PQA 파일), WML 스크립트들, 바이트 코드 및 펄(perl) 스크립트들과 같은 실행가능한 컨텐트를 가지는 파일들을 포함할 수 있다. 또한, 여기에서 참조되는 "애플리케이션"은 열릴 필요가 있는 문서들 또는 액세스될 필요가 있는 다른 데이터 파일들과 같은 사실상 실행되지 않는 파일들을 포함할 수 있다.

도 1은 본 발명의 적어도 하나의 실시예에 따른 무선 시스템(100)의 하나의 예시적인 실시예의 블록 다이어그램을 나타낸다. 시스템(100)은 무선 통신 포털(portal) 또는 무선 네트워크(104)에 대한 다른 데이터 액세스를 통해 소프트웨어 애플리케이션들 및 컴포넌트들을 무선 장치들로 선택적으로 전송하는 적어도 하나의 애플리케이션 다운로드 서버(106)와 무선 네트워크(104)를 통해 통신하는 셀룰러 전화기(102)와 같은 클라이언트 장치들을 포함할 수 있다. 여기에 도시된 바와 같이, 무선 (클라이언트) 장치는 셀룰러 전화기(102), 개인 정보 단말기(PDA)(108), 여기에서 양방향 텍스트 페이저로서 도시된 페이저(110), 또는 무선 통신 포털을 가지는 개별적인 컴퓨터 플랫폼(112)일 수 있다. 본 발명의 실시예들은 그리하여 무선 통신 포털을 포함하거나 또는 무선 모뎀들, PCMCIA 카드들, 개인용 컴퓨터들, 액세스 터미널들, 전화기들 또는 이들의 임의의 결합이나 서브-결합을 제한없이 포함하는 무선 통신 능력들을 가지는 임의의 형태의 클라이언트 장치를 통해 구현될 수 있다.

애플리케이션 다운로드 서버(ADS)(106)는 무선 네트워크(104)와 통신하는 다른 컴퓨터 엘리먼트들과 함께 네트워크(116) 상에 도시되어 있다. 스탠드-얼론(stand-alone) 서버(122)가 존재할 수 있으며, 각각의 서버는 무선 네트워크(104)를 통해 개별적인 서비스들 및 프로세스들을 클라이언트 장치들(102, 108, 110, 112)로 제공할 수 있다. 바람직하게는, 또한 무선 장치들(102, 108, 110, 112)에 의해 다운로드될 수 있는 소프트웨어 애플리케이션들 및 컨텐트를 포함하는 적어도 하나의 저장된 애플리케이션 데이터베이스(118)가 존재한다. 그러나, 본 발명의 속하는 기술분야에서 통상의 지식을 가진 자는 도 1에 도시된 구성이 단지 예시적인 것임을 이해할 것이다. 이에 따라, 본 발명의 실시예들은 하나 이상의 서버들을 포함할 수 있으며, 하나 이상의 서버들 각각은 모든 설명된 기능들을 수행할 수 있고 모든 필요한 하드웨어 및 소프트웨어를 포함할 수 있거나, 또는 오직 선택된 기능만을 포함할 수 있다.

도 2에서, 시스템(100)을 보다 상세하게 설명하는 블록 다이어그램이 도시되어 있으며, 시스템(100)은 무선 네트워크(104)의 컴포넌트들 및 본 발명의 예시적인 실시예들의 엘리먼트들에 대한 상호관계를 포함한다. 시스템(100)은 단지 예시적이며 무선 클라이언트 컴퓨팅 장치들(102, 108, 110, 112)과 같은 원격 클라이언트 장치들이 서로에 대하여 그리고/또는 무선 네트워크 캐리어들 및/또는 서버들을 제한없이 포함하는 무선 네트워크(104)를 통해 연결된 컴포넌트들 사이에서 무선으로 통신하도록 허용하는 임의의 시스템을 포함할 수 있다. 셀룰러 원격 통신 서비스들을 제공하기 위해 사용되는 빌링 서버(130)와 같은 임의의 다른 서버들과 함께, 애플리케이션 다운로드 서버(106) 및 저장된 애플리케이션 데이터베이스(118)는 인터넷, 보안 LAN, WAN 또는 다른 네트워크와 같은 데이터 링크를 통해 캐리어 네트워크(200)와 통신한다. 도시된 실시예에서, 서버(120)는 애플리케이션 다운로드 서버(106), 빌링 서버(130) 및 저장된 애플리케이션 데이터베이스(118)를 포함할 수 있다. 그러나, 이러한 서버들은 또한 독립적인 장치들일 수 있다.

캐리어 네트워크(200)는 메시징 서버스 제어기("MSC")(202)로 전송된 (일반적으로 데이터 패킷들로서 전송된) 메시지들을 제어한다. 캐리어 네트워크(200)는 네트워크, 인터넷 및/또는 공중 스위칭 전화 네트워크(PSTN)에 의해 MSC(202)와 통신한다. 전형적으로, 캐리어 네트워크(200) 및 MSC(202) 사이의 네트워크 또는 인터넷 접속은 데이터를 전달하며, PSTN 접속은 음성 정보를 전달한다. MSC(202)는 다수의 기지국들("BTS")(204)로 연결될 수 있다. 캐리어 네트워크와 유사한 방식으로, MSC(202)는 전형적으로 데이터 전달 및/또는 음성 정보를 위해 네트워크, 인터넷 및/또는 PSTN에 의해 BTS(204)와 연결된다. BTS(204)는 단문 메시징 서비스("SMS") 또는 기술적으로 공지된 다른 무선(OTA: over-the-air) 방법들에 의해 셀룰러 전화기(102)와 같은 클라이언트 장치들로 무선으로 데이터 메시지들을 브로드캐스팅할 수 있다.

셀룰러 전화기(102)와 같은 클라이언트 장치(여기에서 무선 클라이언트 컴퓨팅 장치)는 애플리케이션 다운로드 서버(106), 빌링 서버(130) 및/또는 서버(120)로부터 전송된 소프트웨어 애플리케이션들 또는 컨텐트 및/또는 명령들을 수신하여 실행할 수 있는 컴퓨터 플랫폼(206)을 가진다. 컴퓨터 플랫폼(206)은 애플리케이션 특정 집적 회로("ASIC")(208) 또는 다른 프로세서, 마이크로프로세서, 로직 회로, 또는 다른 데이터 프로세싱 장치를 포함할 수 있다. ASIC(208) 또는 다른 프로세서는 무선 장치의 메모리(212)에 있는 임의의 상주 프로그램들과 인터페이싱하는 애플리케이션 프로그래밍 인터페이스("API")(210) 계층을 실행한다. 메모리(212)는 판독-전용(read-only) 또는 랜덤-액세스 메모리(RAM 및 ROM), EEPROM, 플래시 카드들, 또는 컴퓨터 플랫폼들에 공통적인 임의의 메모리로 구성될 수 있다. API(210)는 또한 클라이언트 장치에서 캐리어 네트워크(200)로의 특별한 빌링 요청들을 처리하도록 구성된 로직을 포함하는 애플리케이션-기반 값 빌링 익스텐션(AVB)(310)을 포함한다. 컴퓨터 플랫폼(206)은 또한 메모리(212)에서 활발하게 사용되지 않는 애플리케이션들을 유지할 수 있는 로컬 데이터베이스(214)를 포함한다. 로컬 데이터베이스(214)는 전형적으로 플래시 메모리 셀이나, 자기 매체, EEPROM, 광학 매체, 테이프, 소프트 또는 하드 디스크 등과 같은 기술적으로 공지된 임의의 2차 저장 장치일 수 있다.

셀룰러 전화기(102)와 같은 무선 클라이언트 컴퓨팅 장치는 게임들, 뉴스들, 증권 모니터링 등과 같은 하나 이상의 소프트웨어 애플리케이션들을 설치하거나 또는 다운로드받는다. 예를 들어, 셀룰러 전화기(102)는 다운로드 서버(106)로부터 다운로드된 하나 이상의 소프트웨어 애플리케이션들 및 컨텐트를 수신할 수 있다. 소프트웨어 애플리케이션들 및 컨텐트는 자신들이 사용되지 않을 때 로컬 데이터베이스(214)에 저장될 수 있다. 셀룰러 전화기(102) 또는 다른 무선 컴퓨팅 장치는 로컬 데이터베이스(214)에 저장된 상주 애플리케이션들이 사용자에 의해 요청되거나 또는 다른 API에 의해 호출될 때 상기 애플리케이션들을 메모리(212)로 업로드할 수 있다.

여기서 사용되는 바와 같이, "클라이언트 장치", "무선 장치" 또는 "클라이언트 컴퓨팅 장치"는 예컨대 상주 구성 로직을 실행하는 하나 이상의 프로세싱 회로들을 포함하며, 여기서 이러한 컴퓨팅 장치들은 예컨대 적어도 클라이언트 장치 및 서버 사이에서 전달되는 빌링 정보로 향해지는 여기에 설명된 동작들을 수행하도록 구성된 프로세서들 및 로직을 포함하는 마이크로프로세서들, 디지털 신호 프 로세서들(DSPs), 마이크로컨트롤러들, 휴대용 무선 전화기들, 개인 정보 단말기들(PDAs) 및 페이징 장치들, 또는 하드웨어, 소프트웨어 및/또는 펌웨어의 임의의 적절한 결합을 포함한다. 클라이언트 컴퓨팅 장치는 클라이언트 장치에서 생성되는 빌링 요청들의 처리와 관련하여 적어도 하나의 원격 서버에 의해 서비스될 수 있다. 본 발명의 실시예들에 따라 사용될 수 있는 클라이언트 장치들의 몇몇 예들은 셀룰러 전화기들 또는 다른 무선 통신 유니트들, PDA들, 페이징 장치들, 핸드헬드 내비게이션 장치들, 핸드헬드 게임 장치들, 음악 및 비디오 컨텐트 다운로드 유니트들, 및 다른 유사한 무선 통신 장치들을 포함한다.

클라이언트 장치(102) 및 BTS(204) 사이의 무선 통신은 코드 분할 다중 접속(CDMA), 시분할 다중 접속(TDMA), 주파수 분할 다중 접속(FDMA), 모바일 통신을 위한 글로벌 시스템(GSM), 또는 무선 통신 네트워크 또는 데이터 통신 네트워크에서 사용될 수 있는 다른 프로토콜들과 같은 상이한 기술들에 기반할 수 있다. 데이터 통신은 전형적으로 클라이언트 장치(102), BTS(204) 및 MSC(202) 사이에서 이루어진다. MSC(202)는 캐리어 네트워크(200), PSTN, 인터넷, 가상 사설 네트워크 등과 같은 다수의 데이터 네트워크들로 연결될 수 있으며, 그리하여 클라이언트 장치가 더 넓은 통신 네트워크로 액세스하도록 허용한다. 이전에 논의된 바와 같이, 음성 전송 이외에도, 데이터는 SMS 또는 기술적으로 알려진 다른 OTA 방법들을 통해 클라이언트 장치로 전송될 수 있다.

도 3과 관련하여, AVB 익스텐션(310)(예를 들어, 애플리케이션 내에서 빌링 요청들 및 처리를 가능하게 하는 API)을 포함하는 애플리케이션(320)(예를 들어, BREW® 애플리케이션)을 포함하는 클라이언트 장치(300)가 도시된다. 빌링 요청은 애플리케이션 내에서 생성된다. 이것은 쇼핑 경험이 애플리케이션 레벨에서 제어되도록 허용하고 애플리케이션의 배포 및 가격, 특징들 및/또는 컨텐트에 대한 보다 큰 유연성을 허용한다. 예를 들어, 개발자는 각각 상이한 가격 레벨들을 가지는 다양한 특징들을 가진 아케이드-타입 애플리케이션을 제공하기를 원할 수 있다. 이러한 특징들은 원래의 애플리케이션과 함께 포함될 수 있거나(예를 들어, 상이한 레벨들의 난이도) 또는 원격 서버로부터 다운로드될 수 있다(예를 들어,향상된 배경 음악). 각각의 특징을 구매하기 위한 옵션은 사용자에게 표시될 수 있으며 사용자는 AVB 익스텐션(310)을 사용하여 애플리케이션 레벨에서 추가적인 특징들을 구매할 것인지 여부를 결정할 수 있다. 그에 따라, 하나의 애플리케이션(320)은 다수의 애플리케이션들 및 상이한 애플리케이션들의 다수의 다운로드들에 대한 필요성없이 구별된 가격에 대하여 개발자 및 캐리어를 위한 증가하는 빌링을 생성할 수 있다. 또한, 추가적인 서비스들이 애플리케이션을 통해 가능하기 때문에, 네트워크 기반 애플리케이션은 새로운 애플리케이션을 재배치해야할 필요없이 증가하는 청구들에 대하여 이용가능한 서비스들의 최신 세트를 동적으로 구성할 수 있다. 이러한 예로는 링톤(ringtone) 쇼핑 애플리케이션이 있다. 링톤들은 서버에 저장될 수 있으며 컨텐트 서버가 적절하다고 결정하면 업데이트될 수 있다. AVB 애플리케이션은 실시간으로 소비자에게 디스플레이하기 위해 링톤들 및 가격에 대한 원격 디렉토리에 액세스할 수 있다. 이와 같이, AVB API는 데이터 서비스 제공 및 가격 유연성에 대하여 개발자들 및 운영자들에게 보다 큰 유연성을 제공한다.

반면에, 기존의 시스템들을 사용하여 유사한 기능을 달성하기 위해서, 애플리케이션 개발자는 각각의 특징 및/또는 가격 레벨을 위해 상이한 애플리케이션들을 만들어내고 이들을 다운로드 가능하게 해야 할 것이다. 기존의 시스템들은 각각의 다운로드를 한번의 구매로 취급하고 빌링 정보를 기록하고 각각의 다운로드된 애플리케이션에 대한 지불들을 처리할 것이다. 이러한 프로세서는 캐리어에 의해 제어되며 각각의 애플리케이션을 구매하기 위해 클라이언트 장치는 애플리케이션 카탈로그를 브라우징하는 캐리어 네트워크로 접속하여 원하는 특징들을 가진 원하는 애플리케이션을 구매해야 할 것이다.

위에서 언급된 바와 같이, 본 발명의 실시예들에서, 쇼핑 경험은 클라이언트 장치(300)에 의해 이루어진다. 그에 따라, 구매 옵션이 표시되고 클라이언트 장치(300)에서 수용된 후에, 클라이언트 장치(300)에서 빌링 요청이 생성된다. 빌링 요청 및 빌링 거래를 처리하기 위해 사용되는 다른 정보(예를 들어, 가입자 식별 정보(SID), 컨텐트 제공자(들), 소매 가격 등)는 원격 빌링 시스템(301)으로 전송될 수 있다. 빌링 요청은 원격 빌링 시스템(301)에서 수신되어 처리된다. 원격 빌링 시스템(301)에서 빌링 요청에 응답하여 검증 응답이 생성된다. 검증 응답은 클라이언트 장치(300)로 전송된다.

검증 응답은 빌링 요청에 대한 승인 또는 거부일 수 있다. 클라이언트 장치가 상기 응답을 수신하면, 클라이언트 장치는 그에 따라 검증을 처리할 수 있다. 예를 들어, 검증 응답이 포지티브(positive)하면, 빌링 요청과 링크된 특징(예를 들어, 아케이드 게임에서의 추가적인 레벨)이 활성화될 수 있다. 마찬가지로, 빌 링 요청이 거부되면, 빌링 요청 거부에 대한 표시가 클라이언트 장치를 통해 디스플레이될 수 있다. 선택적으로, 상기 요청이 거부된 이유(예를 들어, 불충분한 자금)와 같은 추가적인 정보가 상기 거부 표시에 포함될 수 있다.

적어도 하나의 실시예에서, 빌링 시스템은 시스템의 구현을 용이하게 하기 위해 존재하는 빌링 컴포넌트들을 레버리징(leverage)할 수 있다. 예를 들어, 도 3에서, 애플리케이션 배포 시스템(ADS)(106)은 클라이언트 장치(300)로부터 빌링 요청을 수신할 수 있다. 그 다음에 ADS(106)는 빌링 엔티티(예를 들어, 캐리어)에 의해 결정될 수 있는 검증 로직(330)으로 액세스할 수 있다. 검증 로직은 원하는 만큼 세부적이거나 또는 제한적일 수 있다. 예를 들어, SID 및 요청된 빌링 액수가 유효하며 충분한 정보가 빌링 이벤트를 생성하기 위해 제공되면(예를 들어, 아이템 ID, 제공자 ID, 공급자 가격(예를 들어, 공급자에게 지불되는 가격) 등), 캐리어는 모든 빌링 이벤트들이 처리되도록 허용할 수 있다. 이러한 정보는 빌링 요청에 직접 포함될 수 있거나 또는 빌링 시스템의 서버에 있는 저장된 정보와 결합하여 생성될 수 있다. 예를 들어, 아이템 ID는 하나 이상의 공급자 ID들 및 관련된 제공자 가격, 아이템 디스크립션(description), 소비자 리스트 가격(CLP) 등과 링크될 수 있다. 그러나, 빌링 요청을 생성하는 클라이언트-기반 거래 동안에 사용자에게 디스플레이되는 가격은 가입자 빌링을 위해 사용되는 가격이어야 하기 때문에, 전형적으로 가격 정보는 AVB(310)로부터 전송될 것이다.

ADS(106)는 아이템 ID에 기반하여 추가적인 빌링 정보를 생성할 수 있다. 추가적으로, 검증 로직(330)이 빌링 요청을 승인하면, ADS(106)는 추가적인 검사들 을 수행할 수 있다. 예를 들어, 클라이언트 가격 방식이 선불 방식이면, 아이템을 구매하기 위한 충분한 자금이 있는지 알기 위해 선불 잔액이 검사될 수 있다. 충분한 자금이 있다면, 상기 승인은 클라이언트 장치로 전송된다. 그러나, 충분한 자금이 없다면, 빌링 요청이 유효하더라도 상기 빌링 요청은 거부된다. 빌링 요청이 최종적으로 빌링 시스템(301)에 의해 승인되면, 상기 승인은 빌링 요청을 생성하였던 AVB(310) 및 애플리케이션(320)에 의해 처리하기 위해 클라이언트 장치(300)로 전송된다.

승인을 전송하는 것 이외에도, ADS(106)는 거래 데이터를 거래 관리자(TXN)(340)로 전달한다. TXN(340)은 ADS(106)로부터 거래 데이터를 수신하도록 구성된다. TXN(340)은 거래 데이터와 함께 포함되지 않은 임의의 추가적인 빌링 정보를 연관시킬 수 있다. 예를 들어, 거래 데이터는 SID, 아이템 ID 및 가격 ID를 포함할 수 있다. TXN(340)은 빌링 프로세스를 완료하기 위해 추가적인 데이터(예를 들어, 공급자 ID들 및 관련된 공급자 가격, 아이템 디스크립션, 풀 프라이스(full pricing) 방식 등)를 연관시킬 수 있다. 그 다음에 TXN(340)는 이러한 정보를 빌링 이벤트로서 클라이언트 빌링 모듈(350) 및 지불(settlement) 모듈(360)로 전달한다. 클라이언트 빌링 모듈(350)은 TXN(340)으로부터 빌링 이벤트를 수신하고 클라이언트 장치(300)와 관련된 가입자에 대한 청구서(bill)를 생성하도록 구성된다. 지불 모듈(360)은 또한 TXN(340)으로부터 빌링 이벤트를 수신하고, 빌링 엔티티(예를 들어, 캐리어/운영자)를 인보이싱(invoice)하고, 공급자(예를 들어, 개발자, 발행자 등)에게 지불하도록 구성된다.

일반적으로, 거래 데이터가 생성된 후에, 빌링 이벤트가 생성되어 기존으로 방식으로 처리된다. 예를 들어, 아이템과 관련된 메타데이터는 TXN(340) 및/또는 관련된 데이터베이스에 저장될 수 있다. 클라이언트 장치(300)가 빌링 요청에 대한 승인을 수신하면, 거래 데이터가 데이터베이스로 전송되어 저장될 수 있다. 캐리어 및/또는 개발자들에 대하여 생성된 보고서들이 AVB 생성 빌링 이벤트로서 거래를 식별할 수 있도록 거래 타입이 또한 저장될 수 있다. 거래 데이터는 또한 메타데이터의 서브세트 및 다른 장치들 및/또는 시스템들에 의해 포함된 추가적인 정보를 포함할 수 있다. 빌링 이벤트들은 메타데이터 및 원시(raw) 거래 데이터를 상관시킴으로써 TXN(340)에서 생성된다. 이러한 프로세스에 대한 보다 상세한 설명은 여기에 참조로서 통합된 출원 번호가 10/222,706이고, 발명의 명칭이 "Transaction Processing"인 미국특허출원에 제시되어 있다.

클라이언트 장치에 대한 애플리케이션들을 구매 및 획득하기 위한 기존의 프로세스는 이용가능한 애플리케이션들의 카탈로그로 액세스하고, 원하는 애플리케이션을 선택하고, 자신으로 애플리케이션을 다운로드하는 클라이언트 장치를 포함한다. 이러한 프로세스는 애플리케이션 다운로드와 관련된 빌링 이벤트를 생성하며, 배경기술에서 논의된 바와 같이, 애플리케이션 다운로드는 최종적으로 가입자의 빌링 및 애플리케이션 개발자에 대한 지불이 이루어지도록 한다. 그러나, 애플리케이션들의 마케팅 및 구매와 무선 가입자 빌링 시스템의 활용은 이러한 클라이언트-서버 접속으로 제한된다.

도 4는 추가적인 서비스 값 빌링을 허용하는 본 발명의 적어도 하나의 실시 예에 따른 시스템을 나타낸다. 서비스 값 빌링(SVB) 모듈(410)은 무선 가입자 빌링 시스템(400)에 포함될 수 있다. SVB(410)는 캐리어 네트워크의 일부가 아닌 신뢰된 서비스(490)(예를 들어, 제3자 벤더, 발행자 등)로 빌링 포털을 제공한다. SVB(410)는 신뢰된 서비스(490)가 빌링 시스템(400)을 통해 이후에 처리되는 빌링 요청들을 생성하도록 허용한다. 클라이언트 장치로부터 직접 선택된 애플리케이션 및 클라이언트 장치로 다운로드된 애플리케이션에 대하여 배포하고 청구하는 기존의 시스템과 대조적으로, SVB는 넌-애플리케이션 관련 거래들이 설정된 무선 가입자 빌링 시스템(400)을 통해 처리되도록 허용한다.

SVB 모듈(410)로 액세스하는 신뢰된 서비스(490)의 신원을 확인할 수 있는 인증 특징이 SVB 모듈(410)에 포함될 수 있다. 예를 들어, 디지털 인증서가 신뢰된 서비스에 대하여 발행될 수 있다. 인증서는 검증을 위해 캐리어/운영자 및 신뢰된 서비스(예를 들어, 컨텐트 수취인)와 관련될 것이다. 신뢰된 서비스(490)는 발행된 인증서를 이용하여 디지털적으로 SVB 모듈(410)에 대한 각각의 거래를 서명할 수 있다. 디지털 서명 및 디지털 인증서는 각각의 요청에 포함될 수 있다. 그 다음에 SVB 모듈은 각각의 빌링 요청에 대한 서명을 인증한다. SVB(410)는 웹-기반 인터페이스일 수 있으며 SVB(410)로의 접속은 예컨대 신뢰된 서비스(490) 인증에서의 HTTPS 프로토콜을 이용하여 인터넷을 통해 이루어질 수 있다. 그러나, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 인터넷 접속 및 HTTPS 프로토콜에 제한되지 않으며 유선 및/또는 무선 접속의 임의의 결합과 적절한 보안/인증 시스템이 신뢰된 서비스로부터 빌링 요청들을 전달하기 위해 사용될 수 있다.

그에 따라, 무선 가입자 빌링 시스템(400)은 빌링 시스템(400)의 외부에 있는 신뢰된 서비스로부터 빌링 요청을 수신할 수 있다. 빌링 요청은 빌링 시스템(400)으로 전달되고 빌링 시스템(400)에서 상기 요청을 검증하는데 사용되는 빌링 정보를 포함할 수 있다. 또한, 빌링 시스템(400)은 빌링 요청에 대한 검증 응답을 생성하여 검증 응답을 신뢰된 서비스(490)로 전달할 수 있다. 빌링 정보는 가입자 ID, 제공자/컨텐트 수취인, 컨텐트(아이템) ID, 리스트 가격, 빌링 디스크립션 등을 포함하는 빌링 요청을 검증하기 위해 사용되는 정보를 포함할 수 있다. 그러나, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 다른 데이터가 빌링 요청에 포함될 수 있다는 것을 이해할 것이다.

예를 들어, 도 4에 도시된 구성에서, 빌링 요청은 신뢰된 서비스(490)에 의해 생성될 수 있다. 여기서 논의되는 바와 같이, SVB(410)는 신뢰된 서비스(490)로부터 빌링 요청을 수신할 수 있고 신뢰된 서비스(490)를 인증할 수 있다. 검증 로직(430)은 빌링 요청을 검증할 수 있다. 검증 로직(430)을 사용하여, 캐리어는 추가적인 프로세싱을 위해 빌링 요청을 승인할 것인지 또는 상기 요청을 거부할 것인지 여부를 결정하기 위해 빌링 무결성(integrity) 검사들을 수행할 수 있다. 캐리어는 가격 및 거래를 제어하지는 않으나 가입자에 대하여 청구하기 때문에, 검증 로직(430)은 캐리어가 어떤 빌링 요청들을 승인할 수 있는지를 결정하도록 허용하기 위한 중재 포인트로서 사용될 수 있다. 빌링 요청이 검증되면, SVB(410)는 빌링 요청에 기반한 거래 데이터를 생성하고 데이터를 거래 관리자(440)로 전달할 수 있다. 거래 관리자(440)는 SVB(410)로부터 거래 데이터를 수신하여 빌링 모듈(450) 및 지불 모듈(460)로 전달될 수 있는 빌링 이벤트를 생성할 수 있다. 빌링 모듈(450)은 거래 관리자(440)로부터 빌링 이벤트를 수신하여 가입자에 대한 청구서를 생성할 수 있다. 지불 모듈(460)은 위에서 논의된 바와 같이 거래 관리자(440)로부터 빌링 이벤트를 수신하고, 캐리어를 인보이싱하고, 컨텐트 제공자(예를 들어, 애플리케이션/컨텐트/청구되는 서비스의 소스)에게 지불할 수 있다. 이에 따라, SVB(410)는 빌링 시스템(400)의 외부로의 거래를 청구하고 지불하도록 사용될 수 있으며, 무선 가입자 빌링 시스템(400)의 사용은 애플리케이션 다운로드들 및/또는 캐리어 관련 서비스들을 청구하고 지불하는 것에 한정되지 않는다.

신뢰된 서비스로부터의 SVB-기반 빌링 이벤트들은 캐리어 네트워크 내에서 또는 가입자 클라이언트 장치로부터 직접적으로 생성되지 않기 때문에, SID 맵 데이터베이스(420)는 고유하게 가입자를 식별하기 위해 SVB에 의해 사용될 수 있다. 예를 들어, 가입자는 신뢰된 서비스(490)에서 자신들의 모바일 디렉토리(다이얼가능한) 번호(MDN) 또는 캐리어에 의해 알려진 다른 할당된 고유한 번호를 이용할 수 있다. MDN (또는 다른 고유한 번호)는 SID로서 빌링 요청과 함께 SVB(410)로 전송될 수 있다. 그 다음에 SVB(410)는 SID 맵 데이터베이스(420)로 액세스하고 빌링 요청들 및 거래들을 처리하기 위해 빌링 시스템에서 사용되는 고유한 SID로 MDN을 교체하거나 또는 고유한 SID와 MDN을 연관시킬 수 있다.

추가적으로, 구매된 아이템/청구된 아이템은 ADS 및/또는 캐리어 네트워크를 통해 배포된 애플리케이션 또는 컨텐트가 아닐 수 있다. 이에 따라, 빌링 요청은 아이템 디스크립션, 소매 가격, 구매 시간/날짜 등과 관련된 추가적인 정보를 포함할 수 있다. 그러나, 이러한 추가적인 정보의 적어도 일부는 또한 데이터베이스로 미리-로딩될 수 있으며 아이템 ID 및/또는 제공자/수취인 ID(예를 들어, 신뢰된 소스)에 기반하여 액세스될 수 있다.

빌링 요청에 포함된 정보는 거래들의 빌링 및 트래킹을 위해 사용되는 다양한 데이터를 포함할 수 있다. 예를 들어, 빌링 요청에 포함된 정보는 신뢰된 서비스에서 구매된 아이템(예를 들어, 애플리케이션, 컨텐트, 물품 및/또는 서비스)에 대한 고유한 식별자를 표현하기 위해 신뢰된 서비스에 의해 특정화될 수 있는 아이템 ID를 포함할 수 있다. 아이템 ID는 아이템에 대한 빌링 파트 번호로 고려될 수 있다. 그러나, 아이템 ID가 신뢰된 서비스들에서 고유하다는 보장은 없기 때문에, 아이템 ID는 고유성을 유지하기 위해 (신뢰된 서비스일 수 있는) 제공자/수취인 ID와 함께 참조될 수 있다. 고객 ID는 운영자의 가입자 ID(SID) 또는 운영자/캐리어의 SID와 관련될 수 있는 고유한 ID일 수 있다. 고객 ID 타입은 빌링 정보에 포함될 수 있다(예를 들어, SID, MDN). 서명은 발행된 디지털 인증서의 개인키를 사용하여 신뢰된 서비스에 의해 디지털적으로 서명된 모든 데이터의 연결된 스트링일 수 있다. 신뢰된 서비스 키 쌍으로부터의 디지털 인증서는 요청을 인증하기 위해 SVB에 대하여 사용될 수 있다. 수취인 ID는 배분된 표준 수익 할당(예를 들어, 캐리어, 지불 모듈 및 컨텐트 제공자 사이에서 분배되는 수익)의 컨텐트 부분이 지불될 제공자/컨텐트 수취인을 표시할 수 있으며, 아이템에 대한 발행자/개발자/제조자를 동일시(equate)할 수 있다. 많은 상황들에서, 수취인 ID는 신뢰된 함수이다.

구매를 위한 그리니치 표준시(GMT) 스탬프가 포함될 수 있다. 로컬 시간을 계산하기 위한 오프셋을 나타내는 GMT 오프셋이 포함될 수 있다. 클라이언트 거래 ID는 빌링/거래 요청에 대한 고유한 식별자를 나타낼 수 있다. 클라이언트 거래 ID는 이러한 거래가 이미 수신되지 않았는지 여부를 검사(이중 빌링을 방지하기 위한 중복 검사)하기 위해 사용될 수 있다. 캐리어 ID는 시스템의 서브-운영자 ID를 나타낸다(예를 들어, 캐리어 ID는 BREW® 캐리어 ID 및 주요 캐리어를 동일시할 수 있다). 선불(pre-pay) 플래그는 엔드 유저가 운영자에 대한 선불 고객인지 여부를 표시할 수 있다. 소매 가격은 컨텐트 청구 이벤트의 소비자 청구액을 나타낼 수 있다. 컨텐트 요금은 가격 조건들에 따라 컨텐트 수취인 지불을 결정하기 위해 사용되는 값을 나타낼 수 있다. 대부분의 경우들에서, 이것은 소매 가격과 동일하다. 화폐 코드(currency code)는 거래에서 특정된 리스트 가격, 컨텐트 요금 및 소스 요금의 화폐를 나타낼 수 있다. 빌링 디스크립션은 캐리어들로 전송된 보고서(예를 들어, 빌링 XML 피드(feed)) 및 개발자들에게 이용가능한 보고서(예를 들어, 개발자 XML 피드)에 포함될 수 있는 컨텐트 아이템에 대한 짧은 설명을 나타낼 수 있으며, 소비자 빌링 문서에 표시될 수 있다. 이것은 이러한 아이템에 대한 빌링 파트 이름과 동일시될 수 있다. 롱 디스크립션(Long Description)은 (예컨대, 고객 서비스를 위해) 추가적으로 거래를 설명하기 위해 사용될 수 있는 밸류 빌 컨텐트(value bill content)의 더 긴 이름을 나타낼 수 있으나, 일반적으로 빌링 추출 XML 또는 개발자 추출 XML(예를 들어, 개발자들에 대한 보고서)에 포함되지 않는다. 판매자 데이터는 빌링 거래와 함께 전달되며 신뢰된 서비스에 의해 사용되 는 추가적인 데이터를 나타낼 수 있다. 판매자 데이터는 빌링 및 개발자 보고서들에 포함될 수 있다. 시작 순환 빌링 인터페이스에 대한 정보는 가입자 빌링을 트리거링(trigger)하기 위해 (예를 들어, MM/DD/YYYY 포맷의) 날짜를 표시할 수 있는 청구 시작일(Start Bill Date)을 포함할 수 있다. 청구 시작일이 미래 시점에 있다면, 빌링을 트리거링하기 위한 제 1 값 빌링(IB) 이벤트는 청구 시작일까지 생성되지 않는다. 청구 종료일(End Bill Date)은 (예를 들어, MM/DD/YYYY 포맷의) 가입 종료 날짜를 표시할 수 있다. 청구 종료일 이후에는 IB 이벤트들이 생성되지 않는다.

빌링 요청에 포함될 수 있거나 그리고/또는 빌링 이벤트와 관련될 수 있는 선택적인 빌링 정보에 대한 이전의 서술은 설명을 위해 제시된 것이다. 빌링 요청들은 위에서 설명된 모든 정보 없이도 처리될 수 있으며, 마찬가지로 리스트되지 않은 추가적인 정보가 빌링 이벤트들을 트래킹하고 보고하기 위한 목적으로 추가될 수 있다. 이에 따라, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 빌링 이벤트를 생성하기 위한 빌링 요청 및 관련된 정보는 캐리어들 및 구매된 아이템들의 제공자들이 원하는 바에 따라 변경될 수 있다.

SVB(410)를 사용하여, 빌링 시스템(400)은 실질적으로 신뢰된 서비스(490)(즉, 빌링 생성을 위한 인가된 소스)로부터의 "패스-스루(pass-through)" 빌링 서비스로서 기능한다. 신뢰된 서비스(490)는 다음과 같은 과정들을 포함할 수 있는 서비스 값 빌링 거래 관리를 책임질 수 있다: 거래를 생성하는 과정(예를 들어, SOAP(간단한 오브젝트 액세스 프로토콜) 인터페이스), 보안을 제공하는 과정, 유효한 거래 속성들(예를 들어, 위에서 설명된 빌링 정보)을 설정하는 과정, 거래를 빌링 시스템(400)으로 전달하는 과정, 빌링 시스템(400)으로부터의 응답을 처리하는 과정 및 필요에 따라 거래를 재전달하는 과정. 신뢰된 서비스(490)는 운영자에 의해 발생된 디지털 인증서 또는 다른 보안 거래 프로세싱을 이용하여 각각의 거래에 대한 인증(예를 들어, 디지털 서명된 각각의 거래)을 SVB(410)로 제공할 수 있다. 그 다음에 SVB(410)는 신뢰된 서비스(490)로부터의 요청들을 인증하고, 요청들을 검증하고, 값 빌링 운영자 인터페이스들을 지원하고, 유효한 요청들(예를 들어, 거래 데이터)을 TXN(440)으로 전달한다. SVB(410)는 유효하지 않은 요청들을 식별하기 위해 에러 코드를 리턴할 수 있다. TXN(440)은 중복 이벤트 검사, 빌링 거래들의 변환 프로세싱, 순환 컨텐트 값 빌링의 매핑 및 프로세싱을 지원할 수 있으며, 값 빌링 이벤트들을 빌링 모듈(450) 및 지불 모듈(460)로 전달할 수 있다.

SVB(410)는 다수의 운영자 인터페이스들을 지원할 수 있다. 예를 들어, 사용자 인가 인터페이스는 SID가 SVB 서비스를 위해 인가되는지를 확인하기 위해 사용될 수 있다. 거래 검증 인터페이스(예를 들어, 검증 로직(430))는 운영자가 빌링 정보의 추가적인 검증(예를 들어, X를 초과하지 않는 컨텐트 요금, 유효한 고객 ID 등)을 구현하도록 하기 위해 사용될 수 있다. 선불 인터페이스는 선불 인가(예를 들어, 선불 잔액 검사)를 개시하고 값 빌링 서비스들에 대한 서비스들을 데빗(debit)하기 위해 사용될 수 있다. 이러한 인터페이스들은 개별적인 모듈들로서 구현될 수 있거나 또는 공통 로직 모듈(예를 들어, 검증 로직(430))에 모두 포함될 수 있다.

기존의 무선 시스템들에서의 애플리케이션 구매는 캐리어/운영자에 의해 제어되며 위에서 논의된 바와 같이 전형적으로 (예를 들어, ADS에 의해 표시되는 바와 같이) 애플리케이션들에 대하여 브라우징하고, 캐리어 네트워크로부터 애플리케이션을 선택하여 다운로딩하는 클라이언트 장치에 기반한다. 거래는 배경 기술 및 이전의 설명에서 논의된 바와 같이 기록되고, 빌링되고 지불될 수 있다.

그러나, 빌링 시스템에 SVB 서비스를 추가하는 것은 캐리어 네트워크로부터의 직접 구매 이외에도 대안적인 구매(Alt Buy) 소스들을 허용한다. 도 5와 관련하여, SID-지시(directed) (또는 클라이언트 장치 지시) 배포 구조는 원격 클라이언트 장치로의 아이템들의 지시된 전달을 허용할 수 있다. 이러한 SID-지시 구조는 캐리어 오프라인으로부터 구매된 애플리케이션들 및/또는 컨텐트가 SID와 연관되도록 허용하며, 그 결과 구매된 애플리케이션/컨텐트는 클라이언트 장치로부터 다운로드 가능하며, 기존의 다운로드 프로세스에서와 같이 다운로드 이벤트는 가입자에 대한 임의의 추가적인 빌링을 생성하지 않을 것이다.

예를 들어, 메인 카탈로그(510)는 캐리어/운영자로부터 구매 가능한 복수의 아이템들(예를 들어, 애플리케이션들, 컨텐트, 서비스들 등)을 포함할 수 있다. 오직 하나의 SID(예를 들어, 소유한 애플리케이션(My Apps) 그룹)를 포함하는 SID-지시 그룹(540)은 구체적으로 이러한 SID(클라이언트 장치)로 향하는 아이템들을 포함하도록 형성될 수 있다. 그에 따라, 쇼핑 카탈로그(550)는 기존의 방식으로(예를 들어, 메인 카탈로그(510)로부터의 폴더들/아이템들을 사용하여) 플랫폼 ID, 런타임 API 및 언어에 기반하여 메인 카탈로그(510)로부터 클라이언트 장치(300)에 대하여 생성될 수 있다. 그러나, 쇼핑 카탈로그(550)는 클라이언트 장치(300)와 관련된 SID에 기반하여 SID-지시 그룹(540) 및 쇼핑 카탈로그(550)에 있는 SID와 관련된 아이템들(예를 들어, My Apps)에 의해 증가(augment)될 수 있다. 그러므로, 쇼핑 카탈로그(550)는 각각의 SID에 대하여 맞춤화될 수 있으며, SID-지시 그룹(540)은 Alt Buy를 통해 구매된 아이템들을 전달하기 위해 사용될 수 있다.

개별적인 그룹들에 있는 아이템들을 표시하는 것 이외에, 구별된 가격이 동일한 아이템에 대하여 사용될 수 있다. 예를 들어, 메인 카탈로그(510)에 있는 아이템 5(예를 들어, 애플리케이션)는 $10. 00의 최대 상업 가격으로 제공될 수 있다. 그러나, 동일한 아이템 5는 공짜로 제공될 수 있는 SID-지시 그룹(540)(예를 들어, My Apps)에 포함될 수 있다. 예를 들어, 아이템 5는 Alt Buy를 통해 구매될 수 있거나 또는 다른 가입자로부터의 선물일 수 있다. 그에 따라, 구매/빌링/지불 프로세스는 기존의 다운로드 개시된 빌링 이벤트와 다르게 구매된 아이템의 전달과 분리될 수 있다.

무선 가입자 빌링 시스템에 대한 외부로의 빌링 채널(예를 들어, SVB(410))은 외부 구매 거래들이 무선 가입자 빌링 시스템을 통해 처리되도록 허용한다. 영화 티겟을 구매하는 것과 같은, 몇몇 구매들은 클라이언트 장치에 대한 임의의 관련된 다운로드 또는 인핸스먼트(enhancement)없이 처리될 수 있다. 그러나, 무선 시스템을 통해 클라이언트 장치로 지시되는 캐리어 카탈로그로부터 아이템들을 구매하는 과정(예를 들어, 애플리케이션의 특징들을 다운로드 또는 향상시키는 과정, 애플리케이션 구매, 링톤 구매 등)을 포함하는 다른 타입들의 외부 거래들이 처리 될 수 있다. 일반적으로 클라이언트 장치로 지시되지만 클라이언트 장치에 의한 캐리어 네트워크에서의 기존의 클라이언트 장치 대 서버 거래 내에서 발생되지 않는 이러한 타입의 거래는 다음의 설명에서 "대안적인 구매" 또는 "Alt Buy"로 지칭된다.

Alt Buy 존(610)은 소매(612)(예를 들어, 운영자/제3자 소매 카드들, 키오스크(kiosk)), PC/웹 기반(614)(예를 들어, 운영자/제3자 웹 사이트 또는 구매가 무선 클라이언트(300)를 위해 관련된 게임에 대하여 이루어질 수 있는 게임과 같은 PC 애플리케이션으로부터 직접 이루어지는 경우), 매스 미디어(616)(예를 들어, 광고 링크들 등)와 같은 다양한 채널들을 포함할 수 있다. Alt Buy는 SID와 관련된 클라이언트 장치(300)로의 컨텐트/애플리케이션 전달을 위해 빌링 및 SID 기반 그룹 함수들(예를 들어, My Apps(540))에 대하여 SVB(410)를 레버리징할 수 있다.

예를 들어, 소매 카드들은 하나 이상의 애플리케이션들을 가입자에게 제공하는 운영자 또는 제3자의 소매 아웃렛에서 판매되는 카드일 수 있다. 구매자는 자신의 카드를 사용할 수 있거나 또는 다른 가입자에게 카드를 선물로 줄 수 있다. 하나의 카드를 통한 다수의 애플리케이션들의 구매는 애플리케이션들의 구매 가격에 대한 할인을 포함할 수 있다. 선물의 구매 또는 수신 후에, 가입자는 카드를 등록할 수 있으며, 이러한 시점에서 애플리케이션들(예를 들어, BREW® 애플리케이션들)은 다운로드 또는 자동-설치를 위해 자신들의 SID-지시 그룹(예를 들어, 소유 애플리케이션 디렉토리)으로 로딩된다. 또한, 거래 프로세싱은 (선불이 아니면 선택적으로) 가입자에게 청구하도록 완료되며, 모든 애플리케이션들 및 서비스 제공 자들에게 지불하게 된다.

카탈로그 매물(offering)들을 모방하며 가능하면 다수의 애플리케이션들의 구매에 대하여 또는 제한된 매물 제공 시간 동안 특정한 매물들의 구매에 대하여 일정한 할인 가격을 적용하는 운영자/제3자 웹 매물들이 표시될 수 있다. 웹사이트 Alt Buy들은 개별적으로 애플리케이션들 및 컨텐트를 제공할 수 있거나, 또는 물품 및 서비스 아이템들의 번들들을 제공할 수 있다. 예를 들어, 가입자 (또는 선물 수여자)는 목적지 가입자의 장치(예를 들어, MDN)와 관련하여 정보를 제공할 수 있으며, 운영자/제3자(예를 들어, 신뢰된 서비스)는 SVB(410) 인터페이스를 통해 가입자 빌링 및 컨텐트 제공자 지불을 위한 정보를 제공한다.

운영자 또는 제3자 키오스크들은 메인 카탈로그 매물들을 모방하고 가능하면 다수의 애플리케이션들의 구매에 대하여 또는 제한된 매물 제공 시간 동안 특정한 매물들의 구매에 대하여 일정한 할인 가격을 적용하는 애플리케이션 구매 능력을 가질 수 있다. 가입자는 목적지 가입자 장치(예를 들어, 클라이언트 장치(300))에 대한 정보를 제공하고, 운영자 또는 제3자는 상기 장치로 구매된 애플리케이션들의 (예를 들어, My Apps를 통해) 배포를 지시하고 가입자 빌링 및 컨텐트 및 서비스 제공자 지불들을 위한 정보를 제공한다.

광고 링크들은 운영자의 가입자들에게 애플리케이션들을 제공할 수 있다. 예를 들어, 이것들은 가입자에 대하여 빌링가능하지 않을(non-billable) 수 있다. 가입자는 목적지 가입자의 장치를 통해 정보를 제공하고 운영자 또는 제3자는 사용자 다운로드를 위해 (예를 들어, My Apps를 통해) 상기 장치에 대한 애플리케이션 들의 배포를 지시한다.

이전에 논의된 바와 같이, Alt Buy는 애플리케이션들/컨텐트를 구매하여 가입자들에게 전달하기 위한 다수의 상이한 채널들을 제공한다. 이러한 구성들 각각에서, 빌링 및 전달 정보는 적절한 전달 및 빌링을 허용하기 위해 SVB(410) 및 그룹 관리자(515)로 전달된다. 그에 따라, 빌링 및 전달 메터데이터는 SVB(410)로 전송되는 빌링 요청의 일부로서 전송될 수 있다.

예를 들어, 애플리케이션은 캐리어 네트워크/빌링 시스템의 외부(예를 들어, 현금, 운영자 키오스크에서의 신용 카드)에서 구매될 수 있다. 빌링 및 배포 요청은 신뢰된 서비스(예를 들어, Alt Buy 존(610))에서 SVB(410)로 전달된다. 거래가 대안적인 거래이며 특별한 가격 베이스(예를 들어, 가입자가 빌링되지 않도록 CLP=0)를 가진다는 것을 표시하는 특별한 가격 처리가 빌링 요청과 함께 포함될 수 있다. SID는 전달을 타게팅하기 위해 사용된다(예를 들어, My Apps). 일반적으로, Alt Buy 서비스는 빌링 및 배포 요청들을 포맷팅하여 제출하고, 리턴 이벤트 정보를 처리하며, 에러 인스턴스들을 처리한다. 빌링/배포 요청은 SVB 거래일 수 있으며, 배포 요청은 그룹 매니저 지시 (SID-지시) 애플리케이션 요청일 수 있다. 상기 요청과 함께 포함된 메타데이터 (정보)는 예컨대 Alt Buy와 관련된 각각의 애플리케이션에 대한 배포 SID, 아이템 ID, 가격 처리, 가격 방법, 가격 기준, 가격 밸류, 판매자 데이터 및 소스 타입을 포함한다.

Alt Buy 전달 테이블(620)은 Alt Buy 소스(예를 들어, 610)로부터 전달된 메타데이터로부터의 데이터와 함께 유지될 수 있다. 예를 들어, 상기 테이블은 SID(예를 들어, 배포 SID), 아이템 ID, 용업(Usage), 가격 처리, CLP 필드들을 포함할 수 있다. 위에서 설명된 시나리오에서, 애플리케이션이 Alt Buy 존(610)에서 지불되었고 CLP=0인 경우에, 이러한 정보는 SID 및 아이템 ID와 관련될 수 있으며 SID-지시 그룹(540)(예를 들어, My Apps)과 관련될 수 있다. SID와 관련된 클라이언트 장치(300)가 ADS(106)에 의해 생성된 쇼핑 카탈로그(550)로부터 SID-지시("My Apps") 그룹으로 액세스하면, 표시된 아이템들(예를 들어, 애플리케이션) 중 하나는 Alt Buy를 통해 구매되었던 아이템일 수 있다.

ADS(106)는 Alt Buy 테이블(620)로 액세스할 수 있으며 SID 및 아이템 ID와 관련된 Alt Buy 가격 처리가 존재하는지 여부를 결정할 수 있다. 그 다음에 ADS는 아이템 ID와 관련된 제공된 가격 처리를 Alt Buy 테이블(620)로부터의 로컬 가격 처리로 교체할 수 있다. 가격이 제로(0)라고 가정하면, $0. 00 또는 "무료"라는 표시 (또는 다른 언어별로 특정된 표시)가 클라이언트 장치(300)에서 디스플레이될 수 있다. 로컬 가격 처리가 존재하면, ADS(106)는 운영자 및 개발자 최소한도(minimum)들이 적용되지 않도록 보장하기 위해 Alt Buy 거래로서 거래를 식별할 수 있으며, 소비자 빌링이 적용되지 않고, 개발자/컨텐트 제공자 지불이 처리되지 않거나 제로값으로 처리된다. 위에서 논의된 바와 같이, ADS(106)는 다운로드 요청을 처리하고, 제로값에서 거래 데이터를 생성하고, 거래 데이터를 거래 프로세싱, 빌링 및 지불 모듈들로 전달할 수 있다. 그러나, 빌링 및 지불이 SVB를 통해 Alt Buy 존에서 수행되었기 때문에, 빌링 및 지불 모두는 0이 될 것이다(CLP=0, DAP=0, 여기서 DAP는 개발자/컨텐트 제공자에 대한 지불임). 그러나, 거래와 관련 된 다른 정보는 운영자 및/또는 개발자 보고서들을 가질 수 있도록 이러한 다운로드 이벤트를 통해 유지될 수 있다. 예를 들어, 이러한 정보는 실제 다운로드된 애플리케이션들, 다운로드 날짜들 등의 트래킹에 유용할 수 있으며, 마케팅 및 고객 서비스를 위해 SID 및 클라이언트 장치와 관련될 수 있다.

다른 예시적인 실시예에서, Alt Buy 구매는 특별한 가격(예를 들어, 낮은 가격 또는 무료 프로모션)으로 한 번 또는 제한된 횟수의 다운로드들 동안 운영자 키오스크에서 이루어질 수 있다. 위에서 논의된 바와 같이, Alt Buy 전달 테이블(620)은 SID와 관련된 클라이언트 장치가 특별한 가격(예를 들어, CLP=0)으로 애플리케이션을 다운로드하도록 허용하기 위해 처음에 설정될 수 있다. 특별한 가격 처리 및 가격 레벨은 이전에 논의된 바와 같이 빌링 시스템을 통해 전달된다. 그러나, Alt Buy 전달 테이블(620)에 가격, 아이템 ID 및 다른 데이터 이외에도, 다운로드 표시자가 저장될 수 있다. 그에 따라, 아이템이 (예를 들어, ADS(106)를 통해) 다운로드되면, 아이템 ID 라이센싱이 SID로 전달되고 이러한 라이센스의 상태는 전달된 상태로 설정된다. 아이템 ID에 대하여 이용가능한 각각의 다운로드 가능한 라이센스에 대한 기록이 유지된다. 아이템 ID 라이센싱이 SID로 전달될 때, 이러한 라이센스의 상태는 전달된 상태로 설정된다. 그에 따라, 다운로드 표시자/전달 상태는 아이템이 전달되었고 Alt Buy 전달 테이블(620)로부터 제거(또는 기능적으로 다운로드 표시자 필드에 대한 로직 검사를 통해 제거)될 수 있다는 것을 표시한다. 마찬가지로, 아이템은 SID-지시(My Apps) 그룹(540)에서 보이지 않을 수 있다. 그에 따라, 아이템이 다시 다운로드된 경우에, 아이템은 메인 카탈로 그(510)에서 정의된 표준 가격 레벨로 제공될 수 있다. 그러므로, 표준 상업 아이템 가격은 애플리케이션들, 컨텐트 및/또는 서비스들을 프로모션하고 마케팅하는데 추가적인 유연성을 허용하기 위해 무선 빌링 시스템에서 Alt Buy 가격과 혼합될 수 있다.

Alt Buy 시나리오에서, 빌링 및 배포 정보는 Alt Buy 존(610)(예를 들어, 운영자 키오스크)에서 생성될 수 있다. 빌링 및 배포 정보는 SVB(410) 및 그룹 관리자(515)로 전달된다. 상기 정보(메타데이터)의 적어도 일부는 시스템이 거래들을 하나의 Alt Buy 거래 ID와 연관시키도록 허용하기 위해 빌링 및 다운로드 거래들을 통해 전달되고 저장될 수 있다. 예를 들어, 거래 메타데이터는 SVB 거래를 통해 생성되어 전달될 수 있다. 이러한 메타데이터는 예컨대 그룹 관리자(515), ADS(106) 또는 다른 서버 또는 로직을 이용하여 SID-지시 그룹(540)에 추가된 아이템 ID와 연관되어 저장될 수 있다. 메타데이터는 다운로드 요청을 통해 클라이언트 장치로 전달될 수 있다. 또한, 메타데이터는 거래 관리자 TXN에 의해 조정된(mediated) 사용 기록에 포함될 수 있다.

Alt Buy 거래는 TXN에서 다수의 거래 데이터(예를 들어, SVB 빌링 요청과 관련된 제 1 거래 데이터 및 클라이언트 장치로의 컨텐트의 실제 전달(예를 들어, 푸시(push)/풀(pull))과 관련된 제 2 거래 데이터)를 생성할 수 있다. 그에 따라, 트래킹 ID가 거래 프로세싱을 통해 사용될 수 있으며, 그 결과 관련된 거래들의 엔드-투-엔드 트래킹이 달성될 수 있다. 그리하여, 트래킹 ID는 Alt Buy 요청과 함께 포함될 수 있으며 제 1 거래 데이터는 빌링 요청에 기반하여 생성될 수 있다. 거래 데이터는 가입자 청구서를 생성하고, 아이템의 제공자에 대한 지불을 배분하고, 그리고/또는 제 1 거래 데이터에 기반한 보고 데이터를 전송하기 위해 빌링 시스템(예를 들어, TXN, 빌링 및 지불 모듈들)을 통해 처리될 수 있다. 트래킹 ID를 포함하는 제 1 거래 데이터는 나중의 검색, 조정들, 고객 서비스 등을 위해 데이터베이스에 저장될 수 있다.

위에서 논의된 바와 같이, Alt Buy 거래에서 컨텐트의 전달은 빌링 요청과 개별적으로 발생할 수 있거나 (예를 들어, 컨텐트가 전달되지 않는다면) 발생하지 않을 수 있다. 그에 따라, 컨텐트가 전달될 것이라면, 컨텐트는 메인 카탈로그로부터 클라이언트 장치와 관련된 SID-지시 그룹으로 추가될 수 있다. 트래킹 ID는 또한 SID-지시 그룹에 있는 컨텐트와 관련될 수 있다. SID-지시 그룹으로부터의 컨텐트가 클라이언트 장치로 다운로드되면, 트래킹 ID는 또한 클라이언트 장치로 전달될 수 있다. 마찬가지로, 이전에 논의된 바와 같이, 제 2 거래 데이터는 트래킹 ID를 포함하는 컨텐트의 다운로드를 통해 생성될 수 있으며 남아있는 빌링, 지불 및/또는 보고 프로세스를 통해 처리될 수 있다. 트래킹 ID를 포함하는 제 2 거래 데이터는 또한 나중의 검색, 조절들, 고객 서비스 등을 위해 저장될 수 있다. 이에 따라, Alt Buy 거래는 엔드-투-엔드로(즉, Alt Buy 판매로부터 애플리케이션 다운로드 및 거래 빌링 및 지불로) 매핑되어 관리될 수 있다. 이러한 거래들을 엔드-투-엔드로 트래킹할 수 있도록 하는 것은 Alt Buy 판매 채널들에 대한 증가된 비지니스 정보 및 애플리케이션 배포를 허용한다. 예를 들어, 트래킹 ID의 사용을 통해, 캐리어는 얼마나 많은 Alt Buy 다운로드들이 구매된 애플리케이션들/컨텐트 에 대하여 실행되었는지를 알 수 있다. 이것은 Alt Buy 관련 다운로드들에 대한 TXN 조정/변환 프로세스를 통해 달성된다. TXN은 조정된 사용 기록 내에 트래킹 ID의 변환을 포함시키기 위해 로컬 가격 처리를 이용할 수 있다. 트래킹 ID는 다운로드 이벤트들과 SVB 빌링 이벤트들을 상관시키기 위해 사용된다. 트래킹 ID가 조정된 사용 기록 내에 포함되기 때문에, 트래킹 ID는 또한 캐리어 빌링 및 데이터 웨어하우징(warehousing) 솔루션들로 통합될 수 있는 빌링 보고서에 포함될 수 있다.

본 발명의 다른 실시예에서, 도 7에 도시된 바와 같이, 거래는 다수의 개발자들/발행자들/판매자들/소스들(752, 754, 756)을 포함할 수 있다. 예를 들어, Alt Buy 시나리오에서, 애플리케이션들은 공통 거래(예를 들어, 소매 게임 팩)로 번들되어 판매될 수 있다. 이전의 설명으로부터 이해되는 바와 같이, SVB는 빌링 거래들을 위해 사용되며 그룹 배포는 빌링된 컨텐트를 배포하기 위해 사용된다. 그에 따라, SVB(410)는 다수의 제3자 소스 수취인들(754, 756)에 기반하여 지불들을 특정하기 위해 구성될 수 있으며, 상기 소스 수취인들은 소스 디스크립션 및 각각의 소스 수취인(754, 756)과 관련된 소스 요금을 가지는 소스 컨텐트 제공자들일 수 있다. 개발자 및/또는 컨텐트 수취인(752)에 더하여, 소스 수취인(들)(754, 756)도 지불받을 수 있다. 다시 말하면, 컨텐트 수취인(752)은 (컨텐트 요금의 100%일 수 있는) 배분된 수익 할당 중 컨텐트 부분에 대하여 지불받을 수 있다. 소스 수취인(들) 지불은 컨텐트 요금으로부터 처리된다(즉, 일반적으로 소스 요금들은 컨텐트 요금에 추가되는 것이 아니다). 또한, 소스 수취인(754, 756)은 개발 자, 발행자 또는 다른 컨텐트 제공자일 수 있다. 예를 들어, 애플리케이션 번들 관계에서, 소스 수취인들(754, 756)은 번들에 포함된 애플리케이션들을 개발한 개별적인 개발자들일 수 있다. 컨텐트 요금은 각각의 개발자와 협상된 요금들에 컨텐트 수취인(752)(예를 들어, 번들러/배포자)에 대한 추가적인 요금들을 합한 것일 수 있다. 멀티-파티(multi-party) 지불(예를 들어, 지불 배분)은 소스 수취인 익스텐션 지불 이벤트들로서 구현될 수 있다. SVB(410)는 알려진 컨텐트 수취인(752) 및 임의의 인가된 멀티-파티 소스 수취인들(754, 756)에 대한 지불들을 지원할 수 있다.

그에 따라, 멀티-파티 지불들에 대하여, 추가적인 소스 수취인(754, 756) 정보는 빌링 시스템에서 생성되거나 또는 Alt Buy 소스에 의해 생성된 빌링 요청들에 포함될 수 있다. 예를 들어, 적어도 하나의 소스 수취인 ID가 포함될 수 있다. 소스 수취인 ID는 컨텐트의 적어도 일부를 제공한 제3자 수취인(소스 수취인)을 나타낼 수 있다. 제3자 수취인은 컨텐트 수취인(752) 지불의 일정 부분을 지불받는다. 소스 수취인(754, 756)에 의해 제공되는 컨텐트의 짧은 디스크립션을 나타내는 소스 디스크립션이 포함될 수 있다. 소스 요금은 컨텐트 수취인 지불의 제3자 수취인 부분을 나타내는 각각의 소스 수취인 ID에 대하여 제공될 수 있다. 이러한 추가적인 정보는 거래와 함께 전달되는 빌링 메타데이터와 함께 포함될 수 있다. 그러므로, 무선 가입자 빌링 시스템은 또한 다수의 제3자 컨텐트 제공자들/소스들을 포함하는 하나의 거래를 자동적으로 빌링하고 지불하기 위해 레버리징될 수 있다.

예를 들어, 무선 가입자 빌링 시스템에서 멀티-파티 빌링 이벤트들을 처리하는데 있어서, 컨텐트 수취인(752), 컨텐트 요금, 적어도 하나의 소스 수취인(754, 756) 및 거래와 관련된 소스 요금을 포함하는 빌링 이벤트가 (예를 들어, 신뢰된 서비스(490)로부터의 요청에 기반하여) 생성된다. 거래는 컨텐트 수취인(752) 및 적어도 하나의 소스 수취인(754, 756)에 대한 지불을 (예를 들어, 지불 모듈(460)을 통해) 배분하기 위해 처리된다. 컨텐트 수취인(752) 및 적어도 하나의 소스 수취인(754, 756)의 지불과 관련된 거래 데이터는 나중의 프로세싱(예를 들어, 고객 서비스, 빌링 조정들, 판매/마케팅 데이터 마이닝(mining) 등)을 위해 (예를 들어, TXN(440) 또는 빌링 시스템과 연결되어 동작하는 다른 데이터베이스에) 저장된다. 위에서 논의된 바와 같이, 컨텐트 요금은 소스 요금들의 합보다 크거나 같다. 또한, 거래 데이터를 저장하는 것 이외에 상기 데이터의 적어도 일부는 (지불 모듈(460)에 의해) 거래 보고 데이터로서 컨텐트 수취인(752) 및/또는 각각의 소스 수취인(754, 756)으로 전송될 수 있다. 예를 들어, 개발자는 빌링 및 배포 시스템으로부터 전송된 거래 보고 데이터를 이용하여 번들링과 관련된 애플리케이션 판매들을 트래킹하기를 원할 수 있다. 또한, 위에서 논의된 바와 같이, 빌링 이벤트는 일반적으로 전달되는 또는 전달되도록 스케줄링된 컨텐트에 대한 소매 가격(예를 들어, CLP)에 기반하여 (예를 들어, 빌링 모듈(450)을 통해) 가입자 청구서를 생성하게 할 것이다. 소매 가격은 일반적으로 컨텐트 요금보다 더 크거나 동일하다.

거래 데이터가 저장되면, 거래 데이터는 위에서 논의된 바와 같이 다양한 목적들을 위해 사용될 수 있다. 이러한 사용 중 하나는 고객 관계 관리(CRM) 서비스 들에서 사용하는 것이다. 도 7에 도시된 바와 같이, 운영자(710)는 빌링 모듈(450) 및 지불 모듈(460)로부터 빌링 정보(예를 들어, 컨텐트 및 컨텐트 요금 중 소스 수취인들 754, 756에 대한 인보이스)를 수신한다. 그에 따라, 운영자(710)는 CRM 목적들을 위해 사용가능한 이러한 정보를 가질 것이다. 가입자는 운영자의 소매 아웃렛을 통해 구매된 애플리케이션 번들에 대하여 만족하지 않는다고 가정한다. 이러한 타입의 거래(애플리케이션 번들의 구매)는 전형적으로 번들에 포함된 애플리케이션들에 대한 다수의 개발자들을 포함하기 때문에, 멀티-파티 지불이 번들 구매 거래의 지불을 위해 이용될 것이다. 이제, CRM 호출 센터 또는 관리(720)가 지불되는 가격을 구매 가격의 20 퍼센트만큼 조정해야 함을 결정한다고 가정한다. 빌링 시스템에 대한 CRM 인터페이스(730)는 저장된 거래 데이터에 액세스하고, 저장된 거래 데이터에 기반하여 네거티브(negative) 컨텐트 요금 및 적어도 하나의 네거티브 소스 요금을 포함하는 조정 거래를 생성할 수 있다. 부분적인 조정들에 대하여, 시스템은 비례적으로 모든 멀티-파티 지불 소스 수취인들을 조정할 것이다.

그에 따라, SID, 거래 트래킹 ID 등을 이용하여, 번들 구매와 관련된 거래 데이터가 액세스될 수 있다. 네거티브 컨텐트 요금 및 적어도 하나의 네거티브 소스 요금은 조정 백분율 및 컨텐트 수취인(752) 및 적어도 하나의 소스 수취인(754, 756)의 지불과 관련된 저장된 거래 데이터에 기반하여 결정될 수 있다. 예를 들어, CRM 인터페이스(730)는 CRM(720)으로부터 조정량 또는 백분율(예를 들어, -20%)을 수신할 수 있다. CRM 인터페이스(730)는 원래의 거래 데이터에 액세스할 수 있고, 그 다음에 컨텐트 수취인(752) 및 각각의 소스 수취인(754, 756)에 대한 네거티브 지불(예를 들어, 컨텐트 요금 및 소스 요금의 20%)을 생성할 수 있다. 조정 백분율은 제한이 없으나, 예컨대 1에서 100 퍼센트(즉, 완전한 환불)의 범위에 있을 수 있다. 또한, 가입자 크레딧이 또한 조정 백분율 및 컨텐트에 대한 리스트 가격에 기반하여 생성될 수 있다. 그에 따라, 가입자에 대한 20 퍼센트 환불은 원래의 구매에서의 각각의 수취인(예를 들어, 캐리어/운영자(710), 컨텐트 수취인(752), 소스 수취인(들)(754, 756))이 비례적으로 20 퍼센트 데빗을 수신하도록 초래할 수 있다. 이것은 네거티브 빌링 이벤트를 생성하는 CRM 인터페이스(730)에 의해 달성될 수 있으며, 네거티브 빌링 이벤트는 빌링 시스템을 통해 전달되어 이전의 설명에서 논의된 빌링 이벤트들과 유사한 방식으로 지불될 것이다. 그리하여, 멀티-파티 지불 시스템의 CRM 인터페이스(730)는 무선 가입자 빌링 시스템을 통해 지불된 임의의 다수의 제3자 거래들에 대한 자동적인 조정을 허용한다. 다시 한번, 조정 거래 데이터는 운영자(710), 컨텐트 수취인(752) 및/또는 소스 수취인(들)(754, 756)에 대한 보고 데이터를 생성하기 위해 저장되고 그리고/또는 사용될 수 있다.

이전의 예들 및 관련된 도 7이 SVB 구매와 관련하여 멀티-파티 지불 및 CRM 서비스를 논의함에도 불구하고, 본 발명의 실시예들은 이러한 구성에 한정되지 않는다. 애플리케이션, 컨텐트 및/또는 서비스를 제공하는 다수의 당사자들을 포함하는 임의의 거래(예를 들어, 클라이언트 장치로부터의 애플리케이션 다운로드)는 이전 섹션에서 설명된 멀티-파티 지불 시스템을 사용하여 지불될 수 있다. 마찬가 지로, CRM(720)을 통해 이루어진 임의의 조정들은 빌링 이벤트의 출처에 관계없이 임의의 빌링 이벤트에 적용할 수 있다.

이전의 설명을 볼 때, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명의 실시예들이 이전에 논의된 동작들, 작업들 및/또는 기능들의 시퀀스를 수행하는 방법들을 포함한다는 것을 이해할 것이다. 예를 들어, 도 8과 관련하여, 본 발명의 일 실시예에 따른 방법이 설명된다. 빌링 요청은 신뢰된 서비스(예를 들어, 소매점, 웹사이트 등)에서 생성될 수 있다(블록 810). 빌링 정보를 포함하는 빌링 요청은 무선 가입자 빌링 시스템으로 전달된다(블록 820). 위에서 논의된 바와 같이, 통신은 원격의 신뢰된 서비스에 대한 임의의 수단의 유선 및/또는 무선 통신(예를 들어, 인터넷, LAN, WAN, 무선 접속 등)일 수 있다. 빌링 요청에 대한 검증 응답이 무선 가입자 빌링 시스템에서 생성되며(블록 830), 검증 응답은 신뢰된 서비스로 전달된다(블록 840). 신뢰된 서비스는 부정한 빌링 이벤트들이 처리되지 않도록 보장하기 위해 빌링 요청을 처리하기 전에 인증될 수 있다(블록 825). 위에서 논의된 바와 같이, 빌링 요청은 신뢰된 서비스로부터의 빌링 요청의 전송에 대한 인증의 일부로서 빌링 요청을 전송하기 전에 신뢰된 서비스에서 디지털 서명될 수 있다.

추가적으로, 이전에 논의된 바와 같이, 빌링 요청에 있는 빌링 정보는 가입자 ID, 제공자 ID/컨텐트 수취인, 컨텐트/아이템 ID, 소매 가격 및/또는 빌링 디스크립션과 같은 거래를 처리하고 트래킹하기 위한 다양한 정보를 포함할 수 있다. 그러나, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 이해되는 바와 같이, 이러한 필드들 모두가 요구되는 것은 아니며 이것이 사용될 가능한 필드들의 완전한 리스트는 아니다. 예를 들어, 선물 타입 시나리오에서는 가입자 ID에 대한 청구와 가입자 ID에 대한 전달이 빌링 요청에서 정의될 수 있다. 대안적으로, 가입자 ID는 거래 타입에 따라서 ID에 대한 청구 또는 전달만을 표현할 수도 있다. 예를 들어, SVB는 무선 가입자 시스템 외부에서 아이템들/서비스들을 구매하기 위해 사용될 수 있으나, 무선 가입자에게 청구하고 거래를 지불하기 위해 무선 가입자 빌링 시스템을 사용할 수 있다. 대안적으로, 위에서 논의된 Alt Buy 예들에서, 무선 가입자 시스템에서 사용가능한 아이템(예를 들어, 애플리케이션, 컨텐트, 서비스 등)은 무선 가입자 시스템의 외부에서 구매될 수 있으며 SID는 장치/가입자에 대한 전달을 식별하기 위한 목적으로 사용될 수 있다(예를 들어, 애플리케이션은 제로 가격 레벨에서 다운로드 가능할 것이다). 그에 따라, 빌링 요청에 포함되거나 또는 이후에 빌링 이벤트와 관련되는 정보는 거래 타입, 거래에 포함된 당사자들(예를 들어, 운영자, 제공자(들), 신뢰된 서비스 등)의 특정한 우선순위들과 같은 많은 인자들에 기반하여 변경될 수 있다.

다시 도 8과 관련하여, 검증 응답이 수신된 후에, 검증 응답은 신뢰된 서비스에서 처리될 수 있다(블록 850). 검증 응답의 프로세싱은 또한 거래 타입에 따라 변할 수 있다. 예를 들어, 무선 시스템의 외부에서의 구매에 대하여 무선 가입자에게 청구하기 위해 무선 가입자 빌링 시스템을 사용하는 SVB 거래에서, 상기 응답은 전형적으로 승인 또는 거부일 것이며, 구매된 아이템(예를 들어, 서비스, 물품 등)은 승인이 수신되지 않는다면 제공되지 않을 것이다. 그러나, Alt Buy 시나 리오에서, 아이템이 무선 가입자 시스템의 외부에서 구매되고 아이템은 전형적으로 오직 무선 가입자 시스템을 통해서 전달되기 때문에, 검증 응답은 단지 요청이 수신된 것에 대한 승인일 수 있다. 다른 시나리오에서, 검증 응답이 수신되지 않고 빌링 요청에 있는 트래킹 ID를 연관시킴으로써 개별적인 거래들로부터 구별될 수 있다면 추가적인 요청들이 생성될 수 있으며, 그 결과 중복 거래들이 용이하게 식별될 수 있다.

도 9와 관련하여, 빌링 요청이 Alt Buy 시나리오에서 승인된 후에, 예를 들어, 무선 캐리어로부터(예를 들어, 메인/상업 카탈로그에서) 사용가능한 구매된 아이템(예를 들어, 애플리케이션)은 빌링 요청에 있는 SID와 관련된 장치/가입자로 전달될 수 있다. 예를 들어, 도 9와 관련하여, 빌링 요청과 관련된 아이템은 메인 카탈로그로부터 빌링 요청과 관련된 가입자 ID로 지시된 그룹(SID-지시 그룹)으로 추가될 수 있다(블록 910). 아이템의 전달을 트래킹하기 위해, 전달 테이블에 있는 정보는 SID-지시 그룹에 있는 아이템과 연관될 수 있다(블록 920). 그 다음에 아이템은 전달될 수 있다(블록 930). 예를 들어, 아이템은 SID-지시 그룹으로부터의 SID와 관련된 클라이언트 장치로부터 다운로드 가능하거나 또는 상기 클라이언트 장치로 푸시될 수 있다. 그러나, 아이템의 전달은 추가적인 서비스의 액티베이션, 미디어 스트리밍과 같은 많은 형태들을 취할 수 있으며, 클라이언트 장치에 대한 다운로드에 한정되지 않는다.

거래 데이터는 전달 테이블에 있는 정보를 이용하여 아이템의 다운로드에 응답하여 생성될 수 있으며(블록 940), 빌링 이벤트가 거래 데이터에 기반하여 생성 될 수 있다(블록 950). 아이템이 Alt Buy 시나리오에서 지불되었다면, 전달 테이블에 있는 정보는 아이템에 대한 제로값 소매 가격을 포함할 수 있으며, 마찬가지로 거래 데이터 및 빌링 이벤트 각각은 아이템에 대한 제로값 소매 가격을 포함할 수 있다. 그에 따라, 아이템은 전달될 수 있으며 가입자에 대한 청구서를 생성하지 않고 빌링 시스템을 통해 전달이 트래킹되고 보고된다. 대안적으로, 상기 값은 0보다 클 수 있으나 메인 카탈로그에 있는 최고 소매 가격보다는 적을 수 있으며, 할인된 가격은 빌링 시스템을 통해 처리될 수 있으며, 가입자에 대하여 할인된 금액으로 청구된다.

도 10과 관련하여, 위에서 언급된 바와 같이, 대안적인 실시예는 빌링 요청과 함께 트래킹 ID를 포함할 수 있다(블록 1010). 트래킹 ID를 포함하는 제 1 거래 데이터는 빌링 요청에 기반하여 생성될 수 있으며, 제 1 거래 데이터가 처리(예를 들어, 가입자에 대한 청구, 제공자에 대한 지불 및/또는 생성된 보고서들)될 수 있다(블록 1020). 트래킹 ID는 나중의 검색 및 다른 거래들과 함께 사용하기 위해 거래 데이터와 함께 저장될 수 있다(블록 1030). 빌링 요청의 대상이 되는 아이템은 메인 카탈로그로부터 SID/클라이언트 장치와 관련된 가입자 ID 지시(SID-지시) 그룹으로 추가될 수 있으며, 트래킹 ID는 SID-지시 그룹에 있는 아이템과 연관될 수 있다(블록 1040). 아이템 및 연관된 트래킹 ID는 SID-지시 그룹으로부터 전달될 수 있다(블록 1050). 예를 들어, 아이템과 트래킹 ID를 포함하는 메타데이터는 클라이언트 장치로 다운로드될 수 있다. 트래킹 ID를 포함하는 제 2 거래 데이터는 아이템의 전달에 응답하여 생성되고 처리될 수 있다(블록 1060). 제 2 거래 데 이터는 제 1 거래 데이터와 유사한 방식으로 빌링 시스템을 통해 처리될 수 있으며, 트래킹 ID는 거래들 모두를 연관시키기 위해 사용될 수 있다.

그에 따라, SVB에서 생성된 빌링 이벤트에 기반하여 트래킹 ID를 포함하는 제 1 거래는 Alt Buy 시나리오에서 애플리케이션의 외부 구매와 같은 거래에 대한 빌링 및 지불을 야기할 수 있다. 거래 및 트래킹 ID 메타데이터는 빌링 시스템에 저장될 수 있다. 애플리케이션이 실제적으로 클라이언트 장치로 다운로드되면, 트래킹 ID는 클라이언트 장치로 전달될 수 있으며, 제 2 거래가 다운로드에 기반하여 생성될 수 있다. 제 2 거래는 위에서 논의된 바와 같이 가입자가 다운로드에 대하여 청구되지 않도록 전달 테이블로부터의 특별한 가격 처리를 포함할 수 있다. 그러나, 이러한 이벤트는 빌링 시스템을 통해 처리될 수 있기 때문에, 아이템의 전달은 트래킹되어 캐리어 및 아이템(예를 들어, 애플리케이션)의 제공자(들)로 보고될 수 있다. 다시 한번, 트래킹 ID는 제 2 거래 데이터와 함께 포함될 수 있으며, 나중의 검색, 보고 등을 위해 빌링 시스템에 저장될 수 있다. 그에 따라, 무선 가입자 빌링 시스템의 외부에서 생성된 구매/빌링 요청들은 빌링 요청으로부터 아이템의 지불 및 전달을 통해 엔드-투-엔드로 트래킹될 수 있다.

도 11에 도시된 바와 같은 또다른 실시예는 무선 가입자 빌링 시스템에서 멀티-파티 빌링 이벤트들을 처리하는 방법을 포함할 수 있다. 제공자 요금 및 수취인과 거래와 관련된 적어도 하나의 소스 요금 및 수취인을 포함하는 빌링 이벤트가 생성된다(블록 1110). 예를 들어, 발행자는 무선 가입자에 의한 다운로드를 위한 애플리케이션들 및 컨텐트(예를 들어, 음악, 비디오 등)의 결합을 포함하는 아이템 을 제공할 수 있다. 위에서 논의된 바와 같이, 아이템이 클라이언트 장치로 다운로드 가능할 때 빌링 이벤트가 생성될 수 있다. 아이템과 관련된 메타데이터는 무선 가입자 빌링 시스템을 통해 거래를 처리하기 위한 정보를 포함할 수 있다. 구체적으로, 상기 정보는 제공자 수취인(예를 들어, 발행자 ID 및 관련된 정보) 및 요금(예를 들어, 발행자에게 지불되는 금액)을 포함할 수 있다. 마찬가지로, 각각의 소스 수취인(예를 들어, 개발자 ID, 컨텐트 제공자 ID) 및 각각의 소스에 대한 요금(예를 들어, 개발자가 애플리케이션에 대하여 지불받는 금액 및 컨텐트 제공자가 컨텐트에 대하여 지불받는 금액)에 대한 정보는 또한 아이템과 관련될 수 있다. 그에 따라, 멀티-파티 거래가 빌링 시스템에 의해 자동적으로 빌링되고 지불될 수 있다. 예를 들어, 거래는 제공자 수취인 및 각각의 소스 수취인에 대하여 지불을 배분하도록 처리된다(블록 1120).

거래 데이터는 추가적인 프로세싱, 데이터 마이닝 및 CRM 서비스들을 위해 저장될 수 있다(블록 1130). CRM 조정 목적을 위해, 저장된 거래 데이터는 액세스될 수 있다(블록 1140). 저장된 거래 데이터에 기반하여 네거티브 제공자 요금 및 적어도 하나의 네거티브 소스 요금을 포함하는 조정 거래가 생성될 수 있다(블록 1150). 조정 거래는 네거티브 제공자 요금 및 적어도 하나의 네거티브 소스 요금에 기반하여 제공자 수취인 및 적어도 하나의 소스 수취인을 데빗하도록 처리될 수 있다(블록 1160). 조정 거래는 처음의 멀티-파티 거래로부터 수익을 획득하였던 당사자들 각각에 비례할 수 있다. 마찬가지로, 가입자 크레딧이 조정 비율 및 아이템에 대한 소매 가격에 기반하여 생성될 수 있다(블록 1170). 예를 들어, 아이템은 주어진 소매 가격으로 구매된다고 가정한다. 운영자, 제공자 및 소스 각각은 (예를 들어, 아이템과 관련된 각각의 요금들에 의해 정의된 바와 같이) 미리-설정된 비율로 소매 가격 중 수익을 획득할 수 있다. 무선 가입자 빌링 시스템은 아이템과 관련된 요금들에 기반하여 자동적으로 가입자에게 청구하고 각각의 당사자들에게 지불할 수 있으며, 이러한 정보는 이전에 논의된 바와 같이 나중의 액세스를 위해 저장될 수 있다. 가입자가 구매의 일부를 크레딧 또는 환불받아야 한다는 CRM에 의한 결정이 있으면, 조정 거래는 네거티브 빌링 이벤트로서 처리될 수 있다. 그리하여, 무선 가입자 빌링 시스템은 저장된 거래 데이터로 액세스하고 원래의 거래로부터 지불된 각각의 요금들에 비례하여 각각의 당사자(예를 들어, 운영자, 제공자 및 소스)를 데빗할 수 있다. 그에 따라, 이러한 조정들은 빌링 시스템을 통해 자동적으로 전달되어 모든 당사자들로 할당될 수 있으며, 이것은 지불 및 CRM 서비스들을 통한 수동적인 노력을 상당하게 줄일 수 있다.

추가적인 실시예들에서, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 이전의 방법들이 컴퓨터 플랫폼의 메모리와 같은 컴퓨터 판독가능 매체에 있는 프로그램의 실행에 의해 구현될 수 있다는 것을 이해할 것이다. 이러한 명령들은 다양한 타입들의 신호-베어링 또는 데이터 저장 1차, 2차 또는 3차 매체에 상주할 수 있다. 매체는 예컨대 클라이언트 장치 및/또는 서버에 의해 액세스 가능하거나 또는 클라이언트 장치 및/또는 서버 내에 상주하는 RAM을 포함할 수 있다. RAM, 디스켓 또는 다른 2차 저장 매체에 포함되는지 여부에 따라, 상기 명령들은 DASD 스토리지(예를 들어, 기존의 "하드 드라이브" 또는 RAID 어레이), 자기 테이 프, 전자 판독-전용 메모리(예를 들어, ROM 또는 EEPROM), 플래시 메모리 카드들, 광학 저장 장치(예를 들어, CD-ROM, WORM, DVD, 디지털 광학 테이프), 페이저 "펀치" 카드들 또는 디지털 및 아날로그 전송 매체를 포함하는 다른 적절한 데이터 저장 매체와 같은 다양한 기계-판독가능한 데이터 저장 매체에 저장될 수 있다.

이전의 설명은 본 발명의 예시적인 실시예들을 제시한 것이며, 첨부된 청구항들에서 정의되는 바와 같이 본 발명의 범위를 벗어남이 없이 다양한 변경들 및 변형들이 이루어질 수 있다는 것을 유의하도록 한다. 여기에 설명된 본 발명의 실시예들에 따른 방법 청구항들의 기능들, 단계들 및/또는 동작들은 임의의 특정한 순서로 수행될 필요는 없다. 또한, 본 발명의 엘리먼트들이 단수 형태로 설명되거나 청구될 수 있더라도, 단수 형태로의 한정이 명백하게 진술되지 않으면 복수 형태가 고려된다는 것을 유의하도록 한다.

Claims (49)

1. 신뢰된(trusted) 서비스로부터 빌링(billing) 요청을 수신하는 단계 ― 상기 빌링 요청은 상기 신뢰된 서비스 및 캐리어 네트워크의 클라이언트 장치 간의 제 3 자 거래에 대응하고, 상기 제 3 자 거래는 상기 클라이언트 장치에 의해 구매된 구매 아이템을 포함함 ―;

   빌링 정보를 포함하는 상기 빌링 요청을 상기 캐리어 네트워크의 무선 가입자 빌링 시스템의 검증 컴포넌트로 전달하는 단계;

   상기 무선 가입자 빌링 시스템의 상기 검증 컴포넌트로부터 상기 빌링 요청에 대한 검증(validation) 응답을 수신하는 단계; 및

   상기 검증 응답을 상기 신뢰된 서비스로 전달하는 단계;

   상기 클라이언트 장치에 대응하는 가입자 식별 정보(SID)에 기반하여 메인 카탈로그로부터 선택된 카탈로그 아이템들의 가입자 식별 정보-지시(SID-directed) 그룹에 상기 빌링 요청에 대응하는 상기 구매 아이템을 추가하는 단계; 및

   상기 클라이언트 장치에 상기 구매 아이템을 포함하는 상기 SID-지시 그룹을 제공(present)하는 단계를 포함하는, 방법
2. 제 1 항에 있어서,

   상기 빌링 요청을 처리하기 전에 상기 신뢰된 서비스를 인증하는 단계를 더 포함하는, 방법.
3. 제 2 항에 있어서, 상기 인증하는 단계는, 상기 빌링 요청과 연관된 상기 신뢰된 서비스의 디지털 서명을 검증하는 단계를 더 포함하는, 방법.
4. 제 1 항에 있어서,

   상기 빌링 정보는 가입자 ID, 제공자 수취인(payee), 아이템 ID, 소매 가격 및 빌링 디스크립션(description) 중 적어도 하나를 포함하는, 방법.
5. 제 1 항에 있어서,

   상기 빌링 요청이 유효하지 않은 것에 응답하여 에러 코드를 리턴하는 단계를 더 포함하는, 방법.
6. 삭제
7. 삭제
8. 제 1 항에 있어서,

   상기 클라이언트 장치에 상기 구매 아이템을 전달하는 단계를 더 포함하는, 방법.
9. 제 1 항에 있어서,

   전달 테이블에 있는 로컬 빌링 정보를 상기 구매 아이템과 관련시키는 단계를 더 포함하며, 상기 로컬 빌링 정보는 상기 제 3 자 거래에 대응하며, 그리고 상기 로컬 빌링 정보는 상기 구매 아이템에 대한 상기 메인 카탈로그에 대응하는 메인 카탈로그 빌링 정보와 상이한, 방법.
10. 제 9 항에 있어서,

    상기 전달 테이블에 있는 상기 로컬 빌링 정보를 이용하여 상기 구매 아이템이 전달되면 거래 데이터를 생성하는 단계; 및

    상기 거래 데이터에 기반하여 빌링 이벤트를 생성하는 단계를 더 포함하는, 방법.
11. 제 10 항에 있어서, 상기 구매 아이템의 전달은 상기 클라이언트 장치로 상기 SID-지시 그룹으로부터의 상기 구매 아이템을 다운로딩하는 것을 포함하며, 상기 전달 테이블에 있는 로컬 빌링 정보는 제로값 가격을 상기 구매 아이템의 상기 다운로딩과 연관시키도록 동작 가능한, 방법.
12. 제 9 항에 있어서,

    상기 구매 아이템의 전달을 표시하는 상기 전달 테이블에 있는 전달 상태를 기록하는 단계를 더 포함하는, 방법.
13. 제 12 항에 있어서,

    상기 구매 아이템과 관련된 상기 전달 테이블에 있는 상기 빌링 정보가 상기 전달 상태로 설정되면 추가적인 다운로드들을 방지하는 단계를 더 포함하는, 방법.
14. 제 1 항에 있어서,

    상기 빌링 요청과 함께 트래킹 ID를 포함하는 단계;

    상기 빌링 요청에 기반하여 상기 트래킹 ID를 포함하는 제 1 거래 데이터를 생성하는 단계; 및

    상기 제 1 거래 데이터를 처리하는 단계를 더 포함하는, 방법.
15. 제 14 항에 있어서,

    상기 제 1 거래 데이터를 처리하는 단계는,

    가입자 청구서(bill)를 생성하는 단계;

    지불(payment)을 제공자에게 배분하는 단계; 및

    상기 제 1 거래 데이터에 기반한 보고 데이터를 운영자 및 상기 제공자 중 적어도 하나에게 전송하는 단계를 더 포함하는, 방법.
16. 제 14 항에 있어서,

    상기 제 1 거래 데이터를 처리하는 단계는

    상기 거래 데이터와 함께 상기 트래킹 ID를 저장하는 단계를 더 포함하는, 방법.
17. 제 14 항에 있어서,

    상기 트래킹 ID를 상기 구매 아이템과 관련시키는 단계를 더 포함하는, 방법.
18. 제 17 항에 있어서,

    상기 구매 아이템 및 상기 트래킹 ID를 상기 클라이언트 장치로 전달하는 단계를 더 포함하는, 방법.
19. 제 18 항에 있어서,

    상기 구매 아이템이 전달되면 상기 트래킹 ID를 포함하는 제 2 거래 데이터를 생성하는 단계; 및

    상기 제 2 거래 데이터를 처리하는 단계를 더 포함하는, 방법.
20. 제 19 항에 있어서, 상기 제 2 거래 데이터를 처리하는 단계는

    상기 제 1 거래 데이터를 처리하는 단계가 가입자 청구서를 생성하는 단계를 포함하면 가입자에 대한 빌링을 방지하는 단계를 포함하는, 방법.
21. 신뢰된 서비스로부터 빌링 요청을 수신하도록 구성된 무선 가입자 빌링 시스템의 서비스 값 빌링(SVB) 모듈 ― 상기 빌링 요청은 상기 신뢰된 서비스 및 캐리어 네트워크의 클라이언트 장치 간의 제 3 자 거래에 대응하고, 상기 제 3 자 거래는 상기 클라이언트 장치에 의해 구매된 구매 아이템을 포함함 ―;

    상기 빌링 요청에 응답하여 검증 응답을 생성하도록 구성된 검증 로직;

    상기 클라이언트 장치에 대응하는 가입자 식별 정보(SID)에 기반하여 메인 카탈로그로부터 선택된 카탈로그 아이템들의 SID-지시 그룹에 상기 빌링 요청에 대응하는 상기 구매 아이템을 추가하도록 구성된 로직; 및

    상기 클라이언트 장치에 상기 구매 아이템을 포함하는 상기 SID-지시 그룹을 제공하도록 구성된 로직을 포함하는, 장치.
22. 제 21 항에 있어서,

    상기 빌링 요청과 관련된 거래 데이터를 수신하고 빌링 이벤트를 생성하도록 구성된 거래 관리자(TXN);

    상기 거래 관리자로부터 상기 빌링 이벤트를 수신하고 청구서를 생성하도록 구성된 클라이언트 빌링 모듈; 및

    상기 거래 관리자로부터 상기 빌링 이벤트를 수신하고, 캐리어를 인보이스(invoice)하고, 그리고 제공자에게 지불하도록 구성된 지불 모듈을 더 포함하는, 장치.
23. 제 22 항에 있어서,

    상기 TXN은 상기 빌링 이벤트를 생성하기 위해 추가적인 빌링 정보를 상기 빌링 요청과 관련시키는, 장치.
24. 제 21 항에 있어서,

    상기 빌링 요청은 상기 신뢰된 서비스에 의해 생성되는, 장치.
25. 제 24 항에 있어서,

    상기 빌링 요청은 상기 신뢰된 서비스를 인증하도록 동작가능한 디지털 서명을 포함하는, 장치.
26. 제 21 항에 있어서,

    상기 빌링 요청은 가입자 ID, 제공자 수취인, 아이템 ID, 소매 가격 및 빌링 디스크립션 중 적어도 하나를 포함하는, 장치.
27. 삭제
28. 제 21 항에 있어서,

    상기 그룹에 있는 상기 구매 아이템과 관련된, 그리고 상기 제 3 자 거래에 대응하는 로컬 빌링 정보를 포함하는 전달 테이블을 더 포함하고, 상기 로컬 빌링 정보는 상기 구매 아이템에 대한 상기 메인 카탈로그에 대응하는 메인 카탈로그 빌링 정보와 상이한, 장치.
29. 제 28 항에 있어서,

    상기 전달 테이블에 있는 상기 로컬 빌링 정보는 제로값 가격을 상기 구매 아이템의 다운로드와 연관시키도록 동작가능한, 장치.
30. 제 28 항에 있어서,

    상기 전달 테이블에 있는 전달 상태를 기록하도록 구성된 로직 ― 상기 전달 상태는 상기 구매 아이템의 전달을 표시함 ―; 및

    상기 구매 아이템과 관련된 상기 전달 테이블에 있는 상기 로컬 빌링 정보가 상기 전달 상태로 설정되면 추가적인 다운로드들을 방지하도록 구성된 로직을 더 포함하는, 장치.
31. 무선 가입자 빌링 시스템에서 신뢰된 서비스로부터 빌링 정보를 포함하는 빌링 요청을 수신하기 위한 수단 ― 상기 빌링 요청은 상기 신뢰된 서비스 및 캐리어 네트워크의 클라이언트 장치 간의 제 3 자 거래에 대응하고, 상기 제 3 자 거래는 상기 클라이언트 장치에 의해 구매된 구매 아이템을 포함함 ―;

    상기 무선 가입자 빌링 시스템에서 상기 빌링 요청에 대한 검증 응답을 생성하기 위한 수단;

    상기 검증 응답을 상기 신뢰된 서비스로 전달하기 위한 수단;

    상기 클라이언트 장치에 대응하는 가입자 식별 정보(SID)에 기반하여 메인 카탈로그로부터 선택된 카탈로그 아이템들의 SID-지시 그룹에 상기 빌링 요청에 대응하는 상기 구매 아이템을 추가하기 위한 수단; 및

    상기 구매 아이템을 포함하는 상기 SID-지시 그룹을 상기 클라이언트 장치에 제공하기 위한 수단을 포함하는, 시스템.
32. 제 31 항에 있어서,

    상기 빌링 요청을 처리하기 전에 상기 신뢰된 서비스를 인증하기 위한 수단을 더 포함하는, 시스템.
33. 제 31 항에 있어서,

    상기 빌링 정보는 가입자 ID, 제공자 수취인, 아이템 ID, 소매 가격 및 빌링 디스크립션 중 적어도 하나를 포함하는, 시스템.
34. 삭제
35. 제 31 항에 있어서,

    상기 구매 아이템을 전달하기 위한 수단; 및

    전달 테이블에 있는 로컬 빌링 정보를 상기 구매 아이템과 관련시키기 위한 수단을 더 포함하고, 상기 로컬 빌링 정보는 상기 구매 아이템에 대한 상기 메인 카탈로그에 대응하는 메인 카탈로그 빌링 정보와 상이한, 시스템.
36. 제 35 항에 있어서,

    상기 전달 테이블에 있는 상기 로컬 빌링 정보를 이용하여 상기 구매 아이템이 전달되면 거래 데이터를 생성하기 위한 수단; 및

    상기 거래 데이터에 기반하여 빌링 이벤트를 생성하기 위한 수단을 더 포함하는, 시스템.
37. 제 35 항에 있어서,

    상기 전달 테이블에 있는 상기 로컬 빌링 정보는 제로값 가격을 상기 구매 아이템의 다운로드와 연관시키도록 동작가능한, 시스템.
38. 제 37 항에 있어서,

    상기 구매 아이템의 전달을 표시하는 상기 전달 테이블에 있는 전달 상태를 기록하기 위한 수단; 및

    상기 구매 아이템과 관련된 상기 전달 테이블에 있는 상기 로컬 빌링 정보가 상기 전달 상태로 설정되면 추가적인 다운로드들을 방지하기 위한 수단을 더 포함하는, 시스템.
39. 실행되면 컴퓨팅 장치가 동작들을 수행하도록 하는 명령들을 포함하는 컴퓨터-판독가능 매체로서, 상기 명령들은,

    무선 가입자 빌링 시스템에서 신뢰된 서비스로부터 빌링 요청을 수신하기 위한 적어도 하나의 명령 ― 상기 빌링 요청은 상기 신뢰된 서비스 및 캐리어 네트워크의 클라이언트 장치 간의 제 3 자 거래에 대응하고, 상기 제 3 자 거래는 상기 클라이언트 장치에 의해 구매된 구매 아이템을 포함함 ―;

    상기 무선 가입자 빌링 시스템에서 상기 빌링 요청에 대한 검증 응답을 생성하기 위한 적어도 하나의 명령;

    상기 검증 응답을 상기 신뢰된 서비스로 전달하기 위한 적어도 하나의 명령;

    상기 클라이언트 장치에 대응하는 가입자 식별 정보(SID)에 기반하여 메인 카탈로그로부터 선택된 카탈로그 아이템들의 SID-지시 그룹에 상기 빌링 요청에 대응하는 상기 구매 아이템을 추가하기 위한 적어도 하나의 명령; 및

    상기 구매 아이템을 포함하는 상기 SID-지시 그룹을 상기 클라이언트 장치에 제공하기 위한 적어도 하나의 명령을 포함하는, 컴퓨터 판독가능 매체.
40. 삭제
41. 무선 가입자 빌링 시스템에서 멀티-파티(multi-party) 빌링 이벤트들을 처리하는 방법으로서,

    제공자 요금(provider fee) 및 제공자 수취인(provider payee)과, 거래와 관련된 적어도 하나의 소스 요금(source fee) 및 소스 수취인(source payee)을 포함하는 빌링 이벤트를 생성하는 단계; 및

    지불을 상기 제공자 수취인 및 상기 적어도 하나의 소스 수취인에게 배분하기 위해 상기 거래를 처리하는 단계;

    거래 데이터를 저장하는 단계;

    상기 저장된 거래 데이터를 액세스하는 단계;

    상기 저장된 거래 데이터에 기반하여 네거티브(negative) 제공자 요금 및 적어도 하나의 네거티브 소스 요금을 포함하는 조정 거래를 생성하는 단계; 및

    상기 네거티브 제공자 요금 및 상기 적어도 하나의 네거티브 소스 요금에 기반하여 상기 제공자 수취인 및 상기 적어도 하나의 소스 수취인을 데빗(debit)하도록 상기 조정 거래를 처리하는 단계를 포함하는, 방법.
42. 제 41 항에 있어서,

    상기 제공자 요금은 상기 적어도 하나의 소스 요금보다 더 크거나 또는 동일한, 방법.
43. 제 41 항에 있어서,

    거래 보고 데이터를 상기 제공자 수취인 및 상기 적어도 하나의 소스 수취인 중 적어도 하나로 전송하는 단계를 더 포함하는, 방법.
44. 제 41 항에 있어서,

    제공된 아이템에 대한 소매 가격에 기반하여 가입자 청구서를 생성하는 단계를 더 포함하며, 상기 소매 가격은 상기 제공자 요금보다 더 크거나 또는 동일한, 방법.
45. 삭제
46. 제 41 항에 있어서,

    비례 기준과 상기 제공자 수취인 및 상기 적어도 하나의 소스 수취인의 지불과 관련된 상기 저장된 거래 데이터에 기반하여 상기 네거티브 제공자 요금 및 상기 적어도 하나의 네거티브 소스 요금을 결정하는 단계를 더 포함하는, 방법.
47. 제 44 항에 있어서,

    조정 비율 및 상기 아이템에 대한 소매 가격에 기반하여 가입자 크레딧(credit)을 생성하는 단계를 더 포함하는, 방법.
48. 제 41 항에 있어서,

    상기 조정 거래를 저장하는 단계를 더 포함하는, 방법.
49. 제 41 항에 있어서,

    조정 거래 보고 데이터를 상기 제공자 수취인 및 상기 적어도 하나의 소스 수취인 중 적어도 하나로 전송하는 단계를 더 포함하는, 방법.

Images