JPWO2012133064A1 - 送信装置、送信方法、受信装置、受信方法、プログラム、および放送システム - Google Patents

Abstract

本技術は、番組やＣＭなどに連動し得るデータ放送用コンテンツのサービスを実現することができる送信装置、送信方法、受信装置、受信方法、プログラム、および放送システムに関する。制御部は、受信装置においてコンテンツに連動して実行させるためのアプリケーションプログラムの制御に関するトリガ情報を格納したメタデータとともに、そのメタデータを符号化オーディオストリームのユーザデータ領域に埋め込むためのサイズ情報を供給し、オーディオエンコーダは、サイズ情報に基づいて、トリガ情報を格納したメタデータがユーザデータ領域に埋め込まれた符号化オーディオストリームを生成し、送信部は、生成された符号化オーディオストリームを、受信装置に送信する。本開示は、例えば米国などにおいてデータ放送を実現する場合に適用できる。

Description

本開示は、送信装置、送信方法、受信装置、受信方法、プログラム、および放送システムに関し、特に、例えばデジタルテレビジョン放送において、番組やＣＭ（コマーシャルメッセージ）の進行に連動してデータ放送のコンテンツを実行させる場合に用いて好適な送信装置、送信方法、受信装置、受信方法、プログラム、および放送システムに関する。

従来、日本ではテレビジョン放送のデジタル化が推進されており、地上デジタル放送やＢＳデジタル放送などが普及している。また、地上デジタル放送などのデジタルテレビジョン放送では、ニュース、ドラマ、映画などの番組の放送のみならず、いわゆるデータ放送も実現されている。このデータ放送におけるコンテンツによれば、例えば、放送中の番組に関連する情報（出演者、ストーリなど）を表示したり、放送中の番組に関連しない情報（他の番組の告知、ニュース、天気予報、交通情報など）を表示したりすることができる（例えば、特許文献１参照）。

なお、日本におけるデータ放送は、テレビジョン放送のデジタル化に際してデジタルテレビジョン放送の放送帯域内にデータ放送専用の帯域が予め確保されており、この専用帯域を用いてデータ放送用コンテンツが放送されることにより実現されている。

一方、米国におけるデジタルテレビジョン放送では、日本のデジタルテレビジョン放送のようなデータ放送専用の帯域が確保されていない。

すなわち、米国の現状のデジタルテレビジョン放送の放送帯域は、図１のＡに示すように、番組の映像用帯域、音声用帯域、および制御情報用帯域によって占められており、データ放送用コンテンツを放送するための帯域が設けられていない。したがって、デジタルテレビジョン放送の限られた放送帯域に、データ放送用コンテンツを放送するための帯域を確保するには、図１のＢに示すように、例えば映像用帯域および音声用帯域を狭める必要がある。

特開２００６−５０２３７号公報

しかしながら、映像用帯域および音声用帯域を狭めて、データ放送用コンテンツを放送するための帯域を確保することは、番組の画質および音質の劣化につながるので、現実的な対応とは言い難い。

また、映像用帯域および音声用帯域を狭めてデータ放送用コンテンツの帯域を確保したとしても伝送できるデータ量は限られている。したがって、データ放送用コンテンツの情報量が乏しくなってしまったり、情報量を増やそうとすると、受信側で必要なデータを受信するまでに時間がかかってしまったりすることになる。

また、米国においては、CATV（ケーブルＴＶ）網を用いたデジタルテレビジョン番組の再送信システムが普及しているが故に、以下のような問題も生じ得る。

図２は、CATV網を用いたデジタルテレビジョン番組の再送信システムの構成の一例を示している。

この再送信システムは、主に放送装置１、CATV再送信装置２、CATV網３、デジタルテレビジョン受像機４、セットトップボックス(STB)５、およびテレビジョン受像機６から構成される。

放送局などに設けられる放送装置１は、デジタルテレビジョン放送信号を地上波または衛星波を用いて放送する。ケーブルＴＶ局などに設けられるCATV再送信装置２は、放送されたデジタルテレビジョン放送を受信し、不要な情報を除去するとともにCATV独自の情報を追加して、CATV網３を介してデジタルデジタルテレビジョン受像機４、セットトップボックス５などに再送信する。

CATV再送信装置２は、チューナ１１、所定のパケットＩＤのパケットをフィルタリングするPIDフィルタ１２、CATV独自信号発生部１３、多重化部１４、および変調部１５から構成される。

チューナ１１は、各チャンネルのデジタルテレビジョン放送信号を受信して復調し、その結果得られるＴＳ（トランスポートストリーム）をPIDフィルタ１２に出力する。PIDフィルタ１２は、ＴＳから所定のパケットＩＤに対応するパケット（番組としてのＡＶコンテンツに関係がないパケット）を除去して多重化部１４に出力する。CATV独自信号発生部１３は、当該CATV局の独自の情報が格納されたパケットを生成して多重化部１４に出力する。多重化部１４は、PIDフィルタ１２の出力と、CATV独自信号発生部１３の出力とを多重化して変調部１５に出力する。変調部１５は、多重化部１４の出力を、CATV網３に適して変調方式により変調して、CATV網３を介してデジタルテレビジョン受像機４、セットトップボックス５などに再送信する。

CATVに対応したデジタルテレビジョン受像機４は、CATV網３を介して、再送信されたデジタルテレビジョン放送のＴＳを受信してデコードし、その結果得られる映像を表示するとともに音声を出力する。

CATVに対応したセットトップボックス５は、CATV網３を介して、再送信されたデジタルテレビジョン放送のＴＳを受信してデコードし、その結果得られる映像信号および音声信号を、HDMIケーブルなどを介してテレビジョン受像機６に出力する。テレビジョン受像機６は、セットトップボックス５からHDMIケーブルなどを介して入力される映像信号および音声信号に基づき、その映像を表示するとともに音声を出力する。

上述したように、CATV再送信装置２においては、PIDフィルタ１２により、デジタル放送信号のＴＳから、所定のパケットＩＤに対応するパケット（番組としてのＡＶコンテンツに関係がないパケット）が除去される。したがって、仮に図１のＢに示されたように、放送帯域に、データ放送用コンテンツを放送するための帯域を確保したとしても、このPIDフィルタ１２により、データ放送用コンテンツが格納されているパケットが排除されてしまうことが起こり得る。

本開示はこのような状況に鑑みてなされたものであり、デジタルテレビジョン放送の放送帯域にデータ放送用の帯域を設けることなく、テレビジョン放送の番組やＣＭの進行に連動し得るデータ放送用コンテンツを実現できるようにするものである。

本開示の第１の側面である送信装置は、受信装置においてコンテンツに連動して実行させるためのアプリケーションプログラムの制御に関するトリガ情報が埋め込まれた符号化オーディオストリームを生成する音声符号化部と、生成された前記符号化オーディオストリームを、前記受信装置に送信する送信部とを備える。

前記トリガ情報を格納したメタデータとともに、前記メタデータを前記符号化オーディオストリームのユーザデータ領域に埋め込むためのサイズ情報を供給して、前記ユーザデータ領域に前記メタデータの埋め込みが行われるように制御する制御部をさらに備える。

前記音声符号化部は、オーディオストリームをAC3（Audio Code number 3）方式により符号化して、前記符号化オーディオストリームを生成し、前記メタデータは、前記AC3方式のフレーム構造におけるAUX（AUXILIARY DATA）の領域に挿入される。

前記音声符号化部は、オーディオストリームをAAC（Advanced Audio Coding）方式により符号化して、前記符号化オーディオストリームを生成し、前記メタデータは、前記AAC方式のフレーム構造におけるDSE（Data Stream Element）の領域に挿入される。

ビデオストリームを符号化して、符号化ビデオストリームを生成する映像符号化部と、前記符号化オーディオストリームと前記符号化ビデオストリームを多重化して、多重化ストリームを生成する多重化部とをさらに備え、前記送信部は、生成された前記多重化ストリームを送信する。

前記メタデータには、情報のタイプを示すタイプ情報が付加されている。

前記メタデータには、情報識別子で区別された複数種類の情報が含まれる。

本開示の第１の側面である送信方法またはプログラムは、上述した本開示の第１の側面である送信装置に対応する送信方法またはプログラムである。

本開示の第１の側面においては、受信装置においてコンテンツに連動して実行させるためのアプリケーションプログラムの制御に関するトリガ情報が埋め込まれた符号化オーディオストリームが生成され、生成された符号化オーディオストリームが、受信装置に送信される。

本開示の第２の側面である受信装置は、送信装置から送信される、コンテンツに連動して実行させるためのアプリケーションプログラムの制御に関するトリガ情報が埋め込まれた符号化オーディオストリームを受信する受信部と、受信された前記符号化オーディオストリームを復号する音声復号部と、前記符号化オーディオストリームを復号して得られるトリガ情報に応じて、前記コンテンツに連動して実行させるアプリケーションプログラムに関する処理を制御する制御部とを備える。

前記音声復号部は、AC3方式により符号化された符号化オーディオストリームのフレーム構造におけるAUXの領域から、メタデータに格納された前記トリガ情報を取得する。

前記音声復号部は、AAC方式により符号化された符号化オーディオストリームのフレーム構造におけるDSEの領域から、メタデータに格納された前記トリガ情報を取得する。

受信された多重化ストリームを多重分離する多重分離部と、前記多重化ストリームから分離された符号化ビデオストリームを復号する映像復号部とをさらに備え、前記音声復号部は、前記多重化ストリームから分離された符号化オーディオストリームを復号する。

本開示の第２の側面である受信方法またはプログラムは、上述した本開示の第２の側面である受信装置に対応する受信方法またはプログラムである。

本開示の第２の側面においては、送信装置から送信される、コンテンツに連動して実行させるためのアプリケーションプログラムの制御に関するトリガ情報が埋め込まれた符号化オーディオストリームが受信され、受信された符号化オーディオストリームが復号され、符号化オーディオストリームを復号して得られるトリガ情報に応じて、コンテンツに連動して実行させるアプリケーションプログラムに関する処理が制御される。

本開示の第３の側面である放送システムは、コンテンツを送信する送信装置と、送信されたコンテンツを受信する受信装置からなる放送システムにおいて、前記送信装置は、前記受信装置においてコンテンツに連動して実行させるためのアプリケーションプログラムの制御に関するトリガ情報が埋め込まれた符号化オーディオストリームを生成する音声符号化部と、生成された前記符号化オーディオストリームを、前記受信装置に送信する送信部とを備え、前記受信装置は、前記送信装置から送信される、前記符号化オーディオストリームを受信する受信部と、受信された前記符号化オーディオストリームを復号する音声復号部と、前記符号化オーディオストリームを復号して得られるトリガ情報に応じて、前記コンテンツに連動して実行させるアプリケーションプログラムに関する処理を制御する制御部とを備える。

本開示の第３の側面においては、送信装置により、受信装置においてコンテンツに連動して実行させるためのアプリケーションプログラムの制御に関するトリガ情報が埋め込まれた符号化オーディオストリームが生成され、生成された符号化オーディオストリームが、受信装置に送信される。受信装置により、送信装置から送信される、符号化オーディオストリームが受信され、受信された符号化オーディオストリームが復号され、符号化オーディオストリームを復号して得られるトリガ情報に応じて、コンテンツに連動して実行させるアプリケーションプログラムに関する処理が制御される。

本開示の第１の側面によれば、デジタルテレビジョン放送の放送帯域にデータ放送用の帯域を設けることなく、テレビジョン放送の番組やＣＭなどの進行に連動してデータ放送用コンテンツを制御することができる。

本開示の第２の側面によれば、デジタルテレビジョン放送の放送帯域にデータ放送用の帯域を設けることなく、テレビジョン放送の番組やＣＭなどの進行に連動してデータ放送用コンテンツを制御することができる。

本開示の第３の側面によれば、デジタルテレビジョン放送の放送帯域にデータ放送用の帯域を設けることなく、テレビジョン放送の番組やＣＭなどの進行に連動してデータ放送用コンテンツを制御することができる。

デジタルテレビジョン放送の放送帯域を示す図である。 既存のCATV再送信システムの構成の一例を示す図である。 実施の形態である放送システムの構成例を示す図である。 実施の形態である放送装置の構成例を示す図である。 実施の形態である受信装置の構成例を示すブロック図である。 メタデータ汎用シンタックスを示す図である。 メタデータ汎用シンタックスを示す図である。 メタデータ汎用シンタックスを示す図である。 メタデータ汎用シンタックスを示す図である。 トリガ情報をＴＳのPCRパケットに含めて送信する概念を示す図である。 PCRパケットにおけるトリガ情報の具体的な配置を示す図である。 PCRパケットにおけるメタデータの具体的な配置を示す図である。 トリガ情報を映像信号に埋め込む例を示す図である。 符号化ビデオストリームに挿入するトリガ情報の具体的な配置を示す図である。 符号化ビデオストリームに挿入するトリガ情報の具体的な配置を示す図である。 AC3のフレームの構成を示す図である。 符号化オーディオストリーム（AC3）に挿入するメタデータの具体的な配置を示す図である。 AACのフレームの構成を示す図である。 符号化オーディオストリーム（AAC）に挿入するメタデータの具体的な配置を示す図である。 第１の実施の形態におけるプリキャッシュコマンドのトリガ情報に含まれる項目を示す図である。 第１の実施の形態におけるエクスキュートコマンドのトリガ情報に含まれる項目を示す図である。 第１の実施の形態におけるインジェクトイベントコマンドのトリガ情報に含まれる項目を示す図である。 第１の実施の形態におけるサスペンドコマンドのトリガ情報に含まれる項目を示す図である。 第１の実施の形態におけるターミネートコマンドのトリガ情報に含まれる項目を示す図である。 第１の実施の形態に対応したトリガ情報のシンタックスの一例を示す図である。 番組およびＣＭの進行に連動してアプリケーションプログラムを実行した場合の表示例を示す図である。 トリガ情報送信処理を説明するフローチャートである。 トリガ情報対応処理を説明するフローチャートである。 アプリケーションプログラムの運用シナリオの一例を示す図である。 受信装置におけるアプリケーションプログラムの第１の状態遷移図である。 複数のアプリケーションプログラムを同時に制御する場合のシナリオの一例を示す図である。 第２の実施の形態におけるレジスタコマンドのトリガ情報に含まれる項目を示す図である。 第２の実施の形態におけるエクスキュートコマンドのトリガ情報に含まれる項目を示す図である。 第２の実施の形態におけるインジェクトイベントコマンドのトリガ情報に含まれる項目を示す図である。 第２の実施の形態におけるサスペンドコマンドのトリガ情報に含まれる項目を示す図である。 第２の実施の形態におけるターミネートコマンドのトリガ情報に含まれる項目を示す図である。 第２の実施の形態に対応したトリガ情報のシンタックスの一例を示す図である。 アプリケーション登録管理処理を説明するフローチャートである。 受信装置におけるアプリケーションプログラムの第２の状態遷移図である。 コマンドと状態遷移の関係を示す図である。 第２の実施の形態におけるアプリケーションプログラムのライフサイクルを示している。 マルチアプリケーションプログラムの関係を示す図である。 マルチアプリケーションプログラムの運用例を示す図である。 コンピュータの構成例を示すブロック図である。

以下、発明を実施するための最良の形態（以下、実施の形態と称する）について、図面を参照しながら詳細に説明する。

＜１．第１の実施の形態＞
［放送システムの構成例］
図３は、実施の形態である放送システムを示している。この放送システム３０は、例えば現状の米国のように、デジタルテレビジョン放送の放送帯域にデータ放送用コンテンツを放送するための帯域が設けられていない状態において、番組やＣＭなどのＡＶコンテンツに連動し得るデータ放送用コンテンツを実現するものである。

なお、データ放送用コンテンツは、受信装置に供給されるアプリケーションプログラムが受信装置にて起動されることによって実現されるので、以下、データ放送用コンテンツを、データ放送用アプリケーションプログラムまたはデータ放送用アプリとも称する。データ放送用アプリは、１つのプログラムデータから構成されていてもよいし、複数のプログラムデータから成るプログラムデータ群であってもよい。

この放送システム３０は、放送局側に設けられる放送装置４１およびサーバ４２、並びに、受信者側に設けられる再生装置５９および受信装置６０から構成される。

放送装置４１は、デジタルテレビジョン放送信号を送信するようになされている。また、放送装置４１は、ＡＶコンテンツに連動させるデータ放送用コンテンツの動作に関するコマンドとしてのトリガ情報を、デジタルテレビジョン放送信号に含めて送信する。具体的には、デジタルテレビジョン放送信号のトランスポートストリーム（ＴＳ）内に配置したり、映像信号に埋め込んだりして送信する。

トリガ情報には、コマンドの種類を示す情報の他、データ放送用アプリの取得先を示す情報などを含む。トリガ情報の詳細については後述する。

サーバ４２は、インタネット５０を介してアクセスしてきた受信装置６０からの要求に応じてデータ放送用アプリを供給する。

受信装置６０は、放送装置４１から放送されたデジタル放送信号を受信し、ＡＶコンテンツの映像および音声をモニタ（不図示）に出力する。また、受信装置６０は、インタネット５０を介してサーバ４２にアクセスし、データ放送用コンテンツを取得する。なお、この受信装置６０は、単体として存在してもよいし、例えば、テレビジョン受像機やビデオレコーダなどに内蔵されているようにしてもよい。

再生装置５９は、所定の記録媒体などに記録されたＡＶコンテンツの映像および音声を再生し、受信装置６０に出力する。

［放送装置の構成例］
図４は、放送装置４１の構成例を示している。放送装置４１は、制御部５１、ビデオエンコーダ５２、オーディオエンコーダ５３、多重化部５４、および送出部５５から構成される。

制御部５１は、前段から入力される番組やＣＭのビデオストリームの進行に合わせてトリガ情報を生成し、ビデオエンコーダ５２および多重化部５４に出力する。

また、制御部５１は、ビデオストリームの進行に合わせて、トリガ情報を格納したメタデータを生成し、オーディオエンコーダ５３および多重化部５４に出力する。メタデータには、例えばトリガ情報など、音声データと直接関係しない所定の情報が格納される。メタデータの詳細については後述する。

ビデオエンコーダ５２は、前段から入力される番組やＣＭのビデオストリームを所定の符号化方式に従ってエンコードし、その結果得られる符号化ビデオストリームを多重化部５４に出力する。ビデオエンコーダ５２における符号化方式としては、例えば、MPEG2方式、H.264方式などがある。

また、ビデオエンコーダ５２は、ビデオストリームをエンコードするに際して、制御部５１からのトリガ情報を埋め込んでエンコードし、その結果得られる符号化ビデオストリームを多重化部５４に出力する。

オーディオエンコーダ５３は、ビデオエンコーダ５２に入力されるビデオストリームに対応するオーディオストリームを所定の符号化方式に従ってエンコードし、その結果得られる符号化オーディオストリームを多重化部５４に出力する。オーディオエンコーダ５３における符号化方式としては、例えば、AC3（Audio Code number 3）方式、AAC（Advanced Audio Coding）方式などがある。

また、オーディオエンコーダ５３は、オーディオストリームをエンコードするに際して、制御部５１からのメタデータを埋め込んでエンコードし、その結果得られる符号化オーディオストリームを多重化部５４に出力する。

多重化部５４は、入力される符号化ビデオストリームと、符号化オーディオストリームを多重化し、さらに、トリガ情報またはメタデータも多重化し、その結果得られた多重化ストリームを送出部５５に出力する。具体的には、例えば、ＴＳ（トランスポートストリーム）に多重化する。あるいは、デジタルテレビジョン放送のネットワーク配信を考慮して、それに適したISO ベースメディアファイルフォーマット(MP4)に多重化するようにしてもよい。

なお、トリガ情報をビデオストリームに埋め込むとともに、メタデータをオーディオストリームに埋め込み、トリガ情報またはメタデータを多重化ストリームにも多重化するとして説明したが、いずれか１つを行うか、またはいずれかの組み合わせを行うようにしてもよい。

送出部５５は、入力される多重化ストリームをデジタルテレビジョン放送信号として送出する。

［受信装置の構成例］
図５は、受信装置６０の構成例を示している。受信装置６０は、チューナ６１、多重分離部６２、オーディオデコーダ６３、音声出力部６４、ビデオデコーダ６５、トリガ検出部６６、映像出力部６７、制御部６８、メモリ６９、操作部７０、記録部７１、通信I/F７２、キャッシュメモリ７３、アプリエンジン７４、アプリ用メモリ７５、HDMI I/F７６、スイッチ７７、およびスイッチ７８から構成される。

チューナ６１は、ユーザによって選局されたチャンネルに対応するデジタルテレビジョン放送信号を受信して復調し、その結果得られるＴＳを多重分離部６２に出力する。多重分離部６２は、チューナ６１から入力されるＴＳを符号化オーディオストリーム（オーディオ符号化信号）、符号化ビデオストリーム（ビデオ符号化信号）、および制御信号に分離し、それぞれをスイッチ７７、ビデオデコーダ６５、または制御部６８に出力する。

さらに、多重分離部６２は、ＴＳに配置されたトリガ情報を含むPCRパケットを抽出してトリガ検出部６６に出力する。

HDMI I/F７６には、再生装置５９からHDMI（High Definition Multimedia Interface）に準拠した通信により送出されたＡＶコンテンツが入力される。HDMI I/F７６は、再生装置５９からのＡＶコンテンツの符号化オーディオストリーム（オーディオ符号化信号）をスイッチ７７に出力し、映像信号をスイッチ７８に出力する。

なお、HDMI I/F７６において、再生装置５９からの入力としては、音声信号がデコードされた状態で入力される場合と、デコードされていない状態で入力される場合があるが、ここでは、符号化オーディオストリームが入力された場合について説明する。

スイッチ７７には、多重分離部６２からの符号化オーディオストリームと、HDMI I/F７６からの符号化オーディオストリームが入力される。スイッチ７７は、予め設定されているユーザからの指示に基づいて、入力された符号化オーディオストリームのうち、一方の符号化オーディオストリームを、オーディオデコーダ６３に出力する。

オーディオデコーダ６３は、入力された符号化オーディオストリームをデコードし、その結果得られるオーディオストリーム（音声信号）を音声出力部６４およびトリガ検出部６６に出力する。音声出力部６４は、入力された音声信号を後段（例えば、スピーカ）に出力する。

ビデオデコーダ６５は、入力された符号化ビデオストリームをデコードし、その結果得られるビデオストリーム（映像信号）をトリガ検出部６６およびスイッチ７８に出力する。

トリガ検出部６６は、入力されたオーディオストリームに埋め込まれているメタデータに格納されているトリガ情報を検出して制御部６８に出力する。また、トリガ検出部６６は、入力されたビデオストリームに埋め込まれているトリガ情報を検出して制御部６８に出力する（トリガ情報がＴＳのみに配置されている場合、これらのトリガ検出部６６の動作は不要である）。また、トリガ検出部６６は、多重分離部６２から入力される、トリガ情報を含むPCRパケットからトリガ情報またはメタデータに格納されているトリガ情報を抽出して制御部６８に出力する。

なお、トリガ検出部６６を省略して、オーディオデコーダ６３にて、オーディオストリームからトリガ情報を抽出し、ビデオデコーダ６５にて、ビデオストリームからトリガ情報を抽出するようにしてもよい。この場合、多重分離部６２では、多重化ストリームに多重化されているトリガ情報が分離され、直接に制御部６８に出力されることになる。

スイッチ７８には、HDMI I/F７６からの映像信号と、ビデオデコーダ６５からの映像信号が入力される。スイッチ７８は、予め設定されているユーザからの指示に基づいて、入力された映像信号のうち、一方の映像信号を、映像出力部６７に出力する。

映像出力部６７は、スイッチ７８から入力された映像信号を後段（例えば、ディスプレイ）に出力する。また、映像出力部６７は、アプリエンジン７４から入力されるデータ放送用コンテンツの映像と、ビデオデコーダ６５から入力された映像信号を合成して、後段に出力する。

制御部６８は、メモリ６９に記録されている制御用プログラムを実行することにより受信装置６０の全体を制御する。また、制御部６８は、トリガ検出部６６から入力されるトリガ情報に基づき、データ放送用アプリの取得、登録、起動、イベント発火、休止、再開、終了等を制御する。

メモリ６９には、制御部６８によって実行される制御用プログラムが記録されている。この制御用プログラムは、デジタルテレビジョン放送信号、またはインタネット５０を介して供給される更新データに基づいて更新することができる。操作部７０は、ユーザからの各種の操作を受け付けて、それに対応する操作信号を制御部６８に通知する。

記録部７１は、データ放送用アプリがデジタルテレビジョン放送信号を用いて配信される場合において、ダウンロードしたデータ放送用アプリを、内蔵するハードディスクなどの記録媒体に保持する。

通信I/F７２は、アプリエンジン７４からの制御に従い、インタネット５０を介してサーバ４２に接続する。アプリエンジン７４は、制御部６８からの制御に従い、通信I/F７２およびインタネット５０を介してサーバ４２からデータ放送用アプリを取得し、キャッシュメモリ７３に保持させる。

アプリエンジン７４は、制御部６８からの制御に従い、記録部７１またはキャッシュメモリ７３に保持されているデータ放送用アプリを読み出して実行する。

アプリ用メモリ７５は、ワークメモリ７５Ａおよび退避メモリ７５Ｂとから成る。アプリエンジン７４は、実行中のデータ放送用アプリに関するデータ（具体的には、表示されている情報の階層などを含む）をワークメモリ７５Ａに記録する。また、アプリエンジン７４は、実行中のデータ放送用アプリを休止する場合、アプリ用メモリ７５のワークメモリ７５Ａのデータを退避メモリ７５Ｂに移動させる。そして、休止したデータ放送用アプリを再開する場合、退避メモリ７５Ｂのデータをワークメモリ７５Ａに移動させて休止前の状態を復活させる。

なお、アプリ用メモリ７５における同じサイズの２領域のうち、一方をワークメモリ７５Ａ、他方を退避メモリ７５Ｂとして交互に切り替えるようにしてもよい。これにより、ワークメモリ７５Ａと退避メモリ７５Ｂとの間でのデータの移動をなくすことができる。

［トリガ情報の送信方法］
次に、トリガ情報の送信方法について説明する。トリガ情報の送信方法としては、次の４種類の方法がある。

（ａ）PCRパケットに挿入する方法
（ｂ）映像信号に埋め込む方法
（ｃ）符号化ビデオストリーム（ビデオ符号化信号）に挿入する方法
（ｄ）符号化オーディオストリーム（オーディオ符号化信号）に挿入する方法

上記の（ａ）乃至（ｄ）の方法のうち、（ｂ），（ｃ）の方法では、トリガ情報がそのまま挿入されるが、（ａ），（ｄ）の方法では、トリガ情報が、トリガ情報以外の情報を含めた汎用的なメタデータ伝送フォーマットにより挿入される。なお、（ａ）の方法については、トリガ情報をそのまま挿入してもよい。

［メタデータ汎用シンタックス］
ここで、上記の（ａ），（ｄ）の方法で用いられる、メタデータ汎用シンタックスについて説明する。図６乃至図８は、メタデータ汎用シンタックスの一例を示している。また、図９は、メタデータ汎用シンタックスにおける主要なデータ規定内容（semantics）を示しており、図６乃至図８の説明では、図９の内容を適宜参照しながら説明する。

図６は、metadata()のシンタックスの一例を示している。

sync_byteは、メタデータ・コンテナ（metadata container）を示すユニークワードとされる。metadata_typeは、メタデータのタイプ情報を示す。このタイプ情報により、複数のタイプのメタデータを選択的に送信することが可能となる。例えば、00000011は、送信されるメタデータがトリガ情報であることを示す。

metadata_lengthは、以降のバイト数を示す。metadata_IDは、メタデータのタイプ内において種類を識別するための情報である。この識別子により、同一タイプの複数種類の情報を同時に送信することが可能となる。

metadata_counterは、一連のメタデータを分割して送信する場合に、何番目の分割情報であるかを示すカウント情報である。このカウント情報はオーディオフレーム毎にインクリメントされるカウンタのカウント値である。

metadata_start_flagは、一連のメタデータ（メタデータパケット）を分割して送信する場合に、最初の分割情報であるか否かを示す。例えば、１は最初の分割情報であることを示し、０は最初の分割情報ではなく、前のフレームの分割情報に続く分割情報であることを示す。

sync_control_flagは、メタデータが同期管理されているか否かを示す。１は、PTS_management()内のPTSによって同期管理されることを示す。０は、同期管理されていないことを示す。sync_control_flagが１であるとき、PTS_management()が存在する。

図７は、PTS_management()のシンタックスの一例を示しており、ＰＴＳ[32-0]の３３ビットで示される時間情報が存在する。

図６に戻り、metadata_lengthで示されるバイト数分のdata_byteは、メタデータパケットMetadata_packet()の全体、あるいは、このメタデータパケットMetadata_packet()を複数個に分割して得られたいずれかの分割情報を構成する。

図８は、metadata_packet()のシンタックスの一例を示している。

packet_typeは、metadata()（図６）のmetadata_typeと同様に、メタデータのタイプ情報を示す。metadata_packet_lengthは、以降のバイト数を示す。そして、このmetadata_packet_lengthで示されるバイト数分のdata_byteに、metadata_packet()の全体が記載される。

例えば、メタデータに格納される情報がトリガ情報である場合、トリガ情報のmetadata_Packet()、すなわち、後述するTrigger_info_data()(図２５，図３７)が、このdata_byteに記載される。

なお、メタデータに格納される情報はトリガ情報以外であってもよく、例えば、他サービスアクセス情報（Metadata for linking service）や、視差情報（Metadata for disparity shifting data）とすることができる。他サービスアクセス情報や視差情報に関しては、例えば、本出願人の出願である特願２０１１−０６１５４９号に記載されている。

［（ａ）PCRパケットに挿入する方法］
次に、トリガ情報の各送信方法の詳細について説明する。図１０は、トリガ情報がデジタルテレビジョン放送信号のＴＳのPCR(Program Clock Reference)パケットに配置された送信される場合の概念を示している。

同図に示すように、トリガ情報は全てのPCRパケットに格納されるわけではなく、ＡＶコンテンツ（番組、ＣＭとなど）に連動させるための適切なタイミングにおいてのみ、PCRパケットに格納される。通常、PCRパケットは、図２に示されたようなCATV再送信装置２のPIDフィルタ１２を通過するので、CATV網を利用する受信装置（図２のデジタルテレビジョン受像機４）に対してもトリガ情報を通知することができる。

なお、トリガ情報は、電波障害や受信装置６０における取りこぼし（受信ミス）を考慮して、同一内容のものが複数回連続的に送信される。

図１１は、PCRパケットにおいてトリガ情報が格納される位置を示している。PCRパケットは、ＴＳパケットのadaptation_fieldにPCRが格納されたものであり、トリガ情報(Trigger Info_descriptor)は、PCRの後に続くtransport_private_data_byteに格納される。なお、トリガ情報が格納される場合、PCRの前に設けられているVarious_flagsのtransport_private_data_flagが１とされる。

また、図１２に示すように、トリガ情報をメタデータに格納して、そのメタデータが、transport_private_data_byteに格納されるようにしてもよい。この場合においても、Various_flagsのtransport_private_data_flagが１とされる。

このように、（ａ）PCRパケットに挿入する方法においては、トリガ情報またはそのトリガ情報を格納したメタデータが、PCRパケットのtransport_private_data_byteに格納される。

［（ｂ）映像信号に埋め込む方法］
図１３は、トリガ情報を映像信号に埋め込む２種類の例を示している。

同図のＡは、トリガ情報を２次元バーコード化して、映像信号の画像の所定の位置（いまの場合、右下隅）に重畳合成する例を示している。同図のＢは、トリガ情報を映像コード化して、映像信号の画像の下部の数ラインに合成する例を示している。同図のＡおよび同図のＢにおけるトリガ情報は、受信装置６０のトリガ検出部６６によって検出される。

同図のＡまたは同図のＢのどちらの例においても、トリガ情報はＡＶコンテンツの映像の上に配置されているので、例えば、CATV網を利用した受信装置（例えば、図２のテレビジョン受像機６）に対しても、トリガ情報を通知することができる。

また、同図のＡまたは同図のＢのどちらの例においても映像上のトリガ情報（２次元バーコードまたは映像コード）は受信装置６０のユーザによって視認され得るが、これが好ましくない場合、映像上のトリガ情報をその周囲の画素と同じ画素によりマスクしてから表示するようにすればよい。

このように、（ｂ）映像信号に埋め込む方法においては、トリガ情報が、映像信号の画像の所定の領域に埋め込まれる。

［（ｃ）符号化ビデオストリームに挿入する方法］
図１４および図１５は、トリガ情報をMPEG2の符号化ビデオストリーム（ビデオ符号化信号）に挿入する場合の例を示している。

図１４は、MPEG2ビデオで定義されるvideo_sequence()の構成を示している。

トリガ情報をMPEG2の符号化ビデオストリームに挿入する場合、video_sequence()内のピクチャレイヤにおけるuser_dataが利用される。

図１５は、user_data()のシンタックスの一例を示している。

user_data_start_codeには、0x000001B2が固定値で記載される。Trigger_Info_Data_identifierには、0x54524749("TRGI")が固定値で記載される。

Trigger_info_data()には、トリガ情報、すなわち、後述するTrigger_info_data()(図２５，図３７)が記載される。

このように、（ｃ）符号化ビデオストリームに挿入する方法においては、トリガ情報が、video_sequence()のuser_data()の領域に挿入される。

［（ｄ）符号化オーディオストリームに挿入する方法］
図１６および図１７は、トリガ情報が格納されたメタデータを、AC3方式によりエンコードされた符号化オーディオストリーム（オーディオ符号化信号）に挿入する場合の例を示している。

図１６は、AC3のフレーム（AC3 Synchronization Frame）の構造を示している。符号化方式がAC3方式の場合、メタデータはAUX（AUXILIARY DATA）の領域に挿入される。

図１７は、AUXのシンタックスの一例を示している。auxdataeが１のとき、aux dataがイネーブルされ、auxdatalの14bits（ビット単位）で示されるサイズのデータが、auxbitsの中に定義される。その際のaudbitsのサイズはnauxbitsに記載される。そして、auxbitsの空間がmetadata（）と定義され、トリガ情報が挿入される。

図１８および図１９は、トリガ情報が格納されたメタデータを、AAC方式によりエンコードされた符号化オーディオストリームに挿入する場合の例を示している。

図１８は、AACの1024サンプル分の音声データが入るフレーム（Raw_data_block）の構造を示している。符号化方式がAAC方式の場合、メタデータはDSE（Data Stream Element）の領域に挿入される。

図１９は、DSEのシンタックスの一例を示している。element_instance_tagは、data_stream_elementの中のデータ種別を示すが、DSEを統一したユーザデータとして利用する場合は、この値を０としてもよい。Data_byte_align_flagは、１とされ、DSEの全体がバイトアラインされるようにする。count、あるいは、その追加バイト数を意味するesc_countは、ユーザデータのサイズによって適宜、値が決められる。そして、data_stream_byteの空間がmetadata()と定義され、トリガ情報が挿入される。

このように、（ｄ）符号化オーディオストリームに挿入する方法においては、トリガ情報を格納したメタデータが、AC3方式によりエンコードされた場合にはAUXの領域に挿入され、AAC方式によりエンコードされた場合にはDSEの領域に挿入される。なお、符号化方式として、AC3方式とAAC方式を採用した場合を説明したが、他の符号化方式にも適用することができる。

［トリガ情報の詳細］
次に、トリガ情報の詳細について説明する。トリガ情報は、それに含まれるコマンドの種類に応じて５種類に分類される。

５種類のコマンドは、２つの組み合わせが提案されている。１組目（以下、第１の実施の形態と称する）は、プリキャッシュ(Pre_cache)、エクスキュート(Execute)、インジェクトイベント(Inject_event)、およびターミネート(Terminate)の各コマンドからなる組み合わせである。２組目（以下、第２の実施の形態と称する）は、レジスタ(Register)、エクスキュート(Execute)、インジェクトイベント(Inject_event)、およびターミネート(Terminate)の各コマンドからなる組み合わせである。

まず、第１の実施の形態における５種類のコマンドについて説明する。第２の実施の形態については図３２以降を参照して後述する。

［５種類のコマンドの第１の例］
図２０は、プリキャッシュ(Pre_cache)コマンドとしてのトリガ情報に含まれる項目を示している。プリキャッシュコマンドは、受信装置６０に対して、データ放送用アプリの取得を指示するためのコマンドである。

Trigger_idは、当該トリガ情報を識別するための情報である。同一内容のトリガ情報が複数回送信される場合、各トリガ情報のTrigger_idは同一である。Protcol_versionは、当該トリガ情報のプロトコルのバージョンを示している。Command_codeは、当該トリガ情報のコマンドの種類を示す。同図の場合、プリキャッシュコマンドであることを示す情報が記載される。

Trigger_varidityは、当該トリガ情報を受信した各受信装置６０が当該トリガ情報に従って処理を実行する確率を示すサーバアクセス分散パラメータ値Ｎである。この値を設けることにより、複数の受信装置６０がサーバ４２からデータ放送用アプリを取得するに際し、そのアクセスが一時期に集中せず分散させることができる。例えば、数多く存在し得る受信装置６０からのサーバ４２に対するアクセスを４回に分散させるためには、同一のトリガ情報を４回送信するようにし、１回目のトリガ情報におけるサーバアクセス分散パラメータＮ＝４とし、２回目のトリガ情報におけるサーバアクセス分散パラメータＮ＝３とし、３回目のトリガ情報におけるサーバアクセス分散パラメータＮ＝２とし、４回目のトリガ情報におけるサーバアクセス分散パラメータＮ＝１とすればよい。

App_idは、当該トリガ情報に対応して取得するデータ放送用アプリの識別情報である。App_typeは、当該トリガ情報に対応するデータ放送用アプリのタイプ（例えば、HTML5，javaなど）を示す情報である。App_urlは、データ放送用アプリの取得先のURLである。

Broadcast_App_flag，Downloaded_App_flag、およびInternet_App_flagは、当該トリガ情報に対応するデータ放送用アプリの所在を示すフラグである。Broadcast_App_flagは、当該トリガ情報に対応するデータ放送用アプリがデジタルテレビジョン放送信号から取得可能である場合に１とされる。Downloaded_App_flagは、当該トリガ情報に対応するデータ放送用アプリが既にダウンロードされていてローカルストレージ（例えば、記録部７１）から取得可能である場合に１とされる。Internet_App_flagは、当該トリガ情報に対応するデータ放送用アプリがインタネット５０を介してサーバ４２から取得可能である場合に１とされる。

図２１は、エクスキュート(Execute)コマンドとしてのトリガ情報に含まれる項目を示している。エクスキュートコマンドとは、受信装置６０に対して、データ放送用アプリの起動を指示するためのコマンドである。

Trigger_id，Protcol_version，Command_code，Trigger_varidity，App_id，App_type，App_url，Broadcast_App_flag，Downloaded_App_flag、およびInternet_App_flagについては、図２０に示されたプリキャッシュコマンドとしてのトリガ情報と同様である。ただし、Command_codeには、エクスキュートコマンドであることを示す情報が記載される。

App_life_scopeは、チャンネルなどの切り替えが生じたときに実行中のデータ放送用アプリを終了することなく、実行状態を継続する範囲を示している。App_expire_dateは、ターミネートコマンドが受信されなくても、実行中のデータ放送用アプリを終了する日時を示している。

図２２は、インジェクトイベント(Inject_event)コマンドとしてのトリガ情報に含まれる項目を示している。インジェクトイベントコマンドは、受信装置６０に対して、実行中のデータ放送用アプリにおいてイベントを引火させるためのコマンドである。

Trigger_id，Protcol_version，Command_code，Trigger_varidity，App_id、およびApp_typeについては、図２０に示されたプリキャッシュコマンドとしてのトリガ情報と同様である。ただし、Command_codeには、インジェクトイベントコマンドであることを示す情報が記載される。

Event_idは、App_idにて指定されたデータ放送用アプリにおいて発火すべきイベントの識別情報である。Event Embedded Dataは、イベントを発火する際に参照されるデータが記載される。

図２３は、サスペンド(Suspend)コマンドとしてのトリガ情報に含まれる項目を示している。サスペンドコマンドは、受信装置６０に対して、実行中のデータ放送用アプリを休止させるためのコマンドである。

Trigger_id，Protcol_version，Command_code，Trigger_varidity，App_id、およびApp_typeについては、図２０に示されたプリキャッシュコマンドとしてのトリガ情報と同様である。ただし、Command_codeには、サスペンドコマンドであることを示す情報が記載される。

図２４は、ターミネート(Terminate)コマンドとしてのトリガ情報に含まれる項目を示している。ターミネートコマンドは、受信装置６０に対して、実行中のデータ放送用アプリを終了させるためのコマンドである。

Trigger_id，Protcol_version，Command_code，Trigger_varidity，App_id、およびApp_typeについては、図２０に示されたプリキャッシュコマンドとしてのトリガ情報と同様である。ただし、Command_codeには、ターミネートコマンドであることを示す情報が記載される。

図２５は、上述した各コマンドとしてのトリガ情報に対応可能なトリガ情報のシンタックスの一例を示している。なお、トリガ情報のシンタックスは任意であって、図２５の例に限定されるものではない。

［受信装置６０の動作概要］
次に、トリガ情報に従う受信装置６０の動作について説明する。

図２６は、ＡＶコンテンツ（番組、ＣＭなど）に対応するデータ放送用アプリを受信装置６０に実行させるときの受信装置６０の表示画面の遷移を示している。

例えば同図のＡに示すように、番組（いまの場合、「７時のニュース」）が放送されており、番組の内容が経済情報に移ると、それにあわせて、番組に対応するデータ放送用アプリに対するエクスキュートコマンドのトリガ情報が送信される。これが受信装置６０に受信されると、データ放送用アプリが起動されて、番組が表示されている画面上には、同図のＢに示すように、データ放送用アプリの表示が用意されている旨をユーザに通知するためのアイコン（いまの場合、「株」）が表示される。

ユーザがこのアイコンを選択すると、画面上には、同図のＣに示すように、データ放送用アプリによる表示（いまの場合、株価情報表示）が行われる。このように、画面上に表示されたアイコンがユーザによって選択された場合にのみ、データ放送用アプリによる表示を行うので、データ放送用アプリによる表示を必要としないユーザを煩わせてしまう事態を抑止することができる。

さらに番組の内容が推移すると（いまの場合、スポーツ情報に推移すると）、それにあわせてインジェクイベントコマンドのトリガ情報が送信される。これが受信されると、イベントが発火されて、例えば、画面上のデータ放送用アプリによる表示が、同図のＤに示すように変更される（いまの場合、試合結果情報表示に変更される）。

その後、ＣＭの放送に先立って、番組に対応する実行中のデータ放送用アプリに対するサスペンドコマンドのトリガ情報が送信され、これが受信されると、番組に対応するデータ放送用アプリが休止される。この後、ＣＭに対応するデータ放送用アプリに対するエクスキュートコマンドのトリガ情報が送信され、これが受信されると、ＣＭ番組のデータ放送用アプリが起動される。これにより、ＣＭが表示されている画面上には、同図のＥに示すように、ＣＭに対応するデータ放送用アプリの表示をユーザに促すためのアイコン（いまの場合、「懸賞応募」）が表示される。

ユーザがこのアイコンを選択すると、画面上には、ＣＭに対応するデータ放送用アプリによる表示（いまの場合、懸賞応募のための表示）が行われる。

ＣＭの終了後、番組再開にあわせて、番組に対応するデータ放送用アプリに対するエクスキュートコマンドのトリガ情報が送信され、これが受信されると、同図のＦに示すように、CMに対応するデータ放送用アプリの表示が消去されて、番組のデータ放送用アプリの表示も、先ほど休止された状態から再開される。

そして、番組が終了するとき、それにあわせて、番組に対応するデータ放送用アプリに対するターミネートコマンドのトリガ情報が送信され、これが受信されると、データ放送用アプリが終了され、同図のＧに示すように、画面上からデータ放送用アプリの表示が消去されて番組の映像のみが表示される。

なお、データ放送用アプリの表示については、図２６に示されたように、番組の表示を縮小してデータ放送用アプリの表示のための領域を設ける方法だけでなく、例えば、番組の表示に、データ放送用アプリの表示を重畳するようにしてもよい。

［トリガ情報送信処理について］
次に、放送装置４１がデジタルテレビジョン放送信号にトリガ情報を含めて送信するときのトリガ情報送信処理について、図２７を参照して説明する。

図２７は、トリガ情報送信処理を説明するフローチャートである。

ステップＳ１０１において、制御部５１は、前段から入力される番組やＣＭのビデオストリームの進行に対応させたトリガ情報を生成する。

ステップＳ１０２において、ビデオエンコーダ５２は、前段から入力された番組やＣＭのビデオストリームをエンコードし、その結果得られる符号化ビデオストリームを多重化部５４に出力する。

ステップＳ１０３において、制御部５１は、符号化オーディオストリームにトリガ情報を挿入するか否か、予め設定されているユーザからの指示に基づいて判断する。

符号化オーディオストリームにトリガ情報を挿入すると判断された場合、処理は、ステップＳ１０４に進められる。ステップＳ１０４において、制御部５１は、トリガ情報に基づいて、メタデータを生成し、このメタデータをユーザデータ領域に埋め込むためのサイズ情報とともに、オーディオエンコーダ５３に出力する。

ステップＳ１０５において、オーディオエンコーダ５３は、制御部５１からのサイズ情報に基づいて、オーディオストリームをエンコードして、制御部５１からのメタデータを挿入し、その結果得られる符号化オーディオストリームを、多重化部５４に出力する。

例えば、符号化方式がAC3方式（図１６）の場合、制御部５１は、サイズＳ＝（frmsizcod−AUXDATA）の情報を、オーディオエンコーダ５３に供給する。ここで、frmsizcodは、AC3のオーディオフレームのサイズであり、ビットレートおよびサンプリング周波数に応じた値が規定されている。例えば、ビットレートが128kbpsで、サンプリング周波数が32kHzの場合には、384*2Bytesである。また、例えば、ビットレートが128kbpsで、サンプリング周波数が44.1kHzの場合には、279*2Bytesである。また、例えば、ビットレートが128kbpsで、サンプリング周波数が48kHzの場合には、256*2Bytesである。

オーディオエンコーダ５３は、サイズＳを目標値としてエンコードし、Audblock ５のmantissa dataと、AUXと、CRCとの合計サイズが全体の３／８を超えないように、オーディオデータをエンコードする。そして、AUXの領域にメタデータを挿入し、CRCを施してストリームを完成する。これにより、図１７のAUX（AUXILIARY DATA）の領域において、auzbitsの空間には、トリガ情報を格納したメタデータが挿入される。

また、例えば、符号化方式がAAC方式（図１８）の場合、制御部５１は、メタデータを挿入すべきDSE（Data Stream Element）のサイズDSE_S＝cntの情報を、オーディオエンコーダ５３に供給する。オーディオエンコーダ５３は、オーディオデータをエンコードするとともに、メタデータが挿入されたDSEを付加して、ストリームを完成する。これにより、図１９のDSEの領域において、data_stream_byteの空間には、トリガ情報を格納したメタデータが挿入される。

なお、オーディオエンコーダ５３は、２回に分けてエンコードすることも可能である。この場合、オーディオエンコーダ５３は、最初は通常の、つまりDSEあるいはAUXがない場合のエンコードを行い、その後に予め予約しておいたサイズのDSEあるいはAUXにメタデータを挿入して、再度エンコードを行う。

以上のように、オーディオエンコーダ５３においては、符号化オーディオストリームのユーザデータ領域（例えば、AC3方式の場合にはAUX、AAC方式の場合にはDSE）に、メタデータを埋め込むための処理が行われ、処理は、ステップＳ１０７に進められる。

なお、ステップＳ１０３において、符号化オーディオストリームにトリガ情報を挿入しないと判断された場合、処理は、ステップＳ１０６に進められる。ステップＳ１０６において、オーディオエンコーダ５３は、オーディオストリームをエンコードし、その結果得られる符号化オーディオストリームを、多重化部５４に出力する。この後、処理はステップＳ１０７に進められる。

ステップＳ１０７において、多重化部５４は、ビデオエンコーダ５２から出力された符号化ビデオストリームと、オーディオエンコーダ５３から出力された符号化オーディオストリームを多重化し、その結果得られた多重化ストリームを送出部５５に出力する。

ステップＳ１０８において、送出部５５は、多重化部４４から入力された多重化ストリームをデジタルテレビジョン放送信号として送出（送信）する。この後、処理はステップＳ１０１に戻って、それ以降が繰り返されることになる。以上で、トリガ情報送信処理の説明を終了する。

なお、上述したトリガ情報送信処理では、上記の（ａ）乃至（ｄ）のトリガ情報の送信方法のうち、（ｄ）符号化オーディオストリームに挿入する方法について説明したが、（ａ）乃至（ｃ）の方法でも同様に、トリガ情報やメタデータを埋め込むことができる。例えば、（ａ）の方法を採用した場合、多重化部５４により多重化が行われる際に、PCRパケットに、トリガ情報またはメタデータが挿入される。また、例えば、（ｂ）の方法を採用した場合、ビデオストリームの映像信号にトリガ情報が埋め込まれる。また、例えば、（ｃ）の方法を採用した場合、ビデオエンコーダ５２によるエンコードが行われる際に、符号化ビデオストリームに、トリガ情報が挿入される。

[トリガ情報対応処理について]
次に、受信装置６０がトリガ情報を受信したときのトリガ情報対応処理について、図２８を参照して説明する。

図２８は、トリガ情報対応処理を説明するフローチャートである。このトリガ情報対応処理は、ユーザがテレビジョン番組を視聴しているとき、すなわち、デジタルテレビジョン放送信号を受信している間、繰り返して実行される。

ステップＳ１において、トリガ検出部６６は、トリガ情報を受信したか否かを判定する。

この判定条件としては、上述した（ａ）の方法が採用された場合には、多重分離部６２からトリガ情報を含むPCRパケットが入力されるまで待機する。また、（ｂ），（ｃ）の方法が採用された場合には、ビデオデコーダ６５から出力される映像信号からトリガ情報が検出されるまで待機する。また、（ｄ）の方法を採用した場合には、オーディオデコーダ６５から出力される音声信号からメタデータに格納されたトリガ情報が検出されるまで待機する。そして、トリガ情報を含むPCRパケットが入力されるか、またはトリガ情報が検出された場合、処理はステップＳ２に進められる。

ステップＳ２において、トリガ検出部６６は、トリガ情報を制御部６８に出力する。制御部６８は、トリガ情報のTrigger_idを読み出し、当該トリガ情報に対してステップＳ３以降の処理を既に実行済みであるか否かを判定する。既にステップＳ３以降の処理を実行済みであると判定された場合、処理はステップＳ１に戻されて、それ以降が繰り返される。反対に、当該トリガ情報に対してステップＳ３以降の処理を実行していないと判定された場合、処理はステップＳ３に進められる。

ステップＳ３において、制御部６８は、トリガ情報のCommand_codeを読み出し、当該トリガ情報の示すコマンドが、プリキャッシュ、エクスキュート、インジェクトイベント、サスペンド、またはターミネートのいずれであるかを判別する。

ステップＳ４において、制御部６８は、ステップＳ３の判別結果がプリキャッシュであるか否かを判断し、プリキャッシュであると判断された場合、処理はステップＳ５に進められる。

ステップＳ５において、制御部６８は、当該トリガ情報のApp_idにより特定されるデータ放送用アプリを取得させる。具体的には、当該トリガ情報のBroadcast_App_flagが１である場合、App_idにより特定されるデータ放送用アプリがテレビジョン放送信号から取得されて記録部７１に記録される。当該トリガ情報のDownloaded_App_flagが１である場合、App_idにより特定されるデータ放送用アプリが、ローカルストレージである記録部７１から取得される。当該トリガ情報のInternet_App_flagが１である場合、App_idにより特定されるデータ放送用アプリが、インタネット５０を介してサーバ４２から取得されてキャッシュメモリ７３に記録される。なお、Broadcast_App_flag，Downloaded_App_flag、およびInternet_App_flagのうち、２つ以上のflagが１である場合、受信装置６０側の都合に応じて、当該トリガ情報のApp_idにより特定されるデータ放送用アプリを取得することができる。この後、処理はステップＳ１に戻り、それ以降が繰り返される。

ステップＳ４において、ステップＳ３の判別結果がプリキャッシュではないと判断された場合、処理はステップＳ６に進められる。ステップＳ６において、制御部６８は、ステップＳ３の判別結果がエクスキュートであるか否かを判断し、エクスキュートであると判断された場合、処理はステップＳ７に進められる。

ステップＳ７において、アプリエンジン７４は、制御部６８からの制御に従い、当該トリガ情報のApp_idにより特定されるデータ放送用アプリが休止中（サスペンド状態）であるか否かを判断する。具体的には、退避メモリ７５Ｂに、App_idにより特定されるデータ放送用アプリに、休止の状態を示すデータが退避されている場合に休止中であると判断する。

ステップＳ７において、App_idにより特定されるデータ放送用アプリが休止中ではないと判断された場合、処理はステップＳ８に進められる。ステップＳ８において、アプリエンジン７４は、制御部６８からの制御に従い、App_idにより特定されるデータ放送用アプリが未取得（記録部７１またはキャッシュメモリ７３に存在しない）の場合にそれを取得する。

ステップＳ９において、アプリエンジン７４は、制御部６８からの制御に従い、現在実行中のデータ放送用アプリがあるならば、それを終了させる。

ステップＳ１０において、アプリエンジン７４は、制御部６８からの制御に従い、App_idにより特定されるデータ放送用アプリを起動する。この後、処理はステップＳ１に戻り、それ以降が繰り返される。

なお、ステップＳ７において、App_idにより特定されるデータ放送用アプリが休止中（サスペンド状態）であると判断された場合、処理はステップＳ１１に進められる。ステップＳ１１において、アプリエンジン７４は、制御部６８からの制御に従い、退避メモリ７５Ｂのデータをワークメモリ７５Ａに移して、App_idにより特定されるデータ放送用アプリを起動する。これにより、App_idにより特定される、休止中のデータ放送用アプリが休止された状態から再開されることになる。この後、処理はステップＳ１に戻り、それ以降が繰り返される。

ステップＳ６において、ステップＳ３の判別結果がエクスキュートではないと判断された場合、処理はステップＳ１２に進められる。ステップＳ１２において、制御部６８は、ステップＳ３の判別結果がインジェクトイベントであるか否かを判断し、インジェクトイベントであると判断された場合、処理はステップＳ１３に進められる。

ステップＳ１３において、制御部６８は、当該トリガ情報のApp_idと、動作中のデータ放送用アプリのApp_idが一致する場合のみ、アプリエンジン７４を制御して、動作中のアプリケーションにおいて、トリガ情報のEvent_idに対応するイベントを発火（実行）させる。この後、処理はステップＳ１に戻り、それ以降が繰り返される。

ステップＳ１２において、ステップＳ３の判別結果がインジェクトイベントではないと判断された場合、処理はステップＳ１４に進められる。ステップＳ１４において、制御部６８は、ステップＳ３の判別結果がサスペンドであるか否かを判断し、サスペンドであると判断された場合、処理はステップＳ１５に進められる。

ステップＳ１５において、アプリエンジン７４は、制御部６８からの制御に従い、現在実行中のデータ放送用アプリの状態を示すデータ（すなわち、現在ワークメモリ７５Ａに書き込まれているデータ。表示する情報に階層構造がある場合、表示されている情報の階層を示す情報を含む）を退避メモリ７５Ｂに退避させる。この後、処理はステップＳ１に戻り、それ以降が繰り返される。

ステップＳ１４において、ステップＳ３の判別結果がサスペンドではないと判断された場合、ステップＳ３の判別結果はターミネートであるので、処理はステップＳ１６に進められる。ステップＳ１６において、アプリエンジン７４は、制御部６８からの制御に従い、App_idにより特定されるデータ放送用アプリが実行中であればそれを終了させる。ステップＳ１７において、アプリエンジン７４は、制御部６８からの制御に従い、App_idにより特定されるデータ放送用アプリに関するデータを、ワークメモリ７５Ａおよび退避メモリ７５Ｂから消去するとともに、データ放送用アプリを記録部７１またはキャッシュメモリ７３から消去させる。この後、処理はステップＳ１に戻り、それ以降が繰り返される。

以上でトリガ情報対応処理の説明を終了する。上述したトリガ情報対応処理によれば、テレビジョン放送のＡＶコンテンツ（番組、ＣＭなど）に連動してデータ放送用アプリを起動したり、イベントを発火させたり、終了したりすることができる。さらに、データ放送用アプリを実行中の状態を保持したままで休止させて、他のデータ情報用アプリを実行、終了し、その後、休止したデータ放送用アプリを休止状態から再開することができる。

[動作シナリオ]
上述したトリガ情報対応処理によれば、図２９に示すようなデータ放送用アプリの運用の可能である。

図２９は、データ放送用アプリの動作シナリオの一例を示している。

放送装置４１が番組の進行にあわせて、番組に対応するデータ放送用アプリの取得を指示するプリキャッシュコマンドのトリガ情報を送信すると、これを受信した受信装置６０では、データ放送用アプリが取得される。

次に、放送装置４１が番組の進行にあわせて、番組に対応するデータ放送用アプリのエクスキュートコマンドのトリガ情報を送信すると、これを受信した受信装置６０では、放送用アプリが起動される。この起動により、番組の映像に、データ放送用アプリの表示が用意されていることを示すアイコンが重畳表示される。

このアイコンをユーザが選択すると、番組の映像に画面上にデータ放送用アプリによる表示が重畳される。

放送装置４１が番組の進行にあわせて、インジェクトイベントコマンドのトリガ情報を送信すると、これを受信した受信装置６０では、実行中のデータ放送用アプリにおいてイベントが発火される（例えば、表示が変更される）。

そして、所定のタイミングにおいて、放送装置４１がデータ放送用アプリのサスペンドコマンドのトリガ情報を送信すると、これを受信した受信装置６０では、実行中のデータ放送用アプリが休止される（関連するデータは退避メモリ７５Ｂに保持される）。その後、放送装置４１がデータ放送用アプリのエクスキュートコマンドのトリガ情報を送信すると、これを受信した受信装置６０では、休止されていたデータ放送用アプリが再開される。

さらに、放送装置４１が番組の終了にあわせて、ターミネートコマンドのトリガ情報を送信すると、これを受信した受信装置６０では、実行中のデータ放送用アプリが終了される。

[データ放送用アプリの第１の状態遷移]
図３０は、５種類のコマンドの第１の例である、プリキャッシュ、エクスキュート、インジェクトイベント、サスペンド、およびターミネートの各コマンドに応じて受信装置６０にて動作するデータ放送用アプリの状態遷移図である。

同図に示すように、データ放送用アプリの状態は、終了状態(Stopped)、準備状態(Ready)、実行中状態(Active)、または休止状態(Suspended)の４種類のうちのいずれかに遷移していると定義される。

終了状態は、データ放送用アプリが受信装置６０に未取得である状態を指す。準備状態は、そのデータ放送用アプリが受信装置６０に取得済みであって起動されていない状態を指す。実行中状態は、データ放送用アプリが起動されて実行中である状態を指す。休止状態は、データ放送用アプリの実行が中断され、その中断したときの状態を示す情報が退避メモリ７５Ｂに保持されている状態を指す。

データ放送用アプリが終了状態に遷移しているとき（受信装置６０に未取得のとき）、プリキャッシュコマンドのトリガ情報が受信され、プリキャッシュコマンドに従ってそのデータ放送用アプリが取得されると、準備状態に遷移する。

データ放送用アプリが準備状態であるとき、エクスキュートコマンドのトリガ情報が受信され、エクスキュートコマンドに従ってそのデータ放送用アプリが起動されると、実行中状態に遷移する。

また、データ放送用アプリが終了状態に遷移しているとき（受信装置６０に未取得のとき）、エクスキュートコマンドのトリガ情報が受信され、エクスキュートコマンドに従ってそのデータ放送用アプリが取得されて起動されると、実行中状態に遷移する。

データ放送用アプリが実行中状態に遷移しているとき、サスペンドコマンドのトリガ情報が受信され、サスペンドコマンドに従って実行中のデータ放送用アプリが中断されると休止状態に遷移する。

データ放送用アプリが休止状態に遷移しているとき、エクスキュートコマンドのトリガ情報が受信され、エクスキュートコマンドに従って、中断されていたデータ放送用アプリが再開されると、実行中状態に遷移する。

データ放送用アプリが準備状態、実行中状態、または休止状態に遷移しているとき、ターミネートコマンドのトリガ情報が受信され、ターミネートコマンドに従って、実行中のデータ放送用アプリが終了されると、終了状態に遷移する。なお、終了状態への遷移は、ターミネートコマンドのトリガ情報に基づくものの他、トリガ情報のApp_expire_dateが経過したとき、他のデータ放送用アプリが実行されたとき、受信チャンネルが切り替えがApp_life_scopeを超えたときにも発生する。

[複数のデータ放送用アプリの状態遷移について]
次に、受信装置６０にて順次実行され得る複数のデータ放送用アプリの状態遷移について説明する。

図３１は、複数のデータ放送用アプリを順次実行させるときの運用シナリオの一例を示している。以下、３つのデータ放送用アプリをデータ放送用アプリＡ，Ｂ，Ｃと称する。

番組が開始されたとき、データ放送用アプリＡ，Ｂ，Ｃは全て終了(Stopped)状態である。そして、データ放送用アプリＡに対するエクスキュートコマンドが受信されると、データ放送用アプリＡが取得、起動され、データ放送用アプリＡは実行中(Active)状態となる。このとき、ワークメモリ７５Ａには、データ放送用アプリＡに関するデータが書き込まれている。

次に、データ放送用アプリＡに対するサスペンドコマンドが受信されると、ワークメモリ７５Ａに書き込まれていた、データ放送用アプリＡに関するデータが退避メモリ７５Ｂに移されて、データ放送用アプリＡが休止(Suspended)状態となる。この後、データ放送用アプリＢに対するエクスキュートコマンドが受信されると、データ放送用アプリＢが取得、起動され、データ放送用アプリＢが実行中状態となる。このとき、ワークメモリ７５Ａには、データ放送用アプリＢに関するデータが書き込まれる。

データ放送用アプリＢが実行中状態のとき、データ放送用アプリＣに対するプリキャッシュコマンドが受信されると、データ放送用アプリＣが取得されてデータ放送用アプリＣは準備状態となる。

次に、データ放送用アプリＡに対するエクスキュートコマンドが受信されると、データ放送用アプリＡは休止状態であるので、データ放送用アプリＡに関するデータが退避メモリ７５Ｂからワークメモリ７５Ａに移されてデータ放送用アプリＡが再開される。一方、データ放送用アプリＢは終了される。

この後、準備状態のデータ放送用アプリＣに対するエクスキュートコマンドが受信されると、データ放送用アプリＣが読み出されて起動され、データ放送用アプリＣは実行中状態となり、ワークメモリ７５Ａには、データ放送用アプリＣに関するデータが書き込まれる。一方、データ放送用アプリＡは終了される。

上述したように、受信装置６０においては複数のデータ放送用アプリを順次実行することができ、休止したデータ放送用アプリについても休止した状態から再開することができる。

＜２．第２の実施の形態＞
［５種類のコマンドの第２の例］
次に、第２の実施の形態について説明する。上述したように、第２の実施の形態における５種類のコマンドは、レジスタ(Register)、エクスキュート(Execute)、インジェクトイベント(Inject_event)、およびターミネート(Terminate)の各コマンドからなる。

図３２は、第２の実施の形態における、レジスタ(Register)コマンドとしてのトリガ情報に含まれる項目を示している。レジスタコマンドは、受信装置６０に対して、データ放送用アプリの取得と登録を指示するためのコマンドである。

すなわち、データ放送用アプリの取得を指示する点については、第１の実施の形態におけるプリキャッシュコマンドと同様であるが、その登録も指示する点が異なる。ここで、データ放送用アプリの登録とは、取得したデータ放送用アプリに対応付けて、その優先度(Persistent_priority)と保持期限(Expire_date)を記憶することを意味する。記憶されたデータ放送用アプリは、制御部６８により、優先度と保持期限に従って管理される（詳細後述）。

Trigger_id，Protcol_version，Command_code，Trigger_varidity，App_type，App_life_scopeについては、図２０に示されたプリキャッシュコマンドとしてのトリガ情報と同様である。ただし、Command_codeには、レジスタコマンドであることを示す情報が記載される。

第２の実施の形態におけるApp_idは、当該トリガ情報に対応して取得するデータ放送用アプリの識別情報であるとともにその取得先（いまの場合、サーバ４２）のURLも示している。換言すれば、データ放送用アプリの取得先がその識別情報にも流用されてApp_idとされている。したがって、レジスタコマンドとしてのトリガ情報には、図２０に示されたプリキャッシュコマンドとしてのトリガ情報に存在していたApp_urlの項目が省かれている。ただし、App_urlをレジスタコマンドとしてのトリガ情報に含めるようにしても構わない。

Persistent_priorityは、対応するデータ放送用アプリを取得、保持するときの優先度を示している。いまの場合、Persistent_priorityに対して２ビットが割り当てられているので、４段階の優先度を付与することができる。対応するデータ放送用アプリを取得、保持するときに記録部７１にそれを保持するだけの記録容量が残っていない場合、対応するデータ放送用アプリよりも優先度の低いものを記録部７１から消去して記録容量を確保するようにする。対応するデータ放送用アプリよりも優先度の低いものが記録部７１に保持されていない場合、対応するデータ放送用アプリは取得されない。ただし、可能であれば、取得してキャッシュメモリ７３に一時的に保持するようにしてもよい。

Expire_dateは、記録部７１に保持した対応するデータ放送用アプリの保持期限を示す。保持期限が経過した場合、対応するデータ放送用アプリは記録部７１から消去される。

図３３は、第２の実施の形態における、エクスキュート(Execute)コマンドとしてのトリガ情報に含まれる項目を示している。エクスキュートコマンドは、受信装置６０に対して、データ放送用アプリの起動を指示するためのコマンドである。

エクスキュートコマンドとしてのトリガ情報に含まれる項目は、図３２に示されたレジスタコマンドとしてのトリガ情報に含まれる項目と同様である。ただし、Command_codeには、エクスキュートコマンドであることを示す情報が記載される。

図３４は、第２の実施の形態における、インジェクトイベント(Inject_event)コマンドとしてのトリガ情報に含まれる項目を示している。エクスキュートコマンドは、受信装置６０に対して、データ放送用アプリの起動を指示するためのコマンドである。

第２の実施の形態における、インジェクトイベントコマンドとしてのトリガ情報に含まれる項目は、図２２に示された第１の実施の形態におけるそれと同様である。ただし、App_idに割り当てられているビット数が異なる。

図３５は、第２の実施の形態における、サスペンド(Suspend)コマンドとしてのトリガ情報に含まれる項目を示している。サスペンドコマンドは、受信装置６０に対して、実行中のデータ放送用アプリを休止させるためのコマンドである。

第２の実施の形態における、サスペンドコマンドとしてのトリガ情報に含まれる項目は、図２３に示された第１の実施の形態におけるそれと同様である。ただし、App_idに割り当てられているビット数と、App_typeが省略されている点が異なる。

図３６は、第２の実施の形態における、ターミネート(Terminate)コマンドとしてのトリガ情報に含まれる項目を示している。ターミネートコマンドは、受信装置６０に対して、実行中のデータ放送用アプリを休止させるためのコマンドである。

第２の実施の形態における、ターミネートコマンドとしてのトリガ情報に含まれる項目は、図２４に示された第１の実施の形態におけるそれと同様である。ただし、App_idに割り当てられているビット数と、App_typeが省略されている点が異なる。

図３７は、上述した各コマンドの第２の実施の形態としてのトリガ情報に対応可能なトリガ情報のシンタックスの一例を示している。なお、トリガ情報のシンタックスは任意であって、図３７の例に限定されるものではない。

[アプリケーション登録管理処理の説明]
第２の実施の形態における受信装置６０によるトリガ対応処理は、上述した第１の実施の形態におけるトリガ対応処理と略同様である。相違点は、第１の実施の形態におけるトリガ対応処理では、プリキャッシュコマンドとしてのトリガ情報を受信したことに応じてデータ放送用アプリを取得、記憶する（図２８のステップＳ５）が、第２の実施の形態では、レジスタコマンドとしてのトリガ情報を受信したことに応じてアプリケーション登録管理処理を実行する。すなわち、アプリケーション登録管理処理は、図２８のステップＳ５の代わりに実行されるものである。

図３８は、このアプリケーション登録管理処理を説明するフローチャートである。アプリケーション登録管理処理は、受信したトリガ情報がレジスタコマンドであると判断された場合に開始される。

ステップＳ３１において、制御部６８は、トリガ情報で指定されているデータ放送用アプリを保持するための記録容量が記録部７１に残っているか否かを判定し、残っていると判定した場合、処理はステップＳ３４に進められる。反対に、残っていないと判定された場合、処理はステップＳ３２に進められる。

ステップＳ３２において、制御部６８は、記録部７１に保持されている（すなわち、既に登録済みの）データ放送用アプリのうち、その優先度がトリガ情報で指定されているデータ放送用アプリの優先度よりも低いものを記録部７１から消去させる。ステップＳ３３において、制御部６８は、トリガ情報で指定されているデータ放送用アプリを保持するための記録容量が記録部７１に確保できたか否かを判定し、確保できたと判定した場合、処理をステップＳ３４に進める。反対に、確保できなかったと判定された場合、対応するデータ放送用アプリは取得されずにアプリケーション登録管理処理は終了される。

ステップＳ３４において、制御部６８は、トリガ情報のApp_idが示すデータ放送用アプリの取得先からデータ放送用アプリを取得させて記録部７１に保持させる。ステップＳ３５において、制御部６８は、取得、保持させたデータ放送用アプリを登録する（データ放送用アプリに、その優先度と保持期限を対応付けて管理する）。以上で、アプリケーション登録管理処理は終了される。

なお、登録されたデータ放送用アプリについては、その保持期限が経過したときに記録部７１から消去される。これにより、当該データ放送用アプリの登録は抹消される。

[データ放送用アプリの第２の状態遷移について]
図３９は、第２の実施の形態における５種類のコマンドである、レジスタ、エクスキュート、インジェクトイベント、サスペンド、およびターミネートの各コマンドとしてのトリガ情報に応じて受信装置６０にて動作するデータ放送用アプリの状態遷移図である。同図に示すように、データ放送用アプリの状態は、解放状態(Released)、準備状態(Ready)、実行中状態(Active)、または休止状態(Suspended)の４種類のうちのいずれかに遷移していると定義される。

解放状態は、データ放送用アプリが受信装置６０に未取得である状態を指す。準備状態は、そのデータ放送用アプリが受信装置６０に登録済みであって起動されていない状態を指す。実行中状態は、データ放送用アプリが起動されて実行中である状態を指す。休止状態は、データ放送用アプリの実行が中断され、その中断したときの状態を示す情報が退避メモリ７５Ｂに保持されている状態を指す。

図４０は、各コマンドと状態遷移の関係を示している。

データ放送用アプリが解放状態に遷移しているとき（受信装置６０に未取得のとき）、レジスタコマンドのトリガ情報に応じて、そのデータ放送用アプリが取得、保持され、登録されると準備状態に遷移する。

データ放送用アプリが準備状態であるとき、エクスキュートコマンドのトリガ情報に応じて、そのデータ放送用アプリが起動されると実行中状態に遷移する。

また、データ放送用アプリが解放状態に遷移しているとき（受信装置６０に未取得のとき）、エクスキュートコマンドのトリガ情報に応じて、そのデータ放送用アプリが取得、登録され、起動されると実行中状態に遷移する。

データ放送用アプリが実行中状態に遷移しているとき、サスペンドコマンドのトリガ情報に応じて、実行中のデータ放送用アプリが中断されると休止状態に遷移する。

また、データ放送用アプリが実行中状態に遷移しているとき、ターミネートコマンドのトリガ情報に応じて、実行中のデータ放送用アプリが終了されると準備状態に遷移する。なお、映像の切替がApp_life_scopeを外れた場合、または他のデータ放送用アプリが起動された場合にも準備状態に遷移する。

データ放送用アプリが休止状態に遷移しているとき、エクスキュートコマンドのトリガ情報に応じて、中断されていたデータ放送用アプリが再開されると、実行中状態に遷移する。

また、データ放送用アプリが休止状態に遷移しているとき、ターミネートコマンドのトリガ情報に応じて、データ放送用アプリは準備状態に遷移する。

データ放送用アプリが準備状態、実行中状態、または休止状態に遷移しているとき、当該データ放送用アプリの保持期限が経過すると、当該データ放送用アプリが記録部７１から消去され、登録が抹消されて解放状態に遷移する。

[データ放送用アプリのライフサイクル]
第１の実施の形態の場合、１度起動されたデータ放送用アプリが終了されると記録部７１から消去されていた。これに対して、第２の実施の形態の場合、登録されたデータ放送用アプリは起動、終了されても、保持期限が経過するまで消去されない。したがって、登録されたデータ放送用アプリは、図４１に示されるような、複数回に亘って起動、終了されるような運用が可能となる。ただし、優先度が低いデータ放送用アプリについては、記録部７１の容量が不足したときに保持期限に関係なく消去されることがある。

図４１は、第２の実施の形態にて可能なデータ放送用アプリの３種類のライフサイクルを示している。

同図のＡは、１回だけ起動、終了されるデータ放送用アプリのライフサークルを示している。このデータ放送用アプリは、エクスキュートコマンドに応じて登録、起動され、ターミネートコマンドに応じて終了され、準備状態に遷移する。その後、保持期限が経過すると記録部７１から消去される。

同図のＢは、登録され、複数回起動、終了されるデータ放送用アプリのライフサークルを示している。このデータ放送用アプリは、レジスタコマンドに応じて取得、保持されて登録され、エクスキュートコマンドに応じて起動され、ターミネートコマンドに応じて終了され、準備状態に遷移する。この後、再びエクスキュートコマンドに応じて起動され、ターミネートコマンドに応じて終了され、準備状態に遷移する。その後、保持期限が経過すると記録部７１から消去される。

同図のＣは、休止状態に遷移されるデータ放送用アプリのライフサークルを示している。このデータ放送用アプリは、レジスタコマンドに応じて取得、保持されて登録され、エクスキュートコマンドに応じて起動され、サスペンドコマンドに応じて休止状態に遷移する。その後、エクスキュートコマンドに応じて再開され、ターミネートコマンドに応じて終了され、準備状態に遷移する。その後、保持期限が経過すると記録部７１から消去される。

[複数のデータ放送用アプリの運用]
以上においては、データ放送用アプリがエクスキュートコマンドとしてのトリガ情報に応じて起動される場合のみを説明したが、エクスキュートコマンドとしてのトリガ情報を用いることなくデータ放送用アプリを起動させることが可能である。具体的には、図４２に示されるように、エクスキュートコマンドに応じて起動されるデータ放送用アプリApp0の内部に、他のデータ放送用アプリApp1，App2などを起動させるための関数を記述しておけばよい。これにより、データ放送用アプリApp0の進行状況やデータ放送用アプリApp0に対するユーザの操作などに応じて、データ放送用アプリApp1などを起動させることができる。

図４３は、３つのデータ放送用アプリapp0，app1，app2を連携して起動させる運用の例を示している。

初めに、データ放送用アプリapp0に対するエクスキュートコマンドとしてのトリガ情報、データ放送用アプリapp1に対するレジスタコマンドとしてのトリガ情報、およびデータ放送用アプリapp2に対するレジスタコマンドとしてのトリガ情報が放送される。これらを受信した受信装置６０では、データ放送用アプリapp0が取得、登録されて起動される。実行されたデータ放送用アプリapp0の画面には、データ放送用アプリapp1，app2にそれぞれ対応するアイコンが表示される。これと同時に、データ放送用アプリapp1，app2が取得、登録される。

ユーザがデータ放送用アプリapp0の画面に表示されたデータ放送用アプリapp1に対応するアイコンを選択した場合、実行中のデータ放送用アプリapp0が終了されるとともに、データ放送用アプリapp1が起動される。この後は、実行中のデータ放送用アプリapp1に対するインジェクトイベントコマンド、サスペンドコマンド、エクスキュートコマンド、ターミネートコマンドにそれぞれ対応して、データ放送用アプリapp1のイベント発火、休止、再開、終了が行われる。

ユーザがデータ放送用アプリapp0の画面に表示されたデータ放送用アプリapp2に対応するアイコンを選択した場合、実行中のデータ放送用アプリapp0が終了されるとともに、データ放送用アプリapp2が起動される。この後は、実行中のデータ放送用アプリapp2に対するインジェクトイベントコマンド、ターミネートコマンドにそれぞれ対応して、データ放送用アプリapp2のイベント発火、終了が行われる。

上記運用によれば、エクスキュートコマンドとしてのトリガ情報を用いることなく複数のデータ放送用アプリを連携させて起動させることが可能である。

以上に説明したように、第１および第２の実施の形態のいずれにおいても、番組、ＣＭなどのＡＶコンテンツに連動させてデータ放送用アプリに関する処理を実行させることができる。

さらに、デジタルテレビジョン番組がCATV網や衛星通信網などを介して再送信される場合においても、テレビジョン番組に連動し得るデータ放送用コンテンツのサービスを実現することができる。

ところで、上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、プログラム記録媒体からインストールされる。

図４４は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。

このコンピュータ１００において、CPU（Central Processing Unit）１０１，ROM（Read Only Memory）１０２，RAM（Random Access Memory）１０３は、バス１０４により相互に接続されている。

バス１０４には、さらに、入出力インタフェース１０５が接続されている。入出力インタフェース１０５には、キーボード、マウス、マイクロホンなどよりなる入力部１０６、ディスプレイ、スピーカなどよりなる出力部１０７、ハードディスクや不揮発性のメモリなどよりなる記憶部１０８、ネットワークインタフェースなどよりなる通信部１０９、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１を駆動するドライブ１１０が接続されている。

以上のように構成されるコンピュータでは、CPU１０１が、例えば、記憶部１０８に記憶されているプログラムを、入出力インタフェース１０５及びバス１０４を介して、RAM１０３にロードして実行することにより、上述した一連の処理が行われる。

なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであってもよいし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであってもよい。

また、プログラムは、１台のコンピュータにより処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであってもよい。

また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。

なお、本開示における実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。

３０ 放送システム， ４１ 放送装置， ５１ 制御部， ５２ ビデオエンコーダ， ５３ オーディオエンコーダ， ５４ 多重化部， ５５ 送出部， ４２ サーバ， ５９ 再生装置， ６０ 受信装置， ６１ チューナ， ６２ 多重分離部， ６３ オーディオデコーダ， ６４ 音声出力部， ６５ ビデオデコーダ， ６６ トリガ検出部， ６７ 映像出力部， ６８ 制御部， ６９ メモリ， ７０ 操作部， ７１ 記録部， ７２ 通信I/F， ７３ キャッシュメモリ， ７４ アプリエンジン， ７５ メモリ， ７５Ａ ワークメモリ， ７５Ｂ 退避メモリ

Claims (16)

1. 受信装置においてコンテンツに連動して実行させるためのアプリケーションプログラムの制御に関するトリガ情報が埋め込まれた符号化オーディオストリームを生成する音声符号化部と、
   生成された前記符号化オーディオストリームを、前記受信装置に送信する送信部と
   を備える送信装置。
2. 前記トリガ情報を格納したメタデータとともに、前記メタデータを前記符号化オーディオストリームのユーザデータ領域に埋め込むためのサイズ情報を供給して、前記ユーザデータ領域に前記メタデータの埋め込みが行われるように制御する制御部をさらに備える
   請求項１に記載の送信装置。
3. 前記音声符号化部は、オーディオストリームをAC3（Audio Code number 3）方式により符号化して、前記符号化オーディオストリームを生成し、
   前記メタデータは、前記AC3方式のフレーム構造におけるAUX（AUXILIARY DATA）の領域に挿入される
   請求項２に記載の送信装置。
4. 前記音声符号化部は、オーディオストリームをAAC（Advanced Audio Coding）方式により符号化して、前記符号化オーディオストリームを生成し、
   前記メタデータは、前記AAC方式のフレーム構造におけるDSE（Data Stream Element）の領域に挿入される
   請求項２に記載の送信装置。
5. ビデオストリームを符号化して、符号化ビデオストリームを生成する映像符号化部と、
   前記符号化オーディオストリームと前記符号化ビデオストリームを多重化して、多重化ストリームを生成する多重化部と
   をさらに備え、
   前記送信部は、生成された前記多重化ストリームを送信する
   請求項１に記載の送信装置。
6. 前記メタデータには、情報のタイプを示すタイプ情報が付加されている
   請求項１に記載の送信装置。
7. 前記メタデータには、情報識別子で区別された複数種類の情報が含まれる
   請求項１に記載の送信装置。
8. コンテンツを送信する送信装置の送信方法において、
   受信装置においてコンテンツに連動して実行させるためのアプリケーションプログラムの制御に関するトリガ情報が埋め込まれた符号化オーディオストリームを生成し、
   生成された前記符号化オーディオストリームを、前記受信装置に送信する
   ステップを含む送信方法。
9. コンテンツを送信する送信装置の制御用のプログラムであって、
   受信装置においてコンテンツに連動して実行させるためのアプリケーションプログラムの制御に関するトリガ情報が埋め込まれた符号化オーディオストリームを生成し、
   生成された前記符号化オーディオストリームを、前記受信装置に送信する
   ステップを含む処理を送信装置のコンピュータに実行させるプログラム。
10. 送信装置から送信される、コンテンツに連動して実行させるためのアプリケーションプログラムの制御に関するトリガ情報が埋め込まれた符号化オーディオストリームを受信する受信部と、
    受信された前記符号化オーディオストリームを復号する音声復号部と、
    前記符号化オーディオストリームを復号して得られるトリガ情報に応じて、前記コンテンツに連動して実行させるアプリケーションプログラムに関する処理を制御する制御部と
    を備える受信装置。
11. 前記音声復号部は、AC3方式により符号化された符号化オーディオストリームのフレーム構造におけるAUXの領域から、メタデータに格納された前記トリガ情報を取得する
    請求項１０に記載の受信装置。
12. 前記音声復号部は、AAC方式により符号化された符号化オーディオストリームのフレーム構造におけるDSEの領域から、メタデータに格納された前記トリガ情報を取得する
    請求項１０に記載の受信装置。
13. 受信された多重化ストリームを多重分離する多重分離部と、
    前記多重化ストリームから分離された符号化ビデオストリームを復号する映像復号部と
    をさらに備え、
    前記音声復号部は、前記多重化ストリームから分離された符号化オーディオストリームを復号する
    請求項１０に記載の受信装置。
14. コンテンツを受信する受信装置の受信方法において、
    送信装置から送信される、コンテンツに連動して実行させるためのアプリケーションプログラムの制御に関するトリガ情報が埋め込まれた符号化オーディオストリームを受信し、
    受信された前記符号化オーディオストリームを復号し、
    前記符号化オーディオストリームを復号して得られるトリガ情報に応じて、前記コンテンツに連動して実行させるアプリケーションプログラムに関する処理を制御する
    ステップを含む受信方法。
15. コンテンツを受信する受信装置の制御用のプログラムであって、
    送信装置から送信される、コンテンツに連動して実行させるためのアプリケーションプログラムの制御に関するトリガ情報が埋め込まれた符号化オーディオストリームを受信し、
    受信された前記符号化オーディオストリームを復号し、
    前記符号化オーディオストリームを復号して得られるトリガ情報に応じて、前記コンテンツに連動して実行させるアプリケーションプログラムに関する処理を制御する
    ステップを含む処理を受信装置のコンピュータに実行させるプログラム。
16. コンテンツを送信する送信装置と、送信されたコンテンツを受信する受信装置からなる放送システムにおいて、
    前記送信装置は、
    前記受信装置においてコンテンツに連動して実行させるためのアプリケーションプログラムの制御に関するトリガ情報が埋め込まれた符号化オーディオストリームを生成する音声符号化部と、
    生成された前記符号化オーディオストリームを、前記受信装置に送信する送信部と
    を備え、
    前記受信装置は、
    前記送信装置から送信される、前記符号化オーディオストリームを受信する受信部と、
    受信された前記符号化オーディオストリームを復号する音声復号部と、
    前記符号化オーディオストリームを復号して得られるトリガ情報に応じて、前記コンテンツに連動して実行させるアプリケーションプログラムに関する処理を制御する制御部と
    を備える
    放送システム。

Images