受信機および受信システム
【課題】連携動作させる機器に実行させるアプリケーションを動的に変更することができる。
【解決手段】受信中のＴＳに対応付けられたＡＩＴに基づいて、放送通信連携サービスにおけるアプリケーションを実行する受信機４において、ＴＳから、通信機能を有する機器８に実行させる端末アプリケーションを指定するアプリケーション指定情報を取得するアプリケーション情報取得部４７２と、アプリケーション情報取得部４７２が取得したアプリケーション指定情報に基づき、機器８に対して、端末アプリケーションを指定し起動制御を行うアプリケーション実行部４３５とを備えた。
【解決手段】受信中のＴＳに対応付けられたＡＩＴに基づいて、放送通信連携サービスにおけるアプリケーションを実行する受信機４において、ＴＳから、通信機能を有する機器８に実行させる端末アプリケーションを指定するアプリケーション指定情報を取得するアプリケーション情報取得部４７２と、アプリケーション情報取得部４７２が取得したアプリケーション指定情報に基づき、機器８に対して、端末アプリケーションを指定し起動制御を行うアプリケーション実行部４３５とを備えた。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受信機および受信システムに関する。
【背景技術】
【０００２】
近年、放送通信連携サービスを実現するための研究が行われている。この放送通信連携サービスは、一例として、視聴者により利用される受信機に、放送局側から放送される放送番組コンテンツと、サービス事業者側からインターネット等の電気通信回線を介して配信される配信コンテンツとをそれぞれ受信させ、これら放送番組コンテンツと配信コンテンツとを連携させて再生させるサービスである。
受信機は、放送番組コンテンツと配信コンテンツとを表示および音声出力するためのアプリケーションを実行処理することによって、放送通信連携サービスを受けることができる。
また、受信機と通信端末とを連携動作させることによって、視聴者に、通信端末をも利用させて放送通信連携サービスを受けさせる試みも行われている。
【０００３】
従来、デジタル放送におけるアプリケーションの実行環境が規格化され運用されている（例えば、非特許文献１参照）。この文献には、ネットワークに接続された機器とこの機器の機能とをデータ放送コンテンツと連動させて利用させるための、ネットワーク機器利用に関する技術的事項が記載されている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】「デジタル放送におけるアプリケーション実行環境 標準規格」、ＡＲＩＢ ＳＴＤ−Ｂ２３、１．２版、社団法人電波産業会、平成２１年７月
【発明の概要】
【発明が解決しようとする課題】
【０００５】
受信機と通信端末との連携機能の実現において、放送番組またはその内容もしくはその進行状況等に応じて、通信端末に実行させるアプリケーションを動的に変更したいという要求がある。しかしながら、この機能要求を満たす仕組みは未だ確立されていない。
【０００６】
本発明は、上記事情に鑑みてなされたものであり、連携動作させる端末に実行させるアプリケーションを動的に変更することができる、受信機および受信システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
［１］上記の課題を解決するため、本発明の一態様である受信機は、受信中の放送ストリームに対応付けられたアプリケーション情報テーブルに基づいて、放送通信連携サービスにおける第１のアプリケーションを実行する受信機において、前記受信中の放送ストリームから、通信機能を有する端末に実行させる第２のアプリケーションを指定するアプリケーション指定情報を取得するアプリケーション情報取得部と、前記アプリケーション情報取得部が取得した前記アプリケーション指定情報に基づき、前記端末に対して、前記第２のアプリケーションを指定し起動制御を行うアプリケーション実行部と、を備えることを特徴とする。
［２］上記［１］記載の受信機において、前記アプリケーション情報取得部は、前記放送ストリームから、放送番組の関連情報であるメタデータも取得し、前記アプリケーション実行部は、前記アプリケーション情報取得部が取得した前記アプリケーション指定情報と前記メタデータとに基づき、前記端末に対して、前記第２のアプリケーションと前記メタデータとを指定し起動制御を行うことを特徴とする。
［３］上記の課題を解決するため、本発明の一態様である受信システムは、放送通信連携サービスにおける第１のアプリケーションを実行する受信機と、端末とを通信可能に備える受信システムにおいて、前記受信機は、受信中の放送ストリームから、前記端末に実行させる第２のアプリケーションを指定するアプリケーション指定情報を取得するアプリケーション情報取得部と、前記アプリケーション情報取得部が取得した前記アプリケーション指定情報に基づき、前記端末に対して、前記第２のアプリケーションを指定し起動制御を行うアプリケーション実行部と、を備え、前記端末は、前記アプリケーション実行部による前記起動制御に基づいて、前記第２のアプリケーションを取得する端末アプリケーション取得部と、前記端末アプリケーション取得部が取得した前記第２のアプリケーションを実行処理する端末アプリケーション実行部と、を備えることを特徴とする。
［４］上記［３］記載の受信システムにおいて、前記アプリケーション情報取得部は、前記放送ストリームから、放送番組の関連情報であるメタデータも取得し、前記アプリケーション実行部は、前記アプリケーション情報取得部が取得した前記アプリケーション指定情報と前記メタデータとに基づき、前記端末に対して、前記第２のアプリケーションと前記メタデータとを指定し起動制御を行い、前記端末アプリケーション実行部は、前記アプリケーション実行部により指定された前記メタデータを用いて、前記端末アプリケーション取得部が取得した前記第２のアプリケーションを実行処理することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、連携動作させる端末に実行させるアプリケーションを動的に変更することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態である受信システムの機能構成を示すブロック図である。
【図２】本発明が適用される放送通信連携システムを利用する者とその関係を示す図である。
【図３】放送通信連携システムの全体構成を示す図である。
【図４】放送通信連携システムの端末連携モデルを示す図である。
【図５】放送通信連携システムのサービス種別の概念図を示す。
【図６】放送通信連携システムに使用するＡＩＴのテキスト表現の例を示す図である。
【図７】放送通信連携システムにおけるアプリケーションのライフサイクルを示す図である。
【図８】放送通信連携システムにおける事業者間のデータの流れを示す図である。
【図９】放送通信連携システム全体におけるデータの流れを示す図である。
【図１０】放送通信連携システムにおけるレコメンドサービスのシーケンスを示す図である。
【図１１】放送通信連携システムにおける転送プロトコルスタックを示す図である。
【図１２】放送通信連携システムにおけるアプリケーション管理モデルを示す図である。
【図１３】放送通信連携システムにおけるセキュアマネージャーの機能モデルを示す。
【図１４】放送通信連携システムにおける画面提示制御方式の概念を示す図である。
【図１５】放送通信連携システムにおける画面提示制御の基本動作モデルを示す図である。
【図１６】放送通信連携システムにおけるポリシーレベルに応じた画面提示制御の例を示す。
【図１７】放送通信連携システムにおける緊急地震速報受信時の提示制御の例を示す。
【図１８】本発明の一実施形態による放送通信連携システムの全体構成図である。
【図１９】同実施形態による受信機の内部構成を示す機能ブロック図である。
【図２０】同実施形態によるアプリケーション実行制御部の詳細な構成を示すブロック図である。
【図２１】同実施形態による提示制御部の詳細な構成を示すブロック図である。
【図２２】本発明の一実施形態において、操作受付部として赤外線リモコンを用いた場合の、概略の外観正面図である。
【図２３】同実施形態である受信機と、受信機アプリサーバと、コンテンツ配信サーバとの処理の手順を示すシーケンス図である。
【図２４】同実施形態である受信機が操作受付部の操作にしたがって作動する場合の、動作の処理手順を示すフローチャートである。
【図２５】同実施形態である受信機が操作受付部の操作にしたがって作動する場合の、動作の処理手順を示すフローチャートである。
【図２６】同実施形態である受信機の動作の処理手順を示すフローチャートである。
【図２７】同実施形態である受信機と、機器と、端末アプリケーションサーバとの処理の手順を示すシーケンス図である。
【図２８】イベント情報テーブルのデータ構造を示す図である。
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための形態について、図面を参照して詳細に説明する。
本発明の一実施形態は、放送サービスのみを受ける状態と、放送通信連携サービスの一サービス形態であるストリーム従属型サービスを受ける状態とを、簡便な操作により切り替えることができる受信機である。また、本実施形態は、放送通信連携サービスの供給者側からの制御によって、現在受けている放送通信連携サービスを放送サービスに切り替えることができる受信機である。また、本実施形態は、放送通信連携サービスにおいて実行するアプリケーション（第１のアプリケーション）と、このアプリケーションに関連するコンテンツデータとを、自装置の要求にしたがって外部の供給元から取得することができる受信機である。また、本実施形態は、受信機、および、受信機と機器（端末）とを含む受信システムであり、連携動作させる機器に実行させるアプリケーション（第２のアプリケーション）を動的に変更することができる、受信機および受信システムである。
【００１１】
図１は、本発明の一実施形態である受信システムの機能構成を示すブロック図である。
同図に示すように、受信システムは、受信機４と機器８とを含んで構成される。
受信機４は、放送受信部４０１と、分離部４０２と、通信入出力部４１１と、アプリケーション実行制御部４１２と、操作入力部４１４と、選局部４１５と、操作受付部４７４とを含んで構成される。
アプリケーション実行制御部４１２は、アプリケーション記憶部４３１と、アプリケーション制御部４３４と、アプリケーション実行部４３５と、リソースアクセス制御部４３８と、リソース制御部４３９とを含んで構成される。
アプリケーション制御部４３４は、アプリケーション情報取得部４７２と、起動制御部４７３と、終了制御部４８１とを含んで構成される。
操作入力部４１４は、起動要求信号取得部４７１を含んで構成される。
機器８は、接続制御部５０１と、端末アプリケーション取得部（同図では、端末アプリ取得部と略記する）５０２と、端末アプリケーション実行部（同図では、端末アプリ実行部と略記する）５０３とを含んで構成される。
機器８は、前述したとおり、携帯電話、ＰＤＡ、スマートフォン、タブレット、パーソナルコンピュータ等の通信機能を備えた端末（電子機器、情報処理装置）である。
【００１２】
［本発明が適用される放送通信連携システムの説明］
ここで、本発明が適用される放送通信連携システムについて説明する。本発明が適用される放送通信連携システム（放送通信融合システム、放送通信システム、送受信システム）は、例えば、Hybridcast（登録商標）（ハイブリッドキャスト）システムであり、放送通信連携サービス（Hybridcast（登録商標）サービス、放送通信融合サービス、放送通信サービス）を提供する。本発明が適用される放送通信連携システムが実現する放送通信連携サービスは、デジタル放送サービスと、インターネットなどによる通信サービスとを連携する。例えば、放送通信連携サービスでは、デジタルテレビやパーソナルコンピュータ、携帯端末などの受信機は、放送により伝送された放送番組（以下、「番組」とも記載する。）の表示画面（以下、番組の表示画面の「放送画面」とも記載する。）に、この受信機に実装されているアプリケーションが通信により取得したサービスやコンテンツの表示画面（以下、「アプリケーション画面」、「アプリケーションの表示画面」とも記載する。）を合わせて同時に表示する。
【００１３】
［１． システムモデル］
［１．１ 放送通信連携システムの利用者]
図２は、放送通信連携システムを利用する者とその関係を示す図である。
編成を伴う番組を送出する放送局は、放送電波あるいは通信網により番組を視聴者に配信する。放送局は、放送通信連携サービスを充実するために、番組に関連するメタデータをサービス事業者に提供する。
【００１４】
放送通信連携サービスを提供するサービス事業者は、視聴者に放送通信連携サービスを提供するためのコンテンツとアプリケーション（以下、「アプリ」とも記載する。）を制作し、配信する。以下では、単に「アプリケーション」と記載した場合、放送通信連携サービスを提供するためのアプリケーション（放送通信連携サービスのアプリケーション）を指す。コンテンツまたはアプリケーションの制作者と配信者が同一のサービス事業者である必要はない。放送局がサービス事業者を兼ねてもよい。サービス事業者は、他のサービス事業者へのリンク情報を提供することも可能である。サービス事業者は、提供するアプリケーションが公式であることを示すために、システム管理者にアプリケーションの登録を申請し、承認を得ることができる。承認されたアプリケーションは、受信機上での動作に制限を受けない。一方、承認されないアプリケーションが表示させる画面は、番組の表示画面および音声にオーバーラップすることはできないが、アプリケーションの表示画面を縮小して放送番組の画面の外に表示することができる。承認されたアプリケーションをＡ（Authorized）アプリケーション、承認されないアプリケーションを一般アプリケーションという。なお、Ａアプリケーションを、公式アプリケーション、登録アプリケーション、認証済アプリケーション、認定アプリケーション、公認アプリケーション、オーソライズドアプリケーション、Ａ（Authorized）タイプアプリケーションとも呼ぶ。また、一般アプリケーションを、非公式アプリケーション、非認証アプリケーション、非認定アプリケーション、非公認アプリケーション、Ｕ（Unauthorized）タイプアプリケーション、Ｕアプリケーションとも呼ぶ。
【００１５】
システム管理者は、視聴者に提供するアプリケーション（受信機アプリ）がＡアプリケーション（公式）であることを認定する機関である。申請されたアプリケーションを承認するか否かのシステム管理者の判断は、放送局からの委託による。
【００１６】
各種設定等を行なうためのアプリケーションを受信機にインストールさせておいてもよい。この際、受信機におけるアプリケーションの表示画面が番組の表示画面（映像）にオーバーラップしてもよい。
【００１７】
放送局により放送された番組を視聴する視聴者は、放送通信連携サービスを享受する。
視聴者は、自身の意思により、アプリケーションをダウンロードしたり、起動したりすることができる。また、視聴者は、自身の意思により、アプリケーションの表示画面を番組の表示画面（映像）にオーバーラップさせることができる。
【００１８】
[１．２ 放送通信連携システムのシステム構成]
図３は、放送通信連携システムの全体構成を示す図である。放送通信連携システムは、電波を利用した現行の放送局設備に、機能的に「放送局サーバ群」、「サービス事業者サーバ群」、「受信機」を加えて構成される。
【００１９】
放送局は、放送局設備を保有する。さらに放送局は、放送局サーバ群あるいはサービス事業者サーバ群の両方を構成し、管理運営する。また、サービス事業者は、サービス事業者サーバ群を構成し、管理運営する。システム管理者は、リポジトリサーバを管理運営する。受信機メーカは、受信機を製造販売する。視聴者は受信機を保有し、放送通信連携サービスを享受する。
【００２０】
受信機（Hybridcast（登録商標）受信機、放送受信通信装置）は、標準化された共通のＡＰＩ（アプリケーションプログラムインタフェース：Application Program Interface）を搭載する。また、受信機は、地上デジタル放送、ＢＳ（broadcasting satellite）デジタル放送等の現行方式の放送を受信する。
放送局設備は、放送通信連携サービスを起動するための信号を放送波に多重化する。多重化の方式については後述する。
【００２１】
[１．３ 放送局サーバ群の構成例]
放送局サーバ群は、放送局が持っているコンテンツやメタデータを管理し、配信する。
例えば、放送局サーバ群は、各種サーバ、データ蓄積部（ＤＢ（データベース））及びＡＰＩを含んで構成され、放送局サーバ群のサーバは、コンテンツ管理サーバ、視聴者管理サーバ、コンテンツ配信サーバ、放送局サービスサーバを含んで構成される。
【００２２】
コンテンツを管理するコンテンツ管理サーバは、放送コンテンツである番組とメタデータを管理する。コンテンツ管理サーバには、放送された番組または放送される番組を管理する番組管理サーバや、番組に関連するメタデータを管理するメタデータ管理サーバが含まれる。メタデータは、例えば、番組タイトル、番組ＩＤ、番組概要、出演者、スタッフ、放送日時、台本、字幕、解説などを示す。
【００２３】
視聴者管理サーバは、視聴者（ユーザ）を管理し、コンテンツ配信サーバは、通信によりコンテンツデータを配信する。放送局サービスサーバは、放送局がサービス事業者に対してサービスを提供するためのサーバである。放送局サービスサーバが提供するサービスには、例えば、放送局が運営するソーシャルネットワークサービスや、放送番組毎のウェブログ（ブログ）などがある。
【００２４】
放送局サーバ群のデータ蓄積部は、放送局が持っているコンテンツ、メタデータを格納する部分とデータベースから構成される。蓄積されたデータには、管理しているサービス事業者のみがアクセス可能であり、他者からはアクセスできないように制限している。
【００２５】
放送局サーバ群のＡＰＩは、サービス事業者サーバ群からの要求に応じてデータを提供するためのＡＰＩである。ＡＰＩは、アプリケーションがサービスを受けるために呼び出すプログラムおよびその実行部である。
【００２６】
[１．４ サービス事業者サーバ群の構成例]
サービス事業者が管理運営するサービスサーバ群は、アプリケーションとコンテンツを管理し、提供する。サービスサーバ群は、受信機アプリサーバ、サービスサーバ、コンテンツ配信サーバ、データ蓄積部（ＤＢ（データベース））及びＡＰＩを含んで構成される。
【００２７】
受信機アプリサーバは、放送通信連携サービスのアプリケーションを管理するサーバである。サービス事業者は、受信機で動作するアプリケーションを保存、管理、配信する。
サービス事業者は、団体または個人で構成される。受信機アプリサーバは、受信機からの要求により、アプリケーションファイル（アプリケーションファイルについては後述する。）の保存場所を受信機に知らせるとともに、アプリケーションファイルを配信する。
【００２８】
サービスサーバは、受信機で動作しているアプリケーションからの要求によりサービスを提供するサーバである。サービスサーバには、例えば、多言語字幕サーバ、話速変換音声サーバ、ソーシャルＴＶサーバ、レコメンドサーバ、番組レビューサーバ、ブックマークサーバなどがある。
【００２９】
コンテンツ配信サーバは、受信機で動作しているアプリケーションからの要求によりコンテンツを提供するサーバである。コンテンツ配信サーバには、例えば、ＶＯＤ（VideoOn Demand）配信サーバ、字幕配信サーバ、マルチビュー配信サーバなどがある。
【００３０】
サービス事業者サーバ群のデータ蓄積部は、コンテンツデータ、メタデータ、サービス事業者が作成したデータ、視聴者データ、アプリケーションファイルを保存する場所である。データ蓄積部に保存されたデータには、管理しているサービス事業者のみがアクセスでき、他者からはアクセスできない。
【００３１】
サービスサーバ群のＡＰＩは、受信機で動作しているアプリケーションからの要求により、アプリケーションファイル、コンテンツ、サービスを提供するためのＡＰＩである。
【００３２】
[１．５ 受信機]
受信機は、現行方式の放送を受信し表示するとともに、放送通信連携サービスを実行する。現行方式の放送とは、地上デジタル放送、ＢＳデジタル放送等の衛星放送、データ放送である。また、受信機は、インターネットに接続される。
【００３３】
受信機は、受信する放送波に多重された情報をもとにして、サービス事業者サーバにアプリケーションのダウンロード要求を行う。受信機が、ダウンロードしたアプリケーションファイルに含まれるアプリケーションプログラムを実行することによって、受信機上でアプリケーションが動作する。受信機上で動作しているアプリケーションは、サービス事業者サーバにアクセスしてコンテンツを取得する。
また、受信機は、同期機能、アプリ制御機能など放送通信連携サービスを実行するために必要な機能である放送通信連携機能を持つ。放送通信連携機能に対するＡＰＩは共通化されているため、アプリケーションの制作が容易であるとともに、アプリケーションは受信機に依存しない。
放送通信連携サービスでは、パーソナルコンピュータや携帯端末などのデバイスとの連携のための機能も取り入れている。
【００３４】
放送通信連携機能には、放送通信連携基本機能と、必要に応じて実装するオプション機能とがある。受信機メーカは、放送通信連携基本機能を全ての受信機に実装する。アプリケーションは、ＡＰＩを通して放送通信連携機能を利用する。放送通信連携機能は、後述するＡＰＩに基づき動作する。
【００３５】
受信機が実装するＡＰＩは、受信機に依存することなく、アプリケーションの動作が同じになるようにするために規定される。全てのアプリケーションは、ＡＰＩを通して受信機の処理を行なうため、ＡＰＩを介さずにアプリケーションが受信機固有の機能にアクセスすることはできない。
【００３６】
[１．６ 端末連携モデル]
図４は、放送通信連携システムの端末連携モデルを示す図である。
受信機は、携帯端末などの端末と連携してサービスを提供することができる。連携する端末には、例えば、パーソナルコンピュータ、携帯電話、タブレット、スマートフォン、ＰＤＡ（Personal Digital Assistant）などがある。受信機は、受信機機能として他の端末が利用可能な機能をＡＰＩとして提供する。この他の端末が利用可能な機能を提供するＡＰＩを端末連携ＡＰＩという。例えば、携帯端末上で動作するアプリケーションは、端末連携ＡＰＩを利用することで、番組情報の取得などの放送リソースにアクセスしたり、再生制御等の受信機機能を呼び出したりすることができる。
【００３７】
[１．６．１ 端末連携ＡＰＩ]
端末連携ＡＰＩは、他の端末やその端末上で動作するアプリケーションが受信機の機能を利用するためのＡＰＩである。連携する端末は、ホームネットワーク（ＬＡＮ）上の端末及びインターネットを通してアクセスする端末を対象とする。各種動作を提供するＡＰＩの規定は後述する。
【００３８】
[１．６．２ 端末連携ＡＰＩ提供プロセス]
受信機上で動作する端末連携ＡＰＩ提供プロセスは、端末連携ＡＰＩを動作させる。端末連携ＡＰＩ提供プロセスは、常駐して動作する一種のデーモンプロセスのように動作する。
【００３９】
[１．６．３ ＡＰＩを呼び出すプロトコル]
端末連携ＡＰＩを呼び出すプロトコルには、例えば、ＲＥＳＴｆｕｌ（ＲＥＳＴ：Representational State Transfer）、ＵＰｎＰ（Universal Plug and Play）、ＸＭＰＰ（eXtensible Messaging and Presence Protocol）などが用いられる。
【００４０】
[１．６．４ プッシュ通知（Notification）機能]
受信機は、インターネット上のサーバ等が受信機に対してプッシュで情報を通知するNotification（通知）機能にも対応する。受信機はサーバ等からのプッシュにより通知された情報を受信する。Notification機能によって、なんらかの受信機動作を制御する場合があり、Notification機能も端末連携ＡＰＩ仕様の一部として規定される。
【００４１】
[２． 放送通信連携アプリケーション]
[２．１ サービスとアプリケーションモデル]
放送通信連携システムのアプリケーションモデルは、ＤＶＢ−ＧＥＭ１．２のアプリケーションモデルの考え方をベースに追加、変更したモデルである。
【００４２】
[２．１．１ 放送通信連携アプリケーション]
放送通信連携サービスのアプリケーションの動作は、ＡＶ（Audio Visual）コンテンツに連動した動作（連動）と、アプリケーション単独での動作（非連動）の２つのパターンに分類される。ＡＶコンテンツとは、放送コンテンツ（番組）または通信コンテンツ（ＶｏＤ等）である。
【００４３】
連動の場合、起動などのアプリケーションのライフサイクル制御は、放送または通信コンテンツに連動して行われる。アプリケーションは、ＡＶコンテンツと一緒に配信されるＡＩＴ（Application Information Table）（アプリケーション情報テーブル、アプリケーション起動情報）をもとに起動される。この場合、視聴者による起動や終了の操作に加え、放送事業者などのＡＶコンテンツの提供者がアプリケーションの自動起動や、終了などのライフサイクルを制御することも可能である。
一方、非連動の場合、放送や通信コンテンツに連動せずに、アプリケーション単独で起動、終了される。この場合、アプリケーションの開始や終了などのアプリケーションのライフサイクルは、視聴者によってのみ制御される。
【００４４】
[２．１．２ サービス]
従来、サービスとは、放送事業者が編成し、スケジュールの一環として放送可能な番組の連続のことをいうが、放送通信連携システムにおいてはこの考え方を拡張し、ストリーム従属型サービスと独立型サービスの２つのサービス種別を定義する。
【００４５】
図５は、サービス種別の概念図を示す。
受信機において、ストリーム従属型サービス及び独立型サービスを擬似的に選局することで、関連するアプリケーションが起動することになる。
ストリーム従属型サービスは、従来の意味でのサービスの考え方を拡張したものであり、放送や通信で伝送するＡＶストリームに、それに連動して動作するアプリケーション（複数可）を加えて構成される。ＡＶストリームの選択・再生（放送の場合は選局）によって連動してアプリケーションを起動することができる。
一方、独立型サービスは、映像・音声のストリームは含まず、アプリケーション（複数可）のみで構成される。視聴者が独立型サービスを選択することで、アプリケーションが起動される。
【００４６】
[２．１．３ オンザフライで取得するアプリ起動とインストールしたアプリの起動]
アプリケーションの起動には、オンザフライでアプリケーションファイルを取得して起動する方法と、予め受信機に蓄積（インストール）しておいたアプリケーションファイルを起動する方法の２つがある。オンザフライとは、アプリケーションの実行時に通信によってアプリケーションファイルを取得する方法であり、非インストール型、直接実行型ともいう。
【００４７】
なお、受信機は、後述するＡＩＴによるアプリケーションの周知をもとに、ローカルのファイルシステムにあるアプリケーションファイルのアプリケーションプログラムを起動する。受信機は、通信によりアプリケーションファイルを取得してインストールする際、関連するＡＩＴに設定されているロケーション階層内の情報（２．５．１節参照）をローカルのファイルシステム上のロケーションに書き換え、必要に応じて独立型サービスを識別する値(独立型サービスのＡＩＴ単位で必要)を生成する動作などが必要となる。
【００４８】
[２．２ アプリケーションの周知法（シグナリング）]
[２．２．１ アプリケーション起動情報（ＡＩＴ）]
サービスに含まれるアプリケーションの周知は、サービス選択時に通知されるアプリケーション起動情報によって行う。アプリケーション起動情報としてＡＲＩＢ ＳＴＤ−Ｂ２３（以下、ＡＲＩＢ−Ｊと記載）で定義されているＡＩＴを用いる。ストリーム従属型サービス、独立型サービスそれぞれで、そのサービス用のＡＩＴが周知される。各サービスにおけるＡＩＴの送り方の詳細を以下に示す。
【００４９】
図６は、放送通信連携システムに使用するＡＩＴのテキスト表現の例を示す図である。
放送通信連携システムにおいて使用するＡＩＴは、ＡＲＩＢ−Ｊで規定されるＡＩＴをベースとする。ＡＩＴには、ＳＩ（Service Information）のテーブルで伝送するためのバイナリ表現と、ＸＭＬ（extensible markup language）形式によるテキスト表現(ＡＩＴ Ｆｉｌｅ)とが存在し、同図では、テキスト表現の例を示している。ＡＩＴには、アプリケーションを特定するアプリケーションＩＤ（applicationIdentifier）、アプリケーション状態を制御する制御コード（controlCode）、アプリケーションファイルの格納位置（格納場所）を示すロケーション情報（location）などが記述される。
【００５０】
[２．２．２ ＡＶコンテンツに連動するアプリケーションの周知]
ＡＶコンテンツに連動するアプリケーションの周知は、ＭＰＥＧ（Moving Picture Experts Group）−２ ＴＳ（トランスポートストリーム：Transport Stream）で伝送するＡＶコンテンツにＡＩＴを多重する場合と、別途ＡＩＴの情報を送る場合がある。ＡＶコンテンツと連動させてＡＩＴを伝送することにより、受信機において、放送番組に連動するアプリケーションの起動や、番組の進行に連動したダイナミックなアプリケーションの起動などのライフサイクル制御が可能となる。
周知方法には、例えば、（１）ＡＩＴ用のＥＳ（エレメンタリーストリーム：Elementary Stream）追加、（２）ＥＩＴ（イベント情報テーブル：EventInformationTable）への記述子追加、（３）カルーセルでの伝送、（４）通信でのＡＩＴファイルの取得、（５）通信でのダイナミックなＡＩＴファイルの伝送、などがある。
【００５１】
（１）ＡＩＴ用のＥＳ追加の場合、ＡＲＩＢ−Ｊにおける規定と同様にＡＩＴのＥＳを放送ＴＳに多重する。
【００５２】
（２）ＥＩＴへの記述子追加の場合、後述する提示制御と同様に、ＥＩＴ（ｐ／ｆ）への記述子を追加し、ＡＩＴで伝送される情報と同じ情報を伝送する。
【００５３】
（３）カルーセルでの伝送の場合、ＤＳＭ−ＣＣ(Digital Storage Media Command and Control)データカルーセルでＡＩＴを伝送する。例えば、特定のモジュールでＡＩＴファイルを伝送する。カルーセルで伝送することで、取得時間のオーバーヘッドが想定されるが、現行の放送信号を変更する必要がない。
カルーセルでの運用例として、放送通信連携起動ファイル伝送用カルーセルのコンポーネントタグ、モジュールを固定する。例えば、コンポーネントタグに「ＡＡ」を、モジュールＩＤに「００００」を設定し、モジュールのType記述子にＡＩＴであることを示すタイプを設定する。受信機は、モジュールの更新を監視し、更新を検出するとＡＩＴを読み直し、ＡＩＴにより指定された制御（アプリケーションのライフサイクル制御）を実行する。
【００５４】
（４）通信でのＡＩＴファイルの取得の場合、ＡＶコンテンツの選択と同時に、別に用意されたＡＩＴファイルを取得する。例えば、再生するＡＶコンテンツの情報（コンテンツＩＤ）とアプリケーション起動情報（ＡＩＴ）が記述された情報を起点に両者を取得する。サーバ型放送（ＡＲＩＢ ＴＲ−Ｂ２７）の利用単位コンテンツやエントリーコンポーネントの考え方を利用することができる。
【００５５】
（５）通信でのダイナミックなＡＩＴの伝送の場合、ＡＶコンテンツを再生中に、新たなアプリケーションを起動したり、起動中のアプリケーションを終了させたりする制御を通信で伝送するＡＩＴにより行う。なお、予め想定されていないタイミングでの制御を行なう場合、通信を経由したプッシュによる通知を行なう。
【００５６】
[２．２．３ 独立して動作するアプリケーションの周知]
受信機は、独立して動作するアプリケーションの起動情報を含むＡＩＴを通信により取得する。独立アプリケーションは、既知のアプリケーションリポジトリから取得する。個々の独立アプリケーションの起動情報を取得するまでの手順を以下に示す。
【００５７】
（１）受信機にアプリケーションリポジトリのロケーションをセットする。出荷時に予め設定してもよく、複数のリポジトリを後から何らかの方法で追加してもよい。
（２）アプリケーションメニューを開くと、受信機はアプリケーションリポジトリからアプリケーションのリスト（各アプリのＡＩＴのロケーション記述を含む）を取得し、メニューにアプリを表示する。
（３）視聴者が選択したアプリケーションのＡＩＴを通信から取得する。
【００５８】
上記の手順は、リポジトリが提供するＷＥＢ（ウェブ） ＡＰＩを利用して実行される。また、独立して動作するアプリケーションは、ＡＶコンテンツと連動して動作するものではないため、予め指定したタイミングでの動的なライフサイクルコントロールは行わない。予め指定されていないタイミングでの制御（終了など）は、通信経由でのプッシュでの通知（Notification）により行なう。
【００５９】
[２．３ アプリケーションの起動と終了]
[２．３．１ アプリケーションのライフサイクル]
[２．３．１．１ ライフサイクル]
図７は、アプリケーションのライフサイクルを示す図である。
アプリケーションの状態は、ＡＲＩＢ−Ｊにおけるアプリケーションの状態に準じ、「Not Loaded（ロード前）」、「Loaded（ロード後）」、「Paused（休止）」、「Started（開始）」、「Destroyed（破壊）」の５つの状態を持つ。これら５つの状態において、アプリケーションがロード、実行されて終了するまでの一連の過程をアプリケーションのライフサイクルと呼び、各状態間の遷移の制御をライフサイクルコントロールと呼ぶ。
【００６０】
[２．３．１．２ ＡＶコンテンツに連動するアプリケーションの基本的ライフサイクル制御]
ＡＶコンテンツに連動するアプリケーションのライフサイクルの制御は、ストリーム従属型サービスの選択を通して行われることを基本とする。
ストリーム従属型サービスの選択は視聴者によって行われる。サービスは、ＡＶコンテンツやアプリケーションを含む一連のコンテンツのセットであり、アプリケーションと一緒に送られるＡＩＴに含まれる制御コードよって起動や終了などのライフサイクルが制御される。一つのサービスに複数のアプリケーションが含まれ、それらが同時に動作する場合もある。
【００６１】
アプリケーション起動のトリガとなるサービスの選択は、受信機ＡＰＩを通してアプリケーションから制御する場合や、受信機のレジデントアプリケーションとしてのナビゲータから制御する場合、放送サービスの場合はリモコンボタンを制御する場合、などがある。サービス切り替え時に、切り替え前後のサービスに含まれるコンテンツ（ＡＶコンテンツやアプリケーション）の提示が切り替えられる。切り替え前後のサービスに含まれるアプリケーションが異なる場合は、切り替え前に起動していたアプリケーションはサービス切り替えによって終了し、切り替え後には異なるアプリケーションが起動可能となる。これらの動作の詳細は、２．４節に後述する。
【００６２】
[２．３．２ アプリケーションの起動]
[２．３．２．１ ＡＩＴによる起動]
受信機においてサービス（ストリーム従属型サービス、独立型サービス）が選択されたとき、サービスと共に提供されるＡＩＴに含まれる制御コードで「auto-start」が指定されたアプリケーションは、視聴者からの明示的なアクションなしでサービス選択とともに自動的に起動する。サービス選択中は、そのサービスに対するアプリケーションシグナリングによってライフサイクルが制御される。例えば、放送サービスの場合は、放送と共に伝送されるＡＩＴを受信機が常に監視し、その変化に対応する。このように、ＡＩＴの伝送などのアプリケーションシグナリングによって、受信機において新たなアプリケーションを途中で自動起動（auto-start）するよう制御できる。
【００６３】
ＡＩＴによるアプリケーション起動情報において「auto-start」が指定されていないアプリケーションは、自動的には起動されず、視聴者による明示的な起動が必要となる。この明示的な起動は、受信機のレジデントアプリケーションのアプリケーションローンチャーによって行われる。例えば、放送サービス選択時に、リモコンの放送通信連携サービスボタンを押すことで、受信機においてアプリケーション起動用のメニューが開き、現在の放送（通信）サービスに連動するアプリケーション一覧が表示される。ここで視聴者は、受信機に対して、起動したいアプリケーションを選択・起動する操作を行う。
【００６４】
[２．３．２．２ 放送通信連携アプリケーションからの起動]
サービス内で複数のアプリケーションを起動できるため、起動済のアプリケーションから同じサービスに含まれる他のアプリケーションを起動することもある。ＡＲＩＢ−Ｊアプリケーション実行環境では、アプリケーションＩＤを指定することにより他のアプリケーションを起動するＡＰＩが規定されている。その他の実行環境の場合も、同様の機能をもったＡＰＩを規定する。
【００６５】
[２．３．２．３ ＢＭＬ（Broadcast Markup Language）からの起動]
受信機は、放送通信連携アプリケーション実行環境に加えて、現行のＢＭＬデータ放送の実行環境を備えることから、ＢＭＬのＡＰＩとして放送通信連携アプリケーションの起動を制御するＡＰＩを追加する。なお、ＢＭＬは、ＡＲＩＢ ＳＴＤ Ｂ２４に規定されるマルチメディア符号化方式であり、現行の日本の地上・ＢＳ・ＣＳデジタル放送におけるデータ放送方式として採用されている。
【００６６】
[２．３．２．４ 独立して動作するアプリケーションの起動]
独立型サービスは、アプリケーションのみを含む仮想的なサービスであり、独立アプリケーションを選択することで、２．３．２．１節のＡＩＴによる起動と同じメカニズムによりＡＩＴを取得してアプリケーションが起動される。ただし、独立型サービスでは、少なくとも１つのauto-startアプリケーションが起動される。独立型サービスの選択は、例えば、アプリケーションローンチャーから行う。
【００６７】
[２．３．３ アプリケーションの終了]
[２．３．３．１ ＡＩＴによる終了]
起動されたアプリケーションは、そのサービスに対するアプリケーションシグナリングによってライフサイクルが制御される。例えば、放送の場合は、放送と共に伝送されるＡＩＴを受信機が常に監視し、起動中のアプリケーションに対して制御コードdestroyを指定することで、アプリケーションを終了する。通信で伝送するストリーム従属型サービスにＡＩＴが多重されている場合も、連動するアプリケーションの終了制御が可能である。
【００６８】
[２．３．３．２ アプリケーション自身による終了]
アプリケーション自身が、終了用のＡＰＩを用いて自ら終了する。
【００６９】
[２．３．３．３ 他のアプリケーションによる終了]
アプリケーションが実行するアプリケーション終了用のＡＰＩを用いて、起動中の他のアプリケーションを終了させる。この場合、他のアプリケーションを終了させる適切なセキュリティポリシーが必要である。
【００７０】
[２．３．３．４ 別のサービスへの切替え時の終了]
受信機における別のサービスへの切り替え時、ストリーム従属型サービスに含まれるアプリケーションのうち、切り替え前のサービスに含まれるアプリケーションは終了し、新しいサービスでシグナリングされたアプリケーションが起動される。切り替え前後のサービスに同じアプリケーションが含まれる場合は、動作を継続することも可能とする。これは、ＡＩＴ中のフラグで制御する。ストリーム従属型サービスに含まれるアプリケーションであるサービスバウンドアプリケーションの詳細は、４．２節に後述する。
【００７１】
[２．３．３．５ 受信機による終了]
受信機は、指定したアプリケーションを受信機機能により終了する。例えば、受信機が起動中のアプリケーション一覧を表示し、視聴者の選択によって指定のアプリケーションを終了させる。
【００７２】
[２．３．３．６ 動的なアプリケーション終了]
アプリケーションの終了を動的に制御するため、アプリケーションの終了を指示するＡＩＴのファイルを受信機に送信する。この場合、ＡＩＴをプッシュ通知（Notification）する。
【００７３】
[２．３．４ 複数アプリケーションの起動]
[２．３．４．１ 同一サービス内でシグナリングされたアプリケーション]
受信機は、同一のサービスにおいてＡＩＴにリストされたアプリケーションを同時実行させることができる。
【００７４】
[２．３．４．２ ＡＶコンテンツに連動するアプリケーションと独立して動作するアプリケーションの同時起動]
ＡＶコンテンツに連動するアプリケーションは、ストリーム従属型サービス内でしか起動されない。一方、独立して動作するアプリケーションは、任意のタイミングでＡＶコンテンツに連動するアプリケーションや独立して動作する他のアプリケーションと同時に起動可能とする。
【００７５】
[２．３．４．３ 複数アプリケーション起動時のリソース管理]
複数のアプリケーションが起動する場合、それらが同じ受信機のリソース（例えばディスプレイ）を必要とする場合がある。受信機は、リソースマネージャなどの仕組みを備えて、適切にリソースを割り振ったり、リソースが使用出来ない場合はアプリケーションの実行をやめたりするなどの動作を行う。
【００７６】
[２．４ アプリケーションのバウンダリ]
[２．４．１ バウンド／アンバウンドの基本的な扱い]
アプリケーションは編成サービスに紐付いた（対応付けられた）バウンドアプリケーションと紐付かない（対応付けられていない）アンバウンドアプリケーションの２種類がある。バウンドアプリケーションがどの編成サービスと紐付いているかは、当該アプリケーションの起動情報を含んでいるＡＩＴがどの編成サービスから得られたかで判定する。
【００７７】
バウンドアプリケーションは、紐付いている編成サービスを受信しているときに実行可能な状態になる。つまり、当該編成サービスからＡＩＴによって起動され、当該編成サービスの受信が終了したとき(受信している編成チャンネルが変更されたとき)には実行が終了する。バウンドアプリケーションから起動された別のアプリケーションもバウンドアプリケーションとして扱う。関連する一連のバウンドアプリケーション群の大本である最初に起動されたアプリケーションが終了したときには、それによって起動された他のアプリケーションも終了する。
【００７８】
アンバウンドアプリケーションは編成サービスに紐付いていないので、受信している編成サービスを変更してもアプリケーションの実行は継続される。編成サービスからはアプリケーションを起動するためのＡＩＴが得られないので、他の手段(例えば、アプリケーションと紐付いているＡＩＴ Ｆｉｌｅ（ファイル）を、アプリケーションローンチャー等を用いて入手するなど)によって起動情報が受信機に与えられ、起動される。アンバウンドアプリケーションから起動された別のアプリケーションもアンバウンドアプリケーションとして扱う。アプリケーションは、視聴者の操作によって明示的に終了することが基本であるが、受信している編成サービスから全てのアプリケーションを終了させる指示（KILLALL）がＡＩＴによって与えられた場合にも終了する。
【００７９】
[２．４．２ アンバウンドアプリケーション固有の扱い]
アンバウンドアプリケーションは編成サービスと紐付かないが、２．３．２．４節で示すように、仮想的な編成サービス(受信機の起動時に受信機内に生成される)に紐付けることにより、バウンドアプリケーションと同じ起動処理メカニズムが適用できる。
【００８０】
仮想的な編成サービスの生成方法は受信機の実装依存であり、その編成サービスにどのような識別値を与えるかは受信機実装によって異なる。しかし、アプリケーションファイルを受信機内に蓄積しておいて任意のタイミングでアプリケーションローンチャーから起動できるようにしておく場合、仮想的な編成サービスを識別するＩＤやアプリケーションファイルの取得先(サービス事業者サーバないしはリポジトリから取得したＡＩＴには当該サーバが取得先として記述されているので、受信機内の蓄積領域から取得するように変更する必要がある)などが受信機実装に合うようにＡＩＴの内容を受信機が更新する必要がある。
【００８１】
[２．５ アプリケーションの取得方法]
[２．５．１ ＡＩＴをもとにした取得]
上記の記述のとおり、全てのアプリケーションの起動情報はＡＩＴにより与えられる。
アプリケーションファイルの取得は、ＡＩＴに含まれるアプリケーションのロケーション情報により指示される。例えば、図３の例ではロケーション情報は、「/ApplicationList/Application/applicationSpecificDescriptor/dvbjDescriptor/location」の階層に記述される(ＸＭＬとしてはlocation要素の内容として記述される)。ロケーション情報の記述は、例えば、「http://192.168.11.37/demo.jar」となる。
上記は、ＨＴＴＰ（Hypertext Transfer Protocol）プロトコルを用いて、demo.jar（Ｊａｖａ（登録商標）のアプリケーションアーカイブ）を取得する例である。使用するトランスポートプロトコルや、アプリケーションのパッケージフォーマットについては、後述する。
【００８２】
[２．５．２ アプリケーションのパッケージフォーマット]
アプリケーションのパッケージフォーマットは、アプリケーションフォーマット（Ｊａｖａ（登録商標）やＨＴＭＬ５）などに依存する。受信機は、何らかのひとかたまりになったファイル、もしくはエントリーファイルを取得することによって、アプリケーション起動に必要な一連のファイル（プログラム本体や画像ファイルなど）を取得する。この一連のファイルがアプリケーションファイルである。例えば、アプリケーションファイルには、一連のファイルを圧縮したもの（ｚｉｐファイル等）、Ｊａｒファイル（Ｊａｖａ（登録商標）実行環境）、エントリーのＨＴＭＬファイル（ＨＴＭＬ５実行環境の場合）、独自に規定したエントリーファイルなどのフォーマットが使用される。
【００８３】
[２．５．３ アプリケーションの伝送方法]
アプリケーションファイルをネットワーク経由で取得する際の伝送方法には、ＨＴＴＰプロトコルによる取得と、ＦＩＬＥプロトコルによる取得とがある。
ＨＴＴＰプロトコルによる取得の場合、GETメソッドにより取得する。ＡＩＴのロケーションの指定は、「http://〜」とする。
一方、ＦＩＬＥプロトコルによる取得の場合、受信機のローカルに保存された（インストールされた）アプリケーションファイル（アプリケーションプログラム）を指定するときには、ＡＩＴのロケーションの指定を「file:///〜」とする。
【００８４】
[３． インタフェース条件]
[３．１ 放送波の放送通信連携サービス制御信号]
放送波には、２．２．２節で前述したアプリケーション起動情報を送出するメカニズムが必要である。さらに、緊急警報放送時などを想定して、全てのアプリケーションを強制終了させるために、ＡＲＩＢ ＳＴＤ−Ｂ２３第二部 １０．１６．３．２節で規定するＡＩＴのアプリケーション制御コード(application_control_code)に「KILLALL」を追加する。表１は、追加する制御コード「KILLALL」の意味を示す。
【００８５】
【表１】
【００８６】
また、アプリケーションとＡＶコンテンツの関係からアプリケーションの提示制御を行うために、ＥＩＴ、ＡＩＴに記述子を追加する。詳細は４．３節に後述する。
【００８７】
[３．２ 放送局サーバ群ＡＰＩ]
図８は、放送通信連携システムにおける事業者間のデータの流れを示す図であり、図９は、放送通信連携システム全体におけるデータの流れを示す図である。
ここでは、図８に示す、放送局サーバ群とサービス事業者サーバ群のサービス毎のサーバとの間、放送局サーバ群と放送通信連携基盤サーバとの間、及び、放送通信連携基盤サーバとサービス事業者サーバ群のサービス毎のサーバとの間のＡＰＩの規定、図９に示す、受信機制御と放送通信連携基盤サーバとの間、メタデータとサービス毎のサーバとの間のＡＰＩについて述べる。
【００８８】
[３．２．１ ＡＰＩ］
放送局サーバ群を構成する各サーバである放送局サーバと、サービス事業者サーバ群を構成する各サーバであるサービス事業者サーバとの間の通信はＲＥＳＴ形式とする。また、放送局サーバとサービス事業者サーバとの間は、提供するサービスに応じてサーバのディレクトリー構成が異なることが予想されるため、ＡＰＩは双方間で取り決める。放送局サーバ及びサービス事業者サーバのＵＲＬの例を以下に示す。
【００８９】
http://hybridcast.org/{放送局名}/{サーバ名}/{コンテントID}/{管理するデータ}/{ソート方法}/{先頭アイテム},{個数}/?{パラメータ}={値}/
【００９０】
［３．２．２ レコメンドサービス］
図１０は、レコメンドサービスのシーケンスを示す図である。サービス事業者サーバ群と、放送局サーバのインタフェース部との間で使用されるメソッドは、「GET」、「POST」、「PUT」、「DELETE」である。コマンドフォーマットの例を以下に示す。
【００９１】
（１）http://hybridcast.or.jp/{放送局名}/(サーバ名)/{コンテントＩＤ}/{管理するデータ}/{ソート方法}/{先頭アイテム},{個数}/
（２）http://hybridcast.or.jp/{放送局名}/(サーバ名)/{視聴者ＩＤ}/{管理するデータ}/{ソート方法}/{先頭アイテム},{個数}/
（３）http://hybridcast.or.jp/{放送局名}/(サーバ名)/{レビューＩＤ}/{管理するデータ}/{ソート方法}/{先頭アイテム},{個数}/
【００９２】
また、パラメータには、{放送局名}、{サーバ名}、{コンテントＩＤ}、{視聴者ＩＤ}、{レビューＩＤ}、{管理するデータ}、{ソート方法}、{先頭アイテム}、{個数}等々がある。
【００９３】
［３．２．３ 管理対象のデータ］
管理対象のデータには、コンテンツ情報、ユーザ情報、ユーザ・ジェネレイテッド・コンテンツ情報、デバイス情報、認証情報がある。
コンテンツ情報は、タイトル、概要、ジャンル、放送日時、放送時間（尺）、映像モード、音声モード、字幕データ、台本、出演者、音楽、制作者、製作会社、著作、推薦番組、動画URI、再生回数、ＣＭ、タイムスタンプ情報、等を示すデータを含む。ユーザ情報は、ユーザ（視聴者）の名前、年齢、性別、地域、レビュー書込み数、コメント書込み数、お気に入り、フレンドリスト、再生場所（時刻）、再生終了場所（時刻）、番組視聴履歴等を示すデータを含む。ユーザ・ジェネレイテッド・コンテンツ情報は、コンテンツＩＤ、ユーザＩＤ、レビュー内容、レビュー書込み時刻、レビュー評価、等を示すデータを含む。デバイス情報は、デバイスＩＤを含む。認証情報は、認証ＩＤを含む。
【００９４】
［３． トランスポートフォーマット］
［３．３．１ 通信で扱う映像/音声について］
通信で扱う映像や音声は、デジタルテレビネットワーク機能仕様 ストリーミング機能仕様書 プロトコル編V1.1(デジタルテレビ情報化研究会)に準拠する。
【００９５】
［３．３．１．１ 映像・音声のモノメディアフォーマットとの関連］
ＭＰＥＧ−２ ＶｉｄｅｏあるいはＨ．２６４／ＭＰＥＧ−４ ＡＶＣ（Advanced Video Coding）で符号化された映像と、ＭＰＥＧ−１ Ａｕｄｉｏ Ｌａｙｅｒ II、ＭＰＥＧ−２ Ａｕｄｉｏ ＡＡＣで符号化された音声、および字幕等の多重化には、ＴＴＳ（Timestamped Transport Stream）形式を使用する。ただし、ＭＰＥＧ２−ＴＳ、ＭＭＴ（MPEG Media Transport）、ＭＰ４等も使用可能である。
【００９６】
［３．３．１．２ 転送プロトコル関係］
図１１は、転送プロトコルスタックを示す図である。
ストリーム伝送は、ＲＴＰ（Real-Time Transport Protocol）／ＵＤＰ（User Datagram protocol）およびＨＴＴＰ／ＴＣＰ（Transmission Control Protocol）を用いる。なお、ＲＴＰ／ＵＤＰを用いる場合、オプションとして、誤り訂正の情報を伝送してもよい。また、ＨＴＴＰ／ＴＣＰを用いる場合、ＨＴＴＰのコネクション、メソッド、ヘッダを利用してストリーム制御を行う。伝送がＲＴＰ（Real-time Transport Protocol）で行われる場合、ストリーム制御情報はＲＴＳＰ（Real Time Streaming Protocol）を用いる。
【００９７】
［３．３．２ 字幕関連］
多言語字幕は、Timed Text Markup Language（Ｗ３Ｃ（World Wide Web Consortium））に準拠する。なお、同期については別途アプリケーションレベルで実施する。また、各対応フォントはサーバから必要に応じてダウンロードする。例えば、ＨＴＴＰのペイロードにフォントファイルを載せる。この場合、ＷｅｂのDynamic Fonts、ＰＦＲ（PortableFont Resource）を利用する。
フォントの容量は約５−３５ＭＢ（メガバイト）程度が望ましい。
【００９８】
［３．４ モノメディアフォーマット］
放送通信連携サービスにおけるモノメディア符号化は下記に定義されたものを用いる。
【００９９】
［３．４．１ 動画］
動画には、ＡＲＩＢ ＳＴＤ−Ｂ３２ ２．４版第１部３．１節で規定されるＭＰＥＧ−２ Ｖｉｄｅｏ方式および同３．２節で規定されるＭＰＥＧ４−ＡＶＣ方式が用いられ、同５．１節で規定されるテレビジョンサービスの符号化パラメータの制約条件が適用される。
【０１００】
［３．４．２ 音声］
音声には、ＭＰＥＧ−２ Ａｕｄｉｏや、ＰＣＭ（Pulse Code Modulation）（ＡＩＦＦ−Ｃ（Audio Interchange File Format Compression））を用いる。
ＭＰＥＧ−２ Ａｕｄｉｏの場合、ＡＲＩＢ ＳＴＤ−Ｂ３２ ２．４版第２部３．１節で規定されるＭＰＥＧ−２ ＡＡＣ方式が用いられ、同第５章で規定される符号化パラメータの制約条件が適用される。
ＰＣＭの場合、ＡＲＩＢ ＳＴＤ−Ｂ２４ ５．４版第一編第２部６．２節で規定される方式が用いられる。
付加音には、ＡＲＩＢ ＳＴＤ−Ｂ２４ ５．４版第一編第２部６．４節で規定される方式が用いられる。
【０１０１】
［３．４．３ 静止画］
ＪＰＥＧ（Joint Photographic Experts Group）の場合、ＡＲＩＢ ＳＴＤ−Ｂ２４
５．４版第一編第２部５．２節で規定される符号化方式が用いられる。
ＰＮＧ（Portable Network Graphics：ポータブル・ネットワーク・グラフィックス）の場合、ＩＳＯ／ＩＥＣ １５９４８：２００３にて規定される方式が用いられる。これは、W3C Recommendation Portable Network Graphics (PNG) Specification (Second Edition)と同内容である
【０１０２】
［３．４．４ 文字］
文字符号化には、ＡＲＩＢ ＳＴＤ−Ｂ２４ ５．４版第一編第２部７．２節で規定される国際符号化文字集合が用いられる。
文字符号集合には、同７．２．１．１．３節で規定されるＢＭＰ（Basic Multilingual Plane）セットが用られ、表７−２０が適用される。また、ＩＳＯ／ＩＥＣ１０６４６：２００３追補５および同追補６が適用される。
外字には、ＡＲＩＢ ＳＴＤ−Ｂ２４ ５．４版第一編第２部７．２．１．２節で規定される方式またはＡＲＩＢ ＳＴＤ−Ｂ２３第一部５．２．１．２節で規定される方式などが適用される。
制御符号には、ＡＲＩＢ ＳＴＤ−Ｂ２４ ５．４版第一編第２部７．２．２．１節で規定されるＣ０制御符号のうち、ＡＰＲ(ＣＲ)、ＡＰＤ(ＬＦ)のみが用いられる。その他のＣ０制御符号およびＣ１制御符号は用いられない。
文字符号の変換は、ＡＲＩＢ ＳＴＤ−Ｂ２４ ５．４版第一編第２部付録規定Ｅに従う。
【０１０３】
上記に規定する文字符号化方式以外の方式で情報が符号化されている場合、送出ないしは受信機内の適切なプロセスにおいて上記の文字符号化方式に変換し、処理を行う。すなわち、他の符号化方式による文字符号をアプリケーションからは直接扱わない。
【０１０４】
［３．５ アプリケーションフォーマット］
受信機上で実行可能なアプリケーションの記述方法を示す。この記述方法により作成されたアプリケーションを実行するための実行環境と、セキュアマネージャとの結合については４章に示す。
【０１０５】
［３．５．１ 受信機で実行可能なアプリケーションフォーマット］
受信機で実行可能なアプリケーションの記述方式として、ＢＭＬ(ＡＲＩＢ ＳＴＤ−Ｂ２４)、ＡＲＩＢ−Ｊ(ＡＲＩＢ ＳＴＤ−Ｂ２３)、ＨＴＭＬ５（Ｗ３Ｃ ＨＴＭＬ５
Ｗｏｒｋｉｎｇ ｄｒａｆｔ − ２０１１／Ｊａｎ／１３）を規定する。
【０１０６】
［３．５．２ ＢＭＬ］
受信機は、地上デジタル放送運用規定(ＡＲＩＢ ＴＲ−Ｂ１４）またはＢＳデジタル放送運用規定(ＡＲＩＢ ＴＲ−Ｂ１５）に準ずるＢＭＬ文書を提示する機能を有する。
受信機は、地上デジタル放送またはＢＳデジタル放送で提供されるデータ放送サービスを既存の規格どおりに提示できなくてはならない。ただし、受信機は、放送でデータカルーセル方式によって配信されるＢＭＬコンテンツの提示のみを必須とし、通信でＨＴＴＰプロトコルによって提供されるＢＭＬコンテンツ（ＴＲ−Ｂ１４ 第三編第２部５．１４節、ＴＲ−Ｂ１５ 第一部第三編８．１４節)の提示は必須としない。
【０１０７】
また、データ放送コンテンツ(ＢＭＬ)を起点として、以下に規定される通信アプリケーションの起動を行うための放送用拡張ＡＰＩとして、browser.startHybridcastApp()、getAITInfo()を規定する。
【０１０８】
表２は、browser.startHybridcastApp()の規定を示す。browser.startHybridcastApp()は、放送通信連携アプリケーションを起動するＡＰＩである。
【０１０９】
【表２】
【０１１０】
表３は、getAITInfo()の規定を示す。getAITInfo()は、受信中のサービスに含まれる最新のＡＩＴ情報を取得するＡＰＩである。
【０１１１】
【表３】
【０１１２】
［３．５．３ ＨＴＭＬ５］
［３．５．３．１ 記述方式］
受信機は、通信から提供されるプレゼンテーションエンジン型アプリケーションの記述方式としてＨＴＭＬ５をサポートする。JavaScript APIとして、下記のものをサポートする。なお、下記のＡＰＩのうち、Ｗ３Ｃで検討が行われているものにはWorking Draft(WD)またはEditor’s Draft(ED)が含まれる。ただし、放送波で伝送されるデータカルーセルに関連するＡＰＩは必須としない。
【０１１３】
（１）System Information API(W3C Working Draft 02 Feb. 2010)（２）WebSocket API(W3C Editor’s Draft 28 Feb. 2011)（３）File API(W3C Working Draft 26 Oct. 2010)（４）Permission for File API, System Information API(Permissions for Device API Access, W3C Working Draft 05 Oct. 2010)（５）Device Description Repository Simple API(W3C Recommendation 05 Dec. 2008)（６）API for Media Resource 1.0(W3C Working Draft 08 June 2010)（７）Web Storage(W3C Working Draft 08 Feb. 2011)（８）Server-Sent Events(W3C Editor’s Draft 28 Feb. 2011)（９）Indexed Database API(W3C Working Draft 19 Aug. 2010)（１０）SIアクセスAPI
（１１）選局API
（１２）印刷
（１３）予約
【０１１４】
［３．５．３．２ ブラウザ］
受信機のＨＴＭＬ５ブラウザは、JavaScript処理系、Web Workers（W3C Working Draft 08 Feb. 2011）、Widget Interface（W3C Working Draft 3 Feb. 2011）、HTML Canvas2D Context（W3C Editor’s Draft 28 Feb. 2011）の機能を実装する。Web Workersは、マルチタスクをサポートするため、Widget Interfaceは、独立アプリケーションをサポートするため、HTML Canvas 2D Contextは、２次元ベクトルグラフィックスをサポートするために必要である。
【０１１５】
［３．５．４ ＡＲＩＢ−Ｊ］
受信機は、通信から提供されるアプリケーション実行エンジン型アプリケーションの記述方式としてＡＲＩＢ−Ｊをサポートする。また、複数ストリーム間の同期ＡＰＩとしてDVB Bluebook A153（GEM Media Synchronization API）を用いる。
【０１１６】
［３．６ 受信機ＡＰＩ］
以下に、ＨＴＭＬ５およびＡＲＩＢ−Ｊで使用可能な受信機ＡＰＩについて説明する。
【０１１７】
［３．６．１ 名前空間］
名前空間とは、サーバ上や受信機内に存在する、映像音声コンテンツ、アプリケーション、モノメディアファイルなど、放送通信連携システムで扱う様々なリソースの位置を特定するための文字列の記述規則である。３．５．２節以降で使用する各種リソースを参照するための名前空間の記法は分類毎に規定する。リソースには、インターネットサーバー上のリソース、アプリケーションキャッシュ上のリソース、放送のリソースがある。インターネットサーバー上のリソースには、ＶＯＤコンテンツなどのストリームリソースや、アプリケーション、アプリケーションから参照されるその他のリソースなどのファイルリソースがある。放送のリソースには、放送中の番組、過去・未来の番組などのストリームリソースや、モジュール、イベントメッセージなどのカルーセルリソースがある。
【０１１８】
［３．６．２ 放送通信連携インタフェース］
放送通信連携インタフェースには、以下のインタフェースがある。
【０１１９】
（１）getRunningApplications()：実行中のアプリケーションの情報を取得する。getRunningApplicationsの戻り値は、apps[]と、アプリケーション毎のapplication_id及びrunning_levelとを含む。apps[]には、実行中アプリケーションのリストが設定される。application_idには、アプリケーションＩＤが設定され、アプリケーションが一般アプリケーション（非公式アプリケーション）の場合はnullである。running_levelには、実行レベル（認証結果および視聴者設定の状態）が設定される。
なお、セキュリティ上の観点から、他アプリケーションに関して取得できる情報は制限すべきである。
【０１２０】
（２）queryApplicationInfo()：指定したアプリケーションの情報を取得する。
（３）getProgramInfo()：受信中の放送の情報を取得する。戻り値は、tuner_state、network_id、ts_id、orig_ts_id、service_id、event_id、content_idである。tuner_stateには、受信状態を表す値が設定される。
（４）getEPGInfo()：受信中の放送のＥＩＴ（＋ＳＤＴ）中の各種情報を取得する。
（５）saveApplicationToCache()：サーバ上のアプリケーションファイルをキャッシュに保存する。
【０１２１】
（６）queryApplicationInCache()：キャッシュ中のアプリケーションファイル（アプリケーションプログラム）を検索する。queryApplicationInCache()の引数は、application_id、getDSMCCModule()、addBroadcastSignalListener()、getListFromHybridcastMenu()である。application_idには、認証機関から発行されたアプリケーションＩＤが設定される。getDSMCCModule()は、放送波から指定のモジュールを取得する。addBroadcastSignalListener()は、ＳＩ、緊急情報、カルーセルおよびイベントメッセージの更新を監視するリスナを登録する。getListFromHybridcastMenu()は、トップメニューアプリケーションのリストを取得する。queryApplicationInCache()の戻り値は、user_apps[]、broadcaster_apps[]、vendor_apps[]である。
【０１２２】
（７）addApplicationToHybridcastMenu()：トップメニューにアプリケーションを追加する。
（８）getKeyFromBroadcast()：放送から限定サーバーアクセスのための鍵情報を取得する。
（９）querySupportedFunction()：アプリケーションブラウザの機能を問い合わせる。これは、機能/ＡＰＩが利用可能かチェックすることを目的として使用される。
【０１２３】
［３．６．３ BroadacastSignalListenerインタフェース］
BroadacastSignalListenerインタフェースは、放送から取得するＳＩ、緊急情報、カルーセル、イベントメッセージを監視するためのリスナーインタフェースである。バウンドアプリケーション実行中に、紐付いている編成サービスが変更された場合にもこのインタフェースのイベントが発生する。
【０１２４】
［３．６．４ LocalDatabaseインタフェース］
LocalDatabaseインタフェースは、視聴者情報を受信機内で保持・管理するためのインタフェースである。視聴者情報は、個人情報などサーバ側に出すべきでない情報であり、視聴者ＩＤ、受信機ＩＤなど最低限の情報である。
【０１２５】
［３．６．５ 同期関連ＡＰＩ］
SynchronizationManagerインタフェースとして、DVB Bluebook A153(GEM Stream Synchronization API)と同様のＡＰＩを導入する。さらに、以下のインタフェースをＡＰＩとして追加する。
【０１２６】
（１）getCurrentSTC()：現在のＳＴＣ（System Time Clock）値を取得する。なお、ＭＰＥＧ ２ Ｓｙｓｔｅｍｓ規格では、送信側のシステムクロック（ＳＴＣ）をＭＰＥＧ２トランスポートストリーム中のＰＣＲ（Program Clock Reference）信号として多重し配信することで、受信機内部のシステムクロック（ＳＴＣ）が送信側のＳＴＣと同期されるように規定している。
（２）getCurrentPositionInProgram()：番組開始からの経過時間を取得する。
（３）delayStreamPresentation()：提示中の放送ストリームの遅延提示を開始する。
（４）getCurrentDelay()：提示中の放送ストリームの（本来の提示時刻からの）遅延時間量を取得する。
【０１２７】
［３．６．６ SecurityExceptionインタフェース］
アプリケーションが、現在の実行レベルにおいて禁止されている関数呼び出しおよびプロパティ操作をした場合に発生する例外のインタフェースである。ecurityExceptionインタフェースは、上記各ＡＰＩの呼び出し、あるいは、放送を参照するオブジェクト(ＨＴＭＬ５なら<video>、ＡＲＩＢ−Ｊなら○○Controller)に対する各種操作によって発生する。
【０１２８】
［３．７ 受信機機能］
放送通信連携システムの受信機は、受信機機能として、アプリケーションローンチャーを備える。アプリケーションローンチャーは、受信機内に蓄積されたアプリケーションの起動、既知のリポジトリから独立アプリケーションの選択、ＡＩＴによって起動指示が記述されたアプリケーションのうち、コントロールコードが「PRESENT」のアプリケーションの選択に用いる。
【０１２９】
［４． セキュリティ］
［４．１ 放送通信連携アプリケーションの管理］
放送事業者の要件を満たしつつ放送通信連携サービスを普及・活性化させるために、放送事業者およびその関係者だけではなく、幅広いサービス事業者や個人が参入できる枠組みが必要となる。本放送通信連携システムでは、セキュリティの観点からアプリケーションを「Ａアプリケーション」と「一般アプリケーション」に分類し、受信機において双方のアプリケーションを実行可能とする。
【０１３０】
図１２は、放送通信連携システムにおけるアプリケーション管理モデルを示す。「Ａアプリケーション」は、登録管理者（第三者機関）への事前登録を行うことにより放送通信連携システムの仕様で期待する動作が保証される。「Ａアプリケーション」は、登録時にＩＤと署名が付与され、受信機において２．２節で定義するセキュアマネージャーにより署名が検証され、すべてのＡＰＩへのアクセスが可能となり、放送リソースを利用した番組連動サービスが行えるようになる。また、放送事業者から送出されるＡＩＴにより、放送事業者の要件に沿ったきめ細かい提示制御が可能となる。
一方、「一般アプリケーション」は、事前の登録は不要であるが、放送通信連携システムの仕様で期待する動作は保証されず、アプリケーションから放送関連のＡＰＩを扱うことはできない。「一般アプリケーション」はＩＤと署名が付与されないため、個々のアプリケーションの指定は困難であるが、放送事業者の要件に基づいた提示制限を加えた上で実行させることは可能である。
【０１３１】
［４．２ セキュアマネージャーの機能モデル］
図１３は、セキュアマネージャーの機能モデルを示す。セキュアマネージャーは、受信機においてセキュリティを総合的に管理する機能である。
【０１３２】
［４．２．１ アプリケーション監視・制御機能］
受信機において動作するアプリケーションは、アプリケーションファイルの配布の形態により、上述したように、「Ａアプリケーション」と「一般アプリケーション」の２種類に大別される。「Ａアプリケーション」と「一般アプリケーション」は、４．１節に示すようにＩＤと署名の有無によって区別され、受信機におけるＡＰＩのアクセス範囲や放送事業者からの制御範囲が異なるなど、アプリケーション実行時の動作内容が異なる。アプリケーション監視・制御機能は、Ａアプリケーションまたは一般アプリケーションの種別の違いを識別し、確実にアプリケーション実行時の動作を制御することを目的とする。
【０１３３】
（１）アプリケーション認証：受信機は、実行するすべてのアプリケーションについて、Ａアプリケーションまたは一般アプリケーションのいずれか、さらにＡアプリケーションであればＩＤを識別する。Ａアプリケーションまたは一般アプリケーションの区別は、アプリケーションファイル（アプリケーションプログラム）に付与された署名の有無を確認しこれを検証することによって行う。Ａアプリケーションであれば、受信機はさらに、署名に記述されたアプリケーションＩＤを取得する。アプリケーションの識別は、アプリケーションの取得時、または、起動時に行うものとする。
（２）画面提示制御：４．３節に後述する。
（３）リソースアクセス制御：受信機は、実行中のアプリケーションの放送リソース等のＡＰＩへのアクセス制御を行う。アプリケーションがＡＰＩにアクセスしようとする時に、当該アプリケーションが一般アプリケーションであれば、ＡＰＩの種別によってアクセスを制限する。
また、アプリケーションがディスプレイへの画面表示ＡＰＩにアクセスする際には、Ａアプリケーションまたは一般アプリケーションの種別と、選局中の放送事業者の提示ポリシーに基づき、画面提示制御を実行する。詳細は４．３節に後述する。
（４）リボケーション：アプリケーションのリボケーション機能を備える。
【０１３４】
［４．２．２ 受信機保護］
受信機は、視聴者情報保護およびウィルス対策等の保護機能を備える。
【０１３５】
［４．３ アプリケーションの画面提示制御］
［４．３．１ 画面提示制御の概要］
放送通信連携サービスでは、放送番組と同時に関連する通信アプリケーションを提示させることにより、放送サービスの利便性を拡張することができる。一方、通信サービスの利用により、受信機の画面上で放送番組と通信アプリケーションが混在して提示されることが想定される。提示方法によっては、放送番組に通信アプリケーションの画面が重なり、放送番組の一意性や作品性が損なわれるだけでなく、緊急地震速報などの緊急性の高い情報が正確に視聴者に伝えられなくなる恐れがある。画面提示制御により、放送通信連携サービスにおいて、放送事業者の意図に基づいたアプリケーションの提示制御を行う。
【０１３６】
図１４は、画面提示制御方式の概念を示す図である。画面提示制御方式は、個々の放送番組に対して通信アプリケーションをどのように画面上に提示させるかという放送事業者の提示ポリシーを受信機に反映させることを意図したもので、これをコンテンツの提示制御と呼ぶこととする。コンテンツの提示制御では、編成に応じた番組単位の提示制御、緊急地震速報などの番組中に発生するイベントに対する提示制御、アプリケーション単位の提示制御を実現する。
【０１３７】
［４．３．２ 画面提示制御の基本動作］
図１５は、画面提示制御の基本動作モデルを示す図である。放送事業者の提示ポリシーを受信機に反映させるために、予め放送事業者が想定した、放送番組に対する通信コンテンツの提示方法を、提示ルールとして受信機で管理する。具体的には、通信コンテンツの提示方法として、重ね合わせの順序や並べ方の違いなどに応じてレベル分けを行い、提示レベル（ポリシーレベル）と提示方法のテーブルを提示ルールとして受信機内に保持する。放送事業者は指定する提示レベルを放送波に多重して伝送し、受信機はその提示レベルと提示ルールを照合し、提示方法を決定する。これにより、放送事業者の提示ポリシーに基づいた提示制御を実現することができる。
【０１３８】
［４．３．３ 制御情報の伝送・多重方式］
放送事業者の提示ポリシーを伝送する制御情報のフォーマットに関して、デジタル放送で使用されている番組配列情報を用いる方式として３つの具体例を挙げる。番組単位での画面提示制御として、既存のＥＩＴ(イベント情報テーブル：Event Information Table)を用いる方式と、ＥＩＴを拡張して用いる方式（ＥＩＴ＋）がある。また、サービス（チャンネル）単位での画面提示制御として、放送信号のＡＩＴを拡張して用いる方式がある。さらに、番組中にリアルタイムに発生する事象単位での画面提示制御として、番組配列情報以外の放送局から送出される情報を用いる方式がある。以下に、４つの方式の詳細を記載する。
【０１３９】
（１）ＥＩＴの番組ジャンル（ＥＩＴ）：既存のＥＩＴのコンテント記述子に記述される番組ジャンルからポリシーレベルを判断する。受信機はそのために、番組ジャンルとポリシーレベルの対応表を管理する。ＡＲＩＢ規格との関連は、ＡＲＩＢ ＳＴＤ−Ｂ１０
第２部 ６．２．４、付録Ｈである。
【０１４０】
表４は、番組ジャンルとポリシーレベルの関係の具体例を示す表である。番組ジャンル（program_genre）は、大分類を表す「content_nibble_level1」（0x0〜0xF）と、中分類を表す「content_nibble_level2」（0x0〜0xF）の２段階で構成される。受信機で管理するテーブルは中分類のジャンルまで対象とし、それぞれポリシーレベルの値を定義する。
【０１４１】
【表４】
【０１４２】
（２）ＥＩＴに新記述子追加（ＥＩＴ＋）：ＥＩＴのイベント情報セクションに新しい記述子を追加し、ポリシー情報を記述する。受信機は、この記述子を解釈し所望の処理を実行することで、番組単位でのポリシーレベルに応じた制御を実現する。ＡＲＩＢ規格との関連は、ＡＲＩＢ ＴＲ−Ｂ１４（第二分冊） 第３部 ３１．３、ＡＲＩＢ ＳＴＤ−Ｂ１０ 第２編 ５．２．７である。
【０１４３】
表５は、イベントセキュリティ記述子の構造を示す表である。ＥＩＴ＋の場合、同図に示すイベントセキュリティ記述子を新規に定義し、ＥＩＴ内の記述子領域にこのイベントセキュリティ記述子を格納して伝送する。イベントセキュリティ記述子には、ポリシーレベル（policy_level）、アプリケーションＩＤ（application_identifier）、制御コード（application_control_code）、優先度（application_priority）、プロトコル識別（protocol_id）、番組関連フラグ（associated_application_flag）を設定する。
【０１４４】
【表５】
【０１４５】
policy_levelは、番組単位でのポリシーレベルを表す。ポリシーレベルは、１〜４の値とする。
application_identifier()は、アプリケーションを識別するための識別子である。表６は、application_identifier()の構造を示す。
【０１４６】
【表６】
【０１４７】
organization_idは、アプリケーションを作成した組織を表し、0x00000063以降の値をとる。application_idは、アプリケーションを識別する番号を表す。application_idは、組織識別内で一意に付与される。
【０１４８】
application_control_codeは、アプリケーション状態を制御する制御コードを規定する。表７は、制御コードの規定を示す。
【０１４９】
【表７】
【０１５０】
application_priorityは、アプリケーション毎のポリシーレベルを示す。アプリケーション毎のポリシーレベルは、サービス内で告知されているアプリケーション間の相対的な優先度を示す。優先度は、１〜４の値とする。
【０１５１】
protocol_idは、アプリケーションファイルを伝送するプロトコルを示す。表８は、protocol_idの規定を示す。
【０１５２】
【表８】
【０１５３】
associated_application_flagは、番組に連動するアプリケーションであるか否かを示す。表９は、protocol_idの規定を示す。
【０１５４】
【表９】
【０１５５】
（３）ＡＩＴのテーブル定義および新記述子の追加（ＡＩＴ＋）：ＡＩＴを拡張してポリシー情報を伝送する。受信機は、このテーブルを解釈し所望の処理を実行することで、随時発生するイベントに対してポリシーレベルに応じた制御を実現する。ＡＲＩＢ規格との関連は、ＡＲＩＢ ＳＴＤ−Ｂ２３ 第２部 １０．１６である。
【０１５６】
表１０に、ＡＩＴのデータ構造を示す。表１０に示すＡＩＴは、ＡＲＩＢ ＳＴＤ−Ｂ２３で規定されているＡＩＴのデータ構造を拡張したものである。ＡＩＴには、ポリシーレベル、アプリケーションＩＤ、制御コードを記述する。なお、ＡＩＴはセクション形式で送信され、イベント継続中は常時送信されるものとする。アプリケーションＩＤは、application_identifier()に記述し、制御コードはapplication_control_codeに記述する。
なお、これらの詳細は、（２）ＥＩＴの拡張で記載したものと同様である。
さらに、ポリシーレベルを記述するために、新たにセキュリティポリシー記述子を定義し、ＡＩＴの共通記述子ループに格納して伝送する。
【０１５７】
【表１０】
【０１５８】
表１１は、新たに定義するセキュリティポリシー記述子の構造を示す。
【０１５９】
【表１１】
【０１６０】
（４）緊急警報放送および緊急地震速報（ＥＷＳ／ＥＥＷ）：放送局から送出される緊急情報を用いてポリシーレベルを判断する。受信機においては予め緊急情報とポリシーレベルとの対応はなされているものとし、緊急警報放送であれば、ＴＭＣＣの緊急警報放送用起動フラグを、緊急地震速報では文字スーパー管理パケットを監視することで、緊急情報の発生と終了が検知され、その際のポリシーレベルを判断することが可能になる。ＡＲＩＢ規格との関連は、ＡＲＩＢ ＳＴＤ−Ｂ３１ ３．１５およびＡＲＩＢ ＳＴＤ−Ｂ２４ 第一編 第３部 第９章である。
【０１６１】
なお、上記の（１）〜（４）のそれぞれの方式は並行して同時に送出することが可能である。したがって、どの方式で送られたものを優先させてポリシーレベルを決定するかを決めておく必要がある。優先順位は以下の通りである。
【０１６２】
ＥＷＳ／ＥＥＷ＞ ＡＩＴ＋ ＞ ＥＩＴ＋ ＞ ＥＩＴ
【０１６３】
受信機はこの優先順位に基づき、ポリシーレベルを判断することで、放送事業者の意図に基づいた、緊急時の事象を優先させた画面提示制御が可能となる。
【０１６４】
［４．３．４ 画面提示制御の例］
図１６は、ポリシーレベルに応じた画面提示制御の例を示す。
番組のポリシーレベルが「１」の場合、Ａアプリケーションのアプリケーション画面のアプリケーション画面および一般アプリケーションのアプリケーション画面の双方とも、放送画面上への重ね合わせが許可される。
番組のポリシーレベルが「２」の場合、Ａアプリケーションのみが放送画面上への重ね合わせが許可され、一般アプリケーションのアプリケーション画面については、放送画面上への重ね合わせは禁止され、放送画面の外側への表示のみが許可される。
番組のポリシーレベルが「３」の場合、Ａアプリケーションのアプリケーション画面、及び、一般アプリケーションのアプリケーション画面とも表示が許可されるが、全てのアプリケーション画面について、放送画面上への重ね合わせは禁止され、放送画面の外側への表示のみが許可される。
ポリシーレベルが「４」の場合、放送画面の全画面表示のみが許可される。
【０１６５】
図１７は、緊急地震速報受信時の提示制御の例を示す。番組Ａの番組ポリシーレベルが「１」である場合、番組Ａの放送時間帯においては、Ａアプリケーションのアプリケーション画面、一般アプリケーションのアプリケーション画面とも放送画面上に重ね合わせて表示される。しかし、受信機は、番組Ａの放送時間帯の中でも緊急地震速報が発生している時間帯におけるポリシーレベルは、緊急地震速報のポリシーレベル「４」であると判断する。そのため、受信機は、番組Ａの放送時間帯であっても、緊急地震速報が発生している時間帯では、Ａアプリケーションのアプリケーション画面、及び、一般アプリケーションのアプリケーション画面とも、放送画面上への重ね合わせを禁止する。
【０１６６】
［上述した放送通信連携システムを適用した本発明の実施形態の説明］
次に、図１に示す本発明の一実施形態を説明する。
図１８は、本発明の一実施形態による放送通信連携システムの全体構成図である。同図に示すように、本実施形態の放送通信連携システムは、放送局が保有する放送事業者装置１、サービス事業者が保有するサービス事業者サーバ群２、システム管理者が保有するリポジトリサーバ３、及び、視聴者が保有する受信機４を備えて構成される。同図においては、受信機４を１台のみ示しているが、現実には複数台の受信機４が設けられる。
【０１６７】
放送事業者装置１は、放送送出装置１１及び放送局サーバ群１２を備える。
放送送出装置１１は、図３に示す放送局設備に相当し、番組編成設備、番組送出設備、送信設備等から構成されるデジタル放送用の放送設備である。
【０１６８】
放送送出装置１１は、放送関連データ管理部１１１、信号設定部１１２及び放送送出部１１３を備えて構成される。
放送関連データ管理部１１１は、各番組の番組セキュリティポリシーデータ、Ａアプリケーションのアプリケーションセキュリティーポリシーデータ、その他のポリシーデータなどを管理する。
番組セキュリティポリシーデータは、番組のポリシーレベルを示すポリシーレベルデータ、番組にバウンドされたアプリケーションのアプリケーションＩＤ、番組にバウンドされたアプリケーションに対する制御コードなどを含む。
アプリケーションセキュリティポリシーデータは、アプリケーションがバウンドされている番組を特定する情報や、アプリケーションのプロトコル識別、ロケーション情報などを含む。ロケーション情報は、アプリケーションの格納位置（格納場所）を示し、例えば、アプリケーションをダウンロード可能な受信機アプリサーバ２１やリポジトリサーバ３のＵＲＬである。プロトコル識別は、アプリケーションが放送により伝送されたか、通信により伝送されたかを示す。
なお、Ａアプリケーションのみが番組にバウンドされる。
【０１６９】
ポリシーデータは、提示ルールデータとポリシーレベルテーブルを含む。
提示ルールデータは、ポリシーレベル毎の提示方法を記述したデータである。提示方法は、画面表示方法と音声出力方法を含む。画面表示方法には、例えば、放送画面（番組の映像）のみ表示する、Ａアプリケーション及び一般アプリケーションともアプリケーション画面（アプリケーションの映像）を放送画面に重ねてあるいは放送画面の外に表示する、Ａアプリケーションのアプリケーション画面のみ放送画面に重ねて表示し、一般アプリケーションのアプリケーション画面は放送画面の外に表示する、などの方法がある。音声出力方法には、例えば、放送番組の音声のみを出力する、放送番組の音声とＡアプリケーションまたは一般アプリケーションの音声を独立にあるいは混合して出力する、などの方法がある。
ポリシーレベルテーブルは、番組のジャンルに対応したポリシーレベルや、各イベントのポリシーレベルを記述したデータである。イベントとは、例えば、緊急警報信号や緊急地震速報など、番組とは必ずしも連動して発生しない放送の内容である。
【０１７０】
信号設定部１１２は、放送送出部１１３が伝送する放送信号に各種データを設定する。
信号設定部１１２は、放送関連データ管理部１１１が管理している番組セキュリティポリシーデータやアプリケーションセキュリティーポリシーデータに基づいて、放送信号にＡＩＴ、番組のポリシーレベルデータを設定する。信号設定部１１２は、番組にバウンドされたアプリケーションのＡＩＴを独立したＥＳとして放送信号（放送ＴＳ）に多重するか、データカルーセルに設定する。あるいは、信号設定部１１２は、番組にバウンドされたアプリケーションのＡＩＴと同等の情報をＥＩＴに設定する。また、信号設定部１１２は、番組のポリシーレベルデータをＥＩＴ（表５）、または、ＡＩＴ（表１１）に設定する。なお、番組のジャンルに対応するポリシーレベルを用いる場合には、ポリシーレベルデータを放送信号に設定しなくともよい。また、信号設定部１１２は、アプリケーションファイルをデータカルーセル等に設定する。また、信号設定部１１２は、放送関連データ管理部１１１が管理しているポリシーデータをセクション形式により放送信号に設定するか、エンジニアリングサービスあるいはデータカルーセルに設定する。
放送送出部１１３は、デジタル放送の放送信号を伝送する。放送信号は、信号設定部１１２により設定された情報を含む。
【０１７１】
放送局サーバ群１２は、図３に示す放送局サーバ群に相当し、コンテンツ管理サーバ１３、コンテンツ配信サーバ１６、放送局サービスサーバ１７及び通知サーバ１８を備えて構成される。
コンテンツ管理サーバ１３は、番組管理サーバ１４及びメタデータ管理サーバ１５を備えて構成される。番組管理サーバ１４は、すでに放送された番組や放送される番組を管理する。メタデータ管理サーバ１５は、各番組に関するメタデータを管理する。メタデータは、例えば、番組タイトル、番組ＩＤ、番組概要、出演者、放送日時、台本、字幕、解説のデータを含む。
【０１７２】
コンテンツ配信サーバ１６は、インターネットなどの通信網９を介して受信機４と接続され、受信機４から要求されたコンテンツのコンテンツデータを配信する。
放送局サービスサーバ１７は、サービス事業者サーバ群２に放送局のサービスのコンテンツデータを送信する。放送局のサービスには、例えば、ソーシャルネットサービス、ブログサービス等がある。
【０１７３】
通知サーバ１８は、通信網９を介して受信機４と接続され、放送送出装置１１の放送関連データ管理部１１１から取得した番組セキュリティポリシーデータとアプリケーションセキュリティーポリシーデータとに基づいて、番組にバウンドされたアプリケーションのＡＩＴ（図６）及び番組のポリシーレベルデータを受信機４に配信する。また、通知サーバ１８は、放送送出装置１１の放送関連データ管理部１１１から取得したポリシーデータを受信機４に配信する。なお、これらの情報の全てまたは一部は、通知サーバ１８からの配信を行なわず、放送送出装置１１の放送送出部１１３が放送信号のみで伝送する場合もある。
【０１７４】
サービス事業者サーバ群２は、図３に示すサービス事業者サーバ群に相当し、受信機アプリサーバ２１、サービスサーバ２２、コンテンツ配信サーバ２３及び通知サーバ２４を備えて構成される。受信機アプリサーバ２１、サービスサーバ２２、コンテンツ配信サーバ２３及び通知サーバ２４は、通信網９を介して受信機４と接続される。
【０１７５】
受信機アプリサーバ２１は、各アプリケーションを管理し、受信機４へアプリケーションファイルを配信する。
サービスサーバ２２は、例えば、多言語字幕サーバ、話速変換音声サーバ、ソーシャルＴＶサーバ、レコメンドサーバ、ブックマークサーバなどであり、受信機４から要求されたサービスのコンテンツデータを配信する。
コンテンツ配信サーバ２３は、例えば、ＶＯＤ配信サーバ、字幕配信サーバ、マルチビュー配信サーバであり、受信機４から要求されたコンテンツのコンテンツデータを配信する。
通知サーバ２４は、アプリケーションのＡＩＴ（図６）を受信機４に送信する。なお、Ａアプリケーションの場合、通知サーバ２４は、放送送出装置１１の放送関連データ管理部１１１から取得した番組セキュリティポリシーデータやアプリケーションセキュリティーポリシーデータに基づいたＡＩＴ（図６）を送信してもよい。
【０１７６】
リポジトリサーバ３は、図３に示すリポジトリに相当し、通信網９を介して受信機４と接続される。リポジトリサーバ３は、サービス事業者が生成したアプリケーションファイル（アプリケーションプログラム）に電子署名を行なうとともに、アプリケーションファイル（アプリケーションプログラム）の電子署名の認証に必要なデータを受信機４に送信する。また、リポジトリサーバ３は、Ａアプリケーションの一覧を示すデータや、そのＡアプリケーションのロケーション情報を受信機４に送信する。なお、リポジトリサーバ３が電子署名されたＡアプリケーションのアプリケーションファイルを受信機４へ送信してもよく、受信機アプリサーバ２１がリポジトリサーバ３から電子署名されたＡアプリケーションのアプリケーションファイルを受信し、受信機４へ送信してもよい。また、リポジトリサーバ３は、ＡアプリケーションのＡＩＴを受信機４に送信してもよい。
また、リポジトリサーバ３は、放送送出装置１１の放送関連データ管理部１１１から受信した番組セキュリティポリシーデータやアプリケーションセキュリティーポリシーデータに基づいて、番組にバウンドされたＡアプリケーションのＡＩＴ（図６）を受信機４に送信してもよい。
【０１７７】
受信機４は、図３に示す受信機に相当し、例えば、テレビ受像機、セットトップボックス、パーソナルコンピュータ、携帯端末等のデバイスである。
【０１７８】
図１９は、受信機４の内部構成を示す機能ブロック図である。同図に示すように、受信機４は、放送受信部４０１、分離部４０２、時計４０３、第１同期用バッファ４０４−１、第２同期用バッファ４０４−２、第１デコーダ４０５−１、第２デコーダ４０５−２、データ放送実行部４０６、映像制御部４０７、映像表示部４０８、音声制御部４０９、音声出力部４１０、通信入出力部４１１、アプリケーション実行制御部４１２、提示制御部４１３、操作入力部４１４、選局部４１５、ローカル情報記憶部４１６及び外部Ｉ／Ｆ部４１７を備えて構成される。
【０１７９】
放送受信部４０１は、放送信号を受信するチューナである。放送信号は、無線放送信号及び有線放送信号またはいずれか一方である。無線放送信号は、放送局側の送信アンテナが送信した放送電波（地上波）や、衛星が中継する衛星波を、受信アンテナで受信することにより得られる信号である。有線放送信号は、光ケーブルや同軸ケーブル等を介して放送局側から伝送される信号である。放送受信部４０１は、放送信号を受信して復調し、放送ストリーム（ＴＳ）を出力する。
分離部４０２は、デマルチプレクサであり、放送受信部４０１から供給された放送ストリームを、ＰＣＲ（Program Clock Reference）、映像データ、音声データ、字幕データ、データ放送、ＰＳＩ（Program Specific Information）／ＳＩ（Service Information）、独立エレメンタリストリーム（ＥＳ）で送信されたＡＩＴなどの各種データに分離する。なお、ＡＩＴはデータ放送に含まれる場合や、ＡＩＴと同様の内容がＳＩを構成するＥＩＴに設定される場合もある。また、分離部４０２は、放送信号からアプリケーションファイルを分離して出力する場合もある。
【０１８０】
通信入出力部４１１は、通信網９を介した通信によるデータの入出力を行う。通信入出力部４１１は、通信網９を経由して送信されたＡＩＴやアプリケーションファイルをアプリケーション実行制御部４１２に出力する。また、通信入出力部４１１は、通信網９を経由して送信された番組のポリシーレベルデータやポリシーデータを提示制御部４１３へ出力する。また、通信入出力部４１１は、アプリケーション実行制御部４１２により実行されるアプリケーションの指示に従って、コンテンツ配信サーバ１６やコンテンツ配信サーバ２３から配信されるコンテンツデータ、サービスサーバ２２から配信されるコンテンツデータを通信網９を経由して受信し、第２同期用バッファ４０４−２に出力する。
【０１８１】
操作入力部４１４は、視聴者による操作を受け付けるインタフェースであり、例えば、リモートコントローラ、携帯電話、タブレット端末等から視聴者が入力した情報を受信する受信装置や、キーボード、マウスなどである。操作入力部４１４は、視聴者が入力したメディア（地上／ＢＳ）やチャンネルの選択指示を選局部４１５に出力する。また、操作入力部４１４は、放送通信連携サービスの開始や終了の指示、アプリケーションに対する指示をアプリケーション実行制御部４１２に出力する。
選局部４１５は、操作入力部４１４に入力された操作に従って、放送受信部４０１において受信するメディアやチャンネルを制御する。
【０１８２】
データ放送実行部４０６は、デジタル放送信号により送信されたデータ放送アプリケーションを実行し、データ放送の画像（グラフィック）データを映像制御部４０７へ出力する。データ放送実行部４０６は、放送通信連携サービスのアプリケーションを起動するためのＡＰＩを備える。データ放送実行部４０６がデータ放送アプリケーションを実行して、放送通信連携サービスのアプリケーションを起動するＡＰＩが呼び出された場合、データ放送実行部４０６は、アプリケーションの起動をアプリケーション実行制御部４１２に指示する。また、データ放送実行部４０６は、データカルーセルによって送信されたＡＩＴやアプリケーションファイルをデータ放送から取得してアプリケーション実行制御部４１２に出力する。また、データ放送実行部４０６は、データカルーセルによって送信されたポリシーデータをデータ放送から取得して提示制御部４１３に出力する。
【０１８３】
アプリケーション実行制御部４１２は、放送通信連携サービスのアプリケーションを実行する。アプリケーション実行制御部４１２は、実行しているアプリケーションに従って、コンテンツ配信サーバ１６、コンテンツ配信サーバ２３、あるいは、サービスサーバ２２から受信したコンテンツデータをデコードするように第２デコーダ４０５−２に指示する。コンテンツデータは、映像データ、音声データの一方または両方を含む。映像データは、例えば、動画、静止画、テキストデータなどである。また、アプリケーション実行制御部４１２は、実行しているアプリケーションに従って、映像制御部４０７にグラフィック（映像）データや映像制御指示を出力し、音声制御部４０９に音声データや音声制御指示を出力する。
【０１８４】
時計４０３は、タイマーカウンタ値を出力する。時計４０３は、ＰＣＲが示すタイマーカウンタ値により発振器の周波数を調整し、放送送信側と時刻を同期させる。
第１同期用バッファ４０４−１は、分離部４０２から出力される映像データ、音声データ、字幕データを記憶する。映像データ、音声データ、字幕データのエレメンタリーストリーム（ＥＳ）から生成されたＰＥＳ（Packetized Elementary Stream）は、放送ストリーム（ＴＳ）を構成するトランスポートパケット（Transport Packet）に分割されて設定される。ＰＥＳのヘッダには、ＰＴＳ（提示時刻情報：Presentation Time Stamp）が含まれる。第１同期用バッファ４０４−１は、分離部４０２から出力された映像データ、音声データ、字幕データを、第１デコーダ４０５−１の指示によりＰＥＳパケット単位で出力する。
第２同期用バッファ４０４−２は、通信入出力部４１１が受信したコンテンツやサービスのコンテンツデータを記憶する。あるいは、第２同期用バッファ４０４−２は、操作入力部４１４により入力された視聴者の指示に従って、分離部４０２から出力される映像データ、音声データ、字幕データを記憶する。第２同期用バッファ４０４−２は、記憶しているコンテンツデータあるいは番組の映像データ、音声データ、字幕データを第２デコーダ４０５−２の指示によりＰＥＳパケット単位で出力する。
【０１８５】
第１デコーダ４０５−１は、時計４０３から出力された時刻に対応したＰＴＳが設定されている第１同期用バッファ４０４−１内のＰＥＳパケットを特定し、特定したＰＥＳパケットからエンコードされた映像データ、音声データ、字幕データを読み出し、読み出したデータをデコードして出力する。
第２デコーダ４０５−２は、時計４０３から出力された時刻に対応するＰＴＳが設定されている第２同期用バッファ４０４−２内のコンテンツデータあるいは番組のＰＥＳパケットを特定し、特定したＰＥＳパケットからエンコードされた映像データ、音声データ、字幕データを読み出し、読み出したデータをデコードして出力する。
【０１８６】
提示制御部４１３は、選局されている番組のポリシーレベルあるいは発生中のイベントのポリシーレベルと、提示ルールデータとに従って提示方法（画面表示方法及び音声出力方法）を決定する。提示制御部４１３は、決定した画面表示方法により、放送画面、Ａアプリケーションのアプリケーション画面、及び、一般アプリケーションのアプリケーション画面を表示するよう映像制御部４０７に指示する。さらに、提示制御部４１３は、決定した音声出力方法により、放送の音声データによる音声、Ａアプリケーションの音声データによる音声、及び、一般アプリケーションの音声データによる音声を出力するよう音声制御部４０９に指示する。
【０１８７】
映像制御部４０７は、第１デコーダ４０５−１から出力された番組の映像データ及び字幕データに基づく放送画面と、第２デコーダ４０５−２から出力されたコンテンツデータの映像データに基づくＡアプリケーション、一般アプリケーションのアプリケーション画面とを、提示制御部４１３またはアプリケーション実行制御部４１２から指示された画面表示方法に従って映像表示部４０８に表示させる。また、アプリケーション実行制御部４１２からアプリケーションの実行によりグラフィック（映像）データが出力される場合、映像制御部４０７は、提示制御部４１３またはアプリケーション実行制御部４１２から指示された画面表示方法に従って、その映像データに基づく表示画面を併せて映像表示部４０８に表示させる。なお、第２デコーダ４０５−２からは、他の番組の映像データ及び字幕データが出力される場合もある。
【０１８８】
映像表示部４０８は、一般的なディスプレイであり、放送およびアプリケーションの画面を表示する。例えば、映像表示部４０８は、番組の放送画面に、通信網９から受信したコンテンツデータの動画、静止画、テキストや、アプリケーションの実行によってアプリケーション実行制御部４１２から出力されたグラフィックなどのアプリケーション画面、または、他の番組の放送画面を合成した映像を表示する。
【０１８９】
音声制御部４０９は、第１デコーダ４０５−１から出力された番組の音声データに基づく音声と、第２デコーダ４０５−２から出力されたコンテンツデータの音声データに基づくＡアプリケーションや一般アプリケーションの音声と、アプリケーションの実行によってアプリケーション実行制御部４１２から出力された音声データに基づく音声とを、提示制御部４１３またはアプリケーション実行制御部４１２より指示された音声出力方法に従って音声出力部４１０から出力させる。なお、第２デコーダ４０５−２からは、他の番組の音声データが出力される場合もある。音声出力部４１０は、一般的なスピーカーあり、放送およびアプリケーションの音声を出力する。
【０１９０】
ローカル情報記憶部４１６は、ユーザ情報などの各種データを記憶する。
外部インタフェース部（以下、「外部Ｉ／Ｆ部」と記載する。）４１７は、ＬＡＮ（Local Area Network）などのホームネットワークなどに接続される機器８との間でデータを送受信する。機器８は、受信機４と連携動作する端末であり、例えば、パーソナルコンピュータ、携帯電話、タブレット、スマートフォン、ＰＤＡである。
【０１９１】
なお、受信機４がセットトップボックスなどの場合、映像表示部４０８及び音声出力部４１０は、受信機４と接続される外部装置とする。
【０１９２】
図２０は、アプリケーション実行制御部４１２の詳細な構成を示すブロック図である。
同図に示すように、アプリケーション実行制御部４１２は、アプリケーション記憶部４３１、アプリケーション認証部４３２、アプリケーション管理部４３３、アプリケーション制御部４３４、アプリケーション実行部４３５、リソースアクセス制御部４３８及びリソース制御部４３９を備える。
【０１９３】
アプリケーション記憶部４３１は、通信入出力部４１１が通信網９を介して受信したアプリケーションファイル、あるいは、データ放送実行部４０６がデータ放送から取得したアプリケーションファイル、または、分離部４０２が放送信号から分離したアプリケーションファイルを記憶する。アプリケーションファイルは出荷時などに予めアプリケーション記憶部４３１に記憶されていてもよい。アプリケーション記憶部４３１は、主記憶装置及びディスク等の補助記憶装置からなり、例えば、アプリケーションファイルはディスクに記憶され、実行時に主記憶装置に読み出される。この場合、オンザフライで実行されるアプリケーションのアプリケーションファイルは、ディスクには記憶されずに主記憶装置のみに記憶され、実行が終了した場合は主記憶装置から削除される。
【０１９４】
アプリケーション認証部４３２は、リポジトリサーバ３から電子署名の認証に必要なデータを受信し、受信したデータを用いてアプリケーションファイル（アプリケーションプログラム）に付加された電子署名の検証を行う。例えば、アプリケーション認証部４３２は、リポジトリサーバ３から受信した公開鍵を用いて、電子署名されたアプリケーションファイルを復号する。その結果、所定のデータ列が得られた場合、アプリケーション認証部４３２は、電子署名の検証が成功したと判断する。アプリケーション認証部４３２は、電子署名の検証が成功した場合、Ａアプリケーションであると判断し、電子署名の検証が不成功である場合、あるいは、電子署名が付加されていない場合、一般アプリケーションであると判断する。
【０１９５】
アプリケーション管理部４３３は、アプリケーション実行部４３５によるアプリケーションの起動または停止の状態、起動しているアプリケーションの出力状況を管理する。出力状況とは、動作中のアプリケーションから画像や音声が出力されているか否かの情報である。アプリケーション管理部４３３は、提示制御部４１３からの問い合わせを受け、起動されているアプリケーションの出力状況や、起動されているアプリケーションがＡアプリケーションであるか一般アプリケーションであるかの応答を返送する。
【０１９６】
アプリケーション制御部４３４は、番組にバウンドされているアプリケーションに対する制御コードや、操作入力部４１４により入力されたアプリケーションに対する指示に従って、アプリケーション実行部４３５におけるアプリケーションの起動や停止などを制御する。また、アプリケーション制御部４３４は、データ放送実行部４０６から起動が指示されたアプリケーションの起動をアプリケーション実行部４３５に指示する。アプリケーション制御部４３４は、操作入力部４１４からの入力に従ってチャンネルが変更される場合、変更前のチャンネルの番組にバウンドされているアプリケーションの終了と、変更後のチャンネルの番組にバウンドされているアプリケーションの起動をアプリケーション実行部４３５に指示する。なお、アプリケーション制御部４３４は、番組にバウンドされているアプリケーションや、バウンドされているアプリケーションに対する制御コードを、放送信号の独立ＥＳもしくはデータ放送に含まれるＡＩＴ、放送信号のＥＩＴから得られるＡＩＴと同等の情報、または、通信入出力部４１１を介して通知サーバ１８もしくは通知サーバ２４から受信したＡＩＴから取得する。また、アプリケーション制御部４３４は、ＡＩＴに設定されているロケーション情報を宛先としてアプリケーションファイルのダウンロード要求を送信する。受信機４からダウンロード要求を受信したリポジトリサーバ３、または、受信機アプリサーバ２１は、アプリケーションファイルを受信機４に配信する。
【０１９７】
アプリケーション実行部４３５は、受信機ＡＰＩ部４３６及び端末連携ＡＰＩ部４３７を備える。アプリケーション実行部４３５は、アプリケーション制御部４３４からの指示に従って、起動が指示されたアプリケーションのアプリケーションプログラムをアプリケーション記憶部４３１から読み出して実行する。アプリケーション実行部４３５がアプリケーションプログラムを実行することにより、受信機４上でアプリケーションが動作し、アプリケーション実行部４３５は通信網９を経由してコンテンツをコンテンツ配信サーバ１６やコンテンツ配信サーバ２３に要求したり、サービスをサービスサーバ２２に要求したりする。また、アプリケーションプログラムを実行することにより、アプリケーション実行部４３５は、映像制御部４０７へグラフィックデータや映像制御指示を出力したり、音声制御部４０９に音声データや音声制御指示を出力したりする。
【０１９８】
受信機ＡＰＩ部４３６は、アプリケーション実行部４３５がアプリケーションを実行するにあたって受信機４内の各リソースを利用するためのＡＰＩである受信機ＡＰＩを実行する。受信機ＡＰＩ部４３６が受信機ＡＰＩを実行することにより、アプリケーション実行部４３５が実行しているアプリケーションプログラムから受信機４内のリソースが利用可能となる。
端末連携ＡＰＩ部４３７は、外部Ｉ／Ｆ部４１７により通信可能なホームネットワーク上の機器８や、通信網９を介して接続される機器が受信機４の機能を利用するためのＡＰＩである端末連携ＡＰＩを実行する。端末連携ＡＰＩ部４３７が端末連携ＡＰＩを実行することにより、ホームネットワークを介して接続される機器８や通信網９を介して接続される機器から受信機４内のリソースが利用可能となる。
【０１９９】
リソース制御部４３９は、受信機ＡＰＩ部４３６や端末連携ＡＰＩ部４３７から受信機４内のリソースである各機能部へのアクセスを制御する。
リソースアクセス制御部４３８は、受信機ＡＰＩ部４３６や端末連携ＡＰＩ部４３７から受信機４内の各機能部へのアクセスを許可するか否かを制御する。リソースアクセス制御部４３８は、この制御を、受信機ＡＰＩ部４３６や端末連携ＡＰＩ部４３７が実行する各ＡＰＩの呼び出し元であるアプリケーションがＡアプリケーションであるか一般アプリケーションであるかに従って行なう。
【０２００】
図２１は、提示制御部４１３の詳細な構成を示すブロック図である。同図に示すように、提示制御部４１３は、ポリシーデータ管理部４５１、ポリシーデータ記憶部４５２、イベント解釈部４５３、ポリシーレベル照合部４５４、イベント制御部４５５、番組ポリシー記憶部４５６、ポリシー調停部４５７及びポリシーレベル記憶部４５８を備える。
【０２０１】
ポリシーデータ記憶部４５２は、提示ルールデータ及びポリシーレベルテーブルを含むポリシーデータを記憶する。ポリシーデータ管理部４５１は、ポリシーデータ記憶部４５２に記憶されるポリシーデータを管理する。ポリシーデータ管理部４５１は、ポリシーデータ記憶部４５２から読み出したポリシーレベルテーブルをポリシーレベル照合部４５４に出力し、ポリシーデータ記憶部４５２から読み出した提示ルールデータをポリシー調停部４５７に出力する。また、ポリシーデータ管理部４５１は、放送により送信されたポリシーデータを分離部４０２あるいはデータ放送実行部４０６から受信し、通信により送信されたポリシーデータを通信入出力部４１１から受信する。ポリシーデータ管理部４５１は、ポリシーデータ記憶部４５２に記憶されているポリシーデータを、放送または通信により送信されたポリシーデータにより更新する。
【０２０２】
イベント解釈部４５３は、放送受信部４０１が受信した放送信号や、分離部４０２が分離したデータ放送や字幕データを解析し、イベントの発生または終了を検出する。イベント解釈部４５３は、イベントの発生または終了を検出（解釈）すると、その検出したイベントのイベント番号と、発生または終了を示すステータスデータとをポリシーレベル照合部４５４に出力する。
【０２０３】
ポリシーレベル照合部４５４は、ポリシーレベルテーブルを参照して、ＥＩＴにより示される各番組のジャンルに対応したポリシーレベルと、イベント番号により特定されるイベントに対応したポリシーレベルを決定（照合）する。ポリシーレベル照合部４５４は、分離部４０２から入力されたＳＩより取得した番組の放送開始時刻及び放送終了時刻のデータと、当該番組のポリシーレベル（以下、「番組ポリシーレベル」と記載する。）をイベント制御部４５５に出力する。なお、番組ポリシーレベルがＥＩＴに設定されている場合、ポリシーレベル照合部４５４は、番組の放送開始時刻及び放送終了時刻のデータと、ＥＩＴから取得した当該番組の番組ポリシーレベルをイベント制御部４５５に出力する。
また、ポリシーレベル照合部４５４は、ＡＩＴから番組ポリシーレベルを取得した場合、取得した番組ポリシーレベルをポリシー調停部４５７に出力する。また、ポリシーレベル照合部４５４は、イベント番号に対応して決定したポリシーレベル（以下、「トリガーポリシーレベル」と記載する。）をポリシー調停部４５７に出力する。
【０２０４】
番組ポリシー記憶部４５６は、番組開始時刻及び番組終了時刻と、番組ポリシーレベルを対応付けて記憶する。イベント制御部４５５は、ポリシーレベル照合部４５４から入力された番組開始時刻及び番組終了時刻のデータと、番組ポリシーレベルとを対応付けて番組ポリシー記憶部４５６に書き込み、番組ポリシー記憶部４５６に記憶されているこれらの情報を基に、表示制御を実行する時刻を管理する。イベント制御部４５５は、番組ポリシー記憶部４５６に記憶されている番組開始時刻のデータを参照し、実行時刻を通知すべき時刻となったことを検出した場合、実行時刻と、その実行時刻に対応した番組ポリシーレベルをポリシー調停部４５７に出力する。
【０２０５】
ポリシーレベル記憶部４５８は、ポリシー調停部４５７に入力された実行時刻及び番組ポリシーレベルと、トリガーポリシーレベル及びステータスデータを記憶する。ポリシー調停部４５７は、イベント制御部４５５から入力された実行時刻及び番組ポリシーレベルと、ポリシーレベル照合部４５４から入力されたトリガーポリシーレベルとからポリシーレベルを決定する。例えば、トリガーポリシーレベルをポリシーレベルとして決定してもよく、番組ポリシーレベルとトリガーポリシーレベルのうちより高いほうをポリシーレベルとして決定してもよい。
【０２０６】
なお、ポリシーレベル照合部４５４からＡＩＴにより取得した番組ポリシーレベルが入力された場合、ポリシー調停部４５７は、イベント制御部４５５から入力された番組ポリシーレベルよりも、ポリシーレベル照合部４５４から入力された番組ポリシーレベルを優先する。つまり、ポリシー調停部４５７は、ＡＩＴより得られた番組ポリシーレベルと、トリガーポリシーレベルとからポリシーレベルを決定する。ポリシー調停部４５７は、提示ルールデータを参照し、決定したポリシーレベルと、アプリケーション管理部４３３から取得した動作中のアプリケーションがＡアプリケーションであるか否かの情報や出力状況から、画面表示方法及び音声出力方法（提示方法）を決定する。ポリシー調停部４５７は、決定した画面表示方法を映像制御部４０７に出力し、決定した音声出力方法を音声制御部４０９に出力する。
【０２０７】
ここで、図１に戻り、操作受付部４７４と、起動要求信号取得部４７１と、アプリケーション情報取得部４７２と、起動制御部４７３と、終了制御部４８１とについて説明する。
また、接続制御部５０１と、端末アプリケーション取得部５０２と、端末アプリケーション実行部５０３とについても説明する。
【０２０８】
操作受付部４７４は、視聴者（操作者）による操作にしたがって操作信号を送信する操作機器である。操作受付部４７４は、例えば、受信機４を遠隔操作可能なリモートコントローラ（以下、リモコン）、受信機４の本体に配設された操作パネル等である。リモコンには、リモコン機能を実現するためのアプリケーションプログラムを実行中である携帯端末（携帯電話、スマートフォン、タブレット端末等）、コンピュータ装置、カーナビゲーション端末等が含まれる。
【０２０９】
操作受付部４７４は、受信機４を操作するための操作部を備える。なお、本実施形態において、操作受付部４７４の操作部は、例えば、電源ボタン、“０”から“９”までの数字ボタン（チャンネル指定ボタン）、チャンネル切替ボタン、音量調節ボタン、データ放送サービスボタン等、従来のテレビ操作リモコンに設けられているものと同様な操作ボタンである。データ放送サービスボタンは、受信機４がデータ放送を受信しているときに押されるたびに、データ放送の表示と非表示とを切り替える操作ボタンである。データ放送サービスボタンは、データ放送ボタン、ｄボタン、またはＤボタンとも呼ばれる。
【０２１０】
また、操作受付部４７４の操作部には、図１には図示しない放送通信連携サービスボタンが設けられている。この放送通信連携サービスボタンは、受信機４に放送通信連携サービスを受け始めさせるための操作ボタンである。放送通信連携サービスボタンは、放送通信連携ボタン、ｈボタン、またはＨボタンとも呼ばれる。操作受付部４７４は、放送通信連携サービスボタンが押されると、放送通信連携サービスにおけるストリーム従属型サービスの開始を要求するための起動要求信号を送信する。
【０２１１】
なお、操作受付部４７４の操作部は、例えば、タッチパネルとグラフィカル・ユーザ・インタフェース（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ；ＧＵＩ）とによって実現されるものであってもよい。
【０２１２】
操作入力部４１４は、操作受付部４７４が送信した操作信号を受信する。
操作入力部４１４の起動要求信号取得部４７１は、操作入力部４１４が受信した操作信号のうち起動要求信号を取り込んで起動要求コマンドを生成し、この起動要求コマンドをアプリケーション実行制御部４１２のアプリケーション制御部４３４に供給する。
また、操作入力部４１４は、放送サービス復帰ボタン、例えば、操作受付部４７４の操作部に設けられた数字ボタンまたはチャンネル切替ボタンが操作されたことによって送信された操作信号を受信した場合、終了要求コマンドを生成し、この終了要求コマンドをアプリケーション制御部４３４に供給する。
【０２１３】
アプリケーション制御部４３４のアプリケーション情報取得部４７２は、分離部４０２から定期的または不定期に供給されるＡＩＴ（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒａｍａｔｉｏｎ Ｔａｂｌｅ、アプリケーション情報テーブル）を取り込む。より詳細には、アプリケーション情報取得部４７２は、視聴者によって所望に選択されたメディアのうち、所望に選局されたチャンネルに対応するＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ；ＴＳ、放送ストリーム）から抽出された、ＡＩＴのＥＳ（Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）を、定期的または不定期に取り込む。
【０２１４】
ＡＩＴは、前述したとおり、アプリケーションに関する情報と、アプリケーションに対する制御情報と、アプリケーションを指定する情報とを含む情報である。図６に示したように、アプリケーションに関する情報には、アプリケーション名（appName）とアプリケーションＩＤ（orgId，appId）とが含まれる。アプリケーションに対する制御情報には、前記の表７に示したアプリケーション制御コード（application_control_code）が含まれる。このアプリケーション制御コードは、例えば、アプリケーションのライフサイクルを制御するためのデータである。アプリケーションを指定する情報には、ロケーション情報（location）が含まれる。このロケーション情報は、アプリケーションファイルの格納場所およびアプリケーションファイルを特定する情報である。ストリーム従属型サービスにおけるロケーション情報は、アプリケーションファイルを格納した受信機アプリサーバ２１またはリポジトリサーバ３（アプリケーションサーバ）のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）である。
【０２１５】
アプリケーション情報取得部４７２は、取り込んだＡＩＴからアプリケーション制御コードとアプリケーションＩＤとを抽出し、これらアプリケーション制御コードとアプリケーションＩＤとを終了制御部４８１に供給する。
なお、アプリケーション情報取得部４７２は、取り込んだＡＩＴからアプリケーションＩＤの代わりに、またはアプリケーションＩＤと共にアプリケーション名を抽出して終了制御部４８１に供給してもよい。
【０２１６】
また、アプリケーション情報取得部４７２は、起動要求信号取得部４７１から供給される起動要求コマンドを取り込むと、この起動要求コマンドの取り込みタイミングと同時またはこの取り込みタイミングの直後に取り込んだＡＩＴから、アプリケーション制御コードの他、アプリケーション名とロケーション情報とを抽出する。アプリケーション情報取得部４７２が抽出したアプリケーション名とアプリケーション制御コードとロケーション情報とを、アプリケーション情報と呼ぶ。アプリケーション情報取得部４７２は、抽出したアプリケーション情報を起動制御部４７３に供給する。
【０２１７】
また、アプリケーション情報取得部４７２は、分離部４０２から定期的または不定期に供給されるＰＳＩ（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ、プログラム特定情報）／ＳＩ（Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ、番組配列情報）を取り込む。より詳細には、アプリケーション情報取得部４７２は、上述した、所望に選択されたメディアのうち、所望に選局されたチャンネルに対応するＴＳから抽出されたＰＳＩ／ＳＩを、定期的または不定期に取り込む。
ＰＳＩ／ＳＩは、放送番組に関連するメタデータを含む情報である。メタデータは、前述したとおり、例えば、番組ＩＤ、番組概要、出演者、スタッフ、放送日時、台本、字幕、解説等の、放送番組に関連する情報である。
【０２１８】
本実施形態では、受信機４と機器８とを連携動作させる場合において機器８に実行させるアプリケーション（端末アプリケーションとも呼ぶ）を指定するアプリケーション指定情報が、ＰＳＩ／ＳＩに含まれている。アプリケーション指定情報は、端末アプリケーションを識別する識別情報であってもよいし、端末アプリケーションを格納する外部の端末アプリケーションサーバのＵＲＬであってもよい。
なお、アプリケーション指定情報はメタデータに含まれていてもよい。
放送送出装置１１の信号設定部１１２は、放送番組またはその内容もしくはその進行状況に対応付けて、アプリケーション指定情報をＴＳに多重化する。
【０２１９】
アプリケーション情報取得部４７２は、取り込んだＰＳＩ／ＳＩからアプリケーション指定情報とメタデータとを抽出し、これらアプリケーション指定情報とメタデータの全部または一部とをアプリケーション実行部４３５に供給する。
なお、アプリケーション指定情報およびメタデータまたはいずれかの情報は、特定の識別子に対応付けられて、独立的に設けられたＥＳに含められてもよい。この場合は、分離部４０２は、そのＥＳから、特定の識別子を手がかりとして、アプリケーション指定情報およびメタデータまたはいずれかの情報を抽出する。
【０２２０】
起動制御部４７３は、アプリケーション情報取得部４７２から供給されるアプリケーション情報、すなわち、アプリケーション名とアプリケーション制御コードとロケーション情報とを取り込む。起動制御部４７３は、アプリケーション制御コードがアプリケーションのスタンバイを示すデータであると識別した場合、アプリケーション情報に対応するアプリケーションの起動を制御する。
【０２２１】
具体的には、起動制御部４７３は、アプリケーション制御コードがアプリケーションのスタンバイを示すデータであると識別した場合、アプリケーション要求コマンドを生成し、このアプリケーション要求コマンドを通信入出力部４１１に供給する。つまり、起動制御部４７３は、アプリケーション要求部である。
アプリケーションのスタンバイを示すデータは、例えば、前記の表７に示したアプリケーション制御コードにおける“１２（１６進数）”（識別名：ＰＲＥＳＥＮＴ）である。
なお、アプリケーションのスタンバイを示すデータとしては、上記の“１２（１６進数）”（識別名：ＰＲＥＳＥＮＴ）以外にも、専用に割り当てられたコードとしてもよい。
アプリケーション要求コマンドは、ロケーション情報が示すロケーションをアプリケーションファイルの要求先とし、そのアプリケーションファイルの取得要求（ダウンロード要求）を示すコマンドである。
【０２２２】
なお、起動制御部４７３によるアプリケーションの起動の制御には、アプリケーション記憶部４３１に記憶されたアプリケーションファイルをアプリケーション実行部４３５に読み込ませて実行開始させることも含まれる。
【０２２３】
また、起動制御部４７３は、通信入出力部４１１から供給されるアプリケーションファイルの取得通知を取り込むと、アプリケーション実行要求コマンドを生成し、このアプリケーション実行要求コマンドをアプリケーション実行部４３５に供給する。
アプリケーション実行要求コマンドは、アプリケーションファイルの取得通知に対応するアプリケーションに対する実行開始要求を示すコマンドである。
【０２２４】
アプリケーション制御部４３４の終了制御部４８１は、操作入力部４１４から供給される終了要求コマンドを取り込むと、アプリケーション実行部４３５からアプリケーションの処理の状態（アプリケーション実行状態）を検出する。終了制御部４８１は、検出したアプリケーション実行状態が実行状態である場合、アプリケーション実行終了コマンドを生成し、このアプリケーション実行終了コマンドをアプリケーション実行部４３５に供給する。つまり、終了制御部４８１は、操作入力部４１４から供給される終了要求コマンドを取り込むと、取り込み中のＴＳに対応付けられ且つ実行中であるアプリケーションの実行終了を制御する。
【０２２５】
また、終了制御部４８１は、アプリケーション情報取得部４７２から供給されるアプリケーション制御コードとアプリケーションＩＤとを取り込む。終了制御部４８１は、取り込んだアプリケーション制御コードがアプリケーションの実行終了を指示するデータであると識別した場合、このアプリケーション制御コードに対応付けられたアプリケーションＩＤに対応するアプリケーションの実行終了を制御する。
【０２２６】
具体的には、終了制御部４８１は、アプリケーション制御コードがアプリケーションの実行終了を指示するデータであると識別した場合、このアプリケーション制御コードに対応付けられたアプリケーションＩＤを含むアプリケーション実行終了コマンドを生成し、このアプリケーション実行終了コマンドをアプリケーション実行部４３５に供給する。
アプリケーションの実行終了を指示するデータは、例えば、前記の表７に示したアプリケーション制御コードにおける“０３（１６進数）”（識別名：ＤＥＳＴＲＯＹ）である。
【０２２７】
なお、アプリケーションの実行終了を指示するデータとしては、上記の“０３（１６進数）”（識別名：ＤＥＳＴＲＯＹ）以外にも、“０４（１６進数）”（識別名：ＫＩＬＬ）、“０８（１６進数）”（識別名：ＫＩＬＬ ＡＬＬ）、その他専用に割り当てられたコードとしてもよい。
【０２２８】
前述したアプリケーション実行部４３５は、その機能構成として、図示しないコンテンツ要求部を備える。このコンテンツ要求部は、アプリケーションの実行処理において必要なコンテンツデータを、放送局サーバ群１２のコンテンツ配信サーバ１６またはサービス事業者サーバ群２のコンテンツ配信サーバ２３に対して要求するためのコンテンツ要求コマンドを生成し、このコンテンツ要求コマンドを通信入出力部４１１に供給する。
【０２２９】
アプリケーション実行部４３５は、前述したとおり、受信機４と機器８との連携機能を実現するための端末連携ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を有している。アプリケーション実行部４３５は、機器８との連携処理を実行するアプリケーション（連携アプリケーションとも呼ぶ）を実行する場合には、その連携アプリケーションに端末連携ＡＰＩを呼び出させて実行処理する。
【０２３０】
アプリケーション実行部４３５は、受信機４と機器８とを連携動作させた後、アプリケーション情報取得部４７２から供給されるアプリケーション指定情報とメタデータとを取り込む。受信機４と機器８とを連携動作させるとは、受信機４と機器８との通信路を確立させて、受信機４と機器８とが協働して放送通信連携サービスの受給状態を実現することである。受信機４と機器８との通信は、サーバを経由しない直接通信であってもよいし、サーバを経由するネットワーク通信であってもよい。
直接通信を実現するためのプロトコルとして、例えば、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ
Ｐｌｕｇ ａｎｄ Ｐｌａｙ）を適用する。また、ネットワーク通信を実現するためのプロトコルとして、例えば、ＸＭＰＰ（ｅＸｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｐｒｏｔｏｃｏｌ）を適用する。
【０２３１】
アプリケーション実行部４３５は、連携動作中である機器８を指定する情報と、その機器８に実行させる端末アプリケーションを指定する情報（アプリケーション指定情報）と、メタデータとに基づいて、その機器８に対して端末アプリケーションを指定し起動制御を行う。機器８を指定する情報は、アプリケーション実行部４３５が、受信機４と機器８との連携を確立させたときに機器８から取得する情報である。
なお、受信機４に連携動作させる機器８があらかじめ特定されている場合は、機器８を指定する情報を省略してもよい。
【０２３２】
アプリケーション実行部４３５は、機器８を指定する情報と、アプリケーション指定情報と、メタデータとに基づいて、機器８に対して端末アプリケーションを指定し起動させるためのInvokeApplicationOnDevice()メソッドを、端末連携ＡＰＩに設けている。InvokeApplicationOnDevice()メソッドは、例えば、下記のフォーマットを有する。
【０２３３】
メソッド名： InvokeApplicationOnDevice（）
機能： 機器８に対して端末アプリケーションを指定し起動させる。
引数： device_dev，application_id，strings_parameters
【０２３４】
上記のInvokeApplicationOnDevice（）メソッドにおいて、device_devは連携動作中である機器８を指定する情報（デバイスＩＤ）、application_idは端末アプリケーションを指定する情報（アプリケーション指定情報、アプリケーションＩＤ）、strings_parametersはメタデータである。
つまり、機器８と受信機４とが連携動作を開始した後、アプリケーション実行部４３５がInvokeApplicationOnDevice()メソッドを実行すると、アプリケーション実行部４３５は、device_devに対応する機器８に対して、application_idに対応する端末アプリケーションを起動させるための起動コマンドを、外部Ｉ／Ｆ４１７を介して機器８に送信する。
このとき、この起動コマンドには、stringus_parametersが引数として含められる。
【０２３５】
なお、アプリケーション実行部４３５は、InvokeApplicationOnDevice（）メソッドにおける引数のうち、stringus_parametersを省略して実行処理してもよい。本実施形態では、引数にstringus_parametersを含む場合について説明する。
【０２３６】
また、前述した通信入出力部４１１は、その機能構成として、図示しないアプリケーション取得部と、コンテンツ取得部とを備える。
アプリケーション取得部は、通信入出力部４１１が送信したアプリケーション要求信号を受信した外部のサーバ、例えば、受信機アプリサーバ２１またはリポジトリサーバ３から送信されたアプリケーションファイルを取り込み、このアプリケーションファイルをアプリケーション記憶部４３１に記憶させる。
コンテンツ取得部は、通信入出力部４１１が送信したコンテンツ要求信号を受信した外部のサーバ、例えば、コンテンツ配信サーバ１６またはコンテンツ配信サーバ２３から送信されたコンテンツデータを取り込み、このコンテンツデータを第２同期用バッファ４０４−２に供給する。
【０２３７】
機器８の接続制御部５０１は、受信機４の外部Ｉ／Ｆ部４１７との間で通信を行うための通信インタフェースである。機器８と受信機４とが連携動作を開始した後、アプリケーション実行部４３５がInvokeApplicationOnDevice()メソッドを実行すると、接続制御部５０１は、外部Ｉ／Ｆ部４１７から供給される、strings_parametersを引数とした起動コマンドを取り込み、この起動コマンドを端末アプリケーション取得部５０２に供給する。
【０２３８】
端末アプリケーション取得部５０２は、接続制御部５０１から供給される起動コマンドを取り込み、この起動コマンドに基づいて端末アプリケーションを取得し、この取得した端末アプリケーションを、strings_parametersとともに端末アプリケーション実行部５０３に供給する。
【０２３９】
具体的には、端末アプリケーション取得部５０２は、図示しない端末アプリケーション記憶部を備えている。端末アプリケーション取得部５０２は、起動コマンドが示すdevice_devが当該機器８に該当するか否かを判定する。device_devが当該機器８に該当する場合、端末アプリケーション取得部５０２は、起動コマンドが示すapplication_idに対応する端末アプリケーションが端末アプリケーション記憶部に記憶されているか否かを判定する。application_idに対応する端末アプリケーションが端末アプリケーション記憶部に記憶されている場合、端末アプリケーション取得部５０２は、その端末アプリケーションを端末アプリケーション記憶部から読み出してstrings_parametersとともに端末アプリケーション実行部５０３に供給する。
device_devが当該機器８に該当しない場合、端末アプリケーション取得部５０２は、接続制御部５０１を介して受信機４にエラー情報を送信してもよい。
【０２４０】
また、application_idに対応する端末アプリケーションが端末アプリケーション記憶部に記憶されていない場合、端末アプリケーション取得部５０２は、その端末アプリケーションの取得要求を示す端末アプリケーション要求信号を生成し、この端末アプリケーション要求信号を、端末アプリケーションサーバに対して供給する。そして、端末アプリケーション取得部５０２は、端末アプリケーション要求信号に応じて端末アプリケーションサーバから供給された端末アプリケーションを取り込み、この端末アプリケーションをstrings_parametersとともに端末アプリケーション実行部５０３に供給する。
なお、端末アプリケーション取得部５０２は、その取り込んだ端末アプリケーションを、端末アプリケーション記憶部に記憶させてもよい。
【０２４１】
端末アプリケーションは、例えば、受信機４を遠隔操作するリモコン機能を実現するためのリモコンアプリケーション、クイズ番組やバラエティ番組等において視聴者から放送局またはサービス事業者に視聴者回答を送信するための回答（投票）アプリケーション、ウェブログ、チャット、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）等のクライアント機能を実現するためのアプリケーション等である。
【０２４２】
端末アプリケーション実行部５０３は、端末アプリケーション取得部５０２から供給される端末アプリケーションとstrings_parametersとを取り込み、このstrings_parametersを用いて端末アプリケーションを実行処理する。
例えば、strings_parametersが放送番組のキャストやスタッフに関する情報である場合、端末アプリケーション実行部５０３は、その放送番組のキャストやスタッフに関する情報、つまり放送リソースを利用して端末アプリケーションを実行処理する。
【０２４３】
図２２は、操作受付部４７４として赤外線リモコンを用いた場合の、概略の外観正面図である。同図に示すように、操作受付部４７４には、電源ボタン、数字ボタン、チャンネル切替ボタン、音量調節ボタン、データ放送サービスボタン等、従来のテレビ操作リモコンに設けられているものと同様なボタンの他、放送通信連携サービスボタン４７５が設けられている。
【０２４４】
次に、操作受付部４７４の放送通信連携サービスボタン４７５が押された場合において、受信機４がＡＩＴを取得し、このＡＩＴに基づいて外部のサーバからアプリケーションファイルを取得してアプリケーションを実行し、このアプリケーションの実行処理に伴い、関連するコンテンツを外部のサーバから取得して提示する処理について説明する。
【０２４５】
図２３は、受信機４と、受信機アプリサーバ２１と、コンテンツ配信サーバ２３との処理の手順を示すシーケンス図である。
ステップＳ１において、受信機４は、操作受付部４７４から送信される起動要求信号を受信すると、視聴者の所望によって選択されたメディアのうち、選局されたチャンネルに対応するＴＳから、ＡＩＴのＥＳを抽出する。
次に、ステップＳ２において、受信機４は、ＡＩＴに含まれるアプリケーション制御コードがアプリケーションのスタンバイを示すデータであると識別した場合、アプリケーション要求信号を受信機アプリサーバ２１に対して送信する。
次に、ステップＳ３において、受信機アプリサーバ２１は、受信機４が送信したアプリケーション要求信号を受信して取り込むと、このアプリケーション要求信号が指定するアプリケーションファイルを読み出す。
次に、ステップＳ４において、受信機アプリサーバ２１は、アプリケーション要求信号を送信した受信機４に対して、アプリケーションファイルを送信する。
【０２４６】
次に、ステップＳ５において、受信機４は、受信機アプリサーバ２１が送信したアプリケーションファイルを受信して取り込み、アプリケーションの実行処理を開始する。
次に、ステップＳ６において、受信機４は、アプリケーションの実行処理に伴って必要となるコンテンツデータを取得するためのコンテンツ要求信号をコンテンツ配信サーバ２３に対して送信する。
次に、ステップＳ７において、コンテンツ配信サーバ２３は、受信機４が送信したコンテンツ要求信号を受信して取り込むと、このコンテンツ要求信号が指定するコンテンツデータを読み出す。
次に、ステップＳ８において、コンテンツ配信サーバ２３は、コンテンツ要求信号を送信した受信機４に対して、コンテンツデータを送信する。
次に、ステップＳ９において、受信機４は、コンテンツ配信サーバ２３が送信したコンテンツデータを受信して取り込み、コンテンツをデコード処理して表示したり音声出力したりする。
【０２４７】
なお、図２３において、受信機アプリサーバ２１の代わりにリポジトリサーバ３を設けた場合、および、コンテンツ配信サーバ２３の代わりにコンテンツ配信サーバ１６を設けた場合も同様な処理となる。
【０２４８】
次に、操作受付部４７４から送信された操作信号を受信する受信機４の動作について、詳細に説明する。
図２４および図２５は、受信機４が操作受付部４７４の操作にしたがって作動する場合の、動作の処理手順を示すフローチャートである。
受信機４が放送信号を取り込み、視聴者によって選択されたメディアと選局されたチャンネルとに対応するＴＳから放送コンテンツを抽出して提示している状態、つまり、所望の番組を表示および音声出力している状態において、受信機４は、本フローチャートによる処理を実行開始する。
【０２４９】
まず、ステップＳ１１において、操作入力部４１４は、操作受付部４７４が送信する操作信号の受信を受け付けている。操作入力部４１４は、操作受付部４７４が送信した操作信号を受信すると、この操作信号を取り込んでステップＳ１２の処理に移す。
ステップＳ１２において、操作入力部４１４は、受信した操作信号が起動要求信号である場合（Ｓ１２：ＹＥＳ）はステップＳ１３の処理に移し、受信した操作信号が起動要求信号でない場合（Ｓ１２：ＮＯ）は、図２５のステップＳ２１の処理に移す。
【０２５０】
ステップＳ１３において、起動要求信号取得部４７１は、起動要求信号を取り込んで起動要求コマンドを生成し、この起動要求コマンドをアプリケーション実行制御部４１２のアプリケーション制御部４３４に供給する。
次に、アプリケーション制御部４３４のアプリケーション情報取得部４７２は、起動要求信号取得部４７１から供給される起動要求コマンドを取り込む。
次に、アプリケーション情報取得部４７２は、分離部４０２から供給されるＡＩＴを取り込む。このＡＩＴは、視聴者によって所望に選択されたメディアのうち、所望に選局されたチャンネルに対応するＴＳから抽出された情報である。
【０２５１】
ステップＳ１４において、アプリケーション情報取得部４７２は、取り込んだＡＩＴから、アプリケーション名とアプリケーション制御コードとロケーション情報とをアプリケーション情報として抽出し、このアプリケーション情報を起動制御部４７３に供給する。
次に、起動制御部４７３は、アプリケーション情報取得部４７２から供給されるアプリケーション情報、すなわち、アプリケーション名とアプリケーション制御コードとロケーション情報とを取り込む。
【０２５２】
次に、ステップＳ１５において、起動制御部４７３は、アプリケーション制御コードがアプリケーションのスタンバイを示すデータであると識別した場合（Ｓ１５：ＹＥＳ）、ステップＳ１６の処理に移し、アプリケーション制御コードがアプリケーションのスタンバイを示すデータでないと識別した場合（Ｓ１５：ＮＯ）、本フローチャートの処理を終了させる。
具体的には、起動制御部４７３は、アプリケーション制御コードが例えば“１２（１６進数）”（識別名：ＰＲＥＳＥＮＴ）であると識別した場合、ステップＳ１６の処理に移し、アプリケーション制御コードが“１２（１６進数）”（識別名：ＰＲＥＳＥＮＴ）でないと識別した場合、本フローチャートの処理を終了させる。
【０２５３】
ステップＳ１６において、起動制御部４７３は、ロケーション情報に示されるロケーションをアプリケーションファイルの要求先として指定したアプリケーション要求コマンドを生成し、このアプリケーション要求コマンドを通信入出力部４１１に供給する。
次に、通信入出力部４１１は、起動制御部４７３から供給されるアプリケーション要求コマンドを取り込み、このアプリケーション要求コマンドをアプリケーション要求信号として要求先に対して送信する。このアプリケーション要求信号は、例えば、アプリケーション要求コマンドをＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケット化した信号である。
すなわち、通信入出力部４１１は、アプリケーション要求コマンドが示す要求先である受信機アプリサーバ２１またはリポジトリサーバ３に対して、アプリケーション要求信号を送信する。
【０２５４】
次に、ステップＳ１７において、通信入出力部４１１は、上記の要求先（受信機アプリサーバ２１またはリポジトリサーバ３）が送信するアプリケーションファイルの受信を受け付けている。通信入出力部４１１は、上記の要求先が送信したアプリケーションファイルを受信すると、このアプリケーションファイルを取り込んでステップＳ１８の処理に移す。
【０２５５】
ステップＳ１８において、通信入出力部４１１は、取り込んだアプリケーションファイルをアプリケーション実行制御部４１２のアプリケーション記憶部４３１に供給し記憶させる。
【０２５６】
次に、ステップＳ１９において、通信入出力部４１１は、アプリケーションファイルの取得通知を起動制御部４７３に供給する。
次に、起動制御部４７３は、通信入出力部４１１から供給されるアプリケーションファイルの取得通知を取り込む。
次に、起動制御部４７３は、アプリケーションファイルの取得通知に対応するアプリケーションに対するアプリケーション実行要求コマンドを生成し、このアプリケーション実行要求コマンドをアプリケーション実行部４３５に供給する。
次に、アプリケーション実行部４３５は、起動制御部４７３から供給されるアプリケーション実行要求コマンドを取り込む。
次に、アプリケーション実行部４３５は、取り込んだアプリケーション実行要求コマンドにより指定されるアプリケーションファイルをアプリケーション記憶部４３１から読み込み、アプリケーションの実行処理を開始し、本フローチャートの処理を終了させる。
【０２５７】
一方、図２５のステップＳ２１において、操作入力部４１４は、操作信号が、操作受付部４７４の操作部に設けられた放送サービス復帰ボタン（例えば、数字ボタンまたはチャンネル切替ボタン）が操作されたことによって送信された操作信号である場合（Ｓ２１：ＹＥＳ）、ステップＳ２２の処理に移し、それ以外はステップＳ２５の処理に移す。
【０２５８】
ステップＳ２２において、操作入力部４１４は、終了要求コマンドを生成し、この終了要求コマンドをアプリケーション制御部４３４に供給する。
次に、アプリケーション制御部４３４の終了制御部４８１は、操作入力部４１４から供給される終了要求コマンドを取り込み、アプリケーション実行部４３５からアプリケーション実行状態を検出する。
【０２５９】
次に、ステップＳ２３において、終了制御部４８１は、検出したアプリケーション実行状態が実行状態である場合（Ｓ２３：ＹＥＳ）、ステップＳ２４の処理に移し、アプリケーション実行状態が実行状態でない場合（Ｓ２３：ＮＯ）、本フローチャートの処理を終了させる。
【０２６０】
ステップＳ２４において、終了制御部４８１は、アプリケーション実行終了コマンドを生成し、このアプリケーション実行終了コマンドをアプリケーション実行部４３５に供給する。
次に、アプリケーション実行部４３５は、終了制御部４８１から供給されるアプリケーション実行終了コマンドを取り込むと、現在実行中であるアプリケーションの実行処理を終了させて、本フローチャートの処理を終了させる。
【０２６１】
一方、ステップＳ２５において、操作入力部４１４は、起動要求信号以外の操作信号にしたがって、メディアやチャンネルを指定するコードを選局部４１５に供給したり、音量を設定するコードを図示しない音量調節回路に供給したりする。
受信機４は、起動要求信号以外の操作信号にしたがった動作を開始して、本フローチャートの処理を終了する。
【０２６２】
次に、放送通信連携サービスの提供者側からの制御に基づいてアプリケーションを実行終了させる受信機４の動作について説明する。
図２６は、受信機４の動作の処理手順を示すフローチャートである。
まず、ステップＳ３１において、アプリケーション情報取得部４７２は、分離部４０２から供給されるＡＩＴを取り込む。
【０２６３】
ステップＳ３２において、アプリケーション情報取得部４７２は、取り込んだＡＩＴからアプリケーション制御コードとアプリケーションＩＤとを抽出し、これらアプリケーション制御コードとアプリケーションＩＤとを終了制御部４８１に供給する。
次に、終了制御部４８１は、アプリケーション情報取得部４７２から供給されるアプリケーション制御コードとアプリケーションＩＤとを取り込む。
【０２６４】
次に、ステップＳ３３において、終了制御部４８１は、アプリケーション制御コードがアプリケーションの実行終了を指示するデータであると識別した場合（Ｓ３３：ＹＥＳ）、ステップＳ３４の処理に移し、アプリケーション制御コードがアプリケーションの実行終了を指示するデータでないと識別した場合（Ｓ３３：ＮＯ）、ステップＳ３１の処理に戻す。
具体的には、終了制御部４８１は、アプリケーション制御コードが例えば“０３（１６進数）”（識別名：ＤＥＳＴＲＯＹ）であると識別した場合、ステップＳ３４の処理に移し、アプリケーション制御コードが“０３（１６進数）”（識別名：ＤＥＳＴＲＯＹ）でないと識別した場合、ステップＳ３１の処理に戻す。
【０２６５】
ステップＳ３４において、終了制御部４８１は、アプリケーション制御コードに対応付けられたアプリケーションＩＤを含むアプリケーション実行終了コマンドを生成し、このアプリケーション実行終了コマンドをアプリケーション実行部４３５に供給する。
次に、アプリケーション実行部４３５は、終了制御部４８１から供給されるアプリケーション実行終了コマンドを取り込む。
次に、アプリケーション実行部４３５は、終了制御部４８１から供給されるアプリケーション実行終了コマンドを取り込むと、現在実行中であるアプリケーションの実行処理を終了させ、本フローチャートの処理を終了させる。
【０２６６】
次に、受信機４と連携動作させる機器８に実行させる端末アプリケーションを動的に変更する受信システムの動作について説明する。
図２７は、受信機４と、機器８と、端末アプリケーションサーバとの処理の手順を示すシーケンス図である。
まず、ステップＳ４１において、受信機４と機器８とが連携を確立させる。
具体的には、受信機４のアプリケーション実行部４３５は、機器８との連携処理を実行する連携アプリケーションに端末連携ＡＰＩを呼び出させて実行処理する。アプリケーション実行部４３５が端末連携ＡＰＩを実行することにより、受信機４と機器８とが連携を確立させる。
【０２６７】
次に、ステップＳ４２において、受信機４は、受信中のＴＳからアプリケーション指定情報とメタデータとを取得する。具体的には、アプリケーション情報取得部４７２は、視聴者によって所望に選択されたメディアのうち、所望に選局されたチャンネルに対応するＴＳから抽出されたＰＳＩ／ＳＩを取り込り、このＰＳＩ／ＳＩからアプリケーション指定情報とメタデータとを取り込む。
【０２６８】
次に、ステップＳ４３において、受信機４は、連携動作中である機器８を指定する情報と、ステップＳ４２の処理において取り込んだアプリケーション指定情報およびメタデータとに基づいて、その機器８に対してその端末アプリケーションを指定し起動制御を行う。
具体的には、アプリケーション実行部４３５は、携帯連携ＡＰＩのInvokeApplicationOnDevice()メソッドを実行し、device_devに対応する機器８に対して、application_idに対応する端末アプリケーションを起動させるための起動コマンド（stringus_parametersを含む）を、外部Ｉ／Ｆ４１７を介して機器８に送信する。
【０２６９】
次に、ステップＳ４４において、機器８は、受信機４からの端末アプリケーションの起動制御を受け、指定された端末アプリケーションについての端末アプリケーション要求信号を生成し、この端末アプリケーション要求信号を端末アプリケーションサーバに対して送信する。
【０２７０】
具体的には、接続制御部５０１は、外部Ｉ／Ｆ部４１７から供給される、strings_parametersを引数とした起動コマンドを取り込み、この起動コマンドを端末アプリケーション取得部５０２に供給する。
次に、端末アプリケーション取得部５０２は、接続制御部５０１から供給される起動コマンドを取り込む。
次に、端末アプリケーション取得部５０２は、この起動コマンドに基づいて端末アプリケーションを取得し、この端末アプリケーションをstrings_parametersとともに端末アプリケーション実行部５０３に供給する。
【０２７１】
より具体的には、端末アプリケーション取得部５０２は、起動コマンドが示すdevice_devが当該機器８に対応するか否かを判定する。device_devが当該機器８に対応する場合、端末アプリケーション取得部５０２は、起動コマンドが示すapplication_idに対応する端末アプリケーションが端末アプリケーション記憶部に記憶されているか否かを判定する。
ただし、図２７は、application_idに対応する端末アプリケーションが端末アプリケーション記憶部に記憶されていない場合の例である。
application_idに対応する端末アプリケーションが端末アプリケーション記憶部に記憶されていない場合、端末アプリケーション取得部５０２は、その端末アプリケーションの取得要求を示す端末アプリケーション要求信号を生成し、この端末アプリケーション要求信号を端末アプリケーションサーバに対して送信する。
【０２７２】
次に、ステップＳ４５において、端末アプリケーションサーバは、機器８が送信した端末アプリケーション要求信号を受信して取り込むと、この端末アプリケーション要求信号が指定する端末アプリケーションのファイルを読み出す。
次に、ステップＳ４６において、端末アプリケーションサーバは、端末アプリケーション要求信号を送信した機器８に対して、端末アプリケーションのファイルを送信する。
【０２７３】
次に、ステップＳ４７において、機器８は、端末アプリケーションサーバが送信した端末アプリケーションのファイルを受信して取り込む。
具体的には、端末アプリケーション取得部５０２は、端末アプリケーション要求信号に応じて端末アプリケーションサーバから供給された端末アプリケーションを取り込み、この端末アプリケーションをstrings_parametersとともに端末アプリケーション実行部５０３に供給する。
【０２７４】
次に、ステップＳ４８において、機器８は、取り込んだ端末アプリケーションのファイルにおける端末アプリケーションの実行処理を開始する。
具体的には、端末アプリケーション実行部５０３は、端末アプリケーション取得部５０２から供給される端末アプリケーションとstrings_parametersとを取り込み、このstrings_parametersを用いて端末アプリケーションの実行処理を開始させる。
次に、ステップＳ４９において、受信機４は連携アプリケーションの実行処理を行うとともに、機器８は端末アプリケーションの実行処理を行う。これにより、受信機４と機器８とは、放送リソースを用いた連携動作を実現する。
【０２７５】
以上説明したように、本発明の一実施形態である受信機４は、視聴者による操作にしたがって操作受付部４７４が送信する操作信号を受信する。操作受付部４７４には、受信機４に放送通信連携サービスを受け始めさせる放送通信連携サービスボタン４７５が設けられている。放送通信連携サービスボタン４７５が押されることによって、操作受付部４７４は、起動要求信号を送信する。
受信機４は、起動要求信号を取り込むと、所望のメディアにおける所望のチャンネルに対応するＴＳからＡＩＴを取得し、このＡＩＴからアプリケーション情報（アプリケーション名、アプリケーション制御コード、およびロケーション情報）を抽出する。
受信機４は、アプリケーション制御コードが、アプリケーションのスタンバイを示すデータである場合に、アプリケーション要求信号を、アプリケーションファイルの要求先である受信機アプリサーバ２１またはリポジトリサーバ３に対して送信する。
受信機４は、アプリケーションの要求先からアプリケーションファイルの供給を受けると、このアプリケーションファイルを取り込み、アプリケーションを実行開始する。
受信機４は、アプリケーションの実行処理に伴って必要となるコンテンツデータを取得するために、コンテンツ要求信号をコンテンツ配信サーバ１６またはコンテンツ配信サーバ２３に対して供給する。
受信機４は、コンテンツデータの要求先からコンテンツデータの供給を受けると、このコンテンツデータを取り込んで提示する。
【０２７６】
この構成によれば、受信機４は、視聴者（操作者）による操作受付部４７４に設けられた放送通信連携サービスボタン４７５の操作にしたがって、放送サービスを受けている状態から、放送通信連携サービスの一サービス形態であるストリーム従属型サービスを受ける状態に切り替えることができる。
よって、受信機４によれば、放送サービスから放送通信連携サービスに、簡便な操作により切り替えることができる。
【０２７７】
また、受信機４は、操作受付部４７４から供給された操作信号が、操作受付部４７４の操作部に設けられた放送サービス復帰ボタン（例えば、数字ボタンまたはチャンネル切替ボタン）が操作されたことによって送信された操作信号である場合、アプリケーションの実行状態を調べる。
現時点でアプリケーションが実行状態である場合、受信機４は、この実行中であるアプリケーションの実行処理を終了させる。
【０２７８】
この構成によれば、受信機４は、視聴者（操作者）による操作受付部４７４に設けられた数字ボタンおよびチャンネル切替ボタンの操作にしたがって、放送通信連携サービスの一サービス形態であるストリーム従属型サービスを受けている状態から、放送サービスを受ける状態に切り替えることができる。
よって、受信機４によれば、放送通信連携サービスから放送サービスに、簡便な操作により切り替えることができる。
【０２７９】
また、受信機４は、ＴＳから得られるＡＩＴに含まれるアプリケーション制御コードがアプリケーションの実行終了を指示するデータであることを識別した場合、このアプリケーション制御コードに対応付けられたアプリケーションＩＤが示すアプリケーションの実行処理を終了させる。
【０２８０】
この構成によれば、放送通信連携サービスの供給者側からの制御によって、受信機４は、現在受けている放送通信連携サービスを放送サービスに切り替えることができる。
よって、受信機４によれば、放送通信連携サービスの供給者側からの制御によって、受信者側が受けている放送通信連携サービスを放送サービスに切り替えることができる。
【０２８１】
また、この構成によれば、受信機４は、時装置が実行するアプリケーションと、このアプリケーションに関連するコンテンツデータとを、自装置の要求にしたがって外部の供給元から取得することができる。
【０２８２】
また、本実施形態である受信システムでは、受信機４が機器８との連携処理を実行する連携アプリケーションを実行する場合には、その連携アプリケーションに端末連携ＡＰＩを呼び出させて実行処理する。
受信機４は、機器８との連携を確立させた後、受信中のＴＳからアプリケーション指定情報とメタデータとを取得する。
受信機４は、連携動作中である機器８を指定する情報と、その機器８に実行させる端末アプリケーションを指定するアプリケーション指定情報と、メタデータとに基づいて、その機器８に対してその端末アプリケーションを指定し起動制御を行う。
機器８は、受信機４の起動制御を受けると、機器８が実行するように指定された端末アプリケーションを内部の端末アプリケーション記憶部または外部の端末アプリケーションサーバから取得する。
機器８は、受信機４から取得したメタデータを用いて、取得した端末アプリケーションを実行処理する。
【０２８３】
この構成によれば、受信機４と連携動作する機器８に実行させるアプリケーションを、放送ストリームから得られるアプリケーション指定情報に基づき動的に変更することができる。
よって、受信機４と連携動作する機器８は、放送番組またはその内容もしくはその進行状況等に応じて、端末アプリケーションを変えて実行することができる。
【０２８４】
なお、受信機４の起動制御部４７３は、操作受付部４７４の操作に関わらず、取得するＡＩＴに含まれるアプリケーション制御コードが、アプリケーションの自動起動を指示するデータであると識別した場合に、アプリケーション要求信号を受信機アプリサーバ２１に対して送信するものである。
【０２８５】
また、本実施形態は、受信機４が放送サービスを受けている状態において、操作受付部４７４に設けられた放送通信連携サービスボタン４７５が押された場合に、放送サービスのみを受ける状態から放送通信連携サービスを受ける状態に移行する例であった。これ以外にも、例えば、受信機４がいずれのサービスも受けていない状態、例えばスタンバイ状態であるときに、放送通信連携サービスボタン４７５が押された場合、受信機４が、その状態から一旦、放送サービスを受ける状態となった後に、放送通信連携サービスを受ける状態に移行するようにしてもよい。
【０２８６】
また、本実施形態は、アプリケーション情報取得部４７２が、放送信号から得られたＴＳに多重化されたＡＩＴのＥＳを取得する例であった。
これ以外にも、放送送出装置１１が、ＡＩＴの情報を含む記述子が設けられたＥＩＴ（Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ、イベント情報テーブル）を多重化したＴＳを放送信号として送信し、放送信号を取り込んだ受信機４において、分離部４０２がＴＳに多重化されたＥＩＴからＡＩＴを抽出し、アプリケーション情報取得部４７２がそのＡＩＴを取得するようにしてもよい。
【０２８７】
図２８は、ＥＩＴのデータ構造を示す図である。
なお、ＥＩＴのデータ構造についての詳細事項は、例えば、「地上デジタルテレビジョン放送運用規定 技術資料」、ＡＲＩＢ ＴＲ−Ｂ１４、４．４版、第二分冊、社団法人電波産業会、平成２３年３月（第四編第３部３１．３）に記載されている。
放送送出装置１１の信号設定部１１２は、例えば、同図に示すデータ構造を有するＥＩＴの記述子（descriptor()）にＡＩＴの情報を格納する。そして、信号設定部１１２は、ＡＩＴが格納されたＥＩＴを多重化したＴＳを生成し、このＴＳを放送送出部１１３に供給する。
【０２８８】
または、放送送出装置１１が、ＢＭＬ（Ｂｒｏａｄｃａｓｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）により記述されたＡＩＴを、ＤＳＭ−ＣＣ（Ｄｉｇｉｔａｌ Ｓｔｏｒａｇｅ
Ｍｅｄｉａ−Ｃｏｍｍａｎｄ ａｎｄ Ｃｏｎｔｒｏｌ）データカルーセル伝送方式によるデータ放送によって送信し、放送信号を取り込んだ受信機４において、分離部４０２がデータ放送コンテンツからＡＩＴを抽出し、アプリケーション情報取得部４７２がそのＡＩＴを取得するようにしてもよい。
【０２８９】
ＤＳＭ−ＣＣデータカルーセル伝送方式についての詳細事項は、例えば、「デジタル放送におけるデータ放送符号化方式と伝送方式 標準規格」、ＡＲＩＢ ＳＴＤ−Ｂ２４、５．１版、第三分冊、社団法人電波産業会、平成１９年３月（第三編第６章）に記載されている。
前述したとおり、信号設定部１１２は、ＡＩＴをカルーセル伝送するためのコンポーネントタグとモジュールとを固定とする。信号設定部１１２は、コンポーネントタグを例えば“ＡＡ”（１６進数）に、モジュールの識別情報であるモジュールＩＤを例えば“０”に固定する。そして、信号設定部１１２は、ＡＩＴであることを識別させるためのタイプを、モジュールのＴｙｐｅ記述子に設定する。
一方、分離部４０２は、ＴＳにおける、モジュールを監視し、モジュールＩＤが“０”であるモジュールを検出したときに、この検出したモジュールから、Ｔｙｐｅ識別子に対応するＡＩＴを抽出する。
【０２９０】
または、放送局サーバ群１２における通知サーバ１８またはサービス事業者サーバ群２における通知サーバ２４に、放送コンテンツの識別情報と対応付けたＡＩＴ、または放送コンテンツの識別情報を含むＡＩＴを格納しておき、放送信号を取り込んだ受信機４において、アプリケーション制御部４３４が分離部４０２からコンテンツの識別情報を取得して、通信入出力部４１１を介して通知サーバ１８または通知サーバ２４からＡＩＴを取得するようにしてもよい。
【０２９１】
また、放送通信連携サービスの供給者側からの制御によって、受信者側が受けている放送サービスを放送通信連携サービスに切り替える機能を実現するために、以下のような構成を有してもよい。
すなわち、アプリケーション情報取得部４７２は、取り込んだＡＩＴからアプリケーション制御コードと所定のフラグとを抽出し、これらアプリケーション制御コードとフラグとを起動制御部４７３に供給する。所定のフラグは、例えば、ＡＩＴに設けられた、アプリケーション起動とデータ放送提示とのいずれかを指定するデータである。
起動制御部４７３は、アプリケーション情報取得部４７２から供給されるアプリケーション制御コードとフラグとを取り込む。
起動制御部４７３は、アプリケーション制御コードがアプリケーションの自動起動を指示するデータであると識別した場合、フラグに応じて、アプリケーションの実行開始またはデータ放送の提示のいずれかを制御する。
アプリケーションの自動起動を指示するデータは、例えば、前記の表７に示したアプリケーション制御コードにおける“０１（１６進数）”（識別名：ＡＵＴＯＳＴＡＲＴ）である。
【０２９２】
また、本実施形態である受信機４の一部の機能をコンピュータで実現するようにしてもよい。この場合、その機能を実現するためのコンピュータプログラムをコンピュータ読み取り可能な記録媒体に記録し、この記録媒体に記録されたコンピュータプログラムをコンピュータシステムに読み込ませて、このコンピュータシステムが実行することによって実現してもよい。なお、ここでいうコンピュータシステムとは、オペレーティング・システム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ；ＯＳ）や周辺装置のハードウェアを含むものである。また、コンピュータ読み取り可能な記録媒体とは、フレキシブルディスク、光磁気ディスク、光ディスク、メモリカード等の可搬型記録媒体、コンピュータシステムに内蔵される磁気ハードディスクやソリッドステートドライブ等の記憶装置のことをいう。さらに、コンピュータ読み取り可能な記録媒体とは、インターネット等のコンピュータネットワークや、電話回線や携帯電話網を介してプログラムを送信する場合の通信回線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバ装置やクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持するものを含んでもよい。また上記のプログラムは、前述した機能の一部を実現するためのものであってもよく、さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせにより実現するものであってもよい。
【０２９３】
以上、本発明の実施の形態について図面を参照して詳述したが、具体的な構成はその実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計等も含まれる。
【符号の説明】
【０２９４】
１…放送事業者装置
１１…放送送出装置
１１１…放送関連データ管理部
１１２…信号設定部
１１３…放送送出部
１２…放送局サーバ群
１３…コンテンツ管理サーバ
１４…番組管理サーバ
１５…メタデータ管理サーバ
１６…コンテンツ配信サーバ
１７…放送局サービスサーバ
１８…通知サーバ
２…サービス事業者サーバ群
２１…受信機アプリサーバ
２２…サービスサーバ
２３…コンテンツ配信サーバ
２４…通知サーバ
３…リポジトリサーバ
４…受信機
４０１…放送受信部
４０２…分離部
４０３…時計
４０４−１…第１同期用バッファ
４０４−２…第２同期用バッファ
４０５−１…第１デコーダ
４０５−２…第２デコーダ
４０６…データ放送実行部
４０７…映像制御部
４０８…映像表示部
４０９…音声制御部
４１０…音声出力部
４１１…通信入出力部
４１２…アプリケーション実行制御部
４１３…提示制御部
４１４…操作入力部
４１５…選局部
４１６…ローカル情報記憶部
４１７…外部Ｉ／Ｆ部
４３１…アプリケーション記憶部
４３２…アプリケーション認証部
４３３…アプリケーション管理部
４３４…アプリケーション制御部
４３５…アプリケーション実行部
４３６…受信機ＡＰＩ部
４３７…端末連携ＡＰＩ部
４３８…リソースアクセス制御部
４３９…リソース制御部
４５１…ポリシーデータ管理部
４５２…ポリシーデータ記憶部
４５３…イベント解釈部
４５４…ポリシーレベル照合部
４５５…イベント制御部
４５６…番組ポリシー記憶部
４５７…ポリシー調停部
４５８…ポリシーレベル記憶部
９…通信網
４７１…起動要求信号取得部
４７２…アプリケーション情報取得部
４７３…起動制御部
４７４…操作受付部
４７５…放送通信連携サービスボタン
４８１…終了制御部
５０１…接続制御部
５０２…端末アプリケーション制御部
５０３…端末アプリケーション実行部
【技術分野】
【０００１】
本発明は、受信機および受信システムに関する。
【背景技術】
【０００２】
近年、放送通信連携サービスを実現するための研究が行われている。この放送通信連携サービスは、一例として、視聴者により利用される受信機に、放送局側から放送される放送番組コンテンツと、サービス事業者側からインターネット等の電気通信回線を介して配信される配信コンテンツとをそれぞれ受信させ、これら放送番組コンテンツと配信コンテンツとを連携させて再生させるサービスである。
受信機は、放送番組コンテンツと配信コンテンツとを表示および音声出力するためのアプリケーションを実行処理することによって、放送通信連携サービスを受けることができる。
また、受信機と通信端末とを連携動作させることによって、視聴者に、通信端末をも利用させて放送通信連携サービスを受けさせる試みも行われている。
【０００３】
従来、デジタル放送におけるアプリケーションの実行環境が規格化され運用されている（例えば、非特許文献１参照）。この文献には、ネットワークに接続された機器とこの機器の機能とをデータ放送コンテンツと連動させて利用させるための、ネットワーク機器利用に関する技術的事項が記載されている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】「デジタル放送におけるアプリケーション実行環境 標準規格」、ＡＲＩＢ ＳＴＤ−Ｂ２３、１．２版、社団法人電波産業会、平成２１年７月
【発明の概要】
【発明が解決しようとする課題】
【０００５】
受信機と通信端末との連携機能の実現において、放送番組またはその内容もしくはその進行状況等に応じて、通信端末に実行させるアプリケーションを動的に変更したいという要求がある。しかしながら、この機能要求を満たす仕組みは未だ確立されていない。
【０００６】
本発明は、上記事情に鑑みてなされたものであり、連携動作させる端末に実行させるアプリケーションを動的に変更することができる、受信機および受信システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
［１］上記の課題を解決するため、本発明の一態様である受信機は、受信中の放送ストリームに対応付けられたアプリケーション情報テーブルに基づいて、放送通信連携サービスにおける第１のアプリケーションを実行する受信機において、前記受信中の放送ストリームから、通信機能を有する端末に実行させる第２のアプリケーションを指定するアプリケーション指定情報を取得するアプリケーション情報取得部と、前記アプリケーション情報取得部が取得した前記アプリケーション指定情報に基づき、前記端末に対して、前記第２のアプリケーションを指定し起動制御を行うアプリケーション実行部と、を備えることを特徴とする。
［２］上記［１］記載の受信機において、前記アプリケーション情報取得部は、前記放送ストリームから、放送番組の関連情報であるメタデータも取得し、前記アプリケーション実行部は、前記アプリケーション情報取得部が取得した前記アプリケーション指定情報と前記メタデータとに基づき、前記端末に対して、前記第２のアプリケーションと前記メタデータとを指定し起動制御を行うことを特徴とする。
［３］上記の課題を解決するため、本発明の一態様である受信システムは、放送通信連携サービスにおける第１のアプリケーションを実行する受信機と、端末とを通信可能に備える受信システムにおいて、前記受信機は、受信中の放送ストリームから、前記端末に実行させる第２のアプリケーションを指定するアプリケーション指定情報を取得するアプリケーション情報取得部と、前記アプリケーション情報取得部が取得した前記アプリケーション指定情報に基づき、前記端末に対して、前記第２のアプリケーションを指定し起動制御を行うアプリケーション実行部と、を備え、前記端末は、前記アプリケーション実行部による前記起動制御に基づいて、前記第２のアプリケーションを取得する端末アプリケーション取得部と、前記端末アプリケーション取得部が取得した前記第２のアプリケーションを実行処理する端末アプリケーション実行部と、を備えることを特徴とする。
［４］上記［３］記載の受信システムにおいて、前記アプリケーション情報取得部は、前記放送ストリームから、放送番組の関連情報であるメタデータも取得し、前記アプリケーション実行部は、前記アプリケーション情報取得部が取得した前記アプリケーション指定情報と前記メタデータとに基づき、前記端末に対して、前記第２のアプリケーションと前記メタデータとを指定し起動制御を行い、前記端末アプリケーション実行部は、前記アプリケーション実行部により指定された前記メタデータを用いて、前記端末アプリケーション取得部が取得した前記第２のアプリケーションを実行処理することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、連携動作させる端末に実行させるアプリケーションを動的に変更することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態である受信システムの機能構成を示すブロック図である。
【図２】本発明が適用される放送通信連携システムを利用する者とその関係を示す図である。
【図３】放送通信連携システムの全体構成を示す図である。
【図４】放送通信連携システムの端末連携モデルを示す図である。
【図５】放送通信連携システムのサービス種別の概念図を示す。
【図６】放送通信連携システムに使用するＡＩＴのテキスト表現の例を示す図である。
【図７】放送通信連携システムにおけるアプリケーションのライフサイクルを示す図である。
【図８】放送通信連携システムにおける事業者間のデータの流れを示す図である。
【図９】放送通信連携システム全体におけるデータの流れを示す図である。
【図１０】放送通信連携システムにおけるレコメンドサービスのシーケンスを示す図である。
【図１１】放送通信連携システムにおける転送プロトコルスタックを示す図である。
【図１２】放送通信連携システムにおけるアプリケーション管理モデルを示す図である。
【図１３】放送通信連携システムにおけるセキュアマネージャーの機能モデルを示す。
【図１４】放送通信連携システムにおける画面提示制御方式の概念を示す図である。
【図１５】放送通信連携システムにおける画面提示制御の基本動作モデルを示す図である。
【図１６】放送通信連携システムにおけるポリシーレベルに応じた画面提示制御の例を示す。
【図１７】放送通信連携システムにおける緊急地震速報受信時の提示制御の例を示す。
【図１８】本発明の一実施形態による放送通信連携システムの全体構成図である。
【図１９】同実施形態による受信機の内部構成を示す機能ブロック図である。
【図２０】同実施形態によるアプリケーション実行制御部の詳細な構成を示すブロック図である。
【図２１】同実施形態による提示制御部の詳細な構成を示すブロック図である。
【図２２】本発明の一実施形態において、操作受付部として赤外線リモコンを用いた場合の、概略の外観正面図である。
【図２３】同実施形態である受信機と、受信機アプリサーバと、コンテンツ配信サーバとの処理の手順を示すシーケンス図である。
【図２４】同実施形態である受信機が操作受付部の操作にしたがって作動する場合の、動作の処理手順を示すフローチャートである。
【図２５】同実施形態である受信機が操作受付部の操作にしたがって作動する場合の、動作の処理手順を示すフローチャートである。
【図２６】同実施形態である受信機の動作の処理手順を示すフローチャートである。
【図２７】同実施形態である受信機と、機器と、端末アプリケーションサーバとの処理の手順を示すシーケンス図である。
【図２８】イベント情報テーブルのデータ構造を示す図である。
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための形態について、図面を参照して詳細に説明する。
本発明の一実施形態は、放送サービスのみを受ける状態と、放送通信連携サービスの一サービス形態であるストリーム従属型サービスを受ける状態とを、簡便な操作により切り替えることができる受信機である。また、本実施形態は、放送通信連携サービスの供給者側からの制御によって、現在受けている放送通信連携サービスを放送サービスに切り替えることができる受信機である。また、本実施形態は、放送通信連携サービスにおいて実行するアプリケーション（第１のアプリケーション）と、このアプリケーションに関連するコンテンツデータとを、自装置の要求にしたがって外部の供給元から取得することができる受信機である。また、本実施形態は、受信機、および、受信機と機器（端末）とを含む受信システムであり、連携動作させる機器に実行させるアプリケーション（第２のアプリケーション）を動的に変更することができる、受信機および受信システムである。
【００１１】
図１は、本発明の一実施形態である受信システムの機能構成を示すブロック図である。
同図に示すように、受信システムは、受信機４と機器８とを含んで構成される。
受信機４は、放送受信部４０１と、分離部４０２と、通信入出力部４１１と、アプリケーション実行制御部４１２と、操作入力部４１４と、選局部４１５と、操作受付部４７４とを含んで構成される。
アプリケーション実行制御部４１２は、アプリケーション記憶部４３１と、アプリケーション制御部４３４と、アプリケーション実行部４３５と、リソースアクセス制御部４３８と、リソース制御部４３９とを含んで構成される。
アプリケーション制御部４３４は、アプリケーション情報取得部４７２と、起動制御部４７３と、終了制御部４８１とを含んで構成される。
操作入力部４１４は、起動要求信号取得部４７１を含んで構成される。
機器８は、接続制御部５０１と、端末アプリケーション取得部（同図では、端末アプリ取得部と略記する）５０２と、端末アプリケーション実行部（同図では、端末アプリ実行部と略記する）５０３とを含んで構成される。
機器８は、前述したとおり、携帯電話、ＰＤＡ、スマートフォン、タブレット、パーソナルコンピュータ等の通信機能を備えた端末（電子機器、情報処理装置）である。
【００１２】
［本発明が適用される放送通信連携システムの説明］
ここで、本発明が適用される放送通信連携システムについて説明する。本発明が適用される放送通信連携システム（放送通信融合システム、放送通信システム、送受信システム）は、例えば、Hybridcast（登録商標）（ハイブリッドキャスト）システムであり、放送通信連携サービス（Hybridcast（登録商標）サービス、放送通信融合サービス、放送通信サービス）を提供する。本発明が適用される放送通信連携システムが実現する放送通信連携サービスは、デジタル放送サービスと、インターネットなどによる通信サービスとを連携する。例えば、放送通信連携サービスでは、デジタルテレビやパーソナルコンピュータ、携帯端末などの受信機は、放送により伝送された放送番組（以下、「番組」とも記載する。）の表示画面（以下、番組の表示画面の「放送画面」とも記載する。）に、この受信機に実装されているアプリケーションが通信により取得したサービスやコンテンツの表示画面（以下、「アプリケーション画面」、「アプリケーションの表示画面」とも記載する。）を合わせて同時に表示する。
【００１３】
［１． システムモデル］
［１．１ 放送通信連携システムの利用者]
図２は、放送通信連携システムを利用する者とその関係を示す図である。
編成を伴う番組を送出する放送局は、放送電波あるいは通信網により番組を視聴者に配信する。放送局は、放送通信連携サービスを充実するために、番組に関連するメタデータをサービス事業者に提供する。
【００１４】
放送通信連携サービスを提供するサービス事業者は、視聴者に放送通信連携サービスを提供するためのコンテンツとアプリケーション（以下、「アプリ」とも記載する。）を制作し、配信する。以下では、単に「アプリケーション」と記載した場合、放送通信連携サービスを提供するためのアプリケーション（放送通信連携サービスのアプリケーション）を指す。コンテンツまたはアプリケーションの制作者と配信者が同一のサービス事業者である必要はない。放送局がサービス事業者を兼ねてもよい。サービス事業者は、他のサービス事業者へのリンク情報を提供することも可能である。サービス事業者は、提供するアプリケーションが公式であることを示すために、システム管理者にアプリケーションの登録を申請し、承認を得ることができる。承認されたアプリケーションは、受信機上での動作に制限を受けない。一方、承認されないアプリケーションが表示させる画面は、番組の表示画面および音声にオーバーラップすることはできないが、アプリケーションの表示画面を縮小して放送番組の画面の外に表示することができる。承認されたアプリケーションをＡ（Authorized）アプリケーション、承認されないアプリケーションを一般アプリケーションという。なお、Ａアプリケーションを、公式アプリケーション、登録アプリケーション、認証済アプリケーション、認定アプリケーション、公認アプリケーション、オーソライズドアプリケーション、Ａ（Authorized）タイプアプリケーションとも呼ぶ。また、一般アプリケーションを、非公式アプリケーション、非認証アプリケーション、非認定アプリケーション、非公認アプリケーション、Ｕ（Unauthorized）タイプアプリケーション、Ｕアプリケーションとも呼ぶ。
【００１５】
システム管理者は、視聴者に提供するアプリケーション（受信機アプリ）がＡアプリケーション（公式）であることを認定する機関である。申請されたアプリケーションを承認するか否かのシステム管理者の判断は、放送局からの委託による。
【００１６】
各種設定等を行なうためのアプリケーションを受信機にインストールさせておいてもよい。この際、受信機におけるアプリケーションの表示画面が番組の表示画面（映像）にオーバーラップしてもよい。
【００１７】
放送局により放送された番組を視聴する視聴者は、放送通信連携サービスを享受する。
視聴者は、自身の意思により、アプリケーションをダウンロードしたり、起動したりすることができる。また、視聴者は、自身の意思により、アプリケーションの表示画面を番組の表示画面（映像）にオーバーラップさせることができる。
【００１８】
[１．２ 放送通信連携システムのシステム構成]
図３は、放送通信連携システムの全体構成を示す図である。放送通信連携システムは、電波を利用した現行の放送局設備に、機能的に「放送局サーバ群」、「サービス事業者サーバ群」、「受信機」を加えて構成される。
【００１９】
放送局は、放送局設備を保有する。さらに放送局は、放送局サーバ群あるいはサービス事業者サーバ群の両方を構成し、管理運営する。また、サービス事業者は、サービス事業者サーバ群を構成し、管理運営する。システム管理者は、リポジトリサーバを管理運営する。受信機メーカは、受信機を製造販売する。視聴者は受信機を保有し、放送通信連携サービスを享受する。
【００２０】
受信機（Hybridcast（登録商標）受信機、放送受信通信装置）は、標準化された共通のＡＰＩ（アプリケーションプログラムインタフェース：Application Program Interface）を搭載する。また、受信機は、地上デジタル放送、ＢＳ（broadcasting satellite）デジタル放送等の現行方式の放送を受信する。
放送局設備は、放送通信連携サービスを起動するための信号を放送波に多重化する。多重化の方式については後述する。
【００２１】
[１．３ 放送局サーバ群の構成例]
放送局サーバ群は、放送局が持っているコンテンツやメタデータを管理し、配信する。
例えば、放送局サーバ群は、各種サーバ、データ蓄積部（ＤＢ（データベース））及びＡＰＩを含んで構成され、放送局サーバ群のサーバは、コンテンツ管理サーバ、視聴者管理サーバ、コンテンツ配信サーバ、放送局サービスサーバを含んで構成される。
【００２２】
コンテンツを管理するコンテンツ管理サーバは、放送コンテンツである番組とメタデータを管理する。コンテンツ管理サーバには、放送された番組または放送される番組を管理する番組管理サーバや、番組に関連するメタデータを管理するメタデータ管理サーバが含まれる。メタデータは、例えば、番組タイトル、番組ＩＤ、番組概要、出演者、スタッフ、放送日時、台本、字幕、解説などを示す。
【００２３】
視聴者管理サーバは、視聴者（ユーザ）を管理し、コンテンツ配信サーバは、通信によりコンテンツデータを配信する。放送局サービスサーバは、放送局がサービス事業者に対してサービスを提供するためのサーバである。放送局サービスサーバが提供するサービスには、例えば、放送局が運営するソーシャルネットワークサービスや、放送番組毎のウェブログ（ブログ）などがある。
【００２４】
放送局サーバ群のデータ蓄積部は、放送局が持っているコンテンツ、メタデータを格納する部分とデータベースから構成される。蓄積されたデータには、管理しているサービス事業者のみがアクセス可能であり、他者からはアクセスできないように制限している。
【００２５】
放送局サーバ群のＡＰＩは、サービス事業者サーバ群からの要求に応じてデータを提供するためのＡＰＩである。ＡＰＩは、アプリケーションがサービスを受けるために呼び出すプログラムおよびその実行部である。
【００２６】
[１．４ サービス事業者サーバ群の構成例]
サービス事業者が管理運営するサービスサーバ群は、アプリケーションとコンテンツを管理し、提供する。サービスサーバ群は、受信機アプリサーバ、サービスサーバ、コンテンツ配信サーバ、データ蓄積部（ＤＢ（データベース））及びＡＰＩを含んで構成される。
【００２７】
受信機アプリサーバは、放送通信連携サービスのアプリケーションを管理するサーバである。サービス事業者は、受信機で動作するアプリケーションを保存、管理、配信する。
サービス事業者は、団体または個人で構成される。受信機アプリサーバは、受信機からの要求により、アプリケーションファイル（アプリケーションファイルについては後述する。）の保存場所を受信機に知らせるとともに、アプリケーションファイルを配信する。
【００２８】
サービスサーバは、受信機で動作しているアプリケーションからの要求によりサービスを提供するサーバである。サービスサーバには、例えば、多言語字幕サーバ、話速変換音声サーバ、ソーシャルＴＶサーバ、レコメンドサーバ、番組レビューサーバ、ブックマークサーバなどがある。
【００２９】
コンテンツ配信サーバは、受信機で動作しているアプリケーションからの要求によりコンテンツを提供するサーバである。コンテンツ配信サーバには、例えば、ＶＯＤ（VideoOn Demand）配信サーバ、字幕配信サーバ、マルチビュー配信サーバなどがある。
【００３０】
サービス事業者サーバ群のデータ蓄積部は、コンテンツデータ、メタデータ、サービス事業者が作成したデータ、視聴者データ、アプリケーションファイルを保存する場所である。データ蓄積部に保存されたデータには、管理しているサービス事業者のみがアクセスでき、他者からはアクセスできない。
【００３１】
サービスサーバ群のＡＰＩは、受信機で動作しているアプリケーションからの要求により、アプリケーションファイル、コンテンツ、サービスを提供するためのＡＰＩである。
【００３２】
[１．５ 受信機]
受信機は、現行方式の放送を受信し表示するとともに、放送通信連携サービスを実行する。現行方式の放送とは、地上デジタル放送、ＢＳデジタル放送等の衛星放送、データ放送である。また、受信機は、インターネットに接続される。
【００３３】
受信機は、受信する放送波に多重された情報をもとにして、サービス事業者サーバにアプリケーションのダウンロード要求を行う。受信機が、ダウンロードしたアプリケーションファイルに含まれるアプリケーションプログラムを実行することによって、受信機上でアプリケーションが動作する。受信機上で動作しているアプリケーションは、サービス事業者サーバにアクセスしてコンテンツを取得する。
また、受信機は、同期機能、アプリ制御機能など放送通信連携サービスを実行するために必要な機能である放送通信連携機能を持つ。放送通信連携機能に対するＡＰＩは共通化されているため、アプリケーションの制作が容易であるとともに、アプリケーションは受信機に依存しない。
放送通信連携サービスでは、パーソナルコンピュータや携帯端末などのデバイスとの連携のための機能も取り入れている。
【００３４】
放送通信連携機能には、放送通信連携基本機能と、必要に応じて実装するオプション機能とがある。受信機メーカは、放送通信連携基本機能を全ての受信機に実装する。アプリケーションは、ＡＰＩを通して放送通信連携機能を利用する。放送通信連携機能は、後述するＡＰＩに基づき動作する。
【００３５】
受信機が実装するＡＰＩは、受信機に依存することなく、アプリケーションの動作が同じになるようにするために規定される。全てのアプリケーションは、ＡＰＩを通して受信機の処理を行なうため、ＡＰＩを介さずにアプリケーションが受信機固有の機能にアクセスすることはできない。
【００３６】
[１．６ 端末連携モデル]
図４は、放送通信連携システムの端末連携モデルを示す図である。
受信機は、携帯端末などの端末と連携してサービスを提供することができる。連携する端末には、例えば、パーソナルコンピュータ、携帯電話、タブレット、スマートフォン、ＰＤＡ（Personal Digital Assistant）などがある。受信機は、受信機機能として他の端末が利用可能な機能をＡＰＩとして提供する。この他の端末が利用可能な機能を提供するＡＰＩを端末連携ＡＰＩという。例えば、携帯端末上で動作するアプリケーションは、端末連携ＡＰＩを利用することで、番組情報の取得などの放送リソースにアクセスしたり、再生制御等の受信機機能を呼び出したりすることができる。
【００３７】
[１．６．１ 端末連携ＡＰＩ]
端末連携ＡＰＩは、他の端末やその端末上で動作するアプリケーションが受信機の機能を利用するためのＡＰＩである。連携する端末は、ホームネットワーク（ＬＡＮ）上の端末及びインターネットを通してアクセスする端末を対象とする。各種動作を提供するＡＰＩの規定は後述する。
【００３８】
[１．６．２ 端末連携ＡＰＩ提供プロセス]
受信機上で動作する端末連携ＡＰＩ提供プロセスは、端末連携ＡＰＩを動作させる。端末連携ＡＰＩ提供プロセスは、常駐して動作する一種のデーモンプロセスのように動作する。
【００３９】
[１．６．３ ＡＰＩを呼び出すプロトコル]
端末連携ＡＰＩを呼び出すプロトコルには、例えば、ＲＥＳＴｆｕｌ（ＲＥＳＴ：Representational State Transfer）、ＵＰｎＰ（Universal Plug and Play）、ＸＭＰＰ（eXtensible Messaging and Presence Protocol）などが用いられる。
【００４０】
[１．６．４ プッシュ通知（Notification）機能]
受信機は、インターネット上のサーバ等が受信機に対してプッシュで情報を通知するNotification（通知）機能にも対応する。受信機はサーバ等からのプッシュにより通知された情報を受信する。Notification機能によって、なんらかの受信機動作を制御する場合があり、Notification機能も端末連携ＡＰＩ仕様の一部として規定される。
【００４１】
[２． 放送通信連携アプリケーション]
[２．１ サービスとアプリケーションモデル]
放送通信連携システムのアプリケーションモデルは、ＤＶＢ−ＧＥＭ１．２のアプリケーションモデルの考え方をベースに追加、変更したモデルである。
【００４２】
[２．１．１ 放送通信連携アプリケーション]
放送通信連携サービスのアプリケーションの動作は、ＡＶ（Audio Visual）コンテンツに連動した動作（連動）と、アプリケーション単独での動作（非連動）の２つのパターンに分類される。ＡＶコンテンツとは、放送コンテンツ（番組）または通信コンテンツ（ＶｏＤ等）である。
【００４３】
連動の場合、起動などのアプリケーションのライフサイクル制御は、放送または通信コンテンツに連動して行われる。アプリケーションは、ＡＶコンテンツと一緒に配信されるＡＩＴ（Application Information Table）（アプリケーション情報テーブル、アプリケーション起動情報）をもとに起動される。この場合、視聴者による起動や終了の操作に加え、放送事業者などのＡＶコンテンツの提供者がアプリケーションの自動起動や、終了などのライフサイクルを制御することも可能である。
一方、非連動の場合、放送や通信コンテンツに連動せずに、アプリケーション単独で起動、終了される。この場合、アプリケーションの開始や終了などのアプリケーションのライフサイクルは、視聴者によってのみ制御される。
【００４４】
[２．１．２ サービス]
従来、サービスとは、放送事業者が編成し、スケジュールの一環として放送可能な番組の連続のことをいうが、放送通信連携システムにおいてはこの考え方を拡張し、ストリーム従属型サービスと独立型サービスの２つのサービス種別を定義する。
【００４５】
図５は、サービス種別の概念図を示す。
受信機において、ストリーム従属型サービス及び独立型サービスを擬似的に選局することで、関連するアプリケーションが起動することになる。
ストリーム従属型サービスは、従来の意味でのサービスの考え方を拡張したものであり、放送や通信で伝送するＡＶストリームに、それに連動して動作するアプリケーション（複数可）を加えて構成される。ＡＶストリームの選択・再生（放送の場合は選局）によって連動してアプリケーションを起動することができる。
一方、独立型サービスは、映像・音声のストリームは含まず、アプリケーション（複数可）のみで構成される。視聴者が独立型サービスを選択することで、アプリケーションが起動される。
【００４６】
[２．１．３ オンザフライで取得するアプリ起動とインストールしたアプリの起動]
アプリケーションの起動には、オンザフライでアプリケーションファイルを取得して起動する方法と、予め受信機に蓄積（インストール）しておいたアプリケーションファイルを起動する方法の２つがある。オンザフライとは、アプリケーションの実行時に通信によってアプリケーションファイルを取得する方法であり、非インストール型、直接実行型ともいう。
【００４７】
なお、受信機は、後述するＡＩＴによるアプリケーションの周知をもとに、ローカルのファイルシステムにあるアプリケーションファイルのアプリケーションプログラムを起動する。受信機は、通信によりアプリケーションファイルを取得してインストールする際、関連するＡＩＴに設定されているロケーション階層内の情報（２．５．１節参照）をローカルのファイルシステム上のロケーションに書き換え、必要に応じて独立型サービスを識別する値(独立型サービスのＡＩＴ単位で必要)を生成する動作などが必要となる。
【００４８】
[２．２ アプリケーションの周知法（シグナリング）]
[２．２．１ アプリケーション起動情報（ＡＩＴ）]
サービスに含まれるアプリケーションの周知は、サービス選択時に通知されるアプリケーション起動情報によって行う。アプリケーション起動情報としてＡＲＩＢ ＳＴＤ−Ｂ２３（以下、ＡＲＩＢ−Ｊと記載）で定義されているＡＩＴを用いる。ストリーム従属型サービス、独立型サービスそれぞれで、そのサービス用のＡＩＴが周知される。各サービスにおけるＡＩＴの送り方の詳細を以下に示す。
【００４９】
図６は、放送通信連携システムに使用するＡＩＴのテキスト表現の例を示す図である。
放送通信連携システムにおいて使用するＡＩＴは、ＡＲＩＢ−Ｊで規定されるＡＩＴをベースとする。ＡＩＴには、ＳＩ（Service Information）のテーブルで伝送するためのバイナリ表現と、ＸＭＬ（extensible markup language）形式によるテキスト表現(ＡＩＴ Ｆｉｌｅ)とが存在し、同図では、テキスト表現の例を示している。ＡＩＴには、アプリケーションを特定するアプリケーションＩＤ（applicationIdentifier）、アプリケーション状態を制御する制御コード（controlCode）、アプリケーションファイルの格納位置（格納場所）を示すロケーション情報（location）などが記述される。
【００５０】
[２．２．２ ＡＶコンテンツに連動するアプリケーションの周知]
ＡＶコンテンツに連動するアプリケーションの周知は、ＭＰＥＧ（Moving Picture Experts Group）−２ ＴＳ（トランスポートストリーム：Transport Stream）で伝送するＡＶコンテンツにＡＩＴを多重する場合と、別途ＡＩＴの情報を送る場合がある。ＡＶコンテンツと連動させてＡＩＴを伝送することにより、受信機において、放送番組に連動するアプリケーションの起動や、番組の進行に連動したダイナミックなアプリケーションの起動などのライフサイクル制御が可能となる。
周知方法には、例えば、（１）ＡＩＴ用のＥＳ（エレメンタリーストリーム：Elementary Stream）追加、（２）ＥＩＴ（イベント情報テーブル：EventInformationTable）への記述子追加、（３）カルーセルでの伝送、（４）通信でのＡＩＴファイルの取得、（５）通信でのダイナミックなＡＩＴファイルの伝送、などがある。
【００５１】
（１）ＡＩＴ用のＥＳ追加の場合、ＡＲＩＢ−Ｊにおける規定と同様にＡＩＴのＥＳを放送ＴＳに多重する。
【００５２】
（２）ＥＩＴへの記述子追加の場合、後述する提示制御と同様に、ＥＩＴ（ｐ／ｆ）への記述子を追加し、ＡＩＴで伝送される情報と同じ情報を伝送する。
【００５３】
（３）カルーセルでの伝送の場合、ＤＳＭ−ＣＣ(Digital Storage Media Command and Control)データカルーセルでＡＩＴを伝送する。例えば、特定のモジュールでＡＩＴファイルを伝送する。カルーセルで伝送することで、取得時間のオーバーヘッドが想定されるが、現行の放送信号を変更する必要がない。
カルーセルでの運用例として、放送通信連携起動ファイル伝送用カルーセルのコンポーネントタグ、モジュールを固定する。例えば、コンポーネントタグに「ＡＡ」を、モジュールＩＤに「００００」を設定し、モジュールのType記述子にＡＩＴであることを示すタイプを設定する。受信機は、モジュールの更新を監視し、更新を検出するとＡＩＴを読み直し、ＡＩＴにより指定された制御（アプリケーションのライフサイクル制御）を実行する。
【００５４】
（４）通信でのＡＩＴファイルの取得の場合、ＡＶコンテンツの選択と同時に、別に用意されたＡＩＴファイルを取得する。例えば、再生するＡＶコンテンツの情報（コンテンツＩＤ）とアプリケーション起動情報（ＡＩＴ）が記述された情報を起点に両者を取得する。サーバ型放送（ＡＲＩＢ ＴＲ−Ｂ２７）の利用単位コンテンツやエントリーコンポーネントの考え方を利用することができる。
【００５５】
（５）通信でのダイナミックなＡＩＴの伝送の場合、ＡＶコンテンツを再生中に、新たなアプリケーションを起動したり、起動中のアプリケーションを終了させたりする制御を通信で伝送するＡＩＴにより行う。なお、予め想定されていないタイミングでの制御を行なう場合、通信を経由したプッシュによる通知を行なう。
【００５６】
[２．２．３ 独立して動作するアプリケーションの周知]
受信機は、独立して動作するアプリケーションの起動情報を含むＡＩＴを通信により取得する。独立アプリケーションは、既知のアプリケーションリポジトリから取得する。個々の独立アプリケーションの起動情報を取得するまでの手順を以下に示す。
【００５７】
（１）受信機にアプリケーションリポジトリのロケーションをセットする。出荷時に予め設定してもよく、複数のリポジトリを後から何らかの方法で追加してもよい。
（２）アプリケーションメニューを開くと、受信機はアプリケーションリポジトリからアプリケーションのリスト（各アプリのＡＩＴのロケーション記述を含む）を取得し、メニューにアプリを表示する。
（３）視聴者が選択したアプリケーションのＡＩＴを通信から取得する。
【００５８】
上記の手順は、リポジトリが提供するＷＥＢ（ウェブ） ＡＰＩを利用して実行される。また、独立して動作するアプリケーションは、ＡＶコンテンツと連動して動作するものではないため、予め指定したタイミングでの動的なライフサイクルコントロールは行わない。予め指定されていないタイミングでの制御（終了など）は、通信経由でのプッシュでの通知（Notification）により行なう。
【００５９】
[２．３ アプリケーションの起動と終了]
[２．３．１ アプリケーションのライフサイクル]
[２．３．１．１ ライフサイクル]
図７は、アプリケーションのライフサイクルを示す図である。
アプリケーションの状態は、ＡＲＩＢ−Ｊにおけるアプリケーションの状態に準じ、「Not Loaded（ロード前）」、「Loaded（ロード後）」、「Paused（休止）」、「Started（開始）」、「Destroyed（破壊）」の５つの状態を持つ。これら５つの状態において、アプリケーションがロード、実行されて終了するまでの一連の過程をアプリケーションのライフサイクルと呼び、各状態間の遷移の制御をライフサイクルコントロールと呼ぶ。
【００６０】
[２．３．１．２ ＡＶコンテンツに連動するアプリケーションの基本的ライフサイクル制御]
ＡＶコンテンツに連動するアプリケーションのライフサイクルの制御は、ストリーム従属型サービスの選択を通して行われることを基本とする。
ストリーム従属型サービスの選択は視聴者によって行われる。サービスは、ＡＶコンテンツやアプリケーションを含む一連のコンテンツのセットであり、アプリケーションと一緒に送られるＡＩＴに含まれる制御コードよって起動や終了などのライフサイクルが制御される。一つのサービスに複数のアプリケーションが含まれ、それらが同時に動作する場合もある。
【００６１】
アプリケーション起動のトリガとなるサービスの選択は、受信機ＡＰＩを通してアプリケーションから制御する場合や、受信機のレジデントアプリケーションとしてのナビゲータから制御する場合、放送サービスの場合はリモコンボタンを制御する場合、などがある。サービス切り替え時に、切り替え前後のサービスに含まれるコンテンツ（ＡＶコンテンツやアプリケーション）の提示が切り替えられる。切り替え前後のサービスに含まれるアプリケーションが異なる場合は、切り替え前に起動していたアプリケーションはサービス切り替えによって終了し、切り替え後には異なるアプリケーションが起動可能となる。これらの動作の詳細は、２．４節に後述する。
【００６２】
[２．３．２ アプリケーションの起動]
[２．３．２．１ ＡＩＴによる起動]
受信機においてサービス（ストリーム従属型サービス、独立型サービス）が選択されたとき、サービスと共に提供されるＡＩＴに含まれる制御コードで「auto-start」が指定されたアプリケーションは、視聴者からの明示的なアクションなしでサービス選択とともに自動的に起動する。サービス選択中は、そのサービスに対するアプリケーションシグナリングによってライフサイクルが制御される。例えば、放送サービスの場合は、放送と共に伝送されるＡＩＴを受信機が常に監視し、その変化に対応する。このように、ＡＩＴの伝送などのアプリケーションシグナリングによって、受信機において新たなアプリケーションを途中で自動起動（auto-start）するよう制御できる。
【００６３】
ＡＩＴによるアプリケーション起動情報において「auto-start」が指定されていないアプリケーションは、自動的には起動されず、視聴者による明示的な起動が必要となる。この明示的な起動は、受信機のレジデントアプリケーションのアプリケーションローンチャーによって行われる。例えば、放送サービス選択時に、リモコンの放送通信連携サービスボタンを押すことで、受信機においてアプリケーション起動用のメニューが開き、現在の放送（通信）サービスに連動するアプリケーション一覧が表示される。ここで視聴者は、受信機に対して、起動したいアプリケーションを選択・起動する操作を行う。
【００６４】
[２．３．２．２ 放送通信連携アプリケーションからの起動]
サービス内で複数のアプリケーションを起動できるため、起動済のアプリケーションから同じサービスに含まれる他のアプリケーションを起動することもある。ＡＲＩＢ−Ｊアプリケーション実行環境では、アプリケーションＩＤを指定することにより他のアプリケーションを起動するＡＰＩが規定されている。その他の実行環境の場合も、同様の機能をもったＡＰＩを規定する。
【００６５】
[２．３．２．３ ＢＭＬ（Broadcast Markup Language）からの起動]
受信機は、放送通信連携アプリケーション実行環境に加えて、現行のＢＭＬデータ放送の実行環境を備えることから、ＢＭＬのＡＰＩとして放送通信連携アプリケーションの起動を制御するＡＰＩを追加する。なお、ＢＭＬは、ＡＲＩＢ ＳＴＤ Ｂ２４に規定されるマルチメディア符号化方式であり、現行の日本の地上・ＢＳ・ＣＳデジタル放送におけるデータ放送方式として採用されている。
【００６６】
[２．３．２．４ 独立して動作するアプリケーションの起動]
独立型サービスは、アプリケーションのみを含む仮想的なサービスであり、独立アプリケーションを選択することで、２．３．２．１節のＡＩＴによる起動と同じメカニズムによりＡＩＴを取得してアプリケーションが起動される。ただし、独立型サービスでは、少なくとも１つのauto-startアプリケーションが起動される。独立型サービスの選択は、例えば、アプリケーションローンチャーから行う。
【００６７】
[２．３．３ アプリケーションの終了]
[２．３．３．１ ＡＩＴによる終了]
起動されたアプリケーションは、そのサービスに対するアプリケーションシグナリングによってライフサイクルが制御される。例えば、放送の場合は、放送と共に伝送されるＡＩＴを受信機が常に監視し、起動中のアプリケーションに対して制御コードdestroyを指定することで、アプリケーションを終了する。通信で伝送するストリーム従属型サービスにＡＩＴが多重されている場合も、連動するアプリケーションの終了制御が可能である。
【００６８】
[２．３．３．２ アプリケーション自身による終了]
アプリケーション自身が、終了用のＡＰＩを用いて自ら終了する。
【００６９】
[２．３．３．３ 他のアプリケーションによる終了]
アプリケーションが実行するアプリケーション終了用のＡＰＩを用いて、起動中の他のアプリケーションを終了させる。この場合、他のアプリケーションを終了させる適切なセキュリティポリシーが必要である。
【００７０】
[２．３．３．４ 別のサービスへの切替え時の終了]
受信機における別のサービスへの切り替え時、ストリーム従属型サービスに含まれるアプリケーションのうち、切り替え前のサービスに含まれるアプリケーションは終了し、新しいサービスでシグナリングされたアプリケーションが起動される。切り替え前後のサービスに同じアプリケーションが含まれる場合は、動作を継続することも可能とする。これは、ＡＩＴ中のフラグで制御する。ストリーム従属型サービスに含まれるアプリケーションであるサービスバウンドアプリケーションの詳細は、４．２節に後述する。
【００７１】
[２．３．３．５ 受信機による終了]
受信機は、指定したアプリケーションを受信機機能により終了する。例えば、受信機が起動中のアプリケーション一覧を表示し、視聴者の選択によって指定のアプリケーションを終了させる。
【００７２】
[２．３．３．６ 動的なアプリケーション終了]
アプリケーションの終了を動的に制御するため、アプリケーションの終了を指示するＡＩＴのファイルを受信機に送信する。この場合、ＡＩＴをプッシュ通知（Notification）する。
【００７３】
[２．３．４ 複数アプリケーションの起動]
[２．３．４．１ 同一サービス内でシグナリングされたアプリケーション]
受信機は、同一のサービスにおいてＡＩＴにリストされたアプリケーションを同時実行させることができる。
【００７４】
[２．３．４．２ ＡＶコンテンツに連動するアプリケーションと独立して動作するアプリケーションの同時起動]
ＡＶコンテンツに連動するアプリケーションは、ストリーム従属型サービス内でしか起動されない。一方、独立して動作するアプリケーションは、任意のタイミングでＡＶコンテンツに連動するアプリケーションや独立して動作する他のアプリケーションと同時に起動可能とする。
【００７５】
[２．３．４．３ 複数アプリケーション起動時のリソース管理]
複数のアプリケーションが起動する場合、それらが同じ受信機のリソース（例えばディスプレイ）を必要とする場合がある。受信機は、リソースマネージャなどの仕組みを備えて、適切にリソースを割り振ったり、リソースが使用出来ない場合はアプリケーションの実行をやめたりするなどの動作を行う。
【００７６】
[２．４ アプリケーションのバウンダリ]
[２．４．１ バウンド／アンバウンドの基本的な扱い]
アプリケーションは編成サービスに紐付いた（対応付けられた）バウンドアプリケーションと紐付かない（対応付けられていない）アンバウンドアプリケーションの２種類がある。バウンドアプリケーションがどの編成サービスと紐付いているかは、当該アプリケーションの起動情報を含んでいるＡＩＴがどの編成サービスから得られたかで判定する。
【００７７】
バウンドアプリケーションは、紐付いている編成サービスを受信しているときに実行可能な状態になる。つまり、当該編成サービスからＡＩＴによって起動され、当該編成サービスの受信が終了したとき(受信している編成チャンネルが変更されたとき)には実行が終了する。バウンドアプリケーションから起動された別のアプリケーションもバウンドアプリケーションとして扱う。関連する一連のバウンドアプリケーション群の大本である最初に起動されたアプリケーションが終了したときには、それによって起動された他のアプリケーションも終了する。
【００７８】
アンバウンドアプリケーションは編成サービスに紐付いていないので、受信している編成サービスを変更してもアプリケーションの実行は継続される。編成サービスからはアプリケーションを起動するためのＡＩＴが得られないので、他の手段(例えば、アプリケーションと紐付いているＡＩＴ Ｆｉｌｅ（ファイル）を、アプリケーションローンチャー等を用いて入手するなど)によって起動情報が受信機に与えられ、起動される。アンバウンドアプリケーションから起動された別のアプリケーションもアンバウンドアプリケーションとして扱う。アプリケーションは、視聴者の操作によって明示的に終了することが基本であるが、受信している編成サービスから全てのアプリケーションを終了させる指示（KILLALL）がＡＩＴによって与えられた場合にも終了する。
【００７９】
[２．４．２ アンバウンドアプリケーション固有の扱い]
アンバウンドアプリケーションは編成サービスと紐付かないが、２．３．２．４節で示すように、仮想的な編成サービス(受信機の起動時に受信機内に生成される)に紐付けることにより、バウンドアプリケーションと同じ起動処理メカニズムが適用できる。
【００８０】
仮想的な編成サービスの生成方法は受信機の実装依存であり、その編成サービスにどのような識別値を与えるかは受信機実装によって異なる。しかし、アプリケーションファイルを受信機内に蓄積しておいて任意のタイミングでアプリケーションローンチャーから起動できるようにしておく場合、仮想的な編成サービスを識別するＩＤやアプリケーションファイルの取得先(サービス事業者サーバないしはリポジトリから取得したＡＩＴには当該サーバが取得先として記述されているので、受信機内の蓄積領域から取得するように変更する必要がある)などが受信機実装に合うようにＡＩＴの内容を受信機が更新する必要がある。
【００８１】
[２．５ アプリケーションの取得方法]
[２．５．１ ＡＩＴをもとにした取得]
上記の記述のとおり、全てのアプリケーションの起動情報はＡＩＴにより与えられる。
アプリケーションファイルの取得は、ＡＩＴに含まれるアプリケーションのロケーション情報により指示される。例えば、図３の例ではロケーション情報は、「/ApplicationList/Application/applicationSpecificDescriptor/dvbjDescriptor/location」の階層に記述される(ＸＭＬとしてはlocation要素の内容として記述される)。ロケーション情報の記述は、例えば、「http://192.168.11.37/demo.jar」となる。
上記は、ＨＴＴＰ（Hypertext Transfer Protocol）プロトコルを用いて、demo.jar（Ｊａｖａ（登録商標）のアプリケーションアーカイブ）を取得する例である。使用するトランスポートプロトコルや、アプリケーションのパッケージフォーマットについては、後述する。
【００８２】
[２．５．２ アプリケーションのパッケージフォーマット]
アプリケーションのパッケージフォーマットは、アプリケーションフォーマット（Ｊａｖａ（登録商標）やＨＴＭＬ５）などに依存する。受信機は、何らかのひとかたまりになったファイル、もしくはエントリーファイルを取得することによって、アプリケーション起動に必要な一連のファイル（プログラム本体や画像ファイルなど）を取得する。この一連のファイルがアプリケーションファイルである。例えば、アプリケーションファイルには、一連のファイルを圧縮したもの（ｚｉｐファイル等）、Ｊａｒファイル（Ｊａｖａ（登録商標）実行環境）、エントリーのＨＴＭＬファイル（ＨＴＭＬ５実行環境の場合）、独自に規定したエントリーファイルなどのフォーマットが使用される。
【００８３】
[２．５．３ アプリケーションの伝送方法]
アプリケーションファイルをネットワーク経由で取得する際の伝送方法には、ＨＴＴＰプロトコルによる取得と、ＦＩＬＥプロトコルによる取得とがある。
ＨＴＴＰプロトコルによる取得の場合、GETメソッドにより取得する。ＡＩＴのロケーションの指定は、「http://〜」とする。
一方、ＦＩＬＥプロトコルによる取得の場合、受信機のローカルに保存された（インストールされた）アプリケーションファイル（アプリケーションプログラム）を指定するときには、ＡＩＴのロケーションの指定を「file:///〜」とする。
【００８４】
[３． インタフェース条件]
[３．１ 放送波の放送通信連携サービス制御信号]
放送波には、２．２．２節で前述したアプリケーション起動情報を送出するメカニズムが必要である。さらに、緊急警報放送時などを想定して、全てのアプリケーションを強制終了させるために、ＡＲＩＢ ＳＴＤ−Ｂ２３第二部 １０．１６．３．２節で規定するＡＩＴのアプリケーション制御コード(application_control_code)に「KILLALL」を追加する。表１は、追加する制御コード「KILLALL」の意味を示す。
【００８５】
【表１】
【００８６】
また、アプリケーションとＡＶコンテンツの関係からアプリケーションの提示制御を行うために、ＥＩＴ、ＡＩＴに記述子を追加する。詳細は４．３節に後述する。
【００８７】
[３．２ 放送局サーバ群ＡＰＩ]
図８は、放送通信連携システムにおける事業者間のデータの流れを示す図であり、図９は、放送通信連携システム全体におけるデータの流れを示す図である。
ここでは、図８に示す、放送局サーバ群とサービス事業者サーバ群のサービス毎のサーバとの間、放送局サーバ群と放送通信連携基盤サーバとの間、及び、放送通信連携基盤サーバとサービス事業者サーバ群のサービス毎のサーバとの間のＡＰＩの規定、図９に示す、受信機制御と放送通信連携基盤サーバとの間、メタデータとサービス毎のサーバとの間のＡＰＩについて述べる。
【００８８】
[３．２．１ ＡＰＩ］
放送局サーバ群を構成する各サーバである放送局サーバと、サービス事業者サーバ群を構成する各サーバであるサービス事業者サーバとの間の通信はＲＥＳＴ形式とする。また、放送局サーバとサービス事業者サーバとの間は、提供するサービスに応じてサーバのディレクトリー構成が異なることが予想されるため、ＡＰＩは双方間で取り決める。放送局サーバ及びサービス事業者サーバのＵＲＬの例を以下に示す。
【００８９】
http://hybridcast.org/{放送局名}/{サーバ名}/{コンテントID}/{管理するデータ}/{ソート方法}/{先頭アイテム},{個数}/?{パラメータ}={値}/
【００９０】
［３．２．２ レコメンドサービス］
図１０は、レコメンドサービスのシーケンスを示す図である。サービス事業者サーバ群と、放送局サーバのインタフェース部との間で使用されるメソッドは、「GET」、「POST」、「PUT」、「DELETE」である。コマンドフォーマットの例を以下に示す。
【００９１】
（１）http://hybridcast.or.jp/{放送局名}/(サーバ名)/{コンテントＩＤ}/{管理するデータ}/{ソート方法}/{先頭アイテム},{個数}/
（２）http://hybridcast.or.jp/{放送局名}/(サーバ名)/{視聴者ＩＤ}/{管理するデータ}/{ソート方法}/{先頭アイテム},{個数}/
（３）http://hybridcast.or.jp/{放送局名}/(サーバ名)/{レビューＩＤ}/{管理するデータ}/{ソート方法}/{先頭アイテム},{個数}/
【００９２】
また、パラメータには、{放送局名}、{サーバ名}、{コンテントＩＤ}、{視聴者ＩＤ}、{レビューＩＤ}、{管理するデータ}、{ソート方法}、{先頭アイテム}、{個数}等々がある。
【００９３】
［３．２．３ 管理対象のデータ］
管理対象のデータには、コンテンツ情報、ユーザ情報、ユーザ・ジェネレイテッド・コンテンツ情報、デバイス情報、認証情報がある。
コンテンツ情報は、タイトル、概要、ジャンル、放送日時、放送時間（尺）、映像モード、音声モード、字幕データ、台本、出演者、音楽、制作者、製作会社、著作、推薦番組、動画URI、再生回数、ＣＭ、タイムスタンプ情報、等を示すデータを含む。ユーザ情報は、ユーザ（視聴者）の名前、年齢、性別、地域、レビュー書込み数、コメント書込み数、お気に入り、フレンドリスト、再生場所（時刻）、再生終了場所（時刻）、番組視聴履歴等を示すデータを含む。ユーザ・ジェネレイテッド・コンテンツ情報は、コンテンツＩＤ、ユーザＩＤ、レビュー内容、レビュー書込み時刻、レビュー評価、等を示すデータを含む。デバイス情報は、デバイスＩＤを含む。認証情報は、認証ＩＤを含む。
【００９４】
［３． トランスポートフォーマット］
［３．３．１ 通信で扱う映像/音声について］
通信で扱う映像や音声は、デジタルテレビネットワーク機能仕様 ストリーミング機能仕様書 プロトコル編V1.1(デジタルテレビ情報化研究会)に準拠する。
【００９５】
［３．３．１．１ 映像・音声のモノメディアフォーマットとの関連］
ＭＰＥＧ−２ ＶｉｄｅｏあるいはＨ．２６４／ＭＰＥＧ−４ ＡＶＣ（Advanced Video Coding）で符号化された映像と、ＭＰＥＧ−１ Ａｕｄｉｏ Ｌａｙｅｒ II、ＭＰＥＧ−２ Ａｕｄｉｏ ＡＡＣで符号化された音声、および字幕等の多重化には、ＴＴＳ（Timestamped Transport Stream）形式を使用する。ただし、ＭＰＥＧ２−ＴＳ、ＭＭＴ（MPEG Media Transport）、ＭＰ４等も使用可能である。
【００９６】
［３．３．１．２ 転送プロトコル関係］
図１１は、転送プロトコルスタックを示す図である。
ストリーム伝送は、ＲＴＰ（Real-Time Transport Protocol）／ＵＤＰ（User Datagram protocol）およびＨＴＴＰ／ＴＣＰ（Transmission Control Protocol）を用いる。なお、ＲＴＰ／ＵＤＰを用いる場合、オプションとして、誤り訂正の情報を伝送してもよい。また、ＨＴＴＰ／ＴＣＰを用いる場合、ＨＴＴＰのコネクション、メソッド、ヘッダを利用してストリーム制御を行う。伝送がＲＴＰ（Real-time Transport Protocol）で行われる場合、ストリーム制御情報はＲＴＳＰ（Real Time Streaming Protocol）を用いる。
【００９７】
［３．３．２ 字幕関連］
多言語字幕は、Timed Text Markup Language（Ｗ３Ｃ（World Wide Web Consortium））に準拠する。なお、同期については別途アプリケーションレベルで実施する。また、各対応フォントはサーバから必要に応じてダウンロードする。例えば、ＨＴＴＰのペイロードにフォントファイルを載せる。この場合、ＷｅｂのDynamic Fonts、ＰＦＲ（PortableFont Resource）を利用する。
フォントの容量は約５−３５ＭＢ（メガバイト）程度が望ましい。
【００９８】
［３．４ モノメディアフォーマット］
放送通信連携サービスにおけるモノメディア符号化は下記に定義されたものを用いる。
【００９９】
［３．４．１ 動画］
動画には、ＡＲＩＢ ＳＴＤ−Ｂ３２ ２．４版第１部３．１節で規定されるＭＰＥＧ−２ Ｖｉｄｅｏ方式および同３．２節で規定されるＭＰＥＧ４−ＡＶＣ方式が用いられ、同５．１節で規定されるテレビジョンサービスの符号化パラメータの制約条件が適用される。
【０１００】
［３．４．２ 音声］
音声には、ＭＰＥＧ−２ Ａｕｄｉｏや、ＰＣＭ（Pulse Code Modulation）（ＡＩＦＦ−Ｃ（Audio Interchange File Format Compression））を用いる。
ＭＰＥＧ−２ Ａｕｄｉｏの場合、ＡＲＩＢ ＳＴＤ−Ｂ３２ ２．４版第２部３．１節で規定されるＭＰＥＧ−２ ＡＡＣ方式が用いられ、同第５章で規定される符号化パラメータの制約条件が適用される。
ＰＣＭの場合、ＡＲＩＢ ＳＴＤ−Ｂ２４ ５．４版第一編第２部６．２節で規定される方式が用いられる。
付加音には、ＡＲＩＢ ＳＴＤ−Ｂ２４ ５．４版第一編第２部６．４節で規定される方式が用いられる。
【０１０１】
［３．４．３ 静止画］
ＪＰＥＧ（Joint Photographic Experts Group）の場合、ＡＲＩＢ ＳＴＤ−Ｂ２４
５．４版第一編第２部５．２節で規定される符号化方式が用いられる。
ＰＮＧ（Portable Network Graphics：ポータブル・ネットワーク・グラフィックス）の場合、ＩＳＯ／ＩＥＣ １５９４８：２００３にて規定される方式が用いられる。これは、W3C Recommendation Portable Network Graphics (PNG) Specification (Second Edition)と同内容である
【０１０２】
［３．４．４ 文字］
文字符号化には、ＡＲＩＢ ＳＴＤ−Ｂ２４ ５．４版第一編第２部７．２節で規定される国際符号化文字集合が用いられる。
文字符号集合には、同７．２．１．１．３節で規定されるＢＭＰ（Basic Multilingual Plane）セットが用られ、表７−２０が適用される。また、ＩＳＯ／ＩＥＣ１０６４６：２００３追補５および同追補６が適用される。
外字には、ＡＲＩＢ ＳＴＤ−Ｂ２４ ５．４版第一編第２部７．２．１．２節で規定される方式またはＡＲＩＢ ＳＴＤ−Ｂ２３第一部５．２．１．２節で規定される方式などが適用される。
制御符号には、ＡＲＩＢ ＳＴＤ−Ｂ２４ ５．４版第一編第２部７．２．２．１節で規定されるＣ０制御符号のうち、ＡＰＲ(ＣＲ)、ＡＰＤ(ＬＦ)のみが用いられる。その他のＣ０制御符号およびＣ１制御符号は用いられない。
文字符号の変換は、ＡＲＩＢ ＳＴＤ−Ｂ２４ ５．４版第一編第２部付録規定Ｅに従う。
【０１０３】
上記に規定する文字符号化方式以外の方式で情報が符号化されている場合、送出ないしは受信機内の適切なプロセスにおいて上記の文字符号化方式に変換し、処理を行う。すなわち、他の符号化方式による文字符号をアプリケーションからは直接扱わない。
【０１０４】
［３．５ アプリケーションフォーマット］
受信機上で実行可能なアプリケーションの記述方法を示す。この記述方法により作成されたアプリケーションを実行するための実行環境と、セキュアマネージャとの結合については４章に示す。
【０１０５】
［３．５．１ 受信機で実行可能なアプリケーションフォーマット］
受信機で実行可能なアプリケーションの記述方式として、ＢＭＬ(ＡＲＩＢ ＳＴＤ−Ｂ２４)、ＡＲＩＢ−Ｊ(ＡＲＩＢ ＳＴＤ−Ｂ２３)、ＨＴＭＬ５（Ｗ３Ｃ ＨＴＭＬ５
Ｗｏｒｋｉｎｇ ｄｒａｆｔ − ２０１１／Ｊａｎ／１３）を規定する。
【０１０６】
［３．５．２ ＢＭＬ］
受信機は、地上デジタル放送運用規定(ＡＲＩＢ ＴＲ−Ｂ１４）またはＢＳデジタル放送運用規定(ＡＲＩＢ ＴＲ−Ｂ１５）に準ずるＢＭＬ文書を提示する機能を有する。
受信機は、地上デジタル放送またはＢＳデジタル放送で提供されるデータ放送サービスを既存の規格どおりに提示できなくてはならない。ただし、受信機は、放送でデータカルーセル方式によって配信されるＢＭＬコンテンツの提示のみを必須とし、通信でＨＴＴＰプロトコルによって提供されるＢＭＬコンテンツ（ＴＲ−Ｂ１４ 第三編第２部５．１４節、ＴＲ−Ｂ１５ 第一部第三編８．１４節)の提示は必須としない。
【０１０７】
また、データ放送コンテンツ(ＢＭＬ)を起点として、以下に規定される通信アプリケーションの起動を行うための放送用拡張ＡＰＩとして、browser.startHybridcastApp()、getAITInfo()を規定する。
【０１０８】
表２は、browser.startHybridcastApp()の規定を示す。browser.startHybridcastApp()は、放送通信連携アプリケーションを起動するＡＰＩである。
【０１０９】
【表２】
【０１１０】
表３は、getAITInfo()の規定を示す。getAITInfo()は、受信中のサービスに含まれる最新のＡＩＴ情報を取得するＡＰＩである。
【０１１１】
【表３】
【０１１２】
［３．５．３ ＨＴＭＬ５］
［３．５．３．１ 記述方式］
受信機は、通信から提供されるプレゼンテーションエンジン型アプリケーションの記述方式としてＨＴＭＬ５をサポートする。JavaScript APIとして、下記のものをサポートする。なお、下記のＡＰＩのうち、Ｗ３Ｃで検討が行われているものにはWorking Draft(WD)またはEditor’s Draft(ED)が含まれる。ただし、放送波で伝送されるデータカルーセルに関連するＡＰＩは必須としない。
【０１１３】
（１）System Information API(W3C Working Draft 02 Feb. 2010)（２）WebSocket API(W3C Editor’s Draft 28 Feb. 2011)（３）File API(W3C Working Draft 26 Oct. 2010)（４）Permission for File API, System Information API(Permissions for Device API Access, W3C Working Draft 05 Oct. 2010)（５）Device Description Repository Simple API(W3C Recommendation 05 Dec. 2008)（６）API for Media Resource 1.0(W3C Working Draft 08 June 2010)（７）Web Storage(W3C Working Draft 08 Feb. 2011)（８）Server-Sent Events(W3C Editor’s Draft 28 Feb. 2011)（９）Indexed Database API(W3C Working Draft 19 Aug. 2010)（１０）SIアクセスAPI
（１１）選局API
（１２）印刷
（１３）予約
【０１１４】
［３．５．３．２ ブラウザ］
受信機のＨＴＭＬ５ブラウザは、JavaScript処理系、Web Workers（W3C Working Draft 08 Feb. 2011）、Widget Interface（W3C Working Draft 3 Feb. 2011）、HTML Canvas2D Context（W3C Editor’s Draft 28 Feb. 2011）の機能を実装する。Web Workersは、マルチタスクをサポートするため、Widget Interfaceは、独立アプリケーションをサポートするため、HTML Canvas 2D Contextは、２次元ベクトルグラフィックスをサポートするために必要である。
【０１１５】
［３．５．４ ＡＲＩＢ−Ｊ］
受信機は、通信から提供されるアプリケーション実行エンジン型アプリケーションの記述方式としてＡＲＩＢ−Ｊをサポートする。また、複数ストリーム間の同期ＡＰＩとしてDVB Bluebook A153（GEM Media Synchronization API）を用いる。
【０１１６】
［３．６ 受信機ＡＰＩ］
以下に、ＨＴＭＬ５およびＡＲＩＢ−Ｊで使用可能な受信機ＡＰＩについて説明する。
【０１１７】
［３．６．１ 名前空間］
名前空間とは、サーバ上や受信機内に存在する、映像音声コンテンツ、アプリケーション、モノメディアファイルなど、放送通信連携システムで扱う様々なリソースの位置を特定するための文字列の記述規則である。３．５．２節以降で使用する各種リソースを参照するための名前空間の記法は分類毎に規定する。リソースには、インターネットサーバー上のリソース、アプリケーションキャッシュ上のリソース、放送のリソースがある。インターネットサーバー上のリソースには、ＶＯＤコンテンツなどのストリームリソースや、アプリケーション、アプリケーションから参照されるその他のリソースなどのファイルリソースがある。放送のリソースには、放送中の番組、過去・未来の番組などのストリームリソースや、モジュール、イベントメッセージなどのカルーセルリソースがある。
【０１１８】
［３．６．２ 放送通信連携インタフェース］
放送通信連携インタフェースには、以下のインタフェースがある。
【０１１９】
（１）getRunningApplications()：実行中のアプリケーションの情報を取得する。getRunningApplicationsの戻り値は、apps[]と、アプリケーション毎のapplication_id及びrunning_levelとを含む。apps[]には、実行中アプリケーションのリストが設定される。application_idには、アプリケーションＩＤが設定され、アプリケーションが一般アプリケーション（非公式アプリケーション）の場合はnullである。running_levelには、実行レベル（認証結果および視聴者設定の状態）が設定される。
なお、セキュリティ上の観点から、他アプリケーションに関して取得できる情報は制限すべきである。
【０１２０】
（２）queryApplicationInfo()：指定したアプリケーションの情報を取得する。
（３）getProgramInfo()：受信中の放送の情報を取得する。戻り値は、tuner_state、network_id、ts_id、orig_ts_id、service_id、event_id、content_idである。tuner_stateには、受信状態を表す値が設定される。
（４）getEPGInfo()：受信中の放送のＥＩＴ（＋ＳＤＴ）中の各種情報を取得する。
（５）saveApplicationToCache()：サーバ上のアプリケーションファイルをキャッシュに保存する。
【０１２１】
（６）queryApplicationInCache()：キャッシュ中のアプリケーションファイル（アプリケーションプログラム）を検索する。queryApplicationInCache()の引数は、application_id、getDSMCCModule()、addBroadcastSignalListener()、getListFromHybridcastMenu()である。application_idには、認証機関から発行されたアプリケーションＩＤが設定される。getDSMCCModule()は、放送波から指定のモジュールを取得する。addBroadcastSignalListener()は、ＳＩ、緊急情報、カルーセルおよびイベントメッセージの更新を監視するリスナを登録する。getListFromHybridcastMenu()は、トップメニューアプリケーションのリストを取得する。queryApplicationInCache()の戻り値は、user_apps[]、broadcaster_apps[]、vendor_apps[]である。
【０１２２】
（７）addApplicationToHybridcastMenu()：トップメニューにアプリケーションを追加する。
（８）getKeyFromBroadcast()：放送から限定サーバーアクセスのための鍵情報を取得する。
（９）querySupportedFunction()：アプリケーションブラウザの機能を問い合わせる。これは、機能/ＡＰＩが利用可能かチェックすることを目的として使用される。
【０１２３】
［３．６．３ BroadacastSignalListenerインタフェース］
BroadacastSignalListenerインタフェースは、放送から取得するＳＩ、緊急情報、カルーセル、イベントメッセージを監視するためのリスナーインタフェースである。バウンドアプリケーション実行中に、紐付いている編成サービスが変更された場合にもこのインタフェースのイベントが発生する。
【０１２４】
［３．６．４ LocalDatabaseインタフェース］
LocalDatabaseインタフェースは、視聴者情報を受信機内で保持・管理するためのインタフェースである。視聴者情報は、個人情報などサーバ側に出すべきでない情報であり、視聴者ＩＤ、受信機ＩＤなど最低限の情報である。
【０１２５】
［３．６．５ 同期関連ＡＰＩ］
SynchronizationManagerインタフェースとして、DVB Bluebook A153(GEM Stream Synchronization API)と同様のＡＰＩを導入する。さらに、以下のインタフェースをＡＰＩとして追加する。
【０１２６】
（１）getCurrentSTC()：現在のＳＴＣ（System Time Clock）値を取得する。なお、ＭＰＥＧ ２ Ｓｙｓｔｅｍｓ規格では、送信側のシステムクロック（ＳＴＣ）をＭＰＥＧ２トランスポートストリーム中のＰＣＲ（Program Clock Reference）信号として多重し配信することで、受信機内部のシステムクロック（ＳＴＣ）が送信側のＳＴＣと同期されるように規定している。
（２）getCurrentPositionInProgram()：番組開始からの経過時間を取得する。
（３）delayStreamPresentation()：提示中の放送ストリームの遅延提示を開始する。
（４）getCurrentDelay()：提示中の放送ストリームの（本来の提示時刻からの）遅延時間量を取得する。
【０１２７】
［３．６．６ SecurityExceptionインタフェース］
アプリケーションが、現在の実行レベルにおいて禁止されている関数呼び出しおよびプロパティ操作をした場合に発生する例外のインタフェースである。ecurityExceptionインタフェースは、上記各ＡＰＩの呼び出し、あるいは、放送を参照するオブジェクト(ＨＴＭＬ５なら<video>、ＡＲＩＢ−Ｊなら○○Controller)に対する各種操作によって発生する。
【０１２８】
［３．７ 受信機機能］
放送通信連携システムの受信機は、受信機機能として、アプリケーションローンチャーを備える。アプリケーションローンチャーは、受信機内に蓄積されたアプリケーションの起動、既知のリポジトリから独立アプリケーションの選択、ＡＩＴによって起動指示が記述されたアプリケーションのうち、コントロールコードが「PRESENT」のアプリケーションの選択に用いる。
【０１２９】
［４． セキュリティ］
［４．１ 放送通信連携アプリケーションの管理］
放送事業者の要件を満たしつつ放送通信連携サービスを普及・活性化させるために、放送事業者およびその関係者だけではなく、幅広いサービス事業者や個人が参入できる枠組みが必要となる。本放送通信連携システムでは、セキュリティの観点からアプリケーションを「Ａアプリケーション」と「一般アプリケーション」に分類し、受信機において双方のアプリケーションを実行可能とする。
【０１３０】
図１２は、放送通信連携システムにおけるアプリケーション管理モデルを示す。「Ａアプリケーション」は、登録管理者（第三者機関）への事前登録を行うことにより放送通信連携システムの仕様で期待する動作が保証される。「Ａアプリケーション」は、登録時にＩＤと署名が付与され、受信機において２．２節で定義するセキュアマネージャーにより署名が検証され、すべてのＡＰＩへのアクセスが可能となり、放送リソースを利用した番組連動サービスが行えるようになる。また、放送事業者から送出されるＡＩＴにより、放送事業者の要件に沿ったきめ細かい提示制御が可能となる。
一方、「一般アプリケーション」は、事前の登録は不要であるが、放送通信連携システムの仕様で期待する動作は保証されず、アプリケーションから放送関連のＡＰＩを扱うことはできない。「一般アプリケーション」はＩＤと署名が付与されないため、個々のアプリケーションの指定は困難であるが、放送事業者の要件に基づいた提示制限を加えた上で実行させることは可能である。
【０１３１】
［４．２ セキュアマネージャーの機能モデル］
図１３は、セキュアマネージャーの機能モデルを示す。セキュアマネージャーは、受信機においてセキュリティを総合的に管理する機能である。
【０１３２】
［４．２．１ アプリケーション監視・制御機能］
受信機において動作するアプリケーションは、アプリケーションファイルの配布の形態により、上述したように、「Ａアプリケーション」と「一般アプリケーション」の２種類に大別される。「Ａアプリケーション」と「一般アプリケーション」は、４．１節に示すようにＩＤと署名の有無によって区別され、受信機におけるＡＰＩのアクセス範囲や放送事業者からの制御範囲が異なるなど、アプリケーション実行時の動作内容が異なる。アプリケーション監視・制御機能は、Ａアプリケーションまたは一般アプリケーションの種別の違いを識別し、確実にアプリケーション実行時の動作を制御することを目的とする。
【０１３３】
（１）アプリケーション認証：受信機は、実行するすべてのアプリケーションについて、Ａアプリケーションまたは一般アプリケーションのいずれか、さらにＡアプリケーションであればＩＤを識別する。Ａアプリケーションまたは一般アプリケーションの区別は、アプリケーションファイル（アプリケーションプログラム）に付与された署名の有無を確認しこれを検証することによって行う。Ａアプリケーションであれば、受信機はさらに、署名に記述されたアプリケーションＩＤを取得する。アプリケーションの識別は、アプリケーションの取得時、または、起動時に行うものとする。
（２）画面提示制御：４．３節に後述する。
（３）リソースアクセス制御：受信機は、実行中のアプリケーションの放送リソース等のＡＰＩへのアクセス制御を行う。アプリケーションがＡＰＩにアクセスしようとする時に、当該アプリケーションが一般アプリケーションであれば、ＡＰＩの種別によってアクセスを制限する。
また、アプリケーションがディスプレイへの画面表示ＡＰＩにアクセスする際には、Ａアプリケーションまたは一般アプリケーションの種別と、選局中の放送事業者の提示ポリシーに基づき、画面提示制御を実行する。詳細は４．３節に後述する。
（４）リボケーション：アプリケーションのリボケーション機能を備える。
【０１３４】
［４．２．２ 受信機保護］
受信機は、視聴者情報保護およびウィルス対策等の保護機能を備える。
【０１３５】
［４．３ アプリケーションの画面提示制御］
［４．３．１ 画面提示制御の概要］
放送通信連携サービスでは、放送番組と同時に関連する通信アプリケーションを提示させることにより、放送サービスの利便性を拡張することができる。一方、通信サービスの利用により、受信機の画面上で放送番組と通信アプリケーションが混在して提示されることが想定される。提示方法によっては、放送番組に通信アプリケーションの画面が重なり、放送番組の一意性や作品性が損なわれるだけでなく、緊急地震速報などの緊急性の高い情報が正確に視聴者に伝えられなくなる恐れがある。画面提示制御により、放送通信連携サービスにおいて、放送事業者の意図に基づいたアプリケーションの提示制御を行う。
【０１３６】
図１４は、画面提示制御方式の概念を示す図である。画面提示制御方式は、個々の放送番組に対して通信アプリケーションをどのように画面上に提示させるかという放送事業者の提示ポリシーを受信機に反映させることを意図したもので、これをコンテンツの提示制御と呼ぶこととする。コンテンツの提示制御では、編成に応じた番組単位の提示制御、緊急地震速報などの番組中に発生するイベントに対する提示制御、アプリケーション単位の提示制御を実現する。
【０１３７】
［４．３．２ 画面提示制御の基本動作］
図１５は、画面提示制御の基本動作モデルを示す図である。放送事業者の提示ポリシーを受信機に反映させるために、予め放送事業者が想定した、放送番組に対する通信コンテンツの提示方法を、提示ルールとして受信機で管理する。具体的には、通信コンテンツの提示方法として、重ね合わせの順序や並べ方の違いなどに応じてレベル分けを行い、提示レベル（ポリシーレベル）と提示方法のテーブルを提示ルールとして受信機内に保持する。放送事業者は指定する提示レベルを放送波に多重して伝送し、受信機はその提示レベルと提示ルールを照合し、提示方法を決定する。これにより、放送事業者の提示ポリシーに基づいた提示制御を実現することができる。
【０１３８】
［４．３．３ 制御情報の伝送・多重方式］
放送事業者の提示ポリシーを伝送する制御情報のフォーマットに関して、デジタル放送で使用されている番組配列情報を用いる方式として３つの具体例を挙げる。番組単位での画面提示制御として、既存のＥＩＴ(イベント情報テーブル：Event Information Table)を用いる方式と、ＥＩＴを拡張して用いる方式（ＥＩＴ＋）がある。また、サービス（チャンネル）単位での画面提示制御として、放送信号のＡＩＴを拡張して用いる方式がある。さらに、番組中にリアルタイムに発生する事象単位での画面提示制御として、番組配列情報以外の放送局から送出される情報を用いる方式がある。以下に、４つの方式の詳細を記載する。
【０１３９】
（１）ＥＩＴの番組ジャンル（ＥＩＴ）：既存のＥＩＴのコンテント記述子に記述される番組ジャンルからポリシーレベルを判断する。受信機はそのために、番組ジャンルとポリシーレベルの対応表を管理する。ＡＲＩＢ規格との関連は、ＡＲＩＢ ＳＴＤ−Ｂ１０
第２部 ６．２．４、付録Ｈである。
【０１４０】
表４は、番組ジャンルとポリシーレベルの関係の具体例を示す表である。番組ジャンル（program_genre）は、大分類を表す「content_nibble_level1」（0x0〜0xF）と、中分類を表す「content_nibble_level2」（0x0〜0xF）の２段階で構成される。受信機で管理するテーブルは中分類のジャンルまで対象とし、それぞれポリシーレベルの値を定義する。
【０１４１】
【表４】
【０１４２】
（２）ＥＩＴに新記述子追加（ＥＩＴ＋）：ＥＩＴのイベント情報セクションに新しい記述子を追加し、ポリシー情報を記述する。受信機は、この記述子を解釈し所望の処理を実行することで、番組単位でのポリシーレベルに応じた制御を実現する。ＡＲＩＢ規格との関連は、ＡＲＩＢ ＴＲ−Ｂ１４（第二分冊） 第３部 ３１．３、ＡＲＩＢ ＳＴＤ−Ｂ１０ 第２編 ５．２．７である。
【０１４３】
表５は、イベントセキュリティ記述子の構造を示す表である。ＥＩＴ＋の場合、同図に示すイベントセキュリティ記述子を新規に定義し、ＥＩＴ内の記述子領域にこのイベントセキュリティ記述子を格納して伝送する。イベントセキュリティ記述子には、ポリシーレベル（policy_level）、アプリケーションＩＤ（application_identifier）、制御コード（application_control_code）、優先度（application_priority）、プロトコル識別（protocol_id）、番組関連フラグ（associated_application_flag）を設定する。
【０１４４】
【表５】
【０１４５】
policy_levelは、番組単位でのポリシーレベルを表す。ポリシーレベルは、１〜４の値とする。
application_identifier()は、アプリケーションを識別するための識別子である。表６は、application_identifier()の構造を示す。
【０１４６】
【表６】
【０１４７】
organization_idは、アプリケーションを作成した組織を表し、0x00000063以降の値をとる。application_idは、アプリケーションを識別する番号を表す。application_idは、組織識別内で一意に付与される。
【０１４８】
application_control_codeは、アプリケーション状態を制御する制御コードを規定する。表７は、制御コードの規定を示す。
【０１４９】
【表７】
【０１５０】
application_priorityは、アプリケーション毎のポリシーレベルを示す。アプリケーション毎のポリシーレベルは、サービス内で告知されているアプリケーション間の相対的な優先度を示す。優先度は、１〜４の値とする。
【０１５１】
protocol_idは、アプリケーションファイルを伝送するプロトコルを示す。表８は、protocol_idの規定を示す。
【０１５２】
【表８】
【０１５３】
associated_application_flagは、番組に連動するアプリケーションであるか否かを示す。表９は、protocol_idの規定を示す。
【０１５４】
【表９】
【０１５５】
（３）ＡＩＴのテーブル定義および新記述子の追加（ＡＩＴ＋）：ＡＩＴを拡張してポリシー情報を伝送する。受信機は、このテーブルを解釈し所望の処理を実行することで、随時発生するイベントに対してポリシーレベルに応じた制御を実現する。ＡＲＩＢ規格との関連は、ＡＲＩＢ ＳＴＤ−Ｂ２３ 第２部 １０．１６である。
【０１５６】
表１０に、ＡＩＴのデータ構造を示す。表１０に示すＡＩＴは、ＡＲＩＢ ＳＴＤ−Ｂ２３で規定されているＡＩＴのデータ構造を拡張したものである。ＡＩＴには、ポリシーレベル、アプリケーションＩＤ、制御コードを記述する。なお、ＡＩＴはセクション形式で送信され、イベント継続中は常時送信されるものとする。アプリケーションＩＤは、application_identifier()に記述し、制御コードはapplication_control_codeに記述する。
なお、これらの詳細は、（２）ＥＩＴの拡張で記載したものと同様である。
さらに、ポリシーレベルを記述するために、新たにセキュリティポリシー記述子を定義し、ＡＩＴの共通記述子ループに格納して伝送する。
【０１５７】
【表１０】
【０１５８】
表１１は、新たに定義するセキュリティポリシー記述子の構造を示す。
【０１５９】
【表１１】
【０１６０】
（４）緊急警報放送および緊急地震速報（ＥＷＳ／ＥＥＷ）：放送局から送出される緊急情報を用いてポリシーレベルを判断する。受信機においては予め緊急情報とポリシーレベルとの対応はなされているものとし、緊急警報放送であれば、ＴＭＣＣの緊急警報放送用起動フラグを、緊急地震速報では文字スーパー管理パケットを監視することで、緊急情報の発生と終了が検知され、その際のポリシーレベルを判断することが可能になる。ＡＲＩＢ規格との関連は、ＡＲＩＢ ＳＴＤ−Ｂ３１ ３．１５およびＡＲＩＢ ＳＴＤ−Ｂ２４ 第一編 第３部 第９章である。
【０１６１】
なお、上記の（１）〜（４）のそれぞれの方式は並行して同時に送出することが可能である。したがって、どの方式で送られたものを優先させてポリシーレベルを決定するかを決めておく必要がある。優先順位は以下の通りである。
【０１６２】
ＥＷＳ／ＥＥＷ＞ ＡＩＴ＋ ＞ ＥＩＴ＋ ＞ ＥＩＴ
【０１６３】
受信機はこの優先順位に基づき、ポリシーレベルを判断することで、放送事業者の意図に基づいた、緊急時の事象を優先させた画面提示制御が可能となる。
【０１６４】
［４．３．４ 画面提示制御の例］
図１６は、ポリシーレベルに応じた画面提示制御の例を示す。
番組のポリシーレベルが「１」の場合、Ａアプリケーションのアプリケーション画面のアプリケーション画面および一般アプリケーションのアプリケーション画面の双方とも、放送画面上への重ね合わせが許可される。
番組のポリシーレベルが「２」の場合、Ａアプリケーションのみが放送画面上への重ね合わせが許可され、一般アプリケーションのアプリケーション画面については、放送画面上への重ね合わせは禁止され、放送画面の外側への表示のみが許可される。
番組のポリシーレベルが「３」の場合、Ａアプリケーションのアプリケーション画面、及び、一般アプリケーションのアプリケーション画面とも表示が許可されるが、全てのアプリケーション画面について、放送画面上への重ね合わせは禁止され、放送画面の外側への表示のみが許可される。
ポリシーレベルが「４」の場合、放送画面の全画面表示のみが許可される。
【０１６５】
図１７は、緊急地震速報受信時の提示制御の例を示す。番組Ａの番組ポリシーレベルが「１」である場合、番組Ａの放送時間帯においては、Ａアプリケーションのアプリケーション画面、一般アプリケーションのアプリケーション画面とも放送画面上に重ね合わせて表示される。しかし、受信機は、番組Ａの放送時間帯の中でも緊急地震速報が発生している時間帯におけるポリシーレベルは、緊急地震速報のポリシーレベル「４」であると判断する。そのため、受信機は、番組Ａの放送時間帯であっても、緊急地震速報が発生している時間帯では、Ａアプリケーションのアプリケーション画面、及び、一般アプリケーションのアプリケーション画面とも、放送画面上への重ね合わせを禁止する。
【０１６６】
［上述した放送通信連携システムを適用した本発明の実施形態の説明］
次に、図１に示す本発明の一実施形態を説明する。
図１８は、本発明の一実施形態による放送通信連携システムの全体構成図である。同図に示すように、本実施形態の放送通信連携システムは、放送局が保有する放送事業者装置１、サービス事業者が保有するサービス事業者サーバ群２、システム管理者が保有するリポジトリサーバ３、及び、視聴者が保有する受信機４を備えて構成される。同図においては、受信機４を１台のみ示しているが、現実には複数台の受信機４が設けられる。
【０１６７】
放送事業者装置１は、放送送出装置１１及び放送局サーバ群１２を備える。
放送送出装置１１は、図３に示す放送局設備に相当し、番組編成設備、番組送出設備、送信設備等から構成されるデジタル放送用の放送設備である。
【０１６８】
放送送出装置１１は、放送関連データ管理部１１１、信号設定部１１２及び放送送出部１１３を備えて構成される。
放送関連データ管理部１１１は、各番組の番組セキュリティポリシーデータ、Ａアプリケーションのアプリケーションセキュリティーポリシーデータ、その他のポリシーデータなどを管理する。
番組セキュリティポリシーデータは、番組のポリシーレベルを示すポリシーレベルデータ、番組にバウンドされたアプリケーションのアプリケーションＩＤ、番組にバウンドされたアプリケーションに対する制御コードなどを含む。
アプリケーションセキュリティポリシーデータは、アプリケーションがバウンドされている番組を特定する情報や、アプリケーションのプロトコル識別、ロケーション情報などを含む。ロケーション情報は、アプリケーションの格納位置（格納場所）を示し、例えば、アプリケーションをダウンロード可能な受信機アプリサーバ２１やリポジトリサーバ３のＵＲＬである。プロトコル識別は、アプリケーションが放送により伝送されたか、通信により伝送されたかを示す。
なお、Ａアプリケーションのみが番組にバウンドされる。
【０１６９】
ポリシーデータは、提示ルールデータとポリシーレベルテーブルを含む。
提示ルールデータは、ポリシーレベル毎の提示方法を記述したデータである。提示方法は、画面表示方法と音声出力方法を含む。画面表示方法には、例えば、放送画面（番組の映像）のみ表示する、Ａアプリケーション及び一般アプリケーションともアプリケーション画面（アプリケーションの映像）を放送画面に重ねてあるいは放送画面の外に表示する、Ａアプリケーションのアプリケーション画面のみ放送画面に重ねて表示し、一般アプリケーションのアプリケーション画面は放送画面の外に表示する、などの方法がある。音声出力方法には、例えば、放送番組の音声のみを出力する、放送番組の音声とＡアプリケーションまたは一般アプリケーションの音声を独立にあるいは混合して出力する、などの方法がある。
ポリシーレベルテーブルは、番組のジャンルに対応したポリシーレベルや、各イベントのポリシーレベルを記述したデータである。イベントとは、例えば、緊急警報信号や緊急地震速報など、番組とは必ずしも連動して発生しない放送の内容である。
【０１７０】
信号設定部１１２は、放送送出部１１３が伝送する放送信号に各種データを設定する。
信号設定部１１２は、放送関連データ管理部１１１が管理している番組セキュリティポリシーデータやアプリケーションセキュリティーポリシーデータに基づいて、放送信号にＡＩＴ、番組のポリシーレベルデータを設定する。信号設定部１１２は、番組にバウンドされたアプリケーションのＡＩＴを独立したＥＳとして放送信号（放送ＴＳ）に多重するか、データカルーセルに設定する。あるいは、信号設定部１１２は、番組にバウンドされたアプリケーションのＡＩＴと同等の情報をＥＩＴに設定する。また、信号設定部１１２は、番組のポリシーレベルデータをＥＩＴ（表５）、または、ＡＩＴ（表１１）に設定する。なお、番組のジャンルに対応するポリシーレベルを用いる場合には、ポリシーレベルデータを放送信号に設定しなくともよい。また、信号設定部１１２は、アプリケーションファイルをデータカルーセル等に設定する。また、信号設定部１１２は、放送関連データ管理部１１１が管理しているポリシーデータをセクション形式により放送信号に設定するか、エンジニアリングサービスあるいはデータカルーセルに設定する。
放送送出部１１３は、デジタル放送の放送信号を伝送する。放送信号は、信号設定部１１２により設定された情報を含む。
【０１７１】
放送局サーバ群１２は、図３に示す放送局サーバ群に相当し、コンテンツ管理サーバ１３、コンテンツ配信サーバ１６、放送局サービスサーバ１７及び通知サーバ１８を備えて構成される。
コンテンツ管理サーバ１３は、番組管理サーバ１４及びメタデータ管理サーバ１５を備えて構成される。番組管理サーバ１４は、すでに放送された番組や放送される番組を管理する。メタデータ管理サーバ１５は、各番組に関するメタデータを管理する。メタデータは、例えば、番組タイトル、番組ＩＤ、番組概要、出演者、放送日時、台本、字幕、解説のデータを含む。
【０１７２】
コンテンツ配信サーバ１６は、インターネットなどの通信網９を介して受信機４と接続され、受信機４から要求されたコンテンツのコンテンツデータを配信する。
放送局サービスサーバ１７は、サービス事業者サーバ群２に放送局のサービスのコンテンツデータを送信する。放送局のサービスには、例えば、ソーシャルネットサービス、ブログサービス等がある。
【０１７３】
通知サーバ１８は、通信網９を介して受信機４と接続され、放送送出装置１１の放送関連データ管理部１１１から取得した番組セキュリティポリシーデータとアプリケーションセキュリティーポリシーデータとに基づいて、番組にバウンドされたアプリケーションのＡＩＴ（図６）及び番組のポリシーレベルデータを受信機４に配信する。また、通知サーバ１８は、放送送出装置１１の放送関連データ管理部１１１から取得したポリシーデータを受信機４に配信する。なお、これらの情報の全てまたは一部は、通知サーバ１８からの配信を行なわず、放送送出装置１１の放送送出部１１３が放送信号のみで伝送する場合もある。
【０１７４】
サービス事業者サーバ群２は、図３に示すサービス事業者サーバ群に相当し、受信機アプリサーバ２１、サービスサーバ２２、コンテンツ配信サーバ２３及び通知サーバ２４を備えて構成される。受信機アプリサーバ２１、サービスサーバ２２、コンテンツ配信サーバ２３及び通知サーバ２４は、通信網９を介して受信機４と接続される。
【０１７５】
受信機アプリサーバ２１は、各アプリケーションを管理し、受信機４へアプリケーションファイルを配信する。
サービスサーバ２２は、例えば、多言語字幕サーバ、話速変換音声サーバ、ソーシャルＴＶサーバ、レコメンドサーバ、ブックマークサーバなどであり、受信機４から要求されたサービスのコンテンツデータを配信する。
コンテンツ配信サーバ２３は、例えば、ＶＯＤ配信サーバ、字幕配信サーバ、マルチビュー配信サーバであり、受信機４から要求されたコンテンツのコンテンツデータを配信する。
通知サーバ２４は、アプリケーションのＡＩＴ（図６）を受信機４に送信する。なお、Ａアプリケーションの場合、通知サーバ２４は、放送送出装置１１の放送関連データ管理部１１１から取得した番組セキュリティポリシーデータやアプリケーションセキュリティーポリシーデータに基づいたＡＩＴ（図６）を送信してもよい。
【０１７６】
リポジトリサーバ３は、図３に示すリポジトリに相当し、通信網９を介して受信機４と接続される。リポジトリサーバ３は、サービス事業者が生成したアプリケーションファイル（アプリケーションプログラム）に電子署名を行なうとともに、アプリケーションファイル（アプリケーションプログラム）の電子署名の認証に必要なデータを受信機４に送信する。また、リポジトリサーバ３は、Ａアプリケーションの一覧を示すデータや、そのＡアプリケーションのロケーション情報を受信機４に送信する。なお、リポジトリサーバ３が電子署名されたＡアプリケーションのアプリケーションファイルを受信機４へ送信してもよく、受信機アプリサーバ２１がリポジトリサーバ３から電子署名されたＡアプリケーションのアプリケーションファイルを受信し、受信機４へ送信してもよい。また、リポジトリサーバ３は、ＡアプリケーションのＡＩＴを受信機４に送信してもよい。
また、リポジトリサーバ３は、放送送出装置１１の放送関連データ管理部１１１から受信した番組セキュリティポリシーデータやアプリケーションセキュリティーポリシーデータに基づいて、番組にバウンドされたＡアプリケーションのＡＩＴ（図６）を受信機４に送信してもよい。
【０１７７】
受信機４は、図３に示す受信機に相当し、例えば、テレビ受像機、セットトップボックス、パーソナルコンピュータ、携帯端末等のデバイスである。
【０１７８】
図１９は、受信機４の内部構成を示す機能ブロック図である。同図に示すように、受信機４は、放送受信部４０１、分離部４０２、時計４０３、第１同期用バッファ４０４−１、第２同期用バッファ４０４−２、第１デコーダ４０５−１、第２デコーダ４０５−２、データ放送実行部４０６、映像制御部４０７、映像表示部４０８、音声制御部４０９、音声出力部４１０、通信入出力部４１１、アプリケーション実行制御部４１２、提示制御部４１３、操作入力部４１４、選局部４１５、ローカル情報記憶部４１６及び外部Ｉ／Ｆ部４１７を備えて構成される。
【０１７９】
放送受信部４０１は、放送信号を受信するチューナである。放送信号は、無線放送信号及び有線放送信号またはいずれか一方である。無線放送信号は、放送局側の送信アンテナが送信した放送電波（地上波）や、衛星が中継する衛星波を、受信アンテナで受信することにより得られる信号である。有線放送信号は、光ケーブルや同軸ケーブル等を介して放送局側から伝送される信号である。放送受信部４０１は、放送信号を受信して復調し、放送ストリーム（ＴＳ）を出力する。
分離部４０２は、デマルチプレクサであり、放送受信部４０１から供給された放送ストリームを、ＰＣＲ（Program Clock Reference）、映像データ、音声データ、字幕データ、データ放送、ＰＳＩ（Program Specific Information）／ＳＩ（Service Information）、独立エレメンタリストリーム（ＥＳ）で送信されたＡＩＴなどの各種データに分離する。なお、ＡＩＴはデータ放送に含まれる場合や、ＡＩＴと同様の内容がＳＩを構成するＥＩＴに設定される場合もある。また、分離部４０２は、放送信号からアプリケーションファイルを分離して出力する場合もある。
【０１８０】
通信入出力部４１１は、通信網９を介した通信によるデータの入出力を行う。通信入出力部４１１は、通信網９を経由して送信されたＡＩＴやアプリケーションファイルをアプリケーション実行制御部４１２に出力する。また、通信入出力部４１１は、通信網９を経由して送信された番組のポリシーレベルデータやポリシーデータを提示制御部４１３へ出力する。また、通信入出力部４１１は、アプリケーション実行制御部４１２により実行されるアプリケーションの指示に従って、コンテンツ配信サーバ１６やコンテンツ配信サーバ２３から配信されるコンテンツデータ、サービスサーバ２２から配信されるコンテンツデータを通信網９を経由して受信し、第２同期用バッファ４０４−２に出力する。
【０１８１】
操作入力部４１４は、視聴者による操作を受け付けるインタフェースであり、例えば、リモートコントローラ、携帯電話、タブレット端末等から視聴者が入力した情報を受信する受信装置や、キーボード、マウスなどである。操作入力部４１４は、視聴者が入力したメディア（地上／ＢＳ）やチャンネルの選択指示を選局部４１５に出力する。また、操作入力部４１４は、放送通信連携サービスの開始や終了の指示、アプリケーションに対する指示をアプリケーション実行制御部４１２に出力する。
選局部４１５は、操作入力部４１４に入力された操作に従って、放送受信部４０１において受信するメディアやチャンネルを制御する。
【０１８２】
データ放送実行部４０６は、デジタル放送信号により送信されたデータ放送アプリケーションを実行し、データ放送の画像（グラフィック）データを映像制御部４０７へ出力する。データ放送実行部４０６は、放送通信連携サービスのアプリケーションを起動するためのＡＰＩを備える。データ放送実行部４０６がデータ放送アプリケーションを実行して、放送通信連携サービスのアプリケーションを起動するＡＰＩが呼び出された場合、データ放送実行部４０６は、アプリケーションの起動をアプリケーション実行制御部４１２に指示する。また、データ放送実行部４０６は、データカルーセルによって送信されたＡＩＴやアプリケーションファイルをデータ放送から取得してアプリケーション実行制御部４１２に出力する。また、データ放送実行部４０６は、データカルーセルによって送信されたポリシーデータをデータ放送から取得して提示制御部４１３に出力する。
【０１８３】
アプリケーション実行制御部４１２は、放送通信連携サービスのアプリケーションを実行する。アプリケーション実行制御部４１２は、実行しているアプリケーションに従って、コンテンツ配信サーバ１６、コンテンツ配信サーバ２３、あるいは、サービスサーバ２２から受信したコンテンツデータをデコードするように第２デコーダ４０５−２に指示する。コンテンツデータは、映像データ、音声データの一方または両方を含む。映像データは、例えば、動画、静止画、テキストデータなどである。また、アプリケーション実行制御部４１２は、実行しているアプリケーションに従って、映像制御部４０７にグラフィック（映像）データや映像制御指示を出力し、音声制御部４０９に音声データや音声制御指示を出力する。
【０１８４】
時計４０３は、タイマーカウンタ値を出力する。時計４０３は、ＰＣＲが示すタイマーカウンタ値により発振器の周波数を調整し、放送送信側と時刻を同期させる。
第１同期用バッファ４０４−１は、分離部４０２から出力される映像データ、音声データ、字幕データを記憶する。映像データ、音声データ、字幕データのエレメンタリーストリーム（ＥＳ）から生成されたＰＥＳ（Packetized Elementary Stream）は、放送ストリーム（ＴＳ）を構成するトランスポートパケット（Transport Packet）に分割されて設定される。ＰＥＳのヘッダには、ＰＴＳ（提示時刻情報：Presentation Time Stamp）が含まれる。第１同期用バッファ４０４−１は、分離部４０２から出力された映像データ、音声データ、字幕データを、第１デコーダ４０５−１の指示によりＰＥＳパケット単位で出力する。
第２同期用バッファ４０４−２は、通信入出力部４１１が受信したコンテンツやサービスのコンテンツデータを記憶する。あるいは、第２同期用バッファ４０４−２は、操作入力部４１４により入力された視聴者の指示に従って、分離部４０２から出力される映像データ、音声データ、字幕データを記憶する。第２同期用バッファ４０４−２は、記憶しているコンテンツデータあるいは番組の映像データ、音声データ、字幕データを第２デコーダ４０５−２の指示によりＰＥＳパケット単位で出力する。
【０１８５】
第１デコーダ４０５−１は、時計４０３から出力された時刻に対応したＰＴＳが設定されている第１同期用バッファ４０４−１内のＰＥＳパケットを特定し、特定したＰＥＳパケットからエンコードされた映像データ、音声データ、字幕データを読み出し、読み出したデータをデコードして出力する。
第２デコーダ４０５−２は、時計４０３から出力された時刻に対応するＰＴＳが設定されている第２同期用バッファ４０４−２内のコンテンツデータあるいは番組のＰＥＳパケットを特定し、特定したＰＥＳパケットからエンコードされた映像データ、音声データ、字幕データを読み出し、読み出したデータをデコードして出力する。
【０１８６】
提示制御部４１３は、選局されている番組のポリシーレベルあるいは発生中のイベントのポリシーレベルと、提示ルールデータとに従って提示方法（画面表示方法及び音声出力方法）を決定する。提示制御部４１３は、決定した画面表示方法により、放送画面、Ａアプリケーションのアプリケーション画面、及び、一般アプリケーションのアプリケーション画面を表示するよう映像制御部４０７に指示する。さらに、提示制御部４１３は、決定した音声出力方法により、放送の音声データによる音声、Ａアプリケーションの音声データによる音声、及び、一般アプリケーションの音声データによる音声を出力するよう音声制御部４０９に指示する。
【０１８７】
映像制御部４０７は、第１デコーダ４０５−１から出力された番組の映像データ及び字幕データに基づく放送画面と、第２デコーダ４０５−２から出力されたコンテンツデータの映像データに基づくＡアプリケーション、一般アプリケーションのアプリケーション画面とを、提示制御部４１３またはアプリケーション実行制御部４１２から指示された画面表示方法に従って映像表示部４０８に表示させる。また、アプリケーション実行制御部４１２からアプリケーションの実行によりグラフィック（映像）データが出力される場合、映像制御部４０７は、提示制御部４１３またはアプリケーション実行制御部４１２から指示された画面表示方法に従って、その映像データに基づく表示画面を併せて映像表示部４０８に表示させる。なお、第２デコーダ４０５−２からは、他の番組の映像データ及び字幕データが出力される場合もある。
【０１８８】
映像表示部４０８は、一般的なディスプレイであり、放送およびアプリケーションの画面を表示する。例えば、映像表示部４０８は、番組の放送画面に、通信網９から受信したコンテンツデータの動画、静止画、テキストや、アプリケーションの実行によってアプリケーション実行制御部４１２から出力されたグラフィックなどのアプリケーション画面、または、他の番組の放送画面を合成した映像を表示する。
【０１８９】
音声制御部４０９は、第１デコーダ４０５−１から出力された番組の音声データに基づく音声と、第２デコーダ４０５−２から出力されたコンテンツデータの音声データに基づくＡアプリケーションや一般アプリケーションの音声と、アプリケーションの実行によってアプリケーション実行制御部４１２から出力された音声データに基づく音声とを、提示制御部４１３またはアプリケーション実行制御部４１２より指示された音声出力方法に従って音声出力部４１０から出力させる。なお、第２デコーダ４０５−２からは、他の番組の音声データが出力される場合もある。音声出力部４１０は、一般的なスピーカーあり、放送およびアプリケーションの音声を出力する。
【０１９０】
ローカル情報記憶部４１６は、ユーザ情報などの各種データを記憶する。
外部インタフェース部（以下、「外部Ｉ／Ｆ部」と記載する。）４１７は、ＬＡＮ（Local Area Network）などのホームネットワークなどに接続される機器８との間でデータを送受信する。機器８は、受信機４と連携動作する端末であり、例えば、パーソナルコンピュータ、携帯電話、タブレット、スマートフォン、ＰＤＡである。
【０１９１】
なお、受信機４がセットトップボックスなどの場合、映像表示部４０８及び音声出力部４１０は、受信機４と接続される外部装置とする。
【０１９２】
図２０は、アプリケーション実行制御部４１２の詳細な構成を示すブロック図である。
同図に示すように、アプリケーション実行制御部４１２は、アプリケーション記憶部４３１、アプリケーション認証部４３２、アプリケーション管理部４３３、アプリケーション制御部４３４、アプリケーション実行部４３５、リソースアクセス制御部４３８及びリソース制御部４３９を備える。
【０１９３】
アプリケーション記憶部４３１は、通信入出力部４１１が通信網９を介して受信したアプリケーションファイル、あるいは、データ放送実行部４０６がデータ放送から取得したアプリケーションファイル、または、分離部４０２が放送信号から分離したアプリケーションファイルを記憶する。アプリケーションファイルは出荷時などに予めアプリケーション記憶部４３１に記憶されていてもよい。アプリケーション記憶部４３１は、主記憶装置及びディスク等の補助記憶装置からなり、例えば、アプリケーションファイルはディスクに記憶され、実行時に主記憶装置に読み出される。この場合、オンザフライで実行されるアプリケーションのアプリケーションファイルは、ディスクには記憶されずに主記憶装置のみに記憶され、実行が終了した場合は主記憶装置から削除される。
【０１９４】
アプリケーション認証部４３２は、リポジトリサーバ３から電子署名の認証に必要なデータを受信し、受信したデータを用いてアプリケーションファイル（アプリケーションプログラム）に付加された電子署名の検証を行う。例えば、アプリケーション認証部４３２は、リポジトリサーバ３から受信した公開鍵を用いて、電子署名されたアプリケーションファイルを復号する。その結果、所定のデータ列が得られた場合、アプリケーション認証部４３２は、電子署名の検証が成功したと判断する。アプリケーション認証部４３２は、電子署名の検証が成功した場合、Ａアプリケーションであると判断し、電子署名の検証が不成功である場合、あるいは、電子署名が付加されていない場合、一般アプリケーションであると判断する。
【０１９５】
アプリケーション管理部４３３は、アプリケーション実行部４３５によるアプリケーションの起動または停止の状態、起動しているアプリケーションの出力状況を管理する。出力状況とは、動作中のアプリケーションから画像や音声が出力されているか否かの情報である。アプリケーション管理部４３３は、提示制御部４１３からの問い合わせを受け、起動されているアプリケーションの出力状況や、起動されているアプリケーションがＡアプリケーションであるか一般アプリケーションであるかの応答を返送する。
【０１９６】
アプリケーション制御部４３４は、番組にバウンドされているアプリケーションに対する制御コードや、操作入力部４１４により入力されたアプリケーションに対する指示に従って、アプリケーション実行部４３５におけるアプリケーションの起動や停止などを制御する。また、アプリケーション制御部４３４は、データ放送実行部４０６から起動が指示されたアプリケーションの起動をアプリケーション実行部４３５に指示する。アプリケーション制御部４３４は、操作入力部４１４からの入力に従ってチャンネルが変更される場合、変更前のチャンネルの番組にバウンドされているアプリケーションの終了と、変更後のチャンネルの番組にバウンドされているアプリケーションの起動をアプリケーション実行部４３５に指示する。なお、アプリケーション制御部４３４は、番組にバウンドされているアプリケーションや、バウンドされているアプリケーションに対する制御コードを、放送信号の独立ＥＳもしくはデータ放送に含まれるＡＩＴ、放送信号のＥＩＴから得られるＡＩＴと同等の情報、または、通信入出力部４１１を介して通知サーバ１８もしくは通知サーバ２４から受信したＡＩＴから取得する。また、アプリケーション制御部４３４は、ＡＩＴに設定されているロケーション情報を宛先としてアプリケーションファイルのダウンロード要求を送信する。受信機４からダウンロード要求を受信したリポジトリサーバ３、または、受信機アプリサーバ２１は、アプリケーションファイルを受信機４に配信する。
【０１９７】
アプリケーション実行部４３５は、受信機ＡＰＩ部４３６及び端末連携ＡＰＩ部４３７を備える。アプリケーション実行部４３５は、アプリケーション制御部４３４からの指示に従って、起動が指示されたアプリケーションのアプリケーションプログラムをアプリケーション記憶部４３１から読み出して実行する。アプリケーション実行部４３５がアプリケーションプログラムを実行することにより、受信機４上でアプリケーションが動作し、アプリケーション実行部４３５は通信網９を経由してコンテンツをコンテンツ配信サーバ１６やコンテンツ配信サーバ２３に要求したり、サービスをサービスサーバ２２に要求したりする。また、アプリケーションプログラムを実行することにより、アプリケーション実行部４３５は、映像制御部４０７へグラフィックデータや映像制御指示を出力したり、音声制御部４０９に音声データや音声制御指示を出力したりする。
【０１９８】
受信機ＡＰＩ部４３６は、アプリケーション実行部４３５がアプリケーションを実行するにあたって受信機４内の各リソースを利用するためのＡＰＩである受信機ＡＰＩを実行する。受信機ＡＰＩ部４３６が受信機ＡＰＩを実行することにより、アプリケーション実行部４３５が実行しているアプリケーションプログラムから受信機４内のリソースが利用可能となる。
端末連携ＡＰＩ部４３７は、外部Ｉ／Ｆ部４１７により通信可能なホームネットワーク上の機器８や、通信網９を介して接続される機器が受信機４の機能を利用するためのＡＰＩである端末連携ＡＰＩを実行する。端末連携ＡＰＩ部４３７が端末連携ＡＰＩを実行することにより、ホームネットワークを介して接続される機器８や通信網９を介して接続される機器から受信機４内のリソースが利用可能となる。
【０１９９】
リソース制御部４３９は、受信機ＡＰＩ部４３６や端末連携ＡＰＩ部４３７から受信機４内のリソースである各機能部へのアクセスを制御する。
リソースアクセス制御部４３８は、受信機ＡＰＩ部４３６や端末連携ＡＰＩ部４３７から受信機４内の各機能部へのアクセスを許可するか否かを制御する。リソースアクセス制御部４３８は、この制御を、受信機ＡＰＩ部４３６や端末連携ＡＰＩ部４３７が実行する各ＡＰＩの呼び出し元であるアプリケーションがＡアプリケーションであるか一般アプリケーションであるかに従って行なう。
【０２００】
図２１は、提示制御部４１３の詳細な構成を示すブロック図である。同図に示すように、提示制御部４１３は、ポリシーデータ管理部４５１、ポリシーデータ記憶部４５２、イベント解釈部４５３、ポリシーレベル照合部４５４、イベント制御部４５５、番組ポリシー記憶部４５６、ポリシー調停部４５７及びポリシーレベル記憶部４５８を備える。
【０２０１】
ポリシーデータ記憶部４５２は、提示ルールデータ及びポリシーレベルテーブルを含むポリシーデータを記憶する。ポリシーデータ管理部４５１は、ポリシーデータ記憶部４５２に記憶されるポリシーデータを管理する。ポリシーデータ管理部４５１は、ポリシーデータ記憶部４５２から読み出したポリシーレベルテーブルをポリシーレベル照合部４５４に出力し、ポリシーデータ記憶部４５２から読み出した提示ルールデータをポリシー調停部４５７に出力する。また、ポリシーデータ管理部４５１は、放送により送信されたポリシーデータを分離部４０２あるいはデータ放送実行部４０６から受信し、通信により送信されたポリシーデータを通信入出力部４１１から受信する。ポリシーデータ管理部４５１は、ポリシーデータ記憶部４５２に記憶されているポリシーデータを、放送または通信により送信されたポリシーデータにより更新する。
【０２０２】
イベント解釈部４５３は、放送受信部４０１が受信した放送信号や、分離部４０２が分離したデータ放送や字幕データを解析し、イベントの発生または終了を検出する。イベント解釈部４５３は、イベントの発生または終了を検出（解釈）すると、その検出したイベントのイベント番号と、発生または終了を示すステータスデータとをポリシーレベル照合部４５４に出力する。
【０２０３】
ポリシーレベル照合部４５４は、ポリシーレベルテーブルを参照して、ＥＩＴにより示される各番組のジャンルに対応したポリシーレベルと、イベント番号により特定されるイベントに対応したポリシーレベルを決定（照合）する。ポリシーレベル照合部４５４は、分離部４０２から入力されたＳＩより取得した番組の放送開始時刻及び放送終了時刻のデータと、当該番組のポリシーレベル（以下、「番組ポリシーレベル」と記載する。）をイベント制御部４５５に出力する。なお、番組ポリシーレベルがＥＩＴに設定されている場合、ポリシーレベル照合部４５４は、番組の放送開始時刻及び放送終了時刻のデータと、ＥＩＴから取得した当該番組の番組ポリシーレベルをイベント制御部４５５に出力する。
また、ポリシーレベル照合部４５４は、ＡＩＴから番組ポリシーレベルを取得した場合、取得した番組ポリシーレベルをポリシー調停部４５７に出力する。また、ポリシーレベル照合部４５４は、イベント番号に対応して決定したポリシーレベル（以下、「トリガーポリシーレベル」と記載する。）をポリシー調停部４５７に出力する。
【０２０４】
番組ポリシー記憶部４５６は、番組開始時刻及び番組終了時刻と、番組ポリシーレベルを対応付けて記憶する。イベント制御部４５５は、ポリシーレベル照合部４５４から入力された番組開始時刻及び番組終了時刻のデータと、番組ポリシーレベルとを対応付けて番組ポリシー記憶部４５６に書き込み、番組ポリシー記憶部４５６に記憶されているこれらの情報を基に、表示制御を実行する時刻を管理する。イベント制御部４５５は、番組ポリシー記憶部４５６に記憶されている番組開始時刻のデータを参照し、実行時刻を通知すべき時刻となったことを検出した場合、実行時刻と、その実行時刻に対応した番組ポリシーレベルをポリシー調停部４５７に出力する。
【０２０５】
ポリシーレベル記憶部４５８は、ポリシー調停部４５７に入力された実行時刻及び番組ポリシーレベルと、トリガーポリシーレベル及びステータスデータを記憶する。ポリシー調停部４５７は、イベント制御部４５５から入力された実行時刻及び番組ポリシーレベルと、ポリシーレベル照合部４５４から入力されたトリガーポリシーレベルとからポリシーレベルを決定する。例えば、トリガーポリシーレベルをポリシーレベルとして決定してもよく、番組ポリシーレベルとトリガーポリシーレベルのうちより高いほうをポリシーレベルとして決定してもよい。
【０２０６】
なお、ポリシーレベル照合部４５４からＡＩＴにより取得した番組ポリシーレベルが入力された場合、ポリシー調停部４５７は、イベント制御部４５５から入力された番組ポリシーレベルよりも、ポリシーレベル照合部４５４から入力された番組ポリシーレベルを優先する。つまり、ポリシー調停部４５７は、ＡＩＴより得られた番組ポリシーレベルと、トリガーポリシーレベルとからポリシーレベルを決定する。ポリシー調停部４５７は、提示ルールデータを参照し、決定したポリシーレベルと、アプリケーション管理部４３３から取得した動作中のアプリケーションがＡアプリケーションであるか否かの情報や出力状況から、画面表示方法及び音声出力方法（提示方法）を決定する。ポリシー調停部４５７は、決定した画面表示方法を映像制御部４０７に出力し、決定した音声出力方法を音声制御部４０９に出力する。
【０２０７】
ここで、図１に戻り、操作受付部４７４と、起動要求信号取得部４７１と、アプリケーション情報取得部４７２と、起動制御部４７３と、終了制御部４８１とについて説明する。
また、接続制御部５０１と、端末アプリケーション取得部５０２と、端末アプリケーション実行部５０３とについても説明する。
【０２０８】
操作受付部４７４は、視聴者（操作者）による操作にしたがって操作信号を送信する操作機器である。操作受付部４７４は、例えば、受信機４を遠隔操作可能なリモートコントローラ（以下、リモコン）、受信機４の本体に配設された操作パネル等である。リモコンには、リモコン機能を実現するためのアプリケーションプログラムを実行中である携帯端末（携帯電話、スマートフォン、タブレット端末等）、コンピュータ装置、カーナビゲーション端末等が含まれる。
【０２０９】
操作受付部４７４は、受信機４を操作するための操作部を備える。なお、本実施形態において、操作受付部４７４の操作部は、例えば、電源ボタン、“０”から“９”までの数字ボタン（チャンネル指定ボタン）、チャンネル切替ボタン、音量調節ボタン、データ放送サービスボタン等、従来のテレビ操作リモコンに設けられているものと同様な操作ボタンである。データ放送サービスボタンは、受信機４がデータ放送を受信しているときに押されるたびに、データ放送の表示と非表示とを切り替える操作ボタンである。データ放送サービスボタンは、データ放送ボタン、ｄボタン、またはＤボタンとも呼ばれる。
【０２１０】
また、操作受付部４７４の操作部には、図１には図示しない放送通信連携サービスボタンが設けられている。この放送通信連携サービスボタンは、受信機４に放送通信連携サービスを受け始めさせるための操作ボタンである。放送通信連携サービスボタンは、放送通信連携ボタン、ｈボタン、またはＨボタンとも呼ばれる。操作受付部４７４は、放送通信連携サービスボタンが押されると、放送通信連携サービスにおけるストリーム従属型サービスの開始を要求するための起動要求信号を送信する。
【０２１１】
なお、操作受付部４７４の操作部は、例えば、タッチパネルとグラフィカル・ユーザ・インタフェース（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ；ＧＵＩ）とによって実現されるものであってもよい。
【０２１２】
操作入力部４１４は、操作受付部４７４が送信した操作信号を受信する。
操作入力部４１４の起動要求信号取得部４７１は、操作入力部４１４が受信した操作信号のうち起動要求信号を取り込んで起動要求コマンドを生成し、この起動要求コマンドをアプリケーション実行制御部４１２のアプリケーション制御部４３４に供給する。
また、操作入力部４１４は、放送サービス復帰ボタン、例えば、操作受付部４７４の操作部に設けられた数字ボタンまたはチャンネル切替ボタンが操作されたことによって送信された操作信号を受信した場合、終了要求コマンドを生成し、この終了要求コマンドをアプリケーション制御部４３４に供給する。
【０２１３】
アプリケーション制御部４３４のアプリケーション情報取得部４７２は、分離部４０２から定期的または不定期に供給されるＡＩＴ（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒａｍａｔｉｏｎ Ｔａｂｌｅ、アプリケーション情報テーブル）を取り込む。より詳細には、アプリケーション情報取得部４７２は、視聴者によって所望に選択されたメディアのうち、所望に選局されたチャンネルに対応するＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ；ＴＳ、放送ストリーム）から抽出された、ＡＩＴのＥＳ（Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）を、定期的または不定期に取り込む。
【０２１４】
ＡＩＴは、前述したとおり、アプリケーションに関する情報と、アプリケーションに対する制御情報と、アプリケーションを指定する情報とを含む情報である。図６に示したように、アプリケーションに関する情報には、アプリケーション名（appName）とアプリケーションＩＤ（orgId，appId）とが含まれる。アプリケーションに対する制御情報には、前記の表７に示したアプリケーション制御コード（application_control_code）が含まれる。このアプリケーション制御コードは、例えば、アプリケーションのライフサイクルを制御するためのデータである。アプリケーションを指定する情報には、ロケーション情報（location）が含まれる。このロケーション情報は、アプリケーションファイルの格納場所およびアプリケーションファイルを特定する情報である。ストリーム従属型サービスにおけるロケーション情報は、アプリケーションファイルを格納した受信機アプリサーバ２１またはリポジトリサーバ３（アプリケーションサーバ）のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）である。
【０２１５】
アプリケーション情報取得部４７２は、取り込んだＡＩＴからアプリケーション制御コードとアプリケーションＩＤとを抽出し、これらアプリケーション制御コードとアプリケーションＩＤとを終了制御部４８１に供給する。
なお、アプリケーション情報取得部４７２は、取り込んだＡＩＴからアプリケーションＩＤの代わりに、またはアプリケーションＩＤと共にアプリケーション名を抽出して終了制御部４８１に供給してもよい。
【０２１６】
また、アプリケーション情報取得部４７２は、起動要求信号取得部４７１から供給される起動要求コマンドを取り込むと、この起動要求コマンドの取り込みタイミングと同時またはこの取り込みタイミングの直後に取り込んだＡＩＴから、アプリケーション制御コードの他、アプリケーション名とロケーション情報とを抽出する。アプリケーション情報取得部４７２が抽出したアプリケーション名とアプリケーション制御コードとロケーション情報とを、アプリケーション情報と呼ぶ。アプリケーション情報取得部４７２は、抽出したアプリケーション情報を起動制御部４７３に供給する。
【０２１７】
また、アプリケーション情報取得部４７２は、分離部４０２から定期的または不定期に供給されるＰＳＩ（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ、プログラム特定情報）／ＳＩ（Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ、番組配列情報）を取り込む。より詳細には、アプリケーション情報取得部４７２は、上述した、所望に選択されたメディアのうち、所望に選局されたチャンネルに対応するＴＳから抽出されたＰＳＩ／ＳＩを、定期的または不定期に取り込む。
ＰＳＩ／ＳＩは、放送番組に関連するメタデータを含む情報である。メタデータは、前述したとおり、例えば、番組ＩＤ、番組概要、出演者、スタッフ、放送日時、台本、字幕、解説等の、放送番組に関連する情報である。
【０２１８】
本実施形態では、受信機４と機器８とを連携動作させる場合において機器８に実行させるアプリケーション（端末アプリケーションとも呼ぶ）を指定するアプリケーション指定情報が、ＰＳＩ／ＳＩに含まれている。アプリケーション指定情報は、端末アプリケーションを識別する識別情報であってもよいし、端末アプリケーションを格納する外部の端末アプリケーションサーバのＵＲＬであってもよい。
なお、アプリケーション指定情報はメタデータに含まれていてもよい。
放送送出装置１１の信号設定部１１２は、放送番組またはその内容もしくはその進行状況に対応付けて、アプリケーション指定情報をＴＳに多重化する。
【０２１９】
アプリケーション情報取得部４７２は、取り込んだＰＳＩ／ＳＩからアプリケーション指定情報とメタデータとを抽出し、これらアプリケーション指定情報とメタデータの全部または一部とをアプリケーション実行部４３５に供給する。
なお、アプリケーション指定情報およびメタデータまたはいずれかの情報は、特定の識別子に対応付けられて、独立的に設けられたＥＳに含められてもよい。この場合は、分離部４０２は、そのＥＳから、特定の識別子を手がかりとして、アプリケーション指定情報およびメタデータまたはいずれかの情報を抽出する。
【０２２０】
起動制御部４７３は、アプリケーション情報取得部４７２から供給されるアプリケーション情報、すなわち、アプリケーション名とアプリケーション制御コードとロケーション情報とを取り込む。起動制御部４７３は、アプリケーション制御コードがアプリケーションのスタンバイを示すデータであると識別した場合、アプリケーション情報に対応するアプリケーションの起動を制御する。
【０２２１】
具体的には、起動制御部４７３は、アプリケーション制御コードがアプリケーションのスタンバイを示すデータであると識別した場合、アプリケーション要求コマンドを生成し、このアプリケーション要求コマンドを通信入出力部４１１に供給する。つまり、起動制御部４７３は、アプリケーション要求部である。
アプリケーションのスタンバイを示すデータは、例えば、前記の表７に示したアプリケーション制御コードにおける“１２（１６進数）”（識別名：ＰＲＥＳＥＮＴ）である。
なお、アプリケーションのスタンバイを示すデータとしては、上記の“１２（１６進数）”（識別名：ＰＲＥＳＥＮＴ）以外にも、専用に割り当てられたコードとしてもよい。
アプリケーション要求コマンドは、ロケーション情報が示すロケーションをアプリケーションファイルの要求先とし、そのアプリケーションファイルの取得要求（ダウンロード要求）を示すコマンドである。
【０２２２】
なお、起動制御部４７３によるアプリケーションの起動の制御には、アプリケーション記憶部４３１に記憶されたアプリケーションファイルをアプリケーション実行部４３５に読み込ませて実行開始させることも含まれる。
【０２２３】
また、起動制御部４７３は、通信入出力部４１１から供給されるアプリケーションファイルの取得通知を取り込むと、アプリケーション実行要求コマンドを生成し、このアプリケーション実行要求コマンドをアプリケーション実行部４３５に供給する。
アプリケーション実行要求コマンドは、アプリケーションファイルの取得通知に対応するアプリケーションに対する実行開始要求を示すコマンドである。
【０２２４】
アプリケーション制御部４３４の終了制御部４８１は、操作入力部４１４から供給される終了要求コマンドを取り込むと、アプリケーション実行部４３５からアプリケーションの処理の状態（アプリケーション実行状態）を検出する。終了制御部４８１は、検出したアプリケーション実行状態が実行状態である場合、アプリケーション実行終了コマンドを生成し、このアプリケーション実行終了コマンドをアプリケーション実行部４３５に供給する。つまり、終了制御部４８１は、操作入力部４１４から供給される終了要求コマンドを取り込むと、取り込み中のＴＳに対応付けられ且つ実行中であるアプリケーションの実行終了を制御する。
【０２２５】
また、終了制御部４８１は、アプリケーション情報取得部４７２から供給されるアプリケーション制御コードとアプリケーションＩＤとを取り込む。終了制御部４８１は、取り込んだアプリケーション制御コードがアプリケーションの実行終了を指示するデータであると識別した場合、このアプリケーション制御コードに対応付けられたアプリケーションＩＤに対応するアプリケーションの実行終了を制御する。
【０２２６】
具体的には、終了制御部４８１は、アプリケーション制御コードがアプリケーションの実行終了を指示するデータであると識別した場合、このアプリケーション制御コードに対応付けられたアプリケーションＩＤを含むアプリケーション実行終了コマンドを生成し、このアプリケーション実行終了コマンドをアプリケーション実行部４３５に供給する。
アプリケーションの実行終了を指示するデータは、例えば、前記の表７に示したアプリケーション制御コードにおける“０３（１６進数）”（識別名：ＤＥＳＴＲＯＹ）である。
【０２２７】
なお、アプリケーションの実行終了を指示するデータとしては、上記の“０３（１６進数）”（識別名：ＤＥＳＴＲＯＹ）以外にも、“０４（１６進数）”（識別名：ＫＩＬＬ）、“０８（１６進数）”（識別名：ＫＩＬＬ ＡＬＬ）、その他専用に割り当てられたコードとしてもよい。
【０２２８】
前述したアプリケーション実行部４３５は、その機能構成として、図示しないコンテンツ要求部を備える。このコンテンツ要求部は、アプリケーションの実行処理において必要なコンテンツデータを、放送局サーバ群１２のコンテンツ配信サーバ１６またはサービス事業者サーバ群２のコンテンツ配信サーバ２３に対して要求するためのコンテンツ要求コマンドを生成し、このコンテンツ要求コマンドを通信入出力部４１１に供給する。
【０２２９】
アプリケーション実行部４３５は、前述したとおり、受信機４と機器８との連携機能を実現するための端末連携ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を有している。アプリケーション実行部４３５は、機器８との連携処理を実行するアプリケーション（連携アプリケーションとも呼ぶ）を実行する場合には、その連携アプリケーションに端末連携ＡＰＩを呼び出させて実行処理する。
【０２３０】
アプリケーション実行部４３５は、受信機４と機器８とを連携動作させた後、アプリケーション情報取得部４７２から供給されるアプリケーション指定情報とメタデータとを取り込む。受信機４と機器８とを連携動作させるとは、受信機４と機器８との通信路を確立させて、受信機４と機器８とが協働して放送通信連携サービスの受給状態を実現することである。受信機４と機器８との通信は、サーバを経由しない直接通信であってもよいし、サーバを経由するネットワーク通信であってもよい。
直接通信を実現するためのプロトコルとして、例えば、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ
Ｐｌｕｇ ａｎｄ Ｐｌａｙ）を適用する。また、ネットワーク通信を実現するためのプロトコルとして、例えば、ＸＭＰＰ（ｅＸｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｐｒｏｔｏｃｏｌ）を適用する。
【０２３１】
アプリケーション実行部４３５は、連携動作中である機器８を指定する情報と、その機器８に実行させる端末アプリケーションを指定する情報（アプリケーション指定情報）と、メタデータとに基づいて、その機器８に対して端末アプリケーションを指定し起動制御を行う。機器８を指定する情報は、アプリケーション実行部４３５が、受信機４と機器８との連携を確立させたときに機器８から取得する情報である。
なお、受信機４に連携動作させる機器８があらかじめ特定されている場合は、機器８を指定する情報を省略してもよい。
【０２３２】
アプリケーション実行部４３５は、機器８を指定する情報と、アプリケーション指定情報と、メタデータとに基づいて、機器８に対して端末アプリケーションを指定し起動させるためのInvokeApplicationOnDevice()メソッドを、端末連携ＡＰＩに設けている。InvokeApplicationOnDevice()メソッドは、例えば、下記のフォーマットを有する。
【０２３３】
メソッド名： InvokeApplicationOnDevice（）
機能： 機器８に対して端末アプリケーションを指定し起動させる。
引数： device_dev，application_id，strings_parameters
【０２３４】
上記のInvokeApplicationOnDevice（）メソッドにおいて、device_devは連携動作中である機器８を指定する情報（デバイスＩＤ）、application_idは端末アプリケーションを指定する情報（アプリケーション指定情報、アプリケーションＩＤ）、strings_parametersはメタデータである。
つまり、機器８と受信機４とが連携動作を開始した後、アプリケーション実行部４３５がInvokeApplicationOnDevice()メソッドを実行すると、アプリケーション実行部４３５は、device_devに対応する機器８に対して、application_idに対応する端末アプリケーションを起動させるための起動コマンドを、外部Ｉ／Ｆ４１７を介して機器８に送信する。
このとき、この起動コマンドには、stringus_parametersが引数として含められる。
【０２３５】
なお、アプリケーション実行部４３５は、InvokeApplicationOnDevice（）メソッドにおける引数のうち、stringus_parametersを省略して実行処理してもよい。本実施形態では、引数にstringus_parametersを含む場合について説明する。
【０２３６】
また、前述した通信入出力部４１１は、その機能構成として、図示しないアプリケーション取得部と、コンテンツ取得部とを備える。
アプリケーション取得部は、通信入出力部４１１が送信したアプリケーション要求信号を受信した外部のサーバ、例えば、受信機アプリサーバ２１またはリポジトリサーバ３から送信されたアプリケーションファイルを取り込み、このアプリケーションファイルをアプリケーション記憶部４３１に記憶させる。
コンテンツ取得部は、通信入出力部４１１が送信したコンテンツ要求信号を受信した外部のサーバ、例えば、コンテンツ配信サーバ１６またはコンテンツ配信サーバ２３から送信されたコンテンツデータを取り込み、このコンテンツデータを第２同期用バッファ４０４−２に供給する。
【０２３７】
機器８の接続制御部５０１は、受信機４の外部Ｉ／Ｆ部４１７との間で通信を行うための通信インタフェースである。機器８と受信機４とが連携動作を開始した後、アプリケーション実行部４３５がInvokeApplicationOnDevice()メソッドを実行すると、接続制御部５０１は、外部Ｉ／Ｆ部４１７から供給される、strings_parametersを引数とした起動コマンドを取り込み、この起動コマンドを端末アプリケーション取得部５０２に供給する。
【０２３８】
端末アプリケーション取得部５０２は、接続制御部５０１から供給される起動コマンドを取り込み、この起動コマンドに基づいて端末アプリケーションを取得し、この取得した端末アプリケーションを、strings_parametersとともに端末アプリケーション実行部５０３に供給する。
【０２３９】
具体的には、端末アプリケーション取得部５０２は、図示しない端末アプリケーション記憶部を備えている。端末アプリケーション取得部５０２は、起動コマンドが示すdevice_devが当該機器８に該当するか否かを判定する。device_devが当該機器８に該当する場合、端末アプリケーション取得部５０２は、起動コマンドが示すapplication_idに対応する端末アプリケーションが端末アプリケーション記憶部に記憶されているか否かを判定する。application_idに対応する端末アプリケーションが端末アプリケーション記憶部に記憶されている場合、端末アプリケーション取得部５０２は、その端末アプリケーションを端末アプリケーション記憶部から読み出してstrings_parametersとともに端末アプリケーション実行部５０３に供給する。
device_devが当該機器８に該当しない場合、端末アプリケーション取得部５０２は、接続制御部５０１を介して受信機４にエラー情報を送信してもよい。
【０２４０】
また、application_idに対応する端末アプリケーションが端末アプリケーション記憶部に記憶されていない場合、端末アプリケーション取得部５０２は、その端末アプリケーションの取得要求を示す端末アプリケーション要求信号を生成し、この端末アプリケーション要求信号を、端末アプリケーションサーバに対して供給する。そして、端末アプリケーション取得部５０２は、端末アプリケーション要求信号に応じて端末アプリケーションサーバから供給された端末アプリケーションを取り込み、この端末アプリケーションをstrings_parametersとともに端末アプリケーション実行部５０３に供給する。
なお、端末アプリケーション取得部５０２は、その取り込んだ端末アプリケーションを、端末アプリケーション記憶部に記憶させてもよい。
【０２４１】
端末アプリケーションは、例えば、受信機４を遠隔操作するリモコン機能を実現するためのリモコンアプリケーション、クイズ番組やバラエティ番組等において視聴者から放送局またはサービス事業者に視聴者回答を送信するための回答（投票）アプリケーション、ウェブログ、チャット、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）等のクライアント機能を実現するためのアプリケーション等である。
【０２４２】
端末アプリケーション実行部５０３は、端末アプリケーション取得部５０２から供給される端末アプリケーションとstrings_parametersとを取り込み、このstrings_parametersを用いて端末アプリケーションを実行処理する。
例えば、strings_parametersが放送番組のキャストやスタッフに関する情報である場合、端末アプリケーション実行部５０３は、その放送番組のキャストやスタッフに関する情報、つまり放送リソースを利用して端末アプリケーションを実行処理する。
【０２４３】
図２２は、操作受付部４７４として赤外線リモコンを用いた場合の、概略の外観正面図である。同図に示すように、操作受付部４７４には、電源ボタン、数字ボタン、チャンネル切替ボタン、音量調節ボタン、データ放送サービスボタン等、従来のテレビ操作リモコンに設けられているものと同様なボタンの他、放送通信連携サービスボタン４７５が設けられている。
【０２４４】
次に、操作受付部４７４の放送通信連携サービスボタン４７５が押された場合において、受信機４がＡＩＴを取得し、このＡＩＴに基づいて外部のサーバからアプリケーションファイルを取得してアプリケーションを実行し、このアプリケーションの実行処理に伴い、関連するコンテンツを外部のサーバから取得して提示する処理について説明する。
【０２４５】
図２３は、受信機４と、受信機アプリサーバ２１と、コンテンツ配信サーバ２３との処理の手順を示すシーケンス図である。
ステップＳ１において、受信機４は、操作受付部４７４から送信される起動要求信号を受信すると、視聴者の所望によって選択されたメディアのうち、選局されたチャンネルに対応するＴＳから、ＡＩＴのＥＳを抽出する。
次に、ステップＳ２において、受信機４は、ＡＩＴに含まれるアプリケーション制御コードがアプリケーションのスタンバイを示すデータであると識別した場合、アプリケーション要求信号を受信機アプリサーバ２１に対して送信する。
次に、ステップＳ３において、受信機アプリサーバ２１は、受信機４が送信したアプリケーション要求信号を受信して取り込むと、このアプリケーション要求信号が指定するアプリケーションファイルを読み出す。
次に、ステップＳ４において、受信機アプリサーバ２１は、アプリケーション要求信号を送信した受信機４に対して、アプリケーションファイルを送信する。
【０２４６】
次に、ステップＳ５において、受信機４は、受信機アプリサーバ２１が送信したアプリケーションファイルを受信して取り込み、アプリケーションの実行処理を開始する。
次に、ステップＳ６において、受信機４は、アプリケーションの実行処理に伴って必要となるコンテンツデータを取得するためのコンテンツ要求信号をコンテンツ配信サーバ２３に対して送信する。
次に、ステップＳ７において、コンテンツ配信サーバ２３は、受信機４が送信したコンテンツ要求信号を受信して取り込むと、このコンテンツ要求信号が指定するコンテンツデータを読み出す。
次に、ステップＳ８において、コンテンツ配信サーバ２３は、コンテンツ要求信号を送信した受信機４に対して、コンテンツデータを送信する。
次に、ステップＳ９において、受信機４は、コンテンツ配信サーバ２３が送信したコンテンツデータを受信して取り込み、コンテンツをデコード処理して表示したり音声出力したりする。
【０２４７】
なお、図２３において、受信機アプリサーバ２１の代わりにリポジトリサーバ３を設けた場合、および、コンテンツ配信サーバ２３の代わりにコンテンツ配信サーバ１６を設けた場合も同様な処理となる。
【０２４８】
次に、操作受付部４７４から送信された操作信号を受信する受信機４の動作について、詳細に説明する。
図２４および図２５は、受信機４が操作受付部４７４の操作にしたがって作動する場合の、動作の処理手順を示すフローチャートである。
受信機４が放送信号を取り込み、視聴者によって選択されたメディアと選局されたチャンネルとに対応するＴＳから放送コンテンツを抽出して提示している状態、つまり、所望の番組を表示および音声出力している状態において、受信機４は、本フローチャートによる処理を実行開始する。
【０２４９】
まず、ステップＳ１１において、操作入力部４１４は、操作受付部４７４が送信する操作信号の受信を受け付けている。操作入力部４１４は、操作受付部４７４が送信した操作信号を受信すると、この操作信号を取り込んでステップＳ１２の処理に移す。
ステップＳ１２において、操作入力部４１４は、受信した操作信号が起動要求信号である場合（Ｓ１２：ＹＥＳ）はステップＳ１３の処理に移し、受信した操作信号が起動要求信号でない場合（Ｓ１２：ＮＯ）は、図２５のステップＳ２１の処理に移す。
【０２５０】
ステップＳ１３において、起動要求信号取得部４７１は、起動要求信号を取り込んで起動要求コマンドを生成し、この起動要求コマンドをアプリケーション実行制御部４１２のアプリケーション制御部４３４に供給する。
次に、アプリケーション制御部４３４のアプリケーション情報取得部４７２は、起動要求信号取得部４７１から供給される起動要求コマンドを取り込む。
次に、アプリケーション情報取得部４７２は、分離部４０２から供給されるＡＩＴを取り込む。このＡＩＴは、視聴者によって所望に選択されたメディアのうち、所望に選局されたチャンネルに対応するＴＳから抽出された情報である。
【０２５１】
ステップＳ１４において、アプリケーション情報取得部４７２は、取り込んだＡＩＴから、アプリケーション名とアプリケーション制御コードとロケーション情報とをアプリケーション情報として抽出し、このアプリケーション情報を起動制御部４７３に供給する。
次に、起動制御部４７３は、アプリケーション情報取得部４７２から供給されるアプリケーション情報、すなわち、アプリケーション名とアプリケーション制御コードとロケーション情報とを取り込む。
【０２５２】
次に、ステップＳ１５において、起動制御部４７３は、アプリケーション制御コードがアプリケーションのスタンバイを示すデータであると識別した場合（Ｓ１５：ＹＥＳ）、ステップＳ１６の処理に移し、アプリケーション制御コードがアプリケーションのスタンバイを示すデータでないと識別した場合（Ｓ１５：ＮＯ）、本フローチャートの処理を終了させる。
具体的には、起動制御部４７３は、アプリケーション制御コードが例えば“１２（１６進数）”（識別名：ＰＲＥＳＥＮＴ）であると識別した場合、ステップＳ１６の処理に移し、アプリケーション制御コードが“１２（１６進数）”（識別名：ＰＲＥＳＥＮＴ）でないと識別した場合、本フローチャートの処理を終了させる。
【０２５３】
ステップＳ１６において、起動制御部４７３は、ロケーション情報に示されるロケーションをアプリケーションファイルの要求先として指定したアプリケーション要求コマンドを生成し、このアプリケーション要求コマンドを通信入出力部４１１に供給する。
次に、通信入出力部４１１は、起動制御部４７３から供給されるアプリケーション要求コマンドを取り込み、このアプリケーション要求コマンドをアプリケーション要求信号として要求先に対して送信する。このアプリケーション要求信号は、例えば、アプリケーション要求コマンドをＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケット化した信号である。
すなわち、通信入出力部４１１は、アプリケーション要求コマンドが示す要求先である受信機アプリサーバ２１またはリポジトリサーバ３に対して、アプリケーション要求信号を送信する。
【０２５４】
次に、ステップＳ１７において、通信入出力部４１１は、上記の要求先（受信機アプリサーバ２１またはリポジトリサーバ３）が送信するアプリケーションファイルの受信を受け付けている。通信入出力部４１１は、上記の要求先が送信したアプリケーションファイルを受信すると、このアプリケーションファイルを取り込んでステップＳ１８の処理に移す。
【０２５５】
ステップＳ１８において、通信入出力部４１１は、取り込んだアプリケーションファイルをアプリケーション実行制御部４１２のアプリケーション記憶部４３１に供給し記憶させる。
【０２５６】
次に、ステップＳ１９において、通信入出力部４１１は、アプリケーションファイルの取得通知を起動制御部４７３に供給する。
次に、起動制御部４７３は、通信入出力部４１１から供給されるアプリケーションファイルの取得通知を取り込む。
次に、起動制御部４７３は、アプリケーションファイルの取得通知に対応するアプリケーションに対するアプリケーション実行要求コマンドを生成し、このアプリケーション実行要求コマンドをアプリケーション実行部４３５に供給する。
次に、アプリケーション実行部４３５は、起動制御部４７３から供給されるアプリケーション実行要求コマンドを取り込む。
次に、アプリケーション実行部４３５は、取り込んだアプリケーション実行要求コマンドにより指定されるアプリケーションファイルをアプリケーション記憶部４３１から読み込み、アプリケーションの実行処理を開始し、本フローチャートの処理を終了させる。
【０２５７】
一方、図２５のステップＳ２１において、操作入力部４１４は、操作信号が、操作受付部４７４の操作部に設けられた放送サービス復帰ボタン（例えば、数字ボタンまたはチャンネル切替ボタン）が操作されたことによって送信された操作信号である場合（Ｓ２１：ＹＥＳ）、ステップＳ２２の処理に移し、それ以外はステップＳ２５の処理に移す。
【０２５８】
ステップＳ２２において、操作入力部４１４は、終了要求コマンドを生成し、この終了要求コマンドをアプリケーション制御部４３４に供給する。
次に、アプリケーション制御部４３４の終了制御部４８１は、操作入力部４１４から供給される終了要求コマンドを取り込み、アプリケーション実行部４３５からアプリケーション実行状態を検出する。
【０２５９】
次に、ステップＳ２３において、終了制御部４８１は、検出したアプリケーション実行状態が実行状態である場合（Ｓ２３：ＹＥＳ）、ステップＳ２４の処理に移し、アプリケーション実行状態が実行状態でない場合（Ｓ２３：ＮＯ）、本フローチャートの処理を終了させる。
【０２６０】
ステップＳ２４において、終了制御部４８１は、アプリケーション実行終了コマンドを生成し、このアプリケーション実行終了コマンドをアプリケーション実行部４３５に供給する。
次に、アプリケーション実行部４３５は、終了制御部４８１から供給されるアプリケーション実行終了コマンドを取り込むと、現在実行中であるアプリケーションの実行処理を終了させて、本フローチャートの処理を終了させる。
【０２６１】
一方、ステップＳ２５において、操作入力部４１４は、起動要求信号以外の操作信号にしたがって、メディアやチャンネルを指定するコードを選局部４１５に供給したり、音量を設定するコードを図示しない音量調節回路に供給したりする。
受信機４は、起動要求信号以外の操作信号にしたがった動作を開始して、本フローチャートの処理を終了する。
【０２６２】
次に、放送通信連携サービスの提供者側からの制御に基づいてアプリケーションを実行終了させる受信機４の動作について説明する。
図２６は、受信機４の動作の処理手順を示すフローチャートである。
まず、ステップＳ３１において、アプリケーション情報取得部４７２は、分離部４０２から供給されるＡＩＴを取り込む。
【０２６３】
ステップＳ３２において、アプリケーション情報取得部４７２は、取り込んだＡＩＴからアプリケーション制御コードとアプリケーションＩＤとを抽出し、これらアプリケーション制御コードとアプリケーションＩＤとを終了制御部４８１に供給する。
次に、終了制御部４８１は、アプリケーション情報取得部４７２から供給されるアプリケーション制御コードとアプリケーションＩＤとを取り込む。
【０２６４】
次に、ステップＳ３３において、終了制御部４８１は、アプリケーション制御コードがアプリケーションの実行終了を指示するデータであると識別した場合（Ｓ３３：ＹＥＳ）、ステップＳ３４の処理に移し、アプリケーション制御コードがアプリケーションの実行終了を指示するデータでないと識別した場合（Ｓ３３：ＮＯ）、ステップＳ３１の処理に戻す。
具体的には、終了制御部４８１は、アプリケーション制御コードが例えば“０３（１６進数）”（識別名：ＤＥＳＴＲＯＹ）であると識別した場合、ステップＳ３４の処理に移し、アプリケーション制御コードが“０３（１６進数）”（識別名：ＤＥＳＴＲＯＹ）でないと識別した場合、ステップＳ３１の処理に戻す。
【０２６５】
ステップＳ３４において、終了制御部４８１は、アプリケーション制御コードに対応付けられたアプリケーションＩＤを含むアプリケーション実行終了コマンドを生成し、このアプリケーション実行終了コマンドをアプリケーション実行部４３５に供給する。
次に、アプリケーション実行部４３５は、終了制御部４８１から供給されるアプリケーション実行終了コマンドを取り込む。
次に、アプリケーション実行部４３５は、終了制御部４８１から供給されるアプリケーション実行終了コマンドを取り込むと、現在実行中であるアプリケーションの実行処理を終了させ、本フローチャートの処理を終了させる。
【０２６６】
次に、受信機４と連携動作させる機器８に実行させる端末アプリケーションを動的に変更する受信システムの動作について説明する。
図２７は、受信機４と、機器８と、端末アプリケーションサーバとの処理の手順を示すシーケンス図である。
まず、ステップＳ４１において、受信機４と機器８とが連携を確立させる。
具体的には、受信機４のアプリケーション実行部４３５は、機器８との連携処理を実行する連携アプリケーションに端末連携ＡＰＩを呼び出させて実行処理する。アプリケーション実行部４３５が端末連携ＡＰＩを実行することにより、受信機４と機器８とが連携を確立させる。
【０２６７】
次に、ステップＳ４２において、受信機４は、受信中のＴＳからアプリケーション指定情報とメタデータとを取得する。具体的には、アプリケーション情報取得部４７２は、視聴者によって所望に選択されたメディアのうち、所望に選局されたチャンネルに対応するＴＳから抽出されたＰＳＩ／ＳＩを取り込り、このＰＳＩ／ＳＩからアプリケーション指定情報とメタデータとを取り込む。
【０２６８】
次に、ステップＳ４３において、受信機４は、連携動作中である機器８を指定する情報と、ステップＳ４２の処理において取り込んだアプリケーション指定情報およびメタデータとに基づいて、その機器８に対してその端末アプリケーションを指定し起動制御を行う。
具体的には、アプリケーション実行部４３５は、携帯連携ＡＰＩのInvokeApplicationOnDevice()メソッドを実行し、device_devに対応する機器８に対して、application_idに対応する端末アプリケーションを起動させるための起動コマンド（stringus_parametersを含む）を、外部Ｉ／Ｆ４１７を介して機器８に送信する。
【０２６９】
次に、ステップＳ４４において、機器８は、受信機４からの端末アプリケーションの起動制御を受け、指定された端末アプリケーションについての端末アプリケーション要求信号を生成し、この端末アプリケーション要求信号を端末アプリケーションサーバに対して送信する。
【０２７０】
具体的には、接続制御部５０１は、外部Ｉ／Ｆ部４１７から供給される、strings_parametersを引数とした起動コマンドを取り込み、この起動コマンドを端末アプリケーション取得部５０２に供給する。
次に、端末アプリケーション取得部５０２は、接続制御部５０１から供給される起動コマンドを取り込む。
次に、端末アプリケーション取得部５０２は、この起動コマンドに基づいて端末アプリケーションを取得し、この端末アプリケーションをstrings_parametersとともに端末アプリケーション実行部５０３に供給する。
【０２７１】
より具体的には、端末アプリケーション取得部５０２は、起動コマンドが示すdevice_devが当該機器８に対応するか否かを判定する。device_devが当該機器８に対応する場合、端末アプリケーション取得部５０２は、起動コマンドが示すapplication_idに対応する端末アプリケーションが端末アプリケーション記憶部に記憶されているか否かを判定する。
ただし、図２７は、application_idに対応する端末アプリケーションが端末アプリケーション記憶部に記憶されていない場合の例である。
application_idに対応する端末アプリケーションが端末アプリケーション記憶部に記憶されていない場合、端末アプリケーション取得部５０２は、その端末アプリケーションの取得要求を示す端末アプリケーション要求信号を生成し、この端末アプリケーション要求信号を端末アプリケーションサーバに対して送信する。
【０２７２】
次に、ステップＳ４５において、端末アプリケーションサーバは、機器８が送信した端末アプリケーション要求信号を受信して取り込むと、この端末アプリケーション要求信号が指定する端末アプリケーションのファイルを読み出す。
次に、ステップＳ４６において、端末アプリケーションサーバは、端末アプリケーション要求信号を送信した機器８に対して、端末アプリケーションのファイルを送信する。
【０２７３】
次に、ステップＳ４７において、機器８は、端末アプリケーションサーバが送信した端末アプリケーションのファイルを受信して取り込む。
具体的には、端末アプリケーション取得部５０２は、端末アプリケーション要求信号に応じて端末アプリケーションサーバから供給された端末アプリケーションを取り込み、この端末アプリケーションをstrings_parametersとともに端末アプリケーション実行部５０３に供給する。
【０２７４】
次に、ステップＳ４８において、機器８は、取り込んだ端末アプリケーションのファイルにおける端末アプリケーションの実行処理を開始する。
具体的には、端末アプリケーション実行部５０３は、端末アプリケーション取得部５０２から供給される端末アプリケーションとstrings_parametersとを取り込み、このstrings_parametersを用いて端末アプリケーションの実行処理を開始させる。
次に、ステップＳ４９において、受信機４は連携アプリケーションの実行処理を行うとともに、機器８は端末アプリケーションの実行処理を行う。これにより、受信機４と機器８とは、放送リソースを用いた連携動作を実現する。
【０２７５】
以上説明したように、本発明の一実施形態である受信機４は、視聴者による操作にしたがって操作受付部４７４が送信する操作信号を受信する。操作受付部４７４には、受信機４に放送通信連携サービスを受け始めさせる放送通信連携サービスボタン４７５が設けられている。放送通信連携サービスボタン４７５が押されることによって、操作受付部４７４は、起動要求信号を送信する。
受信機４は、起動要求信号を取り込むと、所望のメディアにおける所望のチャンネルに対応するＴＳからＡＩＴを取得し、このＡＩＴからアプリケーション情報（アプリケーション名、アプリケーション制御コード、およびロケーション情報）を抽出する。
受信機４は、アプリケーション制御コードが、アプリケーションのスタンバイを示すデータである場合に、アプリケーション要求信号を、アプリケーションファイルの要求先である受信機アプリサーバ２１またはリポジトリサーバ３に対して送信する。
受信機４は、アプリケーションの要求先からアプリケーションファイルの供給を受けると、このアプリケーションファイルを取り込み、アプリケーションを実行開始する。
受信機４は、アプリケーションの実行処理に伴って必要となるコンテンツデータを取得するために、コンテンツ要求信号をコンテンツ配信サーバ１６またはコンテンツ配信サーバ２３に対して供給する。
受信機４は、コンテンツデータの要求先からコンテンツデータの供給を受けると、このコンテンツデータを取り込んで提示する。
【０２７６】
この構成によれば、受信機４は、視聴者（操作者）による操作受付部４７４に設けられた放送通信連携サービスボタン４７５の操作にしたがって、放送サービスを受けている状態から、放送通信連携サービスの一サービス形態であるストリーム従属型サービスを受ける状態に切り替えることができる。
よって、受信機４によれば、放送サービスから放送通信連携サービスに、簡便な操作により切り替えることができる。
【０２７７】
また、受信機４は、操作受付部４７４から供給された操作信号が、操作受付部４７４の操作部に設けられた放送サービス復帰ボタン（例えば、数字ボタンまたはチャンネル切替ボタン）が操作されたことによって送信された操作信号である場合、アプリケーションの実行状態を調べる。
現時点でアプリケーションが実行状態である場合、受信機４は、この実行中であるアプリケーションの実行処理を終了させる。
【０２７８】
この構成によれば、受信機４は、視聴者（操作者）による操作受付部４７４に設けられた数字ボタンおよびチャンネル切替ボタンの操作にしたがって、放送通信連携サービスの一サービス形態であるストリーム従属型サービスを受けている状態から、放送サービスを受ける状態に切り替えることができる。
よって、受信機４によれば、放送通信連携サービスから放送サービスに、簡便な操作により切り替えることができる。
【０２７９】
また、受信機４は、ＴＳから得られるＡＩＴに含まれるアプリケーション制御コードがアプリケーションの実行終了を指示するデータであることを識別した場合、このアプリケーション制御コードに対応付けられたアプリケーションＩＤが示すアプリケーションの実行処理を終了させる。
【０２８０】
この構成によれば、放送通信連携サービスの供給者側からの制御によって、受信機４は、現在受けている放送通信連携サービスを放送サービスに切り替えることができる。
よって、受信機４によれば、放送通信連携サービスの供給者側からの制御によって、受信者側が受けている放送通信連携サービスを放送サービスに切り替えることができる。
【０２８１】
また、この構成によれば、受信機４は、時装置が実行するアプリケーションと、このアプリケーションに関連するコンテンツデータとを、自装置の要求にしたがって外部の供給元から取得することができる。
【０２８２】
また、本実施形態である受信システムでは、受信機４が機器８との連携処理を実行する連携アプリケーションを実行する場合には、その連携アプリケーションに端末連携ＡＰＩを呼び出させて実行処理する。
受信機４は、機器８との連携を確立させた後、受信中のＴＳからアプリケーション指定情報とメタデータとを取得する。
受信機４は、連携動作中である機器８を指定する情報と、その機器８に実行させる端末アプリケーションを指定するアプリケーション指定情報と、メタデータとに基づいて、その機器８に対してその端末アプリケーションを指定し起動制御を行う。
機器８は、受信機４の起動制御を受けると、機器８が実行するように指定された端末アプリケーションを内部の端末アプリケーション記憶部または外部の端末アプリケーションサーバから取得する。
機器８は、受信機４から取得したメタデータを用いて、取得した端末アプリケーションを実行処理する。
【０２８３】
この構成によれば、受信機４と連携動作する機器８に実行させるアプリケーションを、放送ストリームから得られるアプリケーション指定情報に基づき動的に変更することができる。
よって、受信機４と連携動作する機器８は、放送番組またはその内容もしくはその進行状況等に応じて、端末アプリケーションを変えて実行することができる。
【０２８４】
なお、受信機４の起動制御部４７３は、操作受付部４７４の操作に関わらず、取得するＡＩＴに含まれるアプリケーション制御コードが、アプリケーションの自動起動を指示するデータであると識別した場合に、アプリケーション要求信号を受信機アプリサーバ２１に対して送信するものである。
【０２８５】
また、本実施形態は、受信機４が放送サービスを受けている状態において、操作受付部４７４に設けられた放送通信連携サービスボタン４７５が押された場合に、放送サービスのみを受ける状態から放送通信連携サービスを受ける状態に移行する例であった。これ以外にも、例えば、受信機４がいずれのサービスも受けていない状態、例えばスタンバイ状態であるときに、放送通信連携サービスボタン４７５が押された場合、受信機４が、その状態から一旦、放送サービスを受ける状態となった後に、放送通信連携サービスを受ける状態に移行するようにしてもよい。
【０２８６】
また、本実施形態は、アプリケーション情報取得部４７２が、放送信号から得られたＴＳに多重化されたＡＩＴのＥＳを取得する例であった。
これ以外にも、放送送出装置１１が、ＡＩＴの情報を含む記述子が設けられたＥＩＴ（Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ、イベント情報テーブル）を多重化したＴＳを放送信号として送信し、放送信号を取り込んだ受信機４において、分離部４０２がＴＳに多重化されたＥＩＴからＡＩＴを抽出し、アプリケーション情報取得部４７２がそのＡＩＴを取得するようにしてもよい。
【０２８７】
図２８は、ＥＩＴのデータ構造を示す図である。
なお、ＥＩＴのデータ構造についての詳細事項は、例えば、「地上デジタルテレビジョン放送運用規定 技術資料」、ＡＲＩＢ ＴＲ−Ｂ１４、４．４版、第二分冊、社団法人電波産業会、平成２３年３月（第四編第３部３１．３）に記載されている。
放送送出装置１１の信号設定部１１２は、例えば、同図に示すデータ構造を有するＥＩＴの記述子（descriptor()）にＡＩＴの情報を格納する。そして、信号設定部１１２は、ＡＩＴが格納されたＥＩＴを多重化したＴＳを生成し、このＴＳを放送送出部１１３に供給する。
【０２８８】
または、放送送出装置１１が、ＢＭＬ（Ｂｒｏａｄｃａｓｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）により記述されたＡＩＴを、ＤＳＭ−ＣＣ（Ｄｉｇｉｔａｌ Ｓｔｏｒａｇｅ
Ｍｅｄｉａ−Ｃｏｍｍａｎｄ ａｎｄ Ｃｏｎｔｒｏｌ）データカルーセル伝送方式によるデータ放送によって送信し、放送信号を取り込んだ受信機４において、分離部４０２がデータ放送コンテンツからＡＩＴを抽出し、アプリケーション情報取得部４７２がそのＡＩＴを取得するようにしてもよい。
【０２８９】
ＤＳＭ−ＣＣデータカルーセル伝送方式についての詳細事項は、例えば、「デジタル放送におけるデータ放送符号化方式と伝送方式 標準規格」、ＡＲＩＢ ＳＴＤ−Ｂ２４、５．１版、第三分冊、社団法人電波産業会、平成１９年３月（第三編第６章）に記載されている。
前述したとおり、信号設定部１１２は、ＡＩＴをカルーセル伝送するためのコンポーネントタグとモジュールとを固定とする。信号設定部１１２は、コンポーネントタグを例えば“ＡＡ”（１６進数）に、モジュールの識別情報であるモジュールＩＤを例えば“０”に固定する。そして、信号設定部１１２は、ＡＩＴであることを識別させるためのタイプを、モジュールのＴｙｐｅ記述子に設定する。
一方、分離部４０２は、ＴＳにおける、モジュールを監視し、モジュールＩＤが“０”であるモジュールを検出したときに、この検出したモジュールから、Ｔｙｐｅ識別子に対応するＡＩＴを抽出する。
【０２９０】
または、放送局サーバ群１２における通知サーバ１８またはサービス事業者サーバ群２における通知サーバ２４に、放送コンテンツの識別情報と対応付けたＡＩＴ、または放送コンテンツの識別情報を含むＡＩＴを格納しておき、放送信号を取り込んだ受信機４において、アプリケーション制御部４３４が分離部４０２からコンテンツの識別情報を取得して、通信入出力部４１１を介して通知サーバ１８または通知サーバ２４からＡＩＴを取得するようにしてもよい。
【０２９１】
また、放送通信連携サービスの供給者側からの制御によって、受信者側が受けている放送サービスを放送通信連携サービスに切り替える機能を実現するために、以下のような構成を有してもよい。
すなわち、アプリケーション情報取得部４７２は、取り込んだＡＩＴからアプリケーション制御コードと所定のフラグとを抽出し、これらアプリケーション制御コードとフラグとを起動制御部４７３に供給する。所定のフラグは、例えば、ＡＩＴに設けられた、アプリケーション起動とデータ放送提示とのいずれかを指定するデータである。
起動制御部４７３は、アプリケーション情報取得部４７２から供給されるアプリケーション制御コードとフラグとを取り込む。
起動制御部４７３は、アプリケーション制御コードがアプリケーションの自動起動を指示するデータであると識別した場合、フラグに応じて、アプリケーションの実行開始またはデータ放送の提示のいずれかを制御する。
アプリケーションの自動起動を指示するデータは、例えば、前記の表７に示したアプリケーション制御コードにおける“０１（１６進数）”（識別名：ＡＵＴＯＳＴＡＲＴ）である。
【０２９２】
また、本実施形態である受信機４の一部の機能をコンピュータで実現するようにしてもよい。この場合、その機能を実現するためのコンピュータプログラムをコンピュータ読み取り可能な記録媒体に記録し、この記録媒体に記録されたコンピュータプログラムをコンピュータシステムに読み込ませて、このコンピュータシステムが実行することによって実現してもよい。なお、ここでいうコンピュータシステムとは、オペレーティング・システム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ；ＯＳ）や周辺装置のハードウェアを含むものである。また、コンピュータ読み取り可能な記録媒体とは、フレキシブルディスク、光磁気ディスク、光ディスク、メモリカード等の可搬型記録媒体、コンピュータシステムに内蔵される磁気ハードディスクやソリッドステートドライブ等の記憶装置のことをいう。さらに、コンピュータ読み取り可能な記録媒体とは、インターネット等のコンピュータネットワークや、電話回線や携帯電話網を介してプログラムを送信する場合の通信回線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバ装置やクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持するものを含んでもよい。また上記のプログラムは、前述した機能の一部を実現するためのものであってもよく、さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせにより実現するものであってもよい。
【０２９３】
以上、本発明の実施の形態について図面を参照して詳述したが、具体的な構成はその実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計等も含まれる。
【符号の説明】
【０２９４】
１…放送事業者装置
１１…放送送出装置
１１１…放送関連データ管理部
１１２…信号設定部
１１３…放送送出部
１２…放送局サーバ群
１３…コンテンツ管理サーバ
１４…番組管理サーバ
１５…メタデータ管理サーバ
１６…コンテンツ配信サーバ
１７…放送局サービスサーバ
１８…通知サーバ
２…サービス事業者サーバ群
２１…受信機アプリサーバ
２２…サービスサーバ
２３…コンテンツ配信サーバ
２４…通知サーバ
３…リポジトリサーバ
４…受信機
４０１…放送受信部
４０２…分離部
４０３…時計
４０４−１…第１同期用バッファ
４０４−２…第２同期用バッファ
４０５−１…第１デコーダ
４０５−２…第２デコーダ
４０６…データ放送実行部
４０７…映像制御部
４０８…映像表示部
４０９…音声制御部
４１０…音声出力部
４１１…通信入出力部
４１２…アプリケーション実行制御部
４１３…提示制御部
４１４…操作入力部
４１５…選局部
４１６…ローカル情報記憶部
４１７…外部Ｉ／Ｆ部
４３１…アプリケーション記憶部
４３２…アプリケーション認証部
４３３…アプリケーション管理部
４３４…アプリケーション制御部
４３５…アプリケーション実行部
４３６…受信機ＡＰＩ部
４３７…端末連携ＡＰＩ部
４３８…リソースアクセス制御部
４３９…リソース制御部
４５１…ポリシーデータ管理部
４５２…ポリシーデータ記憶部
４５３…イベント解釈部
４５４…ポリシーレベル照合部
４５５…イベント制御部
４５６…番組ポリシー記憶部
４５７…ポリシー調停部
４５８…ポリシーレベル記憶部
９…通信網
４７１…起動要求信号取得部
４７２…アプリケーション情報取得部
４７３…起動制御部
４７４…操作受付部
４７５…放送通信連携サービスボタン
４８１…終了制御部
５０１…接続制御部
５０２…端末アプリケーション制御部
５０３…端末アプリケーション実行部
【特許請求の範囲】
【請求項１】
受信中の放送ストリームに対応付けられたアプリケーション情報テーブルに基づいて、放送通信連携サービスにおける第１のアプリケーションを実行する受信機において、
前記受信中の放送ストリームから、通信機能を有する端末に実行させる第２のアプリケーションを指定するアプリケーション指定情報を取得するアプリケーション情報取得部と、
前記アプリケーション情報取得部が取得した前記アプリケーション指定情報に基づき、前記端末に対して、前記第２のアプリケーションを指定し起動制御を行うアプリケーション実行部と、
を備えることを特徴とする受信機。
【請求項２】
前記アプリケーション情報取得部は、前記放送ストリームから、放送番組の関連情報であるメタデータも取得し、
前記アプリケーション実行部は、前記アプリケーション情報取得部が取得した前記アプリケーション指定情報と前記メタデータとに基づき、前記端末に対して、前記第２のアプリケーションと前記メタデータとを指定し起動制御を行う
ことを特徴とする請求項１記載の受信機。
【請求項３】
放送通信連携サービスにおける第１のアプリケーションを実行する受信機と、端末とを通信可能に備える受信システムにおいて、
前記受信機は、
受信中の放送ストリームから、前記端末に実行させる第２のアプリケーションを指定するアプリケーション指定情報を取得するアプリケーション情報取得部と、
前記アプリケーション情報取得部が取得した前記アプリケーション指定情報に基づき、前記端末に対して、前記第２のアプリケーションを指定し起動制御を行うアプリケーション実行部と、
を備え、
前記端末は、
前記アプリケーション実行部による前記起動制御に基づいて、前記第２のアプリケーションを取得する端末アプリケーション取得部と、
前記端末アプリケーション取得部が取得した前記第２のアプリケーションを実行処理する端末アプリケーション実行部と、
を備えることを特徴とする受信システム。
【請求項４】
前記アプリケーション情報取得部は、前記放送ストリームから、放送番組の関連情報であるメタデータも取得し、
前記アプリケーション実行部は、前記アプリケーション情報取得部が取得した前記アプリケーション指定情報と前記メタデータとに基づき、前記端末に対して、前記第２のアプリケーションと前記メタデータとを指定し起動制御を行い、
前記端末アプリケーション実行部は、前記アプリケーション実行部により指定された前記メタデータを用いて、前記端末アプリケーション取得部が取得した前記第２のアプリケーションを実行処理する
ことを特徴とする請求項３記載の受信システム。
【請求項１】
受信中の放送ストリームに対応付けられたアプリケーション情報テーブルに基づいて、放送通信連携サービスにおける第１のアプリケーションを実行する受信機において、
前記受信中の放送ストリームから、通信機能を有する端末に実行させる第２のアプリケーションを指定するアプリケーション指定情報を取得するアプリケーション情報取得部と、
前記アプリケーション情報取得部が取得した前記アプリケーション指定情報に基づき、前記端末に対して、前記第２のアプリケーションを指定し起動制御を行うアプリケーション実行部と、
を備えることを特徴とする受信機。
【請求項２】
前記アプリケーション情報取得部は、前記放送ストリームから、放送番組の関連情報であるメタデータも取得し、
前記アプリケーション実行部は、前記アプリケーション情報取得部が取得した前記アプリケーション指定情報と前記メタデータとに基づき、前記端末に対して、前記第２のアプリケーションと前記メタデータとを指定し起動制御を行う
ことを特徴とする請求項１記載の受信機。
【請求項３】
放送通信連携サービスにおける第１のアプリケーションを実行する受信機と、端末とを通信可能に備える受信システムにおいて、
前記受信機は、
受信中の放送ストリームから、前記端末に実行させる第２のアプリケーションを指定するアプリケーション指定情報を取得するアプリケーション情報取得部と、
前記アプリケーション情報取得部が取得した前記アプリケーション指定情報に基づき、前記端末に対して、前記第２のアプリケーションを指定し起動制御を行うアプリケーション実行部と、
を備え、
前記端末は、
前記アプリケーション実行部による前記起動制御に基づいて、前記第２のアプリケーションを取得する端末アプリケーション取得部と、
前記端末アプリケーション取得部が取得した前記第２のアプリケーションを実行処理する端末アプリケーション実行部と、
を備えることを特徴とする受信システム。
【請求項４】
前記アプリケーション情報取得部は、前記放送ストリームから、放送番組の関連情報であるメタデータも取得し、
前記アプリケーション実行部は、前記アプリケーション情報取得部が取得した前記アプリケーション指定情報と前記メタデータとに基づき、前記端末に対して、前記第２のアプリケーションと前記メタデータとを指定し起動制御を行い、
前記端末アプリケーション実行部は、前記アプリケーション実行部により指定された前記メタデータを用いて、前記端末アプリケーション取得部が取得した前記第２のアプリケーションを実行処理する
ことを特徴とする請求項３記載の受信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【公開番号】特開２０１２−２５７２３３（Ｐ２０１２−２５７２３３Ａ）
【公開日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願番号】特願２０１２−１１２９７３（Ｐ２０１２−１１２９７３）
【出願日】平成２４年５月１７日（２０１２．５．１７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡＳＣＲＩＰＴ
【出願人】（０００００４３５２）日本放送協会 (2,206)
【Ｆターム（参考）】
【公開日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願日】平成２４年５月１７日（２０１２．５．１７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡＳＣＲＩＰＴ
【出願人】（０００００４３５２）日本放送協会 (2,206)
【Ｆターム（参考）】
[ Back to top ]