(57)【要約】送信に基づく請求用のコンピュータおよびネットワークに基づく方法およびシステムが提供される。例示の実施形態は、パケットベース請求システム（「ＰＢＢＳ」）を提供する。パケットベース請求システムは、キャリアおよびコンテンツプロバイダ等のアプリケーションプロバイダを、アプリケーション上毎に、使用の程度に基づくユーザベース毎に、無線デバイス等のモバイル加入者デバイス上のコンテンツの使用に対して加入者に請求することを可能にする。本発明の実施形態はまた、アプリケーション上毎に、同様に有線加入者デバイス用のユーザを基準として、同一の技術を用いて、コンテンツの使用に対して、加入者に請求するように使用され得る。
2005509322.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに基づく環境において、ネットワークを介して、データを送信するコンテンツの送信に基づく請求を提供する方法であって、
請求トラッキングコードを決定する工程と、
該決定された請求トラッキングコードを該コンテンツに備える工程であって、該備える工程により、該コンテンツを修正し、該修正されたコンテンツがターゲットデバイス上で実行される場合に、該請求トラッキングコードは、自動的に、該修正されてたコンテンツと該ネットワークとの間で送信されたデータ量に基づいて、請求データを通信する、備える工程と
を包含する、方法。
【請求項２】
前記請求トラッキングコードは、前記ネットワークを介して、前記備えられたコンテンツから送られたデータ量をトラッキングする請求項１に記載の方法。
【請求項３】
前記ネットワークはインターネットである請求項２に記載の方法。
【請求項４】
前記データ量は、論理的に規定されるパケットレベルにてトラッキングされる請求項２に記載の方法。
【請求項５】
前記請求トラッキングコードは、前記ネットワークから前記備えられたコンテンツによって受け取られたデータ量をトラッキングする請求項１に記載の方法。
【請求項６】
前記ネットワークがインターネットである請求項５に記載の方法。
【請求項７】
前記データ量は、論理的に規定されるパケットレベルにてトラッキングされる請求項５に記載の方法。
【請求項８】
前記コンテンツがＪａｖａ（Ｒ）ベースである請求項１に記載の方法。
【請求項９】
前記コンテンツは、バイトコード命令を含む請求項１に記載の方法。
【請求項１０】
前記備える工程は、コンテンツ検査のバイトコードレベルにて達成される請求項１に記載の方法。
【請求項１１】
前記備えられたコンテンツは、セキュリティキーを含み、該セキュリティキーは、該請求データのソースの整合性が検証され得るように、自動的に通信された請求データと共に送信される請求項１に記載の方法。
【請求項１２】
前記セキュリティキーが乱数に基づく請求項１１に記載の方法。
【請求項１３】
前記セキュリティキーがアプリケーションおよび加入者固有である請求項１１に記載の方法。
【請求項１４】
前記セキュリティキーは、前記コンテンツをダウンロードするリクエストを受けると、前記コンテンツに備えられる請求項１１に記載の方法。
【請求項１５】
前記環境は、無線キャリアインフラストラクチャと統合される請求項１に記載の方法。
【請求項１６】
前記備えられたコンテンツを無線送信媒体を介してターゲットデバイスにダウンロードされるようにする工程をさらに包含する請求項１に記載の方法。
【請求項１７】
前記コンテンツは、無線送信媒体を介して、前記コンピュータに基づく環境からのキャリアの加入者によって要求される請求項１６に記載の方法。
【請求項１８】
前記備えられたコンテンツを有線送信媒体を介してターゲットデバイスにダウンロードされるようにする工程をさらに包含する請求項１に記載の方法。
【請求項１９】
前記有線送信媒体がインターネットである請求項１８に記載の方法。
【請求項２０】
前記請求データは、送られたデータ量、受け取られたデータ量、タイムスタンプ、アプリケーション識別子、セキュリティキー、取引識別子および再試行期限インジケータの少なくとも一つを含む請求項１に記載の方法。
【請求項２１】
前記請求データは、請求サーバシステムへの送信を基準として自動的に通信される請求項１に記載の方法。
【請求項２２】
データを送信する工程であって、該データは、加入者のデバイスと請求サーバシステムでないサーバシステムとの間での直接の請求データではない、工程をさらに包含する請求項２１に記載の方法。
【請求項２３】
前記請求データを、顧客データレコードを生成する顧客ベースの請求情報に統合する工程をさらに包含する請求項１に記載の方法。
【請求項２４】
前記請求データは、複数の請求ポリシーを支援するように用いられる請求項１に記載の方法。
【請求項２５】
前記請求ポリシーは、指定されるアプリケーションに縮小された料金を提供する促進的な申し出を含む請求項２４に記載の方法。
【請求項２６】
前記請求ポリシーは、コンテンツプロバイダによって提供される請求項２４に記載の方法。
【請求項２７】
前記請求データは、前記コンテンツのプロバイダに印税支払を提供するように用いられる請求項１に記載の方法。
【請求項２８】
前記備えられたコンテンツと前記ネットワークとの間で送信されるデータを、前記自動的に通信される送信に基づく請求データに従って、ルーティングされるようにする工程をさらに包含する請求項１に記載の方法。
【請求項２９】
前記ルーティングは、前記ネットワーク上のリソースの効率的な使用を可能にする請求項２８に記載の方法。
【請求項３０】
送信使用法に基づいて、優先順位がコンテンツに割り当てられる請求項２８に記載の方法。
【請求項３１】
前記請求トラッキングコードは、プロキシストアおよび転送技術を利用し、これにより、前記備えられたコンテンツと複数のサーバシステムとの間で請求データおよびデータ送信パケットを送信する、請求項１に記載の方法。
【請求項３２】
請求トラッキングコードを備えられたコンテンツを含むネットワークに基づく送信媒体であって、該コンテンツがターゲットデバイス上で実行される場合、該請求トラッキングコードは、送信を基準として請求データを自動的に生成する、送信媒体。
【請求項３３】
前記請求トラッキングコードは、前記ネットワークを介して、前記備えられたコンテンツから送られたデータ量をトラッキングする請求項３２に記載の送信媒体。
【請求項３４】
前記ネットワークがインターネットである請求項３３に記載の送信媒体。
【請求項３５】
前記データ量は、論理的に規定されるパケットレベルにてトラッキングされる請求項３３に記載の送信媒体。
【請求項３６】
前記請求トラッキングコードは、前記ネットワークからの前記備えられたコンテンツによって受け取られたデータ量をトラッキングする請求項３２に記載の送信媒体。
【請求項３７】
前記ネットワークがインターネットである請求項３６に記載の送信媒体。
【請求項３８】
前記データ量は、論理的に規定されるパケットレベルにてトラッキングされる請求項３６に記載の送信媒体。
【請求項３９】
前記コンテンツがＪａｖａ（Ｒ）ベースである請求項３２に記載の送信媒体。
【請求項４０】
前記備えることがコンテンツ検査のバイトコードレベルで達成される請求項３２に記載の送信媒体。
【請求項４１】
前記コンテンツがバイトコード命令を含む請求項３２に記載の送信媒体。
【請求項４２】
前記備えられたコンテンツがセキュリティキーを含む請求項３２に記載の送信媒体。
【請求項４３】
前記セキュリティキーがアプリケーションおよび加入者固有である請求項３２に記載の送信媒体。
【請求項４４】
前記送信媒体が無線送信媒体である請求項３２に記載の送信媒体。
【請求項４５】
前記送信媒体が有線送信媒体である請求項３２に記載の送信媒体。
【請求項４６】
前記有線送信媒体が有線送信媒体である請求項４５に記載の送信媒体。
【請求項４７】
前記請求トラッキングコードは、送られたデータ量、受け取られたデータ量、タイムスタンプ、アプリケーション識別子、セキュリティキー、取引識別子および再試行期限インジケータの少なくとも一つを自動的に生成する請求項３２に記載の送信媒体。
【請求項４８】
前記請求トラッキングコードは、前記送信に基づく請求データに従って、前記コンテンツからのデータをルーティングするように用いられる請求項３２に記載の送信媒体。
【請求項４９】
前記コンテンツがターゲット無線デバイスに送信される請求項３２に記載の送信媒体。
【請求項５０】
コンピュータに基づく環境において、クライアントデバイス上で実行するとともにネットワークを介してデータを送信するコンテンツに対して、請求データを自動的に生成する送信に基づく請求システムであって、
請求トラッキングコードを該コンテンツに備えるコードモディファイアであって、該クライアントデバイス上で実行される場合、該ネットワークを介して送信されるデータ量を反映する請求データを自動的に通信するコードモディファイアを含む、請求システム。
【請求項５１】
前記請求トラッキングコードは、前記ネットワークを介して、前記備えられたコンテンツから送られたデータ量をトラッキングする、請求項５０に記載の請求システム。
【請求項５２】
前記ネットワークはインターネットである請求項５１に記載の請求システム。
【請求項５３】
前記データ量は、論理パケットレベルでトラッキングされる請求項５１に記載の請求システム。
【請求項５４】
前記請求トラッキングコードは、前記ネットワークからの前記備えられたコンテンツによって受け取られたデータ量をトラッキングする請求項５０に記載の請求システム。
【請求項５５】
前記ネットワークがインターネットである請求項５４に記載の請求システム。
【請求項５６】
前記データ量は、論理パケットレベルでトラッキングされる請求項５４に記載の請求システム。
【請求項５７】
前記コンテンツがＪａｖａ（Ｒ）ベースである請求項５０に記載の請求システム。
【請求項５８】
前記コンテンツがバイトコード命令を含む請求項５０に記載の請求システム。
【請求項５９】
前記備えることは、コンテンツ検査のバイトコードレベルで達成される請求項５０に記載の請求システム。
【請求項６０】
前記備えられたコンテンツは、セキュリティキーを含み、該セキュリティキーは、該請求データのソースの整合性が受領の際に基づいて検証され得るように、自動的に通信される請求データと共に送信される請求項５０に記載の請求システム。
【請求項６１】
前記セキュリティキーが乱数に基づいている請求項６０に記載の請求システム。
【請求項６２】
前記セキュリティキーがアプリケーションおよび加入者固有である請求項６０に記載の請求システム。
【請求項６３】
前記セキュリティキーは、前記コンテンツをダウンロードするリクエストを受けると、前記コンテンツに備えられる請求項６０に記載の請求システム。
【請求項６４】
前記コンピュータ環境は、無線キャリアインフラストラクチャと統合される請求項５０に記載の請求システム。
【請求項６５】
前記備えられたコンテンツを無線送信媒体を介してターゲットデバイスにダウンロードされるようにすることをさらに含む請求項５０に記載の請求システム。
【請求項６６】
前記コンテンツは、無線送信媒体を介して、前記コンピュータ環境からのキャリアの加入者によって要求される請求項６５に記載の請求システム。
【請求項６７】
前記備えられたコンテンツを有線送信媒体を介してターゲットデバイスにダウンロードされるようにすることをさらに含む請求項５０に記載の請求システム。
【請求項６８】
前記有線送信媒体がインターネットである請求項６７に記載の請求システム。
【請求項６９】
前記請求データは、送られたデータ量、受け取られたデータ量、タイムスタンプ、アプリケーション識別子、セキュリティキー、取引識別子および再試行期限インジケータの少なくとも一つを含む請求項５０に記載の請求システム。
【請求項７０】
前記請求データは、請求サーバシステムへの送信を基準として自動的に通信される請求項５０に記載の請求システム。
【請求項７１】
加入者のデバイスと請求サーバシステムでないサーバシステムとの間での直接の請求データではないデータを送信するために、パケット検出およびフォーワーディングモジュールをさらに含む請求項７０に記載の請求システム。
【請求項７２】
前記請求データを、顧客データレコードを生成するために、顧客ベースの請求情報に統合することをさらに含む請求項５０に記載の請求システム。
【請求項７３】
前記請求データは、複数の請求ポリシーを支援するように用いられる請求項５０に記載の請求システム。
【請求項７４】
前記請求ポリシーは、指定されるアプリケーションに縮小された料金を提供する促進的な申し出を含む請求項７３に記載の請求システム。
【請求項７５】
前記請求ポリシーは、コンテンツプロバイダによって提供される請求項７３に記載の請求システム。
【請求項７６】
前記請求データは、前記コンテンツのプロバイダに印税支払を提供するように用いられる請求項５０に記載の請求システム。
【請求項７７】
前記備えられたコンテンツと前記ネットワークとの間で送信されるデータを、前記送信に基づく請求データに従って、ルーティングされるようにすることをさらに含む請求項５０に記載の請求システム。
【請求項７８】
前記ルーティングは、前記ネットワーク上のリソースの効率的な使用を可能にする請求項７７に記載の請求システム。
【請求項７９】
送信使用法に基づいて、優先順位がコンテンツに割り当てられる請求項７７に記載の請求システム。
【請求項８０】
前記請求トラッキングコードは、プロキシストアおよび転送技術を組み込み、これにより、前記備えられたコンテンツと複数のサーバシステムとの間で請求データおよびデータ送信パケットを送信する、請求項５０に記載の請求システム。
【請求項８１】
データのパケットがネットワークからのコンテンツによって受け取られる場合、該コンテンツの識別子と共に、受け取られたデータ量をログする工程と、
データのパケットが該ネットワークを介して該コンテンツによって送られることになる場合、該コンテンツの識別子と共に、送られるデータ量をログする工程と、
該コンテンツの識別子と共に該ログされたデータ量をサーバシステムに蓄積されるように送信する工程であって、該送信する工程により、該サーバシステムを該蓄積されたデータに基づいて加入者に請求することを可能にする、送信する工程とにより、
無線デバイス中のコンピュータプロセッサをコンテンツ毎を基準にして、パケットベースの請求データを自動的に送信するように制御する命令を含むコンピュータ読み出し可能媒体。
【請求項８２】
前記データ量をログする工程は、前記無線デバイスに透明にロードされるコードにより、実行される、請求項８１に記載のコンピュータ読み出し可能媒体。
【請求項８３】
前記データ量をログする工程および前記ログされたデータを送信する工程は、コードライブラリに常駐するコードにより、実行される、請求項８１に記載のコンピュータ読み出し可能媒体。
【請求項８４】
前記データ量をログする工程および前記ログされたデータを送信する工程は、前記無線デバイスのネットワークドライバソフトウェアに常駐するコードにより、実行される、請求項８１に記載のコンピュータ読み出し可能媒体。
【請求項８５】
前記データ量をログする工程および前記ログされたデータを送信する工程は、送信に基づく請求に対する仕様に書き込まれるコードにより、実行される、請求項８１に記載のコンピュータ読み出し可能媒体。
【請求項８６】
前記データ量をログする工程および前記ログされたデータを送信する工程は、前記クライアントデバイス上の命令の実行前に、前記命令に備えられるコードにより、実行される、請求項８１に記載のコンピュータ読み出し可能媒体。
【請求項８７】
無線デバイスにおいて、パケットベースの請求データを自動的に送信する方法であって、
データのパケットがネットワークから受け取られる場合、受け取られるデータ量をログする工程と、
データのパケットが該ネットワークを介して送られることになる場合、送られるデータ量をログする工程と、
該ログされたデータ量をサーバシステムに蓄積されるように送信する工程であって、該送信する工程により、該サーバシステムが該蓄積されたデータに基づいて加入者に請求することを可能にする、送信する工程とを
包含する方法。
【請求項８８】
前記データ量をログする工程は、前記無線デバイスに透明にロードされるコードにより、実行される、請求項８７に記載の方法。
【請求項８９】
前記データ量をログする工程および前記ログされたデータを送信する工程は、コードライブラリに常駐するコードにより、実行される、請求項８７に記載の方法。
【請求項９０】
前記データ量をログする工程および前記ログされたデータを送信する工程は、前記無線デバイスのネットワークドライバソフトウェアに常駐するコードにより、実行される、請求項８７に記載の方法。
【請求項９１】
前記データ量をログする工程および前記ログされたデータを送信する工程は、送信に基づく請求に対する仕様に書き込まれるコードにより、実行される、請求項８７に記載の方法。
【請求項９２】
前記データ量をログする工程および前記ログされたデータを送信する工程は、前記クライアントデバイス上の命令の実行前に、前記命令に備えられるコードにより、実行される、請求項８７に記載の方法。
【請求項９３】
パケットベースの請求データを自動的に送信する無線デバイスであって、
データのパケットがネットワークから受け取られる場合、受け取られるデータ量をログし、
データのパケットが該ネットワークを介して送られることになる場合、送られるデータ量をログし、
該ログされたデータ量をサーバシステムに蓄積されるように送信し、これにより、該サーバシステムを該蓄積されたデータに基づいて加入者に請求することを可能にする、
請求およびトラッキングコードを備えたアプリケーションを含む、無線デバイス。
【請求項９４】
前記請求およびトラッキングコードは、前記無線デバイス上に透明にロードされる請求項９３に記載の無線デバイス。
【請求項９５】
前記請求およびトラッキングコードは、コードライブラリに常駐する請求項９３に記載の無線デバイス。
【請求項９６】
前記請求およびトラッキングコードは、前記無線デバイスの前記ネットワークドライバソフトウェアに常駐し、前記アプリケーションから呼び出される請求項９３に記載の無線デバイス。
【請求項９７】
前記請求およびトラッキングコードは、送信に基づく請求に対する仕様に書き込まれる請求項９３に記載の無線デバイス。
【請求項９８】
前記請求およびトラッキングコードは、前記アプリケーションの実行前に該アプリケーションに備えられる請求項９３に記載の無線デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
（発明の背景）
（発明の分野）
本発明は、送信に基づく請求のための方法およびシステムに関し、より詳細には、ネットワークを介して送信されたデータに基づいて無線および有線アプリケーションの使用を請求するための方法およびシステムに関する。
【背景技術】
【０００２】
（背景情報）
今日では、無線デバイスは、世界の多くの共同体で実を結ぶようになってきている。無線電話、ハンドセット、パーソナル情報マネージャ、電子オーガナイザ、携帯情報端末、ポータブル電子メールマシン、ゲームマシン、および他のデバイス等のデバイスが、われわれの生活に便宜を与えるために、電話キャリアの加入者によって使用される。しかし、このようなデバイス上で使用されたソフトウエア、ならびにこのようなソフトウエアの使用のためにこれらのデバイスに展開および請求するためのメカニズムは難解である。典型的には、アプリケーションまたは他のサービスが無線デバイスにロードされる（一度に、一律料金で）場合、アプリケーションまたは他のサービスは、加入者ベース（アプリケーションおよびサービスのセットの全体の使用に対する手数料、あるいは全体の回線使用時間（ａｉｒｔｉｍｅ））で請求される。より最近の第三世代であるＧＰＲ等の無線ネットワークでは、キャリアは、デバイスによって使用された物理パケットの全体の数またはデバイスによって使用されたデータの量を識別することが可能である。従って、典型的なネットワークキャリアに対する請求モデルは、一律料金または加入者ベースの請求を反映し、アプリケーションおよびサービスの使用を必ずしも正確に反映しない。例えば、デバイス上で動作する間に、ネットワークにアクセスする無線アプリケーション（例えば、カレンダ、ブラウザ、または電子メールクライアント）は、典型的には、ネットワークにアクセスしないアプリケーションとは異なるキャリアリソース（例えば計算器またはテキストエディタ）を利用する。キャリアまたはコンテンツプロバイダは、特定のアプリケーションが消費するキャリアリソースの量に対して正確に料金請求することが利用できない。なぜなら、無線キャリアレベルにおいて提供された現在の請求システムは、ダウンロード時を除いてアプリケーションレベルに対して異なった請求を提供することができないからである。
【発明の開示】
【課題を解決するための手段】
【０００３】
（発明の簡単な要旨）
本発明の実施形態は、送信に基づく請求のためのコンピュータおよびネットワークに基づく方法およびシステムを提供する。この方法およびシステムは、アプリケーション間に送信されたデータの量またはコンテンツの他のタイプのコンテンツ、ならびにネットワークに基づいた請求情報のトラッキングを提供する。例示的な実施形態は、パケットベースの請求システム（Ｐａｃｋｅｔ−Ｂａｓｅｄ  Ｂｉｌｌｉｎｇ  Ｓｙｓｔｅｍ（「ＰＢＢＳ」））を提供し、このシステムは、キャリアおよびサードパーティコンテンツプロバイダ等のアプリケーションプロバイダが無線デバイス等のモバイル加入者デバイス、アプリケーション毎、利用の程度に基づいたユーザ毎のベースでアプリケーション／サービス（一般的には「コンテンツ」）の使用に対してクライアントまたは加入者（一般的には「ユーザ」）に請求することを可能にする。本発明の実施形態はまた、同じ技術を用いて、有線加入者デバイスに対するアプリケーション毎、ユーザ毎を基本として加入者に請求するために使用され得る。
【０００４】
ＰＢＢＳは、請求トラッキングコードおよび関連する通信サポート（概して本明細書中では、まとめて「請求トラッキングコード」と呼ぶ）を決定かつ提供し、アプリケーション、ならびにサービスプロバイダまたは他のコンテンツプロバイダ（典型的にはキャリア）が、ネットワークを介してアプリケーションまたはサービスによって転送かつ／または受信されたデータの量に基づいて、構成可能な論理パケットレベルに関する請求情報を自動的にトラッキングすることを可能にする。無線デバイスおよび無線ネットワークの場合では、この請求データは、従来の「全体の回線使用時間」使用モデルの代わりにアプリケーション毎を基本としてネットワークの利用をトラッキングする。トラッキングされたデータは、特定のユーザに関連付けられることにより、アプリケーションまたはサービスプロバイダが、ユーザ毎、実際の使用量に基づいたアプリケーション毎を基本として請求することを可能にする。一実施形態では、トラッキングかつ転送された請求データは、ネットワークを介して転送／受信されたデータ量、タイムスタンプ、アプリケーション識別子、セキュリティキー、トランザクション識別子、および再試行期限インジケータを含む。他の実施形態では、請求データは、これらのデータのサブセットを含んでもよいし、異なるまたはさらなるデータを含んでもよい。アプリケーション／サービスプロバイダは、経時的に変化し得る、アプリケーションまたはユーザレベルにおける種々の請求ポリシーを連続的にインプリメントし得る。
【０００５】
一実施形態では、ＰＢＢＳは、クライアントデバイス上に請求データをトラッキングかつ蓄積し、プロキシサーバまたは請求サーバ等のサーバにデータを転送するために、コンテンツへのパケットベースの請求トラッキングコードを具備する。Ｊａｖａ（Ｒ）アプリケーション、．ＮＥＴアプリケーションおよび他のバイナリアプリケーション等のあるコンテンツに対して、計装がバイトコードレベルで達成される。１つのこのような実施形態では、計装は、データ構造、呼び出しシーケンス、任意のネットワーク呼び出しの位置および識別を決定するためのコンテンツを解析し、請求およびトラッキングコードを含むプロキシネットワーク呼び出しによってこれらの呼び出しを置換するコンテンツ（コード）モディファイアによって実行される。
【０００６】
別の実施形態では、請求トラッキングコードは、書き込まれた仕様に従ってコンテンツを修正することによってコンテンツに組み込まれる。さらに別の実施形態では、請求トラッキングコードは、アプリケーションプログラミングインターフェースライブラリへの呼び出しを介してコンテンツに組み込まれる。さらに別の実施形態では、請求トラッキングコードは、クライアントデバイス上のネットワークドライバソフトウエアに置かれ、プロキシ／請求サーバと直接インターフェースを取る。
【０００７】
さらに別の実施形態では、セキュリティキーは、請求データがクライアントデバイスから転送される場合、請求トラッキングコードがプロキシサーバに対してコード自体を識別することを可能にするために挿入される。１つのこのような実施形態では、各セキュリティキーは、コンテンツ／ユーザの組み合わせに一意的に関連付けられた数であり、不正支出および虚偽請求データを避けるために安全なデータレポジトリに格納される。別の実施形態では、セキュリティキーは、固有のランダムナンバーである。
【０００８】
一実施形態では、ＰＢＢＳは、コンテンツ（コード）モディファイア、請求トラッキングコードを含む異なるプロキシネットワーク呼び出しに対するネットワーク呼び出しの関係を含む。すなわち、１つ以上のデータレポジトリ、請求データのためのビジネス規則、生の請求データ、およびセキュリティキー、プロキシサーバ、請求サーバ、およびアカウンティングプログラムである。本実施形態に従って、ＰＢＢＳ機能は、アプリケーション取得システムにおいて異なるプログラムに統合され、異なるコンポーネントを介して分散され得る。次いで、これらのコンポーネントは、請求トラッキングコードを決定し、このコードをコンテンツに挿入するように相互作用し、請求トラッキングコードからデータを受信し、そして請求レコードを生成するために示された請求ポリシーと共にトラッキングされたデータを処理する。一実施形態では、請求トラッキングコードは、アプリケーションに対するクライアントデバイスからのリクエストに応答して挿入され、修正されたアプリケーションは自動的に返信される。次いでこの請求データは、修正されたアプリケーションがクライアントデバイス上で実施される場合に転送される。別の実施形態では、請求データは、ストリーミングオーディオおよびビデオ等のストリーミングコンテンツに対するクライアントデバイスからのリクエストに応答して直接生成される。なぜなら、リクエストは、特定のバイト数またはデータの量のためにあるためである。これらの実施形態の１つでは、アプリケーション取得システムは、有線デバイスにアプリケーションを提供する。別の実施形態では、アプリケーション提供システムは、有線デバイスのためのアプリケーションを提供する。
【０００９】
別の実施形態では、送信に基づくデータは、アプリケーションから他のサーバにネットワークパケットをルーティングするために使用される（ネットワークトラフィック）。本実施形態に従って、送信に基づく（請求）データは、アプリケーションが消費しているリソースの程度を決定することにより、プロキシサーバがより大きい効率性を生成し、例えば、著しく使用されたかまたは人気のあるアプリケーション、あるいはいくつかの他の基準に基づくアプリケーションに対するより良好な応答時間を提供／保証するようにネットワークトラフィックに指示し得ることを決定するために使用される。
【発明を実施するための最良の形態】
【００１０】
（発明の詳細な説明）
本発明の実施形態は、送信に基づく請求のためのコンピュータおよびネットワークに基づく方法およびシステムを提供する。この方法およびシステムは、アプリケーション間に送信されたデータの量またはコンテンツの他のタイプ、ならびにネットワークに基づいた請求情報のトラッキングを提供する。例示的な実施形態は、パケットベースの請求システム（「ＰＢＢＳ」）を提供し、このシステムは、キャリアおよびサードパーティコンテンツプロバイダ等のアプリケーションプロバイダが、利用の程度に基づいたアプリケーション毎、ユーザ毎を基本として無線デバイス等のモバイル加入者デバイス上のアプリケーション／サービス（一般的には「コンテンツ」）の使用に対してクライアントまたは加入者（一般的には「ユーザ」）に請求することを可能にする。本発明の実施形態はまた、同様な技術を用いて、有線加入者デバイスに対してもアプリケーション毎、ユーザ毎を基本として加入者に請求するために使用され得る。本説明は、主にアプリケーションを参照するが、当業者は、本明細書中で説明された本方法およびシステムが、ネットワークを介してパケットレベル（サービスおよびリソース等）で送信され得る任意の他のタイプのコンテンツに適用可能であり、これらがクライアントデバイス上で「実行される」場合、請求データをサーバに通信することが可能であることを理解する。例えば、オーディオまたはビデオ等を再生するためのエンジンはこれらの方法に従って送信に基づく請求に対して修正され得る。さらに、本明細書中で説明された方法およびシステムは、ストリーミングされ得る、テキスト、ビデオ、オーディオ、グラフィックス等のコンテンツに拡張可能である。
【００１１】
ＰＢＢＳは、請求トラッキングコードおよび関連する通信サポート（本明細書中では、まとめて「請求トラッキングコード」と呼ぶ）を動的に提供し、アプリケーション、ならびにサービスプロバイダまたは他のコンテンツプロバイダ（典型的にはキャリア）が、ネットワークを介してアプリケーションまたはサービスによって送信かつ／または受信されたデータの量に基づいて構成可能な論理パケットレベルに関する請求情報を自動的にトラッキングすることを可能にする。トラッキングされたデータは、特定のユーザに関連付けられることにより、コンテンツプロバイダが、実際の使用量に基づいたユーザ毎、アプリケーション毎を基本として請求することを可能になる。コンテンツプロバイダ（本明細書中では、概して任意のタイプのコンテンツプロバイダを指すように使用される）は、以後、アプリケーションまたはユーザレベルにおける種々の請求ポリシーをインプリメントし得る。この請求ポリシーは経時的に変更され得る。例えば、アプリケーションプロバイダは、例えば、加入者によって頻繁に使用される場合、特定の加入者に対するこれらのアプリケーションによって受信／転送されたパケットの量によって測定されるために、人気のあるアプリケーションに対するより低い料金を望み得る。別の例のとしては、通常料金と比較してその特定のアプリケーションに対して送信量当たりほとんど課金されないために、サービスプロバイダは、新しいアプリケーションに対する促進をインプリメントすることを望み得る。
【００１２】
図１は、例示的な送信に基づく請求システムの概略的ブロック図である。図１では、パケットベースの請求システム１００は、いくつかのコンポーネントを含む。すなわち、請求トラッキングコードを含むようにリクエストされたコンテンツを修正するためのコンテンツ（コード）モディファイア１０３、送信および請求トラッキングコードを格納するための構成データレポジトリ１０５、ターゲット（クライアント）デバイスにダウンロードされるコンテンツから請求データを受信かつ収集するためのプロキシサーバおよび／または請求サーバ１０４、請求情報を収集するための収集された請求データ、ならびに請求データおよびビジネス規則を格納する他の請求データレポジトリ１０６、そして収集された請求データを読み出し、カスタマ請求レコード１０８を発生させるアカウンティングプログラム１０７である。以下のさらなる詳細において説明されるように、ＰＢＢＳコンポーネントは、典型的には、ターゲットデバイスにコンテンツを提供するシステムに統合される。動作において、パーソナルコンピュータ１０１または無線ハンドセット１０２等のクライアントデバイスは、コンテンツを提供するシステムから、アプリケーション等のコンテンツをリクエストする。コンテンツは、無線ネットワークを介して無線デバイス（ハンドセット１０２等）に接続されるシステムからリクエストされ得るか、または接続されるシステムから有線ネットワークを介して、有線デバイス（パーソナルコンピュータ１０１等）に接続されるシステムからリクエストされ得る。コンテンツをリクエストするプロセスの一部に対して、システムが、リクエストされたコンテンツを決定および取り出した後、コンテンツモディファイア１０３は、コンテンツを解析し、どのタイプの請求トラッキングコードがリクエストされたコンテンツに挿入される必要があるかを決定し、それに従って、コンテンツをユーザが気付くことなく修正するために構成データレポジトリ１０５を調べる。次いでこの修正されたコンテンツは、ダウンロードするためにクライアントデバイス１０１／１０２に戻される。以後の時間において、ダウンロードされた修正されたコンテンツがクライアントデバイス１０１／１０２上で実行された場合、請求トラッキングコードが、請求データを収集し、これをプロキシ／請求サーバ１０４に転送するように自動的に実行される。請求サーバ１０４は、ビジネス規則に従って、受信された請求データを収集し、これを請求データレポジトリ１０６に格納する。次いでアカウンティングプログラム１０７は、カスタマ請求レコード１０８を生成するように、収集された請求データを取り出し得る。典型的には、アカウンティングプログラムは、無線ネットワーク環境におけるキャリア等、請求に対して責任があるサービスの必要性に適応するように特別に設計される。
【００１３】
例示的な請求データは、転送および／または受信されたバイト数、タイムスタンプ、アプリケーション識別子、ユーザ識別子（請求データが無線ネットワークを介して転送される場合、キャリアインフラストラクチャによって自動的に転送された）、セキュリティキー、トランザクション識別子、および再試行終了インジケータを含む。トランザクション識別子は、典型的には、個々の／異なる請求トラッキング「イベント」を識別するために使用される。クライアントデバイスは、転送動作が失敗することを認識する場合、この再試行終了インジケータは、どれくらい長くクライアントデバイスが同じ請求データの再転送を継続すべきであるかどうかを示す。同様に、プロキシ／請求サーバは、重複受信転送を検出するためにどれくらい長くトランザクション識別子が有効であるかを決定するために再試行終了インジケータを使用する。
【００１４】
一実施形態では、ＦＢＢＳコンテンツモディファイア（例えば、図１のコンテンツ（コード）モディファイア１０３）は、本発明の技術を達成するためにリクエストされたコンテンツにパケットベースの請求トラッキングコードを具備させる。本明細書中で使用する場合、計装は、さらなるコードを含むようにコンテンツ（例えばアプリケーション）を修正するための割り込みのない（ｎｏｎ−ｉｎｔｒｕｓｉｖｅ）手段であり、この場合、請求トラッキングおよび送信コードである。一実施形態では、コンテンツに常駐しているネットワーク呼び出しがＰＢＢＳコードモディファイアによって検出され、送信に基づく請求専用の請求トラッキングコードによって置換されることにより、この請求トラッキングコードは、パケットベースの請求データを計算かつ収集し、元の特殊なネットワーク呼び出しを呼び出す。この意味において、計装は、ネットワーク呼び出しを遮断するための方法として、ネットワーク呼び出しの前後において「フック」として使用される。異なる環境において異なるコンテンツが種々のネットワーク呼び出しを使用し、異なるプロバイダが異なる請求ポリシーを有するために、ＰＢＢＳコードモディファイアは、どの置換ネットワーク呼び出しがコンテンツを具備するかどうかを決定するために、構成データレポジトリ（図１における構成データレポジトリ１０５等）を使用する。この置換呼び出しは、ターゲットデバイス上の一時的なストレージに収集された請求データをローカルに格納し得、次いで、コンテンツが実行を終了する場合（例えば、アプリケーションが終了する場合）、収集されたデータを転送する。あるいは、収集されたデータは、各ネットワーク呼び出し応じて転送され得る。さらに、デバイス上のサイクリングパワー（ｃｙｃｌｉｎｇ  ｐｏｗｅｒ）の後に転送され得るように、収集されたデータは、クライアントデバイス上の永久ストレージに格納され得る。当業者は、データが転送される場合の異なるシナリオが可能であり、これらの技術と共に作用することが企図されることを理解する。
【００１５】
図２は、パケットベースの請求システムのコンテンツ（コード）モディファイアによって実行されたような請求トラッキングコードを用いて具備されたコンテンツの例示的なブロック図である。例えば、アプリケーション２１０等のコードは、解析および具備のためにコード識別子２０１に転送される。アプリケーション２１０内部のルーチンの呼び出し順序が概略的に示される（呼び出し順序解析を受けた後）。示された順序に従って、「ｓｔａｒｔｕｐ（）」ルーチン２１１が呼び出され、次にネットワーク呼び出し２１２が続き、次にアプリケーションクリーンアップのための「ｅｎｄ（）」ルーチン２１３が続き、次に、アプリケーション実行を終了させる終了呼び出し２１４が続く。コンテンツモディファイア２０１は、構成データレポジトリ２０２においてネットワーク呼び出しを参照し、送信に基づく請求およびトラッキングをインプリメントするためのコードを含む対応するネットワーク呼び出し２２２を決定かつ取り出す。対応するネットワーク呼び出し２２２は、元のネットワーク呼び出し２１２を呼び出すためにインプリメントされ、それにより、元のネットワーク呼び出し２１２に対する「フック」を提供する。このコンテンツモディファイア２０１はまた、どのようにして周波数請求情報が転送されるか等の請求に対する構成パラメータ（例えば、データの特定の時間または量が送信された後）、および請求データが転送されるべきプロキシサーバのネットワークアドレスを決定するために、構成データレポジトリ２０２を調べる。次いでコンテンツモディファイア２０１は、決定された構成パラメータによって示されたように、取り出されたネットワーク呼び出し２２２および請求データを転送するためのコードを用いてアプリケーションに具備させる。例示的に修正されたアプリケーション２２０の概略図は、計装が実行された後、呼び出し順序によって示される。修正されたアプリケーション２２０では、「ｓｔａｒｔｕｐ（）」ルーチン２１１が呼び出され、次に具備されたネットワーク呼び出し２２２（元のネットワーク呼び出し２１２の後に続く）に続き、「ｅｎｄ（）」ルーチン２１３が続く。コンテンツモディファイアはまた、所定の構成パラメータに従って請求データをプロキシ／請求サーバに転送するためにコード２２３を具備させる。この転送コード２２３は、「ｅｎｄ（）」ルーチン２１３と終了呼び出し２１４との間の順序で示される。アプリケーションの終了時に請求データを転送するコードを有することによって、請求データがより以前に転送されたとしても、任意の以前に失敗した転送の再試行転送を試みる。一実施形態では、最後の転送呼び出し２２３が失敗する場合、請求データは、単に失敗して無視されるだけである。他の実施形態は、アプリケーションが再度実行される場合、請求データおよび再試行転送をより永久的に格納するように選択し得る。この再試行終了インジケータは、冗長請求イベントを妨げるように使用され得る。特に、クライアントデバイスは、タイムスタンプに基づいて、再試行期間が終了されるか、または転送コードが同じ請求データを再転送するように試みるべきかどうかを決定する。当業者は、多くのこのような修正が可能であることを理解する。具備された請求トラッキングコードに加えて、いくつかの実施形態では、コンテンツモディファイア２０１が、一旦ダウンロードされた場合、アプリケーションに対する請求データは、偽造請求データを転送することによって着服されることができないことを確実にするために、セキュリティキー２３０を修正されたアプリケーションに追加する。
【００１６】
他の実施形態では、添付物Ｅに詳細に説明されたように、請求トラッキングコードは、割り込みおよび非割り込み手段を含む他の手段によってコンテンツに組み込まれる。例えば、パケットベースの請求トラッキングコードに対する仕様は、このようなトラックング等を明示的に含むようにそれらのコンテンツを修正し得る他のプロバイダに提供され得る。第２の例では、アプリケーションプログラミングインターフェース（「ＡＰＩ」）は、パケットベースの請求トラッキングおよび通信を提供するためにコンテンツ内の適切なポイントにおいてコンテンツプロバイダによって呼び出され得る。さらに第３の例では、無線デバイス等のターゲットデバイスのネットワークドライバソフトウエアは、パケットベースの請求トラッキングコードを含むように修正され得る（仕様またはライブラリ機構を介して）。これらの他の実施形態の全てにおいて、コンテンツプロバイダまたはデバイスドライバ製造業者のいずれかは、請求トラッキングコードおよび通信技術に気付かされる必要があり、それにより、請求サポートを組み込むより多くの割り込み手段を提供する。
【００１７】
ＰＢＢＳコンポーネントおよび機能性は、アプリケーション提供システム等のネットワーク環境において異なるコンポーネントに統合され、異なるコンポーネントを介して分散され得る。次いでこのシナリオでは、コンポーネントを提供することは、請求トラッキングコードを決定し、これをコンテンツに挿入し、請求トラッキングコードからデータを受信し、そして請求レコードを生成するために、示された請求ポリシーと共にトラッキングされたデータを処理するために相互作用する。より詳細には、アプリケーションが加入者によってリクエストされる場合、アプリケーションは、リクエストしているデバイスに対するアプリケーション提供システムによって提供され、リクエストしているデバイスにアプリケーションに対して具備された適切な請求コードと共にダウンロードされる。本明細書で使用された場合、提供することは、特定の使用（例えば、特定のカスタマによる特定の種類の加入者デバイスのために）に対するコンテンツをカスタマイズおよび分配することである。モバイルアプリケーションシステム（ＭＡＳ）と呼ばれた例示的なアプリケーション提供システムは、本明細書中で説明されたＰＢＢＳを用いて使用され得る。添付物Ｄは、アプリケーションへのコードを具備させ、このようなアプリケーションをカスタマイズし、そしてこのアプリケーションを特に無線デバイスに分配するための技術を含む、このようなシステムを詳細に説明する。ＭＡＳは、モバイルおよび有線加入者デバイスにアプリケーション、リソース、および他のコンテンツを提供するために安全な態様で個別にそして共に働く相互動作するサーバコンポーネントの収集である。
【００１８】
図３は、例示的なモバイルアプリケーションシステム環境内部でインプリメントされた例示的な送信に基づく請求システムのブロック図である。示されたモバイルアプリケーションシステム（ＭＡＳ）は、無線接続を介して無線ハンドセット３１０に接続された提供システムである。ＭＡＳのコンポーネントは、とりわけ、コンテンツスキャナ、解析器、および計装器の（ｉｎｓｔｒｕｍｅｎｔｏｒ）能力３０３をその機能の一部として含む提供および展開マネージャ３０２と、請求マネージャ３０５と、構成データレポジトリ３０４と、アカウンティングプログラム３０６とを含む。提供および展開マネージャ３０２のこの計装器能力３０３は、ＰＢＢＳのコードモディファイア機能を提供する。この請求マネージャ３０５は、転送された請求データを収集するためにプロキシサーバの役割を組み込み得る。無線ハンドセット３１０は、典型的にはフラッシュメモリ３１１、または請求データが収集される場合に請求データを保持するためのローカル、半永久ストレージの他のタイプを含む。無線ハンドセット３１０はまた、無線接続を介してインターネット３２０等のパブリックネットワークに接続される。説明を簡単にするために、ハンドセット３１０がＭＡＳ請求マネージャ３０５に請求データを直接的におよび別個に転送するパブリックネットワーク３２０上でサーバへのアドレスを可能にすることが想定されが、この想定は、本明細書中で説明された技術を必ずしも達成するとは限らない。特に、クライアントデバイスが複数のサーバに直接アドレシングすることができない場合、受信されたネットワークパケットの全てに対する格納および送信能力をインプリメントするプロキシサーバが提供され得る。このシナリオでは、プロキシサーバは、パケットを受信し、その意図された宛先（および請求データの受信）を決定し、パケットから請求データを取り出し、そしてその元のパケットデータをその意図された宛先に送信する。
【００１９】
ＰＢＢＳの技術は、一般的には任意のタイプのクライアント無線デバイスに対して利用可能であるが、当業者は、加入者デバイス、クライアントデバイス、電話、ハンドヘルド等の用語は、ＰＢＢＳと共に動作することが可能である任意のタイプの加入者デバイスを示すために交換可能に使用されることを理解する。あるいは、用語は、明示的に説明されてもされなくてもよい代替のスペルを有し得る。例えば、バイト−コード（ｂｙｔｅ−ｃｏｄｅ）は、「バイトコード（ｂｙｔｅｃｏｄｅ）」または「バイトコード（Ｂｙｔｅｃｏｄｅ）」としても示され得、当業者は、このような用語の変動の全てが含まれるべきであることが意図されることを理解する。さらに本明細書中で説明された例示的実施形態は、１つ以上のネットワークを介して送信に基づく請求システムをインプリメントするために、アプリケーション、ツール、データ構造、および他のサポートを提供する。本発明の方法およびシステムの他の実施形態が、ソフトウエア送信に基づく請求サポートをそのソフトウエアに対して具備させ、非無線加入者デバイス（パーソナルコンピュータ、ドッキングされた無線ハンドセット、インターネット接続性を有する電話、またはカスタマキオスク（例えば空港またはショッピングモール内の））に対して、例えばインターネット等の非無線ネットワークを介してソフトウエアおよび他のコンテンツに対して送信に基づく請求サポートを具備させることを含む、多くの他の目的のために使用され得ることを理解する。さらに、この説明は、アプリケーション、サービス、およびリソースの形態でコンテンツを主に参照するが、当業者は、コンテンツがテキスト、グラフィック、オーディオ、およびビデオを含み得ることを理解する。あるいは、以下の説明において、本発明の方法およびシステムの技術の完全な理解を提供するために、データフォーマットおよびコードフロー等の多くの特定の詳細が説明される。しかし、当業者は、本発明はまた、本明細書で説明された、いくつかの特定の細部なしでまたは他の特定の細部（コードフローの順序に関する変更等）を用いて実施され得ることを認識する。
【００２０】
さらに、ＰＢＢＳの技術は、ストリーミングコンテンツと共に動作するように拡張され得る。特に、ストリーミングコンテンツ（テキスト、オーディオ、ビデオ、グラフィックス等）がクライアントデバイスによってリクエストされる場合、リクエストは、ダウンロードするコンテンツの量を示す。コンテンツモディファイアは、請求およびトラッキングコードをコンテンツに挿入する代わりに、請求イベントを直接的に生成し、これらをプロキシ／請求サーバに転送する。
【００２１】
あるいは、当業者は、本発明の技術は、転送かつ受信されたデータの量を決定およびトラッキングすることが、請求データを生成する以外で価値がある他の使用に対して使用され得ることを認識する。例えば、本発明の技術のためのさらなる使用は、ネットワークパケットおよびリクエストのルーティングに関する。特に、コンテンツとネットワークとの間で転送かつ受信されたデータ量に基づいて請求データをトラッキングするための同じ技術は、どのようにしておよびどこでルーティングポリシーに基づいてネットワークパケットをルーティングするかを決定するプロキシサーバによって使用され得る。転送された「請求データ」は、ユーザ、送信されるべきアプリケーションおよびデータの量を識別する情報を含み、これは、トラフィックをルーティングするために、ルーティングシステムによって使用され得る。例えば、アプリケーションサーバは、著しいトラフィックのアプリケーション／ユーザの組み合わせに対して、特定の態様でネットワークトラフィックを分配するかまたは特定のサーバを保存することを望み得ることにより、ある種のロード収支を提供する。
【００２２】
図４は、送信に基づく請求システムの実施形態を実行するための汎用コンピュータシステムおよびクライアントデバイスの例示的なブロック図である。図４のコンピュータ環境は、ネットワーク４１０を介して通信するクライアント（加入者）デバイス４０１および汎用コンピュータシステム４２０を含む。各ブロックは、特定の実施形態で適切であるような１つ以上のこのようなブロックを表してもよいし、他のブロックと組み合わせられてもよい。各ブロックは、別個の物理場所において常駐し得る。
【００２３】
クライアントデバイス４０１は、コンピュータメモリ（「メモリ」）４０２、ディスプレイ４０４、入力／出力デバイス４０３、および中央演算処理装置（「ＣＰＵ」）４０５を含む。修正されたコンテンツ４０６（例えば、実行可能なアプリケーション）は、他のダウンロードされたアプリケーション４０７および請求データ４０８の一時的なストレージのためのデータレポジトリを用いてメモリ４０２に常駐するように示される。この修正されたコンテンツ４０６は、好ましくは、送信データをトラッキングし、ネットワーク４１０を介してプロキシ／請求サーバに請求データを通信するために、前図で示されたようにＣＰＵ４０５上で実行し、挿入された請求トラッキングコードを実行する。
【００２４】
汎用コンピュータシステム４２０は、１つ以上のサーバおよび／またはクライアントコンピューティングシステムを含み得、分配された場所に及び得る。ＰＢＢＳが、ＭＡＳ等のアプリケーション提供システムに統合される一実施形態では、ＭＡＳは、Ｊａｖａ（Ｒ）２  Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ）を用いてインプリメントされ、Ｊ２ＥＥコンプライアントアプリケーションサーバを提供する汎用コンピュータシステム上で実行する。本実施形態に従って、ＭＡＳが、Ｊ２ＥＥマルチティアアプリケーションアーキテクチャを用いて設計かつ符号化され、これは、サーバ側上のウエブティア、ビジネスティア、およびデータベースティアをサポートする。従って、汎用コンピュータシステム４２０は、ＭＡＳおよびＰＢＢＳの１つ以上のコンポーネントおよび／またはデータレポジトリを実行することが可能な１つ以上のサーバを表す。
【００２５】
示されたように、汎用コンピュータシステム４２０は、ＣＰＵ４２３、メモリ４２１、ならびに随意にディスプレイ４２２および入力／出力デバイス４２４を含む。ＰＢＢＳ４３０のコンポーネントは、メモリ４２１に常駐するように示され、好適には、１つ以上のＣＰＵ４２３を実行する。他のデータレポジトリおよび他のプログラム（図示せず）はまた、メモリ４２１に常駐し、好適には、１つ以上のＣＰＵ４２３上で実行する。典型的な実施形態では、ＰＢＢＳ４３０は、コンテンツモディファイア４２５、送信および請求トラッキングコードを格納するためのデータレポジトリ４２７および４２８、請求データおよびビジネス規則、請求サーバ４２６（プロキシおよび請求サーバとして動作するように示される）、ならびにアカウンティングプログラム４２９を含む。上述したように、ＰＢＢＳは、キャリアまたは他のホストシステムの必要性およびこれの統合に応じて、他のデータレポジトリおよびコンポーネントを含み得る。アプリケーション提供システム一部である他のコンポーネントはまた、メモリ４２１（示されないが、提供および展開コンポーネントおよびローカルアプリケーション格納等）に存在する。説明されたように、アプリケーションは、クライアントデバイス４０１にダウンロードする前にコンテンツモディファイア４２５によって請求トラッキングコードを用いて提供かつ具備される。
【００２６】
当業者はＰＢＢＳ４３０が、複数の、一様な、異種のコンピュータシステムおよびネットワークから構成される分配された環境においてインプリメントされ得ることを認識する。例えば、一実施形態では、コンテンツモディファイア４２５および請求サーバ４２６は、物理的に異なるコンピュータシステムに配置される。別の実施形態では、ＰＢＢＳ４３０の種々のコンポーネントは、それぞれ別個のサーバマシン上でホストにされ、データレポジトリ４２７および４２８からリモートに位置付けられ得る。さらに、いくつかのシナリオにおいて、アカウンティングプログラム４２９は、キャリアのインフラストラクチャ内部にホスト化され得、完全にＰＢＢＳから分離され得る。プログラムおよびデータの異なる構成および場所は、本発明の技術を用いて使用するために企図される。
【００２７】
例示的実施形態では、ＰＢＢＳ４２１のコンポーネントは、Ｊａｖａ（Ｒ）２  Ｐｌａｔｆｏｒｍ，Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ，Ｖｅｒｓｉｏｎ  １．２，Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，１９９９に詳細に説明されたように、Ｊ２ＥＥマルチティアアプリケーションプラットフォームを用いてインプリメントされる（ＭＡＳの一部として）。典型的には、コンテンツモディファイア４２５は、ＭＡＳ提供および展開マネージャの一部である（図３に示されたように）。請求マネージャ４２６は、送信に基づく請求に関連付けられた種々の能力を実行するために強化されたＭＡＳのコンポーネントである。測定されるべきコードを格納するためのデータレポジトリ４２７および４２８、ビジネス規則、および請求データは、ＭＡＳの構成マネージャの一部であってもよいし（図３の構成データレポジトリ３０４を参照）、セキュリティの必要性、アカウンティングプログラム４２９等の場所に応じて、別個のデータレポジトリとしてインプリメントされてもよい。図５〜図１３は、図１〜図３を参照しながら記載された機能性を達成するために、これらのコンポーネントの各々によってインプリメントされた特定のルーチンの種々の例示的実施形態を説明する。例示的実施形態では、これらのコンポーネントは、同時にかつ非同期的に実行し得、それにより、コンポーネントは、周知のメッセージ引渡し技術を用いて通信し得る。当業者は、等価の同期実施形態もまたＰＢＢＳインプリメンテーションによってサポート可能であることを理解する。あるいは、当業者は、他のステップが各ルーチンに対して、異なる順序、および異なるルーチンでインプリメントされても、さらになおＰＢＢＳの機能を達成し得ることを認識する。
【００２８】
図１を参照しながら説明されたように、クライアント（加入者）デバイスは、モバイルアプリケーションシステム等のアプリケーション提供システムからアプリケーションをリクエストし得る。ＭＡＳを用いて、アプリケーションは、デバイスおよび加入者に予め提供されてもよいし、ＭＡＳ（「壁のある庭の提供（ｗａｌｌｅｄ  ｇａｒｄｅｎ  ｐｒｏｖｉｓｉｏｎｉｎｇ）」と呼ばれる）内部にローカルに格納されてもよいし、例えば、インターネットを介してサイトをブラウジング（「開いた提供（ｏｐｅｎ  ｐｒｏｖｉｓｉｏｎｉｎｇ）」）することによって、アプリケーションがリクエストされた場合、オンザフライで提供され得る。図５は、送信に基づく請求と共に使用するためのモバイルアプリケーションシステムのためのアプリケーションを転送するためのいくつかの例示的な手順のブロック図である。図５では、サードパーティアプリケーションプロバイダまたはキャリア等のコンテンツプロバイダ５０１は、提供システムのためのアプリケーションを転送する（本明細書中では、ＭＡＳ５０２として示される）。ＭＡＳ５０２は、アプリケーションをローカルストレージ５０３に格納する（生データまたは予め提供されたもののいずれかとして）。コンテンツプロバイダ５０１はまた、請求データレポジトリ５０４におけるＭＡＳ５０２によって適切に格納されるビジネス規則に関連した請求を提供する。これらの規則は、請求データを転送するための頻度または間隔などの請求関連情報、請求データを転送するためのプロキシサーバのアドレス、論理パケットの大きさ、および論理パケットサイズに関連付けられた請求課金情報を示す。当業者は、アプリケーション特有またはユーザ特有である他の請求関連ビジネス規則もまた必要とされた場合格納され得ることを理解する。
【００２９】
図６は、モバイルアプリケーションシステムを用いてクライアントデバイスへの送信に基づく請求を支援するアプリケーションを気付かれずに配信するための全体のプロセスを示す例示的なブロック図である。クライアントデバイス６０１は、コマンドハンドラ６０２を用いてＭＡＳ６０２からアプリケーションをリクエストする。コマンドハンドラ６０２は、ＭＡＳに対するリクエストを処理する。コマンドハンドラ６０２は、アプリケーションリクエストをＭＡＳの適切なコンポーネント（ＭＡＳ提供および展開マネージャ（図示せず）等）に分配することに対して責任がある。コンテンツモディファイア機能性も含むこれらのコンポーネントは、リクエストされたアプリケーションに対応するアプリケーションがキャッシュ６０３に既に存在するかどうか、またはアプリケーションが展開のために提供される必要があるかどうかを決定する。提供プロセスの一部として、請求トラッキングコードは、アプリケーション６０５に具備され、セキュリティキー６０６が追加されて修正されたアプリケーション６０４を生成する。具備された請求トラッキングコードを有する提供されたアプリケーションがキャッシュ６０３において利用可能である場合であっても、セキュリティキーを生成することが必要であり得る（使用された技術に応じて）。好ましくは、セキュリティキー６００が生成され、関連付けられたアプリケーション識別子およびアプリケーション識別子と共に安全なデータレポジトリ６０７に格納される。加入者およびアプリケーションに一意に関連付けられるセキュリティキーを生成するための任意の機構が組み込まれ、本発明の技術と共に使用され得る。１つの機構は、ｎビット乱数を生成し、この乱数を、固有のアプリケーション識別子および固有の加入者識別子を用いてある態様で組み合わせることである。この機構は、単一のセキュリティキーが、アプリケーション／加入者の組み合わせの１より多くに対して再使用されることを可能にする。なぜなら、このキーは、各アプリケーション／加入者の組み合わせに固有に結合されるからである。従って、修正されたコンテンツ（請求トラッキングコードおよびセキュリティキーを含む）がキャッシュされ、それにより、コンテンツの高速ダウンロードが可能になり得る。あるいは、固有のセキュリティキーが、コンテンツのアプリケーション／加入者バージョンの各々に関連付けられ得る。セキュリティキーの目的は、請求データが収集および処理のためにプロキシ／請求サーバに転送される場合、特定の加入者およびアプリケーションに一意に属するものとして以後認識され得る数を生成することである。修正されたアプリケーション６０４は、キャッシュ６０３に随意に格納され、コマンドハンドラ６０２を介してリクエストクライアントデバイス６０１に戻される。リクエストが適切なダウンロードを失敗し、クライアントデバイス６０１が同じアプリケーションに対するリクエストを再試行する場合において、短期間で修正されたアプリケーション６０４をキャッシュ６０３に格納することが望ましくあり得る。しかし、ここで、一実施形態では、このアプリケーションに追加されたセキュリティキーは、特定の加入者に関連付けられることに留意のこと。このシナリオでは、セキュリティキーを有する修正されたアプリケーション６０４をキャッシュ６０３に格納することは、異なるアプリケーション／加入者の組み合わせに展開することに対して意味を成さない。
【００３０】
図７は、送信に基づく請求をサポートするためにアプリケーションを修正するためのルーチンの例示的なフローチャートである。このルーチンは、典型的には、提供および展開プロセスの一部として実行される（図２のコンテンツモディファイア２０１を参照のこと）。要するに、ルーチンは、具備された請求トラッキングコードを有する指定されたアプリケーションのバージョンを決定または生成し、アプリケーションに挿入される適切なセキュリティキーを決定または生成し、そして修正されたアプリケーションをリクエスタに戻す。特に、ステップ７０１では、ルーチンは、指定されたアプリケーションを有するアプリケーションリクエストをパラメータとして受信する。ステップ７０２では、ルーチンは、具備されたアプリケーションが既に利用可能であるかどうか決定し（例えば、図６におけるキャッシュ６０３に格納される）、利用可能である場合、ステップ７０５に進み、利用可能でない場合、ステップ７０３に進む。ステップ７０３では、ルーチンは、アプリケーションのコードフローを解析し、請求トラッキングコードをアプリケーションに具備させる。このプロセスは、図８を参照しながら以下にさらに説明される。ステップ７０４では、ルーチンは具備されたアプリケーションを、例えばアプリケーションキャッシュに格納し、ステップ７０７に進む。ステップ７０５では、具備されたアプリケーションが既に利用可能であることを決定した後、ルーチンは、ローカルストレージ（例えばキャッシュ）から具備されたアプリケーションを取り出し、ステップ７０６に進む。ステップ７０６では、ルーチンは、取り出されたアプリケーションが、それに取り付けられるかまたは関連付けられたセキュリティキーを既に有するかどうかを決定する。セキュリティキーを既に有する場合、セキュリティキー（またはセキュリティキーを用いて修正されたアプリケーション）を取り出すためにステップ７１０に進み、セキュリティキーをまだ有さない場合、ステップ７０７に進む。制限された期間において潜在的な着服を制限するための具備されたアプリケーションを用いて取り付けられたセキュリティキーを保持することが望ましくあり得る。ステップ７０７では、ルーチンは、アプリケーションのための新しいセキュリティキーを生成する。図６に説明された機構を含む任意の適切なセキュリティ機構が利用され得る。ステップ７０８では、ルーチンは、新しく生成されたセキュリティキーを安全なデータレポジトリに格納する。ステップ７０９では、ルーチンは、新しいセキュリティキーをアプリケーションに具備させる。ステップ７１１では、ルーチンは、具備された請求トラッキングコードおよびリクエスタに対するセキュリティキーを含む修正されたアプリケーションを送信し、そして処理を終了する。
【００３１】
図８は、送信に基づく請求に対するサポートを有するアプリケーションを解析および具備するためのルーチンの例示的なフローチャートである。このルーチンは、図２に示されたような送信に基づく請求に対するサポートを含む修正されたアプリケーションにアプリケーションを変換する。ステップ８０１では、ルーチンは、アプリケーションの構造および呼び出し順序のフローをスキャンかつ解析し、好適には、バイトコードレベル（時には、「バイナリアプリケーション」と呼ばれる）において、データ構造（パッケージ、クラス、方法、およびフィールド定義）および呼び出し順序を理解する。この分解／デコードプロセスの一部として、ルーチンは、アプリケーション中に存在するＡＰＩの全てを検出し、任意のネットワーク呼び出しを識別する。この解析の結果、ステップ８０２では、ルーチンは、どのコードがネットワークを呼び出すかを識別し、それにより、呼び出しがアプリケーション内部に配置される。アプリケーションがＪａｖａ（Ｒ）で符号化される場合、この解析は、プログラムのバイトコード（またはバイナリ）レベルで実行され得、ソースレベルにおいて解析生成コードを挿入する必要がない（バイトコードレベルは、バイナリコードの「中間レベル」を参考にし、実行するために「エンジン」、「バイトコード」、インタープリター、または「仮想マシン」等によって解釈される）。当業者は、データ構造および呼び出し順序を提供することが検出かつ解析され得ることによって、他の実施形態が他の言語およびコンテンツに対してインプリメントされ得ることを理解する。当業者は、他の実施形態が他の言語およびコンテンツに対してインプリメントされ、データ構造および呼び出し順序を提供することが検出および解析され得ることを認識する。特にＪａｖａ（Ｒ）および．ＮＥＴアプリケーションがこのようなプロセスに固有に適応される。なぜなら、これらのアプリケーションは、駆動された命令であるためである（すなわち、異なるバイトコードが異なる言語エレメントを示すために使用される）。他の中間コード言語が同様に解析され得る。ステップ８０３において、ルーチンはアプリケーション内部に位置付けられたネットワーク呼び出しに対応するプロキシネットワーク呼び出しを決定する。これらのプロキシ呼び出しは、典型的には、特定のデバイスおよびプロトコルに種々のネットワーク呼び出しを関連付ける配置データレポジトリから決定される。添付物Ａは、位置付けられたネットワーク呼び出しをプロキシネットワーク呼び出しにマッピングするための例示的な擬似コードを含む。ステップ８０４では、ルーチンは、例えば、キャリアによって特定されたようにこのアプリケーションに適応する特定のビジネス規則を決定する。冒頭で説明されたように、これらの規則は、プロキシ／請求サーバに転送されるべき請求データに対する間隔／頻度、課金するために使用されるべきパケットの論理的大きさ、およびパケットに関連付けられた課金を規定し得る。規則の拡張セットは、アプリケーションまたはユーザ毎を基本として特定され得る。当業者は、他のビジネス規則が適切なように特定され得、経時的に変化され得ることを理解する。例えば、いくつかのシステムでは、アプリケーションプログラマによってデフォルト課金情報を提供することが可能にされ得、この情報は、キャリア（すなわちＰＢＢＳ）による標準的な乗算器によって修正され得る。ステップ８０５では、図２に示されるように、ルーチンは、アプリケーション内で識別されたネットワーク呼び出しをプロキシネットワーク呼び出しに置換する。図２に示されるように、ステップ８０６では、ルーチンは、アプリケーション処理の終了時において請求データを転送するために最後のプロキシネットワーク呼び出しを追加する。典型的には、以前のプロキシネットワーク呼び出しシステムが失敗した場合に転送された請求データをプロキシ／請求サーバに呼び出しても、この呼び出しは典型的には追加される。以前のプロキシネットワーク呼び出しがクライアントデバイス上でデータをローカルに収集する状況において、データを転送するための最終呼び出しは、ビリングデータの蓄積されたセットの請求データと通信する。
【００３２】
図１を参照して説明されたように、修正されたコンテンツがクライアントデバイス上で実行される（処理される）場合、請求トラッキングコードがアクティブ化され、データを収集し、そのデータを、ＰＢＢＳに関連付けられたプロキシ／請求サーバに自動的に転送する。図９は、アプリケーション毎を基本としてネットワーク送信データに基づいて請求データを通信するための全体のプロセスを示す例示的なブロック図である。例示の目的のためではあるが、コンポーネントは、アプリケーション提供システムのインターネットの一部であることが想定される。当業者は、冒頭で説明されたように、ＰＢＢＳの機能を実行することが可能な任意のコンテンツ配信システムに統合され得ることを理解する。図９では、クライアントデバイス９０１は、アプリケーションに以前に具備された転送コードの結果として、請求データ（ネットワークパケットを介して）をプロキシサーバ９０２に転送する（図２および図８を参照のこと）。プロキシサーバの２つの異なるタイプは、デバイスの能力に応じてインプリメントされ得る。特に、いくつかのデバイスは、１より多いサーバにパケットを直接転送し得る。その場合、いくつかのサーバに向かうパケット９０９は、サーバに直接転送されつつ、請求データは、プロキシサーバ９０２に直接転送され得る（このようなセットアップは、時には計算およびログアプローチと呼ばれる）。他のデバイスは、ネットワークパケットを１つのみのサーバに転送することができる。このシナリオでは、プロキシサーバ９０２は、格納および送信プロキシサーバとして作用し、ネットワークパケットをそれらの意図された宛先に分配して、転送された請求データを有するパケットのみを処理する。別個のサーバである場合、プロキシサーバ９０２は、転送されたデータを収集し、適切なものとしてそのデータを請求サーバ９０３に送信する。いくつかの実施形態では、プロキシサーバおよびビリングサーバが組み合わせられる。しかし、いくつかの状況では、例えばセキュリティに関連のために、プロキシおよび請求サーバを分離することが望ましくあり得る。別の例のように、請求サーバは、既に存在し得、プロキシサーバがインターフェースを取る特定のデータ収集プロトコルを有し得る。一旦、収集された請求データが受信されると、請求サーバ９０３は、請求データと共に転送されたセキュリティキーが、そのセキュリティキーと、セキュリティデータレポジトリ９０５におけるその特定のアプリケーションおよびそのユーザに対する予測されたセキュリティキーとを比較することによって合法的であるかどうかを決定する。セキュリティキーが合法的である場合、請求サーバ９０３は、生の請求データをデータレポジトリ９０６に格納する。請求サーバ９０３は、例えば、レポジトリ９０６に格納されたビジネス規則に従って請求データを随意に後処理し得る。当業者は、データレポジトリが例示のみのために示されたように分離されること、および単一のデータレポジトリなどの他の組み合わせが使用されることを認識する。さらに、プロキシサーバ９０２は、請求サーバ９０３によって非同期的に処理されるべき生の請求データを直接格納し得る。アカウンティングプログラム９０４は、請求データ（生のまたは後処理された）をデータレポジトリ９０６から取り出し、随意に無効なビジネス規則（例えば、データレポジトリ９０７に格納されたような）を使用し、請求データをさらに処理し、呼び出し（カスタマ）データレコード９０８を生成する。無効なビジネス規則は、例えば、特定のアプリケーションまたは加入者の無効、宣伝（ｐｒｏｍｏｔｉｏｎ）等を含み得る。
【００３３】
図１０は、請求データを収集し、そして転送するために修正されてきたデータをネットワークに転送するためのクライアントルーチンの例示的なフローチャートである。このルーチンは、いくつかのタイプの「ｓｅｎｄ＿ｄａｔａ」ネットワーク呼び出しを置換する例示的なプロキシネットワークコードを示す。ネットワークを介してデータを転送するプロキシネットワークコードの例示的な擬似コードインプリメンテーションは、添付物Ｂに含まれる。このルーチンは、転送されるべきデータの量をトラッキングかつ蓄積し、蓄積された量が請求データを転送するための頻度／間隔に対するルーチンに組み込まれたビジネス規則に対応する場合、請求データが転送される。特に、ステップ１００１では、ルーチンは、現在のパケットにおいて転送されるデータの量を決定し、そのデータを蓄積する（例えば、可変「ｄａｔａ＿ｏｕｔ」において）。ステップ１００２では、ルーチンは、ローカルストレージにおけるタイムスタンプ、アプリケーション識別子、およびセキュリティキーと共に現在のパケットにおけるデータの量を格納する。ステップ１００３では、ルーチンは、データを転送する時間になっているかどうか（例えば、時間／頻度の符号化された間隔がデータを転送するために引き渡されるかどうか）を決定する。データを転送する時間になっている場合、ステップ１００４に進み、請求データをプロキシサーバに転送する。データを転送する時間になっていない場合、ステップ１００６に進む。ステップ１００６では、ルーチンは、データベースの転送のためのビジネス規則がカウントベース（データ量に基づく）であるかどうかを決定する。ビジネス規則がカウントベースである場合、カウントがデータを転送するために示された規則よりも大きいかどうかである。カウントがデータを転送するために示された規則よりも大きい場合、ルーチンは、ステップ１００５に進み、カウントがデータを転送するために示された規則よりも大きくない場合、ステップ１００７に進む。ステップ１００５では、ルーチンは、データ量カウンタをリセットし、請求データをプロキシサーバに転送するためにステップ１００４に進む。ステップ１００７では、ルーチンは、アプリケーションに符号化された元のネットワーク呼び出しを用いてデータを転送する。
【００３４】
図１１は、請求データを収集し、そして転送するために修正されてきたデータをネットワークに転送するためのクライアントルーチンの例示的なフローチャートである。このルーチンは、いくつかのタイプの「ｒｅｃｅｉｖｅ＿ｄａｔａ」ネットワーク呼び出しを置換する例示的なプロキシネットワークコードを示す。ネットワークを介してデータを受信するプロキシネットワークコードの例示的な擬似コードインプリメンテーションは、添付物Ｃに含まれる。このルーチンは、受信されるべきデータの量をトラッキングかつ蓄積し、蓄積された量が請求データを転送するために頻度／間隔に対するルーチンに組み込まれたビジネス規則に対応する場合、請求データが転送される。特に、ステップ１１０１では、ルーチンは、元のネットワーク呼び出しを用いてデータを受信し、この返信を遮断する。次いで、ステップ１１０２では、返信は、元のネットワーク呼び出しが成功したかどうかを決定し、元のネットワーク呼び出しが成功した場合、ステップ１１０３に進み、元のネットワーク呼び出しが成功しない場合、エラーを戻す。ステップ１１０３では、ルーチンは、パケットにおいて受信されたデータの量を決定し、それを蓄積する（例えば、可変「ｄａｔａ＿ｉｎ」において）。ステップ１１０４では、ルーチンは、ローカルストレージにおけるタイムスタンプ、アプリケーション識別子、およびセキュリティキーと共に受信された現在のパケットにおけるデータの量を格納する。ステップ１１０５では、データを転送する時間になっているかどうか（例えば、時間／頻度の符号化された間隔がデータを転送するために適用するかどうか）を決定する。データを転送する時間になっている場合、ステップ１１０６に進み、請求データをプロキシサーバに転送する。データを転送する時間になっていない場合、ステップ１１０７に進む。ステップ１１０７では、ルーチンは、データベースの転送のためのビジネス規則がカウントベース（データ量に基づく）であるかどうかを決定する。ビジネス規則がカウントベースである場合、カウントがデータを転送するために示された規則よりも大きいかどうかである。カウントがデータを転送するために示された規則よりも大きい場合、ルーチンは、ステップ１１０８に進み、カウントがデータを転送するために示された規則よりも大きくない場合、戻る。ステップ１１０８では、ルーチンは、データ量カウンタをリセットし、請求データをプロキシサーバに転送するためにステップ１１０６に進み、次いで戻る。
【００３５】
図１２は、転送された送信に基づく請求データを処理するためのサーバルーチンの例示的なフローチャートである。このルーチンは、例えば、請求サーバ（図９における請求サーバ９０３等）またはプロキシサーバ（図９におけるプロキシサーバ９０２等）によって実行され得る。当業者は、本明細書中に含まれたステップが単に例示的であり、周囲の環境におけるＰＢＢＳの機能の配置および統合に応じて、異なるステップがこれらのステップと置換され得るかまたはこれらのステップと組み合わせられ得ることを認識する。ステップ１２０１では、ルーチンは、クライアントデバイスから転送された請求データを受信する。ステップ１２０２では、ルーチンは、請求データからセキュリティキー、アプリケーション識別子、およびユーザ識別子を抽出する。次いで、ステップ１２０３では、ルーチンは、セキュリティキーデータレポジトリテーブルにおけるそのセキュリティキーに関連付けられたアプリケーション識別子およびユーザ識別子と情報を比較する。ステップ１２０４では、セキュリティキー情報が整合する場合、ルーチンは、ステップ１２０６に進み、セキュリティキー情報が整合しない場合、請求データは、ステップ１２０５において放棄され、ルーチンは戻る。ステップ１２０６では、ルーチンは、請求データを格納する（または請求データを請求サーバに送信する）。デバイスが１つのサーバシステムとの通信に制限される実施形態では、次いでステップ１２０７では、ルーチンは、他のサーバに対して指定されたデータパケットを検出かつ送信し、次いで戻る。
【００３６】
図１３は、送信に基づく請求データに基づく請求課金を生成するためのステップの例示的なフローチャートである。このルーチンは、例えば、アカウンティングプログラム（図９におけるアカウンティングプログラム９０４等）によって実行され得る。本明細書中で示されたステップは、請求レコードを処理することに対して一般的に適用可能である。しかし、キャリアの詳細または請求レートを決定する他のコンテンツプロバイダに応じて、カスタマ（呼び出し）データレコードの適用性およびデータレコードのフォーマット、種々のさらなるまたは異なるステップが含まれ得る。ステップ１３０１では、ルーチンは、送信に基づく請求データを取り出す。ステップ１３０２では、ルーチンは、示されたアプリケーション識別子およびユーザ識別子に対する適用可能なビジネス規則を決定する。ステップ１３０３では、ルーチンは、任意の無効のポリシー／ビジネス規則（例えば、宣伝、ディスカウント等）が存在するかどうかを決定し、任意の無効のポリシー／ビジネス規則が存在する場合、ステップ１３０４に進み、無効規則を決定する。任意の無効のポリシー／ビジネス規則が存在しない場合、ステップ１３０５に進む。ステップ１３０５では、ルーチンは、任意の決定されたビジネス規則を適用し、呼び出しデータレコードを生成する。これらのレコードのフォーマットは、送信に基づく請求データが、例えば無線キャリアインフラストラクチャ内部に既に存在する請求システムに統合される任意の請求システムに著しく依存する。
【００３７】
上記から、本発明の特定の実施形態が例示の目的のために本明細書中で示されてきたが、種々の修正が本発明の精神および範囲から逸脱することなくなされ得ることが理解される。例えば、当業者は、本明細書中で説明された方法およびシステムがコンテンツ提供システムおよび送信に基づく請求システム任意のネットワーク、有線、無線、または複数のこのようなネットワークを介して適用可能であることを認識する。当業者は、本明細書中で説明された方法およびシステムが異なるプロトコル、通信媒体（光、無線、ケーブル等）、加入者デバイス（無線ハンドセット、電子オーガナイザ、携帯情報端末、ポータブル電子メールマシン、ゲーム機、ページャ、ＧＰＳレシーバ等のナビゲーションデバイス等）に適用可能であることも認識する。本発明の局面は、必要である場合、本発明のさらなる実施形態を提供するためのこれらの種々の特許、出願および公報の方法、システム、および概念を利用するために修正され得る。さらに、当業者は、どのようにして、特定の要求または条件に合致するように説明された方法およびシステムに対して変更および修正を行うかを理解する。
【００３８】
【表１】
2005509322.tif 000003
2005509322.tif 000004
2005509322.tif 000005
2005509322.tif 000006
2005509322.tif 000007
2005509322.tif 000008
2005509322.tif 000009
2005509322.tif 000010
2005509322.tif 000011
2005509322.tif 000012
2005509322.tif 000013
2005509322.tif 000014
2005509322.tif 000015
2005509322.tif 000016
付録（ＡＰＰＥＮＤＩＸ）  Ｄ
無線アプリケーションの保守および分配
本発明の実施形態は、無線アプリケーションを保守および提供するためのコンピュータおよびネットワークベースの方法、ならびにシステムを提供する。本明細書中で議論されるように、プロビジョニング（Ｐｒｏｖｉｓｉｏｎｉｎｇ）とは、特定の使用、例えば、特定の顧客による特定の種類の加入者デバイス上で使用するためのコンテンツをカスタマイズおよび分配することである。例示の実施形態においては、モバイルアプリケーションシステム（ＭＡＳ）が提供される。ＭＡＳは、アプリケーション、リソース、およびモバイル加入者デバイスへの他のコンテンツを提供するために、個別かつ共にセキュアな態様で動作する相互運用サーバコンポーネントの集合である。ＭＡＳは、例えば、セルラー電話およびハンドセットデバイス等の無線デバイスが、それらのデバイス上で用いるために、新しい、かつ更新されたアプリケーションをＭＡＳから動的にダウンロードすることを可能にする。動的ダウンロード能力は、無線アプリケーションのディベロッパー（コンテンツプロバイダ）の製品化までの時間の要求（ｔｉｍｅ−ｔｏ−ｍａｒｋｅｔ  ｒｅｑｕｉｒｅｍｅｎｔｓ）を著しく低減し、その結果、製品サポートおよびマーケティングの効率を高める。顧客は、その無線デバイス上でオペレーティングソフトウェアを迅速かつ便利に更新し、かつ人気のあるアプリケーション（ゲームを含む）をダウンロードすることができる。ＭＡＳを用いて、顧客は、その無線ハンドセットデバイスをネットワークから直接的に更新し、これにより、ソフトウェアを更新するために地域の顧客サービス担当者と話す、または、サービスセンターを訪れるという時間のかかる経験を回避することができる。ＭＡＳは、さらに、加入ビリング（ｓｕｂｓｃｒｉｐｔｉｏｎ  ｂｉｌｌｉｎｇ）を含む柔軟なビリングシナリオを支援し、これは、顧客が特定のサービスに加入して、所望するリソースおよびアプリケーションのみを受取ることを可能にする。
【００３９】
ＭＡＳの能力は、通常、任意のタイプの顧客無線デバイスに適用可能であるが、当業者は、加入者デバイス、顧客デバイス、電話、ハンドヘルド等の用語が、ＭＡＳと共に動作することができる任意のタイプの加入者デバイスを示すために交換可能に用いられることを認識する。さらに、本明細書中に記載される例示の実施形態は、１つ以上のネットワークを介して無線アプリケーションの維持および分配をインプリメントするためにアプリケーション、ツール、データ構造および他のサポートを提供する。当業者は、本発明の方法およびシステムの他の実施形態が、インターネット等の非無線ネットワークを介して、パーソナルコンピュータ、ネットワーク接続無線ハンドセット、インターネットとの接続性を有する電話、あるいは、空港またはショッピングセンター内のカスタマーキオスク、等の非無線加入者デバイスにソフトウェアおよび他のコンテンツを保守および分配することを含む、複数の他の目的のために用いられ得ることを認識する。さらに、この記載は、主に、アプリケーションおよびリソースの形態のコンテンツに関するが、当業者は、このコンテンツがテキスト、グラフィック、オーディオおよびビデオを含み得ることを認識する。さらに、以下の記載において、本発明の方法およびシステムの技術の徹底的な理解を提供するために、データフォーマット、ユーザインテーフェーススクリーンディスプレイ、コードの流れ、メニューオプション等の多数の特定の詳細が示される。しかしながら、当業者は、本発明が、本明細書中に記載される特定の詳細のいくつかを用いないか、あるいは、コードの流れの順序付けまたはユーザインターフェーススクリーンディスプレイに示される特定の特徴に関する変更等、他の特定の詳細を用いても実行され得ることを認識する。
【００４０】
図１は、無線サービスの加入者がリクエストし、かつモバイルアプリケーションシステムからソフトウェアアプリケーションをダウンロードする態様を示す例示的ブロック図である。ＭＡＳが動作する無線環境は、加入者デバイス１０１および１０１ｂ、トランシーバ１０３を有する無線ネットワーク１０２、無線キャリアサービス１０４、ＭＡＳ１０５および種々のコンテンツプロバイダ１０６を含む。コンテンツプロバイダ１０６は、キャリアサービス１０４の認可を通じて、または認可によってＭＡＳ１０５にアプリケーションを提供する。アプリケーションは、その後、リクエストされると、ＭＡＳ１０５によって、検証され、公開され、かつ加入者デバイス１０１に供給される。このタイプのプロビジョニングは、本明細書中において「ウォールドガーデン」プロビジョニングと呼ばれる。なぜなら、この態様で供給および公開されるアプリケーションは、キャリアおよび／またはＭＡＳインフラストラクチャに既知だからである。コンテンツプロバイダ１０６は、さらに、ＭＡＳ１０５によって動的に供給され得る、加入者デバイスによってブラウズされ得るアプリケーションをホストとして処理し得る。このタイプのプロビジョニングは、本明細書中において「オープン」プロビジョニングと呼ばれる。なぜなら、ＭＡＳまたはキャリアインフラストラクチャの範囲内で「既知の」アプリケーションに限定されないからである。これらは、異なったタイプのプロビジョニングが複数の類似の機能を共有するので、議論の都合上、区別されるにすぎない。ＭＡＳ１０５は、さらに、キャリア、コンテンツプロバイダ、カスタマケア担当者および加入者に、特定の加入者または加入者の群に利用可能なアプリケーション、サービス、およびビリングシナリオをカスタマイズするための複数のツールを提供する。
【００４１】
図１において、加入者デバイス１０１は、現在、存在するか否かに関わらず、無線ハンドセット、電話、電子オーガナイザ、パーソナルデジタルアシスタント、ポータブル電子メール機器、ゲーム機器、ページ、ナビゲーションデバイス等の、無線ネットワーク１０２を介して通信ができる電子デバイスを含む。１つ以上の加入者デバイス１０１（顧客デバイスとも呼ばれる）は、無線ネットワーク１０２を横断して、そのサービスを用いるように加入者が手続きをした無線キャリアサービス１０４に通信する。無線ネットワーク１０２は、加入者デバイス１０１にサービスを中継する（および加入者のリクエストを処理する）ために用いられるトランシーバ１０３を有する。当業者は、無線サービスの加入者が、代替的ネットワーク（インターネット等）を用いることによって、および、アプリケーションをダウンロードするためにより使い易いインターフェースを提供し得る、パーソナルコンピュータ１０１ｂ等の比較的大きいフォームファクタを有するデバイスを用いることによって、無線ネットワークを横断して無線アプリケーションをリクエストおよびダウンロードすることに含まれる任意またはすべての工程を補完し得ることを認識する。トランシーバ１０３は、通常、無線通信をケーブルベースの通信に変換し、かつケーブルベースの通信を無線通信に変換するが、当業者は、種々の媒体およびプロトコルが用いられ得ることを認識する。トランシーバ１０３は、通常、キャリア専用通信プロトコルを用いてケーブルベースの媒体を横断してキャリアサービス１０４と通信する。キャリア専用の通信は、ハイパーテキストトランスポートプロトコル（ＨＴＴＰ）およびワイヤレスアプリケーションプロトコル（ＷＡＰ）等のポイントツーポイント通信のために適切な任意のプロトコルを用い得る。キャリアサービス１０４は、アカウンティング、ＰＯＴＳ（「平凡な旧式の電話サービス（ｐｌａｉｎ  ｏｌｄ  ｔｅｌｅｐｈｏｎｅ  ｓｅｒｖｉｃｅ」）および他の電話サービス（自動転送、発信者番号通知サービス、ボイスメール等）およびダウンロード可能なアプリケーションを含む電話局に典型的であるサービスを提供する。モバイルアプリケーションシステム１０５は、例えば、広帯域通信チャネル１０８、またはインターネット１０７等の公共的にアクセス可能なネットワークを介して、キャリアサービス１０４と通信して、提供されたアプリケーションを加入者デバイス１０１に供給する。当業者は、モバイルアプリケーションシステム１０５が、キャリアサービス１０４と完全または部分的に統合され得ることを認識する。ウォールドガーデンプロビジョニングを用いて、通常、コンテンツプロバイダ１０６により生成されるダウンロード可能なアプリケーションが、モバイルアプリケーションシステム１０５またはキャリアサービス１０４に直接的に、またはインターネット１０７等のネットワークを横断して供給される。これらのダウンロード可能なアプリケーションは、その後、モバイルアプリケーションシステム１０５によって適切に検証およびカスタマイズされて、加入者デバイス１０１に供給される。オープンプロビジョニングを支援する実施形態において、キャリアの加入者は、位置（ネットワークアドレスまたはＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｃｅ  Ｌｏｃａｔｏｒ）等）を指定することによって、ウェブサイトからアプリケーションをダウンロードし得る。ＭＡＳは、加入者からのダウンロードリクエストをインターセプティングし、その後、位置指定し、検証し、かつ顧客にアプリケーションを供給する。
【００４２】
加入者デバイス１０１は、アプリケーションをリクエストおよびダウンロードするために、顧客側アプリケーション管理ユーティリティ（例えば、ハンドセットアドミニストレーションコンソールまたはブラウザ）に依存する。図２は、モバイルアプリケーションシステムと共に動作するハンドセットアドミニストレーションコンソールの例示的ブロック図である。ハンドセットアドミニストレーションコンソールは、加入者の無線デバイス上のアプリケーションの通知、インストール、アンインストールを処理する。加入者デバイス２０１は、デバイスに利用可能な機能のメニューを加入者に提供する。加入者は、例えば、デバイスに既にインストールされたアプリケーションを管理し、かつダウンロードされ得る新しいアプリケーションを提供するメニュールーチンから選択され得る。例えば、ルーチンは、インストールされたアプリケーションのバージョン情報を加入者が取得して、これらのアプリケーションの更新が利用可能になった場合、これらをダウンロードし、かつダウンロードされるべき新しいアプリケーションのためにブラウズすることを可能にし得る。メニュー２０２は、加入者デバイス２０１に場合によってはダウンロードされ得る新しいアプリケーション２０３のリストを示す例示的メニューである。例示的スクリーンディスプレイ２０４は、ダウンロードするために加入者がアプリケーションを選択した後で提供される例示的ユーザインターフェースを示す。スクリーンディスプレイ２０４は、ダウンロードオペレーションを示すアイコン２０５、ダウンロードされるアプリケーションのタイトル２０６、およびダウンロードの進行中のプロセスを表示するステータスバー２０７を提供する。スクリーン２０４は、さらに、ダウンロードプロセスがキャンセルされることを可能にするストップボタン２０８を提供する。
【００４３】
図３は、無線加入者デバイスにアプリケーションを供給するために例示的モバイルアプリケーションシステムによって実行される一般的工程の例示的概要のフローチャートである。これらの工程は、プロビジョニングシナリオ（ウォールドガーデンを用いて）またはオープンプロビジョニングのどちらかに適用可能である。これらの同じ工程は、さらに、図１におけるインターネット１０７を通じて接続されるもの等の無線デバイスにアプリケーションを供給するために用いられ得る。工程３０１〜３１０は、ＭＡＳが入来するリクエストを処理して加入者デバイスからアプリケーションをダウンロードし、リクエストされたアプリケーションを供給し、かつリクエストされたアプリケーションを加入者デバイスに送信する態様を示す。プロビジョニングは、コードを取り出す工程、検査する工程、最適化する工程、計測する工程、およびパッケージングする工程の１つ以上を含み、かつ、アプリケーションをターゲットデバイスにダウンロードするために準備するように、必要に応じて、さらなる工程を含み得る。例えば、さらなるセキュリティおよびビリング方法がシステムに追加され、プロビジョニングは、除法を暗号化する工程およびレポートされる工程を包含し得る。別の場合、工程３０１〜３１０は、アプリケーションがネットワーク上のロケーションをブラウズすることによって間接的にリクエストされるのとは対照的に、ＭＡＳから直接的にリクエストされることを想定する。（オープン供給の場合、ＭＡＳは、リクエストをインターセプティングし、初めてこれを受取るかのようにアプリケーションを供給およびダウンロードすることを試みる。）
具体的に、工程３０１において、アプリケーションは、通常、キャリアから、またはコンテンツプロバイダから直接的にダウンロードするために利用可能にされる。アプリケーションは、多様な加入者デバイス上で実行することができるＪａｖｅなどのコンピュータ言語を用いて書き込まれ得る。アプリケーションは、キャリアのアプリケーションデータのリポジトリ（ＭＡＳにおいてか、またはキャリアの構内にて配置され得る）に局所的に格納されるか、または、適宜、信用される第３者サーバに格納される（オープンプロビジョニングの場合、第３者サーバは、必ずしも信用されない）。工程３０２において、加入者は、アプリケーションをダウンロードし、利用可能なアプリケーションのリストを取り出し、特定の管理クエリまたは他のコマンドを実行するリクエストを送信する。プロトコル変換は、入来するリクエスト（および出ていくメッセージ）に対して実行され、多様な無線キャリアを横断して加入者デバイスとの通信をイネーブルする。ダウンロードされたアプリケーションは、例えば、加入者デバイス上で動作する新しい、および人気のあるアプリケーション、あるいは、アップグレードまたはより最近のソフトウェアのバージョンであり得る。リクエストは、例えば、リクエストを方向付けることを知らせるＨＴＴＰを用いるＵｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒｓ（ＵＲＬ）を用いてなされる。ＭＡＳは、拡張可能なコマンド処理エンジンを支援し、かつ種々のハンドラ、モジュール、ＭＡＳのコンポーネントである他の構造の直接的な呼出しを、ＨＴＴＰリクエストまたはアプリケーションプログラミングインターフェース（「ＡＰＩ］）のどちらかを通じて支援する。アプリケーションプロビジョニングリクエストの場合、特定のファイルをダウンロードするためのリクエストが、ダウンロードするファイル（アプリケーションまたはサービス）を識別するＵＲＬを割り当てることによって行われる。管理クエリの場合、リクエストは、例えば、管理サーブレットまたはリクエストを処理するＭＡＳにおける他のコードに対してなされる。工程３０３において、ＭＡＳは、ダウンロードのためか、または特定の他のコマンドのためのリクエストかを決定し、ダウンロードのリクエストである場合、工程３０５にて続行し、そうでない場合、工程３０４にてコマンドを処理する。工程３０５において、ＭＡＳが割り当てられたＵＲＬが公開アプリケーションを指定するか否か（これにより、ウォールドガーデン供給が実行され得ることを示す）を決定し、指定する場合、工程３０６にて続行し、そうでない場合、工程３０８にて続行する。工程３０６において、加入者のリクエストは、認証、デバイス能力、および、適切である場合、プリペイドビリングの認可について検証される。認可レベルは、通常、顧客が加入したサービスのレベルに依存する。例えば、１実施形態において、ＭＡＳは、プリペイドビリングを支援し、これは、加入者がアプリケーションを使用するために支払いを予め済ませることを可能にする。この場合、ＭＡＳは、アプリケーションがダウンロードされる前にプリペイドビリングアカウントがリクエストを扱い得ることを検証する。販売促進のためのオファーが��供されているか否か、加入者がサービスにアクセスした回数、特別提供価格が存在するか否か、サービスがアクセスされた日時または週、ダウンロードされるべきバイト数および他のこのようなファクタ等の他のファクタが適用され得る。デバイス能力は、さらに、リクエストされたアプリケーションが加入者デバイス上で十分に動作し得るか否かを決定するために点検される。これは、例えば、リクエストするデバイスを既知のデバイスプロファイルおよびリクエストされたアプリケーションのアプリケーションプロファイルと比較することによって実行され得る。工程３０７において、ＭＡＳは、加入者のリクエストが首尾よく検証されたか否かを決定し、検証された場合、工程３０８にて続行し、そうでない場合、これは、リクエストを拒絶し、かつ別のリクエストを待つために工程３０２に戻す。
【００４４】
工程３０８において、ＭＡＳは、加入者リクエストに対応し、かつ加入者デバイスに適切である予め供給されたアプリケーションがすでに存在するか否かを決定する。予め供給されたアプリケーションは、加入者デバイスの認可のレベルおよび能力に従って予めカスタマイズされたアプリケーションである。予め供給されたアプリケーションは、利用可能である場合、対応するアプリケーションリクエストに対してシステムの待ち時間を最小限にし、かつシステム応答時間を向上（ｅｎｈａｎｃｅ）させる。アプリケーションは、加入者の加入の典型的レベルおよび典型的加入者デバイス（例えば、使用予定によって決定される）により予め供給され得、かつ後からのアクセスのために格納されて、予め供給されたアプリケーションに対応するアプリケーションの加入者デバイスリクエストに応答する。アプリケーションが予め供給されなかった場合、ＭＡＳは、アプリケーションを動的に供給し、これは、リクエストを処理するために必要とされる時間を増加させるが、配布するためのカスタマイズおよび認可されたアプリケーションを生成する。
【００４５】
工程３０８において、加入者デバイスのために適切な予め供給されたアプリケーションが見出された場合、プロビジョニングシナリオは、工程３１０にて続行し、そうでない場合、これは、工程３０９にて続行する。３０９において、アプリケーションは、特定の加入者デバイスのために、およびアクセス認可に従って供給される。工程３１０において、ＭＡＳは、供給されたアプリケーションをダウンロード用に加入者デバイスに送信する。
【００４６】
上述のように、ＭＡＳによって支援されるリクエストの１つは、加入者のデバイスにダウンロードされ得る利用可能なアプリケーションのリストを取り出すことである。このプロセスは、アプリケーションディスカバリと呼ばれる。図４は、無線加入者デバイスのためにアプリケーションディスカバリを実行する、例示的モバイルアプリケーションシステムによって実行される工程の概要の例示的フローチャートである。例示的実施形態において、２つのタイプのアプリケーションディスカバリが支援される。第１のタイプは、システムによって駆動され、かつシステムから導き出されるリストを生成する。第２のタイプは、リクエスタ（ｒｉｑｕｅｓｔｅｒ）によって駆動され、かつ「適切な」アプリケーションのリストを生成するためにＭＡＳによって整合される検索用語を指定する。工程４０１において、ＭＡＳは、ユーザが任意の検索用語を入力したか否かを決定し、入力した場合、工程４０２にて続行し、そうでない場合、工程４０３にて続行する。工程４０２において、ＭＡＳは、公開アプリケーションのデータレポジトリをリクエストにおいて指定された基準を満たすものについて検索し、そして工程４０４にて続行する。あるいは、工程４０３において、ＭＡＳは、初期リストを決定する。１実施形態において、このリストは、加入者の個人専用リスト（利用可能である場合）から形成され、そうでない場合、ＭＡＳは、デフォルトリストを提供する。工程４０４において、ＭＡＳは、この初期リストを加入者およびデバイス能力に基づいてフィルタリングする。例えば、ＭＡＳは、加入者がアプリケーションを用いることを認可されたか否か、および、アプリケーションプロファイルに反映されるようなアプリケーションのニーズがデバイスによって満たされるか否かを決定するために、例えば、加入者プロファイル、デバイスプロファイルおよびアプリケーションプロファイル等の種々のプロファイルを解析し得る。工程４０５において、ＭＡＳは、任意のシステム定義アプリケーションをリスト（「スタートデック（ｓｔａｒｔｄｅｃｋ）」と呼ばれる）に追加する。このようなアプリケーションは、キャリアのカスタマイズ可能な規則に従って割り当てられ得、例えば、これらのアプリケーションをリストのトップに配置することによって、より多くの収益を生成するアプリケーションに「プレミアム」可視時間が与えられ得る。工程４０５において、ＭＡＳは、リクエストするデバイスの可視能力によりリストをフォーマット化（例えば、支援されるマークアップ言語）して処理を終了する。
【００４７】
図５は、モバイルアプリケーションシステムの例示的な実施形態のコンポーネントの概略的なブロック図である。この実施形態において、モバイルアプリケーションシステム５００は、プロトコルマネージャ５０３、プロビジョニングマネージャ５０４、キャッシュ５０５、デプロイメントマネージャ５０６、請求マネージャ５０７、ロギングマネージャ５０８、アドミニストレータ５０９および心拍モニタ３１０を含む。これらのコンポーネントは、コンテンツプロバイダおよび通信事業者サービスからアプリケーションを受信するように相互動作し、図１に示されるように、加入者デバイスに送達するためにそれらをプロビジョニングし、ＭＡＳコマンドを処理する。ＭＡＳのコンポーネントまたは異なるコンポーネントの機能性に関する多くの異なる配置および分割が可能であることを、当業者は認識している。例えば、プロトコルマネージャ５０４および請求マネージャ５０７に配置された機能は、１つのコンポーネントに結合される。他の配置は、また、可能であり、検討される。
【００４８】
ＭＡＳの様々なコンポーネントは、通信事業者によって提供されたサービスを管理する通信事業者（またはシステム）管理者あるいは顧客ケアの代表者と、アプリケーションおよびサービスを発展させて、通信事業者に分配するコンテンツプロバイダと、サービス、アプリケーションおよび他のコンテンツを消費する加入者とに多数の性能を提供するように相互作用する。管理者５０９は、様々なユーザインタフェースをこれらのタイプの各々に提供して、ＭＡＳ、アプリケーション、請求および他のサービスを構成し、ＭＡＳによって加入者の体験をカスタマイズする。プロビジョニング局面を示すと、図３を参照して記述されるように、加入者がＭＡＳを呼び出して、アプリケーションを加入者のデバイスにダウンロードさせる場合にＭＡＳコンポーネントに起こる処理ステップの観点からＭＡＳの機能が説明される。コンポーネントの他のデータフローおよび使用法が適切であり、かつ、処理されたコマンド、および／または、コンポーネントまたはコンポーネント内のコードが呼び出される方法に依存していることは、当業者に認識されている。
【００４９】
より詳細には、図５に示される例示的な実施形態において、Ｊ２ＭＥまたはＷＡＰハンドセット等の加入者デバイスからの通信は、入来リクエスト５０１および出行データ５０２としてそれぞれモバイルアプリケーションシステム５００に提示され、モバイルアプリケーションシステム５００から受信される。通常、ＭＡＳは、（ウェブサイトベースのインタフェースとは対照的に）コマンドインタフェースを介して加入者によって呼び出され、２つの異なるタイプの入力リクエスト（アプリケーションの探索および要求されたアプリケーションのダウンローディング）を処理する。ＭＡＳは、また、他のコマンドを処理するように呼び出され得る。また、ＭＡＳのコンポーネントは、例えば、使用の情報を得るための管理のリクエストを実行するために、直接呼び出され得る。入力リクエスト５０１がアプリケーション探索のリクエストである場合、加入者、アプリケーションプロフィールおよびデバイスプロフィールに基づいて利用可能および適切なアプリケーションのリストをコンパイルし、戻す。アプリケーション探索を達成するためにＭＡＳによって通常に実行されたステップは、図４を参照して説明される。あるいは、入力リクエスト５０１が指定されたアプリケーションをダウンロードするリクエストである場合、ＭＡＳは、アプリケーションを検索し、アプリケーションが適切であり、ダウンロードがデバイスおよびユーザに許可されていることを検証し、要求されたアプリケーションをプロビジョニングし、パッケージ化し、要求している加入者デバイスにパッケージ化されたアプリケーションを送る。プロビジョニングしているアプリケーションを達成するためにＭＡＳによって通常実行されたステップは、図３を参照して記述される。
【００５０】
プロトコルマネージャ５０３は、加入者デバイスとプロビジョニングマネージャ５０４との間のメッセージのプロトコル変換を実行する。プロトコル変換は、ＭＡＳ５００が任意の加入者デバイス（ワイヤレスまたは有線）と通信し得ることを保証し、（図１におけるワイヤレスネットワーク１０２等の）ネットワークにおいて用いられる通信プロトコルに独立であり、処理されるべき様々なプロトコル内で組み込まれ得る入来リクエストを許可する。例としてのプロトコルマネージャ５０３は、ＷＡＰおよびＨＴＴＰプロトコルのための組み込みサポートを有し、さらなるフォーマットおよびプロトコルのためのサポートを提供する周知の技術を用いて拡張され得る。ＷＡＰゲートウェイ（図示せず）等の１つ以上の別々のゲートウェイは、プロトコルマネージャ５０３、入来リクエスト５０１／出行データ５０２間に常駐し得る。これらのゲートウェイは、特定のプロトコルとしてターゲットされたメッセージを処理するように用いられ得る。プロトコルマネージャ５０３は、また、プラグインセキュリティ層を随意的に含み得、データ暗号化、復号化、および、エンド−トゥ−エンドセキュリティサポートに対する証明の管理を取り扱い得る。プロトコルマネージャ５０３が、所望なように安全な通信のための他のタイプのサポートを含むように拡張され得ることは、当業者に認識されている。
【００５１】
入来リクエストが適切に変換されると、プロビジョニングマネージャ５０４は、リクエストを処理し、必要なら他のコンポーネントのアシスタンスに関わる。例えば、リクエストが管理のクエリである場合、プロビジョニングマネージャ５０４は、ＭＡＳに管理サーブレットにリクエストを転送し得る。代わりに、加入者デバイスにダウンロードされ得るアプリケーションのリストのためのリクエストである場合、プロビジョニングマネージャ５０４は、通信事業者から利用可能な各アプリケーションの性能およびリクエストを加入者のデバイスおよび加入者に対応する適切なデバイスおよび加入者プロフィールデータと比較することによってこのようなリストを生成するために、リポジトリ３１１およびプロフィールマネジメントコードに問い合わせ得る。一方、加入者からのリクエストが指定されたアプリケーションをダウンロードする場合、プロビジョニングマネージャ５０４およびデプロイメントマネージャ５０６は、加入者に分配するために要求されたアプリケーションを得て、プロビジョニングするように相互作用する。一実施形態において、プロビジョニングマネージャ５０４は、ユーザ、デバイス、請求および加入者リクエストによって参照されたアプリケーション情報を検証し、デプロイメントマネージャ５０６は、アプリケーションを回収し、プロビジョニングする。デプロイメントマネージャ５０６によって実行されたアプリケーションプロビジョニングプロセスは、以下の処理ステップのうちの１つ以上を含む。検索するステップ、点検するステップ、最適化するステップ、コードを編集するステップ、パッケージ化するステップであり、図７を参照して以下に記載される。
【００５２】
プロビジョニングマネージャ５０４は、プロトコルマネージャ５０３からの加入者リクエストを受信し、ダウンロードリクエスト、または、加入者リクエストに含まれる他のコマンドを取り扱う。ダウンロードリクエストは、各ダウンロードリクエストによって提出された情報、および、ＭＡＳによってアクセス可能な他の情報（例えば、データリポジトリ５１１に格納されたプロフィール）に基づいて取り扱われる。アプリケーションをダウンロードする要求を処理する場合、プロビジョニングマネージャ５０４が加入者、加入者デバイス、および、要求されたアプリケーション（単数または複数）および請求に関連する情報のために前に生成された、または、利用可能なプロフィールを試験し、特定の加入者を用いる、加入者の請求方法に従う加入者のために要求されたアプリケーションの適切さを決定する。プロフィールを点検した後、プロビジョニングマネージャ５０４は、例えば、要求されたアプリケーションが首尾良く加入者デバイス上で動作し得るかどうかを評価しようとすることによって要求を賛成するか否定するかのいずれかである。例えば、アプリケーションの必要条件が特定の加入者デバイスの性能によって適合し得るかどうかを決定することによって、この評価が実行される。プロビジョニングマネージャ５０４は、また、請求方法が要求されたアプリケーションにセットアップされているかどうか、加入者は適合可能であり、ダウンロードを実行するために十分であるかどうかを決定する。例えば、加入者がプリペイド請求プログラムの一部であることをこの要求が示す場合に、プロビジョニングマネージャ５０４は、加入者のプリペイド請求額の資金がダウンロードされたアプリケーションを可能にするために十分であることを検証する。
【００５３】
１度認証されると、プロビジョニングマネージャ５０４は、キャッシュ５０５かデプロイメントマネージャ５０６かのいずれかから要求されたアプリケーションを獲得し得る。通常、キャッシュ５０５は、予めプロビジョニングされたフォーマットに頻繁にダウンロードされたアプリケーションを格納するように用いられ、一方、デプロイメントマネージャ５０６は、それらが要求される間に、動的にアプリケーションをプロビジョニングするように用いられる。通信事業者によって制御されるアプリケーションは、通常、予めプロビジョニングされて、キャッシュ５０５に格納され、例えば、インターネットサイトを介して利用可能なアプリケーションは、通常、ダウンロードが要求される場合にのみプロビジョニングされる。
【００５４】
キャッシュ５０５は、加入者デバイスへの要求されたアプリケーションのより早い送達を提供するように用いられる。キャッシュ５０５は、例えば、特定の加入者デバイスのために、または、認可されたアクセスに応じて、特定のプロフィールのための時間に先行して処理されているプロビジョニングされたアプリケーションをキャッシュするように用いられる。既に点検され、最適化され、編集されているキャッシュ５０５に格納されたアプリケーションは、配置のプロビジョニングが整うとタグ付けされる。ＭＡＳの他のコンポーネント間で類似のキャッシング機能をインプリメントすることによってシステムパフォーマンスが強化され得ることも当業者は、認識している。例えば、インターネットアプリケーションを保持するキャッシュは、デプロイメントマネージャとインターネットとの間に常駐し、インターネットアプリケーションと通信するために必要とされるアクセス時間を低減し得る。また、例えば、保管されていないＪＡＲファイルを保持するキャッシュは、計装処理を早めるようにインプリメントされ得る。他の構成も可能である。特定の加入者および特定のデバイスに対する要求された認証アプリケーションがキャッシュ５０５に発見されない場合、そのアプリケーションは、デプロイメントマネージャ５０６を介して検索され得る。デプロイメントマネージャ５０６は、加入者デバイスへの送達用のアプリケーションを用意する。デプロイメントマネージャ５０６は、アプリケーション（例えば、不当なアプリケーション検出、制限されたＡＰＩの利用、試行分配（１セットの回数または１セットの時間のみで許可される使用）および他の請求方法のためのサポート、要求している加入者デバイスのためのアプリケーションサイズ最適化等のアプリケーション）を用意すること、維持することおよびプロビジョニングするという多くの面、ならびに他の面を管理する。デプロイメントマネージャ５０６は、アプリケーションを獲得し、アプリケーションのインスタンスが要求される場合に、アプリケーションの意図された（要求された）使用のために各アプリケーションインスタンスをプロビジョニングする。デプロイメントマネージャ５０６は、また、前もってそれらのプロフィールのためにアプリケーションをプロビジョニングすることによって、キャッシュ５０５、または他のデータリポジトリに素早いアクセスに対する結果を格納することによって、特定のデバイスおよび／または加入者プロフィールのためのアプリケーションを予め配置（「予めプロビジョニング」）し得る。図７を参照して以下で説明されるように、デプロイメントマネージャ５０６は、通信事業者のアプリケーションデータリポジトリから、（信用されている、または、信用されていない）遠隔アプリケーションホストから、または、任意の他のアプリケーションソースからアプリケーションを配置し得る。デプロイメントマネージャ５０６が要求されたアプリケーションを適切にプロビジョニングした後、デプロイメントマネージャ５０６は、出て行く応答に対する任意の後処理のために、プロビジョニングマネージャに要求されたアプリケーションを戻す。
【００５５】
プロビジョニングされたアプリケーションがユーザに伝達されているとき、取引に関する詳細は、通常、ロギングマネージャ５０８に記録される。ロギングマネージャ５０８は、請求マネージャ５０７にアクセス可能である様々な請求方法を可能にする。記録されたデータは、入来リクエスト５０１に関する情報、および、加入者ＩＤ、ダウンロードのサイズ、ダウンロードの時間および日付、ダウンロードされた特定のアプリケーション等の配置されたアプリケーションを含む。ダウンロードに関して記録された情報が幅広いので、通信事業者は、サービスおよび加入者の異なるカテゴリーに応じて、アプリケーションのプロビジョニングのための請求の方法に、非常に柔軟性を有している。通信事業者は、例えば、用いられた空路量、ダウンロード時間、ダウンロードされたデータの量、クライアントの人口統計によって、または、ダウンロードされた特定のアプリケーションに基づいて請求し得る。
【００５６】
請求マネージャ５０７は、請求方法を実施する際に支援する義務がある。例示的な実施形態において、いくつかの初期請求オプションが提供される。（１）アプリケーションをダウンロードすることに基づいてダウンロード料、（２）ネットワークパケットの送信に基づくパケットベースの請求料、（３）日毎、周毎または月毎のような定期的な料金に基づく加入料、（４）お試し使用の任意の計算法に基づくお試し使用料、例えば、アプリケーションが実行され得る回数、（５）プリペイド請求。これらの請求オプションは、通信事業者レベルおよびアプリケーションレベルの両方でカスタマイズ可能であり、一以上が特定のアプリケーションのために提供されるときに、所望の請求オプションは、加入者によって選択され得る。例示的なモバイルアプリケーションシステム５００において、アプリケーションプログラミングインタフェース（ＡＰＩ）は、通信事業者の存在する請求サブシステムによって容易に統合するために提供される。一実施形態において、加入者は、後にダウンロードされるべきアプリケーションのために予めお金を払う。加入者が予めお金を払われたアプリケーションをダウンロードするときに、請求マネージャ５０７は、請求記録を通信事業者のプリペイド請求システムへの請求記録を転送して、これにより、加入者の金額は、変化され得、更新され得る。代替的な実施形態において、プリペイド加入者口座が格納され、請求マネージャ５０７によって維持される。他の構成も可能であり、請求方法の他のタイプのために支持する。請求マネージャ５０７が請求に関連した情報を生成した後、アプリケーションは、プロトコルマネージャ５０３に送信され、出向データ５０２として顧客に必要とされ、かつ、伝送される場合、異なるプロトコルのために再フォーマットされる。
【００５７】
管理者５０９は、例としてのＭＡＳ５００の他のコンポーネントと相互作用し、ＭＡＳ５００の様々な局面をカスタマイズする。たとえば、管理者５０９によって、通信事業者は、カスタマイズ可能なプロビジョニングに関連する規約をインプリメント可能にし、モバイルアプリケーションシステム自体の再プログラミングコンポーネントを介してそれら自体のインフラストラクチャーでＭＡＳを統合する。これにより、加入者、通信事業者、システム管理者およびコンテンツプロバイダは、プロフィール管理、レポートの生成、請求方法管理およびサーバ管理を実行する際に、柔軟性が強化され得ます。
【００５８】
心拍モニタ５１０は、モニタし、他のＭＡＳ５００コンポーネントのレポートを提供し、関連するシステムイベントが起こるときに、適切な通告を提供する。例えば、コンポーネントが動作しなくなる等のシステムの問題を検出する。例えば、心拍モニタ５１０は、プロトコルマネージャ５０３をモニタ可能であり、プロトコルマネージャ５０３が所定の時限内に入来リクエストに応答するかどうかを決定する。プロトコルマネージャ５０３が適切に応答していないことを心拍モニタが決定する場合、多数の心拍モニタ５１０は、第１のモニタが適切に機能しているかどうかをモニタし得、必要なら引き継ぎ得るように提供される。心拍モニタ５１０は、（状態リクエストでデバイスにポーリングすることによって）能動モニタリングと（適切な時間に特定の種類の通信が起こることを検証することによる）受動リスニングとの両方が可能である。心拍モニタ５１０は、また、産業標準プロトコル、例えば、シンプルネットワークマネジメントプロトコル（ＳＮＭＰ）に対してインタフェースを提供し、他の外部コードがＭＡＳをモニタすることを可能にする。
【００５９】
図５を参照して説明されるように、ＭＡＳプロビジョニングマネージャは、入来ダウンロードリクエストおよび他のコマンドを処理し、ダウンローディングためのアプリケーションの動的プロビジョニングを駆動する。図６は、モバイルアプリケーションシステムの例示的なプロビジョニングマネージャのコンポーネントの例示的なブロック図である。一実施形態において、プロビジョニングマネージャ６００は、ＭＡＳコマンド、制御プロセッサ６２０（「ＭＣＣＰ」）、検証部６０１、ＸＳＬＴプロセッサ６３０、リクエストプロセッサおよびポストプロセッサ６４０、ならびに、ＭＡＳデータクエリエンジン６５０を含む。ＭＣＣＰは、リクエストを復号化する責任を負い、リクエストを正しいＭＡＳサブコンポーネントに導く。例えば、発光されたアプリケーションをダウンロードする、または、アプリケーション探索を実行する等である。加入者検証器６０２、デバイス検証器６０３、プリペイド請求検証器６０４およびアプリケーション検証器６０５を含む検証器６０１は、検証を実行して、加入者およびデバイスのためのアプリケーションを適切に決定する。ＸＳＬＴプロセッサは、例えば、産業標準拡張スタイルシートプロセッサとしてインプリメントされ得、リクエストデバイスのレンダリング能力に応じてデータをフォーマットするように用いられる。一実施形態において、ＸＳＬＴプロセッサは、ＳＭＬ用のスタイルシートをサポートするが、ＨＴＭＬ、Ｊａｖａ（登録商標）、ＷＭＬ、ＸＨＴＭＬ  Ｂａｓｉｃおよびテキスト、または、任意の他のメークアップまたはレンダリング言語用のさらなるスタイルシートを提供するように容易に拡張され得る。リクエストプロセッサおよびポストプロセッサ６４０は、リクエスト「パケット」のパラメータを操作して、他のコンポーネント内で通信し、このレベルで「フック」され得る任意のタイプのプロセッシングを実行するように拡張され得る。ＭＡＳデータクエリエンジン６５０は、様々なデータリポジトリとの通信を管理する。ＭＡＳデータクエリエンジン６５０は、プロビジョニング用リーダ６５１、プロフィール用リーダ６５２および構成データ用のリーダ６５３を含む。容易に見ることができるようにこれらのコンポーネントを接続することを示す矢印は存在しないが、当業者は、コンポーネントが多くの方法で相互接続され、かつ、相互動作されることを認識している。
【００６０】
最初に、プロビジョニングマネージャ６００は、プロトコルマネージャ（例えば、図５のプロトコルマネージャ５０４）等から入来リクエストを受信する。マネージャ６００は、入来リクエストを解析し、後に行われるプロビジョニング、請求またはロギングステップを強化し、変更し、または、制限することを動的に考慮するリクエストを修正することによってリクエストをオプションで再処理する。このような動的修正によって、通信事業者が通信事業者自体のインフラストラクチャを動的にシステムにフックできる。例えば、プロビジョニングマネージャ６００は、入来ダウンロードリクエストに添って通過されたリクエストヘッダを観察し得、ヘッダを修正、追加または削除して、システムの挙動を修正する。ＭＡＳの他のコンポーネントがヘッダと共に含まれる情報を用いているので、ヘッダ情報を更新するまたは修正することは、特定のリクエストの機能を拡張または制限する、あるいは、ＭＡＳの挙動を修正するという手段を提供する。
【００６１】
（ウェブサイトまたはＡＰＩを介して直接呼び出されることに対して）ＭＡＳコマンドインタフェースから受信されるときに、リクエストがＭＣＣＰによって処理される。リクエストがアプリケーション検索のためであるか、コンテンツをダウンロードすることである場合、様々な検証器６０１は、アプリケーションの適合性を決定するように用いられる。リクエストがいくつかの他のコマンド用である場合、結果的にリクエストは処理される。
【００６２】
アプリケーション検証器６０４は、要求されたアプリケーションが配置用の通信事業者によって禁止されているかどうかを決定する。詳細には、アプリケーション検証器６０４は、アプリケーションのリストを検査する。ここで、通信事業者が要求されたアプリケーションを禁止するかどうかを決定するように、このアプリケーションのリストがダウンロードされることが可能であることを通信事業者は望まない。例えば、不当な挙動を提供するようにアプリケーションが突然発見され、通信事業者が通信事業者の分配を直ぐに中断することを望む場合に、この状況が起こる。
【００６３】
加入者検証器６０１は、リクエストを生成したある者から加入者のアイデンティティを決定し、サービスのレベルを決定する。このサービスのレベルに対して、加入者は、加入者が特定のアプリケーションを用いることを認証されるかどうかを決定するように権利を与えられている。特定のサービスに対する加入者は、権利を与えられ、プロフィールリーダ６５２、対応する加入者プロフィールを検索して、用いることによって、ならびに、様々な要因を単独でまたは組み合わせて試験することによって決定され得る。要因は、例えば、任意の月内で許可されたダウンロード数、ダウンロードに必要とされる時間、１日および１週でリクエストがなされる時間、特別提供の利用可能性およびグレースピリオド等を含み得る。加入者検証器６０１は、また、加入者が所属する加入者グループを決定し得、加入者グループ全体として考慮される、および、考慮されないサービスを決定することによって加入者に許可されたアクセスレベルを決定する。加入者検証器によって実行された決定の例示的な実施形態は、図１７を参照して説明される。
【００６４】
デバイス検証器６０２は、加入者デバイス（この加入者デバイスからリクエストがなされる）のタイプおよび能力を決定し、デバイスの能力が特定のアプリケーションをサポートするために十分であるかどうかを決定する。加入者デバイスの能力は、存在するなら、要求している加入者デバイスに対応するプロフィールリーダ６５２を用いて検索することによって決定されている。デバイスプロフィールは、加入者デバイスで適切に実行する要求されたアプリケーションによって必要とされた特性をデバイスが有するかどうか決定するように試験される。デバイス検証器５０２によって実行された決定の例示的な実施形態は、図１８を参照して説明される。
【００６５】
プリペイド請求法がＭＡＳによってサポートされるとき、個々の加入者用の請求記録が格納される場所はどこでも、プリペイド請求検証器６０３は、通信事業者プリペイド請求インフラストラクチャをクエリする。ダウンロードされたリクエストは、通常、通信事業者によって示されたように、加入者の口座に十分な資金があるときのみ、プロビジョニングへと進むことを許可される。
【００６６】
加入者デバイスが要求されたアプリケーションを動作させるために適切であることをプロビジョニングマネージャ６００が決定した後、加入者は、アプリケーション用い、十分な資金を有している（プリペイド請求スキームの一部の場合）ことを認証される。次いで、プロビジョニングマネージャ６００は、デプロイメントマネージャのプロビジョニングインタフェースを呼出し、対応するプロビジョニングされたアプリケーションを獲得する。デプロイメントマネージャは、図７を参照して説明され、要求されたアプリケーションを検索かつプロビジョニングし、それをプロビジョニングマネージャ６００に戻す。
【００６７】
加入者デバイスにダウンロードするために適したプロビジョニングされたアプリケーションがデプロイメントマネージャから獲得された後、プロビジョニングマネージャ６００は、オプションでリクエストをポストプロセスする。プリプロセスすることによって、ポストプロセスは、検証されたリクエストに対してさらなる修正を実行し得、これにより、この修正は、ＭＡＳの機能を拡張するように用いられ得る。例えば、命令は、プロトコルマネージャ（例えば、図５のプロトコルマネージャ）を後に導入し、カスタムプロトコルに対するリクエストをパッケージ化する。
【００６８】
上述したように、（図５のデプロイメントマネージャ５０６等の）デプロイメントマネージャは、プロビジョニングマネージャからの加入者リクエストを受信し、または、（例えば、システム管理者から）直接のリクエストを受信して、リクエストに対応するプロビジョニングされたアプリケーションを獲得する。リクエストは、要求されたアプリケーションのＵＲＬを含み、要求されたアプリケーションは、アプリケーション用のソースの位置を示す。一実施形態において、ＵＲＬは、ミラーサイトのリストを参照し、ＭＡＳから決定された最適位置からアプリケーションを検索する。別の実施形態において、ＵＲＬは、プロキシであり、デプロイメントマネージャは、ＵＲＬをその実際の位置に再び向ける。このような方法は、さらなる安全な層をシステムに提供し得る。アプリケーションに対する位置を示す任意の方法がこれらの技術によって用いられ得、これらの技術がＵＲＬではなくインジケータで動作することを、当業者は認識している。アプリケーションは、また、アプリケーションが配置され、加入者に送られる前に、送信用に点検され、最適化され、そして、編集される。
【００６９】
図７は、モバイルアプリケーションシステムのデプロイメントマネージャのコンポーネントの例示的なブロック図である。デプロイメントマネージャ７００は、リトリーバ７０１、リモートフェッチ７０２、ローカルフェッチ７０３、インスペクター７０４、オプティマイザー７０５、計装インストーラ７０６、および、アプリケーションパッケージャ７０７を含む。リトリーバ７０１は、リモートフェッチャー７０２かローカルフェッチャー７０３かのいずれかを用いて適切なホストサーバからアプリケーションコードを獲得し、次いで、様々なコンポーネントを介してアプリケーションコードをし、適切にアプリケーションコードをプロビジョンする。特に、インスペクターコンポーネント７０４は、不当のコードおよび禁止されたＡＰＩのためのアプリケーションを点検する；オプティマイザーコンポーネント７０５は、可能なら、コードのサイズを低減する；計装インストーラ７０６は、通信事業者特定規約および管理機能を、例えば、請求および通告メッセージをコードに組み込む。
【００７０】
詳細には、リトリーバ７０１は、多数のユーザおよび多数の通信事業者が異なるプロトコルを用いて様々なネットワークを介して通信することを可能にする。このことは、通信事業者が分配のためにホストするソフトウェアアプリケーション（コンテンツ）の位置で通信事業者を柔軟にすることを可能にすることによって、部分的に達成される。例えば、通信事業者は、ＦＴＰまたはＨＴＴＰサーバ、標準ＤＢＭＳ等のデータリポジトリに対する指定されたディレクトリにこのようなアプリケーションを格納することによって通信事業者自身のネットワークから全ての利用可能なアプリケーションをホストすることを選択し得る。通信事業者アプリケーションストア７０８は、このようなデータリポジトリであり、ＭＡＳ自体のサーバに常駐し得る。リトリーバ７０１は、ローカルフェッチャー７０３を活動させ、ローカルに格納されたデータのコピーを検索する。通信事業者は、また、信用された第３者のアプリケーションプロバイダにリモートアプリケーションホスト７０９からのアプリケーションをホストすることを可能にすることを選択し得る。このリモートアプリケーションホスト７０９は、信用された第３者アプリケーションプロバイダの制御の下にある。さらに、オープンプロビジョニングを実行するように用いられるとき、リトリーバ７０１は、必ずしも信用されたソースからではない第三者のホストからアプリケーションを検索し得る。両方の場合、通信事業者は、第３者によって供給されたＵＲＬを用い、入来リクエストをリモートアプリケーションホスト７０９のうちの１つでホストされる特定のダウンロード可能なアプリケーションに帰する。リトリーバ７０１は、通常、リモートフェッチャー７０２を活発にし、このようなホストが公開プロトコルを介してアクセス可能であるときに、リモートアプリケーションホスト７０９でホストされたこのようなアプリケーションを検索する。一実施形態において、ローカルフェッチ７０３は、ローカルに格納されたデータを素早く検索するように最適化され得るが、一方で、リモートフェッチャー７０２は、必要な公開プロトコルをインプリメントし、公開ネットワークを介してアクセス可能なホストに常駐するアプリケーションを検索する。
【００７１】
信用された第３者ホストまたは通信事業者の好みに応じて、リトリーバ７０１によって検索されたアプリケーションコードは、既にプロビジョンされ得る。リトリーバ７０１がプロビジョンされないコードを獲得する場合、コードは、インスペクタ７０４、オプティマイザ７０５および計装インストーラ７０６にさらなる処理のために送られる。インスペクタ７０４は、検索されたプロビジョンされないアプリケーションコードを試験し、不当なコードを検出する。Ｊａｖａ（登録商標）コードにおいて、インスペクタ７０４は、また、アプリケーションコードのクラス解析を実行し得、アプリケーションにおけるクラスが番号、タイプ、ＡＰＩコールの周波数等の所望の標準に一致する。さらに、インスペクタ７０４は、アプリケーションフィルタを適用して、パッケージ、およびメソッド名、クラス、フィールドまたは、不便で、不当な挙動を有すると疑われる、または、要求している加入者、ターゲットデバイスまたはいくつかの他のターゲットによって用いられるための認証され得ないＡＰＩの他のフォームを検出する。インスペクタ７０４は、また、アプリケーションフィルタを適用し得、ＡＰＩ使用パターンを検出し得る。インスペクタ７０４は、（図６を参照して説明された）プロビジョニングマネージャによって検索された加入者およびデバイスプロフィールを使用するために利用可能であり、これにより、インスペクタ７０４は、デバイス毎に、または、加入者ベース毎に制限を強化し得る。例示的な実施形態において、インスペクタ７０４は、このようなパラメータの閾値、および、例えば、ロギングマネージャ等の他のエンティティによるさらなる点検用のパラメータをフラッギングするための閾値が、調節されることを可能とする。インスペクタ７０４が潜在的に不当な挙動を探索する場合、プロビジョニング（および、引き続くダウンローディング）、ならびに、ロギングマネージャに報告された犯罪者のアイデンティティによる侵害は、防がれ得る（または、加入者が警告する）。
【００７２】
インスペクタ７０４が首尾良く検索されたプロビジョニングされないアプリケーションコードを試験した後、コードは、さらなる処理のためにオプティマイザー７０５に転送され、アプリケーションのサイズを減少させる。オプティマイザー７０５は、当該分野で周知の方法を用い、可変の名前を短くし、アプリケーションから用いられていないコードを取り除く。このような最適化プロシージャは、通常、ダウンロードをより早くする。オプティマイザー７０５は、また、当該分野で周知の技術を用い得、この技術が実行されると、特定の命令の使用をより効率的な命令に変化させる等で、アプリケーションのスピードが増加される。ＭＡＳのコンポーネントが拡張され得るか修正され得るので、任意の最適化がシステム内に組み込まれ得ることは、当業者は認識している。
【００７３】
最適化の後、点検され、最適化されたアプリケーションコードは、さらなる処理のために計装インストーラ７０６に転送される。ダウンロード可能なアプリケーションの供給元が通常、個々の加入者のための要求されたアプリケーションを修正する能力を有しないので、加入者に特定のコードを加えるために、アプリケーションのコードを修正することが望ましい。例えば、「お試し使用」スキーム等の請求オプションによって、例えば、アプリケーションに、ある回数のみ、または、特定の期間のみ実行させるアプリケーション内にコードを挿入することによってインプリメントされ得る。同様に、目的をロギングするための情報を報告するコード、または、（伝送されたネットワークパケットの数に基づいて充填するパケットベースの請求等の）他の請求オプションのための情報がインプリメントされ得る。また、オープンプロビジョニングの場合、加入者が信用されていないソースからコンテンツをダウンロードして、実行しようとしていることを、加入者に警告するコードが備えられ得る。計装インストーラ７０６は、また、通信事業者によって特定される他の規約（例えば、促進および広告キャンペーンをインプリメントするという規約）にしたがって、アプリケーションのコードを修正し得る。ライブラリを操作する等の周知の方法を用いることによって、または、クラスおよびメソッドをサブクラス分けすることによって、コードが、多くの他の目的のために備えられ得る、または、所定の位置で備えられ得ることは、当業者は、認識している。
【００７４】
計装インストーラ７０６がリクエストされたアプリケーションを備えた後、アプリケーションパッケージャ７０７が、点検され、最適化され、備えられたアプリケーションをパッケージ化する。プロビジョニングマネージャによって獲得されたデバイスプロフィールから決定されて、図６を参照して説明されるように、アプリケーションパッケージャ７０７は、加入者デバイスが読み出し得る態様で、アプリケーションファイルのコンテンツをフォーマットすることによって、要求されるアプリケーションをパッケージ化する。例えば、多くの加入者デバイスは、圧縮された「ＪＡＲ」フォーマット（Ｊａｖａ（登録商標）アーカイブフォーマット）内に提示されるファイルを読み出す能力を有している。この「ＪＡＲ」フォーマットは、要求されたＪＡＶＡ（登録商標）アプリケーションを圧縮し、かつ、パッケージ化するように用いられるフォーマットである。いくつかのデバイスが圧縮されたＪＡＲファイルを受け得ないので、アプリケーションパッケージャ７０７は、圧縮されたＪＡＲフォーマットにファイルを受け得ないこれらの加入者デバイスのためのプロビジョニングされたアプリケーションのカスタムパッケージングを提供する。このようなパッケージングコンバータ、および、ＪＡＲ以外のフォーマット用の他のコンバータが、パッケージングルーチンをサブクラス分けすることによる等の周知の技術を用いて、アプリケーションパッケージャ７０７にインストールされ得ることは、当業者に認識されている。さらに、いくつかの加入者デバイスは、加入者デバイスが受信し得るパケットのサイズを制限し得る。検出されるとき、アプリケーションパッケージャ７０７は、このような加入者デバイス用のプロビジョンされたアプリケーションを、多数のデータファイルにパッケージ化し得る。加入者デバイスは、受け取ると同時に、この多数のデータファイルを単一のＪＡＲファイルに組み込み得る。多数のデータファイルは、アプリケーションをインストールするために加入者デバイスによって用いられ得る。
【００７５】
図５を参照して説明されるように、アドミニストレータコンポーネント（例えば、アドミニストレータ５０９）は、異なるタイプのユーザに用いられ得、モバイルアプリケーションシステムの様々なコンポーネントを構成し、嗜好を特定する。図８は、モバイルアプリケーションシステムのアドミニストレータコンポーネントの例示的なブロック図である。一実施形態において、アドミニストレータ８００は、好ましくは、多数のウェブベースユーザインタフェースを提供して、コンテンツプロバイダ、システム（通信事業者またはＭＡＳ）アドミニストレータ、加入者、および、顧客サービスサポートスタッフを、ＭＡＳのコンポーネントにアクセス可能にし、彼らの経験をカスタマイズ可能にする。特に、例示的なアドミニストレータは、コンテンツプロバイダウェブサイト８０１、アドミニストレータウェブサイト８０２およびパーソナリゼーションウェブサイト８０３を提供する。それぞれ説明されたウェブサイトが多数のスクリーンディスプレイを含み得ること、および、これらのおよび／または他のスクリーンディスプレイ、およびウェブサイトが同じ結果を達成する様々な構成で結合され得ることは、当業者が認識している。例えば、アドミニストレータウェブサイト８０２は、別々の顧客ケアウェブサイト８０４をオプションで含み得る。この顧客ケアウェブサイト８０４は、（通常、通信事業者の）顧客ケアの代表者によって用いられ得、通信事業者に代わって、個々の加入者の口座を管理する。
【００７６】
アドミニストレータ８００は、コンテンツプロバイダが用いるためのコンテンツプロバイダウェブサイト８０１を提供し、ダウンロード可能なアプリケーションをＭＡＳに提出し、提出されたダウンロード可能なアプリケーションが検討され（例えば、点検され）、公開用に認可されるかどうかをモニタする。コンテンツプロバイダは、また、コンテンツプロバイダウェブサイト８０１を用い得、アプリケーションプロバイダに変更を勧め、それらのアプリケーションの人気をモニタする、または、ＭＡＳアドミニストレータと通信する。
【００７７】
アドミニストレータ８００は、また、ＭＡＳシステムアドミニストレーションにアドミニストレーションウェブサイト８０２を提供し、例えば、コンテンツプロバイダによって提出された、公開され、ペンディングのアプリケーションを管理する。一実施形態において、アドミニストレーションウェブサイト８０２インタフェースは、別々のノードを提供し、アカウント、アプリケーション、加入者、デバイス、サーバおよびレポートを構築、構成および／管理する。
【００７８】
システムアドミニストレータは、アドミニストレーションウェブサイト８０２のアプリケーションノードを用い得、通信事業者によってサポートされたグローバルな請求方法を特定する。一実施形態において、アドミニストレータは、ダウンロード毎、ネットワーク利用毎（例えば、送信ベース）、加入毎、および、金額のかからないお試し使用毎に料金を発生させる多数の請求オプションを選択し得る。
【００７９】
他の機能は、また、アドミニストレーションウェブサイト８０２を介してシステムアドミニストレータにアクセス可能である。例えば、システムアドミニストレータは、加入者ノードを用い得、加入者によってＭＡＳの使用を管理し、各加入者用の加入者プロフィールを構築し得る。加入者プロフィールは、各加入者によってダウンロードされた公開されたアプリケーションのリストを維持し、特定の加入者が動作し得ない禁止されたアプリケーションのリストを維持し、特定のユーザが所属する加入者グループを生成かつ維持する。一実施形態において、これらのプロフィールは、ＭＡＳのデータリポジトリ（例えば、図５におけるデータリポジトリ）に格納され、プロビジョニングマネージャのプロフィールリーダ（例えば、図６のプロフィールリーダ６５２）によって読み出される。
【００８０】
システムアドミニストレータは、また、加入者にメッセージ（例えば、更新されたバージョンが加入者によって既にダウンロードされたアプリケーションのうちの１つに対して利用可能であるという通告）を送り得る。この挙動は、時折、「プッシュ」能力と呼ばれる。加入者とコンタクトを取るための情報は、加入者プロフィールから通常利用可能である。
【００８１】
さらに、システムアドミニストレータは、計装インストーラ７０６が適切にダウンロードされたコンテンツを計装する場合、ワイヤレスネットワークを介してダウンロードされたアプリケーションを遠隔に動作させる、または、停止させることを選択し得る。例えば、計装されたアプリケーションは、アプリケーションの新規のバージョンが利用可能であるかどうかを認識するようにホストサーバ（通信業者または第３者）によってチェックするように強要され得る、および、アプリケーションサーバの新規のバージョンをダウンロードするかどうかを判定するように加入者を促し得る。計装されたアプリケーションは、また、時限が失効する、または、アプリケーションが動作可能な回数を越える（例えば、お試し期間請求オプションの使用）かどうかを判定するようにホストサーバによってチェックすることを強要され得る。計装されたアプリケーションは、また、例えば、１日のセットされた期間内に特定の回数のみ使用されるようにアプリケーションを制限し得る、１日時間制限を置き得る。これらの制限によって、効果的に、システムアドミニストレータが加入者の特権を無効にする、または、制限することを可能にし、アプリケーションが加入者のワイヤレスデバイスにダウンロードされた後にでさえアプリケーションを実行可能にする。他の制限および能力が同様に強要され得ることは、当業者が認識している。
【００８２】
システムアドミニストレータは、アドミニストレータウェブサイト８０２のデバイスノードを用い得、アプリケーションのプロビジョニング中の検証のために用いられる情報を提出し、かつ、維持する。例えば、システムアドミニストレータは、特定のデバイスに対応するデバイスプロフィールのリストを生成かつ維持し得る。通常、システムアドミニストレータは、ＭＡＳによってサポートされる各デバイス用のデバイスプロフィールを生成する。新規のデバイスプロフィールおよび対応するデバイス指定は、必要なら加えられ得る。各デバイスプロフィールは、例えば、ランタイムメモリおよびフラッシュメモリの量、チップアイデンティフィケーション、最大ダウンロードサイズ、およびデバイスが「ＯＴＡ」に準拠しているかどうか（ＯＴＡは、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍの放送適合基準（Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍ’ｓ  Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  ｃｏｎｆｏｒｍａｎｃｅ  ｓｐｅｃｉｆｉｃａｔｉｏｎ）を参照する。ＯＴＡに従うデバイスは、他の能力に共通してデバイスの首尾良いダウンロードを追跡する。）等のハードウェアに特定の情報およびソース特性を含む。
【００８３】
各デバイスプロフィールは、また、デバイスによってサポートされる単一のＪａｖａ（登録商標）プロフィールを指定し得る。Ｊａｖａ（登録商標）プロフィールは、デバイスによってサポートされるＪａｖａ（登録商標）ＡＰＩを特定する。例えば、ＭＩＤＰ１．０規格（デバイスによってインプリメントされるＪａｖａ（登録商標）ＡＰＩのセットを規定する周知の規格）は、通常、この整合性を示すデバイスプロフィールを有する。デバイス（および、関連するＪａｖａ（登録商標））プロフィールは、特定のデバイスがリソースを有し、アプリケーションによって必要とされるＡＰＩのセットをサポートすることを保証するために、アプリケーションとの比較のための検証プロセス中にプロビジョニングマネージャによって用いられる。同じＪａｖａ（登録商標）プロフィールが多数のデバイスに関連し得るが、デバイスは、通常、１つのＪａｖａ（登録商標）プロフィールをサポートし得るのみである。システムアドミニストレータは、ＡＰＩのセットを特定し、かつ、説明するアーカイブファイル（例えば、ＪＡＲファイルまたは．ｚｉｐファイル）の名前を特定することによって、Ｊａｖａ（登録商標）をロードする。ＭＡＳは、特定のアーカイブの構造（パッケージ、クラス、メソッドおよびフィールド定義）のために特定のアーカイブを試験し、この構造を含むプロフィールを生成する。これらのプロフィールは、また、アプリケーションフィルタを生成するように用いられ得、このアプリケーションフィルタによって、特定のＡＰＩを用いるアプリケーションがプロビジョニングする、および／または、ダウンロードすることを防ぐ。Ｊａｖａ（登録商標）が可能なデバイスおよびＪａｖａ（登録商標）ＡＰＩに関して主に記載されるが、特定のＡＰＩ、オブジェクト、クラス、変数および／または他のデータ構造がアプリケーションに存在して、デバイスによってサポートされているかどうかを決定することを言語がサポートしている限り、および、構造がバイト−コードレベルで確認され得る限り、ＭＡＳが他の言語規格および他の言語が可能なデバイスに順応され得ることは、当業者が認識している。さらに、受信しているアプリケーションがソースをコンパイル、または、インタプリタし得、実行可能なファイルを生成する限り、これらの技術がソースコードレベルで使用するために採用され得ることは、当業者は認識している。
【００８４】
アドミニストレーションウェブサイト８０２によって、システムアドミニストレータが、プロビジョニングおよびデプロイメントマネージャによって提供される検証および点検プロセスを補充かつ補完する様々なセキュリティ技術および規約をインプリメントすることが可能となる。１つのこのような技術は、アプリケーションフィルタを規定する能力であり、記載されるように、これらは、特定のデバイスまたは他のターゲットを用いるアプリケーションによって呼び出され得るべきではないＡＰＩを特定するように用いられる。これらの制限された能力および構造は、加入者のリクエストに応答して、アプリケーションプロビジョニングプロセス中に識別され得て、コンテンツプロバイダによるアプリケーションを提出すると、加入者が特定のデバイスに不適切なコードをロードしないことを保証することを助ける。提供される別のセキュリティ技術は、ＵＲＬを変更する能力である。システムアドミニストレータは、アドミニストレーションウェブサイト８０２のサーバノードを用いてＵＲＬを変更マッピングを特定することによって、ＭＡＳユーザの利便性および安全のためにＵＲＬを変更し得る。例えば、認証されていない広告サイトを指すＵＲＬは、支払い広告主からの広告を提供するＵＲＬに変更され得る。同様に、コンテンツを取り除いた後、システムアドミニストレータは、エラーメッセージの代わりに、以前にコンテンツを参照したＵＲＬを変更することを望む。また、変更されたＵＲＬは、アプリケーションの実際の位置を隠すように、アプリケーションがより容易に移動されることが可能であるように用いられ得る。入来データを受信すると、ＭＡＳは、アプリケーションを特定する任意のＵＲＬと、アドミニストレーションウェブサイト８０２を用いて管理された、変更されたＵＲＬのリストとを比較し、特定される場合にそれらを変更する。さらなるおよび他のセキュリティ技術がＭＡＳによって追加され、利用され得、必要なら、アドミニストレーションウェブサイト８０２を介して構成され、様々な安全なメカニズムを提供して、加入者、コンテンツプロバイダ、アドミニストレータ、および様々なＭＡＳコンポーネント間で安全に通信し、ＭＡＳに格納される、ＭＡＳを介してアクセス可能である、または、クライアントデバイスに格納されるデータを安全に送達する。例えば、ＫＳＳＬ等の安全なプロトコルをサポートするデバイスが製造されるので、様々なＭＡＳコンポーネントは、プロトコルを用いるように構成され得る。さらに、適用可能な場所において、安全なインタフェースは、ウェブベースのインターフェースと、ウェブベースのインタフェースによって操作されたＭＡＳコンポーネントとの間のコンポーネントとしてインストールされ得る。
【００８５】
アドミニストレータ８００は、また、パーソナリゼーションウェブサイト８０３を提供し、このパーソナリゼーションウェブサイト８０３は、加入者によって用いられ、加入者に関連するサービスおよび情報を注文、維持および表示し、アプリケーションを管理する。加入者は、パーソナリゼーションウェブサイト８０３を用いて、（請求された金額の変化をユーザに生じさせる可能性があり得る）サービスプランを変化させることによって、コンテンツのさらなるカテゴリーに加入する。新規のサービスプランが選択されると、次いで、加入者は、関連したコンテンツカテゴリーを用いるように認証される。
【００８６】
加入者は、また、現在のアプリケーションを観察することによって、アプリケーションを追加することによって、アプリケーションを取り除くことによって、アプリケーションを統括することによって、加入者のアプリケーションを管理し得る。アプリケーションを参照して説明されるが、これらの技術が任意のダウンロード可能なコンテンツに適用され得、アプリケーションベースの管理に加えて、カテゴリーまたは他の抽象概念によってアプリケーションが管理され得ることは、当業者は認識している。加入者は、パーソナリゼーションウェブサイト８０３を用い得、加入者の「個人アクセスリスト」（「ＰＡＬ」）を生成かつ管理する。加入者のＰＡＬは、例えば、アプリケーション探索中に、加入者のデバイスにＭＡＳを表示させることを加入者が所望するアプリケーションのリストである。このリストは、アプリケーションの初期セット、または、アプリケーションを含まない初期セット、あるいは、加入者がダウンロードした、または、将来にダウンロードすることを所望するアプリケーションのリストを含む、あるいは、これらの組み合わせを含み得る。一実施形態において、ＰＡＬは、加入者がダウンロードしたものを最初に含む。それぞれのワイヤレスデバイスおよびあらゆるワイヤレスデバイスに対してアプリケーションダウンロードの記録を維持しているので、ＭＡＳは、加入者のダウンロードされたアプリケーションを追跡可能である。
【００８７】
加入者は、また、パーソナリゼーションウェブサイト８０３を用い得、アカウント情報、および、ダウンロードまたはアカウント活動の履歴を獲得および変更する。
【００８８】
パーソナリゼーションウェブサイト８０３を介して、システムアドミニストレータが、更新されたまたは新規のアプリケーション、あるいは、「共催イベント」（「ｔｉｅ−ｉｎｓ」）の利用可能性を加入者に通知し得る。これらによって、システムアドミニストレータは、（「プッシュ」メッセージを介して）製品の提供または広告を表示し得る。加入者は、加入者のワイヤレスデバイスを用いて、または、（パーソナルコンピュータ等の）ワイヤレスデバイスを介する優れた表示特性を好ましくは有する表示有線デバイスを用いてパーソナリゼーションウェブサイト８０３にアクセスし得る。優れた表示特性を有する有線デバイスがパーソナリゼーションウェブサイト８０３にアクセスするように用いられるとき、優れた表示特性が強化された共催イベントをサポートするように用いられ得る。
【００８９】
様々なウェブサイトベースのユーザインタフェースを存在するＭＡＳコンポーネントに提供することに加えて、ＭＡＳのアドミニストレータコンポーネント（例えば、図５のアドミニストレータ５０９）によって、システムアドミニストレータは、ＭＡＳ自体のコンポーネントを再プログラミングすることを通して、および、プロビジョニングルールを定義することを通して、カスタマイズ可能なプロビジョニング関連の規約をインプリメント可能となる。一実施形態において、再プログラミングは、アドミニストレータウェブサイト８０２を通して達成される。しかし、他のメカニズムを用いて、例えば、登録メカニズムを通してアドミニストレータと共に異なるコンポーネントおよびプロフィールを登録することによって、または、ＭＡＳインタフェースの要素をサブクラス分けすることによって、この機能が達成され得ることは、当業者が認識している。提出されたアプリケーションを観察する際に、プロフィールマネジメント、レポート生成およびサーバアドミニストレーションを実行する際に、この機能によって、加入者、通信事業者、システムアドミニストレータの柔軟性が強化される。
【００９０】
例えば、システムアドミニストレータは、プロフィールマネジメントを用い得、プロビジョニングルールをインプリメントする。プロフィールは、本質的に動的なデータ駆動技術を提供する。加入者のためのサービスの様々なカテゴリー、および、加入者のグループを特定することによって、プロビジョニングルールは、様々なプロフィールを修正することによって、例えば、アドミニストレータコンポーネントのウェブサイトインタフェースを用いることによって、個々に適用され得るか、加入者のグループに適用され得るかである。さらに、プロビジョニングルールは、サービスのカテゴリーが個々の加入者、および、加入者のグループに適用される方法を決定するように用いられるプロフィールに格納され得る。プロビジョニングルールは、それら自体で修正され得る。
【００９１】
プロフィールマネジメントによって、プロビジョニング関連および請求関連のサービス規約を定義する際に高度な柔軟性を可能にする。例えば、通信事業者は、基本的なサービスレベルおよび高級なサービスレベルを含む加入サービスを提供し得る。基本的なサービスの加入者は、加入者がダウンロードする各アプリケーションに対して個々に変更され得一方で、高級なサービスの加入者は、より高い月額料金を払うが、付加的な料金を払うことなく無制限の数のアプリケーションをダウンロード可能とされる。別の例において、銀行等の企業は、通信事業者と交渉し、サービスの特定のタイプを設定する。このサービスのタイプにおいて、企業の顧客は、例えば、銀行の顧客が口座の残高を見る、および、資金を送ることを可能にする加入者デバイスの１つのタイプに対して、企業に特定のアプリケーションをダウンロード可能である。この例では、通信事業者は、企業に対して加入者プロフィールをホストし、ＬＤＡＰおよび当業者に周知の関連するデータベース等の産業標準データベースを用いて企業がこの情報にアクセス可能となる。
【００９２】
アドミニストレータ８００はまた、ＭＡＳの他のコンポーネントを統治するために必要なユーザインタフェースを提供する。これらのインタフェースを介して、システムアドミニストレータは、ＭＡＳの異なるモジュールを観測し、サーバ側のセキュリティを管理し、いつでもシステムステータスおよびサーバパフォーマンスをモニターし得る。システムアドミニストレータはまた、加入者のアカウントを管理し、様々なレベルのアドミニストレーティブ特権を割り当て得る。サーバアドミニストレータはまた、ログ管理およびトラブルシューティングを目的とした分析ツールといった機能を含む。
【００９３】
例示の実施形態において、モバイルアプリケーションシステムの方法およびシステムは、１つ以上の多目的コンピュータシステムおよび典型的なクライアント／サーバアーキテクチャによる無線ネットワークにおいてインプリメントされ、分散環境で動作するように設計および／または構成され得る。例示の実施形態は、例えば、１つ以上の無線ネットワークを介してＭＡＳと通信する複数の加入者デバイスを有するネットワーク環境といった、グローバルネットワーク環境において動作するように設計される。
【００９４】
図１２は、モバイルアプリケーションシステムの実施形態を実行するための多目的コンピュータシステムおよび加入者デバイスの例示のブロック図である。図１２のコンピュータ環境は、無線キャリア１２０８を介して通信する加入者デバイス１２０１および多目的コンピュータシステム１２００を含む。各ブロックは、特定の実施形態に適した１つ以上のブロックを表し得、それぞれが個別の物理ロケーションに常駐し得る。
【００９５】
加入者デバイス１２０１は、コンピュータメモリ（「メモリ」）１２０２、ディスプレイ１２０３、入力／出力デバイス１２０４、および中央処理装置（「ＣＰＵ」）１２０５を備える。ダウンロードされたアプリケーション１２０７と共にメモリ１２０２に常駐するハンドセットアドミニストレーションコンソール（Ｈａｎｄｓｅｔ  Ａｄｍｉｎｉｓｔｒａｔｉｏｎ  Ｃｏｎｓｏｌｅ）１２０６が示される。ハンドセットアドミニストレーションコンソール１２０６は、好ましくは、ＣＰＵ１２０５で実行し、現在、メモリ１２０２にあるアプリケーション１２０７を実行するか、または、上述の図を参照して記載されるように無線キャリア１２０８を介してＭＡＳ１２０９からのアプリケーションをダウンロードする。
【００９６】
多目的コンピュータシステム１２００は、１つ以上のサーバおよび／またはクライアント計算システムを備え、分散ロケーションの橋渡しをし得る。一実施形態において、ＭＡＳは、Ｊａｖａ（Ｒ）  ２  Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ）を用いてインプリメントされ、Ｊ２ＥＥコンプライアントアプリケーションサーバを提供する多目的コンピュータシステムで実行する。本実施形態によると、ＭＡＳは、サーバ側のウェブ層、ビジネス層、およびデータベース層をサポートするＪ２ＥＥ多層構成アプリケーションアーキテクチャを用いて設計され、符号化される。従って、多目的コンピュータシステム１２００は、１つ以上のコンポーネントを実行することが可能な一つ以上のサーバおよび／またはＭＡＳのデータレポジトリを表す。
【００９７】
図示されるように、多目的コンピュータシステム１２００は、ＣＰＵ１２１３、メモリ１２１０、ならびに随意的にディスプレイ１２１１および入力／出力デバイス１２１２を備える。ＭＡＳ１２０９のコンポーネントは、他のデータレポジトリ１２２０および他のプログラム１２３０と共に、メモリ１２１０内に常駐することが示され、好ましくは、１つ以上のＣＰＵ１２１３で実行する。典型的な実施形態において、ＭＡＳ１２０９は、プロビジョニングコンポーネント１２１４、プロフィールおよび構造データを格納するためのデータレポジトリ１２１５、ならびに、アプリケーションストア１２１６を含む。以前に記載されたように、ＭＡＳは、キャリアまたは他のホストシステムの必要性およびキャリアまたは他のホストシステムとの統合に依存する他のデータレポジトリおよびコンポーネントを含み得る。プロビジョニングコンポーネント１２１４は、図５に図示され、かつ、図５を参照して記載されるＭＡＳのコンポーネントを含む。プロビジョニングコンポーネント１２１４により、ＭＡＳ１２０９は、ダウンロード可能なアプリケーション（単数または複数）の発見のための要求を受信すること、特定の加入者および特定の加入者デバイスによる使用のための要求の適合性を検証すること、その結果、要求されたアプリケーションをカスタマイズすること、および加入者デバイス１２０１に取得したアプリケーションを送信することが可能になる。アプリケーションストア１２１６は、加入者デバイス１２０１にダウンロードするのに適したアプリケーションを格納するデータレポジトリである。加入者デバイス１２０１にクイックダウンロードするためのアプリケーションが予め提供され得る（「静的プロビジョニング」）。すなわち、要求によって、アプリケーションが提供され得る（「動的プロビジョニング」）。データレポジトリ１２１５は、データレポジトリおよび回収サービスを提供して、加入者の熟練度およびデバイスの機能を確立し（プロフィール管理に使用されるプロフィールをホストすること）、各カスタマーデバイスに適したアプリケーションを決定する。
【００９８】
ＭＡＳ１２０９が、複数の極めて不均一なコンピュータシステムおよびネットワークから成る分散環境にインプリメントされ得ることを、当業者は認識する。例えば、一実施形態において、プロビジョニングコンポーネント１２１４およびアプリケーションストア１２１５は、物理的に異なるコンピュータシステムに位置される。別の実施形態において、プロビジョニングコンポーネント１２１４の様々なコンポーネントは、個々のサーバマシンでホストされ、データレポジトリ１２１５および１２１６から遠隔に配置され得る。本発明の技術を使用するためのプログラムおよびデータの異なる構成およびロケーションが検討される。
【００９９】
例示の実施形態において、プロビジョニングコンポーネント１２１４は、１９９９年にＳｕｎ  ＭｉｃｒｏｓｙｓｔｅｍｓのＪａｖａ（Ｒ）  ２  Ｐｌａｔｆｏｒｍ（Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ，Ｖｅｒｓｉｏｎ  １．２）に詳細に記載されるように、Ｊ２ＥＥを用いてインプリメントされ、本明細書中に参考として援用される。プロビジョニングコンポーネント１２１４は、プロトコルマネージャ、プロビジョニングマネージャ、配置マネージャ、ビリングマネージャ、および他のコンポーネントを含む。図１３〜２８は、これらの各コンポーネントによってインプリメントされる特定のルーチンの多様な例示の実施形態を記載し、図３〜８を参照して記載される機能性を実現する。例示の実施形態において，これらのコンポーネントは、同時に、かつ、非同期的に実行し得る。従って、コンポーネントは、周知のメッセージパッシング技術を用いて通信し得る。等しい同期の実施形態もまたＭＡＳインプリメンテーションによってサポートされることは、当業者にとって認識されることである。さらに、当業者は、他のステップが各ルーチンに対して実装され得ることを認識し、異なるオーダーおよび異なるルーチンにおいて、まださらにＭＡＳの機能を達成する。
【０１００】
図１３は、異なるプロトコルを用いて、変化するワイヤレスネットワークを介して様々な加入者デイバスと通信するために、モバイルアプリケーションシステムのプロトコルマネージャによって実行されるし処理の例となるフロー図である。（例えば、図５におけるプロトコルマネージャ５０３を参照されたい。）ステップ１３０１において、プロトコルマネージャは初期化される。ステップ１３０２において、プロトコルマネージャは、加入者デイバスからの入来データリクエストがあるかどうかを判断し、かつ、あれば、ステップ１３０３に進み、なければ、ステップ１３０６に続く。ステップ１３０３において、プロトコルマネージャは、どのワイヤレスネットワーク（もしくはワイヤネットワーク）を介してリクエストが送信されたのかを判断することにより、入来リクエストに対して利用されるプロトコルを判断し、かつ、入来リクエストと関連するレコードに、その判断された保留中のリクエストに対するプロトコルを格納する。プロトコルレコードおよびシステムによって処理されるような入来リクエストの間の関連は、例えば、リクエストメッセージヘッダー内のプロトコルレコードに対する参照を格納することによって、維持される。ステップ１３０４において、プロトコルマネージャは、最初に利用されたプロトコル（例えば、ＨＴＴＰ）に対する入来リクエストを変換する。ステップ１３０５において、プロトコルマネージャは、変換されたリクエストをプロビジョニングマネージャ（例えば、図５におけるプロビジョニングマネージャ５０４）に送信し、その後、リクエストの処理ステップは終了する。ステップ１３０６において、プロトコルマネージャは、加入者デバイスに対する出行データリクエストのあるなしを判断し、もしあれば、ステップ１３０７に進み、なければ、リクエストの処理ステップは終了する。ステップ１３０７において、プロトコルマネージャは、出力データに対応する入来リクエストと関連する判断されたプロトコルを取り出す。判断されたプロトコルは、リクエストを発行した加入者デイバスによって利用されるプロトコルである。ステップ１３０８において、プロトコルマネージャは、判断されたプロトコルに応じて出行データメッセージを符号化する／変換する。ステップ１３０９において、プロトコルマネージャは、符号化された出行データを、リクエストを提示した加入者デバイスに送信し、その後、処理ステップは終了する。
【０１０１】
図１４は、加入者デバイスに対して要求されたアプリケーションの適合性を判断し、かつ、要求されたアプリケーションを、加入者デバイスが復号化され得る形式のデバイスに提示するために、モバイルアプリケーションシステムのプロビジョニングマネージャによって実行される処理の例となるフロー図である。（例えば、図５におけるプロビジョニングマネージャ５０４を参照されたい。）ステップ１４０１において、プロビジョニングマネージャは、任意の必要とされる初期化を実行する。ステップ１４０２〜１４１３において、プロビジョニングマネージャは、ＭＡＳ「命令」を処理する。ステップ１４０２において、プロビジョニングマネージャは、入来リクエストで指定されるコマンド（または、ダウンロードするリクエスト）を判断する。ステップ１４０３において、プロビジョニングマネージャは、図６を参照して述べられたように、後で取られるべきあるプロビジョニングステップの拡張、変更または制限を提供するために入来リクエストを解析し、かつ、動的なリクエストを修正することによって、あるいは、通信または構成理由に対して他のパラメター値を挿入することによって、リクエストの前処理を行う。ステップ１４０４において、プロビジョニングマネージャは、「コマンド」がダウンロードのリクエストであるかどうかを判断し、そうであれば、ステップ１４０４に続き、そうでなければ、ステップ１４０８に続く。別の「タイプ」のコマンドとして現在実装されているが、ダウンロードリクエストが、パラメターとして「ＵＲＬ」を指定することによって示されていようとも、それらは本質的にコマンドであり、かつ、コマンド処理を実行するための同等なプログラムの技術が数多く存在することを、当業者は理解する。ステップ１４０５において、プロビジョニングマネージュは、要求されたアプリケーション（コンテンツ）ＭＡＳに認識されているかどうかを判断し、そうであれば、ステップ１４０６に進んでウォールドガーデン（ｗａｌｌｅｄ−ｇａｒｄｅｎ）プロビジョニングを実行し、そうでなければ、ステップ１４０７に進み、オープン（ｏｐｅｎ）プロビジョニングを実行する。例示的な実施形態では、コンテンツが「ＭＡＳに認識されるようにし得るいくらかの方法がある。すなわち、システム管理者がアプリケーションを提供し公表するウェブサイトを利用する方法、コンテンツプロバイダが、最終的に承認され公開されるコンテンツを提示する方法、および、加入者が、提示プロセスを間接的に発生させる通信事業者に既知の信用できる第３者のコンテンツプロバイダから、既知のアプリケーションのダウンロードを要求する方法である。ウォールドガーデンプロビジョニングは、さらに図１５に関連して議論され、オープンプロビジョニングは、図１６を参照してさらに議論される。一旦プロビジョニングがステップ１４０６または１４０７で発生すると、リクエストは、ステップ１４０３において後処理がなされる。一方、ステップ１４０８において、設計されたコマンドがアプリケーションリストに対するリクエストである場合、プロビジョニングマネージャはステップ１４０９に進んで、アプリケーションディスカバリを実行するか、あるいは、ステップ１４１０に進む。アプリケーションディスカバリの後、プロビジョニングマネージャはステップ１４１３に進み、リクエストの後処理を行う。ステップ１４０９において、コマンドがダウンロード履歴に対するリクエストである場合、プロビジョニングマネージャはステップ１４１１に進み、ダウンロードされたアプリケーションのリストを取り出し、ステップ１４１３に進んで、後処理を行う。ステップ１４１２において、コマンドがいくらかの他のＭＡＳコマンドである場合、プロビジョニングマネージャは、適切にコマンドを処理し、ステップ１４１３に進む。ステップ１４１３において、図６に関連して説明されたように、プロビジョニングマネージャは、ＭＡＳの他のコンポーネントを指示するための命令の参照を含むリクエストを修正することによってリクエストの後処理を行い、その結果、他のコンポーネントの機能を拡張となる、または、他のパラメターを修正する機能を実行する。例えば、プロビジョニングマネージャが、ダウンロードを要求する個々人が高価値の広告業者の従業員がクライアントであると判断した場合、プロビジョニングマネージャは、この特定のトランザクションに対する請求を行わないように請求マネージャに指示し得る。リクエストの後処理の後、プロビジョニングマネージャは、他のリクエストが受信されるまで処理を終了する。
【０１０２】
図１５は、プロビジョニングマネージャの実行ウォールドガーデンプロビジョニングルーチンによって、実行される処理の例となるフロー図である。（図１４のステップ１４０６を参照されたい。）ウォールドガーデンプロビジョニングでは、要求されるアプリケーションは、加入者による権限および加入者デイバスの性能に対して検査する。具体的には、ステップ１５０１において、プロビジョニングマネージャは、要求されるアプリケーションに対応する加入者のプロフィール、デバイスのプロフィール、および、アプリケーションのプロフォールを取り出す。１つの実施形態では、これらのプロフィールは、図６においてプロフィールリーダー６５２を呼び出すことによって取り出される。ステップ１５０２において、プロビジョニングマネージャは、アプリケーション検査を実行して、例えば、禁止されたＡＰＩが含まれているために、要求されるアプリケーションがワイヤレス通信事業者によって取り出されたかを検査する。アプリケーション検査は、図１６を参照してさらに説明される。ステップ１５０３において、プロビジョニングマネージャは、加入者検査を実行し、通信事業者請求規約か別の方法で、要求されるアプリケーションに対する権限を加入者が与えられているかどうかを判断する。加入者権限は、図１７を参照してさらに議論される。ステップ１５０４において、プロビジョニングマネージャは、デバイス検査を実行し、要求されるアプリケーションに対応するアプリケーションプロフィールによって指定されるリソースおよび要求されるおよび他の性能をデバイスが有するかどうかを判断する。デバイス権限は、図１８を参照してさらに議論される。ステップ１５０５において、プロビジョニングマネージャは、プリペイド請求検査を実行し、プリペイド請求がシステムに含まれる場合、図６に関連して説明されるように、加入者の貯金がアプリケーションのダウンロードに対する課金に十分であるかどうかを検査する。ステップ１５０６において、プロビジョニングマネージャは、デプロイメントマネージャのプロビジョニングインターフェイスを呼び出し、プロビジョンアプリケーションに戻る。
【０１０３】
図１６は、プロビジョニングマネージャの検査アプリケーションルーチンによって実行される処理の例となるフロー図である。（図１５におけるステップ１５０２を参照されたい。）まとめると、検査アプリケーションルーチンは、通信事業者が要求されるアプリケーションのダウンロード（グローバルに、または、加入者アイデンティティ、デバイス等の他の判断基準に基づいて対象を絞って）を禁じているかどうかを判断する。ステップ１６０１において、ルーチンは、通信事業者がダウンロードの許可を与えなかったアプリケーションのリストを要求し、取得する。このリストは、例えば、図６のＭＡＳクエリエンジン６５０を利用して、ローカルに取り出され、定期的に更新される。ステップ１６０２において、ルーチンは、要求されるリストから要求されるアプリケーションを検索して、アプリケーションが禁じられているかどうかを判断する。このことは、例えば、悪質なコードを含む、または、悪質なコードを含む疑いのあるアプリケーションのダウンロードを禁止するために、迅速で強固な方法を提供する。この方法は、（各デバイスが「ウイルスチェッカー」および悪質なアプリケーションデータファイルを取得する分割アプローチと比較して）中心に基づくアプローチを提供して、悪質なアプリケーションの拡大をストップさせる。ステップ１６０３において、このルーチンは、リクエストが禁止されたアプリケーションに対するものかどうかを判断し、そうであれば、ステップ１６０５に進み、そうでなければ、ステップ１６０４に進む。ステップ１６０４では、リクエストはログを取られ、ルーチンは成功した状態に戻る。ステップ１６０５では、失敗したリクエストがログを取られ、加入者に通知が送信され、ルーチンは失敗した状態に戻る。
【０１０４】
図１７は、プロビジョニングマネージャの検査加入者ルーチンによって実行される処理の例となるフロー図である。（図１５のステップ１５０３を参照されたい。）まとめると、検査加入者ルーチンは、プロフィールにおけるアドミニストレータコンポーネント（例えば、図５におけるアドミニストレータ５０９）によって格納され保存される際に、加入者プロフィールをコンテンツカテゴリーおよびサービスプラン定義と比較し、かつ、加入者が要求されるアプリケーションをダウンロードする権限が与えられているかを判断する。具体的には、ステップ１７０１において、ルーチンが、どの通信事業者からリクエストメッセージを受信したのかを判断する。ステップ１７０２において、ルーチンは、リクエストを送信した加入者を識別する。これは、例えば、ルーティング情報に対してリクエストメッセージを調べることによって、達成され得る。ステップ１７０３において、ルーチンは、加入者プロフィール情報が通信事業者に格納されている場合に、判断された通信事業者との接続を確立し、ステップ１７０４において、通信事業者から識別される加入者プロフィールを取り出す。当業者は、例えば、図５のローカルデータレポジトリ５１１にアクセスするために図６のプロフィールリーダー６５２コンポーネントを利用して、加入者のプロフィールが、ＭＡＳ上にローカルに格納され得、かつ、ＭＡＳから取り出され得ることを理解する。ステップ１７０５において、ルーチンはリクエストを調べて、どのアプリケーションが要求されたのかを判断する。ステップ１７０６において、ルーチンは、加入者のプロフィールが要求されるアプリケーションのダウンロードに対して権限を有するかを判断する。この判断は、例えば、加入者が所属する加入者グループのサービスプランを調べて、アプリケーションがそのサービスプランと関連するコンテンツカテゴリーに所属するかどうかを判断することによって、達成され得る。さらに、ルーチンは、加入者プロフィールに適合する禁じられたアプリケーションが存在するかをチェックし、適合が発見されれば、順番にリクエストを拒絶する。ステップ１７０７において、リクエストに権限が与えられていると判断される場合、ルーチンはステップ１７０８に進み、そうでなければ、ステップ１７０９に進む。ステップ１７０８において、リクエストはログを取られ、ルーチンは成功した状態に戻る。ステップ１７０９において、失敗したリクエストはログを取られ、加入者に通知が送信され、ルーチンは失敗状態に戻る。
【０１０５】
図１８は、プロビジョニングマネージャの検査デバイスルーチンによって実行される処理の例となるフロー図である。（図１５のステップ１５０４を参照されたい。）まとめると、検査デイバスルーチンは、加入者のデイバスと関連するデバイスプロフィールを、要求されるアプリケーションに対するアプリケーションプロフィールと比較し、かつ、アプリケーションによって要求されるリソースがデバイスプロフィールに従って利用可能であるかを検査する。ステップ１８０１において、ルーチンは、リクエストを受信した加入者デバイスのタイプを識別する。当業者は、この情報が、プロトコル交渉（ｎｅｇｏｔｉａｔｉｏｎ）において判断され、典型的には、リクエストメッセージに格納されるルーティング情報から抽出され得ることを理解する。ステップ１８０２において、ルーチンは、識別されたデバイスと関連するすでに格納されたデバイスプロフィールにアクセスすることによって、加入者デバイスの性能を判断する。１つの実施形態では、デバイスプロフィールは、図６のプロフィールリーダー６５２を利用して取り出される。デバイスプロフィールが識別されたデイバスに対して発見されなければ、そのイベントはログを取られ、システムアドミニストレータは、それに応じて通知される。（１つの実施形態では、加入者が、電話番号を取得するために通信事業者に登録する際に、通信事業者は、各加入者によって利用されるデバイスの特定の種類がわかる。通信事業者は、好ましくは全ての登録されるデバイスのタイプが、デイバスプロフィールでサポートされることを保証するべきである。）デバイスプロフィールは、メモリ容量、プロセッサタイプ、処理速度、ダウンロード可能なアプリケーションの最小サイズ等の加入者デイバスの性能と関連する情報を含む。ステップ１８０３において、ルーチンは、既にアドミニストレータコンポーネントによって生成されたように、要求されるアプリケーションと対応するアプリケーションプロフィールを取り出し、かつ、調べることによって、要求されるアプリケーションに対する要件を判断する。アプリケーションプロフィールは、必要とされるメモリの量、生成されるＡＰＩ呼び出し、および、最小限のプロセッサ速度などを含むアプリケーションを実行するための要件を含む。要件はまた、サポートされる加入者デバイスのタイプに応じて、アプリケーションプロフィールで指定され得る。ステップ１８０４において、デバイスの性能は、デバイスとアプリケーションプロフィールを比較することによって、要求されるアプリケーションの要件と比較される。ステップ１８０５において、ルーチンは、デイバスが要求されるアプリケーションを実行する能力があるかを判断し、あれば、ステップ１８０６に進み、なければ、ステップ１８０７に進む。ステップ１８０６において、リクエストはログを取られ、ルーチンは成功した状態に戻る。ステップ１８０７において、失敗したリクエストはログを取られ、加入者に通知が送信され、ルーチンは失敗した状態に戻る。
【０１０６】
図１９は、プロビジョニングマネージャの実行オープンプロビジョニングルーチンによって実行される処理の例となるフロー図である。（図１４のステップ１４０７を参照されたい。）ステップ１９０１および１９０２において、プロビジョニングマネージャは、既に利用可能であるか、または、キャッシュされたプロビジョンアプリケーションが存在するかどうかを決定する必要があり、あれば、ステップ１９０３に進み、なければ、ステップ１９０４に進む。このシナリオは、例えば、アプリケーションが、信頼されない、もしくは、未知の送信元からのものであってでさえ、以前に要求され、かつ、提供されたものである場合に、起こり得る。ステップ１９０３において、プロビジョンアプリケーションは戻される。もしくは、プロビジョンアプリケーションが発見されない場合、ステップ１９０４において、ルーチンは、リクエストメッセージ内に提供される指示されたＵＲＬを利用して、アプリケーションを取り出す。このアプリケーションは、ＭＡＳによって以前に処理された可能性があり、従って、既に対応するアプリケーションプロフィールを有し得る。従って、ステップ１９０５において、ルーチンは、対応するアプリケーションプロフィールが存在するかどうかを決定し、存在すれば、ステップ１９０７に進み、なければ、ステップ１９０６で新規のアプリケーションプロフィールを生成し、ステップ１９０７に進む。ステップ１９０７において、ルーチンは、アプリケーションプロフィールを加入者のリクエストのデバイスのタイプに対応するデイバスプロフィールと比較することによって、デイバス検査を実行する。ステップ１９０８において、ルーチンは、デプロイメントマネージャのプロビジョニングインターフェイスを呼び出し、信頼されないアプリケーションを提供し、ステップ１９０９においてプロビジョンアプリケーションへ戻る。
【０１０７】
図２０は、プロビジョニングマネージャの実行アプリケーションディスカバリルーチンによって実行される処理の例となるフロー図である。（図１４のステップ１４０９を参照されたい。）アプリケーションディスカバリには２つの基本タイプがある。加入者によって指定される判断基準と適合するアプリケーションの検索、および、格納された加入者の好みに基づくアプリケーションリストを提供されるシステムである。具体的には、ステップ２００１において、ルーチンは、ユーザが検索判断基準を指定しているかどうかを判断し、指定していれば、ステップ２００２に進み、指定していなければ、ステップ２００４に進む。ステップ２００２において、ルーチンは、アプリケーションストア（アプリケーションのデータレポジトリ）を検索し、指定された判断基準に適合するアプリケーション（コンテンツ）を照会する。例となる判断基準は、カテゴリー、金額、性別、年齢等を含む。ステップ２００３において、リストは、最初にこれらの照会結果に設定され、ステップ２００７に続く。ステップ２００４において、ルーチンは、利用可能なパーソナルアクセスリスト（「ＰＡＬ」）が存在するかどうかを判断し、あれば、ステップ２００５に進み、最初にリストを判断されたＰＡＬに設定し、そうでなければ、ステップ２００６に進み、最初にリストをディフォルト値に設定する。ステップ２００７において、ＭＡＳは、定義されたアプリケーションのセットを初期リストに追加する（スタートデックとして知られる）。スタートデックにより、本質的に、ＭＡＳは、例えば高収入の広告業者に対して、アプリケーションディスカバーセッションのスロットを予約することができる。ステップ２００８において、ルーチンは、図１７に関連して説明されたように、リスト上の各初期のアプリケーションに対して検査加入者ルーチンを呼び出す。フィルタリングするステップ２００８〜２００９の任意の１つを経ていない任意のアプリケーションは、そのプロセスにおける次のステップ前に、リストからフィルタリングされる。ステップ２００９において、ルーチンは、図１８を参照して説明されたように、リスト上の初期の各アプリケーションに対して、検査デイバスを呼び出す。ステップ２０１０において、ルーチンは、内部で標準化されたフォーマットに対するＸＭＬを生成し、ステップ２０１１において、このリストのコンテンツを加入者デイバスに対応する適切な言語に変換する。
【０１０８】
図２１は、加入者およびシステムアドミニストレータによるリクエストに応答してプロビジョンアプリケーションを提供するための、モバイルアプリケーションシステムのデプロイメントマネージャによって実行される処理の例となるフロー図である。（例えば、図５のデプロイメントマネージャ５０６を参照されたい。）システムアドミニストレータは、人気のあるデバイスに対する人気のあるアプリケーションが、加入者のリクエストに応答ために要求される時間を最小化するために、予め提供され（静的に提供され）、かつ、キャッシュされることを要求し得る。もしくは、全てのアプリケーションは、動的に提供され得、かつ、選択的にキャッシュされる。ステップ２１０１において、デプロイメントマネージャが初期化される。ステップ２１０２において、デプロイメントマネージャは、リクエストを評価して、要求されるアプリケーションのアイデンティティを判断する。ステップ２１０３において、デプロイメントマネージャは、図２２を参照してさらに説明されるように、獲得プロビジョンアプリケーションルーチンを呼び出し、コンテンツの取り出しを制御し、プロビジョニングを発生させる。ステップ２１０４において、デプロイメントマネージャは、プロビジョンアプリケーションの格納を開始するために、リクエストがシステムアドミニストレータによって生成されるかどうかを判断し、そうであれば、ステップ２１０５に進み、そうでなければ、ステップ２１０６に進む。ステップ２１０５において、デプロイメントマネージャは、キャッシュ、通信事業者のアプリケーションストア、または、リモートアプリケーションホストのサーバに、プロビジョンアプリケーションを格納し、処理を終了する。ステップ２１０６において、デプロイメントマネージャは、プロビジョンアプリケーションをプロビジョニングマネージャに送信し、その後、処理を終了する。
【０１０９】
図２２は、デプロイメントマネージャの獲得プロビジョンアプリケーションルーチンによって実行される処理の例となるフロー図である。（図２１のステップ２１０５を参照されたい。）まとめると、デプロイメントマネージャは、ＭＡＳにおいて実装される現在の規約に応じて、アプリケーションコードを取り出し、それを検査し、最適化し、および、備える。ステップ２２０１において、ルーチンは、インデックスのいくらかのタイプを調べて、プレプロビジョンバージョンのアプリケーションがＭＡＳに既知の位置に存在するかどうかを判断する。この情報が格納される態様は、どのようにキャッシュおよび／またはデータレポジトリが実装されるかに関係する。ローカルファストデータストアおよびインデックスを用いてキャッシュを実装するための周知の技術が、利用され得る。同一のプロビジョニング要件を必要とするアプリケーションに対して、大量のリクエストが生成されることが予期される場合に、アプリケーションは予め定義され、かつ、格納され得る。これは、例えば、同じ種類の加入者デイバスを有する大量のユーザが、同一のアプリケーションを要求する場合に、発生し得る。このような場合、アプリケーションは、キャッシュ内に提供され、かつ、格納され（かつ、アプリケーションが提供される加入者デバイスを有するユーザによってリクエストが生成される場合に取り出される）、あるいは、他のＭＡＳデータレポジトリに格納され得る。ステップ２２０２において、プレプロビジョンバージョンのアプリケーションが存在する場合、ルーチンはステップ２２０３に進み、そうでなければ、ステップ２２０７に進む。ステップ２２０３において、プレプロビジョンアプリケーションの位置が判断される。ステップ２２０４において、ルーチンは、プリプロビジョンアプリケーションがローカルに格納されているかどうかを判断し、そうであれば、ステップ２２０５に進み、そうでなければ、ステップ２２０６に進む。ステップ２２０５において、ルーチンは、アプリケーションをローカルに取り出し（典型的には、ＭＡＳ内、もしくは、通信事業者の敷地に配置され得る通信事業者のアプリケーションストアから）、そして戻る。ステップ２２０６において、ルーチンは、リモートアプリケーションホスト（例えば、第３者サーバ）からアプリケーションを取り出し、そして戻る。一方、ステップ２２０２において、ルーチンが、プレプロビジョンバージョンの要求されるアプリケーションが存在しないと判断する場合、ステップ２２０７において、ルーチンは、処理されていない提供されていないアプリケーションの位置を判断する。ステップ２２０８において、ルーチンは、アプリケーションコードがローカルに格納されているかどうかを判断し、そうであれば、ステップ２２０９に進み、そうでなければ、ステップ２２１０に進む。ステップ２２０９において、ルーチンは、通信事業者のアプリケーションストア、あるいは、他のローカルストレージからアプリケーションコードを取り出す。ステップ２２１０において、ルーチンは、リモートアプリケーションホストからアプリケーションコードを取り出す。ステップ２２１１において、ルーチンは、図２３に関連してさらに説明されたように、取り出されたアプリケーションを提供し、そして戻る。
【０１１０】
図２３は、デプロイメントマネージャのプロビジョンアプリケーションルーチンによって実行される処理の例となるフロー図である。ステップ２３０１において、プロビジョンアプリケーションルーチンは、図２４と関連してさらに説明されるアプリケーションを検査する。ステップ２３０２において、ルーチンは、図２５を参照してさらに説明されるようにアプリケーションを最適化する。ステップ２３０３において、ルーチンは、図２６に関連してさらに説明されるように、アプリケーションに計装をインストールする。ステップ２３０４において、ルーチンは、図２３に関連してさらに説明されるように、配送に適した形式でアプリケーションをパッケージ化し、そして戻る。
【０１１１】
図２４は、デプロイメントマネージャの検査アプリケーションルーチンによって実行される処理の例となるフロー図である。（例えば、図２３のステップ２３０１を参照されたい。）ステップ２４０１において、ルーチンは、パッケージ、クラス、メソッド、および、フィールド、あるいは、適切な他の構造を含むＡＰＩを識別することが必要とされる場合、アプリケーションの構造を解体／復号化する。アプリケーションがｊａｖａ（登録商標）でコード化される場合、検査はバイナリプログラムに対して実行され得、生成されるデバッキング／ロギング情報に対するアプリケーション自体に、ソースコードレベルチェックを挿入する必要はない。検査ステップのセットは、ステップ２４０１〜２４０５の例として説明される。しかしながら、当業者は、他の検査ステップは、本明細書中に説明されるものに追加もしくは代替として、適切に適用され得ることを理解する。ステップ２４０２において、ルーチンは、検査下にある潜在的なターゲットと関連のある任意のアプリケーションフィルタ（要求されるアプリケーション、要求している加入者、アプリケーションのコンテンツプロバイダ、および、グローバルフィルタ）を取り出す。１つの実施形態では、これらのフィルタは、ＭＡＳデータレポジトリに格納されるが、これらは任意の既知の位置に格納され得る。ステップ２４０３において、ルーチンは、解体されたコードを禁止されたデータ構造の格納された命令と比較することによって、取り出されたアプリケーションから、悪質であり、かつ、禁止されたコードを検査する。ステップ２４０４において、ルーチンは、コード内に存在するＡＰＩ呼び出しの数、タイプ、および、頻度を判断し、それらが、アプリケーションフィルタに格納され得るシステムアドミニストレーション要件と適合するかどうかをチェックする。ステップ２４０５において、ルーチンは、解体されたアプリケーションのフロー解析を実行し、実行されるスレッドの数が、システムアドミニストレータの要件内にあるかどうかを判断する。このフロー解析は、コードの方向性グラフ（ｄｉｒｅｃｔｉｏｎａｌ  ｇｒａｐｈ）を生成し、かつ、周知のグラフ解析アルゴリズムを適用する等の技術を利用して、達成され得る。当業者は、他のチェックが、取り出されたアプリケーション上で実行され得ることを理解する。ステップ２４０６において、ルーチンは、取り出されたアプリケーションが検査を経ているかどうかを判断し、経ていれば、成功状態に戻り、そうでなければ、ルーチンは失敗状態にフラグを立て、失敗状態に戻る。
【０１１２】
図２５は、デプロイメントマネージャの最適化アプリケーションルーチンによって実行される処理の例となるフロー図である。（例えば、図２３のステップ２３０２を参照されたい。）当業者は、任意の周知のコード最適化技術が、このルーチンに組み込まれ得、示されるものが例であることを理解する。ステップ２５０１において、ルーチンは、要求されるアプリケーションのファイルサイズを小さくするために、取り出されたアプリケーションに含まれる変数名を短くする。ステップ２５０２において、ルーチンは、取り出されたアプリケーションの実行可能なパスをマッピングする。ステップ２５０３において、ルーチンは、ファイルの長さを短くするために、任意の利用されていないコードを取り除き、同様の最適化ステップを続ける。最適化が終了すると、ルーチンは戻る。
【０１１３】
図２６は、デプロイメントマネージャのインストール計装ルーチンによって実行される処理の例となるフロー図である。（例えば、図２３のステップ２３０３を参照されたい。）ステップ２６０１において、ルーチンは、例えば、図６のプロフィールリーダー６５２を利用して、典型的にはローカルデータレポジトリから、識別された加入者プロフィールを取り出す。ステップ２６０２において、ルーチンは、要求されるアプリケーションを利用する際に、識別された加入者に対する通信事業者の規約を決定する。例えば、ある加入者は、予約中心または試行中心でアプリケーションを利用することを許可され得るが、他は許可されない。図７を参照して上述されたように、計装は、ある規約を実装する。例えば、プロビジョンコードを制限された回数または所与の期間で実行させることができるコードラッパーを、計装は提供することができる。ステップ２６０３において、ルーチンは、決定された通信事業者の規約に応じて、要求されるアプリケーションに計装をインストールし、その後、ルーチンは戻る。例示的な実施形態では、インストール計装ルーチンは、コード計装技術を利用し、バイナリコードレベルで、新しいコードを挿入する、もしくは、アプリケーション内の既存のコードを修正する。備えられるコードは、インストール計装ルーチンによって直接提供され得、もしくは、他のデータストレージ（例えば、異なる通信事業者規約と関連するデータストレージ）から取り出し可能であり得る。
【０１１４】
図２７は、デプロイメントマネージャのパッケージ化アプリケーションルーチンによって実行される処理の例となるフロー図である。（例えば、図２３のステップ２３０４を参照されたい。）ステップ２７０１において、ルーチンは、取り出された加入者デイバスプロフィールにアクセスして、識別された加入者デバイスに対して互換性のあるファイル形式かどうかを判断する。ステップ２７０２において、ルーチンは、加入者デバイスが圧縮ファイルを読むことができるかどうかを判断し、できれば、ステップ２７０３に進み、そうでなければ、ステップ２７０４に進む。ステップ２７０３において、ルーチンは、送信時間および送信されるバイト数を最小化するために、プロビジョンアプリケーションを圧縮する。ステップ２７０４において、ルーチンは、アプリケーションを抽出するワイヤレスデバイス上で実行するハンドセットアドミニストレーションコンソールを可能にするのに十分な情報を有するプロビジョンアプリケーションをカプセル化することによって、決定されたファイル形式を利用してアプリケーションをパッケージ化する。（例えば、図２のハンドセットアドミニストレーションコンソールを参照されたい。）上述したように、多くのＪａｖａ（登録商標）が有効なワイヤレスデバイスによって実行される１つの形式は、圧縮ＪＡＲファイルである。しかし、ある場合では、アプリケーションは、より小さなパケットでデバイスに分配される必要があり、それは、ワイヤレスデバイス上でのインストール作業に対して再組立てする。請求マネージャはまた、図２８を参照して以下で説明されるが、請求およびルーティング目的のための情報のカプセル化を当てにする。アプリケーションがパッケージ化された後、ルーチンは戻る。
【０１１５】
図２８は、モバイルアプリケーションシステムの請求マネージャによって実行される処理の例となるフロー図である。（例えば、図５の請求マネージャ５０７を参照されたい。）ステップ２８０１において、請求マネージャは初期化される。ステップ２８０２において、請求マネージャは、請求レポートを生成する時間があるかどうかを判断し、あれば、ステップ２８０３に進み、なければ、ステップ２８０４に進む。代替となる実施形態では、請求マネージャは、請求レポートを生成するために、例えばアドミニストレータコンポーネントからの管理上のクエリに応答し得る。ステップ２８０３において、請求マネージャは、システムアドミニストレータによるパラメターのセットに基づいた請求レポートを生成する。ステップ２８０４において、請求マネージャが、ログプロビジョニング情報（請求目的の）へのリクエストが存在するかどうかを判断し、あれば、ステップ２８０５に進み、なければ、戻る。ステップ２８０５において、請求マネージャは、請求（例えば、リクエストを生成するユーザのアイデンティティ、リクエストのカテゴリー、要求されたダウンロードのサイズ等）およびシステム変数（例えば、日付、日時等）の状態を関係付けるリクエストのパラメターのログを取り、未来の請求に対して利用する。例えば、アプリケーションの長さ、アプリケーションが要求された時間、アプリケーションを処理するのに必要な時間、および、アプリケーション数が、請求レポート生成する際に利用され得る。さらに、プリペイド請求がサポートされる場合、請求マネージャは、会計リクエストを通信事業者に対して生成し、加入者のプリペイド請求額を適切に減少させる。請求レポートが生成され、適切なパラメターのログが取られた後、請求マネージャは戻る。
【０１１６】
【表２】
2005509322.tif 000017
2005509322.tif 000018
2005509322.tif 000019
2005509322.tif 000020
2005509322.tif 000021
2005509322.tif 000022
2005509322.tif 000023
2005509322.tif 000024
2005509322.tif 000025
2005509322.tif 000026
2005509322.tif 000027
2005509322.tif 000028
2005509322.tif 000029
2005509322.tif 000030
2005509322.tif 000031
2005509322.tif 000032
2005509322.tif 000033
2005509322.tif 000034
2005509322.tif 000035
2005509322.tif 000036
2005509322.tif 000037
2005509322.tif 000038
2005509322.tif 000039
2005509322.tif 000040
2005509322.tif 000041
付録（ＡＰＰＥＮＤＩＸ）Ｅ
ワイヤレスアプリケーション環境におけるパケットレベル請求の方法およびシステム
本発明は、ワイヤレス環境のための方法およびシステムに関する。詳細には、本発明は、ワイヤレスアプリケーションのパケットレベルにおいて情報を請求するおよびロギングする方法およびシステムに関する。
【０１１７】
本発明の実施形態は、ワイヤレスアプリケーション環境でのパケットレベル（「パケットレベル請求システム」）で、パケットタイプの請求および他のタイプの統計収集およびロギングのためのコンピュータベースおよびネットワークベースの方法およびシステムを提供する。いくつかの例示的な実施形態は、付録Ａで詳細に説明される。付録Ａは、本明細書中でその全体が参照として援用される。放送時間がワイヤレスアプリケーションのための請求を決定するように用いられる統計のみではないように、請求情報を収集する、および、ロギングする際の使用のために、方法およびシステムが説明されるが、これらのメカニズムの任意が、他の時間および使用情報等の、統計情報の他のタイプをロギングするように用いられ得ることは、当業者が認識している。他の統計を用いることによって、請求サーバの規約をインプリメントするサーバ側のインプリメンテーションを提供する代わりに、データ収集規約の任意のタイプは、規格、ＡＰＩ、および／または、付録Ａ〜Ｅに記載される他のコードによってインプリメントされ得る。
【０１１８】
パケットレベル請求システムは、不便な態様で、または、不便ではない態様で、インプリメントされ得、これにより、パケットレベル請求の生成を含むように変更されるコードの一部で、および、パケットレベル請求生成コードが呼び出されることに気付くコードで、様々な柔軟性の度合いを可能にする。また、いくつかの方法は、ネットワークアプリケーション開発者に気付くことなく請求（または、任意の他のタイプのロギング情報）を集め、かつ、生成し得る。方法およびシステムは、「規格への書き込み」ソリューション、ライブラリソリューション、デバイスソフトウェア（ドライバ）修正ソリューションおよび計装ソリューションを含む。
【０１１９】
以上から、本発明の特定の実施形態は、例示するために本明細書中で説明されており、様々な修正が本発明の意図および範囲を逸脱することなくなされることは、当業者に認識されている。例えば、本明細書中で説明されている方法およびシステムが任意の種類のアプリケーションデータの収集および生成に適用可能であることは当業者に認識されている。本明細書中で説明された方法およびシステムが異なるプロトコル、通信メディア（光、ワイヤレス、ケーブル等）およびクライアントデバイス（例えば、ワイヤレスハンドセット、電子主催者、ポータブルｅメール機、ゲーム機、ページャ、ＧＰＳ受信器等のナビゲーションデバイス等）に適用可能であることは、当業者に認識されている。
付録  Ａ〜Ｅ
パケットレベルの請求
ワイヤレス環境におけるネットワークアプリケーション用
【０１２０】
【表３】
2005509322.tif 000042
極秘
（パケットレベルの請求  ページ１／１６）
目次
定義・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・３
非ネットワークアプリケーション・・・・・・・・・・・・・・・・・・・・・・３
ネットワークアプリケーション・・・・・・・・・・・・・・・・・・・・・・・３
サーバ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・３
クライアント・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・４
背景・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・５
要約・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・６
ネットワークアプリケーションのための４ｔｈｐａｓｓ請求ソリューション・・・・７
「仕様書にあわせて書く」ソリューション（侵入型）・・・・・・・・・・・・・・９
プロキシの保存および転送アプローチ・・・・・・・・・・・・・・・・・・・・９
ライブラリソリューション（侵入型）・・・・・・・・・・・・・・・・・・・・１０
プロキシの保存および転送アプローチ・・・・・・・・・・・・・・・・・・・１０
計算およびログアプローチ・・・・・・・・・・・・・・・・・・・・・・・・１１
デバイスソフトウェア修正ソリューション（非侵入型）・・・・・・・・・・・・１２
プロキシの保存および転送アプローチ・・・・・・・・・・・・・・・・・・・１２
計算およびログアプローチ・・・・・・・・・・・・・・・・・・・・・・・・１３
計装ソリューション（非侵入型）・・・・・・・・・・・・・・・・・・・・・・１３
ＤＮＳに基づくサーバ側インプリメンテーション・・・・・・・・・・・・・・・１４
異なるソリューションの比較・・・・・・・・・・・・・・・・・・・・・・・・１５
（パケットレベルの請求  ページ２／１６）
定義
アプリケーションタイプ
本文書の目的に沿って、ワイヤレスデバイス上で実行し得るアプリケーションは、２つのカテゴリーに分割される。
【０１２１】
非ネットワークアプリケーション
これらのタイプのアプリケーションは、動作時にネットワークを介して通信を行わない。これらのアプリケーションは、ネットワークに対して任意のデータを送信することも、ネットワークから任意のデータを受信することもない。
【０１２２】
例：アドレスブック、計算機、テキストエディター、等
ネットワークアプリケーション
これらのタイプのアプリケーションは、動作時にネットワーク上の他のアプリケーション／デバイス／サービスにアクセスするために、いくらかの種類のネットワーク通信を利用する。これらのアプリケーションは、ネットワーク上で、メッセージを送信／受信する。
【０１２３】
例：ブラウザ、ｅメールクライアント、チャットプログラム、カレンダー、等
サーバ
本文書の目的に沿って、サーバは、通常、クライアントに対して特定のデータまたはサービスを提供する（必ずしも、サーバハードウェアにマッピングしなくてもよい）ソフトウェアである。所与のサーバの機能は、サーバを識別するために使用される。例えば、（請求特定データを生成し、および／または、ログをとる）請求サーバ、（他のサーバとの通信においてプロキシとして動作する）プロキシサーバ等。
（パケットレベルの請求  ページ３／１６）
クライアント
本文書の目的に沿って、「クライアント」は、ワイヤレスデバイス上で実行されるネットワークアプリケーションを意味するように利用され、従来の「クライアント−サーバ」における意味でのサーバと通信する。
（パケットレベルの請求  ページ４／１６）
背景
典型的には、ワイヤレスデバイスユーザが通信時間を使用する際、または、ユーザがデバイスに対する任意のアプリケーションまたは任意の他のデータをダウンロードする際に、通信事業者の規約に応じて、ワイヤレスデバイスユーザは課金される。全ての現在のソリューションの系統は、通信時間およびデバイス上にダウンロードされたデータの総量に対してユーザに請求する手段を提供する。特定のアプリケーションが送信または受信するデータに基づくワイヤスデバイス上での特定のネットワークアプリケーションまたはアプリケーションの一部分の利用に対して、通信事業者が顧客に対して課金できるようにするためのソフトウェアレベルまたはハードウェアレベルで現在利用可能なソリューションはない。
（パケットレベルの請求  ページ５／１６）
要約
４ｔｈｐａｓｓは、データパケットレベル（すなわち、ワイヤレスデバイスによって送信および受信されるデータパケット）での特定のネットワークアプリケーションのデータの使用を決定するためのソリューションのセットを提案する。これらのソリューションにより、通信事業者は、送信および受信されたデータだけでなく該当のアプリケーションをも考慮する請求規約を明らかにすることができる。
【０１２４】
ネットワークアプリケーションは、ＴＣＰ／ＩＰおよびＵＤＰ／ＩＰのような下位レベルコミュニケーションプロトコルと、ＨＴＴＰおよびＷＡＰ（ワイヤレスアプリケーションプロトコル）のような上位レベルプロトコルとを利用することとを利用する。提案されるソリューションは、一般的なソリューションであり、任意の通信プロトコルに対して作用する。特定のソリューションのインプリメンテーションは、プロトコルに特有およびアプリケーション言語に特有である。
【０１２５】
本文書において提案される異なるソリューションは、（アプリケーションが常駐する）デバイスおよび（請求特定データが生成され、および／または、ログがとられる）請求サーバ上で、異なるタイプのサポートを必要とする。本文書は、通信時間請求規約の代替または追加として、送信／受信したデータに基づきユーザに課金し得るように、各アプリケーションに対するパケットレベルの情報を生成するという目的を達成するために、異なるソリューションをインプリメントする異なる方法について記載する。
【０１２６】
パケットレベルの請求を提供するための完全なソリューションは、クライアント側のソリューションおよびサーバ側のソリューションを含む。ソリューションに応じて、請求情報は、クライアントまたはサーバのどちらかによって生成される。請求サーバは、最終的に、それに基づいて請求記録が生成されるデータサイズ／データパケット情報を収集する。
（パケットレベルの請求  ページ６／１６）
ネットワークアプリケーションのための４ｔｈｐａｓｓ請求ソリューション
４ｔｈｐａｓｓは、デバイス上で動作中のアプリケーションが送信および受信したデータに応じて請求データを生成するために、以下のソリューションのカテゴリーを提案する。各ソリューションのカテゴリーは、ソリューションをインプリメントする異なる方法を提供する。
【０１２７】
１．「仕様書にあわせて書く」ソリューション：ネットワークアプリケーション開発者は、ネットワークアプリケーション開発者のコードを書くために、４ｔｈｐａｓｓによって提供される仕様書を利用する。仕様書は、パケットレベルで適切な請求情報を生成するために、コードのネットワーク通信部分をどのように書くべきかを指示する。
【０１２８】
２．ライブラリソリューション：ネットワークアプリケーション開発者は、アプリケーションを書くために、ソフトウェアライブラリの形式で４ｔｈｐａｓｓによって提供される、請求情報を生成するアプリケーションプログラミングインターフェイス（ＡＰＩ）の特定のセットを利用する。本ソリューションは、先のソリューションの拡張である。
【０１２９】
３．デバイスソフトウェア修正ソリューション：デバイス製造業者は、請求情報を生成するために、デイバス上のネットワーク機能ソフトウェア層を修正する。
【０１３０】
４．計装ソリューション：ソフトウェアは、アプリケーションがデバイス上にインストールされる前に、（アプリケーション機能を変更することなく）ユーザに見えないように請求情報を生成する請求ＡＰＩを利用するために、自動的にアプリケーションをスキャンして修正する。
【０１３１】
大まかに言うと、アプリケーション開発者が特定の方法でコードを書かなければならないのか、または、特定のツールを使わなくてはならないのかに応じて、本ソリューションをさらに２つのカテゴリーに分割することができる。
【０１３２】
１．侵入型（ｉｎｔｒｕｓｉｖｅ）：上述されたソリューションの最初の２つのカテゴリー、すなわち、「仕様書にあわせて書くソリューション」および「ライブラリソリューション」は、侵入型のソリューションである。アプリケーション開発者は、パケットレベルの請求情報を生成するために、特定の方法でコード化しなければならないか、または、特別のアプリケーションプログラミングインターフェイス（ＡＰＩ）を利用してコード化しなければならない。
（パケットレベルの請求  ページ７／１６）
２．非侵入型：上述された第３および第４のカテゴリー、すなわち、「デバイスソフトウェア修正ソリューション」および「計装ソリューション」は、非侵入型のソリューションである。開発者は、開発者のアプリケーションを書きながら、どんな特別なことも行う必要がない。代わりとして、４ｔｈｐａｓｓが提供するツールは、必要なパケットレベルの請求を自動的に生成する機能を備えている。
【０１３３】
全てのカテゴリー、すなわち、侵入型と非侵入型、良い点と悪い点、および、それらに特定のサーバ側のソリューションは、本文書中に詳細に記載される。次に、ソリューションの各カテゴリーは、必要とされる機能を達成するために様々なメカニズムを提案する。
（パケットレベルの請求  ページ８／１６）
「仕様書にあわせて書く」ソリューション（侵入型）
本ソリューションは、アプリケーションコードの書き方を記載することによって、４ｔｈｐａｓｓがアプリケーション開発者に対して詳細な仕様書を提供することを要求する。
【０１３４】
仕様書は、必要とされる請求情報を生成するためにどのようにアプリケーションコードを書くべきかについての情報を提供する。開発者は、請求情報が適切に生成されるような特定のガイドラインに合わせて、特定の形式および特定の順序でコードを書かなくてはならない。
【０１３５】
本仕様書にあわせて書く場合、以下のプロキシに基づくメカニズムが、請求情報を生成するために利用され得る。
【０１３６】
プロキシの保存および転送アプローチ
アプリケーションのためのコードは、所定のプロキシサーバと通信するように書かれる。データは、所定の形式（転送されるべき送信先情報およびデータを含む）でプロキシサーバへ送信される。プロキシサーバは、（公知の形式で保存された）所定のデータを読み、そのデータから送信先と正確に通信するために必要となる情報を抽出し、送信先へデータを転送する。
【０１３７】
送信先へ転送されたデータは、受信元としてプロキシサーバを表示し、従って、送信先から逆の通信を可能にする。送信先からデータを受信する際に、プロキシサーバは、元の送信者を判断し、かつ、元の送信者に受信したデータを転送する。
【０１３８】
データを前後させて転送する間に、送信されかつ受信されたデータサイズ／データパケット情報は、それらの情報が請求情報を生成する際に後で利用され得るように、例えば（さらに請求サーバとして動作する、または、請求サーバへその情報を転送する）プロキシサーバによってログを取られる。
（パケットレベルの請求  ページ９／１６）
【０１３９】
【表４】
2005509322.tif 000043
ライブラリソリューション（侵入型）
「ライブラリソリューション」は、「仕様書にあわせて書くソリューション」の拡張である。アプリケーション開発者に仕様書を提供するのではなく、開発者は、プロキシサーバ／請求サーバとユーザに見えないように相互通信するソフトウェアライブラリ、すなわち、所定のアプリケーションプログラミングインターフェイス（ＡＰＩ）のセットを提供される。開発者は、ＡＰＩを利用する際にまだ特定のガイドラインのセットに従わなくてはならないが、元にある仕様書は、ＡＰＩの手段に取得され、開発者は、仕様書をサポートするために広範囲に努力する必要がない。
【０１４０】
ライブラリソリューションは、異なるおよび／または複数のライブラリを提供することによって、２つの異なる種類のインプリメンテーションをサポートできるように利用することができる。
【０１４１】
プロキシの保存および転送アプローチ
アプリケーションのためのコードは、所定のＡＰＩのセットを利用して書かれる。本アプローチは、アプリケーション開発者に対して提供されるライブラリが、異なるＡＰＩを利用して（受信元および送信先の間の）プロキシサーバとの通信をインプリメントし、かつ、カプセル化すること以外は、「仕様書にあわせて書くソリューション」に記載されたアプローチと同じである。
【０１４２】
既存のＡＰＩにより、開発者は、複雑な仕様およびライブラリコードのインプリメンテーションを知らなくても、コードを開発することができるようになる。
（パケットレベルの請求  ページ１０／１６）
本アプローチでは、サーバが、請求情報を生成する（および、ログをとる）。
【０１４３】
【表５】
2005509322.tif 000044
計算およびログアプローチ
ライブラリメカニズムの別のインプリメンテーションは、ユーザに見えない請求情報のロギング／生成を提供する。本アプローチは、元のネットワークがデバイス間の直接の通信を許可する場合に、有用である。本インプリメンテーションでは、クライアントアプリケーションに対して飽和した双方向の通信量を扱うためにプロキシサーバを利用するのではなく、請求サーバは、請求データ（すなわち、パケットサイズ／パケットの数など）が送信されるのみであり、クライアントおよびサーバ間のアプリケーションデータの通常の通信が続く。
【０１４４】
具体的には、ライブラリＡＰＩは、請求（ロギング）コードのインプリメンテーションを隠蔽し、ここでは、「プロキシの保存および転送アプローチ」とは異なるように動作する。プロキシサーバに送信されるべきデータを受信する（および、次にプロキシサーバから戻ってくるデータを受信する）のではなく、アプリケーションにおいて実行するライブラリＡＰＩは、アプリケーションプログラムから見えないように、データサイズ／パケット数を判断し、請求サーバにこの情報を送信する。送信先デバイスまたは任意の外部サーバとの通信は、直接実行される。
（パケットレベルの請求  ページ１１／１６）
【０１４５】
【表６】
2005509322.tif 000045
デバイスソフトウェア修正ソリューション（非侵入型）
本アプローチは、パケットレベルの請求を提供するために、特定のデバイスのネットワーキングソフトウェアドライバ（ネットワーキング接続性を提供する義務のあるデバイス上のソフトウェア）の開発者４ｔｈｐａｓｓと一緒に仕事をすることを要求する。本アプローチを利用して、４ｔｈｐａｓｓは、ネットワーキングソフトウェアドライバと一体化される専用のソフトウェアの断片を提供する。専用のソフトウェアの断片は、プロキシアプローチまたは「計算およびログ」アプローチのどちらが取られるかに応じて、異なる機能を提供する。これらのアプローチは、ネットワークアプリケーション開発者がどんな特定の方法によってコードを書く必要も、どんな仕様に従う必要もないこと以外は、先の２つのセクションにおいて記載されたアプローチと同じである。代わりに、ネットワーキング通信ドライバコードは、請求特定機能を提供するための責任を負う。
【０１４６】
プロキシの保存および転送アプローチ
【０１４７】
【表７】
2005509322.tif 000046
（パケットレベルの請求  ページ１２／１６）
計算およびログアプローチ
【０１４８】
【表８】
2005509322.tif 000047
計装ソリューション（非侵入型）
計装ソリューションは、「ライブラリ」および「仕様書にあわせて書く」ソリューションをあわせたものである。本アプローチを利用して、アプリケーション開発者によってではないが、請求仕様書に書かれるＡＰＩが、ネットワークアプリケーションに付加される。
【０１４９】
具体的には、４ｔｈｐａｓｓは、ネットワークアプリケーションを読むことができ、適切なＡＰＩを含むようにバイナリイメージ（例えば、Ｊ２ＭＥにおけるバイトコード）を修正し得る、自動ソフトウェアツールを提供する。４ｔｈｐａｓｓソフトウェアツールは、既存のバイナリコード（例えば、Ｊ２ＭＥにおけるバイトコード形式）を付加、修正、または、消去することによって、進行中にバイナリイメージ（例えば、Ｊ２ＭＥにおけるバイトコード）を修正し得るインプリメンテーションをサポートする。
【０１５０】
従って、インプリメンテントされたコードを自動的に導入することによって、ネットワークプログラムは、任意の仕様を満たし、必要とされる請求ソリューションを提供することができる。
【０１５１】
先のセクションで議論された全てのサーバ側のインプリメンテーション（例えば、プロキシの保存および転送、ならびに、計算およびログ）を適用する。デバイス上にネットワークアプリケーションをインストールする直前に、ネットワークアプリケーションに、４ｔｈｐａｓｓバイナリスキャナおよび計装が実行される。
（パケットレベルの請求  ページ１３／１６）
スキャナは、利用されるネットワークＡＰＩを判断し、それらを自動的により新しいネットワーキングＡＰＩに置換する。新しいネットワーキングＡＰＩは、さらに請求特定情報を生成すること以外は元の機能と同じの機能を提供する。
【０１５２】
【表９】
2005509322.tif 000048
一旦、修正されたアプリケーションが実行されると（アプリケーション’）、アプリケーション’は、元のネットワーキングＡＰＩを利用するが、これらのＡＰＩは、適切な請求情報を生成する／ログをとる拡張された機能を提供する。
【０１５３】
上述の図では、アプリケーションは、以前の４ｔｈｐａｓｓで処理されたバージョンのネットワークアプリケーションを表わすが、アプリケーション’は、後の４ｔｈｐａｓｓで処理されたバージョンを表わす。サーバ側のサポートは、「プロキシの保存および転送」または「計算およびログ」アプローチと同じである（例えば、「ライブラリソリューション」のセクションで記載された図を参照されたい）。
サーバ側インプリメンテーションに基づくＤＮＳ
ある特定の場合におけるクライアントにおいてパケットレベルの請求をサポートするために、ソリューションに基づくＤＮＳは、サーバ上でインプリメントされる。本ソリューションは、外部ネットワーク（パブリックＩＰを利用したもの等）からのデバイスまたはプログラムを、発見され得ないプライベートＩＰを用いてネットワーク内部のデバイスにアクセスさせるのに役立つ。この方法では、（ネットワークアプリケーションへの）入来データパケットをカウントすることができ、アプリケーション請求情報をさらに生成することができる。
【０１５４】
外部ネットワークからのデバイスまたはプログラムは、全く異なるネットワーク上にあり、かつ、発見されないプライベートＩＰからのデータは、パブリックＩＰを利用してプログラムに送信され得ないので、本試みは、外部ネットワークからのデバイスまたはプログラムが内部デバイスと通信するための手段を提供することである。
（パケットレベルの請求  ページ１４／１６）
４ｔｈｐａｓｓソリューションにより、通信事業者側に専用のＤＮＳサーバインプリメンテーションを提供することによって、そのような通信が可能になる。通信事業者側は、パブリックＩＰのプール（単数または複数）とともに動作し、パブリックなＩＰは、内部ネットワークプライベートＩＰに対して動的にマッピングされる。ＤＮＳサーバは、ネットワークアドレストランスレーション（ＮＡＴ）を提供することによって、２つの終端の間の仮想通信リンクを管理する。
【０１５５】
さらなる情報を別の文書において入手することができ、本ソリューションをインプリメントする技術について記載する。
異なるソリューションの比較
異なるソリューションのそれぞれは、長所および短所を有する。仕様書に基づくソリューションは、ライブラリソフトウェアの配布を必要としないので、管理するのが比較的簡単であるが、一方では、仕様書は、ソフトウェアライブラリと比較すると、理解しかつ準拠するのがより難しい。ライブラリを利用すると、フードの下で何が起こっているのかを知らずに、ネットワークアプリケーション開発者はＡＰＩを呼び出す。
【０１５６】
これら両方を比較すると、同じ機能を提供されるようにネットワーキングソフトウェアドライバを修正することは、アプリケーション開発者の立場からして、インプリメントしかつ管理することが比較的簡単である。しかしながら、異なるデバイスを管理することがより難しくなり、ドライバ修正が別々にそれぞれに適用される必要がある。規模拡張性がありかつエラー耐久性のある方法における異なるＡＰＩに対するサポートは、維持するのが難しくなり得る。さらに、多数のネットワーキングデバイスドライバの作者に、４ｔｈｐａｓｓコードを含めるように納得させることも、困難であり得る。
【０１５７】
上述のアプローチを比較すると、計装アプローチが最も柔軟性があり、規模拡張性がある。計装アプローチは、前述のソリューションの柔軟性および利点を提供する。ＡＰＩのソフトウェアライブラリは、（それらをスキャンした後にネットワークアプリケーションに動的に付加される）仕様書にあわせて書かれ、かつ、ネットワークアプリケーション開発者は、どのようにそれらが書かれているかを理解する必要がない。また、開発者は、ライブラリＡＰＩが付加されるべきことを知る必要もない。代わりに、アプリケーション開発者によって既に書かれたアプリケーションをスキャンする際に、４ｔｈｐａｓｓツールは、ネットワークＡＰＩ（プロトコルに関わらず）の利用のためのアプリケーションを検査する。
（パケットレベルの請求  ページ１５／１６）
ネットワークＡＰＩの検知と同時に、４ｔｈｐａｓｓツールは、検知されたネットワークＡＰＩを様々な仕様書をインプリメントするＡＰＩの所定のセットに置換する。本ソリューションは、アプリケーション開発者の部品に、どんな発明も必要としない。さらに、（パブリックにされていてでさえも）インプリメンテーションは開発者から隠蔽されているので、インプリメンテーションの管理は比較的容易である。さらに、古いソリューションが配置されているときであってさえ、インプリメンテーションは変更かつ拡張し得るので、最適のソリューションをインプリメントすることを可能にする。最後に、自動ステップは一般的に手動ステップに比べてエラー傾向が低いので、最低ではないが、エラー傾向が低い。
（パケットレベルの請求  ページ１６／１６）
【図面の簡単な説明】
【０１５８】
【図１】図１は、例示的な送信に基づく請求システムの概略的ブロック図である。
【図２】図２は、パケットベースの請求システムのコンテンツ（コード）モディファイアによって実行された場合の請求トラッキングコードと共に備えられたコンテンツの例示的ブロック図である。
【図３】図３は、例示的なモバイルアプリケーションシステム内にインプリメントされた例示的な送信に基づく請求システムのブロック図である。
【図４】図４は、送信に基づく請求システムの実施形態を実行するための汎用コンピュータシステムおよびクライアントデバイスの例示的ブロック図である。
【図５】図５は、送信に基づく請求と共に使用するためのモバイルアプリケーションシステムにアプリケーションを転送するための例示的な手順のブロック図である。
【図６】図６は、モバイルアプリケーションシステムを用いて、送信に基づく請求を支援するアプリケーションをクライアントデバイスに認識されないように配信するための全体のプロセスを示す例示的ブロック図である。
【図７】図７は、送信に基づく請求を支援するためにアプリケーションを修正するためのルーチンの例示的なフローチャートである。
【図８】図８は、送信に基づく請求のための支援によってアプリケーションを解析およびこれを具備するためのルーチンの例示的なフローチャートである。
【図９】図９は、アプリケーション毎を基礎としてネットワーク送信データに基づいた請求データと通信するための全体のプロセスを示す例示的なブロック図である。
【図１０】図１０は、請求データを収集かつ送信するために修正されたデータをネットワークに転送するためのクライアントルーチンの例示的なフローチャートである。
【図１１】図１１は、請求データを収集かつ送信するために修正されたデータをネットワークから受信するためのクライアントルーチンの例示的なフローチャートである。
【図１２】図１２は、転送された送信に基づく請求データを処理するためのサーバルーチンの例示的なフローチャートである。
【図１３】図１３は、送信に基づく請求データに基づいて請求料金を生成するためのステップの例示的なフローチャートである。
【図１】
2005509322.tif 000049
【図２】
2005509322.tif 000050
【図３】
2005509322.tif 000051
【図４】
2005509322.tif 000052
【図５】
2005509322.tif 000053
【図６】
2005509322.tif 000054
【図７】
2005509322.tif 000055
【図８】
2005509322.tif 000056
【図９】
2005509322.tif 000057
【図１０】
2005509322.tif 000058
【図１１】
2005509322.tif 000059
【図１２】
2005509322.tif 000060
【図１３】
2005509322.tif 000061
【手続補正書】
【提出日】平成15年10月29日(2003.10.29)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】０１１７
【補正方法】変更
【補正の内容】
【０１１７】
本発明の実施形態は、ワイヤレスアプリケーション環境でのパケットレベル（「パケットレベル請求システム」）で、パケットタイプの請求および他のタイプの統計収集およびロギングのためのコンピュータベースおよびネットワークベースの方法およびシステムを提供する。いくつかの例示的な実施形態は、付録Ａで詳細に説明される。付録Ａは、本明細書中でその全体が参照として援用される。放送時間がワイヤレスアプリケーションのための請求を決定するように用いられる統計のみではないように、請求情報を収集する、および、ロギングする際の使用のために、方法およびシステムが説明されるが、これらのメカニズムの任意が、他の時間および使用情報等の、統計情報の他のタイプをロギングするように用いられ得ることは、当業者が認識している。他の統計を用いることによって、請求サーバの規約をインプリメントするサーバ側のインプリメンテーションを提供する代わりに、データ収集規約の任意のタイプは、規格、ＡＰＩ、および／または、付録Ｘに記載される他のコードによってインプリメントされ得る。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０１１９
【補正方法】変更
【補正の内容】
【０１１９】
以上から、本発明の特定の実施形態は、例示するために本明細書中で説明されており、様々な修正が本発明の意図および範囲を逸脱することなくなされることは、当業者に認識されている。例えば、本明細書中で説明されている方法およびシステムが任意の種類のアプリケーションデータの収集および生成に適用可能であることは当業者に認識されている。本明細書中で説明された方法およびシステムが異なるプロトコル、通信メディア（光、ワイヤレス、ケーブル等）およびクライアントデバイス（例えば、ワイヤレスハンドセット、電子主催者、ポータブルｅメール機、ゲーム機、ページャ、ＧＰＳ受信器等のナビゲーションデバイス等）に適用可能であることは、当業者に認識されている。
付録  Ｘ
パケットレベルの請求
ワイヤレス環境におけるネットワークアプリケーション用
【国際調査報告】
2005509322.tif 000062
2005509322.tif 000063
2005509322.tif 000064