(57)【要約】【課題】放送リソースを利用するアプリケーションを用いたサービスの品質の向上を図ることの可能な受信装置を提供する。【解決手段】放送番組と、この放送番組の少なくとも一部のシーンについて、当該シーン毎に時間的に対応して伝送され、前記放送番組に関連する関連情報を取得するために必要な情報を含むタグ情報とを含む放送信号を受信する放送受信部と、アプリケーションと、このアプリケーションの動作制御情報、およびこのアプリケーションが利用する関連情報を特定するための情報を含むタグ情報を特定するための識別情報が少なくとも記述されたアプリケーション情報テーブルをそれぞれ取得し、このテーブルをもとにアプリケーションの動作を制御するアプリケーション制御部と、受信された放送信号からアプリケーション情報テーブルに記述された識別情報をもとにタグ情報を取得し、このタグ情報をもとに関連情報を取得し、実行中のアプリケーションに供給するタグ情報処理部と具備する。【選択図】図６
2019036981.tif 000002
【特許請求の範囲】
【請求項１】
１以上のシーンで構成される放送番組と、この放送番組の少なくとも一部のシーンについて、当該シーン毎に時間的に対応して伝送され、前記放送番組に関連する関連情報を取得するために必要な情報を含むタグ情報とを含む放送信号を受信する放送受信部と、
前記関連情報を利用するアプリケーションと、このアプリケーションの動作を制御するための情報、およびこのアプリケーションが利用する関連情報を特定するための情報を含むタグ情報を特定するための識別情報が少なくとも記述されたアプリケーション情報テーブルをそれぞれ取得し、このアプリケーション情報テーブルをもとに前記アプリケーションの動作を制御するアプリケーション制御部と、
前記受信された放送信号から、前記アプリケーション情報テーブルに記述された識別情報をもとに前記タグ情報を取得し、このタグ情報をもとに前記関連情報を取得し、実行中の前記アプリケーションに供給するタグ情報処理部と
具備する受信装置。
【請求項２】
請求項１に記載の受信装置であって、
前記タグ情報は、前記関連情報の伝送チャンネルを識別するためのチャンネル識別情報を含み、
前記タグ情報処理部は、前記チャンネル識別情報により特定される伝送チャンネルから前記関連情報を取得するように構成される
受信装置。
【請求項３】
請求項１に記載の受信装置であって、
前記タグ情報は、前記関連情報のネットワーク上のロケーション情報を含み、
前記タグ情報処理部は、前記ロケーション情報をもとに前記関連情報を取得するように構成される
受信装置。
【請求項４】
請求項１に記載の受信装置であって、
前記アプリケーション情報テーブルには、前記アプリケーションから所定の演算によって求められた当該アプリケーションを代表する第１の代表値がさらに記述され、かつ電子署名が添付され、
前記アプリケーション制御部は、取得した前記アプリケーション情報テーブルに添付された前記電子署名を検証するように構成される
受信装置。
【請求項５】
１以上のシーンで構成される放送番組と、この放送番組の少なくとも一部のシーンについて、当該シーン毎に時間的に対応して伝送され、前記放送番組に関連する関連情報を取得するために必要な情報を含むタグ情報とを含む放送信号を送信する放送部
を具備する放送装置。
【請求項６】
請求項５に記載の放送装置であって、
前記送信部は、さらに当該シーン毎に時間的に対応して前記関連情報を放送するように構成される
放送装置。
【請求項７】
放送により伝送される放送番組の関連情報を利用するアプリケーションと、前記放送番組の少なくとも一部のシーンについて、当該シーン毎に時間的に対応して伝送され、前記放送番組に関連する関連情報を取得するために必要な情報を含むタグ情報を特定するための識別情報が少なくとも記述されたアプリケーション情報テーブルを格納する格納部と、
前記格納部に格納された前記アプリケーションおよびアプリケーション情報テーブルをユーザの受信端末からの要求に応じてネットワークを介して配信する配信部と
を具備するサーバ装置。
【請求項８】
放送受信部が、１以上のシーンで構成される放送番組と、この放送番組の少なくとも一部のシーンについて、当該シーン毎に時間的に対応して伝送され、前記放送番組に関連する関連情報を取得するために必要な情報を含むタグ情報とを含む放送信号を受信し、
アプリケーション制御部が、前記関連情報を利用するアプリケーションと、このアプリケーションの動作を制御するための情報、およびこのアプリケーションが利用する関連情報を特定するための情報を含むタグ情報を特定するための識別情報が少なくとも記述されたアプリケーション情報テーブルをそれぞれ取得し、このアプリケーション情報テーブルをもとに前記アプリケーションの動作を制御し、
タグ情報処理部が、前記受信された放送信号から、前記アプリケーション情報テーブルに記述された識別情報をもとに前記タグ情報を取得し、このタグ情報をもとに前記関連情報を取得し、実行中の前記アプリケーションに供給する
受信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、アプリケーション管理テーブルを用いてアプリケーションを実行することが可能な受信装置と、放送装置、サーバ装置および受信方法に関する。
【背景技術】
【０００２】
近年、放送コンテンツの再生と同時に、インターネット等のネットワークを通じて配信されるアプリケーションの実行を行うことを可能とする技術が知られている。このような技術として、ハイブリッドブロードバンド放送（Hybrid Broadcast Broadband TV、以下「ＨｂｂＴＶ」と称する。）と呼ばれる技術が知られている。ＨｂｂＴＶの標準規格として、欧州では「ETSI TS 102 796」（非特許文献１参照。）が策定されている。また、我が国でもこれに相当する標準規格「ARIB STD-B24（第4編）」（非特許文献２参照。）が策定されている。
【０００３】
例えばＨｂｂＴＶなどのように、放送コンテンツの再生と同時にアプリケーションが実行されるシステムでは、アプリケーションの起動から終了までのライフサイクルが、放送コンテンツに重畳されたＡＩＴセクション（Application Information Table）と呼ばれるデータ構造によって管理される。ＡＩＴセクションを取得した情報端末は、ＡＩＴセクションに含まれるアプリケーション制御用のコードをもとにアプリケーションの制御を行う。
【０００４】
また、放送ＡＩＴセクションと同等の情報を有し、インターネットなど通信網を利用して受信機にアプリケーションに関する情報を提供するために最適なフォーマットとして、ＸＭＬ形式で記述されたＸＭＬ−ＡＩＴがある。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】ETSI（European Telecommunications Standards Institute）「ETSI TS 102 796 V1.1.1 （2010-06)」http://www.etsi.org/deliver/etsi_ts/102700_102799/102796/01.01.01_60/ts_102796v010101p.pdf（平成２３年１０月２１日閲覧）
【非特許文献２】社団法人電波産業会「デジタル放送におけるデータ放送符号化方式と伝送方式、標準規格、ARIB STD-B24 5.8版」http://www.arib.or.jp/english/html/overview/doc/2-STD-B24v5_8-2p3-2.pdf（平成２５年７月３日閲覧）
【発明の概要】
【発明が解決しようとする課題】
【０００６】
今後、放送局以外の事業者、例えば端末メーカやサードパーティなどのアプリケーション事業者から、放送番組を何らかのかたちで利用するアプリケーションが提供されることが想定される。しかし、このようにアプリケーション事業者によって提供されるアプリケーションを利用したサービスを実際に運用するにあたっては、解決すべき様々な課題が未だ残されており、その対策が望まれている。
【０００７】
本技術の目的は、放送リソースを利用するアプリケーションを用いたサービスの品質の向上を図ることの可能な受信装置、放送装置、サーバ装置および受信方法を提供することにある。
【課題を解決するための手段】
【０００８】
上記の課題を解決するために、本技術に係る受信装置は、１以上のシーンで構成される放送番組と、この放送番組の少なくとも一部のシーンについて、当該シーン毎に時間的に対応して伝送され、前記放送番組に関連する関連情報を取得するために必要な情報を含むタグ情報とを含む放送信号を受信する放送受信部と、前記関連情報を利用するアプリケーションと、このアプリケーションの動作を制御するための情報、およびこのアプリケーションが利用する関連情報を特定するための情報を含むタグ情報を特定するための識別情報が少なくとも記述されたアプリケーション情報テーブルをそれぞれ取得し、このアプリケーション情報テーブルをもとに前記アプリケーションの動作を制御するアプリケーション制御部と、前記受信された放送信号から、前記アプリケーション情報テーブルに記述された識別情報をもとに前記タグ情報を取得し、このタグ情報をもとに前記関連情報を取得し、実行中の前記アプリケーションに供給するタグ情報処理部とを具備する。
【０００９】
前記受信装置において、前記タグ情報は、前記関連情報の伝送チャンネルを識別するためのチャンネル識別情報を含み、前記タグ情報処理部は、前記チャンネル識別情報により特定される伝送チャンネルから前記関連情報を取得するように構成されてもよい。
【００１０】
前記受信装置において、前記タグ情報は、前記関連情報のネットワーク上のロケーション情報を含み、前記タグ情報処理部は、前記ロケーション情報をもとに前記関連情報を取得するように構成されてもよい。
【００１１】
前記受信装置において、前記アプリケーション情報テーブルには、前記アプリケーションから所定の演算によって求められた当該アプリケーションを代表する第１の代表値がさらに記述され、かつ電子署名が添付され、前記アプリケーション制御部は、取得した前記アプリケーション情報テーブルに添付された前記電子署名を検証するように構成されてもよい。
【００１２】
本技術に係る放送装置は、１以上のシーンで構成される放送番組と、この放送番組の少なくとも一部のシーンについて、当該シーン毎に時間的に対応して伝送され、前記放送番組に関連する関連情報を取得するために必要な情報を含むタグ情報とを含む放送信号を送信する放送部を具備する。
【００１３】
本技術に係るサーバ装置は、放送により伝送される放送番組の関連情報を利用するアプリケーションと、前記放送番組の少なくとも一部のシーンについて、当該シーン毎に時間的に対応して伝送され、前記放送番組に関連する関連情報を取得するために必要な情報を含むタグ情報を特定するための識別情報が少なくとも記述されたアプリケーション情報テーブルを格納する格納部と、前記格納部に格納された前記アプリケーションおよびアプリケーション情報テーブルをユーザの受信端末からの要求に応じてネットワークを介して配信する配信部とを具備する。
【００１４】
本技術の別の観点に基づく受信方法は、放送受信部が、１以上のシーンで構成される放送番組と、この放送番組の少なくとも一部のシーンについて、当該シーン毎に時間的に対応して伝送され、前記放送番組に関連する関連情報を取得するために必要な情報を含むタグ情報とを含む放送信号を受信し、アプリケーション制御部が、前記関連情報を利用するアプリケーションと、このアプリケーションの動作を制御するための情報、およびこのアプリケーションが利用する関連情報を特定するための情報を含むタグ情報を特定するための識別情報が少なくとも記述されたアプリケーション情報テーブルをそれぞれ取得し、このアプリケーション情報テーブルをもとに前記アプリケーションの動作を制御し、タグ情報処理部が、前記受信された放送信号から、前記アプリケーション情報テーブルに記述された識別情報をもとに前記タグ情報を取得し、このタグ情報をもとに前記関連情報を取得し、実行中の前記アプリケーションに供給する。
【発明の効果】
【００１５】
以上のように、本技術によれば、放送リソースを利用するアプリケーションを用いたサービスの品質の向上を図ることができる。
【図面の簡単な説明】
【００１６】
【図１】本実施形態の情報処理システムの概要を示す図である。
【図２】本実施形態のＸＭＬ−ＡＩＴのデータ構造を示す図である。
【図３】アプリケーションモード記述子１２１のデータ構造を示す図である。
【図４】アプリケーションハッシュ記述子１２２のデータ構造を示す図である。
【図５】ＸＭＬ−ＡＩＴに格納されるアプリケーション制御コード（controlCode）２３の定義を示す図である。
【図６】本実施形態の受信端末３２の構成を示すブロック図である。
【図７】受信端末３２においてシーン毎のアフィリエイトタグおよびアフィリエイトインフォの取得の流れを示す図である。
【図８】ＸＭＬ−ＡＩＴ、アプリケーション、アフィリエイトタグ、アフィリエイトインフォの関係を示す図である。
【図９】セクション形式で伝送されるアフィリエイトタグのデータ構造を示す図である。
【図１０】伝送プロトコル記述子（transport_protocol_descriptor）のデータ構造を示す図である。
【図１１】データカルーセル伝送のセレクタバイトのデータ構造を示す図である。
【図１２】伝送プロトコルがＨＴＴＰ／ＨＴＴＰＳである場合のセレクタバイトのデータ構造を示す図である。
【図１３】アフィリエイトタグをＸＭＬ形式のファイルとして、データカルーセル方式またはＦＬＵＴＥにより伝送する場合のフォーマットの例である。
【図１４】アフィリエイトインフォを取得するためのＨＴＴＰＳ Ｐｏｓｔリクエストの例である。
【図１５】電子署名およびハッシュ値の生成と検証の仕組みについて説明するためのブロック図である。
【発明を実施するための形態】
【００１７】
以下、本技術の実施の形態を図面をもとに説明する。
＜第１の実施形態＞
［情報処理システム］
図１は、本実施形態の情報処理システム１の概要を示す図である。
本実施形態の情報処理システム１には、エンティティとして、放送事業者１０、アプリケーション事業者２０、ユーザ３０が存在する。
【００１８】
放送事業者１０は、放送局１２とアフィリエイトインフォサーバ１４を有する。
放送局１２は、放送設備を有し、例えば、地上波、衛星波、ＩＰ（Internet Protocol）ネットワークなどの通信媒体を介してデジタル放送信号を送信する。放送局１２は、映像、音声、字幕などの各トランスポートストリームが多重化されたＡＶストリームと、ＡＶストリームに付随するデータなどとが重畳されたいわゆる放送ストリームを送出する。ＡＶストリームに付随するデータとしては、例えば、ＡＦＴ（Affiliate Tag Table）、ＦＬＵＴＥ、データカルーセルなどがある。
【００１９】
アフィリエイトインフォサーバ１４は、ユーザ３０の受信端末３２において実行されるアプリケーションによって利用され、放送番組のシーンに関連する情報であるアフィリエイトインフォを蓄積する。アフィリエイトインフォサーバ１４は、ユーザ３０の受信端末３２からのリクエストに対して該当するアフィリエイトインフォをネットワークを通じて応答するように構成される。
【００２０】
アプリケーション事業者２０は、アプリケーション／ＡＩＴ生成装置２２とアプリケーション／ＡＩＴサーバ２４を備える。
【００２１】
アプリケーション／ＡＩＴ生成装置２２は、アプリケーションと、このアプリケーションの動作を制御するための情報が記述されたＸＭＬ−ＡＩＴ（Extensible Markup Language-Application Information Table）の生成等を行う装置である。アプリケーション／ＡＩＴ生成装置２２は、より具体的にはパーソナルコンピュータなどの計算機と、この計算機上で実行されるプログラムで構成される。
【００２２】
アプリケーション／ＡＩＴサーバ２４は、アプリケーション／ＡＩＴ生成装置２２によって生成され、アプリケーション事業者２０によって電子署名が付与されたアプリケーションとＸＭＬ−ＡＩＴのファイルを蓄積する格納部２４１と、ユーザ３０の受信端末３２からのリクエストに対して該当するアプリケーションとＸＭＬ−ＡＩＴのファイルをネットワークを通じて配信する配信部２４２とを有する。
【００２３】
なお、アプリケーション／ＡＩＴサーバ２４は、アプリケーションサーバとＡＩＴサーバの２つのサーバで構成されてもよい。アプリケーション／ＡＩＴサーバ２４は、それぞれＣＰＵ、メインメモリ、データ記憶装置、ユーザインタフェースなど、典型的なコンピュータのハードウェア構成と、それぞれのサーバ用のプログラムとで構成される。
【００２４】
ユーザ３０の受信端末３２は、例えば、パーソナルコンピュータ、携帯電話、スマートフォン、テレビジョン装置、ゲーム機、タブレット端末、オーディオ・ビデオ再生機器などであるが、具体的に製品形態は問わない。
【００２５】
ユーザ３０の受信端末３２は、放送局１２からデジタル放送信号を受信し、復調してトランスポートストリームを得る。受信端末３２は、このトランスポートストリームから放送ストリームを分離し、デコードして受信端末３２にそれぞれ搭載されるあるいはそれぞれ接続される表示部（図示せず）及びスピーカ部（図示せず）や、記録装置（図示せず）に出力することが可能である。
【００２６】
また、ユーザ３０の受信端末３２は、アプリケーション／ＡＩＴサーバ２４からＸＭＬ−ＡＩＴのファイルおよびアプリケーションを取得する。より具体的には、受信端末３２は、まず、ＸＭＬ−ＡＩＴのファイルを取得し、このＸＭＬ−ＡＩＴに記述されたアプリケーションの置き場所を示すＵＲＬをもとにアプリケーションを取得するように構成される。
【００２７】
なお、上記の説明では、アフィリエイトインフォのファイルをアフィリエイトインフォサーバ１４に配置し、ネットワークを通じて受信端末３２に伝送することとしたが、放送によりアフィリエイトインフォを受信端末３２に伝送してもよい。放送によりアフィリエイトインフォなどのファイルを伝送するためのプロトコルとして、例えば、ＩＰマルチキャスト環境におけるファイルデリバリーのプロトコルであるＦＬＵＴＥ（File Delivery over Unidirectional Transport）、データカルーセルなどがある。
【００２８】
［アプリケーション］
ここで、アプリケーション事業者２０から提供されるアプリケーションについて説明を補足する。アプリケーションは、例えばＨＴＭＬ（Hyper Text Markup Language）文書、ＢＭＬ文書（Broadcast Markup Language）、ＭＨＥＧ文書（Multimedia and Hypermedia information coding）、Ｊａｖａ（登録商標）スクリプト、静止画ファイル、動画ファイルなどで構成される。
【００２９】
アプリケーションは可視的なものであっても不可視的なものであってもよい。可視的なアプリケーションとは、画面を通じてその状態をユーザが視ることのできるアプリケーションである。不可視的なアプリケーションは、画面を通じてその状態をユーザが視ることのできないアプリケーションである。また、アプリケーションは、受信端末３２へのユーザによる操作に従って提示する情報や機能を変えることができる双方向型アプリケーションでもよいし、ユーザに対して一方向に情報を提示するアプリケーションでもよい。
【００３０】
［ＸＭＬ−ＡＩＴのデータ構造］
次に、本実施形態で採用されるＸＭＬ−ＡＩＴのデータ構造について説明する。
図２は、本実施形態のＸＭＬ−ＡＩＴのデータ構造を示す図である。
ＸＭＬ−ＡＩＴには、アプリケーション毎の、アプリケーション名（app_Name）、アプリケーション識別子（application_Iidentifier）、アプリケーション記述子（application_Descriptor）、アプリケーションタイプ（type）、アプリケーション制御コード（control_Code）１２３、アプリケーションの可視性（visibility）、現在のサービス内でのみ有効かを示すフラグ（service_Bound）、アプリケーションの優先度（priority）、アプリケーションのバージョン（version）、プラットフォームプロファイルにあわせたバージョン（mhp_Version）、アイコン（icon）、ストレージ機能の性能（storage_Capability）、トランスポートプロトコル記述子（application_Transport）、アプリケーションロケーション記述子（application_Location）、アプリケーションバウンダリ記述子（application_Boundary）、アプリケーションスペシフィック記述子（application_Specific_Descriptor）、アプリケーションユーセジ記述子（application_Usage_Descriptor）、アプリケーションモード記述子（application_Mode_Descriptor）１２１、アプリケーションハッシュ記述子（application_Hash_Descriptor）１２２などが格納される。
【００３１】
このＸＭＬ−ＡＩＴには、改ざんを検出するための電子署名が添付される。電子署名としては、例えばＸＭＬ署名などが用いられる。ＸＭＬ署名の形式は、ＸＭＬ−ＡＩＴに対して独立したdetached署名、ＸＭＬ−ＡＩＴを包含した形式を有するenveloping署名、ＸＭＬ−ＡＩＴに包含された形式のenveloped署名のいずれであるかを問わない。なお、ＸＭＬ−ＡＩＴのフォーマットへの影響を抑えるにはdetached署名を採用するのがよい。
【００３２】
本実施形態で採用されるＸＭＬ−ＡＩＴには、アプリケーションのモードを示す記述子であるアプリケーションモード記述子（Application Mode Descriptor）１２１が設けられている。
【００３３】
図３はアプリケーションモード記述子１２１のデータ構造を示す図である。
アプリケーションモード記述子１２１は、アプリケーションモード記述子１２１を識別する記述子タグ（descriptor_tag）、記述子長（descriptor_length）、アプリケーションのモードを示すアプリケーションモード（application_mode）、アフィリエイトタグ数（number_of_affilate_tag）、アフィリエイトタグＩＤ（affiliate_tag_id）などで構成される。
【００３４】
アプリケーションモードは、アプリケーションが利用できる機能（ＡＰＩ：Application Program Interface）を制御するための情報である。アプリケーションによって利用が制限される機能としては、例えば、放送の番組やデータなどの様々な放送リソースにアクセスして提示する放送リソース提示機能などがある。より詳細には、放送リソースにアクセスするアプリケーションは、その放送リソース提示機能を利用できるようにアプリケーションモードの値が設定され、放送リソースにアクセスしないアプリケーションは、その放送リソース提示機能を利用できないようにアプリケーションモードの値が設定される。なお、アプリケーションモードによって、利用できるかどうかが切り替えられる機能は放送リソース提示機能に限られない。
【００３５】
放送リソースにアクセスするアプリケーションに対して設定されるアプリケーションモードを"mode1"、放送リソースにアクセスしないアプリケーションに対して設定されるアプリケーションモードを"mode2"とした場合を想定する。
この想定においては、アプリケーションモードは、受信端末３２において電子署名の検証の要否を知るための情報として利用することができる。すなわち、受信端末３２はアプリケーションモードが"mode1"であるとき電子署名の検証が不要と判定し、"mode2"であるとき電子署名の検証が必要であることを判定する。但し、これは１つの運用形態に過ぎず、放送リソースにアクセスするアプリケーションについても電子署名の検証を必要とすることとしてもよい。
【００３６】
アフィリエイトタグ数は、アフィリエイトタグの総数を示す。
アフィリエイトタグＩＤは、放送により配信される各々のアフィリエイトタグに割り当てられた識別情報である。アフィリエイトタグについては後で詳細に説明する。
【００３７】
図４は、アプリケーションハッシュ記述子１２２のデータ構造を示す図である。
アプリケーションハッシュ記述子１２２は、記述子タグ（descriptor_tag）、記述子長（descriptor_length）、ハッシュ値の計算方法を示すハッシュアルゴリズム（hash_algorithm）、ハッシュ値長（hash_value_length）、ハッシュ値（hash_value_byte）などで構成される。ハッシュ値は、アプリケーションのハッシュ値であり、所定のハッシュ関数などによってアプリケーションの実体から生成された値であり、そのアプリケーションを代表する値と言うことができる。このハッシュ値の利用方法については後で説明する。
【００３８】
［アプリケーション制御コードの定義］
アプリケーションのライフサイクルは、ＸＭＬ−ＡＩＴに格納されるアプリケーション制御コード１２３をもとに、受信端末によって動的に制御される。
【００３９】
図５はＸＭＬ−ＡＩＴに格納されるアプリケーション制御コード（controlCode）１２３の定義を示す図である。
同図に示すように、アプリケーション制御コードとしては、"AUTOSTART"、"PRESENT"、"DESTROY"、"KILL"、"PREFETCH"、"REMOTE"、"DISABLED"、"PLAYBACK_AUTOSTART"が標準規格上存在する。これらアプリケーション制御コードの定義は以下のとおりである。
【００４０】
"AUTOSTART"は、サービスの選択に伴いアプリケーションを自動で起動することを指示するコードである。アプリケーションが既に実行されている場合にはこの限りでない。
"PRESENT"は、サービスが選択されている間、アプリケーションを実行可能な状態とすることを指示するコードである。但し、対象のアプリケーションは、サービスの選択に伴って自動的にアプリケーションは起動されず、ユーザからの起動の指示を受けて起動される。
"DESTROY"は、アプリケーションの終了の許可を指示するコードである。
"KILL"は、アプリケーションの強制的な終了を指示するコードである。
"PREFETCH"は、アプリケーションのキャッシュを指示するコードである。
"REMOTE"は、現在のトランスポートストリームでは取得できないアプリケーションであることを示すコードである。そのアプリケーションは、別のトランスポートストリームあるいはキャッシュから取得して利用可能となる。
"DISABLED"は、アプリケーションの起動を禁止することを示すコードである。
"PLAYBACK_AUTOSTART"は、ストレージ（記録装置）に録画された放送コンテンツの再生に伴いアプリケーションを起動させるためのコードである。
【００４１】
［システム全体の大まかな動作例］
次に、システム全体の大まかな動作の流れの一例を図１を参照して説明する。
１．まず、アプリケーション事業者２０のアプリケーション／ＡＩＴ生成装置２２において、アプリケーションとこのアプリケーションの動作を制御するためのＸＭＬ−ＡＩＴが生成される。生成されたアプリケーションとＸＭＬ−ＡＩＴはアプリケーション事業者２０から放送事業者１０にその内容を確認してもらうために送られる。
【００４２】
２．放送事業者１０（放送局１２）は、アプリケーション事業者２０より供給されたアプリケーションとＸＭＬ−ＡＩＴについて、予め決められた評価基準に従ってこれらの利用を許可できるかどうかを確認する。放送事業者１０（放送局１２）は、問題が無ければ、アプリケーションとＸＭＬ−ＡＩＴのそれぞれに放送局１２の秘密鍵を用いて生成された電子署名を付与する。電子署名が付与されたアプリケーションとＸＭＬ−ＡＩＴはアプリケーション事業者２０に送り戻される。
【００４３】
３．アプリケーション事業者２０は、これらのアプリケーションとＸＭＬ−ＡＩＴをアプリケーション／ＡＩＴサーバ２４に配置し、受信端末３２からネットワークを介してアクセス可能な状態にする。
【００４４】
なお、アプリケーション事業者２０と放送事業者１０（放送局１２）との間でのアプリケーションおよびＸＭＬ−ＡＩＴの受け渡しはネットワークを通じて行ってもよいし、電子データを記録可能な記録媒体の受け渡しにより行われてもよい。
【００４５】
４．一方、放送事業者１０（放送局１２）は、アフィリエイトインフォ（affiliate_info）のファイルを生成し、アフィリエイトインフォサーバ１４に受信端末３２によってアクセス可能な状態で配置する。ここで、アフィリエイトインフォとは、放送番組の少なくとも一部のシーンについて、そのシーンに時間的に対応して、受信端末３２において実行中のアプリケーションによって利用される、放送番組に関連した情報が格納されるデータ構造である。なお、アフィリエイトインフォ（affiliate_info）の具体的なデータ構造は放送事業者１０により任意に決定される。
【００４６】
アフィリエイトインフォ（affiliate_info）に格納されることが想定される関連情報としては、例えば、次のようなものがある。
ａ．放送番組のシーンに登場する人、物、店などのオブジェクトに関する詳細情報。
ｂ．そのオブジェクトの詳細情報をアクセスするための情報。
ｃ．シーンに関連する座標位置情報（ニュースの現場の場所、ドラマのシーン位置など）。
ｄ．ＥＰＧ相当の番組情報。
ｅ．シーンやカットの代表的な映像や縮小映像。
ｆ．番組の台詞やナレーションなど、番組中の発話を時系列にテキスト化したデータ。
ｇ．その他、放送事業者１０が所有する情報。
【００４７】
一方、アプリケーションは、上記の関連情報を用いて処理を行い、処理結果を出力する。アプリケーションとしては、例えば次のようなものが想定される。
Ａ．上記ａのオブジェクトの詳細情報を取得し、シーン中でユーザがポインタを使って指示した人、物、店などのオブジェクトの詳細情報を画面に表示させるアプリケーション。
Ｂ．上記ｂのアクセス情報を取得し、シーン中でユーザがポインタを使って指示した人、物、店などのオブジェクトの詳細情報にアクセス情報をもとにアクセスし、画面に表示させるアプリケーション。
Ｃ．上記ｃの座標位置情報を取得し、この座標位置情報が示す位置をマップ上に表示することによって、ニュースの現場の場所や、ドラマのシーン位置などをユーザに提示するアプリケーション。
Ｄ．上記ｄのＥＰＧ相当の番組情報を取得し、番組情報をもとにウェブを対象に検索を行って関連するウェブページを表示するアプリケーション。
Ｅ．上記ｅのシーンやカットの代表的な映像や縮小映像を時間順に一覧表示するアプリケーション。
Ｆ．上記ｆの番組中の発話を時系列にテキスト化したデータを取得し、時間順に一覧表示したり、一覧表示された発話テキスト化データの中からユーザにより選択されたデータをもとにウェブを対象に検索を行って関連するウェブページを表示するアプリケーション。
その他、アプリケーションとしては様々なものが想定される。
【００４８】
システム全体の動作の流れの説明に戻る。
５．放送局１２は、放送局１２の秘密鍵に対応する公開鍵が格納された証明書を放送する。証明書の放送には、例えばデータカルーセル方式などが用いられる。
【００４９】
６．受信端末３２は、例えば、ユーザ３０から放送番組に対応するアプリケーション実行指示を受けることによって、アプリケーション／ＡＩＴサーバ２４からその放送番組に対応するＸＭＬ−ＡＩＴを取得する。受信端末３２は、さらにそのＸＭＬ−ＡＩＴに記述されたアプリケーションのロケーション情報をもとにアプリケーション／ＡＩＴサーバ２４からアプリケーションを取得する。さらに、受信端末３２は、放送信号から証明書を取得し、この証明書に格納された公開鍵を用いてＸＭＬ−ＡＩＴの電子署名の検証を行い、検証に成功すると、取得したアプリケーションを信頼できるアプリケーションとして位置付ける。
【００５０】
７．放送局１２は、放送番組の少なくとも一部のシーン（上記のアフィリエイトインフォ（affiliate_info）が関連付けられた各々のシーン）に時間的に対応してアフィリエイトタグ（affiliate_tag）を例えばデータカルーセル方式で放送する。
【００５１】
８．受信端末３２は、取得したＸＭＬ−ＡＩＴに記述されたアフィリエイトタグＩＤに一致するアフィリエイトタグを放送信号から検出し、これを取得する。
【００５２】
９．受信端末３２は、取得したアフィリエイトタグに記述された、例えば、アフィリエイトインフォのファイルのロケーション情報などをもとに、アフィリエイトインフォサーバ１４にアクセスして目的のアフィリエイトインフォを取得する。
【００５３】
１０．受信端末３２は、取得したアフィリエイトインフォに格納された関連情報をアプリケーションに供給する。これにより、アプリケーションにおいて放送番組のシーンに対応する関連情報を用いた処理が実行される。
【００５４】
なお、この動作例では、アフィリエイトインフォサーバ１４からアフィリエイトインフォのファイルを取得することとしたが、放送信号から伝送されるアフィリエイトインフォを取得するようにしてもよい。この場合、アフィリエイトタグには、アフィリエイトインフォを取得するために必要な情報として、放送チャンネルを特定する情報が記述される。
以上が、システム全体の大まかな動作の説明である。
【００５５】
次に、受信端末３２の構成について説明し、続いて情報処理システム１の動作の詳細を説明する。
【００５６】
［受信端末３２の構成］
図６は本実施形態の受信端末３２の構成を示すブロック図である。
受信端末３２は、放送インタフェース３２１、デマルチプレクサ３２２、ビデオデコーダ３２３、オーディオデコーダ３２４、証明書受信処理部３２５、アフィリエイト処理部３２６、アプリケーション制御部３２７、通信インタフェース３２８、アプリケーションエンジン３２９、および映像合成部３３０を有する。
【００５７】
放送インタフェース３２１は、アンテナ及びチューナを有し、これらを用いてユーザにより選局されたデジタル放送信号を受信する。放送インタフェース３２１は、受信したデジタル放送信号に対して復調処理などを施して得たトランスポートストリームをデマルチプレクサ３２２に出力する。
【００５８】
デマルチプレクサ３２２は、ＴＳ（トランスポートストリーム）に多重化されたビデオ、オーディオ、セクション形式のデータであるアフィリエイトタグ、証明書を分離する。すなわち、デマルチプレクサ３２２は、ＴＳを構成するＴＳパケットに含まれるＰＩＤ（Packet ID）を参照し、ストリーム形式のＴＳパケットのうちビデオのＥＳ（エレメンタリストリーム）をビデオデコーダ３２３に出力し、オーディオストリームのＥＳをオーディオデコーダ３２４に出力する。また、セクション形式のデータが格納されたＴＳパケットのうち、アフィリエイトタグの格納されたパケットをアフィリエイト処理部３２６に出力し、さらに、証明書が格納されたパケットを証明書受信処理部３２５に出力する。
【００５９】
ビデオデコーダ３２３は、ビデオのＥＳをデコードして映像信号を生成し、生成した映像信号を映像合成部３３０に出力する。
【００６０】
オーディオデコーダ３２４は、オーディオのＥＳをデコードして音声信号を生成し、生成した音声信号を図示しない出力処理部に出力する。
【００６１】
証明書受信処理部３２５は、デマルチプレクサ３２２によってトランスポートストリームから分離された証明書のパケットから証明書のデータを抽出してアプリケーション制御部３２７に供給する。
【００６２】
アプリケーション制御部３２７は、ＸＭＬ−ＡＩＴに従って、アプリケーションエンジン３２９においてアプリケーションの起動、停止などの制御を行う。アプリケーション制御部３２７は、アプリケーションの動作制御情報であるＸＭＬ−ＡＩＴを、通信インタフェース３２８を使ってアプリケーション事業者２０のアプリケーション／ＡＩＴサーバ２４から取得する。アプリケーション制御部３２７は、取得したＸＭＬ−ＡＩＴに記述されているロケーション情報をもとに、所望の放送番組に関連するアプリケーションを、通信インタフェース３２８を使ってアプリケーション事業者２０のアプリケーション／ＡＩＴサーバ２４から取得し、アプリケーションエンジン３２９において起動させるように制御する。
【００６３】
アプリケーションエンジン３２９は、１以上のアプリケーションを実行させるためのプラットフォームであり、具体的には、例えばＨＴＭＬ（HyperText Markup Language）ブラウザなどである。アプリケーションエンジン３２９において実行中のアプリケーションは、アフィリエイト処理部３２６に対して、ＸＭＬ−ＡＩＴに記述されたアフィリエイトタグＩＤに一致するアフィリエイトタグを放送信号から検出して取得するように指示する。アプリケーションは、アフィリエイト処理部３２６からアフィリエイトタグの取得完了の応答を受けると、続いてアフィリエイトインフォを取得するようにアフィリエイト処理部３２６に指示する。そして、アプリケーションエンジン３２９において実行中のアプリケーションは、アフィリエイト処理部３２６によって取得されたアフィリエイトインフォに格納された関連情報を用いて所定の処理を行う。
【００６４】
アフィリエイト処理部３２６は、デマルチプレクサ３２２によってトランスポートストリームから分離されたアフィリエイトタグのパケットから、ＸＭＬ−ＡＩＴに記述されたアフィリエイトタグＩＤに一致するアフィリエイトタグを検出する。アフィリエイト処理部３２６は、検出されたアフィリエイトタグに記述された、アフィリエイトインフォを取得するための情報をもとに、アフィリエイトインフォサーバ１４もしくは放送信号からアフィリエイトインフォを取得し、アプリケーションエンジン３２９において実行中のアプリケーションに応答するように構成されている。
【００６５】
通信インタフェース３２８は、ネットワーク２００を通じて外部の機器と通信を行うためのインタフェースである。通信インタフェース３２８は無線による通信、有線による通信を問わない。
【００６６】
映像合成部３３０は、ビデオデコーダ３２３からの映像信号、アプリケーションエンジン３２９において実行中のアプリケーションによって生成された表示データを合成し、例えば、受信端末３２に接続された記録装置（図示せず）、表示部及びスピーカ部（図示せず）に出力する。
【００６７】
上記の受信端末３２の少なくとも証明書受信処理部３２５、アフィリエイト処理部３２６、アプリケーション制御部３２７、アプリケーションエンジン３２９を含む構成の少なくとも一部は、ＣＰＵ（Central Processing Unit）およびメモリを有するコンピュータと、このコンピュータを受信端末３２としてとして機能させるプログラムとにより構成される。
【００６８】
［受信端末３２の動作］
次に、本実施形態の受信端末３２の動作の詳細を説明する。
図７は受信端末３２においてシーン毎のアフィリエイトタグおよびアフィリエイトインフォの取得の流れを示す図である。
図８はＸＭＬ−ＡＩＴ、アプリケーション、アフィリエイトタグ、アフィリエイトインフォの関係を示す図である。
【００６９】
例えば、ユーザ３０から視聴中の放送番組に対応するアプリケーション実行指示を受けると、アプリケーション制御部３２７は、通信インタフェース３２８を使ってアプリケーション事業者２０のアプリケーション／ＡＩＴサーバ２４にアクセスし、目的のアプリケーションの動作制御情報であるＸＭＬ−ＡＩＴを取得する。
【００７０】
アプリケーション制御部３２７は、取得したＸＭＬ−ＡＩＴに記述されているアプリケーションのロケーション情報（例えばApp_URL）をもとにアプリケーション／ＡＩＴサーバ２４から目的のアプリケーションを取得し、ハッシュ値及び電子署名の検証を行う。なお、ハッシュ値の検証及び電子署名の検証の詳細については後で説明する。ハッシュ値及び電子署名の検証に成功した場合、アプリケーション制御部３２７は、ＸＭＬ−ＡＩＴに記述されたアプリケーション制御コードに従って、そのアプリケーションをアプリケーションエンジン３２９の上で起動させる。
【００７１】
次に、アプリケーションエンジン３２９において実行中のアプリケーション（例えば図７のApp1またはApp2）は、アフィリエイト処理部３２６に対して、ＸＭＬ−ＡＩＴに記述されたアフィリエイトタグＩＤに一致するアフィリエイトタグを、放送信号から検出するように指示する（図８：Affiliate_Tag検出開始）。
【００７２】
アフィリエイト処理部３２６は、デマルチプレクサ３２２によってトランスポートストリームから分離されたアフィリエイトタグのパケットから、ＸＭＬ−ＡＩＴに記述されたアフィリエイトタグＩＤに一致するアフィリエイトタグを検出する。
【００７３】
実行中のアプリケーションは、アフィリエイト処理部３２６に対してアフィリエイトタグの取得の完了を周期的に問い合わせる（図８：Affiliate_Tag取得確認）。実行中のアプリケーションは、アフィリエイト処理部３２６から取得完了の通知を受けると、続いてアフィリエイトインフォの取得をするようにアフィリエイト処理部３２６に指示する。アフィリエイト処理部３２６は、この指示に従って、アフィリエイトタグに記述された、アフィリエイトインフォを取得するための情報（図８：Affiliate_tokenまたはAffiliate_URI）をもとに、アフィリエイトインフォサーバ１４もしくは放送信号からアフィリエイトインフォを取得する（図８：Affiliate_info取得）。
【００７４】
図８に示すように、アフィリエイトタグには、アフィリエイトインフォを取得するための情報として、アフィリエイトインフォサーバ１４に格納されたアフィリエイトインフォのファイルを取得するための情報（図８：Affiliate_token、Affiliate_URI）、またはアフィリエイトインフォが放送信号で伝送されるチャンネル情報（図８：original_network_id、transport_stream_id、service_id）などがある。
【００７５】
アフィリエイトタグの伝送方法には、
１．セクション形式のアフィリエイトタグ（ＡＦＴ：Affiliate_tag_Table）を伝送する方法。
２．データカルーセル、ＦＬＵＴＥによるファイル形式のアフィリエイトタグを伝送する方法。
３．例えばＭＰＥＧ２ Ｖｉｄｅｏのユーザデータ領域、Ｈ２６４のＳＥＩなどのビデオデータにバイナリ形式のアフィリエイトタグを埋め込んで伝送する方法。
などがある。
【００７６】
［アフィリエイトタグ（affiliate_tag）のデータ構造］
ここで、アフィリエイトタグのデータ構造について説明する。
図９はセクション形式で伝送されるアフィリエイトタグのデータ構造を示す図である。
【００７７】
セクション形式で伝送されるアフィリエイトタグ（affiliate_tag）には、テーブルＩＤ（table_id）、セクションシンタックス識別子（section_syntax_indicator）、将来利用のための予約（reserved_future_use）、予約（reserved）、セクション長（section_length）、アフィリエイトタグＩＤ（affiliate_tag_id）、バージョン番号（version_number）、カレントネクスト指示（current_next_indicator）、セクション番号（section_number）、最後セクション番号（last_section_number）、アフィリエイトトークンフラグ（affiliate_token_flag）、アフィリエイトトークン（affiliate_token）、追加の記述子長（descriptor_loop_length）、および追加の記述子（descriptor）などが記述される。
【００７８】
アフィリエイトタグのテーブルＩＤには、アフィリエイトタグテーブルであることを一意に識別可能なＩＤが記述される。アフィリエイトタグＩＤは各々のアフィリエイトタグを識別するためのＩＤである。
【００７９】
アフィリエイトトークンフラグは、アフィリエイトトークンの有無を示すフラグである。
アフィリエイトトークンは、アフィリエイトタグＩＤに対応する秘密コードである。この秘密コードは、アフィリエイトインフォサーバ１４において、どのアフィリエイトインフォに対するアクセス要求であるかを一意に判別することができるように決められた情報である。
【００８０】
なお、セキュリティの強化のため、アフィリエイトインフォのファイルをアフィリエイトインフォサーバ１４から取得するための情報としてはアフィリエイトトークンを用いることが望ましいが、本技術においては、少なくとも、アフィリエイトインフォを取得するための情報であればよい。例えば、ＵＲＬのような一般的なロケーション情報であってもよい。また、データカルーセル方式やＦＬＵＴＥによって放送されるアフィリエイトインフォのファイルを取得する場合には、アフィリエイトトークンフラグによりアフィリエイトトークンが無いことをアフィリエイトタグに明示し、original_network_id、transport_stream_id、service_idなどで構成される伝送チャンネル情報をアフィリエイトインフォを取得するための情報として記述することができる。
【００８１】
追加の記述子（descriptor）には、例えば、伝送プロトコル記述子（transport_protocol_descriptor）などを目的に応じて記述できる。
【００８２】
図１０は、上記の伝送プロトコル記述子（transport_protocol_descriptor）のデータ構造を示す図である。
伝送プロトコル記述子は、伝送プロトコル記述子タグ（descriptor_tag）、伝送プロトコル記述子長（descriptor_length）、プロトコルＩＤ（protocol_id）、伝送プロトコルラベル（transport_protocol_label）およびセレクタバイト（selector_byte）を含む。
【００８３】
伝送プロトコル記述子タグは、アフィリエイトインフォを伝送するプロトコルを示す。伝送プロトコルとしては、例えばＨＴＴＰ（Hypertext Transfer Protocol）／ＨＴＴＰＳ（Hypertext Transfer Protocol Secure）、データカルーセル伝送、ＦＬＵＴＥなどがある。
【００８４】
セレクタバイトは、プロトコルＩＤ毎にシンタックスが規定される領域である。
【００８５】
図１１は、データカルーセル伝送のセレクタバイトのデータ構造を示す図である。
このデータカルーセル伝送のセレクタバイトは、リモートコネクション（remote_connection）、予約（reserved_future_use）、オリジナルネットワークＩＤ（original_network_id）、トランスポートＩＤ（transport_stream_id）、サービスＩＤ（service_id）、およびコンポーネントタグ（component_tag）を含む。
【００８６】
リモートコネクションは、アフィリエイトタグとアフィリエイトインフォが同じチャンネルで伝送されるかどうかを示す値である。
【００８７】
オリジナルネットワークＩＤ、トランスポートＩＤ、サービスＩＤはアフィリエイトインフォが伝送されるチャンネルを示す情報である。そして、コンポーネントタグは、そのチャンネルのどのストリームがアフィリエイトインフォであるかを示す値である。
【００８８】
図１２は、伝送プロトコルがＨＴＴＰ／ＨＴＴＰＳである場合のセレクタバイトのデータ構造を示す図である。
このセレクタバイトには、１つ以上のＵＲＬを記述することができる。
【００８９】
図１３はアフィリエイトタグをＸＭＬ形式のファイルとして、データカルーセル方式またはＦＬＵＴＥにより伝送する場合のフォーマットの例である。
【００９０】
図１４は、アフィリエイトインフォを取得するためのＨＴＴＰＳ Ｐｏｓｔリクエストの例である。
この例では、アフィリエイトトークンはＨＴＴＰＳ Ｐｏｓｔリクエストのボディ部に格納される。ＳＳＬ（Transport Layer Security）ではボディ部が暗号化されるので、アフィリエイトトークンを安全に伝送することができる。
【００９１】
ボディ部には、さらに、ＸＭＬ−ＡＩＴに記述された事業者ＩＤ（Organization_id）と、アプリケーション識別子（Application_Iidentifier）と、デバイス識別子（Affiliate_device）とが記述される。これにより、放送リソースを利用したアプリケーション事業者、アプリケーション、受信端末をログとしてアフィリエイトインフォサーバ１４に記録することができ、アプリケーション事業者、ユーザ等に対する従量課金などに利用することができる。
【００９２】
（電子署名およびハッシュ値の生成と検証）
次に、電子署名およびハッシュ値の生成と検証について説明する。
図１５は電子署名およびハッシュ値の生成と検証の仕組みについて説明するためのブロック図である。
【００９３】
アプリケーション／ＡＩＴサーバ２４は、ＡＩＴ生成部３５０を有する。ＡＩＴ生成部３５０は、具体的にはメインメモリにロードされた、電子署名およびハッシュ値の生成を行うプログラムと、このプログラムを実行するＣＰＵとで実現される。
【００９４】
ＡＩＴ生成部３５０は、以下の処理を行う。
１．ＡＩＴ生成部３５０は、アプリケーション３５１の実体（バイナリコード）から所定のハッシュ演算器３５２を用いてハッシュ値３５３を算出する。ハッシュのアルゴリズムとしては、例えばFIPS PUB 180-1,180-2で標準規格化されているSHA-1やSHA-2などがある。
【００９５】
２．ＡＩＴ生成部３５０は、当該アプリケーション３５１のＸＭＬ−ＡＩＴにハッシュ値３５３を合成（３５４）して、ハッシュ値付きのＸＭＬ−ＡＩＴ３５５を生成する。
【００９６】
３．ＡＩＴ生成部３５０は、アプリケーション３５１とＸＭＬ−ＡＩＴ３５５について放送局ＣＡ（Certificate Authority）８００に対して認証を依頼する。
放送局ＣＡ８００は、放送局１２から、放送リソースの利用に関する認証業務の依頼を受けてその業務を遂行する。放送局ＣＡ８００は、アプリケーション事業者２０より依頼された認証の対象であるアプリケーション３５１とＸＭＬ−ＡＩＴ３５５の内容をチェックし、その内容に問題がなければ、ルートＣＡ９００より発行された秘密鍵と公開鍵のペアのうち秘密鍵を署名生成鍵として署名生成器３５６に設定する。署名生成器３５６はハッシュ値付きのＸＭＬ−ＡＩＴ３５５に対して署名用のハッシュ関数を用いてダイジェストを生成し、このダイジェストを署名生成鍵（秘密鍵）３５７で暗号化してＸＭＬ署名３５８を生成する。放送局ＣＡ８００は、生成したＸＭＬ署名３５８をアプリケーション／ＡＩＴサーバ２４に応答する。
【００９７】
４．アプリケーション／ＡＩＴサーバ２４のＡＩＴ生成部３５０は、放送局ＣＡ８００より応答されたＸＭＬ署名３５８をハッシュ値付きのＸＭＬ−ＡＩＴ３５５に付加（３５９）して電子署名付きのＸＭＬ−ＡＩＴ３６０を生成する。
５．そして、アプリケーション／ＡＩＴサーバ２４のＡＩＴ生成部３５０は、電子署名付きのＸＭＬ−ＡＩＴ３６０を受信端末３２に提供する。なお、ＸＭＬ署名３５８の生成で用いられた秘密鍵に対応する公開鍵は、受信端末３２に別経路で与えられ、受信端末３２の署名検証部７０８はこの公開鍵を保持する。
【００９８】
受信端末３２の署名検証部７０８は、以下の処理を行う。
１．署名検証部７０８は、アプリケーション／ＡＩＴサーバ２４より取得したアプリケーション３５１の実体（バイナリコード）から所定のハッシュ演算器７５１（ハッシュ関数）を用いてハッシュ値７５２を算出する。ここで用いられるハッシュ関数は、アプリケーション／ＡＩＴサーバ２４のＡＩＴ生成部３５０のハッシュ演算器３５２のそれと同じである必要がある。そこで署名検証部７０８は、取得した電子署名付きのＸＭＬ−ＡＩＴ３６０に記述されたハッシュアルゴリズムを確認して、ハッシュ演算器７５１（ハッシュ関数）のハッシュアルゴリズムとの整合がとれているかどうかを判定する。もしハッシュアルゴリズムの不整合が判定された場合、署名検証部７０８はハッシュ演算器７５１（ハッシュ関数）を切り替えてアプリケーション／ＡＩＴサーバ２４のＡＩＴ生成部３５０のハッシュ演算器３５２のそれと整合させる。
【００９９】
２．署名検証部７０８は、電子署名付きのＸＭＬ−ＡＩＴ３６０から抽出したハッシュ値３５３とハッシュ値７５２とをハッシュ比較器７５６を用いて比較し、一致／不一致の結果７５７を得る。
【０１００】
３．署名検証部７０８は、署名生成器７５３にて、電子署名付きのＸＭＬ−ＡＩＴ３６０からＸＭＬ署名を抽出し、このＸＭＬ署名を署名検証鍵（公開鍵）７５４を用いて検証して署名検証結果７５５を得る。
【０１０１】
以上のようにして、サーバでの電子署名およびハッシュ値の生成と、受信端末３２での電子署名およびハッシュ値の検証が行われる。
【０１０２】
［実施形態の効果等］
本実施形態によれば、放送番組のシーンの単位で、その放送番組に関連する情報をアプリケーションにおいて利用でき、しかもその放送番組に関連する情報が不正な受信端末やアプリケーションによって取得され、利用されるのを防止することができる。すなわち、セキュリティに関し、アフィリエイトインフォを取得するために必要な情報は、正規のＸＭＬ−ＡＩＴとアプリケーションを取得した受信端末３２だけが取得できる仕組みが実現される。
【０１０３】
また、本実施形態によれば、ＸＭＬ−ＡＩＴとアプリケーションには電子署名を付けて受信端末３２に供給され、受信端末３２はアプリケーション実行時にその電子署名を検証する。このため、ＸＭＬ−ＡＩＴのアフィリエイトタグＩＤはすりかえることはできない。
【０１０４】
＜変形例＞
ＨｂｂＴＶの標準規格を前提とした実施形態を説明したが、本技術は、ＨｂｂＴＶの標準規格を前提とすることに必ずしも限定されるものではない。
【０１０５】
その他、本技術は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
【０１０６】
なお、本技術は以下のような構成も採ることができる。
（１）１以上のシーンで構成される放送番組と、この放送番組の少なくとも一部のシーンについて、当該シーン毎に時間的に対応して伝送され、前記放送番組に関連する関連情報を取得するために必要な情報を含むタグ情報とを含む放送信号を受信する放送受信部と、
前記関連情報を利用するアプリケーションと、このアプリケーションの動作を制御するための情報、およびこのアプリケーションが利用する関連情報を特定するための情報を含むタグ情報を特定するための識別情報が少なくとも記述されたアプリケーション情報テーブルをそれぞれ取得し、このアプリケーション情報テーブルをもとに前記アプリケーションの動作を制御するアプリケーション制御部と、
前記受信された放送信号から、前記アプリケーション情報テーブルに記述された識別情報をもとに前記タグ情報を取得し、このタグ情報をもとに前記関連情報を取得し、実行中の前記アプリケーションに供給するタグ情報処理部と
具備する受信装置。
【０１０７】
（２）前記（１）に記載の受信装置であって、
請求項１に記載の受信装置であって、
前記アプリケーション情報テーブルには、前記アプリケーションから所定の演算によって求められた当該アプリケーションを代表する第１の代表値がさらに記述され、かつ電子署名が添付され、
前記アプリケーション制御部は、取得した前記アプリケーション情報テーブルに添付された前記電子署名を検証するように構成される
受信装置。
【０１０８】
（３）前記（１）または（２）に記載の受信装置であって、
前記タグ情報は、前記関連情報の伝送チャンネルを識別するためのチャンネル識別情報を含み、
前記タグ情報処理部は、前記チャンネル識別情報により特定される伝送チャンネルから前記関連情報を取得するように構成される
受信装置。
【０１０９】
（４）前記（１）または（３）に記載の受信装置であって、
前記タグ情報は、前記関連情報のネットワーク上のロケーション情報を含み、
前記タグ情報処理部は、前記ロケーション情報をもとに前記関連情報を取得するように構成される
受信装置。
【符号の説明】
【０１１０】
１…情報処理システム
１０…放送事業者
１２…放送局
１４…アフィリエイトインフォサーバ
２０…アプリケーション事業者
２２…アプリケーション／ＡＩＴ生成装置
２４…アプリケーション／ＡＩＴサーバ
３２…受信端末
２００…ネットワーク
２４１…格納部
２４２…配信部
３２１…放送インタフェース
３２２…デマルチプレクサ
３２３…ビデオデコーダ
３２４…オーディオデコーダ
３２５…証明書受信処理部
３２６…アフィリエイト処理部
３２７…アプリケーション制御部
３２８…通信インタフェース
３２９…アプリケーションエンジン
３５０…ＡＩＴ生成部
７０８…署名検証部
【図１】
2019036981.tif 000003
【図２】
2019036981.tif 000004
【図３】
2019036981.tif 000005
【図４】
2019036981.tif 000006
【図５】
2019036981.tif 000007
【図６】
2019036981.tif 000008
【図７】
2019036981.tif 000009
【図８】
2019036981.tif 000010
【図９】
2019036981.tif 000011
【図１０】
2019036981.tif 000012
【図１１】
2019036981.tif 000013
【図１２】
2019036981.tif 000014
【図１３】
2019036981.tif 000015
【図１４】
2019036981.tif 000016
【図１５】
2019036981.tif 000017
【手続補正書】
【提出日】平成30年11月9日(2018.11.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
放送番組に関連する関連情報のロケーション情報を含むタグ情報を含む放送信号に含まれる前記関連情報を利用するアプリケーションと、このアプリケーションの動作を制御するための情報が少なくとも記述されたアプリケーション情報テーブルを送信する送信部を備える
送信装置。
【請求項２】
請求項１に記載の送信装置であって、
前記タグ情報は、前記関連情報の伝送チャンネルを識別するためのチャンネル識別情報
を含む
送信装置。
【請求項３】
請求項１または２に記載の送信装置であって、
前記アプリケーション情報テーブルには、前記アプリケーションから所定の演算によって求められた当該アプリケーションを代表する第１の代表値がさらに記述され、かつ電子署名が添付される
送信装置。」
【請求項４】
放送番組に関連する関連情報のロケーション情報を含むタグ情報を含む放送信号に含まれる前記関連情報を利用するアプリケーションと、このアプリケーションの動作を制御するための情報が少なくとも記述されたアプリケーション情報テーブルを送信する
送信方法。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
本技術は、アプリケーション管理テーブルの送信装置および送信方法に関する。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
本技術の目的は、放送リソースを利用するアプリケーションを用いたサービスの品質の
向上を図ることの可能な送信装置および送信方法を提供することにある。