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

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

Info

Publication number
JPWO2017014034A1
JPWO2017014034A1 JP2017529533A JP2017529533A JPWO2017014034A1 JP WO2017014034 A1 JPWO2017014034 A1 JP WO2017014034A1 JP 2017529533 A JP2017529533 A JP 2017529533A JP 2017529533 A JP2017529533 A JP 2017529533A JP WO2017014034 A1 JPWO2017014034 A1 JP WO2017014034A1
Authority
JP
Japan
Prior art keywords
application
data
cache
size
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
JP2017529533A
Other languages
English (en)
Inventor
淳 北原
淳 北原
北里　直久
直久 北里
山岸　靖明
靖明 山岸
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Publication of JPWO2017014034A1 publication Critical patent/JPWO2017014034A1/ja
Abandoned legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0813—Multiuser, multiprocessor or multiprocessing cache systems with a network or matrix configuration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H04N21/4355—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream involving reformatting operations of additional data, e.g. HTML pages on a television screen
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6408—Unicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/812—Monomedia components thereof involving advertisement data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/8173—End-user applications, e.g. Web browser, game
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/31—Providing disk cache in a specific location of a storage system
    • G06F2212/314—In storage network, e.g. network attached cache

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Marketing (AREA)
  • Business, Economics & Management (AREA)
  • Mathematical Physics (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

受信装置において、アプリケーション単位、またはプレゼンテーション・ユニット単位のキャッシュ処理を実行させ、完成度の高いアプリケーション実行処理を可能とする装置、方法を提供する。受信装置が、送信装置からアプリケーションのデータサイズであるアプリケーションサイズと、アプリケーションリンク情報、さらに、アプリケーション構成要素であるプレゼンテーション・ユニット（ＰＵ）各々のデータサイズを記録したシグナリングデータを受信する。受信装置はキャッシュサイズと、アプリケーションや、ＰＵ各々のデータサイズとを比較し、キャッシュ可能なアプリケーション、またはＰＵをキャッシュ対象データとして決定し、アプリケーションまたはＰＵ単位のキャッシュ処理を実行する。

Description

本開示は、受信装置、送信装置、およびデータ処理方法に関する。さらに詳細には例えば放送波やネットワークを介したデータの受信または送信を実行する受信装置、送信装置、および通信データ対応のデータ処理方法に関する。
画像データや音声データ等のコンテンツを各通信事業者のサービス形態に関わらず配信可能としたデータ配信方式としてＯＴＴ（Ｏｖｅｒ Ｔｈｅ Ｔｏｐ）がある。ＯＴＴによる配信コンテンツはＯＴＴコンテンツと呼ばれ、また、ＯＴＴを利用した画像（ビデオ）データの配信サービスはＯＴＴビデオやＯＴＴ−Ｖ（Ｏｖｅｒ Ｔｈｅ Ｔｏｐ Ｖｉｄｅｏ）と呼ばれる。
ＯＴＴ−Ｖに従ったデータストリーミング配信規格としてＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒＨＴＴＰ）規格がある。ＤＡＳＨは、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）をベースとしたストリーミングプロトコルを用いたアダプティブ（適応型）ストリーミング配信に関する規格である。
アダプティブ（適応型）ストリーミングでは、放送局等のコンテンツ配信サーバは、データ配信先となる様々なクライアントにおいてコンテンツ再生を可能とするため、複数のビットレートの動画コンテンツの細分化ファイルとこれらの属性情報やＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を記述したマニフェスト・ファイルを作成し、クライアントに提供する。
クライアントは、マニフェスト・ファイルをサーバから取得して、自装置の表示部のサイズや利用可能な通信帯域に応じた最適なビットレートコンテンツを選択し、選択コンテンツを受信して再生する。ネットワーク帯域の変動に応じてビットレートの動的な変更も可能であり、クライアント側では、状況に応じた最適なコンテンツを随時切り替えて受信することが可能となり、映像途切れの発生を低減した動画コンテンツ再生が実現される。なお、アダプティブ（適応型）ストリーミングについては、例えば特許文献１（特開２０１１−８７１０３号公報）に記載がある。
放送局やその他のコンテンツサーバ等の送信装置から、テレビ、ＰＣ、携帯端末等の受信装置に対して、放送波等による一方向通信、あるいは、インターネット等のネットワークを介した双方向通信、一方向通信を用いて放送番組等のコンテンツを送受信するシステムについての開発や規格化が、現在、盛んに進められている。
なお、放送波およびネットワークを介したデータ配信を実現するための技術を開示した従来技術として、例えば特許文献２（特開２０１４−０５７２２７号公報）がある。
放送波およびネットワークを介したデータ配信システムに関する規格として、現在、ＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍ Ｃｏｍｍｉｔｔｅ）３．０の規格化が進行中である。
ＡＴＳＣ３．０では、ＡＴＳＣ３．０準拠物理層（ＡＴＳＣ−ＰＨＹ）を実装した放送配信用デバイス（チューナ実装デバイス）上に、ＡＴＳＣ３．０放送の受信処理等を実行するミドルウェアを実装させることで、ＡＴＳＣ放送用の制御情報等を含むシグナリングデータを受信して、シグナリングデータによる様々な制御を可能とする構成を検討している。
具体的には、シグナリングデータによる制御によって、インターネット等で利用されているアプリケーションプログラム、いわゆるクライアントアプリケーションをそのまま利用して、放送コンテンツの出力処理や、放送波等によって提供される様々なアプリケーションを利用したデータ処理を実現可能とする構成を検討している。
例えば、家庭内やホットスポットに設置された放送サービスの受信装置（専用サーバの他、ＰＣ、ＴＶ、タブレット、スマホ等）にＡＴＳＣ３．０準拠物理層（ＡＴＳＣ−ＰＨＹ）、ならびに、ＡＴＳＣ３．０放送受信ミドルウェアを実装する。
受信装置において、ＡＴＳＣ３．０放送サービスを受信後、受信装置の再生制御部やアプリケーション制御部上で稼働するアプリケーション（例えばＡＴＳＣ３．０ ＤＡＳＨクライアントアプリケーション）を利用して、放送コンテンツの再生や、放送で配信される様々なアプリケーションを実行することが可能となる。
受信装置においてアプリケーションを実行するためには、アプリケーションを構成する様々なファイル、例えば動画等の画像ファイル、音声ファイル等をユーザ装置内のキャッシュ（記憶部）に格納するキャッシュ処理が必要となる。
しかし、受信装置のキャッシュ（記憶部）に十分な空き容量が無い場合、アプリケーションの構成ファイルの全てを格納できない場合が発生する。
アプリケーション構成ファイルの一部がキャッシュできないまま、アプリを実行すると、キャッシュできなかった画像（動画）や音声データの欠落や、全くアプリを実行できないといったアプリケーション・エラーが発生する場合がある。
特開２０１１−８７１０３号公報 特開２０１４−０５７２２７号公報
本開示は、例えば上記問題点に鑑みてなされたものであり、放送波等を介してアイプリケーションを受信して実行する受信装置において、アプリケーション、またはアプリケーション構成要素単位のデータサイズやリンク情報を取得したキャッシュ処理により、所定のアプリ単位、またはアプリ構成要素単位のアプリケーションの実行を可能とする受信装置、送信装置、およびデータ処理方法を提供する。
さらに、本開示の一実施態様では、アプリケーション構成要素のデータサイズ情報や、リンク情報を取得して、これらの取得情報に基づいて、キャッシュ可能なアプリケーション、またはアプリケーション構成要素を選択してキャッシュ処理を行なうことで、キャッシュデータに基づく確実なアプリケーションの実行を可能とする受信装置、送信装置、およびデータ処理方法を提供する。
本開示の第１の側面は、
アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを受信する通信部と、
自装置の記憶部に格納可能なデータサイズであるキャッシュサイズと、前記第１シグナリングデータから取得するリンク関係にある各アプリケーションのデータサイズとを比較して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定し、アプリケーション単位のキャッシュ処理を実行するデータ処理部を有する受信装置にある。
さらに、本開示の第２の側面は、
アプリケーション構成データを格納したパケットと、
前記アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを格納したパケットを生成するデータ処理部と、
前記データ処理部の生成したパケットを送信する通信部と、
を有する送信装置にある。
さらに、本開示の第３の側面は、
受信装置において実行するデータ処理方法であり、
通信部が、アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを受信し、
データ処理部が、自装置の記憶部に格納可能なデータサイズであるキャッシュサイズと、前記第１シグナリングデータから取得するリンク関係にある各アプリケーションのデータサイズとを比較して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定し、アプリケーション単位のキャッシュ処理を実行するデータ処理方法にある。
さらに、本開示の第４の側面は、
送信装置において実行するデータ処理方法であり、
データ処理部が、
アプリケーション構成データを格納したパケットと、
前記アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを格納したパケットを生成し、
通信部が、前記データ処理部の生成したパケットを送信するデータ処理方法にある。
本開示のさらに他の目的、特徴や利点は、後述する本開示の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
本開示の一実施例の構成によれば、受信装置において、アプリケーション単位、またはプレゼンテーション・ユニット単位のキャッシュ処理を実行させ、完成度の高いアプリケーション実行処理を可能とする装置、方法が実現される。
具体的には、受信装置が、送信装置からアプリケーションのデータサイズであるアプリケーションサイズと、アプリケーションリンク情報、さらに、アプリケーション構成要素であるプレゼンテーション・ユニット（ＰＵ）各々のデータサイズを記録したシグナリングデータを受信する。受信装置はキャッシュサイズと、アプリケーションや、ＰＵ各々のデータサイズとを比較し、キャッシュ可能なアプリケーション、またはＰＵをキャッシュ対象データとして決定し、アプリケーションまたはＰＵ単位のキャッシュ処理を実行する。
本構成により、受信装置において、アプリケーション単位、またはプレゼンテーション・ユニット単位のキャッシュ処理を実行させ、完成度の高いアプリケーション実行処理を可能とする装置、方法が実現される。
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。
本開示の処理を実行する通信システムの一構成例について説明する図である。 送信装置の送信データについて説明する図である。 送信装置および受信装置のプロトコルスタックの例を示す図である。 ＲＯＵＴＥ、およびＦＬＵＴＥに関するプロトコルスタックを示す図である。 受信装置（クライアント）３０におけるデータ出力例を説明する図である。 様々なユーザ情報を利用した出力広告の選択例について説明する図である。 受信装置の構成例について説明する図である。 アプリケーションの構成例について説明する図である。 アプリケーションの構成とリンクについて説明する図である。 アプリケーションのサイズと、キャッシュサイズとの対応例について説明する図である。 アプリケーションのサイズと、キャッシュサイズとの対応に基づくキャッシュ対象選択処理例について説明する図である。 シグナリングデータに基づくアプリケーション取得処理例について説明する図である。 ＵＳＢＤ／ＵＳＤにおける放送配信アプリケーション関連データの記録例について説明する図である。 ＵＳＢＤ／ＵＳＤにおける放送配信アプリケーション関連データの記録例について説明する図である。 ＡＩＴのデータ記録例について説明する図である。 Ｓ−ＴＳＩＤのデータ記録例について説明する図である。 Ｓ−ＴＳＩＤのデータ記録例について説明する図である。 Ｓ−ＴＳＩＤのデータ記録例について説明する図である。 キャッシュサイズに応じたキャッシュ処理のショリシーケンスについて説明するフローチャートを示す図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体例について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体的シーケンスについて説明するフローチャートを示す図である。 受信装置のキャッシュサイズに応じたキャッシュ処理二際して参照するシグナリングデータの記述について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体例について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体的シーケンスについて説明するフローチャートを示す図である。 受信装置のキャッシュサイズに応じたキャッシュ処理二際して参照するシグナリングデータの記述について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体例について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体的シーケンスについて説明するフローチャートを示す図である。 受信装置のキャッシュサイズに応じたキャッシュ処理二際して参照するシグナリングデータの記述について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体例について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体的シーケンスについて説明するフローチャートを示す図である。 受信装置のキャッシュサイズに応じたキャッシュ処理二際して参照するシグナリングデータの記述について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体例について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体的シーケンスについて説明するフローチャートを示す図である。 受信装置のキャッシュサイズに応じたキャッシュ処理二際して参照するシグナリングデータの記述について説明する図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行するアプリケーション遷移処理例について説明する図である。 受信装置の実行するアプリケーション遷移処理例について説明する図である。 サービスワーカー（ＳＷ）を利用した処理について説明する図である。 サービスワーカー（ＳＷ）を利用した処理について説明する図である。 サービスワーカー（ＳＷ）を利用した処理について説明する図である。 通信装置である送信装置と受信装置の構成例について説明する図である。 通信装置である送信装置と受信装置のハードウェア構成例について説明する図である。
以下、図面を参照しながら本開示の受信装置、送信装置、およびデータ処理方法の詳細について説明する。なお、説明は以下の項目に従って行なう。
１．通信システムの構成例について
２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて
３．送信装置と受信装置の実行する通信処理例について
４．受信装置におけるアプリケーションを適用したデータ出力例について
５．受信装置の構成例と処理例について
６．アプリケーションの構成例について
７．アプリケーションのキャッシュ処理について
８．シグナリングデータの構成、およびシグナリングデータを適用したキャッシュ対象データ選択処理について
９．受信装置のキャッシュサイズ（データ格納許容サイズ）に応じた具体的な処理例について
９−１．受信装置のデータ格納許容キャッシュサイズが最小サイズ（Ｍｉｎｉｍｕｍ）であり、１つのプレゼンテーション・ユニット（ＰＵ）のみ格納可能である場合の処理例について
９−２．受信装置のデータ格納許容キャッシュサイズが小サイズ（Ｓｍａｌｌ）であり、複数のプレゼンテーション・ユニット（ＰＵ）が格納可能である場合の処理例について
９−３．受信装置のデータ格納許容キャッシュサイズが中サイズ（Ｍｅｄｉｕｍ）であり、１つのアプリケーションが格納可能である場合の処理例について
９−４．受信装置のデータ格納許容キャッシュサイズが大サイズ（Ｌａｒｇｅ）であり、複数のアプリケーションが格納可能である場合の処理例について
９−５．受信装置のデータ格納許容キャッシュサイズが最大サイズ（Ｍａｘｉｍｕｍ）であり、複数のアプリケーションが格納可能である場合の処理例について
１０．受信装置におけるデータ処理の全体シーケンスについて
１０−１．受信装置における放送ストリーム受信処理の全体シーケンス
１０−２．受信装置における放送ストリーム受信処理の詳細シーケンス
１０−３．受信装置におけるシグナリングの受信、解析処理の詳細シーケンス
１０−４．受信装置におけるアプリケーションの取得、実行処理の詳細シーケンス
１０−５．受信装置における放送経由のアプリケーションの取得処理の詳細シーケンス
１０−６．受信装置におけるプレゼンテーション・ユニット（ＰＵ）単位のキャッシュ処理の詳細シーケンス
１０−７．受信装置におけるアプリケーション単位のキャッシュ処理の詳細シーケンス
１０−８．受信装置におけるアプリケーションまたはプレゼンテーション・ユニット（ＰＵ）間の遷移処理シーケンス
１１．アプリケーション遷移処理の具体例について
１２．サービスワーカー（ＳＷ）を利用したキュッシュ制御処理例について
１３．送信装置と受信装置の構成例について
１４．本開示の構成のまとめ
［１．通信システムの構成例について］
まず、図１を参照して本開示の処理を実行する通信システムの一構成例について説明する。
図１に示すように、通信システム１０は、画像データや音声データ等のコンテンツを送信する通信装置である送信装置２０と、送信装置２０の送信するコンテンツを受信する通信装置である受信装置３０を有する。
送信装置２０は、具体的には、例えば、主にＴＶ番組等を送信する放送サーバ（放送局）２１や、主に広告データを送信する広告サーバ２２、様々なデータを送信するデータ配信サーバ２３等、様々なコンテンツ（放送番組、広告、その他のデータ）を提供する側の装置である。
一方、受信装置３０は、一般ユーザのクライアント装置であり、具体的には、例えばテレビ３１、ＰＣ３２、携帯端末３３等によって構成される。
なお、図１には、受信装置の代表例として、テレビ３１、ＰＣ３２、携帯端末３３を示しているが、本開示の処理を実行可能な受信装置としては、その他、例えば、スマートフォン、タブレット端末、スマートウォッチ、ウェアラブルデバイス等、様々な受信装置が含まれる。
また、図１では、送信装置２０の例として、放送サーバ（放送局）２１、広告サーバ２２、データ配信サーバ２３を区別して記載しているが、１つのサーバが放送番組、広告、その他のデータをすべて送信する構成としてもよい。
例えば、１つの放送局が、放送波を介して様々な番組、広告、アプリケーション、その他のデータを配信する構成、あるいは、１つのサーバが、通信ネットワークを介して様々な番組、広告、アプリケーション、その他のデータを配信する構成なども可能である。
送信装置２０と受信装置３０間のデータ通信は、インターネット等のネットワークを介した双方向通信、一方向通信、あるいは、放送波等による一方向通信の少なくともいずれか、あるいは両者を利用した通信として行われる。
送信装置２０から受信装置３０に対するコンテンツ送信は、例えばアダプティブ（適応型）ストリーミング技術の規格であるＭＰＥＧ−ＤＡＳＨ規格や、ＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）など、様々なフォーマットに従って実行される。なお、本開示の処理を実行する場合、データ配信フォーマットは限定されない。
ＭＰＥＧ−ＤＡＳＨ規格には、以下の２つの規格が含まれる。
（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格、
（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格、
送信装置２０から、受信装置３０に対するコンテンツ配信は、上記のＭＰＥＧ−ＤＡＳＨ規格に従って実行する。
送信装置２０は、コンテンツデータを符号化し、符号化データおよび符号化データのメタデータを含むデータファイルを生成する。符号化処理は、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って行われる。なお、送信装置２０がＭＰ４形式のデータファイルを生成する場合の符号化データのファイルは「ｍｄａｔ」、メタデータは「ｍｏｏｖ」や「ｍｏｏｆ」等と呼ばれる。
送信装置２０が受信装置３０に提供するコンテンツは、例えば音楽データや、映画、テレビ番組、ビデオ、写真、文書、絵画および図表などの映像データや、ゲームおよびソフトウェアなど、様々なデータである。
送信装置２０の送信データについて図２を参照して説明する。
ＭＰＥＧ−ＤＡＳＨ規格に従ってデータ送信を実行する送信装置２０は、図２に示すように、大きく分けて以下の複数種類のデータの送信を行う。
（ａ）シグナリングデータ５０
（ｂ）ＡＶセグメント６０
（ｃ）その他のデータ（ＥＳＧ，ＮＲＴコンテンツ等）７０
ＡＶセグメント６０は、受信装置において再生する画像（Ｖｉｄｅｏ）や、音声（Ａｕｄｉｏ）データ、すなわち例えば放送局の提供する番組コンテンツ等によって構成される。例えば、上述したＭＰ４符号化データ（ｍｄａｔ）や、メタデータ（ｍｏｏｖ，ｍｏｏｆ）によって構成される。なお、ＡＶセグメントは、ＤＡＳＨセグメントとも呼ばれる。
一方、シグナリングデータ５０は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、アプリケーション制御情報等の様々な制御情報によって構成される。
受信装置３０は、このシグナリングデータ５０を、再生対象となる番組コンテンツを格納したＡＶセグメント６０の受信に先行して受信することが必要となる。
このシグナリングデータ５０は、例えばＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式のデータとして送信装置２０から送信される。
シグナリングデータは、随時、繰り返し送信される。例えば１００ｍｓｅｃ毎など、頻繁に繰り返し送信される。
これは、受信装置（クライアント）が、いつでも、即座にシグナリングデータを取得することを可能とするためである。
クライアント（受信装置）は、随時、受信可能なシグナリングデータに基づいて、必要な番組コンテンツのアクセス用アドレスの取得や、コーデック設定処理など、番組コンテンツの受信および再生に必要な処理を遅滞なく実行することが可能となる。
その他のデータ７０は、例えばＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）、ＮＲＴコンテンツ等が含まれる。
ＥＳＧは、電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）であり、例えば番組表等の案内情報である。
ＮＲＴコンテンツはノンリアルタイム型のコンテンツである。
ＮＲＴコンテンツには、例えば、クライアントである受信装置３０のブラウザ上で実行される様々なアプリケーションや、動画、静止画等のデータファイル等が含まれる。
図２に示す以下のデータ、すなわち、
（ａ）シグナリングデータ５０
（ｂ）ＡＶセグメント６０
（ｃ）その他のデータ（ＥＳＧ，ＮＲＴコンテンツ等）７０
これらのデータは、例えば、データ通信プロトコル：ＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）に従って送信される。
［２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて］
データ通信プロトコル：ＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）はマルチキャストにより伝送するコンテンツのセッション管理を行うプロトコルである。
例えば送信装置であるサーバ側で生成されるファイル（ＵＲＬとバージョンで識別される）は、ＦＬＵＴＥプロトコルに従って、受信装置であるクライアントに送信される。
受信装置（クライアント）３０は、例えば記憶部（クライアントキャッシュ）に、受信ファイルのＵＲＬおよびバージョンとファイルを対応付けて蓄積する。
同じＵＲＬでバージョンが異なるものはファイルの中身が更新されているものとみなす。ＦＬＵＴＥプロトコルは一方向ファイル転送制御のみを行うもので、クライアントにおけるファイルの選択的なフィルタリング機能はないが、ＦＬＵＴＥで転送制御するファイルをそのファイルに紐づけられるメタデータを利用して、クライアント側で取捨選択することにより、選択的なフィルタリングを実現し、ユーザの嗜好を反映したローカルキャッシュを構成・更新管理することが可能となる。
なお、メタデータは、ＦＬＵＴＥプロトコルに拡張して組み込むこともできるし、別途ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）等のプロトコルで記述することもできる。
なお、ＦＬＵＴＥは、当初マルチキャストにおけるファイル転送プロトコルとして仕様化された。ＦＬＵＴＥは、ＦＤＴと、ＡＬＣと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコル、具体的にはそのビルディングブロックであるＬＣＴやＦＥＣコンポーネント、の組み合わせにより構成される。
従来のＦＬＵＴＥは、主に非同期型のファイル転送に利用するために開発されたが、現在、放送波およびネットワークを介したデータ配信システムに関する規格化団体であるＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍ Ｃｏｍｍｉｔｔｅ）において、ブロードキャストライブストリーミングにも適用しやすくするための拡張を行っている。このＦＬＵＴＥの拡張仕様がＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）と呼ばれる。
放送波およびネットワークを介したデータ配信システムに関する規格の１つとして現在、標準化が進められている規格としてＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍ Ｃｏｍｍｉｔｔｅ）３．０がある。このＡＴＳＣ３．０は、ＲＯＵＴＥを従来のＦＬＵＴＥプロトコルに置き換えて、シグナリングデータや、ＥＳＧ、あるいは非同期ファイル、同期型ストリーム等の送信に採用したスタック構成を規定している。
［３．送信装置と受信装置の実行する通信処理例について］
次に、送信装置と受信装置の実行する通信処理例について説明する。
図３は、送信装置および受信装置のプロトコルスタックの例を示す図である。
図３に示す例は、以下の２つの通信データの処理を行なうための２つのプロトコルスタックを有する。
（ａ）ブロードキャスト（マルチキャストも含む）通信（例えば放送型データ配信）
（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）
図３の左側が（ａ）ブロードキャスト通信（例えば放送型データ配信）に対応するプロトコルスタックである。
図３の右側が、（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）に対応するプロトコルスタックである。
図３左側に示す（ａ）ブロードキャスト通信（例えば放送型データ配信）に対応するプロトコルスタックは、下位レイヤから順に、以下のレイヤを持つ。
（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ ＰＨＹ）
（２）ＩＰマルチキャストレイヤ（ＩＰ Ｍｕｌｔｉｃａｓｔ）
（３）ＵＤＰレイヤ
（４）ＲＯＵＴＥ（＝拡張型ＦＬＵＴＥ）レイヤ
（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣ
（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ ５））
なお、（２）ＩＰマルチキャストレイヤ（ＩＰ Ｍｕｌｔｉｃａｓｔ）の上位レイヤとしてシグナリング（Ｓｉｇｎａｌｉｎｇ）レイヤが設定される。
シグナリングレイヤは、先に図２を参照して説明したシグナリングデータ５０の送受信に適用されるレイヤである。シグナリングデータには、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、制御情報などが含まれる。
シグナリングデータは、受信装置（クライアント）が受信、再生するＡＶセグメントのアクセス情報や、復号処理等の受信後の処理に必要となる案内情報や制御情報を含むデータであり、送信装置から随時繰り返し送信されるデータである。
シグナリングデータには、情報に応じた様々な種類がある。具体的には、例えば、サービス単位のシグナリングデータであるＵＳＤ（ユーザサービスディスクリプション（Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ））がある。
ＵＳＤには、様々な種類の制御情報が含まれる。代表的な制御情報として、コンテンツ（ＡＶセグメント）に対応する様々な案内情報、制御情報を格納したマニフェスト・ファイルを持つシグナリングデータであるＭＰＤ（メディアプレゼンテーションディスクリプション（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ））がある。
各種のシグナリングデータは、それぞれ受信装置（クライアント）において、送信装置から送信されるＡＶセグメントやアプリケーション（アプリケーションプログラム）の受信、再生処理、制御処理に必要となるデータであり、例えばカテゴリ別に個別のファイル（メタファイル）として設定され、送信装置から送信される。
なお、（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ ＰＨＹ）の上位レイヤとして将来の新たなプロトコルの利用許容レイヤ（Ｆｕｔｕｒｅ Ｅｘｔｅｎｓｉｂｉｌｉｔｙ）が設定されている。
（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ ＰＨＹ）は、ブロードキャスト通信を実行するための例えば放送系の通信部を制御する通信制御部によって構成される物理レイヤである。
（２）ＩＰマルチキャストレイヤ（ＩＰ Ｍｕｌｔｉｃａｓｔ）は、ＩＰマルチキャストに従ったデータ送受信処理を実行するレイヤである。
（３）ＵＤＰレイヤは、ＵＤＰパケットの生成、解析処理レイヤである。
（４）ＲＯＵＴＥレイヤは、拡張型ＦＬＵＴＥプロトコルであるＲＯＵＴＥプロトコルにしたがって転送データの格納や取り出しを行うレイヤである。
ＲＯＵＴＥは、ＦＬＵＴＥと同様、ＡＬＣと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコルであり、具体的にはそのビルディングブロックであるＬＣＴやＦＥＣコンポーネントの組み合わせにより構成される。
図４に、ＲＯＵＴＥ、およびＦＬＵＴＥに関するプロトコルスタックを示す。
（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＲＯＵＴＥプロトコルに従って転送されるデータである。
ＤＡＳＨ規格に従った同報型配信サービスは、ＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）と呼ばれる。このＭＢＭＳをＬＴＥで効率的に実現させる方式としてｅＭＢＭＳ（ｅｖｏｌｖｅｄ Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）がある。
ＭＢＭＳやｅＭＢＭＳは、同報型配信サービスであり、特定のエリア内に位置する受信装置である複数のユーザ端末（ＵＥ）に対して共通のベアラで一斉に同一データ、例えば映画コンテンツなどを配信するサービスである。ＭＢＭＳやｅＭＢＭＳに従った同報配信により、配信サービス提供エリアに位置する多数のスマホやＰＣ、あるいはテレビ等の受信装置に、同じコンテンツを同時に提供することができる。
ＭＢＭＳ、およびｅＭＢＭＳは、３ＧＰＰファイルフォーマット（ＩＳＯ−ＢＭＦＦファイル、ＭＰ４ファイル）に従ったファイルを、転送プロトコルＲＯＵＴＥ、またはＦＬＵＴＥに従ってダウンロードする処理について規定している。
先に図２を参照して説明した以下のデータ、すなわち、
（ａ）シグナリングデータ５０
（ｂ）ＡＶセグメント６０
（ｃ）その他のデータ（ＥＳＧ、ＮＲＴコンテンツ等）７０
これらのデータの多くはＲＯＵＴＥプロトコル、またはＦＬＵＴＥプロトコルに従って送信される。
（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＲＯＵＴＥプロトコルに従って転送されるデータである。
ＥＳＧは、電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）であり、例えば番組表等の案内情報である。
ＮＲＴｃｏｎｔｅｎｔはノンリアルタイム型のコンテンツである。
前述したように、ＮＲＴコンテンツには、例えば、クライアントである受信装置のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。
Ｖｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＤＡＳＨ規格に従って配信されるビデオやオディオ等、再生対象となる実データである。
（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５）は、ＲＯＵＴＥプロトコルに従って転送するデータの生成、あるいは解析、その他、様々なデータの出力制御等を実行するアプリケーションレイヤであり、例えばＨＴＭＬ５を適用したデータ生成、解析、出力処理等を行う。
一方、図３の右側に示す、（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）に対応するプロトコルスタックは、下位レイヤから順に、以下のレイヤを持つ。
（１）ブロードバンド物理レイヤ（Ｂｒｏａｂａｎｄ ＰＨＹ）
（２）ＩＰユニキャストレイヤ（ＩＰ Ｕｎｉｃａｓｔ）
（３）ＴＣＰレイヤ
（４）ＨＴＴＰレイヤ
（５）ＥＳＧ，Ｓｉｇｎａｌｉｎｇ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣ
（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５））
（１）ブロードバンド物理レイヤ（Ｂｒｏａｂａｎｄ ＰＨＹ）は、ブロードバンド通信を実行する例えばネットワークカード等の通信部を制御するデバイスドライバ等の通信制御部によって構成される物理レイヤである。
（２）ＩＰユニキャストレイヤ（ＩＰ Ｕｎｉｃａｓｔ）は、ＩＰユニキャスト送受信処理を実行するレイヤである。
（３）ＨＴＴＰレイヤは、ＨＴＴＰパケットの生成、解析処理レイヤである。
この上位レイヤは、図３左側の（ａ）ブロードキャスト通信（例えば放送型データ配信）のスタック構成と同様である。
なお、送信装置（サーバ）２０、受信装置（クライアント）３０は、図３の２つの処理系、すなわち、
（ａ）ブロードキャスト通信（例えば放送型データ配信）
（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）
これら２つの通信プロトコルスタックの少なくともいずれかに従った処理を行なう。
図３に示すプロトコルスタックにおいて、ＲＯＵＴＥ（ＦＬＵＴＥ）に従ってマルチキャスト転送されるファイル群の属性（ファイルの識別子であるＵＲＬを含む）は、ＲＯＵＴＥ（ＦＬＵＴＥ）の制御ファイル内に記述することもできれば、ファイル転送セッションを記述するシグナリング（Ｓｉｇｎａｌｉｎｇ）データ中に記述することもできる。また、ファイル転送セッションのさらなる詳細属性を（エンドユーザへの提示用途にも適用可能な）ＥＳＧにより記述することもできる。
前述したように、放送波およびネットワークを介したデータ配信システムに関する規格の１つとしてＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍ Ｃｏｍｍｉｔｔｅ）３．０の規格化が進められている。
ＡＴＳＣ３．０におけるＩＰベースのトランスポートスタックの標準化において、ＭＰＥＧ−ＤＡＳＨのファイルフォーマット（ＩＳＯ−ＢＭＦＦファイル、ＭＰ４ファイル）に基づくファイルをＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）を拡張したＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）プロトコルにより転送する方法が提案され、標準候補方式として設定された。
ＲＯＵＴＥプロトコルを適用することで、ＤＡＳＨ規格のフラグメント化されたＭＰ４（ｆｒａｇｍｅｎｔｅｄ ＭＰ４）ファイルシーケンスと、ＤＡＳＨ規格の制御情報（シグナリングデータ）格納メタファイルであるＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ））、ならびに、放送配信のためのシグナリングデータである、
ＵＳＢＤ／ＵＳＤ（Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｂｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ／Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）、
Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ ｂａｓｅｄ Ｔｒａｎｓｐｏｒｔ Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）、
例えば、これらのシグナリンクデータ等を転送することができる。
ＵＳＤは、例えば放送局、あるいは番組など、所定のサービス単位の情報から構成され、サービスを受領するためのアクセス情報（ＵＲＬ等）、コーデック情報、再生タイミング情報等、受信装置においてサービスを利用するために必要となる情報から構成される。ＵＳＢＤは、ＵＳＤの束（バンドル）である。
Ｓ−ＴＳＩＤは、各サービス単位の付加情報であり、ＵＳＤに記録されない付加的な情報が記録される。
前述したように、ＲＯＵＴＥプロトコルはＦＬＵＴＥをベースとするプロトコルである。ＦＬＵＴＥにおける転送制御パラメータを記述したメタデータファイルをＦＤＴ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｔａｂｌｅ）と呼び、ＲＯＵＴＥにおける転送制御パラメータを記述したメタデータファイルをＳ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ ｂａｓｅｄ Ｔｒａｎｓｐｏｒｔ Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）と呼ぶ。Ｓ−ＴＳＩＤはＦＤＴのスーパーセットでありＦＤＴを含む。
ＡＴＳＣ３．０サービスレイヤのシグナリングデータ（ＳＬＳ：Ｓｅｒｖｉｃｅ Ｌａｙｅｒ Ｓｉｇｎａｌｉｎｇ）として提案されているＵＳＢＤ／ＵＳＤ、Ｓ−ＴＳＩＤ、ＭＰＤ等はすべてＲＯＵＴＥセッションにより転送される。
なお、ＡＴＳＣ３．０に従った放送サービスにおいては、上述したＲＯＵＴＥプロトコルの他、ＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）を適用した通信も利用可能である。
［４．受信装置におけるアプリケーションを適用したデータ出力例について］
次に、放送サーバ２１等の送信装置２０から様々な番組コンテンツや、アプリケーション等のデータを受信して、出力する受信装置（クライアント）３０におけるデータ出力例について説明する。
図５は、受信装置３０が、放送サーバ２１等の送信装置２０から、ある番組コンテンツを受信し、受信装置３０の表示部に表示している状態を示している。
放送サーバ２１等の送信装置２０は、番組配信に併せて、ＮＲＴコンテンツ（ノンリアルタイムコンテンツ）として、天気情報を表示するアプリケーション、およびこの天気情報表示アプリケーションに利用される様々なデータファイル、例えば動画、静止画、音声等の様々なデータを含むデータファイルを受信装置３０に提供する。
以下では、これらのアプリケーションおよびデータファイルを「リソース」と呼ぶ。
受信装置３０は、送信装置２０から受信した「リソース」、すなわちアプリケーションの構成するデータファイルを利用して、図５に示すように、番組表示に併せて、天気情報の表示を行うことができる。
このような、アプリケーションを利用したデータ表示を行うためには、アプリケーションを構成する全てのファイル、例えば、
ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイル、
動画ファイル、
音声ファイル、
スタイルシート、
例えば、これらのアプリケーション構成ファイルを全て取得し、受信装置３０の記憶部であるキャッシュ部に格納しておくことが必要となる。
しかし、例えば、受信装置のキャッシュ容量が不足して、一部の動画ファイルがキャッシュできないといっち状態が発生し、この状態でアプリケーションを実行すると、キャッシュできなかった動画の再生領域が空白となった不完全なアプリケーションが実行される事態が発生する。
次に、図６を参照して、受信装置３０が、送信装置２０から受信するアプリケーションを広告表示に利用した例について説明する。
受信装置３０には、図６下部に示すタイムライン（時間軸（ｔ））に従って、例えば映画やニュース、その他の放送番組（メインコンテンツ）と広告が交互に出力される。
ユーザが選択したあるチャンネルの番組開始時間をｔ０とすると、以下のように、間推移に従って放送番組と広告が交互に出力される。
時間ｔ０〜ｔ１：広告
時間ｔ１〜ｔ２：放送番組
時間ｔ２〜ｔ３：広告
時間ｔ３〜ｔ４：放送番組
時間ｔ４〜ｔ５：広告
時間ｔ５〜：放送番組
ここで、受信装置３０に出力される広告は、送信装置２０が送信する番組コンテンツとは別に送信するアプリケーションを利用して表示される。送信装置２０は、様々なユーザに応じた広告、いわゆるターゲット広告を表示する複数の広告アプリケーションをＮＲＴ（ノンリアルタイム）コンテンツとして受信装置３０に送信する。例えば、
（ａ）子供向けのゲームの広告表示アプリケーション、
（ｂ）若者向けのファッションアイテムの広告アプリケーション、
（ｃ）大人向けのアルコール飲料の広告アプリケーション、
送信装置２０は、例えば、このような様々なユーザ（視聴者）向けの広告アプリケーションを受信装置３０に対して送信する。
受信装置３０は、受信装置３０側で設定したユーザ（視聴者）情報に基づいて、ユーザに最適な広告を選択取得し、出力する。
ユーザ情報とは、例えば、ユーザ（視聴者）の年齢、性別、住所、趣味嗜好など、さまざまな情報である。
これらのユーザ情報は、受信装置の記憶部に予め登録した情報を用いる。
あるいは、番組開始時点で、ユーザ（視聴者）にユーザ情報を入力させ、この入力情報を用いる構成としてもよい。
受信装置３０が、例えば放送波を介して取得するアプリケーションは、前述したように、様々なデーファイルによって構成される。すなわち、前述したように、
ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイル、
動画ファイル、
音声ファイル、
スタイルシート、
例えば、これらの複数のアプリケーション構成ファイルを全て取得し、受信装置３０の記憶部であるキャッシュ部に格納した後に、アプリケーションの実行を開始することで、完全な広告再生を行なうことができる。
アプリケーション構成ファイルのキャッシュ処理を確実に実行するためには、受信装置３０は、自装置のキャッシュ空き容量と、取得予定のアプリケーションのデータサイズを比較した上で、キャッシュ可能なデータを選択的に取得してキャッシュ処理を開始することが重要となる。
このようなキャッシュ制御を実行することで、キャッシュ処理を開始したデータは、確実に受信装置３０のキャッシュ部（記憶部）に格納することができる。
このようなキャッシュ制御を行わずに、キャッシュ処理を開始してしまうと、キャッシュ処理の途中で、キャッシュ部（記憶部）が溢れ、データの一部がキャッシュできないといった事態が発生する可能性がある。
本開示の受信装置３０は、自装置のキャッシュ空き容量と、取得予定のアプリケーションのデータサイズを比較した上で、キャッシュ可能なデータを選択的に取得してキャッシュ処理を開始するキャッシュ制御を実行する。
このキャッシュ制御処理の具体的構成については後述する。
なお、図５、図６を参照して説明したアプリケーションの例は一例であり、送信装置２０は、受信装置３０に対して提供するアプリケーションは、図５、図６を参照して説明した例以外にも様々なアプリケーションがある。
例えば、ニュース情報提供アプリ、野球中継時の選手情報提供アプリ、旅番組における地図情報、ホテル情報、クイズ、アンケート処理等を実行するアプリケーション等、様々なアプリケーションがある。
［５．受信装置の構成例と処理例について］
次に、図７以下を参照して受信装置３０の構成例と処理例について説明する。
なお、受信装置３０は、先に図１を参照して説明したように、テレビ３１、ＰＣ３２、携帯端末３３、あるいは、その他、例えば、スマートフォン、タブレット端末、スマートウォッチ、ウェアラブルデバイス等、様々な機器によって構成される。
図７に示す受信装置３０は、放送サーバや、広告サーバ等の送信装置２０からの送信データを受信するミドルウェア１１０と、受信データの解析やキャッシュ処理を実行するプロキシサーバ１２０、番組再生やアプリケーション実行によるデータ再生処理を実行するデータ再生部１３０を有する。
放送サーバや、広告サーバ等の送信装置２０は、放送波や、インターネット等の通信ネットワークを介したデータ送信により、放送コンテンツ等からなるＡＶセグメント、アプリケーション、シグナリングデータ、その他のデータを送信する。
図７に示す受信装置３０のミドルウェア１１０は、送信装置２０から放送波を介した提供データを受信し、解析する。
ミドルウェア１１０は、通信部（ＰＨＹ／ＭＡＣ）１１１、シグナリングデータを取得するシグナリング取得部１１２、シグナリングデータを解析するシグナリング解析部１１３、シグナリングデータ、および、映像、音声等の番組コンテンツデータや、アプリケーション等のＮＲＴコンテンツ等のデータファイルを取得するセグメント取得部１１４を有する。
ミドルウェア１１０が受信したデータは、プロキシサーバ１２０のキュッシュ制御部１２１介してキャッシュ部（プロキシキャッシュ）１２２に格納される。プロキシサーバ１２０は、さらにネットワーク経由で送信装置２０から取得したデータをキャッシュ部１２２に格納する。
プロキシサーバ１２０のキャッシュ制御部１２１は、データ再生部１３０の再生制御部（ＤＡＳＨ Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２からのデータ取得要求を入力し、要求データをデータ再生部に提供する。
例えば、キャッシュ制御部１２１は、再生制御部（ＤＡＳＨ Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２からのデータ取得要求に応じたアドレス解決処理等を行い、アドレスに応じたデータをキャッシュ部１２１から取得して、データ再生部１３０の再生制御部（ＤＡＳＨ Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２に出力する。なお、キャッシュ部１２２に要求データが格納されていない場合は、外部から取得して提供する場合もある。
データ再生部１３０の再生制御部（ＤＡＳＨ Ｃｌｉｅｎｔ）１３１は、ＤＡＳＨ（ＭＰＥＧ−ＤＡＳＨ）規格に従って送信されたコンテンツの再生制御を実行する。
前述したように、ＭＰＥＧ−ＤＡＳＨ規格には、以下の２つの規格が含まれる。
（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格、
（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格、
送信装置２０から、受信装置３０に対するコンテンツ配信は、上記のＭＰＥＧ−ＤＡＳＨ規格に従って実行される。
コンテンツは、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って所定単位の分割データであるセグメント（ＡＶセグメント等）として送信され、再生制御部（ＤＡＳＨ Ｃｌｉｅｎｔ）１３１は、マニフェスト・ファイル（ＭＰＤ）を参照して、再生対象コンテンツを格納したセグメントを取得する処理等を実行する。
アプリケーション制御部１３２は、例えば、先に図５、図６を参照して説明した天気予報、広告のアプリケーション等、送信装置２０から提供されるアプリケーションの実行、開始、終了等の制御を行う。
出力制御部１３３は、再生制御部１３１やアプリケーション制御部１３２から提供される番組構成データやアプリケーション実行用データを取得し、取得データの復号処理や、表示部への出力処理等を実行する。
なお、再生制御部（ＤＡＳＨ Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２は、送信装置２０（放送サーバ２１、広告サーバ２２等）が送信するシグナリングデータを参照し、シグナリングデータに記述された情報に従って必要なデータをプロキシサーバ１２０から取得し、また、シグナリングデータに記述された情報に従って再生制御やアプリケーション制御を実行する。
先に図２を参照して説明したように、シグナリングデータ５０は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、アプリケーション制御情報等の様々な制御情報によって構成される。
再生制御部（ＤＡＳＨ Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２は、シグナリングデータ（ＳＬＳ：Ｓｅｒｖｉｃｅ Ｌａｙｅｒ Ｓｉｇｎａｌｉｎｇ）を取得して取得したシグナリングデータに基づくデータ取得処理や、データ再生制御や、アプリケーション実行制御等を実行する。
例えば、アプリケーション制御部１３２は、アプリケーション対応の属性情報や制御情報を記録した様々なシグナリングデータに基づくアプリケーション制御を実行する。具体的には、例えば、ＡＴＳＣ３．０のシグナリングデータであるＵＳＢＤ／ＵＳＤや、Ｓ−ＴＳＩＤ、あるいは、個々のアプリケーションに対応する属性情報や制御情報を記録したアプリケーション・インフォーメーション・テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）などを利用したアプリケーション制御を実行する。
なお、再生制御部（ＤＡＳＨ Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２は、プロキシサーバ１２０のキャッシュ部１２２に格納されたデータを利用した処理を実行する。
キャッシュ部１２２に格納されるデータは、ミドルウェア（Ｃｌｉｅｎｔ Ｌｏｃａｌ ＡＴＳＣ Ｍｉｄｄｌｅｗａｒｅ）１１０が受信したデータや、プロキシサーバ１２０がネットワークを介して受信したデータである。
ミドルウェア１１０、またはプロキシサーバ１２０が放送波あるいは通信ネットワークを介して取得するデータは、例えば、ＤＡＳＨ−ＭＰＤファイルやＤＡＳＨセグメント（ｓｅｇｍｅｎｔ）ファイル、その他一般のアプリケーションファイル、ならびに、シグナリングデータを格納したＳＬＳ（Ｓｅｒｖｉｃｅ ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）ファイル等である。
これらは、キャッシュ制御部１２１の制御に基づいてキャッシュ部１２２に格納される。
その後、キャッシュ制御部１２１は、再生制御部（ＤＡＳＨ Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２の要求に応じて、キャッシュ部１２２から要求データを取得して、再生制御部（ＤＡＳＨ Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２に提供され、ストリームのレンダリングや、アプリケーションの実行等のデータ再生処理に利用される。
再生制御部（ＤＡＳＨ Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２がセグメント（ｓｅｇｍｅｎｔ）ファイル、その他一般のアプリケーションファイル、ならびに、シグナリングデータファイルの取得を、プロキシサーバ１２０のキャッシュ制御部１２１に対して要求（ＨＴＴＰリクエスト）すると、それを受けたプロキシサーバ１２０のキャッシュ制御部１２１は、キャッシュ部１２２からデータ取得を行う。なお、キャッシュ部１２２にデータがない場合は、放送、またはネット経由での取得処理を行う。
また、再生制御（ＤＡＳＨ Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２は、コンテンツの再生、アプリケーションの制御情報等を記録したシグナリングデータを取得する。これらは、シグナリング取得部（ＳＬＳ Ｓｉｇｎａｌｉｎｇ Ｒｅｔｒｉｅｖｅｒ）１１２によって取得される。
例えば、ＵＳＢＤ／ＵＳＤや、ＡＩＴや、Ｓ−ＴＳＩＤ、ＭＰＤ等の様々なシグナリングデータが取得され、利用される。
シグナリング取得部（ＳＬＳ Ｓｉｇｎａｌｉｎｇ Ｒｅｔｒｉｅｖｅｒ）１１２は、通信部（ＡＴＳＣチューナ：ＡＴＳＣ３．０ ＰＨＹ／ＭＡＣ）１１１を介して放送受信するＳＬＳ ＬＣＴパケットにより運ばれるシグナリングデータを抽出する。
これらのシグナリングデータは、ミドルウェア１１０のシグナリング取得部１１２によって取得され、シグナリング解析部（ＳＬＳ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）１１３において解析される。
シグナリングデータには、例えば、番組再生に必要となるＡＶセグメントや、アプリケーションの実行に必要となる様々なデータファイル（リソース）等を取得するためのアドレス情報（ＵＲＬ）が含まれ、シグナリング解析部１１３は、必要となるセグメントやリソースファイルを取得するアドレス情報（放送配信アドレス情報）の取得処理などを行う。
この放送配信アドレス情報に基づいて、所望のファイルが格納されたＬＣＴパケットを放送ストリームから取得し、取得データがプロキシサーバ１２０のキャッシュ部１２２内に展開される。
なお、プロキシサーバ１２０のキャッシュ制御部１２１は、アプリケーションの取得、キャッシュ処理に際して、キャッシュ部１２２のキャッシュ可能なデータ容量を確認し、さらに、シグナリングデータからアプリケーションサイズや、アプリケーションの構成要素単位のデータサイズを取得して、キャッシュ可能なデータを選択してキャッシュ処理を実行する。このキャッシュ処理については、後段で詳細に説明する。
［６．アプリケーションの構成例について］
先に図５、図６を参照して説明したように、受信装置３０は、送信装置２０から例えば放送波を介して様々なアプリケーションを受信し、受信したアプリケーションを実行する。
送信装置２０が受信装置３０に提供するアプリケーションの構成例について、図８以下を参照して説明する。
図８には、１つのアプリケーション（ＡＰＰ１）２００の構成例を示している。
アプリケーション（ＡＰＰ１）２００は、１つ以上のプレゼンテーション・ユニット（ＰＵ：Ｐｅｒｅｓｅｎｔａｔｉｏｎ Ｕｎｉｔ）２１０によって構成される。
なお、１つのプレゼンテーション・ユニット（ＰＵ：Ｐｅｒｅｓｅｎｔａｔｉｏｎ Ｕｎｉｔ）は、１つまたは複数のＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイル２１１と、このＨＴＭＬファイルを利用して提示されるデータファイル２１２のセットによって構成される。
具体的には、例えば１つのプレゼンテーション・ユニット（ＰＵ）は、以下の構成要素からなるユニットである。
（１）１つまたは複数のＨＴＭＬファイル
（２）上記ＨＴＭＬに従って出力される画像（動画、静止画）ファイル、
（３）上記ＨＴＭＬに従って出力される音声ファイル、
（４）上記ＨＴＭＬに従ったデータ出力スタイルを規定したスタイルシート格納ファイル、
例えば、上記構成要素によって１つのプレゼンテーション・ユニット（ＰＵ）が設定される。
１つのプレゼンテーション・ユニット（ＰＵ）に属するデータが全て取得できれば、そのプレゼンテーション・ユニット（ＰＵ）に含まれるＨＴＭＬ文書によるデータ出力、例えばＷｅｂペーシの出力が完全な形で実行されることが保証される。
なお、アプリケーション（ＡＰＰ１）２００は、１つ、または、複数のプレゼンテーション・ユニット（ＰＵ：Ｐｅｒｅｓｅｎｔａｔｉｏｎ Ｕｎｉｔ）によって構成される。
図８に示す例では、アプリケーション（ＡＰＰ１）２００は３つのプレゼンテーション・ユニット（ＰＵ１１（Ｇ１（グループ１））〜ＰＵ３１（Ｇ３（グループ３）））を有している。
１つのアプリケーション内の各プレゼンテーション・ユニット（ＰＵ）は、それぞれ異なるグループＩＤ（ｇｒｏｕｐＩｄ）が設定される。
プレゼンテーション・ユニット（ＰＵ）の構成データ（ＨＤＭＬファイル、データファイル）の各々には、識別子としてグループＩＤが設定され、それぞれがどのＰＵに属するデータであるかを識別可能な構成となっている。
また、プレゼンテーション・ユニット（ＰＵ１１（Ｇ１）〜ＰＵ３１（Ｇ３））間にはリンクが設定される場合がある。図８に示す例では、プレゼンテーション・ユニット（ＰＵ１１（Ｇ１））のＨＴＭＬファイル２１１から、プレゼンテーション・ユニット（ＰＵ２１（Ｇ２））のＨＴＭＬファイルへのリンク２１３ａが設定されている。
また、プレゼンテーション・ユニット（ＰＵ１１（Ｇ１））のＨＴＭＬファイルから、プレゼンテーション・ユニット（ＰＵ３１（Ｇ３））のＨＴＭＬファイルへのリンク２１３ｂが設定されている。
リンクが設定された２つのＰＵは、例えば、リンク元のプレゼンテーション・ユニット（ＰＵ）の実行中に、何らかのイベントをトリガとして、リンク先のプレゼンテーション・ユニットの実行を開始するというＰＵの遷移を行う関係にある。
例えばプレゼンテーション・ユニット（ＰＵ１１（Ｇ１））のＨＴＭＬ文書による表示データ中の一部の領域、例えばタグ等のアイコンの表示領域をユーザがクリックすると、このクリック処理が遷移実行イベントとして検出され、リンク先のプレゼンテーション・ユニット（ＰＵ２１（Ｇ２））のＨＴＭＬ文書に基づく表示データが表示されるといった処理が行われる。
遷移イベントは、ユーザ操作に限らず、例えばアプリケーション・インフォメーション・テーブル（ＡＩＴ）等のシグナリングデータの記述等、例えば時間経過に基づくイベント等、様々なイベントがある。
なお、アプリケーションの表示開始や、表示終了等を指定するコントロールコード、その他のアプリ制御情報は、アプリケーション対応のシグナリングデータであるアプリケーション・インフォメーション・テーブル（ＡＩＴ）に記録されており、受信装置３０のアプリケーション制御部１３２は、ＡＩＴの記録情報に従ってアプリケーションを実行する。
なお、ＡＩＴには特定のアプリケーション（ＡＰＰ）の取得情報（ＵＲＬ等）や、アプリの実行態様を規定したコントロールコード、例えば、自動起動処理（ＡＵＴＯＳＴＡＲＴ）や、プリフェッチ（ｐｒｅｆｅｔｃｈ）等の様々なアプリの実行態様規定情報であるコントロールコードも記録されている。
なお、アプリケーションには、個別のアプリケーションを識別する識別子であるアプリケーションＩＤが設定される。
ＡＩＴ等のシグナリングデータには、アプリケーションＩＤとともに、そのアプリケーションに関する様々な情報、例えばアプリケーションサイズ情報や、アクセス情報や制御情報等が記録される。
ＡＩＴ等のシグナリングデータに記録される情報の詳細については後段で説明する。
図８に示すようにアプリケーションＩＤは、
（ａ）組織ＩＤ（ｏｒｇＩｄ）、
（ｂ）アプリ本体ＩＤ（ａｐｐＩｄ）、
これらの２つのＩＤの連結データとして構成される。
組織ＩＤは、アプリケーションを提供する放送局や、アプリケーションの制作者等の組織を示す識別子である。
アプリ本体ＩＤは、アプリケーション本体各々に対応付けて設定される識別子である。
例えばアプリケーションＩＤの前半の組織ＩＤを参照することで、アプリケーションを提供する放送局や、アプリケーションの制作者等の組織を確認することが可能となり、アプリケーションＩＤの後半のアプリ本体ＩＤを参照することで、１つの組織の提供する複数アプリの中の１つのアプリを個別に識別することが可能となる。
また、アプリケーションの構成要素であるプレゼンテーション・ユニット（ＰＵ）にも、個別のプレゼンテーション・ユニット（ＰＵ）を識別する識別子であるプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）が設定される。
詳細は後述するが、プレゼンテーション・ユニット（ＰＵ）に関するアクセス情報等の属性情報を記録したＳ−ＴＳＩＤ等のシグナリングデータには、プレゼンテーション・ユニット（ＰＵ）に属する各ファイルに対応付けてプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）が記録される。
受信装置３０は、放送局等の送信装置２０の提供するシグナリングデータであるＳ−ＴＳＩＤを参照することで、送信装置２０１の提供する各ファイルがどのプレゼンテーション・ユニット（ＰＵ）に属するファイルであるかを識別することができる。
なお、Ｓ−ＴＳＩＤには、各プレゼンテーション・ユニット（ＰＵ）単位のデータサイズも記録される。
Ｓ−ＴＳＩＤ等のシグナリングデータに記録される情報の詳細については後段で説明する。
図８に示すようにプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）は、
（ａ）アプリ本体ＩＤ（ａｐｐＩｄ）、
（ｂ）グループＩＤ（ｇｒｏｕｐＩｄ）、
これらの２つのＩＤを連結したデータとして構成される。
アプリ本体ＩＤは、このプレゼンテーション・ユニットが属するアプリケーション本体に対応付けて設定される識別子である。
前述のアプリケーションＩＤの構成要素となる「アプリ本体ＩＤ」と同一の値が設定されることになる。
グループＩＤは、各プレゼンテーション・ユニット（ＰＵ）個別の識別子である。１つのアプリケーションに複数のプレゼンテーション・ユニット（ＰＵ）が含まれる場合、それぞれ異なるグループＩＤが設定される。
プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）の前半のアプリ本体ＩＤを参照することで、このプレゼンテーション・ユニットが属するアプリケーションを確認することが可能となり、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）の後半のグループＩＤを参照することで、１つのアプリケーションに含まれる複数のプレゼンテーション・ユニット（ＰＵ）を個別に識別することが可能となる。
図８には、１つのアプリケーション（ＡＰＰ１）のみを示しているが、受信装置３０においてアプリケーションを実行する場合、複数のアプリケーションを利用した処理を行なう場合もある。
具体的な例について、図９を参照して説明する。
図９には、以下の３つのアプリケーションを示している。
（１）アプリケーション１（ＡＰＰ１）
（２）アプリケーション２（ＡＰＰ２）
（３）アプリケーション３（ＡＰＰ３）
図９に示す点線矢印はリンク関係を示している。
リンクは、図８を参照して説明したように、各アプリケーション内のプレゼンテーション・ユニット（ＰＵ）間に設定されているとともに、図９に示す例では、各アプリケーション間にも設定されている。
アプリケーション１〜３を利用した処理において、最初に起動されるアプリケーションはアプリケーション１（ＡＰＰ１）であり、その中の１つのプレゼンテーション・ユニット（ＰＵ１１）のＨＴＭＬ文書が最初に起動されるＨＴＭＬ文書であるとする。
なお、あるアプリの実行時に最初に利用されるＨＴＭＬ文書をエントリ文書と呼ぶ。
図９に示す例では、アプリケーション１（ＡＰＰ１）のエントリ文書は、プレゼンテーション・ユニット（ＰＵ１１）のＨＴＭＬ文書である、すなわち図９に示すエントリ文書２２１である。
アプリケーション１（ＡＰＰ１）から、アプリケーション２（ＡＰＰ２）に向かう点線矢印で示すリンクは、アプリケーション１（ＡＰＰ１）の実行中に、例えばユーザによる画面操作、あるいは時間経過等の所庭の遷移イベントの発生に基づいてアプリケーション２（ＡＰＰ２）を起動する処理が行われることを示す。
このように、複数のアプリケーションにリンクを設定して、複数のアプリケーションを適用した処理が行われる場合もある。
なお、アプリケーション間のリンク関係や、プレゼンテーション・ユニット（ＰＵ）間のリンク関係についての情報は、ＡＩＴやＳ−ＴＳＩＤ等のシグナリングデータに記録されており、受信装置３０は、これらのシグナリングデータの記述に基づいて、各リンク関係を把握することが可能となる。
［７．アプリケーションのキャッシュ処理について］
受信装置３０において、アプリケーションを実行するためには、アプリケーションの構成データを受信装置の記憶部（キャッシュ部）に格納（キャッシュ）することが必要となる。
例えば、図７に示すキャッシュ部１２２に、実行対象となるアプリケーションの構成データ（アプリケーションリソース）を格納することが必要である。
アプリケーションを実行するのは、アプリケーション制御部１３０であり、アプリケーション制御部１３０は、アプリケーション実行に必要なデータ（リソース）をキャッシュ部１２２から取得してアプリケーションを実行する。
キャッシュ部１２２に必要なデータが格納されていない場合、アプリケーションの実行エラーが発生する可能性がある。
アプリケーションの実行タイミングまでに必要なデータをキャッシュ部１２２に格納することが必要となるが、キャッシュ部１２２に十分な空き容量が無い場合には、アプリケーション構成データを全てキャッシュ部１２２に格納することができない可能性もある。
本開示の構成において、受信装置３０は、キャッシュ部１２２に格納可能なデータ量（空き容量）に相当するキャッシュサイズと、アプリケーションサイズ、またはプレゼンテーション・ユニット（ＰＵ）サイズを比較して、プレゼンテーション・ユニット（ＰＵ）単位、または、アプリケーション単位で、キャッシュ部１２２に対するデータ格納処理（キャッシュ処理）を行なう。
少なくともプレゼンテーション・ユニット（ＰＵ）単位でキャッシュ部１２２にデータが格納されていれば、プレゼンテーション・ユニット（ＰＵ）に含まれるＨＴＭＬ文書を適用したデータ出力は完全な形で実行されることが保証される。
以下、受信装置３０におけるキャッシュ処理、すなわち、アプリケーション単位、またはプレゼンテーション・ユニット（ＰＵ）単位でキャッシュ部１２２にデータを格納する処理について説明する。
図１０は、アプリケーション、およびプレゼンテーション・ユニット（ＰＵ）のデータサイズと、受信装置のキャッシュサイズとの対応関係の一例について説明する図である。
横軸がデータサイズ、およびキャッシュサイズに相当する軸である。
上から、順に、
（Ａ）アプリサイズ
（Ｂ）受信装置のキャッシュサイズ
これらの各サイズ設定例を示している。
（Ａ）アプリサイズとして示す例は、図９を参照して説明した以下の３つのアプリケーションの各サイズを示している。
（１）アプリケーション１（ＡＰＰ１）
（２）アプリケーション２（ＡＰＰ２）
（３）アプリケーション３（ＡＰＰ３）
アプリケーション１（ＡＰＰ１）のデータサイズは、Ｓ３である。
アプリケーション１（ＡＰＰ１）＋アプリケーション２（ＡＰＰ２）の合計データサイズは、Ｓ４である。
アプリケーション１（ＡＰＰ１）〜アプリケーション３（ＡＰＰ３）の合計データサイズは、Ｓ５である。
また、アプリケーション１（ＡＰＰ１）は３つのプレゼンテーション・ユニット（ＰＵ）から構成されている。
プレゼンテーション・ユニット（ＰＵ１１）のデータサイズは、Ｓ１である。
プレゼンテーション・ユニット（ＰＵ１１）＋プレゼンテーション・ユニット（ＰＵ１２）の合計データサイズは、Ｓ２である。
プレゼンテーション・ユニット（ＰＵ１１）〜プレゼンテーション・ユニット（ＰＵ１３）の合計データサイズは、Ｓ３であり、アプリケーション１（ＡＰＰ１）のデータサイズ、Ｓ３に一致する。
一方、（Ｂ）受信装置のキャッシュサイズの例として、以下の５つのキャッシュサイズを示している。
（１）最小サイズ（Ｍｉｎｉｍｕｍ）
（２）小サイズ（Ｓｍａｌｌ）
（３）中サイズ（Ｍｅｄｉｕｍ）
（４）大サイズ（Ｌａｒｇｅ）
（５）最大サイズ（Ｍａｘｉｍｕｍ）
これらは、例えば携帯端末、ＰＣ等、送信装置２０の提供するアプリケーションを実行する様々なユーザ装置としての受信装置３０の利用可能なキャッシュサイズの例である。
（１）最小サイズ（Ｍｉｎｉｍｕｍ）のキャッシュの格納（キャッシュ）可能なデータサイズ、すなわちキャッシュサイズは、Ｓ１以上、Ｓ２未満である。
（２）小サイズ（Ｓｍａｌｌ）のキャッシュの格納（キャッシュ）可能なデータサイズ、すなわちキャッシュサイズは、Ｓ２以上、Ｓ３未満である。
（３）中サイズ（Ｍｅｄｉｕｍ）のキャッシュの格納（キャッシュ）可能なデータサイズ、すなわちキャッシュサイズは、Ｓ３以上、Ｓ４未満である。
（４）大サイズ（Ｌａｒｇｅ）のキャッシュの格納（キャッシュ）可能なデータサイズ、すなわちキャッシュサイズは、Ｓ４以上、Ｓ５未満である。
（５）最大サイズ（Ｍａｘｉｍｕｍ）のキャッシュの格納（キャッシュ）可能なデータサイズ、すなわちキャッシュサイズは、Ｓ５以上である。
このような様々なキャッシュサイズを持つ受信装置が、送信装置から送信される３つのアプリケーションを、キャッシュ部にキャッシュ（格納）して、実行しようとする場合、それぞれのキャッシュサイズに応じて、キャッシュ対象を選択することが必要である。
理想的には、アプリケーション１〜アプリケーション３の全てのアプリ構成データファイルを全てキャッシュすることが望まれるが、これらの３つ全てのアプリを格納可能なのは、（５）最大サイズ（Ｍａｘｉｍｕｍ）のキャッシュのみである。
（１）最小サイズ（Ｍｉｎｉｍｕｍ）〜（４）大サイズ（Ｌａｒｇｅ）のキャッシュを持つ受信装置は、キャッシュ対象データを選択してキャッシュする処理を行なうことが必要となる。
本開示の受信装置のキャッシュ対象選択処理は、以下のルールで実行される。
（ルール１）キャッシュサイズが、リンク関係にあるアプリケーションの全てを格納可能であれば、リンク関係にあるアプリケーションの全てを格納（キュッシュ）する。
（ルール２）キャッシュサイズが、リンク関係にあるアプリケーションの全てを格納可能でない場合、アプリケーション単位、またはプレゼンテーション・ユニット（ＰＵ）単位で、データを格納（キャッシュ）する。
（ルール３）アプリケーション単位ののアプリ格納優先順位は、初期実行アプリケーションからのリンク経路に従う。
（ルール４）プレゼンテーション・ユニット（ＰＵ）単位の格納優先順位は、エントリ文書を持つプレゼンテーション・ユニット（ＰＵ）からのリンク経路に従う。
受信装置は、上記ルールを適用して、自装置のキャッシュサイズと、アプリケーションサイズ、および各プレゼンテーション・ユニット（ＰＵ）サイズを比較して、キャッシュ対象を選択する。
上記ルールに従ったキャッシュ対象選択処理を行なった場合、図１０に示す５つのキャッシュサイズに応じたキャッシュ対象データは、以下の設定となる。
（１）最小サイズ（Ｍｉｎｉｍｕｍ）＝プレゼンテーション・ユニット（ＰＵ１１）
（２）小サイズ（Ｓｍａｌｌ）＝プレゼンテーション・ユニット（ＰＵ１１）＋プレゼンテーション・ユニット（ＰＵ１２）
（３）中サイズ（Ｍｅｄｉｕｍ）＝アプリケーション（ＡＰＰ１）
（４）大サイズ（Ｌａｒｇｅ）＝アプリケーション（ＡＰＰ１）＋アプリケーション（ＡＰＰ２）
（５）最大サイズ（Ｍａｘｉｍｕｍ）＝アプリケーション（ＡＰＰ１）＋アプリケーション（ＡＰＰ２）＋アプリケーション（ＡＰＰ３）
受信装置は、これらのキャッシュ対象選択処理に際して、送信装置２０が送信するシグナリングデータであるＡＩＴやＳ−ＴＳＩＤを参照する。
これらのシグナリングデータには、アプリケーション単位の情報、プレゼンテーション・ユニット（ＰＵ）単位の情報が記録されている。
例えば、先に図８を参照して説明したアプリケーションＩＤ、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）に対応付けて、各アプリ、各ＰＵのサイズ情報や、リンク情報が記録されている。
ＩＤ情報を用いたキャッシュ対象選択処理例について、図１１を参照して説明する。
図１１には、図１０を参照して説明した以下の５つのキャッシュサイズにおけるキャッシュ対象選択処理例を示している。
（１）最小サイズ（Ｍｉｎｉｍｕｍ）
（２）小サイズ（Ｓｍａｌｌ）
（３）中サイズ（Ｍｅｄｉｕｍ）
（４）大サイズ（Ｌａｒｇｅ）
（５）最大サイズ（Ｍａｘｉｍｕｍ）
（１）最小サイズ（Ｍｉｎｉｍｕｍ）の許容キャッシュサイズを持つ受信装置は、エントリ文書を持つプレゼンテーション・ユニット（ＰＵ１１）を最優先のキャッシュ対象ＰＵとして選択する。
エントリ文書を持つプレゼンテーション・ユニット（ＰＵ１１）は、シグナリングデータ（ＡＩＴ，Ｓ−ＴＳＩＤ）に基づいて判別することができる。
エントリ文書を持つプレゼンテーション・ユニット（ＰＵ１１）のＰＵＩＤを持つファイルをキャッシュ対象として選択してキャッシュ処理を実行する。
シグナリングデータとしてのＳ−ＴＳＩＤには、プレゼンテーション・ユニット（ＰＵ）を構成するファイル単位で、各ファイルのグループＩＤが記録されている。すなわち、先に図８を参照して説明したプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）を構成する後半ＩＤとして設定されるグループＩＤが、各ファイルに対応付けて記録されている。
最小サイズ（Ｍｉｎｉｍｕｍ）の許容キャッシュサイズを持つ受信装置は、エントリ文書を持つプレゼンテーション・ユニット（ＰＵ１１）のＩＤ（ＰＵＩＤ）のグループＩＤ（ｇｒｏｕｐＩｄ１）と同じグループＩＤが、シグナリングデータ（Ｓ−ＴＳＩＤ）のファイルリストに記録されたファイルをキャッシュ対象として選択する。
なお、シグナリングデータのデータ記録構成の詳細については後段で説明する。
（２）小サイズ（Ｓｍａｌｌ）の許容キャッシュサイズを持つ受信装置は、エントリ文書を持つプレゼンテーション・ユニット（ＰＵ１１）を最優先のキャッシュ対象ＰＵとして選択し、さらに、このエントリ文書を持つプレゼンテーション・ユニット（ＰＵ１１）からリンク先として指定されている第２のプレゼンテーション・ユニット（ＰＵ１２）をキャッシュ対象とすることができる。
前述したように、シグナリングデータとしてのＳ−ＴＳＩＤには、プレゼンテーション・ユニット（ＰＵ）を構成するファイル単位で、各ファイルのグループＩＤが記録されている。
小サイズ（Ｓｍａｌｌ）の許容キャッシュサイズを持つ受信装置は、
エントリ文書を持つプレゼンテーション・ユニット（ＰＵ１１）のＩＤ（ＰＵＩＤ）のグループＩＤ（ｇｒｏｕｐＩｄ１）、
リンク先のプレゼンテーション・ユニット（ＰＵ１２）のＩＤ（ＰＵＩＤ）のグループＩＤ（ｇｒｏｕｐＩｄ２）、
これら２つのグループＩＤ（ｇｒｏｕｐＩｄ１、またはｇｒｏｕｐＩｄ２）のいずれかと一致するグループＩＤが記録されたファイルを、シグナリングデータ（Ｓ−ＴＳＩＤ）のファイルリストからキャッシュ対象として選択する。
（３）中サイズ（Ｍｅｄｉｕｍ）の許容キャッシュサイズを持つ受信装置は、初期実行アプリケーション（ＡＰＰ１）を構成するプレゼンテーション・ユニット（ＰＵ１１〜ＰＵ１３）を全てキャッシュ対象とすることができる。
先に図８を参照して説明したように、プレゼンテーション・ユニット（ＰＵ）にはプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）が設定されており、このＩＤの前半は、アプリ本体ＩＤによって構成され、プレゼンテーション・ユニット（ＰＵ）の属するアプリケーションが識別可能な設定となっている。
従って、受信装置は、シグナリングデータとしてのＳ−ＴＳＩＤに記録されたプレゼンテーション・ユニット（ＰＵ）のリストから、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）の前半に設定されたアプリ本体ＩＤが、エントリ文書のＰＵのアプリ本体ＩＤと同じ値を持つプレゼンテーション・ユニットをキャッシュ対象として選択すればよい。
図１１に示す例では、アプリ本体ＩＤ＝ａｐｐＩｄ１の設定されたプレゼンテーション・ユニット（ＰＵ）、すなわち、ＰＵ１１〜ＰＵ１３に属するファイルをキャッシュ対象として選択する。
（４）大サイズ（Ｌａｒｇｅ）の許容キャッシュサイズを持つ受信装置は、初期実行アプリケーション（ＡＰＰ１）、および、アプリケーション（ＡＰＰ１）のリンク先として設定されたもう１つのアプリケーション（ＡＰＰ２）をキャッシュ対象とすることができる。
（４）大サイズ（Ｌａｒｇｅ）の許容キャッシュサイズを持つ受信装置は、上述した「（３）中サイズ（Ｍｅｄｉｕｍ）の許容キャッシュサイズを持つ受信装置」と同様の処理によって、アプリケーション（ＡＰＰ１）の構成ファイルを全て取得し、さらに、および、アプリケーション（ＡＰＰ１）のリンク先として設定されたもう１つのアプリケーション（ＡＰＰ２）について、アプリ本体ＩＤ（ａｐｐＩｄ２）を検索キーとしてアプリケーション２（ＡＰＰ２）に属するファイルを検索してキャッシュ対象とする。
図１１に示す例では、
アプリ本体ＩＤ＝ａｐｐＩｄ１、または、
アプリ本体ＩＤ＝ａｐｐＩｄ２、
これらいずれかの設定されたプレゼンテーション・ユニット（ＰＵ）、すなわち、ＰＵ１１〜ＰＵ１３、ＰＵ２１〜ＰＵ２３に属するファイルをキャッシュ対象として選択する。
（５）最大サイズ（Ｍａｘｉｍｕｍ）の許容キャッシュサイズを持つ受信装置は、初期実行アプリケーション（ＡＰＰ１）、および、アプリケーション（ＡＰＰ１）のリンク先として設定されたもう１つのアプリケーション（ＡＰＰ２）、さらに、そのリンク先として設定されたもう１つのアプリケーション（ＡＰＰ３）を全てキャッシュ対象とすることができる。
（５）最大サイズ（Ｍａｘｉｍｕｍ）の許容キャッシュサイズを持つ受信装置は、上述した「（４）大サイズ（Ｌａｒｇｅ）の許容キャッシュサイズを持つ受信装置」と同様の処理によって、アプリケーション（ＡＰＰ１）と、アプリケーション（ＡＰＰ２）の構成ファイルを全て取得し、さらに、および、アプリケーション（ＡＰＰ２）のリンク先として設定されたもう１つのアプリケーション（ＡＰＰ３）について、アプリ本体ＩＤ（ａｐｐＩｄ３）を検索キーとしてアプリケーション３（ＡＰＰ３）に属するファイルを検索してキャッシュ対象とする。
図１１に示す例では、
アプリ本体ＩＤ＝ａｐｐＩｄ１、または、
アプリ本体ＩＤ＝ａｐｐＩｄ２、または、
アプリ本体ＩＤ＝ａｐｐＩｄ３、
これらいずれかの設定されたプレゼンテーション・ユニット（ＰＵ）、すなわち、ＰＵ１１〜ＰＵ１３、ＰＵ２１〜２３、ＰＵ３１〜３３に属するファイルをキャッシュ対象として選択する。
［８．シグナリングデータの構成、およびシグナリングデータを適用したキャッシュ対象データ選択処理について］
次に、図１２以下を参照して、送信装置２０が受信装置３０に提供するシグナリングデータの構成と、受信装置３０において実行するシグナリングデータを適用したキャッシュ対象データ選択処理について説明する。
送信装置２０は、送信装置２０が受信装置３０にアプリケーションを送信するとともに、送信アプリケーションのアクセス情報や、アプリケーションの属性情報、制御情報を記録した様々なシグナリングデータを受信装置３０に提供する。
送信装置２０が受信装置３０に提供するアプリケーションに関するシグナリングデータとしては、例えば、以下のデータがある。
（１）ＵＳＢＤ／ＵＳＤ（Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｂｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ／Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）
（２）Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ ｂａｓｅｄ Ｔｒａｎｓｐｏｒｔ Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）、
（３）アプリケーション・インフォーメーション・テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）
前述したように、ＵＳＤは、例えば放送局、あるいは番組など、所定のサービス単位の情報から構成され、サービスを受領するためのアクセス情報（ＵＲＬ等）、コーデック情報、再生タイミング情報等、受信装置においてサービスを利用するために必要となる情報から構成される。ＵＳＢＤは、ＵＳＤの束（バンドル）であり、ＵＳＤもＵＳＢＤも内容的には同じ制御情報を格納したシグナリングデータである。。
Ｓ−ＴＳＩＤは、各サービス単位の付加情報であり、ＵＳＤに記録されない付加的な情報が記録される。
前述したように、ＲＯＵＴＥプロトコルはＦＬＵＴＥをベースとするプロトコルである。ＦＬＵＴＥにおける転送制御パラメータを記述したメタデータファイルをＦＤＴ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｔａｂｌｅ）と呼び、ＲＯＵＴＥにおける転送制御パラメータを記述したメタデータファイルをＳ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ ｂａｓｅｄ Ｔｒａｎｓｐｏｒｔ Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）と呼ぶ。Ｓ−ＴＳＩＤはＦＤＴのスーパーセットでありＦＤＴを含む。
ＡＩＴは、１つまたは複数のアプリケーションに対応して設定されたアプリケーション固有のシグナリングデータであり、アプリケーションの取得用情報（ＵＲＬ）や、アプリ実行に適用される制御情報等が記録される。
これらシグナリングデータの構成と、これらのシグナリングイデータを利用したキャッシュ対象データの選択処理例について、図１２以下を参照して説明する。
図１２には、
（１）ＵＳＢＤ／ＵＳＤ
（２）ＡＩＴ
（３）Ｓ−ＴＳＩＤ
これらの一部データと、これらのデータを利用したアプリケーション取得処理について説明する図である。
なお、ＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ−ＴＳＩＤ等のシグナリングデータは、送信装置２０から随時、繰り返し送信されており、受信装置は、アプリケーションの取得に先立ち、これらのシグナリングデータを予め取得する。さらに、取得したシグナリングデータを参照してアプリケーションのアクセス情報を取得してアプリケーションを取得する。
アプリケーションは、放送波、または、インターネット等の通信ネットワークを介して取得することができる。
ＵＳＢＤには、
（ａ）放送波を介してアプリケーションが提供される場合のアプリケーション取得用のアクセス情報構成データである放送波対応ベースパターン、
（ｂ）通信ネットワークを介してアプリケーションが提供される場合のアプリケーション取得用のアクセス情報構成データである通信ネットワーク対応ベースパターン、これらのいずれかのベースパターンが記録される。
図１２に示すＵＳＢＤ／ＵＳＤには、アプリケーションが放送波を介して送信される場合、放送波に対応するベースパターン記録領域（ＵＳＤ／ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ／ａｔｓｃ：ＢｃＡｐｐＳｅｒｖｉｃｅ／ｂａｓｅＰａｔｔｅｒｎ）にベースパターンが記録される。
一方、アプリケーションが通信ネットワークを介して送信される場合、通信ネットワークに対応するベースパターン記録領域（ＵＳＤ／ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ／ａｔｓｃ：ＵｃＡｐｐＳｅｒｖｉｃｅ／ｂａｓｅＰａｔｔｅｒｎ）にベースパターンが記録される。
受信装置は、ＵＳＢＤまたはＵＳＤにどちらのベースパターンが記録されているかによって、アプリケーションが放送波を介して送信されるか、またはインターネット等の通信ネットワークを介して送信されるか、あるいは放送波とインターネット等の通信ネットワークの双方を介して送信されるかを判定することができる。
また、アプリケーション対応のシグナリングデータであるＡＩＴには、特定のアプリケーションを取得するためのＵＲＩが記録される。
受信装置は、アプリケーションの取得処理のために、まず、ステップＳ１１において、ＵＳＢＤ（またはＵＳＤ）に記録されたベースパターンを参照して、アプリケーションが放送波、通信ネットワークのどちらを利用して配信されているかを確認するとともに、ＡＩＴに記録されたＵＲＩと、ベースパターンとＵＲＩを組み合わせてアプリケーションのアクセス情報（アプリケーション取得用アドレス）を生成する。
具体的には、送信装置から送信されるシグナリングデータであるＵＳＤ（ユーザ・サービス・ディスクリプション）のデリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）と、ＡＩＴのアプリケーションロケーション（ＡｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の記述に基づいて、アプリケーションの伝送経路（放送波／ネット
通信）を確認し、その後、いずれかのベースパターンとＵＲＩを組み合わせてアプリケーションのアクセス情報（アプリケーション取得用アドレス）を生成する。
アプリケーションが通信ネットワークを介して配信されていると確認された場合、ステップＳ２１において、生成したアクセス情報（アプリケーション取得用アドレス）を適用して、通信ネットワークを介してアプリケーションを取得する。
一方、アプリケーションが放送波を介して配信されていると確認された場合、ステップＳ３１において、もう１つのシグナリングデータであるＳ−ＴＳＩＤを取得し、
ＡＩＴに記録されたアプリケーションロケーション（ａｐｐＬｏｃａｔｉｏｎ（ＵＲＩ）と一致するロケーション情報（ＲＳ／ＬＳ／ＳｃＦｌｗ／ＥＦＤＴ／＠ｃｏｎｔｅｎｔ−ｌｏｃ）を持つファイルのファイル単位情報を検索する。
Ｓ−ＴＳＩＤには、プレゼンテーション・ユニット（ＰＵ）を構成する各ファイル単位の情報が記録されている。
さらに、Ｓ−ＴＳＩＤのファイル単位情報に記録されたＴＯＩ（Ｔｒａｎｓｐｏｒｔ Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒ）を取得する。
ＴＯＩ（Ｔｒａｎｓｐｏｒｔ Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒ）は、送信装置２０から送信されるアプリケーションを格納したＬＣＴパケットのパケットヘッダに記録されるパケット識別子である。
ＬＣＴパケットのパケットヘッダにはパケットのペイロードに応じた識別子としてのＴＯＩが記録される。
受信装置は、ステップＳ３２において、Ｓ−ＴＳＩＤに記録されたＴＯＩに基づいて放送波によって送信されるＬＣＴパケットから目的のアプリケーションに含まれるファイルを格納したＬＣＴパケットを選択して取得する。
図１２（１）に示すように、ＵＳＢＤ／ＵＳＤには、放送波または通信ネットワーク対応のアプリケーションアクセス情報としてのベースパターンが記録される。
放送波を介したＮＲＴコンテンツとしてアプリケーションを送信することを示すＵＳＢＤ／ＵＳＤの記録データの具体例について図１３、図１４を参照して説明する。
図１３（１）は、放送波を介して送信されるＮＲＴサービスの１つとして放送波を介したＮＲＴアプリケーション送信サービスを定義した設定である。
図に示すように、ＵＳＢＤ／ＵＳＤ内のデリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）に新たに放送波を介したＮＲＴアプリケーション送信サービスの定義領域２３１を設定する。
この新たな定義領域に、１つ以上（１〜Ｎ）の放送によって配信するＮＲＴアプリケーションのベースパターンを記録する。
図１３（２）は、ＵＳＢＤ／ＵＳＤ内のデリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）内に定義されているアプリケーション送信サービス定義領域（ａｔｓｃ：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅ）内に新たに放送波を介したＮＲＴアプリケーション送信サービスのベースパターン定義領域２３２を設定した構成である。
図１４（３）は、ベースパターンそのものを記録するのではなく、サービスタイプ、すなわちサービス提供態様が、例えばライブ番組の配信等のサービスであるリニアタイプのサービスであるか、アプリケーション配信を含むノンリアルタイム（ＮＲＴ）コンテンツの配信サービスであるかを識別可能なフラグ（０，１）を記録する設定である。
ＵＳＢＤ／ＵＳＤ内のデリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）内に定義されているアプリケーション送信サービス定義領域（ａｔｓｃ：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅ）内に上記のフラグの記録領域２３３を設ける。
受信装置は、例えば、これら図１３、図１４に示す（１）〜（３）の記録データを参照することで、放送サービスによるアプリケーション配信が実行されているか否かを確認することができる。
一方、シグナリングデータとしてのＡＩＴ（アプリケーション・インフォメーション・テーブル）、およびＳ−ＴＳＩＤには、先に図１０、図１１を参照して説明したキャッシュ対象データの選択処理を行なうためのデータが記録される。
図１５、および図１６を参照して、ＡＩＴ、Ｓ−ＴＳＩＤの記録データの一例について説明する。
図１５は、ＡＩＴ（アプリケーション・インフォメーション・テーブル）の記録データの例を示す図である。
図１５に示すＡＩＴは、先に図９、図１０を参照して説明した３つのアプリケーション（ＡＰＰ１〜ＡＰＰ３）に対応する情報を記録したＡＩＴの一例である。
ＡＩＴは１つのアプリケーションのみの情報を記録した設定も可能であるが、複数の関連するアプリケーションの情報をまとめて記録した設定とすることもできる。
図１５に示すＡＩＴには、
アプリケーション１（ＡＰＰ１）に関する情報の記録領域２４１、
アプリケーション２（ＡＰＰ２）に関する情報の記録領域２４２、
アプリケーション３（ＡＰＰ３）に関する情報の記録領域２４３、
これらの情報記録領域が含まれる。
各アプリケーション情報記録領域２４１〜２４３の各々には、
アプリケーションＩＤ２５１、
アプリケーションアクセス情報（ａｐｐＬｏｃａｔｉｏｎ（ＵＲＩ））２５２、
アプリケーションサイズ２５３、
リンク先アプリケーション情報２５４、
これらの情報が記録される。
アプリケーションＩＤ２５１は、先に図８を参照して説明したアプリケーション識別子である。
すなわち、組織ＩＤ（ｏｒｇＩｄ）と、アプリ本体ＩＤ（ａｐｐＩｄ）から構成されるアプリケーションＩＤである。
アプリケーションアクセス情報（ａｐｐＬｏｃａｔｉｏｎ（ＵＲＩ））２５２は、アプリケーションを取得するために利用されるＵＲＩである。先に図１２を参照して説明したように、ＵＳＢＤに記録されたベースパターンと併せてアクセス情報が生成可能となる。
アプリケーションサイズ２５３は、１つのアプリケーションに含まれる全ての構成データの総データサイズである。
例えば、図９に示すアプリケーション１（ＡＰＰ１）の場合、３つのプレゼンテーション・ユニット（ＰＵ１１〜ＰＵ１３）を構成するファイルの総サイズが記録される。図１０に示す例では、アプリケーション１（ＡＰＰ１）のサイズはＳ１であり、このＳ１が、アプリケーションサイズ２５３として記録される。
リンク先アプリケーション情報２５４は、先に図９を参照して説明したアプリ間のリンクに関する情報である。具体的には、リンク先のアプリケーションのアプリケーションＩＤが記録される。
なお、リンク先のアプリケーションがない場合は、記録されない。
次に、図１６を参照して、Ｓ−ＴＳＩＤの記録データについて説明する。
前述したように、Ｓ−ＴＳＩＤは、サービス単位の転送制御パラメータを記述したメタデータファイルであり、サービスにおいて提供される多数のファイルのファイル単位の情報であるＦＤＴ（ファイル・デリバリ・テーブル）を含むシグナリングデータである。
図１６に示すＳ−ＴＳＩＤは、先に図９、図１０を参照して説明した３つのアプリケーション（ＡＰＰ１〜ＡＰＰ３）に対応する情報を記録したＳ−ＴＳＩＤの一部のみを示している。
なお、図１６には、アプリケーション１（ＡＰＰ１）に属する２つのブレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２）に対応する情報記録領域、すなわち、
プレゼンテーション・ユニット（ＰＵ１１）対応情報２６２、
プレゼンテーション・ユニット（ＰＵ１２）対応情報２６３、
これらの情報記録領域のみを抜き出して示している。
図１６に示すブレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２）に対応する情報記録領域以下に、ＰＵ１３，ＰＵ２１〜ＰＵ２３，ＰＵ３１〜ＰＵ３３の情報が記録される。
図１６に示すＳ−ＴＳＩＤには、以下の各情報が記録されている。
プレゼンテーション・ユニット（ＰＵ）間リンク情報２６１、
プレゼンテーション・ユニット（ＰＵ１１）対応情報２６２、
プレゼンテーション・ユニット（ＰＵ１２）対応情報２６３、
プレゼンテーション・ユニット（ＰＵ）間リンク情報２６１には、リンク元のプレゼンテーション・ユニット（ＰＵ）のＰＵＩＤと、リンク先のプレゼンテーション・ユニット（ＰＵ）のＰＵＩＤが記録される。
なお、ＰＵＩＤは、先に図８を参照して説明したように、プレゼンテーション・ユニット（ＰＵ）の属するアプリケーションのアプリ本体ＩＤ（ａｐｐＩｄ）と、同一アプリ内のプレゼンテーション・ユニットを個別に識別可能としたグループＩＤ（ｇｒｏｕｐＩｄ）によって構成される。
なお、ＰＵＩＤを構成するグループＩＤ（ｇｒｏｕｐＩｄ）は、１つのアプリケーションに含まれるブレゼンテーション・ユニット（ＰＵ）に対して、例えば１，２，３の連番が設定され、グループＩＤ（ｇｒｏｕｐＩｄ）＝１のＰＵがエントリ文書を持つＰＵとなる。
さらに、そのエントリ文書を持つ最初のファイル（Ｆｉｌｅ）がエントリ文書としてのＨＴＭＬ文書に相当するファイルである。
この最初のファイルのファイル単位情報に、プレゼンテーション・ユニット（ＰＵ１１）サイズ情報が記録される。
図１６に示すように、プレゼンテーション・ユニット（ＰＵ１１）対応情報２６２には、プレゼンテーション・ユニット（ＰＵ１１）に属するファイル単位の情報が記録される。
最初のファイル単位情報には、以下の各情報が記録されている。
ファイルアクセス情報としてのＴＯＩ情報、
プレゼンテーション・ユニット（ＰＵ１１）構成ファイルの所属グループ情報２７１、
プレゼンテーション・ユニット（ＰＵ１１）サイズ情報２７２、
２番目以降のファイル単位情報には、
ファイルアクセス情報としてのＴＯＩ情報、
プレゼンテーション・ユニット（ＰＵ１１）構成ファイルの所属グループ情報、
これらの情報が記録される。
また、プレゼンテーション・ユニット（ＰＵ１２）対応情報２６３には、プレゼンテーション・ユニット（ＰＵ１２）に属するファイル単位の情報が記録される。
最初のファイル単位情報には、以下の各情報が記録されている。
ファイルアクセス情報としてのＴＯＩ情報、
プレゼンテーション・ユニット（ＰＵ１２）構成ファイルの所属グループ情報２７３、
プレゼンテーション・ユニット（ＰＵ１２）サイズ情報２７４、
このように、Ｓ−ＴＳＩＤには、プレゼンテーション・ユニット（ＰＵ）を構成する各ファイル単位の次用法が記録され、このファイル単位情報内に、プレゼンテーション・ユニットのＩＤや、プレゼンテーション・ユニットのサイズ情報が記録される。
Ｓ−ＴＳＩＤのファイル単位のデータ記録領域であるＦＤＴ（ファイル・デリバリ・テーブル）のデータ記録例を図１７に示す。
図１７に示すように、ファイル単位のデータ記録領域であるＦＤＴ（ファイル・デリバリ・テーブル）には、以下の各情報が記録される。
（ａ）ファイルのアクセス情報としてのコンテンツロケーション（＠Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ）
（ｂ）送信装置から送信されるＬＣＴパケットのパケットヘッダに記録されるパケット識別子であるＴＯＩ（Ｔｒａｎｓｐｏｒｔ Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒ）
（ｃ）コンテンツのレングス、タイプ、
さらに、図に示すデータ記録領域２８１に、
（ｄ）プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）
（ｅ）プレゼンテーション・ユニット（ＰＵ）サイズ
これらの各データが記録される。
また、図１６を参照して説明したように、Ｓ−ＴＳＩＤには、プレゼンテーション・ユニット（ＰＵ）間リンク情報２６１が記録される。
この具体的記録例について、図１８を参照して説明する。
プレゼンテーション・ユニット（ＰＵ）間リンク情報２６１は、
Ｓ−ＴＳＩＤ内の以下の記録領域、すなわち、
ＲＳ／ＬＳ／ＳｃＦｌｗ／ＣｏｎｔｅｎｔＩｎｆｏ
以下に記録される。
図１８は、コンテンツ情報（ＣｏｎｔｅｎｔＩｎｆｏ）内に記録されるＰＵ間リンク情報の例を示す図である。
例えば、図１８のデータ記録領域２８２に示すような設定で、プレゼンテーション・ユニット（ＰＵ）間リンク情報が記録される。
リンク元のプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）
リンク先のプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）
データ記録領域２８２には、これらの２つのＰＵＩＤを記録する領域が設定される。
次に、図１９に示すフローチャートを参照して、受信装置においてシグナリングデータを参照して実行するアプリケーション取得処理と、キャッシュ対象データの選択処理シーケンスについて説明する。すなわち、
ＵＳＢＤ／ＵＳＤ
ＡＩＴ
Ｓ−ＴＳＩＳ
これらのシグナリンクデータを適用したアプリケーション取得処理と、キャッシュ対象データの選択処理である。
なお、図１９に示すフローに従った処理は、受信装置３０のデータ処理部において実行される処理である。例えば、図１９に示す処理シーケンスを記録したプログラムに従って実行される。なお、図１９に示す処理シーケンスを実行するデータ処理部は、例えば、図７に示す受信装置３０におけるシグナリング解析部１１３や、キャッシュ制御部等の機能を実行するデータ処理部である。
以下、各ステップの処理について、順次、説明する。
（ステップＳ５１）
受信装置は、ステップＳ５１において、送信装置から送信されるＳＬＳ（サービスレベルシグナリング）からＡＩＴ（アプリケーション・インフォメーション・テーブル）を取得して、配信アプリケーションに関する情報を取得する。
すなわち、図１５を参照して説明したＡＩＴ（アプリケーション・インフォメーション・テーブル）を取得して、配信アプリケーションに関する情報を取得する。
具体的には、例えば、アプリケーションＩＤ、アプリケーションサイズ情報、アプリケーション間リンク情報等を取得する。
（ステップＳ５２）
受信装置は、次に、ステップＳ５２において、送信装置から送信されるシグナリングデータであるＵＳＤ（ユーザ・サービス・ディスクリプション）のデリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）と、ＡＩＴのアプリケーションロケーション（ＡｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の記述の比較に基づいて、アプリケーションの伝送経路（放送波／ネット通信）を確認する。
（ステップＳ５３）
次に、受信装置は、ステップＳ５３において、送信装置から送信されるシグナリングデータであるＡＩＴから取得したアプリケーションサイズ情報と、アプリケーション間リンク情報と、受信装置のキャッシュ許容サイズに基づいて、キャッシュ可能なデータ範囲を決定する。
例えば、先に図１０〜図１８を参照して説明した処理に従って、キャッシュ可能なアプリケーション構成データ範囲を確認して、キャッシュ対象データを決定する。
（ステップＳ５４）
次に、受信装置は、ステップＳ５４において、１つのアプリケーション単位のキャッシュが可能か否かを判定する。
すなわち、図１０、図１１を参照して説明したキャッシュサイズが、中サイズ（Ｍｅｄｉｕｍ）〜最大サイズ（Ｍａｘｉｍｕｍ）に相当するか否かを判定する。
ステップＳ５４において、１つのアプリケーション単位のキャッシュが可能と判定した場合は、ステップＳ５５に進む。
一方、ステップＳ５４において、１つのアプリケーション単位のキャッシュが不可能と判定した場合は、ステップＳ５６に進む。
（ステップＳ５５）
ステップＳ５４において、１つのアプリケーション単位のキャッシュが可能と判定した場合は、受信装置は、ステップＳ５５において、ＡＩＴに記述されたアプリケーションサイズ情報と、アプリケーション間リンク情報と、受信装置のキャッシュ許容サイズに基づいて決定したキャッシュ可能な範囲のアプリケーションを取得して、キャッシュ処理を実行する。
この処理は、図１０、図１１を参照して説明したキャッシュサイズが、中サイズ（Ｍｅｄｉｕｍ）〜最大サイズ（Ｍａｘｉｍｕｍ）に相当する場合の処理に対応する。
（ステップＳ５６）
一方、ステップＳ５４において、１つのアプリケーション単位のキャッシュが不可能と判定した場合は、受信装置は、ステップＳ５６において、Ｓ−ＴＳＩＤのＥＦＤＴ／ＦＩＬＥ要素に記述されたプレゼンテーション・ユニット（ＰＵ）サイズと、受信装置のキャッシュ許容サイズに基づいて、決定したキャッシュ可能な範囲のプレゼンテーション・ユニットを取得して、キャッシュ処理を実行する。
この処理は、図１０、図１１を参照して説明したキャッシュサイズが、最小サイズ（Ｍｉｎｉｍｕｍ）〜小サイズ（Ｓｍａｌｌ）に相当する場合の処理に対応する。
［９．受信装置のキャッシュサイズ（データ格納許容サイズ）に応じた具体的な処理例について］
次に、図２０以下を参照して、受信装置のキャッシュサイズ（データ格納許容サイズ）に応じた具体的な処理例について説明する。
先に図１０、図１１を参照して説明した以下の５つのキャッシュサイズにおけるキャッシュ対象選択処理例について、順次、説明する。
（１）最小サイズ（Ｍｉｎｉｍｕｍ）
（２）小サイズ（Ｓｍａｌｌ）
（３）中サイズ（Ｍｅｄｉｕｍ）
（４）大サイズ（Ｌａｒｇｅ）
（５）最大サイズ（Ｍａｘｉｍｕｍ）
なお、アプリケーションサイズ、プレゼンテーション・ユニット（ＰＵ）サイズについても、図１０、図１１に示す設定であるものとして説明する。
すなわち、上記５つのキャッシュサイズに応じたキャッシュ対象データは、以下の設定となる。
（１）最小サイズ（Ｍｉｎｉｍｕｍ）＝プレゼンテーション・ユニット（ＰＵ１１）
（２）小サイズ（Ｓｍａｌｌ）＝プレゼンテーション・ユニット（ＰＵ１１）＋プレゼンテーション・ユニット（ＰＵ１２）
（３）中サイズ（Ｍｅｄｉｕｍ）＝アプリケーション（ＡＰＰ１）
（４）大サイズ（Ｌａｒｇｅ）＝アプリケーション（ＡＰＰ１）＋アプリケーション（ＡＰＰ２）
（５）最大サイズ（Ｍａｘｉｍｕｍ）＝アプリケーション（ＡＰＰ１）＋アプリケーション（ＡＰＰ２）＋アプリケーション（ＡＰＰ３）
以下、５つの異なるサイズのデータ格納許容キャッシュサイズを持つ受信装置における処理例について、順次、説明する。
なお、以下に説明する処理例は、アプリケーションが放送波を介して配信されている場合の処理例であり、受信装置は、放送波を介してアプリケーションを構成するファイルを取得する。
［９−１．受信装置のデータ格納許容キャッシュサイズが最小サイズ（Ｍｉｎｉｍｕｍ）であり、１つのプレゼンテーション・ユニット（ＰＵ）のみ格納可能である場合の処理例について］
まず、図２０以下を参照して、受信装置のデータ格納許容キャッシュサイズが最小サイズ（Ｍｉｎｉｍｕｍ）であり、１つのプレゼンテーション・ユニット（ＰＵ）のみ格納可能である場合の処理例について説明する。
図２０は、受信装置のデータ格納許容キャッシュサイズが最小サイズ（Ｍｉｎｉｍｕｍ）である場合の、キャッシュ（格納）対象データを説明する図である。
受信装置は、１つのプレゼンテーション・ユニット（ＰＵ）のみ格納可能である。
受信装置の実行する処理は、アプリケーション（ＡＰＰ１）の起動後に最初に読み込まれるＨＴＭＬ文書（エントリ文書２２１）とリソースファイルで構成されるプレゼンテーション・ユニット（ＰＵ１１）を取得し、キャッシュして表示する処理となる。
図２１には、受信装置が放送波を介してアプリケーションを取得し、キャッシュ処理を行ない、実行するまでの処理シーケンスを説明するフローチャートを示している。
さらに、図２２には、図２１に示すフローチャートの各ステップの処理に際して利用されるシグナリングデータを示している。
（１）ＡＩＴ
（２）Ｓ−ＴＳＩＤ
これら２つのシグナリングデータである。
図２１に示す各ステップ番号（Ｓ１１１〜Ｓ１１６）の処理と、図２２に示す同じステップ番号（Ｓ１１１〜Ｓ１１６）の処理は同一の処理である。図２２においては、各ステップの処理に際して参照するシグナリングデータ（ＡＩＴ，Ｓ−ＴＳＩＤ）の記録領域と各ステップ番号とを対応付けて示している。
図２１、および図２２を参照して各ステップの処理について、順次、説明する。
（ステップＳ１１１）
受信装置は、まず、ステップＳ１１１において、送信装置から送信されるＳＬＳ（サービスレベルシグナリング）からＡＩＴ（アプリケーション・インフォメーション・テーブル）、Ｓ−ＴＳＩＤを取得する。
（ステップＳ１１２）
次に、受信装置は、ステップＳ１１２において、ＡＩＴから、配信アプリケーションに関する情報の取得、確認を行う。例えば、以下の処理を行なう。
（１）アプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）から、エントリ文書のＵＲＬを取得する。
（２）コントロールコードがキャッシュ処理の必要なコード（ＡＵＴＯＳＴＡＲＴ，Ｐｒｅｆｅｔｃｈなど）に設定されていることを確認する。
（３）アプリケーションＩＤを取得する。
（４）アプリケーションサイズを取得する。
さらに、取得したアプリケーションサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
本例では、キャッシュサイズ＝最小（Ｍｉｎｉｍｕｍ）であり、アプリケーションサイズより小さく、アプリケーション全体のキャッシュ処理はできないと判断する。
（ステップＳ１１３）
次に、受信装置は、ステップＳ１１３において、Ｓ−ＴＳＩＤから、エントリ文書の取得先情報を取得する。
具体的には、図２２のステップＳ１１３に示すように、Ｓ−ＴＳＩＤに記録されたファイル単位の情報に記録されたコンテンツロケーション情報（ＲＳ／ＬＳ／ＳｃＦｌｗ／ＥＦＤＴ／ｃｏｎｔｅｎｔ−ｌｏｃａｔｉｏｎ）と、ＡＩＴのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報を取得する。
前述したように、Ｓ−ＴＳＩＤには、プレゼンテーション・ユニット（ＰＵ）を構成するファイル単位の情報が記録されている。
受信装置は、ＡＩＴのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報として、Ｓ−ＴＳＩＤのファイル単位情報に記録されたＴＯＩ（Ｔｒａｎｓｐｏｒｔ Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒ）を取得する。
ＴＯＩ（Ｔｒａｎｓｐｏｒｔ Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒ）は、送信装置２０から送信されるアプリケーションを格納したＬＣＴパケットのパケットヘッダに記録されるパケット識別子である。
ＬＣＴパケットのパケットヘッダにはパケットのペイロードに応じた識別子としてのＴＯＩが記録される。
受信装置は、Ｓ−ＴＳＩＤに記録されたＴＯＩに基づいて放送波によって送信されるＬＣＴパケットから目的のアプリケーションに含まれるファイルを格納したＬＣＴパケットを選択して取得することができる。
（ステップＳ１１４）
次に、受信装置は、ステップＳ１１４において、Ｓ−ＴＳＩＤから、エントリ文書を含むプレゼンテーション・ユニット（ＰＵ）と、Ｓ−ＴＳＩＤに記録されたリンク情報を辿って得られるプレゼンテーション・ユニット（ＰＵ）のＩＤ（ＰＵＩＤ＝アプリ本体ＩＤ＋グループＩＤ）、さらに、各プレゼンテーション・ユニット（ＰＵ）のサイズ情報（ＰＵＳｉｚｅ）を取得する。
図２２のステップＳ１１４ａに示すように、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）は、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）から構成されている。
アプリ本体ＩＤ（ａｐｐＩｄ）は、ファイルの属するプレゼンテーション・ユニット（ＰＵ）が属するアプリケーションに設定されたアプリケーションＩＤ（組織ＩＤ（ｏｒｇＩｄ）＋アプリ本体ＩＤ（ａｐｐＩｄ））の構成データであるアプリ本体ＩＤ（ａｐｐＩｄ）と同じ値である。
また、図２２のステップＳ１１４ｂに示すように、受信装置は、Ｓ−ＴＳＩＤに記録されたリンク情報を取得する。
受信装置は、このリンク情報を辿って得られるプレゼンテーション・ユニット（ＰＵ）のＩＤ（ＰＵＩＤ＝アプリ本体ＩＤ＋グループＩＤ）、さらに、各プレゼンテーション・ユニット（ＰＵ）のサイズ情報（ＰＵＳｉｚｅ）を取得する。
（ステップＳ１１５）
次に、受信装置は、ステップＳ１１５において、受信装置のキャッシュサイズ、すなわち利用可能なキャッシュサイズと、各プレゼンテーション・ユニット（ＰＵ）のデータサイズを比較して、キャッシュ対象とするプレゼンテーション・ユニットを選択する。
なお、最優先キャッシュ対象ＰＵは、エントリ文書を有するプレゼンテーション・ユニット（例えば、ＰＵ１１）である。
その次の優先キャッシュ対象ＰＵは、エントリ文書を有するＰＵ１１のリンク先ＰＵ、例えばＰＵ１２となる。
さらに、ＰＵ１２のリンク先ＰＵ１３が次のキャッシュ対象ＰＵとして選択され、リンクを辿って、順次、キャッシュ対象ＰＵが選択される。
キャッシュサイズを超えた時点で、キャッシュ対象ＰＵの選択が完了する。
具体的には、例えば、
ＰＵ１１サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２）サイズ
の場合は、ＰＵ１１のみをキャッシュ対象ＰＵとして選択する。
また、（ＰＵ１１＋ＰＵ１２）サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２＋ＰＵ１３）サイズ
の場合は、ＰＵ１１とＰＵ１２をキャッシュ対象ＰＵとして選択する。
このように、ＰＵの総計サイズが、キャッシュサイズに達するまでの範囲内で、キャッシュ対象ＰＵを、リンクを辿って順次、選択する。
本例の場合は、
ＰＵ１１サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２）サイズ
上記式が満足され、ＰＵ１１のみをキャッシュ対象ＰＵとして選択する。
（ステップＳ１１６）
次に、受信装置は、ステップＳ１１６において、ステップＳ１１５で決定したキャッシュ対象のプレゼンテーション・ユニット（ＰＵ）のＰＵＩＤと同じＰＵＩＤを持つファイルを取得して、キャッシュ処理を実行して、エントリ文書を出力（表示）する。
図２２のステップＳ１１６に示すように、Ｓ−ＴＳＩＤに記録されたファイル単位の情報から、キャッシュ対象として選択したプレゼンテーション・ユニット（ＰＵ）のＰＵＩＤ（ＰＵ１１）と同じＰＵＩＤ（ＰＵ１１）を持つファイルを選択して、これらのファイル単位情報に記録されたＴＯＩに基づいて放送波から該当ファイルを格納したパケットを選択取得する。選択取得したファイルをキャッシュ部に格納（キャッシュ）する処理を実行して、その後、エントリ文書からの出力（表示）処理を開始する。
これらの処理によって、アプリケーション（ＡＰＰ１）の１つのプレゼンテーション・ユニット（ＰＵ１１）に属する全てのファイルを取得することができる。
従って、１つのプレゼンテーション・ユニット（ＰＵ）の全構成ファイルを利用したアプリケーションの実行が可能となり、プレゼンテーション・ユニット単位の完全な形態でのデータ再生が可能となる。
すなわち、より完成度の高いアプリケーション実行処理が実現される。
［９−２．受信装置のデータ格納許容キャッシュサイズが小サイズ（Ｓｍａｌｌ）であり、複数のプレゼンテーション・ユニット（ＰＵ）が格納可能である場合の処理例について］
次に、図２３以下を参照して、受信装置のデータ格納許容キャッシュサイズが小サイズ（Ｓｍａｌｌ）であり、複数のプレゼンテーション・ユニット（ＰＵ）が格納可能である場合の処理例について説明する。
図２３は、受信装置のデータ格納許容キャッシュサイズが小サイズ（Ｓｍａｌｌ）である場合の、キャッシュ（格納）対象データを説明する図である。
受信装置は、２つのプレゼンテーション・ユニット（ＰＵ１１とＰＵ１２）を格納可能である。
受信装置の実行する処理は、アプリケーション（ＡＰＰ１）の起動後に最初に読み込まれるＨＴＭＬ文書（エントリ文書２２１）とリソースファイルで構成されるプレゼンテーション・ユニット（ＰＵ１１）、さらに、プレゼンテーション・ユニット（ＰＵ１１）のリンク先として設定されているプレゼンテーション・ユニット（ＰＵ１２）を取得し、キャッシュして表示する処理となる。
なお、プレゼンテーション・ユニット（ＰＵ１１）のリンク先として設定されているプレゼンテーション・ユニットが複数ある場合は、それらの複数のリンク先ＰＵを取得する。
図２４には、受信装置が放送波を介してアプリケーションを取得し、キャッシュ処理を行ない、実行するまでの処理シーケンスを説明するフローチャートを示している。
さらに、図２５には、図２４に示すフローチャートの各ステップの処理に際して利用されるシグナリングデータを示している。
（１）ＡＩＴ
（２）Ｓ−ＴＳＩＤ
これら２つのシグナリングデータである。
図２４に示す各ステップ番号（Ｓ１２１〜Ｓ１２６）の処理と、図２５に示す同じステップ番号（Ｓ１２１〜Ｓ１２６）の処理は同一の処理である。図２５においては、各ステップの処理に際して参照するシグナリングデータ（ＡＩＴ，Ｓ−ＴＳＩＤ）の記録領域と各ステップ番号とを対応付けて示している。
図２４、および図２５を参照して各ステップの処理について、順次、説明する。
（ステップＳ１２１）
受信装置は、まず、ステップＳ１２１において、送信装置から送信されるＳＬＳ（サービスレベルシグナリング）からＡＩＴ（アプリケーション・インフォメーション・テーブル）、Ｓ−ＴＳＩＤを取得する。
（ステップＳ１２２）
次に、受信装置は、ステップＳ１２２において、ＡＩＴから、配信アプリケーションに関する情報の取得、確認を行う。例えば、以下の処理を行なう。
（１）アプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）から、エントリ文書のＵＲＬを取得する。
（２）コントロールコードがキャッシュ処理の必要なコード（ＡＵＴＯＳＴＡＲＴ，Ｐｒｅｆｅｔｃｈなど）に設定されていることを確認する。
（３）アプリケーションＩＤを取得する。
（４）アプリケーションサイズを取得する。
さらに、取得したアプリケーションサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
本例では、キャッシュサイズ＝小（Ｓｍａｌｌ）であり、アプリケーションサイズより小さく、アプリケーション全体のキャッシュ処理はできないと判断する。
（ステップＳ１２３）
次に、受信装置は、ステップＳ１２３において、Ｓ−ＴＳＩＤから、エントリ文書の取得先情報を取得する。
具体的には、図２５のステップＳ１２３に示すように、Ｓ−ＴＳＩＤに記録されたファイル単位の情報に記録されたコンテンツロケーション情報（ＲＳ／ＬＳ／ＳｃＦｌｗ／ＥＦＤＴ／ｃｏｎｔｅｎｔ−ｌｏｃａｔｉｏｎ）と、ＡＩＴのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報を取得する。
（ステップＳ１２４）
次に、受信装置は、ステップＳ１２４において、Ｓ−ＴＳＩＤから、エントリ文書を含むプレゼンテーション・ユニット（ＰＵ）と、Ｓ−ＴＳＩＤに記録されたリンク情報を辿って得られるプレゼンテーション・ユニット（ＰＵ）のＩＤ（ＰＵＩＤ＝アプリ本体ＩＤ＋グループＩＤ）、さらに、各プレゼンテーション・ユニット（ＰＵ）のサイズ情報（ＰＵＳｉｚｅ）を取得する。
図２５のステップＳ１２４ａに示すように、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）は、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）から構成されている。
アプリ本体ＩＤ（ａｐｐＩｄ）は、ファイルの属するプレゼンテーション・ユニット（ＰＵ）が属するアプリケーションに設定されたアプリケーションＩＤ（組織ＩＤ（ｏｒｇＩｄ）＋アプリ本体ＩＤ（ａｐｐＩｄ））の構成データであるアプリ本体ＩＤ（ａｐｐＩｄ）と同じ値である。
また、図２５のステップＳ１２４ｂに示すように、受信装置は、Ｓ−ＴＳＩＤに記録されたリンク情報を取得する。
図２５のステップＳ１２４ｃに示すように、受信装置は、このリンク情報を辿って得られるプレゼンテーション・ユニット（ＰＵ）のＩＤ（ＰＵＩＤ＝アプリ本体ＩＤ＋グループＩＤ）、さらに、各プレゼンテーション・ユニット（ＰＵ）のサイズ情報（ＰＵＳｉｚｅ）を取得する。
（ステップＳ１２５）
次に、受信装置は、ステップＳ１２５において、受信装置のキャッシュサイズ、すなわち利用可能なキャッシュサイズと、各プレゼンテーション・ユニット（ＰＵ）のデータサイズを比較して、キャッシュ対象とするプレゼンテーション・ユニットを選択する。
なお、最優先キャッシュ対象ＰＵは、エントリ文書を有するプレゼンテーション・ユニット（例えば、ＰＵ１１）である。
その次の優先キャッシュ対象ＰＵは、エントリ文書を有するＰＵ１１のリンク先ＰＵ、例えばＰＵ１２となる。
さらに、ＰＵ１２のリンク先ＰＵ１３が次のキャッシュ対象ＰＵとして選択され、リンクを辿って、順次、キャッシュ対象ＰＵが選択される。
キャッシュサイズを超えた時点で、キャッシュ対象ＰＵの選択が完了する。
具体的には、例えば、
ＰＵ１１サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２）サイズ
の場合は、ＰＵ１１のみをキャッシュ対象ＰＵとして選択する。
また、（ＰＵ１１＋ＰＵ１２）サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２＋ＰＵ１３）サイズ
の場合は、ＰＵ１１とＰＵ１２をキャッシュ対象ＰＵとして選択する。
このように、ＰＵの総計サイズが、キャッシュサイズに達するまでの範囲内で、キャッシュ対象ＰＵを、リンクを辿って順次、選択する。
本例の場合は、
（ＰＵ１１＋ＰＵ１２）サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２＋ＰＵ１３）サイズ
が満足され、ＰＵ１１とＰＵ１２をキャッシュ対象ＰＵとして選択する。
（ステップＳ１２６）
次に、受信装置は、ステップＳ１２６において、ステップＳ１２５で決定したキャッシュ対象のプレゼンテーション・ユニット（ＰＵ）のＰＵＩＤと同じＰＵＩＤを持つファイルを取得して、キャッシュ処理を実行して、エントリ文書を出力（表示）する。
図２５のステップＳ１２６ａ，ｂに示すように、受信装置は、Ｓ−ＴＳＩＤに記録されたファイル単位の情報から、キャッシュ対象ＰＵのＰＵＩＤと同じＰＵＩＤを持つファイルを選択して、これらのファイル単位情報に記録されたＴＯＩに基づいて放送波から該当ファイルを格納したパケットを選択取得する。選択取得したファイルをキャッシュ部に格納（キャッシュ）する処理を実行して、その後、エントリ文書からの出力（表示）処理を開始する。
これらの処理によって、アプリケーション（ＡＰＰ１）の２つのプレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２）に属する全てのファイルを取得することができる。
従って、２つのプレゼンテーション・ユニット（ＰＵ）の全構成ファイルを利用したアプリケーションの実行が可能となり、プレゼンテーション・ユニット単位の完全な形態でのデータ再生が可能となる。
すなわち、より完成度の高いアプリケーション実行処理が実現される。
［９−３．受信装置のデータ格納許容キャッシュサイズが中サイズ（Ｍｅｄｉｕｍ）であり、１つのアプリケーションが格納可能である場合の処理例について］
次に、図２６以下を参照して、受信装置のデータ格納許容キャッシュサイズが中サイズ（Ｍｅｄｉｕｍ）であり、１つのアプリケーション（Ａｐｐ１）が格納可能である場合の処理例について説明する。
図２６は、受信装置のデータ格納許容キャッシュサイズが中サイズ（Ｍｅｄｉｕｍ）である場合の、キャッシュ（格納）対象データを説明する図である。
受信装置は、１つのアプリケーション（ＡＰＰ１）を格納可能である。
受信装置の実行する処理は、アプリケーション（ＡＰＰ１）の起動後に最初に読み込まれるＨＴＭＬ文書（エントリ文書２２１）とリソースファイルで構成されるプレゼンテーション・ユニット（ＰＵ１１）の属するアプリケーション（ＡＰＰ１）の構成ファイル全てを取得し、キャッシュして表示する処理となる。
図２７には、受信装置が放送波を介してアプリケーションを取得し、キャッシュ処理を行ない、実行するまでの処理シーケンスを説明するフローチャートを示している。
さらに、図２８には、図２７に示すフローチャートの各ステップの処理に際して利用されるシグナリングデータを示している。
（１）ＡＩＴ
（２）Ｓ−ＴＳＩＤ
これら２つのシグナリングデータである。
図２７に示す各ステップ番号（Ｓ１３１〜Ｓ１３５）の処理と、図２８に示す同じステップ番号（Ｓ１３１〜Ｓ１３５）の処理は同一の処理である。図２８においては、各ステップの処理に際して参照するシグナリングデータ（ＡＩＴ，Ｓ−ＴＳＩＤ）の記録領域と各ステップ番号とを対応付けて示している。
図２７、および図２８を参照して各ステップの処理について、順次、説明する。
（ステップＳ１３１）
受信装置は、まず、ステップＳ１３１において、送信装置から送信されるＳＬＳ（サービスレベルシグナリング）からＡＩＴ（アプリケーション・インフォメーション・テーブル）、Ｓ−ＴＳＩＤを取得する。
（ステップＳ１３２）
次に、受信装置は、ステップＳ１３２において、ＡＩＴから、配信アプリケーションに関する情報の取得、確認を行う。例えば、以下の処理を行なう。
（１）アプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）から、エントリ文書のＵＲＬを取得する。
（２）コントロールコードがキャッシュ処理の必要なコード（ＡＵＴＯＳＴＡＲＴ，Ｐｒｅｆｅｔｃｈなど）に設定されていることを確認する。
（３）アプリケーションＩＤを取得する。
（４）アプリケーションサイズを取得する。
（５）リンク先アプリケーションを取得する。
（６）リンク先アプリケーションサイズを取得する。
さらに、取得したアプリケーションサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
本例では、キャッシュサイズ＝中（Ｍｅｄｉｕｍ）であり、アプリケーション（ＡＰＰ１）のアプリケーションサイズより大きく、アプリケーション（ＡＰＰ１）全体のキャッシュ処理ができると判断する。
さらに、アプリケーションサイズにリンク先アプリケーションサイズを加算したデータサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
本例では、キャッシュサイズ＝中（Ｍｅｄｉｕｍ）であり、このキャッシュサイズは、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）のアプリケーション合計サイズより小さく、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）全体のキャッシュ処理はできないと判断する。
すなわち、１つのアプリケーション（ＡＰＰ１）のキャッシュ処理を実行することに決定する。
（ステップＳ１３３）
次に、受信装置は、ステップＳ１３３において、Ｓ−ＴＳＩＤから、エントリ文書の取得先情報を取得する。
具体的には、図２８のステップＳ１３３に示すように、Ｓ−ＴＳＩＤに記録されたファイル単位の情報に記録されたコンテンツロケーション情報（ＲＳ／ＬＳ／ＳｃＦｌｗ／ＥＦＤＴ／ｃｏｎｔｅｎｔ−ｌｏｃａｔｉｏｎ）と、ＡＩＴのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報を取得する。
（ステップＳ１３４）
次に、受信装置は、ステップＳ１３４において、エントリ文書のグループ（Ｇｒｏｕｐ）要素に記述されたプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）から、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）を取得する。
図２８のステップＳ１３４に示すように、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）は、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）から構成されている。
アプリ本体ＩＤ（ａｐｐＩｄ）は、ファイルの属するプレゼンテーション・ユニット（ＰＵ）が属するアプリケーションに設定されたアプリケーションＩＤ（組織ＩＤ（ｏｒｇＩｄ）＋アプリ本体ＩＤ（ａｐｐＩｄ））の構成データであるアプリ本体ＩＤ（ａｐｐＩｄ）と同じ値である。
（ステップＳ１３５）
次に、受信装置は、ステップＳ１３５において、エントリ文書のＰＵＩＤ（アプリ本体ＩＤ（ａｐｐＩｄ）＋グループＩＤ（ｇｒｏｕｐＩｄ））中のアプリ本体ＩＤ（ａｐｐＩｄ）と同じアプリ本体ＩＤ（ａｐｐＩｄ）を持つファイルを取得して、キャッシュ処理を実行して、出力（表示）する。
図２８のステップＳ１３５に示すように、Ｓ−ＴＳＩＤに記録されたファイル単位の情報から、エントリ文書のＰＵＩＤを構成するアプリ本体ＩＤ（ａｐｐＩｄ）と同じアプリ本体ＩＤ（ａｐｐＩｄ）を持つファイルを取得して、キャッシュ処理を実行して、出力（表示）する。
これらの処理によって、アプリケーション（ＡＰＰ１）に属する全てのプレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２，ＰＵ１３）に属する全てのファイルを取得することができる。
従って、アプリケーション（ＡＰＰ１）に属する全てのプレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２，ＰＵ１３）の全構成ファイルを利用したアプリケーションの実行が可能となり、アプリケーション単位、およびプレゼンテーション・ユニット単位の完全な形態でのデータ再生が可能となる。
すなわち、より完成度の高いアプリケーション実行処理が実現される。
［９−４．受信装置のデータ格納許容キャッシュサイズが大サイズ（Ｌａｒｇｅ）であり、複数のアプリケーションが格納可能である場合の処理例について］
次に、図２９以下を参照して、受信装置のデータ格納許容キャッシュサイズが大サイズ（Ｌａｒｇｅ）であり、複数のアプリケーション（ＡＰＰ１，ＡＰＰ２）が格納可能である場合の処理例について説明する。
図２９は、受信装置のデータ格納許容キャッシュサイズが大サイズ（Ｌａｒｇｅ）である場合の、キャッシュ（格納）対象データを説明する図である。
受信装置は、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）を格納可能である。
受信装置の実行する処理は、アプリケーション（ＡＰＰ１）の起動後に最初に読み込まれるＨＴＭＬ文書（エントリ文書２２１）とリソースファイルで構成されるプレゼンテーション・ユニット（ＰＵ１１）の属するアプリケーション（ＡＰＰ１）の構成ファイル、さらに、アプリケーション（ＡＰＰ１）のリンク先アプリケーションであるアプリケーション（ＡＰＰ２）の構成ファイル全てを取得し、キャッシュして表示する処理となる。
図３０には、受信装置が放送波を介してアプリケーションを取得し、キャッシュ処理を行ない、実行するまでの処理シーケンスを説明するフローチャートを示している。
さらに、図３１には、図３０に示すフローチャートの各ステップの処理に際して利用されるシグナリングデータを示している。
（１）ＡＩＴ
（２）Ｓ−ＴＳＩＤ
これら２つのシグナリングデータである。
図３０に示す各ステップ番号（Ｓ１４１〜Ｓ１４５）の処理と、図３１に示す同じステップ番号（Ｓ１４１〜Ｓ１４５）の処理は同一の処理である。図３１においては、各ステップの処理に際して参照するシグナリングデータ（ＡＩＴ，Ｓ−ＴＳＩＤ）の記録領域と各ステップ番号とを対応付けて示している。
図３０、および図３１を参照して各ステップの処理について、順次、説明する。
（ステップＳ１４１）
受信装置は、まず、ステップＳ１４１において、送信装置から送信されるＳＬＳ（サービスレベルシグナリング）からＡＩＴ（アプリケーション・インフォメーション・テーブル）、Ｓ−ＴＳＩＤを取得する。
（ステップＳ１４２）
次に、受信装置は、ステップＳ１４２において、ＡＩＴから、配信アプリケーションに関する情報の取得、確認を行う。例えば、以下の処理を行なう。
（１）アプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）から、エントリ文書のＵＲＬを取得する。
（２）コントロールコードがキャッシュ処理の必要なコード（ＡＵＴＯＳＴＡＲＴ，Ｐｒｅｆｅｔｃｈなど）に設定されていることを確認する。
（３）アプリケーションＩＤを取得する。
（４）アプリケーションサイズを取得する。
（５）リンク先アプリケーションを取得する。
（６）リンク先アプリケーションサイズを取得する。
さらに、取得したアプリケーションサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
本例では、キャッシュサイズ＝大（Ｌａｒｇｅ）であり、アプリケーション（ＡＰＰ１）のアプリケーションサイズより大きく、アプリケーション（ＡＰＰ１）全体のキャッシュ処理ができると判断する。
さらに、アプリケーションサイズにリンク先アプリケーションサイズを加算したデータサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
本例では、キャッシュサイズ＝大（Ｌａｒｇｅ）であり、このキャッシュサイズは、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）のアプリケーション合計サイズより大きく、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）全体のキャッシュ処理ができると判断する。
さらに、リンク先アプリケーション（ＡＰＰ２）のリンク先アプリケーション（ＡＰＰ３）のサイズを取得して、３つのアプリの総計データサイズと、キャッシュサイズと比較する。
本例では、キャッシュサイズは３つのアプリケーションの総計データサイズより小さく、３つのアプリケーション全ての格納（キャッシュ）はできないと判断する。
結果として、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）のキャッシュ処理を実行することに決定する。
（ステップＳ１４３）
次に、受信装置は、ステップＳ１４３において、Ｓ−ＴＳＩＤから、初期実行アプリ（ＡＰＰ１）のエントリ文書の取得先情報を取得する。
具体的には、図３１のステップＳ１４３に示すように、Ｓ−ＴＳＩＤに記録されたファイル単位の情報に記録されたコンテンツロケーション情報（ＲＳ／ＬＳ／ＳｃＦｌｗ／ＥＦＤＴ／ｃｏｎｔｅｎｔ−ｌｏｃａｔｉｏｎ）と、ＡＩＴのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報を取得する。
なお、本例では、ＡＩＴに記録された２つのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報を取得する。
（ステップＳ１４４）
次に、受信装置は、ステップＳ１４４において、２つのアプリケーション各々のエントリ文書のグループ（Ｇｒｏｕｐ）要素に記述されたプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）から、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）を取得する。
図３１のステップＳ１４４に示すように、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）は、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）から構成されている。
アプリ本体ＩＤ（ａｐｐＩｄ）は、ファイルの属するプレゼンテーション・ユニット（ＰＵ）が属するアプリケーションに設定されたアプリケーションＩＤ（組織ＩＤ（ｏｒｇＩｄ）＋アプリ本体ＩＤ（ａｐｐＩｄ））の構成データであるアプリ本体ＩＤ（ａｐｐＩｄ）と同じ値である。
本例では、図３１のステップＳ１４４ａ，Ｓ１４４ｂに示すように、リンク元とリンク先の２つのアプリケーションＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２）を取得する。
（ステップＳ１４５）
次に、受信装置は、ステップＳ１４５において、エントリ文書のＰＵＩＤ（アプリ本体ＩＤ（ａｐｐＩｄ）＋グループＩＤ（ｇｒｏｕｐＩｄ））中のアプリ本体ＩＤ（ａｐｐＩｄ）と同じアプリ本体ＩＤ（ａｐｐＩｄ）を持つファイルを取得して、キャッシュ処理を実行する。
本例では、２つのアプリケーションＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２）を持つファイルを取得して、キャッシュ処理を実行し、アプリケーション１（ＡＰＰ１）のエントリ文書を用いてアプリケーションの実行を開始する。
図３１のステップＳ１４５に示すように、Ｓ−ＴＳＩＤに記録されたファイル単位の情報から、エントリ文書のＰＵＩＤ（ＰＵＩｄ１１，ＰＵＩｄ２１）を構成するアプリ本体ＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２）と同じアプリ本体ＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２）を持つファイルを取得して、キャッシュ処理を実行して、出力（表示）する。
これらの処理によって、アプリケーション（ＡＰＰ１）と、リンク先のアプリケーション（ＡＰＰ２）に属する全てのプレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２，ＰＵ１３、ＰＵ２１，ＰＵ２２，ＰＵ２３）に属する全てのファイルを取得することができる。
これにより、アプリケーション（ＡＰＰ１）に属する全てのプレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２，ＰＵ１３）の全構成ファイルを利用したアプリケーションの実行、さらに、アプリケーション（ＡＰＰ２）に属する全てのプレゼンテーション・ユニット（ＰＵ２１，ＰＵ２２，ＰＵ２３）の全構成ファイルを利用したアプリケーションの実行が可能となる。
すなわち、アプリケーション単位、およびプレゼンテーション・ユニット単位の完全な形態でのデータ再生が可能となる。
すなわち、より完成度の高いアプリケーション実行処理が実現される。
［９−５．受信装置のデータ格納許容キャッシュサイズが最大サイズ（Ｍａｘｉｍｕｍ）であり、複数のアプリケーションが格納可能である場合の処理例について］
次に、図３２以下を参照して、受信装置のデータ格納許容キャッシュサイズが最大サイズ（Ｍａｘｉｍｕｍ）であり、リンク関係の設定された３つ全てのアプリケーション（ＡＰＰ１，ＡＰＰ２，ＡＰＰ３）が格納可能である場合の処理例について説明する。
図３２は、受信装置のデータ格納許容キャッシュサイズが最大サイズ（Ｍａｘｉｍｕｍ）である場合の、キャッシュ（格納）対象データを説明する図である。
受信装置は、リンク関係の設定された３つ全てのアプリケーション（ＡＰＰ１，ＡＰＰ２，ＡＰＰ３）を格納可能である。
受信装置の実行する処理は、アプリケーション（ＡＰＰ１）の起動後に最初に読み込まれるＨＴＭＬ文書（エントリ文書２２１）とリソースファイルで構成されるプレゼンテーション・ユニット（ＰＵ１１）の属するアプリケーション（ＡＰＰ１）の構成ファイル、さらに、アプリケーション（ＡＰＰ１）のリンク先アプリケーションであるアプリケーション（ＡＰＰ２）、さらに、アプリケーション（ＡＰＰ２）のリンク先アプリケーションであるアプリケーション（ＡＰＰ３）の構成ファイル全てを取得し、キャッシュして表示する処理となる。
図３３には、受信装置が放送波を介してアプリケーションを取得し、キャッシュ処理を行ない、実行するまでの処理シーケンスを説明するフローチャートを示している。
さらに、図３４には、図３３に示すフローチャートの各ステップの処理に際して利用されるシグナリングデータを示している。
（１）ＡＩＴ
（２）Ｓ−ＴＳＩＤ
これら２つのシグナリングデータである。
図３３に示す各ステップ番号（Ｓ１５１〜Ｓ１５５）の処理と、図３４に示す同じステップ番号（Ｓ１５１〜Ｓ１５５）の処理は同一の処理である。図３４においては、各ステップの処理に際して参照するシグナリングデータ（ＡＩＴ，Ｓ−ＴＳＩＤ）の記録領域と各ステップ番号とを対応付けて示している。
図３３、および図３４を参照して各ステップの処理について、順次、説明する。
（ステップＳ１５１）
受信装置は、まず、ステップＳ１５１において、送信装置から送信されるＳＬＳ（サービスレベルシグナリング）からＡＩＴ（アプリケーション・インフォメーション・テーブル）、Ｓ−ＴＳＩＤを取得する。
（ステップＳ１５２）
次に、受信装置は、ステップＳ１５２において、ＡＩＴから、配信アプリケーションに関する情報の取得、確認を行う。例えば、以下の処理を行なう。
（１）アプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）から、エントリ文書のＵＲＬを取得する。
（２）コントロールコードがキャッシュ処理の必要なコード（ＡＵＴＯＳＴＡＲＴ，Ｐｒｅｆｅｔｃｈなど）に設定されていることを確認する。
（３）アプリケーションＩＤを取得する。
（４）アプリケーションサイズを取得する。
（５）リンク先アプリケーションを取得する。
（６）リンク先アプリケーションサイズを取得する。
さらに、取得したアプリケーションサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
本例では、キャッシュサイズ＝最大（Ｍａｘｉｍｕｍ）であり、アプリケーション（ＡＰＰ１）のアプリケーションサイズより大きく、アプリケーション（ＡＰＰ１）全体のキャッシュ処理ができると判断する。
さらに、アプリケーションサイズにリンク先アプリケーション（ＡＰＰ２）のサイズを加算したデータサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
本例では、キャッシュサイズ＝最大（Ｍａｘｉｍｕｍ）であり、このキャッシュサイズは、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）のアプリケーション合計サイズより大きく、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）全体のキャッシュ処理ができると判断する。
さらに、リンク先アプリケーション（ＡＰＰ２）のリンク先アプリケーション（ＡＰＰ３）のサイズを取得して、３つのアプリの総計データサイズと、キャッシュサイズと比較する。
本例では、キャッシュサイズは３つのアプリケーションの総計データサイズより大きく、３つのアプリケーション全ての格納（キャッシュ）が可能であると判断する。
結果として、リンク関係にある３つ全てのアプリケーション（ＡＰＰ１，ＡＰＰ２，ＡＰＰ３）のキャッシュ処理を実行することに決定する。
（ステップＳ１５３）
次に、受信装置は、ステップＳ１５３において、Ｓ−ＴＳＩＤから、エントリ文書の取得先情報を取得する。
具体的には、図３４のステップＳ１５３に示すように、Ｓ−ＴＳＩＤに記録されたファイル単位の情報に記録されたコンテンツロケーション情報（ＲＳ／ＬＳ／ＳｃＦｌｗ／ＥＦＤＴ／ｃｏｎｔｅｎｔ−ｌｏｃａｔｉｏｎ）と、ＡＩＴのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報を取得する。
なお、本例では、ＡＩＴに記録された３つのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報を取得する。
（ステップＳ１５４）
次に、受信装置は、ステップＳ１５４において、３つのアプリケーション各々のエントリ文書のグループ（Ｇｒｏｕｐ）要素に記述されたプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）から、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）を取得する。
図３４のステップＳ１５４に示すように、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）は、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）から構成されている。
アプリ本体ＩＤ（ａｐｐＩｄ）は、ファイルの属するプレゼンテーション・ユニット（ＰＵ）が属するアプリケーションに設定されたアプリケーションＩＤ（組織ＩＤ（ｏｒｇＩｄ）＋アプリ本体ＩＤ（ａｐｐＩｄ））の構成データであるアプリ本体ＩＤ（ａｐｐＩｄ）と同じ値である。
本例では、図３４のステップＳ１５４ａ，Ｓ１５４ｂ，Ｓ１５４ｃに示すように、リンク関係にある３つのアプリケーションＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２，ａｐｐＩｄ３）を取得する。
（ステップＳ１５５）
次に、受信装置は、ステップＳ１５５において、エントリ文書のＰＵＩＤ（アプリ本体ＩＤ（ａｐｐＩｄ）＋グループＩＤ（ｇｒｏｕｐＩｄ））中のアプリ本体ＩＤ（ａｐｐＩｄ）と同じアプリ本体ＩＤ（ａｐｐＩｄ）を持つファイルを取得して、キャッシュ処理を実行する。
本例では、３つのアプリケーションＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２，ａｐｐＩｄ３）を持つファイルを取得して、キャッシュ処理を実行し、アプリケーション１（ＡＰＰ１）のエントリ文書を用いてアプリケーションの実行を開始する。
図３４のステップＳ１５５に示すように、Ｓ−ＴＳＩＤに記録されたファイル単位の情報から、エントリ文書のＰＵＩＤ（ＰＵＩｄ１１，ＰＵＩｄ２１，ＰＵＩｄ３１）を構成するアプリ本体ＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２，ａｐｐＩｄ３）と同じアプリ本体ＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２，ａｐｐＩｄ３）を持つファイルを取得して、キャッシュ処理を実行して、出力（表示）する。
これらの処理によって、リンク関係の設定されたアプリケーション（ＡＰＰ１）と、アプリケーション（ＡＰＰ２）、およびアプリケーション（ＡＰＰ３）に属する全てのプレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２，ＰＵ１３、ＰＵ２１，ＰＵ２２，ＰＵ２３，ＰＵ３１，ＰＵ３２）に属する全てのファイルを取得することができる。
これにより、３つのアプリケーション（ＡＰＰ１〜ＡＰＰ３）に属する全てのプレゼンテーション・ユニット（ＰＵ１１〜ＰＵ３２）の全構成ファイルを利用したアプリケーションの実行が可能となる。
すなわち、アプリケーション単位、およびプレゼンテーション・ユニット単位の完全な形態でのデータ再生が可能となる。
すなわち、より完成度の高いアプリケーション実行処理が実現される。
［１０．受信装置におけるデータ処理の全体シーケンスについて］
次に、図３５以下に示すフローチャートを参照して、受信装置の実行する主要な処理のシーケンスについて説明する。
図３５以下に示すフローチャートは、受信装置において実行する例えば以下の処理を中心として説明するフローチャートである。
（１）放送ストリームの受信処理、
（２）アプリケーション構成ファイルのキャッシュ処理、
（３）アプリケーションの実行およびアプリケーション間の遷移処理
［１０−１．受信装置における放送ストリーム受信処理の全体シーケンス］
まず、図３５に示すフローを参照して受信装置の実行する放送ストリームの受信処理の全体シーケンスについて説明する。各ステップの処理について説明する。
（ステップＳ２０１）
ステップＳ２０１は、受信装置において実行する選局処理である。
これは、受信装置側のユーザによる受信チャンネル（例えば放送局）選択処理である。
（ステップＳ２０２）
ステップＳ２０１において、１つの受信チャンネルが選択されると、ステップＳＺ２０２において、受信装置は、選択チャンネルに応じた放送ストリームの受信処理を実行する。
この処理の詳細については、図３６以下のフローを参照して後段で説明する。
（ステップＳ２０３）
ステップＳ２０３は、放送ストリームの受信終了の判定処理ステップである。例えばユーザによる受信装置の電源オフ等の処理をトリガとしてステップＳ２０２の放送ストリーム受信処理を終了する。
放送ストリームの受信終了がなされない場合は、ステップＳ２０２の放送ストリームの受信処理を継続して実行する。
［１０−２．受信装置における放送ストリーム受信処理の詳細シーケンス］
次に、図３６に示すフローを参照して受信装置の実行する放送ストリームの受信処理の詳細シーケンスについて説明する。各ステップの処理について説明する。
（ステップＳ２５１）
受信装置は、放送ストリームの受信処理を開始すると、送信装置からの送信パケットの受信処理を開始する。
なお、受信装置において選択されたチャンネルに従って選択されたチャンネル対応のデータ格納パケットを選択して取得する。
なお、送信装置の送信するデータは、先に図２参照して説明したように、
ＡＶセグメント、
シグナリングデータ、
アプリケーション等を含むＮＲＴデータ等、
これら様々なデータがである。
なお、シグナリングデータには、先に説明したＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ−ＴＳＩＤ等、様々な種類のシグナリングデータが含まれる。
（ステップＳ２５２）
受信装置は、受信パケットのパケットヘッダ情報等を参照して、受信データが、
ビデオ、音声、字幕データ等のＡＶセグメントであるか、
アプリケーション等のＮＲＴデータであるか、
シグナリングデータであるか、
これらのいずれであるかを判定する。
受信パケットが、ビデオ、音声、字幕データ等のＡＶセグメントを格納したパケットである場合は、ステップＳ２５３に進む。、
受信パケットが、アプリケーション等のＮＲＴデータを格納したパケットである場合は、ステップＳ２５４に進む。、
受信パケットが、ＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ−ＴＳＩＤ等のシグナリングデータを格納したパケットである場合は、ステップＳ２５５に進む。、
（ステップＳ２５３）
受信パケットが、ビデオ、音声、字幕データ等のＡＶセグメントを格納したパケットである場合は、ステップＳ２５３において、受信パケットから、ビデオ、音声、字幕データ等を取り出し、所定の復号処理を実行し、レンダリング、すなわち再生出力処理を実行する。
この処理は、例えば放送番組の再生出力処理である。
（ステップＳ２５４）
受信パケットが、アプリケーション等のＮＲＴデータを格納したパケットである場合は、ステップＳ２５４において、シグナリングデータに基づいてＮＲＴデータを受信し、蓄積する処理を行なう。
なお、ＮＲＴデータがアプリケーションである場合は、先に説明したように、ＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ−ＴＳＩＤ等のシグナリングデータの記録情報に従って、格納（キャッシュ）データの選択処理を伴う処理を実行する。
すなわち、アプリケーションの格納（キャッシュ）処理に先行してアプリケーション対応のシグナリングデータの取得が実行され、先行取得したシグナリングデータの記述に従ってアプリケーションの選択的取、キャッシュ処理が実行されることになる。
（ステップＳ２５５）
受信パケットが、ＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ−ＴＳＩＤ等のシグナリングデータを格納したパケットである場合は、ステップＳ２５５に進む。
ステップＳ２５５では、シグナリングデータの受信、解析処理を実行する。
この処理の詳細については、図３７のフローを参照して後段で説明する。
（ステップＳ２５６）
ステップＳ２５６において、ステップＳ２５５におけるシグナリングデータの解析結果に基づいて、アプリケーションの取得処理が必要か否かを判定する。
具体的には、受信装置がアプリケーションの取得処理を実行する設定となっているか、すなわち、アプリケーション取得処理フラグがＴｒｕｅに設定されているか否かを判定する処理を行なう。
なお、このフラグ設定は、ステップＳ２５５においてシグナリングデータとしてＡＩＴを受信した場合に設定される。詳細については、後段において図３７に示すフローを参照して説明する。
フラグ設定がアプリケーション取得処理を実行する設定になっている場合は、ステップＳ２５７に進む。
アプリケーションの取得を行う設定でないと判定した場合は、ステップＳ２０２の放送ストリーム受信処理の開始位置に戻り、次のパケットの受信処理、すなわち、ステップＳ２５１以下の処理を実行する。
（ステップＳ２５７）
ステップＳ２５６において、ステップＳ２５５におけるシグナリングデータの解析結果に基づいて、アプリケーションの取得処理が必要と判定した場合は、ステップＳ２５７に進み、アプリケーションの取得処理を実行する。
この処理は、先に説明したＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ−ＴＳＩＤ等のシグナリングデータの記録情報に従ったアプリケーションの取得処理であり、キャッシュ対象データを自装置のキャッシュ容量に応じて選択する処理を伴う処理である。
この処理については、図３８に示すフローを参照して後段で詳細に説明する。
［１０−３．受信装置におけるシグナリングの受信、解析処理の詳細シーケンス］
次に、図３７に示すフローを参照して、図３６のステップＳ２５５において実行するシグナリングデータの受信、解析処理の詳細シーケンスについて説明する。
以下、各ステップの処理について説明する。
（ステップＳ２８１）
まず、受信装置は、ステップＳ２８１において、受信したシグナリングデータが、取得対象となるシグナリングデータであるか否かを判定する。
未取得のシグナリングデータや、取得済みであっても取得済みシグナリングデータより新しいバージョンの更新されたシグナリングデータを受信した場合等は、取得対象のシグナリングデータであると判定してステップＳ２８２に進む。
（ステップＳ２８２）
ステップＳ２８２において、受信装置は、シグナリングデータを取得する。
なお、先に説明したように、シグナリングデータには、様々な種類がある。
例えば、ＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ−ＴＳＩＤ等のシグナリングデータ、さらに、ＡＶストリーム対応のシグナリングデータであるＭＰＤ等、様々な種類のシグナリングデータがある。
（ステップＳ２８３）
次に、受信装置は、ステップＳ２８３において、受信したシグナリングデータが、アプリケーションに対応する制御情報等を記録したＡＩＴ（アプリケーション・インフォメーション・テーブル）であるか否かを判定する。
ＡＩＴである場合は、ステップＳ２８４に進む。
ＡＩＴ以外のシグナリングデータである場合は、ステップＳ２８５に進む。
（ステップＳ２８４）
ステップＳ２８３において、受信したシグナリングデータが、アプリケーションに対応する制御情報等を記録したＡＩＴ（アプリケーション・インフォメーション・テーブル）であると判定した場合、受信装置は、ステップＳ２８４において、アプリケーションの取得処理を実行する設定、すなわち、アプリケーション取得処理フラグをＴｒｕｅとする処理を行なう。
（ステップＳ２８５）
一方、ステップＳ２８３において、受信したシグナリングデータが、アプリケーションに対応する制御情報等を記録したＡＩＴ（アプリケーション・インフォメーション・テーブル）でなく、その他のシグナリングデータあると判定した場合、受信装置は、ステップＳ２８５に進み、受信したＡＩＴ以外のシグナリングデータの解析、および受信シグナリングデータに従った処理を実行する。
［１０−４．受信装置におけるアプリケーションの取得、実行処理の詳細シーケンス］
次に、図３８に示すフローを参照して、図３６のステップＳ２５７において実行するアプリケーションの取得、実行処理の詳細シーケンスについて説明する。
以下、各ステップの処理について説明する。
（ステップＳ３０１）
まず、受信装置は、ステップＳ３０１において、取得したＡＩＴから、アプリケーションに対する処理態様を規定したコントロールコード（ｃｔｒｌＣｏｄｅ）情報を取得し、コントロールコードがアプリケーションのキャッシュ処理を必要とするコードであるか否かを判定する。
キャッシュ処理の必要なコードは、例えば、アプリケーションの即時実行を指定したコードである（ＡＵＴＯＳＴＡＲＴ）、あるいはアプリケーションを事前取得し、その後、所定時間に実行させるコードである（ＰＲＥＦＥＴＣＨ）等がある。
ＡＩＴに記録されたコントロールコードが、これらのアプリケーションのキャッシュ処理を必要とするコードであることを確認すると、ステップＳ３０２に進む。
なお、これら、キャッシュ処理が必要となるコードでない場合は、ステップＳ３０２以下の処理は実行されず、記録コードに応じた処理が実行されることになる。
（ステップＳ３０２）
受信装置は、ＡＩＴに記録されたコントロールコードが、アプリケーションのキャッシュ処理を必要とするコードであることを確認すると、ステップＳ３０２において、ＡＩＴから、アプリケーションの取得先ＵＲＩを読み取る。
すなわち、先に図１５を参照して説明したＡＩＴ記録情報中のアプリケーションアクセス情報（ａｐｐＬｏｃａｔｉｏｎ（ＵＲＩ））である。
（ステップＳ３０３〜Ｓ３０４）
次に、受信装置は、ステップＳ３０３において、もう１つのシグナリングデータであるＵＳＤ（またはＵＳＢＤ）を参照して、アプリケーションが放送波、または通信ネットワークのいずれを介して送信されるかを確認する。
これは、先に図１２を参照して説明した処理であり、図１２に示すＵＳＤ（ＵＳＢＤ）に記録されたベースパターン情報を参照して確認する。
図１２に示すＵＳＤ（ＵＳＢＤ）には、アプリケーションが放送波を介して送信される場合、放送波に対応するベースパターン記録領域（ＵＳＤ／ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ／ａｔｓｃ：ＢｃＡｐｐＳｅｒｖｉｃｅ／ｂａｓｅＰａｔｔｅｒｎ）にベースパターンが記録される。
一方、アプリケーションが通信ネットワークを介して送信される場合、通信ネットワークに対応するベースパターン記録領域（ＵＳＤ／ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ／ａｔｓｃ：ＵｃＡｐｐＳｅｒｖｉｃｅ／ｂａｓｅＰａｔｔｅｒｎ）にベースパターンが記録される。
受信装置は、ＵＳＤにどちらのベースパターンが記録されているかによって、アプリケーションが放送波を介して送信されるか、インターネット等の通信ネットワークを介して送信されるかを判定することができる。
アプリケーションが放送波を介して送信されることが確認された場合は、ステップＳ３０５に進む。
一方、アプリケーションがインターネット等の通信ネットワークを介して送信されることが確認された場合は、ステップＳ３０６に進む。
（ステップＳ３０５）
アプリケーションが放送波を介して送信されることが確認された場合は、ステップＳ３０５にみ、ステップＳ３０５において、放送波を介したアプリケーション取得処理を実行する。
この処理については、後段で図３９に示すフローを参照して詳細に説明する。
（ステップＳ３０６）
一方、アプリケーションがインターネット等の通信ネットワークを介して送信されることが確認された場合は、ステップＳ３０６にみ、ステップＳ３０６において、通信ネットワークを介したアプリケーション取得処理を実行する。
（ステップＳ３０７）
ステップＳ３０５、またはステップＳ３０６においてアプリケーションの取得処理が行われた後、受信装置は、ステップｓ３０７においてアプリケーションを実行する。
なお、アプリケーションの実行タイミング等は、アプリケーション対応のＡＩＴに記録されており、受信装置は、ＡＩＴの記述に従ってアプリケーションの実行制御を行う。
［１０−５．受信装置における放送経由のアプリケーションの取得処理の詳細シーケンス］
次に、図３９に示すフローを参照して、図３８のステップＳ３０５において実行する放送経由でのアプリケーションの取得処理の詳細シーケンスについて説明する。
以下、各ステップの処理について説明する。
（ステップＳ３２１）
まず、受信装置は、ステップＳ３２１において、受信装置の利用可能なキャッシュサイズを取得する。
（ステップＳ３２２）
次に、受信装置は、ステップＳ３２２において、取得予定のアプリケーションのデータサイズ、すなわちアプリケーションサイズを取得する。
アプリケーションサイズは、先に図１２を参照して説明したようにＡＩＴに記録されている。図１２に示すアプリケーションサイズ２５３（＠ａｐｐＳｉｚｅ）である。
受信装置は、取得予定のアプリケーションに対応するＡＩＴを参照して、アプリケーションサイズを読み取る。
（ステップＳ３２３）
次に、受信装置は、ステップＳ３２３において、受信装置の利用可能なキャッシュサイズと、アプリケーションサイズを比較する。
キャッシュサイズが、アプリケーションサイズより小さい場合は、ステップＳ３２４に進む。
一方、キャッシュサイズが、アプリケーションサイズ以上である場合は、ステップＳ３２５に進む。
（ステップＳ３２４）
ステップＳ３２３におけるサイズ比較処理において、キャッシュサイズが、アプリケーションサイズより小さいと判定した場合は、ステップＳ３２４に進み、プレゼンテーション・ユニット（ＰＵ）単位のキャッシュ処理を実行する。
この処理は、先に図２０〜図２５を参照して説明した処理、すなわち、
キャッシュサイズが最小サイズ（Ｍｉｎｉｍｕｍ）、または小サイズ（Ｓｍａｌｌ）の場合の処理に相当する処理である。
（ステップＳ３２５）
一方、ステップＳ３２３におけるサイズ比較処理において、キャッシュサイズが、アプリケーションサイズ以上であると判定した場合は、ステップＳ３２５に進み、アプリケーション単位のキャッシュ処理を実行する。
この処理は、先に図２６〜図３４を参照して説明した処理、すなわち、
キャッシュサイズが中サイズ（Ｍｅｄｉｕｍ）、または大サイズ（Ｌａｒｇｅ）、または最大サイズ（Ｍａｘｉｍｕｍ）の場合の処理に相当する処理である。
［１０−６．受信装置におけるプレゼンテーション・ユニット（ＰＵ）単位のキャッシュ処理の詳細シーケンス］
次に、図４０に示すフローを参照して、図３９のステップＳ３２４において実行するプレゼンテーション・ユニット（ＰＵ）単位のキャッシュ処理の詳細シーケンスについて説明する。
以下、各ステップの処理について説明する。
（ステップＳ３４１）
まず、受信装置は、ステップＳ３４１において、送信装置から送信されるシグナリングデータであるＳ−ＴＳＩＤから、エントリ文書を含むプレゼンテーション・ユニット（ＰＵ）と、このＰＵからリンクするプレゼンテーション・ユニット（ＰＵ）のＩＤ（ＰＵＩＤ）を取得する。
受信装置は、先に図１６を参照して説明したＳ−ＴＳＩＤにおけるプレゼンテーション・ユニット間リンク情報２６１を参照して、リンク関係にあるＰＵのＩＤを取得する。
（ステップＳ３４２）
次に、受信装置は、受信装置のキャッシュサイズ、すなわち利用可能なキャッシュサイズと、各プレゼンテーション・ユニット（ＰＵ）のデータサイズを比較して、キャッシュ対象とするプレゼンテーション・ユニットを選択する。
なお、最優先キャッシュ対象ＰＵは、エントリ文書を有するプレゼンテーション・ユニット（例えば、ＰＵ１１）である。
その次の優先キャッシュ対象ＰＵは、エントリ文書を有するＰＵ１１のリンク先ＰＵ、例えばＰＵ１２となる。
さらに、ＰＵ１２のリンク先ＰＵ１３が次のキャッシュ対象ＰＵとして選択され、リンクを辿って、順次、キャッシュ対象ＰＵが選択される。
キャッシュサイズを超えた時点で、キャッシュ対象ＰＵの選択が完了する。
具体的には、例えば、
ＰＵ１１サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２）サイズ
の場合は、ＰＵ１１のみをキャッシュ対象ＰＵとして選択する。
また、（ＰＵ１１＋ＰＵ１２）サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２＋ＰＵ１３）サイズ
の場合は、ＰＵ１１とＰＵ１２をキャッシュ対象ＰＵとして選択する。
このように、ＰＵの総計サイズが、キャッシュサイズに達するまでの範囲内で、キャッシュ対象ＰＵを、リンクを辿って順次、選択する。
（ステップＳ３４３）
次に、受信装置は、ステップＳ３４２で決定したキャッシュ対象プレゼンテーション・ユニット（ＰＵ）を取得して、キャッシュ部（記憶部）にキュッシュ（格納）する。
その後、図３８のフローに示すステップＳ３０７において、キャッシュされたプレゼンテーション・ユニットを利用してアプリケーションが実行される。
なお、この図４０に示すフローに従った処理は、先に図２０〜図２５を参照して説明した処理、すなわち、
キャッシュサイズが最小サイズ（Ｍｉｎｉｍｕｍ）、または小サイズ（Ｓｍａｌｌ）の場合の処理に相当する処理である。
先に説明したように、１つのプレゼンテーション・ユニット（ＰＵ：Ｐｅｒｅｓｅｎｔａｔｉｏｎ Ｕｎｉｔ）は、１つまたは複数のＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を利用して提示されるデータのセットによって構成される。
具体的には、１つのプレゼンテーション・ユニット（ＰＵ）は、以下の構成要素からなるユニットである。
（１）１つまたは複数のＨＴＭＬファイル
（２）上記ＨＴＭＬに従って出力される画像（動画、静止画）ファイル、
（３）上記ＨＴＭＬに従って出力される音声ファイル、
（４）上記ＨＴＭＬに従ったデータ出力スタイルを規定したスタイルシート格納ファイル、
例えば、上記構成要素によって１つのプレゼンテーション・ユニット（ＰＵ）が設定される。
１つのプレゼンテーション・ユニット（ＰＵ）に属するデータが全て取得できれば、そのプレゼンテーション・ユニット（ＰＵ）に含まれるＨＴＭＬ文書によるデータ出力、例えばＷｅｂペーシの出力が完全な形で実行されることが保証される。
［１０−７．受信装置におけるアプリケーション単位のキャッシュ処理の詳細シーケンス］
次に、図４１に示すフローを参照して、図３９のステップＳ３２５において実行するアプリケーション単位のキャッシュ処理の詳細シーケンスについて説明する。
以下、各ステップの処理について説明する。
（ステップＳ３６１）
まず、受信装置は、ステップＳ３６１において、送信装置から送信されるシグナリングデータであるＡＩＴから、初期実行アプリケーションと、そのアプリケーションのリンク先アプリケーションの情報を取得する。
受信装置は、例えば、先に図１５を参照して説明したＡＩＴにおけるリンク先アプリケーション情報２５４を参照して、リンク関係にあるアプリケーションの情報を取得する。
（ステップＳ３６２）
次に、受信装置は、受信装置のキャッシュサイズ、すなわち利用可能なキャッシュサイズと、各アプリケーションのデータサイズを比較して、キャッシュ対象とするアプリケーションを選択する。
なお、最優先キャッシュ対象アプリケーションは、ＡＩＴによって指定された初期起動アプリケーション（例えば、ＡＰＰ１）である。
その次の優先キャッシュ対象アプリは、初期起動アプリ１（ＡＰＰ１）のリンク先アプリ、例えばＡＰＰ２となる。
さらに、アプリ２（ＡＰＰ２）のリンク先アプリ３（ＡＰＰ３）が次のキャッシュ対象アプリとして選択され、リンクを辿って、順次、キャッシュ対象アプリが選択される。
キャッシュサイズを超えた時点で、キャッシュ対象アプリの選択が完了する。
具体的には、例えば、
アプリ１（ＡＰＰ１）サイズ≦キャッシュサイズ＜（アプリ１（ＡＰＰ１）＋アプリ２（ＡＰＰ２））サイズ
の場合は、アプリ１（ＡＰＰ１）のみをキャッシュ対象ＰＵとして選択する。
また、アプリ１（ＡＰＰ１）＋アプリ２（ＡＰＰ２））サイズ≦キャッシュサイズ＜（アプリ１（ＡＰＰ１）＋アプリ２（ＡＰＰ２）＋アプリ３（ＡＰＰ３））サイズ
の場合は、アプリ１（ＡＰＰ１）と、アプリ２（ＡＰＰ２）をキャッシュ対象ＰＵとして選択する。
このように、アプリの総計サイズが、キャッシュサイズに達するまでの範囲内で、キャッシュ対象アプリを、リンクを辿って順次、選択する。
（ステップＳ３６３）
次に、受信装置は、ステップＳ３６２で決定したキャッシュ対象アプリケーションを取得して、キャッシュ部（記憶部）にキュッシュ（格納）する。
その後、図３８のフローに示すステップＳ３０７において、キャッシュされたアプリケーションを利用してアプリケーションが実行される。
なお、この図４１に示すフローに従った処理は、先に図２６〜図３４を参照して説明した処理、すなわち、
キャッシュサイズが中サイズ（Ｍｅｄｉｕｍ）、または大サイズ（Ｌａｒｇｅ）、または最大サイズ（Ｍａｘｉｍｕｍ）の場合の処理に相当する処理である。
先に説明したように、１つのアプリケーションには１つ以上のプレゼンテーション・ユニット（ＰＵ：Ｐｅｒｅｓｅｎｔａｔｉｏｎ Ｕｎｉｔ）が含まれる。プレゼンテーション・ユニット（ＰＵ）は、
（１）１つまたは複数のＨＴＭＬファイル
（２）上記ＨＴＭＬに従って出力される画像（動画、静止画）ファイル、
（３）上記ＨＴＭＬに従って出力される音声ファイル、
（４）上記ＨＴＭＬに従ったデータ出力スタイルを規定したスタイルシート格納ファイル、
例えば、上記構成要素によって構成される。
１つのプレゼンテーション・ユニット（ＰＵ）に属するデータが全て取得できれば、そのプレゼンテーション・ユニット（ＰＵ）に含まれるＨＴＭＬ文書によるデータ出力、例えばＷｅｂペーシの出力が完全な形で実行されることが保証される。
本開示のキャッシュ処理は、アプリケーション単位、またはプレゼンテーション・ユニット（ＰＵ）単位でキャッシュ処理を実行する。
すなわち、最小キャッシュ単位は、プレゼンテーション・ユニット（ＰＵ）であり、ＰＵを構成するデータの一部がキャッシュされていないといった事態を発生させることかない。
従って、プレゼンテーション・ユニット（ＰＵ）のに含まれるＨＴＭＬ文書による完成されたデータ出力が実行される。
［１０−８．受信装置におけるアプリケーションまたはプレゼンテーション・ユニット（ＰＵ）間の遷移処理シーケンス］
次に、図４２に示すフローを参照して、アプリケーション実行中に発生するアプリケーションまたはプレゼンテーション・ユニット（ＰＵ）間の遷移処理シーケンスについて説明する。
以下、各ステップの処理について説明する。
（ステップＳ５０１〜Ｓ５０２）
以下において説明する処理は、受信装置において所定のアプリケーションを実行中に行われる処理である。
受信装置は、ステップＳ５０１において遷移イベントを待機する。
なお、ここで遷移とは、実行中のアプリケーションからリンク先アプリへの遷移であるアプリ間遷移、または、実行中のプレゼンテーション・ユニット（ＰＵ）からリンク先のプレゼンテーション・ユニット（ＰＵ）への遷移であるＰＵ間遷移のいずれかである。
なお、遷移イベントは、例えばＡＩＴの制御情報、あるいは、例えばユーザの操作に基づいて発生するリンク先への遷移を指示するイベントである。
受信装置は、遷移イベントを検出するとステップＳ５０３に進む。
（ステップＳ５０３）
受信装置は、遷移イベントの検出に応じて、ステップＳ５０３において、遷移先のアプリケーション、またはプレゼンテーション・ユニット（ＰＵ）がキャッシュ済みであるか否かを判定する。
キャッシュ済みである場合は、ステップＳ５０４に進む。
一方、キャッシュ済みでない場合は、ステップＳ５０５に進む。
（ステップＳ５０４）
ステップＳ５０３において、遷移先のアプリケーション、またはプレゼンテーション・ユニット（ＰＵ）がキャッシュ済みであると判定した場合は、ステップＳ５０４において、遷移先のアプリケーション、またはプレゼンテーション・ユニット（ＰＵ）をキャッシュ部から取得して実行する。
（スップＳ５０５）
一方、ステップＳ５０３において、遷移先のアプリケーション、またはプレゼンテーション・ユニット（ＰＵ）がキャッシュ済みでないと判定した場合は、ステップＳ５０５において、遷移態様が、以下のいずれであるかを確認する。
（ａ）アプリケーション内のブレゼンテーション・ユニット（ＰＵ）間の遷移、
（ｂ）アプリケーション間の遷移、
（ａ）アプリケーション内のブレゼンテーション・ユニット（ＰＵ）間の遷移である場合は、ステップＳ５０６に進む。
一方、（ｂ）アプリケーション間の遷移である場合は、ステップＳ５０７に進む。
（ステップＳ５０６）
ステップＳ５０５において、遷移イベントが、（ａ）アプリケーション内のブレゼンテーション・ユニット（ＰＵ）間の遷移である場合は、ステップＳ５０６において、遷移先のプレゼンテーション・ユニット（ＰＵ）のキャッシュ処理を実行する。
この処理は、先に図４０を参照して説明したプレゼンテーション・ユニット（ＰＵ）単位のキャッシュ処理と同じ処理である。
このキャッシュ処理を実行した後、キャッシュしたプレゼンテーション・ユニット（ＰＵ）をキャッシュ部から取得して実行する。
（ステップＳ５０７）
一方、ステップＳ５０５において、遷移イベントが、（ｂ）アプリケーション間の遷移である場合は、ステップＳ５０７において、遷移先のアプリケーションを取得してキャッシュ処理を実行し、その後、キャッシュアプリケーションを実行する。
この処理は、先に図３８を参照して説明したアプリケーションの取得、実行処理と同じ処理である。
このように、リンク先のアプリケーション、またはプレゼンテーション・ユニット（ＰＵ）がキャッシュされていない場合においても、リンク先に応じてキャッシュ対象をアプリケーション、またはプレゼンテーション・ユニット（ＰＵ）単位としたキャッシュ処理を実行する。
［１１．アプリケーション遷移処理の具体例について］
次に、図４２に示すフローチャートを参照して説明したアプリケーションの遷移処理の具体例について説明する。
図４３、図４４を参照して、以下の２つの遷移処理例について説明する。
（例１）番組再生に併せて実行される番組連動アプリからＣＭアプリへの遷移処理例
（例２）番組再生アプリからＣＭアプリへの遷移処理例
まず、図４３を参照して、
（例１）番組再生に併せて実行される番組連動アプリからＣＭアプリへの遷移処理例
について説明する。
図４３には、受信装置の選択したチャンネルに対応して、送信装置が放送波を介して提供する以下の４つのデータを示している。
（ａ）画像（Ｖｉｄｅｏ）
（ｂ）音声（Ａｕｄｉ）
（ｃ）ＮＲＴ（アプリケーション（ＡＰＰ））
（ｄ）シグナリングデータ
受信装置は、図４３に示すステップＳ７０１〜Ｓ７０７の処理を実行する。
各処理ステップについて、順次、説明する。
（ステップＳ７０１）
まず、受信装置は、ステップＳ７０１において、送信装置の送信するシグナリングデータを受信する。
シグナリングデータには、様々な種類があり、ＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ−ＴＳＩＤ、さらに、番組再生に利用されるＭＰＤ等がある。
受信装置は、これらのシグナリンクデータを受信する。
（ステップＳ７０２）
次に、受信装置は、ステップＳ７０２において、受信したシグナリングデータを解析し、解析結果に基づいて番組構成データであるＡＶセグメント、アプリのケーションリソース等のアクセス情報等、番組再生やアプリケーションの実行に必要となる情報を取得する。
（ステップＳ７０３）
次に、受信装置は、ステップＳ７０３において、ステップＳ７０２で取得したシグナリングデータ解析情報に基づいて、番組を構成するＡＶセグメントやアプリケーションリソース等のデータ取得処理、キャッシュ処理を実行する。
本例では、番組再生に必要となるＡＶセグメント、および番組再生に併せて実行させる番組連動アプリ（ＡＰＰ１）、さらに、番組連動アプリ（ＡＰＰ１）のリンク先（遷移先）アプリであるＣＭアプリケーション（ＣＭ ＡＰＰ）を取得し、キャッシュ部に格納する。
（ステップＳ７０４）
受信装置は、ステップＳ７０４において、放送波を介して取得したＡＶセグメントを用いて番組再生を行ない、さらに番組再生に並列して番組連動アプリ（ＡＰＰ１）を実行する。
例えば、一例として、番組が野球中継であり、番組連動アプリ（ＡＰＰ１）は出場選手の選手情報提供アプリケーション等の組み合わせ等がある。
（ステップＳ７０５）
次に、受信装置に対して、シグナリングデータによるイベント通知がなされる。
このイベント通知は、実行アプリケーションの切り替えを要求するイベント通知で、すなわちアプリケーション間遷移通知イベントである。
（ステップＳ７０６）
受信装置は、このアプリ遷移イベントの検出に応じて、アプリケーションの遷移処理を実行する。
この処理の具体的処理シーケンスは、図４２に示すフローチャートに従った処理となる。
ここで、遷移先のアプリケーションは、ＣＭアプリケーション（ＣＭ ＡＰＰ）であるものとする。
（ステップＳ７０７）
受信装置は、ステップＳ７０７において、予めキャッシュされているＣＭアプリケーション（ＣＭ ＡＰＰ）を利用してＣＭの再生処理を開始する。
例えば、ここで再生するＣＭアプリは、先に図６を参照して説明したように、視聴者に応じたＣＭとして設定することができる。
送信装置が、様々な視聴者に対応した異なるＣＭアプリを送信する構成として、受信装置側で、予め登録したユーザ情報に応じて受信するＣＭアプリを選択してキャッシュする。
このようなアプリの選択取得処理を実行することで、ユーザ（視聴者）の年齢、性別、好み等に応じた最適なユーザ対応ＣＭを表示することも可能となる。
次に、図４４を参照して、
（例２）番組再生アプリからＣＭアプリへの遷移処理例
について説明する。
図４４にも、図４３と同様、受信装置の選択したチャンネルに対応して、送信装置が放送波を介して提供する以下の４つのデータを示している。
（ａ）画像（Ｖｉｄｅｏ）
（ｂ）音声（Ａｕｄｉ）
（ｃ）ＮＲＴ（アプリケーション（ＡＰＰ））
（ｄ）シグナリングデータ
受信装置は、図４４に示すステップＳ８０１〜Ｓ８０７の処理を実行する。
各処理ステップについて、順次、説明する。
（ステップＳ８０１）
まず、受信装置は、ステップＳ８０１において、送信装置の送信するシグナリングデータを受信する。
シグナリングデータには、様々な種類があり、ＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ−ＴＳＩＤ、さらに、番組再生に利用されるＭＰＤ等がある。
受信装置は、これらのシグナリンクデータを受信する。
（ステップＳ８０２）
次に、受信装置は、ステップＳ８０２において、受信したシグナリングデータを解析し、解析結果に基づいて番組構成データであるＡＶセグメント、アプリのケーションリソース等のアクセス情報等、番組再生やアプリケーションの実行に必要となる情報を取得する。
（ステップＳ８０３）
次に、受信装置は、ステップＳ８０３において、ステップＳ７０２で取得したシグナリングデータ解析情報に基づいて、番組を構成するＡＶセグメントやアプリケーションリソース等のデータ取得処理、キャッシュ処理を実行する。
本例では、番組再生に必要となるＡＶセグメント、および番組再生処理を実行する番組再生アプリ（ＡＰＰ１）、さらに、番組再生アプリ（ＡＰＰ１）のリンク先（遷移先）アプリであるＣＭアプリケーション（ＣＭ ＡＰＰ）を取得し、キャッシュ部に格納する。
（ステップＳ８０４）
受信装置は、ステップＳ８０４において、放送波を介して取得したＡＶセグメントと番組再生アプリ（ＡＰＰ１）を用いて番組再生を行なう。
（ステップＳ８０５）
次に、受信装置は、例えばＡＩＴ等のシグナリングデータ、あるいは、ユーザの操作（リモコン操作）等によるイベントを検出する。
このイベントは、実行アプリケーションの切り替えを要求するイベントである。すなわちアプリケーション間遷移通知イベントである。
（ステップＳ８０６）
受信装置は、このアプリ遷移イベントの検出に応じて、アプリケーションの遷移処理を実行する。
この処理の具体的処理シーケンスは、図４２に示すフローチャートに従った処理となる。
ここで、遷移先のアプリケーションは、ＣＭアプリケーション（ＣＭ ＡＰＰ）であるものとする。
（ステップＳ８０７）
受信装置は、ステップＳ８０７において、予めキャッシュされているＣＭアプリケーション（ＣＭ ＡＰＰ）を利用してＣＭの再生処理を開始する。
この例においても、ＣＭアプリは、先に図６を参照して説明したように、視聴者に応じたＣＭとして設定することができる。
送信装置が、様々な視聴者に対応した異なるＣＭアプリを送信する構成として、受信装置側で、予め登録したユーザ情報に応じて受信するＣＭアプリを選択してキャッシュする。
このようなアプリの選択取得処理を実行することで、ユーザ（視聴者）の年齢、性別、好み等に応じた最適なユーザ対応ＣＭを表示することも可能となる。
［１２．サービスワーカー（ＳＷ）を利用したキュッシュ制御処理例について］
次に、サービスワーカー（ＳＷ）を利用してアプリケーションのキャッシュ制御を行う処理例について説明する。
まず、サービスワーカー（ＳＷ：Ｓｅｒｖｉｃｅ Ｗｏｒｋｅｒ）の概要について、図４５〜図４７を参照して説明する。
サービスワーカー（ＳＷ）は、放送サーバや、広告サーバ等の送信装置２０から受信装置３０に提供される。
サービスワーカー（ＳＷ）は、受信装置（クライアント）３０において実行されるアプリケーションや、アプリケーションの実行時に利用されるデータファイル等の取得処理や、記憶部（キャッシュ）に対する格納処理、さらに更新処理、削除処理等を実行するプログラムである。具体的には、例えばＪａｖａＳｃｒｉｐｔ（登録商標）によって構成される。
サービスワーカー（ＳＷ）は、例えば送信装置２０が提供する放送番組（放送コンテンツ）に対応して設定され、送信装置２０から受信装置３０に提供されるアプリケーションの制御および管理プログラムとして、受信装置３０に提供される。
サービスワーカー（ＳＷ）、アプリケーション、およびアプリケーションの実行時に利用されるデータファイル、これらは、例えば先に図２、図３を参照して説明したＮＲＴコンテンツ（ノンリアルタイムコンテンツ）として、送信装置２０から受信装置３０に提供される。
あるいは、放送番組を配信するサーバとは別のデータ提供サーバが、サービスワーカー（ＳＷ）、アプリケーション、およびアプリケーションの実行時に利用されるデータファイルを受信装置３０に提供する構成としてもよい。
サービスワーカー（ＳＷ）は、例えば、受信装置３０においてＷｅｂページ等の閲覧処理を実行するために利用されるプログラムであるブラウザを利用して情報表示を実行するアプリケーション等の管理（取得、保持、更新、削除等）処理などを実行する。
サービスワーカー（ＳＷ）を利用した処理の具体例（ユースケース）について、図４５、図４６を参照して説明する。
図４５は、受信装置３０が、放送サーバ２１等の送信装置２０から、ある番組コンテンツを受信し、受信装置３０の表示部に表示している状態を示している。
放送サーバ２１等の送信装置２０は、番組配信に併せて、ＮＲＴコンテンツ（ノンリアルタイムコンテンツ）として、天気情報を表示するアプリケーション、およびこの天気情報表示アプリケーションに利用される様々なデータファイル、例えば動画、静止画、音声等の様々なデータを含むデータファイル（リソース）を受信装置３０に提供する。
放送サーバ２１は、さらに、これらの「リソース」を管理するリソース管理プログラムとして、サービスワーカー（ＳＷ）を、やはりＮＲＴコンテンツ（ノンリアルタイムコンテンツ）として受信装置３０に提供する。
受信装置３０は、送信装置２０から受信した「リソース」、すなわちアプリケーションおよびデータファイルを利用して、図４５に示すように、番組表示に併せて、天気情報の表示を行うことができる。
このような、アプリケーションを利用したデータ表示は、これまでのデータ配信構成では、アプリケーションの提供される番組の終了とともに実行できなくなってしまう。
これは、天気情報表示アプリケーション等のリソースは、番組受信中は、受信装置３０において利用可能な設定、例えば、一時記憶キャッシュに格納され、利用可能な状態に設定されるが、番組終了、あるいはユーザがチャンネルを切り替えると、これらのキャッシュデータが消去、あるいはアクセス不可能な状態に設定されてしまうためである。
サービスワーカー（ＳＷ）は、このような番組対応のアプリケーションやデータを、番組終了後や、チャンネル切り替え後、あるいは放送の非受信状態、ネットワーク非接続状態等のオフライン状態であっても利用可能とするためのリソース管理プログラムとして機能する。
図４６に示すように、天気情報表示アプリケーションを、このアプリを提供した番組の終了後や、他のチャンネルに切り換え後、あるいはデータ受信を実行していないオフライン状態であっても、利用することが可能となる。すなわち天気情報を受信装置３０の表示部に表示して閲覧することが可能となる。
なお、天気情報表示アプリケーションは、例えばブラウザ上で表示されるプログラムである。
この天気情報表示アプリケーションは、サービスワーカー（ＳＷ）の制御によって、受信装置３０の記憶部（キャッシュ）に格納される。例えばユーザによる表示要求等のリクエスト（イベント）があると、サービスワーカー（ＳＷ）の制御によって、の記憶部（キャッシュ）から読み出され、表示部に表示される。
なお、アプリケーション等のリソースを格納する記憶部（キャッシュ）は、受信装置３０の電源がオフとなっても格納データが消去されない不揮発性メモリとすることが好ましい。
このように、サービスワーカー（ＳＷ）を利用することで、様々な番組対応アプリケーションを、番組の表示、非表示と無関係に利用することが可能となる。
なお、サービスワーカー（ＳＷ）は、例えばある番組対応のリソース（アプリケーション、およびアプリ関連データ）単位ごとに設定され、リソースに併せて、あるいはリソース送信に前後して送信装置２０から受信装置３０に提供される。
サービスワーカー（ＳＷ）は、各番組対応の設定とすることもできるが、複数番組を含む特定のチャンネル対応のリソースに対して、共通に利用可能としたサービスワーカー（ＳＷ）を設定することもできる。
サービスワーカー（ＳＷ）と、サービスワーカー（ＳＷ）によって管理されるリソース（アプリケーションおよびアプリ関連データ）は、受信装置３０の記憶部（キャッシュ）に格納される。
このサービスワーカー（ＳＷ）を利用してキャッシュ制御処理を実行させる構成とすることができる。
すなわち、先に、図４０をに示すフローチャートを参照して説明したプレゼンテーション・ユニット（ＰＵ）単位のキャッシュ処理や、図４１を参照して説明したアプリケーション単位のキャッシュ制御処理を実行させる構成とすることができる。
図４７は、サービスワーカー（ＳＷ）を利用した処理の一例を説明する図である。
図４７には、受信装置３０が送信装置２０からリソースとしてのＷｅｂページ（例えば図４５、図４６に示す天気情報表示ページ）を取得して受信装置３０の記憶部（キャッシュ）に格納して利用するシーケンスの一例を示している。
なお、Ｗｅｂページは、所定のＷｅｂページ表示アプリケーションと、表示用データによって構成されるリソースを利用して表示される。
図４７には、受信装置内のブラウザ４５０の構成要素として表示処理部４５１、サービスワーカー（ＳＷ）４５２、キャッシュ（記憶部）４５３を示している。
ステップＳ８５１〜Ｓ８５２は、受信装置３０による送信装置２０に対する初回アクセス処理によるリソース（Ｗｅｂページ）取得処理である。
これは、例えば放送サーバ等の送信するＮＲＴコンテンツから取得される。
このリソース取得処理に際してサービスワーカー（ＳＷ）を適用し、キャッシュサイズとアプリサイズやプレゼンテーション・ユニット（ＰＵ）サイズに応じたリソース取得処理を実行させる。
すなわち、最小キャッシュサイズをブレゼンテーション・ユニット（ＰＵ）としたキャッシュ処理を実行する。
このキャッシュ処理によるリソース取得後、表示処理部４５１によって、アプリケーション実行によるＷｅｂページ４５５が、受信装置３０の表示部に表示される。この表示は、このＷｅｂページを提供している番組に併せて表示されている状態であり、先に図４５を参照して説明した表示状態に相当する。
その後、番組終了後、あるいはチャンネル切り替え後、あるいはオフライン設定状態において、ステップＳ８５５において、ユーザがＷｅｂペーシの閲覧要求を行う。
サービスワーカー（ＳＷ）４５２は、この閲覧要求の入力をフェッチイベントとして検出し、フェッチイベント検出に応じて、ステップＳ８５６において、リソース（Ｗｅｂページ）を記憶部（キャッシュ）から取得する。
表示処理部４５１は、ステップＳ８５７において、Ｗｅｂページ４５６を表示する。
このＷｅｂページ表示処理は、番組終了後、あるいはチャンネル切り替え後、あるいはオフライン設定状態における表示処理であり、先に図４６を参照して説明した表示状態に相当する。
このように、サービスワーカー（ＳＷ）を利用することで、様々なアプリケーション等のプログラムを、番組の表示、非表示と無関係に利用することが可能となり、例えば、番組付属の表示情報として設定されたＷｅｂページを番組と無関係に、任意のタイミングで表示する等の処理が可能となる。
このように、サービスワーカー（ＳＷ）は、例えば、Ｗｅｂページ、ＨＴＭＬページ、ＪａｖａＳｃｒｉｐｔ（登録商標）等を構成要素としたアプリケーションやプログラム、アプリケーション等に利用されるデータ等からなるリソースの取得、保存、更新、削除等の、リソース管理を実行する。
リソースの保存される記憶部（キャッシュ）は、通常のローカル／テンポラリなキャッシュとは異なり、アプリケーションが稼働していなくても、データが保存される。
Ｗｅｂページ表示プログラムであるブラウザに一種のプロキシサーバが実装され、いつでも、必要なときにプロキシサーバをアクセスしてＷｅｂページを取得して表示可能としたイメージである。
なお、サービスワーカー（ＳＷ）自身もキャッシュに格納（インストール）される。サービスワーカー（ＳＷ）が、受信装置にインストールされると、このサービスワーカー（ＳＷ）の管理対象とするリソースについて、様々な制御が可能となる。
例えば、リソースへのアクセスリクエスト（リソースへのフェッチリクエスト）に応じて、ブラウザ側の処理（ローカルキャッシュやネットワークからのリソースの取得）がはじまる前に、サービスワーカー（ＳＷ）の処理が開始され、キャッシュからのリソースの提供が行われる。
また、サービスワーカー（ＳＷ）は、ＪａｖａＳｃｉｒｐｔ（登録商標）で提供されるため、さまざまな手続きを組み込むことが可能であり、キャッシュのリソースの一部の更新等キャッシュ制御についての柔軟な処理記述が可能となっている。
なお、サービスワーカー（ＳＷ）自身も更新可能である。サービスワーカー（ＳＷ）は、送信装置２０から提供されるが、このサービスワーカー（ＳＷ）のヘッダ情報（ＨＴＴＰ Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ）に更新日時情報や更新データのアクセス情報等、更新処理に必要となる各種情報が記録され、このヘッダ情報に基づいて更新処理が実行される。
例えば、ヘッダに設定された使用期限等に基づいて、使用期限が来ると、受信装置３０は、新しいバージョンのサービスワーカ（ＳＷ）の取得処理を実行して、キャッシュに格納された旧バージョンのＳＷを置き換える更新処理を行なう。
受信装置３０は、サービスワーカー（ＳＷ）を利用して、任意のタイミングで、例えば図４５、図４６を参照して説明したような天気情報表示アプリケーション等のアプリケーションやプログラム、すなわちサービスワーカ（ＳＷ）の管理対象てあるアプリケーションやプログラムを実行することが可能となる。
［１３．送信装置と受信装置の構成例について］
次に、通信装置である送信装置（サーバ）２０と、受信装置（クライアント）３０の装置構成例について、図４８、図４９を参照して説明する。
図４８には、送信装置（サーバ）２０と、受信装置（クライアント）３０の構成例を示している。
送信装置（サーバ）２０は、データ処理部７５１、通信部７５２、記憶部７５３を有する。
受信装置（クライアント）３０は、データ処理部７７１、通信部７７２、記憶部７７３、入力部７７４、出力部７７５を有する。
送信装置（サーバ）２０のデータ処理部７５１は、データ配信サービスを実行するための各種のデータ処理を実行する。例えばデータ配信サービスの構成データの生成や送信制御を行う。さらに、データ処理部７５１は、受信装置（クライアント）３０に提供するＡＶセグメント、アプリケーション、その他の様々なデータや、シグナリングデータの生成、送信処理を行う。
通信部７５２は、ＡＶセグメントの他、アプリケーション、その他の様々なデータ、シグナリングデータ等の配信等の通信処理を行う。
記憶部７５３は配信対象とするＡＶセグメント、アプリケーション、アプリケーションによって利用されるデータ、シグナリングデータなどが格納される。
さらに、記憶部７５３は、データ処理部７５１の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
送信装置２０の実行する具体的な処理は、例えば、以下の処理である。
データ処理部７５１は、アプリケーション構成データを格納したパケットと、アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータ（ＡＩＴ）を格納したパケット、さらに、アプリケーションの構成要素であるプレゼンテーション・ユニットのデータサイズと、プレゼンテーション・ユニット間のリンク情報を記録した第２シグナリングデータ（Ｓ−ＴＳＩＤ）を格納したパケットなどを生成する。
通信部７５２は、データ処理部７５１の生成したこれらのパケットを送信する処理などを実行する。
一方、受信装置（クライアント）３０は、データ処理部７７１、通信部７７２、記憶部７７３、入力部７７４、出力部７７５を有する。
通信部７７２は、送信装置（サーバ）２０から配信されるデータ、例えばＡＶセグメントやアプリケーション、アプリケーションによって利用されるデータ、シグナリングデータ等を受信する。
データ処理部７７１は、通信データ処理、シグナリングデータ解析処理、データキャッシュ制御処理、再生制御処理、アプリケーション制御処理等、例えば先に説明した実施例に従った処理等を実行する。
具体的には、アプリケーションや、プレゼンテーション・ユニット（ＰＵ）単位のキャッシュ制御、アプリケーションム実行制御等を実行する。
ユーザの指示コマンド、例えばチャンネル選択、アプリケーション起動、アプリケーション遷移等の様々なコマンドは入力部７７４を介して入力される。
再生データは表示部やスピーカ等の出力部７７５に出力される。
記憶部７７３はＡＶセグメント、アプリケーション、アプリケーションによって利用されるデータ、シグナリングデータなどが格納される。
さらに、記憶部７７３は、データ処理部７７１の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
受信装置３０の実行する具体的な処理は、例えば以下の処理である。
通信部７７２は、アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータ（ＡＩＴ）や、アプリケーションの構成要素であるプレゼンテーション・ユニットのデータサイズを記録した第２シグナリングデータ（Ｓ−ＴＳＩＤ）等を受信する。
また、データ処理部７７１は、自装置の記憶部７７３に格納可能なデータサイズであるキャッシュサイズと、第１シグナリングデータ（ＡＩＴ）から取得するリンク関係にある各アプリケーションのデータサイズとを比較して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定し、アプリケーション単位のキャッシュ処理を実行する。
さらに、データ処理部７７１は、キャッシュサイズが、１つのアプリケーションのデータサイズより小さい場合、第２シグナリングデータ（Ｓ−ＴＳＩＤ）を参照し、プレゼンテーション・ユニットのデータサイズと、キャッシュサイズとを比較し、キャッシュサイズ以下の１つ以上のプレゼンテーション・ユニットをキャッシュ対象として決定し、プレゼンテーション・ユニット単位のキャッシュ処理を実行する。
図４９は、送信装置２０、受信装置３０として適用可能な通信装置のハードウェア構成例を示している。
ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）８０１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）８０２、または記憶部８０８に記憶されているプログラムに従って各種の処理を実行するデータ処理部として機能する。例えば、上述した実施例において説明したシーケンスに従った処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）８０３には、ＣＰＵ８０１が実行するプログラムやデータなどが記憶される。これらのＣＰＵ８０１、ＲＯＭ８０２、およびＲＡＭ８０３は、バス８０４により相互に接続されている。
ＣＰＵ８０１はバス８０４を介して入出力インタフェース８０５に接続され、入出力インタフェース８０５には、各種スイッチ、キーボード、マウス、マイクロホンなどよりなる入力部８０６、ディスプレイ、スピーカなどよりなる出力部８０７が接続されている。ＣＰＵ８０１は、入力部８０６から入力される指令に対応して各種の処理を実行し、処理結果を例えば出力部８０７に出力する。
入出力インタフェース８０５に接続されている記憶部８０８は、例えばハードディスク等からなり、ＣＰＵ８０１が実行するプログラムや各種のデータを記憶する。通信部８０９は、インターネットやローカルエリアネットワークなどのネットワークを介したデータ通信の送受信部、さらに放送波の送受信部として機能し、外部の装置と通信する。
入出力インタフェース８０５に接続されているドライブ８１０は、磁気ディスク、光ディスク、光磁気ディスク、あるいはメモリカード等の半導体メモリなどのリムーバブルメディア８１１を駆動し、データの記録あるいは読み取りを実行する。
なお、データの符号化あるいは復号は、データ処理部としてのＣＰＵ８０１の処理として実行可能であるが、符号化処理あるいは復号処理を実行するための専用ハードウェアとしてのコーデックを備えた構成としてもよい。
［１４．本開示の構成のまとめ］
以上、特定の実施例を参照しながら、本開示の実施例について詳解してきた。しかしながら、本開示の要旨を逸脱しない範囲で当業者が実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本開示の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。
なお、本明細書において開示した技術は、以下のような構成をとることができる。
（１） アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを受信する通信部と、
自装置の記憶部に格納可能なデータサイズであるキャッシュサイズと、前記第１シグナリングデータから取得するリンク関係にある各アプリケーションのデータサイズとを比較して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定し、アプリケーション単位のキャッシュ処理を実行するデータ処理部を有する受信装置。
（２） 前記第１シグナリングデータは、
リンク元アプリケーションＩＤと、リンク先アプリケーションＩＤとの対応データを、アプリケーションリンク情報として記録し、
さらに、各アプリケーションＩＤに対応付けてアプリケーションサイズを記録した構成であり、
前記データ処理部は、
前記第１シグナリングデータのアプリケーションリンク情報から、リンク元アプリケーションＩＤと、リンク先アプリケーションＩＤを取得し、
取得した各アプリケーションＩＤに対応して記録されたアプリケーションサイズ情報を取得して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定する（１）に記載の受信装置。
（３） 前記データ処理部は、
リンク関係にある複数のアプリケーションが存在する場合、
初期実行アプリケーションを最優先のキャッシュ対象アプリケーションとして選択し、以下、前記初期実行アプリケーションからのリンクに順に従って、キャッシュ対象アプリケーションを順次、選択する（１）または（２）に記載の受信装置。
（４） 前記アプリケーションＩＤは、組織ＩＤと、アプリケーション本体ＩＤが含まれた識別子である（２）または（３）に記載の受信装置。
（５） 前記第１シグナリングデータは、アプリケーション単位の情報を記録したアプリケーション・インフォーメーション・テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）である（１）〜（４）いずれかに記載の受信装置。
（６） 前記通信部は、
前記第１シグナリナングデータを、放送波を介して受信する（１）〜（５）いずれかに記載の受信装置。
（７） 前記アプリケーションは、広告出力処理を実行するアプリケーションである（１）〜（６）いずれかに記載の受信装置。
（８） 前記受信部は、
アプリケーションの構成要素であるプレゼンテーション・ユニットのデータサイズを記録した第２シグナリングデータを受信し、
前記データ処理部は、
前記キャッシュサイズが、１つのアプリケーションのデータサイズより小さい場合、
前記第２シグナリングデータを参照し、前記プレゼンテーション・ユニットのデータサイズと、前記キャッシュサイズとを比較し、
キャッシュサイズ以下の１つ以上のプレゼンテーション・ユニットをキャッシュ対象として決定し、プレゼンテーション・ユニット単位のキャッシュ処理を実行する（１）〜（７）いずれかに記載の受信装置。
（９） 前記プレゼンテーション・ユニットは、
１つまたは複数のＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書と、該ＨＴＭＬ文書を適用して出力されるデータファイルによって構成されるデータの集合である（８）に記載の受信装置。
（１０） 前記第２シグナリングデータは、
リンク元プレゼンテーション・ユニットＩＤと、リンク先プレゼンテーション・ユニットＩＤとの対応データを、プレゼンテーション・ユニットリンク情報として記録し、
さらに、各プレゼンテーション・ユニットＩＤに対応付けてプレゼンテーション・ユニットサイズを記録した構成であり、
前記データ処理部は、
前記第２シグナリングデータのプレゼンテーション・ユニットリンク情報から、リンク元プレゼンテーション・ユニットＩＤと、リンク先プレゼンテーション・ユニットＩＤを取得し、
取得した各プレゼンテーション・ユニットＩＤに対応して記録されたプレゼンテーション・ユニットサイズ情報を取得して、キャッシュ可能な１つ以上のプレゼンテーション・ユニットをキャッシュ対象アプリケーションとして決定する（８）または（９）に記載の受信装置。
（１１） 前記データ処理部は、
リンク関係にある複数のプレゼンテーション・ユニットが存在する場合、
エントリ文書を含むプレゼンテーション・ユニットを最優先のキャッシュ対象プレゼンテーション・ユニットとして選択し、以下、前記エントリ文書を含むプレゼンテーション・ユニットからのリンクに順に従って、キャッシュ対象プレゼンテーション・ユニットを順次、選択する（８）〜（１０）いずれかに記載の受信装置。
（１２） 前記プレゼンテーション・ユニットＩＤは、プレゼンテーション・ユニットの属するアプリケーションを識別可能としたアプリケーション本体ＩＤと、所属アプリケーション内のプレゼンテーション・ユニットを個別に識別可能としたグループＩＤを含むＩＤである（１０）または（１１）に記載の受信装置。
（１３） 前記第２シグナリングデータは、アプリケーションを構成するプレゼンテーション・ユニットに含まれるファイル単位の情報を記録したＳ−ＴＳＩＤである（８）〜（１１）いずれかに記載の受信装置。
（１４） 前記第２シグナリングデータには、プレゼンテーション・ユニットに含まれるファイル単位の情報が記録され、
ファイル単位情報の各々には、ファイルの属するプレゼンテーション・ユニットに設定されたグループＩＤが対応付けて記録されており、
前記データ処理部は、
グループＩＤに基づいて、キャッシュ対象ファイルの選択処理を実行する（８）〜（１３）いずれかに記載の受信装置。
（１５） 前記通信部は、
前記第２シグナリナングデータを、放送波を介して受信する（８）〜（１４）いずれかに記載の受信装置。
（１６） アプリケーション構成データを格納したパケットと、
前記アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを格納したパケットを生成するデータ処理部と、
前記データ処理部の生成したパケットを送信する通信部と、
を有する送信装置。
（１７） 前記データ処理部は、さらに、
アプリケーションの構成要素であるプレゼンテーション・ユニットのデータサイズと、プレゼンテーション・ユニット間のリンク情報を記録した第２シグナリングデータを格納したパケットを生成し、
前記通信部は、前記第２シグナリングデータを格納したパケットを送信する（１６）に記載の送信装置。
（１８） 前記プレゼンテーション・ユニットは、
１つまたは複数のＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書と、該ＨＴＭＬ文書を適用して出力されるデータファイルによって構成されるデータの集合である（１７）に記載の送信装置。
（１９） 受信装置において実行するデータ処理方法であり、
通信部が、アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを受信し、
データ処理部が、自装置の記憶部に格納可能なデータサイズであるキャッシュサイズと、前記第１シグナリングデータから取得するリンク関係にある各アプリケーションのデータサイズとを比較して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定し、アプリケーション単位のキャッシュ処理を実行するデータ処理方法。
（２０） 送信装置において実行するデータ処理方法であり、
データ処理部が、
アプリケーション構成データを格納したパケットと、
前記アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを格納したパケットを生成し、
通信部が、前記データ処理部の生成したパケットを送信するデータ処理方法。
また、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。例えば、プログラムは記録媒体に予め記録しておくことができる。記録媒体からコンピュータにインストールする他、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介してプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。
なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
以上、説明したように、本開示の一実施例の構成によれば、受信装置において、アプリケーション単位、またはプレゼンテーション・ユニット単位のキャッシュ処理を実行させ、完成度の高いアプリケーション実行処理を可能とする装置、方法が実現される。
具体的には、受信装置が、送信装置からアプリケーションのデータサイズであるアプリケーションサイズと、アプリケーションリンク情報、さらに、アプリケーション構成要素であるプレゼンテーション・ユニット（ＰＵ）各々のデータサイズを記録したシグナリングデータを受信する。受信装置はキャッシュサイズと、アプリケーションや、ＰＵ各々のデータサイズとを比較し、キャッシュ可能なアプリケーション、またはＰＵをキャッシュ対象データとして決定し、アプリケーションまたはＰＵ単位のキャッシュ処理を実行する。
本構成により、受信装置において、アプリケーション単位、またはプレゼンテーション・ユニット単位のキャッシュ処理を実行させ、完成度の高いアプリケーション実行処理を可能とする装置、方法が実現される。
１０ 通信システム
２０ 送信装置
２１ 放送サーバ
２２ 広告サーバ
２３ データ配信サーバ
３０ 受信装置
３１ ＴＶ
３２ ＰＣ
３３ 携帯端末
５０ シグナリングデータ
６０ ＡＶセグメント
７０ その他のデータ
１１０ ミドルウェア
１１１ 通信部（ＰＨＹ／ＭＡＣ）
１１２ シグナリング取得部
１１３ シグナリング解析部
１１４ セグメント取得部
１２０ ＨＴＴＰプロキシサーバ
１２１ キャッシュ制御部
１２２ キャッシュ部
１３０ データ再生部
１３１ 再生制御部
１３２ アプリケーション制御部
１３３ 出力制御部
２００ アプリケーション
２１０ プレゼンテーション・ユニット（ＰＵ）
２１１ ＨＴＭＬファイル
２１２ データファイル
２１３ リンク
２２１ エントリ文書
４５０ ブラウザ
４５１ 表示処理部
４５２ サービスワーカー（ＳＷ）
４５３ キャッシュ
４５５，４５６ Ｗｅｂページ
７５１ データ処理部
７５２ 通信部
７５３ 記憶部
７７１ データ処理部
７７２ 通信部
７７３ 記憶部
７７４ 入力部
７７５ 出力部
８０１ ＣＰＵ
８０２ ＲＯＭ
８０３ ＲＡＭ
８０４ バス
８０５ 入出力インタフェース
８０６ 入力部
８０７ 出力部
８０８ 記憶部
８０９ 通信部
８１０ ドライブ
８１１ リムーバブルメディア

Claims (20)

  1. アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを受信する通信部と、
    自装置の記憶部に格納可能なデータサイズであるキャッシュサイズと、前記第１シグナリングデータから取得するリンク関係にある各アプリケーションのデータサイズとを比較して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定し、アプリケーション単位のキャッシュ処理を実行するデータ処理部を有する受信装置。
  2. 前記第１シグナリングデータは、
    リンク元アプリケーションＩＤと、リンク先アプリケーションＩＤとの対応データを、アプリケーションリンク情報として記録し、
    さらに、各アプリケーションＩＤに対応付けてアプリケーションサイズを記録した構成であり、
    前記データ処理部は、
    前記第１シグナリングデータのアプリケーションリンク情報から、リンク元アプリケーションＩＤと、リンク先アプリケーションＩＤを取得し、
    取得した各アプリケーションＩＤに対応して記録されたアプリケーションサイズ情報を取得して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定する請求項１に記載の受信装置。
  3. 前記データ処理部は、
    リンク関係にある複数のアプリケーションが存在する場合、
    初期実行アプリケーションを最優先のキャッシュ対象アプリケーションとして選択し、以下、前記初期実行アプリケーションからのリンクに順に従って、キャッシュ対象アプリケーションを順次、選択する請求項１に記載の受信装置。
  4. 前記アプリケーションＩＤは、組織ＩＤと、アプリケーション本体ＩＤが含まれた識別子である請求項２に記載の受信装置。
  5. 前記第１シグナリングデータは、アプリケーション単位の情報を記録したアプリケーション・インフォーメーション・テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）である請求項１に記載の受信装置。
  6. 前記通信部は、
    前記第１シグナリナングデータを、放送波を介して受信する請求項１に記載の受信装置。
  7. 前記アプリケーションは、広告出力処理を実行するアプリケーションである請求項１に記載の受信装置。
  8. 前記受信部は、
    アプリケーションの構成要素であるプレゼンテーション・ユニットのデータサイズを記録した第２シグナリングデータを受信し、
    前記データ処理部は、
    前記キャッシュサイズが、１つのアプリケーションのデータサイズより小さい場合、
    前記第２シグナリングデータを参照し、前記プレゼンテーション・ユニットのデータサイズと、前記キャッシュサイズとを比較し、
    キャッシュサイズ以下の１つ以上のプレゼンテーション・ユニットをキャッシュ対象として決定し、プレゼンテーション・ユニット単位のキャッシュ処理を実行する請求項１に記載の受信装置。
  9. 前記プレゼンテーション・ユニットは、
    １つまたは複数のＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書と、該ＨＴＭＬ文書を適用して出力されるデータファイルによって構成されるデータの集合である請求項８に記載の受信装置。
  10. 前記第２シグナリングデータは、
    リンク元プレゼンテーション・ユニットＩＤと、リンク先プレゼンテーション・ユニットＩＤとの対応データを、プレゼンテーション・ユニットリンク情報として記録し、
    さらに、各プレゼンテーション・ユニットＩＤに対応付けてプレゼンテーション・ユニットサイズを記録した構成であり、
    前記データ処理部は、
    前記第２シグナリングデータのプレゼンテーション・ユニットリンク情報から、リンク元プレゼンテーション・ユニットＩＤと、リンク先プレゼンテーション・ユニットＩＤを取得し、
    取得した各プレゼンテーション・ユニットＩＤに対応して記録されたプレゼンテーション・ユニットサイズ情報を取得して、キャッシュ可能な１つ以上のプレゼンテーション・ユニットをキャッシュ対象アプリケーションとして決定する請求項８に記載の受信装置。
  11. 前記データ処理部は、
    リンク関係にある複数のプレゼンテーション・ユニットが存在する場合、
    エントリ文書を含むプレゼンテーション・ユニットを最優先のキャッシュ対象プレゼンテーション・ユニットとして選択し、以下、前記エントリ文書を含むプレゼンテーション・ユニットからのリンクに順に従って、キャッシュ対象プレゼンテーション・ユニットを順次、選択する請求項８に記載の受信装置。
  12. 前記プレゼンテーション・ユニットＩＤは、プレゼンテーション・ユニットの属するアプリケーションを識別可能としたアプリケーション本体ＩＤと、所属アプリケーション内のプレゼンテーション・ユニットを個別に識別可能としたグループＩＤを含むＩＤである請求項１０に記載の受信装置。
  13. 前記第２シグナリングデータは、アプリケーションを構成するプレゼンテーション・ユニットに含まれるファイル単位の情報を記録したＳ−ＴＳＩＤである請求項８に記載の受信装置。
  14. 前記第２シグナリングデータには、プレゼンテーション・ユニットに含まれるファイル単位の情報が記録され、
    ファイル単位情報の各々には、ファイルの属するプレゼンテーション・ユニットに設定されたグループＩＤが対応付けて記録されており、
    前記データ処理部は、
    グループＩＤに基づいて、キャッシュ対象ファイルの選択処理を実行する請求項８に記載の受信装置。
  15. 前記通信部は、
    前記第２シグナリナングデータを、放送波を介して受信する請求項８に記載の受信装置。
  16. アプリケーション構成データを格納したパケットと、
    前記アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを格納したパケットを生成するデータ処理部と、
    前記データ処理部の生成したパケットを送信する通信部と、
    を有する送信装置。
  17. 前記データ処理部は、さらに、
    アプリケーションの構成要素であるプレゼンテーション・ユニットのデータサイズと、プレゼンテーション・ユニット間のリンク情報を記録した第２シグナリングデータを格納したパケットを生成し、
    前記通信部は、前記第２シグナリングデータを格納したパケットを送信する請求項１６に記載の送信装置。
  18. 前記プレゼンテーション・ユニットは、
    １つまたは複数のＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書と、該ＨＴＭＬ文書を適用して出力されるデータファイルによって構成されるデータの集合である請求項１７に記載の送信装置。
  19. 受信装置において実行するデータ処理方法であり、
    通信部が、アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを受信し、
    データ処理部が、自装置の記憶部に格納可能なデータサイズであるキャッシュサイズと、前記第１シグナリングデータから取得するリンク関係にある各アプリケーションのデータサイズとを比較して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定し、アプリケーション単位のキャッシュ処理を実行するデータ処理方法。
  20. 送信装置において実行するデータ処理方法であり、
    データ処理部が、
    アプリケーション構成データを格納したパケットと、
    前記アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを格納したパケットを生成し、
    通信部が、前記データ処理部の生成したパケットを送信するデータ処理方法。
JP2017529533A 2015-07-23 2016-07-04 受信装置、送信装置、およびデータ処理方法 Abandoned JPWO2017014034A1 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2015145494 2015-07-23
JP2015145494 2015-07-23
PCT/JP2016/069752 WO2017014034A1 (ja) 2015-07-23 2016-07-04 受信装置、送信装置、およびデータ処理方法

Publications (1)

Publication Number Publication Date
JPWO2017014034A1 true JPWO2017014034A1 (ja) 2018-05-10

Family

ID=57833882

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017529533A Abandoned JPWO2017014034A1 (ja) 2015-07-23 2016-07-04 受信装置、送信装置、およびデータ処理方法

Country Status (8)

Country Link
US (1) US10820041B2 (ja)
EP (1) EP3327576A4 (ja)
JP (1) JPWO2017014034A1 (ja)
KR (1) KR102611253B1 (ja)
CN (1) CN107851072B (ja)
CA (1) CA2987903A1 (ja)
MX (1) MX2018000649A (ja)
WO (1) WO2017014034A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10938878B2 (en) * 2017-05-16 2021-03-02 Red Hat, Inc. Separate cache servers for storing objects in different dedicated size ranges
CN110891246B (zh) * 2018-09-11 2022-07-05 成都鼎桥通信技术有限公司 一种组播媒体数据的处理方法

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100339842C (zh) * 2002-10-09 2007-09-26 松下电器产业株式会社 信息处理器
JPWO2005076125A1 (ja) * 2004-02-10 2009-05-07 松下電器産業株式会社 プログラム実行装置、プログラム実行方法、及びプログラム
US8272022B2 (en) 2008-11-18 2012-09-18 Lg Electronics Inc. Method for receiving a broadcast signal and broadcast receiver
JP2011087103A (ja) 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供
JP6076248B2 (ja) * 2011-05-20 2017-02-08 日本放送協会 放送通信連携システム、アプリケーション管理サーバー、および、アプリケーション管理サーバーにおけるアプリケーション管理方法
JP6043089B2 (ja) 2011-05-20 2016-12-14 日本放送協会 放送通信連携受信装置
KR101976052B1 (ko) * 2011-08-10 2019-05-08 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 방법 및 방송 서비스 수신 장치
WO2013042902A1 (ko) * 2011-09-23 2013-03-28 엘지전자 주식회사 방송 서비스 수신 방법 및 그 수신 장치
BR112014014585A8 (pt) * 2011-12-21 2017-07-04 Sony Corp aparelho e método de processamento de informação, aparelho de servidor, método de processamento de servidor, e, programa
CA2838471C (en) * 2012-05-10 2020-08-18 Sony Corporation Receiving apparatus, reception method, transmitting apparatus, transmission method, and program
US9154840B2 (en) * 2012-07-31 2015-10-06 Sony Corporation Reception apparatus, reception method, transmission apparatus, and transmission method
JP6348251B2 (ja) 2012-09-13 2018-06-27 サターン ライセンシング エルエルシーＳａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ 端末装置、受信方法、およびプログラム
WO2014057833A1 (ja) * 2012-10-10 2014-04-17 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、及び、プログラム
CN103905147B (zh) * 2012-12-28 2017-03-22 联芯科技有限公司 数据处理方法、发送设备、接收设备和通信系统
JP6118243B2 (ja) * 2013-12-27 2017-04-19 日立マクセル株式会社 放送受信装置及び携帯情報端末
US10798449B2 (en) * 2014-01-07 2020-10-06 Sony Corporation Information processing apparatus and information processing method for validating an application
JP5725235B1 (ja) * 2014-04-22 2015-05-27 ソニー株式会社 受信装置及び受信方法、並びに、送信装置及び送信方法
JP5725242B1 (ja) * 2014-06-04 2015-05-27 ソニー株式会社 送信装置及び送信方法、並びに受信装置並びに受信方法
US20160182977A1 (en) * 2014-12-19 2016-06-23 Telefonaktiebolaget L M Ericsson (Publ) User interaction with advertisements on hybrid terminals

Also Published As

Publication number Publication date
US20180124454A1 (en) 2018-05-03
US10820041B2 (en) 2020-10-27
KR20180034332A (ko) 2018-04-04
CA2987903A1 (en) 2017-01-26
EP3327576A1 (en) 2018-05-30
EP3327576A4 (en) 2018-12-12
WO2017014034A1 (ja) 2017-01-26
MX2018000649A (es) 2018-04-24
KR102611253B1 (ko) 2023-12-08
CN107851072A (zh) 2018-03-27
CN107851072B (zh) 2021-03-12

Similar Documents

Publication Publication Date Title
WO2014084071A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法
JP4904564B2 (ja) コンテンツ配信システム、コンテンツ配信装置、コンテンツ再生端末およびコンテンツ配信方法
JP4878642B2 (ja) コンテンツ配信システム、コンテンツ配信装置、コンテンツ再生端末およびコンテンツ配信方法
JP6583281B2 (ja) 受信装置、送信装置、およびデータ処理方法
WO2016203850A1 (ja) 受信装置、送信装置、およびデータ処理方法
WO2015070796A1 (zh) 智能电视向移动通信终端推送资源的方法和装置
WO2018079295A1 (ja) 情報処理装置、及び、情報処理方法
JPWO2016174960A1 (ja) 受信装置、送信装置、およびデータ処理方法
KR102532046B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
JP6614154B2 (ja) 受信装置、送信装置、およびデータ処理方法
JP6589879B2 (ja) 受信装置、送信装置、およびデータ処理方法
WO2017014034A1 (ja) 受信装置、送信装置、およびデータ処理方法
KR102460444B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
JP6597604B2 (ja) 受信装置、送信装置、データ通信方法、およびデータ処理方法
JPWO2016174959A1 (ja) 受信装置、送信装置、およびデータ処理方法
JP2015165699A (ja) データ配信装置、データ配信方法、データ受信装置およびデータ受信方法
JP2012043466A (ja) データ配信装置、データ配信方法、データ受信装置およびデータ受信方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190621

A762 Written abandonment of application

Free format text: JAPANESE INTERMEDIATE CODE: A762

Effective date: 20200406