JP6526082B2 - ワイヤレスネットワークにおいて移動局セッションを別の移動局によって資金援助すること - Google Patents

Description

ワイヤレスネットワークにおいて移動局セッションを別の移動局によって資金援助することに関する。

関連出願の相互参照
本出願は、２０１２年１１月１５日に出願された米国特許仮出願第６１／７２６，９１９号明細書、および２０１２年３月２１日に出願された米国特許仮出願第６１／６１３，６９３号明細書の利益を主張するものであり、それらの内容は、参照によって本明細書に組み込まれている。

アプリケーションプロバイダと第３世代パートナーシッププロジェクト（３ＧＰＰ）ネットワークオペレータコアネットワーク（ＣＮ：core network）との間における相互作用をサポートすることが望ましい。アプリケーションとモバイルネットワークとの間における緊密な統合は、エンドユーザへの課金および請求書送付を効率よく行うことによって実施されることが可能である。たとえば、アプリケーション課金は、モバイルネットワークオペレータ（ＭＮＯ：mobile network operator）によってエンドユーザへ送付される請求書と統合されることが可能である。現在、ユーザがアプリケーションサービスに関して別のユーザを資金援助することを可能にするためのメカニズムはない。

ワイヤレス送信／受信ユニット（ＷＴＲＵ）による、資金援助サービス（sponsoring service）および優先トラフィック処理（preferential traffic handling）（すなわち、データ接続）のための装置および方法が説明される。第１のＷＴＲＵが、アプリケーションサーバ（ＡＳ：application server）を介して第２のＷＴＲＵのアイデンティティーを得て、第２のＷＴＲＵのユーザ資金援助を開始することができる。第１のＷＴＲＵは、ＡＳからサービストリガーを受信して、サービストリガーを第２のＷＴＲＵへ転送することができる。次いで第２のＷＴＲＵは、ＡＳからのサービスを受信するために、サービストリガーを使用して、ＡＳとの間での資金援助されるセッションを開始することができる。第１のＷＴＲＵは、クレジットを第２のＷＴＲＵへ転送するようＡＳに要求することもできる。ＡＳは、オンライン課金機能（ＯＣＦ：online charging function）と課金データ機能（ＣＤＦ：charging data function）を含む課金システムとの間で直接通信リンクを確立することができる。ＡＳは、第２のＷＴＲＵへコンテンツを配信するために必要とされる優先トラフィック処理を提供する要求をネットワークへ送信することができる。

以降の説明から、より詳細な理解が得られることが可能であり、以降の説明は、例として添付の図面とともに与えられている。

１または複数の開示されている実施形態が実施されることが可能である例示的な通信システムを示す図である。 図１Ａに示されている通信システム内で使用されることが可能である例示的なワイヤレス送信／受信ユニット（ＷＴＲＵ）を示す図である。 図１Ａに示されている通信システム内で使用されることが可能である例示的な無線アクセスネットワークおよび例示的なコアネットワーク（ＣＮ）を示す図である。 課金ノードと相互接続されているアプリケーションサーバ（ＡＳ）を含むネットワークアーキテクチャーを示す図である。 アプリケーションサーバ（ＡＳ）がモバイルネットワークオペレータ（ＭＮＯ）によって所有され展開されることが可能であるユーザ資金援助手順のメッセージフロー図である。 アプリケーションサーバ（ＡＳ）がモバイルネットワークオペレータ（ＭＮＯ）によって所有され展開されることが可能であるユーザ資金援助手順のメッセージフロー図である。 資金援助要求手順のメッセージフロー図である。 資金援助要求手順のメッセージフロー図である。 被資金援助セッション開始のための手順のメッセージフロー図である。 被資金援助セッション開始のための手順のメッセージフロー図である。 アプリケーションサービスプロバイダがアクセスプロバイダネットワークとの間での契約を確立することができるアーキテクチャーコンテキストを示す図である。 ユーザベースの資金援助を実施する手順のハイレベルメッセージフロー図である。 ユーザベースの資金援助を実施する手順のハイレベルメッセージフロー図である。 アプリケーションプロバイダが別のＷＴＲＵの代わりにＷＴＲＵサービスを資金援助するための手順のハイレベルメッセージフロー図である。 アプリケーションプロバイダが別のＷＴＲＵの代わりにＷＴＲＵサービスを資金援助するための手順のハイレベルメッセージフロー図である。 課金イベントがサードパーティーＡＳによって第３世代パートナーシッププロジェクト（３ＧＰＰ）コアネットワーク（ＣＮ）へ送信されることを可能にすることのアーキテクチャー図である。 課金イベントがサードパーティーＡＳによって第３世代パートナーシッププロジェクト（３ＧＰＰ）コアネットワーク（ＣＮ）へ送信されることを可能にすることのアーキテクチャー図である。 課金イベントがサードパーティーＡＳによって第３世代パートナーシッププロジェクト（３ＧＰＰ）コアネットワーク（ＣＮ）へ送信されることを可能にすることのアーキテクチャー図である。 ユーザ資金援助のための手順のハイレベルメッセージフロー図である。 ユーザ資金援助のための手順のハイレベルメッセージフロー図である。 ２つの異なるＷＴＲＵのユーザが第１のＭＮＯにサブスクライブしているが、それらのＷＴＲＵのうちの１つは、第１のＭＮＯへのサブスクライバーに追加コストで優先トラフィック処理を提供する第２のＭＮＯにおいてローミングしている、ホームに回送されるネットワークアーキテクチャーを示す図である。 １つのＷＴＲＵのユーザが、別のＷＴＲＵのユーザのためのアプリケーションサービスおよび／または優先トラフィック処理を資金援助するローカルブレイクアウトローミングネットワークアーキテクチャーを示す図である。 同じＭＮＯおよびローミングを伴うローカルブレイクアウトコラボレーティブケースに関する手順のハイレベルメッセージフロー図である。 同じＭＮＯおよびローミングを伴うローカルブレイクアウトコラボレーティブケースに関する手順のハイレベルメッセージフロー図である。 同じＭＮＯおよびローミングを伴う、ホームに回送されるコラボレーティブケースに関する手順のハイレベルメッセージフロー図である。 同じＭＮＯおよびローミングを伴う、ホームに回送されるコラボレーティブケースに関する手順のハイレベルメッセージフロー図である。 別々のＭＮＯを伴う非ローミングコラボレーティブケースに関する手順のハイレベルメッセージフロー図である。 別々のＭＮＯを伴う非ローミングコラボレーティブケースに関する手順のハイレベルメッセージフロー図である。 別々のＭＮＯを伴うローミングコラボレーティブケースに関する手順のハイレベルメッセージフロー図である。 別々のＭＮＯを伴うローミングコラボレーティブケースに関する手順のハイレベルメッセージフロー図である。 ビジネス契約がなく、同じＭＮＯを関与させる、コラボレーティブでない状況に関する手順のハイレベルメッセージフロー図である。 ビジネス契約がなく、異なるＭＮＯを関与させる、コラボレーティブでない状況に関する手順のハイレベルメッセージフロー図である。 課金メッセージが、資金援助されるイベントの受領者を識別するために使用される情報要素（ＩＥ：information element）を含むように強化されている手順のハイレベルメッセージフロー図である。 ＷＴＲＵユーザ同士の間においてクレジットを転送するための手順のハイレベルメッセージフロー図である。 ＷＴＲＵユーザ同士の間においてクレジットを転送するための手順のハイレベルメッセージフロー図である。

図１Ａは、１または複数の開示されている実施形態が実施されることが可能である例示的な通信システム１００を示している。通信システム１００は、コンテンツ、たとえば音声、データ、ビデオ、メッセージング、放送などを複数のワイヤレスユーザに提供するマルチプルアクセスシステムであることが可能である。通信システム１００は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含むシステムリソースの共有を通じてそのようなコンテンツにアクセスすることを可能にすることができる。たとえば、通信システム１００は、１または複数のチャネルアクセス方法、たとえば符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などを採用することができる。

図１Ａに示されているように、通信システム１００は、ワイヤレス送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク（ＣＮ）１０６、公衆交換電話網（ＰＳＴＮ：public switched telephone network）１０８、インターネット１１０、およびその他のネットワーク１１２を含むことができるが、開示されている実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を想定していることが理解されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、ワイヤレス環境において動作および／または通信を行うように構成されている任意のタイプのデバイスであることが可能である。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス信号を送信および／または受信するように構成されることが可能であり、ユーザ機器（ＵＥ）、移動局、固定式または移動式のサブスクライバーユニット、ページャー、セルラー電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、家庭用電化製品などを含むことができる。

通信システム１００は、基地局１１４ａおよび基地局１１４ｂを含むこともできる。基地局１１４ａ、１１４ｂのそれぞれは、ＣＮ１０６、インターネット１１０、および／またはその他のネットワーク１１２などの１または複数の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つとワイヤレスにインターフェースを取るように構成されている任意のタイプのデバイスであることが可能である。例として、基地局１１４ａ、１１４ｂは、ベーストランシーバステーション（ＢＴＳ）、Ｎｏｄｅ−Ｂ、エボルブドＮｏｄｅ−Ｂ（ｅＮＢ）、ホームＮｏｄｅ−Ｂ（ＨＮＢ）、ホームｅＮＢ（ＨｅＮＢ）、サイトコントローラ、アクセスポイント（ＡＰ）、ワイヤレスルータなどであることが可能である。基地局１１４ａ、１１４ｂは、それぞれ単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことができることが理解されるであろう。

基地局１１４ａは、ＲＡＮ１０４の一部であることが可能であり、ＲＡＮ１０４は、その他の基地局および／またはネットワーク要素（図示せず）、たとえば基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどを含むこともできる。基地局１１４ａおよび／または基地局１１４ｂは、特定の地理的領域内でワイヤレス信号を送信および／または受信するように構成されることが可能であり、その地理的領域は、セル（図示せず）と呼ばれることもある。セルは、セルセクタにさらに分割されることが可能である。たとえば、基地局１１４ａに関連付けられているセルは、３つのセクタに分割されることが可能である。したがって一実施形態においては、基地局１１４ａは、３つのトランシーバ、すなわち、セルのそれぞれのセクタごとに１つのトランシーバを含むことができる。別の実施形態においては、基地局１１４ａは、多入力多出力（ＭＩＭＯ：multiple-input multiple -output）技術を採用することができ、したがって、セルのそれぞれのセクタごとに複数のトランシーバを利用することができる。

基地局１１４ａ、１１４ｂは、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１または複数と通信することができ、エアインターフェース１１６は、任意の適切なワイヤレス通信リンク（たとえば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）であることが可能である。エアインターフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されることが可能である。

より具体的には、上述したように、通信システム１００は、マルチプルアクセスシステムであることが可能であり、１または複数のチャネルアクセススキーム、たとえばＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどを採用することができる。たとえば、ＲＡＮ１０４内の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実施することができ、この無線技術は、ワイドバンドＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインターフェース１１６を確立することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／またはエボルブドＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含むことができる。ＨＳＰＡは、ハイスピードダウンリンクパケットアクセス（ＨＳＤＰＡ）および／またはハイスピードアップリンクパケットアクセス（ＨＳＵＰＡ）を含むことができる。

別の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、エボルブドＵＴＲＡ（Ｅ−ＵＴＲＡ）などの無線技術を実施することができ、この無線技術は、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインターフェース１１６を確立することができる。

その他の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、無線技術、たとえばＩＥＥＥ（登録商標） ８０２．１６（すなわちＷｉＭＡＸ（worldwide interoperability for microwave access））、ＣＤＭＡ２０００（登録商標）、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ＥＶ−ＤＯ（CDMA2000 evolution- data optimized）、ＩＳ−２０００（Interim Standard 2000）、ＩＳ−９５（Interim Standard 95）、ＩＳ−８５６（Interim Standard 856）、ＧＳＭ（登録商標）（global system for mobile communications）、ＥＤＧＥ（enhanced data rates for GSM evolution）、ＧＳＭ／ＥＤＧＥ ＲＡＮ（ＧＥＲＡＮ）などを実施することができる。

図１Ａにおける基地局１１４ｂは、たとえばワイヤレスルータ、ＨＮＢ、ＨｅＮＢ、またはＡＰであることが可能であり、局所的なエリア、たとえば事業所、家庭、乗り物、キャンパスなどにおけるワイヤレス接続を容易にするために、任意の適切なＲＡＴを利用することができる。一実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を確立するために、ＩＥＥＥ ８０２．１１などの無線技術を実施することができる。別の実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を確立するために、ＩＥＥＥ ８０２．１５などの無線技術を実施することができる。さらに別の実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ピコセルまたはフェムトセルを確立するために、セルラーベースのＲＡＴ（たとえば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用することができる。図１Ａに示されているように、基地局１１４ｂは、インターネット１１０への直接接続を有することができる。したがって、基地局１１４ｂは、ＣＮ１０６を介してインターネット１１０にアクセスすることを求められないことが可能である。

ＲＡＮ１０４は、ＣＮ１０６と通信状態にあることが可能であり、ＣＮ１０６は、音声、データ、アプリケーション、および／またはボイスオーバーインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１または複数に提供するように構成されている任意のタイプのネットワークであることが可能である。たとえば、ＣＮ１０６は、コール制御、料金請求サービス、モバイルロケーションベースサービス、プリペイドコーリング、インターネット接続、ビデオ配信などを提供すること、および／またはユーザ認証などのハイレベルセキュリティー機能を実行することが可能である。図１Ａに示されていないが、ＲＡＮ１０４および／またはＣＮ１０６は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用しているその他のＲＡＮと直接または間接の通信状態にあることが可能であることが理解されるであろう。たとえば、ＣＮ１０６は、Ｅ−ＵＴＲＡ無線技術を利用している可能性があるＲＡＮ１０４に接続されていることに加えて、ＧＳＭ無線技術を採用している別のＲＡＮ（図示せず）と通信状態にあることも可能である。

ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／またはその他のネットワーク１１２にアクセスするためのゲートウェイとして機能することもできる。ＰＳＴＮ１０８は、単純旧式電話サービス（ＰＯＴＳ）を提供する回線交換電話ネットワークを含むことができる。インターネット１１０は、ＴＣＰ／ＩＰスイートにおけるトランスミッションコントロールプロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスからなるグローバルシステムを含むことができる。ネットワーク１１２は、その他のサービスプロバイダによって所有および／または運営されている有線またはワイヤレスの通信ネットワークを含むことができる。たとえば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用している可能性がある１または複数のＲＡＮに接続されている別のＣＮを含むことができる。

通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちのいくつかまたはすべては、マルチモード機能を含むことができ、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、別々のワイヤレスリンクを介して別々のワイヤレスネットワークと通信するために複数のトランシーバを含むことができる。たとえば、図１Ａに示されているＷＴＲＵ１０２ｃは、セルラーベースの無線技術を採用している可能性がある基地局１１４ａ、およびＩＥＥＥ ８０２無線技術を採用している可能性がある基地局１１４ｂと通信するように構成されることが可能である。

図１Ｂは、図１Ａに示されている通信システム１００内で使用されることが可能である例示的なＷＴＲＵ１０２を示している。図１Ｂに示されているように、ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送信／受信要素（たとえば、アンテナ）１２２、スピーカー／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、取り外し不能メモリ１３０、取り外し可能メモリ１３２、電源１３４、グローバルポジショニングシステム（ＧＰＳ）チップセット１３６、およびその他の周辺機器１３８を含むことができる。ＷＴＲＵ１０２は、一実施形態との整合性を保持しながら、上述の要素同士の任意の下位組合せを含むことができることが理解されるであろう。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、マイクロプロセッサ、ＤＳＰコアと関連付けられている１もしくは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、集積回路（ＩＣ）、状態マシンなどであることが可能である。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、および／または、ＷＴＲＵ１０２がワイヤレス環境において機能することを可能にするその他の任意の機能を実行することができる。プロセッサ１１８は、トランシーバ１２０に接続されることが可能であり、トランシーバ１２０は、送信／受信要素１２２に接続されることが可能である。図１Ｂは、プロセッサ１１８とトランシーバ１２０を別々の構成要素として示しているが、プロセッサ１１８とトランシーバ１２０は、電子パッケージまたはチップ内に統合されることが可能である。

送信／受信要素１２２は、エアインターフェース１１６を介して、基地局（たとえば、基地局１１４ａ）に信号を送信するように、または基地局（たとえば、基地局１１４ａ）から信号を受信するように構成されることが可能である。たとえば、一実施形態においては、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されているアンテナであることが可能である。別の実施形態においては、送信／受信要素１２２は、たとえば、ＩＲ信号、ＵＶ信号、または可視光信号を送信および／または受信するように構成されているエミッタ／検知器であることが可能である。さらに別の実施形態においては、送信／受信要素１２２は、ＲＦ信号および光信号の両方を送信および受信するように構成されることが可能である。送信／受信要素１２２は、ワイヤレス信号の任意の組合せを送信および／または受信するように構成されることが可能である。

加えて、送信／受信要素１２２は、図１Ｂにおいては単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含むことができる。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用することができる。したがって、一実施形態においては、ＷＴＲＵ１０２は、エアインターフェース１１６を介してワイヤレス信号を送信および受信するために、複数の送信／受信要素１２２（たとえば、複数のアンテナ）を含むことができる。

トランシーバ１２０は、送信／受信要素１２２によって送信されることになる信号を変調するように、また、送信／受信要素１２２によって受信される信号を復調するように構成されることが可能である。上述したように、ＷＴＲＵ１０２は、マルチモード機能を有することができる。したがってトランシーバ１２０は、ＷＴＲＵ１０２が、たとえばＵＴＲＡおよびＩＥＥＥ ８０２．１１など、複数のＲＡＴを介して通信することを可能にするために複数のトランシーバを含むことができる。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカー／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（たとえば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットもしくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に接続されることが可能であり、そこからユーザ入力データを受け取ることができる。プロセッサ１１８は、ユーザデータをスピーカー／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８へ出力することもできる。加えて、プロセッサ１１８は、取り外し不能メモリ１３０および／または取り外し可能メモリ１３２など、任意のタイプの適切なメモリからの情報にアクセスすること、およびそれらのメモリにデータを格納することが可能である。取り外し不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、またはその他の任意のタイプのメモリストレージデバイスを含むことができる。取り外し可能メモリ１３２は、サブスクライバーアイデンティティーモジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含むことができる。その他の実施形態においては、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上など、ＷＴＲＵ１０２上に物理的に配置されていないメモリからの情報にアクセスすること、およびそのメモリにデータを格納することが可能である。

プロセッサ１１８は、電源１３４から電力を受け取ることができ、また、ＷＴＲＵ１０２内のその他の構成要素への電力を分配および／または制御するように構成されることが可能である。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の適切なデバイスであることが可能である。たとえば、電源１３４は、１または複数の乾電池（たとえば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などを含むことができる。

プロセッサ１１８は、ＧＰＳチップセット１３６に接続されることも可能であり、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（たとえば、経度および緯度）を提供するように構成されることが可能である。ＷＴＲＵ１０２は、ＧＰＳチップセット１３６からの情報に加えて、またはその情報の代わりに、基地局（たとえば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１６を介して位置情報を受信すること、および／または複数の近隣の基地局から受信されている信号のタイミングに基づいて自分の位置を特定することが可能である。ＷＴＲＵ１０２は、一実施形態との整合性を保持しながら、任意の適切な位置特定方法を通じて位置情報を得ることができる。

プロセッサ１１８は、その他の周辺機器１３８にさらに接続されることが可能であり、その他の周辺機器１３８は、さらなる特徴、機能、および／または有線接続もしくはワイヤレス接続を提供する１または複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含むことができる。たとえば、周辺機器１３８は、加速度計、ｅ−コンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビジョントランシーバ、ハンドフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタルミュージックプレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含むことができる。

図１Ｃは、図１Ａに示されている通信システム１００内で使用されることが可能である例示的なＲＡＮ１０４および例示的なＣＮ１０６を示している。上述したように、ＲＡＮ１０４は、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ−ＵＴＲＡ無線技術を採用することができる。ＲＡＮ１０４は、ＣＮ１０６と通信状態にあることも可能である。

ＲＡＮ１０４は、ｅＮＢ１４０ａ、１４０ｂ、１４０ｃを含むことができるが、ＲＡＮ１０４は、一実施形態との整合性を保持しながら、任意の数のｅＮＢを含むことができることが理解されるであろう。ｅＮＢ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために１または複数のトランシーバを含むことができる。一実施形態においては、ｅＮＢ１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実施することができる。したがって、ｅＮＢ１４０ａは、たとえば、ＷＴＲＵ１０２ａにワイヤレス信号を送信するために、およびＷＴＲＵ１０２ａからワイヤレス信号を受信するために、複数のアンテナを使用することができる。

ｅＮＢ１４０ａ、１４０ｂ、１４０ｃのそれぞれは、特定のセル（図示せず）に関連付けられることが可能であり、無線リソース管理決定、ハンドオーバ決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを取り扱うように構成されることが可能である。図１Ｃに示されているように、ｅＮＢ１４０ａ、１４０ｂ、１４０ｃは、Ｘ２インターフェースを介して互いに通信することができる。

図１Ｃに示されているＣＮ１０６は、モビリティーマネージメントエンティティー（ＭＭＥ）１４２、サービングゲートウェイ１４４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１４６を含むことができる。上述の要素のうちのそれぞれは、ＣＮ１０６の一部として示されているが、これらの要素のいずれかが、ＣＮオペレータ以外のエンティティーによって所有および／または運営されることも可能であることが理解されるであろう。

ＭＭＥ１４２は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮＢ１４０ａ、１４０ｂ、１４０ｃのそれぞれに接続されることが可能であり、コントロールノードとして機能することができる。たとえば、ＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの最初の接続中に特定のサービングゲートウェイを選択することなどを担当することができる。ＭＭＥ１４２は、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどのその他の無線技術を採用しているその他のＲＡＮ（図示せず）との間における切り替えを行うためのコントロールプレーン機能を提供することもできる。

サービングゲートウェイ１４４は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮＢ１４０ａ、１４０ｂ、１４０ｃのそれぞれに接続されることが可能である。サービングゲートウェイ１４４は一般に、ユーザデータパケットをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへ／ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃから回送および転送することができる。サービングゲートウェイ１４４は、その他の機能、たとえば、ｅＮＢ間でのハンドオーバ中にユーザプレーンを固定すること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにとってダウンリンクデータが利用可能である場合にページングをトリガーすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなどを実行することもできる。

サービングゲートウェイ１４４は、ＰＤＮゲートウェイ１４６に接続されることも可能であり、ＰＤＮゲートウェイ１４６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応デバイスとの間における通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。

ＣＮ１０６は、その他のネットワークとの通信を容易にすることができる。たとえば、ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の地上通信線通信デバイスとの間における通信を容易にするために、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。たとえば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間におけるインターフェースとして機能するＩＰゲートウェイ（たとえば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができ、またはそうしたＩＰゲートウェイと通信することができる。加えて、ＣＮ１０６は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができ、ネットワーク１１２は、その他のサービスプロバイダによって所有および／または運営されているその他の有線またはワイヤレスのネットワークを含むことができる。

「資金援助者」とは、人（たとえば、ＷＴＲＵのユーザ）であることが可能であり、その人は、パブリックランドモバイルネットワーク（ＰＬＭＮ）のサブスクライバーであることが可能である。簡単にするために、資金援助者は、本出願においては「ＷＴＲＵ１」と呼ばれることが可能であり、そのＷＴＲＵ１は、サービスにアクセスするために、および資金援助を開始するために使用されるデバイスであることが可能である。それにもかかわらず、その人（デバイスではない）は、資金援助者であることが可能であり、この人は、サービスにアクセスするために、および資金援助を開始するために、その他のデバイス（たとえば、パーソナルコンピュータ（ＰＣ））を使用することができる。同様に、「資金援助されるエンティティー」も、人、典型的にはＰＬＭＮサブスクライバー（たとえば、ＷＴＲＵのユーザ）であることが可能である。簡単にするために、資金援助されるエンティティーは、本出願においては「ＷＴＲＵ２」と呼ばれることが可能であり、そのＷＴＲＵ２は、資金援助されるイベントを消費するために使用されるデバイスであることが可能である。

ユーザは、アプリケーションサービスに関して別のユーザを資金援助することができる。資金援助者（ＷＴＲＵ１）、および資金援助されるイベントの受領者（ＷＴＲＵ２）が、同じモバイルネットワークオペレータ（ＭＮＯ）のサブスクライバーであることが可能である場合の、またはＷＴＲＵ２がＭＮＯのサブスクライバーであることが可能ではない場合の統合。ＷＴＲＵ１のＭＮＯと、ＡＰとの間におけるサービスコラボレーションが存在することが可能である。サービスコラボレーションを伴わないケースが存在することも可能であり、これは、ローミングシナリオ、ならびに、ＷＴＲＵ１のユーザおよびＷＴＲＵ２のユーザが別々のＭＮＯのサブスクライバーであることが可能であるケースを含む。

資金援助は、他者とのサービスの共有を可能にすることができる。１つの使用ケースにおいては、ユーザが、友人の家において友人を訪問する場合がある。訪問しているユーザは、有料ライブイベントストリーミングサービスへのアクセスを有する場合があり、友人のテレビジョン（ＴＶ）上でライブイベントを見たいと望む場合がある。別の使用ケースにおいては、ショーを見ているユーザが、公共交通機関上で友人と出会って、その友人のデバイス上でそのショーのプレゼンテーションを複製する場合がある。あるいは、ユーザは、その後の時点で（たとえば、１週間以内に）そのショーを見ようと誰かにデジタル招待状を送信する場合がある。すべてのケースにおいて、招待主が、関連付けられているサービス料金に対して責任を負う場合がある。アプリケーションプロバイダは、特定のレベルの使用まで何らかの形態の無料共有を可能にすることもできる。

アプリケーション資金援助に関連付けられている料金が資金援助者に適切に請求されることが可能であることを確実にするために、何らかのレベルの統合が定義されることが可能である。現在、資金援助情報は、資金援助がその他のエンドユーザによって申し出られることが可能である動的な状況に適用可能ではないと言える。

セルラーネットワークサブスクライバーは、ユーザデータアクセス、監視、および課金のためにセルラーネットワークと相互運用するための契約を有するアプリケーションを使用することに関して別のサブスクライバーを資金援助することができる。ＷＴＲＵ１は、資金援助を可能にする（場合によっては、これを一式のサービスに制限する）ために、自分のＭＮＯとの間での事前契約を結ぶことができる。この情報は、ＭＮＯネットワーク（ホームサブスクライバーサーバ（ＨＳＳ：home subscriber server）、サブスクライバープロファイルリポジトリ（ＳＰＲ：subscriber profile repository）／ユーザデータリポジトリ（ＵＤＲ：user data repository））内に格納されることが可能である。ＷＴＲＵ１は、別のユーザを資金援助することをアプリケーションサーバ（ＡＳ）に申し出ることができる。ＡＳは、（ネットワークにおける、および潜在的にはＷＴＲＵ２との間での）承認をチェックすること、ならびに、直接またはＷＴＲＵ１を通じてＷＴＲＵ２に適切なトリガー（たとえば、ハイパーリンク）を提供することによってその申し出を受けることが可能である。このシーケンスの一部は、事前に実行されることが可能である（たとえば、ＡＳは、１回限りの資金援助トークン（sponsorship tokens）をＷＴＲＵ１に事前に提供することができる。次いでＷＴＲＵ１は、そのようなトークンを含むユニフォームリソースロケータ（ＵＲＬ）をＷＴＲＵ２へその後の時点で通信することができる。その後に（たとえば、トリガーを受信した直後に、またはこのトリガーを受信した１週間後に）、ＷＴＲＵ２は、資金援助されるアプリケーションセッションを開始することができる。セッションサービス品質（ＱｏＳ：quality of service）および課金構成中に、図２に示されているようなポリシーおよび課金ルール機能（ＰＣＲＦ：policy and charging rules function）２４０は、この資金援助が承認されることが可能であることを確実にするために資金援助者のプロファイルをチェックすることができる。次いでセッションは、進行することができる。その資金援助者は、資金援助されるセッションに関して後ほど課金されることが可能である。

本明細書において説明されているように、所与のアプリケーションサービスのユーザ同士の間における資金援助および共有をサポートする強化された３ＧＰＰ ＣＮオペレーションは、サービスそのものに適用されることが可能であるが、その上、ネットワークリソース使用（たとえば、サービスにアクセスするために十分なリソースを被資金援助者に提供すること）をカバーすることもできる。これは、たとえ被資金援助者のプランがこのレベルのサービスを可能にしていない場合でも、当てはまることができる。図２を参照すると、ＡＳ２０５は、既に３ＧＰＰ ＣＮオペレータとの間での契約を有していることが可能であり、これは、ＡＳ２０５が、サブスクライバープロファイルアクセス、ＱｏＳ、および課金のためにＣＮとの間で相互運用することを可能にする。

ユーザプロファイル情報要素（ＩＥ）が、ＨＳＳまたはＳＰＲ／ＵＤＲ内に格納されることが可能であり、このユーザプロファイル情報要素（ＩＥ）は、おそらくはアプリケーションごとに、ユーザによってその他のユーザを資金援助するための契約を指定し、ターゲットＷＴＲＵ、有効時間、またはコストの点でのさまざまな制限を含む。資金援助に関連したアプリケーション固有の制限が、ＨＳＳ２４５またはＡＳ２０５において導入されることも可能である。たとえば、一片のコンテンツに対する同時に資金援助されるアクセスの数に対する制限が存在することが可能である。グループ資金援助に関連したさらなるサブスクライバープロファイルＩＥ、および転送可能な資金援助トークンが含まれることも可能である。

エンドユーザは、アプリケーションサーバを含めて、別のユーザに資金援助を提案することができる。この資金援助は、サービスそのものに関するものであることが可能であるが、アクセスネットワークにおけるリソース割当てのコストをカバーすることもできる。このプロセス中に、ＡＳ２０５は、資金援助者ユーザプロファイルにアクセスし、このオペレーションが可能にされていることを確認し、次いで、その後の使用のために内部の被資金援助イベント記述子を作成することができる。ＡＳ２０５または資金援助者のいずれかは最後に、資金援助されるサービスにアクセスするための情報をオペレーションのＷＴＲＵターゲットに通信することができる。

ＡＳ２０５は、ＷＴＲＵに資金援助トークンを提供することができ、ＷＴＲＵは、資金援助されるイベントへのアクセスをその他のＷＴＲＵに与えるために、その資金援助トークンをそれらのＷＴＲＵに通信することができる。これらのトークンは、限られた範囲、使用回数、または有効期間を有することができる。これらのトークンは、ＡＳ２０５において、何らかの形態の事前に割り当てられた被資金援助イベント記述子に関連付けられることが可能である。資金援助トークンは、その他のＷＴＲＵへ転送可能であってもよく、または転送可能でなくてもよい。

ＷＴＲＵは、別のユーザによって資金援助されるアプリケーションセッションを開始することができ、その場合、ＡＳ２０５は、このセッション開始を既存の被資金援助イベント記述子とマッチさせ、ＰＣＲＦ２４０を通じてセッションＱｏＳおよび課金を構成し、区別できる課金キーを使用することによって、いかなる課金もその資金援助者に向けられることが可能であることを確実にする。ＰＣＲＦ２４０は、資金援助されるイベントが承認されることを確実にするために、資金援助者および資金援助されるＷＴＲＵの両方のサブスクライバープロファイルをチェックすることができる。承認された場合には、セッションは、ポリシーおよび課金実施機能（ＰＣＥＦ：policy and charging enforcement function）を通じて構成されることが可能である。ＡＳ２３５によるＰＣＲＦ２４０を通じた事前承認チェックを可能にするために、ＡＳ２０５とＰＣＲＦ２４０との間におけるＲｘ参照ポイント２３５を介してメッセージが導入されることが可能である。

説明されているフローの諸部分は、独立して適用されることが可能であり、それによってサポートは、一方では、ＷＴＲＵが別のＷＴＲＵとサービスを共有することを可能にすることができ、他方では、サポートは、ＷＴＲＵが、別のＷＴＲＵに与えられるサービスに関して課金されることが可能となるようＡＳ２０５がＣＮに要求することを可能にすることができる。

条件付きモードのＷＴＲＵベースの資金援助が実施されることが可能であり、それによってＷＴＲＵは、別のＷＴＲＵが既存のアカウントを使用してサービスにアクセスすることができない場合には自分がその別のＷＴＲＵのためにサービスを資金援助する準備が整っていることを表明する。

３ＧＰＰ以外のコンテキストにおいては、ＱｏＳ、課金、および、サブスクライバープロファイルへのアクセスのためにアクセスプロバイダネットワークと統合されたアプリケーションサービスは、ＷＴＲＵベースの資金援助または共有を可能にすることができる。

３ＧＰＰの資金援助機能は、オペレーションを可能にするトークンを得たいという資金援助者ＷＴＲＵ１からの要求を含むことができる。被資金援助者ＷＴＲＵ２は、ＷＴＲＵ１の代わりにセッションの資金援助をＡＳ２０５に行わせるためのトリガーの形態としてのトークンを（セッション開始時に）ＡＳに提供することができる。

ＡＳ２０５と３ＧＰＰ ＣＮとの間における強化されたインターフェースは、課金イベントがＡＳ２０５によって送信されることを可能にするために使用されることが可能であり、その場合、課金イベントは、実際のトラフィックには関連しておらず、ＡＳ２０５によって提供されるサービスに関連している。Ｒｘ参照ポイント２３５は、この機能をサポートするように修正されることが可能である。ＡＳ２０５と課金システムとの間における介在物としての（場合によっては、ＰＣＲＦと、またはＰ−ＧＷと統合されている）ゲートウェイ機能が実装されることが可能である。サードパーティーＡＳと課金システムとの間において直接のインターフェースが確立されることが可能である。

同じＭＮＯを伴うコラボレーティブケースに相当する第１の実施形態においては、ＷＴＲＵ１およびＷＴＲＵ２は、ＭＮＯ Ｙのサブスクライバーである。ＭＮＯ ＹとＡＰ Ｘとの間において、契約が存在する。

図２は、課金ノード２１０と相互接続されているアプリケーションサーバ（ＡＳ）２０５を含むネットワークアーキテクチャー２００を示している。課金ノード２１０は、オンライン課金システム（ＯＣＳ：online charging system）２１５およびオフライン課金システム（ＯＦＣＳ：offline charging system）２２０を含むことができる。アーキテクチャー２００は、ＡＳ２０５と、モバイルノード（ＭＮ）などのワイヤレス送信／受信ユニット（ＷＴＲＵ）との間における相互接続を提供することができる。ＡＳ２０５および課金ノード２１０は、（オンライン課金用の）Ｍｏ参照ポイント２２５、および／または（オフライン課金用の）Ｍｆ参照ポイント２３０を介して直接相互接続されることが可能である。Ｍｏ参照ポイント２２５は、Ｄｉａｍｅｔｅｒベースプロトコルに基づくＲｏインターフェースに基づくことが可能であり、Ｍｆ参照ポイント２３０は、Ｄｉａｍｅｔｅｒベースプロトコルに基づくＲｆインターフェースに基づくことが可能である。アーキテクチャー２００においては、サービス（またはコンテンツ）にアクセスすることに関連した料金は、Ｍｏ参照ポイント２２５およびＭｆ参照ポイント２３０を介して伝達されることが可能である。

オフライン課金に関しては、Ｒｆインターフェースは（したがって、Ｍｆ参照ポイント２３０も）、イベントベースの課金およびセッションベースの課金をサポートすることができる。ＡＳ２０５は、アカウンティングレコードタイプＥＶＥＮＴまたはＳＴＡＲＴ／ＩＮＴＥＲＩＭ／ＳＴＯＰのアカウンティングデータを含むアカウンティング要求（ＡＣＲ）メッセージを送信することができる。オンライン課金に関しては、Ｒｏは（したがって、Ｍｏ参照ポイント２２５も）、即座のイベント課金、ユニット予約を伴うイベント課金、およびユニット予約を伴うセッション課金をサポートすることができる。ＡＳ２０５は、ｃｒｅｄｉｔ−ｃｏｎｔｒｏｌ−ｒｅｑｕｅｓｔ（ＣＣＲ）メッセージ（適切な値へのセットのＣＣ−ｒｅｑｕｅｓｔｅｄ−ｔｙｐｅを含む）を送信することができる。

ＡＳ２０５およびＰＣＲＦ２４０課金インターフェース更新は、以降で説明されているように生じることが可能である。ＡＳ２０５は、Ｍｏ参照ポイント２２５またはＭｆ参照ポイント２３０を介して第１のＷＴＲＵユーザ（ＷＴＲＵ１）に課金することができるため、ユーザ資金援助は、サービスおよび接続に関して別々に可能にされ得る。

１つの手順は、サービス資金援助（たとえば、ＡＳ２０５によって配信されるコンテンツのためのアクセスのコスト）に関して適用可能とすることができ、別の手順は、接続資金援助（たとえば、第２のＷＴＲＵ（ＷＴＲＵ２）のために満足できる体感品質（ＱｏＥ）を伴ってそのコンテンツを配信するために必要とされる優先トラフィック処理のためのコストに関して適用可能とすることができる。この手順は、サービスのユーザ資金援助（たとえば、コンテンツにアクセスするためのコスト）を含むことができ、これは、ＡＳ２０５によってＭｏ参照ポイント２２５またはＭｆ参照ポイント２３０を介して、ＷＴＲＵ２ではなく直接ＷＴＲＵ１に課金することによって、またはＷＴＲＵ２に課金してＷＴＲＵ１のアイデンティティーを資金援助者として含めることによって実行されることが可能である。ＯＣＳ２１５およびＯＦＣＳ２２０は、ＷＴＲＵ１に関する課金データレコード（ＣＤＲ）を作成することができ、このＣＤＲは、このＣＤＲがＷＴＲＵ２のユーザ資金援助に関連していることを示すＩＥを含む。したがって、ＷＴＲＵ１の請求書は、料金とともにこの情報に言及することができる。

別の手順は、ＡＳ２０５によってＲｘインターフェース２３５を介して、Ｒｘメッセージ内でユーザ資金援助者アイデンティティーに言及することによって実行されるユーザ資金援助を含むことができる。

ユーザ資金援助タイプは、アプリケーションレイヤにおいてＷＴＲＵ１によって制御されることが可能である。ＡＳ２０５へ送信されるユーザ資金援助要求において、ユーザ資金援助者は、サービスのみ、優先トラフィック処理（すなわち接続）のみ、ならびに、サービスおよび優先トラフィック処理という選択肢の中から資金援助のタイプを選択することができる。ＡＳ２０５は、ＷＴＲＵ１によって選択されたユーザ資金援助タイプに応じて、上述の手順を独立して使用することによって機能することができる。

このシステムは、ＯＣＳ２１５に対するユーザ資金援助関連チェックを可能にすることができる。ＰＣＲＦ２３５は、ＷＴＲＵ１がユーザ資金援助を実行する上で十分なクレジットを有しているかどうかをチェックするために、ＯＣＳ２１５に対する自分の既存のインターフェースを使用することができる。たとえば、ＷＴＲＵ１のためのユーザ資金援助割当量（たとえば、１カ月あたり最大で１００メガバイトまでのデータトラフィックが資金援助されることが可能であること）を表すために、ＭＮＯによって特定のユーザ資金援助ポリシーカウンタがセットアップされることが可能である。

Ｒｘ参照ポイント２３５を介した資金援助者アイデンティティーの分類が生じることが可能である。通常の資金援助者（ＭＮＯとの間での資金援助契約を有するエンティティー）と、ユーザ資金援助者（たとえば、ＷＴＲＵ１などのサブスクライバー）との間において区別を行うために、Ｒｘシグナリングが強化されることが可能である。ＰＣＲＦ２４０は、オペレータポリシーによって可能にされている場合には、資金援助される優先トラフィック処理プロファイルに関して承認チェックを実行することができ、その一方で、ユーザ資金援助に関する承認チェックは異なることが可能である（たとえば、このケースにおける承認は、ＷＴＲＵ１のサブスクライバープロファイルをチェックすることを必要とすることが可能である）。エンティティーとユーザ資金援助者との間におけるこの区別は、資金援助者アイデンティティーのフォーマット上でいくつかのヒューリスティックを使用することによって可能にされ得る（たとえば、移動局国際加入者ディレクトリ番号（ＭＳＩＳＤＮ）は、ユーザ資金援助のみのために使用されることが可能である）。それでもなお、これは、資金援助者アイデンティティー文字列を分析すること、ならびに、エンティティーアイデンティティーおよびユーザ資金援助者アイデンティティーの両方のフォーマット上にさらなる制限を課すことを必要とする場合があり、それは、システムに複雑さを加え、資金援助機能を不必要に制限する場合がある。

適切な分類のために、下記の例示的なメソッドが使用されることが可能である。これらは、資金援助者アイデンティティーの分類の実施態様の２つの例である。
Ｓｐｏｎｓｏｒｅｄ−Ｃｏｎｎｅｃｔｉｖｉｔｙ−Ｄａｔａ：：＝＜ＡＶＰ Ｈｅａｄｅｒ：５３０＞
［Ｓｐｏｎｓｏｒ−Ｉｄｅｎｔｉｔｙ］
［Ｕｓｅｒ−Ｓｐｏｎｓｏｒ−Ｉｄｅｎｔｉｔｙ］
（Ｓｐｏｎｓｏｒ−ＩｄｅｎｔｉｔｙまたはＵｓｅｒ−Ｓｐｏｎｓｏｒ−Ｉｄｅｎｔｉｔｙのいずれかが存在することが可能である）
［Ａｐｐｌｉｃａｔｉｏｎ−Ｓｅｒｖｉｃｅ−Ｐｒｏｖｉｄｅｒ−Ｉｄｅｎｔｉｔｙ］
［Ｇｒａｎｔｅｄ−Ｓｅｒｖｉｃｅ−Ｕｎｉｔ］
［Ｕｓｅｄ−Ｓｅｒｖｉｃｅ−Ｕｎｉｔ］
^*［ＡＶＰ］
−または−
Ｓｐｏｎｓｏｒｅｄ−Ｃｏｎｎｅｃｔｉｖｉｔｙ−Ｄａｔａ：：＝＜ＡＶＰ Ｈｅａｄｅｒ：５３０＞
［Ｓｐｏｎｓｏｒ−Ｉｄｅｎｔｉｔｙ］
［Ｓｐｏｎｓｏｒ−Ｉｄｅｎｔｉｔｙ−Ｔｙｐｅ］
［Ａｐｐｌｉｃａｔｉｏｎ−Ｓｅｒｖｉｃｅ−Ｐｒｏｖｉｄｅｒ−Ｉｄｅｎｔｉｔｙ］
［Ｇｒａｎｔｅｄ−Ｓｅｒｖｉｃｅ−Ｕｎｉｔ］
［Ｕｓｅｄ−Ｓｅｒｖｉｃｅ−Ｕｎｉｔ］
^*［ＡＶＰ］

第１の例においては、タイプＵＴＦ８Ｓｔｒｉｎｇの新たなｕｓｅｒ−ｓｐｏｎｓｏｒ−ｉｄｅｎｔｉｔｙが使用されることが可能である。Ｓｐｏｎｓｏｒｅｄ−ｃｏｎｎｅｃｔｉｖｉｔｙ−ｄａｔａは、唯一の資金援助者アイデンティティー属性値ペア（ＡＶＰ）、（ＭＮＯとの間での資金援助契約を有するエンティティーに関しては）ｓｐｏｎｓｏｒ−ｉｄｅｎｔｉｔｙ、または（モバイルネットワークのサブスクライバーである資金援助者に関しては）ｕｓｅｒ−ｓｐｏｎｓｏｒ−ｉｄｅｎｔｉｔｙを含むことができる。

あるいは、第２の同等なエンコーディングが、一例として提供されることが可能であり、この場合、ｓｐｏｎｓｏｒ−ｉｄｅｎｔｉｔｙは、両方のタイプの資金援助者に関して使用されることが可能であるが、新たな列挙されるＡＶＰ ｓｐｏｎｓｏｒ−ｉｄｅｎｔｉｔｙ−ｔｙｐｅが、サポートされる値ＳＰＯＮＳＯＲ＿ＴＹＰＥ＿ＥＮＴＩＴＹ（０）、すなわち、このＡＶＰが存在しない場合の（下位互換性のための）デフォルト値、およびＳＰＯＮＳＯＲ＿ＴＹＰＥ＿ＵＳＥＲ（１）を伴って付加されることが可能である。

第３の選択肢としては、ＡＶＰ定義において変更はないが、資金援助者タイプを伝達する方法でＳｐｏｎｓｏｒ−Ｉｄｅｎｔｉｔｙを使用することに同意することがＡＰおよびＭＮＯに委ねられる。たとえば、ユーザ資金援助者を識別するためのＭＳＩＳＤＮまたはＭＳＩＳＤＮ＠ｍｎｏｌ．ｃｏｍまたはＷＴＲＵネットワークアクセス識別子（ＮＡＩ）、およびエンティティー資金援助者を識別するためのその他の文字列である。

Ｍｆ参照ポイントを介した資金援助者アイデンティティーの分類が生じることが可能である。既存の被資金援助データ接続機能に関して、２つの展開シナリオが存在する。第１のシナリオにおいては、ＰＣＲＦは、資金援助されるインターネットプロトコル（ＩＰ）フローのためにサービス固有の課金キーを割り振ることができる。結果として、その課金キーを使用して、アカウンティングレコードおよび使用データのその後の相関付けが実行されることが可能である。第２のシナリオにおいては、資金援助者識別子およびアプリケーションサービスプロバイダアイデンティティーが、ＰＣＲＦからＰＣＥＦへのポリシー制御および課金（ＰＣＣ：policy control and charging）ルール内に含まれることが可能であり、ＰＣＥＦは、この情報を課金ノードに提供することができる。

この第２のシナリオにおいては、ユーザ資金援助者と、ＭＮＯとの間での契約を有するエンティティーとの間における区別を可能にするために、Ｍｆ参照ポイントシグナリング（これは、Ｒｆシグナリングと同等であると想定される）が強化されることが可能である。結果として、課金ノード（たとえば、課金データ機能（ＣＤＦ））は、アカウンティングレコードがユーザ資金援助者に関連している可能性があることに気づくことができ、その料金をこのユーザに適用することができる。

下記のものは、この分類の実施態様の一例である。Ｓｅｒｖｉｃｅ−Ｄａｔａ−Ｃｏｎｔａｉｎｅｒ ＡＶＰが、ＡＣＲメッセージ内に含まれることが可能である。Ｓｅｒｖｉｃｅ−ｄａｔａ−ｃｏｎｔａｉｎｅｒ ＡＶＰは、パケット交換（ＰＳ）情報ＡＶＰ内に含まれることが可能であり、パケット交換（ＰＳ）情報ＡＶＰは、ｓｅｒｖｉｃｅ−ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰ内に含まれることが可能であり、ｓｅｒｖｉｃｅ−ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰは、ＡＣＲ内に含まれることが可能である。
Ｓｅｒｖｉｃｅ−Ｄａｔａ−Ｃｏｎｔａｉｎｅｒ：：＝ ＜ＡＶＰ Ｈｅａｄｅｒ：２０４０＞
［ＡＦ−Ｃｏｒｒｅｌａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ］
［Ｃｈａｒｇｉｎｇ−Ｒｕｌｅ−Ｂａｓｅ−Ｎａｍｅ］
［Ａｃｃｏｕｎｔｉｎｇ−Ｉｎｐｕｔ−Ｏｃｔｅｔｓ］
［Ａｃｃｏｕｎｔｉｎｇ−Ｏｕｔｐｕｔ−Ｏｃｔｅｔｓ］
［Ａｃｃｏｕｎｔｉｎｇ−Ｉｎｐｕｔ−Ｐａｃｋｅｔｓ］
［Ａｃｃｏｕｎｔｉｎｇ−Ｏｕｔｐｕｔ−Ｐａｃｋｅｔｓ］
［Ｌｏｃａｌ−Ｓｅｑｕｅｎｃｅ−Ｎｕｍｂｅｒ］
［ＱｏＳ−Ｉｎｆｏｒｍａｔｉｏｎ］
［Ｒａｔｉｎｇ−Ｇｒｏｕｐ］
［Ｃｈａｎｇｅ−Ｔｉｍｅ］
［Ｓｅｒｖｉｃｅ−Ｉｄｅｎｔｉｆｉｅｒ］
［Ｓｅｒｖｉｃｅ−Ｓｐｅｃｉｆｉｃ−Ｉｎｆｏ］
［ＳＧＳＮ−Ａｄｄｒｅｓｓ］
［Ｔｉｍｅ−Ｆｉｒｓｔ−Ｕｓａｇｅ］
［Ｔｉｍｅ−Ｌａｓｔ−Ｕｓａｇｅ］
［Ｔｉｍｅ−Ｕｓａｇｅ］
^*［Ｃｈａｎｇｅ−Ｃｏｎｄｉｔｉｏｎ］
［３ＧＰＰ−Ｕｓｅｒ−Ｌｏｃａｔｉｏｎ−Ｉｎｆｏ］
［３ＧＰＰ２−ＢＳＩＤ］
［Ｓｐｏｎｓｏｒ−Ｉｄｅｎｔｉｔｙ］
［Ｕｓｅｒ−Ｓｐｏｎｓｏｒ−Ｉｄｅｎｔｉｔｙ］
（Ｅｉｔｈｅｒ Ｓｐｏｎｓｏｒ−Ｉｄｅｎｔｉｔｙ ｏｒ Ｕｓｅｒ−Ｓｐｏｎｓｏｒ−Ｉｄｅｎｔｉｔｙ ｍａｙ ｂｅ ｐｒｅｓｅｎｔ）
［Ａｐｐｌｉｃａｔｉｏｎ−Ｓｅｒｖｉｃｅ−Ｐｒｏｖｉｄｅｒ−Ｉｄｅｎｔｉｔｙ］
−または−
Ｓｅｒｖｉｃｅ−Ｄａｔａ−Ｃｏｎｔａｉｎｅｒ：：＝＜ＡＶＰ Ｈｅａｄｅｒ：２０４０＞
［ＡＦ−Ｃｏｒｒｅｌａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ］
［Ｃｈａｒｇｉｎｇ−Ｒｕｌｅ−Ｂａｓｅ−Ｎａｍｅ］
［Ａｃｃｏｕｎｔｉｎｇ−Ｉｎｐｕｔ−Ｏｃｔｅｔｓ］
［Ａｃｃｏｕｎｔｉｎｇ−Ｏｕｔｐｕｔ−Ｏｃｔｅｔｓ］
［Ａｃｃｏｕｎｔｉｎｇ−Ｉｎｐｕｔ−Ｐａｃｋｅｔｓ］
［Ａｃｃｏｕｎｔｉｎｇ−Ｏｕｔｐｕｔ−Ｐａｃｋｅｔｓ］
［Ｌｏｃａｌ−Ｓｅｑｕｅｎｃｅ−Ｎｕｍｂｅｒ］
［ＱｏＳ−Ｉｎｆｏｒｍａｔｉｏｎ］
［Ｒａｔｉｎｇ−Ｇｒｏｕｐ］
［Ｃｈａｎｇｅ−Ｔｉｍｅ］
［Ｓｅｒｖｉｃｅ−Ｉｄｅｎｔｉｆｉｅｒ］
［Ｓｅｒｖｉｃｅ−Ｓｐｅｃｉｆｉｃ−Ｉｎｆｏ］
［ＳＧＳＮ−Ａｄｄｒｅｓｓ］
［Ｔｉｍｅ−Ｆｉｒｓｔ−Ｕｓａｇｅ］
［Ｔｉｍｅ−Ｌａｓｔ−Ｕｓａｇｅ］
［Ｔｉｍｅ−Ｕｓａｇｅ］
^*［Ｃｈａｎｇｅ−Ｃｏｎｄｉｔｉｏｎ］
［３ＧＰＰ−Ｕｓｅｒ−Ｌｏｃａｔｉｏｎ−Ｉｎｆｏ］
［３ＧＰＰ２−ＢＳＩＤ］
［Ｓｐｏｎｓｏｒ−Ｉｄｅｎｔｉｔｙ］
［Ｓｐｏｎｓｏｒ−Ｉｄｅｎｔｉｔｙ−Ｔｙｐｅ］
［Ａｐｐｌｉｃａｔｉｏｎ−Ｓｅｒｖｉｃｅ−Ｐｒｏｖｉｄｅｒ−Ｉｄｅｎｔｉｔｙ］

第１の例においては、タイプＵＴＦ８Ｓｔｒｉｎｇの新たなｕｓｅｒ−ｓｐｏｎｓｏｒ−ｉｄｅｎｔｉｔｙが使用されることが可能である。Ｓｐｏｎｓｏｒｅｄ−ｃｏｎｎｅｃｔｉｖｉｔｙ−ｄａｔａは、（ＭＮＯとの間での資金援助契約を有するエンティティーに関しては）ｓｐｏｎｓｏｒ−ｉｄｅｎｔｉｔｙ、または（モバイルネットワークのサブスクライバーである資金援助者に関しては）ｕｓｅｒ−ｓｐｏｎｓｏｒ−ｉｄｅｎｔｉｔｙを含むことができる。

あるいは、第２の同等なエンコーディングが、一例として提供されることが可能であり、この場合、ｓｐｏｎｓｏｒ−ｉｄｅｎｔｉｔｙは、両方のタイプの資金援助者に関して使用されることが可能であるが、新たな列挙されるＡＶＰ ｓｐｏｎｓｏｒ−ｉｄｅｎｔｉｔｙ−ｔｙｐｅが、サポートされる値ＳＰＯＮＳＯＲ＿ＴＹＰＥ＿ＥＮＴＩＴＹ（０）、すなわち、このＡＶＰが存在しない場合の（下位互換性のための）デフォルト値、およびＳＰＯＮＳＯＲ＿ＴＹＰＥ＿ＵＳＥＲ（１）を伴って付加されることが可能である。

別の選択肢としては、ＡＶＰ定義においては変更なしとすることができるが、資金援助者タイプを伝達する方法（たとえば、ユーザ資金援助者を識別するためのＭＳＩＳＤＮまたはＭＳＩＳＤＮ＠ｍｎｏｌ．ｃｏｍまたはＷＴＲＵ−ＮＡＩ、およびエンティティー資金援助者を識別するためのその他の文字列）でｓｐｏｎｓｏｒ−ｉｄｅｎｔｉｔｙを使用することに同意することがＡＰおよびＭＮＯに委ねられることが可能である。

Ｍｏ参照ポイントを介した資金援助者アイデンティティーの分類が生じることが可能である。Ｍｆ参照ポイントに関して（すなわち、オフライン課金ケースに関して）上述した強化は、Ｍｏ参照ポイントに関して（すなわち、オンライン課金ケースに関して）も適用可能とすることができる。なぜなら、ｓｅｒｖｉｃｅ−ｄａｔａ−ｃｏｎｔａｉｎｅｒ ＡＶＰは、ｃｒｅｄｉｔ−ｃｏｎｔｒｏｌ−ｒｅｑｕｅｓｔメッセージ内に含まれることも可能であるためである。

ＭＮＯによって所有されるＡＳが生じることが可能である。この実施形態は、ＡＳがＭＮＯによって所有され展開されるケースに拡張されることが可能である。このケースにおけるソリューションの実際のシグナリングにおいては、変更はない。

マイナーな強化の例は、「資金援助許可がＡＳを関与させている」という部分においてＷＴＲＵ１の承認をチェックするためにＡＳは典型的にはＰＣＲＦと対話することはないことを含む。

同じＭＮＯを伴う、コラボレーティブケースに相当する第２の実施形態においては、ＷＴＲＵ１およびＷＴＲＵ２は、ＭＮＯ Ｙのサブスクライバーである。ＭＮＯ ＹとＡＰ Ｘとの間において、契約が存在する。

ＡＳが課金ノードと相互接続されるアーキテクチャーが構成されることが可能である。Ｍｏ／Ｍｆを介したＡＳと課金ノードとの直接相互接続が、ＡＳによってユーザに直接課金するために使用されることが可能であり、ユーザ資金援助者は、サービスのみ、優先トラフィック処理のみ、またはそれらの両方を資金援助することができる。ＡＳは、ＭＮＯによって所有され展開されることが可能である。

図３Ａおよび図３Ｂは、ともに併せて、ＡＳがＭＮＯによって所有され展開されることが可能であるユーザ資金援助手順３００のメッセージフロー図である。ユーザは、同じＭＮＯの別のサブスクライバーのためにアプリケーションセッションを資金援助することができる。コンテキスト情報がネットワーク構造のために提供されることが可能であり、そこでは、ＡＳがモバイルネットワークとの間での契約を有する。ＷＴＲＵ１およびＷＴＲＵ２は、同じモバイルネットワークのサブスクライバーであることが可能である。

ＷＴＲＵ１は、ＭＮＯに対する契約を有するＡＳによって提供されるサービスにアクセスすることができる。ＷＴＲＵ１は、ホームネットワーク内に存在していることが可能であり、またはローミングしていることが可能である。ＷＴＲＵ２は、同じＭＮＯのサブスクライバーであることが可能である。ＷＴＲＵ２は、ホームネットワーク内に存在していることが可能である。ＷＴＲＵ１は、たとえば、ＡＳによって提供される映画サービスからの特定の映画のストリーミング、またはこのサービスからの任意の映画のストリーミングなどのアプリケーションセッションを２週間以内に最大で４時間にわたって資金援助しようと努めることができる。

図３Ａに示されているように、ＷＴＲＵ１のユーザプロファイルにおいて、および／またはＡＳにおいて、ユーザ資金援助データが構成されることが可能である（３０２）。ＷＴＲＵ１は、ＷＴＲＵ２からアイデンティティーおよび承認を得ることができ、ＷＴＲＵ１は、代わりに、ＷＴＲＵ２を関与させることなく、ＷＴＲＵ２のユーザまたはＷＴＲＵ２そのもののアイデンティティーを得ることもできる（３０４）。ＷＴＲＵ２のユーザ資金援助が開始されることが可能である（サービス資金援助タイプパラメータまたは接続資金援助タイプパラメータのうちの少なくとも１つ）（３０６）。ＡＳは、（ＨＳＳ、ＳＰＲ、またはＵＤＲから）承認されたユーザ資金援助オペレーションをＷＴＲＵ１サブスクライバーが有しているかどうかをチェックすることができる（３０８）。ＡＳは、サービストリガーをＷＴＲＵ２に提供することができ、またはＡＳは、トリガーをＷＴＲＵ１に提供することができ、ＷＴＲＵ１は、そのトリガーをＷＴＲＵ２に提供する（３１０）。ＷＴＲＵ１は、（おそらくは事前に、たとえばサインアップ時に、または毎月）資金援助トークンを得ることができ、その資金援助トークンは、範囲／時間において制限されること（およびサービス資金援助タイプまたは接続資金援助タイプのうちの少なくとも１つに関連付けられること）が可能である（３１２）。ＷＴＲＵ１は、ＷＴＲＵ２へのトリガー（たとえば、トークンを含むＵＲＬ）を提供することを、おそらくはそうするための承認をＷＴＲＵ２に要求した後に行うことができる（３１４）。

図３Ｂに示されているように、ＷＴＲＵ２は、トリガー（たとえば、埋め込まれているトークン（埋め込みトークン（embedded token））を伴うハイパーリンク）を使用して、資金援助されるセッションを開始することができる（３１６）。ＡＳは、（たとえばトークンを使用して）セッションを資金援助者とマッチさせることができる（３１８）。ＡＳは、課金システムと対話すること（たとえば、オフライン課金のための強化されたアカウンティングレコードメッセージ、またはオンライン課金のための強化されたクレジットコントロール要求を送信すること）が可能であり、ＡＳは、（現在または後ほどセッション中またはセッション後に生じる）イベントベースの対話、またはセッションベースの対話を使用することができる（３２０）。この対話は、サービスコストが（ＷＴＲＵ１がサービスを資金援助することを選択した場合には）ＷＴＲＵ１に、またはそうでなければＷＴＲＵ２のユーザに課金されることが可能であることを確実にすることができる。ＡＳは、ＷＴＲＵ１のユーザが接続を資金援助することを選択した場合にはユーザ資金援助者としてＷＴＲＵ１のユーザを含めて、このセッションに関するネットワークリソースをＲｘインターフェースを介してＰＣＲＦ（ＱｏＳ、課金）に要求することができる（このケースにおいては、プロセスの一部として、ＡＳおよび／またはＰＣＲＦは、資金援助が許可されているかどうかを確認するためにＷＴＲＵ１のおよびＷＴＲＵ２のプロファイル情報をチェックすることができる）（３２２）。ＰＣＲＦは、ＰＣＣルールをＰＣＥＦへ送信すること、およびＱｏＳルールをアクセスネットワークノードへ送信することが可能である。オンラインケースにおいては、ＰＣＲＦは、ユーザ資金援助のためにＷＴＲＵ１のクレジット残高をチェックする目的でＳｙインターフェースを使用することができる。ＡＳは、ＷＴＲＵ２に応答して、サービスの配信を進めることができる（３２４）。ＰＣＥＦは、セッション使用情報を課金エンティティーに通信することができる（３２６）。資金援助される接続に関する課金は、ＷＴＲＵ１に請求するために後ほど使用されることが可能であり、またはＷＴＲＵ１の前払いから差し引かれることが可能である（３２８）。

図３Ｃおよび図３Ｄは、ともに併せて、資金援助要求手順３３０のメッセージフロー図である。図３Ｃに示されているように、アイデンティティー、ならびに、特定のサービスに関して資金援助する／資金援助される意志および能力についてやり取りするために、ＷＴＲＵ１とＷＴＲＵ２との間において（オフラインおよび／またはオンラインで）最初の通信が確立されることが可能である（３３２）。ＷＴＲＵ１は、資金援助要求メッセージ（ターゲット：ＷＴＲＵ２、範囲：特定のコンテンツ、持続時間、コスト、時間ウィンドウなど）をＡＳへ送信して、ＷＴＲＵ２を資金援助することを申し出ることができ、ＷＴＲＵ２のアイデンティティー、ならびに資金援助に関する範囲情報（たとえば、特定のコンテンツまたは特定のカテゴリーのコンテンツへのアクセスとしての、コストまたはサービス持続時間の点での制限）を提供することができる（３３４）。この要求は、アプリケーションレイヤにおいて実行されることが可能であり、サービスは、この資金援助機能に関して明示的なサポートを有することができる。

資金援助要求を受信すると、ＡＳは、ＷＴＲＵ１が別のユーザを資金援助することを承認されていることをチェックすることができる。このチェックの目的は、ユーザ体験を強化することである。一般に、この段階で手順を停止することは、その後にＷＴＲＵ２がアプリケーションセッションを開始する時点で手順が失敗するのにまかせるよりもユーザフレンドリーである場合がある。このチェックは、いくつかの方法で実行されることが可能である。

第１の選択肢（３３６）においては、ＵＤＲが使用されることが可能である。ＡＳは、資金援助に関連したＷＴＲＵ１プロファイル情報を求めてＵＤＲにクエリーを行って、ＷＴＲＵ１がＷＴＲＵ２を資金援助することを承認されていることを確認することができる。

第２の選択肢（３３８）においては、ＡＳは、資金援助に関連したＷＴＲＵ１プロファイル情報をＨＳＳから得ることができる。

図３Ｄに示されているように、第３の選択肢（３４０）においては、ＡＳは、ＰＣＲＦに事前承認を求めることができる。次いでＰＣＲＦは、ＳＰＲ／ＵＤＲからＷＴＲＵ１プロファイル情報を得ること、ＷＴＲＵ２を資金援助するための自分の承認をチェックすること、およびＡＳに応答することが可能である。これは、ＡＳとＲｘとの間におけるＰＣＲＦおよびＲｘ参照ポイントに対する変更（たとえば、新たなセッションを作成すること、または既存のセッションを修正することの代わりに、その後のセッションの事前承認を要求するためのＡＡＲメッセージに対する修正）を必要とする場合がある。

この資金援助されるイベントが承認されていることを確認するために、ＷＴＲＵ２のユーザプロファイルが使用されることも可能である。たとえば、資金援助されるイベントの最近の履歴は、ＷＴＲＵ２の資金援助される割当てが超過されていることを示すこと（そのような割当てがＡＳによって課されていると想定した場合）が可能である。

ＡＳは、このチェックをより早期に、たとえば、ＷＴＲＵ１がサービスにサインオンして、資金援助を可能にするようにアプリケーションアカウントを構成した時点で実行することができ、それによってＡＳは、この結果をキャッシュすることができる。ＡＳは、このチェックを省略することができ、その結果、ＷＴＲＵ２は、ＷＴＲＵ１がこのサービスに関してＷＴＲＵ２を資金援助することを承認されていない場合には、資金援助されるサービスを拒否される場合がある。

ＡＳは、いくつかの課金が関与している場合などに、ＷＴＲＵ１に確認を要求することができる（３４２）。ＷＴＲＵ１は、確認する前に最終的な課金を見直すことができる。これは、ＷＴＲＵ２が適切なＩＰ接続プランを有していない場合に必要とされることがあるあらゆる不測の追加料金を含むことができる。ＡＳは、ＷＴＲＵ１に確認を要求することができる。ＡＳは、その後の使用のために内部の被資金援助イベント記述子を作成することができる（３４４）。ＡＳは、ＷＴＲＵ１およびＷＴＲＵ２のアイデンティティー、トークン、トリガーＵＲＬ、アプリケーションレベル範囲、資金援助されるイベントを消費する上での有効期日、ならびに許可されたサービス持続時間のうちのすべてまたはいくつかをイベント記述子内に含めることができる。

ＡＳは、肯定的なまたは否定的な成功コードを用いてＷＴＲＵ１に応答することができる（３４６、３４８）。成功のケースにおいては、ＡＳは、トリガー（たとえば、資金援助されるイベントを識別するトークンを含む、資金援助されるコンテンツへのハイパーリンク）を、（たとえば、ショートメッセージサービス（ＳＭＳ）を使用して）ＷＴＲＵ２に提供することができる（３４６）。ＡＳは、この情報をＷＴＲＵ１への応答内に含めて提供することができ、ＷＴＲＵ１は、それを、たとえば近距離無線通信、ＳＭＳ、またはＥメールを使用して、ＷＴＲＵ２へ送信することができる（３４６）。

図３Ｅおよび図３Ｆは、ともに併せて、被資金援助セッション開始のための手順３５０のメッセージフロー図である。図３Ｅに示されているように、ＷＴＲＵ２は、たとえば、トークンを含むハイパーリンクをたどることによって、資金援助されるアプリケーションセッションを開始することができる（３５２）。資金援助されるアプリケーションセッションを開始しようという決断は、ＷＴＲＵ２のユーザによって開始されることが可能である（たとえば、資金援助されるショーを都合のよい時間に見ること）。ＷＴＲＵ１のユーザは、進行中のライブショーを共有するためにＷＴＲＵ２のユーザを資金援助することができる。ＷＴＲＵ２は、資金援助開始プロセスが完了されるとすぐにサービスを受信し始めることができる。資金援助されるアプリケーションは、ＡＳによって開始されることも可能である（たとえばＡＳは、資金援助されるライブショーが開始したときにＳＭＳをＷＴＲＵ２へ送信することができる）。ＷＴＲＵ２からアプリケーションセッション要求を受信すると、ＡＳは、たとえば、ＷＴＲＵ２によって使用されるサービスＵＲＬ内に含まれているトークンを使用して、このトークンを、ＡＳ上に格納されている被資金援助イベント記述子データ構造とマッチさせることによって、このセッションをその資金援助者とマッチさせることができる（３５４）。ＡＳは、進行する前に承認チェックを実行することができる。たとえば、承認チェックは、同じビデオショーを同時に資金援助しすぎることを防止することができ、資金援助機能の悪用を防止することができる。ＡＳは、ＱｏＳおよび課金のためにアプリケーションセッションを構成するためにＰＣＲＦと通信することができる（たとえば、Ｒｘを介したＡＡＲメッセージ）。たとえば、セッション識別子と、課金キーと、資金援助者アイデンティティーと、アプリケーションサービスプロバイダアイデンティティーと、資金援助に関連したその他のパラメータとを含むことができるＡＡＲメッセージが送信されることが可能である（３５６）。

ＰＣＲＦは、この資金援助されるイベントが承認されていること（たとえば、ＷＴＲＵ１のプロファイルが、この特定のサービスの資金援助を承認していること）を確実にするために、（ＳＰＲ／ＵＤＲから）資金援助者のプロファイルをチェックすることができる（３５８）。たとえば、ＷＴＲＵ２は、資金援助されることが可能であるＷＴＲＵのホワイトリストの一部であることが可能である。この同じテストのための入力としてＷＴＲＵ２プロファイルが使用されることも可能である（たとえば、ＷＴＲＵ２が、所与の期間内にあまりにも多くの回数にわたって資金援助されている場合には、資金援助されるイベントが承認されないことが可能であり、および／またはＷＴＲＵ２のデータプランが、必要とされているＱｏＳをサポートしていない場合には、ＷＴＲＵ１プロファイルは、追加料金が許容可能であるかどうかを示すことができる）。ＰＣＲＦは、ＰＣＥＦを通じてセッションを構成することができる。ＰＣＥＦは、ＯＣＳまたはＯＦＣＳなどの課金システムノードと、ＯＣＳへのＧｙインターフェースを介して、またはＯＦＣＳへのＧｚインターフェースを介して対話することができる。

ＰＣＲＦは、ＷＴＲＵ１およびＷＴＲＵ２プロファイルに、ならびにＡＳからの要求において提供される情報に基づいて、資金援助者に対するＷＴＲＵ１承認を評価することができる（３６０）。ＰＣＲＦは、現在のセッションに関する課金キーを含むＡＳに対する応答（たとえば、ＡＡ回答）を送信することができる（３６２）。

図３Ｆに示されているように、ＰＣＲＦは、セッションのフローを構成するＰＣＥＦに対する要求（たとえば、ルーティングエリア（ＲＡ）要求）を送信することができる（３６４）。ＰＣＥＦは、ＱｏＳルールをインストールまたは修正すること（３６６）、およびＰＣＲＦへ応答を送信すること（３６８）が可能である。ＰＣＥＦは、（この資金援助されるイベントに関してＷＴＲＵ２のための特定の課金キー、または別法として、アプリケーションサービスプロバイダアイデンティティーと資金援助者アイデンティティーとに関連付けられているＷＴＲＵ２のための課金キーを使用して、）課金キーに関連した課金情報を送信することができる（３７０）。資金援助されるイベントに関する課金は、ＷＴＲＵ１のサブスクライバーに請求するために後ほど使用されることが可能であり、またはＷＴＲＵ１のサブスクライバーの前払いから差し引かれることが可能である（３７２）。

複数のＷＴＲＵが同時にサポートされることが可能である。たとえば、イベントの主催者は、そのイベントに存在するすべてのユーザに向けたサービスを資金援助することができる。ＡＳは、グループ資金援助をサポートすることができる。すなわち、ＡＳは、複数のエンドユーザに関して有効なトークンを提供して処理することができる。たとえばＡＳは、最大で１，０００人のエンドユーザに関して有効なトークンを、彼らが、資金援助されるセッションを単一の有効期日中に開始する限り、発行することができる。さらに、そのトークンは、ＷＴＲＵ１（またはＡＳ）によってすべての受領者に提供されることが可能である。たとえば、ＷＴＲＵ１は、すべての意図されている受領者に複数のＳＭＳメッセージを送信することができ、または別法として、トークンをウェブまたはイントラネットページ上にポストすることができる。ＷＴＲＵ１のサブスクライバープロファイルは、グループ資金援助を有効にする／無効にするための、またはグループ資金援助に制限を課すための新たなＩＥを含むことができる。たとえば、グループ資金援助に関する受領者の最大数が含まれることが可能であり、および／またはグループ資金援助に関するコスト制限が有効にされることが可能である。これらの情報要素は、単一のアプリケーションの範囲を有すること、またはすべてのアプリケーションに関してグローバルであることが可能である。

転送可能なトークンがサポートされることも可能である。すなわち、トークンは、ＷＴＲＵ２からＷＴＲＵ３へ送信されることが可能である。次いでＷＴＲＵ３は、そのトークンを使用して、サービスを消費する。たとえば、ユーザが、資金援助されるサービスへのリンク（たとえば、ライブスポーツイベントへのアクセス）を友人に誕生日ギフトとして送信するが、この友人は、そのショーを見る時間がなく、そのリンクを自分の息子に転送しようと決める（その息子は、そのショーを自分自身のデバイス上で別のサブスクリプションのもとで見ることになる）。

図３Ａおよび図３Ｂに提示されているメッセージフローは、転送されるトークンに適用されることが可能である。トークンは、ＡＳにおいて転送可能または転送不能としてマークされることが可能である。たとえば、ＷＴＲＵ１は、宛先ＷＴＲＵ２アイデンティティーを「ＷＴＲＵ１サブスクライバーがＷＴＲＵ２の資金援助を開始する」要求内に含めて提供することによって、転送不能なトークンをＡＳに要求することができる。ＷＴＲＵ１は、ＷＴＲＵ２のアイデンティティーをその要求内に含めないことが可能である。ＡＳは、転送可能なトークンをＷＴＲＵ１に提供する前に、ＷＴＲＵ１がそれらのトークンを得ることを許可されているかどうかをチェックすることができる。ＷＴＲＵ２または別のＷＴＲＵ３が、転送されたトークンを使用してサービスにアクセスした場合には、ＡＳは、そのトークンを、資金援助されるセッションと照合し、ＷＴＲＵ１からのオリジナルの資金援助要求内でＷＴＲＵ２が明確に言及されていた場合には、ＷＴＲＵ３からの要求を拒否することができる。明確な指示がない場合には、資金援助されるサービスは、さらに進むことができる。

ＡＳは、資金援助のターゲットが特定されていないトークンを提供することができる（たとえば、ＡＳが一式の月極トークンをＷＴＲＵ１に提供する前述のケース）。このケースにおいては、ＡＳは、転送されるトークンと同様の方法で、ＷＴＲＵ２／ＷＴＲＵ３からのサービス要求を処理することができる。この状況においては、（アプリケーションごとの、および／またはコスト制限に関連付けられている）転送可能な資金援助を有効にすること／無効にすることを含めるために、さらなるサブスクライバープロファイルＩＥが利用されることが可能である。

上述の手順の部分的な適用が実行されることも可能である。たとえば、上述の手順のうちのより少ないステップが独立して実行されることが可能である。共有は、課金に焦点を合わせることなく生じることが可能であり、ユーザ資金援助は、予備的なやり取りの間に生じることが可能である。

課金に対する影響を伴わない共有に関しては、資金援助は、共有と置き換えられることが可能である。ＷＴＲＵ１は、（おそらくは、ＷＴＲＵ１のデバイス上で現在再生されているショーと同期化されている）ライブショーおよび／またはそのショーのストリーミングへのアクセスなど、サービスへのアクセスを可能にするためにＷＴＲＵ２にトークンを提供することができる。

トークンのやり取りは、上述のように生じることが可能である。ＷＴＲＵ２は、ＡＳとの間でのアプリケーションセッションを開始することができる。ＡＳは、トークンを共有トークンと解釈することができる。ＡＳは、ＰＣＲＦへ送信されるセッションセットアップメッセージ（たとえば、ＡＡＲ）内に資金援助者アイデンティティーを含めないことが可能である。アプリケーションセッションＱｏＳおよび課金は、上述のように処理されることが可能である。

条件付きの資金援助が生じることも可能である。条件付きの資金援助に関しては、ＷＴＲＵ１は、ＷＴＲＵ２、および必要な場合には資金援助者のみとセッションを共有したいと希望する。たとえば、ＷＴＲＵ２が既に、ＡＳによって提供されるサービスの月極サブスクライバーである場合には、典型的には、ＷＴＲＵ１がＷＴＲＵ２を資金援助する必要はない。条件付きの資金援助は、ＡＳにおいて（すなわち、アプリケーションレイヤにおいて）実施されることが可能である。アプリケーションは、ＷＴＲＵ２が既にサービスのサブスクライバーであるかどうか、およびＷＴＲＵ２がメンバーであるかどうかをチェックし、アプリケーションは、資金援助者アイデンティティーを、ＰＣＲＦに向けたセッションセットアップメッセージ（たとえばＤｉａｍｅｔｅｒ ＡＡＲ）内に含めて提供しないことが可能である。ＷＴＲＵ２がサブスクライバーではない場合には（またはＷＴＲＵ２のサブスクリプションが、ＷＴＲＵ１がＷＴＲＵ２と共有したいと望む特定のサービスを含んでいない場合には）、資金援助は、たとえば上述のフローに従って、進行することができる。

ユーザが予備的なやり取り（たとえば、統合されたアカウントのためのサポート）を伴わずに資金援助を行っている状況においては、ＡＳは、ＷＴＲＵ２がＷＴＲＵ１によって資金援助されていることを事前に知ることができる。たとえば、別々のサブスクリプションを有する何人かの家族が、単一のアカウントを使用して単一のサービスにアクセスしようと決める場合がある。そのような単一のアカウントは、これらの特定の他のユーザのためのすべてのサービスアクセスを資金援助するように構成されることが可能である。これをサポートするためには、ユーザサブスクライバープロファイルは、特定のパラメータ（たとえば、Ｙというコスト制限内で（または無限のコスト制限を伴って）アプリケーションＸに関する資金援助を行うためのＷＴＲＵのリスト）を含むことができる。

この説明の応用例は、一般的な、非３ＧＰＰ固有のコンテキストに関して提供されている。ＱｏＳおよび課金を提供する、およびサードパーティーアプリケーションプロバイダのための統合フックを提供するアクセスネットワークオペレータは、ユーザ資金援助および共有をサポートするように強化されることが可能である。

図４は、アプリケーションサービスプロバイダ４０５がアクセスプロバイダネットワーク４１０との間での契約を確立することができるアーキテクチャーコンテキスト４００を示している。この契約の一部として、アプリケーションサービスプロバイダ４０５は、アクセスプロバイダネットワーク４１０を介してサービスにアクセスするＷＴＲＵ（たとえば、ＷＴＲＵ１およびＷＴＲＵ２）のためのＱｏＳおよび課金を制御することができる。アプリケーションサービスプロバイダ４０５は、サブスクライバープロファイルの一部分にアクセスすることもできる。

図５Ａおよび図５Ｂは、ともに併せて、ユーザベースの資金援助を実施する手順５００のハイレベルメッセージフロー図である。

図５Ａに示されているように、第１のフェーズ（５０５）において、時刻ｔ０に（たとえば、サブスクリプション時に）、ＷＴＲＵ１サブスクライバープロファイルは、資金援助が承認されている（場合によっては、いくつかは制限を伴って、サービスごとに、ターゲットＷＴＲＵごとに、ソースＷＴＲＵごとになど）ことを示すように更新されることが可能である。この更新は、サブスクライバー（たとえば、ウェブサービスを通じて）、またはアクセスネットワークオペレータ（たとえば、契約に基づいて）によって入力されることが可能である。ＡＳおよび／またはサブスクライバープロファイルは、さらなる資金援助関連サービス設定（たとえば、同じコンテンツに対して同時に資金援助されるアクセスの最大数を保持することができる。

第２のフェーズ（５１０）において、時刻ｔ１に、ＷＴＲＵ１サブスクライバーがＷＴＲＵ２を資金援助したいと望む場合には、資金援助許可は、ＡＳを関与させることが可能である。ＷＴＲＵ１は、ＷＴＲＵ２からアイデンティティーおよび場合によっては承認を得ることができる（その代わりに、ＷＴＲＵ１は、ＷＴＲＵ２を関与させることなく、ＷＴＲＵ２のアイデンティティーを得ることもできる）（５１５）。ＷＴＲＵ１サブスクライバーは、ＷＴＲＵ２の資金援助を開始することができる（５２０）。ＡＳは、（ＱｏＳ／課金コントロールから、またはサブスクライバープロファイルから）ＷＴＲＵ１サブスクライバーがこの種類のオペレータを承認しているかどうかをチェックすることができる（５２５）。ＡＳは、サービストリガーをＷＴＲＵ２に提供することができ、またはＡＳは、トリガーをＷＴＲＵ１に提供することができ、ＷＴＲＵ１は、そのトリガーをＷＴＲＵ２に提供することができる（５３０）。代替の第２のフェーズ（５３５）において、時刻ｔ１に、ＷＴＲＵ１サブスクライバーがＷＴＲＵ２を資金援助したいと望む場合には、資金援助許可は、ＡＳを関与させないことが可能である。おそらくは事前に（たとえばサインアップ時に、または毎月）、ＷＴＲＵ１は、資金援助トークンを得ることができ、その資金援助トークンは、範囲／時間において制限されることが可能である（５４０）。ＷＴＲＵ１は、ＷＴＲＵ２へのトリガー（たとえば、トークンを含むＵＲＬ）を提供することを、おそらくはそうするための承認をＷＴＲＵ２に要求した後に行うことができる（５４５）。

図５Ｂに示されているように、第３のフェーズ（５５０）において、時刻ｔ２に、ＷＴＲＵ２サブスクライバーが、資金援助されるセッションを開始したいと望む場合には、ＷＴＲＵ２は、トリガー（たとえば、埋め込みトークンを伴うハイパーリンク）を使用して、資金援助されるセッションを開始することができる（５５５）。ＡＳは、（たとえばトークンを使用して）セッションを資金援助者とマッチさせることができる（５６０）。ＡＳは、ＱｏＳ／課金のためにセッションを構成することができる（５６５）。プロセスの一部として、ＡＳは、資金援助が許可されているかどうかを確認するために資金援助者（ＷＴＲＵ１サブスクライバー）のプロファイル情報をチェックすることができる。セッションを構成するためにＱｏＳ／課金コントロールが使用されることが可能である（５７０）。ＡＳは、ＷＴＲＵ２に応答して、サービスの配信を進めることができる（５７５）。

アプリケーションプロバイダは、ＷＴＲＵ１の代わりにＷＴＲＵ２を資金援助することができる。資金援助者は、３ＧＰＰ ＣＮの観点からは、アプリケーションプロバイダであると言える。ＷＴＲＵ１は、ＷＴＲＵ１の代わりにＷＴＲＵ２を資金援助するようＡＳをトリガーすることができる。ＨＳＳおよび／またはＳＰＲ／ＵＤＲ内のサブスクライバープロファイルは、（ＡＳが資金援助トークンを許可する前にチェックすることができる）資金援助関連構成を依然として含むことができ、および／またはＡＳは、この情報をすべて内部に格納することができる。

第１の例、すなわち、ユーザベースの資金援助においては、ＷＴＲＵは、固定された基準で課金されることが可能である。ＷＴＲＵ１は、ＡＳによって提供されるサービスのサブスクライバーとして、（典型的には、資金援助されるイベントの最大コスト制限または最大数内で）無料でまたは固定された追加サブスクリプション料金の一部として他のＷＴＲＵを資金援助する資格が与えられることが可能である。３ＧＰＰ ＣＮの観点からは、アプリケーションプロバイダは、ＷＴＲＵを資金援助することができる。内部では、ＡＳは、（たとえば、資金援助されるイベントのカウントおよび／またはサービスコストの合計を保持することによって、）資金援助に関する認められた制限内にＷＴＲＵ１がとどまることを確実にすることができる。

図６Ａおよび図６Ｂは、ともに併せて、アプリケーションプロバイダが別のＷＴＲＵの代わりにＷＴＲＵサービスを資金援助するための手順６００のハイレベルメッセージフロー図である。資金援助は、無料、または固定されたサブスクリプションパッケージの一部であるため、ＡＳは、資金援助されるセッションのコストがＷＴＲＵ１の請求書内に統合されることが可能であることを確実にすることを必要としないことが可能である。

図６Ａに示されているように、第１のフェーズ（６０５）において、時刻ｔ０に（たとえば、サブスクリプション時に）、ＨＳＳ／ＳＰＲ／ＵＤＲ上のＷＴＲＵ１サブスクライバープロファイルは、資金援助に関連したＩＥを投入されることが可能である。ＡＳ上のＷＴＲＵ１サブスクライバープロファイルが、そのようなＩＥを投入されることも可能である。

第２のフェーズ（６１０）において、時刻ｔ１に、ＷＴＲＵ１サブスクライバーがＷＴＲＵ２を資金援助したいと望む場合には、資金援助許可は、ＡＳを関与させることが可能である。ＷＴＲＵ１は、ＷＴＲＵ２からアイデンティティーおよび場合によっては承認を得ることができる（その代わりに、ＷＴＲＵ１は、ＷＴＲＵ２を関与させることなく、ＷＴＲＵ２のアイデンティティーを得ることもできる）（６１５）。ＷＴＲＵ１サブスクライバーは、ＷＴＲＵ２の資金援助を開始することができる（６２０）。ＡＳは、（ＡＳ内で、またはＰＣＲＦを通じてＵＤＲ、ＨＳＳ、もしくはＳＰＲから）ＷＴＲＵ１サブスクライバーがこの種類のオペレータを承認しているかどうかをチェックすることができる（６２５）。ＡＳは、サービストリガーをＷＴＲＵ２に提供することができ、またはＡＳは、トリガーをＷＴＲＵ１に提供することができ、ＷＴＲＵ１は、そのトリガーをＷＴＲＵ２に提供することができる（６３０）。代替の第２のフェーズ（６３５）において、時刻ｔ１に、ＷＴＲＵ１サブスクライバーがＷＴＲＵ２を資金援助したいと望む場合には、資金援助許可は、ＡＳを関与させないことが可能である。おそらくは事前に（たとえばサインアップ時に、または毎月）、ＷＴＲＵ１は、資金援助トークンを得ることができ、その資金援助トークンは、範囲／時間において制限されることが可能である（６４０）。ＷＴＲＵ１は、ＷＴＲＵ２へのトリガー（たとえば、トークンを含むＵＲＬ）を提供することを、おそらくはそうするための承認をＷＴＲＵ２に要求した後に行うことができる（６４５）。

図６Ｂに示されているように、第３のフェーズ（６５０）において、時刻ｔ２に、ＷＴＲＵ２サブスクライバーが、資金援助されるセッションを開始したいと望む場合には、ＷＴＲＵ２は、トリガー（たとえば、埋め込みトークンを伴うハイパーリンク）を使用して、資金援助されるセッションを開始することができる（６５５）。ＡＳは、（たとえばトークンを使用して）セッションを資金援助者とマッチさせることができる（６６０）。ＡＳは、ＷＴＲＵ１の内部のプロファイル内の（または別法として、ＨＳＳ／ＵＤＲ／ＳＰＲ内の）資金援助使用を更新することができる。ＡＳは、アプリケーションプロバイダを資金援助者として使用して（資金援助される接続に関する通常の手順に従って）ＰＣＲＦ（ＱｏＳ、課金）においてセッションを構成することができる（６６５）。ＡＳは、ＷＴＲＵ２に応答して、サービスの配信を進めることができる（６７０）。

資金援助者ＷＴＲＵは、資金援助されるセッションごとに課金されることが可能である。ＷＴＲＵ１のユーザは、固定された支払いの範囲外で他のＷＴＲＵを資金援助している。たとえば、各セッションのコストは、被資金援助者の使用の実効時間に基づく。さまざまな支払いモデルが使用されることが可能である（たとえばＷＴＲＵ１は、一定のコストまでは無料で他のＷＴＲＵを資金援助し、次いで超過使用に関しては支払いを行うことができる）。アプリケーションプロバイダは、（３ＧＰＰ ＣＮの観点からは）実質的にセッションを資金援助している。したがってＡＳは、何らかの種類の課金イベントを使用して、課金をＷＴＲＵ１のサブスクライバーへ向け直すことが必要である。これらの課金イベントは、ＰＣＥＦを通る実際のセッションには関連しておらず、代わりに１回限りのコスト（単発のイベント）を示すか、または時間ベースの課金イベントの開始もしくは終了を示す。

課金イベントの実施態様の一例においては、Ｒｘインターフェースは、課金イベントがＡＳによってＰＣＲＦへ送信されることを可能にする（たとえば、ＸＸＸ、サービスのコストをＷＴＲＵ１に課金する）ように強化されることが可能である。課金イベントは、ＰＣＲＦおよびＰＣＥＦを通じて課金サーバへ伝達されることが可能である。より詳細には、新たな「Ｃｈａｒｇｉｎｇ−Ｅｖｅｎｔ−Ｔｙｐｅ」属性値ペア（ＡＶＰ）タイプが定義されて、「１回限り」、「開始」、および「停止」などの値を有することが可能である。このＡＶＰは、課金イベントを表すために（ＡＳからＰＣＲＦへの）ＡＡ要求コマンドにおいて使用されることが可能である。セッションＩＤ値またはレンジは、課金イベントタイプに関連させるために確保されることが可能である（すなわち、このセッションＩＤが実際のセッションに関連することはない）。

ＡＳは、オフライン課金システムおよび／またはオンライン課金システムとの間での直接相互接続を有することができる。サードパーティーＡＳと課金システムとの間におけるこれらの新たなインターフェースは、課金トリガー機能（ＡＳ）とオンライン課金機能との間におけるＲｏ、および課金トリガー機能（ＡＳ）とオフライン課金機能との間におけるＲｆを含む参照ポイントに基づくことが可能である。

ＡＳは、課金ゲートウェイを通じて課金システムと相互接続することができる。この課金ゲートウェイは、課金機能への参照ポイントに対する課金トリガー機能の役割を有することができる。ＡＳと課金ゲートウェイとの間において、参照ポイントが導入されることが可能である。この参照ポイントは、Ｒｏ、Ｒｆ、またはこれらの参照ポイントの機能のサブセットを実施することができる。

図７Ａ、図７Ｂ、および図７Ｃは、課金イベントがサードパーティーＡＳによって３ＧＰＰ ＣＮへ送信されることを可能にすることのアーキテクチャー図を示している。

図７Ａにおいては、強化されたＲｘインターフェース７０５が、１回限りの課金コマンドなどの課金イベントがＡＳ７１０によってＰＣＲＦ７１５へ送信されることを可能にすることができる。

図７Ｂにおいては、オンライン課金機能（ＯＣＦ）７２０、および／または、課金データ機能（ＣＤＦ）７２５などのオフライン課金機能への直接相互接続が、ＡＳ７３０によって課金イベントを送信するために使用されることが可能である。

図７Ｃにおいては、課金ゲートウェイ７４５を通じたＯＣＦ７３５および／またはＣＤＦ７４０への間接相互接続が、ＡＳ７５０によって課金イベントを送信するために使用されることが可能である。

図８Ａおよび図８Ｂは、ともに併せて、ユーザ資金援助のための手順８００のハイレベルメッセージフロー図である。ＡＳは、典型的には、資金援助許可がＡＳ部分を関与させる場合にはＷＴＲＵ１の承認をチェックするためにＰＣＲＦと対話しないことが可能である。コラボレーティブケースにおいては、ローミング状況において同じＭＮＯを伴って、ＷＴＲＵ１およびＷＴＲＵ２は、同じＭＮＯ Ｙに関するサブスクライバーであることを可能にされ得る。ＡＰ Ｘは、ＭＮＯ Ｙとの間での契約を有することができる。ＷＴＲＵ２は、ＭＮＯ Ｗにおいてローミングしていることが可能である。ＭＮＯ Ｗは、ユーザに対して追加コストでＭＮＯ Ｙサブスクライバーのための優先トラフィック処理を提供するためにＭＮＯ Ｙとの間でのローミング契約を有することができる。

図８Ａに示されているように、ＨＳＳ／ＳＰＲ／ＵＤＲ上のＷＴＲＵ１サブスクライバープロファイルは、資金援助に関連したＩＥを投入されることが可能である。ＡＳ上のＷＴＲＵ１サブスクライバープロファイルが、そのようなＩＥを投入されることも可能である（８０５）。

資金援助許可がＡＳを関与させる場合（８１０）には、ＷＴＲＵ１は、ＷＴＲＵ２からアイデンティティーおよび承認を得ることができ、またはＷＴＲＵ２を関与させることなく、ＷＴＲＵ２のアイデンティティーを得ることもできる（８１５）。ＷＴＲＵ２のユーザ資金援助が、ＷＴＲＵ１によってＡＳに対して開始されることが可能である（サービス資金援助タイプパラメータまたは接続資金援助タイプパラメータのうちの少なくとも１つ）（８２０）。ＡＳは、（ＨＳＳ、ＳＰＲ、またはＵＤＲから）ＷＴＲＵ１サブスクライバーがユーザ資金援助オペレーションを承認しているかどうかをチェックすることができる（８２５）。ＡＳは、サービストリガーをＷＴＲＵ２に提供することができ、またはＡＳは、サービストリガーをＷＴＲＵ１に提供することができ、ＷＴＲＵ１は、そのトリガーをＷＴＲＵ２に提供する（８３０）。

資金援助許可がＡＳを関与させない場合（８３５）には、（おそらくは事前に、たとえばサインアップ時に、または毎月）、ＷＴＲＵ１は、資金援助トークンを得ることができ、その資金援助トークンは、範囲／時間において制限されることが可能である（およびサービスまたは接続のうちの少なくとも１つの中からの資金援助タイプに関連付けられることが可能である）（８４０）。ＷＴＲＵ１は、ＷＴＲＵ２へのトリガー（たとえば、トークンを含むＵＲＬ）を提供することを、おそらくはそうするための承認をＷＴＲＵ２に要求した後に行うことができる（８４５）。

図８Ｂに示されているように、ＷＴＲＵ２は、トリガー（たとえば、埋め込みトークンを伴うハイパーリンク）を使用して、資金援助されるセッションを開始することができる（８５０）。ＡＳは、（たとえばトークンを使用して）セッションを資金援助者とマッチさせることができ、ＡＳは、ＡＳにおけるＷＴＲＵ１のプロファイル内の、またはＨＳＳ、ＵＤＲ、もしくはＳＰＲ内の資金援助使用を更新することができ、ＡＳは、ＷＴＲＵ１に固有の課金キーを選択することができる（８５５）。ＡＳは、（たとえば、オフライン課金のための強化されたアカウンティングレコードメッセージ、またはオンライン課金のための強化されたクレジットコントロール要求を送信することによって）課金システム（ＯＣＳまたはＯＦＣＳ）と対話することができる（８６０）。サービスコストが（ＷＴＲＵ１のユーザがサービスを資金援助することを選択した場合には）ＷＴＲＵ１に、またはそうでなければＷＴＲＵ２に課金されることを確実にするために、（現在または後ほどセッション中またはセッション後に生じる）イベントベースの対話、またはセッションベースの対話が使用されることが可能である。ＷＴＲＵ１が接続を資金援助することを選択した場合には、ＡＳは、（サービス課金とともに、または別に）Ｍｏ／Ｍｆ参照ポイントを介してＷＴＲＵ１に課金することができる（８６０）。ＡＳは、ＷＴＲＵ１のユーザが接続を資金援助することを選択した場合にはアプリケーションプロバイダを資金援助者として使用して、（このケースにおいては、資金援助される接続に関する通常の手順に従って、）Ｒｘインターフェースを介して、ＰＣＲＦ（ＱｏＳ、およびおそらくは課金キー）においてセッションをセットアップすることができる（８６５）。ＰＣＲＦは、ＰＣＣルールをＰＣＥＦにダウンロードすることができ、ＰＣＥＦは、課金サブシステムと通信することができる。ＡＳは、ＷＴＲＵ２に応答して、サービスの配信を進めることができる（８７０）。

図９は、アプリケーションのコンテキストに関するネットワークアーキテクチャー９００を示している。ＷＴＲＵ１は、以降で説明されているソリューションに影響を与えることなく、ホームネットワークにおいて、または別のＰＬＭＮにおいて表されることが可能である。なぜなら、ＷＴＲＵ１の関与は、アプリケーションレイヤにおいて存在することが可能であるためである。ＷＴＲＵ２は、ＰＬＭＮ Ｗにおいてローミングしていることが可能である。図９は、ホームに回送されるローミングアーキテクチャーを示しており、それによって、データトラフィックは、ホームネットワークを通じてＷＴＲＵ２へ／ＷＴＲＵ２から回送されることが可能である。

図１０は、さらなるコンテキストに関するネットワークアーキテクチャー１０００を示している。ＷＴＲＵ１は、以降で説明されているソリューションに影響を与えることなく、ホームネットワークにおいて、または別のＰＬＭＮにおいて表されることが可能である。なぜなら、ＷＴＲＵ２の関与は、アプリケーションレイヤにおいて存在することが可能であるためである。ＷＴＲＵ２のＷＴＲＵ２は、ＰＬＭＮ Ｗにおいてローミングしている。図１０は、ローカルブレイクアウトローミングアーキテクチャーを示しており、それによって、ＷＴＲＵ２への／ＷＴＲＵ２からのデータトラフィックは、訪問されたネットワークＰＧＷにおいてブレイクアウトしていることが可能になる。

ＷＴＲＵ１は、アプリケーションサービスまたは優先トラフィック処理のうちの少なくとも１つを資金援助することができる。サービスのユーザ資金援助に関しては、ＡＳは、ＷＴＲＵ１に課金するためにＭＮＯ ＹとともにＭｏ／Ｍｆを使用することができる。ＷＴＲＵ１がＷＴＲＵ２のための優先トラフィック処理を資金援助する場合には、ＡＰ Ｘは、ＭＮＯ Ｙとの間での自分のＲｘ相互接続を介して優先トラフィック処理を要求することができる。ＡＰ Ｘは、Ｒｘを介した要求内にＷＴＲＵ１のアイデンティティーを資金援助者アイデンティティーとして挿入することができる。ＰＣＲＦ Ｙは、ＷＴＲＵ１がＷＴＲＵ２を資金援助することを承認されていることを確実にするためにチェックを実行することができ、次いでＰＣＲＦ Ｙは、ＰＣＲＦ Ｗを通じてリソースを要求するためにＳ９を使用する。

ＷＴＲＵ１のサブスクライバーアイデンティティー（ＩＤ）がＲｘを介して資金援助者として設定されることが可能であるローミングケースが存在することが可能である。ローカルブレイクアウトケースにおいては、ＰＣＲＦ Ｙは、Ｓ９を介したメッセージ内に資金援助者アイデンティティーを挿入することが可能である。ＰＣＲＦ Ｗは、（資金援助者アイデンティティーも含む）ＰＤＮ ＧＷ Ｗ内のＰＣＣルール、およびＱｏＳルールをアクセスノードにダウンロードすることができる。ＰＤＮ ＧＷ Ｗは、資金援助者に課金することができる（すなわち、ユーザアイデンティティーとしてＷＴＲＵ２を使用しながらも、ＷＴＲＵ１が資金援助者である旨に言及する課金関連メッセージを送信するか、または、ユーザアイデンティティーとしてＷＴＲＵ１を使用して、おそらくは、ＷＴＲＵ２が被資金援助者である旨に言及する課金関連メッセージを送信する）。最後に、ＷＴＲＵ１は、既に配置されているローミング課金の仕組みを通じて課金されることが可能である。ホームに回送されるケースにおいては、ＰＣＲＦ Ｙは、Ｓ９を介したメッセージ内に資金援助者アイデンティティーを挿入すること、または挿入しないことが可能である。ＰＣＲＦ Ｗは、それが存在している場合には、それを無視することができる。ＰＣＲＦは、ＱｏＳルールをアクセスノードにダウンロードすることができる。ホームネットワークにおいては、ＰＤＮ ＧＷ Ｙは、資金援助者に課金することができる（すなわち、ユーザアイデンティティーとしてＷＴＲＵ２を使用しながらも、ＷＴＲＵ１が資金援助者である旨に言及する課金関連メッセージを送信するか、または、ユーザアイデンティティーとしてＷＴＲＵ１を使用して、おそらくは、ＷＴＲＵ２が被資金援助者である旨に言及する課金関連メッセージを送信する）。最後に、ＷＴＲＵ１は、既に配置されているローミング課金の仕組みを通じて課金されることが可能である。

図１１Ａおよび図１１Ｂは、ともに併せて、同じＭＮＯおよびローミングを伴うローカルブレイクアウトコラボレーティブケースに関する手順１１００のハイレベルメッセージフロー図である。結果として、ＷＴＲＵ１は、ＯＣＳ／ＯＦＣＳ Ｙを通じてサービスに関して１回、および、ちょうどまるでＷＴＲＵ１がＭＮＯ ＷにおいてローミングしていたかのようにＭＮＯ Ｗを通じて接続（すなわち、優先トラフィック処理）に関して１回、課金されることが可能である。

図１１Ａに示されているように、ＷＴＲＵ１のユーザは、ＷＴＲＵ２のユーザ資金援助（サービスまたは接続のうちの少なくとも１つ）を開始することができ、それによってＷＴＲＵ２は、（非ローミングケースと同様に）サービストリガーを得ることができる（１１０５）。ＷＴＲＵ２は、トリガー（たとえば、埋め込みトークンを伴うハイパーリンク）を使用して、資金援助されるセッションを開始することができる（１１１０）。ＡＳは、（たとえばトークンを使用して）セッションを資金援助者とマッチさせることができ、ＡＳにおけるＷＴＲＵ１のプロファイル内の、またはＨＳＳ、ＵＤＲ、もしくはＳＰＲ内の資金援助使用を更新することができ、ＡＳは、ＷＴＲＵ１に固有の課金キーを選択することができる（１１１５）。ＡＳは、（ＷＴＲＵ１のユーザの資金援助者アイデンティティーを含めて）Ｒｘインターフェースを介してサービスセッショントラフィックのための優先トラフィック処理をセットアップすることができる（１１２０）。ＰＣＲＦは、ユーザ資金援助承認のためにＷＴＲＵ１のサブスクライバープロファイルをチェックすることができ、インターネットプロトコル接続アクセスネットワーク（ＩＰ−ＣＡＮ）セッション修正手順の一部としてＷＴＲＵ２のサブスクライバープロファイルをチェックすることができる（１１２５）。オンラインケースにおいては、ＰＣＲＦは、ユーザ資金援助のためにＷＴＲＵ１のクレジット残高をチェックする目的でＳｙインターフェースを使用することができる。ＷＴＲＵ２はローミングしていることが可能であるため、ＰＣＲＦ Ｙは、ＩＰ−ＣＡＮセッション修正要求をＰＣＲＦへ通信するためにＳ９を使用することができる（ＷＴＲＵ２は、ユーザであることが可能であり、資金援助者アイデンティティーは、ＷＴＲＵ１のユーザであることが可能である）（１１３０）。

図１１Ｂに示されているように、非ローミングケースとまったく同様に、セッションの前、最中、および／または後に、ＡＳは、ＷＴＲＵ１のユーザがサービスを資金援助することを選択した場合には、ＷＴＲＵ２のサービスアクセスに関してＷＴＲＵ１に課金することができる（１１３５）。ＰＣＲＦ Ｗは、ＷＴＲＵ１のユーザの資金援助者アイデンティティーを含むＰＣＣルールをＰＤＮ ＧＷ Ｗにダウンロードすることができ、ＱｏＳルールをアクセスノードＷにダウンロードすることもできる（１１４０）。ＷＴＲＵ２は、優先トラフィック処理を用いてサービスへのアクセスを得ることができる（１１４５）。ＰＧＷ Ｗは、Ｒｏ／Ｒｆインターフェースを介してＯＣＳ／ＯＦＣＳへ課金情報を通信することができ、ＷＴＲＵ１は、セッションの資金援助者として指定されることが可能である（１１５０）。オンライン課金ケースにおいては、ＰＧＷ Ｗは代わりに、ＯＣＳ Ｗの代わりに直接ＯＣＳ Ｙと通信することができる。ローミング契約によって、ＭＮＯ ＷおよびＭＮＯ Ｙ課金システムは通信を行うことができる（たとえば、ＭＮＯ Ｗは、オンラインケースにおいてはＷＴＲＵ１のクレジットをチェックして確保することができ、ＭＮＯ Ｗは、オフラインケースにおいてはＣＤＲをＭＮＯ Ｙに提供することができる）（１１５５）。

図１２Ａおよび図１２Ｂは、ともに併せて、同じＭＮＯおよびローミングを伴う、ホームに回送されるコラボレーティブケースに関する手順１２００のハイレベルメッセージフロー図である。結果として、ＷＴＲＵ１は、ＯＣＳ／ＯＦＣＳ Ｙを通じてサービスに関して１回、および、ちょうどまるでＷＴＲＵ１がＭＮＯ ＷにおいてローミングしていたかのようにＭＮＯ Ｗを通じて接続（すなわち、優先トラフィック処理）に関して１回、課金されることが可能である。

図１２Ａに示されているように、ＷＴＲＵ１のユーザは、ＷＴＲＵ２のユーザの資金援助（サービスまたは接続のうちの少なくとも１つ）を開始することができ、ＷＴＲＵ２は、（非ローミングケースと同様に）サービストリガーを得ることができる（１２０５）。ＷＴＲＵ２は、トリガー（たとえば、埋め込みトークンを伴うハイパーリンク）を使用して、資金援助されるセッションを開始することができる（１２１０）。ＡＳは、（たとえばトークンを使用して）セッションを資金援助者とマッチさせることができ、ＡＳにおけるＷＴＲＵ１のプロファイル内の、またはＨＳＳ、ＵＤＲ、もしくはＳＰＲ内の資金援助使用を更新することができる（１２１５）。ＡＳは、ＷＴＲＵ１に固有の課金キーを選択することができる。ＡＳは、（ＷＴＲＵ１のユーザの資金援助者アイデンティティーを含めて）Ｒｘインターフェースを介してサービスセッショントラフィックのための優先トラフィック処理をセットアップすることができる（１２２０）。ＰＣＲＦは、ユーザ資金援助承認のためにＷＴＲＵ１のサブスクライバープロファイルを、およびＩＰ−ＣＡＮセッション修正手順の一部としてＷＴＲＵ２のサブスクライバープロファイルをチェックすることができる（１２２５）。オンラインケースにおいては、ＰＣＲＦは、ユーザ資金援助のためにＷＴＲＵ１のクレジット残高をチェックする目的でＳｙインターフェースを使用することができる。ＷＴＲＵ２はローミングしているため、ＰＣＲＦ Ｙは、ＩＰ−ＣＡＮセッション修正要求をＰＣＲＦ Ｗへ通信するために（たとえば、ＱｏＳルールをＰＣＲＦ Ｗへプッシュするために、この場合、ＷＴＲＵ２はユーザであり、資金援助者アイデンティティーはＷＴＲＵ１のユーザである）、Ｓ９を使用することができる（１２３０）。

図１２Ｂに示されているように、ＰＣＲＦ Ｗは、（ＷＴＲＵ１の資金援助者アイデンティティーを含めて）ＰＣＣルールをＰＧＷ Ｙにダウンロードすることができる（１２３５）。ＰＣＲＦ Ｗは、ＱｏＳルールをアクセスノードＷにダウンロードすることができる（１２４０）。非ローミングケースとまったく同様に、セッションの前、最中、および／または後に、ＡＳは、ＷＴＲＵ１がサービスを資金援助することを選択した場合には、ＷＴＲＵ２のサービスアクセスに関してＷＴＲＵ１に課金することができる（１２４５）。ＷＴＲＵ２は、優先トラフィック処理を用いてサービスへのアクセスを得ることができる（１２５０）。ＰＧＷ Ｙは、Ｒｏ／Ｒｆインターフェースを介してＯＣＳ／ＯＦＣＳへ課金情報を通信することができ、その場合、ＷＴＲＵ１は、セッションの資金援助者として指定される（１２５５）。

ＡＰ Ｘは、Ｒｘインターフェースを介して資金援助者として設定されることが可能である。ＡＰ Ｘは、資金援助者に言及するすべてのメッセージにおいて資金援助者としてＷＴＲＵ１の代わりに使用されることが可能である。したがってＡＰ Ｘは、関連したコストに関してＭＮＯ Ｙによって課金されることが可能である。加えて、ＡＳ Ｘは、優先トラフィック処理のコストを反映するために、Ｍｏ／Ｍｆを介してＷＴＲＵ１に課金することができる。

ＷＴＲＵ１およびＷＴＲＵ２は、別々のＭＮＯ（それぞれ、ＭＮＯ ＹおよびＭＮＯ Ｚ）のサブスクライバーであることが可能である。ＡＰ Ｘは、ＭＮＯ Ｙとの間での契約を有することができる。ＷＴＲＵ２は、自分のホームネットワーク内に存在していることが可能であり、またはローミングしていることが可能である。ＷＴＲＵ１は、サービスのみ、接続のみ、または両方を資金援助することを選択することができる。

非ローミング状況においては、ＷＴＲＵ２は、自分のホームネットワークＺ内に存在している。ＷＴＲＵ１がサービスアクセスに関してＷＴＲＵ２を資金援助する場合には、ＡＳ Ｘは、Ｍｏ／Ｍｆを介してＷＴＲＵ１に課金することができる。ＷＴＲＵ２は、別のＭＮＯのサブスクライバーである。ＷＴＲＵ１が接続（すなわち、優先トラフィック処理）に関してＷＴＲＵ２を資金援助する場合には、ＡＰ Ｘは、ＰＣＲＦ Ｙを通じてＭＮＯ Ｚ上のネットワークリソースを確保するためにＲｘを使用することができる。ＰＣＲＦ Ｙは、ＷＴＲＵ１がＷＴＲＵ２を資金援助することを承認されていることを確認することができる。ＰＣＲＦ Ｙは、メッセージをＰＣＲＦ Ｚへ転送するためにＳ９を使用することができ、ＰＣＲＦ Ｚは、リソースを効果的に確保すること（たとえば、ＰＣＣルールをＰＤＮ ＧＷ Ｚ内に、ＱｏＳルールをアクセスネットワークＺノード内にダウンロードすること）が可能である。ＰＤＮ ＧＷ Ｚは、ユーザとしてＷＴＲＵ２を、および資金援助者としてＷＴＲＵ１を使用して、ＭＮＯ Ｚの課金サブシステムとの間で課金情報を通信することができる。最後に、ＷＴＲＵ１は、ローミング契約と同様に、ＭＮＯ ＺとＭＮＯ Ｙとの間における契約を通じて課金されることが可能である。この契約は、実質的には、通常のローミング契約のマイナーな拡張と見なされることが可能であり、この場合、ＭＮＯ Ｚは、ＭＮＯ Ｙのサブスクライバーであるユーザ資金援助者の代わりにユーザのためのリソースを確保することに同意している。

図１３は、別々のＭＮＯを伴う非ローミングコラボレーティブケースに関する手順１３００のハイレベルメッセージフロー図を示している。図１３に示されていないが、それぞれのＰＬＭＮ（ＹおよびＺ）は、対応するＰＣＲＦ（ＹおよびＺ）ならびにアクセスノード（ＹおよびＺ）を含むことができる。ＡＳ Ｘは、サービスに関してＷＴＲＵ１に課金するために、およびＰＬＭＮ Ｚ上のネットワークリソースを確保するために、ＰＬＭＮ Ｙとの間での自分のサービスコラボレーションを使用することができる。あるいは、ＡＰ Ｘは、ＭＮＯ Ｚとの間でのビジネス関係契約を有することができる。ＷＴＲＵ１が接続に関してＷＴＲＵ２を資金援助する場合には、ＡＳ Ｘは、ＰＣＲＦ Ｚを通じてＭＮＯ Ｚ上のネットワークリソースを直接確保するためにＲｘを使用することができる。このケースにおいては、このステップに先立って、ＡＰ Ｘは、Ｍｈを介してＷＴＲＵ１のサブスクライバープロファイルにアクセスすることによってＷＴＲＵ２を資金援助するためのＷＴＲＵ１承認を確認することができる。

図１３に示されているように、ＷＴＲＵ１は、ＷＴＲＵ２のユーザ資金援助を要求し、トリガー（サービス資金援助タイプサービスまたは接続資金援助タイプのうちの少なくとも１つ）を得ることができる（１３０５）。ＡＳは、ＷＴＲＵ１のユーザがＷＴＲＵ２のユーザを資金援助することを承認されていることを確認することができる（１３１０）。ＷＴＲＵ１は、ユーザ資金援助トリガーをＷＴＲＵ２へ転送することができる（１３１５）。ＷＴＲＵ２は、ＡＳトリガーを使用して、サービスにアクセスすることができる（１３２０）。ＡＳは、（Ｍｏ／Ｍｆを介して）サービスアクセスに関してＷＴＲＵ１のユーザに課金することができる（１３２５）。ＡＳは、Ｒｘを介してリソースを確保することができる（その場合、ユーザはＷＴＲＵ２であり、資金援助者はＷＴＲＵ１である）（１３３０）。ＰＣＲＦ Ｙは、ＷＴＲＵ１に関する承認を確認することができる（１３３５）。ＰＣＲＦ Ｙは、Ｓ９を介してリソースを確保することができる（ユーザはＷＴＲＵ２であり、資金援助者はＷＴＲＵ１である）（１３４０）。ＰＣＲＦ Ｚは、ＷＴＲＵ２に関する承認を確認することができる（１３４５）。ＰＣＲＦ Ｚは、リソースを許可して、ＰＧＷ ＺおよびアクセスノードＺとのセッションをセットアップすることができる（１３５０）。次いでＰＬＭＮ Ｚは、応答をＰＬＭＮ Ｙへ送信することができ（１３５５）、次いでＰＬＭＮ Ｙは、応答をＡＳ Ｘへ送信することができる（１３６０）。ＷＴＲＵ２のセッションは進行することができる（１３６５）。ＷＴＲＵ１は、ローミングのような契約（roaming-like agreement）を通じてＷＴＲＵ２の接続に関して課金されることが可能である（１３７０）。

図１４は、別々のＭＮＯを伴う非ローミングコラボレーティブケースに関する手順１４００のハイレベルメッセージフロー図を示している。図１４に示されていないが、それぞれのＰＬＭＮ（ＹおよびＺ）は、対応するＰＣＲＦ（ＹおよびＺ）ならびにアクセスノード（ＹおよびＺ）を含むことができる。ＡＳ Ｘは、サービスに関してＷＴＲＵ１に課金するためにＰＬＭＮ Ｙとの間での自分のサービスコラボレーションを、およびＰＬＭＮ Ｚ上のネットワークリソースを確保するためにＰＬＭＮ Ｚとの間での自分のビジネス関係を使用することができる。

図１４に示されているように、ＷＴＲＵ１は、ＷＴＲＵ２のユーザ資金援助を要求し、トリガー（サービス資金援助タイプサービスまたは接続資金援助タイプのうちの少なくとも１つ）を得ることができる（１４０５）。ＡＳは、ＷＴＲＵ１のユーザがＷＴＲＵ２のユーザを資金援助することを承認されていることを確認することができる（１４１０）。ＷＴＲＵ１は、ユーザ資金援助トリガーをＷＴＲＵ２へ転送することができる（１４１５）。ＷＴＲＵ２は、ＡＳトリガーを使用して、サービスにアクセスすることができる（１４２０）。ＡＳは、（Ｍｏ／Ｍｆを介して）サービスアクセスに関してＷＴＲＵ１のユーザに課金することができる（１４２５）。ＡＳは、Ｒｘを介してリソースを確保することができる（その場合、ユーザはＷＴＲＵ２であり、資金援助者はＷＴＲＵ１である）（１４３０）。ＰＣＲＦ Ｚは、リソースを許可して、ＰＧＷ ＺおよびアクセスノードＺとのセッションをセットアップすることができる（１４３５）。ＰＬＭＮ Ｚは、応答メッセージをＡＳ Ｘへ送信することができる（１４４０）。ＷＴＲＵ２のセッションは進行することができる（１４４５）。ＷＴＲＵ１は、ローミングのような契約を通じてＷＴＲＵ２の接続に関して課金されることが可能である（１４５０）。

ＷＴＲＵ２は、ネットワークＷにおいてローミングすることが可能である。それらの仕組みは、非ローミングケースと同様であり、主として異なるのは、ＰＣＲＦ ＺがＰＬＭＮ Ｗにおいてネットワークリソースを確保するためにＳ９を使用することができるという点である。ＷＴＲＵ１は、非ローミングケースにおけるのと同様に、ローミングのような契約を通じてＷＴＲＵ２の接続に関して課金されることが可能であるが、このケースにおいては、それは、ＭＮＯ ＷとＭＮＯ Ｙとの間における契約である。資金援助者としてＷＴＲＵ１を伴う、ユーザの資金援助される要求を受信した場合には、ＰＣＲＦ Ｗは、そのような契約が存在することを確認することができ、またはそうでない場合には、その資金援助される要求を拒否することができる。

図１５は、別々のＭＮＯを伴うローミングコラボレーティブケースに関する手順１５００のハイレベルメッセージフロー図を示している。図１５に示されていないが、それぞれのＰＬＭＮ（Ｗ、Ｙ、およびＺ）は、対応するＰＣＲＦ（Ｗ、Ｙ、およびＺ）ならびにアクセスノード（Ｗ、Ｙ、およびＺ）を含むことができる。図１５に示されているように、ＷＴＲＵ１は、ＷＴＲＵ２のユーザ資金援助を要求し、トリガー（サービス資金援助タイプサービスまたは接続資金援助タイプのうちの少なくとも１つ）を得ることができる（１５０５）。ＡＳは、ＷＴＲＵ１のユーザがＷＴＲＵ２のユーザを資金援助することを承認されていることを確認することができる（１５１０）。ＷＴＲＵ１は、ユーザ資金援助トリガーをＷＴＲＵ２へ転送することができる（１５１５）。ＷＴＲＵ２は、ＡＳトリガーを使用して、サービスにアクセスすることができる（１５２０）。ＡＳは、（Ｍｏ／Ｍｆを介して）サービスアクセスに関してＷＴＲＵ１のユーザに課金することができる（１５２５）。ＡＳは、Ｒｘを介してリソースを確保することができる（その場合、ユーザはＷＴＲＵ２であり、資金援助者はＷＴＲＵ１である）（１５３０）。ＰＣＲＦ Ｙは、ＷＴＲＵ１に関する承認を確認することができる（１５３５）。ＰＣＲＦ Ｙは、Ｓ９を介してリソースを確保することができる（ユーザはＷＴＲＵ２であり、資金援助者はＷＴＲＵ１である）（１５４０）。ＰＣＲＦ Ｚは、Ｓ９を介してリソースを確保することができる（ユーザはＷＴＲＵ２であり、資金援助者はＷＴＲＵ１である）（１５４５）。ＰＣＲＦ ＺおよびＷは、ＰＧＷ Ｚ（ホームに回送されるアクセスのケース）またはＰＧＷ Ｗ（訪問されるアクセスのケース）およびアクセスノードＷを関与させる、ホームに回送されるまたは訪問されるアクセスの手順に従って、リソースを許可することができる（１５５０）。ＰＬＭＮ Ｗは、ＷＴＲＵ１のユーザ資金援助に関してＰＬＭＮ Ｙから承認を受信することができる。応答メッセージ１５５５が、ＰＬＭＮ ＷからＰＬＭＮ Ｚへ、ＰＬＭＮ Ｙへ、ＡＳ Ｘに転送して戻されることが可能である。ＷＴＲＵ２のセッションは進行することができる（１５６０）。ＷＴＲＵ１は、ＷとＹとの間におけるローミングのような契約を通じてＷＴＲＵ２の接続に関して課金されることが可能である（１５６５）。

図１６は、別々のＭＮＯを伴うローミングコラボレーティブケースに関する手順１６００のハイレベルメッセージフロー図を示している。図１６に示されていないが、それぞれのＰＬＭＮ（Ｗ、Ｙ、およびＺ）は、対応するＰＣＲＦ（Ｗ、Ｙ、およびＺ）ならびにアクセスノード（Ｗ、Ｙ、およびＺ）を含むことができる。図１５によって示されているシナリオとは異なり、このシナリオにおいては、ビジネス関係が、ＡＳ ＸとＰＬＭＮ Ｚとの間において存在することが可能であり、ＡＸ Ｘがネットワークリソースを要求するためにＰＬＭＮ Ｚと直接対話することを可能にする。図１６に示されているように、ＷＴＲＵ１は、ＷＴＲＵ２のユーザ資金援助を要求し、トリガー（サービス資金援助タイプサービスまたは接続資金援助タイプのうちの少なくとも１つ）を得ることができる（１６０５）。ＡＳは、ＷＴＲＵ１のユーザがＷＴＲＵ２のユーザを資金援助することを承認されていることを確認することができる（１６１０）。ＷＴＲＵ１は、ユーザ資金援助トリガーをＷＴＲＵ２へ転送することができる（１６１５）。ＷＴＲＵ２は、ＡＳトリガーを使用して、サービスにアクセスすることができる（１６２０）。ＡＳは、（Ｍｏ／Ｍｆを介して）サービスアクセスに関してＷＴＲＵ１のユーザに課金することができる（１６２５）。ＡＳは、Ｒｘを介してリソースを確保することができる（その場合、ユーザはＷＴＲＵ２であり、資金援助者はＷＴＲＵ１である）（１６３０）。ＰＣＲＦ Ｚは、Ｓ９を介してリソースを確保することができる（ユーザはＷＴＲＵ２であり、資金援助者はＷＴＲＵ１である）（１６３５）。ＰＣＲＦ ＺおよびＰＣＲＦ Ｗは、ＰＧＷ Ｚ（ホームに回送されるアクセスのケース）またはＰＧＷ Ｗ（訪問されるアクセスのケース）およびアクセスノードＷを関与させる、ホームに回送されるまたは訪問されるアクセスの手順に従って、リソースを許可することができる（１６４０）。ＰＬＭＮ Ｗは、ＷＴＲＵ１のユーザ資金援助に関してＰＬＭＮ Ｙから承認を受信することができる。応答メッセージが、ＷからＺへ、ＡＳ Ｘに転送して戻されることが可能である（１６４５）。ＷＴＲＵ２のセッションは進行することができる（１６５０）。ＷＴＲＵ１のユーザは、ＷとＹとの間におけるローミングのような契約を通じてＷＴＲＵ２の接続に関して課金されることが可能である（１６５５）。

ＡＰ Ｘは、ＷＴＲＵ１のＭＮＯ Ｙとの間でのサービスコラボレーションを有さないことが可能である。ＷＴＲＵ１は、ＭＮＯ Ｙとの間での自分の現在のアクセスプランを使用して、ＡＰ Ｘとの間でのアプリケーションセッションを開始することができる。必要とされる場合には、ＷＴＲＵ１は、そのセッションに関してＭＮＯ Ｙによる優先トラフィック処理を要求することができる。ＷＴＲＵ１は、プレビュー期間の後に優先トラフィック処理を確認すること（または確認しないこと）が可能である。確認された場合には、ＷＴＲＵ１は、後ほど優先トラフィック処理に関して請求を受けることが可能である。

状況に応じて、ＡＰとＭＮＯとの間においてビジネス契約が存在すること、または存在しないことが可能である。

ビジネス契約がある場合には、サービスコラボレーションは存在しないことが可能である。したがって、ＭＮＯ Ｙは、ＡＰ Ｘの代わりにＷＴＲＵ１に請求を行うことはできないと言える。それでもなお、ＡＰ Ｘは、（たとえば、Ｒｘを通じて）ネットワークリソースを依然として確保することができる。なぜなら、ＡＰ Ｘは、ＭＮＯ Ｙとの間でのビジネス契約を有することができるためである。ＷＴＲＵ１に課金するためにＭｏ／Ｍｆを使用する代わりに、ＡＰ Ｘは、その他の仕組みを通じて（たとえば、クレジットカードまたはＡＰ Ｘからの月次明細を通じて）ＷＴＲＵ１に課金することができる。たとえサービス提携契約がなくても、ＭＮＯ Ｙは、Ｒｘを介した接続のユーザ資金援助を依然としてサポートすることができる（たとえば、ＷＴＲＵ１は、ＷＴＲＵ２によるネットワークリソース使用に関してＭＮＯ Ｙによって課金されることが可能である）。

ビジネス契約がない場合には、ユーザは、優先トラフィック処理を得ることができる。いかなるユーザも優先トラフィック処理を要求できるようにするためにプレビュー機能が開発されることが可能である。ユーザ資金援助方法は、専用のＡＳ（ユーザ資金援助ＡＳ）の利用を通じてこの機能を完全に回避することができ、ユーザ資金援助ＡＳは、コラボレーティブケースにおいて既に開発されている手順を再利用することを可能にすることができる。なぜなら、ユーザ資金援助ＡＳは、ＭＮＯ Ｙとの間でそのようなコラボレーションを有することができるためである。

非ローミング状況において、同じＭＮＯを伴い、ビジネス契約がない、非コラボレーティブケースにおいては、ＷＴＲＵ１およびＷＴＲＵ２は、両方とも同じＭＮＯ Ｙのサブスクライバーであることが可能である。ＭＮＯ Ｙは、ＡＰ Ｘとの間での契約を有さないことが可能である。ＷＴＲＵ１は、ＷＴＲＵ２のセッションの資金援助を開始する場合には、１）サービスのみを資金援助すること、２）ＭＮＯ Ｙによる優先処理を資金援助すること、または３）サービスおよびＭＮＯ Ｙによる優先処理の両方を資金援助することが可能である。

ケース１）および３）においては、サービス／コンテンツ資金援助が、ＡＰ Ｘからあらゆるデジタルグッズと同様に購入されることが可能である。このプロセスは、アプリケーション固有であり、（数ある可能なシナリオの中の）一例においては、ＷＴＲＵ１は、ＡＰ Ｘのポータル上で購入を実行し、ハイパーリンクを提供され、そのハイパーリンクは、ＥメールによってＷＴＲＵ２へ送信されることが可能である。ＡＰ Ｘは、（たとえば、ＷＴＲＵ１のクレジットカードまたはその他の手段を使用して、）ＷＴＲＵ１に課金することができる。

ケース２）および３）においては、ユーザ資金援助ＡＳが存在することが可能である。このＡＳは、データ接続に関するユーザ資金援助要求を処理することを担当する。ユーザ資金援助ＡＳは、たとえば、専用のＡＳとして展開されることや、ＭＮＯ Ｙ、またはＭＮＯ Ｙとの間でのサービスコラボレーション契約を有するサードパーティーによって展開されることが可能である。ＷＴＲＵ１は、ユーザ資金援助要求をユーザ資金援助ＡＳへ送信することができる。この要求は、有効期限の時間、最大時間またはコストなど、ならびにＷＴＲＵ２のアイデンティティーに言及することができる。ＷＴＲＵ１は、ＡＳからＵＲＬなどのトリガーを得ることができる。あるいは、ＡＰは、資金援助トリガーを事前にＷＴＲＵ１に提供することができ、その資金援助トリガーは、（後ほど特定されることになる）ユーザを資金援助するために使用されることが可能である。ＷＴＲＵ１は、トリガーをＷＴＲＵ２に提供することができる。次いでＷＴＲＵ２は、トリガー、ならびにトラフィックフィルタなどのセッション情報を含めて、優先トラフィック処理をユーザ資金援助ＡＳに要求することができる。次いでユーザ資金援助ＡＳは、ＰＣＲＦへのＲｘを使用して、ＷＴＲＵ２の代わりにセッション優先トラフィック処理をセットアップすることができる。ユーザ資金援助ＡＳは、ＭＮＯによって、またはＭＮＯとコラボレートするＡＰによって運営されているＡＳである。

図１７は、非ローミングケース（ＭＮＯ ＺにおけるＷＴＲＵ２）およびローミングケース（ＭＮＯ ＷにおけるＷＴＲＵ２）の両方に関してビジネス契約がなく、同じＭＮＯを伴う、非コラボレーティブケースに関する手順１７００のハイレベルメッセージフロー図を示している。

ローミング状況を伴い、ビジネス契約がなく、同じＭＮＯを伴う、非コラボレーティブケースにおいては、ＭＮＯ ＹのサブスクライバーであるＷＴＲＵ１と同様であるＷＴＲＵ２は、ＭＮＯ Ｗにおいてローミングしている。上述のケース１）および３）において、ユーザへの追加コストでユーザのための優先トラフィック処理を提供するためのＭＮＯ Ｙとの間でのローミング契約をＭＮＯ Ｗが有していると想定すると、サービス／コンテンツ資金援助は、ＭＮＯを関与させることなく、ＡＰによって実行されることが可能である。データ接続のユーザ資金援助、すなわち、上述のケース２）および３）に関しては、ＷＴＲＵ１は、ユーザ資金援助ＡＳ Ｙを通じてＷＴＲＵ２の優先トラフィック処理を資金援助することができる。この変形形態は、上述の非ローミング変形形態と同様であるが、ここでは、ユーザ資金援助ＡＳ Ｙが優先トラフィック処理を設定する。なぜなら、ＷＴＲＵ２は、図１７に示されているようにローミングしているためである。

図１７に示されているように、ＷＴＲＵ１のユーザは、ＷＴＲＵ２のユーザのユーザ資金援助を要求し、トリガー（資金援助タイプ、サービス）を得ることができる（１７０５）。ＷＴＲＵ１のユーザは、ＷＴＲＵ２のユーザ資金援助を要求し、トリガー（接続のみ）を得ることができる（１７１０）。あるいは、ＷＴＲＵ１は、ＡＳから事前にユーザ資金援助トリガーを得ておくことができる（１７１５）。ＷＴＲＵ１は、ユーザ資金援助トリガーをＷＴＲＵ２へ転送することができる（１７２０）。ＷＴＲＵ２は、ＡＳトリガーを使用して、サービスにアクセスすることができる（１７２５）。アプリケーション固有の資金援助が実施されることが可能である（ＷＴＲＵ１のユーザがＡＳによって課金されることが可能である）（１７３０）。ＷＴＲＵ２のユーザは、ユーザ資金援助ＡＳトリガーを使用して、優先トラフィック処理を要求することができる（１７３５）。ユーザ資金援助ＡＳは、非ローミングケースまたはローミングケースに関してＷＴＲＵのユーザの代わりに優先トラフィック処理をセットアップすることができる（１７４０）。ＷＴＲＵ１のユーザは、ローミングのような契約を通じてＭＮＯ ＹまたはＷによって課金されることが可能である。

図１８は、異なるＭＮＯを関与させるコラボレーティブでない状況に関する手順１８００のハイレベルメッセージフロー図を示している。ＷＴＲＵ２は、ＭＮＯ Ｚのサブスクライバーであることが可能である（その一方でＷＴＲＵ１は、ＭＮＯ Ｙのサブスクライバーであることが可能である）。第１のサブケースにおいては、ＡＰとＭＮＯ Ｙとの間においてビジネス契約が存在することが可能である。第２のサブケースにおいては、そのようなビジネス契約が存在しないことが可能である。

ビジネス契約があるケースにおいては、いかなるサービスコラボレーションも存在しないことが可能である。したがって、ＭＮＯ Ｙは、ＡＰ Ｘの代わりにＷＴＲＵ１に請求を行うことはできないと言える。それでもなお、ＡＰ Ｘは、（たとえば、Ｒｘインターフェースを通じて）ネットワークリソースを依然として確保することができる。ＡＰ Ｘは、ＷＴＲＵ１の代わりにＷＴＲＵ２を資金援助することができると言える。ＷＴＲＵ１に課金するためにＭｏ／Ｍｆを使用する代わりに、ＡＰ Ｘは、その他の仕組みを通じて（たとえば、クレジットカードまたはＡＰ Ｘからの月次明細を通じて）ＷＴＲＵ１に課金することができる。

非ローミング状況においては、使用されるユーザ資金援助ＡＳは、ＭＮＯ Ｙの代わりにＭＮＯ Ｚによって（またはＭＮＯ Ｚと連携して）展開されることが可能である。ＭＮＯ Ｚは、ユーザのための優先トラフィック処理を、典型的には使用に対する追加コストで、提供するためのＭＮＯ Ｙとの間でのローミング契約を有することができる。

図１８に示されているように、ＷＴＲＵ１のユーザは、ＷＴＲＵ２のユーザのユーザ資金援助を要求し、トリガー（資金援助タイプ、サービス）を得ることができる（１８０５）。ＷＴＲＵ１のユーザは、ＷＴＲＵ２のユーザ資金援助を要求し、トリガー（接続のみ）を得ることができる（１８１０）。あるいは、ＷＴＲＵ１は、ＡＳから事前にユーザ資金援助トリガーを得ておくことができる（１８１５）。ＷＴＲＵ１は、ユーザ資金援助トリガーをＷＴＲＵ２へ転送することができる（１８２０）。ＷＴＲＵ２は、ＡＳトリガーを使用して、サービスにアクセスすることができる（１８２５）。アプリケーション固有の資金援助が実施されることが可能である（ＷＴＲＵ１のユーザがＡＳによって課金されることが可能である）（１８３０）。ＷＴＲＵ２のユーザは、ユーザ資金援助ＡＳトリガーを使用して、優先トラフィック処理を要求することができる（１８３５）。ユーザ資金援助ＡＳは、非ローミングケースまたはローミングケースに関してＷＴＲＵのユーザの代わりに優先トラフィック処理をセットアップすることができる（１８４０）。ＷＴＲＵ１のユーザは、ローミングのような契約を通じてＭＮＯ Ｚによって、またはローミングのような契約を通じてＷによって課金されることが可能である。

ＷＴＲＵ２は、ＭＮＯ Ｚのサブスクライバーであり、ＭＮＯ Ｗにおいてローミングしていることが可能である。ユーザへの追加コストでユーザのための優先トラフィック処理を提供するためのＭＮＯ Ｙとの間でのローミング契約をＭＮＯ Ｗが有している場合（すなわち、ＷＴＲＵ２がローミングしているＭＮＯと、ＷＴＲＵ１のＭＮＯとの間においてローミング契約が存在することが可能である場合）には、サービス／コンテンツ資金援助は、ＭＮＯを関与させることなく、ＡＰによって実行されることが可能である。データ接続のユーザ資金援助に関しては、ＷＴＲＵ１は、ユーザ資金援助ＡＳ Ｚを通じてＷＴＲＵ２の優先トラフィック処理を資金援助することができる。この変形形態は、上述の非ローミング変形形態と同様である。ここでは、優先トラフィック処理を設定するためにユーザ資金援助ＡＳ Ｚが使用されることが可能である。なぜなら、ＷＴＲＵ２はローミングしているためである。

ＷＴＲＵ１は、ＭＮＯ Ｙのサブスクライバーであることが可能であり、ＷＴＲＵ２は、ＭＮＯのサブスクライバー（たとえば、ＩＳＤＮアクセスネットワークサブスクライバー）ではないことが可能である。ＡＰ Ｘは、ＭＮＯ Ｙとの間でのサービスコラボレーション契約を有することができ、またはＡＰ Ｘは、そのような契約を有さない。

コラボレーティブケースがある状況においては、Ｒｘを介した課金イベントメッセージ、開始／停止をサポートすること、および１回限りのイベントが使用されることが可能である。ＡＰとＭＮＯとの間における直接のＭｏ／Ｍｆインターフェースが使用されることも可能である。ＷＴＲＵ１の請求書は、この特定の課金が実際にＷＴＲＵ２の資金援助されるセッションであったということに言及することができる。あるいは、ＷＴＲＵ１の請求書は、資金援助されるイベントに関するすべての課金を、資金援助されるアイデンティティー（ＷＴＲＵ２、Ｃａｒｏｌなど）ごとに１つのアイテムではなく、単一の統合されたアイテムに再グループ化することができる。さらなる属性値ペア（ＡＶＰ）を用いてＭｏ／Ｍｆシグナリングを強化すること、およびこの新たなＡＶＰを使用することによって、ＡＣＲ（accounting-request）メッセージ（Ｍｆ）、ＣＣＲ（credit-control-request）メッセージ（Ｍｏ）内に、またはその他のＭｏ／Ｍｆメッセージ内に。ＷＴＲＵ２はＭＮＯのサブスクライバーではないため、課金メッセージは、ＷＴＲＵ２のＵｓｅｒ−Ｎａｍｅを使用すべきではなく、代わりに、これらのメッセージのＵｓｅｒ−Ｎａｍｅ ＡＶＰは、ＷＴＲＵ１のネットワークアドレス識別子（ＮＡＩ）であるべきである。通常の課金と、ユーザ資金援助関連の課金との間において区別を行うために、「ｕｓｅｒ−ｓｐｏｎｓｏｒｉｎｇ」と名付けられた新たなＡＶＰは、列挙されたＡＶＰ（このＡＶＰが存在しない場合のデフォルト値であるＮＯＴ＿ＵＳＥＲ＿ＳＰＯＮＳＯＲＥＤ（０）、および、ユーザ資金援助が行われるセッションに現在のメッセージが関連していることを示すＵＳＥＲ＿ＳＰＯＮＳＯＲＥＤ（１）のいずれかを保持する）、またはＵＴＦ８Ｓｔｒｉｎｇ ＡＶＰ（アプリケーション固有のＩＤ（たとえば、この特定の資金援助されるセッションに関して一時的に割り当てられているユーザ名）、Ｅメールアドレス、ＷＴＲＵ１によってプロセスの一部として提供され、かつＷＴＲＵ１にとってのみ意味があるユーザ名（たとえばＷＴＲＵ１が、受領者として「ＷＴＲＵ２」に言及すると、この文字列は、実際の受領者をＷＴＲＵ１に思い出させるためにのみ使用される）、もしくはＩＰアドレスなど、資金援助されるユーザのアイデンティティーを保持する）のいずれかである。

図１９は、ＡＳによってＣＮへ送信される課金メッセージ（典型的には、Ｍｆを介したＡＣＲ、またはＭｏを介したＣＣＲ）が、資金援助されるイベントの受領者を識別する新たなＩＥを含むように強化されている、（ＡＳがＭｏ／Ｍｆ参照ポイントへのアクセスを有するというアーキテクチャー上の選択に従う）手順１９００のハイレベルメッセージフロー図を示している。

図１９に示されているように、（別のアクセスネットワークにおける）ＷＴＲＵ２は、ＷＴＲＵ１から、またはＡＳからサービストリガー（たとえば、ＵＲＬ）を得ることができる（１９０５）。ＷＴＲＵ２は、資金援助されるセッションを開始することができる（１９１０）。ＡＳは、ＷＴＲＵ１のプロファイルから承認を確認することができる（１９１５）。ＡＳは、Ｍｏ／Ｍｆを介して課金システムと対話すること（たとえば、オフライン課金のための強化されたアカウンティングレコードメッセージ、またはオンライン課金のための強化されたクレジットコントロール要求を送信すること）が可能である（１９２０）。ＡＳは、（現在または後ほどセッション中またはセッション後に生じる）イベントベースの対話、または（セッションの前、最中、およびセッションの完了後の）セッションベースの対話を使用することができる。この対話は、サービスコストがＷＴＲＵ１のユーザに課金されることを確実にすることができる。ＡＳは、サービスをＷＴＲＵ２へ配信することができる（１９２５）。

非コラボレーティブケースにおいては、ＡＰ Ｘは、ＷＴＲＵ１の代わりに資金援助を行うＷＴＲＵ２のデータ接続を可能にすることはできない。なぜなら、ＷＴＲＵ２のデータ接続は、ＭＮＯ Ｙの制御下にないためである。ＡＰ Ｘは、ＭＮＯ Ｙとの間でのサービス契約を有しておらず、したがってＡＰ Ｘは、Ｍｏ、Ｍｆ、またはその他の任意のインターフェースを使用して、ＭＮＯ Ｙを通じたサービス／コンテンツアクセスに関してＷＴＲＵ１に課金することはできない。いかなるサービス／コンテンツ資金援助も、ＡＳによって（たとえば、アプリケーションがクレジットカードサービスを使用して課金を管理している場合には、ＡＳの内部で）実行されることが可能である。

ＷＴＲＵ１は、自分のアカウントからＷＴＲＵ２のアカウントへクレジットを転送することができる。ＷＴＲＵ２は、ＷＴＲＵ１と同じＭＮＯまたは異なるＭＮＯのサブスクライバーであることが可能である。次いでＷＴＲＵ２は、（転送中にＷＴＲＵ１によって設定された制限を伴って、または伴わずに）任意のサービスまたはデータ接続に伴ってクレジットを使うことができる。ＷＴＲＵ１は、おそらくは使用上の制限を付加して、自分のアカウントからＷＴＲＵ２のアカウントへのクレジット転送を要求するコマンドを発行する。その後、ＷＴＲＵ２がＭＮＯ課金システムを通じて課金される際には、その課金システムは、使用条件が満たされているかどうかをチェックすることができ、このケースにおいては、ＷＴＲＵ１によって提供されたクレジットが使用される。そうでない場合には、ＷＴＲＵ２が通常どおり課金されることが可能である。

図２０Ａおよび図２０Ｂは、ともに併せて、ＷＴＲＵ１のユーザがクレジットをＷＴＲＵ２のユーザへ転送するための手順２０００のハイレベルメッセージフロー図である。新たなクレジット転送サポートＡＳ（ＣＴＳ−ＡＳ）が使用されることが可能である。ＣＴＳ−ＡＳは、クレジット転送を求める要求を受け入れ、次いでオペレーションを実行するために課金システムと対話することができる。ＣＴＳ−ＡＳは、ＭＮＯ Ｙとの（およびＭＮＯ間でのクレジット転送をサポートするためには、ＭＮＯ Ｚとの）サービスコラボレーションを伴う非ＩＭＳ ＡＳとして実装されることが可能である。したがって（ＷＴＲＵ１からＣＴＳ−ＡＳへの）最初のクレジット転送メッセージは、ＨＴＴＰを介したＸＭＬなどのアプリケーションレイヤメッセージとして実施されることが可能である。ＣＴＳ−ＡＳがＰＬＭＮの課金システムと相互接続するためにＭｏ／Ｍｆを使用するケースにおいては、ＣＴＳ−ＡＳは、これらのインターフェースを使用して、ＷＴＲＵ１に課金すること（または課金ユニットを確保すること）、ならびにＷＴＲＵ２に対してユーザ資金援助クレジットを許可すること／キャンセルすることが可能である。ユーザ資金援助クレジット許可／キャンセルメッセージは、Ｍｏ／Ｍｆを介した新たなメッセージであることが可能であり、またはＭｏ／Ｍｆを介した既存のメッセージ内に新たな情報要素を付加することによって可能にされ得る。ユーザ資金援助クレジット許可／キャンセルメッセージが資金援助者アイデンティティーを含むことを可能にするための既存のＭｏ／Ｍｆ（ならびにＲｏ／Ｒｆ）メッセージＡＶＰに対する強化の例は、上述のように伝達されることが可能であり、既存のＲｅｑｕｅｓｔ−Ａｃｔｉｏｎ ＡＶＰは、ＵＳＥＲ＿ＳＰＯＮＳＯＲＩＮＧ＿ＧＲＡＮＴ、ＵＳＥＲ＿ＳＰＯＮＳＯＲＩＮＧ＿ＧＲＡＮＴ＿ＣＡＮＣＥＬＬＡＴＩＯＮなどの新たなタイプを用いて拡張されることが可能であり、（クレジット金額および条件を含む）さらなる許可情報が、下記のように、新たなＡＶＰを使用して伝達されることが可能である。

Ｇｒａｎｔ−Ｉｎｆｏｒｍａｔｉｏｎ：：＝＜ＡＶＰ Ｈｅａｄｅｒ：（ＡＶＰ−ｎｕｍｂｅｒ−ｔｏ−ｂｅ−ｄｅｔｅｒｍｉｎｅｄ）＞
^*［Ａｐｐｌｉｃａｔｉｏｎ−Ｓｅｒｖｉｃｅ−Ｐｒｏｖｉｄｅｒ−Ｉｄｅｎｔｉｔｙ］（ｅｘｉｓｔｉｎｇ
ＡＶＰ，ｔｏ ｓｅｔ ａｌｌｏｗｅｄ ｓｅｒｖｉｃｅ（ｓ））
［Ｍｕｌｔｉｐｌｅ−Ｓｅｒｖｉｃｅｓ−Ｃｒｅｄｉｔ−Ｃｏｎｔｒｏｌ］（ｅｘｉｓｔｉｎｇ ＡＶＰ，ｔｏ ｓｅｔ ｇｒａｎｔｅｄ ｏｒ ｕｓｅｄ ａｍｏｕｎｔ）
［Ｓｔｏｐ−ｔｉｍｅ］（ｅｘｉｓｔｉｎｇ ＡＶＰ，ｔｏ ｓｅｎｄ ｔｈｅ ｔｉｍｅ ｌｉｍｉｔ ｏｆ ｔｈｅ ｇｒａｎｔ， ｉｆ ａｎｙ）
［Ｇｒａｎｔ−ＩＤ］（ｎｅｗ ＡＶＰ，ｅ．ｇ． ａｎ ｉｎｔｅｇｅｒ ｏｒ ａ ｓｔｒｉｎｇ，ｓｅｔ ｂｙ ｔｈｅ ｃｈａｒｇｉｎｇ ｓｙｓｔｅｍ ａｎｄ ｕｎｉｑｕｅ ｗｉｔｈｉｎ ｔｈｉｓ ｃｈａｒｇｉｎｇ ｓｙｓｔｅｍ，ｕｓｅｄ ｔｏ ｃｏｒｒｅｌａｔｅ ｍｅｓｓａｇｅｓ）

Ｍｕｌｔｉｐｌｅ−Ｓｅｒｖｉｃｅｓ−Ｃｒｅｄｉｔ−Ｃｏｎｔｒｏｌ ＡＶＰは、グループ化されたタイプである。たとえば、含まれているＡＶＰ「Ｒｅｑｕｅｓｔｅｄ−Ｓｅｒｖｉｃｅ−Ｕｎｉｔ」は、ユーザ資金援助が行われる許可された金額を（許可要求内に）保持するために使用されることが可能であり、「Ｕｓｅｄ−Ｓｅｒｖｉｃｅ−Ｕｎｉｔｓ」は、実際に使用された金額を（キャンセル応答内に）保持するために使用されることが可能である。

ＣＴＳ−ＡＳは、（ＣＴＳ−ＡＳがＭＮＯ Ｙとの間での自分のサービスコラボレーションを通じてアクセスすることができるＷＴＲＵ１のサブスクライバープロファイルに応じて、オフラインまたはオンライン課金システムを使用してＷＴＲＵ１に課金することができる。ＣＴＳ−ＡＳは、たとえば両方のケースにおいてイベントベースの課金を使用することができる。このケースにおいては、「金額確保」メッセージは、実際に全額に関する課金である。許可にタイムリミットがある場合には、ＣＴＳ−ＡＳは、使用されていない部分に関してＷＴＲＵ１に返金することができる。

課金ノード（たとえばＯＣＳ、たとえばＣＤＦ機能）は、ユーザ資金援助をサポートして、一式の関連した情報要素、すなわち、資金援助されるユーザのＩＤ、資金援助者ＩＤ、条件、およびクレジット金額を保持するように強化されている。この情報は、課金メッセージ（たとえば、ＡＣＲまたはＣＣＲメッセージ）の受信時に使用されることが可能であり、マッチが存在する場合には、アカウントに課金する代わりに、資金援助されたクレジットを消費する。

図２０Ａに示されているように、ＷＴＲＵ１は、クレジット転送をＷＴＲＵ２に要求することができる（これは、条件に関連付けられることが可能である）（２００５）。クレジットの金額が、ＷＴＲＵ１のアカウントにおいて確保されることが可能である（２０１０）。ユーザ資金援助が行われるクレジットの許可が、ＷＴＲＵ２へ送信されることが可能である（これは、条件に関連付けられることが可能である）（２０１５）。課金ノードは、資金援助されるクレジットをＷＴＲＵ１の条件に（および請求書編成のためにＷＴＲＵ１のＩＤに）関連付けることができる（２０２０）。ＷＴＲＵ２は、ネットワークリソースを使用すること、および／またはＰＤＮ Ｚとの間でのサービスコラボレーションを伴うＡＰによって提供されるサービスを消費することが可能である（２０２５）。ＰＤＮ Ｚノード（たとえば、ＰＣＲＦ）またはＡＳ Ｘは、ＷＴＲＵ２のユーザに課金することができる（２０３０）。課金ノードは、課金情報（たとえば、アプリケーション名）をＷＴＲＵ１ユーザの条件と比較することができる（２０３５）。マッチが存在する場合には、ＷＴＲＵ１ユーザのクレジットが使用されることが可能である。これが十分ではない場合には、ＷＴＲＵ２ユーザの通常のクレジットが使用されることが可能であり、残りに関しては、マッチが存在しない場合には、ＷＴＲＵ２の通常のクレジットが使用されることが可能である。

図２０Ｂに示されているように、ＷＴＲＵ２ユーザは、課金システム情報に基づいて後ほど請求を受けることが可能である（２０４０）。ＷＴＲＵ２ユーザの請求書は、ＷＴＲＵ１のユーザアイデンティティーおよび条件を含めて、特定のアイテムとしてＷＴＲＵ１のユーザ資金援助が行われるクレジットに言及することができる。ユーザ資金援助が行われるクレジットの転送に対するタイムリミットをＷＴＲＵ１のユーザが設定しているという条件で（２０４５）、ＷＴＲＵ１が最大のタイムピリオドを含んでいたケースにおいては、この時点で、この特定の資金援助に関してそのタイムピリオドは満了することが可能である（２０５０）。ＷＴＲＵ２ユーザに対するユーザ資金援助が行われるクレジットがキャンセルされることが可能である（２０５５）。応答は、ＷＴＲＵ１のユーザクレジットのうちのいくらが実際に使用されたかを示すことができる（２０６０）。ＷＴＲＵ１のユーザは、所与の金額に関して課金されることが可能であり、確保されたクレジットのうちの残りは、解放されることが可能である（２０６５）。

実施形態
１．ワイヤレス送信／受信ユニット（ＷＴＲＵ）によるユーザ資金援助の方法であって、
第１のＷＴＲＵが、アプリケーションサーバ（ＡＳ）を介して第２のＷＴＲＵのユーザ資金援助を開始することと、
第１のＷＴＲＵが、ＡＳからサービストリガーを受信すること、およびそのサービストリガーを第２のＷＴＲＵに提供することと、
第２のＷＴＲＵが、サービストリガーを使用して、ＡＳとの資金援助されるセッションを開始することと、
ＡＳが、第２のＷＴＲＵへコンテンツを配信するために必要とされる優先トラフィック処理を提供する要求をネットワークへ送信することであり、第１のＷＴＲＵのユーザは、その優先トラフィック処理について課金される、ことと
を含む、方法。
２．ＡＳが、オンライン課金機能（ＯＣＦ）および課金データ機能（ＣＤＦ）を含む課金システムとの直接通信リンクを確立すること
をさらに含む、実施形態１に記載の方法。
３．第１のＷＴＲＵに関連付けられたユーザプロファイル内のユーザ資金援助データを構成することと、
第１のＷＴＲＵが、第２のＷＴＲＵからの承認を得ることと
をさらに含む、実施形態１または２に記載の方法。
４．サービストリガーは、埋め込みトークンを伴うハイパーリンクに関連付けられている、実施形態１乃至３のいずれか１つに記載の方法。
５．サービストリガーは、トークンを含むユニフォームリソースロケータ（ＵＲＬ）に関連付けられている、実施形態１乃至４のいずれか１つに記載の方法。
６．第１のＷＴＲＵが資金援助トークンを得ることをさらに含む、実施形態１乃至５のいずれか１つに記載の方法。
７．第１のＷＴＲＵのサブスクライバープロファイルが、アプリケーションサーバ（ＡＳ）上に存在する、実施形態１乃至６のいずれか１つに記載の方法。
８．第１のＷＴＲＵのサブスクライバープロファイルが、ホームサブスクライバーサーバ（ＨＳＳ）上に存在する、実施形態１乃至７のいずれか１つに記載の方法。
９．第１のＷＴＲＵのサブスクライバープロファイルが、サブスクライバープロファイルリポジトリ（ＳＰＲ）上に存在する、実施形態１乃至８のいずれか１つに記載の方法。
１０．第１のＷＴＲＵのサブスクライバープロファイルが、ユーザデータリポジトリ（ＵＤＲ）上に存在する、実施形態１乃至９のいずれか１つに記載の方法。
１１．第１のＷＴＲＵが、クレジットを第２のＷＴＲＵへ転送するようＡＳに要求すること
をさらに含む、実施形態１乃至１０のいずれか１つに記載の方法。
１２．ワイヤレス送信／受信ユニット（ＷＴＲＵ）によるユーザ資金援助の方法であって、
第１のＷＴＲＵが、アプリケーションサーバ（ＡＳ）からの第２のＷＴＲＵのユーザ資金援助を要求することと、
ＡＳが、オンライン課金機能（ＯＣＦ）および課金データ機能（ＣＤＦ）を含む課金システムとの直接通信リンクを確立することと
を含む、方法。
１３．第１のＷＴＲＵが、ＡＳからユーザ資金援助トリガーを得ること、およびそれらの資金援助トリガーを第２のＷＴＲＵへ転送することと、
第２のＷＴＲＵが、ＡＳトリガーを使用して、ＡＳからのサービスにアクセスすることと、
第２のＷＴＲＵとＡＳとの間のセッションを確立することと
をさらに含む、実施形態１２に記載の方法。
１４．ＡＳが、第２のＷＴＲＵへコンテンツを配信するために必要とされる優先トラフィック処理を提供する要求をネットワークへ送信することであり、第１のＷＴＲＵのユーザは、その優先トラフィック処理について課金される、こと
をさらに含む、実施形態１２または１３に記載の方法。
１５．第１のＷＴＲＵのユーザは、ローミングのような契約を通じて第２のＷＴＲＵの優先トラフィック処理について課金される、実施形態１２乃至１４のいずれか１つに記載の方法。
１６．ＡＳが、第１のＷＴＲＵのユーザが第２のＷＴＲＵのユーザを資金援助することを承認されていることを確認することと、
第１のＷＴＲＵが、ＡＳからサービストリガーを受信することと、
第１のＷＴＲＵが、サービストリガーを第２のＷＴＲＵに提供することと、
第２のＷＴＲＵが、サービストリガーを使用して、ＡＳとの間での資金援助されるセッションを開始することと、
第２のＷＴＲＵが、ＡＳからのサービスを受信することと
をさらに含む、実施形態１２乃至１５のいずれか１つに記載の方法。
１７．第１のＷＴＲＵが、クレジットを第２のＷＴＲＵへ転送するようＡＳに要求すること
をさらに含む、実施形態１２乃至１６のいずれか１つに記載の方法。
１８．実施形態１乃至１７のいずれか１つに記載の方法を実行するように適合されていることを特徴とするシステム。
１９．アプリケーションサーバ（ＡＳ）であって、
第２のワイヤレス送信／受信ユニット（ＷＴＲＵ）を資金援助する第１のＷＴＲＵへサービストリガーを送信するように構成された送信機
を備え、
送信機は、第２のＷＴＲＵへコンテンツを配信するために必要とされる優先トラフィック処理を提供する要求をネットワークへ送信するようにさらに構成され、第２のＷＴＲＵのユーザは、オンライン課金機能（ＯＣＦ）および課金データ機能（ＣＤＦ）を含む課金システムを介してその優先トラフィック処理について課金される、アプリケーションサーバ（ＡＳ）。
２０．アプリケーションサーバ（ＡＳ）のための方法であって、
第２のワイヤレス送信／受信ユニット（ＷＴＲＵ）を資金援助する第１のＷＴＲＵへサービストリガーを送信することと、
第２のＷＴＲＵへコンテンツを配信するために必要とされる優先トラフィック処理を提供する要求をネットワークへ送信することであり、第２のＷＴＲＵのユーザは、オンライン課金機能（ＯＣＦ）および課金データ機能（ＣＤＦ）を含む課金システムを介してその優先トラフィック処理について課金される、こととを含むことを特徴とする方法。
２１．第１のワイヤレス送信／受信ユニット（ＷＴＲＵ）であって、
アプリケーションサーバ（ＡＳ）を介して第２のＷＴＲＵのユーザ資金援助を開始するように構成された送信機と、
ＡＳからサービストリガーを受信するように構成された受信機と
を備え、
送信機は、サービストリガーを第２のＷＴＲＵへ転送するようにさらに構成されており、第２のＷＴＲＵはそのサービストリガーを使用してＡＳとの資金援助されるセッションを開始することができ、第１のＷＴＲＵのユーザは、第２のＷＴＲＵに提供されたサービスおよび優先トラフィック処理について課金システムを介して課金され、その課金システムは、オンライン課金機能（ＯＣＦ）および課金データ機能（ＣＤＦ）を含む、第１のワイヤレス送信／受信ユニット（ＷＴＲＵ）。
２２．サービストリガーは、埋め込みトークンを伴うハイパーリンクに関連付けられている、実施形態２１に記載の第１のＷＴＲＵ。
２３．第１のワイヤレス送信／受信ユニット（ＷＴＲＵ）のための方法であって、
アプリケーションサーバ（ＡＳ）を介して第２のＷＴＲＵのユーザ資金援助を開始することと、
ＡＳからサービストリガーを受信することと、
サービストリガーを第２のＷＴＲＵへ転送することであり、第２のＷＴＲＵはそのサービストリガーを使用してＡＳとの間での資金援助されるセッションを開始することができ、第１のＷＴＲＵのユーザは、第２のＷＴＲＵに提供されたサービスおよび優先トラフィック処理について課金システムを介して課金され、その課金システムは、オンライン課金機能（ＯＣＦ）および課金データ機能（ＣＤＦ）を含む、こととを含む、方法。
２４．サービストリガーは、埋め込みトークンを伴うハイパーリンクに関連付けられている、実施形態２３に記載の方法。

上記では特徴および要素が特定の組合せで説明されているが、それぞれの特徴または要素は、単独で、またはその他の特徴および要素のうちの任意のものとの組合せで使用されることが可能であることを当技術分野における標準的な技術者なら理解するであろう。加えて、本明細書に記載されている実施形態は、コンピュータまたはプロセッサによって実行するためにコンピュータ可読メディア内に組み込まれているコンピュータプログラム、ソフトウェア、またはファームウェアで実装されることが可能である。コンピュータ可読メディアの例は、（有線接続またはワイヤレス接続を介して伝送される）電子信号、およびコンピュータ可読ストレージメディアを含む。コンピュータ可読ストレージメディアの例は、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、磁気メディア（たとえば、内蔵ハードディスクまたは取り外し可能ディスク）、光磁気メディア、および、コンパクトディスク（ＣＤ）またはデジタル多用途ディスク（ＤＶＤ）などの光学メディアを含むが、それらには限定されない。ソフトウェアと関連付けられているプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、Ｎｏｄｅ−Ｂ、ｅＮＢ、ＨＮＢ、ＨｅＮＢ、ＡＰ、ＲＮＣ、ワイヤレスルータ、または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実装するために使用されることが可能である。

Claims (20)

1. モバイルデータのユーザ対ユーザ資金援助のためのワイヤレス送信／受信ユニット（ＷＴＲＵ）において使用する方法であって、
   １つ以上の他のＷＴＲＵから識別する情報を受信することと、
   トリガーによって、前記１つ以上の他のＷＴＲＵのうちの第２のＷＴＲＵに対するモバイルデータの資金援助を開始することであり、前記開始の中で、サービス資金援助タイプパラメータまたは接続資金援助タイプパラメータのうちの少なくとも１つが使用される、ことと、
   前記トリガーを前記第２のＷＴＲＵに提供することであり、前記トリガーは前記第２のＷＴＲＵへの前記資金援助されるモバイルデータを開始するよう構成されている、ことと
   を含む、方法。
2. 前記識別する情報は、前記１つ以上の他のＷＴＲＵの関与を伴って、受信される、請求項１に記載の方法。
3. 前記第２のＷＴＲＵから資金援助についての承認を取得することをさらに含む、請求項１に記載の方法。
4. 承認を取得することは、前記ＷＴＲＵにより実行される、請求項３に記載の方法。
5. 前記トリガーは、アプリケーションサーバにより提供される、請求項１に記載の方法。
6. 前記トリガーは、資金援助トークンを含む、請求項１に記載の方法。
7. 前記資金援助トークンは、資金援助されるモバイルデータタイプの範囲に制限される、請求項６に記載の方法。
8. 前記資金援助トークンは、時間で制限される、請求項６に記載の方法。
9. 前記トリガーは、トークンを含む、請求項１に記載の方法。
10. 前記モバイルデータを、前記トークンを有する前記ＷＴＲＵにマッチさせることをさらに含む、請求項９に記載の方法。
11. 前記第２のＷＴＲＵの資金援助は、前記第２のＷＴＲＵが前記モバイルデータにアクセスすることを可能にする、請求項１に記載の方法。
12. モバイルデータのユーザ対ユーザ資金援助するワイヤレス送信／受信ユニット（ＷＴＲＵ）であって、
    １つ以上の他のＷＴＲＵから識別する情報を受信し、
    トリガーによって、前記１つ以上の他のＷＴＲＵのうちの第２のＷＴＲＵに対するモバイルデータの資金援助を開始し、前記開始の中で、サービス資金援助タイプパラメータまたは接続資金援助タイプパラメータのうちの少なくとも１つが使用され、
    前記第２のＷＴＲＵへの前記資金援助されるモバイルデータを開始するための前記トリガーを前記第２のＷＴＲＵに提供する
    よう構成された回路を備えた、ＷＴＲＵ。
13. 前記識別する情報は、前記１つ以上の他のＷＴＲＵの関与を伴って、受信される、請求項１２に記載のＷＴＲＵ。
14. 前記第２のＷＴＲＵから資金援助についての承認を取得することをさらに含む、請求項１２に記載のＷＴＲＵ。
15. 前記トリガーは、資金援助トークンを含む、請求項１２に記載のＷＴＲＵ。
16. 前トリガーは、トークンを含む、請求項１２に記載のＷＴＲＵ。
17. 前記モバイルデータを、前記トークンを有する前記ＷＴＲＵにマッチさせることをさらに含む、請求項１６に記載のＷＴＲＵ。
18. ユーザ対ユーザ資金援助されるモバイルデータのためのワイヤレス送信／受信ユニット（ＷＴＲＵ）であって、
    資金援助するＷＴＲＵへ、前記ＷＴＲＵの識別する情報を提供し、
    資金援助されるモバイルデータへのアクセスを開始するためのトリガーを受信し、前記受信することはサービス資金援助タイプパラメータまたは接続資金援助タイプパラメータのうちの少なくとも１つを受信することを含み、
    前記トリガーで、資金援助されるモバイルデータを開始する
    う構成された回路を備えた、ＷＴＲＵ。
19. 前記トリガーは資金援助トークンを含む、請求項１８に記載のＷＴＲＵ。
20. 前記資金援助するＷＴＲＵから資金援助についての承認を取得することをさらに含む、請求項１８に記載のＷＴＲＵ。

Images