JP2009543517A - 課金証明書およびデータの無線配信 - Google Patents

Abstract

無線プロトコルを使用して課金証明書をモバイルデバイスに伝達する構成を通して、課金を可能にする。課金トリガは、課金データがモバイルデバイスによって通知される位置、および公開鍵／秘密鍵ペアのうちの公開鍵を含む課金証明書を提供し、代替的には、そのような課金証明書へのリンクを提供する。課金ヘルパは、課金証明書をモバイルデバイス上のＤＲＭシステムに渡し、ＤＲＭシステムは課金ＩＤと関連付けられた課金データを収集し、公開鍵を使用して課金データを暗号化して課金チャレンジにする。課金ヘルパは、その課金チャレンジを前記位置に通知する。課金サービスは、秘密鍵を使用して課金チャレンジから課金データを抽出し、課金レスポンスを生成する。課金レスポンスは、課金ヘルパによって受信され、課金データが格納されるデータストアの少なくとも一部分をリセットするようにＤＲＭシステムに指示する。

Description

本発明は、課金証明書およびデータの無線配信に関する。

課金（ｍｅｔｅｒｉｎｇ）は、デジタルメディアコンテンツプロバイダが保護されたメディアコンテンツの使用をトラッキングできるようにする技術である。課金は、一般的には、個人ユーザのリスニング習慣をトラッキングするのに使用されるのではなく、むしろ、メディアコンテンツアイテムの特定の部分が何回使用されたか（例えば、メディアコンテンツがどれだけの頻度で再生またはコピーされたか）を集計する手段である。したがって、課金は、使用料金モデルや、ユーザがオンラインカタログから選択したメディアコンテンツの限られた使用を楽しむために定期的な料金（例えば、毎月）を支払う加入モデルなどの、複数の可能なビジネスモデルに役立つ可能性がある。ユーザが加入を継続しないことを選択した場合、いずれかのコンテンツのライセンスが単に期限切れとなり、再生ができないこととなる。

メディアコンテンツプロバイダは、一般に、デジタル著作権管理（ＤＲＭ：ｄｉｇｉｔａｌ ｒｉｇｈｔｓ ｍａｎａｇｅｍｅｎｔ）技術のようなコピープロテクトで保護されたメディアコンテンツに関する課金データを収集して記録する機能を有するパーソナルコンピュータ（ＰＣ）またはモバイルデバイス上で稼動する、メディアプレイヤを使用可能にする。このような課金機能は、例えば、システム開発者からライセンス供与されるソフトウェア開発キット（ＳＤＫ：ｓｏｆｔｗａｒｅ ｄｅｖｅｌｏｐｍｅｎｔ ｋｉｔ）の使用を通して、そのようなプラットフォーム用に開発されることがある。課金はいくつかの利点を提供し、その１つは、コンテンツにライセンスを供与して該コンテンツを顧客に再販する、コンテンツプロバイダサービスに対するロイヤルティ料金を低減することである。ロイヤルティ料金は、販売が永久的な譲渡（ｐｅｒｍａｎｅｎｔ ｔｒａｎｓｆｅｒ）であるか、課金による一回だけの再生（ｍｅｔｅｒｅｄ ｓｉｎｇｌｅ ｐｌａｙ）であるか、などの販売のタイプに基づくものである。課金による一回だけの再生の費用は、永久的な譲渡の費用よりもはるかに安価であるので、課金制のコンテンツはしばしば、コンテンツプロバイダにとってはるかに経済的である。課金は、他にも利点も提供する。課金制のコンテンツによって、コンテンツプロバイダは、例えば、どのコンテンツがより人気があるかを判断し、再生されるコンテンツのアーティストを識別して料金を支払い、広告が見られる回数をトラッキングすることができる。

現在の課金の構成は、多くのアプリケーションで満足されているが、典型的には、例えばドッキングタイプの接続を使用して課金サービスとモバイルデバイスとの間の中継として機能する、ＰＣなどのプロキシデバイスに依存する。ＰＣは、課金証明書（ｍｅｔｅｒｉｎｇ ｃｅｒｔｉｆｉｃａｔｅ）（課金データが報告される位置（ｌｏｃａｔｉｏｎ）を識別する）をモバイルデバイスに配信すること、ならびに課金イベントをトリガすることに使用される。しかし、モバイルデバイスは、プロキシデバイスに結合されていないと、課金証明書を受信し、課金データを報告することができない。

課金は、課金証明書が無線（ｏｖｅｒ−ｔｈｅ−ａｉｒ）プロトコルを使用してモバイルデバイスに伝達される構成を通して使用可能になる。種々の具体的な例では、課金サービスは、課金証明書、代替的には課金証明書へのリンクを含む課金トリガ（ｍｅｔｅｒｉｎｇ ｔｒｉｇｇｅｒ）をモバイルデバイスに送信する。課金証明書は、課金データがモバイルデバイスによって通知される位置、課金ＩＤ、および公開鍵と秘密鍵のペアのうちの公開鍵を含む。

モバイルデバイスには、課金トリガを受信すると起動される課金ヘルパアプリケーション（ｍｅｔｅｒｉｎｇ ｈｅｌｐｅｒ ａｐｐｌｉｃａｔｉｏｎ）が準備されている。課金ヘルパアプリケーションは、課金証明書をモバイルデバイス上のＤＲＭシステムに渡す。ＤＲＭシステムは、課金ＩＤと関連付けられた課金データを収集し、公開鍵を使用して、収集された課金データを暗号化して課金チャレンジ（ｍｅｔｅｒｉｎｇ ｃｈａｌｌｅｎｇｅ）にする。ＤＲＭシステムは、該課金チャレンジを課金ヘルパアプリケーションに渡し、課金ヘルパアプリケーションは、該課金チャレンジを、課金証明書において識別された位置に通知する。課金サービスは、公開鍵／秘密鍵ペアのうちの秘密鍵を使用して、課金チャレンジから課金データを抽出する。課金サービスは、課金レスポンス（ｍｅｔｅｒｉｎｇ ｒｅｓｐｏｎｓｅ）を生成し、該課金レスポンスは、課金ヘルパアプリケーションによって受信され、該課金ヘルパアプリケーションは、ＤＲＭシステムに、課金データが格納されているデータストアの少なくとも一部をリセットするように指示（ｐｒｏｍｐｔ）する。

本構成は、有利には、課金証明書を受信するため、あるいは課金サービスへの課金データの報告を可能にするためにプロキシデバイスを必要とせずに、消費者が、好適なロケーションでモバイルデバイスを使用してメディアコンテンツにすぐにアクセスし、消費することを可能にする。

無線で課金証明書を配信して課金データを報告する例示的な構成のブロック図である。 システム開発者が課金証明書を課金サービスに提供し、課金サービスから公開鍵を受信し、ソフトウェア開発キットをライセンシに提供する例示的な構成を示すブロック図である。 ライセンシが課金ヘルパアプリケーションをモバイルデバイスに提供する例示的な構成を示すブロック図である。 例示的な課金証明書を示す図である。 無線で課金証明書を受信して課金データを報告するように構成された例示的なモバイルデバイスのコンポーネントを示す図である。 モバイルデバイスと課金サービスとの間の例示的なメッセージフローを示す図である。 特定のＡｐｐＩＤを含むＷＡＰプッシュを処理する例示的な構成を示す図である。 特定のＭＩＭＥタイプを含むメッセージパケットを処理する例示的な構成を示す図である。

図面を参照すると、図面において、同様の参照番号は同様のコンポーネントまたは要素を示す。図１は、無線で課金証明書を配信して課金データを報告するための例示的な構成１００のブロック図である。図１に示されるように、モバイルデバイス１０５は、課金サービス１２１との無線通信１１５を備えている。本明細書で使用される「無線（ｏｖｅｒ−ｔｈｅ−ａｉｒ）」とは、オープン空間をその伝送媒体として使用する任意のタイプのワイヤレス通信を、モバイルデバイス１０５と課金サービス１２１との間の通信に利用する構成を意味する。無線通信は、例えば、ＷＡＰ（Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を使用するＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｉｎｇ ｓｅｒｖｉｃｅ）を用いて、モバイルデバイス１０５と課金サービス１２１との間で使用可能にされることがある。例えば、以下で詳しく説明されるように、ダイレクトプッシュ（Ｄｉｒｅｃｔ Ｐｕｓｈ）（すなわち、ＩＰプッシュ）メッセージング構成も無線通信を採用することがあるが、課金サービスは、ＷＡＰプッシュＳＭＳ（ＷＡＰ Ｐｕｓｈ ＳＭＳ）メッセージをモバイルデバイス１０５に送信することがある。

モバイルデバイス１０５は、本実施例において、消費者によってミュージック、ビデオ、オーディオ、ニュース、着信音、ゲーム、データなどのメディアコンテンツを選択してアクセスして消費するのに一般に使用される、種々のモバイルデバイスのいずれか１つから選択される。したがって、モバイルデバイス１０５は、ポータブルメディアプレイヤ、パーソナルデジタルアシスタント、ポケットＰＣ、ミュージックプレイヤ、携帯電話、スマートフォン、ハンドヘルドゲームデバイスなどの１つから選択される。しかしながら、課金証明書および課金データの無線配信に関する利点および特徴を、本明細書に説明される特徴を実装するように配置されるとメディアコンテンツをレンダリングし、あるいは消費するように構成される、多数のタイプの電子デバイスによって実現することができるので、デバイスに関するこの列挙は単なる例示であることを強調する。

課金サービス１２１は、課金データを収集して処理するサービスを表す。課金サービス１２１は、例えば、メディアコンテンツプロバイダ１３０（例えば、メディアコンテンツのライセンサ、または加入サービスプロバイダ）により契約される課金集約サービス（ｍｅｔｅｒｉｎｇ ａｇｇｒｅｇａｔｉｏｎ ｓｅｒｖｉｃｅ）、またはメディアコンテンツ所有者によって、図１にライン１３２で示されるように提供されることがある。代替的に、課金サービス１２１は、メディアコンテンツプロバイダ１３０によって直接モバイルデバイス１０５に提供される（この代替構成は図１に示されていない）。課金サービス１２１は、この実施例において、モバイルデバイス１０５との間で通信を送受信することによりサーバ・クライアントタイプのアーキテクチャを実装するように構成される、アプリケーションまたはデータサーバを使用して実装されている。

メディアコンテンツプロバイダ１３０は、典型的に、ライン１３６で示されるように、メディアコンテンツをモバイルデバイス１０５に提供するように構成される。このようなメディアコンテンツは、物理的な媒体（すなわち、ＣＤ、ＤＶＤ、ＨＤ（ｈｉｇｈ−ｄｅｆｉｎｉｔｉｏｎ）ディスク、フラッシュメモリカードなど）をモバイルデバイス１０５に転送すること、またはメディアコンテンツプロバイダ１３０からダウンロードすることを含め、種々のメカニズムを使用して配信可能である。さらに、本構成では必須でないが、メディアコンテンツプロバイダ１３０は、一般に、ＤＲＭライセンスなどのライセンスを、ライセンスサーバまたは権利管理サーバ（図示せず）からモバイルデバイス１０５に提供する。このようなライセンスは、通常、メディアコンテンツプロバイダ１３０が配信されるメディアコンテンツの使用に対して課す、使用上のルール、権利または制約を提供する。このライセンスは、一般に、配信されるメディアコンテンツと関連する課金ＩＤも含み、その結果、その特定のメディアコンテンツに関する課金データを、別のメディアコンテンツプロバイダによって配信されるメディアコンテンツとは別に、トラッキングして報告することができる（例えば、消費者は、２つのミュージックサービスに加入し、課金制のメディアコンテンツを各々からダウンロードすることができる）。この実施例では、配信されるメディアコンテンツとライセンスは、無線で、あるいはＰＣなどのプロキシデバイスを使用して、配信可能である。

図２は、システム開発者２０６が課金証明書２２１を課金サービス１２１（図１）に提供し、課金サービス１２１から公開鍵２１３を受信する例示的な構成２００を示すブロック図である。公開鍵２１３は公開鍵／秘密鍵のペアの一部であり、公開鍵／秘密鍵のペアは典型的に、課金サービス１２１によって生成され、暗号化されていない文章で（ｉｎ ｔｈｅ ｃｌｅａｒ）パスワードまたは他の鍵を交換する必要のない公知の暗号化手法を用いる、サーバとクライアントとの間のセキュアなデータ通信を実装するのに使用される。課金サービス１２１は、認証のために公開鍵２１３をシステム開発者２０６に送信するが、一方、公開鍵２１３で暗号化された情報を復号するのに必要とされる公開鍵／秘密鍵ペアのうちの秘密鍵は残したままにする。システム開発者２０６は、図４に示し、以下で詳しく説明するように、組み込み公開鍵２１３を用いて課金証明書２２１を作成する。

図２に示されるように、システム開発者２０６は、ソフトウェア開発キット（ＳＤＫ）２５３もライセンシ２６０に提供する。課金証明書および課金データの無線配信の一部のアプリケーションにおいて、ライセンシ２６０は、メディアコンテンツプロバイダ１３０（図１）またはメディアコンテンツの所有者である。代替的には、ライセンシ２６０は、課金サービス１２１または別のエンティティである。本構成では、ライセンシ２６０は典型的にＳＤＫ２５３を利用して、モバイルデバイス１０５上で稼動するように構成されて課金証明書および課金データの無線配信を容易にする、課金ヘルパアプリケーションを作成する。課金ヘルパアプリケーションは、図５を参照して詳しく説明される。

図３に示されるように、ライセンシ２６０は、課金ヘルパアプリケーション３１４をモバイルデバイス１０５に提供する。課金ヘルパアプリケーション３１４は、課金証明書および課金データの無線配信の一部のセッティングにおいて、モバイルデバイス１０５に予め準備されている。他のセッティングにおいて、課金ヘルパアプリケーション３１４は、モバイルデバイス１０５（図１）によって、必要に応じてまたはオンデマンドで、アプリケーションとしてダウンロードされるか、あるいはプラグインされるように構成される。

図４は、図２に示される課金証明書２２１の例示的な構成を示す図である。図４に示されるように、課金証明書２２１は、課金ＩＤ４１０、ＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）４１５、および公開鍵２１３を含め、３つのコンポーネントを含む。課金ＩＤ４１０は、消費者が２つ以上のコンテンツプロバイダからのメディアコンテンツをモバイルデバイス１０５に格納しておくことが予想される場合において、課金データが収集されているコンテンツプロバイダを識別するのに使用される。

ＵＲＬ４１５は、モバイルデバイス１０５によって課金データが報告されるアドレスを提供する。この実施例では、課金データはＨＴＴＰ ＰＯＳＴコマンドを使用してＵＲＬ４１５に通知される。ＨＴＴＰ、すなわち、ハイパーテキスト転送プロトコル（ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）は、クライアントとサーバとの間の非同期通信を実現するのに使用されるオープンインターネットプロトコルである。典型的に、ＵＲＬ４１５は、図１を参照して上述したライセンスサーバや権利管理サーバなどのライセンスソースと共通ドメイン名を共有する。

図５は、モバイルデバイス１０５（図１）の例示的な構成を示す図である。モバイルデバイス１０５は、図５に示されるブラウザ５１１などのネットワーキング・インタフェースを含むように構成される。代替的に、ネットワーキング・インタフェースは、ＷＡＰ／ＨＴＴＰハンドラまたはダイレクトプッシュハンドラを備えてもよい。ネットワーキング・インタフェース（例えば、ブラウザ５１１）は、無線通信プロトコルを使用してメッセージおよび他のデータを送受信するように構成される。モバイルデバイス１０５は、さらに、１つまたは複数のヘルパアプリケーション５２４、ＤＲＭシステム５３１、およびメディアプレイヤ５６０を含むように構成される。

ヘルパアプリケーション５２４は、モバイルデバイス１０５の特定の構成に応じて様々なタスクを実行するように構成される、１つまたは複数のアプリケーションを含むことができる。ヘルパアプリケーション５２４は、大抵はモバイルデバイス上で動作するように構成されたブラウザの場合であるが、ブラウザがＤＲＭシステムと直接にやりとりする十分な機能を備えていないようなセッティングにおいて使用される。典型的には、ヘルパアプリケーション５１４は、モバイルデバイス１０５のネイティブレベル（ｎａｔｉｖｅ ｌｅｖｅｌ）に存在し、ブラウザ５１１とＤＲＭシステム５３１との間のプロキシの役割を果たす。したがって、ヘルパアプリケーション５２４は、ブラウザ５１１およびＤＲＭシステム５３１の両方に対するインタフェースを有し、それぞれに信頼性のあるエンティ（ｔｒｕｓｔｅｄ ｅｎｔｉｔｙ）として識別される。

この実施例において、ヘルパアプリケーション５２４は、示されるように課金ヘルパアプリケーション３１４を含む。課金ヘルパアプリケーション３１４は、モバイルデバイス１０５によって、図６に示され説明されるメッセージフローを実装するのに使用される。ヘルパアプリケーション５２４は、例えば、ライセンス取得ヘルパ（ｌｉｃｅｎｓｅ ａｃｑｕｉｓｉｔｉｏｎ ｈｅｌｐｅｒ）を含むこともある。

図５のＤＲＭシステム５３１は、メディアコンテンツプロバイダ１３０（図１）からのメディアコンテンツのセキュアな受信を実現するのに使用され、さらに、メディアコンテンツに関連するラインセンスによって課される使用上のルール、権利、または制約に従ってメディアコンテンツをメディアプレイヤで使用し、再生することを可能する。さらに、ＤＲＭシステム５３１は、課金されるメディアコンテンツの課金データ（これは、モバイルデバイス１０５に格納され、後にモバイルデバイス１０５によって報告される）を、典型的には課金ＩＤによって記録して、格納する。ＤＲＭシステム５３１は、ＤＲＭシステム５３１によって記録された課金データを格納するのに使用される課金データストア５３６を含む。

図６は、モバイルデバイス１０５と課金サービス１２１との間の例示的なメッセージフローを示す図であり、このメッセージフローは、７つのステップのシーケンスで構成される。課金サービス１２１は、最初に、課金トリガ６０１を生成し、モバイルデバイス１０５からの課金報告（ｍｅｔｅｒｉｎｇ ｒｅｐｏｒｔ）の要求を開始する。様々な代替的実施形態では、課金トリガ６０１は、モバイルデバイス１０５を使用する特定の消費者または加入者に向けて送られる、ＷＡＰプッシュＳＬ（サービスロード（ｓｅｒｖｉｃｅｌｏａｄ））ＳＭＳとして構成され、あるいはユーザがプロンプトを「受け付ける（ａｃｃｅｐｔ）」ことが望まれる場合は、ＷＡＰプッシュＳＩ（サービスインジケータ）ＳＭＳとして構成される。課金トリガ６０１（例えば、ＷＡＰプッシュ）は、課金証明書（図４）へのＵＲＬを含む。

図７に示されるように、ＷＡＰプッシュは、ブラウザ４１１による受信されると、モバイルデバイス１０５に配置されたヘルパアプリケーション４２４の中の特定のヘルパアプリケーションがトリガされるように構成される、特定のＷＡＰ ＡｐｐＩＤを含むことがある。図７に示される具体的な例では、ＷＡＰプッシュＳＭＳメッセージ７０７に含まれるＷＡＰ ＡｐｐＩＤは、それぞれ参照番号７１３、７１８および７２２で示されるヘルパアプリケーション１、２．．．Ｎの中の、課金ヘルパアプリケーション３１４をトリガするように設定される。

図６の課金トリガ６０１に戻ると、オプションとして、ダイレクトデータプッシュ（例えば、ＩＰプッシュ）がモバイルデバイス１０５で使用可能であれば、ＷＡＰプッシュは不要である。代わりに、課金サービス１２１が、（上述した課金証明書に対するＵＲＬではなく）課金証明書２２１自体がメッセージの本体に組み込まれているメッセージを、モバイルデバイス１０５に送信することがある。この場合、課金ヘルパアプリケーション３１４は、以下で説明されるように、メッセージのＭＩＭＥタイプ（Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎ）を通して起動されるが、課金ヘルパアプリケーション３１４は、ステップ４（課金データの収集）にスキップする。

参照番号６０２で示されるように、課金トリガ６０１（例えば、ＷＡＰプッシュＳＭＳメッセージ）を受信すると、モバイルデバイス１０５内の課金ヘルパアプリケーション３１４は、課金トリガ６０１に含まれるＵＲＬをたどり、典型的にＨＴＴＰを使用して、課金証明書２２１を取得する。課金サービス１２１は、参照番号６０３で示されるように課金証明書２２１をモバイルデバイスに返す。上述したように、ダイレクトプッシュメッセージが利用される場合、図６の破線の枠で示されるようにステップ３と４は必要ではない。

モバイルデバイス１０５は、課金トリガ６０１を受信するとすぐに、要求された課金データの収集を開始し、またはその課金レポートを送り返すことは要件とされないことにさらに留意されたい。課金証明書および課金データの無線配信の特定のアプリケーションの要求に応じて、モバイルデバイス１０５は、しばらくして収集と報告を実行するように構成される。

図８に示されるように、課金サービス１２１（図１）によってモバイルデバイス１０５に送信されるメッセージは、複数のＭＩＭＥタイプの設定された１つで構成可能である。ＭＩＭＥタイプは、ＨＴＴＰヘッダのコンテンツタイプのフィールドに含まれる。特定のＭＩＭＥタイプがブラウザ４１１によって受信されると、必要に応じて、適切なヘルパアプリケーションがトリガされ、処理のためにメッセージがヘルパアプリケーションに渡される。表１は、２つの例示的なＭＩＭＥタイプ名、および関連する説明を示しており、これらは入力メッセージ（ｉｎｃｏｍｉｎｇ ｍｅｓｓａｇｅ）を課金アプリケーションヘルパ３１４（図３）に送るように構成される。当然、他のヘルパアプリケーション５２４（図５）は、表１に列挙されるもの以外のＭＩＭＥタイプを使用するであろう。

図８に示される実施例では、入力メッセージパケット８０７のＭＩＭＥタイプは、それぞれ参照番号８１３、８１８、および８２２で示される残りのヘルパアプリケーション１、２．．．Ｎの中の、課金ヘルパアプリケーション３１４にメッセージパケットが配信されるようにセットされる。

再び図６に戻ると、例示的なメッセージフローは、参照番号６０４で示されるように、モバイルデバイス１０５での課金データの収集に進む。ここで、課金ヘルパアプリケーション３１４は、課金サービス１２１から受信した課金証明書２２１を、ＤＲＭシステム５３１（図５）に渡す。具体的には、課金ヘルパアプリケーション３１４は、ＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）を公開するＤＲＭシステム５３１に対するインタフェースを通して稼動し、それによって、要求された課金データにアクセスして、該課金データを収集する。消費者が２以上のコンテンツプロバイダから課金されるメディアコンテンツを格納しているほとんどのアプリケーションでは、ＤＲＭシステム５３１は、特定の課金ＩＤと関連付けられた課金データを収集する。

次に、ＤＲＭシステム５３１は、課金チャレンジメッセージ（ｍｅｔｅｒｉｎｇ ｃｈａｌｌｅｎｇｅ ｍｅｓｓａｇｅ）６０５を生成する。この課金チャレンジ６０５には、収集された課金データが組み込まれており、これは、課金ヘルパアプリケーション３１４から渡された課金証明書２２１に含まれる公開鍵２１３（図２）を使用してＤＲＭシステム５３１によって暗号化される。課金データストア５３６に含まれる課金データの量、および利用されるバッファのサイズに応じて、２つ以上の課金チャレンジ６０５を利用して適切な課金データの全てを課金サービス１２１に報告することがある。ＤＲＭシステム５３１は、課金チャレンジ６０５を課金ヘルパアプリケーション３１４に渡す。課金ヘルパアプリケーション３１４は、上述されるように典型的にはＨＴＴＰ ＰＯＳＴを使用して課金チャレンジ６０５をＵＲＬ４１５（図４）に順に通知する。

２以上のメディアコンテンツプロバイダによって提供され課金されるコンテンツを、モバイルデバイス１０５が格納する場合（その結果、課金データは２以上の課金ＩＤを使用して課金データストア５３１に格納される場合）、オプションの構成が利用されることがある。このような場合、課金ヘルパアプリケーション３１４は、「全ての課金データを報告する」トリガを受信するとＤＲＭシステム５３１からの複数の課金ＩＤの各々について課金データを報告するように構成されている。この場合、モバイルデバイス１０５は複数の課金証明書を取得し、それによって、適切な課金データを収集し、報告する。課金アプリケーションヘルパ３１４は、次いで、ＤＲＭシステム５３１が課金証明書を使用して、課金チャレンジの各々が特定の課金ＩＤと関連する課金データを含む、複数の課金チャレンジを準備することを要求する。ＤＲＭシステム５３１は、それぞれの課金チャレンジの各々を課金ヘルパアプリケーション３１４に渡し、該課金ヘルパアプリケーション３１４は、課金ＩＤと関連付けられたそれぞれの課金サービスにそれを通知する。このような収集と報告を繰り返し方式で実行すると、複数の課金サービスにバッチタイプの構成で課金を報告することが実現される。

課金チャレンジ６０５を受信すると、課金サービス１２１は、その中に含まれる暗号化された課金データを、図２に示し上述した公開鍵／秘密鍵のペアのうちの秘密鍵を使用して抽出する。課金サービス１２１は、例えばコンテンツがプレイされているアーティストを特定して料金を支払うために、必要に応じて、抽出された課金データを使用し、または格納する。

課金データが受信され、抽出されると、課金サービス１２１は、モバイルデバイス１０５に送信される課金レスポンスメッセージ（ｍｅｔｅｒｉｎｇ ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ）６０６を生成する。この課金レスポンス６０６は、クライアントによって利用され、課金チャレンジに含まれる課金データを格納するのに使用される課金データストア５３６の一部分をリセットする。課金ヘルパアプリケーション３１４は、受信される課金レスポンス６０６をＤＲＭシステム５３１に渡すことにより、図６の参照番号６０７で示されるように、課金データストア５３６の適切な部分をリセットするようにＤＲＭシステム５３１に指示する。

課金証明書と課金データの無線配信に関する様々な例示的な構成および方法を示し、説明してきたが、添付の特許請求の範囲は、上述した特定の特徴、構成または方法に必ずしも限定されるものではないことを、理解されたい。むしろ、特定の特徴、構成または方法は、より具体的に請求項に記載される課金証明書と課金データの無線配信の例示的な形態として開示されたものである。

Claims (20)

1. 無線プロトコル（１１５）を使用して課金データをクライアント（１０５）から課金サービスサーバ（１２１）に提供する方法であって、
   前記課金サービス（１２１）からの課金トリガ（６０１）をネットワーキング・インタフェース（５１１）で受信するステップと、
   クライアント（１０５）上で稼動する課金ヘルパ（３１４）を前記課金トリガ（６０１）に応答して起動するステップであって、前記課金ヘルパ（３１４）は、前記課金データを収集するのに使用される課金サービス（１２１）によって提供される課金証明書を取得するステップと、
   前記課金データを含む課金チャレンジ（６０５）を、前記課金証明書（２２１）において特定される位置に送信するステップと
   を含むことを特徴とする方法。
2. 前記ネットワーキング・インタフェース（５１１）は、ブラウザ、ＷＡＰプッシュハンドラ、またはダイレクトプッシュハンドラの１つから選択されることを特徴とする請求項１に記載の方法。
3. 前記課金トリガ（６０１）は、該課金トリガ内に具現化される課金証明書（２２１）を含むことを特徴とする請求項１に記載の方法。
4. 前記課金トリガ（６０１）に組み込まれたＵＲＬをたどることによって課金証明書（２２１）を要求するステップ（６０２）をさらに含むことを特徴とする請求項１に記載の方法。
5. 前記クライアント（１０５）は、ポータブルメディアプレイヤ、パーソナルデジタルアシスタント、ポケットＰＣ、ミュージックプレイヤ、携帯電話、スマートフォン、またはハンドヘルドゲームデバイスの１つから選択された電子デバイスにおいて動作することを特徴とする請求項１に記載の方法。
6. 前記課金データは、前記クライアント（１０５）上のＤＲＭシステム（５３１）によって記録され、格納されることを特徴とする請求項１に記載の方法。
7. 前記ＤＲＭシステム（５３１）は、前記課金証明書（２２１）の課金ＩＤ（４１０）を使用して、前記課金ＩＤ（４１０）と関連付けられた課金データを収集することを特徴とする請求項６に記載の方法。
8. 課金データの収集および送信は、バッチタイプのプロセスで複数の課金サービスに課金データを報告するために複数の課金ＩＤの各々について繰り返されることを特徴とする請求項７に記載の方法。
9. 前記ＤＲＭシステム（５３１）は、単一の課金チャレンジが課金データストア内の累積課金データのすべては含むことができない場合、１つまたは複数の追加の課金チャレンジを生成することを特徴とする請求項１に記載の方法。
10. 課金サービス（１２１）によってクライアント（１０５）から課金データを収集する方法であって、
    公開鍵／秘密鍵ペアのうちの公開鍵（２１３）を含み課金トリガに組み込まれる課金証明書（２２１）または前記課金証明書（２２１）へのリンクを含む課金トリガ（６０１）をクライアント（１０５）に送信するステップと、
    前記公開鍵／秘密鍵ペアのうちの秘密鍵を使用して、前記クライアント（１０５）から受信した課金チャレンジに含まれる課金データであって前記公開鍵（２１３）を使用してクライアントによって暗号化された課金データを復号するステップと、
    前記課金チャレンジ（６０５）に含まれる前記課金データのデータストア（５３６）の少なくとも一部をリセットするように前記クライアント（１０５）に指示する課金レスポンス（６０６）を生成するステップと
    を含むことを特徴とする方法。
11. 前記課金トリガ（６０１）は、ＷＡＰプッシュまたはダイレクトプッシュの１つから選択された無線プロトコルを使用するメッセージに含まれることを特徴とする請求項１０に記載の方法。
12. 前記ＷＡＰプッシュは、ＷＡＰプッシュＳＬ ＳＭＳ、またはＷＡＰプッシュＳＩ ＳＭＳを含むことを特徴とする請求項１１に記載の方法。
13. 前記ＷＡＰプッシュは、一意の値を有するＡｐｐＩＤを含み、それによりクライアント側に存在する課金ヘルパアプリケーションを始動することを特徴とする請求項１１に記載の方法。
14. 設定されたＭＩＭＥタイプを有するパッケージで前記課金証明書（２１１）を前記クライアント（１０５）に提供し、これによって前記課金証明書（２１１）を前記クライアント（１０５）上で稼動している課金ヘルパアプリケーション（３１４）に渡すように、前記クライアント（１０５）内のネットワーキング・インタフェース（５１１）に指示するステップをさらに含むことを特徴とする請求項１０に記載の方法。
15. 設定されたＭＩＭＥタイプを有するパッケージで前記課金レスポンス（６０６）をクライアント（１０５）に提供し、これによって前記課金レスポンス（６０６）を前記クライアント（１０５）上で稼動している課金ヘルパアプリケーション（３１４）に渡すように、前記クライアント（１０５）内のネットワーキング・インタフェース（５１１）に指示するステップをさらに含むことを特徴とする請求項１０に記載の方法。
16. 前記課金証明書（２２１）は、課金ＩＤ（４１０）、または前記課金データが報告されるＵＲＬ（４１５）をさらに含むことを特徴とする請求項１０に記載の方法。
17. モバイルデバイス（１０５）におけるメディアコンテンツの使用量を課金する方法であって、
    ＰＣなどのプロキシデバイスを使用しないように前記モバイルデバイス（１０５）上にインストール可能な課金ヘルパアプリケーション（３１４）を実装し、これによって前記モバイルデバイス（１０５）から課金サービス（１２１）に直接に課金を報告することを可能にするＳＤＫ（２５３）を提供するステップと、
    公開鍵／秘密鍵ペアのうちの公開鍵（２１３）、課金データが通知されるＵＲＬ（４１５）、および課金サービスと関連付けられた課金ＩＤ（４１０）を含む課金証明書（２２１）を作成するステップと、
    前記課金証明書（２２１）を前記課金サービス（１２１）に提供するステップと
    を含むことを特徴とする方法。
18. 前記課金ヘルパアプリケーション（３１４）は、前記課金サービス（１２１）から受信した前記課金証明書（２２１）をＤＲＭシステム（５３１）に渡すように構成され、前記ＤＲＭシステム（５３１）は、前記課金証明書（２２１）からの前記公開鍵（２１３）を使用して、前記課金ＩＤに関する課金データを含む課金チャレンジ（６０５）を生成することを特徴とする請求項１７に記載の方法。
19. 前記課金チャレンジ（６０５）は、前記課金ヘルパアプリケーション（３１４）によって前記ＵＲＬ（４１５）に通知されることを特徴とする請求項１８に記載の方法。
20. 前記課金サービス（１２１）は、公開鍵／秘密鍵ペアのうちの秘密鍵を使用して前記課金チャレンジ（６０５）から前記課金データを抽出することを特徴とする請求項１７に記載の方法。

Images