JP2004356949A - 情報配信装置及び情報受信装置 - Google Patents

Abstract

【課題】従来は、コンテンツ情報全てを復号するため計算コストがかかる。また、試聴や試視のために、許可されたユーザー向けに著作権保護されたコンテンツ情報とは別のコンテンツ情報を作り、情報配信装置から配信する必要がある。
【解決手段】ＲＴＰヘッダの内容を、変換テーブルに基づき、ＲＴＰヘッダ変換部１０４で書き換える。このヘッダを含むペイロードデータであるＲＴＰデータと擬似ＲＴＰデータと、変換テーブルを暗号化部１０８で暗号化してコントロールデータ作成部１１０でコントロールデータの一部として作成されたコントロールデータとは、ＩＰパケットとしてネットワーク上へ配信される。コンテンツ全体を暗号化するよりも少ない計算量で動画・音声データを配信できる。このＩＰパケットを受信する受信装置は、暗号化された変換テーブルの復号手段を有しない既存の受信装置では情報の一部分だけしか再生できないが、視聴は可能である。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は情報配信装置及び情報受信装置に係り、特に動画や音声などのコンテンツの情報をインターネット等のネットワークを介して著作権保護を考慮して配信し、受信する情報配信装置及び情報受信装置に関する。
【０００２】
【従来の技術】
ネットワークの常時接続環境の普及や、ネットワーク速度の向上などの環境変化により、近年、動画や音声などのマルチメディアコンテンツをインターネット等のネットワーク上で送受信するサービスが増加している。動画や音声などのマルチメディアコンテンツは著作権などの権利が存在しているものが多く、許可された利用者だけがネットワーク上で再生する機能や、データのコピーや再配布の禁止の機能がないと、コンテンツ権利保持者がネットワーク上でのコンテンツ配信に消極的になり、たとえネットワークの環境が整備されてきても、ネットワーク上での配信が普及しない事態になる。従って、ネットワーク上での権利保護機能は、動画や音声などのマルチメディアコンテンツの送受信には不可欠の技術である。
【０００３】
ネットワーク上でのマルチメディアコンテンツの送受信には、利用者が再生の要求をしてからの待ち時間や、ライブコンテンツの送受信を考えると、利用者側の受信装置に一旦データを蓄積するのではなく、送受信しながらデータを再生する、ストリーミング型の送受信が優れている。ストリーミング型であれば、マルチキャスト技術を用いて、トラフィックを増加させないで、同時に多くの利用者に送信することも可能である。
【０００４】
また、到着時刻や到着保証性が無いインターネット上でマルチメディアコンテンツを扱う場合、プロトコルとしてインターネットの研究開発機関であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）が発行するＲＦＣ１８８９で規定されたＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）とＲＴＣＰ（ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を用いる。これらのプロトコルＲＴＰ及びＲＴＣＰを用いることにより、同期再生や輻輳制御、パケット廃棄に対する処理が行える。
【０００５】
上記のＲＴＰを用いてコンテンツの著作権を保護する情報配信装置及び受信装置が従来より知られている（例えば、特許文献１参照）。この特許文献１記載の従来の情報配信装置及び受信装置では、インターネットに情報配信装置であるＭＰＥＧ４（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ｐｈａｓｅ ４）配信サーバと受信装置が接続されており、インターネットを通してＭＰＥＧ４配信サーバと受信装置との間でＭＰＥＧ４のＡＶストリームの秘匿通信を行うものである。
【０００６】
そして、ＭＰＥＧ４配信サーバと受信装置との間で認証処理を行い、符号化されたコンテンツ情報を暗号化し、暗号化の有無を示す属性情報と暗号方式を示す属性情報の少なくとも一方の属性情報を含む暗号拡張ヘッダを作成し、コンテンツ情報の転送に必要なトランスポートプロトコル処理を行うと共に、基本トランスポートヘッダを作成し、基本トランスポートヘッダと暗号拡張ヘッダと暗号化されたコンテンツ情報とを含むパケットを送出する。また、ＲＴＰ拡張ヘッダ若しくはＭＰＥＧ４拡張ヘッダ、ＭＰＥＧ４のペイロードデータのいずれかに暗号の復号のために必要な属性情報を入れ、ＲＴＰデータとして送信する。
【０００７】
【特許文献１】
特開２０００−２８７１９２号公報
【０００８】
【発明が解決しようとする課題】
しかしながら、上記の従来の情報配信装置及び受信装置では、コンテンツの権利を守るためにコンテンツ情報を暗号化するのは効果的ではあるが、コンテンツ情報全てを復号するのに計算コストがかかるという問題がある。また、ＲＴＰの拡張ヘッダを使用し、ＭＰＥＧ４ペイロードを使用して、暗号化情報を記述するためには、特殊なＲＴＰヘッダのパーサーが必要になり、そのために専用の受信装置が不可欠になる。
【０００９】
また、実際の配信を考えた場合、必ずしも、許可されている利用者のみに再生できれば十分とはいえない場合も考えられる。例えば、コンテンツを配信し、利用してもらうためには試聴や試視が重要であり、そのために再生品質を悪くしたり、一部分のコンテンツ情報のみ、許可されていない利用者にもコンテンツを再生できる機能が必要になる。従来はこの機能を実現する場合、許可されたユーザー向けに著作権保護されたコンテンツ情報とは別のコンテンツ情報を作り、情報配信装置から配信する必要がある。特に、ライブの場合は２種類のコンテンツ情報を作成する必要がある。また、許可されていない利用者は通常は専用受信装置を持っていないので、汎用的な受信装置でコンテンツ情報の再生が可能でなければならない。
【００１０】
本発明は、以上の点に鑑みなされたもので、計算コストをかけずに、著作権保護を可能とする情報配信装置及び受信装置を提供することを目的とする。
【００１１】
また、本発明の他の目的は、利用を許可されておらず、専用の受信装置を持たない利用者に一部のコンテンツ情報の再生を可能とする情報配信装置及び受信装置を提供することにある。
【００１２】
【課題を解決するための手段】
上記の目的を達成するため、第１の発明の情報配信装置は、画像データ及び音声データの一方又は両方からなる配信すべき情報を所定のプロトコルでネットワーク上に配信する情報配信装置であって、配信すべき情報を符号化してペイロードデータを得る符号化手段と、ペイロードデータから所定のプロトコルのヘッダを生成するヘッダ生成手段と、ヘッダの内容を変換するための変換テーブルを所定のアルゴリズムに基づいて生成する変換テーブル生成手段と、変換テーブルに基づいてヘッダの内容を変換する変換手段と、与えられた暗号鍵に基づいて変換テーブルを暗号化する暗号化手段と、暗号化手段により暗号化された変換テーブルを、所定のプロトコルに規定の所定データの一部として作成するデータ作成手段と、変換手段により内容が変換されたヘッダ、ペイロードデータ及び所定データを所定のプロトコルのパケットとして、ネットワークへ送出する送出手段とを有する構成としたものである。
【００１３】
この発明では、所定のプロトコルのヘッダの内容を変換テーブルにより変換するようにしたため、変換後のヘッダに基づきコンテンツの一部分だけを一般的な汎用プレーヤで視聴可能になるペイロードデータを生成、配信できる。また、この発明では、変換テーブルを暗号鍵にて暗号化して配信するようにしたため、配信すべき情報全体を暗号化するよりはるかに少ない計算量で暗号化したデータの配信ができる。更に、この発明では、ペイロードデータでなくヘッダを暗号化した変換テーブルで変換しているので、配信すべき情報の符号化方式によらず共通の方法で暗号化ができる。
【００１４】
また、上記の目的を達成するため、第２の発明の情報配信装置は、画像データ及び音声データの一方又は両方からなる配信すべき情報を所定のプロトコルでネットワーク上に配信する情報配信装置であって、配信すべき情報を符号化してペイロードデータを得る符号化手段と、ペイロードデータから所定のプロトコルのヘッダを生成するヘッダ生成手段と、ヘッダが付加されたペイロードデータを記憶する第１の記憶手段と、ペイロードデータから補助データを記憶する第２の記憶手段と、第１及び第２の記憶手段から読み出したヘッダが付加されたペイロードデータ及び補助データとから、ヘッダの内容を変換するための変換テーブルを所定のアルゴリズムに基づいて生成する変換テーブル生成手段と、変換テーブルに基づいてヘッダの内容を変換する変換手段と、与えられた暗号鍵に基づいて変換テーブルを暗号化する暗号化手段と、暗号化手段により暗号化された変換テーブルを、所定のプロトコルに規定の所定データの一部として作成するデータ作成手段と、変換手段により内容が変換されたヘッダ、ペイロードデータ及び所定データを所定のプロトコルのパケットとして、ネットワークへ送出する送出手段とを有する構成としたものである。
【００１５】
この発明では、ヘッダが付加されたペイロードデータを記憶すると共に、変換テーブルを生成するために使用する補助データを記憶するようにしたため、ライブでデータ配信するだけでなく、予め作成していた配信すべき情報を受信者のリクエストに応じて配信することができる。
【００１６】
また、上記の目的を達成するため、第３の発明の情報受信装置は、第１又は第２の発明の情報配信装置により所定のプロトコルでネットワーク上に配信されたパケットを受信する情報受信装置であって、パケットを受信する受信手段と、受信手段により受信されたパケットから所定データを読み込み、所定データから暗号化された変換テーブルを取り出し、暗号化された変換テーブルを与えられた暗号鍵に基づいて復号する変換テーブル復号手段と、受信手段により受信されたパケットからヘッダが付加されたペイロードデータを読み込む読み込み手段と、変換テーブル復号手段により復号された変換テーブルに基づき、読み込み手段により読み込まれたヘッダ及びペイロードデータのうち、ヘッダを元に変換するヘッダ変換手段と、変換テーブル復号手段により復号された変換テーブルを保持すると共に、ヘッダ変換手段で使用した変換テーブルを適宜削除する管理手段と、ヘッダ変換手段により変換されたヘッダが付加されたペイロードデータから配信すべき情報を復号する情報復号手段とを有する構成としたものである。
【００１７】
この発明では、変換テーブルに基づいてヘッダ部分が変換された所定のプロトコルのペイロードデータと暗号化された変換テーブルを読み込み、暗号化された変換テーブルを復号し、その復号した変換テーブルを用いて上記のヘッダ部分を変換するようにしたため、上記の変換テーブルによるヘッダ変換手段を有しない許可されていない利用者が使用する汎用の受信装置では一部のペイロードデータしか再生することができないが、ヘッダ変換手段を有する許可されている利用者が使用する専用の受信装置では、配信された情報をすべて再生することができる。
【００１８】
また、この発明では、暗号化を復号する手段は、所定のプロトコルのヘッダを含むペイロードデータ全体でなく、ヘッダ部分だけを復号するだけで済む。更に、この発明では、符号化されていないヘッダ部分だけを暗号化の復号を行うだけでよく、データの圧縮符号化方式に依存しない。
【００１９】
更に、上記の目的を達成するため、第４の発明の情報受信装置は、第１又は第２の発明の情報配信装置により所定のプロトコルでネットワーク上に配信されたパケットを受信する情報受信装置であって、パケットを受信する受信手段と、受信手段により受信されたパケットから所定データを読み込む第１の読み込み手段と、第１の読み込み手段により得られた所定データから暗号化された変換テーブルを取り出し、暗号化された変換テーブルを与えられた暗号鍵に基づいて復号する変換テーブル復号手段と、受信手段により受信されたパケットからヘッダが付加されたペイロードデータを読み込む第２の読み込み手段と、変換テーブル復号手段により復号された変換テーブルに基づき、読み込み手段により読み込まれたヘッダ及びペイロードデータのうち、ヘッダを元に変換するヘッダ変換手段と、変換テーブル復号手段により復号された変換テーブルを保持すると共に、ヘッダ変換手段で使用した変換テーブルを適宜削除する管理手段と、ヘッダ変換手段により変換されたヘッダが付加されたペイロードデータと、第１の読み込み手段により得られた所定データのうち、暗号化された変換テーブル以外のデータとから所定のプロトコルのパケットを再構築して送出するパケット送出手段とを有する構成としたものである。
【００２０】
この発明では、受信したパケット中のヘッダ部分を、復号した変換テーブルを用いて元に戻し、そのヘッダを含む所定のプロトコルのペイロードデータと、暗号化された変換テーブル以外のコントロールデータとから所定のプロトコルのパケットを再構築して送出するようにしたため、送出されたパケットを既存の所定のプロトコル用の受信装置で受信できる。
【００２１】
【発明の実施の形態】
次に、本発明の各実施の形態について図面と共に説明する。図１は本発明になる情報配信装置の第１の実施の形態のブロック図を示す。同図において、入力された画像データ及び音声データ（画像・音声データ）は、圧縮データ生成部１０１において圧縮符号化されて通信用のデータに変換される。この通信用データは、例えば画像データの場合はＭＰＥＧ４動画圧縮フォーマットの場合もあるし、音声データの場合はＧ．７２６の場合もある。本実施の形態ではこの通信用のデータは特定のフォーマットに限定されることは無い。
【００２２】
生成された通信用データはペイロードデータ生成部１０２に供給され、ここで１パケット単位に切り出され、ペイロードデータにされる。このペイロードデータは圧縮フォーマットに適した形式になる。ＭＰＥＧ４動画圧縮フォーマットなどの一部のフォーマットについては、ＲＦＣで規定があるので、それを使うべきであるが、本実施の形態では特にペイロードのフォーマットを規定するものではない。
【００２３】
ペイロードデータはＲＴＰヘッダ付与部１０３に供給されて、ＲＴＰデータにするためにＲＴＰヘッダが付加される。ＲＴＰヘッダはＲＦＣ１８８９で規定されたヘッダである。このＲＴＰヘッダではパケットの圧縮方式などの種類をあらわすパケットタイプ、フレームの境界を示すＭビット、ストリームの識別であるＳＳＲＣ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ＳｏｕＲＣｅ）、シーケンス番号、タイムスタンプ等が記述される。
【００２４】
ＲＴＰヘッダ変換部１０４は、ＲＴＰヘッダ付与部１０３から入力されたＲＴＰデータのＲＴＰヘッダのうち、シーケンス番号とタイムスタンプを、変換テーブルに基づき書き換える機能を持つ。この変換テーブルは、ペイロードデータ生成部１０２で生成されたペイロードデータと、ＲＴＰヘッダ付与部１０３で付加されるＲＴＰヘッダとにより、変換テーブル生成部１０７で後述する方法で生成されたものである。
【００２５】
ＲＴＰヘッダ変換部１０４でシーケンス番号とタイムスタンプを書き換えられたＲＴＰデータは、データ整列部１０５に供給されてシーケンス番号順に並べられる。データ整列部１０５はバッファを持ち、ＲＴＰデータを整列し直す。整列されたＲＴＰデータはＩＰデータ処理部１０６に供給される。
【００２６】
一方、変換テーブル生成部１０７で生成された変換テーブルは、ＲＴＰヘッダ変換部１０４及びＩＰデータ処理部１０６に供給されると共に、変換テーブル暗号化部１０８に供給され、ここで暗号鍵により暗号化された後、コントロールデータ作成部１１０に供給されてコントロールデータの形式に変換されて、ＩＰデータ処理部１０６に供給される。上記の暗号鍵は受信装置と安全な方法で交換される。交換の方法はネットワークを介してもよく、別の方法で鍵を交換してもよい。暗号鍵は暗号鍵処理部１０９により交換用鍵データから取り出される。変換テーブルの暗号化は画像・音声データの圧縮処理方式に依存しないので、動画・音声データを生成する際に、圧縮符号化に依存した暗号処理が不要になる。
【００２７】
ＩＰデータ処理部１０６は、上記のＲＴＰデータ、コントロールデータ及び変換テーブルを適切なＩＰパケットとして送出する機能を持つ。ＲＴＰデータは変換テーブルによって、その送出ポート番号が変わる場合があるので、ＩＰデータ処理部１０６には変換テーブル生成部１０７により生成された変換テーブルが入力される。ＩＰデータ処理部１０６から出力されるＲＴＰデータのうち、ＲＴＰデータのフォーマットに準拠しているが、正規のＲＴＰデータと比較してシーケンス番号、タイムスタンプが書き換えられ、送出ポートが変更されたＲＴＰデータも送出されるが、このＲＴＰデータを以後擬似ＲＴＰデータと呼ぶ。
【００２８】
変換テーブルは、ＲＴＰコントロールプロトコル（ＲＴＣＰ）を使用してＲＴＣＰデータとして送信される。ＲＴＰデータ及び擬似ＲＴＰデータは、時系列的に合成されて同じポートから送受信されるが、ＲＴＣＰデータはこれらとは別のポートから非同期で送受信される。上記の３種類のデータがＩＰパケットを構成している。
【００２９】
このようにして、本実施の形態によれば、実時間で画像・音声データを圧縮、パケッタイズ、送信することができるが、ＲＴＰヘッダのシーケンス番号とタイムスタンプを、変換テーブルに基づき書き換えるようにしているため、コンテンツの画像・音声データの一部分だけを一般的な汎用プレーヤで視聴可能な動画・音声データを生成・配信することができる。また、本実施の形態では、変換テーブルは暗号鍵にて暗号化して送信するため、動画・音声データはコンテンツの再生を許可された利用者が使う専用の受信装置ではコンテンツ全体を再生することができ、しかも、ＲＴＰヘッダの内容のみを変換することにより、コンテンツ全体を暗号化するよりもはるかに少ない計算量で動画・音声データを生成することができる。
【００３０】
次に、本発明の情報配信装置の第２の実施の形態について説明する。図２は本発明になる情報配信装置の第２の実施の形態のブロック図を示す。同図中、図１と同一構成部分には同一符号を付し、その説明を適宜省略する。本実施の形態は、途中段階のデータをＲＴＰデータ記憶装置１１１及びペイロード補助データ記憶装置１１２に記憶するようにしたものである。
【００３１】
図２において、ペイロードデータ生成部１０２で１パケット単位に切り出されて生成されたペイロードデータは、ＲＴＰヘッダ付与部１０３にて、ＲＴＰデータにするためにＲＴＰヘッダが付加された後、ＲＴＰデータ記憶装置１１１に蓄積される。また、ＲＴＰデータには、構成される画像データがＩフレームなのかＰフレームなのか等の情報が含まれないので、ペイロードデータ生成部１０２で生成されたペイロードデータから変換テーブルを生成するのに必要な補助情報をペイロード補助データ記憶装置１１２に蓄積する。この時点で情報配信装置においてコンテンツはＲＴＰデータ記憶装置１１１とペイロード補助データ記憶装置１１２に蓄積されている。
【００３２】
情報配信装置では受信装置の要求に応じて、配信するコンテンツをＲＴＰデータ記憶装置１１１ならびにペイロード補助データ記憶装置１１２から読み込む。変換テーブル生成部１１３は、ＲＴＰデータ記憶装置１１１からのＲＴＰデータとペイロード補助データ記憶装置１１２からの補助データとに基づいて、変換テーブルを生成する。ＲＴＰデータ記憶装置１１１からのＲＴＰデータと変換テーブルはＲＴＰヘッダ変換部１０４に供給されてＲＴＰヘッダのシーケンス番号とタイムスタンプが書き換えられた後、データ整列部１０５にてシーケンス番号順に並べられる。
【００３３】
上記の変換テーブル生成部１１３で生成された変換テーブルは、変換テーブル暗号化部１０８で暗号鍵処理部１０９からの暗号鍵により暗号化され、コントロールデータ作成部１１０でコントロールデータの形式になり、ＩＰデータ処理部１１４により送信される。ＩＰデータ処理部１１４はＲＴＰデータ、コントロールデータを適切なＩＰパケットとして送出する機能を持つ。
【００３４】
このように、本実施の形態によれば、エンコード、ペイロードデータ化、ＲＴＰヘッダ付与の部分を予め行い、データを蓄積することにより、受信装置からの要求時に少ない負荷で許可された受信者のみに受信できるデータを配信することができる。また、本実施の形態では、ＲＴＰデータ及び変換テーブルを生成するのに必要な補助データを記憶する記憶装置１１２を設けているため、第１の実施の形態の特長に加えて、ライブでデータ配信するだけでなく、予め作成していたコンテンツを受信者のリクエストに応じて配信することができる。
【００３５】
次に、本発明の情報受信装置について説明する。図３は本発明になる情報受信装置の第１の実施の形態のブロック図を示す。同図において、ＲＴＰデータ、擬似ＲＴＰデータ、ＲＴＣＰデータは、情報配信装置からネットワークを介してＩＰデータ処理部２０１により受信される。通常のＲＴＰデータでは受信のポート番号やＩＰアドレスは一定であるが、本発明の擬似ＲＴＰデータは本来のＲＴＰデータと異なるポート番号を使って通信されることがある。
【００３６】
これは変換テーブルにより明らかになるので、変換テーブルデータはＩＰデータ処理部２０１に送られ、本来のＲＴＰポート、ＲＴＣＰポート以外にも、適切なポートからの入力データを受信する。ＩＰデータ処理部２０１によって読み込まれたＲＴＣＰデータから変換テーブルデータがコントロールデータ読込部２０６で分離される。この変換テーブルデータは暗号化されているので、情報配信装置と関連付けられた暗号鍵により、変換テーブル復号部２０７で変換テーブルが復号される。変換テーブル復号部２０７に供給される暗号鍵は、暗号鍵処理部２０８にて交換用鍵データから得られる。
【００３７】
一方、ＩＰデータ処理プ２０１からＲＴＰデータ読込部２０２によって読み込まれたＲＴＰデータは、ＲＴＰヘッダ変換部２０３において、ＲＴＰデータのヘッダ部分が変換テーブル復号部２０７で復号された変換テーブルに基づき変換される。なお、変換テーブルは各ＲＴＰデータ毎に存在するので、変換に使用した変換テーブルデータは変換テーブル管理部２０９により保持された後、適宜消去される。
【００３８】
ＲＴＰは通常ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）で送られるので、パケットロスにより受信装置に到着しない場合がある。その場合、変換テーブルのデータが使用されずにいつまでも消去されないので、変換テーブルデータは使用されなくても到着からある一定時刻経過したら変換テーブル管理部２０９により消去される。ＲＴＰヘッダ変換部２０３でＲＴＰヘッダが変換されたＲＴＰデータは、時系列に並んでいないので、ＲＴＰデータ整列部２０４において、データが並べ替えられた後、圧縮データ復号部２０５に供給され、ここデータイムスタンプに基づいてデコード、再生される。
【００３９】
このように、本実施の形態の情報受信装置では、変換テーブルに基づいてヘッダ部分が変換されたＲＴＰデータと、暗号化された変換テーブルを読み込み、変換テーブルは復号してＲＴＰデータのヘッダ部分の変換に用いるようにしたため、コンテンツ全体の画像・音声データを正常に再生することができる。また、変換テーブルだけが暗号化されているため、コンテンツの画像・音声データ全体を暗号化されているものにくらべて、はるかに少ない計算量と計算コストで画像・音声データを再生することができる。
【００４０】
図４は許可されていない利用者の使用する情報受信装置の一例のブロック図を示す。この情報受信装置はＲＴＰ，ＲＴＣＰに準拠した一般的なプレーヤであり、例えばＱｕｉｃｋ Ｔｉｍｅプレーヤがこれに相当する。同図において、ネットワークを介して受信されたデータは、ＩＰデータ処理部３０１でＲＴＰデータとＲＴＣＰデータに分離され、ＲＴＰデータはＲＴＰデータ読込部３０２にて読み込まれ、ＲＴＰデータ整列部３０４で時系列に並べられた後、圧縮データ復号部３０５に供給されてデコードされる。
【００４１】
一方、ＲＴＣＰデータはコントロールデータ読込部３０６により読み込まれてコントロールデータとして出力される。このコントロールデータはＲＦＣで規定してある、複数のストリーム間の同期やパケットロスの状況のレポート以外には使われない。このため、この一般的な情報受信装置では、変換テーブルに基づいてＲＴＰヘッダ部分が変換できないので、コンテンツの一部のみしか視聴することができない。
【００４２】
図３と図４の各情報受信装置を比較して明らかなように、図３の本発明の情報受信装置では図４の一般的な情報受信装置に対して、変換テーブル復号部２０７とＲＴＰヘッダ変換部２０３、暗号鍵処理部２０８及び変換テーブル管理部２０９が付加されたものであり、処理量の増加部分はわずかである。
【００４３】
次に、本発明の情報受信装置の第２の実施の形態について説明する。図５は本発明になる情報受信装置の第２の実施の形態のブロック図を示す。同図中、図３及び図４と同一構成部分には同一符号を付し、その説明を適宜省略する。図５に示す第２の実施の形態の情報受信装置は、受信変換部２００と既存受信装置部３００とから構成される。既存受信装置部３００は図４に示した、許可されていない利用者の使用する受信装置例と同一構成であり、例えばＱｕｉｃｋ Ｔｉｍｅプレーヤがこれに相当する。
【００４４】
受信変換部２００は図３に示した第１の実施の形態の情報受信装置の構成と略同様の構成であり、ネットワークを介して配信されたＲＴＰデータ、擬似ＲＴＰデータ、ＲＴＣＰデータをＩＰデータ処理部２０１により受信され、また、本来のＲＴＰポート、ＲＴＣＰポート以外にも、適切なポートからの入力データが受信される。
【００４５】
ＩＰデータ処理部２０１によって受信されたデータ中のＲＴＣＰデータがコントールデータ読込部２１０により読み込まれ、その中から変換テーブルデータとその他のコントロールデータが、コントロールデータ読込部２１０で分離され、その他のコントロールデータがＩＰデータ送信処理部２１１に送られ、変換テーブルデータが変換テーブル復号部２０７に送られる。この変換テーブルデータは暗号化されているので、情報配信装置と関連付けられた暗号鍵により、変換テーブル復号部２０７で復号されて元の変換テーブルに復元される。なお、暗号鍵は暗号鍵処理部２０８にて交換用鍵データから得られる。
【００４６】
ＲＴＰヘッダ変換部２０３において、ＲＴＰデータ読込部２０２で読み込まれたＲＴＰデータのヘッダ部分が上記の変換テーブルに基づき変換されて元に戻される。なお、変換テーブルはＲＴＰデータ毎に存在するので、変換に使用した変換テーブルデータは変換テーブル管理部２０９により消去される。ＲＴＰヘッダ整列部２０４で整列されたＲＴＰデータおよび、コントロールデータ読込部２１０からの変換テーブル以外のコントロールデータとは、ＩＰデータ送信処理部２１１により、再びＲＴＰデータ及びＲＴＣＰデータからなるＩＰパケットに再構築される。
【００４７】
これらのＲＴＰデータ及びＲＴＣＰデータからなるＩＰパケットは、既存のプロトコルの構成であるので、既存受信装置部３００で受信可能である。受信変換部２００と既存受信装置部３００は、ローカルなネットワークで通信しており、外部にデータを流さない。この方法ではＱｕｉｃｋ Ｔｉｍｅプレーヤなどの既存受信装置部３００を使用して、許可された利用者にコンテンツを見せることが可能である。
【００４８】
次に、ＲＴＰヘッダの書き換えの目的について述べる。一般的にＲＴＰデータはパケットロスがあっても、再生は部分的に欠けることはあるが、再生不能になることはないように構成されている。これは到達確実性の無いインターネット上でリアルタイム情報を送る場合に考慮されるべきものである。本発明では通常偶発的に起こるパケットロスと同じ状態を恣意的に画質や音質を低下させるために起こすことに特徴がある。そのためには、パケットヘッダの書き換えによる擬似ＲＴＰデータ化の方法をとる。擬似ＲＴＰデータは通常のＲＴＰデータに対して、シーケンス番号、タイムスタンプを変え、さらに必要ならポート番号、ＩＰアドレスを変えて送信するものである。
【００４９】
例えば、ＭＰＥＧ４動画圧縮においてフレーム内符号化されたＩフレームデータのうち半数のデータを擬似ＲＴＰデータにし、さらにＩフレーム以外のフレーム間予測符号化されたＰフレームデータ、Ｂフレームデータをすべて擬似ＲＴＰデータにすると、Ｉフレームの画像の一部のみ見ることができる。また、音声パケットの一部のデータのみ擬似ＲＴＰデータにすると、再生される音声にノイズを入れることができる。
【００５０】
変換テーブルは、擬似ＲＴＰデータを生成するためのものである。擬似ＲＴＰデータは本来のＲＴＰデータに対して、シーケンス番号、タイムスタンプ及び必要ならポート番号や送信元のＩＰアドレスを変えることで実現する。この時、シーケンス番号とタイムスタンプは矛盾があってはならない。つまり、シーケンス番号が大きいほうがタイムスタンプも大きくなっている必要がある。
【００５１】
ここで重要なことは、受信側ではＲＴＰデータの受信は矛盾が生じないということである。つまり、一部のパケットが擬似ＲＴＰデータになっており、シーケンス番号が連続していなくても、ネットワーク上でパケットロスにより、シーケンス番号が連続していないものとの区別がつかない。また、パケット順を入れ替えてある場合は、ＲＴＰデータそのものは正常に見えるが、実際のペイロードデータが入れ替わっている。これらのデータを通常の受信装置で再生すると、画像が欠け、音声が途切れるが、再生が停止してしまうことは無い。
【００５２】
送信者は許可されている利用者に向けて、暗号化された変換テーブルを送り、情報受信装置で復号した変換テーブルを用いて、ＲＴＰヘッダの付け替えを行うことにより、すべて正しいＲＴＰヘッダにすることができる。
【００５３】
図６は変換テーブルの一例を示す。変換前の元シーケンス番号と変換前の元タイムスタンプ、変換後のシーケンス番号、タイムスタンプさらにポート番号が変更される場合はポート番号をテーブルとして持つ。元シーケンス番号はパケットごとに連番が振られる。
【００５４】
次に、変換テーブルの作成方法について説明する。ただし、許可されていない受信者に対してどの程度データを見せるかによって、変換テーブルの作成方法は異なるため、必ずしもここにあげる方法をとる必要はない。
【００５５】
第１の変換テーブルの作成方法は、音声データのようにパケットデータの時間間隔が一定であり、かつ、各々のパケットデータが独立である場合の作成方法であり、図７にそのアルゴリズムを示す。この場合は、シーケンス番号とタイムスタンプを矛盾が生じないようにパケットの順を入れ替えることで実現できる。入れ替える位置は固定間隔ではなく、乱数によりある程度振らす。ただし、最大振れ量を規定しておき、情報配信装置、情報受信装置のバッファ量で実現できるようにする。
【００５６】
図１に示した変換テーブル生成部１０７は、図７において、まず、最大振れ量Ｒに設定値を代入すると共に、ＲＴＰヘッダに含まれているシーケンス番号ｓに初期値０を代入する（ステップＳ１）。続いて、シーケンス番号ｓと最大振れ量Ｒとの差が、負であるか、あるいは変換後のシーケンス番号Ｔ（０）〜Ｔ（ｓ−１）に含まれているかどうか判定する（ステップＳ２）。
【００５７】
シーケンス番号ｓと最大振れ量Ｒとの差が、負であるか、変換後のシーケンス番号Ｔ（０）〜Ｔ（ｓ−１）に含まれていれば、（ｓ−Ｒ）から（ｓ＋Ｒ）のシーケンス番号のうち、変換後のシーケンス番号Ｔ（０）〜Ｔ（ｓ−１）に使用されていない任意の０以上のシーケンス番号を変換後のシーケンス番号Ｔ（ｓ）に設定し（ステップＳ３）、シーケンス番号ｓが最大シーケンス番号か判定する（ステップＳ４）。一方、上記の差が０以上かＴ（０）〜Ｔ（ｓ−１）に含まれていなければ、その差の値を変換後のシーケンス番号Ｔ（ｓ）に設定し（ステップＳ５）、シーケンス番号ｓが最大シーケンス番号か判定する（ステップＳ４）。
【００５８】
ステップＳ４でシーケンス番号ｓが最大シーケンス番号でないと判定された時には、シーケンス番号ｓを１つインクリメントし（ステップＳ６）、再びステップＳ２とＳ３又はＳ５の処理を行う。以下、シーケンス番号ｓが最大シーケンス番号となるまで上記の処理を繰り返し、最大シーケンス番号ｓとなると処理を終了する（ステップＳ７）。
【００５９】
このアルゴリズムによって生成された変換テーブル例を図６に示す。図６に示す変換テーブルは、図７に示した変換テーブル生成アルゴリズムにおいて、最大振れ量Ｒを「３」としたときのもので、まず、ステップＳ１でシーケンス番号ｓ＝０とされ、ステップＳ２でｓ−Ｒが−３であり、負と判定されるので、ステップＳ３に進み、ｓ−Ｒ（＝０−３＝−３）からｓ＋Ｒ（＝０＋３＝３）までのうち、０以上の任意の値として例えば「２」を選択する。これにより、元シーケンス番号０は２に変換される。
【００６０】
続いて、ｓの値が１に更新され（ステップＳ４、Ｓ６）、ステップＳ２でｓ−Ｒが−２であり、負と判定されるので、ステップＳ３に進み、ｓ−Ｒ（＝１−３＝−２）からｓ＋Ｒ（＝１＋３＝４）までの０以上の数のうち、Ｔ（０）に入れられている２以外の任意の値として例えば「４」を選択する。これにより、元シーケンス番号１は４に変換される。続いて、ｓの値が２に更新され（ステップＳ４、Ｓ６）、ステップＳ２でｓ−Ｒが−１であり、負と判定されるので、ステップＳ３に進み、ｓ−Ｒ（＝２−３＝−１）からｓ＋Ｒ（＝２＋３＝５）までの０以上の数のうち、Ｔ（０）、Ｔ（１）に入れられている２と４以外の任意の値として例えば「０」を選択する。これにより、元シーケンス番号２は０に変換される。
【００６１】
続いて、ｓの値が３に更新され（ステップＳ４、Ｓ６）、ステップＳ２でｓ−Ｒが０であり、この値はＴ（０）、Ｔ（１）、Ｔ（２）に既に含まれているので、ステップＳ３に進み、ｓ−Ｒ（＝３−３＝０）からｓ＋Ｒ（＝３＋３＝６）までの０以上の数のうち、２、４、０以外の任意の値として例えば「１」を選択する。これにより、元シーケンス番号３は１に変換される。以下、同様にして図７のアルゴリズムにより図６の変換テーブルが生成される。
【００６２】
ところで、動画データの場合、パケットデータを入れ替える方法は何通りかある。ペイロードデータから判断し、ＭＰＥＧ４動画圧縮における１ＧＯＶ単位で入れ替えると０．５〜数秒単位で画像の順が変わり、内容は分かるが鑑賞に堪えられない動画になる。別の例ではＰフレーム（ピクチャ）、Ｂフレーム（ピクチャ）単位で画像を入れ替えれば、参照フレームとの対応が正しくないので、正常に再生できない画像になる。
【００６３】
異なるポート番号を用いて擬似ＲＴＰデータを作成した場合、許可されていない受信者には本来のポート番号以外のパケットは受信することができず、見かけ上パケットロスを生じているように見える。受信装置側から見れば、これは単に伝送中のパケットが落ちたことと同じに見えるので、汎用の受信装置で再生が停止することはない。
【００６４】
図８は変換テーブルの第２の作成アルゴリズムを示す。Ｉフレーム（ピクチャ）のみ正規のポート番号で送り、Ｐフレーム（ピクチャ）、Ｂフレーム（ピクチャ）は別のポートで送るようにする例である。同図において、まず、ＲＴＰヘッダに含まれるシーケンス番号ｓに初期値０を代入した後（ステップＳ１１）、ペイロードデータに基づきＲＴＰデータを構成するフレームがＩフレームかどうか判定する（ステップＳ１２）。
【００６５】
Ｉフレームでない場合は、元のポート番号ｐに定数を加算した値を変換後のポート番号Ｔ（ｓ）とし（ステップＳ１３）、シーケンス番号ｓが最大シーケンス番号かどうか判定する（ステップＳ１４）。Ｉフレームであるときには、元のポート番号ｐを変換後のポート番号Ｔ（ｓ）とし（ステップＳ１５）、シーケンス番号ｓが最大シーケンス番号かどうか判定する（ステップＳ１４）。
【００６６】
シーケンス番号ｓが最大シーケンス番号でないときには、現在のシーケンス番号に１を加算して新たなシーケンス番号ｓとし（ステップＳ１６）、以下、上記と同様の動作を繰り返す。このようにしてすべてのシーケンス番号ｓについて処理が行われると変換テーブル生成処理を終了する（ステップＳ１７）。このアルゴリズムにより、図９に示す変換テーブルが作成される。この変換テーブルは、ｐ＝６１００、定数＝４００の例である。
【００６７】
この変換テーブルを使用した場合は、許可されていない利用者には、正規のポート番号６１００に入力されたＩフレームのみの画像が表示されるので、内容はわかるが低品質の動画像となる。この例のように、許可されていない利用者に、全くコンテンツを見せなかったり、内容がわからない程度見せたり、内容は理解できるが品質を悪く見せたりという制御が変換テーブルの生成方法を変更することで可能になる。
【００６８】
変換テーブルはＲＴＰコントロールプロトコル（ＲＴＣＰ）を使用して送る。最初に情報配信装置と情報受信装置とで安全に暗号鍵を交換する。この暗号鍵の交換にはＲＴＰ、ＲＴＣＰを使う必要は無く、既知の方法が使える。ＲＴＣＰには送信側からのレポート（ＳＲ）、受信側からのレポート（ＲＲ）が規定されているが、そのほかにアプリケ−ションで任意のデータを送ることができる部分が規定されている（ＡＰＰ）。これを用いて交換した暗号鍵を使って暗号化した変換テーブルを送る。
【００６９】
全てのパケットに対して変換テーブルデータを持つが、変換テーブルを送る際には、図１０に示すように適切なパケット数に区切ってデータを送る。ＲＴＣＰは通常ＵＤＰで送られるので到着が保障されていない。そのために送信側の情報配信装置からテーブルデータを送り、受信装置側で受け取ったら、送信側にＡＣＫを送信する。
【００７０】
また、図１１に示すように送信側の情報配信装置は変換テーブルデータ（ＲＴＣＰデータ）を送信後、一定時間Ｔ１たってもＡＣＫが返ってこなかった場合、変換テーブルの送信に失敗したと判断して、変換テーブルデータ（ＲＴＣＰデータ）を再送する。変換された擬似ＲＴＰデータを送るときには既にそのパケットに対する変換テーブルが受信装置に到着していないと、受信装置側でＲＴＰデータを正しいシーケンス番号やタイムスタンプに変換することができず、結果として正常に再生できなくなる。これを防ぐためにはＡＣＫが返ってくるまでは当該ＲＴＰデータを送出しない。ＲＴＣＰデータの再送が繰り返され、結果として、当該ＲＴＰデータを送出しなければ、再生時刻に間に合わなくなる場合は、以下の３方法のいずれかをとる。
【００７１】
１つ目の方法は図１２に示すように、ＲＴＰデータを遅らせる方法である。図１２では２回目のＲＴＣＰデータの再送後、ＲＴＰデータ８を送信してから応答パケットＡＣＫを受信するまで、次のＲＴＰデータ９の送信を停止している。ライブではこの方法はとれない。また、この方法をとった場合、受信装置ではコンテンツの再生が一旦停止する。
【００７２】
２つ目の方法は図１３に示すように、変換テーブルデータを送れなかったＲＴＰデータの送出を行わない方法である。図１３ではＲＴＰデータ９〜１２の変換テーブルデータの２回目の再送後に、応答パケットＡＣＫを受信するまで情報配信装置はＲＴＰデータ９〜１２を送信しない例を示す。この方法では、ライブでも使用できるが、送信しなかったＲＴＰデータ９〜１２の再生データが全て欠落する。
【００７３】
３つ目の方法は、図１４に示すように、ＲＴＣＰによる変換テーブルを送れなかったＲＴＰデータは情報配信装置でＲＴＰヘッダを変換することなく、データを送出する方法である。図１４ではＲＴＰデータ９〜１２の変換テーブルデータの２回目の再送後に、情報配信装置はＲＴＰデータ９〜１２をそれらのヘッダを変換することなく送信する例を示す。この方法では、受信装置側でＲＴＰデータ９〜１２のヘッダの変換ができないが、もともと正しいデータが到着しているので、正常に再生ができる。ただし、その間、データはスクランブルされていない状態なので、この状態が長く続くとセキュリティ上問題を生じる場合がある。
【００７４】
マルチキャストの場合も原理は同じであるが、変換テーブルは一通りしかないので、各受信装置側に同じ内容の変換テーブルを送る。ただし、各受信装置側とは異なる暗号鍵を交換するので、ＲＴＣＰによって実際に送られる変換テーブルデータは受信装置毎に別々にユニキャストで送る。
【００７５】
なお、上記の実施の形態では、画像データと音声データの両方を伝送するシスムに適用したが、本発明は画像データと音声データの一方を伝送するシステムにも適用可能である。
【００７６】
【発明の効果】
以上説明したように、本発明の情報配信装置によれば、所定のプロトコルのヘッダの内容を変換テーブルにより変換し、変換後のヘッダを含むペイロードデータと、変換テーブルを含むコントロールデータとからなる所定のプロトコルのパケットを配信するようにしたため、変換テーブルに基づきヘッダの内容を元に戻す手段を有しない既存の汎用プレーヤでは、配信すべき情報の一部のみ視聴可能であるが、コンテンツの再生を許可された利用者が使う変換テーブルに基づきヘッダの内容を復元する手段を有する専用装置では配信すべき情報全体を再生できるパケットを配信できる。
【００７７】
また、本発明によれば、変換テーブルを暗号鍵にて暗号化して配信するようにしたため、配信すべき情報全体を暗号化するよりはるかに少ない計算量と計算コストで著作権保護のために暗号化したデータの配信ができ、また、ペイロードデータでなくヘッダを暗号化した変換テーブルで変換しているので、ペイロードデータの符号化方式によらず共通の方法で暗号化ができるため、ペイロードデータを生成する際に、圧縮符号化に依存した暗号処理が不要になる。
【００７８】
また、本発明の情報配信装置によれば、ヘッダが付加されたペイロードデータを記憶すると共に、変換テーブルを生成するために使用する補助データを記憶するようにしたため、ライブでデータ配信するだけでなく、予め作成していた配信すべき情報を受信者のリクエストに応じて配信することができる。
【００７９】
また、本発明の情報受信装置によれば、変換テーブルに基づいてヘッダ部分が変換された所定のプロトコルのペイロードデータと暗号化された変換テーブルを読み込み、暗号化された変換テーブルを復号し、その復号した変換テーブルを用いて上記のヘッダ部分を変換するようにしたため、上記の変換テーブルによるヘッダ変換手段を有しない許可されていない利用者が使用する汎用の受信装置では一部のペイロードデータしか再生することができないパケットを受信して、配信された情報をすべて再生することができる。
【００８０】
また、本発明の情報受信装置によれば、暗号化を復号する手段は、所定のプロトコルのヘッダを含むペイロードデータ全体でなく、ヘッダ部分だけを復号するだけで済むため、所定のプロトコルのヘッダを含むペイロードデータ全体が暗号化されたデータを復号する場合に比べて、はるかに少ない計算量で復号でき、配信された情報を正常に受信再生できる。
【００８１】
また、本発明の情報受信装置によれば、符号化されていないヘッダ部分だけを暗号化の復号を行うだけでよく、データの圧縮符号化方式に依存しないため、配信されたデータを再生する際に、圧縮符号化に依存した暗号復号処理を不要にできる。
【００８２】
更に、本発明の情報受信装置によれば、受信したパケット中のヘッダ部分を、復号した変換テーブルを用いて元に戻し、そのヘッダを含む所定のプロトコルのペイロードデータと、暗号化された変換テーブル以外のコントロールデータとから所定のプロトコルのパケットを再構築して送出することにより、送出されたパケットを既存の所定のプロトコル用の受信装置で受信できるようにしたため、許可された利用者であれば再生に既存の所定のプロトコル用の受信装置を使用しても、配信された情報をすべて再生することができる。
【図面の簡単な説明】
【図１】本発明の情報配信装置の第１の実施の形態を示す構成図である。
【図２】本発明の情報配信装置の第２の実施の形態を示す構成図である。
【図３】本発明の情報受信装置の第１の実施の形態を示す構成図である。
【図４】許可されない利用者の利用する一般的な受信装置の一例の構成図である。
【図５】本発明の情報受信装置の第２の実施の形態を示す構成図である。
【図６】本発明の要部の変換テーブルの一例を示す図である。
【図７】図６の変換テーブルの生成アルゴリズムの一例を示すフローチャートである。
【図８】本発明の要部の変換テーブルの生成アルゴリズムの他の例を示すフローチャートである。
【図９】図８の生成アルゴリズムにより生成された変換テーブルの一例を示す図である。
【図１０】本発明の要部の変換テーブルの送信方法の第１の例を示す図である。
【図１１】本発明の要部の変換テーブルの送信方法の第２の例を示す図である。
【図１２】本発明の要部の変換テーブルの送信方法の第３の例を示す図である。
【図１３】本発明の要部の変換テーブルの送信方法の第４の例を示す図である。
【図１４】本発明の要部の変換テーブルの送信方法の第５の例を示す図である。
【符号の説明】
１０１ 圧縮データ生成部
１０２ ペイロードデータ生成部
１０３ ＲＴＰヘッダ付与部
１０４ ＲＴＰヘッダ変換部
１０５ データ整列部
１０６、１１４、２０１、３０１ ＩＰデータ処理部
１０７、１１３ 変換テーブル生成部
１０８ 変換テーブル暗号化部
１０９、２０８ 暗号鍵処理部
１１０ コントロールデータ作成部
１１１ ＲＴＰデータ記憶装置
１１２ ペイロード補助データ記憶装置
２００ 受信変換部
２０２、３０２ ＲＴＰデータ読込部
２０３ ＲＴＰヘッダ変換部
２０４、３０４ ＲＴＰデータ整列部
２０５、３０５ 圧縮データ復号部
２０６、２１０、３０６ コントロールデータ読込部
２０７ 変換テーブル復号部
２０９ 変換テーブル管理部
２１１ ＩＰデータ送信処理部
３００ 既存受信装置部

Claims (4)

1. 画像データ及び音声データの一方又は両方からなる配信すべき情報を所定のプロトコルでネットワーク上に配信する情報配信装置であって、
   前記配信すべき情報を符号化してペイロードデータを得る符号化手段と、
   前記ペイロードデータから前記所定のプロトコルのヘッダを生成するヘッダ生成手段と、
   前記ヘッダの内容を変換するための変換テーブルを所定のアルゴリズムに基づいて生成する変換テーブル生成手段と、
   前記変換テーブルに基づいて前記ヘッダの内容を変換する変換手段と、
   与えられた暗号鍵に基づいて前記変換テーブルを暗号化する暗号化手段と、
   前記暗号化手段により暗号化された前記変換テーブルを、前記所定のプロトコルに規定の所定データの一部として作成するデータ作成手段と、
   前記変換手段により内容が変換された前記ヘッダ、前記ペイロードデータ及び前記所定データを前記所定のプロトコルのパケットとして、前記ネットワークへ送出する送出手段と
   を有することを特徴とする情報配信装置。
2. 画像データ及び音声データの一方又は両方からなる配信すべき情報を所定のプロトコルでネットワーク上に配信する情報配信装置であって、
   前記配信すべき情報を符号化してペイロードデータを得る符号化手段と、
   前記ペイロードデータから前記所定のプロトコルのヘッダを生成するヘッダ生成手段と、
   前記ヘッダが付加された前記ペイロードデータを記憶する第１の記憶手段と、
   前記ペイロードデータから補助データを記憶する第２の記憶手段と、
   前記第１及び第２の記憶手段から読み出した前記ヘッダが付加されたペイロードデータ及び前記補助データとから、前記ヘッダの内容を変換するための変換テーブルを所定のアルゴリズムに基づいて生成する変換テーブル生成手段と、
   前記変換テーブルに基づいて前記ヘッダの内容を変換する変換手段と、
   与えられた暗号鍵に基づいて前記変換テーブルを暗号化する暗号化手段と、
   前記暗号化手段により暗号化された前記変換テーブルを、前記所定のプロトコルに規定の所定データの一部として作成するデータ作成手段と、
   前記変換手段により内容が変換された前記ヘッダ、前記ペイロードデータ及び前記所定データを前記所定のプロトコルのパケットとして、前記ネットワークへ送出する送出手段と
   を有することを特徴とする情報配信装置。
3. 請求項１又は２記載の情報配信装置により所定のプロトコルでネットワーク上に配信された前記パケットを受信する情報受信装置であって、
   前記パケットを受信する受信手段と、
   前記受信手段により受信された前記パケットから前記所定データを読み込み、該所定データから前記暗号化された変換テーブルを取り出し、該暗号化された変換テーブルを与えられた暗号鍵に基づいて復号する変換テーブル復号手段と、
   前記受信手段により受信された前記パケットから前記ヘッダが付加された前記ペイロードデータを読み込む読み込み手段と、
   前記変換テーブル復号手段により復号された前記変換テーブルに基づき、前記読み込み手段により読み込まれた前記ヘッダ及びペイロードデータのうち、前記ヘッダを元に変換するヘッダ変換手段と、
   前記変換テーブル復号手段により復号された前記変換テーブルを保持すると共に、前記ヘッダ変換手段で使用した前記変換テーブルを適宜削除する管理手段と、
   前記ヘッダ変換手段により変換された前記ヘッダが付加された前記ペイロードデータから配信すべき情報を復号する情報復号手段と
   を有することを特徴とする情報受信装置。
4. 請求項１又は２記載の情報配信装置により所定のプロトコルでネットワーク上に配信された前記パケットを受信する情報受信装置であって、
   前記パケットを受信する受信手段と、
   前記受信手段により受信された前記パケットから前記所定データを読み込む第１の読み込み手段と、
   前記第１の読み込み手段により得られた前記所定データから前記暗号化された変換テーブルを取り出し、該暗号化された変換テーブルを与えられた暗号鍵に基づいて復号する変換テーブル復号手段と、
   前記受信手段により受信された前記パケットから前記ヘッダが付加された前記ペイロードデータを読み込む第２の読み込み手段と、
   前記変換テーブル復号手段により復号された前記変換テーブルに基づき、前記読み込み手段により読み込まれた前記ヘッダ及びペイロードデータのうち、前記ヘッダを元に変換するヘッダ変換手段と、
   前記変換テーブル復号手段により復号された前記変換テーブルを保持すると共に、前記ヘッダ変換手段で使用した前記変換テーブルを適宜削除する管理手段と、
   前記ヘッダ変換手段により変換された前記ヘッダが付加された前記ペイロードデータと、前記第１の読み込み手段により得られた前記所定データのうち、前記暗号化された変換テーブル以外のデータとから前記所定のプロトコルのパケットを再構築して送出するパケット送出手段と
   を有することを特徴とする情報受信装置。

Images