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

Abstract

【課題】ストリーミング・メディアを含むデジタル・コンテンツへのアクセスを管理するシステムおよび方法。
【解決手段】ストリーミング・データ（５０２）を含むデジタル・コンテンツへのアクセスを管理するシステムおよび方法であって、メディアサーバは認証チケットを生成しそれをウェブサーバ（５１８）により生成されたものと一致するかを比較（５２２）してアクセスを認可するかどうかを判断する（５３０）。
【選択図】図５

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ウェブ・ページに応答して、エンド・ユーザはエンド・ユーザのユーザＩＤを提供し、リンクを起動し、これによって、認証アプリケーションにログインし、該リンクに関連する特定のストリーミング・メディア・コンテンツ・ファイルへのアクセスをリクエストする。（ステップ３０４）。ストリーミングＩＤが“１２３４５６”で表されるストリーミング・リクエストの一例が以下に示される。＜Ａ ｈｒｅｆ ｈｔｔｐ：／／ｗｅｂｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｇｅｔｓｔｒｅａｍ．ａｓｐ？ＩＤ＝１２３４５６＞。

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

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

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

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

メディア・ファイルへのリンクの実例は以下の通りである。＜ＲＥＦ ｈｒｅｆ＝”ｍｍｓ：／／ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｔｒｅａｍ１．ａｓｆ？ＩＤ＝１２３４５６＆ＴＩＣＫＥＴ＝ｕｖｗ１２３ｘｙｚ＆ＵＳＥＲ＿ＩＤ＝ａｂｃ１２３ｄｅｆ”＞。ここで、ＵＲＬ接頭部は「ｍｍｓ：／／」によってリクエストされ、ホスト名は「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」によって表わされ、ファイル名は「ｓｔｒｅａｍ１．ａｓｆ」によって表わされ、リクエストされたコンテンツのストリーミングＩＤは「１２３４５６」によって表わされ、チケットは「ｕｖｗ１２３ｘｙｚ」によって表わされ、そして、エンド・ユーザＩＤは「ａｂｃ１２３ｄｅｆ」によって表わされる。

リンクを受信した後、エンド・ユーザ・プロセッサ１０２はストリーミング・メディア・コンテンツをリクエストするステップに進む。（ステップ３１６）。より詳細には、エンド・ユーザ・プロセッサ１０２に存在するメディア・プレーヤーがリンクによって識別される「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」（即ち、ストリーミング・メディア・サーバ１０４）を呼び出す。呼び出しの一部として、メディア・プレーヤーは、リクエストしたコンテンツのストリーミングＩＤのコピー、ウェブ・サーバ１０６によって生成されたチケット、およびエンド・ユーザＩＤをストリーミング・メディア・サーバに１０４に供給する。

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

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

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

ここで、変数「＄ｉｎｔｅｒｖａｌ」はセキュリティ・インターバルに対応しており、セキュリティ・インターバルは１５分である。

例えば、現在の時刻が２０００年５月３１日午後２：１６：０７（中部標準時）であった場合、関数「ｔｉｍｅ（）」は、おおよそ「９５９８００５６７」の値を返す。直近の１５分インターバルにこのＵＴＣ時間を切り下げることによって「９５９８００５００」が得られ、これは、２０００年５月３１日午後２：１５：００（中部標準時）に相当する。

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

一旦、ウェブ・サーバ１０６がハッシュに対して入力された値（アルゴリズム公開暗号キー情報、プライベート・キー情報および時刻）を有すれば、ウェブ・サーバ１０６は、ハッシュ・アルゴリズムへの入力ストリングを生成する。（ステップ４１４）。本実施形態において、ハッシュ・アルゴリズムは「ＭＤ５」のメッセージ・ダイジェスト・アルゴリズムである。さらに、本実施形態においては、メディア・サーバ１０４およびウェブ・サーバ１０６は同じアルゴリズムを利用する。

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

使用される特定のハッシュ・アルゴリズムに対して入力ストリングが有効である限り、およびストリーミング・メディア・サーバ１０４が入力ストリングの配置を認識している限り、入力値の任意の配置が入力ストリングとして使用されてよい。本実施形態において、次の所定の配置が使用される。

ＴＴＴＴＴＴＴＴＴＴＫＫＫＫＫＫＫＫＫＫＳＳＳＳＳＳＳＳＳＳＵＵＵＵＵＵＵＵＵＵ。

ここで、「Ｔ」は時刻のデジットを表わし、「Ｋ」はセキュリティ・キーの英数字の文字を表し、「Ｓ」はストリーミングＩＤのデジットを表わし（任意の必要な先行・埋め込み文字を含む）、および「Ｕ」は、エンド・ユーザＩＤの英数字の文字を表わす（任意の必要な先行・埋め込み文字を含む）。他の実施形態において、入力ストリングは異なる長さであってもよい。

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

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

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

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

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

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

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

受信されるエンド・ユーザＩＤおよびストリーミングＩＤが既に格納されていない場合、メディア・サーバ１０４は、エンド・ユーザＩＤおよびストリーミングＩＤをメモリに格納するステップへと進み（ステップ５３４）、エンド・ユーザにコンテンツへのアクセスを許可する。（ステップ５３８）。故に、エンド・ユーザＩＤおよびストリーミングＩＤを格納することによって、エンド・ユーザがリクエストしたコンテンツを指向するリンクを他人と共有する事を防ぐ事により、更に高度なセキュリティ保護が達成される。

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

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

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

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

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

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

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

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

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

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

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

本実施形態の動作が、図８のワークフローに関してここに記述される。本実施例の例のために、エンド・ユーザは１つの保護コンテンツを含む再生リストへのアクセスをリクエストする。最初、ウェブ・サーバ６０６は、認証アプリケーションにログインすることをエンド・ユーザにリクエストし、所定のストリーミング・メディアを視聴する選択肢をエンド・ユーザに選択させるウェブ・ページを提供する。（ステップ８０２）。図３の実施形態と同様に、典型的なウェブ・ページは、リンクを起動する事によって特定のコンテンツ・ファイルを選択する事と、エンド・ユーザＩＤを提供する事と、請求書発行情報を提供する事をエンド・ユーザにリクエストするフォームを備え得る。ウェブ・ページに応答して、エンド・ユーザはエンド・ユーザのユーザＩＤおよびクレジットカード情報を提供し、ストリーミング・リクエスト・リンクを起動し、これによって、特定のストリーミング・メディア・コンテンツ・ファイルへのアクセスをリクエストする。再生リストＩＤが「７８９０００」である典型的なストリーミング・リクエスト・リンクは以下のとおりである。＜Ａ ｈｒｅｆ”ｈｔｔｐ：／／ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ？ＩＤ＝７８９０００”＞。

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

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

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

チケットを受信した後、エンド・ユーザ・プロセッサ６０２上で実行されるスクリプトは、ストリーミング・リクエスト・リンクの末端に情報をアペンドする。（ステップ８１４）。典型的なリンクが以下に示される。＜Ａ ｈｒｅｆ ”ｈｔｔｐ：／／ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｍａｋｅｐｌａｙｌｉｓｔ？ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｕｖｗ１２３ｘｙｚ ｒｅｔｕｎ＆ｕｓｅｒ＿ｉｄ＝ａｂｃ１２３ｄｅｆ”＞。ここで、再生リストＩＤは「７８９０００」で表され、チケットは「ｕｖｗ１２３ｘｙｚ」で表され、エンド・ユーザＩＤは「ａｂｃ１２３ｄｅｆ」で表される。

エンド・ユーザ・プロセッサ６０２上で実行されるスクリプトは、ホスト名「ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」によってストリーミング・リクエスト・リンク中に識別される再生リスト・サーバ６１０を呼び出させる。（ステップ８１６）。従って、再生リスト・サーバ６１０は、リンク、再生リストＩＤ、チケットおよびユーザＩＤを供給される。「ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ」オブジェクトの管理の下で、再生リスト・サーバ６１０は、ＡＳＸファイルのような、コンテンツがウインドウズ・メディア・フォーマットであるリダイレクター・ファイルを生成する。（ステップ８１８）。「ｍａｋｅｐｌａｙｌｉｓｔ」プログラムは、例えばＡＳＰを含む多くのプログラムあるいは技術のうちの任意のものを使用して実施されうる。リダイレクター・ファイルは、チケットおよび公開暗号キー（つまり、ストリーミングＩＤおよびエンド・ユーザＩＤ）に加えて、リクエストされたコンテンツへのリンクを含んでいる。リダイレクター・ファイルを生成するために、再生リストと、ストリーミングＩＤに関連付けられたホスト名・ＵＲＬ接頭部・ファイル名を含むコンテンツ・ファイルへのリンクに際して必要な情報とを含むコンテンツ・ファイルのストリーミングＩＤを検索するために、再生リスト・サーバ６１０はデータベース６０８にアクセスする。

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

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

ここでＵＲＬ接頭部は、「ｍｍｓ：／／」で表され、適切なメディア・サーバ６０４のホスト名が「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」で表され、ファイル名は「ｓｔｒｅａｍ１．ａｓｆ」で表され、リクエストされたコンテンツ・ストリーミングＩＤは「１２３４５６」で表わされ、チケットは「ｕｖｗ１２３ｘｙｚ」で表され、エンド・ユーザＩＤは「ａｂｃｌ２３ｄｅｆ」で表される。

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

ＡＳＸファイルを受信した後、エンド・ユーザ・プロセッサ６０２はストリーミング・メディア・コンテンツをリクエストするステップへと進む。より詳細には、メディア・プレーヤーは、ＡＳＸファイル中に識別される「ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ」（つまり、ストリーミング・メディア・サーバ６０４）を呼び出す。（ステップ８２２）。呼び出された後、メディア・プレーヤーは、リクエストされた番組のストリーミングＩＤのコピー、ウェブ・サーバ６０６によって生成されたチケット、およびエンド・ユーザＩＤをストリーミング・メディア・サーバに６０４を供給する。

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

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

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

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

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

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

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

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

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

更に他の実施形態は、再生リストＩＤに基づいてチケットを生成することにより、複数の保護コンテンツ・ストリーミングを含む再生リストへのアクセスを管理する。このような実施形態は、下記の変更を伴った上で、図６〜図８のシステムの記述に従って作動する。一般的に、一旦エンド・ユーザが認証アプリケーションにログインし、再生リストへのアクセスをリクエストすれば、ウェブ・サーバ６０６は、再生リストＩＤに基づいてチケットを生成し、エンド・ユーザ・プロセッサ６０２にチケットを返送する。これを受けて、エンド・ユーザ・プロセッサ６０２上で実行されるスクリプトは、ストリーミング・リクエスト・リンクにチケットおよびエンド・ユーザＩＤをアペンドする。以下、公開暗号キー情報がアペンドされたストリーミング・リクエスト・リンクの例を示す。＜Ａ ｈｒｅｆ”ｈｔｔｐ：／／ｐｌａｙｌｉｓｔｓｅｒｖｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｍａｋｅｐｌａｙｌｉｓｔ．ｄｌｌ？ＰＬＡＹＬＩＳＴ＿ＩＤ＝７８９０００＆ＴＩＣＫＥＴ＝ｘｙｚ３２１ａｂｃ＆ＵＳＥＲ＿ＩＤ＝ａｂｃ１２３ｄｅｆ”＞。ここで、再生リストＩＤは「７８９０００」で表され、チケットは「ｘｙｚ３２１ａｂｃ」で表され、エンド・ユーザＩＤは「ａｂｃ１２３ｄｅｆ」で表される。

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

ここで、再生リストは、「ｓｔｒｅａｍ１．ａｓｆ」、 「ｓｔｒｅａｍ２．ａｓｆ」、 「ｓｔｒｅａｍ３．ａｓｆ」、と名前の付けられた３つのウィンドウズ・メディア・フォーマット（ウィンドウズは登録商標）のコンテンツ・ファイルを含み、再生リストＩＤは「７８９０００」で表され、エンド・ユーザＩＤは「ａｂｃ１２３ｄｅｆ」で表され、チケットは「ｘｙｚ３２１ａｂｃ」で表される。

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

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

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

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

符号の説明

１０２ エンド・ユーザ・プロセッサ
１０４ メディア・サーバ、
１０６ ウェブ・サーバ、
１０８ ＣＭデータベース
２０４ ストリーミング・テーブル
２０８ 再生リストテーブル
２１０ 再生リスト・ストリーミング・テーブル

Claims (33)

1. １つ以上のメディア・ファイルへのアクセスを管理するためにサーバーによって実行可能な方法であって、
   少なくとも１つのサーバーが、
   (a)前記メディア・ファイルの識別情報及びユーザ識別情報を含むユーザアクセス要求を受信するステップと、
   (b)前記メディア・ファイルの識別情報に関連するプライベート・キー情報を記憶媒体から検索するステップと、
   (c)前記プライベート・キー情報と、前記メディア・ファイルの識別情報と、前記ユーザ識別情報と、第１時間とを、所定の暗号アルゴリズムに提供して第１認証チケットを生成するステップと、
   (d)前記プライベート・キーと、前記メディア・ファイルの識別情報と、前記ユーザ識別情報と、第２時間とを、前記所定の暗号アルゴリズムに提供して第２認証チケットを生成するステップと、
   (e)前記メディア・ファイルへのアクセスを許可するかどうかの判断を可能にするために、前記第１認証チケットと前記第２認証チケットとを比較するステップと、
   を実行する方法。
2. ステップ(c)がおおよそ前記第１時間に起こり、ステップ(d)がおおよそ前記第２時間に起こり、前記第２時間は前記第１時間よりも未来の時間であり、
   前記第１認証チケットと前記第２認証チケットが一致する場合、前記方法は、前記メディア・ファイルへのアクセスを許可するステップをさらに備え、
   前記第１時間と前記第２時間との偏差が所定の量よりも少ない場合に前記第１認証チケットと前記第２認証チケットが一致する、請求項１に記載のサーバーによって実行可能な方法。
3. ステップ(c)がおおよそ前記第１時間に起こり、ステップ(d)がおおよそ前記第２時間に起こり、前記第２時間は前記第１時間よりも未来の時間であり、
   前記第１認証チケットと前記第２認証チケットが一致しない場合、前記方法は、前記メディア・ファイルへのアクセスを拒否するステップをさらに備え、
   前記第１時間と前記第２時間との偏差が所定の量よりも多い場合に前記第１認証チケットと前記第２認証チケットが一致しない、請求項１に記載のサーバーによって実行可能な方法。
4. 前記第１認証チケットは、前記第１時間を或る時間間隔の倍数まで切り下げた値と近似する第１時刻に更に基づき、前記第２認証チケットは、前記第２時間を前記時間間隔の倍数まで切り下げた値と近似する第２時刻に更に基づく、請求項３に記載のサーバーによって実行可能な方法。
5. 前記第１認証チケットおよび前記第２認証チケットが、セキュリティ・キーに更に基づく、請求項１に記載のサーバーによって実行可能な方法。
6. 前記ファイルが再生リストを備え、前記識別子が前記再生リストの識別子である、請求項１に記載のサーバーによって実行可能な方法。
7. 第３時間に基づいて第３認証チケットを生成するステップを更に備え、
   前記メディア・ファイルへのアクセスを許可するかどうかを判断するために、ステップ(ｅ)が、前記第１認証チケットから前記第３認証チケットを比較するステップを更に備える、請求項１に記載のサーバーによって実行可能な方法。
8. 前記第２認証チケットを生成するステップがおおよそ前記第２時間に起こり、前記第２認証チケットは、前記第２時間を或る時間間隔の他の倍数まで切り下げた値と近似する第２時刻に基づき、
   前記第３認証チケットを生成するステップがおおよそ前記第３時間に起こり、前記第３認証チケットは、前記第３時間を前記時間間隔の倍数まで切り下げた値と近似する第３時刻に基づき、前記第３時刻は前記第２時刻よりも過去の時刻である、請求項７に記載のサーバーによって実行可能な方法。
9. 前記第２時間と前記第３時間が同一の時間である、請求項８に記載のサーバーによって実行可能な方法。
10. 前記第２認証チケットを生成するステップがおおよそ前記第２時間に起こり、前記第２認証チケットは、前記第２時間を或る時間間隔の倍数まで切り下げた値と近似する第２時刻に更に基づき、
    前記第３認証チケットを生成するステップがおおよそ前記第３時間に起こり、前記第３認証チケットは、前記第３時間を前記時間間隔の他の倍数まで切り上げた値と近似する第３時刻に更に基づく、請求項７に記載のサーバーによって実行可能な方法。
11. 前記第２時間と前記第３時間が同一の時間である、請求項１０に記載のサーバーによって実行可能な方法。
12. １つ以上のメディア・ファイルへのアクセスを管理するためにサーバーによって実行可能な方法であって、
    少なくとも１つのサーバーが、
    (a)前記メディア・ファイルに対するユーザのリクエストを受信するステップと、
    (b)前記リクエストに含まれている前記メディア・ファイルの識別情報に関連するプライベート・キー情報を記憶媒体から検索するステップと、
    (c)前記プライベート・キー情報と、前記メディア・ファイルの識別情報と、前記ユーザの識別情報と、第１時間とを基に所定の暗号アルゴリズムにより生成された第１認証チケットを受信するステップと、
    (d)前記プライベート・キー情報と、前記メディア・ファイルの識別情報と、前記ユーザの識別情報と、第２時間とを所定の暗号アルゴリズムに提供して第２認証チケットを生成するステップと、
    (e)前記第１認証チケットと前記第２認証チケットとを比較する事によって、前記メディア・ファイルへのアクセスを許可するかどうかを判断するステップと、
    を実行する方法。
13. (e)前記第１認証チケットと前記第２認証チケットが一致しないということに基づいて、前記メディア・ファイルへのアクセスを拒否するステップをさらに備え、
    前記第１時間と前記第２時間との偏差が所定の量である場合に前記第１認証チケットと前記第２認証チケットが一致しない、請求項１２に記載のサーバーによって実行可能な方法。
14. 前記第１認証チケットは、前記第１時間を或る時間間隔の倍数まで切り下げた値と近似する第１時刻に更に基づき、前記第２認証チケットは、前記第２時間を前記時間間隔の前記倍数まで切り下げた値と近似する第２時刻に更に基づく、請求項１２に記載のサーバーによって実行可能な方法。
15. 前記第１認証チケットおよび前記第２認証チケットが、セキュリティ・キーに更に基づく、請求項１２に記載のサーバーによって実行可能な方法。
16. 前記ファイルが再生リストを備え、前記識別子が前記再生リストの識別子である、請求項１２に記載のサーバーによって実行可能な方法。
17. 第３時間に基づいて第３認証チケットを生成するステップを更に備え、
    前記メディア・ファイルへのアクセスを許可するかどうかを判断するために、ステップ（ｅ）が、前記第１認証チケットから前記第３認証チケットを比較するステップを更に備える、請求項１２に記載のサーバーによって実行可能な方法。
18. 前記リクエストがメディア・プレーヤーから受信される、請求項１２に記載のサーバーによって実行可能な方法。
19. 前記第１認証チケットが、ウェブ・サーバによって生成される、請求項１２に記載のサーバーによって実行可能な方法。
20. ステップ（ａ）からステップ（ｅ）までがメディア・サーバによって実行される、請求項１２に記載のサーバーによって実行可能な方法。
21. １以上のメディア・ファイルへのアクセスをエンド・ユーザが受信するために少なくとも１つのサーバーと通信するユーザコンピュータによって実行可能な方法であって、
    前記ユーザコンピュータによって、
    ａ．前記メディア・ファイルへのアクセスをリクエストするステップと、
    ｂ．前記リクエストから得られる前記メディア・ファイルの識別情報に関連するプライベート・キー情報を記憶媒体から検索するステップと、
    ｃ．第１時間に基づく第１認証チケットを、前記プライベート・キー情報と、前記メディア・ファイルの識別情報と、前記エンド・ユーザの識別情報と、おおよそ第１時間の情報とを所定の暗号アルゴリズムで用いることによって生成させるステップと、
    ｄ．第２時間に基づく第２認証チケットを、前記プライベート・キー情報と、前記メディア・ファイルの識別情報と、前記エンド・ユーザの識別情報と、おおよそ第２時間の情報とを所定の暗号アルゴリズムで用いることよって生成させるステップと、
    ｅ．前記第１認証チケットと前記第２認証チケットが一致する場合、前記メディア・ファイルへのアクセスを受信するステップと、
    が実行され、
    前記第１時間と前記第２時間との偏差が所定の量よりも少ない場合に前記第１認証チケットと前記第２認証チケットが一致する、ことを特徴とする方法。
22. ステップ（ｃ）が、ウェブ・ページ上のリンクを起動するステップを備える、請求項２１に記載のコンピュータによって実行可能な方法。
23. ステップ（ｄ）が、メディア・サーバを呼び出すステップを備える、請求項２１に記載のコンピュータによって実行可能な方法。
24. ステップ（ｅ）が、メディア・プレーヤーによって前記メディア・ファイルを受信するステップを更に備える、請求項２１に記載のコンピュータによって実行可能な方法。
25. １つ以上のメディア・ファイルへのアクセスを管理するシステムであって、
    前記リクエストから得られる前記メディア・ファイルの識別情報に関連する、記憶媒体から検索したプライベート・キー情報と、前記プライベート・キー情報と、前記メディア・ファイルの識別情報と、前記ユーザの識別情報と、第１時間とを所定の暗号アルゴリズムに提供して第１認証チケットを生成する第１プロセッサと、
    前記第１プロセッサからは独立し、前記プライベート・キーと、前記メディア・ファイルの識別情報と、前記ユーザ識別情報と、第２時間とを、前記所定の暗号アルゴリズムに提供して第２認証チケットを生成する第２プロセッサと、
    前記第１認証チケットを受信し、前記第１認証チケットと前記第２認証チケットとを比較する事によって、前記メディア・ファイルへのアクセスを許可するかどうかを判断する第３プロセッサと、を備えるシステム。
26. 前記第２プロセッサが前記第３プロセッサである、請求項２５に記載のシステム。
27. 前記第１プロセッサが更に、第１時刻に基づいて前記第１認証チケットを生成し、前記第１時間を或る時間間隔の倍数まで切り下げることによって前記第１時刻を計算し、前記第２プロセッサが更に、第２時刻に基づいて前記第２認証チケットを生成し、前記第２時間を前記時間間隔の前記倍数まで切り下げることによって前記第２時刻を計算する、請求項２５に記載のシステム。
28. 前記第２プロセッサが更に、第３時間に基づいて第３認証チケットを生成し、前記第３プロセッサが更に、第１認証チケットと第３認証チケットを比較する、請求項２５に記載のシステム。
29. 前記第２時間と前記第３時間が同一の時間である、請求項２８に記載のシステム。
30. 前記第２プロセッサが更に、第３時刻に基づいて前記第３認証チケットを生成し、前記第３時間を或る時間間隔の倍数まで切り上げることによって前記第３時刻を計算する、請求項２８に記載のシステム。
31. 前記第１プロセッサおよび前記第２プロセッサが、前記メディア・ファイルの識別子に基づいて前記第１および第２認証チケットをそれぞれ生成する、請求項２５に記載のシステム。
32. 前記第１プロセッサおよび前記第２プロセッサが、セキュリティ・キーに基づいて前記第１および第２認証チケットをそれぞれ生成する、請求項２５に記載のシステム。
33. コンピュータプログラムコードが記録されたコンピュータ読取り可能な記憶媒体であって、前記コンピュータプログラムコードが１つ以上のプロセッサに対し、
    ａ．メディア・ファイルに関連付けられたプライベート・キー情報を記憶媒体から検索し、且つ当該プライベート・キー情報と、前記メディア・ファイルの識別情報と、前記ユーザ識別情報と、第１時間とを所定の暗号アルゴリズムに提供して生成させた第１認証チケットを受信し、
    ｂ．前記プライベート・キー情報と、前記メディア・ファイルの識別情報と、前記ユーザ識別情報と、第２時間とを所定の暗号アルゴリズムに提供して第２認証チケットを生成し、
    ｃ．前記第１認証チケットと前記第２認証チケットとを比較し、
    ｄ．前記第１認証チケットと前記第２認証チケットとの比較に基づいて、前記メディア・ファイルを送信する処理を実行させるためのプログラムを記録したコンピュータ読取り可能な媒体。

Images