JP2011527782A - ドメインネームサーバを使用するサービスブロッキング - Google Patents

Abstract

実施形態に従うシステム及び方法は、ＤＮＳサーチを使用してサービスを発見するための技術を提供する。例えば、顧客のエンドユーザデバイス（１０、２０、３０）のＩＰアドレスは、サービス、例えば、支払サービスあるいはビデオ配信サービス、を指し示すエントリを取得することができるリバースＤＮＳサーチを実行するために使用することができる。そして、このエントリ、例えば、ユニフォームリソースロケータ（ＵＲＬ）は、識別されるサービスにアクセスするあるいは識別されるサービスを評価するために使用することができる。
【選択図】 なし

Description

本発明は、一般的には、通信システムに関するものであり、特に、ドメインネームサーバを使用してサービスを仲介するための方法及びシステムに関するものである。

通信技術とその用途は、ここ数十年で大きく変化している。ごく最近までは、銅線技術が、長距離に渡る音声通信を送信するために使用される主要なメカニズムであった。コンピュータが導入されたことで、遠隔地間でのデータ交換を行うための要望が、様々な目的、例えば、ビジネス、個人のユーザ、及び教育機関のために成長している。ケーブルテレビの導入は、ビジネスから公共への通信及びデータ配信を増加させるための追加のオプションを提供した。技術が進化を続けるにつれて、デジタル加入者ライン（ＤＳＬ）送信機器が導入され、これは、既存の銅線による電話線設備を介してより高速なデータ送信を可能にしている。更に、ケーブル設備を介する双方向の情報交換が、ビジネス及び公共で利用可能になっている。これらの進歩は、使用できるサービスのオプションの成長を促進させていて、一方で、特に、ビデオの品質と、配信のために利用可能なコンテンツの全体量が増えるにつれて、これらのサービスを配信するための利用可能な帯域幅を改善し続ける必要性も増している。

家電市場が成長し続け、かつプロセッサの処理能力が上がるにつれて、より多くのデバイスが公共利用で利用可能になっていて、これにより、デバイスとより多くのアプリケーションとの間でのデータの送信を可能にし、かつ、送信されるデータに基づいて動作するより多くのアプリケーションが利用可能になっている。これは、特に、インターネット及びローカルエリアネットワーク（ＬＡＮ）群で顕著である。これらの２つの改革は、複数のユーザと複数のデバイスに、様々なデバイスと様々なデバイスタイプとの間での通信及びデータ交換を可能にする。例えば、パーソナルコンピュータ、ラップトップコンピュータ、及び携帯電話は、様々なメディアコンテンツプロバイダへすべてアクセスして、データを交換すること及びサービスを受信することの少なくとも一方を行うことができる。これらのデバイスと処理能力の進歩に伴い、ユーザは、これらのネットワークを介して様々なサービスを受けることをますます要望している。

ユーザデバイス、サービスオプション及びプロバイダの量が増加するにつれて、コンテンツへのアクセスをユーザに効率的に提供することの要望が増し、また、このように要望されるコンテンツに関連付けられている有益な課金方法についての必要性も成長することが期待されている。サービス及びアプリケーションの少なくとも一方へのアクセスを進めることのユーザの要望と課金をマージするための、移動電話に関連付けられている１つのメカニズムには、エリクソン社のインターネット支払取引（ＩＰＸ）がある。ＩＰＸはビジネス協定であり、このビジネス協定は、移動電話ユーザとコンテンツプロバイダに、コンテンツが移動体ユーザによってリクエストされる場合に所定の課金方法を有することを許可するものである。ＩＰＸは、オペレータとコンテンツ企業との間で、様々なプロトコルを再利用するブローカーとして動作することができる。このプロトコルには、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）、ショートメッセージピアツーピア（ＳＭＰＰ）プロトコル及びＭＭ７がある。例えば、移動体ユーザが、着信音をリクエストしてその支払を委任する、緩慢で何かしらの手動の方法が介在することに代えて、ＩＰＸを使用するコンテンツプロバイダが着信音をダウンロードしている場合、移動電話ユーザは、コンテンツプロバイダから着信音をダウンロードするために、自身の移動オペレータから毎月、自身の請求が課金され得る。加えて、これらのシステムは、たいてい、オペレータが課金システムを実装することを要求する。例えば、ＩＰＸのような移動体カスタマになされるような課金システムは、典型的には、有線カスタマに対しては実現されていない。

コンピュータ産業、電気通信産業及びエンターテイメント産業の継続的な成長で予見できるように、様々な製品／サービスの用途の間にはかなりの重複が存在し、かつこの重複は増えることが予想されている。この重複は、様々なタイプのエンドユーザデバイス、例えば、パーソナルコンピュータ、無線あるいは有線接続を使用するラップトップコンピュータ、及び移動電話に、エンドユーザのサービスプロバイダを必ずしも必要としない、複数のコンテンツプロバイダからコンテンツへアクセスできることを可能にする要望をもたらしている。このコンテンツには、オーディオ、ビデオオンデマンド（ＶｏＤ）、着信音、気象情報の更新及びその類を含み得る。これは、エンドユーザが、コンテンツプロバイダからコンテンツ、特に、低コストで反復的なコンテンツをリクエストする場合に、自身が利用可能な、複数の使いやすい、安全な課金オプションを要望することになることが予見できる。

例えば、ユーザがインターネットサーフィンをしていて、オンラインによる閲覧につき、２ドルの購読料金が発生する新聞を読みたいと思っていて、この閲覧に対する購読料金の支払方法は、ＶＩＳＡあるいはマスタカードによるクレジットカードによるものと限定されていると想定する。要求される情報フィールドのすべてを埋めるために必要とされる時間の量と労力は、おそらくは、クレジットカード会社と新聞社の両方に対して繰り返されることになり、これは、２ドルの料金に対して、また、潜在的には、関心のある新聞記事を読むための短時間に対して、長期に渡る手順となる。加えて、この支払方法は、エンドユーザがＶＩＳＡあるいはマスタカードのクレジットカードを持っていることを想定するので柔軟ではない。エンドユーザの観点からは、複数のユーザが選択可能な支払オプションを有するより簡便なシステムが望まれる。また、コンテンツプロバイダの観点からは、支払の柔軟性及び自動化は、潜在的な市場を増やし、また、サービスを使用する顧客を増やすことができる可能性がある。このような柔軟性と自動化は、支払方法の代替物の識別以外に、サービスに対しても適用することができる可能性がある。

従って、本明細書の実施形態は、ネットワーク内のサービスを発見するための技術を提供するためのシステム及び方法を提供する。

本発明に従うシステム及び方法は、デバイスに対するコンテンツを要求する場合に、エンドユーザに複数の支払／課金オプションを提供するためのシステム及び方法を提供することによって、上述の必要性及びその他のことに対処する。

一実施形態に従えば、サービスプロバイダによって、特定のタイプのサービスを発見する方法が提供される。この方法は、リバースドメインネームサーバ（ＤＮＳ）サーチを実行するステップと、前記リバースＤＮＳサーチに基づいて、ＤＮＳから、前記サービスに関連付けられている少なくとも１つのエントリを取得するステップとを備える。ここで、前記少なくとも１つエントリは、前記特定のタイプのサービスのサービスプロバイダを指し示す少なくとも１つのユニフォームリソースロケータである。

本発明の別の実施形態に従えば、プロセッサを備える装置が提供される。このプロセッサは、リバースドメインネームサーバ（ＤＮＳ）サーチを実行することによって、サービスプロバイダによって提供される特定のタイプのサービスを発見し、かつＤＮＳから前記サービスに関連付けられている少なくとも１つのエントリを取得する。前記少なくとも１つのエントリは、前記特定のタイプのサービスのサービスプロバイダを指し示す少なくとも１つのユニフォームリソースロケータ（ＵＲＬ）である。

本発明の更に別の実施形態に従えば、コンピュータあるいはプロセッサによって実行される場合のプログラム命令を含むコンピュータ可読記憶媒体が提供される。これは、リバースドメインネームサーバ（ＤＮＳ）サーチを実行するステップと、前記リバースＤＮＳサーチに基づいて、ＤＮＳから、前記サービスに関連付けられている少なくとも１つのエントリを取得するステップとを実行する。前記少なくとも１つエントリは、前記特定のタイプのサービスのサービスプロバイダを指し示す少なくとも１つのユニフォームリソースロケータ（ＵＲＬ）である。

本実施形態に従うコンテンツプロバイダと通信するエンドユーザデバイスを備えるフレームワークを示す図である。 本実施形態に従う課金ゲートウェイを選択するためのフローチャートである。 本実施形態に従うエンドユーザデバイスあるいは通信ノードを示す図である。 本実施形態に従うサービスを発見するための方法を示すフローチャートである。 本実施形態に従うオペレータの課金ゲートウェイ（ＢＧＷ）を使用するための呼フロー図である。 本実施形態に従うサードパーティのＢＧＷを使用するための呼フロー図である。

以下の実施形態の詳細説明は、図面を参照する。異なる図面内での同一の参照番号は、同一あるいは同様の要素を識別する。また、以下の詳細説明は、本発明を限定するものではない。むしろ、本発明の範囲は、添付の請求項によって定義される。

上述のように、コンテンツあるいはサービス、例えば、デバイス用の、ビデオ、ゲーム、オーディオ、着信音をリクエストする場合に、複数の支払あるいは課金オプションを提供するためのシステム及び方法をエンドユーザに提供することが望ましい。加えて、使用されるデバイスのタイプ、かつそれをどのようにして使用できるかについての柔軟性が増すことが望ましい。例えば、ユーザは、自身のセットトップボックス（ＳＴＢ）によって受信される、自身のテレビ加入に対して支払うことができる自身のパーソナルコンピュータ（ＰＣ）を欲しい場合がある。この議論に対していくつかの状況を示すために、例示の通信フレームワーク１００が図１に示され、ここでは、様々なノードから、例えば、コンテンツプロバイダノードから、例えば、エンドユーザデバイスへの通信を提供する。例示のエンドユーザデバイス１０、２０及び３０は、コンテンツをリクエストし、また、コンテンツに対する課金手順をやり取りするために使用することができ、これには、限定されるものではないが、携帯電話、ラップトップコンピュータ、ＰＣ、ＳＴＢ、例えば、ウェブブラウザを備えるデバイスのようなコンテンツを受信することができる他のデバイスがある。

図１に示される実施形態に従えば、コンテンツをリクエストし、かつ受信することができるエンドユーザデバイス１０、２０及び３０は、異なる相互接続通信ネットワークを介して、複数のコンテンツプロバイダ１１２、１１６及び１２８と通信することができる。コンテンツのリクエスト／受信に関与するいくつかのノードと、関連する課金手順が図１に示され、これについて以下で説明するが、潜在的には、複数の他のノードと通信リンク群、例えば、不図示ではあるが、ワイドエリアネットワーク（ＷＡＮ）２１０内のルータ群、セルラーネットワーク１２６内の基地局群及びｅノードＢ群の少なくとも一方が、必要に応じて存在することが理解されるであろう。加えて、セルラーネットワーク１２６は、セルラーネットワークを説明する様々な文献や規格で記載されている、あるいは今日使用されている、任意の様々なタイプの、かつ様々な世代のセルラー電話ネットワークを表している。

この例示のシステムでは、エンドユーザデバイス１０及び３０は、ケーブルあるいはデジタル加入者ライン（ＤＳＬ）モデムであり得る、ホームゲートウェイ（ＧＷ）１０２と通信していて、一方で、このホームゲートウェイ（ＧＷ）１０２は、オペレータゲートウェイ（あるいはノード）１０４と通信している。オペレータＧＷ１０４は、自身の関連するドメインネームシステム（ＤＮＳ）サーバ１０６と通信している。加えて、オペレータ１０８は、エンドユーザに対するＷＡＮ２１０へのアクセスを提供している。ＷＡＮ１１０は、デバイス間のトラフィックをルーティングするための、複数のルータと複数のノード（不図示）を含むことができる。また、ＷＡＮ１１０は、様々なコンテンツプロバイダ１１２及び１１６と接続する通信リンクを有することができ、これらのコンテンツプロバイダ１１２及び１１６のそれぞれは、関連するＤＮＳサーバ１１４及び１１８を備える。また、通信リンクは、ＷＡＮ１１０とセルラーネットワーク１２６の間にも存在する。携帯電話２０は、オペレータゲートウェイ（あるいはノード）１２２と通信し、オペレータゲートウェイ（あるいはノード）１２２は、自身の関連するＤＮＳサーバ１２４と通信し、両者はともにセルラーネットワーク１２６の一部とみなすことができる。また、セルラーネットワーク１２６との通信には、コンテンツプロバイダ１２８と、その関連するＤＮＳサーバ１２８がある。他の追加的なノード、例えば、サードパーティ（ＴＰ）課金ゲートウェイ（ＢＧＷ）１２０は、ＷＡＮ１１０及びセルラーネットワーク１２６の少なくとも一方と通信することができる。これらのノードは、本実施形態に従う、コンテンツあるいはサービスをリクエストするための、また、課金情報あるいは支払を送信／受信するための、エンドユーザデバイスに対する純粋な例示の物理フレームワークを示すために記載されている。

図１に示される例示の通信システムの例示のエンドユーザデバイス１０、２０及び３０を使用することで、コンテンツあるいはサービスをリクエストすることができ、かつ課金あるいは支払情報を収集して、交換することができる。本明細書で使用される用語「コンテンツ」は、任意のコンテンツ、サービス、商品の配信等の総称であり、これらは、エンドユーザあるいはエンドユーザデバイスによってリクエストされる。エンドユーザがデバイスからコンテンツを注文する場合、オペレータ１０８と、コンテンツプロバイダ１１２、１１６あるいは１２８との両方に対して好ましく、かつ受け入れ可能な、エンドユーザが選択するための様々な支払ソリューションを有することがしばしば要望される。本明細書で使用される用語「好適な（preferred）」は、１つ以上のパーティによって受け入れられる支払方法、また、例えば、受け入れ可能な支払方法を順序付けたランクキングに基づいて、１つ以上のパーティにより好ましい受け入れ可能な支払方法のサブセットの総称である。実施形態に従えば、ユーザ、オペレータ、課金システム及びコンテンツプロバイダの間の一連の信頼関係をそれぞれが含む、複数の支払ソリューションから選択することをユーザに可能にするシステム及び方法が提供される。本明細書で使用される、一連の信頼関係は、異なるエンティティ間で信頼されているソース群から、受け入れられた課金オプションを示すものである。これは、一部分においては、コンテンツをリクエストする場合に、エンドユーザと、オペレータ及びコンテンツプロバイダの少なくとも一方との間の通信中に収集される情報に基づくことができる。

コンテンツ配信に関与する様々なパーティ群の一部あるいはすべて、例えば、エンドユーザ、コンテンツプロバイダ及びサービスオペレータの一部あるいはすべての間で、順序立てられており、更に柔軟なネゴシエーションを容易にするために、本発明の実施形態は、エンドユーザデバイス１０、２０及び３０側と、ネットワーク側との両方における技術とメカニズムを提供する。エンドユーザ側の技術とメカニズムは、ネットワーク側の技術とメカニズムとともに使用することができる。あるいは、２つのセットの機能が、お互いに独立して使用することができる。これらの様々な技術及びメカニズムの完全な理解を提供するために、エンドユーザ側の技術とメカニズムを、まず、ネットワーク側の技術とメカニズムとは独立して説明し、次に、ネットワーク側の技術及びメカニズムを説明し、そして、最後に、それらの潜在的な対話を示すいくつかの例を提示する。

エンドユーザ側
実施形態に従えば、ソフトウェアアプリケーションは、様々なエンドユーザデバイス１０、２０及び３０にインストールすることができ、エンドユーザデバイス１０、２０及び３０は、例えば、課金手順のストリーミングを支援するために自身のウェブブラウザと対話する。例えば、ソフトウェアアプリケーションは、オペレータ１０８、または任意のコンテンツプロバイダ１１２、１１６あるいは１２８（「販売業者」とも呼ばれる）からの問い合わせに応対するために使用することができる。これらのオペレータ、または任意のコンテンツプロバイダ１１２、１１６あるいは１２８は、特定のエンドユーザに対する、潜在的な課金ゲートウェイのリストを生成するために使用される情報の提供を支援するためのものである。本実施形態に従えば、このソフトウェアアプリーションは、デバイスのメモリ及びプロセッサと協働して、エンドユーザデバイス１０、２０及び３０に、支払の連鎖に組み込まれ得る情報に関するいくつかの機能を実行させることを可能にする。例えば、エンドユーザデバイス１０、２０及び３０は、好適なエンティティ群及びブラックリストに挙げられているエンティティ群の少なくとも一方、例えば、課金ゲートウェイ群のリストを保持することができる。エンドユーザデバイス１０、２０及び３０は、代替の支払方法のリストも保持することができ、これは、必要に応じて、オペレータ１０８及びコンテンツプロバイダ１１２、１１６及び１２８に送信される。エンドユーザデバイス１０、２０及び３０は、支払あるいは支払トランザクション（取引）に関するオプションのメタデータを保持することができ、これには、例えば、通貨の換算、契約の詳細、事前認可情報に関連するメタデータがある。エンドユーザデバイス１０、２０及び３０は、信頼の連鎖（群）の管理を、ブートストラップする、そうでなければ管理するあるいは支援するために使用されるレコードのセットも保持することができる。更に、また、エンドユーザデバイス１０、２０及び３０は、ブランディング情報、例えば、支払取引に関係するロゴをプロビジョンすることができる。

これらの記憶されたデータ要素のいくつかあるいはすべてが、エンドユーザデバイス１０、２０及び３０によって自動的に支払の連鎖に組み込まれ、特に、比較的、安価なコンテンツのリクエストに対する、課金手順の時間と労力の削減に貢献することで、エンドユーザに強いられる負担を軽減する。このデータは、例えば、消費者が、自身の認証とは別に、ワンクリックするだけで、支払方法を識別し、かつその支払を認可するために十分なものである。つまり、このデータは、典型的には、支払機関、支払サービスタイプ、領域等のような情報を示しているが、実際のアカウントＩＤや任意の認証情報は除外され得る。

エンドユーザデバイス１０、２０及び３０に記憶される、上述の情報は、様々な異なる方法でネットワーク側に提供され得る。一実施形態に従えば、このような情報は、エンドユーザデバイス１０、２０及び３０からネットワークに向けて送信されるメッセージ内の、ハイパーテキスト転送プロトコル（ＨＴＴＰ）ヘッダを使用して提供され得る。これらのＨＴＴＰヘッダは、それらが、識別可能な課金情報を指し示しているかどうかを判定するためにネットワーク側でチェックされ得る。この識別可能な課金情報は、例えば、ＨＴＴＰヘッダが、「ｅｏｂｇｗ：ｉｐｘ，１２７．０．０．１，５５７７，ＵＩＤ」あるいは「ｅｏｂｇｗ：ｍａｓｔｅｒｃａｒｄｐｐ，１９．１．２．３，１２３，ＵＩＤ」である。ここで、この例では、ヘッダプリアンブル「ｅｏｂｇｗ」は、純粋な例示としての、エリクソオープン課金ゲートウェイと呼ばれる課金ゲートウェイを示している。これらのＨＴＴＰヘッダは、エンドユーザデバイス１０、２０、３０から、スタンバイ状態にあるウェブブラウザによる追加のソフトウェアアプリケーションで、あるいは、ポスト、クッキー、ユーザエージェントプロファイル（ＵＡＰｒｏｆ）あるいはその類で自身がカプセル化されて、送信されることになる。この状況での用語「ポスト（post）」は、ＨＴＴＰ ＰＯＳＴ方法を示していて、これは、アプリケーションに、データをブラウザからサーバへサブミットさせることを可能にする。

例えば、自身のウェブブラウザを介して、販売業者のウェブページに入ると、エンドユーザデバイス１０、２０、３０は、代替の支払方法、支払プリファレンス及びエンドユーザに受け入れることができない支払方法の少なくともいずれかに関する情報を用いて、追加のＨＴＴＰヘッダのセットを販売業者のサーバに提示することができる。この情報は、ＵＲＬ、クッキーあるいはＨＴＴＰヘッダの形式で提供することができる。実施形態に従うエンドユーザデバイスによって販売業者のサーバに提示される、以下のＨＴＴＰヘッダのセットの例について検討する。

例１：
ＥＯＢＧＰ：http://bgw.visa.com/uid,preferene 1
ＥＯＢＧＰ：http://bgw.b2.net/*,preference-1(blacklist)
ＥＯＢＧＰ：http://bgw.fsb.se/pnum,preferene 2
ＥＯＢＧＰ：http://bgw.paypal.com/06128@mail.com,preferene 100
エンドユーザデバイス１０、２０、３０によって提供されるこれらの情報のセットから、販売業者は、提供される場合の優先順位を考慮して、特定のユーザに向けられている課金方法のセットを判定する。例えば、販売業者のサーバは、販売業者が所有する課金ゲートウェイの候補のリストとユーザのリストとをマッチングして、両方のリストで検出される最高ランクの課金ゲートウェイを選択することができる。販売業者のサーバは、例えば、「ペイパル（paypal）を介して支払を行うための＜ＰＡＹ＞の押下」のメッセージをエンドユーザデバイスへ返信するために使用する、課金ゲートウェイの選択を行うことができる、あるいは、エンドユーザに対して選択するための課金ゲートウェイのリストを返信することができる。例えば、ＨＴＴＰヘッダを介して、販売業者と直接、支払プリファレンス情報を提供することの代替としては、エンドユーザデバイス１０、２０、３０は、選択的に、エンドユーザの支払プリファレンス情報が記憶され、かつ販売業者のサーバによってアクセスすることができるネットワーク上の位置を示すＵＲＬを販売業者のサーバへ送信することができる。

エンドユーザデバイス１０、２０、３０は、支払方法情報を、上述のプッシュメカニズムとして、あるいは、コンテンツあるいはサービスプロバイダからのトリガーあるいはリクエストに応じるプルメカニズムとして提示することができる。例えば、エンドユーザデバイス１０、２０、３０によって閲覧されている販売業者のサイトからのリクエストで、エンドユーザデバイスは、これらのＵＲＬを販売業者（あるいは他のネットワークサーバＵＲＬ）へ送信して、ユーザが所有するあるいは希望する支払に対するメカニズムを示すことができる。これらのＵＲＬは、各支払方法に対する顧客のプリファレンス、例えば、上述の例示の数字によるランキングを示すためのマーカを有していても良い。販売業者は、これらのＵＲＬのセットを受信し、それと、ユーザが支払チャネルとして受け入れることができる、ユーザが所有するＵＲＬのリストとマッチングする。販売業者のリストは、長いものであってよく、また、エンドユーザに対して公表されるあるいは提示される必要がない（但し、以下の他の実施形態では、そのような公表メカニズムを提供している）。これは、販売業者の潜在的な課金ゲートウェイ群／支払方法群のリストにおける多くのエントリは、たいては、特定の消費者とは無関係であるからである。販売業者とユーザとの両者によってサポートされる、マッチングするリストの支払方法の内、販売業者は、この時点で、あまり魅力的でないあるいはあまり好ましくないものを削除することができ、好適なものだけをエンドユーザデバイス１０、２０、３０を介して、その顧客に公表することができる。オプションとしては、販売業者は、自身の最も好適な支払方法をリストに追加して、例えば、エンドユーザに対して推奨する／広告することができる。使用することができる支払方法のリストが完了すると、そのリストを選択することができる消費者へ提示され、販売業者は、選択される課金ゲートウェイに向けて消費者をリダイレクトすることができる。エンドユーザの観点から支払を簡単にすることに加えて、販売業者は、どの支払方法が自身の市場区分で好適であるかを測定して、それに従って動作することができるようになる。

支払情報をプルするために、エンドユーザデバイスへ向けて販売業者あるいはコンテンツプロバイダによって送信されるトリガーは、これらの実施形態に従って様々な形式で実現することができる。例えば、一実施形態に従えば、このトリガーは、エンドユーザデバイス１０、２０、３０から、記憶されている支払方法の情報を読み出すことができるジャバスクリプトとして実現することができる。この動作は、オプションとして、エンドユーザの承認を条件としても良い。支払方法の情報をプルするためのトリガーとしてジャバスクリプトを使用することは、更なる利点を提供する。その利点とは、トリガー自身に従う、ＡＪＡＸ通信あるいは同様の「帯域外」シグナリングの形式で、その情報を埋め込むことができることである。別の実施形態に従えば、エンドユーザデバイスから支払方法の情報をプルするためのトリガーとして、専用のメタタグを使用することができる。例えば、メタタグ＜ｍｅｔａ ｈｔｔｐ−ｅｑｉｖ＝”ＥＯＢＧＷ” ｃｏｎｔｅｎｔ＝”ｈｔｔｐ：／／ＵＲＬ”＞を、エンドユーザデバイスへ送信することができる。ここで、メタタグは、追加の、例えば、関連する支払方法、ＨＴＴＰヘッダあるいはクッキーに埋め込まれているデータを伴う、指定されているＵＲＬへのリダイレクトをトリガーするものである。

上述の内容に基づいて、例示の技術は、エンドユーザの支払方法の情報と、特定の販売業者あるいはコンテンツプロバイダへの支払用の適切な課金ゲートウェイの選択を管理するためのものであり、実施形態に従う課金ゲートウェイを選択するための一般的な方法が、例えば、エンドユーザデバイスによって、図２のフローチャートで示されることが理解されるであろう。図２で示されるように、エンドユーザデバイス１０、２０、３０は、ステップ２０２において、課金ゲートウェイのリストを受信する。ここで、例えば、リストは、上述の技術の任意のものあるいはすべてを使用してコンパイルされている。ステップ２０４において、エンドユーザとエンドユーザデバイスの少なくとも一方は、そのリストから課金ゲートウェイの１つを選択する。ステップ２０６によって示されるように、この選択は、例えば、エンドユーザデバイスでトランザクションを完了する際に使用するためのリストから課金ゲートウェイの１つの選択を識別するメッセージを送信することによって、エンドユーザデバイスによって送信される。必要であれば、エンドユーザデバイス１０、２０、３０は、ユーザが導入している課金ゲートウェイと、ユーザが導入している課金ゲートウェイに関連付けられている情報とのうちの少なくとも１つを含むメッセージを最初に送信することができ、そうすることで、エンドユーザデバイスによって続いて受信される課金ゲートウェイのリストは、ユーザが導入している課金ゲートウェイ、あるいは、ユーザが導入している課金ゲートウィに関連付けられている情報のどちからの少なくとも一部に基づくことになる。

つまり、デバイス３００、例えば、本実施形態に従うエンドユーザデバイスが、図３に示される。その内部では、ユーザエージェント３０８が、コンテンツをリクエストし、かつ上述のような受信したメッセージに基づくエンドユーザの選択結果を送信するための、上述のソフトウェアアプリケーションとして動作する。通信インタフェース３１０は、リクエストされたコンテンツに関連付けられている課金情報に関連付けられているメッセージを送受信する。これには、課金ゲートウェイのリストの受信と、リスト内の課金ゲートウェイの１つの選択結果の送信を含んでいる。メモリ３０４は、リクエストされたコンテンツに対する、例えば、支払プリファレンスに関連する様々な情報を記憶している。プロセッサ３０２は、メモリ３０４と通信インタフェース３１０と通信して、そのプロセッサ３０２上でユーザエージェント３０８が動作する。また、プロセッサ３０２は、エンドユーザデバイス３００の動作を制御する。

ネットワーク側
ここまでは、エンドユーザデバイス１０、２０及び３０に関連付けられている、少なくとも主要な実施形態を説明してきている。次に、支払方法あるいは課金ゲートウェイのネゴシエーション及び選択の少なくとも一方を容易にするための、ネットワーク側で使用することができる例示の技術及びメカニズムについて説明する。但し、以下で説明されるように、以下の実施形態のいくつかは、支払に関連付けられているサービス以外のサービス、例えば、ビデオ配信サービスあるいは他のサービス群、の選択あるいはロケーション（サービス発見：location）を実現するために使用することができる。

エンドユーザ側の技術の議論で説明されるように、エンドユーザデバイス１０、２０、３０は、ユーザの支払方法のプリファレンス及びケイパビリティの少なくとも一方に関連付けられている情報を、コンテンツプロバイダ１１２、１１６、１２８に提供することができる。しかしながら、他の実施形態に従えば、エンドユーザデバイス、及び自身のＩＳＰ／オペレータ１０４、１２２の少なくとも一方に利用可能な支払方法を、ネットワーク側に判定させることができる。このような場合、ネットワーク側は、潜在的な支払オプションを判定するための開始ポイントとして、消費者のＩＰアドレスのみを有することができる。以下の実施形態に従えば、消費者のＩＰアドレスを使用して、販売業者あるいはコンテンツプロバイダ１１２、１１６、１２８は、リバースＤＮＳルックアップを行う。このリバースＤＮＳルックアップは、既知のＩＰアドレスを使用することと、例えば、ＤＮＳに記憶されているポインタ（ＰＴＲ）を使用することによって、そのＩＰアドレスに属するホストネームとドメインネームをルックアップすることを含むことが、当業者には理解されるであろう。ＰＴＲレコードは、ＩＰアドレスを基準のホスト／ドメインネームにマッピングする。この特定のエンドユーザデバイス１０、２０、３０に関連付けられているＩＳＰ／オペレータは、支払方法を提案し、かつＤＮＳ１０６、１２４にこれらの支払方法を登録している場合、ＤＮＳ１０６、１２４は、ＵＲＬ（群）を、リクエストしているコンテンツプロバイダ１１２、１１６、１２８に対してサポートされている支払ゲートウェイ（群）へ返信する。これらのＵＲＬ群は、支払サービス（例えば、特定の支払方法を使用して行われる購入に対するエア「マイレージ」で、ユーザをクレジットする支払方法）に価値を付加することができるＩＳＰ／オペレータに対する様々なパートナーを指し示すことで、そのよう役割のためのビジネスを生み出すことができる。これらの例示の実施形態はＤＮＳに基づいているので、これらは、潜在的な支払方法の識別を実現することができる。ここで、潜在的な支払方法とは、関連するウェブ端末、携帯端末あるいは固定デバイスの構成設定を伴わないあるいはわずかな構成設定で、販売業者とエンドユーザ１０、２０、３０の両方に受け入れ可能となるものである。本明細書で使用される役割と関連する用語を明確にするために、用語「オペレータ」は、例えば、ＩＳＰあるいは他のパーティを指し示している。ここで、ＩＳＰあるいは他のパーティは、サーチ（検索）が実行されるＤＮＳを所有すること及び操作することの少なくとも一方を実行する。用語「エンドユーザ」は、コンテンツ、サービス、あるいは商品の配信の、消費者あるいはエンドユーザの買い手を指し示している。用語「コンテンツプロバイダ」は、エンドユーザによってリクエストされる、コンテンツ、サービスあるいは商品の販売業者あるいは売り手であるパーティをを指し示していて、また、これは、リバースＤＮＳを開始するパーティであっても良い。用語「支払プロバイダ」あるいは「手形交換所」は、サービスを提供するために、オペレータと協働するサードパーティを指し示している。コンテンツプロバイダは、コンテンツ、サービス及び商品の少なくとも１つの売り手であるとともに、これらのサービス及び商品の少なくとも一方のプロバイダの両方であっても良く、あるいはそうでなくても良い。エンドユーザへコンテンツ、サービス及び商品の少なくとも１つを提供するエンティティは、そのエンティティがコンテンツプロバイダであるか否かに関わらず、本明細書では、「サービスプロバイダ」と呼んでいる。

これらの実施形態をより理解するために、以下で、純粋な例示を検討する。エンドユーザデバイス１０がオペレータ２０８に接続する場合に、エンドユーザデバイス１０が１３０．１３．９７．５５のパブリックＩＰアドレス（時には、インターネットアドレスあるいはＷＡＮ割当ＩＰアドレスとして知られる）を受信すると想定する。このＩＰアドレスは、この例では、ｖｄｓｌ−１３０−１３−９７−５５．ｐｈｎｘ．ｑｕｅｓｔ．ｎｅｔに解決される。次に、エンドユーザは、コンテンツ、例えば、着信音を、コンテンツプロバイダ２１２から、自身の携帯電話にダウンロードするために注文することを決定する。コンテンツプロバイダ２１２は、この特定のＩＰアドレスに対して正式なものである課金ゲートウェイを検出するために、ＤＮＳサーバ情報を使用するサーチ（検索）を実行する。次に、オペレータ２０４は、ｖｄｓｌ−１３０−１３−９７−５５．ｐｈｎｘ．ｑｕｅｓｔ．ｎｅｔに関連付けられているテキストレコード（ＴＸＴ）に対するルックアップを実行し、識別可能な課金情報を探す。識別可能な課金情報がそのアドレス内で検出されない場合、コンテンツプロバイダ２１２は、例えば、そのテキストレコードに対するｐｈｎｘ．ｑｕｅｓｔ．ｎｅｔをサーチすることによって、ある程度正確なマッチングを実行することができ、そして、先頭のドメインだけが残るまでこのサーチを繰り返す。このサーチは、例えば、５５．９７．１３．１３０．ｉｎ−ａｄｄｒ．ａｒｐａにおけるＴＸＴレコードを検出することを試行することによって、純粋なＩＰアドレスについても実行することができ、サーチされない場合、必要に応じて、５５、９７及び１３をスケーリングする。識別可能な課金情報には、これに制限されるものではないが、プロトコル情報、プロトコルとは独立しているＢＧＷのＩＰアドレス／ポート、及び様々なプロトコルを有する複数のＢＧＷを含むことができる。

すべてのＤＮＳサーチが一旦完了すると、コンテンツプロバイダ２１２は、それぞれのＢＧＷに渡るサーチの結果として識別される課金プロバイダのそれぞれと接続することができ、また、存在するならば、各課金プロバイダ及びコンテンツプロバイダ２１２と、オペレータ２０４と、及びエンドユーザデバイス１０との間に、信頼関係の連鎖（特定のＩＰアドレスで識別され、かつ特定のエンドユーザに関連付けられている）が存在するかを判定する。エンドユーザが課金ゲートウェイのリストを有している場合、コンテンツプロバイダは様々な課金ゲートウェイのセットととの信頼関係を有していて、これにより、コンテンツプロバイダの課金ゲートウェイの１つから顧客までの信頼されている経路に対する、ユーザの課金ゲートウェイのそれぞれに再帰的に問い合わせることができる。例えば、エンドユーザがマスタカードと、オペレータ２０８のアカウントと、市民銀行のアカウントと、地方信用組合のアカウントを有しているとする。オペレータ２０８は、エンドユーザに関連付けられているアカウントを有していて、マスタカード、ＶＩＳＡ及び市民銀行を利用可能である。コンテンツプロバイダ２１２は、マスタカード、ＶＩＳＡ及びオペレータ２０８を認識する。サーチの結果と、判定された信頼関係の連鎖を使用することによって、潜在的な課金プロバイダのリスト、例えば、マスタカードとオペレータ２０８を含むリストが構築される。次に、このリストが、所望の課金プロバイダを選択するために、ユーザ用のエンドユーザデバイス１０へ送信される。所望の課金プロバイダの選択においては、ユーザは、課金の検証を完了するために、選択された課金プロバイダの課金ゲートウェイへリダイレクトされる。また、この時点で、このコンテンツプロバイダとの将来の課金に対するオプションの認可をセットアップすることができる。この課金のステップが完了すると、エンドユーザは、再度、コンテンツプロバイダ２１２へリダイレクトされ、そうすることで、コンテンツプロバイダは、コンテンツ、あるいは送信された商品に対する受領書情報を送信することができる。

上述の実施形態に従えば、コンテンツプロバイダ２１２は、ＤＮＳサーチ（あるいはリバースＤＮＳサーチ）を実行して、自身と、エンドユーザデバイス１０、２０、３０との両方に対して相互に受け入れ可能となる支払方法／課金ゲートウェイを識別することができる。それゆえ、他の実施形態に従えば、オペレータに、受け入れられるあるいは提案される支払方法をＤＮＳ１０６、１２４へ公表するための技術を提供することは有用である。例えば、ＵＲＬ（群）と、ＤＮＳ内でサポートされる支払ゲートウェイ（群）に関連付けられている補助的なメタデータを公表することによって、オペレータは、例えば、コンテンツプロバイダによる上述のサーチを容易にするために、この情報を任意の外部のパーティに容易にアクセス可能にすることができる。この実施形態に従えば、これらのＵＲＬ（群）と、任意の補助的なメタデータは、サードパーティへの支払をサポートすることができるオペレータ所有の課金システムを含むだけでなく、オペレータと自身の加入者基盤が加入している他の支払プロバイダを含むことができる。ＵＲＬ（群）のリストは、加入者基盤のメンバーに利用可能な支払プロバイダのセットを表している。これは、例えば、自身の基本の課金システムに対する代替を提案するための機会をオペレータに提供する。この基本の課金システムでは、例えば、エンドユーザに、自身のオペレータのサービス請求の代替とともに、選択されたチャリティーに送信される追加料金の割合を提案することができる。

オペレータが受け入れるあるいは好ましい支払方法を公表するために、提供するＤＮＳレコードの変形あるいはその追加を、これらの実施形態に従う任意の方法で実行することができる。例えば、オペレータ１０４、１２２は、例えば、サポートされている支払ゲートウェイを識別するＴＸＴレコードを、自身のそれぞれのＤＮＳ１０６、１０４に入力することができる。このような支払ゲートウェイに対して、複数の構文あるいは標準が存在する場合、オペレータ１０４、１２２は、そのようなすべての構文あるいは、サポートしたいものだけを入力することができる。

上述したように、これらの例示のネットワーク側の実施形態は、支払方法の公表、及び支払方法のサーチに限定されるものではなく、他のタイプのサービスの公表、及び他のタイプのサービスのサーチに適用することができる。例えば、ビデオサービス、例えば、ＩＰＴＶの環境においては、コンテンツプロバイダ１１２は、エンドユーザデバイス１０、２０、３０に直接ビデオコンテンツを送信する代わりに、キャッシングサーバ（不図示）に送信することもできる。このようなキャッシングサーバが特定のエンドユーザデバイス１０に対して配置されているかどうか、またどこに存在するかを判定するために、コンテンツプロバイダ１１２は、そのエンドユーザのオペレータ１０４のＤＮＳ１０６に問い合わせることができる。オペレータ１０４が、自身のＤＮＳ１０６内のそのようなビデオコンテンツ（あるいはキャッシングサーバがそのようなビデオコンテンツを登録している場合）に対する自身のキャッシングサーバのアイデンティティ／アドレスを公表している場合、コンテンツプロバイダ１１２は、その情報を取得して、エンドユーザデバイス１０への次の配信のために、エンドユーザによってリクエストされているビデオコンテンツをキャッシングサーバへ送信することになる。より一般的には、ＤＮＳ１０６、１２４は、自身の中に自身で登録することを選択する任意の、かつあらゆるタイプのサービスに対するサービスブローカとして動作することができ、これによって、例えば、事前にネゴシエートされているサービスの契約に対する要件に関連付けられている制約を取り除くことができる。

例えば、ネットワーク側のサービスの発見、例えば、支払方法情報の発見を管理するための上述の例示の技術に基づいて、実施形態に従うサービスの発見のための一般的な方法が図４のフローチャートで示されることが理解されるであろう。図示されるように、サービスプロバイダによって提供される特定のタイプのサービスを発見するための方法は、例えば、特定のサービスに対して関心のあるエンドユーザデバイスのＩＰアドレスに基づいて、リバースドメインネームサーバ（ＤＮＳ）サーチを実行するステップ４００を含んでいる。次に、ステップ４０２で、サービスに関連付けられている少なくとも１つのエントリが、リバースＤＮＳサーチに基づいて、サービスプロバイダに関連付けられているＤＮＳから取得される。

同様に、ネットワーク側の実施形態を実行することができるネットワークノードは、通常は、（また、汎用のエンドユーザデバイスを説明するためにも使用されている）図３で説明することができる。このようなネットワークノードは、例えば、プロセッサ３０２を含むことができ、このプロセッサ３０２は、リバースＤＮＳサーチを実行して、オペレータに関連付けられているＤＮＳ（１０６、１２４）からサービスに関連付けられている少なくとも１つのエントリを取得することによって、オペレータ１０４、１２２によって提供される特定のタイプのサービスを発見する。

上述の例は、支払サービスを発見する環境で提供されているが、これらの実施形態は支払サービスの発見／プロビジョンに制限されるものではなく、実際には、リバースＤＮＳサーチを介して発見することができる任意のタイプのサービスに適用することが理解されるであろう。例えば、上述の方法で発見することができる他のサービスには、（１）例えば、ＧＰＳ、ＴＯＡ、ＴＤＯＡ、及び他のロケーションベースのサービスの少なくとも１つを介して、エンドユーザの位置を提供することができる位置決めサーバを検出すること、（２）エンドユーザプロファイルデータ用のサーバを検出すること、（３）（例えば、キーを発見するための）ＤＲＭサーバを検出すること、及び（４）利用可能なメディアリソースサーバを検出することを含んでいる。また、上述の例は、リバースＤＮＳサーチがコンテンツプロバイダによって開始される場合を説明しているが、例えば、ネットワーク上の自身が所有するＤＲＭサーバを発見することをエンドユーザに可能にするために、リバースＤＮＳサーチは、所望のサービスを発見することに関心のある任意のパーティによって実行されても良い。この任意のパーティには、例えば、サービスプロバイダ、オペレータ、あるいは、エンドユーザさえも含んでいる。

例示の対話
上述のように、上述のエンドユーザ側の技術と、ネットワーク側の技術は、様々な実施形態にしたがって、一方とは独立して、あるいは一方とともに使用することができる。これらの実施形態をより理解するために、エンドユーザ側の技術とネットワーク側の技術との間のいくつかの対話例を、図５の例示のシグナリング図とともに提示する。この純粋な例示のシグナリグ図は、潜在的なオペレータの課金ゲートウェイ（ＢＧＷ）群のリストを受信して、かつ、特定のコンテンツプロバイダあるいは販売業者と後続の支払手順を実行するためにこれらのＢＧＷ群から選択されたＢＧＷ（この例では、ＢＧＷ５０４）を使用するために、エンドユーザ５０２が関与する信号群を示している。

典型的には、図５のシグナリング図の開始の時点で、エンドユーザデバイス１０は、自身のオペレータ１０８を介してネットワークに既に接続されていて、かつ、固有識別子、例えば、ＷＡＮ割当ＩＰアドレスを受信している。最初に、ユーザ５０２が、メッセージ５０６において、コンテンツプロバイダ１１２から、デバイス１０に対するプレミアムコンテンツをリクエストすると想定する。コンテンツプロバイダ１１２は、メッセージ５０８において、課金リクエストを伴うリプライを行う。ユーザ５０２は、オプションで、メッセージ５１０において、例えば、ＨＴＴＰヘッダ内にあるいはクッキー（群）として埋め込まれている、取り得る支払の代替と、ユーザ推奨ＢＧＷ群で応答する。次に、コンテンツプロバイダ１１２は、それに関連付けられているＤＮＳサーバ１１４と、オペレータのＤＮＳサーバ１０６と協働して、信号５１２及び５１４で示されるように、ＢＧＷ群に基づいてＤＮＳを解決するために、上述のように、ＤＮＳ、リバースＤＮＳ技術、及び、ＨＴＴＰヘッダ等を使用するサーチを実行する。次に、メッセージ５１６において、オペレータのＢＧＷ群のリストが、コンテンツプロバイダ１１２へ送信される。次に、サーチを通して検出されている、及び／あるいは、ユーザ５０２、オペレータ１０８及びコンテンツプロバイダ１１２によって直接提供されている、様々なＢＧＷ群が、マージされて、メッセージ５１８において、ユーザ５０２へ送信される。

この例では、ユーザ５０２は、使用するための所望のＢＧＷとしてオペレータのＢＧＷ５０４を選択し、メッセージ５２０において、その情報をコンテンツプロバイダ１１２へ送信する。次に、コンテンツプロバイダ１１２は、メッセージ５２２において、オペレータのＢＧＷ５０４へ契約書を送信する。また、コンテンツプロバイダ１１２は、メッセージ５２４によって示されるように、オペレータのＢＧＷ５０４へユーザをリダイレクトする。次に、ユーザ５０２は、メッセージ５２６において、選択されたオペレータのＢＧＷ５０４から契約書をリクエストする。オペレータのＢＧＷ５０４は、メッセージ５２８において、ユーザ５０２に、所望のコンテンツに対する契約書を送信し、また、オプションとして、再発し得る課金のための認可リクエストを送信する。次に、ユーザ５０２は、メッセージ５３０において、支払を認可する。次に、オペレータのＢＧＷ５０４は、メッセージ５３２において、再度、ユーザ５０２を、コンテンツプロバイダ１１２へリダイレクトする。次に、ユーザ５０２は、メッセージ５３４において、選択されたコンテンツをコンテンツプロバイダ１１２からリクエストする、あるいは、送信されているコンテンツに対する受領書をリクエストする。次に、コンテンツプロバイダは、メッセージ５３６及び５３８において示されるように、オペレータのＢＧＷ５０４との契約状態の検証を実行する。この時点で、メッセージ５４０によって示されるように、受領書あるいはコンテンツがコンテンツプロバイダ１１２から送信される。

（オペレータではなく）サードパーティの課金ゲートウェイが介在する別の実施形態に従えば、潜在的な課金ゲートウェイ（ＢＧＷ）群のリストを受信し、かつサードパーティのＢＧＷを使用するために、エンドユーザ５０２が介在する信号群を示す例示のシグナリング図が、図６で示される。図６では、オペレータのＢＧＷ５０４が、図５との比較目的のために単に示されているが、これは、図６で示される例では通信は発生しない。典型的には、図６のシグナリングが開始する時点で、エンドユーザデバイス１０は、自身のオペレータ１０８を介してネットワークに既に接続されていて、また、固有の識別子、例えば、ＷＡＮ割当ＩＰアドレスを受信している。

最初に、ユーザ５０２は、メッセージ６０２において、コンテンツプロバイダ１１２からデバイスに対するプレミアムコンテンツをリクエストする。コンテンツプロバイダ１１２は、メッセージ６０４において、課金リクエストを伴うリプライを行う。ユーザ５０２は、オプションで、メッセージ６０６において、ＨＴＴＰヘッダ内にあるいはクッキー（群）として埋め込まれている、取り得る支払の代替と、ユーザ推奨ＢＧＷ群で応答する。次に、コンテンツプロバイダ１１２は、それに関連付けられているＤＮＳサーバ１１４と協働して、信号６０８で示されるように、ＢＧＷ群に基づいてＤＮＳを解決するために、上述のように、ＤＮＳ、リバースＤＮＳ技術、及び、ＨＴＴＰヘッダ等を使用するサーチを実行する。次に、メッセージ６１０において、それらの結果、例えば、オペレータのＢＧＷ群の解決されたリストが、コンテンツプロバイダ１１２へ送信される。次に、サーチを通して検出されている、及び／あるいは、ユーザ５０２、オペレータ１０８及びコンテンツプロバイダ１１２によって直接提供されている、様々なＢＧＷ群が、マージされて、メッセージ６１２において、ユーザ５０２へ送信される。

この例では、ユーザ５０２は、サードパーティのＢＧＷ１２０、例えば、ＶＩＳＡ（ビザ）に関連付けられている課金ゲートウェイを、受信したリストから選択し、メッセージ６１４において、その情報をコンテンツプロバイダ１１２へ送信する。次に、コンテンツプロバイダ１１２は、メッセージ６１６において、サードパーティ１２０へ契約書を送信する。また、コンテンツプロバイダは、メッセージ６１８によって示されるように、ユーザをサードパーティのＢＧＷ１２０へリダイレクトする。また、コンテンツプロバイダは、メッセージ６１８によって示されるように、ユーザをサードパーティのＢＧＷ１２０にリダイレクトする。次に、ユーザ５０２は、メッセージ６２０において、選択されたサードパーティのＢＧＷ１２０からその契約書をリクエストする。サードパーティのＢＧＷ１２０は、メッセージ６２２において、ユーザ５０２に、所望のコンテンツに対する契約書を送信し、また、オプションとして、再発し得る課金のための認可リクエストを送信する。次に、ユーザ５０２は、メッセージ６２４において、支払を認可する。次に、サードパーティのＢＧＷ１２０は、メッセージ６２６において、再度、ユーザ５０２を、コンテンツプロバイダ１１２へリダイレクトする。次に、ユーザ５０２は、メッセージ６２８において、選択されたコンテンツをコンテンツプロバイダ１１２からリクエストする、あるいは、送信されているコンテンツに対する受領書をリクエストする。次に、コンテンツプロバイダは、メッセージ６３０及び６３２において示されるように、サードパーティのＢＧＷ１２０との契約状態の検証を実行する。この時点で、メッセージ６３４によって示されるように、受領書あるいはコンテンツがコンテンツプロバイダ１１２から送信される。

図６に示されるように、コンテンツプロバイダ１１２は、課金リクエストを提供するメッセージ６０４をユーザ５０２へ送信する。本実施形態に従えば、他の情報は、ユーザからの応答メッセージ６０６に含めることができる。例えば、ユーザに提供されるＢＧＷそれぞれに対するＩＰアドレスを含めることができる。また、提供されるＢＧＷそれぞれに対する顧客を識別する顧客識別情報として、例えば、ユーザのアカウント情報、パーソナル識別番号（ＰＩＮ）、あるいはその類、それに加えて、ユーザに提供されるＢＧＷそれぞれによって使用されるプロトコルを提供することで、コンテンツプロバイダ１１２と、ユーザに提供されるＢＧＷの任意のものとの間のデータ交換を容易にすることができる。

本実施形態に従えば、エンドユーザ５０２に提示されるＢＧＷ群のリストは様々な方法で修正することができる。例えば、コンテンツプロバイダ１１２は、ユーザ５０２によって提供されるＢＧＷ群のリストを取得して、コンテンツプロバイダ１１２の課金ゲートウェイ群の１つから顧客への、信頼されている経路について、ユーザ５０２に提示されるＢＧＷ群のそれぞれを再帰的に問い合わせることができる。信頼される経路を確立できない場合、対応するＢＧＷはリストから削除され、信頼が欠如している経路であることを示すために適切にマークされる、そうでなければ、識別されるようにする。加えて、このリストは、ユーザ５０２の観点から、あるいはコンテンツプロバイダ１１２の観点から、最も好ましいものからそうでないものまで（あるいはその逆）を提示する、あるいはランク付けすることができる。例えば、様々なサードパーティのＢＧＷは、様々なサービス料金を課して良く、ユーザ５０２は、自身のプリファレンスを設定することができるので、最低の追加料金のＢＧＷがリストの先頭に配置されるようにする。このリストの優先順位を決めるための別の方法は、例えば、リストの先頭に、決して使用されるべきでないＢＧＷを配置することである。このリストの優先順位を決めるための別の方法は、エンドユーザ５１２及びコンテンツプロバイダ２１２の少なくとも一方の要望に沿うように使用することができるようにする。一実施形態に従えば、エンドユーザデバイス５０２にダウンロードされるソフトウェアは、セットアップ時と、エンドユーザ５０２によって指定されるＢＧＷのリストの記憶時に使用することができる。

上述のシステム及び方法を利用して、ＢＧＷを迅速かつ容易に選択するための実施形態について説明する。ユーザ５０２がインターネットサーフィンをしていて、２ドルの購読料金で新聞を読みたいと想定する。ユーザ５０２は、インターネットサーフィンしている自身のウェブブラウザと対話する例示のソフトウェアアプリケーションを有している。加えて、ユーザ５０２、新聞社、いくつかの課金ゲートウェイとの間に信頼関係の連鎖が予め確立されているとする。予め記憶されているプリファレンスを使用して、ユーザ５０２が読むための新聞を選択することを選ぶ場合、ユーザ５０２は、所望の課金ゲートウェイ、この場合は、自身のインターネットサービスプロバイダの課金ゲートウェイに案内される。ユーザ５０２は、アカウント確認用のＰＩＮを入力することが問い合わせされる。ユーザの入力したＰＩＮが受け付けられると、ユーザ５０２は、新聞社のウェブサイトにリダイレクトされ、それにより、ユーザ５０２は、その選択した新聞を自由に読むことができる。

本明細書で使用される課金ゲートウェイは、例えば、通信システムあるいはサービスに関連付けられている課金データを収集し、かつ取り扱う処理を仲介するエンティティ群あるいはノード群を示している。例えば、複数のベンダーをサポートする課金ゲートウェイは、課金データの収集と取り扱いをより簡単にし、かつ上述のように、かつ、すべての課金データ収集のために、一つに統一され、かつ安定した標準インフェースを顧客管理システム（ＣＡＳ）提供することによって、より効率的にする。この結果、課金データの収集に対するネットワークの複雑さを軽減し、アップグレード中の影響を最小化し、かつ新規のネットワーク要素（ＮＥ）群あるいは後処理システムの統合のコストを削減する。課金ゲートウェイは、呼データレコード（ＣＤＲ）群、インターネットプロトコル（ＩＰ）レコード群、及び他の使用データレコード群（ＵＤＲ群、即ち、ＩＰノードからのログ群及びイベントレコード群）を自動的に収集し、かつ様々なタイプのＮＥからオンラインで収集する。ＣＤＲ群は、自身の最終の宛先へ配信する前に、課金ゲートウェイで処理することができる。

課金ゲートウェイは、いくつかの実施形態に従って、ユーザフレンドリなポータブルグラフィックユーザインタフェース（ＧＵＩ）を備えるクライアント−サーバアーキテクチャとして実現することができる。このポータブルグラフィックユーザインタフェース（ＧＵＩ）は、課金ゲートウェイの構成設定を直接的に行うものである。例えば、オペレータ要員は、ＣＤＲ群がどのようにして収集され、ＣＤＲ群がどのようにして処理され、そして、ＣＤＲ群をどこに配信するかを特定するために、ＧＵＩを使用することができる。本実施形態に従う課金ゲートウェイは、様々なネットワークアーキテクチャ、及び様々な製品ライン、リリース及びベンダーからの様々なＮＥ群から生成される課金データを収集したものの同時使用をサポートする。このネットワークアーキテクチャは、移動通信用のグローバルシステム（ＧＳＭ）、汎用パケット無線システム（ＧＰＲＳ）、広帯域符号分割多元アクセス（ＷＣＤＭＡ）、及びＩＰネットワークがある。課金ゲートウェイによって提供される柔軟な処理能力は、新規のサービスに対して課金すること、かつ課金システムに対する変更を最小限にすることを容易にする。課金ゲートウェイは、ネットワークサイズ及びサービスの変更及び普及を簡単にするだけでなく、異なるフォーマット間の変換、課金データの処理、不正行為検出実現性の改善、及びいくつかの標準プロトコルを使用する課金データの配信もサポートする。

特に、課金ゲートウェイは、以下の例示の機能群のいくつかあるいはすべてを提供する。この機能群には、収集、通信デーモン、コンテンツマネージャ、外部エージェント、収集用の実質的なリアルタイム課金、データベースインタフェース（データベースＮＥ）、処理、フォーマッティング、フィルタリング、連結モジュール、レイティング及び番号解析、ルックアップ、コンフィグレーション、管理、上級コンフィグレーションツールキット、アラーム処理、ロギング、配信、配信用の実質的なリアルタイム課金、データベースインタフェース（データベース後処理システム）、高可用性、クラスタ、災害回復クラスタ、及び冗長サーバがある。

上述の実施形態は、本発明を制限するものではなく、本発明のあらゆる観点における例示であることが意図されている。このような変形及び変更のすべてが、特許請求の範囲によって定義される本発明の範囲及び精神内に含まれるものと想定される。本願の記載で使用されない要素、動作、あるいは命令は、明示しない限り、本発明の基準あるいは本質的要素であると解釈されるべきである。また、本明細書で使用される、冠詞「ａ」は、１つ以上の要素を含むように意図されるものである。

Claims (25)

1. サービスプロバイダ（１０４、１２２）によって提供される特定のタイプのサービスを発見する方法であって、
   リバースドメインネームサーバ（ＤＮＳ）サーチを実行するステップ（４００）と、
   前記リバースＤＮＳサーチに基づいて、ＤＮＳ（１０６、１２４）から、前記サービスに関連付けられている少なくとも１つのエントリを取得するステップ（４０２）とを備え、
   前記少なくとも１つエントリは、前記特定のタイプのサービスのサービスプロバイダを指し示す少なくとも１つのユニフォームリソースロケータ（ＵＲＬ）である
   ことを特徴とする方法。
2. 前記特定のタイプのサービスは、支払サービスであり、
   前記サービスプロバイダは、オペレータ及び支払プロバイダの内の１つであり、
   前記少なくとも１つのＵＲＬは、支払を受け入れるために前記オペレータと前記支払プロバイダの内の１つと対話することができる、少なくとも１つの課金ゲートウェイを指し示している
   ことを特徴とする請求項１に記載の方法。
3. 前記支払サービスは、コンテンツ、サービス及び商品の少なくとも１つの配信に関連付けられている
   ことを特徴とする請求項２に記載の方法。
4. 前記配信は、ストリーミングコンテンツ配信サービスであり、
   前記サービスプロバイダは、インターネットサービスプロバイダ（ＩＳＰ）であり、
   前記少なくとも１つのＵＲＬは、ストリーミングコンテンツ配信を提供するために、前記ＩＳＰと対話することができるキャッシングサーバを指し示している
   ことを特徴とする請求項３に記載の方法。
5. 前記取得するステップは、
   前記特定のタイプのサービスをリクエストしているエンドユーザデバイスのＩＰアドレスを使用する、リバースＤＮＳルックアップ動作を実行するステップを更に備える
   ことを特徴とする請求項１に記載の方法。
6. 前記取得される少なくとも１つのエントリに基づいて、前記オペレータによって提案される支払方法を識別するステップと、
   前記コンテンツプロバイダによって識別される支払方法から支払方法を選択するステップと、
   前記選択された支払方法をエンドユーザデバイスへ提示するステップと
   を更に備えることを特徴とする請求項３に記載の方法。
7. 対応する前記サービスプロバイダの機能を公表するために、前記少なくとも１つのエントリとして、テキストエントリを、前記特定のタイプのサービスを指し示す前記ＤＮＳへ追加するステップを更に備える
   ことを特徴とする請求項１に記載の方法。
8. 前記リバースＤＮＳサーチを実行するステップは、
   エンドユーザによって前記リバースＤＮＳサーチを開始するステップを更に備え、
   前記特定のサービスは、デジタル著作権管理（ＤＲＭ）サービスであり、
   前記エンドユーザは、少なくとも１つのＤＲＭキーを取得するために、前記取得されたＵＲＬを使用する
   ことを特徴とする請求項１に記載の方法。
9. 前記リバースＤＮＳサーチを実行するステップは、
   コンテンツプロバイダによって前記ＤＮＳサーチを開始するステップを更に備え、
   前記特定のサービスは、ロケーションサービスであり、
   前記コンテンツプロバイダは、エンドユーザの位置を取得するために、前記取得されたＵＲＬを使用する
   ことを特徴とする請求項１に記載の方法。
10. 前記リバースＤＮＳサーチを実行するステップは、
    支払プロバイダによって前記リバースＤＮＳサーチを開始するステップを更に備える
    ことを特徴とする請求項１に記載の方法。
11. 装置であって、
    リバースドメインネームサーバ（ＤＮＳ）サーチを実行することによって、サービスプロバイダ（１０４、１２２）によって提供される特定のタイプのサービスを発見し、かつＤＮＳ（１０６、１２４）から前記サービスに関連付けられている少なくとも１つのエントリを取得するプロセッサ（３０２）とを備え、
    前記少なくとも１つのエントリは、前記特定のタイプのサービスのサービスプロバイダを指し示す少なくとも１つのユニフォームリソースロケータ（ＵＲＬ）である
    ことを特徴とする装置。
12. 前記特定のタイプのサービスは、支払サービスであり、
    前記サービスプロバイダは、オペレータ及び支払プロバイダの内の１つであり、
    前記少なくとも１つのＵＲＬは、支払を受け入れるために前記オペレータと前記支払プロバイダの内の１つと対話することができる、少なくとも１つの課金ゲートウェイを指し示している
    ことを特徴とする請求項１１に記載の装置。
13. 前記支払サービスは、コンテンツ、サービス及び商品の少なくとも１つの配信に関連付けられている
    ことを特徴とする請求項１２に記載の装置。
14. 前記配信は、ストリーミングコンテンツ配信サービスであり、
    前記サービスプロバイダは、インターネットサービスプロバイダ（ＩＳＰ）であり、
    前記少なくとも１つのＵＲＬは、ストリーミングコンテンツ配信を提供するために、前記ＩＳＰと対話することができるキャッシングサーバを指し示している
    ことを特徴とする請求項１３に記載の装置。
15. 前記プロセッサは、前記特定のタイプのサービスをリクエストしているエンドユーザデバイスのＩＰアドレスを使用する、リバースＤＮＳルックアップ動作を実行する
    ことを特徴とする請求項１１に記載の装置。
16. 前記プロセッサは、前記取得される少なくとも１つのエントリに基づいて、前記オペレータと前記支払プロバイダの内の１つによって提案される支払方法を識別し、前記コンテンツプロバイダによって識別される支払方法から支払方法を選択し、前記選択された支払方法をエンドユーザデバイスへ提示する
    ことを特徴とする請求項１３に記載の装置。
17. 前記プロセッサは、対応する前記サービスプロバイダの機能を公表するために、前記少なくとも１つのエントリとして、テキストエントリを、前記特定のタイプのサービスを指し示す前記ＤＮＳへ追加する
    ことを特徴とする請求項１１に記載の装置。
18. 前記装置は、エンドユーザデバイス、コンテンツプロバイダに関連付けられているネットワークノード、サービスプロバイダに関連付けられているネットワークノード、支払プロバイダに関連付けられているネットワークノードの内の１つである
    ことを特徴とする請求項１１に記載の装置。
19. 前記特定のタイプのサービスは、支払サービス、エンドユーザデバイスの位置を検出するロケーションサービス、エンドユーザプロファイルデータサービス、デジタル著作権管理（ＤＲＭ）サービス、及び利用可能なメディアリソースサービスの内の１つである
    ことを特徴とする請求項１１に記載の装置。
20. コンピュータあるいはプロセッサによって実行される場合のプログラム命令を含むコンピュータ可読記憶媒体であって、
    リバースドメインネームサーバ（ＤＮＳ）サーチを実行するステップ（４００）と、
    前記リバースＤＮＳサーチに基づいて、ＤＮＳ（１０６、１２４）から、前記サービスに関連付けられている少なくとも１つのエントリを取得するステップ（４０２）とを備え、
    前記少なくとも１つエントリは、前記特定のタイプのサービスのサービスプロバイダを指し示す少なくとも１つのユニフォームリソースロケータ（ＵＲＬ）である
    ことを特徴とするコンピュータ可読記憶媒体。
21. 前記特定のタイプのサービスは、支払サービスであり、
    前記サービスプロバイダは、オペレータ及び支払プロバイダの内の１つであり、
    前記少なくとも１つのＵＲＬは、支払を受け入れるために前記オペレータと前記支払プロバイダの内の１つと対話することができる、少なくとも１つの課金ゲートウェイを指し示している
    ことを特徴とする請求項２０に記載のコンピュータ可読記憶媒体。
22. 前記支払サービスは、コンテンツ、サービス及び商品の少なくとも１つの配信に関連付けられている
    ことを特徴とする請求項２１に記載のコンピュータ可読記憶媒体。
23. 前記配信は、ストリーミングコンテンツ配信サービスであり、
    前記サービスプロバイダは、インターネットサービスプロバイダ（ＩＳＰ）であり、
    前記少なくとも１つのＵＲＬは、ストリーミングコンテンツ配信を提供するために、前記ＩＳＰと対話することができるキャッシングサーバを指し示している
    ことを特徴とする請求項２２に記載のコンピュータ可読記憶媒体。
24. 前記取得するステップは、
    前記特定のタイプのサービスをリクエストしているエンドユーザデバイスのＩＰアドレスを使用する、リバースＤＮＳルックアップ動作を実行するステップを更に備える
    ことを特徴とする請求項２０に記載のコンピュータ可読記憶媒体。
25. 前記取得される少なくとも１つのエントリに基づいて、前記オペレータによって提案される支払方法を識別するステップと、
    前記コンテンツプロバイダによって識別される支払方法から支払方法を選択するステップと、
    前記選択された支払方法をエンドユーザデバイスへ提示するステップと
    を更に備えることを特徴とする請求項２２に記載のコンピュータ可読記憶媒体。

Images