(57)【要約】【課題】配信されるコンテンツが配信者の意図しない受信装置で受信された場合でも受信者が視聴できないようにするとともに、ＲＴＰによるＩＰ伝送において鍵の切り替えタイミングを適正に制御する。【解決手段】送信装置１０において、コンテンツを構成するＴＳパケットを暗号化するための鍵KEYdesを定期的に更新しながらＴＳパケットを暗号化する。暗号化されたＴＳパケットはＲＴＰパケットに変換され、受信装置４０へ出力される。現在の周期で使用する鍵KEYdes-1と次の周期で使用する鍵KEYdes-2とは対応シーケンス番号ｓ１，ｓ２とともに、鍵切り替えタイミング情報（ＳＲＥパケット）として受信装置４０に送信される。受信装置４０は、受信したＲＴＰパケットから暗号化されたＴＳパケットを抽出し、鍵切り替えタイミング情報に基づいて復号化鍵で復号化する。受信したＲＴＰパケットのシーケンス番号が対応シーケンス番号に達するタイミングで復号化鍵が更新される。【選択図】図３
2017220886.tif 000002
【特許請求の範囲】
【請求項１】
送信装置からリアルタイムトランスポートプロトコル（ＲＴＰ）を利用してＩＰパケットにより通信ネットワーク経由で１以上の受信装置へコンテンツを配信するコンテンツ配信方法であって、
前記送信装置が、前記コンテンツを構成するＭＰＥＧ２−ＴＳのＴＳパケットを暗号化するための暗号化鍵KEYdesを定期的に更新するステップと、
前記送信装置が、前記ＴＳパケットを前記暗号化鍵KEYdesで暗号化するステップと、
前記送信装置が、前記暗号化されたＴＳパケットをＲＴＰパケットに変換するステップと、
前記送信装置が、前記暗号化鍵KEYdesとして、現在の周期で使用する鍵KEYdes-1と、次の周期で使用する鍵KEYdes-2とをそれぞれに対応するＲＴＰパケットの対応シーケンス番号ｓ１，ｓ２とともに前記受信装置に送信するステップと、
前記受信装置が、前記ＲＴＰパケットを受信するステップと、
前記受信装置が、前記鍵KEYdes-1およびKEYdes-2とともに前記対応シーケンス番号ｓ１，ｓ２を受信するステップと、
前記受信装置が、前記ＲＴＰパケットから前記暗号化されたＴＳパケットを抽出するステップと、
前記受信装置が、前記暗号化されたＴＳパケットを復号化鍵で復号化するステップと、
前記受信装置が、前記受信したＲＴＰパケットのシーケンス番号が前記対応シーケンス番号に達するタイミングで前記復号化鍵を前記対応シーケンス番号に対応する鍵に切り替えるステップと
を備えたコンテンツ配信方法。
【請求項２】
リアルタイムトランスポートプロトコル（ＲＴＰ)を使用したＩＰパケットにより通信ネットワーク経由でコンテンツを伝送する送信装置であって、
コンテンツを構成するＭＰＥＧ２−ＴＳのＴＳパケットを第１の鍵（KEYdes）で暗号化する第１の暗号化部と、
前記第１の暗号化部により暗号化されたＴＳパケットをＲＴＰパケットに変換するＴＳ／ＩＰ変換部と、
前記第１の鍵を定期的に更新して生成する鍵生成部と、
前記第１の暗号化部に対して所定の切り替えタイミングで、前記第１の暗号化部に与える前記第１の鍵の更新値を切り替えるともに、前記ＴＳ／ＩＰ変換部から取得したＲＴＰシーケンス番号を参照して当該切り替えタイミングに対応するＲＴＰシーケンス番号を決定する制御部と、
前記第１の鍵の各更新値および対応するＲＴＰシーケンス番号を鍵切り替えタイミング情報として生成するタイミング情報生成部と、
前記ＲＴＰパケットおよび前記鍵切り替えタイミング情報を前記通信ネットワーク上に出力する出力部と、
を備えた送信装置。
【請求項３】
前記タイミング情報生成部は、前記第１の鍵の各更新値と当該更新値に対応するＲＴＰシーケンス番号とを含む前記鍵切り替えタイミング情報を前記ＲＴＰパケットとは異なるパケットとして生成する請求項２に記載の送信装置。
【請求項４】
前記ＲＴＰパケットのＵＤＰポートと、前記鍵切り替えタイミング情報のＵＤＰポートとを異ならせた請求項２または３に記載の送信装置。
【請求項５】
前記第１の鍵は、前記ＲＴＰシーケンス番号の単位で更新される請求項２〜４のいずれかに記載の送信装置。
【請求項６】
前記所定のパケットに変換される前に前記第１の鍵を第２の鍵（KEYp）により暗号化する第２の暗号化部をさらに備え、前記送信部は、暗号化された第１の鍵を送信する請求項２〜５のいずれかに記載の送信装置。
【請求項７】
前記第２の鍵（KEYp）を、第３の鍵（KEYrx）で暗号化する第３の暗号化部を更に備え、
前記第３の鍵は複数の受信装置毎に異なる請求項６に記載の送信装置。
【請求項８】
前記第３の鍵（KEYrx）は、各受信装置毎の、公開鍵暗号方式による公開鍵で暗号化されて、通知される請求項７に記載の送信装置。
【請求項９】
送信装置からリアルタイムトランスポートプロトコル（ＲＴＰ）を利用してＩＰパケットにより通信ネットワーク経由で配信されるコンテンツを受信する受信装置であって、
暗号化されたＴＳパケットを含むＲＴＰパケットとともに、前記ＴＳパケットを暗号化した鍵KEYdes-1，KEYdes-2およびそれぞれに対応する対応シーケンス番号ｓ１，ｓ２を含む鍵切り替えタイミング情報を受信する入力部と、
前記ＲＴＰパケットから前記暗号化されたＴＳパケットを抽出するＩＰ／ＴＳ変換部と、
前記暗号化されたＴＳパケットを復号化鍵で復号化するＴＳ復号化部と、
前記ＩＰ入力部で受信したＲＴＰパケットのシーケンス番号が前記対応シーケンス番号に達するタイミングで前記復号化鍵を前記対応シーケンス番号に対応する鍵に切り替える鍵制御部と
を備えた受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リアルタイムトランスポートプロトコル（ＲＴＰ）を利用してＩＰパケットにより通信ネットワーク経由で１以上の受信装置へコンテンツを配信するコンテンツ配信方法、ならびにこの方法に使用する送信装置および受信装置に関する。
【背景技術】
【０００２】
音声や動画像をインターネット等の通信ネットワーク上で伝送するためのプロトコルとして、リアルタイムトランスポートプロトコル（RTP: Real-time Transport Protocol)が知られている。ＲＴＰは、シンプルな構成で制御が簡単なＵＤＰ（User Datagram Protocol）上で用いられる。再送制御のある信頼性の高いＴＣＰ(Transmission Control Protocol)に比べて、ＵＤＰはリアルタイムで忠実な再生を行うのに適している。ＲＴＰは、そのヘッダにシーケンス番号やタイムスタンプ等を格納して送信することにより、ＵＤＰにおけるパケットの順序を正すことができない等の問題を克服している。したがって、ＲＴＰは、リアルタイムに音声や動画をリストリーム配信するような用途に適している。
【０００３】
このようなリアルタイムトランスポートプロトコル（ＲＴＰ）を使用したＩＰパケットによるＭＰＥＧ２−ＴＳ(Transport Stream)を伝送するシステム（TS over IPシステム）において、既存機器ではＴＳパケットのデスクランブルはＢ−ＣＡＳ（Conditional Access Systems）を使用したＭＵＬＴＩ２によるスクランブルに依存している。
【０００４】
特許文献１には、放送信号の全てまたは一部に、放送事業者の送信器が行った暗号処理とは異なる暗号処理を行う放送再送信装置が提案されている。これにより、放送事業者の暗号処理と中継事業者の暗号処理とが干渉することを防止している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−９６２７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述のＢ−ＣＡＳシステムに関して、権利的、経済的等の制約によりＢ−ＣＡＳシステムを導入できない事業者（例えば小規模なＣＡＴＶ放送局等）では、ＩＰ伝送によるデジタル放送システムを構築した場合、スクランブルされていないデータが送受信されることになる。そのようなシステムでマルチキャストまたはブロードキャストによりＩＰパケットを配信した場合、契約外の受信装置（ＩＰ／ＴＳ変換装置、パーソナルコンピュータ（ＰＣ）等）にＩＰパケットが到達して不正に視聴される恐れがある。
【０００７】
また、従来のＢ−ＣＡＳを使用したＭＵＬＴＩ２によるＴＳのスクランブルに用いられるスクランブル鍵は放送波のＴＳパケット内に包含して伝送されるが、そのようなスクランブル鍵とは異なる別途の暗号鍵で動画像等の暗号化をＩＰ伝送で行おうとした場合、従来の仕組みをそのまま適用できないという問題が生じる。すなわち、従来のＢ−ＣＡＳを使用したＭＵＬＴＩ２によるスクランブル鍵は到着順が保証された放送波のＴＳパケットに格納されて伝送されるので、ＴＳとの関係が明確であるのに対して、ＴＳパケットの到達順序や到達自体が保証されないＲＴＰによるＩＰ伝送においてＲＴＰパケットに含まれるＴＳパケットを暗号化するための鍵を、当該ＲＴＰパケットとは別のパケットで送信すると、鍵の切り替えタイミングを適正に制御することが困難となるという問題が生じる。
【０００８】
上記特許文献１に記載の装置では、ＴＳデータを伝送するＵＤＰパケット内に暗号鍵情報を含め、暗号鍵の更新についても言及されており、この問題が解決されることが期待される。しかし、ＵＤＰパケットの到着順序が入れ替わった場合の検出および対処、そのようなＴＳデータに対する暗号鍵の更新の同期をどのように制御するかについて、具体的な対応が記載されておらず、改善の余地がある。
【０００９】
したがって、本発明はこのような背景においてなされたものであり、その目的は、配信されるコンテンツが配信者の意図しない受信装置で受信された場合でも受信者が視聴できないようにすることにある。また、ＲＴＰによるＩＰ伝送においても鍵の切り替えタイミングを適正に制御することができるようにすることにある。
【課題を解決するための手段】
【００１０】
本発明によるコンテンツ配信方法は、送信装置からリアルタイムトランスポートプロトコル（ＲＴＰ）を利用してＩＰパケットにより通信ネットワーク経由で１以上の受信装置へコンテンツを配信するコンテンツ配信方法であって、前記送信装置が、前記コンテンツを構成するＭＰＥＧ２−ＴＳのＴＳパケットを暗号化するための暗号化鍵KEYdesを定期的に更新するステップと、前記送信装置が、前記ＴＳパケットを前記暗号化鍵KEYdesで暗号化するステップと、前記送信装置が、前記暗号化されたＴＳパケットをＲＴＰパケットに変換するステップと、前記送信装置が、前記暗号化鍵KEYdesとして、現在の周期で使用する鍵KEYdes-1と、次の周期で使用する鍵KEYdes-2とをそれぞれに対応するＲＴＰパケットの対応シーケンス番号ｓ１，ｓ２とともに前記受信装置に送信するステップと、前記受信装置が、前記ＲＴＰパケットを受信するステップと、前記受信装置が、前記鍵KEYdes-1およびKEYdes-2とともに前記対応シーケンス番号ｓ１，ｓ２を受信するステップと、前記受信装置が、前記ＲＴＰパケットから前記暗号化されたＴＳパケットを抽出するステップと、前記受信装置が、前記暗号化されたＴＳパケットを復号化鍵で復号化するステップと、前記受信装置が、前記受信したＲＴＰパケットのシーケンス番号が前記対応シーケンス番号に達するタイミングで前記復号化鍵を前記対応シーケンス番号に対応する鍵に切り替えるステップとを備えたものである。
【００１１】
ＴＳデータの伝送にＲＴＰを利用することにより、ＵＤＰの利点を活かしつつ、ＵＤＰパケットの到着順序が入れ替わった場合の検出および対処が可能となる。また、更新される暗号化鍵KEYdesとして、現在の周期で使用する鍵KEYdes-1と、次の周期で使用する鍵KEYdes-2とをそれぞれに対応するＲＴＰパケットの対応シーケンス番号ｓ１，ｓ２とともに受信装置に送信し、受信側で、受信したＲＴＰパケットのシーケンス番号が対応シーケンス番号に達するタイミングで復号化鍵を対応シーケンス番号に対応する鍵に切り替える鍵の更新を行うことにより、受信装置において鍵の切り替えタイミングでシームレスにＴＳパケットの復号化が行える。また、ＲＴＰパケットのシーケンス番号を利用することにより、ＴＳデータに対する暗号鍵の更新の同期を適正に制御することができる。
【００１２】
本発明による送信装置は、リアルタイムトランスポートプロトコル（ＲＴＰ)を使用したＩＰパケットにより通信ネットワーク経由でコンテンツを伝送する送信装置であって、コンテンツを構成するＭＰＥＧ２−ＴＳのＴＳパケットを第１の鍵（KEYdes）で暗号化する第１の暗号化部と、前記第１の暗号化部により暗号化されたＴＳパケットをＲＴＰパケットに変換するＴＳ／ＩＰ変換部と、前記第１の鍵を定期的に更新して生成する鍵生成部と、前記第１の暗号化部に対して所定の切り替えタイミングで、前記第１の暗号化部に与える前記第１の鍵の更新値を切り替えるともに、前記ＴＳ／ＩＰ変換部から取得したＲＴＰシーケンス番号を参照して当該切り替えタイミングに対応するＲＴＰシーケンス番号を決定する制御部と、前記第１の鍵の各更新値および対応するＲＴＰシーケンス番号を鍵切り替えタイミング情報として生成するタイミング情報生成部と、前記ＲＴＰパケットおよび前記鍵切り替えタイミング情報を前記通信ネットワーク上に出力する出力部とを備えたものである。
【００１３】
前記送信装置の実施形態において、前記タイミング情報生成部は、前記第１の鍵の各更新値と当該更新値に対応するＲＴＰシーケンス番号とを含む前記鍵切り替えタイミング情報を前記ＲＴＰパケットとは異なるパケットとして生成することができる。これにより、ＲＴＰパケットに含まれるＴＳデータのみを暗号化することで、既存のプロトコルであるＲＴＰを有効に利用することができる。
【００１４】
前記送信装置の実施形態において、前記ＲＴＰパケットのＵＤＰポートと、前記鍵切り替えタイミング情報のＵＤＰポートとを異ならせてもよい。これにより、ＵＤＰのポート番号に基づいて受信処理を振り分けることができ、ＴＳ受信処理での処理負荷が軽減される。
【００１５】
前記送信装置の実施形態において、前記第１の鍵は、前記ＲＴＰシーケンス番号の単位で更新される。ＲＴＰシーケンス番号の単位とは、例えばシーケンス番号が所定数（例えば10,000）経過する毎という意である。
【００１６】
前記送信装置は、前記所定のパケットに変換される前に前記第１の鍵を第２の鍵（KEYp）により暗号化する第２の暗号化部をさらに備えてもよく、その場合に前記送信部は、暗号化された第１の鍵を送信する。これにより暗号化のセキュリティが向上する。この第２の鍵に有効期限を設定することもできる。
【００１７】
前記送信装置は、前記第２の鍵（KEYp）を、第３の鍵（KEYrx）で暗号化する第３の暗号化部を更に備えてもよく、その場合に、前記第３の鍵は複数の受信装置毎に異なるものとする。これにより暗号化のセキュリティがさらに向上する。
【００１８】
前記送信装置の実施形態において、前記第３の鍵（KEYrx）は、例えば、各受信装置毎の、公開鍵暗号方式による公開鍵で暗号化されて、通知される。これにより、通信ネットワーク経由での鍵の交換が安全に行える。
【００１９】
本発明による受信装置は、送信装置からリアルタイムトランスポートプロトコル（ＲＴＰ）を利用してＩＰパケットにより通信ネットワーク経由で配信されるコンテンツを受信する受信装置であって、暗号化されたＴＳパケットを含むＲＴＰパケットとともに、前記ＴＳパケットを暗号化した鍵KEYdes-1，KEYdes-2および対応する対応シーケンス番号ｓ１，ｓ２を含む鍵切り替えタイミング情報を受信する入力部と、前記ＲＴＰパケットから前記暗号化されたＴＳパケットを抽出するＩＰ／ＴＳ変換部と、前記暗号化されたＴＳパケットを復号化鍵で復号化するＴＳ復号化部と、前記ＩＰ入力部で受信したＲＴＰパケットのシーケンス番号が前記対応シーケンス番号に達するタイミングで前記復号化鍵を前記対応シーケンス番号に対応する鍵に切り替える鍵制御部とを備えたものである。
【００２０】
本発明のこれらの構成の作用および効果ならびの他の構成については以下に詳述する。
【発明の効果】
【００２１】
本発明によれば、配信されるコンテンツが配信者の意図しない受信装置で受信された場合でも受信者が視聴できないようにすることができる。また、ＲＴＰによるＩＰ伝送において鍵の切り替えタイミングを適正に制御することができる。ＲＴＰのシーケンス番号を使用することにより、既存のプロトコルであるＲＴＰのパケットを変更する必要がなく、暗号化機能を実現することが可能となる。
【図面の簡単な説明】
【００２２】
【図１】本発明の実施の形態によるコンテンツ配信システムの概略構成を表したブロック図である。
【図２】本発明の実施の形態における各種の鍵の利用状況を模式化して示した図である。
【図３】本発明の実施の形態における送信装置の内部の主要な機能を表したブロック図である。
【図４】図３に示した送信装置内のＴＳ／ＩＰ変換部による処理の概要を説明するための図である。
【図５】図３に示した送信装置内のＴＳ／ＩＰ変換部により生成されるＩＰパケットとしてのＲＴＰパケットの概略構成を示す図である。
【図６】本発明の実施形態における受信装置の内部の主要な機能を表したブロック図である。
【図７】本発明の実施形態におけるＳＭＳのデータベース（ＤＢ）のデータ構成例を示す図である。
【図８】本発明の実施形態において受信装置をＳＭＳに登録する手順を説明するための図である。
【図９】本発明の実施形態において受信装置の登録シーケンスの例を示す図である。
【図１０】本発明の実施形態においてＳＭＳのＤＢから登録済の受信装置情報を削除する際の登録抹消シーケンスの例を示す図である。
【図１１】本発明の実施形態において受信装置のＳＭＳへの登録処理の際に、受信装置のユニークＩＤが異常、または未登録の場合のシーケンスの例を示す図である。
【図１２】本発明の実施形態におけるＳＭＳ起動時シーケンスの例を示す図である。
【図１３】本発明の実施形態における鍵変更要求（Key Change Request）シーケンスの例を示す図である。
【図１４】本発明の実施形態における受信許可状態変更シーケンスの例を示す図である。
【図１５】本発明の実施形態におけるストリーム受信権情報（ＳＲＥ：Stream Receive Entitlement）の送信シーケンスの例を示す図である。
【図１６】本実施形態における送信装置の鍵KEYdesの生成・更新に関連した処理フローの一例を示す図である。
【図１７】本発明の実施形態における受信装置の鍵KEYdesの受信・更新に関連した処理フローの一例を示す図である。
【図１８】本発明の実施形態における時間軸上での、ＲＴＰシーケンス番号と、ＳＲＥパケットに含まれる鍵(KEYdes odd/even）との対応関係を例示した図である。
【図１９】本発明の実施形態の受信装置におけるデータの流れを処理ブロックの連携で示した図である。
【発明を実施するための形態】
【００２３】
以下、本発明の実施形態について図面を参照しながら詳細に説明する。
【００２４】
（コンテンツ配信システムの概略構成）
図１に、本実施の形態によるコンテンツ配信システムの概略構成を表したブロック図を示す。本明細書において、コンテンツとは動画像（または映像）、音声、静止画等のいずれかまたはそれらの任意の組み合わせをいう。本実施形態におけるコンテンツ配信システムはデジタル放送システムとして把握することもできる。
【００２５】
このシステムは、典型的には、送信側の送信装置１０およびサブスクリプション管理サーバ（ＳＭＳ：Subscription Management Server）２０と、受信側の１以上（典型的には複数）の受信装置４０とが通信ネットワーク３０（例えばインターネット等のＩＰ網）で接続されたものである。本実施形態のシステムにおいては、送信装置１０、ＳＭＳ２０、受信装置４０は、通信ネットワーク３０を介して相互にＩＰパケットでデータの送受信を行う。
【００２６】
送信装置１０は、リアルタイムトランスポートプロトコル（ＲＴＰ)を使用したＩＰパケットにより通信ネットワーク経由でコンテンツを伝送するための装置である。より具体的には、映像、音声およびデータを含みうるコンテンツをＴＳパケットとしてＲＴＰストリームにより通信ネットワーク３０へ送信する。ＲＴＰストリームは、ユニキャストまたはマルチキャストで送信を行う。ユニキャストとは、１台の送信装置１０が特定の１台の受信装置４０へ１対１で配信を行う方式である。マルチキャストとは、１台の送信装置１０が複数の受信装置４０へ、１対特定多数で配信を行う方式である。ブロードキャストとは、１台の送信装置１０が不特定多数の受信装置４０へ配信を行う方式である。
【００２７】
受信装置４０は、送信装置１０が送信するＲＴＰストリームを受信する機器である。より具体的には、受信装置４０は、リアルタイムトランスポートプロトコル（ＲＴＰ）を使用したＩＰパケットによるＭＰＥＧ２−ＴＳの伝送を受ける受信装置であり、暗号化されたＴＳデータを送信装置１０から受信する。復号化の際に使用する鍵は送信装置１０から配布されるものを使用する。受信装置４０は１台または複数台の構成で暗号化通信を可能とする。各受信装置４０にはその出力信号を再生する表示装置５０が接続される。表示装置５０は、映像および音声を再生するモニタ、テレビジョン受信機等である。受信装置４０は、表示装置５０に接続されるセットトップボックス（ＳＴＢ）の形態でありうる。あるいは、表示装置５０は受信装置４０と一体化された形態（例えばパーソナルコンピュータ：ＰＣ）であってもよい。
【００２８】
サブスクリプション管理サーバ（ＳＭＳ）２０は、複数の利用者について、その受信装置４０のＲＴＰ受信可否についてサブスクリプション管理を行うための装置である。ＳＭＳ２０は、サブスクリプション管理用のデータベース２１０を有する。小規模なネットワークでは送信装置１０がＳＭＳ２０を兼ねる場合がありうる。
【００２９】
（本実施形態における暗号化について）
以下、ＲＴＰを使用したＩＰパケットによるＭＰＥＧ２−ＴＳの伝送において送受信するパケットの暗号化について説明する。ここでは、暗号化通信を実現するためのパケット構造およびシーケンスについて記述する。暗号化・復号化の具体的なアルゴリズム、鍵の詳細などについては既知のものを利用できるので特に詳述はしない。本実施形態で用いる共通鍵暗号の暗号化アルゴリズムは特に限定するものではない。本明細書において、鍵KEYdesの「des」はdescrambleの略語である。同様に、鍵KEYpの「p」はProgram、鍵KEYrxの「rx」はReceiverの略語である。
【００３０】
（暗号化/復号化のブロック図）
図２に、これら各種の鍵の利用状況を模式化して示す。
【００３１】
ＴＳパケットは、以下の様にして暗号化/復号化を行う。後述する鍵KEYdesおよび鍵KEYpはネットワーク経由で受信装置４０に定期的に送信される。それぞれの送信周期はＳＭＳ２０／送信装置１０の設定により可変とする。鍵KEYrxは受信装置４０のＳＭＳ２０への初回登録時に生成する。
【００３２】
本実施形態における暗号化の目的は次のとおりである。
（１）データ送信時に送信側に登録されていない受信装置４０での受信を防ぐ。
（２）暗号化でのコンテンツの保護機能による商品価値を付加する。
（３）送信装置と受信装置とを特定の組み合わせでしか動作しないようにし、安価な製品（主に受信装置）を他のシステムに転用されることを防ぐ。
【００３３】
このような目的のため、次のような各種の鍵を用いた措置を採る。
（１）送信装置でＲＴＰパケットを送信する際に、ＲＴＰパケットに含まれるＭＰＥＧ２−ＴＳパケット（本実施形態ではヘッダを含むＴＳパケット全体）を、予め用意した暗号化鍵（「KEYdes」とする）により暗号化する。本実施形態における暗号化鍵KEYdesは共通鍵暗号方式による鍵である。
（２）送信装置では暗号化鍵KEYdesを定期的に更新し、受信装置４０に対してＲＴＰパケットとともに送信する。定期的な更新により、鍵KEYdesが解析された場合でも、新しい鍵KEYdesに変更することでコンテンツの不正視聴を防ぐことができる。鍵KEYdesの更新は比較的短期間（特に限定するものではないが、例えば５〜１０秒程度）に行うことにより、解析されることをより困難にすることができる。
（３）暗号化鍵KEYdesを更新する際は映像が途切れないようにする。そのために、暗号化鍵KEYdesは、使用中の鍵KEYdes-1と、次の周期で使用する鍵KEYdes-2とを同時に送信装置から受信装置に送信し、受信装置において鍵の切り替えタイミングでシームレスにＲＴＰパケットのＭＰＥＧ２−ＴＳパケットを復号化する。鍵の切り替えタイミングの同期にはＲＴＰパケットのシーケンス番号を使用する。
【００３４】
鍵KEYdesは定期的に更新するが、鍵KEYdesの各更新値を一つしか送信しないと、その切り替え時に一瞬映像が停止してしまう。特にＵＤＰ通信を用いるので、受信装置４０にパケットが必ず届くとの保証はなく、そのため、パケットが届かなかった場合も考慮して安全のために同じ鍵（更新値）を２回以上重複して送付する。また、電源をＯＮしたタイミングでその時に使用する鍵がないと、次の送付タイミングまで待つことになり映像の表示が遅れてしまう。このような理由から、現在の周期の鍵KEYdes-1と次の周期の鍵KEYdes-2を同時に受信装置４０へ送信しておき、鍵の切り替え時に受信装置４０においてシームレスの鍵の切り替えを行えるようにする。これにより、受信装置４０の電源ＯＮ時にも鍵の切り替え時にも映像が停止することのないようにすることができる。この場合、どのタイミングで鍵を切り替えるかが重要となる。本実施形態では、送信装置１０側でＲＴＰのシーケンス番号単位で鍵の適用を変更し、そのシーケンス番号を受信装置４０に通知することにより、受信装置４０側で鍵の交換タイミングを計る。
【００３５】
また、鍵の切り替えタイミングの制御（同期）にＲＴＰのシーケンス番号を使用することの利点は、既存のプロトコルであるＲＴＰのパケットを変更する必要がないことである。これにより、既存プロトコルを変更することなく、拡張することで暗号化機能を実現することができる。
（４）鍵は、インターネットのようなオープンな通信ネットワークを使用して配信するため、盗聴などによる漏洩を防止する措置を講ずる。そのために、鍵KEYdes自体も暗号化して送信する。鍵KEYdesを暗号化するための暗号化鍵（「KEYp」とする）は事前にＳＭＳ２０（または送信装置１０）から受信装置４０に対して送信する。本実施形態における暗号化鍵KEYpは共通鍵暗号化方式による鍵である。鍵KEYpには有効期限を設け、受信装置４０が契約切れ等の理由によりその受信を停止する必要がある場合に、有効期限以降に鍵KEYdesを復号化できないようにする。有効期限を更新するため、鍵KEYpは定期的にＳＭＳ２０（または送信装置１０）から受信装置４０に対して送信する。鍵KEYpの更新周期は特に限定するものではないが、鍵KEYdesの更新周期よりは長く、一例として例えば２４時間である。
（５）鍵KEYp自体も暗号化してＳＭＳ２０（または送信装置１０）から受信装置４０に送信する。そのための暗号化鍵（「KEYrx」とする）は受信装置４０の設置時に登録する。本実施形態における暗号化鍵KEYrxは共通鍵暗号化方式による鍵である。登録はIP通信を使用して行い、その際はＳＭＳ２０（または送信装置１０）と受信装置４０とが、例えば公開鍵方式で双方のデータを暗号化して鍵KEYrxの登録を行う。
【００３６】
（送信装置１０の概略構成）
図３に、本実施形態における送信装置１０の内部の主要な機能を表したブロック図を示す。
【００３７】
送信装置１０は、ＴＳ入力部１０１、ＴＳ暗号化部１０３、ＴＳ／ＩＰ変換部１０５、ＩＰ出力部１０７、鍵生成部（KEYdes生成部）１１１、鍵制御部（KEYdes制御部）１１３、およびタイミング情報生成部１１５により構成される。
【００３８】
ＴＳ入力部１０１は、配信対象コンテンツを構成するＴＳデータ（Transport Stream）（具体的にはＭＰＥＧ２−ＴＳ）の入力を受け付ける入力インタフェース部である。その具体的なインタフェースは問わないが、例えばＤＶＢ−ＡＳＩ入力である。ＴＳは固定長（１８８バイト。誤り訂正符号を付加した場合には２０４バイト）のＴＳパケットの形式で与えられる。
【００３９】
ＴＳ暗号化部１０３は、コンテンツを構成するＭＰＥＧ２−ＴＳのＴＳパケットを所定の暗号化鍵KEYdes（第１の鍵）で暗号化するための部位であり、本発明における第１の暗号化部に相当する。
【００４０】
ＴＳ／ＩＰ変換部１０５は、暗号化されたＴＳパケットをＩＰパケットに変換するための部位である。ＩＰパケットはこの例では後述するＲＴＰパケットである。
【００４１】
ＩＰ出力部１０７は、ＲＴＰパケットおよび鍵切り替えタイミング情報を通信ネットワーク上に出力する部位であり、より具体的には、ＴＳ／ＩＰ変換部１０５から得られたＲＴＰパケット（ＩＰパケット）、および、タイミング情報生成部１１５から得られたＳＲＥパケット等を通信ネットワーク上へ出力する出力インタフェース部である。ＳＲＥはストリーム受信権情報(Stream Receive Entitlement)を意味し、本実施形態において新たに導入した情報であり、その詳細については後述する。
【００４２】
鍵生成部１１１は、暗号化鍵KEYdesとして、ＴＳ暗号化部１０３に与える第１の鍵（の更新値）として、定期的に１対の鍵KEYdes odd/evenを生成（更新）する。生成された１対の鍵KEYdes odd/evenは、後述する鍵制御部１１３、およびタイミング情報生成部１１５へ与えられる。
【００４３】
鍵制御部１１３は、鍵生成部１１１から受け取った暗号化鍵KEYdes（の更新値）を、逐次所定のタイミングで切り替えてＴＳ暗号化部１０３へ与える（すなわち、第１の鍵の更新値を切り替える）ともに、前記ＴＳ／ＩＰ変換部から取得したＲＴＰシーケンス番号を参照してＲＴＰシーケンス番号を決定する。
【００４４】
また、鍵制御部（KETdes制御部）１１３は、ＴＳ／ＩＰ変換部１０５から取得したＲＴＰシーケンス番号を参照して、１対の鍵KEYdes odd/evenの一方（例えばｅｖｅｎキー）が有効となる、当該切り替えタイミングに対応するシーケンス番号を決定する。さらに、鍵の交換時間とＴＳのビットレートから次の暗号化鍵（例えばｏｄｄキー）が有効となるシーケンス番号を算出し、タイミング情報生成部１１５へ送出する。すなわち、ＴＳのビットレートからＲＴＰパケットのシーケンス番号更新周期が求められるので、その周期と鍵の変更時間から鍵を更新するＲＴＰシーケンス番号を算出することができる。例えば、ＲＴＰシーケンス番号の更新周期が１ミリ秒で鍵の変更時間が10秒の場合、ＲＴＰパケットのシーケンス番号が10,000経過する毎に鍵のEven/Oddを切り替える。
【００４５】
タイミング情報生成部１１５は、鍵制御部（鍵制御部）１１３から受け取ったシーケンス番号と、鍵生成部１１１から受け取った暗号化鍵KEYdes odd/even（第１の鍵の各更新値）とから、鍵切り替えタイミング情報を含むＳＲＥ(Stream Receive Entitlement)パケットを生成し、ＩＰ出力部１０７を介してこのＳＲＥパケットを通信ネットワーク上へ送信させる。このＳＲＥパケットは、受信を許可している全ての受信装置４０に対してユニキャスト、マルチキャストまたはブロードキャストで送信される、ストリームのデスクランブル情報としての鍵KEYdesを通知するためのパケットである。
【００４６】
より具体的には、鍵制御部１１３では、ＴＳ／ＩＰ変換部１０５から取得するＲＴＰシーケンス番号を監視して、先に算出したｅｖｅｎキーが有効となるシーケンス番号まで待機し、そのシーケンス番号に達したタイミングでｅｖｅｎキーによるＴＳパケットの暗号化を開始する。その後は同様に、oddキーが有効となるシーケンス番号まで待機して鍵を次の更新値（ｏｄｄキー）に変更する。変更後、次のｅｖｅｎキーが有効となるシーケンス番号を算出して、新たなKEYevenを作成してＳＲＥを更新する。以降、このような処理が繰り返して実行される。
【００４７】
図４に、ＴＳ／ＩＰ変換部１０５による処理の概要を説明する。この図に模式的に示すように、ＴＳ／ＩＰ変換部１０５は所定の個数の時系列のＴＳパケット６０をカプセル化して１つのＲＴＰパケット７０を構成する。時系列の複数のＴＳパケットは、映像、音声、ＰＡＴ（Program Association Table)、ＰＭＴ(Program Map Table)、ＰＣＲ(Program Clock Reference)、Null(空)等の各種のパケットを含み得る。各ＲＴＰパケット７０には一連のシーケンス番号(n, n+1, …）が付与される。シーケンス番号はＲＴＰパケットの送出ごとに増分（＋１）される。
【００４８】
図５に、ＴＳ／ＩＰ変換部１０５により生成されるＩＰパケットとしてのＲＴＰパケット７０の概略構成を示す。ＲＴＰパケット７０は、ＩＰヘッド７１と、ＵＤＰヘッダ７２と、ＲＴＰヘッダ７３と、データ７４の各部により構成される。
【００４９】
ＩＰヘッド７１は、ＩＰパケットのヘッダ部であり、送信元ＩＰアドレス、宛先ＩＰアドレス等が格納される。
【００５０】
ＵＤＰヘッダ７２は、ＵＤＰパケットのヘッダ部であり、ＵＤＰに関連した送信元ポートおよび宛先ポートが格納される。
【００５１】
ＲＴＰヘッダ７３は、ＲＴＰパケットのヘッダ部であり、上述したＲＴＰパケットのシーケンス番号、およびタイムスタンプ等が格納される。タイムスタンプには各ＴＳパケットに関連したシステムクロック信号が格納される。
【００５２】
データ７４には、一連のＴＳパケット等のデータが包含される。
【００５３】
（受信装置４０の概略構成）
図６に、本実施形態における受信装置４０の内部の主要な機能を表したブロック図を示す。受信装置４０は、送信装置１０からリアルタイムトランスポートプロトコル（ＲＴＰ）を利用してＩＰパケットにより通信ネットワーク経由で配信されるコンテンツを受信する装置であり、ＩＰ入力部４０１、ＩＰ／ＴＳ変換部４０３、ＴＳ復号化部４０５、ＴＳ出力部４０７、タイミング情報解析部４１１、および鍵制御部４１３により構成される。
【００５４】
ＩＰ入力部４０１は、送信装置１０から受け取ったＩＰパケット（ＲＴＰパケットやＳＲＥパケット等）を入力する入力インタフェース部である。ＩＰ入力部４０１は、より具体的には、暗号化されたＴＳパケットを含むＲＴＰパケットとともに、ＴＳパケットを暗号化した鍵KEYdes-1，KEYdes-2およびそれぞれに対応する対応シーケンス番号ｓ１，ｓ２を含む鍵切り替えタイミング情報を受信する。ＩＰ入力の具体的なインタフェースは問わない。ＲＴＰパケットは後段のＩＰ／ＴＳ変換部４０３へ送られ、ＳＲＥパケットは後述のタイミング情報解析部４１１へ送られる。
【００５５】
ＩＰ／ＴＳ変換部４０３は、受信したＩＰパケット、すなわちＲＴＰパケットをＴＳパケットに変換（復元）する部位である。復元されたＴＳパケットは暗号化ＴＳパケットであり、後段のＴＳ復号化部４０５へ入力される。ＩＰ／ＴＳ変換部４０３は、また、ＲＴＰパケットに含まれるＲＴＰシーケンス番号を抽出し、後述の鍵制御部４１３へ送る。
【００５６】
タイミング情報解析部４１１は、ＩＰ入力部４０１から受け取ったＳＲＥパケットを解析し、鍵KEYdes odd/evenと、これらの鍵に対応付けられた鍵切り替えタイミングを定めるＲＴＰシーケンス番号ｓ１，ｓ２とを抽出し、鍵制御部４１３へ送る。
【００５７】
鍵制御部４１３は、ＩＰ入力部４０１で受信したＲＴＰパケットのシーケンス番号が前記対応シーケンス番号に達するタイミングで復号化鍵を、対応シーケンス番号に対応する鍵に切り替える。すなわち、鍵制御部４１３は、鍵制御部ＩＰ／ＴＳ変換部４０３からのＲＴＰシーケンス番号を監視し、タイミング情報解析部４１１から受け取った鍵KEYdes odd/evenと、これらに対応するＲＴＰシーケンス番号ｓ１，ｓ２に基づいて、所定のタイミングで所定の鍵KEYdes（更新値）をＴＳ復号化部４０５へ出力する。
【００５８】
ＴＳ復号化部４０５は、鍵制御部４１３から与えられた鍵KEYdesに基づいて、暗号化ＴＳパケットを復号し、元のＴＳパケットを再生する。
【００５９】
ＴＳ出力部４０７は、ＴＳ復号化部４０５から復号されたＴＳパケットを受けて、所定（所望）の形式のＴＳデータを出力する。例えば、ＴＳデータをデジタル放送波としてＲＦ信号に変換する場合には、ＴＳ出力部４０７の後段にＯＦＤＭ変調器およびＲＦアップコンバータ等（いずれも図示せず）を設けてもよい。
【００６０】
（ＳＭＳ２０のデータベース２１０のデータ構成例）
図７にＳＭＳ２０のデータベース（ＤＢ）２１０のデータ構成例を示す。
【００６１】
図７は、データベース２１０として、本実施形態におけるコンテンツの受信・再生が許可される受信装置４０の各々について保持するデータ項目の一例を示している。この例では、受信装置４０自身のＩＰアドレスである受信装置ＩＰアドレス２１１、受信装置４０のＭＡＣ（Media Access Control)アドレス２１２、各利用者を一意に識別するためのユニークＩＤ（利用者には非公開な利用者毎の識別子）２１３、受信装置４０の製品シリアル番号（例えば、製品筐体に貼付するシリアル番号）２１４、送信装置１０自身のＩＰアドレスである送信装置ＩＰアドレス２１５、送信装置１０がＩＰパケットを送る際の宛先ＩＰアドレスである送信装置宛先ＩＰアドレス２１６、宛先ポート番号である送信先ＵＤＰポート番号２１７、受信装置４０毎のKEYp有効期限２１８、等である。ＲＴＰパケットをユニキャストで送信する場合、送信装置宛先ＩＰアドレス２１６と受信装置ＩＰアドレス２１１は同一になるが、マルチキャストで送信する場合、特別なマルチキャストアドレスを使用して送信するため、両ＩＰアドレスは同一にならない。送信装置１０はＲＴＰの宛先ＩＰアドレスにマルチキャストアドレスを指定してネットワーク全体に送信し、各受信装置４０はＲＴＰパケットの宛先ＩＰアドレスを確認して自身が受信したいマルチキャストアドレスであれば受信処理を行う。送信装置ＩＰアドレス２１５、送信装置宛先ＩＰアドレス２１６、送信先ＵＤＰポート番号２１７は通常、全受信装置４０に共通の情報であるが、複数のコンテンツのＲＴＰパケットを混在して送信する場合には、受信装置毎に送信装置宛先ＩＰアドレス２１６および送信先ＵＤＰポート番号２１７が異なることになる。なお、送信装置ＩＰアドレス２１５は全受信装置４０に共通である。
【００６２】
なお、ＳＭＳ２０自体は、特に図示しないが、中央処理装置（プロセッサ）、入出力装置、記憶装置、通信インタフェース部等の既存のデータ処理装置により構成することができる。
【００６３】
（暗号化通信パケット）
以下、本実施形態における暗号化通信で使用するパケットの詳細について説明する。
【００６４】
（SCP: Subscription Control Packet）
本実施形態では、受信装置４０のサブスクリプション制御データを送受信するためのＴＣＰ／ＩＰパケットとして、サブスクリプション制御パケット（ＳＣＰ：Subscription Control Packet）を用いる。このパケットの通信に使用するＴＣＰの宛先ポート番号は設定により変更可能とする。
【００６５】
SCP TCPパケットのペイロードは次のような項目を含む。
・id：  SCP ID
・length： id，lengthを除いたペイロードのバイトサイズ
・type： ＳＣＰ種別
・reserve： 予約
・encryption_type： ＳＣＰペイロード暗号化種別（ＳＣＰペイロードの暗号化アルゴリズム種別）
・payload： ＳＣＰペイロード（必要に応じて暗号化される）
・crc_32： ＳＣＰペイロードの32Bit CRC（ＳＣＰペイロードが暗号化されている場合は暗号化後のデータのＣＲＣ（Cyclic Redundancy Check））
【００６６】
（ＳＣＰ種別（type））
ＳＣＰ種別に設定しうる項目を以下に挙げる。
・SMS Notify： ＳＭＳ通知（ＳＭＳサーバのＩＰアドレスを受信装置に通知する）。
・Receive Admission Request：受信許可要求（受信装置がＳＭＳへの登録リクエスト時に送信する要求）。鍵KEYsmsnで暗号化される。
・Receive Admission Response： 受信許可応答（Receive Admission Requestに対する応答）。公開鍵PbKEYrxで暗号化される。
・Receiver ID Request： 受信装置ＩＤ要求（受信許可要求が受信装置からＳＭＳに送信された場合に受信装置のＩＤを要求する）。公開鍵PbKEYrxで暗号化される。
・Receiver ID Response： 受信装置ＩＤ応答（Receiver ID Requestに対する応答）。 公開鍵PbKEYsmsで暗号化される。
・Admission Complete Notify： 参加完了通知（受信許可応答Receive Admission Responseにより受信装置の登録が完了した際に受信装置からＳＭＳに完了を通知する）。公開鍵PbKEYsmsで暗号化される。
・Receiver Delete Request：  受信装置登録抹消要求（ＳＭＳのＤＢから受信装置情報を削除する）。鍵KEYrxで暗号化される。
・Ack： Ack 応答  （通信毎に異なる）
【００６７】
（SRCP:  Subscription Control Packet)
本実施形態では、受信装置のＲＴＰストリーム受信可否・ＴＳパケットのデスクランブル鍵を送るためのＵＤＰ／ＩＰパケットとして、ＳＲＣＰ（Subscription Control Packet)を用いる。ＲＴＰはＵＤＰで送信するため、送信時に宛先ポート番号を設定する必要がある。ＳＲＣＰの伝送に使用するＵＤＰの宛先ポート番号は、ＭＰＥＧ２−ＴＳ伝送（TS over IP）の宛先ポートと異なる空きポートを利用する。本例では宛先ポート番号に６加算した値とする。この効果（意義、利点）については後述する。
【００６８】
このＵＤＰパケットのペイロードは以下の様な項目を含む。
・id： SRCP ID
・length： id、lengthを除いたペイロードのバイトサイズ
・type： SRCP種別
・reserve： 予約
・encryption_type： SRCPペイロード暗号化種別（SRCPペイロードの暗号化アルゴリズム種別）。
・payload： SRCPペイロード  （必要に応じて暗号化される）。
・crc_32： SRCPペイロードの32Bit CRC（SRCPペイロードが暗号化されている場合は暗号化後のデータのＣＲＣ）。
【００６９】
SRCP種別（type）に設定する項目を以下に挙げる。
・Key Change Request： 送信装置からＳＭＳに鍵の変更が発生した場合に送信する鍵変更要求
・Key Change Response：Key Change Requestに対する鍵変更応答。
・Key Get Request： ＳＭＳから送信装置に対して鍵を要求する鍵取得要求。
・Key Get Response： Key Get Requestに対する鍵取得応答。
・Stream Receive Permission： ＳＭＳから受信装置に対して送信される、鍵KEYpを含むストリーム受信許可情報（ＳＲＰ）。（送信するデータは受信装置毎に異なる）  鍵KEYrxで暗号化される。
・Stream Receive Entitlement：送信装置から受信装置に対してストリームの鍵KEYdesを含む鍵切り替えタイミング情報を送信するストリーム受信権情報（ＳＲＥ）。 鍵KEYpで暗号化される。
【００７０】
（受信装置の登録）
図８により受信装置４０をＳＭＳ２０に登録する手順を説明する。
【００７１】
各受信装置４０は、利用者サイドでの設置時等の初回通信開始時にＳＭＳ２０に受信装置情報の登録を行い（Ｓ１）、ＲＴＰパケットの受信許諾を受ける。その情報はデータベース２１０に登録される。この際、図７に示した「送信装置ＩＰアドレス」を除いた項目について登録される。「送信装置宛先ＩＰアドレス」「送信先ＵＤＰポート番号」については設定済みの項目が選択されて登録される。
【００７２】
ＳＭＳ２０は、その登録完了後、当該受信装置４０宛に、自身（ＳＭＳ）のＩＰアドレスを通知する（Ｓ２）。受信装置４０は、通知されたＳＭＳ２０のＩＰアドレス宛にＴＳパケットの復号化に使用する「鍵の種」の取得要求を送信する（Ｓ３）。受信装置４０からの要求に応じて、ＳＭＳ２０は、当該「鍵の種」を受信装置４０へ通知する（Ｓ４）。この処理によりＳＭＳ２０と受信装置４０で同一の鍵（KEYrx）を生成して（Ｓ５）、登録完了とする（Ｓ６）。なお、本実施形態では、「鍵の種」として、事業者毎にユニークなＩＤを割り当て、それを使用する。鍵KEYrxは鍵の種をそのまま使用するのではなく、鍵の種を加工して作成する。この加工にには受信装置同士で同一にならないよう受信装置の持つ固有情報を付加して行う。
【００７３】
（受信装置登録シーケンス）
図９に受信装置４０の具体的な登録シーケンスの例を示す。
【００７４】
ＳＭＳ２０は、そのＤＢ２０１への受信装置情報追加を契機に、自身（ＳＭＳ）のＩＰアドレスを含むＳＭＳ通知（SMS Notify）をユニキャストで当該受信装置４０宛に送信する（Ｓ２１，Ｓ２２）。ＳＭＳ通知（SMS Notify）は、ＳＭＳ２０から受信装置４０に対してＳＭＳ２０の存在を知らせるために送信するデータである。ＳＭＳ２０は、受信装置４０から受信許可要求（Receive Admission Request）が返信されるまで（Ｓ４１）、この送信を反復継続する。図の例では、ステップＳ２１の送信には返信がなく、ステップＳ２２に対して返信があった場合を想定している。
【００７５】
受信装置４０は、受信許可要求（Receive Admission Request）をＳＭＳ２０へ送信する（Ｓ４１）。受信許可要求は、受信装置４０がＳＭＳ２０への登録リクエスト時に送信する要求であり、受信装置４０が生成した公開鍵PbKEYrxをＳＭＳ２０の暗号化鍵KEYsmsnで暗号化してＳＭＳ２０へ送信する。鍵KEYsmsnは、受信装置４０にＳＭＳサーバのＩＰアドレスを通知するための情報を暗号化/復号化するための鍵である。
【００７６】
ＳＭＳ２０は、受信許可要求（Receive Admission Request）に応じて受信装置ＩＤ要求（Receiver ID Request）を受信装置４０へ送信する（Ｓ２３）。受信装置ＩＤ要求は、ＳＭＳ２０から受信装置４０に対してユニークＩＤの取得リクエストを送信するためのデータであり、ＳＭＳ２０の公開鍵PbKEYsmsを、受信装置４０の公開鍵PbKEYrxで暗号化したものを含む。
【００７７】
これに対して受信装置４０は、自身のユニークＩＤをＳＭＳ２０の暗号化鍵KEYsmsnで暗号化してＳＭＳ２０へ送信する（Ｓ４２）。この時、ＳＭＳ２０は受信装置４０からユニークＩＤを取得して受信装置４０の登録情報と照合し、これにより当該受信装置４０が登録済みの受信装置であることを確認する。
【００７８】
照合の結果、登録済みの受信装置であればＳＭＳ２０は、受信許可応答（Receive Admission Response）により「KEYrxの種」となる情報を、受信装置４０の公開鍵PbKEYrxで暗号化して、受信装置４０に送信する（Ｓ２４）。受信装置４０はこの情報を自身の秘密鍵PrKEYrxで復号化することができる。受信装置４０は、受信許可応答（Receive Admission Response）により受信装置の登録が完了した際に、参加完了通知（Admission Complete Notify）をＳＭＳ２０に完了を通知する（Ｓ４３）。参加完了通知（Admission Complete Notify）は、受信装置の登録が完了しストリームの受信が完了となったタイミングで、受信装置４０からＳＭＳ２０に対して送信するデータである。この参加完了通知は公開鍵PbKEYsmsで暗号化される。ＳＭＳ２０はこの情報を自身の秘密鍵PrKEYsmsで復号化することができる。
【００７９】
ＳＭＳ２０は、Ack（正常）を受信装置４０へ通知する（Ｓ２５）。Ackは、要求（〜 Request）や通知（〜 Notify）に対する受信応答として送信するデータである。
【００８０】
なお、受信装置４０は、登録完了後、ＳＭＳ２０から再度、ＳＭＳ通知（SMS Notify）を受信した場合、同様の処理を再度実行する。
【００８１】
受信装置４０は受け取った鍵KEYrxの種から鍵KEYrxを生成する（Ｓ４４）。同じ「KEYrxの種」から、ＳＭＳ２０も同じ鍵KEYrxを生成し（Ｓ２６）、ＳＭＳ２０への登録が完了となる（Ｓ２７）。
【００８２】
（受信装置登録抹消シーケンス）
図１０は、ＳＭＳ２０のＤＢ２１０から登録済の受信装置情報を削除する際の登録抹消シーケンスの例を示す。
【００８３】
ＳＭＳ２０は、受信装置４０へ登録抹消要求（Receiver Delete Request）を送信する（Ｓ２１１）。この要求は受信装置４０の鍵KEYrxで暗号化される。受信装置４０はそのパケットを受信して、Ａｃｋを返信し（Ｓ４１１）、自身の持つ鍵KEYrxおよび鍵KEYpを削除する（Ｓ４１２）。その後、ＳＭＳ２０はデータベース２１０から当該受信装置４０の鍵KEYrxを消去する（Ｓ２１２）。
【００８４】
（受信装置ユニークＩＤ異常・未登録時シーケンス）
図１１に、受信装置４０のＳＭＳ２０への登録処理の際に、受信装置４０のユニークＩＤが異常、または未登録の場合のシーケンスの例を示す。
【００８５】
このシーケンスにおけるステップＳ４２１，Ｓ２２１，Ｓ４２２は、図９に示したステップＳ４１，Ｓ２３，Ｓ４２と同じであり、重複した説明は省略する。ステップＳ４２２の受信装置ＩＤ応答（Receiver ID Response）でＳＭＳ２０に返信された受信装置４０のユニークＩＤがＳＭＳ２０に登録されているものと一致しない、または未登録の場合、ＳＭＳ２０は、受信許可応答（Receive Admission Response）に「異常」を設定して受信装置４０に返す（Ｓ２２２）。その後、ＳＭＳ２０はＳＭＳ通知（SMS Notify）の送信からリトライを行い、所定回（この例では３回）連続して失敗するまで、受信装置４０の登録を試行する（Ｓ２２３）。試行までの待ち時間は設定で変更可能である。
【００８６】
所定回連続して失敗した場合、受信装置４０の登録を失敗として終了する。この場合、ＳＭＳ通知（SMS Notify）は手動で送信するか、自動で再度実行するかは設定により変更可能である。
【００８７】
なお、詳細なシーケンスは示さないが、ＳＭＳ２０が、暗号化されたＳＣＰペイロードの復号化に失敗した場合、同様に、ＳＭＳ２０はＳＭＳ通知（SMS Notify）の送信からリトライを行い、所定回連続して失敗するまで受信装置４０の登録を試行する。ＳＣＰペイロードの復号化の失敗とは、ＣＲＣの値をチェックしてチェック結果が誤りである場合である。
【００８８】
（ＲＴＰ送信中シーケンス）
以下、送信装置１０からＲＴＰ送信中に、暗号化通信に関わるデータのシーケンスについて説明する。
【００８９】
暗号化通信に関わるデータには上述したストリーム受信許可情報（ＳＲＰ：Stream Receive Permission）、ストリーム受信権情報（ＳＲＥ：Stream Receive Entitlement）の２つがあり、いずれもＳＲＣＰパケットを使用して送受信する。本明細書では、ＳＲＥパケットおよびＳＲＰパケット（両パケットは広義にはＳＲＣＰパケットに含まれる）を暗号化パケットと呼ぶ。これらのパケットの詳細については後述する。
【００９０】
（ＳＲＰシーケンス）
ＳＭＳ２０からユニキャストで受信装置４０宛にストリーム受信許可情報（ＳＲＰ：Stream Receive Permission）を以下のタイミングで送信する。
・ＳＭＳ起動時
・送信装置からのKey Change RequestをＳＭＳが受信時
・前回送信時間からＳＲＰ送信間隔以上経過時
・契約変更等により受信装置のストリーム受信許可状態に変更が発生し、ＳＭＳのＤＢが更新された時
【００９１】
ＳＲＰ送信間隔は設定により可変とし、ストリーム受信許可情報（ＳＲＰ）はユニキャストで全ての受信装置４０宛に送信する。送信間隔は、受信装置４０の台数やＳＭＳ２０の負荷状況に応じてユーザが設定することができる。
【００９２】
（ＳＭＳ起動時シーケンス）
図１２にＳＭＳ起動時シーケンスの例を示す。
【００９３】
ＳＭＳ２０は、自身が起動したタイミングで鍵取得要求（Key Get Request）を送信装置１０へ送付する（Ｓ２３１，Ｓ２３２）。これにより、送信装置１０から鍵取得要求により鍵KEYpを取得して（Ｓ１３１）、ストリーム受信許可情報（ＳＲＰ）の定期送信を開始する（Ｓ２３２）。
【００９４】
鍵取得要求（Key Get Request）は、ＳＭＳ２０が送信装置１０からKEYpの情報を取得する際に送信するデータである。
【００９５】
ＳＭＳ起動時に送信装置１０が存在しない場合、鍵取得要求（Key Get Request）を送信装置１０に対して定期的に送信して鍵取得応答（Key Get Response）を受信するまで繰り返す。
【００９６】
鍵取得応答（Key Get Response）は、送信装置１０からＳＭＳ２０に対して鍵取得要求（Key Get Request）に対する応答として送信するデータである。送信装置１０は、key_infoで送信している全てのＲＴＰストリームの鍵情報をＳＭＳ２０に送信する。
【００９７】
鍵取得応答（Key Get Response）のSRCPペイロードは以下の項目を含む。
・number： SRCPペイロードに含まれるkey_info個数
・key_info：キー情報：以下の項目を含む。
・・ip_version： ＩＰバージョン （IPv4、IPv6等の区別）
・・key_status： 変更が発生したKEYpの状態
・・reserve： 予約
・・src_ip： ＲＴＰストリーム送信元ＩＰアドレス
・・dst_ip： ＲＴＰストリーム送信先ＩＰアドレス
・・port： ＲＴＰストリーム 宛先ポート番号
・・limit_datetime KEYpの有効期限 （年月日時分秒）
・・keyp_length： keypバイトサイズ
・・keyp： KEYp
【００９８】
ＳＭＳ２０は、初回のStream Receive Permission (SRP)の送信後、ＳＲＰ送信間隔でＳＲＰの送信を繰り返す（Ｓ２３２，Ｓ２３３，…）。
【００９９】
ストリーム受信許可情報（ＳＲＰ：Stream Receive Permission）は、ＳＲＣＰで送受信するデータであり、受信装置４０毎にＳＭＳ２０からユニキャストでストリームの受信可否を通知する。具体的には、鍵KEYpを受信装置４０へ送付する。
【０１００】
ストリーム受信許可情報（Stream Receive Permission）のSRCPペイロードは以下の項目を含む。stream_infoは通知するストリーム情報が複数の場合、ひとつのＳＲＰパケットに複数のstream_infoを設定することが可能である。受信装置４０ではstream_infoに含まれていない鍵KEYpを内部に保持している場合、ＳＲＰを受信したタイミングでその鍵KEYpを削除する。
・datetime： 送信装置の現在時刻 （年月日時分秒）
・number： SRCPペイロードに含まれるstream_info個数
・stream_info： ip_version ＩＰバージョン （IPv4、IPv6等の区別）
・reserve：  予約
・src_ip： ＲＴＰストリーム送信元ＩＰアドレス
・dst_ip： ＲＴＰストリーム送信先ＩＰアドレス
・port： ＲＴＰストリーム宛先ポート番号
・limit_datetime： KEYpの有効期限 （年月日時分秒）
・keyp_length： keypバイトサイズ
・keyp： KEYp
【０１０１】
（Key Change Requestシーケンス）
鍵変更要求（Key Change Request）は、鍵KEYpの変更が発生した際に送信装置１０からサーバに送信するデータである。key_infoは通知する鍵が複数の場合、ひとつの鍵変更要求（Key Change Request）パケットに複数設定できる。鍵KEYpの値が変更された場合、key_statusに無効を設定したkey_infoと新しいkeypを設定したkey_infoの２つを送信する必要はなく、keypの値を変更したデータのみをＳＭＳ２０に送信すればよい。
【０１０２】
鍵変更要求（Key Change Request）のSRCPペイロードは以下の項目を含む。
・number： SRCPペイロードに含まれるkey_info個数
・key_info：  キー情報：以下の項目を含む。
・・ ip_version： ＩＰバージョン IPv4、IPv6等の別）
・・key_status： 変更が発生したKEYpの状態 （有効または無効）
・・reserve reserve：予約
・・src_ip： ＲＴＰストリーム送信元ＩＰアドレス
・・dst_ip： ＲＴＰストリーム送信先ＩＰアドレス
・・port： ＲＴＰストリーム 宛先ポート番号
・・keyp_length： keypバイトサイズ
・・keyp： KEYp
【０１０３】
図１３に鍵変更要求（Key Change Request）シーケンスの例を示す。
【０１０４】
ＳＲＰの定期送信中に送信装置１０がＳＭＳ２０に鍵変更要求（Key Change Request）を送信した場合（Ｓ１４１）、ＳＭＳ２０は、鍵変更応答（Key Change Response）を送信装置１０へ返す（Ｓ２４２）。ＳＭＳ２０は、更新された鍵KEYpを受信装置４０宛に即時に送信する（Ｓ２４１）。受信装置４０は、これに応じてKEYpを更新する（Ｓ４４１）。ＳＭＳ２０は、以後、ＳＲＰ送信間隔で当該更新された鍵KEYpの送信を繰り返す（Ｓ２４３，Ｓ２４４，…）。
【０１０５】
鍵変更応答（Key Change Response）は、ＳＭＳ２０から送信装置１０に対して鍵変更要求（Key Change Request）の応答として送信するデータである。そのＳＣＰペイロードは以下の項目を含む。
・number： Key Change Requestで受信したkey_info個数
【０１０６】
（受信許可状態変更シーケンス）
図１４に受信許可状態変更シーケンスの例を示す。
【０１０７】
ＳＭＳ２０は、契約の変更等の要因により、受信装置４０の受信許可状態を変更する（Ｓ２５１）。この場合、契約の変更なので受信装置４０の受信許可状態の変更後、ＳＭＳ２０から即時に、鍵KEYpを含むストリーム受信許可情報（ＳＲＰ：Stream Receive Permission）を送信する（Ｓ２５２）。ＳＲＰ送信後はＳＲＰ送信間隔で送信を繰り返す（Ｓ２５３，…）。ストリーム受信許可情報（Stream Receive Permission）のSRCPペイロードは上述したとおりである。
【０１０８】
（ＳＲＥ送信シーケンス）
図１５にストリーム受信権情報（ＳＲＥ：Stream Receive Entitlement）の送信シーケンスの例を示す。
【０１０９】
送信装置１０から全ての受信装置４０宛（ＲＴＰの宛先と同一）にＳＲＥ送信間隔でストリーム受信権情報（ＳＲＥ：Stream Receive Entitlement)を送信する（Ｓ１６１）。ＳＲＥ送信間隔は設定により可変とし、ＳＲＰ送信間隔や送信装置１０の負荷状況に応じてＳＲＥ送信間隔を設定する。
【０１１０】
各ＳＲＥ送信間隔の期間中にＴＳパケット単位に、ＴＳストリームを暗号化して受信装置４０へ送信する（Ｓ１６２〜Ｓ１６４）。
【０１１１】
ストリーム受信権情報（ＳＲＥ）は、ＳＲＣＰで送受信するデータであり、ＲＴＰストリームを復号化するための鍵KEYdes（を含む鍵切り替えタイミング情報）を送信装置１０から受信装置４０に通知する際に送信するデータである。より具体的には、受信を許可している全ての受信装置４０に対してユニキャスト、マルチキャストまたはブロードキャストで送信してＴＳストリームを復号するための鍵情報（デスクランブル情報）を通知するためのデータである。
【０１１２】
ストリーム受信権情報（ＳＲＥ）のSRCPペイロードは以下の項目を含む。
・datetime： 送信装置の現在時刻 （年月日時分秒）
・des_current： 現在有効なデスクランブルキー （0：EVEN / １：ODD）
・reserve：  予約
・des_info_even：evenキー情報
・・sequence： des_info_evenが有効となるシーケンス番号（「ＲＴＰパケットのシーケンス番号」に相当）
・・keydes_length： keydesバイトサイズ
・・keydes： KEYdes
・des_info_odd：oddキー情報
・・ sequence： des_info_oddが有効となるシーケンス番号（「ＲＴＰパケットのシーケンス番号」に相当）
・・keydes_length： keydesバイトサイズ
・・keydes： KEYdes
【０１１３】
（送信装置の処理フロー）
図１６に、本実施形態における送信装置１０の鍵KEYdesの生成・更新に関連した処理フローの一例を示す。
【０１１４】
送信装置１０（鍵生成部１１１）は、暗号化鍵KEYdesとして、鍵Ｎ，Ｎ＋１を生成する（Ｓ５０１）。鍵Ｎ，Ｎ＋１は、本発明における「現在の周期で使用する鍵KEYdes-1と、次の周期で使用する鍵KEYdes-2」に相当する。
【０１１５】
送信装置１０（鍵制御部１１３，タイミング情報生成部１１５）は、これらの鍵Ｎ，Ｎ＋１をそれぞれＲＴＰシーケンス番号ｓ，ｓ＋１から適用するものとして、ＩＰ出力部１０７から受信装置４０へ定期送信を開始する（Ｓ５０２）。この処理は図１５のステップＳ１６１，Ｓ１６５，…に相当する。
【０１１６】
次いで、送信装置１０（鍵制御部１１３，ＴＳ暗号化部１０３，ＴＳ／ＩＰ変換部１０５）は、ＲＴＰシーケンス番号ｓから鍵Ｎを使用して暗号化し、ＴＳ／ＩＰ変換部１０５によりＲＴＰパケットに変換してＩＰ出力部１０７から受信装置４０へ送信を開始する（Ｓ５０３）。この処理は、図１５のステップＳ１６２〜Ｓ１６４に相当する。
【０１１７】
その後、送信装置１０（鍵生成部１１１）は、所定のタイミングで鍵Ｎ＋２を生成する（Ｓ５０４）。送信装置１０は、一定時間待機した後（Ｓ５０５）、ＲＴＰシーケンス番号ｓ＋１から対応する鍵Ｎ＋１を使用してＴＳパケットを暗号化して、ＴＳ／ＩＰ変換部１０５によりＲＴＰパケットに変換してＩＰ出力部１０７から受信装置４０へ送信する（Ｓ５０６）。
【０１１８】
その後、送信装置１０（鍵制御部１１３，タイミング情報生成部１１５）は、これらの鍵Ｎ＋１，Ｎ＋２をそれぞれＲＴＰシーケンス番号ｓ＋１、ｓ＋２から適用するものとして、ＩＰ出力部１０７から受信装置４０へ定期送信を開始する（Ｓ５０７）。
【０１１９】
これらのステップＳ５０５〜Ｓ５０８は、番号Ｎおよびｓを更新（増分）しながら、繰り返して実行される。
【０１２０】
（受信装置の処理フロー）
図１７に、本実施形態における受信装置４０の鍵KEYdesの受信・更新に関連した処理フローの一例を示す。
【０１２１】
受信装置４０は、鍵Ｎ，Ｎ＋１とその対応シーケンス番号ｓ，ｓ＋１を受信する（Ｓ６０１）。より具体的には、ＩＰ入力部４０１にＳＲＥパケットを受信し、タイミング情報解析部４１１により、このＳＲＥパケットを解析して、鍵Ｎ，Ｎ＋１とその対応シーケンス番号ｓ，ｓ＋１を抽出する。
【０１２２】
ついで、受信装置４０（鍵制御部４１３）は、シーケンス番号ｓのＲＴＰパケットを受信するまで待機する（Ｓ６０２）。
【０１２３】
受信装置４０は、ＩＰ／ＴＳ変換部４０３においてＲＴＰパケットをＴＳパケットに変換するとともに、鍵制御部４１３でＲＴＰパケットを監視し、シーケンス番号ｓのＲＴＰパケットを受信したとき、このＲＴＰパケットからＴＳ復号化部４０５により鍵Ｎを使用して、そのＴＳパケットの復号化を開始する（Ｓ６０３）。復号化されたＴＳパケットはＴＳ出力部４０７から後段へ出力される。
【０１２４】
その後、受信装置４０（鍵制御部４１３）は、シーケンス番号ｓ＋１のＲＴＰパケットを受信するまで待機する（Ｓ６０４）。
【０１２５】
受信装置４０（鍵制御部４１３，ＴＳ復号化部４０５）は、シーケンスｓ＋１のＲＴＰパケットから鍵Ｎ＋１を使用して、そのＴＳパケットの復号化を開始する（Ｓ６０５）。
【０１２６】
その後、受信装置４０は、鍵Ｎ＋１，Ｎ＋２とその対応シーケンス番号ｓ＋１，Ｓ＋２を受信する（Ｓ６０６）。
【０１２７】
以後、受信装置４０は、番号ｓとＮの値を更新（増分）しながら、ステップＳ６０２〜Ｓ６０６を繰り返して実行する。
【０１２８】
（ＲＴＰシーケンス番号と、ＳＲＥパケット内の鍵(KEYdes odd/even）との対応関係)
図１８は、本実施形態における時間軸上での、ＲＴＰシーケンス番号と、ＳＲＥパケットに含まれる鍵(KEYdes odd/even）との対応関係を例示するものである。
【０１２９】
この例では便宜上、ＲＴＰシーケンス番号が０から１０００までを示している。ＲＴＰシーケンス番号が１００変化する毎の周期で、すなわち、ＲＴＰシーケンス番号が１００の倍数になる毎に、暗号化鍵（KEYdes）が更新される場合を想定している。現在の周期内で、その周期に使用する鍵と、次の周期で使用する鍵とが一緒に、上述したＳＲＥパケットで受信装置４０へ送信される。「現在有効な鍵」(current)は、上述した「SRE SRCPペイロード」中の項目「des_current」で指定される。図から分かるように、「現在有効な鍵」としてのｏｄｄキーとｅｖｅｎキーは周期毎に交互に切り替わるようにしている。
【０１３０】
図の例では、「現在有効な鍵」(current)は、ＲＴＰシーケンス番号０〜９９の周期Ｐ１ではｅｖｅｎキーであり、次のＲＴＰシーケンス番号１００〜１９９の周期Ｐ２ではｏｄｄキー、次のＲＴＰシーケンス番号２００〜２９９の周期Ｐ３ではｅｖｅｎキー、…となっている。
【０１３１】
また、周期Ｐ１内で送信されるＳＲＥパケットには、その周期で使用する鍵と、次の周期で使用する鍵の２つの鍵Ｎ，Ｎ＋１として、それぞれdes_info_even（N)とdes_info_odd（N+1)が対応シーケンス番号(0, 100)とともに包含される。次の周期Ｐ２内で送信されるＳＲＥパケットには、その周期内で使用する鍵と、次の周期で使用する鍵の２つの鍵Ｎ＋１，Ｎ＋２として、それぞれdes_info_odd（N+1)とdes_info_even（N+2)が対応シーケンス番号(100, 200)とともに包含される。次の周期Ｐ３内で送信されるＳＲＥパケットにはその周期内で使用する鍵と、次の周期で使用する鍵の２つの鍵Ｎ＋２，Ｎ＋３として、それぞれdes_info_even（N+2)とdes_info_odd（N+3)が対応シーケンス番号(200, 300)とともに包含される。このように、各周期におけるＳＲＥパケットは、その周期で使用する鍵と次の周期で使用する鍵の２つの鍵が対応シーケンス番号とともに包含される。結果的に、隣列する周期で同じ鍵が重複して送信される。
【０１３２】
（本実施の形態の効果）
ここで、本実施の形態においてＴＳデータを含むＲＴＰパケットとは別に、鍵KEYdesの配信をＳＲＣＰパケット（ＳＲＥパケット、ＳＲＰパケットなどを包括）としての暗号化パケット（鍵切り替えタイミング情報を含む）で行うことの効果（意義、利点）を説明する。この構成によれば、ＲＴＰのペイロードに含まれるＴＳデータのみを暗号化することで、既存のプロトコルであるＲＴＰを有効に利用することができる。すなわち、暗号化が必要となった場合、レート再生や誤り訂正などが含まれた既存資産であるＲＴＰの送受信モジュールはそのまま使用でき、それを拡張する形で暗号化が実現可能となる。なお、鍵KEYdesをＴＳデータに含めることも可能であるが、本実施の形態ではＲＴＰパケットに含めるＴＳパケット全体を暗号化するため、仮にＳＲＥをＴＳデータと同じサイズにして格納しても、暗号化されたＴＳパケットはどのようなデータになるか分からないためＳＲＥの識別が困難になるという問題がある。本実施の形態ではこのような問題は生じない。ＲＴＰを使用せずに独自プロトコルを新たに設計した場合はＴＳデータに鍵データを含めることが可能であるが、別途、独自プロトコルの設計が必要となる。
【０１３３】
また、暗号化パケットとＲＴＰパケットとで両パケットの宛先ポート（送信先ＵＤＰポート番号）を異ならせることの効果（意義、利点）について図１９により説明する。図１９（ａ）（ｂ）はそれぞれポート番号を同一にした場合と異ならせた場合の受信装置４０におけるデータの流れを処理ブロックの連携で示したものである。処理ブロックは、ＥＴＨ（ETHERNET（登録商標））ポート５０１、ＵＤＰ／ＩＰプロトコルスタック５０２、ＴＳ＋暗号化パケット受信処理部５０３、前方誤り訂正受信処理部（行）（ＦＥＣ Ｒ：Forward Error Correction Row）５０４、前方誤り訂正受信処理部（列）（ＦＥＣ Ｃ：Forward Error Correction Column）５０５、ＴＳ受信処理部５０６、暗号化パケット受信処理部５０７を含む。一般に受信装置がＵＤＰデータを待ち受ける際に、ポート番号によりデータの種別を判断して各処理に振り分けるが、ポート番号を同一にした場合、図１９（ａ）に示すように、データ受信後にデータの内容を見て処理を振り分ける必要がある。これに対しポートを別にした場合は、図１９（ｂ）に示すように、ＴＳ＋暗号化パケット受信処理部５０３が不要となり、ＵＤＰのポート番号に基づいて受信処理を振り分けることができる。したがって、ＴＳ受信処理での処理負荷が軽減される。また、比較的に単調で高速な処理が求められるＴＳ受信処理はハードウェア（例えばFPGA: Field-Programmable Gate Array）で実現し、比較的低速で柔軟な処理が求められる暗号化パケット受信処理はソフトウェア（ＣＰＵプログラム処理）で行うなど、処理速度に応じた処理の担当の振り分けが容易になる利点もある。
【０１３４】
（変形例）
以上、本発明の好適な実施の形態について説明したが、上記で言及した以外にも種々の変形、変更を行うことが可能である。
【０１３５】
例えば、本実施形態における「ＲＴＰパケットに含まれるＭＰＥＧ２−ＴＳパケット」に対する暗号化鍵（「KEYdes」）による暗号化」は、既存のＢ−ＣＡＳを使用したMULTI2によるスクランブルの代替手段となるものであるが、それと併用されてもよい。すなわち、本発明はＢ−ＣＡＳの有無にかかわらず適用可能である。
【０１３６】
送信装置１０とＳＭＳ２０の役割は可能であれば、一方が他方の代行をしてもよい。
【０１３７】
１台の送信装置１０から複数のコンテンツに対応した複数のＴＳデータをそれぞれＲＴＰパケットとして送出することも可能である。その場合、鍵KEYpをＴＳデータ毎に変更し、当該コンテンツを視聴可能な受信装置４０にのみ当該鍵KEYpを配布することでコンテンツ単位の視聴可否に関する限定受信を実現することができる。
【符号の説明】
【０１３８】
１０：  送信装置
３０：  通信ネットワーク
４０：  受信装置
５０：  表示装置
６０：  ＴＳパケット
７０：  ＲＴＰパケット（ＩＰパケット）
１０１：  入力部
１０３：  ＴＳ暗号化部
１０５：  ＴＳ／ＩＰ変換部
１０７：  出力部
１１１：  鍵生成部
１１３：  鍵制御部
１１５：  タイミング情報生成部
２１０：  データベース
４０１：  ＩＰ入力部
４０３：  ＩＰ／ＴＳ変換部
４０５：  復号化部
４０７：  ＩＰ出力部
４１１：  タイミング情報解析部
４１３：  鍵制御部
【図１】
2017220886.tif 000003
【図２】
2017220886.tif 000004
【図３】
2017220886.tif 000005
【図４】
2017220886.tif 000006
【図５】
2017220886.tif 000007
【図６】
2017220886.tif 000008
【図７】
2017220886.tif 000009
【図８】
2017220886.tif 000010
【図９】
2017220886.tif 000011
【図１０】
2017220886.tif 000012
【図１１】
2017220886.tif 000013
【図１２】
2017220886.tif 000014
【図１３】
2017220886.tif 000015
【図１４】
2017220886.tif 000016
【図１５】
2017220886.tif 000017
【図１６】
2017220886.tif 000018
【図１７】
2017220886.tif 000019
【図１８】
2017220886.tif 000020
【図１９】
2017220886.tif 000021