JP2022183813A - 受信装置、クライアント端末装置、およびプログラム - Google Patents

Abstract

【課題】ハイブリッドキャストアプリのコンテンツを、受信装置と連携するクライアント端末装置の側で利用可能とする。【解決手段】受信装置は、コンテンツ変換部と、ウェブリソース提供部とを含む。コンテンツ変換部は、アプリを、ウェブプラットフォームで利用可能な形式のアプリに変換する。ウェブリソース提供部は、クライアント端末装置から送信されるアプリ起動要求に基づいてアプリを起動させる。ウェブリソース提供部は、コンテンツ変換部が変換した結果であるウェブプラットフォームで利用可能なアプリを前記クライアント端末装置に対して通信を介して送信する。【選択図】図２

Description

本発明は、受信装置、クライアント端末装置、およびプログラムに関する。

従来技術において、テレビ受信機は、放送波に含まれる様々なリソース（映像、音声、字幕など）を活用する。このような放送に含まれるリソースの活用は、基本的に放送チューナーを有するテレビ受信機等に限られていたものである。

これに対して、放送波に含まれるリソースをウェブプラットフォームで利活用できるようにするための技術の普及が進みつつある。このような技術では、テレビ受信機以外の端末装置（例えば、ウェブクライアント端末）でも放送に含まれるリソースの活用が可能となる。例えば、日本国外の規格であるＡＴＳＣ ３．０規格（ＡＴＳＣは、「Advanced Television Systems Committee」の略）に準拠したテレビ受信機などは、配信サーバーの役割を担うことができる。即ち、そのようなテレビ受信機は、受信した放送映像などを別の端末装置に対して配信することができる。

一方、日本の放送規格（ＩＳＤＢ－Ｔなど）では、様々な電機メーカーが提供する録画機などによってリモート視聴のサービスが提供されている。非特許文献１には、リモート視聴について記載されている。

標準化された技術としては、テレビ受信機と視聴端末とが連携するための仕組みである、ハイブリッドキャストの端末連携機能が存在する。この機能は、「ハイブリッドキャストコネクト」あるいは「ハイコネ」と呼ばれる。ハイブリッドキャストコネクト（ハイブリッドキャストの端末連携機能）の技術標準では、発見・接続・データ送受信プロトコルなどが提供されている。非特許文献２には、ハイブリッドキャストの端末連携機能の規定が含まれる。

「デジタル放送のリモート視聴について」，一般社団法人放送サービス高度化推進協会，［online］，［2021年4月10日ダウンロード］，インターネット＜URL：https://www.apab.or.jp/remote-viewing/pdf/remote-viewing.pdf＞ 「IPTVフォーラム標準規格,運用規定」，一般社団法人IPTVフォーラム， IPTVFJ-STD0010 2.3版・IPTVFJ-STD0011 2.6版・IPTVFJ-STD0013 2.9版，[2020年10月2日]，インターネット＜URL：https://www.iptvforum.jp/download/input.html＞

しかしながら、従来技術には、解決すべき課題が存在する。

非特許文献１に記載されているリモート視聴のしくみでは、テレビ受信機と視聴端末（およびその端末上で動作するアプリケーションプログラム）の組合せが、メーカーごとに固定されている。その理由としては、テレビ受信機と視聴端末との間での発見・接続プロトコルや、コンテンツ保護のための技術として、メーカーごとの独自技術が用いられていることが考えられる。つまり、テレビ受信機と視聴端末との間の相互接続性が向上しないという問題がある。このような事情により、ユーザーの利便性が向上せず、技術の普及が阻害されているという問題がある。

非特許文献２に記載されているハイブリッドキャストの端末連携機能のしくみでは、視聴端末において、放送波のリソースを取得して動画再生を行ったり字幕を表示したりすることができないという問題がある。

つまり、標準的な技術でテレビ受信機と視聴端末との間の相互接続性を高めるためには、ハイブリッドキャストの端末連携機能の標準技術を拡張して、放送波に含まれる様々なリソースを視聴端末で活用できるようにすることが望まれる。

この状況において本発明が解決すべき課題は、次の通りである。放送チューナーを有しているテレビ受信機（以下、受信端末装置あるいは受信装置とも呼ぶ）は、受信した放送信号から映像や音声を抽出して視聴者に提示するだけではなく、様々なコンテンツを提示する。そういったコンテンツの一つは、ハイブリッドキャストアプリのコンテンツである。ハイブリッドキャストアプリのコンテンツは、特定の放送サービスによってマネージされる形態で起動したり、視聴者のリモコン操作等に基づいて起動したりする。従来技術では、ハイブリッドキャストアプリが出力するコンテンツは、受信端末装置においては視聴することができたが、受信端末装置と連携動作する視聴端末（以下、クライアント端末装置とも呼ぶ）では視聴することができなかった。

しかしながら、単に放送番組の映像や音声だけではなく、ハイブリッドキャストアプリのコンテンツも、受信端末装置と連携するクライアント端末装置で視聴できるようにすることが望まれる。さらに、好ましくは、受信端末装置とクライアント端末装置との間での標準的なウェブインターフェースに則った形式で、クライアント端末装置が、ハイブリッドキャストアプリのコンテンツを利用・活用できるようにすることが望まれる。

本発明は、上記の課題認識に基づいて行なわれたものであり、受信装置（テレビ受信機）からクライアント端末装置（視聴端末）に対して、ハイブリッドキャストアプリのコンテンツを、クライアント端末装置側で利用可能な形で渡すことを可能にする受信装置、クライアント端末装置、およびプログラムを提供しようとするものである。

［１］上記の課題を解決するため、本発明の一態様による受信装置は、放送信号を受信する受信部と、受信された前記放送信号に基づいて取得したアプリケーション情報テーブル、または受信した前記放送信号に基づくアプリケーション情報テーブルの所在情報、の少なくともいずれかを、通信を介して、連携先のクライアント端末装置に対して送信するウェブリソース提供部と、を備える。

［２］また、本発明の一態様は、上記の受信装置において、前記アプリケーション情報テーブルが特定するアプリを、ウェブプラットフォームで利用可能なアプリに変換するコンテンツ変換部、をさらに備えるものである。

［３］また、本発明の一態様は、上記の受信装置において、前記アプリケーション情報テーブルが特定するアプリの稼働を制御するアプリケーション制御部、をさらに備えるものである。

［４］また、本発明の一態様は、上記の受信装置において、前記ウェブリソース提供部は、連携先のクライアント端末装置から送信されるアプリ起動要求に基づいて前記アプリを起動するよう前記アプリケーション制御部に指示し、前記コンテンツ変換部が変換した結果である前記ウェブプラットフォームで利用可能なアプリを前記クライアント端末装置に対して通信を介して送信する、ものである。

［５］また、本発明の一態様は、上記の受信装置において、受信された前記放送信号から抽出された映像リソースまたは音声リソースの少なくともいずれかのデータを、ウェブプラットフォームで利用可能な形式のデータにトランスコードして、ウェブリソースとして出力するトランスコード部、をさらに備え、前記ウェブリソース提供部は、前記トランスコード部が出力する前記ウェブリソースを前記クライアント端末装置に対して通信を介して送信する、というものである。

［６］また、本発明の一態様は、上記の受信装置において、前記ウェブリソース提供部は、前記クライアント端末装置からの前記アプリ起動要求に含まれる情報によって特定される前記アプリを起動するように前記アプリケーション制御部に指示する、ものである。

［７］また、本発明の一態様は、上記の受信装置において、前記ウェブリソース提供部は、前記受信部が受信した前記放送信号に含まれる情報によって特定される前記アプリを起動するように前記アプリケーション制御部に指示する、ものである。

［８］また、本発明の一態様は、上記の受信装置において、前記アプリケーション制御部は、前記クライアント端末装置から送信されるアプリ起動要求に基づいて前記アプリを起動するよう前記ウェブリソース提供部から指示を受けたときに、外部の起動可否判定サーバー装置に問い合わせを行い、起動可否判定サーバー装置からの応答に基づいて、前記ウェブプラットフォームで利用可能なアプリを前記クライアント端末装置に対して送信するか否かを決定する、ものである。

［９］また、本発明の一態様は、上記の受信装置において、前記ウェブリソース提供部は、前記クライアント端末装置からの起動可否状態取得のリクエストに応じて、前記ウェブプラットフォームで利用可能なアプリの起動可否状態のデータを、前記クライアント端末装置に対して送信する、ものである。

［１０］また、本発明の一態様は、上記の受信装置において、前記ウェブリソース提供部は、前記クライアント端末装置からの受信機状態取得のリクエストに応じて、前記ウェブプラットフォームで利用可能なアプリについての受信機状態のデータを、前記クライアント端末装置に対して送信する、ものである。

［１１］また、本発明の一態様によるクライアント端末装置は、上記［２］の受信装置の前記コンテンツ変換部が出力するアプリのアプリ起動要求を前記受信装置に対して送信し、前記コンテンツ変換部が変換した結果であるウェブプラットフォームで利用可能なアプリを前記受信装置から受信する受信端末連携制御部、を備えるものである。

［１２］また、本発明の一態様は、上記のクライアント端末装置において、上記［５］の受信装置の前記トランスコード部が出力した前記ウェブリソースを受信して利用するウェブアプリケーションを稼働させるアプリケーションエンジン、をさらに備え、前記受信端末連携制御部は、ハイブリッドキャストの端末連携機能により、前記ウェブリソースを利用するために必要な処理を、前記受信装置との連携動作として実行する、ものである。

［１３］また、本発明の一態様は、上記のクライアント端末装置において、前記受信端末連携制御部は、前記アプリ起動要求とともに、起動すべきアプリを特定する情報を前記受信装置に対して送信する、ものである。

［１４］また、本発明の一態様は、上記のクライアント端末装置において、前記受信端末連携制御部は、前記アプリ起動要求を送信する際に、起動すべきアプリを特定する情報を前記受信装置に対して送信せず、前記受信装置が受信する放送信号に含まれる情報によって起動すべきアプリを特定するよう前記受信装置に要求する、ものである。

［１５］また、本発明の一態様は、上記のクライアント端末装置において、前記受信端末連携制御部は、起動可否状態取得のリクエストを前記受信装置に対して送信し、前記受信装置からアプリの起動可否状態のデータを受信する、ものである。

［１６］また、本発明の一態様は、上記のクライアント端末装置において、前記受信端末連携制御部は、受信機状態取得のリクエストを前記受信装置に対して送信し、前記受信装置からアプリの受信機状態のデータを受信する、ものである。

［１７］また、本発明の一態様は、放送信号を受信する受信部、を備えるコンピューターを、上の［１］から［１０］までのいずれか一項に記載の受信装置、として機能させるためのプログラムである。

［１８］また、本発明の一態様は、コンピューターを、上の［１１］から［１６］までのいずれか一項に記載のクライアント端末装置、として機能させるためのプログラムである。

本発明によれば、受信装置において稼働するハイブリッドキャストアプリのデータを、クライアント端末装置の側においても活用することができるようになる。

本発明の実施形態によるシステムの構成を示すブロック図である。 同実施形態による受信端末装置の機能構成を示す機能ブロック図である。 同実施形態によるクライアント端末装置の機能構成を示す機能ブロック図である。 同実施形態において拡張されたハイブリッドキャストの端末連携機能を用いた、受信端末装置とクライアント端末装置との間での、リクエストおよびレスポンスのシーケンスの例を示す概略図（その１）である。 上記図４と同様の、受信端末装置とクライアント端末装置との間での、リクエストおよびレスポンスのシーケンスの例を示す概略図（その２）である。 同実施形態（手法１）により、クライアント端末装置から受信端末装置に対して、ハイブリッドキャストコンテンツの起動を要求するための、拡張されたＡＰＩを示す概略図である。 同実施形態（手法１）において、図６の起動要求の際に、クライアント端末装置から受信端末装置に送信されるデータの例を示す概略図である。 同実施形態（手法１）において、受信端末装置からクライアント端末装置に返されるレスポンスのデータの例を示す概略図である。 同実施形態（手法２）により、クライアント端末装置から受信端末装置に対して送られるハイブリッドキャストアプリ起動要求リクエストのＡＰＩを示す概略図である。 同実施形態（手法３）により、クライアント端末装置から受信端末装置に対して送られるハイブリッドキャストアプリ起動要求リクエストの新規ＡＰＩを示す概略図である。 同実施形態（手法３）において、図１０の起動要求の際に、クライアント端末装置から受信端末装置に送信されるデータの例を示す概略図である。 同実施形態（手法４）により、受信端末装置からＡＩＴ起動可否判定サーバー装置に対してリクエスト（可否問合せ）を送信するためのインターフェースの例を示す概略図である。 同実施形態（手法４）における、図１２のリクエスト（問い合わせ）に対する、ＡＩＴ起動可否判定サーバー装置から受信端末装置へのレスポンスのデータ例を示す概略図である。 同実施形態（手法４の変形例２）により、受信端末装置からＡＩＴ起動可否判定サーバー装置に対してリクエスト（可否問合せ）を送信するためのインターフェースの例を示す概略図である。 同実施形態（手法４の変形例２）における、図１４のリクエスト（問い合わせ）に対する、ＡＩＴ起動可否判定サーバー装置から受信端末装置へのレスポンスのデータ例を示す概略図である。 同実施形態（手法６）によるハイブリッドキャストアプリの起動要求（放送信号に基づいて提供されるアプリの起動）の際に、クライアント端末装置から受信端末装置に対して送信されるデータの例を示す概略図である。 同実施形態（手法７）において、クライアント端末装置が受信端末装置に対してハイブリッドキャストアプリの起動を要求するためのＡＰＩを示す概略図である。 同実施形態（手法８）において、クライアント端末装置が受信端末装置に対してハイブリッドキャストアプリの起動を要求するためのＡＰＩを示す概略図である。 同実施形態（手法１０）によって拡張された起動可否状態取得ＡＰＩにおいて、受信端末装置からクライアント端末装置に対して送信されるレスポンスのデータの例を示す概略図である。 同実施形態（手法１１）において利用可能としているハイブリッドキャストの端末連携機能のＡＰＩ（ウェブのハイブリッドキャストアプリの起動要求）を示す概略図である。 同実施形態（手法１１）において、図２０で示したリクエストに対応して、受信端末装置がクライアント端末装置に返すレスポンスデータの例を示す概略図である。 同実施形態（手法１２）で拡張したＡＰＩ（受信機状態取得）において、受信端末装置がクライアント端末装置に送信するレスポンスのデータの例を示す概略図である。 同実施形態（手法１３）で用いる、クライアント端末装置と受信端末装置との間の新規ＡＰＩ（ウェブのハイブリッドキャストアプリに関する受信機状態の取得）を示す概略図である。 同実施形態（手法１３）において、図２３で示したＡＰＩで受信端末装置からクライアント端末装置に対して送信されるレスポンスのデータの例を示す概略図である。 同実施形態によるシステムを構成する各装置の内部構成の例を示すブロック図である。

次に、本発明の一実施形態について、図面を参照しながら説明する。

本実施形態では、受信端末装置２は、放送波のリソースをウェブのプラットフォームで利活用できるようにするための機能を持つ。また、クライアント端末装置３は、受信端末装置２によって提供されるウェブのリソースを活用するための機能を持つ。受信端末装置２とクライアント端末装置３とのそれぞれは、ハイブリッドキャストの端末連携機能の拡張機能によって上記機能を実現する。

本実施形態において、放送信号から抽出された映像のリソースと音声のリソースとは、標準的なウェブのプラットフォームで用いられるネット配信動画のコンテンツとして、受信端末装置２からクライアント端末装置３に配信される。本実施形態では、ハイブリッドキャストアプリをクライアント端末装置３側で利用可能とする。ハイブリッドキャストアプリは、例えばＨＴＭＬ５で記述されるものであり、ＪａｖａＳｃｒｉｐｔ（登録商標）による実行コードを含むものであってよい。従来技術において、ハイブリッドキャストアプリは、放送受信端末が持つ専用の環境で稼働するものである。本実施形態では下に説明する手法により、クライアント端末装置３においてハイブリッドキャストアプリが稼働するようにする。

図１は、本実施形態によるシステムの構成を示すブロック図である。図示するように、システム１は、受信端末装置２と、クライアント端末装置３と、アンテナ４と、ルーター８と、通信ネットワーク９と、ＡＩＴ起動可否判定サーバー装置１１とを含んで構成される。受信端末装置２は、「受信装置」とも呼ばれる。システム１においては、受信端末装置２とクライアント端末装置３とが、ハイブリッドキャストの端末連携機能によって連携動作する。これにより、クライアント端末装置３は、受信端末装置２から提供される放送のリソースに基づくコンテンツを、提示することができる。なお、受信端末装置２と、クライアント端末装置３と、アンテナ４と、ルーター８とは、例えば、宅内あるいは事業所内等に設置され、あるいは置かれるものであってよい。この図では、受信端末装置２、クライアント端末装置３、ルーター８、ＡＩＴ起動可否判定サーバー装置１１をそれぞれ１台ずつ示しているが、システム１が含むこれらそれぞれの装置の台数は任意である。例えば複数の受信端末装置２あるいはクライアント端末装置３が１つのローカルネットワークに接続されてシステム１を構成していてもよい。システム１を構成するそれぞれの装置の機能については、次に説明する。

受信端末装置２は、アンテナ４を介して放送信号（高周波、ＲＦ）を受信する。受信端末装置２は、デジタル方式の放送信号を復調および復号し、放送信号に含まれる映像や音声や字幕等のリソースを抽出する。つまり、受信端末装置２は、いわゆるテレビ受像機である。受信端末装置２は、ローカルエリアネットワークを介して、インターネットプロトコル（ＩＰ）により、クライアント端末装置３との間で通信を行う。つまり、受信端末装置２は、ルーター８経由で、クライアント端末装置３と通信を行うことができる。受信端末装置２は、無線または有線の通信によりルーター８にアクセスすることができる。受信端末装置２上では、アプリケーションプログラム（以下、「アプリケーション」あるいは「アプリ」と呼ぶ場合がある）を稼働させることができる。受信端末装置２は、ハイブリッドキャストの端末連携機能を用いて、クライアント端末装置３と連携動作する。なお、受信端末装置２の詳細な機能構成については、後で別の図を参照しながら説明する。

クライアント端末装置３は、受信端末装置２と連携する端末装置である。クライアント端末装置３は、具体的には、ＰＣ（パーソナルコンピューター）や、タブレット端末や、スマートフォンや、スマートスピーカー等の装置であってよい。クライアント端末装置３は、アプリを稼働させることができる。クライアント端末装置３上では、受信端末装置２と連携動作するためのアプリが稼働する。クライアント端末装置３は、ハイブリッドキャストの端末連携機能を用いて、受信端末装置２と連携動作する。クライアント端末装置３は、受信端末装置２に対して、ウェブリソースを視聴するための各種の要求（リクエスト）を送信する。クライアント端末装置３は、リクエストした結果に応じて、ウェブリソースを利用することができる。即ち、クライアント端末装置３は、ウェブリソースをユーザー（視聴者）に提示する。なお、クライアント端末装置３自体は、放送信号を直接受信するためのチューナーの機能を持つ必要がない。

アンテナ４は、上記の放送信号を受信するためのものである。アンテナ４は、空中波として捉えた放送信号を、電気信号として受信端末装置２に供給する。

ルーター８は、上記のローカルエリアネットワークを構成する機器のひとつである。ルーター８は、ローカルエリアネットワークに接続されている送信元の装置から送信されるＩＰパケットを、宛先の装置側に向けて転送する。図示する構成においては、ルーター8がＩＰパケットを転送することにより、受信端末装置２とクライアント端末装置３とが相互に通信を行うことが可能となる。

通信ネットワーク９は、受信端末装置２が外部と通信する際に用いるための通信ネットワークである。受信端末装置２は、通信ネットワーク９を介して、ＡＩＴ起動可否判定サーバー装置１１や、その他の外部装置との間で通信を行うことができる。

ＡＩＴ起動可否判定サーバー装置１１は、ハイブリッドキャストアプリを起動することが可能か否かを判定して、判定結果を返す装置である。ＡＩＴ起動可否判定サーバー装置１１は、例えば受信端末装置２から、放送サービスを特定する情報と、ハイブリッドキャストアプリを特定する情報（例えば、ＡＩＴの所在情報）を受信する。ＡＩＴ起動可否判定サーバー装置１１は、その放送サービスとハイブリッドキャストアプリとの組合せにおいて、ハイブリッドキャストアプリを起動してよいか否かを判定する。放送サービスとハイブリッドキャストアプリとが関連付けられていて、その放送サービスとそのハイブリッドキャストアプリの組合せにおいてのみ、そのハイブリッドキャストアプリを起動できる場合がある。ＡＩＴ起動可否判定サーバー装置１１は、その組み合わせごとに予め可否情報を保持するなどといった方法で、判定を行い、受信端末装置２からの問い合わせに対する回答を行うことができる。

本実施形態のＡＩＴ起動可否判定サーバー装置１１は、通常の（即ち、ウェブ用ではない）ハイブリッドキャストアプリの起動可否と、ウェブ用の（言い換えれば、ウェブリソースの）ハイブリッドキャストアプリの起動可否とを、区別して判定することができる。言い換えれば、本実施形態のＡＩＴ起動可否判定サーバー装置１１は、上記の２種類のうちのいずれか一方のみの起動可否について判定を行ってもよい。あるいは、本実施形態のＡＩＴ起動可否判定サーバー装置１１は、上記の２種類の両方のそれぞれの起動可否について判定を行ってもよい。いずれの場合も、ＡＩＴ起動可否判定サーバー装置１１は、受信端末装置２からの問い合わせに応答する形で、ハイブリッドキャストアプリの起動可否の情報を受信端末装置２に渡す。なお、ＡＩＴ起動可否判定サーバー装置１１と受信端末装置２との間のインターフェースについては、後で、複数の手法のそれぞれに応じて説明する。

図２は、受信端末装置２の機能構成を示す機能ブロック図である。受信端末装置２は、放送波（放送信号）が含む映像や音声や字幕やイベント情報などといったリソース、あるいはその他のリソースを、ウェブのプラットフォームで活用可能とするための機能を持つ。具体的には、図示するように、受信端末装置２は、チューナー部２０１と、デスクランブラー２０２と、デマルチプレクサー２０３と、データ放送処理部２１１と、映像デコーダー部２１２と、音声デコーダー部２１３と、字幕デコーダー部２１４と、データ放送エンジン２２１と、通信部２３１と、ストリーミング受信部２３２と、デマルチプレクサー２３３と、映像デコーダー部２４２と、音声デコーダー部２４３と、字幕デコーダー部２４４と、アプリケーション制御部２５１と、アプリケーションエンジン２５２と、アプリケーションロンチャー２５３と、トランスコード部２６１と、ウェブリソース提供部２６２と、クライアント端末連携制御部２６３と、映像出力部２７１と、音声出力部２７２と、データ解析部２８１と、イベント処理部２８２と、ハイブリッドキャストコンテンツ変換部２９１と、を含んで構成される。

受信端末装置２の各機能部は、例えば、電子回路を用いて構成される。また、受信端末装置２が持つ少なくとも一部の機能を、コンピューターと、プログラムとで実現することが可能である。また、各機能部は、必要に応じて、記憶手段を有する。記憶手段は、例えば、プログラム上の変数や、プログラムの実行によりアロケーションされるメモリーである。また、必要に応じて、磁気ハードディスク装置やソリッドステートドライブ（ＳＳＤ）といった不揮発性の記憶手段を用いるようにしてもよい。受信端末装置２が持つ各部の機能は、次に説明する通りである。

なお、図２においては省略している機能部間のやりとりもある。それらについては、本実施形態の中で別途説明する。

チューナー部２０１は、放送信号を受信し、受信した放送信号のチューニング（選局）を行い、選局された放送信号をデスクランブラー２０２に渡す。なお、受信される放送信号は、ＩＳＤＢ－Ｔ（地上デジタル放送）やＩＳＤＢ－Ｓ（衛星デジタル放送）などの放送信号である。なお、チューナー部２０１は、「受信部」とも呼ばれる。

デスクランブラー２０２（descrambler）は、受信された放送信号をデスクランブルして出力する。デスクランブラー２０２は、デスクランブルした結果の信号を、デマルチプレクサー２０３に渡す。

デマルチプレクサー２０３（demultiplexer）は、多重送信された放送信号から、個々のリソースの信号を取り出して出力する。具体的には、デマルチプレクサー２０３は、デスクランブラー２０２から出力された信号から、データ放送の信号や、映像の信号や、音声の信号や、字幕の信号や、必要に応じてその他の信号を、それぞれ抽出して出力する。

データ放送処理部２１１は、デマルチプレクサー２０３が抽出したデータ放送の信号を処理する。データ放送の信号は、例えばＢＭＬ（Broadcast Markup Language）で記述されたコンテンツである。

映像デコーダー部２１２は、デマルチプレクサー２０３が抽出した映像のリソースを受け取り、映像としてデコード（復号）する。映像デコーダー部２１２は、デコード結果である映像を、映像出力部２７１およびトランスコード部２６１に渡す。

音声デコーダー部２１３は、デマルチプレクサー２０３が抽出した音声のリソースを受け取り、音声としてデコードする。音声デコーダー部２１３は、デコード結果である音声を、音声出力部２７２およびトランスコード部２６１に渡す。

字幕デコーダー部２１４は、デマルチプレクサー２０３が抽出した字幕のリソースを受け取り、デコードする。字幕デコーダー部２１４は、デコード結果である字幕のデータを、映像出力部２７１に渡す。さらに、字幕デコーダー部２１４は、その字幕のデータを、トランスコード部２６１にも渡してよい。

データ放送エンジン２２１は、データ放送処理部２１１から出力されたコンテンツについての処理を行う。データ放送エンジン２２１は、その処理結果を、映像として、映像出力部２７１に渡す。

通信部２３１は、外部の装置との通信を行う。通信部２３１は、例えば、インターネットプロトコル（ＩＰ）を用いて、外部と通信する。通信部２３１の機能により、受信端末装置２は、クライアント端末装置３等との間で相互に通信を行うことが可能となる。なお、通信部２３１は、後述する外部（例えば宅外）のサーバー装置（ウェブ編成情報管理サーバー装置９１等）とも通信を行うことができる。

ストリーミング受信部２３２は、通信（インターネット等）を介してストリーミング配信されるコンテンツの信号を受信する。ストリーミング受信部２３２は、受信した信号をデマルチプレクサー２３３に渡す。

デマルチプレクサー２３３は、ストリーミング受信部２３２が受信したコンテンツの信号から、各リソースのデータをそれぞれ抽出する。抽出されるデータは、映像や、音声や、字幕等のデータである。デマルチプレクサー２３３は、映像のデータを映像デコーダー部２４２に渡し、音声のデータを音声デコーダー部２４３に渡し、字幕のデータを字幕デコーダー部２４４に渡す。デマルチプレクサー２３３が、映像や音声や字幕以外の種類のリソースを抽出してもよい。

映像デコーダー部２４２は、デマルチプレクサー２３３から渡される映像のデータをデコードし、デコード後の映像を出力する。

音声デコーダー部２４３は、デマルチプレクサー２３３から渡される音声のデータをデコードし、デコード後の音声を出力する。

字幕デコーダー部２４４は、デマルチプレクサー２３３から渡される字幕のデータをデコードし、デコード後の字幕（テキスト）を出力する。

アプリケーション制御部２５１は、受信端末装置２上で稼働するアプリケーションプログラムを制御する。つまり、アプリケーション制御部２５１は、下記のアプリケーションエンジン２５２でのアプリの稼働を制御する。具体的には、アプリケーション制御部２５１は、特定のアプリケーションプログラムを起動させたり、停止させたり、その他の管理を行ったりする。アプリケーション制御部２５１は、ハイブリッドキャストの技術（規定）に基づく制御を行う。

アプリケーション制御部２５１は、クライアント端末装置３から送信されるアプリ起動要求に基づいてアプリを起動するようウェブリソース提供部２６２から指示を受ける場合がある。その場合、アプリケーション制御部２５１は、アプリを起動するための制御を行う。これにより、アプリが、アプリケーションエンジン２５２において実行される。

また、アプリを起動するようウェブリソース提供部２６２から指示を受けたときに、アプリケーション制御部２５１は、後述するように、外部のＡＩＴ起動可否判定サーバー装置１１に問い合わせを行ってもよい。この場合、アプリケーション制御部２５１は、ＡＩＴ起動可否判定サーバー装置１１からの応答に基づいて、アプリを起動させるか否かを決定する。クライアント端末装置３からの起動要求によってアプリケーション制御部２５１が起動するアプリは、ハイブリッドキャストコンテンツ変換部２９１が変換結果として出力し、クライアント端末装置３に対して送信する、ウェブプラットフォームで利用可能なアプリであってよい。

アプリケーションエンジン２５２は、受信端末装置２上で稼働するアプリケーションプログラムを稼働させる環境である。言い換えれば、アプリケーションエンジン２５２は、アプリケーションプログラムを実行させる。アプリケーションプログラムは、例えば、ＨＴＭＬ５で記述されるコンテンツである。ＨＴＭＬ５で記述されるコンテンツは、画面等に提示するためのページの定義や、実行可能なコードを含む。

アプリケーションロンチャー２５３は、特定のアプリケーションプログラムをアプリケーションエンジン２５２上で起動させるための機能を有するものである。

トランスコード部２６１は、デコードされた映像や音声のデータを受け取り、通信を介して配信するためのフォーマット（ネット動画配信フォーマット）に変換（トランスコード）する。変換先のネット動画配信フォーマットは、例えば、ＭＰＥＧ－ＤＡＳＨ（ＤＡＳＨは、「Dynamic Adaptive Streaming over HTTP」の略）やＨＬＳ（HTTP Live Streaming）である。つまり、トランスコード部２６１は、受信された放送信号から抽出されたリソース（映像リソースまたは音声リソースの少なくともいずれか）のデータを、ウェブプラットフォームで利用可能な形式のデータにトランスコードして、ウェブリソースとして出力する。トランスコード部２６１が出力するデータは、ウェブリソース提供部２６２に渡され、さらにクライアント端末装置３側に提供され得るものである。なお、トランスコード部２６１がコンテンツをトランスコードする際のパラメーターは、アプリケーション制御部２５１やクライアント端末連携制御部２６３によって制御・設定され得るものである。

ウェブリソース提供部２６２は、トランスコード部２６１から出力されるネット動画配信形式のコンテンツ（ウェブリソース）を受け取り、外部装置（クライアント端末装置３等）への配信の管理を行う。ウェブリソース提供部２６２は、トランスコード部２６１が出力した動画コンテンツを、少なくとも所定期間、蓄積しておくこともできる。ウェブリソース提供部２６２は、動画コンテンツを、通信部２３１経由で、クライアント端末装置３等に提供することができる。つまり、ウェブリソース提供部２６２は、外部に存在するクライアント端末装置３からの視聴要求に応じて、トランスコード部２６１が出力する前記ウェブリソースを、通信を介して、クライアント端末装置３に対して送信する。

また、ウェブリソース提供部２６２は、ウェブクライアント（クライアント端末装置３等）が動画コンテンツを利用するためのエンドポイント情報を生成する。エンドポイント情報は、ウェブクライアント側から見た、動画配信コンテンツのアクセス先を表す情報である。ウェブリソース提供部２６２が生成したエンドポイント情報は、クライアント端末連携制御部２６３を介して、クライアント端末装置３側に渡され得る情報である。このエンドポイント情報によって、クライアント端末装置３は、動画コンテンツを取得するためのアクセス先を知る。

本実施形態のウェブリソース提供部２６２は、さらに、チューナー部２０１が受信したＡＩＴのデータ、またはＡＩＴの所在情報（ＵＲＬ）のデータを受け取り、管理する。

また、ウェブリソース提供部２６２は、クライアント端末連携制御部２６３と疎通し、ハイブリッドキャストの端末連携機能が持つ制御に応じた処理を行う。具体的には、ウェブリソース提供部２６２は、クライアント端末装置３からの、ハイブリッドキャストアプリの起動要求や、ハイブリッドキャストアプリの起動可否状態の取得要求や、ハイブリッ
ドキャストアプリに関する受信機状態の取得要求などに対応した処理を行う。

また、ウェブリソース提供部２６２は、ハイブリッドキャストアプリのコンテンツなどを、ウェブリソースとして、クライアント端末装置３に伝送する機能を持つ。また、ウェブリソース提供部２６２は、ハイブリッドキャストコンテンツ変換部２９１と疎通し、ハイブリッドキャストアプリの伝達を行ったり、変換処理の結果を受け取ったりする機能を持つ。

つまり、ウェブリソース提供部２６２は、トランスコード部２６１が出力するウェブリソースを連携先のクライアント端末装置３に対して、通信を介して、送信する。また、ウェブリソース提供部２６２は、クライアント端末装置３から送信されるアプリ起動要求に基づいてアプリを起動するようアプリケーション制御部２５１に指示する。つまり、ウェブリソース提供部２６２は、連携先のクライアント端末装置３から送信されるアプリ起動要求に基づいてアプリを起動するようアプリケーション制御部２５１に指示し、ハイブリッドキャストコンテンツ変換部２９１が変換した結果であるウェブプラットフォームで利用可能なアプリをクライアント端末装置３に対して通信を介して送信する。

ウェブリソース提供部２６２は、後述するように、複数の方法のいずれかで、起動するアプリを決定する。

ウェブリソース提供部２６２は、一つの方法として、クライアント端末装置３からのアプリ起動要求に含まれる情報によって特定されるアプリを起動するように、アプリケーション制御部２５１に指示する。この方法では、一例として、アプリ起動要求のデータ内に、ＡＩＴのＵＲＬが含まれている。これにより、ＡＩＴがアクセス可能となる。また、ＡＩＴ内には、アプリケーションコードを特定する情報が含まれる。これにより、アプリケーション制御部２５１は、特定のアプリを起動することができる。

ウェブリソース提供部２６２は、受信された放送信号に基づいて取得したアプリケーション情報テーブル、または受信した放送信号に基づくアプリケーション情報テーブルの所在情報、の少なくともいずれかを、通信を介して、連携先のクライアント端末装置に対して送信することができる。

ウェブリソース提供部２６２は、別の方法として、チューナー部２０１が受信した放送信号に含まれる情報によって特定されるアプリを起動するように、アプリケーション制御部２５１に指示する。この方法では、一例として、受信した放送信号内に、ＡＩＴのＵＲＬが含まれている。これにより、ＡＩＴがアクセス可能となる。また、ＡＩＴ内には、アプリケーションコードを特定する情報が含まれる。これにより、アプリケーション制御部２５１は、特定のアプリを起動することができる。

ウェブリソース提供部２６２は、ハイブリッドキャストの端末連携機能のＡＰＩを介してクライアント端末装置３が情報の取得を要求してきた場合には、要求された情報をクライアント端末装置３に対して提供する場合がある。ウェブリソース提供部２６２が提供する情報とは、ウェブリソースのハイブリッドキャストアプリに関する受信機状態であったり、ウェブリソースのハイブリッドキャストアプリに関する起動可否状態であったりしてよい。つまり、ウェブリソース提供部２６２は、クライアント端末装置３からの起動可否状態取得のリクエストに応じて、ウェブプラットフォームで利用可能なアプリの起動可否状態のデータを、クライアント端末装置３に対して送信する。また、ウェブリソース提供部２６２は、クライアント端末装置３からの受信機状態取得のリクエストに応じて、ウェブプラットフォームで利用可能なアプリについての受信機状態のデータを、クライアント端末装置３に対して送信する。

クライアント端末連携制御部２６３は、受信端末装置２とクライアント端末装置３との間の連携を制御する。具体的には、クライアント端末連携制御部２６３は、ハイブリッドキャストの端末連携機能によって、受信端末装置２とクライアント端末装置３との間の連携を制御する。ハイブリッドキャストの端末連携機能自体は既存の技術であるが、クライアント端末連携制御部２６３は、本実施形態に特有の機能として、ハイブリッドキャストの端末連携機能を拡張した機能を実現するものである。

具体的には、クライアント端末連携制御部２６３は、ハイブリッドキャストの端末連携機能（拡張機能を含む）によりクライアント端末装置３との連携動作を制御するとともに、ウェブリソースを利用するために必要な情報をクライアント端末装置に送信する。クライアント端末連携制御部２６３は、少なくとも、ウェブリソースを利用するためのロケーション（エンドポイント等）の情報をクライアント端末装置３に送信する。つまり、クライアント端末連携制御部２６３は、ウェブリソース提供部２６２と疎通し、端末間の連携のための処理の結果を、クライアント端末装置３に伝達する。その際、クライアント端末連携制御部２６３は、ハイブリッドキャストの端末連携機能のＡＰＩを介してクライアント端末装置３に対する情報伝達を行ったり、ウェブソケット（WebSocket）プロトコルによって情報伝達を行ったりする。

クライアント端末連携制御部２６３は、拡張したハイブリッドキャストの端末連携機能において、次のような処理を行う。即ち、クライアント端末連携制御部２６３は、前述のエンドポイント情報を、クライアント端末装置３に対して提供する。また、クライアント端末連携制御部２６３は、放送リソースからトランスコードされたウェブリソースを利用するためのＡＰＩ（アプリケーションプログラムインターフェース）を、クライアント端末装置３に対して提供する。また、クライアント端末連携制御部２６３は、クライアント端末装置３側から渡されるトランスコード部２６１を制御するための情報を取得し、その制御情報（トランスコード処理用のパラメーター等）を、アプリケーション制御部２５１経由で、トランスコード部２６１に渡す。つまり、クライアント端末連携制御部２６３は、クライアント端末装置３からの情報に基づいて、トランスコード部２６１を制御する。なお、受信端末装置２とクライアント端末装置３との間の連携については、後でさらに詳細に説明する。

クライアント端末連携制御部２６３は、さらに、ハイブリッドキャストアプリの制御のために、次のような処理を行う機能を持つ。

クライアント端末連携制御部２６３は、クライアント端末装置３からの、ハイブリッドキャストの端末連携機能を通しての、ハイブリッドキャストアプリの起動要求を解釈する。具体的には、クライアント端末連携制御部２６３は、クライアント端末装置３からの起動要求が、どのＡＩＴに基づいてアプリを起動することを要求しているものであるかを解釈する。後述する通り、クライアント端末装置３から明示的にＡＩＴの所在情報（ＵＲＬ、ユニフォームリソースロケーター）等が指定される場合には、クライアント端末連携制御部２６３は、その所在情報によって特定されるＡＩＴに基づいてアプリを起動することが要求されていると解釈する。クライアント端末装置３から明示的にＡＩＴの所在情報（ＵＲＬ）等が指定されない場合には、クライアント端末連携制御部２６３は、受信端末装置２が放送信号から抽出したＡＩＴの情報（ＵＲＬ等）に基づいてアプリを起動することが要求されていると解釈する。明示的にＡＩＴの所在情報等が指定されないというのは、例えば、指定された情報がヌル文字列である場合や、指定された情報が具体的にＡＩＴを直接指し示すものではない場合などである。例えば、クライアント端末装置３が、放送信号から求められるＡＩＴを用いるように明示的に指示する場合にも、クライアント端末連携制御部２６３は、受信端末装置２が放送信号から抽出したＡＩＴの情報に基づいてアプリを起動することが要求されていると解釈する。

また、クライアント端末連携制御部２６３は、ハイブリッドキャストアプリの制御に関しても、クライアント端末装置３との間で、必要な情報の送受信を行う。つまり、クライアント端末連携制御部２６３は、ウェブリソース提供部２６２と疎通し、クライアント端末装置３から受信したリクエストの情報をウェブリソース提供部２６２に渡したり、ハイブリッドキャストアプリの制御の結果（レスポンス）の情報をクライアント端末装置３に送信したりする。クライアント端末連携制御部２６３は、受信端末装置２とクライアント端末装置３との間の制御情報のやり取りを、ハイブリッドキャストの端末連携機能のＡＰＩを介して行ったり、websocketによる双方向のデータ（テキスト）の送受信により行ったりする。

映像出力部２７１は、映像デコーダー部２１２や、字幕デコーダー部２１４や、映像デコーダー部２４２や、字幕デコーダー部２４４や、データ放送エンジン２２１等から渡される映像を統合して、統合された映像を出力する。つまり、映像出力部２７１は、その映像をユーザー（視聴者）に対して提示する。具体的には、映像出力部２７１は、ディスプレイ装置等に対して、提示するための映像の信号を出力する。なお、本実施形態において、受信端末装置２が、映像出力部２７１を持たない構成としてもよい。その場合にも、受信端末装置２は、映像（字幕に相当する情報を含む）をウェブリソースとしてクライアント端末装置３に提供することができる。

音声出力部２７２は、音声デコーダー部２１３や音声デコーダー部２４３から渡される音声を、外部に出力する。具体的には、音声出力部２７２は、スピーカーやイヤフォン等に対して、音声の信号を出力する。なお、本実施形態において、受信端末装置２が、音声出力部２７２を持たない構成としてもよい。その場合にも、受信端末装置２は、音声をウェブリソースとしてクライアント端末装置３に提供することができる。

データ解析部２８１は、データを解析し、映像データや音声データに関連付けられるメタデータを管理する。具体的には、データ解析部２８１は、受信端末装置２が受信して抽出した映像データを解析し、映像に含まれる人物あるいは物体の情報や、映像と同期する文字スーパー（テキスト）などを、メタデータとして管理する。また、データ解析部２８１は、受信端末装置２が受信して抽出した音声データを解析し、音声データに含まれる発話内容などの情報（話者や、発話テキスト等）をメタデータとして管理する。データ解析部２８１は、映像データや音声データに関連して管理しているメタデータを、クライアント端末装置３に提供することができる。具体的には、データ解析部２８１は、ウェブリソース提供部２６２と連携して、上記のメタデータをクライアント端末装置３に提供する。

データ解析部２８１は、例えば、放送信号から抽出した字幕データと、放送信号から抽出した音声データの解析結果（例えば、音声認識処理等を含む解析の結果）とを照合し、こうどんな字幕処理結果を生成することもできる。

また、データ解析部２８１は、上記のメタデータを、受信端末装置２が受信した番組情報（ＥＰＧ－ＡＰＩなどの情報）と照合（マッチング）させる機能を有する。ＥＰＧは、「Electronic Programming Guide」（電子番組表）の略である。

なお、データ解析部２８１が使用する映像解析や音声解析の技術自体は、既存技術である。

イベント処理部２８２は、受信した放送信号に含まれていたイベント情報に関する処理を行う。

イベント処理部２８２は、ネット動画配信向けのイベント用メタデータとして、メディアタイムドイベント（ＭＴＥ、MediaTimedEvents）のデータを生成する機能を有する。ＭＴＥのデータは、ＭＰＤもしくはＥＭＳＧである。ＭＰＤは、「Media Presentation Description」の略である。ＥＭＳＧは、インバンド（in-band）形式のメッセージを格納するための形式である。イベント処理部２８２は、トランスコード部２６１が出力したネット動画（映像や音声）に、ＭＴＥを挿入する。イベント処理部２８２は、ウェブリソース提供部２６２と連携する。つまり、ウェブリソース提供部２６２がクライアント端末装置３に対してウェブリソースを提供する際に、イベント処理部２８２が、提供されるネット動画にＭＴＥを挿入する。

イベント処理部２８２は、ＭＴＥを用いてイベントを送信する代わりに、イベントの情報を表すテキストデータを、ハイブリッドキャストの端末連携機能の双方向の端末連携通信を用いて、クライアント端末装置３側に送信することもできる。

つまり、イベント処理部２８２は、放送信号から抽出されたリソースに基づく、映像あるいは音声の少なくともいずれかに付随する付随情報を含むイベント情報を生成する。ここで、付随情報は、放送信号から抽出されたイベントメッセージと、字幕と、文字スーパーと、アプリケーション情報テーブル（ＡＩＴ）と、サービス情報（ＳＩ）と、データ放送コンテンツと、のいずれか、である。あるいは、付随情報は、放送信号から抽出された映像リソースまたは音声リソースの少なくともいずれかを解析して得られたメタデータである。

ハイブリッドキャストコンテンツ変換部２９１は、ハイブリッドキャストコンテンツがクライアント端末装置３において利用可能となるための各種の変換等を行う。ハイブリッドキャストコンテンツ変換部２９１は、単に「コンテンツ変換部」とも呼ばれる。本実施形態のハイブリッドキャストコンテンツ変換部２９１は、アプリ（ハイブリッドキャストアプリ）を、ウェブプラットフォームで利用可能な形式のアプリに変換する。具体的には、ハイブリッドキャストコンテンツ変換部２９１は、次のような処理を行う。

ハイブリッドキャストコンテンツ変換部２９１は、ハイブリッドキャストブラウザー向けに出力されるハイブリッドキャストアプリのコンテンツのデータを、一般的なウェブブラウザーで利用できる形のデータに変換する。さらに詳細には、次の通りである。ハイブリッドキャストコンテンツ変換部２９１は、ハイブリッドキャストブラウザーに専用のＡＰＩを、一般的なウェブブラウザーで利用可能なＡＰＩに変換する。また、ハイブリッドキャストコンテンツ変換部２９１は、ハイブリッドキャストブラウザーのために出力されるタグを、一般的なウェブブラウザーで解釈可能なタグに変換する。一例としては、ハイブリッドキャストコンテンツ変換部２９１は、ハイブリッドキャストコンテンツの<object>タグを、<video>タグに変換する。また、ハイブリッドキャストコンテンツ変換部２９１は、受信端末装置２の状態（ステータス）を把握するためのＡＰＩを、ハイブリッドキャストの端末連携機能が提供するＡＰＩのリクエストに変換する。例えば、ハイブリッドキャストコンテンツ変換部２９１は、受信端末装置２の状態を把握するためのＡＰＩ（ハイブリッドキャストアプリ内から呼び出し可能な関数）である「getAvailableMedia()」を、ハイブリッドキャストの端末連携機能の利用可能メディア取得ＡＰＩのリクエストに変換する。また、例えば、ハイブリッドキャストコンテンツ変換部２９１は、受信端末装置２の状態を把握するためのＡＰＩ（関数）である「getChannelInformation()」を、ハイブリッドキャストの端末連携機能のサービス一覧取得ＡＰＩのリクエストに変換する。その他のＡＰＩについても、ハイブリッドキャストコンテンツ変換部２９１は、適宜、同種の機能を有するハイブリッドキャストの端末連携機能のＡＰＩに変換する。

なお、ハイブリッドキャストアプリのＡＰＩの中には、ハイブリッドキャストの端末連携機能では代用できないものも存在する。例えば、動作環境（受信端末装置２）における郵便番号の取得のＡＰＩなどがそれに該当する。そのようなＡＰＩについては、ハイブリッドキャストコンテンツ変換部２９１は、ハイブリッドキャストの端末連携機能における端末連携通信（双方向）の機能を用いて、処理を、クライアント端末装置３側から受信端末装置２側に委託する流れを構築する。このとき、ハイブリッドキャストコンテンツ変換部２９１は、クライアント端末装置３側からのリクエストを、sendtexttohostdeviceの機能によって受信端末装置２側に送れるようにする。また、ハイブリッドキャストコンテンツ変換部２９１は、受信端末装置２での処理結果（レスポンス）を、endtexttoconpaniondeviceの機能によってクライアント端末装置３側に送れるようにする。

以上のようにして、ハイブリッドキャストコンテンツ変換部２９１は、ハイブリッドキャストアプリのコンテンツを、クライアント端末装置３で利用可能とするような処理を行う。

上記のような機能構成により、受信端末装置２は、放送信号として受信した映像や音声や字幕等のリソースを、クライアント端末装置３が持つウェブブラウザー（ウェブプラットフォーム）で提示（利用）できるようにする。即ち、受信端末装置２を用いることにより、放送リソースをウェブプラットフォームで利用できるようになる。

なお、受信端末装置２が、オプションとして、次のような機能を持つようにしてもよい。受信端末装置２は、クライアント端末装置３に対してはウェブサーバーとして機能するが、そのウェブサーバー内に、トランスコード部２６１が生成した動画データ（ｍｐ４など）を蓄積できるようにしても良い。これにより、例えばクライアント端末装置３からの要求に基づいて、巻き戻し視聴（特定の再生位置までジャンプ）を可能にしたり、ビデオオンデマンド（ＶＯＤ）による視聴を可能にしたりすることができる。また、受信端末装置２が、動画再生プレーヤーの機能や、動画再生可能なＨＴＭＬコンテンツを持つようにしてもよい。これにより、クライアント端末装置３が動画再生プレーヤーの機能を持たない場合にも、動画の再生をすることが可能となる。また、受信端末装置２が、動画配信の際に、チャンク転送エンコーディング（chunked-transfer-encoding）を用いることができるようにしてもよい。これにより、ＣＭＡＦ（Common Media Application Format）での超低遅延配信を実現することも可能となる。

図３は、クライアント端末装置３の内部の概略機能構成を示すブロック図である。図示するように、クライアント端末装置３は、通信部３３１と、アプリケーションエンジン３５２と、アプリケーションロンチャー３５３と、受信端末連携制御部３６３とを含んで構成される。クライアント端末装置３は、電子回路を用いて実現可能である。クライアント端末装置３が持つ機能の少なくとも一部を、コンピューターとプログラムとで実現してもよい。各部の機能は、次の通りである。

なお、クライアント端末装置３を構成する機能は、必ずしもすべて同一のハードウェア上に実現される必要はない。複数の装置（ハードウェア）上に分散する形（疎結合）でクライアント端末装置３を実現してもよい。

通信部３３１は、外部の装置との通信を行う。通信部３３１は、例えば、インターネットプロトコル（ＩＰ）を用いて、外部と通信する。通信部３３１の機能により、クライアント端末装置３は、受信端末装置２等との間で相互に通信を行うことが可能となる。

アプリケーションエンジン３５２は、アプリケーションプログラムを実行させるものである。図示するように、例えばウェブアプリケーションは、アプリケーションエンジン３５２上で実行されるプログラムの一つである。具体的には、アプリケーションエンジン３５２は、受信端末装置２からウェブリソースを受信して利用するウェブアプリケーションを稼働させる。

上記のウェブアプリケーションは、ウェブコンテンツを表示する機能を有するものである。ウェブコンテンツは、ＨＴＭＬ（ハイパーテキストマークアップ言語）で記述されたコンテンツや、ＭＰＥＧ－ＤＡＳＨ動画再生プレーヤーなどを含むものである。

アプリケーションロンチャー３５３は、アプリケーションエンジン３５２上で特定のアプリケーションプログラムを起動させるものである。アプリケーションロンチャー３５３は、例えばユーザーの操作等に基づいて、上記のウェブアプリケーションを起動させる。

受信端末連携制御部３６３は、受信端末装置２との間で、ハイブリッドキャストの端末連携機能による連携動作を行う。具体的には、受信端末連携制御部３６３は、受信端末装置２が提供するウェブリソースを利用するための情報を、ハイブリッドキャストの端末連携機能のＡＰＩを介して取得する。ハイブリッドキャストの端末連携機能は標準化された技術であるため、受信端末装置２とクライアント端末装置３との間では、装置のメーカー等に依存しない形で、相互に連携することが可能となる。

つまり、受信端末連携制御部３６３は、ハイブリッドキャストの端末連携機能により、ウェブリソースを利用するために必要な処理を、受信端末装置２との連携動作として実行する。具体的には、受信端末連携制御部３６３は、少なくとも、ウェブリソースを利用するためのロケーション（エンドポイント等）の情報を受信端末装置２から受信する。また、受信端末連携制御部３６３は、受信端末装置２のハイブリッドキャストコンテンツ変換部２９１が出力するウェブプラットフォームで利用可能なアプリを取得するためのアプリ起動要求を受信端末装置２に対して送信する。

受信端末連携制御部３６３が上記のアプリ起動要求を送信する際に、特定のアプリを指定するための情報を付けて送信する方法と、特定のアプリを指定するための情報を付けずに送信する方法との、どちらかを取り得る。前者の場合には、受信端末連携制御部３６３は、アプリ起動要求とともに、起動すべきアプリを特定する情報として、例えば、ＡＩＴのＵＲＬを送信してよい。そのＵＲＬによって特定されるＡＩＴは、アプリの所在情報を含んでいる。後者の場合には、受信端末連携制御部３６３は、アプリ起動要求の際に、起動すべきアプリを特定する情報を送信しない。この場合、受信端末連携制御部３６３は、例えば、上記ＡＩＴのＵＲＬの代わりにヌル文字列を送信したり、アプリを特定しないことを示す所定のデータを送信したりしてよい。この場合、受信端末装置２は、例えば、放送信号からＡＩＴのＵＲＬ等のアプリを特定する情報を抽出し、それによって特定されるアプリを起動することができる。

また、受信端末連携制御部３６３は、受信端末装置２から情報を取得するためのリクエストを受信端末装置２に対して送信することができる。具体的には、受信端末連携制御部３６３は、アプリの起動可否状態取得のリクエストを送信する。受信端末連携制御部３６３は、このリクエストに対応して受信端末装置２が送信する起動可否状態のデータを受信する。また、受信端末連携制御部３６３は、アプリの受信機状態取得のリクエストを送信する。受信端末連携制御部３６３は、このリクエストに対応して受信端末装置２が送信する受信機状態のデータを受信する。なお、受信端末装置２側で稼働する上記のアプリは、ハイブリッドキャストアプリであってよい。また、そのアプリからの出力であるコンテンツが、クライアント端末装置３で利用可能なウェブリソースであってよい。

図４および図５は、本実施形態において拡張されたハイブリッドキャストの端末連携機能を用いた、受信端末装置２とクライアント端末装置３との間での、リクエストおよびレスポンスのシーケンスの例を示す概略図である。

図示するステップＳ１０１からＳ１１５まで、およびステップＳ１２１からＳ１３２までの処理のうち、ステップＳ１０１からＳ１１５までが、従来のハイブリッドキャストの端末連携機能においても存在するＡＰＩ（リクエストおよびレスポンス等）によるものである。ただし、従来のリクエストあるいはレスポンスの少なくとも一部が本実施形態のために拡張される場合もある。つまり、以下に説明するステップＳ１０１からＳ１１５までの処理のすべてが従来技術に属するものであるというわけではない。また、ステップＳ１２１からＳ１３２までの処理が、特に本実施形態に特有の拡張されたハイブリッドキャストの端末連携機能のＡＰＩ（リクエストおよびレスポンス）によるものである。

また、受信端末装置２とクライアント端末装置３とが、これらのステップＳ１０１からＳ１１５まで、およびステップＳ１２１からＳ１３２までのすべての手順を順次実行するとは限らない。なお、図示する通り、ステップＳ１１５の処理以外は、リクエストとレスポンスの対としてまとまった処理である。ステップＳ１１５の処理は、双方向通信であり、その中の具体的な手順は、適用する処理内容およびデータ内容に依存する。

以下では、図４および図５のそれぞれについて順に説明する。

図４のステップＳ１０１において、クライアント端末装置３は、受信端末装置２に対して、機器発見のリクエストを送信する。上記のリクエストに対して、ステップＳ１０２において、受信端末装置２は、クライアント端末装置３に対して、機器発見のレスポンスを送信する。

ステップＳ１０３において、クライアント端末装置３は、受信端末装置２に対して、認証のリクエストを送信する。上記のリクエストに対して、ステップＳ１０４において、受信端末装置２は、クライアント端末装置３に対して、認証のレスポンスを送信する。

ステップＳ１０５において、クライアント端末装置３は、受信端末装置２に対して、利用可能メディア取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１０６において、受信端末装置２は、クライアント端末装置３に対して、利用可能メディア取得のレスポンスを送信する。

ステップＳ１０７において、クライアント端末装置３は、受信端末装置２に対して、編成サービス一覧取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１０８において、受信端末装置２は、クライアント端末装置３に対して、編成サービス一覧取得のレスポンスを送信する。

ステップＳ１０９において、クライアント端末装置３は、受信端末装置２に対して、選局・ＨＣアプリ起動要求のリクエストを送信する。上記のリクエストに対して、ステップＳ１１０において、受信端末装置２は、クライアント端末装置３に対して、選局・ＨＣアプリ起動要求のレスポンスを送信する。なお、「ＨＣ」は、ハイブリッドキャストの略である。

ステップＳ１１１において、クライアント端末装置３は、受信端末装置２に対して、起動可否状態取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１１２において、受信端末装置２は、クライアント端末装置３に対して、起動可否状態取得のレスポンスを送信する。

ステップＳ１１３において、クライアント端末装置３は、受信端末装置２に対して、受信機状態取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１１４において、受信端末装置２は、クライアント端末装置３に対して、受信機状態取得のレスポンスを送信する。なお、ここで「受信機」とは、受信端末装置２を指すものである。

ステップＳ１１５において、クライアント端末装置３および受信端末装置２は、双方向に通信を行う。これにより、クライアント端末装置３と受信端末装置２とが連携動作することが可能となる。つまり、クライアント端末装置３と受信端末装置２とは、端末連携通信を行う。

図５に移り、ステップＳ１２１において、クライアント端末装置３は、受信端末装置２に対して、ウェブリソース機器発見のリクエストを送信する。上記のリクエストに対して、ステップＳ１２２において、受信端末装置２は、クライアント端末装置３に対して、ウェブリソース機器発見のレスポンスを送信する。この「ウェブリソース機器発見」のリクエストおよびレスポンスは、従来のハイブリッドキャストの端末連携機能の技術では存在しない手順である。

ステップＳ１２３において、クライアント端末装置３は、受信端末装置２に対して、ウェブリソース利用可否取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１２４において、受信端末装置２は、クライアント端末装置３に対して、ウェブリソース利用可否取得のレスポンスを送信する。この「ウェブリソース利用可否取得」のリクエストおよびレスポンスは、従来のハイブリッドキャストの端末連携機能の技術では存在しない手順である。

ステップＳ１２５において、クライアント端末装置３は、受信端末装置２に対して、ウェブサービス一覧取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１２６において、受信端末装置２は、クライアント端末装置３に対して、ウェブサービス一覧取得のレスポンスを送信する。この「ウェブサービス一覧取得」のリクエストおよびレスポンスは、従来のハイブリッドキャストの端末連携機能の技術では存在しない手順である。

ステップＳ１２７において、クライアント端末装置３は、受信端末装置２に対して、ウェブサービス起動要求のリクエストを送信する。上記のリクエストに対して、ステップＳ１２８において、受信端末装置２は、クライアント端末装置３に対して、ウェブサービス起動要求のレスポンスを送信する。この「ウェブサービス起動要求」のリクエストおよびレスポンスは、従来のハイブリッドキャストの端末連携機能の技術では存在しない手順である。

ステップＳ１２９において、クライアント端末装置３は、受信端末装置２に対して、ウェブサービス起動可否状態取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１３０において、受信端末装置２は、クライアント端末装置３に対して、ウェブサービス起動可否状態取得のレスポンスを送信する。この「ウェブサービス起動可否状態取得」のリクエストおよびレスポンスは、従来のハイブリッドキャストの端末連携機能の技術では存在しない手順である。

ステップＳ１３１において、クライアント端末装置３は、受信端末装置２に対して、ウェブサービス状態取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１３２において、受信端末装置２は、クライアント端末装置３に対して、ウェブサービス状態取得のレスポンスを送信する。この「ウェブサービス状態取得」のリクエストおよびレスポンスは、従来のハイブリッドキャストの端末連携機能の技術では存在しない手順である。

次に、クライアント端末装置３からの要求に基づいて、ハイブリッドキャストアプリを制御したり、ハイブリッドキャストアプリの稼働状態等に関する情報を取得したりするためのそり手順について、説明する。具体的には、以下において、手法１から手法１３までのそれぞれについて説明する。また、これらの手法のバリエーション（変形例）についても説明する。

［手法１］ハイブリッドキャストの端末連携機能経由での、ハイブリッドキャストコンテンツの活用（その１ ハイブリッドキャストの端末連携機能の機能拡張）
本手法では、ハイブリッドキャストの端末連携機能を拡張することによって、クライアント端末装置３側からのハイブリッドキャストコンテンツの起動を可能にする。ここで使用されるＡＰＩは、図４のステップＳ１０９（リクエスト）およびＳ１１０（レスポンス）である。本手法では、このＡＰＩを拡張する。

本手法では、具体的には、システム１は次のように動作する。即ち、受信端末装置２とクライアント端末装置３との間では、相互の機器発見に基づいて既にペアリングが確立している。即ち、受信端末装置２とクライアント端末装置３とは既に連携している。その状態から、クライアント端末装置３は、受信端末装置２に対して、ハイブリッドキャストコンテンツの起動要求（mode=app）を送信する。受信端末装置２は、この起動要求を受け取り、指定されたハイブリッドキャストアプリケーションを起動させる。具体的には、受信端末装置２は、クライアント端末装置３からの起動要求に含まれる"resource"の指定にしたがって、放送サービス（チャンネル）を選局するとともに、上記起動要求に含まれるハイブリッドキャストのＡＩＴ（アプリケーション情報テーブル）のＵＲＬの情報にしたがって、ハイブリッドキャストアプリケーションを取得する。

図６は、本手法によってクライアント端末装置３がハイブリッドキャストコンテンツの起動を要求するための、拡張されたＡＰＩを示す概略図である。図示する通り、このＡＰＩのＵＲＬは、「＜BaseURL＞/hybridcast」である。なお、＜BaseURL＞は、所定の、基底となるＵＲＬである（以後においても同様）。このＡＰＩを呼び出すためのメソッドはＰＯＳＴである。

図７は、上記の選局・ハイブリッドキャストアプリ起動要求（図４のステップＳ１０９（リクエスト））の際にクライアント端末装置３から受信端末装置２に送信されるデータの例を示す概略図である。このデータは、例えば、ＪＳＯＮ（JavaScript Object Notation）の形式で記述される。図示するように、このデータは、"resource"のブロック（第２行目から第６行目まで）と"hybridcast"のブロック（第７行目から第１１行目まで）とを有する。"resource"のブロックは、上記の通り、選局対象とする放送サービスを特定する情報を持つ。具体的には、放送サービスは、トランスポートストリームＩＤ（transport_stream_id）と、オリジナルネットワークＩＤ（original_network_id）と、サービスＩＤ（service_id）との組で指定され得る。"hybridcast"のブロックは、上で説明したハイブリッドキャストのＡＩＴ（アプリケーション情報テーブル）のＵＲＬの所在情報（ＵＲＬ）を含む。"hybridcast"のブロックは、他に、組織ＩＤ（orgid）と、アプリケーションＩＤ（app_id）の情報を持っている。

上記の選局・ハイブリッドキャストアプリ起動のリクエストを受けると、受信端末装置２は、ハイブリッドキャストアプリケーションを起動させるとともに、クライアント端末装置３がハイブリッドキャストコンテンツを利用するための処理を行う。つまり、受信端末装置２のハイブリッドキャストコンテンツ変換部２９１は、ハイブリッドキャストコンテンツをウェブリソースに変換する。また、ハイブリッドキャストコンテンツ変換部２９１は、変換結果であるハイブリッドキャストコンテンツをクライアント端末装置３が利用するためのＵＲＬを生成する。受信端末装置のウェブリソース提供部２６２は、取得したハイブリッドキャストコンテンツを、クライアント端末装置３に提供する。即ち、ウェブリソース提供部２６２は、上記のリクエストに対応するレスポンスを、クライアント端末装置３に送信する。

図８は、受信端末装置２からクライアント端末装置３に返されるレスポンス（図４のステップＳ１１０に相当）のデータの例を示す概略図である。このデータは、例えばＪＳＯＮ形式で記述される。図示するように、このデータは、ヘッダー（"head"）のブロック（第２行目から第５行目まで）とボディー（"body"）のブロック（第６行目から第９行目まで）とを持つ。ヘッダー（"head"）のデータは、ハイブリッドキャストアプリケーションが起動したことを示すものである。ボディー（"body"）のデータは、タスクＩＤ（taskid）の情報とウェブハイブリッドキャストＵＲＬ（webhybridcasturl）の情報とを持つ。タスクＩＤは、稼働するタスク（ここでは、ハイブリッドキャストアプリ）を一意に識別するための情報である。また、ウェブハイブリッドキャストＵＲＬは、上述のハイブリッドキャストコンテンツ変換部２９１が生成した、ウェブリソースとしてのハイブリッドキャストコンテンツを利用するための所在情報である。本例では、そのＵＲＬは、「/webhybridcast/15180375.html」である。つまり、本例では、上記のタスクＩＤを用いたＵＲＬとしている。なお、このＵＲＬ情報は、「エンドポイント」とも呼ばれる。

［手法１の変形例１ ハイブリッドキャストコンテンツのＵＲＬ指定方法］
ここで、本手法の変形例について、説明する。上の説明では、受信端末装置２からクライアント端末装置３へのレスポンスの中に、ウェブハイブリッドキャストＵＲＬの情報を含めるようにした。代わりに、変形例１として、レスポンス内にはＵＲＬ情報を含めず、予めクライアント端末装置３側でもわかっている特定のＵＲＬ（エンドポイント）で、クライアント端末装置３が、ハイブリッドキャストコンテンツを利用できるようにしてもよい。その場合、一例としては、固定のＵＲＬを用いてもよい。

ただし、複数のクライアント端末装置３が同時に稼働する場合には、ＵＲＬが競合しないように工夫することが必要である。例えば、クライアント端末装置３ごとに固有の文字列（端末ＩＤ等）を含むＵＲＬを使用する。あるいは、本変形例を用いず、リクエストの発生の都度、動的にＵＲＬを生成するようにする。

［手法１の変形例２ ハイブリッドキャストコンテンツ変換部２９１による変換処理の一例］
上記のハイブリッドキャストコンテンツ変換部２９１がハイブリッドキャストコンテンツをクライアント端末装置３側で利用可能なウェブリソースに変換する処理の具体的な内容は、様々であるが、ここではその一例を説明する。

受信端末装置２は、前述の通り、テレビ受像機である。つまり、受信端末装置２上では、ハイブリッドキャストブラウザーが稼働する。本手法では、ハイブリッドキャストアプリが出力するコンテンツを、一般的なウェブブラウザー（例えば、Chrome等）でも利用可能とするため、ハイブリッドキャストコンテンツ変換部２９１は、タグの変換を行う。ハイブリッドキャストアプリは、例えば放送コンテンツを表示するためのタグとして<object>タグを用いる。ハイブリッドキャストコンテンツ変換部２９１は、この<object>タグを<video>タグに変換する。これにより、クライアント端末装置３側で稼働するブラウザーは、<video>タグで提供される動画を視聴者に提示することができる。

また、ハイブリッドキャストアプリが提供するハイブリッドキャストブラウザー向けのＡＰＩを、ハイブリッドキャストコンテンツ変換部２９１が、一般的なウェブブラウザーでも利用できるように変換してもよい。ハイブリッドキャストアプリは元々ハイブリッドキャストブラウザーで動作することが想定されているが、このようにＡＰＩを変換するようにすれば、一般的なウェブブラウザーにおいてもハイブリッドキャストアプリが利用可能となる。

例えば、ハイブリッドキャストアプリのＡＰＩ（郵便番号の取得等）では、ハイブリッドキャストの端末連携機能におけるsendtextの機能を用いて、レスポンスのデータをテキストデータとして、受信端末装置２からクライアント端末装置３に送信するようにしてもよい。

［手法１の変形例３ クライアント端末装置３側でのハイブリッドキャストコンテンツの変換処理］
上では、受信端末装置２内のハイブリッドキャストコンテンツ変換部２９１が変換したコンテンツを、受信端末装置２からクライアント端末装置３に送信するようにしていた。本変形例では、受信端末装置２側では、ハイブリッドキャストコンテンツの変換を行わない。受信端末装置２は、ハイブリッドキャストアプリが出力するコンテンツのデータを、そのまま、クライアント端末装置３に送信する。クライアント端末装置３側には、既に説明した受信端末装置２内のハイブリッドキャストコンテンツ変換部２９１と同様の変換処理の機能を持たせる。そして、クライアント端末装置３側にてハイブリッドキャストコンテンツの変換処理を行うようにする。これにより、クライアント端末装置３側でハイブリッドキャストコンテンツを利用することが可能となる。

［手法１の変形例４ 一般のウェブブラウザーで使用可能なハイブリッドキャストアプリを使用］
本変形例では、受信端末装置２側には、ハイブリッドキャストコンテンツ変換部２９１を持たない。本変形例では、代わりに、一般のウェブブラウザー（Chrome等）でも利用可能なハイブリッドキャストアプリを、予め用意しておく。ハイブリッドキャストアプリを受信端末装置２に対して提供するサーバー装置が、通常のハイブリッドキャストアプリの代わりに、一般のウェブブラウザーでも利用可能なハイブリッドキャストアプリを提供するようにする。受信端末装置２は、そのサーバー装置から、一般のウェブブラウザーでも利用可能なハイブリッドキャストアプリを取得して稼働させる。これにより、クライアント端末装置３側でハイブリッドキャストコンテンツを利用することが可能となる。

［手法２ ハイブリッドキャストの端末連携機能経由での、ハイブリッドキャストコンテンツの活用（その２ ハイブリッドキャストの端末連携機能の別の機能拡張）］
本手法においても、ハイブリッドキャストの端末連携機能を拡張することによって、クライアント端末装置３側からのハイブリッドキャストコンテンツの起動を可能にする。本手法では、クライアント端末装置３が選局・ＨＣアプリ起動要求のＡＰＩ（図４のステップＳ１０９（リクエスト））を呼び出す際に、クエリーパラメーターとして「mode=web」を指定できるようにする。

図９は、本手法におけるクライアント端末装置３からのハイブリッドキャストアプリ起動要求リクエストのＡＰＩを示す概略図である。図示するように、このＡＰＩを呼び出すためのＵＲＬとメソッドとは、図６に示したものと同様である。ただし、図９で示すＡＰＩにおいては、拡張クエリーとして「mode=web」を指定するようになっている。このようなリクエストを受ける受信端末装置２は、このクエリーパラメーター「mode=web」を取得することにより、クライアント端末装置３からの要求がウェブでのハイブリッドキャストコンテンツの利用を求めるものであることを明示的に把握できる。

なお、本手法において、クライアント端末装置３から受信端末装置２に対するリクエストの際に送信されるデータは、図７を参照しながら説明したデータと同様のものであってよい。

［手法３ ハイブリッドキャストの端末連携機能経由での、ハイブリッドキャストコンテンツの活用（その３ ハイブリッドキャストの端末連携機能での新規ＡＰＩ）］
本手法では、クライアント端末装置３から受信端末装置２に対するハイブリッドキャストアプリの起動要求のために、新規ＡＰＩを使用することを可能とする。

図１０は、ウェブプラットフォームで利用するための、クライアント端末装置３から受信端末装置２へのハイブリッドキャストアプリの起動要求のＡＰＩを示す概略図である。図示するように、「webhybridcast」という新規のＡＰＩを、クライアント端末装置３側から利用可能としている。このＡＰＩのＵＲＬは「＜BaseURL＞/webhybridcast」である。また、このＡＰＩを呼ぶためのメソッドはＰＯＳＴである。

図１１は、本手法のＡＰＩを介してウェブプラットフォームで利用するためのハイブリッドキャストアプリの起動を要求する際に、クライアント端末装置３が受信端末装置２に対して送信されるデータの例を示す概略図である。図示するように、このデータもまた、"resource"のブロック（第２行目から第６行目まで）と"hybridcast"のブロック（第７行目から第１１行目まで）とを持つ。"resource"のブロックは、上記の通り、選局対象とする放送サービスを特定する情報（トランスポートストリームＩＤ（transport_stream_id）、オリジナルネットワークＩＤ（original_network_id）、サービスＩＤ（service_id））を持つものである。"hybridcast"のブロックは、上で説明したハイブリッドキャストのＡＩＴ（アプリケーション情報テーブル）のＵＲＬの所在情報（ＵＲＬ）を含む。

［手法４］ハイブリッドキャストアプリの起動可否判定サーバー装置に対する問い合わせ
本手法では、システム１において受信端末装置２がＡＩＴ起動可否判定サーバー装置１１に対する問い合わせを行えるようにする。ＡＩＴ起動可否判定サーバー装置１１は、指定されたハイブリッドキャストアプリケーションプログラムがいかなる形態で稼働可能であるかを表す情報を、受信端末装置２に与える。

具体的には、システム１は次の手順で動作する。クライアント端末装置３は、受信端末装置２に対して、ハイブリッドキャストアプリの起動を要求する。クライアント端末装置３からの要求の方法は、前述の手法１から３までのどの手法であってもよい。受信端末装置２は、クライアント端末装置３からの要求を受けると、ＡＩＴ起動可否判定サーバー装置１１に対して、ハイブリッドキャストアプリの起動可否を問い合わせる。これに応じて、ＡＩＴ起動可否判定サーバー装置１１は、問い合わせ元の受信端末装置２に対して、起動可否の情報を応答する。受信端末装置２は、ＡＩＴ起動可否判定サーバー装置１１からの応答に応じて、クライアント端末装置３側から要求されたハイブリッドキャストアプリを起動するか否かを決定する。

ＡＩＴ起動可否判定サーバー装置１１から起動不可の応答を得た場合には、受信端末装置２は、その形態でのハイブリッドキャストアプリを起動しない。また、その場合、受信端末装置２は、必要に応じてその形態でのハイブリッドキャストアプリの起動を要求したクライアント端末装置３に対して、処理結果として何らかのエラーを報告してもよい。

ＡＩＴ起動可否判定サーバー装置１１から起動可能の応答を得た場合には、受信端末装置２は、その形態でのハイブリッドキャストアプリを起動する。また、その場合、受信端末装置２は、必要に応じてその形態でのハイブリッドキャストアプリの起動を要求したクライアント端末装置３に対して、処理結果として正常完了を、ないしは同種の結果を報告してもよい。

図１２は、本手法における、受信端末装置２からＡＩＴ起動可否判定サーバー装置１１に対してリクエストを送信するためのインターフェースの例を示す概略図である。図示するように、このリクエストは、ハイブリッドキャストアプリの起動可否を問い合わせるものであり、メソッドはＧＥＴである。このリクエストのＵＲＬは、ＡＩＴ起動可否判定サーバー装置１１のＵＲＬと、クエリー文字列とを含む。受信端末装置２は、クライアント端末装置３から受信したハイブリッドキャストアプリの起動リクエストの内容に基づいて、このクエリー文字列を作成する。図示する例において、クエリー文字列は、「transport_stream_id=32736&original_network_id=32736&service_id=1024&aiturl=https%3A%2F%2Fexample.com%2Fait.xml&orgid=16&appid=5」である。つまり、このクエリー文字列は、図７や図１１で例示した、選局・ハイブリッドキャストアプリ起動要求のデータに対応する。上記の通り、クエリー文字列は、トランスポートストリームＩＤ、オリジナルネットワークＩＤ、サービスＩＤ、ＡＩＴのＵＲＬ、ＯＲＧＩＤ、ＡＰＰＩＤを具体的に特定するものである。

図１３は、図１２のリクエスト（問い合わせ）に対する、ＡＩＴ起動可否判定サーバー装置１１から受信端末装置２への応答のデータ例を示す概略図である。図示するように、このデータは、ヘッダー（"head"）のブロック（第２行目から第５行目まで）とボディー（"body"）のブロック（第６行目から第９行目まで）とを有する。ボディーのブロックは、通常の（ウェブのコンテンツとして出力されない）ハイブリッドキャストアプリとしての起動可否の情報と、ウェブ用に出力されるハイブリッドキャストアプリとしての起動可否の情報とを、それぞれ持つ。ここに図示する例では、「hybridcast」のラベルで示されるデータは「OK」である。これは、通常のハイブリッドキャストアプリとしての起動が可能であることを表す。また、「webhybridcast」のラベルで示されるデータは「OK」である。これは、ウェブリソースとして出力されるハイブリッドキャストアプリとしての起動が可能であることを表す。

上の例のように、ＡＩＴ起動可否判定サーバー装置１１は、パラメーターで指定されたハイブリッドキャストアプリの、通常のハイブリッドキャストアプリとしての起動の可否の情報と、ウェブ用のハイブリッドキャストアプリとしての起動の可否の情報とを、受信端末装置２に送信する。

［手法４の変形例１ ＡＩＴ起動可否判定サーバー装置］
この手法４で用いるＡＩＴ起動可否判定サーバー装置１１は、通常のハイブリッドキャストアプリとしての起動の可否の情報と、ウェブ用のハイブリッドキャストアプリとしての起動の可否の情報と、の両方を、受信端末装置２に送信するものである。変形例として、通常のハイブリッドキャストアプリとしての起動の可否の情報を受信端末装置２に返すＡＩＴ起動可否判定サーバー装置と、ウェブ用のハイブリッドキャストアプリとしての起動の可否の情報を受信端末装置２に返すＡＩＴ起動可否判定サーバー装置とを、別々に分けても受けてもよい。その場合には、これら２種類のＡＩＴ起動可否判定サーバー装置は、それぞれ独自のＵＲＬでアクセスされる。受信端末装置２は、必要に応じて、いずれか一方、あるいは両方のＡＩＴ起動可否判定サーバー装置に対して問い合わせを行うことができる。

［手法４の変形例２ クエリー文字列内のパラメーターのキーワードにより、通常のハイブリッドキャストアプリとしての起動の問い合わせか、ウェブ用のハイブリッドキャストアプリとしての起動の問い合わせかを区別］
手法４の変形例２では、クエリー文字列内のキーワードによって、通常のハイブリッドキャストアプリについての問い合わせか、ウェブ用のハイブリッドキャストアプリについての問い合わせか、を区別する。

図１４は、本変形例における、受信端末装置２からＡＩＴ起動可否判定サーバー装置１１に対してリクエストを送信するためのインターフェースの例を示す概略図である。図１２で示したリクエスト（クエリー）の例では、ＡＩＴのＵＲＬを指定するパラメーター用のキーワードは「aiturl」であった。一方、本変形例の図１４で示すリクエストの例では、「webaiturl」というキーワードで、ＡＩＴのＵＲＬを指定している。即ち、当該部分の文字列は「・・・webaiturl=https%3A%2F%2Fexample.com%2Fait.xml・・・」である。この例のように、キーワード「webaiturl」を用いて指定されたＵＲＬは、ウェブ用のハイブリッドキャストアプリとしての起動の可否を問い合わせる対象となるＡＩＴのＵＲＬである。なお、キーワード「aiturl」を指定する場合には、そのクエリーは、通常のハイブリッドキャストアプリについての問い合わせである。

図１５は、図１４のリクエストに対応してＡＩＴ起動可否判定サーバー装置１１が返すレスポンスのデータ例を示す概略図である。図示するように、このレスポンスのデータは、ヘッダー（"head"）のブロックのみを持つ。本例のレスポンスは、ヘッダーに記述された内容として、コード（"code"）の値「２００」と、メッセージ（"message"）の値「ＯＫ」を持つ。このレスポンスのデータは、ハイブリッドキャストアプリが起動可能であることを表す。起動不可である場合には、ＡＩＴ起動可否判定サーバー装置１１は、起動不可であることを表すデータを、レスポンスとして返す。

この変形例では、受信端末装置２からの問い合わせ時のキーワードによって、通常のアプリかウェブ用のアプリか、どちらについての問い合わせであるかを明示するようにしている。これにより、ＡＩＴ起動可否判定サーバー装置１１が返すレスポンスのデータを、シンプルな構造のデータとすることができる。

［手法５ 放送信号に基づくハイブリッドキャストコンテンツの活用（その１）］
本手法では、クライアント端末装置３側からＡＩＴの所在情報（ＵＲＬ）を指定するのではなく、放送信号に含まれるＡＩＴの所在情報に基づくハイブリッドキャストコンテンツを、クライアント端末装置３側で活用できるようにする。

具体的には、次の通りである。受信端末装置２が受信する放送信号には、ハイブリッドキャストアプリを起動するためのＡＩＴのＵＲＬが含まれている。このようなアプリは、放送マネージドアプリとも呼ばれる。また、受信端末装置２は、ハイブリッドキャストの端末連携機能の所定の手順により、予めクライアント端末装置３との間のペアリングを完了している。即ち、受信端末装置２は、そのクライアント端末装置３と連携している。この状況において、クライアント端末装置３は、ハイブリッドキャストの端末連携機能におけるsendtext（テキスト送信）の機能を用いて、受信端末装置２に対して、ハイブリッドキャストアプリの起動を要求する。sendtextは、ハイブリッドキャストの端末連携機能のwebsocket（双方向の連携端末通信）が提供する機能の一つである。クライアント端末装置３からのリクエストのデータには、ハイブリッドキャストアプリのＡＩＴの所在情報が含まれない。つまり、クライアント端末装置３は、受信端末装置２が放送信号から抽出したＡＩＴの所在情報に基づいて、ハイブリッドキャストアプリを起動することを、受信端末装置２に対して、要求している。

上記のクライアント端末装置３からのリクエストに応じて、受信端末装置２は、放送信号から抽出されたＵＲＬに基づいてＡＩＴを取得し、そのＡＩＴを用いてハイブリッドキャストアプリを起動する。受信端末装置２のハイブリッドキャストコンテンツ変換部２９１は、そのハイブリッドキャストアプリからの出力を変換してウェブプラットフォームで利用可能な形態とする。ウェブリソース提供部２６２は、sendtextの機能を用いてクライアント端末装置３に対して、ハイブリッドキャストアプリにアクセスするためのＵＲＬを送信する。これにより、クライアント端末装置３は、ウェブプラットフォームを用いて、ハイブリッドキャストコンテンツを利用できる。

上記の通り、本手法では、クライアント端末装置３から受信端末装置２に対して、連携端末通信の機能を用いて、ハイブリッドキャストアプリの起動を要求する。ただし、クライアント端末装置３はＡＩＴの所在情報を送信する必要がない。また、受信端末装置２は、ハイブリッドキャストアプリを起動するとともに、そのコンテンツを利用するためのＵＲＬの情報を、クライアント端末装置３に対して、連携端末通信の機能を用いて送信する。

［手法６ 放送信号に基づくハイブリッドキャストコンテンツの活用（その２）］
本手法でも、上で説明した手法５と同様に、受信端末装置２は、放送信号から取得したＡＩＴの所在受法に基づいて、ハイブリッドキャストアプリを起動する。ただし、本手法では、クライアント端末装置３は、ハイブリッドキャストの端末連携機能の、ハイブリッドキャストアプリ起動のリクエストを用いる。

具体的には、次の通りである。受信端末装置２が受信する放送信号には、ハイブリッドキャストアプリを起動するためのＡＩＴのＵＲＬが含まれている。また、受信端末装置２は、ハイブリッドキャストの端末連携機能の所定の手順により、予めクライアント端末装置３との間のペアリングを完了している。その状況において、クライアント端末装置３は、ハイブリッドキャストの端末連携機能のＡＰＩを介して、受信端末装置２に対して、ハイブリッドキャストアプリの起動を要求する。なお、これは、「mode=app」による起動要求である。この起動要求のＡＰＩについては、図６を参照して説明した通りである。

図１６は、上記のハイブリッドキャストアプリの起動要求の際に、クライアント端末装置３から受信端末装置２に対して送信されるデータの例を示す概略図である。図示するように、このデータは、図７で示したデータと同様のデータ項目で構成される。ただし、図１６に示すデータでは、ＡＩＴのＵＲＬ（"aiturl"）が格納されておらず、ヌル文字列となっている。なお、ＵＲＬ（"aiturl"）として、ヌル文字列の代わりに、特定の文字列等が指定された場合に、放送信号から取得されるＡＩＴの所在情報を用いるようにしてもよい。

図１６に示すデータをクライアント端末装置３から受信した場合、受信端末装置２は、このデータが示す放送リソースの情報（"resource"）によって特定される放送サービスを選局する。その放送サービスを受信しているときに、受信端末装置２は、放送信号からＡＩＴのＵＲＬの情報を抽出することができる。一方、図１６に示すデータにおいて指定されているＡＩＴのＵＲＬは、ヌル文字列である。このため、受信端末装置２は、放送信号から得られたＡＩＴのＵＲＬに基づいて、ハイブリッドキャストアプリを起動する。

なお、手法６で説明した事項以外については、システム１は、上述の手法５に準じて動作する。

［手法７ 放送信号に基づくハイブリッドキャストコンテンツの活用（その３ ハイブリッドキャストの端末連携機能のＡＰＩの拡張）］
本手法は、手法６の変形例である。つまり、本手法では、クライアント端末装置３から受信端末装置２に対してハイブリッドキャストアプリの起動を要求する際に、クエリーパラメーターとして「mode=web」を明示的に指定できるようにしている。

図１７は、本手法においてクライアント端末装置３が受信端末装置２に対してハイブリッドキャストアプリの起動を要求するためのＡＰＩを示す概略図である。図示するように、このＡＰＩにおいては、拡張クエリーとして「mode=web」を指定するようになっている。このようなリクエストを受ける受信端末装置２は、このクエリーパラメーター「mode=web」を取得することにより、クライアント端末装置３からの要求がウェブでのハイブリッドキャストコンテンツの利用を求めるものであることを明示的に把握する。

なお、手法７におけるその他の点は、手法６と同様である。つまり、クライアント端末装置３は、受信端末装置２に対するリクエストにおいて、ＡＩＴの所在情報を明示しない。受信端末装置２は、放送信号に含まれるＡＩＴの所在情報に基づいて、ハイブリッドキャストアプリを起動する。

［手法８ 放送信号に基づくハイブリッドキャストコンテンツの活用（その４ ハイブリッドキャストの端末連携機能の新規ＡＰＩ）］
本手法は、手法６の変形例である。本手法では、クライアント端末装置３から受信端末装置２に対してハイブリッドキャストアプリの起動を要求するための、新規ＡＰＩを用いる。この新規ＡＰＩは、ハイブリッドキャストの端末連携機能によって連携している受信端末装置２とクライアント端末装置３との間で使用され得るインターフェースである。

図１８は、本手法においてクライアント端末装置３が受信端末装置２に対してハイブリッドキャストアプリの起動を要求するためのＡＰＩを示す概略図である。図示するように本手法では、「webhybridcast」という新規のＡＰＩを、クライアント端末装置３側から利用可能としている。このＡＰＩのＵＲＬは「＜BaseURL＞/webhybridcast」である。また、このＡＰＩを呼ぶためのメソッドはＰＯＳＴである。

なお、手法８におけるその他の点は、手法６や７と同様である。つまり、クライアント端末装置３は、受信端末装置２に対するリクエストにおいて、ＡＩＴの所在情報を明示しない。受信端末装置２は、放送信号に含まれるＡＩＴの所在情報に基づいて、ハイブリッドキャストアプリを起動する。

［手法９ 放送信号に基づくハイブリッドキャストコンテンツの活用（その５ 起動可否判定サーバー装置に対する問い合わせ）］
本手法は、手法５から８までのいずれかの変形例である。つまり、本手法では、手法５から８までのいずれかの処理に加えて、受信端末装置２がＡＩＴ起動可否判定サーバー装置１１に対する問い合わせを行えるようにする。ＡＩＴ起動可否判定サーバー装置１１は、指定されたハイブリッドキャストアプリケーションプログラムがいかなる形態で稼働可能であるかを表す情報を、受信端末装置２に与える。

ＡＩＴ起動可否判定サーバー装置１１の機能は、前述の手法４と同様である。また、受信端末装置２からＡＩＴ起動可否判定サーバー装置１１へのリクエスト（問い合わせ）およびそのレスポンスの手順等も、手法４において説明した通りである。即ち、受信端末装置２は、通常のハイブリッドキャストアプリとウェブ用のハイブリッドキャストアプリのいずれか、または両方について、起動可否をＡＩＴ起動可否判定サーバー装置１１に問い合わせる。起動可否をＡＩＴ起動可否判定サーバー装置１１は、その応答として、起動可否の情報を受信端末装置２に送信する。受信端末装置２は、起動可否をＡＩＴ起動可否判定サーバー装置１１から受け取った可否情報に基づいて、ハイブリッドキャストアプリを起動するか否かを決定する。

［手法１０ 起動可否状態取得ＡＰＩの拡張（ウェブリソースとして提供するハイブリッドキャストアプリの起動可否状態）］
本手法では、起動可否状態取得ＡＰＩ（図４のステップＳ１１１およびＳ１１２）を拡張することにより、クライアント端末装置３が、ウェブリソースとして提供するハイブリッドキャストアプリの起動可否状態を、受信端末装置２から受け取ることができるようにしている。

本手法において、クライアント端末装置３は、起動可否状態取得ＡＰＩを呼び出すことにより、受信端末装置２に対するリクエストを行う。リクエストするためのＵＲＬは「＜BaseURL＞/hybridcast」である。また、メソッドはＧＥＴである。これにより、受信端末装置２は、起動可否状態取得のリクエストを受信する。本手法の特徴は、受信端末装置２が、クライアント端末装置３に対して、ウェブ用のハイブリッドキャストアプリの起動可否状態（下記の"webhybridcast"）を返す点である。

図１９は、本手法で拡張された起動可否状態取得ＡＰＩにおいて、受信端末装置２からクライアント端末装置３に対して送信されるレスポンスのデータの例を示す概略図である。図示するように、このレスポンスのデータは、ヘッダー（"head"）のブロック（第２行目から第５行目まで）とボディー（"body"）のブロック（第６行目から第２２行目まで）とを持つ。ボディー（"body"）のデータは、タスクＩＤ（"taskid"）と、通常のハイブリッドキャストアプリの起動可否状態（"hybridcast"）と、ウェブ用のハイブリッドキャストアプリの起動可否状態（"webhybridcast"）と、を含む。通常のハイブリッドキャストアプリの起動可否状態およびウェブ用のハイブリッドキャストアプリの起動可否状態は、それぞれ、受信端末装置２がクライアント端末装置３に返す起動可否状態のデータである。通常のハイブリッドキャストアプリの起動可否状態およびウェブ用のハイブリッドキャストアプリの起動可否状態のそれぞれは、状態（"status"）と、コード（"code"）と、メッセージ（"message"）とを含む。

本例では、通常のハイブリッドキャストアプリの起動可否状態における状態は「NoProcess」であり、コードは「５００」である。これは、通常のハイブリッドキャストアプリが起動不可であることを表している。また、ウェブ用のハイブリッドキャストアプリの起動可否状態における状態は「Done」であり、コードは「２００」である。これは、ウェブ用のハイブリッドキャストアプリが起動可能であることを表している。

以上の説明の通り、本手法では、起動可否状態取得ＡＰＩを拡張したことにより、クライアント端末装置３は、ウェブ用のハイブリッドキャストアプリの起動可否状態を取得できる。

［手法１１ ウェブリソースとして提供するハイブリッドキャストアプリの起動可否状態を取得するための新規ＡＰＩ］
上の手法１０では、既存のＡＰＩを拡張することにより、クライアント端末装置３が、受信端末装置２から、ウェブリソースとして提供するハイブリッドキャストアプリの起動可否状態を受信するようにした。これに対して、本手法では、ウェブリソースとして提供するハイブリッドキャストアプリの起動可否状態を取得するための、ハイブリッドキャストの端末連携機能の新たなＡＰＩを設けている。

図２０は、本手法において利用可能としているハイブリッドキャストの端末連携機能のＡＰＩを示す概略図である。このＡＰＩは、クライアント端末装置３が、受信端末装置２からウェブリソース向けのハイブリッドキャストアプリの起動可否状態を取得するためのものである。クライアント端末装置３は、図４のステップＳ１１１およびＳ１１２で示した起動可否状態取得の手順に代えて、図２０のＡＰＩによって起動可否状態を取得することができる。図示するように、このＡＰＩのＵＲＬは「＜BaseURL＞/webhybridcast」である。また、メソッドはＧＥＴである。

図２１は、図２０で示したクライアント端末装置３からのリクエストに対応して、受信端末装置２が返すレスポンスデータの例を示す概略図である。図示するように、このレスポンスのデータは、ヘッダー（"head"）のブロック（第２行目から第５行目まで）とボディー（"body"）のブロック（第６行目から第１５行目まで）とを持つ。ボディー（"body"）のデータは、タスクＩＤ（"taskid"）と、ウェブ用のハイブリッドキャストアプリの起動可否状態（"webhybridcast"）とを含む。ウェブ用のハイブリッドキャストアプリの起動可否状態は、状態（"status"）と、コード（"code"）と、メッセージ（"message"）とを含む。図示する例では、状態は「Done」、コードは「２００」、メッセージは「OK」である。このデータは、ウェブ用のハイブリッドキャストアプリが起動可能であることを表している。ウェブ用のハイブリッドキャストアプリが起動不可である場合には、例えば、状態が「NoProcess」、コードが「５００」などといった値をとる。

以上説明したように、本手法では、ウェブ用のハイブリッドキャストアプリの起動可否状態を問い合わせるための専用のＡＰＩを用いるようにしている。これにより、受信端末装置２がクライアント端末装置３に返すレスポンスのデータを、シンプルな構造にすることができる。

［手法１２ 受信機状態取得ＡＰＩの拡張（ウェブリソースとして提供するハイブリッドキャストアプリの状態）］
本手法では、ハイブリッドキャストの端末連携機能の受信機状態取得のＡＰＩ（図４のステップＳ１１３およびＳ１１４）を拡張することにより、クライアント端末装置３が、ウェブリソースとして提供するハイブリッドキャストアプリの起動状態を取得できるようにする。

図２２は、本手法で拡張したＡＰＩ（受信機状態取得）において、受信端末装置２がクライアント端末装置３に送信するレスポンスのデータの例を示す概略図である。図示するように、このレスポンスのデータは、ヘッダー（"head"）のブロック（第２行目から第５行目まで）とボディー（"body"）のブロック（第６行目から第１７行目まで）とを持つ。ボディーのデータは、通常のハイブリッドキャストアプリに関する受信機状態のデータ（"hybridcast"のラベルが付いている）と、ウェブ用のハイブリッドキャストアプリに関する受信機状態のデータ（"webhybridcast"のラベルが付いている）とを含む。このデータの例では、通常のハイブリッドキャストアプリに関する受信機状態は「NotStarted」であり、即ちアプリが起動されていない（何もない）ことを表す。また、ウェブ用のハイブリッドキャストアプリに関する受信機状態は「Running」であり、即ちアプリが起動され稼働中であることを表す。ボディー（"body"）内の状態（"status"）のブロック（第７行目から第１６行目まで）は、アプリの起動状態を表す上記の２つのデータの他に、連携アプリ（"companion_apps"）およびリソース（"resource"）のデータを持つ。リソースのデータは、受信端末装置２が選局した放送サービスを特定する情報である。

［手法１３ ウェブリソースとして提供するハイブリッドキャストアプリの起動状態を取得するための新規ＡＰＩ］
上の手法１１では、既存のＡＰＩを拡張することによって、受信端末装置２からクライアント端末装置３に、ウェブ用のハイブリッドキャストアプリの状態を渡した。本手法では、ハイブリッドキャストの端末連携機能の新規のＡＰＩを用いる。即ち、本手法では、既存のＡＰＩを拡張する代わりに、クライアント端末装置３がウェブ用のハイブリッドキャストアプリの状態を取得するための新規のＡＰＩを用いるようにする。

図２３は、本手法で用いる、クライアント端末装置３と受信端末装置２との間のＡＰＩ
新規ＡＰＩを示す概略図である。クライアント端末装置３は、ウェブリソースとして提供されるハイブリッドキャストアプリの起動状態を受信端末装置２に問い合わせるために、このＡＰＩを呼び出すことができる。図示するように、このＡＰＩのＵＲＬは「＜BaseURL＞/webstatus」である。また、このＡＰＩを呼び出すためのメソッドはＧＥＴである。クライアント端末装置３は、図４のステップＳ１１３およびＳ１１４で示した手順に代えて、本手法のＡＰＩを呼び出すことができる。

図２４は、上の図２３で示したＡＰＩにおける、受信端末装置２からクライアント端末装置３に対して送信されるレスポンスのデータの例を示す概略図である。図示するように、このレスポンスのデータは、ヘッダー（"head"）のブロック（第２行目から第５行目まで）とボディー（"body"）のブロック（第６行目から第１６行目まで）とを持つ。ボディーのデータは、状態（"status"）というデータを持つ。状態のデータの要素の一つは、ウェブ用のハイブリッドキャストアプリの起動状態（"status"）のデータである。本図で示す例では、ウェブ用のハイブリッドキャストアプリの起動状態の値は「Running」であり、この値はウェブ用のハイブリッドキャストアプリが起動され、稼働中であることを表す。ウェブ用のハイブリッドキャストアプリが起動されていない（何もない）場合には、ウェブ用のハイブリッドキャストアプリの起動状態の値は、例えば、「NotStarted」などとされる。

図２４で示す状態（"status"）のデータは、他にも、連携アプリ（"companion_apps"）およびリソース（"resource"）のデータを持つ。リソースのデータは、受信端末装置２が選局した放送サービスを特定する情報である。

以上説明したように、本手法では、ハイブリッドキャストの端末連携機能の新規のＡＰＩを利用可能とした。このＡＰＩは、クライアント端末装置３が、受信端末装置２から、ウェブリソースのハイブリッドキャストアプリの起動状態の情報を取得するために用いることができる。

以上のように、手法１から１３までのいずれかを用いて、受信端末装置２やクライアント端末装置３が処理を行う。なお、受信端末装置２やクライアント端末装置３が、手法１から１３までのうちの複数の手法を組み合わせて処理を行ってもよい。

図２５は、本実施形態におけるシステム１を構成する各装置（受信端末装置２、クライアント端末装置３、およびその他の必要なサーバー装置等）の内部構成の例を示すブロック図である。各装置は、コンピューターを用いて実現され得る。図示するように、そのコンピューターは、中央処理装置９０１と、ＲＡＭ９０２と、入出力ポート９０３と、入出力デバイス９０４や９０５等と、バス９０６と、を含んで構成される。コンピューター自体は、既存技術を用いて実現可能である。中央処理装置９０１は、ＲＡＭ９０２等から読み込んだプログラムに含まれる命令を実行する。中央処理装置９０１は、各命令にしたがって、ＲＡＭ９０２にデータを書き込んだり、ＲＡＭ９０２からデータを読み出したり、算術演算や論理演算を行ったりする。ＲＡＭ９０２は、データやプログラムを記憶する。ＲＡＭ９０２に含まれる各要素は、アドレスを持ち、アドレスを用いてアクセスされ得るものである。なお、ＲＡＭは、「ランダムアクセスメモリー」の略である。入出力ポート９０３は、中央処理装置９０１が外部の入出力デバイス等とデータのやり取りを行うためのポートである。入出力デバイス９０４や９０５は、入出力デバイスである。入出力デバイス９０４や９０５は、入出力ポート９０３を介して中央処理装置９０１との間でデータをやりとりする。バス９０６は、コンピューター内部で使用される共通の通信路である。例えば、中央処理装置９０１は、バス９０６を介してＲＡＭ９０２のデータを読んだり書いたりする。また、例えば、中央処理装置９０１は、バス９０６を介して入出力ポートにアクセスする。

なお、各装置の少なくとも一部の機能をコンピューターで実現する場合、この機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行する。なお、ここでいう「コンピューターシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ＵＳＢメモリー等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。つまり、「コンピューター読み取り可能な記録媒体」とは、非一過性の（non-transitory）コンピューター読み取り可能な記録媒体であってよい。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、一時的に、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリーのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

［変形例Ａ］
上で説明した実施形態では、受信端末装置２がトランスコード部２６１を備えていた。トランスコード部２６１は、放送信号から抽出される映像や音声を、ウェブプラットフォームで利用可能な形式のウェブリソースに変換する。ただし、変形例として、受信端末装置２がトランスコード部２６１を持たなくてもよい。そのような構成であっても、クライアント端末装置３は、受信端末装置２に対して、アプリ（ハイブリッドキャストアプリ）の起動を要求できる。また、受信端末装置２は、上記起動要求に基づいてアプリ（コンテンツデータ）を出力し、そのアプリをクライアント端末装置３側で利用することが可能である。また、放送以外の、通信によって配信される映像や音声と、アプリからの出力とを組み合わせて、クライアント端末装置３側で利用することもできる。

［変形例Ｂ］
変形例Ｂでは、アプリは、クライアント端末装置３上で稼働させるために、ハイブリッドキャストコンテンツ変換部２９１による変換を必要としない。言い換えれば、このアプリは、受信端末装置２でしか利用できない機能を用いていない。

変形例Ｂにおいても、受信端末装置２のウェブリソース提供部２６２が、受信端末装置２によって受信された放送信号に基づいて特定されるアプリを、クライアント端末装置３が取得できるようにする。一例として、ウェブリソース提供部２６２は、受信された放送信号に基づいて取得したアプリケーション情報テーブル（ＡＩＴ）を、通信を介して、連携先のクライアント端末装置３に対して送信するようにする。あるいは、ウェブリソース提供部２６２は、受信された放送信号に基づいて特定されるアプリケーション情報テーブルの所在情報（ＵＲＬ等）を、通信を介して、連携先のクライアント端末装置３に対して送信するようにしてもよい。これらの場合のいずれも、クライアント端末装置３は、通信を介して、そのアプリケーション情報テーブルを取得することができる。そして、クライアント端末装置３は、取得したアプリケーション情報テーブルから、アプリのコード自体の所在情報を把握し、アプリを取得することができる。

以上説明したように、本実施形態（変形例を含む）では、クライアント端末装置３は、受信端末装置２と連携する。また、クライアント端末装置３は、受信端末装置２に対して、アプリの起動を要求する。また、受信端末装置２は、アプリを、ウェブプラットフォームで利用可能な形式のアプリに変換して、クライアント端末装置３に送信する。つまり、クライアント端末装置３は、ウェブプラットフォームで利用可能なアプリを利用することができる。

以上、この発明の実施形態（変形例を含む）について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

本発明は、例えば、映像等のコンテンツを提供する産業、およびそのための機器類を製造あるいは販売等する産業等に利用することができる。但し、本発明の利用範囲はここに例示したものには限られない。

１ システム
２ 受信端末装置（受信装置）
３ クライアント端末装置
４ アンテナ
８ ルーター
９ 通信ネットワーク
１１ ＡＩＴ起動可否判定サーバー装置
２０１ チューナー部（受信部）
２０２ デスクランブラー
２０３ デマルチプレクサー
２１１ データ放送処理部
２１２ 映像デコーダー部
２１３ 音声デコーダー部
２１４ 字幕デコーダー部
２２１ データ放送エンジン
２３１ 通信部
２３２ ストリーミング受信部
２３３ デマルチプレクサー
２４２ 映像デコーダー部
２４３ 音声デコーダー部
２４４ 字幕デコーダー部
２５１ アプリケーション制御部
２５２ アプリケーションエンジン
２５３ アプリケーションロンチャー
２６１ トランスコード部
２６２ ウェブリソース提供部
２６３ クライアント端末連携制御部
２７１ 映像出力部
２７２ 音声出力部
２８１ データ解析部
２８２ イベント処理部
２９１ ハイブリッドキャストコンテンツ変換部
３３１ 通信部
３５２ アプリケーションエンジン
３５３ アプリケーションロンチャー
３６３ 受信端末連携制御部
９０１ 中央処理装置
９０２ ＲＡＭ
９０３ 入出力ポート
９０４，９０５ 入出力デバイス
９０６ バス

Claims (18)

1. 放送信号を受信する受信部と、
   受信された前記放送信号に基づいて取得したアプリケーション情報テーブル、または受信した前記放送信号に基づくアプリケーション情報テーブルの所在情報、の少なくともいずれかを、通信を介して、連携先のクライアント端末装置に対して送信するウェブリソース提供部と、
   を備える受信装置。
2. 前記アプリケーション情報テーブルが特定するアプリを、ウェブプラットフォームで利用可能なアプリに変換するコンテンツ変換部、
   をさらに備える請求項１に記載の受信装置。
3. 前記アプリケーション情報テーブルが特定するアプリの稼働を制御するアプリケーション制御部、
   をさらに備える請求項１または２に記載の受信装置。
4. 前記ウェブリソース提供部は、連携先のクライアント端末装置から送信されるアプリ起動要求に基づいて前記アプリを起動するよう前記アプリケーション制御部に指示し、前記コンテンツ変換部が変換した結果である前記ウェブプラットフォームで利用可能なアプリを前記クライアント端末装置に対して通信を介して送信する、
   請求項３に記載の受信装置。
5. 受信された前記放送信号から抽出された映像リソースまたは音声リソースの少なくともいずれかのデータを、ウェブプラットフォームで利用可能な形式のデータにトランスコードして、ウェブリソースとして出力するトランスコード部、
   をさらに備え、
   前記ウェブリソース提供部は、前記トランスコード部が出力する前記ウェブリソースを前記クライアント端末装置に対して通信を介して送信する、
   請求項４に記載の受信装置。
6. 前記ウェブリソース提供部は、前記クライアント端末装置からの前記アプリ起動要求に含まれる情報によって特定される前記アプリを起動するように前記アプリケーション制御部に指示する、
   請求項４または５に記載の受信装置。
7. 前記ウェブリソース提供部は、前記受信部が受信した前記放送信号に含まれる情報によって特定される前記アプリを起動するように前記アプリケーション制御部に指示する、
   請求項４から６までのいずれか一項に記載の受信装置。
8. 前記アプリケーション制御部は、前記クライアント端末装置から送信されるアプリ起動要求に基づいて前記アプリを起動するよう前記ウェブリソース提供部から指示を受けたときに、外部の起動可否判定サーバー装置に問い合わせを行い、起動可否判定サーバー装置からの応答に基づいて、前記ウェブプラットフォームで利用可能なアプリを前記クライアント端末装置に対して送信するか否かを決定する、
   請求項４から７までのいずれか一項に記載の受信装置。
9. 前記ウェブリソース提供部は、前記クライアント端末装置からの起動可否状態取得のリクエストに応じて、前記ウェブプラットフォームで利用可能なアプリの起動可否状態のデータを、前記クライアント端末装置に対して送信する、
   請求項４から８までのいずれか一項に記載の受信装置。
10. 前記ウェブリソース提供部は、前記クライアント端末装置からの受信機状態取得のリクエストに応じて、前記ウェブプラットフォームで利用可能なアプリについての受信機状態のデータを、前記クライアント端末装置に対して送信する、
    請求項４から９までのいずれか一項に記載の受信装置。
11. 請求項２に記載の受信装置の前記コンテンツ変換部が出力するアプリのアプリ起動要求を前記受信装置に対して送信し、前記コンテンツ変換部が変換した結果であるウェブプラットフォームで利用可能なアプリを前記受信装置から受信する受信端末連携制御部、
    を備えるクライアント端末装置。
12. 請求項５に記載の受信装置の前記トランスコード部が出力した前記ウェブリソースを受信して利用するウェブアプリケーションを稼働させるアプリケーションエンジン、
    をさらに備え、
    前記受信端末連携制御部は、ハイブリッドキャストの端末連携機能により、前記ウェブリソースを利用するために必要な処理を、前記受信装置との連携動作として実行する、
    請求項１１に記載のクライアント端末装置。
13. 前記受信端末連携制御部は、前記アプリ起動要求とともに、起動すべきアプリを特定する情報を前記受信装置に対して送信する、
    請求項１１または１２に記載のクライアント端末装置。
14. 前記受信端末連携制御部は、前記アプリ起動要求を送信する際に、起動すべきアプリを特定する情報を前記受信装置に対して送信せず、前記受信装置が受信する放送信号に含まれる情報によって起動すべきアプリを特定するよう前記受信装置に要求する、
    請求項１１または１２に記載のクライアント端末装置。
15. 前記受信端末連携制御部は、起動可否状態取得のリクエストを前記受信装置に対して送信し、前記受信装置からアプリの起動可否状態のデータを受信する、
    請求項１１から１４までのいずれか一項に記載のクライアント端末装置。
16. 前記受信端末連携制御部は、受信機状態取得のリクエストを前記受信装置に対して送信し、前記受信装置からアプリの受信機状態のデータを受信する、
    請求項１１から１５までのいずれか一項に記載のクライアント端末装置。
17. 放送信号を受信する受信部、を備えるコンピューターを、
    請求項１から１０までのいずれか一項に記載の受信装置、
    として機能させるためのプログラム。
18. コンピューターを、
    請求項１１から１６までのいずれか一項に記載のクライアント端末装置、
    として機能させるためのプログラム。

Images