JP2007519120A - 無線加入者ネットワークにおけるアプリケーションをベースにした価値課金 - Google Patents

Abstract

無線加入者請求システムにおけるアプリケーションをベースにした課金のためのシステムおよび方法が開示される。無線クライアント装置は、課金要求を発生し、請求システムに送信することができる。請求システムは、課金要求に対して検証応答を発生し、検証応答をクライアント装置に送信する。検証応答はクライアント装置により処理することができ、課金要求にリンクされたサービスを可能にすることができる。

Description

関連出願へのクロスリファレンス

この出願は、２００４年１月２１日に出願した米国仮特許出願第６０／５３８，２０６に基づいて３５Ｕ．Ｓ．Ｃ．１１９（ｅ）に基づく優先権を請求する。この開示はその全体において参照することによりここに組み込まれる。

この発明は一般に遠隔コンピューティング装置とサーバーとの間の通信に関する。特に、この発明は課金イベントの作成およびサーバーと遠隔クライアント装置との間の請求書イベントの送信に関する。

技術の進歩はより小さくより強力なパーソナルコンピューティング装置を結果として生じた。例えば、各々が小型であり、軽量であり、ユーザーにより容易に運ぶことができるポータブル無線電話、パーソナルデジタルアシスタンツ（ＰＤＡｓ）およびページング装置のような無線コンピューティング装置を含む多様なポータブルパーソナルコンピューティング装置が現在存在する。特に、例えば、ポータブル無線電話は、無線ネットワークを介して音声およびデータパケットを通信する携帯電話をさらに含む。さらに、多くのそのような携帯電話は、計算能力を相対的に大きく増大して製造されており、このため小型のパーソナルコンピューターおよびハンドヘルドＰＤＡｓと同等になりつつある。しかしながら、これらのより小型でより強力なパーソナルコンピューティング装置は典型的に厳しくリソースが制限される。例えば、スクリーンサイズ、利用可能なメモリおよびファイルシステムの量、入出力能力および処理能力の量は各々装置の小型サイズ、特に、ユーザー入力装置、特にキーボードの小型サイズにより制限されるかもしれない。そのような厳しいリソース制約のために、例えばそのような遠隔パーソナルコンピューティング装置（クライアント装置）上に存在するソフトウエアアプリケーションおよび他の情報の制限されたサイズおよび品質を維持することがしばしば典型的に望ましい。

パーソナルコンピューティング装置のいくつかはアプリケーションプログラミングインターフェース（ＡＰＩｓ）を利用する。アプリケーションプログラミングインターフェースは、ときどきローカルコンピュータープラットホーム上にインストールされるランタイム環境およびソフトウエアプラットホームと呼ばれる。アプリケーションプログラミングインターフェースは、例えば、装置固有のリソースのために汎用化された呼を供給することによりそのような装置の動作を簡単にするために使用される。さらに、また、そのようなＡＰＩｓのいくつかは、ソフトウエア開発者に、そのような装置上で完全に実行可能であるソフトウエアアプリケーションを作成する能力を供給することが知られている。さらに、コンピューティング装置の計算能機能が、ソフトウエア開発者が特定のコンピューティング装置システムソースコードを有することを必要とせずにソフトウエアアプリケーションに利用可能になるように、そのようなＡＰＩｓのいくつかは、コンピューティング装置システムソフトウエアとソフトウエアアプリケーションとの間に操作上位置していることが知られている。さらにいくつかのＡＰＩｓは、安全な暗号情報を用いて、そのようなパーソナル装置（すなわち、クライアント）と遠隔装置（すなわち、サーバー）との間の安全な通信のための機構を供給することが知られている。

そのようなＡＰＩｓの例は、そのいくつかは以下により詳細に記載されるが、カリフォルニア州サンディエゴに所在するＱＵＡＬＣＯＭＭ社により開発された無線（ＢＲＥＷ（登録商標））のためのバイナリランタイム環境のバージョンを含む。ＢＲＥＷ（登録商標）は、コンピューティングデバイス（例えば、無線携帯電話）のオペレーティングシステムと強力することができ、いくつかある特徴の中で特に、パーソナルコンピューティングデバイス上で発見されるハードウエア特徴へのインターフェースを供給する。ＢＲＥＷ（登録商標）はまたそのようなパーソナルコンピューティングデバイス上のこれらのインターフェースを、デバイスリソース上の需要に対しておよび ＲＥＷ ＡＰＩを含む装置のための消費者により支払われる価格に対して相対的に低価格で供給することができる。ＢＲＥＷ（登録商標）のさらなる特徴は、無線サービスオペレーター、ソフトウエア開発者およびコンピューティングデバイス消費者のために多様な利益を提供するエンド・ツー・エンドソフトウエア配布プラットホームを含む。少なくとも１つのそのような現在利用可能なエンド・ツー・エンドソフトウエア配布プラットホームは、サーバー−クライアントアーキテクチャを介して分配されるロジックを含む。この場合、サーバーは、例えば、課金、セキュリティおよびアプリケーション配布機能性を実行し、クライアントは、例えばアプリケーション実行、セキュリティおよびユーザーインターフェース機能性を実行する。

［０００６］クライアント装置における機能強化されたコンピューティング能力およびセキュリティ特徴は、アプリケーションをキャリアネットワークから直接購入することを可能にし、クライアント装置にダウンロードし、インストールすることを可能にした。アプリケーションが購入されると、遠隔請求システムは、クライアント装置に関連する加入者／アカウントに課金を自動的に発生することができ、開発者／発行者に適切な支払いを配布することができる。しかしながら、現在の無線サーバー−クライアントシステムは制限された購入されたオプションを提供する。典型的には、一度だけの購入または個定数の使用は、所望のアプリケーションまたはコンテンツに対して購入することができる。これは、開発者およびコンテンツプロバイダーがアプリケーションをパッケージ化したりまたは高く売りつける場合に限られた柔軟性を生じる。

関連技術の上述の記載は、ＡＰＩｓの周知の使用のいくつかの概観を提供することおよびこの発明の実施形態に使用することができるＢＲＥＷ（登録商標）への導入として提供することを単に意図している。しかしながら、この発明は、特定の実施、オペレーティングプラットフォームまたは環境に限定するように解釈されるべきでない。

発明の概要

この発明の例示実施形態は、無線ネットワークにおいてクライアント装置が発生した課金要求を発生し処理するためのシステムおよび方法に向けられている。

従って、この発明の一実施形態は、無線加入者請求システムにおいてアプリケーションをベースにした課金のための方法を含むことができる。この方法は、クライアント装置内で課金要求を発生することと、加入者識別（ＳＩＤ）を含む課金要求を請求システムに送信することと、請求システムにおいて課金要求への検証応答を発生することと、検証応答をクライアント装置に送信することを含む。

この発明の他の実施形態は装置を含むことができる。この装置は、課金要求を発生して送信するように構成され、検証応答を受信するように構成されたアプリケーションを含む無線クライアント装置と、課金要求を受信し検証応答を送信するように構成された請求サーバーと、および課金要求に応答して検証応答を発生するように構成された検証ロジックとを備える。

この発明の他の実施形態は、クライアント装置を含むことができる。クライアント装置は、無線でデータを送受信することができるトランシーバーと、ユーザーインターフェースと、課金要求を発生するように構成され、トランシーバーを用いた請求システムに課金要求を送信するように構成され、および請求システムから課金要求に関連する検証応答を受信するように構成されたアプリケーションとを備える。

この発明の他の実施形態は、請求システムを含むことができる。請求システムは、無線でデータを送受信することができるトランシーバーと、トランシーバーに動作可能に接続される請求サーバーであって、クライアント装置から加入者ＩＤ（ＳＩＤ）を含む課金要求を受信するように構成され、検証応答をクライアント装置に送信するように構成された請求サーバーと、課金要求に応答して検証応答を発生するように構成された検証ロジックとを備える。

この発明の他の実施形態は、アプリケーションをベースにした課金要求を無線で通信するためのコンピュータープログラムが記憶されるコンピューター読み取り可能な媒体を含むことができる。コンピュータープログラムは、無線クライアント装置上の少なくとも１つのコンピューティングデバイスにより実行されるとき、コンピューティングデバイスに、無線クライアント装置において課金要求を発生するプロセスと、課金を請求システムに送信するプロセスと、請求システムからの課金要求に関連する検証応答を受信するプロセスを実行させる命令を備える。

この発明の他の実施形態は、請求システムを含むことができる。請求システムは、クライアント装置内に課金要求を発生する手段と、加入者識別（ＳＩＤ）を含む課金要求を請求サーバーに送信する手段と、請求サーバーにおいて課金要求に対する検証応答を発生する手段と、検証応答をクライアント装置に送信する手段とを備える。

この発明の実施形態のより完全な理解およびそれらの付随する利点の多くは、例証のためにだけ提示され、この発明の限定ではない添付された図面に関連して考慮されるとき以下の詳細な説明を参照することにより、付随する利点がより良く理解されるようになるので、容易に得られる。

この発明の観点は、この発明の特定の実施形態に向けられる以下の記載および関連する図面に開示される。この発明の範囲を逸脱することなく代替実施形態を考案してもよい。さらに、この発明の良く知られたエレメントは、この発明の関連する詳細をあいまいにしないように詳細に記載されないかまたは省略されるであろう。

「例示」という用語はここでは、例、インスタンス、または例証として機能することを意味するために使用される。「例示」としてここに記載される任意の実施形態は、他の実施形態に対して好適であるとかまたは利点があると必ずしも解釈されるべきでない。同様に、「この発明の実施形態」という用語は、この発明のすべての実施形態が議論した特徴、利点、または動作モードを含むことを必要としない。

さらに、多くの実施形態は、例えば、コンピューティングデバイスのエレメントにより実行されるアクションのシーケンスの観点から記載される。ここに記載される種々の動作は、特定の回路（例えば、特定用途向け集積回路（ＡＳＩＣｓ）によって、１つ以上のプロセッサーにより実行されるプログラム命令によって、または両方の組み合わせによって実行することができることが認識されるであろう。さらに、ここに記載されるこれらの動作のシーケンスは、実行されると関連するプロセッサーにここに記載した機能性を実行させるコンピューター命令の対応するセットが記憶された任意の形態のコンピューター読み取り可能な記憶媒体に全体的に具現化されると考えることができる。従って、この発明の種々の観点は、多数の異なる形態で具現化されてもよい。これらの形態のすべては、請求される主題の範囲内にあるように意図される。さらに、ここに記載される実施形態の各々に対して、任意のそのような実施形態の対応する形態は、ここでは、例えば、記載した動作を実行する「ように構成されたロジック」として記載してもよい。

この発明の１つ以上の実施形態は、コンピューティングデバイス上で実行する実行時間環境（例えば、ＡＰＩ）とともに使用することができる。そのような実行時間環境（ＡＰＩ）の１つは、以前に述べたＷｉｒｅｌｅｓｓ（登録商標）（ＢＲＥＷ（登録商標））のためのバイナリ実行時間環境である。しかしながら、この発明の１つ以上の実施形態は、例えば、無線クライアントコンピューティングデバイス上のアプリケーションの実行を制御するように動作する他のタイプの実行時間環境（ＡＰＩｓ）と一緒に使用することができる。さらに、「ＡＰＩ」は、特定の機能を達成するために使用され、「アプリケーション」、「プログラム」、「ルーチン」、「命令」、および「アプレット」と交換できるように使用することができるスタンドアロンプログラムまたはプログラムの一部として広く解釈されるように意図される。

図１は、この発明の少なくとも１つの実施形態に従って、無線システム１００の一例示実施形態のブロック図を図解する。システム１００は、無線通信ポータルまたは無線ネットワークへの他のデータアクセスを介して無線装置からの課金イベントを受信する少なくとも１つの請求サーバー１０６を有する無線ネットワーク１０４を介した通信において、携帯電話のようなクライアント装置を含むことができる。ここに示されるように、無線（クライアント）装置は、携帯電話１０２、パーソナルデジタルアシスタント１０８、ここでは双方向テキストページャとして示されるページャ１１０または無線通信ポータルを有する別個のコンピュータープラットホーム１１２であり得る。従ってこの発明の実施形態は、無線通信ポータルを含む、または無線モデム、ＰＣＭＣＡカード、パーソナルコンピューター、アクセス端末、電話、または任意のそれらのコンビネーションまたはサブコンビネーションを限定されることなく含む無線通信能力を有する任意の形態のクライアント装置上で実現することができる。

請求サーバー（ＢＤＳ）１０６はここでは、無線ネットワーク１０４と通信する他のコンピューターエレメントを有するネットワーク１１６上に示される。さらなるスタンドアロンサーバー（例えば、スタンドアロンサーバー１２２）が存在することができ、各サーバーは無線ネットワーク１０４を介してクライアント装置１０２、１０８、１１０、１１２に別個のサービスと処理を提供することができる。また、望ましくは、無線装置１０２、１０８、１１０、１１２からの課金関連トランザクションのレコードを保持する少なくとも１つの記憶されたトランザクションデータベース１１８がある。しかしながら、当業者は、図１に図解される構成は単に例示であることを理解するであろう。従って、この発明の実施形態は、各々がすべての記載された機能を実行することができ、すべての必要なハードウエアおよびソフトウエアを含むことができ、または選択された機能性のみを含むことができる１つ以上のサーバーを含むことができる。

図２において、無線ネットワーク１０４のコンポーネントおよびこの発明の例示実施形態のエレメントの相互関係を含む、システム１００をより完全に図解するブロック図が示される。システム１００は、単に例示であり、無線クライアントコンピューティングデバイス３００、１０２、１０８、１１０、１１２のような遠隔クライアント装置が互いの間でおよび／または、無線ネットワークキャリアおよび／またはサーバーを限定することなく含む無線ネットワーク１０４を介して接続されたコンポーネント間で無線を介して通信することを可能にする任意のシステムを含むことができる。セルラー電気通信サービスを提供するために使用されるアプリケーションダウンロードサーバー１３０のような任意の他のサーバーとともに請求サーバー１０６および記憶されたトランザクションデータベースは、インターネット、セキュアＬＡＮ、ＷＡＮ、または他のネットワークのようなデータリンクを介してキャリアネットワーク２００と通信する。図示された実施形態において、シングルサーバー１２０は、アプリケーションダウンロードサーバー１３０、請求サーバー１０６および記憶されたトランザクションデータベース１１８を含むことができる。さらに、サーバー１２０はキャリアネットワークに直接接続することができるかまたはキャリアネットワーク内に含まれることができる。しかしながら、これらのサーバーはまた独立した装置であり得る。

キャリアネットワーク２００は、メッセージングサービスコントローラー（「ＭＳＣ」）２０２に送信されたメッセージ（典型的にはデータパケットとして送信される）を制御する。キャリアネットワーク２００は、ネットワーク、インターネットおよび／または公衆交換電話網（ＰＳＴＮ）によりＭＳＣ２０２と通信する。典型的には、キャリアネットワーク２００とＭＳＣ２０２との間のネットワークまたはインターネット接続は、データを転送し、ＰＳＴＮは音声情報を転送する。ＭＳＣ２０２は複数の基地局（「ＢＴＳ」）２０４に接続することができる。キャリアネットワークと類似した方法で、ＭＳＣ２０２は典型的に、データ転送および／または音声情報のためにネットワーク、インターネット、および／またはＰＳＴＮによりＢＴＳ２０４に接続される。ＢＴＳ２０４は、ショートメッセージングサービス（「ＳＭＳ」）または技術的に知られた他の無線（ＯＴＡ）方法により、クライアント装置１０２のようなクライアント装置に無線でデータメッセージをブロードキャストすることができる。

クライアント装置３００、例えば、携帯電話は、ソフトウエアアプリケーションを受信して実行することができ、アプリケーションからの課金要求を請求サーバー１０６に送信することができるコンピュータープラットホーム２０６を有する。さらに、クライアント装置３００はアプリケーションダウンロードサーバー１３０と通信することができる。コンピュータープラットホーム２０６は、特定用途向け集積回路（「ＡＳＩＣ」２０８）、または他のプロセッサー、マイクロプロセッサー、論理回路、または他のデータ処理装置を含むことができる。ＡＳＩＣ２０８または他のプロセッサーは、無線装置のメモリ２１２内の任意の常駐プログラムとインターフェースするアプリケーションプログラミングインターフェース（「ＡＰＩ」）２１０を実行する。メモリ２１２はリードオンリーメモリまたはランダムアクセスメモリ（ＲＡＭおよびＲＯＭ）、ＥＥＰＲＯＭ、フラッシュカード（登録商標）、またはコンピュータープラットホームに共通の任意のメモリで構成することができる。また、ＡＰＩ２１０（例えば、ＢＲＥＷ（登録商標））上で実行されるのは、キャリアネットワーク２００を介してクライアント装置から請求サーバー１０６への特別な課金要求を処理するように構成されたロジックを含むアプリケーションをベースにした価値−課金（ＡＶＢ）アプリケーション３１０である。また、コンピュータープラットホーム２０６は、メモリ２１２においてアクティブに使用されないアプリケーションを保持することができるローカルデータベース２１４を含むことができる。ローカルデータベース２１４は典型的にはフラッシュメモリセルであるが、磁気媒体、ＥＥＰＲＯＭ、光媒体、ソフトまたはハードディスクまたは類似のもののような技術的に知られた任意の二次記憶装置であり得る。

携帯電話のような無線クライアント装置３００は、ゲーム、ニュース、ストックモニター(stock monitor)および同種のもののような１つ以上のソフトウエアアプリケーションをインストールするかそうでなければダウンロードする。例えば、クライアント装置３００は、アプリケーションダウンロードサーバー１３０からダウンロードされた１つ以上のソフトウエアアプリケーションを受信してもよい。ソフトウエアアプリケーションは使用していないときは、ローカルデータベース２１４上に記憶してもよい。クライアント装置３００または他の無線コンピューティングデバイスは、ユーザーによりそのように要望されたときまたは他のＡＰＩにより起動されたとき、ローカルデータベース２１４上に記憶された常駐アプリケーションをＡＰＩ２１０上で実行するためにメモリ２１２にアップロードしてもよい。このように、一実施形態において、アプリケーションの実行のためにおよび請求サーバー１０６に対する課金要求の発生のためにクライアント装置３００上にロードすることができる。

ここに使用されるように、「クライアント装置」、「無線装置」、「無線コンピューティングデバイス」、「クライアントコンピューティングデバイス」およびそれらの変形物は互換性があり、各々は、常駐用に構成されたロジックを実行する１つ以上の処理回路を含む。この場合、そのようなコンピューティングデバイスは例えば、マイクロプロセッサー、デジタルシグナルプロセッサー（ＤＳＰｓ）、マイクロコントローラー、ポータブル無線電話、パーソナルデジタルアシスタンツ（ＰＤＡｓ）、およびページング装置、またはクライアント装置３００と請求サーバー１０６との間で通信される課金情報に向けられたここに記載された動作を少なくとも実行するように構成されたプロセッサーおよびロジックを含む、ハードウエア、ソフトウエアおよび／またはファームウエアの任意の適切な組み合わせを含む。クライアント装置３００は、クライアント装置３００において発生された課金要求を処理することに関して少なくとも１つの遠隔請求サーバー１０６によりサービスを受けることができる。この発明の実施形態に従って使用してもよいクライアント装置のいくつかの例は、携帯電話または他の無線通信装置、ＰＤＡｓ、ページング装置、ハンドヘルドナビゲーション装置、ハンドヘルドゲーミング装置、音楽またはビデオコンテンツダウンロード装置、および他の同様の無線通信装置を含む。

クライアント装置３００とＢＴＳ２０４との間の無線通信は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス、モバイル通信のためのグローバルシステム（ＧＳＭ）、または無線通信ネットワークまたはデータ通信ネットワークに使用してもよい他のプロトコルのような異なる技術に基づくことができる。データ通信は、典型的には、クライアント装置３００、ＢＴＳ２０４、およびＭＳＣ２０２の間で行われる。ＭＳＣ２０２は、キャリアネットワーク２００、ＰＳＴＮ、インターネット、仮想プライベートネットワーク、および同種のもののような多重データネットワークに接続することができ、クライアント装置がより広帯域の通信ネットワークにアクセスすることを可能にする。上述したように、音声送信に加えて、データは、ＳＭＳまたは技術的に知られた他のＯＴＡ方法を介してクライアント装置に送信することができる。

開発者達は、それらのアプリケーションおよびブランドのための消費者の強い好みを作るために大きな努力を注ぎ込んだ。多くの開発者達は、顧客がアプリケーションの最初の購入を越えてますます増加する購入を喜んでするであろうことを信じ、そしてより多くの価値を消費者に提供し、開発者、発行者、および無線オペレーターのための新しい収入機会を作り出すと信じている。例えば、開発者達は、最初のアプリケーションの購入とは別個の購入により可能となることができるさらなる特徴（例えば、ゲームにおける武器の強化またはさらなるレベル）を含むアプリケーションを作り出すことができる。従って、開発者達は、これらのアプリケーションをベースにした購入から増大した収入を派生することができる。さらに、リンガーマネージャー(ringer manager)のようないくつかのアプリケーションは、実際にはコンテンツを使用する（例えば、レコーディングアーティストまたは同様のものからの音楽であり得るリンガー自体）また、このコンテンツは、購入してクライアント装置に配布することができ、別個のトランザクションでクライアント装置にインストールすることができる。要求されたサービス（例えば、武器の追加またはコンテンツの配布）の課金およびイネーブリング(enabling)課金は別個のイベントであり得る。

この開示の理解を容易にするために、用語のいくつかのための定義が提供される。一般に、アプリケーションは、消費者の傾向および相互作用に基づいて行動を実行するソフトウエアプログラムである。従って、アプリケーションは使用されるごとに潜在的に異なって動作する。

ハンドラーはコンテンツのレンダリングをサポートするアプリケーションである。ハンドラーは典型的には装置上にプリインストールされ、１つ以上のコンテンツタイプをサポートすることができる。典型的には、ハンドラーは消費者と情報をやりとりしないが、そのかわりコンテンツを起動するために場面の裏側で機能する。しかしながら、いくつかのハンドラーは、「このリンガーをあなたのデフォルトにしたいですか？」というような簡単な消費者との相互作用をサポートする。

コンテンツ（または静的コンテンツ）は一般的に、アプリケーション、インタープリーター、またはハンドラーを介して消費者に表示されるソフトウエアファイルである。コンテンツファイルは典型的には任意の条件付きの／実行可能なソフトウエアロジックを含まない。典型的なコンテンツタイプは画像、ビデオ、ブラウザーページ、リンガーおよびテキストファイルを含む。

アプリケーションをベースにした価値課金（ＡＶＢ）要求は、クライアント装置上のアプリケーションにおいて発生される課金要求である。また、ＡＶＢ要求は、価値課金要求または単に課金要求と読んでもよい。同様に、ＡＶＢ要求から発生された課金イベントはＡＶＢイベント、価値課金イベントまたは単に課金イベントと呼んでもよい。

上述した定義は必要最小限であり、包括的であると考えるべきではない。例えば、アプリケーションは、消費者／加入者の相互作用に加えて特定の装置パラメーターおよび設定に基づいて、動作を実行することができる。従って、当業者により理解されるであろうように、用語の他の観点は、定義と発明の意図された範囲内にある。

図３を参照すると、アプリケーションをベースにした価値課金（ＡＶＢ）は、課金処理のために（例えば、ＡＶＢ拡張３１５を介して）支払い請求可能なイベントを請求サーバー（ＢＤＳ）１０６に提出するために、クライアント装置のアプリケーション（例えば、ＢＲＥＷ（登録商標）アプリケーション）３２０の能力を考慮することができる。アプリケーション３２０および関連するＡＶＢ拡張３１５は、クライアント装置３００で課金イベントを発生し処理するための能力を含むＡＶＢアプリケーション３１０を考慮することができる。これらの価値課金イベントは、ＢＤＳ１０６を介して請求モジュール３５０（例えば、オペレーターの加入者課金システム）および決済モジュール（例えば、ＢＲＥＷ（登録商標）課金サービス）に伝えることができる。決済モジュール３６０は消費者課金、開発者支払い、オペレーター歳入分与、および決済歳入分与をサポートする。ＡＶＢサービスは典型的には、クライアント装置３００へのコンテンツ配布を必要としないし、クライアント装置３００上の価値課金に関連するサービスを可能にすることを必要としない。それゆえ、ＢＤＳ１０６はＡＶＢに関連するライセンス管理サービスを必ずしも強要しない。価値課金要求を提出し、検証応答を処理し、成功した検証応答を受信したときにサービスを可能にすることはＡＶＢアプリケーション３１０の責任である。このライセンス管理のローカル制御は、開発者が、ＢＤＳ１０６により強要されるあらかじめ決められた規則（例えば、一度だけの課金、加入課金、等）に準拠する必要なしに必要に応じて、値づけおよび／またはライセンス供与をカスタマイズ可能にする。

上述したように、課金サービスは、ＡＶＢアプリケーション３１０に直接拡張することができる。従って、ＡＶＢアプリケーション３１０は、ＡＶＢアプリケーション３１０がダウンロードされる最初のアプリケーションダウンロードトランザクションの後で課金イベントを開始することができる。ＡＶＢアプリケーション３１０は、加入者／消費者へのさらなるコストに対してさらなるサービス（ポスト−アプリケーションダウンロード）を提供してもよい。経済的かかわりのために、これらの課金を可能にされたアプリケーション（例えば、ＡＶＢアプリケーション３１０）は、ＢＤＳ１０６上の課金に関連する特別に保護されたアプリケーションインターフェースを使用することができる。例えば、ＡＶＢアプリケーションは、ＢＤＳ１０６を介して課金を利用するために、課金インターフェース、ダウンロードインターフェース、および相互認証インターフェースをアクセスし、使用することができる。これらのインターフェースは、ＡＶＢ拡張３１５への呼を介してアクセスすることができる。ＡＶＢ拡張３１５は、以下にさらに詳細に記載するように、アプリケーションを用いた統合のために開発者に配布することができる。

ＡＶＢアプリケーションは多数の方法でサービスのための価値課金を発生する。例えば、ゲーム開発者達は、ベーシックアプリケーションを超えたサービスを提供することができる。これらのサービスは増加してもよく、ゲームの機能強化されたレベル、例えばゴルフゲームにおける新しいゴルフコースから、より多くの特徴および同種のものにまで及んでいてもよい。典型的には、これらのサービスは、ＡＶＢアプリケーション３１０を介して加入者に提供される。加入者が購入を確認した後で、ＡＶＢアプリケーション３１０は、課金要求を開始することができ、購入を処理して課金するために課金要求をＢＤＳ１０６に送信することができる。この能力は、ＡＶＢアプリケーション３１０を実行している間、アプリケーション開発者達がより低いエントリーアプリケーションコストおよび／またはサービスのための区別された値づけを有するより広い顧客にアピールするために柔軟性を提供する。

他の例は着信音ショッピングアプリケーションであり得る。現在、典型的な着信音アプリケーションは、ユーザー値づけモデルの購入／番号を利用する。１つの使用は、１つの着信音ダウンロードと同じである。しかしながら、ＡＶＢアプリケーション３１０とＢＤＳ１０６における価値課金を用いて、着信音供給者は着信音間で値づけを区別することができる。例えば、ポピュラーな着信音は他の着信音とは異なって価格をつけてもよい。

さらに、ＡＶＢアプリケーションは、ＡＶＢアプリケーションにより発生される課金要求に基づいて付加的な課金として請求される内蔵された価値課金サービスを備えた月ぎめの加入として価格を設定することができる。ＡＶＢアプリケーションによって発生された価値課金課徴金は、ＡＶＢアプリケーション課金とは独立して処理することができる（例えば、クライアント装置上のＡＶＢアプリケーションをインストールするための一度のダウンロード課金）。典型的に、各価値課金要求は一度だけの購入イベントとして考えられ、価値課金イベントとＢＤＳからのダウンロードイベントとの間の課金関係である必要はない。

ＡＶＢアプリケーションは、いくつかあるアイテムの中で特に、課金記述および請求金額、例えば、顧客料金表に基づく料金（ＣＬＰ）、およびクライアント装置３００に関連する加入者ＩＤ（ＳＩＤ）に関連する他の課金データおよび課金要求（ＡＶＢ要求）を発生したＡＶＢアプリケーション３１０に関連する他の課金データを含むように課金属性を設定することができる。この課金はＡＶＢ要求において、ＢＤＳ１０６に送信される。ＡＶＢ要求は、検証ロジック３３０を利用して処理して検証することができる。検証ロジック３３０は、キャリア／オペレーターにより構成することができ、ＡＶＢ要求を承認または拒否するために使用される。例えば、オペレーターは、５０ドルより大きい請求金額を有するＡＶＢ要求の拒否を発行してもよく、または特定のＳＩＤｓからのＡＶＢ要求の拒否を発行してもよい。さらに、ＳＩＤが前払い口座と関係しているなら、検証ロジック３３０は、例えば、十分な資金のための前払い口座における残高をチェックするために前払いインターフェースをアクセスしてもよい。ＡＶＢ要求が承認されると、ＡＶＢ課金イベントはＢＤＳ１０６を介して伝えることができる。さらに、ＡＶＢ課金イベントは、請求処理、顧客サービスサポート、ビジネスインテリジェンス、支払い調停サポート等のためにオペレーターおよび／または開発者へのリポートに含めることができる。

ＡＶＢアプリケーション３１０は、クライアント装置３００にプリインストールすることができ、一般的な方法でダウンロードすることができる。例えば、消費者／加入者は、カタログを閲覧し、ダウンロードのためにＡＶＢアプリケーション３１０を選択して購入することができる。次に、消費者は、購入を確認するように要求されることができ、ＡＶＢアプリケーション３１０に関連するさらなるサービス／コンテンツ料金があるかもしれないことを通知されることができる。次に、ＡＶＢアプリケーション３１０は、一般的な方法でダウンロードすることができ、ログを取ることができる。従って、ＡＶＢアプリケーション３１０の使用期間中のあるポイントにおいて、ＡＶＢアプリケーションは、「付加価値サービス」を購入する機会を提示することができる。ＡＶＢアプリケーション３１０は、キャリア、プラットホーム、言語、前払い情報、および／または環境（例えば、ＢＲＥＷ（登録商標）３．０）を利用して、利用可能な関連する付加価値サービスおよび値づけを決定することができる。ＡＶＢアプリケーション３１０は、消費者にさらなる価格の付けられたサービス、例えば、＄０．２５で新しい武器をまたは＄１．００でＭＰ３ソングを表示することができる。付加価値アイテムおよび価格は、コアアプリケーションの一部として局所的に記憶することができ、および／またはＡＶＢアプリケーション３１０は開発者のコンテンツサーバー３９０または他の遠隔サーバーに接続することができる。

上述したように、サービス（付加価値サービス）はすでにＡＶＢアプリケーション３１０（例えば、ゲームのエキストラレベル）にすでに存在することができ、またはコンテンツサーバー３９０への接続を要求することができる。次に、ＡＶＢアプリケーション３１０は、消費者課金承認を要求することができる（すなわち、ＡＶＢ要求を発生する）。クライアント装置３００は購入承認（例えば、ネットワーク接続を行う）のためにＢＤＳ１０６とコンタクトを取る。ＢＤＳ１０６は承認または拒否に応答する、または応答が無い。応答に基づいて、ＡＶＢアプリケーション３１０は、ローカルサービスを解除することができ、コンテンツサーバー３９０にコンタクトすることができ、または要求されたサービスを拒否することができる。所定の時間および／またはリトライ回数の後で応答が無いなら、ＡＶＢアプリケーション３１０は、トランザクションを未決定のものまたは放棄するものとしてトランザクションにマークを付けることができる。ＡＶＢアプリケーション３１０には存在しないコンテンツが必要なら、クライアント装置３００／ＡＶＢアプリケーション３１０はコンテンツサーバー３９０にコンタクトを取ることができる。ＡＶＢアプリケーション３１０がコンテンツを検索することができないなら、サービス購入は委託されたので、アプリケーションはリトライを待ち行列にいれることができる。典型的には、課金要求が承認されると、課金イベントが発生されＢＤＳ１０６を介して伝達され、加入者請求書が発生される。

この発明の少なくとも１つの実施形態は図３に図解される。ＡＶＢアプリケーション３１０を含むクライアント装置３００が図解される。ＡＶＢアプリケーション３１０は、ＡＶＢ拡張３１０（例えば、アプリケーション内の課金要求および処理を可能にするＡＰＩ）を含むアプリケーション（例えばＢＲＥＷ（登録商標）アプリケーション）３２０を含むことができる。従って、課金要求は、クライアント装置３００（例えば、ＡＶＢアプリケーション３１０において）内に発生される。これは、クライアント装置レベルでショッピング経験を制御可能にし、アプリケーションのライセンス供与、配布、および値付けにより大きな柔軟性を許容し、アプリケーションおよび／またはコンテンツにおける特徴を許容する。例えば、開発者は、各々が異なる価格レベルを有する種々の特徴を有するアーケードタイプアプリケーションを供給したいと思うかもしれない。これらの特徴は、オリジナルアプリケーション（例えば、異なるレベルの困難性）に含まれてもよいし、または遠隔コンテンツサーバー３９０からダウンロードされてもよい（例えば、機能強化されたバックグラウンドミュージック）。各サービスを購入するためのオプション（例えば、さらなる特徴、コンテンツ）は、ユーザーに提示することができ、ユーザーはアプリケーションレベルで各サービスを購入するか否かを決定することができる。従って、複数のアプリケーションおよび／または異なるアプリケーションの複数のダウンロードの必要性なしに、開発者またはキャリアのためのさらなる付加的な課金を発生することができる。

対照的に従来のシステムを用いて同様の機能性を達成するために、アプリケーション開発者は、各特徴および／または価格レベルのために異なるアプリケーションを発生する必要があるであろうし、ダウンロードのためにそれらを利用可能にする必要があるであろう。従来のシステムは、課金情報を記録し、ダウンロードされた各アプリケーションのための決済を処理する。このプロセスは、キャリアにより制御され、各アプリケーションを購入するために、クライアント装置はキャリアネットワークに接続して、アプリケーションカタログを閲覧し、所望の特徴を有する所望のアプリケーションを購入する必要があるであろう。

上述したように、この発明の少なくとも１つの実施形態において、ショッピング経験はクライアント装置３００で行われる。従って、購入オプションがクライアント装置３００において提示され受け入れられた後、課金要求がクライアント装置３００内で発生される。課金要求は、請求トランザクション（例えば、ＳＩＤ）を処理するために使用される情報を含み、遠隔請求サーバー（例えば、ＢＤＳ１０６）に送信することができる。課金要求はＢＤＳ１０６において受信され処理される。検証応答は、ＢＤＳ１０６における課金要求に応答して検証ロジック３３０により発生される。次に、検証応答はクライアント装置３００に送信される。

検証応答は、課金要求の承認または課金要求の拒否であり得る。クライアント装置が応答を受信すると、クライアント装置は、検証応答を処理することができる。例えば、課金要求にリンクされたサービス（例えば、ゲームのさらなる特徴を可能にすること）は、検証応答が肯定的であるなら、アクティブにすることができる。同様に、課金要求が拒否されるなら、課金要求の拒否の表示がクライアント装置上に表示することができる。状況に応じて、なぜ要求が拒否されたかの理由（例えば、不十分な資金）のようなさらなる情報を拒否に含めることができる。

少なくとも１つの実施形態において、ＢＤＳ１０６は、アプリケーションをベースにした価値請求システムの実施を容易にするために既存の課金コンポーネントを利用することができる。例えば、図３において、ＢＤＳ１０６は、クライアント装置３００から課金要求を受信することができる。次に、ＢＤＳ１０６は、請求エンティティ（例えば、オペレーター／キャリア）により決定することができるアクセス検証ロジック３３０をアクセスすることができる。検証ロジック３３０は、所望のように詳述することもできるし限定することもできる。例えば、キャリアは、ＳＩＤが有効である限り、デフォルト量および受取人情報を用いて、すべての課金イベントを処理可能にしてもよい。しかしながら、典型的には、検証チェックは、要求された請求金額が有効であり、課金イベント（例えば、サービスのための価格、ＡＶＢアプリケーションＩＤ、要求されたサービスの短い記述、および同様のもの）を発生するために十分な情報が提供されることを含むことができる。この情報は、課金要求に直接含めることができるかまたはＢＤＳ１０６またはＢＤＳ１０６に動作可能に接続される他のサーバー内の記憶された情報と組み合わせて発生することができる。例えば、アプリケーションＩＤは、１つ以上の供給者ＩＤｓおよび関連する供給者値付け、アプリケーションの記述、カタログ記載価格（ＣＬＰ）、値付けプラン、および同種のものにリンクすることができる。しかしながら、課金要求を発生するクライアントをベースにした購入トランザクションの期間に、サービスのために表示される価格は、典型的には加入者請求のために使用される価格であるので、典型的には、少なくともＳＩＤ、価格（ＣＬＰ）および要求されるサービスの短い記述は、クライアント装置３００／ＡＶＢアプリケーション３１０から送信されるであろう。

典型的に、上述したように、課金要求は、ＳＩＤ、要求されるサービスの短い記述（短い記述）およびサービスのための価格（ＣＬＰ）を含むことができるまたはそれらと関連づけることができる。アプリケーションＩＤ、トランザクションＩＤ、提出時間、作成時間、通貨、長い記述、受取人ＩＤ、ベンダーデータ、ＳＩＤハッシュ、プラットホーム、言語、環境（例えば、ＢＲＥＷ（登録商標）３．０）および同種のもののうちの少なくとも１つを含むさらなる情報を課金要求とともに送信することができる。さらなるデータは、当業者により理解されるであろうように、オペレーターおよび／または開発者により使用することができる。

例えば、トランザクションＩＤは、同じ課金要求／トランザクションに対して複数の課金イベントを防止するために使用される固有のコードであり得る。無線環境において、通信路の障害は、請求サーバーとクライアント装置との間のデータ通信の途絶を生じさせることができる。従って、課金要求は、請求サーバーにより受信され承認されることができるが、承認はクライアント装置により受信されないかもしれない。従って、トランザクションＩＤは両方の要求に対して同じであるので、クライアント装置が課金要求を再提出するなら、二重の課金を防止するために、トランザクションＩＤを使用することができる。

さらに、ＳＩＤハッシュはＳＩＤに関連した固有の識別子であり得るが、ＳＩＤに戻ってトレースすることはできない。従って、ＳＩＤハッシュは、ＳＩＤに関連する加入者のプライバシーを危険にさらすことなしに、追加されたビジネス／マーケティングインテリジェンスのために開発者／または他の第三者に送信することができる。例えば、ＳＩＤハッシュを用いて、特定の加入者がＡＶＢアプリケーションから複数の価値サービスを購入したと決定することは可能である。しかしながら、ＳＩＤハッシュは、その特定の加入者の識別を防止する。

さらに、この発明の実施形態において、検証ロジック３３０は、課金要求を承認するためにさらなるチェックを実行することができる。例えば、加入者価格プランが前払いプランならば、要求されたサービスを購入するための十分な資金があるか否かを見るために前払い差し引き残高をチェックすることができる。十分な資金があるなら、承認はクライアント装置に送信される。しかしながら、十分な資金が無いなら、課金要求自体が有効であるとしても、その課金要求は拒否される。課金要求が検証ロジック３３０／請求サーバー１０６により最終的に承認されると、その承認は、課金要求を発生したＡＶＢアプリケーションによる処理のためにクライアント装置３００に送信される。

承認をクライアント装置３００に送信すると、トランザクションデータは、トランザクションデータを更新するように構成されたトランザクションマネージャー（ＴＸＮ）３４０に通信される。ＴＸＮ３４０は任意に、含まれていないさらなる課金情報を、課金要求からのトランザクションデータと関連づけることができる。例えば、トランザクションデータは、ＳＩＤ、要求されたサービスの記述（短い記述）および価格（例えば、ＣＬＰ）を含むことができる。ＴＸＮ３４０は、課金プロセスを完成するために更なるデータを関連づけることができる（例えば、アイテムの記述、アプリケーションＩＤ、値付けプラン、および同種のもの）。あるいは、ＴＸＮ３４０は、任意の追加または変更なしに受信されたトランザクションデータを処理し通すことができる。次に、ＴＸＮ３４０は、この情報を課金イベントとしてクライアント請求モジュール３５０および決済モジュール３６０に通信することができる。クライアント請求モジュール３５０は、ＴＸＮ３４０からの課金イベントを受信し、請求書を、ＳＩＤに関連する加入者およびクライアント装置３００に発生するように構成することができる。また、決済モジュール３６０もＴＸＮ３４０から課金イベントを受信し、キャリア／オペレーターに請求書を送り、キャリア／オペレーターから支払いを受信し、サービス供給者（例えば、開発者、コンテンツプロバイダー、発行者等）に支払うように構成することができる。

トランザクションデータが発生されると、課金イベントは、一般的なアプリケーションダウンロードトランザクションに類似の方法で作ることができ処理することができる。例えば、購入された課金要求／サービスに関連するトランザクションデータは、ＴＸＮ３４０および／または関連データベース（トランザクションデータベース１１８）に記憶することができる。トランザクションデータは、ＴＸＮ３４０または関連するデータベースに記憶されたメタデータのサブセット、および他の装置および／またはシステムにより含まれるさらなる情報を含んでいてもよい。課金イベントは、メタデータとトランザクションデータを相関させることによりＴＸＮ３４０において作ることができ、またはＡＶＢアプリケーション３１０から受信したトランザクションデータにもっぱら基づくことができる。上述したように、課金イベントが発生されると、それは、関連する報告データ（例えば、ベンダーデータ）と一緒に通信することができ、請求モジュール３５０および決済モジュール３６０により処理することができる。課金要求に含まれる少なくともいくつかのデータは、処理されないかもしれない。例えば、ベンダーデータは、ＢＤＳ１０６および／または関連コンポーネントを介してベンダーデータを伝達すること以外に処理されないデータを通すことができる。

共通の請求サーバー／システムＢＤＳ１０６の一部として図解されるけれども、図解される種々のコンポーネント（例えば、検証ロジック３３０、ＴＸＮ３４０、請求モジュール３５０および決済モジュール３６０）および／または記載される機能性は、必要に応じて分離することができるしまたは結合することができる。さらに、記載された種々のコンポーネントおよび／または機能性は、有線または無線ネットワーク、インターネット、ＰＳＴＮ、他の周知の通信システムおよびそれらの組み合わせを介して互いに動作可能に接続された別個のサーバー／コンピューティング装置に任意に常駐することができる。

図４は開発者の観点からＡＶＢプロセスを図解する。開発者は、収入を増大させ、アプリケーションの配布を広げ、ライセンス供与構成を機能強化するためにＡＶＢアプリケーションを使用することができる。ＡＶＢアプリケーションを開発するために、開発者は、価値課金ドキュメンテーションおよび価値課金アプリケーションを開発するために必要な情報を検索することができる。これは、プログラミングガイドライン、ツール、およびＢＤＳ１０６のオーナー／オペレーターから利用可能なパブリック拡張（例えば、ＡＶＢ拡張３１０）にアクセスすることを含むことができる。（ブロック４１０）。

次に開発者は、アクティブキャリア、プラットホーム、言語、前払いおよびＳＩＤに敏感に反応することができる付加価値サービスを組み込んだＡＶＢアプリケーションを構築する。価格管理はＡＶＢアプリケーション並びに価値課金トランザクション管理サービス（ＡＶＢ拡張）に統合することができる。ＡＶＢアプリケーションは、操作環境テストツール（例えば、ＢＲＥＷ価値付加テストツール）を利用する開発者によりテストすることができる（ブロック４２０）。

次のアプリケーションは、付加価値請求サービスおよびＡＶＢアプリケーションのトランザクションマネージメント動作を記載する補足情報とともに第三者のテストセンターまたはオペレーターテストセンターに提出することができる。テストセンターは、価値課金のためにＡＶＢアプリケーションをテストまたは増大させることができる。例えば、テストセンターは、ＡＶＢトランザクション管理がＢＤＳからの承認された、拒否されたおよび応答無しの条件を適切に処理することを検証することができる。さらに、テストセンターは、価値課金サービスのサブセットを行使し、クライアント装置上のグラフィックユーザーインターフェースとの相互作用を検証することができる。また、プラットホーム（例えば、装置タイプ／オペレーティングシステム）と加入をベースにした試験も、ＡＶＢアプリケーションを認証するためにプラットホームおよび前払い／加入タイプによる付加価値サービス提供に対する効果を調べるために含むことができる。

アプリケーションが開発中および／またはテストサイクル中の間、開発者とオペレーターは、ＡＶＢアプリーション、付加価値サービス、およびＡＶＢアプリケーションと付加価値サービスの価格を議論することができる。オペレーターは、ネットワークサーバーアクセスおよび価格レンジ協定上の動作可能時間のための開発者とのサービスレベル取り決め（ＳＬＡ）を要求してもよい。ＡＶＢアプリケーションが分配された後、開発者はある場合には、ネットワーク化されたサーバー（例えば、コンテンツサーバー３９０）を用いてサービス価格を変更してもよい。しかしながら、オペレーターは協定価格帯内で値づけを要求してもよい（ブロック４４０）。

ＡＶＢアプリケーションの値づけはオペレーターにより同意することができる。次にオペレーターは、オペレーターのネットワーク上で利用可能なアプリケーションのカタログにアプリケーションを付加することができる。上述したように、分配のためにオペレーターのカタログにＡＶＢアプリケーションが利用可能であると、加入者はＡＶＢアプリケーションを閲覧することができ、アプリケーションをダウンロードすることができる（ブロック４５０）。

アプリケーションが分配された後、開発者により制御されるネットワーク／コンテンツサーバーが付加価値サービスに使用されるなら、付加価値サービスおよび関連する値付けを管理することができる。ＡＶＢアプリケーションが、処理され承認される価値課金要求を発生するので、開発者は、ＢＤＳから支払いと、ＡＶＢに関連したリポートを受信することができる。報告書は、各価値課金イベントおよび任意の関連する調節、価値課金サービスに関連する支払い、および同種のもののための使用情報を供給するＢＤＳにより発生することができる。例えば、ＢＤＳは、独立して価値課金サービスに基づいて支払いを発生することができる。あるいは、支払いは、アプリケーションダウンロードのための支払いのような他の開発者の支払いとともに合計金額に含めることができる。支払いが合計金額内で受信されるなら、ＢＤＳから支払いリポートまたは他のリポートは、ＡＶＢをベースにした支払いを識別するために使用することができる（ブロック４６０）。

課金データとともに、ベンダーデータは、課金要求とともに送信することができ、請求システムを介して伝達することができる。ベンダーデータ内のデータは、開発者リポートとともに含まれることができ、ＡＶＢをベースにした課金要求／購入に対応する開発者によりプログラムされた情報を提供する。例えば、データは、特定の価値をベースにしたサービス要求が成される前に、アプリケーションまたは特徴の使用回数を示すことができた。このデータは他のレポーティングデータとともに使用することができ、開発者が、ＡＶＢイベントから重要なビジネスインテリジェンスを派生させることを可能にする。ＡＶＢイベントは、値付けの決定、アプリケーション設計、機能強化／削除に対する特徴、および同種のもののために使用することができる。

オペレーターの観点から、ＡＶＢアプリケーションは新しい収入機会を可能にさせる。しかしながら、アプリケーションダウンロードにより存在するオペレーター分散制御ポイントは変更してもよい。例えば、ＡＶＢアプリケーションは、付加価値サービスを消費者に提供し、リスト価格を設定することを制御する。典型的には、オペレーターのカタログからのアプリケーションの一般的なアクセスにおいて、オペレーターは、すべてのアプリケーションの消費者のカタログと値付けを制御する。ＡＶＢアプリケーションの場合、オペレーターは同じシステマティック消費者／加入者ショッピング制御を有していない。しかしながら、オペレーターは、開発者との直接の議論を介して制御を強化することができる（例えば４４０）。さらに、有効ロジック（例えば、３３０）は、オペレーターにより制御することができる。従って、課金要求を承認することに対する制御は、たとえ値付けと他の観点が直接制御されないとしても、依然として行使することができる。このために、価値課金要求の場合、ＢＤＳ１０６は、オペレーターインターフェース（例えば、検証ロジック３３０）を介して全ての価値課金要求を検証するために、オペレーター手段を提供する。

図５は分布のためにカタログマネージャー５３０とオペレーターのカタログ５４０へのＡＶＢアプリケーションの受け入れと統合のためのシステムのより詳細な図解を提供する。一般に、テストセンター５１０は、開発者からＡＶＢアプリケーションを受信するように構成されたロジック５１２と、ＡＶＢアプリケーションを認証するように構成されたロジック５１４と、認証されたＡＶＢアプリケーションを統一されたアプリケーションマネージャー（ＵＡＭ）５２０に知らせるように構成されたロジック５１６を含むことができる。ＵＡＭ５２０は、課金および報告の目的のためにアプリケーションに関連したメタデータを記憶することができる。メタデータは、請求トランザクションを処理するためにＢＤＳ（例えば、ＴＸＮ）によりアクセスすることができる。ＵＡＭ５２０は、ＡＶＢアプリケーションをカタログマネージャー５３０に通信することができる。カタログマネージャー５３０は、ＡＶＢアプリケーションに関連する特権（例えば、課金サービス等へのアクセス）に基づいてＡＶＢアプリケーションを識別するように構成されたロジック５３２、ＡＶＢアプリケーションをパーツリストに受け入れるように構成されたロジック５３４、ＡＶＢアプリケーションをパーツリストに受け入れるように構成されたロジック５３６、およびＡＶＢアプリケーションを含むカタログをアクティブにするように構成されたロジック５３８を含むことができる。アクティブにされたカタログは、オペレーターＡＤＳカタログ５４０と考えることができる。カタログ５４０は、ＡＤＳによりアクセスすることができ、閲覧とダウンローディングのために加入者に提示することができるショッピングカタログ（例えば、パーツリストからのアプリケーションを含む階層的なグループ化されたフォルダー）と考えることができる。パーツリスト（例えば、ダウンロードのために利用可能なアイテムのリスト）に価値課金アプリケーションを受け入れると、オペレーターは、ＡＶＢアプリケーションを識別することができる。なぜならばＡＶＢアプリケーションは特権を持つ価値課金拡張に従属関係を有するからである。ＡＶＢアプリケーションの場合、各オペレーターは、加入者に公表されるであろうＧＵＩ、値付け、性能および付加価値サービスに満足されるアプリケーションに対するさらなる前商用試験を任意に行うことができる。各オペレーター／キャリアの経営的意思決定を変えることにより、ＡＶＢアプリケーションが試験センターテストにパスするが、価値課金のためのオペレーター固有のガイドラインを満足しないようにすることは可能である。従って、オペレーターネゴシエーション４４０の一部として、開発者達は、各オペレーターのガイドラインを再調査してＡＶＢアプリケーションに対してどのように各固有のオペレーターと連携するかを決定しなければならない。

上述するように、検証ロジックは、課金要求が承認されまたは拒否されるかを決定するために使用することができる。検証ロジックは、ＢＤＳ上の価値課金に関する種々のオペレーターインターフェースに依存することができる（例えば、ユーザー認証、検証トランザクション、および前払いサービス）。ユーザー認証は、ＳＩＤレベルにおける価値課金要求を承認または拒否するためにオペレーターにより使用することができる。例えば、オペレーターは、オペレーター定義されたしきい値（例えば、５０ドル）に基づいて、価値課金の上限を定めてもよい。しきい値に到達した後で、次にオペレーターは、無期限または限定された期間、例えば、月の残りの期間次の価値課金要求を拒否してもよい。検証トランザクションは、前払いプロセッシングまたは承認された応答を戻す前に価値課金要求に任意のさらなる検証テストを含めるためにオペレーターにより使用することができる。さらなる検証ロジックは、例えば、請求金額が単一価値課金イベント（例えば、１０ドル）のためのしきい値を超えないことを検証することを含んでいてもよい。他の例は、事後分配サービスおよび値付け議論（または他の理由により不可とされた）により、要求するＡＶＢアプリケーションがオペレーターの価値課金排除リスト上に無いことを検証することを含む。請求金額が適切な１０進法の精度内にあるかというような機能的なフォーマッティングチェックも行うことができる。前払いインターフェースは、一般的な前払いサービスに類似する前払いサービス（例えば、認証と前払い残高の負債）を行使するためにオペレーターにより使用することができる。オペレーターインターフェース（例えば、検証ロジック）に加えて、消費者／加入者課金および開発者支払いを処理するためのさらなる課金統合は、価値課金イベントのために追加することができる。オペレーターは、既存の請求システムの多くを利用することができるけれども、ＡＶＢシステムは多くの課金統合観点を有する。例えば、ＡＶＢ課金イベントは、アプリケーションダウンロード課金イベントとは区別された課金イベントとして取り扱うことができる。さらに、ＡＶＢ課金イベントに対して実行され調節は、調節されたＡＶＢトランザクションＩＤ（上述したようにＡＶＢトランザクションを表すユニークなコード）を参照するトランザクション調節イベントを生じることができる。例えば、購入されたサービスの短い記述は、サービスが典型的にオペレーターのカタログに無いので、ＡＶＢアプリケーションからパスすることができる。また、価値課金アプリケーションからパスされた請求金額は、加入者に課金された価格として含むことができる。

調節サービスは、ＡＶＢ課金イベントを含むことができるオンラインまたはオフライン調節処理をサポートすることができる。しかしながら、典型的に、要求されたサービスは、オペレーターのカタログにおいて部品番号に関係していない。従って、顧客サービス代表は、パート名と部品番号によって価値課金イベントを記録したＡＶＢアプリケーションを見ることができる。しかし、価値サービスはそれ自身アプリケーションによって定義され、課金記述において指定される。従って、長い記述は、自由に、ＡＶＢトランザクションに関する短い記述より大きな詳細を提供することができるＡＶＢ課金要求に含まれることができる。長い記述は典型的には、顧客サービスアクセスのみに利用可能であり、典型的には、レポートおよび加入者課金には含まれない。ＡＶＢ課金イベント上の調節は、類似の調節期間を使用することを含む他のタイプの課金イベント（例えば、ダウンロードおよび加入課金イベント）に類似した調節ルールに対して検証することができる。

先の開示を考慮して、当業者は、発明の実施形態がアクション、オペレーションおよび／またはここに議論された機能のシーケンスを行なう方法を含むことを認識するだろう。例えば、図６Ａは、少なくとも発明の一実施形態に従ってプロセスを図解する。課金要求はクライアント装置において発生することができる（ブロック６１０）。課金要求は、請求書サーバーシステムに送信することができる（ブロック６２０）。課金要求に応答して、検証応答は請求システムにおいて発生することができる（ブロック６３０）。検証応答は、クライアント装置に送信することができる（ブロック６４０）。検証応答はクライアント装置において受信されるかもしれないし、受信されないかもしれない（ブロック６５０）。（例えば、所定の時間の後に）検証応答が受信されないなら、検証応答が受信されるまでまたは所定数の再送信が試みられるまで課金要求は再送信することができる（ブロック６７０）。検証応答が受信されるなら、検証応答は、以下に詳細に記載されるクライアント装置において処理することができる（ブロック７００）。

図６Ｂを参照すると、ブロック６３０の検証プロセスはさらに図解される。例えば、検証プロセスの一部として、ＳＩＤは、ＳＩＤが価値課金サービスに対して認可されるか否かを決定するためにチェックすることができる（ブロック６３２）。ＳＩＤが認可されないなら、課金要求は拒否することができる（ブロック６３１）。課金要求は、検証課金情報（例えば、適切な通貨、フォーマッティング等）に対してチェックすることができる（ブロック６３３）。無効の課金情報が検出されるなら、課金要求は拒否することができる（ブロック６３１）。クライアント装置のローミングステータスはチェックすることができる（ブロック６３４）。クライアント装置がローミングしているなら、課金要求は拒否することができる（ブロック６３１）。ＳＩＤの前払いステータスをチェックすることができる（ブロック６３５）。ＳＩＤが前払いプランに関連するなら、課金請求をカバーするのに十分な資金があるか残高をチェックすることができる（ブロック６３６）。資金が不十分な場合、課金要求は拒否することができる（ブロック６３１）。上述したように、資金が十分で課金要求が拒否されなかったなら、課金要求は承認することができる（ブロック６３９）。上述の議論および関連する例証は単にこの発明の観点の例であり、この発明はこれらの例に限定されない。検証プロセスは、オペレーターにより必要に応じて、上述の例証から追加または削除された多くの代わりの検証チェックを用いて構成することができる。

同様に、検証応答７００を処理するための限定されない例は、図７Ａおよび７Ｂに図解される。例えば、アプリケーションは、検証応答が受信される前にすべてのまたはあるサービスを任意で可能にしてもよい。これらのサービスは、サービスを遅らせるのを回避するために（例えば、アーケードゲームにおける追加された特徴）、サービスのコスト等のような、開発者により確立された種々の基準に基づいて決定してもよい。従って、図７Ａに図解されるように、検証応答に関連するサービスが可能か否かを見るためのチェックを実行することができる（ブロック７０２）。サービスが可能になるなら、検証応答は、拒否のためにチェックすることができる（ブロック７０４）。拒否が受信されるなら、サービスはディスエーブルになることができる（ブロック７０６）。状況に応じて、課金要求が拒否され、および／またはサービスがディスエーブルされたという通知は、クライアント装置上に表示することができる（ブロック７０８）。

アプリケーションは検証応答を受信する前には、あるサービスまたはいかなるサービスをも可能にしなくてもよい。従って、図７Ｂに図解するように、承認のために検証応答をチェックすることができる（ブロック７１０）。ブロック７１２において、検証応答が承認を示し、サービスが局所的に（例えば、アプリケーション自体で）利用可能なら、ブロック７１４においてサービスは、アプリケーションにより直接イネーブルになることができる。しかしながら、サービスがクライアント装置上で利用できないなら、ブロック７１６において遠隔サーバー／コンテンツサーバーはコンタクトすることができ、サービス／コンテンツは、ブロック７１８においてアクセスすることができおよび／または検索することができる（例えば、購入されたチケット、ダウンロードされた音楽、ストリームされたビデオ等）。検証応答が承認されないなら、課金要求および／または要求されたサービスが拒否される通知は表示することができる（ブロック７２０）。当業者は、図７Ａおよび７Ｂに図解されるプロセスの１つのみがアプリケーションにより使用されてもよくまたは両方がアプリケーションにより使用されてもよい（例えば、検証応答を介して承認の前にいくつかのサービスがイネーブルになるときおよびアプリケーションにより提供された他のサービスがイネーブルでないとき）。

前と同じように、上述の議論および関連する例証は単にこの発明の観点の例であり、この発明はこれらの例に限定されない。さらに、他の方法および代替物は当業者によって認識することができる。また、図解された例はここに開示される方法を限定することを意図したものではない。

さらなる実施形態において、当業者は、図解された上述の方法およびここに開示された方法は、コンピュータープラットホームのメモリのようなコンピューター読み取り可能記憶媒体上に具現化されたプログラムの実行により実施することができることを理解するであろう。命令は、種々のタイプの信号ベアリング(bearing)または記憶装置一次、二次または三次媒体に常駐することができる。媒体は、例えば、クライアント装置および／またはサーバーによりアクセス可能なＲＡＭで構成してもよく、またはクライアント装置および／またはサーバー内に常駐してもよい。ＲＡＭ、ディスケットまたは他の二次記憶媒体に含まれていようとなかろうと、命令は、ＤＡＳＤストレージ（例えば、一般的な「ハードドライブ」またはＲＡＩＤアレイ）、磁気テープ、電子リードオンリーメモリ（例えば、ＲＯＭ、またはＥＥＰＲＯＭ）、フラッシュメモリカード（登録商標）、光学記憶装置（例えば、ＣＤ−ＲＯＭ、ＷＯＲＭ、ＤＶＤ、デジタル光学テープ）、紙「パンチ」カード、またはデジタルおよびアナログ送信媒体を含む他の適切なデータ記憶媒体のような多様な機械読み取り可能データ記憶媒体上に記憶してもよい。

先の記載に記述されたアプリケーションをベースにした価値請求（ＡＶＢ）システムは、オペレーターと開発者の両方のための新しい収入機会を開くために使用することができる。さらに、このシステムは、消費者／加入者が買うものおよび行うものにおける増大された制御と選択を消費者／加入者に持たせることを可能にする。コンテンツサポートは、クライアント装置上でアプリケーションを使用しながら、消費者に経験をカスタマイズさせることを可能にする。従って、消費者は、トラヒックをナビゲートしようとまたはコンタクトを管理しようと、時間を用いてより生産的に、およびゲーム、歌、および他のエンターティンメントの楽しみを強化するためにこれらの付加価値提供を利用することができる。

上述の開示は、この発明の例示的実施形態を示すけれども、この発明の範囲から逸脱することなく種々の変更と変形を行うことができることに留意する必要がある。例えば、ここに記載されたこの発明の実施形態に従って方法クレームの機能、ステップ、および／またはアクションは、いずれかの特定の順番に実行する必要なない。さらに、発明のエレメントは単数で記載されまたはクレームされるかもしれないけれども、単一への限定が明示的に記載されないかぎり、複数が意図される。同様に、サーバーおよび／またはシステムの一部として示される機能エレメントは任意の動作可能な態様で組織することができ、必要に応じて統合したり分離したりすることができる。例えば、請求サーバーは、検証ロジックからの別個のサーバー上に常駐することができる。または、両方が共通のサーバー上に常駐することができおよび／または共通のエレメントに集積することができる。

それゆえ、上述の実施形態は限定的というよりむしろ例証としてみなされるべきである。従って、これらの実施形態に対する変形は、以下のクレームにより定義されるように、この発明の範囲から逸脱することなく当業者により行うことができることが理解されなければならない。

図１は、この発明の少なくとも一実施形態に従ってクライアント装置とサーバーをサポートする無線ネットワークアーキテクチャーの図である。 図２は、この発明の少なくとも１つの実施形態に従ってクライアント装置とサーバーをサポートする無線ネットワークアーキテクチャーのより詳細な図である。 図３は、この発明の少なくとも１つの実施形態に従って、アプリケーションをベースにした価値請求システムのシステムレベルの説明図である。 図４は、この発明の少なくとも１つの実施形態に従って、開発者の観点からアプリケーションをベースにした価値課金プロセスの説明図である。 図５は、この発明の少なくとも１つの実施形態に従って、アプリケーションをベースにした価値課金請求アプリケーションをオペレーターカタログに追加するシステムレベルの説明図である。 図６Ａは、この発明の少なくとも１つの実施形態に従うアプリケーションをベースにした価値課金プロセスの説明図である。 図６Ｂはこの発明の少なくとも１つの実施形態に従う検証ロジックの説明図である。 図７Ａは、この発明の少なくとも１つの実施形態に従ってクライアント装置において検証応答を処理する説明図である。 図７Ｂは、この発明の少なくとも１つの実施形態に従ってクライアント装置において検証応答を処理する説明図である。

Claims (51)

1. 無線加入者請求システムにおけるアプリケーションをベースにした課金のための方法において、
   クライアント装置内に課金要求を発生させることと、
   加入者識別（ＳＩＤ）を含む前記課金請求を前記請求システムに送信することと、
   前記請求システムにおいて、前記課金要求に対する検証応答を発生することと、
   前記クライアント装置に前記検証応答を送信すること、
   とを備えた方法。
2. 前記クライアント装置は、無線コンピューティング装置、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）、およびページング装置の少なくとも１つである、請求項１の方法。
3. 前記検証応答は、前記課金要求の承認および前記課金要求の拒否の少なくとも１つである、請求項１の方法。
4. 前記クライアント装置において前記検証応答を受信することと、
   前記検証応答を処理することとをさらに備えた請求項１の方法。
5. 前記検証応答を処理することは、
   前記検証応答が承認であるなら前記課金要求にリンクされたサービスをイネーブルにすることをさらに備えた、請求項４の方法。
6. 前記検証応答を処理することは、
   遠隔コンテンツサーバーに接続することと、
   前記検証応答が承認ならば、前記課金要求にリンクされたコンテンツを検索することとをさらに備えた、請求項４の方法。
7. 前記検証応答を処理することは、前記検証応答が拒否なら前記課金要求の拒否を示すことをさらに備えた、請求項４の方法。
8. リスト価格を含むサービスを購入するためのオプションを前記クライアント装置上に提示することと、
   前記課金要求を発生する前に前記購入オプションの受け入れを受信することとをさらに備えた、請求項１の方法。
9. 前記課金要求にベンダーデータを関連づけることをさらに備えた請求項１の方法。
10. 前記請求システムを介して前記ベンダーデータを伝達することと、
    前記ベンダーデータを含むレポートを発生することとをさらに備えた、請求項９の方法。
11. 前記課金要求はさらなる課金情報を含み、前記さらなる課金情報は、リスト価格、アプリケーションＩＤ、トランザクションＩＤ、提出時間、作成時間、通過、短い記述、長い記述、受取人ＩＤ、ベンダーデータおよびＳＩＤハッシュの少なくとも１つである、請求項１の方法。
12. 検証応答を発生することは、
    前記ＳＩＤが前払い口座に関連するか否かを決定することと、
    前記前払い口座に十分な資金が利用可能であることを検証することと、
    十分な資金が利用可能でないなら、前記課金要求を拒否することと、
    を備えた、請求項１の方法。
13. 検証応答を発生することは、
    クライアント装置のローミングステータスを決定することと、
    前記クライアント装置がローミングしているなら前記課金要求を拒否することと、
    を備える、請求項１の方法。
14. 検証応答を発生することは、
    前記ＳＩＤが価値課金サービスに対して許可されるか否かを決定することと、
    前記ＳＩＤが価値課金サービスに対して許可されていないなら前記課金要求を拒否することとを備えた、請求項１の方法。
15. 検証応答を発生することは、
    前記課金要求が検証課金情報を含むか否かを決定することと、
    前記課金情報が有効でないなら前記課金要求を拒否することと、
    を備えた、請求項１の方法。
16. 前記検証応答の受信の前に前記課金要求に関連するサービスをイネーブルにすることと、
    前記検証応答が拒否なら前記サービスをディスエーブルにすることをさらに備えた、請求項１の方法。
17. 課金要求を発生し送信するように構成され、検証応答を受信するように構成されたアプリケーションを含む、無線クライアント装置と、
    前記課金要求を受信し前記検証応答を送信するように構成された請求サーバーと、
    前記課金要求に応答して前記検証応答を発生するように構成された検証ロジックと、
    を備えた装置。
18. 前記クライアント装置は、無線コンピューティング装置、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）およびページング装置の少なくとも１つである、請求項１７の装置。
19. 前記課金要求に関連するトランザクションデータを受信し、課金イベントを発生するように構成されたトランザクションマネージャーと、
    前記トランザクションマネージャーから前記課金イベントを受信し、請求書を発生するように構成されたクライアント請求モジュールと、
    前記トランザクションマネージャーから前記課金イベントを受信することと、キャリアに請求書を送ることと、サービスプロバイダーに支払うこととのうちの少なくとも１つを実行するように構成された決済モジュールと、
    をさらに備えた、請求項１７の装置。
20. 前記請求サーバーは、さらなる課金情報を前記課金要求と関連づけるように構成された、請求項１７の装置。
21. 前記検証応答は、前記課金要求の承認と前記課金要求の拒否の少なくとも１つである、請求項１７の装置。
22. 前記アプリケーションは、前記検証応答が承認なら前記課金要求にリンクされたサービスをイネーブルにするようにさらに構成される、請求項１７の装置。
23. 前記アプリケーションは、遠隔コンテンツサーバーに接続するように構成され、前記検証応答が承認なら前記課金要求にリンクされたコンテンツを検索するようにさらに構成される、請求項１７の装置。
24. データを無線で送受信することができるトランシーバーと、
    ユーザーインターフェースと、
    課金要求を発生し、前記課金要求を、前記トランシーバーを使用する請求システムに送信し、および前記請求システムからの課金要求に関連する検証応答を受信するように構成されたアプリケーションと、
    を備えたクライアント装置。
25. 前記検証応答が受信されないなら、前記アプリケーションはさらに前記課金要求を再送信するように構成された、請求項２４のクライアント装置。
26. 前記アプリケーションは、前記検証応答が拒否を示すなら要求指示の拒否をユーザーインターフェースに提示するように構成され、前記検証応答が承認を示すなら、前記検証応答を処理するように構成される、請求項２４のクライアント装置。
27. 前記検証応答が承認を示すなら、前記アプリケーションはさらに前記課金要求にリンクされたサービスをアクティブにするようにさらに構成される、請求項２４のクライアント装置。
28. 前記アプリケーションは、遠隔コンテンツサーバーに接続するように構成され、前記検証応答が承認を示すなら前記課金要求にリンクされたコンテンツを検索するようにさらに構成される、請求項２４のクライアント装置。
29. 前記アプリケーションはさらに、リスト価格を含むサービスを購入するためのオプションをユーザーインターフェースに提示するように構成され、前記課金要求を発生する前に前記ユーザーインターフェースから前記購入オプションの受け取りを受信するように構成される、請求項２４のクライアント装置。
30. 前記クライアント装置は、無線コンピューティング装置、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）およびページング装置の少なくとも１つである、請求項２４のクライアント装置。
31. データを無線で送受信することができるトランシーバーと、
    前記トランシーバーに動作可能に接続される請求サーバーであって、前記請求サーバーは、クライアント装置から加入者ＩＤ（ＳＩＤ）を含む課金要求を受信し、検証応答を前記クライアント装置に送信するように構成される請求サーバーと、
    前記課金要求に応答して前記検証応答を発生するように構成される検証ロジックと、
    を備えた請求システム。
32. 前記課金要求に関連するトランザクションデータを受信し、課金イベントを発生するように構成されるトランザクションマネージャーと、
    前記トランザクションマネージャーから前記課金イベントを受信し、加入者請求書を発生するように構成される請求モジュールと、
    前記トランザクションマネージャーから前記課金イベントを受信することと、オペレーターに請求書を送ることと、サービスプロバイダーに払うことのうちの少なくとも１つを行うように構成された決済モジュールと、
    をさらに備えた、請求項３１の請求システム。
33. 前記請求サーバーは、さらなる課金情報を前記課金要求に関連づけるように構成される、請求項３１の請求システム。
34. 前記検証ロジックは、
    前記ＳＩＤが前払い口座に関連するか否かを決定するように構成されたロジックと、
    十分な資金が前記前払い口座において利用可能であることを検証するように構成されたロジックと、
    十分な資金が利用可能でないならば、前記課金要求を拒否するように構成されたロジックと、
    を備えた、請求項３１の請求システム。
35. 前記検証ロジックは、
    前記クライアント装置のローミングステータスを決定するように構成されたロジックと、
    前記クライアント装置がローミング中であるなら、前記課金要求を拒否するように構成されたロジックと、
    を備えた、請求項３１の請求システム。
36. 前記検証ロジックは、
    前記ＳＩＤが価値課金サービスに対して許可されるか否かを決定するように構成されたロジックと、
    前記ＳＩＤが価値課金サービスに対して許可されないなら前記課金要求を拒否するように構成されたロジックと、
    を備えた、請求項３１の請求システム。
37. 前記検証ロジックは、
    前記課金要求における課金情報が有効か否かを決定するように構成されたロジックと、
    前記課金情報が有効なら、前記課金要求を拒否するように構成されたロジックと、
    を備えた、請求項３１の請求システム。
38. アプリケーションをベースにした課金要求を無線で通信するためのコンピュータープログラムが記憶されたコンピューター読み取り可能媒体であって、前記コンピュータープログラムは、無線クライアント装置上の少なくとも１つのコンピューティング装置により実行されると、前記コンピューティング装置に、
    前記無線クライアント装置において課金要求を発生することと、
    前記課金要求を請求システムに送信することと、
    前記請求システムからの前記課金要求に関連する検証応答を受信すること、を実行させる命令を備えるコンピューター読み取り可能媒体。
39. 前記コンピュータープログラム命令は、少なくとも１つのコンピューティング装置により実行されると、前記コンピューティング装置に、前記検証応答が受信されないなら前記課金要求を再送信するプロセスを実行させる、請求項３８のコンピューター読み取り可能媒体。
40. 前記コンピュータープログラム命令は、少なくとも１つのコンピューティング装置により実行されると、前記コンピューティング装置に、前記検証応答が承認を示しているなら前記課金要求にリンクされたサービスをアクティブにするプロセスを実行させる、請求項３８のコンピューター読み取り可能媒体。
41. 前記コンピュータープログラム命令は、少なくとも１つのコンピューティング装置により実行されると、さらに前記コンピューティング装置に、
    遠隔コンテンツサーバーに接続するプロセスと、
    前記検証応答が承認を示しているなら前記課金要求にリンクされたコンテンツを検索するプロセスを実行させる、請求項３８のコンピューター読み取り可能媒体。
42. クライアント装置内に課金要求を発生する手段と、
    加入者識別（ＳＩＤ）を含む前記課金要求を請求サーバーに送信する手段と、
    前記請求サーバーにおいて、前記課金要求に対する検証応答を発生する手段と、
    前記検証応答を前記クライアント装置に送信する手段と、
    を備えた請求システム。
43. 前記クライアント装置は、無線コンピューティング装置、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）、およびページング装置の少なくとも１つである、請求項４２の請求システム。
44. クライアント装置において前記検証応答を受信する手段と、
    前記検証応答を処理する手段と、
    をさらに備えた請求項４２の請求システム。
45. 前記検証応答を処理する手段は、前記検証応答が承認であるなら前記課金要求にリンクされたサービスをイネーブルにする手段を備えた、請求項４４の請求システム。
46. 前記検証応答を処理する手段は、
    遠隔コンテンツサーバーに接続する手段と、
    前記検証応答が承認であるなら前記課金要求にリンクされたコンテンツを検索する手段と、
    を備えた、請求項４４の請求システム。
47. 前記検証応答を処理する手段は、
    前記検証応答が拒否であるなら、前記課金要求の拒否を示す手段を備えた、請求項４４の請求システム。
48. リスト価格を含むサービスを購入するためのオプションをクライアント装置上に提示する手段と、
    前記課金要求を発生する前に前記購入オプションの受け入れを受信する手段と、
    をさらに備えた、請求項４２の請求システム。
49. 前記課金要求が有効課金情報を含むか否かを決定する手段と、
    前記課金情報が有効でないなら前記課金要求を拒否する手段と、
    をさらに備えた、請求項４２の請求システム。
50. 前記課金要求に基づいて加入者請求書を発生する手段をさらに備えた、請求項４２の請求システム。
51. 前記課金要求に基づいてレポートを発生する手段と、
    前記レポートをオペレーターおよび開発者の少なくとも一人に通信する手段と、
    をさらに備えた、請求項４２の請求システム。

Images