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

Description

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

放送局やコンテンツサーバ等、コンテンツを提供する送信装置から、テレビ、ＰＣ、携帯端末等の受信装置に対して、放送波等による一方向通信、あるいは、インターネット等のネットワークを介した双方向通信、一方向通信によって、放送番組等のコンテンツを送受信するシステムについての開発や規格化が、現在、盛んに進められている。
なお、放送波およびネットワークを介したデータ配信を実現するための技術を開示した従来技術して。例えば特許文献１（特開２０１４−０５７２２７号公報）がある。

放送波およびネットワークを介したデータ配信システムに関する規格の１つとしてＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍ Ｃｏｍｍｉｔｔｅ）３．０の規格化が進められている。
ＡＴＳＣ３．０では、ダウンロード型のアプリケーション配信管理用のパッケージング方式、ならびに、オフラインのアプリケーション登録・更新管理方式がまだ検討段階にある。

一方、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）利用技術の国際的標準化団体であるＷ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）は、クライアントにおける便利なアプリケーションの利用を実現するために利用する制御プログラム等からなるサービスワーカー（ＳＷ：Ｓｅｒｖｉｃｅ Ｗｏｒｋｅｒ）の仕様を策定中である。

このサービスワーカー（ＳＷ）のフレームワークを、放送コンテンツの受信装置であるクライアントにおいて有効な利用を実現するためには、放送配信されるアプリケーションパーツや、サービスワーカー（ＳＷ）自体の配信管理を効果的に実装できるようにすることが課題となる。

特開２０１４−０５７２２７号公報

本開示は、上述したサービスワーカー（ＳＷ）のフレームワークを、放送コンテンツの受信装置であるクライアントにおいて有効な利用を実現する受信装置、送信装置、およびデータ処理方法を提供することを目的とする。
サービスワーカー（ＳＷ）は、受信装置において利用するリソース（アプリケーションや動画、静止画、音声等の様々なデータファイル）の管理、具体的には、リソースの取得、更新、削除処理等を実行する。

しかし、これらの管理対象リソースや、サービスワーカー（ＳＷ）自身の更新処理を行なう場合の具体的な仕様が規定されていない。
本開示は、この問題点に鑑みてなされたものであり、サービスワーカー（ＳＷ）おや、その管理リソースの確実な更新を可能とする受信装置、送信装置、およびデータ処理方法を提供することを目的とする。

本開示の第１の側面は、
受信装置の格納データに関するデータ管理プログラムであるサービスワーカー（ＳＷ）に関する情報を格納したテーブルであり、個別のサービスワーカー（ＳＷ）単位の更新処理情報を含むサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）を受信し、受信したＳＷＩＴを利用したデータ管理処理を実行するデータ処理部を有する受信装置にある。

さらに、本開示の第２の側面は、
受信装置の格納データに関するデータ管理プログラムであるサービスワーカー（ＳＷ）に関する情報を格納したテーブルであり、個別のサービスワーカー（ＳＷ）単位の更新処理情報を含むサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）を送信する送信装置にある。

さらに、本開示の第３の側面は、
受信装置において実行するデータ処理方法であり、
受信装置のデータ処理部が、
格納データに関するデータ管理プログラムであるサービスワーカー（ＳＷ）に関する情報を格納したテーブルであり、個別のサービスワーカー（ＳＷ）単位の更新処理情報を含むサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）を受信し、受信したＳＷＩＴを利用したデータ管理処理を実行するデータ処理方法にある。

さらに、本開示の第４の側面は、
送信装置において実行するデータ処理方法であり、
受信装置の格納データに関するデータ管理プログラムであるサービスワーカー（ＳＷ）に関する情報を格納したテーブルであり、個別のサービスワーカー（ＳＷ）単位の更新処理情報を含むサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）を送信するデータ処理方法にある。

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

本開示の一実施例の構成によれば、受信装置におけるデータ管理プログラムであるサービスワーカー（ＳＷ）やその管理リソースの更新処理を効率的に確実に実行する装置、方法が実現される。
具体的には、例えば、受信装置の格納データに関するデータ管理プログラムであるサービスワーカー（ＳＷ）に関する情報を格納したテーブルであり、個別のＳＷ単位の更新処理情報を含むサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）を受信し、受信したＳＷＩＴを利用したデータ管理処理を実行する。ＳＷＩＴは、ＳＷ識別子と、ＳＷ識別子によって特定されるＳＷおよび管理リソースに関する更新情報を記録したテーブルであり、受信装置は、ＳＷＩＴを参照して、ＳＷおよび管理リソースの更新処理を実行する。
本構成により、受信装置におけるデータ管理プログラムであるサービスワーカー（ＳＷ）やその管理リソースの更新処理を効率的に確実に実行する装置、方法が実現される。
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。

本開示の処理を実行する通信システムの一構成例について説明する図である。 送信装置の送信データについて説明する図である。 送信装置および受信装置のプロトコルスタックの例を示す図である。 シグナリングデータの構成例について説明する図である。 サービスワーカー（ＳＷ）を利用した処理の具体例（ユースケース）について説明する図である。 サービスワーカー（ＳＷ）を利用した処理の具体例（ユースケース）について説明する図である。 サービスワーカー（ＳＷ）を利用した処理の一例を説明する図である。 受信装置の構成例について説明する図である。 サービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）のデータ構成例について説明する図である。 受信装置において実行する処理の処理シーケンスについて説明する図である。 受信装置において実行する処理の処理シーケンスについて説明する図である。 通信装置である送信装置と受信装置の構成例について説明する図である。 通信装置である送信装置と受信装置のハードウェア構成例について説明する図である。

以下、図面を参照しながら本開示の受信装置、送信装置、およびデータ処理方法の詳細について説明する。なお、説明は以下の項目に従って行なう。
１．通信システムの構成例について
２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて
３．送信装置と受信装置の実行する通信処理例について
４．シグナリングデータの詳細について
５．サービスワーカー（ＳＷ）について
６．受信装置の構成例と処理について
７．サービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）の構成例について
８．サービスワーカー（ＳＷ）およびアプリケーションの利用処理シーケンスについて
８−１．処理フェーズ１の処理シーケンスについて
８−２．処理フェーズ２の処理シーケンスについて
８−３．処理フェーズ３の処理シーケンスについて
９．送信装置と受信装置の構成例について
１０．本開示の構成のまとめ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

［４．シグナリングデータの詳細について］
シグナリングデータは、受信装置（クライアント）が受信、再生するＡＶセグメントのアクセス情報や、復号処理等の受信後の処理に必要となる案内情報や制御情報を含むデータであり、送信装置から随時繰り返し送信されるデータである。

シグナリングデータに含まれるＳＣＳ（Ｓｅｒｖｉｃｅ Ｃｈａｎｎｅｌ Ｓｉｇｎａｌｉｎｇ）の詳細構成について図４を参照して説明する。
ＳＣＳは、サービスチャンネルシグナリング（Ｓｅｒｖｉｃｅ Ｃｈａｎｎｅｌ Ｓｉｇｎａｌｉｎｇ）であり、ユーザに提供されるコンテンツに対応する案内情報、制御情報が含まれる。

なお、ＳＣＳは、様々な情報単位の複数のシグナリングデータを含む。
具体的には、ＳＣＳは、サービス単位のシグナリングデータであるＵＳＤ（ユーザサービスデスクリプション）を含む。
さらに、ＵＳＤは、配信メソッドに関する情報を格納した以下の３種類のシグナリングデータを含む。
ＳＤＰ（セッションディスクリプション）
ＦＤＤ（ファイルデリバリディスクリプション）
ＲＦＤ（リペアフローディスクリプション）
さらに、ＵＳＤは、コンテンツ（ＡＶセグメント）に対応する様々な案内情報、制御情報を格納したマニフェスト・ファイルを持つシグナリングデータとして、
ＭＰＤ（メディアプレゼンテーションディスクリプション）
を含む。

これらの各種のシグナリングデータは、それぞれ受信装置（クライアント）において、送信装置から送信されるＡＶセグメントを受信し再生するために必要となるデータであり、基本的には、カテゴリ別に個別のファイル（メタファイル）として設定され、送信装置から送信される。
なお、図４に示すシグナリングデータは一例であり、この他のシグナリングデータも存在し得る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

［６．受信装置の構成例と処理について］
上述したように、受信装置３０は、サービスワーカー（ＳＷ）を利用して、任意のタイミングで、例えば図５、図６を参照して説明したような天気情報表示アプリケーション等のアプリケーション、すなわちサービスワーカ（ＳＷ）の管理対象てあるアプリケーションを実行することが可能となる。
受信装置３０側のユーザは、任意タイミングでアプリケーションを実行することで、天気情報表示ページや、様々なＷｅｂページをいつでも閲覧することが可能となる。

サービスワーカー（ＳＷ）を受信し、利用する受信装置３０の構成例について、図８を参照して説明する。
受信装置３０は、図８に示すように、各種のデータ処理を実行するデータ処理部１５１、放送波を受信し復調処理を行なう通信部１５２、さらに、ネットワークを介した通信処理を実行する通信部としてのネットワークＩ／Ｆ１５３を有する。

受信装置３０のデータ処理部１５１は、パケット分離部（Ｄｅｍｕｌｔｉｐｌｅｘｅｒ）１７１、画像データ処理部１７２、音声データ処理部１７３、システム制御部１７４、アプリケーション制御部１７５、キャッシュ部１７６、サービスワーカー（ＳＷ）制御部１７７、ミドルウェア（ＭＷ）キャッシュ部１７８、記憶部（永続キャッシュ部）１７９、出力制御部１８０、合成処理部１８１を有する。

放送サーバ２１から送信される放送信号は、通信部１５２によって受信され復調されたパケット分離部１７１に入力される。
パケット分離部１７１は、通信部１５２を介して受信するパケットのパケット識別子（ＰＩＤ）に基づいて受信パケットをデータ種別（画像、音声、制御信号等）ごとに分離して、分離した各パケットを各データ処理部に供給する。

画像データ処理部１７２は、画像データを格納したパケットから画像データを取得し、復号処理等、画像の再生処理に必要な処理を実行する。
音声データ処理部１７３は、音声データを格納したパケットから音声データを取得し、復号処理等、音声の再生処理に必要な処理を実行する。

システム制御部１７４は、各種の制御信号、すなわちシグナリングデータを含むパケットを入力し、パケットからシグナリングデータを取得して、データ処理部１５１内の構成部に制御信号を出力してデータ処理の全体的なむ制御を実行する。

アプリケーション制御部１７５は、シグナリングデータの一部のデータ、具体的には、アプリケーションに対する制御データを格納したＡＩＴ（アプリケーション・インフォメーション・テーブル）や、サービスワーカー（ＳＷ）に対する制御データを格納したＳＷＩＴ（サービスワーカー・インフォメーション・テーブル）等を入力し、受信装置３０において実行するアプリケーションや、サービスワーカー（ＳＷ）の制御を実行する。

アプリケーション制御部１７５は、ＡＩＴ（アプリケーション・インフォメーション・テーブル）や、ＳＷＩＴ（サービスワーカー・インフォメーション・テーブル）を適用して、出力制御部１８０で実行するアプリケーション、サービスワーカー（ＳＷ）の実行制御を行う。
また、サービスワーカー（ＳＷ）に対する制御データを格納したＳＷＩＴ（サービスワーカー・インフォメーション・テーブル）は、サービスワーカー（ＳＷ）制御部１７７に入力される。

サービスワーカー（ＳＷ）制御部１７７は、ＳＷＩＴ（サービスワーカー・インフォメーション・テーブル）を用いて、サービスワーカー（ＳＷ）の制御、例えば更新制御等を実行する。
サービスワーカー（ＳＷ）制御部１７７は、ネットワークを介して入力するアプリケーション、サービスワーカー（ＳＷ）、リソース等を一時的に格納するミドルウェア（ＭＷ）キャッシュ１７８や、アプリケーション、サービスワーカー（ＳＷ）、およびサービスワーカー（ＳＷ）の管理対象データであるリソース等を永続的に格納する記憶部（永続キャッシュ）１７８をアクセスし、これらの各キャッシュに格納されたデータの更新処理を実行する。

キャッシュ部１７６は、放送サーバ２１から送信されるアプリケーションや、サービスワーカー（ＳＷ）、さらにサービスワーカー（ＳＷ）の管理対象となる各首のリソースデータを入力する。
これらのデータは、キャッシュ部１７６を介してブラウザ等を実行する出力制御部１８０に入力され、利用される。すなわち、アプリケーションの実行、サービスワーカー（ＳＷ）の適用処理等が行われる。

なお、出力制御部１８０は、記憶部（永続キャッシュ）１７９に対して、アプリケーション、サービスワーカー（ＳＷ）、リソースを格納し、これらをいつでも利用することが可能である。

ネットワークインタフェース１５３は、データ配信サーバ２２との通信を実行し、データ配信サーバ２２の提供するアプリケーション、サービスワーカー（ＳＷ）、リソースを受信し、出力制御部１８０に出力、あるいはミドルウェアキャッシュ部１７８に格納する。

出力制御部１８０は、放送サーバ２１から放送を介して、またはデータ配信サーバ２２からネットワークを介して入力するアプリケーション、サービスワーカー（ＳＷ）、リソースを利用した処理、具体的にはアプリケーションの実行処理等を行う。
出力制御部１８０の生成した出力データは、合成処理部１８１を介して、例えば放送番組等と合成され出力される。

［７．サービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）の構成例について］
次に、送信装置２０から受信装置３０に提供されるサービスワーカー（ＳＷ）に関する制御情報を記録したサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）の構成例について図９を参照して説明する。

サービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）は、例えば、図９に示す各情報を登録したテーブルである。
以下、テーブル記録情報について、順次、説明する。
（１）＠ｕｒｌ：ＳＷＩＴを再取得するためのアクセス情報（ＵＲＬ）。
（２）ａｐｐ：このＳＷＩＴに対応付けられたサービスワーカー（ＳＷ）に関連付けられたアプリケーション（＝サービスワーカー（ＳＷ）管理リソースとしてのアプリケーション）。
複数ある場合は、（２）ａｐｐ以下の項目が、複数設定される。

（３）＠ａｐｐｌｉｃａｔｉｏｎｉｄ：このＳＷＩＴに対応付けられたＡＩＴ（アプリケーション・インフォメーション・テーブル）に記録されているアプリケーションの識別子（アプリケーションＩＤ）。
（４）ｓｗ：このＳＷＩＴによる管理対称となるサービスワーカー（ＳＷ）。
複数ある場合は、（４）ｓｗ以下の項目が、複数設定される。

（５）＠ｓｗＮａｍｅ：（４）に規定されたサービスワーカー（ＳＷ）のサービスワーカー名。
（６）＠ｖｅｒｓｉｏｎ：（４）に規定されたサービスワーカー（ＳＷ）のバージョン（更新されるとバージョンが変更される）。
（７）＠ｕｒｌ：（４）に規定されたサービスワーカー（ＳＷ）の更新サービスワーカー（ＳＷ）を取得する際のアクセス情報（ＵＲＬ）。
（８）＠ｇｐｉｄ：（４）に規定されたサービスワーカー（ＳＷ）の更新サービスワーカー（ＳＷ）の属する更新グループの識別子（更新グループＩＤ）。

（９）ｒｅｓｏｕｃｅＬｉｓｔ：このＳＷＩＴに対応付けられたサービスワーカー（ＳＷ）の管理対象となるリソース（キャッシュ対象リソース）のリスト。
（１０）ｒｅｓｏｕｒｃｅ：このＳＷＩＴに対応付けられたサービスワーカー（ＳＷ）の管理対象となるリソース
複数ある場合は、（１０）ｒｅｓｏｕｒｃｅ以下の項目が、複数設定される。
（１１）＠ｇｐｉｄ：（１０）に規定されたリソースの属する更新グループの識別子（更新グループＩＤ）。（指定なしの場合は更新なしを示す）
（１２）ｕｒｌ：（１０）に規定されたリソース（更新リソース）を取得する際のアクセス情報（ＵＲＬ）。
（１３）ｖｅｒｓｉｏｎ：（１０）に規定されたリソースのバージョン。

（１４）ｕｐｄａｔｅＳｃｈｅｄｕｌｅ：（４）に規定されたサービスワーカー（ＳＷ）の更新スケジュール情報。
（１５）ｕｐｄａｔｅＧｐ：同一の更新スケジュールを持つサービスワーカー（ＳＷ）およびリソースのグループ（更新グループ）
複数ある場合は、（１５）ｕｐｄａｔｅＧｐ以下の項目が、複数設定される。

（１６）＠ｇｐｉｄ：（１５）に規定された更新グループの識別子（更新グループＩＤ）。
（１７）ｓｃｅｄｕｌｅ：（１５）に規定された更新グループの更新スケジュール情報（詳細情報は（１８），または（１９）に記録）
（１８）＠ｎｅｘｔＵｐｄａｔｅ：（１５）に規定された更新グループの更新スケジュール情報としての次回更新日時。
（１９）＠ｕｐｄａｔｅＤｕｒａｔｉｏｎ：（１５）に規定された更新グループの更新スケジュール情報としての更新頻度情報（例えば、１：１０分、２：１時間、３：３時間、４：６時間、５：１２時間、６：１日、７：１週間、８：１か月）。

サービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）には、例えば、図９に示す、これらの情報が記録される。

［８．サービスワーカー（ＳＷ）およびアプリケーションの利用処理シーケンスについて］
次に、図１０〜図１１を参照して、受信装置３０におけるサービスワーカー（ＳＷ）およびアプリケーションの利用処理シーケンスについて説明する。
図１０〜図１１は、左から右に流れる時間軸に従った処理を説明する図であり、以下の各要素各々の処理と、各要素間のデータの流れを示している。
（１）放送信号（画像（Ｖｉｄｅｏ），音声（Ａｕｄｉｏ），ＮＲＴ，ＳＣＳ）
（２）サービスワーカー（ＳＷ）サーバ
（３）アプリケーション制御部
（４）サービスワーカー（ＳＷ）制御部
（５）出力制御部（ブラウザ）

（１）放送信号は、放送サーバ２１が放送波を介して出力する信号である。例えば番組コンテンツを構成する画像（Ｖｉｄｅｏ），音声（Ａｕｄｉｏ）信号、さらに、アプリケーションやサービスワーカー（ＳＷ）等のファイルに相当するＮＲＴ（ノンリアルタイムコンテンツ），さらに、シグナリングデータとしてのＳＣＳが放送波を介して、継続的に送信されている。
ＳＣＳは、先に図４を参照して説明したように、サービスチャンネルシグナリング（Ｓｅｒｖｉｃｅ Ｃｈａｎｎｅｌ Ｓｉｇｎａｌｉｎｇ）であり、ユーザに提供されるコンテンツに対応する案内情報、制御情報が含まれる。

（２）サービスワーカー（ＳＷ）サーバは、例えば図１に示すデータ配信サーバ２２に相当する。サービスワーカー（ＳＷ）の送信処理を実行する。
なお、以下に説明する例では、サービスワーカー（ＳＷ）サーバは、サービスワーカー（ＳＷ）を送信するサーバとして説明するが、その他、アプリケーションや、サービスワーカーの管理データとしてのリソースを提供する構成としてもよい。

（３）アプリケーション制御部、（４）サービスワーカー（ＳＷ）更新制御部、（５）出力制御部（ブラウザ）、これらは、図４を参照して説明した受信装置３０のデータ処理部１５１内の構成部である。
（３）アプリケーション制御部は、図４に示すアプリケーション制御部１７５に相当する。
（４）サービスワーカー（ＳＷ）制御部は、図４に示すサービスワーカー（ＳＷ）制御部１７７に相当する。
（５）出力制御部（ブラウザ）は、図４に示す出力制御部（ブラウザ）１８０に相当する。

図１０〜図１１において、時間は、左から右に経過する。
以下、時間経過に従った処理として、
処理フェーズ１〜３の各フェーズの処理について説明する。

［８−１．処理フェーズ１の処理シーケンスについて］
処理フェーズ１は、受信装置３０放送信号からアプリケーションとサービスワーカー（ＳＷ）を取得して、これらを用いた処理を実行して、サービスワーカー（ＳＷ）と、リソースを記憶部（永続キャッシュ）に格納するまでの処理を実行するフェーズである。
処理フェーズ１において実行されるステップＳ２０１〜Ｓ２１０の各処理について、順次、説明する。

（ステップＳ２０１）
受信装置３０のアプリケーション制御部１７５は、放送信号のシグナリングデータであるＳＣＳ（サービスチャンネルシグナリング）から、アプリケーション用の制御情報格納テーブルであるＡＩＴ（アプリケーション・インフォメーション・テーブル）と、サービスワーカ（ＳＷ）の制御情報格納テーブルであるＳＷＩＴ（サービスワーカー・インフォメーション・テーブル）を取得する。
図に示すＳＣＳ上の二重丸は、これらのテーブルをＳＣＳから取得していることを示す。
ＡＩＴには特定のアプリケーション（Ａｐｐ１）の取得情報（ＵＲＬ等）および起動処理（ａｕｔｏｓｔａｒｔ）情報が規定されている。

（ステップＳ２０２）
受信装置３０のアプリケーション制御部１７５は、ＡＩＴに記録されたアプリケーション（Ａｐｐ１）の取得情報（ＵＲＬ等）を利用して、放送信号中のＮＲＴ信号から、アプリケーション（Ａｐｐ１）を取得して、出力制御部（ブラウザ）１８０に出力する。
なお、アプリケーション制御部１７５は、、出力制御部（ブラウザ）１８０に出力したアプリケーション（Ａｐｐ１）に関連付けられたサービスワーカ（ＳＷ）の制御情報格納テーブルであるＳＷＩＴ（サービスワーカー・インフォメーション・テーブル）を保持しておく。
ＳＷＩＴ（サービスワーカー・インフォメーション・テーブル）については、図９を参照して説明した各データが記録されている。図９に示すように、ＳＷＩＴには、ＡＩＴのアプリケーションＩＤ（＠ａｐｐｌｉｃａｔｉｏｎＩｄ）が記録され、ＳＷＩＴと、ＡＩＴは対応付けられたテーブルとして設定されている。

なお、図１０においてステップＳ２０２のアプリケーション（Ａｐｐ１）の取得処理は、放送信号のＮＲＴから取得する設定として示しているが、データ配信サーバ２２から取得する構成としてもよい。

（ステップＳ２０３）
受信装置３０の出力制御部（ブラウザ）は、ステップＳ２０２において取得したアプリケーション（Ａｐｐ１）の実行処理を開始する。

（ステップＳ２０４）
アプリケーション（ａｐｐ１）の動作において、ユーザ操作、あるいはアプリケーションやアプリケーションに対応する番組コンテンツ内のトリガー情報等により、サービスワーカー（ＳＷ）の登録処理（ｉｎｓｔａｌｌ）が行われる。
具体的には、アプリケーション（ａｐｐ１）によって指定されるＵＲＬに基づいて、放送信号に含まれるＮＲＴ信号からサービスワーカー（ＳＷ１．ｊｓ）を取得する。
なお、ｊｓは、ＪａｖａＳｃｒｉｐｔ（登録商標）ファイルであることを意味する。

（ステップＳ２０５）
サービスワーカー（ＳＷ）は、登録（ｉｎｓｔａｌｌ）イベントにより、取得されるとすぐに起動し、実行される。
その後、以下のプロセス（ステップＳ２０６〜Ｓ２０９）を実行する。これらのプロセス（Ｓ２０６〜Ｓ２０９）は、サービスワーカー（ＳＷ１．ｊｓ）に記述されたプロセス情報に従って実行される。

（ステップＳ２０６）
受信装置３０のミドルウェアであるサービスワーカー制御部１７７に対して、処理対象とする特定のサービスワーカー（ＳＷ）のサービスワーカーファイル名（ＳＷ１．ｊｓ）、またはサービスワーカー識別子（ＳＷ＿ｉｄ）を指定してサービスワーカー（ＳＷ）更新処理起動ＡＰＩを実行する。

サービスワーカー制御部１７７は、サービスワーカーファイル名（ＳＷ１．ｊｓ）、またはサービスワーカー識別子（ＳＷ＿ｉｄ）によって特定される更新対象とする特定のサービスワーカー（ＳＷ）に対応する制御情報を、ＳＷＩＴから抽出する。
先に図９を参照して説明したように、ＳＷＩＴには、複数のサービスワーカー（ＳＷ）の制御情報が記録される場合があり、ここでは、処理対象となる１つのサービスワーカー（ｓｗ１．ｊｓ）に関する制御情報を抽出する。これをパーシャルＳＷＩＴ（ＰＳＷＩＴ：パーシャル・サービスワーカー・インフォメーション・テーブル）と呼ぶ。

例えば、図９に示すＳＷＩＴの（５）＠ｓｗＮａｍｅ：サービスワーカー名として、サービスワーカーファイル名（ＳＷ１．ｊｓ）の記録エントリを検出し、このエントリ（５）以下、このサービスワーカーファイル名（ＳＷ１．ｊｓ）に関する情報の記録領域（５）〜（１９）からなるデータをＰＳＷＩＴとして抽出する。

なお、例えば、このＰＳＷＩＴには、例えば以下の情報が記録されている。
（６）＠ｖｅｒｓｉｏｎ：実行中のサービスワーカー（ｓｗ１．ｊｓ）のバージョン
（７）＠ｕｒｌ：サービスワーカー（ｓｗ１．ｊｓ）の更新サービスワーカー（ＳＷ）を取得する際のアクセス情報（ＵＲＬ）。
（８）＠ｇｐｉｄ：サービスワーカー（ｓｗ１．ｊｓ）の更新サービスワーカー（ＳＷ）の属する更新グループの識別子（更新グループＩＤ）。

さらに、（９）〜（１２）には、サービスワーカー（ｓｗ１．ｊｓ）の管理リソースであるキャッシュ対象リソースのリスト、リストされたリソース各々の情報としてのアクセス情報（ＵＲＬ）、更新グループＩＤ、バージョン情報が記録されている。
さらに、（１３）〜（１９）には、リソースリストにリストアップされたリソースに関する更新スケジュールに関する情報が更新グループ単位で記録されている。

サービスワーカー（ＳＷ）制御部１７７は、このＰＳＷＩＴに記録された情報に基づいて、取得すべきキャッシュリソースを決定して、以下に説明するステップＳ２０８でキャッシュリソースの取得を実行する。

（ステップＳ２０７）
サービスワーカー制御部１７７は、ＰＳＷＩＴ（パーシャルＳＷＩＴ）をミドルウェアキャッシュ部１７８に格納する。

（ステップＳ２０８）
サービスワーカー制御部１７７は、ＰＳＷＩＴ（パーシャルＳＷＩＴ）に記述されているサービスワーカー（ｓｗ１．ｊｓ）キャッシュ対象リソースを、ＮＲＴ信号から取得し、それぞれのバージョン情報と共に、ミドルウェアキャッシュ部１７８に格納する。
なお、リソースアクセス情報は、ＳＷＩＴ（サービスワーカー・インフォメーション・テーブル）の一部構成情報であり、処理対象であるサービスワーカー（ｓｗ１．ｊｓ）に関する情報のみからなるＰＳＷＩＴ（パーシャルＳＷＩＴ）から取得する。

図のステップＳ２０８の矢印の先の白マルはリソースを意味する、例として２つの白マルを示しているが、これは、取得リソースが複数、例えば１つのアプリケーションと１つの動画ファイル等によって構成されていることを示す。

（ステップＳ２０９）
サービスワーカー制御部１７７は、処理対象であるサービスワーカー（ｓｗ１．ｊｓ）の管理対象リソースの取得と、ミドルウェアキャッシュ部１７８に対する格納処理を完了すると、出力制御部１８０に対して、処理完了の通知を行う。すなわち、出力制御部１８０において実行中のサービスワーカー（ｓｗ１．ｊｓ）に対してリソースキャッシュ完了イベントを発行する。

（ステップＳ２１０〜Ｓ２１１）
出力制御部１８０において実行中のサービスワーカー（ｓｗ１．ｊｓ）は、上記のリソースキャッシュ完了イベントを受けて、まず、ＰＳＷＩＴ（パーシャルＳＷＩＴ）読み込みＡＰＩを実行して、実行中のサービスワーカー（ｓｗ１．ｊｓ）の管理対象であるサービスワーカー（ｓｗ１．ｊｓ）キャッシュ対象リソースリストを取得し、リストにあるリソースの取得処理を開始する。

これらのサービスワーカー（ｓｗ１．ｊｓ）キャッシュ対象リソースは、ステップＳ２０８において、すでにミドルウェアキャッシュ部１７８に格納されている。
出力制御部１８０は、ミドルウェアキャッシュ部１７８に格納されているリソースを取得して、記憶部（永続キャッシュ部）１７９に格納する。
これらの処理は、サービスワーカー（ｓｗ１．ｊｓ）に記録されたプロセス情報に従って実行される。

（ステップＳ２１２）
出力制御部１８０は、サービスワーカー（ｓｗ１．ｊｓ）キャッシュ対象リソースを記憶部（永続キャッシュ部）１７９に格納する処理を完了すると、サービスワーカー（ｓｗ１．ｊｓ）適用処理を終了し、サービスワーカー（ｓｗ１．ｊｓ）を記憶部（永続キャッシュ部）１７９に格納する。

ここまでの処理が処理フェーズ１の処理である。
処理フェーズ１の処理をまとめると以下のようになる。
（Ｓ２０１）アプリケーション制御部１７５が、ＳＣＳからＡＩＴ（アプリケーション・インフォメーション・テーブル）と、ＳＷＩＴ（サービスワーカー・インフォメーション・テーブル）を取得。
（Ｓ２０２〜Ｓ２０３）アプリケーション制御部１７５が、ＡＩＴの記録情報に従って、ＮＲＴから取得したアプリケーション（Ａｐｐ１）を出力制御部１８０において実行。
（Ｓ２０４〜Ｓ２０５）出力制御部１８０が、実行中のアプリケーション（Ａｐｐ１）の指定するサービスワーカー（ｓｗ１．ｊｓ）を取得して実行。

（Ｓ２０６〜Ｓ２０８）サービスワーカー制御部１７７が、出力制御部１８０で実行中のサービスワーカー（ｓｗ１．ｊｓ）に対応する制御情報をＳＷＩＴから抽出したＰＳＷＩＴ（パーシャルＳＷＩＴ）を取得し、ＰＳＷＩＴに記録されたキャッシャ対象リソースをＮＲＴから取得してミドルウェアキャッシュに格納。
（Ｓ２０９〜Ｓ２１２）出力制御部１８０が、ミドルウェアキャッシュに格納されたリソースを記憶部（永続キャッシュ）１７９に格納し、さらに、サービスワーカー（ｓｗ１．ｊｓ）を記憶部（永続キャッシュ）１７９に格納する。

これらの処理において、ステップＳ２０６〜Ｓ２０８におけるキャッシュリソースの取得処理は、前述したように、処理対象であるサービスワーカー（ｓｗ１．ｊｓ）に関する情報のみからなるＰＳＷＩＴ（パーシャルＳＷＩＴ）を参照して実行される。

［８−２．処理フェーズ２の処理シーケンスについて］
次に、ステップＳ２２１以降の処理フェーズ２の処理について説明する。
処理フェーズ２の処理は、処理フェーズ１において記憶部（永続キャッシュ部）１７６に格納したリソースやサービスワーカー（ＳＷ）の更新処理を行なうフェーズである。この更新処理は先に図９を参照して説明したＳＷＩＴ（サービスワーカー・インフォメーション・テーブル）を参照した処理として実行される。

ここでは、処理対象となるサービスワーカー（ｓｗ１．ｊｓ）に関する情報のみからなるＰＳＷＩＴ（パーシャルＳＷＩＴ）を参照した処理として実行される。
リソースやサービスワーカー（ＳＷ）の更新処理は、ＳＷＩＴ、またはＰＳＷＩＴに記録された更新スケジュール情報に従って実行される。
以下、各ステップの処理について説明する。

（ステップＳ２２１）
サービスワーカー（ＳＷ）制御部１７７は、ＰＳＷＩＴに記述される更新グループ毎の更新スケジュール情報に従って、サービスワーカー（ＳＷ）と、その管理対称データであるキャッシュ対象リソースの更新取得のスケジュール動作を行う。
スケジュール指定としては、次回更新日時を指定する方法と取得頻度を示す方法がある。次回更新日時を指定する場合には更新処理終了後にＰＳＷＩＴの再取得先（ネットワーク上）から最新のＰＳＷＩＴを取得して（バージョン確認の上）保持する。

上記いずれのスケジュール指定方法においてもサービスワーカー（ＳＷ）制御部１７７は、指定または算出される更新日時に更新取得先（ネットワーク上）から最新のサービスワーカー（ＳＷ）、またはキャッシュ対象リソースを取得し、（バージョンを確認した上）バージョン情報と共にミドルウェアキャッシュ部１７８に保持する。
ステップＳ２２１の処理は、ＰＳＷＩＴに記録されたスケジュールに従った更新リソース取得処理である。

なお、前述したように、ＰＳＷＩＴには、例えば以下の情報が記録されている。
（６）＠ｖｅｒｓｉｏｎ：実行中のサービスワーカー（ｓｗ１．ｊｓ）のバージョン
（７）＠ｕｒｌ：サービスワーカー（ｓｗ１．ｊｓ）の更新サービスワーカー（ＳＷ）を取得する際のアクセス情報（ＵＲＬ）。
（８）＠ｇｐｉｄ：サービスワーカー（ｓｗ１．ｊｓ）の更新サービスワーカー（ＳＷ）の属する更新グループの識別子（更新グループＩＤ）。

さらに、（９）〜（１２）には、サービスワーカー（ｓｗ１．ｊｓ）の管理リソースであるキャッシュ対象リソースのリスト、リストされたリソース各々の情報としてのアクセス情報（ＵＲＬ）、更新グループＩＤ、バージョン情報が記録されている。
さらに、（１３）〜（１９）には、リソースリストにリストアップされたリソースに関する更新スケジュールに関する情報が更新グループ単位で記録されている。

サービスワーカー（ＳＷ）制御部１７７は、このＰＳＷＩＴに記録された情報に基づいて、取得すべきキャッシュリソースを決定してキャッシュリソースの取得を実行する。
例えば、サービスワーカー（ＳＷ）識別子であるサービスワーカー名や、サービスワーカー（ＳＷ）のバージョン、さらに、リソース名、リソースのバージョン等を確認した上で、データ取得処理を実行する。

なお、取得するキャッシュリソースが更新リソースである場合、ＰＳＷＩＴに記録された更新スケジュール情報に従って、更新グループ単位でのデータ取得処理を行なうことが可能であり、効率的なリソース取得を行うことができる。
すなわち、ＳＷＩＴやＰＳＷＩＴを参照して、更新グループ識別子と、更新グループ対応の更新スケジュール情報を確認して、グループ単位のリソース更新処理を実行することができる。

（ステップＳ２２２）
サービスワーカー（ＳＷ）制御部１７７は、ステップＳ２２１における処理、すなわち、更新キャッシュ対象リソースを、バージョン情報と共にミドルウェアキャッシュ部１７８に格納する処理が完了すると、出力制御部（ブラウザ）１８０に対してリソースキャッシュイベントを発行する。

（ステップＳ２２３）
出力制御部（ブラウザ）１８０においてサービスワーカー（ｓｗ１．ｊｓ）は、上記のリソースキャッシュ完了イベントを受けると、次に、ＰＳＷＩＴ読み込みＡＰＩを実行して、サービスワーカー（ＳＷ）キャッシュ対象リソースリストを取得し、リストされたリソースを取得する処理を開始する。

これらのサービスワーカー（ｓｗ１．ｊｓ）キャッシュ対象リソースは、ステップＳ２２１において、すでにミドルウェアキャッシュ部１７８に格納されている。
出力制御部１８０は、ミドルウェアキャッシュ部１７８に格納されているリソースを取得して、記憶部（永続キャッシュ部）１７９に格納する。
これらの処理は、サービスワーカー（ｓｗ１．ｊｓ）に記録されたプロセス情報に従って実行される。

（ステップＳ２４１）
次に、サービスワーカー（ＳＷ）制御部１７７は、ＰＳＷＩＴに記述される更新グループ毎の更新スケジュール情報に従って、サービスワーカー（ＳＷ）の更新取得のスケジュール動作を行う。
スケジュール指定としては、次回更新日時を指定する方法と取得頻度を示す方法がある。次回更新日時を指定する場合には更新処理終了後にＰＳＷＩＴの再取得先（ネットワーク上）から最新のＰＳＷＩＴを取得して（バージョン確認の上）保持する。

上記いずれのスケジュール指定方法においてもサービスワーカー（ＳＷ）制御部１７７は、指定または算出される更新日時に更新取得先（ネットワーク上）から最新のサービスワーカー（ＳＷ）を取得し、（バージョンを確認した上）バージョン情報と共にミドルウェアキャッシュ部１７８に保持する。
ステップＳ２４１の処理は、ＰＳＷＩＴに記録されたスケジュールに従った更新サービスワーカー（ＳＷ）取得処理である。

サービスワーカー（ＳＷ）制御部１７７は、このＰＳＷＩＴに記録された情報に基づいて、取得すべきサービスワーカー（ＳＷ）を決定してサービスワーカー（ＳＷ）の取得を実行する。例えば、取得するサービスワーカー（ＳＷ）が更新ＳＷである場合、ＰＳＷＩＴに記録された更新スケジュール情報に従って、更新グループ単位でのデータ取得処理を行なうことが可能であり、効率的なサービスワーカー（ＳＷ）取得を行うことができる。
すなわち、ＳＷＩＴやＰＳＷＩＴを参照して、更新グループ識別子と、更新グループ対応の更新スケジュール情報を確認して、グループ単位のサービスワーカー（ＳＷ）更新処理を実行することができる。

（ステップＳ２４２）
サービスワーカー（ＳＷ）制御部１７７は、ステップＳ２４１における処理、すなわち、更新サービスワーカー（ＳＷ）を、バージョン情報と共にミドルウェアキャッシュ部１７８に格納する処理が完了すると、出力制御部（ブラウザ）１８０に対してサービスワーカー（ＳＷ）キャッシュ完了イベントを発行する。

（ステップＳ２４３）
出力制御部（ブラウザ）１８０は、上記のサービスワーカー（ＳＷ）キャッシュ完了イベントを受けると、該当するサヘビスワーカー（ＳＷ）の更新処理としての、再）登録処理（ｉｎｓｔａｌｌ）を実行する。この場合、結果として、ミドルウェアキャッシュ部１７８に保持された更新されたサービスワーカー（ＳＷ）ファイルが引き込まれて新たなサービスワーカー（ＳＷ）として記憶部（永続キャッシュ部）１７９に保持される。

なお、その後、この更新されたサービスワーカー（ＳＷ）に対応する管理リソースの再取得処理を行なう。
図に示すステップＳ２５１〜Ｓ２５４の処理である。
ステップＳ２５１が、更新されたサービスワーカーによるサービスワーカー制御部１７７に対する処理指示としてのイベント発行処理である。
その後のステップＳ２５２〜Ｓ２５４の処理は、先に説明したステップＳ２２１〜Ｓ２２３の処理と同様の処理となる。

なお、リソースや、サービスワーカー（ＳＷ）の記憶部（永続キャッシュ部）１７９に対する格納処理は、上述したキャッシュ完了イベントによる方法の他、サービスワーカー（ＳＷ）のタイマー処理や、無効化（ｅｘｐｉｒｅ）指定により、サービスワーカー（ＳＷ）に規定したプロセスに従って実行することも可能である。

ここまでの処理が処理フェーズ２の処理である。
処理フェーズ２の処理をまとめると以下のようになる。
（Ｓ２２１）サービスワーカー（ＳＷ）制御部１７７が、ＰＳＷＩＴに記録された情報に基づいて、取得すべきキャッシュリソースを決定してキャッシュリソースの取得を実行し、得した更新キャッシュ対象リソースを、バージョン情報と共にミドルウェアキャッシュ部１７８に格納。
（Ｓ２２２）サービスワーカー（ＳＷ）制御部１７７が、出力制御部（ブラウザ）１８０に対してリソースキャッシュイベントを発行する。
（Ｓ２２３）出力制御部（ブラウザ）１８０において実行中のサービスワーカー（ｓｗ１．ｊｓ）が、ＰＳＷＩＴからキャッシュ対象リソースリストを取得し、リストされたリソースをミドルウェアキャッシュ部１７８から取得して、記憶部（永続キャッシュ部）１７９に格納する。

（Ｓ２４１〜Ｓ２４３）
ステップＳ２４１〜Ｓ２４３の処理は、上述のステップＳ２２１〜Ｓ２２３の処理における更新リソースを更新サービスワーカー（ＳＷ）に置き換えた処理であり、ＰＳＷＩＴを参照して更新対象となるサービスワーカー（ＳＷ）の情報を取得した更新処理を行なう。

（Ｓ２５１〜Ｓ２５４）
ステップＳ２５１〜Ｓ２５４の処理は、上述のステップＳ２４１〜Ｓ２４３の処理で更新されたサービスワーカー（ＳＷ）の管理レリソースの取得処理である。

これらの処理において、ステップＳ２２１〜Ｓ２２３における更新キャッシュリソースの取得処理や、ステップＳ２４１〜Ｓ２４３の更新サービスワーカー（ＳＷ）の取得処理は、前述したように、処理対象であるサービスワーカー（ｓｗ１．ｊｓ）に関する情報のみからなるＰＳＷＩＴ（パーシャルＳＷＩＴ）を参照して実行される。
例えば、取得するキャッシュリソースが更新リソースである場合、ＰＳＷＩＴに記録された更新スケジュール情報に従って、更新グループ単位でのデータ取得処理を行なうことが可能であり、効率的なリソース取得が可能となる。

［８−３．処理フェーズ３の処理シーケンスについて］
次に、ステップＳ２６１以降の処理フェーズ３の処理について説明する。
ステップＳ２６１の処理は、アプリケーションによるサービスワーカー（ＳＷ）の利用処理である。
先に説明した処理フェーズ１以降のいずれのタイミングにおいても以下のアプリケーション動作が行われ得る。

（ステップＳ２６１）
出力制御部１８０が、サービスワーカー（ＳＷ）の登録時とは異なる任意の日時に異なるＡＩＴにより番組に連動するアプリケーションを起動する。
起動したアプリケーションに基づいて、サービスワーカー（ＳＷ）の管理リソースにアクセスすると、記憶部（永続キャッシュ）１７９に格納されている最新リソースを読み出して利用することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なお、本明細書において開示した技術は、以下のような構成をとることができる。
（１） 受信装置の格納データに関するデータ管理プログラムであるサービスワーカー（ＳＷ）に関する情報を格納したテーブルであり、個別のサービスワーカー（ＳＷ）単位の更新処理情報を含むサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）を受信し、受信したＳＷＩＴを利用したデータ管理処理を実行するデータ処理部を有する受信装置。

（２） 前記ＳＷＩＴは、
サービスワーカー（ＳＷ）識別子と、該サービスワーカー（ＳＷ）識別子によって特定されるサービスワーカー（ＳＷ）の管理リソースに関する更新情報を記録したテーブルであり、
前記データ処理部は、前記ＳＷＩＴを参照して、サービスワーカー（ＳＷ）の管理リソースに関する更新処理を実行する（１）に記載の受信装置。

（３） 前記ＳＷＩＴは、
サービスワーカー（ＳＷ）識別子と、該サービスワーカー（ＳＷ）識別子によって特定されるサービスワーカー（ＳＷ）自身に関する更新情報を記録したテーブルであり、
前記データ処理部は、前記ＳＷＩＴを参照して、サービスワーカー（ＳＷ）の更新処理を実行する（１）または（２）に記載の受信装置。

（４） 前記ＳＷＩＴは、
サービスワーカー（ＳＷ）識別子と、該サービスワーカー（ＳＷ）識別子によって特定されるサービスワーカー（ＳＷ）のバージョン情報を記録したテーブルであり、
前記データ処理部は、前記ＳＷＩＴを参照して、サービスワーカー（ＳＷ）識別子とバージョンを確認して更新処理を実行する（１）〜（３）いずれかに記載の受信装置。

（５） 前記ＳＷＩＴは、
サービスワーカー（ＳＷ）の管理対称となるリソースのリソース識別子と、該リソース識別子によって特定されるリソースのバージョン情報を記録したテーブルであり、
前記データ処理部は、前記ＳＷＩＴを参照して、リソース識別子とバージョンを確認して更新処理を実行する（１）〜（４）いずれかに記載の受信装置。

（６） 前記ＳＷＩＴは、
サービスワーカー（ＳＷ）の管理対称となるリソースの属する更新グループ識別子と、更新グループ対応の更新スケジュール情報が記録され、
前記データ処理部は、前記ＳＷＩＴを参照して、更新グループ識別子と、更新グループ対応の更新スケジュール情報を確認して、グループ単位のリソース更新処理を実行する（１）〜（５）いずれかに記載の受信装置。

（７） 前記ＳＷＩＴは、
サービスワーカー（ＳＷ）の更新グループ識別子と、更新グループ対応の更新スケジュール情報が記録され、
前記データ処理部は、前記ＳＷＩＴを参照して、更新グループ識別子と、更新グループ対応の更新スケジュール情報を確認して、グループ単位のサービスワーカー（ＳＷ）更新処理を実行する（１）〜（６）いずれかに記載の受信装置。

（８） 前記ＳＷＩＴは、
サービスワーカー（ＳＷ）、またはサービスワーカー（ＳＷ）管理リソースの更新スケジュール情報として、次回更新日時情報、または、更新頻度情報を記録した構成であり、
前記データ処理部は、前記ＳＷＩＴに記録された更新スケジュール情報に従って、サービスワーカー（ＳＷ）、またはサービスワーカー（ＳＷ）管理リソースの更新処理を実行する（１）〜（７）いずれかに記載の受信装置。

（９） 前記データ処理部は、
送信装置から送信されるサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）を受信し、
ＳＷＩＴから、処理対象となる特定のサービスワーカー（ＳＷ）に関する情報のみを選択抽出したテーブルであるパーシャルＰＳＷＩＴを利用した処理を実行する（１）〜（８）いずれかに記載の受信装置。

（１０） 受信装置の格納データに関するデータ管理プログラムであるサービスワーカー（ＳＷ）に関する情報を格納したテーブルであり、個別のサービスワーカー（ＳＷ）単位の更新処理情報を含むサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）を送信する送信装置。

（１１） 前記ＳＷＩＴは、
サービスワーカー（ＳＷ）識別子と、該サービスワーカー（ＳＷ）識別子によって特定されるサービスワーカー（ＳＷ）の管理リソースに関する更新情報を記録したテーブルであり、
前記受信装置において、前記ＳＷＩＴを参照して、サービスワーカー（ＳＷ）の管理リソースに関する更新処理を実行させることを可能としたテーブルである（１０）に記載の送信装置。

（１２） 前記ＳＷＩＴは、
サービスワーカー（ＳＷ）識別子と、該サービスワーカー（ＳＷ）識別子によって特定されるサービスワーカー（ＳＷ）自身に関する更新情報を記録したテーブルであり、
前記受信装置において、前記ＳＷＩＴを参照して、サービスワーカー（ＳＷ）の更新処理を実行させることを可能としたテーブルである（１０）または（１１）に記載の送信装置。

（１３） 受信装置において実行するデータ処理方法であり、
受信装置のデータ処理部が、
格納データに関するデータ管理プログラムであるサービスワーカー（ＳＷ）に関する情報を格納したテーブルであり、個別のサービスワーカー（ＳＷ）単位の更新処理情報を含むサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）を受信し、受信したＳＷＩＴを利用したデータ管理処理を実行するデータ処理方法。

（１４） 送信装置において実行するデータ処理方法であり、
受信装置の格納データに関するデータ管理プログラムであるサービスワーカー（ＳＷ）に関する情報を格納したテーブルであり、個別のサービスワーカー（ＳＷ）単位の更新処理情報を含むサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）を送信するデータ処理方法。

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

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

以上、説明したように、本開示の一実施例の構成によれば、受信装置におけるデータ管理プログラムであるサービスワーカー（ＳＷ）やその管理リソースの更新処理を効率的に確実に実行する装置、方法が実現される。
具体的には、例えば、受信装置の格納データに関するデータ管理プログラムであるサービスワーカー（ＳＷ）に関する情報を格納したテーブルであり、個別のＳＷ単位の更新処理情報を含むサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）を受信し、受信したＳＷＩＴを利用したデータ管理処理を実行する。ＳＷＩＴは、ＳＷ識別子と、ＳＷ識別子によって特定されるＳＷおよび管理リソースに関する更新情報を記録したテーブルであり、受信装置は、ＳＷＩＴを参照して、ＳＷおよび管理リソースの更新処理を実行する。
本構成により、受信装置におけるデータ管理プログラムであるサービスワーカー（ＳＷ）やその管理リソースの更新処理を効率的に確実に実行する装置、方法が実現される。

１０ 通信システム
２０ 送信装置
２１ 放送サーバ
２２ データ配信サーバ
３０ 受信装置
３１ ＴＶ
３２ ＰＣ
３３ 携帯端末
５０ シグナリングデータ
６０ ＡＶセグメント
７０ その他のデータ
１５１ データ処理部
１５２ 通信部
１５３ ネットワークＩ／Ｆ
１７１ パケット分離部
１７２ 画像データ処理部
１７３ 音声データ処理部
１７４ システム制御部
１７５ アプリケーション制御部
１７６ キャッシュ部
１７７ サービスワーカー（ＳＷ）制御部
１７８ ミドルウェアキャッシュ部
１７９ 記憶部（永続キャッシュ部）
１８０ 出力制御部（プラウザ）
１８１ 合成処理部
７５１ データ処理部
７５２ 通信部
７５３ 記憶部
７７１ データ処理部
７７２ 通信部
７７３ 記憶部
７７４ 入力部
７７５ 出力部
８０１ ＣＰＵ
８０２ ＲＯＭ
８０３ ＲＡＭ
８０４ バス
８０５ 入出力インタフェース
８０６ 入力部
８０７ 出力部
８０８ 記憶部
８０９ 通信部
８１０ ドライブ
８１１ リムーバブルメディア

Claims (14)

1. 受信装置の格納データに関連するサービスの終了時または切り替え時、もしくは受信装置のオフライン状態時において前記格納データに関するデータ管理を実現するプログラムであるサービスワーカー（ＳＷ）を識別するサービスワーカー（ＳＷ）識別子と、前記サービスワーカー（ＳＷ）識別子によって特定されるサービスワーカー（ＳＷ）の管理リソースに関する更新処理情報を含むデータ管理処理情報を受信し、受信した前記データ管理処理情報を利用してサービスワーカー（ＳＷ）の管理リソースに関する更新処理を含むデータ管理処理を実行するデータ処理部を有する受信装置。
2. 前記データ管理処理情報は、
   個別のサービスワーカー（ＳＷ）単位の更新処理情報を含むサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）である請求項１に記載の受信装置。
3. 前記ＳＷＩＴは、
   前記サービスワーカー（ＳＷ）識別子によって特定されるサービスワーカー（ＳＷ）自身に関する更新情報を含み、
   前記データ処理部は、前記ＳＷＩＴを参照して、サービスワーカー（ＳＷ）の更新処理を実行する請求項２に記載の受信装置。
4. 前記ＳＷＩＴは、
   前記サービスワーカー（ＳＷ）識別子によって特定されるサービスワーカー（ＳＷ）のバージョン情報を含み、
   前記データ処理部は、前記ＳＷＩＴを参照して、サービスワーカー（ＳＷ）識別子とバージョンを確認して更新処理を実行する請求項２に記載の受信装置。
5. 前記ＳＷＩＴは、
   サービスワーカー（ＳＷ）の管理対称となるリソースのリソース識別子と、前記リソース識別子によって特定されるリソースのバージョン情報を含み、
   前記データ処理部は、前記ＳＷＩＴを参照して、リソース識別子とバージョンを確認して更新処理を実行する請求項２に記載の受信装置。
6. 前記ＳＷＩＴは、
   サービスワーカー（ＳＷ）の管理対称となるリソースの属する更新グループ識別子と、更新グループ対応の更新スケジュール情報を含み、
   前記データ処理部は、前記ＳＷＩＴを参照して、更新グループ識別子と、更新グループ対応の更新スケジュール情報を確認して、グループ単位のリソース更新処理を実行する請求項２に記載の受信装置。
7. 前記ＳＷＩＴは、
   サービスワーカー（ＳＷ）の更新グループ識別子と、更新グループ対応の更新スケジュール情報を含み、
   前記データ処理部は、前記ＳＷＩＴを参照して、更新グループ識別子と、更新グループ対応の更新スケジュール情報を確認して、グループ単位のサービスワーカー（ＳＷ）更新処理を実行する請求項２に記載の受信装置。
8. 前記ＳＷＩＴは、
   サービスワーカー（ＳＷ）、またはサービスワーカー（ＳＷ）管理リソースの更新スケジュール情報として、次回更新日時情報、または、更新頻度情報を含んだ構成であり、
   前記データ処理部は、前記ＳＷＩＴに記録された更新スケジュール情報に従って、サービスワーカー（ＳＷ）、またはサービスワーカー（ＳＷ）管理リソースの更新処理を実行する請求項２に記載の受信装置。
9. 前記データ処理部は、
   送信装置から送信されるサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）を受信し、
   ＳＷＩＴから、処理対象となる特定のサービスワーカー（ＳＷ）に関する情報のみを選択抽出したテーブルであるパーシャルＰＳＷＩＴを利用した処理を実行する請求項２に記載の受信装置。
10. 受信装置の格納データに関連するサービスの終了時または切り替え時、もしくは受信装置のオフライン状態時において前記格納データに関するデータ管理を実現するプログラムであるサービスワーカー（ＳＷ）を識別するサービスワーカー（ＳＷ）識別子と、前記サービスワーカー（ＳＷ）識別子によって特定されるサービスワーカー（ＳＷ）の管理リソースに関する更新処理情報を含むデータ管理処理情報を生成して送信する送信装置。
11. 前記データ管理処理情報は、
    個別のサービスワーカー（ＳＷ）単位の更新処理情報を含むサービスワーカー・インフォメーション・テーブル（ＳＷＩＴ）である請求項１０に記載の送信装置。
12. 前記ＳＷＩＴは、
    前記サービスワーカー（ＳＷ）識別子によって特定されるサービスワーカー（ＳＷ）自身に関する更新情報を含み、
    前記受信装置において、前記ＳＷＩＴを参照して、サービスワーカー（ＳＷ）の更新処理を実行させることを可能としたテーブルである請求項１１に記載の送信装置。
13. 受信装置において実行するデータ処理方法であり、
    受信装置のデータ処理部が、
    格納データに関連するサービスの終了時または切り替え時、もしくは受信装置のオフライン状態時において前記格納データに関するデータ管理を実現するプログラムであるサービスワーカー（ＳＷ）を識別するサービスワーカー（ＳＷ）識別子と、前記サービスワーカー（ＳＷ）識別子によって特定されるサービスワーカー（ＳＷ）の管理リソースに関する更新処理情報を含むデータ管理処理情報を受信し、受信した前記データ管理処理情報を利用してサービスワーカー（ＳＷ）の管理リソースに関する更新処理を含むデータ管理処理を実行するデータ処理方法。
14. 送信装置において実行するデータ処理方法であり、
    受信装置の格納データに関連するサービスの終了時または切り替え時、もしくは受信装置のオフライン状態時において前記格納データに関するデータ管理を実現するプログラムであるサービスワーカー（ＳＷ）を識別するサービスワーカー（ＳＷ）識別子と、前記サービスワーカー（ＳＷ）識別子によって特定されるサービスワーカー（ＳＷ）の管理リソースに関する更新処理情報を含むデータ管理処理情報を生成して送信するデータ処理方法。

Images