JP2005526329A - アクセスコントロール付きデータ配信処理方法及びマネージメントプラットフォーム - Google Patents

Abstract

本発明は、ＩＰデータ伝送ネットワークを介してサービスプロバイダに接続された複数のユーザー端末（２）にデジタルデータを配信するための処理に関し、各ユーザー端末（２）は、セキュリティプロセッサに入力されたユニークアドレスＵＡとＩＰアドレスとによってネットワークにおいて識別される。本発明による処理は、ＨＴＴＰプロトコルレベルで規定されたアクセス条件を配信用のデータに関連づけることにある。

Description

本発明は、アクセスコントロールの技術分野に属し、更に詳しくはＩＰデータ伝送ネットワークを介してサービスプロバイダに接続された複数のユーザー端末にデジタルデータを配信(distribute)するための処理に関し、各配信先の端末は、セキュリティプロセッサに入力されたユニークアドレスＵＡとＩＰアドレスとによってネットワークにおいて識別される。

フランステレコム(France TELECOM)によって２００２年１０月２９日に出願されたフランス特許出願第０１−１３９６３号では、ＩＰネットワークに接続された複数の端末に対するオーディオビジュアルプログラムのアクセスコントロール付き配信のために処理が述べられている。

この処理では、ネットワークを介して提供される各サービスは、サービスプロバイダによって規定されたアクセス条件(access conditions)およびアドレスが割り当てられる。スクランブリングプラットフォームは、データサーバーにより普通語で提供される入力ＩＰ／ＵＤＰデータグラムを受け取り、そしてそのＩＰ／ＵＤＰデータグラムを、これらデータグラムのヘッダに存在する宛先ポート(destination ports)及びアドレスの関数としてスクランブルされるべきデータからフィルタする。

このソリューションは、通常、ユニキャストユーザー端末ＩＰアドレスが動的に割り当てられ、またセッションによって異なるという事柄から生じる欠点を抱えている。その結果、これらのＩＰアドレスは、カスタマと共に或るセッションから他のセッションへの入れ替わりの発生について信頼性ある手段を構築することができない。

更に、ポイント・トゥ・ポイントモードでは、（ＩＳＯ ３）ネットワークレイヤレベルで条件付きアクセス（ＣＡ）基準(conditional access criterion)をコンテンツに関連づけることが困難であるという事柄から他の欠点が生じる。

本発明の目的は、一方ではサービスを要求するユーザー又はユーザー達との相関関係において、他方では配信されたコンテンツとの相関関係において配信モードでアクセス条件を規定すると共にポイント・ツゥ・ポイントモードでアクセス条件を規定することを可能にする処理によって上述の従来技術の欠点を克服することにある。
フランス特許出願第０１−１３９６３号

更に詳しくは、本発明は、データ配信をアドレス変化に依存させないようにするために、ＩＰパラメータに関連したネットワークレイヤ（ＩＳＯレイヤ３）レベルではなく、プレゼンテーションレイヤ（ＩＳＯテンプレートや６）レベルでアクセス条件を規定することを可能にする。

本発明によれば、ＨＴＴＰプロトコルレベルで規定されたアクセス条件は配信データと関連づけられる。

本発明の第１の選択的実施においては、データは、次のステップ、即ち、
・ユーザー端末から、少なくとも、前記端末のＩＰアドレスを備えるＨＴＴＰリクエストと、データをコンテンツサーバーにローカライズすることのリクエストを可能にする（ＵＲＩ）パラメータ及びユニークアドレスＵＡとを送信するステップ：
・前記ユニークアドレスＵＡによって前記ＨＴＴＰリクエストの送信者を認証するステップ：
・前記コンテンツサーバーおよびスクランブリングユニットに前記ＨＴＴＰリクエストを送信すると共に、前記ＨＴＴＰリクエストに対する応答を受信するステップ：
・少なくとも前記サービスプロバイダによって予め規定された条件付きアクセス（ＣＡ）基準を有するアクセスコントロールフィールドおよび（ＵＲＩ）パラメータを備えたＨＴＴＰヘッダを、リクエストされた各データパケットに関連づけるステップ：
・前記リクエストされたデータをスクランブルするステップ：
・前記スクランブルされたデータを前記条件付アクセス（ＣＡ）基準と共に前記ユーザー端末に送信するステップ：
に従って、ポイント・ツゥ・ポイントモードで配信される。

前記条件付きアクセス（ＣＡ）基準および前記（ＵＲＩ）パラメータは、例えば、プレゼンテーションサーバー上で、前記サービスプロバイダにより予めユーザーに利用可能とされる。

本発明の上記第１の選択的実施において、各ユーザーに対し、カスタマイズされたＥＣＭが、条件付きアクセス（ＣＡ）基準の関数および暗号化されたコントロールワードＣＷの関数として生成される。コントロールワードＣＷは、サービスプロバイダに特有なルートキーＫｅの多様性(diversification)によって得られたキーＫｅ_ＵＡによって暗号化される。この多様性は、各ユーザーに特有なユニークアドレスＵＡの関数として実施される。

本発明の第２の選択的実施において、前記データは、配信モードでグループアドレスによって識別されるユーザー端末のグループに配信される。この配信は、次のステップ、即ち、
・ＨＴＴＰリクエストを、前記グループアドレスと共に中央サーバーに送信するステップ：
・前記リクエストの送信者を認証するステップ：
・前記リクエストされたコンテンツが配信されたことを検証するステップ：
・前記リクエストされたコンテンツが配信されなければ、前記ユーザーにストップメッセージを送信するステップ：
に従って実行される。

本発明のこの第２の選択的実施においては、データは、英語で一般に呼ばれるようなプッシュ(PUSH)配信モードで送信される。この伝送モードでは、グループアクセスにより識別された全ユーザーは、ＨＴＴＰリクエストを介して配信を起動する従前の義務を有することなく、利用可能な配信デジタルデータを受信する。それでもやはり、ユーザー、通常はサービスを受信するために最初のＨＴＴＰリクエストを送信した第１ユーザーによって、配信がコントロールされてもよい。また、このユーザーは、第２のＨＴＴＰによりデータの配信を止めることもできる。このことは、特定のユーザーが、コントロールが及ぶところの多くの他のユーザー情報に利用可能としているときに特に有用である。これは、例えば、教師と多くのリスナーが伝送ネットワークに接続された通信教育アプリケーションにおけるケースであり、教師は、コンテンツの配信（アクチベーション及びカットオフ）をコントロールするユーザーである。

この二つの選択的な実施において、スクランブルされたデータは、ＩＰデータグラムにカプセル化され、このＩＰデータグラムは、
・ＩＰヘッダ
・ＴＣＰ／ＵＤＰヘッダ
・ＨＴＴＰヘッダ
・前記アクセス条件を含むヘッダ
を備える。

或る特定の実施形態において、セキュリティプロセッサはチップカード(chip card)である。しかしながら、このプロセッサは、ユーザー端末に格納されたプログラムであってもよい。

また、本発明は、ＩＰネットワークを介してサービスプロバイダに接続された複数のユーザー端末に送信されるスクランブルデータに対するアクセスをコントロールするためのマネージメントプラットフォームに関し、各ユーザー端末は、セキュリティプロセッサに入力されたユニークアドレスＵＡにより及びＩＰアドレスによりネットワークにおいて識別され、前記プラットフォームは、少なくとも、ユーザー端末から送信されたＨＴＴＰリクエストに応答してＨＴＴＰプロトコルレベルで配信用のデータにアクセス基準を関連づけることができる中央サーバーを備える。

好ましくは、配信用のデータは、コンテンツサーバーから（ＵＲＩ）パラメータの関数として抽出され得る。
更に、本発明によるプラットフォームは、少なくとも一つのスクランブリングユニットと、少なくとも一つのコンテンツサーバーを備える。
配信用のデータは、オーディオビジュアルプログラムまたはマルチメディアデータであってもよい。

本発明の他の特徴及び利点は、以下の説明から明らかとなり、添付の図面を参照して非制限的な例として与えられるであろう。

本発明は、配信用のデータが、インターネットのネットワークを介して多くのユーザーに送信されるオーディオビジュアルプログラムであるところの特定のアプリケーションである状況において述べられる。各ユーザーは、チップカードリーダが取り付けられた端末２を備える。各ユーザーは個人チップカード(personal chip card)を有し、この個人チップカードは、１又は２以上のオペレータ(operator)によって提供されるオーディオビジュアルサービスに対するアクセス権に関する情報を含むユニークアドレスＵＡにより識別される。

特定の実施形態において、各ユーザー端末は、ローカルネットワークにグループ化される複数の端末と通信するゲートウェイ端末であってもよい。この場合、ゲートウェイ端末には、提供されるサービスに対する少なくとも一つのアクセス権を有するチップカードが取り付けられる。

オーディオビジュアルコンテンツはリモートサーバーに格納され、そして各コンテンツは、資源(resource)がユニークな方法で指定されることを可能にするＨＴＴＰヘッダのフィールドであるところのＵＲＩ(Uniform Resource Indicator)によって呼び出すことが可能である。

以下では、ユーザーへの送信に先だってオーディオビジュアルフローを処理するための全ての装置を、ＶｉａｃｃｅｓｓＮｅｔ（登録商標）プラットフォームなる用語で表す。

図１を参照すると、ユーザー端末２は、インターネットネットワーク６またはＩＰトランキング(IP trunking)を介してＶｉａｃｃｅｓｓＮｅｔ（登録商標）プラットフォーム４に接続される。第１出力ルーター８は、インターネットネットワーク６の出力に設けられ、且つ、ＶｉａｃｃｅｓｓＮｅｔ（登録商標）プラットフォーム４に直接的に接続されたファイアーウォールサーバー１２に接続される第２相互接続ルーター１０に接続されている。

ＶｉａｃｃｅｓｓＮｅｔ（登録商標）プラットフォーム４は、中央サーバー１６を備え、この中央サーバー１６の機能は、ユーザー端末２とプラットフォーム４との間の通信を管理するためのものである。

第１ローカルネットワーク１４は、更に、サービスプレゼンテーションページ(service presentation page)のようにスクランブルされる必要のない情報を格納するためのキャッシュサーバー１８と、例えば、ＶｉａｃｃｅｓｓＮｅｔ（登録商標）プラットフォーム４の内部または外部のサーバーのＩＰアドレスをネームとして表現するためのＤＮＳサーバー２０と、中央サーバー１６の機能的な冗長性を提供するための第２セキュリティサーバー２２を備える。この第１ローカルアクセスネットワーク１４は、スクランブリングステーション２４を介して、第２ローカルネットワーク２６と第３ローカルネットワーク２８とに接続される。第２ローカルネットワークはコンテンツサーバー３０を備え、第３ローカルネットワーク２８は、ＥＣＭジェネレータ３２及びＥＣＭマネージメントステーション３４を備える。

＜ポイント・トゥ・ポイントモード＞
ポイント・トゥ・ポイントモードにおける動作は、処理の実施に不可欠な端末のみが示された図２を参照して説明される。この図２において、中央サーバー１６は、二つの別々の機能ユニット、即ちプラットフォーム４に送信されるＨＴＴＰのフィルタリングおよびユーザー認証を行うための第１ユニット４０と、（ＣＡ）コントロール基準を配信用のデータに関連づけるための第２ユニット４２とから構成される。ユーザー認証は、ＨＴＴＰリクエストと共に受信されたＵＡが、オペレータに配置されたライトマネージメントセンター４４においてリストされるかどうかを検証することである。

これに先だって、１又は２以上のオーディオビジュアルプログラムを希望するユーザーは、リクエスト可能なオーディオビジュアルプログラムをアクセスするための（ＣＡ）基準に関する情報をオペレータから受信する。

プレゼンテーションサーバー４６に問い合わせた後、ユーザーは、リクエストされたプログラムに対応するＵＲＩおよびＩＰアドレスと、そのユニークアドレスＵＡを与えるＨＴＴＰ取得リクエストを中央サーバー１６に送信する（矢印５０）。認証ユニット４０は、ユニークアドレスＵＡによってＨＴＴＰリクエストをフィルタし、そして次の動作を実行する。
・暗号化されたデータグラムトランスポートレベルでフローをコントロールすること。具体的には、このユニット４０は、ＴＣＰフィードバックパケットが、プラットフォーム４と顧客端末２との間の最大伝送遅延内で受信されることをチェックする。
・前のコントロールに続いてセッションをコントロールすること。実際には、セッションは、最大伝送遅延を超過すれば中断される。

そして、中央サーバー１６は、データの送信元のＩＰアドレスであってユーザーによってプレゼンテーションサーバー４６から読み取られるＩＰアドレスのみならず、要求されるＵＲＩおよびユーザーのＵＡアドレスと、リターンパスのための端末２のＩＰアドレスをオペレータのマネージメントセンタ４４に送信する（矢印５２）。

マネージメントセンタ４４は、データベース５６に予め記録された権利(rights)に応じて、コンテンツに対するアクセス（矢印５４）を拒否するか、またはその同意を与える。

そして、ユーザー端末のＩＰアドレスおよびＵＲＩ、ＵＡアドレスは、中央サーバー１６によりＨＴＴＰリクエストを用いてスクランブリングユニット２４に送信される（矢印５８）。コンテンツに関連する条件付きアクセス（conditional access；ＣＡ）基準(criterion)もこの方法で送信される。これらの全パラメータは、スクランブリングユニット２４が、中央サーバー１６を介してコンテンツサーバー３０から到来するＨＴＴＰリクエストに対する応答を識別することを可能にするであろう。

スクランブリングユニット２４は、関連するＵＡおよびＩＰアドレスおよび条件付きアクセス（ＣＡ）基準と共に、ユーザーによって選択されたスクランブリングのためのフローをコンテンツサーバー３０から待っていることを確かめる認証ユニット４０に確認応答(acknowledgement)（矢印５９）を送信する。

そして、ＨＴＴＰ取得リクエストは、認証ユニット４０を介してユニット４２に再送信される（矢印６０）。後者は、ＵＲＩに注目することによりそのリクエストを考慮し、そして他ならぬこのＨＴＴＰ取得リクエストをコンテンツサーバー３０に送り返す（矢印６１）。

そして、コンテンツサーバー３０から中央サーバー１６に送信されたＨＴＴＰ取得リクエストに対する応答はユニット４２に送り返される（矢印６２）。後者は、補助的フィールド(supplementary field)を、スクランブリングユニット２４にＵＲＩを思い起こさせる“コンテンツロケーション”フィールドと共にＩＰフィールドに挿入する。中央サーバー１６は、スクランブルを行うスクランブリングユニット２４にＨＴＴＰ応答を送信する（矢印６４）。

スクランブリングユニット２４は、データをスクランブルして、それをユーザー端末２に送信し（矢印６６）、ユーザー端末２は、それを、チップカードに入力された権利と送信されたコントロール情報とを用いてアンスクランブル(unscramble)して元の状態に戻す。

図３は、中央サーバー１６によってスクランブリングユニット２４に送信されるパケットの構成を図式的に示す。このＨＴＴＰ応答は、
・ＩＰヘッダ７０、
・ＴＣＰ／ＵＤＰヘッダ７２、
・ＨＴＴＰヘッダ７４、
・配信されるデータのＵＲＩを含むアクセスコントロールヘッダ７６、および
・スクランブルされたデータ８０
を備える。

図４における構成チャート(organization chart)は、ポイント・ツゥ・ポイントモードでの実施例における処理での異なるステップを詳細に示す。

ステップ９０では、ユーザーは、コンテンツを要求するためのＨＴＴＰ取得リクエストを、ユーザー端末２とＶｉａｃｃｅｓｓＮｅｔ（登録商標）プラットフォーム４との間の暗号化されたトンネル(tunnel)による安全リンク(secure link)を介して中央サーバー１６に送信する。

この安全なトンネルは、端末２と共に各リンクに特有であり、セキュアソケットレイヤ(Secure Socket Layer; SSL)プロトコルまたはセキュアシェル(SSH)プロトコルに基づくことができ、またＩＰＳｅｃプロトコルに基づくことができる。セキュリティは、端末２とＶｉａｃｃｅｓｓＮｅｔ（登録商標）プラットフォーム４との間のインターネットネットワーク上を通るデータの機密性および完全性を向上させることを可能にする。

ステップ９２では、中央サーバー１６は、リクエストされたコンテンツのＵＲＩを読み取り、そして取得リクエストの妥当性を検証する。
もし、このリクエストが有効でなければ、フローがユーザーに対して拒否される（ステップ９４）。
もし、取得リクエストが有効であれば、中央サーバー１６は、それをスクランブリングステーション２４とコンテンツサーバー３０とに送信する（ステップ９６）。

同様に、中央サーバー１６は、例えばサービスプレゼンテーションページのようなスクランブルすべきでないデータを問い合わせることを可能とするために、端末２とキャッシュサーバー１８との間のリンクを確立する（ステップ９８）。

取得リクエストに応答して、コンテンツサーバー３０は、リクエストされたデータをスクランブリングユニット２４に中央サーバー１６を介して配信する。後者は、コンテンツサーバー３０によって配信されたデータの各パケットに、ＵＲＩを含む“コンテンツロケーション”フィールドを加え、そしてこのパケットをスクランブリングユニット２４に送り返す（ステップ１００）。このスクランブルユニット２４では、付け加えられたＨＴＴＰヘッダでデータがスクランブルされる。

ステップ１０２では、中央サーバー１６は、ＨＴＴＰヘッダのロケーションヘッダフィールドを削除し、そしてＶｉａｃｃｅｓｓＮｅｔ（登録商標）プラットフォーム４と端末２との間の安全なチャンネルを介して、暗号化されたフローを端末２に配信する（ステップ１０４）。
ステップ１０６では、スクランブルされたデータは、ユーザー端末２によって受信され、端末２では、データがアンスクランブル(unscramble)される。

ポイント・トゥ・ポイントに特有の或る特性によれば、全く同一のプログラムへのアクセスのために、このプログラムのルート暗号化キーＫｅおよびアクセス条件を運ぶＥＣＭ−Ｕとして知られるカスタマイズされたＥＣＭは、条件付きアクセス（ＣＡ）基準の関数として、且つ暗号化されたコントロールワードＣＷの関数として生成される。

コントロールワードＣＷは、サーバープロバイダに特有のルートキーＫｅの多様性(diversification)により得られるキーＫｅ_ＵＡによって暗号化される。この多様性は、各ユーザーに特有のユニークアドレスＵＡの関数として実施される。

このようにして、リクエストされたプログラムは、カードがＥＣＭ−Ｕの対象とされたユーザーによって見られるだけであり、ＥＣＭ−Ｕに記述された条件付きアクセス（ＣＡ）基準に合致する少なくとも一つの権利を備える。

図５は、図式的にルートキーＫｅについての多様性手順を示す。後者は、各ユーザーの入力ユニークアドレスＵＡを受信する計算モジュール１０７における処理に従う。この計算の結果は、多様化されたキーＫｅ_ＵＡであり、このキーＫｅ_ＵＡはユーザーのユニークアドレスＵＡに依存する。そして、キーＫｅ_ＵＡは、コントロールワードＣＷを暗号化するために使用される。この機能は、キーＫｅ_ＵＡおよびＣＷ値を入力するモジュール１０８によって実施される。

これに先だって、ユーザーは、事実上、厳密に個人的である情報の潜在的な受信者、またはオペレータによってコントロールされるところの限られたグループの受信者として登録される。このコントロールは、ユニークアドレスＵＡによって各潜在的な受信者の同一性に関連する。

図６は、ユニークアドレスＵＡ１およびＵＡ２をそれぞれ有する二つの端末１１０および１１２がＨＴＴＰリクエストをプラットフォーム４に送信してプログラムを受信する例において、この原理を図式的に示す。計算機能１２０により、それぞれ端末ＵＡ１および端末ＵＡ２を対象としたＥＣＭ−Ｕ１およびＥＣＭ−Ｕ２を生成するために、ＥＣＭは、多様化されたキーＫｅ_ＵＡで暗号化されたコントロールキーＣＷによってカスタマイズされる。そして、ＥＣＭ−Ｕ１およびＥＣＭ−Ｕ２は、マルチプレクシングモジュール１３２により多重化され、そしてユーザーに送信される。

＜配信モード＞
図７に示されたこの実施のモードでは、配信は、グループアドレスによってパラメータ化された全端末に対して行われる。この場合、ユーザーは、ＨＴＴＰリクエストをグループアドレスと共に中央サーバー１６に送信する（矢印１３０）。後者は、このリクエストの送信者を認証し（矢印１３２−１３４）、そして、このリクエストされたコンテンツが実際に配信されるかどうかを検証する（矢印１３６）。もし、このリクエストされたコンテンツが配信されなければ、中央サーバー１６は、ストップメッセージをユーザー端末に送信する。
もし、コンテンツが配信されれば、認証されたユーザーは、その配信されたコンテンツを受信する。

要約すれば、この実施モードは、次のステップを備える。
・ユーザーがリクエストを作成する： 要求されるＵＲＩ及びＵＡ、グループＩＰアドレス、リターンパスのための端末のＩＰアドレスは中央サーバー１６により記録(note)される。
・マネージメントセンタ４４が、予め入力された全てのパラメータを転送した後にコンテンツアクセスセッションを拒否し又はその同意を与える。
・応答は配信について肯定的であってもよく、この場合、コンテンツサーバーは、リクエストされたデータをスクランブリングユニット２４に配信し（ステップ１３８）、スクランブリングユニット２４は、このデータをスクランブル後に送信する（ステップ１４０）。また、この応答は否定的であることができ、この場合、データ配信は拒否される。

注目すべきは、この実施モードにおいて、ユーザーが、コンテンツの配信を開始する権利を持つことができないことが可能であるということである。
・グループＩＰアドレスおよびＵＲＩは、中央サーバー１６によって生成されたコンテンツコマンドの初期の配信と共に送信される。
・リクエストされたフローは配信され、そして配信のためのＩＰソースアドレスはコンテンツサーバー３０のものである。
・応答は、最終的には、予めインストールされたデコーディングソフトウェアを用いて受信されたコンテンツをアンスクランブルする端末に送り返される（ステップ１４２）。

＜アプリケーション＞
本発明の処理は、ＨＴＴＰプロトコルによるコンテンツマーケティングと共にサービスアクセスコントロールシステムにおいて実施されてもよい。このコンテンツは、アクセス条件に支配されるＨＴＭＬページ上の画像(image)、又は重ねてテキスト部分を備えても良い。

このシステムは、ビデオ、オーディオ（音楽など）ファイルなどのダウンロードを売買するために、スクランブルされたコンテンツを配信するサービスの実施を可能としてもよい。

一例として、本発明は、次のＰＣアプリケーションの分野で実施されてもよい。
・“コンテンツオンデマンド(content on demand)”−オンライン株式売買または銀行取引、テレビジョン、ビデオまたはラジオクリップ(radio clip)のようなコンテンツオンデマンドの提供。
・カスタマイズされたメッセージ処理システム。
・ファイルダウンロード（ゲーム、仮想現実ソフトウェア、他のアプリケーションまたは個人生産性（教育など）ソフトウェア）。

また、本発明は、ユニキャストデータを配信するためにインターネットネットワークの使用を必要とするビジネス分野（撮影されたミーティング(filmed meeting)、ＶＰＮネットワーク上でのビデオ会議開催、極秘文書など）に適用されてもよい。

また、本発明は、ケーブルオペレータおよびデジタルＴＶサテライトオペレータの分野におけるアプリケーションも見つけることができる。ＩＰサービスオペレータは、以前の購入品に続いて問い合わせを受け得るスクランブルされたコンテンツの配信を実施してもよい。ＩＰネットワークによってダウンロードされるべきコンテンツに対するリード／ライト権のマネージメントに関連した高度のスクランブリングを必要とする企業内ネットワーク(intranet)の問い合わせは、本発明の追加的なアプリケーションを構成してもよい。

また、本発明は、ＴＶデコーダに設けられた受信機によって受信されたコンテンツに対するアクセスをコントロールするために実施されてもよい。
最後に、本発明は、モバイル電話またはサテライト電話アプリケーションにおいて実施されてもよい。対象とする伝送技術(transport technology)は、双方向ＧＳＭ(interactive GSM)、ＧＰＲＳまたはＵＭＴＳアプリケーションである。
スクランブルされたオーディオビジュアルプログラムを携帯電話またはＰＤＡ上で受信するために本発明を実施することも可能である。

本発明によるアクセスマネージメントプラットフォームの概略図である。 本発明の第１の選択的実施を示すシステム図である。 本発明による処理によって配信データをカプセル化するためのモードを図式的に示す図である。 本発明の上記第１の選択的実施を示す構成チャートである。 本発明によるアクセスコントロールメッセージを多様化するための手順を図式的に示す図である。 ポイント・トゥ・ポイントモードにおけるＥＣＭの多様性を図式的に示す図である。 本発明の第２の選択的実施を示すシステム図である。

符号の説明

２ ユーザー端末
４ ＶｉａｃｃｅｓｓＮｅｔ（登録商標）プラットフォーム
６ インターネットネットワーク
８ 第１出力ルーター
１０ 第２相互接続ルーター
１２ ファイアーウォールサーバー

Claims (14)

1. ＩＰデータ伝送ネットワーク（６）を介してサービスプロバイダに接続された複数のユーザー端末（２）にデジタルデータを配信するための処理方法であって、各配信先の端末（２）が、セキュリティプロセッサに入力されたユニークアドレス（ＵＡ）とＩＰアドレスとによりネットワークにおいて識別される方法において、前記データは、ＨＴＴＰプロトコルレベルで規定されたアクセス条件に関連づけられたことを特徴とする処理方法。
2. 前記データはポイント・トゥ・ポイントモードで配信され、該ポイント・トゥ・ポイントモードは、
   ユーザー端末（２）から、少なくとも、リクエストされた前記データがコンテンツサーバー３０にローカライズされることを可能とする（ＵＲＩ）パラメータと、ユニークアドレスと、前記端末（２）の前記ＩＰアドレスとを備えたＨＴＴＰリクエストを送信するステップと、
   前記ユニークアドレスにより前記ＨＴＴＰリクエストの送信者を認証するステップと、
   前記ＨＴＴＰリクエストを前記コンテンツサーバー（３０）とスクランブリングユニット（２４）とに送信するステップと、
   前記ＨＴＴＰリクエストに対する応答を受信すると、前記サービスプロバイダによって予め規定された少なくとも一つの条件付きアクセス基準を有するアクセスコントロールフィールド（７６）と前記（ＵＲＩ）パラメータ（７４）とを備えたＨＴＴＰヘッダを、各リクエストされたデータパケットに関連づけるステップと、
   前記リクエストされたデータをスクランブルするステップと、
   前記スクランブルされたデータを、前記条件付きアクセス基準と共に前記ユーザー端末（２）に送信するステップと
   に従うことを特徴とする請求項１記載の処理方法。
3. 前記条件付きアクセス基準および前記（ＵＲＩ）パラメータは、前記サービスプロバイダによって予め前記ユーザー端末（２）に送信されることを特徴とする請求項２記載の処理方法。
4. 各ユーザーについて、カスタマイズされたＥＣＭが、各ユーザー端末（２）の前記ユニークアドレスの関数としてルートキー（Ｋｅ）の多様性により得られたキー（Ｋｅ_ＵＡ）によって暗号化されたコントロールワード（ＣＷ）及び前記条件付きアクセス基準の関数として生成されることを特徴とする請求項３記載の処理方法。
5. 前記データは、
   グループアドレスと共に前記ＨＴＴＰリクエストを中央サーバー（１６）に送信するステップと、
   前記ＨＴＴＰリクエストの送信者を認証するステップと、
   前記リクエストされたコンテンツが配信されたことを検証するステップと、
   もし前記リクエストされたコンテンツが配信されなければ、ストップメッセージを前記ユーザー端末（２）に送信するステップと
   に従って、前記グループアドレスによって識別されるユーザー端末（２）のグループに配信モードで配信されることを特徴とする請求項１記載の処理方法。
6. 前記データ配信はユーザーによってコントロールされることを特徴とする請求項５記載の処理方法。
7. 前記スクランブルされたデータは、
   ＩＰヘッダ（７０）と、
   ＴＣＰ／ＵＤＰヘッダ（７２）と、
   ＨＴＴＰヘッダ（７４）と、
   前記条件付きアクセス基準を有するアクセスコントロールヘッダ（７６）と
   を更に備えたＩＰデータグラムにカプセル化されたことを特徴とする請求項１ないし６の何れか１項記載の処理方法。
8. 前記セキュリティプロセッサはチップカードであることを特徴とする請求項１記載の処理方法。
9. 各ユーザー端末（２）は、ローカルネットワークにグループ化された複数の端末と通信するゲートウェイ端末であることを特徴とする請求項８記載の処理方法。
10. ＩＰネットワーク（６）を介してサービスプロバイダに接続された複数のユーザー端末（２）に送信されたスクランブルデータに対するアクセスをコントロールするためのマネージメントプラットフォーム（４）であって、各ユーザー端末（２）がセキュリティプロセッサに入力されたユニークアドレスとＩＰアドレスとによって前記ネットワーク（６）において識別されるマネージメントプラットフォーム（４）において、ユーザー端末（２）から送信されたＨＴＴＰリクエストに応答してＨＴＴＰプロトコルレベルで配信用の前記データに条件付きアクセス基準を関連づけることが可能な少なくとも一つの中央サーバーを備えたことを特徴とするマネージメントプラットフォーム。
11. 配信用の前記データは、コンテンツサーバー（３０）から（ＵＲＩ）パラメータの関数として抽出され得ることを特徴とする請求項１０記載のマネージメントプラットフォーム。
12. 少なくとも一つのスクランブリングユニット（２４）と少なくとも一つのコンテンツサーバー（３０）とを更に備えたことを特徴とする請求項８ないし１１の何れか１項記載のマネージメントプラットフォーム。
13. 配信用の前記データは、オーディオビジュアルプログラムであることを特徴とする請求項８ないし１２の何れか１項記載のマネージメントプラットフォーム。
14. 配信用の前記データは、マルチメディアデータであることを特徴とする請求項８ないし１２の何れか１項記載のマネージメントプラットフォーム。
    

Images