JP6610555B2 - 受信装置、送信装置、およびデータ処理方法 - Google Patents

Description

本開示は、受信装置、送信装置、およびデータ処理方法に関する。さらに詳細には例えば放送波やネットワークを介したデータの送信または受信を実行する受信装置、送信装置、および通信データに対するデータ処理方法に関する。

放送局やコンテンツサーバ等、コンテンツを提供する送信装置から、テレビ、ＰＣ、携帯端末等の受信装置に対して、放送波等による一方向通信、あるいは、インターネット等のネットワークを介した双方向通信、一方向通信によって、放送番組等のコンテンツを送受信するシステムについての開発や規格化が、現在、盛んに進められている。

しかし、ネットワークを介したデータ送信においては、ネットワークの輻輳等により、一定のビットレートでのデータ受信が困難となる場合がある。
このような問題を解決するため、複数のビットレートのデータの細分化ファイルであるセグメントをネットワーク上に送信し、ネットワーク状況に応じてクライアント側で最適なビットレートのセグメントを選択して再生するアダプティブ（適応型）ストリーミングが提案されている。

このアダプティブ（適応型）ストリーミングの規格として、ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒＨＴＴＰ）がある。ＤＡＳＨは、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルを使用したアダプティブ（適応型）ストリーミング技術の標準規格である。

アダプティブ（適応型）ストリーミングでは、コンテンツ配信サーバは様々なクライアントで配信コンテンツの再生を可能とするため、複数のビットレートの動画コンテンツの細分化ファイルとこれらの属性情報やＵＲＬを記述したマニフェスト・ファイルを作成し保持する。

クライアントは、マニフェスト・ファイルをサーバから取得して、自装置の表示部のサイズや利用可能な通信帯域に応じた最適なビットレートコンテンツを選択し、選択コンテンツを受信して再生する。ネットワーク帯域の変動に応じてビットレートの動的な変更も可能であり、クライアント側では、状況に応じた最適なコンテンツを随時切り替えて受信することが可能となり、映像途切れの発生を低減した動画コンテンツ再生が実現される。なお、アダプティブ（適応型）ストリーミングについては、例えば特許文献１（特開２０１１−８７１０３号公報）に記載がある。

ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）符号化された動画や音声データを上記のＤＡＳＨに従ってストリーミング配信するための仕様を定めた規格としてＭＰＥＧ−ＤＡＳＨ規格がある。
ＭＰＥＧ−ＤＡＳＨ規格には、以下の２つの規格が含まれる。
（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格。
（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格。
ＭＰＥＧデータをＤＡＳＨに従ってストリーミング配信する場合は、このＭＰＥＧ−ＤＡＳＨ規格に従った処理が行われる。

一方、放送、インターネットからのコンテンツ配信を受信するクライアント（受信装置）には対話的サービスを行うためにＨＴＭＬ５ブラウザが搭載され、ＨＴＭＬ５にて記述されたアプリテーションがクライアントで実行される。
上記アダプティブ（適応型）ストリーミングもＨＴＭＬ５アプリケーションのＪａｖａＳｃｒｉｐｔ（登録商標）によって制御が行われる。
ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）利用技術の国際的標準化団体であるＷ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）は、このためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の標準規格として、ＭＳＥ（Ｍｅｄｉａ Ｓｏｕｒｃｅ Ｅｘｔｅｎｔｉｏｎｓ）−ＡＰＩを規定している。
このＭＳＥ−ＡＰＩを利用することで、アダプティブストリーミングのみならず、アプリケーションがユーザの属性に合わせた広告をコンテンツに挿入を行うことも可能である。

しかし、例えば、テレビ等のクライアント（受信装置）が、放送波を介した受信データにネットワークを介して受信するデータをアプリケーションの制御により重畳、あるいは置き換えて出力しようとする場合、データ出力時間の遅延が発生するという問題がある。
これは、例えば、ＭＳＥ−ＡＰＩでは、アプリケーションがチューナー受信データとネットワーク受信データを処理し、さらに合成処理において実行される様々なデータ処理の処理時間に起因する。
また、広告挿入において複数のＨＴＭＬ５ビデオをタイミングを合わせて重畳表示する場合でも、アプリケーションの制御によって放送番組の映像、音声と広告の映像、音声の出力タイミングを正確に合わせることは難しい。
これは、ＨＴＭＬ５ブラウザ等のアプリケーション実行環境では、アプリケーションが一秒以下の精度でタイミング合わせをするようなリアルタイム処理に適さないという問題に起因する。

さらに、放送システムの場合は、番組もしくやチャンネル毎に異なるアプリケーションを切り替えて実行するのが一般的である。従って、アプリケーションがＭＳＥ−ＡＰＩを利用し放送波を介して受信した映像音声データとインターネットの映像音声データを制御するような場合は、番組の切り替え、チャンネルの切り替えで映像、音声再生の連続性が失われるという重大な問題がある。

特開２０１１−８７１０３号公報

本開示は、例えば、上記問題に鑑みてなされたものであり、放送波、もしくは、ネットワークから受信した映像音声データの合成処理をアプリケーションが行うとともに、再生遅延の減少や、連続的な映像や音声データの再生を可能とする受信装置、送信装置、およびデータ処理方法を提供することを目的とする。

本開示の第１の側面は、
受信装置の受信データのバッファ処理を、受信装置が実行するアプリケーションのメディア再生の処理オブジェクトであるメディアソースオブジェクトとして開示するデータ処理部を有する受信装置にある。

さらに、本開示の第２の側面は、
受信装置において利用されるアプリケーションを送信する通信部を有し、
前記アプリケーションは、受信装置における受信データのバッファ処理を開示するメディアソースオブジェクトを利用して、受信データとアプリケーションの受信データとの合成処理を実行させるアプリケーションである送信装置にある。

さらに、本開示の第３の側面は、
受信装置において実行するデータ処理方法であり、
前記受信装置のデータ処理部が、受信データを受信装置が実行するアプリケーションのメディア再生の処理オブジェクトであるメディアソースオブジェクトに設定するデータ処理方法にある。

さらに、本開示の第４の側面は、
送信装置において実行するデータ処理方法であり、
送信装置の通信部が、受信装置において利用されるアプリケーションを送信し、
前記アプリケーションは、受信装置における受信データのバッファ処理を開示するメディアソースオブジェクトを利用して、受信データとアプリケーションの受信データとの合成処理を実行させるアプリケーションであるデータ処理方法にある。

本開示のさらに他の目的、特徴や利点は、後述する本開示の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

本開示の一実施例の構成によれば、放送受信データとネットワーク受信データの合成処理を効率的に実行する装置、方法が実現される。
具体的には、例えば受信装置が通信部を介して受信する放送受信データの処理を、ＨＴＭＬ５ブラウザのＭＳＥ ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を適用して、受信装置の実行するアプリケーションの処理オブジェクトであるメディアソースオブジェクトとしてアプリケーションが制御可能なように設定する。アプリケーションは、メディアソースオブジェクトに対する処理として、放送受信データのメディアソースオブジェクトをＨＴＭＬ５のビデオオブジェクトに設定し、放送受信データの映像音声再生をアプリケーションから制御する。アプリケーションは放送受信データのメディアソースオブジェクトを利用して前記放送受信データと、ネットワークを介して受信するネットワーク受信データとの合成処理の制御を実行する。アプリケーションは、ＡＰＩ適用処理によってアプリケーション時間軸と放送時間軸の時間差に相当する時間オフセットを取得し、高精度、低遅延のデータ合成処理の制御を実行する。
本構成により、放送受信データとネットワーク受信データの合成処理および出力処理を低遅延、高精度に行うことが可能となる。
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。

本開示の処理を実行する通信システムの一構成例について説明する図である。 送信装置の送信データについて説明する図である。 送信装置および受信装置のプロトコルスタックの例を示す図である。 サービスワーカー（ＳＷ）を利用した処理の具体例（ユースケース）について説明する図である。 サービスワーカー（ＳＷ）を利用した処理の具体例（ユースケース）について説明する図である。 サービスワーカー（ＳＷ）を利用した処理の一例を説明する図である。 放送受信コンテンツと、ネットワーク受信コンテンツとの合成表示処理例について説明する図である。 放送受信コンテンツと、ネットワーク受信コンテンツとの合成表示処理例について説明する図である。 アダプティブ（適応型）ストリーミングについて説明する図である。 アダプティブ（適応型）ストリーミングに従って、様々なビットレートのセグメントを受信して再生する受信装置の処理構成例を示す図である。 放送波とネットワークを介する２つの経路の受信データを合成して出力する場合の処理と、遅延要因について説明する図である。 本開示の受信装置（クライアント）における合成処理、すなわち放送波の受信データの一部を、ネットワーク受信データに置き換えて出力する処理を説明する図である。 放送波の受信データの一部を、ネットワーク受信データに置き換えて出力するメディアソース更新処理について説明する図である。 受信装置におけるデータ受信および合成処理に適用するハードウェア構成例について説明する図である。 受信装置の実行する全体的な処理のシーケンスを説明するフローチャートを示す図である。 受信装置のアプリケーションが実行する処理のシーケンスを説明するフローチャートを示す図である。 受信装置のアプリケーションが実行する処理のシーケンスを説明するフローチャートを示す図である。 通信装置である送信装置と受信装置の構成例について説明する図である。 通信装置である送信装置と受信装置のハードウェア構成例について説明する図である。

以下、図面を参照しながら本開示の受信装置、送信装置、およびデータ処理方法の詳細について説明する。なお、説明は以下の項目に従って行なう。
１．通信システムの構成例について
２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて
３．送信装置と受信装置の実行する通信処理例について
４．サービスワーカー（ＳＷ）について
５．放送波とネットワーク双方の受信データの合成処理について
６．放送波とネットワーク双方の受信データの合成処理における遅延を解消または減少させた実施例について
７．受信装置におけるデータ受信および合成処理に適用するハードウェア構成例について
８．受信装置の実行する処理のシーケンスについて
９．サービスワーカー（ＳＷ）とアプリケーションを利用した処理例について
１０．送信装置と受信装置の構成例について
１１．本開示の構成のまとめ

［１．通信システムの構成例について］
まず、図１を参照して本開示の処理を実行する通信システムの一構成例について説明する。
図１に示すように、通信システム１０は、画像データや音声データ等のコンテンツを送信する通信装置である送信装置２０と、送信装置２０の送信するコンテンツを受信する通信装置である受信装置３０を有する。

送信装置２０は、具体的には、例えば放送局２１やコンテンツサーバ２２等、コンテンツを提供する側の装置である。
一方、受信装置３０は、一般ユーザのクライアント装置であり、具体的には、例えばテレビ３１、ＰＣ３２、携帯端末３３等によって構成される。

送信装置２０と受信装置３０間のデータ通信は、インターネット等のネットワークを介した双方向通信、一方向通信、あるいは、放送波等による一方向通信の少なくともいずれか、あるいは両者を利用した通信として行われる。

送信装置２０から受信装置３０に対するコンテンツ送信は、例えばアダプティブ（適応型）ストリーミング技術の規格であるＭＰＥＧ−ＤＡＳＨ規格に従って実行する。
ＭＰＥＧ−ＤＡＳＨ規格には、以下の２つの規格が含まれる。
（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格、
（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格、
送信装置２０から、受信装置３０に対するコンテンツ配信は、上記のＭＰＥＧ−ＤＡＳＨ規格に従って実行する。

送信装置２０は、コンテンツデータを符号化し、符号化データおよび符号化データのメタデータを含むデータファイルを生成する。符号化処理は、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って行われる。なお、送信装置２０がＭＰ４形式のデータファイルを生成する場合の符号化データのファイルは「ｍｄａｔ」、メタデータは「ｍｏｏｖ」や「ｍｏｏｆ」等と呼ばれる。

送信装置２０が受信装置３０に提供するコンテンツは、例えば音楽データや、映画、テレビ番組、ビデオ、写真、文書、絵画および図表などの映像データや、ゲームおよびソフトウェアなど、様々なデータである。

送信装置２０の送信データについて図２を参照して説明する。
ＭＰＥＧ−ＤＡＳＨ規格に従ってデータ送信を実行する送信装置２０は、図２に示すように、大きく分けて以下の複数種類のデータの送信を行う。
（ａ）シグナリングデータ５０
（ｂ）ＡＶセグメント６０
（ｃ）その他のデータ（ＥＳＧ，ＮＲＴコンテンツ等）７０

ＡＶセグメント６０は、受信装置において再生する画像（Ｖｉｄｅｏ）や、音声（Ａｕｄｉｏ）データ、すなわち例えば放送局の提供する番組コンテンツ等によって構成される。例えば、上述したＭＰ４符号化データ（ｍｄａｔ）や、メタデータ（ｍｏｏｖ，ｍｏｏｆ）によって構成される。

一方、シグナリングデータ５０は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、制御情報によって構成される。
受信装置３０は、このシグナリングデータ５０を、再生対象となる番組コンテンツを格納したＡＶセグメント６０の受信に先行して受信することが必要となる。
このシグナリングデータ５０は、例えばＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式のデータとして、スマホやテレビ等のユーザ端末である受信装置（クライアント）に送信される。

前述したように、シグナリングデータは、随時、繰り返し送信される。例えば１００ｍｓｅｃ毎など、頻繁に繰り返し送信される。
これは、受信装置（クライアント）が、いつでも、即座にシグナリングデータを取得することを可能とするためである。
クライアント（受信装置）は、随時、受信可能なシグナリングデータに基づいて、必要な番組コンテンツのアクセス用アドレスの取得や、コーデック設定処理など、番組コンテンツの受信および再生に必要な処理を遅滞なく実行することが可能となる。

その他のデータ７０は、例えばＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）、ＮＲＴコンテンツ等が含まれる。
ＥＳＧは、電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）であり、例えば番組表等の案内情報である。
ＮＲＴコンテンツはノンリアルタイム型のコンテンツである。

ＮＲＴコンテンツには、例えば、クライアントである受信装置３０のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。
後述するアプリケーション等の制御プログラムとして利用されるサービスワーカー（Ｓｅｒｖｉｃｅ Ｗｏｒｋｅｒ）も、ＮＲＴコンテンツに含まれる。

図２に示す以下のデータ、すなわち、
（ａ）シグナリングデータ５０
（ｂ）ＡＶセグメント６０
（ｃ）その他のデータ（ＥＳＧ，ＮＲＴコンテンツ等）７０
これらのデータは、例えば、データ通信プロトコル：ＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）に従って送信される。

［２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて］
データ通信プロトコル：ＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）はマルチキャストにより伝送するコンテンツのセッション管理を行うプロトコルである。
例えば送信装置であるサーバ側で生成されるファイル（ＵＲＬとバージョンで識別される）は、ＦＬＵＴＥプロトコルに従って、受信装置であるクライアントに送信される。

受信装置（クライアント）３０は、例えば受信装置（クライアント）３０の記憶部（クライアントキャッシュ）に、受信ファイルのＵＲＬおよびバージョンとファイルを対応付けて蓄積する。
同じＵＲＬでバージョンが異なるものはファイルの中身が更新されているものとみなす。ＦＬＵＴＥプロトコルは一方向ファイル転送制御のみを行うもので、クライアントにおけるファイルの選択的なフィルタリング機能はないが、ＦＬＵＴＥで転送制御するファイルをそのファイルに紐づけられるメタデータを利用して、クライアント側で取捨選択することにより、選択的なフィルタリングを実現し、ユーザの嗜好を反映したローカルキャッシュを構成・更新管理することが可能となる。
なお、メタデータは、ＦＬＵＴＥプロトコルに拡張して組み込むこともできるし、別途ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）等のプロトコルで記述することもできる。

なお、ＦＬＵＴＥは、当初マルチキャストにおけるファイル転送プロトコルとして仕様化された。ＦＬＵＴＥは、ＦＤＴと、ＡＬＣと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコル、具体的にはそのビルディングブロックであるＬＣＴやＦＥＣコンポーネント、の組み合わせにより構成される。

従来のＦＬＵＴＥは、主に非同期型のファイル転送に利用するために開発されたが、現在、放送波およびネットワークを介したデータ配信システムに関する規格化団体であるＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍ Ｃｏｍｍｉｔｔｅ）において、ブロードキャストライブストリーミングにも適用しやすくするための拡張を行っている。このＦＬＵＴＥの拡張仕様がＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）と呼ばれる。

放送波およびネットワークを介したデータ配信システムに関する規格の１つとして現在、標準化が進められている規格としてＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍ Ｃｏｍｍｉｔｔｅ）３．０がある。このＡＴＳＣ３．０は、ＲＯＵＴＥを従来のＦＬＵＴＥプロトコルに置き換えて、シグナリングデータや、ＥＳＧ、あるいは非同期ファイル、同期型ストリーム等の送信に採用したスタック構成を規定している。

［３．送信装置と受信装置の実行する通信処理例について］
次に、送信装置と受信装置の実行する通信処理例について説明する。
図３は、送信装置および受信装置のプロトコルスタックの例を示す図である。
図３に示す例は、以下の２つの通信データの処理を行なうための２つのプロトコルスタックを有する。
（ａ）ブロードキャスト（マルチキャストも含む）通信（例えば放送型データ配信）
（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のクライアントサーバ型通信）

図３の左側が（ａ）ブロードキャスト通信（例えば放送型データ配信）に対応するプロトコルスタックである。
図３の右側が、（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のクライアントサーバ型通信）に対応するプロトコルスタックである。

図３左側に示す（ａ）ブロードキャスト通信（例えば放送型データ配信）に対応するプロトコルスタックは、下位レイヤから順に、以下のレイヤを持つ。
（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ ＰＨＹ）
（２）ＩＰマルチキャストレイヤ（ＩＰ Ｍｕｌｔｉｃａｓｔ）
（３）ＵＤＰレイヤ
（４）ＲＯＵＴＥ（＝拡張型ＦＬＵＴＥ）レイヤ
（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣ
（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５））

なお、（２）ＩＰマルチキャストレイヤ（ＩＰ Ｍｕｌｔｉｃａｓｔ）の上位レイヤとしてＳｉｇｎａｌｉｎｇ（シグナリング）レイヤが設定される。
シグナリングレイヤは、先に図２を参照して説明したシグナリングデータ５０の送受信に適用されるレイヤである。シグナリングデータには、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、制御情報などが含まれる。
なお、（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ ＰＨＹ）の上位レイヤとして将来の新たなプロトコルの利用許容レイヤ（Ｆｕｔｕｒｅ Ｅｘｔｅｎｓｉｂｉｌｉｔｙ）が設定されている。

（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ ＰＨＹ）は、ブロードキャスト通信を実行するための例えば放送系の通信部を制御する通信制御部によって構成される物理レイヤである。
（２）ＩＰマルチキャストレイヤ（ＩＰ Ｍｕｌｔｉｃａｓｔ）は、ＩＰマルチキャストに従ったデータ送受信処理を実行するレイヤである。
（３）ＵＤＰレイヤは、ＵＤＰパケットの生成、解析処理レイヤである。

（４）ＲＯＵＴＥレイヤは、拡張型ＦＬＵＴＥプロトコルであるＲＯＵＴＥプロトコルにしたがって転送データの格納や取り出しを行うレイヤである。
ＲＯＵＴＥは、ＦＬＵＴＥと同様、ＡＬＣと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコルであり、具体的にはそのビルディングブロックであるＬＣＴやＦＥＣコンポーネントの組み合わせにより構成される。

（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＲＯＵＴＥプロトコルに従って転送されるデータである。

ＤＡＳＨ規格に従った同報型配信サービスは、ＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）と呼ばれる。このＭＢＭＳをＬＴＥで効率的に実現させる方式としてｅＭＢＭＳ（ｅｖｏｌｖｅｄ Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）がある。
ＭＢＭＳやｅＭＢＭＳは、同報型配信サービスであり、特定のエリア内に位置する受信装置である複数のユーザ端末（ＵＥ）に対して共通のベアラで一斉に同一データ、例えば映画コンテンツなどを配信するサービスである。ＭＢＭＳやｅＭＢＭＳに従った同報配信により、配信サービス提供エリアに位置する多数のスマホやＰＣ、あるいはテレビ等の受信装置に、同じコンテンツを同時に提供することができる。

ＭＢＭＳ、およびｅＭＢＭＳは、３ＧＰＰファイルフォーマット（ＩＳＯ−ＢＭＦＦファイル、ＭＰ４ファイル）に従ったファイルを、転送プロトコルＲＯＵＴＥ、またはＦＬＵＴＥに従ってダウンロードする処理について規定している。

先に図２を参照して説明した以下のデータ、すなわち、
（ａ）シグナリングデータ５０
（ｂ）ＡＶセグメント６０
（ｃ）その他のデータ（ＥＳＧ、ＮＴＲコンテンツ等）７０
これらのデータの多くはＲＯＵＴＥプロトコル、またはＦＬＵＴＥプロトコルに従って送信される。

（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＲＯＵＴＥプロトコルに従って転送されるデータである。

ＥＳＧは、電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）であり、例えば番組表等の案内情報である。

ＮＲＴｃｏｎｔｅｎｔはノンリアルタイム型のコンテンツである。
前述したように、ＮＲＴコンテンツには、例えば、クライアントである受信装置のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。さらに、後述するアプリケーション等の制御プログラムとして利用されるサービスワーカー（Ｓｅｒｖｉｃｅ Ｗｏｒｋｅｒ（ＳＷ））も、ＮＲＴコンテンツに含まれる。
Ｖｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＤＡＳＨ規格に従って配信されるビデオやオーディオ等、再生対象となる実データである。

（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５））は、ＲＯＵＴＥプロトコルに従って転送するデータの生成、あるいは解析、その他、様々なデータの出力制御等を実行するアプリケーションレイヤであり、例えばＨＴＭＬ５を適用したデータ生成、解析、出力処理等を行う。

一方、図３の右側に示す、（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）に対応するプロトコルスタックは、下位レイヤから順に、以下のレイヤを持つ。
（１）ブロードバンド物理レイヤ（Ｂｒｏａｂａｎｄ ＰＨＹ）
（２）ＩＰユニキャストレイヤ（ＩＰ Ｕｎｉｃａｓｔ）
（３）ＴＣＰレイヤ
（４）ＨＴＴＰレイヤ
（５）ＥＳＧ，Ｓｉｇｎａｌｉｎｇ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣ
（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５））

（１）ブロードバンド物理レイヤ（Ｂｒｏａｂａｎｄ ＰＨＹ）は、ブロードバンド通信を実行する例えばネットワークカード等の通信部を制御するデバイスドライバ等の通信制御部によって構成される物理レイヤである。
（２）ＩＰユニキャストレイヤ（ＩＰ Ｕｎｉｃａｓｔ）は、ＩＰユニキャスト送受信処理を実行するレイヤである。
（３）ＨＴＴＰレイヤは、ＨＴＴＰパケットの生成、解析処理レイヤである。
この上位レイヤは、図３左側の（ａ）ブロードキャスト通信（例えば放送型データ配信）のスタック構成と同様である。

なお、送信装置（サーバ）２０、受信装置（クライアント）３０は、図３の２つの処理系、すなわち、
（ａ）ブロードキャスト通信（例えば放送型データ配信）
（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）
これら２つの通信プロトコルスタックの少なくともいずれかに従った処理を行なう。

図３に示すプロトコルスタックにおいて、ＲＯＵＴＥ（ＦＬＵＴＥ）に従ってマルチキャスト転送されるファイル群の属性（ファイルの識別子であるＵＲＬを含む）は、ＲＯＵＴＥ（ＦＬＵＴＥ）の制御ファイル内に記述することもできれば、ファイル転送セッションを記述するシグナリング（Ｓｉｇｎａｌｉｎｇ）データ中に記述することもできる。また、ファイル転送セッションのさらなる詳細属性を（エンドユーザへの提示用途にも適用可能な）ＥＳＧにより記述することもできる。

［４．サービスワーカー（ＳＷ）について］
次に、送信装置（サーバ）２０が提供し、主に受信装置（クライアント）３０において利用されるサービスワーカー（ＳＷ：Ｓｅｒｖｉｃｅ Ｗｏｒｋｅｒ）について説明する。
サービスワーカー（ＳＷ）は、放送サーバ２１や、データ配信サーバ２２等の送信装置２０から受信装置に提供される。

サービスワーカー（ＳＷ）は、受信装置（クライアント）３０において実行されるアプリケーション（＝アプリケーションプログラム）や、アプリケーションの実行時に利用されるデータファイル等の取得処理や、記憶部（キャッシュ）に対する格納処理、さらに更新処理、削除処理等を実行するプログラムである。具体的には、例えばＪａｖａＳｃｒｉｐｔ（登録商標）によって構成される。

サービスワーカー（ＳＷ）は、例えば放送サーバ２１や、データ配信サーバ２２等の送信装置２０が提供する放送番組（放送コンテンツ）に対応して設定され、送信装置２０から受信装置３０に提供されるアプリケーションの制御および管理プログラムとして、受信装置３０に提供される。

サービスワーカー（ＳＷ）、アプリケーション、およびアプリケーションの実行時に利用されるデータファイル、これらは、例えば先に図２、図３を参照して説明したＮＲＴコンテンツ（ノンリアルタイムコンテンツ）として、送信装置２０から受信装置３０に提供される。
あるいは、放送番組を配信するサーバとは別のデータ提供サーバが、サービスワーカー（ＳＷ）、アプリケーション、およびアプリケーションの実行時に利用されるデータファイルを受信装置３０に提供する構成としてもよい。

サービスワーカー（ＳＷ）は、例えば、受信装置３０においてＷｅｂページ等の閲覧処理を実行するために利用されるプログラムであるブラウザを利用して情報表示を実行するアプリケーションのリソース管理（取得、保持、更新、削除等）処理などを実行する。

サービスワーカー（ＳＷ）を利用した処理の具体例（ユースケース）について、図４、図５を参照して説明する。
図４は、受信装置３０が、放送サーバ２１等の送信装置２０から、ある番組コンテンツを受信し、受信装置３０の表示部に表示している状態を示している。

放送サーバ２１等の送信装置２０は、番組配信に併せて、ＮＲＴコンテンツ（ノンリアルタイムコンテンツ）として、天気情報を表示するアプリケーション、およびこの天気情報表示アプリケーションに利用される様々なデータファイル、例えば動画、静止画、音声等の様々なデータを含むデータファイルを受信装置３０に提供する。
以下では、これらのアプリケーションおよびデータファイルを「リソース」と呼ぶ。
放送サーバ２１は、さらに、これらの「リソース」を管理するリソース管理プログラムとして、サービスワーカー（ＳＷ）を、やはりＮＲＴコンテンツ（ノンリアルタイムコンテンツ）として受信装置３０に提供する。

受信装置３０は、送信装置２０から受信した「リソース」、すなわちアプリケーションおよびデータファイルを利用して、図４に示すように、番組表示に併せて、天気情報の表示を行うことができる。
このような、アプリケーションを利用したデータ表示は、これまでのデータ配信構成では、アプリケーションの提供される番組の終了とともに実行できなくなってしまう。

これは、天気情報表示アプリケーション等のリソースは、番組受信中は、受信装置３０において利用可能な設定、例えば、一時記憶キャッシュに格納され、利用可能な状態に設定されるが、番組終了、あるいはユーザがチャンネルを切り替えると、これらのキャッシュデータが消去、あるいはアクセス不可能な状態に設定されてしまうためである。

サービスワーカー（ＳＷ）は、このような番組対応のアプリケーションやデータを、番組終了後や、チャンネル切り替え後、あるいは放送の非受信状態、ネットワーク非接続状態等のオフライン状態であっても利用可能とするためのリソース管理プログラムとして機能する。

図５に示すように、天気情報表示アプリケーションを、このアプリを提供した番組の終了後や、他のチャンネルに切り替え後、あるいはデータ受信を実行していないオフライン状態であっても、利用することが可能となる。すなわち天気情報を受信装置３０の表示部に表示して閲覧することが可能となる。
なお、天気情報表示アプリケーションは、例えばブラウザ上で表示されるプログラムである。

この天気情報表示アプリケーションは、サービスワーカー（ＳＷ）の制御によって、受信装置３０の記憶部（永続キャッシュ）に格納される。例えばユーザによる表示要求等のリクエスト（イベント）があると、サービスワーカー（ＳＷ）の制御によって、の記憶部（永続キャッシュ）から読み出され、表示部に表示される。
なお、アプリケーション等のリソースを格納する記憶部（永続キャッシュ）は、受信装置３０の電源がオフとなっても格納データが消去されない不揮発性メモリとすることが好ましい。
このように、サービスワーカー（ＳＷ）を利用することで、様々な番組対応アプリケーションを、番組の表示、非表示と無関係に利用することが可能となる。

なお、サービスワーカー（ＳＷ）は、例えばある番組対応のリソース（アプリケーション、およびアプリ関連データ）単位ごとに設定され、リソースに併せて、あるいはリソース送信に前後して送信装置２０から受信装置３０に提供される。
サービスワーカー（ＳＷ）は、各番組対応の設定とすることもできるが、複数番組を含む特定のチャンネル対応のリソースに対して、共通に利用可能としたサービスワーカー（ＳＷ）を設定することもできる。
サービスワーカー（ＳＷ）と、サービスワーカー（ＳＷ）によって管理されるリソース（アプリケーションおよびアプリ関連データ）は、受信装置３０の記憶部（永続キャッシュ）に格納される。

図６は、サービスワーカー（ＳＷ）を利用した処理の一例を説明する図である。
図６には、受信装置３０が送信装置２０からリソースとしてのＷｅｂページ（例えば図４、図５に示す天気情報表示ページ）を取得して受信装置３０の記憶部（永続キャッシュ）に格納して利用するシーケンスの一例を示している。
なお、Ｗｅｂページは、所定のＷｅｂページ表示アプリケーションと、表示用データによって構成されるリソースを利用して表示される。
図６には、受信装置内表示制御部９０の構成要素として表示処理部９１、サービスワーカー（ＳＷ）９２、キャッシュ（記憶部）９３を示している。

ステップＳ１０１〜Ｓ１０２は、受信装置３０による送信装置２０に対する初回アクセス処理によるリソース（Ｗｅｂページ）取得処理である。
これは、例えば放送サーバ等の送信するＮＲＴコンテンツから取得される。
この取得処理後、表示処理部９１によって、Ｗｅｂページ９５が、受信装置３０の表示部に表示される。この表示は、このＷｅｂページを提供している番組に併せて表示されている状態であり、先に図３を参照して説明した表示状態に相当する。

この表示期間において、例えばユーザによる指示としてリソース（Ｗｅｂページ）の登録（インストール）要求がなされると、ステップＳ１０３において、サービスワーカー（ＳＷ）９２が、リソース（Ｗｅｂページ）の登録（インストール）処理を開始する。
具体的には、ステップＳ１０４に示すようにリソースをキャッシュ９３に渡し、記憶部（永続キャッシュ）に格納する処理を行なう。

その後、番組終了後、あるいはチャンネル切り替え後、あるいはオフライン設定状態において、ステップＳ１０５において、ユーザがＷｅｂペーシの閲覧要求を行う。
サービスワーカー（ＳＷ）９２は、この閲覧要求の入力をフェッチイベントとして検出し、フェッチイベント検出に応じて、ステップＳ１０６において、リソース（Ｗｅｂページ）を記憶部（永続キャッシュ）から取得する。
表示処理部９１は、ステップＳ１０７において、Ｗｅｂページ９６を表示する。

このＷｅｂページ表示処理は、番組終了後、あるいはチャンネル切り替え後、あるいはオフライン設定状態における表示処理であり、先に図５を参照して説明した表示状態に相当する。

このように、サービスワーカー（ＳＷ）を利用することで、様々な番組対応アプリケーションを、番組の表示、非表示と無関係に利用することが可能となり、例えば、番組付属の表示情報として設定されたＷｅｂページを番組と無関係に、任意のタイミングで表示する等の処理が可能となる。

このように、サービスワーカー（ＳＷ）は、例えば、Ｗｅｂページ、ＨＴＭＬページ、ＪａｖａＳｃｒｉｐｔ（登録商標）等を構成要素としたアプリケーションや、アプリケーションに利用されるデータ等からなるリソースの取得、保存、更新、削除等の、リソース管理を実行する。

リソースの保存、あるいはキャッシュは、永続的なキャッシュであり、通常のローカル／テンポラリなキャッシュとは異なり、アプリケーションが稼働していなくても、データが保存される。
Ｗｅｂページ表示プログラムであるブラウザに一種のプロキシサーバが実装され、いつでも、必要なときにプロキシサーバ（永続キャッシュ）をアクセスしてＷｅｂページを取得して表示可能としたイメージである。

なお、サービスワーカー（ＳＷ）自身も永続キャッシュに格納（インストール）される。サービスワーカー（ＳＷ）が、受信装置にインストールされると、このサービスワーカー（ＳＷ）の管理対象とするリソースについて、様々な制御が可能となる。
例えば、リソースへのアクセスリクエスト（リソースへのフェッチリクエスト）に応じて、ブラウザ側の処理（ローカルキャッシュやネットワークからのリソースの取得）がはじまる前に、サービスワーカー（ＳＷ）の処理が開始され、永続キャッシュからのリソースの提供が行われる。
また、サービスワーカー（ＳＷ）は、ＪａｖａＳｃｉｒｐｔ（登録商標）で提供されるため、さまざまな手続きを組み込むことが可能であり、永続キャッシュのリソースの一部の更新等キャッシュ制御についての柔軟な処理記述が可能となっている。

なお、サービスワーカー（ＳＷ）自身も更新可能である。サービスワーカー（ＳＷ）は、送信装置２０から提供されるが、このサービスワーカー（ＳＷ）のヘッダ情報（ＨＴＴＰ Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ）に更新日時情報や更新データのアクセス情報等、更新処理に必要となる各種情報が記録され、このヘッダ情報に基づいて更新処理が実行される。
例えば、ヘッダに設定された使用期限等に基づいて、使用期限が来ると、受信装置３０は、新しいバージョンのサービスワーカ（ＳＷ）の取得処理を実行して、キャッシュに格納された旧バージョンのＳＷを置き換える更新処理を行なう。

［５．放送波とネットワーク双方の受信データの合成処理について］
受信装置３０は、送信装置である放送サーバ２１から放送波を介して番組コンテンツを受信し、さらに、データ配信サーバ２２からネットワークを介して様々なコンテンツを受信することが可能である。受信装置３０は、これらの２つの通信経路を併用して、２つの通信経路から受信したデータを合成して表示することができる。

例えば、受信装置において実行するアプリケーション、例えば上述したサービスワーカー（ＳＷ）の管理アプリケーション等、受信装置３０において実行されるアプリケーションを適用して、２つの通信経路から受信したデータを合成する処理を実行させることが可能となる。

例えば、アプリケーションは、
（ａ）放送波を介して受信する番組コンテンツ
（ｂ）ネットワークを介して受信する広告コンテンツ
これらの２つのデータを合成して表示する処理を行なう。

具体的な処理例について図７、図８を参照して説明する。
図７には、受信装置（クライアント）３０の表示部に表示されるデータの時間経過に伴う推移を示している。
（１）時間ｔ０〜ｔ１では、放送波を介して受信する番組コンテンツを表示している。
（２）時間ｔ１〜ｔ２では、放送波を介して受信する番組コンテンツに、ネットワークを介して受信する広告コンテンツを重畳して表示している。
（３）時間ｔ２〜ｔ３では、放送波を介して受信する番組コンテンツを表示している。

（２）の時間ｔ１〜ｔ２においてネットワークを介して受信する広告コンテンツは、例えば特定の地域や特定のユーザを対象とした広告コンテンツ（ターゲット広告）としてユーザに提供することができる。
受信装置３０が、（２）の時間ｔ１〜ｔ２においてネットワークを介して受信する広告コンテンツは、受信装置３０においてアプリケーションを実行している場合に受信可能なコンテンツとなる。
アプリケーションを実行していない受信装置では、放送波を介して受信するデータのみが表示される。

図７に示す構成は、時間ｔ１〜ｔ２において、放送波の受信データにネットワーク受信データを併せて表示（並列表示）する例である。この場合は、広告コンテンツを番組コンテンツに重畳し再生するために複数の映像復号化装置が必要である。
この他、受信装置３０のアプリケーションの処理態様としては、２つの受信データの並列表示ではなく、放送波を介する受信データの一部期間のデータを、ネットワーク受信データに完全に置き換えて出力する処理も可能である。この場合は、一つの映像復号化装置にて再生可能である。
この置換表示例を図８に示す。

（１）時間ｔ０〜ｔ１では、放送波を介して受信する番組コンテンツを表示している。
（２）時間ｔ１〜ｔ２では、ネットワークを介して受信する広告コンテンツを表示している。
（３）時間ｔ２〜ｔ３では、放送波を介して受信する番組コンテンツを表示している。

（２）の時間ｔ１〜ｔ２においてネットワークを介して受信する広告コンテンツは、例えば特定の地域や特定のユーザを対象とした広告コンテンツ（ターゲット広告）としてユーザに提供することができる。
受信装置３０が、（２）の時間ｔ１〜ｔ２においてネットワークを介して受信する広告コンテンツは、受信装置３０がアプリケーションを実行している場合において受信可能なコンテンツとなる。
アプリケーションを実行していない受信装置では、時間ｔ１〜ｔ２の間に、放送波を介して受信する不特定多数向けの広告コンテンツを受信して表示する設定とすることができる。

このように、アプリケーションの処理によって、放送受信データとネットワーク受信データとの合成表示処理が実行できる。
しかし、この、放送受信データとネットワーク受信データの合成処理の処理時間が長くなると、再生遅延を発生させてしまう場合がある。
特に、例えば図８に示すように、放送受信データをネットワーク受信データに置き換えて表示する場合、合成処理に時間を要すると、図８に示す時間ｔ１において、広告表示が実行されず、画像が途切れてしまうとっいた事態が発生する可能性がある。
以下、この問題点について説明する。

この問題点の説明の前に、ネットワーク状況に応じてクライアント側で最適なビットレートのセグメントを選択して再生するアダプティブ（適応型）ストリーミング処理について説明する。
前述したように、ネットワークを介したデータ送信においては、ネットワークの輻輳等により、一定のビットレートでのデータ受信が困難となる場合がある。
このような問題を解決するため、複数のビットレートのデータの細分化ファイルであるセグメントをネットワーク上に送信し、ネットワーク状況に応じてクライアント側で最適なビットレートのセグメントを選択して再生するアダプティブ（適応型）ストリーミングが提案されている。

受信装置３０は、ネットワーク受信データに限らず、放送受信データについてもネットワーク状況や、地震の表示装置の解像度情報に応じて最適なビットレートのデータを選択取得して出力可能な構成を持つ。
なお、受信装置３０は、どのようなビットレートのデータが送信されるかについての情報を、送信装置２０が提供するマニフェストファイルに基づいて取得することができる。

図９は、アダプティブ（適応型）ストリーミングについて説明する図である。
データ配信サーバ２２は、配信データとして、例えばライブ映像からなるコンテンツを配信する場合、予め複数の異なるビットレートのデータを用意する。
図に示す例では、
高ビットレート（２Ｍｂｐｓ）データ１０１、
中ビットレート（１．５Ｍｂｐｓ）データ１０２、
低ビットレート（１Ｍｂｐｓ）データ１０３、
これらのデータを配信データとする。

これらのデータは細分化されたデータであるセグメント単位でネットワークを介して受信装置３０に提供される。Ａ１〜Ａｎ，Ｂ１〜Ｂｎ，Ｃ１〜Ｃｎの各々がセグメントデータである。
Ａ１，Ｂ１，Ｃ１はすべて同一シーンのデータであり、ビットレートが異なるデータ（セグメント）として構成されている。
各セグメントは、１つのセグメント単位で復号可能なデータ、たとえばＭＰ４ファイルを含むセグメントである。
さらに、セグメントの属性情報やＵＲＬを記述したマニフェスト・ファイル１０４を、ネットワークを介して受信装置３０に提供する。

受信装置（クライアント）３０は、マニフェスト・ファイル１０４をサーバから取得して、自装置の表示部のサイズや利用可能な通信帯域に応じた最適なビットレートデータ（セグメント）を選択し、選択データを受信して再生する。ネットワーク帯域の変動に応じてビットレートの動的な変更も可能であり、クライアント側では、状況に応じた最適なデータを随時切り替えて受信することが可能となり、映像途切れの発生を低減した動画コンテンツ再生が実現される。
図に示す再生データ１０５が受信装置３０における再生データであり、様々なビットレートのデータ（セグメント）が混在して再生される。
例えば、図７、図８を参照して説明した広告コンテンツもこのようなセグメントデータの組み合わせによって構成される。

図１０は、アダプティブ（適応型）ストリーミングに従って、様々なビットレートのセグメントを受信して再生する受信装置３０の処理構成例を示す図である。
図１０に示す構成は、例えば受信装置３０において実行されるブラウザによって利用されるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）として実装可能なＭＳＥ（Ｍｅｄｉａ Ｓｏｕｒｃｅ Ｅｘｔｅｎｔｉｏｎｓ）−ＡＰＩの処理構成である。

メディアソース１１０は、例えば外部サーバから受信する再生対象データを示すオブジェクトである。このオブジェクトには、複数のビットレートのセグメントデータが含まれる。
なお、オブジェクトとは、アプリケーションによる処理やアクセスが可能な要素を意味し、受信装置３０の受信するデータや、記憶部に格納されるデータ、あるいは受信装置の記憶部や通信部等のハードウェアがオブジェクトに設定可能な要素となる。
メディアソース１１０は、例えば受信装置３０の記憶部に格納されたビデオや音声データに相当する。

ＭＳＥ−ＡＰＩは、メディアソース１１０をそれぞれのビットレートのデータ（セグメント）単位で振り分け、個別のソースバッファ１１１〜１１３を設定する。
これら個別のソースバッファ１１１〜１１３は、メディアソース１１０の構成要素であり、いずれもアプリケーションによる処理対象となるオブジェクトである。
ソースバッファ１１１は、ビデオデータと２ｃｈオーディオデータの各セグメントを含むデータのソースバッファである。
ソースバッファ１１２は、ビデオデータのみ、ソースバッファ１１３はオーディオデータのみを格納するソースバッファである。

これらの各データは、それぞれ再生時間を同期させたトラックバッファ１１４に振り分けられ、ビデオ、オーディオ個別のデコーダ１１５においてデコード処理がなされた後、画像出力部１１７、音声出力部１１６に出力される。
なお、画像出力部１１７には、いずれか１つのビデオデコード結果が出力され、音声出力部１１６にはいずれか１つのオーディオデコード結果が出力される。
どのデコード結果、すなわちどのビットレートデータを選択して出力するかは、受信装置（クライアント）３０側において、ネットワーク状況や受信装置の出力部機能等に応じて決定することができる。

このように、受信装置は、ネットワークを介して受信する様々なビットレートのデータを適宜、選択して出力することが可能となる。
しかし、このようなアプリケーションがＭＳＥ ＡＰＩを利用してネットワーク受信データを放送波に合成して出力する処理に時間を要すると合成画像の出力に遅延が発生する場合がある。

遅延の具体的要因としては、例えば以下のような要因があると考えられる。
（Ａ）ライブ放送での再生遅延の要因
合成処理を実行するアプリケーションは、放送波によって送信される放送ストリームを、ＸＨＲ（ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ）によってセグメント単位で読み込む。読み込みセグメントは、図１０を参照して説明したネットワーク経由の受信セグメントの格納領域を想定したオブジォェクトとしてのソースバッファに追加（Ａｐｐｅｎｄ）する。この一連の処理により遅延が生じる。

（Ｂ）番組切り替え時、チャンネル切り替え時における遅延
合成処理を実行するアプリケーションは、番組単位、あるいはチャンネル単位で設定されており、番組切り替え時、チャンネル切り替え時にはアプリケーションも切り替える必要がある。この切り替え処理によって遅延が発生し、また、連続して再生できなく映像が静止したり黒画像が挿入される問題がある。

このように、アプリケーションがネットワーク受信データを放送波に合成して出力する場合は上記のような問題がある。
図１１を参照して、放送波とネットワークを介する２つの経路の受信データを合成して出力する処理と、遅延要因について説明する。
なお、以下では、放送波の受信データの一部をネットワーク受信データに置き換えて出力する場合の処理例について説明する。すなわち、図８を参照して説明したように、放送受信データの一部期間のデータをネットワーク受信データに置き換えて出力する処理例について説明する。

図１１は、受信装置（クライアント）３０における合成処理、すなわち放送受信データの一部を、ネットワーク受信データに置き換えて出力する処理を説明する図である。
受信装置（クライアント）３０は、放送サーバ２１からの放送波を、アンテナ１３１を介して受信する。
さらに、データ配信サーバ２２からデータ受信を行う。

アンテナ１３１を介して受信するデータを放送受信セグメント１２５、
データ配信サーバ２２からの受信データをネットワーク受信セグメント１２６とする。
放送受信セグメント１２５は、例えば映画等の番組コンテンツであり、ネットワーク受信セグメント１２６は、番組コンテンツの決められたタイミングに表示する広告コンテンツであるとする。

図に示す例では、放送受信セグメント１２５の一部セグメントａ，ｂ，ｃ，ｄ，ｅ，ｆの６つのセグメントを示している。
一方、ネットワーク受信セグメント１２６として（ｃ），（ｄ）の２つのセグメントを示している。
なお、各セグメントは、各セグメント単位で復号可能な例えばＭＰＥＧ圧縮されたデータ（ＭＰ４データ）である。
データの置き換えはセグメント単位で実行する。

ネットワーク受信セグメントである２つの広告セグメント（ｃ），（ｄ）を、放送受信セグメント１２５のセグメントａ，ｂ，ｃ，ｄ，ｅ，ｆ中のセグメントｃ，ｄに置き換えて出力する。
すなわち、受信装置３０における出力コンテンツを以下のセグメント列とする。
ａ，ｂ，（ｃ），（ｄ），ｅ，ｆ
上記セグメント列中、セグメントａ，ｂ，ｅ，ｆは、放送受信セグメントであり、セグメント（ｃ），（ｄ）は、ネットワーク受信セグメントである。

受信装置３０は、ブラウザ（ＨＴＭＬ５ブラウザ）１４０を有し、ブラウザ１４０上でアプリケーション（Ｗｅｂ ａｐｐｌｉｃａｔｉｏｎ（ＪａｖａＳｃｒｉｐｔ（登録商標））１４２を実行する。
アプリケーション１４２は、例えばＡＰＩ（先に説明した図１０に示すＭＳＥ−ＡＰＩ）等を利用した処理により、放送受信セグメント１２５と、ネットワーク受信セグメント１２６との合成処理を行なう、

放送受信セグメント１２５は、受信装置に設定されるプロキシサーバとしてのＨＴＴＰサーバ１３３に一旦、格納される。
ＨＴＴＰサーバ１３３にデータを格納することで、アプリケーション１４２は、ＨＴＴＰサーバ１３３から、ＸＨＲ（ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ）１４１を適用してセグメント単位のデータ読み込みを行うことが可能となる。

アプリケーション１４２は、ＨＴＴＰサーバ１３３に格納された放送受信セグメント１２５を、ＸＨＲ（ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ）１４１によってセグメント単位で読み込む。
アプリケーション１４２によるセグメント読み込みにおいて、ネットワーク受信セグメント（ｃ），（ｄ）によって置き換え対象となる放送受信セグメントｃ，ｄは読み込まず、出力対象となる放送受信セグメントａ，ｂ，ｅ，ｆのみの読み込み処理を行なう。

その後、アプリケーション１４２は、読み込んだ放送受信セグメントａ，ｂ，ｅ，ｆと、データ配信サーバ２２から受信した放送受信セグメント（ｃ），（ｄ）を合成する。
アプリケーション１４２は、先に図８を参照して説明した放送波として受信する番組コンテンツを非表示として、ネットワークを介して受信する広告コンテンツを番組コンテンツに置き換えたセグメント列、すなわち、
ａ，ｂ，（ｃ），（ｄ），ｅ，ｆ
上記セグメント列を生成する。

アプリケーション１４２は、放送受信セグメント１２５の一部のセグメントをネットワーク受信セグメント１２６に置き換えたセグメント列、
ａ，ｂ，（ｃ），（ｄ），ｅ，ｆ
上記セグメント列からなるメディアソース１４３の生成処理を実行する。
このメディアソース１４３は、図１０に示すメディアソース１１０に相当する。
なお、図１０に示す例では、メディアソース１１０には様々なビットレートのデータが混在するものとして説明したが、図１１に示す例では、説明を簡略化するため、すでに出力予定の１つのビットレートが決定されており、そのビットレートのセグメントに対する処理を行うものとして説明する。

このように、アプリケーション１４２は、放送受信セグメント１２５の一部のセグメントをネットワーク受信セグメント１２６に置き換えたメディアソース１４３の生成処理を実行する。
その後、メディアソース１４３は、データの種類に応じて振り分けられ、画像対応ソースバッファ１４４と、音声対応ソースバッファ１４５が生成される。

画像対応ソースバッファ１４４は、画像デコーダ１３４によってデコードされ、画像表示部１３５に表示される。
音声対応ソースバッファ１４５は、音声デコーダ１３６によってデコードされ、音声出力部１３７に出力される。
この結果として再生されるセグメントが図に示す再生セグメント１２７であり、放送受信セグメント１２５の一部のセグメントがネットワーク受信セグメント１２６に置き換えて再生される。
例えば図８に示す時間ｔ０〜ｔ３の一連のデータ表示が実行される。

図１１を参照して説明したアプリケーション１４２によって実行される放送受信セグメント１２５とネットワーク受信セグメント１２６との合成処理は、先に図１０を参照して説明したＭＳＥ（Ｍｅｄｉａ Ｓｏｕｒｃｅ Ｅｘｔｅｎｔｉｏｎｓ）−ＡＰＩを利用して実行される。
このＡＰＩの処理アルゴリズムは例えば、以下のアルゴリズムとなる。
＜ｓｃｒｉｐｔ＞
ｖａｒ ｖｉｄｅｏ＝ｄｏｃｕｍｅｎｔ．ｇｅｔＥｌｅｍｅｎｔＢｙＩｄ（'ｖ'）；
ｖａｒ ｍｅｄｉａＳｏｕｒｃｅ＝ｎｅｗ ＭｅｄｉａＳｏｕｒｃｅ（）；
ｍｅｄｉａＳｏｕｒｃｅ．ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒ（'ｓｏｕｒｃｅｏｐｅｎ'，ｏｎＳｏｕｒｃｅＯｐｅｎ．ｂｉｎｄ（ｔｈｉｓ， ｖｉｄｅｏ））；
ｖｉｄｅｏ．ｓｒｃ＝ｗｉｎｄｏｗ．ＵＲＬ．ｃｒｅａｔｅＯｂｊｅｃｔＵＲＬ（ｍｅｄｉａＳｏｕｒｃｅ）；
ｖａｒ ｖｉｄｅｏＳｏｕｒｃｅＢｕｆｆｅｒ＝ｍｅｄｉａＳｏｕｒｃｅ．ａｄｄＳｏｕｒｃｅＢｕｆｆｅｒ（'ｖｉｄｅｏ／ｍｐ４；ｃｏｄｅｃｓ＝"ａｖｃ１．４ｄ４０１ｆ"'）；
ｖａｒ ａｕｄｉｏＳｏｕｒｃｅＢｕｆｆｅｒ＝ｍｅｄｉａＳｏｕｒｃｅ．ａｄｄＳｏｕｒｃｅＢｕｆｆｅｒ（'ａｕｄｉｏ／ｍｐ４；ｃｏｄｅｃｓ＝"ｍｐ４ａ．４０．２"'）
＜／ｓｃｒｉｐｔ＞

上記のＡＰＩの処理の概要は以下の通りである。
（Ｓ１）新規のメディアソース１４３を作成する。
（Ｓ２）メディアソース１４３対応のビデオソースバッファ１４４と、オーディオソースバッファ１４５を追加し、ＨＴＭＬ５のビデオオブジェクトにメディアバッファを設定する。
アプリケーション１４２は、これらのＡＰＩ処理によって生成されたメディアソース１４３、ビデオソースバッファ１４４、オーディオソースバッファ１４５に上述した合成セグメントを設定する処理を行なう。

しかし、図１１を参照して説明したセグメント合成処理において、問題となるのが再生遅延である。具体的には、例えばネットワーク受信コンテンツの表示タイミングが、規定の時間より遅れてしまう場合があるということである。特にライブイベントの番組コンテンツやチャンネル切り替え場合にこの遅延の問題が大きい。
これは、図１１を参照して説明した一連の合成処理に時間を要してしまうということが大きな要因である。

特に、以下の処理の処理時間が遅延の要因として考えられる。
（ａ）放送受信セグメント１２５のＨＴＴＰサーバ１３３に対する格納と、アプリケーション１４２によるＨＴＴＰサーバ１３３からのセグメント単位の読み込み処理
（ｂ）アプリケーション１４２によるメディアソース１４３へセグメントデータの置き換えや追加する処理、
これらの一連の処理が遅延を発生させる大きな要因であると考えられる。

（ａ）の処理は、前述したように、放送受信セグメント１２５は、ＨＴＴＰサーバ１３３に一旦、格納され、その後、アプリケーション１４２が、ＨＴＴＰサーバ１３３に格納された放送受信セグメント１２５を、ＸＨＲ（ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ）１４１によってセグメント単位で読み込む処理である。
（ｂ）の処理は、アプリケーション１４２が、放送受信セグメント１２５の一部のセグメントをネットワーク受信セグメント１２６に置き換えてメディアソース１４３を生成する処理である。
これらの処理には、所定の時間を要するため、再生遅延が避けられない状況となっていると考えられる。
さらに、アプリケーション１４２は、番組切り替えやチャンネル切り替え時に切り替えることが必要となる場合が多く、このアプリケーション切り替え処理時間も、さらに遅延を大きくする要因となる。ＨＴＴＰサーバ１３３の代わりに、ＷｅｂＳｏｃｋｅｔサーバを利用して、アプリケーション１２５がＷｅｂ Ｓｏｃｋｅｔ ＡＰＩによってプッシュ型のデータ送受信をすることで遅延を低減する方法も考えられるが、最低でも一つのセグメントを受信して、送信するという処理に要する時間は低減することができない。

［６．放送波とネットワーク双方の受信データの合成処理における遅延を解消または減少させた実施例について］
次に、放送波とネットワーク双方の受信データの合成処理における遅延を解消または減少させた実施例について説明する。

図１２は、本開示の受信装置（クライアント）３０における合成処理、すなわち放送波の受信データの一部を、ネットワーク受信データに置き換えて出力する処理を説明する図である。
なお、図１２に示す処理も図１１と同様、放送波の受信データの一部をネットワーク受信データに置き換えて出力する場合の処理、すなわち、図８を参照して説明したデータ置き換え処理を行なう場合の処理例である。

受信装置（クライアント）３０は、放送サーバ２１からの放送波を、アンテナ１３１を介して受信する。
さらに、データ配信サーバ２２からデータ受信を行う。
アンテナ１３１を介して受信するデータを放送受信セグメント１２５、
データ配信サーバ２２からの受信データをネットワーク受信セグメント１２６とする。
放送波セグメント１２５は、例えば映画等の番組コンテンツであり、ネットワーク受信セグメント１２６は、番組コンテンツの決められたタイミングに表示する広告コンテンツであるとする。

図に示す例では、放送受信セグメント１２５の一部セグメントａ，ｂ，ｃ，ｄ，ｅ，ｆの６つのセグメントを示している。
一方、ネットワーク受信セグメント１２６として（ｃ），（ｄ）の２つのセグメントを示している。
なお、各セグメントは、各セグメント単位で復号可能な例えばＭＰＥＧ圧縮されたデータ（ＭＰ４データ）である。
データの置き換えはセグメント単位で実行する。

ネットワーク受信セグメントである２つの広告セグメント（ｃ），（ｄ）を、放送受信セグメント１２５のセグメントａ，ｂ，ｃ，ｄ，ｅ，ｆ中のセグメントｃ，ｄと置き換えて出力する。
すなわち、受信装置３０における出力コンテンツを以下のセグメント列とする。
ａ，ｂ，（ｃ），（ｄ），ｅ，ｆ
上記セグメント列中、セグメントａ，ｂ，ｅ，ｆは、放送受信セグメントであり、セグメント（ｃ），（ｄ）は、ネットワーク受信セグメントである。

受信装置３０は、ブラウザ（ＨＴＭＬ５ブラウザ）２１０を有し、ブラウザ２１０上でアプリケーション（Ｗｅｂ ａｐｐｌｉｃａｔｉｏｎ（ＪａｖａＳｃｒｉｐｔ（登録商標））２１２を実行する。
このアプリケーション２１２が放送受信セグメント１２５と、ネットワーク受信セグメント１２６との合成処理を行なう、

この図１２に示す構成では、放送受信セグメント１２５は、そのままメディアソース２１３として構成される。
先に図１１を参照して説明した構成では、放送受信セグメント１２５は、受信装置に設定されるプロキシサーバとしてのＨＴＴＰサーバ１３３に一旦、格納され、その後、アプリケーションによるサーバからのセグメント単位の読み出しが実行されていた。
この図１２に示す構成では、放送受信セグメント１２５に対するＨＴＴＰサーバに対する格納処理や読み出し処理が実行されず、放送受信セグメント１２５は、そのままメディアソース２１３として構成される。
この時点で、メディアソース２１３は、図に示すセグメント列（１）のように、放送受信セグメント、ａ，ｂ，ｃ，ｄ，ｅ，ｆによって構成される。つまり、放送受信セグメントはアプリケーション２１２が実行されているか否かに関わらず、画像デコーダ、音声デコーダに送られ、再生されている。

その後、アプリケーション２１２は放送波で伝送されたシグナリングにより放送の番組に連動して起動され、ネットワーク受信セグメント１２６であるセグメント（ｃ），（ｄ）のみを取得し、このネットワーク受信セグメント（ｃ），（ｄ）を、放送受信セグメント、ａ，ｂ，ｃ，ｄ，ｅ，ｆのみによって構成されたメディアソース２１３の一部のセグメントｃ，ｄと置き換える処理を実行する。

すなわち、アプリケーション２１２は、放送受信セグメント、ａ，ｂ，ｃ，ｄ，ｅ，ｆのみによって構成されたメディアソース（１）更新処理を実行して、更新されたメディアソース（２）、すなわち、
ａ，ｂ，（ｃ），（ｄ），ｅ，ｆ
上記セグメント列からなるメディアソース（２）となるように制御する。。

このように、アプリケーション２１２は、放送受信セグメント列のみからなるメディアソースの構成セグメントの一部をネットワーク受信セグメントに置き換えるメディアソース更新処理の制御を実行する。
この具体的処理については、後段で説明する。

その後、
ａ，ｂ，（ｃ），（ｄ），ｅ，ｆ
上記セグメント列を有するメディアソース（２）２１３は、データの種類に応じて振り分けられ、画像対応ソースバッファ２１４と、音声対応ソースバッファ２１５が生成される。

画像対応ソースバッファ２１４は、画像デコーダ２２１によってデコードされ、画像表示部２２２に表示される。
音声対応ソースバッファ２１５は、音声デコーダ２２３によってデコードされ、音声出力部２２４に出力される。
この結果として再生されるセグメントが図に示す再生セグメント２２５であり、放送受信セグメント１２５の一部のセグメントがネットワーク受信セグメント１２６に置き換えて再生される。
例えば図８に示す時間ｔ０〜ｔ３の一連のデータ表示が実行される。

図１２を参照して説明したアプリケーション２１２によって実行される放送受信セグメント１２５とネットワーク受信セグメント１２６との合成処理は、先に図１０を参照して説明したＭＳＥ（Ｍｅｄｉａ Ｓｏｕｒｃｅ Ｅｘｔｅｎｔｉｏｎｓ）−ＡＰＩをベースとして改良した新ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を利用して実行される。
この新ＡＰＩの処理アルゴリズムは例えば、以下のアルゴリズムとなる。
＜ｓｃｒｉｐｔ＞
ｖａｒ ｖｉｄｅｏ＝ｄｏｃｕｍｅｎｔ．ｇｅｔＥｌｅｍｅｎｔＢｙＩｄ（'ｖ'）；
ｖａｒ ｔｕｎｅｒ＝ｎａｖｉｇａｔｏｒ．ｔｖ．ｃｕｒｒｅｎｔＴｕｎｅｒ（）；
ｖａｒ ｍｅｄｉａＳｏｕｒｃｅ＝．ｔｕｎｅｒ．ｇｅｔＭｅｄｉａＳｏｕｒｃｅ（）；
ｍｅｄｉａＳｏｕｒｃｅ．ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒ（'ｓｏｕｒｃｅｏｐｅｎ'，ｏｎＳｏｕｒｃｅＯｐｅｎ．ｂｉｎｄ（ｔｈｉｓ，ｖｉｄｅｏ））；
ｖｉｄｅｏ．ｓｒｃ＝ｗｉｎｄｏｗ．ＵＲＬ．ｃｒｅａｔｅＯｂｊｅｃｔＵＲＬ（ｍｅｄｉａＳｏｕｒｃｅ）；
ｖａｒ ｖｉｄｅｏＳｏｕｒｃｅＢｕｆｆｅｒ＝ｍｅｄｉａＳｏｕｒｃｅ．ｓｏｕｒｃｅＢｕｆｆｅｒｓ［０］；
ｖａｒ ａｕｄｉｏＳｏｕｒｃｅＢｕｆｆｅｒ＝ｍｅｄｉａＳｏｏｒｃｅ．ｓｏｕｒｃｅＢｕｆｆｅｒｓ［１］；
＜／ｓｃｒｉｐｔ＞

上記の新ＡＰＩの処理の概要は以下の通りである。
（Ｓ１）通信部（チューナー）２０２受信セグメント格納用のメディアソース２１３を取得し、アプリケーション１４２による参照を可能な設定とする。
（Ｓ２）メディアソース２１３対応のビデオソースバッファ２１４と、オーディオソースバッファ２１５を取得し、アプリケーション１４２による参照を可能な設定とする。メディアソース２１３は、ＨＴＭＬ５のビデオオブジェクトに設定する。

アプリケーション１４２は、これらのＡＰＩ処理によって参照可能となったメディアソース２１２、ビデオソースバッファ２１４、オーディオソースバッファ２１５を参照して、これらのオブジェクトに格納されている通信部（チューナー）２０２受信セグメントに対して、ネットワーク受信セグメントによるセグメント置き換えの制御を実行する。

このように、アプリケーション１４２は、新ＡＰＩの処理によって参照可能となった放送受信セグメント用のメディアソースと、ソースバッファに対する放送受信セグメントのデータ格納状況を確認して、置き換え対象の放送受信セグメントがバッファに格納されていることを確認すると、広告コンテンツの再生コンテンツを挿入する時間位置の放送受信セグメントをネットワーク受信セグメントに置き換える処理を実行する。

図１２を参照して説明した処理例では、放送受信メディアセグメントはアプリケーションで処理されないため、先に図１１を参照して説明した再生遅延の要因が解消される。
すなわち、以下の処理の処理時間が不要となるため、処理遅延が解消される。
（ａ）放送受信セグメントのＨＴＴＰサーバに対する格納と、アプリケーションによるＨＴＴＰサーバからのセグメント単位の読み込み処理
（ｂ）アプリケーションによるメディアソースへの放送受信セグメントの置き換えや追加処理
図１２を参照して説明した処理例では、これらの一連の遅延発生要因となる処理が不要となり、この結果再生遅延を解消することができる。

図１２に示す処理構成では、放送受信セグメント１２５は、そのままメディアソース２１３として設定されるので、放送受信セグメント１２５のＨＴＴＰサーバへの格納処理や、アプリケーションによる読み込み処理が不要となる。また、アプリケーションによるメディアソースの生成処理も不要となる。
また、アプリケーションは、番組切り替えやチャンネル切り替え時に切り替えることが必要となるが、放送受信セグメントによって構成されるメディアソースは、アプリ切り替えと無関係に生成されるのでのアプリケーション切り替え処理時間によって、メディアソース生成の遅延や、アプリケーションの切り替え時に放送セグメントの再生が中断される問題は発生しない。

図１２に示すアプリケーション２１２の実行するメディアソース更新処理の詳細について、図１３を参照して明する。
図１３には、以下の３つのデータを時系列（左から右に時間が経過）に示している。
（Ａ）アプリケーション受信セグメント（ネットワーク受信セグメント）
（Ｂ）チューナー受信セグメント（放送受信セグメント）
（Ｃ）デコーダ入力セグメント（出力セグメント）

時間軸として、以下の２つの時間軸を示している。
下段に放送時間軸（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））
上段にＨＴＭＬ５ビデオオブジェクト時間軸（ＣｕｒｒｅｎｔＴｉｍｅ）

放送時間軸（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））は、放送サーバ２１が、放送波を介して送信するデータの時間管理に適用する時間を示す時間軸（受信映像音声再生時間軸）である。
ここでは、いわゆる実時間情報に相当するウォールクロック（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））を適用した例を示す。
放送波を介して受信する放送受信セグメントには、放送時間軸（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））に従ったタイムスタンプが設定されている。

一方、ＨＴＭＬ５ビデオ時間軸（ＣｕｒｒｅｎｔＴｉｍｅ）は、アプリケーション２１２の処理時間や、アプリケーション２１２による生成データの管理用の時間を規定したアプリケーション時間軸（アプリケーションメディア再生時間軸）である。
アプリケーション２１２は、ＨＴＭＬ５ビデオ時間軸（ＣｕｒｒｅｎｔＴｉｍｅ）に従って処理を実行する。
図１３において、ＨＴＭＬ５ビデオ時間軸（ＣｕｒｒｅｎｔＴｉｍｅ）上の各時間ｔ３ｈ〜ｔ５ｈは、ＨＴＭＬ５ビデオ時間軸（ＣｕｒｒｅｎｔＴｉｍｅ）上の時間であることを示すため（ｈ）を付記している。

以下、各時間軸に示すｔ１〜ｔ５、ｔ３ｈ〜ｔ５ｈにおける処理について、順次、説明する。
（時間ｔ１）
まず、時間ｔ１において、受信装置は、チューナー選局を行う。例えばユーザの選択した特定のチャンネルの番組の受信を開始する。
チューナーによる番組受信の開始に併せて、
（Ｂ）チューナー受信セグメント（放送受信セグメント）が、放送サーバ２１から送信され、受信装置３０において順次、受信される。

この時点では、アプリケーション２１２によるセグメントの合成処理は開始されておらず、
（Ｂ）チューナー受信セグメント（放送受信セグメント）
は、そのまま、
（Ｃ）データコーダ入力セグメント（出力セグメント）
として設定され、チューナー受信セグメント（放送受信セグメント）がデコードされて出力（表示、音声出力）される。

（時間ｔ２）
時間ｔ２において、チューナー受信番組に対応して設定されたアプリケーション（ＨＴＭＬ５アプリ）２１２が起動する。
アプリケーション２１２の起動は、例えばチューナー受信番組、またはそのメタデータに含まれるトリガー情報に基づいて実行される。
ユーザによるアプリケーション起動指示に基づいて起動する設定も可能である。

（時間ｔ３（＝ｔ３ｈ））
時間ｔ３は、時間ｔ２におけるアプリケーション起動後、アプリケーション２１２による処理が開始可能となった時間である。
アプリケーション２１２は、この処理可能開始時間を、ＨＴＭＬ５ビデオ時間軸の起点（ｃｕｒｒｅｎｔＴｉｍｅ＝０）に設定され、ＨＴＭＬ５ビデオ時間軸のＣｕｒｒｅｎｔＴｉｍｅはチューナー受信番組の再生とともに更新される。。
アプリケーションの処理タイミングは、ＨＴＭＬ５ビデオ時間（ｃｕｒｒｅｎｔＴｉｍｅ）に基づいて決定される。

時間ｔ３（ｔ３ｈ＝ＣｕｒｒｅｎｔＴｉｍｅ＝０）において、アプリケーション２１２は、処理対象オブジェクトとしてメディアソースやソースバッファを確保する。
これは、先に図１２を参照して説明した新ＡＰＩの処理によって行われる。前述したように、新ＡＰＩの処理は以下の通りである。
（Ｓ１）通信部（チューナー）２０２受信セグメント格納用のメディアソース２１３を取得し、アプリケーション１４２による参照を可能な設定とする。
（Ｓ２）メディアソース２１３対応のビデオソースバッファ２１４と、オーディオソースバッファ２１５を取得し、アプリケーション１４２による参照を可能な設定とする。
これらのＡＰＩ処理によって、アプリケーション２１２は、メディアソースやソースバッファを参照して、バッファ状況の確認に基づく処理が可能となる。

なお、図１２に示すメディアソース２１３、ソースバッファ２１４，２１５は、アプリケーション２１２による処理対象となるオブジェクトであり、具体的には、受信装置３０の記憶部（バッファ）に格納される放送受信セグメント列に相当する。
ビデオソースバッファ２１４は、受信装置３０の記憶部（バッファ）に格納されるビデオデータのみからなるセグメント列に相当する。
オーディオソースバッファ２１５は、受信装置３０の記憶部（バッファ）に格納されるオーディオデータのみからなるセグメント列に相当する。
メディアソース２１３は、受信装置３０の記憶部（バッファ）に格納されるビデオデータとオーディオデータを含む放送受信セグメント列に相当する。

この時間ｔ３（＝ｔ３ｈ）以降、アプリケーション２１２は、メディアソース２１３、ソースバッファ２１４，２１５（記憶部内に格納される放送受信セグメント列）を参照し、様々な処理を行なうことが可能となる。

アプリケーションは、まず、時間ｔ３（＝ｔ３ｈ）以降、新たにメディアソース２１３に設定されたチューナー受信セグメント、すなわち、受信装置３０の記憶部（バッファ）に新たに格納された放送受信セグメントに設定されたタイムスタンプを取得する。
図に示す例では、セグメント［Ｓｅｇ（ｔｕｎｅｒ１）］が、時間ｔ３（＝ｔ３ｈ）以降に最初にメディアソース２１３に入力したチューナー受信セグメントである。
アプリケーション２１３は、このセグメント［Ｓｅｇ（ｔｕｎｅｒ１）］に設定されたタイムスタンプを取得する。

放送受信セグメントには、放送時間系のタイムスタンプ、すなわちウォールクロック（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））に従ったタイムスタンプが設定されている。
アプリケーションは、このタイムスタンプ（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））を用いて、放送時間軸（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））と、ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）との差分（時間オフセット）である放送タイムオフセット（ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ）を算出する。
すなわち、時間ｔ３（＝ｔ３ｈ）以降に最初にメディアソース２１３に入力したチューナー受信セグメント［Ｓｅｇ（ｔｕｎｅｒ１）］に設定されたタイムスタンプの示す時間を、放送タイムオフセット（ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ）とする。

具体例として、セグメント［Ｓｅｇ（ｔｕｎｅｒ１）］に設定されたタイムスタンプが、
ＵＴＣ２０１４年１０月３日午前７時３分４０秒
であったとする。
この場合、アプリケーションは、放送タイムオフセット（ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ）を上記時間に設定する。すなわち、
ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ＝ＵＴＣ２０１４年１０月３日午前７時３分４０秒
とする。

この時間オフセットは、放送時間軸（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））と、ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）との差分（時間オフセット）に相当する。
すなわち、時間ｔ３（＝ｔ３ｈ）において、
ＨＴＭＬ５ビデオ時間：ｃｕｒｒｅｎｔＴｉｍｅ＝０、
放送時間：ＷａｌｌＣｌｏｃｋ（ＵＴＣ）＝０１４年１０月３日午前７時３分４０秒
であり、
時間オフセット：ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ＝ＵＴＣ２０１４年１０月３日午前７時３分４０秒は、放送時間軸（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））と、ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）との差分（時間オフセット）に相当する。

なお、上述した時間オフセット算出処理例は、アプリケーション２１２の処理対象オブジェクトであるメディアソース、すなわちメディアソースとしての記憶部に格納された放送受信セグメントのタイムスタンプを用いて算出する処理例であリ、前述した新ＡＰＩ（ＭＳＥ−ＡＰＩ）によってメディアソースから取得するデータをそのまま利用することができる。
すなわち、ＡＰＩによる時間オフセット情報の取得処理として実行することが可能である。

また、時間オフセット情報の取得処理は、その他のオブジェクトから取得することも可能である。例えば、メディアソース以外のアプリケーションの処理オブジェクトとして設定可能な通信部（チューナー）２０２や、ビデオデータ等のオブジェクトを介したオフセット情報の取得または算出を行う構成としてもよい。

（時間ｔ４ｈ）
その後、アプリケーションは、時間ｔ４ｈにおいて、ネットワークを介した合成用セグメントの受信を開始する。すなわち、放送受信セグメントに置き換えて出力するための例えば広告コンテンツ等からなるネットワーク受信セグメントの受信処理を開始する。

なお、ネットワークを介した合成用セグメントの受信開始時間ｔ４ｈは、ネットワーク受信セグメント（広告：Ａｄ）の出力開始時間ｔ５（ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ）（＝ｔ５ｈ＝ＶｉｄｅｏＡｄＳｔａｒｔＴｉｍｅ）から予め規定した時間［マージン（Ｍａｒｇｉｎ）］前の時間とする。
マージンは、例えば、インターネットを介したデータ取得に必要な時間等によって決定することができる。

アプリケーション２１２は、ネットワークを介した合成用セグメントの受信開始時間ｔ４ｈを、以下の式によって算出する。
ｔ４ｈ＝ＶｉｄｅｏＡｄＳｔａｒｔＴｉｍｅＢｅｆｏｒｅ
＝ｔ５ｈ−Ｍａｒｇｉｎ
＝ＶｉｄｅｏＡｄＳｔａｒｔｔｉｍｅ−Ｍａｒｇｉｎ
＝ｔ５−ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ
＝ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ−ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ

なお、上記式において、
ｔ４ｈ：ＶｉｄｅｏＡｄＳｔａｒｔＴｉｍｅＢｅｆｏｒｅ
ｔ５ｈ：ＶｉｄｅｏＡｄＳｔａｒｔｔｉｍｅ
Ｍａｒｇｉｎ
これらの時間は、ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）に従った時間情報である。
ｔ５：ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ
この時間は、放送時間軸（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））に従った時間情報である。

なお、アプリケーション２１２は、（広告：Ａｄ）の出力開始時間ｔ５（ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ）について、コンテンツ（番組）の属性情報（メタデータ）から取得することが可能である。

また、
ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ
は、時間ｔ３（＝ｔ３ｈ）において算出した時間オフセットであり、
ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ＝ＵＴＣ２０１４年１０月３日午前７時３分４０秒
である。
アプリケーション２１２は、ネットワークを介した合成用セグメントの受信開始時間ｔ４ｈを、これらの各データを用いて算出する。

この時間ｔ４ｈ以降、アプリケーション２１２は、ネットワークを介して、ネットワーク受信セグメント（広告：Ａｄ）を順次、受信する。
図１３に示すセグメントＳａ１〜Ｓａ５である。
アプリケーションは、これらのネットワーク受信セグメントＳａ１〜Ｓａ５を、チューナー受信セグメントＳ１〜Ｓ５の位置に設定する処理を実行する。
すなわち、チューナー受信セグメントＳ１〜Ｓ５をネットワーク受信セグメントＳａ１〜Ｓａ５に置き換える処理を行なう。

アプリケーション２１２は、前述した新ＡＰＩ（新ＭＳＥ−ＡＰＩ）の処理によって参照可能とされたメディアソース２１３、ソースバッファ２１４，２１５に格納された放送受信セグメントの格納状況を確認してセグメント置き換え処理を実行する。

このセグメント置き換え処理は、置き換え後のネットワーク受信セグメントの出力に間に合うように実行すればよい。
例えば、ネットワーク受信セグメントＳａ１は、チューナー受信セグメントＳ１の位置に置き換えて設定され、チューナー受信セグメントＳ１の出力時間（ｔ５）に出力される。
従って、ネットワーク受信セグメントＳａ１の置換処理は、広告開始時間ｔ５（＝ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ＝２０１４年１０月３日午前７時１６分２０秒）までに完了しておくことが必要となる。

図１３に示す例では、時間ｔ５ｈ（＝ｔ５）が、広告開始時間である。
この時間は、ソースバッファのセグメント（Ｓ１）が出力される時間であり、この時間（ｔ５）のタイムスタンプの設定されたセグメント（Ｓ１）を置換対象セグメント列の開始位置として、ネットワーク受信セグメントＳａ１から順次、置き換えればよい。

アプリケーションは、この処理のために、放送時間系であるウォールクロック（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））に従った広告開始時間ｔ５（＝ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ＝２０１４年１０月３日午前７時１６分２０秒）を、アプリケーションの時間軸［ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）］における時間ｔ５ｈ（ＶｉｄｅｏＡｄＳｔａｒｔＴｉｍｅ）に変換する。
変換処理は以下の式に従って実行される。

ｔ５ｈ（ＶｉｄｅｏＡｄＳｔａｒｔＴｉｍｅ）
＝ｔ５−（ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ）
＝（ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ）−（ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ）
＝（２０１４年１０月３日午前７時１６分２０秒）−（２０１４年１０月３日午前７時３分４０秒）
＝１２分４０秒

なお、上記式において、
ｔ５ｈ：ＶｉｄｅｏＡｄＳｔａｒｔｔｉｍｅ
この時間は、ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）に従った時間情報である。
ｔ５：ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ
この時間は、放送時間軸（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））に従った時間情報である。

なお、アプリケーション２１２は、（広告：Ａｄ）の出力開始時間ｔ５（ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ）について、コンテンツ（番組）の属性情報（メタデータ）から取得することが可能である。
また、記憶部（バッファ）に格納された放送受信セグメントＳ１のタイムスタンプから取得することも可能である。
セグメントＳ１には出力時間を示すタイムスタンプとして、放送時間系であるウォールクロック（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））に従った広告開始時間ｔ５（＝ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ＝２０１４年１０月３日午前７時１６分２０秒）が設定されている。

また、上記式において、
ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ
は、時間ｔ３（＝ｔ３ｈ）において算出した時間オフセットであり、
ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ＝ＵＴＣ２０１４年１０月３日午前７時３分４０秒
である。

上記算出式によって算出された
１２分４０秒
は、ＨＴＭＬ５ビデオ時間軸に従った時間（ｃｕｒｒｅｎｔＴｉｍｅ）、すなわちアプリケーション起動時間：ｔ３ｈ＝０からの経過時間に相当する。
アプリケーションは、この算出時間、
ｃｕｒｒｅｎｔＴｉｍｅ＝１２分３０秒までに、受信装置の記憶部（バッファ）に格納された放送受信セグメントＳ１をネットワーク受信セグメントＳａ１に置き換える処理を実行する。

アプリケーションは、ＨＴＭＬ５ビデオ時間軸に従った時間（ｃｕｒｒｅｎｔＴｉｍｅ）に出力対象として設定されたソースバッファの放送受信セグメント、すなわちセグメントＳ１をネットワーク受信セグメントＳａ１に置き換える処理を実行する。
以降のセグメントＳ２〜Ｓ５についても、各セグメントに設定された出力時間を示すタイムスタンプの経過前に同様の処理を実行して、ネットワーク受信セグメントＳａ２〜Ｓａ５に置き換える処理を実行する。

（時間ｔ５ｈ（＝ｔ５））
受信装置３０の記憶部に格納された放送受信セグメントのセグメントＳ１〜Ｓ５は、アプリケーション２１２の処理によって、順次、ネットワーク受信セグメントＳａ１〜Ｓａ５に置き換えられ、広告開始時間ｔ５（＝ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ＝２０１４年１０月３日午前７時１６分２０秒）以降、置き換え後のネットワーク受信セグメントＳａ１〜Ｓａ５が、順次、出力される。

図１３に示す（ｃ）デコーダ入力セグメントは、置き換え後のセグメント列を示している。このセグメント列がデコーダに入力され、デコード処理後、表示部等の出力部に出力されることになる。
この処理によって、放送波受信セグメントの一部がネットワーク受信セグメントに置き換えられ、先に図８を参照して説明したようなデータ切り換え表示が可能となる。
すなわち、放送受信データである番組コンテンツを、所定タイミングでネットワーク受信データである広告コンテンツに切り替え、その後、再度、放送受信データである番組コンテンツに切り替えるデータ出力処理が可能となる。

時間ｔ３ｈ以後、アプリケーション２１２は、アプリケーション２１２の参照可能なオブジェクトに設定された図１３（Ｂ）チューナー受信セグメント、すなわち記憶部（バッファ）に格納された放送受信セグメントを参照して、バッファされた放送受信セグメントの出力時間に相当するタイムスタンプを取得し、それぞれのタイムスタンプに至る前に、放送受信セグメントＳ１〜Ｓ５をネットワーク受信セグメントＳａ１〜Ｓａ５に置き換える処理を完了させる。

記憶部（バッファ）に格納された放送受信セグメントは、前述の新ＡＰＩの処理により、アプリケーション２１２による処理対象オブジェクトであるメディアソース２１３や、ソースバッファ２１４，２１５として設定され、アプリケーションは、バッファ状況を確認することが可能である。
アプリケーション２１２は、バッファされた放送受信セグメントＳ１〜Ｓ５のタイムスタンプを確認し、それぞれのタイムスタンブ設定時間までに、置換処理を完了させる。

なお、放送受信セグメントＳ１〜Ｓ５のタイムスタンプは、放送時間軸（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））に従った時間情報である。
アプリケーション２１２は、タイムスタンブ設定時間を、前述の時間（ｔ３ｈ）において算出した時間オフセット：ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ＝ＵＴＣ２０１４年１０月３日午前７時３分４０秒を考慮して、ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）に従った時間情報に変換する。
この変換処理によって、生成した時間に基づいて、各セグメントの置換処理を各セグメントの出力開始時間までに完了させる。

このように、アプリケーション２１２は、受信装置３０の記憶部（バッファ）に格納された放送受信セグメントの一部をネットワーク受信セグメントによって置き換えるメディアソース更新処理を実行する。
この処理によって、放送波受信セグメントの一部がネットワーク受信セグメントに置き換えられ、先に図８を参照して説明したようなデータ切り換え表示が可能となる。
すなわち、放送受信データである番組コンテンツを、所定タイミングでネットワーク受信データである広告コンテンツに切り替え、その後、再度、放送受信データである番組コンテンツに切り替えるデータ出力処理が可能となる。

この実施例では、チューナー受信セグメントは、ＨＴＴＰサーバへの格納、読み出し処理が行われず、直接、アプリケーション２１２の処理対象オブジェクトとしてのソースバッファとして設定される。
アプリケーション２１２は、ソースバッファのセグメントの置き換えを伴うソースバッファ更新処理によって、放送波受信セグメントのみからなるソースバッファの一部のセグメントを、ネットワーク受信セグメントに置き換える。
このソースバッファ更新処理は、ＨＴＴＰサーバに対するデータ格納、読み出し処理に比較して極めて短時間の処理として実行することが可能であり、置き換えられたセグメントの出力を遅延なく実行することが可能となる。

［７．受信装置におけるデータ受信および合成処理に適用するハードウェア構成例について］
次に、図１４を参照して受信装置におけるデータ受信および合成処理に適用するハードウェア構成例について説明する。

図１４には、受信装置３０において実行する以下の処理、すなわち、
（ａ）ネットワークおよび放送波を介したデータ受信処理、
（ｂ）受信データに基づくデータ合成処理（セグメント合成処理）を実行して表示部等の出力部に出力するデータの生成処理、
これらの処理を実行する受信装置３０のハードウェア構成例を示す図である。

図１４に示すように、受信装置３０は、
放送受信データ処理部３１０、ネットワーク受信データ処理部３３０、さらに。メタデータ（シグナリング）処理部３２１、バッファ管理部３２２、合成部３４１を有する。
放送受信データ処理部３１０は、チューナー３１１、記憶部（バッファ）３１２、デコーダ＆レンダラー３１３を有する。
また、ネットワーク受信データ処理部３３０は、ネットワークＩ／Ｆ３３１、ＨＴアプリケーション実行部（ＨＴＭＬ５ブラウザ）３３２、グラフィックシステム（ＨＴＭＬページ出力部）３３３を有する。

放送波を介して送信されるデータは、アンテナを介して放送受信データ処理部３１０のチューナー３１１によって受信される。受信データは、記憶部（バッファ）３１２に格納された後、デコーダ＆レンダラー３１３において、デコード処理および描画処理がなされ、合成部３４１において、ネットワーク受信データ処理部の生成するＨＴＭＬページとの合成処理がなされて合成画像の出力が実行される。

ネットワークを介して送信されるデータは、ネットワーク受信データ処理部３３０のネットワークＩ／Ｆ３３１によって受信される。受信データは、アプリケーション実行部３３２に渡され、必要に応じて、前述した放送受信セグメントとの合成処理が行われる。
アプリケーション実行部３３２の生成したデータが、グラフィックスシステム（ＨＴＭＬページ生成部）３３３に渡され、生成されたＨＴＭＬページが合成部３４１に出力される。
合成部３４１において、放送受信データ処理部の生成した出力データとの合成処理がなされて合成画像の出力が実行される。

ここで、アプリケーション実行部３３２が、前述した放送受信セグメントとネットワーク受信セグメントとの合成処理を行なう場合の処理例について説明する。
放送受信セグメントは、すべて記憶部（バッファ）３１２に格納される。

この記憶部（バッファ）３１２に格納された放送受信セグメントのバッファ格納情報は、バッファ管理部３２２を介してアプリケーション実行部３３２が取得することができる。
記憶部（バッファ）３１２の格納データは、図１２に示すアプリケーション２１２の処理対象オブジェクトであるメディアソース２１３、ソースバッファ２１４，２１５を構成するデータである。
前述したように、アプリケーション２１２は、新ＡＰＩの処理によって、記憶部（バッファ）３１２の格納データを参照することが可能となる。
図１４に示すハードウェア構成では、アプリケーション実行部３３２は、バッファ管理部３２２を介してバッファ情報を取得する処理を実行する。

また、アプリケーション実行部３３２は、チューナー３１１を介して受信される各種のメタデータ（シグナリングデータ）をメタデータ（シグナリング）処理部３２１を介して取得することができる。
このメタデータ（シグナリング）には、例えば、先に図１３を参照して説明した広告開始時間（ｔ５）等の情報が含まれる。

アプリケーション実行部３３２は、バッファ管理部３２２を介して取得するバッファ情報、例えば、記憶部（バッファ）３１２に格納された放送受信セグメントのタイムスタンプ情報等を取得し、さらに、メタデータ（シグナリング）処理部３２１を介して例えば、先に図１３を参照して説明した広告開始時間（ｔ５）等の情報を取得する。
アプリケーション実行部２１２は、これらの情報を適用して、先に図１３を参照して説明したセグメントの置き換え処理、すなわち、記憶部（バッファ）３１２に格納された放送受信セグメントの一部をネットワーク受信セグメントに置き換える処理をバッファ管理部３２２に指示して実行させる。
このハードウェア構成例によれば、放送受信セグメントのメディアソースのバッファリング情報はＡＰＩとしては公開されているが、放送セグメント自体はソフトウェアで実装されたブラウザに伝送されることはなく、放送受信データ処理部で処理されるためハードウェア化できるため、ソフトウェアの負荷を低減できるため、高性能なＣＰＵや大量のメモリを必要しない低コストな実装や低消費電力化の実装が可能である。

［８．受信装置の実行する処理のシーケンスについて］
次に、図１５以下に示すフローチャートを参照して、受信装置３０、および図１２に示すアプリケーション２１２（＝図１４に示すアプリケーション実行部３３２）の実行する処理のシーケンスについて説明する。

まず、図１５に示すフローチャートを参照して、受信装置３０の実行する全体的な処理についてのシーケンスを説明する。
図１５に示すフローは、例えば受信装置３０の記憶部に記憶されたプログラムに従って、受信装置のプログラム実行機能を持つＣＰＵ等を備えたデータ処理部の制御の下に実行される。
以下、図１５に示すフローの各ステップの処理について、順次、説明する。

（ステップＳ２０１）
まず、ステップＳ２０１において、受信装置３０側のユーザによって受信チャンネルの選択がなされ、選択されたチャンネルのコンテンツ（番組）の受信処理と再生処理が開始される。
このコンテンツは、放送サーバ２１の送信する放送波から取得される。
なお、受信装置３０は、コンテンツ（番組）の受信に併せて、コンテンツ対応のアプリケーションや、コンテンツ対応の様々なメタデータを受信する。

（ステップＳ２０２）
次に、受信装置は、ステップＳ１０１において選択され、受信、再生を開始したコンテンツ（番組）に対応して設定されたアプリケーションを起動する。例えば図１２に示すアプリケーション２１２である。
アプリケーションの起動は、例えばチューナー受信番組、またはそのメタデータに含まれるトリガー情報に基づいて実行される。
ユーザによるアプリケーション起動指示に基づいて起動する設定としてもよい。

（ステップＳ２０３）
次に、受信装置３０は、起動したアプリケーションによる処理を実行する。具体的には、ネットワークを介して受信した広告コンテンツ等のネットワーク受信データを放送受信データに置き換え、あるいは重畳するデータ合成処理を実行する。
これは、先に図１２〜図１４を参照して説明した処理に相当する。
このステップＳ２０３のアプリケーション処理の詳細シーケンスについては、図１６〜図１７に示すフローチャートを参照して後段で説明する。

（ステップＳ２０４〜Ｓ２０５）
ステップＳ２０４は、チャンネル切り替えの有無判定処理である。
チャンネル切り替えが発生すると、ステップＳ２０５に進み、バングミ連動のアプリケーションは終了する。アプリケーション終了後、ステップＳ２０１に戻り、切り替え後のチャンネル対応のコンテンツ（番組）の受信、再生処理を開始する。
一方、ステップＳ２０４においてチャンネル切り替え無しの判定の場合は、ステップＳ２０６に進む。その他、チャンネル切り替えが発生していないい場合でも、先に示したように受信番組のメタデータに含まれるトリガー情報に基づいて、別のアプリケーションが起動される場合もある。

（ステップＳ２０６〜Ｓ２０７）
ステップＳ２０６は、ユーザによる受信装置３０の電源オフ動作がなされたか否かの判定処理である。
電源がオフされた場合、ステップＳ２０７に進み、コンテンツ受信、再生を終了する。併せてアプリケーションの処理も終了する。
一方、電源がオフされていない場合は、ステップＳ２０３におけるアプリケーションの処理を継続して実行する。

次に、ステップＳ２０３において実行されるアプリケーション処理の詳細シーケンスについて、図１６、図１７に示すフローチャートを参照して説明する。
図１６のフローのステップＳ３０１から、各ステップの処理の詳細について、順次、説明する。
なお、アプリケーションは、図１２を参照して説明したアプリケーション２１２であり、具体的には、例えばブラウザ上で動作するＨＴＭＬ５アプリケーションである。

（ステップＳ３０１）
まず、アプリケーションは、ステップＳ３０１において、アプリケーションの処理対象（オブジェクト）としてＨＴＭＬ５ビデオオブジェクトを設定する。
これは、放送受信データとネットワーク受信データとの合成処理を可能とするための準備処理であり、アプリケーションの生成する合成データ用の処理オブジェクトとしてＨＴＭＬ５ビデオデータを設定する処理である。

（ステップＳ３０２）
次に、アプリケーションは、ステップＳ３０２において、アプリケーションの処理対象（オブジェクト）としてチューナーを設定する。図１２に示す放送受信セラグメント１２５を受信する通信部（チューナー）２０２である。
これも、放送受信データとネットワーク受信データとの合成処理を可能とするための準備処理であり、放送受信データを受信する通信部（チューナー）２０２を処理対象（オブジェクト）に設定する処理である。ＣｕｒｒｅｎｔＴｕｎｅｒとあるのは、受信機が複数チューナーを搭載していた場合、テレビに表示されているチューナのオブジェクトを取得するという意味である。このチューナーオブジェクトはアプリケーションがチャンネル切り替えを指示するＡＰＩとしても利用される。
なお、この処理は、前述した新ＡＰＩを適用した処理として実行される。
前述した新ＡＰＩ（ＭＳＥ−ＡＰＩ）の実行する処理アルゴリズム中の以下の処理に相当する。
ｔｕｎｅｒ＝ｎａｖｉｇａｔｏｒ．ｔｖ．ｃｕｒｒｅｎｔＴｕｎｅｒ（）；

（ステップＳ３０３）
次に、アプリケーションは、ステップＳ３０３において、ステップＳ３２０において処理対象オブジェクトに設定したチューナーオブジェクトから、チューナーメディアソースオブジェクトを取得する。
この処理は、図に示すメディアソース２１３の取得処理に相当する。
図１２に示す通信部（チューナー）２０２は、放送サーバ２１の送信する放送受信セグメント１２５を受信し、受信セグメントをメディアソースとして記憶部（バッファ）に格納された設定となる。ただし、ハードウェア構成として図１４に示す様に、チューナーからの受信セグメントはアプリケーションの実行部に関わらず、記憶部（バッファ）３１２に放送受信セグメント１２５を格納し、デコーダ＆レンダラ３１３を経て再生されている事になる。

アプリケーションは、この記憶部（バッファ）３１２に格納された放送受信セグメントのバッファリング情報を提供するアプリケーションの処理対象オブジェクトであるメディアソース、すなわち、図１２に示すメディアソース２１３として取得する。
なお、この処理も、前述した新ＡＰＩを適用した処理として実行される。
前述した新ＡＰＩの実行する処理アルゴリズム中の以下の処理に相当する。
ｍｅｄｉａＳｏｕｒｃｅ＝．ｔｕｎｅｒ．ｇｅｔＭｅｄｉａＳｏｕｒｃｅ（）；

（ステップＳ３０４）
次に、アプリケーションは、ステップＳ３０４において、ステップＳ３０１においてアプリケーションの処理対象オブジェクトに設定したＨＴＭＬ５ビデオオブジェクトに、ステップＳ３０３において取得したチューナーメディアソースオブジェクトを設定する。
すなわち、アプリケーションによる合成処理の準備処理として、放送ジュシンセグメントのみから構成されるメディアソースを、ＨＴＭＬ５ビデオオブジェクトに設定する処理である。
これは、例えば、図１３に示す（Ｂ）チューナー受信セグメントのセグメントＳ１等を含むセグメント列（＝更新前メディアソース）をＨＴＭＬ５ビデオオブジェクトに設定する処理である。
なお、この処理も、前述した新ＡＰＩを適用した処理として実行される。
前述した新ＡＰＩの実行する処理アルゴリズム中の以下の処理に相当する。ただし、この処理は元のＭＳＥ ＡＰＩで行われる処理と同じである。
ｖｉｄｅｏ．ｓｒｃ＝ｗｉｎｄｏｗ．ＵＲＬ．ｃｒｅａｔｅＯｂｊｅｃｔＵＲＬ（ｍｅｄｉａＳｏｕｒｃｅ）；

（ステップＳ３０５）
次に、アプリケーションは、ステップＳ３０５において、ステップＳ３０３において取得したチューナーメディアソースオブジェクトから、放送時間オフセットを取得する。
この時間オフセット取得処理は、先に図１３を参照して説明した放送タイムオフセット（ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ）の取得処理である。

チューナーメディアソースオブジェクトに含まれる放送受信セグメントには、放送時間系のタイムスタンプ、すなわちウォールクロック（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））に従ったタイムスタンプが設定されている。
アプリケーションは、このタイムスタンプ（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））を用いて、放送時間軸（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））と、ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）との差分（時間オフセット）である放送タイムオフセット（ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ）を決定する。

先に、図１３を参照して説明したように、例えば、図１３に示すセグメント［Ｓｅｇ（ｔｕｎｅｒ１）］に設定されたタイムスタンプが、
ＵＴＣ２０１４年１０月３日午前７時３分４０秒
であったとする。
この場合、アプリケーションは、放送タイムオフセット（ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ）を上記時間に設定する。すなわち、
ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ＝ＵＴＣ２０１４年１０月３日午前７時３分４０秒
とする。

この時間オフセットは、放送時間軸（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））と、ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）との差分（時間オフセット）に相当する。
すなわち、時間ｔ３（＝ｔ３ｈ）において、
ＨＴＭＬ５ビデオ時間：ｃｕｒｒｅｎｔＴｉｍｅ＝０、
放送時間：ＷａｌｌＣｌｏｃｋ（ＵＴＣ）＝０１４年１０月３日午前７時３分４０秒
であり、
時間オフセット：ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ＝ＵＴＣ２０１４年１０月３日午前７時３分４０秒は、放送時間軸（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））と、ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）との差分（時間オフセット）に相当する。

なお、上述した時間オフセット算出処理例は、アプリケーションの処理対象オブジェクトであるメディアソース、すなわちメディアソースとしての記憶部に格納された放送受信セグメントのタイムスタンプを用いて算出する処理例であリ、前述した新ＡＰＩ（ＭＳＥ−ＡＰＩ）によってメディアソースから取得するデータをそのまま利用することができる。
すなわち、以下のＡＰＩによる時間オフセット情報の取得処理として実行することが可能である。
ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ ＝ ｍｅｄｉａＳｏｕｒｃｅ.ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ

また、時間オフセット情報の取得処理は、その他のオブジェクトから取得することも可能である。例えば、以下のようにメディアソース以外のアプリケーションの処理オブジェクトとして設定可能な通信部（チューナー）や、ビデオデータ等のオブジェクトを介したオフセット情報の取得または算出を行う構成としてもよい。
ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ ＝ ｎａｖｉｇａｔｏｒ.ｔｖ.ｃｕｒｒｅｎｔＴｕｎｅｒ().ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ
ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ ＝ ｖｉｄｅｏ.ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ

（ステップＳ３０６）
次に、アプリケーションは、ステップＳ３０６において、ステップＳ３０３で取得したチューナーメディアソースオブジェクトから、ビデオ、オーディオの各ソースバッファを取得する。
ビデオソースバッファは、図１２に示すソースバッファ２１４に相当し、オーディオソースバッファは、図１２に示すソースバッファ２１５に相当する。
これらのソースバッファ２１４，２１５は、メディアソース２１３の一部の構成要素から構成されるオブジェクト、すなわちアプリケーションが処理可能なオブジェクトである。

これらは、受信装置３０の記憶部（バッファ）に格納される放送受信セグメント列に相当する。
ビデオソースバッファ２１４は、図１４に示す受信装置３０の記憶部（バッファ）３１２に格納されるビデオデータのみからなるセグメント列に相当する。
オーディオソースバッファ２１５は、受信装置３０の記憶部（バッファ）３１２に格納されるオーディオデータのみからなるセグメント列に相当する。
メディアソース２１３は、受信装置３０の記憶部（バッファ）３１２に格納されるビデオデータとオーディオデータを含む放送受信セグメント列に相当する。

アプリケーションは、ステップＳ３０６において、ステップＳ３０３で取得したチューナーメディアソースオブジェクトから、ビデオ、オーディオの各ソースバッファを取得する。
なお、この処理も、前述した新ＡＰＩを適用した処理として実行される。
前述した新ＡＰＩの実行する処理アルゴリズム中の以下の処理に相当する。元のＭＳＥ ＡＰＩではアプリケーションが新規にバッファを作成していたが、新ＡＰＩではチューナーメディアソースオブジェクトは放送受信データに含まれるビデオ、オーディオの数やコーデックの種類に合わせてブラウザにより生成される
ｖｉｄｅｏＳｏｕｒｃｅＢｕｆｆｅｒ＝ｍｅｄｉａＳｏｕｒｃｅ．ｓｏｕｒｃｅＢｕｆｆｅｒｓ［０］；
ａｕｄｉｏＳｏｕｒｃｅＢｕｆｆｅｒ＝ｍｅｄｉａＳｏｏｒｃｅ．ｓｏｕｒｃｅＢｕｆｆｅｒｓ［１］；

（ステップＳ３０７）
次に、アプリケーションは、ステップＳ３０７において、放送波を介して受信するメタデータ（シグナリングデータ）から、ネットワーク受信データ（例えばＭＰ４広告からなるセグメント列）の挿入の開始時間（ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ）と、ネット受信セグメントファイルのＵＲＬリスト、セグメントファイルの数を取得する。

これは、図１４に示すチューナー３１１から、メタデータ（シグナリング）処理部３２１を介してアプリケーション実行部３３２に至るデータ経路を介して実行される処理である。
放送サーバ２１は、コンテンツ（番組）に併せて、様々なメタデータをシグナリングデータとして受信装置３０に提供しており、受信装置３０は、これらのメタデータをチューナー（図１２の通信部（チューナー）２０２＝図１４のチューナー３１１））を介して受信する。
アプリケーションは、このメタデータ（シグナリングデータ）から、ネットワーク受信データ（例えばＭＰ４広告からなるセグメント列）の挿入の開始時間（ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ）と、ネット受信セグメントファイルのＵＲＬリスト、セグメントファイルの数を取得する。これらの情報は、ＭＰＥＧ ＤＡＳＨのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）を用いて記述することもでき、したがってアダプティブストリーミングによりコンテンツ再生することもできる。また、サービスワーカーをつかうことによって、広告コンテンツのセグメントを予め取得し、受信機の永続的キャッシュに保存しておくことで、ネットワークの帯域に影響されずに、放送番組と同等の高画質、高音質にて広告を再生することが可能である。

なお、ネットワークを介して受信し、放送データに合成するコンテンツには様々な種類があるが、例えば広告データの場合、提供地域やユーザに応じて異なる広告とする設定が可能である。いわゆるターゲット広告の設定が可能となる。
このような場合、受信装置やユーザの属性によって提供される広告動画は異なることになり、ネット受信セグメントファイルのＵＲＬリスト、セグメントファイルの数等は、受信装置毎に異なる設定となる場合がある。

（ステップＳ３０８〜Ｓ３０９）
次に、アプリケーションは、ステップＳ３０８において、ステップＳ３０１で処理対象として設定し、ステップＳ３０４でチューナーメディアソースを設定したＨＴＭＬ５ビデオオブジェクト、すなわち、放送受信セグメントのみによって構成されるＨＴＭＬ５ビデオオブジェクトのカレントタイム（ｃｕｒｒｅｎｔＴｉｍｅ）を取得する。カレントタイム（ｃｕｒｒｅｎｔＴｉｍｅ）は、アプリケーションの時間軸［ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）］に従った時間情報である。

さらに、ステップＳ３０９において、ネットワークを介して、ネットワーク受信セグメント、例えば広告コンテンツからなるＭＰ４ファイルを格納したセグメントの受信を開始する。
このステップＳ３０８〜Ｓ３０９の処理は、先に図１３を参照して説明した時間（ｔ３ｈ〜ｔ４ｈ）の処理に相当する。

すなわち、先に図１３を参照して説明したように、アプリケーションは、ネットワークを介した合成用セグメントの受信開始時間ｔ４ｈを、以下の式によって算出する。
ｔ４ｈ＝ＶｉｄｅｏＡｄＳｔａｒｔＴｉｍｅＢｅｆｏｒｅ
＝ｔ５ｈ−Ｍａｒｇｉｎ
＝ＶｉｄｅｏＡｄＳｔａｒｔｔｉｍｅ−Ｍａｒｇｉｎ
＝ｔ５−ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ
＝ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ−ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ

なお、上記式において、
ｔ４ｈ：ＶｉｄｅｏＡｄＳｔａｒｔＴｉｍｅＢｅｆｏｒｅ
ｔ５ｈ：ＶｉｄｅｏＡｄＳｔａｒｔｔｉｍｅ
Ｍａｒｇｉｎ
これらの時間は、ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）に従った時間情報である。
ｔ５：ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ
この時間は、放送時間軸（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））に従った時間情報である。

なお、アプリケーションは、（広告：Ａｄ）の出力開始時間ｔ５（ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ）を、ステップＳ３０７においてコンテンツ（番組）の属性情報（メタデータ）から取得済みである。

また、
ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ
は、ステップＳ３０５において算出した時間オフセットであり、
図１３を参照して説明した例では、
ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ＝ＵＴＣ２０１４年１０月３日午前７時３分４０秒
である。
アプリケーションは、ネットワークを介した合成用セグメントの受信開始時間（ＶｉｄｅｏＡｄＳｔａｒｔＴｉｍｅＢｅｆｏｒｅ）、すなわち、図１３に示す時間ｔ４ｈを、これらの各データを用いて算出する。

（ステップＳ３１０〜Ｓ３１１）
アプリケーションは、ステップＳ３１０において、ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）に従った時間（ｃｕｒｒｅｎｔＴｉｍｅ）が、ネットワークを介した合成用セグメントの受信開始時間（ＶｉｄｅｏＡｄＳｔａｒｔＴｉｍｅＢｅｆｏｒｅ）になったか否かを判定する。
時間になったと判定した場合は、ステップＳ３１１に進み、ネットワークを介した合成用セグメント、例えばＭＰ４広告コンテンツを格納したセクメントの受信を開始する。
時間になっていない場合は、ステップＳ３０８に戻り、ステップＳ３０８〜Ｓ３０９の処理を繰り返す。

（ステップＳ３１２）
アプリケーションは、ステップＳ３１２において、ステップＳ３１１でネットワークを介して受信したネットワーク受信セグメント（例えばＭＰ４広告）を、ビデオ、オーディオの各ソースバッファの（ＶｉｄｅｏＡｄＳｔａｒｔＴｉｍｅ）の位置に追加する処理を行なう。

アプリケーションの処理対象オブジェクトとして設定されたビデオ、オーディオの各ソースバッファに設定されたデータ（セグメント）は、すべてアプリケーションの時間軸［ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）］に従った処理を行なうオブジェクトとして設定される。

ネットワーク受信セグメントの追加位置を規定する（ＶｉｄｅｏＡｄＳｔａｒｔＴｉｍｅ）は、ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）］における時間である。これは、先に図１３を参照して説明した時間（ｔ５ｈ）に相当する。

先に図１３を参照して説明したように、時間（ｔ５ｈ＝ＶｉｄｅｏＡｄＳｔａｒｔＴｉｍｅ）は、放送時間系であるウォールクロック（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））に従った広告開始時間ｔ５（＝ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ）を利用して算出する。

算出処理は以下の式に従って実行される。図１３を参照して説明した時間情報を適用して説明する。
ｔ５ｈ（ＶｉｄｅｏＡｄＳｔａｒｔＴｉｍｅ）
＝ｔ５−（ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ）
＝（ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ）−（ｂｒｏａｄｃａｓｔＴｉｍｅＯｆｆｓｅｔ）
＝（２０１４年１０月３日午前７時１６分２０秒）−（２０１４年１０月３日午前７時３分４０秒）
＝１２分４０秒

なお、上記式において、
ｔ５ｈ：ＶｉｄｅｏＡｄＳｔａｒｔｔｉｍｅ
この時間は、ＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）に従った時間情報である。
ｔ５：ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ
この時間は、放送時間軸（ＷａｌｌＣｌｏｃｋ（ＵＴＣ））に従った時間情報である。

なお、アプリケーションは、（広告：Ａｄ）の出力開始時間ｔ５（ＢｒｏａｄｃａｓｔＡｄＳｔａｒｔＴｉｍｅ）をステップＳ３０７において、コンテンツ（番組）の属性情報（メタデータ）から取得済みである。

アプリケーションは、このようにして算出したＨＴＭＬ５ビデオ時間軸（ｃｕｒｒｅｎｔＴｉｍｅ）に従った時間情報である広告開始時間（ＶｉｄｅｏＡｄＳｔａｒｔＴｉｍｅ）の時間位置に、ステップＳ３１１でネットワークを介して受信したネットワーク受信セグメント（例えばＭＰ４広告）を追加する処理を行なう。デコード＆レンダラー３１３の処理による遅延のために実際はＨＴＭＬ５ビデオのＣｕｒｒｅｎｔＴｉｍｅの値とチューナーのメディアソースのとのバッファに格納されているセグメントのバッファ範囲を示すＢｕｆｆｅｒｅｄプロパティーにはこの遅延分のズレが有有るので、より緻密なタイミング制御にはＢｕｆｆｅｒｅｄプロパティーの値を利用して、セグメントの置換処理を行うのが良い。

（ステップＳ３１３〜Ｓ３１４）
次に、アプリケーションは、ステップＳ３１３において、すべてのネットワーク受信セグメントの処理を完了したか否かを判定する。
処理が完了していない場合は、ステップＳ３１１に戻り、未処理セグメントについてステップＳ３１１以下の処理を実行する。
すべてのセグメントに対する処理が完了したと判定した場合は、ステップＳ３１４に進み、次のネット受信セグメント列（例えば次の広告）の処理のために、ステップＳ３０７に戻る。

以上、アプリケーションの実行する処理の詳細について、図１６、図１７に示すフローチャートを参照して説明した。
これらの説明から理解されるように、アプリケーションは、図１４に示す受信装置３０の記憶部（バッファ）に格納された放送受信セグメントの一部をネットワーク受信セグメントによって置き換えるメディアソース更新処理を実行する。
この処理によって、放送波受信セグメントの一部がネットワーク受信セグメントに置き換えられ、先に図８を参照して説明したようなデータ切り換え表示が可能となる。
すなわち、放送受信データである番組コンテンツを、所定タイミングでネットワーク受信データである広告コンテンツに切り替え、その後、再度、放送受信データである番組コンテンツに切り替えるデータ出力処理が可能となる。

本実施例では、チューナー受信セグメントは、先に図１１を参照して説明したようなＨＴＴＰサーバへの格納、読み出し処理が行われない。
本実施例では、チューナー受信セグメントは、直接、アプリケーションの処理対象オブジェクトであるソースバッファとして設定される。
アプリケーションは、ソースバッファのセグメントの置き換えを伴うソースバッファ更新処理によって、放送波受信セグメントのみからなるソースバッファの一部のセグメントを、ネットワーク受信セグメントに置き換える。
このソースバッファ更新処理は、ＨＴＴＰサーバに対するデータ格納、読み出し処理に比較して極めて短時間の処理として実行することが可能であり、置き換えられたセグメントの出力を遅延なく実行することが可能となる。

［９．サービスワーカー（ＳＷ）とアプリケーションを利用した処理例について］
上述したアプリケーションは、先に説明したサービスワーカー（ＳＷ）の管理アプリケーションとして設定することが可能となる。
サービスワーカー（ＳＷ）の管理アプリケーションとして設定することで、アプリケーションは、アプリケーションの提供されたコンテンツ（番組）終了後も、受信装置の記憶部に格納され、他の番組再生中や、ネットワークが接続されていないオフライン状態であっても任意のタイミングで実行することが可能となる。

サービスワーカー（ＳＷ）は、例えば放送波やネットワークを介して送信されるデータを選択的に取得する処理や、アプリケーションの起動タイミングを制御する処理などを実行する機能を有する。

このサービスワーカー（ＳＷ）とアプリケーションを組み合わせることで、例えば、以下のような処理を行なうことが可能となる。
（処理例１）
アプリケーションが、ユーザの視聴履歴を取得し、取得した視聴履歴情報をメタデータとしてサービスワーカー（ＳＷ）に通知する。
サービスワーカー（ＳＷ）は、メタデータ（視聴履歴情報）に基づいて、放送波によって送信される様々な種類の広告データから、ユーザの興味に適合した広告を選択取得する。
アプリケーションは、サービスワーカー（ＳＷ）がの選択的に取得した広告コンテンツの表示処理を実行する。
このような処理を行なうことで、ユーザの興味に一致した広告を集中的に提供することが可能となる。

（処理例２）
サービスワーカー（ＳＷ）が、事前に広告データと、その出力時間を記録したメタデータを取得し、受信装置の記憶部に格納しておく。
アプリケーションは、受信装置の記憶部に格納された広告データと、メタデータを取得して、メタデータに記録された出力時間に併せて取得した広告データを出力する処理を実行する。

サービスワーカー（ＳＷ）とアプリケーションを組み合わせることで、例えば、上記のような処理を行なうことが可能となる。

また、上述した実施例では、図８に示した置換表示により広告を表示する例を示したが、図７のように広告コンテンツを重畳する場合も容易に実現することが可能である。重畳表示する場合は、放送の受信データを格納したメディアソースに加え、重畳するネットワーク受信したデータを再生するメディアソースの２つのメディアソースを利用し、ＨＴＭＬ５のビデオオブジェクトも２つ作成し、各々のメディアソースを設定する。

ネットワーク受信したデータを再生するメディアソースを通常のＭＳＥ−ＡＰＩで作成する。本実施例で示したとおり、放送データのメディアソースが設定されたＨＴＭＬ５ビデオの時間軸と放送の時間軸を合わせることは可能であるので、ネットワーク受信のデータの再生するＨＴＭＬ５ビデオ時間軸を放送データのＨＴＭＬ５ビデオの時間軸合わせることができれば、放送時間の任意のタイミングにて広告コンテンツを重畳して表示させることが可能である。

具体的にはＨＴＭＬ５のビデオオブジェクトにはＭｅｄｉａＧｒｏｕｐプロパティーが定義されており、複数のビデオ再生をＣｕｒｒｅｎｔＴｉｍｅを同時に進む様に同期させることが可能である。重畳表示の場合は図１６に示した設定のフローは、以下に示すＪａｖａＳｃｒｉｐｔ（登録商標）に従った処理として行よれる。

＜ｓｃｒｉｐｔ＞
ｖａｒ ｖｉｄｅｏＴｕｎｅｒ＝ｄｏｃｕｍｅｎｔ．ｇｅｔＥｌｅｍｅｎｔＢｙＩｄ（'ｖＴｕｎｅｒ'）；
ｖａｒ ｔｕｎｅｒ＝ｎａｖｉｇａｔｏｒ．ｔｖ．ｃｕｒｒｅｎｔＴｕｎｅｒ（）；
ｖａｒ ｍｅｄｉａＳｏｕｒｃｅＴｕｎｅｒ＝．ｔｕｎｅｒ．ｇｅｔＭｅｄｉａＳｏｕｒｃｅ（）；
ｍｅｄｉａＳｏｕｒｃｅＴｕｎｅｒ．ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒ（'ｓｏｕｒｃｅｏｐｅｎ'，ｏｎＳｏｕｒｃｅＯｐｅｎ．ｂｉｎｄ（ｔｈｉｓ，ｖｉｄｅｏ））；
ｖｉｄｅｏＴｕｎｅｒ．ｓｒｃ＝ｗｉｎｄｏｗ．ＵＲＬ．ｃｒｅａｔｅＯｂｊｅｃｔＵＲＬ（ｍｅｄｉａＳｏｕｒｃｅＴｕｎｅｒ）；
ｖａｒ ｖｉｄｅｏＳｏｕｒｃｅＢｕｆｆｅｒＴｕｎｅｒ＝ｍｅｄｉａＳｏｕｒｃｅＴｕｎｅｒ．ｓｏｕｒｃｅＢｕｆｆｅｒｓ［０］；
ｖａｒ ａｕｄｉｏＳｏｕｒｃｅＢｕｆｆｅｒＴｕｎｅｒ＝ｍｅｄｉａＳｏｕｒｃｅＴｕｎｅｒ．ｓｏｕｒｃｅＢｕｆｆｅｒｓ［１］；
ｖａｒ ｖｉｄｅｏＡｄ＝ｄｏｃｕｍｅｎｔ．ｇｅｔＥｌｅｍｅｎｔＢｙＩｄ（'ｖＡｄ'）；
ｖａｒ ｍｅｄｉａＳｏｕｒｃｅＡｄ＝ｎｅｗ ＭｅｄｉａＳｏｕｒｃｅ（）；
ｍｅｄｉａＳｏｕｒｃｅＡｄ．ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒ（'ｓｏｕｒｃｅｏｐｅｎ'，ｏｎＳｏｕｒｃｅＯｐｅｎ．ｂｉｎｄ（ｔｈｉｓ， ｖｉｄｅｏ））；
ｖｉｄｅｏＡｄ．ｓｒｃ＝ｗｉｎｄｏｗ．ＵＲＬ．ｃｒｅａｔｅＯｂｊｅｃｔＵＲＬ（ｍｅｄｉａＳｏｕｒｃｅＡｄ）；
ｖａｒ ｖｉｄｅｏＳｏｕｒｃｅＢｕｆｆｅｒＡｄ＝ｍｅｄｉａＳｏｕｒｃｅＡｄ．ａｄｄＳｏｕｒｃｅＢｕｆｆｅｒ（'ｖｉｄｅｏ／ｍｐ４；ｃｏｄｅｃｓ＝"ａｖｃ１．４ｄ４０１ｆ"'）；
ｖａｒ ａｕｄｉｏＳｏｕｒｃｅＢｕｆｆｅｒＡｄ＝ｍｅｄｉａＳｏｕｒｃｅＡｄ．ａｄｄＳｏｕｒｃｅＢｕｆｆｅｒ（'ａｕｄｉｏ／ｍｐ４；ｃｏｄｅｃｓ＝"ｍｐ４ａ．４０．２"'）
ｖｉｄｅｏＴｕｎｅｒ.ｍｅｄｉａＧｒｏｕｐ = "ＳＹＮＣ";
ｖｉｄｅｏＡｄ.ｍｅｄｉａＧｒｏｕｐ = "ＳＹＮＣ";
＜／ｓｃｒｉｐｔ＞

広告コンテンツのセグメントの追加処理は図１７に示したフローは重畳表示でもほぼ、同じである。重畳表示ではアプリケーションは放送データのメディアソースではなく、ネットワークのメディアソース（ｍｅｄｉａＳｏｕｒｃｅＡｄ）のソースバッファ（ａｕｄｉｏＳｏｕｒｃｅＢｕｆｆｅｒＡｄ、ｖｉｄｅｏＳｏｕｒｃｅＢｕｆｆｅｒＡｄ）にネットワークから受信した広告のセグメントデータを広告開始時間の位置に挿入するのが違いである。

同じＭｅｄｉａＧｒｏｕｐプロパティーの値を持つビデオオブジェクトのＣｕｒｒｅｎｔＴｉｍｅは同期して進行し、同期しているいずれかのＭｅｄｉａＳｏｕｒｃｅに再生位置のセグメントデータが格納されていた場合はＣｕｒｒｅｎｔＴｉｍｅが更新され再生が継続するものとする。この場合はＭｅｄｉａＳｏｕｒｃｅＡｄのソースバッファには広告区間の時間範囲のみセグメントデータを追加すれば良い。一方、ＭｅｄｉａＳｏｕｃｅｒを設定せずにＨＴＭＬ５ビデオの同期をとる場合には、お互いのＨＴＭＬ５ビデオ時間軸の同期時間のオフセット(例、ｖｉｄｅｏ.ｍｅｄｉａＧｒｏｕｐＴｉｍｅＯｆｆｓｅｔ)を設定するようにＨＴＭＬ５ビデオを拡張することで実現できる。

［１０．送信装置と受信装置の構成例について］
次に、通信装置である送信装置（サーバ）２０と、受信装置（クライアント）３０の装置構成例について、図１８、図１９を参照して説明する。

図１８には、送信装置（サーバ）２０と、受信装置（クライアント）３０の構成例を示している。
送信装置（サーバ）２０は、データ処理部７５１、通信部７５２、記憶部７５３を有する。
受信装置（クライアント）３０は、データ処理部７７１、通信部７７２、記憶部７７３、入力部７７４、出力部７７５を有する。
データ処理部には通信データ処理部７７１ａ、再生処理部７７１ｂが含まれる。

送信装置（サーバ）２０のデータ処理部７５１は、データ配信サービスを実行するための各種のデータ処理を実行する。例えばデータ配信サービスの構成データの生成や送信制御を行う。さらに、データ処理部７５１は、受信装置（クライアント）３０に提供するアプリケーション、サービスワーカー（ＳＷ）、その他の様々なデータや、シグナリングデータの生成、送信処理を行う。

通信部７５２は、ＡＶセグメントの他、アプリケーション、サービスワーカー（ＳＷ）、その他の様々なデータ、シグナリングデータ等の配信等の通信処理を行う。
記憶部７５３は配信対象とするＡＶセグメント、アプリケーション、サービスワーカー（ＳＷ）、アプリケーションによって利用されるデータ、シグナリングデータなどが格納される。
さらに、記憶部７５３は、データ処理部７５１の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。

一方、受信装置（クライアント）３０は、データ処理部７７１、通信部７７２、記憶部７７３、入力部７７４、出力部７７５を有する。
通信部７７２は、送信装置（サーバ）２０から配信されるデータ、例えばＡＶセグメントやアプリケーション、サービスワーカー（ＳＷ）、アプリケーションによって利用されるデータ、シグナリングデータ等を受信する。

データ処理部７７１は、通信データ処理部７７１ａ、再生処理部７７１ｂを有し、例えば先に説明した実施例に従った処理等を実行する。
具体的には、アプリケーションや、ＡＰＩ、さらに、サービスワーカー（ＳＷ）を利用したデータ処理等を実行する。

ユーザの指示コマンド、例えばチャンネル選択、アプリケーション起動、インストール等の様々なコマンドは入力部７７４を介して入力される。
再生データは表示部やスピーカ等の出力部７７５に出力される。
記憶部７７３はＡＶセグメント、サービスワーカー（ＳＷ）、アプリケーション、アプリケーションによって利用されるデータ、シグナリングデータなどが格納される。
さらに、記憶部７７３は、データ処理部７７１の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。

図１９は、送信装置２０、受信装置３０として適用可能な通信装置のハードウェア構成例を示している。

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）８０１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）８０２、または記憶部８０８に記憶されているプログラムに従って各種の処理を実行するデータ処理部として機能する。例えば、上述した実施例において説明したシーケンスに従った処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）８０３には、ＣＰＵ８０１が実行するプログラムやデータなどが記憶される。これらのＣＰＵ８０１、ＲＯＭ８０２、およびＲＡＭ８０３は、バス８０４により相互に接続されている。

ＣＰＵ８０１はバス８０４を介して入出力インタフェース８０５に接続され、入出力インタフェース８０５には、各種スイッチ、キーボード、マウス、マイクロホンなどよりなる入力部８０６、ディスプレイ、スピーカなどよりなる出力部８０７が接続されている。ＣＰＵ８０１は、入力部８０６から入力される指令に対応して各種の処理を実行し、処理結果を例えば出力部８０７に出力する。

入出力インタフェース８０５に接続されている記憶部８０８は、例えばハードディスク等からなり、ＣＰＵ８０１が実行するプログラムや各種のデータを記憶する。通信部８０９は、インターネットやローカルエリアネットワークなどのネットワークを介したデータ通信の送受信部、さらに放送波の送受信部として機能し、外部の装置と通信する。

入出力インタフェース８０５に接続されているドライブ８１０は、磁気ディスク、光ディスク、光磁気ディスク、あるいはメモリカード等の半導体メモリなどのリムーバブルメディア８１１を駆動し、データの記録あるいは読み取りを実行する。

なお、データの符号化あるいは復号は、データ処理部としてのＣＰＵ８０１の処理として実行可能であるが、符号化処理あるいは復号処理を実行するための専用ハードウェアとしてのコーデックを備えた構成としてもよい。

［１１．本開示の構成のまとめ］
以上、特定の実施例を参照しながら、本開示の実施例について詳解してきた。しかしながら、本開示の要旨を逸脱しない範囲で当業者が実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本開示の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。

なお、本明細書において開示した技術は、以下のような構成をとることができる。
（１） 受信装置の受信データのバッファ処理を、受信装置が実行するアプリケーションのメディア再生の処理オブジェクトであるメディアソースオブジェクトとして開示するデータ処理部を有する受信装置。

（２） 前記データ処理部は、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を適用して、前記受信データを前記メディアソースオブジェクトに設定し、アプリケーションが前記バッファの状態の取得やバッファに格納されている受信データの置き換え、または追加の処理を実行する（１）に記載の受信装置。

（３） 前記データ処理部は、前記アプリケーションによる処理時間を規定するアプリケーションのメディア再生時間軸と、前記受信データにおいて利用される映像音声再生時間軸の時間差に相当する時間オフセットを取得する（１）または（２）に記載の受信装置。

（４） 前記データ処理部は、前記アプリケーション、または前記ＡＰＩの適用処理により、前記時間オフセットを取得する（３）に記載の受信装置。

（５） 前記アプリケーションは、
前記メディアソースオブジェクトに対する処理として、前記データ処理部に格納された受信データと、アプリケーション受信データとの合成処理を実行する（１）〜（４）いずれかに記載の受信装置。

（６） 前記アプリケーションは、
前記アプリケーションによる処理時間を規定するアプリケーションメディア再生時間軸と、前記受信データにおいて利用される映像音声再生時間軸の時間差に相当する時間オフセットを取得し、取得した時間オフセットを利用して、前記受信データに対する前記アプリケーションが受信したデータの挿入時間位置を決定する（５）に記載の受信装置。

（７） 前記アプリケーションは、
前記時間オフセットを利用して、前記アプリケーション受信データの受信開始時間を決定する（６）に記載の受信装置。

（８） 前記アプリケーションは、
前記受信データを構成するセグメントを、前記アプリケーション受信データを構成するセグメントに置き換えるセグメント置換処理を実行する（５）〜（７）いずれかに記載の受信装置。

（９） 受信装置において利用されるアプリケーションを送信する通信部を有し、
前記アプリケーションは、受信装置における受信データのバッファ処理を開示するメディアソースオブジェクトを利用して、受信データとアプリケーションの受信データとの合成処理を実行させるアプリケーションである送信装置。

（１０） 前記アプリケーションを実行する受信装置は、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を適用して、前記受信データを前記メディアソースオブジェクトに設定する処理を実行し、
前記アプリケーションは、前記ＡＰＩによって設定されたメディアソースオブジェクトを利用した処理を実行するアプリケーションである（９）に記載の送信装置。

（１１） 受信装置において実行するデータ処理方法であり、
前記受信装置のデータ処理部が、受信データを受信装置が実行するアプリケーションのメディア再生の処理オブジェクトであるメディアソースオブジェクトに設定するデータ処理方法。

（１２） 送信装置において実行するデータ処理方法であり、
送信装置の通信部が、受信装置において利用されるアプリケーションを送信し、
前記アプリケーションは、受信装置における受信データのバッファ処理を開示するメディアソースオブジェクトを利用して、受信データとアプリケーションの受信データとの合成処理を実行させるアプリケーションであるデータ処理方法。

また、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。例えば、プログラムは記録媒体に予め記録しておくことができる。記録媒体からコンピュータにインストールする他、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介してプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。
また、実施例においては放送からブロードバンド受信した番組コンテンツのセグメントにネットワークから受信した広告コンテンツのセグメントで置き換えることを示したが、受信経路については限定するものではなく、番組コンテンツ、広告コンテンツの双方をネットワーク経由で受信する場合は、もしくは、双方を放送経由で受信する場合でも適応することが可能である。

なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

以上、説明したように、本開示の一実施例の構成によれば、放送受信データとネットワーク受信データの合成処理を効率的に実行する装置、方法が実現される。
具体的には、例えば受信装置が通信部を介して受信する放送受信データを、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を適用して、受信装置の実行するアプリケーションの処理オブジェクトであるメディアソースオブジェクトに設定する。アプリケーションは、メディアソースオブジェクトに対する処理として、前記放送受信データと、ネットワークを介して受信するネットワーク受信データとの合成処理を実行する。アプリケーションは、ＡＰＩ適用処理によってアプリケーション時間軸と放送時間軸の時間差に相当する時間オフセットを取得し、高精度、低遅延のデータ合成処理を実行する。
本構成により、放送受信データとネットワーク受信データの合成処理および出力処理を低遅延、高精度に行うことが可能となる。これにより放送された番組コンテンツに対してネットワークからの広告コンテンツを挿入することが容易となり、放送サービスとインターネットサービスの融合が進むことが期待される。

１０ 通信システム
２０ 送信装置
２１ 放送サーバ
２２ データ配信サーバ
３０ 受信装置
３１ ＴＶ
３２ ＰＣ
３３ 携帯端末
５０ シグナリングデータ
６０ ＡＶセグメント
７０ その他のデータ
９０ 受信装置内表示制御部
９１ 表示処理部
９２ サービスワーカー（ＳＷ）
９３ キャッシュ
９５，９６ Ｗｅｂページ
１０１ 高ビットレートデータ
１０２ 中ビットレートデータ
１０３ 低ビットレートデータ
１０４ マニフェスト・ファイル
１０５ 再生データ
１１０ メディアソース
１１１〜１１３ ソースバッファ
１１４ トラックバッファ
１２５ 放送受信セグメント
１２６ ネットワーク受信セグメント
１２７ 再生セグメント
１３１ アンテナ
１３２ 通信部（チューナー）
１３３ ＨＴＴＰサーバ
１３４ 画像デコーダ
１３５ 画像表示部
１３６ 音声デコーダ
１３７ 音声出力部
１４０ ブラウザ
１４１ ＸＨＲ
１４２ アプリケーション
１４３ メディアソース
１４４，１４５ ソースバッファ
２０１ アンテナ
２０２ 通信部（チューナー）
２１０ ブラウザ
２１２ アプリケーション
２１３ メディアソース
２１４，２１５ ソースバッファ
２２１ 画像デコーダ
２２２ 画像表示部
２２３ 音声デコーダ
２２４ 音声出力部
２２５ 再生セグメント
３１０ 放送受信データ処理部
３１１ チューナー
３１２ 記憶部（バッファ）
３１３ デコーダ＆レンダラー
３２１ メタデータ（シグナリング）処理部
３２２ バッファ管理部
３３０ ネットワーク受信データ処理部
３３１ ネットワークＩ／Ｆ
３３２ アプリケーション実行部
３３３ グラフィックシステム
３４１ 合成部
７５１ データ処理部
７５２ 通信部
７５３ 記憶部
７７１ データ処理部
７７２ 通信部
７７３ 記憶部
７７４ 入力部
７７５ 出力部
８０１ ＣＰＵ
８０２ ＲＯＭ
８０３ ＲＡＭ
８０４ バス
８０５ 入出力インタフェース
８０６ 入力部
８０７ 出力部
８０８ 記憶部
８０９ 通信部
８１０ ドライブ
８１１ リムーバブルメディア

Claims (12)

1. 受信装置の受信データを、受信装置が実行するアプリケーションの読み込み処理を経ずに、前記アプリケーションのメディア再生の処理オブジェクトであるメディアソースオブジェクトとして設定するデータ処理部を有する受信装置。
2. 前記データ処理部は、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を適用して、前記受信データを前記メディアソースオブジェクトに設定し、アプリケーションは、前記受信データが記憶されたバッファの状態の取得やバッファに格納されている受信データの置き換え、または追加の処理を実行する請求項１に記載の受信装置。
3. 前記データ処理部は、前記アプリケーションによる処理時間を規定するアプリケーションのメディア再生時間軸と、前記受信データにおいて利用される映像音声再生時間軸の時間差に相当する時間オフセットを取得する請求項１に記載の受信装置。
4. 前記アプリケーションは、
   前記メディアソースオブジェクトに対する処理として、前記データ処理部に格納された受信データと、アプリケーション受信データとの合成処理を実行する請求項１に記載の受信装置。
5. 前記受信データは放送コンテンツデータであり、
   前記アプリケーション受信データは通信コンテンツデータであり、
   前記データ処理部は、前記通信コンテンツデータの属性情報を記述したマニフェスト・ファイルを受信し、
   前記アプリケーションは、前記放送コンテンツデータに連動して起動され、前記マニフェスト・ファイルに基づいて、前記通信コンテンツデータをセグメント単位で受信する請求項４に記載の受信装置。
6. 前記アプリケーションは、
   前記アプリケーションによる処理時間を規定するアプリケーションメディア再生時間軸と、前記受信データにおいて利用される映像音声再生時間軸の時間差に相当する時間オフセットを取得し、取得した時間オフセットを利用して、前記受信データに対する前記アプリケーションが受信したデータの挿入時間位置を決定する請求項４に記載の受信装置。
7. 前記アプリケーションは、
   前記時間オフセットを利用して、前記アプリケーション受信データの受信開始時間を決定する請求項６に記載の受信装置。
8. 前記アプリケーションは、
   前記受信データを構成するセグメントを、前記アプリケーション受信データを構成するセグメントに置き換えるセグメント置換処理を実行する請求項４に記載の受信装置。
9. 受信装置において利用されるアプリケーションの読み込み処理を経ずに設定された、受信装置における受信データのメディアソースオブジェクトを利用して、前記受信データとアプリケーションの受信データとの合成処理を実行させるアプリケーションを生成し、
   前記アプリケーションを送信するデータ処理部を有する送信装置。
10. 前記データ処理部は、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を適用して、前記受信データを前記メディアソースオブジェクトに設定する処理を実行し、
    前記アプリケーションは、前記ＡＰＩによって設定されたメディアソースオブジェクトを利用した処理を実行するアプリケーションである請求項９に記載の送信装置。
11. 受信装置において実行するデータ処理方法であり、
    前記受信装置のデータ処理部が、受信データを受信装置が実行するアプリケーションの読み込み処理を経ずに、前記アプリケーションのメディア再生の処理オブジェクトであるメディアソースオブジェクトとして設定するデータ処理方法。
12. 送信装置において実行するデータ処理方法であり、
    受信装置において利用されるアプリケーションの読み込み処理を経ずに設定された、受信装置における受信データのメディアソースオブジェクトを利用して、前記受信データとアプリケーションの受信データとの合成処理を実行させるアプリケーションを生成し、
    前記アプリケーションを送信するデータ処理方法。

Images