ストリーミング・メディアを含む、デジタルコンテンツへのアクセスを制御するためのシステム及び方法
ストリーミング・メディアを含むデジタルコンテンツへのアクセスを制御するためのシステム及び方法。システムは、ウェブサーバ、メディアサーバ、及びネットワークに結合されたパーソナルコンピュータなどのエンドユーザプロセッサを含む。ウェブサーバは、エンドユーザのファイルへのアクセスのリクエストに応答して暗号化されたチケットを生成する。チケットは、少なくとも部分的には、チケットが生成された時間又はその近くの時間に基づいている。メディアサーバは、好ましくは、ウェブサーバと同じ暗号化アルゴリズムを使用して許可チケットを生成する。メディアサーバの許可チケットは、少なくとも部分的に、メディアサーバがファイルへのアクセスに対するリクエストを受信した時間又はその近くの時間に基づく。メディアサーバは、ウェブサーバによって生成されたチケットをメディアサーバによって生成されたチケットと比較することによって、ファイルに対するアクセスを認可するかどうかを判断する。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願に対するクロスリファレンス）
本出願は、２００１年６月６日に出願された表題が「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＣＯＮＴＲＯＬＬＩＮＧ ＡＣＣＥＳＳ ＴＯ ＤＩＧＩＴＡＬ ＣＯＮＴＥＮＴ， ＩＮＣＬＵＤＩＮＧ ＳＴＲＥＡＭＩＮＧ ＭＥＤＩＡ」の国際特許出願第ＰＣＴ／ＵＳ０１／１８３２４号の一部継続出願である、２００１年１１月５日に出願された表題が「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＣＯＮＴＲＯＬＬＩＮＧ ＡＣＣＥＳＳ ＴＯ ＤＩＧＩＴＡＬ ＣＯＮＴＥＮＴ， ＩＮＣＬＵＤＩＮＧ ＳＴＲＥＡＭＩＮＧ ＭＥＤＩＡ」の国際特許出願第ＰＣＴ／ＵＳ０１／４６７２６号に基づいた、２００３年５月１２日に出願された表題が「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＣＯＮＴＲＯＬＬＩＮＧ ＡＣＣＥＳＳ ＴＯ ＤＩＧＩＴＡＬ ＣＯＮＴＥＮＴ， ＩＮＣＬＵＤＩＮＧ ＳＴＲＥＡＭＩＮＧ ＭＥＤＩＡ」の米国特許出願番号１０／４１６，６２３号の一部継続出願である、２００３年１０月２２日に出願された米国特許出願番号１０／６９２，４４４号の継続出願であり、これらの全ては引用により本明細書に組み込まれる。
【０００２】
本発明は、一般に、デジタルコンテンツへのアクセス制御に関し、より詳細にはストリーミング・メディアへのアクセスを制限するためのチケットベースのシステム及び方法に関する。
【背景技術】
【０００３】
インターネットとワールドワイドウェブの出現に伴い、ストリーミング・メディアコンテンツのようなデジタルコンテンツの配信に関連する産業が発達した。一例として、ストリーミング・メディアは、エンターテイメント、通信教育、及び企業目的を含む多くの目的のいずれかに使用することができる。エンターテイメント企業は、映画及びスポーツイベントをストリーミングし、通信教育企業は教育コンテンツをストリーミングし、企業はトレーニング教材をストリーミングする。
【０００４】
このようなストリーミング・メディアの多くの用途では、コンテンツへのアクセス制御が必要不可欠である。例えば、エンターテイメント企業は、ストリーミング・メディアのアイテムの各視聴に対してエンドユーザに課金することができ、これはエンターテイメント特有の用語で「ペイ・パー・ビュー」と呼ばれる。同様に通信教育企業は、オンライン教育コースへのアクセス、すなわちストリーミング・メディアへのアクセスに対して生徒に課金する。企業コンテンツは社外秘の場合が多いので、従ってこの場合もアクセス制御を必要とする。
【０００５】
従って、ストリーミング・メディアへのアクセスを制限するためのシステムが開発されている。ストリーミング・コンテンツへのアクセスを制限するための最新の業界標準は、ストリーミング・メディアコンテンツを提供する前にストリーミング・メディアサーバのエンドユーザ認証を含む。より詳細には、ストリーミング・メディアサーバは通常、ストリーミング・メディアへのアクセスを許可するかどうかを判断するためのロジックを含むコンパイル済みコードのソフトウエア・プラグインを含む。しかしながら、このような認証プラグインは、複雑であり、開発及び維持するのが困難である場合が多い。例えば、ストリーミング・メディアコンテンツへのアクセスを許可するためのロジックを変更する必要性が生じた場合、ストリーミング・メディアサーバ上のコンパイルされたプラグインを変更するのは困難である。更に、ストリーミング・メディアサーバ上にあるロジックの全ては、ストリーミング・メディアサーバが、データベース又は分散型のメッセージ受け渡しサービスに対し直接アクセスする必要がある。その上、ストリーミング・メディアコンテンツへのアクセスが許可されている特定のエンドユーザを確認する場合においてさえも、このようなエンドユーザは、無許可のエンドユーザとアクセスを共有することによって許可プロセスを免れ得ることが多い。このようなアクセスの共有は、コンテンツに対するリンクのユーザ名及びパスワードの共有も含む多くの形態を取ることができる。デジタルコンテンツの他の形態へのアクセスを制御するために使用されるシステムに関しても同様の問題が存在する。従って、デジタルコンテンツ、特にストリーミング・メディアコンテンツへのアクセスを制御し、エンドユーザを許可するためのシステム及び方法に対する改善の必要性が存在する。
【発明の開示】
【０００６】
本発明は、オーディオ、ビジュアル、ビデオ、テキスト、及びストリーミング・メディアなどのデジタルコンテンツへのアクセスを制御するためのシステム及び方法を提供することによって、前記並びに他の必要性を解決する。本発明による１つのシステム及び方法は、ストリーミング・メディアへのアクセスを制御し、ネットワークに接続されたウェブサーバ、メディアサーバ、及びパーソナルコンピュータなどのエンドユーザプロセッサを含む。
【０００７】
動作中、ウェブサーバは、ファイルにアクセスするためのエンドユーザのリクエストに応答して暗号化されたチケットを生成する。チケットは、少なくとも部分的には、チケットが生成された時間又はその近くの時間に基づいている。ある実施形態ではチケットは、例えばセキュリティタイムインターバル又はエンドユーザの識別子を含む追加情報に基づく。
【０００８】
メディアサーバがリクエストされたファイルへのアクセスを提供する前に、メディアサーバは、好ましくはウェブサーバと同じ暗号化アルゴリズムを使用して許可チケットを生成する。メディアサーバの許可チケットは、メディアサーバがファイルへのアクセスに対するリクエストを受信した時間又はその近くの時間に少なくとも部分的に基づく。メディアサーバは、ウェブサーバによって生成されたチケットをメディアサーバによって生成されたチケットと比較することによって、ファイルに対するアクセスを認可するかどうかを判断する。
【０００９】
１つの実施形態では、チケットが一致しない場合には、ウェブサーバがチケットを生成した時間とメディアサーバがチケットを生成した時間とが予め定められた量よりも大きく異なり、チケットは、論理的に「有効期限切れ」であると考えることができる。従ってメディアサーバは、メディアコンテンツへのアクセスを認可しない。チケットが一致する場合には、チケットは、許可されたタイムインターバルの範囲内に生成されており、メディアサーバは、エンドユーザがリクエストしたメディアコンテンツへアクセスするのを認可する。
【発明を実施するための最良の形態】
【００１０】
ここで、本発明の特定の好ましい実施形態を図面を参照しながら説明する。コンテンツへのアクセスを制御するための本発明は、ストリーミング・データファイルへのアクセス制御の関連で説明されているが、本発明はあらゆるタイプのメディア又はファイルに適用可能である点は理解されたい。更に、本明細書で検討される本実施形態は、オンデマンドのストリーミング・メディアに関するのであるが、ライブのストリーミング・メディアにも適用可能であることは、当業者であれば認識するであろう。
【００１１】
一般に、本実施形態のシステムは、エンドユーザプロセッサ１０２、ストリーミング・メディアサーバ１０４、及びコンテンツマネージメントデータベース１０８を有するウェブサーバ１０６を含み、これらの全てはインターネットに結合されている。エンドユーザプロセッサ１０２は、ＩＮＴＥＲＮＥＴ ＥＸＰＬＯＲＥＲの名称でＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって提供されるか、又はＮＥＴＳＣＡＰＥ ＮＡＶＩＧＡＴＯＲの名称でＡｍｅｒｉｃａ Ｏｎｌｉｎｅ Ｉｎｃ．のＮｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓによって提供されるようなインターネットブラウザ、及びＷＩＮＤＯＷＳ ＭＥＤＩＡ ＰＬＡＹＥＲ（ウィンドウズメディアプレーヤ）の名称でＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって提供されるか、又はＲＥＡＬＰＬＡＹＥＲ（リアルプレーヤ）の名称でＲｅａｌ Ｎｅｔｗｏｒｋｓ，Ｉｎｃにより提供されるようなストリーミング・メディアプレーヤを含む。
ウェブサーバ１０６は、エンドユーザ１０２によってアクセス可能なウェブサイトを提供する。ウェブサイトは、ストリーミング・メディアサーバ１０４上にあるストリーミング・メディアコンテンツにアクセスするためにエンドユーザ１０２が起動することができるリンクを含む。
【００１２】
本発明は、幾つかの何らかのコンピュータ技術を利用して実施できることは理解されたい。例えば、本実施形態は、インターネットを介してコンテンツへのアクセスを提供することに関するが、本発明は、例えばワイドエリアネットワークを含む、どのようなコンピュータネットワーク上でも利用することができる。同様に、エンドユーザプロセッサ１０２は、例えば携帯情報端末、ウェブ対応の携帯電話、ネットワークにダイヤルアップする有線電話、モバイルコンピュータ、パーソナルコンピュータ、インターネット機器及び同様のものを含む、ネットワークに結合可能なあらゆる装置とすることができる。更に、本明細書で説明されるサーバは、何らかのソフトウェアを実行するあらゆるタイプのものとすることができ、本明細書で説明されるソフトウェアモジュール、オブジェクト、及びプラグインは、どのようなプログラム言語で記述されていてもよい。最後に本明細書で説明されるデータベース及び記憶装置は、例えばローカルのコンピュータメモリ、ネットワーク接続記憶装置、及び磁気又は光学などのいずれかの既知の記憶媒体を含む、どのような記憶技術を使用してもよい。
【００１３】
ＣＭデータベース１０８の例示的な表現が図２に示される。図示されているように、データベース１０８は、ストリーミング・コンテンツの全てのアイテムにユニバーサルに適用可能な情報及び関連データの幾つかのテーブルを含む。ユニバーサル情報２０２は、セキュリティキー、セキュリティタイムインターバル、及びコンテンツが存在するストリーミング・メディアサーバ１０４の名称（「ホスト名」）を含む。セキュリティキー及びセキュリティインターバルは、エンドユーザ１０２がコンテンツにアクセスするのを許可する際に使用され、従って、好ましくは秘密に保持されてコンテンツの所有者によって設定される。セキュリティキー及びセキュリティインターバルは、全てのコンテンツへのアクセスを制御するのに使用されるが、別の実施形態では、各コンテンツファイルは、その固有のセキュリティキー及びこれに関連するセキュリティインターバルを有する。
【００１４】
ＣＭデータベース１０８は、コンテンツ又はストリーミング識別情報を含む一連のテーブルを更に含む。より詳細には、ストリーミングテーブル２０４は、一意のストリーミング識別子（ＩＤ）によって識別されたストリーミング・コンテンツの各アイテムのレコードを含む。更に各レコードは、例えば、コンテンツファイルの生成日付を含むコンテンツファイルを記述するストリーミングの詳細、ファイルの記述、コンテンツがオーディオか又はビデオかの識別、コンテンツが関係するプラットフォーム、コンテンツが最後に修正された日付、コンテンツの視聴に必要ないずれかのコーデック、コンテンツの長さ及びサイズ、コンテンツの有効期限（もしあれば）、．ａｓｆ又は．ｒｍなどのストリーミングのタイプ、コンテンツのタイトル、コンテンツの作者、コンテンツのステータス、コンテンツの著作権情報、コンテンツのビットレート、及び同様のものを含む。また各レコードは、メディアサーバ１０４へのリンクを生成するために使用されるプレフィックス（「ＵＲＬＰｒｅｆｉｘ（ＵＲＬプレフィックス）」）と、ストリーミング・メディアサーバ１０４上に格納されているコンテンツファイルの名前（「Ｆｉｌｅｎａｍｅ（ファイル名）」）を含む。ファイル名が、オンデマンドコンテンツのストリーミング・メディアサーバ１０４に結合された記憶装置上の実パスを指してもよく、或いは、ライブストリーミングの別名、ポート、又はチャネルを指してもよいことは理解されるべきである。
【００１５】
データベース１０８はまた、「プレイ（再生）リスト」情報を収容するテーブルを含む。クライアントのプレイリストは、一般に、グループとして利用可能にする目的で論理上関連付けられる１つ又はそれ以上のコンテンツファイルのグループである。プレイリストの一部として識別された各コンテンツファイルはまた、個々に利用可能にすることができる。このようなプレイリスト情報は、プレイリストテーブル２０８及びプレイリストストリーミングテーブル２１０内に収容される。一般に、プレイリストテーブル２０８は、プレイリストＩＤによって識別される各プレイリストを識別するレコードを含む。各レコードは更に、例えばプレイリストのフォーマット（ウインドウズメディアプレーヤ又はリアルプレーヤなど）、プレイリストの記述、プレイリスト名、及び同様のものを含むプレイリストの詳細、及びプレイリストの許可されたユーザグループＩＤを更に含む。
【００１６】
許可されたユーザグループＩＤは、特定のプレイリストを視聴するよう許可されたエンドユーザ１０２のグループに対応する。より詳細には、データベース１０８は更に、一意のエンドユーザＩＤによって識別される各エンドユーザ１０２を１つ又はそれ以上の許可されたユーザグループＩＤに関連付ける許可ユーザテーブル２０６を含む。エンドユーザ１０２がプレイリストを視聴するためには、エンドユーザ１０２は、当該コンテンツファイルに対する許可されたユーザグループＩＤの一部として識別される必要がある。特定の別の実施形態では、許可されたユーザグループＩＤは使用されず、別の代替の実施形態では、各コンテンツファイルがこれらに関連する許可グループＩＤを有する。
【００１７】
プレイリストストリーミングテーブル２１０は、プレイリストＩＤによって識別された各プレイリストをストリーミングＩＤによって識別された構成コンテンツファイルと関連付けるレコードを含む。各レコードはまた、プレイリスト中の各コンテンツファイルの順序（「ソート順序」）を示す情報を収容する。
【００１８】
本発明で使用される構成要素について説明してきたが、ここでストリーミング・メディアコンテンツへのアクセスを制御するプロセスを説明する。概説すると、ウェブサーバ１０６上に配置された認証ソフトウェア構成要素が、公開キー情報、秘密キー情報、及び現在時刻に基づいてハッシュ値又は「チケット」を生成する。公開キーは、エンドユーザとエンドユーザのユーザＩＤによってリクエストされたストリーミング・コンテンツに対する一意の識別子である。秘密キーは、コンテンツの所有者によって設定されたセキュリティキーとセキュリティタイムインターバルとを含む。
【００１９】
リクエストされたコンテンツが存在するストリーミング・メディアサーバ１０４は、公開キーを含むストリーミングのリクエストとウェブサーバ１０６によって生成されたチケットとを受け取る。ストリーミング・メディアサーバ１０４は、ローカルに格納された秘密キー情報を使用して固有形態のチケットの生成に進む。ストリーミング・メディアサーバ１０４は、ストリーミング・メディアサーバ１０４とウェブサーバ１０６によって生成されたチケットの比較に基づいて、リクエストされたストリーミング・コンテンツへのアクセスを拒否するか、又はアクセスを与える。
【００２０】
次に、図３のワークフロー図と図４及び５のフローチャートを参照しながらアクセスを制御するプロセスをより詳細に説明する。本実施例では、エンドユーザ１０２が、単一のストリーミング・メディアコンテンツファイルへのアクセスをリクエストする。最初に、ウェブサーバ１０６は、エンドユーザに許可アプリケーションにログインするようリクエストし、特定のストリーミング・メディアを視聴するオプションをエンドユーザに呈示するウェブページを提供する（ステップ３０２）。例えば、このようなページは、視聴のため各々が固有のストリーミングリクエストのリンクを有する幾つかのコンテンツファイルの１つを選択し、そのエンドユーザＩＤ（コンテンツの所有者が予め割り当ててエンドユーザに提供した）を提供し、更に、選択されたコンテンツへのアクセスに対してエンドユーザに課金することができるようにクレジットカード番号を提供するようエンドユーザにリクエストするフォームを含むことができる。別の実施形態では、エンドユーザは、エンドユーザの連絡先情報及び課金情報を提供することによってコンテンツの所有者に予め登録され、所有者は、割り当てられたエンドユーザＩＤと共にこれらをデータベース内にテーブル形式で格納する。
【００２１】
ウェブページに応答して、エンドユーザは、エンドユーザのユーザＩＤを提供してリンクを起動し、これにより認証アプリケーションにログインし、このリンクに関連する特定のストリーミング・コンテンツファイルへのアクセスをリクエストする（ステップ３０４）。ストリーミングＩＤが「１２３４５６」によって表現される例示的なストリーミングリクエストは、以下の通りである。
＜Ａ ｈｒｅｆ ｈｔｔｐ：／／ｗｅｂｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｇｅｔｓｔｒｅａｍ．ａｓｐ？ＩＤ＝１２３４５６＞
【００２２】
本実施形態では、認証アプリケーションは、ウェブサーバ１０６上に存在する「．ｄｌｌ」ソフトウェア要素である。しかしながら、例えばアクティブ・サーバページ（ＡＳＰ）又はサーブレットなどの他のあらゆるプログラム言語又は技術を使用して本明細書で説明された機能性を実施することができる点を当業者であれば認識するであろう。特定のプログラミング技術に関係なく、認証アプリケーションは、ウェブサーバ上のどのような処理ボトルネックをも軽減するために、ウェブサーバ１０６上で実行させることが好ましい。
【００２３】
エンドユーザが認証アプリケーションにログインし、ウェブサーバ１０６がエンドユーザからストリーミングリクエスト及びエンドユーザＩＤを受け取ると、ウェブサーバ１０６は、続いて許可チケットを動的に生成し、更に、選択されたコンテンツファイルへのリンクを動的に生成する。より詳細には、認証アプリケーションの制御下において、ウェブサーバ１０６は、許可チケットを生成する際に使用するための秘密キーを求めてデータベース１０８にリクエストを出す（ステップ３０６）。ウェブサーバ１０６は、リクエストされたコンテンツファイルに関連するセキュリティキー及びセキュリティインターバルを含む秘密キーをＣＭデータベース１０８から検索するためのデータベースクエリーを発行する。これに応答して、ＣＭデータベース１０８は、秘密キーをウェブサーバ１０６に返送する（ステップ３０８）。
【００２４】
データベース１０８から秘密キーの取得が完了すると、ウェブサーバ１０６はチケットを生成する（ステップ３１０）。図４に関連してより詳細に説明されるように、ウェブサーバ１０６は、秘密キー、ストリーミングＩＤ、エンドユーザＩＤ、現在時刻、及びハッシュアルゴリズムを使用してチケットを生成する。本実施形態では、リクエストされたコンテンツのストリーミングＩＤが、ステップ３０４でエンドユーザによって起動されたストリーミングリクエストリンクに含まれているので、ウェブサーバ１０６は、ストリーミングＩＤを使用してチケットを生成することができる。しかしながら、別の実施形態では、エンドユーザによって提供されるストリーミングリクエストは、ストリーミングＩＤ以外の、例えばコンテンツのタイトル、作者、及び／又はファイル名などの一意の識別情報を含む。このような実施形態では、ウェブサーバ１０６は、ストリーミングテーブル２０４をサーチして、ストリーミングリクエストに含まれる識別情報に基づいてストリーミングＩＤを検索する。更に別の実施形態では、ストリーミングリクエストは、システムがチケットを生成するために使用するファイル名又はパスなどの、ストリーミングＩＤ以外の一意の識別子を含む。
【００２５】
チケットが生成されると、ウェブサーバ１０６は、メディアサーバ上のリクエストされたコンテンツへのリンクを生成する。より詳細には、上記で示された例示的なストリーミングリクエストに基づいて、エンドユーザプロセッサ１０２に存在するメディアプレーヤが「ｗｅｂｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」（すなわちウェブサーバ１０６）を呼び出し、メディアサーバ１０４へのリンクを動的に生成するための「ｇｅｔｓｔｒｅａｍ．ａｓｐ」プログラムを実行することになる（ステップ３１２）。「ｇｅｔｓｔｒｅａｍ」アプリケーションは、アクティブ・サーバページ（すなわちＡＳＰ）拡張子を有するが、必ずしもＡＳＰ技術を使用するとは限らない点を当業者は認識するであろう。むしろ、「．ｄｌｌ」構成要素などの何らかのプログラム又はスクリプト言語若しくは技術を用いて、所望の機能性を提供することができる。しかしながら、認証アプリケーションの場合と同様に、エンドユーザプロセッサ１０２でのあらゆる処理ボトルネックを緩和するためにプログラムはウェブサーバ側で実行されるのが望ましい。「ｇｅｔｓｔｒｅａｍ．ａｓｐ」プログラムは、ウェブサーバ１０６にＣＭデータベース１０８を呼び出させ、メディアサーバ１０４へのリンクを動的に生成するのに必要なデータを検索させるよう機能する。より詳細にはウェブサーバ１０６は、ユニバーサル情報テーブル２０２からホスト名を検索し、ストリーミングテーブル２０４からＵＲＬプリフィックス及びファイル名を検索する。「ｇｅｔｓｔｒｅａｍ．ａｓｐ」プログラムはまた、リンクの最後にストリーミングＩＤ、チケット、及びエンドユーザＩＤを付加する。次いで、ウェブサーバ１０６は、エンドユーザプロセッサ１０２のメディアプレーヤへリンクを返す（ステップ３１４）。
【００２６】
メディアファイルへの例示的なリンクは以下の通りである。
＜ ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍｌ．ａｓｆ？ＩＤ＝１２３４５６＆ＴＩＣＫＥＴ＝ｕｖｗｌ２３ｘｙｚ＆ＵＳＥＲ＿ＩＤ＝ａｂｃｌ２３ｄｅｆ”＞
ここで、ＵＲＬプリフィックスは「ｍｍｓ：／／」によってリクエストされ、ホスト名は「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」で表され、ファイル名は「ｓｔｒｅａｍ１．ａｓｆ」で表され、コンテンツのリクエストアイテムのストリーミングＩＤは「１２３４５６」で表され、チケットは「ｕｖｗ１２３ｘｙｚ」で表され、エンドユーザＩＤは「ａｂｃ１２３ｄｅｆ」で表される。
【００２７】
リンクを受け取ると、エンドユーザプロセッサ１０２は、ストリーミング・メディアコンテンツをリクエストするステップに進む（ステップ３１６）。より詳細には、エンドユーザプロセッサ１０２に存在するメディアプレーヤは、リンクで識別された「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」（すなわちストリーミング・メディアサーバ１０４）を呼び出す。呼び出しの一部として、メディアプレーヤは、リクエストされたコンテンツのストリーミングＩＤのコピー、ウェブサーバ１０６によって生成されたチケット、及びエンドユーザＩＤをストリーミング・メディアサーバ１０４に供給する。
【００２８】
ストリーミングＩＤ、エンドユーザＩＤ、及びチケットを含むリンクを受け取ると、ストリーミング・メディアサーバ１０４は、エンドユーザがリクエストされたコンテンツへアクセスするのを認可するかどうかを判断するステップに進む（ステップ３１８）。図５を参照して以下に更に詳細に説明されるように、ストリーミング・メディアサーバ１０４は、ローカルに格納された秘密キー情報とリンク内に含まれるストリーミングＩＤ並びにエンドユーザＩＤに基づいて独自にチケットを生成することによってアクセスを認可するか否かを判断する。一般に、ストリーミング・メディアサーバ１０４によって生成されたチケットがウェブサーバ１０６によって生成されたチケットと一致する場合、ストリーミング・メディアサーバ１０４は、リクエストされたストリーミング・メディアコンテンツをエンドユーザプロセッサ１０２に供給する（ステップ３２０）。
【００２９】
用語「一致」は、異なる実施形態においては異なる意味を有することができることを理解されたい。一致とは、完全な一致又は予め定められた範囲内での一致を意味することができる。或いは、一致は、あるアルゴリズム又は方程式に基づいて標準偏差だけ互いに異なる２つの値を有することができる。
【００３０】
ここで図４を参照しながら、ウェブサーバ１０６によってチケットを生成するプロセスをより詳細に説明する。上述のようにチケット生成プロセスは、ウェブサーバ１０６に存在する許可ソフトウエア・プラグインによって行われるのが好ましい。本実施形態では、本プロセスは、ウェブサーバ１０６がストリーミングＩＤ及びエンドユーザＩＤを含むストリーミングリクエストを受け取るステップで始まる（ステップ４０２）。次にウェブサーバ１０６は、データベース１０８にアクセスし、リクエストされたストリーミングＩＤに関連する秘密キー情報を検索するステップに進む（ステップ４０６）。このような秘密キー情報は、ユニバーサルセキュリティキー及びセキュリティインターバルを含む。別の実施形態では各ストリーミングは、ストリーミングテーブル２０４にフィールドとして格納された固有のセキュリティキー及びセキュリティインターバルを有し、これをウェブサーバ１０６がストリーミングリクエストに含まれるストリーミングＩＤに基づいて検索する。
【００３１】
上述のようにウェブサーバ１０６はまた、現在時刻を使用してチケットを生成する。より詳細には、ウェブサーバ１０６は、現在時刻を算出し、その時刻をセキュリティインターバルの最も近い倍数にまで切り下げる（ステップ４１０）。本実施形態では、Ｃプログラミング言語の標準ライブラリ関数「ｔｉｍｅ（）」によって生成される協定世界時（ＵＴＣ）を秒単位で利用する。セキュリティインターバル（変数「＄ｔｉｍｅ」で表される）の最も近い倍数に切り下げられた時刻を生成するための例示的なパール（Ｐｅｒｌ）プログラミングコードを以下に示す。
＃
＃ ｅｘａｍｐｌｅ ｏｆ １５ ｍｉｎｕｔｅ ｔｉｃｋｅｔ ｅｘｐｉｒａｔｉｏｎ／ｓｅｃｕｒｉｔｙ ｉｎｔｅｒｖａｌ
＃
＄ｉｎｔｅｒｖａｌ＝１５＊６０
＄ｔｉｍｅ＝ｉｎｔ（ｔｉｍｅ（）／＄ｉｎｔｅｒｖａｌ）＊＄ｉｎｔｅｒｖａｌ；
ここで、変数「＄ｉｎｔｅｒｖａｌ」はセキュリティインターバルに対応し、１５分に等しい。
【００３２】
例証として、現在時刻が中央標準時で２０００年５月３１日午後２：１６：０７であると、関数「ｔｉｍｅ（）」は、およそ「９５９８００５６７」の値を返す。このＵＴＣ値を最も近い１５分インターバルに切り下げると、およそ「９５９８００５００」の値となり、これは、中央標準時で２０００年５月３１日午後２：１５：００の時刻を表す。
【００３３】
上記の例示的なコードは変更してもよく、それでも尚本発明の範囲内とすることができる点は理解されたい。例えば、セキュリティインターバルは分単位である必要はなく、インターバルが「ｔｉｍｅ（）」関数によって使用される時間の単位で表されるように適切な変換が行われる限り、該インターバルは他の時間単位で表してもよい。更に、別の実施形態では、現在時刻はＵＴＣ以外の標準ときに基づく。このような実施形態では、時間標準は、ウェブサーバ１０６及びストリーミング・メディアサーバ１０４に固有のものである。許可チケットを生成する際に使用するために、エンドユーザプロセッサ１０２に時間を計算させてその値をウェブサーバ１０６に渡すことは、本発明の範囲内にある点も理解されたい。更に別の実施形態では、セキュリティインターバルは、標準時間が所望の桁数にまで単に切り捨てられるように選択される。
【００３４】
ウェブサーバ１０６がハッシュアルゴリズムに対する入力値（公開キー情報、秘密キー情報、及び時間値）を有すると、ウェブサーバ１０６は、ハッシュアルゴリズムに対する入力ストリングを生成する（ステップ４１４）。本実施形態では、ハッシュアルゴリズムは「ＭＤ５」メッセージダイジェスト・アルゴリズムである。更に本実施形態では、メディアサーバ１０４及びウェブサーバ１０６は同じアルゴリズムを使用する。
【００３５】
チケットを生成するために基本的にいずれかのハッシュ又は暗号化アルゴリズムを利用することが本発明の範囲内であることは理解されるべきである。更に、チケットを生成する２つのサーバ（上記の実施形態ではウェブサーバ１０６とストリーミング・メディアサーバ１０４）は、同じ入力値に基づいて同じチケットを生成するか、或いは同じ入力値に基づいて互いに既知の偏差値の範囲にあるチケットを生成するのが好ましい。別の実施形態では、セキュリティを向上させるために利用可能な複数のアルゴリズムの１つが使用される。例証として、このような実施形態は、利用可能な複数のアルゴリズムからランダムに選択された１つのアルゴリズムを使用するか、或いは、リクエストされたコンテンツ、リクエストの日付又は時間、特定のエンドユーザ、コンテンツを所有するエンティティ、及び同様のものに基づいて複数のアルゴリズムのうちの１つを選択することができる。このような実施形態では、システムは、メディアサーバに対してウェブサーバによって使用されるアルゴリズムの指示を渡すか、又はメディアサーバが、ウェブサーバによって利用された同じアルゴリズムを選択及び使用させるロジックを含む。
【００３６】
使用される特定のハッシュアルゴリズムに対して入力ストリングが有効である限り、及びストリーミング・メディアサーバ１０４が入力ストリングの配置を認識している限り、入力値のどのような配置も入力ストリングとして使用することができる。本実施形態では、以下の予め定められた配置が使用される。
ＴＴＴＴＴＴＴＴＴＴＫＫＫＫＫＫＫＫＫＫＳＳＳＳＳＳＳＳＳＳＵＵＵＵＵＵＵＵＵＵ
ここで、「Ｔ」は時間値の桁を表し、「Ｋ」はセキュリティキーの英数字を表し、「Ｓ」はストリーミングＩＤ（あらゆる必要な先頭埋め込み文字を含む）の桁を表し、「Ｕ」はエンドユーザＩＤ（あらゆる必要な先頭埋め込み文字を含む）の英数字を表す。別の実施形態では、入力ストリングは異なる長さとすることができる。
【００３７】
ハッシュアルゴリズム入力ストリングが生成されると、ウェブサーバ１０６は、入力ストリングにハッシュアルゴリズムを適用し、これによりチケットを生成する（ステップ４１８）。
【００３８】
ここで図５を参照して、リクエストされたコンテンツストリーミングへのアクセスを認可するかどうかを判断するストリーミング・メディアサーバ１０４のプロセスを検討する。最初に、必ずしも必要ではないが、本実施形態のメディアサーバ１０４は、アクセスを認可するか否かを判断する際に使用するために、各々が異なる時間値に基づいた３つの許可チケットを生成する点に留意されたい。更に、ウェブサーバの機能性と同様、アクセスを認可するか否かを判断するプロセスが、メディアサーバ１０４上に存在する許可ソフトウェア要素において実行されることが望ましい。
【００３９】
アクセスを認可するかどうかを判断する際には、最初に、ストリーミング・メディアサーバ１０４が、エンドユーザプロセッサ１０２上に存在するメディアプレーヤから、ストリーミングＩＤ、エンドユーザＩＤ、及びチケットを含むストリーミングリクエストを受け取る（ステップ５０２）。ストリーミングリクエストが受け取られると、メディアサーバ１０４は、ハッシュアルゴリズムへの入力ストリングを生成する。この点でメディアサーバ１０４は、ローカルのメモリから秘密キー情報、すなわちセキュリティキーとセキュリティインターバルとを検索する（ステップ５０６）。好ましくは、メディアサーバ１０４は、秘密キー情報をローカルのメモリに格納するが、別の実施形態では、メディアサーバ１０４は、例えばＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎにより提供されるライトウェイト・ディレクトリ・アクセス・プロトコル（Ｌｉｇｈｔ−Ｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）によってアクセスされるアクティブディレクトリツリー又は遠隔のデータベースに情報を保存する。更に別の代替の実施形態では、メディアサーバ１０４は、ローカルエリアネットワーク（ＬＡＮ）などのネットワーク接続を介してデータベース１０８にアクセスすることによって秘密キー情報を検索する。
【００４０】
ウェブサーバ１０６が行ったように、メディアサーバ１０４もまた、現在時刻を計算し、その時間をセキュリティインターバルの最も近い倍数（すなわち以前の時間に）にまで切り下げる（ステップ５１０）。しかしながら、ウェブサーバ１０６とは異なり、ストリーミング・メディアサーバ１０４はまた、メディアサーバ１０４によって計算された第１の時間値よりも小さな（すなわち以前の時間の）セキュリティインターバルの次に最も近い倍数にまで切り下げされた現在時刻に等しい第２の時間値を計算する（ステップ５１０）。メディアサーバ１０４は更に、セキュリティインターバルの最も近い倍数にまで切り上げされた現在時刻（すなわちより遅い時間）に等しい第３の時間値を計算する（ステップ５１０）。
【００４１】
次いで、メディアサーバ１０４は、検索された秘密キー情報、受け取られた公開キー情報、及び３つの時間値を使用して、３つの対応するハッシュ入力ストリングを生成する（ステップ５１４）。次に、メディアサーバ１０４は、３つの入力ストリングの各々にハッシュアルゴリズムを適用し、これにより３つのチケットを生成する（ステップ５１８）。
【００４２】
独自のチケットを生成した後、次にメディアサーバ１０４は、メディアサーバ１０４によって生成されたチケットのいずれかがウェブサーバ１０６によって生成されたチケットと一致するかどうかを判断する（ステップ５２２）。チケットが一致しない場合、ストリーミングリクエストは認証されたものではなく、及び／又は有効期限が切れたものである（すなわち、ユーザのリクエスト時間から測定されるセキュリティインターバルを越えた時間にメディアサーバ１０４によって生成されたもの）可能性が高い。従って、メディアサーバ１０４は、リクエストされたコンテンツへのアクセスを拒否する（ステップ５２６）。
【００４３】
チケットが一致する場合、ストリーミングリクエストは認証されたものであり、セキュリティインターバルの範囲内にある可能性が高い。しかしながら、アクセスを認可する前に、メディアサーバ１０４は最初に、エンドユーザが同じコンテンツへのアクセスをリクエストして、既に視聴したかどうかを判断する（ステップ５３０）。メディアサーバ１０４は、エンドユーザＩＤのリストと該エンドユーザが既にアクセスを認可されている対応するストリーミングＩＤとをローカルメモリ内に保持するのが好ましい。リクエストされたコンテンツをエンドユーザが既に視聴したかどうかを判断するために、メディアサーバ１０４は、メモリにアクセスして、受け取ったエンドユーザＩＤ及びストリーミングＩＤが以前に格納されているかどうかを判断する。エンドユーザＩＤ及びストリーミングＩＤが既に格納されている場合には、エンドユーザは、リクエストされたコンテンツへのアクセスが拒否される（ステップ５３０）。
【００４４】
受け取ったエンドユーザＩＤ及びストリーミングＩＤが、これまで格納されていない場合には、メディアサーバ１０４は、エンドユーザＩＤ及びストリーミングＩＤをメモリに格納するステップに進み（ステップ５３４）、エンドユーザにコンテンツへのアクセスを与える（ステップ５３８）。従って、エンドユーザＩＤ及びストリーミングＩＤを格納することにより、リクエストされたコンテンツを指すリンクをエンドユーザが他者と共有するのを防ぐ任意の追加レベルのセキュリティ保護が得られる。
【００４５】
ウェブサーバ１０６のローカル時間とメディアサーバ１０４のローカル時間との間が同期されていないことを考慮に入れるために、３つのチケットを使用することが望ましい点は理解されるべきである。更に、ある状況では、メディアサーバ１０４によって生成された第１のチケット（すなわち、セキュリティインターバルの最も近い倍数にまで切り下げられた現在時刻に基づく）は、エンドユーザが許可されている場合でも、ウェブサーバ１０６によって生成された第１のチケットと一致しないことになる。例えば、セキュリティインターバルを１５分とすると、ウェブサーバ１０６が午後１２：１４：００にチケットを生成し、メディアサーバ１０４がその第１のチケットを午後１２：１６：００に生成する場合、同じ日の時間帯においてリクエストがセキュリティインターバルの範囲内にあってもチケットは一致しないことになる。ウェブサーバは、午後１２：００：００に対応する時間値に基づいてチケットを生成し、一方、メディアサーバ１０４は、午後１２：１５分：００に対応する時間値に基づいてチケットを生成することになる。従って、本実施形態では、メディアサーバ１０４は、セキュリティインターバルの次に最も近い倍数に切り下げられたそのときの現在時刻に基づいて第２のチケットを生成し、すなわち本実施例では、午後１２：００：００に対応する。従って、第２のチケットは、ウェブサーバ１０６によって生成されるチケットと一致するであろう。同様に、セキュリティインターバルが経過した後、エンドユーザに対しアクセスを認可することが可能である。従って、本実施形態では、セキュリティインターバルは複数のチケットの使用を考慮するように選択されるべきである。ウェブサーバ１０６とメディアサーバ１０４は、セキュリティインターバルの約半分以内に時刻同期するのが望ましい。
【００４６】
メディアサーバ１０４が、上記の実施形態で３つのチケットの代替として１つ又はそれ以上の異なるチケットを生成することもまた本発明の範囲内である点を理解すべきである。更に上記の実施形態では、チケットが共に並列に生成されるものとして説明しているが、メディアサーバ１０４がチケットを順に連続して生成及び／又は比較することも本発明の範囲内である。更に、時間値は、例えばメディアサーバ１０４によって計算された第１の時間値からセキュリティインターバルを単に加減算することを含め、多くの方法のいずれかで生成することができる点も理解されるべきである。
【００４７】
別の実施形態では、別のレベルのセキュリティを提供してもよい。より詳細には、ウェブサーバ１０６によって生成されたチケットが、メディアサーバ１０４によって生成されたチケットのうちの１つと一致する場合、メディアサーバ１０４は、同じチケットが既に生成されていたかどうかを判断するステップに進む。メディアサーバ１０４は、アクセスが許可されたチケットのリストを保持している。このようなリストは、論理上、全ての「使用済み」チケットを表す。一致したチケットが「使用済み」チケットのリストに存在しない場合には、メディアサーバ１０４は、アクセスを認可し、エンドユーザプロセッサ１０２上に存在するメディアプレーヤにリクエストされたコンテンツを供給する。アクセスを認可するステップの一部として、メディアサーバ１０４はまた、「使用済み」チケットのリスティングを更新する。一致したチケットが使用済みチケットのリストに存在する場合には、メディアサーバ１０４はアクセスを拒否し、リクエストしているエンドユーザに適切なメッセージを供給する。使用済みチケットを追跡することによって、システムは、許可されたエンドユーザがウェブサーバ１０６から受け取ったストリーミングリクエストを他者と共有するのを防止する。
【００４８】
更に、アクセスを認可するかどうかを判断する際にエラー計算を使用することも本発明の範囲内である点を理解されたい。例えば１つのエラー計算は、例えば、予め定められた時間期間（例えば１５分、３０分など）、適用可能なセキュリティインターバルの設定百分率（例えば５０％、１２５％など）、又は他のエラー計算などのエラーインターバルに現在時刻を加算及び／又は減算した値に基づいて、メディアサーバ１０４が１つ又はそれ以上の追加チケットを生成するステップを含む。このようなエラー計算は、上記の実施形態において第２又は第３の時間値に対する代替値として、或いはこれに加えて使用することができる。
【００４９】
別の実施形態では、ウェブサーバ１０６及びメディアサーバ１０４は、上記の実施形態とは異なる方法で時間値を計算することによってチケットを生成する。１つの例示的な実施形態では、ウェブサーバ１０６及びメディアサーバ１０４は、現在時刻を計算し、これをセキュリティインターバル以外の或るインターバルの倍数に切り下げ又は切り上げる。セキュリティインターバルが１５分であるこうした１つの実施形態では、ウェブサーバ１０６は、５分の最も近いインターバルに切り下げられた現在時刻に基づいてチケットを生成する。次に、ストリーミング・メディアサーバ１０４は、同じ５分のインターバルに切り下げられた現在時刻に基づいてチケットを生成する。チケットが一致しない場合、メディアサーバ１０４は、次に古いインターバルに切り下げされた時間に基づいてチケットを生成するステップに進む。メディアサーバは、設定された回数又はウェブサーバとメディアサーバのチケットが一致するまで、次に古いインターバルに基づいてチケットを生成し続ける。好適には、メディアサーバ１０４は、合計が少なくともセキュリティインターバルに及ぶタイムインターバルに基づいて繰り返し新しいチケットを生成する。本実施例ではメディアサーバ１０４は、各５分の合計１５分のインターバルで少なくとも３つのチケットを生成する。
【００５０】
許可プロセスにおいてエンドユーザＩＤの使用を完全に省略すること、或いはエンドユーザＩＤを上述の方法とは異なる方法で使用することは、本発明の範囲内にある点は理解すべきである。例えば、別の実施形態では、エンドユーザＩＤは、ハッシュアルゴリズムに対する入力ストリングの一部としては使用されない。その代わり、データベース１０８は、どのエンドユーザがコンテンツへのアクセスをリクエストしたかを追跡するテーブルを含む。このような実施形態は、ストリーミングＩＤによって識別されるコンテンツを、エンドユーザＩＤによって識別され、該コンテンツストリーミングに既にアクセス又は視聴したエンドユーザと関連付けるレコードを含む視聴ユーザ（ストリーミング）テーブルを含む。同様に本実施形態は、プレイリストＩＤによって識別されるプレイリストを、エンドユーザＩＤによって識別され、該プレイリストに既にアクセス又は視聴したエンドユーザと関連付けるレコードを含む視聴ユーザ（プレイリスト）テーブルを含む。許可チケットを生成する前に、ウェブサーバは、適切な視聴ユーザテーブルをチェックし、同じエンドユーザが特定のストリーミング又はプレイリストへのアクセスをリクエストしたかどうかを判断する。エンドユーザが既にアクセスをリクエストしていた場合、ウェブサーバは、アクセスを拒否するか、或いはエンドユーザに対して、これ以後のアクセスに対しては再度課金されることをエンドユーザに示すウェブページを供給する。テーブルは、セキュリティインターバルなどの時間期間又はこれを超える或る期間の後に自動的にクリアされる。
【００５１】
本発明はまた、例えば、コンテンツの所有者であるクライアントの代わりに、サービスプロバイダがウェブサーバ、ストリーミング・メディアサーバ、及びプレイリストサーバを操作する比較的より複雑なシステムにおいて具現化することができる点を理解すべきである。このような１つの実施形態を次に図６−８を参照しながら説明する。本実施形態の機能性の大部分が、図３の実施形態の機能性と同じであり、従って同じ技術のどれによっても実施することができる点は当業者には理解されるであろう。
【００５２】
図６に示されるように、本システムは、図１の実施形態の構成要素と類似の幾つかの構成要素を含み、エンドユーザプロセッサ６０２、１つ又はそれ以上のストリーミング・メディアサーバ６０４、及びデータベース６０８を含む１つ又はそれ以上のウェブサーバ６０６を含み、これらの全てはインターネット又は他のネットワークに結合される。加えて、本実施形態のシステムは、サービスプロバイダによって同様に動作されるプレイリストサーバ６１０も含む。好適には、ウェブサーバ６０６、データベース６０８を含むストリーミング・メディアサーバ６０４、プレイリストサーバ６１０は、ローカルエリアネットワーク（ＬＡＮ）又はワイドエリアネットワーク（ＷＡＮ）などのサービスプロバイダのネットワーク、並びにインターネットに接続される。
【００５３】
一般に、データベース６０８は、図２の実施形態のデータベース内に収容されている同じ情報を含むが、該情報はクライアントのアカウント毎に格納される。図７に示されるように、データベース６０８は、アカウントＩＤによって識別される各クライアントのレコードを含むアカウントテーブル７０２を含む。各レコードは更に、クライアント名、アドレス、請求書発行情報及び同様のものなどのクライアント識別情報（「クライアント情報」）、クライアントのコンテンツが保護されているかどうかに関する表示（「保護許可」）、クライアントのセキュリティキー（「セキュリティキー）、及びセキュリティインターバル（「セキュリティインターバル」）を含む。
【００５４】
図２の実施形態と同様に本データベース６０８はまた、ストリーミングＩＤによって識別される各コンテンツファイルのストリーミング識別情報を含むストリーミングテーブル７０４と、エンドユーザＩＤを許可されたグループＩＤに関連付ける許可ユーザテーブル７０６と、プレイリストＩＤによって識別される各プレイリスト用のプレイリスト識別情報を含むプレイリストテーブル７０８と、所定のプレイリストＩＤに関連付けられたストリーミングＩＤを識別するプレイリストストリーミングテーブル７１０とを含む。図２のデータベースに関連して説明された情報フィールドに加えて、本ストリーミングテーブル７０４及びプレイリストストリーミングテーブル７０８は更に、各コンテンツファイル及び各プレイリストとそれぞれ関連付けられたアカウントＩＤを識別するフィールドを含む。
【００５５】
本データベース６０８はまた、ストリーミングサーバテーブル７１２を含み、該テーブルは、ストリーミングＩＤによって指定される各コンテンツファイルのレコードを含み、コンテンツファイルが存在する特定のストリーミング・メディアサーバ１０４のホスト名を識別する。図２の実施形態と同様、ホスト名はメディアサーバ１０４のＤＮＳ名である。
【００５６】
ここで、本実施形態の動作を図８のワークフロー図に関連して説明する。本実施例の目的のために、エンドユーザは、保護コンテンツの１つのアイテムを有するプレイリストへのアクセスをリクエストする。最初に、ウェブサーバ６０６は、エンドユーザに対し許可アプリケーションにログインすることをリクエスし、特定のストリーミング・メディアを視聴するオプションをエンドユーザに呈示するウェブページを提供する（ステップ８０２）。図３の実施形態と同様に、例示的なウェブページは、リンクを起動することによって特定のコンテンツファイルを選択し、エンドユーザＩＤを提供し、及び請求書発行情報を提供することをエンドユーザにリクエストするフォームを含むことができる。ウェブページに応答して、エンドユーザは、エンドユーザＩＤ及びクレジットカード情報を提供し、ストリーミングリクエストリンクを起動し、これにより特定のストリーミング・メディアコンテンツファイルへのアクセスをリクエストする。プレイリストＩＤが「７８９０００」の場合の例示的なストリーミングリクエストリンクは以下の通りである。
＜Ａ ｈｒｅｆ”ｈｔｔｐ：／／ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｍａｌｃｅｐｌａｙｌｉｓｔ．ｄｌｌ？ＩＤ＝７８９０００”＞
【００５７】
エンドユーザが、ストリーミングリクエストリンクを起動すると、エンドユーザプロセッサ６０２上で実行されるプログラミングスクリプトによって、ストリーミングリクエストリンク及びエンドユーザＩＤがウェブサーバ６０６に送られることになる（ステップ８０４）。当業者は、本質的に、例えばＣ＋＋、パール（Ｐｅｒｌ）、ビジュアルベーシック、ジャバ（Ｊａｖａ）及び同様のものを含むどのようなプログラム言語でもエンドユーザのスクリプトを実行することができる点を認識するであろう。本実施形態では、スクリプトはＪａｖａスクリプトであり、エンドユーザのウェブブラウザと連動して実行される。
【００５８】
ウェブサーバ６０６がスクリプトからストリーミングリクエストを受け取ると、ウェブサーバ６０６は、許可ソフトウエア・プラグインの指示の下でチケットを生成する。この件に関して、ウェブサーバ６０６は、データベース６０８に対して許可チケットの生成の際に使用する秘密キー（本実施形態では、リクエストされたプレイリストに関連するセキュリティキーとセキュリティインターバル）のリクエストを発行する（ステップ８０８）。これに応答して、データベース６０８はウェブサーバ６０６に秘密キーを返す（ステップ８０８）。
【００５９】
データベース６０８から秘密キーを取得した後、ウェブサーバ６０６は、ストリーミングされたものではなくプレイリストＩＤ（本実施形態ではプレイリストＩＤで置き換える）を使用して、図４に関連して前述されたようにチケットを生成する（ステップ８１０）。上述のように、ウェブサーバ６０６は、秘密キー、ストリーミングＩＤ、エンドユーザＩＤ、及び時間値をハッシュアルゴリズムに適用してチケットを生成する。次いで、ウェブサーバ６０６は、エンドユーザプロセッサ６０２上で実行されるウェブブラウザにチケットとエンドユーザＩＤを返す（ステップ８１２）。
【００６０】
チケットを受け取った後、エンドユーザプロセッサ６０２上で実行されるスクリプトは、ストリーミングリクエストリンクの最後に情報を付加する（ステップ８１４）。例示的なリンクは以下に示される。
＜Ａ ｈｒｅｆ”ｈｔｔｐ：／／ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ． ｃｏｍ／ｍａｋｅｐｌａｙｌｉｓｔ？ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｕｖｗ１２３ｘｙｚｒｅｔｕｍ＆ＵＳＥＲ＿ＩＤ＝ａｂｃｌ２３ｄｅｆ”＞
ここで、プレイリストＩＤは「７８９０００」で表され、チケットは「ｕｖｗ１２３ｘｙｚ」で表され、エンドユーザＩＤは「ａｂｃ１２３ｄｅｆ」で表される。
【００６１】
次いで、エンドユーザプロセッサ６０２上で実行されるスクリプトにより、ホスト名「ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」によってストリーミングリクエストリンクで識別されるプレイリストサーバ６１０が呼び出される（ステップ８１６）。従って、プレイリストサーバ８１０は、リンク、プレイリストＩＤ、チケット、及びユーザＩＤが提供される。「ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ」オブジェクトの制御下で、プレイリストサーバ６１０は、コンテンツがウインドウズメディア・フォーマットであるＡＳＸファイルなどのリダイレクタファイルを生成する（ステップ８１８）。「ｍａｋｅｐｌａｙｌｉｓｔ」プログラムは、例えばＡＳＰを含む幾つかのプログラム又は技術のいずれかを使用して実行することができる。リダイレクタファイルは、チケット及び公開キー（すなわちストリーミングＩＤ及びエンドユーザＩＤ）と共にリクエストされたコンテンツへのリンクを含む。リダイレクタファイルを生成するために、プレイリストサーバ６１０はデータベース６０８にアクセスし、プレイリストと、ストリーミングＩＤに関連付けられたホスト名、ＵＲＬプレフィックス、及びファイル名を含むコンテンツファイルへのリンクに必要とされる情報とを含むコンテンツファイルのストリーミングＩＤを検索する。
【００６２】
別の実施形態では、ストリーミングリクエストにチケットを付加するためにエンドユーザのスクリプトは使用されない。その代わりに、エンドユーザが、エンドユーザＩＤを提供してストリーミングリクエストリンクを起動する（ステップ８０４で）ときに、ウェブサーバ６０６上で実行される認証アプリケーションがチケットを生成し、該チケットとエンドユーザＩＤとをストリーミングリクエストリンクに付加し、プレイリストサーバ６１０を直接呼び出してリダイレクタファイルを生成する。ウェブサーバ６０６はまた、エンドユーザプロセッサ６０２上のメディアプレーヤを識別する情報をプレイリストサーバ６１０に渡すので、プレイリストサーバ６１０は、メディアプレーヤにリダイレクタファイルを転送する（これによりステップ８１２、８１４、及び８１６が不要になる）。このような実施形態を図１０を参照して以下に説明する。
【００６３】
次に、プレイリストサーバ６１０は、エンドユーザプロセッサ６０２でメディアプレーヤにＡＳＸリダイレクタファイルを渡す（ステップ８２０）。本実施例の目的のために、ＡＳＸファイルは以下のように表される。
＜ＡＳＸ＞
＜ＥＮＴＲＹ＞
＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍｌ．ａｓｆ？ＩＤ＝１２３４５６＆ＴＩＣＫＥＴ＝ｕｖｗｌ２３ｘｙｚ＆ＵＳＥＲ＿ＩＤ＝ａｂｃｌ２３ｄｅｆ”＞
＜／ＥＮＴＲＹ＞
＜／ＡＳＸ＞
ここで、ＵＲＬプレフィックスが「ｍｍｓ：／／」で表され、適切なメディアサーバ６０４のホスト名が「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」で表され、ファイル名が「ｓｔｒｅａｍ１．ａｓｆ」で表され、コンテンツストリーミングＩＤのリクエストされたアイテムが「１２３４５６」で表され、チケットが「ｕｖｗ１２３ｘｙｚ」で表され、エンドユーザＩＤが「ａｂｃ１２３ｄｅｆ」で表される。
【００６４】
リダイレクタファイルは、コンテンツファイル用のメタデータなどの他の情報、或いは広告などの保護されていない他のファイルを含むことができる。
【００６５】
ＡＳＸファイルを受け取った後、エンドユーザプロセッサ６０２は、ストリーミング・メディアコンテンツをリクエストするステップに進む。より詳細にはメディアプレーヤは、ＡＳＸファイルで識別された「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」（すなわちストリーミング・メディアサーバ６０４）を呼び出す（ステップ８２２）。呼び出しされると、メディアプレーヤは、リクエストされたコンテンツのストリーミングＩＤのコピー、ウェブサーバ６０４によって生成されたチケット、及びエンドユーザＩＤをストリーミング・メディアサーバ６０４に提供する。
【００６６】
メディアプレーヤの呼び出しに応答して、ストリーミング・メディアサーバ６０４は、リクエストされたコンテンツへのエンドユーザのアクセスを認可するかどうかを判断するステップに進む（ステップ８２４）。ストリーミング・メディアサーバ６０４は、１つ又はそれ以上の認証チケットを独自に生成し、そのチケットをウェブサーバ６０６によって生成されたチケットと比較することによってアクセスを認可するかどうかを判断をする。許可チケットの生成及び比較プロセスは、ストリーミングＩＤではなくプレイリストＩＤを使用して、図５に関連して説明された同じ方法で行われる。メディアサーバ６０４によって生成されたチケットが、ウェブサーバ６０６によって生成されたチケットと一致する場合には、メディアサーバ６０４は、エンドユーザにリクエストされたコンテンツへのアクセスを認可する（ステップ８２４）。
【００６７】
上記の実施形態は、保護されたコンテンツへの無許可のアクセスに対して該コンテンツの所有者に十分なレベルの保護をもたらすことが理解されると同ときに、更に高いレベルの保護を実装することも可能である。１つのこのような更に高いレベルの保護は、特定のエンドユーザが所与の任意の時間にアクセスできるコンテンツファイル数を制限することを含む。別のレベルの保護は、特定のユーザが保護されたコンテンツにアクセスするのに使用できる異なるプロセッサ（例えばコンピュータ）の数を制限する。上述の実施形態のいずれもこのような更に高いレベルの保護を含むように修正することができ、ここで図９と１０に関連して更に高い保護の実施を説明する。
【００６８】
図９の概略図で分かるように、本実施形態は、図６−８に示され関連して説明された実施形態に基づく。上述のように、一般にコンテンツ配信及び認証システムは、ウェブサーバ６０６、データベース６０８、及びプレイリストサーバ６１０を含む。更に、必ずしも必要ではないが、本システムは、複数のストリーミング・メディアサーバ６０４−１、６０４−２、６０４−ｎ（総称して６０４と称する）を含み、その各々がサーバＩＤによって識別され、保護されたコンテンツを収容している。好適には、ストリーミング・メディアサーバ６０４は各々、同じストリーミング・コンテンツのコピーを収容し、システムは、ラウンドロビン又は他の負荷バランス手法を使用することにより複数のストリーミング・メディアサーバ上の負荷バランスを取る。データベース６０８は、格納されるサーバＩＤと各コンテンツファイルを関連付ける。以下の説明に基づいて理解されるように、本実施形態は、異なるメディアサーバ上の同じコンテンツファイルへのアクセスが許可された別のユーザからアクセス情報を受け取ることによって、無許可のエンドユーザが特定のメディアサーバ上のコンテンツファイルにアクセスすることを防止するので、複数のストリーミング・メディアサーバと共に使用するのに特に好適である。図９に示されるように、上述の構成要素は、保護されたネットワークを介して互いに通信するのが好ましいが、しかしながら、別の実施形態では、グローバルキャッシュ・サーバ９０２は、ストリーミング・メディアサーバ６０４とだけ直接接続され、ビジネスサーバ９０４は、グローバルキャッシュ・サーバ９０２とだけ直接接続されている。上述の実施形態と同様、エンドユーザは、インターネット又は他のネットワークに結合されたエンドユーザプロセッサ６０２−１、６０２−２、６０２−ｍ（総称して６０２と称する）を介して保護されたコンテンツにアクセスする。
【００６９】
一般に、グローバルキャッシュ・サーバ９０２は、ストリーミング・メディアサーバ６０４に対する各エンドユーザの接続に関する接続情報をキャッシュし、エンドユーザＩＤに基づいて高いレベルの認証保護を提供する。接続情報は、キャッシュ又はデータベースなどのローカルのデータ記憶装置、又はデータベース６０８などの遠隔の記憶装置に格納される。以下でより詳細に説明されるように、各ストリーミング・メディアサーバ６０４は、当該ストリーミング・メディアサーバ６０４を許可した各エンドユーザのアクセスに対してグローバルキャッシュ・サーバ９０２に接続情報を転送する。本実施形態では、接続情報は、エンドユーザＩＤ、各エンドユーザのメディアプレーヤのグローバル固有ＩＤ（ＧＵＩＤ）、エンドユーザがアクセスを許可されたストリーミング・コンテンツのフォーマット（例えばウインドウズメディアプレーヤ又はリアルプレーヤフォーマット）、エンドユーザによってアクセスされるコンテンツが存在するサーバのＩＤ、及びエンドユーザがリクエストされコンテンツにアクセスしている特定のエンドユーザプロセッサ６０２の識別子（「ｐｐｖスロット」と称される）を含む。周知のように、メディアプレーヤのプロバイダは、一般に各メディアプレーヤにＧＵＩＤを割り当ててメディアプレーヤを識別する。
【００７０】
各エンドユーザは、該エンドユーザがコンテンツにアクセスすることができる幾つかのエンドユーザプロセッサ６０２を論理的に割り当てられる。本実施例では各エンドユーザは、最大３つの異なるエンドユーザプロセッサ６０２からコンテンツにアクセスすることができる。３つの異なるプロセッサは、例えば、エンドユーザの家庭用コンピュータ、業務用コンピュータ、及びモバイルコンピュータ、ウェブ対応の携帯電話、若しくはウェブ対応の携帯情報端末（ＰＤＡ）のいずれかとすることができる。更に、３つのプロセッサ６０２の各々に対し、エンドユーザは、システムによってサポートされている各メディアフォーマット毎に複数のメディアプレーヤを有することができる。本実施形態では、ウインドウズメディアプレーヤ又はリアルプレーヤフォーマットがサポートされる。従って、本実施形態では、各エンドユーザは、３つまでの異なるｐｐｖスロット値だけを有することができ、各ｐｐｖスロット値に対して、エンドユーザは、各タイプのフォーマットのメディアプレーヤ毎に２つのＧＵＩＤを有することができる。
【００７１】
本実施形態では、特定のエンドユーザプロセッサ６０２のｐｐｖスロット値は、当該プロセッサのクッキーＩＤである。一般に、クッキーは、エンドユーザが特定のエンドユーザプロセッサ６０２を介してシステムウェブサイトを最初に訪れたときに、ウェブサーバ６０６がエンドユーザのブラウザに対して付与するデータのセットである。ウェブサーバ６０６は、クッキーが含むエンドユーザに関する情報を保存し、エンドユーザのブラウザは、通常、エンドユーザプロセッサ６０２上のブラウザのシステムフォルダ内に格納されるテキストファイルとしてクッキーを格納する。ユーザのプロセッサ６０２がクッキーを受け入れない場合には、アプリケーションは、ユーザに対してオプションを変更するようにリクエストする応答を生成することになる。
【００７２】
本実施形態では、ｐｐｖスロット情報は、データベース６０８内のトランザクションテーブルに格納される。一般に、トランザクションテーブルは、エンドユーザを特定のストリーミング・メディアイベント及びそのイベントの３つのｐｐｖスロットと関連付ける。この目的のために、トランザクションテーブルは、以下のフィールド、すなわち、エンドユーザＩＤ、イベントＩＤ（所与のメディアイベントを一意的に識別する）、ストリーミングＩＤ、イベントに対するエンドユーザのアクセスの日付、第１のｐｐｖスロット値、第１のｐｐｖスロットのＧＵＩＤ、第２のｐｐｖスロット値、第２のｐｐｖスロットのＧＵＩＤ、第３のｐｐｖスロット値、第３のｐｐｖスロット値のＧＵＩＤを含む。本明細書の説明に基づいて、エンドユーザ及びｐｐｖスロット情報を特定のイベントと関連付けることを利用して、１つのイベントにつき各エンドユーザに対しエンドユーザプロセッサ６０２を３つ以下に制約することができ、一方、トランザクション・データベースがエンドユーザを単にｐｐｖスロット情報に関連付けている（イベント毎ではなく全イベントにわたって）別の実施形態では、各ユーザを全イベントにわたって３つのエンドユーザプロセッサ６０２までに制約することができる点は理解されるであろう。
【００７３】
以下により詳細に説明されるように、ビジネスサーバ９０４は、ｐｐｖスロット値を含む接続情報の全て又は一部をグローバルキャッシュ・サーバ９０２から受け取る。グローバルキャッシュ・サーバ９０２と同様、ビジネスサーバ９０４は、ローカル又は遠隔のデータ記憶装置を含み、各固有のセットの接続情報についての別個のレコードをデータベース内に格納する。接続情報に基づいて、ビジネスサーバ９０４上に存在する許可アプリケーションは、エンドユーザのアクセスを３つ以下のエンドユーザプロセッサ６０２に制限し、該３つのエンドユーザプロセッサ６０２の各々について単一のメディアプレーヤに制限する。許可されるエンドユーザプロセッサ６０２の数（従ってｐｐｖスロット値の数）は、ビジネスサーバ９０４の許可アプリケーションにおいて構成変更可能である。
【００７４】
本実施形態に関連して説明された更に高いレベルの保護は、上述の実施形態の認証システム及び方法と共に利用することができるが、本実施形態に関連して説明された更に高いレベルの保護の１つ又はそれ以上のいずれかは、認証メカニズム単独で実施してもよく、或いは、本明細書で上記に説明された以外の認証メカニズムと共に実施してもよい点は理解されるであろう。従ってここで、単なる例証として、更に高いレベルの保護を図１０のワークフロー図を参照して説明する。
【００７５】
最初にウェブサーバ６０６は、サービスへの登録と許可アプリケーションへのログインをエンドユーザにリクエストするウェブページを該エンドユーザに供給する。ウェブページはまた、各々が別個のストリーミングリクエストリンクを有する多くのストリーミングメディアファイルの１つを視聴するオプションをエンドユーザに呈示する（ステップ１００２）。これに応答して、エンドユーザは、エンドユーザＩＤを提供し、ウェブページ上の所望のストリーミングリクエストリンクを起動して、これにより特定のストリーミング・メディアコンテンツファイルへのアクセスをリクエストする。エンドユーザはまた、クレジットカード番号などの支払い情報又は他のアカウント情報を提供することができる。上記の実施形態と同様、エンドユーザＩＤの提供並びにストリーミングリクエストリンクの起動は、単一のステップ又は別個のステップとして行うことができる。エンドユーザがログインするときには、Ｊａｖａスクリプト又は他のスクリプト若しくは構成要素などのウェブサーバ６０６上で実行される認証アプリケーションは、エンドユーザがこれまでにそのシステムにログインしたことを示すｐｐｖスロットクッキーについてエンドユーザプロセッサ６０２をチェックする。クッキーが存在しない場合には、ウェブサーバ６０６は、特定のエンドユーザプロセッサ６０２にクッキーを割り当て、これをエンドユーザプロセッサ６０２上に格納し、これによってプロセッサ６０２を識別する。ストリーミングリクエストリンクを起動することによって、ストリーミングリクエストリンクとエンドユーザＩＤは、ウェブサーバ６０６に伝達される（ステップ１００４）。
【００７６】
エンドユーザがシステムにログインし、コンテンツへのアクセスをリクエストするときには、ウェブサーバ６０６の認証アプリケーションは、エンドユーザが割り当てられた３つのｐｐｖスロットを超えているかどうかを判断し、超えていない場合には、トランザクションテーブルを更新する（ステップ１０１０ａ）。この点において、ウェブサーバ６０６は、エンドユーザがシステムにログインしたときに割り当てられたクッキーＩＤを、特定のエンドユーザ（エンドユーザＩＤによって識別された）及びイベント（イベントＩＤによって識別された）に関するトランザクションテーブル内の全てのｐｐｖスロット値と比較する。トランザクションテーブルが既に３つのｐｐｖスロット値を含み、受け取ったクッキーＩＤが、既存の３つのｐｐｖスロット値のどれとも一致しない場合には、エンドユーザは、第４のプロセッサから許可されていないアクセスを試みたものとみなされ、このアクセスは拒否される。
【００７７】
トランザクションテーブルが、そのイベントのエンドユーザに対して３つより少ないｐｐｖスロット値を含む場合には、ウェブサーバ６０６は、トランザクションテーブル内にレコードを作成する。より具体的には、ウェブサーバ６０６は、エンドユーザＩＤ、イベントＩＤ（エンドユーザによって購入されたコンテンツに以前に割り当てられた）、購入されたコンテンツのストリーミングＩＤ（ストリーミングリクエストリンクのプレイリストＩＤに対応するものとして、データベース６０８からウェブサーバ６０６が検出する）、日付、及びｐｐｖスロット値を使用してレコードを作成する。
【００７８】
エンドユーザが、ｐｐｖスロット情報に基づいてアクセスが拒否されない場合には、ストリーミングリクエストリンク及びエンドユーザＩＤを受け取ると、ウェブサーバ６０６上で実行される認証アプリケーションは、データベース６０８にアクセスし（ステップ１００６）、該データベース６０８から秘密キー情報を受け取り（ステップ１００８）、チケットを生成して、チケット、エンドユーザＩＤ、及びｐｐｖスロット値をストリーミングリクエストリンクに付加する（ステップ１０１０ｂ）。次いで、ウェブサーバ６０６上で実行される認証アプリケーションは、付加されたチケット、エンドユーザＩＤ、及びｐｐｖスロット値を含むストリーミングリクエストリンクをプレイリストサーバ６１０に渡す（ステップ１０１２）。
【００７９】
プレイリストサーバ６１０が、ストリーミングリクエストリンク、チケット、エンドユーザＩＤ、及びｐｐｖスロット値を受け取ると、プレイリストサーバ６１０は、リダイレクタファイルを生成するステップに進む。上述のように、リダイレクタファイルを生成するために、プレイリストサーバ６１０は、データベース６０８にアクセスし（ステップ１０１４）、プレイリスト、並びにその全てが特定のストリーミングＩＤと対応付けられた、ホスト名、ＵＲＬプレフィックス、及びファイル名を含むコンテンツファイルのストリーミングＩＤを検索する（ステップ１０１６）。この情報を使用して、プレイリストサーバ６１０は、リダイレクタファイルを作成する（ステップ１０１８）。次いで、プレイリストサーバ６１０は、ＧＵＩＤにより識別されるエンドユーザプロセッサ６０２の特定のメディアプレーヤにリダイレクタファイルを渡す（ステップ１０２０）。本実施形態の例示的なリダイレクタファイルを以下に示す。
＜ＡＳＸ＞
＜ＥＮＴＲＹ＞
＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍｌ．ａｓｆ？ＩＤ＝１２３４５６＆ＴＩＣＫＥＴ＝ｕｖｗｌ２３ｘｙｚ＆ＵＳＥＲ＿ＩＤ＝ａｂｃｌ２３ｄｅｆ＆ＰＰＶ＿ＳＬＯＴ＝１”＞
＜／ＥＮＴＲＹ＞
＜／ＡＳＸ＞
ここで、ＵＲＬプレフィックスが「ｍｍｓ：／／」で表され、適切なメディアサーバ６０４のホスト名が「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」で表され、ファイル名が「ｓｔｒｅａｍ１．ａｓｆ」で表され、コンテンツストリーミングＩＤのリクエストされたアイテムが「１２３４５６」で表され、チケットが「ｕｖｗ１２３ｘｙｚ」で表され、エンドユーザＩＤが「ａｂｃ１２３ｄｅｆ」で表され、ｐｐｖスロット値が「１」である。
【００８０】
リダイレクタファイルを受け取った後、エンドユーザプロセッサ６０２上のメディアプレーヤは、適切なストリーミング・メディアサーバ６０４にストリーミング・メディアコンテンツをリクエストするステップに進む（ステップ１０２２）。より具体的には、メディアプレーヤは、リダイレクタファイルにおいて識別された特定のストリーミング・メディアサーバ６０４を呼び出す。呼び出されると、メディアプレーヤは、リクエストされたコンテンツのストリーミングＩＤのコピー、ウェブサーバ６０６によって生成されたチケット（ステップ１０１０で）、エンドユーザＩＤ、及びｐｐｖスロット値をストリーミング・メディアサーバ６０４に提供する。更にメディアプレーヤは、そのＧＵＩＤをストリーミング・メディアサーバに渡す。
【００８１】
エンドユーザプロセッサ６０２からオリジナルのストリーミングリクエスト及びログイン情報を受け取ると、ストリーミング・メディアサーバ６０４上で実行されるアプリケーションは、メディアプレーヤがＧＵＩＤを渡した（又は無効のデフォルト値を渡した）かどうかを判断する。渡していない場合、アプリケーションは、認証プロセスを中止することによってエンドユーザのアクセスを拒否し、エンドユーザに通知する。好適には、エンドユーザのメディアプレーヤがＧＵＩＤを提供しなかったことがデータベース６０８又は他のデータ記憶装置内に記録され、次回にこのエンドユーザがシステムにログインするときに、システムは、ＧＵＩＤの送信を可能にする方法に関する指示をエンドユーザに提供する。
【００８２】
図６−８の実施形態と同様、ストリーミング・メディアサーバ６０４がメディアプレーヤの呼び出しを受けると、ストリーミング・メディアサーバ６０４は、１つ又はそれ以上の認証チケットを個別に生成し、その１つ又はそれ以上のチケットをメディアプレーヤから受け取られたチケットと比較する（ステップ１０２４）。チケットが「一致する」場合、ストリーミング・メディアサーバ６０４は、コンテンツへのアクセスを許可し、エンドユーザにコンテンツをストリーミングする（ステップ１０２６）。
【００８３】
ストリーミングサーバ６０４が、エンドユーザにコンテンツへのアクセスを許可する度に、ストリーミング・メディアサーバ６０４は、特定の接続を識別する情報をグローバルキャッシュ・サーバ９０２に送る（ステップ１０２８）。上述のように、このような接続情報は、エンドユーザＩＤ、ストリーミング・コンテンツのフォーマット（例えばウインドウズのメディアプレーヤ又はリアルプレーヤ）、エンドユーザにコンテンツを提供するストリーミング・メディアサーバ６０４のサーバＩＤ、エンドユーザのメディアプレーヤのＧＵＩＤ、及びエンドユーザがシステムにログインした特定のエンドユーザプロセッサ６０２を表すｐｐｖスロット値を含むのが好ましい。
【００８４】
ストリーミングサーバ６０４が、エンドユーザにコンテンツへのアクセスを許可する度に、ストリーミング・メディアサーバ６０４はまた、ストリーミング名又はストリーミングＩＤ、エンドユーザＩＤ、及びリクエストに関する接続情報をローカルにキャッシュする。ストリーミング接続が終了する場合は常に、ストリーミング・メディアサーバ６０４は、キャッシュ中の対応するエントリーを削除する。従って、キャッシュ中の全てのエントリーは、現在のストリーミング又はアクセスを表す。ソフトウェア構成要素又はオブジェクトなどのストリーミング・メディアサーバ６０４上で実行されるポーリングサービスを使用して、メディアサーバ６０４は、エントリーのキャッシュを周期的に（例えば２分毎に）ポーリングする。各エントリーに対し、ストリーミング・メディアサーバ６０４は、グローバルキャッシュ・サーバ９０２に接続情報を再送する。
【００８５】
上述のように、グローバルキャッシュ・サーバ９０２は、受け取られた接続情報を各レコードが含んでいるデータベース又はキャッシュを含む。グローバルキャッシュ・サーバ９０２が、特定のユーザに関する接続情報を受け取ると、サーバ９０２は、通常、そのデータベース内に新しいレコードを作成する。しかしながら、新しいレコードを作成する前に、グローバルキャッシュ・サーバ９０２は、そのデータベースが新規に受け取った接続情報と同じエンドユーザＩＤを有するレコードを含むかどうかを最初に判断する（ステップ１０３０）。
【００８６】
グローバルキャッシュ・サーバ９０２はまた、アクセスが終了するときに特定のアクセスに関するレコードを削除する。上述のように、各ストリーミング・メディアサーバ６０４は、接続情報によって識別されるアクセスの期間中に所定の間隔でグローバルキャッシュ・サーバ９０２に接続情報の各セットを再送する。グローバルキャッシュ・サーバ９０２は、接続情報が再送されなかったレコードを周期的に消去し、これにより最新のアクセスに関するレコードだけを保持する。別の実施形態では、グローバルキャッシュ・サーバは、別の方法に基づいて、もはや使用されていない接続に関するレコードを消去することができる。例えば、別の実施形態において、グローバルキャッシュ・サーバ９０２は、該グローバルキャッシュ・サーバが特定の接続が終了したことを示す終了メッセージをストリーミング・メディアサーバから受け取るまで、特定の接続に関するレコードを保持する。つまり、グローバルキャッシュ・サーバのデータベース内にレコードが存在することは、特定のエンドユーザ（エンドユーザＩＤによって識別される）が現在コンテンツファイルにアクセスしていることを表している。
【００８７】
グローバルキャッシュ・サーバ９０２が受け取ったエンドユーザＩＤと同じエンドユーザＩＤを備えたレコードを既に有する場合、エンドユーザ（又はアクセス情報を取得した無許可のユーザ）は、複数のコンテンツファイルに同ときにアクセスし、或いは複数回同じコンテンツファイルにアクセスすることを試みている。本実施形態では、このような複数アクセスは許可されない。従って、グローバルキャッシュ・サーバ９０２は、新規に受け取られる接続情報が受け取られているメディアサーバと、現存のデータベースレコード中のサーバＩＤによって識別されるメディアサーバの両方にエンドユーザのアクセスを終了させるリクエストを発行する。ストリーミング・メディアサーバ６０４がエンドユーザから接続解除されると、グローバルキャッシュ・サーバ９０２は、そのデータベースから特定のエンドユーザに関係するレコードを削除する。
【００８８】
この更に高いレベルの許可保護は任意選択であり、異なる方法で実施することができる点は理解されるべきである。例えば、別のサーバが、ユーザが複数アクセスを試みているかどうかを判断するためにグローバルキャッシュ・サーバ９０２に照会することができる。このような１つの実施形態では、プレイリストサーバ６１０がウェブサーバ６０６からリクエストリンク、チケット、及びエンドユーザＩＤを受け取った後で、グローバルキャッシュ・サーバ９０２を呼び出し、グローバルキャッシュ・サーバ９０２が既にコンテンツにアクセスしているエンドユーザのレコードを有するかどうかを判断する（ステップ１０１８ａ）。グローバルキャッシュ・サーバ９０２は、エンドユーザが現在コンテンツにアクセスしているか否かに関する表示をプレイリストサーバ６１０に返信する（ステップ１０１８ｂ）。これに応じて、プレイリストサーバ６１０上で実行される認証アプリケーションは、偽又は無効のリダイレクタファイルを生成する。このような１つの実施例では、リダイレクタファイルは、チケットが存在せず、又はストリーミング・メディアサーバ６０４によって検出されることになるデフォルトチケットを含むことにより、無効である。
【００８９】
グローバルキャッシュ・サーバ９０２が、そのデータベースにおいて新しい接続情報で受け取られたエンドユーザＩＤと同一のエンドユーザＩＤを有するレコードが存在しないことを識別した場合、グローバルキャッシュ・サーバ９０２は、そのデータベースにおいて受け取った接続情報を用いて新しいレコードを作成し、エンドユーザのコンテンツへのアクセスを妨げない。
【００９０】
グローバルキャッシュ・サーバ９０２が、エンドユーザの接続を解除しない場合、サーバ９０２は、接続情報の全部又は一部をビジネスサーバ９０４に中継し、該ビジネスサーバは、２つの更に高いレベルの任意選択の許可保護を有効にする（ステップ１０３４）。本実施形態では、グローバルキャッシュ・サーバ９０２は、エンドユーザＩＤ、ｐｐｖスロット、ＧＵＩＤ、及びストリーミングフォーマットをビジネスサーバ９０４に中継する。
【００９１】
ビジネスサーバ９０４は、グローバルキャッシュ・サーバ９０２から受け取ったこの接続情報を使用して、メディアプレーヤのＧＵＩＤに部分的に基づいてコンテンツへのアクセスを制御する（ステップ１０３６）。上述のように、各エンドユーザは、各々が各フォーマットに対し１つだけのメディアプレーヤを有する３つの異なるエンドユーザプロセッサ６０２からシステムにログインし、コンテンツにアクセスすることが許可される。従って、特定のエンドユーザプロセッサ６０２（ｐｐｖスロットによって識別される）に関し、エンドユーザが特定のメディアフォーマット用の特定のメディアプレーヤ（ＧＵＩＤにより識別される）を用いてアクセスするようリクエストし、該メディアプレーヤが、同じフォーマットのメディアに対して同じエンドユーザプロセッサ６０２上で以前使用されていたメディアプレーヤとは異なる場合、ビジネスサーバ９０４は、エンドユーザの接続を切断させることになる。一般に、この決定は、トランザクションテーブルにアクセスし、新しく受け取られる接続情報をエンドユーザ及びｐｐｖスロット値に関する既存のエントリーと比較することによって行われる。
【００９２】
ビジネスサーバ６０４が、所与のエンドユーザ及びｐｐｖスロットに関する接続情報とを受け取ると、ビジネスサーバ９０４は、トランザクションテーブルにアクセスし、ＧＵＩＤがこの特定のエンドユーザ、ｐｐｖスロット、及びフォーマットについて以前受け取ったかどうかを判断する。受け取っていない場合には、ビジネスサーバ９０４がトランザクションテーブルを更新させてＧＵＩＤを反映させ、ビジネスサーバ９０４は、エンドユーザのアクセスを終了するために何もしない。
【００９３】
受け取られた接続情報が、ＧＵＩＤが既に受け取ったトランザクションテーブル中のレコードに対応する場合、ビジネスサーバ９０４は、受け取られたＧＵＩＤがそのｐｐｖスロットに関して格納された特定のメディアフォーマット用のＧＵＩＤと一致するかどうかを判断する。ＧＵＩＤが一致しない場合には、ビジネスサーバ９０４は、グローバルキャッシュ・サーバ９０２にエンドユーザのコンテンツへのアクセスを終了する旨の命令を送信し、エンドユーザのアクセスは拒否される。このような命令は、エンドユーザＩＤを指定するのが好ましい（ステップ１０３８）。次に、グローバルキャッシュ・サーバ９０２は、現在エンドユーザにコンテンツを供給している１つ又はそれ以上のストリーミング・メディアサーバ６０４にリクエストを発行する。
【００９４】
従って、エンドユーザが一時的にコンテンツへのアクセスが許可されていても、本実施形態は、無許可のエンドユーザに対してアクセスを拒否するものとみなされるべきである。このような一時的なアクセスは、グローバルキャッシュ・サーバ９０２及びビジネスサーバ９０４での処理に起因してアクセスの許可に遅延が生じないこと望ましいので、本実施形態においては許可される。グローバルキャッシュ・サーバ９０２及びビジネスサーバ９０４の処理に対してアクセスが遅延した特定の事例においては、エンドユーザのメディアプレーヤがタイムアウトとなり、アクセスの認可が妨げられる可能性がある。その結果、本実施形態のメディアサーバ６０４は、チケットが一致すると直ちにアクセスを認可し、これによりメディアプレーヤがタイムアウトとなることを防ぎ、更に、グローバルキャッシュ・サーバ９０２又はビジネスサーバ９０４がそのアクセスを不適切であると判断した場合には、このようなアクセスは終了する。
【００９５】
ビジネスサーバ９０４が、新しく受け取られたメディアプレーヤのＧＵＩＤがｐｐｖスロット及びフォーマットに関しメモリ内に格納されたＧＵＩＤと一致すると判断した場合、ビジネスサーバ９０４は、何も行わず、エンドユーザのアクセスが継続することを許可する。
【００９６】
グローバルキャッシュ・サーバ９０２が、システム内の全てのストリーミング・メディアサーバ９０４からの接続情報を受け取ることが好ましい限りは、各々がメディアサーバのサブセットから接続情報を受け取る複数のグローバルキャッシュ・サーバを含むことができる点を理解されたい。しかしながら、このような実施形態では、複数のグローバルキャッシュ・サーバは相互に通信している。
【００９７】
更に、特定の実施形態において、グローバルキャッシュ・サーバ９０２及びビジネスサーバ９０４の機能性を１つのサーバに組み合わせてもよいが、２つの別個のサーバの使用には、スケーラビリティを含む幾つかの利点がある。例えば、許可システムが複数のコンテンツ所有者のアカウントに対して利用される場合には、各アカウントが別個の認証ルールを実施することができ、各ルールは、グローバルキャッシュ・サーバへのアクセスを有する別個のビジネスサーバ上にある。このような実施形態において、接続情報は、現存する接続情報又はアカウントＩＤなどの接続情報に含まれる付加的なフィールドに基づいて適切なビジネスサーバに送ることができる。
【００９８】
本実施形態では、システムは、エンドユーザのｐｐｖスロット情報（ｐｐｖスロット値とＧＵＩＤを含む）を再登録及びクリアする機会を各エンドユーザに提供し、これによりエンドユーザが異なるマシン及び／又はメディアプレーヤからのコンテンツにアクセスすることが可能になる。
【００９９】
他の別の実施形態では、メディアサーバ６０４とは対照的に、グローバルキャッシュ・サーバ９０２でチケット許可を実行することによってプレイリストへのアクセスを制御する。これは、より大きなスケーラビリティを有するより効率的なシステムをもたらすことができる。このことは、全て同様のコンテンツを供給する極めて多くのメディアサーバが存在する場合に特に有用である。各メディアサーバ上で全く同じ情報を保管し且つ処理する代わりに、この実施形態により、認証情報を１つの中央プレイリスト上に存在させることが可能となり、残りのシステムに渡していくことができる。従って、メディアサーバは、コンテンツをストリーミングすることに集中し、認証アルゴリズムによって妨げられないようにすることができる。ここで、このような１つの実施形態を図１１−１２に関連して説明する。本実施形態の機能性のほとんどは、図３、図６、及び図９の実施形態の機能性と同じであり、従って、同じ技術のいずれかによって実施することができる点は、当業者であれば理解されるであろう。本実施形態のアーキテクチャは、図９に関連して検討されたアーキテクチャと同じものである。
【０１００】
次に、本実施形態の動作を図１１のワークフロー図に関連して説明する。本実施例の目的のために、エンドユーザは、保護されたコンテンツの１つのアイテムを有するプレイリストへのアクセスをリクエストするが、複数のアイテムを使用することもできる。最初に、ウェブサーバ６０６は、許可アプリケーションへのログインをエンドユーザにリクエストし、特定のストリーミング・メディアを視聴するオプションをユーザに呈示するウェブページを提供する（ステップ１１０２）。
【０１０１】
エンドユーザが、ストリーミングリクエストリンクを起動すると、エンドユーザプロセッサ６０２上で実行されるプログラミングスクリプトにより、ストリーミングリクエストリンク及びエンドユーザＩＤをウェブサーバ６０６に送る（ステップ１１０４）。エンドユーザのスクリプトは、例えばＣ＋＋、Ｐｅｒｌ（パール）、ビジュアルベーシック、Ｊａｖａ及び同様のものを含むどのようなプログラミング言語ででも基本的に実施することができることを当業者であれば認識するであろう。本実施形態では、スクリプトはＪａｖａスクリプトであり、エンドユーザのウェブブラウザと連動して実行される。
【０１０２】
ウェブサーバ６０６が、スクリプトからストリーミングリクエストを受け取ると、ウェブサーバ６０６は、許可ソフトウエア・プラグインの指示の下で許可チケットを生成する。この件に関して、ウェブサーバ６０６は、データベース６０８に対して許可チケットの生成の際に使用する秘密キー（本実施形態では、リクエストされたプレイリストに関連するセキュリティキーとセキュリティインターバル）のリクエストを発行する（ステップ１１０６）。これに応答して、データベース６０８は、ウェブサーバ６０６に秘密キーを返す（ステップ１１０８）。別の実施形態では、より多くの又はより少ない或いは異なるデータを備えた秘密キーを使用することができ、セキュリティインターバルなどの特定の情報は、メモリから検索されるのではなく、暗号で設定することができる。
【０１０３】
データベース６０８から秘密キーを取得した後、ウェブサーバ６０６は、ストリーミングＩＤ又はプレイリストＩＤのいずれかを使用して、図４に関連して上述されたようにチケットを生成する（ステップ１１１０）。本明細書で説明されたように、ウェブサーバ６０６は、秘密キー、ストリーミングＩＤ又はプレイリストＩＤ、エンドユーザＩＤ、及び時間値をハッシュアルゴリズムに適用してチケットを生成する。次いで、ウェブサーバは、エンドユーザプロセッサ６０２上で実行されるウェブブラウザにチケットとエンドユーザＩＤを返す（ステップ１１１２）。
【０１０４】
許可チケットを受け取った後、エンドユーザプロセッサ６０２上で実行されるスクリプトは、ストリーミングリクエストリンクの最後に情報を付加する（ステップ１１１４）。例示的なリンクは以下に示される。ここで、プレイリストＩＤは「７８９０００」で表され、チケットが「ｕｖｗ１２３ｘｙｚ」で表され、エンドユーザＩＤが「ａｂｃ１２３ｄｅｆ」で表される。
【０１０５】
＜ Ａ ｈｒｅｆ
”ｈｔｔｐ：／／ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｍａｋｅｐｌａｙｌｉｓｔ？ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｕｖｗｌ２３ｘｙｚｒｅｔｕｒｎ＆ＵＳＥＲ＿ＩＤ＝ａｂｃｌ２３ｄｅｆ”＞
【０１０６】
次いで、エンドユーザプロセッサ６０２上で実行されるスクリプトは、ホスト名「ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」によりストリーミングリクエストリンクで識別されるプレイリストサーバ６１０が呼び出される（ステップ１１１６）。従って、プレイリストサーバ６１０は、リンク、プレイリストＩＤ、チケットユーザＩＤ及びクッキーＩＤが提供され、これらは以下により詳細に説明する。
【０１０７】
別の実施形態では、ストリーミングリクエストにチケットを付加するためにエンドユーザスクリプトは使用されない。その代わりに、エンドユーザが、そのエンドユーザＩＤを提供してストリーミングリクエストリンクを起動する（ステップ１１０４で）ときに、ウェブサーバ６０６上で実行される認証アプリケーションがチケットを生成し、該チケットとエンドユーザＩＤとをストリーミングリクエストリンクに付加し、プレイリストサーバ６１０を直接呼び出してチケットを検証する。ウェブサーバ６０６はまた、プレイリストサーバ６１０にエンドユーザプロセッサ６０２を識別する情報を渡すので、プレイリストサーバ６１０は、プレイリスト・ハッシュ（以下で説明する）をエンドユーザプロセッサ６０２に転送する（これによりステップ１１１２、１１１４、及び１１１６を不要にする）。
【０１０８】
次に、プレイリストサーバ６１０は、リクエストと共にウェブサーバ６０６によって生成されたチケットをグローバルキャッシュ・サーバ９０２に渡し、第２のチケットを生成する（ステップ１１１８）。グローバルキャッシュ・サーバは、そのローカルのデータベースに対し許可チケットを生成する際に使用するための秘密キー（本実施形態では、リクエストされたプレイリストに関連するセキュリティキーとセキュリティインターバル）のリクエストを発行する（ステップ１１２０）。ローカルデータベースを有することで追加される利点は、別のサーバ又は他のデータベースを使用することを必要とせずにデータベース内で情報にアクセスできることである点を認識されたい。従って、ローカルデータベースを使用することにより、データベース内に格納された情報をより迅速に処理することができる。リクエストに応答して、ローカルデータベースは、グローバルキャッシュ・サーバ９０２に秘密キーを返す（ステップ１１２２）。
【０１０９】
このローカルデータベースから秘密キーを取得した後、グローバルキャッシュ・サーバ９０２は、図１１に関連して以下に更に詳細に説明するように、１つ又はそれ以上の認証チケットを独自に生成し、これらのチケットをウェブサーバ６０６によって生成されたチケットと比較することにより、アクセスを認可するかどうかを判断する（ステップ１１２４）。グローバルキャッシュ・サーバ９０２によって生成されたチケットが、ウェブサーバ６０６によって生成されたチケットと一致する場合、グローバルキャッシュ・サーバ９０２は、プレイリストサーバ６１０に一致を表すメッセージを送る。チケットが一致しない場合は、プレイリストサーバ６１０に不一致を表すメッセージが送られる（ステップ１１２６）。
【０１１０】
プレイリストサーバ６１０が、一致を表すメッセージを受け取ると、プレイリストサーバ６１０は、プレイリスト・ハッシュを生成する。このハッシュは、当該プロセッサ６０２に対するクッキーＩＤに基づく。上述のように、一般に、クッキーは、エンドユーザが特定のエンドユーザプロセッサ６０２を介して１つ又はそれ以上の特定のウェブサイトを最初に訪れたときに、ウェブサーバがエンドユーザのブラウザに付与するデータのセットである。ウェブサーバ６０６は、クッキーが含むエンドユーザに関する情報（例えばユーザＩＤ）を保存し、エンドユーザのブラウザは、通常、エンドユーザプロセッサ６０２上のブラウザのシステムフォルダ内に格納されるテキストファイルとしてクッキーを格納する。このクッキーは、リンク、プレイリストＩＤ、チケット及びユーザＩＤと共にエンドユーザプロセッサ６０２からプレイリストサーバに渡される。ユーザのプロセッサ６０２（例えばウェブブラウザ）がクッキーを受け入れない場合には、アプリケーションは、ユーザに対してオプションを変更するようリクエストする応答を生成することになる。このクッキーは、現在時刻及び予め定められたタイムインターバルと共に、プレイリストサーバ６１０によって使用されてプレイリスト・ハッシュを生成する。このハッシュの生成については、以下に更に詳細に説明する。チケットが一致しなかった場合には、「ダミーハッシュ」が生成され、ストリーミングに付加される（ステップ１１２８）。この「ダミーのハッシュ」は、クッキーに基づく必要はなく、むしろ許可されなかったことをシステムに対して単に示すものである。従って、ダミーハッシュは、予め定められた英数字、又はランダムに生成されたストリング、過去の時間又は未来時間に基づくハッシュ、ゼロ値、及び同様のものとすることができる。ストリーミングリクエストと共にハッシュ及び許可チケットは、エンドユーザプロセッサ６０２に送られる（ステップ１１３０）。或いは、許可チケットの１つ又は両方はエンドユーザプロセッサ６０２には渡されない。特定の実施形態では、「ダミーハッシュ」が生成されずに、むしろストリーミングリクエストが、どのようなハッシュも付加されずにエンドユーザプロセッサ６０２に送られ、すなわち許可されなかったことを示すことも理解されたい。
【０１１１】
プレイリスト・ハッシュは、コンテンツを視聴するための許可が認可されていたか又は許可が拒否されていたものとしてユーザを識別するよう機能する点も理解されたい。ユーザが許可されていた場合、有効なプレイリスト・ハッシュが生成されることになる。ユーザが許可されていなかった場合、無効又は「ダミー」ハッシュが生成されることになる。対照的に、生成された許可チケットは、コンテンツを視聴する許可をユーザが認可されるべきか否かを判断するベースを形成する。
【０１１２】
プレイリスト・ハッシュを受け取った後、エンドユーザプロセッサ６０２は、ストリーミング・メディアサーバ６０４にストリーミング・メディアコンテンツをリクエストするステップに進む（ステップ１１３２）。エンドユーザプロセッサ６０２は、必要に応じてストリーミングＩＤのコピー又はプレイリストＩＤ、プレイリスト・ハッシュ、許可チケット、並びにクッキーを渡す。上記で説明されたように、特定の実施形態では、許可チケットの１つ又は両方はプレイリストサーバ６１０からエンドユーザプロセッサ６０２に渡されず、従って、エンドユーザプロセッサ６０２からストリーミング・メディアサーバ６０４に渡されない。ストリングが受け取られると、ストリーミング・メディアサーバ６０４は、現在時刻、受け取ったクッキー、及び予め定められたセキュリティタイムインターバルを利用するプレイリストサーバによって使用されたのと同じハッシュアルゴリズムを使用して第２のハッシュ値を生成することによって、プレイリスト・ハッシュの精度を検証する。次にメディアサーバ６０４は、生成されたハッシュを受け取ったハッシュと比較する（ステップ１１３４）。ハッシュの妥当性が検証されると（例えば生成されたハッシュと一致すると）コンテンツが供給され、検証されない場合には、ハッシュが「ダミーハッシュ」であるか、或いはアクセスの有効期限が切れている理由からアクセスが拒否される（ステップ１１３６）。
【０１１３】
大半の認証をメディアサーバではなくプレイリストサーバ上で行うことができる利点が付加されることにより、システムの効率が大幅に向上する点を理解すべきである。全てが同じコンテンツを供給する多数のメディアサーバが存在できる場合、メディアサーバ上で保管及び処理される完全に同一の情報は、様々な異なる箇所で見出すことができる。従って、メディアサーバが処理する認証を可能な限り少なくできることで、メモリ空間を大幅に節約することができる。従って、大半の認証情報を１つの中央プレイリストサーバ上に存在させることができ、該情報を残りのシステムに渡していくことができる。加えて、メディアサーバがコンテンツのストリーミングに集中できることにより、コンテンツのストリーミングも同様により効率的になる。
【０１１４】
次に、リクエストされたコンテンツストリーミングへのアクセスを認可するかどうかを判断するグローバルキャッシュ・サーバ９０２のプロセスを図１２を参照して説明する。理解されるように、本プロセスは、図５に関連して上記で説明されたプロセスと同じである。
【０１１５】
アクセスを認可するかどうかの判断において、最初に、グローバルキャッシュ・サーバ９０２が、ストリーミングＩＤ、エンドユーザＩＤ、公開キー、エンドユーザのクッキー及びチケットを含むストリーミングリクエストをプレイリストサーバ６１０から受け取る（ステップ１２０２）。ストリーミングリクエストを受け取ると、グローバルキャッシュ・サーバ９０２は、ハッシュアルゴリズムに対する入力ストリングを生成する。この点に関して、グローバルキャッシュ・サーバ９０２は、キャッシュ又はローカルデータベースとすることができるローカルメモリから秘密キー情報、すなわちセキュリティキー及びセキュリティインターバルを検索するが、別のキーを使用してもよい（ステップ１２０６）。
【０１１６】
メディアサーバ１０４に関して上記で検討したように、グローバルキャッシュ・サーバ９０２は、３つの時間値を計算してその時差を考慮する（ステップ１２１０）。次いで、この時点で、グローバルキャッシュ・サーバ９０２は、検索された秘密キー情報、受け取った公開キー情報、及び３つの時間値を用いて、３つの対応するハッシュ入力ストリングを生成する（ステップ１２１４）。本実施形態では、３つの時間値は、現在時刻、現在時刻＋セキュリティタイムインターバル、及び現在時刻−セキュリティタイムインターバルであり、例えば、ここでセキュリティインターバルは、現在時刻の１０秒前及び現在時刻の１０秒後である。時間値の間の差が小さいほど、適用されるセキュリティのレベルが高くなることは理解されるべきである。適正なハッシュでも有効寿命が限られているので、より短いタイムインターバルは、ユーザが適正なハッシュを傍受し、これを適正な認証として渡してコンテンツを不正に取得しようとする可能性を低減する。次に、グローバルキャッシュ・サーバ９０２は、ハッシュアルゴリズムに対して３つの入力ストリングの各々を適用し、これにより３つのチケットを生成する（ステップ１２１８）。
【０１１７】
チケットを独自に生成した後、次にグローバルキャッシュ・サーバ９０２は、グローバルキャッシュ・サーバ９０２によって生成されたチケットのいずれかがウェブサーバ６０６によって生成されたチケットと一致するかどうかを判断する（ステップ１２２２）。チケットが一致しない場合には、ストリーミングリクエストは認証されたものではなく、及び／又は有効期限が切れたものである（すなわち、ユーザのリクエスト時間から測定してセキュリティインターバルを超えた時間にグローバルキャッシュ・サーバ９０２によって生成されたもの）可能性が高い。従って、グローバルキャッシュ・サーバは、プレイリストサーバに認証されなかったことを通知するメッセージを渡す（ステップ１２２６）。
【０１１８】
チケットが一致する場合、ストリーミングリクエストは認証されたものであり、セキュリティタイムインターバルの範囲内にある可能性が高い。次にグローバルキャッシュ・サーバ９０２は、プレイリストサーバ９１０に対してプレイリスト・ハッシュを生成するように指示するメッセージをプレイリストサーバ９１０に渡す（ステップ１２３０）。図１１に関連して上述されたように、このハッシュは、ストリーミングリクエストと共にエンドユーザプロセッサ６０２に渡され、そこからハッシュの精度を検証するためにストリーミング・メディアサーバ６０４に渡される。
【０１１９】
本明細書の説明に基づいて、図５に関連して検討された種々の実施形態及び修正の全てが本実施形態にも適用できることは、当業者であれば理解されるであろう。
【０１２０】
上述の実施形態は、セキュリティキー及びセキュリティインターバルの両方を含む秘密キーを利用するが、これより多くの情報又は少ない情報を秘密キーとして利用することも本発明の範囲内であることは理解すべきである。例えば、別の実施形態では、秘密キーは使用されず、他の実施形態では、秘密キーに例えばクライアントのユーザ名及びパスワードを含む追加情報が含められる。同様に、ストリーミングＩＤ及びエンドユーザＩＤ以外の情報を含む公開キーを利用することは本発明の範囲内である。例えば、ファイルパス名を含む情報を識別する別のコンテンツファイルを使用してもよい。加えて、ある実施形態では、エンドユーザＩＤは公開キー情報から省くことができる。更に別の実施形態では公開キー情報は、リクエストコンテンツファイルのタイトル又は他のストリーミング詳細などの追加情報を含む。
【０１２１】
ウェブサーバ及びストリーミング・メディアサーバによって提供されるものとして記載された機能性は、これに関連する他のデバイス上で実施することができる点も理解されるであろう。例えば、本発明の特定の実施形態では、ストリーミング・メディアサーバは、これに接続された関連アプリケーションサーバを有し、該アプリケーションサーバは、コンテンツへのアクセスを拒否又は認可するプロセスの全て又は一部を実施する。同様に、アプリケーションサーバをウェブサーバと対応付けて、例えば許可チケットを生成するプロセスを含むウェブサーバの機能性の一部又は全てを提供することは、本発明の範囲内である。従って、特定のサーバに対する言及は、他の関連するサーバ又は言及するサーバに結合されたプロセッサを含むことを意味する。
【０１２２】
また、許可チケットは、正確な時間に生成される必要がない点も理解されるべきである。例えば、ウェブサーバによって生成されるチケットは、エンドユーザがストリーミングリクエストリンクを起動する時間、又はウェブサーバがデータベースから秘密キー情報を受け取る時間、或いはストリーミングリクエストの起動時間付近の他の任意の時間に基づくことができる。同様に、メディアサーバは、例えば、メディアプレーヤから呼び出された時間、又は秘密キー情報が検索された後、又はコンテンツへの呼び出しがなされた時間付近の他の任意の時間に許可を生成することができる。更にメディアサーバが複数のチケットを生成する場合、チケットは、異なる時間又は同じ時間に基づくことができる。従って、時間又は現在時刻に対する言及は、正確な時間ではなく範囲を言及することを意味する。
【０１２３】
上記の例示的な実施形態は、単一のアイテムのコンテンツへのアクセスを制御する関連で説明されてきたが、上記の実施形態のいずれかを使用して、複数の保護されたコンテンツファイルを含むプレイリストへのアクセスを制御することができる点を当業者は理解するであろう。ここで、プレイリストへのアクセスを制御するための１つの例示的な実施形態を図６−８に関連して説明する。このような実施形態は、以下に指摘される修正により上述の説明に従って動作する。一般に、ウェブサーバ６０６は、各ストリーミングのストリーミングＩＤに基づいてプレイリストに収容された各コンテンツストリーミングのためのチケットを生成する。
【０１２４】
エンドユーザプロセッサ６０２上のメディアプレーヤは、プレイリストＩＤを含むストリーミングリクエストをプレイリストプロセッサ６１０に渡す。次に、プレイリストプロセッサ６１０は、リダイレクタファイルを生成し、これをメディアプレーヤに返す。「ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ」オブジェクトは、本実施例ではプレイリストＩＤ「７８９０００」を使用して適切なリダイレクタファイルを構築する。より詳細には、プレイリストサーバ６１０は、プレイリストテーブル７０８とプレイリストテーブル７１０にアクセスし、どのコンテンツファイルがリクエストされたプレイリストの一部であるか、及びプレイリストのコンテンツファイルの順番を判断する。コンテンツファイルのファイル名は、ストリーミングテーブル７０４から検索される。次いで、エンドユーザプロセッサ６０２上で実行されるスクリプトは、対応するコンテンツストリーミングにリンクしているＵＲＬにストリーミングＩＤ、チケット、及びエンドユーザＩＤを付加する。本実施形態では、全てのコンテンツストリーミングが、ストリーミングサーバテーブル７１２において識別される同じメディアサーバ６０４上に配置される。
【０１２５】
対応するコンテンツストリーミングへのＵＲＬリンクに付加されたストリーミングＩＤ、チケット、及びエンドユーザＩＤを含む例示的なＡＳＸリダイレクタファイルは以下の通りである。
【０１２６】
＜ＡＳＸ＞
＜ＥＮＴＲＹ＞
＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍｌ．ａｓｆ？ＩＤ＝１２３４５６＆ＴＩＣＫＥＴ＝ａｂｃ１１１ｘｙｚ＆ＵＳＥＲ＿ＩＤ＝ａｂｃｌ２３ｄｅｆ”＞
＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍ２．ａｓｆ？ＩＤ＝２３４５６７＆ＴＩＣＫＥＴ＝ｄｅｆ２２２ｘｙｚ＆ＵＳＥＲ＿ＩＤ＝ａｂｃ１２３ｄｅｆ”＞
＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ． ｃｏｍ／ｓｔｒｅａｍ３．ａｓｆ？ＩＤ＝３４５６７８＆ＴＩＣＫＥＴ＝ｇｈｉ３３３ｘｙｚ＆ＵＳＥＲ＿ＩＤ＝ａｂｃ１２３ｄｅｆ”＞
＜／ＥＮＴＲＹ＞
＜／ＡＳＸ＞
【０１２７】
次いでメディアプレーヤは、ストリーミング・メディアサーバ６０４を連続して呼び出し、各呼び出しに対する各ＵＲＬリンクがリダイレクタファイルに含まれる。より詳細には、メディアプレーヤは最初に、第１のコンテンツストリーミング（本実施例ではストリーミングＩＤ１２３４５６を有する）へのアクセスに対しメディアサーバ６０４を呼び出す。呼び出しに応答し、更に図５に関連して上記に一般的に説明されたように、メディアサーバ６０４は、チケットを独自に生成してコンテンツへのアクセスを認可するかどうかを判断する。アクセスが認可されない場合、エンドユーザはそのように通知される。他方、メディアサーバが、エンドユーザに対し第１のコンテンツストリーミングへのアクセスを認可する場合、メディアプレーヤは、プレイリスト中の残りのコンテンツストリーミング用のメディアサーバ６０４を呼び出すステップに進む。各呼び出しで、メディアサーバ６０４は、リクエストされたコンテンツストリーミングへのアクセスを許可又は拒否するステップに進む。
【０１２８】
しかしながら、このような実施形態では、各コンテンツストリーミングが、プレイリスト中のストリーミングの前に再生されるコンテンツストリーミングの合計持続時間を考慮する個々のセキュリティインターバルを有することが望ましい点を理解されたい。例えば各々が５分の持続時間である（ストリーミングテーブル７０４のストリーミング詳細フィールドで識別された）３つのコンテンツストリーミングを含むプレイリストでは、第２のストリーミングのセキュリティインターバルは、第１のストリーミングのセキュリティインターバルよりも５分だけ長くすることができ、第３のストリーミングのセキュリティインターバルは、第１のストリーミングのセキュリティインターバルよりも１０分だけ長くすることができる。プレイリストの各ストリーミングの持続時間を考慮することによって、システムは、許可されたエンドユーザがプレイリスト中の第１のコンテンツストリーミングへのアクセスを受け入れるが、チケットが有効期限切れである理由から後続のコンテンツストリーミングに対してはアクセスが受け入れられないことを防止するのに役立つ。セキュリティインターバルはまた、プレイリスト中に含まれた広告などのあらゆる非保護のコンテンツをも考慮することができる。
【０１２９】
他の別の実施形態は、プレイリストＩＤに基づいてチケットを生成することによって、複数の保護されたコンテンツストリーミングを含むプレイリストへのアクセスを制御する。１つのこのような実施形態は、以下に指摘される修正と共に、図６−８のシステムの説明に従って動作する。一般的に、エンドユーザが許可アプリケーションにログインし、プレイリストへのアクセスをリクエストすると、ウェブサーバ６０６は、プレイリストＩＤに基づいてチケットを生成し、該チケットをエンドユーザプロセッサ６０２に返す。これに応答して、エンドユーザプロセッサ６０２上で実行されるスプリットは、ストリーミングリクエストリンクにチケット及びエンドユーザＩＤを付加する。以下は、付加された公開キー情報を有する例示的なストリーミングリクエストリンクである。ここで、プレイリストＩＤが「７８９０００」で表され、チケットが「ｘｙｚ３２１ａｂｃ」で表され、エンドユーザＩＤが「ａｂｃ１２３ｄｅｆ」で表される。
【０１３０】
＜Ａ ｈｒｅｆ
”ｈｔｔｐ：／／ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ？ＰＬＡＹＬＩＳＴ＿ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｘｙｚ３２１ａｂｃ＆ＵＳＥＲ＿ＩＤ＝ａｂｃｌ２３ｄｅｆ’＞
【０１３１】
エンドユーザプロセッサ６０２は、名称「ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」によって識別されるプレイリストサーバ６１０を呼び出す。次に、プレイリストサーバ６１０は、リダイレクタファイルを生成するためにプレイリストサーバ６１０に存在する「ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ」オブジェクトを起動する。本実施形態では、全てのコンテンツストリーミングが同一のメディアサーバ６０４上に存在する。上述の実施形態とは異なり、「ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ」オブジェクトはまた、リダイレクタファイルの第１のＵＲＬリンクの終わりにプレイリスト中の後続の保護されたコンテンツストリーミングのファイル名を付加し、後続のＵＲＬリンクの各々にはプレイリストＩＤ及びチケットだけが付加される。例示的なＡＳＸリダイレクタファイルを以下に示す。ここでプレイリストは、「ｓｔｒｅａｍ１．ａｓｆ」、「ｓｔｒｅａｍ２．ａｓｆ」、「ｓｔｒｅａｍ３．ａｓｆ」で表されるファイル名を有する３つのウインドウズメディア・フォーマットのコンテンツファイルを含み、プレイリストＩＤが「７８９０００」で表され、エンドユーザＩＤが「ａｂｃ１２３ｄｅｆ」で表され、チケットが「ｘｙｚ３２１ａｂｃ」で表される。
【０１３２】
＜ＡＳＸ＞
＜ＥＮＴＲＹ＞
＜ＲＥＦ
ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍｌ．ａｓｆ？ＰＬＡＹＬＩＳＴ＿ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｘｙｚ３２１ａｂｃ＆ＵＳＥＲ＿ＩＤ＝ａｂｃ１２３ｄｅｆ＆ＳＴＲＥＡＭ＝ｓｔｒｅａｍ２．ａｓｆ＆
ＳＴＲＥＡＭ＝ｓｔｒｅａｍ３．ａｓｆ”＞
＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍ２．ａｓｆ？ＰＬＡＹＬＩＳＴ＿ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｘｙｚ３２１ａｂｃ”＞
＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍ３．ａｓｆ？ＰＬＡＹＬＩＳＴ＿ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｘｙｚ３２１ａｂｃ”＞
＜／ＥＮＴＲＹ＞
＜／ＡＳＸ＞
【０１３３】
エンドユーザプロセッサ６０２のメディアプレーヤは、第１のコンテンツファイルにアクセスするために、ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ（すなわちストリーミング・メディアサーバ６０４のホスト名）を呼び出すステップに進む。メディアサーバ６０４は、図５に関連して上述されたように、プレイリストＩＤに基づいてチケットを生成し、アクセスを認可又は拒否するステップに進む。メディアサーバ６０４がアクセスを認可し、メディアプレーヤにプレイリスト中の第１のコンテンツファイルを提供する場合、メディアサーバ６０４は、プレイリストＩＤ及び対応するチケット用のローカルに格納されたテーブル内にレコードを作成し、リダイレクタファイルに含まれているプレイリスト中の後続のコンテンツストリーミングのファイル名をレコードに格納する。
【０１３４】
続いて、メディアプレーヤが、第２のコンテンツストリーミングへのアクセスを要求する場合、メディアプレーヤは、メディアサーバ６０４にプレイリストＩＤ及びチケットを供給する。次に、メディアサーバ６０４は、プレイリストＩＤ及びチケットによって識別されたレコードを求めてテーブルをサーチする。レコードが存在する場合、メディアサーバ６０４は、第２のストリーミングへのアクセスを許可し、特定のチケットを有するエンドユーザが視聴したものとしてストリーミングにフラグを立てる。無許可のエンドユーザが同じＵＲＬリンクを使用して第２のストリーミングにアクセスしようと試みる場合、プレイリストＩＤ及びチケットに関するレコードにおいては、第２のストリーミングは既に視聴されているものとしてフラグが立っているので、メディアサーバ６０４はアクセスを拒否することになる。同様のプロセスが、プレイリスト内の残りのコンテンツストリーミングへのアクセスを許可するために使用される。当業者には理解されるように、この実施形態は、第１のストリーミングへのアクセス認可とこのような後続のストリーミングとの間の時間遅延に起因して、プレイリスト内の後続のストリーミングへのアクセスを誤って拒否されるどのような可能性をも回避する。
【０１３５】
本発明の方法及びシステムは、多くの用途を有し、多くの様態で実施することができ、従って、上記の例示的な実施形態及び実施例によって限定されるものではない点を当業者であれば理解されるであろう。更に、本発明の範囲は、当業者には理解されるように、本明細書で説明されたシステム構成要素に対する従来公知の、及び将来開発される変形及び修正を対象とする。
【図面の簡単な説明】
【０１３６】
【図１】本発明の１つの実施形態に基づくシステムを示す概略図である。
【図２】本発明の１つの実施形態に基づくデータベースを示す概略図である。
【図３】本発明の１つの実施形態に基づくワークフローを示す概略図である。
【図４】本発明の１つの実施形態に基づくチケットを生成するプロセスを示すフローチャートである。
【図５】本発明の１つの実施形態に基づくストリーミング・メディアコンテンツのアイテムへのアクセスを許可するかどうかを判断するプロセスを示すフローチャートである。
【図６】本発明の別の実施形態に基づくシステムを示す概略図である。
【図７】本発明の別の実施形態に基づくデータベースを示す概略図である。
【図８】本発明の別の実施形態に基づくワークフローを示す概略図である。
【図９】本発明の別の実施形態に基づくシステムを示す概略図である。
【図１０】本発明の別の実施形態に基づくワークフローを示す概略図である。
【図１１】本発明の別の実施形態に基づくワークフローを示す概略図である。
【図１２】本発明の別の実施形態に基づくストリーミング・メディアコンテンツのアイテムへのアクセスを許可するかどうかを判断するプロセスを示すフローチャートである。
【符号の説明】
【０１３７】
１０２ エンドユーザ
１０４ ストリーミング・メディアサーバ
１０６ ウェブサーバ
１０８ データベース
【技術分野】
【０００１】
（関連出願に対するクロスリファレンス）
本出願は、２００１年６月６日に出願された表題が「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＣＯＮＴＲＯＬＬＩＮＧ ＡＣＣＥＳＳ ＴＯ ＤＩＧＩＴＡＬ ＣＯＮＴＥＮＴ， ＩＮＣＬＵＤＩＮＧ ＳＴＲＥＡＭＩＮＧ ＭＥＤＩＡ」の国際特許出願第ＰＣＴ／ＵＳ０１／１８３２４号の一部継続出願である、２００１年１１月５日に出願された表題が「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＣＯＮＴＲＯＬＬＩＮＧ ＡＣＣＥＳＳ ＴＯ ＤＩＧＩＴＡＬ ＣＯＮＴＥＮＴ， ＩＮＣＬＵＤＩＮＧ ＳＴＲＥＡＭＩＮＧ ＭＥＤＩＡ」の国際特許出願第ＰＣＴ／ＵＳ０１／４６７２６号に基づいた、２００３年５月１２日に出願された表題が「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＣＯＮＴＲＯＬＬＩＮＧ ＡＣＣＥＳＳ ＴＯ ＤＩＧＩＴＡＬ ＣＯＮＴＥＮＴ， ＩＮＣＬＵＤＩＮＧ ＳＴＲＥＡＭＩＮＧ ＭＥＤＩＡ」の米国特許出願番号１０／４１６，６２３号の一部継続出願である、２００３年１０月２２日に出願された米国特許出願番号１０／６９２，４４４号の継続出願であり、これらの全ては引用により本明細書に組み込まれる。
【０００２】
本発明は、一般に、デジタルコンテンツへのアクセス制御に関し、より詳細にはストリーミング・メディアへのアクセスを制限するためのチケットベースのシステム及び方法に関する。
【背景技術】
【０００３】
インターネットとワールドワイドウェブの出現に伴い、ストリーミング・メディアコンテンツのようなデジタルコンテンツの配信に関連する産業が発達した。一例として、ストリーミング・メディアは、エンターテイメント、通信教育、及び企業目的を含む多くの目的のいずれかに使用することができる。エンターテイメント企業は、映画及びスポーツイベントをストリーミングし、通信教育企業は教育コンテンツをストリーミングし、企業はトレーニング教材をストリーミングする。
【０００４】
このようなストリーミング・メディアの多くの用途では、コンテンツへのアクセス制御が必要不可欠である。例えば、エンターテイメント企業は、ストリーミング・メディアのアイテムの各視聴に対してエンドユーザに課金することができ、これはエンターテイメント特有の用語で「ペイ・パー・ビュー」と呼ばれる。同様に通信教育企業は、オンライン教育コースへのアクセス、すなわちストリーミング・メディアへのアクセスに対して生徒に課金する。企業コンテンツは社外秘の場合が多いので、従ってこの場合もアクセス制御を必要とする。
【０００５】
従って、ストリーミング・メディアへのアクセスを制限するためのシステムが開発されている。ストリーミング・コンテンツへのアクセスを制限するための最新の業界標準は、ストリーミング・メディアコンテンツを提供する前にストリーミング・メディアサーバのエンドユーザ認証を含む。より詳細には、ストリーミング・メディアサーバは通常、ストリーミング・メディアへのアクセスを許可するかどうかを判断するためのロジックを含むコンパイル済みコードのソフトウエア・プラグインを含む。しかしながら、このような認証プラグインは、複雑であり、開発及び維持するのが困難である場合が多い。例えば、ストリーミング・メディアコンテンツへのアクセスを許可するためのロジックを変更する必要性が生じた場合、ストリーミング・メディアサーバ上のコンパイルされたプラグインを変更するのは困難である。更に、ストリーミング・メディアサーバ上にあるロジックの全ては、ストリーミング・メディアサーバが、データベース又は分散型のメッセージ受け渡しサービスに対し直接アクセスする必要がある。その上、ストリーミング・メディアコンテンツへのアクセスが許可されている特定のエンドユーザを確認する場合においてさえも、このようなエンドユーザは、無許可のエンドユーザとアクセスを共有することによって許可プロセスを免れ得ることが多い。このようなアクセスの共有は、コンテンツに対するリンクのユーザ名及びパスワードの共有も含む多くの形態を取ることができる。デジタルコンテンツの他の形態へのアクセスを制御するために使用されるシステムに関しても同様の問題が存在する。従って、デジタルコンテンツ、特にストリーミング・メディアコンテンツへのアクセスを制御し、エンドユーザを許可するためのシステム及び方法に対する改善の必要性が存在する。
【発明の開示】
【０００６】
本発明は、オーディオ、ビジュアル、ビデオ、テキスト、及びストリーミング・メディアなどのデジタルコンテンツへのアクセスを制御するためのシステム及び方法を提供することによって、前記並びに他の必要性を解決する。本発明による１つのシステム及び方法は、ストリーミング・メディアへのアクセスを制御し、ネットワークに接続されたウェブサーバ、メディアサーバ、及びパーソナルコンピュータなどのエンドユーザプロセッサを含む。
【０００７】
動作中、ウェブサーバは、ファイルにアクセスするためのエンドユーザのリクエストに応答して暗号化されたチケットを生成する。チケットは、少なくとも部分的には、チケットが生成された時間又はその近くの時間に基づいている。ある実施形態ではチケットは、例えばセキュリティタイムインターバル又はエンドユーザの識別子を含む追加情報に基づく。
【０００８】
メディアサーバがリクエストされたファイルへのアクセスを提供する前に、メディアサーバは、好ましくはウェブサーバと同じ暗号化アルゴリズムを使用して許可チケットを生成する。メディアサーバの許可チケットは、メディアサーバがファイルへのアクセスに対するリクエストを受信した時間又はその近くの時間に少なくとも部分的に基づく。メディアサーバは、ウェブサーバによって生成されたチケットをメディアサーバによって生成されたチケットと比較することによって、ファイルに対するアクセスを認可するかどうかを判断する。
【０００９】
１つの実施形態では、チケットが一致しない場合には、ウェブサーバがチケットを生成した時間とメディアサーバがチケットを生成した時間とが予め定められた量よりも大きく異なり、チケットは、論理的に「有効期限切れ」であると考えることができる。従ってメディアサーバは、メディアコンテンツへのアクセスを認可しない。チケットが一致する場合には、チケットは、許可されたタイムインターバルの範囲内に生成されており、メディアサーバは、エンドユーザがリクエストしたメディアコンテンツへアクセスするのを認可する。
【発明を実施するための最良の形態】
【００１０】
ここで、本発明の特定の好ましい実施形態を図面を参照しながら説明する。コンテンツへのアクセスを制御するための本発明は、ストリーミング・データファイルへのアクセス制御の関連で説明されているが、本発明はあらゆるタイプのメディア又はファイルに適用可能である点は理解されたい。更に、本明細書で検討される本実施形態は、オンデマンドのストリーミング・メディアに関するのであるが、ライブのストリーミング・メディアにも適用可能であることは、当業者であれば認識するであろう。
【００１１】
一般に、本実施形態のシステムは、エンドユーザプロセッサ１０２、ストリーミング・メディアサーバ１０４、及びコンテンツマネージメントデータベース１０８を有するウェブサーバ１０６を含み、これらの全てはインターネットに結合されている。エンドユーザプロセッサ１０２は、ＩＮＴＥＲＮＥＴ ＥＸＰＬＯＲＥＲの名称でＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって提供されるか、又はＮＥＴＳＣＡＰＥ ＮＡＶＩＧＡＴＯＲの名称でＡｍｅｒｉｃａ Ｏｎｌｉｎｅ Ｉｎｃ．のＮｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓによって提供されるようなインターネットブラウザ、及びＷＩＮＤＯＷＳ ＭＥＤＩＡ ＰＬＡＹＥＲ（ウィンドウズメディアプレーヤ）の名称でＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって提供されるか、又はＲＥＡＬＰＬＡＹＥＲ（リアルプレーヤ）の名称でＲｅａｌ Ｎｅｔｗｏｒｋｓ，Ｉｎｃにより提供されるようなストリーミング・メディアプレーヤを含む。
ウェブサーバ１０６は、エンドユーザ１０２によってアクセス可能なウェブサイトを提供する。ウェブサイトは、ストリーミング・メディアサーバ１０４上にあるストリーミング・メディアコンテンツにアクセスするためにエンドユーザ１０２が起動することができるリンクを含む。
【００１２】
本発明は、幾つかの何らかのコンピュータ技術を利用して実施できることは理解されたい。例えば、本実施形態は、インターネットを介してコンテンツへのアクセスを提供することに関するが、本発明は、例えばワイドエリアネットワークを含む、どのようなコンピュータネットワーク上でも利用することができる。同様に、エンドユーザプロセッサ１０２は、例えば携帯情報端末、ウェブ対応の携帯電話、ネットワークにダイヤルアップする有線電話、モバイルコンピュータ、パーソナルコンピュータ、インターネット機器及び同様のものを含む、ネットワークに結合可能なあらゆる装置とすることができる。更に、本明細書で説明されるサーバは、何らかのソフトウェアを実行するあらゆるタイプのものとすることができ、本明細書で説明されるソフトウェアモジュール、オブジェクト、及びプラグインは、どのようなプログラム言語で記述されていてもよい。最後に本明細書で説明されるデータベース及び記憶装置は、例えばローカルのコンピュータメモリ、ネットワーク接続記憶装置、及び磁気又は光学などのいずれかの既知の記憶媒体を含む、どのような記憶技術を使用してもよい。
【００１３】
ＣＭデータベース１０８の例示的な表現が図２に示される。図示されているように、データベース１０８は、ストリーミング・コンテンツの全てのアイテムにユニバーサルに適用可能な情報及び関連データの幾つかのテーブルを含む。ユニバーサル情報２０２は、セキュリティキー、セキュリティタイムインターバル、及びコンテンツが存在するストリーミング・メディアサーバ１０４の名称（「ホスト名」）を含む。セキュリティキー及びセキュリティインターバルは、エンドユーザ１０２がコンテンツにアクセスするのを許可する際に使用され、従って、好ましくは秘密に保持されてコンテンツの所有者によって設定される。セキュリティキー及びセキュリティインターバルは、全てのコンテンツへのアクセスを制御するのに使用されるが、別の実施形態では、各コンテンツファイルは、その固有のセキュリティキー及びこれに関連するセキュリティインターバルを有する。
【００１４】
ＣＭデータベース１０８は、コンテンツ又はストリーミング識別情報を含む一連のテーブルを更に含む。より詳細には、ストリーミングテーブル２０４は、一意のストリーミング識別子（ＩＤ）によって識別されたストリーミング・コンテンツの各アイテムのレコードを含む。更に各レコードは、例えば、コンテンツファイルの生成日付を含むコンテンツファイルを記述するストリーミングの詳細、ファイルの記述、コンテンツがオーディオか又はビデオかの識別、コンテンツが関係するプラットフォーム、コンテンツが最後に修正された日付、コンテンツの視聴に必要ないずれかのコーデック、コンテンツの長さ及びサイズ、コンテンツの有効期限（もしあれば）、．ａｓｆ又は．ｒｍなどのストリーミングのタイプ、コンテンツのタイトル、コンテンツの作者、コンテンツのステータス、コンテンツの著作権情報、コンテンツのビットレート、及び同様のものを含む。また各レコードは、メディアサーバ１０４へのリンクを生成するために使用されるプレフィックス（「ＵＲＬＰｒｅｆｉｘ（ＵＲＬプレフィックス）」）と、ストリーミング・メディアサーバ１０４上に格納されているコンテンツファイルの名前（「Ｆｉｌｅｎａｍｅ（ファイル名）」）を含む。ファイル名が、オンデマンドコンテンツのストリーミング・メディアサーバ１０４に結合された記憶装置上の実パスを指してもよく、或いは、ライブストリーミングの別名、ポート、又はチャネルを指してもよいことは理解されるべきである。
【００１５】
データベース１０８はまた、「プレイ（再生）リスト」情報を収容するテーブルを含む。クライアントのプレイリストは、一般に、グループとして利用可能にする目的で論理上関連付けられる１つ又はそれ以上のコンテンツファイルのグループである。プレイリストの一部として識別された各コンテンツファイルはまた、個々に利用可能にすることができる。このようなプレイリスト情報は、プレイリストテーブル２０８及びプレイリストストリーミングテーブル２１０内に収容される。一般に、プレイリストテーブル２０８は、プレイリストＩＤによって識別される各プレイリストを識別するレコードを含む。各レコードは更に、例えばプレイリストのフォーマット（ウインドウズメディアプレーヤ又はリアルプレーヤなど）、プレイリストの記述、プレイリスト名、及び同様のものを含むプレイリストの詳細、及びプレイリストの許可されたユーザグループＩＤを更に含む。
【００１６】
許可されたユーザグループＩＤは、特定のプレイリストを視聴するよう許可されたエンドユーザ１０２のグループに対応する。より詳細には、データベース１０８は更に、一意のエンドユーザＩＤによって識別される各エンドユーザ１０２を１つ又はそれ以上の許可されたユーザグループＩＤに関連付ける許可ユーザテーブル２０６を含む。エンドユーザ１０２がプレイリストを視聴するためには、エンドユーザ１０２は、当該コンテンツファイルに対する許可されたユーザグループＩＤの一部として識別される必要がある。特定の別の実施形態では、許可されたユーザグループＩＤは使用されず、別の代替の実施形態では、各コンテンツファイルがこれらに関連する許可グループＩＤを有する。
【００１７】
プレイリストストリーミングテーブル２１０は、プレイリストＩＤによって識別された各プレイリストをストリーミングＩＤによって識別された構成コンテンツファイルと関連付けるレコードを含む。各レコードはまた、プレイリスト中の各コンテンツファイルの順序（「ソート順序」）を示す情報を収容する。
【００１８】
本発明で使用される構成要素について説明してきたが、ここでストリーミング・メディアコンテンツへのアクセスを制御するプロセスを説明する。概説すると、ウェブサーバ１０６上に配置された認証ソフトウェア構成要素が、公開キー情報、秘密キー情報、及び現在時刻に基づいてハッシュ値又は「チケット」を生成する。公開キーは、エンドユーザとエンドユーザのユーザＩＤによってリクエストされたストリーミング・コンテンツに対する一意の識別子である。秘密キーは、コンテンツの所有者によって設定されたセキュリティキーとセキュリティタイムインターバルとを含む。
【００１９】
リクエストされたコンテンツが存在するストリーミング・メディアサーバ１０４は、公開キーを含むストリーミングのリクエストとウェブサーバ１０６によって生成されたチケットとを受け取る。ストリーミング・メディアサーバ１０４は、ローカルに格納された秘密キー情報を使用して固有形態のチケットの生成に進む。ストリーミング・メディアサーバ１０４は、ストリーミング・メディアサーバ１０４とウェブサーバ１０６によって生成されたチケットの比較に基づいて、リクエストされたストリーミング・コンテンツへのアクセスを拒否するか、又はアクセスを与える。
【００２０】
次に、図３のワークフロー図と図４及び５のフローチャートを参照しながらアクセスを制御するプロセスをより詳細に説明する。本実施例では、エンドユーザ１０２が、単一のストリーミング・メディアコンテンツファイルへのアクセスをリクエストする。最初に、ウェブサーバ１０６は、エンドユーザに許可アプリケーションにログインするようリクエストし、特定のストリーミング・メディアを視聴するオプションをエンドユーザに呈示するウェブページを提供する（ステップ３０２）。例えば、このようなページは、視聴のため各々が固有のストリーミングリクエストのリンクを有する幾つかのコンテンツファイルの１つを選択し、そのエンドユーザＩＤ（コンテンツの所有者が予め割り当ててエンドユーザに提供した）を提供し、更に、選択されたコンテンツへのアクセスに対してエンドユーザに課金することができるようにクレジットカード番号を提供するようエンドユーザにリクエストするフォームを含むことができる。別の実施形態では、エンドユーザは、エンドユーザの連絡先情報及び課金情報を提供することによってコンテンツの所有者に予め登録され、所有者は、割り当てられたエンドユーザＩＤと共にこれらをデータベース内にテーブル形式で格納する。
【００２１】
ウェブページに応答して、エンドユーザは、エンドユーザのユーザＩＤを提供してリンクを起動し、これにより認証アプリケーションにログインし、このリンクに関連する特定のストリーミング・コンテンツファイルへのアクセスをリクエストする（ステップ３０４）。ストリーミングＩＤが「１２３４５６」によって表現される例示的なストリーミングリクエストは、以下の通りである。
＜Ａ ｈｒｅｆ ｈｔｔｐ：／／ｗｅｂｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｇｅｔｓｔｒｅａｍ．ａｓｐ？ＩＤ＝１２３４５６＞
【００２２】
本実施形態では、認証アプリケーションは、ウェブサーバ１０６上に存在する「．ｄｌｌ」ソフトウェア要素である。しかしながら、例えばアクティブ・サーバページ（ＡＳＰ）又はサーブレットなどの他のあらゆるプログラム言語又は技術を使用して本明細書で説明された機能性を実施することができる点を当業者であれば認識するであろう。特定のプログラミング技術に関係なく、認証アプリケーションは、ウェブサーバ上のどのような処理ボトルネックをも軽減するために、ウェブサーバ１０６上で実行させることが好ましい。
【００２３】
エンドユーザが認証アプリケーションにログインし、ウェブサーバ１０６がエンドユーザからストリーミングリクエスト及びエンドユーザＩＤを受け取ると、ウェブサーバ１０６は、続いて許可チケットを動的に生成し、更に、選択されたコンテンツファイルへのリンクを動的に生成する。より詳細には、認証アプリケーションの制御下において、ウェブサーバ１０６は、許可チケットを生成する際に使用するための秘密キーを求めてデータベース１０８にリクエストを出す（ステップ３０６）。ウェブサーバ１０６は、リクエストされたコンテンツファイルに関連するセキュリティキー及びセキュリティインターバルを含む秘密キーをＣＭデータベース１０８から検索するためのデータベースクエリーを発行する。これに応答して、ＣＭデータベース１０８は、秘密キーをウェブサーバ１０６に返送する（ステップ３０８）。
【００２４】
データベース１０８から秘密キーの取得が完了すると、ウェブサーバ１０６はチケットを生成する（ステップ３１０）。図４に関連してより詳細に説明されるように、ウェブサーバ１０６は、秘密キー、ストリーミングＩＤ、エンドユーザＩＤ、現在時刻、及びハッシュアルゴリズムを使用してチケットを生成する。本実施形態では、リクエストされたコンテンツのストリーミングＩＤが、ステップ３０４でエンドユーザによって起動されたストリーミングリクエストリンクに含まれているので、ウェブサーバ１０６は、ストリーミングＩＤを使用してチケットを生成することができる。しかしながら、別の実施形態では、エンドユーザによって提供されるストリーミングリクエストは、ストリーミングＩＤ以外の、例えばコンテンツのタイトル、作者、及び／又はファイル名などの一意の識別情報を含む。このような実施形態では、ウェブサーバ１０６は、ストリーミングテーブル２０４をサーチして、ストリーミングリクエストに含まれる識別情報に基づいてストリーミングＩＤを検索する。更に別の実施形態では、ストリーミングリクエストは、システムがチケットを生成するために使用するファイル名又はパスなどの、ストリーミングＩＤ以外の一意の識別子を含む。
【００２５】
チケットが生成されると、ウェブサーバ１０６は、メディアサーバ上のリクエストされたコンテンツへのリンクを生成する。より詳細には、上記で示された例示的なストリーミングリクエストに基づいて、エンドユーザプロセッサ１０２に存在するメディアプレーヤが「ｗｅｂｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」（すなわちウェブサーバ１０６）を呼び出し、メディアサーバ１０４へのリンクを動的に生成するための「ｇｅｔｓｔｒｅａｍ．ａｓｐ」プログラムを実行することになる（ステップ３１２）。「ｇｅｔｓｔｒｅａｍ」アプリケーションは、アクティブ・サーバページ（すなわちＡＳＰ）拡張子を有するが、必ずしもＡＳＰ技術を使用するとは限らない点を当業者は認識するであろう。むしろ、「．ｄｌｌ」構成要素などの何らかのプログラム又はスクリプト言語若しくは技術を用いて、所望の機能性を提供することができる。しかしながら、認証アプリケーションの場合と同様に、エンドユーザプロセッサ１０２でのあらゆる処理ボトルネックを緩和するためにプログラムはウェブサーバ側で実行されるのが望ましい。「ｇｅｔｓｔｒｅａｍ．ａｓｐ」プログラムは、ウェブサーバ１０６にＣＭデータベース１０８を呼び出させ、メディアサーバ１０４へのリンクを動的に生成するのに必要なデータを検索させるよう機能する。より詳細にはウェブサーバ１０６は、ユニバーサル情報テーブル２０２からホスト名を検索し、ストリーミングテーブル２０４からＵＲＬプリフィックス及びファイル名を検索する。「ｇｅｔｓｔｒｅａｍ．ａｓｐ」プログラムはまた、リンクの最後にストリーミングＩＤ、チケット、及びエンドユーザＩＤを付加する。次いで、ウェブサーバ１０６は、エンドユーザプロセッサ１０２のメディアプレーヤへリンクを返す（ステップ３１４）。
【００２６】
メディアファイルへの例示的なリンクは以下の通りである。
＜ ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍｌ．ａｓｆ？ＩＤ＝１２３４５６＆ＴＩＣＫＥＴ＝ｕｖｗｌ２３ｘｙｚ＆ＵＳＥＲ＿ＩＤ＝ａｂｃｌ２３ｄｅｆ”＞
ここで、ＵＲＬプリフィックスは「ｍｍｓ：／／」によってリクエストされ、ホスト名は「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」で表され、ファイル名は「ｓｔｒｅａｍ１．ａｓｆ」で表され、コンテンツのリクエストアイテムのストリーミングＩＤは「１２３４５６」で表され、チケットは「ｕｖｗ１２３ｘｙｚ」で表され、エンドユーザＩＤは「ａｂｃ１２３ｄｅｆ」で表される。
【００２７】
リンクを受け取ると、エンドユーザプロセッサ１０２は、ストリーミング・メディアコンテンツをリクエストするステップに進む（ステップ３１６）。より詳細には、エンドユーザプロセッサ１０２に存在するメディアプレーヤは、リンクで識別された「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」（すなわちストリーミング・メディアサーバ１０４）を呼び出す。呼び出しの一部として、メディアプレーヤは、リクエストされたコンテンツのストリーミングＩＤのコピー、ウェブサーバ１０６によって生成されたチケット、及びエンドユーザＩＤをストリーミング・メディアサーバ１０４に供給する。
【００２８】
ストリーミングＩＤ、エンドユーザＩＤ、及びチケットを含むリンクを受け取ると、ストリーミング・メディアサーバ１０４は、エンドユーザがリクエストされたコンテンツへアクセスするのを認可するかどうかを判断するステップに進む（ステップ３１８）。図５を参照して以下に更に詳細に説明されるように、ストリーミング・メディアサーバ１０４は、ローカルに格納された秘密キー情報とリンク内に含まれるストリーミングＩＤ並びにエンドユーザＩＤに基づいて独自にチケットを生成することによってアクセスを認可するか否かを判断する。一般に、ストリーミング・メディアサーバ１０４によって生成されたチケットがウェブサーバ１０６によって生成されたチケットと一致する場合、ストリーミング・メディアサーバ１０４は、リクエストされたストリーミング・メディアコンテンツをエンドユーザプロセッサ１０２に供給する（ステップ３２０）。
【００２９】
用語「一致」は、異なる実施形態においては異なる意味を有することができることを理解されたい。一致とは、完全な一致又は予め定められた範囲内での一致を意味することができる。或いは、一致は、あるアルゴリズム又は方程式に基づいて標準偏差だけ互いに異なる２つの値を有することができる。
【００３０】
ここで図４を参照しながら、ウェブサーバ１０６によってチケットを生成するプロセスをより詳細に説明する。上述のようにチケット生成プロセスは、ウェブサーバ１０６に存在する許可ソフトウエア・プラグインによって行われるのが好ましい。本実施形態では、本プロセスは、ウェブサーバ１０６がストリーミングＩＤ及びエンドユーザＩＤを含むストリーミングリクエストを受け取るステップで始まる（ステップ４０２）。次にウェブサーバ１０６は、データベース１０８にアクセスし、リクエストされたストリーミングＩＤに関連する秘密キー情報を検索するステップに進む（ステップ４０６）。このような秘密キー情報は、ユニバーサルセキュリティキー及びセキュリティインターバルを含む。別の実施形態では各ストリーミングは、ストリーミングテーブル２０４にフィールドとして格納された固有のセキュリティキー及びセキュリティインターバルを有し、これをウェブサーバ１０６がストリーミングリクエストに含まれるストリーミングＩＤに基づいて検索する。
【００３１】
上述のようにウェブサーバ１０６はまた、現在時刻を使用してチケットを生成する。より詳細には、ウェブサーバ１０６は、現在時刻を算出し、その時刻をセキュリティインターバルの最も近い倍数にまで切り下げる（ステップ４１０）。本実施形態では、Ｃプログラミング言語の標準ライブラリ関数「ｔｉｍｅ（）」によって生成される協定世界時（ＵＴＣ）を秒単位で利用する。セキュリティインターバル（変数「＄ｔｉｍｅ」で表される）の最も近い倍数に切り下げられた時刻を生成するための例示的なパール（Ｐｅｒｌ）プログラミングコードを以下に示す。
＃
＃ ｅｘａｍｐｌｅ ｏｆ １５ ｍｉｎｕｔｅ ｔｉｃｋｅｔ ｅｘｐｉｒａｔｉｏｎ／ｓｅｃｕｒｉｔｙ ｉｎｔｅｒｖａｌ
＃
＄ｉｎｔｅｒｖａｌ＝１５＊６０
＄ｔｉｍｅ＝ｉｎｔ（ｔｉｍｅ（）／＄ｉｎｔｅｒｖａｌ）＊＄ｉｎｔｅｒｖａｌ；
ここで、変数「＄ｉｎｔｅｒｖａｌ」はセキュリティインターバルに対応し、１５分に等しい。
【００３２】
例証として、現在時刻が中央標準時で２０００年５月３１日午後２：１６：０７であると、関数「ｔｉｍｅ（）」は、およそ「９５９８００５６７」の値を返す。このＵＴＣ値を最も近い１５分インターバルに切り下げると、およそ「９５９８００５００」の値となり、これは、中央標準時で２０００年５月３１日午後２：１５：００の時刻を表す。
【００３３】
上記の例示的なコードは変更してもよく、それでも尚本発明の範囲内とすることができる点は理解されたい。例えば、セキュリティインターバルは分単位である必要はなく、インターバルが「ｔｉｍｅ（）」関数によって使用される時間の単位で表されるように適切な変換が行われる限り、該インターバルは他の時間単位で表してもよい。更に、別の実施形態では、現在時刻はＵＴＣ以外の標準ときに基づく。このような実施形態では、時間標準は、ウェブサーバ１０６及びストリーミング・メディアサーバ１０４に固有のものである。許可チケットを生成する際に使用するために、エンドユーザプロセッサ１０２に時間を計算させてその値をウェブサーバ１０６に渡すことは、本発明の範囲内にある点も理解されたい。更に別の実施形態では、セキュリティインターバルは、標準時間が所望の桁数にまで単に切り捨てられるように選択される。
【００３４】
ウェブサーバ１０６がハッシュアルゴリズムに対する入力値（公開キー情報、秘密キー情報、及び時間値）を有すると、ウェブサーバ１０６は、ハッシュアルゴリズムに対する入力ストリングを生成する（ステップ４１４）。本実施形態では、ハッシュアルゴリズムは「ＭＤ５」メッセージダイジェスト・アルゴリズムである。更に本実施形態では、メディアサーバ１０４及びウェブサーバ１０６は同じアルゴリズムを使用する。
【００３５】
チケットを生成するために基本的にいずれかのハッシュ又は暗号化アルゴリズムを利用することが本発明の範囲内であることは理解されるべきである。更に、チケットを生成する２つのサーバ（上記の実施形態ではウェブサーバ１０６とストリーミング・メディアサーバ１０４）は、同じ入力値に基づいて同じチケットを生成するか、或いは同じ入力値に基づいて互いに既知の偏差値の範囲にあるチケットを生成するのが好ましい。別の実施形態では、セキュリティを向上させるために利用可能な複数のアルゴリズムの１つが使用される。例証として、このような実施形態は、利用可能な複数のアルゴリズムからランダムに選択された１つのアルゴリズムを使用するか、或いは、リクエストされたコンテンツ、リクエストの日付又は時間、特定のエンドユーザ、コンテンツを所有するエンティティ、及び同様のものに基づいて複数のアルゴリズムのうちの１つを選択することができる。このような実施形態では、システムは、メディアサーバに対してウェブサーバによって使用されるアルゴリズムの指示を渡すか、又はメディアサーバが、ウェブサーバによって利用された同じアルゴリズムを選択及び使用させるロジックを含む。
【００３６】
使用される特定のハッシュアルゴリズムに対して入力ストリングが有効である限り、及びストリーミング・メディアサーバ１０４が入力ストリングの配置を認識している限り、入力値のどのような配置も入力ストリングとして使用することができる。本実施形態では、以下の予め定められた配置が使用される。
ＴＴＴＴＴＴＴＴＴＴＫＫＫＫＫＫＫＫＫＫＳＳＳＳＳＳＳＳＳＳＵＵＵＵＵＵＵＵＵＵ
ここで、「Ｔ」は時間値の桁を表し、「Ｋ」はセキュリティキーの英数字を表し、「Ｓ」はストリーミングＩＤ（あらゆる必要な先頭埋め込み文字を含む）の桁を表し、「Ｕ」はエンドユーザＩＤ（あらゆる必要な先頭埋め込み文字を含む）の英数字を表す。別の実施形態では、入力ストリングは異なる長さとすることができる。
【００３７】
ハッシュアルゴリズム入力ストリングが生成されると、ウェブサーバ１０６は、入力ストリングにハッシュアルゴリズムを適用し、これによりチケットを生成する（ステップ４１８）。
【００３８】
ここで図５を参照して、リクエストされたコンテンツストリーミングへのアクセスを認可するかどうかを判断するストリーミング・メディアサーバ１０４のプロセスを検討する。最初に、必ずしも必要ではないが、本実施形態のメディアサーバ１０４は、アクセスを認可するか否かを判断する際に使用するために、各々が異なる時間値に基づいた３つの許可チケットを生成する点に留意されたい。更に、ウェブサーバの機能性と同様、アクセスを認可するか否かを判断するプロセスが、メディアサーバ１０４上に存在する許可ソフトウェア要素において実行されることが望ましい。
【００３９】
アクセスを認可するかどうかを判断する際には、最初に、ストリーミング・メディアサーバ１０４が、エンドユーザプロセッサ１０２上に存在するメディアプレーヤから、ストリーミングＩＤ、エンドユーザＩＤ、及びチケットを含むストリーミングリクエストを受け取る（ステップ５０２）。ストリーミングリクエストが受け取られると、メディアサーバ１０４は、ハッシュアルゴリズムへの入力ストリングを生成する。この点でメディアサーバ１０４は、ローカルのメモリから秘密キー情報、すなわちセキュリティキーとセキュリティインターバルとを検索する（ステップ５０６）。好ましくは、メディアサーバ１０４は、秘密キー情報をローカルのメモリに格納するが、別の実施形態では、メディアサーバ１０４は、例えばＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎにより提供されるライトウェイト・ディレクトリ・アクセス・プロトコル（Ｌｉｇｈｔ−Ｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）によってアクセスされるアクティブディレクトリツリー又は遠隔のデータベースに情報を保存する。更に別の代替の実施形態では、メディアサーバ１０４は、ローカルエリアネットワーク（ＬＡＮ）などのネットワーク接続を介してデータベース１０８にアクセスすることによって秘密キー情報を検索する。
【００４０】
ウェブサーバ１０６が行ったように、メディアサーバ１０４もまた、現在時刻を計算し、その時間をセキュリティインターバルの最も近い倍数（すなわち以前の時間に）にまで切り下げる（ステップ５１０）。しかしながら、ウェブサーバ１０６とは異なり、ストリーミング・メディアサーバ１０４はまた、メディアサーバ１０４によって計算された第１の時間値よりも小さな（すなわち以前の時間の）セキュリティインターバルの次に最も近い倍数にまで切り下げされた現在時刻に等しい第２の時間値を計算する（ステップ５１０）。メディアサーバ１０４は更に、セキュリティインターバルの最も近い倍数にまで切り上げされた現在時刻（すなわちより遅い時間）に等しい第３の時間値を計算する（ステップ５１０）。
【００４１】
次いで、メディアサーバ１０４は、検索された秘密キー情報、受け取られた公開キー情報、及び３つの時間値を使用して、３つの対応するハッシュ入力ストリングを生成する（ステップ５１４）。次に、メディアサーバ１０４は、３つの入力ストリングの各々にハッシュアルゴリズムを適用し、これにより３つのチケットを生成する（ステップ５１８）。
【００４２】
独自のチケットを生成した後、次にメディアサーバ１０４は、メディアサーバ１０４によって生成されたチケットのいずれかがウェブサーバ１０６によって生成されたチケットと一致するかどうかを判断する（ステップ５２２）。チケットが一致しない場合、ストリーミングリクエストは認証されたものではなく、及び／又は有効期限が切れたものである（すなわち、ユーザのリクエスト時間から測定されるセキュリティインターバルを越えた時間にメディアサーバ１０４によって生成されたもの）可能性が高い。従って、メディアサーバ１０４は、リクエストされたコンテンツへのアクセスを拒否する（ステップ５２６）。
【００４３】
チケットが一致する場合、ストリーミングリクエストは認証されたものであり、セキュリティインターバルの範囲内にある可能性が高い。しかしながら、アクセスを認可する前に、メディアサーバ１０４は最初に、エンドユーザが同じコンテンツへのアクセスをリクエストして、既に視聴したかどうかを判断する（ステップ５３０）。メディアサーバ１０４は、エンドユーザＩＤのリストと該エンドユーザが既にアクセスを認可されている対応するストリーミングＩＤとをローカルメモリ内に保持するのが好ましい。リクエストされたコンテンツをエンドユーザが既に視聴したかどうかを判断するために、メディアサーバ１０４は、メモリにアクセスして、受け取ったエンドユーザＩＤ及びストリーミングＩＤが以前に格納されているかどうかを判断する。エンドユーザＩＤ及びストリーミングＩＤが既に格納されている場合には、エンドユーザは、リクエストされたコンテンツへのアクセスが拒否される（ステップ５３０）。
【００４４】
受け取ったエンドユーザＩＤ及びストリーミングＩＤが、これまで格納されていない場合には、メディアサーバ１０４は、エンドユーザＩＤ及びストリーミングＩＤをメモリに格納するステップに進み（ステップ５３４）、エンドユーザにコンテンツへのアクセスを与える（ステップ５３８）。従って、エンドユーザＩＤ及びストリーミングＩＤを格納することにより、リクエストされたコンテンツを指すリンクをエンドユーザが他者と共有するのを防ぐ任意の追加レベルのセキュリティ保護が得られる。
【００４５】
ウェブサーバ１０６のローカル時間とメディアサーバ１０４のローカル時間との間が同期されていないことを考慮に入れるために、３つのチケットを使用することが望ましい点は理解されるべきである。更に、ある状況では、メディアサーバ１０４によって生成された第１のチケット（すなわち、セキュリティインターバルの最も近い倍数にまで切り下げられた現在時刻に基づく）は、エンドユーザが許可されている場合でも、ウェブサーバ１０６によって生成された第１のチケットと一致しないことになる。例えば、セキュリティインターバルを１５分とすると、ウェブサーバ１０６が午後１２：１４：００にチケットを生成し、メディアサーバ１０４がその第１のチケットを午後１２：１６：００に生成する場合、同じ日の時間帯においてリクエストがセキュリティインターバルの範囲内にあってもチケットは一致しないことになる。ウェブサーバは、午後１２：００：００に対応する時間値に基づいてチケットを生成し、一方、メディアサーバ１０４は、午後１２：１５分：００に対応する時間値に基づいてチケットを生成することになる。従って、本実施形態では、メディアサーバ１０４は、セキュリティインターバルの次に最も近い倍数に切り下げられたそのときの現在時刻に基づいて第２のチケットを生成し、すなわち本実施例では、午後１２：００：００に対応する。従って、第２のチケットは、ウェブサーバ１０６によって生成されるチケットと一致するであろう。同様に、セキュリティインターバルが経過した後、エンドユーザに対しアクセスを認可することが可能である。従って、本実施形態では、セキュリティインターバルは複数のチケットの使用を考慮するように選択されるべきである。ウェブサーバ１０６とメディアサーバ１０４は、セキュリティインターバルの約半分以内に時刻同期するのが望ましい。
【００４６】
メディアサーバ１０４が、上記の実施形態で３つのチケットの代替として１つ又はそれ以上の異なるチケットを生成することもまた本発明の範囲内である点を理解すべきである。更に上記の実施形態では、チケットが共に並列に生成されるものとして説明しているが、メディアサーバ１０４がチケットを順に連続して生成及び／又は比較することも本発明の範囲内である。更に、時間値は、例えばメディアサーバ１０４によって計算された第１の時間値からセキュリティインターバルを単に加減算することを含め、多くの方法のいずれかで生成することができる点も理解されるべきである。
【００４７】
別の実施形態では、別のレベルのセキュリティを提供してもよい。より詳細には、ウェブサーバ１０６によって生成されたチケットが、メディアサーバ１０４によって生成されたチケットのうちの１つと一致する場合、メディアサーバ１０４は、同じチケットが既に生成されていたかどうかを判断するステップに進む。メディアサーバ１０４は、アクセスが許可されたチケットのリストを保持している。このようなリストは、論理上、全ての「使用済み」チケットを表す。一致したチケットが「使用済み」チケットのリストに存在しない場合には、メディアサーバ１０４は、アクセスを認可し、エンドユーザプロセッサ１０２上に存在するメディアプレーヤにリクエストされたコンテンツを供給する。アクセスを認可するステップの一部として、メディアサーバ１０４はまた、「使用済み」チケットのリスティングを更新する。一致したチケットが使用済みチケットのリストに存在する場合には、メディアサーバ１０４はアクセスを拒否し、リクエストしているエンドユーザに適切なメッセージを供給する。使用済みチケットを追跡することによって、システムは、許可されたエンドユーザがウェブサーバ１０６から受け取ったストリーミングリクエストを他者と共有するのを防止する。
【００４８】
更に、アクセスを認可するかどうかを判断する際にエラー計算を使用することも本発明の範囲内である点を理解されたい。例えば１つのエラー計算は、例えば、予め定められた時間期間（例えば１５分、３０分など）、適用可能なセキュリティインターバルの設定百分率（例えば５０％、１２５％など）、又は他のエラー計算などのエラーインターバルに現在時刻を加算及び／又は減算した値に基づいて、メディアサーバ１０４が１つ又はそれ以上の追加チケットを生成するステップを含む。このようなエラー計算は、上記の実施形態において第２又は第３の時間値に対する代替値として、或いはこれに加えて使用することができる。
【００４９】
別の実施形態では、ウェブサーバ１０６及びメディアサーバ１０４は、上記の実施形態とは異なる方法で時間値を計算することによってチケットを生成する。１つの例示的な実施形態では、ウェブサーバ１０６及びメディアサーバ１０４は、現在時刻を計算し、これをセキュリティインターバル以外の或るインターバルの倍数に切り下げ又は切り上げる。セキュリティインターバルが１５分であるこうした１つの実施形態では、ウェブサーバ１０６は、５分の最も近いインターバルに切り下げられた現在時刻に基づいてチケットを生成する。次に、ストリーミング・メディアサーバ１０４は、同じ５分のインターバルに切り下げられた現在時刻に基づいてチケットを生成する。チケットが一致しない場合、メディアサーバ１０４は、次に古いインターバルに切り下げされた時間に基づいてチケットを生成するステップに進む。メディアサーバは、設定された回数又はウェブサーバとメディアサーバのチケットが一致するまで、次に古いインターバルに基づいてチケットを生成し続ける。好適には、メディアサーバ１０４は、合計が少なくともセキュリティインターバルに及ぶタイムインターバルに基づいて繰り返し新しいチケットを生成する。本実施例ではメディアサーバ１０４は、各５分の合計１５分のインターバルで少なくとも３つのチケットを生成する。
【００５０】
許可プロセスにおいてエンドユーザＩＤの使用を完全に省略すること、或いはエンドユーザＩＤを上述の方法とは異なる方法で使用することは、本発明の範囲内にある点は理解すべきである。例えば、別の実施形態では、エンドユーザＩＤは、ハッシュアルゴリズムに対する入力ストリングの一部としては使用されない。その代わり、データベース１０８は、どのエンドユーザがコンテンツへのアクセスをリクエストしたかを追跡するテーブルを含む。このような実施形態は、ストリーミングＩＤによって識別されるコンテンツを、エンドユーザＩＤによって識別され、該コンテンツストリーミングに既にアクセス又は視聴したエンドユーザと関連付けるレコードを含む視聴ユーザ（ストリーミング）テーブルを含む。同様に本実施形態は、プレイリストＩＤによって識別されるプレイリストを、エンドユーザＩＤによって識別され、該プレイリストに既にアクセス又は視聴したエンドユーザと関連付けるレコードを含む視聴ユーザ（プレイリスト）テーブルを含む。許可チケットを生成する前に、ウェブサーバは、適切な視聴ユーザテーブルをチェックし、同じエンドユーザが特定のストリーミング又はプレイリストへのアクセスをリクエストしたかどうかを判断する。エンドユーザが既にアクセスをリクエストしていた場合、ウェブサーバは、アクセスを拒否するか、或いはエンドユーザに対して、これ以後のアクセスに対しては再度課金されることをエンドユーザに示すウェブページを供給する。テーブルは、セキュリティインターバルなどの時間期間又はこれを超える或る期間の後に自動的にクリアされる。
【００５１】
本発明はまた、例えば、コンテンツの所有者であるクライアントの代わりに、サービスプロバイダがウェブサーバ、ストリーミング・メディアサーバ、及びプレイリストサーバを操作する比較的より複雑なシステムにおいて具現化することができる点を理解すべきである。このような１つの実施形態を次に図６−８を参照しながら説明する。本実施形態の機能性の大部分が、図３の実施形態の機能性と同じであり、従って同じ技術のどれによっても実施することができる点は当業者には理解されるであろう。
【００５２】
図６に示されるように、本システムは、図１の実施形態の構成要素と類似の幾つかの構成要素を含み、エンドユーザプロセッサ６０２、１つ又はそれ以上のストリーミング・メディアサーバ６０４、及びデータベース６０８を含む１つ又はそれ以上のウェブサーバ６０６を含み、これらの全てはインターネット又は他のネットワークに結合される。加えて、本実施形態のシステムは、サービスプロバイダによって同様に動作されるプレイリストサーバ６１０も含む。好適には、ウェブサーバ６０６、データベース６０８を含むストリーミング・メディアサーバ６０４、プレイリストサーバ６１０は、ローカルエリアネットワーク（ＬＡＮ）又はワイドエリアネットワーク（ＷＡＮ）などのサービスプロバイダのネットワーク、並びにインターネットに接続される。
【００５３】
一般に、データベース６０８は、図２の実施形態のデータベース内に収容されている同じ情報を含むが、該情報はクライアントのアカウント毎に格納される。図７に示されるように、データベース６０８は、アカウントＩＤによって識別される各クライアントのレコードを含むアカウントテーブル７０２を含む。各レコードは更に、クライアント名、アドレス、請求書発行情報及び同様のものなどのクライアント識別情報（「クライアント情報」）、クライアントのコンテンツが保護されているかどうかに関する表示（「保護許可」）、クライアントのセキュリティキー（「セキュリティキー）、及びセキュリティインターバル（「セキュリティインターバル」）を含む。
【００５４】
図２の実施形態と同様に本データベース６０８はまた、ストリーミングＩＤによって識別される各コンテンツファイルのストリーミング識別情報を含むストリーミングテーブル７０４と、エンドユーザＩＤを許可されたグループＩＤに関連付ける許可ユーザテーブル７０６と、プレイリストＩＤによって識別される各プレイリスト用のプレイリスト識別情報を含むプレイリストテーブル７０８と、所定のプレイリストＩＤに関連付けられたストリーミングＩＤを識別するプレイリストストリーミングテーブル７１０とを含む。図２のデータベースに関連して説明された情報フィールドに加えて、本ストリーミングテーブル７０４及びプレイリストストリーミングテーブル７０８は更に、各コンテンツファイル及び各プレイリストとそれぞれ関連付けられたアカウントＩＤを識別するフィールドを含む。
【００５５】
本データベース６０８はまた、ストリーミングサーバテーブル７１２を含み、該テーブルは、ストリーミングＩＤによって指定される各コンテンツファイルのレコードを含み、コンテンツファイルが存在する特定のストリーミング・メディアサーバ１０４のホスト名を識別する。図２の実施形態と同様、ホスト名はメディアサーバ１０４のＤＮＳ名である。
【００５６】
ここで、本実施形態の動作を図８のワークフロー図に関連して説明する。本実施例の目的のために、エンドユーザは、保護コンテンツの１つのアイテムを有するプレイリストへのアクセスをリクエストする。最初に、ウェブサーバ６０６は、エンドユーザに対し許可アプリケーションにログインすることをリクエスし、特定のストリーミング・メディアを視聴するオプションをエンドユーザに呈示するウェブページを提供する（ステップ８０２）。図３の実施形態と同様に、例示的なウェブページは、リンクを起動することによって特定のコンテンツファイルを選択し、エンドユーザＩＤを提供し、及び請求書発行情報を提供することをエンドユーザにリクエストするフォームを含むことができる。ウェブページに応答して、エンドユーザは、エンドユーザＩＤ及びクレジットカード情報を提供し、ストリーミングリクエストリンクを起動し、これにより特定のストリーミング・メディアコンテンツファイルへのアクセスをリクエストする。プレイリストＩＤが「７８９０００」の場合の例示的なストリーミングリクエストリンクは以下の通りである。
＜Ａ ｈｒｅｆ”ｈｔｔｐ：／／ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｍａｌｃｅｐｌａｙｌｉｓｔ．ｄｌｌ？ＩＤ＝７８９０００”＞
【００５７】
エンドユーザが、ストリーミングリクエストリンクを起動すると、エンドユーザプロセッサ６０２上で実行されるプログラミングスクリプトによって、ストリーミングリクエストリンク及びエンドユーザＩＤがウェブサーバ６０６に送られることになる（ステップ８０４）。当業者は、本質的に、例えばＣ＋＋、パール（Ｐｅｒｌ）、ビジュアルベーシック、ジャバ（Ｊａｖａ）及び同様のものを含むどのようなプログラム言語でもエンドユーザのスクリプトを実行することができる点を認識するであろう。本実施形態では、スクリプトはＪａｖａスクリプトであり、エンドユーザのウェブブラウザと連動して実行される。
【００５８】
ウェブサーバ６０６がスクリプトからストリーミングリクエストを受け取ると、ウェブサーバ６０６は、許可ソフトウエア・プラグインの指示の下でチケットを生成する。この件に関して、ウェブサーバ６０６は、データベース６０８に対して許可チケットの生成の際に使用する秘密キー（本実施形態では、リクエストされたプレイリストに関連するセキュリティキーとセキュリティインターバル）のリクエストを発行する（ステップ８０８）。これに応答して、データベース６０８はウェブサーバ６０６に秘密キーを返す（ステップ８０８）。
【００５９】
データベース６０８から秘密キーを取得した後、ウェブサーバ６０６は、ストリーミングされたものではなくプレイリストＩＤ（本実施形態ではプレイリストＩＤで置き換える）を使用して、図４に関連して前述されたようにチケットを生成する（ステップ８１０）。上述のように、ウェブサーバ６０６は、秘密キー、ストリーミングＩＤ、エンドユーザＩＤ、及び時間値をハッシュアルゴリズムに適用してチケットを生成する。次いで、ウェブサーバ６０６は、エンドユーザプロセッサ６０２上で実行されるウェブブラウザにチケットとエンドユーザＩＤを返す（ステップ８１２）。
【００６０】
チケットを受け取った後、エンドユーザプロセッサ６０２上で実行されるスクリプトは、ストリーミングリクエストリンクの最後に情報を付加する（ステップ８１４）。例示的なリンクは以下に示される。
＜Ａ ｈｒｅｆ”ｈｔｔｐ：／／ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ． ｃｏｍ／ｍａｋｅｐｌａｙｌｉｓｔ？ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｕｖｗ１２３ｘｙｚｒｅｔｕｍ＆ＵＳＥＲ＿ＩＤ＝ａｂｃｌ２３ｄｅｆ”＞
ここで、プレイリストＩＤは「７８９０００」で表され、チケットは「ｕｖｗ１２３ｘｙｚ」で表され、エンドユーザＩＤは「ａｂｃ１２３ｄｅｆ」で表される。
【００６１】
次いで、エンドユーザプロセッサ６０２上で実行されるスクリプトにより、ホスト名「ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」によってストリーミングリクエストリンクで識別されるプレイリストサーバ６１０が呼び出される（ステップ８１６）。従って、プレイリストサーバ８１０は、リンク、プレイリストＩＤ、チケット、及びユーザＩＤが提供される。「ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ」オブジェクトの制御下で、プレイリストサーバ６１０は、コンテンツがウインドウズメディア・フォーマットであるＡＳＸファイルなどのリダイレクタファイルを生成する（ステップ８１８）。「ｍａｋｅｐｌａｙｌｉｓｔ」プログラムは、例えばＡＳＰを含む幾つかのプログラム又は技術のいずれかを使用して実行することができる。リダイレクタファイルは、チケット及び公開キー（すなわちストリーミングＩＤ及びエンドユーザＩＤ）と共にリクエストされたコンテンツへのリンクを含む。リダイレクタファイルを生成するために、プレイリストサーバ６１０はデータベース６０８にアクセスし、プレイリストと、ストリーミングＩＤに関連付けられたホスト名、ＵＲＬプレフィックス、及びファイル名を含むコンテンツファイルへのリンクに必要とされる情報とを含むコンテンツファイルのストリーミングＩＤを検索する。
【００６２】
別の実施形態では、ストリーミングリクエストにチケットを付加するためにエンドユーザのスクリプトは使用されない。その代わりに、エンドユーザが、エンドユーザＩＤを提供してストリーミングリクエストリンクを起動する（ステップ８０４で）ときに、ウェブサーバ６０６上で実行される認証アプリケーションがチケットを生成し、該チケットとエンドユーザＩＤとをストリーミングリクエストリンクに付加し、プレイリストサーバ６１０を直接呼び出してリダイレクタファイルを生成する。ウェブサーバ６０６はまた、エンドユーザプロセッサ６０２上のメディアプレーヤを識別する情報をプレイリストサーバ６１０に渡すので、プレイリストサーバ６１０は、メディアプレーヤにリダイレクタファイルを転送する（これによりステップ８１２、８１４、及び８１６が不要になる）。このような実施形態を図１０を参照して以下に説明する。
【００６３】
次に、プレイリストサーバ６１０は、エンドユーザプロセッサ６０２でメディアプレーヤにＡＳＸリダイレクタファイルを渡す（ステップ８２０）。本実施例の目的のために、ＡＳＸファイルは以下のように表される。
＜ＡＳＸ＞
＜ＥＮＴＲＹ＞
＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍｌ．ａｓｆ？ＩＤ＝１２３４５６＆ＴＩＣＫＥＴ＝ｕｖｗｌ２３ｘｙｚ＆ＵＳＥＲ＿ＩＤ＝ａｂｃｌ２３ｄｅｆ”＞
＜／ＥＮＴＲＹ＞
＜／ＡＳＸ＞
ここで、ＵＲＬプレフィックスが「ｍｍｓ：／／」で表され、適切なメディアサーバ６０４のホスト名が「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」で表され、ファイル名が「ｓｔｒｅａｍ１．ａｓｆ」で表され、コンテンツストリーミングＩＤのリクエストされたアイテムが「１２３４５６」で表され、チケットが「ｕｖｗ１２３ｘｙｚ」で表され、エンドユーザＩＤが「ａｂｃ１２３ｄｅｆ」で表される。
【００６４】
リダイレクタファイルは、コンテンツファイル用のメタデータなどの他の情報、或いは広告などの保護されていない他のファイルを含むことができる。
【００６５】
ＡＳＸファイルを受け取った後、エンドユーザプロセッサ６０２は、ストリーミング・メディアコンテンツをリクエストするステップに進む。より詳細にはメディアプレーヤは、ＡＳＸファイルで識別された「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」（すなわちストリーミング・メディアサーバ６０４）を呼び出す（ステップ８２２）。呼び出しされると、メディアプレーヤは、リクエストされたコンテンツのストリーミングＩＤのコピー、ウェブサーバ６０４によって生成されたチケット、及びエンドユーザＩＤをストリーミング・メディアサーバ６０４に提供する。
【００６６】
メディアプレーヤの呼び出しに応答して、ストリーミング・メディアサーバ６０４は、リクエストされたコンテンツへのエンドユーザのアクセスを認可するかどうかを判断するステップに進む（ステップ８２４）。ストリーミング・メディアサーバ６０４は、１つ又はそれ以上の認証チケットを独自に生成し、そのチケットをウェブサーバ６０６によって生成されたチケットと比較することによってアクセスを認可するかどうかを判断をする。許可チケットの生成及び比較プロセスは、ストリーミングＩＤではなくプレイリストＩＤを使用して、図５に関連して説明された同じ方法で行われる。メディアサーバ６０４によって生成されたチケットが、ウェブサーバ６０６によって生成されたチケットと一致する場合には、メディアサーバ６０４は、エンドユーザにリクエストされたコンテンツへのアクセスを認可する（ステップ８２４）。
【００６７】
上記の実施形態は、保護されたコンテンツへの無許可のアクセスに対して該コンテンツの所有者に十分なレベルの保護をもたらすことが理解されると同ときに、更に高いレベルの保護を実装することも可能である。１つのこのような更に高いレベルの保護は、特定のエンドユーザが所与の任意の時間にアクセスできるコンテンツファイル数を制限することを含む。別のレベルの保護は、特定のユーザが保護されたコンテンツにアクセスするのに使用できる異なるプロセッサ（例えばコンピュータ）の数を制限する。上述の実施形態のいずれもこのような更に高いレベルの保護を含むように修正することができ、ここで図９と１０に関連して更に高い保護の実施を説明する。
【００６８】
図９の概略図で分かるように、本実施形態は、図６−８に示され関連して説明された実施形態に基づく。上述のように、一般にコンテンツ配信及び認証システムは、ウェブサーバ６０６、データベース６０８、及びプレイリストサーバ６１０を含む。更に、必ずしも必要ではないが、本システムは、複数のストリーミング・メディアサーバ６０４−１、６０４−２、６０４−ｎ（総称して６０４と称する）を含み、その各々がサーバＩＤによって識別され、保護されたコンテンツを収容している。好適には、ストリーミング・メディアサーバ６０４は各々、同じストリーミング・コンテンツのコピーを収容し、システムは、ラウンドロビン又は他の負荷バランス手法を使用することにより複数のストリーミング・メディアサーバ上の負荷バランスを取る。データベース６０８は、格納されるサーバＩＤと各コンテンツファイルを関連付ける。以下の説明に基づいて理解されるように、本実施形態は、異なるメディアサーバ上の同じコンテンツファイルへのアクセスが許可された別のユーザからアクセス情報を受け取ることによって、無許可のエンドユーザが特定のメディアサーバ上のコンテンツファイルにアクセスすることを防止するので、複数のストリーミング・メディアサーバと共に使用するのに特に好適である。図９に示されるように、上述の構成要素は、保護されたネットワークを介して互いに通信するのが好ましいが、しかしながら、別の実施形態では、グローバルキャッシュ・サーバ９０２は、ストリーミング・メディアサーバ６０４とだけ直接接続され、ビジネスサーバ９０４は、グローバルキャッシュ・サーバ９０２とだけ直接接続されている。上述の実施形態と同様、エンドユーザは、インターネット又は他のネットワークに結合されたエンドユーザプロセッサ６０２−１、６０２−２、６０２−ｍ（総称して６０２と称する）を介して保護されたコンテンツにアクセスする。
【００６９】
一般に、グローバルキャッシュ・サーバ９０２は、ストリーミング・メディアサーバ６０４に対する各エンドユーザの接続に関する接続情報をキャッシュし、エンドユーザＩＤに基づいて高いレベルの認証保護を提供する。接続情報は、キャッシュ又はデータベースなどのローカルのデータ記憶装置、又はデータベース６０８などの遠隔の記憶装置に格納される。以下でより詳細に説明されるように、各ストリーミング・メディアサーバ６０４は、当該ストリーミング・メディアサーバ６０４を許可した各エンドユーザのアクセスに対してグローバルキャッシュ・サーバ９０２に接続情報を転送する。本実施形態では、接続情報は、エンドユーザＩＤ、各エンドユーザのメディアプレーヤのグローバル固有ＩＤ（ＧＵＩＤ）、エンドユーザがアクセスを許可されたストリーミング・コンテンツのフォーマット（例えばウインドウズメディアプレーヤ又はリアルプレーヤフォーマット）、エンドユーザによってアクセスされるコンテンツが存在するサーバのＩＤ、及びエンドユーザがリクエストされコンテンツにアクセスしている特定のエンドユーザプロセッサ６０２の識別子（「ｐｐｖスロット」と称される）を含む。周知のように、メディアプレーヤのプロバイダは、一般に各メディアプレーヤにＧＵＩＤを割り当ててメディアプレーヤを識別する。
【００７０】
各エンドユーザは、該エンドユーザがコンテンツにアクセスすることができる幾つかのエンドユーザプロセッサ６０２を論理的に割り当てられる。本実施例では各エンドユーザは、最大３つの異なるエンドユーザプロセッサ６０２からコンテンツにアクセスすることができる。３つの異なるプロセッサは、例えば、エンドユーザの家庭用コンピュータ、業務用コンピュータ、及びモバイルコンピュータ、ウェブ対応の携帯電話、若しくはウェブ対応の携帯情報端末（ＰＤＡ）のいずれかとすることができる。更に、３つのプロセッサ６０２の各々に対し、エンドユーザは、システムによってサポートされている各メディアフォーマット毎に複数のメディアプレーヤを有することができる。本実施形態では、ウインドウズメディアプレーヤ又はリアルプレーヤフォーマットがサポートされる。従って、本実施形態では、各エンドユーザは、３つまでの異なるｐｐｖスロット値だけを有することができ、各ｐｐｖスロット値に対して、エンドユーザは、各タイプのフォーマットのメディアプレーヤ毎に２つのＧＵＩＤを有することができる。
【００７１】
本実施形態では、特定のエンドユーザプロセッサ６０２のｐｐｖスロット値は、当該プロセッサのクッキーＩＤである。一般に、クッキーは、エンドユーザが特定のエンドユーザプロセッサ６０２を介してシステムウェブサイトを最初に訪れたときに、ウェブサーバ６０６がエンドユーザのブラウザに対して付与するデータのセットである。ウェブサーバ６０６は、クッキーが含むエンドユーザに関する情報を保存し、エンドユーザのブラウザは、通常、エンドユーザプロセッサ６０２上のブラウザのシステムフォルダ内に格納されるテキストファイルとしてクッキーを格納する。ユーザのプロセッサ６０２がクッキーを受け入れない場合には、アプリケーションは、ユーザに対してオプションを変更するようにリクエストする応答を生成することになる。
【００７２】
本実施形態では、ｐｐｖスロット情報は、データベース６０８内のトランザクションテーブルに格納される。一般に、トランザクションテーブルは、エンドユーザを特定のストリーミング・メディアイベント及びそのイベントの３つのｐｐｖスロットと関連付ける。この目的のために、トランザクションテーブルは、以下のフィールド、すなわち、エンドユーザＩＤ、イベントＩＤ（所与のメディアイベントを一意的に識別する）、ストリーミングＩＤ、イベントに対するエンドユーザのアクセスの日付、第１のｐｐｖスロット値、第１のｐｐｖスロットのＧＵＩＤ、第２のｐｐｖスロット値、第２のｐｐｖスロットのＧＵＩＤ、第３のｐｐｖスロット値、第３のｐｐｖスロット値のＧＵＩＤを含む。本明細書の説明に基づいて、エンドユーザ及びｐｐｖスロット情報を特定のイベントと関連付けることを利用して、１つのイベントにつき各エンドユーザに対しエンドユーザプロセッサ６０２を３つ以下に制約することができ、一方、トランザクション・データベースがエンドユーザを単にｐｐｖスロット情報に関連付けている（イベント毎ではなく全イベントにわたって）別の実施形態では、各ユーザを全イベントにわたって３つのエンドユーザプロセッサ６０２までに制約することができる点は理解されるであろう。
【００７３】
以下により詳細に説明されるように、ビジネスサーバ９０４は、ｐｐｖスロット値を含む接続情報の全て又は一部をグローバルキャッシュ・サーバ９０２から受け取る。グローバルキャッシュ・サーバ９０２と同様、ビジネスサーバ９０４は、ローカル又は遠隔のデータ記憶装置を含み、各固有のセットの接続情報についての別個のレコードをデータベース内に格納する。接続情報に基づいて、ビジネスサーバ９０４上に存在する許可アプリケーションは、エンドユーザのアクセスを３つ以下のエンドユーザプロセッサ６０２に制限し、該３つのエンドユーザプロセッサ６０２の各々について単一のメディアプレーヤに制限する。許可されるエンドユーザプロセッサ６０２の数（従ってｐｐｖスロット値の数）は、ビジネスサーバ９０４の許可アプリケーションにおいて構成変更可能である。
【００７４】
本実施形態に関連して説明された更に高いレベルの保護は、上述の実施形態の認証システム及び方法と共に利用することができるが、本実施形態に関連して説明された更に高いレベルの保護の１つ又はそれ以上のいずれかは、認証メカニズム単独で実施してもよく、或いは、本明細書で上記に説明された以外の認証メカニズムと共に実施してもよい点は理解されるであろう。従ってここで、単なる例証として、更に高いレベルの保護を図１０のワークフロー図を参照して説明する。
【００７５】
最初にウェブサーバ６０６は、サービスへの登録と許可アプリケーションへのログインをエンドユーザにリクエストするウェブページを該エンドユーザに供給する。ウェブページはまた、各々が別個のストリーミングリクエストリンクを有する多くのストリーミングメディアファイルの１つを視聴するオプションをエンドユーザに呈示する（ステップ１００２）。これに応答して、エンドユーザは、エンドユーザＩＤを提供し、ウェブページ上の所望のストリーミングリクエストリンクを起動して、これにより特定のストリーミング・メディアコンテンツファイルへのアクセスをリクエストする。エンドユーザはまた、クレジットカード番号などの支払い情報又は他のアカウント情報を提供することができる。上記の実施形態と同様、エンドユーザＩＤの提供並びにストリーミングリクエストリンクの起動は、単一のステップ又は別個のステップとして行うことができる。エンドユーザがログインするときには、Ｊａｖａスクリプト又は他のスクリプト若しくは構成要素などのウェブサーバ６０６上で実行される認証アプリケーションは、エンドユーザがこれまでにそのシステムにログインしたことを示すｐｐｖスロットクッキーについてエンドユーザプロセッサ６０２をチェックする。クッキーが存在しない場合には、ウェブサーバ６０６は、特定のエンドユーザプロセッサ６０２にクッキーを割り当て、これをエンドユーザプロセッサ６０２上に格納し、これによってプロセッサ６０２を識別する。ストリーミングリクエストリンクを起動することによって、ストリーミングリクエストリンクとエンドユーザＩＤは、ウェブサーバ６０６に伝達される（ステップ１００４）。
【００７６】
エンドユーザがシステムにログインし、コンテンツへのアクセスをリクエストするときには、ウェブサーバ６０６の認証アプリケーションは、エンドユーザが割り当てられた３つのｐｐｖスロットを超えているかどうかを判断し、超えていない場合には、トランザクションテーブルを更新する（ステップ１０１０ａ）。この点において、ウェブサーバ６０６は、エンドユーザがシステムにログインしたときに割り当てられたクッキーＩＤを、特定のエンドユーザ（エンドユーザＩＤによって識別された）及びイベント（イベントＩＤによって識別された）に関するトランザクションテーブル内の全てのｐｐｖスロット値と比較する。トランザクションテーブルが既に３つのｐｐｖスロット値を含み、受け取ったクッキーＩＤが、既存の３つのｐｐｖスロット値のどれとも一致しない場合には、エンドユーザは、第４のプロセッサから許可されていないアクセスを試みたものとみなされ、このアクセスは拒否される。
【００７７】
トランザクションテーブルが、そのイベントのエンドユーザに対して３つより少ないｐｐｖスロット値を含む場合には、ウェブサーバ６０６は、トランザクションテーブル内にレコードを作成する。より具体的には、ウェブサーバ６０６は、エンドユーザＩＤ、イベントＩＤ（エンドユーザによって購入されたコンテンツに以前に割り当てられた）、購入されたコンテンツのストリーミングＩＤ（ストリーミングリクエストリンクのプレイリストＩＤに対応するものとして、データベース６０８からウェブサーバ６０６が検出する）、日付、及びｐｐｖスロット値を使用してレコードを作成する。
【００７８】
エンドユーザが、ｐｐｖスロット情報に基づいてアクセスが拒否されない場合には、ストリーミングリクエストリンク及びエンドユーザＩＤを受け取ると、ウェブサーバ６０６上で実行される認証アプリケーションは、データベース６０８にアクセスし（ステップ１００６）、該データベース６０８から秘密キー情報を受け取り（ステップ１００８）、チケットを生成して、チケット、エンドユーザＩＤ、及びｐｐｖスロット値をストリーミングリクエストリンクに付加する（ステップ１０１０ｂ）。次いで、ウェブサーバ６０６上で実行される認証アプリケーションは、付加されたチケット、エンドユーザＩＤ、及びｐｐｖスロット値を含むストリーミングリクエストリンクをプレイリストサーバ６１０に渡す（ステップ１０１２）。
【００７９】
プレイリストサーバ６１０が、ストリーミングリクエストリンク、チケット、エンドユーザＩＤ、及びｐｐｖスロット値を受け取ると、プレイリストサーバ６１０は、リダイレクタファイルを生成するステップに進む。上述のように、リダイレクタファイルを生成するために、プレイリストサーバ６１０は、データベース６０８にアクセスし（ステップ１０１４）、プレイリスト、並びにその全てが特定のストリーミングＩＤと対応付けられた、ホスト名、ＵＲＬプレフィックス、及びファイル名を含むコンテンツファイルのストリーミングＩＤを検索する（ステップ１０１６）。この情報を使用して、プレイリストサーバ６１０は、リダイレクタファイルを作成する（ステップ１０１８）。次いで、プレイリストサーバ６１０は、ＧＵＩＤにより識別されるエンドユーザプロセッサ６０２の特定のメディアプレーヤにリダイレクタファイルを渡す（ステップ１０２０）。本実施形態の例示的なリダイレクタファイルを以下に示す。
＜ＡＳＸ＞
＜ＥＮＴＲＹ＞
＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍｌ．ａｓｆ？ＩＤ＝１２３４５６＆ＴＩＣＫＥＴ＝ｕｖｗｌ２３ｘｙｚ＆ＵＳＥＲ＿ＩＤ＝ａｂｃｌ２３ｄｅｆ＆ＰＰＶ＿ＳＬＯＴ＝１”＞
＜／ＥＮＴＲＹ＞
＜／ＡＳＸ＞
ここで、ＵＲＬプレフィックスが「ｍｍｓ：／／」で表され、適切なメディアサーバ６０４のホスト名が「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」で表され、ファイル名が「ｓｔｒｅａｍ１．ａｓｆ」で表され、コンテンツストリーミングＩＤのリクエストされたアイテムが「１２３４５６」で表され、チケットが「ｕｖｗ１２３ｘｙｚ」で表され、エンドユーザＩＤが「ａｂｃ１２３ｄｅｆ」で表され、ｐｐｖスロット値が「１」である。
【００８０】
リダイレクタファイルを受け取った後、エンドユーザプロセッサ６０２上のメディアプレーヤは、適切なストリーミング・メディアサーバ６０４にストリーミング・メディアコンテンツをリクエストするステップに進む（ステップ１０２２）。より具体的には、メディアプレーヤは、リダイレクタファイルにおいて識別された特定のストリーミング・メディアサーバ６０４を呼び出す。呼び出されると、メディアプレーヤは、リクエストされたコンテンツのストリーミングＩＤのコピー、ウェブサーバ６０６によって生成されたチケット（ステップ１０１０で）、エンドユーザＩＤ、及びｐｐｖスロット値をストリーミング・メディアサーバ６０４に提供する。更にメディアプレーヤは、そのＧＵＩＤをストリーミング・メディアサーバに渡す。
【００８１】
エンドユーザプロセッサ６０２からオリジナルのストリーミングリクエスト及びログイン情報を受け取ると、ストリーミング・メディアサーバ６０４上で実行されるアプリケーションは、メディアプレーヤがＧＵＩＤを渡した（又は無効のデフォルト値を渡した）かどうかを判断する。渡していない場合、アプリケーションは、認証プロセスを中止することによってエンドユーザのアクセスを拒否し、エンドユーザに通知する。好適には、エンドユーザのメディアプレーヤがＧＵＩＤを提供しなかったことがデータベース６０８又は他のデータ記憶装置内に記録され、次回にこのエンドユーザがシステムにログインするときに、システムは、ＧＵＩＤの送信を可能にする方法に関する指示をエンドユーザに提供する。
【００８２】
図６−８の実施形態と同様、ストリーミング・メディアサーバ６０４がメディアプレーヤの呼び出しを受けると、ストリーミング・メディアサーバ６０４は、１つ又はそれ以上の認証チケットを個別に生成し、その１つ又はそれ以上のチケットをメディアプレーヤから受け取られたチケットと比較する（ステップ１０２４）。チケットが「一致する」場合、ストリーミング・メディアサーバ６０４は、コンテンツへのアクセスを許可し、エンドユーザにコンテンツをストリーミングする（ステップ１０２６）。
【００８３】
ストリーミングサーバ６０４が、エンドユーザにコンテンツへのアクセスを許可する度に、ストリーミング・メディアサーバ６０４は、特定の接続を識別する情報をグローバルキャッシュ・サーバ９０２に送る（ステップ１０２８）。上述のように、このような接続情報は、エンドユーザＩＤ、ストリーミング・コンテンツのフォーマット（例えばウインドウズのメディアプレーヤ又はリアルプレーヤ）、エンドユーザにコンテンツを提供するストリーミング・メディアサーバ６０４のサーバＩＤ、エンドユーザのメディアプレーヤのＧＵＩＤ、及びエンドユーザがシステムにログインした特定のエンドユーザプロセッサ６０２を表すｐｐｖスロット値を含むのが好ましい。
【００８４】
ストリーミングサーバ６０４が、エンドユーザにコンテンツへのアクセスを許可する度に、ストリーミング・メディアサーバ６０４はまた、ストリーミング名又はストリーミングＩＤ、エンドユーザＩＤ、及びリクエストに関する接続情報をローカルにキャッシュする。ストリーミング接続が終了する場合は常に、ストリーミング・メディアサーバ６０４は、キャッシュ中の対応するエントリーを削除する。従って、キャッシュ中の全てのエントリーは、現在のストリーミング又はアクセスを表す。ソフトウェア構成要素又はオブジェクトなどのストリーミング・メディアサーバ６０４上で実行されるポーリングサービスを使用して、メディアサーバ６０４は、エントリーのキャッシュを周期的に（例えば２分毎に）ポーリングする。各エントリーに対し、ストリーミング・メディアサーバ６０４は、グローバルキャッシュ・サーバ９０２に接続情報を再送する。
【００８５】
上述のように、グローバルキャッシュ・サーバ９０２は、受け取られた接続情報を各レコードが含んでいるデータベース又はキャッシュを含む。グローバルキャッシュ・サーバ９０２が、特定のユーザに関する接続情報を受け取ると、サーバ９０２は、通常、そのデータベース内に新しいレコードを作成する。しかしながら、新しいレコードを作成する前に、グローバルキャッシュ・サーバ９０２は、そのデータベースが新規に受け取った接続情報と同じエンドユーザＩＤを有するレコードを含むかどうかを最初に判断する（ステップ１０３０）。
【００８６】
グローバルキャッシュ・サーバ９０２はまた、アクセスが終了するときに特定のアクセスに関するレコードを削除する。上述のように、各ストリーミング・メディアサーバ６０４は、接続情報によって識別されるアクセスの期間中に所定の間隔でグローバルキャッシュ・サーバ９０２に接続情報の各セットを再送する。グローバルキャッシュ・サーバ９０２は、接続情報が再送されなかったレコードを周期的に消去し、これにより最新のアクセスに関するレコードだけを保持する。別の実施形態では、グローバルキャッシュ・サーバは、別の方法に基づいて、もはや使用されていない接続に関するレコードを消去することができる。例えば、別の実施形態において、グローバルキャッシュ・サーバ９０２は、該グローバルキャッシュ・サーバが特定の接続が終了したことを示す終了メッセージをストリーミング・メディアサーバから受け取るまで、特定の接続に関するレコードを保持する。つまり、グローバルキャッシュ・サーバのデータベース内にレコードが存在することは、特定のエンドユーザ（エンドユーザＩＤによって識別される）が現在コンテンツファイルにアクセスしていることを表している。
【００８７】
グローバルキャッシュ・サーバ９０２が受け取ったエンドユーザＩＤと同じエンドユーザＩＤを備えたレコードを既に有する場合、エンドユーザ（又はアクセス情報を取得した無許可のユーザ）は、複数のコンテンツファイルに同ときにアクセスし、或いは複数回同じコンテンツファイルにアクセスすることを試みている。本実施形態では、このような複数アクセスは許可されない。従って、グローバルキャッシュ・サーバ９０２は、新規に受け取られる接続情報が受け取られているメディアサーバと、現存のデータベースレコード中のサーバＩＤによって識別されるメディアサーバの両方にエンドユーザのアクセスを終了させるリクエストを発行する。ストリーミング・メディアサーバ６０４がエンドユーザから接続解除されると、グローバルキャッシュ・サーバ９０２は、そのデータベースから特定のエンドユーザに関係するレコードを削除する。
【００８８】
この更に高いレベルの許可保護は任意選択であり、異なる方法で実施することができる点は理解されるべきである。例えば、別のサーバが、ユーザが複数アクセスを試みているかどうかを判断するためにグローバルキャッシュ・サーバ９０２に照会することができる。このような１つの実施形態では、プレイリストサーバ６１０がウェブサーバ６０６からリクエストリンク、チケット、及びエンドユーザＩＤを受け取った後で、グローバルキャッシュ・サーバ９０２を呼び出し、グローバルキャッシュ・サーバ９０２が既にコンテンツにアクセスしているエンドユーザのレコードを有するかどうかを判断する（ステップ１０１８ａ）。グローバルキャッシュ・サーバ９０２は、エンドユーザが現在コンテンツにアクセスしているか否かに関する表示をプレイリストサーバ６１０に返信する（ステップ１０１８ｂ）。これに応じて、プレイリストサーバ６１０上で実行される認証アプリケーションは、偽又は無効のリダイレクタファイルを生成する。このような１つの実施例では、リダイレクタファイルは、チケットが存在せず、又はストリーミング・メディアサーバ６０４によって検出されることになるデフォルトチケットを含むことにより、無効である。
【００８９】
グローバルキャッシュ・サーバ９０２が、そのデータベースにおいて新しい接続情報で受け取られたエンドユーザＩＤと同一のエンドユーザＩＤを有するレコードが存在しないことを識別した場合、グローバルキャッシュ・サーバ９０２は、そのデータベースにおいて受け取った接続情報を用いて新しいレコードを作成し、エンドユーザのコンテンツへのアクセスを妨げない。
【００９０】
グローバルキャッシュ・サーバ９０２が、エンドユーザの接続を解除しない場合、サーバ９０２は、接続情報の全部又は一部をビジネスサーバ９０４に中継し、該ビジネスサーバは、２つの更に高いレベルの任意選択の許可保護を有効にする（ステップ１０３４）。本実施形態では、グローバルキャッシュ・サーバ９０２は、エンドユーザＩＤ、ｐｐｖスロット、ＧＵＩＤ、及びストリーミングフォーマットをビジネスサーバ９０４に中継する。
【００９１】
ビジネスサーバ９０４は、グローバルキャッシュ・サーバ９０２から受け取ったこの接続情報を使用して、メディアプレーヤのＧＵＩＤに部分的に基づいてコンテンツへのアクセスを制御する（ステップ１０３６）。上述のように、各エンドユーザは、各々が各フォーマットに対し１つだけのメディアプレーヤを有する３つの異なるエンドユーザプロセッサ６０２からシステムにログインし、コンテンツにアクセスすることが許可される。従って、特定のエンドユーザプロセッサ６０２（ｐｐｖスロットによって識別される）に関し、エンドユーザが特定のメディアフォーマット用の特定のメディアプレーヤ（ＧＵＩＤにより識別される）を用いてアクセスするようリクエストし、該メディアプレーヤが、同じフォーマットのメディアに対して同じエンドユーザプロセッサ６０２上で以前使用されていたメディアプレーヤとは異なる場合、ビジネスサーバ９０４は、エンドユーザの接続を切断させることになる。一般に、この決定は、トランザクションテーブルにアクセスし、新しく受け取られる接続情報をエンドユーザ及びｐｐｖスロット値に関する既存のエントリーと比較することによって行われる。
【００９２】
ビジネスサーバ６０４が、所与のエンドユーザ及びｐｐｖスロットに関する接続情報とを受け取ると、ビジネスサーバ９０４は、トランザクションテーブルにアクセスし、ＧＵＩＤがこの特定のエンドユーザ、ｐｐｖスロット、及びフォーマットについて以前受け取ったかどうかを判断する。受け取っていない場合には、ビジネスサーバ９０４がトランザクションテーブルを更新させてＧＵＩＤを反映させ、ビジネスサーバ９０４は、エンドユーザのアクセスを終了するために何もしない。
【００９３】
受け取られた接続情報が、ＧＵＩＤが既に受け取ったトランザクションテーブル中のレコードに対応する場合、ビジネスサーバ９０４は、受け取られたＧＵＩＤがそのｐｐｖスロットに関して格納された特定のメディアフォーマット用のＧＵＩＤと一致するかどうかを判断する。ＧＵＩＤが一致しない場合には、ビジネスサーバ９０４は、グローバルキャッシュ・サーバ９０２にエンドユーザのコンテンツへのアクセスを終了する旨の命令を送信し、エンドユーザのアクセスは拒否される。このような命令は、エンドユーザＩＤを指定するのが好ましい（ステップ１０３８）。次に、グローバルキャッシュ・サーバ９０２は、現在エンドユーザにコンテンツを供給している１つ又はそれ以上のストリーミング・メディアサーバ６０４にリクエストを発行する。
【００９４】
従って、エンドユーザが一時的にコンテンツへのアクセスが許可されていても、本実施形態は、無許可のエンドユーザに対してアクセスを拒否するものとみなされるべきである。このような一時的なアクセスは、グローバルキャッシュ・サーバ９０２及びビジネスサーバ９０４での処理に起因してアクセスの許可に遅延が生じないこと望ましいので、本実施形態においては許可される。グローバルキャッシュ・サーバ９０２及びビジネスサーバ９０４の処理に対してアクセスが遅延した特定の事例においては、エンドユーザのメディアプレーヤがタイムアウトとなり、アクセスの認可が妨げられる可能性がある。その結果、本実施形態のメディアサーバ６０４は、チケットが一致すると直ちにアクセスを認可し、これによりメディアプレーヤがタイムアウトとなることを防ぎ、更に、グローバルキャッシュ・サーバ９０２又はビジネスサーバ９０４がそのアクセスを不適切であると判断した場合には、このようなアクセスは終了する。
【００９５】
ビジネスサーバ９０４が、新しく受け取られたメディアプレーヤのＧＵＩＤがｐｐｖスロット及びフォーマットに関しメモリ内に格納されたＧＵＩＤと一致すると判断した場合、ビジネスサーバ９０４は、何も行わず、エンドユーザのアクセスが継続することを許可する。
【００９６】
グローバルキャッシュ・サーバ９０２が、システム内の全てのストリーミング・メディアサーバ９０４からの接続情報を受け取ることが好ましい限りは、各々がメディアサーバのサブセットから接続情報を受け取る複数のグローバルキャッシュ・サーバを含むことができる点を理解されたい。しかしながら、このような実施形態では、複数のグローバルキャッシュ・サーバは相互に通信している。
【００９７】
更に、特定の実施形態において、グローバルキャッシュ・サーバ９０２及びビジネスサーバ９０４の機能性を１つのサーバに組み合わせてもよいが、２つの別個のサーバの使用には、スケーラビリティを含む幾つかの利点がある。例えば、許可システムが複数のコンテンツ所有者のアカウントに対して利用される場合には、各アカウントが別個の認証ルールを実施することができ、各ルールは、グローバルキャッシュ・サーバへのアクセスを有する別個のビジネスサーバ上にある。このような実施形態において、接続情報は、現存する接続情報又はアカウントＩＤなどの接続情報に含まれる付加的なフィールドに基づいて適切なビジネスサーバに送ることができる。
【００９８】
本実施形態では、システムは、エンドユーザのｐｐｖスロット情報（ｐｐｖスロット値とＧＵＩＤを含む）を再登録及びクリアする機会を各エンドユーザに提供し、これによりエンドユーザが異なるマシン及び／又はメディアプレーヤからのコンテンツにアクセスすることが可能になる。
【００９９】
他の別の実施形態では、メディアサーバ６０４とは対照的に、グローバルキャッシュ・サーバ９０２でチケット許可を実行することによってプレイリストへのアクセスを制御する。これは、より大きなスケーラビリティを有するより効率的なシステムをもたらすことができる。このことは、全て同様のコンテンツを供給する極めて多くのメディアサーバが存在する場合に特に有用である。各メディアサーバ上で全く同じ情報を保管し且つ処理する代わりに、この実施形態により、認証情報を１つの中央プレイリスト上に存在させることが可能となり、残りのシステムに渡していくことができる。従って、メディアサーバは、コンテンツをストリーミングすることに集中し、認証アルゴリズムによって妨げられないようにすることができる。ここで、このような１つの実施形態を図１１−１２に関連して説明する。本実施形態の機能性のほとんどは、図３、図６、及び図９の実施形態の機能性と同じであり、従って、同じ技術のいずれかによって実施することができる点は、当業者であれば理解されるであろう。本実施形態のアーキテクチャは、図９に関連して検討されたアーキテクチャと同じものである。
【０１００】
次に、本実施形態の動作を図１１のワークフロー図に関連して説明する。本実施例の目的のために、エンドユーザは、保護されたコンテンツの１つのアイテムを有するプレイリストへのアクセスをリクエストするが、複数のアイテムを使用することもできる。最初に、ウェブサーバ６０６は、許可アプリケーションへのログインをエンドユーザにリクエストし、特定のストリーミング・メディアを視聴するオプションをユーザに呈示するウェブページを提供する（ステップ１１０２）。
【０１０１】
エンドユーザが、ストリーミングリクエストリンクを起動すると、エンドユーザプロセッサ６０２上で実行されるプログラミングスクリプトにより、ストリーミングリクエストリンク及びエンドユーザＩＤをウェブサーバ６０６に送る（ステップ１１０４）。エンドユーザのスクリプトは、例えばＣ＋＋、Ｐｅｒｌ（パール）、ビジュアルベーシック、Ｊａｖａ及び同様のものを含むどのようなプログラミング言語ででも基本的に実施することができることを当業者であれば認識するであろう。本実施形態では、スクリプトはＪａｖａスクリプトであり、エンドユーザのウェブブラウザと連動して実行される。
【０１０２】
ウェブサーバ６０６が、スクリプトからストリーミングリクエストを受け取ると、ウェブサーバ６０６は、許可ソフトウエア・プラグインの指示の下で許可チケットを生成する。この件に関して、ウェブサーバ６０６は、データベース６０８に対して許可チケットの生成の際に使用する秘密キー（本実施形態では、リクエストされたプレイリストに関連するセキュリティキーとセキュリティインターバル）のリクエストを発行する（ステップ１１０６）。これに応答して、データベース６０８は、ウェブサーバ６０６に秘密キーを返す（ステップ１１０８）。別の実施形態では、より多くの又はより少ない或いは異なるデータを備えた秘密キーを使用することができ、セキュリティインターバルなどの特定の情報は、メモリから検索されるのではなく、暗号で設定することができる。
【０１０３】
データベース６０８から秘密キーを取得した後、ウェブサーバ６０６は、ストリーミングＩＤ又はプレイリストＩＤのいずれかを使用して、図４に関連して上述されたようにチケットを生成する（ステップ１１１０）。本明細書で説明されたように、ウェブサーバ６０６は、秘密キー、ストリーミングＩＤ又はプレイリストＩＤ、エンドユーザＩＤ、及び時間値をハッシュアルゴリズムに適用してチケットを生成する。次いで、ウェブサーバは、エンドユーザプロセッサ６０２上で実行されるウェブブラウザにチケットとエンドユーザＩＤを返す（ステップ１１１２）。
【０１０４】
許可チケットを受け取った後、エンドユーザプロセッサ６０２上で実行されるスクリプトは、ストリーミングリクエストリンクの最後に情報を付加する（ステップ１１１４）。例示的なリンクは以下に示される。ここで、プレイリストＩＤは「７８９０００」で表され、チケットが「ｕｖｗ１２３ｘｙｚ」で表され、エンドユーザＩＤが「ａｂｃ１２３ｄｅｆ」で表される。
【０１０５】
＜ Ａ ｈｒｅｆ
”ｈｔｔｐ：／／ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｍａｋｅｐｌａｙｌｉｓｔ？ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｕｖｗｌ２３ｘｙｚｒｅｔｕｒｎ＆ＵＳＥＲ＿ＩＤ＝ａｂｃｌ２３ｄｅｆ”＞
【０１０６】
次いで、エンドユーザプロセッサ６０２上で実行されるスクリプトは、ホスト名「ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」によりストリーミングリクエストリンクで識別されるプレイリストサーバ６１０が呼び出される（ステップ１１１６）。従って、プレイリストサーバ６１０は、リンク、プレイリストＩＤ、チケットユーザＩＤ及びクッキーＩＤが提供され、これらは以下により詳細に説明する。
【０１０７】
別の実施形態では、ストリーミングリクエストにチケットを付加するためにエンドユーザスクリプトは使用されない。その代わりに、エンドユーザが、そのエンドユーザＩＤを提供してストリーミングリクエストリンクを起動する（ステップ１１０４で）ときに、ウェブサーバ６０６上で実行される認証アプリケーションがチケットを生成し、該チケットとエンドユーザＩＤとをストリーミングリクエストリンクに付加し、プレイリストサーバ６１０を直接呼び出してチケットを検証する。ウェブサーバ６０６はまた、プレイリストサーバ６１０にエンドユーザプロセッサ６０２を識別する情報を渡すので、プレイリストサーバ６１０は、プレイリスト・ハッシュ（以下で説明する）をエンドユーザプロセッサ６０２に転送する（これによりステップ１１１２、１１１４、及び１１１６を不要にする）。
【０１０８】
次に、プレイリストサーバ６１０は、リクエストと共にウェブサーバ６０６によって生成されたチケットをグローバルキャッシュ・サーバ９０２に渡し、第２のチケットを生成する（ステップ１１１８）。グローバルキャッシュ・サーバは、そのローカルのデータベースに対し許可チケットを生成する際に使用するための秘密キー（本実施形態では、リクエストされたプレイリストに関連するセキュリティキーとセキュリティインターバル）のリクエストを発行する（ステップ１１２０）。ローカルデータベースを有することで追加される利点は、別のサーバ又は他のデータベースを使用することを必要とせずにデータベース内で情報にアクセスできることである点を認識されたい。従って、ローカルデータベースを使用することにより、データベース内に格納された情報をより迅速に処理することができる。リクエストに応答して、ローカルデータベースは、グローバルキャッシュ・サーバ９０２に秘密キーを返す（ステップ１１２２）。
【０１０９】
このローカルデータベースから秘密キーを取得した後、グローバルキャッシュ・サーバ９０２は、図１１に関連して以下に更に詳細に説明するように、１つ又はそれ以上の認証チケットを独自に生成し、これらのチケットをウェブサーバ６０６によって生成されたチケットと比較することにより、アクセスを認可するかどうかを判断する（ステップ１１２４）。グローバルキャッシュ・サーバ９０２によって生成されたチケットが、ウェブサーバ６０６によって生成されたチケットと一致する場合、グローバルキャッシュ・サーバ９０２は、プレイリストサーバ６１０に一致を表すメッセージを送る。チケットが一致しない場合は、プレイリストサーバ６１０に不一致を表すメッセージが送られる（ステップ１１２６）。
【０１１０】
プレイリストサーバ６１０が、一致を表すメッセージを受け取ると、プレイリストサーバ６１０は、プレイリスト・ハッシュを生成する。このハッシュは、当該プロセッサ６０２に対するクッキーＩＤに基づく。上述のように、一般に、クッキーは、エンドユーザが特定のエンドユーザプロセッサ６０２を介して１つ又はそれ以上の特定のウェブサイトを最初に訪れたときに、ウェブサーバがエンドユーザのブラウザに付与するデータのセットである。ウェブサーバ６０６は、クッキーが含むエンドユーザに関する情報（例えばユーザＩＤ）を保存し、エンドユーザのブラウザは、通常、エンドユーザプロセッサ６０２上のブラウザのシステムフォルダ内に格納されるテキストファイルとしてクッキーを格納する。このクッキーは、リンク、プレイリストＩＤ、チケット及びユーザＩＤと共にエンドユーザプロセッサ６０２からプレイリストサーバに渡される。ユーザのプロセッサ６０２（例えばウェブブラウザ）がクッキーを受け入れない場合には、アプリケーションは、ユーザに対してオプションを変更するようリクエストする応答を生成することになる。このクッキーは、現在時刻及び予め定められたタイムインターバルと共に、プレイリストサーバ６１０によって使用されてプレイリスト・ハッシュを生成する。このハッシュの生成については、以下に更に詳細に説明する。チケットが一致しなかった場合には、「ダミーハッシュ」が生成され、ストリーミングに付加される（ステップ１１２８）。この「ダミーのハッシュ」は、クッキーに基づく必要はなく、むしろ許可されなかったことをシステムに対して単に示すものである。従って、ダミーハッシュは、予め定められた英数字、又はランダムに生成されたストリング、過去の時間又は未来時間に基づくハッシュ、ゼロ値、及び同様のものとすることができる。ストリーミングリクエストと共にハッシュ及び許可チケットは、エンドユーザプロセッサ６０２に送られる（ステップ１１３０）。或いは、許可チケットの１つ又は両方はエンドユーザプロセッサ６０２には渡されない。特定の実施形態では、「ダミーハッシュ」が生成されずに、むしろストリーミングリクエストが、どのようなハッシュも付加されずにエンドユーザプロセッサ６０２に送られ、すなわち許可されなかったことを示すことも理解されたい。
【０１１１】
プレイリスト・ハッシュは、コンテンツを視聴するための許可が認可されていたか又は許可が拒否されていたものとしてユーザを識別するよう機能する点も理解されたい。ユーザが許可されていた場合、有効なプレイリスト・ハッシュが生成されることになる。ユーザが許可されていなかった場合、無効又は「ダミー」ハッシュが生成されることになる。対照的に、生成された許可チケットは、コンテンツを視聴する許可をユーザが認可されるべきか否かを判断するベースを形成する。
【０１１２】
プレイリスト・ハッシュを受け取った後、エンドユーザプロセッサ６０２は、ストリーミング・メディアサーバ６０４にストリーミング・メディアコンテンツをリクエストするステップに進む（ステップ１１３２）。エンドユーザプロセッサ６０２は、必要に応じてストリーミングＩＤのコピー又はプレイリストＩＤ、プレイリスト・ハッシュ、許可チケット、並びにクッキーを渡す。上記で説明されたように、特定の実施形態では、許可チケットの１つ又は両方はプレイリストサーバ６１０からエンドユーザプロセッサ６０２に渡されず、従って、エンドユーザプロセッサ６０２からストリーミング・メディアサーバ６０４に渡されない。ストリングが受け取られると、ストリーミング・メディアサーバ６０４は、現在時刻、受け取ったクッキー、及び予め定められたセキュリティタイムインターバルを利用するプレイリストサーバによって使用されたのと同じハッシュアルゴリズムを使用して第２のハッシュ値を生成することによって、プレイリスト・ハッシュの精度を検証する。次にメディアサーバ６０４は、生成されたハッシュを受け取ったハッシュと比較する（ステップ１１３４）。ハッシュの妥当性が検証されると（例えば生成されたハッシュと一致すると）コンテンツが供給され、検証されない場合には、ハッシュが「ダミーハッシュ」であるか、或いはアクセスの有効期限が切れている理由からアクセスが拒否される（ステップ１１３６）。
【０１１３】
大半の認証をメディアサーバではなくプレイリストサーバ上で行うことができる利点が付加されることにより、システムの効率が大幅に向上する点を理解すべきである。全てが同じコンテンツを供給する多数のメディアサーバが存在できる場合、メディアサーバ上で保管及び処理される完全に同一の情報は、様々な異なる箇所で見出すことができる。従って、メディアサーバが処理する認証を可能な限り少なくできることで、メモリ空間を大幅に節約することができる。従って、大半の認証情報を１つの中央プレイリストサーバ上に存在させることができ、該情報を残りのシステムに渡していくことができる。加えて、メディアサーバがコンテンツのストリーミングに集中できることにより、コンテンツのストリーミングも同様により効率的になる。
【０１１４】
次に、リクエストされたコンテンツストリーミングへのアクセスを認可するかどうかを判断するグローバルキャッシュ・サーバ９０２のプロセスを図１２を参照して説明する。理解されるように、本プロセスは、図５に関連して上記で説明されたプロセスと同じである。
【０１１５】
アクセスを認可するかどうかの判断において、最初に、グローバルキャッシュ・サーバ９０２が、ストリーミングＩＤ、エンドユーザＩＤ、公開キー、エンドユーザのクッキー及びチケットを含むストリーミングリクエストをプレイリストサーバ６１０から受け取る（ステップ１２０２）。ストリーミングリクエストを受け取ると、グローバルキャッシュ・サーバ９０２は、ハッシュアルゴリズムに対する入力ストリングを生成する。この点に関して、グローバルキャッシュ・サーバ９０２は、キャッシュ又はローカルデータベースとすることができるローカルメモリから秘密キー情報、すなわちセキュリティキー及びセキュリティインターバルを検索するが、別のキーを使用してもよい（ステップ１２０６）。
【０１１６】
メディアサーバ１０４に関して上記で検討したように、グローバルキャッシュ・サーバ９０２は、３つの時間値を計算してその時差を考慮する（ステップ１２１０）。次いで、この時点で、グローバルキャッシュ・サーバ９０２は、検索された秘密キー情報、受け取った公開キー情報、及び３つの時間値を用いて、３つの対応するハッシュ入力ストリングを生成する（ステップ１２１４）。本実施形態では、３つの時間値は、現在時刻、現在時刻＋セキュリティタイムインターバル、及び現在時刻−セキュリティタイムインターバルであり、例えば、ここでセキュリティインターバルは、現在時刻の１０秒前及び現在時刻の１０秒後である。時間値の間の差が小さいほど、適用されるセキュリティのレベルが高くなることは理解されるべきである。適正なハッシュでも有効寿命が限られているので、より短いタイムインターバルは、ユーザが適正なハッシュを傍受し、これを適正な認証として渡してコンテンツを不正に取得しようとする可能性を低減する。次に、グローバルキャッシュ・サーバ９０２は、ハッシュアルゴリズムに対して３つの入力ストリングの各々を適用し、これにより３つのチケットを生成する（ステップ１２１８）。
【０１１７】
チケットを独自に生成した後、次にグローバルキャッシュ・サーバ９０２は、グローバルキャッシュ・サーバ９０２によって生成されたチケットのいずれかがウェブサーバ６０６によって生成されたチケットと一致するかどうかを判断する（ステップ１２２２）。チケットが一致しない場合には、ストリーミングリクエストは認証されたものではなく、及び／又は有効期限が切れたものである（すなわち、ユーザのリクエスト時間から測定してセキュリティインターバルを超えた時間にグローバルキャッシュ・サーバ９０２によって生成されたもの）可能性が高い。従って、グローバルキャッシュ・サーバは、プレイリストサーバに認証されなかったことを通知するメッセージを渡す（ステップ１２２６）。
【０１１８】
チケットが一致する場合、ストリーミングリクエストは認証されたものであり、セキュリティタイムインターバルの範囲内にある可能性が高い。次にグローバルキャッシュ・サーバ９０２は、プレイリストサーバ９１０に対してプレイリスト・ハッシュを生成するように指示するメッセージをプレイリストサーバ９１０に渡す（ステップ１２３０）。図１１に関連して上述されたように、このハッシュは、ストリーミングリクエストと共にエンドユーザプロセッサ６０２に渡され、そこからハッシュの精度を検証するためにストリーミング・メディアサーバ６０４に渡される。
【０１１９】
本明細書の説明に基づいて、図５に関連して検討された種々の実施形態及び修正の全てが本実施形態にも適用できることは、当業者であれば理解されるであろう。
【０１２０】
上述の実施形態は、セキュリティキー及びセキュリティインターバルの両方を含む秘密キーを利用するが、これより多くの情報又は少ない情報を秘密キーとして利用することも本発明の範囲内であることは理解すべきである。例えば、別の実施形態では、秘密キーは使用されず、他の実施形態では、秘密キーに例えばクライアントのユーザ名及びパスワードを含む追加情報が含められる。同様に、ストリーミングＩＤ及びエンドユーザＩＤ以外の情報を含む公開キーを利用することは本発明の範囲内である。例えば、ファイルパス名を含む情報を識別する別のコンテンツファイルを使用してもよい。加えて、ある実施形態では、エンドユーザＩＤは公開キー情報から省くことができる。更に別の実施形態では公開キー情報は、リクエストコンテンツファイルのタイトル又は他のストリーミング詳細などの追加情報を含む。
【０１２１】
ウェブサーバ及びストリーミング・メディアサーバによって提供されるものとして記載された機能性は、これに関連する他のデバイス上で実施することができる点も理解されるであろう。例えば、本発明の特定の実施形態では、ストリーミング・メディアサーバは、これに接続された関連アプリケーションサーバを有し、該アプリケーションサーバは、コンテンツへのアクセスを拒否又は認可するプロセスの全て又は一部を実施する。同様に、アプリケーションサーバをウェブサーバと対応付けて、例えば許可チケットを生成するプロセスを含むウェブサーバの機能性の一部又は全てを提供することは、本発明の範囲内である。従って、特定のサーバに対する言及は、他の関連するサーバ又は言及するサーバに結合されたプロセッサを含むことを意味する。
【０１２２】
また、許可チケットは、正確な時間に生成される必要がない点も理解されるべきである。例えば、ウェブサーバによって生成されるチケットは、エンドユーザがストリーミングリクエストリンクを起動する時間、又はウェブサーバがデータベースから秘密キー情報を受け取る時間、或いはストリーミングリクエストの起動時間付近の他の任意の時間に基づくことができる。同様に、メディアサーバは、例えば、メディアプレーヤから呼び出された時間、又は秘密キー情報が検索された後、又はコンテンツへの呼び出しがなされた時間付近の他の任意の時間に許可を生成することができる。更にメディアサーバが複数のチケットを生成する場合、チケットは、異なる時間又は同じ時間に基づくことができる。従って、時間又は現在時刻に対する言及は、正確な時間ではなく範囲を言及することを意味する。
【０１２３】
上記の例示的な実施形態は、単一のアイテムのコンテンツへのアクセスを制御する関連で説明されてきたが、上記の実施形態のいずれかを使用して、複数の保護されたコンテンツファイルを含むプレイリストへのアクセスを制御することができる点を当業者は理解するであろう。ここで、プレイリストへのアクセスを制御するための１つの例示的な実施形態を図６−８に関連して説明する。このような実施形態は、以下に指摘される修正により上述の説明に従って動作する。一般に、ウェブサーバ６０６は、各ストリーミングのストリーミングＩＤに基づいてプレイリストに収容された各コンテンツストリーミングのためのチケットを生成する。
【０１２４】
エンドユーザプロセッサ６０２上のメディアプレーヤは、プレイリストＩＤを含むストリーミングリクエストをプレイリストプロセッサ６１０に渡す。次に、プレイリストプロセッサ６１０は、リダイレクタファイルを生成し、これをメディアプレーヤに返す。「ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ」オブジェクトは、本実施例ではプレイリストＩＤ「７８９０００」を使用して適切なリダイレクタファイルを構築する。より詳細には、プレイリストサーバ６１０は、プレイリストテーブル７０８とプレイリストテーブル７１０にアクセスし、どのコンテンツファイルがリクエストされたプレイリストの一部であるか、及びプレイリストのコンテンツファイルの順番を判断する。コンテンツファイルのファイル名は、ストリーミングテーブル７０４から検索される。次いで、エンドユーザプロセッサ６０２上で実行されるスクリプトは、対応するコンテンツストリーミングにリンクしているＵＲＬにストリーミングＩＤ、チケット、及びエンドユーザＩＤを付加する。本実施形態では、全てのコンテンツストリーミングが、ストリーミングサーバテーブル７１２において識別される同じメディアサーバ６０４上に配置される。
【０１２５】
対応するコンテンツストリーミングへのＵＲＬリンクに付加されたストリーミングＩＤ、チケット、及びエンドユーザＩＤを含む例示的なＡＳＸリダイレクタファイルは以下の通りである。
【０１２６】
＜ＡＳＸ＞
＜ＥＮＴＲＹ＞
＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍｌ．ａｓｆ？ＩＤ＝１２３４５６＆ＴＩＣＫＥＴ＝ａｂｃ１１１ｘｙｚ＆ＵＳＥＲ＿ＩＤ＝ａｂｃｌ２３ｄｅｆ”＞
＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍ２．ａｓｆ？ＩＤ＝２３４５６７＆ＴＩＣＫＥＴ＝ｄｅｆ２２２ｘｙｚ＆ＵＳＥＲ＿ＩＤ＝ａｂｃ１２３ｄｅｆ”＞
＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ． ｃｏｍ／ｓｔｒｅａｍ３．ａｓｆ？ＩＤ＝３４５６７８＆ＴＩＣＫＥＴ＝ｇｈｉ３３３ｘｙｚ＆ＵＳＥＲ＿ＩＤ＝ａｂｃ１２３ｄｅｆ”＞
＜／ＥＮＴＲＹ＞
＜／ＡＳＸ＞
【０１２７】
次いでメディアプレーヤは、ストリーミング・メディアサーバ６０４を連続して呼び出し、各呼び出しに対する各ＵＲＬリンクがリダイレクタファイルに含まれる。より詳細には、メディアプレーヤは最初に、第１のコンテンツストリーミング（本実施例ではストリーミングＩＤ１２３４５６を有する）へのアクセスに対しメディアサーバ６０４を呼び出す。呼び出しに応答し、更に図５に関連して上記に一般的に説明されたように、メディアサーバ６０４は、チケットを独自に生成してコンテンツへのアクセスを認可するかどうかを判断する。アクセスが認可されない場合、エンドユーザはそのように通知される。他方、メディアサーバが、エンドユーザに対し第１のコンテンツストリーミングへのアクセスを認可する場合、メディアプレーヤは、プレイリスト中の残りのコンテンツストリーミング用のメディアサーバ６０４を呼び出すステップに進む。各呼び出しで、メディアサーバ６０４は、リクエストされたコンテンツストリーミングへのアクセスを許可又は拒否するステップに進む。
【０１２８】
しかしながら、このような実施形態では、各コンテンツストリーミングが、プレイリスト中のストリーミングの前に再生されるコンテンツストリーミングの合計持続時間を考慮する個々のセキュリティインターバルを有することが望ましい点を理解されたい。例えば各々が５分の持続時間である（ストリーミングテーブル７０４のストリーミング詳細フィールドで識別された）３つのコンテンツストリーミングを含むプレイリストでは、第２のストリーミングのセキュリティインターバルは、第１のストリーミングのセキュリティインターバルよりも５分だけ長くすることができ、第３のストリーミングのセキュリティインターバルは、第１のストリーミングのセキュリティインターバルよりも１０分だけ長くすることができる。プレイリストの各ストリーミングの持続時間を考慮することによって、システムは、許可されたエンドユーザがプレイリスト中の第１のコンテンツストリーミングへのアクセスを受け入れるが、チケットが有効期限切れである理由から後続のコンテンツストリーミングに対してはアクセスが受け入れられないことを防止するのに役立つ。セキュリティインターバルはまた、プレイリスト中に含まれた広告などのあらゆる非保護のコンテンツをも考慮することができる。
【０１２９】
他の別の実施形態は、プレイリストＩＤに基づいてチケットを生成することによって、複数の保護されたコンテンツストリーミングを含むプレイリストへのアクセスを制御する。１つのこのような実施形態は、以下に指摘される修正と共に、図６−８のシステムの説明に従って動作する。一般的に、エンドユーザが許可アプリケーションにログインし、プレイリストへのアクセスをリクエストすると、ウェブサーバ６０６は、プレイリストＩＤに基づいてチケットを生成し、該チケットをエンドユーザプロセッサ６０２に返す。これに応答して、エンドユーザプロセッサ６０２上で実行されるスプリットは、ストリーミングリクエストリンクにチケット及びエンドユーザＩＤを付加する。以下は、付加された公開キー情報を有する例示的なストリーミングリクエストリンクである。ここで、プレイリストＩＤが「７８９０００」で表され、チケットが「ｘｙｚ３２１ａｂｃ」で表され、エンドユーザＩＤが「ａｂｃ１２３ｄｅｆ」で表される。
【０１３０】
＜Ａ ｈｒｅｆ
”ｈｔｔｐ：／／ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ？ＰＬＡＹＬＩＳＴ＿ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｘｙｚ３２１ａｂｃ＆ＵＳＥＲ＿ＩＤ＝ａｂｃｌ２３ｄｅｆ’＞
【０１３１】
エンドユーザプロセッサ６０２は、名称「ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」によって識別されるプレイリストサーバ６１０を呼び出す。次に、プレイリストサーバ６１０は、リダイレクタファイルを生成するためにプレイリストサーバ６１０に存在する「ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ」オブジェクトを起動する。本実施形態では、全てのコンテンツストリーミングが同一のメディアサーバ６０４上に存在する。上述の実施形態とは異なり、「ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ」オブジェクトはまた、リダイレクタファイルの第１のＵＲＬリンクの終わりにプレイリスト中の後続の保護されたコンテンツストリーミングのファイル名を付加し、後続のＵＲＬリンクの各々にはプレイリストＩＤ及びチケットだけが付加される。例示的なＡＳＸリダイレクタファイルを以下に示す。ここでプレイリストは、「ｓｔｒｅａｍ１．ａｓｆ」、「ｓｔｒｅａｍ２．ａｓｆ」、「ｓｔｒｅａｍ３．ａｓｆ」で表されるファイル名を有する３つのウインドウズメディア・フォーマットのコンテンツファイルを含み、プレイリストＩＤが「７８９０００」で表され、エンドユーザＩＤが「ａｂｃ１２３ｄｅｆ」で表され、チケットが「ｘｙｚ３２１ａｂｃ」で表される。
【０１３２】
＜ＡＳＸ＞
＜ＥＮＴＲＹ＞
＜ＲＥＦ
ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍｌ．ａｓｆ？ＰＬＡＹＬＩＳＴ＿ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｘｙｚ３２１ａｂｃ＆ＵＳＥＲ＿ＩＤ＝ａｂｃ１２３ｄｅｆ＆ＳＴＲＥＡＭ＝ｓｔｒｅａｍ２．ａｓｆ＆
ＳＴＲＥＡＭ＝ｓｔｒｅａｍ３．ａｓｆ”＞
＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍ２．ａｓｆ？ＰＬＡＹＬＩＳＴ＿ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｘｙｚ３２１ａｂｃ”＞
＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍ３．ａｓｆ？ＰＬＡＹＬＩＳＴ＿ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｘｙｚ３２１ａｂｃ”＞
＜／ＥＮＴＲＹ＞
＜／ＡＳＸ＞
【０１３３】
エンドユーザプロセッサ６０２のメディアプレーヤは、第１のコンテンツファイルにアクセスするために、ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ（すなわちストリーミング・メディアサーバ６０４のホスト名）を呼び出すステップに進む。メディアサーバ６０４は、図５に関連して上述されたように、プレイリストＩＤに基づいてチケットを生成し、アクセスを認可又は拒否するステップに進む。メディアサーバ６０４がアクセスを認可し、メディアプレーヤにプレイリスト中の第１のコンテンツファイルを提供する場合、メディアサーバ６０４は、プレイリストＩＤ及び対応するチケット用のローカルに格納されたテーブル内にレコードを作成し、リダイレクタファイルに含まれているプレイリスト中の後続のコンテンツストリーミングのファイル名をレコードに格納する。
【０１３４】
続いて、メディアプレーヤが、第２のコンテンツストリーミングへのアクセスを要求する場合、メディアプレーヤは、メディアサーバ６０４にプレイリストＩＤ及びチケットを供給する。次に、メディアサーバ６０４は、プレイリストＩＤ及びチケットによって識別されたレコードを求めてテーブルをサーチする。レコードが存在する場合、メディアサーバ６０４は、第２のストリーミングへのアクセスを許可し、特定のチケットを有するエンドユーザが視聴したものとしてストリーミングにフラグを立てる。無許可のエンドユーザが同じＵＲＬリンクを使用して第２のストリーミングにアクセスしようと試みる場合、プレイリストＩＤ及びチケットに関するレコードにおいては、第２のストリーミングは既に視聴されているものとしてフラグが立っているので、メディアサーバ６０４はアクセスを拒否することになる。同様のプロセスが、プレイリスト内の残りのコンテンツストリーミングへのアクセスを許可するために使用される。当業者には理解されるように、この実施形態は、第１のストリーミングへのアクセス認可とこのような後続のストリーミングとの間の時間遅延に起因して、プレイリスト内の後続のストリーミングへのアクセスを誤って拒否されるどのような可能性をも回避する。
【０１３５】
本発明の方法及びシステムは、多くの用途を有し、多くの様態で実施することができ、従って、上記の例示的な実施形態及び実施例によって限定されるものではない点を当業者であれば理解されるであろう。更に、本発明の範囲は、当業者には理解されるように、本明細書で説明されたシステム構成要素に対する従来公知の、及び将来開発される変形及び修正を対象とする。
【図面の簡単な説明】
【０１３６】
【図１】本発明の１つの実施形態に基づくシステムを示す概略図である。
【図２】本発明の１つの実施形態に基づくデータベースを示す概略図である。
【図３】本発明の１つの実施形態に基づくワークフローを示す概略図である。
【図４】本発明の１つの実施形態に基づくチケットを生成するプロセスを示すフローチャートである。
【図５】本発明の１つの実施形態に基づくストリーミング・メディアコンテンツのアイテムへのアクセスを許可するかどうかを判断するプロセスを示すフローチャートである。
【図６】本発明の別の実施形態に基づくシステムを示す概略図である。
【図７】本発明の別の実施形態に基づくデータベースを示す概略図である。
【図８】本発明の別の実施形態に基づくワークフローを示す概略図である。
【図９】本発明の別の実施形態に基づくシステムを示す概略図である。
【図１０】本発明の別の実施形態に基づくワークフローを示す概略図である。
【図１１】本発明の別の実施形態に基づくワークフローを示す概略図である。
【図１２】本発明の別の実施形態に基づくストリーミング・メディアコンテンツのアイテムへのアクセスを許可するかどうかを判断するプロセスを示すフローチャートである。
【符号の説明】
【０１３７】
１０２ エンドユーザ
１０４ ストリーミング・メディアサーバ
１０６ ウェブサーバ
１０８ データベース
【特許請求の範囲】
【請求項１】
メディアファイルへのアクセスを制御するための方法であって、前記方法は、
ユーザからの前記メディアファイルへアクセスするリクエストに応答して第１の時間に第１の許可チケットを生成する段階と、
第２の時間に第２の許可チケットを生成する段階と、
前記第１及び第２の許可チケットが一致するかどうかを判断し、これにより前記ユーザが前記メディアファイルへのアクセスが許可されているかどうかを判断する段階と、
前記許可チケットが一致するかどうかの判断並びにデータに基づいて第３の時間に第１のハッシュを生成する段階と、
第４の時間に前記データに基づく第２のハッシュを生成する段階と、
前記第１のハッシュと前記第２のハッシュが一致するかどうかを判断する段階と、
前記ユーザが既に許可されていることを示す前記第１と第２のハッシュが一致した場合には、前記ユーザの前記メディアファイルへのアクセスを許可する段階と、
を含む方法。
【請求項２】
前記アクセスを許可する段階が、複数のメディアファイルへのアクセスを許可する段階を含む請求項１に記載の方法。
【請求項３】
前記第１及び第２の許可チケットが一致しないことにより、無許可のアクセスが試みられたことを示し、前記第１のハッシュがアクセスが拒否されたことを示す値を有することを特徴とする請求項１に記載の方法。
【請求項４】
第１のサーバが前記第１のハッシュを生成し、第２のサーバが前記ユーザのアクセスを許可し、前記第１のサーバが前記第２のサーバとは異なることを特徴とする請求項１に記載の方法。
【請求項５】
第１のサーバが前記第１及び第２の許可チケットが一致するかどうかを判断し、第２のサーバが前記ユーザのアクセスを許可し、前記第１のサーバは前記第２のサーバとは異なることを特徴とする請求項１に記載の方法。
【請求項６】
前記第１の許可チケットはウェブサーバ上で生成され、
前記第２の許可チケットはグローバルキャッシュ・サーバ上で生成され、前記第１及び第２の許可チケットが一致するかどうかの判断は、前記グローバルキャッシュ・サーバ上で行われ、
前記第１のハッシュは、プレイリストサーバ上で生成され、
前記第１のハッシュを生成する段階、前記第１及び第２のハッシュが一致するかどうかを判断する段階、及び前記ユーザの前記メディアファイルへのアクセスを許可する段階が、全てメディアサーバ上で行われることを特徴とする請求項１に記載の方法。
【請求項７】
前記リクエストは、ユーザのコンピュータから受け取られ、前記データは、前記ユーザのコンピュータ上のクッキーであることを特徴とする請求項１に記載の方法。
【請求項８】
前記データは、ランダムに生成されたストリングであることを特徴とする請求項１に記載の方法。
【請求項９】
前記データは、ゼロ値であることを特徴とする請求項１に記載の方法。
【請求項１０】
前記データは、日付であることを特徴とする請求項１に記載の方法。
【請求項１１】
前記データは、未来の日付であることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記データは、現在の日付であることを特徴とする請求項１０に記載の方法。
【請求項１３】
前記データは、過去の日付であることを特徴とする請求項１０に記載の方法。
【請求項１４】
前記第２の時間に第３の許可チケットを生成する段階と、
前記第１の許可チケットを前記第２及び第３の許可チケットと比較する段階と、を更に含む請求項１に記載の方法。
【請求項１５】
前記第１の許可チケットと前記第２の許可チケットは、時間に基づくことを特徴とする請求項１に記載の方法。
【請求項１６】
前記時間は、未来の時間であることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記時間は、現在の時間であることを特徴とする請求項１５に記載の方法。
【請求項１８】
前記時間は、過去の時間であることを特徴とする請求項１５に記載の方法。
【請求項１９】
前記第１の許可チケットと前記第２の許可チケットは、セキュリティキーに基づくことを特徴とする請求項１に記載の方法。
【請求項２０】
前記第１の許可チケットと前記第２の許可チケットは、前記メディアファイルの識別子に基づくことを特徴とする請求項１に記載の方法。
【請求項２１】
前記第１のハッシュと前記第２のハッシュが更に、時間に基づくことを特徴とする請求項１に記載の方法。
【請求項２２】
前記時間は、未来の時間であることを特徴とする請求項２１に記載の方法。
【請求項２３】
前記時間は、現在の時間であることを特徴とする請求項２１に記載の方法。
【請求項２４】
前記時間は、過去の時間であることを特徴とする請求項２１に記載の方法。
【請求項２５】
前記第１のハッシュと前記第２のハッシュが更に、セキュリティキーに基づくことを特徴とする請求項１に記載の方法。
【請求項２６】
前記第１のハッシュと前記第２のハッシュが更に、メディアファイルの識別子に基づくことを特徴とする請求項１に記載の方法。
【請求項２７】
メディアファイルへのアクセスを制御するためのシステムであって、前記システムが、
前記メディアファイルへアクセスするリクエストに応答して第１の時間に第１の許可チケットを生成し、
前記第１の許可チケットとは関係なく第２の時間に第２の許可チケットを生成して、前記第１の許可チケットと前記第２の許可チケットを比較することによって前記メディアファイルへのアクセスを認可するかどうかを判断し、
前記第２のプロセッサの判断に基づいて第１のハッシュを生成し、
第２のハッシュを生成し、
前記第１のハッシュと前記第２のハッシュとを比較することによって前記メディアファイルへのアクセスを認可するかどうかを判断し、
前記第１のハッシュと前記第２のハッシュとの比較に基づいて前記メディアファイルへのアクセスを許可する、
ようにソフトウェアが動作可能な１つ又はそれ以上のプロセッサを含むことを特徴とするシステム。
【請求項２８】
前記アクセスの制御は、複数のメディアファイルへのアクセスの制御であることを特徴とする請求項２７に記載のシステム。
【請求項２９】
ウェブサーバ、ローカル記憶装置を有するグローバルキャッシュ・サーバ、プレイリストサーバ、及びメディアサーバを更に含み、
前記ウェブサーバは、前記メディアファイルへアクセスするリクエストに応答して第１の時間に第１の許可チケットを生成し、
前記グローバルキャッシュ・サーバは、前記第１の許可チケットとは無関係に第２の時間に第２の許可チケットを生成して、前記第１の許可チケットと前記第２の許可チケットとを比較することによって前記メディアファイルへのアクセスを認可するかどうかを判断し、
前記プレイリストサーバは、前記第２のプロセッサの判断に基づいて第１のハッシュを生成し、
前記メディアサーバは、前記第１のハッシュと前記第２のハッシュとを比較することによって前記メディアファイルへのアクセスを認可するかどうかを判断し、前記第１のハッシュと前記第２のハッシュとの比較に基づいて前記メディアファイルへのアクセスを許可することを特徴とする請求項２７に記載のシステム。
【請求項３０】
メディアファイルへのアクセスを制御するための方法であって、前記方法は、
関連する第１のユーザデータを有する第１のユーザからリクエストを受け取る段階と、
前記第１のユーザデータに基づいて第１の許可チケットを生成する段階と、
前記第１のユーザデータに基づいて第２の許可チケットを生成する段階と、
前記第１の許可チケットが前記第２の許可チケットと一致することを判断し、これにより前記第１のユーザが許可されていることを示す段階と、
前記許可チケット及び前記第１のユーザのリクエストの前記判断に基づいて、第１のハッシュを生成する段階と、
関連する第２のユーザデータを有する前記第２のユーザからのリクエストを受け取る段階と、
前記第２のユーザのリクエストに応答して第２のハッシュを生成する段階と、
前記第１のハッシュと前記第２のハッシュとが一致しないことを判断し、これにより前記第２のユーザが許可されなかったことを示す段階と、
前記第２のユーザの前記メディアファイルへのアクセスを拒否する段階と、
を含む方法。
【請求項３１】
前記第１のユーザのリクエストに応答して、前記第１の許可チケットと前記第２の許可チケットとの比較に基づいて第３のハッシュを生成する段階と、
前記第１のハッシュが前記第３のハッシュと一致することを判断し、これにより前記第１のユーザが許可されていたことを示す段階と、
前記第１のユーザが前記メディアファイルへアクセスするのを認可する段階と、
を更に含む請求項３０に記載の方法。
【請求項３２】
前記アクセスを制御する段階が、複数のメディアファイルへのアクセスを制御する段階であることを特徴とする請求項３０に記載の方法。
【請求項３３】
前記第３のデータは、第４のデータであることを特徴とする請求項３０に記載の方法。
【請求項３４】
１つ又はそれ以上のプロセッサに、
メディアファイルへアクセスするリクエストに応答して生成された第１の許可チケットを受け取り、
前記第１の許可チケットとは無関係に第２の許可チケットを生成し、
前記第１の許可チケットと前記第２の許可チケットとを比較し、
前記許可チケット及びデータの比較に基づいて第１のハッシュを生成し、該第１のハッシュを転送する、
ように指示するためのコンピュータコードを含むコンピュータ読み取り可能媒体。
【請求項１】
メディアファイルへのアクセスを制御するための方法であって、前記方法は、
ユーザからの前記メディアファイルへアクセスするリクエストに応答して第１の時間に第１の許可チケットを生成する段階と、
第２の時間に第２の許可チケットを生成する段階と、
前記第１及び第２の許可チケットが一致するかどうかを判断し、これにより前記ユーザが前記メディアファイルへのアクセスが許可されているかどうかを判断する段階と、
前記許可チケットが一致するかどうかの判断並びにデータに基づいて第３の時間に第１のハッシュを生成する段階と、
第４の時間に前記データに基づく第２のハッシュを生成する段階と、
前記第１のハッシュと前記第２のハッシュが一致するかどうかを判断する段階と、
前記ユーザが既に許可されていることを示す前記第１と第２のハッシュが一致した場合には、前記ユーザの前記メディアファイルへのアクセスを許可する段階と、
を含む方法。
【請求項２】
前記アクセスを許可する段階が、複数のメディアファイルへのアクセスを許可する段階を含む請求項１に記載の方法。
【請求項３】
前記第１及び第２の許可チケットが一致しないことにより、無許可のアクセスが試みられたことを示し、前記第１のハッシュがアクセスが拒否されたことを示す値を有することを特徴とする請求項１に記載の方法。
【請求項４】
第１のサーバが前記第１のハッシュを生成し、第２のサーバが前記ユーザのアクセスを許可し、前記第１のサーバが前記第２のサーバとは異なることを特徴とする請求項１に記載の方法。
【請求項５】
第１のサーバが前記第１及び第２の許可チケットが一致するかどうかを判断し、第２のサーバが前記ユーザのアクセスを許可し、前記第１のサーバは前記第２のサーバとは異なることを特徴とする請求項１に記載の方法。
【請求項６】
前記第１の許可チケットはウェブサーバ上で生成され、
前記第２の許可チケットはグローバルキャッシュ・サーバ上で生成され、前記第１及び第２の許可チケットが一致するかどうかの判断は、前記グローバルキャッシュ・サーバ上で行われ、
前記第１のハッシュは、プレイリストサーバ上で生成され、
前記第１のハッシュを生成する段階、前記第１及び第２のハッシュが一致するかどうかを判断する段階、及び前記ユーザの前記メディアファイルへのアクセスを許可する段階が、全てメディアサーバ上で行われることを特徴とする請求項１に記載の方法。
【請求項７】
前記リクエストは、ユーザのコンピュータから受け取られ、前記データは、前記ユーザのコンピュータ上のクッキーであることを特徴とする請求項１に記載の方法。
【請求項８】
前記データは、ランダムに生成されたストリングであることを特徴とする請求項１に記載の方法。
【請求項９】
前記データは、ゼロ値であることを特徴とする請求項１に記載の方法。
【請求項１０】
前記データは、日付であることを特徴とする請求項１に記載の方法。
【請求項１１】
前記データは、未来の日付であることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記データは、現在の日付であることを特徴とする請求項１０に記載の方法。
【請求項１３】
前記データは、過去の日付であることを特徴とする請求項１０に記載の方法。
【請求項１４】
前記第２の時間に第３の許可チケットを生成する段階と、
前記第１の許可チケットを前記第２及び第３の許可チケットと比較する段階と、を更に含む請求項１に記載の方法。
【請求項１５】
前記第１の許可チケットと前記第２の許可チケットは、時間に基づくことを特徴とする請求項１に記載の方法。
【請求項１６】
前記時間は、未来の時間であることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記時間は、現在の時間であることを特徴とする請求項１５に記載の方法。
【請求項１８】
前記時間は、過去の時間であることを特徴とする請求項１５に記載の方法。
【請求項１９】
前記第１の許可チケットと前記第２の許可チケットは、セキュリティキーに基づくことを特徴とする請求項１に記載の方法。
【請求項２０】
前記第１の許可チケットと前記第２の許可チケットは、前記メディアファイルの識別子に基づくことを特徴とする請求項１に記載の方法。
【請求項２１】
前記第１のハッシュと前記第２のハッシュが更に、時間に基づくことを特徴とする請求項１に記載の方法。
【請求項２２】
前記時間は、未来の時間であることを特徴とする請求項２１に記載の方法。
【請求項２３】
前記時間は、現在の時間であることを特徴とする請求項２１に記載の方法。
【請求項２４】
前記時間は、過去の時間であることを特徴とする請求項２１に記載の方法。
【請求項２５】
前記第１のハッシュと前記第２のハッシュが更に、セキュリティキーに基づくことを特徴とする請求項１に記載の方法。
【請求項２６】
前記第１のハッシュと前記第２のハッシュが更に、メディアファイルの識別子に基づくことを特徴とする請求項１に記載の方法。
【請求項２７】
メディアファイルへのアクセスを制御するためのシステムであって、前記システムが、
前記メディアファイルへアクセスするリクエストに応答して第１の時間に第１の許可チケットを生成し、
前記第１の許可チケットとは関係なく第２の時間に第２の許可チケットを生成して、前記第１の許可チケットと前記第２の許可チケットを比較することによって前記メディアファイルへのアクセスを認可するかどうかを判断し、
前記第２のプロセッサの判断に基づいて第１のハッシュを生成し、
第２のハッシュを生成し、
前記第１のハッシュと前記第２のハッシュとを比較することによって前記メディアファイルへのアクセスを認可するかどうかを判断し、
前記第１のハッシュと前記第２のハッシュとの比較に基づいて前記メディアファイルへのアクセスを許可する、
ようにソフトウェアが動作可能な１つ又はそれ以上のプロセッサを含むことを特徴とするシステム。
【請求項２８】
前記アクセスの制御は、複数のメディアファイルへのアクセスの制御であることを特徴とする請求項２７に記載のシステム。
【請求項２９】
ウェブサーバ、ローカル記憶装置を有するグローバルキャッシュ・サーバ、プレイリストサーバ、及びメディアサーバを更に含み、
前記ウェブサーバは、前記メディアファイルへアクセスするリクエストに応答して第１の時間に第１の許可チケットを生成し、
前記グローバルキャッシュ・サーバは、前記第１の許可チケットとは無関係に第２の時間に第２の許可チケットを生成して、前記第１の許可チケットと前記第２の許可チケットとを比較することによって前記メディアファイルへのアクセスを認可するかどうかを判断し、
前記プレイリストサーバは、前記第２のプロセッサの判断に基づいて第１のハッシュを生成し、
前記メディアサーバは、前記第１のハッシュと前記第２のハッシュとを比較することによって前記メディアファイルへのアクセスを認可するかどうかを判断し、前記第１のハッシュと前記第２のハッシュとの比較に基づいて前記メディアファイルへのアクセスを許可することを特徴とする請求項２７に記載のシステム。
【請求項３０】
メディアファイルへのアクセスを制御するための方法であって、前記方法は、
関連する第１のユーザデータを有する第１のユーザからリクエストを受け取る段階と、
前記第１のユーザデータに基づいて第１の許可チケットを生成する段階と、
前記第１のユーザデータに基づいて第２の許可チケットを生成する段階と、
前記第１の許可チケットが前記第２の許可チケットと一致することを判断し、これにより前記第１のユーザが許可されていることを示す段階と、
前記許可チケット及び前記第１のユーザのリクエストの前記判断に基づいて、第１のハッシュを生成する段階と、
関連する第２のユーザデータを有する前記第２のユーザからのリクエストを受け取る段階と、
前記第２のユーザのリクエストに応答して第２のハッシュを生成する段階と、
前記第１のハッシュと前記第２のハッシュとが一致しないことを判断し、これにより前記第２のユーザが許可されなかったことを示す段階と、
前記第２のユーザの前記メディアファイルへのアクセスを拒否する段階と、
を含む方法。
【請求項３１】
前記第１のユーザのリクエストに応答して、前記第１の許可チケットと前記第２の許可チケットとの比較に基づいて第３のハッシュを生成する段階と、
前記第１のハッシュが前記第３のハッシュと一致することを判断し、これにより前記第１のユーザが許可されていたことを示す段階と、
前記第１のユーザが前記メディアファイルへアクセスするのを認可する段階と、
を更に含む請求項３０に記載の方法。
【請求項３２】
前記アクセスを制御する段階が、複数のメディアファイルへのアクセスを制御する段階であることを特徴とする請求項３０に記載の方法。
【請求項３３】
前記第３のデータは、第４のデータであることを特徴とする請求項３０に記載の方法。
【請求項３４】
１つ又はそれ以上のプロセッサに、
メディアファイルへアクセスするリクエストに応答して生成された第１の許可チケットを受け取り、
前記第１の許可チケットとは無関係に第２の許可チケットを生成し、
前記第１の許可チケットと前記第２の許可チケットとを比較し、
前記許可チケット及びデータの比較に基づいて第１のハッシュを生成し、該第１のハッシュを転送する、
ように指示するためのコンピュータコードを含むコンピュータ読み取り可能媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公表番号】特表２００７−５１９３０３（Ｐ２００７−５１９３０３Ａ）
【公表日】平成１９年７月１２日（２００７．７．１２）
【国際特許分類】
【出願番号】特願２００６−５３６７３３（Ｐ２００６−５３６７３３）
【出願日】平成１６年１０月２０日（２００４．１０．２０）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０３４６３５
【国際公開番号】ＷＯ２００５／０４８０２９
【国際公開日】平成１７年５月２６日（２００５．５．２６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（５０１４３８４８５）ヤフー！ インコーポレイテッド (200)
【Ｆターム（参考）】
【公表日】平成１９年７月１２日（２００７．７．１２）
【国際特許分類】
【出願日】平成１６年１０月２０日（２００４．１０．２０）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０３４６３５
【国際公開番号】ＷＯ２００５／０４８０２９
【国際公開日】平成１７年５月２６日（２００５．５．２６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（５０１４３８４８５）ヤフー！ インコーポレイテッド (200)
【Ｆターム（参考）】
[ Back to top ]