JP2008546096A

JP2008546096A - 無線加入者請求書作成及び配布

Info

Publication number: JP2008546096A
Application number: JP2008514743A
Authority: JP
Inventors: ユ、ジュリー; オリバー、ミッチェル・ビー．; ホレル、ジェラルド・チャールズ; ヌグイェン、フィル・ティエン; プラスト、サンドラ・エル．; パトワリ、ジャイティーアス
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2005-05-31
Filing date: 2006-05-31
Publication date: 2008-12-18
Anticipated expiration: 2026-05-31
Also published as: WO2006130539A3; CN101185282A; TW200719619A; CN101620720A; KR20080017418A; US20060270386A1; EP2367318B1; JP5579383B2; BRPI0611321A2; CN101185282B; EP2288075B1; EP2288075A1; EP1886440A2; TWI324866B; WO2006130539B1; EP1886440B1; WO2006130539A2; JP2013012213A; US9350875B2; EP2367318A1

Abstract

無線加入者請求書作成システムにおいて請求書作成要求を生成し、且つ応答するシステム及び方法が開示される。請求書作成要求は信用サービスにおいて生成される。請求書作成情報を含む請求書作成要求は無線加入者請求書作成システムに通信される。請求書作成要求に対する確認応答は無線加入者請求書作成システムにおいて生成され、そして確認応答は信用サービスに通信される。
【選択図】図４

Description

発明の分野

本発明は一般に遠隔コンピュータ・デバイスとサーバとの間の通信に関係する特に、本発明はサーバと遠隔クライアント・デバイスとの間の請求イベントの作成及び送信に関係する。

発明の背景

技術の進歩は小型、且つ強力な個人用コンピュータ・デバイスをもたらした。例えば、小型軽量で、且つユーザーが容易に持ち運びできる携帯無線電話、携帯情報機器（ＰＤＡ）及びページング・デバイスといった、無線コンピュータ・デバイスを含めて、様々な携帯用個人コンピュータ・デバイスが現在存在する。特に、携帯無線電話は、例えば、無線ネットワーク上で音声及びデータ・パケットを通信するセルラー電話をさらに含む。さらに、多くの前記セルラー電話は計算能力を比較的大きく増大させて製造されつつあり、そしてそれ自体は小さな個人用コンピュータ及び携帯情報機器と同等になりつつある。しかしながら、これらのさらに小さな、且つさらに強力な個人コンピュータ・デバイスは一般的に厳しく資源を制約される。例えば、画面サイズ、利用可能なメモリとファイル・システム空間の容量、入出力能力の大きさ及び処理能力はデバイスの小型サイズ及びユーザー入力ユニット、例えば、キーボードの小型サイズによって制限される。そのような厳しい資源制限のために、前記遠隔個人コンピュータ・デバイス（クライアント・デバイス）上にあるソフトウェア・アプリケーション及び他の情報の限られたサイズ及び量を維持することが大抵は一般的に望ましい。

いくつかの個人コンピュータ・デバイスはランタイム環境及びソフトウェア・プラットフォームとも時々呼ばれるアプリケーション・プログラミング・インタフェース（ＡＰＩ）を利用し、それはそれらの局所コンピュータ・プラットフォームに取付けられ、そしてデバイス特定の資源に対する汎用呼出を行うといったことによって、例えば、前記デバイスの動作を単純化するために使用される。さらに、いくつかの前記ＡＰＩはまた前記デバイス上で十分に実行可能なソフトウェア・アプリケーションを造出する能力をソフトウェア開発者に提供することが知られている。その上、いくつかの前記ＡＰＩは、ソフトウェア開発者が特定のコンピュータ・デバイス・システムのソース・コードを持つことを必要とすることなく、コンピュータ・デバイスの計算機能がソフトウェア・アプリケーションに利用可能になるように、コンピュータ・デバイスのシステム・ソフトウェアとソフトウェア・アプリケーションの間に操作上位置していることが知られている。さらに、いくつかのＡＰＩは安全な暗号情報を使用して前記個人デバイス（即ち、クライアント）と遠隔デバイス（即ち、サーバ）との間の安全な通信の機構を提供することが知られている。

前記ＡＰＩの例は、そのうちのいくつかは下記でさらに詳細に述べられるが、カリフォルニア州サンディエゴ市のカルコム（QUALCOMM）社によって開発された無線用バイナリ・ランタイム環境ソフトウェア（Binary Runtime Environment for Wireless：ＢＲＥＷ（登録商標））の版を含む。ＢＲＥＷはコンピュータ・デバイス（例えば、無線携帯電話）のオペレーティング・システムによって動作し、いくつかの機能の中で、個人コンピュータ・デバイス上で特に見付けたハードウェア機能にインタフェースを提供することができる。ＢＲＥＷはまたデバイス資源への要求に関して、且つＢＲＥＷを含むデバイスに利用者が支払う値段に関して比較的低い費用で前記個人用コンピュータ・デバイス上でこれらのインタフェースを提供することができる。ＢＲＥＷのさらなる機能は無線サービス作業者、ソフトウェア開発者及びコンピュータ・デバイス利用者に様々な利益を提供するその終端間（end-to-end）ソフトウェア配分プラットフォームを含む。少なくとも一つのそのような現在利用可能な終端間ソフトウェア配分プラットフォームはサーバ-クライアント・アーキテクチャ上に配分された論理を含み、そこではそのサーバは、例えば、請求書作成（billing）、安全及びアプリケーション配分の機能を実行し、そしてクライアントは、例えば、アプリケーション実行、安全及びユーザー・インタフェースの機能を実行する。

関連技術の前述の説明は単にＡＰＩのいくつかの既知の使用法を概観し、且つＢＲＥＷプラットフォームへの導入として提供することを意図するもので、それは本発明の実施例において使用される。しかしながら、本発明は特定の実施、動作プラットフォームまたは環境に限定されると解釈されるものではない。

発明の概要

本発明の典型的な実施例は無線ネットワークにおいて請求書作成要求を生成し、且つ処理するためのシステム及び方法に関するものである。

従って、本発明の実施例は、信用サービス（trusted service）において請求書作成要求を生成すること；請求書作成情報を含む請求書作成要求を無線加入者請求書作成システムに通信すること；無線加入者請求書作成システムにおいて請求書作成要求に対する確認応答を生成すること；及び確認応答を信用サービスに通信することからなる方法を含む。

本発明の別の実施例は、信用サービスから請求書作成要求を受取り、且つ信用サービスを認証するために構成された無線加入者請求書作成システムにおけるサービス値請求書作成（ＳＶＢ）モジュール；及び請求書作成要求に応答して確認応答を生成するために構成された確認論理を具備する装置を含む。

本発明の別の実施例は、無線加入者請求書作成システムにおいて信用サービスから請求書作成情報を受取る手段；無線加入者請求書作成システムにおける請求書作成要求に対する確認応答を生成する手段；及び確認応答を信用サービスに通信する手段を具備するシステムを含む。

本発明の別の実施例は無線加入者請求書作成システムにおける請求書作成要求を処理するコンピュータ・プログラムが記憶されるコンピュータ可読媒体を含み、コンピュータ・プログラムは、実行されると、請求書作成要求を信用サービスから受取ること（ここでは請求書作成は無線加入者請求書作成システムに請求書作成情報を要求する）；無線加入者請求書作成システムにおける請求書作成要求に対する確認応答を生成すること；及び確認応答を信用サービスに通信することからなる処理をコンピュータ・デバイスに実行させる命令を含む。

本発明の別の実施例は無線加入者請求書作成システムにおける多数の請求書作成イベントを処理する方法を含み、その方法は、プロバイダ料金及び受取人、及び業務（transaction）に関連する少なくとも一つのソース料金及び受取人を含む請求書作成イベントを生成すること；及び支払金をプロバイダ受取人及び少なくとも一人のソース受取人に配分するために業務を処理することを含む。

本発明の限定ではなく単に例示のために提示される付随の図と関連して考察するとき、同じことが次の詳細な説明の参照によってさらによく理解されるので、本発明の実施例及び多数の付随するその利点のさらに完全な理解が容易に得られるであろう。

好ましい実施形態の詳細な説明

本発明の形態は発明の特定の実施例に関する次の記述及び関連の図で開示される。代替実施例は本発明の範囲から逸脱することなく考案される。その上、本発明の周知の要素は本発明の適切な詳細を不明瞭にしないために詳細に示されず、或いは省略されるであろう。

用語「典型的な（exemplary）」は「例（example）、事例（instance）、または例示（illustration）として役立つ」ことを意味するものとしてここでは使用される。「典型的な」としてここに記述された実施例は他の実施例に対して好ましいとか、或いは有利であると必ずしも解釈されない。同様に、用語「本発明の実施例」は本発明の全ての実施例が動作について述べた特徴、利点、または様式を含むことを要求しない。

同様に、多くの実施例は、例えば、コンピュータ・デバイスの要素によって行われる一連の動作行為（actions）に関して記述される。ここに述べる様々な動作行為は特定の回路（例えば、特定用途集積回路（ＡＳＩＣ））によって、一以上のプロセッサにより実行されるプログラム命令によって、或いは両者の組合せによって実行され得ることが認識されるであろう。その上、ここに述べたこれらの一連の動作行為は、実行の際関連するプロセッサがここに述べた機能を実行するために対応するコンピュータ命令の集合を記憶していたいずれかの形のコンピュータ可読媒体内で完全に具現化されると考えられる。従って、本発明の様々な形態はいくつかの異なる形で具現化され、その全ては請求項の範囲内にあると考えられてきた。その上、ここに記述した各々の実施例について、前記のいずれかの実施例の対応形は、例えば、記載の動作行為を実行するために「構成された論理」としてここに記述される。

本発明の一以上の実施例はコンピュータ・デバイス上で実行するランタイム環境（例えば、ＡＰＩ）と共に使用される。そのような一つのランタイム環境は以前に述べた無線のためのバイナリ・ランタイム環境（ＢＲＥＷ）である。しかしながら、本発明の一以上の実施例は、例えば、無線クライアント・コンピュータ・デバイス上でアプリケーションの実行を制御するために動作する他の形式のランタイム環境またはプラットフォームによって使用される。

その上、配分され、且つ実行されているアプリケーション・ファイル形式はここでは説明を簡単にするために記述されることは当業者には理解されるであろう。しかしながら、「アプリケーション」はまたオブジェクト・コード、スクリプト、Ｊａｖａ（登録商標）ファイル、ブックマーク・ファイル（またはＰＱＡファイル）、ＷＭＬスクリプト、バイト・コード、及びｐｅｒｌスクリプトといった実行可能な内容をもつファイルを含む。その上、ここで参照される「アプリケーション」はまた開かれる必要がある文書またはアクセスされる必要がある他のデータ・ファイルのように、本来実行できないファイルを含む。

図１は本発明の少なくとも一つの実施例による無線システム１００の一つの典型的な実施例のブロック図を例示する。システム１００は無線通信ポータルまたは無線ネットワーク１０４への他のデータ・アクセスを通してソフトウェア・アプリケーション及び構成要素（components）を無線デバイスへ選択的に伝送する少なくとも一つのアプリケーション・ダウンロード・サーバ１０６と無線ネットワーク１０４を通して通信中のセルラー電話１０２のようなクライアント・デバイスを含む。ここで示したように、無線 ( クライアント ) デバイスはセルラー電話１０２、携帯情報機器１０８、双方向のテキスト・ポケットベルとしてここで示されるポケットベル（pager）１１０、または無線通信ポータルを持つ別個のコンピュータ・プラットフォーム１１２である。本発明の実施例は無線通信ポータルを含み、或いは無線通信能力を持ち、制限なしで、無線モデム、ＰＣＭＣＩＡカード、パーソナル・コンピュータ、アクセス端末、電話、またはそのいずれかの組合せ或いは部分組合せを含むいずれかの形のクライアント・デバイス上でこのように実現される。

アプリケーション・ダウンロード・サーバ（ＡＤＳ）１０６は無線ネットワークと通信している他のコンピュータ要素を持つネットワーク１１６に関してここで示されている。単体のサーバ１２２があり、各サーバは無線ネットワーク１０４を通して個別のサービス及び処理をクライアント・デバイス１０２、１０８、１１０、１１２へ提供する。好しくは無線デバイス１０２、１０８、１１０、１１２によってダウンロード可能なソフトウェア・アプリケーション及び内容（content）を保持する少なくとも一つの記憶アプリケーション・データベース１１８がまたある。しかしながら、当業者は図１に例示した構成が単に典型的であることを理解するであろう。従って、全ての説明された機能をそれぞれ実行し、そして全ての必要なハードウェア及びソフトウェアを含み、或いは選択した機能だけを含む一以上のサーバを本発明の実施例は含む。

図２において、無線ネットワーク１０４の構成要素を含むシステム１００及び本発明の典型的な実施例の要素の相互関係をさらに詳しく例示するブロック図が示される。システム１００は単に典型的なものであり、無線クライアント・コンピュータ・デバイス１０２、１０８、１１０、１１２といった遠隔クライアント・デバイスが相互の間で、及び／または、制限なしで、無線ネットワーク・キャリア及び／またはサーバを含む無線ネットワークを介して結合された構成要素の間で無線通信することを可能にするいずれかのシステムを含む。アプリケーション・サーバ１０６及び記憶アプリケーション・データベース１１８は、セルラー電気通信サービスを行うために使用される請求書作成サーバ１３０のような他のいずれかのサーバと共に、インターネット、安全なＬＡＮ、ＷＡＮ、または他のネットワークといったデータ回線を通じてキャリア・ネットワーク２００と通信する。示した実施例において、サーバ１２０はアプリケーション・ダウンロード・サーバ１０６、請求書作成サーバ１３０及び記憶アプリケーション・データベース１１８を含む。しかしながら、これらのサーバはまた独立したデバイスである。

キャリア・ネットワーク２００はメッセージ・サービス制御器（ＭＳＣ）２０２に送られる（一般的にデータ・パケットとして送られる）メッセージを制御する。キャリア・ネットワーク２００はネットワーク、インターネット、及び／または加入者電話網（ＰＳＴＮ）によってＭＳＣ２０２と通信する。一般的に、キャリア・ネットワーク２００とＭＳＣ２０２との間のネットワーク或いはインターネット接続はデータを転送し、そしてＰＳＴＮは音声情報を転送する。ＭＳＣ２０２は多数の基地局（ＢＴＳ）２０４に接続される。キャリア・ネットワークに類似した方法で、ＭＳＣ２０２は一般的にデータ転送及び／または音声情報に関してネットワーク、インターネット及び／またはＰＳＴＮによってＢＴＳ２０４に接続される。ＢＴＳ２０４は短メッセージ・サービス（ＳＭＳ）または当技術分野において既知の他の無線（over-the-air：ＯＴＡ）方法によって、セルラー電話１０２のようなクライアント・デバイスにデータ・メッセージを同報する。

クライアント・デバイス（ここでは、無線クライアント・コンピュータ・デバイス）、例えばセルラー電話１０２は、アプリケーション・ダウンロード・サーバ１０６、請求書作成サーバ１３０及び／またはサーバ１２０から伝送されたソフトウェア・アプリケーションまたは内容（content）及び／または命令（commands）を受信し、且つ実行するコンピュータ・プラットフォーム２０６を有する。コンピュータ・プラットフォーム２０６は特定用途集積回路（ＡＳＩＣ２０８）、または他のプロセッサ、マイクロプロセッサ、論理回路、或いは他のデータ処理デバイスを含む。ＡＳＩＣ２０８または他のプロセッサは無線デバイスのメモリ２１２内の在駐プログラムと相互作用するアプリケーション・プログラミング・インタフェース（ＡＰＩ）２１０層を実行する。メモリ２１２は読取専用またはランダムアクセス・メモリ（ＲＡＭ及びＲＯＭ）、ＥＥＰＲＯＭ、フラッシュ・カード、またはコンピュータ・プラットフォームに共通のいずれかのメモリから成る。ＡＰＩ２１０はまたクライアント・デバイスからキャリア・ネットワーク２００への特定の請求書作成要求を処理するために構成された論理を含むアプリケーションに基づく金額請求書作成拡張機能（ＡＶＢ）３１０を含む。コンピュータ・プラットフォーム２０６はまたメモリ内であまり使用されないアプリケーションを保持する局所データベース２１４を含む。局所データベース２１４は一般的にはフラッシュ・メモリ・セルであるが、磁気媒体、ＥＥＰＲＯＭ、光学媒体、テープ、ソフトまたはハード・ディスク、等々といった当技術分野で既知の二次記憶デバイスである。

無線クライアント・コンピュータ・デバイス、例えばセルラー電話１０２などは、それにインストールをしており、そうでなければゲーム、ニュース、ストック・モニタ、等々といった、一以上のソフトウェア・アプリケーションをダウンロードする。例えば、セルラー電話１０２はダウンロード・サーバ１０６からダウンロードされた一以上のソフトウェア・アプリケーション及び内容を受取る。使用していないときは、ソフトウェア・アプリケーション及び内容は局所データベース２１４に記憶される。セルラー電話１０２または他の無線コンピュータ・デバイスはユーザーによってそのように所望されたとき、或いは別のＡＰＩによって呼出されたとき、ＡＰＩ２１０上で実行するために局所データベース２１４上に記憶された在駐アプリケーションを転送（upload）する。

ここに使用するように、「クライアント・デバイス」、「無線デバイス」または「クライアント・コンピュータ・デバイス」は、例えば、在駐の構成された論理を実行する一以上の処理回路を含み、そこでは前記コンピュータ・デバイスはマイクロプロセッサ、ディジタル信号プロセッサ（ＤＳＰ）、携帯情報機器（ＰＤＡ）、及びページング・デバイスを、或いはクライアントとサーバ間で通信される請求書作成情報向けにここに記述された動作を少なくとも行うために構成されたプロセッサ及び論理を含むハードウェア、ソフトウェア及び／またはファームウェアのいずれか適当な組合せを含む。クライアント・コンピュータ・デバイスはクライアント・デバイスにおいて生成された請求書作成要求を処理することに関して少なくとも一つの遠隔サーバによるサービスを受ける。本発明の実施例に従って使用されるいくつかのクライアント・デバイスはセルラー電話または他の無線通信ユニット、ＰＤＡ、ページング・デバイス、携帯用航行デバイス、携帯用ゲーム・デバイス、音楽またはビデオ内容ダウンロード・ユニット、及び他の同様な無線通信デバイスを含む。

クライアント・デバイス１０２とＢＴＳ２０４との間の無線通信は符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、汎欧州ディジタル・セルラー・システム（ＧＳＭ）、或いは無線通信ネットワークまたはデータ通信ネットワークにおいて使用される他のプロトコルといった、異なる技術に基づいている。データ通信は一般的にクライアント・デバイス１０２、ＢＴＳ２０４、及びＭＳＣ２０２間のものである。ＭＳＣ２０２はキャリア・ネットワーク２００、ＰＳＴＮ、インターネット、仮想私設通信網、等々といった多元データ・ネットワークに接続され、したがってクライアント・デバイスの広範な通信ネットワークへのアクセスを可能にする。前に述べたように、音声伝送に加えて、データは当技術分野において既知のＳＭＳまたは他のＯＴＡ方法によってクライアント・デバイスに伝送される。

図３を参照すると、ＡＶＢ拡張機能３１０（例えば、アプリケーション内の請求書作成要求及び処理を可能にするＡＰＩ）を含むアプリケーション３２０（例えば、ＢＲＥＷ（商標）アプリケーション）を含むクライアント・デバイス３００が例示される。請求書作成要求はアプリケーション内で生成される。これは買物の経験がアプリケーション・レベルで制御されること、及びアプリケーションの配分及び価格決定、アプリケーションの機構、及び／または内容においてより大きな柔軟性を可能にする。例えば、開発者は各々異なる価格レベルを持つ様々な機構によって、アーケード形式のアプリケーションを提供することを望む。これらの機構は元のアプリケーションと共に含まれ（例えば、難しさの異なるレベル）、或いは遠隔サーバからダウンロードされる（例えば、高度のバックグラウンド音楽）。各機構を購入する選択肢はユーザーに提示され、そしてユーザーはＡＶＢ拡張機能３１０を使用してアプリケーション・レベルで追加の機構を購入するかどうか決定する。従って、一つのアプリケーション３２０は多数のアプリケーション、及び異なるアプリケーションの多数のダウンロードを必要とすることなく、差別化価格決定について開発者及びキャリアに関して増加する請求書作成を行う。同様に、追加サービスがアプリケーションを通して可能になり、ネットワークによるアプリケーションは新しいアプリケーションを再配置しなくとも課金（charges）の増加に利用可能な最新のサービス・セットを動的に設定する。これの例は着信音ショッピング・アプリケーションであろう。着信音はサーバに記憶され、そして内容サーバが適切に決定するように更新される。ＡＶＢアプリケーションは実時間で顧客に表示するために着信音及び価格決定の遠隔の番号帳にアクセスすることができる。従って、ＡＶＢＡＰＩはデータ・サービス提案及び価格決定の柔軟性に関して開発者及び作業者にさらに大きい柔軟性を提供する。

対称的に、従来のシステムを使って同様の機能を達成するために、アプリケーション開発者は各機構及び／または価格決定レベルの異なるアプリケーションを生成し、そしてそれらをダウンロードに利用可能にしなければならないであろう。従来のシステムは一回限りの購入として各ダウンロードを扱い、そして請求書作成情報を記録し、そしてダウンロードされた各アプリケーションに関する決済を処理するであろう。この処理はキャリアによって制御され、そして各アプリケーションを購入するために、クライアント・デバイスはアプリケーション・カタログを閲覧し、且つ所望の機構を持つ所望のアプリケーションを購入するためキャリア・ネットワークに接続しなければならないであろう。

上で述べたように、本発明の実施例では、ショッピングの経験はクライアント・デバイス３００で行われる。従って、購入選択肢がクライアント・デバイス３００で提示され、且つ受理された後で、請求書作成要求はクライアント・デバイス３００内で生成される。請求書作成要求、及び請求書作成業務（例えば、加入者識別情報（ＳＩＤ）、内容プロバイダ）、小売価格、等々を処理するために使用される他の情報は遠隔の請求書作成システム３０１に伝送される。請求書作成要求は遠隔の請求書作成システム３０１で受取られ、そして処理される。確認応答は遠隔の請求書作成システム３０１における請求書作成要求に応答して生成される。確認応答はクライアント・デバイス３００に伝送される。

確認応答は請求書作成要求の承認、または請求書作成要求の拒否である。一旦、クライアント・デバイスがその応答を受取れば、それに従ってその確認を処理する。例えば、確認応答が肯定であれば、請求書作成要求に関連する機構（例えば、アーケード・ゲームにおける追加レベル）は稼働状態になる。同様に、請求書作成要求が拒否されれば、請求書作成要求の拒否の指示がクライアント・デバイス上に表示される。選択的に、追加情報はその要求が拒否された理由（例、資金不足）のような拒否に含まれる。

少なくとも一つの実施例では、請求書作成システムはシステムの実施を容易にするために現存の請求書作成構成部品を活用する。例えば、図３において、アプリケーション配分システム（ＡＤＳ）１０６はクライアント・デバイス３００から請求書作成要求を受取る。ＡＤＳ１０６はそれから請求書作成本体（例えば、キャリア）によって決定される確認論理３３０にアクセスする。確認論理は詳述されるか、もしくは所望するように限定される。例えば、ＳＩＤ及び要求された請求書作成量が正当であり、且つ十分な情報が請求書作成イベント（例えば、項目（item）ＩＤ、プロバイダＩＤ、プロバイダ価格決定（例えば、プロバイダが支払われる価格）、等々）を生成するために提供される限り、キャリアは全ての請求書作成イベントが処理されることを可能にする。この情報は請求書作成要求に直接含まれ、もしくは請求書作成システムにおけるサーバ中の記憶情報と組合わせて生成される。例えば、項目ＩＤは一以上のプロバイダＩＤ及び関係するプロバイダ価格決定、項目の説明、顧客表示価格（ＣＬＰ）と関連する。しかしながら、請求書作成要求を生成するクライアントからの業務の間にユーザーに表示された価格は加入者請求書作成のために使用される価格であるはずなので、一般的に価格決定情報はＡＶＢ３１０から伝送されるであろう。

ＡＤＳ１０６は項目ＩＤに基づいて追加請求書作成情報を生成する。その上、一旦、確認論理３３０が請求書作成要求を承認すれば、ＡＤＳ１０６は追加検査を実行する。例えば、クライアント価格決定計画が前納（prepay）計画であれば、前納収支がその項目を購入するのに十分な資金があるかどうかを知るために検査される。十分な資金があれば、その承認はクライアント・デバイスに伝送される。しかしながら、資金不足があれば、たとえ請求書作成要求が正当であったとしても、請求書作成要求は拒否される。一旦、請求書作成要求が請求書作成システム３０１によって究極的に承認されると、その承認は請求書作成要求を生成したＡＶＢ３１０及びアプリケーション３２０による処理のためにクライアント・デバイス３００に伝送される。

承認の伝送に加えて、ＡＤＳ１０６は業務データを業務マネージャ（ＴＸＮ）３４０に通信する。ＴＸＮ３４０はＡＤＳ１０６から業務データを受取るために構成される。ＴＸＮ３４０は含まれていない請求書作成情報をいくらかのさらなる業務データと関連させる。例えば、業務データはＳＩＤ、項目ＩＤ、及び価格ＩＤを含む。ＴＸＮ３４０は請求書作成処理（例えば、プロバイダＩＤ及び関連のプロバイダ価格決定、項目の説明、完全な価格決定計画、等々）を完了するために追加データを関連させる。ＴＸＮ３４０はそれから請求書作成イベントとしてこの情報をクライアント請求書作成モジュール３５０及び決済モジュール３６０に通信する。クライアント請求書作成モジュール３５０はＴＸＮ３４０から請求書作成イベントを受取り、且つクライアント・デバイス３００に関連する加入者に対する請求書（bill）を生成するために構成される。決済モジュール３６０は請求書作成本体（例えば、キャリア／作業者）を呼出し、そしてプロバイダ（例えば、開発者、出版者、等々）に支払うためにＴＸＮ３４０から請求書作成イベントを受取るために構成される。

一般的に、業務データが生成された後、請求書作成イベントは従来の方法において造出され、且つ処理される。例えば、項目と関連するメタデータはＴＸＮ３４０及び／または関係するデータベースに記憶される。クライアント・デバイス３００が請求書作成要求に対する承認を受取ると、業務データはデータベースに送られ、且つ記憶される。キャリア及び／または開発者に生成された報告が業務をＡＶＢ生成の請求書作成イベントとして識別することができるように業務の形式もまた記憶される。業務データはまた他のデバイス及び／またはシステムによって含まれるメタデータの部分集合及び追加情報を含む。請求書作成イベントはメタデータ及び未加工の業務データを相関させることによってＴＸＮ３４０において造出される。この処理のさらに詳細な記述は「業務処理（Transaction Processing）」と題する、共有米国特許出願番号第１０／２２２，７０５号に見られ、それは全体として参照によってここに組込まれている。

クライアント・デバイスのアプリケーションを購入し、且つ取得するための従来の処理は利用可能なアプリケーションのカタログにアクセスし、所望のアプリケーションを選択し、そしてクライアント・デバイスへアプリケーションをダウンロードするクライアント・デバイスを含む。この処理は、発明の背景において述べたように、究極的に加入者の請求書作成及びアプリケーション開発者の支払いをもたらすアプリケーション・ダウンロードに関係する請求書作成イベントを生成する。しかしながら、アプリケーションの販売及び購入、及び無線加入者請求書作成システムの利用はこのクライアント-サーバ接続に制限されてきた。

図４は追加サービス額請求書作成を可能にする本発明の少なくとも一つの実施例によるシステムを例示する。サービス額請求書作成（ＳＶＢ）モジュール４１０は無線加入者請求書作成システム４００に含まれる。ＳＶＢ４１０はキャリア・ネットワークの一部ではない信用サービス４９０（例えば、第三者供給元（third-party vendor）、出版者、等々）のために請求書作成ポータルを提供する。ＳＶＢ４１０は信用サービス４９０がその後請求書作成システム４００を通して処理される請求書作成要求を生成することを可能にする。クライアント・デバイスから直接選択され、且つクライアント・デバイスへダウンロードされたアプリケーションについて配分し、且つ請求する従来のシステムとは対照的に、ＳＶＢは非アプリケーション関連の業務が確定無線加入者請求書作成システム４００を通して処理されることを可能にする。

認証機構はＳＶＢモジュール４１０にアクセスしている信用サービス４９０の識別を証明するＳＶＢモジュール４１０に含まれる。例えば、ディジタル証明書は信用サービスに発行される。証明書は確認のためにキャリア／作業者及び信用サービス（例えば、内容受取人）と関連しているであろう。信用サービス４９０は発行証明書を使用してＳＶＢモジュール４１０への各業務にディジタル的に署名する。ディジタル署名及びディジタル証明書は各要求に含まれる。ＳＶＢモジュールはそれから各請求書作成要求に関する署名を認証する。例えば、ＳＶＢ４１０はウェブ準拠インタフェースであり、そしてＳＶＢ４１０への接続は、例えば、信用サービス４９０認証におけるＨＴＴＰＳプロトコルを使用してインターネットを経由する。しかしながら、本発明がインターネット接続及び HTTPS プロトコル及び有線及び／または無線接続のどのような組合せにも制限されず、そして適当な安全性／認証システムが信用サービスからの請求書作成要求を通信するために使用されることを当業者は認識するであろう。

従って、無線加入者請求書作成システム４００は請求書作成システム４００の外部の信用サービスから請求書作成要求を受取る。請求書作成要求は請求書作成システム４００に通信され、且つ請求書作成システム４００における要求を有効にするために使用される請求書作成情報を含む。さらに、請求書作成システム４００は請求書作成要求に対する確認応答を生成し、そして確認応答を信用サービス４９０に通信する。請求書作成情報は加入者ＩＤ、プロバイダ／内容受取人、内容（項目）ＩＤ、表示価格、請求書作成説明、等々を含めて、請求書作成要求を有効とするために使用される情報を含む。しかしながら、当業者は他のデータが請求書作成要求に含まれることを認識するであろう。

例えば、図４に例示した構成において、請求書作成要求は信用サービス４９０によって生成される。ＳＶＢ４１０は信用サービス４９０から請求書作成要求を受取り、そしてここに述べたように、信用サービス４９０を認証する。確認論理４３０は請求書作成要求を有効にする。キャリアはさらなる処理の請求書作成要求を受入れるか、もしくは要求を拒絶することを望むかどうかを判定するために、確認論理４３０を使用して、キャリアは請求書作成完全性の検査を行う。キャリアは価格決定及び業務を制御していないが、加入者に請求書を送っているので、確認論理４３０はどちらの請求書作成要求が受入れ可能であるかをキャリアが判定することを可能にする介入点として使用される。請求書作成要求が有効とされれば、ＳＶＢ４１０は請求書作成要求に基づいて業務データを生成し、そして業務データを業務マネージャ４４０に通信する。業務マネージャ４４０はＳＶＢ４１０から業務データを受取り、そして請求書作成モジュール４５０及び決済モジュール４６０に通信される請求書作成イベントを生成する。請求書作成モジュール４５０は業務マネージャ４４０から請求書作成イベントを受取り、そして加入者に請求書を生成する。決済モジュール４６０は、上で述べたように、業務マネージャ４４０から請求書作成イベントを受取り、キャリアに送り状を送り、そして内容プロバイダ（content provider）（例えば、請求されたアプリケーション／内容／サービスのソース）に支払う。従って、ＳＶＢ４１０は請求書作成システム４００の外部の業務の請求書を作成し、且つ決済を行い、そして無線加入者請求書作成システム４００の使用はアプリケーション・ダウンロード及び／またはキャリア関連サービスの請求書作成及び決済に限定されない。

信用サービスからのＳＶＢ準拠請求書作成イベントはキャリア・ネットワーク中もしくは加入者のクライアント・デバイスから直接生成されないので、ＳＩＤマップ・データベース４２０は加入者を一意的に識別するためにＳＶＢによって使用される。例えば、加入者はそれらの移動電話帳（ダイアル可能）番号（ＭＤＮ）、もしくは信用サービス４９０においてキャリアによって既知の他の割当てられた固有番号を使用するであろう。ＭＤＮ（もしくは、他の固有番号）はＳＶＢ４１０へＳＩＤとして請求書作成要求と共に伝送される。ＳＶＢ４１０はそれからＳＩＤマップ・データベース４２０にアクセスし、そしてＭＤＮを置換し、或いは請求書作成要求及び業務を処理するためにＭＤＮを請求書作成システムにおいて使用される固有のＳＩＤと関連させる。

その上、項目について購入された／請求書を作成された項目はＡＤＳ及び／またはキャリア・ネットワークを通して配分されたアプリケーションまたは内容ではない。従って、請求書作成要求は項目説明、小売り価格、購入時間／日付、等々に関する追加情報を含む。しかしながら、この追加情報の少なくとも一部はまたデータベースに組込み済みであり、そして項目ＩＤ及び／またはプロバイダ／受取人ＩＤ（例えば、信用ソース）に基づいてアクセスされる。

請求書作成要求に含まれる情報は請求書作成及び追跡業務のために使用される様々なデータを含む。例えば、請求書作成要求に含まれる情報は信用サービスで購入された項目（例えば、アプリケーション、内容、品物及び／またはサービス）の唯一の識別子を表すために信用サービスによって指定される項目ＩＤを含む。それは項目に関する請求書作成部分番号であると考えられる。しかしながら、項目ＩＤは信用サービスを通して唯一であるという保証はないので、それは唯一性を維持するためにプロバイダ／受取人ＩＤ（それは信用サービスである）によって参照される。顧客（Customer）ＩＤは作業者の加入者ＩＤ（ＳＩＤ）、または作業者／キャリアのＳＩＤと関係する他の固有のＩＤである。顧客ＩＤ形式は請求書作成情報に含まれる（例えば、ＳＩＤ、ＭＤＮ）。署名は発行されたディジタル証明書の秘密鍵を用いて、信用サービスによってディジタル的に署名された全てのデータの連結文字列（concatenated string）である。信用サービス鍵の対からのディジタル証明書は要求を認証するためにＳＶＢに関して使用される。受取人ＩＤは標準収入分け前（例えば、キャリア、決済本体、及び内容提供者の間で分割された収入）の内容部分を支払われるプロバイダ／内容受取人を表し、そしてその項目について出版者／開発者／製造者に同等である。多くの状況において、受取人ＩＤは信用サービスである。

購入のグリニッジ標準時（ＧＭＴ）刻印が含まれる。現地時間を計算するためにそのずれ（オフセット）を表すＧＭＴオフセットが含まれる。クライアント業務ＩＤは請求書作成／業務要求のための唯一の識別子を表す。それはこの業務がまだ受取られなかったことを検査する（二重請求書作成を防ぐため二重検査する）ために使用される。キャリアＩＤはシステムにおける副作業者ＩＤを表す（例えば、それはＢＲＥＷキャリアＩＤ及び一次キャリア（Primary Carrier）に同等である）。前払いフラグは末端ユーザーが作業者にとって前払い顧客であるか否かを示す。小売価格（Retail Price）は内容請求イベントの顧客料金を表す。内容料金（Content Fee）は価格決定規約に従って内容受取人支払いを決定するために使用される価値を示す。殆どの場合、それは小売り価格と同じである。通貨（currency）コードは表示価格、内容料金、及び業務において指定されたソース料金額の通貨を示す。請求書作成説明書はキャリアに送られる報告書（例えば、請求書作成ＸＭＬ供給）及び開発者に利用可能な報告書（例えば、開発者ＸＭＬ供給）に含まれ、そして顧客請求書作成説明書に現れる内容項目の短い説明を表す。それはこの項目に関する請求書作成部分名と同等である。長い説明書は（例えば、顧客サービスに関する）業務をさらに説明するために使用される金額請求内容の長い名前を表すが、一般的に請求書作成抜粋ＸＭＬ及び開発者抜粋ＸＭＬ（即ち、開発者への報告）に含まれない。製造供給元（Vendor）データは請求書作成業務によって渡される信用サービスによって使用される追加データを表す。製造供給元データは請求書作成及び開発者報告書に含まれる。開始再帰請求書作成インタフェースに関する情報は加入請求書作成を始動する日を（例えば、ＭＭ／ＤＤ／ＹＹＹＹフォーマットで）示す開始請求書日付を含む。開始請求書日付が将来であれば、請求書作成を始動する最初の金額請求書作成（ＩＢ）イベントは開始請求書日付まで起こらない。最終請求書日付は加入の最終日付を（例えば、ＭＭ／ＤＤ／ＹＹＹＹフォーマットで）示す。ＩＢイベントは最終請求書日付の後は起らない。

請求書作成要求に含まれ、且つ／または請求書作成イベントと関連する任意の請求書作成情報の前記説明は例示のためだけに行われた。請求書作成要求は上で述べた全ての情報がなくても処理され、同様に記載されなかった追加情報は請求書作成イベントを追跡し、且つ報告する目的のために加えられるであろう。従って、請求書作成要求及び請求書作成イベントを生成するための関連情報は購入項目のキャリア及びプロバイダによって望まれるように変えられことを当業者は理解するであろう。

ＳＶＢ４１０を使用して、請求書作成システム４００は信用サービス４９０（即ち、請求書生成の公認ソース）からの窓口請求書作成サービスとして実質的に機能している。信用サービス４９０は：業務（例えば、ＳＯＡＰ（簡単なオブジェクト・アクセス・プロトコル）インタフェース）を造出すること、安全性を提供すること、正当な業務属性（例えば、上で述べた請求書作成情報）を設定すること、業務を請求書作成システム４００に提示すること、請求書作成システム４００からの応答を処理すること、及び必要とされる業務を再提示することを含むサービス金額業務管理に関して責を負う。信用サービス４９０は作業者または他の保証業務処理によって発行されたディジタル証明書を使用してＳＶＢ４１０へ各業務（例えば、ディジタル的に各業務に署名する）に関して認証を行う。ＳＶＢ４１０はそれから信用サービ４９０からの要求を認証し、要求を正当化し、金額請求書作成作業者インタフェースを支援し、そして正当な要求（例えば、業務データ）をＴＸＮ４４０へ通信する。ＳＶＢ４１０は無効の要求を識別するために誤りコードを返す。ＴＸＮ４４０は二重イベント検査、請求書作成業務の変換処理、再帰内容金額請求書作成の写像及び処理に対応し、そして金額請求書作成イベントを請求書作成モジュール４５０及び決済モジュール４６０へ通信する。

ＳＶＢ４１０は多数の作業者インタフェースに対応する。例えば、ユーザー認証インタフェースはＳＩＤがＳＶＢサービスについて認可されることを証明するために使用される。業務確認インタフェース（例えば、確認論理４３０）は作業者が請求書作成情報（即ち、Ｘを超えない内容料金、有効な顧客ＩＤ、等）の追加確認を実施するために使用される。前納インタフェースは価値請求書作成に関する前納認証（例えば、前納収支を検査する）及び借方サービスを開始するために使用される。これらのインタフェースは個別モジュールとして実現され、或いは一般の論理モジュール（例えば、確認論理４３０）に全て含まれる。

従来の無線システムにおけるアプリケーション購入はキャリア／作業者によって制御され、そして一般的に（例えば、ＡＤＳによって提示されたように）アプリケーションを閲覧し、上で述べたように、キャリア・ネットワークからアプリケーションを選択し、且つダウンロードするクライアント・デバイスに基づいている。業務は発明の背景及び先述の開示において述べたように記憶され、請求書が作成され、そして決済される。

しかしながら、請求書作成システムにおけるＳＶＢサービスの追加はキャリア・ネットワークからの直接購入に加えて代替購入（ＡｌｔＢｕｙ）ソースを可能にする。図５を参照すると、ＳＩＤ向け（或いは、クライアント・デバイス向け）の配分構造は遠隔クライアント・デバイスへの項目（例えば、アプリケーション、内容等）の指示配送を可能にする。従来のダウンロード処理におけるように、購入されたアプリケーション及び／または内容がクライアント・デバイスからのダウンロードに利用可能であり、そしてダウンロード・イベントが加入者への追加請求書作成を全く生成しないように、このＳＩＤ向け構造はキャリア・オフラインから購入されたアプリケーション及び／または内容がＳＩＤと関連することを可能にする。

例えば、主カタログ５１０はキャリア／作業者からの購入に利用可能な複数の項目（例えば、アプリケーション、内容、サービス等 )を含む。ただ一つのＳＩＤ（例えば、ＭｙＡｐｐｓグループ）だけを含むＳＩＤ向けグループ５４０が形成され、それはそのＳＩＤ（クライアント・デバイス）に特に指示された項目を含む。従って、クライアント・デバイス３００のショッピング・カタログ５５０は、従来の方法において（例えば、主カタログ５１０からのフォルダ／項目を使用して）、プラットフォームＩＤ、ランＡＰＩ、及び言語に基づいて生成される。しかしながら、ショッピング・カタログ５５０はＳＩＤ向けグループ５４０、及びクライアント・デバイス３００と関連するＳＩＤに基づいてショッピング・カタログ５５０におけるＳＩＤと関連する項目（例えば、ＭｙＡｐｐｓ）だけ増大する。従って、ショッピング・カタログ５５０は各ＳＩＤについてカスタム化可能であり、そしてＳＩＤ向けグループ５４０はＡｌｔＢｕｙを介して購入された項目を配送するために使用される。

個別のグループにおいて項目を提示することに加えて、差別化価格決定が同じ項目について使用される。例えば、主カタログ５１０における項目５（例えば、アプリケーション）は＄１０．００の正規商品価格で提供される。しかしながら、同じ項目５は無料で提供されるＳＩＤ向けグループ５４０（例えば、ＭｙＡｐｐｓ）に含まれる。例えば、項目５はＡｌｔＢｕｙを介して購入されたか、もしくは別の加入者からの贈物である。従って、購入／請求書作成／決済処理は従来のダウンロード開始の請求書作成イベントと異なり購入された項目の配送から分離される。

無線加入者請求書作成システムへの外部の請求書作成チャネル（例えば、ＳＶＢ４１０）は外部の購入業務が無線加入者請求書作成システムによって処理されるのを可能にする。いくつかの購入は映画への切符を購入するといった、クライアント・デバイスへいくらか関連するダウンロードまたは強化なしで処理される。しかしながら、無線システム上のクライアント・デバイス向けのキャリア・カタログから項目を購入する（例えば、アプリケーション、アプリケーション購入、呼出音購入等の機構をダウンロードし、もしくは強化する）ことを含む他の形式の外部業務が処理される。一般に、クライアント・デバイス向けであるが、クライアント・デバイスによるキャリア・ネットワークにおけるサーバ業務に対して従来のクライアント・デバイスの中で生成されないこの形式の業務は下記の記述では「代替購入（alternate buy）」または「ＡｌｔＢｕｙ」と言われる。

ＡｌｔＢｕｙ領域６１０は小売店６１２（例えば、作業者／第三者販売カード、キオスク）、ＰＣ／Ｗｅｂ準拠６１４（作業者／第三者Ｗｅｂサイト、購入が無線クライアント３００について関連するゲームについて行われるゲームのようにＰＣアプリケーション内から直接的に）、マス・メディア６１６（例えば、広告関連、等々）といった、様々なチャネルを含む。ＡｌｔＢｕｙは請求書作成についてＳＶＢ４１０を利用し、ＳＩＤに関連するクライアント・デバイス３００への内容／アプリケーションの配送についてＳＩＤに基づくグループ機能（例えば、ＭｙＡｐｐｓ５４０）を利用する。

例えば、販売カードは一以上のアプリケーションを加入者に提供する作業者または第三者の小売販売店のいずれかにおいて販売されたカードである。購入者は自分でカードを利用するか、もしくは別の加入者にカードを贈呈する。一つのカード上の多数のアプリケーションの購入はアプリケーションの購入価格に割引を含む。贈物の購入または受取りの後、加入者はカードを登録し、その時点でアプリケーション（例えば、ＢＲＥＷアプリケーション）はダウンロードまたは自動インストールのためにそれらのＳＩＤ向けグループ（例えば、ＭｙＡｐｐｓ要覧）に搭載される。さらに、加入者に請求書を送り（前納されなければ随意である）、且つ全てのアプリケーション及びサービス・プロバイダとの決済を行う業務処理は完了する。

カタログ提供をまねた作業者／第三者のウェブ提供が提示され、そして恐らくは多数のアプリケーションの購入について或いは限られた時間提供の間に或る提供物の購入についていくらかの割引価格決定を組込むことができる。ウェブ・サイトＡｌｔＢｕｙｓはアプリケーション及び内容を個々に提供し、或いは製品及びサービス項目を纏めて提供する。例えば、加入者（或いは、贈呈者）は目的加入者のデバイス（例えば、ＭＤＮ）に関する情報を提供し、そして作業者／第三者（即ち、信用サービス）はＳＶＢ４１０インタフェースを介して加入者請求書作成及び内容プロバイダ支払いに関する情報を提供する。

作業者または第三者の売店（kiosks）は主カタログ提供をまねて、そして多数のアプリケーションの購入について、或いは限られた時間提供の間に或るアプリケーションの購入についていくらかの割引価格決定を恐らくは組込むアプリケーション購入能力を持つ。加入者は目的の加入者のデバイス（例えば、クライアント・デバイス３００）に関する情報を提供し、そして作業者または第三者はそのデバイスへ（例えば、ＭｙＡｐｐｓを介して）購入アプリケーションの配分を指示し、そして加入者請求書作成及び内容及びサービス・プロバイダ支払いに関する情報を提供する。

広告回線はアプリケーションを作業者の加入者に提示する。例えば、これらは加入者に請求できない。加入者は目的の加入者のデバイスに関する情報を提供し、そして作業者及び第三者はユーザーダウンロードのために（例えば、ＭｙＡｐｐｓを介して）そのデバイスへのアプリケーションの配分を指示する。

前に述べたように、ＡｌｔＢｕｙはアプリケーション／内容を購入させ、且つ加入者に配送するために様々な異なるチャネルを提供する。これらの各々の構成において、請求書作成及び配送情報は適切な配送及び請求書作成を可能にするためにＳＶＢ４１０及びグループ・マネージャ５１５に通信される。従って、請求書作成及び配送メタデータはＳＶＢ４１０に通信される請求書作成要求の一部として伝送される。

例えば、アプリケーションはキャリア・ネットワーク／請求書作成システムの外で（例えば、作業者売店において現金、クレジット・カード）で購入される。請求書作成及び配分要求は信用サービス（例えば、ＡｌｔＢｕｙ領域６１０）からＳＶＢ４１０へ通信される。その業務が代替購入であり、且つ特価決定基準（例えば、加入者が請求されないように、ＣＬＰ＝０）を持つこと示す請求書作成要求と共に特価ハンドルが含まれる。ＳＩＤは配送（例えば、ＭｙＡｐｐｓ）を対象にするために使用される。一般に、ＡｌｔＢｕｙサービスは請求書作成及び配分要求をフォーマットし、且つ提示し、戻りイベント情報を処理し、そして誤りインスタンスを処理する。請求書作成／配布要求はＳＶＢ業務であり、そして配布要求はグループ・マネージャ向け（ＳＩＤ向け）アプリケーション要求である。要求と共に含まれるメタデータ（情報）は、例えば、ＡｌｔＢｕｙと関連する各アプリケーションに関する配分ＩＤ、項目ＩＤ、価格処理、価格方法、価格基準、価格金額、製造販売者データ、及びソース形式を含む。

ＡｌｔＢｕｙ配送表６２０はＡｌｔＢｕｙソース（例えば、６１０）から渡されたメタデータからのデータを投入される。例えば、その表はＳＩＤ（例えば、配分ＳＩＤ）、項目ＩＤ、用法、価格ハンドラー、ＣＬＰフィールドを含む。上で述べたシナリオでは、そこではそのアプリケーションはＡｌｔＢｕｙ領域において代金が支払われ、ＣＬＰ＝０であったが、この情報はＳＩＤ及び項目ＩＤと関連し、ＳＩＤ向けグループ５４０（例えば、ＭｙＡｐｐｓ）と関連する。ＳＩＤと関連するクライアント・デバイス３００がＡＤＳ１０６によって生成されたショッピング・カタログ５５０からのＳＩＤ向け（ＭｙＡｐｐｓ）グループへアクセスするとき、提示された項目の一つ（例えば、アプリケーション）はＡｌｔＢｕｙを介して購入された項目である。

ＡＤＳ１０６はＡｌｔＢｕｙ表６２０にアクセスし、そしてＳＩＤ及び項目ＩＤと関連するＡｌｔＢｕｙ価格ハンドルがあるかどうかを判定する。ＡＤＳはそれからＡｌｔＢｕｙ表６２０からの局所価格ハンドルを持つ項目ＩＤと関連する提供価格ハンドルを交換する。価格がゼロであると仮定すると、＄０．００または「無料である（Ｆｒｅｅ）」（或いは、他の言語特定表示）の掲示がクライアント・デバイス３００に表示される。局所価格ハンドルがあれば、作業者及び開発者の最小額を保証するＡｌｔＢｕｙ業務は適用せず、顧客請求書作成は適用されず、そして開発者／内容プロバイダ決済は処理されないか、或いはゼロ金額で処理されるので、ＡＤＳ１０６は業務を識別する。ＡＤＳ１０６はダウンロード要求を処理し、そしてゼロ金額で業務データを生成し、そして上で述べたように、業務データを業務処理、請求書作成及び決済モジュールに渡す。しかしながら、請求書作成及び決済はＳＶＢを介してＡｌｔＢｕｙ領域で行われたので、請求書作成と決済の両方はゼロであろう（ＣＬＰ＝０、ＤＡＰ＝０、但しＤＡＰは開発者／内容プロバイダへの支払いである）。しかしながら、業務に関係する他の情報は作業者及び／または開発者報告を投入するために、このダウンロード・イベントに関して維持される。例えば、その情報はダウンロードされた実際のアプリケーション、ダウンロードの日付、等々の追跡において有用であり、そして販売及び／または顧客サービスに関してＳＩＤ及びクライアント・デバイスと関連させることができる。

別の典型的な実施例では、ＡｌｔＢｕｙ購入は特価（例えば、低価格またはゼロ価格促進）のために一時の、または限られたダウンロード数について作業者の売店から行われる。上で述べたように、ＡｌｔＢｕｙ配送表６２０はＳＩＤと関連するクライアント・デバイスが特別な価格決定（例えば、ＣＬＰ＝０）でアプリケーションをダウンロードすることを可能にするために初めに設定される。前に述べたように、特別な価格決定ハンドル及び価格レベルは請求書作成システムを介して伝搬される。しかしながら、ＡｌｔＢｕｙ配送表６２０における価格決定、項目ＩＤ及び他のデータに加えて、ダウンロード指標が記憶される。従って、一旦その項目が（例えば、ＡＤＳ１０６を介して）ダウンロードされると、項目ＩＤライセンスがＳＩＤに配送され、そのライセンスの状態は配送された状態に設定される。記録は項目ＩＤについて利用可能な各ダウンロード可能なライセンスについて保持される。項目ＩＤライセンスがＳＩＤに配送されるとき、そのライセンスの状態は配送された状態に設定される。従って、ダウンロード指標／配送状態はその項目が配送されたこと、及びＡｌｔＢｕｙ配送表６２０から取除かれる（もしくは機能的にダウンロード指標フィールドへ論理検査を介して取除かれる ) ことを示す。同様に、項目はＳＩＤ向け（ＭｙＡｐｐｓ）グループ５４０からは見えない。従って、いずれかの場合に、項目が再びダウンロードされれば、それは主カタログ５１０において定義された標準価格レベルで提供される。従って、標準商品項目価格決定はアプリケーション、内容及び／またはサービスの促進、且つ売買における柔軟性を加えるために無線請求書作成システムにおいてＡｌｔＢｕｙ価格決定と混合される。
ＡｌｔＢｕｙシナリオにおいて、請求書作成及び配分情報はＡｌｔＢｕｙ領域６１０（例えば、作業者売店）において生成される。請求書作成及び配分情報はＳＶＢ４１０及びグループ・マネージャ５１５に通信される。少なくとも情報（メタデータ）の一部は転送され、そしてシステムが業務を一つのＡｌｔＢｕｙ業務ＩＤと関係づけることを可能にするために請求書作成及びダウンロード業務を通じて記憶される。例えば、業務メタデータはＳＶＢ業務によって生成され、搬送される。このメタデータは、例えば、グループ・マネージャ５１５、ＡＤＳ１０６または他のサーバまたは論理を用いて、ＳＩＤ向けグループ５４０に付加される項目ＩＤと共に記憶される。メタデータはダウンロード要求に基づいてクライアント・デバイスに渡される。さらに、メタデータは業務マネージャＴＸＮによる間接用法記録に含まれる。

ＡｌｔＢｕｙ業務はＴＸＮにおいて多数の業務データ（例えば、ＳＶＢ請求書作成要求と関連する第一の業務データ、及びクライアント・デバイスへの内容の実際の配送（例えば、押込み／引出し）と関連する第二の業務データ）を生成する。従って、関連の業務の終端間追跡（end-to-end tracking）が達成されるように追跡ＩＤが業務処理を通して使用される。このように、追跡ＩＤはＡｌｔＢｕｙ請求書作成要求と共に含まれ、そして第一の業務データは請求書作成要求に基づいて生成される。業務データは第一の業務データに基づいて、加入者請求書を生成し、支払いを項目のプロバイダに配分し、且つ／または報告データを伝送するために請求書作成システム（例えば、ＴＸＮ、請求書作成及び決済モジュール）を通して処理される。追跡ＩＤを含む第一の業務データは後での再生、調整、顧客サービス等のためにデータベースに記憶される。

上記で述べたように、ＡｌｔＢｕｙ業務における内容の配送は請求書作成要求から別に発生し、或いは（例えば、内容が配送されなければ）全く発生しない。従って、内容が配送されれば、その内容は主カタログからクライアント・デバイスと関連するＳＩＤ向けグループへ付加される。追跡ＩＤはまたＳＩＤ向けグループにおける内容と関連している。ＳＩＤ向けグループからの内容がクライアント・デバイスにダウンロードされるとき、追跡ＩＤはまたクライアント・デバイスに渡される。同様に、第二の業務データは追跡ＩＤを含む内容のダウンロードに基づいて生成され、前に述べたように、残りの請求書作成、決済且つ／または報告処理によって処理される。追跡ＩＤを含む第二の業務データはまた後での再生、調整、顧客サービス、等々のために記憶される。従って、ＡｌｔＢｕｙ業務は終端間で（ＡｌｔＢｕｙ販売からアプリケーションのダウンロード及び業務請求書作成及び決済まで）写像され、且つ管理される。終端間でこれらの業務を追跡することができることはＡｌｔＢｕｙ販売チャネルに関するビジネス知能及びアプリケーション配分浸透の増加を可能にする。例えば、追跡ＩＤの使用によって、キャリアは購入されたアプリケーション／内容に対して如何に多くのＡｌｔＢｕｙダウンロードが行使されたかを得ることができる。これはＡｌｔＢｕｙ関連のダウンロードのためのＴＸＮ仲介／変換処理によって達成される。ＴＸＮは仲介用法記録に追跡ＩＤの変換を含めるために局所価格ハンドルを使用する。追跡ＩＤはダウンロード・イベントをＳＶＢ請求書作成イベントと関連させるために使用される。追跡ＩＤは仲介用法記録に含まれるので、それはまたキャリア請求書作成及びデータ倉入れ決済策に統合される請求書作成報告に含まれる。

本発明の別の実施例では、図７に例示したように、業務は多数の開発者／出版者／製造販売者／ソース（７５２、７５４、７５６）を含む。例えば、ＡｌｔＢｕｙシナリオにおいては、アプリケーションは一般の業務において纏められて売られる（例えば、小売りゲーム・パック）。前述の開示から理解できるように、ＳＶＢは請求書作成業務のために使用され、そしてグループ配分は請求された内容を配分するために使用される。従って、ＳＶＢ４１０は、ソース内容プロバイダである、多数の第三者のソース受取人７５４、７５６に基づいて、各ソース受取人７５４、７５６に関連するソース説明及びソース料金によって支払い決済を指定するために構成される。開発者及び／または内容受取人７５２に加え、ソース受取人７５４、７５６も支払いを得る。即ち、内容受取人７５２は収入分け前分割の内容の一部を支払われる（内容料金の１００％であるかもしれない）。ソース受取人支払いは内容料金から処理される（即ち、一般的にソース料金は内容料金に加えない）。さらに、ソース受取人７５４、７５６は開発者、出版者、または他の内容プロバイダのこともある。例えば、アプリケーション束の意味では、ソース受取人７５４、７５６はその束に含まれるアプリケーションを開発した個々の開発者でもある。内容料金は各開発者と取決めた料金に加えて内容受取人７５２（例えば、纏め人／販売人）の追加料金の合計である。複数決済（例えば、支払い配分）はソース受取人拡張決済イベントとして実施される。ＳＶＢ４１０は既知の内容受取人７５２及びその認定されたどの複数ソース受取人７５４、７５６への支払いに対応する。

従って、複数決済のために、追加のソース受取人７５４、７５６情報が請求書作成システムにおいて、或いはＡｌｔＢｕｙソースによって生成された請求書作成要求に含まれる。例えば、少なくとも一つのソース受取人ＩＤが含まれる。ソース受取人ＩＤは内容の少なくとも一部を供給した第三者受取人（ソース受取人）を表す。第三者受取人は内容受取人７５２支払いのいくらかの部分を支払われる。ソース受取人７５４によって提供される内容の短い説明を表すソース説明が含まれる。ソース料金は内容受取人支払いの第三者受取人部分を表す各ソース受取人ＩＤについて提供される。この追加情報は業務によって渡される請求書作成メタデータに含まれる。従って、無線加入者請求書作成システムはさらに自動的に請求書を活用され、且つ多数の第三者内容プロバイダ／ソースを含む業務を決済される。

例えば、無線加入者請求書作成システムにおける複数の請求書作成イベントを処理する際に、請求書作成イベントは（例えば、信用サービス４９０からの要求に基づいて）内容受取人７５２、内容料金、及び業務に関連する少なくとも一人のソース受取人７５４、７５６及びソース料金を含めて生成される。業務は支払いを（例えば、決済モジュール４６０を介して）内容受取人７５２及び少なくとも一人のソース受取人７５４、７５６に配分するために処理される。内容受取人７５２及び少なくとも一人のソース受取人７５４、７５６の支払いに関係する業務データは（例えば、ＴＸＮ４４０または請求書作成システムに動作可能に結合された他のデータベースに）後の処理（例えば、顧客サービス、販売／営業データ・マイニング、等々）のために記憶される。上で述べたように、内容料金はソース料金の合計を上回るか、或いは等しい。さらに、業務データの記憶に加えて、そのデータの少なくとも一部は（例えば、決済モジュール４６０によって）内容受取人７５２及び／または各ソース受取人７５４、７５６へ業務報告データとして伝送される。例えば、開発者は請求書作成及び配分システムから送られた業務報告データを用いて一纏めしたことに関するアプリケーション販売を追跡することを望む。同じく、上で述べたように、請求書作成イベントは（例えば、請求書作成モジュール４５０を介して）一般的に内容配送の小売価格（例えば、ＣＬＰ）に基づき生成される、或いは配送のため予定される加入者請求書に至るであろう。小売価格は一般的に内容料金を上回るか、或いは等しい。

一旦、業務データが記憶されると、それは上で述べたように様々な目的のために使用される。そのような一つの使用は顧客関係管理（ＣＲＭ）サービスにある。図７に例示したように、作業者７１０は請求書作成モジュール４５０及び決済モジュール４６０から請求書作成情報（例えば、内容及びソース受取人７５４、７５６内容料金の一部に関する送り状）を受取る。従って、作業者７１０はＣＲＭ目的に利用可能なこの情報を持つであろう。加入者が作業者の小売販売店を通して購入したアプリケーション束に満足しなかったと仮定しよう。この形式の業務（アプリケーション束の購入）は一般的に束に含まれるアプリケーションの多数の開発者を有するので、複数決済がアプリケーション束購入業務の決済において行われてきた。そこで、支払い価格は購入価格の２０パーセントにするとＣＲＭ呼出センタまたはマネージャ７２０が決定すると推測しよう。請求書作成システムへのＣＲＭインタフェース７３０は記憶業務データにアクセスし、そして記憶業務データに基づいてマイナス内容料金及び少なくとも一つのマイナス・ソース料金を含む調整業務を生成する。部分調整のために、システムは比例して全ての複数決済ソース受取人を調整するであろう。

従って、ＳＩＤ、業務追跡ＩＤ、等々を使用して、アプリケーション束購入に関連する業務データがアクセスされる。マイナス内容料金及び少なくとも一つのマイナス・ソース料金は調整百分率（percentage）、及び内容受取人及び少なくとも一つのソース料金受取人７５４、７５６の支払いに関係する業務データに基づいている。例えば、ＣＲＭインタフェース７３０はＣＲＭ７２０からの調整量または百分率（例えば、−２０％）を受取ることができる。ＣＲＭインタフェース７３０は元の業務データにアクセスし、その後、内容受取人７５２及び各ソース受取人７５４、７５６に関するマイナス支払い（例えば、内容料金及びソース料金の２０％）を生成する。調整百分率は制限されないが、例えば１から１００パーセント（即ち、全額返金）の範囲である。さらに、加入者クレジットがまた調整百分率、及び内容の表示価格に基づいて生成される。従って、加入者への２０パーセント返済は比例する２０パーセント借方を受取る元の購入（例えば、キャリア／作業者７１０、内容受取人７５２、ソース受取人７５４、７５６）において各受取人にもたらされる。これはマイナス請求書作成イベントを生成するＣＲＭインタフェースによって達成され、そしてそれは請求書作成システムを通して渡され、前述の説明において述べた請求書作成イベントと同様の方法で決済される。このように、複数決済システムのＣＲＭインタフェース７３０は無線加入者請求書作成システムを通じて決済された多数の第三者業務の自動調整を可能にする。さらにまた、調整業務データは作業者７１０、内容受取人７５２及び／またはソース受取人７５４、７５６への報告データを生成するために記憶され、且つ／または使用される。

図７に関連する前述の例はＳＶＢ購入に関して複数決済及びＣＲＭサービスを述べているけれども、本発明の実施例はこの構成に限定されない。アプリケーション、内容及び／またはサービスを提供する多数の相手を含んでいたどんな業務（例えば、クライアント・デバイスからのアプリケーションのダウンロード）も前節に述べた前述の複数決済システムを用いて決済される。同様に、請求書作成イベントの起因に関係なく、ＣＲＭ７２０によって行われたいかなる調整もどんな請求書作成イベントに適用される。

前述の開示を考慮して、本発明の実施例が一連の行為、動作及び／または前に述べた機能を実行する方法を含むことを当業者は認識するであろう。例えば、図８を参照すると、本発明の実施例による方法が例示される。請求書作成要求は信用サービス（例えば、小売店、ウェブサイト、等々）において生成される（ブロック８１０）。請求書作成情報を含む請求書作成要求は無線加入者請求書作成システムに通信される（ブロック８２０）。上で述べたように、通信は遠隔信用サービス（例えば、インターネット、ＬＡＮ、ＷＡＮ、無線接続、等々）への有線及び／または無線通信のいくつかの手段である。請求書作成要求に対する確認応答は無線加入者請求書作成システムにおいて生成され（ブロック８３０）、そして信用サービスへ通信される（ブロック８４０）。信用サービスは不正な請求書作成イベントが処理されないことを保証するために、請求書作成要求を処理する前に認証される（ブロック８２５）。上で述べたように、信用サービスからの請求書作成要求の伝送を認証することの一部として請求書作成要求を伝送する前に、請求書作成要求はディジタル的に署名される。

その上、前に述べたように、請求書作成要求における請求書作成情報は加入者ＩＤ、プロバイダＩＤ／内容受取人、内容／項目ＩＤ、小売価格、及び／または請求書作成説明といった業務を処理し、そして追跡するために使用される様々な情報を含む。しかしながら、当業者には理解されるように、全てのこれらのフィールドが必要であるのではなく、或いはこれが使用される可能なフィールドの完全な一覧ではない。例えば、加入者ＩＤへの請求書及び加入者ＩＤへ配送は贈物形式のシナリオにおける請求書作成要求において定義される。代りに、加入者ＩＤは業務の形式に応じてＩＤへの請求書、或いは配送を単に表す。例えば、ＳＶＢは無線加入者システムの外部の項目／サービスを購入するために使用されるが、無線加入者に請求書を送り、そして業務を決済するために無線加入者請求書作成システムを使用する。代りに、上記で述べたＡｌｔＢｕｙの例では、無線加入者システムにおいて利用可能な項目（例えば、アプリケーション、内容、サービス、等々）は無線加入者システムの外部で購入され、そしてＳＩＤはデバイス／加入者への配送を識別する目的のために使用される（例えば、アプリケーションはゼロ価格水準でダウンロードに利用可能であろう）。従って、請求書作成要求に含まれ、或いは請求書作成イベントと後で関連する情報は業務の形式、及び業務に含まれる相手（例えば、作業者、プロバイダ）の特定の好みといった、多くの要素に基づいて変化する。

図８を参照すると、確認応答が受取られた後、それは信用サービスにおいて処理される（ブロック８５０）。確認応答の処理はまた業務の形式に応じて変化する。例えば、無線システムの外部の購入について無線加入者に請求書を送るために無線加入者請求書作成システムを使用しているＳＶＢ業務において、その応答は一般的に承認または拒否であり、そして承認が得られない限り、購入項目（例えば、サービス、品物、等々）は提供されないであろう。しかしながら、ＡｌｔＢｕｙシナリオでは、項目は無線加入者システムの外部で購入され、そして項目は一般的に無線加入者システムを介して配送されているので、確認応答は要求が受取られることのまさに承認である。どちらのシナリオにおいても、確認応答が受取られず、且つ二重業務が容易に識別できるように請求書作成要求における追跡ＩＤを関連させることによって個別の業務と区別できれば、追加の要求が生成される。

図９を参照すると、例えば、請求書作成要求がＡｌｔＢｕｙシナリオにおいて認められた後、（例えば、主／商業カタログにおいて）無線キャリアから利用可能な項目（例えば、アプリケーション）は請求書作成要求におけるＳＩＤに関連するデバイス／加入者に配送される。例えば、図９を参照すると、請求書作成要求と関連する項目は主カタログから請求書作成要求と関連する加入者ＩＤ向けグループ（ＳＩＤ向けグループ）へ付加される（ブロック９１０）。項目の配送を追跡するため、配送表における情報はＳＩＤ向けグループにおける項目と関連される（ブロック９２０）。その項目はそれから配送される（ブロック９２０）。例えば、その項目はクライアントからダウンロードされ、ＳＩＤ向けのグループからＳＩＤと関連するクライアント・デバイスへ入れられる。しかしながら、項目の配送は追加サービスの起動、メディアのストリーミングといった多くの形を取り、そしてクライアント・デバイスへのダウンロードに限定されない。

業務データは配送表における情報を使用して項目のダウンロードに関して生成され（ブロック９４０）、そして請求書作成イベントは業務データに基づいて生成される（ブロック９５０）。項目がＡｌｔＢｕｙシナリオにおいて支払われたならば、配送表における情報は項目に関してゼロ金額小売価格を含み、同様に業務データ及び請求書作成イベントはそれぞれ項目に関してゼロ金額小売価格を含む。従って、項目は配送され、そして配送は追跡され、且つ請求書作成システムを介して請求書を生成することなく加入者に報告される。代りに、その値はゼロより大きいが、主カタログにおける全小売価格より小さく、そして割引価格が請求書作成システム及び割引額を請求された加入者を介して処理される。

図１０を参照すると、上で述べたように、代替実施例は請求書作成要求と共に追跡ＩＤを含む（ブロック１０１０）。追跡ＩＤを含む第一の業務データは請求書作成要求に基づいて生成され、そして第一の業務データが処理される（例えば、加入者請求、プロバイダ支払い、及び／または報告書生成）（ブロック１０２０）。追跡ＩＤは後の再生及び他の業務による使用のために業務データと共に記憶される（ブロック１０３０）。請求書作成要求の主題である項目は主カタログからＳＩＤ／クライアント・デバイスと関連する加入者ＩＤ向け（ＳＩＤ向け）グループへ付加され、追跡ＩＤはＳＩＤ向けグループにおける項目に対して関連させられる（ブロック１０４０）。項目及び関連する追跡ＩＤはＳＩＤ向けグループから配送される（ブロック１０５０）。例えば、項目及び追跡ＩＤを含むメタデータはクライアント・デバイスにダウンロードされる。追跡ＩＤを含む第二の業務データは項目の配送に関して生成され、且つ処理される（ブロック１０６０）。第二の業務データは第一の業務データと同様の方法で請求書作成システムを介して処理され、そして追跡ＩＤは双方の業務を関連させるために使用される。

従って、ＳＶＢ生成請求書作成イベントに基づく追跡ＩＤを含む第一の業務はＡｌｔＢｕｙシナリオにおいて、アプリケーションの外部の購入のような業務の請求書作成及び決済をもたらす。業務及び追跡ＩＤメタデータは請求書作成システムに記憶される。アプリケーションが実際にクライアント・デバイスにダウンロードされるとき、追跡ＩＤはクライアント・デバイスに渡され、そして第二の業務がダウンロードに基づいて生成される。上で述べたように、第二の業務は配送表からの特別な価格決定ハンドルを含み、従って、加入者はダウンロードに関して請求されない。しかしながら、そのイベントは請求書作成システムを介して処理され、その結果、項目の配送は追跡され、そしてキャリア及び項目のプロバイダに報告される。さらにまた、追跡ＩＤは第二の業務データと共に含まれ、そして後の再生、報告、等々のために請求書作成システムに記憶される。従って、無線請求書作成システムの外部で生成された加入者購入／請求書作成要求は項目の決済及び配送を通して請求書作成要求から終端間で追跡される。

図１１に例示した別の実施例は無線加入者請求書作成システムにおける複数請求書作成イベントを処理する方法を含む。プロバイダ料金と受取人、及び業務と関連する少なくとも一つのソース料金と受取人を含む請求書作成イベントが生成される（ブロック１１１０）。例えば、出版者は無線加入者によるダウンロードのためにアプリケーション及び内容（例えば、音楽、ビデオ、等々）の組合せを含む項目を提供するであろう。上で述べたように、項目がクライアント・デバイスにダウンロードされるとき、請求書作成イベントが生成される。項目と関連するメタデータは無線加入者請求書作成システムを通して業務を処理する情報を含む。特に、情報は項目に関するプロバイダ受取人（例えば、出版者ＩＤ及び関連の情報 ) 及びそれらに関する料金（例えば、出版者が支払われる額）を含む。同様に、各ソース受取人（例えば、開発者ＩＤ、内容プロバイダＩＤ）に関する情報及び各ソースに関する料金（開発者がアプリケーションについて支払われ、そしてプロバイダが内容について支払われる額）は項目と関連する。従って、複数業務は請求書作成システムによって自動的に請求され、且つ決済され、例えば、業務は支払金をプロバイダ及び各ソース受取人へ配分するために処理される（ブロック１１２０）。

業務データはさらなる処理、データ・マイニング及びＣＲＭサービスのために記憶される（ブロック１１３０）。ＣＲＭ調整目的のために、記憶業務データはアクセスされる（ブロック１１４０）。記憶業務データに基づくマイナス・プロバイダ料金及び少なくとも一つのマイナス・ソース料金を含む調整業務が生成される（ブロック１１５０）。調整業務はマイナス・プロバイダ料金及び少なくとも一つのマイナス・ソース料金に基づいてプロバイダ受取人及び少なくとも一人のソース受取人の借方に記入するために処理される（ブロック１１６０）。調整業務は最初の複数業務から収入を得た各々の相手に比例する。同様に、加入者クレジットは調整比率及び項目の小売価格に基づいて生成される（ブロック１１７０）。例えば、項目はある小売価格で購入されると推測しよう。作業者、プロバイダ及びソースそれぞれは所定の（例えば、項目と関連するそれぞれの料金によって定められた）比率で小売価格から収入を得る。前に述べたように、無線加入者請求書作成システムは自動的に加入者に請求し、且つ項目と関連する料金に基づいてそれぞれの相手に支払い、そしてこの情報は後のアクセスのために記憶される。加入者が信用され、もしくは購入の一部を返済されるべきことを表すＣＲＭによる決定に関して、調整業務はマイナス請求書作成イベントとして処理される。このように、無線加入者請求書作成システムは記憶業務データにアクセスし、そして、元の業務から支払われるそれぞれの料金に比例して各相手（例えば、作業者、プロバイダ、及びソース）の借方に記入する。従って、その調整は請求書作成システムを通して自動的に伝搬し、そして全ての相手に配分され、それは決済及びＣＲＭサービスと共に手作業を著しく低減させる。

さらなる実施例において、前述の方法はコンピュータ・プラットフォームのメモリ等のコンピュータ可読媒体上に具現化されたプログラムの実行によって実施されることを当業者は理解するであろう。その命令は様々な形式の信号保持またはデータ記憶の一次、二次、または三次媒体に在駐する。その媒体は、例えば、クライアント・デバイス及び／またはサーバによってアクセス可能な、あるいはその中に在駐するＲＡＭを含む。ＲＡＭ、ディスケット、または他の二次記憶媒体に含まれるか否かに拘らず、その命令はＤＡＳＤ記憶（例えば、従来の「ハード・ドライブ」またはＲＡＩＤアレイ）、磁気テープ、電子読出専用メモリ（例えば、ＲＯＭまたはＥＥＰＲＯＭ）、フラッシュ・メモリー・カード、光記憶デバイス（例えば、ＣＤ-ＲＯＭ、ＷＯＲＭ、ＤＶＤ、ディジタル光テープ）、パンチカード、またはディジタル及びアナログ伝送媒体を含む他の適当なデータ記憶媒体などの様々なマシン可読データ記憶媒体上に記憶される。

前述の開示は本発明の例示実施例を示すものであるが、様々な変更及び修正が付随の請求項によって定義されたように発明の範囲から逸脱することなくこの中で行われることに注目すべきである。ここに記載した発明の実施例による方法請求項の機能、ステップ及び／または行為はいずれの特定の順序で実行する必要はない。さらに、発明の要素は単数で記載され、或いは請求されているけれども、単数の限定が明白に示されてない限り、複数も考慮される。

本発明の少なくとも一つの実施例によるクライアント・デバイス及びサーバに対応する無線ネットワーク・アーキテクチャの図である。本発明の少なくとも一つの実施例によるクライアント・デバイス及びサーバに対応する無線ネットワーク・アーキテクチャのさらに詳細な図である。本発明の少なくとも一つの実施例によるアプリケーション額（value）請求書作成システムのシステム・レベルの実例である。本発明の少なくとも一つの実施例によるサービス額（value）請求書作成システムのシステム・レベルの実例である。本発明の少なくとも一つの実施例によるグループ配分システムのシステム・レベルの実例である。本発明の少なくとも一つの実施例によるシステム要素を含む別の購入処理のシステム・レベルの実例である。本発明の少なくとも一つの実施例による複数加入者（multi-party）決済及びＣＲＭシステムのシステム・レベルの実例である。本発明の実施例による方法を例示するフローチャートである。本発明の実施例による方法を例示するフローチャートである。本発明の実施例による方法を例示するフローチャートである。本発明の実施例による方法を例示するフローチャートである。

Claims

信用サービス（４９０）において、クライアント・デバイス（３００）と関連する請求書作成要求を生成すること、
請求書作成情報を含む請求書作成要求を無線加入者請求書作成システムへ通信すること、
無線加入者請求書作成システムにおける請求書作成要求に対する確認応答を生成すること、
信用サービス（４９０）へ確認応答を通信すること、
主カタログからクライアント・デバイス（３００）において指示されるグループを造出すること、及び
少なくとも一つの項目を含むグループをクライアント・デバイス（３００）に提示することを含む方法。
請求書作成要求を処理する前に信用サービス（４９０）を認証することをさらに含む、請求項１記載の方法。
請求書作成要求を伝送する前に信用サービス（４９０）において請求書作成要求を署名することをさらに含む、請求項１記載の方法。
請求書作成情報は加入者ＩＤ、プロバイダ受取人、項目ＩＤ、小売価格、及び請求書作成説明の少なくとも一つを含む、請求項１記載の方法。
無効である請求書作成要求に応答して誤りコードを返送することさらに含む、請求項１記載の方法。
信用サービス（４９０）において確認応答を処理することをさらに含む、請求項１記載の方法。
（削除）
グループから少なくとも一つの項目を配送することをさらに含む、請求項１記載の方法。
配送表中の情報をグループ中の少なくとも一つの項目と関連させることをさらに含む、請求項１記載の方法。
配送表中の情報を使用して少なくとも一つの項目の配送に関する業務データを生成すること、及び
業務データに基づいて請求書作成イベントを生成することをさらに含む、請求項９記載の方法。
配送表中の情報は少なくとも一つの項目に関するゼロ金額小売価格を含み、そして業務データ及び請求書作成イベントは各々少なくとも一つの項目に関するゼロ金額小売価格を含む、請求項１０記載の方法。
少なくとも一つの項目を指示する配送表における配送状態を記録することをさらに含む、請求項９記載の方法。
グループ中の少なくとも一つの項目と関連する配送表中の情報が配送された状態に設定されたとき、さらなるダウンロードを防止することをさらに含む、請求項１２記載の方法。
追跡ＩＤを請求書作成要求と共に含めること、
請求書作成要求に基づいて追跡ＩＤを含む第一の業務データを生成すること、及び
第一の業務データを処理することをさらに含む、請求項１記載の方法。
第一の業務データを処理することは、
加入者請求書を生成すること、
支払いをプロバイダへ配分すること、及び
第一の業務データに基づいて報告データを作業者及びプロバイダの少なくとも一人へ伝送することをさらに含む、請求項１４記載の方法。
第一の業務データを処理することは追跡ＩＤを業務データと共に記憶することをさらに含む、請求項１４記載の方法。
グループを造出することはクライアント・デバイス（３００）の属性に基づいて行われる、請求項１４記載の方法。
追跡ＩＤをグループ中の少なくとも一つの項目に関連させること、及び
グループから少なくとも一つの項目及び追跡ＩＤを配送することをさらに含む、請求項１７記載の方法。
追跡ＩＤを含む少なくとも一つの項目の配送に関して第二の業務データを生成すること、及び
第二の業務データを処理することをさらに含む、請求項１８記載の方法。
第二の業務データを処理することはさらに、第一の業務データを処理することが加入者請求書を含むとき、加入者に請求書を送ることを防止することを含む、請求項１９記載の方法。
信用サービス（４９０）からクライアント・デバイス（３００）と関連している請求書作成要求を受取り、信用サービス（４９０）を認証するために構成された無線加入者請求書作成システムにおけるサービス額請求書作成（ＳＶＢ）（４１０）モジュールと、
請求書作成要求に応答して確認応答を生成するように構成された確認論理と、
主カタログからクライアント・デバイス（３００）にグループを造出するように構成され、グループは少なくとも一つの項目を含む論理と、及び
クライアント・デバイス（３００）に少なくとも一つの項目を含むグループを提示するように構成された論理とを具備する装置。
請求書作成要求に関係した業務データを受取り、そして請求書作成イベントを生成するように構成された業務マネージャ（ＴＸＮ）（４４０）と、
業務マネージャ（４４０）から請求書作成イベントを受取り、そして請求書を生成するように構成されたクライアント請求書作成モジュール（４５０）と、及び
業務マネージャ（４４０）から請求書作成イベントを受取り、キャリアに送り状を作り、プロバイダに支払うように構成された決済モジュール（４６０）とをさらに具備する、請求項２１記載の装置。
ＴＸＮ（４４０）は請求書作成イベントを生成するように追加請求書作成情報を請求書作成要求に関連させる、請求項２２記載の装置。
信用サービス（４９０）は請求書作成要求を生成するように構成される、請求項２１記載の装置。
信用サービス（４９０）は請求書作成要求にディジタル的に署名するように構成される、請求項２４記載の装置。
請求書作成要求は加入者ＩＤ、プロバイダ受取人、項目ＩＤ、小売価格、及び請求書作成説明の少なくとも一つを含む、請求項２１記載の装置。
（削除）
配送表はグループ中の少なくとも一つの項目と関連する情報を含む、請求項２１記載の装置。
配送表中の情報は少なくとも一つの項目に関してゼロ金額小売価格を含む、請求項２８記載の装置。
配送表中の少なくとも一つの項目の配送を記録するように構成された論理と、及び
グループ中の少なくとも一つの項目と関連する配送表中の情報が配送の状態に設定されたとき、さらなるダウンロードを防止するように構成された論理とをさらに具備する、請求項２８記載の装置。
無線加入者請求書作成システムにおいて信用サービス（４９０）から、クライアント・デバイス（３００）と関連している請求書作成情報を含む請求書作成要求を受取る手段と、
無線加入者請求書作成システムにおいて請求書作成要求に対する確認応答を生成する手段と、
確認応答を信用サービス（４９０）へ通信する手段と、
主カタログからクライアント・デバイス（３００）において指示された少なくとも一つの項目を含むグループを造出する手段と、及び
少なくとも一つの項目を含むグループをクライアント・デバイス（３００）に提示する手段とを具備するシステム。
請求書作成要求を処理する前に信用サービス（４９０）を認証する手段をさらに具備する、請求項３１記載のシステム。
請求書作成要求は加入者ＩＤ、プロバイダ受取人、項目ＩＤ、小売価格、及び請求書作成説明の少なくとも一つを含む、請求項３１記載のシステム。
（削除）
グループから少なくとも一つの項目を配送する手段と、及び
配送表中の情報をグループ中の少なくとも一つの項目と関連させる手段とをさらに具備する、請求項３１記載のシステム。
配送表中の情報を使用して少なくとも一つの項目の配送に関して業務データを生成する手段と、及び
業務データに基づいて請求書作成イベントを生成する手段とをさらに具備する、請求項３５記載のシステム。
配送表中の情報は少なくとも一つの項目に関してゼロ金額小売価格を含み、さらに業務データ及び請求書作成イベントは少なくとも一つの項目に関してゼロ金額小売価格をそれぞれ含む、請求項３５記載のシステム。
少なくとも一つの項目の配送を指示する配送表中の配送状態を記録する手段と、及び
グループ中の少なくとも一つの項目と関連する配送表中の情報が配送の状態に設定されたとき、さらなるダウンロードを防止する手段とを具備する、請求項３７記載のシステム。
実行されるとコンピュータ・デバイスに動作を行わせる命令を含むコンピュータ可読媒体であって、その命令が、
信用サービス（４９０）からクライアント・デバイス（３００）と関連する請求書作成要求を受取る少なくとも一つの命令と、
無線加入者請求書作成システムにおいて請求書作成要求に対する確認応答を生成する少なくとも一つの命令と、
確認応答を信用サービス（４９０）へ通信する少なくとも一つの命令と、
主カタログからクライアント・デバイス（３００）において指示された少なくとも一つの項目を含むグループを造出する少なくとも一つの命令と、及び
少なくとも一つの項目を含むグループをクライアント・デバイス（３００）に提示する少なくとも一つの命令とを含むコンピュータ可読媒体。
（削除）
無線加入者請求書作成システムにおいて複数請求書作成イベントを処理する方法であって、
プロバイダ料金及び受取人、及び業務と関連する少なくとも一つのソース料金及び受取人を含む請求書作成イベントを生成すること、
プロバイダ受取人及び少なくとも一人のソース受取人に支払金を配分するために業務を処理すること、
業務データを記憶すること、
記憶された業務データにアクセスすること、
記憶された業務データに基づいてマイナス・プロバイダ料金及び少なくとも一つのマイナス・ソース料金を含む調整業務を生成すること、及び
マイナス・プロバイダ料金及び少なくとも一つのマイナス・ソース料金に基づいてプロバイダ受取人及び少なくとも一人のソース受取人の借方に記入するために調整業務を処理することを含む方法。
プロバイダ料金は少なくとも一つのソース料金を上回るか、或いは等しい、請求項４１記載の方法。
業務報告データを少なくとも一人のプロバイダ受取人及び少なくとも一人のソース受取人に伝送することをさらに含む、請求項４１記載の方法。
提供された項目の小売価格に基づいて加入者請求書を生成することをさらに含み、小売価格はプロバイダ料金を上回るか、或いは等しい、請求項４１記載の方法。
（削除）
比例基準、及びプロバイダ受取人及び少なくとも一人のソース受取人の支払いに関係する記憶業務データに基づいて、マイナス・プロバイダ料金及び少なくとも一つのマイナス・ソース料金を決定することをさらに含む、請求項４１記載の方法。
調整比率、及び項目に関する小売価格に基づいて加入者クレジットを生成することをさらに含む、請求項４６記載の方法。
調整業務を記憶することをさらに含む、請求項４１記載の方法。
調整業務報告データを少なくとも一人のプロバイダ受取人及び少なくとも一人のソース受取人へ伝送することをさらに含む、請求項４１記載の方法。