WO2016067988A1

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

Info

Publication number: WO2016067988A1
Application number: PCT/JP2015/079645
Authority: WO
Inventors: 山岸　靖明; 五十嵐　卓也; 典史吉川; 義治出葉
Original assignee: ソニー株式会社
Priority date: 2014-10-28
Filing date: 2015-10-21
Publication date: 2016-05-06
Also published as: US20170317773A1; KR20170074874A; CN107113471A; CA2964719C; JP6583281B2; KR102460099B1; CA2964719A1; JPWO2016067988A1; MX2017005212A; EP3214844A4; EP3214844A1; US10880024B2

Abstract

各々の受信装置に最適化したデータ管理を実行するサービスワーカー（ＳＷ）の選択取得および利用処理を可能とする装置、方法を提供する。受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）から、特定クラスのＳＷを選択取得して利用可能とした。例えば、受信装置におけるアプリケーション利用状況に応じて選択されるクラス対応のＳＷの利用を実現する。受信装置は、特定クラスのＳＷのアクセス情報を効率的に検索可能とするためのトークンを記録したシグナリングデータを利用して特定クラスのＳＷのアクセス情報を取得してＳＷを取得する。

Description

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

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

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

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

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

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

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

　本開示は、上述したサービスワーカー（ＳＷ）のフレームワークを、放送コンテンツの受信装置であるクライアントにおいて有効な利用を実現する受信装置、送信装置、およびデータ処理方法を提供することを目的とする。
　さらに、具体的には、受信装置（クライアント）の実行環境や記憶容量等の各種リソースの制約を考慮にいれて、受信装置側のユーザの嗜好情報や、記憶域容量他ランタイム環境制約、ローカルネットワーク負荷等のさまざまなクライアント環境属性を参照することにより、きめの細かなキャッシュ対象であるアプリケーション（パーツ）のキャッシュ制御を実現する受信装置、送信装置、およびデータ処理方法を提供することを目的とする。

　本開示の第１の側面は、
　受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）から、特定クラスのサービスワーカー（ＳＷ）を選択取得して利用するデータ処理部を有する受信装置にある。

　さらに、本開示の第２の側面は、
　受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）を送信する送信装置にある。

　さらに、本開示の第３の側面は、
　受信装置において実行するデータ処理方法であり、
　前記受信装置のデータ処理部が、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）から、特定クラスのサービスワーカー（ＳＷ）を選択取得して利用するデータ処理方法にある。

　さらに、本開示の第４の側面は、
　送信装置において実行するデータ処理方法であり、
　受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）を送信するデータ処理方法にある。

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

　本開示の一実施例の構成によれば、各々の受信装置に最適化したデータ管理を実行するサービスワーカー（ＳＷ）の選択取得および利用処理を可能とする装置、方法が実現される。
　具体的には、例えば、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）から、特定クラスのＳＷを選択取得して利用可能とした。例えば、受信装置におけるアプリケーション利用状況に応じて選択されるクラス対応のＳＷの利用を実現する。受信装置は、特定クラスのＳＷのアクセス情報を効率的に検索可能とするためのトークンを記録したシグナリングデータを利用して特定クラスのＳＷのアクセス情報を取得してＳＷを取得する。
　本構成により、各々の受信装置に最適化したデータ管理を実行するサービスワーカー（ＳＷ）の選択取得および利用処理を可能とする装置、方法が実現される。
　なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。

本開示の処理を実行する通信システムの一構成例について説明する図である。送信装置の送信データについて説明する図である。送信装置および受信装置のプロトコルスタックの例を示す図である。サービスワーカー（ＳＷ）を利用した処理の具体例（ユースケース）について説明する図である。サービスワーカー（ＳＷ）を利用した処理の具体例（ユースケース）について説明する図である。サービスワーカー（ＳＷ）を利用した処理の一例を説明する図である。受信装置の構成例について説明する図である。アプリケーションの取得および実行、さらにサービスワーカー（ＳＷ）の取得と登録処理のシーケンスについて説明する図である。アプリケーションの取得および実行、さらにサービスワーカー（ＳＷ）の取得と登録処理のシーケンスについて説明する図である。アプリケーションの取得および実行、さらにサービスワーカー（ＳＷ）の取得と登録処理のシーケンスについて説明する図である。トークンを利用したデータ取得処理シーケンスについて説明する図である。トークンを利用したデータ取得処理シーケンスについて説明する図である。シグナリングデータ（メタデータ）の構成例について説明する図である。シグナリングデータ（メタデータ）の構成例について説明する図である。シグナリングデータ（メタデータ）に対するトークン設定例について説明する図である。シグナリングデータ（メタデータ）に対するトークン設定例について説明する図である。シグナリングデータ（メタデータ）に対するトークン設定例について説明する図である。サービスワーカー（ＳＷ）の更新処理シーケンスについて説明する図である。サービスワーカー（ＳＷ）の更新処理シーケンスについて説明する図である。サービスワーカー（ＳＷ）による受信装置の記憶部（永続キャッシュ）の制御処理シーケンスについて説明する図である。サービスワーカー（ＳＷ）による受信装置の記憶部（永続キャッシュ）の制御処理シーケンスについて説明する図である。プッシュ型のトークン適用データ選択取得処理シーケンスについて説明する図である。プッシュ型のトークン適用データ選択取得処理シーケンスについて説明する図である。プッシュ型処理におけるサービスワーカー更新処理シーケンスについて説明する図である。送信装置から送信されるシグナリングデータ（メタデータ）の構成例を示す図である。サービス・フラグメント（Ｓｅｒｖｉｃｅ　Ｆｒａｇｍｅｎｔ）の構成例について説明する図である。ＵＳＤ（ユーザサービスディスクリプション）の全体構成例について説明する図である。シグナリングデータを構成するＵＳＤ（ユーザサービスバンドルディスクリプション）以下の階層構成例を示す図である。スケジュールディスクリプション（Ｓｃｈｅｄｕｌｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）要素以下のシグナリングデータ構成を示す図である。フィルタディスクリプションリファレンス（ｆｉｌｔｅｒ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｒｅｆｅｒｅｎｃｅ）によって特定されるフィルタディスクリプション（ｆｉｌｔｅｒ　Ｄｅｓｃｒｉｐｔｉｏｎ）要素のデータ構成について説明する図である。シグナリングデータを構成するＵＳＤ（ユーザサービスバンドルディスクリプション）以下の階層構成例を示す図である。ファイル転送をＦＬＵＴＥプロトコルに従って実行する場合に、デリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）要素に設定されるＦＬＵＴＥへの参照情報の例を示す図である。ファイル転送をＦＬＵＴＥプロトコルに従って実行する場合に、デリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）要素に設定されるＦＬＵＴＥへの参照情報の例を示す図である。ファイル転送をＲＯＵＴＥプロトコルに従って実行する場合に、デリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）要素に設定されるＦＬＵＴＥへの参照情報の例を示す図である。ファイル転送をＲＯＵＴＥプロトコルに従って実行する場合に、デリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）要素に設定されるＦＬＵＴＥへの参照情報の例を示す図である。ＦＤＴ－Ｉｎｓｔａｎｃｅ要素の属性、もしくは、Ｆｉｌｅ要素の属性にトークンを記録する構成について説明する図である。ＦＤＴインスタンス対応のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）と、ファイル対応のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）の詳細構成を説明する図である。ＲＯＵＴＥで規定しているＬＳＩＤ以下のデータ構成を示す図である。ＥＦＤＴ要素単位のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）データ要素、ファイル（Ｆｉｌｅ）単位のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）データ要素の詳細について説明する図である。サービスワーカー（ＳＷ）による受信装置の記憶部（永続キャッシュ）の制御処理シーケンスについて説明する図である。サービスワーカー（ＳＷ）による受信装置の記憶部（永続キャッシュ）の制御処理シーケンスについて説明する図である。通信装置である送信装置と受信装置の構成例について説明する図である。通信装置である送信装置と受信装置のハードウェア構成例について説明する図である。

　以下、図面を参照しながら本開示の受信装置、送信装置、およびデータ処理方法の詳細について説明する。なお、説明は以下の項目に従って行なう。
　１．通信システムの構成例について
　２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて
　３．送信装置と受信装置の実行する通信処理例について
　４．サービスワーカー（ＳＷ）について
　５．受信装置におけるアプリケーションの取得および実行例について
　６．サービスワーカー（ＳＷ）のクラス分類と、クラス分類されたサービスワーカー（ＳＷ）の選択取得用情報の通知（シグナリング）処理につい
　７．サービスワーカー（ＳＷ）の配信とキャッシュ制御処理について（ポーリング型の処理例）
　７．１．放送ストリーム付随アプリケーションからのサービスワーカー（ＳＷ）の取得、登録処理について
　７．２．サービスワーカー（ＳＷ）に対するクラス設定について
　７．３．トークンを適用して特定クラスのサービスワーカー（ＳＷ）の取得処理を効率化した構成について
　７．４．サービスワーカー（ＳＷ）の更新処理について
　７．５．サービスワーカー（ＳＷ）による受信装置の記憶部（永続キャッシュ）の制御処理について
　８．サービスワーカー（ＳＷ）の配信とキャッシュ制御処理について（プッシュ型の処理例）
　８．１．放送ストリーム付随アプリケーションからのサービスワーカー（ＳＷ）の取得、登録処理について
　８．２．トークンを適用して受信装置のデータ取得処理を効率化した構成について
　８．３．サービスワーカー（ＳＷ）の更新処理について
　８．４．サービスワーカー（ＳＷ）による受信装置の記憶部（永続キャッシュ）の制御処理について
　９．トークンを記述するシグナリングデータ（メタデータ）の構成について
　９．１．シグナリングデータ（メタデータ）を構成するＯＭＡ－ＥＳＧに対するトークン記録例について
　９．２．シグナリングデータ（メタデータ）を構成するＵＳＤに対するトークン記録例について
　９．３．シグナリングデータ（メタデータ）を構成するＦＬＵＴＥ（ＲＯＵＴＥ）パラメータレイヤに対するトークン記録例について
　１０．サービスワーカー（ＳＷ）の利用可能なＡＰＩによるキャッシングの最適化処理例について
　１１．送信装置と受信装置の構成例について
　１２．本開示の構成のまとめ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　図７には、例えば天気情報表示アプリケーション等のサービスワーカー（ＳＷ）管理アプリケーションを実行する受信装置３０の一部構成として、主にアプリケーションの取得や実行に適用する構成例を示している。
　図７に示すように、受信装置３０はミドルウェア１１０、ＨＴＴＰプロキシサーバ１２０、出力制御部１３０を有する。

　ミドルウェア１１０は、放送サーバ２１の提供データを受信し、解析する。
　ミドルウェア１１０は、通信部（ＰＨＹ／ＭＡＣ）１１１、シグナリングデータを取得するシグナリング取得部１１２、シグナリングデータを解析するシグナリング解析部１１３、シグナリングデータ、および、映像、音声等の番組コンテンツデータや、アプリケーション等のＮＲＴコンテンツ等のデータファイルを取得するファイル取得部１１４を有する。

　ミドルウェア１１０が受信したデータは、プロキシサーバ１２０のキャッシュ部（プロキシキャッシュ）１２１に格納される。プロキシサーバ１２０は、さらにネットワーク経由でデータ配信サーバ２２から取得したデータをキャッシュ部（プロキシキャッシュ）１２２に格納する。
　プロキシサーバ１２０は、出力制御部１３０からのデータ要求をアドレス解決部１２３に入力し、要求されたデータをキャッシュ部（プロキシキャッシュ）１２１，１２２、または外部から取得して提供する。

　出力制御部１３０は、例えば天気情報表示アプリケーション等のサービスワーカー（ＳＷ）管理アプリケーションを実行するデータ処理部である。例えばブラウザ上でＷｅｂページの表示処理等を実行する。
　出力制御部１３０は、表示データ（ＨＴＭＬ／ＪａｖａＳｃｒｉｐｔ（登録商標）等）取得＆解析部１３１、表示処理部（Ｒｅｎｄｅｒｅｒ）１３２を有する。

　出力制御部１３０は、プロキシサーバ（Ｃｌｉｅｎｔ　Ｌｏｃａｌ　ＨＴＴＰ　Ｐｒｏｘｙ　Ｓｅｒｖｅｒ）１２０を介して、放送系受信スタックが実装されたミドルウェア（Ｃｌｉｅｎｔ　Ｌｏｃａｌ　ＡＴＳＣ　Ｍｉｄｄｌｅｗａｒｅ）１１０か、もしくは、ネット系送受信処理を行う通常のネットワークスタックを介してアプリケーション、およびパーツ（ＨＴＭＬページやＪａｖａＳｃｒｉｐｔ）を取得して提示する。
　なお、受信装置３０にＬＡＮ等のネットワークを介して接続された外部装置１５０の出力制御部１４１においてアプリケーション、およびパーツ（ＨＴＭＬページやＪａｖａＳｃｒｉｐｔ）を転送して、外部装置１４０においてアプリケーションを実行することも可能である。

　出力制御部１３０は、記憶部（永続キャッシュ）１３３に前述したサービスワーカー（ＳＷ）や、サービスワーカー（ＳＷ）の管理対象となるリソース（アプリケーション、およびアプリ関連データ）を格納し、任意タイミングで記憶部（永続キャッシュ）に格納されたサービスワーカー（ＳＷ）やリソースを利用した処理を実行することができる。
　例えば先に図４、図５を参照して説明したように、任意タイミングでアプリケーションを利用した様々なデータ出力を行うことができる。また、出力制御部１３０は、必要に応じて、サービスワーカー（ＳＷ）や、リソース（アプリケーション、およびアプリ関連データ）の更新処理や削除処理などを行う。

　外部装置１４０の出力制御部１４１も同様であり、外部装置１４０の記憶部（永続キャッシュ）１４２にサービスワーカー（ＳＷ）や、リソース（アプリケーション、およびアプリ関連データ）を格納し、任意タイミングでサービスワーカー（ＳＷ）やアプリケーションを利用した様々なデータ処理を行う。また、必要に応じて、サービスワーカー（ＳＷ）や、リソース（アプリケーション、およびアプリ関連データ）の更新処理や削除処理などを行う。

　なお、図７に示すモデルでは、出力制御部１３０，１４０は外部とのアクセスを行う場合、必ずプロキシサーバ１２０を介してアクセスするため、アプリケーション等のリソースを放送経由で取得しているのか、ネット経由で取得しているのかを区別することがない。すなわちネットワーク透過性が提供される。

　出力制御部１３０からのデータ要求に応じたデータ取得、提供処理例について説明する。
　例えば、出力制御部１３０が、アプリケーションを構成するＨＴＭＬページもしくはＪａｖａＳｃｒｉｐｔ（登録商標）の取得を要求すると（ＨＴＴＰリクエスト）、それを受けたプロキシサーバ１２０は、アドレス解決部（Ｂｒｏａｄｃａｓｔ／Ｂｒｏａｄｂａｎｄ　Ａｄｄｒｅｓｓ　Ｒｅｓｏｌｖｅｒ）１２３において放送受信スタックを介して取得するか、ネット経由で取得するかの判断を行う。

　この判断の材料となる情報は、シグナリング解析部１１３によるシグナリングデータの解析結果から得られる。
　シグナリング解析部（Ｓｉｇｎａｌｉｎｇ　Ｐａｒｓｅｒ）１１３は、シグナリング取得部（Ｓｉｇｎａｌｉｎｇ　Ｒｅｔｒｉｅｖｅｒ）１１２に対して、ＡＴＳＣ３．０のシグナリングデータに含まれるメタデータであるＵＳＢＤ（ＵＳＤ，ＳＤＰ等）の取得要求を行う。
　シグナリング解析部（Ｓｉｇｎａｌｉｎｇ　Ｐａｒｓｅｒ）１１３は、通信部（ＡＴＳＣチューナー：ＡＴＳＣ３．０ＰＨＹ／ＭＡＣ）１１１を介して放送受信するシグナリングデータ格納ＬＣＴパケットによって転送されるシグナリングデータに含まれるメタデータを抽出する。

　さらに、シグナリング解析部（Ｓｉｇｎａｌｉｎｇ　Ｐａｒｓｅｒ）１１３は、アプリケーション構成要素（パーツ）の取得要求に含まれるＵＲＬに基づいて、シグナリングデータ（メタデータ）から、要求ファイルを取得するための放送配信アドレス情報を解決する。アプリケーション構成要素（パーツ）が放送配信対象データであると判定されると、その放送配信アドレス情報をもとに、ファイル取得部（Ｆｉｌｅ　Ｒｅｔｒｉｅｖｅｒ）１１４が所望のファイルが格納されたファイル格納ＬＣＴパケットを放送ストリームから取得し、キャッシュ部（プロキシキャッシュ）１２１内に格納する。

　プロキシサーバ１２０は、キャッシュされたファイルを出力制御部１３０に（ＨＴＴＰのレスポンスとして）返す。アプリケーションパーツの取得要求に含まれるＵＲＬが、シグナリングデータに含まれるメタデータに設定されていなければ、プロキシサーバ１２０は、通常のネットスタックを介して、データ配信サーバ２２からファイルを取得する。

　　［６．サービスワーカー（ＳＷ）のクラス分類と、クラス分類されたサービスワーカー（ＳＷ）の選択取得用情報の通知（シグナリング）処理について］
　先に説明したように、サービスワーカー（ＳＷ）は、送信装置２０から受信装置３０に提供され、受信装置（クライアント）３０において実行されるアプリケーションや、アプリケーションの実行時に利用されるデータファイル等の取得処理や、記憶部（キャッシュ）に対する格納処理、さらに更新処理、削除処理等を実行するプログラムである。

　サービスワーカー（ＳＷ）は、例えば番組対応のアプリケーションやデータを、番組終了後や、チャンネル切り替え後、あるいは放送の非受信状態、ネットワーク非接続状態等のオフライン状態であっても利用可能とするリソース管理プログラムとして機能する。
　さらに、サービスワーカー（ＳＷ）を適用することで、サービスワーカー（ＳＷ）管理データとして設定された新規のあるいは更新されたアプリケーションや、動画、静止画等のデータファイルを、随時取得する処理が可能である。
　すなわち、サービスワーカー（ＳＷ）は受信装置３０において取得可能な様々なデータの取得制御も実現する。

　このサービスワーカー（ＳＷ）をクラス分類し、受信装置が、複数クラスのサービスワーカー（ＳＷ）の１つを選択して取得し、これを適用することで、例えば受信装置側のユーザ嗜好等に応じたサービスワーカー管理データ（リソース）の取得（キャッシング）を実現することが可能である。

　すなわち、受信装置は、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）から、特定クラスのサービスワーカー（ＳＷ）を選択取得して利用する。
　例えば、受信装置におけるデータ処理状況に応じて特定クラスのサービスワーカー（ＳＷ）を選択取得して利用する。データ処理状況は、例えば、受信装置におけるアプリケーションまたはデータの利用状況である。

　このように、複数クラスのサービスワーカー（ＳＷ）から特定クラスのサービスワーカー（ＳＷ）を選択取得して利用可能とすることで、クラス（種類）によって異なる複数のキャッシングポリシーを反映した処理が可能となる。
　受信装置３０は、同時に配信される複数のクラスのサービスワーカー（ＳＷ）の中から、受信装置３０にとって最適なクラスのサービスワーカ（ＳＷ）を選択して取得する。
　この処理のためには、例えば受信装置３０のブラウザ上で稼働するクライアントアプリケーションが最適なサービスワーカー（ＳＷ）を選択して、登録できるようにすることが必要となる。

　上記処理を実現させる１つの構成として、サービスワーカー（ＳＷ）に設定されたクラスの各々が、どのようなデータを選択取得する設定であるか、すなわち、どのようなキャッシングポリシーを反映したクラスのサービスワーカー（ＳＷ）であるかを受信装置３０に通知するためのシグナリングデータ（メタデータ）を利用する構成がある。
　例えば、シグナリングデータの１つであるＵＳＤを適用してＳＷのクラス（キャッシングポリシーを反映するクラス）を通知する。

　なお、ここでいうキャッシングポリシーのクラスとは、例えば、受信装置３０側のエンドユーザのアプリケーション実行履歴等から解析される嗜好を反映したクラス等である。具体的には例えば以下のようなクラスを設定して、受信装置にそのクラスのサービスワーカー（ＳＷ）を選択取得させて適用させる構成が可能である。

　（１）ネットワーク負荷や料金が高価になっても高画質版ストリームを好むユーザの場合、
　キャッシュ対象のストリームの候補が複数ある場合（高画質、中画質、低画質版等）、高画質版ストリームのみをキャッシュするよう記述されたサービスワーカー（ＳＷ）を選択できるようにする。

　（２）再生品質にこだわりがあり鮮度が失われても高画質版を好むユーザの場合、
　キャッシュ対象のストリームが、当日の夕方までは、ネット経由の低品質版で配信され、夜まで待つとさらに高画質版が放送配信される場合に、放送配信高画質版をキャッシュするよう記述されたクラスのサービスワーカー（ＳＷ）を選択できるようにする。

　（３）逆に、品質にはこだわりがなく、とにかく早く観たがる傾向のあるユーザの場合、
　このケースの場合、ネット経由の低品質版をキャッシュするよう記述されたクラスのサービスワーカー（ＳＷ）を選択できるようにする。

　クラス別のサービスワーカー（ＳＷ）を選択取得して利用することで、受信装置（クライアント）の実行環境や記憶容量等の各種リソースの制約なども考慮した最適なデータ取得、管理を実現することができる。受信装置側のユーザの嗜好情報や、記憶域容量他ランタイム環境制約、ローカルネットワーク負荷等のさまざまなクライアント環境属性を参照して利用するサービスワーカー（ＳＷ）のクラスを決定することにより、きめの細かなキャッシュ対象であるアプリケーション（パーツ）のキャッシュ制御が実現される。
　なお、クラス分類されたサービスワーカー（ＳＷ）を選択取得するためには、シグナリングデータが利用される。
　例えば、ＵＳＤ等のシグナリングデータを用いて、サービスワーカー（ＳＷ）のクラスを受信装置３０に通知し、受信装置３０がシグナリングデータに基づいて、自装置に最適なサービスワーカー（ＳＷ）を選択取得することで、上記のように、受信装置３０側の状況やユーザの嗜好に応じた最適なデータを受信装置３０が取得（キャッシング）することが可能となる。

　　［７．サービスワーカー（ＳＷ）の配信とキャッシュ制御処理について（ポーリング型の処理例）］
　次に、サービスワーカー（ＳＷ）の配信とキャッシュ制御処理について説明する。
　サービスワーカー（ＳＷ）、あるいはサービスワーカー（ＳＷ）の管理対象となるアプリケーションやアプリケーションに適用するデータからなるリソースは、例えば受信装置３０に実装されたブラウザからの取得要求を契機としてポーリング型で取得処理を行なう構成と、ブラウザからの取得要求に関わらず取得してブラウザに提供するプッシュ型の２つの態様がある。
　以下、これらの処理態様、すなわち、
　（Ａ）ポーリング型のデータ取得処理例
　（Ｂ）プッシュ型のデータ取得処理例
　上記（Ａ），（Ｂ）の２つの処理態様について、順次、説明する。
　まず、ポーリング型のデータ取得処理を行なう場合の処理例について説明する。

　　［７．１．放送ストリーム付随アプリケーションからのサービスワーカー（ＳＷ）の取得、登録処理について］
　まず、サービスワーカー（ＳＷ）を、送信装置２０から受信装置３０に送信される放送ストリームに付随するアプリケーションを利用して取得し、登録する処理例について説明する。

　受信装置（クライアント）３０は、受信装置３０において実行中の放送ストリーム再生アプリケーション（ブラウザもしくはネイティブの環境で実行される）の処理によって、取得対象とするアプリケーションのＵＲＬを取得する。
　例えば、特定の番組の放送ストリームには、アプリケーションを起動するためのＵＲＬ通知するトリガー情報が含まれ、再生アプリケーションは、このトリガー情報に基づいてアプリケーションを取得するためのＵＲＬを取得することができる。

　受信装置３０は、このＵＲＬを利用して放送ストリームの中からＵＲＬによって特定されるアプリケーションを抽出するか、もしくは、ネット経由でアプリケーションを取得し、ブラウザ上でそのアプリケーションを実行する。
　アプリケーションは、このアプリケーション自身を管理対象として設定したサービスワーカー（ＳＷ）［ＳＷ．ｊｓ］の取得処理と登録処理を行う。ＳＷ．ｊｓのｊｓはＪａｖａＳｃｒｉｐｔ（登録商標）を意味する。

　このアプリケーションの取得および実行、さらにサービスワーカー（ＳＷ）の取得と登録処理のシーケンスについて、図８～図１０に示すシーケンス図を参照して説明する。
　図８～図１０には、左から、以下の各構成要素を示している。
　（ａ）送信装置２０である放送サーバ
　（ｂ）送信装置２０であるデータ配信サーバ
　（ｃ）受信装置３０の構成要素であるミドルウェア
　（ｄ）受信装置３０の構成要素であるプロキシサーバ
　（ｅ）受信装置３０の構成要素である出力制御部

　図８～図１０のシーケンス図に示す各ステップの処理について、順次、説明する。
　なお、図８～図１０の処理シーケンスの開始前に、受信装置３０の出力制御部では、ネイティブのストリーム再生アプリケーション、もしくは、ブラウザ上のストリーム再生アプリケーションが起動されているものとする。

　　（ステップＳ２１１）
　まず、受信装置３０の構成要素である出力制御部は、放送コンテンツストリームのＤＡＳＨストリーミングの制御ファイルであるＭＰＤに記述されたコンテンツ格納セグメントのアクセス情報であるセグメントＵＲＬを取得して、取得したセグメントＵＲＬを用いて放送コンテンツを格納したコンテンツセグメントファイルの取得要求を実行する。

　前述したように、送信装置２０から受信装置３０に対するコンテンツ送信は、例えばアダプティブ（適応型）ストリーミング技術の規格であるＭＰＥＧ－ＤＡＳＨ規格に従って実行される。
　ＭＰＥＧ－ＤＡＳＨ規格に従ってデータ送信を実行する送信装置２０は、先に図２を参照して説明したように、大きく分けて以下の複数種類のデータの送信を行う。
　（ａ）シグナリングデータ５０
　（ｂ）ＡＶセグメント６０
　（ｃ）その他のデータ（ＥＳＧ，ＮＲＴコンテンツ等）７０

　ＡＶセグメント６０は、受信装置において再生する画像（Ｖｉｄｅｏ）や、音声（Ａｕｄｉｏ）データ、すなわち例えば放送局の提供する番組コンテンツ等によって構成される。例えば、上述したＭＰ４符号化データ（ｍｄａｔ）や、メタデータ（ｍｏｏｖ，ｍｏｏｆ）によって構成される。
　シグナリングデータ５０は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、制御情報によって構成される。
　その他のデータ７０は、例えばＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）、ＮＲＴコンテンツ等が含まれる。
　ＥＳＧは、電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）であり、例えば番組表等の案内情報である。
　ＮＲＴコンテンツはノンリアルタイム型のコンテンツである。
　ＮＲＴコンテンツには、例えば、クライアントである受信装置のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。サービスワーカー（ＳＷ）も、ＮＲＴコンテンツに含まれる。

　（ＭＰＤ：Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）は、動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイルである。具体的には、例えば、放送局が配信する番組コンテンツの配信開始時間情報や、ＡＶセグメントに対するアクセス情報などが記録される。

　受信装置３０の出力制御部は、ステップＳ２１１において、放送コンテンツストリームのＤＡＳＨストリーミングの制御ファイルであるＭＰＤに記述されたコンテンツ格納セグメントのアクセス情報であるセグメントＵＲＬを取得して、取得したセグメントＵＲＬを用いてコンテンツセグメントファイルの取得要求をプロキシサーバに対して実行する。

　　（ステップＳ２１２～Ｓ２１３）
　次に、受信装置３０のプロキシサーバは、ステップＳ２１２において、セグメントＵＲＬで識別されるコンテンツセグメントファイルがプロキシサーバの管理するキャッシュに格納されていれば、キャッシュからコンテンツセグメントファイルを取得して取得したファイルをレスポンスとして出力制御部に返す。
　一方、受信装置３０のプロキシサーバは、ステップＳ２１３において、セグメントＵＲＬで識別されるコンテンツセグメントファイルがプロキシサーバの管理するキャッシュに格納されていないと判定した場合は、コンテンツセグメントファイルの取得要求をミドルウェアに出力する。

　　（ステップＳ２１４）
　ステップＳ２１４の処理は、放送サーバ２１によって継続的に実行される処理を示している。放送サーバ２１は、番組コンテンツの配信に併せて、配信コンテンツに関する制御情報、管理情報等からなるシグナリングデータ（メタデータ等）を受信装置３０に継続的に提供する。

　　（ステップＳ２１５）
　ステップＳ２１５の処理は、ステップＳ２１３において、プロキシサーバからコンテンツセグメントファイルの要求が発生した場合に、ミドルウェアが実行する。
　ミドルウェアは、放送サーバ２１から受信するシグナリングデータ（メタデータ）に基づいて、プロキシサーバから取得要求のあったコンテンツセグメントファイルが放送によって受信可能か否かを判定し、判定情報をプロキシサーバに通知する。

　　（ステップＳ２１６）
　プロキシサーバは、ミドルウェアからコンテンツセグメントファイルが放送によって受信可能であるとの通知を受けると、セグメントファイルのプロキシサーバ管理キュャッシュへの展開（格納）を待機する。
　一方、ミドルウェアからコンテンツセグメントファイルが放送によって受信不可能であるとの通知を受けると、セグメントファイルのネット経由での取得要求をデータ配信サーバ２２に対して実行する。

　　（ステップＳ２１７～Ｓ２１８）
　ステップＳ２１７～Ｓ２１８の処理は、プロキシサーバから取得要求のあったコンテンツセグメントファイルが放送によって受信可能である場合に実行される処理である。
　この場合、放送サーバ２１は、ステップＳ２１７において、コンテンツセグメントファイルを放送波によって送信する。
　受信装置３０のミドルウェアは、ステップＳ２１８において、放送サーバ２１から送信されたセグメントファイルを受信して、プロキシサーバの管理キャッシュに展開（格納）する。

　　（ステップＳ２１９）
　ステップＳ２１９の処理は、プロキシサーバから取得要求のあったコンテンツセグメントファイルが放送によって受信不可能である場合に実行される処理である。
　この場合、データ配信サーバ２２は、ステップＳ２１９において、受信装置３０から要求されたコンテンツセグメントファイルを受信装置３０に対して送信する。
　受信装置３０のプロキシサーバは、送信されたセグメントファイルを受信して、プロキシサーバの管理キャッシュに展開（格納）する。

　　（ステップＳ２２０）
　放送サーバ２１、またはデータ配信サーバ２２から取得されプロキシサーバ管理キャッシュ内に格納されたコンテンツセグメントファイルは、ステップＳ２２０において、プロキシサーバから、出力制御部に提供される。

　　（ステップＳ２２１）
　ステップＳ２２１において、受信装置３０の出力制御部は、プロキシサーバから取得したコンテンツの再生を開始する。
　さらに、コンテンツ再生時にコンテンツに含まれるトリガー情報を取得し、トリガー情報に記録されたコンテンツ対応のアプリケーションのアクセス情報であるアプリケーションＵＲＬをトリガー情報から取得して、取得したアプリケーションＵＲＬを適用したアプリケーション取得要求をプロキシサーバに対して実行する。

　　（ステップＳ２２３）
　ステップＳ２２３の処理は、ステップＳ２２１において再生中のコンテンツ（例えば放送番組）に対して設定されたアプリケーションの取得と実行処理である。
　ステップＳ２２３では、ステップＳ２１２～Ｓ２１９の処理（処理（Ａ－１～２））と同様の処理を、アプリケーションファイルに対して実行する。
　すなわち、ステップＳ２１２～Ｓ２１９の処理中に示す「セグメントファイル」を「アプリケーションファイル」に置き換えた処理を実行し、放送サーバ２１、またはデータ配信サーバ２２からアプリケーションファイルを取得してプロキシサーバの管理キャッシュに格納する。なお、すでにプロキシサーバの管理キャッシュに目的のアプリケーションファイルが展開（格納）されている場合は、新たな取得処理は不要である。

　　（ステップＳ２２４）
　放送サーバ２１、またはデータ配信サーバ２２から取得されプロキシサーバ管理キャッシュ内に格納されたアプリケーションファイルは、ステップＳ２２４において、プロキシサーバから、出力制御部に提供される。

　　（ステップＳ２２５）
　ステップＳ２２５において、受信装置３０の出力制御部は、プロキシサーバから取得したアプリケーションを実行する。
　例えば、番組コンテンツの表示に併せてＷｅｂページの表示処理等が実行される。なお、処理内容は、アプリケーションに応じて異なるものであり、必ずしもデータ表示が実行されるとは限らない。

　　（ステップＳ２２６）
　ステップＳ２２６の処理は、ステップＳ２２５において実行中のアプリケーションの制御の下で実行される処理であり、サービスワーカー（ＳＷ）の取得と実行処理である。
　ステップＳ２２６では、ステップＳ２１２～Ｓ２１９の処理（処理（Ａ－１～２））と同様の処理を、サービスワーカー（ＳＷ）ファイルに対して実行する。
　すなわち、ステップＳ２１２～Ｓ２１９の処理中に示す「セグメントファイル」を「サービスワーカーファイル」に置き換えた処理を実行し、放送サーバ２１、またはデータ配信サーバ２２からサービスワーカーファイルを取得してプロキシサーバの管理キャッシュに格納する。なお、すでにプロキシサーバの管理キャッシュに目的のサービスワーカーファイルが展開（格納）されている場合は、新たな取得処理は不要である。

　　（ステップＳ２２７）
　放送サーバ２１、またはデータ配信サーバ２２から取得されプロキシサーバ管理キャッシュ内に格納されたサービスワーカーファイルは、ステップＳ２２７において、プロキシサーバから、出力制御部に提供される。

　　（ステップＳ２２８）
　ステップＳ２２８において、受信装置３０の出力制御部は、プロキシサーバから取得したサービスワーカーの登録処理を実行する。
　具体的には、サービスワーカー（ＳＷ）を記憶部（永続キャッシュ）に格納する処理を実行する。

　　［７．２．サービスワーカー（ＳＷ）に対するクラス設定について］
　前述したようにサービスワーカー（ＳＷ）をクラス分類して、受信装置において所定クラスのサービスワーカー（ＳＷ）を選択取得して適用することにより、例えば、受信装置３０側のユーザ嗜好に応じたアプリケーションやデータを取得し実行、再生することが可能となる。

　送信装置２０は、様々な異なるクラスのサービスワーカー（ＳＷ）を同時に並列配信し、受信装置３０は、これらの複数クラスのサービスワーカー（ＳＷ）から１つのクラスのサービスワーカー（ＳＷ）を選択取得するフィルタリング処理を行なうことになる。

　受信装置３０において実行されるアプリケーション、あるいはサービスワーカー（ＳＷ）が、受信装置３０のミドルウェアに対して、新規取得するサービスワーカー（ＳＷ）に対するフィルタリング情報を設定する。すなわちどのクラスのサービスワーカー（ＳＷ）を取得すべきかのサービスワーカー（ＳＷ）クラス設定を行う。

　受信装置３０のミドルウェアは、サービスワーカー（ＳＷ）クラス設定情報に基づいて、フィルタリング処理を実行し、送信比装置２０の送信する様々なクラスのサービスワーカー（ＳＷ）から指定されたクラスのサービスワーカー（ＳＷ）のみを選択取得する。

　サービスワーカー（ＳＷ）クラスのセットは、例えば、プロキシサーバ上のサーバサイドスクリプトに対してａｊａｘを用いて要求を投げられるようにする等により実装される。

　なお、シグナリングデータ（メタデータ）に記録されたすべてのファイルＵＲＬの中から所望のファイルＵＲＬを検索し、選択取得する処理が煩雑（負荷のかかる処理となる可能性がある）となるため、プリフィルタリング処理を行なうことが望ましい。

　プリフィルタリングとは、例えば目的とするファイル（例えば指定クラスのサービスワーカー（ＳＷ））ファイル）のＵＲＬをシグナリングデータの中から検索する際の検索範囲の特定（スコープ（ｓｃｏｐｉｎｇ））する処理等である。
　具体的には、例えば、特定のアプリケーションの提供元のチャンネル提供者（放送局）のシグナリングデータのみから目的のファイルＵＲＬを探せるようにしておく等の処理である。
　この処理には、後述する検索スコープトークンが利用される。

　サービスワーカー（ＳＷ）クラスのセットがなされた後、放送シグナリングデータを受信したミドルウェアは、設定されたサービスワーカー（ＳＷ）クラスに基づいて、シグナリングデータの中に該当するサービスワーカー（ＳＷ）クラスに対応するファイル配信セッションがあるか否かを判定する。さらに、受信スケジュールリングを行い、指定されたサービスワーカー（ＳＷ）が放送経由で配信されると、フィルタリングモジュールにより、サービスワーカー（ＳＷ）を自動的に選択取得してローカルプロキシサーバのキャッシュに展開することが可能となる。これらプロキシーサーバキャッシュに展開されたファイルについては、クライアントのアプリケーションからの要求に対して即座に応答することが可能となる。

　図１１～図１２に示すシーケンス図を参照して、サービスワーカー（ＳＷ）のクラス設定処理と、サービスワーカー（ＳＷ）取得処理シーケンスについて説明する。
　図１１～図１２には、左から、以下の各構成要素を示している。
　（ａ）送信装置を構成する放送サーバ
　（ｂ）送信装置を構成するデータ配信サーバ
　（ｃ）受信装置のミドルウェア

　（ｄ）受信装置の出力制御部で実行されるサービスワーカー
　（ｅ）受信装置の出力制御部で実行されるアプリケーション
　図１１～図１２のシーケンス図に示す各ステップの処理について、順次、説明する。

　　（ステップＳ２５１）
　ステップＳ２５１の処理は、受信装置の出力制御部で実行されるアプリケーションによって実行される。
　アプリケーションが、サービスワーカー（ＳＷ）クラスの設定要求をミドルウェアに対して実行する。
　具体的には、例えば図７に示すミドルウェア１１０のシグナリング解析部１１３に対して、シグナリングデータに含まれるどのクラスのサービスワーカー（ＳＷ）アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部１１３に検出すべきクラスのサービスワーカー（ＳＷ）アクセス情報を判別可能な状態に設定する。

　なお、アプリケーションは、例えば、受信装置（クライアント）の環境属性（状態情報）や、アプリケーションや再生データの利用履歴の統計情報に基づいて、最適なクラスを決定する。このクラス決定アルゴリズムは、アプリケーション自身が保持してもよいし、アプリケーションが利用可能なプログラムやＡＰＩを利用して取得する構成としてもよい。

　　（ステップＳ２５２～Ｓ２５３）
　ステップＳ２５２～Ｓ２５３の処理は、受信装置の出力制御部で実行されるアプリケーションおよびサービスワーカーによって実行される。
　ミドルウェアに対するサービスワーカー（ＳＷ）クラスの設定処理は、ステップＳ２５１で説明したように、アプリケーションの処理として実行してもよいが、サービスワーカー（ＳＷ）の処理として実行してもよい。
　ステップＳ２５２～Ｓ２５３の処理は、ミドルウェアに対するサービスワーカー（ＳＷ）クラスの設定処理をサービスワーカー（ＳＷ）の処理として実行する場合に行われる。

　まず、ステップＳ２５２において、アプリケーションが、サービスワーカー（ＳＷ）の登録処理を実行し、サービスワーカー（ＳＷ）の処理を開始する。
　登録処理によってサービスワーカー（ＳＷ）は、記憶部（永続キャッシュ）に格納され、いつでも利用可能な状態になる。
　次に、登録されたサービスワーカー（ＳＷ）が、サービスワーカー（ＳＷ）クラスの設定要求をミドルウェアに対して実行する。
　サービスワーカー（ＳＷ）クラスの設定は、ステップＳ２５１の処理と同様の処理である。すなわち、例えば図７に示すミドルウェア１１０のシグナリング解析部１１３に対して、シグナリングデータに含まれるどのクラスのサービスワーカー（ＳＷ）アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部１１３に検出すべきクラスのサービスワーカー（ＳＷ）アクセス情報を判別可能な状態に設定する。

　　（ステップＳ２５４）
　ステップＳ２５４の処理は、放送サーバによって継続的に実行されているシグナリングデータの送信処理である。
　このシグナリングデータには、例えば、様々なクラス対応のサービスワーカー（ＳＷ）を取得するためのアクセス情報が記録されている。

　　（ステップＳ２５５）
　ステップＳ２５５の処理は、受信装置３０のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、アプリケーションまたはサービスワーカー（ＳＷ）から通知されたサービスワーカー（ＳＷ）クラスを設定し、設定したサービスワーカー（ＳＷ）クラスに基づいて、シグナリングデータから設定されたクラスのサービワーカー（ＳＷ）のアクセス情報検出を行う。

　　（ステップＳ２５６）
　さらに、受信装置３０のミドルウェアは、ステップＳ２５６において、シグナリングデータから取得したアクセス情報に基づいて、取得対象ファイルの配信スケジュール情報を取得し、これらを用いたサービスワーカー（ＳＷ）格納ファイル取得処理を開始する。

　　（ステップＳ２５７）
　ステップＳ２５７の処理は、放送サーバによって継続的に実行されている各種ファイルの送信処理である。
　送信ファイルには、アプリケーション、アプリケーション実行時に利用されるデータファイル等のアプリケーション関連データ、さらにサービスワーカー（ＳＷ）などが含まれる。

　　（ステップＳ２５８）
　ステップＳ２５５の処理は、受信装置３０のミドルウェアの処理である。ミドルウェアは、放送サーバの送信ファイルから、取得対象となるファイルを選択取得し、取得ファイルをプロキシサーバの管理キャッシュに展開（格納）する。

　このように、受信装置のミドルウェアに取得すべきサービスワーカー（ＳＷ）のクラス設定を実行することで、設定されたクラス対応のサービスワーカー（ＳＷ）を選択的に取得することが可能となる。

　　［７．３．トークンを適用して特定クラスのサービスワーカー（ＳＷ）の取得処理を効率化した構成について］
　次に、受信装置における取得データの取得、選択処理を効率化した構成について説明する。
　具体的には、トークンを適用して特定クラスのサービスワーカー（ＳＷ）の取得処理を効率化した構成について説明する。

　送信装置２０から送信されるサービスワーカー（ＳＷ）は様々なクラスのサービスワーカー（ＳＷ）であり、受信装置３０は、これらの多数のクラスのサービスワーカー（ＳＷ）から特定クラスのサービスワーカー（ＳＷ）のみを選択取得する処理が必要となる。

　しかし、放送波を介して提供されるサービスワーカー（ＳＷ）や、アプリケーション、およびデータファイルは、個々の番組に対応して設定され、送信装置２０の送信するファイル数は膨大な数となることが予想される。
　受信装置３０は、これらの膨大な数の送信ファイルから、自装置に最適なクラスのサービスワーカー（ＳＷ）を選択して取得する必要がある。

　このファイル選択処理を効率的に実行するための構成について、以下説明する。
　サービスワーカー（ＳＷ）は、例えばＮＲＴコンテンツとして放送波を介して逐次、送信される。
　さらに、サービスワーカー（ＳＷ）等のファイルを取得するために必要となるアクセス情報であるファイル対応のＵＲＬや各ファイルの送信タイミング情報等がシグナリングデータ（メタデータ）に記録されて受信装置３０に提供される。
　受信装置３０は、シグナリングデータ（メタデータ）を解析して、取得すべきファイルのＵＲＬや送信タイミング等を知ることができる。

　シグナリングデータ（メタデータ）は、例えば１つのチャンネルや１つの番組を１つのサービス単位として、各サービス単位の様々な情報（メタデータ）を記録する構成を有している。

　例えば、図１３に示すように、
　サービスＡの記述を持つメタデータ、
　サービスＢの記述を持つメタデータ、
　サービスＣの記述を持つメタデータ、
　このようにサービス単位（番組単位やチャンネル単位）のメタデータが記述されている。
　さらに、各サービス単位のメタデータは、下位のメタデータとしてファイル転送セッション単位のメタデータを有する。

　ファイル転送セッション単位のメタデータには、各セッションにおいて転送されるファイルのアクセス情報が記録される。
　受信装置３０は、このアクセス情報を利用して、先に図７参照して説明したシグナリング解析部１１３、アドレス解決部１２３の処理によって取得し、必要なファイルのＵＲＬにマッチするファイルアクセス情報を取得して、ファイルを取得することができる。

　しかし、受信装置３０は、必要なファイルのアクセス情報が、シグナリングデータのどのメタデータに記録されているかを知ることができない。
　従って、シナリングデータに記録されたアクセス情報をすべて検索対象として調べる必要があり、検索時間に多大な時間を要することになる。

　この解決策として、シグナリングデータに検索範囲を限定するためのトークンやＵＲＬを記録する構成とした例について、図１４を参照して説明する。
　トークンやＵＲＬは、受信装置３０の取得予定データに関するアクセス情報（メタデータ）を効率的に検索するための検索補助情報である。
　例えば、特定のクラスのサービスワーカー（ＳＷ）や、特定のクラスのサービスワーカー（ＳＷ）の管理対象となるデータであるリソース（アプリケーションアプリ関連データ）に関するアクセス情報を効率的に検索するための検索補助情報である。

　図１４は、図１３と同様のシグナリングデータ（メタデータ）の構成例を示している。前述したように、シグナリングデータ（メタデータ）は、例えば１つのチャンネルや１つの番組を１つのサービス単位として、各サービス単位の様々な情報（メタデータ）を記録する構成を有している。
　図１４に示すように、
　サービスＡの記述を持つメタデータ、
　サービスＢの記述を持つメタデータ、
　サービスＣの記述を持つメタデータ、
　このようにサービス単位（番組単位やチャンネル単位）のメタデータが記述されている。
　さらに、各サービス単位のメタデータは、下位のメタデータとしてファイル転送セッション単位のメタデータを有する。

　図１４に示す例では、サービスＡの記述を持つメタデータ１５１に、トークン＜ＳＷ－Ｓｃｏｐｅ＞の記述が含まれる。
　また、メタデータ１５１に含まれる下位のセッション単位のメタデータであるファイル転送セッション２の記述を持つメタデータ１５２と、ファイル転送セッション３の記述を持つメタデータ１５４には、トークン＜ＳＷ－Ｃｌａｓｓ＞とファイルＵＲＬの記述が含まれる。
　また、メタデータ１５１に含まれる下位のセッション単位のメタデータであるファイル転送セッション１の記述を持つメタデータ１５３には、ファイルＵＲＬの記述が含まれる。
　これら、＜ＳＷ－Ｓｃｏｐｅ＞、＜ＳＷ－Ｃｌａｓｓ＞やファイルＵＲＬが、受信装置において取得ファイルのアクセス情報を効率化するために適用されるトークンとして記述されるデータである。

　メタデータ１５１に記録されるトークン＜ＳＷ－Ｓｃｏｐｅ＞は、検索対象とするアクセス情報を記録したメタデータの検索範囲を限定するために利用されるトークンであり、
　「サービスワーカー（ＳＷ）検索スコープトークン」
　である。
　また、メタデータ１５２に記録されるトークン＜ＳＷ－Ｃｌａｓｓ＞は、特定のＳＷの管理、または更新対象となるファイル（キャッシュ対象ファイル）に関するＵＲＬ情報がまとめて記録されていることを示すトークンであり、
　「サービスワーカー（ＳＷ）クラス指定トークン」
　である。
　なお、これらのトークンは、いずれも特定のサービスワーカー（ＳＷ）対応のトークンとして設定されている。

　「サービスワーカー（ＳＷ）検索スコープトークン＜ＳＷ－Ｓｃｏｐｅ＞」は、取得すべき特定クラスのサービスワーカー（ＳＷ）のファイルアクセス情報が、このトークンの記録されたメタデータ、またはその下位のメタデータ中に記録されていることを示すトークンである。
　受信装置３０は、このトークンの記録されたメタデータを選択し、このメタデータ、およびこのメタデータの下位のメタデータを検索範囲として検索を行えば、受信装置の取得すべきクラスのサービスワーカー（ＳＷ）ファイルのアクセス情報を効率的に取得することができる。
　すなわち、その他のメタデータを検索対象から除外することが可能となり、検索範囲を限定することで、検索効率を高めることが可能となる。

　また、「サービスワーカー（ＳＷ）クラス指定トークン＜ＳＷ－Ｃｌａｓｓ＞」は、例えば、受信装置の取得対象となるクラスのサービスワーカー（ＳＷ）ファイルのアクセス情報が、このトークンの記録されたメタデータ中にまとめて記録されていることを示す特定のサービスワーカー（ＳＷ）の管理対象ファイル群（グループ）を示すトークンである。
　受信装置３０は、このトークンの記録されたメタデータを選択し、このメタデータに記録されたアクセス情報のみを取得すれば、受信装置の取得すべきクラスのサービスワーカー（ＳＷ）ファイルのアクセス情報を効率的に取得することができる。

　このように、トークンやＵＲＬは、受信装置３０の取得予定データに関するアクセス情報（メタデータ）を効率的に検索するための検索補助情報として設定される。
　なお、図１４に示すように、サービスワーカー（ＳＷ）検索スコープトークンを、シグナリングデータのサービス単位の記述パートに配置し、サービスワーカー（ＳＷ）クラス指定トークンを、シグナリングデータのファイル転送セッションの記述パートに配置する構成が検索効率を高めるトークン設定例の１つである。
　この構成をとることにより、受信装置（クライアント）においてシグナリングデータを受信した場合のアクセス情報取得をより効率的に行うことが可能となる。

　受信装置３０は、サービスワーカー（ＳＷ）検索スコープトークンを有するサービス記述群を選択的に抽出した後、それらに関連づけられるファイル転送セッション記述を抽出し、サービスワーカー（ＳＷ）クラス指定トークンもしくはファイルＵＲＬにマッチするファイル転送アドレス（放送ストリーム上で転送される実際のファイルを取得するのに必要なアドレスパラメーター）を検索して所望のファイルを取得する。

　送信装置２０から受信装置３０に送信されるシグナリングデータ（メタデータ）は、図１４に示すように階層構成を有するが、さらに具体的なシグナリングデータ（メタデータ）の構成例と、トークンの設定例について、図１５～図１７を参照して説明する。

　図１５に示す（１）トークン設定例１に基づいて、送信装置２０から受信装置３０に送信されるシグナリングデータ（メタデータ）の階層構成設定例について説明する。
　図１５（１）に示すシグナリングデータ（メタデータ）は、最上位が番組やチャンネル単位で設定されるサービス単位のメタデータ（Ｓｅｒｖｉｃｅ）である。
　このサービス単位メタデータの下位にコンテンツ単位のメタデータ（Ｃｏｎｔｅｎｔ）が設定される。
　サービス単位のメタデータ（Ｓｅｒｖｉｃｅ）、または、コンテンツ単位のメタデータ（Ｃｏｎｔｅｎｔ）の下位には、配信スケジュールやアクセス情報を記述したメタデータ（Ｓｃｈｅｄｕｌｅ＆Ａｃｃｅｓｓ）が設定される。

　さらに、メタデータ（Ｓｃｈｅｄｕｌｅ＆Ａｃｃｅｓｓ）の下位にＵＳＤ（ユーザサービスディスクリプション）メタデータが設定される。
　なお、ＵＳＤは、例えば配信メソッドに関する情報を格納し、例えば以下のシグナリングデータを含む。
　ＳＤＰ（セッションディスクリプション）
　ＦＤＤ（ファイルデリバリディスクリプション）
　ＲＦＤ（リペアフローディスクリプション）
　ＳＤ（スケジュールディスクリプション）
　さらに、ＵＳＤは、コンテンツ（ＡＶセグメント）に対応する様々な案内情報、制御情報を格納したマニフェスト・ファイルを持つシグナリングデータとして、
　ＭＰＤ（メディアプレゼンテーションディスクリプション）
　を含む。

　ＵＳＤメタデータの下位に、ＲＯＵＴＥプロトコルに従って配信される具体的な配信データ情報、例えば、実際に配信されるファイル個別の転送パラメータ等を記録したＲＯＵＴＥメタデータが設定される。

　図１５（１）に示すトークン設定例１は、
　サービスメタデータ１６１に、「サービスワーカー（ＳＷ）検索スコープトークン＜ＳＷ－Ｓｃｏｐｅ＞」を記録している。
　受信装置３０は、このトークンに従って取得予定クラスのサービスワーカー（ＳＷ）ファイルのＵＲＬやアクセス情報の検索範囲を限定することができる。すなわち、図の点線枠で示す検索範囲を設定して取得予定ファイルのＵＲＬやアクセス情報の検索を行うことができる。

　さらに、最下層のＲＯＵＴＥメタデータ１６２，１６３に、「サービスワーカー（ＳＷ）クラス指定トークン＜ＳＷ－Ｃｌａｓｓ＞」が記録されている。
　受信装置３０は、このトークンに従って、このメタデータ１６２，１６３に特定クラスのサービスワーカー（ＳＷ）や、管理リソースファイルのＵＲＬやアクセス情報が記録されていることを知ることができる。

　図１５（２）に示すトークン設定例２は、
　コンテンツメタデータ１６４に、「サービスワーカー（ＳＷ）検索スコープトークン＜ＳＷ－Ｓｃｏｐｅ＞」を記録している。
　受信装置３０は、このトークンに従って検索範囲を限定することができる。すなわち、図の点線枠で示す検索範囲を設定して取得予定ファイルのＵＲＬやアクセス情報の検索を行うことができる。

　さらに、最下層のＲＯＵＴＥメタデータ１６５に、「サービスワーカー（ＳＷ）クラス指定トークン＜ＳＷ－Ｃｌａｓｓ＞」が記録されている。
　受信装置３０は、このトークンに従って、このメタデータ１６５に特定クラスのサービスワーカー（ＳＷ）や、管理リソースを構成するグループの取得予定ファイルのＵＲＬやアクセス情報が記録されていることを知ることができる。

　図１６（３）に示すトークン設定例３は、
　スケジュール＆アクセスメタデータ１６６に、「サービスワーカー（ＳＷ）検索スコープトークン＜ＳＷ－Ｓｃｏｐｅ＞」を記録している。
　受信装置３０は、このトークンに従って取得予定クラスのサービスワーカー（ＳＷ）ファイルのＵＲＬやアクセス情報の検索範囲を限定することができる。すなわち、図の点線枠で示す検索範囲を設定して検索を行うことができる。

　さらに、最下層のＲＯＵＴＥメタデータ１６７に、「サービスワーカー（ＳＷ）クラス指定トークン＜ＳＷ－Ｃｌａｓｓ＞」が記録されている。
　受信装置３０は、このトークンに従って、このメタデータ１６７に特定クラスのサービスワーカー（ＳＷ）や管理リソースを構成するグループの取得予定ファイルのＵＲＬやアクセス情報が記録されていることを知ることができる。

　図１７（４）に示すトークン設定例４は、
　ＵＳＤメタデータの下位に設定されたスケジュールディスクリプションメタデータ１６８に、「サービスワーカー（ＳＷ）検索スコープトークン＜ＳＷ－Ｓｃｏｐｅ＞」を記録している。
　受信装置３０は、このトークンに従って検索範囲を限定することができる。すなわち、図の点線枠で示す検索範囲を設定して取得予定ファイルのＵＲＬやアクセス情報の検索を行うことができる。

　さらに、最下層のＲＯＵＴＥメタデータ１６９に、「サービスワーカー（ＳＷ）クラス指定トークン＜ＳＷ－Ｃｌａｓｓ＞」が記録されている。
　受信装置３０は、このトークンに従って、このメタデータ１６９に特定のサービスワーカー（ＳＷ）や、管理リソースを構成するグループの取得予定ファイルのＵＲＬやアクセス情報が記録されていることを知ることができる。

　図１５～図１７を参照してシグナリングデータに対するトークンの設定例について複数の例を説明したが、この他にも様々な態様でのトークン設定が可能である。

　受信装置３０は、シグナリングデータに含まれるトークンに基づいて、取得すべきファイルのＵＲＬやアクセス情報を効率的に取得することが可能となる。
　受信装置３０は、例えば、放送データを受信するミドルウェアに、上述した検索範囲の限定や、検索対象ファイルのグループ特定等のフィルタリング処理に適用するトークンを検出するためのトークン検出用のトークン情報を通知（セット）し、セットされたトークン情報に従って、送信装置２０から送信されるシグナリングデータを解析してトークンを検出し、検出したトークンを利用した効率的な検索処理を行ない、記憶部（永続キャッシュ）に格納するファイルの取得に必要なＵＲＬ情報やアクセス情報、配信スケジュール情報等を取得する。なお、シグナリングデータにはファイルＵＲＬに併せて、各ファイルの配信スケジュール情報も記録されている。

　ミドルウェアに対するトークン情報のセット処理は、例えば、プロキシサーバ上のサーバサイドスクリプトに対してａｊａｘを用いて要求を出力することで実行できる。
　なお、トークン情報のセット態様としては、以下の設定態様がある。
　（１）サービスワーカー（ＳＷ）クラス指定トークン（ＳＷ－Ｃｌａｓｓ）
　（２）サービスワーカー（ＳＷ）検索スコープトークン（ＳＷ－Ｓｃｏｐｅ）＋）サービスワーカー（ＳＷ）クラス指定トークン（ＳＷ－Ｃｌａｓｓ）

　なお、具体的な設定パラメータとしては、例えばサービスワーカー（ＳＷ）クラス識別子などが用いられる。また、特定クラス対応のサービスワーカー（ＳＷ）のファイルＵＲＬを用いてもよい。
　また、特定クラスのサービスワーカー（ＳＷ）の管理データであるリソースの選択取得も併せて行う場合は、これらリソースのファイルＵＲＬをトークンに併せてパラメータ指定してもよい。

　　［７．４．サービスワーカー（ＳＷ）の更新処理について］
　次に、受信装置３０に格納されたサービスワーカー（ＳＷ）の更新処理について説明する。
　受信装置３０によって取得されたサービスワーカー（ＳＷ）は受信装置の記憶部（永続キャッシュ）に、サービスワーカー（ＳＷ）の管理対象となるリソース（アプリケーション、およびアプリ関連データ）とともに格納され、いつでも利用可能な設定となる。

　このサービスワーカー（ＳＷ）には、利用期限を定めることができ、受信装置３０は、必要に応じて、受信装置の保持する利用期限の来たサービスワーカー（ＳＷ）を新たなサービスワーカー（ＳＷ）に置き換えるサービスワーカー（ＳＷ）更新処理を行なうことができる。

　サービスワーカー（ＳＷ）は、例えば所定のコンテンツ（番組）に対応して設定されたアプリケーションを用いた取得要求により、放送サーバ２１、あるいはデータ配信サーバ２２等の送信装置２０から取得される。
　例えば、この取得処理の際に（放送経由の場合もネット経由の場合も）、サービスワーカー（ＳＷ）の提供処理に際して送信装置２０から受信装置３０に対する通信データである「ＨＴＴＰレスポンスヘッダ：Ｃａｃｈｅ－ｃｏｎｔｒｏｌ」にサービスワーカー（ＳＷ）自身の有効期限を指定することができる。

　例えば、所定のコンテンツ（番組）に対応して設定されたアプリケーションの処理によって実行されるサービスワーカー登録処理によって、受信装置３０の記憶部（永続キャッシュ）に格納されたサービスワーカー（ＳＷ）は、例えば受信装置の出力制御部において実行されるブラウザによって、有効期限の確認処理や、更新処理が実行される。

　ブラウザは、受信装置３０の記憶部（永続キャッシュ）に格納された複数のサービスワーカー（ＳＷ）各々について、有効期限を確認し、有効期限になると自動的にローカルプロキシサーバに対する取得リクエストを行い、中身が更新されていればサービスワーカー（ＳＷ）を再登録、すなわち更新処理を実行する。
　もしくは、ブラウザの設定した一定期限（例えば１日に一回等）がすぎると自動的にサービスワーカー（ＳＷ）についてローカルプロキシサーバに対する取得リクエストを行い、中身が更新されていれば再登録する処理がなされる。

　図１８～図１９に示すシーケンス図を参照して、サービスワーカー（ＳＷ）の更新処理シーケンスについて説明する。
　図１８～図１９には、左から、以下の各構成要素を示している。
　（ａ）送信装置を構成する放送サーバ
　（ｂ）送信装置を構成するデータ配信サーバ
　（ｃ）受信装置のミドルウェア
　（ｄ）受信装置の出力制御部で実行されるブラウザ
　さらに、
　（ｅ）受信装置の出力制御部で実行されるブラウザ上で実行されるサービスワーカー（ＳＷ）
　これらの各構成要素を示している。
　図１８～図１９のシーケンス図に示す各ステップの処理について、順次、説明する。

　　（ステップＳ２７１）
　ステップＳ２７１の処理は、放送サーバによって継続的に実行されているシグナリングデータの送信処理である。
　このシグナリングデータには、例えば、先に図１４～図１７を参照して説明したトークンが設定されている。

　　（ステップＳ２７２）
　ステップＳ２７２の処理は、受信装置３０のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、アプリケーションまたはサービスワーカー（ＳＷ）から通知されたトークン情報を設定し、設定したトークン情報に基づいて、シグナリングデータからのトークン（もしくはファイルＵＲＬ）検出を実行する。

　　（ステップＳ２７３）
　ステップＳ２７３の処理は、放送サーバによって継続的に実行されている各種ファイルの送信処理である。
　送信ファイルには、アプリケーション、アプリケーション実行時に利用されるデータファイル等のアプリケーション関連データ、さらにサービスワーカー（ＳＷ）などが含まれる。

　　（ステップＳ２７４）
　ステップＳ２７４の処理は、受信装置３０のミドルウェアの処理である。ミドルウェアは、放送サーバの送信ファイルから、取得対象となるファイルを選択取得し、取得ファイルをプロキシサーバの管理キャッシュに展開（格納）する。
　このキャッシュデータには、アプリケーション、アプリケーション実行時に利用されるデータファイル等のアプリケーション関連データ、さらにサービスワーカー（ＳＷ）などが含まれる。
　サービスワーカー（ＳＷ）には、受信装置３０が保持しているサービスワーカー（ＳＷ）の更新バージョンも含まれる。

　　（ステップＳ２７５）
　ステップＳ２７５は、受信装置の出力制御部で実行されるブラウザの処理である。
　ブラウザは、受信装置３０の記憶部（永続キャッシュ）に格納された複数のサービスワーカー（ＳＷ）各々について、有効期限を確認し、有効期限になると自動的にローカルプロキシサーバに対する取得リクエストを行う。
　もしくは、ブラウザの設定した一定期限（例えば１日に一回等）がすぎると自動的にサービスワーカー（ＳＷ）についてローカルプロキシサーバに対する取得リクエストを行う。

　　（ステップＳ２７６）
　ステップＳ２７６の処理は、受信装置３０のミドルウェアの処理である。ミドルウェアは、プロキシサーバの管理キャッシュに、ブラウザから取得要求のあった更新されたサービスワーカー（ＳＷ）の検索を行い、検出された場合、更新されたサービスワーカー（ＳＷ）をブラウザに出力する。

　　（ステップＳ２７７）
　ステップＳ２７７は、受信装置の出力制御部で実行されるブラウザの処理である。
　ブラウザは、プロキシサーバから受領した更新後のサービスワーカー（ＳＷ）を登録する。すなわち、記憶部（永続キャッシュ）に格納する。

　　（ステップＳ２７８）
　ステップＳ２７８は、受信装置の出力制御部で実行されるサービスワーカー（ＳＷ）の処理である。ここでは、新たに登録された更新後のサービスワーカー（ＳＷ）の処理を示している。
　更新後のサービスワーカー（ＳＷ）は、必要に応じて、トークン情報の設定要求をミドルウェアに対して実行する。
　トークン情報の設定は、前述した図１１のステップＳ２５１の処理と同様の処理である。すなわち、例えば図７に示すミドルウェア１１０のシグナリング解析部１１３に対して、シグナリングデータに含まれるどのクラスのサービスワーカー（ＳＷ）アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部１１３に検出すべきクラスのサービスワーカー（ＳＷ）のアクセス情報を判別可能な状態に設定する。

　　（ステップＳ２７９）
　ステップＳ２７９の処理は、受信装置３０のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、更新後のサービスワーカー（ＳＷ）から通知されたトークン情報を設定し、設定したトークン情報に基づいて、シグナリングデータからのトークン（もしくはファイルＵＲＬ）検出を実行する。

　　［７．５．サービスワーカー（ＳＷ）による受信装置の記憶部（永続キャッシュ）の制御処理について］
　次に、受信装置３０に格納されたサービスワーカー（ＳＷ）による受信装置の記憶部（永続キャッシュ）の制御処理について説明する。

　受信装置３０に格納されたサービスワーカー（ＳＷ）は、管理対象のリソース、すなわちアプリケーションやアプリケーション関連データを管理処理の１つとして、これらのリソースが格納された記憶部（永続キャッシュ）の制御、すなわちキャッシュ制御を実行する。

　まず、サービスワーカー（ＳＷ）は、所定のイベント検出に応じて、自身を最初に起動したアプリケーションに必要なファイルを、受信装置３０の記憶部（永続キャッシュ）に格納する。
　サービスワーカー（ＳＷ）によるリソース格納のトリガーとなるイベントを受け取るタイミングは、サービスワーカー（ＳＷ）の登録処理、または再登録（更新）処理時である。これらの時点でサービスワーカー（ＳＷ）は、登録（ｉｎｓｔａｌｌ）イベントを受領する。
　その他、アプリケーションがＨＴＭＬページやＪａｖａＳｃｒｉｐｔ（登録商標）を要求する時点（フェッチ（ｆｅｔｃｈ）イベントを受領）、あるいは、サービスワーカー（ＳＷ）自身が生成したタイマーにより再起動される時点等に上記のリソース格納処理のトリガーとなるイベントを受領する。

　サービスワーカー（ＳＷ）が記憶部（永続キャッシュ）に展開したアプリケーション（パーツ群）は、放送ストリームに付随（同時）して起動されるばかりではなく、放送ストリームとは独立してクライアントにインストールされたアプリケーション（オフラインアプリケーション）として起動することが可能となる。

　図２０～図２１に示すシーケンス図を参照して、サービスワーカー（ＳＷ）による受信装置の記憶部（永続キャッシュ）の制御処理シーケンスについて説明する。
　図２０～図２１には、左から、以下の各構成要素を示している。
　（ａ）送信装置を構成する放送サーバ
　（ｂ）送信装置を構成するデータ配信サーバ
　（ｃ）受信装置のミドルウェア
　（ｄ）受信装置のプロキシサーバ
　（ｅ）受信装置の出力制御部で実行されるブラウザの管理下の記憶部（永続キャッシュ）
　（ｆ）受信装置の出力制御部の実行するブラウザ上で実行されるサービスワーカー（ＳＷ）
　（ｇ）受信装置の出力制御部の実行するブラウザ上で実行されるアプリケーション
　（ｈ）受信装置の出力制御部で実行されるネィティブアプリケーション
　これらの各構成要素を示している。

　なお、ネィティブアプリケーションは、受信装置３０で実行されるアプリケーションであるが、サービスワーカー（ＳＷ）の管理下にあるアプリケーションではなく、例えばコンテンツ（番組）対応のアプリケーションの起動処理等に用いられるアプリケーションである。
　図２０～図２１のシーケンス図に示す各ステップの処理について、順次、説明する。

　　（ステップＳ３０１）
　ステップＳ３０１の処理は、ネィティブアプリケーションによるコンテンツ（番組）対応のアプリケーションの起動処理である。
　上述したように、ネィティブアプリケーションは、コンテンツ（番組）対応のアプリケーションの起動処理等に用いられるアプリケーションである。
　コンテンツ（番組）対応のアプリケーションが、例えば、番組中に埋め込まれたトリガー情報に基づいて起動する設定の場合は、このネィティブアプリケーションによる起動処理は不要である。

　　（ステップＳ３０２）
　ステップＳ３０２において、起動されたアプリケーションが、サービスワーカー（ＳＷ）の登録処理を実行する。
　登録処理によってサービスワーカー（ＳＷ）は、記憶部（永続キャッシュ）に格納され、いつでも利用可能な状態になる。
　このサービスワーカー（ＳＷ）登録処理は、サービスワーカー（ＳＷ）自身からは、登録（ｉｎｓｔａｌｌ）イベントの検出として把握され、サービスワーカー（ＳＷ）は、この登録（ｉｎｓｔａｌｌ）イベント検出を契機として、ステップＳ３０３のキャッシュ制御を開始する。

　　（ステップＳ３０３～Ｓ３０５）
　サービスワーカー（ＳＷ）は、登録（ｉｎｓｔａｌｌ）イベントを検出すると、ステップＳ３０３において、例えばスクリプト記述に従った記憶部（永続キャッシュ）の制御を開始する。
　具体的には、特定クラスのサービスワーカー（ＳＷ）、または特定クラスのサービスワーカー（ＳＷ）の管理対象となるリソース（アプリケーションや、アプリ関連データ）の取得、キャッシュ展開（格納）処理を開始する。

　なお、特定クラスのサービスワーカー（ＳＷ）、または特定クラスのサービスワーカー（ＳＷ）の管理対象となるリソース（アプリケーションや、アプリ関連データ）は、ステップＳ３０４において、放送サーバ、データ配信サーバ等の送信装置から継続的に送信される。
　ステップＳ３０４では、先に図８～図９を参照して説明したリソース送受信処理における図８～９（Ａ－１～２）の各ステップのセグメントファイルに対する処理を、リソースに対する処理に置き換えた処理が実行される。

　送信データは、ステップＳ３０５において、プロキシサーバの管理キャッシュを介して、記憶部（永続キャッシュ）に展開（格納）される。

　　（ステップＳ３０６～Ｓ３０９）
　ステップＳ３０６において、アプリケーションがアプリケーションパーツ、例えばアプリケーションの実行に必要となる動画ファイルや静止画ファイル、あるいはＪａｖａＳｃｒｉｐｔ（登録商標）プログラム、音声データ等のアプリ関連データをサービスワーカー（ＳＷ）に要求する。
　この要求処理は、サービスワーカー（ＳＷ）におけるフェッチ（ｆｅｔｃｈ）イベント検出に相当する。
　ステップＳ３０７～Ｓ３０９において、サービスワーカー（ＳＷ）は、要求されたパーツを記憶部（永続キャッシュ）から取得して、アプリケーションに提供する。

　　（ステップＳ３１０～Ｓ３１１）
　ステップＳ３１０～Ｓ３１１の処理は、サービスワーカー（ＳＷ）によるアクティベート（ａｃｔｉｖａｔｅ）イベント検出時の処理である。
　アクティベート（ａｃｔｉｖａｔｅ）イベントは、例えば、ユーザによるリソースの削除要求の入力が実行された場合、あるいはアプリケーションの有効期限が切れた場合などに検出される。
　サービスワーカー（ＳＷ）が、アクティベート（ａｃｔｉｖａｔｅ）イベントを検出すると、例えばスクリプト記述に従った記憶部（永続キャッシュ）の制御を開始する。
　具体的には、特定クラスのサービスワーカー（ＳＷ）、または特定クラスのサービスワーカー（ＳＷ）の管理対象となるリソース（アプリケーションや、アプリ関連データ）の削除処理等を行なう。

　　（ステップＳ３１２～Ｓ３１５）
　ステップＳ３１２～Ｓ３１５の処理は、サービスワーカー（ＳＷ）によるタイマーイベント検出時の処理である。
　タイマーイベントは、例えば、アプリケーションの有効期限が切れた場合、更新期限がきた場合などに検出される。
　タイマーイベントに応じた処理としては、例えばキャッシュリソースの削除、あるいは更新リソースや追加リソースの取得処理などがある。

　ステップＳ３１３は、タイマーイベントに応じたキャッシュリソースの削除処理のシーケンスである。
　ステップＳ３１４～Ｓ３１５は、タイマーイベントに応じた更新リソースや追加リソースの取得処理のシーケンスを示している。
　なお、ステップＳ３１４では、先に図８～図９を参照して説明したリソース送受信処理における図８～９（Ａ－１～２）の各ステップのセグメントファイルに対する処理を、リソースに対する処理に置き換えた処理が実行される。

　　［８．サービスワーカー（ＳＷ）の配信とキャッシュ制御処理について（プッシュ型の処理例）］
　前述したように、サービスワーカー（ＳＷ）、あるいはサービスワーカー（ＳＷ）の管理対象となるアプリケーションやアプリケーションに適用するデータからなるリソースは、例えば受信装置３０に実装されたブラウザからの取得要求を契機としてポーリング型で取得処理を行なう構成と、ブラウザからの取得要求に関わらず取得してブラウザに提供するプッシュ型の２つの態様がある。

　図８～図２１を参照して説明した処理は、受信装置３０に実装されたブラウザからの取得要求を契機としてサービスワーカ（ＳＷ）やその管理リソース（アプリケーション、およびアプリ関連データ）の取得を行うポーリング型の処理例である。
　以下、ブラウザからの取得要求に関わらず、サービスワーカ（ＳＷ）やその管理リソース（アプリケーション、およびアプリ関連データ）を取得してブラウザに提供するプッシュ型の処理例について説明する。

　　［８．１．放送ストリーム付随アプリケーションからのサービスワーカー（ＳＷ）の取得、登録処理について］
　プッシュ型処理においても、放送サーバ２１から提供されるコンテンツ（番組）対応のアプリケーションを利用したサービスワーカー（ＳＷ）の取得、登録シーケンスは、先に図８～図１０を参照して説明したポーリング型の処理例と同様の処理となる。

　　［８．２．トークンを適用して受信装置のデータ取得処理を効率化した構成について］
　先に図１１～図１２を参照して説明したポーリングン型のトークン利用処理では、コンテンツ付随アプリケーション、もしくはサービスワーカー（ＳＷ）が、取得すべきリソースやサービスワーカー（ＳＷ）を含むファイルをミドルウェアにおいてフィルタリング取得するためのトークン情報（もしくはファイルＵＲＬ）をセットする処理を実行するものとして説明した。

　このシナリオは、ミドルウェアに対してトークン情報（もしくはファイルＵＲＬ）により特定されるファイルを、ローカルＨＴＴＰプロキシサーバのキャッシュに展開（格納）するように要求するものである。
　しかし、トークン情報の設定要求をしたアプリケーションやサービスワーカー（ＳＷ）は、プロキシサーバのキャッシュに、トークンに従って選択されたファイルが展開（格納）されたかどうかを受動的に検知することができない。

　すなわち、図１１～図１２を参照して説明したシーケンスは、ブラウザ（アプリケーション）側からのポーリング型でアプリケーションパーツやサービスワーカー（ＳＷ）のプロキシサーバからの引き込みを行うモデルである。

　前述のポーリング型の処理の説明では、サービスワーカー（ＳＷ）のキャッシュ有効期限や、タイマー、あらかじめ定めたポーリング周期等を、ポーリングを行う契機とする方法を説明した。
　この処理は、キャッシュ有効期限／タイマー／ポーリング周期等が長いと、プロキシサーバのキャッシュで更新が行われたら即座にブラウザ側に引き込むというような、設定された時間間隔の粒度に依存しないような引き込みタイミング制御ができないという問題がある。
　また、タイミング精度を上げるために時間間隔を短くすると、問い合わせ要求が頻繁になり、無駄な負荷を上げることとなる。

　この問題を解消するために、以下に説明するプッシュ型処理では、ブラウザ側からトークン情報（もしくはファイルＵＲＬ）の設定要求を行うと同時に、ミドルウェアの管理キャッシュに対するデータ展開（格納）が実行された場合に、キャッシュ展開をブラウザ側に通知させるプッシュＡＰＩ等を利用したプッシュ型イベント通知機構を利用した処理としている。
　このプッシュ型のトークン適用データ選択取得処理シーケンスについて、図２２～図２３のシーケンス図を参照して説明する。

　図２２～図２３には、左から、以下の各構成要素を示している。
　（ａ）送信装置を構成する放送サーバ
　（ｂ）送信装置を構成するデータ配信サーバ
　（ｃ）受信装置のミドルウェア
　（ｄ）受信装置の出力制御部で実行されるサービスワーカー
　（ｅ）受信装置の出力制御部で実行されるアプリケーション
　図２２～図２３のシーケンス図に示す各ステップの処理について、順次、説明する。

　　（ステップＳ３２１）
　ステップＳ３２１の処理は、受信装置の出力制御部で実行されるアプリケーションによって実行される。
　アプリケーションが、トークン情報の設定要求をミドルウェアに対して実行する。
　具体的には、例えば図７に示すミドルウェア１１０のシグナリング解析部１１３に対して、シグナリングデータに含まれるどのクラスのサービスワーカー（ＳＷ）アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部１１３に検出すべきクラスのサービスワーカー（ＳＷ）のアクセス情報を判別可能な状態に設定する。
　具体的には、例えば、サービスワーカー（ＳＷ）識別子等をトークン情報として通知し、設定する。

　このステップＳ３２１の処理に並行して、アプリケーション、ミドルウェア間、およびミドルウェアと送信装置（放送サーバ、データ配信サーバ）間において、ステップＳ３２１ａ，ｂに示すイベント登録、承諾処理を実行する。
　これは、送信装置（放送サーバ、データ配信サーバ）から受信装置に送信されたデータ（アプリケーション、アブリケーション関連データ、サービスワーカ（ＳＷ）等）が、ミドルウェアのプロキシサーバ管理キャッシュに展開（格納）された場合に、アプリケーションに通知する処理の実行を各装置または構成部が承諾して実行することを確認する処理である。

　　（ステップＳ３２２～Ｓ３２３）
　ステップＳ３２２～Ｓ３２３の処理は、受信装置の出力制御部で実行されるアプリケーションおよびサービスワーカーによって実行される。
　ミドルウェアに対するトークン情報の設定処理は、ステップＳ３２１で説明したように、アプリケーションの処理として実行してもよいが、サービスワーカー（ＳＷ）の処理として実行してもよい。
　ステップＳ３２２～Ｓ３２３の処理は、ミドルウェアに対するトークン情報の設定処理をサービスワーカー（ＳＷ）の処理として実行する場合に行われる。

　まず、ステップＳ３２２において、アプリケーションが、サービスワーカー（ＳＷ）の登録処理を実行し、サービスワーカー（ＳＷ）の処理を開始する。
　登録処理によってサービスワーカー（ＳＷ）は、記憶部（永続キャッシュ）に格納され、いつでも利用可能な状態になる。
　次に、登録されたサービスワーカー（ＳＷ）が、トークン情報の設定要求をミドルウェアに対して実行する。
　トークン情報の設定は、ステップＳ３２１の処理と同様の処理である。すなわち、例えば図７に示すミドルウェア１１０のシグナリング解析部１１３に対して、シグナリングデータに含まれるどのクラスのサービスワーカー（ＳＷ）アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部１１３に検出すべきクラスのサービスワーカー（ＳＷ）のアクセス情報を判別可能な状態に設定する。

　このステップＳ３２２～Ｓ３２３の処理が実行される場合は、これらの処理に並行して、アプリケーション、ミドルウェア間、およびミドルウェアと送信装置（放送サーバ、データ配信サーバ）間において、ステップＳ３２３ａ，ｂに示すイベント登録、承諾処理を実行する。
　これは、送信装置（放送サーバ、データ配信サーバ）から受信装置に送信されたデータ（アプリケーション、アブリケーション関連データ、サービスワーカ（ＳＷ）等）が、ミドルウェアのプロキシサーバ管理キャッシュに展開（格納）された場合に、アプリケーションに通知する処理の実行を各装置または構成部が承諾して実行することを確認する処理である。

　　（ステップＳ３２４）
　ステップＳ３２４の処理は、放送サーバによって継続的に実行されているシグナリングデータの送信処理である。
　このシグナリングデータには、例えば、先に図１４～図１７を参照して説明したトークンが設定されている。

　　（ステップＳ３２５）
　ステップＳ３２５の処理は、受信装置３０のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、アプリケーションまたはサービスワーカー（ＳＷ）から通知されたトークン情報を設定し、設定したトークン情報に基づいて、シグナリングデータからのトークン（もしくはファイルＵＲＬ）検出を実行する。
　さらに、受信装置３０のミドルウェアは、トークン（もしくはファイルＵＲＬ）に基づいて、取得対象ファイルを決定し、選択ファイルの配信スケジュール情報に従って、ファイル取得処理を開始する。

　　（ステップＳ３２６）
　ステップＳ３２６の処理は、放送サーバによって継続的に実行されている各種ファイルの送信処理である。
　送信ファイルには、アプリケーション、アプリケーション実行時に利用されるデータファイル等のアプリケーション関連データ、さらにサービスワーカー（ＳＷ）などが含まれる。

　　（ステップＳ３２７～Ｓ３２８）
　ステップＳ３２７の処理は、受信装置３０のミドルウェアの処理である。ミドルウェアは、放送サーバの送信ファイルから、取得対象となるファイルを選択取得し、取得ファイルをプロキシサーバの管理キャッシュに展開（格納）する。

　このステップＳ３２７の処理が実行される際に、ステップＳ３２８ａ～ｄに示すイベント通知処理が各装置、各構成部間で実行される。
　これは、送信装置（放送サーバ、データ配信サーバ）から受信装置に送信されたデータ（アプリケーション、アブリケーション関連データ、サービスワーカ（ＳＷ）等）が、ミドルウェアのプロキシサーバ管理キャッシュに展開（格納）されたことを、アプリケーション、またはサービスワーカー（ＳＷ）に通知する処理である。
　なお、図には、ステップＳ３２８ａ～ｄの４本のイベント通知ラインを示しているが、ステップＳ３２８ａ，ｂについては、データ送信を実行したいずれかの装置がイベント通知を実行すればよい。
　また、ステップＳ３２８ｃ，ｄのミドルウェアからの通知処理は、トークン情報設定要求の発行元、すなわちアプリケーションまたはサービスワーカー（ＳＷ）のいずれかのみに対して実行すればよい。

　上述の処理シーケンスにおいて、プッシュＡＰＩによるトークン（もしくはファイルＵＲＬ）設定ならびにプッシュイベント依頼のイベントは、ＡＴＳＣ３．０クライアント放送ミドルウェア上に実装されるプッシュイベトサーバ（パブリッシャー）に登録される。プッシュイベントサーバは、必要に応じて、ネット経由で、送信装置に対して、プッシュイベント依頼のイベントを登録する。

　ミドルウェアは、設定されたトークン（もしくはファイルＵＲＬ）によってフィルタされたデータがプロキシサーバ上に展開されると、プッシュイベントをプッシュイベントクライアント（アプリケーションもしくはサービスワーカー（ＳＷ））に通知する。

　ブラウザ側では、イベントを受けるとすぐに取得要求（ブラウザキャッシュへの引き込み）を行うことができるため、これにより、放送経由でクライアント側にファイルが蓄積されると即座にブラウザ側で利用することが可能となる。また、プッシュイベントをネット経由で送受できるようにすることは、クライアント放送ミドルウェアが当該ファイル転送ストリームにチューンしていない場合でも、クライアント側でファイル転送の事実を検知することができるようにするためである。

　　［８．３．サービスワーカー（ＳＷ）の更新処理について］
　次に、プッシュ型の処理を実行する場合のサービスワーカー（ＳＷ）の更新処理について説明する。
　前述したように、サービスワーカー（ＳＷ）には、利用期限を定めることができ、受信装置３０は、必要に応じて、受信装置の保持する利用期限の来たサービスワーカー（ＳＷ）を新たなサービスワーカー（ＳＷ）に置き換えるサービスワーカー（ＳＷ）更新処理を行なうことができる。

　ポーリング型のサービスワーカー（ＳＷ）更新処理シーケンスは、先に図１８～図１９を参照して説明したシーケンスとなる。
　プッシュ型処理では、ミドルウェアの管理キャッシュに対して更新サービスワーカー（ＳＷ）の展開（格納）が実行された場合に、キャッシュ展開をブラウザ側に通知させるプッシュＡＰＩ等を利用したプッシュ型イベント通知機構を利用した処理を行なう。

　プッシュ型処理におけるサービスワーカー更新処理シーケンスについて、図２４を参照して説明する。
　図２４には、左から、以下の各構成要素を示している。
　（ａ）送信装置を構成する放送サーバ
　（ｂ）送信装置を構成するデータ配信サーバ
　（ｃ）受信装置のミドルウェア
　（ｄ）受信装置の出力制御部で実行されるブラウザ
　さらに、
　（ｅ）受信装置の出力制御部で実行されるブラウザ上で実行されるサービスワーカー（ＳＷ）
　これらの各構成要素を示している。
　図２４のシーケンス図に示す各ステップの処理について、順次、説明する。

　なお、図２４のシーケンスの開始以前に、既に、先に説明した図２２に示すと同様の各装置、構成部間で、イベント登録、承諾処理が実行されているものとする。
　すなわち、アプリケーション、ミドルウェア間、およびミドルウェアと送信装置（放送サーバ、データ配信サーバ）間において、例えば図２２に示すステップＳ３２１ａ，ｂに示すイベント登録、承諾処理が実行されている。
　これは、送信装置（放送サーバ、データ配信サーバ）から受信装置に送信されたデータ（アプリケーション、アブリケーション関連データ、サービスワーカ（ＳＷ）等）が、ミドルウェアのプロキシサーバ管理キャッシュに展開（格納）された場合に、アプリケーションに通知する処理の実行を各装置または構成部が承諾して実行することを確認する処理である。

　図２４に示すシーケンスは、これらのイベント登録、承諾処理が実行された後の処理に相当する。
　図２４のシーケンス図に示す各ステップの処理について、順次、説明する。

　　（ステップＳ３５１）
　ステップＳ３５１ａ～ｄは、送信装置（放送サーバ、データ配信サーバ）から受信装置に送信されたデータ（本例では、更新サービスワーカー（ＳＷ））が、ミドルウェアのプロキシサーバ管理キャッシュに展開（格納）されたことを、アプリケーション、またはサービスワーカー（ＳＷ）に通知する処理である。
　なお、図には、ステップＳ３５１ａ～ｄの４本のイベント通知ラインを示しているが、ステップＳ３５１ａ，ｂについては、データ送信を実行したいずれかの装置がイベント通知を実行すればよい。
　また、ステップＳ３５１ｃ，ｄのミドルウェアからの通知処理は、アプリケーションまたはサービスワーカー（ＳＷ）のいずれかのみに対して実行すればよい。

　　（ステップＳ３５２）
　ステップＳ３５２は、受信装置の出力制御部で実行されるブラウザの処理である。
　ブラウザは、イベント通知に基づいて、更新サービスワーカー（ＳＷ）のローカルプロキシサーバに対する取得リクエストを行う。

　　（ステップＳ３５３）
　ステップＳ３５３の処理は、受信装置３０のミドルウェアの処理である。ミドルウェアは、プロキシサーバの管理キャッシュに、ブラウザから取得要求のあった更新されたサービスワーカー（ＳＷ）の検索を行い、検出された場合、更新されたサービスワーカー（ＳＷ）をブラウザに出力する。

　　（ステップＳ３５４）
　ステップＳ３５４は、受信装置の出力制御部で実行されるブラウザの処理である。
　ブラウザは、プロキシサーバから受領した更新後のサービスワーカー（ＳＷ）を登録する。すなわち、記憶部（永続キャッシュ）に格納する。

　　（ステップＳ３５５）
　ステップＳ３５５は、受信装置の出力制御部で実行されるサービスワーカー（ＳＷ）の処理である。ここでは、新たに登録された更新後のサービスワーカー（ＳＷ）の処理を示している。
　更新後のサービスワーカー（ＳＷ）は、必要に応じて、トークン情報の設定要求をミドルウェアに対して実行する。
　トークン情報の設定は、前述した図１１のステップＳ２５１の処理と同様の処理である。すなわち、例えば図７に示すミドルウェア１１０のシグナリング解析部１１３に対して、シグナリングデータに含まれるどのクラスのサービスワーカー（ＳＷ）アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部１１３に検出すべきクラスのサービスワーカー（ＳＷ）のアクセス情報を判別可能な状態に設定する。

　なお、このステップＳ３５５の処理に並行して、ステップＳ３５５ａに示すイベント登録／承諾処理を実行する。これは、トークン情報に応じたデータがミドルウェアのプロキシサーバに展開（格納）された場合に、サービスワーカー（ＳＷ）またはアプリケーションに通知させるための処理である。

　　（ステップＳ３５６）
　ステップＳ３５６の処理は、受信装置３０のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、更新後のサービスワーカー（ＳＷ）から通知されたトークン情報を設定し、設定したトークン情報に基づいて、シグナリングデータからのトークン（もしくはファイルＵＲＬ）検出を実行する。

　　［８．４．サービスワーカー（ＳＷ）による受信装置の記憶部（永続キャッシュ）の制御処理について］
　プッシュ型処理においても、受信装置３０に格納されたサービスワーカー（ＳＷ）による受信装置の記憶部（永続キャッシュ）の制御処理シーケンスは、先に図２０～図２１を参照して説明したポーリング型の処理例と同様の処理となる。

　　［９．トークンを記述するシグナリングデータ（メタデータ）の構成について］
　先に、図１４～図１７を参照して説明したように、例えば放送サーバ２１等の送信装置２０から送信されるシグナリングデータ（メタデータ）には、受信装置３０における取得データの選択を効率化するためのトークン（もしくはＵＲＬ）が記述されている。

　以下、シグナリングデータ（メタデータ）に対するトークン（もしくはＵＲＬ）の具体的な記録構成例について説明する。
　図２５は、例えば放送サーバ２１等の送信装置２０から送信されるシグナリングデータ（メタデータ）の構成例を示す図である。

　シグナリングデータ（メタデータ）は、図２５に示すように、以下の３つのレイヤを持つ。
　（１）サービスレイヤ（ＯＭＡ－ＥＳＧ）
　（２）ファイル転送セッションレイヤ（３ＧＰＰ－ＭＢＭＳ－ＵＳＤ）
　（３）ＦＬＵＴＥ（ＲＯＵＴＥ）パラメータレイヤ（ＦＬＵＴＥ（ＲＯＵＴＥ））

　（１）サービスレイヤは、特にユーザ提示を目的としたサービスやコンテンツの属性情報を記述するレイヤである。
　（２）ファイル転送セッションレイヤは、ファイルの転送パラメータ等を記述するレイヤである。
　（３）ＦＬＵＴＥ（ＲＯＵＴＥ）パラメータレイヤは、ＦＬＵＴＥ（ＲＯＵＴＥ）プロトコル対応のパラメータを記述するレイヤである。

　（１）サービスレイヤは、いわゆる番組表等を記録するＯＭＡ－ＥＳＧ（Ｏｐｅｎ　Ｍｏｂｉｌｅ　Ａｌｌｉａｎｃｅ－Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）以下に、例えば以下の属性情報（要素）記録領域（フラグメント）が設定されている。
　（ａ）サービス・フラグメント（Ｓｅｒｖｉｃｅ　Ｆｒａｇｍｅｎｔ）
　（ｂ）コンテンツ・フラグメント（Ｃｏｎｔｅｎｔ　Ｆｒａｇｍｅｎｔ）
　（ｃ）インタラクティビティデータ・フラグメント（ＩｎｔｅｒａｃｔｉｖｉｔｙＤａｔａ　Ｆｒａｇｍｅｎｔ）
　（ｄ）スケジュール・フラグメント（Ｓｃｈｅｄｕｌｅ　Ｆｒａｇｍｅｎｔ）
　（ｅ）アクセス・フラグメント（Ａｃｃｅｓｓ　Ｆｒａｇｍｅｎｔ）

　これらは、それぞれ異なる種類の属性情報を記録する領域として区分されている。
　なお、ＯＭＡ－ＥＳＧには、この他にも複数の属性情報（要素）記録領域（フラグメント）が設定されるが、上記の（ａ）～（ｅ）の属性情報（要素）記録領域（フラグメント）を前述したトークンの記録領域として設定した例について、後段で説明する。

　なお、図に示す矢印は、各属性情報（要素）記録領域（フラグメント）間の参照関係を示している。
　例えば（ａ）サービス・フラグメントから、（ｄ）スケジュール・フラグメントに延びる矢印は、（ａ）サービス・フラグメントに記録された個々のサービス（例えばチャンネルや番組）対応の配信スケジュール情報が（ｄ）スケジュール・フラグメントに記録されていることを示す。

　また、ファイル転送セッションレイヤは、サービス単位のシグナリングデータであるＵＳＤ（ユーザサービスディスクリプション）以下に例えば以下の属性情報（要素）記録領域（フラグメント）が設定されている。
　（ｆ）スケジュール・フラグメント（Ｓｃｈｅｄｕｌｅ　Ｆｒａｇｍｅｎｔ）
　（ｇ）フィルタディスクリプション・フラグメント（ＦｉｌｔｅｒＤｅｓｃｒｉｐｔｉｏｎ　Ｆｒａｇｍｅｎｔ）

　ＵＳＤ（ユーザサービスディスクリプション）には、この他にも複数の属性情報（要素）記録領域（フラグメント）が設定されるが、上記の（ｆ）～（ｇ）の属性情報（要素）記録領域（フラグメント）を前述したトークンの記録領域として設定した例について、後段で説明する。

　　［９．１．シグナリングデータ（メタデータ）を構成するＯＭＡ－ＥＳＧに対するトークン記録例について］
　先に図２５を参照して説明したように、
　シグナリングデータ（メタデータ）は、図２５に示すように、以下の３つのレイヤを持つ。
　（１）サービスレイヤ（ＯＭＡ－ＥＳＧ）
　（２）ファイル転送セッションレイヤ（３ＧＰＰ－ＭＢＭＳ－ＵＳＤ）
　（３）ＦＬＵＴＥ（ＲＯＵＴＥ）パラメータレイヤ（ＦＬＵＴＥ（ＲＯＵＴＥ））

　まず、（１）サービスレイヤ（ＯＭＡ－ＥＳＧ）に対するトークン記録例について説明する。
　サービスレイヤ（ＯＭＡ－ＥＳＧ）に設定される属性情報（要素）記録領域（フラグメント）のうちトークンを格納するのにふさわしいフラグメントには、前述したように、以下の属性情報（要素）記録領域（フラグメント）がある。
　（ａ）サービス・フラグメント（Ｓｅｒｖｉｃｅ　Ｆｒａｇｍｅｎｔ）
　（ｂ）コンテンツ・フラグメント（Ｃｏｎｔｅｎｔ　Ｆｒａｇｍｅｎｔ）
　（ｃ）インタラクティビティデータ・フラグメント（ＩｎｔｅｒａｃｔｉｖｉｔｙＤａｔａ　Ｆｒａｇｍｅｎｔ）
　（ｄ）スケジュール・フラグメント（Ｓｃｈｅｄｕｌｅ　Ｆｒａｇｍｅｎｔ）
　（ｅ）アクセス・フラグメント（Ａｃｃｅｓｓ　Ｆｒａｇｍｅｎｔ）

　（ａ）サービス・フラグメント（Ｓｅｒｖｉｃｅ　Ｆｒａｇｍｅｎｔ）は、チャネルやストリーミングサービスというようなサービスレイヤの属性を記述するフラグメントである。
　（ｂ）コンテンツ・フラグメント（Ｃｏｎｔｅｎｔ　Ｆｒａｇｍｅｎｔ）は、サービス・フラグメント（Ｓｅｒｖｉｃｅ　Ｆｒａｇｍｅｎｔ）を構成する各々のコンテンツ（サービスがチャネルを記述する場合は番組等の単位）を記述するフラグメントである。

　（ｄ）スケジュール・フラグメント（Ｓｃｈｅｄｕｌｅ　Ｆｒａｇｍｅｎｔ）は、サービス（Ｓｅｒｖｉｃｅ）、コンテンツ（Ｃｏｎｔｅｎｔ）、インタラクティビティデータ（ＩｎｔｅｒａｃｔｉｖｉｔｙＤａｔａ）を時間軸上（番組配信スケジュール、番組提示スケジュール等）にマッピングするためのフラグメントである。

　（ｅ）アクセス・フラグメント（Ａｃｃｅｓｓ　Ｆｒａｇｍｅｎｔ）は、スケジュール（Ｓｃｈｅｄｕｌｅ）フラグメントの配信スケジュールとともに実際のファイルやストリームのアドレスを記述するためのフラグメントである。

　これら、各々の属性情報（要素）記録領域（フラグメント）には、様々なデータを記録可能な拡張領域であるプライベート・エクステンション（ＰｒｉｖａｔｅＥｘｔｅｎｓｉｏｎ）要素が設定されている。
　例えば、ＯＭＡとは異なる標準化団体において、このスキーマ定義を利用して機能要素を追加するために新たな要素が必要となった場合には、この拡張領域下に、様々な要素を追加規定することができる。ただし、ＯＭＡ自身でスキーマを拡張する場合、もしくは、他の標準化団体自身が全体のスキーマを変更できる場合には追加要素そのものをプライベート・エクステンション（ＰｒｉｖａｔｅＥｘｔｅｎｓｉｏｎ）要素上に格納するように定義される。

　例えば、（ａ）サービス・フラグメント（Ｓｅｒｖｉｃｅ　Ｆｒａｇｍｅｎｔ）は、図２６に示す構成を有する。
　図２６に示すように、プライベート・エクステンション（ＰｒｉｖａｔｅＥｘｔｅｎｓｉｏｎ）データ記録領域２０１の下位にトークン記録領域２０２を設定することができる。

　これは、例えば先に図１５を参照して説明した図１５（１）トークン設定例１に示すサービスメタデータ１６１に、「サービスワーカー（ＳＷ）検索スコープトークン＜ＳＷ－Ｓｃｏｐｅ＞」を記録する場合の例に対応する。

　図２６に示すトークン記録領域２０２には、トークンを例えば、ＸＭＬデータとして記録する。
　トークンのＸＭＬスキーマ定義は、例えば、以下の設定とする。
　＜ｘｓ：ｅｌｅｍｅｎｔ　ｎａｍｅ＝"ＳＷＣｌａｓｓ"　ｔｙｐｅ＝"ｘｓ：ｓｔｒｉｎｇ"　ｘｍｌｎｓ：ｘｓ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ"／＞
　上記設定の文字列表現としてエンコードする。

　また、サービス・フラグメント（Ｓｅｒｖｉｃｅ　Ｆｒａｇｍｅｎｔ）のＸＭＬインスタンスの例は、例えば以下の設定となる。
　＜Ｓｅｒｖｉｃｅ＞
　・・・
　＜ＰｒｉｖａｔｅＥｘｔ＞
　　＜ＳＷＣｌａｓｓ＞ＳＷクラスの文字列＜／ＳＷＣｌａｓｓ＞
　＜／ＰｒｉｖａｔｅＥｘｔ＞
＜／Ｓｅｒｖｉｃｅ＞

　　［９．２．シグナリングデータ（メタデータ）を構成するＵＳＤに対するトークン記録例について］
　先に図２５を参照して説明したように、
　シグナリングデータ（メタデータ）は、図２５に示すように、以下の３つのレイヤを持つ。
　（１）サービスレイヤ（ＯＭＡ－ＥＳＧ）
　（２）ファイル転送セッションレイヤ（３ＧＰＰ－ＭＢＭＳ－ＵＳＤ）
　（３）ＦＬＵＴＥ（ＲＯＵＴＥ）パラメータレイヤ（ＦＬＵＴＥ（ＲＯＵＴＥ））

　以下、（２）ファイル転送セッションレイヤ（３ＧＰＰ－ＭＢＭＳ－ＵＳＤ）にトークンを記録する例について説明する。
　サービス単位のシグナリングデータであるＵＳＤ（ユーザサービスディスクリプション）に設定される属性情報（要素）記録領域（フラグメント）のうちトークンを格納するのにふさわしいフラグメントには、前述したように、以下の属性情報（要素）記録領域（フラグメント）がある。
　（ｆ）スケジュール・フラグメント（Ｓｃｈｅｄｕｌｅ　Ｆｒａｇｍｅｎｔ）
　（ｇ）フィルタディスクリプション・フラグメント（ＦｉｌｔｅｒＤｅｓｃｒｉｐｔｉｏｎ　Ｆｒａｇｍｅｎｔ）

　ＵＳＤ（ユーザサービスディスクリプション）はサービスを構成するトランスポートセッションの属性を格納するハブ的な要素である。
　ＵＳＤ（ユーザサービスディスクリプション）の全体構成例を図２７に示す。
　ＵＳＤ（ユーザサービスバンドルディスクリプション）２１０は、複数のＵＳＤ（ユーザサービスディスクリプション）２１１の集合である。
　図２７に示す白抜きひし形の矢印は、白抜き矢印側の要素が接続要素を含む（ｉｎｃｌｕｄｅ）ことを意味する。
　通常矢印は、参照（ｒｅｆｅｒｅｎｃｅ）関係を示す。

　ＵＳＤ（ユーザサービスディスクリプション）２１１の下位には、
　スケジュール（Ｓｃｈｅｄｕｌｅ）要素２１２が設定される。なお、要素は、フラグメントと同意である。
　スケジュール（Ｓｃｈｅｄｕｌｅ）要素２１２の回に、スケジュールディスクリプション（Ｓｃｈｅｄｕｌｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）要素２１３、さらに、その下意にフィルタディスクリプション（Ｆｉｌｔｅｒ　Ｄｅｓｃｒｉｐｔｉｏｎ）要素２１４が設定される。

　ＵＳＤ要素２１１の下のスケジュール（Ｓｃｈｅｄｕｌｅ）要素２１２は、トランスポートセッションの配信スケジュールを記述する。このスケジュール（Ｓｃｈｅｄｕｌｅ）要素２１２から参照されるスケジュールディスクリプション（Ｓｃｈｅｄｕｌｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）要素２１３から、このスケジュールで配信されるサービス（ストリームセッションやファイルセッション）を選択的に取得する際に利用するフィルタリングに利用するパラメータを格納するフィルタディスクリプション（ＦｉｌｔｅｒＤｅｓｃｒｉｐｔｉｏｎ）要素２１４を参照させることができる。

　図２８に、シグナリングデータを構成するＵＳＤ（ユーザサービスバンドルディスクリプション）２１０以下の階層構成例を示す。
　ＵＳＤ（ユーザサービスバンドルディスクリプション）２１０以下、
　ＵＳＤ（ユーザサービスディスクリプション）要素２１１、
　スケジュール（Ｓｃｈｅｄｕｌｅ）要素２１２
　これらの各要素が設定される。

　スケジュール（Ｓｃｈｅｄｕｌｅ）要素２１２の中に、スケジュールディスクリプション（Ｓｃｈｅｄｕｌｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）要素２１３の識別情報としてのスケジュールディスクリプションＵＲＩ　２１２ａが記録される。
　このスケジュールディスクリプションＵＲＩ　２１２ａに基づいて、スケジュールディスクリプション（Ｓｃｈｅｄｕｌｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）要素２１３が特定される。

　なお、ＵＳＤ（ユーザサービスディスクリプション）要素２１１以下に設定されるデリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）要素にはＦＬＵＴＥ（ＲＯＵＴＥ）への参照情報が格納される。この構成については後述する。

　図２９は、スケジュールディスクリプション（Ｓｃｈｅｄｕｌｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）要素２１３以下のシグナリングデータ構成を示す図である。
　スケジュールディスクリプション（Ｓｃｈｅｄｕｌｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）要素２１３以下に、アトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）データ２２２が設定され、アトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）データ２２２内に、特定のフィルタディスクリプション要素を識別するための識別情報であるフィルタディスクリプションリファレンス（ｆｉｌｔｅｒ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｒｅｆｅｒｅｎｃｅ）２２３が記録される。

　また、スケジュールディスクリプション（Ｓｃｈｅｄｕｌｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）要素２１３以下に記録される１つのアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）データ２２４に、特定のフィルタを識別するための識別情報であるフィルタＩＤ（ｆｉｌｔｅｒ　ＩＤ）２２５が記録される。

　図３０は、フィルタディスクリプションリファレンス（ｆｉｌｔｅｒ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｒｅｆｅｒｅｎｃｅ）２２３によって特定されるフィルタディスクリプション（ｆｉｌｔｅｒ　Ｄｅｓｃｒｉｐｔｉｏｎ）要素２３１のデータ構成を示している。
　フィルタディスクリプション（ｆｉｌｔｅｒ　Ｄｅｓｃｒｉｐｔｉｏｎ）要素２３１以下には、各フィルタ対応のデータを設定するフィルタデータ（ｆｉｌｔｅｒＤａｔａ）要素２３２が設定される。
　さらに、フィルタデータ（ｆｉｌｔｅｒＤａｔａ）要素２３２のアトリビュート（属性）（ａｔｔｒｉｂｕｔｅ）２３３には、図２９のデータ構成に示すフィルタＩＤ（ｆｉｌｔｅｒ　ＩＤ）２２５に対応するｉｄデータ２３４が記録される。
　さらに、フィルタデータ（ｆｉｌｔｅｒＤａｔａ）要素２３２以下のデータ記録領域に上述したトークン２３５を記録する。

　これは、例えば先に図１７を参照して説明した図１７（４）トークン設定例４に示すスケジュールディスクリプション１６８に、「サービスワーカー（ＳＷ）検索スコープトークン＜ＳＷ－Ｓｃｏｐｅ＞」を記録する場合の例に対応する。

　トークン２３５は、例えば、ＸＭＬデータとして記録する。
　トークンのＸＭＬスキーマ定義は、例えば、以下の設定とする。
　＜ｘｓ：ｅｌｅｍｅｎｔ　ｎａｍｅ＝"ＳＷＣｌａｓｓ"　ｔｙｐｅ＝"ｘｓ：ｓｔｒｉｎｇ"　ｘｍｌｎｓ：ｘｓ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ"／＞
として、文字列表現としてエンコードする。

　また、フィルタディスクリプション（ｆｉｌｔｅｒＤｅｓｃｒｉｐｔｉｏｎ）フラグメントのＸＭＬインスタンスの例は、例えば以下の設定となる。
　＜ｆｉｌｔｅｒＤｅｓｃｒｉｐｔｉｏｎ＞
　　・・・
　　＜ｆｉｌｔｅｒＤａｔａ＞
　　　＜ＳＷＣｌａｓｓ＞ＳＷクラスの文字列＜／ＳＷＣｌａｓｓ＞
　　＜／ｆｉｌｔｅｒＤａｔａ＞
　＜／ｆｉｌｔｅｒＤｅｓｃｒｉｐｔｉｏｎ＞

　　［ＵＳＤからＦＬＵＴＥ／ＲＯＵＴＥへの参照処理例について］
　受信装置３０が、トークンを利用して選択取得するデータは、アプリケーション、およびアプリケーション関連データ、あるいはサービスワーカー（ＳＷ）等のファイルであり、これらは、ＦＬＵＴＥ／ＲＯＵＴＥプロトコルに従って転送される。
　受信装置３０は、例えば上述したシグナリングデータであるＵＳＤ等に記載されたトークンに基づいて、ＦＬＵＴＥ／ＲＯＵＴＥプロトコルに従って転送されるファイルを識別して取得することが必要となる。
　以下、この処理のための構成について、図３１以下を参照して説明する。

　図３１は、先に図２８を参照して説明したと同様、シグナリングデータを構成するＵＳＤ（ユーザサービスバンドルディスクリプション）２１０以下の階層構成例を示す図である。
　ＵＳＤ（ユーザサービスバンドルディスクリプション）２１０以下、
　ＵＳＤ（ユーザサービスディスクリプション）要素２１１、
　スケジュール（Ｓｃｈｅｄｕｌｅ）要素２１２
　これらの各要素が設定される。

　ＵＳＤ（ユーザサービスディスクリプション）要素２１１以下に設定されるデリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）要素２４１にＦＬＵＴＥ（ＲＯＵＴＥ）への参照情報が格納される。

　図３２は、ファイル転送をＦＬＵＴＥプロトコルに従って実行する場合に、デリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）要素２４１に設定されるＦＬＵＴＥへの参照情報の例を示す図である。

　図３２に示すように、デリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）要素２４１以下に設定されるアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）２４２のうち、セッションディスクリプションＵＲＩ（ｓｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ）属性２４３から参照されるＳＤＰとして、図３２に示す以下の情報が記録される。
ｖ＝・・・
ｏ＝・・・
ｓ＝・・・
ｔ＝・・・
ａ＝ＡＴＳＣ－ｍｏｄｅ：Ｆｒｅｑｕｅｎｃｙ　ＰｉｐｅＩＤ（ＢＢＰＳｔｒｅａｍＩＤ）　｛周波数とその周波数内のｍｏｄｕｌａｔｉｏｎ／ｃｏｄｉｎｇパラメータ等が異なる伝送パイプのＩＤ｝
ａ＝ｆｌｕｔｅ－ｔｓｉ：　（ＴＳＩ－ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ）
ｓ＝ｓｏｕｒｃｅＦｉｌｔｅｒ：　ＩＮ　ＩＰ４　ＩＰ　Ａｄｄｒｅｓｓ（ソースＩＰアドレス）
ｍ＝ＡＰＰＬＩＣＡＴＩＯＮ　ｐｏｒｔ（ポート番号）　ＦＬＵＴＥ／ＵＤＰ　
ｃ＝ＩＮ　ＩＰ４　ＩＰＡｄｄｒｅｓｓ（ディスティネーションＩＰアドレス）
　この情報に従って特定されるファイル特定構成を図３３に示す。

　ＦＬＵＴＥ（ＲＯＵＴＥ）プロトコルにより転送されるファイルは、いずれもＩＰパケットの上のＵＤＰパケットの上のＬＣＴパケットに格納されて転送される。
　ＦＬＵＴＥの場合は、ＳＤＰで指示されるソースＩＰアドレス（ＳｏｕｒｃｅＩＰＡｄｄｒｅｓｓ）、ディスティネーションＩＰアドレス（ＤｅｓｔｉｎａｔｉｏｎＩＰＡｄｄｒｅｓｓ）、ポート番号（Ｐｏｒｔ）、ＴＳＩにて特定される。これは、ＦＬＵＴＥセッション単位で実行される）。

　ソースＩＰアドレス（ＳｏｕｒｃｅＩＰＡｄｄｒｅｓｓ）、ディスティネーションＩＰアドレス（ＤｅｓｔｉｎａｔｉｏｎＩＰＡｄｄｒｅｓｓ）がＩＰパケットの特定に、ホート番号（Ｐｏｒｔ）がＵＤＰパケットの特定に、ＴＳＩがＬＣＴパケット列の特定に利用される。
　また、ＬＣＴパケットに格納されるＴＯＩ（ＴｒａｎｓｐｏｒｔＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒ）により所望のファイルが特定される。
　ＴＯＩが０のＬＣＴパケットにはＦＤＴ（Ｆｉｌｅ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｔａｂｌｅ）が格納され、同じＴＳＩで特定されるトランスポートセッションの内の他のファイルオブジェクトについて、各々のファイルＵＲＬ（ＦＤＴ－Ｉｎｓｔａｎｃｅ／Ｆｉｌｅ／＠ＣｏｎｔｅｎｔＬｏｃａｔｏｉｎに格納）と、対応するＴＯＩ（ＦＤＴ－Ｉｎｓｔａｎｃｅ／Ｆｉｌｅ／＠ＴＯＩに格納）との関係が解決される。

　一方、図３４は、ファイル転送をＲＯＵＴＥプロトコルに従って実行する場合に、デリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）要素２４１に設定されるＦＬＵＴＥへの参照情報の例を示す図である。

　図３４に示すように、デリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）要素２４１以下に設定されるアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）２４２のうち、セッションディスクリプションＵＲＩ（ｓｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ）属性２４３から参照されるＳＤＰとして、図３４に示す以下の情報が記録される。
ｖ＝・・・
ｏ＝・・・
ｓ＝・・・
ｔ＝・・・
ａ＝ＡＴＳＣ－ｍｏｄｅ：　Ｆｒｅｑｕｅｎｃｙ　ＰｉｐｅＩＤ（ＢＢＰＳｔｒｅａｍＩＤ）　｛周波数とその周波数内のｍｏｄｕｌａｔｉｏｎ／ｃｏｄｉｎｇパラメータ等が異なる伝送パイプのＩＤ｝
ｓ＝ｓｏｕｒｃｅＦｉｌｔｅｒ：　ＩＮ　ＩＰ４　ＩＰ　Ａｄｄｒｅｓｓ（ソースＩＰアドレス）
ｍ＝ＡＰＰＬＩＣＡＴＩＯＮ　ｐｏｒｔ（ポート番号）　ＲＯＵＴＥ／ＵＤＰ　
ｃ＝ＩＮ　ＩＰ４　ＩＰＡｄｄｒｅｓｓ（ディスティネーションＩＰアドレス）
　この情報に従って特定されるファイル特定構成を図３５に示す。

　ＲＯＵＴＥの場合は、ＳＤＰで指示されるソースＩＰアドレス（ＳｏｕｒｃｅＩＰＡｄｄｒｅｓｓ）、ディスティネーションＩＰアドレス（ＤｅｓｔｉｎａｔｉｏｎＩＰＡｄｄｒｅｓｓ）、ポート番号（Ｐｏｒｔ）にて特定される。これは、ＲＯＵＴＥセッション単位で実行される。
　ソースＩＰアドレス（ＳｏｕｒｃｅＩＰＡｄｄｒｅｓｓ）、ディスティネーションＩＰアドレス（ＤｅｓｔｉｎａｔｉｏｎＩＰＡｄｄｒｅｓｓ）がＩＰパケットの特定に、Ｐｏｒｔ番号がＵＤＰパケットの特定に利用される。

　ＲＯＵＴＥセッションには、ＬＣＴパケットのＴＳＩが０でＴＯＩが０であるＬＣＴパケットにＬＳＩＤ（ＬＣＴ　Ｓｅｓｓｉｏｎ　Ｉｎｓｔａｎｃｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）が格納され、ＲＯＵＴＥセッション内の他のトランスポートセッション（ＬＣＴパケットのＴＳＩで特定される）についての属性が格納される。ＬＳＩＤのＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ／ＳｏｕｒｃｅＦｌｏｗ／ＥＦＤＴ／Ｆｉｌｅ要素の属性であるＣｏｎｔｅｎｔＬｏｃａｔｉｏｎ属性とＴＯＩ属性によりファイルＵＲＬと対応するＴＯＩとの関係が解決される。

　クライアントミドルウェアは、ＦＬＵＴＥのＦＤＴ（ＦＤＴ－Ｉｎｓｔａｎｃｅ）もしくはＲＯＵＴＥのＬＳＩＤをパース（解析）してそのファイル転送セッションで転送されるファイルＵＲＬがわかる。

　　［９．３．シグナリングデータ（メタデータ）を構成するＦＬＵＴＥ（ＲＯＵＴＥ）パラメータレイヤに対するトークン記録例について］
　先に図２５を参照して説明したように、
　シグナリングデータ（メタデータ）は、図２５に示すように、以下の３つのレイヤを持つ。
　（１）サービスレイヤ（ＯＭＡ－ＥＳＧ）
　（２）ファイル転送セッションレイヤ（３ＧＰＰ－ＭＢＭＳ－ＵＳＤ）
　（３）ＦＬＵＴＥ（ＲＯＵＴＥ）パラメータレイヤ（ＦＬＵＴＥ（ＲＯＵＴＥ））

　以下、（３）ＦＬＵＴＥ（ＲＯＵＴＥ）パラメータレイヤ（ＦＬＵＴＥ（ＲＯＵＴＥ））にトークンを記録する例について説明する。

　ＦＬＵＴＥ（ＲＯＵＴＥ）パラメータレイヤにおいて、トークンを格納するのにふさわしい要素には、ＦＬＵＴＥファイル転送セッション全体を記述するＦＤＴインスタンス（ＦＤＴ－Ｉｎｓｔａｎｃｅ）要素、もしくは、そのセッションの中で運ばれる個々のファイルの属性を記述するファイル（Ｆｉｌｅ）要素がある。
　例えばファイル（Ｆｉｌｅ）要素の属性であるコンテンツロケーション（Ｃｏｎｔｅｎｔ－Ｌｏｃａｔｉｏｎ）属性に、ファイルＵＲＬが格納される。
　このＦＤＴ－Ｉｎｓｔａｎｃｅ要素の属性、もしくは、Ｆｉｌｅ要素の属性にトークンを記録する構成について、図３６以下を参照して説明する。

　図３６は、シグナリングデータを構成するＦＬＵＴＥ（ＲＯＵＴＥ）パラメータレイヤ内のＦＤＴインスタンス要素以下のデータ格納構成を示す図である。
　ＦＤＴインスタンス（ＦＤＴ　Ｉｎｓｔａｎｃｅ）要素３０１以下に、
　ＦＤＴインスタンス対応のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）３０２、
　ファイル（Ｆｉｌｅ）要素３０３が設定される。
　さらに、ファイル（Ｆｉｌｅ）要素３０３以下に、
　ファイル対応のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）３０４が設定される。

　ＦＤＴインスタンス対応のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）３０２と、
　ファイル対応のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）３０４、
　これらの詳細構成を図３７に示す。

　図３７に示すように、これらのアトリビュート（属性）記録領域には、規定の属性（Ａｔｔｒｉｂｕｔｅ）情報の記録領域の他、自由なデータを格納可能なデータ記録フィールド（ａｎｙ）が設定される。
　このデータ記録フィールド（ａｎｙ）３１１，３１２にトークンを記録する。

　このトークン記録例は、例えば先に図１５を参照して説明した図１５（１）トークン設定例１に示す最下層のＲＯＵＴＥメタデータ１６２，１６３に、「サービスワーカー（ＳＷ）クラス指定トークン＜ＳＷ－Ｃｌａｓｓ＞」を記録する場合の例に対応する。

　なお、ファイル対応のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）３０４内の既定のコンテンツロケーション（Ｃｏｎｔｅｎｔ－Ｌｏｃａｔｉｏｎ）記録領域にはファイルＵＲＬが記録される。

　ＦＤＴインスタンス対応のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）３０２と、ファイル対応のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）３０４内のデータ記録フィールド（ａｎｙ）３１１，３１２に記録するトークンは、例えば、ＸＭＬデータとして記録する。
　トークンのＸＭＬスキーマ定義は、例えば、以下の設定とする。
　＜ｘｓ：ａｔｔｒｉｂｕｔｅ　ｎａｍｅ＝"ＳＷＣｌａｓｓ"ｔｙｐｅ＝"ｘｓ：ｓｔｒｉｎｇ"　ｘｍｌｎｓ：ｘｓ＝"ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ"／＞
　上記設定の文字列表現としてエンコードする。

　トークンを図３７（ａ）に示すように、ＦＤＴインスタンス（ＦＤＴ－Ｉｎｓｔａｎｃｅ）要素に格納した場合のＸＭＬインスタンスの例は、例えば以下の設定となる。
　＜ＦＤＴ－Ｉｎｓｔａｎｃｅ・・ＳＷＣｌａｓｓ＝"ＳＷクラスの文字列"・・・＞
　・・・
　＜／ＦＤＴ－Ｉｎｓｔａｎｃｅ＞

　なお、ＦＤＴインスタンス（ＦＤＴ－Ｉｎｓｔａｎｃｅ）要素の属性に例えば「サービスワーカー（ＳＷ）検索スコープトークン＜ＳＷ－Ｓｃｏｐｅ＞」が配置された場合には、このファイル転送セッションの中のファイルのいずれかに所望のサービスワーカー（ＳＷ）関連ファイルが格納されていることを示す。
　一方、「サービスワーカー（ＳＷ）クラス指定トークン＜ＳＷ－Ｃｌａｓｓ＞」が配置された場合には、このファイル転送セッションの中のすべてのファイルが所望のサービスワーカー（ＳＷ）関連ファイルであることを示す。

　トークンを図３７（ｂ）に示すように、また、ファイル（Ｆｉｌｅ）要素に格納した場合のＸＭＬインスタンスの例は、以下のようになる。
　＜ＦＤＴ－Ｉｎｓｔａｎｃｅ＞
　・・・
　　＜Ｆｉｌｅ・・・ＳＷＣｌａｓｓ＝"ＳＷクラスの文字列"・・・＞
　・・・
　＜／ＦＤＴ－Ｉｎｓｔａｎｃｅ＞

　ファイル（Ｆｉｌｅ）要素の属性には、「サービスワーカー（ＳＷ）クラス指定トークン＜ＳＷ－Ｃｌａｓｓ＞」のみが配置可能であり、このファイルが所望のサービスワーカー（ＳＷ）関連ファイルであることを示す。

　一方、ＲＯＵＴＥについては、ＲＯＵＴＥで規定しているシグナリングデータとしてのＬＳＩＤの中にＦＬＵＴＥで規定しているＦｉｌｅ要素が格納される。
　図３８にＲＯＵＴＥで規定しているＬＳＩＤ以下のデータ構成を示す。
　図３８に示すように、
　ＬＳＩＤ要素３５１、
　トランスポートセッション（ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ）要素３５２、
　ソースフロー（ＳｏｕｒｃｅＦｌｏｗ）要素３５３、
　ＥＦＤＴ要素３５４、
　ファイル（Ｆｉｌｅ）要素３５５、
　これらの階層設定となる。

　このため、サービスワーカー（ＳＷ）トークン（ＳＷ検索スコープトークン、ＳＷクラス指定トークン）を格納するのにふさわしい要素としては、以下の要素がある。
　（ａ）ＥＦＤＴ要素３５４単位のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）データ要素３６１、
　（ｂ）ファイル（ｆｉｌｅ）３５５単位のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）データ要素３６２、
　（ｃ）ＥＦＤＴ要素３５４単位のアプリケーション識別子（ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ）要素３６３
　これらの各要素が候補となる。

　（ａ）ＥＦＤＴ要素３５４単位のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）データ要素３６１、
　（ｂ）ファイル（Ｆｉｌｅ）３５５単位のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）データ要素３６２、
　これらの詳細構成を図３９に示す。

　図３９に示すように、これらのアトリビュート（属性）記録領域には、規定の属性（Ａｔｔｒｉｂｕｔｅ）情報の記録領域の他、自由なデータを格納可能なデータ記録フィールド（ａｎｙ）が設定される。
　このデータ記録フィールド（ａｎｙ）３７１，３７２にトークンを記録する。

　なお、ファイル対応のアトリビュート（属性）（Ａｔｔｒｉｂｕｔｅ）３６２内の既定のコンテンツロケーション（Ｃｏｎｔｅｎｔ－Ｌｏｃａｔｉｏｎ）記録領域にはファイルＵＲＬが記録される。

　トークンを図３９（ａ）に示すように、ＥＦＤＴインスタンス（ＥＦＤＴ－Ｉｎｓｔａｎｃｅ）要素に格納した場合のＸＭＬインスタンスの例は、例えば以下の設定となる。
　＜ＬＳＩＤ＞
　・・・
　　＜ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ＞
　・・・
　　＜ＳｏｕｒｃｅＦｌｏｗ＞
　　　・・・
　　　　＜ＥＦＤＴ　…　ＳＷＣｌａｓｓ＝"ＳＷクラスの文字列"・・・　＞
　　　　　・・・
　　　　＜／ＥＦＤＴ＞
　　　　・・・
　　　＜／ＳｏｕｒｃｅＦｌｏｗ＞
　　・・・
　　＜／ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ＞
　　・・・
　＜／ＬＳＩＤ＞

　また、トークンを、図３８に示すＥＦＤＴ要素３５４単位のアプリケーション識別子（ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ）要素３６３に格納した場合のＸＭＬインスタンスの例は、以下のようになる。
　＜ＬＳＩＤ＞
　　・・・
　　＜ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ＞
　　・・・
　　＜ＳｏｕｒｃｅＦｌｏｗ＞
　　・・・
　　　　＜ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ＞ＳＷクラスの文字列＜ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ＞
　　・・・
　　　＜／ＳｏｕｒｃｅＦｌｏｗ＞
　　・・・
　　＜／ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ＞
　　・・・
　＜／ＬＳＩＤ＞

　ＬＳＩＤ／ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎ／ＳｏｕｒｃｅＦｌｏｗ／ＡｐｐｌｉｃａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ要素に「サービスワーカー（ＳＷ）検索スコープトークン＜ＳＷ－Ｓｃｏｐｅ＞」が配置された場合には、このファイル転送セッションの中のファイルのいずれかに所望のサービスワーカー（ＳＷ）関連ファイルが格納されていることを示す。
　一方、「サービスワーカー（ＳＷ）クラス指定トークン＜ＳＷ－Ｃｌａｓｓ＞」が配置された場合には、このファイル転送セッションの中のすべてのファイルが所望のサービスワーカー（ＳＷ）関連ファイルであることを示す。

　さらに、トークンを図３９（ｂ）に示すように、ファイル（Ｆｉｌｅ）要素に格納した場合のＸＭＬインスタンスの例は、例えば以下の設定となる。
　＜ＥＦＤＴ＞
　　・・・
　　＜Ｆｉｌｅ　…　ＳＷＣｌａｓｓ＝"ＳＷクラスの文字列"・・・　＞
　　・・・
　＜／ＥＦＤＴ　＞

　なお、ファイル（Ｆｉｌｅ）要素の属性には、「サービスワーカー（ＳＷ）クラス指定トークン＜ＳＷ－Ｃｌａｓｓ＞」のみが配置可能であり、このファイルが所望のサービスワーカー（ＳＷ）関連ファイルであることを示す。

　　［１０．サービスワーカー（ＳＷ）の利用可能なＡＰＩによるキャッシングの最適化処理例について］
　次に、受信装置３０において実行するサービスワーカー（ＳＷ）の利用可能なＡＰＩによるキャッシングの最適化処理例について説明する。

　前述した実施例は、サービスワーカー（ＳＷ）をクラス分類して、サービスワーカー（ＳＷ）自体をキャッシングポリシーごとに準備するモデルである。
　ひのモデルは、ポリシーの種類が少ない場合には、効果があるが、クライアントの環境に応じた非常にきめの細かな制御を行えるようにする場合には、サービスワーカー（ＳＷ）の種類（クラス）が膨大になる恐れがある。この問題に対処するため、サービスワーカー（ＳＷ）はできるだけ共通のもの（多くても数種類）を用意して、サービスワーカー（ＳＷ）のロジックの中で受信装置（クライアント）の環境属性を取得するＡＰＩを適用してキャッシングの最適化を実現することも可能である。
　すなわち、ＡＰＩを適用してアプリケーション実行環境の状態情報やユーザの視聴情報の統計データ等を参照しながら、キャッシングポリシーを選択できるようにする実装モデルである。

　図４０～図４１に示すシーケンス図を参照して、ＡＰＩを適用してアプリケーション実行環境の状態情報やユーザの視聴情報の統計データ等を参照しながら、キャッシングポリシーを選択し、受信装置の記憶部（永続キャッシュ）の制御処理シーケンスについて説明する。
　図４０～図４１には、左から、以下の各構成要素を示している。
　（ａ）送信装置を構成する放送サーバ
　（ｂ）送信装置を構成するデータ配信サーバ
　（ｃ）受信装置のミドルウェア
　（ｄ）受信装置のプロキシサーバ
　（ｅ）受信装置の出力制御部で実行されるブラウザの管理下の記憶部（永続キャッシュ）
　（ｆ）受信装置の出力制御部の実行するブラウザ上で実行されるサービスワーカー（ＳＷ）
　（ｇ）受信装置の出力制御部の実行するブラウザ上で実行されるアプリケーション
　（ｈ）受信装置の出力制御部で実行されるネィティブアプリケーション
　これらの各構成要素を示している。

　なお、ネィティブアプリケーションは、受信装置３０で実行されるアプリケーションであるが、サービスワーカー（ＳＷ）の管理下にあるアプリケーションではなく、例えばコンテンツ（番組）対応のアプリケーションの起動処理等に用いられるアプリケーションである。
　図４０～図４１のシーケンス図に示す各ステップの処理について、順次、説明する。

　　（ステップＳ４０１）
　ステップＳ４０１の処理は、ネィティブアプリケーションによるコンテンツ（番組）対応のアプリケーションの起動処理である。
　上述したように、ネィティブアプリケーションは、コンテンツ（番組）対応のアプリケーションの起動処理等に用いられるアプリケーションである。
　コンテンツ（番組）対応のアプリケーションが、例えば、番組中に埋め込まれたトリガー情報に基づいて起動する設定の場合は、このネィティブアプリケーションによる起動処理は不要である。

　　（ステップＳ４０２）
　ステップＳ４０２において、起動されたアプリケーションが、サービスワーカー（ＳＷ）の登録処理を実行する。
　登録処理によってサービスワーカー（ＳＷ）は、記憶部（永続キャッシュ）に格納され、いつでも利用可能な状態になる。
　このサービスワーカー（ＳＷ）登録処理は、サービスワーカー（ＳＷ）自身からは、登録（ｉｎｓｔａｌｌ）イベントの検出として把握され、サービスワーカー（ＳＷ）は、この登録（ｉｎｓｔａｌｌ）イベント検出を契機として、ステップＳ４０３のキャッシュ制御を開始する。

　　（ステップＳ４０３～Ｓ４０５、およびステップＳ５０１）
　サービスワーカー（ＳＷ）は、登録（ｉｎｓｔａｌｌ）イベントを検出すると、ステップＳ４０３において、例えばスクリプト記述に従った記憶部（永続キャッシュ）の制御を開始する。
　具体的には、特定クラスのサービスワーカー（ＳＷ）、または特定クラスのサービスワーカー（ＳＷ）の管理対象となるリソース（アプリケーションや、アプリ関連データ）の取得、キャッシュ展開（格納）処理を開始する。

　このステップＳ４０３～Ｓ４０５の処理に際しては、ステップＳ５０１において、ＡＰＩを適用して得られた最適ファイル選択情報に応じたファイル取得処理およびキャッシュ展開が実行される。
　ＡＰＩを適用して得られる最適ファイル選択情報は、例えば、アプリケーション実行環境の状態情報やユーザの視聴情報統計データ等に基づいて得られる情報である。

　なお、特定クラスのサービスワーカー（ＳＷ）、または特定クラスのサービスワーカー（ＳＷ）の管理対象となるリソース（アプリケーションや、アプリ関連データ）は、ステップＳ４０４において、放送サーバ、データ配信サーバ等の送信装置から継続的に送信される。
　ステップＳ４０４では、先に図８～図９を参照して説明したリソース送受信処理における図８～９（Ａ－１～２）の各ステップのセグメントファイルに対する処理を、リソースに対する処理に置き換えた処理が実行される。

　送信データは、ステップＳ４０５において、プロキシサーバの管理キャッシュを介して、記憶部（永続キャッシュ）に展開（格納）される。

　　（ステップＳ４０６～Ｓ４０９）
　ステップＳ４０６において、アプリケーションがアプリケーションパーツ、例えばアプリケーションの実行に必要となる動画ファイルや静止画ファイル、あるいはＪａｖａＳｃｒｉｐｔ（登録商標）プログラム、音声データ等のアプリ関連データをサービスワーカー（ＳＷ）に要求する。
　この要求処理は、サービスワーカー（ＳＷ）におけるフェッチ（ｆｅｔｃｈ）イベント検出に相当する。
　ステップＳ４０７～Ｓ４０９において、サービスワーカー（ＳＷ）は、要求されたパーツを記憶部（永続キャッシュ）から取得して、アプリケーションに提供する。

　このステップＳ４０７～Ｓ４０９の処理に際しては、ステップＳ５０１において、ＡＰＩを適用して得られた最適ファイル選択情報に応じたファイル取得処理が実行される。
　ＡＰＩを適用して得られる最適ファイル選択情報は、例えば、アプリケーション実行環境の状態情報やユーザの視聴情報統計データ等に基づいて得られる情報である。

　　（ステップＳ４１０～Ｓ４１１）
　ステップＳ４１０～Ｓ４１１の処理は、サービスワーカー（ＳＷ）によるアクティベート（ａｃｔｉｖａｔｅ）イベント検出時の処理である。
　アクティベート（ａｃｔｉｖａｔｅ）イベントは、例えば、ユーザによるリソースの削除要求の入力が実行された場合、あるいはアプリケーションの有効期限が切れた場合などに検出される。
　サービスワーカー（ＳＷ）が、アクティベート（ａｃｔｉｖａｔｅ）イベントを検出すると、例えばスクリプト記述に従った記憶部（永続キャッシュ）の制御を開始する。
　具体的には、特定クラスのサービスワーカー（ＳＷ）、または特定クラスのサービスワーカー（ＳＷ）の管理対象となるリソース（アプリケーションや、アプリ関連データ）の削除処理等を行なう。

　このステップＳ４１０～Ｓ４１１の処理に際しては、ステップＳ５０２において、ＡＰＩを適用して得られた最適ファイル選択情報に応じたファイル削除が実行される。
　ＡＰＩを適用して得られる最適ファイル選択情報は、例えば、アプリケーション実行環境の状態情報やユーザの視聴情報統計データ等に基づいて得られる情報である。

　　（ステップＳ４１２～Ｓ４１５）
　ステップＳ４１２～Ｓ４１５の処理は、サービスワーカー（ＳＷ）によるタイマーイベント検出時の処理である。
　タイマーイベントは、例えば、アプリケーションの有効期限が切れた場合、更新期限がきた場合などに検出される。
　タイマーイベントに応じた処理としては、例えばキャッシュリソースの削除、あるいは更新リソースや追加リソースの取得処理などがある。

　このステップＳ４１２～Ｓ４１５の処理に際しては、ステップＳ５０２において、ＡＰＩを適用して得られた最適ファイル選択情報に応じたファイル削除または取得処理およびキャッシュ展開が実行される。
　ＡＰＩを適用して得られる最適ファイル選択情報は、例えば、アプリケーション実行環境の状態情報やユーザの視聴情報統計データ等に基づいて得られる情報である。

　ステップＳ４１３は、タイマーイベントに応じたキャッシュリソースの削除処理のシーケンスである。
　ステップＳ４１４～Ｓ４１５は、タイマーイベントに応じた更新リソースや追加リソースの取得処理のシーケンスを示している。
　なお、ステップＳ４１４では、先に図８～図９を参照して説明したリソース送受信処理における図８～９（Ａ－１～２）の各ステップのセグメントファイルに対する処理を、リソースに対する処理に置き換えた処理が実行される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　なお、本明細書において開示した技術は、以下のような構成をとることができる。
　（１）　受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）から、特定クラスのサービスワーカー（ＳＷ）を選択取得して利用するデータ処理部を有する受信装置。

　（２）　前記データ処理部は、
　受信装置におけるデータ処理状況に応じて特定クラスのサービスワーカー（ＳＷ）を選択取得する（１）に記載の受信装置。

　（３）　前記データ処理状況は、受信装置におけるアプリケーションまたはデータの利用状況である（２）に記載の受信装置。

　（４）　前記サービスワーカー（ＳＷ）は、管理対象データとしてアプリケーション、または画像、または音声、少なくともいずれかのデータファイルを含む（１）～（３）いずれかに記載の受信装置。

　（５）　前記データ処理部は、
　送信装置の送信するメタデータであるシグナリングデータから、特定クラスのサービスワーカー（ＳＷ）のアクセス情報を取得し、取得したアクセス情報を利用して、サービスワーカー（ＳＷ）を取得する（１）～（４）いずれかに記載の受信装置。

　（６）　前記シグナリングデータには、特定クラスのサービスワーカー（ＳＷ）のアクセス情報を効率的に検索するための検索補助情報であるトークンが記録され、
　前記データ処理部は、
　トークンを利用したアクセス情報検索処理を実行する（５）に記載の受信装置。

　（７）　前記トークンは、
　特定クラスのサービスワーカー（ＳＷ）のアクセス情報の検索範囲を限定可能としたサービスワーカー（ＳＷ）検索スコープトークンである（６）に記載の受信装置。

　（８）　前記トークンは、特定クラスのサービスワーカー（ＳＷ）のアクセス情報が記録されていることを示すサービスワーカー（ＳＷ）クラス指定トークンである（６）に記載の受信装置。

　（９）　前記シグナリングデータは、
　（ａ）ユーザ提示を目的としたサービスまたはコンテンツの属性情報を記述するサービスレイヤ、
　（ｂ）ファイル転送パラメータを記述したファイル転送セッションレイヤ、
　（ｃ）ＦＬＵＴＥ（ＲＯＵＴＥ）プロトコル対応のパラメータを記述したＦＬＵＴＥ（ＲＯＵＴＥ）パラメータレイヤ、
　上記（ａ）～（ｃ）のレイヤを有し、
　少なくとも（ａ）～（ｃ）いずれかのレイヤにトークンが記録された構成である（６）～（８）いずれかに記載の受信装置。

　（１０）　前記データ処理部は、前記サービスレイヤ、または、前記ファイル転送セッションレイヤ、または、前記ＦＬＵＴＥ（ＲＯＵＴＥ）パラメータレイヤに記録されたトークンを取得する（９）に記載の受信装置。

　（１１）　前記受信装置のデータ処理部において実行されるアプリケーションは、受信データの処理を実行するミドルウェアに対して、前記トークンを検出するためのトークン情報の設定要求を実行し、
　前記ミドルウェアは、トークン情報設定要求に応じて設定したトークン情報に基づいて、トークン検出を行う（１）～（１０）いずれかに記載の受信装置。

　（１２）　前記受信装置のデータ処理部において実行されるデータ管理プログラムであるサービスワーカー（ＳＷ）は、受信データの処理を実行するミドルウェアに対して、前記トークンを検出するためのトークン情報の設定要求を実行し、
　前記ミドルウェアは、トークン情報設定要求に応じて設定したトークン情報に基づいて、トークン検出を行う（１）～（１１）いずれかに記載の受信装置。

　（１３）　前記トークンは、
　特定のサービスワーカー（ＳＷ）の管理対象となるデータに対応するアクセス情報の検索処理を効率化するための情報であり、
　前記データ処理部は、
　前記サービスワーカー（ＳＷ）の更新に応じて、前記ミドルウェアに対して、新たなトークン情報の設定要求を行う（１２）に記載の受信装置。

　（１４）　受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）を送信する送信装置。

　（１５）　前記送信装置は、
　受信装置において、特定クラスのサービスワーカー（ＳＷ）のアクセス情報を効率的に検索するための検索補助情報であるトークンを記録したメタデータであるシグナリングデータを送信する（１４）に記載の送信装置。

　（１６）　前記トークンは、
　特定クラスのサービスワーカー（ＳＷ）のアクセス情報の検索範囲を限定可能としたサービスワーカー（ＳＷ）検索スコープトークン、または、
　特定クラスのサービスワーカー（ＳＷ）のアクセス情報が記録されていることを示すサービスワーカー（ＳＷ）クラス指定トークンである（１５）に記載の送信装置。

　（１７）　受信装置において実行するデータ処理方法であり、
　前記受信装置のデータ処理部が、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）から、特定クラスのサービスワーカー（ＳＷ）を選択取得して利用するデータ処理方法。

　（１８）　送信装置において実行するデータ処理方法であり、
　受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）を送信するデータ処理方法。

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

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

　以上、説明したように、本開示の一実施例の構成によれば、各々の受信装置に最適化したデータ管理を実行するサービスワーカー（ＳＷ）の選択取得および利用処理を可能とする装置、方法が実現される。
　具体的には、例えば、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）から、特定クラスのＳＷを選択取得して利用可能とした。例えば、受信装置におけるアプリケーション利用状況に応じて選択されるクラス対応のＳＷの利用を実現する。受信装置は、特定クラスのＳＷのアクセス情報を効率的に検索可能とするためのトークンを記録したシグナリングデータを利用して特定クラスのＳＷのアクセス情報を取得してＳＷを取得する。
　本構成により、各々の受信装置に最適化したデータ管理を実行するサービスワーカー（ＳＷ）の選択取得および利用処理を可能とする装置、方法が実現される。

　　１０　通信システム
　　２０　送信装置
　　２１　放送サーバ
　　２２　データ配信サーバ
　　３０　受信装置
　　３１　ＴＶ
　　３２　ＰＣ
　　３３　携帯端末
　　５０　シグナリングデータ
　　６０　ＡＶセグメント
　　７０　その他のデータ
　１１０　ミドルウェア
　１１１　通信部（ＰＨＹ／ＭＡＣ）
　１１２　シグナリング取得部
　１１３　シグナリング解析部
　１１４　ファイル取得部
　１２０　ＨＴＴＰプロキシサーバ
　１２１，１２２　キャッシュ部
　１２３　アドレス解決部
　１３０　出力制御部
　１３１　表示データ（ＨＴＭＬ／ＪａｖａＳｃｒｉｐｔ（登録商標）等）取得＆解析部
　１３２　表示処理部（Ｒｅｎｄｅｒｅｒ）
　１３３　記憶部（永続キャッシュ）
　１４０　外部装置
　１４１　出力制御部
　１４２　記憶部（永続キャッシュ）
　７５１　データ処理部
　７５２　通信部
　７５３　記憶部
　７７１　データ処理部
　７７２　通信部
　７７３　記憶部
　７７４　入力部
　７７５　出力部
　８０１　ＣＰＵ
　８０２　ＲＯＭ
　８０３　ＲＡＭ
　８０４　バス
　８０５　入出力インタフェース
　８０６　入力部
　８０７　出力部
　８０８　記憶部
　８０９　通信部
　８１０　ドライブ
　８１１　リムーバブルメディア

Claims

　受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）から、特定クラスのサービスワーカー（ＳＷ）を選択取得して利用するデータ処理部を有する受信装置。
　前記データ処理部は、
　受信装置におけるデータ処理状況に応じて特定クラスのサービスワーカー（ＳＷ）を選択取得する請求項１に記載の受信装置。
　前記データ処理状況は、受信装置におけるアプリケーションまたはデータの利用状況である請求項２に記載の受信装置。
　前記サービスワーカー（ＳＷ）は、管理対象データとしてアプリケーション、または画像、または音声、少なくともいずれかのデータファイルを含む請求項１に記載の受信装置。
　前記データ処理部は、
　送信装置の送信するメタデータであるシグナリングデータから、特定クラスのサービスワーカー（ＳＷ）のアクセス情報を取得し、取得したアクセス情報を利用して、サービスワーカー（ＳＷ）を取得する請求項１に記載の受信装置。
　前記シグナリングデータには、特定クラスのサービスワーカー（ＳＷ）のアクセス情報を効率的に検索するための検索補助情報であるトークンが記録され、
　前記データ処理部は、
　トークンを利用したアクセス情報検索処理を実行する請求項５に記載の受信装置。
　前記トークンは、
　特定クラスのサービスワーカー（ＳＷ）のアクセス情報の検索範囲を限定可能としたサービスワーカー（ＳＷ）検索スコープトークンである請求項６に記載の受信装置。
　前記トークンは、特定クラスのサービスワーカー（ＳＷ）のアクセス情報が記録されていることを示すサービスワーカー（ＳＷ）クラス指定トークンである請求項６に記載の受信装置。
　前記シグナリングデータは、
　（ａ）ユーザ提示を目的としたサービスまたはコンテンツの属性情報を記述するサービスレイヤ、
　（ｂ）ファイル転送パラメータを記述したファイル転送セッションレイヤ、
　（ｃ）ＦＬＵＴＥ（ＲＯＵＴＥ）プロトコル対応のパラメータを記述したＦＬＵＴＥ（ＲＯＵＴＥ）パラメータレイヤ、
　上記（ａ）～（ｃ）のレイヤを有し、
　少なくとも（ａ）～（ｃ）いずれかのレイヤにトークンが記録された構成である請求項６に記載の受信装置。
　前記データ処理部は、前記サービスレイヤ、または、前記ファイル転送セッションレイヤ、または、前記ＦＬＵＴＥ（ＲＯＵＴＥ）パラメータレイヤに記録されたトークンを取得する請求項９に記載の受信装置。
　前記受信装置のデータ処理部において実行されるアプリケーションは、受信データの処理を実行するミドルウェアに対して、前記トークンを検出するためのトークン情報の設定要求を実行し、
　前記ミドルウェアは、トークン情報設定要求に応じて設定したトークン情報に基づいて、トークン検出を行う請求項１に記載の受信装置。
　前記受信装置のデータ処理部において実行されるデータ管理プログラムであるサービスワーカー（ＳＷ）は、受信データの処理を実行するミドルウェアに対して、前記トークンを検出するためのトークン情報の設定要求を実行し、
　前記ミドルウェアは、トークン情報設定要求に応じて設定したトークン情報に基づいて、トークン検出を行う請求項１に記載の受信装置。
　前記トークンは、
　特定のサービスワーカー（ＳＷ）の管理対象となるデータに対応するアクセス情報の検索処理を効率化するための情報であり、
　前記データ処理部は、
　前記サービスワーカー（ＳＷ）の更新に応じて、前記ミドルウェアに対して、新たなトークン情報の設定要求を行う請求項１２に記載の受信装置。
　受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）を送信する送信装置。
　前記送信装置は、
　受信装置において、特定クラスのサービスワーカー（ＳＷ）のアクセス情報を効率的に検索するための検索補助情報であるトークンを記録したメタデータであるシグナリングデータを送信する請求項１４に記載の送信装置。
　前記トークンは、
　特定クラスのサービスワーカー（ＳＷ）のアクセス情報の検索範囲を限定可能としたサービスワーカー（ＳＷ）検索スコープトークン、または、
　特定クラスのサービスワーカー（ＳＷ）のアクセス情報が記録されていることを示すサービスワーカー（ＳＷ）クラス指定トークンである請求項１５に記載の送信装置。
　受信装置において実行するデータ処理方法であり、
　前記受信装置のデータ処理部が、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）から、特定クラスのサービスワーカー（ＳＷ）を選択取得して利用するデータ処理方法。
　送信装置において実行するデータ処理方法であり、
　受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ（ＳＷ）を送信するデータ処理方法。