JP7760030B2 - デジタルテレビ放送システム、方法 - Google Patents

Description

実施形態は、デジタルテレビ放送システム、方法に関する。

ＢＳデジタル放送、１１０度ＣＳデジタル放送、地上デジタル放送（これらを総称して２Ｋ放送とも称する）や高度広帯域衛星デジタル放送（４Ｋ／８Ｋ放送とも称する）に対応する受信機（以下、単に受信機とも称する）には書き換え可能かつ電源断によっても記憶内容が保持される（すなわち、不揮発性の）記憶媒体であるＮＶＲＡＭ（Ｎｏｎ－Ｖｏｌａｔｉｌｅ Ｍｅｍｏｒｙ）が搭載されている。ＮＶＲＡＭは、２Ｋ放送や４Ｋ／８Ｋ放送で実施されているサービスの一つであるデータ放送で取り扱うデータ（受信機データとも称する）の格納媒体（データ放送用ＮＶＲＡＭとも称する）などとして用いられている。データ放送用ＮＶＲＡＭには放送事業者が作成および送信し、受信機上で実行されるデータ放送コンテンツからアクセス可能であるが、放送事業者ごとにアクセス可能な領域が決められているなど、ある放送事業者がデータ放送用ＮＶＲＡＭに記録したデータを他の放送事業者から秘匿するためのアクセス制御技術が提供されている。

特許第５０２７６３６号公報

ＡＲＩＢ ＴＲ－Ｂ１４ ６．２版 「地上デジタルテレビジョン放送運用規定」 ＡＲＩＢ ＴＲ－Ｂ３９ ２．２版 「高度広帯域衛星デジタル放送運用規定」

しかしながら、受信機の所有者や放送事業者ではない第三者が、データ放送コンテンツからアクセスする以外の方法（例えば、データ放送用ＮＶＲＡＭの実体である半導体メモリに、その読み出し装置を接続して読み出す方法等が考えられる）を用いてデータ放送用ＮＶＲＡＭに記録されたデータを読み出した場合、当該第三者は当該データにより表されている情報を得ることができる。すなわち、情報の機密性は確保されない。不揮発性の記憶媒体であるＮＶＲＡＭに記録されたデータは明示的に消去されない限り保持されるため、例えば、受信機を他人に譲渡した場合や廃棄した場合に第三者に情報が取り出される可能性が考えられる。放送事業者が作成するデータ放送コンテンツ（将来的に作成されるものを含む）によっては、個人情報など、第三者に取り出されれば重大な問題となりうる情報をデータ放送用ＮＶＲＡＭに記録することを鑑みると、第三者にデータを取り出された場合であっても情報の機密性を確保することが必要である。

本発明が解決しようとする課題は、情報の機密性を確保しながら受信機データを記録・収集するためのデジタルテレビ放送システム及び方法を提供することである。

一実施形態によれば、受信機とサーバと送信機とを備えるデジタルテレビ放送システムであって、
前記受信機は、
前記送信機から送られてくる放送信号を受信する受信手段と、
鍵取得命令に基づいて、前記放送信号から又は通信回線を介して前記サーバから暗号化鍵を取得する暗号化鍵取得手段と、
前記放送信号に含まれる書き込み命令に基づいて、前記暗号化鍵を使用して前記受信機にある受信機データを暗号化して暗号化付きデータを生成する暗号化手段と、
前記暗号化付きデータを情報蓄積部に書き込みする情報書き込み手段と、を備え、
前記送信機は、
アプリケーションデータ生成手段を有し、このアプリケーションデータ生成手段は、
前記受信機に前記暗号化鍵を取得させるための前記鍵取得命令と、
前記暗号化鍵を使用して前記暗号化付きデータを生成し、前記暗号化付きデータを前記情報蓄積部に書き込ませるための前記書き込み命令と、
前記受信機の情報読み出し手段が前記情報蓄積部から前記暗号化付きデータを読み出すように命令する読み出し命令と、
読み出した前記暗号化付きデータを前記サーバへ送信するように命令する送信命令と、を生成して前記放送信号に含ませる、前記アプリケーションデータ生成手段である、
デジタルテレビ放送システムが提供される。

図１は、実施形態に係るシステムの構成例を示すブロック図である。 図２は、実施形態に係る放送局の送信機の機能構成例を示すブロック図である。 図３は、実施形態に係る送信機のアプリケーションデータ生成部で記述可能なＡＰＩコマンドの例である。 図４は、実施形態に係る放送局のサーバの機能構成例を示すブロック図である。 図５は、実施形態に係る受信機の機能構成例を示すブロック図である。 図６は、実施形態に係る受信機の情報蓄積部の蓄積データ領域の例を示す図である。 図７は、実施形態に係る受信機のアプリケーション実行部の機能構成例を示すブロック図である。 図８は、第１の実施形態に係るシステムの動作例を示すシーケンスチャートである。 図９は、同実施形態に係る送信機の処理動作の例を示すフローチャートである。 図１０は、同実施形態における受信機の処理動作の例を示すフローチャートである。 図１１は、同実施形態における暗号化鍵取得時のアプリケーション実行部の処理動作の例を示すフローチャートである。 図１２は、同実施形態における暗号化鍵取得時のサーバの処理動作の例を示すフローチャートである。 図１３は、同実施形態におけるデータ書き込み時のアプリケーション実行部の処理動作の例を示すフローチャートである。 図１４は、同実施形態におけるデータ読み出し時のアプリケーション実行部の処理動作の例を示すフローチャートである。 図１５は、同実施形態におけるデータ送信時のアプリケーション実行部の処理動作の例を示すフローチャートである。 図１６は、同実施形態におけるデータ受信時のサーバの処理動作の例を示すフローチャートである。 図１７は、第２の実施形態に係るシステムのシーケンスチャートである。 図１８は、同実施形態に係る送信機の処理動作の例を示すフローチャートである。 図１９は、同実施形態における暗号化鍵取得時のアプリケーション実行部の処理動作の例を示すフローチャートである。 図２０は、第３の実施形態に係るシステムのシーケンスチャートである。 図２１は、同実施形態におけるＴＳ方式の放送波４のＳＩで暗号化鍵を送信する場合の例である。 図２２は、同実施形態におけるＭＭＴ方式の放送波４のＳＩで暗号化鍵を送信する場合の例である。 図２３は、同実施形態における受信機の処理動作の例を示すフローチャートである。 図２４は、同実施形態におけるデータ書き込み時のアプリケーション実行部の処理動作の例を示すフローチャートである。 図２５は、第４の実施形態におけるデータ書き込み時の書込み処理部の処理動作の例を示すフローチャートである。 図２６は、同実施形態におけるデータ書き込み時のアプリケーション実行部の処理動作の例を示すフローチャートである。

以下、実施の形態について図面を参照して説明する。

図１は、実施形態に係るシステムの構成例を示すブロック図である。

放送局１０は、２Ｋ放送または４Ｋ／８Ｋ放送の放送局である。特に２Ｋ放送の放送局と４Ｋ／８Ｋ放送の放送局とを区別する場合は、それぞれ２Ｋ放送局、４Ｋ／８Ｋ放送局と称する。放送局１０は送信機１、サーバ２を含む。

送信機１は、アプリケーションデータ、各種制御情報などを含めたデジタル放送信号を２Ｋ放送や４Ｋ／８Ｋ放送などの放送波に乗せて、アンテナやケーブルなどから放送波を出力する。

サーバ２は、例えばコンピュータであり、外部装置との通信を実施する通信インターフェースや、データの処理を実施するＣＰＵなどを備える。具体的には、サーバ２は、ネットワーク５を介して受信機３と各種データのやり取りをする。また、サーバ２は、ネットワーク６を介して送信機１と各種データのやり取りをする。送信機１はサーバ２から得たデータを放送波４によって送信することができる。なお図１においては、放送局１０、受信機３それぞれ１つしか図示していないが、通常、放送局１０（送信機１、サーバ２）、受信機３ともに複数ある。この場合、各放送局のサーバ２はそれぞれ複数の受信機３とデータのやり取りが可能である。また各放送局の送信機１はそれぞれが個別に放送波４を出力し、各受信機３は複数の送信機１からの放送波４を１つまたは複数受信することができる。

放送波４は、例えば電波であるが、アンテナから出力されてもよいし、ケーブル放送などの有線で伝送されても良い。

ネットワーク５は、例えばインターネットなどの電気通信回線であり、その媒体は無線でも有線でもよい。

ネットワーク６は、放送局内で主に送信機１とサーバとの通信を行うためのインターフェースであり、例えば、インターネットなどの電気通信回線でもよいし、専用線でもよい。その媒体は無線でも有線でもよい。

図２は、実施形態に係る放送局の送信機の機能構成例を示すブロック図である。

送信機１は、例えばサーバ２から得たデジタル放送信号（デジタル放送用のデジタルデータ）、アプリケーションデータ、各種制御情報などから各種デジタル放送の規格に応じた放送ストリーム（デジタルデータストリーム）を生成し、デジタルデータストリームを放送波４によって出力する。各種デジタル放送の規格とは、例えば、２Ｋ放送の送信方式であるＭＰＥＧ２トランスポートストリーム方式（ＴＳ方式）や、４Ｋ／８Ｋ放送の送信方式であるＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ方式（ＭＭＴ方式）でもよい。

サービスデータストリーム生成部１１は、映像、音声、字幕などのサービスデータに対して、各種デジタル放送の規格に応じた情報源符号化を含む符号化やパケット化などにより、符号化したサービスデータのデータストリームを生成する。

制御情報生成部１２は、サービスデータの提示に関する制御情報や、アプリケーションを制御するための制御情報（以降、アプリケーション制御情報と称する）などを生成する。

アプリケーションストリーム生成部１３は、アプリケーションデータに対して、各種デジタル放送の規格に準じた情報源符号化を含む符号化やパケット化などにより、アプリケーションデータのデータストリームを生成する。アプリケーションデータは、各種デジタル放送の規格に準じた方式、例えばデータカルーセル方式やイベントメッセージ方式などに基づいてデータストリーム（アプリケーションストリーム）として生成される。

アプリケーションデータ生成部１４は、受信機３において実行させるアプリケーションのデータを生成する。本実施形態において、アプリケーションデータ生成部１４は、図３に示すＡｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）に対するコマンド（以降、ＡＰＩコマンドと称する）を含めたアプリケーションデータを生成する。ＡＰＩは、受信機３に組み込まれる実行プログラムであるアプリケーションエンジンがアプリケーションに対して提供するインターフェースであり、ＡＲＩＢ ＳＴＤ－Ｂ２４やＡＲＩＢ ＳＴＤ－Ｂ６２などの規格に規定される放送用拡張関数（または放送用拡張オブジェクト）とも称される。本実施形態におけるアプリケーションは、データ放送アプリケーション（４Ｋ／８Ｋ放送の場合）、データ放送コンテンツ（２Ｋ放送の場合）を想定する。具体的には、Ｂｒｏａｄｃａｓｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＢＭＬ）やＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＨＴＭＬ）などで記述されたファイル（それぞれＢＭＬファイル、ＨＴＭＬファイルと称する）が送信され、本実施形態においては、これらのファイルに次のようなＡＰＩを実行するためのＡＰＩコマンドを含む。詳細は図３の説明において述べる。・暗号化に用いる暗号化鍵を取得・格納するＡＰＩ（暗号化鍵取得ＡＰＩ）・データ書き込みＡＰＩ（暗号化付き）・暗号化付きデータ読み出しＡＰＩ（復号なし）・データ送信ＡＰＩなお、本実施形態においてアプリケーションデータ生成部１４は、送信機１の機能とする例を示すが、サーバ２の機能であってもよい。アプリケーションデータ生成部１４をサーバ２の機能とする場合は、アプリケーションデータ生成部１４が生成したアプリケーションデータはネットワーク６を介して送信機１に送信される。

暗号化鍵格納部１５は、サーバ２が生成する非対称暗号の暗号化鍵を格納し、アプリケーションデータ生成部１４に出力する。

放送ストリーム生成部１６は、例えばマルチプレクサを含み、サービスデータストリーム生成部１１、制御情報生成部１２、アプリケーションストリーム生成部１３が出力するデータストリームを各種デジタル放送の規格に応じて多重し、放送ストリームとして出力する。

放送信号送信部１７は、放送ストリームのデジタルデータに対して、各種デジタル放送の規格に応じた伝送路符号化を含む符号化や変調などを実施し、放送波４を生成し、図示せぬアンテナ、ケーブルなどへ出力する。

通信部１８は、サーバ２と通信するための機能であり、例えばネットワーク６を介する場合は、ネットワーク６に適用されている通信プロトコル（ＩＰ通信方式、専用線の方式など）を実装している。

図３は、実施形態に係る送信機のアプリケーションデータ生成部１４で記述可能なＡＰＩコマンドの例であり、列ごとに左からＡＰＩのＮｏ．（図３における番号）、ＡＰＩ機能、ＡＰＩ機能に対するＡＰＩコマンド（ＡＰＩ名、引数など）をＢＭＬまたはＨＴＭＬに記述する場合について示す。ここで、ＡＰＩは受信機３に組み込まれる実行プログラムであるアプリケーションエンジンがアプリケーションに対して提供するインターフェースであり、送信機１がＢＭＬファイルやＨＴＭＬファイルに記述するのは、本図が示すＡＰＩコマンド（ＡＰＩ名やＡＰＩへの引数など）である。

Ｎｏ．１の行は、暗号化鍵取得ＡＰＩを実行させるＡＰＩコマンドであり、受信機３にサーバ２から暗号化に用いる暗号化鍵を取得させるＡＰＩコマンドである。

ＢＭＬの場合、例えば、ＡＲＩＢ ＳＴＤ－Ｂ２４に規定されるｂｒｏｗｓｅｒ疑似オブジェクトのメソッドとして定義するＡＰＩであるｄｏｗｎｌｏａｄＢｒｏａｄｃａｓｔｅｒＣｅｒｔｉｆｉｃａｔｅを呼び出すＡＰＩコマンドである。ＡＰＩコマンドは、例えばｄｏｗｎｌｏａｄＢｒｏａｄｃａｓｔｅｒＣｅｒｔｉｆｉｃａｔｅ（引数）とする。本実施形態においては、引数には、少なくともサーバ２から取得する暗号化鍵を識別する情報（例えば、“ｈｔｔｐｓ：／／サーバ２のアドレス／暗号化鍵ファイルのパス”というＵＲＬ）を含むが、受信機３に取得させる他の内容（例えば、暗号化鍵の属性を示す識別情報など）を含めてもよい。

ＨＴＭＬの場合、例えば、ＡＲＩＢ ＳＴＤ－Ｂ６２に規定されるＲｅｃｅｉｖｅｒＤｅｖｉｃｅオブジェクトのメソッドとして定義するＡＰＩであるｄｏｗｎｌｏａｄＢｒｏａｄｃａｓｔｅｒＣｅｒｔｉｆｉｃａｔｅを呼び出すＡＰＩコマンドである。ＡＰＩコマンドは、例えばｄｏｗｎｌｏａｄＢｒｏａｄｃａｓｔｅｒＣｅｒｔｉｆｉｃａｔｅ（引数）とする。本実施形態においては、引数には、少なくともサーバ２から取得する暗号化鍵を識別する情報（例えば、“ｈｔｔｐｓ：／／サーバ２のアドレス／暗号化鍵ファイルのパス”というＵＲＬ）を含むが、受信機３に取得させる他の内容（例えば、暗号化鍵の属性を示す識別情報など）を含めてもよい。

Ｎｏ．１のＡＰＩコマンドによって受信機３が取得する暗号化鍵の信頼性は、ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ｓｅｃｕｒｅ（ｈｔｔｐｓ）コネクションの信頼性により担保することでもよい。Ｎｏ．１のＡＰＩを用いる場合、受信機３は、まず放送局サーバ２とｈｔｔｐｓを用いてコネクションを確立し、そのｈｔｔｐｓコネクションでの通信により暗号化鍵を放送局サーバ２から取得する。ｈｔｔｐｓコネクションによって受信機３からみてサーバ２は認証されており、取得した暗号化鍵の信頼性が確保される。

Ｎｏ．２の行は、暗号化鍵取得ＡＰＩを実行させるＡＰＩコマンドであり、放送中のアプリケーションストリーム内にて送信されている暗号化鍵を受信機３に取得させるＡＰＩコマンドである。

ＢＭＬの場合、例えば、ＡＲＩＢ ＳＴＤ－Ｂ２４に規定されるｂｒｏｗｓｅｒ疑似オブジェクトのメソッドとして定義するＡＰＩであるｄｏｗｎｌｏａｄＢｒｏａｄｃａｓｔｅｒＣｅｒｔｉｆｉｃａｔｅを呼び出すＡＰＩコマンドである。ＡＰＩコマンドは、例えばｄｏｗｎｌｏａｄＢｒｏａｄｃａｓｔｅｒＣｅｒｔｉｆｉｃａｔｅ（引数）とする。本実施形態においては、引数には、少なくとも放送データ（放送信号）中の暗号化鍵の格納場所を識別する情報（例えば、“ａｒｉｂ－ｄｃ：／／暗号化鍵のリソース名”というＵＲＬ）を含むが、受信機３に取得させる他の内容（例えば、暗号化鍵の属性を示す識別情報など）を含めてもよい。

ＨＴＭＬの場合、例えば、ＡＲＩＢ ＳＴＤ－Ｂ６２に規定されるＲｅｃｅｉｖｅｒＤｅｖｉｃｅオブジェクトのメソッドとして定義するＡＰＩであるｄｏｗｎｌｏａｄＢｒｏａｄｃａｓｔｅｒＣｅｒｔｉｆｉｃａｔｅを呼び出すＡＰＩコマンドである。ＡＰＩコマンドは、例えばｄｏｗｎｌｏａｄＢｒｏａｄｃａｓｔｅｒＣｅｒｔｉｆｉｃａｔｅ（引数）とする。本実施形態においては、引数には、少なくとも放送データ（放送信号）中の暗号化鍵の格納場所を識別する情報（例えば、“ａｒｉｂ－ｄｃ２：／／暗号化鍵のリソース名”というＵＲＬ）を含むが、受信機３に取得させる他の内容（例えば、暗号化鍵の属性を示す識別情報など）を含めてもよい。

Ｎｏ．３の行は、データ書き込みＡＰＩを実行させるＡＰＩコマンドであり、受信機３に、受信機データを暗号化させ、暗号化したデータ（以降、暗号化付きデータと称する）を受信機３の情報蓄積部３６（データ放送用ＮＶＲＡＭ）に書き込ませるＡＰＩコマンドである。

ＢＭＬの場合、例えば、ＡＲＩＢ ＳＴＤ－Ｂ２４に規定されたＡＰＩであるｗｒｉｔｅＰｅｒｓｉｓｔｅｎｔＡｒｒａｙを呼び出すＡＰＩコマンドである。ＡＰＩコマンドは、例えばｗｒｉｔｅＰｅｒｓｉｓｔｅｎｔＡｒｒａｙ（引数）である。ＡＰＩコマンドの引数には、少なくとも、受信機３に暗号化付きデータとして書込みさせる受信機データを識別する情報（受信機データ識別情報）と、前記データを暗号化付きデータとして書き込むことを受信機３に指示する情報（暗号化書込み指示情報）と、前記暗号化付きデータを書き込む格納場所を識別する情報（格納場所識別情報）とを含む。例えば、受信機データ識別情報は、ＡＲＩＢ ＴＲ－Ｂ１４で規定される通りとしてもよい。また受信機データ識別情報と、格納場所識別情報については、ＡＲＩＢ ＴＲ－Ｂ１４で規定されるデータ放送用ＮＶＲＡＭ内の格納場所を識別する情報の一形態である“ｎｖｒａｍ：／／～／＜ブロック番号＞”というＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）に代えて、“ｎｖｒａｍｅ：／／～／＜ブロック番号＞”というＵＲＩを用いてもよい。ここで、～や＜ブロック番号＞の意味は、ＡＲＩＢ ＴＲ－Ｂ１４の規定に準じた値とする。

ＨＴＭＬの場合、例えば、ＡＲＩＢ ＴＲ－Ｂ３９にその運用が規定されるＬｏｃａｌＳｔｏｒａｇｅオブジェクトのメソッドを用いたＡＰＩであるｓｅｔＩｔｅｍを呼び出すＡＰＩコマンドである。ＡＰＩコマンドは、例えばｓｅｔＩｔｅｍ（引数）とする。ＡＰＩコマンドの引数には、少なくとも、受信機データ識別情報と、暗号化書込み指示情報と、格納場所識別情報とを含む。例えば、受信機データ識別情報は、ＡＲＩＢ ＴＲ－Ｂ３９で規定される通りとしてもよい。また暗号化書込み指示情報と、格納場所識別情報とについては、例えば、ＡＲＩＢ ＴＲ－Ｂ３９で規定されるアクセスキー名、例えば「“＿ｗｌｏｃａｌ”＋アイテム番号」に代えて、「“＿ｅ＿ｗｌｏｃａｌ“＋アイテム番号」、例えば”＿ｅ＿ｗｌｏｃａｌ０“を用いてもよい。

Ｎｏ．４の行は、データ書き込みＡＰＩを実行させるＡＰＩコマンドであり、受信機３に、受信機データを暗号化させ、暗号化したデータ（以降、暗号化付きデータと称する）を受信機３の情報蓄積部３６（データ放送用ＮＶＲＡＭ）に書き込ませるＡＰＩコマンドである。

ＢＭＬの場合、例えば、ＡＲＩＢ ＳＴＤ－Ｂ２４に規定されたｗｒｉｔｅＰｅｒｓｉｓｔｅｎｔＡｒｒａｙに準じたＡＰＩであるｗｒｉｔｅＰｅｒｓｉｓｔｅｎｔＡｒｒａｙＥｎｃｒｙｐｔｅｄを呼び出すＡＰＩコマンドである。ＡＰＩコマンドは、例えばｗｒｉｔｅＰｅｒｓｉｓｔｅｎｔＡｒｒａｙＥｎｃｒｙｐｔｅｄ（引数）とする。ＡＰＩコマンドの引数には、少なくとも、受信機データ識別情報と、格納場所識別情報とを含む。例えば、前記Ｎｏ．３の行のＢＭＬの場合のＡＰＩコマンドにおける引数の実施形態に準じた引数としてもよいし、ＡＲＩＢ ＴＲ－Ｂ１４で規定されるｗｒｉｔｅＰｅｒｓｉｓｔｅｎｔＡｒｒａｙの引数に準じた引数としてもよい。後者の場合、受信機３は、ＡＰＩ名に含まれる「Ｅｎｃｒｙｐｔｅｄ」からＮＶＲＡＭに書き込むデータを暗号化させる必要があることを認識し、引数に指定された書込みデータを暗号化した上で、ＮＶＲＡＭに格納することでもよい。

ＨＴＭＬの場合、例えば、ＡＲＩＢ ＴＲ－Ｂ３９にその運用が規定されるＬｏｃａｌＳｔｏｒａｇｅオブジェクトのメソッドに準じたＡＰＩであるｓｅｔＩｔｅｍＥｎｃｒｙｐｔｅｄを呼び出すＡＰＩコマンドである。ＡＰＩコマンドは、例えばｓｅｔＩｔｅｍＥｎｃｒｙｐｔｅｄ（引数）とする。ＡＰＩコマンドの引数には、少なくとも、受信機３に暗号化付きデータとして書き込みさせる受信機データ識別情報と、格納場所識別情報とを含む。例えば、前記Ｎｏ．３の行のＨＴＭＬの場合のＡＰＩコマンドにおける引数の実施形態に準じた引数としてもよいし、ＡＲＩＢ ＴＲ－Ｂ３９で規定されるｓｅｔＩｔｅｍの引数に準じた引数としてもよい。後者の場合、受信機３は、Ｎｏ．４のＡＰＩが呼び出された場合、ＡＰＩ名に含まれる「Ｅｎｃｒｙｐｔｅｄ」からＮＶＲＡＭに書き込むデータを暗号化させる必要があることを認識し、引数に指定された書込みデータを暗号化した上で、ＮＶＲＡＭに格納することでもよい。本実施形態において、受信機３が、Ｎｏ．１やＮｏ．２のＡＰＩで取得した暗号化鍵を用いて、Ｎｏ．３とＮｏ．４のＡＰＩで暗号化付きの書き込みを実施する例を示す。

Ｎｏ．３とＮｏ．４のＡＰＩコマンドにより暗号化付きデータを書き込むＮＶＲＡＭの領域は、ＡＲＩＢ ＴＲ－Ｂ１４やＡＲＩＢ ＴＲ－Ｂ３９で規定されているＮＶＲＡＭの領域とは別の領域としても良いし、同じ領域としても良い。例えば、Ｎｏ．３のＢＭＬのＡＰＩコマンドにおいて、暗号化付きデータを書き込む格納場所を指示するＵＲＬ“ｎｖｒａｍｅ：／／～／０”が表す領域は、ＡＲＩＢ ＴＲ－Ｂ１４の規定するＵＲＬ“ｎｖｒａｍ：／／～／０”が表す領域とは別の領域であってもよいし、同じ領域であってもよい。Ｎｏ．３のＨＴＭＬのＡＰＩコマンドにおいてアクセスキーが表す領域についても同様である。さらに、例えばＮｏ．３とＮｏ．４のＢＭＬのＡＰＩコマンド、すなわちｗｒｉｔｅＰｅｒｓｉｓｔｅｎｔＡｒｒａｙ（引数）とｗｒｉｔｅＰｅｒｓｉｓｔｅｎｔＡｒｒａｙＥｎｃｒｙｐｔｅｄ（引数）において、例えばＵＲＬ“ｎｖｒａｍ：／／～／０”を指示したとき、前者のＮｏ．３のＡＰＩコマンドによってＡＰＩが呼び出されたときに受信機３がデータを書き込む領域と、後者のＮｏ．４のＡＰＩコマンドによってＡＰＩが呼び出されたときに受信機３が暗号化付きデータを書き込む領域は、別々の領域であってもよいし、同じ領域であってもよい。Ｎｏ．４のＨＴＭＬのＡＰＩコマンドにおいても同様である。

Ｎｏ．５の行は、暗号化付きデータ読み出しＡＰＩを実行させるＡＰＩコマンドであり、受信機３に暗号化付きデータを情報蓄積部３６から読出しをさせるＡＰＩコマンドである。

ＢＭＬの場合、例えば、ＡＲＩＢ ＳＴＤ－Ｂ２４に規定されたＡＰＩであるＲｅａｄＰｅｒｓｉｓｔｅｎｔＡｒｒａｙを呼び出すＡＰＩコマンドである。ＡＰＩコマンドは、例えばＲｅａｄＰｅｒｓｉｓｔｅｎｔＡｒｒａｙ（引数）である。ＡＰＩコマンドの引数には、少なくとも、受信機３に読み出しをさせる暗号化付きデータの格納場所を識別する情報（格納場所識別情報、例えば、ｎｖｒａｍｅ：／／～／＜ブロック番号＞）を含む。ただし、～や＜ブロック番号＞は、上記のＮｏ．３の場合と同様である。

ＨＴＭＬの場合、例えば、ＡＲＩＢ ＴＲ－Ｂ３９にその運用が規定されるＬｏｃａｌＳｔｏｒａｇｅオブジェクトのメソッドとして定義するＡＰＩであるｇｅｔＩｔｅｍを呼び出すＡＰＩコマンドである。ＡＰＩコマンドは、例えばｇｅｔＩｔｅｍ（引数）とする。ＡＰＩコマンドの引数には、受信機３に読み出しをさせる暗号化付きデータの格納場所を識別する情報（格納場所識別情報、例えば、”＿ｅ＿ｗｌｏｃａｌ“＋アイテム番号）を含む。アイテム番号は、上記のＮｏ．３の場合と同様である。

Ｎｏ．６の行は、暗号化付きデータ読み出しＡＰＩを実行させるＡＰＩコマンドであり、受信機３に暗号化付きデータを情報蓄積部３６から読出させるＡＰＩコマンドである。

ＢＭＬの場合、例えば、ＡＲＩＢ ＳＴＤ－Ｂ２４に規定されたＲｅａｄＰｅｒｓｉｓｔｅｎｔＡｒｒａｙに準じたＡＰＩであるＲｅａｄＰｅｒｓｉｓｔｅｎｔＡｒｒａｙＥｎｃｒｙｐｔｅｄを呼び出すＡＰＩコマンドである。ＡＰＩコマンドは、例えばＲｅａｄＰｅｒｓｉｓｔｅｎｔＡｒｒａｙＥｎｃｒｙｐｔｅｄ（引数）とする。ＡＰＩコマンドの引数には、少なくとも、受信機３に読み出しをさせる暗号化付きデータの格納場所識別情報を含む。読み出しさせる暗号化付きデータの格納場所識別情報として、例えば、ＡＲＩＢ
ＴＲ－Ｂ１４に規定されるデータ放送用ＮＶＲＡＭ内の格納場所を識別する情報の一形態である“ｎｖｒａｍ：／／～／＜ブロック番号＞”というＵＲＩを指定しても良い。このとき、同じブロック番号であっても暗号化付きデータと暗号化なし受信機データとが別の領域に格納される実施形態の場合には、受信機３は、Ｎｏ．６のＡＰＩコマンドを受信した場合、ＡＰＩ名に含まれる「Ｅｎｃｒｙｐｔｅｄ」から暗号化付きデータを格納する領域から読み出すことを認識し、暗号化付きデータをＮＶＲＡＭから読み出すことでもよい。

ＨＴＭＬの場合、例えば、ＡＲＩＢ ＴＲ－Ｂ３９にその運用が規定されるＬｏｃａｌＳｔｏｒａｇｅオブジェクトに準じたＡＰＩであるｇｅｔＩｔｅｍＥｎｃｒｙｐｔｅｄを呼び出すＡＰＩコマンドである。ＡＰＩコマンドは、例えばｇｅｔＩｔｅｍＥｎｃｒｙｐｔｅｄ（引数）とする。ＡＰＩコマンドの引数には、少なくとも、受信機３に読出させる暗号化付きデータの格納場所を識別する情報を含む。読み出しさせる暗号化付きデータの格納場所を識別する情報として、例えば、ＡＲＩＢ ＴＲ－Ｂ３９で規定されるアクセスキー名を指定してもよい。このとき、同じブロック番号であっても暗号化付きデータと暗号化なし受信機データとが別の領域に格納される実施形態の場合には、受信機３は、Ｎｏ．６のＡＰＩコマンドを受信した場合、ＡＰＩ名に含まれる「Ｅｎｃｒｙｐｔｅｄ」から暗号化付きデータを格納する領域から読み出すことを認識し、暗号化付きデータをＮＶＲＡＭから読み出すことでもよい。

Ｎｏ．７の行は、データ送信ＡＰＩを実行させるＡＰＩコマンドであり、受信機３に暗号化付きデータを放送局のサーバ２へ送信させるＡＰＩコマンドである。

ＢＭＬの場合、例えば、ＡＲＩＢ ＳＴＤ－Ｂ２４に規定されたＡＰＩであるｔｒａｎｓｍｉｔＴｅｘｔＤａｔａＯｖｅｒＩＰを呼び出すＡＰＩコマンドである。ＡＰＩコマンドは、例えばｔｒａｎｓｍｉｔＴｅｘｔＤａｔａＯｖｅｒＩＰ（引数）である。本実施形態においては、ＡＰＩコマンドの引数には、Ｎｏ．４またはＮｏ．５のＡＰＩコマンドを用いて読み出した暗号化付きデータと、送信先を識別する情報を含む。本実施形態において、前記暗号化付きデータはテキストデータであってもよい。なお一般に暗号化付きデータはバイナリデータでありテキストデータではないので、例えば、Ｂａｓｅ６４符号化により暗号化付きデータを可逆的にテキストデータへ変換したデータを引数としてもよい。また前記送信先を識別する情報は、例えば、サーバ２のＵＲＬ“ｈｔｔｐｓ：／／サーバ２のアドレス”でありさらにパラメータとして「？ｄａｔａｔｙｐｅ＝ｎｖｒａｍ＆ｅｎｃｒｙｐｔｅｄ＝ｙｅｓ」を付加したＵＲＬである。この情報は、本ＡＰＩコマンドを受信した受信機３に、暗号化付きのデータを放送局のサーバ２へ送信させることを示す。より具体的には、受信機３は暗号化データを送信するためにサーバ２に対して接続要求をする。接続要求時には上記のパラメータを送信する。受信機３から送信のための接続を受けたサーバ２は、受信したパラメータにより、受信機３が暗号化付きデータを送信しようとしていることを確認する。

ＨＴＭＬの場合、標準機能である通信手段を用いてサーバ２との通信を実行可能である。本実施形態では、例えば、ＪａｖａＳｃｒｉｐｔのＸＭＬＨｔｔｐＲｅｑｕｅｓｔオブジェクトを用いて、サーバ２へ暗号化付きデータを送信する。この場合、ＡＰＩコマンドは、例えばＸＭＬＨｔｔｐＲｅｑｕｅｓｔ．ｏｐｅｎ（引数）とＸＭＬＨｔｔｐＲｅｑｕｅｓｔ．ｓｅｎｄ（引数）とを含めても良い（前者の引数は暗号化付きデータを送信する送信先を識別する情報であり、後者の引数は送信する暗号化付きデータである）。これらの実施形態は、前記ＢＭＬのｔｒａｎｓｍｉｔＴｅｘｔＯｖｅｒＩＰにおける実施形態と同じとしてもよい。Ｎｏ．７のＡＰＩコマンドにより、受信機３は、情報蓄積部３６（データ放送用ＮＶＲＡＭ）から読み出した暗号化付きデータをそのまま、すなわち暗号化を復号せずに指定された放送局のサーバ２に送信する。

なお、本実施形態においては、受信機３のＡＰＩへの命令であるＡＰＩコマンドを、デジタルテレビのデータ放送サービスで放送するアプリケーションデータに含める例を示すが、これに限られない。例えば、ＡＰＩ機能の命令をＴＳ方式のＳｉｇｎａｌｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ（ＳＩ）信号などに含めることでもよい。

図４は、実施形態に係る放送局のサーバの機能構成例を示すブロック図である。

放送局のサーバ２は、例えばコンピュータであり、外部装置との通信を実施する通信インターフェースや、データの処理を実施するＣＰＵなどを備える。具体的には、放送局のサーバ２は、ネットワーク５を介して受信機３と各種データのやり取りをする。また、サーバ２は、ネットワーク６を介して送信機１と各種データのやり取りをする。

通信部２１は、サーバ２がネットワーク５やネットワーク６を介して通信をするための通信インターフェースを含み、ネットワーク５、ネットワーク６に適用されている通信プロトコル（ＩＰ通信方式、専用線の方式など）をそれぞれ実装している。

アプリケーションデータ処理部２２は、受信機３や送信機２と、ｈｔｔｐｓ通信によりアプリケーションレベルのデータをやり取りし、処理をする。例えば、アプリケーションデータ処理部２２は、受信機３からのアプリケーションデータ（ここではＢＭＬファイル、ＨＴＭＬファイルとは限らない）を解析し、必要に応じてサーバ２内の機能に処理命令をする。

暗号化鍵要求処理部２３は、受信した受信機３からの暗号化鍵要求に応じて、サーバ２内に格納された暗号化鍵をアプリケーションデータ処理部２２へ出力する。出力された暗号化鍵は、通信部２１などを介して受信機３へ送信される。

鍵格納部２４は、例えば不揮発性メモリであり、暗号化鍵や暗号化復号鍵が格納されている。ただし、暗号化鍵と暗号化復号鍵はそれらの秘匿の重要性の違いを考慮して物理的に異なるメモリに格納することでもよい。

鍵生成部２５は、暗号化鍵や暗号復号化鍵を生成し、鍵格納部２４に格納する。本実施形態においては非対称鍵暗号技術を適用し、暗号化鍵を公開鍵とし、暗号復号化鍵を秘密鍵とする。鍵生成部２５は、公開鍵と秘密鍵とを１対１の組み合わせで生成する。秘密鍵は生成者が秘密に所持し、公開鍵は秘密にする必要はなく第三者に公開されてもよい。非対称鍵暗号技術また公開鍵および秘密鍵の生成方法については一般的な技術であるため説明は省略する。

復号処理部２６は、受信機３から受信した暗号化付きデータを暗号化復号鍵で復号し、受信機データを得て、出力する。具体的には、復号処理部２６は、アプリケーションデータ処理部２２から暗号化鍵で暗号化された受信機データである暗号化付きデータを受信する。復号処理部２６は、暗号化付きデータを暗号化復号鍵によって復号し、受信機データを得る。非対称鍵暗号技術による暗号化復号鍵（秘密鍵）を用いた復号方法については一般的な技術であるため説明は省略する。なお、本実施形態においては、サーバ２が暗号化鍵と暗号化復号鍵を持つ例を示すが、暗号化鍵と暗号化復号鍵を持つサーバが異なっていてもよい。その場合は、暗号化復号鍵を持つサーバが、暗号化復号鍵を用いた処理をする機能を備える。なお、本実施形態においては、サーバ２が暗号化鍵と暗号化復号鍵を持つ例を示すが、暗号化鍵と暗号化復号鍵を持つサーバが異なっていてもよい。その場合は、暗号化復号鍵を持つサーバが、暗号化復号鍵を用いた処理をする機能を備える。

受信機データ格納部２７は、復号処理部２６から出力される受信機データを格納する。受信機データは、受信機３が所有する受信機３に関する設置場所情報、所有者情報、視聴データ、視聴行動データなどの任意のデータであり、例えば、視聴データや視聴行動データは視聴分析などの解析データとして用いられる。

図５は、実施形態に係る受信機の機能構成例を示すブロック図である。

受信機３は、例えばデジタルテレビの受信機であり、２Ｋ放送、４Ｋ／８Ｋ放送を含むデジタル放送の受信機能を備える。また受信機３は、ネットワーク５を介してサーバ２や図示せぬ外部サーバとデータのやり取りをするための通信インターフェースを備える。さらに受信機３は、デジタル放送から得たデータとサーバから得たデータとを連携させて各種放送通信連携サービスを実現するための機能を備える。また、受信機３は、受信機３によって視聴されたデジタル放送の番組の視聴履歴など視聴行動データや、例えば受信機３の所有者に関する情報を取得し、保存することができる。これらを含めて受信機３が保存可能なデータを受信機データと称する。受信機３は、受信機データの全てもしくは一部を、情報蓄積部３６（データ放送用ＮＶＲＡＭ）に記憶することができる。受信機３は、例えばネットワーク５を介してサーバ２に受信機データを送信することができる。サーバ２は受信した受信機データを解析するなどして利用する。本実施形態においては、受信機データを暗号化した上で暗号化付きデータとして情報蓄積部３６に記憶し、情報蓄積部３６から暗号化付きデータを読み出してサーバ２へ送信する。また、受信機３は、上記の機能を実現するためのＣＰＵなどの演算処理機能を備える。

放送チューナ３１は、放送波４をアンテナやケーブルなどから受波し、各種デジタル放送の規格に応じた送信機１の伝送路符号化や変調方式などに対応する復号、復調などを放送波４に対して実施し、放送ストリームのデジタルデータを取得し、出力する。

放送ストリーム処理部３２は、放送チューナ３１から入力される放送ストリームに対して、各種デジタル放送の規格に応じた、例えばデマルチプレクサ（データ分離）、情報源符号化復号化などを実施して、サービスデータ、データ放送サービスデータ、アプリケーションデータ、各種制御情報などを取得し、出力する。

制御部３３は、受信機３の全体の制御を実施する。例えば制御部３３は、放送ストリーム処理部３２から各種制御情報などを取得し、取得した各種制御情報などに基づいて受信機３の各種機能を制御する。また制御部３３は、リモコン部３０３やインターフェース部３０２を介して、ユーザからの各種制御命令を受信し、各種制御命令に基づいて受信機３の各種機能を制御することでもよい。

アプリケーションデータ格納部３４は、例えばメモリであり、放送ストリーム処理部３２が出力するアプリケーションデータを格納する。具体的には、放送チューナ３１が放送信号の受信を開始してから、受信機３（具体的にはアプリケーション実行部３５）がアプリケーションを実行するまでに受信したアプリケーションデータを格納しておくキャッシュ、バッファとして用いてもよい。

アプリケーション実行部３５は、例えばＢＭＬブラウザ、ＨＴＭＬブラウザなどアプリケーションエンジンの機能を含む。図７の説明において詳述する。

情報蓄積部３６は、例えば不揮発性の記憶媒体であるＮＶＲＡＭ（Ｎｏｎ－Ｖｏｌａｔｉｌｅ Ｍｅｍｏｒｙ）である。情報蓄積部３６は、２Ｋ放送や４Ｋ／８Ｋ放送で実施されているサービスの一つであるデータ放送で取り扱うデータ（受信機データとも称する）の格納媒体（データ放送用ＮＶＲＡＭとも称する）であってもよい。情報蓄積部３６は、論理アドレス中の識別子であるｎｖｒａｍｅ、ｎｖｒａｍによって、記憶されるデータが暗号化付きであるか否かが区別されてもよい。

本実施形態においては、情報蓄積部３６（ＮＶＲＡＭ）に暗号化付きデータが格納され、また格納されているデータが暗号化付きデータであるか非暗号化データであるかを判別可能である。

図６は、実施形態に係る受信機の情報蓄積部の蓄積データ領域の例を示す図である。本図は情報蓄積部３６に蓄積されているデータの説明を目的として、データの内容に基づいて、論理的に区別して示したものであり、情報蓄積部３６における物理的な関係を示すものとは限らない。従って、図に示される内容が必ずしも全て情報蓄積部３６に蓄積されているとは限らない。

図６（ａ）は、放送事業者に割り当てられたＮＶＲＡＭ上の記憶領域の一例を示している。ＮＶＲＡＭは大きく、放送事業者ごとの領域や放送事業者共用の領域に分けられ、さらに各放送事業者の領域や放送事業者共用の領域は、ブロック（またはアイテム）という小領域に分けられる。

領域３６０１に示すアドレス“ｎｖｒａｍ：／／ｂ＿ｉｄ”は、情報蓄積部３６（ＮＶＲＡＭ）上の記憶領域の場所を示している。ｂ＿ｉｄは、具体的には、放送事業者のブロードキャスタ識別子の値であり、当該ブロードキャスタ識別子を割り当てられた放送事業者が送信するアプリケーションにおいては、記号～によっても表すことができる。ここで領域３６０１自体は、ＮＶＲＡＭ上になくてもよく、図示せぬ別のメモリ上にて、ＮＶＲＡＭの格納場所と放送事業者とを紐づける対応表などを格納し、受信機３がＮＶＲＡＭにアクセスする際には、その対応表を参照することでもよい。

本実施例では、ブロック（またはアイテム）に「氏名」「住所」や「メールアドレス」を格納している。なお、「氏名」「住所」「メールアドレス」といった情報の種類を「情報要素名」として図示しているが、データとして格納しているものではない。すなわち「情報要素名」は、図６の説明のために便宜上示したものであり、具体的なデータとして情報蓄積部３６に格納されていなくてもよい。また、各ブロックをフィールド１、フィールド２に分割し、それぞれに「データ本体」、「登録日時」を書き込む形態をとっている。

領域３６０２は、フィールド１でありデータ本体が格納される。例えばブロック０のフィールド１には、「氏名」が格納される。

領域３６０３は、フィールド２であり、フィールド１に格納するデータ本体に対する「登録日時」が格納される。例えばブロック０においては、「氏名」をブロック０に書き込んだ（登録した）日時が格納される。

領域３６０４は、情報蓄積部３６上の記憶領域であるブロック１のデータを示す。ブロック１に格納される情報要素は「住所」である。より詳細には、ブロック１のフィールド１にはデータ本体として具体的な「住所」が格納され、フィールド２には「住所」の登録された「登録日時」が格納される。

領域３６０５は、情報蓄積部３６上の記憶領域であるブロックＮのデータを示す。ブロックＮに格納される情報要素は「視聴行動データ」であり、より詳細には、領域３６０４と同様であるので省略する。

図６（ｂ）は、情報蓄積部３６の記憶領域に格納されるデータの一例を示している。図６（ａ）との違いは、領域３６０６に示すアドレスである。領域３６０６に示すアドレスｎｖｒａｍｅ：／／ｂ＿ｉｄは、図６（ａ）と同じブロードキャスタ識別子ｂ＿ｉｄで識別される放送事業者に割り当てられた領域であるが、暗号化付きデータを記憶する情報蓄積部３６上の領域であることを示す。図６（ｂ）におけるフィールド１の「データ本体」は、全て暗号化されているデータ（暗号化付きデータ）である。

図６（ｃ）は、情報蓄積部３６の記憶領域に格納されるデータの一例を示している。図６（ａ）との違いは、領域３６０７である。図６（ｃ）においては、フィールド３「暗号化有無」を追加している。図６（ｂ）の場合は、領域３６０６に示すアドレスにより、情報蓄積部３６に格納されているデータが暗号化付きであることを判断可能としているが、図６（ｃ）の場合は、フィールド３によりデータが暗号化付きであるかどうかを判断できる。

図５に戻り、受信機データ格納部３７には、受信機３が取得した視聴行動データや、受信機３の所有者に関する受信機固有の情報などの受信機データが格納される。受信機データ格納部３７は、例えば、アプリケーション実行部３５が用いるワークメモリの一部としてもよい。前記ワークメモリは、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などでもよい。

通信部３８は、受信機３がネットワーク５を介して通信をするための通信インターフェースを含み、ネットワーク５に適用されている通信プロトコル（ＩＰ通信方式、専用線の方式など）を実装している。

提示制御部３９は、サービスデータ、データ放送サービスデータ、アプリケーションデータなどを提示部３０１に表示もしくは音声出力するために各データの出力タイミング、各データの加工などの調整を実施した上でデータ（提示データと称する）を提示部３０１に出力する。

提示部３０１は、例えばモニタ、スピーカであり、提示データを、映像データや画像データとて表示したり音声としてスピーカから出力したりする。

インターフェース部３０２は、受信機３とユーザとのユーザーインターフェースであり、例えば受信機３の付属のリモートコントローラ（リモコン）とのインターフェースであるＩＲ通信、ＰＣ用のマウス、キーボードなどとのインターフェースであるＵＳＢなどを含んでもよい。なお、インターフェース部３０２と結線されていない受信機３内の機能ブロックとデータ、信号などのやり取りをする場合もある。

リモコン部３０３は、例えば受信機３の付属のリモコンである。例えばユーザがリモコン部３０３を操作するとリモコン部３０３が制御データを出力する。出力された制御データを制御部３３がインターフェース部３０２を介して受信し、制御部３３が受信機３内の機能を制御することで、ユーザは受信機３の制御が可能である。

図７は、実施形態に係る受信機のアプリケーション実行部の機能構成例を示すブロック図である。

データ解析部３５０は、アプリケーションデータを解析するなどの機能を有する。アプリケーションデータは、例えばＢＭＬやＨＴＭＬで記述されたデータでもよい。データ解析部３５０は、アプリケーションデータからＡＰＩコマンドを抽出し、ＡＰＩ処理部３５１に出力する。

ＡＰＩ処理部３５１は、データ解析部３５０から入力された各種ＡＰＩコマンドを解釈し、解釈結果またはＡＰＩコマンドそのものを関連する機能に出力する。具体的には、ＡＰＩ処理部３５１は、データ解析部３５０から入力されたＡＰＩコマンド（ＡＰＩ名および付随する引数など）に基づいて、関連機能にＡＰＩの処理を実行させる。

読出し処理部３５２は、ＡＰＩ処理部３５１から暗号化付きデータの読み出しに関する実行命令を受信し、命令に従って処理を実行する。具体的には、読出し処理部３５２は、処理を実行することにより、情報蓄積部３６（ＮＶＲＡＭ）から暗号化付きデータを読み出し、例えば、通信処理部３５９に出力する。

暗号化判定部３５３は、ＡＰＩ処理部３５１からＡＰＩコマンドを受信し、ＡＰＩコマンドが暗号化付きデータに関わるものであるかどうかを判定する。具体的には、図３のＮｏ．４、Ｎｏ．６のＡＰＩのようにＡＰＩ名に「ｅｎｃｒｙｐｔｅｄ」などが含まれる場合や、図３のＮｏ．３、Ｎｏ．５のＡＰＩのように引数によってそれが示される場合（例えば、格納先識別情報として“ｎｖｒａｍｅ：／／～／＜ブロック番号＞”が指示される場合）場合は、それらのＡＰＩコマンドは暗号化付きデータを扱うＡＰＩコマンドであると認識する。

暗号化鍵取得部３５４は、ＡＰＩ処理部３５１から暗号化鍵の取得の実行命令を受信し、受信した実行命令に従って、処理を実行する。具体的には、暗号化鍵取得部３５４は、処理を実行することにより、暗号化鍵を取得したり暗号化鍵格納部３５５に暗号化鍵を取得済みであるかどうかを確認したりする。

暗号化鍵格納部３５５は、暗号化鍵取得部３５４が取得した暗号化鍵を格納するメモリである。

暗号化処理部３５６は、ＡＰＩ処理部３５１からの実行命令に応じて、暗号化鍵取得部３５４が取得した暗号化鍵を用いて受信機データを暗号化する。非対称鍵暗号技術による暗号化およびその復号化の方法については一般的な技術であるため説明は省略する。

受信機データ取得部３５７は、ＡＰＩ処理部３５１からの実行命令に応じて処理を実行する。具体的には、受信機データ取得部３５７は、情報蓄積部３６や受信機データ格納部３７などから受信機データを取得し、取得した受信機データを暗号化処理部３５６に出力する。

書込み処理部３５８は、ＡＰＩ処理部３５１からの実行命令に応じて、処理を実行する。具体的には、書込み処理部３５８は、暗号化処理部３５６から入力される暗号化付きデータをＡＰＩコマンドで指定される情報蓄積部３６のブロックまたはアイテムに書き込む。

通信処理部３５９は、アプリケーション実行部３５がネットワーク５を介して受信機３外部の装置（例えばサーバ２）と通信をするための機能を備える。具体的には、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）通信、ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ｓｅｃｕｒｅ（ｈｔｔｐｓ）通信またはＴｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ／Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ（ＴＬＳ／ＳＳＬ）通信などの機能を備えている。通信処理部３５９から出力されるデータは通信部３８からネットワーク５に出力される。

（第１の実施形態）
本実施形態においては、データ放送サービスのアプリケーションに含めた命令により、受信機３に対して、受信機データを暗号化させ、暗号化付きデータを格納領域を指定して情報蓄積部３６に書きこませ、さらに暗号付き受信機データを情報蓄積部３６から読み出させ、放送局のサーバに暗号化付きデータを送信させる例を説明する。

本実施形態のシステムの構成は図１、送信機１の機能構成は図２、サーバ２の機能構成は図４、受信機３の機能構成は図５、図６（ａ）、図７による。

以下、本実施形態に係るシステムの動作例を説明する。

図８は、第１の実施形態に係るシステムの動作例を示すシーケンスチャートである。

本実施形態に係るシステムの動作は、大きく４つのフェーズがある。フェーズごとに各装置の動作を示す。

フェーズ１は受信機３が暗号化鍵を取得するフェーズである。送信機１が「暗号化鍵取得命令」を放送波４で送信する（ステップＰ１１）。受信機３は放送波４を受信し、「暗号化鍵取得命令」を取得すると、「暗号化鍵要求」をサーバ２に出力する（ステップＰ１２）。サーバ２は、「暗号化鍵要求」を受信すると、「暗号化鍵」を受信機３に出力し、受信機３は「暗号化鍵」を受信し、暗号化鍵格納部３５５に格納する（ステップＰ１３）。

フェーズ２は受信機３が情報蓄積部３６に暗号化付きでデータを書き込むフェーズである。送信機１が（暗号化付きのデータの）書き込み命令を放送波４で送信する（ステップＰ２１）。受信機３は、放送波４を受信し、（暗号化付きのデータの）書き込み命令を取得すると、フェーズ１で取得した「暗号化鍵」を用いて受信機データを暗号化する（ステップＰ２２）。受信機３は、暗号化した受信機データを情報蓄積部３６に格納する（ステップＰ２３）。

フェーズ３は受信機３が情報蓄積部３６から暗号化付きデータを読み込むフェーズである。送信機１が「（暗号化付きデータの）読み出し命令」を放送波４で送信する（ステップＰ３１）。受信機３は放送波４を受信し、「（暗号化付きデータの）読み出し命令」を取得すると、情報蓄積部３６から指定された暗号化付きデータを読み出す（ステップＰ３２）。

フェーズ４は受信機３が暗号化付きデータをサーバ２へ送信し、サーバ２が受信機データを取得するフェーズである。送信機１が「（暗号化付きのデータの）送信命令」を放送波４で送信する（ステップＰ４１）。受信機３は放送波４を受信し、「（暗号化付きのデータの）送信命令」を取得すると、暗号化付きのデータを指定された装置（本実施形態においてはサーバ２）へ送信する（ステップＰ４２）。サーバ２は、暗号化付きのデータを受信し（ステップＰ４３）、暗号化復号鍵を用いて受信した暗号化付きのデータを復号し、受信機データを取得する（ステップＰ４４）。

なお、本実施形態においては送信機１が「書き込み命令」、「読み出し命令」、「送信命令」の生成を実施する例を示すが、サーバ２が各命令を生成し、ネットワーク６を介して送信機１に転送し、送信機１に各命令を放送波４で送信させることでもよい。

以下、各フェーズにおける送信機１、サーバ２、受信機３の動作例について各フローチャートを用いて説明する。

図９は、同実施形態に係る送信機の処理動作の例を示すフローチャートである。

送信機１のアプリケーションデータ生成部１４は、上記全てのフェーズの処理を順番に受信機３に実行させるためのＡＰＩコマンドを含めてアプリケーションデータを生成する（ステップＳ１１）。具体的なアプリケーションデータ例を以下に示す。＜アプリケーションデータがＢＭＬファイルの場合＞｛ｄｏｗｎｌｏａｄＢｒｏａｄｃａｓｔｅｒＣｅｒｔｉｆｉｃａｔｅ（引数１）ｗｒｉｔｅＰｅｒｓｉｓｔｅｎｔＡｒｒａｙ（引数２、引数３）ｒｅａｄＰｅｒｓｉｓｔｅｎｔＡｒｒａｙ（引数２）ｔｒａｎｓｍｉｔＴｅｘｔＤａｔａＯｖｅｒＩＰ（引数４、引数５）｝＜アプリケーションデータがＨＴＭＬファイルの場合＞｛ｄｏｗｎｌｏａｄＢｒｏａｄｃａｓｔｅｒＣｅｒｔｉｆｉｃａｔｅ（引数１）ｓｅｔＩｔｅｍ（引数２、引数３）ｇｅｔＩｔｅｍ（引数２）ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ．ｏｐｅｎ（引数４）ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ．ｓｅｎｄ（引数５）｝ただし、ＢＭＬファイル、ＨＴＭＬファイルともに、引数１は“ｈｔｔｐｓ：／／サーバ２のアドレス／暗号化鍵ファイルのパス”、引数２はｎｖｒａｍｅ：／／～／＜ブロック番号＞、引数３は受信機データ識別情報としてもよい。引数４は、送信先を識別する情報であり、例えば、暗号化付きのデータを放送局のサーバ２へ送信させる場合には“ｈｔｔｐｓ：／／サーバ２のアドレス？ｄａｔａｔｙｐｅ＝ｎｖｒａｍ＆ｅｎｃｒｙｐｔｅｄ＝ｙｅｓ”などでもよい。引数５は、各ファイルごとのＡＰＩコマンド、すなわちｒｅａｄＰｅｒｓｉｓｔｅｎｔＡｒｒａｙ（引数２）またはｇｅｔＩｔｅｍ（引数２）によって読み出される暗号化付きデータを表す情報であって、例えば読み出される暗号化付きデータの格納先を示す変数、オブジェクトなどでもよい。
放送ストリーム生成部１６は、生成したアプリケーションデータ（ＢＭＬファイルまたはＨＴＭＬファイル）と、サービスデータストリーム生成部１１や制御情報生成部１２が出力するデータストリームとを多重し、放送ストリームとして出力する（ステップＳ１２）。

放送信号送信部１７は、放送ストリームのデジタルデータが入力されると、各種デジタル放送の規格に応じた伝送路符号化や変調などを実施して放送波４を生成し、出力する（ステップＳ１３）。放送波４は図示せぬアンテナ、ケーブルなどから出力される。

図１０は、同実施形態における受信機の処理動作の例を示すフローチャートである。

例えばユーザがリモコン３０３からチャンネル切替をしたとする。受信機３は、インターフェース部３０２を介してリモコン３０３からのリモコン制御信号を受信し、制御部３３でリモコン制御信号が「チャンネル選択命令」であることを認識する（ステップＳ３１のＹｅｓ）。制御部３３は「チャンネル選択命令」に応じて放送チューナ３１を制御すると、放送チューナ３１は選択されたチャンネルの放送波４を受信する（ステップＳ３２）。放送チューナ３１は放送波４を処理して放送ストリームを得て、放送ストリーム処理部３２は放送ストリームを処理して各種データを得る。放送ストリーム処理部３２が取得したデータのうち、アプリケーション制御情報が制御部３３に出力されると、制御部３３はアプリケーション制御情報を解析する（ステップＳ３３）。制御部３３によりアプリケーション制御情報が解析され、「アプリケーション実行命令」が検知されると、制御部３３は、アプリケーション実行部３５を起動させる（ステップＳ３４）。一方、放送ストリーム処理部３２から得たデータのうちアプリケーションデータは、一旦、アプリケーションデータ格納部３４に格納される（ステップＳ３５）。アプリケーション実行部３５が起動すると、データ解析部３５０は、アプリケーション格納部３４からアプリケーションデータを取得し、アプリケーションデータを解析する（ステップＳ３６）。データ解析部３５０は、アプリケーションデータを解析して抽出したＡＰＩコマンドをＡＰＩ処理部３５１に出力し、ＡＰＩ処理部３５１はＡＰＩコマンドを解釈し、ＡＰＩの機能を実行する（ステップＳ３７）。

図１１は、同実施形態における暗号化鍵取得時のアプリケーション実行部の処理動作の例を示すフローチャートであり、フェーズ１での処理動作に相当する。本図は、図１０のフローチャートのステップＳ３７の詳細に相当する。

ＡＰＩ処理部３５１は、図３のＮｏ．１の行に示されるＡＰＩコマンドを受信し、ＡＰＩコマンドを認識する（ステップＳ３１１）。なお、各機能のＡＰＩについては、２Ｋ放送（ＴＳ方式）と４Ｋ８Ｋ方式（ＭＭＴ方式）とでＡＰＩコマンドの違いはあるが、ＡＰＩコマンドの処理およびＡＰＩによる処理には特に違いはない。従って、以降特に断らない限りは実施形態における説明は２Ｋ放送（ＴＳ方式）の場合および４Ｋ８Ｋ方式（ＭＭＴ方式）の場合両者に適用可能である。受信機３が受信する放送波４が２Ｋ放送（ＴＳ方式）であるか４Ｋ８Ｋ方式（ＭＭＴ方式）であるかは図１０のステップＳ３２において決まる。ＡＰＩ処理部３５１は、受信したＡＰＩコマンドが暗号化鍵をサーバ２に要求するＡＰＩコマンドであることを認識し、暗号化鍵取得部３５４に暗号化鍵取得処理を実行させる。暗号化鍵取得部３５４は、サーバ２に対して暗号化鍵を要求する（ステップＳ３１２）。具体的には、暗号化鍵取得部３５４は、ＡＰＩ処理部３５１からのＡＰＩコマンドに基づいた実行要求に従って暗号化鍵要求メッセージを作成し、通信処理部３５９、通信部３８を介して、サーバ２に暗号化鍵要求メッセージを送信する。サーバ２から暗号化鍵が送信されると、暗号化鍵取得部３５４は、通信部３８、通信処理部３５９を介して暗号化鍵を受信し、暗号化鍵格納部３５５に暗号化鍵を格納する（ステップＳ３１３）。

図１２は、同実施形態における暗号化鍵取得時のサーバの処理動作の例を示すフローチャートである。

サーバ２において、鍵生成部２５は、暗号化鍵、暗号化復号鍵を生成し、鍵格納部２４に格納する（ステップＳ２１１）。なお、鍵生成部２５は、受信機３の暗号化鍵要求メッセージを受信したタイミングで暗号化鍵、暗号化復号鍵を生成してもよいし、受信機３の暗号化鍵要求メッセージの受信有無に関わらず任意のタイミングで生成し、鍵格納部２４に格納することでもよい。アプリケーションデータ処理部２２は、通信部２１を介してメッセージを受信し、暗号化鍵要求メッセージであることを認識すると、暗号化鍵要求処理部２３に暗号化鍵要求メッセージを出力する（ステップＳ２１２）。暗号化鍵要求処理部２３は、受信した暗号化鍵要求メッセージに基づいて、暗号化鍵を鍵格納部２４から取得する（ステップＳ２１３）。暗号化鍵要求処理部２３は、受信機３に例えばｈｔｔｐｓ通信で暗号化鍵を送信する（ステップＳ２１４）。以上の手順により、受信機３は、サーバ２が所有する暗号化鍵を取得することができる。

図１３は、同実施形態におけるデータ書き込み時のアプリケーション実行部の処理動作の例を示すフローチャートであり、フェーズ２での処理動作に相当する。本図は、図１０のフローチャートのステップＳ３７の詳細に相当する。

ＡＰＩ処理部３５１は、図３のＮｏ．３またはＮｏ．４の行に示されるＡＰＩコマンドを受信する。ＡＰＩ処理部３５１は、ＡＰＩコマンドを認識し、暗号化判定部３５３に出力する（ステップＳ３２１）。暗号化判定部３５３は、ＡＰＩ名またはその引数などから、ＡＰＩコマンドが暗号化付きデータを扱うＡＰＩコマンドであるかどうかを判定する（ステップＳ３２２）。本実施形態においては、例えば、ＡＰＩコマンド名が”ｗｒｉｔｅＰｅｒｓｉｓｔｅｎｔＡｒｒａｙＥｎｃｒｙｐｔｅｄ“であれば暗号化付きデータを扱うＡＰＩコマンドであると判定し、ＡＰＩコマンド名が”ｗｒｉｔｅＰｅｒｓｉｓｔｅｎｔＡｒｒａｙ“であれば暗号化付きデータを扱わないと判定してもよい。または、ＡＰＩコマンドの引数が“ｎｖｒａｍｅ：／／～／＜ブロック番号＞”であれば暗号化付きデータを扱うＡＰＩコマンドであると判定し、ＡＰＩコマンドの引数が“ｎｖｒａｍ：／／～／＜ブロック番号＞”であれば暗号化付きデータを扱わないと判定することとしてもよい。

ＡＰＩコマンドが暗号化付きデータを扱う場合は、ＡＰＩ処理部３５１は暗号化処理部３５６にＡＰＩコマンドに基づいた処理を実行させて、暗号化処理部３５６はＡＰＩコマンドの引数などにて指定される受信機データ識別情報から暗号化すべき受信機データを認識し、指定された受信機データ（暗号化されていないデータ）を暗号化する（ステップＳ３２２のＹｅｓ、ステップＳ３２３）。より詳細には、暗号化処理部３５６は、ＡＰＩ処理部３５１から処理の実行命令を受信すると、例えば受信機データ格納部３７（場合によって情報蓄積部３６）から受信機データを取得し、暗号化鍵格納部３５５に格納されている暗号化鍵を用いて取得した受信機データの暗号化を実施し、暗号化付きデータを書込み処理部３５８に出力する。書込み処理部３５８は、暗号化付きデータを情報蓄積部３６の暗号化付きデータの格納エリア（例えば、ｎｖｒａｍｅ：／／～／＜ブロック番号＞の＜ブロック番号＞により指示されるブロック）に格納する（ステップＳ３２４）。一方、暗号化判定部３５３が、受信したＡＰＩコマンドは暗号化付きデータを扱わないと判定した場合、ＡＰＩ処理部３５１は、暗号化を行わずに指定のデータを情報蓄積部３６に格納する（ステップＳ３２２のＮｏ、ステップＳ３２５）。

図１４は、同実施形態におけるデータ読み出し時のアプリケーション実行部の処理動作の例を示すフローチャートであり、フェーズ３での処理動作に相当する。本図は、図１０のフローチャートのステップＳ３７の詳細に相当する。

ＡＰＩ処理部３５１は、図３のＮｏ．５またはＮｏ．６の行に示されるＡＰＩコマンドを受信し、ＡＰＩコマンドを認識する（ステップＳ３３１）。具体的には、ＡＰＩ処理部３５１は、ＡＰＩコマンドを認識し、暗号化判定部３５３に出力する。暗号化判定部３５３は、ＡＰＩ名またはその引数などから、ＡＰＩコマンドが暗号化付きデータを扱うＡＰＩコマンドであるかどうかを判定する（ステップＳ３３２）。本実施形態においては、例えば、ＡＰＩコマンド名が”ｒｅａｄＰｅｒｓｉｓｔｅｎｔＡｒｒａｙＥｎｃｒｙｐｔｅｄ“であれば暗号化付きデータを扱うＡＰＩコマンドであると判定し、ＡＰＩコマンド名が”ｒｅａｄＰｅｒｓｉｓｔｅｎｔＡｒｒａｙ“であれば暗号化付きデータを扱わないと判定してもよいし、または、ＡＰＩコマンドの引数が“ｎｖｒａｍｅ：／／～／＜ブロック番号＞”であれば暗号化付きデータを扱うＡＰＩコマンドであると判定し、ＡＰＩコマンドの引数が“ｎｖｒａｍ：／／～／＜ブロック番号＞”であれば暗号化付きデータを扱わないと判定することとしてもよい。ＡＰＩコマンドが暗号化付きデータを扱う場合は、読出し処理部３５２は、情報蓄積部３６の暗号化付きデータの格納エリアから暗号化付きデータを取り出し、通信処理部３５９に出力する（ステップＳ３３３）。ＡＰＩコマンドが暗号化付きデータを扱わない場合は、読出し処理部３５２は、情報蓄積部３６の暗号化無しデータの格納エリアからデータを取り出し、通信処理部３５９に出力する（ステップＳ３３４）。なお、暗号化付きデータの格納エリアと、暗号化なしデータの格納エリアを区別しない実施形態においては、前記ＡＰＩコマンドが暗号化付きデータを扱うＡＰＩコマンドであるかの判定（ステップＳ３３２）を行わず、読出し処理部３５２は情報蓄積部３６からデータを取り出し、通信処理部３５９に出力するのでもよい。通信処理部３５９においては、暗号化付きデータを例えば図示せぬメモリ、バッファなどに格納することでもよい。

図１５は、同実施形態におけるデータ送信時のアプリケーション実行部の処理動作の例を示すフローチャートであり、フェーズ４での処理動作に相当する。本図は、図１０のフローチャートのステップＳ３７の詳細に相当する。

ＡＰＩ処理部３５１は、図３のＮｏ．７の行に示されるＡＰＩコマンドを受信し、ＡＰＩコマンドを認識する（ステップＳ３４１）。ＡＰＩ処理部３５１は、認識したＡＰＩコマンドに基づいて、通信処理部３５９に処理を実行させる。具体的には、通信処理部３５９はＡＰＩコマンドで指定されたデータを、ｈｔｔｐｓ通信で送信するためのデータ（以降、ｈｔｔｐｓ送信データと称する）に変換する（ステップＳ３４２）。ｈｔｔｐｓ送信データは、通信部３８からネットワーク５を介してＡＰＩコマンドで指定されたＵＲＬにより識別されるサーバ２に送信される（ステップＳ３４３）。なお、フェーズ３である図３のＮｏ．５またはＮｏ．６の行のＡＰＩコマンドに応じたＡＰＩ機能の実行直後に図３のＮｏ．７の行のＡＰＩコマンドに応じたＡＰＩ機能を連続的に実行させることで、通信処理部３５９は、Ｎｏ．７の行のＡＰＩコマンドの引数に関わらずフェーズ３において情報蓄積部３６から読み出された暗号化付きデータを送信することにしてもよい。

図１６は、同実施形態におけるデータ受信時のサーバの処理動作の例を示すフローチャートである。

サーバ２のアプリケーションデータ処理部２２は、受信機３が送信したｈｔｔｐｓ送信データを受信する（ステップＳ２２１）。アプリケーションデータ処理部２２は、ｈｔｔｐｓ送信データに含まれる送信宛先ＵＲＬを解析する（ステップＳ２２２）。例えば、送信宛先ＵＲＬに”ｈｔｔｐｓ：／／サーバ２のアドレス？ｄａｔａｔｙｐｅ＝ｎｖｒａｍ＆ｅｎｃｒｙｐｔｅｄ＝ｙｅｓ“のように「ｅｎｃｒｙｐｔｅｄ＝ｙｅｓ」と記載されている場合は、アプリケーションデータ処理部２２は、ｈｔｔｐｓ送信データに含まれるデータが暗号化付きデータであると判断する。一方、送信宛先ＵＲＬ”ｈｔｔｐｓ：／／サーバ２のアドレス？ｄａｔａｔｙｐｅ＝ｎｖｒａｍ＆ｅｎｃｒｙｐｔｅｄ＝ｎｏ“のように「ｅｎｃｒｙｐｔｅｄ＝ｎｏ」と記載されている場合は、ｈｔｔｐｓ送信データに含まれるデータが暗号化付きでないデータであると判断する。ＵＲＬの解析の結果、ｈｔｔｐｓ送信データに含まれるデータが暗号化付きデータである場合、アプリケーションデータ処理部２２は、復号処理部２６に暗号化付きデータを出力する（ステップＳ２２２のＹｅｓ）。復号処理部２６は鍵格納部２４に格納されている暗号化復号鍵を用いて、暗号化付きデータを復号する（ステップＳ２２３）。

以上の手順により、データ放送サービスのアプリケーションに含めたＡＰＩコマンドによって、受信機３に受信機データを暗号化させ、情報蓄積部３６（ＮＶＲＡＭ）に書きこませることができる。さらにデータ放送サービスのアプリケーションに含めたＡＰＩコマンドによって、受信機３に情報蓄積部３６上の暗号化付きの受信機データを読み出させて、放送局のサーバ２に送信させることができる。放送局のサーバ２は、受信機３から暗号化付きの受信機データを受信し、暗号化付きの受信機データを復号することで受信機データを取得することが可能になる。

本実施形態においては、情報蓄積部３６に格納されるデータに対して非対称鍵暗号技術を用いて暗号化を実施することで、情報蓄積部３６に格納される暗号化付きデータはサーバ２のみが保有する暗号化復号鍵によってのみ復号することが可能となるので、サーバ２は機密性（または情報セキュリティ技術におけるＣｏｎｆｉｄｅｎｔｉａｌｉｔｙ）を確保しながら受信機データを収集することが可能になる。なお、データに対する暗号化技術としては、対称鍵暗号技術を用いることも可能である。ただし対称鍵暗号技術を用いる場合、データを暗号化するには共通鍵を用いる。共通鍵は、暗号化付きのデータの暗号化および暗号化の復号に必要となる。もし本実施形態において対称鍵暗号技術を適用させる場合、データの暗号化をする受信機３と暗号化付きデータの復号をするサーバ２とが同一の共通鍵を共有する。従って、対称鍵暗号技術を適用する場合、受信機３も暗号化付きデータを復号することのできる鍵を保有することとなる。受信機３の所有者やサーバ２の管理者である放送事業者ではない第三者が、何らかの手段（例えば、データ放送用ＮＶＲＡＭの実体である半導体メモリに、その読み出し装置を接続して読出しを行うなど）により情報蓄積部３６から暗号化付きデータを読み出し、かつ、前記の受信機３が保有する共通鍵も同様に取り出した場合、前記第三者は前記暗号化付きデータを復号して受信機データを入手することが可能であり、情報の機密性を確保するという課題は解決されない。非対称鍵暗号技術は、第三者に知られてもよい公開可能な公開鍵を暗号化鍵として利用し、復号鍵を共有する必要が無いために、本実施形態のようなシステムにおいて情報の機密性を確保するのに非常に効果的である。本実施形態においては、非対称鍵暗号技術を適用することで以上の問題は解決される。

（第２の実施形態）
本実施形態においては、データ放送サービスのアプリケーションに含めた命令により、受信機３に対して、放送信号に含まれている暗号化鍵を取得させる例を説明する。本実施形態においては、アプリケーションデータの一部として放送波４で送信される暗号化鍵を取得する場合の例を説明する。

本実施形態のシステムの構成は図１、送信機１の機能構成は図２、サーバ２の機能構成は図４、受信機３の機能構成は図５、図７を用いて説明する。

以下、本実施形態に係るシステムの動作例を説明する。

図１７は、第２の実施形態に係るシステムのシーケンスチャートであり、受信機３がアプリケーションデータの一部として送信される暗号化鍵を取得するフェーズにおけるシステムの動作の例である。

放送局のサーバ２は暗号化鍵を生成し、生成した「暗号化鍵」を、ネットワーク６を介して送信機１に送信する（ステップＰ１２１）。送信機１は、暗号化鍵を放送波４で送信する（ステップＰ１２２）。ここで送信機１は、アプリケーションデータ内に暗号化鍵を格納し、放送波４で送信する。送信機１は、暗号化鍵の送信とは別に「暗号化鍵取得命令」を放送波４で送信する（ステップＰ１２３）。受信機３は放送波４を受信し、解析する（ステップＰ１２４）。解析の結果、受信機３は「暗号化鍵取得命令」を検知すると、放送波４をさらに解析し、アプリケーションデータ内の暗号化鍵を取得する（ステップＰ１２５）。

図１８は、同実施形態に係る送信機の処理動作の例を示すフローチャートである。

送信機１のアプリケーションデータ生成部１４は、サーバ２から受信した暗号化鍵データを放送波４に乗せて送信するための暗号化鍵の送信データを生成する（ステップＳ１２０１）。具体的には、以下に示すような放送波４の種類に応じた放送波４上の格納場所（ＡＲＩＢ ＳＴＤ－Ｂ２４、ＡＲＩＢ ＳＴＤ－Ｂ６２などに準ずる）である、アプリケーションを構成するリソース（ファイル）として暗号化鍵の送信データを格納することでもよい。＜放送波４がＴＳ方式の場合＞ａｒｉｂ－ｄｃ：／／暗号化鍵のリソース名＜放送波４がＭＭＴ方式の場合＞ａｒｉｂ－ｄｃ２：／／暗号化鍵のリソース名
さらに、ステップＳ１２０１とは独立に（並行して）、受信機３に暗号化鍵の取得を実行させるために以下に示すようにＡＰＩコマンドを含めてアプリケーションデータを生成する（ステップＳ１２０２）。＜アプリケーションデータがＢＭＬファイルの場合＞｛ｄｏｗｎｌｏａｄＢｒｏａｄｃａｓｔｅｒＣｅｒｔｉｆｉｃａｔｅ（引数１）｝＜アプリケーションデータがＨＴＭＬファイルの場合＞｛ｄｏｗｎｌｏａｄＢｒｏａｄｃａｓｔｅｒＣｅｒｔｉｆｉｃａｔｅ（引数２）｝引数１、引数２については、例えばＢＭＬファイルの引数１は“ａｒｉｂ－ｄｃ：／／暗号化鍵のリソース名”、ＨＴＭＬファイルの引数２は“ａｒｉｂ－ｄｃ２：／／暗号化鍵のリソース名”とする。

放送ストリーム生成部１６は、生成した暗号化鍵の送信データとアプリケーションデータ（ＢＭＬファイルまたはＨＴＭＬファイル）とを、他のサービスデータストリーム生成部１１や制御情報生成部１２が出力するデータストリームと多重し、放送ストリームとして出力する（ステップＳ１２０３）。暗号化鍵の送信データは、アプリケーションストリームに格納される。

放送信号送信部１７は、放送ストリームのデジタルデータが入力されると、各種デジタル放送の規格に応じた伝送路符号化や変調などを実施して放送波４を生成し、出力する（ステップＳ１２０４）。放送波４は図示せぬアンテナ、ケーブルなどから出力される。

図１９は、同実施形態における暗号化鍵取得時のアプリケーション実行部の処理動作の例を示すフローチャートである。受信機３の処理動作は、図１０のフローチャートと同様であり、図１９は図１０のステップＳ３７に相当する処理動作を示している。

受信機３のＡＰＩ処理部３５１は、図３のＮｏ．２の行に示されるＡＰＩコマンドを受信し、ＡＰＩコマンドを認識する（ステップＳ３２０１）。ＡＰＩ処理部３５１は、ＡＰＩコマンドの引数から放送波４に暗号化鍵が格納されていることを認識すると、制御部３３にＡＰＩコマンドに基づいた処理を実行させる。制御部３３は、放送波４の解析を実行する。（ステップＳ３２０２）。具体的には、制御部３３は、ＡＰＩコマンドの引数として指定された暗号化鍵データの格納場所に基づいて、放送ストリーム処理部３２が出力するデータ放送サービスのデータから、暗号化鍵を特定する。制御部３３は、特定した暗号化鍵をＡＰＩ処理部３５１に出力し、ＡＰＩ処理部３５１は、入力された暗号化鍵を暗号化鍵格納部３５５に格納する（ステップＳ３２０３）。

以上の手順により、データ放送サービスのアプリケーションに含めた命令により、受信機３は、放送波４に含めて送信される暗号化鍵を取得することが可能になる。

（第３の実施形態）
本実施形態においては、受信機３に対して、放送信号に含まれている暗号化鍵を取得させる例を説明する。本実施形態においては、アプリケーションデータとは別に同一の放送波４で送信されるＳＩ（Ｓｉｇｎａｌｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ）から暗号化鍵を取得する場合の例を説明する。

本実施形態のシステムの構成は図１、送信機１の機能構成は図２、サーバ２の機能構成は図４、受信機３の機能構成は図５、図７を用いて説明する。

以下、本実施形態に係るシステムの動作例を説明する。

図２０は、第３の実施形態に係るシステムのシーケンスチャートであり、受信機３がアプリケーションデータとは別に同一の放送波４で送信されるＳＩから暗号化鍵を取得するフェーズにおけるシステムの動作の例である。

放送局のサーバ２は、暗号化鍵を生成し、生成した暗号化鍵をネットワーク６を介して送信機１に送信する（ステップＰ１３１）。送信機１は、暗号化鍵を放送波４のＳＩで送信する（ステップＰ１３２）。ここで送信機１は、暗号化鍵を繰り返し放送波４で送信することでもよい。受信機３は放送波４を受信し、解析する（ステップＰ１３３）。解析により、受信機３は放送波４に格納されている暗号化鍵を取得する（ステップＰ１３４）。

図２１は、同実施形態におけるＴＳ方式の放送波４のＳＩで暗号化鍵を送信する場合の例である。図２１（ａ）は、暗号化鍵である放送事業者の公開鍵を格納する記述子（ブロードキャスタ公開鍵記述子）であり、その構造はＡＲＩＢ ＳＴＤ－Ｂ１０に規定される記述子の共通構造の通りである。前記記述子を、例えば、図２１（ｂ）の領域１２４１Ａまたは１２４１Ｂに示す、ＡＲＩＢ ＳＴＤ－Ｂ１０が規定するブロードキャスタ情報テーブル（ＢＩＴ）の記述子領域に配置して送信する。

図２２は、同実施形態におけるＭＭＴ方式の放送波４のＳＩで暗号化鍵を送信する場合の例である。図２２（ａ）は、暗号化鍵である放送事業者の公開鍵を格納する記述子（ＭＨ－ブロードキャスタ公開鍵記述子）であり、その構造はＡＲＩＢ ＳＴＤ－Ｂ６０に規定される記述子の共通構造の通りである。前記記述子を、例えば、図２２（ｂ）の領域１２４２Ａまたは１２４２Ｂに示す、ＡＲＩＢ ＳＴＤ－Ｂ６０が規定するＭＨ－ブロードキャスタ情報テーブル（ＭＨ－ＢＩＴ）の記述子領域に配置して送信する。

送信機１は、ステップＰ１３１とは独立に（暗号化付きのデータの）書き込み命令を放送波４で送信する（ステップＰ２３１）。受信機３は、（暗号化付きのデータの）書き込み命令を受信すると、例えば暗号化で必要な暗号化鍵が暗号化鍵格納部３５５に格納されているかを確認する（ステップＰ２３２）。受信機３は、暗号化鍵格納部３５５に暗号化鍵が格納されていることを認識すると、（暗号化付きのデータの）書き込み命令の対象となる受信機データを暗号化鍵を用いて暗号化する（ステップＰ２３３）。受信機３は、暗号化した受信機データを情報蓄積部３６に格納する（ステップＰ２３４）。以下、本実施形態における送信機１、受信機３の動作例について説明する。

送信機１は、例えば制御情報生成部１２において制御情報（例えばＳＩ）として暗号化鍵を送信する。また、送信機１のアプリケーションデータ生成部１４は、暗号化鍵の送信とは独立に、図３のＮｏ．３の行のＡＰＩコマンドを含めて以下のようにアプリケーションデータを生成する。＜アプリケーションデータがＢＭＬファイルの場合＞｛ｗｒｉｔｅＰｅｒｓｉｓｔｅｎｔＡｒｒａｙ（引数１、引数２）｝＜アプリケーションデータがＨＴＭＬファイルの場合＞｛ｓｅｔＩｔｅｍ（引数３、引数４）｝ただし、引数１は“ｎｖｒａｍｅ：／／～／＜ブロック番号＞”、引数３は“＿ｅ＿ｗｌｏｃａｌ＋アイテム番号”としてもよい。また、引数２および引数４は受信機データ識別情報としてもよい。上記のＡＰＩコマンドについては、第１の実施形態において用いたＡＰＩコマンドと同一なので説明を省略する。

図２３は、同実施形態における受信機の処理動作の例を示すフローチャートである。

ステップＳ３３０１からＳ３３０６までの動作は、第１の実施形態の図１０のステップＳ３１からＳ３７と同様であるのでここでは説明を省略する。本実施形態においては、第１の実施形態の動作例と異なり、ステップＳ３３０７からＳ３３０９が追加されている。図２３のフローチャートにおいては、ステップＳ３３０２以降、Ｓ３３０３、Ｓ３３０４、Ｓ３３０７が並列（独立）に動作していることを示している。

受信機３の制御部３３は、放送ストリーム処理部３２が出力する放送ストリームを解析し、暗号化鍵を含むＳＩを抽出する（ステップＳ３３０７）。さらに制御部３３は、抽出したＳＩから暗号化鍵を抽出し、暗号化鍵取得部３５４に暗号化鍵を出力する（ステップＳ３３０８）。暗号化鍵取得部３５４は入力された暗号化鍵を暗号化鍵格納部３５５に格納する（ステップＳ３３０９）。

図２４は、同実施形態におけるデータ書き込み時のアプリケーション実行部の処理動作の例を示すフローチャートであり、図２３のフローチャートのステップＳ３３１０の詳細に相当する。

ＡＰＩ処理部３５１は、図３のＮｏ．３の行に示されるＡＰＩコマンドを受信し、ＡＰＩコマンドを認識する（ステップＳ３３２１）。ＡＰＩ処理部３５１は、認識したＡＰＩコマンドを暗号化判定部３５３に出力する。暗号化判定部３５３は、ＡＰＩ名またはその引数などから、ＡＰＩコマンドが暗号化付きデータを扱うＡＰＩコマンドであるかどうかを判定する（ステップＳ３３２２）。本実施形態においては、ＡＰＩコマンドの引数に「ｎｖｒａｍｅ：」が含まれていることから、暗号化判定部３５３は、暗号化付きデータを扱うＡＰＩコマンドであると判定し、ＡＰＩ処理部３５１は、その判定に基づいて、暗号化鍵格納部３５５に必要な暗号化鍵が格納されているかを暗号化鍵取得部３５４に確認させる（ステップＳ３３２３）。暗号化鍵格納部３５５に必要な暗号化鍵が格納されている場合、暗号化鍵取得部３５４は、暗号化鍵格納部３５５から暗号化鍵を取得し、暗号化処理部３５６に入力する（ステップＳ３３２３のＹｅｓ、Ｓ３３２４）。暗号化処理部３５６は、ＡＰＩコマンドの引数の受信機データ識別情報などにて指定された受信機データ（暗号化されていないデータ）を先のステップで取得した暗号化鍵で暗号化し、暗号化付きデータを生成する（ステップＳ３３２５）。暗号化処理部３５６は、暗号化付きデータを書込み処理部３５８に出力し、書込み処理部３５８は、暗号化付きデータを情報蓄積部３６の暗号化付きデータの格納エリア（例えば、ｎｖｒａｍｅ：／／～／＜ブロック番号＞）に格納する（ステップＳ３３２６）。暗号化判定部３５３が、ＡＰＩコマンドが暗号化付きデータを扱わないＡＰＩコマンドであると判定した場合、ＡＰＩ処理部３５１は、暗号化を行わずに指定のデータを情報蓄積部３６に格納する（ステップＳ３３２２のＮｏ、Ｓ３３２７）。また、暗号化鍵取得部３５４は、暗号化鍵格納部３５５に必要な暗号化鍵が格納されていない場合、指定の受信機データの暗号化を行わずに終了する（ステップＳ３３２３のＮｏ）。もしくは、しばらく待ってから再度、ステップＳ３３２３から繰り返してもよい。

以上の手順によって、受信機３が放送波４におけるアプリケーションデータとは別に同一の放送波４にて送信されるＳＩから暗号化鍵を取得し、データ放送サービスのアプリケーションに含めた命令により、受信機３に対して、受信機データを暗号化させ、暗号化付きデータを情報蓄積部３６（ＮＶＲＡＭ）に書き込ませることができる。

なお、第２の実施形態において、放送波４のアプリケーションデータの一部として暗号化鍵を送信する例について説明し、第３の実施形態において、放送波４のＳＩとして暗号化鍵を送信する例について説明したが、例えば、第２の実施形態において暗号化鍵をＳＩとして送信する形態や、第３の実施形態において暗号化鍵をアプリケーションの一部として送信する形態も可能である。具体的には、前者の形態においては、暗号化鍵を取得させるＡＰＩコマンドに、暗号化鍵の放送波４における格納位置を識別する情報として、例えば空文字列を設定し、制御部３３は、暗号化鍵の格納位置を識別する情報として空文字列が指定されていることを確認した場合に、暗号化鍵を放送波４のＳＩから取得し、取得した暗号化鍵をＡＰＩ処理部３５１に出力するようにしてもよい。後者の形態においては、暗号化鍵をアプリケーションデータのあらかじめ定められたリソースとして格納することでもよい。以上のように、送信側（送信機１）が鍵を送信する方法には、アプリケーションデータの一部として送信する方法やＳＩとして送信する方法などがある。また、受信側（受信機３）が鍵を受信する方法には、ＡＰＩで行う方法やＡＰＩを用いずに受信機がバックグラウンドで行う方法などがある。これら鍵を送信する方法と鍵を受信する方法との組み合わせに特に制限はなく、任意の組み合わせが可能である。

（第４の実施形態）
本実施形態においては、データ放送サービスのアプリケーションに含めた命令により、受信機３に対して、暗号化領域を指定せずに暗号化付きデータを情報蓄積部３６（ＮＶＲＡＭ）に書きこませ、さらに書き込ませたデータを読み出させる例について説明する。本実施形態においては、ＡＰＩコマンドのＡＰＩ名に暗号化データを扱うことがわかるワードを含ませることで、受信機３はＡＰＩコマンドが暗号化付きデータを扱うことを認識する。

本実施形態のシステムの構成は図１、送信機１の機能構成は図２、サーバ２の機能構成は図４、受信機３の機能構成は図５、図７を用いて説明する。

以下、本実施形態に係るシステムの動作例を説明する。本実施形態においては、暗号化鍵が暗号化鍵格納部３５５に格納されているものとする。また、送信機１、サーバ２、受信機３の動作例は、第１の実施形態で用いたフローチャートを用いて説明する。また、第１の実施形態における動作例と同様の部分については説明を省略する。

以下、図９のフローチャートを用いて送信機１の動作例を説明する。

アプリケーションデータ生成部１４は、受信機３に暗号化付きの受信機データの書き込み、読出し、送信を実行させるために図３のＮｏ．４、Ｎｏ．６、Ｎｏ．７の行のＡＰＩコマンドを含めて以下に示すようにアプリケーションデータを生成する（図９のステップＳ１１）。＜アプリケーションデータがＢＭＬファイルの場合＞｛ｗｒｉｔｅＰｅｒｓｉｓｔｅｎｔＡｒｒａｙＥｎｃｒｙｐｔｅｄ（引数１、引数２）ＲｅａｄＰｅｒｓｉｓｔｅｎｔＡｒｒａｙＥｎｃｒｙｐｔｅｄ（引数１）ｔｒａｎｓｍｉｔＴｅｘｔＤａｔａＯｖｅｒＩＰ（引数３、引数４）｝＜アプリケーションデータがＨＴＭＬファイルの場合＞｛ｓｅｔＩｔｅｍＥｎｃｒｙｐｔｅｄ（引数１、引数２）ｇｅｔＩｔｅｍＥｎｃｒｙｐｔｅｄ（引数１）ｐｕｔＩｔｅｍ（引数３、引数４）｝ただし、引数１はＢＭＬファイルでは“ｎｖｒａｍ：／／～／＜ブロック番号＞”、ＨＴＭＬファイルでは“＿ｗｌｏｃａｌ＋アイテム番号”などとしてもよい。引数２はＢＭＬファイル、ＨＴＭＬファイルともに受信機データ識別情報としてもよい。引数３は、各ファイルごとのＡＰＩコマンド、すなわちｒｅａｄＰｅｒｓｉｓｔｅｎｔＡｒｒａｙ（引数１）またはｇｅｔＩｔｅｍＥｎｃｒｙｐｔｅｄ（引数１）によって読み出される暗号化付きデータを表す情報であって、例えば読み出される暗号化付きデータの格納先を示す変数、オブジェクトなどでもよい。引数４は、送信先を識別する情報であり、例えば、暗号化付きのデータを放送局のサーバ２へ送信させる場合には“ｈｔｔｐｓ：／／サーバ２のアドレス？ｄａｔａｔｙｐｅ＝ｎｖｒａｍ＆ｅｎｃｒｙｐｔｅｄ＝ｙｅｓ”などでもよい。第１の実施形態での引数と異なり、本実施形態においては、データ書き込み先の引数１を「ｎｖｒａｍ：」としている。また、データ送信ＡＰＩコマンド（図３のＮｏ．７の行のＡＰＩ）について、上記のように暗号化付きデータ読み出しＡＰＩを実行するＡＰＩコマンドとデータ送信ＡＰＩを実行するＡＰＩコマンドが連続して記述されている場合には、引数２の指定がなくとも、データ送信ＡＰＩは暗号化付きデータ読み出しＡＰＩが読み出したデータを送信するようにしてもよい。

放送ストリーム生成部１６は、生成したアプリケーションデータ（ＢＭＬファイルまたはＨＴＭＬファイル）と他のデータストリームとを多重した放送ストリームを生成し、放送信号送信部１７は、放送ストリームを放送波４として出力する（ステップＳ１２、Ｓ１３）。

次に受信機３のデータ書き込み時の動作例を、第１の実施形態の説明で示した図１０および図１３を用いて説明する。

受信機３は、図１０のフローチャートによってＡＰＩコマンドを抽出し（ステップＳ３７）、さらに図１３のフローチャートによって受信機データの暗号化処理（ステップＳ３２３）を実施し、暗号化付きデータを得たものとする。

図２５は、第４の実施形態におけるデータ書き込み時の書込み処理部の処理動作の例を示すフローチャートであり、図１３のステップＳ３２４の詳細に相当する。

書込み処理部３５８は、暗号化を実施した受信機データに対して、「暗号化を実施したデータ」であることを示すための暗号化識別情報を生成する（ステップＳ３４０１）。書込み処理部３５８は、暗号化した受信機データと暗号化識別情報とを含めて、データブロックを生成する（ステップＳ３４０２）。データブロックとは、図６に示したブロックごとの全てのフィールドのデータを示しており、特にフィールド１の「データ」が暗号化された受信機データである場合、暗号化データブロックと称してもよい。

図６（ｃ）は、情報蓄積部３６の記憶領域に格納されるデータの一例を示しており、図６（ａ）に対して領域３６０７、「暗号化有無」のフィールドを追加している。暗号化識別情報は、例えば、１ビットのデータとして、０の場合は暗号化なしのデータ、１の場合は暗号化有のデータとすることでもよい。本実施形態では、ブロックごとに「データ」の暗号化処理を実施し、ブロックごとの暗号化識別情報を領域３６０７に格納する例を示している。第１の実施形態では、図６（ｂ）の領域３６０６に示すように暗号化した受信機データを格納する領域をｎｖｒａｍｅ：／／～として指定したが、本実施形態では、暗号化した受信機データを格納する領域をｎｖｒａｍ：／／～としている。そのために本実施形態の例では、暗号化した受信機データと暗号化されていない受信機データが混在して格納される可能性がある。本実施形態においては図６（ｃ）の領域３６０７を追加することで、暗号化した受信機データと暗号化されていない受信機データを区別することが可能である。なお、暗号化識別情報を領域３６０７に格納するのではなく、情報蓄積部３６のブロックと暗号化識別情報との対応表を作成し、対応表を別途メモリなどに格納することでもよい。

図２５に戻り、書込み処理部３５８は、暗号化データブロックをｎｖｒａｍ：／／～で指定される情報蓄積部３６に書き込む（ステップＳ３４０３）。

以上の手順により、暗号化データの領域を定めることなく、情報蓄積部３６（データ放送用ＮＶＲＡＭ）に暗号化データを書き込むことができる。

以下に、受信機３のデータ読み出し時の動作例を説明する。

図２６は、同実施形態におけるデータ読み出し時のアプリケーション実行部の処理動作の例を示すフローチャートであり、図１０のフローチャートのステップＳ３７の詳細に相当する。

ＡＰＩ処理部３５１は、図３のＮｏ．６の行に示されるＡＰＩコマンドを受信し、ＡＰＩコマンドを認識する（ステップＳ３４３１）。ＡＰＩ処理部３５１は、認識したＡＰＩコマンドを暗号化判定部３５３に出力する。暗号化判定部３５３は、ＡＰＩ名またはその引数などから、ＡＰＩコマンドが暗号化付きデータを扱うＡＰＩコマンドであるかどうかを判定する（ステップＳ３４３２）。本実施形態においては、ＡＰＩ名に「Ｅｎｃｒｙｐｔｅｄ」が含まれていることから暗号化判定部３５３は、暗号化付きデータを扱うＡＰＩコマンドであると判定し、ＡＰＩ処理部３５１は読出し処理部３５２にＡＰＩコマンドに基づく処理を実行させ、読出し処理部３５２は、暗号化付きデータの読み出し処理を実施する。読出し処理部３５２は、ＡＰＩコマンドの引数である受信機データ識別情報で読出し指定された「情報要素」に対する暗号化識別情報（図６（ｃ）の領域３６０７）が１の場合に、読出し指定された「情報要素」のデータを読み出して、通信処理部３５９に出力する（ステップＳ３４３３のＹｅｓ、Ｓ３４３４）。読出し指定された「情報要素」に対する暗号化識別情報が０の場合は、読出し処理部３５２は、読出し指定された「情報要素」の読出しを中止する（ステップＳ３４３３のＮｏ、Ｓ３４３５）。一方、暗号化判定部３５３が、暗号化付きデータを扱うＡＰＩコマンドであると判定しなかった場合、ＡＰＩ処理部３５１は読出し処理部３５２に暗号化のされていないデータの読み出し処理を実施させる。読出し処理部３５２は、読出し指定された「情報要素」に対する暗号化識別情報（図６（ｃ）の領域３６０７）が０の場合に、指定された「情報要素」のデータを読み出して、通信処理部３５９に出力する（ステップＳ３４３６のＹｅｓ、Ｓ３４３４）。読出し指定された「情報要素」に対する暗号化識別情報が１の場合は、読出し処理部３５２は、読出し指定された「情報要素」の読出しを中止する（ステップＳ３４３３のＮｏ、Ｓ３４３５）。通信処理部３５９において、読出し処理部３５２が読み出したデータが入力された場合、例えば図示せぬメモリ、バッファなどに格納することでもよい。本実施形態においては、暗号化付きデータ読み出しＡＰＩを実行するＡＰＩコマンドの直後にデータ送信ＡＰＩを実行するＡＰＩコマンドが記述されているので、読出し処理部３５２が読み出したデータは直ちに、通信処理部３５９から通信部３８を介してサーバ２へと送信されることでもよい。

以上の手順により、暗号化データの領域を定めずに情報蓄積部３６（データ放送用ＮＶＲＡＭ）から暗号化データを読み出すことができる。なお、情報蓄積部３６のブロックと暗号化識別情報との対応表がある場合は、読出し処理部３５２は、対応表に基づいて、読出し処理を実施することでもよい。また本実施形態によれば、暗号化データの領域を定めない情報蓄積部３６に、暗号化されたデータと暗号化されていないデータが混在する場合においても、暗号化されたデータと暗号化されていないデータ双方を選択して読み出すことができる。

以上の手順で読み出されたデータは、図１５のフローチャートを用いて外部に送信することできる。データの送信の詳細については、第１の実施形態と同様であるため説明を省略する。さらに、受信機３から送信された暗号化付きのデータは、図１６のフローチャートを用いてサーバ２が受信し、暗号化を復号して（暗号化されていない）受信機データを取得することができる。サーバ２による暗号化付きデータの受信、復号の詳細については、第１の実施形態と同様であるため説明を省略する。

本実施形態によれば、データ放送サービスのアプリケーションに含めた命令により、受信機３に対して、受信機データを暗号化させ、暗号化領域を指定せずに暗号化付きデータを情報蓄積部３６（データ放送用ＮＶＲＡＭ）に書きこませ、さらに書き込ませたデータを読み出し、サーバ２へ送信させることが可能となる。

以上述べた少なくとも１つの実施形態によれば、情報の機密性を確保しながら受信機データを記録または収集するための受信機、方法およびプログラムを提供することができる。

上記した本システムにおける受信機の要点は以下のように記載することもできる。（１）放送信号に含まれるデータ放送サービスのアプリケーションデータを実行するアプリケーション実行手段（アプリケーション実行部３５）と、前記アプリケーションデータにより指示された情報の書き込みを実行する情報書き込み手段（書込み処理部３５８）、前記アプリケーションデータにより指示された情報を蓄積する情報蓄積手段（情報蓄積部部３６）を備える受信機であって、前記アプリケーションデータにより指示された情報を暗号化する暗号化手段（暗号化処理部３５６）、前記暗号化手段が用いる暗号化鍵を格納する暗号化鍵格納手段（暗号化鍵格納部３５５）を備え、前記情報を前記暗号化手段によって暗号化してから、前記情報蓄積手段へ書き込むことを特徴とする受信機。（２）前記アプリケーションデータによる指示により前記情報蓄積手段から暗号化された情報を読み出しする情報読出し手段（読出し処理部３５２）を備え、前記読み出した情報を復号せず外部装置（サーバ２）へ出力することを特徴とする、（１）に記載の受信機。（３）前記暗号化鍵は、公開鍵暗号方式の公開鍵であることを特徴とする（１）または（２）に記載の受信機。（４）前記アプリケーションデータに含まれる指示によって暗号化鍵を前記暗号化鍵格納手段へ格納する前記暗号化鍵格納指示手段を備えることを特徴とする（１）から（３）に記載の受信機。（５）前記暗号化鍵は、前記放送信号に含まれるデータ放送のアプリケーションデータの一部であることを特徴とする、（４）に記載の受信機。（６）前記暗号化鍵は、暗号化復号鍵を所有する外部装置（サーバ２）から取得することを特徴とする（４）に記載の受信機。（７）前記放送信号の前記アプリケーションデータを除いた部分から前記暗号化鍵を取り出し、前記暗号化鍵を前記暗号化鍵格納手段に格納する暗号化鍵分離手段（制御部３３）を備えることを特徴とする、（１）から（３）に記載の受信機（８）前記情報書き込み手段、前記情報読み出し手段は、前記アプリケーション実行手段が提供する、データアプリケーションから呼び出されるためのＡＰＩであることを特徴とする、（１）から（７）に記載の受信機。（９）前記暗号化鍵格納指示手段は、前記アプリケーション実行手段が提供する、データアプリケーションから呼び出されるためのＡＰＩであることを特徴とする、（４）から（６）に記載の受信機。

上記した本システムにおける送信機の要点は以下のように記載することもできる。（Ａ１）
デジタルテレビ放送の送信機であって、
暗号化鍵を持つサーバから暗号化鍵を取得し、前記暗号化鍵を格納する暗号化鍵格納部と、
前記デジタルテレビ放送の受信機に、前記受信機にある受信機データを前記暗号化鍵で暗号させ、暗号化付きデータを前記受信機の内部の情報蓄積手段に書き込ませる書き込み命令と、前記暗号化鍵とを放送信号に含めて送信する放送信号送信手段を具備した送信機。（Ａ２）
前記暗号化鍵は、公開鍵暗号方式の公開鍵である（Ａ１）に記載の送信機。（Ａ３）
書き込み命令を送信する書込み命令送信手段を備える（Ａ１）または（Ａ２）のいずれか１項に記載の送信機。（Ａ４）
前記書き込み命令は、書き込みをさせる受信機データの識別情報と前記受信機データを暗号化して生成させた暗号化付きデータの格納先であるデータ格納識別情報とを含む（Ａ１）乃至（Ａ３）のいずれか１項に記載の送信機。（Ａ５）
前記データ格納識別情報は、前記受信機データを暗号化して生成させる暗号化書込み指示情報である（Ａ４）に記載の受信機。（Ａ６）
前記書き込み命令名は、前記書き込みをさせる受信機データが前記暗号化付きデータであることを判別するための判別情報を含む（Ａ４）に記載の受信機。（Ａ７）
前記書き込み命令は、前記デジタルテレビ放送のデータ放送サービスで放送されるアプリケーションデータに含められて、前記アプリケーションデータは前記放送信号に含められる（Ａ１）乃至（Ａ６）のいずれか１項に記載の送信機。（Ａ８）
前記書き込み命令は、受信機に組み込まれるＡＰＩに対するコマンドである（Ａ７）に記載の送信機。

上記した本システムの要点は以下のように記載することもできる。（Ｂ１）
送信機とサーバと受信機とを備えるデジタルテレビ放送のシステムにおいて、
前記送信機と前記サーバとは暗号化鍵を共有し、
前記送信機は、暗号化鍵を持つサーバから暗号化鍵を取得し、前記暗号化鍵を格納する暗号化鍵格納部と、
前記デジタルテレビ放送の受信機に、前記受信機にある受信機データを前記暗号化鍵で暗号化させ、暗号化付きデータを前記受信機の内部の情報蓄積手段に書き込ませる書き込み命令と、前記暗号化鍵とを放送信号に含めて送信する放送信号送信手段とを備え、
前記受信機は、放送信号を受信する放送信号受信手段と、
前記放送信号から暗号化鍵を取得する暗号化鍵取得手段と、
前記放送信号に含まれる書き込み命令に基づいて、前記暗号化鍵を使って前記受信機にある受信機データを暗号化して暗号化付きデータを生成する暗号化手段と、
前記暗号化付きデータを情報蓄積部に書き込みする情報書き込み手段とを備えたシステム。（Ｂ２）
前記暗号化鍵は、公開鍵暗号方式の公開鍵である（Ｂ１）に記載のシステム。（Ｂ３）
前記書き込み命令は、前記デジタルテレビ放送のデータ放送サービスで放送されるアプリケーションデータに含められて、前記アプリケーションデータは前記放送信号に含められる（Ｂ１）または（Ｂ２）のいずれか１項に記載のシステム。（Ｂ４）
前記暗号化鍵は、前記アプリケーションデータに含められる（Ｂ１）乃至（Ｂ３）のいずれか１項に記載のシステム。（Ｂ５）
前記暗号化鍵は、前記放送信号の前記アプリケーションデータを除いた部分に含められる（Ｂ１）乃至（Ｂ３）のいずれか１項に記載のシステム。

本発明のいくつかの実施形態を説明したが、これらの実施形態は例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。さらにまた、請求項の各構成要素において、構成要素を分割して表現した場合、或いは複数を合わせて表現した場合、或いはこれらを組み合わせて表現した場合であっても本発明の範疇である。また、複数の実施形態を組み合わせてもよく、この組み合わせで構成される実施例も発明の範疇である。

また、図面は、説明をより明確にするため、実際の態様に比べて、各部の幅、厚さ、形状などについて模式的に表される場合がある。図面の機能ブロック図においては、説明に必要な機能の構成要素をブロックで表しており、一般的な機能の構成要素についての記載を省略している場合がある。また機能を示すブロックは機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。例えば、各機能のブロックの分散・統合の具体的な形態は図中の形態に限らない。各機能のブロックにおける使用状況などに応じて、機能的もしくは物理的に分散・統合して構成する。ブロック図においては、結線されていないブロック間もしくは、結線されていても矢印が示されていない方向に対してもデータや信号のやり取りを行う場合もある。ブロック図に示される各機能や、フローチャート、シーケンスチャートに示す処理は、ハードウェア（ＩＣチップなど）、ソフトウェア（プログラムなど）、デジタル信号処理用演算チップ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ、ＤＳＰ）、またはこれらのハードウェアとソフトウェアの組み合わせによって実現してもよい。また請求項を制御ロジックとして表現した場合、コンピュータを実行させるインストラクションを含むプログラムとして表現した場合、および前記インストラクションを記載したコンピュータ読み取り可能な記録媒体として表現した場合でも本発明の装置または方法を適用したものである。また、使用している名称や用語についても限定されるものではなく、他の表現であっても実質的に同一内容、同趣旨であれば、本発明に含まれるものである。

１…送信機、２…サーバ、３…受信機、４…放送波、５…ネットワーク、６…ネットワーク、１０…放送局、１１…サービスデータストリーム生成部、１２…制御情報生成部、１３…アプリケーションストリーム生成部、１４…アプリケーションデータ生成部、１５…暗号化鍵格納部、１６…放送ストリーム生成部、１７…放送信号送信部、２１…通信部、２２…アプリケーションデータ処理部、２３…暗号化鍵要求処理部、２４…鍵格納部、２５…鍵生成部、２６…復号処理部、２７…受信機データ格納、３１…放送チューナ、３２…放送ストリーム処理部、３３…制御部、３４…アプリケーションデータ格納部、３５…アプリケーション実行部、３６…情報蓄積部、３７…受信機データ格納部、３８…通信部、３９…提示制御部、３０１…提示部、３０２…インターフェース部、３０３…リモコン部、３５０…データ解析部、３５１…ＡＰＩ処理部、３５２…読出し処理部、３５３…暗号化判定部、３５４…暗号化鍵取得部、３５５…暗号化鍵格納部、３５６…暗号化処理部、３５７…受信機データ取得部、３５８…書込み処理部、３５９…通信処理部。

Claims (4)

1. 受信機とサーバと送信機とを備えるデジタルテレビ放送システムであって、
   前記受信機は、
   前記送信機から送られてくる放送信号を受信する受信手段と、
   鍵取得命令に基づいて、前記放送信号から又は通信回線を介して前記サーバから暗号化鍵を取得する暗号化鍵取得手段と、
   前記放送信号に含まれる書き込み命令に基づいて、前記暗号化鍵を使用して前記受信機にある受信機データを暗号化して暗号化付きデータを生成する暗号化手段と、
   前記暗号化付きデータを情報蓄積部に書き込みする情報書き込み手段と、を備え、
   前記送信機は、
   アプリケーションデータ生成手段を有し、このアプリケーションデータ生成手段は、
   前記受信機に前記暗号化鍵を取得させるための前記鍵取得命令と、
   前記暗号化鍵を使用して前記暗号化付きデータを生成し、前記暗号化付きデータを前記情報蓄積部に書き込ませるための前記書き込み命令と、
   前記受信機の情報読み出し手段が前記情報蓄積部から前記暗号化付きデータを読み出すように命令する読み出し命令と、
   読み出した前記暗号化付きデータを前記サーバへ送信するように命令する送信命令と、を生成して前記放送信号に含ませる、前記アプリケーションデータ生成手段である、
   デジタルテレビ放送システム。
2. 前記情報蓄積部の蓄積データ領域は、放送事業者ごとの領域、放送事業者共用の領域に分けられ、さらに前記放送事業者の領域や放送事業者共用の領域は、ブロック（またはアイテム）の小領域に分けられている、
   請求項1記載のデジタルテレビ放送システム。
3. 受信機とサーバと送信機とが通信可能な状態で放送を行うデジタルテレビ放送方法であって、
   前記受信機は、
   前記送信機から送られてくる放送信号を受信し、
   鍵取得命令に基づいて、前記放送信号から又は通信回線を介して前記サーバから暗号化鍵を取得し、
   前記放送信号に含まれる書き込み命令に基づいて、前記暗号化鍵を使用して前記受信機にある受信機データを暗号化して暗号化付きデータを生成し、
   前記暗号化付きデータを情報蓄積部に書き込み可能であり、
   前記送信機は、
   アプリケーションデータ生成手段が、
   前記受信機に前記暗号化鍵を取得させるための前記鍵取得命令と、
   前記暗号化鍵を使用して前記暗号化付きデータを生成し、前記暗号化付きデータを前記情報蓄積部に書き込ませるための前記書き込み命令と、
   前記受信機の情報読み出し手段が前記情報蓄積部から前記暗号化付きデータを読み出すように命令する読み出し命令と、
   読み出した前記暗号化付きデータを前記サーバへ送信するように命令する送信命令と、を生成して前記放送信号に含ませる、デジタルテレビ放送方法。
4. 前記情報蓄積部の蓄積データ領域は、放送事業者ごとの領域、放送事業者共用の領域に分けられ、さらに前記放送事業者の領域や放送事業者共用の領域は、ブロック（またはアイテム）の小領域に分けられている、
   請求項３記載のデジタルテレビ放送方法。