JP6790169B2 - 繰り返されるライセンス更新によるメディアセッション同時性管理のためのシステム、方法およびコンピュータプログラム - Google Patents

Description

関連出願への相互参照
この出願は、２０１６年７月１９日に出願された米国特許出願番号第１５／２１３，６２４号と、２０１５年７月３０日に出願された米国仮特許出願番号第６２／１９９，２１１号と、２０１５年７月２０日に出願された米国仮特許出願番号第６２／１９４，８０４号との利益を請求しており、その各々が本願明細書においてその全文が参照により援用される。

技術分野
開示される主題は、繰り返されるライセンス更新によるメディアセッション同時性管理のためのシステム、方法および媒体に関する。より特定的には、開示される主題は、同時再生検出のための繰り返されるライセンス更新、および、ビデオ送達サービスについての同時性制限実施を使用することと、そのような繰り返されるライセンス更新を処理するためのサーバリソースを管理することとに関する。

背景
映画、音楽、およびメディアコンテンツの他の形態が、さまざまなコンテンツプロバイダからインターネットを介してコンピューティングデバイスに提供される。多くの理由により、このコンテンツのうちのいくつかは保護されており、当該コンテンツにおいて、関連付けられるメディアコンテンツを使用、再生、コピー、および／または、配布するさまざまな権利を少なくとも識別するライセンスが必要とされる。他の保護は、メディアコンテンツを復号するためにキーを必要とし得るさまざまなレベルまたはタイプの暗号化保護を含み得る。

さらに、特定のユーザが確立することが許可されている同時ストリーミング接続の数に制限が課され得る。すなわち、各々が同じユーザアカウントで認証されるとともに同時にメディアコンテンツがストリーミングおよび鑑賞され得るデバイスの数が制限され得る（たとえば１つのユーザアカウント当たり合計２つの接続、４つのデバイスについて１つのユーザアカウント当たり３つの接続など）。そのような制限を実施するために、ユーザが新しいストリーミング接続を要求すると、そのユーザに関連付けられる現在確立しているストリーミング接続の数が検出され、その数が許可された同時ストリーミング接続の最大数を上回っていれば、新しいストリーミング接続についての要求が拒否され得る。この制限を含むポリシーの実施を管理することは、困難なタスクである。

特定のユーザが１つのメディアコンテンツを視聴することをやめた場合に、当該特定のユーザに関連付けられるクライアントデバイスがサーバにメッセージを送信することを要求することにより同時性制限実施の問題に対応するようにさまざまなアプローチが試みられている。しかしながら、そのようなアプローチは、クライアントインプリメンテーションおよびデバイスアーキテクチャを抑制し得、クライアントデバイス上において永続ストレージを必要とし得る。すなわち、これらのアプローチにおいて、同時制限実施は、各それぞれのクライアントデバイスに依存することになる。さらに、これらのアプローチは一般に信頼性がないと考えられる。クライアントデバイスは、デバイスの障害（クラッシュ）、停電、ネットワーク障害などにより、「無秩序な」態様で再生を停止し得るからである。

したがって、繰り返されるライセンス更新によるメディアセッション同時性管理のための新しいシステム、方法および媒体を提供することが望ましい。

概要
開示される主題のいくつかの実現例に従うと、繰り返されるライセンス更新によるメディアセッション同時性管理のためのメカニズムが提供される。

いくつかの実現例に従うと、同時性検出および実施のためのシステムが提供され、当該システムは、少なくとも１つのサーバを含む。当該少なくとも１つのサーバは、メディア再生デバイス上で提示されるべきメディアコンテンツアイテムに関係するメディアコンテンツライセンスについての要求を受信することを行うように構成されており、メディアコンテンツライセンスについての要求はユーザアカウントに関連付けられており、少なくとも１つのサーバは、メディアコンテンツライセンスについての要求に応答して、メディアコンテンツアイテムに関連付けられる１つ以上のキーと、制限されたライセンス期間および更新要求間隔を含むポリシーを含むライセンスとをメディア再生デバイスに送信することと、メディア再生デバイス上で提示されるメディアコンテンツアイテムに関係するライセンス更新についての要求を、更新要求間隔内のある時間において、受信することと、ユーザアカウントに関連付けられる複数のメディア再生デバイスにわたるメディアセッション同時性に基づき、メディアコンテンツアイテムについてライセンス更新を発行するべきかどうか決定することとを行うように構成されており、決定は、ユーザアカウントについて所与の期間に発行されるライセンス更新のレコードについてクエリ送信することを含んでおり、少なくとも１つのサーバはさらに、ユーザアカウントに関連付けられるライセンス更新のレコードに基づいて、メディア再生デバイスにライセンス更新を送信することを行うように構成される。

いくつかの実現例において、少なくとも１つのサーバはさらに、制限されたライセンス期間および更新要求間隔のうちの少なくとも１つを修正するように構成される。いくつかの実現例において、修正は、ユーザアカウントについて所与の期間に発行されるライセンス更新のレコードを検討することと、ライセンス更新のレコードが、ユーザアカウントに関連付けられる複数のメディア再生デバイスによるライセンス更新要求の抑制を示すと決定することとに応答して、行なわれる。いくつかの実現例において、修正は、サーバ停止を検出することに応答して実行される。

いくつかの実現例において、ライセンスにおける１つ以上のキーが無効化されるべきであると決定することに応答して、ライセンス更新に関連付けられる制限されたライセンス期間は０の期間を有するか、または、メディア権の非継続を実施する他の何らかの手段を有する。

いくつかの実現例において、少なくとも１つのサーバはさらに、非継続のために、レコード内で以前に発行されたライセンスを同時に示しながら、メディアコンテンツアイテムについての制限されたライセンス期間のライセンスをメディア再生デバイスに自動的に送信するように構成される。

いくつかの実現例において、少なくとも１つのサーバはさらに、ユーザアカウントについて所与の期間に発行されるライセンス更新のレコードを検討することと、複数の実施モードからユーザアカウントに適用するべき実施モードを決定することと、ライセンス更新を発行する際に、決定された実施モードを適用することとを行うように構成され、制限されたライセンス期間および更新要求間隔のうちの少なくとも１つが調節される。

いくつかの実現例において、少なくとも１つのサーバはさらに、ライセンス更新についての要求を処理するための複数のライセンスサーバのリストを、メディア再生デバイス上で実行されるメディア再生アプリケーションに送信するように構成され、メディア再生アプリケーションは、複数のライセンスサーバのうちの第１のライセンスサーバにライセンス更新についての要求を送信し、かつ、第１のライセンスサーバが利用不可能であることを検出する際およびライセンスの終了に先立って、メディアコンテンツライセンスについてのライセンス更新が受信されるまで、複数のライセンスサーバのうちの第２のライセンスサーバに要求を送信する。

いくつかの実現例において、少なくとも１つのサーバは、所与の期間内に、ユーザアカウントに関連付けられるライセンス更新の数を数えることにより、ライセンス更新を発行するべきかどうか決定することと、カウントに基づいてメディア再生デバイスにライセンス更新を送信することとを行うようにさらに構成される。

いくつかの実現例において、少なくとも１つのサーバはさらに、ライセンス更新のレコードにアクセスすることができないことに応答して、自動的にライセンス更新を発行する緊急更新モードに入るべきかどうか決定するように構成される。いくつかの実現例において、緊急更新モードには、初期のライセンス要求または更新要求に対応する１つ以上のサーバに関連付けられるリソース情報に基づいて入る。いくつかの実現例において、ライセンス更新は、第１のライセンス期間より大きい第２のライセンス期間を含む。いくつかの実現例において、サーバと通信することの失敗の数がしきい値より大きいことに応答して緊急更新モードに入り、ハードウェアプロセッサはさらに、初期のライセンス要求または更新要求に対応する代替的なサーバにライセンス更新を送信するように構成される。いくつかの実現例において、システムは、初期のライセンス要求に対応するように構成されるサーバが利用不可能であると検出することに応答して、ライセンス更新を発行する更新のみモードに入るべきかどうか決定することをさらに含む。

いくつかの実現例に従うと、同時性検出および実施のためのシステムが提供され、当該システムは、ハードウェアプロセッサを含む少なくとも１つのサーバを含む。当該ハードウェアプロセッサは、メディアコンテンツアイテムに対応する初期のライセンスについてのユーザアカウントに関連付けられるメディア再生デバイスから要求を受信することと、初期のライセンスについて初期ライセンス期間および初期ライセンス更新間隔をセットする検出モードをユーザアカウントに課すことと、メディア再生デバイスに初期ライセンスを送信することとを行うように構成されており、初期ライセンスは初期ライセンス期間および初期ライセンス更新間隔を有しており、ハードウェアプロセッサはさらに、ユーザアカウントが、更新要求抑制を示す疑わしい挙動に関連付けられるかどうかを決定することと、初期のライセンス期間未満である更新ライセンス期間または初期のライセンス更新間隔未満であるライセンス更新間隔をセットするより厳しい実施モードをユーザアカウントに課すことと、メディア再生デバイスにライセンス更新を送信することとを行うように構成されており、ライセンス更新は更新ライセンス期間およびライセンス更新間隔のうちの少なくとも１つを有する。

いくつかの実現例において、初期のライセンス期間は、メディアコンテンツアイテムのコンテンツ期間より大きい。いくつかの実現例において、初期のライセンス期間および更新ライセンス期間のうちの少なくとも１つは、メディアコンテンツアイテムのコンテンツ期間未満である。いくつかの実現例において、更新ライセンス期間は、メディアコンテンツアイテムのコンテンツ期間の半分未満である所定期間である。いくつかの実現例において、ライセンス更新間隔は初期の更新間隔未満である。

いくつかの実現例では、ユーザアカウントが疑わしい挙動に関連付けられるかどうか決定することは、ユーザアカウントが、ユーザアカウントに関連付けられる複数のメディア再生デバイスにわたって複数のライセンス要求を生成していることを検出することをさらに含む。

いくつかの実現例において、ユーザアカウントが疑わしい挙動に関連付けられるかどうか決定することは、ユーザアカウントが特定の時間期間内にライセンス更新要求を生成していないことを検出することをさらに含む。

いくつかの実現例において、ユーザアカウントが疑わしい挙動に関連付けられるかどうか決定することは、ユーザアカウントが、同じメディア再生デバイス上で同じメディアコンテンツアイテムについて複数のライセンス要求を生成していることを検出することをさらに含む。

いくつかの実現例において、ユーザアカウントが疑わしい挙動に関連付けられるかどうかを決定することは、疑わしい更新要求を検出することをさらに含み、疑わしい更新要求に関連付けられる時間は、初期の更新間隔よりも初期のライセンス期間に近い。

いくつかの実現例において、システムは、特定の時間期間が経過したことに応答して、より厳しい実施モードほど制限的でない実施モードをユーザアカウントに課すことをさらに含む。

開示される主題のさまざまな目的、特徴および利点は、添付の図面に関連して考慮されると、開示される主題の以下の詳細な説明を参照してより完全に認識され得る。当該図面において、同様の参照番号は同様の要素を識別している。

開示される主題のいくつかの実現例に従った、メディア再生デバイスと１つ以上のライセンスサーバとの間での要求および応答を含むデータの流れの例示的な例を示す図である。 開示される主題のいくつかの実現例に従った、繰り返されるライセンス更新によるメディアセッション同時性管理のプロセスための例示的な例を示す図である。 開示される主題のいくつかの実現例に従った、ユーザアカウント挙動情報に基づいて、複数の実施モードのうちの１つをユーザアカウントに適用するためのプロセスの例示的な例を示す図である。 本願明細書に記載されるような繰り返されるライセンス更新によるメディアセッション同時性管理のためのメカニズムがいくつかの実現例に従って実現され得るシステムの一般化された概略図の例を示す図である。 開示される主題のいくつかの実現例に従った、図４に示される１つ以上のコンピューティングデバイスおよびサーバを実現するために使用され得るハードウェアの例を示す図である。

詳細な説明
さまざまな実現例に従うと、繰り返されるライセンス更新によるメディアセッション同時性管理のための（システム、方法および媒体を含む）メカニズムが提供される。

概して言えば、コンテンツ配布システムは、コンテンツサーバと、コンピューティングデバイス上で実行されるメディア再生アプリケーションと、コンピューティングデバイス上で実行されるメディア再生アプリケーションにコンテンツサーバを接続する通信ネット
ワークとを含み得る。コンテンツサーバは、コンピューティングデバイス上で実行されるメディア再生アプリケーションにコンテンツサーバからダウンロードされ得るメディアコンテンツアイテムを格納するように構成され得る。たとえば、タイトルまたはメディアコンテンツアイテムを識別する任意の他の好適な情報を選択するユーザ要求を受信することに応答して、コンピューティングデバイス上で実行されるメディア再生アプリケーションは、メディアコンテンツアイテムに対応するメディアファイルをダウンロードおよび再生するように構成され得る。当該メディアファイルは、連続するコンテンツデータ、オーディオデータ、ビデオデータなどを含み得る。そのような再生は、オーディオデータおよびビデオデータをオーディオ信号およびビデオ信号へデコードおよびレンダリングすることを含み得る。いくつかの実現例では、コンテンツサーバは、メディア再生アプリケーションに連続してメディアファイルを送信またはストリーミングする。したがって、コンピューティングデバイス上で実行されるメディア再生アプリケーションは、メディアコンテンツアイテムの１つ以上の付加的なメディアファイルが取得されている間、上記メディアファイルを使用してメディアコンテンツアイテムの一部を提示し得る。

いくつかの状況において、特定のユーザアカウントが確立することを許可される同時ストリーミング接続の数に制限が課され得る。たとえば、特定のアカウントおよび／または特定タイプのデバイスに基づいて、コンテンツプロバイダは、そのアカウントまたはそのデバイスについて確立され得る同時ストリーミング接続の最大数に対して制限を課し得る。本願明細書において、同時ストリーミング接続の数に対する制限の実施は、デジタル権利管理（ＤＲＭ： digital rights management）サーバのような任意の好適なサーバによって実行され得る。特定のユーザアカウントのユーザが新しいストリーミング接続を要求する場合、メディアコンテンツに加えて、メディアライセンスが必要になり得る。ＤＲＭサーバは、そのユーザアカウントに関連付けられる現在アクティブであるストリーミング接続または確立されているストリーミング接続の数を検出し、その数が許可された同時ストリーミング接続の最大数を上回っていれば、新しいストリーミング接続についての要求を拒否することに少なくとも部分的によって、新しいストリーミング接続を要求するデバイスにメディアライセンスを発行するべきかどうか決定し得る。なお、そのようなライセンスを拒否することによって、メディアコンテンツは再生不可能となるか、または、そうでなければメディアコンテンツが再生されることが抑制される。

また、いくつかの状況において、あるユーザアカウントのユーザによって確立された以前のストリーミング接続がメディア再生アプリケーションによって終了されるが、当該終了イベントの通知は、ライセンスサーバによって受信されない。これにより、ユーザアカウントに関係する不正確または古い状態情報がＤＲＭサーバ上に格納されることになり得、当該ユーザアカウントに関連付けられるユーザの閲覧体験に影響を与え得る。たとえば、正当に特定のストリーミング接続を終了したあるユーザアカウントのユーザは、特定のストリーミング接続が終了したことをＤＲＭサーバが知らない場合、任意の新しいストリーミング接続を確立することが許可され得ない。ユーザが同時ストリーミング接続に課される制限に従っている場合に当該ユーザが新しいストリーミング接続を確立することを許可しなければ、ユーザ体験が損なわれ得るので、そのようなコンテンツ配布システムにおいて望ましくない。

ＤＲＭサーバは、新しいライセンスについてＤＲＭクライアントデバイスからメディアライセンス要求を受信することに応答して、制限された期間のライセンスで応答し得る。たとえば、ライセンスは、約数分（たとえば５分）の制限された期間を有し得、ライセンス更新を可能にするポリシーに関連付けられ得る。なお、ライセンスは、各々がキー識別子に関連付けられ得る１つ以上のキーと、キーの使用に関する任意の他の好適な情報とを含む、キーシステムに特有の状態情報であり得る。また、ライセンスに含まれる１つ以上のキーは、ライセンスが終了している場合、メディアコンテンツ（たとえばメディアデー
タの１つ以上のブロック）の復号には使用可能ではあり得ない。

ＤＲＭクライアントデバイス上のライセンスの終了に先立って、ＤＲＭクライアントデバイスは、ライセンス更新ポリシーに従ってライセンス更新要求を発行し得る。たとえば、ライセンス更新ポリシーは、更新要求間隔（すなわちライセンス更新要求同士の間の時間）と、ライセンス期間とを示し得る。なお、ライセンス更新ポリシーは、任意の好適なパラメータ（たとえばアカウントごと、デバイスごと、メディアコンテンツタイトルごとなど）に基づいて動的に調節され得る。当該調節は、サーバオーバーロードの時間の間またはデータセンタの停止の間におけるライセンス期間を増加することと、特定タイプの挙動を示すと考えられるユーザアカウントについてライセンス期間を増加することと、特定タイプの挙動を示すと考えられるユーザアカウントについてより頻繁な更新要求間隔とすることとなどを含み得る。また、ライセンス更新は、特定のタイムアウト期間の後にライセンス更新要求が受信されない場合、繰り返され得る。

ＤＲＭクライアントデバイスからライセンス更新要求を受信することに応答して、ＤＲＭサーバは、別のライセンス更新期間について当該ライセンスを延長するか、または、キー使用権を非継続にするかどうかを決定し得る。たとえば、ライセンス更新は一般に、（たとえばライセンスが１つ以上のメディアキーを含み得る一方）メディアキーの使用を延長または無効にすることを示すポリシーデータを含むので、初期のライセンスより軽くなり得る。なお、メディアキーの使用の非継続または無効化は、たとえばメディア権利の非継続を実施するよう、０の期間のライセンス更新または他の何らかの手段を送信することにより行われ得る。

したがって、ＤＲＭクライアントデバイスは、ライセンス更新を受信することに応答して、ライセンス更新において規定される量だけライセンスを延長するか、または、メディアキーへのアクセスを無効にすることによりメディアコンテンツアイテムの再生を終了するように構成され得る。

同時ストリーミング接続を検出することに関して、ＤＲＭサーバは、あるユーザアカウントおよび／またはメディアコンテンツアイテムについて前回の更新期間に受信されたライセンス更新要求の数を数えることによって、どれだけ多くのＤＲＭクライアントデバイスが特定のメディアコンテンツアイテム（または一般にメディアサービス）にアクセスしているか決定し得る。なお、ＤＲＭサーバが前回の更新期間内にＤＲＭクライアントインスタンスから要求を受信していない場合、ＤＲＭサーバは、ＤＲＭクライアントデバイスがもはやメディアコンテンツアイテムを再生していないと仮定し得る。たとえば、ＤＲＭクライアントデバイスのユーザがメディアコンテンツアイテムの再生を非継続にしたかもしれない。別の例では、キー使用権がライセンス終了により無効化または非継続にされたかもしれない。

いくつかの実現例では、ライセンス更新要求に対応するＤＲＭサーバまたは任意の他の好適なサーバは、ライセンス更新要求のキューを維持し得、ライセンス期間と同等の時間の後に当該キューにおける古いエントリが終了し得る。ＤＲＭサーバは、新しい初期のライセンス要求に応答して、同時進行中の再生セッションを決定するようキュー（たとえばライセンス更新サーバキュー）をチェックすることにより、初期のライセンスを発行するべきかどうか決定し得る。代替的には、ＤＲＭサーバは、最も古いセッションについてライセンス更新要求が次に受信される時に、ＤＲＭサーバまたは任意の他の好適な更新サーバに当該最も古いセッションについてライセンス権利を非継続にしつつ、常に新しい要求に対応するように構成され得る。これはたとえば、他の再生セッションが進行中であると考えられるので、新しい要求を拒否するのではなく、最も最近のユーザ要求を常に許可するという利点を有する。

いくつかの実現例において、付加的または代替的には、ＤＲＭサーバは、検出のみ実施モードを実現するように構成され得る。当該検出のみ実施モードにおいて、初期のライセンス要求を処理するライセンスサーバと、ライセンス更新要求を処理するライセンス更新サーバとは、受信された要求に対応するとともにレコードにログを記録し得る。

本願明細書において記載されるこれらのメカニズムはさまざまな用途において使用され得る。たとえば、これらのメカニズムは、疑わしい挙動を示すユーザを、そのような疑わしい挙動を示さないユーザへのメディア送達サービスに影響を与えることなく、検出および抑え込むために使用され得る。別の例において、これらのメカニズムは、クライアントアーキテクチャから独立しているので、異なるタイプおよび異なる数のクライアントにわたってスケールされ得、クライアントデバイスにおいてストレージ（たとえばＪａｖａＳｃｒｉｐｔ（登録商標）ストレージ）を必要とせず、プライベートブラウジングモードで動作するように実現され得る。より特定的な例において、これらのメカニズムは、クライアントデバイスインプリメンテーションまたはクライアントデバイスアーキテクチャを抑制し得ない。ライセンスを要求し処理し得るクライアントデバイスは、繰り返されるライセンス更新の使用をサポートし得る。さらに別の例において、これらのメカニズムは、脅威が拡大または縮小するに従って、柔軟性を提供し得る。さらに別の例において、これらのメカニズムは、不正行為を検出するとともに同時性制限を実施する単一の実現例を提供するために使用され得る。

より特定的な例において、ライセンスの終了の前に受信されるライセンス更新要求が存在しないことは、メディアコンテンツがもはや再生されていないという指示として使用され得る。このため、そのような指示は、デバイスクラッシュ、ラップトップコンピューティングデバイスでの蓋を閉じることなどによって失われ得ない。

繰り返されるライセンス更新によるメディアセッション同時性管理のこれらの特徴および他の特徴を図１〜図５に関連してさらに説明する。

図１を参照して、開示される主題のいくつかの実現例に従って、メディア再生デバイスと１つ以上のＤＲＭまたはライセンスサーバとの間で繰り返されるライセンス更新を実現するためのフロー図１００の例示的な例が示される。たとえば、メディア再生デバイスは、ＤＲＭサーバにライセンスおよびライセンス更新についての要求を送信し得、ＤＲＭサーバは、ライセンスとライセンス更新とを発行するべきかどうかの決定を処理する。なお、図１は１つのＤＲＭライセンスサーバを示しているが、任意の好適な数のＤＲＭライセンスサーバが使用され得る。たとえば、メディア再生デバイスは、ライセンスサーバにライセンスについての要求を送信し得るとともに、ライセンス更新についての要求を１つ以上のライセンス更新サーバに送信し得る。別の例において、ウェブサーバのようなサーバが、ライセンスまたはライセンス更新についての要求を処理し得るとともに、どのライセンスサーバがライセンス要求を処理するべきであるかと、どのライセンス更新サーバがライセンス更新要求を処理するべきであるかとを決定し得る。さらに別の例において、ＤＲＭクライアントは、特定の期間内においてライセンス要求またはライセンス更新要求に対する応答をＤＲＭクライアントが受信していないこと（たとえば所定のタイムアウト）に応答して、別のＤＲＭライセンスサーバに別のライセンス要求またはライセンス更新要求を送信するように構成され得る。

なお、以下に記載されるように、各ライセンス更新は、特定のメディアコンテンツアイテムをストリーミングするための接続がアクティブなままであることを示すために使用され得る。たとえば、これは、アクティブなストリーミング接続の数を決定し、別のライセンスまたはライセンス更新を発行するべきかどうか決定する際に、同時性制限を有するア
クティブなストリーミング接続の決定された数を比較するために使用され得る。

いくつかの実現例では、プロセス１００は、メディア再生デバイス上での提示のためのメディアコンテンツアイテムに関するメディアコンテンツライセンスについての要求を受信することにより、１１０において開始し得る。たとえば、（たとえばメディアコンテンツアイテムをストリーミングするために）コンテンツサーバからのメディアコンテンツアイテムを要求することに応答して、ＤＲＭクライアントは暗号化されたメディアデータを受信し得る。当該暗号化されたメディアデータは、１つ以上のキーを含むメディアライセンスで復号されると、ＤＲＭクライアント上でメディアコンテンツアイテムを再生する。メディアコンテンツライセンスについての要求はたとえば、タイトル情報、ビデオフォーマット情報、解像度またはビットレート、アスペクト比、長さ情報、オーディオフォーマット情報、字幕情報などといった、メディアコンテンツアイテムに関連付けられるメタデータを含み得る。別の例では、メディアコンテンツライセンスについての要求は、ユーザアカウントに関連付けられるユーザ名およびパスワードといったユーザクレデンシャル情報と、デバイス識別子、デバイスタイプ情報、接続情報などといったデバイス情報とを含み得る。

いくつかの実現例では、ＤＲＭライセンスサーバは、ＤＲＭクライアントデバイスからのライセンス要求に対応するべきかどうか決定し得る。たとえば、ＤＲＭライセンスサーバは、ユーザアカウントについて前回の更新期間に受信されたライセンス更新要求の数を数えることによって、任意の好適な数のＤＲＭクライアントデバイスから、あるユーザアカウントに関連付けられる同時ストリーミング接続の数を検出し得る。この例を引き続き参照して、ＤＲＭライセンスサーバが前回の更新期間内にＤＲＭクライアントインスタンスから更新要求を受信していない場合、ＤＲＭライセンスサーバは、ＤＲＭクライアントデバイスがもはやメディアコンテンツアイテムを再生していないということの指示としてそのような情報を使用し得る。これは、たとえば、ＤＲＭクライアントデバイスのユーザがメディアコンテンツアイテムの再生を非継続にしたかもしれないし、キー使用権がライセンス終了により無効化または非継続にされたかもしれないなどといったことである。

いくつかの実現例では、ＤＲＭライセンスサーバは、キューにおける古いエントリがライセンス期間と同等な時間の後に終了し得るライセンス更新要求のキューを維持することによって、同時ストリーミング接続の数を検出し得る。これにより、ＤＲＭライセンスサーバは、新しい初期のライセンス要求に応答して、同時進行中の再生セッションを決定するようキュー（たとえばライセンス更新サーバキュー）をチェックすることにより、初期のライセンスを発行するべきかどうか決定し得る。

なお、特定のユーザアカウントで認証されたユーザデバイスからの新しい初期のライセンス要求にどのように応答するかを決定することにおいてＤＲＭライセンスサーバを支援する任意の好適な情報が得られ得る。たとえば、ライセンス要求を処理するＤＲＭライセンスサーバと、ライセンス更新要求を処理するととともにライセンス更新キューを維持する１つ以上のライセンス更新サーバとを含む実現例において、そのような情報は、アクティブセッションの数と、ライセンス更新要求の数と、ライセンス更新の数と、ライセンス更新要求に関連付けられるタイミング情報と、ライセンス更新要求に関連付けられるデバイス情報と、ライセンス情報と、最大数の許可可能な同時セッションが与えられた好適な応答と、ユーザアカウントについて利用可能なままである同時セッションの数となどを含み得る。

代替的には、ＤＲＭライセンスサーバは、最も古いセッションについてライセンス更新要求が次に受信される時に、ＤＲＭライセンスサーバまたは任意の他の好適な更新サーバに当該最も古いセッションについてライセンス権利を非継続にしつつ、常に新しい要求に
対応するように構成され得る。これはたとえば、他の再生セッションが進行中であると考えられるので、新しい要求を拒否するのではなく、最も最近のユーザ要求を常に許可するという利点がある。

図１を再び参照して、いくつかの実現例では、１２０において、ＤＲＭクライアントデバイスからメディアライセンスについて受け取られた要求に応答して、ＤＲＭライセンスサーバは、制限された期間のライセンスを含む応答を送信し得る。たとえば、ＤＲＭクライアントデバイスによって送信される要求からのメタデータまたは他の情報を使用して、ＤＲＭライセンスサーバは、復号されるべきメディアデータに関連付けられる１つ以上のキーを特定して取得し得るとともに、１つ以上のキーを制限された期間のライセンスに含め得る。より特定的な例において、ＤＲＭライセンスサーバによって発行されるライセンスは、各々がキー識別子に関連付けられ得る１つ以上のキーと、キーの使用に関する任意の他の好適な情報とを含む、キーシステムに特有の状態情報であり得る。

なお、そのようなライセンスの期間はたとえば、所与の数の分（たとえば３分、５分など）であり得る。たとえば、ライセンスの期間は、メディアコンテンツアイテムの期間または全体的な再生の長さと同等であり得る。別の例において、ライセンスの期間は、メディアコンテンツアイテムの期間、および、メディアコンテンツアイテムの再生を一時停止するといったユーザインタラクションについての付加的な期間と同等であり得る（たとえばコンテンツ期間プラスｘ分）。さらに別の例では、ライセンスの期間は、メディアコンテンツアイテムの全体的な再生長さと比較して短い期間としてセットされ得る（たとえば３０分の合計の再生期間を有するメディアコンテンツアイテムについて５分のライセンス期間）。また、そのようなライセンスは、いくつかの実現例において、特定のライセンス期間をセットしてライセンス更新を可能にするポリシーを有するように構成され得、ライセンスの終了に先立って、ＤＲＭクライアントデバイスは、メディアライセンスを維持してメディアコンテンツアイテムを再生し続けるためにライセンス更新要求を発行する。ライセンスに含まれる１つ以上のキーは、ライセンスが終了している場合、メディアコンテンツ（たとえばメディアデータの１つ以上のブロック）の復号には使用可能ではあり得ない。

いくつかの実現例において、ＤＲＭライセンスサーバまたはライセンス更新サーバ（たとえばライセンス更新のアカウントを維持する好適なサーバ）によって発行されるライセンスは、任意の好適なパラメータに基づいて構成され得る。たとえば、コンテンツプロバイダは、特定のユーザアカウント、特定のデバイス、特定のあるメディアコンテンツなどについて動的にライセンスのライセンス期間を調節する任意の好適なパラメータを提供し得る。そのようなパラメータは、サーバオーバーロード（たとえば、サーバリソースの使用を緩和するためにライセンス期間を増加すること）と、データセンタの停止（たとえばデータセンタの停止の検出に応答してライセンス期間を増加すること）と、良い挙動または優良な態度と考えられるユーザアカウント（たとえば、検出された疑わしい挙動がないかまたはほとんどない特定のユーザアカウントについてライセンス期間を増加すること）と、疑わしい挙動が検出されたユーザアカウント（たとえばライセンス期間を減少させ、および／または、ユーザ挙動に基づいて同時セッションの数を減少または動的に変化させる異なるライセンスポリシーを適用すること）と、競合の解消（たとえば、サーバが異常な状況が存在することを示すことに応答して、良い挙動と考えられるユーザアカウントについて初期のライセンスまたはライセンス更新を自動的に許可すること）と、メディアタイプ（たとえば、より短いオーディオクリップとは対照的に、より長いムービーはより短いライセンス期間を受ける）ことなどとの決定に応答して、または、これらの指示を受信することに応答してライセンス期間の調節を引き起こし得る。

いくつかの実現例では、ライセンス期間が修正されることを可能にすることに対して付
加的または代替的には、任意の好適なパラメータに基づいて、更新要求間隔も修正され得る。たとえば、ユーザアカウントまたはユーザデバイスの一般的な挙動（たとえば、検出された疑わしい挙動のインスタンスを有していない点において良い挙動、しきい値より疑わしい挙動の検出の数が大きい点で悪い挙動、特定の期間未満である挙動情報を有するユーザアカウントまたはユーザデバイスを有する点で未決定の挙動など）を示すパラメータに応答して、更新要求間隔は、挙動パラメータに基づいて修正され得る。より特定的な例において、サーバは、デフォルト期間（たとえば、より短くより制限的な２分の更新猶予期間と比較して、５分のより長い更新猶予期間）の更新要求間隔を有するライセンスを発行し得、ユーザアカウントまたはユーザデバイスに関連付けられる挙動情報に応答して、後のライセンス要求における更新要求間隔が減少されるべきであるかどうか決定し得る。この例において、初期のライセンス要求は、たとえば６分ごとといったようなより長い更新要求間隔を有するあまり制限的でないライセンスを受け得るが、ライセンス更新要求は、疑わしい挙動を検出すること（たとえば、特定のしきい値より大きい特定の期間内のライセンス要求の数）に応答して、２分ごとといったようなより短い更新要求間隔を有するより制限的なライセンス更新を受け得る。これはたとえば、他のライセンスが有効な間にユーザアカウントが複数の新しいライセンス要求を有するという決定に応答して、使用され得る。これは、特定のユーザアカウントのユーザが、同時に多くのメディアコンテンツをストリーミングし、更新要求をブロックすることにより自身のアカウントを乱用していることか、または、ユーザが消費することに興味を持っているメディアコンテンツを見つけるまでさまざまなメディアコンテンツを正当に閲覧していることを示し得る。

なお、任意の好適なアプローチは、更新要求間隔をセットするために使用され得る。たとえば、サーバは、各ユーザアカウントまたは各ユーザデバイスに挙動指示を関連付け得る。各挙動指示は、特定のライセンス期間および／または特定の更新要求間隔に関連付けられる。挙動指示を受信することに応答して、ＤＲＭライセンスサーバは、受信されたライセンス要求またはライセンス更新要求に応答して、適切なライセンスを送信し得る。

いくつかの実現例では、発行されたライセンスについてライセンス更新が許可される場合に、ライセンスは、ライセンス更新要求を処理するための１つ以上のサーバに関係する情報を含み得る（たとえば１つ以上のライセンス更新サーバについてのＵＲＬ）。いくつかの実現例では、そのような情報は、１つ以上のライセンス更新サーバのＵＲＬの順序づけられたリストを含み得る。当該ＵＲＬの例としては、第１のライセンス更新サーバについてのＵＲＬと、所与のタイムアウト期間内に応答が受信されない場合の第２のライセンス更新サーバについてのＵＲＬなどとがある。代替的には、いくつかの実現例では、そのような情報は、第１のライセンス更新サーバのＵＲＬと、第１のライセンス更新サーバが特定の期間内に到達できない場合にはライセンス更新サーバの１つ以上のフォールバックＵＲＬ（fallback URL）とを含み得る。

いくつかの実現例では、１３０において、ＤＲＭクライアントは、現在発行されているライセンスについてライセンス更新が必要かどうか決定し得る。たとえば、１２０において発行されたライセンスを受信することに応答して、ＤＲＭクライアントは、ライセンス期間が特定の期間（たとえば５分）であり、かつ、発行されたライセンスについてのライセンス更新が特定のライセンス更新要求間隔で許可されることを決定し得る。ライセンス期間を決定することに応答して、ＤＲＭクライアントは、現在発行されているライセンスの終了の２分前（または現在発行されているライセンスの終了より充分に前の時間）といったような、ライセンス更新が得られるべきである特定の時間期間を決定し得る。

より特定的な例において、ＤＲＭクライアントは、発行されたライセンスに関連付けられるポリシーがライセンス期間および更新要求間隔（またはライセンス更新要求同士の間の時間）を示すことを決定し得る。たとえば、現在発行されているライセンスを延長する
ことによりメディアコンテンツアイテムを再生し続けることをユーザが望む場合、ポリシーは、特定のライセンス更新ウィンドウが特定の時間に開くことをＤＲＭクライアントに命令し得る。たとえば、ライセンス更新要求は、現在発行されているライセンスの終了の少なくとも１分前に開く更新ウィンドウ内においてＤＲＭサーバから受信され得る。なお、ライセンス更新ポリシーは、任意の好適なパラメータ（たとえば、アカウントごと、デバイスごと、メディアコンテンツタイトルごとなど）に基づいて、ＤＲＭライセンスサーバによって動的に調節され得る。当該調節は、サーバオーバーロードまたはデータセンタ停止中のライセンス期間を増加することと、特定タイプの挙動を示すと考えられるユーザアカウントについてライセンス期間を増加することと、特定タイプの挙動を示すと考えられるユーザアカウントについて更新要求間隔をより頻繁にすることとなどを含み得る。

いくつかの実現例では、現在発行されているライセンスの終了に先立って、ライセンス更新がメディアコンテンツアイテムを再生し続けるために必要とされると決定することに応答して、ＤＲＭクライアントデバイスは、１４０においてライセンス更新要求を送信し得る。ライセンス更新要求は、現在発行されているライセンスに関連付けられるライセンス識別子、現在アクティブなストリーミング接続に関連付けられるセッション識別子、現在発行されているライセンスの終了に先立ったある量の時間、または、ライセンス更新を発行するためにＤＲＭライセンスサーバによって必要とされるＤＲＭクライアントデバイスからの任意の他の好適な情報といった、任意の好適な情報を含み得る。いくつかの実現例では、ＤＲＭライセンスサーバによって発行されるライセンスは、現在発行されているライセンスについてライセンス更新を発行するためにどんな情報（たとえばユーザアカウント情報、ライセンス情報、デバイス情報、タイミング情報、または、その任意の好適な組み合わせ）が必要かに関する命令を含み得る。

いくつかの実現例では、ライセンス更新要求に対する応答が受信されない場合、ＤＲＭクライアントデバイスは、構成されたタイムアウトの後に、有効な更新を任意の好適な回数だけ取得するようライセンス更新要求を繰り返し得る。たとえば、ライセンス更新要求に対する応答は、特定のライセンス更新サーバの停止により受信されない場合がある。より特定的な例において、第１のＵＲＬにてライセンス更新サーバへライセンス更新要求を送信することに応答して、ＤＲＭクライアントデバイスは、フォールバックＵＲＬにて別のライセンス更新サーバに、その後のライセンス更新要求を送信し得る。ライセンス更新要求の送信は、ライセンス更新が得られるまで、フォールバックＵＲＬにてライセンス更新サーバに送信され続け得る。

１５０において、ＤＲＭクライアントデバイスからのライセンス更新要求を受信することに応答して、ＤＲＭライセンスサーバは、ライセンス更新を発行するべきかどうか決定し得る。たとえば、ＤＲＭライセンスサーバは、別のライセンス更新期間についてライセンスを延長するべきか、または、キー使用権を非継続にするべきかどうかを決定し得る。なお、ライセンス更新を発行する決定は、メディアキーの使用を継続するようライセンス更新期間（たとえばさらに３分、さらに５分など）をセットすることを含み得、これによりメディアコンテンツアイテムが再生され続けることが可能になる。また、ライセンスにおけるメディアキーの使用の非継続または無効化は、たとえば０の期間のライセンス更新を送信すること、または、そうでなければキー使用権を終了する命令を発行することによって行なわれ得る。

いくつかの実現例では、上述したように、ＤＲＭライセンスサーバは、ユーザアカウントについて前回の更新期間に受信されたライセンス更新要求の数を数えることによって、任意の好適な数のＤＲＭクライアントデバイスからユーザアカウントに関連付けられる同時ストリーミング接続の数を検出し得る。この例を引き続き参照して、ＤＲＭライセンスサーバが前回の更新期間内にＤＲＭクライアントインスタンスから更新要求を受信してい
ない場合、ＤＲＭライセンスサーバは、ＤＲＭクライアントデバイスはもはやメディアコンテンツアイテムを再生していないことの指示として、そのような情報を使用し得る。当該指示の例としては、ＤＲＭクライアントデバイスのユーザがメディアコンテンツアイテムの再生を非継続にしたことの指示、キー使用権がライセンス終了などにより無効化または非継続にされたことの指示などがある。

いくつかの実現例では、ＤＲＭライセンスサーバは、キューにおける古いエントリがライセンス期間と同等な時間の後に終了し得るライセンス更新要求のキューを維持することにより、同時ストリーミング接続の数を検出し得る。したがって、ＤＲＭライセンスサーバは、ライセンス更新要求に応答して、同時進行中の再生セッションを決定するようキュー（たとえばライセンス更新サーバキュー）をチェックすることにより、ライセンス更新を発行するべきかどうか決定し得る。

なお、１つ以上のライセンス更新サーバがライセンス更新要求を処理する実現例において、ライセンスサーバは、ライセンス更新キューについてクエリ送信し、かつ、ライセンス更新要求を処理するために使用され得る情報を決定し得る。当該情報の例としては、アクティブセッションの数、ライセンス更新要求の数、ライセンス更新の数、ライセンス更新要求に関連付けられるタイミング情報、ライセンス更新要求に関連付けられるデバイス情報、ライセンス情報、許可可能である最大数の同時セッションが与えられた好適な応答、ユーザアカウントについて利用可能なままである同時セッションの数などがある。

代替的には、いくつかの実現例では、ＤＲＭライセンスサーバは、初期のライセンス要求および／またはライセンス更新要求が自動的に対応される検出のみモードを実現し得るとともに、要求と関連付けられるライセンスおよびライセンス更新とのログを維持する。これは、たとえば、サーバオーバーロード、データセンタ停止などの期間中に実現され得る。

なお、いくつかの実現例では、ＤＲＭライセンスサーバは、最も古いセッションについてライセンス更新要求が次に受信される時に、ＤＲＭライセンスサーバまたは任意の他の好適な更新サーバに当該最も古いセッションについてライセンス権利を非継続にしつつ、常に新しい更新要求に対応するように構成され得る。終了のために指定されたキューにおけるより古いセッションにライセンス更新要求が対応すると決定することに応答して、ＤＲＭライセンスサーバは、０の期間を有するライセンス更新またはメディア権の非継続を実施する他の何らか手段によりライセンス更新要求に応答し得る。これはたとえば、他の再生セッションが進行中であると考えられるので、新しい要求を拒否するのではなく、最も最近のユーザ要求を常に許可するという利点が存在し得る。

１６０において、特定の更新パラメータを有するライセンス更新メッセージは、ＤＲＭライセンスサーバからＤＲＭクライアントデバイスに送信され得る。ＤＲＭクライアントデバイスは、１７０において、受信されたライセンス更新メッセージに基づいて、メディアコンテンツアイテムの再生が許可されるかどうかを決定し得る。たとえば、上述したように、ライセンス更新メッセージの受信に応答して、ＤＲＭクライアントデバイスは、受信されたライセンス更新メッセージから更新パラメータを抽出し得、ライセンスへの延長が特定の期間（たとえば初期のライセンスに関連付けられるライセンス期間と同じである別の短い期間、初期のライセンスに関連付けられるライセンス期間未満である短期間など）について許可されたと決定し得る。１８０において、更新されたライセンスを有するメディア再生アイテムは再生され続け得る。ＤＲＭクライアントデバイスは１３０に戻り得、ライセンス更新がメディアコンテンツアイテムを再生し続けるために必要であるかどうかその後の時間において決定され得る。たとえば、更新されたライセンスの終了に先立って（たとえばライセンス更新ウィンドウが開いたとき）、ＤＲＭクライアントデバイスは
、メディアコンテンツアイテムを再生し続けるためにライセンス更新が必要かどうか決定し得る。

別の例において、上述したように、ライセンス更新メッセージを受信することと、受信されたライセンス更新メッセージから更新パラメータを抽出することと、０の期間のライセンス更新（またはメディア権の非継続を実施する何らかの他の手段）が発行されたと決定することとに応答して、ＤＲＭクライアントデバイスは、キーへのアクセスを無効化し得、これにより、１９０においてメディアコンテンツの再生を終了する。

いくつかの実現例では、異なる実施モードが、開示される主題に関して使用され得る。ライセンス期間および更新要求間隔がＤＲＭライセンスサーバによって動的に調節され得る例示的な例において、ＤＲＭライセンスサーバは、複数の実施モードのうちの１つを実現するようにそのような調節を行い得る。

図２を参照して、ＤＲＭライセンスサーバは、２１０において、ユーザアカウントに対応するクレデンシャルで認証されたユーザデバイスから要求を受信することによってプロセス２００を開始し得る。たとえば、当該要求は、再生のためのメディアコンテンツアイテムを選択することに応答する初期のライセンスについての要求であり得る。

２２０において、ＤＲＭライセンスサーバは、特定のライセンスパラメータを有する実施モードに従って、要求に対する応答を送信し得る。たとえば、ＤＲＭライセンスサーバは、初期の検出のみモードで、各ＤＲＭクライアントデバイスを開始し得る。この例を引き続き参照して、初期の検出のみモードにおいて、ＤＲＭライセンスサーバは、更新要求間隔を５分（または任意の他の好適な要求間隔）にセットし、メディアコンテンツアイテムのコンテンツ期間プラスｘ分と同等のライセンス期間（たとえばコンテンツ期間＋メディアコンテンツアイテムの再生中に受信され得る休止命令についてのｘ分など）をセットし得る。なお、任意の好適な初期の更新要求間隔および／またはライセンス期間は、この検出のみ実施モードで提供され得る。

いくつかの実現例では、ＤＲＭライセンスサーバは、２３０において、ユーザアカウント挙動情報にアクセスし当該ユーザアカウント挙動情報を検討することにより、継続し得る。たとえば、ユーザアカウントに対応するクレデンシャルで認証されたユーザデバイスからライセンス要求またはライセンス更新要求を受信することに応答して、かつ、ＤＲＭライセンスサーバが要求に対応するべきかどうか決定することに関連して、プロセス２００は、ユーザアカウントに関連付けられるライセンスレコードにアクセスし得、ユーザアカウントレコードにおける情報が疑わしい挙動を示すかどうか決定し得る。疑わしい挙動はたとえば、ユーザアカウントに関連付けられる１つ以上のデバイスによる更新要求の可能性のある抑制またはなされ得る抑制を示す情報を含み得る。より特定的な例において、ユーザアカウントが複数のデバイスにわたって特定の数の新しいライセンス要求より多い新しいライセンス要求を生成しており、かつ、特定の期間内に更新要求を生成していないことをユーザアカウントレコードにおける情報から検出することに応答して、ＤＲＭライセンスは、そのようなユーザアカウント挙動情報を、更新要求がユーザアカウントに関連付けられるデバイスによって抑制されているという指示として使用し得、ライセンスまたはライセンス更新パラメータを調節し得る。

いくつかの実現例では、２４０において、ＤＲＭライセンスサーバは、ライセンスまたはライセンス更新パラメータを調節し得る。たとえば、更新要求の可能性のある抑制（またはユーザアカウントに関する任意の他の疑わしい挙動）を検出することに応答して、ＤＲＭライセンスサーバは、当該ユーザアカウントに、調節されたライセンスパラメータを有する異なる実施モードを課し得る。概して言えば、これは、たとえばより短いライセン
ス期間および／またはより頻繁な更新要求間隔を含むより厳しい実施モードであり得る。

図２に示されるように、ＤＲＭライセンスサーバが、ユーザアカウントに関連付けられる１つ以上のデバイスから要求を受信することを継続すると、ＤＲＭライセンスは２３０に戻り得、ユーザアカウント挙動情報を検討し続け得る。したがって、更新要求の可能性のある抑制（または当該ユーザアカウントに関する任意の他の疑わしい挙動）を検出し続けることに応答して、ＤＲＭライセンスサーバは、当該ユーザアカウントに、調節されたライセンスパラメータを有するさらに別の実施モードを課し得る。当該さらに別の実施モードはたとえば、さらに調節されたライセンス期間および／またはさらに調節された更新要求間隔を有する厳しい実施モードである。

いくつかの実現例では、２５０において、ＤＲＭライセンスサーバが、ユーザアカウント挙動情報に基づいて、現在の実施モードを修正するべきかどうか決定し得る。たとえば、ユーザアカウントに関連付けられるデバイスが更新要求を抑制しているか、または、疑わしい挙動を示している可能性がより低いと決定することに応答して、ＤＲＭライセンスサーバは、実施モードを修正し得るか、または、そうでなければユーザアカウントに関連付けられるデバイスからの要求に関連付けられるライセンスパラメータを調節し得る。より特定的な例において、ＤＲＭライセンスサーバは、複数のレベルの実施を含み得、ユーザアカウント挙動情報に応答して、ＤＲＭライセンスサーバは、実施のレベルを（たとえば検出のみ実施モードとより厳しい実施モードとの間で）増加または減少させるべきかどうかを決定し得る。別のより特定的な例において、ＤＲＭライセンスサーバは、特定の量の時間が経過したことを検出することに応答して、実施のレベルをより厳しくない実施モードに低減し得る。さらに別のより特定の例において、ＤＲＭライセンスサーバは、特定の量の時間が経過したことを検出することと、ユーザアカウントに関連付けられるデバイスが疑わしい挙動を示し続けていることとに応答して、０の期間のライセンスまたはライセンス更新を発行し得、これによりメディアキーの使用を非継続または無効化する。

適用され得る複数の実施モードの例示的な例が図３に示される。
示されるように、ＤＲＭライセンスサーバは、３１０において、特定の更新間隔および特定のライセンス期間を有する検出のみモードを適用することにより開始し得る。たとえば、図２に関連して上述したように、ＤＲＭライセンスサーバは、初期の検出のみモードで各ＤＲＭクライアントデバイスを開始し得る。この例を引き続き参照して、初期の検出のみモードにおいて、ＤＲＭライセンスサーバは、更新要求間隔を５分（または任意の他の好適な要求間隔）にセットし、メディアコンテンツアイテムのコンテンツ期間プラスｘ分と同等のライセンス期間（たとえばコンテンツ期間＋メディアコンテンツアイテムの再生中に受信され得る休止命令についてのｘ分など）をセットし得る。なお、任意の好適な初期の更新要求間隔および／またはライセンス期間が、この検出のみ実施モードにおいて提供され得る。

検出のみモードの間、ＤＲＭライセンスサーバは、ユーザアカウントに関連付けられるユーザデバイスから要求を受信し続け得、３２０において、ライセンスレコードについてクエリ送信することと、ユーザアカウントに関連付けられるユーザアカウント挙動情報を検討することによって、更新要求の抑制の可能性（またはユーザアカウントに関する任意の他の疑わしい挙動）を検出することに応答して、３３０において、更新間隔および／またはライセンス期間パラメータを調節した軽量実施モードが適用され得る。たとえば、ライセンスレコードにおけるユーザアカウント挙動情報を検討することと、特定の期間内において、ユーザアカウントが（たとえば複数のデバイスにわたって）特定の数の新しいライセンス要求よりも多い新しいライセンス要求を生成しており、更新要求を生成していないことを検出することとに応答して、ＤＲＭライセンスサーバは、更新要求が抑制されていることの指示としてユーザアカウント挙動情報を使用し得、当該ユーザアカウントに軽
量実施モードを課し得る。

軽量実施モードにおいて、ＤＲＭライセンスサーバは、更新要求間隔および／またはライセンス期間を修正し得る。上述した例を引き続き参照して、ＤＲＭライセンスサーバは、更新要求間隔を５分（または任意の他の好適な要求間隔）に維持し得、ライセンス期間をコンテンツ期間の半分（コンテンツ期間÷２）に等しくなるように設定し得る。なお、ライセンス期間をメディアコンテンツアイテムのコンテンツ期間の半分と同等に設定することは単に例示であり、メディアコンテンツアイテムのコンテンツ期間未満である任意の好適なライセンス期間が設定され得、および／または、検出のみモードにおいて設定されたライセンス期間未満である任意の好適なライセンス期間が設定され得る。ユーザアカウントのユーザが更新要求を抑制していることに応答して、そのようなユーザアカウントは、メディアコンテンツ全体を消費することが可能でなくなる。

軽量実施モードの間、ＤＲＭライセンスサーバは、ユーザアカウントに関連付けられるユーザデバイスからの要求を受信し続け得、更新要求の抑制の可能性（またはユーザアカウントに関する任意の他の疑わしい挙動）を検出することに応答して、３４０において、ライセンスレコードについてクエリ送信し、ユーザアカウントに関連付けられるユーザアカウント挙動情報を検討する。たとえば、ユーザアカウントに関連付けられるデバイスからのライセンス要求またはライセンス更新要求を受信することに応答して、ＤＲＭライセンスサーバは、この機会を利用して、ライセンスレコードに基づいてユーザアカウント挙動情報をさらに検討し得る。

図３を再び参照して、ユーザアカウントに関連付けられるデバイスが疑わしい挙動に関わりがある可能性があるとユーザアカウント挙動情報が示し続けていると決定することに応答して、３５０において、さらに調節された更新間隔またはライセンスの期間パラメータを有する厳しい実施モードが適用され得る。たとえば、ＤＲＭライセンスサーバは、特定の期間が経過したことと、当該ユーザアカウントに関連付けられるデバイスがライセンス更新要求を抑制している可能性があることを示す挙動を示していることとを決定することに応答して、厳しい実施モードを適用し得る。別の例において、ＤＲＭライセンスサーバは、同じデバイス上での同じメディアコンテンツアイテムについての２つ以上の新しいライセンス要求の受信、または、疑わしいライセンス更新要求の受信といった特定のイベントがライセンスレコードに記録されたことを検出することに応答して、厳しい実施モードを適用し得る。

より特定的な例において、ユーザアカウントが一貫して同じデバイス上で同じメディアコンテンツについて２つ以上の新しいライセンス要求を生成していることを検出することに応答して、または、デバイスから疑わしい更新要求を受信すること（たとえば５分の更新間隔の代わりに、前回の更新要求からの時間がライセンス期間に近いこと）に応答して、ＤＲＭライセンスサーバは、ライセンスレコードからのそのような情報を、更新要求が抑制されていることの指示および（ライセンスが終了するときに）コンテンツの途中でリロードが実行されていることの指示として使用し得る。なお、軽量実施モードを課されたユーザアカウントは、サーバ停止によってほんのわずか多く影響を受け得る。なぜならば、延長された停止のみが、メディアコンテンツアイテムの再生を停止させ得るからである。また、疑わしい挙動が継続する場合、ユーザアカウントは、より厳しい実施モード、または、より制限的な任意の他の好適なモードを課され得る。

厳しい実施モードにおいて、ＤＲＭライセンスサーバはさらに、更新要求間隔および／またはライセンス期間パラメータを修正し得る。上述した例を引き続き参照して、ＤＲＭライセンスサーバは、更新間隔を３分（または任意の他の好適な要求間隔）にセットし得、ライセンス期間を５分（または任意の他の好適な期間）にセットし得る。したがって、
更新要求が抑制されている場合、ユーザアカウントのユーザは一度に５分間より多くメディアコンテンツを視聴できない。なお、厳しい実施モードを課されたユーザアカウントは、数分（たとえば２分）より長いサーバ停止によってのみ影響を受け得る。

また、いくつかの実現例では、特定の期間が経過した（たとえば１週間、２週間など）後、ＤＲＭライセンスサーバは、３６０において、上で説明された軽量実施モードまたは検出のみモードのようなより緩和されたモードを当該ユーザアカウントに課し得る。

なお、ほとんどのユーザは概して、緩和された実施モードに関連付けられるカテゴリーに該当するので、より緩和された実施モードを課されたユーザアカウントについてのユーザ体験は、影響を受け得ず、サーバリソースも影響を受け得ない。また、乱用していないユーザの場合、更新サーバ停止があると、より制限的なモードを課されることはユーザおよびユーザ体験に単に否定的に影響し得るが、そのような停止においてさえ、ユーザには長い猶予期間が与えられ得、疑わしいユーザは代替的なサーバに到達し得る。

図４は、本願明細書において記載されるような繰り返されるライセンス更新によるメディアセッション同時性管理のためのメカニズムがいくつかの実現例に従って実現され得るシステムの一般化された概略図の例４００を示す。示されるように、システム４００は１つ以上のユーザデバイス４１０を含み得る。ユーザデバイス４１０は互いにローカルまたは互いにリモートであり得る。ユーザデバイス４１０は、１つ以上の通信リンク４０８によって通信ネットワーク４０６に接続され得、通信ネットワーク４０６は、通信リンク４０４を介してデジタル権利管理（ＤＲＭ： digital rights management）ライセンスサーバ４０２のようなサーバにリンクされ得る。

システム４００は１つ以上のサーバ４０２を含み得る。サーバ４０２は、プロセッサ、コンピュータ、データ処理デバイスまたはそのようなデバイスの任意の好適な組み合わせといった、繰り返されるライセンス更新によるメディアセッション同時性管理のための本願明細書において記載されるメカニズムへのアクセスを提供するための任意の好適なサーバであり得る。いくつかの実現例では、ライセンス要求およびライセンス更新要求を処理するＤＲＭライセンスサーバ４０２は、任意の好適な数のサーバとして分散され得る。たとえば、上述したように、かつ、図４に示すように、初期のライセンスを発行するとともにライセンス更新を発行するためのメカニズムは、複数のバックエンドコンポーネントならびに複数のフロントエンドコンポーネントおよび／またはインターフェイスに分散され得る。より特定的な例において、１つ以上のメディアキーで応答し得る、１つ以上のユーザデバイス４１０からの初期のライセンス要求を処理するＤＲＭライセンスサーバ４０２が提供され得、かつ、メディアキーの使用の延長または無効化を示すポリシーデータで応答し得る、ライセンス更新要求を処理する１つ以上のライセンス更新サーバ４２０が提供され得る。この例において、複数のサーバデバイス４０２および４１０を有することにより、ライセンス更新要求に対する応答はたとえば、メディアキーの抽出とライセンスへのメディアキーの組み込みとを含み得る、初期のライセンス要求に応答することよりも速くなり得る。これはさらに、ライセンス更新を処理する１つ以上のライセンス更新サーバ４２０が、キーサーバまたはキーストレージデバイスおよびユーザアカウントデータベースから分離されることを可能にし得る。以下に記載されるように、これはさらに、システム４００がライセンス更新を処理する複数のサーバを含むこと（たとえばサーバの信頼性および冗長性を提供すること）を可能にし得る。

いくつかの実現例において、複数のライセンスサーバ４０２および４２０は、信頼性を増加させること、および／または、サーバがユーザデバイス４１０と通信し得る（たとえばライセンスおよび／またはライセンス更新の通信）速度を増加させることを行うよう、さまざまな位置において実現され得る。

いくつかの実現例において、さらに別のサーバ（またはサーバのセット）が、同時セッションの数を示すためのライセンスおよび更新ライセンスのレコードを維持し得る。

ライセンス更新のいくつかの実現例は、サーバ４０２および４２０ならびにユーザデバイス４１０がメッセージを認証するために使用されるセッションキーの共有された認識を有することを必要とし得るが、本願明細書において記載されるメカニズムは、初期のライセンス要求に対応するサーバ４０２と、ライセンス更新要求に対応するサーバ４２０とが、同じセッションキーを導出し得るとともにそれらの間で如何なる情報も交換する必要なくメッセージを認証および署名し得るように、そのようなキーを計算するために実現され得る。したがって、ライセンスサーバ４０２が初期のライセンス要求に対応するのに必要なインフラストラクチャにアクセスすることができない場合でも、ライセンス更新サーバ４２０はライセンス更新要求に対応し続け得る。さらに、ライセンスサーバ４０２および／または４２０は、バックエンドインフラストラクチャが利用不可能になり、同時性をチェックすることができなくなった場合のような非常モードにおいてライセンスを常に更新するように構成され得る。

そのような実現例では、（たとえばオリジナルのＤＲＭサーバ４０２が到達できなくても）ライセンスサーバが作動しており到達可能な場合、既存のメディア再生セッションは中断され得ない。したがって、ライセンスサーバの冗長性を加えることにより、レジリエンシーが増加され得、メディア再生アプリケーションは、ライセンス更新メッセージまたは要求を処理するために複数のＵＲＬを含み得る。これは、たとえば、メディア再生アプリケーションがサーバ割込または障害に対してよりレジリエントであることを可能し得る。

いくつかの実現例では、システム４００は、構成およびインフラストラクチャにわたってライセンス更新サーバ４２０を展開することによって、レジリエンシーをさらに増加させるために実現され得る。これはたとえば、中央サーバまたはデータセンタが到達不可能になるというイベントにおいて、ライセンス更新要求が処理される可能性を増加させ得る。

なお、ライセンス更新は、メディアキーの使用を延長または無効化するべきであるかどうかを示すポリシーデータを含んでいる（そしてメディアキー自身は含んでいない）ので、一般に初期のライセンスよりサイズがより小さい。このため、ライセンス更新要求は、初期のライセンス要求よりも、より少数のリソースに対応することを要求し得る。次いで、ライセンス更新サーバ４２０は、キーサーバ／ストアと、たとえば、メインユーザアカウントデータベースとから分離され得る。したがって、ライセンス更新サーバ４２０は、初期のライセンス要求に対応するサーバ４０２とは異なり得る。これは、たとえば、全体的なシステム４００の信頼性を増加させ得る。

開示される主題のいくつかの実現例では、本願明細書において記載される同時性実施システム４００は、分散された冗長性を使用して同時性実施システムの信頼性を増加するよう実現され得る。そのような実現例は、（たとえば検出のみ実施モードまたは軽量実施モードを課されたユーザアカウントはサーバ停止によって悪影響を受け得ないので）上述した厳しい実施モードを課されたユーザアカウントのユーザにとって妥当であり得る。

いくつかの実現例では、初期のライセンス要求に対応するライセンスサーバ４０２が利用不可能になると、ユーザデバイス４１０上で実行されるメディア再生アプリケーションからの初期のライセンス要求はフェイルすることになる（たとえば５０３または他のエラーメッセージ）。たとえば、メディア再生アプリケーションは、ライセンスサーバ４０２
がライセンス要求に対して応答を提供することができなかったことを示すＨＴＴＰ応答コードを受信し得る。ライセンス要求メッセージについてネットワークおよび／またはサーバ障害を検出することに応答して、クライアントデバイス上で実行されるメディア再生アプリケーションは、ＵＲＬ（たとえばライセンスサーバのリストからの次のＵＲＬ）をフォールバックライセンスサーバ４０２に使用して、ライセンスについての要求を送信し得る。上述したように、メディア再生アプリケーションは、たとえば、国にわたる異なるクラスタまたはデータセンタ、別の国における異なるクラスタまたはデータセンタ、別の大陸における異なるクラスタまたはデータセンタなどを含む、ライセンスサーバ４０２について任意の好適な数のフォールバックＵＲＬを有するリストにアクセスし得る。メディア再生アプリケーションは、ライセンスが受信されるまで、１つ以上のフォールバックライセンスサーバ４０２にライセンス要求を送信し続け得る。たとえば、メディア再生アプリケーションは、次のライセンスサーバ４０２に進む前に、特定の回数だけ、特定のライセンスサーバ４０２に到達することを試み得る。別の例において、メディア再生アプリケーションは、異なる位置におけるライセンスサーバ４０２に進む前に、特定の回数だけ、特定の位置におけるライセンスサーバ４０２に到達することを試み得る（たとえば、西海岸ベースのデータセンタが利用不可能な場合、東海岸に位置するライセンスサーバ４０２に到達することを試みる）。なお、いくつかの実現例では、メディア再生アプリケーションは、あるライセンスサーバ４０２が利用可能になりライセンスが受信されるまで、これらの繰り返される要求を実行し得る。

いくつかの実現例では、ライセンス更新要求に対応するライセンス更新サーバ４２０が利用不可能になると、ユーザデバイス４１０上で実行されるメディア再生アプリケーションからのライセンス更新要求がフェイルすることになる（たとえば５０３または他のエラーメッセージ）。たとえば、メディア再生アプリケーションは、ライセンス更新サーバ４２０がライセンス更新要求に対して応答を提供することができなかったことを示すＨＴＴＰ応答コードを受信し得る。ライセンス更新要求メッセージについてネットワークおよび／またはサーバ障害を検出することに応答して、クライアントデバイス上で実行されるメディア再生アプリケーションは、ＵＲＬ（たとえばライセンス更新サーバのリストからの次のＵＲＬ）をフォールバックライセンス更新サーバ４２０に使用して、ライセンス更新についての要求を送信し得る。上述したように、メディア再生アプリケーションは、たとえば、国にわたる異なるクラスタまたはデータセンタ、別の国における異なるクラスタまたはデータセンタ、別の大陸における異なるクラスタまたはデータセンタなどを含む、ライセンス更新サーバ４２０について任意の好適な数のフォールバックＵＲＬを有するリストにアクセスし得る。メディア再生アプリケーションは、ライセンス更新が受信されるまで、１つ以上のフォールバックライセンス更新サーバ４２０にライセンス更新要求を送信し続け得る。たとえば、メディア再生アプリケーションは、次のライセンス更新サーバ４２０に進む前に、特定の回数だけ、特定のライセンス更新サーバ４２０に到達することを試み得る。別の例において、メディア再生アプリケーションは、異なる位置におけるライセンス更新サーバ４２０に進む前に、特定の回数だけ、特定の位置におけるライセンス更新サーバ４２０に到達することを試み得る（たとえば、西海岸ベースのデータセンタが利用不可能な場合、東海岸に位置するライセンス更新サーバに到達することを試みる）。なお、いくつかの実現例において、メディア再生アプリケーションは、現在アクティブなライセンスのライセンス期間が終了していない間、ライセンス更新サーバ４２０からライセンス更新を受信するようこれらの試みを実行し得る。

いくつかの実現例では、ライセンスサーバ４０２は、ライセンス要求を満たすためにユーザデータベースおよびコンテンツキーストアにアクセスすることによって、初期のライセンス要求に対応し始め得る。なお、ライセンスサーババックエンドが利用不可能な場合、サーバはライセンス要求を拒絶する（たとえば、５００、５０３または他のエラーメッセージが受信される）。その後、ライセンスサーバ４０２は、ライセンス要求または同時
使用のレコード（たとえばライセンス更新サーバ４２０または任意の他の好適なサーバにおけるレコード４２２）をチェックし得る。なお、同様に、同時性インフラストラクチャが利用不可能な場合、サーバは、要求に対応するかまたはフェイルする（たとえば、５００、５０３または他のエラーメッセージが受信される）ことを選択し得る。同時性情報に基づいて、ライセンスサーバ４０２は、ライセンス要求を拒絶またはライセンス要求に対応し得る。代替的には、上述したように、ライセンスサーバ４０２は常に、より古いライセンスを非継続のためにフラグを立てつつ、新しいライセンス要求に対応するように構成され得る。

いくつかの実現例では、ライセンス更新サーバ４２０は、ライセンス更新サーバ４２０におけるライセンスレコード４２２のような更新要求または同時使用のレコードをチェックすることによって、ライセンス更新要求に対応し始め得る。非継続のためにセッションにフラグが立てられる場合、ライセンスサーバ４２０は、ライセンス更新要求を拒否し得るか、または、再生が非継続にされるべきであることを示す応答を発行する。そうでなければ、ライセンス更新サーバ４２０はライセンス更新を発行し得る。

いくつかの実現例において、ライセンスサーバ４０２または４２０が、ライセンス更新が発行されるべきかどうか決定するために使用される更新要求または同時使用もしくは任意の他の好適な情報のレコード（たとえばレコード４２２）にアクセスすることができない場合、ライセンスサーバ４０２または４２０は、緊急更新モードに入るべきかどうか決定し得る。たとえば、バックエンドサーバコンポーネントからのレコードにアクセスするのに失敗した試みの回数が所与のしきい値より大きいことに応答して、ライセンスサーバ４０２または４２０は、サーバが緊急更新モードに入るべきであると決定し得る。そのような検出は、ログが記録され得、アラートがトリガされ得る。緊急更新モードにおいて、ライセンスサーバ４２０は自動的にすべての有効なライセンスを更新し得る。緊急更新モードのいくつかの実現例において、（たとえばサーバ停止またはサーバオーバーロード中にサーバへの更新メッセージを緩和するよう）ライセンス期間および／または更新要求間隔が増加され得る。

図４を再び参照して、他のサーバがシステム４００に含まれ得る。たとえば、コンテンツ送達サーバ４３０が、メディアコンテンツアイテムを提示する要求を受信し得、（たとえばＤＲＭライセンスサーバ４０２または任意の他の好適なサーバからのキーがメディアデータを復号することを必要とする暗号化された形態で）メディアコンテンツアイテムを提供し得る。別の例では、コンテンツ送達サーバ４３０は、ユーザデバイス４１０によって表示されているメディアコンテンツに対応するメタデータまたは他の情報を提供し得る。

一般に、ユーザデバイス４１０は、ネットワーク４０６などのようなネットワークを介してメッセージを送受信可能であるとともにコンテンツにアクセスおよび／または再生可能である任意のコンピューティングデバイスを含み得る。さらに、ユーザデバイス４１０は、ラップトップコンピュータ、スマートフォンおよびタブレットコンピュータなどといった、別のコンピューティングデバイスに接続することおよび情報を受信することが可能である任意のコンピューティングデバイスを含み得る。しかしながら、コンピューティングデバイスはそのように限定されておらず、携帯電話、ディスプレイページャ、無線周波数（「ＲＦ」）デバイス、赤外線（「ＩＲ」）デバイス、パーソナルデジタルアシスタント（「ＰＤＡ」）、ハンドヘルドコンピュータ、ウェアラブルコンピュータ、および、前述のデバイスのうちの１つ以上を組み合わせた統合されたデバイスなどといったさらに他のデバイスを含み得る。そのため、ユーザデバイス４１０は典型的に、能力および特徴の点において広い範囲にある。

いくつかの実現例では、ウェブが有効化されたユーザデバイス４１０は、ウェブページおよびウェブベースメッセージなどを送受信するように構成されるブラウザアプリケーションを含み得る。ブラウザアプリケーションは、事実上任意のインターネットベースのプロトコルおよび／またはネットワークベースのプロトコルを用いて、グラフィックス、テキスト、マルチメディア、メディアコンテンツなどを受信および表示するように構成され得る。インターネットベースのプロトコルおよび／またはネットワークベースのプロトコルは、ワイヤレスアプリケーションプロトコルメッセージ（「ＷＡＰ」）またはハイパーテキスト転送プロトコル（「ＨＴＴＰ」）などを含むがこれらに限定されない。１つの実現例において、ブラウザアプリケーションは、メッセージを表示および送信するために、ハンドヘルドデバイスマークアップ言語（「ＨＤＭＬ(Handheld Device Markup Language)」）、ワイヤレスマークアップ言語（「ＷＭＬ(Wireless Markup Language)」）、ＷＭ
ＬＳｃｒｉｐｔ、ＪａｖａＳｃｒｉｐｔ、標準一般化マークアップ言語（「ＳＧＭＬ(Standard Generalized Markup Language)」）、ハイパーテキストマークアップオーディオ言語（「ＨＴＭＡＬ(HyperText Markup Audio Language)」）、および、エクステンシブル
マークアップ言語（「ＸＭＬ(eXtensible Markup Language)」）などを使用するように有効化される。１つの実現例では、クライアントユーザのユーザは、ネットワークを介して（オンラインで）さまざまなアクティビティを実行するためにブラウザアプリケーションを使用し得る。しかしながら、別のアプリケーションもさまざまなオンラインアクティビティを実行するために使用され得る。

ユーザデバイス４１０はさらに、別のコンピューティングデバイスとの間でコンテンツを受信および／または送信するように構成される少なくとも１つの他のクライアントアプリケーションを含み得る。クライアントアプリケーションは、コンテンツなどを送信および／または受信する能力を含み得る。クライアントアプリケーションは、タイプ、能力、および名称などを含む、自身を識別する情報をさらに提供し得る。１つの実現例では、ユーザデバイス４１０は、それら自身をデバイスのクラスの一部として識別し得る。別の実現例では、ユーザデバイス４１０は、電話番号、モバイル識別番号（「ＭＩＮ(Mobile Identification Number)」）、電子シリアルナンバー（「ＥＳＮ(electronic serial number)」）、インターネットプロトコル（ＩＰ(Internet Protocol)）アドレス、ネットワー
クアドレス、または、他のモバイルデバイス識別子を含むさまざまなメカニズムのうちのいずれかを介して自身を一意に識別し得る。情報はさらに、モバイルデバイスによって使用することが可能とされるコンテンツフォーマットを示し得る。そのような情報は、ネットワークパケットなどで提供され得、他のクライアントデバイスまたは他のコンピューティングデバイス同士の間で送信され得る。さらに、デバイス、および／または、クライアントデバイスと通信しているあるデバイス内のコンポーネントは、クライアントデバイスによって使用されるメカニズムを含むさまざまなメカニズムのいずれかを使用して、自身を識別し得るということが容易に理解されるべきである。

ユーザデバイス４１０はさらに、別のコンピューティングデバイスによって管理され得るユーザアカウントにユーザがログインすることを可能にするクライアントアプリケーションを含むように構成され得る。そのようなユーザアカウントは、１つの非限定的な例において、ユーザが１つ以上のオンラインアクティビティを管理することを可能にするように構成され得る。当該オンラインアクティビティは、１つの非限定的な例において、検索アクティビティ、ソーシャルネットワーキングアクティビティ、さまざまなウェブサイトをブラウジングすること、または、他のユーザと通信することなどを含む。１つの実現例では、ユーザのクライアントデバイスは、クライアントデバイスにおける再生のためにクライアントデバイスにストリーミングされるコンテンツを受信し得る。しかしながら、オンラインアクティビティへの参加は、ユーザアカウントにログインせずに実行することも可能である。

いくつかの実現例において、ユーザデバイス４１０ならびにサーバ４０２、４２０および４３０の各々は、コンピュータのような汎用デバイスまたはクライアント、サーバなどのような特殊目的デバイスのいずれかであり得る。これらの汎用デバイスまたは特殊目的デバイスのいずれかは、（マイクロプロセッサ、デジタル信号プロセッサ、コントローラなどであり得る）ハードウェアプロセッサ、メモリ、通信インターフェイス、ディスプレイコントローラ、入力デバイスなどといった、任意の好適なコンポーネントを含み得る。たとえば、ユーザデバイス４１０は、カメラを有するスマートフォン、カメラを有するタブレットコンピュータ、カメラを有するウェアラブルコンピュータ、スマートフォンとインターフェイス接続するカメラデバイス（たとえばスマートフォンのためのカメラドングル）、デジタルカメラ（たとえばポイントアンドシュートカメラ（point and shoot camera）、ＤＳＬＲカメラ、デジタルカムコーダなど）、アナログカムコーダ、パーソナルコンピュータ、ラップトップコンピュータ、スマートフォン、タブレットコンピュータ、ゲーミングデバイス、デジタルメディアレシーバ、セットトップボックス、スマートテレビジョン、サーバなどとして実現され得る。

通信ネットワーク４０６は、インターネット、イントラネット、ワイドエリアネットワーク（ＷＡＮ(wide-area network)）、ローカルエリアネットワーク（ＬＡＮ(local-area
network)）、ワイヤレスネットワーク、デジタル加入者線（ＤＳＬ(digital subscriber
line)）ネットワーク、フレームリレーネットワーク、非同期転送モード（ＡＴＭ(asynchronous transfer mode)）ネットワーク、仮想プライベートネットワーク（ＶＰＮ(virtual private network)）などを含むそのようなネットワークの任意の好適なコンピュータ
ネットワークまたは組合せであり得る。通信リンク４０４、４０８、４２５および４３５は、ユーザデバイス４１０ならびにサーバ４０２、４２０および４３０の間でデータを通信するのに好適な任意の通信リンクであり得る。当該通信リンクの例としては、ネットワークリンク、ダイアルアップリンク、ワイヤレスリンク、ハードワイヤードリンク、任意の他の好適な通信リンク、またはそのようなリンクの任意の好適な組合せがある。ユーザデバイス４１０はさらに、コンテンツ送達サーバ４３０または任意の他の好適な源（たとえばハードドライブ、クラウドストレージ、フラッシュドライブなど）から閲覧者にビデオを提示するために使用され得る。ユーザデバイス４１０、サーバ４０２、４２０および４３０は任意の好適な位置に位置し得る。

図５は、開示される主題のいくつかの実現例に従った、サーバ４０２（またはサーバ４２０もしくは４３０）と図４に示されるユーザデバイス４１０のうちの１つとを実現するために使用され得るハードウェアの例５００を示す。図５を参照して、ユーザデバイス４１０は、相互接続され得る、ハードウェアプロセッサ５１２と、ディスプレイ５１４と、入力デバイス５１６と、メモリ５１８とを含み得る。いくつかの実現例では、メモリ５１８は、ハードウェアプロセッサ５１２を制御するためのコンピュータプログラムを格納するための（一時的でないコンピュータ読取可能媒体のような）ストレージデバイスを含み得る。

ハードウェアプロセッサ５１２は、コンテンツおよび／またはインターフェイスをディスプレイ５１４上で提示するためにコンピュータプログラムを使用し得、当該インターフェイスは、たとえばユーザが、サーバ４３０からビデオを抽出させることと、メディア再生アプリケーションとインタラクションすることと、繰り返されるライセンス更新がＤＲＭライセンスサーバ４０２またはライセンス更新サーバ４２０のようなデバイスによって実行される状態でリソース管理のための本願明細書において記載されるメカニズムとインタラクションすることと、通信リンク４０８を通じてデータを送受信することとを可能にする。また、通信リンク４０８または任意の他の通信リンクを通じて受信されるデータは任意の好適な源から受信され得る。いくつかの実現例では、ハードウェアプロセッサ５１２は、たとえばトランスミッタ、レシーバ、トランスミッタ／レシーバ、トランシーバ、
または、任意の他の好適な通信デバイスを使用して、通信リンク４０８または任意の他の通信リンクを介してデータを送受信し得る。ディスプレイ５１４は、フラットパネルディスプレイ、陰極線管ディスプレイ、プロジェクタ、タッチスクリーン、スピーカ、ならびに／または、任意の他の好適なディスプレイおよび／もしくは提示デバイスであり得る。入力デバイス５１６は、コンピュータキーボード、コンピュータマウス、マイクロフォン、タッチパッド、音声認識回路、タッチスクリーンおよび／または任意の他の好適な入力デバイスであり得る。

サーバ４０２（またはサーバ４２０もしくは４３０）は、相互接続され得る、ハードウェアプロセッサ５２２、ディスプレイ５２４、入力デバイス５２６およびメモリ５２８を含み得る。いくつかの実現例では、メモリ２２８は、通信リンク１０４または他のリンクを通じて受信されるデータを格納するためのストレージデバイスを含み得る。ストレージデバイスはさらに、ハードウェアプロセッサ２２２を制御するためのサーバプログラムを含み得る。

ハードウェアプロセッサ５２２は、ユーザデバイス４１２と通信するためにサーバプログラムを使用し得る。また、通信リンク４０４または任意の他の通信リンクを通じて受信されるデータは、任意の好適な源から受信され得る。いくつかの実現例では、ハードウェアプロセッサ５２２は、たとえばトランスミッタ、レシーバ、トランスミッタ／レシーバ、トランシーバ、または、任意の他の好適な通信デバイスを使用して、通信リンク４０４または任意の他の通信リンクを介してデータを送受信し得る。いくつかの実現例では、ハードウェアプロセッサ５２２は、１人以上のユーザによって送信されるコマンドおよび／または値を受信し得る。ディスプレイ５２４は、フラットパネルディスプレイ、陰極線管ディスプレイ、プロジェクタ、タッチスクリーン、スピーカ、ならびに／または、任意の他の好適なディスプレイおよび／もしくは提示デバイスであり得る。入力デバイス５２６は、コンピュータキーボード、コンピュータマウス、マイクロフォン、タッチパッド、音声認識回路、タッチスクリーンおよび／または任意の他の好適な入力デバイスであり得る。

１つの特定の実現例では、本願明細書において記載されるメカニズムは、サーバサイドのソフトウェア、サーバサイドのハードウェア、クライアントサイドのソフトウェア、クライアントサイドのハードウェア、または、それらの任意の好適な組み合わせを含み得る。たとえば、メディア再生アプリケーションは、編集アプリケーションを実行するサーバ４０２によって認識可能であるプログラミング言語で記述されたコンピュータプログラム（たとえばＪａｖａ（登録商標）、Ｃ、Ｏｂｊｅｃｔｉｖｅ−Ｃ、Ｃ＋＋、Ｃ＃、ＪａｖａＳｃｒｉｐｔ、ＶｉｓｕａｌＢａｓｉｃ、または任意の他の好適なアプローチといったプログラミング言語で書かれたプログラム）を包含し得る。別の例として、メディア再生アプリケーションは、（たとえば、ハイパーテキストマークアップ言語（「ＨＴＭＬ（Hyper Text Markup Language）」）、ダイナミックハイパーテキストマークアップ言語（「ＤＨＴＭＬ（Dynamic Hyper Text Markup Language）」）、エクステンシブルマークアップ言語（「ＸＭＬ（Extensible Markup Language）」）、JavaServer Pages（「ＪＳＰ」）、Active Server Pages（「ＡＳＰ」）、ColdFusion、または任意の他の好適なアプロ
ーチといった任意の好適なエンコーディングを介して）１つ以上のウェブページまたはウェブページ部分を包含し得る。

したがって、繰り返されるライセンス更新によるメディアセッション同時性管理のためのシステム、方法および媒体が提供される。

いくつかの実現例では、任意の好適なコンピュータ読取可能媒体が、本願明細書において記載される機能および／またはプロセスを実行するための命令を格納するために使用さ
れ得る。たとえば、いくつかの実現例では、コンピュータ読取可能媒体は一時的であることが可能であり、または、一時的でないことも可能である。たとえば、一時的でないコンピュータ読取可能媒体は、（ハードディスク、フロッピー（登録商標）ディスクなどのような）磁気媒体、（コンパクトディスク、デジタルビデオディスク、ブルーレイディスクなどのような）光学媒体、（フラッシュメモリ、電気的プログラマブル読取専用メモリ（ＥＰＲＯＭ（electrically programmable read only memory））、電気的消去可能プログラマブル読取専用メモリ（ＥＥＰＲＯＭ（electrically erasable programmable read only memory））などのような）半導体媒体、一時的ではないかもしくは伝送の間に永続性
の様相が欠けることがない任意の好適な媒体、および／または、任意の好適な有形の媒体といった媒体を含み得る。別の例として、一時的なコンピュータ読取可能媒体は、ワイヤー、導体、光ファイバ、回路におけるネットワーク上の信号、一時的であるかもしくは伝送の間に永続性の様相が欠ける任意の好適な媒体、および／または、任意の好適な無形の媒体を含み得る。

プロセスの上記のステップは、図に示され記載される順序およびシーケンスに限定されない任意の順序またはシーケンスで実行され得るということが理解されるべきである。さらに、プロセスの上記のステップのうちのいくつかは、適切な場合、実質的に同時に実行され得るか、または、レイテンシおよび処理時間を低減するために並列で実行され得る。

また、本願明細書において使用されるように、メカニズムという用語は、ハードウェア、ソフトウェア、ファームウェアまたは任意の好適な組み合わせを包含し得る。

本発明は上記の例示的な実現例において記載され示されたが、本開示は例示としてのみなされたものであり、添付の請求の範囲によってのみ限定される本発明の実現例の詳細における多数の変更は、本発明の精神および範囲から逸脱することがなければ行なうことができるということが理解される。開示される実現例の特徴は、さまざまな態様において組み合わせおよび再構成され得る。

Claims (11)

1. 同時性検出および実施のためのシステムであって、
   メモリと、
   ハードウェアプロセッサを含む少なくとも１つのサーバとを含み、前記ハードウェアプロセッサが前記メモリに格納されるコンピュータ実行可能命令を実行すると、前記少なくとも１つのサーバは、
   メディア再生デバイス上で提示されるべきメディアコンテンツアイテムに関係するメディアコンテンツライセンスについての要求に応答して、前記メディアコンテンツアイテムに関連付けられる１つ以上のキーと、制限されたライセンス期間および更新要求間隔を含むポリシーを含むライセンスとを前記メディア再生デバイスに送信することと、
   前記メディア再生デバイス上で提示される前記メディアコンテンツアイテムに関係するライセンス更新についての要求を、前記更新要求間隔内のある時間において、受信することと、
   ユーザアカウントに関連付けられる複数のメディア再生デバイスにわたるメディアセッション同時性に基づき、前記メディアコンテンツアイテムについて前記ライセンス更新を発行するべきかどうか決定することと、
   前記メディア再生デバイスに前記ライセンス更新を送信することとを行うように構成される、システム。
2. 前記メディアコンテンツライセンスについての前記要求は前記ユーザアカウントに関連付けられている、請求項１に記載のシステム。
3. 前記ライセンスにおける前記１つ以上のキーが無効化されると決定することに応答して、前記ライセンス更新に関連付けられる前記制限されたライセンス期間は０の期間を有する、請求項１または請求項２に記載のシステム。
4. 前記少なくとも１つのサーバはさらに、前記ライセンス更新についての前記要求を処理するための複数のライセンスサーバのリストを、前記メディア再生デバイス上で実行されるメディア再生アプリケーションに送信するように構成され、前記メディア再生アプリケーションは、前記複数のライセンスサーバのうちの第１のライセンスサーバに前記ライセンス更新についての前記要求を送信し、かつ、前記第１のライセンスサーバが利用不可能であることを検出する際および前記ライセンスの終了に先立って、前記メディアコンテンツライセンスについての前記ライセンス更新が受信されるまで、前記複数のライセンスサーバのうちの第２のライセンスサーバに前記要求を送信する、請求項１〜請求項３のいずれか１項に記載のシステム。
5. 前記少なくとも１つのサーバはさらに、
   前記ユーザアカウントについて所与の期間に発行されるライセンス更新のレコードのクエリ送信に応答して、ライセンス更新の前記レコードがアクセス不能であると決定することと、
   ライセンス更新の前記レコードがアクセス不能であることを決定することに応答して自動的に前記ライセンス更新を発行する緊急更新モードに入ることとを行うように構成される、請求項１または請求項２に記載のシステム。
6. ハードウェアプロセッサを含む少なくとも１つのサーバを用いて実行される、同時性検出および実施のための方法であって、
   メディア再生デバイス上で提示されるべきメディアコンテンツアイテムに関係するメディアコンテンツライセンスについての要求に応答して、前記メディアコンテンツアイテムに関連付けられる１つ以上のキーと、制限されたライセンス期間および更新要求間隔を含むポリシーを含むライセンスとを前記メディア再生デバイスに送信することと、
   前記メディア再生デバイス上で提示される前記メディアコンテンツアイテムに関係するライセンス更新についての要求を、前記更新要求間隔内のある時間において、受信することと、
   ユーザアカウントに関連付けられる複数のメディア再生デバイスにわたるメディアセッション同時性に基づき、前記メディアコンテンツアイテムについて前記ライセンス更新を発行するべきかどうか決定することと、
   前記メディア再生デバイスに前記ライセンス更新を送信することとを含む、方法。
7. 前記メディアコンテンツライセンスについての前記要求は前記ユーザアカウントに関連付けられている、請求項６に記載の方法。
8. 前記ライセンスにおける前記１つ以上のキーが無効化されると決定することに応答して、前記ライセンス更新に関連付けられる前記制限されたライセンス期間は０の期間を有する、請求項６または請求項７に記載の方法。
9. 前記ライセンス更新についての前記要求を処理するための複数のライセンスサーバのリストを、前記メディア再生デバイス上で実行されるメディア再生アプリケーションに送信することをさらに含み、前記メディア再生アプリケーションは、前記複数のライセンスサーバのうちの第１のライセンスサーバに前記ライセンス更新についての前記要求を送信し、かつ、前記第１のライセンスサーバが利用不可能であることを検出する際および前記ライセンスの終了に先立って、前記メディアコンテンツライセンスについての前記ライセンス更新が受信されるまで、前記複数のライセンスサーバのうちの第２のライセンスサーバに前記要求を送信する、請求項６〜請求項８のいずれか１項に記載の方法。
10. 前記ユーザアカウントについて所与の期間に発行されるライセンス更新のレコードのクエリ送信に応答して、ライセンス更新の前記レコードがアクセス不能であると決定することと、
    ライセンス更新の前記レコードがアクセス不能であることを決定することに応答して自動的に前記ライセンス更新を発行する緊急更新モードに入ることとを含む、請求項６または請求項７に記載の方法。
11. 請求項６〜請求項１０のいずれか１項に記載された方法をコンピュータに実行させるための、コンピュータプログラム。

Images