(57)【特許請求の範囲】
【請求項１】
ヘッドエンドから少なくとも１つのクライアントへ、前記ヘッドエンドおよび前記クライアントが接続された少なくとも１つのネットワークを介して、コンテンツ・データを安全なパケット・ベースで送信する方法であって、
データ・パケット・プロトコルに従って構成されたクリア・データ・パケットを取り出すステップであって、前記クリア・データ・パケットは、前記データ・パケット・プロトコルに従って構成されたクリア・データ・パケット・ヘッダと、暗号化されていないペイロードとを含むものである、取り出すステップと、
前記クリア・データ・パケットからの前記暗号化されていないペイロードを２以上のフラグメントに分割する分割ステップと、
それぞれのフラグメントに暗号化アルゴリズムを適用して暗号化済フラグメントを生成するステップと、
それぞれの前記暗号化済フラグメントのために暗号化ヘッダを生成するステップと、
それぞれの前記暗号化済フラグメントについて暗号化済データを有するパケットを組み立てるステップであって、前記暗号化済フラグメント、前記暗号化済フラグメントのための前記暗号化ヘッダ、および前記データ・パケット・プロトコルに従った前記クリア・データ・パケット・ヘッダを含むようにする、組み立てるステップと、
前記組み立てるステップで組み立てられた前記パケットのそれぞれを前記データ・パケット・プロトコルに従って前記クライアントへ送信するステップと
を備える方法。
【請求項２】
前記暗号化されていないペイロードをフラグメントに分割する前記分割ステップにおいて、前記フラグメントのサイズが、暗号化済データを有する前記パケットのサイズを前記ネットワークの最大送信単位より下に保つように選ばれる、請求項１に記載の方法。
【請求項３】
前記クリア・データ・パケットにおいて指定された条件付きアクセス・データを取り出すステップを更に備え、前記条件付きアクセス・データが、前記暗号化済フラグメントを生成するために使用されるものである、請求項１または２に記載の方法。
【請求項４】
暗号化前の前記フラグメントの長さ、およびそれぞれのクリア・データと関連する暗号化されていないデータと相対する暗号化済データを有する前記パケットへの前記暗号化アルゴリズムによって加えられる追加の長さに関して、各フラグメントについて前記暗号化ヘッダにおいて情報が符号化される、請求項１ないし３の何れかに記載の方法。
【請求項５】
少なくとも１つのフラグメントのための前記暗号化ヘッダが、前記暗号化されていないペイロードのチェックサムに関する情報を備え、前記クライアントにおいて前記クリア・データ・パケットを再組立てすることを可能にする、請求項１ないし４の何れかに記載の方法。
【請求項６】
１つの前記暗号化されていないペイロードから生成された複数の前記暗号化済フラグメントに対して前記組み立てるステップで組み立てられた複数のパケットについて、前記暗号化ヘッダが、前記複数のパケットのうちの最初に送信されるパケットを、前記複数のパケットのうちの他のパケットから区別するためのフラグを含む、請求項１ないし５の何れかに記載の方法。
【請求項７】
前記暗号化されていないペイロードの第１のフラグメントに対しての暗号化されていないフラグメントのオフセットを含む情報が、前記暗号化されていないフラグメントから生成された前記暗号化済フラグメントのための前記暗号化ヘッダに備えられる、請求項１ないし６の何れかに記載の方法。
【請求項８】
前記フラグメントに適用された前記暗号化アルゴリズムを指定する情報が、前記暗号化ヘッダ内に符号化される、請求項１ないし６の何れかに記載の方法。
【請求項９】
クライアントが特定のサービスを利用することを許可するための資格管理メッセージをデータ・パケットとして送信するステップを更に備える、請求項１ないし８の何れかに記載の方法。
【請求項１０】
クライアントが特定のサービスに属するデータを受信することを選択的に許可するための、暗号解読情報を含む資格制御メッセージをデータ・パケットとして送信するステップを更に備える、請求項１ないし９の何れかに記載の方法。
【請求項１１】
サービスを識別し、前記サービスに属するメッセージを受信するための情報を含む情報メッセージをデータ・パケットとして送信するステップを更に備える、請求項１ないし１０の何れかに記載の方法。
【請求項１２】
前記取り出すステップで取り出された前記クリア・データ・パケットの前記クリア・データ・パケット・ヘッダは、ＩＰアドレスを含むヘッダを備える、請求項１ないし１１の何れかに記載の方法。
【請求項１３】
前記取り出すステップで取り出された前記クリア・データ・パケットの前記クリア・データ・パケット・ヘッダは、トランスポート層プロトコルに関する第２のヘッダを更に備え、
前記組み立てるステップで組み立てられた前記パケットのうちの１つのパケットの前記クリア・データ・パケット・ヘッダは、前記第２のヘッダを更に備える、
請求項１２に記載の方法。
【発明の詳細な説明】
【０００１】
発明の背景
本発明は、コンテンツ・データの、安全なパケット・ベースのブロードキャスティング、マルチキャスティング、またはユニキャスティングの分野に関し、より詳細には、パケットに符号化されたデータの暗号化の分野に関する。本発明はまた、暗号化鍵、資格情報、およびブロードキャスト／マルチキャスト・ヘッドエンドからコンテンツのユーザへ鍵および資格情報をどのように取り出すかを指定する情報を転送することの分野を対象とする。
【０００２】
本発明は実質的に、少なくとも１つのネットワークを介してクライアントへ接続されたヘッドエンドからクライアントが受信した暗号化済データを有するパケットを処理する方法に関し、データ・パケットは、少なくとも暗号化ヘッダおよび暗号化済ペイロードを含む。
【０００３】
本発明は、コンテンツ・データの安全なパケット・ベースの転送のためのシステムに関するものであり、ネットワークに接続されるヘッドエンドを備え、ヘッドエンドは、ソースからクリア・データ・パケットを受信するレシーバと、少なくともデータ・パケットの一部を暗号化し、クリア・データ・パケットの暗号化部分を含むデータ・パケットを生成する暗号化ユニットと、ネットワークを介してそのデータ・パケットを送信するネットワーク・インターフェースとを備え、前記システムは、少なくとも１つのクライアンを更に備え、クライアントは、ネットワーク・インターフェースを用いてネットワークへ接続され、ネットワークを介して送信されたデータ・パケットを受信し、データ・パケットのフラグメントからデータ・パケットを構成することができる。
【０００４】
本発明はまた、ヘッドエンドから少なくとも１つのクライアントへ、そのヘッドエンドおよびクライアントが接続された少なくとも１つのネットワークを介して、コンテンツ・データを安全なパケット・ベースで伝送する方法に関する。
【０００５】
コンテンツを暗号化しブロードキャストすることは、テレビジョン・ブロードキャスティングの分野から知られている。インターネットの出現で、インターネットのために定義された標準プロトコルを使用して、この媒体を介してコンテンツをブロードキャストすることが開始された。インターネットを介して送信されるコンテンツもまた、不正な視聴を回避するために暗号化しなければならない。コンテンツのレシーバ（クライアント）は通常、複数のタスクを実行するＰＣである。暗号化処理がクライアントＰＣのパフォーマンスにあまりに大きなインパクトを与えないことが重要である。また、解読機構がネットワーク・カードおよびアプリケーションから独立していることも非常に重要である。これを達成することができれば、解読システムのプロバイダに対して著しいコスト節約を可能にする。アプリケーションは、新しいオペレーティング・システムへ移植するだけでよく、そうすれば、任意のコンフィギュレーションのネットワーク・インターフェース・ハードウェアおよび任意のマルチキャストまたはユニキャストのアプリケーションを有するデータ処理ソフトウェアで使用することができる。
【０００６】
暗号化済情報を解読できるためには、暗号化鍵をクライアント（コンテンツのレシーバおよび視聴者）へ送らなければならない。クライアントがコンテンツを使用または視聴する資格があるかどうかを判定できるためには、コンテンツのアクセス条件をクライアントへ送らなければならない。テレビジョン・ブロードキャスト環境では、この情報は、特別なタイプのメッセージ、即ち資格制御メッセージ（ＥＣＭ）を使用してコンテンツの一部として送られる。そのようなメッセージは、プログラムの暗号化鍵およびアクセス条件を含む。
【０００７】
ＥＣＭに加えて、資格管理メッセージ（ＥＭＭ）もまた、クライアントへ送らなければならない。ＥＭＭは、視聴者のアクセス・プロファイルを設定するメッセージ、換言すれば、クライアントが特定のサービスをデスクランブルすることを許可するメッセージである。
【０００８】
クライアントのコンフィギュレーションから独立な、上記で議論した種類のシステムおよび方法を得るために、本発明は、クライアントが受信した暗号化済データを有するパケットを処理するための上述のタイプの方法を提供するものであり、その方法は、
−データ・パケットから暗号化ヘッダを抽出すること、
−暗号化済ペイロードを抽出し解読してクリア・データを形成すること、
−クリア・データ・パケット・ヘッダを生成すること、および
−クリア・データ・パケット・ヘッダおよびクリア・データを含むクリア・データ・パケット・フラグメントを生成すること
を含む。
【０００９】
クリア・データ・パケット・ヘッダおよびクリア・データを含むクリア・データ・パケット・フラグメントを生成することによって、解読処理は、そのクリア・データを使用するアプリケーションに対して透明になる。それらは、暗号化フォーマットに適合する必要はなく、解読は、そのデータを使用するアプリケーションおよびオペレーティング・システムから独立である。
【００１０】
本発明の好ましい一実施形態において、方法は、クリア・データ・パケット・フラグメントをバッファし、それらをクリア・データ・パケットに組立てることができるクライアント上のネットワーク・プロトコル・スタックに対する入力として、クリア・データ・パケット・フラグメントを提供することを更に含む。これにより、迅速な解読およびクライアント上のリソース使用の節約が可能になる。それは、クリア・データ・パケット・フラグメントを、事前に何らバッファすることなく、解読の後に直接にスタックへ渡すことができるからである。
【００１１】
暗号化済データを有するパケットの暗号化ヘッダが、関連するクリア・データ・パケット・フラグメントからクリア・データ・パケットをスタックにおいて組立てることを可能にする情報を含むものである好ましい一実施形態において、方法は、暗号化ヘッダから情報を抽出すること、およびその情報をクリア・データ・パケット・フラグメントと共に含めることを更に含む。
【００１２】
これにより、クリア・データ・パケットがスタック内で処理された後、それらのクリア・データ・パケットを使用するスタックおよびアプリケーションに対して、解読処理が完全に透明になる。クリア・データ・パケット・フラグメントに既に含まれる既存の標準に準拠する情報を除いて、特別な情報は何もスタックへ渡す必要がないので、解読は、ネットワーク・プロトコル・スタックの特定の実施から独立している。
【００１３】
本発明は、ヘッドエンドから少なくとも１つのクライアントへコンテンツ・データを安全なパケット・ベースで伝送するための上述のタイプの方法を提供するものであり、方法は、
−暗号化されていないペイロードを含むクリア・データ・パケットを取り出すこと、
−暗号化されていないペイロードを１つまたは複数のフラグメントに分割すること、
−それぞれのフラグメントに暗号化アルゴリズムを適用して暗号化済フラグメントを生成すること、
−それぞれの暗号化済フラグメントに対する暗号化ヘッダを生成すること、
−フラグメント、暗号化ヘッダ、およびフラグメントに対するデータ・パケット・ヘッダを含むようにした、それぞれの暗号化済フラグメントに対しての、暗号化済データを有するパケットを組み立てること、および
−このように構成されたパケットのそれぞれをクライアントへ送信すること
を備える。
【００１４】
即ち、暗号化されていないペイロードがフラグメントに分割され、それぞれのフラグメントに対して暗号化済データ・パケットが生成されるので、暗号化済データ・パケットを受信するクライアントは、暗号化済データの解読を始める前に、全ての暗号化済ペイロードを収集するためにバッファを使用する必要がない。その代わりに、クライアントは、それぞれのフラグメントが到着するとそのフラグメントを解読することができ、それにより、クライアントにおいて利用可能なリソースの要求がより少なくなり、解読処理がスピード・アップされる。
【００１５】
好ましい一実施形態では、少なくとも１つのフラグメントに対する暗号化ヘッダに、クリア・データ・パケットの長さに関する情報と、暗号化されていないペイロードのチェックサムに関する情報とが提供されて、クライアントにおいてクリア・データ・パケットを再組立てすることが可能になる。
【００１６】
暗号化済ペイロードを含むすべてのフラグメントが到着する前に、この情報から、クライアントで新しいヘッダを組み立てることができる。この新しいヘッダを含むフラグメントは、直ちにクリア・データ・パケットのフラグメントを再組立てする標準ソフトウェアへ渡すことができ、従って、プロトコル・スタックにおいて暗号化済データを有するパケットに対してこのタスクを実行するいかなる特別なソフトウェアの必要もなくなる。
【００１７】
迅速な解読およびクライアント・リソースに対する要求が低いこともまた、本発明による上述のタイプのシステムに固有な利点であり、ここで、クライアントは、受信したデータ・パケットに含まれる暗号化済データを解読することによってクリア・データを生成するため、およびそのクリア・データからデータ・パケット・フラグメントを生成するための解読ユニットを備える。クライアントは、データ・パケット・フラグメントからデータ・パケットを組み立てることができるので、解読後に、データ・パケット・フラグメントを通常のクリア・データ・パケットに直接に組立てることができる。
【００１８】
次に添付の図面を参照しながら、本発明を更に詳細に述べる。
詳細な説明
この詳細な説明は、本発明による、コンテンツ・データの安全なパケット・ベースの転送のためのシステムの動作の一般的概要を提供する。次いで、ＩＰパケットの暗号化および解読に対する本発明による方法のアプリケーションおよびシステムの暗号化および解読サブシステムの機能を詳細に述べる。
【００１９】
本明細書は、ＩＰＥＭＭ、ＩＰＥＣＭおよびＩＰ−ｉｎｆｏメッセージのフォーマットもまたカバーする。これらのメッセージは、この実施形態において、クライアントが、特定のサービスを利用すること、特定のサービスに属するデータを受信すること、およびそのサービスを識別することを許可するため、ならびにクライアントがそのサービスの条件付きアクセス・メッセージを受信することを可能にするために使用される。本明細書は、条件付きアクセス・メッセージをクライアントへ転送するために使用される方法に対して更に展開される。
【００２０】
システム概要
データをマルチキャスト、ブロードキャスト、またはユニキャストするために使用される、本発明によるシステムの一実施形態を図１に示す。本システムは、以後はヘッドエンド１と称する送信側を備える。本システムは、単一のスタンドアロン・デバイスからネットワーク（ＬＡＮ、ＷＡＮまたはダイヤルアップ接続）にリンクされた複数のコンピュータおよびデバイスに及ぶ様々な装置を使用して様々な方法で実施することができる。
【００２１】
ヘッドエンド１は、コンテンツが収集されフォーマットされる部分である。ヘッドエンド１は、本発明によるコンテンツ・データの安全なパケット・ベースのブロードキャスティングのための方法を使用して、コンテンツ・データを暗号化し、暗号化済データを有するパケットを生成する。暗号化済コンテンツ・データは、必要ならば多重化され、次いでブロードキャストされる。これらの機能は、１つの中央地点、またはそれぞれがコンテンツに対する特定の機能を実行する複数の地点で実行することができる。
【００２２】
ブロードキャスト・ヘッドエンド１の出力は、コンテンツが暗号化されたパケット・ベースのデータ、例えばＩＰデータであり、そのデータは次いで、ブロードキャスト・ネットワーク２へブロードキャストされる。これはどのネットワークでもよく、衛星、ケーブル、地上、ＤＳＬ（デジタル加入者回線）、インターネット、ＬＡＮ、ＷＡＮ、無線（ＧＰＲＳ、ＵＭＴＳ）や、そのオペレータ（運営者）の加入者にアクセスを提供する任意の将来型のネットワークでよい。ブロードキャスト・ネットワーク２は、インターネット、接続された異なるタイプのネットワークの集合でもよい。運営者は、暗号化されたマルチキャスト・サービスを、許可された加入者に提供するエンティティを指す。
【００２３】
ネットワーク２がＩＰネットワークであれば、コンテンツを、全てのインターネット・ユーザではなくその運営者の加入者へブロードキャストするためにＩＰマルチキャスト・プロトコルを使用することが有利である。コンテンツは、マルチキャストされ、以後ではクライアント３と称する加入者の端末によって受信される。クライアント３は、そのマルチキャストを受信してそのコンテンツを解釈して表現できる任意の受信デバイス（ＰＣ、セットトップ・ボックス、または他の任意の端末装置）でよい。クライアント３は、通常、安全デバイス（secure device、セキュア・デバイス）および何らかのソフトウェアを備えるＰＣを含む。安全デバイスは、スマート・カード・リーダによってＰＣにインターフェースするスマート・カードでよい。
【００２４】
パケット・ベースのデータを受信する標準ソフトウェアは、クライアント３上で実行される。そのソフトウェアは、データ・パケットの様々な部分を処理するプログラムの集合を含む。それらは、ネットワーク・プロトコル・スタックにおいて階層的に積み重ねられる。データがＩＰプロトコルに従ってブロードキャストされた場合、クライアント３で受信したデータ・パケットを処理するために使用されるソフトウェアは、ＩＰスタックを形成すると言われる。最下位レベルのソフトウェアは、ＩＰアドレスを含む第１ヘッダ、即ちＩＰヘッダを抽出する。データ・パケット・フラグメントでデータ・パケットがクライアント３に到着した場合、これらは全パケットが完了するまでバッファされる。より上位レベルのソフトウェアは、データが正しいプログラムに対する入力として提供されることを保証する。このソフトウェアは、ＵＤＰまたはＴＣＰなどのトランスポート層プロトコルに従って符号化されたデータ・パケットの更に他のヘッダを使用する。
【００２５】
本発明によるシステムのクライアント３は、ブロードキャスト・データ・パケットを受信する。上述のように、クライアント３によって受信された暗号化済データを有するパケットは、本発明による方法を使用して、暗号化されていないペイロードのフラグメントから生成されている。この好ましい実施形態において、フラグメント・サイズは、暗号化済データを有するパケットのサイズをネットワークの最大伝送単位以下に維持するように選択済みである。従って、それらは、フラグメントで到着せず、バッファする必要もなくす。
【００２６】
次いで、パケット内の暗号化済データは、本発明による受信したデータ・パケットを処理する方法を使用して、クライアント３で解読される。クライアント３は、受信したデータ・パケットに含まれる暗号化済データを解読するため、およびこの解読済データから、ネットワーク・プロトコル・スタック内のソフトウェアに渡すことができるデータ・パケット・フラグメントを生成するための、解読ユニットを備える。従って、クライアント３は、アプリケーションにクリア・マルチキャスト・データを与えることができる。
【００２７】
ヘッドエンド
本発明によるヘッドエンドの一実施形態４を図２に示す。このヘッドエンドは、ＩＰ暗号化システム５を含む。このシステム５は、通常、ヘッドエンド４で稼働するＰＣであり、ＩＰ暗号化を実行する何らかの特別なハードウェアを備えることができる。ＩＰ暗号化システム５は、１つまたは複数の暗号化されたマルチキャスト・チャネル／サービスを暗号化し管理する機能を有する１組のソフトウェアおよび／またはカスタマイズされたハードウェアである。サービスは、１つまたは複数のストリームからなる。例えば、サービスは、ストリーム１＝ビデオ、ストリーム２＝オーディオ１、ストリーム３＝オーディオ２と構成することができる。
【００２８】
暗号化システム５は、上述のタスク専用のサーバとして実施するか、または他の多数の機能を実行するＰＣ上で稼働するプログラムとすることができる。暗号化システム５は、暗号化システム５が常に利用可能でありサービスのいかなる中断も回避することを確実にするための、良好な冗長方式を使用して実施することが有利である。
【００２９】
暗号化システム５は暗号化ユニット６を備える。ＩＰ暗号化システム５の暗号化ユニット６はクリア・データ・パケットを取り出すものであり、クリア・データ・パケットは、クリア・データ・パケット・ヘッダ即ちＩＰヘッダと、アドレス即ちＩＰアドレスと、暗号化されていないペイロード、即ちブロードキャスト、マルチキャストまたはユニキャストされるデータとを含む。これらのＩＰデータ・パケットは、ソース７から出され、インターフェース８を介して暗号化ユニット６に渡される。ソース７は、マルチキャスト・ストリーマまたは他の任意の適切なコンテンツ・ソースでよい。インターフェース８は、ＩＰ／ＵＤＰプロトコルを使用して実施することが好ましいが、本発明は、ヘッドエンド４におけるコンポーネント間の通信に使用されるプロトコルに依存しないので、他の任意の適切なプロトコル、例えばＩＰ／ＴＣＰも使用することができる。
【００３０】
暗号化ユニット６は、パフォーマンス改善のために別のハードウェア・カードとして実施するか、またはサーバ上で稼働するコンピュータ・プログラムとして実施することができる。いかなる暗号化システム５においても、１つまたは複数のこれらの暗号化ユニット６があってよく、それらのユニットは、同じまたは異なる位置に配置することができる。暗号化ユニット６の出力は、暗号化済ＩＰパケットを含む。
【００３１】
暗号化ユニット６は、暗号化システム５に含まれる暗号化マネージャ９から受信した鍵を使用してデータを暗号化する。暗号化マネージャ９は、図２に記号で示す鍵生成機能１０を備える。
【００３２】
暗号化マネージャ９は、暗号化処理を管理するユニットである。暗号化マネージャ９は、以下の機能を有する。
・鍵サイクル期間（暗号化鍵がどれほどの頻繁で変更されるか）を指定すること。
【００３３】
・ＣＡシステム１３に対するインターフェース。
・送信されたＩＰパケットの生存時間（time to live）を判断すること。
・条件付きアクセス・メッセージをレシーバへ送信すること。
【００３４】
・アナウンスメントを受信するための外部スケジューラ、例えば、外部局管理システム、に対するインターフェース。アナウンスメントは、スケジューラからのストリームを定義するために使用される。これは、外部システムからのストリームを定義する一方法である。
【００３５】
・データを受信および送信するためのネットワーク・アタプタに対するインターフェース。
・暗号化されるべき静的サービスの暗号化。
【００３６】
・鍵を生成して暗号化ユニット６（１または複数）へ転送すること。
暗号化マネージャ９内の鍵生成機能１０は、設定された間隔で必要な長さのランダム鍵を生成するように要請される。実際に充分なセキュリティを提供することが証明された一実施形態は、ＩＰデータを暗号化するために５６ビットの鍵およびＢｌｏｗｆｉｓｈアルゴリズムを使用するが、任意の適切なアルゴリズムまたは鍵長を使用することができる。暗号化マネージャ９は、ローカル・スケジューラまたは外部局管理システム１１からアナウンスメントを受信して、ブロードキャストの新しいストリームを変更または定義することができる。外部局管理システム１１からのアナウンスメントは、外部局管理システム１１と暗号化マネージャ９の間のインターフェース１２を通過する。インターフェース１２は、例えば、ＩＰ／ＵＤＰプロトコルまたはＩＰ／ＴＣＰプロトコルを利用することができる。
【００３７】
ヘッドエンド４は、条件付きアクセス（conditional access）（ＣＡ）システム１３を更に備える。ＣＡシステム１３は、暗号化システム５上の１組のプログラム、または自体のハードウェア上で稼働するスタンドアロン・システムとして実施することができる。ＣＡシステム１３は、暗号化鍵およびアクセス条件を使用して資格制御メッセージ（Entitlement Control Message）（ＥＣＭ）を生成するＥＣＭジェネレータ１４を備える。鍵生成機能１０は前者を提供し、サービス・マネージャ１５は後者を提供する。
【００３８】
本発明の一部として、これらのＥＣＭは、データ・パケットとしてクライアント３に送信されるものであり、ＩＰＥＣＭと呼ぶ。解読情報を含むＥＣＭをデータ・パケットとして送信することによって、特定のサービスに属するデータを受信することをクライアント３に選択的に許可することができる。クライアント３が、鍵、および使用されるアルゴリズムなどのような他の解読情報を、特定のサービスと共に送信されたＥＣＭから抽出することができる場合のみ、クライアント３は、サービスの一部として提供されたコンテンツ・データを有するパケットを解読することもできる。
【００３９】
ＣＡシステム１３のＥＭＭジェネレータ１６は、同様にデータ・パケットとしてクライアント３へ送信されることを意図された資格管理メッセージ（Entitlement Management Message）（ＥＭＭ）を生成する。これらは、ＩＰＥＭＭと呼び、クライアントが特定のサービスを利用することを許可または不許可するために使用される。ＥＭＭおよびＥＣＭは条件付きアクセス・システムにおいて一般的に使用されることが当業界において知られており、本明細書では詳細には説明しない。
【００４０】
ＥＭＭジェネレータ１６は、加入者の詳細を含むローカル加入者管理システム（ＳＭＳ）１７、またはＳＭＳインターフェース１９を介してインターフェースする外部ＳＭＳ１８から、加入者管理コマンドを受信する。このインターフェース１９は、ほとんどの実施形態において、ＩＰ／ＴＣＰプロトコルまたは同様のネットワーク・プロトコルを使用して実施される。
【００４１】
加入者管理コマンドは、使用されるＣＡシステム１３の正確な実施によって要求されるフォーマットを有するが、通常は、
・加入者を活動化すること、
・加入者を非活動化すること、
・資格（アクセス・プロファイル）を付加すること、
・資格を削除すること、
・パスワードを設定／リセットすること、および
・ペイ・パー・ビュー（ＰＰＶ）のクレジットを得る／与えること
のためのコマンド、ならびにＣＡシステム１３の安全モジュールを管理するために必要な他の任意の機能のためのコマンドである。
【００４２】
インターフェース２０、２１は、サービス・マネージャ１５とＥＣＭジェネレータ１４との間、およびＳＭＳ１７とＥＭＭジェネレータ１６との間の通信のためにそれぞれ提供される。インターフェース２０、２１は、例えば、分散コンポーネント・オブジェクト・モデル、またはコモン・オブジェクト・リクエスト・ブローカ・アーキテクチャ（Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ）などのような同様のタイプのインターフェースを使用して実施することができる。
【００４３】
ＥＭＭおよびＥＣＭは、暗号化マネージャ９へ戻される。暗号化マネージャ９は、パケット・ヘッダ、追加情報ならびにチェックサムを付加し、ＩＰＥＣＭおよびＩＰＥＭＭメッセージを作成する。
【００４４】
鍵は暗号化マネージャ９からＥＣＭジェネレータ１４へ渡され、ＥＣＭはインターフェース２３を介して戻される。ＥＭＭは、ＥＭＭジェネレータ１６から暗号化マネージャ９へ、他のインターフェース２４を介して渡される。これらのインターフェース２３、２４は、ＩＰ／ＵＤＰおよびＩＰ／ＴＣＰプロトコルを使用して実施することができる。公開鍵暗号または他の任意の適切な方式などの知られている手法を使用して、ＩＰ暗号化システム５とＣＡシステム１３との間の通信を認証および暗号化することも可能である。
【００４５】
データ・パケットとしてクライアントへ送信されるためのＩＮＦＯ（情報）メッセージもまた作成され、ＩＰＥＣＭおよびＩＰＥＭＭの位置を示す。従って、サービスを識別し、サービス、ＩＰＥＭＭおよびＩＰＥＣＭに属するメッセージを受信するための情報を含む情報メッセージを、クライアント３へ送信することによって、それらのクライアントは、ＥＭＭおよびＥＣＭを符号化するパケットをどのように認識するかが分かる。データ・パケットを生成するためにインターネット・プロトコルが使用される場合、暗号化済データを有するパケットならびにＩＰＥＭＭおよびＩＰＥＣＭは、ＩＰアドレスまたはポートによって容易に識別することができる。クライアント３は、ＩＰヘッダ内のアドレスまたはＴＣＰまたはＵＤＰヘッダ内のポートによって、データ・パケットがサービスに属することを認識する。
【００４６】
ＩＰＥＭＭおよびＩＰＥＣＭは、任意の適切なネットワークを使用して、別のデータ・ストリームとしてクライアント３へ送信することができる。そのネットワークは、このコンテンツまたは他のコンテンツをブロードキャストするために使用されるのと同じネットワーク２でよい。ＩＮＦＯメッセージによりクライアント３がＩＰＥＣＭおよびＩＰＥＭＭを認識できるようになるので、それらを別々に送信することが可能である。
【００４７】
暗号化済コンテンツ・データを含むデータ・パケットおよびＣＡメッセージ（ＩＰＥＭＭ、ＩＰＥＣＭおよびＩＮＦＯメッセージ）を含むデータ・パケットを送信するために、ヘッドエンド４はネットワーク・インターフェース２５を有する。
【００４８】
本発明によるコンテンツ・データの安全なパケット・ベースのブロードキャスティングのための方法の一実施形態において、ＣＡメッセージを含むデータ・パケットには、暗号化済データを有するパケットとは異なる（ＩＰ）アドレスおよび／またはポートが提供される。これにより、メッセージを別のデータ・ストリームとして送信することが可能になり、換言すれば、帯域外で送信することが可能になる。また、メッセージの一部を含む各データ・パケットのヘッダにフラグを設定することによって、帯域外でメッセージを送信することも考えられる。これにより、そのメッセージが、暗号化済コンテンツ・データを含むパケットから区別できるようになる。
【００４９】
解読鍵が変更されるので、データ・パケットとして送信されるＣＡメッセージを別に扱うことは有利である。解読処理が停滞するのを防止するために、新しい鍵の下で暗号化されたデータを有するパケットがクライアント３に到着する前に、その新しい鍵がクライアント３で利用可能でなければならないことは、明らかである。
【００５０】
好ましい一実施形態では、ネットワーク２上を送信されるＩＮＦＯメッセージは、次のフォーマットを有する。
【００５１】
【表１】
0004813006.tif 000002
【００５２】
ネットワーク２上を送信されるＩＰＥＣＭの一実施例は、次のフォーマットを有する。
【００５３】
【表２】
0004813006.tif 000003
【００５４】
ネットワーク２上を送信されるＩＰＥＭＭの一実施例は次のフォーマットを有する。
【００５５】
【表３】
0004813006.tif 000004
【００５６】
ＩＰ暗号化システム５は、暗号化マネージャ９と暗号化ユニット６との間のインターフェース２２を備え、メッセージを利用するが、その中で、２つの重要なメッセージは、「ストリーム定義」メッセージおよび「鍵定義」メッセージである。
【００５７】
「ストリーム定義」メッセージは、ヘッドエンド４によって暗号化および配信されるアプリケーション・データ（クライアント３上のアプリケーションによって使用されるコンテンツ）の単一チャネルを定義する。単一「ストリーム」は、一意のＩＰアドレスおよびポートの組合わせによって識別される。例えば、アドレス２２４．０．０．１、ポート１００１で送信されるデータは、おそらく「オーディオ」という名前の単一ストリームであり得る。アドレス２２４．０．０．１、ポート１００２上のデータは、おそらく「ビデオ」という名前の他のストリームを含み得る。すべてのポートを指定することも可能であり、それにより、ストリームが自体上のＩＰアドレスによって識別される。メッセージは、サービスにストリームを追加すること、およびストリームを取り除くことの両方のために使用することができる。暗号化ユニット６からの応答メッセージは、「ストリーム定義」メッセージの受信を肯定応答（アクノレッジ）するために使用される。
【００５８】
「鍵定義」メッセージは、サービスに関連して使用される鍵を定義する。鍵長および鍵コンテンツは、このメッセージで指定される。この情報から生成されたＩＰパケットのための暗号化アルゴリズムおよび生存時間もまた、他の任意の追加情報とともに指定することができる。暗号化ユニット６から暗号化マネージャ９への応答メッセージは、「鍵定義」メッセージの受信を肯定応答するために使用される。
【００５９】
クライアント
図３に示すように、クライアント３のＩＰ解読システム２６は、ブロードキャスト、マルチキャストおよびユニキャストのＩＰデータを受信するためのＩＰレシーバ２７を備える。ＩＰレシーバ２７は、モデム、ネットワーク・インターフェース、またはネットワーク２からデータを受信することができる他の任意のデバイスでよい。
【００６０】
ＩＰレシーバ２７は、受信したデータ・パケットをクライアントのＮＤＩＳ層２８［ＮＤＩＳ：ネットワーク・ドライバ・インターフェース・スペシフィケーションは、ネットワーク・ドライバのための標準ＡＰＩ（アプリケーション・プログラム・インターフェース）である］へ渡す。ＮＤＩＳ層２８は、ＩＰフラグメントがＩＰスタック２９へ渡される前に、それらのＩＰフラグメントを得る可能性を提供する。好ましいネットワーク・ドライバ・インターフェース層として、ここでＮＤＩＳが指定されているが、ＩＰフラグメントがＩＰスタック２９へ渡される前にそれらのＩＰフラグメントに対するアクセスを提供する他の任意の層を使用することができる。
【００６１】
ＩＰスタック２９は、ＩＰパケットのフラグメントを受信すること、必要であればすべてが受信されるまでそれらフラグメントをバッファすること、次いでそれらフラグメントを完全なＩＰパケットに組合わせることの機能を有する。本発明において、解読ユニット３０は、ＮＤＩＳ層２８からのフラグメントを、スタック２９に渡される前に、インターセプトする。それぞれのフラグメントは、解読され、ＮＤＩＳ層２８を介してＩＰスタック２９へ直ちに渡され、それによってＩＰ解読ユニット３０においてバッファする必要をなくす。
【００６２】
本発明のこのエレメントは、解読処理がクライアント３に課す処理オーバヘッドが非常に小さいという効果を有する。ＮＤＩＳ層２８を介してＩＰスタック２９へフラグメントを渡すことは、暗号化処理の全体をＩＰスタック２９に対して透明にする利点を有する。ＩＰスタック２９は、ＩＰ解読ユニット３０へのインターフェースを提供するためにカスタマイズする必要がない。
【００６３】
本発明による安全なパケット・ベースのブロードキャスティングのための方法を使用すると、ＩＰパケットのサイズは、ブロードキャスト・ネットワーク２の最大送信単位に既に調整済みであろう。従って、クライアント３に到着する暗号化済データを有するフラグメントは、一般に、全ＩＰパケットを含み、その結果として、暗号化前のバッファは必要ない。
【００６４】
ＩＰ解読システム２６の他のエレメントは、解読マネージャ３１である。解読マネージャ３１は、インターフェース３２を介してＩＰスタック２９から受信したＩＰＥＣＭ、ＩＰＥＭＭおよびＩＮＦＯメッセージを処理する。解読マネージャ３１は、ＩＰＥＭＭおよびＩＰＥＣＭからＥＣＭおよびＥＭＭを抽出し、それらを安全エレメントへ送信する。その安全エレメントがコンテンツを受信することを許可されていれば、解読鍵は、その安全エレメントから返されて受信される。
【００６５】
安全エレメントは、安全ハードウェア、またはそれが実現可能であれば安全ソフトウェアにおいて実施することができる。図３に示す実施形態において、安全エレメントは、インターフェース３５を介してクライアント３に接続されたスマート・カード・リーダ３４に挿入されるスマート・カード３３である。インターフェース３５は、データ交換のための知られている標準、例えば、ペリフェラル・コンポーネント・インターフェースまたはユニバーサル・シリアル・バスを利用する。
【００６６】
解読鍵を含む情報は、ＩＰフラグメントを解読する際の使用のためにＩＯＣＴＬなどの低レベル通信方法を使用して、解読マネージャ３１から解読ユニット３０へインターフェース３６を介して送信される。
【００６７】
解読マネージャ３１は、それが受信するＩＮＦＯメッセージを使用して、ＩＰＥＣＭ、ＩＰＥＭＭおよび暗号化済コンテンツを見つける。インターフェース３６を介して解読マネージャ３１から解読ユニット３０へ送信される情報は、ＩＰアドレス、ＩＰポートおよび鍵を含む。
【００６８】
解読済ＩＰフラグメントがＩＰスタック２９によってＩＰパケットに組立てられると、これらのＩＰパケットが処理され、クリア・コンテンツが、アプリケーション３７、またはブロードキャスト・コンテンツを使用するクライアント３上のアプリケーションへ渡される。コンテンツは、表示すること、記憶媒体に格納すること、再フォーマットすること、またはコンテンツに対する他の任意の行為、あるいはコンテンツを他のデバイスまたはアプリケーションへ渡すことのために、使用することができる。解読処理全体は、アプリケーション３７に見えないまたは透明である。
【００６９】
解読マネージャ３１と解読ユニット３０との間に提供されるインターフェース３６は、メッセージを利用し、その中で２つの重要なメッセージは、サービスに対するコンテンツ・データのストリームを定義する「ストリーム定義」メッセージ、および新しい鍵を解読ユニット３０へ通信する「鍵定義」メッセージである。この好ましい実施形態において、「ストリーム定義」メッセージおよび「鍵定義」メッセージのフォーマットは、ＩＰ暗号化システム５において暗号化マネージャ９と暗号化ユニット６との間の通信に使用される同一の名前のメッセージのフォーマットと実質的に同じである。クライアント３の特定の構成次第では、解読マネージャ３１と解読ユニット３０との間の更なるメッセージが予見されるが、これらのメッセージは本発明の本質的なものではない。
【００７０】
暗号化ユニット処理
次に、ヘッドエンド１、４からクライアント３へのコンテンツ・データの安全なパケット・ベースのブロードキャスティングのための方法を、図４および５を参照しながらより完全に説明する。図４は、ヘッドエンド１、４で実行される１組の処理ステップを示す。図５は、クリアＩＰパケットおよび暗号化済データを有する生成されたＩＰパケットの様々なコンポーネントを示す。
【００７１】
ヘッドエンド１、４において実行される１つのステップ３８は、暗号化鍵を含むＣＡデータをヘッドエンド１、４において受信することを含み、そこからサービス・データが抽出される。暗号化ユニット６は、サービス・データ、即ち、ＩＰアドレス、ポート、暗号化鍵、およびアルゴリズム・タイプを、暗号化マネージャ９から受信する。これは、鍵またはサービス・セットアップが変更されるにつれて定期的に起こる。
【００７２】
その後のステップ３９において、暗号化ユニット６のルックアップ・テーブル４０が、受信したサービス・データを使用して更新される。このルックアップ・テーブル４０は、幾つかのデータ・ストリームのためのサービス・データを含むことができ、従って、ヘッドエンド１、４が、複数ソースからのデータおよび／または１つのソースからの複数ストリームを暗号化するのに適切なものになる。
【００７３】
ヘッドエンド１、４は、ソース７によって送信されたクリア・データ・パケットを取り出す。クリア・データ・パケットは、この場合、ＩＰアドレスを有するＩＰヘッダ４８およびトランスポート層プロトコル・ヘッダ４９（ＵＤＰまたはＴＣＰ）からなるクリア・データ・パケット・ヘッダを含む。クリア・データ・パケットは、暗号化されていないペイロードを更に含む。知られている手法を使用して、このデータ・パケットのフラグメントが、ヘッドエンド１、４への到着時にバッファされ、クリアＩＰパケットが構築される。
【００７４】
他のステップ４２において、、ＩＰアドレスまたはＩＰポートあるいはその両方がクリア・データ・パケットのＩＰヘッダ４８から抽出され、それにより、適切な暗号化データ、本質的には暗号化鍵および使用するアルゴリズムを、ルックアップ・テーブル４０で見つけることができるようにする。このルックアップ・テーブル４０をチェックすることは、ステップ４３において記号で表される。
【００７５】
他のステップ４４において、ＩＰデータ・パケットが再フラグメント化される。これは、暗号化されていないペイロードが１つまたは複数のフラグメントに分割されて、そのフラグメントに、その後のステップ４５において暗号化アルゴリズムが適用されることを意味する。例示目的のために、図５のクリア・データ・パケットの暗号化されていないペイロードは、２つのフラグメント５０、５１に分割される。その結果の暗号化済フラグメントは、それぞれ参照番号５２および５３によって表記されている。
【００７６】
この好ましい実施形態において、フラグメント５０、５１のサイズは、この処理の結果として作成される暗号化済データを有するパケットのサイズをブロードキャスト・ネットワーク２の最大送信単位より下に維持するように選ばれる。従って、本方法は、暗号化処理の結果としてデータに付加されたいかなる特別な長さも考慮に入れる。これは、送信における利点を提供する。なぜなら、本発明の方法を使用して組み立てられた暗号化済データを有するパケットは、ブロードキャスト・ネットワーク２を介してそれ自体の進路上で送信された後に、再び再フラグメント化する必要がないからである。
【００７７】
本発明による方法において重要なステップ４６は、それぞれの暗号化済フラグメント５２、５３のための暗号化ヘッダ５４、５５を生成することである。暗号化ヘッダ５４、５５は、それぞれの暗号化済フラグメント５２、５３に付加されて、生成されるパケットのための新しいペイロードを形成する。
【００７８】
暗号化済ペイロード全体および暗号化ヘッダを含むパケットのデータ・サイズが、ブロードキャスト・ネットワーク２の最大送信単位を超過すると判断された場合、ソース７から受信されるクリア・データ・パケットのペイロードは、ステップ４４において、少なくとも２つのフラグメントに分割済みであろう。本発明のこの好ましい実施形態において、第１フラグメント５０のための暗号化ヘッダ５４は、ＵＤＰまたはＴＣＰチェックサムと、元のデータ・パケットの長さとを含む。
【００７９】
少なくとも１つのフラグメントに対する暗号化ヘッダに、クリア・データ・パケットの長さに関する情報と、暗号化されていないペイロードのチェックサムに関する情報とが提供されるので、クライアント３の１つにおいてクリア・データ・パケットを再組立てすることは、はるかに簡単になる。暗号化済データを有するパケットは、クライアント３にフラグメントで到着し、そのフラグメントは、暗号化済データを有する１つのパケットのフラグメントのすべてが到着するまで別々にバッファ記憶することはせずに、到着時に直接に暗号化してＩＰスタック２９へ渡すことができる。従って、バッファ・スペースおよびパフォーマンス・オーバヘッドは、解読側で節約される。ＩＰスタック２９のソフトウェアは、クリア・データ・パケットを再組立てすることができる。そのためには、チェックサムおよびパケット長は、第１フラグメントに存在しなければならない。
【００８０】
他方の暗号化済フラグメント５３のためにヘッドエンド１、４において生成された暗号化ヘッダ５５は、クリア・フラグメント５１のフラグメント・オフセットを含む。従って、それぞれの更なるフラグメントのための暗号化ヘッダに、第１フラグメント５０に対してのその更なるフラグメントのオフセットを含む情報が提供される。クリア・データ・パケットの更なるフラグメントから生成された暗号化済データを有するそれぞれのパケットは、到着すると直ちに解読され、ＩＰスタック２９へ転送することができ、そこで完全なクリア・データ・パケットが再組立てされる。
【００８１】
クライアント３が、第１フラグメント５０から生成された暗号化済データを有するパケットと、更なるフラグメントから生成されたパケットとを区別できるようにするために、パケットが、暗号化されていないペイロードの第１フラグメントからの暗号化済データを含むかまたは他のフラグメントからの暗号化済データを含むかを示すフラグが、暗号化ヘッダ５４、５５に提供される。これは、暗号化ヘッダはより小さくてよいことも意味する。なぜなら、暗号化ヘッダのデータ・フィールドが、暗号化されていないペイロードの長さおよびチェックサム、またはオフセット値のいずれかを符号化するために使用されるからである。
【００８２】
「スタックより下」、即ち、暗号化済データを有するパケットがクライアント３のＩＰスタック２９を通過する前、の解読が好ましいが、「スタックより上」の解読を妨げる必要はない。本発明のこの好ましい実施形態において、暗号化および特別な長さが暗号化アルゴリズムによって追加される前に、フラグメントの長さを表す情報が、それぞれのフラグメントのための暗号化ヘッダ５４、５５内に符号化される。この情報で、標準プロトコル・ヘッダ（ＩＰ／ＴＣＰ、ＩＰ／ＵＤＰ）をクライアント３で変更することができ、暗号化済データを有するパケットの暗号化済ペイロード５２、５３および暗号化ヘッダ５４、５５が、クライアント３において正しく抽出されることを保証する。
【００８３】
本発明のこの好ましい実施形態において、暗号化ユニット６によって使用される暗号化アルゴリズムは、鍵の長さと同様に、幾つかの利用可能な代替物の１つから選択することができる。従って、暗号化ヘッダ５４、５５には、フラグメント５０、５１に適用される暗号化アルゴリズムを指定する情報が提供される。
【００８４】
図４に戻ると、最後に表されたステップ４７は、暗号化済データを有するパケットを組み立てることを含む。ＩＰフラグメント・ヘッダ・チェックサムおよび長さは、暗号化済データ・フラグメント５２、５３の新たなペイロードおよび暗号化ヘッダ５４、５５に基づいて変更される。ＩＰヘッダ５６、５７と、第１の暗号化済フラグメント５２のためのトランスポート層プロトコル・ヘッダ５８とを含むフラグメント・ヘッダが、新しいペイロードに追加されて、暗号化済データを有するパケットを完成させる。次いで、このように組み立てられた暗号化済データを有するパケットは、クライアント３へ送信される。パケットがブロードキャストされるか、マルチキャストされるか、またはユニキャストされるかによって、標準によって提供される可能性を使用して、適切なアドレスが、ＩＰヘッダ５６、５７内に符号化される。
【００８５】
解読ユニットの処理ステップ
暗号化済データ・パケットを処理する方法を、図６および７を参照しながらより完全に説明する。図６は、クライアント３で実行される幾つかの処理ステップを示す。図７は、暗号化済データを有するパケット、例えば、図５の第１の暗号化済フラグメント５２を含むパケットが、どのように処理されて、クライアント３のＩＰスタック２９に渡すことができるクリア・データ・パケット・フラグメントを生成するかを示す。
【００８６】
ステップ５９へ周期的に戻ることは、解読ユニット３０が、サービス・データ６０、即ち、ＩＰアドレス、ポート、暗号化鍵およびアルゴリズム・タイプを、解読マネージャ３１から受信するときに起きる。このステップ５９は、鍵またはサービス・セットアップが変更になるときはいつも行われる。
【００８７】
解読ユニット３０は、そのユニットが解読することができるサービスに対するルックアップ・テーブル６２を維持する。このテーブル６２は、新しいサービス・データ６０で更新される。図３の説明で説明したように、解読マネージャ３１は、安全エレメントと共に働いて、クライアントがデータ・パケットとして受信した条件付きアクセス・メッセージから、このデータ６０を生成する。
【００８８】
暗号化済データを有するデータ・パケットまたはデータ・パケット・フラグメントは、クライアント３の１つで受信され、ＮＤＩＳ層２８を介して解読ユニット３０によって受信される。図７を参照すると、一例として提供された暗号化済データを有するパケットは、ＩＰヘッダ６７、ＴＣＰまたはＵＤＰヘッダでよいトランスポート層プロトコル・ヘッダ６８、暗号化ヘッダ６９、および暗号化済ペイロード７０を含む。図５の議論において説明したように、トランスポート層プロトコル・ヘッダ６８は、暗号化済データを有するパケット全てに含まれる必要はないことに留意されたい。
【００８９】
本方法内のその後のステップ６３において、解読ユニット３０は、暗号化ヘッダ６９およびＩＰアドレスを抽出する。そのユニットは、暗号化ヘッダ６９からクリア・データ・パケット・フラグメントのための宛先ポートも得る。
【００９０】
本発明のこの好ましい実施形態において、ルックアップ・テーブル６２は、受信したデータ・パケットにおいて指定されたＩＰアドレスまたはＩＰポートあるいはその両方を、暗号化済ペイロード７０を解読する鍵へリンクする。ＩＰアドレスおよびＩＰポートを使用して、解読ユニット３０は、本方法のその後のステップ６４において、解読鍵を含む解読情報をルックアップ・テーブル６２から取り出す。
【００９１】
この好ましい実施形態において、任意の一時点において複数の鍵が有効（妥当）であり、暗号化ヘッダ６９内の鍵インジケータまたはフラグは、ルックアップ・テーブル６２からこれらの鍵のどれを取り出すべきかを示す。例えば、任意の一時点において、２つの鍵が妥当である場合、サービス・データ６０は、どちらがオッド（odd）でどちらがイーブン（even）の鍵であるかを示す。暗号化ヘッダ６９のフラグは、暗号化済ペイロード７０が、オッド鍵で暗号化されたかまたはイーブン鍵で暗号化されたかを示す。これは、ＥＣＭがコンテンツ・データのストリームに含まれる必要がないこと、または暗号化済データを有するパケットのストリームにおいて順に並べる必要がないことの利点を有する。任意の一時点において、１つの鍵だけが妥当である場合、その鍵は、前の鍵の下で暗号化されたデータを有する最後のパケットと、新しい鍵の下で暗号化されたデータを有する最初のパケットとの間に、解読ユニット３０に到着しなければならない。
【００９２】
解読アルゴリズムは、その後、暗号化済ペイロード７０に適用されて、クリア・データ７１を生成する。クリア・データ・パケット・ヘッダもまた生成される。図７の実施例において、これは、ＩＰヘッダ７２およびトランスポート層プロトコル・ヘッダ７３を含む。暗号化ヘッダ６９内に符号化された情報を使用して、宛先ポートが、クリア・データ・パケット・フラグメントのＴＣＰまたはＵＤＰヘッダ７３に含まれ、それにより、クリア・データ７１が、正しいアプリケーション３７に対して入力として提供される。
【００９３】
暗号化済データを有するパケットが、１組の関連フラグメントの第１のフラグメントである場合、暗号化ヘッダ６９には、クリア・データ・パケットの長さに関する情報、および暗号化されていないペイロードのチェックサムに関する情報が提供済みである。この情報は、解読ユニット３０によって暗号化ヘッダ６９から抽出され、トランスポート層プロトコル・ヘッダ７３を生成するために使用されて、ＩＰスタック２９においてクリア・データ・パケット・フラグメントからクリア・データ・パケットを再組立てすることを可能にする。
【００９４】
暗号化済データを有するパケットが、１組の関連するフラグメントの第１のフラグメントでない場合、暗号化ヘッダ６９には、その更なるフラグメントの第１のフラグメントに対してのオフセットを含む情報が提供済みである。解読ユニット３０は、それ自体が生成するクリア・データ・パケット・フラグメントのＩＰヘッダ７２にこのオフセット値を含め、従って、関連するフラグメントのグループをＩＰスタック２９において１つのクリアＩＰパケットに連結することを可能にする。連結のために必要なデータ・パケット・フラグメントのバッファ記憶がこのようにＩＰスタック２９において行われることは、本発明の非常に有利な機能である。本発明の方法を使用して、解読ユニット３０は、クリア・データ・パケット・フラグメントが生成されると直ちに、ＮＤＩＳ層２８を介してＩＰスタック２９へそれぞれのクリア・データ・パケット・フラグメントを渡すことができる。
【００９５】
暗号化ヘッダ・フォーマット
以下の表は、本発明によるシステムにおいて使用される暗号化ヘッダ・フォーマットの有利な一実施例を示す。
【００９６】
【表４】
0004813006.tif 000005
【００９７】
様々なネットワーク・タイプ
本発明をＩＰパケットに関してここに述べているが、本方法は、メッセージが断片に分解され、ネットワークを介して送信され、受信システムまたは端末、即ちクライアントで再構築されるものである他のどのプロトコルにも適用することができる。幾つかの実施例は、ＧＰＲＳやＵＭＴＳなどの無線電話ネットワークを送信されるデータ・パケットである。解読システム２６は、ＩＰパケットを受信するように設計されたどの端末上にも実施することができる。実施例には、移動電話、パーソナル・デジタル・アシスタント、そしてＤＶＤブレイヤ、デジタル・パーソナル・ビデオ・レコーダなどのＩＰ対応家電製品が含まれる。ＩＰＥＭＭ、ＩＰＥＣＭおよびＩＮＦＯメッセージを帯域外で、即ち、暗号化済データを有するパッケージのストリームとは別に送信する機構は、マルチキャストやブロードキャストのサービスでＩＰ暗号化済パケットを配信するどのネットワークにも等しく応用することができる。
【００９８】
ＩＮＦＯメッセージのための他の使用法
ＩＮＦＯ／ＩＰＥＣＭメッセージは、ブロードキャスト、マルチキャスト、またはユニキャストされるサービスに関するより多くの情報を含むように拡張することができる。この方法を使用して、サービスに対するイベントに関するイベント情報、即ち、ＩＰ暗号化済ブロードキャストおよびマルチキャストのためのある種のプログラム・ガイドを、ブロードキャストすることができる。そのコンパクトにされたという特性により、このタイプの情報は、帯域幅、受信クライアントのアプリケーション・スペース、およびクライアントの表示サイズが限定的である移動電話ネットワークなどのブロードキャスト・サービスで有用である。
【００９９】
様々なシステム構成
図８および図９は、本発明によるシステムの実施例の２つの異なる構成を示す。図８の構成において、システムを実施する２つの異なる方法を述べる。以下に提供する３つの実施例は、本発明によるシステムの多数の可能な応用例を例示する役割を果たすに過ぎない。本発明は、もちろんこれら３つの実施例に限定されない。
【０１００】
図８は、ヘッドエンドが、ＩＰ暗号化システム５を含む第１コンピュータ７４を含む一実施形態を示す。暗号化済データ・パケットは、このコンピュータ７４において生成される。顧客の世話および請求は、第２コンピュータ７５から指図され、そのコンピュータは、例えば、図２の外部ＳＭＳ１８または外部局管理システム１１として機能し、ヘッドエンド７４からのＥＭＭブロードキャストまたはＩＮＦＯメッセージを介して、誰がどのサービスにアクセスを有するかを制御する。デジタル・コンテンツ・サーバ７６は、図２のソース７に相当する。
【０１０１】
暗号化済データ・パケットは、第１ネットワーク７７を介して受信側クライアント７８へブロードキャストされる。他のクライアント７９〜８１は、第２ネットワーク８２を介して受信側クライアント７８に接続される。この図において、第１ネットワーク７７は衛星ネットワークとして示され、第２ネットワーク８２は、インターネット、ケーブル・ネットワーク、ＤＳＬネットワーク、地上局による送信、または無線として示される。ネットワーク７７、８２は、もちろん任意の順、例えば、第１ネットワーク７７がインターネットで、第２のもの８２が無線ネットワーク等であるように、使用することができる。
【０１０２】
本システムの最も基本的な形態は、エンド・クライアント７９〜８１で解読が行われる好ましい実施形態において述べたものである。即ち、データがクライアントに達する前に、中間の解読は何も行われない。
【０１０３】
第２構成では、コンテンツが、複数のタイプのネットワークを横断することができ、受信側クライアント７８に含まれるＩＰ解読システム２６によって解読され、次いで、第２ネットワーク８２上をクリアでブロードキャストまたはマルチキャストされる。
【０１０４】
他の構成では、コンテンツが、クライアント７９〜８１の１つに達する前に、複数のタイプのネットワークを横断することができる。コンテンツは、第１ネットワーク７７を介して受信された後に、受信側クライアント７８に含まれるＩＰ解読システム２６によって解読される。しかし、そのまま伝えられる代わりに、図９に示すように、クリア・データが、暗号化システム５を備えるコンピュータ８３において本発明の方法を使用して再暗号化されてから、最終のネットワーク８２へマルチキャストされる。この図では、第１のネットワークが衛星ネットワーク７７であり、第２のネットワーク８２は、インターネット、ケーブル、ＤＳＬ、地上または無線ネットワークである。ネットワークはもちろん任意のシーケンスで使用することができる。
【０１０５】
本発明は、上述の実施形態に限定されることなく、請求の範囲内で幾つかの態様に変更できることが、当業者には明らかであろう。例えば、図８および図９の構成の他に、システムの幾つかの追加の構成が可能である。更に、ヘッドエンドにおいて組み立てられる様々なメッセージおよびヘッダのコンテンツの変形形態または追加が考えられ、それはＩＰ／ＴＣＰやＩＰ／ＵＤＰプロトコル以外のプロトコルを利用する実施例を含む。
【図面の簡単な説明】
【図１】  図１は、マルチキャスティングに適切な、本発明によるシステムの一実施形態の一般的概観を示す。
【図２】  図２は、本発明による安全なパケット・ベースのデータ・ブロードキャスティングのための方法を実行するのに適切な、本発明によるシステムの一実施形態におけるヘッドエンドのコンポーネントの図である。
【図３】  図３は、本発明によるクライアントのコンポーネントの図である。
【図４】  図４は、暗号化処理における選択されたステップを含む流れ図である。
【図５】  図５は、本発明による方法を使用しての暗号化されたデータを有するパケットの生成を示す図である。
【図６】  図６は、解読処理における選択されたステップを含む流れ図である。
【図７】  図７は、本発明による方法を使用しての暗号化されたデータを有するパケットからクリア・データ・パケット・フラグメントの生成を示す図である。
【図８】  図８は、エンド・クライアントまたはゲートウェイの解読を実施することができる衛星マルチキャスティングを使用する、本発明によるシステムの一実施形態の概観図である。
【図９】  図９は、衛星およびインターネットの組合わせの環境でのエンド・クライアントの解読の図である。
【図１】
0004813006.tif 000006
【図２】
0004813006.tif 000007
【図３】
0004813006.tif 000008
【図４】
0004813006.tif 000009
【図５】
0004813006.tif 000010
【図６】
0004813006.tif 000011
【図７】
0004813006.tif 000012
【図８】
0004813006.tif 000013
【図９】
0004813006.tif 000014