JP2004516748A - Ｒｔｐヘッダにおける暗号化されたデータに対するポインタ - Google Patents

Abstract

本発明は、フレームフォーマット化されたユーザデータが実時間送信される一方で送信前にフレームベースの暗号化手順をユーザデータに対して行うことに関わる。特に、暗号化手順を受ける前に、局部化データは、データフレームと合わされ、後の暗号化から除外される所定の管理位置に配置される。

Description

【０００１】
本発明は、所定の管理位置に配置されるフレーム局部化データを合わすことでフレームフォーマット化されたユーザデータを実時間送信し、送信前に局部化データを除外する暗号化を行う方法及びシステムと、システムと、送信器と、受信器と、このような方法と使用するためにこのような送信器によって生成される信号とに関わる。
【０００２】
［発明の背景］
本発明は、請求項１の冒頭部分に記載するようなシステムに関わる。データ特に、制限的でないがマルチメディアデータは、オリジナルマターのクリエータ及びディストリビュータがこのような情報のユーザから適量の報酬を集めることができるよう、とりわけ様々な条件付アクセススキームを実行するために現在では暗号化されている。受信側では、ユーザデータは、規則正しい表示、視聴、傾聴、実行、及び、他のユーザ関連動作を可能にするために回復されなくてはならない。ある送信媒体、例えば、ネットワークを介する実際の送信は、パケット化されたレベルで行われ、このときパケットは該ネットワーク若しくは複数のネットワークに対して標準化される。
【０００３】
第１のアプローチ法は、比較的簡単な手順であり、送信プロパ（ｐｒｏｐｅｒ）を保護することが大丈夫な実時間プロトコル送信パケットに基づいて暗号化を行うことである。或いは、受信側で実施されたままとなるより高い保護レベルが達成され得、これは、ソースデータ或いはユーザデータのフレーム構造に基づいて暗号化を実行することで行われ得る。更に、上記２つのアプローチ法の組み合わせを実行することも可能である。ここで、暗号化は、フレームの始まりを見つけるために複雑な事前処理を行う必要がない標準的なコンポーネントで有利には実行されるべきである。従って、全ての上記手順は、フレームの始まりを確実に見つけるために簡単な機構を必要とする。
【０００４】
［発明の要約］
その結果、本発明は、中でも、異なるフレームの始まりを迅速且つ簡単に見つけるために、符号化機構、及び、可能性として、復号化機構を可能にするよう特定の局部化情報を追加することを目的とする。
【０００５】
従って、本発明の一つの面によると、本発明は請求項１の特徴部分によって特徴付けられる。
【０００６】
更に、発明者は、請求項１の僅かな変更が、請求項２に記載する通りユーザデータの一部だけを効果的に暗号化し、様々なこのような暗号化された部分の直接的な局部化をまだ可能にすることを認識する。本発明は、請求項１記載の方法を実行するよう配置されるシステムと、このようなシステムにおいて使用する送信器及び受信器と、このような送信器によって生成される信号とに関わる。本発明の更なる有利な面は、従属項に記載する。
【０００７】
［好ましい実施例の詳細な説明］
本発明の上記及びそれ以外の面及び利点は、好ましい実施例の開示を参照して、特に、添付の図面を参照して以下により詳細に説明する。
【０００８】
インターネット上のオーディオ又はビデオのようなコンテンツ情報の質は、符号化技法及び送信帯域幅における確実な進歩により改善されている。コンテンツプロバイダは、このような高値コンテンツを販売することを意図し、従って、条件付アクセス或いはディジタル権利管理を行う必要が生じている。このような条件付アクセスシステムは、コンテンツアイテムを暗号化し、その後認可されたエンドユーザだけが復号化し完全にオリジナルコンテンツを再構成することができるよう関連する復号化キーを管理する。
【０００９】
マルチメディアデータは一般的にフレームに構成され、フレームの大きさは情報のカテゴリーに関連する。更に、送信されたフレームの大きさは、圧縮度並びに暗号化される前に受けた他の処理に関連し得る。実際、フレームは、実際の送信に使用されるパケットよりも大きく或いは小さくてもよい。従って、単一の送信パケットは、一つ以上のフレーム、又は、フレームの端数部分を含んでもよい。「ストリーミング」は、コンテンツが到着するとすぐにクライアントがこのコンテンツを再生するか、さもなければ、使用するため、再生前にコンテンツ全体の全てを若しくは相当部分をダウンロードしない技法である。ストリーミングは、パケットの再送信を許可しない。コンテンツユーザは、データ損失の発生に対処しなくてはならない。
【００１０】
最適保護に関して、コンテンツは、不均一なフレームの大きさを有してもフレームレベルで暗号化されることが最適である。フレームレベルでのこのような暗号化は、送信されたコンテンツ並びに記憶されたコンテンツの両方に適用される持続性の或いはエンド・ツー・エンド暗号化を可能にする。実際の暗号化を実行するシステムコンポーネントが一般的なコンポーネントであり、従って、特定のストリーミングサーバと無関係であり、且つ、特定のフレームフォーマットと無関係であるべきことが好ましい。これを実現する一つの方法は、暗号化コンポーネントを実時間送信プロトコル、即ち、ＲＴＰトランスレータとして定義することである。現在、事実上全てのストリーミングサーバがＲＴＰストリーミングプロトコルを使用している。従って、暗号化コンポーネントは、ＲＴＰパケットを受信し、ペイロードを暗号化し、後に暗号化されたＲＴＰパケットを送ることができる。或いは、暗号化は、ストリーミングサーバと統合されてもよい。
【００１１】
或いは、暗号化は、ＲＴＰパケットのレベルで実行されてもよい。これは、送信プロパを保護し、受信後に受信器側で一部の保護をなくす。更に、これら２つの暗号化アプローチ法の組み合わせが、例えば、利用できるハードウェアファシリティに関して偶発的戦略に基づいて適当な暗号化レベルを割り当てることで可能である。
【００１２】
暗号化が例えば、フレームレベルで行われるとき、フレームのヘッダが暗号化されないまま維持される点で問題が生ずる。これは、フレームのヘッダの位置を確認するために一般的な暗号化コンポーネントがＲＴＰパケットのペイロードを解析することを必要とする。しかしこれは、暗号化コンポーネントの性能を低下させ、暗号化コンポーネントを実際のフレームフォーマットに依存させる。
【００１３】
本発明は、実際に暗号化される必要があるＲＴＰパケットペイロードの部分に対するポインタを含むようＲＴＰパケットのヘッダを延長することで該問題に対する解決策を提供する。ポインタは、ストリーミングササーバによって設定される。サーバは、これをヒント処理、即ち、マルチメディアデータのオフライン解析の一部として行ってもよく、従って、データはいずれ後の瞬間により効率的にストリーミングされ得る。ヒント処理の結果は、いわゆるヒントトラックにコンテンツと並列に記憶される。
【００１４】
図１は、本発明による方法を実行するよう配置されるシステムを示す図である。入力２３でユーザデータフレームを受信し、これらユーザデータフレームは、複数のこのようなフレームのストレージを収容するストレージ２２に一時的に記憶される。その後処理ブロック２４は、これらデータフレームに、複数のこのようなユーザフレームを有してもよいが必ずしも整数だけ有さないＲＴＰパケットのコンテキストにおけるフレームヘッダ局部化情報を合わせる。この処理の結果は、多数のＲＴＰペイロードを受け入れるブロック２６に一時的に記憶される。簡略化のため、上記した特定の「ヒント」トラックは別個に示されていない。実際、ヒントトラックファシリティは、標準的なファシリティとして当業者には認識されるであろう。実際、このようなヒントトラックは、異なるフレームの位置を示すことを可能にするためにブロックの入力側２３で実行されるであろう。送信前にユーザデータは、暗号化モジュール２８で暗号化され、インターネットのような通信ファシリティ３０上で送信される。図示するシステムの送信側での全手順は、全体的な同期化ファシリティ２０からの破線によって示されるように、このファシリティ２０によって同期化されてもよい。
【００１５】
受信側では、復号化ファシリティ３４を通じて復号化が行われ、その結果はブロック３６に一時的に記憶される。ユーザフレームの再構成は、処理ファシリティ３８で行われ、続いて、ブロック４０で一時的に記憶される。ユーザアプリケーションは、ブロック４２によって表わされる。記憶ブロック３６、４０は、完全なプログラム或いはその相当部分のダウンロードを受け入れないが、通信ファシリティ３０の転送速度変動に対する要求を満たすよう幾らかの同期化を提供する。ここでも、受信側での全体的な同期化が同期化ブロック３２を通じて行われる。
【００１６】
図２は、本発明において使用する例示的なデータフォーマットの実行を示す。簡略化のため、単一の実行だけを示す。ＲＴＰ構造の様々なデータブロック５０−６０が図示されている。これらの中でもブロック５４−６０がＲＴＰペイロードを構成し、このときブロック５６及び６０は夫々暗号化されたフレームペイロードを含み、ブロック５４及び５８は関連するフレームヘッダを含む。ブロック５６及び６０の長さが同じである必要はないことに注意する。ブロック５０は、ＲＴＰヘッダを有し、続くブロック５２はポインタを含む。図示するように、ポインタ６２は、各暗号化されたフレームペイロードの始まり及び終わりの両方を示す。ここで、ヘッダ５０は、ヒントトラックにおいて見つけられ、ポインタ５２は、ＲＴＰ５０の延長部である。このヒントトラックは、ＲＴＰパケットをパッケージングするためにストリーミングサーバによって使用される。
【００１７】
図３は、部分的に暗号化されたユーザデータを有する、図２に関して修正されたフォーマットを示す。簡略化のため、図２と異なる面だけが特に示されている。フレームペイロード内では、暗号化された（Ｅ）と暗号化されていないユーザデータとの間の区別が斜線によって示されている。局部化情報、この場合６２は、暗号化がフレームのユーザデータの始めから開始すると仮定して、夫々の暗号化された部分の終わり示す（６３，６５）。当然のことながら、他の部分的暗号化が使用されてもよい。暗号化自体は、フレーム或いは部分的フレームのレベル、パケットのレベル、又は、それらの組み合わせに基づいて行われてもよい。
【図面の簡単な説明】
【図１】
本発明による方法を実行するよう配置されるシステムを示す図である。
【図２】
本発明において使用するデータフォーマットの実行を示す図である。
【図３】
部分的に暗号化された図２に関して修正されたフォーマットを示す図である。

Claims (15)

1. 暗号化手順を送信若しくは再送信前に行うとして、フレームフォーマット化されたユーザデータを実時間送信又は再送信する方法であって、
   上記ユーザデータが上記暗号化手順を受けることに関連して、上記ユーザデータに適当なフレーム局部化データを合わし、ヘッダ情報と同様に後の上記暗号化手順から除外される所定の管理位置に上記フレーム局部化データを配置する段階を有することを特徴とする方法。
2. 上記ユーザデータの一部だけに上記暗号化手順を受けさせ、上記ユーザデータの暗号化された部分と暗号化されていない部分とを区別するために上記管理位置における暗号化局部化データを供給する、請求項１記載の方法。
3. 上記管理位置は、ヘッダ延長の情報位置である請求項１又は２記載の方法。
4. 暗号化後の上記ユーザデータはＲＴＰパケットで送信され、上記ユーザデータは上記ＲＴＰパケットのレベルで暗号化される請求項１又は２記載の方法。
5. 上記ユーザデータはフレームレベルで暗号化される請求項１又は２記載の方法。
6. 上記送信は、部分的フレームをパケットにし、複数のフレームを単一のパケットにすることを可能にする請求項４又は５記載の方法。
7. 上記ヘッダ延長情報位置は、複数のフレーム局部化データを有する請求項３記載の方法。
8. 上記管理位置は別個のヒントトラック内に配置される請求項１又は２記載の方法。
9. 請求項１記載の方法を実施するよう配置され、フレームフォーマット化されたユーザデータを実時間送信或いは再送信する送信手段と、上記送信或いは再送信前に上記ユーザデータに対して暗号化手順を行う暗号化手段とを有するシステムであって、
   上記暗号化手段の次に、上記ユーザデータにフレーム局部化データを合わし、ヘッダ情報と同様に後の上記暗号化から除外される所定の管理位置に上記フレーム局部化データを配置する手段を有することを特徴とするシステム。
10. 送信媒体としてインターネットとインターフェースするよう配置される請求項９記載のシステム。
11. 請求項９記載のシステムにおいてステーションとして使用するよう配置される送信器。
12. 請求項１１記載のステーションによって生成される信号。
13. 請求項９記載のシステムにおいてステーションとして使用するよう配置され、受信すると上記暗号化手順を受けたユーザデータを復号化する復号化手段を有し、上記ユーザデータを含むフレームに基づいて上記復号化されたユーザデータを出力する、受信器。
14. 上記復号化手段は、フレームレベルで使用できる請求項１３記載の受信器。
15. 上記復号化手段は、パケットレベルで使用できる請求項１３記載の受信器。

Images