JP2005508536A - デジタル・コンテンツおよびストリーミングデータへのアクセスを管理する方法 - Google Patents

Abstract

【課題】ストリーミング・メディアを含むデジタル・コンテンツへのアクセスを管理する方法。
【解決手段】システムは、ネットワークに接続されるウェブ・サーバ（１０６）、メディア・サーバ（１０４）、およびパーソナルコンピュータのようなエンド・ユーザ・プロセッサ（１０２）を備える。ウェブ・サーバ（１０６）は、ファイルへのアクセスに対するエンド・ユーザのリクエストに応じて暗号化されたチケットを生成する。チケットは、チケットが生成された時間、またはそれに近接した時間に少なくとも一部基づく。メディア・サーバ（１０４）は、好ましくはウェブ・サーバ（１０６）と同じ暗号化アルゴリズムを用いて、認証チケットを生成する。メディア・サーバ認証チケットは、メディア・サーバ（１０４）がファイルへのアクセスに対するリクエストを受信した時間、またはそれに近接した時間に少なくとも一部基づく。メディア・サーバ（１０４）は、ウェブ・サーバ（１０６）によって生成されたチケットとメディア・サーバ（１０４）によって生成されたチケットを比較する事によって、ファイルへのアクセスを許可するかどうかを判断する。
【選択図】図１

Description

【技術分野】
【０００１】
本出願は、２００１年６月６日に出願された、「ストリーミング・メディアを含むデジタル・コンテンツへのアクセスを管理するシステムおよび方法」という名称の国際出願第ＰＣＴ／ＵＳ０１／１８３２４号の一部継続出願であり、本願明細書において援用されるものとする。
【０００２】
本発明は、広義にはデジタル・コンテンツへのアクセスを管理する事に関し、より詳細には、時間に一部基づくチケットに基づいてシステムおよびストリーミング・メディアへのアクセスを制限する方法に関する。
【背景技術】
【０００３】
インターネットとワールドワイド・ウェブの普及により、ストリーミング・メディア・コンテンツのようなデジタル・コンテンツの配信に関連する産業が発展した。例えば、ストリーミング・メディアは、エンターテインメント、通信教育および企業目的を含む多数の目的のうちの何れかのために使用され得る。エンターテインメント会社は映画とスポーツイベントをストリーミングし、通信教育会社は教育のコンテンツをストリーミングし、また、企業はトレーニング教材をストリーミングする。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
このようなストリーミング・メディアの多くの用途において、コンテンツへのアクセスを管理する事は必要不可欠である。例えば、エンターテインメント会社は、ストリーミング・メディアのアイテムをエンド・ユーザが視聴する毎に課金し得るが、これはエンターテインメント業界においては「ペイ・パー・ビュー」と称されている。同様に、通信教育会社は、オンライン教育のコースへのアクセス、およびストリーミング・メディアへのアクセスに対して、学生に課金する。企業関係のコンテンツは多くの場合機密であり、従って、管理されたアクセスを必要とする。
【０００５】
従って、ストリーミング・メディアへのアクセスを制限するために各種のシステムが開発されている。ストリーミング・コンテンツへのアクセスを制限するための現在の業界標準は、ストリーミング・メディア・コンテンツを提供するのに先立ってエンド・ユーザを確認するストリーミング・メディア・サーバを含んでいる。より具体的には、ストリーミング・メディア・サーバは、ストリーミング・メディアへのアクセスを許可するかどうかを判断するロジックを含むコンパイルされたプログラムのソフトウェア・プラグインを含んでいる。しかしながら、そのような認証プラグインはしばしば複雑になり、開発・維持が困難である。例えば、ストリーミング・メディア・コンテンツへのアクセスを許可するロジックを変更する必要性が生じた場合、ストリーミング・メディア・サーバ上のコンパイルされたプラグインの変更は困難である。更に、ストリーミング・メディア・サーバに存在するロジックの全てにおいて、ストリーミング・メディア・サーバは、データベースあるいは各所に配置されるメッセージ転送サービスに対して直接アクセスしていなければならない。さらに、ストリーミング・メディア・コンテンツにアクセスすることを認められているような特定のエンド・ユーザを確認するような例においてさえも、そのようなエンド・ユーザは多くの場合無許可のエンド・ユーザとアクセスを共有することにより許可プロセスの裏をかくことができる。このようなアクセスの共有は、コンテンツへのリンクのユーザ名およびパスワードを共有する事のような多くの形式を取り得る。同様の問題が、他の形式のデジタル・コンテンツへのアクセスを管理するために使用されるシステムにおいても存在する。従って、デジタル・コンテンツ、具体的にはストリーミング・メディア・コンテンツへのアクセスを管理し、エンド・ユーザを許可するための改善されたシステムおよび方法が必要となっている。
【課題を解決するための手段】
【０００６】
本発明は、オーディオ、ビジュアル、ビデオ、テキスト、ストリーミング・メディアのようなデジタル・コンテンツへのアクセスを管理するシステムおよび方法を提供する事によって、上記の、および他のニーズを解決する。本発明に係る１つのシステムおよび方法はストリーミング・メディアへのアクセスを管理し、ネットワークに接続されたウェブ・サーバ、メディア・サーバ、およびパーソナルコンピュータのようなエンド・ユーザ・プロセッサを備える。
【０００７】
運用において、エンド・ユーザのファイルのアクセスに対するリクエストに応答して、暗号化されたチケットを生成する。チケットは、チケットが生成された時間、またはそれに近接した時間に少なくとも一部基づく。一実施形態において、チケットは、例えばセキュリティ・タイム・インターバルまたはエンド・ユーザ識別子のような付加的な情報に基づく。
【０００８】
メディア・サーバがリクエストされたファイルへのアクセスを提供するのに先立って、メディア・サーバは、好ましくはウェブ・サーバと同一の暗号化アルゴリズムを用いて認証チケットを生成する。メディア・サーバ認証チケットは、メディア・サーバがファイルへのアクセスに対するリクエストを受信した時間、またはそれに近接した時間に少なくとも一部基づく。メディア・サーバは、ウェブ・サーバによって生成されたチケットとメディア・サーバによって生成されたチケットを比較する事によって、ファイルへのアクセスを許可するかどうかを判断する。
【０００９】
一実施形態において、これらのチケットが一致しない場合、ウェブ・サーバがチケットを生成した時間とメディア・サーバがチケットを生成した時間との差が、所定の量よりも大きく、チケットは論理的に「有効期限切れ」であると考えられる。従って、メディア・サーバは、メディア・コンテンツに対するアクセスを許可しない。これらのチケットが一致する場合、これらのチケットは認可されたタイム・インターバルの範囲内に生成されており、メディア・サーバは、エンド・ユーザがリクエストしたメディア・コンテンツにアクセスする事を許可する。
【発明を実施するための最良の形態】
【００１０】
本発明の特定の好ましい実施形態は、図面に関して記載されている。コンテンツに対するアクセスを管理するための本発明は、ストリーミング・メディア・ファイルに対するアクセスの管理に関するコンテキストで記載されているが、本発明が全ての種類のメディアまたはファイルに適用され得る事が理解されよう。さらに、本願明細書において記載される実施形態はオンデマンドのストリーミング・メディアに関するものであるが、本実施例がライブのストリーミング・メディアに適用できることは、当業者にとって認識される。
【００１１】
一般に、本実施形態のシステムは、エンド・ユーザ・プロセッサ１０２、ストリーミング・メディア・サーバ１０４、およびコンテンツ・マネジメント（ＣＭ）データベース１０８を備えるウェブ・サーバ１０６を有し、これらの全てがインターネットに接続される。エンド・ユーザ・プロセッサ１０２は、インターネット・エクスプローラーと言う名称でマイクロソフト社より提供されるか、または、ネットスケープ・ナビゲータと言う名称でネットスケープ・コミュニケイションズより提供されるようなインターネット・ブラウザ、および、ウインドウズ・メディア・プレーヤーと言う名称でマイクロソフト社より提供される、また、リアルプレーヤーと言う名称でリアル・ネットワークス社によって提供されるストリーミング・メディア・プレーヤーを含む。ウェブ・サーバ１０６はエンド・ユーザ１０２によってアクセス可能なウェブサイトを提供する。ストリーミング・メディア・サーバ１０４上に存在するストリーミング・メディア・コンテンツにアクセスするために、ウェブサイトはエンド・ユーザ１０２によって起動可能なリンクを含む。
【００１２】
本発明は、任意のコンピュータ技術の使用に際して適用し得る事が理解されよう。例えば、本実施形態はインターネットによってコンテンツへのアクセスを提供する事に関するが、本発明は、例えば広域ネットワークを含む任意のコンピュータネットワーク上に使用され得る。同様に、エンド・ユーザ・プロセッサ１０２は、例えばＰＤＡ、ウェブ対応の携帯電話、ネットワークにダイアルアップする有線電話、モバイル・コンピュータ、パーソナルコンピュータ、インターネット装置等のネットワークに接続し得る任意のデバイスであり得る。更に、ここに記述されたサーバは、任意のソフトウエアを実行する任意の種類のもので有り得、また、ここに記述されたソフトウェア・モジュール、オブジェクトおよびプラグインは、任意のプログラム言語で記述され得る。最後に、ここに記述されたデータベースおよび記憶装置は、例えばローカルのコンピュータ・メモリー、ネットワークに接続された記憶装置、および磁気あるいは光学のような任意の公知の記憶媒体の様な任意の記憶技術を利用し得る。
【００１３】
ＣＭデータベース１０８の一例が図２に示される。図示されるように、データベース１０８は、全てのストリーミング・コンテンツに普遍的に適用可能な情報と、関連データの幾つかのテーブルを含む。普遍的な情報２０２はセキュリティ・キー、セキュリティ・インターバル、およびコンテンツが保存されているストリーミング・メディア・サーバ１０４の名前（「ホスト名」）を含んでいる。セキュリティ・キーおよびセキュリティ・インターバルは、エンド・ユーザ１０２がコンテンツにアクセスすることを許可するために使用され、秘密にされ、かつ、コンテンツの所有者によって設定される事が望ましい。セキュリティ・キーおよびセキュリティ・インターバルは全てのコンテンツに対するアクセスを管理するために使用されるが、他の実施形態においては、各コンテンツ・ファイルがそれ自身に関するセキュリティ・キーおよびセキュリティ・インターバルを有する。
【００１４】
ＣＭデータベース１０８は、コンテンツあるいはストリーミング識別情報を含む一連のテーブルをさらに有する。より詳細には、ストリーミング・テーブル２０４は、ユニークなストリーミング識別子（ＩＤ）によって識別されるそれぞれのストリーミング・コンテンツのレコードを含む。更に、各レコードは、例えばコンテンツ・ファイルの作成日を含むコンテンツ・ファイルについて記述するストリーミングの詳細、ファイルの記述、コンテンツがオーディオであるかビデオであるかの識別子、コンテンツが関係するプラットフォーム、コンテンツが最後に修正された日付、コンテンツを視聴するのに必要なコーデック、コンテンツの長さおよびサイズ、コンテンツの有効期限（もしあれば）、．ａｓｆまたは．ｒｍのようなストリーミングの種類、コンテンツのタイトルおよびコンテンツの作者、コンテンツのステータス、コンテンツの著作権情報、コンテンツのビットレート等を含む。各レコードは更に、メディア・サーバ１０４へのリンクを生成するために使用される接頭部 （「ＵＲＬ接頭部」）、およびストリーミング・メディア・サーバ１０４に格納されているコンテンツ・ファイルの名前（「ファイル名」）を含む。ファイル名は、オンデマンドのコンテンツ用のストリーミング・メディア・サーバ１０４に接続された記憶装置上の実際のパスを指しても良いし、ファイル名は、ライブのストリーミング用の別名、チャネルまたはポートを指しても良い、と言う事が理解されるべきである。
【００１５】
データベース１０８は「再生リスト」情報を有するテーブルを含む。クライアントの再生リストは、一般に、グループとして利用可能になされる目的で論理上関連した、１以上のコンテンツ・ファイルのグループである。再生リストの一部であると確認された各コンテンツ・ファイルもまた個々に利用可能になされ得る。このような再生リスト情報は、再生リストテーブル２０８および再生リスト・ストリーミング・テーブル２１０に含まれる。一般に、再生リストテーブル２０８は、再生リストＩＤによって識別される各再生リストを識別するレコードを含む。各レコードは、例えば再生リストのフォーマット（例えばウインドウズ・メディア・プレーヤーまたはリアルプレーヤー）、再生リストの記述、再生リスト名および同種のもの、および再生リストに対する許可ユーザ・グループＩＤを含む、再生リスト詳細をさらに含む。
【００１６】
許可ユーザ・グループＩＤは、特定の再生リストを視聴することを認められるエンド・ユーザ１０２のグループに対応する。より詳細には、データベース１０８は、ユニークなエンド・ユーザＩＤによって識別される各エンド・ユーザ１０２を１以上の許可ユーザ・グループＩＤに関連付ける許可ユーザ・テーブル２０６をさらに含む。エンド・ユーザ１０２が再生リストを視聴するために、エンド・ユーザ１０２が該コンテンツ・ファイルのための許可ユーザ・グループＩＤの一部であるということが確認されなければならない。他の実施形態においては許可グループＩＤは使用されない場合もあり、更に他の実施形態においては、コンテンツ・ファイルのそれぞれが、該ファイルに関連付けられた許可グループＩＤを有する。
【００１７】
再生リスト・ストリーミング・テーブル２１０は、再生リストＩＤによって識別される再生リストと、ストリーミングＩＤによって識別される構成コンテンツ・ファイルとを関連付けるレコードを有する。さらに、各レコードは、再生リスト中の各コンテンツ・ファイルの順番を示す情報（「ソート順番」）を含んでいる。
【００１８】
本実施形態において使用されるコンポーネントについて記載してきたが、ここで、ストリーミング・メディア・コンテンツへのアクセスを管理するプロセスについて記述する。概説すると、ウェブ・サーバ１０６に保存された許可ソフトウエア・コンポーネントは、公開暗号キー情報、プライベート・キー情報および現在時刻に基づいたハッシュ値即ち「チケット」を生成する。公開暗号キーは、エンド・ユーザ１０２およびエンド・ユーザのユーザＩＤによってリクエストされるストリーミング・コンテンツが有するユニーク識別子である。プライベート・キーは、コンテンツの所有者によって設定されたセキュリティ・キーとセキュリティ・インターバルを含む。
【００１９】
リクエストされたコンテンツが格納されているストリーミング・メディア・サーバ１０４は、公開暗号キーを含むストリーミング・リクエストと、ウェブ・サーバ１０６によって生成されたチケットを受信する。ストリーミング・メディア・サーバ１０４は、自身のチケットを生成するために、ローカルに格納されたプライベート・キー情報を使用するプロセスへと進む。ストリーミング・メディア・サーバ１０４は、ストリーミング・メディア・サーバ１０４およびウェブ・サーバ１０６によって生成されるチケットを比較することによって、リクエストされたストリーミング・メディアを供給するか、もしくは供給を拒否する。
【００２０】
アクセスを管理するプロセスが、図３のワークフロー・ダイアグラムおよび図４および図５のフローチャートによって詳細に記述される。本実施例において、エンド・ユーザ１０２があるストリーミング・メディア・コンテンツ・ファイルへのアクセスをリクエストする。最初、ウェブ・サーバ１０６は、認証アプリケーションにログインすることをエンド・ユーザにリクエストし、あるストリーミング・メディアを視聴する選択肢をエンド・ユーザに提供するウェブ・ページを供する。（ステップ３０２）。例えば、このようなページは、いくつかのコンテンツ・ファイルのうち、視聴するための１つのコンテンツを選択することをエンド・ユーザにリクエストするフォームを含んでいてもよく、このフォームは、コンテンツの所有者が前もって割り当ててエンド・ユーザに提供したエンド・ユーザＩＤと、選択するコンテンツのアクセスに対してエンド・ユーザが課金されるようにクレジットカード番号を提供するために用いられる。他の実施形態において、エンド・ユーザはエンド・ユーザの連絡情報および請求書発行情報を提供することによりコンテンツの所有者にあらかじめ登録され、コンテンツの所有者は、エンド・ユーザの連絡情報および請求書発行情報を、登録されたエンド・ユーザＩＤと共にテーブル形式で保存する。
【００２１】
ウェブ・ページに応答して、エンド・ユーザはエンド・ユーザのユーザＩＤを提供し、リンクを起動し、これによって、認証アプリケーションにログインし、該リンクに関連する特定のストリーミング・メディア・コンテンツ・ファイルへのアクセスをリクエストする。（ステップ３０４）。ストリーミングＩＤが“１２３４５６”で表されるストリーミング・リクエストの一例が以下に示される。＜Ａ ｈｒｅｆ ｈｔｔｐ：／／ｗｅｂｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｇｅｔｓｔｒｅａｍ．ａｓｐ？ＩＤ＝１２３４５６＞。
【００２２】
本実施形態において、認証アプリケーションは、ウェブ・サーバ１０６上に存在する「．ｄｌｌ」ソフトウエア・コンポーネントである。しかしながら、ここに記述された機能性を実施するために、例えばアクティブ・サーバー・ページ（ＡＳＰ）またはサーブレットのような他のプログラム言語あるいは技術を使用し得ることを、当業者は認識するであろう。特定のプログラミング技術に関係なく、認証アプリケーションは、エンド・ユーザ・プロセッサ１０２上の如何なる処理障害をも緩和するためにウェブ・サーバ１０６上で実行されることが望ましい。
【００２３】
一旦エンド・ユーザが認証アプリケーションにログインし、ウェブ・サーバ１０６がエンド・ユーザからストリーミング・リクエストおよびエンド・ユーザＩＤを受け取れば、ウェブ・サーバ１０６は、認証チケットを動的に生成し、選択されたコンテンツ・ファイルへのリンクを動的に生成することを継続する。より詳細には、認証アプリケーションの管理下において、ウェブ・サーバ１０６は、認証チケットを生成する際に使用するためのプライベート・キーをデータベース１０８に対してリクエストする。（ステップ３０６）。ウェブ・サーバ１０６は、リクエストされたコンテンツ・ファイルに関連したセキュリティ・キーおよびセキュリティ・インターバルを含むプライベート・キーをＣＭデータベース１０８から検索するためにデータベース・クエリーを発行する。これを受けて、ＣＭデータベース１０８はウェブ・サーバ１０６にプライベート・キーを返送する。（ステップ３０８）。
【００２４】
データベース１０８からプライベート・キーを取得した後、ウェブ・サーバ１０６はチケットを生成する。（ステップ３１０）。図４に関してより詳細に記述されるように、ウェブ・サーバ１０６は、チケットを生成するためにプライベート・キー、ストリーミングＩＤ、エンド・ユーザＩＤ、現在時刻およびハッシュ・アルゴリズムを利用する。本実施形態において、リクエストされたコンテンツのストリーミングＩＤが、ステップ３０４においてエンド・ユーザによって起動されたストリーミング・リクエスト・リンクに含まれているので、ウェブ・サーバ１０６は、チケットを生成する際にストリーミングＩＤを使用することができる。しかしながら、他の実施形態においては、エンド・ユーザによって提供されるストリーミング・リクエストは、例えばコンテンツのタイトル、作者、および（または）ファイル名の様な、ストリーミングＩＤ以外のユニーク識別情報を含む。このような実施形態において、ウェブ・サーバ１０６はストリーミング・テーブル２０４を検索し、ストリーミング・リクエストに含まれる識別情報に基づいてストリーミングＩＤを検索する。更に他の実施形態において、ストリーミング・リクエストは、チケットがシステムを生成する際に使用するファイル名またはパスのような、ストリーミングＩＤ以外のユニーク識別子を含む。
【００２５】
一旦チケットが生成されれば、ウェブ・サーバ１０６はメディア・サーバ１０４上に存在するリクエストされたコンテンツへのリンクを生成する。より詳細には、上に例示したストリーミング・リクエストに基づいて、エンド・ユーザ・プロセッサ１０２に存在するメディア・プレーヤーが、メディア・サーバ１０４へのリンクを動的に生成するためのプログラム「ｇｅｔｓｔｒｅａｍ．ａｓｐ」を実行する「ｗｅｂｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」（即ち、ウェブ・サーバ１０６）へ回線を接続する。（ステップ３１２）。当業者は、「ｇｅｔｓｔｒｅａｍ」アプリケーションはアクティブ・サーバー・ページ（即ちＡＳＰ）の拡張子を有しているが、ＡＳＰ技術を使用することが必ずしも必要ではないことを認識するであろう。むしろ、「．ｄｌｌ」コンポーネントの様な任意のプログラミングまたはスクリプト言語または技術が所望の機能性を提供するために使用され得る。しかしながら、認証アプリケーションにおいて、エンド・ユーザ・プロセッサ１０２における如何なる処理障害をも緩和するために、該プログラムはサーバ側で実行されることが望ましい。「ｇｅｔｓｔｒｅａｍ．ａｓｐ」プログラムは、メディア・サーバ１０４へのリンクを動的に生成するのに必要となるデータを検索するため、ウェブ・サーバ１０６がＣＭデータベース１０８を呼び出す様に機能する。より詳細には、ウェブ・サーバ１０６は、普遍情報テーブル２２０およびＵＲＬ接頭部からホスト名を検索し、ストリーミング・テーブル２０４からファイル名を検索する。更に、「ｇｅｔｓｔｒｅａｍ．ａｓｐ」プログラムはストリーミングＩＤ、チケットおよびエンド・ユーザＩＤをリンクの端部に付加する。その後、ウェブ・サーバ１０６は、エンド・ユーザ・プロセッサ１０２のメディア・プレーヤーへリンクを返送する。（ステップ３１４）。
【００２６】
メディア・ファイルへのリンクの実例は以下の通りである。＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍ１．ａｓｆ？ＩＤ＝１２３４５６＆ＴＩＣＫＥＴ＝ｕｖｗ１２３ｘｙｚ＆ＵＳＥＲ＿ＩＤ＝ａｂｃ１２３ｄｅｆ”＞。ここで、ＵＲＬ接頭部は「ｍｍｓ：／／」によってリクエストされ、ホスト名は「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」によって表わされ、ファイル名は「ｓｔｒｅａｍ１．ａｓｆ」によって表わされ、リクエストされたコンテンツのストリーミングＩＤは「１２３４５６」によって表わされ、チケットは「ｕｖｗ１２３ｘｙｚ」によって表わされ、そして、エンド・ユーザＩＤは「ａｂｃ１２３ｄｅｆ」によって表わされる。
【００２７】
リンクを受信した後、エンド・ユーザ・プロセッサ１０２はストリーミング・メディア・コンテンツをリクエストするステップに進む。（ステップ３１６）。より詳細には、エンド・ユーザ・プロセッサ１０２に存在するメディア・プレーヤーがリンクによって識別される「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」（即ち、ストリーミング・メディア・サーバ１０４）を呼び出す。呼び出しの一部として、メディア・プレーヤーは、リクエストしたコンテンツのストリーミングＩＤのコピー、ウェブ・サーバ１０６によって生成されたチケット、およびエンド・ユーザＩＤをストリーミング・メディア・サーバに１０４に供給する。
【００２８】
ストリーミングＩＤ、エンド・ユーザＩＤおよびチケットを含んでいるリンクを受信した後、ストリーミング・メディア・サーバ１０４は、リクエストされたコンテンツへのアクセスをエンド・ユーザに許可するかどうかを判断するステップに進む。（ステップ３１８）。図５に関してより詳細に以下記述されるように、ストリーミング・メディア・サーバ１０４は、ローカルに格納されたプライベート・キー情報およびリンク中に含まれるストリーミングＩＤおよびエンド・ユーザＩＤに基づいてチケットを個々に生成することにより、アクセスを付与するかどうかを判断する。一般的に、ストリーミング・メディア・サーバ１０４によって生成されたチケットがウェブ・サーバ１０６によって生成されたチケットと一致する場合、ストリーミング・メディア・サーバ１０４はエンド・ユーザ・プロセッサ１０２にリクエストされたストリーミング・メディア・コンテンツを供給する。（ステップ３２０）。
【００２９】
ウェブ・サーバ１０６によってチケットを生成するプロセスが、図４を参照して詳細に記述される。上述したように、チケット生成プロセスは、ウェブ・サーバ１０６に存在する許可ソフトウェア・プラグインによって行なわれることが好ましい。本実施形態において、本プロセスは、ウェブ・サーバ１０６がストリーミングＩＤおよびエンド・ユーザＩＤを含むストリーミング・リクエストを受信するステップより開始される。（ステップ４０２）。その後、ウェブ・サーバ１０６は、リクエストされたストリーミングＩＤに関連したプライベート・キー情報を検索するためにデータベース１０８にアクセスするステップへと進む。（ステップ４０６）。このようなプライベート・キー情報は普遍的なセキュリティ・キーおよびセキュリティ・インターバルを含む。他の実施形態において、各ストリーミングはストリーミング・テーブル２０４にフィールドとしてそれ自身のセキュリティ・キーおよびセキュリティ・インターバルを格納し、ウェブ・サーバ１０６はストリーミング・リクエストに含まれるストリーミングＩＤに基づいてストリーミング・テーブル２０４検索する。
【００３０】
上述されるように、ウェブ・サーバ１０６は、チケットを生成するために現在時刻を更に使用する。より詳細には、ウェブ・サーバ１０６は現在時刻を計算し、セキュリティ・インターバルに最も近い倍数までその時刻を切り下げる。（ステップ４１０）。本実施形態において、Ｃプログラミング言語の標準ライブラリー関数「ｔｉｍｅ（）」によって生成されるような協定世界時（ＵＴＣ）を秒単位で利用する。変数「＄ｔｉｍｅ」によって表される、セキュリティ・インターバルに最も近い倍数まで切り下げられた時間を生成するためのＰｅｒｌプログラム・コードの一例を以下に示す。
【表１】

ここで、変数「＄ｉｎｔｅｒｖａｌ」はセキュリティ・インターバルに対応しており、セキュリティ・インターバルは１５分である。
【００３１】
例えば、現在の時刻が２０００年５月３１日午後２：１６：０７（中部標準時）であった場合、関数「ｔｉｍｅ（）」は、おおよそ「９５９８００５６７」の値を返す。直近の１５分インターバルにこのＵＴＣ時間を切り下げることによって「９５９８００５００」が得られ、これは、２０００年５月３１日午後２：１５：００（中部標準時）に相当する。
【００３２】
先に例示したコードは変更されても良く、その変更されたコードもまた本発明の範囲内であり得る事が理解されよう。例えば、セキュリティ・インターバルは数分である必要は無く、インターバルが「ｔｉｍｅ（）」関数によって用いられる時間の単位で表わされるように適切な変換が行なわれる限り、インターバルは他の時間の単位で表わされも良い。更に、他の実施形態において、現在時刻はＵＴＣ以外の標準時に基づく。そのような実施形態において、時間の標準は、ウェブ・サーバ１０６およびストリーミング・メディア・サーバ１０４に固有のものである。また、エンド・ユーザ・プロセッサ１０２に時間を計算させ、かつ認証チケットを生成する際に用いられるべく、ウェブ・サーバ１０６へその値を送信させることもまた、本発明の範囲内であることが理解されよう。更に他の実施形態において、セキュリティ・インターバルは、標準時が所望の桁数まで単に切り下げられるように選択される。
【００３３】
一旦、ウェブ・サーバ１０６がハッシュに対して入力された値（アルゴリズム公開暗号キー情報、プライベート・キー情報および時刻）を有すれば、ウェブ・サーバ１０６は、ハッシュ・アルゴリズムへの入力ストリングを生成する。（ステップ４１４）。本実施形態において、ハッシュ・アルゴリズムは「ＭＤ５」のメッセージ・ダイジェスト・アルゴリズムである。さらに、本実施形態においては、メディア・サーバ１０４およびウェブ・サーバ１０６は同じアルゴリズムを利用する。
【００３４】
チケットを生成する任意のハッシュあるいは暗号アルゴリズムを利用する事は、本質的に本発明の範囲内である事が理解されよう。更に、チケットを生成する２つのサーバ（先の実施形態においては、ウェブ・サーバ１０６およびストリーミング・メディア・サーバ１０４）は、同一の入力に基づいて同一のチケットを生成するか、同一の入力に基づいて、相互の偏差が所定の範囲内のチケットを生成する事が望ましい。他の実施形態において、セキュリティを増加させるために、複数の利用可能なアルゴリズムの１つが使用される。例えば、そのような実施形態は、複数の利用可能なアルゴリズムから任意に選択された１個のアルゴリズムを使用するか、もしくは、リクエストされたコンテンツ、リクエストの日付と時間、特定のエンド・ユーザ、コンテンツを有するエンティティ等に基づいて複数のアルゴリズムから１つを選択する事も可能である。このような実施形態において、システムは、ウェブ・サーバによって使用されるアルゴリズムの指示をメディア・サーバへ転送するか、あるいは、メディア・サーバは、ウェブ・サーバによって利用されるアルゴリズムと同一のアルゴリズムを選択・使用させるロジックを有する。
【００３５】
使用される特定のハッシュ・アルゴリズムに対して入力ストリングが有効である限り、およびストリーミング・メディア・サーバ１０４が入力ストリングの配置を認識している限り、入力値の任意の配置が入力ストリングとして使用されてよい。本実施形態において、次の所定の配置が使用される。
【００３６】
ＴＴＴＴＴＴＴＴＴＴＫＫＫＫＫＫＫＫＫＫＳＳＳＳＳＳＳＳＳＳＵＵＵＵＵＵＵＵＵＵ。
【００３７】
ここで、「Ｔ」は時刻のデジットを表わし、「Ｋ」はセキュリティ・キーの英数字の文字を表し、「Ｓ」はストリーミングＩＤのデジットを表わし（任意の必要な先行・埋め込み文字を含む）、および「Ｕ」は、エンド・ユーザＩＤの英数字の文字を表わす（任意の必要な先行・埋め込み文字を含む）。他の実施形態において、入力ストリングは異なる長さであってもよい。
【００３８】
ハッシュ・アルゴリズム入力ストリングを生成した後、ウェブ・サーバ１０６は入力ストリングにハッシュ・アルゴリズムを適用し、それによってチケットを生成する。（ステップ４１８）。
【００３９】
ストリーミング・メディア・サーバ１０４が、リクエストされたコンテンツ・ストリーミングへのアクセスを許可するかどうかを判断するプロセスが、図５に関連してここに記載される。先ず、必ずしも必要と言うわけではないが、本実施形態におけるメディア・サーバ１０４が３枚の認証チケットを生成し、それぞれのチケットは異なる時刻に基づき、アクセスを許可するべきかどうかを判断するために使用される、と言う事に注目されるべきである。更に、ウェブ・サーバの機能性と同様に、アクセスを許可するべきかどうかを判断するプロセスは、メディア・サーバ１０４上に存在する許可ソフトウエア・コンポーネント中で実行されることが望ましい。
【００４０】
アクセスを許可するべきかどうかを判断する際に、ストリーミング・メディア・サーバ１０４は、エンド・ユーザのプロセッサ１０２上に存在するメディア・プレーヤーから、ストリーミングＩＤ、エンド・ユーザＩＤおよびチケットを含むストリーミング・リクエストを最初に受け取る。（ステップ５０２）。一旦ストリーミング・リクエストが受信されれば、メディア・サーバ１０４はハッシュ・アルゴリズムへの入力ストリングを生成する。この点において、メディア・サーバ１０４はローカルメモリからプライベート・キー情報（すなわちセキュリティ・キーとセキュリティ・インターバル）を検索する。（ステップ５０６）。メディア・サーバ１０４はローカルメモリにプライベート・キー情報を格納するのが望ましいが、他の実施形態においては、メディア・サーバ１０４は、例えばマイクロソフト社によって提供されるＬＤＡＰによってアクセスされるアクティブ・ディレクトリー・ツリーに情報を格納してもよいし、または遠隔のデータベースに情報を格納してもよい。更に他の実施形態において、メディア・サーバ１０４は、ローカル・エリア・ネットワーク（ＬＡＮ）のようなネットワーク接続によってデータベース１０８にアクセスすることにより、プライベート・キー情報を検索する。
【００４１】
ウェブ・サーバ１０６が行ったように、メディア・サーバ１０４は更に現在時刻を計算し、セキュリティ・インターバルに最も近接した倍数にその値の端数を切り下げる。（ステップ５１０）。しかしながら、ウェブ・サーバ１０６と異なり、ストリーミング・メディア・サーバ１０４はメディア・サーバ１０４によって計算されたセキュリティ・インターバルに最も近接した倍数よりも過去の時間である、セキュリティ・インターバルに２番目に近接した倍数に現在時刻を切り下げた第２時刻を更に計算する（ステップ５１０）。更に、メディア・サーバ１０４はセキュリティ・インターバルに最も近接した倍数に現在時刻を切り上げた（つまり、時間的に後となる）第３時刻を計算する。（ステップ５１０）。
【００４２】
その後、メディア・サーバ１０４は、３つの対応するハッシュ入力ストリングを生成するために、検索されたプライベート・キー情報、受信された公開暗号キー情報および３つの時刻を使用する。（ステップ５１４）。その後、メディア・サーバ１０４は、ハッシュ・アルゴリズムに対して３つの入力ストリングを適用し、これによって、３枚のチケットが生成される。（ステップ５１８）。
【００４３】
個々にチケットを生成した後、メディア・サーバ１０４は、メディア・サーバ１０４によって生成されたチケットのうちの任意のチケットがウェブ・サーバ１０６によって生成されたチケットと一致するかどうかを判断する。（ステップ５２２）。チケットが一致しない場合、ストリーミング・リクエストが本物でない、かつ（または）、有効期限切れである（つまり、メディア・サーバ１０４によって生成された時刻が、ユーザのリクエストの時間から測定されるセキュリティ・インターバルの範囲を超えている）可能性が高い。従って、メディア・サーバ１０４はリクエストされたコンテンツへのアクセスを許可しない。（ステップ５２６）。
【００４４】
チケットが一致する場合、ストリーミング・リクエストは本物かつセキュリティ・インターバルの範囲内のものである。しかしながら、アクセスを許可するのに先立って、メディア・サーバ１０４は、エンド・ユーザが既に同じコンテンツへのアクセスを以前にリクエストし、視聴したかどうかを最初に判断する。（ステップ５３０）。メディア・サーバ１０４は、エンド・ユーザＩＤのリストと、ユーザが以前にアクセスを許可されたストリーミングＩＤを対応させてローカルメモリに保持する事が望ましい。エンド・ユーザがリクエストされたコンテンツを既に視聴したかどうかを判断するために、メディア・サーバ１０４は、受信したエンド・ユーザＩＤおよびストリーミングＩＤが既に格納されているかどうかを判断するために、メモリにアクセスする。エンド・ユーザＩＤおよびストリーミングＩＤが既に格納されている場合、エンド・ユーザは、リクエストしたコンテンツに対するアクセスを許可されない。（ステップ５３０）。
【００４５】
受信されるエンド・ユーザＩＤおよびストリーミングＩＤが既に格納されていない場合、メディア・サーバ１０４は、エンド・ユーザＩＤおよびストリーミングＩＤをメモリに格納するステップへと進み（ステップ５３４）、エンド・ユーザにコンテンツへのアクセスを許可する。（ステップ５３８）。故に、エンド・ユーザＩＤおよびストリーミングＩＤを格納することによって、エンド・ユーザがリクエストしたコンテンツを指向するリンクを他人と共有する事を防ぐ事により、更に高度なセキュリティ保護が達成される。
【００４６】
ウェブ・サーバ１０６のローカル時間とメディア・サーバ１０４のローカル時間の間が同期されていない事を補償するために、３つのチケットを使用する事が望ましい事が理解されよう。更に、ある状況では、エンド・ユーザが認証されている場合でも、メディア・サーバ１０４によって生成された第１のチケット（つまり、セキュリティ・インターバルに最も近接した倍数に切り下げた現在時刻に基づく）が、ウェブ・サーバ１０６によって生成された第１のチケットと一致しないであろう。例えば、所定のセキュリティ・インターバルを１５分とすると、ウェブ・サーバ１０６が午後１２：１４：００にチケットを生成し、メディア・サーバ１０４が午後１２：１６：００にその第１のチケットを生成する場合、同じ時間帯の同じ日において、たとえリクエストがセキュリティ・インターバルの範囲内にあってもチケットは一致しない。メディア・サーバ１０４が午後１２：１５：００に対応する時刻に基づいたチケットを生成する一方、ウェブ・サーバは、午後１２：００：００に対応する時刻に基づいたチケットを生成する。従って、本実施形態において、メディア・サーバ１０４は、セキュリティ・インターバルに２番目に近接した倍数に現在時刻を切り下げた時刻に基づいた第２のチケットを生成する。本例においては、午後１２：００：００に対応する。そのため、第２のチケットはウェブ・サーバ１０６によって生成されるチケットと一致する。同様に、セキュリティ・インターバルが経過した後、エンド・ユーザに対してアクセスを許可する事も可能である。したがって、本実施形態において、セキュリティ・インターバルは複数のチケットの使用を補償するように選択されるべきである。ウェブ・サーバ１０６およびメディア・サーバ１０４は、セキュリティ・インターバルの半分の時間内の誤差で合わせられた時計を有する事が望ましい。
【００４７】
メディア・サーバ１０４が、先の実施形態中における３つのチケットの代替として１つ以上の異なるチケットを生成する事もまた、本発明の範囲内である事が理解されよう。更に、先の実施形態においては、並列に生成されるチケットについて記述したが、メディア・サーバ１０４がチケットを直列に順次生成・比較する事もまた、本発明の範囲内である。更に、時刻は多くの方法で生成され得、例えば、メディア・サーバ１０４によって計算された第１の時刻から単にセキュリティ・インターバルを加える、または除する事によって生成されても良い、と言う事が理解されよう。
【００４８】
他の実施形態において、異なったレベルのセキュリティが提供されてもよい。特に、ウェブ・サーバ１０６によって生成されたチケットがメディア・サーバ１０４によって生成されたチケットのうちの１つと一致する場合、メディア・サーバ１０４は同じチケットが既に生成されていたかどうかを判断するステップへと進む。メディア・サーバ１０４は、アクセスが許可されたチケットのリストを保持する。論理上、このようなリストは全ての「使用済」チケットを表している。一致したチケットが「使用済」チケットのリストに載っていない場合、メディア・サーバ１０４は、エンド・ユーザのプロセッサ１０２に存在するメディア・プレーヤーに、リクエストしたコンテンツに対するアクセスを許可する。アクセスを許可するステップの一部として、メディア・サーバ１０４は、「使用済」チケットのリストを更に更新する。一致したチケットが使用済チケットのリストに載っている場合、メディア・サーバ１０４はアクセスを拒否し、リクエストしたエンド・ユーザに適切なメッセージを供給する。使用済チケットをトラッキングする事によって、システムは、認可されたエンド・ユーザがウェブ・サーバ１０６から受信されたストリーミング・リクエストを他人と共有するのを防ぐ。
【００４９】
さらに、アクセスを許可するべきかどうかを判断する際にエラー計算を使用する事も、本発明の範囲内であると言う事が理解されよう。例えば、１つのエラー計算は、所定の期間（例えば１５分、３０分等）、適用可能なセキュリティ・インターバルの設定百分率（例えば、５０％、１２５％等）のセット割合あるいは他のエラー計算のような、エラー・インターバルを現在時刻に加えた、および（または）除した値に基づいて１以上の追加のチケットを生成するメディア・サーバ１０４を伴う。このようなエラー計算は、先の実施形態において、第２時刻または第３時刻の代替値として、またはそれに加えて使用されてもよい。
【００５０】
他の実施形態において、ウェブ・サーバ１０６およびメディア・サーバ１０４は、時刻を先の実施形態とは異なった方法で計算することにより、チケットを生成する。典型的な一実施形態において、ウェブ・サーバ１０６およびメディア・サーバ１０４は現在時刻およびセキュリティ・インターバル以外の或るインターバルの倍数によって切り下げまたは切り上げた現在時刻を計算する。セキュリティ・インターバルが１５分である実施形態の場合、ウェブ・サーバ１０６は、５分のインターバルに最も近接した値に切り下げた現在時刻に基づいてチケットを生成する。次に、ストリーミング・メディア・サーバ１０４は、同じ５分インターバルに切り下げた現在時刻に基づいてチケットを生成する。チケットが一致しない場合、メディア・サーバ１０４は、時間的に遡った次のインターバルに切り下げた時間に基づいてチケットを生成するステップに進む。メディア・サーバは、所定の回数、またはウェブ・サーバとメディア・サーバのチケットが一致するまで、時間的に遡った次のよりインターバルに基づいたチケットを生成し続ける。メディア・サーバ１０４は、その和が少なくともセキュリティ・インターバルに及ぶ複数のタイム・インターバルに基づいて新しいチケットを繰り返し生成する。本実施例において、メディア・サーバ１０４は、合計１５分の５分インターバル、つまり、少なくとも３枚のチケットを生成する。
【００５１】
許可プロセスにおいてエンド・ユーザＩＤの使用を完全に省略するか、あるいは上述された方法とは異なる方法でエンド・ユーザＩＤを使用する事もまた、本発明の範囲内である事が理解されよう。例えば、他の実施形態において、エンド・ユーザＩＤは、ハッシュ・アルゴリズムへの入力ストリングの一部として使用されない。その代わり、データベース１０８は、どのエンド・ユーザがコンテンツへのアクセスをリクエストしたかをトラッキングするためのテーブルを含む。このような実施形態は、ストリーミングＩＤで識別されるコンテンツと、ユーザＩＤで識別され、該コンテンツストリーミングに既にアクセスまたは視聴したエンド・ユーザとを対応付けるレコードを含む視聴ユーザ（ストリーミング）テーブルを含む。同様に、本実施形態は、再生リストＩＤで識別される再生リストと、ユーザＩＤで識別され、該コンテンツストリーミングに既にアクセスしたか視聴したエンド・ユーザとを対応付けるレコードを含む視聴ユーザ（再生リスト）テーブルを含む。認証チケットを生成する前に、ウェブ・サーバは、同じエンド・ユーザが特定のストリーミングおよび再生リストにアクセスする事を既にリクエストしたかどうかを判断するために、適切な視聴ユーザ・テーブルをチェックする。エンド・ユーザが既にアクセスをリクエストしていた場合、ウェブ・サーバはアクセスを拒否するか、あるいは、今回のアクセスに対してエンド・ユーザは再び課金されるであろうということを示すウェブ・ページをエンド・ユーザに供給する。テーブルは、セキュリティ・インターバルのような期間あるいはそれを超過する期間の後に、自動的にクリアーされる。
【００５２】
本発明が、コンテンツの所有者であるクライアントに代わって、ウェブ・サーバ、ストリーミング・メディア・サーバおよび再生リスト・サーバを例えばサービス・プロバイダーが操作するような比較的複雑なシステムに適用される事も可能である、と言う事が理解されよう。このような実施形態が、図６〜図８に関してここに記述される。本実施形態における機能性の多くは図３に示された実施形態における機能性と同一であり、同一の技術のうちで任意のものによって実施され得る、と言う事が当業者によって理解されよう。
【００５３】
図６に示されるように、本システムは図１に示された実施形態の構成要素と同様の構成要素を幾つか含む。本システムは、エンド・ユーザ・プロセッサ６０２、データベース６０８を含む１つ以上のストリーミング・メディア・サーバ６０４、および１つ以上のウェブ・サーバ６０６を含み、これらのすべてはインターネットあるいは他のネットワークへ接続される。さらに、本実施形態におけるシステムは、サービス・プロバイダーによって操作される再生リスト・サーバ６１０を更に含む。データベース６０８を含むウェブ・サーバ６０６、ストリーミング・メディア・サーバ６０４、および再生リスト・サーバ６１０は、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）のようなサービス・プロバイダーのネットワークおよびインターネットに接続される事が好ましい。
【００５４】
一般的に、データベース６０８は図２の実施形態のデータベースに含まれている情報と同じ情報を含んでいるが、該情報はクライアント・アカウント毎に格納される。図７に示されるように、データベース６０８は、アカウントＩＤによって識別される各クライアントのレコードを含むアカウント・テーブル７０２を含む。各レコードは、クライアント名、アドレス、請求書発行情報等のクライアントを識別する情報（「クライアント情報」）、クライアントのコンテンツが保護されているかどうかに関する表示（「コンテンツ保護」）、クライアントのセキュリティ・キー（「セキュリティ・キー」）、およびセキュリティ・インターバル（「セキュリティ・インターバル」）を更に含む。
【００５５】
図２の実施形態と同様に、本データベース６０８は、ストリーミングＩＤによって識別される各コンテンツ・ファイル用のストリーミング識別情報を含むストリーミング・テーブル７０４と、許可されたユーザ・グループＩＤにエンド・ユーザＩＤを対応付ける許可ユーザ・テーブル７０６と、再生リストＩＤによって識別される各再生リスト用の再生リスト識別情報を含む再生リストテーブル７０８と、所定の再生リストＩＤに関連付けられたストリーミングＩＤを識別する再生リスト・ストリーミング・テーブル７１０を更に備える。図２のデータベースに関して記述された情報フィールドに加えて、ストリーミング・テーブル７０４および再生リストテーブル７０８は、各コンテンツ・ファイルおよび各再生リストに関連したアカウントＩＤを識別するフィールドをそれぞれに更に含む。
【００５６】
本データベース６０８は、コンテンツ・ファイルが格納される特定のストリーミング・メディア・サーバ６０４のホスト名を識別し、ストリーミングＩＤによって指定される各コンテンツ・ファイル用のレコードを含むストリーミング・サーバ・テーブル７１２を含む。図２におけるの実施形態と同様、ホスト名はメディア・サーバ６０４のＤＮＳ名である。
【００５７】
本実施形態の動作が、図８のワークフローに関してここに記述される。本実施例の例のために、エンド・ユーザは１つの保護コンテンツを含む再生リストへのアクセスをリクエストする。最初、ウェブ・サーバ６０６は、認証アプリケーションにログインすることをエンド・ユーザにリクエストし、所定のストリーミング・メディアを視聴する選択肢をエンド・ユーザに選択させるウェブ・ページを提供する。（ステップ８０２）。図３の実施形態と同様に、典型的なウェブ・ページは、リンクを起動する事によって特定のコンテンツ・ファイルを選択する事と、エンド・ユーザＩＤを提供する事と、請求書発行情報を提供する事をエンド・ユーザにリクエストするフォームを備え得る。ウェブ・ページに応答して、エンド・ユーザはエンド・ユーザのユーザＩＤおよびクレジットカード情報を提供し、ストリーミング・リクエスト・リンクを起動し、これによって、特定のストリーミング・メディア・コンテンツ・ファイルへのアクセスをリクエストする。再生リストＩＤが「７８９０００」である典型的なストリーミング・リクエスト・リンクは以下のとおりである。＜Ａ ｈｒｅｆ”ｈｔｔｐ：／／ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ？ＩＤ＝７８９０００”＞。
【００５８】
エンド・ユーザがストリーミング・リクエスト・リンクを起動する場合、エンド・ユーザ・プロセッサ６０２上で実行されるプログラミング・スクリプトによって、ストリーミング・リクエスト・リンクおよびエンド・ユーザＩＤがウェブ・サーバ６０６に送信される。（ステップ８０４）。当業者は、エンド・ユーザ・スクリプトは、例えばＣ＋＋、Ｐｅｒｌ、ビジュアルベーシック、Ｊａｖａ（登録商標）等の実質的に任意のプログラム言語によって記述され得る事を認識するであろう。本実施形態において、スクリプトはＪａｖａスクリプトであり、エンド・ユーザのウェブ・ブラウザと共働して実行される。
【００５９】
一旦ウェブ・サーバ６０６がスクリプトからストリーミング・リクエストを受け取れば、ウェブ・サーバ６０６は、許可ソフトウェア・プラグインの指示の下にチケットを生成する。この点において、ウェブ・サーバ６０６は、認証チケットを生成する際に使用されるプライベート・キーをデータベース６０８へ要求するリクエストを発行する（本実施形態において、セキュリティ・キーとセキュリティ・インターバルはリクエストされた再生リストと関連付けられている）。（ステップ８０６）。これを受けて、データベース６０８はウェブ・サーバ６０６にプライベート・キーを返す。（ステップ８０８）。
【００６０】
データベース６０８からプライベート・キーを取得した後、ウェブ・サーバ６０６は、図４に関して上に記述されるようなストリーミングされたものの代わりに再生リストＩＤを使用することによってチケットを生成する（本実施形態において、再生リストＩＤに代替される）。（ステップ８１０）。前述されたように、ウェブ・サーバ６０６は、チケットを生成するためにハッシュ・アルゴリズムにプライベート・キー、ストリーミングＩＤ、エンド・ユーザＩＤおよび時刻を適用する。その後、ウェブ・サーバ６０６は、エンド・ユーザ・プロセッサ６０２上で実行されるウェブ・ブラウザにチケットおよびエンド・ユーザＩＤを返す。（ステップ８１２）。
【００６１】
チケットを受信した後、エンド・ユーザ・プロセッサ６０２上で実行されるスクリプトは、ストリーミング・リクエスト・リンクの末端に情報をアペンドする。（ステップ８１４）。典型的なリンクが以下に示される。＜Ａ ｈｒｅｆ ”ｈｔｔｐ：／／ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｍａｋｅｐｌａｙｌｉｓｔ？ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｕｖｗ１２３ｘｙｚ ｒｅｔｕｎ＆ｕｓｅｒ＿ｉｄ＝ａｂｃ１２３ｄｅｆ”＞。ここで、再生リストＩＤは「７８９０００」で表され、チケットは「ｕｖｗ１２３ｘｙｚ」で表され、エンド・ユーザＩＤは「ａｂｃ１２３ｄｅｆ」で表される。
【００６２】
エンド・ユーザ・プロセッサ６０２上で実行されるスクリプトは、ホスト名「ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」によってストリーミング・リクエスト・リンク中に識別される再生リスト・サーバ６１０を呼び出させる。（ステップ８１６）。従って、再生リスト・サーバ６１０は、リンク、再生リストＩＤ、チケットおよびユーザＩＤを供給される。「ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ」オブジェクトの管理の下で、再生リスト・サーバ６１０は、ＡＳＸファイルのような、コンテンツがウインドウズ・メディア・フォーマットであるリダイレクター・ファイルを生成する。（ステップ８１８）。「ｍａｋｅｐｌａｙｌｉｓｔ」プログラムは、例えばＡＳＰを含む多くのプログラムあるいは技術のうちの任意のものを使用して実施されうる。リダイレクター・ファイルは、チケットおよび公開暗号キー（つまり、ストリーミングＩＤおよびエンド・ユーザＩＤ）に加えて、リクエストされたコンテンツへのリンクを含んでいる。リダイレクター・ファイルを生成するために、再生リストと、ストリーミングＩＤに関連付けられたホスト名・ＵＲＬ接頭部・ファイル名を含むコンテンツ・ファイルへのリンクに際して必要な情報とを含むコンテンツ・ファイルのストリーミングＩＤを検索するために、再生リスト・サーバ６１０はデータベース６０８にアクセスする。
【００６３】
他の実施形態において、エンド・ユーザ・スクリプトはストリーミング・リクエストにチケットをアペンドするために利用されない。その代わり、エンド・ユーザが自身のエンド・ユーザＩＤを提供し、ストリーミング・リクエスト・リンクを起動する場合（ステップ８０４）、ウェブ・サーバ６０６上で実行される認証アプリケーションがチケットを生成し、ストリーミング・リクエスト・リンクにチケットおよびエンド・ユーザＩＤをアペンドし、リダイレクター・ファイルを作成するために再生リスト・サーバ６１０を直接呼び出す。さらにウェブ・サーバ６０６がエンド・ユーザ・プロセッサ６０２上のメディア・プレーヤーを識別する情報を再生リスト・サーバ６１０情報に転送するので、再生リスト・サーバ６１０は、メディア・プレーヤーへリダイレクター・ファイルを転送する（ステップ８１２，８１４および８１６が省略される）。このような実施形態は、図１０に関して後述される。
【００６４】
その後、再生リスト・サーバ６１０はエンド・ユーザ・プロセッサ６０２のメディア・プレーヤーへＡＳＸリダイレクター・ファイルを転送する。（ステップ８２０）。本実施例のために、ＡＳＸファイルは以下のとおりに記述される。
【表２】

ここでＵＲＬ接頭部は、「ｍｍｓ：／／」で表され、適切なメディア・サーバ６０４のホスト名が「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」で表され、ファイル名は「ｓｔｒｅａｍ１．ａｓｆ」で表され、リクエストされたコンテンツ・ストリーミングＩＤは「１２３４５６」で表わされ、チケットは「ｕｖｗ１２３ｘｙｚ」で表され、エンド・ユーザＩＤは「ａｂｃｌ２３ｄｅｆ」で表される。
【００６５】
リダイレクター・ファイルは、コンテンツ・ファイル用メタデータや、広告のような保護されていないファイルのような他の情報を含んでいて良い。
【００６６】
ＡＳＸファイルを受信した後、エンド・ユーザ・プロセッサ６０２はストリーミング・メディア・コンテンツをリクエストするステップへと進む。より詳細には、メディア・プレーヤーは、ＡＳＸファイル中に識別される「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」（つまり、ストリーミング・メディア・サーバ６０４）を呼び出す。（ステップ８２２）。呼び出された後、メディア・プレーヤーは、リクエストされた番組のストリーミングＩＤのコピー、ウェブ・サーバ６０６によって生成されたチケット、およびエンド・ユーザＩＤをストリーミング・メディア・サーバに６０４を供給する。
【００６７】
メディア・プレーヤーの呼び出しに応答して、ストリーミング・メディア・サーバ６０４は、エンド・ユーザがアクセスをリクエストしているコンテンツへのアクセスを認めるかどうかを判断するステップへと進む。（ステップ８２４）。ストリーミング・メディア・サーバ６０４は、個々に１以上の認証チケットを生成し、そのチケットをウェブ・サーバ６０６によって生成されたチケットと比較することにより、アクセスを許可するかどうかを判断する。認証チケットを生成するおよび比較するプロセスは、ストリーミングＩＤの代わりに再生リストＩＤを使用する点を除いて、図５に関して記述されるのと同じ方法で達成される。メディア・サーバ６０４によって生成されたチケットがウェブ・サーバ６０６によって生成されたチケットと一致する場合、メディア・サーバ６０４はエンド・ユーザがアクセスをリクエストしているコンテンツへのアクセスを許可する。（ステップ８２４）。
【００６８】
先の実施形態が、保護コンテンツへの無許可のアクセスに対して十分なレベルの保護を保護コンテンツの所有者に対して提供する事が理解される一方、更に高レベルの保護が与えられても良い。このような更に高レベルの保護は、特定のエンド・ユーザが所定の時間内においてアクセスし得るコンテンツ・ファイルの数を制限することを含む。他のレベルの保護は、保護コンテンツにアクセスするために特定のエンド・ユーザが使用するプロセッサ（例えば、コンピュータ）の数を制限する。先述した任意の実施形態はこのような高レベルの保護を含むように修正され得、追加の保護が実施されたものが図９および１０に関して記述される。
【００６９】
図９の略図から明らかなように、本実施形態は、図６〜図８に関して図示・記述された実施形態に基づく。上述されたように、コンテンツ配信および認証システムはウェブ・サーバ６０６、データベース６０８および再生リスト・サーバ６１０を一般的に含んでいる。更に、必ずしも必要と言うわけではないが、システムは複数のストリーミング・メディア・サーバ６０４−１，６０４−２，６０４−ｎ（総称して６０４と称する）を含んでおり、そのそれぞれがサーバＩＤによって識別され、保護コンテンツを格納している。ストリーミング・メディア・サーバ６０４のそれぞれは、同一のストリーミング・コンテンツのコピーを備え、システムは、ラウンドロビンまたは他の負荷平衡スキームの使用によって、ストリーミング・メディア・サーバ上の負荷のバランスを取ることが好ましい。データベース６０８は、各コンテンツ・ファイルを、格納されるサーバＩＤと関連付ける。以下の記載に基づいて認識されるように、本実施形態は、異なるメディア・サーバ上の同一のコンテンツ・ファイルにアクセスすることを許可された他のエンド・ユーザからアクセス情報を得ることによって無許可のエンド・ユーザが特定のメディア・サーバ上のコンテンツ・ファイルにアクセスする事を防止するので、以下の記述に基づいて認識されるように、本実施形態は、特に複数のストリーミング・メディア・サーバを備えた使用に際して適している。図９に示されるように、先述の構成要素はセキュリティ保護下にあるネットワークによって相互に通信する事が望ましいが、しかしながら、他の実施形態では、グローバル・キャッシュ・サーバ９０２は、ストリーミング・メディア・サーバ６０４にのみに直接接続され、また、ビジネス・サーバ９０４はグローバル・キャッシュ・サーバ９０２にのみ直接接続される。先述した実施形態でのように、エンド・ユーザは、インターネットあるいは他のネットワークに接続されたエンド・ユーザ・プロセッサ６０２−１，６０２−２，６０２−ｍ（総称して６０２と称する）によって保護コンテンツにアクセスする。
【００７０】
一般的に、グローバル・キャッシュ・サーバ９０２は、ストリーミング・メディア・サーバ６０４への各エンド・ユーザの接続に関する接続情報をキャッシュし、エンド・ユーザＩＤに基づいて、更に高レベルの認証保護を提供する。接続情報は、キャッシュまたはデータベースのようなローカルのデータ記憶装置、またはデータベース６０８のような遠隔の記憶装置に格納される。以下詳細に記述されるように、各ストリーミング・メディア・サーバ６０４は、該ストリーミングメディアサーバ６０４を認証した各エンド・ユーザのアクセスに対して、接続情報をグローバル・キャッシュ・サーバ９０２へ転送する。本実施形態において、接続情報は、エンド・ユーザＩＤ、エンド・ユーザのメディア・プレーヤーのグローバル一意識別子（ＧＵＩＤ）、エンド・ユーザがアクセスを許可されたストリーミング・コンテンツのフォーマット（例えば、ウインドウズ・メディアもしくはリアルプレーヤー・フォーマット）、エンド・ユーザによってアクセスされているコンテンツが存在するサーバのＩＤ、および、エンド・ユーザがリクエストを発信し、コンテンツにアクセスする際に用いる特定のエンド・ユーザ・プロセッサ６０２の識別子（ｐｐｖスロットと証する）を含む。既に公知であるように、メディア・プレーヤーの供給業者は、メディア・プレーヤーを識別するために通常は各メディア・プレーヤーにＧＵＩＤを割り当てる。
【００７１】
各エンド・ユーザは、多数のエンド・ユーザ・プロセッサ６０２をエンド・ユーザがコンテンツにアクセスするために割り当てられる。本実施例において、各エンド・ユーザが、３つまでの異なるエンド・ユーザ・プロセッサ６０２からコンテンツにアクセスしてもよい。３つの異なるプロセッサは例えば、エンド・ユーザの家庭用コンピュータ、業務用、またいずれかのモバイル・コンピュータ、ウェブ対応の携帯電話あるいはウェブ対応のＰＤＡ（ＰＤＡ）であって良い。更に、３つのプロセッサ６０２のそれぞれにおいて、エンド・ユーザは複数のメディア・プレーヤーを有しても良く、それぞれのメディア・フォーマットがシステムによってサポートされている。本実施形態において、ウインドウズ・メディアおよびリアルプレーヤー・フォーマットがサポートされる。従って、本実施形態において、各エンド・ユーザは３つまでの異なるｐｐｖスロット値のみを有し得、また、各ｐｐｖスロット値に対して、各メディア・プレーヤーのフォーマット用の２つのＧＵＩＤを有し得る。
【００７２】
本実施形態において、特定のエンド・ユーザ・プロセッサ６０２に対応するｐｐｖスロット値は、そのプロセッサ６０２用のクッキーＩＤである。一般に、クッキーは１セットのデータであり、エンド・ユーザが特定のエンド・ユーザ・プロセッサ６０２によってシステム・ウェブサイトを初めて訪れる時に、ウェブ・サーバ６０６がエンド・ユーザのブラウザに付与するものである。ウェブ・サーバ６０６はクッキーに含まれるエンド・ユーザに関する情報を保存し、エンド・ユーザのブラウザがクッキーを保存する（通常はエンド・ユーザ・プロセッサ６０２のブラウザのシステムフォルダに格納されるテキストファイルとして保存される）。ユーザのプロセッサ６０２（例えばウェブ・ブラウザ）がクッキーを受理しない場合、アプリケーションは、ユーザに対してオプションを変更するように要求するレスポンスを生成する。
【００７３】
本実施形態において、ｐｐｖスロット情報は、データベース６０８中のトランザクション・テーブルに格納される。一般的に、トランザクション・テーブルは、特定のストリーミング・メディアのイベントおよび該イベントに対する３つのｐｐｖスロットにエンド・ユーザを関連付ける。この目的のために、トランザクション・テーブルは、エンド・ユーザＩＤ、所定のメディアのイベントをユニークに識別するイベントＩＤ、ストリーミングＩＤ、エンド・ユーザのイベントに対するアクセスの日付、第１のｐｐｖスロット値、第１のｐｐｖスロットのＧＵＩＤ、第２のｐｐｖスロット値、第２のｐｐｖスロットのＧＵＩＤ、第３のｐｐｖスロット値、および第３のｐｐｖスロット値のＧＵＩＤのフィールドを含む。本記述に基づいて、エンド・ユーザおよびｐｐｖスロット情報と、特定のイベントとを関連付ける事によって、１つのイベントに対して、各エンド・ユーザに対するエンド・ユーザ・プロセッサ６０２の数を３つ以内に制限することが可能となり、一方、トランザクション・データベースが単にエンド・ユーザとｐｐｖスロット情報（イベントごとの情報ではなく、全てのイベントに渡る情報）とを関連付けるような他の実施形態においては、各エンド・ユーザに対するエンド・ユーザ・プロセッサ６０２の数を全てのイベントにわたって３つ以内に制限することが可能となる、と言う事が理解されよう。
【００７４】
以下詳細に記述されるように、ビジネス・サーバ９０４はグローバル・キャッシュ・サーバ９０２からｐｐｖスロット値を含む接続情報の一部または全部を受信する。グローバル・キャッシュ・サーバ９０２と同様、ビジネス・サーバ９０４はローカルまたはリモートのデータ格納装置を備え、個々の接続情報ごとに、別々のレコードをデータベース中に格納する。接続情報に基づいて、ビジネス・サーバ９０４上に存在する認証アプリケーションはエンド・ユーザがアクセスするエンド・ユーザ・プロセッサ６０２の数を３つ以下に制限し、各エンド・ユーザ・プロセッサ６０２に対して、メディア・プレーヤーの数を１つに制限する。許可されるエンド・ユーザ・プロセッサ６０２の数（したがってｐｐｖスロット値の数）は、ビジネス・サーバ９０４の認証アプリケーションにおいて調整可能である。
【００７５】
本実施形態に関して記述されている更に高レベルの保護は、先の実施形態の認証システムおよび方法と共に利用されうる一方、本実施形態に関して記述される１つ以上の任意の更に高レベルの保護は、先述した認証メカニズムとして実施されても良いし、先述した以外の認証メカニズムと共に実施されても良い、と言う事が理解されよう。従って、例示として、さらに高レベルの保護レベルは、図１０の作業のワークフロー図関してここに記述される。
【００７６】
先ず、ウェブ・サーバ６０６は、サービスの登録手続と認証アプリケーションにログインすることをエンド・ユーザに要求するウェブ・ページをエンド・ユーザに供給する。更に、ウェブ・ページは、それぞれが別個のストリーミング・リクエスト・リンクを有する多くのストリーミング・メディア・ファイルのうちの１つを視聴する選択肢をエンド・ユーザに提示する。（ステップ１００２）。これを受けて、エンド・ユーザはエンド・ユーザのユーザＩＤを提供し、所望のストリーミングをウェブ・ページ上で起動し、これによって、特定のストリーミング・メディア・コンテンツ・ファイルに対するアクセスをリクエストする。エンド・ユーザは、さらにクレジットカード番号のような支払い情報あるいは他のアカウント情報を提供してもよい。先の実施形態と同様に、エンド・ユーザＩＤの提供およびストリーミング・リクエスト・リンクの起動は、単一のステップとして、あるいは個々の複数のステップとして発生し得る。エンド・ユーザがログインする場合、ウェブ・サーバ６０６上で実行されるＪａｖａスクリプトあるいは他のソフトウェア・スクリプトまたはコンポーネントのような認証アプリケーションは、過去にシステムにログインした事のあるエンド・ユーザを示すｐｐｖスロットクッキー存在するかどうか、エンド・ユーザ・プロセッサ６０２をチェックする。クッキーが存在しない場合、ウェブ・サーバ６０６は特定のエンド・ユーザ・プロセッサ６０２にクッキーを帰し、エンド・ユーザ・プロセッサ６０２上にそれを格納し、それによって、プロセッサ６０２を識別する。ストリーミング・リクエスト・リンクを起動することによって、ストリーミング・リクエスト・リンクおよびエンド・ユーザＩＤがウェブ・サーバ６０６に伝達される。（ステップ１００４）。
【００７７】
エンド・ユーザがシステムにログインし、コンテンツへのアクセスをリクエストする場合、ウェブ・サーバ６０６の認証アプリケーションは、エンド・ユーザが３つの割り当てられたｐｐｖスロット数を超過しているかどうかを判断し、超過していない場合、トランザクション・テーブルを更新する。（ステップ１０１０Ａ）。この点において、ウェブ・サーバ６０６は、エンド・ユーザがシステムにログインした際の、特定のエンド・ユーザに対するトランザクション・テーブル中の全てのｐｐｖスロット値に割り当てられたクッキーＩＤ（エンド・ユーザＩＤによって認識される）と、イベント（イベントＩＤによって認識される）とを比較する。トランザクション・テーブルが既に３つのｐｐｖスロット値を含んでおり、受信されるクッキーＩＤが、既存の３つのｐｐｖスロット値のうちのどれとも一致しない場合、エンド・ユーザが無許可のアクセスを４番目のプロセッサ６０２から試みていると見做され、本アクセスは拒否される。
【００７８】
トランザクション・テーブルが、イベントに対するエンド・ユーザのｐｐｖスロット値が３未満の場合、ウェブ・サーバ６０６はトランザクション・テーブル中にレコードを作成する。より具体的には、ウェブ・サーバ６０６はエンド・ユーザＩＤ、イベントＩＤ（以前にエンド・ユーザによって購入されたコンテンツに割り当てられたもの）、購入されたコンテンツのストリーミングＩＤ（ストリーミング・リクエスト・リンクの再生リストＩＤに対応するものとして、ウェブ・サーバ６０６がデータベース６０８から検索したもの）、日付およびｐｐｖスロット値を使用して、レコードを作成する。
【００７９】
ｐｐｖスロット情報に基づいてエンド・ユーザのアクセスが拒否されなければ、ストリーミング・リクエスト・リンクおよびエンド・ユーザＩＤを受信した後、ウェブ・サーバ６０６上で実行される認証アプリケーションはデータベース６０８にアクセスし（ステップ１００６）、データベース６０８からプライベート・キー情報を得て（ステップ１００８）、チケットを生成し、ストリーミング・リクエスト・リンクにチケット、エンド・ユーザＩＤおよびｐｐｖスロット値をアペンドする（ステップ１０１０ｂ）。その後、ウェブ・サーバ６０６上で実行される認証アプリケーションは、アペンドされたチケット、エンド・ユーザＩＤおよびｐｐｖスロット値を含むストリーミング・リクエスト・リンクを再生リスト・サーバ６１０へ転送する。（ステップ１０１２）。
【００８０】
再生リスト・サーバ６１０がストリーミング・リクエスト・リンク、チケット、エンド・ユーザＩＤおよびｐｐｖスロット値を一旦受信すると、再生リスト・サーバ６１０はリダイレクター・ファイルを生成するステップへと進む。上述されたように、リダイレクター・ファイルを生成するために、再生リスト・サーバ６１０はデータベース６０８にアクセスし（ステップ１０１４）、再生リストを含むコンテンツ・ファイルのストリーミングＩＤおよび該ストリーミングＩＤに関連するホスト名、ＵＲＬ接頭部およびファイル名を検索する（ステップ１０１６）。この情報をもとに、再生リスト・サーバ６１０はリダイレクター・ファイルを作成する。（ステップ１０１８）。その後、再生リスト・サーバ６１０は、ＧＵＩＤによって識別されるエンド・ユーザ・プロセッサ６０２の特定のメディア・プレーヤーへリダイレクター・ファイルを転送する。（ステップ１０２０）。本実施形態における典型的なリダイレクター・ファイル、ＵＲＬ接頭部を以下に示す。
【表３】

ここで、ＵＲＬ接頭部は「ｍｍｓ：／／」で表され、適切なメディア・サーバ６０４のホスト名は「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」で表され、ファイル名は「ｓｔｒｅａｍｌ１．ａｓｆ」で表され、リクエストされたコンテンツ・ストリーミングＩＤは「１２３４５６」で表され、チケットは「ｕｖｗ１２３ｘｙｚ」で表され、エンド・ユーザＩＤ「ａｂｃｌ２３ｄｅｆ」で表され、ｐｐｖスロット値は「１」で表される。
【００８１】
リダイレクター・ファイルを受信した後、エンド・ユーザ・プロセッサ６０２上のメディア・プレーヤーは適切なストリーミング・メディア・サーバ６０４にストリーミング・メディア・コンテンツをリクエストするステップへと進む。（ステップ１０２２）。より具体的には、メディア・プレーヤーは、リダイレクター・ファイル中に識別される特定のストリーミング・メディア・サーバ６０４を呼び出す。呼出がなされた場合、メディア・プレーヤーは、リクエストされたコンテンツのストリーミングＩＤのコピー、ウェブ・サーバ６０６によって生成されたチケット（ステップ１０１０）、エンド・ユーザＩＤおよびｐｐｖスロット値をストリーミング・メディア・サーバに６０４を供給する。更に、メディア・プレーヤーは、自身のＧＵＩＤをストリーミング・メディア・サーバへ転送する。
【００８２】
エンド・ユーザ・プロセス６０２からオリジナルのストリーミング・リクエストおよびログイン情報を受け取る場合、ストリーミング・メディア・サーバ６０４上で実行されるアプリケーションはメディア・プレーヤーがＧＵＩＤを転送したかどうか（あるいは無効のデフォルト値を転送したか）を判断する。もし転送していなかった場合、アプリケーションは認証プロセスを停止することによりエンド・ユーザのアクセスを拒否し、エンド・ユーザに通知する。エンド・ユーザのメディア・プレーヤーがＧＵＩＤを提供しなかったという事実はデータベース６０８、あるいは他のデータ記憶装置に記録され、今度そのエンド・ユーザがシステムにログインする時に、エンド・ユーザにＧＵＩＤを送信可能にするべき方法についての指示をシステムが提供する事が好ましい。
【００８３】
図６〜図８の実施形態において、ストリーミング・メディア・サーバ６０４がメディア・プレーヤーからの呼び出しを一旦受けると、ストリーミング・メディア・サーバ６０４は個別に１以上の認証チケットを生成し、１つ以上のチケットをメディア・プレーヤーから受信してチケットと比較する。（ステップ１０２４）。これらのチケットが一致した場合、ストリーミング・メディア・サーバ６０４はコンテンツへのアクセスの許可を与えて、エンド・ユーザへコンテンツを配信する。（ステップ１０２６）。
【００８４】
ストリーミング・サーバ６０４がエンド・ユーザにコンテンツに対するアクセスを許可する毎に、ストリーミング・メディア・サーバ６０４は、該接続を識別する情報をグローバル・キャッシュ・サーバ９０２に送信する。（ステップ１０２８）。上述したように、このような接続情報は、エンド・ユーザＩＤ、ストリーミング・コンテンツのフォーマット（例えばウインドウズ・メディアあるいはリアルプレーヤー）、エンド・ユーザにコンテンツを供給するストリーミング・メディア・サーバ６０４のサーバＩＤ、エンド・ユーザのメディア・プレーヤーのＧＵＩＤ、および、エンド・ユーザがシステムにログインするのに用いる特定のエンド・ユーザ・プロセッサ６０２を表わすｐｐｖスロット値を含む事が好ましい。
【００８５】
ストリーミング・サーバ６０４がエンド・ユーザにコンテンツに対するアクセスを許可する毎に、ストリーミング・メディア・サーバ６０４はさらにローカルにストリーミング名またはストリーミングＩＤ、エンド・ユーザＩＤ、およびリクエストに関する接続情報をキャッシュする。ストリーミング接続が終了する場合は常に、ストリーミング・メディア・サーバ６０４は、キャッシュ中の対応するエントリーを削除する。そのため、キャッシュ中の全てのエントリーはその時点におけるストリーミングあるいはアクセスを表わす。ソフトウエア・コンポーネントやオブジェクトのような、ストリーミング・メディア・サーバ６０４上で実行されるポーリングサービスを利用して、メディア・サーバ６０４は、周期的に（例えば２分毎に）エントリー毎にキャッシュをポーリングする。エントリー毎に、ストリーミング・メディア・サーバ６０４が、グローバル・キャッシュ・サーバ９０２へ接続情報を再送する。
【００８６】
上述されるように、グローバル・キャッシュ・サーバ９０２はデータベースまたはキャッシュを備え、各レコード上に受信した接続情報を含んでいる。グローバル・キャッシュ・サーバ９０２が特定のユーザに関する接続情報を得る場合、サーバ９０２は通常はそのデータベース中で新しいレコードを作成する。しかしながら、新しいレコードを作成するに先立って、グローバル・キャッシュ・サーバ９０２は、新たに受信した接続情報と同一のエンド・ユーザＩＤをそのデータベースが有するかどうかを先ず判断する。（ステップ１０３０）。
【００８７】
さらに、アクセスが終了する場合、グローバル・キャッシュ・サーバ９０２は、該アクセスのレコードを削除する。上述されるように、各ストリーミング・メディア・サーバ６０４は、接続情報によって識別されるアクセスの期間中に、所定の間隔でグローバル・キャッシュ・サーバ９０２に接続情報の各セットを再送する。グローバル・キャッシュ・サーバ９０２は、接続情報が再送されなかったレコードを周期的に削除し、その時点においてアクセスが存在するレコードのみが保持されるようにする。他の実施形態においては、グローバル・キャッシュ・サーバは、これとは異なった方法で、もはや使用されていない接続に関するレコードを削除しても良い。例えば、他の実施形態において、グローバル・キャッシュ・サーバ９０２が特定の接続が終了したことを示す終了メッセージをストリーミング・メディア・サーバから受信するまで、グローバル・キャッシュ・サーバ９０２が特定の接続に関するレコードを保持する。つまり、グローバル・キャッシュ・サーバのデータベース中のレコードが存在すると言うことは、エンド・ユーザＩＤによって識別される特定のエンド・ユーザがコンテンツ・ファイルにその時点においてアクセスしている、と言うことを示す。
【００８８】
グローバル・キャッシュ・サーバ９０２が、受信したエンド・ユーザＩＤと同一のエンド・ユーザＩＤを伴うレコードを既に有する場合、エンド・ユーザ（あるいはアクセス情報を取得した無許可のユーザ）は、複数のコンテンツ・ファイルに同時にアクセスすること、または同一コンテンツ・ファイルに２回以上アクセスする事を試みている。本実施形態において、このようなマルチプルアクセスは許可されない。従って、グローバル・キャッシュ・サーバ９０２は、新たに受信された接続情報の送信元であるメディア・サーバと、既存のデータベースレコード中のサーバＩＤによって識別されるメディア・サーバの双方に、エンド・ユーザのアクセスを終了させる要求を発行する。ストリーミング・メディア・サーバ６０４にエンド・ユーザからの接続を切断させる際、特定のエンド・ユーザに関するレコードをデータベースより削除する。
【００８９】
ここに述べた更に高レベルの許可保護は任意のものであり、また、異なる方式で実施されても良い、と言う事が理解されよう。例えば、他の実施形態におけるサーバは、ユーザがマルチプルアクセスを試みているかどうかを判断するために、グローバル・キャッシュ・サーバ９０２を照会しても良い。そのような実施形態において、再生リスト・サーバ６１０がリクエスト・リンク、チケットおよびエンド・ユーザＩＤをウェブ・サーバ６０６から受信した後、再生リスト・サーバ６１０は、グローバル・キャッシュ・サーバ９０２が既にコンテンツにアクセスしたエンド・ユーザのレコードを有するかどうかを判断するために、グローバル・キャッシュ・サーバ９０２を呼び出す。（ステップ１０１８ａ）。グローバル・キャッシュ・サーバ９０２は、エンド・ユーザがその時点においてコンテンツにアクセスしているかどうかに関する表示を用いて再生リスト・サーバ６１０に回答する。ステップ（１０１８ｂ）。これを受けて、再生リスト・サーバ６１０上で実行される認証アプリケーションは偽または無効リダイレクター・ファイルを生成する。このような実施形態において、リダイレクター・ファイルは、チケットの不足あるいはストリーミング・メディア・サーバ６０４によって検知されるデフォルト・チケットが含まれているので、無効である。
【００９０】
グローバル・キャッシュ・サーバ９０２が、受信された新たな接続情報に含まれるエンド・ユーザＩＤと同一のエンド・ユーザＩＤを有するデータベース中にレコードの存在を認めなかった場合、グローバル・キャッシュ・サーバ９０２は、受信した接続情報を用いてデータベース中に新たなレコードを作成し、エンド・ユーザがコンテンツにアクセスする事を妨げない。
【００９１】
グローバル・キャッシュ・サーバ９０２がエンド・ユーザの接続を切断しない場合、サーバ９０２はビジネス・サーバ９０４へ接続情報の一部または全部を中継する。ビジネス・サーバ９０４は、任意の２個の更に高レベルの許可保護を有効にする。（ステップ１０３４）。本実施形態において、グローバル・キャッシュ・サーバ９０２は、エンド・ユーザＩＤ、ｐｐｖスロット、ＧＵＩＤおよびストリーミング・フォーマットをビジネス・サーバ９０４へ中継する。
【００９２】
ビジネス・サーバ９０４は、メディア・プレーヤーのＧＵＩＤに一部基づいてコンテンツに対するアクセスを管理するために、グローバル・キャッシュ・サーバ９０２から受信した該接続情報を使用する。（ステップ１０３６）。上述されたように、各エンド・ユーザは、３つの異なるユーザ・プロセッサ６０２からシステムにログインし、コンテンツにアクセスする事が許可される。ユーザ・プロセッサ６０２のそれぞれは各フォーマットに対して１つのみのメディア・プレーヤーを有する。従って、ｐｐｖスロットによって識別される特定のエンド・ユーザ・プロセッサ６０２から、特定のメディア・フォーマット用のＧＵＩＤによって識別される特定のメディア・プレーヤーを用いてエンド・ユーザがアクセスをリクエストし、該メディアプレーヤーが、同一のフォーマットのメディアに対して同一のエンド・ユーザ・プロセッサ６０２上で以前用いられていたメディア・プレーヤーと異なる場合、ビジネス・サーバ９０４はエンド・ユーザの接続を切断させる。一般的に、この決定は、トランザクション・テーブルにアクセスし、新たに受信される接続情報をエンド・ユーザおよびｐｐｖスロット値に対する既存のエントリーと比較することによりなされる。
【００９３】
ビジネス・サーバ６０４が所定のエンド・ユーザおよびｐｐｖスロットに対する接続情報を得る場合、ビジネス・サーバ９０４は、該エンド・ユーザ、ｐｐｖスロットおよびフォーマットに関して既にＧＵＩＤが受信されたかどうかを判断するためにトランザクション・テーブルにアクセスする。もし受信されていなければ、トランザクション・テーブルは、ＧＵＩＤを反映するためにビジネス・サーバ９０４によって更新される。また、ビジネス・サーバ９０４は、エンド・ユーザのアクセスを終了させない。
【００９４】
受信した接続情報が、ＧＵＩＤが既に受信されているトランザクション・テーブル中のレコードに対応する場合、ビジネス・サーバ９０４は、受信されたＧＵＩＤが、ｐｐｖスロットに関して格納された特定のメディア・フォーマット用のＧＵＩＤと一致するかどうかを判断する。ＧＵＩＤが一致しない場合、ビジネス・サーバ９０４は、エンド・ユーザの保護コンテンツに対するアクセスを終了させる旨グローバル・キャッシュ・サーバ９０２に指示を送信し、エンド・ユーザのアクセスが拒否される。このような指示は、エンド・ユーザＩＤを指定する事が好ましい。（ステップ１０３８）。次に、グローバル・キャッシュ・サーバ９０２は、エンド・ユーザにコンテンツをその時点において供給している１つ以上のストリーミング・メディア・サーバ６０４へのリクエストを発行する。
【００９５】
そのため、たとえエンド・ユーザがコンテンツへのアクセスを一時的に許可されたとしても、本実施形態は無許可のエンド・ユーザに対してアクセスを拒否する、と考えられるべきである。グローバル・キャッシュ・サーバ９０２およびおよびビジネス・サーバ９０４における処理に起因してアクセスの提供に遅延が生じることを防ぐ事が望ましいので、本実施形態においてはこのような一時的アクセスが許可される。グローバル・キャッシュ・サーバ９０２およびビジネス・サーバ９０４の処理に起因してアクセスが遅延するような例において、エンド・ユーザのメディア・プレーヤーは時間切れとなり得、アクセスが許可されるのを妨げられる。従って、本実施形態のメディア・サーバ６０４は、チケットの一致によってアクセスを許可し、メディア・プレーヤーが時間切れになる事を防止し、それから、グローバル・キャッシュ・サーバ９０２あるいはビジネス・サーバ９０４によってアクセスが不適当であると判断された場合にこのようなアクセスが終了する。
【００９６】
ビジネス・サーバ９０４が、新たに受信したメディア・プレーヤーのＧＵＩＤとｐｐｖスロットおよびフォーマットに関してメモリに格納したＧＵＩＤとが一致すると判断した場合、ビジネス・サーバ９０４は何も行わず、エンド・ユーザのアクセスが継続することを許可する。
【００９７】
単一のグローバル・キャッシュ・サーバ９０２がシステム中の全てのストリーミング・メディア・サーバ９０４から接続情報を取得する事が望ましい一方、複数のグローバル・キャッシュ・サーバを含み得、そのそれぞれがメディア・サーバの部分集合から接続情報を取得する事が可能である、と言う事が理解されるべきである。しかしながら、そのような実施形態においては、複数のグローバル・キャッシュ・サーバは相互に通信可能な状態にある。
【００９８】
更に、グローバル・キャッシュ・サーバ９０２およびビジネス・サーバ９０４の機能性は、一実施形態中においては１つのサーバへ組み合わせられていても良い一方で、２つの別個のサーバを使用する事によって、スケーラビリティを有する等の幾つかの利点がある。例えば、認証システムが複数のコンテンツ所有者のアカウントに対して利用される場合、各アカウントは個別の許可ルールをそれぞれ適用し得、それぞれのルールは、グローバル・キャッシュ・サーバへのアクセスを有する個別のビジネス・サーバ上に存在する。このような実施形態において、既存の接続情報に基づいて、またはアカウントＩＤのような接続情報に含まれる付加的なフィールドに基づいて、適切なビジネス・サーバへ接続情報を送信する事が出来る。
【００９９】
本実施形態において、システムは、各エンド・ユーザにエンド・ユーザのｐｐｖスロット情報（ｐｐｖスロット値およびＧＵＩＤを含む）を再登録および削除する機会を提供し、これによって、エンド・ユーザが、異なる機器および（または）メディア・プレーヤーからコンテンツにアクセスすることを可能にする。
【０１００】
先の実施形態はセキュリティ・キーとセキュリティ・インターバルの両方を含むプライベート・キーを利用するが、プライベート・キーとしてそれ以上、またはそれ以下の情報を利用するのも、本発明の範囲内である事が理解されよう。例えば、他の実施形態においてはセキュリティ・キーが使用されない。また、他の実施形態においては、例えばクライアントのユーザ名およびパスワードを含む補足情報が、プライベート・キーに含まれる。同様に、ストリーミングＩＤおよびエンド・ユーザＩＤ以外の情報を含む公開暗号キーを利用する事も、本発明の範囲内である。例えばファイル・パス名の様な、情報を識別する他のコンテンツ・ファイル識別情報が使用されてもよい。さらに、ある実施形態においては、エンド・ユーザＩＤが公開暗号キー情報から省略されてもよい。更に他の実施形態において、公開暗号キー情報は、他のリクエスト・コンテンツ・ファイルのタイトルあるいはストリーミング詳細のような補足情報を含んでいる。
【０１０１】
ウェブ・サーバおよびストリーミング・メディア・サーバによって提供されると記載された機能性が、それに関連する他のデバイス上において実施され得るということが理解されよう。例えば、本発明の一実施形態において、ストリーミング・メディア・サーバが、それに接続される関連するアプリケーションサーバを備え、アプリケーションサーバは、コンテンツに対するアクセスを拒否または許可するプロセスの全部または一部を実施する。同様に、それは、例えば認証チケットを生成する過程を含むウェブ・サーバの機能性のうちの一部または全部を提供するためにウェブ・サーバとアプリケーションサーバとを関連付ける事は、本発明の範囲内である。そのため、特定のサーバに対する言及は、言及されたサーバと接続される他の関連するサーバあるいはプロセッサを含む、という事を意図している。
【０１０２】
さらに、認証チケットを正確な時間に生成する必要は無い、と言う事が理解されよう。例えば、ウェブ・サーバによって生成されるチケットは、エンド・ユーザがストリーミング・リクエスト・リンクを起動する時間に基づいても良いし、ウェブ・サーバがデータベースからプライベート・キー情報を得る時間に基づいても良いし、ストリーミング・リクエストの起動時間に近接した任意の時間に基づいても良い。同様に、メディア・サーバが許可を生成する時間は、例えば、メディア・プレーヤーからの呼出がなされた時でも良いし、プライベート・キー情報が検索された後でも良いし、ストリーミング・リクエストの起動時間に近接した任意の時間であっても良い。更に、メディア・サーバが複数のチケットを生成する際、チケットは異なる複数の時間に基づいて生成されても良いし、単一の時間に基づいて生成されても良い。従って、時間または現在時刻に対する参照は、ある一定の範囲の参照を意図するものであり、正確な時刻の参照を意図するものではない。
【０１０３】
先の典型的な実施形態は、単一のコンテンツに対するアクセスを管理すると言うコンテキストで記載されたが、先の実施形態が複数の保護コンテンツ・ファイルを含む再生リストへのアクセスを管理するために用いられ得るという事を当業者は理解するであろう。再生リストへのアクセスを管理するための典型的な一実施形態が、図６〜図８の実施形態に関して記述される。このような実施形態は、下記の変更を伴った上で、前述の記載に従って作動する。一般的に、ウェブ・サーバ６０６は、各ストリーミングのストリーミングＩＤに基づいて、再生リストに含まれる各コンテンツ・ストリーミングのチケットを生成する。
【０１０４】
エンド・ユーザ・プロセッサ６０２のメディア・プレーヤーは、再生リストＩＤを含むストリーミング・リクエストを再生リストプロセッサ６１０へ転送する。次に、再生リストプロセッサ６１０はリダイレクター・ファイルを生成し、メディア・プレーヤーにリダイレクター・ファイルを返送する。本実施例において、オブジェクト「ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ」は、適切なリダイレクター・ファイルを構築するために再生リストＩＤ「７８９０００」を使用する。より詳細には、どのコンテンツがリクエストされた再生リストの一部を構成するのかを判断するため、および再生リスト中のコンテンツ・ファイルの順番を判断するために、再生リスト・サーバ６１０は、再生リストテーブル７０８および再生リスト・ストリーミング・テーブル７１０にアクセスする。コンテンツ・ファイルのファイル名はストリーミング・テーブル７０４から検索される。続いて、エンド・ユーザ・プロセッサ６０２上で実行されるスクリプトは、対応するコンテンツ・ストリーミングへリンクするＵＲＬにストリーミングＩＤ、チケットおよびエンド・ユーザＩＤをアペンドする。本実施形態において、ストリーミング・サーバ・テーブル７１２中から識別されるように、全てのコンテンツ・ストリーミングは同一のメディア・サーバ６０４に格納される。
【０１０５】
対応するコンテンツ・ストリーミングのためのＵＲＬリンクにアペンドされたストリーミングＩＤ、チケットおよびエンド・ユーザＩＤを含むＡＳＸリダイレクター・ファイルの例を以下に示す。
【表４】

【０１０６】
その後、メディア・プレーヤーは、ストリーミング・メディア・サーバ６０４を連続して呼び出し、各呼び出しに対する各ＵＲＬリンクがリダイレクター・ファイルに含まれている。より具体的には、メディア・プレーヤーは先ず、第１のコンテンツ・ストリーミング（本例において、ストリーミングＩＤ「１２３４５６」を有する）にアクセスするためにメディア・サーバ６０４を呼び出す。呼び出しに応答して、また、図５に関して概説したように、メディア・サーバ６０４は個々にチケットを生成し、コンテンツへのアクセスを許可するべきかどうかを判断する。アクセスが許可されない場合、エンド・ユーザにその旨が通知される。一方、メディア・サーバがエンド・ユーザに対して第１のコンテンツ・ストリーミングへのアクセスを許可する場合、メディア・プレーヤーは、再生リスト中の残りのコンテンツ・ストリーミング用のメディア・サーバ６０４を呼び出すステップへと進む。それぞれの呼び出しで、メディア・サーバ６０４はリクエストされたコンテンツへのアクセスを許可するか拒否するかのステップへと進む。
【０１０７】
しかしながら、このような実施形態において、各々のコンテンツ・ストリーミングが、再生リスト中のストリーミングに先立って再生されるコンテンツ・ストリーミングの所要時間の合計を計上した長さの個々のセキュリティ・インターバルを有することが望ましい、と言う事が理解されるべきである。例えば、それぞれが５分の所要時間を有する（ストリーミング・テーブル７０４のストリーミング詳細フィールドに示される）３つのコンテンツ・ストリーミングを含む再生リスト中で、第２のストリーミングのセキュリティ・インターバルは、第１のストリーミングのセキュリティ・インターバルよりも５分間だけ長くても良く、第３のストリーミングのセキュリティ・インターバルは、第１のストリーミングのセキュリティ・インターバルよりも１０分間だけ長くても良い。再生リスト中の各ストリーミングの所要時間を計上する事によって、システムは、許可されたエンド・ユーザが、再生リスト中の第１のコンテンツ・ストリーミングへのアクセスを許可されるがチケットが有効期限切れになったという理由によって後続のコンテンツ・ストリーミングに対するアクセスが許可されない、という事を防止する。更に、セキュリティ・インターバルは、再生リストに含まれる広告のような任意の非保護コンテンツの所要時間を計上しても良い。
【０１０８】
更に他の実施形態は、再生リストＩＤに基づいてチケットを生成することにより、複数の保護コンテンツ・ストリーミングを含む再生リストへのアクセスを管理する。このような実施形態は、下記の変更を伴った上で、図６〜図８のシステムの記述に従って作動する。一般的に、一旦エンド・ユーザが認証アプリケーションにログインし、再生リストへのアクセスをリクエストすれば、ウェブ・サーバ６０６は、再生リストＩＤに基づいてチケットを生成し、エンド・ユーザ・プロセッサ６０２にチケットを返送する。これを受けて、エンド・ユーザ・プロセッサ６０２上で実行されるスクリプトは、ストリーミング・リクエスト・リンクにチケットおよびエンド・ユーザＩＤをアペンドする。以下、公開暗号キー情報がアペンドされたストリーミング・リクエスト・リンクの例を示す。＜Ａ ｈｒｅｆ”ｈｔｔｐ：／／ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ？ＰＬＡＹＬＩＳＴ＿ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｘｙｚ３２１ａｂｃ＆ＵＳＥＲ＿ＩＤ＝ａｂｃ１２３ｄｅｆ”＞。ここで、再生リストＩＤは「７８９０００」で表され、チケットは「ｘｙｚ３２１ａｂｃ」で表され、エンド・ユーザＩＤは「ａｂｃ１２３ｄｅｆ」で表される。
【０１０９】
エンド・ユーザ・プロセッサ６０２は、「ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」と言う名称によって識別される再生リスト・サーバ６１０を呼び出す。次に、再生リスト・サーバ６１０は、リダイレクター・ファイルを生成するために再生リスト・サーバ６１０に存在する「ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ」オブジェクトを始動する。本実施形態において、コンテンツ・ストリーミングはすべて同一のメディア・サーバ６０４上に存在する。先の実施形態と異なり、「ｍａｋａｐｌａｙｌｉｓｔ．ｄｌｌ」オブジェクトは、リダイレクター・ファイル中の第１のＵＲＬの端部に、再生リスト中の後続する保護コンテンツ・ストリーミングのファイル名をアペンドし、それぞれの後続のＵＲＬリンクには、再生リストＩＤおよびチケットのみがアペンドされる。ＡＳＸリダイレクター・ファイルの例を以下に示す。
【表５】

【０１１０】
ここで、再生リストは、「ｓｔｒｅａｍ１．ａｓｆ」、 「ｓｔｒｅａｍ２．ａｓｆ」、 「ｓｔｒｅａｍ３．ａｓｆ」、と名前の付けられた３つのウィンドウズ・メディア・フォーマット（ウィンドウズは登録商標）のコンテンツ・ファイルを含み、再生リストＩＤは「７８９０００」で表され、エンド・ユーザＩＤは「ａｂｃ１２３ｄｅｆ」で表され、チケットは「ｘｙｚ３２１ａｂｃ」で表される。
【０１１１】
エンド・ユーザ・プロセッサ６０２のメディア・プレーヤーは、第１のコンテンツ・ファイルにアクセスするために、ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ（即ち、ストリーミング・メディア・サーバ６０４のホスト名）を呼び出すステップへ進む。メディア・サーバ６０４は、図５に関して上述されたように、再生リストＩＤに基づいてチケットを生成し、アクセスを許可または拒否するステップへと進む。メディア・サーバ６０４がアクセスを許可し、メディア・プレーヤーに再生リスト中の第１のコンテンツ・ファイルを提供する場合、メディア・サーバ６０４は、再生リストＩＤおよび対応するチケットのためにローカルに格納されたテーブル中にレコードを作成し、リダイレクター・ファイルに含まれている再生リスト中の後続するコンテンツ・ストリーミングのファイル名をレコード中に格納する。
【０１１２】
メディア・プレーヤーが第２のコンテンツ・ストリーミングへのアクセスを要求する場合、メディア・プレーヤーはメディア・サーバ６０４に再生リストＩＤおよびチケットを供給する。次に、メディア・サーバ６０４は、再生リストＩＤおよびチケットによって識別されたレコードを、テーブル中から検索する。レコードが存在する場合、メディア・サーバ６０４は第２のストリーミングをへのアクセスを許可し、特定のチケットを有するエンド・ユーザによって視聴された旨、ストリーミングにフラグを立てる。無許可のエンド・ユーザが同じＵＲＬリンクを使用して第２のストリーミングにアクセスすることを試みる場合、再生リストＩＤおよびチケットに関するレコードにおいて、上述したように第２のストリーミングが視聴された旨を示すフラグが立っているので、メディア・サーバ６０４はアクセスを拒否する。同様のプロセスが、再生リスト中の残りのコンテンツ・ストリーミングへのアクセスを許可するために利用される。当業者によって認識されるように、本実施形態は、第１のストリーミングへのアクセス許可と、後続のストリーミングとの間の時間遅延に起因して再生リスト中の後続のストリーミングへのアクセスが不適切に拒否されるような如何なる可能性をも回避する。
【０１１３】
当業者は、本発明の方法およびシステムが多数の応用を有し、多数の方法において実施され得、従って、以上記載された典型的な実施形態および実施例によって制限され無いという事を認識するであろう。さらに、当業者によって理解されるように、本発明の範囲は、本願明細書に記載されているシステム構成部分に対する従来公知の、および将来開発される変更および修正を含む。
【図面の簡単な説明】
【０１１４】
【図１】本発明の一実施形態におけるシステムを示す略図である。
【図２】本発明の一実施形態におけるデータベース示す略図である。
【図３】本発明の一実施形態におけるワークフローを示す図である。
【図４】本発明の一実施形態におけるチケットを生成するプロセスを示すフローチャートである。
【図５】本発明の一実施例における、ストリーミング・メディア・コンテンツのアイテムを供給するべきかどうかを判断するプロセスを示すフローチャートである。
【図６】本発明の他の実施形態におけるシステムを示す略図である。
【図７】本発明の他の実施形態におけるデータベースを示す略図である。
【図８】本発明の他の実施形態におけるワークフローを示す略図である。
【図９】本発明の他の実施形態におけるシステムを示す略図である。
【図１０】本発明の他の実施形態におけるワークフローを示す略図である。
【符号の説明】
【０１１５】
１０２...エンド・ユーザ・プロセッサ
１０４...メディア・サーバ、
１０６...ウェブ・サーバ、
１０８...ＣＭデータベース
２０４...ストリーミング・テーブル
２０８...再生リストテーブル
２１０...再生リスト・ストリーミング・テーブル

Claims (2)

1. １以上のメディア・ファイルへのアクセスを管理する方法であって、
   （ａ）第１メディアファイルへのアクセスを要求する第１リクエストを受信するステップと、
   （ｂ）前記第１リクエストを許可するステップと、
   （ｃ）第１エンドユーザ識別子、第１エンドユーザプロセッサ識別子、および第１メディアプレーヤー識別子を関連付けるステップと、
   （ｄ）第２メディアファイルへのアクセスを要求する第２リクエストを受信するステップと、
   （ｃ）前記第１エンド・ユーザ識別子が第２エンド・ユーザ識別子と一致し、
   前記第１メディア・プレーヤー識別子が第２メディア・プレーヤー識別子と一致し、
   前記第１メディア・プレーヤー識別子が第２メディア・プレーヤー識別子と一致する場合に、
   前記リクエストを許可するステップと、
   （ｄ）前記第１エンド・ユーザ識別子が前記第２エンド・ユーザ識別子と一致し、
   前記第１メディア・プレーヤー識別子が前記第２メディア・プレーヤー識別子と一致し、
   前記第１メディア・プレーヤー識別子が前記第２メディア・プレーヤー識別子と一致しない場合、
   前記リクエストを拒否するステップと
   を備え、
   前記第１リクエストは、
   前記第１リクエストを要求する第１エンドユーザを識別する前記第１エンドユーザ識別子と、
   前記第１エンドユーザによる前記リクエストの要求元である第１エンドユーザプロセッサを識別する前記第１エンドユーザプロセッサ識別子と、
   前記第１エンドユーザによる前記リクエストの要求元である第１メディアプレーヤーを識別する前記第１メディアプレーヤー識別子と
   を備え、
   前記第２リクエストは、
   前記第２リクエストを要求する第２エンドユーザを識別する前記第２エンドユーザ識別子と、
   前記第２エンドユーザによる前記リクエストの要求元である第２エンドユーザプロセッサを識別する前記第１エンドユーザプロセッサ識別子と、
   前記第２エンドユーザによる前記リクエストの要求元である第２メディアプレーヤーを識別する前記第２メディアプレーヤー識別子と
   を備える方法。
2. エンド・ユーザが、１以上のエンド・ユーザ・プロセッサから１以上のメディア・ファイルへのアクセスを試みる事によって、前記１以上のメディア・ファイルへのアクセスを管理する方法であって、
   （ａ）前記１以上のメディア・ファイルへのアクセスが許可されるエンド・ユーザ・プロセッサの許容数を設定するステップと、
   （ｂ）前記１以上のメディア・ファイルのうちの１つにアクセスするために、前記エンド・ユーザからの１以上のリクエストを受信するステップと、
   （ｃ）指示の数が前記エンド・ユーザ・プロセッサの許容数と同じになるまで、リクエストがなされる各エンド・ユーザ・プロセッサの指示を格納するステップと、
   （ｄ）前記１以上のリクエストの要求元である前記エンド・ユーザ・プロセッサが、格納された指示と対応する場合に、前記１以上のリクエストを許可するステップと、
   （ｅ）前記１以上のリクエストの要求元である前記エンド・ユーザ・プロセッサが、格納された指示と対応しない場合に、前記１以上のリクエストを拒否するステップと
   を備え、
   前記１以上のリクエストのそれぞれが、前記１以上のエンド・ユーザ・プロセッサのうちの１つによって要求される、
   方法。

Images