JP2004529538A - マルチメディアコンテンツのためのコンテンツの権利および条件の実施 - Google Patents

Abstract

本発明の一実施形態によると、番組の無料のプレビューは、マルチキャスティングシステムにおいてクライアントコンピュータに提供され得る。これは、マルチキャスティングシステムにおける視聴者が、番組コンテンツを注文するかどうかを決定する前に番組の第１の部分を視聴することを可能にし得る。別の実施形態によると、種々の配信方法が番組コンテンツを配信するための暗号化鍵を用いて達成され得る。さらに別の実施形態によると、暗号化鍵の交渉を可能にするように最初の視聴期間が提供され得る。別の実施形態によると、マルチキャスティング環境におけるコンテンツを提供するための規則および条件が利用され得る。
【選択図】図１

Description

【０００１】
（関連出願の相互参照）
本出願は２０００年１０月２６日に出願された米国仮出願６０／２４３，９２５号の利益を主張し、本出願を全目的のために参考として援用する。
【０００２】
本発明は概してマルチキャスティングネットワークの領域に関する。より詳細には本発明はネットワーク上でクライアントに配信された番組のプレビュー部分を提供することに関する。
【０００３】
（背景）
ネットワークを介してユーザに自動ビジュアルコンテンツ等のコンテンツを配信するための種々のシステムがある。１つの例は、ユーザが番組を視聴する前に番組に対して支払うペーパービュープログラミングである。別の例は、予め調整された時間の間に特定のチャンネルに対して、ユーザがプログラミングを受信するためにサービスプロバイダに加入料金を支払う視聴料金に基づいたプログラミングである。例えばＨＢＯ（Ｒ）またはＳＨＯＷＴＩＭＥ（Ｒ）は、ユーザがこれらの番組に対して指定されたチャンネルの任意の番組の放送を受信するために月ぎめ料金を支払う視聴料金に基づいた番組の例である。従って、ユーザはこれらの特定のチャンネルで発生するそれぞれ個々のショーまたはイベントに対して支払を必要としない。むしろ加入料金の支払が全番組を補う。
【０００４】
マルチキャスティングネットワークの進展によって、現在では、映画および音楽等の番組コンテンツがネットワークを介してマルチキャスト転送において配信され得る。例えば、サーバはインターネットを介してクライアントコンピュータに映画をマルチキャストし得る。これは、コンテンツを各クライアントのアドレスに同時に配信することによって達成され得る。しかし、暗号化システムは、このような転送の商品化を容易にする場所において見られない。すなわち、暗号化システムは、ユーザが以後暗号化されユーザに利用不可能になる番組をプレビューすることを可能にする使用において見られない。
【０００５】
結果として、ほとんどのマルチキャスト転送は、番組コンテンツに関心のある既知のクライアントのセットに前もって転送されなければならない。これは、番組コンテンツプロバイダが番組の無料のプレビューを提供することによって、他の関心のある視聴者にその番組を購入する気にさせ得ない点において番組コンテンツのプロバイダへの商業的な利益を低減させる。
【０００６】
（要旨）
本発明の実施形態によると、ネットワークに番組コンテンツを配信するための方法がインプリメントされ得、ネットワークは、番組コンテンツを提供するためのサーバと、ネットワークを介してサーバと通信するために動作可能なクライアントと、番組コンテンツのコピーを格納するために動作可能なキャッシングサーバとを含む。本方法は、クライアントが番組コンテンツを受信する権利が与えられるかどうかを規定する規則を構築するステップと、クライアントがサーバから番組コンテンツをリクエストすることを可能にするステップとを含み得る。本実施形態の種々の他の局面によると、規則は、支払方法、加入料金識別子、番組コンテンツが配信されるべき位置に基づいた制限、またはユーザの年齢に基づいた制限から構成され得る。
【０００７】
本発明の別の実施形態によると、ネットワークにおいて番組コンテンツ配信する方法は、クライアントが番組コンテンツを受信する権利が与えられるかどうかを規定する規則を構築すること、クライアントがサーバから番組コンテンツをリクエストすることを可能にすること、番組コンテンツに対するリクエスト受け取ること、番組コンテンツおよび番組コンテンツに対する規則を識別する識別子を含むデータレコードをフォーマットすることによって提供され得る。
【０００８】
本発明のさらに別の実施形態によると、番組コンテンツおよびネットワークを配信する方法は、クライアントが番組コンテンツに権利が与えられたかどうかを決定する際に使用するために、クライアントについてのデータレコードを受信し、クライアントが番組コンテンツに権利が与えられたかどうかを決定するようにキャッシングサーバによる使用のために番組コンテンツに関連付けられた規則を受信し、そしてクライアントが番組材料に権利が与えられたかどうかを決定するようにデータレコードおよび規則を利用することによって提供され得る。
【０００９】
本発明のさらに別の実施形態によると、番組コンテンツの識別子のための領域および視聴者が番組コンテンツを受信する権限が与えられたかどうかを規定する規則のための領域を規定するデータ構造が提供される。
【００１０】
（特定の実施形態の説明）
図１を参照すると、コンテンツ配信システム１００のブロック図が示される。この実施形態では、コンテンツ配信システム１００は、アクティブディレクトリ１０４、１つ以上のオリジンサーバ１０８、１つ以上のクライアントコンピュータ１１２、１つ以上のコンテンツ交換１１６、１つ以上の外部オリジンサーバ１１８、インターネット１２０等のネットワーク、およびクローリング（ｃｒａｗｌｉｎｇ）ディレクトリ１２４を含む。特定のクライアントコンピュータ１１２は、ダウンロードするためのコンテンツオブジェクトを選択するようにアクティブディレクトリ１０４と相互作用するように示される。オブジェクトは、それがストリーミングメディアである場合にダウンロードする間に再生され得るか、または以後の表示のために格納され得る。コンテンツオブジェクトは、種々のタイプの情報（オーディオ、ビデオ、またはネットワークからダウンロードされるために利用可能なデータ等）であり得る。さらに、この情報は、マルチキャスティングおよび／またはユニキャスティングするために使用され得る。
【００１１】
いくつかの実施形態では、オリジンサーバ１０８は、コンテンツオブジェクトをダウンロードするためにクライアントコンピュータに指示するように好適なソースを決定する。クライアントコンピュータ１１２の優先度およびコンテンツオブジェクトのコピーの位置は、オリジンサーバ１０８が情報の好適なソースにクライアントコンピュータに再指示する際に使用し得る全ての考慮である。このソースはオリジンサーバ１０８自体であってもよいし、コンテンツ交換１１６の内の１つであってもよい。
【００１２】
外部オリジンサーバ１１８のコンテンツオブジェクトは、１以上の割り当てられたコンテンツ交換に予めロードされ、これらのコンテンツオブジェクトを提供し得る。コンテンツオブジェクトが初めてリクエストされた場合の遅延を低減するためには、アクティブディレクトリ１０４は、外部オリジンサーバ１１８を呼び出して、外部オリジンサーバ１１８から利用可能なコンテンツオブジェクトを決定し得る。この利用可能なコンテンツオブジェクトは、クローリングディレクトリ１２４に追加され得る。一旦、利用可能なコンテンツオブジェクトが知られると、アクティブディレクトリ１０４は、１以上の関連付けられたコンテンツ交換上に各コンテンツオブジェクトのロードを引き起こすように１以上の関連付けられたコンテンツ交換から各コンテンツオブジェクトをリクエストし得る。このように、コンテンツオブジェクトは、関連付けられたコンテンツ交換上で予めロードされ得る。
【００１３】
図２は、図１の個々のシステム構成要素が、どのようにして種々の、一般的に同様に構成された処理システムにおいて分離された態様または統合された態様でインプリメントされ得るかを広範に示す。システム２００は、プロセッサ２０１、入力デバイス２０２、出力デバイス２０３、格納デバイス２０４、コンピュータ読み出し可能な格納メディア読み出し器２０５ａ、通信システム２０６、処理アクセレーション（例えばＤＳＰまたは特殊プロセッサ）２０７、およびメモリ２０９を含む、バス２０８を介して電気的に接続されるハードウエア構成要素から構成されることが示される。コンピュータ読み出し可能な格納メディア読み出し器２０５ａは、さらにコンピュータ読み出し可能な格納メディア読み出し器２０５ｂに接続される。これらの組み合わせは、一時的および／またはより永久的にコンピュータ読み出し可能情報を含むための、格納メディア、メモリ等を加えた、リモート、ローカル、固定、および／または除去可能な格納デバイスを理解可能に表す。これらの組み合わせは、格納デバイス２０４、メモリ２０９、および／またはこのような任意の他のアクセス可能なシステム２００リソース等を含んでもよい。またシステム２００は、プログラム、アプレット、データ等の、オペレーティングシステム２９２および他のコード２９３を含むソフトウエア構成要素（作動メモリ２９１内に現在配置されたように示される）を含む。
【００１４】
システム２００は、その拡張可能なフレキシビリティおよび構成可能性に二者択一的に大きく起因して、インプリメンテーションとして望ましい。従って、例えば、単一のアークテクチャが、現在望ましいプロトコル、プロトコル改変、拡張等に従ってさらに構成され得る１以上のサービスをインプリメントするために利用され得る。しかし、実質的な改変がより多くの特定のアプリケーション要求に従って利用され得ることが当業者に明らかである。例えば、１以上の構成要素がシステム２００コンポーネント内で（例えば通信システム２０６内で）サブ構成要素としてインプリメントされ得る。またカスタマイズされたハードウエアが利用され得、および／または特定の構成要素がハードウエア、ソフトウエア（アプレット等のいわゆる「ポータブルソフトウエア」を含む）、またはその両方においてインプリメントされ得る。さらにネットワーク入力／出力デバイス（図示せず）等の他の計算デバイスへの接続が利用されるが、ワイヤード、ワイヤレス、モデム、および／または他の接続または他の計算デバイスへの接続が利用され得ることが理解される。配信プロセス、多重サイトビューイング、情報転送、コラボレーション、リモート情報取り出し、マージ、および関連した能力がそれぞれ企図される。オペレーティングシステムはまた、特定のホストデバイスおよび／またはプロセスタイプ（例えばコンピュータ、アプライアンス、ポータブルデバイス等）に応じて変更するが、恐らく全てのシステム２００のコンポーネントが全ての場合において必要とされるわけではない。
【００１５】
図１のネットワークは、種々の方法でインプリメントされ得る。例えば、一実施形態によると、ユーザデータグラムプロトコル（ＵＤＰ）の使用を想定し得る。ユーザデータグラムプロトコルは、「リアルタイム転送プロトコル」／「リアルタイム制御プロトコル」（ＲＴＰ／ＲＴＣＰ）、「インターネットグループ管理プロトコル」（ＩＧＭＰ）、「リアルタイムストリーミングプロトコル」（ＲＴＳＰ）、および恐らく「セッション通知プロトコル」／「セッション記述プロトコル」（ＳＡＰ／ＳＤＰ）を搬送し得る。さらに、マルチキャストアドレシングの目的のために、マルチキャストＩＰアドレス割り当ておよび指定が任意のインターネットプロトコル権利管理システムに対して明らかであることが想定され得る。このセッション記述は、ＳＡＰプロトコル、ＲＴＳＰ ＡＮＮＯＵＮＣＥコマンド、またはＨＴＴＰのいずれかを使用することによって配信され得る。あるいは、ビジネスモデルとして、ペイパービュー、加入支払（ｓｕｂｓｃｒｉｐｔｉｏｎ）、および時間単位の支払が全ての望ましい購入オプションであることが想定され得る。さらに、ＴＶのようなチャネルサーフィンは、放送のようなマルチキャスト配信の予測されたユーザ経験であることが想定される。
【００１６】
本特許において使用された以下の用語が下記のように理解され得る。
【００１７】
コンテンツプロバイダ−例えばコンテンツを消費する必要がない間にキャッシングサーバにコンテンツを配信するエンティティである。
【００１８】
消費者−キャッシングサーバから得られたコンテンツを消費し、システムにおいてコンテンツを他の消費者に選択的に再配信するエンティティである。消費者、キャッシングサーバ、およびコンテンツプロバイダの役割は、許可された挙動および移動によって関連されたコンテンツソースおよびシンクのマトリクスとして視聴され得る。
【００１９】
番組−開始および終了を有する特別に識別されたコンテンツの一部である。
【００２０】
サービス−同じストリーム上の番組の連続的な収集である。
【００２１】
進行中の番組−特に規定された開始および終了を有さない番組である。視聴者は通常任意の時間に参加および中断する。これは「ホームショッピング」、「ファッションショー」、「進行中のスポーツコンテンツ」等に適する。
【００２２】
購入オプション−クライアントがコンテンツを購入することを可能にするメカニズムである。
【００２３】
加入支払−クライアントが登録し、実質的に前もってコンテンツに対して恐らく支払う購入メカニズムである。典型的には、クライアントは、１よりも多い番組（例えば全体のサービス）に対して権限を獲得する。単一の番組のみに権限が与えられても、呼び出し前の（Ｃａｌｌ−ａｈｅａｄ）ＰＰＶとして公知である。
【００２４】
ペイパービュー（ＰＰＶ）−クライアントが登録し、一回で単一の番組またはパッケージに対して支払う購入メカニズムである。このメカニズムは、ネットワークによって可能にされるかまたはローカルに可能にされ得る。ネットワークによって可能にされた場合では、一旦購入が望まれると、クライアントはインフラストラクチャと契約し、インフラストラクチャは購入を可能にする。このアプローチは、しばしば番組の前にピーク要求によるスケーリングの問題を有する。ローカルに可能にされた場合では、しばしば「ＩＰＰＶ」または「インパルス」ＰＰＶと呼ばれ、クライアント自体は、ローカルに購入させ、購入のレコードを格納する。いくらか遅れた時に、レコードは請求のためにインフラストラクチャシステムに報告される。イベントがマルチキャストされている場合、例えば番組が開始する前にネットワークをヒットする要求のスパイクがない場合、このアプローチは有効である。あるいはローカルにイネーブルされた場合では、ネットワーク遅延またはネットワーク交換遅延がないので、クライアントはコンテンツを速やかに視聴し得る。いずれの場合においても、ＰＰＶ購入は典型的には、どれぐらいの人が実際見ているかに関わらず全体の番組のためにある。
【００２５】
時間単位の支払（ＰＢＴ）−実際に見ていたコンテンツの継続時間に対してクライアントが支払う購入メカニズムである。離散時間増加は、異なる番組またはサービスの異なる継続時間を有し得る。ＰＢＴは、視聴者が認識した値の損失なしでランダムなアクセスを許容し得る番組およびサービスの小さいセットに限定される。いくつかのスポーツイベントおよび音楽イベントがこのタイプである。
【００２６】
品位単位の支払（ＰＢＱ）−コンテンツは、分離されたストリームまたは品位をコンテンツに追加する各さらなる層を有する層状化されたストリームのいずれかとして、異なる品位（すなわちビットレート）で提供され得る。クライアントは、クライアントが消費し得る最高のビットレートを報告し得、その品位以下でコンテンツを購入するように提示され得る。サーバはまた、ネットワークの中間状態に基づいて実時間でレートを調整し得る。一時的なネットワークの輻輳が検出され、コンテンツの品位は所定の期間の間低減され、次いで公示された品位を再開し得る。サーバはこのような発生を追跡し、これを請求書センターに報告し、それによりユーザに元の価格未満を請求し得る。さらにクライアントは、ユーザ選択に従ってユーザによって認識されたビットレートを調整し得る。例えばサムネイル番組はユーザに対して価値を有するが、そのコストが全画面（居間の視聴可能な番組）に等しい場合、価値を有さない。
【００２７】
購入のタイミング−クライアントが異なる時間でコンテンツを購入し得る。
【００２８】
前もって−クライアントは、有意に前もってコンテンツを購入することを決定する。このような番組は、単一の番組ではなく、加入支払等の全体のサービスに関連付けられ得る。
【００２９】
番組の直前または番組中−クライアントはコンテンツの開始前またはコンテンツの開始直近において短い期間でコンテンツを購入することを決定する。
【００３０】
ビデオオンデマンド−ＶＯＤは、格納されたコンテンツの個々の選択に基づいてストリームを単一の消費者に提供するポイントツーポイント送達システムである。この消費者は、「停止」、「早送り」、および「巻戻し」としてこのような機能を呼び出し、即時必要性に対する視聴経験を調整し得る。
【００３１】
マルチキャスト−マルチキャストは既存のＴＶ放送と同様である。マルチキャストは１以上の消費者に同時に同一のコンテンツを送達する。これは通常スケジューリングされ、生中継のコンテンツであってもよい。
【００３２】
無料プレビュー−無料プレビューは、消費者がコンテンツに対して支払わなければならない前に小さい部分（例えば数分）を見ることを可能にするメカニズムである。これはユーザをコンテンツに引き付けるために使用される。別の使用は、消費者のほとんどがコンテンツに登録される場合、ＰＰＶイベントの開始等の高サーバトラフィックのスムースアウト（ｓｍｏｏｔｈ ｏｕｔ）期間を使用することである。消費者の資格認定が検査される間、消費者は見ることを許可され得る（無料のプレビュー期間が終了した後またはプレビューがない場合、前もって登録されたクライアントに公知の分離グループの鍵を利用することによって高いサーバトラフィックのさらなるスムースアウト期間を可能である）。この無料のプレビューは、より低い品位で提示され得る。
【００３３】
元のコンテンツサーバ（ＯＣＳ）−コンテンツを例えばキャッシングサーバに提供するコンテンツプロバイダのコンピュータにおけるサーバである。
【００３４】
（購入モデル）
コンテンツモデルのポイントツーポイントＶＯＤ送達において、購入オプションは比較的簡単である。なぜなら、コンテンツ（イベント）の各部分は、別個に交渉されるからである。従って、ペイパービューモデルはポイントツーポイントＶＯＤ送達に適している。さらに消費者サーバ通信は、典型的には２方向接続であるため、コンテンツへのアクセスの交渉のための主要メカニズムは、コンテンツが視聴される前に行われる（従来のシステムにおいて使用されたＩＰＰＶメカニズムを格納および転送することに対して）。
【００３５】
マルチキャストモデルは、（１）消費者の優先度、（２）コンテンツの性質、または（３）コンテンツが公示される方法に基づいてコンテンツを販売する異なるメカニズムを提供する。
【００３６】
（ペイパービュー）
マルチキャストモデルのペイパービュー（ＰＰＶ）は、クライアントが単一のイベントを購入する点でポイントツーポイントＶＯＤモデルと同様であり得る。１つの差は、イベントが一度暗号化され、複数のクライアントによって共有されることである。従って、ユーザのコンピュータおよびキャッシングサーバは、ユーザごとの固有のコンテンツ復号キーについて交渉しない。
【００３７】
別の差は、同じイベントへのアクセスを同時に（イベントの開始）リクエストする多数のクライアントが存在することである。これは、比較的小さい時間ウインドウ内のシステム上に大きな負荷を生成する。拡張性を可能にするために、無料のプレビュー期間を設定し、コンテンツ暗号鍵を全ての参加者に配信する十分な時間をキャッシングサーバに提供し得る。
【００３８】
以下の例は、ペイパービューモデルインプリメンテーションの実施形態を示す。このＰＰＶシナリオは、ユーザが、どのコンテンツを入手しそしていつコンテンツを入手するかを決定する「コンテンツオンデマンド」ケースと同様である。元のコンテンツサーバ（ＯＣＳ）はクライアントが加入支払されていないことを検出する場合、元のクライアントは、購入オプションおよび他のコンテンツアクセス規則および制限のセットによってクライアントをガイドする。一旦、クライアントが購入オプションを選択すると、クライアントは安全なオブジェクトに含まれる。この安全なオブジェクトはまた、所与のコンテンツの部分に関連付けられた規則の全てまたはサブセットを含み得る。
【００３９】
クライアントは、安全なオブジェクトおよびチケットをその受給データ（例えば加入支払サービスのリスト、位置、コンテンツに対する支払能力等）と共にキャッシングサーバに送達する。このキャッシングサーバは、安全なオブジェクトおよびクライアントによって提示されたチケットを調査して、安全なオブジェクトからのクライアント選択およびチケットからの受給情報からのクライアント選択がコンテンツアクセス規則に適合するかどうかを決定する。全ての規則が満足される場合、キャッシングサーバはコンテンツ暗号鍵を番組鍵を介して送達することによってリクエストされたコンテンツへのアクセスを許可する。例えば、番組鍵は、固有の鍵を用いてクライアントに送達されつつ、コンテンツ鍵は番組鍵によって暗号化される。
【００４０】
（加入支払）
一実施形態では、比較的多数（数千または数万）のビデオオンデマンドサーバおよび、マルチキャストコンテンツを提示する比較的少数（数百、恐らく数千）のサーバが存在することが想定され得る。加入支払モデルは、ほとんどの時間で利用可能なコンテンツの連続的なストリームであり、および消費者がそのモデルに戻る場合に意味がある。
【００４１】
視聴者がサービスについて加入支払する場合、視聴者がそのサービスにアクセスする初回に視聴者は、単一の番組イベントに割り当てられる番組鍵より長い寿命を有するサービス鍵が与えられ得る。この鍵によって、視聴者はサービスに戻り、任意の新しい鍵と交渉することなくコンテンツを見得る。これは、ＴＶチャンネルサーフィンの経験を作成するのに役立つ。
【００４２】
このようなモデルのための関連した実施形態の１つの目的は、キャッシングサーバがどれくらいの数のクライアントおよびいつクライアントが実際にコンテンツを見たかを追跡することである。アカウントする目的のために、消費者の所定の集団が、消費者が地上テレビのＮｉｅｌｓｅｎ視聴トラッキングと類似のこのようなサービス等に訪れる度に、サーバと契約するようにリクエストされる場合、これらの消費者のコンピュータは、サービス鍵が与えられるのではなく、新しい番組鍵のみが与えられ得る。これは、チケットに含まれた構成または加入支払オプションである。
【００４３】
加入支払モデルはまた、ビデオレンタルのための一律の月の割合としてポイントツーポイントＶＯＤシナリオについて意味があり得ることに留意すること。
【００４４】
以下の例は、加入支払モデルインプリメンテーションの一実施形態を示す。オリジンコンテンツサーバ（ＯＣＳ）が配信ネットワークの一部となる場合、サーバがＶＯＤコンテンツまたはマルチキャストコンテンツを提供するかどうかを示す。加入支払に対するオプションが提供される場合、提供センタは１以上のサービスＩＤをＯＣＳに割り当てる。
【００４５】
クライアント／消費者がこのサービスに加入支払することを望む場合、クレジットカード番号または任意の他の適切な支払方法を提供することが要求され、例えばＫｅｒｂｅｒｏｓ環境において、サーバチケットは、加入支払されたサービスおよび他の認証データ（認証、支払能力など）のリストを用いて更新される。
【００４６】
クライアント／消費者がＯＣＳとの接続を開始した場合、以下の情報を提供する。すなわち、固有の消費者識別子、購入能力（クレジットカード番号がレコード上ににあり、検証される指示）および加入支払されるサービスのリストである。ＯＣＳが支払コンテンツを提供している場合、ＯＣＳは第１にクライアント／消費者がコンテンツに対する支払が可能であるかどうかをチェックする。コンテンツが加入支払ベースで利用可能である場合、加入支払されたサービスのリストは、１つ以上のＯＣＳのサービスＩＤに対してチェックされる。ＯＣＳがリスト上にある場合、購入メニューが迂回され、クライアントは適切なキャッシングサーバに再指示される。クライアントがサービスについて加入支払されていない場合、購入オプションに提示される。両方の場合では、ＯＣＳは、ＯＣＳサービスＩＤ、ソースＩＤ、選択された購入方法（例えば、加入支払、ＰＰＶ、ＰＢＴ等）およびサービスが無料であるかまたは有料のコンテンツであるかどうかの支持、ならびに他のアクセス規則を含み得る安全なオブジェクトを生成する。
【００４７】
クライアント／消費者が選択されたコンテンツを提供し得るキャッシングサーバに接続される場合、キャッシングサーバチケットを提示する。キャッシングサーバチケットは、クライアントのアイデンティティ、購入能力およびＯＣＳから入手された安全なオブジェクトと共に加入されたサービスのリストに関する情報を含む。クライアントは、ＯＣＳからのチケットまたは安全なオブジェクトのいずれかを読み出しまたは変更し得ないことに留意すること。
【００４８】
キャッシングサーバは安全なオブジェクトおよびチケットからの情報を比較する。情報が整合する場合、クライアントはコンテンツへのアクセスが許可される（コンテンツ暗号鍵が与えられた場合、この場合サービス鍵を利用して直接的または間接的に送達される）。情報が整合していなければ、コンテンツへのアクセスは、拒否される。キャッシングサーバはまた、使用において選択された購入オプションおよび請求サービスに送達された請求データを報告する。
【００４９】
クライアントは安全なオブジェクトおよびサービス鍵をキャッシュし得、その結果、サービスを中断し後で戻る場合、ＯＣＳまたはキャッシングサーバと再度契約する必要がない（ユーザに明らかであるが獲得時間に遅延を与える）。
【００５０】
加入支払モードは、サービス鍵を用いることなく以下に説明されるＰＰＶモードによってシミュレートされ得ることに留意すること。キャッシングサーバまたは請求システムは、このクライアントが加入者であり、それによりこのサービスについての個々のイベントに対する請求を行わないことを検出する。
【００５１】
（時間単位の支払）
時間単位の支払（ＰＢＴ）は、ファッションショー、または継続中のスポーツイベント（例えばオリンピック）等の良好に規定された開始時間または終了時間、あるいは内蔵型プロットを有しないコンテンツに対して適する。
【００５２】
本発明のいくつかの既存の代替は、消費者がグループを出る場合に、階層のサブツリーに再び鍵をかけるための鍵およびアルゴリズムのツリー階層に基づく。これらの既存の代替は、グループを出る消費者の頻度が比較的低く、時間をかけて十分に分配される場合に限り、多くのマルチキャストグループを処理し得る。一方で、本発明の一実施形態は、マルチキャストを出ようとする複数の消費者の大きなピークを処理するように設計される。
【００５３】
準ＰＢＴアプローチのために、キャッシングサーバは、コンテンツを支払いセグメントに分割し、セグメント鍵を支払いセグメントに割り当て得る。全ての消費者は、どれくらいの数のセグメントを見たかについて追跡するために各セグメントに対する鍵と交渉する。これは、セグメント境界上のキャッシングサーバ上の大きい負荷を生成する。これは、各ラビット（ｒａｂｂｉｔ）が現在のセグメントおよび次のセグメントに鍵が与えられる鍵管理アプローチを用いて緩和され得る。これは、現在のセグメント中に次のセグメント鍵を配信するのに十分な時間をキャッシングサーバに与える。
【００５４】
以下の例は、時間単位のモデルインプリメンテーションの実施形態を示す。いくつかのコンテンツはＰＰＶとして販売されるのに適し得ない。一例は、十分に定義された開始および終了、あるいは特定のプロットを有しないコンテンツである。これは、ファッションショー、所定のタイプのスポーツイベント等のコンテンツを含み得る。視聴者がＯＣＳと購入オプションを交渉する時点で、視聴者は、申し込まれた場合、時間単位のオプションを選択するように選択し得る。視聴者は支払期間が何であるか、および各支払期間のコストが何であるかが説明される。視聴者の選択は安全なオブジェクトに含まれる。
【００５５】
クライアントがキャッシングサーバと暗号鍵について交渉する場合、クライアントはマルチキャストコンテンツの受信を開始する。クライアントは、各支払期間に対して終了時間をモニタリングし、キャッシングサーバから新しいセットの鍵をリクエストする。視聴者が見るのをやめるかまたは別のサービスに移動すると、クライアントは新しい鍵を要求しないか、または現在のマルチキャストセッションを出ることを望むことをキャッシングサーバにアクティブに通知する。キャッシングサーバは、各クライアントが請求目的のためにマルチキャストに参加および中断する時間を記録する。
【００５６】
（無料のプレビュー）
本発明の一実施形態では、番組の無料のプレビューがマルチキャスティングシステムにおけるクライアントコンピュータに提供され得る。図３を参照すると、本発明の本実施形態をインプリメントするためのフローチャート３００が理解され得る。ブロック３０４では、暗号化された材料がクライアントへの配信のために提供される。例えば、このような暗号化された材料は、メトロポリタンビデオ交換またはコンテンツが発生するオリジンサーバ等のコンテンツ交換によって提供され得る。ブロック３０８では、例えば暗号化された番組材料の第１の部分を復号化する際のクライアントコンピュータによる使用のために提供中に、前もって鍵が提供される。方法３００のブロック３１２では、暗号化された番組材料の第１の部分が少なくとも１つのクライアントに配信される。最終的に、ブロック３１６では、クライアントは、番組の無料のプレビュー部分を入手するために提供された鍵を使用することが可能にされる。従って、番組が異なる鍵を用いて暗号化されるまでクライアントは番組材料を復号化し、料金なしで番組のプレビューを入手することができる。
【００５７】
従って、サービスプロバイダは、ユーザが所定量の時間の間の暗号化鍵の変更を待つことによって番組材料の第１の部分を獲得することを可能にし得る。これは、ユーザが暗号鍵の使用によってプレビューを視聴することを可能にする。
【００５８】
図４は、本発明のさらに別の実施形態を示す。図４のフローチャート４００では、無料のプレビュー鍵がブロック４２０に示されたクライアントに前もって（例えば、提供中に）提供される。ブロック４０４では、暗号化された材料がクライアントへの配信のために提供される。ブロック４０８では、コンテンツ鍵が提供される。コンテンツ鍵はブロック４１２に示されるように無料のプレビュー鍵を用いて暗号化される。次いでこの暗号化されたコンテンツ鍵は、ブロック４１６によって示されるように複数のクライアントに提供される。次いで、クライアントは、クライアントにおける無料のプレビュー鍵を利用して、ブロック４２４に示されるように暗号化されたコンテンツを復号化し得る。暗号化された番組材料の第１の部分は、ブロック４２８に示されたように複数のクライアントに配信され得る。次いでクライアントはコンテンツ鍵を利用して暗号化された番組コンテンツを復号化し、それによりブロック４３６に示されたように番組コンテンツの無料のプレビューを獲得し得る。このプロセスの間、ユーザが番組材料４４０を購入する申し込みによって、画面上のディスプレイを介して促進され得る。この時点において、ユーザは、ユーザインターフェイスを介して申し込みの受け取りを示し得、これによって、番組コンテンツを購入する。この時点で、新しい鍵は、残っている番組の暗号化された部分を復号化する際に使用するためにユーザに配信され得る。
【００５９】
あるいは、無料プレビュー鍵（ＦＰＫ）を用いて暗号化されたコンテンツ鍵を送達する代わりに、ＦＰＫを使用してコンテンツの最初の部分を直接暗号化し得る。この場合、最初のコンテンツ鍵はＦＰＫの値と同じである。
【００６０】
さらに別の代替は、ＦＰＫを用いて暗号化される番組セグメント鍵（ＰＳＫ）を配信することである。次いでＰＳＫを利用して、ＰＳＫを用いて暗号化されたコンテンツ鍵を配信する。
【００６１】
本特許において記載された種々の実施形態が、例えば番組マルチキャストの間に繰り返される作用によって達成され得ることが理解されるべきである。従って、図４では、ブロック４１２および４２８は一回以上繰り返され得る。同様に、説明された、いくつかの作用が同時に起こりうることが理解されるべきである。再度、例えば、ブロック４１２および４１８は同時に発生し得る。さらに、いくつかの例は簡略さのためにサーバとクライアントとの間の関係を説明し得るが、より多いクライアントが参加し得ることが理解されるべきである。
【００６２】
図５を参照すると、本発明のさらに別の実施形態が示される。図５の方法５００では、番組材料はブロック５０４に示されるように配信のためにまず提供される。番組材料の第１の部分は、ネットワークを介してブロック５０８に示されるようにクライアントコンピュータに配信される。ブロック５１２では、ユーザは残っている番組コンテンツを購入するように可能にされる。番組材料の第１の部分が暗号化されないが番組の残りの部分がブロック５１６に示されるように暗号化される。従って鍵が例えばサーバにおいて提供され得、この番組の残りの部分を暗号化する。ブロック５２０では、番組の残りの部分が、残りのクライアントコンピュータが適切な暗号化ツールなしで番組の暗号化された残りの部分を受信または視聴できることを妨げるように、ブロック５１２において残りの番組コンテンツをリクエストしたクライアントコンピュータに配信される。従って、ユーザは番組材料の暗号化された部分を復号化するように動作可能である鍵を用いて提供され得る。これは、残りの部分が暗号化されつつ最初の番組材料が暗号化なしで配信されるという点で無料のプレビューを提供するさらに別の方法である。従って、クライアントコンピュータは番組材料の元の部分を自由に視聴するために復号化鍵を必要としない。従って、ユーザは、番組材料の最初の部分を視聴し、番組の残りの部分を購入するか否かを自由に決定する。
【００６３】
図６は、本発明のさらに別の実施形態を示す。図６の方法６００では、ブロック６０４において、複数のクライアントコンピュータと通信するためにサーバが設けられる、このサーバは、ブロック６０８に示されるように、複数のクライアントコンピュータにコンテンツ材料の番組を提供するように構成される。例えば、マルチキャスティング構成がインプリメントされ得る。ブロック６１２では、番組の無料プレビュー部分がクライアントコンピュータによる視聴のために提供される。クライアントが無料のプレビュー期間の終了のためにコンテンツの残りを購入することを選択すると仮定する。サーバと通信し、映画を復号化するために必要な鍵を受信するのに十分な時間がない可能性があり、このため視聴されたコンテンツが停止し、次いでこのような鍵が到達した後しばらくして再開する。本発明の最初の視聴期間の概念は、サーバの鍵配信の遅延にもかかわらず連続的な視聴を可能にする方法を提供する。ブロック６２０は、最初の視聴期間が所定の数のクライアントが番組の暗号化された部分を復号化するための鍵を受信することを可能にするのに十分な期間で提供され得ることを示す。
【００６４】
図７Ａは、番組のためのリクエスト数対番組継続時間を示すプロットを示す。図７Ａに示されるように、最初の無料プレビュー期間はクライアントコンピュータが番組の暗号化された部分を視聴するための最初の鍵をリクエストすることを提供する。このリクエスト数は、無料のプレビュー期間では高く、次いで残りの番組継続の間降下する。従って、無料のプレビュー番組期間は、システムが番組の最初の視聴の間、鍵に対するリクエストに適応することを可能にする。
【００６５】
図７Ａの底部では、コンテンツ鍵０、１、および２の配信が示される。コンテンツ鍵０は、無料のプレビューを入手するために一実施形態においてユーザに提供される。コンテンツ鍵１および２は、２つの鍵のみが番組コンテンツの残りを暗号化するために要求される場合の例を示す。
【００６６】
例として、鍵０は、周知の無料のプレビュー鍵、無料のプレビュー鍵によって暗号化されたコンテンツ暗号鍵であり得、またはコンテンツは、無料のプレビュー期間の間に全く暗号化されないかもしれない。鍵１は、グループ鍵自体または最初の視聴期間で使用されたグループ鍵によって暗号化されたコンテンツ暗号鍵を表す（後者の場合、ブロック６１６は暗号化されたコンテンツ鍵をクライアントにマルチキャストするように機能する）。そして鍵２は、コンテンツを購入したクライアントにのみ送達された実際のコンテンツ暗号化鍵である。従って、まずコンテンツに調整するクライアントが無料のプレビューを視聴して、購買する決定を行う。このようなリクエストを行う者がグループ鍵を使用して、視聴経験が継続することを可能にする。サーバは、この期間で鍵２を送達し、その結果視聴者が連続的な態様でコンテンツの残りの視聴を継続する。最初の視聴期間の概念は、番組が提供された無料プレビューを有するか否かを適用することに留意すること。
【００６７】
（鍵配信）
時間単位の支払、ペイパービュー、加入支払ベース等の種々の配信方法において、暗号鍵は番組コンテンツの受領を容易にするようにクライアントに配信され得る。本発明の一実施形態では、多重階段状鍵階層を提供して、ペイパービューまたは時間単位の支払等の種々の購入オプションに適応させる。本発明の一実施形態では、鍵の異なるタイプおよびその関係が以下のように構成される。
【００６８】
固有の鍵（ＵＫ）：例えば、チケットリクエストメッセージ交換の間にＫｅｒｂｅｒｏｓ鍵分配センター（ＫＤＣ）によって、Ｋｅｒｂｅｒｏｓ環境においてクライアントに与えられたセッション鍵であり得る。この鍵は視聴者およびセッションごとに固有である。クライアントは複数のＵＫ（各キャッシングサーバの１つ）のリストを維持する。各ＵＫは、特定のキャッシングサーバとの鍵リクエストメッセージ交換を開始するために使用される。ＵＫは、暗号化されたコンテンツ鍵（ＣＫ）、サービス鍵（ＳＫ）、番組鍵（ＰＫ）、または番組セグメント鍵（ＰＳＫ）を送達するために利用され得る。
【００６９】
サービス鍵（ＳＫ）：この鍵は、１以上の番組エポックに広がり、数日〜数ヶ月の継続時間を有する加入支払鍵として使用される。この鍵はこのサービスの加入者全てによって共有されるが、キャッシングサーバ間では異なり得る。クライアントが特定のキャッシングサーバからリクエストされたサービスに対して加入支払される場合、最初にキャッシングサーバがクライアントによってアクセスされると、鍵リクエストメッセージ交換がクライアントのＵＫを用いて暗号化される間にＳＫがクライアントに与えられる。一旦クライアントが鍵を有すると、クライアントは、ＳＫが終了するまでこのサービスのコンテンツを復号化し得る。その時（または好適にはサーバの過負荷を回避するために前もってさらに十分適切に）クライアントはキャッシングサーバからのＳＫの次のバージョンをリクエストする。
【００７０】
この機構は、加入支払を有するクライアントがキャッシングサーバと鍵について交渉することなくサービスを速やかに獲得することを可能にし、それによりキャッシングサーバの負荷を低減する。これはコンテンツ暗号化鍵、番組セグメント鍵、および番組鍵がしばしば配信されることを想定する。
【００７１】
番組鍵（ＰＫ）：この鍵は１つの番組エポックに対して価値がある。ペイパービューオプションを用いて購入された個々の番組イベントへのアクセスを与えるために使用される。ＳＫと同様に、鍵リクエストメッセージ交換の間クライアントに鍵が与えられる。またこのＰＫはＳＫによって暗号化され、ＳＫを所有する全てのクライアントに配信され得る。
【００７２】
番組セグメント鍵（ＰＳＫ）：この鍵は、単一の番組イベントまたは全体のサービスを購入可能なセグメントに分割するために用いられる。このＰＳＫは、単一キャストまたはマルチキャスト配信のいずれかを用いて配信される。ペイパービュー購入オプションを使用するクライアントは鍵リクエストメッセージ交換を用いてＰＳＫを獲得する。ＰＰＶ購入オプションを用いるクライアントは、マルチキャスト配信を用いるＰＫにおいて暗号化されたＰＳＫを受信する。加入支払を有するクライアントは、マルチキャスト配信を用いてＳＫまたはＰＫにおいて暗号化されたＰＳＫを受信し得る（あるいは、加入支払を有するクライアントは、ＳＫにおいて直接暗号化されたＣＫを受信し得る）。
【００７３】
これらのセグメントは拡張性を助けるためにオーバーラップし得る。２つのＰＳＫ（現在のＰＳＫおよび次のＰＳＫ）は任意の所与の時間に配信される。これはクライアントがコンテンツの受信しながらキャッシングサーバからのＰＳＫの次にセットをリクエストすることを継続することを可能にする。
【００７４】
コンテンツ鍵（ＣＫ）：この鍵は、コンテンツ自体を暗号化するために使用される。ＰＳＫと少なくとも同じ頻度で変更されるべきである。この鍵は、いくつかの方法によって配信され得る。例えば、その方法は、（１）時間単位の支払いオプションを選択する視聴者のためのＰＳＫによって暗号化される、（２）ＰＰＶオプションを選択するユーザのためのＰＫまたはＵＫによって暗号化される、または（３）サービスに対して加入支払する者のためのＳＫによって暗号化されることである。
【００７５】
グループ鍵（ＧＫ）：この鍵はＣＫまたはＰＳＫを配信するために使用され、次いで、最初の視聴期間でＣＫを暗号化する。クライアントは、例えば提供中にＰＰＶまたはＰＢＴベースの販売された番組イベントの前にＧＫを獲得する。これは、コンテンツの開始を見ながらクライアントが１つ以上の他の鍵についてキャッシングサーバと交渉するオプションを視聴者に与える。
【００７６】
無料のプレビュー鍵（ＦＰＫ）：この鍵は、ＣＫまたはＰＳＫを配信するために使用され、次いでこの鍵は最初の無料プレビュー期間のコンテンツに対してＣＫを暗号化する。これは、全クライアントに公知のまたは提供の間に配信された固定された鍵であり得る。
【００７７】
表１は、種々の鍵をクライアントに配信するための本発明の種々の実施形態を示す。表１に示されるように、ＵＫを用いて個々のクライアントに配信された唯一の鍵（ＵＫによって暗号化された鍵として示される）が単一キャスト方式で送達される。これらのユニットにアドレスされたメッセージは、受給管理メッセージ（ＥＭＭ）機能を満たす。あるいは、改良された効率に対して異なるＵＫを用いて暗号化された複数のＥＭＭは、単一のマルチキャストメッセージに組み合わせられ得る。他の鍵が認定されたクライアントおよびマルチキャストのグループに対して一回のみ暗号化され得る。なぜなら、これらの鍵はより高いレベルの鍵を所有するクライアントによってのみ復号化され得るからである。これらのグループにアドレスされたマルチキャストメッセージは、受給制御メッセージ（ＥＣＭ）のメッセージの役割を果たす。
【００７８】
【表１】

本発明の異なる実施形態は、上記で概説された鍵を配信するためのモデルを提供する。例えば、「プル」モデル、「プッシュ」モデル、および組み合わせ「プッシュ−プル」モデルが利用され得る。プルモデルにおいて、各クライアントは、鍵およびその満了時間を追跡し、サービスの中断を回避するために、現在の鍵が満了する前に新しい鍵をアクティブにリクエストする。あるいは、プッシュモデルは、アクティブなクライアントを追跡するサーバに対する責任を移動し、現在の鍵が満了する前に、新しい鍵をアクティブクライアントに配信する。純粋なプッシュモデルは、さらに信頼性のために繰り返された配信のいくつかの形態を含み得る。例えば、ペイパービュー購入モデルは、鍵配信に対してプルモードを利用し得る。なぜなら、サーバは、どのクライアントがこれらのクライアントに請求するために番組を購入するかを知る必要があるからである。コンテンツ鍵（すなわち、番組コンテンツ自体を暗号化するために使用される鍵）は、ペイパービューイベントの間に変化させることを要求されない。クライアントは、ペイパービュー番組のためにコンテンツ鍵を暗号化するために使用された番組鍵を引っ張り得る。従って、他の鍵がペイパービューイベントの間に要求されないが、サーバは、どのクライアントがペイパービューイベントを受信するために鍵を引っ張るかを追跡し得る。同様に、加入者は、ユーザが拡張された期間にわたって番組を受信するための加入支払価格を支払う加入支払の支払モデルが同様にプルモードを利用する。例えば、加入者モデルにおける最初のリクエストにおいて、クライアントは加入支払をリクエストし、そのクライアントのための固有の鍵によって暗号化されるサービス鍵を引っ張る。次いで加入支払モデルは、プッシュモードがペイパービューイベントのための該当する番組鍵が利用されることを可能にし、または時間単位のイベントのための番組セグメント鍵がサービス鍵によって暗号化されたクライアントにプッシュアウトされる。同様に、コンテンツ鍵が番組セグメント鍵によって暗号化されたクライアントにプッシュアウトされる。従って、加入支払モデルはプルおよびプッシュモードの両方を利用し得る。プルキー配信モデル、プッシュ組み合わせ鍵配信モデル、およびプル／プッシュキー配信モデルが以下にさらに詳細に説明される。
【００７９】
プル鍵配信モデルは、各クライアントがサーバからアクティブに鍵をリクエストすることを可能にする。図８では、フローチャート８００が、プル鍵配信システムをインプリメントするために図示される。ブロック８１０では、サーバはクライアントから暗号鍵に対するリクエストを受信する。サーバは、ブロック８１４において鍵に対するリクエストを記録する。例えば、このようなログエントリは、サーバによって保守されたデータベース等のログに作成され得る。ブロック８１８では、鍵およびその満了時間は、クライアントによるリクエストに応答してクライアントに配信される。従って、サーバはクライアントの鍵の状態をモニタする必要はなく、むしろ、いつ新しい鍵が要求されるかを決定する責任がクライアントに送られ得る。ブロック８２２では、番組コンテンツは、リクエストされた暗号鍵を利用するクライアントによって復号化するために配信される。最終的に、ブロック８２６では、ログエントリは、請求書構成の請求書パラメータに基づいてクライアントに請求するように利用され得る。
【００８０】
図９は、本発明のさらに別の実施形態によるフローチャート９００を示す。方法９００は、例えば、２つの番組セグメント鍵が利用されて２つの異なるマルチキャストメッセージでクライアントに同じ鍵を転送するし得ることを示す。従って、ユーザが新しい番組セグメント鍵をまだ受け取っていない場合、コンテンツ鍵は、古い番組セグメント鍵を利用することによって入手され得る。この「軟らかい」鍵の遷移は、鍵更新の受領におけるフレキシビリティを可能にする。これは、新しい番組セグメント鍵をリクエストしなかったクライアントが次のセグメントを受信することを可能にする間、新しい番組セグメント鍵をリクエストするクライアントためのサービスの破壊を妨げる。この問題は、番組セグメントをより小さい子暗号エポックに分割することによって軽減され得る。
【００８１】
再度、ブロック９１０では、暗号鍵に対するリクエストがクライアントから受信される。鍵に対するリクエストはブロック９１４に示されるように記録される。ブロック９１８では、鍵が使用され得る番組コンテンツのセグメントが、ログレコードにおいて記録される。再度、サーバは、クライアントによって、鍵のための必要性をモニタリングする必要がない。むしろ、クライアントは、鍵をリクエストする際にサーバから独立して動作し得る。ブロック９２６では、所望された鍵は最初の番組セグメント鍵を用いて暗号化される。ブロック９３０では、暗号化された鍵は第１のマルチキャストメッセージの一部として配信される。あるいは、異なる実施形態では、鍵がクライアントに単一キャストされ得る。従って、特定のクライアントの固有の鍵は、新しい鍵を特定のクライアントに配信するために使用され得る。同様に、所望された鍵は第２のマルチキャストメッセージの一部として配信される。これはブロック９３４に示される。ブロック９３４では、鍵が第２の番組セグメント鍵によって暗号化され、そして第２のマルチキャストメッセージの一部として配信される。ブロック９３８では、番組コンテンツが転送された鍵を利用するクライアントによって復号化のために配信される。最終的に、ブロック９４２では、クライアントが任意のログエントリに基づいて請求される。
【００８２】
鍵に対するリクエストを記録する際に、サーバはリクエストに関する種々の情報を記録し得る。例えば、リクエストされた鍵である時間およびセグメントが記録され得る。次いでこれらのレコードは、請求システムに転送され、各クライアントによって見られたコンテンツの長さを決定するためにこれらのレコードを解析し得る。このサーバは、鍵を追跡し、鍵をクライアントにアクティブに配信する必要がない。むしろ、サーバは、単に新しい鍵を要求するクライアントを待つだけである。
【００８３】
プル鍵配信モデルによって、各クライアントは、新しい鍵をリクエストし、鍵配信サーバによって個々に応答される。サーバは、この第１のリクエストに基づいてマルチキャストセッションにおけるアクティブな参加者のリストを保守し得る。次いで、このリスト上の全てのクライアントは、参加者の固有の鍵を用いて各参加者に対して暗号化された新しい番組セグメント鍵を有するマルチキャストＵＤＰメッセージを用いて新しい鍵が定期的に与えられ得る。クライアントがマルチキャストセッションを出ることを決定する場合、クライアントは認証されたリクエストをリストから除去するように尋ねるサーバに送信する。この信号はサーバにシグナリングしてクライアントがコンテンツの受信を停止させる時間を記録し、その結果、クライアントは以後のコンテンツのために請求しない。従って、クライアントは、アクティブな参加者のリストから除去され得、次の鍵の更新メッセージを受信しない。理論上、クライアントは鍵を所有し、コンテンツを復号化できないが、サーバは、除去されたクライアントがさらなるコンテンツを復号化しないように、アクティブな参加者に一定の間隔で新しい鍵を発行できる。
【００８４】
本発明の別の実施形態において、プッシュ鍵配信モデルは、サーバからクライアントに鍵を配信するようにインプリメントされ得る。従って、図１０は、プッシュ鍵配信モデルをインプリメントするためのフローチャート１０００を示す。ブロック１０１０では、サーバは第１の鍵に対するリクエストをクライアントから受信する。ブロック１０２０では、サーバは第１の鍵をリクエストされたクライアントのリストを生成する。ブロック１０３０では、番組コンテンツを復号化する際に直接または間接的に利用される第２の鍵を配信するように、マルチキャストメッセージがクライアントに配信される。
【００８５】
図１１は、図１０に示された方法のより詳細な実施形態を示すフローチャート１１００を示す。ブロック１１１０では、第１の鍵に対するリクエストがクライアントから受信される。サーバはブロック１１２０において、第１の鍵をリクエストするクライアントのリストを生成する。ブロック１１３０では、各クライアントの固有の鍵は、それぞれのクライアントに第２の鍵を配信する前に第２の鍵を暗号化するように使用される。次いで、サーバは、例えば、ブロック１１４０に示されるように、各クライアントの固有の鍵によって暗号化された第２の鍵を配信するようにマルチキャストメッセージをクライアントに配信する。ブロック１１５０において、クライアントはマルチキャストセッションを出るサーバに指示する。この点では、クライアントはブロック１１６０に示されるようにクライアントのメッセージに応答するリストから除去される。ブロック１１７０では、エントリは、いつクライアントがセッションを出たかを記録するように記録され、その結果クライアントはさらなるコンテンツのために請求されない。第３の鍵は、リスト上に残るクライアントに配信され、除去されたクライアントがブロック１１８０に示されるように以後発生するコンテンツを受信することを妨げる。従って、第３の鍵はリスト上に残っているクライアントに配信され得る。従って、第１、第２、および第３の鍵が、番組コンテンツのために各コンテンツ鍵を復号化するために番組セグメント鍵として利用され得る。
【００８６】
プッシュ鍵モデルおよびプル鍵モデルは、クライアントに鍵を配信するための組み合わせモデルにおいて組み合わせられ得る。図１２に示されるように、方法１２００は、本発明の実施形態のために使用され得る。ブロック１２１０では、鍵が番組コンテンツを復号化する際に使用するためにクライアントに配信される。鍵を配信するサーバは、ブロック１２２０において示されるようにクライアントが鍵を受信したことの確認を待つ。ブロック１２３０では、サーバは、クライアントが鍵が受信されたことを確認する所定の期間だけ待つ。確認メッセージがサーバによって受信されない場合、サーバは、ブロック１２４０に示されるように確認メッセージが「心拍メッセージ（ｈｅａｒｔ−ｂｅａｔ ｍｅｓｓａｇｅ）」として動作するようにリストからクライアントを除去する。従って、サーバはクライアント外部に鍵をプッシュするだけでなく、プルモードと同様に各クライアントからメッセージを受信する。
【００８７】
これを達成するための１つの方法は、各番組セグメントの間、各クライアントが少なくとも一度「その状態に保つ（ｋｅｅｐ ａｌｉｖｅ）」メッセージを送信することである。サーバは、アクティブ参加者のリストを獲得し、各クライアントに対する種々の個々の固有の鍵によって暗号化された新しい鍵を用いてマルチキャストＵＤＰメッセージを介して新しいセグメント鍵をそのリストに配信する。サーバがセグメントの継続のための「その状態に保つ」メッセージを見ない場合、サーバはクライアントをそのアクティブリストから除去する。いくつかのクライアントのためにクライアントは、「その状態に保つ」メッセージを送信しないが、コンテンツを受信し続けることを望む場合、クライアントは番組セグメント鍵の満了時間をモニタリングし、その鍵が終了する前に個々の鍵更新リクエストを送信する。再度、これは、「プル」局面を組み合わせモデルにインプリメントする方法である（「その状態に保つ」間隔を単一の番組セグメントよりも長く規定することがさらに可能である）。
【００８８】
図１３は、本発明の実施形態を実現するためのフローチャート１３００を示す。ブロック１３１０では、サーバは複数のクライアントに番組コンテンツをマルチキャストすることを開始する。ブロック１３２０では、アクティブな参加者のリストが、どのクライアントが番組を受信しているかを示すように生成される。ブロック１３３０では、クライアントがリスト上に残るべきであることを示す「その状態に保つ」メッセージ等のメッセージがクライアントから受信される。ブロック１３４０では、番組コンテンツの次のセグメントを復号化するために、サーバは新しい鍵（例えば番組セグメント鍵）を含むアクティブ参加者のリストにマルチキャストメッセージを送信する。クライアントがリストから除去された場合、それによりアクティブな参加者の第２のリストが生成される。
【００８９】
鍵配信システムの一部として、コンテンツ鍵は、番組コンテンツの配信の経過にわたって番組コンテンツを復号化するために利用される。従って、新しい鍵がインプリメントされる場合、インプリメンテーションは、クライアントにシグナリングされ、その結果クライアントが、クライアントに提供された新しいコンテンツ鍵を利用することを開始し得る。しばしば、クライアントは、例えば番組セグメント鍵を用いて暗号化されるコンテンツ鍵の暗号化バージョンがクライアントに提供される。同様に、番組セグメント鍵はサービス鍵または固有の鍵でさえも用いて暗号化され得る。
【００９０】
シグナリング方法は、新しい鍵のインプリメンテーションを示すために使用され得る。例えば、所定のビットを使用して、古いコンテンツ鍵または現在のコンテンツ鍵が、クライアントに最近配信された新しいコンテンツ鍵に対抗して使用されるべきであるかどうかを示し得る。従って、クライアントは、パケットの所定のビットをチェックし、適切なコンテンツ鍵を使用することを決定し得る。一例として、単一ビットが使用され、「１」を使用して、現在のコンテンツ鍵が既に使用されてことを示し得る一方で、「０」を使用して新しいコンテンツが使用されるべきであることを示し得る。図１４は、シグナリング方法をインプリメントするためのフローチャート１４００を示す。図１４は、番組コンテンツを配信するためのＲＴＰパケットの使用を示すが、これはコンテンツを配信する際に利用された他のプロトコルに等価に適用され得る。従って、同様に他のプロトコルによってインプリメントされ得る方法を例示するに過ぎない。ブロック１４１０において、パケットは、ペイロード部およびヘッダー部の両方を有するＲＴＰパケットとして使用するために提供される。ブロック１４２０では、フィールドがヘッダー部と鍵交換を示すように動作可能であるペイロード部との間に挿入される。これは、固定されたフィールドに対する所定の値がパケットのペイロード部分に対するコンテンツ鍵が変更されたことを示す拡張されたヘッダーのような固定されたフィールドであり得る。あるいは、次に発生するペイロード部が新しいコンテンツ鍵またはこのような同様のインプリメンテーションを利用して復号化され得ることを示し得る。ブロック１４３０では、改変されたＲＴＰパケットが作成される。ブロック１４４０においてこの改変されたＲＴＰパケットがサーバからクライアントに転送される。クライアントは、ブロック１４５０に示されたように改変されたＲＴＰパケットを受信し、鍵がブロック１４６０に示されるように変更されたかどうかを挿入されたフィールドから決定する。ブロック１４７０は、改変されたＲＴＰパケットから挿入されたフィールド部分を除去し、ブロック１４７０に示されるように元のＲＴＰパケットを回復する。次いで回復されたＲＴＰパケットがブロック１４８０に示されたように処理され、パケットが拡張されたヘッダーのインジケータに応じて現在の鍵または次の鍵を用いて復号化され得る。
【００９１】
他のシグナリング方法が同様に利用され得る。例えば、ＲＴＰヘッダー拡張が利用され得る。このように、ヘッダーの拡張された部分は、鍵交換を示すように少なくともコンテンツ鍵のパリティビットを含み得る。
【００９２】
同様に、ペイロードに特有のマーカービットが利用され得る。このビットは、フレームの開始を示すようにマーカービットを使用するＭＰＥＧ４ペイロード等のいくつかのペイロードタイプにおいて既に利用されている。
【００９３】
さらに、例えばパッディングビットが利用され得る。ＲＴＰヘッダーにおけるこのパッディングビットは、鍵交換を示すために利用され得る。これはＲＴＰパケットに適用された暗号化方法が任意のパッディングを利用しないことを想定する。
【００９４】
オーディオおよび視覚材料等の番組コンテンツをマルチキャストする際に、資格受給管理メッセージおよび資格受給制御メッセージ等の番組コンテンツは、サーバからクライアントコンピュータに送信され得る。本発明の一実施形態はこのようなメッセージのフォーマットを提供する。このフォーマットにおいて、再生攻撃に抗して保護するための連続番号またはタイムスタンプが提供される。さらに、ＥＭＭおよびＥＣＭメッセージの別のフィールドでは、鍵をかけられたメッセージ認証コード（ＭＡＣ）または認証のための公開鍵デジタル署名が提供される。クライアントが鍵リクエスト交換を実行するまで、メッセージ認証のための鍵をかけられたハッシュ（ＨＭＡＣ）もこの署名も検証され得ないことに留意すること。さらに別のフィールドは、メッセージに含まれた鍵のタイプ（コンテンツ鍵、グループ鍵、番組セグメント鍵、サービス鍵等）を含む。さらに、フィールドは、メッセージ内の鍵を暗号化するために使用された鍵のタイプが提供される。従って、固有の鍵は、例えば、サービス鍵を転送するメッセージに対して示され得る。別のフィールドは鍵の寿命の残っている時間に対して別のフィールドに提供され得る。さらに、フィールドは、メッセージ中の鍵を暗号化するために使用された鍵のタイプに提供される。あるいは、多数のＥＭＭが単一のマルチキャストメッセージにおいて送達される場合、しばしば必要とされるユーザ識別が提供され得る。データ構造の各フィールドはこれらのフィールドそれぞれに適用する。従って、これらのフィールドは、データ構造がこれらのフィールドの１以上を含むように任意の順序で構成され得る。
【００９５】
図７Ｂは、コンテンツ鍵ＣＫ０が無料のプレビュー鍵（ＥＣＭ：［ＣＫ０］ＦＰＫ）を用いて符号化される無料のプレビュー期間に対する資格受給制御メッセージを示す。同様に図７Ｂは、コンテンツ鍵がグループ鍵（ＥＣＭ：［ＣＫ１］ＧＫ）を用いて符号化される資格受給制御メッセージを示す。第２の資格受給メッセージは、番組鍵（ＥＣＭ：［ＣＫ２］ＰＫ）を用いて暗号化された第２のコンテンツ鍵を伝達することが示される。さらに、いくつかの資格受給管理メッセージが特定のクライアントコンピュータのための独特の鍵を用いて暗号化される新しい番組鍵と共に示される。ＰＫは、個々のクライアントに対してユニキャストであり得る。あるいは、単一のメッセージは、複数のクライアントにマルチキャストする番組鍵の集中されたメッセージを形成するように作成され得る。従って、各クライアントは、クライアント特定の新しい番組鍵を構文解析および復号化し得る。
【００９６】
あるいは、ＣＫ０はＥＣＭ内部に配信される必要がない。複数のクライアントによって既に所有されたＦＰＫの値はＣＫ０として選択され得る。
【００９７】
あるいは、ＣＫ１はＥＣＭ内部に配信される必要がない。複数のクライアントによって既に所有されたＧＫの値はＣＫ１として選択され得る。
【００９８】
あるいは、ＣＫ２はＵＫを用いて暗号化され、図に示されたＥＣＭ形態の代わりにクライアントにＥＣＭの形態で直接配信され得る。
【００９９】
（初期視聴期間）
ペイパービューイベント等のいくつかのマルチキャストイベントに対して、システムは最も大きい負荷を経験し、トラフィックリクエスト番組鍵であり、番組のスケジューリングされた開始に非常に近いことが期待される。マルチキャストセッションに集まるクライアントの集団が非常に大きい場合、サーバは、全ての参加者に速やかに鍵を配信することを不可能にする。従って、サーバが番組材料を購入した者に鍵を配信する場合、システムは視聴者がこの期間に番組の開始を受信することを可能にする必要がある。図１５は、初期視聴期間の間の鍵を配信するための一実施形態の方法を示す。
【０１００】
初期視聴期間をインプリメントする一方法は、共通の鍵を前もって（例えば、番組コンテンツの配信前に）潜在的な参加者に配信することである。このような鍵は、本明細書中ではグループ鍵と呼ぶ。クライアントが特定のキャッシングサーバをリクエストする場合、グループ鍵がクライアントに与えられ得るか、または提供の間に配信システムにおいてクライアントが初期化された場合、グループ鍵は、クライアントによって入手された真のグローバル鍵であり得る。各クライアントがこのような状況でグループ鍵を受信するため、理論上、全てのクライアントは、料金のためにコンテンツの第１の部分を受信し得る。図１５は、本発明の一実施形態をインプリメントするためのフローチャート１５００を示す。図１５のブロック１５１０では、第１の鍵（グループ鍵）がクライアントに提供される。ブロック１５２０では、番組コンテンツの第１の部分を復号化する際に使用するために第２の鍵が提供される。このような鍵はコンテンツ鍵を呼ばれる。第２の鍵は、ブロック１５３０に示されるように、第２の鍵によって暗号化された複数のクライアントの内の少なくとも１つに提供される。第２の鍵は、クライアントへの配信の前にグループ鍵によって暗号化され得る。ブロック１５４０では、第２の鍵はサーバにおいて利用され、番組コンテンツの第１の部分を暗号化する。次いで、暗号化された番組コンテンツの第１の部分は、ブロック１５５０において示されるようにクライアントのグループに配信される。従って、第２の鍵を受信したクライアントは、暗号化された番組コンテンツを復号化することを可能にする。すなわち、クライアントはグループ鍵を利用するコンテンツ鍵を復号化し得、次いで、暗号化された番組コンテンツを復号化するコンテンツ鍵を利用する。これは、ブロック１５６０に示される。
【０１０１】
従って、マルチキャストイベントが開始する場合、最初のコンテンツ鍵はグループ鍵、ならびに、ペイパービューイベントに対する番組鍵または時間単位の支払イベントに対する第１のセグメント鍵によって配信され得る（ＰＳＫは同様にＧＫによって暗号化され得る）。グループ鍵が前もって配信されるために、クライアントは、最終的にはクライアントに配信される番組鍵または番組セグメント鍵の受信を待つ必要がない。むしろ、サーバは、番組コンテンツに対してクライアントによって期待された要求に基づいて最初の視聴期間の継続時間を設定する。またサーバは時間にわたって番組を購入するクライアントの瞬間の負荷に基づいて動的に調整され得る。従って、サーバは特定の番組に対する要求に基づいてリアルタイムで調整し得る。最初の視聴期間が、単一の間隔として決定されるのではなく、「Ｎ」コンテンツ鍵期間から構成され得ることに留意すること。
【０１０２】
図１６Ａおよび図１６Ｂは、本発明の実施形態をインプリメントするためのフローチャート１６００を示す。ブロック１６１０では、番組コンテンツが複数のクライアントをマルチキャストするために提供される。番組コンテンツコンテンツ第１の部分は、第１の鍵（グループ鍵等）を利用して暗号化され、ブロック１６２０において番組コンテンツの暗号化された第１の部分を生成する。ブロック１６３０では、番組コンテンツを復号化する際（典型的には前もって（例えば提供中に））に、クライアントに番組コンテンツを復号化する際に使用するための第１の鍵が提供される。ブロック１６４０では、暗号化された番組コンテンツの第１の部分は、クライアントによる購入の前にクライアントにマルチキャストされる。ブロック１６５０では、例えばこの第１の部分が以前に配信されたグループ鍵によって復号化され得るため、番組コンテンツの第１の部分は、ユーザが番組コンテンツの最初の視聴を入手することを可能にする時間で暗号化される。この期間は、番組に対する期待された所定の要求に基づき得る。ブロック１６６０では、ユーザは、例えば、ユーザインターフェイスを介して無料プレビュー期間の終了時に番組コンテンツを購入することを促進する。次いでブロック１６７０は、保証された期間が提供され、ユーザが、番組サービスが妨害されることなく番組コンテンツを購入することを可能にすることを示す。従って、ユーザが保証された期間に番組を購入する場合、ユーザは、番組視聴の損失が発生しないタイミングのよい方式で必要な鍵を受信することを期待し得る。ブロック１６７４では、サーバは第２の鍵を発生し、次いで、ブロック１６８０に示されるように番組コンテンツの第２の部分を暗号化するために使用される。さらに、第２の鍵は、ブロック１６８４に示されるように保証された期間で番組コンテンツを購入したクライアントのそれぞれに提供される。例えば、番組鍵は、番組鍵の購入に応じてクライアントに配信され得る。次いで、この番組鍵は、第２の鍵がクライアントに転送される場合、第２の鍵を復号化するように利用され得る。従って、ブロック１６９０では、番組コンテンツの暗号化された第２の部分は複数のクライアントにマルチキャストされる。従って、番組コンテンツを購入し、第２の鍵を受信したこれらのクライアントは、番組コンテンツの第２の部分を復号化することができる。
【０１０３】
図７Ｂは、本発明の一例において保証された期間を示す。図７Ｂでは、グループ鍵が利用されて、暗号化された番組コンテンツを復号化するために利用されるコンテンツ鍵を復号化される保証された期間が示される。保証された期間の間の番組コンテンツを購入する任意のユーザが最初の鍵配信の間に次に必要な復号化鍵を受信する。従って、鍵が保証された期間の間に購入されたクライアントに配信されることを可能にするように、最初の鍵配信期間が保証された期間よりも長く継続することが示される。従って、コンテンツ鍵（ＣＫ１）は、全体の最初の鍵配信期間の間で継続することが示される。従って、次のコンテンツ鍵は、最初の鍵配信期間の経過の前に購入しているユーザによって入手される。
【０１０４】
従って、ユーザ経験を満たすことを提供するために、「保証された期間」の間、イベントへのアクセスを要求する全てのクライアント（例えばペイパービューイベントのための番組鍵をリクエストする）が妨害なしでコンテンツを受信することが保証される。これは、リクエストが保証された期間の間に受信された全てのクライアントが全てのクライアントに配信させた番組鍵を有するまで、サーバがグループ鍵によってコンテンツ鍵の配信を停止させないことを意味する。再度、これは最初の視聴期間、または同意義では最初の鍵配信期間と呼ばれる。
【０１０５】
保証された期間の後コンテンツをリクエストするクライアントは、例えば、映画の冒頭を見逃した。すなわち、番組鍵または番組セグメント鍵の送達は重要ではなく、わずかな遅延がこれらの視聴者に許容可能である。実際には、ユーザは一時的に妨害される視聴経験をより早く開始するのではなく、連続的な視聴経験をより遅く開始することが好ましい可能性がある。
【０１０６】
以前に説明されたように、初期鍵配信期間が予測された特定の番組の人気に基づいて最初に設定され得、サーバによって現在の負荷に調整されるように改変される。従って、サーバコンピュータのリクエスト数または性能に基づいて、配信期間が拡張され得る。図１７は、これを達成するための本発明の一実施形態のための方法を示す。ブロック１７１０では、番組コンテンツはマルチキャストするために提供される。ブロック１７２０では、番組コンテンツの第１の部分は、無料で複数のクライアントにマルチキャストされる。ブロック１７３０に示されるように、保証された期間が番組コンテンツの第１の部分をマルチキャストする間に提供される。ブロック１７４０は、保証された期間の間に番組コンテンツを購入するクライアント数が推定されることを示す。ブロック１７５０では、最初の鍵配信期間は、番組コンテンツの受領が購入しているクライアントにおいて妨害されることを妨げるように、購入しているクライアントに暗号鍵を提供するのに十分長い継続時間を有するように提供される。ブロック１７６０では、最初の鍵配信期間が調整される。最初の鍵配信期間の調整は、例えば、単に最初の鍵配信期間を拡張することによって発生し得る。従って、コンテンツ鍵は、コンテンツを購入する視聴者のさらなる付加に適応する期間の間に番組コンテンツを暗号化するために使用され得る。さらに、購入しているクライアントの実際の数は、番組コンテンツを購入するために期待された推定されたクライアントの数を決定し、このクライアントの数と比較され得る。最初の鍵配信期間がクライアントのさらなる負荷に基づいて拡張され得る。さらにこの遅延は、これらのコンポーネントの性能が解析され、最初の配信期間がそれに従って調整され得るサーバ上またはネットワーク上の負荷のためであり得る。
【０１０７】
図１８は、上述の保証された期間の終了後に、ユーザがコンテンツを購入することを可能にする方法１８００を示す。ブロック１８１０では、番組コンテンツが複数のクライアントのための配信のために提供される。番組コンテンツの連続的な視聴を購入するための第１の期間は、ブロック１８２０において提供される。従って、これは前述した保証された期間に一致する。番組コンテンツのために購入しているクライアントからの購入リクエストは、第１の期間の間にブロック１８３０において示されたように受信される。ブロック１８４０に示されるように、第２の期間が第２の期間が第１の期間の後に発生する番組コンテンツを購入するために提供される。ブロック１８５０において示されたように、遅い購入クライアントからの購入リクエストは、この第２の期間の間に受信される。この番組コンテンツは、ブロック１８６０に示されるように番組コンテンツの視聴を中断なしで購入しているクライアントに配信される一方で、遅い購入クライアントに配信された番組コンテンツの復号化の遅延は、番組クライアントが遅い購入しているクライアントによる視聴を中断することなく復号化され得る。これはブロック１８７０において示される。従って、この方法は、サーバが遅い購入クライアントが番組コンテンツの連続的な視聴のために必要な鍵を受信することを決定するまで、遅く購入しているクライアントへの鍵の通信を遅延させ得る。
【０１０８】
（コンテンツ権利および条件）
図１９を参照すると、システムがマルチキャスト環境においてコンテンツを提供するための規則および条件をインプリメントするために理解され得る。システム１９００は、ネットワーク１９１６（インターネット等）を介してサーバ（オリジンコンテンツサーバ１９０４等）に接続される少なくとも１つのクライアント１９０８から構成されたクライアントサーバネットワークを示す。さらに、図１９は、キャッシングサーバ１９１２および認証センタ１９２０を示し、これらもネットワークに接続される。オリジンコンテンツサーバは、番組コンテンツへのアクセスを格納または制御するサーバを示すことが意図される。例えば、このようなコンテンツはマルチメディアであってもよいし、ウエブキャスティングシステムを介する配信のための映画であってもよい。キャッシングサーバ１９１２はこのマルチキャスティング環境において利用され得、元のコンテンツサーバ上で発生した番組コンテンツのコピーを格納する。
【０１０９】
本発明の一実施形態では、クライアントは認証センタ１９２０に登録し、クライアントが入手する資格が与えられるのはどのダイプのコンテンツかを決定するチケットを入手する。従って、クライアントはコンテンツを入手することを望む場合、クライアントが特定の番組コンテンツを受信する資格が与えられたかどうかを確認するために種々の手続がインプリメントされ得る。番組コンテンツを入手するために少なくとも３つのオプションが利用され得る。例えば、図１９におけるオリジンコンテンツサーバ１９０４に対するコンテンツプロバイダが検査を実行し得る。あるいは、図１９におけるキャッシングサーバ１９１２は、検査ルーチンを実行し得るかまたはこの検査がクライアント自体で実行され得る。
【０１１０】
オリジンコンテンツサーバが検査を実行する場合において、オリジンコンテンツサーバは、番組コンテンツに対するクライアントのリクエストを解析し、認証センタを検査して、クライアントが特定のコンテンツに対して認定されたかどうかを決定する。この方法は、特にアクセスがクライアントに拒否されるべきである場合、初期の決定が為されることを可能にし、コンテンツへのアクセスが拒否される際にさらなる処理およびおそらく視聴者のフラストレーションを取り除く あるいは、この検査は、クライアント自体において実行され得る。例えば、クライアントは、各個々のクライアントに配信される規則を実行させ得るハードウエアセキュリティデバイスまたはセキュリティチップを用いて作成され得る。従って、このハードウエアセキュリティデバイスによって使用された規則は、クライアントの視聴資格受給と比較され得るかまたはクライアントの物理位置（クライアントが位置している国等）等の他の属性と比較され得る。このような物理位置は、異なる国がどのタイプの番組コンテンツが配信され得るかに関する種々の法律を有する場合に重要になり得る。
【０１１１】
本発明の別の実施形態は、キャッシングサーバにおいて実行されるべき検査を可能にする。キャッシングサーバは、コンテンツ規則とクライアント資格受給とを比較し得、規則を安全に実施する。クライアントの資格受給は、クライアントがキャッシングサーバに提示するかまたはキャッシングサーバが他の手段を介して受信するデータレコード（チケット）に安全に含まれ得る。この規則は、オリジンサーバからキャッシングサーバに配信され得る。さらに、購入オプションは、オリジンサーバからクライアントに配信され得、次いで、クライアントはキャッシングサーバに購入オプションを伝達し得る。
【０１１２】
コンテンツ規則をユーザの（クライアントの）資格受給と比較することに加えて、ユーザの選択された購入オプションは、また認証決定を作成する際の規則と比較され得る。
【０１１３】
図２０Ａおよび図２０Ｂは、本発明の一実施形態をインプリメントするための方法２０００を示す。図２０Ａのブロック２００４では、クライアントが番組コンテンツに資格を与えるかどうかを規定する規則が構築される。このクライアントは、図１９のオリジンコンテンツサーバ１９０４のようなサーバから番組コンテンツをリクエストすることを可能にする。これはブロック２００８によって示される。ブロック２０１２では、番組コンテンツに対するリクエストが受信される。例えば、クライアントはオリジンコンテンツサーバからの番組コンテンツをリクエストし得る。ブロック２０１６では、データレコードは、番組コンテンツを識別するための識別子、番組コンテンツに誰がアクセスし得るかを規定する規則、およびユーザによって選択された購入オプションを含むオリジンサーバによってフォーマットされる。ブロック２０２０では、データレコードが署名され、暗号化され、安全なオブジェクトとなり得る。ブロック２０２４は、信頼された第三者がデータレコードを署名するために利用され得ることが示される。例えば、データレコードを署名する際に使用するために、このような信頼された第三者を使用して、署名鍵をオリジンコンテンツサーバに発行し得る。同様に、同一の信頼された第三者が利用されて、認証されたデータレコードを以後使用するキャッシングサーバに検証鍵を提供する。ブロック２０２８では、データレコードはクライアントに伝達されるものとして示される。次いで、クライアントはブロック２０３２に示されるようにキャッシングサーバにデータレコードを伝達し得る。データ統合性はブロック２０３４に示されたように署名を検査することによって検証される。あるいは、データレコードは、クライアントを通過得することなくオリジンサーバからキャッシングサーバに直接伝達され得る。図２０Ｂのブロック２０３６では、クライアントが番組コンテンツを受信する権利が与えられるかどうかに関して、キャッシングサーバにおいて決定が為される。キャッシングサーバは、番組コンテンツを受信する権利が与えられた者を規定する規則を含むデータレコードを利用し得、サーバはまた、番組コンテンツをリクエストするクライアントに特有の資格受給を利用し得る。この決定によって、キャッシングサーバはクライアントにより使用のために番組コンテンツ鍵を提供するか否かを決定し得る。さらに、キャッシングサーバは、ブロック２０４０に示されるように、クライアント（または複数のクライアント）による使用のために番組コンテンツ材料の暗号化されたコピーを配信する。
【０１１４】
キャッシングサーバのそれぞれから示された本発明の別の実施形態が図２１に示される。図２１のフローチャート２１００では、キャッシングサーバは、ブロック２１１０によって示されるように、クライアントから番組コンテンツ識別子を受信する。この番組コンテンツ識別子を使用して、クライアントコンピュータのユーザが入手を望む特定の番組コンテンツを識別し得る。ブロック２１２０は、ユーザの選択された支払方法がまたサーバに通信されることを示す。例えば、オリジンサーバとクライアントによって交渉された支払方法がキャッシングサーバと通信され得る。ブロック２１３０では、番組コンテンツに関連付けられた１以上の規則は、クライアントが番組コンテンツに対して権利が与えられたかどうか決定する際に使用するためのキャッシングサーバによって入手される。番組コンテンツ識別子、ユーザの選択された支払方法、および番組コンテンツに関連付けられた規則は、クライアントによってキャッシングサーバに送信された安全なオブジェクトのキャッシングサーバに全て伝達され得る。次いでこの安全なオブジェクトまたはデータレコードは相対的な情報を入手するためにキャッシングサーバによって構文解析され得る。さらに、ブロック２１４０において示されたように、チケットがクライアントから入手され得る。ブロック２１１０、２１２０、２１３０、および２１４０が互いに対して任意の順序で発生し得ることに留意すること。このチケットは、クライアントが番組コンテンツを受信する権利が与えられるかどうかを決定するように使用され得る資格受給情報から構成される。例えば、チケットはクライアントが加入支払するサービスのリスト、クライアントの位置（例えば米国）、コンテンツに対するクライアントの支払能力等を格納し得る。このようなチケット情報は、キャッシングサーバによって入手された規則と比較され、ブロック２１５０に示されるように、クライアントは番組コンテンツに資格が与えられるかどうかを決定する。クライアントが番組コンテンツの受信に対して権利が与えられる場合、ブロック２１６０に示されるように暗号化された番組コンテンツを復号化する際に直接的な使用または間接的な使用のために、鍵がクライアントに伝達され得る。クライアントが番組コンテンツに権利が与えられない場合、このような鍵が配信される必要はない。従って、権利が与えられる番組コンテンツのための鍵を受信するためのクライアント、番組コンテンツのマルチキャストは、受信された鍵を用いて暗号化され得る。
【０１１５】
キャッシングサーバは、番組材料のためのコンテンツ規則を各クライアントの資格受給と比較し、この規則を安全に実施し得る。このクライアント資格受給は、クライアントが特定のコンテンツをリクエストする場合、クライアントがキャッシングサーバに提示するデータレコードにおいて安全に含まれ得る。コンテンツ規則は、少なくとも２つの態様で送達され得る。例えば、コンテンツ規則がキャッシングサーバに直接送達され得る（例えば、コンテンツと共に）。このように、規則は各キャッシングサーバに一回だけ送信される。番組材料の加入支払の場合では、視聴者はコンテンツの各部分を個々に交渉することを必要としない。なぜなら、視聴者は、クライアントの加入支払同意に含まれないからである。視聴者が購入オプション（ペイパービューまたは時間単位の支払等）を選択する必要がない場合、視聴者はオリジンコンテンツサーバと購入オプションについて交渉する。選択された購入オプションが署名され、クライアントに暗号化され送達され（コンテンツ規則の送達メカニズムとは無関係に）、例えば、次いでクライアントによってキャッシングサーバに送信されたリクエストに含まれる。選択された購入オプションが、クライアントではなくキャッシングサーバに対して公知の鍵によって暗号化されるため、これらのオプションはクライアントによって改変されない。あるいは、クライアントがオリジンコンテンスサーバとコンテンツへのアクセスに対して交渉する場合、コンテンツ規則がコンテンツプロバイダ（すなわちオリジンコンテンツサーバ）によって作成され得る。このような規則は視聴者が選択した特定の購入オプション（選択されたペイパービューまたは時間単位の支払い等）と組み合わせられ得る。次いで、例えば選択された購入オプションと組み合わせたコンテンツ規則が署名され、暗号化され、そしてクライアントに送達され得る。これはクライアントによってキャッシングサーバに送信されたリクエストに含まれる。コンテンツ規則は、クライアントではなくキャッシングサーバに公知の鍵によって暗号化されるために、コンテンツ規則は、クライアントによって改変されない。このアプローチは、コンテンツ規則の送達のためにオリジンコンテンツサーバとキャッシングサーバとの間の直接のデータインターフェイスに対する必要性を除去する。
【０１１６】
オリジンコンテンツサーバとクライアントとの間の購入を交渉する際、オリジンコンテンツサーバは、規則および購入オプション情報をローカルに維持する。次いで、クライアントが決定を行うことを可能にするように、コンテンツサーバは、クライアントに全ての異なる購入オプションを申し込みし得る。従って、購入オプションは、クライアントに戻る安全なデータレコードにカプセル化され得る。次いで、クライアントは、クライアントの資格受給情報（例えば、購入能力、加入支払されたサービスのリスト等）を含むクライアントチケットと共に安全なデータレコードを適切なキャッシングサーバに転送し得る。図１９のクライアントは、クライアントがマルチキャストシステムに登録する場合、認証センタ１９２０からの資格受給情報を獲得し得る。
【０１１７】
図２２は、オリジンコンテンツサーバによって提供され得るデータレコードを示す。このデータレコードは、クライアントまたはキャッシングサーバへの伝達の前に暗号化され得る。図２２は、データレコードの一部として利用され得る異なるフィールドを示す。従って、図２２は、映画の名前のような特別の番組コンテンツを識別する番組コンテンツＩＤのためのフィールドを示す。さらに、データレコード２２００は、番組コンテンツへのアクセスを有する者を規定する規則を格納するためのフィールドを含み得る。図２２に示される実施形態では、格付け情報フィールドはまた、特定の格付け基準と一致し得るように示される。あるいは、フィールドは、クライアントおよびオリジンコンテンツサーバによって交渉されたペイパービューまたは時間単位の支払等のクライアントの購入優先度（選択）を格納するように図２２に示されるように提供され得る。図２２はまた、認証フィールドを示し、クライアントがデータレコードを改変することを防ぐ。
【０１１８】
図２３は、個々のクライアントのために提供され得るデータレコードを示す。このようなデータレコードを使用して、異なる番組コンテンツに対する特定のクライアントの資格受給を規定し得る。従って、例えば、図２３は、クライアントの位置（クライアントが位置している国等）を識別するためのフィールドから構成されたデータレコードを示す。クライアントが加入した加入支払（ＨＢＯ（Ｒ）またはＳＨＯＷＴＩＭＥ（Ｒ））を識別するフィールドが示される。さらなるフィールドが同様に示され得る。この情報は、クライアントが自身の資格授与を修正できないように認証され暗号化され得る。
【０１１９】
本発明の種々の実施形態が本発明をインプリメントするための装置または方法として示されてきたが、本発明は、コンピュータに接続されたコード（例えば、コンピュータに常駐するコードまたはコンピュータによってアクセス可能なコードによってインプリメントされ得る。例えば、ソフトウエアおよびデータベースは、上述の多くの方法をインプリメントするために使用され得ることが理解されるべきである。従って、本発明がハードウエアによって達成される実施形態に加えて、これらの実施形態は、埋め込まれたコンピュータ読み出し可能プログラムコードを有するコンピュータ利用可能媒体から構成された製造品の使用によって達成され得ることに留意されたい。これにより本明細書に開示された機能の可能性を生じる。従って、本発明の実施形態もまた、同様に本特許の番組コード手段によって保護される本発明の実施形態が考慮されることが望ましい。
【０１２０】
本発明の実施形態は、搬送波および転送媒体を介して伝播された信号（例えば電気的および光学的に）に埋め込まれたコンピュータ信号として達成され得ることが明らかである。従って、上述の種々の情報が、データ構造等の構造においてフォーマットされ、電気信号として転送媒体を介して転送され、またはコンピュータ読み出し可能媒体に格納され得る。
【０１２１】
本発明に記載された多くの構造、材料、および作用が機能を実施するための機能またはステップを実行するための手段として記載され得ることに留意されたい。従って、本明細書およびその均等物に開示されたこのような全ての構造、材料、または作用を包含するためにこのような構造に権利が与えられることが理解されるべきである。
【０１２２】
本発明の実施形態の装置および方法およびそれに付随する利点の多くが本明細書から理解され、種々の変更が、本発明の精神および範囲から逸脱することなくまたは本発明の利点の全てを犠牲にすることなく、本発明の一部の形態、構造、および構成で作成され得ることが明らかであり、説明される前の本明細書の形態は単に本発明の例示であるに過ぎないことが想起される。
【図面の簡単な説明】
【図１】
図１は、インターネットを介して番組コンテンツをマルチキャスティングするために使用されるようなコンテンツ配信システムの実施形態のブロック図である。
【図２】
図２は、図１に示されたコンテンツ配信システムのクライアントコンピュータ部分の実施形態のブロック図である。
【図３】
図３は、無料のプレビューをクライアントに提供するための本発明の一実施形態を示すフローチャートである。
【図４】
図４は、無料のプレビューを提供するための本発明の別の実施形態を示すフローチャートである。
【図５】
図５は、番組の暗号化されていない部分および番組の暗号化された部分を配信するための本発明の実施形態を示すフローチャートである。
【図６】
図６は、無料のプレビューを表示することを可能にする本発明の実施形態を示すフローチャートである。
【図７Ａ】
図７Ａは、番組の部分の間の暗号鍵の例示的な配信を示すグラフである。
【図７Ｂ】
図７Ｂは、番組の部分の間の暗号鍵の例示的な配信を示すグラフである。
【図８】
図８は、本発明の一実施形態のもとで鍵を配信するためのフローチャートを示す。
【図９】
図９は、本発明の別の実施形態による鍵を配信するための別のフローチャートを示す。
【図１０】
図１０は、鍵が複数のクライアントにマルチキャストされる本発明の一実施形態に対するフローチャートを示す。
【図１１】
図１１は、クライアントがマルチキャストコンテンツを受信するためにサーバからの鍵をリクエストする本発明の実施形態を示すフローチャートを示す。
【図１２】
図１２は、クライアントが、鍵が受信された受領メッセージを送信し得るクライアントに鍵を配信するための本発明の実施形態を示す。
【図１３】
図１３は、番組を受信するアクティブな参加者のリストが作成され、クライアントがそのリストに残っているべきであることを示す確認メッセージを送信する本発明の実施形態に対するフローチャートを示す。
【図１４】
図１４は、改変されたＲＴＰパケットが暗号鍵の変化を信号発信するために作成される本発明の実施形態に対するフローチャートを示す。
【図１５】
図１５は、マルチキャスティングシステムにおいてクライアントに共通鍵を提供するための本発明の一実施形態によるフローチャートを示す。
【図１６Ａ】
図１６Ａは、番組コンテンツの最初のプレビューを提供するための本発明の一実施形態によるフローチャートを示す。
【図１６Ｂ】
図１６Ｂは、番組コンテンツの最初のプレビューを提供するための本発明の一実施形態によるフローチャートを示す。
【図１７】
図１７は、番組コンテンツを購入するための調整可能な最初の鍵配信期間を提供するための本発明の一実施形態によるフローチャートを示す。
【図１８】
図１８は、番組コンテンツについて遅く購入することによって、連続的な視聴を番組コンテンツに提供するための本発明の一実施形態によるフローチャートを示す。
【図１９】
図１９は、本発明の一実施形態に従って使用するためのネットワークを示す。
【図２０Ａ】
図２０Ａは、本発明の一実施形態に従って、元のコンテンツサーバからキャッシングサーバにデータレコードを伝達するためのフローチャートを示す。
【図２０Ｂ】
図２０Ｂは、本発明の一実施形態に従って、元のコンテンツサーバからキャッシングサーバにデータレコードを伝達するためのフローチャートを示す。
【図２１】
図２１は、キャッシングサーバによって使用するための番組コンテンツに関連付けられた少なくとも１つの規則に基づいてクライアントが番組コンテンツに対して権利が与えられたかどうかを決定するために提供する本発明の一実施形態によるフローチャートを示す。
【図２２】
図２２は、元のコンテンツサーバからキャッシングサーバに情報を伝達するための本発明の一実施形態によるデータ構造を示す。
【図２３】
図２３は、異なる番組コンテンツに特定のクライアントの資格授与を規定するために個々のクライアントに提供され得る本発明の一実施形態によるデータレコードを示す。

Claims (26)

1. 番組コンテンツを提供するためのサーバと、ネットワークを介して該サーバと通信するために動作可能なクライアントと、該番組コンテンツのコピーを格納するために動作可能なキャッシングサーバとを含む該ネットワークに該番組コンテンツを配信するための方法であって、
   該クライアントが該番組コンテンツを受信する権利が与えられるかどうかを規定する規則を構築するステップと、
   該ネットワーク上に該規則を格納するステップと、
   該クライアントが該ネットワークから該番組コンテンツをリクエストすることを可能にするステップと、
   該番組コンテンツを復号化するために該クライアントに鍵を配信する前に、該クライアントが該番組コンテンツを受信する権利を与えられるかどうかを決定するように少なくとも１つの該クライアントの資格授与特性を記述するレコードと該規則を比較するステップと
   該番組コンテンツをマルチキャスティングするステップと
   を含む、ネットワークに番組コンテンツを配信するための方法。
2. 前記規則は支払方法から構成される、請求項１に記載のネットワークに番組コンテンツを配信するための方法。
3. 前記規則は加入支払識別子から構成される、請求項１に記載のネットワークに番組コンテンツを配信するための方法。
4. 前記規則は前記番組コンテンツが送達されるべき位置に基づいた制限から構成される、請求項１に記載のネットワークに番組コンテンツを配信するための方法。
5. 前記規則はユーザのためのコンテンツ格付けに基づいた制限からなる、請求項１に記載のネットワークに番組コンテンツを配信するための方法。
6. 前記少なくとも１つの資格授与特性は、前記クライアントの物理的な位置を示す情報を含む、請求項１に記載のネットワークに番組コンテンツを配信するための方法。
7. 前記少なくとも１つの資格授与特性は、前記クライアントに与えられた少なくとも１つのサービスを示す情報を含む、請求項１に記載のネットワークに番組コンテンツを配信するための方法。
8. 前記少なくとも１つの資格授与特性は、キャッシングサーバを用いて前記クライアントを認証する際に使用するためのデータを含む、請求項１に記載のネットワークに番組コンテンツを配信するための方法。
9. 前記少なくとも１つの資格授与特性は、前記クライアントによってチケットに格納される、請求項１に記載のネットワークに番組コンテンツを配信するための方法。
10. 前記少なくとも１つの資格授与特性は、前記クライアントから前記キャッシングサーバに伝達される、請求項１に記載のネットワークに番組コンテンツを配信するための方法。
11. 前記クライアントが前記少なくとも１つの資格授与特性を変更することを許可しないステップをさらに含む、請求項１に記載のネットワークに番組コンテンツを配信するための方法。
12. 前記クライアントが前記少なくとも１つの資格授与特性を変更することを防ぐように前記少なくとも１つの番組コンテンツを暗号化するステップをさらに含む、請求項１に記載のネットワークに番組コンテンツを配信するための方法。
13. 前記クライアントの前記少なくとも１つの資格授与特性を記述する前記レコードと前記規則を比較する前に、前記番組コンテンツをマルチキャストするステップが開始される、請求項１に記載のネットワークに番組コンテンツを配信するための方法。
14. 番組コンテンツを格納するためのサーバと、ネットワークを介して該サーバと通信するために動作可能なクライアントと、該番組コンテンツのコピーを格納するために動作可能なキャッシングサーバとを含む該ネットワークに該番組コンテンツを配信するための方法であって、
    該クライアントが該番組コンテンツを受信する権利が与えられるかどうかを規定する規則を構築するステップと、
    該クライアントが該サーバから該番組コンテンツをリクエストすることを可能にするステップと、
    該番組コンテンツのために該クライアントからのリクエストをサーバにて受信するステップと、
    該番組コンテンツおよび該番組コンテンツのための該規則を識別する識別子を含むデータレコードをフォーマットするステップと
    を含む、ネットワークに番組コンテンツを配信するための方法。
15. 前記データレコードを認証するステップをさらに含む、請求項１４に記載のネットワークに番組コンテンツを配信するための方法。
16. 前記キャッシングサーバが前記データレコードを認証することを可能にするように該データレコードを署名するステップをさらに含む、請求項１４に記載のネットワークに番組コンテンツを配信するための方法。
17. 前記データレコードを認証するステップは、
    信頼された第三者を利用して、前記データレコードを署名する際に使用するために前記サーバに認証鍵を提供し、該データレコードを認証する際に使用するための前記キャッシングサーバに検証鍵を提供するステップを含む、請求項１６に記載のネットワークに番組コンテンツを配信するための方法。
18. 前記データレコードを前記クライアントに伝達するステップをさらに含む、請求項１４に記載のネットワークに番組コンテンツを配信するための方法。
19. 前記データレコードを署名するステップと、
    該署名されたデータレコードを前記クライアントに伝達するステップと
    をさらに含む、請求項１４に記載のネットワークに番組コンテンツを配信するための方法。
20. 前記データレコードを署名するステップと、
    該署名されたデータレコードを前記クライアントに伝達するステップと、
    該署名されたデータレコードを該クライアントから前記キャッシングサーバに伝達するステップと
    をさらに含む、請求項１４に記載のネットワークに番組コンテンツを配信するための方法。
21. 前記データレコードを署名するステップと、
    該署名されたデータレコードを該サーバから前記キャッシングサーバに伝達するステップと
    をさらに含む、請求項１４に記載のネットワークに番組コンテンツを配信するための方法。
22. 前記データレコードを署名するステップと、
    該署名されたデータレコードを前記クライアントに伝達するステップと、
    該署名されたデータレコードを該クライアントから前記キャッシングサーバに伝達するステップと
    前記番組コンテンツを識別する識別子を該クライアントから該キャッシングサーバに伝達するステップと、
    該キャッシングサーバにおいて該データレコードを認証するステップと、
    該キャッシングサーバが、該クライアントが該番組コンテンツを受信する権利が与えられたかどうかを決定することを可能にするステップとをさらに含む、請求項１４に記載のネットワークに番組コンテンツを配信するための方法。
23. サーバと、ネットワークを介して該サーバと通信するために動作可能なクライアントと、該番組コンテンツのコピーを格納するために動作可能なキャッシングサーバとを含む該ネットワークに該番組コンテンツを配信するための方法であって、
    該クライアントが該番組コンテンツに権利が与えられるかどうかを決定する際に使用するために、該クライアントに対するデータレコードを受信するステップと、
    該クライアントが該番組コンテンツに権利が与えられるかどうかを決定するように該キャッシングサーバによる使用のために該番組コンテンツに関連付けられた規則を受信するステップと、
    該クライアントが該番組コンテンツに権利が与えられるかどうかを決定するように該データレコードおよび該規則を利用するステップと、
    該番組コンテンツをマルチキャスティングするステップとを含む、ネットワークに番組コンテンツを配信するための方法。
24. 前記番組材料を前記クライアントに伝達するステップをさらに含む、請求項２３に記載のネットワークに番組コンテンツを配信するための方法。
25. 信頼された第三者から受信された鍵を用いて前記データレコードを復号化するステップをさらに含み、該信頼された第三者は前記キャッシングサーバおよび前記サーバに対して信頼された第三者である、請求項２３に記載のネットワークに番組コンテンツを配信するための方法。
26. 前記クライアントに対する前記データレコードを受信するステップは、該クライアントから該データレコードを受信するステップを含む、請求項２３に記載のネットワークに番組コンテンツを配信するための方法。

Images