JP2022183550A - 受信装置、クライアント端末装置、およびプログラム - 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＞

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

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

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

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

この状況において本発明が解決すべき課題は、次の通りである。放送信号は、映像や音声のほかに、イベントの情報や、字幕の情報や、番組情報などの様々な情報を含む。また、映像や音声を解析することにより、メタデータの情報を得ることもできる。放送のコンテンツを視聴端末で利用可能とする場合に、映像や音声だけでなく、放送信号に含まれるイベントの情報、あるいはその他の情報も、ウェブリソースとして視聴端末で利用可能にすることが望まれる。なお、放送信号におけるイベントの情報は、例えばＥＭ（event message、イベントメッセージ）の形で伝送されるものである。

つまり、放送波に含まれる、映像や音声以外の情報（典型的には、イベント）や、映像や音声を解析することによって得られるメタデータの情報を、ウェブの標準的なインターフェースで活用できるようにすることが望まれる。これらの、映像や音声以外の情報や、映像や音声を解析することによって得られるメタデータの情報を、まとめて「付随情報」と呼ぶことにする。つまり、テレビ受信装置（受信端末装置）が受信した放送に関する付随情報を、標準的なウェブインターフェースに則った形式で視聴端末（クライアント端末装置）が活用できるようにすることが望まれる。

本発明は、上記の課題認識に基づいて行なわれたものであり、受信装置（テレビ受信機）からクライアント端末装置（視聴端末）に対して放送リソースに基づくウェブリソースを提供するシステムにおいて、付随情報（イベント情報等）をクライアント端末装置側で利用することを可能にする受信装置、クライアント端末装置、およびプログラムを提供しようとするものである。

［１］上記の課題を解決するため、本発明の一態様による受信装置は、放送信号を受信する受信部と、前記放送信号から抽出されたリソースに基づくイベント情報を生成するイベント処理部と、前記イベント処理部が生成した前記イベント情報を、通信を介して、連携先のクライアント端末装置に対して送信するウェブリソース提供部と、を備える。

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

［３］また、本発明の一態様は、上記の受信装置において、前記付随情報は、前記放送信号から抽出されたイベントメッセージと、字幕と、文字スーパーと、アプリケーション情報テーブル（ＡＩＴ）と、サービス情報（ＳＩ）と、データ放送コンテンツと、のいずれか、または、前記放送信号から抽出された前記映像リソースまたは前記音声リソースの少なくともいずれかを解析して得られたメタデータ、を含む、ものである。

［４］また、本発明の一態様は、上記の受信装置において、前記ウェブリソース提供部は、ハイブリッドキャストコネクト（ハイブリッドキャストの端末連携機能）における前記連携先のクライアント端末装置との間での端末連携通信の機能を用いて、前記イベント情報を、前記連携先のクライアント端末装置に対して送信する、ものである。

［５］また、本発明の一態様は、上記の受信装置において、前記付随情報は、前記放送信号から抽出されたイベントメッセージのデータを含み、前記ウェブリソース提供部は、同一内容の前記イベントメッセージのデータを含む前記イベント情報を複数回重複して前記クライアント端末装置に対して送信することを抑止する制御を行う、ものである。

［６］また、本発明の一態様は、上記の受信装置において、前記ウェブリソース提供部は、前記クライアント端末装置における前記ウェブリソースの再生位置の情報を前記クライアント端末装置から受け取り、受け取った前記再生位置の情報に基づくタイミングで、前記ウェブリソースにおける特定の再生位置に関連付けられた前記イベント情報を、前記クライアント端末装置に対して送信する、ものである。

［７］また、本発明の一態様は、上記の受信装置において、前記ウェブリソース提供部は、複数の前記クライアント端末装置をそれぞれ識別するとともに、それぞれの前記クライアント端末装置から受け取った前記再生位置の情報に基づくタイミングで、前記ウェブリソースにおける特定の再生位置に関連付けられた前記イベント情報を、複数の前記クライアント端末装置のそれぞれに対して送信する、ものである。

［８］また、本発明の一態様は、上記の受信装置において、前記イベント処理部は、前記イベント情報をメディアタイムドイベント（ＭＴＥ）として生成して、生成した前記メディアタイムドイベントを前記トランスコード部が出力した前記ウェブリソースに挿入し、前記ウェブリソース提供部は、前記メディアタイムドイベントが挿入された前記ウェブリソースを、前記クライアント端末装置に対して送信する、ものである。

［９］また、本発明の一態様は、上記の受信装置において、前記イベント処理部が生成する前記メディアタイムドイベントは、前記放送信号から抽出された字幕と、文字スーパーと、アプリケーション情報テーブル（ＡＩＴ）と、サービス情報（ＳＩ）と、データ放送コンテンツと、のいずれか、を前記付随情報として含むものである。

［１０］また、本発明の一態様は、上記の受信装置において、抽出された前記音声リソースを解析した結果である音声解析結果と、抽出された前記字幕と、をマッチングすることによって得られる再生位置に前記字幕を関連付けるデータ解析部、をさらに備え、前記イベント処理部は、前記再生位置に関連付けられた前記字幕を含む前記メディアタイムドイベントを、前記ウェブリソースに挿入する、ものである。

［１１］また、本発明の一態様は、上記の受信装置において、抽出された前記映像リソースを解析した結果である映像解析結果と、前記放送信号から抽出された番組情報または外部のウェブサーバー装置から情報と、を関連付けることによって得られたメタデータを生成するデータ解析部、をさらに備え、前記イベント処理部は、前記データ解析部が生成した前記メタデータを含む前記メディアタイムドイベントを、前記ウェブリソースに挿入する、ものである。

［１２］また、本発明の一態様によるクライアント端末装置は、上の［１］に記載の受信装置から前記イベント情報を受信する受信端末連携制御部、を備えるものである。

［１３］また、本発明の一態様によるクライアント端末装置は、上の［２］に記載の受信装置から前記ウェブリソースを受信して利用するウェブアプリケーションを稼働させるアプリケーションエンジンと、ハイブリッドキャストコネクト（ハイブリッドキャストの端末連携機能）により、前記ウェブリソースを利用するために必要な処理を、前記受信装置との連携動作として実行する受信端末連携制御部と、を備え、前記受信装置が受信した放送信号から抽出されたリソースに基づく、映像あるいは音声の少なくともいずれかに付随する付随情報を含むイベント情報を、前記受信装置から受信する、ものである。

［１４］また、本発明の一態様は、上記のクライアント端末装置において、前記受信端末連携制御部が、前記受信装置との間での端末連携通信によって、前記イベント情報を受信する、というものである。

［１５］また、本発明の一態様は、上記のクライアント端末装置において、受信した前記イベント情報が持つ識別情報に基づいて、前記イベント情報が処理済みであるか否かを判定し、既に処理済みである前記イベント情報についての処理を抑止する制御を行う、ものである。

［１６］また、本発明の一態様は、上記のクライアント端末装置において、前記ウェブアプリケーションが受信する前記ウェブリソースに含まれるメディアタイムドイベント（ＭＴＥ）として、前記イベント情報を受信する、ものである。

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

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

本発明によれば、受信装置が受信した放送リソースに含まれる映像リソースまたは音声リソースに付随する付随情報を、イベント情報としてクライアント端末装置に配信することが可能となる。

本発明の実施形態によるシステムの構成を示すブロック図である。 同実施形態による受信端末装置の機能構成を示す機能ブロック図である。 同実施形態によるクライアント端末装置の機能構成を示す機能ブロック図である。 同実施形態において拡張されたハイブリッドキャストの端末連携機能を用いた、受信端末装置とクライアント端末装置との間での、リクエストおよびレスポンスのシーケンスの例を示す概略図（その１）である。 上記図４と同様の、受信端末装置とクライアント端末装置との間での、リクエストおよびレスポンスのシーケンスの例を示す概略図（その２）である。 同実施形態により、ハイブリッドキャストの端末連携機能のsendtextの機能を用いて受信端末装置からクライアント端末装置に対して送信されるイベントメッセージのデータの例を示す概略図である。 同実施形態によるイベント処理部がネット配信用の動画コンテンツに挿入するＭＴＥの例を示す概略図である。 同実施形態において、字幕データをイベントとして挿入したＭＴＥ（メディアタイムドイベント）の例を示す概略図である。 同実施形態において、種別（用途等）に応じて使い分けられるＭＴＥの識別子の一覧の例である。 同実施形態によるシステムを構成する各装置の内部構成の例を示すブロック図である。

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

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

本実施形態において、放送信号から抽出された映像のリソースと音声のリソースとは、標準的なウェブのプラットフォームで用いられるネット配信動画のコンテンツとして、受信端末装置２からクライアント端末装置３に配信される。また、映像や音声以外のデータ（付随情報。イベントの情報を含む。また、映像や音声を解析して得られるメタ情報を含む。）については、２通りの方法のうちの少なくともいずれかの方法で、受信端末装置２からクライアント端末装置３に配信することが可能である。

その第１の方法は、ハイブリッドキャストの端末連携機能における双方向の端末連携通信を用いる方法である。この方法については、図４のステップＳ１１５においても説明する。この方法を用いる場合には、ハイブリッドキャストの端末連携機能の技術で連携している受信端末装置２とクライアント端末装置３との間で、任意の側から他方へ、「sendtext」の機能を用いて、テキストデータを送信することができる。なお、テキストデータ以外のデータを、適切にコーディングすることにより、テキストデータとして送信することができるのは、言うまでもない。

また第２の方法は、メディアタイムドイベント（Media Timed Event、ＭＴＥ）を用いる方法である。メディアタイムドイベントは、映像等のメディアのデータに時刻に関連付けられたイベントの情報を挿入するための、標準化された方法である。このＭＴＥを用いる場合には、受信端末装置２側からクライアント端末装置３側に向けて、情報を送信することができる。つまり、ＭＴＥは、ネット配信動画として配信される動画コンテンツに挿入される。ＭＴＥは、ネット配信動画内の所定の位置（再生位置。動画の先頭からの相対時刻。）に関連付けられるため、動画と同期をとるためのデータを格納するのに向いている。

なお、ＭＴＥについては、文献「Requirements for Media Timed Events, W3C Interest Group Note, 25 June 2020」（https://www.w3.org/TR/media-timed-events/）にも記載されている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本実施形態のウェブリソース提供部２６２は、受信端末装置２が受信する放送信号に含まれるイベントメッセージ（ＥＭ）の情報を受け取り、管理する。ウェブリソース提供部２６２は、クライアント端末連携制御部２６３と疎通し、上記のイベントメッセージに関連付くイベント情報を、通信を介して、クライアント端末装置３に提供する。なお、イベント情報は、イベント処理部２８２が生成したデータである。ウェブリソース提供部２６２がイベント情報をクライアント端末装置３に配信する具体的な方法は、次の通りである。第１に、ウェブリソース提供部２６２は、ハイブリッドキャストの端末連携機能における、連携先のクライアント端末装置３との間での端末連携通信の機能を用いて、イベント情報を、連携先のクライアント端末装置３に対して送信してよい。第２に、ウェブリソース提供部２６２は、後述のイベント処理部２８２から提供されるメディアタイムドイベント（ＭＴＥ）を、クライアント端末装置３に向けて伝送する。なお、イベント処理部２８２は、ＭＴＥを、クライアント端末装置３に対して配信される映像や音声のコンテンツ（ウェブリソース）に挿入する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

つまり、受信端末連携制御部３６３は、ハイブリッドキャストの端末連携機能により、ウェブリソースを利用するために必要な処理を、受信端末装置２との連携動作として実行する。具体的には、受信端末連携制御部３６３は、少なくとも、ウェブリソースを利用するためのロケーション（エンドポイント等）の情報を受信端末装置２から受信する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次に、付随情報（イベントの情報等）を受信端末装置２からクライアント端末装置３に配信する処理の、様々なバリエーション（変形例）について、それぞれ説明する。以下で説明するバリエーションは、（１）から（１９）までの１９種類の手法である。

（１）イベント情報（ＥＭ）のクライアント端末装置３への伝送（その１）
次に、受信端末装置２からクライアント端末装置３へのイベント情報の詳細について説明する。受信端末装置２からクライアント端末装置３へは、ハイブリッドキャストの端末連携機能の「sendtext」（テキストの送信）の機能を用いて、イベントの情報を伝送する。このsendtextの処理は、図４におけるステップＳ１１５の端末連携通信（双方向通信）において行われるものである。

その手順としては、次の通りである。即ち、クライアント端末装置３は、予め受信端末装置２におけるサーバー機能（クライアント端末連携制御部２６３）との間で、ハイブリッドキャストの端末連携機能によるペアリングを完了している。つまり、図４で説明した機器発見や認証などの手順は、既に完了している。これにより、ハイブリッドキャストの端末連携機能が有するＡＰＩ群に含まれるwebsocketによる、受信端末装置２とクライアント端末装置３との間の疎通が可能となっている。

その前提で、受信端末装置２のチューナー部２０１が受信した放送信号にはイベントメッセージが含まれる。デマルチプレクサー２０３が分離・抽出したイベントメッセージは、イベント処理部２８２等を経由して、ウェブリソース提供部２６２に渡され、管理される。ウェブリソース提供部２６２は、クライアント端末連携制御部２６３が持つハイブリッドキャストの端末連携機能を用いて、イベントメッセージを、クライアント端末装置３に配信する。この際には、前述のsendtextの機能が用いられる。

図６は、ハイブリッドキャストの端末連携機能におけるsendtextの機能を用いて受信端末装置２からクライアント端末装置３に対して送信されるイベントメッセージのデータの例を示す概略図である。図示するように、このデータは、例えばＪＳＯＮ形式で記述される。ＪＳＯＮは、「JavaScript Object Notation」の略である。図示するデータは、ブロック構造を有する。このデータの第２行目から第１６行目までは、「message」というラベルが付いたブロックである。このmessageは、次の２つの要素を持つ。

第１の要素は、「devid」というラベルを持ち、メッセージの送信先の端末のＩＤのデータを持つ。この「dev」はdeviceの略である。実際には、このメッセージを送信する時点までに、受信端末装置２とクライアント端末装置３との間のペアリングは完了している。つまり、クライアント端末連携制御部２６３が把握している適切な端末ＩＤが、この「devid」のデータとして設定される。

また、第２の要素は、「sendTextToCompanionDevice」（連携端末へのテキストの送信）というラベルを持つデータである。この「sendTextToCompanionDevice」という要素のさらに下位には、「text」というラベルで示されるブロックが存在する。この「text」は、次の７個の要素を含むものである。第１の要素（第６行目）は、「$type」というラベルを持ち、その値は文字列「event_message」である。つまり、伝送されるデータの種別がイベントメッセージであることを表す。第２の要素（第７行目）は、「$name」というラベルを持ち、その値は文字列「event_message」である。つまり、伝送されるデータの名称がイベントメッセージであることを表す。第３の要素（第８行目）は、「status」というラベルを持ち、その値は数値０である。このデータは、状態を表すものである。第４の要素（第９行目）は、「private_data」というラベルを持ち、その値は、本例では、ヌルストリング（空文字列）である。このデータは、イベントメッセージの内容本体を表すものである。第５の要素（第１０行目）は、「message_id」というラベルを持ち、その値は１４７という数値である。このデータは、伝送される個々のメッセージを識別するためのものである。第６の要素（第１１行目）は、「message_version」というラベルを持ち、その値は１という数値である。このデータは、メッセージのバージョンを表す。第７の要素（第１２行目）は、「message_group_id」というラベルを持ち、その値は３１という数値である。このデータは、メッセージをハンドリングするための、メッセージのグループの識別情報である。例えば上記のprivate_dataが同一であるメッセージが複数回送信される場合に、message_group_idが同一であるか否かで、それら複数回の送信が、同一のメッセージであるか別のメッセージであるかを区別することができる。

なお、予めＩＤ（上記の第１の要素（$type）、第２の要素（$name）、あるいは第５の要素（message_id）など）にメッセージの意味を付与しておくようにしてもよい。一例として、「type=emergency」のときには、クライアント端末装置３側ではメッセージの意味を「praivate_data=emergency」として処理する。これにより、Praivate_dataが空である場合や、何らかの理由でメッセージが欠落した場合にも、イベントの意味を取りこぼさないようにすることができる。

以上説明したように、本手法では、イベントメッセージを、ハイブリッドキャストの端末連携機能におけるsendtextの機能を用いて、受信端末装置２からクライアント端末装置３に配信する。これにより、クライアント端末装置３において、イベントメッセージを利用することが可能となる。

なお、イベントメッセージを受信端末装置２からクライアント端末装置３に伝送する頻度が高いと、イベントメッセージを受信端末装置２やクライアント端末装置３にかかる処理負荷が大きくなりすぎる場合があり得ると考えられる。そこで、次に説明する方法を用いるようにしても良い。

（２）イベント情報（ＥＭ）のクライアント端末装置３への伝送（その２）
本手法の基本的な手順等は、前記の「（１）イベント情報（ＥＭ）のクライアント端末装置３への伝送－その１」に基づく。ただし、受信端末装置２やクライアント端末装置３の処理負荷を軽減するために、本手法では、受信端末装置２は、重複するイベントメッセージの送信を抑制するための複数のオプション機能を持つ。以下では、第１オプションおよび第２オプションを説明する。システム１の動作として、第１オプションまたは第２オプションのどちらか一方のみを行ってもよいし、第１オプションと第２オプションの両方を行ってもよい。

第１オプションとして、受信端末装置２は、ペアリングしているクライアント端末装置３が存在する時のみに、イベントメッセージを配信するための処理を行う。つまりペアリングしている相手（クライアント端末装置３）がない場合には、イベント処理部２８２や、ウェブリソース提供部２６２や、クライアント端末連携制御部２６３や、受信端末装置２内の他の各部は、イベントメッセージを配信するための処理を行わない。これにより、受信端末装置２側の処理負荷を軽減することが可能である。

第２オプションとして、受信端末装置２は、イベントメッセージを管理することにより、同一のイベントメッセージを同一のクライアント端末装置３に複数回送信してしまわないように、抑制する。具体的な制御の手順としては、次の通りである。即ち、ウェブリソース提供部２６２は、クライアント端末装置３ごとに、配信したイベントメッセージに関する情報を管理する。具体的には、ウェブリソース提供部２６２は、特定のイベントメッセージを特定のクライアント端末装置３に配信済みであるか否かを表す真偽値や、その配信回数を表す数値といった情報を、メッセージを識別する情報に関連付けて記憶し、管理する。

そして、ウェブリソース提供部２６２は、放送信号内に含まれていたイベントメッセージがあったときに、上記の管理している情報に基づいて、そのイベントメッセージを個々のクライアント端末装置３に送信すべきであるか否かを判断する。判断の結果、送信すべきであれば、ウェブリソース提供部２６２は、そのメッセージを対象のクライアント端末装置３に送信する。送信すべきでない場合には、ウェブリソース提供部２６２は、そのメッセージを対象のクライアント端末装置３には送信しない。その判断のための手法の例は、次の通りである。即ち、ウェブリソース提供部２６２は、イベントメッセージを識別する情報（前記の、図６に示した、メッセージＩＤ（message_id）やメッセージグループＩＤ（message_group_id））に基づいて、特定のメッセージを送出すべきか否かを判断する。

一例として、送信対象となり得るイベントメッセージのメッセージＩＤ（message_id）のパラメーター値が前回配信済みのものと異なる場合には、ウェブリソース提供部２６２は、そのイベントメッセージを、クライアント端末装置３に送信する。メッセージＩＤ（message_id）のパラメーター値が前回配信済みのものと同一である場合には、ウェブリソース提供部２６２は、そのイベントメッセージを、クライアント端末装置３に送信しないようにする。なお、ウェブリソース提供部２６２は、メッセージＩＤ（message_id）の代わりにメッセージグループＩＤ（message_group_id）を用いて、同様の判定および配信要否の制御を行うようにしてもよい。

つまり、本手法においては、付随情報は、放送信号から抽出されたイベントメッセージのデータを含む。また、ウェブリソース提供部２６２は、同一内容の前記イベントメッセージのデータを含むイベント情報を複数回重複して前記クライアント端末装置に対して送信することを抑止する制御を行う。

なお、所定の条件に合致する場合に、ウェブリソース提供部２６２は、記憶していた上記の管理情報をクリア（初期化）して、再度初期状態からイベントメッセージの送信用日の管理を行うようにしてもよい。

以上説明したように、本手法によれば、受信端末装置２からクライアント端末装置３に対してイベントメッセージを送信する際の、受信端末装置２およびクライアント端末装置３の両方における処理負荷を軽減することが可能となる。

なお、ここまでに記載した手法においては、解決されていない課題が存在する。即ち、上記の各手法では、クライアント端末装置３側での動画再生状況に応じたイベントメッセージの配信を行うことはできない。つまり、例えば、クライアント端末装置３側から受信端末装置２側に対してネット配信動画のデータの再読み込みを要求した場合などに、クライアント端末装置３は、再読み込み後の動画再生の状況に合ったイベントメッセージを受信することができないという問題がある。そこで、次に説明する方法を用いるようにしても良い。

（３）イベント情報（ＥＭ）のクライアント端末装置３への伝送（その３、コンテンツに関連付くイベントの制御）
本手法では、前記の課題を解決するために、クライアント端末装置３側での生成制御の状況に基づいて、受信端末装置２側（サーバーサイド）からのイベントメッセージの配信を行う。つまり、本手法では、イベント配信のタイミングを制御する。なお、一例として、スポーツ中継動画の配信における特定イベントに関連する演出の場合を説明する。つまり、本手法では、次のようなオプション機能を可能とする。

本手法では、受信端末装置２は、クライアント端末装置３側での動画の再生制御の状況に応じて、イベントメッセージの配信を行う。そのために、受信端末装置２は、ネット配信動画のコンテンツごとに、再生位置と発生するイベントメッセージとの関連を管理する。一例として、サッカー中継におけるゴールの瞬間に視聴端末（クライアント端末装置３）側で所定の演出を行う場合を考える。ゴールの瞬間の演出とは、例えば、ＬＥＤライトや効果音等の視覚あるいは聴覚の効果を、クライアント端末装置３側で発生させることである。この場合には、受信端末装置２は、ネット配信動画の再生位置（例えば動画の先頭からの相対時刻（ｈｈ時ｍｍ分ｓｓ秒．ｎｎｎ等、ただし「ｎｎｎ」は秒の小数点以下の部分））と特定のイベントメッセージとを、相互に関連付けて管理する。

なお、ネット配信動画に関連付かないイベント（例えば、緊急地震速報等）については、受信端末装置２は、上記の再生位置との関連付けによる管理を行わない。

手順１： クライアント端末装置３は、再生中のネット配信動画（受信端末装置２から提供されたウェブリソース）の再生開始や再生停止（一時停止や、一時停止からのリジューム等を含む）の情報を、前述のsendtextの機能を用いて、受信端末装置２に送信する。ここで、クライアント端末装置３は、ハイブリッドキャストの端末連携機能（図４のステップＳ１１５で示した端末連携通信（双方向））を用いて、上記の送信を行う。

なお、上記の手順１においてクライアント端末装置３から受信端末装置２に送信される情報（「動画再生制御情報」と呼ぶ）は、例えば次のようなものである。即ち、動画再生制御情報は、再生開始されたタイミングや、再生停止（一時停止を含む）されたタイミングの情報を含んでよい。また、動画再生情報は、再生開始（再開を含む）されたときの、その動画の再生位置（前記の相対時刻）の情報を含む。また、動画再生情報は、クライアント端末装置３において再生位置が変更された場合（巻き戻しや早送り等）の、新たな再生位置の情報をさらに含んでもよい。

手順２： 受信端末装置２側では、クライアント端末連携制御部２６３が、クライアント端末装置３から受信した動画再生制御情報（再生開始や、再生停止や、再生位置等の情報）を、ウェブリソース提供部２６２に伝達する。これにより、ウェブリソース提供部２６２は、クライアント端末装置３において、ネット配信動画を再生中であるか停止中であるかという情報や、再生位置の情報を把握する。

手順３： そして、ウェブリソース提供部２６２は、受け取った動画再生制御情報に応じて、クライアント端末装置３側へのイベントメッセージの配信を制御する。つまり、クライアント端末装置３での動画の配信中（再生位置が進行中）に、前記のイベントに関連付けられた再生位置が到来すると、そのタイミングで、ウェブリソース提供部２６２は、関連付けられたイベントメッセージを、クライアント端末装置３に配信する。

なお、クライアント端末装置３側におけるネット配信動画の再生が停止されたときや再開されたときには、ウェブリソース提供部２６２は、イベントメッセージを管理するための情報を適宜初期化（クリア）してもよい。また、前記の通り、ウェブリソース提供部２６２は、クライアント端末装置３側でのそのときの再生位置に基づいて、イベントメッセージを配信する。したがって、例えば、クライアント端末装置３側で巻き戻しの操作（再生位置を過去に遡らせる操作）が行われたなどの場合にも、ウェブリソース提供部２６２は、適切なタイミングでイベントメッセージを繰り返し送信することもできる。

なお、前述の通り、使い捨てのイベント（例えば、緊急地震速報等）は、配信されるネット動画の再生位置に関連付けられない。このため、ウェブリソース提供部２６２は、そのような使い捨てのイベントについては、１回だけクライアント端末装置３に配信すれば充分である。即ち、使い捨てのイベントの再送は行われずに済む。

つまり、本手法では、ウェブリソース提供部２６２は、配信先のクライアント端末装置３におけるウェブリソースの再生位置の情報をクライアント端末装置３から受け取る。また、ウェブリソース提供部２６２は、受け取った再生位置の情報に基づくタイミングで、そのウェブリソースにおける特定の再生位置に関連付けられたイベント情報を、そのクライアント端末装置３に対して送信する。

上記の通り、本手法によれば、配信されるネット動画等の内容に関連付けられたイベントの、通知のタイミングを制御することが可能となる。また、クライアント端末装置３側で再生位置の変更（巻き戻しや早送り等、いずれもそれが可能な場合）が行われたときにも、適切にイベントメッセージを配信することが可能となる。即ち、イベント送信のタイミングがずれたり、送信されるべきイベントメッセージが送信されないといった事態を避けたり、（早送り等でスキップされたために）送信されるべきではないイベントメッセージが送信されてしまったりといった事態を避けたり、できる。

（４）イベント情報（ＥＭ）のクライアント端末装置３への伝送（その４、コンテンツに関連付くイベントの、複数のクライアント端末装置３それぞれにおける制御）
本手法は、上記の、クライアント端末装置３側での再生制御に基づくイベント配信の、さらなる変形例である。本手法では、受信端末装置２は、複数のクライアント端末装置３のそれぞれについて、個別に動画再生制御情報を管理する。

そのために、クライアント端末装置３側からの機器発見および認証等（図４を参照）のリクエストに基づいてペアリングが成立する都度、クライアント端末連携制御部２６３はウェブリソース提供部２６２に対して、そのクライアント端末装置３の端末ＩＤを渡す。これにより、受信端末装置２のウェブリソース提供部２６２は、任意の時点において、ペアリング済みのクライアント端末装置３の端末ＩＤのセットを保持することができる。

そして、ウェブリソース提供部２６２は、上記の端末ＩＤごと（即ち、ペアリング相手であるクライアント端末装置３ごと）に個別に動画再生制御情報を管理する。そして、ウェブリソース提供部２６２は、この端末ＩＤごとに個別の動画再生制御情報に基づいて、イベントメッセージを、個々のクライアント端末装置３に対して送信することができる。また、ウェブリソース提供部２６２は、端末ＩＤごとに個別に、どのイベントメッセージ（メッセージＩＤやメッセージグループＩＤで識別される)を送信済みであるかを管理し、その管理状況に基づいてイベントメッセージを送信することができる。

つまり、本手法では、ウェブリソース提供部２６２は、複数の前記クライアント端末装置３をそれぞれ識別する。ウェブリソース提供部２６２は、それぞれのクライアント端末装置３から受け取った再生位置の情報に基づくタイミングで、ウェブリソースにおける特定の再生位置に関連付けられたイベント情報を、複数のクライアント端末装置３のそれぞれに対して送信する。

つまり、本手法を用いる受信端末装置２は、複数のクライアント端末装置３に対してそれぞれウェブリソースとしての動画を配信している場合にも、各々のクライアント端末装置３に固有の状況（再生位置等）に応じて、イベントメッセージを配信することが可能となる。

（５）イベント情報（ＥＭ）のクライアント端末装置３への伝送（その５、クライアント端末装置３側でのメッセージ重複のハンドリング）
本手法では、既に説明した手法とは異なった方法で、重複メッセージが何度も配信されないようにするための制御を行う。具体的には、前述の「（２）イベント情報（ＥＭ）のクライアント端末装置３への伝送－その２」の手法では、受信端末装置２側(サーバー側)で、重複メッセージを１回だけ配信するための制御を行った。本手法では、その制御を受信端末装置２側では行わず、同様の制御をクライアント端末装置３側で行うようにする。

本手法におけるクライアント端末装置３による処理は、次の通りである。即ち、クライアント端末装置３は、端末間連携通信により、受信端末装置２からイベントメッセージを受信する。クライアント端末装置３が受信するイベントメッセージは、図６を参照しながら説明したように、メッセージＩＤとメッセージグループＩＤとを持っている。クライアント端末装置３は、受信したイベントメッセージのメッセージＩＤおよびメッセージグループＩＤを記録し、管理する。クライアント端末装置３は、管理されている情報に基づいてイベントメッセージの重複を管理する。つまり、メッセージＩＤおよびメッセージグループＩＤのいずれか一方または両方（識別情報と呼ぶ）を用いて、イベントメッセージを識別する。クライアント端末装置３は、受信したイベントメッセージの識別情報が、それまでに受信済みのイベントメッセージの識別情報と一致するか否かを確認する。受信したイベントメッセージの識別情報が既に受信済みのイベントメッセージの識別情報と一致しない場合には、クライアント端末装置３は、そのイベントメッセージの内容に応じた処理（例えば、イベント内容（サッカーにおけるゴール等）に応じた演出の処理）を実行する。受信したイベントメッセージの識別情報が受信済み（処理済み）の識別情報と一致する場合には、クライアント端末装置３は、今回はそのイベントメッセージについて何も処理をしない。言い換えれば、クライアント端末装置３は、そのイベントメッセージを読み飛ばす。

以上説明したように、本手法では、クライアント端末装置３は、受信したイベント情報が持つ識別情報に基づいて、そのイベント情報が処理済みであるか否かを判定し、既に処理済みであるイベント情報についての処理を抑止する制御を行う。このような、クライアント端末装置３側での識別情報に基づいた制御によって、同一のイベントを複数回処理しないようにすることができる。

なお、ここまでで説明した（１）から（５）までの手法では、受信端末装置２が、映像あるいは音声を受信してクライアント端末装置３に対して提供するか否かに関わらず、イベント情報をクライアント端末装置３に配信することができる。即ち、映像や音声の有無に関わらず、受信端末装置２は、放送信号に含まれるイベントメッセージを受信し、そのイベントメッセージをクライアント端末装置３に配信できる。

（６）ＭＴＥによるイベント情報の伝送
本手法では、ＭＴＥによりイベント情報を受信端末装置２からクライアント端末装置３に配信する。

具体的には、次の通りである。受信端末装置２が受信した放送信号から抽出された映像や音声のデータを、トランスコード部２６１は、ネット動画配信用のフォーマットに変換する。ネット動画配信用のフォーマットは、例えばＭＰＥＧ－ＤＡＳＨ等である。トランスコード部２６１は、生成したネット動画配信用のフォーマットのデータを、イベント処理部２８２を経由して、ウェブリソース提供部２６２に渡す。

一方で、受信端末装置２がイベントメッセージを受信すると、イベント処理部２８２はそのイベントメッセージを取得する。イベント処理部２８２は、イベントメッセージの情報をＭＴＥのデータに変換するとともに、トランスコード部２６１から渡される上記のネット動画用のコンテンツのデータに上記ＭＴＥを挿入する。このように、ＭＴＥが挿入されたネット動画配信用のコンテンツのデータは、ウェブリソース提供部２６２で管理される。ウェブリソース提供部２６２は、クライアント端末装置３からの要求に応じて、ＭＴＥが挿入されているネット動画配信用のコンテンツのデータを、クライアント端末装置３に配信する。

図７は、イベント処理部２８２がネット配信用の動画コンテンツに挿入するＭＴＥの例を示す概略図である。図示するように、ＭＴＥは、例えばＪＳＯＮ形式で記述される。同図に示す第１行目から第１５行目までは、１つのＭＴＥである。このＭＴＥは、「scheme_id_url」（第２行目、スキームＩＤ ＵＲＬ、識別子）、「value」（第３行目、値）、「event_id」（第４行目、イベントＩＤ）、「presentation_delta」（第５行目、プレゼンテーションデルタ）、「time_scale」（第６行目、タイムスケール）、「presentation_delta」（第７行目、プレゼンテーションデルタ）、「event_duration」（第８行目、イベント持続期間）のそれぞれのデータを持つ。また、このＭＴＥは、第９行目から第１４行目までに記述されるメッセージデータ（message_data）を持つ。このメッセージデータは、コンポーネントタグ（"component_tag"、値は"0x40"）と、メッセージグループＩＤ（"message_group_id"、値は０）と、メッセージＩＤ（"message_id"、値は１７０）と、メッセージバージョン（"message_version"、値は１）と、プライベートデータ（"private_data"、値は"event msg"という文字列）とを含むものである。このメッセージデータが、イベントの内容を表す情報である。

本手法では、受信端末装置２は、イベントの情報を、ネット配信動画に挿入されたＭＴＥとしてクライアント端末装置３に配信する。つまり、イベントの情報は、動画内の特定の再生位置に挿入される。

具体的には、本手法では、イベント処理部２８２は、イベント情報を、メディアタイムドイベント（ＭＴＥ）として生成する。イベント処理部２８２は、生成したメディアタイムドイベントを、トランスコード部２６１が出力したウェブリソースに挿入する。ウェブリソース提供部２６２は、メディアタイムドイベントが挿入されたウェブリソースを、クライアント端末装置３に対して送信する。これにより、クライアント端末装置３は、イベントのタイミングを、配信されるネット動画内の再生位置と関連付けて把握することができる。即ち、クライアント端末装置３は、ネット配信動画内の所定の位置と同期する形でそのイベントについての処理を、容易に行うことができる。

（７）字幕データをイベント情報として配信
図２を参照しながら説明した通り、受信端末装置２が放送信号として受信するリソースの一つは、字幕のリソースである。デジタル字幕データについては、ＡＲＩＢ標準でも規定されている。本手法では、受信端末装置２は、字幕のデータを含むイベント情報を、クライアント端末装置３に配信する。

具体的な処理は、次の通りである。受信端末装置２の字幕デコーダー部２１４は、放送信号から抽出された字幕リソースをデコードする。字幕デコーダー部２１４は、デコード処理の結果である字幕データを、イベント処理部２８２に渡す。イベント処理部２８２は、その字幕データを含むＭＴＥのデータを生成し、そのＭＴＥをネット配信動画のコンテンツに挿入する。ＭＴＥをネット配信動画に挿入する処理については、前の「（６）ＭＴＥによるイベント情報の伝送」においても説明した通りである。イベント処理部２８２は、ＭＴＥを挿入したネット配信動画のデータを、ウェブリソース提供部２６２に渡す。ウェブリソース提供部２６２は、そのネット配信動画を管理するとともに、クライアント端末装置３に配信する。

これにより、クライアント端末装置３は、字幕データを含むＭＴＥが挿入されたネット配信動画コンテンツを、受信端末装置２から受信することができる。つまり、クライアント端末装置３は、ネット配信動画に挿入されたＭＴＥから、字幕データを取り出して利用することができる。

図８は、字幕データをイベントとして挿入したＭＴＥの例を示す概略図である。ＭＴＥは、例えばＪＳＯＮ形式で記述される。同図に示す第１行目から第１５行目までは、１つのＭＴＥである。図７の場合と同様に、このＭＴＥは、「scheme_id_url」、「value」、「event_id、「presentation_delta」、「time_scale」、「presentation_delta」、「event_duration」のそれぞれのデータを持つ。また、このＭＴＥは、第９行目から第１４行目までに記述されるメッセージデータ（message_data）を持つ。

このメッセージデータは、第１０行目のコンテンツ識別情報（"content"）、第１１行目のテキスト（"text"）、第１２行目の開始日時（"startTime"）、第１３行目の終了日時（"endTime"）のそれぞれのデータを含む。コンテンツ識別情報は、字幕テキストが挿入される対象となるコンテンツを識別する情報である。コンテンツ識別情報は、例えば、サービスを識別する情報であってよい。コンテンツ識別情報は、一例として、３２７３６という数値である。テキストは、放送信号から抽出された字幕のテキストである。テキストは、一例として、「分かった。僕に任せて。」というものである。開始日時は、当該字幕テキストの提示開始の日時のデータである。図示する例では、開始日時は、日本時間の２０２０年０８月０７日１２時５８分３７秒である。終了日時は、当該字幕テキストの提示終了の日時のデータである。図示する例では、終了日時は、日本時間の２０２０年０８月０７日１２時５８分４２秒である。

つまり、本手法において字幕情報を挿入したメッセージデータは、コンテンツを識別する情報と、字幕のテキストと、その字幕の提示タイミング（開始および終了の日時）の情報を含む。

つまり、本手法では、イベント処理部２８２が生成するメディアタイムドイベントは、放送信号から抽出された字幕を、付随情報として含むものである。

なお、字幕テキストをＭＴＥに格納する形で受信端末装置２からクライアント端末装置３に配信する代わりに、ハイブリッドキャストの端末連携機能におけるsendtextの機能を用いて受信端末装置２が字幕テキストのデータをクライアント端末装置３に配信するようにしてもよい。

本手法により、放送信号に含まれていた字幕テキストのデータを、受信端末装置２は、イベント情報として、クライアント端末装置３に送信することができる。

（８）字幕データをイベント情報として配信する際のオプション（その１）
上で説明した手法では字幕データをイベント情報として、受信端末装置２からクライアント端末装置３に配信した。本手法では、そのオプションとして、受信端末装置２が受信した放送信号から抽出された、字幕データ以外の放送リソースを、イベント情報として挿入してクライアント端末装置３に配信する。本手法でイベント情報に含められる放送リソースは、例えば、文字スーパー、ＳＩ（サービス情報）、ＡＩＴ（ハイブリッドキャストのアプリケーション情報テーブル）、ＢＭＬ（ＢＭＬで記述されたデータ放送コンテンツ）等である。

つまり、本手法では、イベント処理部２８２が生成するメディアタイムドイベントは、放送信号から抽出された文字スーパーと、アプリケーション情報テーブル（ＡＩＴ）と、サービス情報（ＳＩ）と、データ放送コンテンツと、のいずれか、を前記付随情報として含むものである。

なお、本手法において、受信端末装置２は、上記のイベント情報を、ＭＴＥとしてクライアント端末装置３に配信してもよいし、ハイブリッドキャストの端末連携機能におけるsendtextの機能を用いてクライアント端末装置３に配信してもよい。

（９）字幕データをイベント情報として配信する際のオプション（その２）
本手法は、字幕データをイベント情報として受信端末装置２からクライアント端末装置３に配信する手法の、さらなるオプションである。本手法では、ＭＴＥ内のメッセージデータ（message_data）の領域（図８の、第９行目から第１４行目まで）に、ＵＲＬを含めるようにする。具体的には、例えば、図８に示すデータにおける「message_data」で示されるブロック内に、ＵＲＬを記述するための要素（例えば「url」等のラベルを使用）を設けるようにする。

上記のＵＲＬは、例えば、外部のサーバー装置内の場所や、受信端末装置２自身内の場所を示すものであってよい。上記のＵＲＬが、字幕テキストが格納された場所を指し示すものであってもよいし、他の任意のデータが格納された場所を示すものであってもよい。

本手法を用いると、例えばＭＴＥのデータのサイズに上限がある場合であっても、その上限を超えるサイズのデータにアクセスするための情報を、ＭＴＥによって受信端末装置２からクライアント端末装置３に伝えることが可能となる。言い換えれば、ＭＴＥのサイズの上限を超えるデータを、本手法によって補完することが可能となる。

（１０）ＭＴＥを配信する受信端末装置２側での処理オプション（その１）
本手法は、イベント情報をＭＴＥとして配信する受信端末装置２側での処理オプションの１つである。本手法では、受信端末装置２がイベントの重複を回避する。

具体的には、受信端末装置２のイベント処理部２８２は、放送信号に含まれる受信するイベントメッセージを適切に識別する。イベント処理部２８２は、イベント識別情報やイベントの内容等に基づいて、受信したイベントメッセージが、処理済み（配信済み）のイベントメッセージと同一のイベントを表すものであるか否かを判定する。未処理のイベントメッセージである場合には、イベント処理部２８２は、通常通りにそのイベントメッセージに対応するＭＴＥを生成し、ネット配信動画のコンテンツに挿入する。処理済みのイベントメッセージである場合には、イベント処理部２８２は、そのイベントメッセージに基づくＭＴＥの生成および挿入を抑止する。

本手法により、同一の内容のイベントは、一度だけ、受信端末装置２からクライアント端末装置３に配信される。つまり、同一のイベントが重複してクライアント端末装置３に配信されることを避けることができる。

（１１）ＭＴＥを配信する受信端末装置２側での処理オプション（その２）
本手法は、イベント情報をＭＴＥとして配信する受信端末装置２側での処理オプションの１つである。本手法では、受信端末装置２が１つのイベントを繰り返して１つのクライアント端末装置３に配信することを可能とする。

具体的には、受信端末装置２のイベント処理部２８２は、放送信号に含まれる受信するイベントメッセージの内容に応じたランク付けを行う。このランク付けは、例えば、イベントの重要度を表すものである。イベント処理部２８２は、イベントメッセージに基づいてＭＴＥを作成し、ネット配信動画に挿入する。ただし、イベント処理部２８２は、所定のランクのイベントメッセージについては、そのイベントを表すＭＴＥを、複数回繰り返してネット配信動画に挿入するようにする。これにより、受信端末装置２は、所定のランク付けがされたイベントに関しては、その内容を表すＭＴＥを複数回繰り返してクライアント端末装置３に配信することとなる。

本手法によれば、例えば通信ネットワークの輻輳やその他の通信エラーなどが生じる際にも、そのイベントをクライアント端末装置３に伝達することのできる確実性が高まる。つまり、一例として緊急地震速報などの重要なイベントを、より確実にクライアント端末装置３に伝えることが可能となる。

（１２）ＭＴＥを配信する受信端末装置２側での処理オプション（その３）
本手法は、イベント情報をＭＴＥとして配信する受信端末装置２側での処理オプションの１つである。本手法では、受信端末装置２のウェブリソース提供部２６２が、ＭＴＥのパース機能を持つ。これにより、ウェブリソース提供部２６２は、イベント処理部２８２が挿入したＭＴＥの情報を管理する必要がない。

（１３）ＭＴＥを配信する受信端末装置２側での処理オプション（その４）
本手法は、イベント情報をＭＴＥとして配信する受信端末装置２側での処理オプションの１つである。本手法では、受信端末装置２のイベント処理部２８２は、特定のクライアント端末装置３のみに対してＭＴＥを配信する。

具体的には、受信端末装置２のイベント処理部２８２は、イベントを配信する先のクライアント端末装置３を識別する情報（端末ＩＤ、コンパニオンＩＤ）を、"scheme_id_url"の値としてＭＴＥに設定する。これにより、ウェブリソース提供部２６２は、上記の"scheme_id_url"で指定されるクライアント端末装置３のみに対して、ＭＴＥを配信することとなる。本手法により、ＭＴＥを配信する先を、特定のクライアント端末装置３のみに絞ることが可能となる。なお、識別する情報を、図７の第９行目“message_data”の箇所に記載してもよい。

なお、上記の"scheme_id_url"は、図７に示したＭＴＥの第２行目や図８に示したＭＴＥの第２行目の要素である。

（１４）ＭＴＥの配信を受けるクライアント端末装置３側での処理オプション
本手法は、ＭＴＥとしてのイベント情報の配信を受けるクライアント端末装置３側での処理オプションの１つである。本手法では、クライアント端末装置３側の処理として、イベントの重複を回避する。

具体的には、クライアント端末装置３の受信端末連携制御部３６３は、受信したＭＴＥをハンドリングする。受信端末連携制御部３６３は、受信したＭＴＥに含まれる内容（識別情報やイベント内容を表す情報等）に基づいて、受信したイベントが、前に受信済み（処理済み）のイベントと同一のものであるか否かを判定する。

未処理のイベントである場合には、受信端末連携制御部３６３は、通常通りにそのイベントに応じた処理（例えば、ネット配信の動画コンテンツの内容に合った、ＬＥＤライト等の演出等）を実行するよう、クライアント端末装置３を制御する。

処理済みのイベントである場合には、受信端末連携制御部３６３は、ここで受信したＭＴＥに基づく演出等の処理を行わない。即ち、クライアント端末装置３は、そのＭＴＥを読み飛ばす。

本手法により、同一の内容のイベントがＭＴＥとして複数回配信されても、配信を受けるクライアント端末装置３は、一度だけ、そのイベントに対応する処理を行うようにすることができる。即ち、イベントの重複を避けることができる。

（１５）ＭＴＥに関する処理オプション
本手法は、ＭＴＥのハンドリングについての処理オプションの１つである。本手法では、複数の"scheme_id_url"を使い分けて、ＭＴＥの振り分けなどのハンドリングを行う。

具体的には、受信端末装置２のイベント処理部２８２は、放送信号から抽出されたイベントの情報に基づいてＭＴＥを生成する際に、ＭＴＥの種別に応じて異なる"scheme_id_url"の値を、ＭＴＥ内に設定する。

図９は、種別（用途等）に応じて使い分けられる"scheme_id_url"（識別子）の一覧の例である。図示する例では、識別子は、まず複数のカテゴリーの分類に対応する。ここでのカテゴリーの例は、ＥＭ（イベントメッセージ）、字幕、文字スーパー、汎用といったものである。これらのうち、「ＥＭ」は、さらに複数の用途に分けられる。即ち、「ＥＭ」は、人名に関わる緊急の情報、演出、パーソナライズコンテンツなどといった用途を含む。また、「字幕」のカテゴリーは、字幕情報という用途に対応する。「文字スーパー」のカテゴリーは、ニュース、選挙情報という用途に対応する。「汎用」のカテゴリーは、汎用という用途に対応する。そして、ここに挙げたそれぞれの用途が、個別の識別子を有する。

即ち、用途「人命にかかわる緊急の情報」の識別子は「urn:scte:scte35:2013:emg」である。用途「演出」の識別子は「urn:scte:scte35:2013:pro」である。用途「パーソナライズコンテンツ」の識別子は「urn:scte:scte35:2013:personal」である。用途「字幕情報」の識別子は「urn:scte:scte35:2013:text」である。用途「ニュース、選挙情報」の識別子は「urn:scte:scte35:2013:news」である。用途「汎用」の識別子は「urn:scte:scte35:2013:general」である。なお、ここで図示したカテゴリー、用途、および識別子（"scheme_id_url"）の対応関係は、あくまでも例に過ぎない。代わりに、カテゴリー、用途、および識別子の他の組合せを用いてもよい。

つまり、本手法では、受信端末装置２側において、ＭＴＥの用途に応じた識別子（"scheme_id_url"）をＭＴＥ内に設定する。受信端末装置２は、そのＭＴＥをクライアント端末装置３に配信する。配信先のクライアント端末装置３は、１台の装置であってもよいし、複数台の装置であってもよい。このＭＴＥを受信したクライアント端末装置３内の受信端末連携制御部３６３は、ＭＴＥ内に設定された識別子を参照することによって、ＭＴＥを複数の機能部に振り分けたり、特定の識別子を有するＭＴＥのみを処理対象としたり、ＭＴＥの優先度付けを行って処理順序を制御したりする。

以上説明したように、本手法では、受信端末装置２は、ＭＴＥごとに異なる識別子を付与することができる。識別子は、例えば、用途を表す。ただし、識別子を、用途以外のものに対応する情報として用いてもよい。ＭＴＥの配信を受けたクライアント端末装置３は、識別子に基づいて、ＭＴＥを振り分けたり、ＭＴＥの処理優先順を制御したりすることができる。つまり、本手法を用いるシステム１は、ＭＴＥに関して多様なハンドリングを行うことが可能となる。

（１６）解析によるメタデータの取得と、メタデータのクライアント端末装置３への配信
本手法では、受信端末装置２は、放送信号として受信した映像や音声のコンテンツを解析して、その解析結果をメタデータとして管理するとともに、そのメタデータをクライアント端末装置３に配信する。

具体的には、受信端末装置２のデータ解析部２８１は、放送信号から抽出された映像や音声を解析する。データ解析部２８１が映像や音声を解析するために用いる技術自体は、既存の技術である。データ解析部２８１は、その解析結果のデータを、放送された映像や音声に関するメタデータとして管理する。なお、データ解析部２８１は、メタデータを、必要に応じて、映像や音声の再生位置（例えば、コンテンツの先頭をゼロとする相対時刻）に関連付けて管理する。

データ解析部２８１は、例えば、映像を解析して、（顔認識等の技術を用いて）映像に登場する人物を特定（出演者名、役者名、役名等を特定）し、人物を特定した情報をメタデータとして管理する。また、データ解析部２８１は、映像を解析して、（物体を認識する技術等を用いて）映像内に含まれる物体を特定し、物体を特定した情報をメタデータとして管理する。また、データ解析部２８１は、文字スーパーのリソースを解析して、（文字認識等の技術を用いて）文字スーパーの画像（映像）内に含まれる文字の情報（語等）を、メタデータとして管理する。また、データ解析部２８１は、音声を解析して、音声認識等の技術を用いて発話内容（セリフなど）のテキストをメタデータとして管理したり、音響特徴に基づく話者特定の技術を用いて話者を特定した結果をメタデータとして管理したりする。

データ解析部２８１は、管理するメタデータの一部または全部を、ウェブリソース提供部２６２に渡す。ウェブリソース提供部２６２は、ハイブリッドキャストの端末連携機能における双方向の端末連携通信の機能を用いて、データ解析部２８１から受け取ったメタデータを、クライアント端末装置３に配信することができる。ここで用いる端末連携通信の機能は、図４のステップＳ１１５で示した機能である。受信端末装置２は、ハイブリッドキャストの端末連携機能におけるsendtextの機能を用いて、上記の端末連携通信により、メタデータをクライアント端末装置３に送ることができる。つまり、本手法によると、受信端末装置２が受信した放送の映像や音声に関するメタデータを、受信端末装置２からクライアント端末装置３に伝送することができる。

なお、本手法において、データ解析部２８１が管理するメタデータのすべてを必ずしもクライアント端末装置３に配信する必要はない。データ解析部２８１やウェブリソース提供部２６２などが適宜選択したメタデータを、クライアント端末装置３に配信するようにしてもよい。

また、本手法において、受信端末装置２は、必ずしも、映像や音声のリソースをクライアント端末装置３に配信しなくてもよい。また、クライアント端末装置３は、必ずしも、映像や音声をデコードして再生する機能を持っていなくてもよい。このような場合にも、本手法を用いることにより、映像や音声に関するメタデータを、受信端末装置２からクライアント端末装置３に配信することができる。言い換えれば、映像や音声を再生する機能を持たないクライアント端末装置３に対しても、映像や音声に関するメタデータを、受信端末装置２から配信することができる。

（１７）ＭＴＥによる、メタデータのクライアント端末装置３への配信
上で説明した手法では、データ解析部２８１が生成したメタデータを、ハイブリッドキャストの端末連携機能における連携端末通信（sendtext）の機能を用いてクライアント端末装置３に配信した。代わりに、本手法では、ＭＴＥのデータにメタデータを格納して、受信端末装置２からクライアント端末装置３に配信する。

具体的には、次の通りである。データ解析部２８１は、既に説明した方法により、映像や音声等のリソースに関連するメタデータを生成し、管理する。データ解析部２８１は、管理するメタデータのうちの必要なデータを、イベント処理部２８２に渡す。イベント処理部２８２は、データ解析部２８１から渡されたメタデータを用いてＭＴＥを作成することができる。イベント処理部２８２は、トランスコード部２６１から渡される映像等（ネット配信動画）に、ここで作成したＭＴＥを挿入する。イベント処理部２８２は、ＭＴＥを挿入したネット配信動画を、ウェブリソース提供部２６２に渡す。ウェブリソース提供部２６２は、クライアント端末装置３からの要求等に応じて、ＭＴＥが挿入されているネット配信動画を、クライアント端末装置３に配信する。このようにして、クライアント端末装置３は、ＭＴＥ内に格納されているメタデータを取得することができる。

本手法では、メタデータがＭＴＥに埋め込まれている。したがって、ネット配信動画の特定の再生位置とメタデータとの間の同期をとりやすい。

（１８）メタデータ（解析結果）の精度の向上（その１）
本手法は、上の（１６）および（１７）の手法として説明したデータ解析の処理のうちの、字幕の精度を向上させるものである。

具体的には、受信端末装置２のデータ解析部２８１は、放送信号から抽出された字幕のデータ（ＡＲＩＢ字幕）を取得する。また、データ解析部２８１は、前述の通り、放送信号から抽出された音声を解析（音声認識処理）して、音声認識結果のテキストを取得する。なお、データ解析部２８１は、音声認識結果のテキストを、元の音声の再生位置（コンテンツ内の相対時刻）と関連付けて管理するようにする。上記のＡＲＩＢ字幕データのテキストと音声認識結果のテキストとは、完全一致はしないかもしれないが、相関関係を有する。したがって、データ解析部２８１は、ＡＲＩＢ字幕データのテキストと音声認識結果のテキストとの間のマッチング（アラインメント）を行うことができる。これにより、データ解析部２８１は、字幕データに、対応する音声認識結果に関連付けられた時刻（再生位置）の情報を付与することができる。

この情報を利用して、データ解析部２８１は、ＡＲＩＢ字幕データに基づくウェブプラットフォーム用のＴＴＭＬファイルを生成する。なお、ＴＴＭＬは、「Timed Text Markup Language」（時刻が付与されたテキストのマークアップ言語）の略である。データ解析部２８１が生成するＴＴＭＬファイルは、ＡＲＩＢ字幕データに基づくテキストを含むものである。また、そのＴＴＭＬファイルは、そのテキストの断片ごとに付与された時刻（コンテンツ内の相対時刻。再生位置。）の情報を含むものである。なお、ＴＴＭＬファイルのデータの形式自体は、標準化されている。

つまり、本手法では、データ解析部２８１は、放送信号から抽出された音声リソースを解析した結果である音声解析結果と、放送信号から抽出された字幕と、をマッチングする。データ解析部２８１は、マッチングによって得られる再生位置に前記字幕を関連付ける。そして、イベント処理部２８２は、再生位置に関連付けられた字幕を含むメディアタイムドイベントを、ウェブリソースに挿入する。

本手法では、上記の通り、字幕テキストの時刻精度が向上している。また、そのように精度の向上した字幕テキストのデータを、時刻情報と関連付けて、受信端末装置２からクライアント端末装置３に配信することが可能となる。クライアント端末装置３側では、再生する映像と、字幕テキストの提示のタイミングとを同期させることも可能となる。

（１９）メタデータ（解析結果）の精度の向上（その２）
本手法は、上の（１６）および（１７）の手法として説明したデータ解析の処理のうちの、映像解析の結果の精度をさらに向上させるものである。

具体的には、受信端末装置２のデータ解析部２８１は、前述の通り、放送信号から抽出された映像を解析して、人物を特定する情報を求めたり、物体を特定する情報を求めたり、文字スーパーに含まれる文字を認識（特定）したりする。データ解析部２８１は、これらの映像等の解析結果を、メタデータとして記憶し、管理する。データ解析部２８１は、本手法では、一方で、受信した放送信号から抽出された番組情報（ＥＰＧ－ＡＰＩなどのデータ）などから、当該放送番組の概略や、出演者名や、ロケ地などの情報を取得する。データ解析部２８１は、さらに外部のウェブサーバー装置などから、一般に公開されている当該放送番組に関連する情報を取得してもよい。

データ解析部２８１は、映像解析の結果として取得したメタデータが含む各データ項目に、番組情報（ＥＰＧ）から取得した情報を、キーワードマッチングや概念マッチングの方法等を用いて関連付ける。さらに、データ解析部２８１は、映像解析の結果として取得したメタデータが含む各データ項目に、外部のウェブサーバー装置などから取得した情報を、キーワードマッチングや概念マッチングの方法等を用いて関連付ける。このように、データ解析部２８１は、映像解析に基づいて生成したメタデータの、情報を充実させる。言い換えれば、データ解析部２８１は、メタデータを高度化する。

受信端末装置２は、データ解析部２８１が高度化したメタデータを、既に述べた方法でイベント情報の中に含めて、クライアント端末装置３側に配信することができる。この場合、受信端末装置２は、イベント情報を、ハイブリッドキャストの端末連携機能における端末連携通信（図４のステップＳ１１５）でクライアント端末装置３側に送信してもよいし、ＭＴＥとしてクライアント端末装置３側に送信してもよい。このようにして、クライアント端末装置３は、高度化されたメタデータを取得することができる。

つまり、本手法では、データ解析部２８１は、放送信号から抽出された映像リソースを解析した結果である映像解析結果と、放送信号から抽出された番組情報または外部のウェブサーバー装置から情報と、を関連付ける。データ解析部２８１は、ここで関連付けて得られたメタデータ（上記の高度化されたメタデータ）を生成する。イベント処理部２８２は、データ解析部２８１が生成したメタデータ（高度化されたメタデータ）を含むメディアタイムドイベントを、ウェブリソースに挿入する。

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

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

以上説明したように、本実施形態では、クライアント端末装置３は、受信端末装置２と連携する。クライアント端末装置３は、受信端末装置２が受信した放送信号から抽出されたリソースに基づく、映像あるいは音声の少なくともいずれかに付随する付随情報を含むイベント情報を、受信端末装置２から受信する。

なお、クライアント端末装置３において、上で説明したように、受信端末連携制御部３６３が、受信端末装置２との間での端末連携通信によって、前記イベント情報を受信するものであってよい。また、クライアント端末装置３では、上で説明したように、アプリケーションエンジン３５２において稼働するウェブアプリケーションがウェブリソースを受信する。クライアント端末装置３は、受信するウェブリソースに含まれるメディアタイムドイベント（ＭＴＥ）として、イベント情報を受信するものであってもよい。

［変形例］
上で説明した実施形態では、受信端末装置２は、トランスコード部２６１を備えていた。このトランスコード部２６１は、映像あるいは音声の少なくともいずれかをトランスコードし、ウェブリソースとして提供していた。そして、受信端末装置２は、この映像や音声のウェブリソースを、クライアント端末装置３に送信していた。受信端末装置２が放送信号に基づくイベント情報をクライアント端末装置３に送信するためには、必ずしも受信端末装置２はトランスコード部２６１を備える必要はない。例えば、ハイブリッドキャストの端末連携機能におけるsendtextの機能でＥＭ（イベントメッセージ）を受信端末装置２からクライアント端末装置３に送信する場合に、映像あるいは音声のウェブリソースは必要ではない。つまり、受信端末装置２が、映像や音声をトランスコードするためのトランスコード部２６１を備えない形態も可能である。

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

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

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

Claims (18)

1. 放送信号を受信する受信部と、
   前記放送信号から抽出されたリソースに基づくイベント情報を生成するイベント処理部と、
   前記イベント処理部が生成した前記イベント情報を、通信を介して、連携先のクライアント端末装置に対して送信するウェブリソース提供部と、
   を備える受信装置。
2. 受信された前記放送信号から抽出された映像リソースまたは音声リソースの少なくともいずれかのデータを、ウェブプラットフォームで利用可能な形式のデータにトランスコードして、ウェブリソースとして出力するトランスコード部、
   をさらに備え、
   前記イベント処理部は、前記映像リソースまたは前記音声リソースの少なくともいずれかに付随する付随情報を含む前記イベント情報を生成し、
   前記ウェブリソース提供部は、前記イベント処理部が生成した前記イベント情報を、前記トランスコード部が出力する前記ウェブリソースとともに、前記クライアント端末装置に対して送信する、
   請求項１に記載の受信装置。
3. 前記付随情報は、
   前記放送信号から抽出されたイベントメッセージと、字幕と、文字スーパーと、アプリケーション情報テーブル（ＡＩＴ）と、サービス情報（ＳＩ）と、データ放送コンテンツと、のいずれか、
   または、
   前記放送信号から抽出された前記映像リソースまたは前記音声リソースの少なくともいずれかを解析して得られたメタデータ、
   を含む、
   請求項２に記載の受信装置。
4. 前記ウェブリソース提供部は、ハイブリッドキャストの端末連携機能における前記連携先のクライアント端末装置との間での端末連携通信の機能を用いて、前記イベント情報を、前記連携先のクライアント端末装置に対して送信する、
   請求項１から３までのいずれか一項に記載の受信装置。
5. 前記付随情報は、前記放送信号から抽出されたイベントメッセージのデータを含み、
   前記ウェブリソース提供部は、同一内容の前記イベントメッセージのデータを含む前記イベント情報を複数回重複して前記クライアント端末装置に対して送信することを抑止する制御を行う、
   請求項２に記載の請求項４に記載の受信装置。
6. 前記ウェブリソース提供部は、前記クライアント端末装置における前記ウェブリソースの再生位置の情報を前記クライアント端末装置から受け取り、受け取った前記再生位置の情報に基づくタイミングで、前記ウェブリソースにおける特定の再生位置に関連付けられた前記イベント情報を、前記クライアント端末装置に対して送信する、
   請求項２に記載の、請求項４または５に記載の受信装置。
7. 前記ウェブリソース提供部は、複数の前記クライアント端末装置をそれぞれ識別するとともに、それぞれの前記クライアント端末装置から受け取った前記再生位置の情報に基づくタイミングで、前記ウェブリソースにおける特定の再生位置に関連付けられた前記イベント情報を、複数の前記クライアント端末装置のそれぞれに対して送信する、
   請求項６に記載の受信装置。
8. 前記イベント処理部は、前記イベント情報をメディアタイムドイベント（ＭＴＥ）として生成して、生成した前記メディアタイムドイベントを前記トランスコード部が出力した前記ウェブリソースに挿入し、
   前記ウェブリソース提供部は、前記メディアタイムドイベントが挿入された前記ウェブリソースを、前記クライアント端末装置に対して送信する、
   請求項２に記載の受信装置。
9. 前記イベント処理部が生成する前記メディアタイムドイベントは、前記放送信号から抽出された字幕と、文字スーパーと、アプリケーション情報テーブル（ＡＩＴ）と、サービス情報（ＳＩ）と、データ放送コンテンツと、のいずれか、を前記付随情報として含むものである、
   請求項８に記載の受信装置。
10. 抽出された前記音声リソースを解析した結果である音声解析結果と、抽出された前記字幕と、をマッチングすることによって得られる再生位置に前記字幕を関連付けるデータ解析部、
    をさらに備え、
    前記イベント処理部は、前記再生位置に関連付けられた前記字幕を含む前記メディアタイムドイベントを、前記ウェブリソースに挿入する、
    請求項９に記載の受信装置。
11. 抽出された前記映像リソースを解析した結果である映像解析結果と、前記放送信号から抽出された番組情報または外部のウェブサーバー装置から情報と、を関連付けることによって得られたメタデータを生成するデータ解析部、
    をさらに備え、
    前記イベント処理部は、前記データ解析部が生成した前記メタデータを含む前記メディアタイムドイベントを、前記ウェブリソースに挿入する、
    請求項９に記載の受信装置。
12. 請求項１に記載の受信装置から前記イベント情報を受信する受信端末連携制御部、
    を備えるクライアント端末装置。
13. 請求項２に記載の受信装置から前記ウェブリソースを受信して利用するウェブアプリケーションを稼働させるアプリケーションエンジンと、
    ハイブリッドキャストの端末連携機能により、前記ウェブリソースを利用するために必要な処理を、前記受信装置との連携動作として実行する受信端末連携制御部と、
    を備え、
    前記受信装置が受信した放送信号から抽出されたリソースに基づく、映像あるいは音声の少なくともいずれかに付随する付随情報を含むイベント情報を、前記受信装置から受信する、
    クライアント端末装置。
14. 前記受信端末連携制御部が、前記受信装置との間での端末連携通信によって、前記イベント情報を受信する、
    請求項１３に記載のクライアント端末装置。
15. 受信した前記イベント情報が持つ識別情報に基づいて、前記イベント情報が処理済みであるか否かを判定し、既に処理済みである前記イベント情報についての処理を抑止する制御を行う、
    請求項１４に記載のクライアント端末装置。
16. 前記ウェブアプリケーションが受信する前記ウェブリソースに含まれるメディアタイムドイベント（ＭＴＥ）として、前記イベント情報を受信する、
    請求項１３に記載のクライアント端末装置。
17. 放送信号を受信する受信部、を備えるコンピューターを、
    請求項１から１１までのいずれか一項に記載の受信装置、
    として機能させるためのプログラム。
18. コンピューターを、
    請求項１２から１６までのいずれか一項に記載のクライアント端末装置、
    として機能させるためのプログラム。

Images