JP4838203B2 - １つ以上のメディア・ファイルへのアクセスを管理する、コンピュータを用いた方法、コンピュータ可読メディア、およびシステム - Google Patents

Description

本出願は、２００１年６月６日に出願された、「ストリーミング・メディアを含むデジタル・コンテンツへのアクセスを管理するシステムおよび方法」という名称の国際出願第ＰＣＴ／ＵＳ０１／１８３２４号の一部継続出願であり、前記国際出願は本願明細書に併合されるものとする。

本発明は、広義にはデジタル・コンテンツへのアクセスを管理する事に関し、より詳細には、時間成分に一部基づくチケットに基づいた、ストリーミング・メディアへのアクセスを制限する、コンピュータを用いた方法、コンピュータ可読メディア、およびシステムに関する。

インターネットとワールド・ワイド・ウェブの普及により、ストリーミング・メディア・コンテンツのようなデジタル・コンテンツの配信に関連する産業が発展した。例えば、ストリーミング・メディアは、エンターテインメント、通信教育および企業目的を含む多数の目的のうちの何れかのために使用され得る。エンターテインメント会社は映画とスポーツイベントを流し、通信教育会社は教育のコンテンツを流し、また、企業はトレーニング教材を流す。

このようなストリーミング・メディアの多くの用途において、コンテンツへのアクセスを管理する事は必要不可欠である。例えば、エンターテインメント会社は、ストリーミング・メディアのアイテムをエンド・ユーザが視聴する毎に課金し得るが、これはエンターテインメント業界においては「ペイ・パー・ビュー」と称されている。同様に、通信教育会社は、オンライン教育のコースへのアクセス、およびストリーミング・メディアへのアクセスに対して、学生に課金する。企業関係のコンテンツは多くの場合機密であり、従って、管理されたアクセスを必要とする。

従って、ストリーミング・メディアへのアクセスを制限するために各種のシステムが開発されている。ストリーミング・コンテンツへのアクセスを制限するための現在の業界標準は、ストリーミング・メディア・コンテンツを提供するのに先立ってエンド・ユーザを確認するストリーミング・メディア・サーバを含んでいる。より具体的には、ストリーミング・メディア・サーバは、ストリーミング・メディアへのアクセスを許可するかどうかを判断するロジックを含むコンパイルされたプログラムのソフトウェア・プラグインを含んでいる。しかしながら、そのような認証プラグインはしばしば複雑になり、開発・維持が困難である。例えば、ストリーミング・メディア・コンテンツへのアクセスを許可するロジックを変更する必要性が生じた場合、ストリーミング・メディア・サーバ上のコンパイルされたプラグインの変更は困難である。更に、ストリーミング・メディア・サーバに存在するロジックの全てにおいて、ストリーミング・メディア・サーバは、データベースあるいは各所に配置されるメッセージ転送サービスに対して直接アクセスしていなければならない。さらに、ストリーミング・メディア・コンテンツにアクセスすることを認められているような特定のエンド・ユーザを確認するような例においてさえも、そのようなエンド・ユーザは、多くの場合、非認定のエンド・ユーザとアクセスを共有することにより認定プロセスの裏をかくことができる。このようなアクセスの共有は、コンテンツへのリンクのユーザ名およびパスワードを共有する事のような多くの形式を取り得る。同様の問題が、他の形式のデジタル・コンテンツへのアクセスを管理するために使用されるシステムにおいても存在する。従って、デジタル・コンテンツ、具体的にはストリーミング・メディア・コンテンツへのアクセスを管理し、エンド・ユーザを認定するための改善されたシステムおよび方法が必要となっている。

本発明は、オーディオ、ビジュアル、ビデオ、テキスト、ストリーミング・メディアのようなデジタル・コンテンツへのアクセスを管理するシステムおよび方法を提供する事によって、上記の、および他のニーズを解決する。本発明に係る１つのシステムおよび方法はストリーミング・メディアへのアクセスを管理し、ネットワークに接続されたウェブ・サーバ、メディア・サーバ、およびパーソナルコンピュータのようなエンド・ユーザ・プロセッサを備える。

運用において、ファイルへアクセスしたいとのエンドユーザのリクエストに応答して、ウェブ・サーバは、暗号化されたチケットを生成する。生成されたチケットは、該チケットが生成された時刻またはその近接時刻に少なくとも一部基づいている。いくつかの実施形態において、該チケットは、他の情報、例えばセキュリティ・タイム・インターバルまたはエンド・ユーザの識別子に基づく。

メディア・サーバは、前記リクエストされたファイルへのアクセスを提供する前に、認証チケットを、好ましくは前記ウェブ・サーバと同一の暗号化アルゴリズムを用いて、生成する。該メディア・サーバ認証チケットは、少なくとも一部、前記メディア・サーバが前記ファイルへアクセスしたいとの前記リクエストを受信した時刻またはその近接時刻に基づく。前記メディア・サーバは、前記ファイルへのアクセスを許可するか否かを、前記ウェブ・サーバによって生成されたチケットと、前記メディア・サーバによって生成されたチケットとを比較する事によって、判断する。

一実施形態において、これらのチケットが一致しない場合は、ウェブ・サーバがチケットを生成した時刻とメディア・サーバがチケットを生成した時刻との差が、所定の時間量よりも大きく、そのチケットは論理的に「有効期限切れ」になっているものと考えられる。従って、前記メディア・サーバは、前記メディア・コンテンツへのアクセスを許可しない。これらのチケットが一致する場合、これらのチケットは認可されたタイム・インターバルの範囲内に生成されており、前記メディア・サーバは、エンド・ユーザが前記リクエストされたメディア・コンテンツへのアクセスを許可する。

本発明のいくつかの好ましい実施形態を以下に図面を参照して説明する。コンテンツへのアクセスを管理する本発明は、ストリーミング・メディア・ファイルへのアクセスを管理するコンテキストに記載されるが、本発明が全ての種類のメディアまたはファイルに適用され得る事は理解されるべきである。さらに、本願明細書において記載される実施形態はオンデマンドのストリーミング・メディアに関するものであるが、本実施例がライブのストリーミング・メディアにも適用できることは、当業者が認め得ることである。

一般に、本実施形態のシステムは、エンド・ユーザ・プロセッサ１０２、ストリーミング・メディア・サーバ１０４、およびコンテンツ・マネジメント（ＣＭ）・データベース１０８を備えるウェブ・サーバ１０６を有し、これらの全てがインターネットに接続される。前記エンド・ユーザ・プロセッサ１０２は、インターネット・エクスプローラーと言う名称でマイクロソフト社より提供されるか、または、ネットスケープ・ナビゲータと言う名称でネットスケープ・コミュニケイションズより提供されるようなインターネット・ブラウザと、そして、ウインドウズ・メディア・プレーヤーと言う名称でマイクロソフト社より提供される、また、リアルプレーヤーと言う名称でリアル・ネットワークス社によって提供されるストリーミング・メディア・プレーヤーとを含む。前記ウェブ・サーバ１０６は、前記エンド・ユーザ・プロセッサ１０２によってアクセス可能なウェブサイトを提供する。一方、前記ウェブサイトは、前記エンド・ユーザ・プロセッサ１０２が前記ストリーミング・メディア・サーバ１０４上に置かれているストリーミング・メディア・コンテンツにアクセスするために、エンド・ユーザ・プロセッサ１０２によって起動可能なリンクを含む。

本発明は、様々なコンピュータ技術の使用に適用し得る事が理解されよう。例えば、本実施形態はインターネットによってコンテンツへのアクセスを提供する事に関するが、本発明は、例えば広域ネットワークを含む任意のコンピュータネットワーク上に使用され得る。同様に、前記エンド・ユーザ・プロセッサ１０２は、例えばＰＤＡ、ウェブ対応の携帯電話、ネットワークにダイアルアップする有線電話、モバイル・コンピュータ、パーソナルコンピュータ、インターネット装置等のネットワークに接続し得る任意のデバイスであり得る。更に、本明細書中に記載の前記サーバは、任意のソフトウエアを実行する任意の種類のもので有り得、また、本明細書中に記載のソフトウェア・モジュール、オブジェクトおよびプラグインは、どのようなプログラム言語で記述されていてもよい。最後に、本明細書中に記載の前記データベースおよび記憶装置は、あらゆる記憶技術、例えばローカルのコンピュータ・メモリー、ネットワークに接続された記憶装置、および磁気的あるいは光学的などの公知のどのような記憶媒体を用いても良い。

前記ＣＭデータベース１０８の一例が図２に示される。図示されるように、データベース１０８は、全てのストリーミング・コンテンツに普遍的に適用可能な情報と、関連データの幾つかのテーブルを含む。普遍的な情報テーブル２０２はセキュリティ・キー、セキュリティ・インターバル、およびコンテンツが保存されているストリーミング・メディア・サーバ１０４の名前（「ホスト名」）を含んでいる。セキュリティ・キーおよびセキュリティ・インターバルは、エンド・ユーザ・プロセッサ１０２がコンテンツにアクセスすることを許可するために使用され、秘密にされ、かつ、コンテンツの所有者によって設定される事が望ましい。セキュリティ・キーおよびセキュリティ・インターバルは全てのコンテンツに対するアクセスを管理するために使用されるが、他の実施形態においては、各コンテンツ・ファイルがそれ自身に関するセキュリティ・キーおよびセキュリティ・インターバルを有する。

ＣＭデータベース１０８は、コンテンツあるいはストリーミング識別情報を含む一連のテーブルをさらに有する。より詳細には、ストリーミング・テーブル２０４は、固有のストリーム識別子（ＩＤ）によって識別されるそれぞれのストリーミング・コンテンツのレコードを含む。更に、各レコードは、例えばコンテンツ・ファイルの作成日を含むコンテンツ・ファイルについて記述するストリームの詳細、ファイルの記述、コンテンツがオーディオであるかビデオであるかのアイデンティフィケーション、コンテンツが関係するプラットフォーム、コンテンツが最後に修正された日付、コンテンツを視聴するのに必要なコーデック、コンテンツの長さおよびサイズ、コンテンツの有効期限（もしあれば）、.asfまたは.rmのようなストリームの種類、コンテンツのタイトルおよびコンテンツの作者、コンテンツのステータス、コンテンツの著作権情報、コンテンツのビットレート等を含む。各レコードは更に、メディア・サーバ１０４へのリンクを生成するために使用されるプレフィックス（「ＵＲＬプレフィックス」）、およびストリーミング・メディア・サーバ１０４に格納されているコンテンツ・ファイルの名前（「ファイル名」）を含む。このファイル名は、オンデマンドのコンテンツ用のストリーミング・メディア・サーバ１０４に接続された記憶装置上の実際のパスを指しても良いし、このファイル名は、ライブ・ストリームのエイリアス、チャネルまたはポートを指しても良い、と言う事が理解されるべきである。

データベース１０８は「再生リスト」情報を有するテーブルを含む。クライアントの再生リストは、一般に、グループとして利用可能とされるために論理的に関連づけられた、１つ以上のコンテンツ・ファイルのグループである。再生リストの一部であると確認された各コンテンツ・ファイルもまた個々に利用可能になされ得る。このような再生リスト情報は、再生リストテーブル２０８および再生リスト・ストリーム・テーブル２１０に含まれる。一般に、再生リストテーブル２０８は、再生リストＩＤによって識別される各再生リストを識別するレコードを含む。各レコードは、さらに再生リストの詳細を含んでおり、この再生リストの詳細は、例えば、再生リストのフォーマット（例えば、ウインドウズ・メディア・プレーヤーまたはリアル・プレーヤー）、再生リストの記述、再生リスト名および同種のもの、および再生リストの認定ユーザ・グループＩＤを含む。

上記認定ユーザ・グループＩＤは、前記特定の再生リストを視聴することを認められるエンド・ユーザ・プロセッサ１０２のグループに対応する。より詳細には、データベース１０８は、固有のエンド・ユーザＩＤによって識別される各エンド・ユーザ・プロセッサ１０２を１つ以上の認定ユーザ・グループＩＤに関連付ける認定ユーザ・テーブル２０６をさらに含む。エンド・ユーザ・プロセッサ１０２が再生リストを視聴するために、エンド・ユーザ・プロセッサ１０２が該コンテンツ・ファイルのための認定ユーザ・グループＩＤの一部であるということが確認されなければならない。他の実施形態においては、認定グループＩＤは使用されない場合もあり、更に他の実施形態においては、コンテンツ・ファイルのそれぞれが、該ファイルに関連付けられた認定グループＩＤを有する。

再生リスト・ストリーム・テーブル２１０は、再生リストＩＤによって識別される再生リストと、ストリームＩＤによって識別される前記構成コンテンツ・ファイルとを関連付けるレコードを有する。さらに、各レコードは、再生リスト中の各コンテンツ・ファイルの順番を示す情報（「ソート順番」）を含んでいる。

本実施形態において使用されるコンポーネントについて記載してきたが、ここで、ストリーミング・メディア・コンテンツへのアクセスを管理するプロセスについて記述する。概説すると、ウェブ・サーバ１０６に保存された認定ソフトウエア・コンポーネントは、公開暗号キー情報、プライベート・キー情報および現在時刻に基づいたハッシュ値すなわち“チケット”を生成する。前記公開暗号キーは、エンド・ユーザ・プロセッサ１０２およびエンド・ユーザのユーザＩＤによってリクエストされるストリーミング・コンテンツが有する固有の識別子である。前記プライベート・キーは、コンテンツの所有者によって設定されたセキュリティ・キーとセキュリティ・インターバルを含む。

リクエストされたコンテンツが格納されているストリーミング・メディア・サーバ１０４は、前記公開暗号キーを含む前記ストリーム・リクエストと、ウェブ・サーバ１０６によって生成された前記チケットを受信する。ストリーミング・メディア・サーバ１０４は、自身のチケットを生成するために、ローカルに格納されたプライベート・キー情報を使用するプロセスへと進む。ストリーミング・メディア・サーバ１０４は、ストリーミング・メディア・サーバ１０４によって生成されたチケットとウェブ・サーバ１０６によって生成されたチケットとの比較に基づいて、前記リクエストされたストリーミング・メディア・コンテンツへのアクセスを、拒否もしくは供給する。

前記アクセスを管理するプロセスを、次に、図３のワークフロー・ダイアグラムおよび図４および図５のフローチャートを参照して詳細に説明する。本実施例において、エンド・ユーザ・プロセッサ１０２があるストリーミング・メディア・コンテンツ・ファイルへのアクセスをリクエストする。まず、ウェブ・サーバ１０６は、エンド・ユーザへ認証アプリケーションへのログインを促すとともに所望のストリーミング・メディアを視聴する選択肢をエンド・ユーザに提示するウェブ・ページを提供する（ステップ３０２）。例えば、このようなページは、いくつかのコンテンツ・ファイルのうち、視聴するための１つのコンテンツを選択することをエンド・ユーザにリクエストするフォームを含んでいてもよく、このフォームは、（コンテンツの所有者が前もって割り当ててエンド・ユーザに提供した）エンド・ユーザＩＤと、選択されたコンテンツへのアクセスに対するエンド・ユーザへの課金を可能とするクレジットカード番号とをエンド・ユーザに提供してもらうために用いられる。他の実施形態において、エンド・ユーザは、エンド・ユーザの連絡情報および請求書発行情報を提供することによりコンテンツの所有者によりあらかじめ登録され、コンテンツの所有者は、エンド・ユーザの連絡情報および請求書発行情報を、登録されたエンド・ユーザＩＤと共にテーブル形式で保存する。

ウェブ・ページに応答して、エンド・ユーザはエンド・ユーザのユーザＩＤを提供し、リンクを起動し、これによって、認証アプリケーションにログインし、該リンクに関連する特定のストリーミング・メディア・コンテンツ・ファイルへのアクセスをリクエストする（ステップ３０４）。一例として、ストリームＩＤが“123456”で表される場合のストリーム・リクエストを示すと、以下のようである：

本実施形態において、認証アプリケーションは、ウェブ・サーバ１０６上に存在する“.dll”ソフトウエア・コンポーネントである。しかしながら、ここに記述された機能性を実施するために、例えば、アクティブ・サーバー・ページ（ＡＳＰ）またはサーブレットのような他のプログラム言語あるいは技術を使用し得ることは、当業者に認められるところであろう。特定のプログラミング技術に関係なく、認証アプリケーションは、エンド・ユーザ・プロセッサ１０２が持つあらゆる処理上の隘路障害を軽減するようにウェブ・サーバ１０６上で実行されることが望ましい。

一旦エンド・ユーザが認証アプリケーションにログインし、ウェブ・サーバ１０６がエンド・ユーザからストリーム・リクエストおよびエンド・ユーザＩＤを受け取れば、ウェブ・サーバ１０６は、認証チケットを動的に生成し、選択されたコンテンツ・ファイルへのリンクを動的に生成することを継続する。より詳細には、認証アプリケーションの管理下において、ウェブ・サーバ１０６は、認証チケットを生成する際に使用するためのプライベート・キーをデータベース１０８に対してリクエストする（ステップ３０６）。ウェブ・サーバ１０６は、リクエストされたコンテンツ・ファイルに関連したセキュリティ・キーおよびセキュリティ・インターバルを含むプライベート・キーをＣＭデータベース１０８から検索するためにデータベース・クエリーを発行する。これを受けて、ＣＭデータベース１０８はウェブ・サーバ１０６にプライベート・キーを返送する（ステップ３０８）。

データベース１０８からプライベート・キーを取得した後、ウェブ・サーバ１０６はチケットを生成する（ステップ３１０）。図４を参照してより詳細に説明すると、ウェブ・サーバ１０６は、プライベート・キー、ストリームＩＤ、エンド・ユーザＩＤ、現在時刻およびハッシュ・アルゴリズムを利用して、チケットを生成する。本実施形態において、リクエストされたコンテンツのストリームＩＤが、ステップ３０４においてエンド・ユーザによって起動されたストリーム・リクエスト・リンクに含まれているので、ウェブ・サーバ１０６は、チケットを生成する際にストリームＩＤを使用することができる。しかしながら、他の実施形態においては、エンド・ユーザによって提供されるストリーム・リクエストは、例えばコンテンツのタイトル、作者、および（または）ファイル名の様な、ストリームＩＤ以外の固有な識別情報を含む。このような実施形態において、ウェブ・サーバ１０６はストリーム・テーブル２０４を検索し、前記ストリーム・リクエストに含まれる識別情報に基づいて前記ストリームＩＤを検索する。更に他の実施形態において、前記ストリーム・リクエストは、前記チケットを前記システムが生成する際に使用するファイル名またはパスのような、ストリームＩＤ以外の固有な識別子を含む。

一旦前記チケットが生成されると、ウェブ・サーバ１０６はメディア・サーバ１０４上に存在するリクエストされたコンテンツへのリンクを生成する。より詳細には、上に例示したストリーム・リクエストに基づいて、エンド・ユーザ・プロセッサ１０２に存在するメディア・プレーヤーが、メディア・サーバ１０４へのリンクを動的に生成するためのプログラム“getstream.asp”を実行する“webserver.company.com”（即ち、ウェブ・サーバ１０６）へ回線を接続する（ステップ３１２）。当業者は、“getstream”アプリケーションはアクティブ・サーバー・ページ（即ちＡＳＰ）の拡張子を有しているが、ＡＳＰ技術を使用することが必ずしも必要ではないことを、認めることであろう。むしろ、“.dll”コンポーネントの様な任意のプログラミングまたはスクリプト言語または技術が所望の機能性を提供するために使用され得る。しかしながら、認証アプリケーションにおいて、エンド・ユーザ・プロセッサ１０２におけるあらゆる処理上の隘路障害を軽減するために、該プログラムはサーバ側で実行されることが望ましい。“getstream.asp”プログラムは、メディア・サーバ１０４へのリンクを動的に生成するのに必要となるデータを検索するため、ウェブ・サーバ１０６がＣＭデータベース１０８を呼び出す様に機能する。より詳細には、ウェブ・サーバ１０６は、普遍情報テーブル２２０およびＵＲＬプレフィックスからホスト名を検索し、ストリーム・テーブル２０４からファイル名を検索する。更に、“getstream.asp”プログラムは、ストリームＩＤ、チケットおよびエンド・ユーザＩＤをリンクの端部に付加する。その後、ウェブ・サーバ１０６は、エンド・ユーザ・プロセッサ１０２のメディア・プレーヤーへリンクを返送する（ステップ３１４）。

メディア・ファイルへのリンクの実例は以下の通りである。

ここで、ＵＲＬプレフィックスは“mms://”によってリクエストされ、ホスト名は“mediaserver.company.com”によって表わされ、ファイル名は“stream1.asf”によって表わされ、リクエストされたコンテンツのストリームＩＤは“123456”によって表わされ、チケットは“uvw123xyz”によって表わされ、そして、エンド・ユーザＩＤは“abc123def”によって表わされる。

リンクを受信した後、エンド・ユーザ・プロセッサ１０２は、ストリーミング・メディア・コンテンツをリクエストするステップに進む（ステップ３１６）。より詳細には、エンド・ユーザ・プロセッサ１０２に存在するメディア・プレーヤーがリンクによって識別される“mediaserver.company.com”（即ち、ストリーミング・メディア・サーバ１０４）を呼び出す。呼び出しの一部として、メディア・プレーヤーは、リクエストしたコンテンツのストリームＩＤのコピー、ウェブ・サーバ１０６によって生成されたチケット、およびエンド・ユーザＩＤをストリーミング・メディア・サーバ１０４に供給する。

ストリームＩＤ、エンド・ユーザＩＤおよびチケットを含んでいるリンクを受信した後、ストリーミング・メディア・サーバ１０４は、リクエストされたコンテンツへのアクセスをエンド・ユーザに許可するかどうかを判断するステップに進む（ステップ３１８）。図５を参照して以下により詳細に説明すると、ストリーミング・メディア・サーバ１０４は、ローカルに格納されたプライベート・キー情報およびリンク中に含まれるストリームＩＤおよびエンド・ユーザＩＤに基づいてチケットを個々に生成することにより、アクセスを許可するかどうかを判断する。一般的に、ストリーミング・メディア・サーバ１０４によって生成されたチケットがウェブ・サーバ１０６によって生成されたチケットと一致する場合、ストリーミング・メディア・サーバ１０４はリクエストされたストリーミング・メディア・コンテンツをエンド・ユーザ・プロセッサ１０２に供給する（ステップ３２０）。

ウェブ・サーバ１０６によってチケットを生成する前記プロセスを、図４を参照して次に詳細に説明する。上述したように、チケット生成プロセスは、ウェブ・サーバ１０６に存在する認定ソフトウェア・プラグインによって行なわれることが好ましい。本実施形態において、本プロセスは、ウェブ・サーバ１０６がストリームＩＤおよびエンド・ユーザＩＤを含むストリーム・リクエストを受信するステップより開始される（ステップ４０２）。その後、ウェブ・サーバ１０６は、リクエストされたストリームＩＤに関連したプライベート・キー情報を検索するためにデータベース１０８にアクセスするステップへと進む（ステップ４０６）。このようなプライベート・キー情報は普遍的なセキュリティ・キーおよびセキュリティ・インターバルを含む。他の実施形態において、各ストリームはストリーム・テーブル２０４にフィールドとしてそれ自身のセキュリティ・キーおよびセキュリティ・インターバルを格納し、ウェブ・サーバ１０６はストリーム・リクエストに含まれるストリームＩＤに基づいてストリーム・テーブル２０４検索する。

上述のように、ウェブ・サーバ１０６は、また、チケットを生成するために現在時刻を使用する。より詳細には、ウェブ・サーバ１０６は、現在時刻を計算し、セキュリティ・インターバルに最も近い倍数に合うようにその時刻値の端数を切り捨てる（ステップ４１０）。本実施形態において、Ｃプログラミング言語の標準ライブラリー関数“time()”によって生成されるような協定世界時（ＵＴＣ）を秒単位で利用する。（変数“＄time”によって表される)前記セキュリティ・インターバルに最も近い倍数に合うように端数を切り捨てた前記時刻を生成するためのＰｅｒｌプログラム・コードの一例を示すと、以下のようである。

ここで、変数“＄interval”はセキュリティ・インターバルに対応しており、セキュリティ・インターバルは１５分である。

例えば、現在の時刻が２０００年５月３１日午後２：１６：０７（中部標準時）であった場合、関数“time()”は、おおよそ“959800567”の値を返す。このＵＴＣ値をその直近の１５分インターバルに合うように端数を切り捨てることによって“959800500”が得られ、これは、２０００年５月３１日午後２：１５：００（中部標準時）に相当する。

先に例示したコードは変更されても良く、その変更されたコードもまた本発明の範囲内であり得る事が理解されよう。例えば、セキュリティ・インターバルは数分である必要は無く、インターバルが“time()”関数によって用いられる時間の単位で表わされるように適切な変換が行なわれる限り、インターバルは他の時間の単位で表わされても良い。更に、他の実施形態において、現在時刻はＵＴＣ以外の標準時に基づく。そのような実施形態において、時間の標準は、ウェブ・サーバ１０６およびストリーミング・メディア・サーバ１０４に固有のものである。また、エンド・ユーザ・プロセッサ１０２に時間を計算させ、かつ認証チケットを生成する際に用いられるべく、ウェブ・サーバ１０６へその値を送信させることもまた、本発明の範囲内であることが理解されよう。更に他の実施形態において、標準時が単に端数を切り捨てられて所望の桁数となるように、セキュリティ・インターバルが選択される。

一旦、ウェブ・サーバ１０６がハッシュに対して入力された値（アルゴリズム公開暗号キー情報、プライベート・キー情報および時刻）を取得すると、ウェブ・サーバ１０６は、ハッシュ・アルゴリズムへ入力文字列を生成する（ステップ４１４）。本実施形態において、前記ハッシュ・アルゴリズムは“MD5”メッセージ・ダイジェスト・アルゴリズムである。さらに、本実施形態においては、メディア・サーバ１０４およびウェブ・サーバ１０６は同じアルゴリズムを利用する。

チケットを生成する任意のハッシュあるいは暗号アルゴリズムを利用する事は、本質的に本発明の範囲内である事が理解されよう。更に、チケットを生成する２つのサーバ（先の実施形態においては、ウェブ・サーバ１０６およびストリーミング・メディア・サーバ１０４）は、同一の入力に基づいて同一のチケットを生成するか、同一の入力に基づいて、相互の偏差が所定の範囲内のチケットを生成する事が望ましい。他の実施形態において、セキュリティを増加させるために、複数の利用可能なアルゴリズムの１つが使用される。例えば、そのような実施形態は、複数の利用可能なアルゴリズムから任意に選択された１個のアルゴリズムを使用するか、もしくは、リクエストされたコンテンツ、リクエストの日付と時間、特定のエンド・ユーザ、コンテンツを有するエンティティ等に基づいて複数のアルゴリズムから１つを選択する事も可能である。このような実施形態において、システムは、ウェブ・サーバによって使用されるアルゴリズムの指示をメディア・サーバへ転送するか、あるいは、メディア・サーバは、ウェブ・サーバによって利用されるアルゴリズムと同一のアルゴリズムを選択・使用させるロジックを有する。

使用される特定のハッシュ・アルゴリズムに対して入力文字列が有効である限り、およびストリーミング・メディア・サーバ１０４が入力文字列の配置を認識している限り、入力値の任意の配置が入力文字列として使用されてよい。本実施形態において、次の所定の配置が使用される。
TTTTTTTTTTKKKKKKKKKKSSSSSSSSSSUUUUUUUUUU
ここで、「T」は時刻の数字を表わし、「K」はセキュリティ・キーの英数字の文字を表し、「S」はストリームＩＤの数字（任意の必要な先行・埋め込み文字を含む）を表わし、そして「U」は、エンド・ユーザＩＤの英数字（任意の必要な先行・埋め込み文字を含む）を表わす。他の実施形態において、入力文字列は異なる長さであってもよい。

ハッシュ・アルゴリズム入力文字列を生成した後、ウェブ・サーバ１０６は入力文字列にハッシュ・アルゴリズムを適用し、それによってチケットを生成する（ステップ４１８）。

ストリーミング・メディア・サーバ１０４が、リクエストされたコンテンツ・ストリームへのアクセスを許可するかどうかを判断するプロセスを、図５を参照して次に説明する。先ず、必ずしも必要と言うわけではないが、本実施形態におけるメディア・サーバ１０４が３枚の認証チケットを生成し、それぞれのチケットは異なる時刻に基づき、アクセスを許可するべきかどうかを判断するために使用される、と言う事が注目されるべきである。更に、ウェブ・サーバの機能性と同様に、アクセスを許可するべきかどうかを判断するプロセスは、メディア・サーバ１０４上に存在する認定ソフトウエア・コンポーネント中で実行されることが望ましい。

アクセスを許可するべきかどうかを判断する際に、ストリーミング・メディア・サーバ１０４は、エンド・ユーザのプロセッサ１０２上に存在するメディア・プレーヤーから、ストリームＩＤ、エンド・ユーザＩＤおよびチケットを含むストリーム・リクエストを最初に受け取る（ステップ５０２）。一旦ストリーミング・リクエストが受信されると、メディア・サーバ１０４はハッシュ・アルゴリズムへの入力文字列を生成する。この点において、メディア・サーバ１０４はローカルメモリからプライベート・キー情報（すなわちセキュリティ・キーとセキュリティ・インターバル）を検索する（ステップ５０６）。メディア・サーバ１０４は、ローカルメモリにプライベート・キー情報を格納するのが望ましいが、他の実施形態においては、メディア・サーバ１０４は、例えばマイクロソフト社によって提供されるライト−ウエイト・ディレクトリー・アクセス・プロトコルによってアクセスされるアクティブ・ディレクトリー・ツリーに情報を格納してもよいし、または遠隔のデータベースに情報を格納してもよい。更に他の実施形態において、メディア・サーバ１０４は、ローカル・エリア・ネットワーク（ＬＡＮ）のようなネットワーク接続によってデータベース１０８にアクセスすることにより、プライベート・キー情報を検索する。

ウェブ・サーバ１０６が行ったように、メディア・サーバ１０４は更に現在時刻を計算し、セキュリティ・インターバルに最も近接した倍数に合うようにその値の端数を切り捨てる（ステップ５１０）。しかしながら、ウェブ・サーバ１０６と異なり、ストリーミング・メディア・サーバ１０４は、また、前記メディア・サーバ１０４によって計算された前記第１の時間値より小さい（すなわち、より早い）、前記セキュリティ・インターバルに次に最も近接した倍数に合うように前記現在時刻値の端数が切り捨てられた値である第２の時間値を計算する（ステップ５１０）。メディア・サーバ１０４は、さらに、前記セキュリティ・インターバルの前記最も近い倍数に合うように前記現在時刻値の端数が切り上げられた（すなわち、より過去時刻である）値である第３の時刻値を計算する（ステップ５１０）。

その後、メディア・サーバ１０４は、３つの対応するハッシュ入力文字列を生成するために、検索されたプライベート・キー情報、受信された公開暗号キー情報および３つの時刻を使用する（ステップ５１４）。その後、メディア・サーバ１０４は、ハッシュ・アルゴリズムに対して３つの入力文字列を適用し、これによって、３枚のチケットが生成される（ステップ５１８）。

個々にチケットを生成した後、メディア・サーバ１０４は、メディア・サーバ１０４によって生成されたチケットのうちの任意のチケットがウェブ・サーバ１０６によって生成されたチケットと一致するかどうかを判断する（ステップ５２２）。チケットが一致しない場合、ストリーミング・リクエストが本物でない、かつ（または）、有効期限切れである（つまり、メディア・サーバ１０４によって生成された時刻が、ユーザのリクエストの時間から測定されるセキュリティ・インターバルの範囲を超えている）可能性が高い。従って、メディア・サーバ１０４はリクエストされたコンテンツへのアクセスを許可しない（ステップ５２６）。

チケットが一致する場合、ストリーム・リクエストは本物かつセキュリティ・インターバルの範囲内のものである。しかしながら、アクセスを許可するのに先立って、メディア・サーバ１０４は、エンド・ユーザが既に同じコンテンツへのアクセスを以前にリクエストし、視聴したかどうかを最初に判断する（ステップ５３０）。メディア・サーバ１０４は、エンド・ユーザＩＤのリストと、ユーザが以前にアクセスを許可されたストリームＩＤを対応させてローカルメモリに保持する事が望ましい。エンド・ユーザがリクエストされたコンテンツを既に視聴したかどうかを判断するために、メディア・サーバ１０４は、受信したエンド・ユーザＩＤおよびストリームＩＤが既に格納されているかどうかを判断するために、メモリにアクセスする。エンド・ユーザＩＤおよびストリームＩＤが既に格納されている場合、エンド・ユーザは、リクエストしたコンテンツに対するアクセスを許可されない（ステップ５３０）。

受信されたエンド・ユーザＩＤおよびストリームＩＤが未だ格納されていない場合、メディア・サーバ１０４は、エンド・ユーザＩＤおよびストリームＩＤをメモリに格納するステップへと進み（ステップ５３４）、エンド・ユーザにコンテンツへのアクセスを許可する（ステップ５３８）。このように、エンド・ユーザＩＤおよびストリームＩＤを格納することによって、リクエストされたコンテンツを指し示すリンクをエンドユーザが他人と共有する事を防ぐという任意レベルのセキュリティ保護を付加することができる。

ウェブ・サーバ１０６のローカル時間とメディア・サーバ１０４のローカル時間の間が同期されていない点に対応するために、３つのチケットを使用する事が望ましい事が理解されよう。更に、ある状況では、エンド・ユーザが認証されている場合でも、メディア・サーバ１０４によって生成された（つまり、セキュリティ・インターバルに最も近接した倍数に合うように前記現在時刻値の端数を切り捨てた値に基づく）第１のチケットが、ウェブ・サーバ１０６によって生成された第１のチケットと一致しない。例えば、所定のセキュリティ・インターバルを１５分とすると、ウェブ・サーバ１０６が午後１２：１４：００にチケットを生成し、メディア・サーバ１０４が午後１２：１６：００にその第１のチケットを生成する場合、同じ時間帯の同じ日において、たとえリクエストがセキュリティ・インターバルの範囲内にあってもチケットは一致しない。メディア・サーバ１０４が午後１２：１５：００に対応する時刻値に基づいたチケットを生成する一方、ウェブ・サーバは、午後１２：００：００に対応する時刻値に基づいたチケットを生成する。従って、本実施形態において、メディア・サーバ１０４は、セキュリティ・インターバルに２番目に近接した倍数に合うように現在時刻値の端数を切り捨てた時刻値に基づいた第２のチケットを生成する。本例においては、午後１２：００：００に対応する。そのため、第２のチケットはウェブ・サーバ１０６によって生成されるチケットと一致する。同様に、セキュリティ・インターバルが経過した後、エンド・ユーザに対してアクセスを許可する事も可能である。したがって、本実施形態において、セキュリティ・インターバルは複数のチケットの使用を保証するように選択されるべきである。ウェブ・サーバ１０６およびメディア・サーバ１０４は、セキュリティ・インターバルの半分の時間内の誤差で合わせられた時計を有する事が望ましい。

メディア・サーバ１０４が、先の実施形態中における３つのチケットの代替として１つ以上の異なるチケットを生成する事もまた、本発明の範囲内である事が理解されよう。更に、先の実施形態においては、同時に、すなわち並列に生成されるチケットについて記述したが、メディア・サーバ１０４がチケットを、連続して順次に、生成および／または比較する事もまた、本発明の範囲内である。また、前記時刻値は多くの方法で生成され得、例えば、前記メディア・サーバ１０４によって計算された第１の時刻に単にセキュリティ・インターバルを加える、または前記第１の時刻から単に前記セキュリティ・インターバルを除する事によって生成されても良い、と言う事が理解されよう。

他の実施形態において、異なったレベルのセキュリティが提供されてもよい。特に、ウェブ・サーバ１０６によって生成されたチケットがメディア・サーバ１０４によって生成されたチケットのうちの１つと一致する場合、メディア・サーバ１０４は同じチケットが以前に生成されていたかどうかを判断するステップへと進む。メディア・サーバ１０４は、アクセスが許可されたチケットのリストを保持する。論理上、このようなリストは全ての“使用済”チケットを表している。一致したチケットが“使用済”チケットのリストに載っていない場合、メディア・サーバ１０４は、エンド・ユーザのプロセッサ１０２に存在するメディア・プレーヤーに、リクエストしたコンテンツに対するアクセスを許可する。アクセスを許可するステップの一部として、メディア・サーバ１０４は、“使用済”チケットのリストを更に更新する。一致したチケットが使用済チケットのリストに載っている場合、メディア・サーバ１０４はアクセスを拒否し、リクエストしたエンド・ユーザに適切なメッセージを供給する。使用済チケットをトラッキングする事によって、システムは、認可されたエンド・ユーザがウェブ・サーバ１０６から受信された前記ストリーミング・リクエストを他人と共有するのを防ぐ。

さらに、アクセスを許可するべきかどうかを判断する際にエラー計算を使用する事も、本発明の範囲内であると言う事が理解されよう。例えば、１つのエラー計算は、所定の期間（例えば１５分、３０分等）、適用可能なセキュリティ・インターバルの設定百分率（例えば、５０％、１２５％等）のセット割合あるいは他のエラー計算のような、エラー・インターバルを現在時刻に加えたおよび／または除した値に基づいて１以上の追加のチケットを生成するメディア・サーバ１０４を伴う。このようなエラー計算は、先の実施形態において、第２時刻値または第３時刻値の代替値として、またはそれに加えて使用されてもよい。

他の実施形態において、ウェブ・サーバ１０６およびメディア・サーバ１０４は、前記時刻値を先の実施形態とは異なった方法で計算することにより、チケットを生成する。典型的な一実施形態において、ウェブ・サーバ１０６およびメディア・サーバ１０４は、現在時刻と、この現在時刻値を前記セキュリティ・インターバル以外の或るインターバルの倍数へ切り下げまたは切り上げた時刻値を計算する。セキュリティ・インターバルが１５分である実施形態の場合、ウェブ・サーバ１０６は、５分のインターバルに最も近接した値に現在時刻値を切り下げた時刻値に基づいてチケットを生成する。次に、ストリーミング・メディア・サーバ１０４は、同じ５分インターバルに現在時刻値を切り下げた時刻値に基づいてチケットを生成する。チケットが一致しない場合、メディア・サーバ１０４は、時間的に遡った次のインターバルに切り下げた時刻値に基づいてチケットを生成するステップに進む。メディア・サーバは、所定の回数、またはウェブ・サーバとメディア・サーバのチケットが一致するまで、時間的に遡った次のよりインターバルに基づいたチケットを生成し続ける。メディア・サーバ１０４は、その和が少なくともセキュリティ・インターバルに及ぶ複数のタイム・インターバルに基づいて新しいチケットを繰り返し生成する。本実施例において、メディア・サーバ１０４は、合計１５分の５分インターバル、つまり、少なくとも３枚のチケットを生成する。

認定プロセスにおいてエンド・ユーザＩＤの使用を完全に省略するか、あるいは上述された方法とは異なる方法でエンド・ユーザＩＤを使用する事もまた、本発明の範囲内である事が理解されよう。例えば、他の実施形態において、エンド・ユーザＩＤは、ハッシュ・アルゴリズムへの入力文字列の一部として使用されない。その代わり、データベース１０８は、どのエンド・ユーザがコンテンツへのアクセスをリクエストしたかをトラッキングするためのテーブルを含む。このような実施形態は、該視聴ユーザ・テーブルは、ストリームＩＤで識別されるコンテンツと、該コンテンツ・ストリームに既にアクセスまたは視聴した、ユーザＩＤで識別されるエンド・ユーザとを関連づけるレコードを有する視聴ユーザ（ストリーム）テーブルを含む。同様に、本実施形態は、再生リストＩＤで識別される再生リストと、該コンテンツストリーミングに既にアクセスしたか視聴した、ユーザＩＤで識別されるエンド・ユーザとを対応付けるレコードを有する視聴ユーザ（再生リスト）テーブルを含む。認証チケットを生成する前に、ウェブ・サーバは、同じエンド・ユーザが特定のストリーミングおよび再生リストにアクセスする事を既にリクエストしたかどうかを判断するために、適切な視聴ユーザ・テーブルをチェックする。エンド・ユーザが既にアクセスをリクエストしていた場合、ウェブ・サーバはアクセスを拒否するか、あるいは、今回のアクセスに対してエンド・ユーザは再び課金されるであろうということを示すウェブ・ページをエンド・ユーザに供給する。テーブルは、セキュリティ・インターバルのような期間あるいはそれを超過する期間の後に、自動的にクリアーされる。

本発明が、コンテンツの所有者であるクライアントに代わって、ウェブ・サーバ、ストリーミング・メディア・サーバおよび再生リスト・サーバを例えばサービス・プロバイダーが操作するような比較的複雑なシステムに適用される事も可能である、と言う事が理解されよう。次に、このような実施形態の一つを、図６〜８を参照して説明する。本実施形態における機能性の多くは図３に示された実施形態における機能性と同一であり、同一の技術のうちで任意のものによって実施され得る、と言う事が当業者によって理解されよう。

図６に示されるように、本システムは図１に示された実施形態の構成要素と同様の構成要素を幾つか含む。本システムは、エンド・ユーザ・プロセッサ６０２、データベース６０８を含む１つ以上のストリーミング・メディア・サーバ６０４、および１つ以上のウェブ・サーバ６０６を含み、これらのすべてはインターネットあるいは他のネットワークへ接続される。さらに、本実施形態におけるシステムは、サービス・プロバイダーによって操作される再生リスト・サーバ６１０を更に含む。データベース６０８を含むウェブ・サーバ６０６、ストリーミング・メディア・サーバ６０４、および再生リスト・サーバ６１０は、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）のようなサービス・プロバイダーのネットワークおよびインターネットに接続される事が好ましい。

一般的に、データベース６０８は図２の実施形態のデータベースに含まれている情報と同じ情報を含んでいるが、該情報はクライアント・アカウント毎に格納される。図７に示されるように、データベース６０８は、アカウントＩＤによって識別される各クライアントのレコードを含むアカウント・テーブル７０２を含む。各レコードは、クライアント名、アドレス、請求書発行情報等のクライアントを識別する情報（“クライアント情報”）、クライアントのコンテンツが保護されているかどうかに関する表示（“保護状態表示
”）、クライアントのセキュリティ・キー（“セキュリティ・キー”）、およびセキュリティ・インターバル（“セキュリティ・インターバル”）を更に含む。

図２の実施形態と同様に、本データベース６０８は、また、ストリームＩＤによって識別される各コンテンツ・ファイル用のストリーム識別情報を含むストリーム・テーブル７０４と、認定ユーザ・グループＩＤにエンド・ユーザＩＤを対応付ける認定ユーザ・テーブル７０６と、再生リストＩＤによって識別される各再生リスト用の再生リスト識別情報を含む再生リストテーブル７０８と、所定の再生リストＩＤに関連付けられたストリームＩＤを識別する再生リスト・ストリーム・テーブル７１０を、備える。図２のデータベースに関して記述された情報フィールドに加えて、本実施例のストリーム・テーブル７０４および再生リストテーブル７０８は、各コンテンツ・ファイルおよび各再生リストに関連したアカウントＩＤを識別するフィールドをそれぞれに更に含む。

本データベース６０８は、コンテンツ・ファイルが格納される特定のストリーミング・メディア・サーバ６０４のホスト名を識別し、ストリームＩＤによって指定される各コンテンツ・ファイル用のレコードを含むストリーム・サーバ・テーブル７１２を含む。図２における実施形態と同様、前記ホスト名はメディア・サーバ６０４のＤＮＳ名である。

次に、本実施形態の動作を、図８のワークフローを参照して説明する。本実施例の目的のために、エンド・ユーザは１つの保護コンテンツを含む再生リストへのアクセスをリクエストする。最初、ウェブ・サーバ６０６は、認証アプリケーションにログインすることをエンド・ユーザにリクエストし、所定のストリーミング・メディアを視聴する選択肢をエンド・ユーザに選択させるウェブ・ページを提供する（ステップ８０２）。図３の実施形態と同様に、典型的なウェブ・ページは、リンクを起動する事によって特定のコンテンツ・ファイルを選択する事と、エンド・ユーザＩＤを提供する事と、請求書発行情報を提供する事をエンド・ユーザにリクエストするフォームを備えてもよい。前記ウェブ・ページに応答して、エンド・ユーザはエンド・ユーザのユーザＩＤおよびクレジットカード情報を提供し、ストリーム・リクエスト・リンクを起動し、これによって、特定のストリーミング・メディア・コンテンツ・ファイルへのアクセスをリクエストする。再生リストＩＤが“789000”である典型的なストリーム・リクエスト・リンクは以下のとおりである。

エンド・ユーザが前記ストリーム・リクエスト・リンクを起動する場合、エンド・ユーザ・プロセッサ６０２上で実行されるプログラミング・スクリプトによって、前記ストリーム・リクエスト・リンクおよびエンド・ユーザＩＤがウェブ・サーバ６０６に送信される（ステップ８０４）。当業者は、エンド・ユーザ・スクリプトが、例えばＣ＋＋、Ｐｅｒｌ、ビジュアルベーシック、Ｊａｖａ（登録商標）等の実質的に任意のプログラム言語によって記述され得る事を認めるであろう。本実施形態において、そのスクリプトはＪａｖａスクリプトであり、エンド・ユーザのウェブ・ブラウザと共働して実行される。

一旦ウェブ・サーバ６０６が前記スクリプトから前記ストリーム・リクエストを受け取ると、ウェブ・サーバ６０６は、認定ソフトウェア・プラグインの指示の下にチケットを生成する。この点において、ウェブ・サーバ６０６は、認証チケットを生成する際に使用されるプライベート・キーを（本実施形態において、セキュリティ・キーとセキュリティ・インターバルはリクエストされた再生リストと関連付けられている）、データベース６０８へ要求するリクエストを発行する（ステップ８０６）。これを受けて、データベース６０８はウェブ・サーバ６０６に前記プライベート・キーを返す（ステップ８０８）。

データベース６０８からプライベート・キーを取得した後、ウェブ・サーバ６０６は、図４を参照して上述されたように、前記ストリームされたもの（本実施形態において、再生リストＩＤに代替される）の代わりに再生リストＩＤを使用することによって、チケットを生成する（ステップ８１０）。前述のように、ウェブ・サーバ６０６は、チケットを生成するためにハッシュ・アルゴリズムにプライベート・キー、ストリームＩＤ、エンド・ユーザＩＤおよび時刻を適用する。その後、ウェブ・サーバ６０６は、エンド・ユーザ・プロセッサ６０２上で実行されるウェブ・ブラウザにチケットおよびエンド・ユーザＩＤを返す（ステップ８１２）。

前記チケットを受信した後、エンド・ユーザ・プロセッサ６０２上で実行されるスクリプトは、ストリーム・リクエスト・リンクの末端に情報をアペンドする（ステップ８１４）。典型的なリンクを例示すると、以下のようである。

ここで、再生リストＩＤは“789000”で表され、チケットは“uvw123xyz”で表され、エンド・ユーザＩＤは“abc123def”で表される。

そこで、前記エンド・ユーザ・プロセッサ６０２上で実行されるスクリプトは、ホスト名“playlistserver.company.com”によって前記ストリーム・リクエスト・リンク中に識別される再生リスト・サーバ６１０を呼び出させる（ステップ８１６）。従って、再生リスト・サーバ６１０は、リンク、再生リストＩＤ、チケットおよびユーザＩＤを供給される。“makeplaylist.dll”オブジェクトの管理の下で、再生リスト・サーバ６１０は、ＡＳＸファイルのような、コンテンツがウインドウズ・メディア・フォーマットであるリダイレクター・ファイルを生成する（ステップ８１８）。“makeplaylist”プログラムは、例えばＡＳＰを含む多くのプログラムあるいは技術のうちの任意のものを使用して実施してもよい。前記リダイレクター・ファイルは、チケットおよび公開暗号キー（つまり、ストリームＩＤおよびエンド・ユーザＩＤ）に加えて、リクエストされたコンテンツへのリンクを含んでいる。前記リダイレクター・ファイルを生成するために、再生リスト・サーバー６１０は、データベース６０８にアクセスして、再生リストと、ストリームＩＤに関連付けられたホスト名、ＵＲＬプレフィックスおよびファイル名を含むコンテンツ・ファイルへのリンクに必要な情報とを有する前記コンテンツ・ファイルの前記ストリームＩＤを検索する。

他の実施形態において、エンド・ユーザ・スクリプトは、前記ストリーム・リクエストにチケットをアペンドするために利用されない。その代わり、エンド・ユーザが自身のエンド・ユーザＩＤを提供し、前記ストリーム・リクエスト・リンクを起動する場合（ステップ８０４）、ウェブ・サーバ６０６上で実行される認証アプリケーションがチケットを生成し、前記ストリーム・リクエスト・リンクに前記チケットおよびエンド・ユーザＩＤをアペンドし、前記リダイレクター・ファイルを作成するために再生リスト・サーバ６１０を直接呼び出す。さらに、ウェブ・サーバ６０６がエンド・ユーザ・プロセッサ６０２上のメディア・プレーヤーを識別する情報を再生リスト・サーバ６１０情報に転送するので、再生リスト・サーバ６１０は、メディア・プレーヤーへリダイレクター・ファイルを転送する（これにより、ステップ８１２，８１４および８１６が省略される）。このような実施形態は、図１０を参照して、以下に説明する。

前記再生リスト・サーバ６１０は、その後、エンド・ユーザ・プロセッサ６０２のメディア・プレーヤーへＡＳＸリダイレクター・ファイルを転送する（ステップ８２０）。本実施例の目的に対して、ＡＳＸファイルは以下のとおりに記述される。

ここでＵＲＬプレフィックスは、“mms://”で表され、適切なメディア・サーバ６０４のホスト名が“mediaserver.company.com”で表され、ファイル名は“stream1.asf”で表され、リクエストされたコンテンツ・ストリームＩＤは“123456”で表わされ、チケットは“uvw123xyz”で表され、エンド・ユーザＩＤは“abc123def”で表される。

リダイレクター・ファイルは、コンテンツ・ファイル用メタデータや、広告のような保護されていないファイルのような他の情報を含んでいても良い。

前記ＡＳＸファイルを受信した後、エンド・ユーザ・プロセッサ６０２はストリーミング・メディア・コンテンツをリクエストするステップへと進む。より詳細には、メディア・プレーヤーは、ＡＳＸファイル中に識別される“mediaserver.company.com”（つまり、ストリーミング・メディア・サーバ６０４）を呼び出す（ステップ８２２）。一旦、前記呼び出しがなされると、メディア・プレーヤーは、リクエストされた番組のストリームＩＤのコピー、ウェブ・サーバ６０６によって生成されたチケット、およびエンド・ユーザＩＤをストリーミング・メディア・サーバに６０４を供給する。

前記メディア・プレーヤーの呼び出しに応答して、ストリーミング・メディア・サーバ６０４は、エンド・ユーザがアクセスをリクエストしているコンテンツへのアクセスを認めるかどうかを判断するステップへと進む（ステップ８２４）。ストリーミング・メディア・サーバ６０４は、個々に１以上の認証チケットを生成し、そのチケットをウェブ・サーバ６０６によって生成されたチケットと比較することにより、アクセスを許可するかどうかを判断する。認証チケットを生成および比較するプロセスは、ストリームＩＤの代わりに再生リストＩＤを使用する点を除いて、図５を参照して説明した方法と同じ方法で達成される。メディア・サーバ６０４によって生成されたチケットがウェブ・サーバ６０６によって生成されたチケットと一致する場合、メディア・サーバ６０４はエンド・ユーザがアクセスをリクエストしているコンテンツへのアクセスを許可する（ステップ８２４）。

先の実施形態において、保護コンテンツへの非認定アクセスに対して十分なレベルの保護が保護コンテンツの所有者に対して提供されていることは明らかであるが、更に高レベルの保護が与えられても良い。このような更に高レベルの保護は、特定のエンド・ユーザが所定の時間内においてアクセスし得るコンテンツ・ファイルの数を制限することを含む。他のレベルの保護は、保護コンテンツにアクセスするために特定のエンド・ユーザが使用するプロセッサ（例えば、コンピュータ）の数を制限する。先述のどの実施形態も、このような追加レベルの保護を含むように変更することができるものであり、かかる追加の保護の実施例を図９および１０を参照して以下に説明する。

図９の図示から分かるように、本実施形態は、図６〜８に図示され、これらを参照して説明した前記実施形態に基づいている。一般に、コンテンツ配信および認証システムは、前述のように、ウェブ・サーバ６０６、データベース６０８および再生リスト・サーバ６１０を含んでいる。更に、必ずしも必要と言うわけではないが、このシステムは、複数のストリーミング・メディア・サーバ６０４−１，６０４−２，６０４−ｎ（総称して６０４と称する）を含んでおり、そのそれぞれがサーバＩＤによって識別され、保護コンテンツを格納している。前記ストリーミング・メディア・サーバ６０４のそれぞれは、同一のストリーミング・コンテンツのコピーを備え、このシステムは、ラウンドロビンまたは他の負荷分散スキームの使用によって、ストリーミング・メディア・サーバ上の負荷のバランスを取ることが好ましい。データベース６０８は、各コンテンツ・ファイルを、格納されるサーバＩＤと関連付ける。以下の記載に基づいて理解されるように、本実施形態は、異なるメディア・サーバ上の同一のコンテンツ・ファイルにアクセスすることを許可された他のエンド・ユーザからアクセス情報を受信することによって、非認定エンド・ユーザが特定のメディア・サーバ上のコンテンツ・ファイルにアクセスする事を防止するので、特に複数のストリーミング・メディア・サーバを備えた使用に適している。図９に示されるように、先述の構成要素はセキュリティ保護下にあるネットワークによって相互に通信する事が望ましいが、しかしながら、他の実施形態では、グローバル・キャッシュ・サーバ９０２は、ストリーミング・メディア・サーバ６０４にのみに直接接続され、また、ビジネス・サーバ９０４はグローバル・キャッシュ・サーバ９０２にのみ直接接続される。先述した実施形態でのように、エンド・ユーザは、インターネットあるいは他のネットワークに接続されたエンド・ユーザ・プロセッサ６０２−１，６０２−２，６０２−ｍ（総称して６０２と称する）によって保護コンテンツにアクセスする。

一般的に、グローバル・キャッシュ・サーバ９０２は、ストリーミング・メディア・サーバ６０４への各エンド・ユーザの接続に関する接続情報をキャッシュし、エンド・ユーザＩＤに基づいて、更に高レベルの認証保護を提供する。接続情報は、キャッシュまたはデータベースのようなローカルのデータ記憶装置、またはデータベース６０８のような遠隔の記憶装置に格納される。以下詳細に記述されるように、各ストリーミング・メディア・サーバ６０４は、該ストリーミング・メディア・サーバ６０４を認証した各エンド・ユーザのアクセスに対して、接続情報をグローバル・キャッシュ・サーバ９０２へ転送する。本実施形態において、接続情報は、エンド・ユーザＩＤ、エンド・ユーザのメディア・プレーヤーのグローバル一意識別子（ＧＵＩＤ）、エンド・ユーザがアクセスを許可されたストリーミング・コンテンツのフォーマット（例えば、ウインドウズ・メディアもしくはリアルプレーヤー・フォーマット）、エンド・ユーザによってアクセスされているコンテンツが存在するサーバのＩＤ、および、エンド・ユーザがリクエストを発信し、コンテンツにアクセスする際に用いる特定のエンド・ユーザ・プロセッサ６０２の識別子（“ｐｐｖスロット”と称する）を含む。周知のように、メディア・プレーヤーの供給業者は、メディア・プレーヤーを識別するために通常は各メディア・プレーヤーにＧＵＩＤを割り当てる。

各エンド・ユーザは、そのエンド・ユーザがコンテンツにそれらからアクセスすることのできる多数のエンド・ユーザ・プロセッサ６０２に論理的に割り当てられる。本実施例において、各エンド・ユーザが、３つまでの異なるエンド・ユーザ・プロセッサ６０２からコンテンツにアクセスしてもよい。３つの異なるプロセッサは、例えば、エンド・ユーザの家庭用コンピュータ、業務用、またいずれかのモバイル・コンピュータ、ウェブ対応の携帯電話あるいはウェブ対応のパーソナル・デジタル・アシスタント（ＰＤＡ）であって良い。更に、３つのプロセッサ６０２のそれぞれにおいて、エンド・ユーザは複数のメディア・プレーヤーを有しても良く、それぞれのメディア・フォーマットがシステムによってサポートされている。本実施形態において、ウインドウズ・メディアおよびリアルプレーヤー・フォーマットがサポートされる。従って、本実施形態において、各エンド・ユーザは３つまでの異なるｐｐｖスロット値のみを有し得、また、各ｐｐｖスロット値に対して、各メディア・プレーヤーのフォーマット用の２つのＧＵＩＤを有し得る。

本実施形態において、特定のエンド・ユーザ・プロセッサ６０２に対応するｐｐｖスロット値は、そのプロセッサ６０２用のクッキーＩＤである。一般に、クッキーは１セットのデータであり、エンド・ユーザが特定のエンド・ユーザ・プロセッサ６０２によってシステム・ウェブサイトを初めて訪れる時に、ウェブ・サーバ６０６がエンド・ユーザのブラウザに付与するものである。ウェブ・サーバ６０６はクッキーに含まれるエンド・ユーザに関する情報を保存し、エンド・ユーザのブラウザがクッキーを保存する（通常はエンド・ユーザ・プロセッサ６０２のブラウザのシステムフォルダに格納されるテキストファイルとして保存される）。ユーザのプロセッサ６０２（例えばウェブ・ブラウザ）がクッキーを受理しない場合、アプリケーションは、ユーザに対してオプションを変更するように要求するレスポンスを生成する。

本実施形態において、ｐｐｖスロット情報は、データベース６０８中のトランザクション・テーブルに格納される。一般的に、トランザクション・テーブルは、特定のストリーミング・メディアのイベントおよび該イベントに対する３つのｐｐｖスロットにエンド・ユーザを関連付ける。この目的のために、トランザクション・テーブルは、エンド・ユーザＩＤ、所定のメディアのイベントを個別に識別するイベントＩＤ、ストリームＩＤ、エンド・ユーザのイベントに対するアクセスの日付、第１のｐｐｖスロット値、第１のｐｐｖスロットのＧＵＩＤ、第２のｐｐｖスロット値、第２のｐｐｖスロットのＧＵＩＤ、第３のｐｐｖスロット値、および第３のｐｐｖスロット値のＧＵＩＤのフィールドを含む。本記述に基づいて、エンド・ユーザおよびｐｐｖスロット情報と、特定のイベントとを関連付ける事によって、１つのイベントに対して、各エンド・ユーザに対するエンド・ユーザ・プロセッサ６０２の数を３つ以内に制限することが可能となり、一方、トランザクション・データベースが単にエンド・ユーザとｐｐｖ−スロット情報（イベントごとの情報ではなく、全てのイベントに渡る情報）とを関連付けるような他の実施形態においては、各エンド・ユーザに対するエンド・ユーザ・プロセッサ６０２の数を全てのイベントにわたって３つ以内に制限することが可能となる、と言う事が理解されよう。

以下詳細に記述されるように、ビジネス・サーバ９０４はグローバル・キャッシュ・サーバ９０２からｐｐｖスロット値を含む接続情報の一部または全部を受信する。グローバル・キャッシュ・サーバ９０２と同様、ビジネス・サーバ９０４はローカルまたはリモートのデータ格納装置を備え、個々の接続情報ごとに、別々のレコードをデータベース中に格納する。接続情報に基づいて、ビジネス・サーバ９０４上に存在する認証アプリケーションはエンド・ユーザがアクセスするエンド・ユーザ・プロセッサ６０２の数を３つ以下に制限し、各エンド・ユーザ・プロセッサ６０２に対して、メディア・プレーヤーの数を１つに制限する。許可されるエンド・ユーザ・プロセッサ６０２の数（したがってｐｐｖスロット値の数）は、ビジネス・サーバ９０４の認証アプリケーションにおいて調整可能である。

本実施形態を参照して説明されているところの更に高レベルの保護は、先の実施形態の認証システムおよび方法と連動して利用されてもよいし、一方、本実施形態に関連して説明される１つ以上のあらゆる前記付加的保護は、前記唯一の認証メカニズムとして実施されても良いし、先述したもの以外の認証メカニズムと共に実施されても良い、と言う事が理解されよう。従って、例示として、さらに高レベルの保護を、図１０のワークフロー図を参照して、以下に説明する。

先ず、ウェブ・サーバ６０６は、サービスの登録手続と認証アプリケーションにログインすることをエンド・ユーザに要求するウェブ・ページをエンド・ユーザに提供する。更に、ウェブ・ページは、それぞれが別個のストリーミング・リクエスト・リンクを有する多くのストリーミング・メディア・ファイルのうちの１つを視聴する選択肢をエンド・ユーザに提示する（ステップ１００２）。これを受けて、エンド・ユーザはエンド・ユーザのユーザＩＤを提供し、所望のストリーム・リクエスト・リンクをウェブ・ページ上で起動し、これによって、特定のストリーミング・メディア・コンテンツ・ファイルへのアクセスをリクエストする。エンド・ユーザは、さらにクレジットカード番号のような支払い情報あるいは他のアカウント情報を提供してもよい。先の実施形態と同様に、エンド・ユーザＩＤの提供およびストリーム・リクエスト・リンクの起動は、単一のステップとして、あるいは個々の複数のステップとして実行してもよい。エンド・ユーザがログインする場合、ウェブ・サーバ６０６上で実行されるＪａｖａスクリプトあるいは他のソフトウェア・スクリプトまたはコンポーネントのような認証アプリケーションは、過去にシステムにログインした事のあるエンド・ユーザを示すｐｐｖスロットクッキーが存在するかどうか、エンド・ユーザ・プロセッサ６０２をチェックする。クッキーが存在しない場合、ウェブ・サーバ６０６は特定のエンド・ユーザ・プロセッサ６０２にクッキーを帰し、エンド・ユーザ・プロセッサ６０２上にそれを格納し、それによって、プロセッサ６０２を識別する。ストリーム・リクエスト・リンクを起動することによって、ストリーム・リクエスト・リンクおよびエンド・ユーザＩＤがウェブ・サーバ６０６に伝達される（ステップ１００４）。

エンド・ユーザがシステムにログインし、コンテンツへのアクセスをリクエストすると、ウェブ・サーバ６０６の認証アプリケーションは、エンド・ユーザが３つの割り当てられたｐｐｖスロット数を超過しているかどうかを判断し、超過していない場合、トランザクション・テーブルを更新する（ステップ１０１０ａ）。この点において、ウェブ・サーバ６０６は、エンド・ユーザがシステムにログインした際の、特定のエンド・ユーザに対するトランザクション・テーブル中の全てのｐｐｖスロット値に割り当てられたクッキーＩＤ（エンド・ユーザＩＤによって認識される）と、イベント（イベントＩＤによって認識される）とを比較する。トランザクション・テーブルが既に３つのｐｐｖスロット値を含んでおり、受信されるクッキーＩＤが、既存の３つのｐｐｖスロット値のうちのどれとも一致しない場合、エンド・ユーザが非認定アクセスを４番目のプロセッサ６０２から試みていると見做され、そのアクセスは拒否される。

トランザクション・テーブルが、イベントに対するエンド・ユーザのｐｐｖスロット値が３未満の場合、ウェブ・サーバ６０６はトランザクション・テーブル中にレコードを作成する。より具体的には、ウェブ・サーバ６０６はエンド・ユーザＩＤ、イベントＩＤ（以前にエンド・ユーザによって購入されたコンテンツに割り当てられたもの）、購入されたコンテンツのストリームＩＤ（ストリーム・リクエスト・リンクの再生リストＩＤに対応するものとして、ウェブ・サーバ６０６がデータベース６０８から検索したもの）、日付およびｐｐｖスロット値を使用して、レコードを作成する。

ｐｐｖスロット情報に基づいてエンド・ユーザのアクセスが拒否されない場合は、ストリーム・リクエスト・リンクおよびエンド・ユーザＩＤを受信した後、ウェブ・サーバ６０６上で実行される認証アプリケーションは、データベース６０８にアクセスし（ステップ１００６）、データベース６０８からプライベート・キー情報を得て（ステップ１００８）、チケットを生成し、ストリーム・リクエスト・リンクにチケット、エンド・ユーザＩＤおよびｐｐｖスロット値をアペンドする（ステップ１０１０ｂ）。その後、ウェブ・サーバ６０６上で実行される認証アプリケーションは、アペンドされたチケット、エンド・ユーザＩＤおよびｐｐｖスロット値を含むストリーム・リクエスト・リンクを再生リスト・サーバ６１０へ転送する（ステップ１０１２）。

再生リスト・サーバ６１０がストリーム・リクエスト・リンク、チケット、エンド・ユーザＩＤおよびｐｐｖスロット値を一旦受信すると、再生リスト・サーバ６１０はリダイレクター・ファイルを生成するステップへと進む。上述されたように、リダイレクター・ファイルを生成するために、再生リスト・サーバ６１０はデータベース６０８にアクセスし（ステップ１０１４）、再生リストを含むコンテンツ・ファイルのストリームＩＤおよび該ストリームＩＤに関連するホスト名、ＵＲＬ接頭部およびファイル名を検索する（ステップ１０１６）。この情報をもとに、再生リスト・サーバ６１０はリダイレクター・ファイルを作成する（ステップ１０１８）。その後、再生リスト・サーバ６１０は、ＧＵＩＤによって識別されるエンド・ユーザ・プロセッサ６０２の特定のメディア・プレーヤーへリダイレクター・ファイルを転送する（ステップ１０２０）。本実施形態における典型的なリダイレクター・ファイル、ＵＲＬプレフィックスを以下に示す。

ここで、ＵＲＬプレフィックスは“mms://”で表され、適切なメディア・サーバ６０４のホスト名は“mediaserver.company.com”で表され、ファイル名は“stream1.asf”で表され、リクエストされたコンテンツ・ストリームＩＤは“123456”で表され、チケットは“uvw123xyz”で表され、エンド・ユーザＩＤは“abc123def”で表され、ｐｐｖ−スロット値は“1”で表される。

リダイレクター・ファイルを受信した後、エンド・ユーザ・プロセッサ６０２上のメディア・プレーヤーは適切なストリーミング・メディア・サーバ６０４にストリーミング・メディア・コンテンツをリクエストするステップへと進む（ステップ１０２２）。より具体的には、メディア・プレーヤーは、リダイレクター・ファイル中に識別される特定のストリーミング・メディア・サーバ６０４を呼び出す。呼出がなされた場合、メディア・プレーヤーは、リクエストされたコンテンツのストリームＩＤのコピー、ウェブ・サーバ６０６によって生成されたチケット（ステップ１０１０）、エンド・ユーザＩＤおよびｐｐｖスロット値をストリーミング・メディア・サーバに６０４を供給する。更に、メディア・プレーヤーは、自身のＧＵＩＤをストリーミング・メディア・サーバへ転送する。

エンド・ユーザ・プロセス６０２からオリジナルのストリーム・リクエストおよびログイン情報を受け取る場合、ストリーミング・メディア・サーバ６０４上で実行されるアプリケーションはメディア・プレーヤーがＧＵＩＤを転送したかどうか（あるいは無効のデフォルト値を転送したか）を判断する。もし転送していなかった場合、アプリケーションは認証プロセスを停止することによりエンド・ユーザのアクセスを拒否し、エンド・ユーザに通知する。エンド・ユーザのメディア・プレーヤーがＧＵＩＤを提供しなかったという事実は、データベース６０８、あるいは他のデータ記憶装置に格納され、今度そのエンド・ユーザがシステムにログインする時に、エンド・ユーザにＧＵＩＤを送信可能にするべき方法についての指示をシステムが提供する事が好ましい。

図６〜８の実施形態において、ストリーミング・メディア・サーバ６０４がメディア・プレーヤーからの呼び出しを一旦受けると、ストリーミング・メディア・サーバ６０４は個別に１以上の認証チケットを生成し、１つ以上のチケットをメディア・プレーヤーから受信してチケットと比較する（ステップ１０２４）。これらのチケットが一致した場合、ストリーミング・メディア・サーバ６０４はコンテンツへのアクセスの許可を与えて、エンド・ユーザへコンテンツを配信する（ステップ１０２６）。

ストリーミング・サーバ６０４がエンド・ユーザにコンテンツへのアクセスを許可する毎に、ストリーミング・メディア・サーバ６０４は、該接続を識別する情報をグローバル・キャッシュ・サーバ９０２に送信する（ステップ１０２８）。上述したように、このような接続情報は、エンド・ユーザＩＤ、ストリーミング・コンテンツのフォーマット（例えばウインドウズ・メディアあるいはリアルプレーヤー）、エンド・ユーザにコンテンツを供給するストリーミング・メディア・サーバ６０４のサーバＩＤ、エンド・ユーザのメディア・プレーヤーのＧＵＩＤ、および、エンド・ユーザがシステムにログインするのに用いる特定のエンド・ユーザ・プロセッサ６０２を表わすｐｐｖスロット値を含む事が好ましい。

ストリーミング・サーバ６０４がエンド・ユーザにコンテンツへのアクセスを許可する毎に、ストリーミング・メディア・サーバ６０４はさらにローカルにストリーム名またはストリームＩＤ、エンド・ユーザＩＤ、およびリクエストに関する接続情報をキャッシュする。ストリーム接続が終了する場合はいつでも、ストリーミング・メディア・サーバ６０４は、キャッシュ中の対応するエントリーを削除する。そのため、キャッシュ中の全てのエントリーはその時点におけるストリーミングあるいはアクセスを表わす。ソフトウエア・コンポーネントやオブジェクトのような、ストリーミング・メディア・サーバ６０４上で実行されるポーリングサービスを利用して、メディア・サーバ６０４は、周期的に（例えば２分毎に）エントリー毎にキャッシュをポーリングする。エントリー毎に、ストリーミング・メディア・サーバ６０４が、グローバル・キャッシュ・サーバ９０２へ接続情報を再送する。

上述されるように、グローバル・キャッシュ・サーバ９０２はデータベースまたはキャッシュを備え、各レコード上に受信した接続情報を含んでいる。グローバル・キャッシュ・サーバ９０２が特定のユーザに関する接続情報を得る場合、サーバ９０２は通常はそのデータベース中で新しいレコードを作成する。しかしながら、新しいレコードを作成するに先立って、グローバル・キャッシュ・サーバ９０２は、新たに受信した接続情報と同一のエンド・ユーザＩＤをそのデータベースが有するかどうかを先ず判断する（ステップ１０３０）。

さらに、アクセスが終了する場合、グローバル・キャッシュ・サーバ９０２は、該アクセスのレコードを削除する。上述されるように、各ストリーミング・メディア・サーバ６０４は、接続情報によって識別されるアクセスの期間中に、所定の間隔でグローバル・キャッシュ・サーバ９０２に接続情報の各セットを再送する。グローバル・キャッシュ・サーバ９０２は、接続情報が再送されなかったレコードを周期的に削除し、その時点においてアクセスが存在するレコードのみが保持されるようにする。他の実施形態においては、グローバル・キャッシュ・サーバは、これとは異なった方法で、もはや使用されていない接続に関するレコードを削除しても良い。例えば、他の実施形態において、グローバル・キャッシュ・サーバ９０２が特定の接続が終了したことを示す終了メッセージをストリーミング・メディア・サーバから受信するまで、グローバル・キャッシュ・サーバ９０２が特定の接続に関するレコードを保持する。つまり、グローバル・キャッシュ・サーバのデータベース中のレコードが存在すると言うことは、エンド・ユーザＩＤによって識別される特定のエンド・ユーザがコンテンツ・ファイルにその時点においてアクセスしている、と言うことを示す。

グローバル・キャッシュ・サーバ９０２が、受信したエンド・ユーザＩＤと同一のエンド・ユーザＩＤを伴うレコードを既に有する場合、エンド・ユーザ（あるいはアクセス情報を取得した非認定ユーザ）は、複数のコンテンツ・ファイルに同時にアクセスすること、または同一コンテンツ・ファイルに２回以上アクセスする事を試みている。本実施形態において、このようなマルチプルアクセスは許可されない。従って、グローバル・キャッシュ・サーバ９０２は、新たに受信された接続情報の送信元であるメディア・サーバと、既存のデータベースレコード中のサーバＩＤによって識別されるメディア・サーバの双方に、エンド・ユーザのアクセスを終了させる要求を発行する。ストリーミング・メディア・サーバ６０４にエンド・ユーザからの接続を切断させる際、特定のエンド・ユーザに関するレコードをデータベースより削除する。

ここに述べた更に高レベルの許可保護は任意のものであり、また、異なる方式で実施されても良い、と言う事が理解されよう。例えば、他の実施形態におけるサーバは、ユーザがマルチプルアクセスを試みているかどうかを判断するために、グローバル・キャッシュ・サーバ９０２を照会しても良い。そのような実施形態において、再生リスト・サーバ６１０がリクエスト・リンク、チケットおよびエンド・ユーザＩＤをウェブ・サーバ６０６から受信した後、再生リスト・サーバ６１０は、グローバル・キャッシュ・サーバ９０２が既にコンテンツにアクセスしたエンド・ユーザのレコードを有するかどうかを判断するために、グローバル・キャッシュ・サーバ９０２を呼び出す（ステップ１０１８ａ）。グローバル・キャッシュ・サーバ９０２は、エンド・ユーザがその時点においてコンテンツにアクセスしているかどうかに関する表示を用いて再生リスト・サーバ６１０に回答する（ステップ１０１８ｂ）。これを受けて、再生リスト・サーバ６１０上で実行される認証アプリケーションは偽または無効リダイレクター・ファイルを生成する。このような実施形態において、リダイレクター・ファイルは、チケットの不足あるいはストリーミング・メディア・サーバ６０４によって検知されるデフォルト・チケットが含まれているので、無効である。

グローバル・キャッシュ・サーバ９０２が、受信された新たな接続情報に含まれるエンド・ユーザＩＤと同一のエンド・ユーザＩＤを有するデータベース中にレコードの存在を認めなかった場合は、グローバル・キャッシュ・サーバ９０２は、受信した接続情報を用いてデータベース中に新たなレコードを作成し、エンド・ユーザがコンテンツにアクセスする事を妨げない。

グローバル・キャッシュ・サーバ９０２がエンド・ユーザの接続を切断しない場合は、サーバ９０２はビジネス・サーバ９０４へ接続情報の一部または全部を中継する。ビジネス・サーバ９０４は、任意の２個の更に高レベルの許可保護を有効にする（ステップ１０３４）。本実施形態において、グローバル・キャッシュ・サーバ９０２は、エンド・ユーザＩＤ、ｐｐｖスロット、ＧＵＩＤおよびストリーム・フォーマットをビジネス・サーバ９０４へ中継する。

ビジネス・サーバ９０４は、メディア・プレーヤーのＧＵＩＤに一部基づいてコンテンツに対するアクセスを管理するために、グローバル・キャッシュ・サーバ９０２から受信した該接続情報を使用する（ステップ１０３６）。上述されたように、各エンド・ユーザは、３つの異なるユーザ・プロセッサ６０２からシステムにログインし、コンテンツにアクセスする事が許可される。ユーザ・プロセッサ６０２のそれぞれは、各フォーマットに対して１つのみのメディア・プレーヤーを有する。従って、ｐｐｖスロットによって識別される特定のエンド・ユーザ・プロセッサ６０２から、特定のメディア・フォーマット用のＧＵＩＤによって識別される特定のメディア・プレーヤーを用いてエンド・ユーザがアクセスをリクエストし、該メディアプレーヤーが、同一のフォーマットのメディアに対して同一のエンド・ユーザ・プロセッサ６０２上で以前用いられていたメディア・プレーヤーと異なる場合、ビジネス・サーバ９０４はエンド・ユーザの接続を切断させる。一般的に、この決定は、トランザクション・テーブルにアクセスし、新たに受信される接続情報をエンド・ユーザおよびｐｐｖスロット値に対する既存のエントリーと比較することによりなされる。

ビジネス・サーバ６０４が所定のエンド・ユーザおよびｐｐｖスロットに対する接続情報を得る場合、ビジネス・サーバ９０４は、該エンド・ユーザ、ｐｐｖスロットおよびフォーマットに関して既にＧＵＩＤが受信されたかどうかを判断するためにトランザクション・テーブルにアクセスする。もし受信されていなければ、トランザクション・テーブルは、ＧＵＩＤを反映するためにビジネス・サーバ９０４によって更新される。また、ビジネス・サーバ９０４は、エンド・ユーザのアクセスを終了させない。

受信した接続情報が、ＧＵＩＤが既に受信されているトランザクション・テーブル中のレコードに対応する場合、ビジネス・サーバ９０４は、受信されたＧＵＩＤが、ｐｐｖスロットに関して格納された特定のメディア・フォーマット用のＧＵＩＤと一致するかどうかを判断する。ＧＵＩＤが一致しない場合、ビジネス・サーバ９０４は、エンド・ユーザの保護コンテンツへのアクセスを終了させる旨の指示をグローバル・キャッシュ・サーバ９０２に送信し、エンド・ユーザのアクセスが拒否される。このような指示は、エンド・ユーザＩＤを指定する事が好ましい（ステップ１０３８）。次に、グローバル・キャッシュ・サーバ９０２は、エンド・ユーザにコンテンツをその時点において供給している１つ以上のストリーミング・メディア・サーバ６０４へのリクエストを発行する。

そのため、たとえエンド・ユーザがコンテンツへのアクセスを一時的に許可されたとしても、本実施形態は無許可のエンド・ユーザに対してアクセスを拒否する、と考えられるべきである。グローバル・キャッシュ・サーバ９０２およびビジネス・サーバ９０４における処理に起因してアクセスの提供に遅延が生じることを防ぐ事が望ましいので、本実施形態においては、このような一時的アクセスが許可される。グローバル・キャッシュ・サーバ９０２およびビジネス・サーバ９０４の処理に起因してアクセスが遅延するような例において、エンド・ユーザのメディア・プレーヤーは時間切れとなり得、アクセスが許可されるのを妨げられる。従って、本実施形態のメディア・サーバ６０４は、チケットの一致によってアクセスを許可し、メディア・プレーヤーが時間切れになる事を防止し、それから、グローバル・キャッシュ・サーバ９０２あるいはビジネス・サーバ９０４によってアクセスが不適当であると判断された場合に、このようなアクセスが終了する。

ビジネス・サーバ９０４が、新たに受信したメディア・プレーヤーのＧＵＩＤとｐｐｖスロットおよびフォーマットに関してメモリに格納したＧＵＩＤとが一致すると判断した場合、ビジネス・サーバ９０４は何も行わず、エンド・ユーザのアクセスが継続することを許可する。

単一のグローバル・キャッシュ・サーバ９０２がシステム中の全てのストリーミング・メディア・サーバ９０４から接続情報を取得する事が望ましい一方、複数のグローバル・キャッシュ・サーバを含み得、そのそれぞれがメディア・サーバの部分集合から接続情報を取得する事が可能である、と言う事が理解されるべきである。しかしながら、そのような実施形態においては、複数のグローバル・キャッシュ・サーバは相互に通信可能な状態にある。

更に、グローバル・キャッシュ・サーバ９０２およびビジネス・サーバ９０４の機能性は、一実施形態中においては１つのサーバへ組み合わせられていても良い一方で、２つの別個のサーバを使用する事によって、スケーラビリティを有する等の幾つかの利点がある。例えば、認証システムが複数のコンテンツ所有者のアカウントに対して利用される場合、各アカウントは個別の許可ルールをそれぞれ適用し得、それぞれのルールは、グローバル・キャッシュ・サーバへのアクセスを有する個別のビジネス・サーバ上に存在する。このような実施形態において、既存の接続情報に基づいて、またはアカウントＩＤのような接続情報に含まれる付加的なフィールドに基づいて、適切なビジネス・サーバへ接続情報を送信する事が出来る。

本実施形態において、システムは、各エンド・ユーザにエンド・ユーザのｐｐｖスロット情報（ｐｐｖスロット値およびＧＵＩＤを含む）を再登録および削除する機会を提供し、これによって、エンド・ユーザが、異なる機器および（または）メディア・プレーヤーからコンテンツにアクセスすることを可能にする。

先の実施形態はセキュリティ・キーとセキュリティ・インターバルの両方を含むプライベート・キーを利用するが、プライベート・キーとしてそれ以上、またはそれ以下の情報を利用するのも、本発明の範囲内である事が理解されよう。例えば、他の実施形態においてはセキュリティ・キーが使用されない。また、他の実施形態においては、例えばクライアントのユーザ名およびパスワードを含む補足情報が、プライベート・キーに含まれる。同様に、ストリームＩＤおよびエンド・ユーザＩＤ以外の情報を含む公開暗号キーを利用する事も、本発明の範囲内である。例えばファイル・パス名の様な、情報を識別する他のコンテンツ・ファイル識別情報が使用されてもよい。さらに、ある実施形態においては、エンド・ユーザＩＤが公開暗号キー情報から省略されてもよい。更に他の実施形態において、公開暗号キー情報は、他のリクエスト・コンテンツ・ファイルのタイトルあるいはストリーミング詳細のような補足情報を含んでいる。

ウェブ・サーバおよびストリーミング・メディア・サーバによって提供されると記載された機能性が、それに関連する他のデバイス上において実施され得るということが理解されよう。例えば、本発明の一実施形態において、ストリーミング・メディア・サーバが、それに接続される関連するアプリケーション・サーバを備え、アプリケーション・サーバは、コンテンツに対するアクセスを拒否または許可するプロセスの全部または一部を実施する。同様に、例えば認証チケットを生成する過程を含むウェブ・サーバの機能性のうちの一部または全部を提供するためにウェブ・サーバとアプリケーションサーバとを関連付ける事は、本発明の範囲内である。このように、特定のサーバに対する言及は、言及されたサーバと接続される他の関連するサーバあるいはプロセッサをも含む、という事を意味する。

さらに、認証チケットを正確な時刻に生成する必要は無い、と言う事が理解されよう。例えば、ウェブ・サーバによって生成されるチケットは、エンド・ユーザがストリーム・リクエスト・リンクを起動した時刻に基づいても良いし、ウェブ・サーバがデータベースからプライベート・キー情報を得た時刻に基づいても良いし、ストリーミング・リクエストの起動時間に近接した任意の時刻に基づいても良い。同様に、メディア・サーバが許可を生成する時刻は、例えば、メディア・プレーヤーからの呼出がなされた時でも良いし、プライベート・キー情報が検索された後でも良いし、ストリーミング・リクエストの起動時間に近接した任意の時刻であっても良い。更に、メディア・サーバが複数のチケットを生成する際、チケットは異なる複数の時刻に基づいて生成されても良いし、単一の時刻に基づいて生成されても良い。従って、時刻または現在時刻に対する参照は、ある一定の範囲の参照を意味するものであり、正確な時刻の参照を意味するものではない。

先の典型的な実施形態は、単一のコンテンツに対するアクセスを管理すると言うコンテキストで記載されたが、先の実施形態が複数の保護コンテンツ・ファイルを含む再生リストへのアクセスを管理するために用いられ得るという事を当業者は理解するであろう。再生リストへのアクセスを管理するための典型的な一実施形態を、図６から８を参照して次に説明する。このような実施形態は、下記の変更を伴った上で、前述に従って作動する。一般的に、ウェブ・サーバ６０６は、各ストリームのストリームＩＤに基づいて、再生リストに含まれる各コンテンツ・ストリームのチケットを生成する。

エンド・ユーザ・プロセッサ６０２のメディア・プレーヤーは、再生リストＩＤを含むストリーム・リクエストを再生リストプロセッサ６１０へ転送する。次に、再生リストプロセッサ６１０はリダイレクター・ファイルを生成し、メディア・プレーヤーにリダイレクター・ファイルを返送する。本実施例において、オブジェクト“makeplaylist.dll”は、適切なリダイレクター・ファイルを構築するために再生リストＩＤ“789000”を使用する。より詳細には、どのコンテンツがリクエストされた再生リストの一部を構成するのかを判断するため、および再生リスト中のコンテンツ・ファイルの順番を判断するために、再生リスト・サーバ６１０は、再生リスト・テーブル７０８および再生リスト・ストリーム・テーブル７１０にアクセスする。コンテンツ・ファイルのファイル名はストリーム・テーブル７０４から検索される。続いて、エンド・ユーザ・プロセッサ６０２上で実行されるスクリプトは、対応するコンテンツ・ストリームへリンクするＵＲＬにストリームＩＤ、チケットおよびエンド・ユーザＩＤをアペンドする。本実施形態において、ストリーム・サーバ・テーブル７１２中から識別されるように、全てのコンテンツ・ストリームは同一のメディア・サーバ６０４に格納される。

対応するコンテンツ・ストリームのためのＵＲＬリンクにアペンドされたストリームＩＤ、チケットおよびエンド・ユーザＩＤを含むＡＳＸリダイレクター・ファイルの例を以下に示す。

前記メディア・プレーヤーは、その後、ストリーミング・メディア・サーバ６０４を連続して呼び出し、各呼び出しに対する各ＵＲＬリンクがリダイレクター・ファイルに含まれている。より具体的には、メディア・プレーヤーは先ず、第１のコンテンツ・ストリーム（本例において、ストリームＩＤ“123456”を有する）にアクセスするためにメディア・サーバ６０４を呼び出す。呼び出しに応答して、また、先に図５を参照して概説したように、メディア・サーバ６０４は個々にチケットを生成し、コンテンツへのアクセスを許可するべきかどうかを判断する。アクセスが許可されない場合、エンド・ユーザにその旨が通知される。一方、メディア・サーバがエンド・ユーザに対して第１のコンテンツ・ストリームへのアクセスを許可する場合、メディア・プレーヤーは、再生リスト中の残りのコンテンツ・ストリーム用のメディア・サーバ６０４を呼び出すステップへと進む。それぞれの呼び出しで、メディア・サーバ６０４はリクエストされたコンテンツへのアクセスを許可するか拒否するかのステップへと進む。

しかしながら、このような実施形態において、各々のコンテンツ・ストリーミングが、再生リスト中のストリーミングに先立って再生されるコンテンツ・ストリーミングの所要時間の合計を計上した長さの個々のセキュリティ・インターバルを有することが望ましい、と言う事が理解されるべきである。例えば、それぞれが５分の所要時間を有する（ストリーム・テーブル７０４のストリーム詳細フィールドに示される）３つのコンテンツ・ストリーミングを含む再生リスト中で、第２のストリームのセキュリティ・インターバルは、第１のストリームのセキュリティ・インターバルよりも５分間だけ長くても良く、第３のストリームのセキュリティ・インターバルは、第１のストリームのセキュリティ・インターバルよりも１０分間だけ長くても良い。再生リスト中の各ストリームの所要時間を計上する事によって、システムは、許可されたエンド・ユーザが、再生リスト中の第１のコンテンツ・ストリームへのアクセスを許可されるが、チケットが有効期限切れになったという理由によって、後続のコンテンツ・ストリーミングに対するアクセスが許可されない、という事を防止する。更に、セキュリティ・インターバルは、再生リストに含まれる広告のような任意の非保護コンテンツの所要時間を計上しても良い。

更に他の実施形態は、再生リストＩＤに基づいてチケットを生成することにより、複数の保護コンテンツ・ストリームを含む再生リストへのアクセスを管理する。このような実施形態は、下記の変更を伴った上で、図６〜８の前記システムの記述に従って作動する。一般的に、一旦エンド・ユーザが認証アプリケーションにログインし、再生リストへのアクセスをリクエストすれば、ウェブ・サーバ６０６は、再生リストＩＤに基づいてチケットを生成し、エンド・ユーザ・プロセッサ６０２にチケットを返送する。これを受けて、エンド・ユーザ・プロセッサ６０２上で実行されるスクリプトは、ストリーム・リクエスト・リンクにチケットおよびエンド・ユーザＩＤをアペンドする。公開暗号キー情報がアペンドされたストリーミング・リクエスト・リンクの例を以下に示す。

ここで、再生リストＩＤは“789000”で表され、チケットは“xyz321abc”で表され、エンド・ユーザＩＤは“abc123def”で表される。

エンド・ユーザ・プロセッサ６０２は、“playlistserver.company.com”と言う名称によって識別される再生リスト・サーバ６１０を呼び出す。次に、再生リスト・サーバ６１０は、リダイレクター・ファイルを生成するために再生リスト・サーバ６１０に存在する“makeplaylist.dll”オブジェクトを始動する。本実施形態において、コンテンツ・ストリーミングはすべて同一のメディア・サーバ６０４上に存在する。先の実施形態と異なり、“makeplaylists.dll”オブジェクトは、リダイレクター・ファイル中の第１のＵＲＬの端部に、再生リスト中の後続する保護コンテンツ・ストリームのファイル名をアペンドし、それぞれの後続のＵＲＬリンクには、再生リストＩＤおよびチケットのみがアペンドされる。ＡＳＸリダイレクター・ファイルの例を以下に示す。

ここで、再生リストは、“stream1.asf”、“stream2.asf”、“stream3.asf”と名前の付けられた３つのウィンドウズ・メディア・フォーマット（ウィンドウズは登録商標）のコンテンツ・ファイルを含み、再生リストＩＤは“789000”で表され、エンド・ユーザＩＤは“abc123def”で表され、チケットは“xyz321abc”で表される。

エンド・ユーザ・プロセッサ６０２のメディア・プレーヤーは、第１のコンテンツ・ファイルにアクセスするために、mediaserver.company.com（即ち、ストリーミング・メディア・サーバ６０４のホスト名）を呼び出すステップへ進む。メディア・サーバ６０４は、図５を参照して上述されたように、再生リストＩＤに基づいてチケットを生成し、アクセスを許可または拒否するステップへと進む。メディア・サーバ６０４がアクセスを許可し、メディア・プレーヤーに再生リスト中の第１のコンテンツ・ファイルを提供する場合、メディア・サーバ６０４は、再生リストＩＤおよび対応するチケットのためにローカルに格納されたテーブル中にレコードを作成し、リダイレクター・ファイルに含まれている再生リスト中の後続するコンテンツ・ストリームのファイル名をレコード中に格納する。

メディア・プレーヤーが第２のコンテンツ・ストリームへのアクセスを要求する場合、メディア・プレーヤーはメディア・サーバ６０４に再生リストＩＤおよびチケットを供給する。次に、メディア・サーバ６０４は、再生リストＩＤおよびチケットによって識別されたレコードを、テーブル中から検索する。レコードが存在する場合、メディア・サーバ６０４は第２のストリーミングへのアクセスを許可し、特定のチケットを有するエンド・ユーザによって視聴された旨、ストリーミングにフラグを立てる。非認定のエンド・ユーザが同じＵＲＬリンクを使用して第２のストリームにアクセスすることを試みる場合、再生リストＩＤおよびチケットに関するレコードにおいて、上述したように第２のストリームが視聴された旨を示すフラグが立っているので、メディア・サーバ６０４はアクセスを拒否する。同様のプロセスが、再生リスト中の残りのコンテンツ・ストリームへのアクセスを許可するために利用される。当業者によって認められるように、本実施形態は、第１のストリームへのアクセス許可と、後続のストリームとの間の時間遅延に起因して再生リスト中の後続のストリームへのアクセスが不適切に拒否されるような如何なる可能性をも回避する。

当業者は、本発明の方法およびシステムが多数の応用を有し、多数の方法において実施され得、従って、以上記載された典型的な実施形態および実施例によって制限されないという事を認めるであろう。さらに、当業者によって理解されるように、本発明の範囲には、本願明細書に記載されているシステム構成部分に対する従来公知の、および将来開発される変更および修正が含まれる。

以上説明したように、本発明によれば、デジタル・コンテンツ、具体的にはストリーミング・メディア・コンテンツへのアクセスを管理し、エンド・ユーザを認定するための改善された、コンピュータを用いた方法、コンピュータ可読メディア、およびシステムを、提供することができる。

本発明の一実施形態におけるシステムを示す略図である。 本発明の一実施形態におけるデータベース示す略図である。 本発明の一実施形態におけるワークフローを示す図である。 本発明の一実施形態におけるチケットを生成するプロセスを示すフローチャートである。 本発明の一実施例における、ストリーミング・メディア・コンテンツのアイテムを供給するべきかどうかを判断するプロセスを示すフローチャートである。 本発明の他の実施形態におけるシステムを示す略図である。 本発明の他の実施形態におけるデータベースを示す略図である。 本発明の他の実施形態におけるワークフローを示す略図である。 本発明の他の実施形態におけるシステムを示す略図である。 本発明の他の実施形態におけるワークフローを示す略図である。

Claims (12)

1. 複数のエンド・ユーザの内の１つのエンド・ユーザが１以上のエンド・ユーザ・プロセッサから１以上のメディア・ファイルへのアクセスを試みる前記１以上のメディア・ファイルへのアクセスを管理する、コンピュータを用いた方法であって、
   （ａ）少なくとも一つのサーバ・プロセッサにおいて、前記１つのエンド・ユーザによる前記１以上のメディア・ファイルへのアクセスが許可されるエンド・ユーザ・プロセッサの許容数を設定するステップ；
   （ｂ）前記少なくとも一つのサーバ・プロセッサにおいて、１以上のリクエストのそれぞれが、前記１以上のエンド・ユーザ・プロセッサのうちの１つによって要求され、前記１以上のメディア・ファイルのうちの１つにアクセスするために、前記１つのエンド・ユーザからの前記１以上のリクエストを受信するステップ；
   （ｃ）前記少なくとも一つのサーバ・プロセッサにおいて、さらに、前記１つのエンド・ユーザのために、リクエストがなされる各エンド・ユーザ・プロセッサの識別子を、前記１つのエンド・ユーザに対する識別子の数が前記１つのエンド・ユーザのための前記エンド・ユーザ・プロセッサの許容数と同じになるまで、格納するステップ；
   （ｄ）前記少なくとも一つのサーバ・プロセッサにおいて、受信したリクエストの要求元である前記エンド・ユーザ・プロセッサの識別子が、前記１つのエンド・ユーザに対する格納されたエンド・ユーザ・プロセッサの識別子と一致する場合に、前記１つのエンド・ユーザのために受信したリクエストを許可するステップ；および
   （ｅ）前記少なくとも一つのサーバ・プロセッサにおいて、前記受信されたリクエストの要求元である前記エンド・ユーザ・プロセッサの前記識別子が、前記１つのエンド・ユーザに対する格納された前記エンド・ユーザ・プロセッサの識別子と一致しない場合に、前記１つのエンド・ユーザのために受信されたリクエストを拒否するステップ；
   を備えることを特徴とするコンピュータを用いた方法。
2. それぞれの許可されたリクエストに対して、
   前記少なくとも一つのサーバ・プロセッサにおいて、前記許可されたリクエストに対する接続情報を記憶するステップであって、前記許可されたリクエストの接続情報は、前記許可されたリクエストのエンド・ユーザ・プロセッサ、メディア・プレーヤー、及びメディア・フォーマットを識別するものであるステップと、
   前記少なくとも一つのサーバ・プロセッサにおいて、前記許可されたリクエストのメディア・プレーヤーが、前記許可されたリクエストのメディア・フォーマットに対する前記許可されたリクエストのエンド・ユーザ・プロセッサで以前に使用されたメディア・プレーヤーと異なる場合に、前記１つのエンド・ユーザの前記メディア・ファイルの１つへのアクセスを終了させるステップと、
   をさらに備えることを特徴とする請求項１に記載のコンピュータを用いた方法。
3. 前記一つ以上のメディア・ファイルが一つ以上のイベントのストリーミング・メディア・コンテンツを含む、請求項１に記載のコンピュータを用いた方法であって、
   前記少なくとも一つのサーバ・プロセッサにおいて、さらに、所与のイベントに対して、前記所与のイベントのストリーミング・コンテンツを含む前記所与のイベントの一つ以上のメディア・ファイルへの前記１つのエンド・ユーザによるアクセスが許容されるところのエンド・ユーザ・プロセッサの数を設定するステップ；
   前記少なくとも一つのサーバ・プロセッサにおいて、格納された各エンド・ユーザ・プロセッサ識別子に対して、該格納されたエンド・ユーザ・プロセッサ識別子に関連づけられるイベントの識別子を格納するステップ；
   を備え、
   前記受信されたリクエストの要求元である前記エンド・ユーザ・プロセッサを識別する前記エンド・ユーザ・プロセッサ識別子が、前記所与のイベントに対して格納されたエンド・ユーザ・プロセッサ識別子に一致するか、あるいは、前記所与のイベントに対して格納されたエンド・ユーザ・プロセッサ識別子の数が、前記エンド・ユーザ・プロセッサ識別子の許容数未満である場合に、前記受信されたリクエストが許可され、
   前記受信されたリクエストの要求元である前記エンド・ユーザ・プロセッサを識別する前記エンド・ユーザ・プロセッサ識別子が、前記所与のイベントに対して格納されたエンド・ユーザ・プロセッサ識別子に一致せず、かつ前記格納されたエンド・ユーザ・プロセッサ識別子の数が、前記所与のイベントに対するエンド・ユーザ・プロセッサ識別子の許容数を超える場合に、前記受信されたリクエストが拒否される、
   ことを特徴とする請求項１に記載のコンピュータを用いた方法。
4. 前記一つ以上のメディア・ファイルが一つ以上のイベントのストリーミング・メディア・コンテンツを含み、そして、前記少なくとも一つのサーバ・プロセッサは、前記一つ以上のメディア・ファイルへの前記１つのエンド・ユーザによるアクセスが許容されるところのエンド・ユーザ・プロセッサの数を、前記一つ以上のイベントにわたるエンド・ユーザ・プロセッサの合計数に設定することを特徴とする請求項１に記載のコンピュータを用いた方法。
5. １以上のエンド・ユーザ・プロセッサから１以上のメディア・ファイルへ複数のエンド・ユーザの内の１つのエンド・ユーザがアクセスを試みることによって、前記１以上のメディア・ファイルへのアクセスを管理するコンピュータ・コードを有するコンピュータ可読メディアであって、前記コンピュータ・コードが少なくとも一つのサーバ・プロセッサに下記指示：
   前記１つのエンド・ユーザによる前記メディア・ファイルへのアクセスの要求元であるエンド・ユーザ・プロセッサの許容数を設定する指示：
   前記エンド・ユーザ・プロセッサから各リクエストがなされ、前記メディア・ファイルの一つへのアクセスを要求する前記１つのエンド・ユーザからの一つ以上のリクエストを受信する指示；
   前記１つのエンド・ユーザのために、リクエストがなされる各エンド・ユーザ・プロセッサの識別子を、前記１つのエンド・ユーザに対する識別子の数が前記１つのエンド・ユーザのための前記エンド・ユーザ・プロセッサの許容数と同じになるまで、格納する指示；
   受信したリクエストの要求元である前記エンド・ユーザ・プロセッサの識別子が、前記１つのエンド・ユーザに対する格納されたエンド・ユーザ・プロセッサの識別子と一致する場合に、前記１つのエンド・ユーザのために受信したリクエストを許可する指示；および
   前記受信されたリクエストの要求元である前記エンド・ユーザ・プロセッサの前記識別子が、前記１つのエンド・ユーザに対する格納されたエンド・ユーザ・プロセッサの識別子と一致しない場合に、前記１つのエンド・ユーザのために受信されたリクエストを拒否する指示；
   を指示するものであることを特徴とするコンピュータ可読メディア。
6. 請求項５に記載のコンピュータ可読メディアであって、
   さらに、前記コンピュータ・コードが前記少なくとも一つのサーバ・プロセッサに下記指示：
   それぞれの許可されたリクエストに対して、
   前記許可されたリクエストに対する接続情報を記憶する指示であって、前記許可されたリクエストの接続情報は、前記許可されたリクエストのエンド・ユーザ・プロセッサ、メディア・プレーヤー、及びメディア・フォーマットを識別するものである指示、
   前記許可されたリクエストのメディア・プレーヤーが、前記許可されたリクエストのメディア・フォーマットに対する前記許可されたリクエストのエンド・ユーザ・プロセッサで以前に使用されたメディア・プレーヤーと異なる場合に、前記１つのエンド・ユーザの前記メディア・ファイルの１つへのアクセスを終了させる指示、
   をさらに備えることを特徴とする請求項５に記載のコンピュータ可読メディア。
7. 前記一つ以上のメディア・ファイルが一つ以上のイベントのストリーミング・メディア・コンテンツを含む、請求項５に記載のコンピュータ可読メディアであって、
   前記コンピュータ・コードが前記少なくとも一つのサーバ・プロセッサにさらに下記指示：
   所与のイベントに対して、前記所与のイベントのストリーミング・コンテンツを含む前記所与のイベントの一つ以上のメディア・ファイルへの前記１つのエンド・ユーザによるアクセスが許容されるところのエンド・ユーザ・プロセッサの数を設定する指示；
   格納された各エンド・ユーザ・プロセッサ識別子に対して、該格納されたエンド・ユーザ・プロセッサ識別子に関連づけられるイベントの識別子を格納する指示；
   を備え、
   前記受信されたリクエストの要求元である前記エンド・ユーザ・プロセッサを識別する前記エンド・ユーザ・プロセッサ識別子が、前記所与のイベントに対して格納されたエンド・ユーザ・プロセッサ識別子に一致するか、あるいは、前記所与のイベントに対して格納されたエンド・ユーザ・プロセッサ識別子の数が、前記エンド・ユーザ・プロセッサ識別子の許容数未満である場合に、前記受信されたリクエストが許可され、
   前記受信されたリクエストの要求元である前記エンド・ユーザ・プロセッサを識別する前記エンド・ユーザ・プロセッサ識別子が、前記所与のイベントに対して格納されたエンド・ユーザ・プロセッサ識別子に一致せず、かつ前記格納されたエンド・ユーザ・プロセッサ識別子の数が、前記所与のイベントに対するエンド・ユーザ・プロセッサ識別子の許容数を超える場合に、前記受信されたリクエストが拒否される、
   ことを特徴とする請求項５に記載のコンピュータ可読メディア。
8. 前記一つ以上のメディア・ファイルが一つ以上のイベントのストリーミング・メディア・コンテンツを含み、前記コンピュータ・コードは、前記少なくとも一つのサーバ・プロセッサが、前記一つ以上のメディア・ファイルへの前記１つのエンド・ユーザによるアクセスが許容されるところのエンド・ユーザ・プロセッサの数を、前記一つ以上のイベントにわたるエンド・ユーザ・プロセッサの合計数に設定することを特徴とする請求項５に記載のコンピュータ可読メディア。
9. １以上のエンド・ユーザ・プロセッサから１以上のメディア・ファイルへ複数のエンド・ユーザの内の１つのエンド・ユーザがアクセスを試みることによって、前記１以上のメディア・ファイルへのアクセスを管理する、少なくとも一つのコンピュータ装置を有するシステムであって、
   前記１つのエンド・ユーザによる前記メディア・ファイルへのアクセスの要求元であるエンド・ユーザ・プロセッサの許容数を設定し；
   前記エンド・ユーザ・プロセッサから前記１つのエンド・ユーザのために各リクエストがなされ、前記メディア・ファイルの一つへのアクセスを要求する前記１つのエンド・ユーザからの一つ以上のリクエストを受信し；
   前記１つのエンド・ユーザのために、リクエストがなされる各エンド・ユーザ・プロセッサの識別子を、前記１つのエンド・ユーザに対する識別子の数が前記１つのエンド・ユーザのための前記エンド・ユーザ・プロセッサの許容数と同じになるまで、格納し；
   受信したリクエストの要求元である前記エンド・ユーザ・プロセッサの識別子が、前記１つのエンド・ユーザに対する格納されたエンド・ユーザ・プロセッサの識別子と一致する場合に、前記１つのエンド・ユーザのために受信したリクエストを許可し；および
   前記受信されたリクエストの要求元である前記エンド・ユーザ・プロセッサの前記識別子が、前記１つのエンド・ユーザに対する格納されたエンド・ユーザ・プロセッサの識別子と一致しない場合に、前記１つのエンド・ユーザのために受信されたリクエストを拒否する；
   ように構築されている少なくとも一つのサーバ・プロセッサを有することを特徴とするシステム。
10. 請求項９に記載のシステムであって、
    前記少なくとも一つのサーバ・プロセッサが、さらに、
    それぞれの許可されたリクエストに対して、
    前記許可されたリクエストに対する接続情報を記憶させ、前記許可されたリクエストの接続情報は、前記許可されたリクエストのエンド・ユーザ・プロセッサ、メディア・プレーヤー、及びメディア・フォーマットを識別するものであり、
    前記許可されたリクエストのメディア・プレーヤーが、前記許可されたリクエストのメディア・フォーマットに対する前記許可されたリクエストのエンド・ユーザ・プロセッサで以前に使用されたメディア・プレーヤーと異なる場合に、前記１つのエンド・ユーザの前記メディア・ファイルの１つへのアクセスを終了させる、
    ようにさらに構築されていることを特徴とする請求項９に記載のシステム。
11. 前記一つ以上のメディア・ファイルが一つ以上のイベントのストリーミング・メディア・コンテンツを含む、請求項９に記載のシステムであって、
    前記少なくとも一つのサーバ・プロセッサが、さらに
    所与のイベントに対して、前記所与のイベントのストリーミング・コンテンツを含む前記所与のイベントの一つ以上のメディア・ファイルへの前記１つのエンド・ユーザによるアクセスが許容されるところのエンド・ユーザ・プロセッサの数を設定し；
    格納された各エンド・ユーザ・プロセッサ識別子に対して、該格納されたエンド・ユーザ・プロセッサ識別子に関連づけられるイベントの識別子を格納し；
    前記受信されたリクエストの要求元である前記エンド・ユーザ・プロセッサを識別する前記エンド・ユーザ・プロセッサ識別子が、前記所与のイベントに対して格納されたエンド・ユーザ・プロセッサ識別子に一致するか、あるいは、前記所与のイベントに対して格納されたエンド・ユーザ・プロセッサ識別子の数が、前記エンド・ユーザ・プロセッサ識別子の許容数未満である場合に、前記受信されたリクエストが許可され、
    前記受信されたリクエストの要求元である前記エンド・ユーザ・プロセッサを識別する前記エンド・ユーザ・プロセッサ識別子が、前記所与のイベントに対して格納されたエンド・ユーザ・プロセッサ識別子に一致せず、かつ前記格納されたエンド・ユーザ・プロセッサ識別子の数が、前記所与のイベントに対するエンド・ユーザ・プロセッサ識別子の許容数を超える場合に、前記受信されたリクエストが拒否される、
    ように構築されていることを特徴とする請求項９に記載のシステム。
12. 前記一つ以上のメディア・ファイルが一つ以上のイベントのストリーミング・メディア・コンテンツを含み、そして、前記少なくとも一つのサーバ・プロセッサは、前記一つ以上のメディア・ファイルへの前記１つのエンド・ユーザによるアクセスが許容されるところのエンド・ユーザ・プロセッサの数を、前記一つ以上のイベントにわたるエンド・ユーザ・プロセッサの合計数に設定することを特徴とする請求項９に記載のシステム。

Images