本発明の特定の好ましい実施形態は、図面に関して記載されている。コンテンツに対するアクセスを管理するための本発明は、ストリーミング・メディア・ファイルに対するアクセスの管理に関するコンテキストで記載されているが、本発明が全ての種類のメディアまたはファイルに適用され得る事が理解されよう。さらに、本願明細書において記載される実施形態はオンデマンドのストリーミング・メディアに関するものであるが、本実施例がライブのストリーミング・メディアに適用できることは、当業者にとって認識される。
一般に、本実施形態のシステムは、エンド・ユーザ・プロセッサ102、ストリーミング・メディア・サーバ104、およびコンテンツ・マネジメント(CM)データベース108を備えるウェブ・サーバ106を有し、これらの全てがインターネットに接続される。エンド・ユーザ・プロセッサ102は、インターネット・エクスプローラーと言う名称でマイクロソフト社より提供されるか、または、ネットスケープ・ナビゲータと言う名称でネットスケープ・コミュニケイションズより提供されるようなインターネット・ブラウザ、および、ウインドウズ・メディア・プレーヤーと言う名称でマイクロソフト社より提供される、また、リアルプレーヤーと言う名称でリアル・ネットワークス社によって提供されるストリーミング・メディア・プレーヤーを含む。ウェブ・サーバ106はエンド・ユーザ102によってアクセス可能なウェブサイトを提供する。ストリーミング・メディア・サーバ104上に存在するストリーミング・メディア・コンテンツにアクセスするために、ウェブサイトはエンド・ユーザ102によって起動可能なリンクを含む。
本発明は、任意のコンピュータ技術の使用に際して適用し得る事が理解されよう。例えば、本実施形態はインターネットによってコンテンツへのアクセスを提供する事に関するが、本発明は、例えば広域ネットワークを含む任意のコンピュータネットワーク上に使用され得る。同様に、エンド・ユーザ・プロセッサ102は、例えばPDA、ウェブ対応の携帯電話、ネットワークにダイアルアップする有線電話、モバイル・コンピュータ、パーソナルコンピュータ、インターネット装置等のネットワークに接続し得る任意のデバイスであり得る。更に、ここに記述されたサーバは、任意のソフトウエアを実行する任意の種類のもので有り得、また、ここに記述されたソフトウェア・モジュール、オブジェクトおよびプラグインは、任意のプログラム言語で記述され得る。最後に、ここに記述されたデータベースおよび記憶装置は、例えばローカルのコンピュータ・メモリー、ネットワークに接続された記憶装置、および磁気あるいは光学のような任意の公知の記憶媒体の様な任意の記憶技術を利用し得る。
CMデータベース108の一例が図2に示される。図示されるように、データベース108は、全てのストリーミング・コンテンツに普遍的に適用可能な情報と、関連データの幾つかのテーブルを含む。普遍的な情報202はセキュリティ・キー、セキュリティ・インターバル、およびコンテンツが保存されているストリーミング・メディア・サーバ104の名前(「ホスト名」)を含んでいる。セキュリティ・キーおよびセキュリティ・インターバルは、エンド・ユーザ102がコンテンツにアクセスすることを許可するために使用され、秘密にされ、かつ、コンテンツの所有者によって設定される事が望ましい。セキュリティ・キーおよびセキュリティ・インターバルは全てのコンテンツに対するアクセスを管理するために使用されるが、他の実施形態においては、各コンテンツ・ファイルがそれ自身に関するセキュリティ・キーおよびセキュリティ・インターバルを有する。
CMデータベース108は、コンテンツあるいはストリーミング識別情報を含む一連のテーブルをさらに有する。より詳細には、ストリーミング・テーブル204は、ユニークなストリーミング識別子(ID)によって識別されるそれぞれのストリーミング・コンテンツのレコードを含む。更に、各レコードは、例えばコンテンツ・ファイルの作成日を含むコンテンツ・ファイルについて記述するストリーミングの詳細、ファイルの記述、コンテンツがオーディオであるかビデオであるかの識別子、コンテンツが関係するプラットフォーム、コンテンツが最後に修正された日付、コンテンツを視聴するのに必要なコーデック、コンテンツの長さおよびサイズ、コンテンツの有効期限(もしあれば)、.asfまたは.rmのようなストリーミングの種類、コンテンツのタイトルおよびコンテンツの作者、コンテンツのステータス、コンテンツの著作権情報、コンテンツのビットレート等を含む。各レコードは更に、メディア・サーバ104へのリンクを生成するために使用される接頭部 (「URL接頭部」)、およびストリーミング・メディア・サーバ104に格納されているコンテンツ・ファイルの名前(「ファイル名」)を含む。ファイル名は、オンデマンドのコンテンツ用のストリーミング・メディア・サーバ104に接続された記憶装置上の実際のパスを指しても良いし、ファイル名は、ライブのストリーミング用の別名、チャネルまたはポートを指しても良い、と言う事が理解されるべきである。
データベース108は「再生リスト」情報を有するテーブルを含む。クライアントの再生リストは、一般に、グループとして利用可能になされる目的で論理上関連した、1以上のコンテンツ・ファイルのグループである。再生リストの一部であると確認された各コンテンツ・ファイルもまた個々に利用可能になされ得る。このような再生リスト情報は、再生リストテーブル208および再生リスト・ストリーミング・テーブル210に含まれる。一般に、再生リストテーブル208は、再生リストIDによって識別される各再生リストを識別するレコードを含む。各レコードは、例えば再生リストのフォーマット(例えばウインドウズ・メディア・プレーヤーまたはリアルプレーヤー)、再生リストの記述、再生リスト名および同種のもの、および再生リストに対する許可ユーザ・グループIDを含む、再生リスト詳細をさらに含む。
許可ユーザ・グループIDは、特定の再生リストを視聴することを認められるエンド・ユーザ102のグループに対応する。より詳細には、データベース108は、ユニークなエンド・ユーザIDによって識別される各エンド・ユーザ102を1以上の許可ユーザ・グループIDに関連付ける許可ユーザ・テーブル206をさらに含む。エンド・ユーザ102が再生リストを視聴するために、エンド・ユーザ102が該コンテンツ・ファイルのための許可ユーザ・グループIDの一部であるということが確認されなければならない。他の実施形態においては許可グループIDは使用されない場合もあり、更に他の実施形態においては、コンテンツ・ファイルのそれぞれが、該ファイルに関連付けられた許可グループIDを有する。
再生リスト・ストリーミング・テーブル210は、再生リストIDによって識別される再生リストと、ストリーミングIDによって識別される構成コンテンツ・ファイルとを関連付けるレコードを有する。さらに、各レコードは、再生リスト中の各コンテンツ・ファイルの順番を示す情報(「ソート順番」)を含んでいる。
本実施形態において使用されるコンポーネントについて記載してきたが、ここで、ストリーミング・メディア・コンテンツへのアクセスを管理するプロセスについて記述する。概説すると、ウェブ・サーバ106に保存された許可ソフトウエア・コンポーネントは、公開暗号キー情報、プライベート・キー情報および現在時刻に基づいたハッシュ値即ち「チケット」を生成する。公開暗号キーは、エンド・ユーザ102およびエンド・ユーザのユーザIDによってリクエストされるストリーミング・コンテンツが有するユニーク識別子である。プライベート・キーは、コンテンツの所有者によって設定されたセキュリティ・キーとセキュリティ・インターバルを含む。
リクエストされたコンテンツが格納されているストリーミング・メディア・サーバ104は、公開暗号キーを含むストリーミング・リクエストと、ウェブ・サーバ106によって生成されたチケットを受信する。ストリーミング・メディア・サーバ104は、自身のチケットを生成するために、ローカルに格納されたプライベート・キー情報を使用するプロセスへと進む。ストリーミング・メディア・サーバ104は、ストリーミング・メディア・サーバ104およびウェブ・サーバ106によって生成されるチケットを比較することによって、リクエストされたストリーミング・メディアを供給するか、もしくは供給を拒否する。
アクセスを管理するプロセスが、図3のワークフロー・ダイアグラムおよび図4および図5のフローチャートによって詳細に記述される。本実施例において、エンド・ユーザ102があるストリーミング・メディア・コンテンツ・ファイルへのアクセスをリクエストする。最初、ウェブ・サーバ106は、認証アプリケーションにログインすることをエンド・ユーザにリクエストし、あるストリーミング・メディアを視聴する選択肢をエンド・ユーザに提供するウェブ・ページを供する。(ステップ302)。例えば、このようなページは、いくつかのコンテンツ・ファイルのうち、視聴するための1つのコンテンツを選択することをエンド・ユーザにリクエストするフォームを含んでいてもよく、このフォームは、コンテンツの所有者が前もって割り当ててエンド・ユーザに提供したエンド・ユーザIDと、選択するコンテンツのアクセスに対してエンド・ユーザが課金されるようにクレジットカード番号を提供するために用いられる。他の実施形態において、エンド・ユーザはエンド・ユーザの連絡情報および請求書発行情報を提供することによりコンテンツの所有者にあらかじめ登録され、コンテンツの所有者は、エンド・ユーザの連絡情報および請求書発行情報を、登録されたエンド・ユーザIDと共にテーブル形式で保存する。
ウェブ・ページに応答して、エンド・ユーザはエンド・ユーザのユーザIDを提供し、リンクを起動し、これによって、認証アプリケーションにログインし、該リンクに関連する特定のストリーミング・メディア・コンテンツ・ファイルへのアクセスをリクエストする。(ステップ304)。ストリーミングIDが“123456”で表されるストリーミング・リクエストの一例が以下に示される。<A href http://webserver.company.com/getstream.asp?ID=123456>。
本実施形態において、認証アプリケーションは、ウェブ・サーバ106上に存在する「.dll」ソフトウエア・コンポーネントである。しかしながら、ここに記述された機能性を実施するために、例えばアクティブ・サーバー・ページ(ASP)またはサーブレットのような他のプログラム言語あるいは技術を使用し得ることを、当業者は認識するであろう。特定のプログラミング技術に関係なく、認証アプリケーションは、エンド・ユーザ・プロセッサ102上の如何なる処理障害をも緩和するためにウェブ・サーバ106上で実行されることが望ましい。
一旦エンド・ユーザが認証アプリケーションにログインし、ウェブ・サーバ106がエンド・ユーザからストリーミング・リクエストおよびエンド・ユーザIDを受け取れば、ウェブ・サーバ106は、認証チケットを動的に生成し、選択されたコンテンツ・ファイルへのリンクを動的に生成することを継続する。より詳細には、認証アプリケーションの管理下において、ウェブ・サーバ106は、認証チケットを生成する際に使用するためのプライベート・キーをデータベース108に対してリクエストする。(ステップ306)。ウェブ・サーバ106は、リクエストされたコンテンツ・ファイルに関連したセキュリティ・キーおよびセキュリティ・インターバルを含むプライベート・キーをCMデータベース108から検索するためにデータベース・クエリーを発行する。これを受けて、CMデータベース108はウェブ・サーバ106にプライベート・キーを返送する。(ステップ308)。
データベース108からプライベート・キーを取得した後、ウェブ・サーバ106はチケットを生成する。(ステップ310)。図4に関してより詳細に記述されるように、ウェブ・サーバ106は、チケットを生成するためにプライベート・キー、ストリーミングID、エンド・ユーザID、現在時刻およびハッシュ・アルゴリズムを利用する。本実施形態において、リクエストされたコンテンツのストリーミングIDが、ステップ304においてエンド・ユーザによって起動されたストリーミング・リクエスト・リンクに含まれているので、ウェブ・サーバ106は、チケットを生成する際にストリーミングIDを使用することができる。しかしながら、他の実施形態においては、エンド・ユーザによって提供されるストリーミング・リクエストは、例えばコンテンツのタイトル、作者、および(または)ファイル名の様な、ストリーミングID以外のユニーク識別情報を含む。このような実施形態において、ウェブ・サーバ106はストリーミング・テーブル204を検索し、ストリーミング・リクエストに含まれる識別情報に基づいてストリーミングIDを検索する。更に他の実施形態において、ストリーミング・リクエストは、チケットがシステムを生成する際に使用するファイル名またはパスのような、ストリーミングID以外のユニーク識別子を含む。
一旦チケットが生成されれば、ウェブ・サーバ106はメディア・サーバ104上に存在するリクエストされたコンテンツへのリンクを生成する。より詳細には、上に例示したストリーミング・リクエストに基づいて、エンド・ユーザ・プロセッサ102に存在するメディア・プレーヤーが、メディア・サーバ104へのリンクを動的に生成するためのプログラム「getstream.asp」を実行する「webserver.company.com」(即ち、ウェブ・サーバ106)へ回線を接続する。(ステップ312)。当業者は、「getstream」アプリケーションはアクティブ・サーバー・ページ(即ちASP)の拡張子を有しているが、ASP技術を使用することが必ずしも必要ではないことを認識するであろう。むしろ、「.dll」コンポーネントの様な任意のプログラミングまたはスクリプト言語または技術が所望の機能性を提供するために使用され得る。しかしながら、認証アプリケーションにおいて、エンド・ユーザ・プロセッサ102における如何なる処理障害をも緩和するために、該プログラムはサーバ側で実行されることが望ましい。「getstream.asp」プログラムは、メディア・サーバ104へのリンクを動的に生成するのに必要となるデータを検索するため、ウェブ・サーバ106がCMデータベース108を呼び出す様に機能する。より詳細には、ウェブ・サーバ106は、普遍情報テーブル220およびURL接頭部からホスト名を検索し、ストリーミング・テーブル204からファイル名を検索する。更に、「getstream.asp」プログラムはストリーミングID、チケットおよびエンド・ユーザIDをリンクの端部に付加する。その後、ウェブ・サーバ106は、エンド・ユーザ・プロセッサ102のメディア・プレーヤーへリンクを返送する。(ステップ314)。
メディア・ファイルへのリンクの実例は以下の通りである。<REF href=”mms://mediaserver.company.com/stream1.asf?ID=123456&TICKET=uvw123xyz&USER_ID=abc123def”>。ここで、URL接頭部は「mms://」によってリクエストされ、ホスト名は「mediaserver.company.com」によって表わされ、ファイル名は「stream1.asf」によって表わされ、リクエストされたコンテンツのストリーミングIDは「123456」によって表わされ、チケットは「uvw123xyz」によって表わされ、そして、エンド・ユーザIDは「abc123def」によって表わされる。
リンクを受信した後、エンド・ユーザ・プロセッサ102はストリーミング・メディア・コンテンツをリクエストするステップに進む。(ステップ316)。より詳細には、エンド・ユーザ・プロセッサ102に存在するメディア・プレーヤーがリンクによって識別される「mediaserver.company.com」(即ち、ストリーミング・メディア・サーバ104)を呼び出す。呼び出しの一部として、メディア・プレーヤーは、リクエストしたコンテンツのストリーミングIDのコピー、ウェブ・サーバ106によって生成されたチケット、およびエンド・ユーザIDをストリーミング・メディア・サーバに104に供給する。
ストリーミングID、エンド・ユーザIDおよびチケットを含んでいるリンクを受信した後、ストリーミング・メディア・サーバ104は、リクエストされたコンテンツへのアクセスをエンド・ユーザに許可するかどうかを判断するステップに進む。(ステップ318)。図5に関してより詳細に以下記述されるように、ストリーミング・メディア・サーバ104は、ローカルに格納されたプライベート・キー情報およびリンク中に含まれるストリーミングIDおよびエンド・ユーザIDに基づいてチケットを個々に生成することにより、アクセスを付与するかどうかを判断する。一般的に、ストリーミング・メディア・サーバ104によって生成されたチケットがウェブ・サーバ106によって生成されたチケットと一致する場合、ストリーミング・メディア・サーバ104はエンド・ユーザ・プロセッサ102にリクエストされたストリーミング・メディア・コンテンツを供給する。(ステップ320)。
ウェブ・サーバ106によってチケットを生成するプロセスが、図4を参照して詳細に記述される。上述したように、チケット生成プロセスは、ウェブ・サーバ106に存在する許可ソフトウェア・プラグインによって行なわれることが好ましい。本実施形態において、本プロセスは、ウェブ・サーバ106がストリーミングIDおよびエンド・ユーザIDを含むストリーミング・リクエストを受信するステップより開始される。(ステップ402)。その後、ウェブ・サーバ106は、リクエストされたストリーミングIDに関連したプライベート・キー情報を検索するためにデータベース108にアクセスするステップへと進む。(ステップ406)。このようなプライベート・キー情報は普遍的なセキュリティ・キーおよびセキュリティ・インターバルを含む。他の実施形態において、各ストリーミングはストリーミング・テーブル204にフィールドとしてそれ自身のセキュリティ・キーおよびセキュリティ・インターバルを格納し、ウェブ・サーバ106はストリーミング・リクエストに含まれるストリーミングIDに基づいてストリーミング・テーブル204検索する。
上述されるように、ウェブ・サーバ106は、チケットを生成するために現在時刻を更に使用する。より詳細には、ウェブ・サーバ106は現在時刻を計算し、セキュリティ・インターバルに最も近い倍数までその時刻を切り下げる。(ステップ410)。本実施形態において、Cプログラミング言語の標準ライブラリー関数「time()」によって生成されるような協定世界時(UTC)を秒単位で利用する。変数「$time」によって表される、セキュリティ・インターバルに最も近い倍数まで切り下げられた時間を生成するためのPerlプログラム・コードの一例を以下に示す。
ここで、変数「$interval」はセキュリティ・インターバルに対応しており、セキュリティ・インターバルは15分である。
例えば、現在の時刻が2000年5月31日午後2:16:07(中部標準時)であった場合、関数「time()」は、おおよそ「959800567」の値を返す。直近の15分インターバルにこのUTC時間を切り下げることによって「959800500」が得られ、これは、2000年5月31日午後2:15:00(中部標準時)に相当する。
先に例示したコードは変更されても良く、その変更されたコードもまた本発明の範囲内であり得る事が理解されよう。例えば、セキュリティ・インターバルは数分である必要は無く、インターバルが「time()」関数によって用いられる時間の単位で表わされるように適切な変換が行なわれる限り、インターバルは他の時間の単位で表わされも良い。更に、他の実施形態において、現在時刻はUTC以外の標準時に基づく。そのような実施形態において、時間の標準は、ウェブ・サーバ106およびストリーミング・メディア・サーバ104に固有のものである。また、エンド・ユーザ・プロセッサ102に時間を計算させ、かつ認証チケットを生成する際に用いられるべく、ウェブ・サーバ106へその値を送信させることもまた、本発明の範囲内であることが理解されよう。更に他の実施形態において、セキュリティ・インターバルは、標準時が所望の桁数まで単に切り下げられるように選択される。
一旦、ウェブ・サーバ106がハッシュに対して入力された値(アルゴリズム公開暗号キー情報、プライベート・キー情報および時刻)を有すれば、ウェブ・サーバ106は、ハッシュ・アルゴリズムへの入力ストリングを生成する。(ステップ414)。本実施形態において、ハッシュ・アルゴリズムは「MD5」のメッセージ・ダイジェスト・アルゴリズムである。さらに、本実施形態においては、メディア・サーバ104およびウェブ・サーバ106は同じアルゴリズムを利用する。
チケットを生成する任意のハッシュあるいは暗号アルゴリズムを利用する事は、本質的に本発明の範囲内である事が理解されよう。更に、チケットを生成する2つのサーバ(先の実施形態においては、ウェブ・サーバ106およびストリーミング・メディア・サーバ104)は、同一の入力に基づいて同一のチケットを生成するか、同一の入力に基づいて、相互の偏差が所定の範囲内のチケットを生成する事が望ましい。他の実施形態において、セキュリティを増加させるために、複数の利用可能なアルゴリズムの1つが使用される。例えば、そのような実施形態は、複数の利用可能なアルゴリズムから任意に選択された1個のアルゴリズムを使用するか、もしくは、リクエストされたコンテンツ、リクエストの日付と時間、特定のエンド・ユーザ、コンテンツを有するエンティティ等に基づいて複数のアルゴリズムから1つを選択する事も可能である。このような実施形態において、システムは、ウェブ・サーバによって使用されるアルゴリズムの指示をメディア・サーバへ転送するか、あるいは、メディア・サーバは、ウェブ・サーバによって利用されるアルゴリズムと同一のアルゴリズムを選択・使用させるロジックを有する。
使用される特定のハッシュ・アルゴリズムに対して入力ストリングが有効である限り、およびストリーミング・メディア・サーバ104が入力ストリングの配置を認識している限り、入力値の任意の配置が入力ストリングとして使用されてよい。本実施形態において、次の所定の配置が使用される。
TTTTTTTTTTKKKKKKKKKKSSSSSSSSSSUUUUUUUUUU。
ここで、「T」は時刻のデジットを表わし、「K」はセキュリティ・キーの英数字の文字を表し、「S」はストリーミングIDのデジットを表わし(任意の必要な先行・埋め込み文字を含む)、および「U」は、エンド・ユーザIDの英数字の文字を表わす(任意の必要な先行・埋め込み文字を含む)。他の実施形態において、入力ストリングは異なる長さであってもよい。
ハッシュ・アルゴリズム入力ストリングを生成した後、ウェブ・サーバ106は入力ストリングにハッシュ・アルゴリズムを適用し、それによってチケットを生成する。(ステップ418)。
ストリーミング・メディア・サーバ104が、リクエストされたコンテンツ・ストリーミングへのアクセスを許可するかどうかを判断するプロセスが、図5に関連してここに記載される。先ず、必ずしも必要と言うわけではないが、本実施形態におけるメディア・サーバ104が3枚の認証チケットを生成し、それぞれのチケットは異なる時刻に基づき、アクセスを許可するべきかどうかを判断するために使用される、と言う事に注目されるべきである。更に、ウェブ・サーバの機能性と同様に、アクセスを許可するべきかどうかを判断するプロセスは、メディア・サーバ104上に存在する許可ソフトウエア・コンポーネント中で実行されることが望ましい。
アクセスを許可するべきかどうかを判断する際に、ストリーミング・メディア・サーバ104は、エンド・ユーザのプロセッサ102上に存在するメディア・プレーヤーから、ストリーミングID、エンド・ユーザIDおよびチケットを含むストリーミング・リクエストを最初に受け取る。(ステップ502)。一旦ストリーミング・リクエストが受信されれば、メディア・サーバ104はハッシュ・アルゴリズムへの入力ストリングを生成する。この点において、メディア・サーバ104はローカルメモリからプライベート・キー情報(すなわちセキュリティ・キーとセキュリティ・インターバル)を検索する。(ステップ506)。メディア・サーバ104はローカルメモリにプライベート・キー情報を格納するのが望ましいが、他の実施形態においては、メディア・サーバ104は、例えばマイクロソフト社によって提供されるLDAPによってアクセスされるアクティブ・ディレクトリー・ツリーに情報を格納してもよいし、または遠隔のデータベースに情報を格納してもよい。更に他の実施形態において、メディア・サーバ104は、ローカル・エリア・ネットワーク(LAN)のようなネットワーク接続によってデータベース108にアクセスすることにより、プライベート・キー情報を検索する。
ウェブ・サーバ106が行ったように、メディア・サーバ104は更に現在時刻を計算し、セキュリティ・インターバルに最も近接した倍数にその値の端数を切り下げる。(ステップ510)。しかしながら、ウェブ・サーバ106と異なり、ストリーミング・メディア・サーバ104はメディア・サーバ104によって計算されたセキュリティ・インターバルに最も近接した倍数よりも過去の時間である、セキュリティ・インターバルに2番目に近接した倍数に現在時刻を切り下げた第2時刻を更に計算する(ステップ510)。更に、メディア・サーバ104はセキュリティ・インターバルに最も近接した倍数に現在時刻を切り上げた(つまり、時間的に後となる)第3時刻を計算する。(ステップ510)。
その後、メディア・サーバ104は、3つの対応するハッシュ入力ストリングを生成するために、検索されたプライベート・キー情報、受信された公開暗号キー情報および3つの時刻を使用する。(ステップ514)。その後、メディア・サーバ104は、ハッシュ・アルゴリズムに対して3つの入力ストリングを適用し、これによって、3枚のチケットが生成される。(ステップ518)。
個々にチケットを生成した後、メディア・サーバ104は、メディア・サーバ104によって生成されたチケットのうちの任意のチケットがウェブ・サーバ106によって生成されたチケットと一致するかどうかを判断する。(ステップ522)。チケットが一致しない場合、ストリーミング・リクエストが本物でない、かつ(または)、有効期限切れである(つまり、メディア・サーバ104によって生成された時刻が、ユーザのリクエストの時間から測定されるセキュリティ・インターバルの範囲を超えている)可能性が高い。従って、メディア・サーバ104はリクエストされたコンテンツへのアクセスを許可しない。(ステップ526)。
チケットが一致する場合、ストリーミング・リクエストは本物かつセキュリティ・インターバルの範囲内のものである。しかしながら、アクセスを許可するのに先立って、メディア・サーバ104は、エンド・ユーザが既に同じコンテンツへのアクセスを以前にリクエストし、視聴したかどうかを最初に判断する。(ステップ530)。メディア・サーバ104は、エンド・ユーザIDのリストと、ユーザが以前にアクセスを許可されたストリーミングIDを対応させてローカルメモリに保持する事が望ましい。エンド・ユーザがリクエストされたコンテンツを既に視聴したかどうかを判断するために、メディア・サーバ104は、受信したエンド・ユーザIDおよびストリーミングIDが既に格納されているかどうかを判断するために、メモリにアクセスする。エンド・ユーザIDおよびストリーミングIDが既に格納されている場合、エンド・ユーザは、リクエストしたコンテンツに対するアクセスを許可されない。(ステップ530)。
受信されるエンド・ユーザIDおよびストリーミングIDが既に格納されていない場合、メディア・サーバ104は、エンド・ユーザIDおよびストリーミングIDをメモリに格納するステップへと進み(ステップ534)、エンド・ユーザにコンテンツへのアクセスを許可する。(ステップ538)。故に、エンド・ユーザIDおよびストリーミングIDを格納することによって、エンド・ユーザがリクエストしたコンテンツを指向するリンクを他人と共有する事を防ぐ事により、更に高度なセキュリティ保護が達成される。
ウェブ・サーバ106のローカル時間とメディア・サーバ104のローカル時間の間が同期されていない事を補償するために、3つのチケットを使用する事が望ましい事が理解されよう。更に、ある状況では、エンド・ユーザが認証されている場合でも、メディア・サーバ104によって生成された第1のチケット(つまり、セキュリティ・インターバルに最も近接した倍数に切り下げた現在時刻に基づく)が、ウェブ・サーバ106によって生成された第1のチケットと一致しないであろう。例えば、所定のセキュリティ・インターバルを15分とすると、ウェブ・サーバ106が午後12:14:00にチケットを生成し、メディア・サーバ104が午後12:16:00にその第1のチケットを生成する場合、同じ時間帯の同じ日において、たとえリクエストがセキュリティ・インターバルの範囲内にあってもチケットは一致しない。メディア・サーバ104が午後12:15:00に対応する時刻に基づいたチケットを生成する一方、ウェブ・サーバは、午後12:00:00に対応する時刻に基づいたチケットを生成する。従って、本実施形態において、メディア・サーバ104は、セキュリティ・インターバルに2番目に近接した倍数に現在時刻を切り下げた時刻に基づいた第2のチケットを生成する。本例においては、午後12:00:00に対応する。そのため、第2のチケットはウェブ・サーバ106によって生成されるチケットと一致する。同様に、セキュリティ・インターバルが経過した後、エンド・ユーザに対してアクセスを許可する事も可能である。したがって、本実施形態において、セキュリティ・インターバルは複数のチケットの使用を補償するように選択されるべきである。ウェブ・サーバ106およびメディア・サーバ104は、セキュリティ・インターバルの半分の時間内の誤差で合わせられた時計を有する事が望ましい。
メディア・サーバ104が、先の実施形態中における3つのチケットの代替として1つ以上の異なるチケットを生成する事もまた、本発明の範囲内である事が理解されよう。更に、先の実施形態においては、並列に生成されるチケットについて記述したが、メディア・サーバ104がチケットを直列に順次生成・比較する事もまた、本発明の範囲内である。更に、時刻は多くの方法で生成され得、例えば、メディア・サーバ104によって計算された第1の時刻から単にセキュリティ・インターバルを加える、または除する事によって生成されても良い、と言う事が理解されよう。
他の実施形態において、異なったレベルのセキュリティが提供されてもよい。特に、ウェブ・サーバ106によって生成されたチケットがメディア・サーバ104によって生成されたチケットのうちの1つと一致する場合、メディア・サーバ104は同じチケットが既に生成されていたかどうかを判断するステップへと進む。メディア・サーバ104は、アクセスが許可されたチケットのリストを保持する。論理上、このようなリストは全ての「使用済」チケットを表している。一致したチケットが「使用済」チケットのリストに載っていない場合、メディア・サーバ104は、エンド・ユーザのプロセッサ102に存在するメディア・プレーヤーに、リクエストしたコンテンツに対するアクセスを許可する。アクセスを許可するステップの一部として、メディア・サーバ104は、「使用済」チケットのリストを更に更新する。一致したチケットが使用済チケットのリストに載っている場合、メディア・サーバ104はアクセスを拒否し、リクエストしたエンド・ユーザに適切なメッセージを供給する。使用済チケットをトラッキングする事によって、システムは、認可されたエンド・ユーザがウェブ・サーバ106から受信されたストリーミング・リクエストを他人と共有するのを防ぐ。
さらに、アクセスを許可するべきかどうかを判断する際にエラー計算を使用する事も、本発明の範囲内であると言う事が理解されよう。例えば、1つのエラー計算は、所定の期間(例えば15分、30分等)、適用可能なセキュリティ・インターバルの設定百分率(例えば、50%、125%等)のセット割合あるいは他のエラー計算のような、エラー・インターバルを現在時刻に加えた、および(または)除した値に基づいて1以上の追加のチケットを生成するメディア・サーバ104を伴う。このようなエラー計算は、先の実施形態において、第2時刻または第3時刻の代替値として、またはそれに加えて使用されてもよい。
他の実施形態において、ウェブ・サーバ106およびメディア・サーバ104は、時刻を先の実施形態とは異なった方法で計算することにより、チケットを生成する。典型的な一実施形態において、ウェブ・サーバ106およびメディア・サーバ104は現在時刻およびセキュリティ・インターバル以外の或るインターバルの倍数によって切り下げまたは切り上げた現在時刻を計算する。セキュリティ・インターバルが15分である実施形態の場合、ウェブ・サーバ106は、5分のインターバルに最も近接した値に切り下げた現在時刻に基づいてチケットを生成する。次に、ストリーミング・メディア・サーバ104は、同じ5分インターバルに切り下げた現在時刻に基づいてチケットを生成する。チケットが一致しない場合、メディア・サーバ104は、時間的に遡った次のインターバルに切り下げた時間に基づいてチケットを生成するステップに進む。メディア・サーバは、所定の回数、またはウェブ・サーバとメディア・サーバのチケットが一致するまで、時間的に遡った次のよりインターバルに基づいたチケットを生成し続ける。メディア・サーバ104は、その和が少なくともセキュリティ・インターバルに及ぶ複数のタイム・インターバルに基づいて新しいチケットを繰り返し生成する。本実施例において、メディア・サーバ104は、合計15分の5分インターバル、つまり、少なくとも3枚のチケットを生成する。
許可プロセスにおいてエンド・ユーザIDの使用を完全に省略するか、あるいは上述された方法とは異なる方法でエンド・ユーザIDを使用する事もまた、本発明の範囲内である事が理解されよう。例えば、他の実施形態において、エンド・ユーザIDは、ハッシュ・アルゴリズムへの入力ストリングの一部として使用されない。その代わり、データベース108は、どのエンド・ユーザがコンテンツへのアクセスをリクエストしたかをトラッキングするためのテーブルを含む。このような実施形態は、ストリーミングIDで識別されるコンテンツと、ユーザIDで識別され、該コンテンツストリーミングに既にアクセスまたは視聴したエンド・ユーザとを対応付けるレコードを含む視聴ユーザ(ストリーミング)テーブルを含む。同様に、本実施形態は、再生リストIDで識別される再生リストと、ユーザIDで識別され、該コンテンツストリーミングに既にアクセスしたか視聴したエンド・ユーザとを対応付けるレコードを含む視聴ユーザ(再生リスト)テーブルを含む。認証チケットを生成する前に、ウェブ・サーバは、同じエンド・ユーザが特定のストリーミングおよび再生リストにアクセスする事を既にリクエストしたかどうかを判断するために、適切な視聴ユーザ・テーブルをチェックする。エンド・ユーザが既にアクセスをリクエストしていた場合、ウェブ・サーバはアクセスを拒否するか、あるいは、今回のアクセスに対してエンド・ユーザは再び課金されるであろうということを示すウェブ・ページをエンド・ユーザに供給する。テーブルは、セキュリティ・インターバルのような期間あるいはそれを超過する期間の後に、自動的にクリアーされる。
本発明が、コンテンツの所有者であるクライアントに代わって、ウェブ・サーバ、ストリーミング・メディア・サーバおよび再生リスト・サーバを例えばサービス・プロバイダーが操作するような比較的複雑なシステムに適用される事も可能である、と言う事が理解されよう。このような実施形態が、図6〜図8に関してここに記述される。本実施形態における機能性の多くは図3に示された実施形態における機能性と同一であり、同一の技術のうちで任意のものによって実施され得る、と言う事が当業者によって理解されよう。
図6に示されるように、本システムは図1に示された実施形態の構成要素と同様の構成要素を幾つか含む。本システムは、エンド・ユーザ・プロセッサ602、データベース608を含む1つ以上のストリーミング・メディア・サーバ604、および1つ以上のウェブ・サーバ606を含み、これらのすべてはインターネットあるいは他のネットワークへ接続される。さらに、本実施形態におけるシステムは、サービス・プロバイダーによって操作される再生リスト・サーバ610を更に含む。データベース608を含むウェブ・サーバ606、ストリーミング・メディア・サーバ604、および再生リスト・サーバ610は、ローカル・エリア・ネットワーク(LAN)またはワイド・エリア・ネットワーク(WAN)のようなサービス・プロバイダーのネットワークおよびインターネットに接続される事が好ましい。
一般的に、データベース608は図2の実施形態のデータベースに含まれている情報と同じ情報を含んでいるが、該情報はクライアント・アカウント毎に格納される。図7に示されるように、データベース608は、アカウントIDによって識別される各クライアントのレコードを含むアカウント・テーブル702を含む。各レコードは、クライアント名、アドレス、請求書発行情報等のクライアントを識別する情報(「クライアント情報」)、クライアントのコンテンツが保護されているかどうかに関する表示(「コンテンツ保護」)、クライアントのセキュリティ・キー(「セキュリティ・キー」)、およびセキュリティ・インターバル(「セキュリティ・インターバル」)を更に含む。
図2の実施形態と同様に、本データベース608は、ストリーミングIDによって識別される各コンテンツ・ファイル用のストリーミング識別情報を含むストリーミング・テーブル704と、許可されたユーザ・グループIDにエンド・ユーザIDを対応付ける許可ユーザ・テーブル706と、再生リストIDによって識別される各再生リスト用の再生リスト識別情報を含む再生リストテーブル708と、所定の再生リストIDに関連付けられたストリーミングIDを識別する再生リスト・ストリーミング・テーブル710を更に備える。図2のデータベースに関して記述された情報フィールドに加えて、ストリーミング・テーブル704および再生リストテーブル708は、各コンテンツ・ファイルおよび各再生リストに関連したアカウントIDを識別するフィールドをそれぞれに更に含む。
本データベース608は、コンテンツ・ファイルが格納される特定のストリーミング・メディア・サーバ604のホスト名を識別し、ストリーミングIDによって指定される各コンテンツ・ファイル用のレコードを含むストリーミング・サーバ・テーブル712を含む。図2におけるの実施形態と同様、ホスト名はメディア・サーバ604のDNS名である。
本実施形態の動作が、図8のワークフローに関してここに記述される。本実施例の例のために、エンド・ユーザは1つの保護コンテンツを含む再生リストへのアクセスをリクエストする。最初、ウェブ・サーバ606は、認証アプリケーションにログインすることをエンド・ユーザにリクエストし、所定のストリーミング・メディアを視聴する選択肢をエンド・ユーザに選択させるウェブ・ページを提供する。(ステップ802)。図3の実施形態と同様に、典型的なウェブ・ページは、リンクを起動する事によって特定のコンテンツ・ファイルを選択する事と、エンド・ユーザIDを提供する事と、請求書発行情報を提供する事をエンド・ユーザにリクエストするフォームを備え得る。ウェブ・ページに応答して、エンド・ユーザはエンド・ユーザのユーザIDおよびクレジットカード情報を提供し、ストリーミング・リクエスト・リンクを起動し、これによって、特定のストリーミング・メディア・コンテンツ・ファイルへのアクセスをリクエストする。再生リストIDが「789000」である典型的なストリーミング・リクエスト・リンクは以下のとおりである。<A href”http://playlistserver.company.com/makeplaylist.dll?ID=789000”>。
エンド・ユーザがストリーミング・リクエスト・リンクを起動する場合、エンド・ユーザ・プロセッサ602上で実行されるプログラミング・スクリプトによって、ストリーミング・リクエスト・リンクおよびエンド・ユーザIDがウェブ・サーバ606に送信される。(ステップ804)。当業者は、エンド・ユーザ・スクリプトは、例えばC++、Perl、ビジュアルベーシック、Java(登録商標)等の実質的に任意のプログラム言語によって記述され得る事を認識するであろう。本実施形態において、スクリプトはJava(登録商標)スクリプトであり、エンド・ユーザのウェブ・ブラウザと共働して実行される。
一旦ウェブ・サーバ606がスクリプトからストリーミング・リクエストを受け取れば、ウェブ・サーバ606は、許可ソフトウェア・プラグインの指示の下にチケットを生成する。この点において、ウェブ・サーバ606は、認証チケットを生成する際に使用されるプライベート・キーをデータベース608へ要求するリクエストを発行する(本実施形態において、セキュリティ・キーとセキュリティ・インターバルはリクエストされた再生リストと関連付けられている)。(ステップ806)。これを受けて、データベース608はウェブ・サーバ606にプライベート・キーを返す。(ステップ808)。
データベース608からプライベート・キーを取得した後、ウェブ・サーバ606は、図4に関して上に記述されるようなストリーミングされたものの代わりに再生リストIDを使用することによってチケットを生成する(本実施形態において、再生リストIDに代替される)。(ステップ810)。前述されたように、ウェブ・サーバ606は、チケットを生成するためにハッシュ・アルゴリズムにプライベート・キー、ストリーミングID、エンド・ユーザIDおよび時刻を適用する。その後、ウェブ・サーバ606は、エンド・ユーザ・プロセッサ602上で実行されるウェブ・ブラウザにチケットおよびエンド・ユーザIDを返す。(ステップ812)。
チケットを受信した後、エンド・ユーザ・プロセッサ602上で実行されるスクリプトは、ストリーミング・リクエスト・リンクの末端に情報をアペンドする。(ステップ814)。典型的なリンクが以下に示される。<A href ”http://playlistserver.company.com/makeplaylist?ID=789000&TICKET=uvw123xyz retun&user_id=abc123def”>。ここで、再生リストIDは「789000」で表され、チケットは「uvw123xyz」で表され、エンド・ユーザIDは「abc123def」で表される。
エンド・ユーザ・プロセッサ602上で実行されるスクリプトは、ホスト名「playlistserver.company.com」によってストリーミング・リクエスト・リンク中に識別される再生リスト・サーバ610を呼び出させる。(ステップ816)。従って、再生リスト・サーバ610は、リンク、再生リストID、チケットおよびユーザIDを供給される。「makeplaylist.dll」オブジェクトの管理の下で、再生リスト・サーバ610は、ASXファイルのような、コンテンツがウインドウズ・メディア・フォーマットであるリダイレクター・ファイルを生成する。(ステップ818)。「makeplaylist」プログラムは、例えばASPを含む多くのプログラムあるいは技術のうちの任意のものを使用して実施されうる。リダイレクター・ファイルは、チケットおよび公開暗号キー(つまり、ストリーミングIDおよびエンド・ユーザID)に加えて、リクエストされたコンテンツへのリンクを含んでいる。リダイレクター・ファイルを生成するために、再生リストと、ストリーミングIDに関連付けられたホスト名・URL接頭部・ファイル名を含むコンテンツ・ファイルへのリンクに際して必要な情報とを含むコンテンツ・ファイルのストリーミングIDを検索するために、再生リスト・サーバ610はデータベース608にアクセスする。
他の実施形態において、エンド・ユーザ・スクリプトはストリーミング・リクエストにチケットをアペンドするために利用されない。その代わり、エンド・ユーザが自身のエンド・ユーザIDを提供し、ストリーミング・リクエスト・リンクを起動する場合(ステップ804)、ウェブ・サーバ606上で実行される認証アプリケーションがチケットを生成し、ストリーミング・リクエスト・リンクにチケットおよびエンド・ユーザIDをアペンドし、リダイレクター・ファイルを作成するために再生リスト・サーバ610を直接呼び出す。さらにウェブ・サーバ606がエンド・ユーザ・プロセッサ602上のメディア・プレーヤーを識別する情報を再生リスト・サーバ610情報に転送するので、再生リスト・サーバ610は、メディア・プレーヤーへリダイレクター・ファイルを転送する(ステップ812,814および816が省略される)。このような実施形態は、図10に関して後述される。
その後、再生リスト・サーバ610はエンド・ユーザ・プロセッサ602のメディア・プレーヤーへASXリダイレクター・ファイルを転送する。(ステップ820)。本実施例のために、ASXファイルは以下のとおりに記述される。
ここでURL接頭部は、「mms://」で表され、適切なメディア・サーバ604のホスト名が「mediaserver.company.com」で表され、ファイル名は「stream1.asf」で表され、リクエストされたコンテンツ・ストリーミングIDは「123456」で表わされ、チケットは「uvw123xyz」で表され、エンド・ユーザIDは「abcl23def」で表される。
リダイレクター・ファイルは、コンテンツ・ファイル用メタデータや、広告のような保護されていないファイルのような他の情報を含んでいて良い。
ASXファイルを受信した後、エンド・ユーザ・プロセッサ602はストリーミング・メディア・コンテンツをリクエストするステップへと進む。より詳細には、メディア・プレーヤーは、ASXファイル中に識別される「mediaserver.company.com」(つまり、ストリーミング・メディア・サーバ604)を呼び出す。(ステップ822)。呼び出された後、メディア・プレーヤーは、リクエストされた番組のストリーミングIDのコピー、ウェブ・サーバ606によって生成されたチケット、およびエンド・ユーザIDをストリーミング・メディア・サーバに604を供給する。
メディア・プレーヤーの呼び出しに応答して、ストリーミング・メディア・サーバ604は、エンド・ユーザがアクセスをリクエストしているコンテンツへのアクセスを認めるかどうかを判断するステップへと進む。(ステップ824)。ストリーミング・メディア・サーバ604は、個々に1以上の認証チケットを生成し、そのチケットをウェブ・サーバ606によって生成されたチケットと比較することにより、アクセスを許可するかどうかを判断する。認証チケットを生成するおよび比較するプロセスは、ストリーミングIDの代わりに再生リストIDを使用する点を除いて、図5に関して記述されるのと同じ方法で達成される。メディア・サーバ604によって生成されたチケットがウェブ・サーバ606によって生成されたチケットと一致する場合、メディア・サーバ604はエンド・ユーザがアクセスをリクエストしているコンテンツへのアクセスを許可する。(ステップ824)。
先の実施形態はセキュリティ・キーとセキュリティ・インターバルの両方を含むプライベート・キーを利用するが、プライベート・キーとしてそれ以上、またはそれ以下の情報を利用するのも、本発明の範囲内である事が理解されよう。例えば、他の実施形態においてはセキュリティ・キーが使用されない。また、他の実施形態においては、例えばクライアントのユーザ名およびパスワードを含む補足情報が、プライベート・キーに含まれる。同様に、ストリーミングIDおよびエンド・ユーザID以外の情報を含む公開暗号キーを利用する事も、本発明の範囲内である。例えばファイル・パス名の様な、情報を識別する他のコンテンツ・ファイル識別情報が使用されてもよい。さらに、ある実施形態においては、エンド・ユーザIDが公開暗号キー情報から省略されてもよい。更に他の実施形態において、公開暗号キー情報は、他のリクエスト・コンテンツ・ファイルのタイトルあるいはストリーミング詳細のような補足情報を含んでいる。
ウェブ・サーバおよびストリーミング・メディア・サーバによって提供されると記載された機能性が、それに関連する他のデバイス上において実施され得るということが理解されよう。例えば、本発明の一実施形態において、ストリーミング・メディア・サーバが、それに接続される関連するアプリケーションサーバを備え、アプリケーションサーバは、コンテンツに対するアクセスを拒否または許可するプロセスの全部または一部を実施する。同様に、それは、例えば認証チケットを生成する過程を含むウェブ・サーバの機能性のうちの一部または全部を提供するためにウェブ・サーバとアプリケーションサーバとを関連付ける事は、本発明の範囲内である。そのため、特定のサーバに対する言及は、言及されたサーバと接続される他の関連するサーバあるいはプロセッサを含む、という事を意図している。
さらに、認証チケットを正確な時間に生成する必要は無い、と言う事が理解されよう。例えば、ウェブ・サーバによって生成されるチケットは、エンド・ユーザがストリーミング・リクエスト・リンクを起動する時間に基づいても良いし、ウェブ・サーバがデータベースからプライベート・キー情報を得る時間に基づいても良いし、ストリーミング・リクエストの起動時間に近接した任意の時間に基づいても良い。同様に、メディア・サーバが許可を生成する時間は、例えば、メディア・プレーヤーからの呼出がなされた時でも良いし、プライベート・キー情報が検索された後でも良いし、ストリーミング・リクエストの起動時間に近接した任意の時間であっても良い。更に、メディア・サーバが複数のチケットを生成する際、チケットは異なる複数の時間に基づいて生成されても良いし、単一の時間に基づいて生成されても良い。従って、時間または現在時刻に対する参照は、ある一定の範囲の参照を意図するものであり、正確な時刻の参照を意図するものではない。
先の典型的な実施形態は、単一のコンテンツに対するアクセスを管理すると言うコンテキストで記載されたが、先の実施形態が複数の保護コンテンツ・ファイルを含む再生リストへのアクセスを管理するために用いられ得るという事を当業者は理解するであろう。再生リストへのアクセスを管理するための典型的な一実施形態が、図6〜図8の実施形態に関して記述される。このような実施形態は、下記の変更を伴った上で、前述の記載に従って作動する。一般的に、ウェブ・サーバ606は、各ストリーミングのストリーミングIDに基づいて、再生リストに含まれる各コンテンツ・ストリーミングのチケットを生成する。
エンド・ユーザ・プロセッサ602のメディア・プレーヤーは、再生リストIDを含むストリーミング・リクエストを再生リストプロセッサ610へ転送する。次に、再生リストプロセッサ610はリダイレクター・ファイルを生成し、メディア・プレーヤーにリダイレクター・ファイルを返送する。本実施例において、オブジェクト「makeplaylist.dll」は、適切なリダイレクター・ファイルを構築するために再生リストID「789000」を使用する。より詳細には、どのコンテンツがリクエストされた再生リストの一部を構成するのかを判断するため、および再生リスト中のコンテンツ・ファイルの順番を判断するために、再生リスト・サーバ610は、再生リストテーブル708および再生リスト・ストリーミング・テーブル710にアクセスする。コンテンツ・ファイルのファイル名はストリーミング・テーブル704から検索される。続いて、エンド・ユーザ・プロセッサ602上で実行されるスクリプトは、対応するコンテンツ・ストリーミングへリンクするURLにストリーミングID、チケットおよびエンド・ユーザIDをアペンドする。本実施形態において、ストリーミング・サーバ・テーブル712中から識別されるように、全てのコンテンツ・ストリーミングは同一のメディア・サーバ604に格納される。
対応するコンテンツ・ストリーミングのためのURLリンクにアペンドされたストリーミングID、チケットおよびエンド・ユーザIDを含むASXリダイレクター・ファイルの例を以下に示す。
その後、メディア・プレーヤーは、ストリーミング・メディア・サーバ604を連続して呼び出し、各呼び出しに対する各URLリンクがリダイレクター・ファイルに含まれている。より具体的には、メディア・プレーヤーは先ず、第1のコンテンツ・ストリーミング(本例において、ストリーミングID「123456」を有する)にアクセスするためにメディア・サーバ604を呼び出す。呼び出しに応答して、また、図5に関して概説したように、メディア・サーバ604は個々にチケットを生成し、コンテンツへのアクセスを許可するべきかどうかを判断する。アクセスが許可されない場合、エンド・ユーザにその旨が通知される。一方、メディア・サーバがエンド・ユーザに対して第1のコンテンツ・ストリーミングへのアクセスを許可する場合、メディア・プレーヤーは、再生リスト中の残りのコンテンツ・ストリーミング用のメディア・サーバ604を呼び出すステップへと進む。それぞれの呼び出しで、メディア・サーバ604はリクエストされたコンテンツへのアクセスを許可するか拒否するかのステップへと進む。
しかしながら、このような実施形態において、各々のコンテンツ・ストリーミングが、再生リスト中のストリーミングに先立って再生されるコンテンツ・ストリーミングの所要時間の合計を計上した長さの個々のセキュリティ・インターバルを有することが望ましい、と言う事が理解されるべきである。例えば、それぞれが5分の所要時間を有する(ストリーミング・テーブル704のストリーミング詳細フィールドに示される)3つのコンテンツ・ストリーミングを含む再生リスト中で、第2のストリーミングのセキュリティ・インターバルは、第1のストリーミングのセキュリティ・インターバルよりも5分間だけ長くても良く、第3のストリーミングのセキュリティ・インターバルは、第1のストリーミングのセキュリティ・インターバルよりも10分間だけ長くても良い。再生リスト中の各ストリーミングの所要時間を計上する事によって、システムは、許可されたエンド・ユーザが、再生リスト中の第1のコンテンツ・ストリーミングへのアクセスを許可されるがチケットが有効期限切れになったという理由によって後続のコンテンツ・ストリーミングに対するアクセスが許可されない、という事を防止する。更に、セキュリティ・インターバルは、再生リストに含まれる広告のような任意の非保護コンテンツの所要時間を計上しても良い。
更に他の実施形態は、再生リストIDに基づいてチケットを生成することにより、複数の保護コンテンツ・ストリーミングを含む再生リストへのアクセスを管理する。このような実施形態は、下記の変更を伴った上で、図6〜図8のシステムの記述に従って作動する。一般的に、一旦エンド・ユーザが認証アプリケーションにログインし、再生リストへのアクセスをリクエストすれば、ウェブ・サーバ606は、再生リストIDに基づいてチケットを生成し、エンド・ユーザ・プロセッサ602にチケットを返送する。これを受けて、エンド・ユーザ・プロセッサ602上で実行されるスクリプトは、ストリーミング・リクエスト・リンクにチケットおよびエンド・ユーザIDをアペンドする。以下、公開暗号キー情報がアペンドされたストリーミング・リクエスト・リンクの例を示す。<A href”http://playlistserver.company.com/makeplaylist.dll?PLAYLIST_ID=789000&TICKET=xyz321abc&USER_ID=abc123def”>。ここで、再生リストIDは「789000」で表され、チケットは「xyz321abc」で表され、エンド・ユーザIDは「abc123def」で表される。
エンド・ユーザ・プロセッサ602は、「playlistserver.company.com」と言う名称によって識別される再生リスト・サーバ610を呼び出す。次に、再生リスト・サーバ610は、リダイレクター・ファイルを生成するために再生リスト・サーバ610に存在する「makeplaylist.dll」オブジェクトを始動する。本実施形態において、コンテンツ・ストリーミングはすべて同一のメディア・サーバ604上に存在する。先の実施形態と異なり、「makaplaylist.dll」オブジェクトは、リダイレクター・ファイル中の第1のURLの端部に、再生リスト中の後続する保護コンテンツ・ストリーミングのファイル名をアペンドし、それぞれの後続のURLリンクには、再生リストIDおよびチケットのみがアペンドされる。ASXリダイレクター・ファイルの例を以下に示す。
ここで、再生リストは、「stream1.asf」、 「stream2.asf」、 「stream3.asf」、と名前の付けられた3つのウィンドウズ・メディア・フォーマット(ウィンドウズは登録商標)のコンテンツ・ファイルを含み、再生リストIDは「789000」で表され、エンド・ユーザIDは「abc123def」で表され、チケットは「xyz321abc」で表される。
エンド・ユーザ・プロセッサ602のメディア・プレーヤーは、第1のコンテンツ・ファイルにアクセスするために、mediaserver.company.com(即ち、ストリーミング・メディア・サーバ604のホスト名)を呼び出すステップへ進む。メディア・サーバ604は、図5に関して上述されたように、再生リストIDに基づいてチケットを生成し、アクセスを許可または拒否するステップへと進む。メディア・サーバ604がアクセスを許可し、メディア・プレーヤーに再生リスト中の第1のコンテンツ・ファイルを提供する場合、メディア・サーバ604は、再生リストIDおよび対応するチケットのためにローカルに格納されたテーブル中にレコードを作成し、リダイレクター・ファイルに含まれている再生リスト中の後続するコンテンツ・ストリーミングのファイル名をレコード中に格納する。
メディア・プレーヤーが第2のコンテンツ・ストリーミングへのアクセスを要求する場合、メディア・プレーヤーはメディア・サーバ604に再生リストIDおよびチケットを供給する。次に、メディア・サーバ604は、再生リストIDおよびチケットによって識別されたレコードを、テーブル中から検索する。レコードが存在する場合、メディア・サーバ604は第2のストリーミングをへのアクセスを許可し、特定のチケットを有するエンド・ユーザによって視聴された旨、ストリーミングにフラグを立てる。無許可のエンド・ユーザが同じURLリンクを使用して第2のストリーミングにアクセスすることを試みる場合、再生リストIDおよびチケットに関するレコードにおいて、上述したように第2のストリーミングが視聴された旨を示すフラグが立っているので、メディア・サーバ604はアクセスを拒否する。同様のプロセスが、再生リスト中の残りのコンテンツ・ストリーミングへのアクセスを許可するために利用される。当業者によって認識されるように、本実施形態は、第1のストリーミングへのアクセス許可と、後続のストリーミングとの間の時間遅延に起因して再生リスト中の後続のストリーミングへのアクセスが不適切に拒否されるような如何なる可能性をも回避する。
当業者は、本発明の方法およびシステムが多数の応用を有し、多数の方法において実施され得、従って、以上記載された典型的な実施形態および実施例によって制限され無いという事を認識するであろう。さらに、当業者によって理解されるように、本発明の範囲は、本願明細書に記載されているシステム構成部分に対する従来公知の、および将来開発される変更および修正を含む。