特許 6298483 受信装置および受信方法、並びに送信装置および送信方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6298483

(24)【登録日】2018年3月2日

(45)【発行日】2018年3月20日

(54)【発明の名称】受信装置および受信方法、並びに送信装置および送信方法

(51)【国際特許分類】

   H04N 21/2362 20110101AFI20180312BHJP

   H04N 21/435 20110101ALI20180312BHJP

   H04H 20/28 20080101ALI20180312BHJP

   H04H 60/13 20080101ALI20180312BHJP

【ＦＩ】

   H04N21/2362

   H04N21/435

   H04H20/28

   H04H60/13

【請求項の数】9

【全頁数】34

(21)【出願番号】特願2016-50376(P2016-50376)

(22)【出願日】2016年3月15日

(62)【分割の表示】特願2012-531797(P2012-531797)の分割

【原出願日】2011年8月22日

(65)【公開番号】特開2016-154344(P2016-154344A)

(43)【公開日】2016年8月25日

【審査請求日】2016年3月15日

(31)【優先権主張番号】13/080,866

(32)【優先日】2011年4月6日

(33)【優先権主張国】US

(31)【優先権主張番号】61/383,244

(32)【優先日】2010年9月15日

(33)【優先権主張国】US

(31)【優先権主張番号】61/378,239

(32)【優先日】2010年8月30日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】316009762

【氏名又は名称】サターン ライセンシング エルエルシー

【氏名又は名称原語表記】Ｓａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ

(74)【代理人】

【識別番号】100121131

【弁理士】

【氏名又は名称】西川 孝

(74)【代理人】

【識別番号】100082131

【弁理士】

【氏名又は名称】稲本 義雄

(72)【発明者】

【氏名】北里 直久

(72)【発明者】

【氏名】出葉 義治

(72)【発明者】

【氏名】山岸 靖明

【審査官】 松元 伸次

(56)【参考文献】

【文献】 特表２００４−５０７９８８（ＪＰ，Ａ）

【文献】 特開２０１０−０３４８９３（ＪＰ，Ａ）

【文献】 特表２０１０−５２４２７１（ＪＰ，Ａ）

【文献】 特開２０１１−０６６５５６（ＪＰ，Ａ）

【文献】 特表２００９−５４０７０４（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｈ２０／００−２０／４６

２０／５１−２０／８６

２０／９１−４０／２７

４０／９０−６０／９８

Ｈ０４Ｎ７／１０

７／１４−７／１７３

７／２０−７／５６

２１／００−２１／８５８

(57)【特許請求の範囲】

【請求項1】

テレビジョン放送信号の受信状態で動作するアプリケーションを制御するアプリケーション制御情報に基づいて、前記アプリケーションに対する処理を行う処理部と、
前記アプリケーションを蓄積する蓄積部と
を備え、
前記アプリケーション制御情報は、前記アプリケーションを識別するアプリケーション識別子、および前記アプリケーションの取得先と前記取得先毎の前記アプリケーションの利用の可否とを表す取得先情報を含むように構成され、
前記処理部は、前記アプリケーション識別子と前記取得先情報に基づいて、前記蓄積部、前記テレビジョン放送信号、サーバの順に、前記アプリケーションの取得処理を行う
受信装置。

【請求項2】

前記処理部は、前記テレビジョン放送信号を監視し、前記テレビジョン放送信号に含まれる前記アプリケーション制御情報が更新された場合、前記処理を行う
ように構成された
請求項１に記載の受信装置。

【請求項3】

前記アプリケーション識別子は、URLの一部を含む
ように構成された
請求項１に記載の受信装置。

【請求項4】

前記アプリケーション制御情報は、前記アプリケーションの有効期限を含む
ように構成された
請求項１に記載の受信装置。

【請求項5】

受信装置が、
テレビジョン放送信号の受信状態で動作するアプリケーションを制御するアプリケーション制御情報に基づいて、前記アプリケーションに対する処理を行う処理ステップ
を含み、
前記アプリケーション制御情報は、前記アプリケーションを識別するアプリケーション識別子、および前記アプリケーションの取得先と前記取得先毎の前記アプリケーションの利用の可否とを表す取得先情報を含むように構成され、
前記アプリケーション識別子と前記取得先情報に基づいて、前記アプリケーションを蓄積する蓄積部、前記テレビジョン放送信号、サーバの順に、前記アプリケーションの取得処理を行う
受信方法。

【請求項6】

テレビジョン放送信号の受信状態で動作するアプリケーションを制御するアプリケーション制御情報を送信する送信部
を備え、
前記アプリケーション制御情報は、受信装置が、前記アプリケーションを蓄積する蓄積部、前記テレビジョン放送信号、サーバの順に、前記アプリケーションの取得を行うために、前記アプリケーションを識別するアプリケーション識別子、および前記アプリケーションの取得先と前記取得先毎の前記アプリケーションの利用の可否とを表す取得先情報を含むように構成される
送信装置。

【請求項7】

前記アプリケーション識別子は、URLの一部を含む
ように構成された
請求項６に記載の送信装置。

【請求項8】

前記アプリケーション制御情報は、前記アプリケーションの有効期限を含む
ように構成された
請求項６に記載の送信装置。

【請求項9】

送信装置が、
テレビジョン放送信号の受信状態で動作するアプリケーションを制御するアプリケーション制御情報を送信する送信ステップ
を含み、
前記アプリケーション制御情報は、受信装置が、前記アプリケーションを蓄積する蓄積部、前記テレビジョン放送信号、サーバの順に、前記アプリケーションの取得を行うために、前記アプリケーションを識別するアプリケーション識別子、および前記アプリケーションの取得先と前記取得先毎の前記アプリケーションの利用の可否とを表す取得先情報を含むように構成される
送信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、受信装置および受信方法、並びに送信装置および送信方法に関し、特に、例えば、テレビジョン放送信号の受信状態で動作するアプリケーションを制御するアプリケーション制御情報を送信できるようにした受信装置および受信方法、並びに送信装置および送信方法に関する。

【背景技術】

【0002】

従来、例えば、コンピュータに内蔵されるハードディスク等の記録媒体からファイルを取得する（読み出す）場合、記録媒体に格納されている複数のファイルのうち、取得対象のファイルを指定する必要がある。取得対象のファイルは、例えば、文字列によりファイルの格納場所を示す名前空間「file://<directory_name>/<file_name>」により指定される。

【0003】

また、例えば、インターネットに接続されているサーバからファイルを取得する場合、サーバに記録されている複数のファイルのうち、取得対象のファイルを指定する必要がある。取得対象のファイルは、例えば、名前空間「http://<domain_name>/<file_name>」により指定される。

【0004】

さらに、例えば、デジタルテレビジョン放送等により放送されるデジタルテレビジョン放送信号からファイルを取得する場合、デジタルテレビジョン放送信号に格納されている複数のファイルのうち、取得対象のファイルを指定する必要がある。取得対象のファイルは、例えば、名前空間「arib://<network_id>.<org_ts_id>.<service_id>/<component_tag>/<module_id>/<file_name>」により指定される。

【0005】

上述のように、従来においては、ファイルの取得先に応じて、異なる名前空間を用いる必要があり、非常に煩雑となっていた。

【0006】

そこで、異なる名前空間毎に、その名前空間を一意に識別するためのファイルＩＤを対応付けるようにして、ファイルの取得先に拘らず、ファイルＩＤのみでファイルを指定できるようにしたファイルＩＤ参照技術が提案されている（例えば、特許文献１参照）。

【0007】

このファイルＩＤ参照技術では、例えば、図１に示されるように、端末１１において、ファイルサーバ１３に格納されているファイルの名前空間に対応するファイルＩＤが指定されると、そのファイルＩＤに対応する名前空間を通知するように、ロケーション解決サーバ１２に対して要求する。

【0008】

これに対して、ロケーション解決サーバ１２は、端末１１からの要求に応じて、ファイルサーバ１３に格納されているファイルの名前空間を、端末１１に通知する。端末１１では、通知された名前空間を用いて、ファイルサーバ１３からファイルを取得する。なお、ロケーション解決サーバ１２は、各ファイルＩＤ毎に、対応する名前空間を対応付けて保持しているものとする。

【0009】

ファイルＩＤ参照技術において、端末１１は、ファイルの取得先に拘らず、ファイルＩＤのみでファイルを指定することができるものの、取得対象のファイルを取得する際には必ず、ロケーション解決サーバ１２にアクセスするという複雑な処理を行なわなければならなかった。このため、端末１１乃至ファイルサーバ１３により構成される通信システムの運用が複雑なものとなってしまっていた。

【先行技術文献】

【特許文献】

【0010】

【特許文献1】特開２００２−２２９８８１号公報

【発明の概要】

【発明が解決しようとする課題】

【0011】

ところで、テレビジョン放送信号の受信状態で動作するアプリケーションを制御するアプリケーション制御情報を送信することは考えられていなかった。

【0012】

本発明は、このような状況に鑑みてなされたものであり、テレビジョン放送信号の受信状態で動作するアプリケーションを制御するアプリケーション制御情報を送信できるようにしたものである。

【課題を解決するための手段】

【0013】

本発明の第１の側面の受信装置は、テレビジョン放送信号の受信状態で動作するアプリケーションを制御するアプリケーション制御情報に基づいて、前記アプリケーションに対する処理を行う処理部と、前記アプリケーションを蓄積する蓄積部とを備え、前記アプリケーション制御情報は、前記アプリケーションを識別するアプリケーション識別子、および前記アプリケーションの取得先と前記取得先毎の前記アプリケーションの利用の可否とを表す取得先情報を含むように構成され、前記処理部は、前記アプリケーション識別子と前記取得先情報に基づいて、前記蓄積部、前記テレビジョン放送信号、サーバの順に、前記アプリケーションの取得処理を行う。

【0014】

本発明の第１の側面の受信方法は、本発明の第１の側面の受信装置に対応する。

【0015】

本発明の第１の側面においては、テレビジョン放送信号の受信状態で動作するアプリケーションを制御するアプリケーション制御情報に基づいて、前記アプリケーションに対する処理が行われ、前記アプリケーションが蓄積部に蓄積される。そして、前記アプリケーション制御情報が、前記アプリケーションを識別するアプリケーション識別子、および前記アプリケーションの取得先と前記取得先毎の前記アプリケーションの利用の可否とを表す取得先情報を含むように構成され、前記アプリケーション識別子と前記取得先情報に基づいて、前記蓄積部、前記テレビジョン放送信号、サーバの順に、前記アプリケーションの取得処理が行われる。

【0016】

本発明の第２の側面の送信装置は、テレビジョン放送信号の受信状態で動作するアプリケーションを制御するアプリケーション制御情報を送信する送信部を備え、前記アプリケーション制御情報は、受信装置が、前記アプリケーションを蓄積する蓄積部、前記テレビジョン放送信号、サーバの順に、前記アプリケーションの取得を行うために、前記アプリケーションを識別するアプリケーション識別子、および前記アプリケーションの取得先と前記取得先毎の前記アプリケーションの利用の可否とを表す取得先情報を含むように構成される。

【0017】

本発明の第２の側面の送信方法は、本発明の第２の側面の送信装置に対応する。

【0018】

本発明の第２の側面においては、テレビジョン放送信号の受信状態で動作するアプリケーションを制御するアプリケーション制御情報が送信される。そして、前記アプリケーション制御情報が、受信装置が、前記アプリケーションを蓄積する蓄積部、前記テレビジョン放送信号、サーバの順に、前記アプリケーションの取得を行うために、前記アプリケーションを識別するアプリケーション識別子、および前記アプリケーションの取得先と前記取得先毎の前記アプリケーションの利用の可否とを表す取得先情報を含むように構成される。

【発明の効果】

【0019】

本発明の第１の側面によれば、テレビジョン放送信号の受信状態で動作するアプリケーションを制御するアプリケーション制御情報に基づいて、アプリケーションに対する処理を行うことができる。

【0020】

また、本発明の第２の側面によれば、テレビジョン放送信号の受信状態で動作するアプリケーションを制御するアプリケーション制御情報を送信することができる。

【図面の簡単な説明】

【0021】

【図1】従来のロケーション解決サーバを用いる場合の一例を示すブロック図である。

【図2】第１の実施の形態である放送システムの構成例を示すブロック図である。

【図3】データ放送用コンテンツの表示例を示す図である。

【図4】受信装置の構成例を示すブロック図である。

【図5】トリガ信号がＴＳのPCRパケットに格納されて送信される場合の概念を示す図である。

【図6】トリガ信号の構成例を示す図である。

【図7】コマンドコードがアプリ起動である場合に、トリガ信号に含まれる項目の一例を示す図である。

【図8】コマンドコードがアプリイベントである場合に、トリガ信号に含まれる項目の一例を示す図である。

【図9】ＡＶコンテンツ及びデータ放送用コンテンツの一例を示す図である。

【図10】トリガ信号に基づいて画面表示を変更させる場合の一例を示す図である。

【図11】トリガ信号のアプリケーションリファレンスに含まれる項目の一例を示す図である。

【図12】エントリアプリファイルの一例を示す図である。

【図13】トリガ信号対応処理を説明するためのフローチャートである。

【図14】ファイル取得処理を説明するためのフローチャートである。

【図15】デジタルテレビジョン放送信号の構成例を示す図である。

【図16】FLUTEによるファイル伝送プロトコルスタックの一例を示す図である。

【図17】FLUTEによるファイル伝送方法の一例を示す図である。

【図18】「ＦＤＴ」の一例を示す図である。

【図19】ＦＤＴをXML言語により記述した場合の一例を示す図である。

【図20】階層構造により、コンテンツ及びファイルを記憶するストレージの一例を示す図である。

【図21】エントリアプリファイルの一例を示す他の図である。

【図22】トリガ信号のアプリケーションリファレンスに含まれる項目の一例を示す他の図である。

【図23】トリガ信号を受信した場合に実行されるイベントの第１の例を示す図である。

【図24】トリガ信号を受信した場合に実行されるイベントの第２の例を示す図である。

【図25】イベントの実行時に、複数の取得先のいずれかからデータを取得することを示す図である。

【図26】トリガ信号を受信した場合に実行されるイベントの第３の例を示す図である。

【図27】コンピュータの構成例を示すブロック図である。

【発明を実施するための形態】

【0022】

＜１．第１の実施の形態＞
［放送システムの構成例］
図２は、第１の実施の形態である放送システム３０を示している。この放送システム３０は、例えば現状の米国において、いわゆるデータ放送のサービスを実現するために取得されるファイルの取得先に拘らず、同一の名前空間を用いてファイルを取得できるようにするものである。

【0023】

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

【0024】

放送装置４１は、デジタルテレビジョン放送信号を送信（放送）するようになされている。このデジタルテレビジョン放送信号には、テレビジョン番組に相当するＡＶコンテンツや、データ放送のサービスに相当するデータ放送用コンテンツが含まれる。

【0025】

なお、ＡＶコンテンツは、テレビジョン番組を表示するために必要な信号により構成されており、データ放送用コンテンツは、データ放送のサービスを実現するために必要なファイルにより構成されている。このことは、図９を参照して後述する。

【0026】

また、放送装置４１において、データ放送用コンテンツの送信には、FLUTEによるファイル伝送方法が用いられる。FLUTEによるファイル伝送方法については、図１５乃至図１９を参照して後述する。

【0027】

さらに、放送装置４１は、所定のタイミングで、デジタルテレビジョン放送信号のＴＳ（トランスポートストリーム）を構成するＴＳパケットのうちのPCR(Program Clock Reference)を含むパケット（以下、PCRパケットという）にトリガ信号を格納して送信する。

【0028】

ここで、トリガ信号とは、データ放送用コンテンツの実行タイミングを示す情報、データ放送用コンテンツの取得先を示す情報などからなる。トリガ信号については、図５乃至図８を参照して後述する。

【0029】

なお、トリガ信号は、PCRパケットに格納する他、いわゆる透かし（watermark）として、デジタルテレビジョン放送信号に対応する映像信号そのものに、ユーザが認知できない形で埋め込むようにしてもよい。

【0030】

その他、例えば、デジタルテレビジョン放送信号として、複数のピクチャにより構成される動画像が放送される場合には、各ピクチャ毎に定義されているユーザ定義領域（例えば、MPEG2のユーザデータ等）に、トリガ信号を格納するようにしてもよい。

【0031】

トリガ信号が、デジタルテレビジョン放送信号に対応する映像信号に埋め込まれて送信される場合には、受信装置６０において、映像信号からトリガ信号が抽出される。また、トリガ信号が、ピクチャのユーザ定義領域に格納されて送信される場合には、受信装置６０において、ユーザ定義領域からトリガ信号が抽出される。

【0032】

以下の説明では、説明の便宜のため、トリガ信号は、PCRパケットに格納されて送信され、受信装置６０において、PCRパケットからトリガ信号が抽出されるものとして説明する。

【0033】

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

【0034】

受信装置６０は、放送装置４１から放送されたデジタルテレビジョン放送信号を受信し、テレビジョン番組に相当するＡＶコンテンツの映像及び音声を取得して出力する。

【0035】

また、受信装置６０は、受信したデジタルテレビジョン放送信号に、データ放送用コンテンツが含まれる場合、受信したデジタルテレビジョン放送信号から、データ放送用コンテンツを取得する。

【0036】

さらに、受信装置６０は、インターネット５０を介してサーバ４２にアクセスし、データ放送用コンテンツを取得する。

【0037】

また、受信装置６０は、受信したデジタルテレビジョン放送信号に含まれるPCRパケットから、トリガ信号を抽出し、抽出したトリガ信号に基づいて、取得したデータ放送用コンテンツにより実現される映像を、図示せぬモニタに表示させる。

【0038】

なお、この受信装置６０は、単体として存在してもよいし、例えば、テレビジョン受像機やビデオレコーダなどに内蔵されているようにしてもよい。また、受信装置６０の詳細については、図４を参照して後述する。

【0039】

[本発明の概要]
次に、図３は、受信装置６０が、放送装置４１からのトリガ信号に基づいて、データ放送用コンテンツにより実現される映像を、図示せぬモニタに表示させる場合の一例を示している。

【0040】

受信装置６０は、放送装置４１から放送されたデジタルテレビジョン放送信号を受信し、受信したデジタルテレビジョン放送信号からＡＶコンテンツの映像７１を取得して図示せぬモニタに表示させている。

【0041】

受信装置６０は、受信したデジタルテレビジョン放送信号のPCRパケットから、例えば、株価情報を表示する際に選択される株価アイコン７２aを表示させるためのトリガ信号７２bを取得したことに対応して、株価アイコン７２aを含む映像７２を表示させる。

【0042】

そして、ユーザが、株価アイコン７２aを選択する選択操作を行ったことに対応して、受信装置６０は、現在の株価を表す株価情報表示７３aを含む映像７３を表示させる。

【0043】

受信装置６０は、受信しているデジタルテレビジョン放送信号から、株価情報表示７３aを更新して最新の株価情報表示７４aを表示させるためのトリガ信号７４bを取得した場合、表示中の映像７３を、株価情報表示７４aを含む映像７４に更新する。

【0044】

受信装置６０は、受信しているデジタルテレビジョン放送信号から、株価情報表示７４aを中止させるためのトリガ信号７５bを取得した場合、株価情報表示７４aを中止して、ＡＶコンテンツの映像７５のみを表示させる。

【0045】

受信装置６０は、株価アイコン７２a、株価情報表示７３a、及び株価情報表示７４aを表示させる際、それらを表示させるために必要なファイル（データ放送用コンテンツに含まれる）を、放送装置４１から放送されるデジタルテレビジョン放送信号、サーバ４２、又は受信装置６０が内蔵するストレージ８８（図４）の少なくとも１つから取得するようにしている。

【0046】

本発明では、受信装置６０が、複雑な処理を行うことなく、取得対象のファイルを、ファイルの取得先に拘らず、同一の名前空間を用いて取得できる。なお、詳細については、例えば図１０乃至図１２を参照して後述する。

【0047】

[受信装置６０の構成例]
次に、図４は、受信装置６０の構成例を示している。受信装置６０は、チューナ８１、多重分離部８２、オーディオデコーダ８３、音声出力部８４、ビデオデコーダ８５、映像出力部８６、ファイル受信処理部８７、ストレージ８８、トリガ処理部８９、アプリ制御部９０、アプリエンジン９１、及び通信I/F９２から構成される。

【0048】

チューナ８１は、ユーザによって選局されたチャンネルに対応するデジタルテレビジョン放送信号を受信して復調し、その結果得られるＴＳを多重分離部８２に出力する。

【0049】

多重分離部８２は、チューナ８１から入力されるＴＳをオーディオ符号化信号及びビデオ符号化信号に分離し、それぞれをオーディオデコーダ８３又はビデオデコーダ８５に出力する。

【0050】

また、多重分離部８２は、ＴＳに配置されたトリガ信号を含むPCRパケットを抽出してトリガ処理部８９に出力する。

【0051】

なお、チューナ８１が、ダウンロード放送用に放送されたデジタルテレビジョン放送信号を受信し、対応するＴＳを多重分離部８２に供給した場合、多重分離部８２は、チューナ８１から入力されるダウンロード放送用のＴＳを、ファイル受信処理部８７に供給する。

【0052】

ファイル受信処理部８７は、多重分離部８２から供給されるダウンロード放送用のＴＳを、ストレージ８８に供給して記憶させる。

【0053】

そして、ダウンロード放送において受信されたデジタルテレビジョン放送信号に対応するＡＶコンテンツを視聴するように、受信装置６０の図示せぬ操作部をユーザが操作することに対応して、対応するＡＶコンテンツを視聴できるようになる。

【0054】

すなわち、ユーザ操作に対応して、多重分離部８２は、ストレージ８８に記憶されているダウンロード放送用のＴＳを読み出し、オーディオ符号化信号及びビデオ符号化信号に分離して、それぞれをオーディオデコーダ８３又はビデオデコーダ８５に出力する。

【0055】

オーディオデコーダ８３は、入力されたオーディオ符号化信号をデコードし、その結果得られる音声信号を音声出力部８４に出力する。音声出力部８４は、入力された音声信号を後段（例えば、モニタ）に出力する。

【0056】

ビデオデコーダ８５は、入力されたビデオ符号化信号をデコードし、その結果得られる映像信号を映像出力部８６に出力する。映像出力部８６は、ビデオデコーダ８５から入力された映像信号を後段（例えば、モニタ）に出力する。また、映像出力部８６は、アプリエンジン９１から入力されるデータ放送用コンテンツの映像と、ビデオデコーダ８５から入力された映像信号を合成して、後段に出力する。なお、音声出力部８４及び映像出力部８６から後段への出力は、例えばHDMI(登録商標)(High-Definition Multimedia Interface)ケーブルを用いることができる。

【0057】

上述したように、ファイル受信処理部８７は、多重分離部８２から供給されるダウンロード放送用のＴＳを、ストレージ８８に供給して記憶させる。

【0058】

ストレージ８８は、ファイル受信処理部８７から供給されるダウンロード放送用のＴＳ等を記憶する。

【0059】

すなわち、ストレージ８８は、ダウンロード放送用に放送されたデジタルテレビジョン放送信号に含まれるＡＶコンテンツ及びデータ放送用コンテンツを、ダウンロード放送用のＴＳとして記憶する。

【0060】

トリガ処理部８９は、多重分離部８２からのPCRパケットから、トリガ信号を取得し、アプリ制御部９０に供給する。

【0061】

アプリ制御部９０は、例えば、図示せぬ操作部からの操作信号等に基づいて、受信装置６０を構成する機能ブロックをそれぞれ制御する。また、アプリ制御部９０は、トリガ処理部８９から入力されるトリガ信号に基づき、アプリエンジン９１を制御して、データ放送用のアプリケーションプログラム（以下、データ放送用アプリケーションという）の取得、起動、イベント発火、終了等を実行させる。

【0062】

なお、データ放送用アプリケーションとは、テレビジョン番組に連動したデータ放送用のサービス（例えば、図３に示されるように、テレビジョン番組に連動して株価情報等を表示させるサービス等）を実現するためのプログラムをいう。データ放送用アプリケーションは、ファイルとして、データ放送用コンテンツに含まれる。

【0063】

アプリエンジン９１は、アプリ制御部９０からの制御にしたがって、通信I/F９２及びインターネット５０を介してサーバ４２からデータ放送用アプリケーションを取得する。

【0064】

また、アプリエンジン９１は、ダウンロード放送により、ストレージ８８にデータ放送用アプリケーションが蓄積（記憶）済みである場合、ストレージ８８からデータ放送用アプリケーションを取得する。

【0065】

さらに、アプリエンジン９１は、アプリ制御部９０からのデジタルテレビジョン放送信号からデータ放送用アプリケーションを取得する。なお、アプリエンジン９１には、チューナ８１から多重分離部８２、トリガ処理部８９、及びアプリ制御部９０を介して、受信されたデジタルテレビジョン放送信号（のＴＳ）が供給されるものとする。

【0066】

通信I/F９２は、アプリエンジン９１からの制御に従い、インターネット５０を介してサーバ４２に接続する。

【0067】

[トリガ信号の詳細]
図５は、トリガ信号がＴＳのPCRパケットに格納されて送信される場合の概念を示している。同図に示すように、トリガ信号は全てのPCRパケットに格納されるわけではなく、テレビジョン番組に相当するＡＶコンテンツと連動させるための適切なタイミングにおいてのみ、PCRパケットに格納される。

【0068】

なお、トリガ信号の内容によっては、図５に示されるように、受信装置６０にて受信されなかった場合を考慮して、同一内容のトリガ信号を複数回送信することがある。

【0069】

図６は、トリガ信号の構成例を示している。

【0070】

トリガ信号は、図６に示されるように、トリガＩＤ、コマンドコード、及びアプリケーションリファレンスにより構成される。なお、トリガ信号は、その他、必要に応じて、コマンド依存フィールドも含むように構成される。

【0071】

トリガＩＤは、当該トリガ信号を識別するための情報である。同一内容のトリガ信号が複数回送信される場合、各トリガ信号のトリガＩＤは同一のものとなる。コマンドコードは、当該トリガ信号がアプリ起動（データ放送用アプリケーションの取得と起動を指示するもの）、アプリ終了（実行中のデータ放送用アプリケーションの終了を指示するもの）、アプリイベント（実行中のデータ放送用アプリケーションにおいてイベント（表示内容の更新など）の発火を指示するもの）、又はプリキャッシュ（データ放送用アプリケーションの取得のみを指示するもの）のいずれであるかを示すコードである。

【0072】

アプリケーションリファレンスは、アプリケーションＩＤ及び取得先フラグからなる。また、コマンド依存フィールドは、アプリケーションタイプ、アプリケーション終了時刻、イベントＩＤ、プロトコルバージョン、又は実行用データ等を含む。

【0073】

アプリケーションＩＤは、当該トリガ信号に対応するデータ放送用アプリケーションを識別するための情報であり、例えば、共通の名前空間により表される。取得先フラグは、コマンドコードがトリガ起動又はプリキャッシュである場合、取得対象とされるデータ放送用アプリケーションの取得先を表す。具体的には、例えば、取得先フラグとしては、ストレージ８８を取得先とするか否かを表す蓄積利用可否フラグ、デジタルテレビジョン放送信号を取得先とするか否かを表す放送利用可否フラグ、及びサーバ１２を取得先とするか否かを表す通信利用可否フラグが考えられる。

【0074】

蓄積利用可否フラグ、放送利用可否フラグ、及び通信利用可否フラグは、例えば、０又は１のいずれかの値であるものとし、取得先とされる場合には１とされ、取得先とされない場合には０とされる。なお、アプリケーションＩＤ及び取得先フラグの詳細は、図１１を参照して後述する。

【0075】

アプリケーションタイプは、当該トリガ信号に対応するデータ放送用アプリケーションのタイプ（例えば、html，javaなど）を示す情報である。

【0076】

アプリケーション終了時刻は、コマンドコードがアプリ終了であるトリガ信号を受信できなかった場合において、実行中のデータ放送用アプリケーションを終了させる時刻を示す情報である。

【0077】

イベントＩＤは、コマンドコードがアプリイベントである場合において、そのイベントを識別するための情報である。プロトコルバージョンは、当該トリガ信号のフォーマットのバージョンを示す情報である。実行用データは、コマンドコードがアプリイベントである場合において、そのイベントの発火（実行）に用いる情報である。なお、トリガ信号には、上述した全ての項目が常に含まれるわけではなく、そのタイミングやコマンドコードに応じて必要な項目のみが含まれている。

【0078】

次に、図７は、コマンドコードがアプリ起動である場合に、トリガ信号に含まれる項目の一例を示している。

【0079】

コマンドコードがアプリ起動（execute）である場合、図７に示されるように、トリガ信号には、例えば、８ビットのトリガＩＤ（Trigger_id）、８ビットのコマンドコード（command_code）が含まれ、アプリケーションリファレンスとして、２４ビットのアプリケーションＩＤ(App_id)、１ビットの蓄積利用フラグ（Downloaded_App_flag）、１ビットの放送利用可否フラグ（Broadcast_App_flag）、及び１ビットの通信利用可否フラグ（Internet_App_flag）が含まれる。

【0080】

また、トリガ信号には、図７に示されるように、コマンド依存フィールドとして、４ビットのアプリケーションタイプ（App_type）、８ビットのプロトコルバージョン（Protocol_version）、及び３２ビットのアプリケーション終了時刻（App_expire_date）等が含まれる。

【0081】

なお、コマンドコードがプリキャッシュである場合、コマンドコードがアプリ起動である場合と同様に、アプリケーションリファレンスには、２４ビットのアプリケーションＩＤ、１ビットの蓄積利用フラグ、１ビットの放送利用可否フラグ、及び１ビットの通信利用可否フラグが含まれる。

【0082】

次に、図８は、コマンドコードがアプリイベントである場合に、トリガ信号に含まれる項目の一例を示している。

【0083】

コマンドコードがアプリイベント（inject event）である場合、図８に示されるように、トリガ信号には、例えば、８ビットのトリガＩＤ（Trigger_id）、８ビットのコマンドコード（command_code）が含まれる。また、トリガ信号には、例えば、８ビットのプロトコルバージョン（Protocol_version）、２４ビットのアプリケーションＩＤ(App_id)、４ビットのアプリケーションタイプ（App_type）、８ビットのイベントＩＤ（Event_id）、及びNビットの実行用データ（Event Embedded Data）等が含まれる。

【0084】

なお、後述する図９乃至図２２では、主に、コマンドコードがアプリ起動又はプリキャッシュである場合について説明する。また、後述する図２３乃至図２６では、コマンドコードがアプリイベントである場合について説明する。

【0085】

次に、図９は、受信装置６０が、デジタルテレビジョン放送信号として受信するＡＶコンテンツ、及びデータ放送のサービスを実現させる際に用いるデータ放送用コンテンツの一例を示している。

【0086】

図９のＡに示されるＡＶコンテンツ１１１は、複数のファイルにより構成される。いまの場合、ＡＶコンテンツ１１１は、例えば、テレビジョン番組に対応する映像及び音声を表すＡＶファイル、テレビジョン番組のジャンル等を表すメタファイル、及びテレビジョン番組のサムネイルを表すサムネイルJPEGにより構成されている。

【0087】

また、図９のＢに示されるデータ放送用コンテンツ１１２は、複数のファイルにより構成される。いまの場合、データ放送用コンテンツ１１２は、例えば、データ放送のサービスを実現させる際に、データ放送用アプリケーションとして最初に実行されるエントリアプリファイル１３１、エントリアプリファイル１３１により参照されて実行されるアプリファイル１３２及びアプリファイル１３３、並びにエントリアプリファイル１３１、アプリファイル１３２、及びアプリファイル１３３に参照される静止画ファイル（GIFやJPEG）及び動画ファイル（ＡＶファイル）等により構成される。

【0088】

次に、図１０は、受信装置６０が、トリガ信号に基づいて、図３に示されるように画面表示を変更させる場合の一例を示している。

【0089】

アプリ制御部９０は、図１０に示されるように、例えば、トリガ処理部８９から、コマンドコードがプリキャッシュ（Pre-Cache）であるトリガ信号が入力された場合、アプリエンジン９１を制御して、アプリエンジン９１に、データ放送用コンテンツ１１２のエントリアプリファイル１３１（図１０のappliに対応）を取得させプリキャッシュさせる。

【0090】

すなわち、例えば、このトリガ信号には、図１１に示されるように、当該トリガ信号のトリガＩＤ、プリキャッシュを表すコマンドコードの他、アプリケーションリファレンスとして、アプリケーションＩＤ（アプリＩＤ）及び取得先フラグ（いまの場合、放送利用可否フラグ、通信利用可否フラグ、及び蓄積利用可否フラグの３つ）が含まれる。

【0091】

また、アプリケーションＩＤは、共通の名前空間を表すスキーマ（文字列）「www.ccc.com/content1.html」を示している。

【0092】

したがって、アプリ制御部９０は、トリガ処理部８９からのトリガ信号に含まれる取得先フラグに基づいて、アプリケーションＩＤにより指定されるエントリアプリファイル１３１の取得先を決定して、アプリエンジン９１に通知する。また、アプリ制御部９０は、スキーマの前に「http://」を付加して得られるURL「http://www.ccc.com/content1.html」を、アプリエンジン９１に通知する。

【0093】

アプリエンジン９１は、アプリ制御部９０からの制御にしたがって、アプリ制御部９０から通知されたURL「http://www.ccc.com/content1.html」に基づいて、アプリ制御部９０から通知された取得先からエントリアプリファイル１３１を取得して、内蔵のプリメモリ等にプリキャッシュ（記憶）させる。

【0094】

なお、サーバ４２、放送装置４１により放送されるデジタルテレビジョン放送信号、又はストレージ８８の少なくとも１つには、共通の名前空間としてのURL「http://www.ccc.com/content1.html」に対応付けて、エントリアプリファイル１３１が格納されているものとする。

【0095】

また、アプリ制御部９０は、図１０に示されるように、トリガ処理部８９から、コマンドコードがアプリ起動（Execute）であるトリガ信号が入力された場合、アプリエンジン９１を制御して、アプリエンジン９１に、プリキャッシュ済みのエントリアプリファイル１３１を実行させる。これにより、アプリエンジン９１は、エントリアプリファイル１３１を実行することにより、株価アイコン７２aを生成して映像出力部８６に供給する。映像出力部８６は、アプリエンジン９１からの株価アイコン７２aと、ビデオデコーダ８５からの映像信号とを合成して、図１０に示されるように、株価アイコン７２aを含む映像７２を表示させる。

【0096】

そして、ユーザが、株価アイコン７２aを選択する選択操作を行ったことに対応して、それ以降、上述した図３で説明したように、図示せぬモニタに表示される映像が遷移することとなる。

【0097】

次に、図１２は、AVコンテンツに連動して、データ放送のサービスを実現するために実行されるファイルを取得するための取得用プログラムの一例を示している。

【0098】

すなわち、例えば、図１２は、取得用プログラムとして、エントリアプリファイル１３１の一例を示している。

【0099】

エントリアプリファイル１３１は、例えば、HTML（Hyper Text Markup Language）により記述されたHTML文書であり、株価アイコン７２aを表示させるための実行コードとして、図１２に示されるように、＜a href="xmloc://www.ccc.com/content2.html&path=st,bb,bc"＞が記載されている。

【0100】

「xmloc://」は、URL「http://www.ccc.com/content2.html」により指定されるHTML文書「content2.html」が、デジタルテレビジョン放送信号、ストレージ８８、又はサーバ４２の少なくとも１つから取得可能であることを示している。

【0101】

また、「&path=」の後ろには、HTML文書「content2.html」の取得先として、ストレージ８８を表す「st(strage)」、インターネット５０上のサーバ４２を表す「bb(broad band)」、又は放送装置４１からのデジタルテレビジョン放送信号を表す「bc（broadcast）」の少なくとも１つが記載される。

【0102】

図１２の場合、「&path=st,bb,bc」となっており、HTML文書「content2.html」は、ストレージ８８、インターネット５０上のサーバ４２、又はデジタルテレビジョン放送信号のいずれからでも取得可能であることを示す。

【0103】

すなわち、例えば、アプリエンジン９１が、図１２に示されるようなHTML文書に記述された＜a href="xmloc://www.ccc.com/content2.html&path=st,bb,bc"＞を実行して、株価アイコン７２aを表示するために必要なHTML文書「content2.html」（例えば、株価アイコン７２aを表す静止画ファイルを表示させるためのもの）を取得する場合、ストレージ８８、インターネット５０上のサーバ４２、又はデジタルテレビジョン放送信号のいずれかから取得する。

【0104】

図１２に示されるように、取得対象のHTML文書を指定するための情報として、例えばURLを採用することとしたので、HTML文書の取得先に拘らず、取得対象のHTML文書をURL形式により指定することが可能となる。

【0105】

したがって、例えば、取得先毎に異なる形式により、取得対象のHTML文書を指定する必要がなくなる。このため、取得先毎に異なる形式により指定しなければならない場合と比較して、図１２に示されるようなHTML文書において、より容易に取得対象のHTML文書を指定するための情報を記述することが可能となる。

【0106】

［トリガ信号対応処理について］
次に、受信装置６０がトリガ信号を受信したときに行なうトリガ信号対応処理について説明する。

【0107】

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

【0108】

ステップＳ１において、トリガ処理部８９は、多重分離部８２からの入力に基づき、トリガ信号を含むPCRパケットが受信されるまで待機する。そして、トリガ信号を含むPCRパケットが受信された場合、トリガ処理部８９は、受信したPCRパケットからトリガ信号を取得し、アプリ制御部９０に供給して、処理をステップＳ２に進める。

【0109】

ステップＳ２において、アプリ制御部９０は、トリガ処理部８９からのトリガ信号に含まれるトリガIDに基づいて、トリガ処理部８９からのトリガ信号に対してステップＳ３以降の処理を既に実行済みであるか否かを判定する。既にステップＳ３以降の処理を実行済みであると判定された場合、処理はステップＳ１に戻されて、それ以降、同様の処理が繰り返される。反対に、当該トリガ信号に対してステップＳ３以降の処理を実行していないと判定された場合、処理はステップＳ３に進められる。

【0110】

ステップＳ３において、アプリ制御部９０は、当該トリガ信号のコマンドコードがアプリ起動、アプリイベント、アプリ終了、又はプリキャッシュのいずれであるかを判別する。

【0111】

ステップＳ３にて、当該トリガ信号のコマンドコードがアプリ起動であると判別された場合、処理はステップＳ４に進められる。

【0112】

ステップＳ４において、アプリ制御部９０は、当該トリガ信号に含まれるアプリケーションＩＤ及び取得先フラグに基づいて、アプリエンジン９１に、アプリケーションＩＤにより指定されるデータ放送用アプリケーション（例えば、図９のエントリアプリファイル１３１）を、取得先フラグにより決定される取得先から取得させるファイル取得処理を行なう。なお、ファイル取得処理の詳細は、図１４のフローチャートを参照して説明する。

【0113】

ここで、後述するステップＳ１１により、アプリエンジン９１が、既にデータ放送アプリケーションを取得してプリキャッシュしている場合、ステップＳ４の処理をスキップして、処理はステップＳ５に進められる。

【0114】

ステップＳ５において、アプリエンジン９１は、アプリ制御部９０からの制御に基づき、例えば、「アプリを実行しますか？」等と画面に表示させることにより、ユーザに対してデータ放送用アプリケーション（例えば、エントリアプリファイル１３１）の起動操作を促す。この促し表示に応じ、ステップＳ６において、ユーザから起動操作が入力されたと判定された場合、処理はステップＳ８に進められる。ステップＳ８において、アプリエンジン９１は、アプリ制御部９０の制御に従い、ステップＳ４又はステップＳ１１のファイル取得処理で取得したデータ放送用アプリケーションを起動する（実行する）。これにより、例えば、株価アイコン７２aを含む映像７２が、図示せぬモニタに表示される。その後、処理はステップＳ１に戻されて、それ以降、同様の処理が繰り返される。

【0115】

なお、ステップＳ５における促し表示の後、ステップＳ６にて、ユーザから起動操作が入力されないと判定され、ステップＳ７において、ユーザから起動操作が入力されないまま所定の時間が経過したと判定された場合、処理はステップＳ１に戻されてそれ以降が繰り返される。

【0116】

ステップＳ３にて、当該トリガ信号のコマンドコードがアプリイベントであると判別された場合、処理はステップＳ９に進められる。ステップＳ９において、アプリ制御部９０は、当該トリガ信号のアプリケーションＩＤと、動作中のデータ放送用アプリケーションのアプリケーションＩＤが一致する場合のみ、アプリエンジン９１を制御して、動作中のデータ放送用アプリケーションにおいて、トリガ信号のイベントＩＤに対応するイベントを発火（実行）させる。この後、処理はステップＳ１に戻されて、それ以降、同様の処理が繰り返される。

【0117】

ステップＳ３にて、当該トリガ信号のコマンドコードがアプリ終了であると判別された場合、処理はステップＳ１０に進められる。ステップＳ１０において、アプリ制御部９０は、当該トリガ信号のアプリケーションＩＤと、動作中のデータ放送用アプリケーションのアプリケーションＩＤが一致する場合のみ、アプリエンジン９１を制御して、動作中のデータ放送用アプリケーションを終了させる。その後、処理はステップＳ１に戻されて、それ以降、同様の処理が繰り返される。

【0118】

なお、コマンドコードがアプリ終了であるトリガ信号を受信しない場合であっても、動作中のデータ放送用アプリケーションを起動させたときのトリガ信号に記述されたアプリケーション終了時刻に現在の時刻が達した場合、動作中のデータ放送用アプリケーションは終了される。

【0119】

ステップＳ３にて、当該トリガ信号のコマンドコードがプリキャッシュであると判別された場合、処理はステップＳ１１に進められる。ステップＳ１１において、アプリ制御部９０は、当該トリガ信号に含まれるアプリケーションＩＤ及び取得先フラグに基づいて、図１４を参照して説明するファイル取得処理を行なう。さらに、アプリ制御部９０は、ファイル取得処理により、アプリエンジン９１に取得させたデータ放送用アプリケーションを、アプリエンジン９１に含まれるキャッシュメモリ等の記憶手段に記憶しておく。その後、処理はステップＳ１に戻されて、それ以降、同様の処理が繰り返される。

【0120】

ステップＳ１１のように、コマンドコードをプリキャッシュとすれば、連動させたいテレビジョン番組の放送時刻よりも先に対応するデータ放送用アプリケーションを取得させることができる。これにより、連動させたいテレビジョン番組の開始と同時に、対応するデータ放送用アプリケーションを実行させることができる。以上で、トリガ信号対応処理の説明を終了する。

【0121】

[ファイル取得処理の詳細]
次に、図１４のフローチャートを参照して、図１３のステップＳ４又はステップＳ１１におけるファイル取得処理について説明する。

【0122】

ステップＳ３１において、アプリ制御部９０は、トリガ処理部８９から供給されたトリガ信号のアプリケーションリファレンスに含まれるアプリケーションＩＤを取得する。いまの場合、例えば、図１１に示されるように、アプリケーションＩＤは、ファイルの取得先を指定するためのスキーマ「www.ccc.com/content1.html」を示している。

【0123】

そして、アプリ制御部９０は、取得したアプリケーションＩＤとしてのスキーマ「www.ccc.com/content1.html」の前に「http://」を付加して得られるURL「http:// www.ccc.com/content1.html」を、アプリエンジン９１に供給する。

【0124】

また、ステップＳ３１において、アプリ制御部９０は、トリガ処理部８９から供給されたトリガ信号のアプリケーションリファレンスに含まれる複数の取得先フラグ（蓄積利用可否フラグ、通信利用可否フラグ、及び放送利用可否フラグ）の中から、蓄積利用可否フラグを取得する。そして、アプリ制御部９０は、取得した蓄積利用可否フラグが１であるか否かを判定し、蓄積利用可否フラグが１であると判定した場合、ストレージ８８を、ファイルの取得先としてアプリエンジン９１に通知して、処理をステップＳ３２に進める。

【0125】

ステップＳ３２において、アプリエンジン９１は、アプリ制御部９０から通知されたファイルの取得先（いまの場合、ストレージ８８）に、アプリ制御部９０からのURL（いまの場合、「http:// www.ccc.com/content1.html」）により指定されるファイル（以下、対象ファイルという）が蓄積済みであるか否かを判定する。

【0126】

そして、アプリエンジン９１は、ファイルの取得先であるストレージ８８に、対象ファイルが蓄積済みであると判定した場合、処理をステップＳ３３に進め、ストレージ８８から、対象ファイルを読み出して、ファイル取得処理を終了する。その後、処理は、図１３のステップＳ４又はステップＳ１１にリターンされる。

【0127】

また、ステップＳ３２において、アプリエンジン９１は、ファイルの取得先であるストレージ８８に、対象ファイルが蓄積済みではないと判定した場合、処理をステップＳ３４に進める。なお、ステップＳ３１では、アプリ制御部９０は、取得した蓄積利用可否フラグが１ではない(０である)と判定した場合にも、処理をステップＳ３４に進める。

【0128】

ステップＳ３４において、アプリ制御部９０は、トリガ処理部８９から供給されたトリガ信号のアプリケーションリファレンスに含まれる複数の取得先フラグから、放送利用可否フラグを取得する。そして、アプリ制御部９０は、取得した放送利用可否フラグが１であるか否かを判定し、放送利用可否フラグが１であると判定した場合、デジタルテレビジョン放送信号を、ファイルの取得先としてアプリエンジン９１に通知して、処理をステップＳ３５に進める。

【0129】

ステップＳ３５において、アプリエンジン９１は、アプリ制御部９０から通知されたファイルの取得先（いまの場合、デジタルテレビジョン放送信号）から、アプリ制御部９０からのURLにより指定される対象ファイルを、取得することを試みる。なお、この場合、アプリエンジン９１には、チューナ８１、多重分離部８２、トリガ処理部８９、及びアプリ制御部９０を介して、デジタルテレビジョン放送信号が供給されるものとする。

【0130】

ステップＳ３６において、アプリエンジン９１は、ステップＳ３５の処理結果に基づいて、対象ファイルの取得に成功したか否かを判定し、対象ファイルの取得に成功したと判定した場合、ファイル取得処理を終了する。その後、処理は、図１３のステップＳ４又はステップＳ１１にリターンされる。

【0131】

また、ステップＳ３６において、アプリエンジン９１は、ステップＳ３５の処理結果に基づいて、対象ファイルの取得に成功していない（失敗した）と判定した場合、処理をステップＳ３７に進める。なお、ステップＳ３４において、アプリ制御部９０は、取得した放送利用可否フラグが１ではない(０である)と判定した場合にも、処理をステップＳ３７に進める。

【0132】

ステップＳ３７において、アプリ制御部９０は、トリガ処理部８９から供給されたトリガ信号のアプリケーションリファレンスに含まれる複数の取得先フラグから、通信利用可否フラグを取得する。そして、アプリ制御部９０は、取得した通信利用可否フラグが１であるか否かを判定し、通信利用可否フラグが１であると判定した場合、サーバ４２を、ファイルの取得先としてアプリエンジン９１に通知して、処理をステップＳ３８に進める。

【0133】

なお、いまの段階で既に、ストレージ８８及びデジタルテレビジョン放送信号から、対象ファイルの取得を試みたが失敗に終わっており、対象ファイルの取得先は、サーバ４２しか残っていない。したがって、ファイル取得処理では、ステップＳ３７の処理を省略して、ステップＳ３８以降の処理を行なうようにしてもよい。

【0134】

ステップＳ３８において、アプリエンジン９１は、アプリ制御部９０から通知されたファイルの取得先（いまの場合、サーバ４２）から、アプリ制御部９０からのURLにより指定される対象ファイルを、取得することを試みる。

【0135】

ステップＳ３９において、アプリエンジン９１は、ステップＳ３８の処理結果に基づいて、対象ファイルの取得に成功したか否かを判定し、対象ファイルの取得に成功したと判定した場合、ファイル取得処理を終了する。その後、処理は、図１３のステップＳ４又はステップＳ１１にリターンされる。

【0136】

また、ステップＳ３９において、アプリエンジン９１は、ステップＳ３８の処理結果に基づいて、対象ファイルの取得に成功していない（失敗した）と判定した場合、ファイルの取得に失敗した旨を、図示せぬモニタ等に表示してファイル取得処理を終了する。そして、処理を、図１３のステップＳ１から再開させる。

【0137】

なお、ステップＳ３７において、アプリ制御部９０は、取得した通信利用可否フラグが１ではない(０である)と判定した場合にも、同様にして、ファイルの取得に失敗した旨を、図示せぬモニタ等に表示してファイル取得処理を終了する。この場合も同様に、処理を、図１３のステップＳ１から再開させる。

【0138】

以上説明したように、ファイル取得処理によれば、ストレージ８８からの取得を、他の取得先（デジタルテレビジョン放送信号及びサーバ４２）に先立って行なうようにしたので、より迅速に対象ファイルを取得することが可能となる。

【0139】

すなわち、対象ファイルを読み出すだけで取得可能なストレージ８８を、優先的に対象ファイルの取得先にするようにしているので、デジタルテレビジョン放送信号を受信して対象ファイルを取得したり、サーバ４２にアクセスして対象ファイルを取得する場合と比較して、より迅速に対象ファイルを取得することが可能となる。

【0140】

また、例えば、ファイル取得処理によれば、ストレージ８８やデジタルテレビジョン放送信号からの取得を、サーバ４２からの取得に先立って行なうようにしたので、サーバ４２に対する対象ファイルの取得要求が集中することにより、サーバ４２がダウンしてしまう事態等を抑止することが可能となる。

【0141】

[放送装置４１からのデジタルテレビジョン放送信号]
次に、図１５乃至図１９を参照して、放送装置４１により放送されるデジタルテレビジョン放送信号について説明する。

【0142】

図１５は、デジタルテレビジョン放送信号の構成例を示している。

【0143】

デジタルテレビジョン放送信号は、図１５に示されるように、各チャンネル毎に、トリガ信号、映像信号（ＡＶコンテンツの映像に対応）、音声信号（ＡＶコンテンツの音声に対応）、ファイル取得処理により取得される対象ファイル等を含むファイル伝送信号、及びチャンネルに関する制御情報として、例えばVCT（Virtual Channel Table）等を含むメタ信号から構成される。

【0144】

なお、ファイル伝送信号において、FLUTEによるファイル伝送方法が用いられる。図１６は、このFLUTEによるファイル伝送プロトコルスタックの一例を示している。

【0145】

次に、図１７は、FLUTEによるファイル伝送方法を示している。

【0146】

図１７は、FLUTEのセッションにより伝送されるコンテンツのデータ構成を説明する図である。FLUTEのセッションにより取得されたデータは、同図の左側に示されるようなFLUTEセッションストリームを構成する。

【0147】

FLUTEセッションストリームには、それぞれ、FLUTEのセッションを特定するための識別子「ＴＳＩ（Transport Session Identifier）」が対応付けられており、識別子「ＴＳＩ」により、それぞれのセッションストリームが識別される。

【0148】

FLUTEセッションストリームは、実際には、所定のサイズに分割された複数のファイルにより構成されており、この複数のファイルのそれぞれには、「ＴＯＩ（Transport Object Identifier）」と称される識別子が付されている。このＴＯＩにより、複数のファイルそれぞれを特定することができるようになされている。この例では、「ＴＯＩ」が０のファイルは、「ＦＤＴ（File Delivery Table）」とされ、「ＴＯＩ」が１のファイルは、「ＦＩＬＥ＃１」とされ、「ＴＯＩ」が２のファイルは、「ＦＩＬＥ＃２」とされ、・・・とされている。

【0149】

なお、複数のファイルそれぞれは、ALC（Asynchronous Layered Coding Protocol）／LCT（Layered Coding Transport (Building Block)）パケットとして伝送される。

【0150】

次に、図１８は、「ＴＯＩ」が０であるときのファイルを表す「ＦＤＴ」の一例を示している。

【0151】

ＦＤＴには、FLUTEセッションストリームを構成する他のファイル（ＦＤＴ以外のファイル）のそれぞれに関する情報が記述される。

【0152】

すなわち、例えば、ＦＤＴには、図１８に示されるように、主に、FLUTEセッション内の「ＦＩＬＥ＃１」に関するファイル情報１５１、FLUTEセッション内の「ＦＩＬＥ＃２」に関するファイル情報１５２、・・・が記述されている。

【0153】

ファイル情報１５１としては、「ＦＩＬＥ＃１」についての「ＴＯＩ」、「ロケーション」、「タイプ」、「サイズ」、「コンテンツID」、「ファイルID」、・・・が含まれている。なお、「ＴＯＩ」は、FLUTEセッション内のファイル「ＦＩＬＥ＃１」を識別するための情報とされ、実際には、所定の数値が記述される。

【0154】

ファイル情報１５１において、「ロケーション」は、「ＦＩＬＥ＃１」が存在するURL等を表し、「タイプ」は、「ＦＩＬＥ＃１」のファイル形式（データの種類）を表し、例えば、「ＦＩＬＥ＃１」が画像データのファイルである場合、「ビデオ」などとされ、「ＦＩＬＥ＃１」が音声データのファイルである場合、「オーディオ」などとされる。

【0155】

また、ファイル情報１５１において、「サイズ」は、「ＦＩＬＥ＃１」のファイルサイズを表し、「コンテンツID」は、「ＦＩＬＥ＃１」を含むコンテンツを一意に識別するための識別子を表し、「ファイルID」は、「ＦＩＬＥ＃１」を一意に識別するための識別子を表す。

【0156】

なお、ファイル情報１５２は、ファイル情報１５１と同様であるため、説明を省略する。

【0157】

次に、図１９は、ＦＤＴをXML（Extensible Markup Language）言語により記述した場合の一例を示している。

【0158】

図１９では、例えば、「ＦＩＬＥ＃１」に関するファイル情報１５１として、「ＦＩＬＥ＃１」のロケーションを示す「Location="http://www.example.com/menu/tracklist.html"」、「ＦＩＬＥ＃１」のＴＯＩを示す「TOI="1"」、「ＦＩＬＥ＃１」に対応するコンテンツIDを示す「Content-id="0x6784bf35"」、「ＦＩＬＥ＃１」のファイルIDを示す「File-id="1"」、及び「ＦＩＬＥ＃１」のファイルタイプを示す「Type="text/html"/」等が記述されている。

【0159】

また、例えば、図１９に示されるように、「ＦＩＬＥ＃２」に関するファイル情報１５２として、「ＦＩＬＥ＃２」のロケーションを示す「Location="http://www.example.com/tracks/track1.mp3"」、「ＦＩＬＥ＃２」のＴＯＩを示す「TOI="2"」、「ＦＩＬＥ＃２」のサイズを示す「Length="6100"」、「ＦＩＬＥ＃２」に対応するコンテンツIDを示す「Content-id="0x6784bf35"」、「ＦＩＬＥ＃２」のファイルIDを示す「File-id="3"」、及び「ＦＩＬＥ＃２」のファイルタイプを示す「Type="audio/mp3"」等が記述されている。

【0160】

アプリエンジン９１は、デジタルテレビジョン放送信号から対象ファイルを取得する場合、例えば、FLUTEによるファイル伝送方法により伝送（放送）されるＦＤＴに基づいて、アプリ制御部９０から通知されるURLと一致するロケーションの対象ファイルを特定する。

【0161】

なお、ダウンロード放送においても、FLUTEによるファイル伝送方法が用いられる。受信装置６０が、ダウンロード放送によるデジタルテレビジョン放送信号を受信すると、TOIが１以上のALC/LCTパケットに対応するファイル（ＦＩＬＥ＃１」、「ＦＩＬＥ＃２」等）は、TOI=０のALC/LCTパケットに対応するファイル「ＦＤＴ」に基づき、例えば、図２０に示されるような階層構造で、ストレージ８８に記憶される。また、ストレージ８８には、ＦＤＴも記憶される。

【0162】

アプリエンジン９１は、ストレージ８８から対象ファイルを取得する場合、例えば、ストレージ８８に記憶されているＦＤＴに基づいて、アプリ制御部９０から通知されるURLと一致するロケーションの対象ファイルを特定する。

【0163】

また、FLUTEによるファイル伝送方法では、ストレージ８８に蓄積され、のちに再生されるデジタルテレビジョン放送信号を放送するダウンロード放送と、リアルタイムに利用されるデジタルテレビジョン放送信号を放送するリアルタイム放送とが同時に行なわれる場合が想定される。この場合、ダウンロード放送用のセッションと、リアルタイム放送用のセッションとは、別々のセッションとされる。具体的には、例えば、リアルタイム放送用のセッションのTSIを０等の固定値とし、ダウンロード放送用のセッションのTSIを０以外の任意の値として、セッションが別々となるようにしている。

【0164】

＜２．第２の実施の形態＞
第１の実施の形態では、図１１及び図１２に示されるように、対象ファイルを、ＵＲＬにより指定するようにしたが、対象ファイルの指定方法は、これに限定されない。

【0165】

すなわち、例えば、スキーマ「www.ccc.com/content2.html」に代えて、図２１に示されるように、対象ファイルのファイルIDと、対象ファイルを含むコンテンツのコンテンツIDとを記述するようにして、対象ファイルを指定するようにしてもよい。なお、図２１では、コンテンツIDは４バイトにより表され、ファイルIDは２バイトにより表されることとするが、コンテンツIDとファイルIDとのバイト数は、これに限定されない。また、図２１において、コンテンツID及びファイルIDは、例えば、１６進数により表され、「2fa64810b233a」等とされる。

【0166】

対象ファイルをサーバ４２から取得する場合、アプリエンジン９１は、URL「http://[bc_domain]?file=“[cid][fid]”」にアクセスして対象ファイルを取得する。なお、[bc_domain]はサーバ４２のドメイン名を、[cid]はコンテンツIDを、[fid]はファイルIDをそれぞれ表す。

【0167】

また、サーバ４２のURL「http://[bc_domain]」は、メタ信号として放送されるVCTに含まれている。よって、アプリエンジン９１は、放送されるVCTから、サーバ４２のURL「http://[bc_domain]」を抽出する。そして、アプリエンジン９１は、抽出した「http://[bc_domain]」と、図２１に示されるHTML文書(例えばエントリアプリファイル１３１)に記述されたコンテンツID及びファイルIDとに基づき得られるURL「http://[bc_domain]?file=“[cid][fid]”」にアクセスして対象ファイルを取得する。

【0168】

対象ファイルをデジタルテレビジョン放送信号から取得する場合、アプリエンジン９１は、放送されるFDTに基づいて、図２１に示されるHTML文書に記述されたコンテンツID及びファイルIDに対応するファイルを、対象ファイルとして取得する。

【0169】

対象ファイルをストレージ８８から取得する場合、アプリエンジン９１は、ストレージ８８に記憶されているFDTに基づいて、図２１に示されるHTML文書に記述されたコンテンツID及びファイルIDに対応するファイルを、対象ファイルとして取得する（読み出す）。

【0170】

図２１に示されたように、コンテンツID及びファイルIDを用いる場合には、例えば、第１の実施の形態（「www.ccc.com/content2.html」を用いる場合）と比較して、より少ないバイト数により、対象ファイルを指定することが可能となる。

【0171】

また、例えば、コンテンツID及びファイルIDは、単なる文字列（図２１の場合、１６進数で表記）の羅列である。よって、コンテンツID及びファイルIDが漏洩したとしても、漏洩したコンテンツID及びファイルIDから、対象ファイルの格納位置を知られるおそれがない。

【0172】

なお、図２１では、HTML文書に記述されたコンテンツID及びファイルIDに基づいて対象ファイルを指定するようにしたが、トリガ信号についても同様のことがいえる。

【0173】

すなわち、例えば、トリガ信号のアプリケーションリファレンスに、４バイトのコンテンツID、２バイトのファイルID、及び取得先フラグを含めるようにして、対象ファイルを指定するようにしてもよい。

【0174】

ところで、トリガ信号は、デジタルテレビジョン放送等により送信されてくるので、トリガ信号のデータ量は少ないほうが望ましい。

【0175】

次に、図２２は、トリガ信号のアプリケーションリファレンスに、３バイトのアプリケーションID及び取得先フラグを含めるようにした構成で、実行すべきファイルを含むコンテンツを指定して取得する場合の一例を示している。

【0176】

なお、図２２において、アプリケーションIDは、トリガ信号のデータ量を少なくするために、単に、データ放送用アプリケーションを識別するための３バイトの識別情報であるものとする。

【0177】

ここで、図２２において、アプリケーションIDは、例えば、図７や図１１に示されるアプリケーションIDのように、スキーマ「www.ccc.com/content1.html」も表すようにはなっていないため、２４バイトよりもデータ量が少ない３バイトにより表すことができる。

【0178】

トリガ信号を用いてコンテンツを指定する場合、アプリ制御部９０は、図２２に示されるように、入力されたトリガ信号に含まれるアプリケーションIDを下位３バイトとし、取得すべきコンテンツのタイプを示すタイプ情報を上位１バイトとするコンテンツIDを生成し、アプリエンジン９１に供給する。

【0179】

ところで、いまの場合、受信したトリガ信号に基づき取得されるコンテンツは、いずれも、データ放送用に用いられるコンテンツであり、１種類に限定されている。したがって、トリガ信号を受信したことに対応して取得すべきコンテンツのタイプ情報は、いずれも同じものとなる。

【0180】

したがって、例えば、アプリ制御部９０は、内蔵するメモリ（図示せず）に、トリガ信号を受信したことに対応して取得すべきコンテンツのタイプ情報を予め保持しているものとする。

【0181】

アプリ制御部９０は、例えば、トリガ処理部８９からのトリガ信号を受信したことに対応して、そのトリガ信号からアプリケーションIDを抽出する。そして、アプリ制御部９０は、抽出したアプリケーションIDを下位３バイトとし、内蔵するメモリに保持されているタイプ情報を上位１バイトとするコンテンツIDを生成し、アプリエンジン９１に供給する。

【0182】

また、アプリ制御部９０は、トリガ処理部８９からのトリガ信号に含まれる取得先フラグに基づいて、生成したコンテンツIDにより指定されるコンテンツの取得先を決定して、アプリエンジン９１に通知する。

【0183】

アプリエンジン９１は、アプリ制御部９０からのコンテンツIDと同一のコンテンツIDのコンテンツを、アプリ制御部９０から通知された取得先から、取得先のFDT等に基づいて取得する。

【0184】

なお、いまの場合、放送装置４１により放送されるFDT及びストレージ８８に記憶されているFDTには、コンテンツIDとして、アプリ制御部９０が内蔵するメモリに保持されているタイプ情報と同一のタイプ情報を上位１バイトとし、アプリケーションIDを下位３バイトとするコンテンツIDが記述されているものとする。

【0185】

また、サーバ４２には、サーバ４２が保持するデータ放送用のコンテンツをそれぞれ識別するためのコンテンツIDとして、アプリ制御部９０が内蔵するメモリに保持されているタイプ情報と同一のタイプ情報を上位１バイトとし、アプリケーションIDを下位３バイトとするコンテンツIDが保持されているものとする。

【0186】

したがって、例えば、コンテンツをサーバ４２から取得する場合、アプリエンジン９１は、アプリ制御部９０からのコンテンツIDに基づいて、URL「http://[bc_domain]?content=“0・・01｛a1｝”」にアクセスして、対応するコンテンツを取得する。ここで、「0・・01」は、アプリ制御部９０からのコンテンツIDの上位１バイトに格納されているタイプ情報を表す。また、「a1」は、アプリ制御部９０からのコンテンツIDの下位３バイトに格納されているアプリケーションIDを表す。なお、アプリエンジン９１は、「http://[bc_domain]」を、メタ信号として放送されるVCTから抽出するものとする。

【0187】

また、例えば、コンテンツをデジタルテレビジョン放送信号から取得する場合、アプリエンジン９１は、放送されるFDTに基づいて、アプリ制御部９０からのコンテンツID（「0・・01」「a1」）に対応するコンテンツを、デジタルテレビジョン放送信号から取得する。

【0188】

さらに、例えば、コンテンツをストレージ８８から取得する場合、アプリエンジン９１は、ストレージ８８に記憶されているFDTに基づいて、アプリ制御部９０からのコンテンツID（「0・・01」「a1」）に対応するコンテンツを、ストレージ８８から取得する（読み出す）。

【0189】

そして、アプリエンジン９１は、取得したコンテンツ（例えば、図９のデータ放送用コンテンツ１１２）から、所定のファイル（例えば、図９のエントリアプリファイル１３１）を取得する。

【0190】

すなわち、例えば、アプリエンジン９１は、取得したコンテンツを構成する各ファイルのうち、最初に実行すべきファイルを取得する。なお、いまの場合、最初に実行すべきファイルには、最初に実行すべきファイルであることを示すファイル名（例えば、index.html等）が付けられているものとする。このため、アプリエンジン９１は、取得したコンテンツを構成する各ファイルのファイル名に基づいて、最初に実行すべきファイルを取得して実行する。

【0191】

上述した第１及び第２の実施の形態では、コマンドコードがアプリ起動又はプリキャッシュである場合、共通の名前空間を用いて、データ放送用アプリケーションを取得するようにした。

【0192】

[コマンドコードがアプリイベントである場合について]
コマンドコードがアプリイベントである場合についても同様に、共通の名前空間を用いて、イベントの実行時に用いられるデータを取得することができる。

【0193】

次に、図２３乃至図２６を参照して、コマンドコードがアプリイベントである場合における一例を説明する。

【0194】

図２３は、コマンドコードがアプリイベントであるトリガ信号を受信した場合に行われる処理の第１の例を示している。

【0195】

図２３のAには、コマンドコードがアプリイベント（inject event）であり、アプリケーションIDが、データ放送用アプリケーションとしてのAppli(T1)を識別するための識別情報T1であり、イベントIDが、イベントE1を識別するための識別情報E1であるトリガ信号７４bが示されている。

【0196】

図２３のBには、Appli(TI)が、トリガ信号７４bに含まれるイベントIDとしてのE1に基づいて、イベントE1を実行する様子の一例を示している。

【0197】

図２３のCには、株価情報表示７３aを含む映像７３を、株価情報表示７４aを含む映像７４に更新するイベントE1が示されている。

【0198】

アプリ制御部９０は、例えば、図２３のAに示されるようなトリガ信号７４bを受信した場合、トリガ信号７４bから、アプリケーションID及びイベントIDを抽出し、アプリエンジン９１に供給する。

【0199】

アプリエンジン９１は、起動済みのデータ放送用アプリケーションのうち、アプリ制御部９０からのアプリケーションIDとしてのT1に対応するAppli(T1)を特定する。

【0200】

そして、アプリエンジン９１は、図２３のBに示されるように、特定したアプリケーションAppli(T1)に、アプリ制御部９０からのイベントIDに対応するイベントE1を実行させる。

【0201】

具体的には、例えば、アプリエンジン９１は、図２３のCに示されるように、図示せぬモニタに表示されている映像７３を映像７４に遷移させる処理を、データ放送用アプリケーションとしてのAppli(T1)に実行させる。

【0202】

なお、アプリエンジン９１は、映像７３を映像７４に遷移させる際に必要なファイルを、いずれかの取得先から取得する必要がある場合、上述した図１２や図２１で説明した場合と同様にして、ファイルを取得することとなる。

【0203】

すなわち、例えば、Appli(T1)はHTML文書により構成されており、実行されるイベントE1に対応するHTMLによる記述には、図１２や図２１において説明したように、イベントE1の実行に必要なファイルの指定及びそのファイルの取得先フラグが示されているものとする。この場合、アプリエンジン９１は、実行されるイベントE1に対応するHTMLによる記述に基づいて、イベントE1の実行に必要なファイルを、取得先フラグが表す取得先から取得する。

【0204】

そして、アプリエンジン９１は、取得したファイルを用いて、映像７３を映像７４に遷移させるイベントE1を実行する。

【0205】

次に、図２４は、コマンドコードがアプリイベントであるトリガ信号を受信した場合に行われる処理の第２の例を示している。

【0206】

図２４のAには、コマンドコード、アプリケーションID及びイベントIDの他、実行用データ（Event Embedded Data）がAppDataRef1であるトリガ信号７４bが示されている。また、図２４のAに示されるコマンドコード、アプリケーションID及びイベントIDは、図２３に示されるコマンドコード、アプリケーションID及びイベントIDと同様であるため、それらの説明は省略する。

【0207】

なお、AppDataRef1とは、イベントE1の実行時に用いられるファイルを指定するために必要な共通の名前空間（例えば、スキーマとしてのURLや、コンテンツID及びファイルID等）、及び取得先フラグを表す。

【0208】

いまの場合、AppDataRef1に、共通の名前空間を含めるようにしている。このため、図２４に示されるアプリケーションIDは、データ放送用アプリケーションを識別するための識別情報であればよく、例えば図１１に示されるアプリケーションIDのように、共通の名前空間としてのURLも表すようなアプリケーションIDである必要はない。

【0209】

図２４のBには、Appli(TI)が、トリガ信号７４bに含まれるイベントIDとしてのE1、及び実行用データとしてのAppDataRef1に基づいて、イベントE1を実行する様子の一例を示している。

【0210】

アプリ制御部９０は、例えば、図２４のAに示されるようなトリガ信号７４bを受信した場合、アプリエンジン９１により起動されているAppli(TI)において、受信したトリガ信号７４bに対応するイベントE1を実行させる。

【0211】

すなわち、例えば、アプリ制御部９０は、受信したトリガ信号７４bから、アプリケーションIDとしてのT1、イベントIDとしてのE1、及び実行用データとしてのAppDataRef1を抽出する。

【0212】

そして、アプリ制御部９０は、図２４のBに示されるように、抽出したAppDataRef1に含まれる取得先フラグに基づいて、イベントE1の実行時に用いられるファイル（図２４のBに示すアプリケーションデータ）の取得先としてサーバ４２を決定し、アプリエンジン９１に通知する。また、アプリ制御部９０は、抽出したAppDataRef1に含まれる名前空間、抽出したアプリケーションIDとしてのT1、及び抽出したイベントIDとしてのE1を、アプリエンジン９１に通知する。

【0213】

アプリエンジン９１は、アプリ制御部９０からの名前空間に基づいて、アプリ制御部９０から通知された取得先であるサーバ４２から、イベントE1の実行時に用いられるファイルを取得する。そして、アプリエンジン９１は、アプリ制御部９０から通知されたT1に対応するAppli(T1)において、取得したファイルを用いて、アプリ制御部９０から通知されたイベントIDに対応するイベントE1を実行させる。

【0214】

なお、アプリエンジン９１は、コマンドコードがアプリイベントであるトリガ信号を受信した場合、イベントE1の実行時に用いられるファイルを、サーバ４２から取得するようにしたが、ファイルの取得先は、サーバ４２に限定されない。すなわち、例えば、アプリエンジン９１は、図２５に示されるように、取得先フラグに応じて、サーバ４２の他、複数の取得先のいずれかから、共通の名前空間を用いて、その名前空間により特定されるファイルを取得することができる。

【0215】

次に、図２６は、コマンドコードがアプリイベントであるトリガ信号を受信した場合に行われる処理の第３の例を示している。

【0216】

図２６のAには、コマンドコード、アプリケーションID及びイベントIDの他、実行用データ（Event Embedded Data）がAD1であるトリガ信号７４bが示されている。また、図２６のAに示されるコマンドコード、アプリケーションID及びイベントIDは、図２３に示されるコマンドコード、アプリケーションID及びイベントIDと同様であるため、それらの説明は省略する。

【0217】

なお、AD1とは、イベントE1の実行時に用いられるファイルを表す。

【0218】

図２６のBには、Appli(TI)が、トリガ信号７４bに含まれるイベントIDとしてのE1、及び実行用データとしてのAD1に基づいて、イベントE1を実行する様子の一例を示している。

【0219】

アプリ制御部９０は、例えば、図２６のAに示されるようなトリガ信号７４bを受信した場合、アプリエンジン９１により起動されているAppli(TI)において、受信したトリガ信号７４bに対応するイベントE1を実行させる。

【0220】

すなわち、例えば、アプリ制御部９０は、受信したトリガ信号７４bから、アプリケーションIDとしてのT1、イベントIDとしてのE1、及び実行用データとしてのAD1を抽出し、アプリエンジン９１に通知する。

【0221】

アプリエンジン９１は、アプリ制御部９０から通知されたT1に対応するAppli(T1)において、アプリ制御部９０から通知されたAD1を用いて、アプリ制御部９０から通知されたイベントIDに対応するイベントE1を実行させる。

【0222】

＜３．変形例＞
第１及び第２の実施の形態では、受信装置６０は、取得先フラグに基づいて、対象ファイルの取得先を決定するようにしたが、その他、取得先フラグを用いずに、取得先からファイルが取得されるまで、予め決められた順序で、取得先を順次決定してファイルの取得を試みるようにしてもよい。

【0223】

この場合、トリガ信号やHTML文書において、取得先フラグを記述する必要がなくなり、取得先フラグの分だけデータ量を少なくすることが可能となる。よって、放送装置４１において、より少ないデータ量のトリガ信号を送信したり、サーバ４２において、より少ないデータ量のHTML文書を送信することができるので、少なくなったデータ量の分だけ、他の情報を送信できるようになる。

【0224】

また、第１及び第２の実施の形態では、取得先フラグとして、蓄積利用可否フラグ、放送利用可否フラグ、及び通信利用可否フラグを用いるようにしたが、その他、例えば、取得先フラグとしては、２つのフラグ、又は４つ以上のフラグを採用するようにしてもよい。

【0225】

また、第１及び第２の実施の形態では、受信装置６０は、受信するトリガ信号に基づいて、対象ファイルを取得先から取得して実行するようにしたが、対象ファイルを取得して実行するタイミングは、トリガ信号を受信するタイミングに限定されない。すなわち、例えば、ユーザにより対象ファイルが指定されたことに対応して、対象ファイルを取得先から取得して実行するようにしてもよい。その他、例えば、第１及び第２の実施の形態では、AVコンテンツに連動して実行されるファイルを、対象ファイルとして取得するようにしたが、対象ファイルの種類は、これに限定されず、受信装置６０において所定の処理を実行するために取得されるファイルであれば、どのようなファイルであってもよい。

【0226】

さらに、図１１及び図１２では、対象ファイルを指定するための情報として、サーバ４２についての名前空間を示すURLを用いるようにしたが、その他、例えば、デジタルテレビジョン放送信号についての名前空間や、ストレージ８８についての名前空間を用いるようにしてもよい。

【0227】

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

【0228】

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

【0229】

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

【0230】

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

【0231】

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

【0232】

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

【0233】

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

【0234】

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

【0235】

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

【符号の説明】

【0236】

３０ 放送システム， ４１ 放送装置， ４２ サーバ， ６０ 受信装置， ８１ チューナ， ８２ 多重分離部， ８３ オーディオデコーダ， ８４ 音声出力部， ８５ ビデオデコーダ， ８６ 映像出力部， ８７ ファイル受信処理部， ８８ ストレージ， ８９ トリガ処理部， ９０ アプリ制御部９０， ９１ アプリエンジン， ９２ 通信I/F

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】