JPWO2016067988A1 - 受信装置、送信装置、およびデータ処理方法 - Google Patents
受信装置、送信装置、およびデータ処理方法 Download PDFInfo
- Publication number
- JPWO2016067988A1 JPWO2016067988A1 JP2016556516A JP2016556516A JPWO2016067988A1 JP WO2016067988 A1 JPWO2016067988 A1 JP WO2016067988A1 JP 2016556516 A JP2016556516 A JP 2016556516A JP 2016556516 A JP2016556516 A JP 2016556516A JP WO2016067988 A1 JPWO2016067988 A1 JP WO2016067988A1
- Authority
- JP
- Japan
- Prior art keywords
- data
- service
- token
- service worker
- file
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
- H04H60/14—Arrangements for conditional access to broadcast information or to broadcast-related services
- H04H60/15—Arrangements for conditional access to broadcast information or to broadcast-related services on receiving information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
- H04H60/13—Arrangements for device control affected by the broadcast information
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/907—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
- H04H20/86—Arrangements characterised by the broadcast information itself
- H04H20/91—Arrangements characterised by the broadcast information itself broadcasting computer programmes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/35—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
- H04H60/45—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying users
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
- G06F16/9566—URL specific, e.g. using aliases, detecting broken or misspelled links
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H40/00—Arrangements specially adapted for receiving broadcast information
- H04H40/18—Arrangements characterised by circuits or components specially adapted for receiving
- H04H40/27—Arrangements characterised by circuits or components specially adapted for receiving specially adapted for broadcast systems covered by groups H04H20/53 - H04H20/95
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Multimedia (AREA)
- Library & Information Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Small-Scale Networks (AREA)
Abstract
Description
なお、放送波およびネットワークを介したデータ配信を実現するための技術を開示した従来技術して。例えば特許文献1(特開2014−057227号公報)がある。
ATSC3.0では、ダウンロード型のアプリケーション配信管理用のパッケージング方式、ならびに、オフラインのアプリケーション登録・更新管理方式がまだ検討段階にある。
さらに、具体的には、受信装置(クライアント)の実行環境や記憶容量等の各種リソースの制約を考慮にいれて、受信装置側のユーザの嗜好情報や、記憶域容量他ランタイム環境制約、ローカルネットワーク負荷等のさまざまなクライアント環境属性を参照することにより、きめの細かなキャッシュ対象であるアプリケーション(パーツ)のキャッシュ制御を実現する受信装置、送信装置、およびデータ処理方法を提供することを目的とする。
受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのサービスワーカー(SW)を選択取得して利用するデータ処理部を有する受信装置にある。
受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)を送信する送信装置にある。
受信装置において実行するデータ処理方法であり、
前記受信装置のデータ処理部が、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのサービスワーカー(SW)を選択取得して利用するデータ処理方法にある。
送信装置において実行するデータ処理方法であり、
受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)を送信するデータ処理方法にある。
具体的には、例えば、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのSWを選択取得して利用可能とした。例えば、受信装置におけるアプリケーション利用状況に応じて選択されるクラス対応のSWの利用を実現する。受信装置は、特定クラスのSWのアクセス情報を効率的に検索可能とするためのトークンを記録したシグナリングデータを利用して特定クラスのSWのアクセス情報を取得してSWを取得する。
本構成により、各々の受信装置に最適化したデータ管理を実行するサービスワーカー(SW)の選択取得および利用処理を可能とする装置、方法が実現される。
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。
1.通信システムの構成例について
2.データ通信プロトコルFLUTE、およびROUTEについて
3.送信装置と受信装置の実行する通信処理例について
4.サービスワーカー(SW)について
5.受信装置におけるアプリケーションの取得および実行例について
6.サービスワーカー(SW)のクラス分類と、クラス分類されたサービスワーカー(SW)の選択取得用情報の通知(シグナリング)処理につい
7.サービスワーカー(SW)の配信とキャッシュ制御処理について(ポーリング型の処理例)
7.1.放送ストリーム付随アプリケーションからのサービスワーカー(SW)の取得、登録処理について
7.2.サービスワーカー(SW)に対するクラス設定について
7.3.トークンを適用して特定クラスのサービスワーカー(SW)の取得処理を効率化した構成について
7.4.サービスワーカー(SW)の更新処理について
7.5.サービスワーカー(SW)による受信装置の記憶部(永続キャッシュ)の制御処理について
8.サービスワーカー(SW)の配信とキャッシュ制御処理について(プッシュ型の処理例)
8.1.放送ストリーム付随アプリケーションからのサービスワーカー(SW)の取得、登録処理について
8.2.トークンを適用して受信装置のデータ取得処理を効率化した構成について
8.3.サービスワーカー(SW)の更新処理について
8.4.サービスワーカー(SW)による受信装置の記憶部(永続キャッシュ)の制御処理について
9.トークンを記述するシグナリングデータ(メタデータ)の構成について
9.1.シグナリングデータ(メタデータ)を構成するOMA−ESGに対するトークン記録例について
9.2.シグナリングデータ(メタデータ)を構成するUSDに対するトークン記録例について
9.3.シグナリングデータ(メタデータ)を構成するFLUTE(ROUTE)パラメータレイヤに対するトークン記録例について
10.サービスワーカー(SW)の利用可能なAPIによるキャッシングの最適化処理例について
11.送信装置と受信装置の構成例について
12.本開示の構成のまとめ
まず、図1を参照して本開示の処理を実行する通信システムの一構成例について説明する。
図1に示すように、通信システム10は、画像データや音声データ等のコンテンツを送信する通信装置である送信装置20と、送信装置20の送信するコンテンツを受信する通信装置である受信装置30を有する。
一方、受信装置30は、一般ユーザのクライアント装置であり、具体的には、例えばテレビ31、PC32、携帯端末33等によって構成される。
MPEG−DASH規格には、以下の2つの規格が含まれる。
(a)動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル(MPD:Media Presentation Description)に関する規格、
(b)動画コンテンツ伝送用のファイル・フォーマット(セグメント・フォーマット)に関する規格、
送信装置20から、受信装置30に対するコンテンツ配信は、上記のMPEG−DASH規格に従って実行する。
MPEG−DASH規格に従ってデータ送信を実行する送信装置20は、図2に示すように、大きく分けて以下の複数種類のデータの送信を行う。
(a)シグナリングデータ50
(b)AVセグメント60
(c)その他のデータ(ESG,NRTコンテンツ等)70
受信装置30は、このシグナリングデータ50を、再生対象となる番組コンテンツを格納したAVセグメント60の受信に先行して受信することが必要となる。
このシグナリングデータ50は、例えばXML(Extensible Markup Language)形式のデータとして、スマホやテレビ等のユーザ端末である受信装置(クライアント)に送信される。
これは、受信装置(クライアント)が、いつでも、即座にシグナリングデータを取得することを可能とするためである。
クライアント(受信装置)は、随時、受信可能なシグナリングデータに基づいて、必要な番組コンテンツのアクセス用アドレスの取得や、コーデック設定処理など、番組コンテンツの受信および再生に必要な処理を遅滞なく実行することが可能となる。
ESGは、電子サービスガイド(Electronic Service Guide)であり、例えば番組表等の案内情報である。
NRTコンテンツはノンリアルタイム型のコンテンツである。
後述するアプリケーション等の制御プログラムとして利用されるサービスワーカー(Service Worker)も、NRTコンテンツに含まれる。
(a)シグナリングデータ50
(b)AVセグメント60
(c)その他のデータ(ESG,NRTコンテンツ等)70
これらのデータは、例えば、データ通信プロトコル:FLUTE(File Delivery over Uni−directional Transport)に従って送信される。
データ通信プロトコル:FLUTE(File Delivery over Uni−directional Transport)はマルチキャストにより伝送するコンテンツのセッション管理を行うプロトコルである。
例えば送信装置であるサーバ側で生成されるファイル(URLとバージョンで識別される)は、FLUTEプロトコルに従って、受信装置であるクライアントに送信される。
同じURLでバージョンが異なるものはファイルの中身が更新されているものとみなす。FLUTEプロトコルは一方向ファイル転送制御のみを行うもので、クライアントにおけるファイルの選択的なフィルタリング機能はないが、FLUTEで転送制御するファイルをそのファイルに紐づけられるメタデータを利用して、クライアント側で取捨選択することにより、選択的なフィルタリングを実現し、ユーザの嗜好を反映したローカルキャッシュを構成・更新管理することが可能となる。
なお、メタデータは、FLUTEプロトコルに拡張して組み込むこともできるし、別途ESG(Electronic Service Guide)等のプロトコルで記述することもできる。
次に、送信装置と受信装置の実行する通信処理例について説明する。
図3は、送信装置および受信装置のプロトコルスタックの例を示す図である。
図3に示す例は、以下の2つの通信データの処理を行なうための2つのプロトコルスタックを有する。
(a)ブロードキャスト(マルチキャストも含む)通信(例えば放送型データ配信)
(b)ユニキャスト(ブロードバンド)通信(例えばHTTP型のP2P通信)
図3の右側が、(b)ユニキャスト(ブロードバンド)通信(例えばHTTP型のP2P通信)に対応するプロトコルスタックである。
(1)ブロードキャスト物理レイヤ(Broadcast PHY)
(2)IPマルチキャストレイヤ(IP Multicast)
(3)UDPレイヤ
(4)ROUTE(=拡張型FLUTE)レイヤ
(5)ESG,NRTcontent,DASH(ISO BMFF)およびVideo/Audio/CC
(6)アプリケーションレイヤ(Applications(HTML5))
シグナリングレイヤは、先に図2を参照して説明したシグナリングデータ50の送受信に適用されるレイヤである。シグナリングデータには、番組表等の番組予定情報や、番組取得に必要となるアドレス情報(URL等)、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報(符号化方式など)などからなる案内情報、制御情報などが含まれる。
なお、(1)ブロードキャスト物理レイヤ(Broadcast PHY)の上位レイヤとして将来の新たなプロトコルの利用許容レイヤ(Future Extensibility)が設定されている。
(2)IPマルチキャストレイヤ(IP Multicast)は、IPマルチキャストに従ったデータ送受信処理を実行するレイヤである。
(3)UDPレイヤは、UDPパケットの生成、解析処理レイヤである。
ROUTEは、FLUTEと同様、ALCと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコルであり、具体的にはそのビルディングブロックであるLCTやFECコンポーネントの組み合わせにより構成される。
MBMSやeMBMSは、同報型配信サービスであり、特定のエリア内に位置する受信装置である複数のユーザ端末(UE)に対して共通のベアラで一斉に同一データ、例えば映画コンテンツなどを配信するサービスである。MBMSやeMBMSに従った同報配信により、配信サービス提供エリアに位置する多数のスマホやPC、あるいはテレビ等の受信装置に、同じコンテンツを同時に提供することができる。
(a)シグナリングデータ50
(b)AVセグメント60
(c)その他のデータ(ESG、NRTコンテンツ等)70
これらのデータの多くはROUTEプロトコル、またはFLUTEプロトコルに従って送信される。
前述したように、NRTコンテンツには、例えば、クライアントである受信装置のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。さらに、後述するアプリケーション等の制御プログラムとして利用されるサービスワーカー(Service Worker(SW))も、NRTコンテンツに含まれる。
Video/Audio/CCは、DASH規格に従って配信されるビデオやオディオ等、再生対象となる実データである。
(1)ブロードバンド物理レイヤ(Broaband PHY)
(2)IPユニキャストレイヤ(IP Unicast)
(3)TCPレイヤ
(4)HTTPレイヤ
(5)ESG,Signaling,NRTcontent,DASH(ISO BMFF)およびVideo/Audio/CC
(6)アプリケーションレイヤ(Applications(HTML5))
(2)IPユニキャストレイヤ(IP Unicast)は、IPユニキャスト送受信処理を実行するレイヤである。
(3)HTTPレイヤは、HTTPパケットの生成、解析処理レイヤである。
この上位レイヤは、図3左側の(a)ブロードキャスト通信(例えば放送型データ配信)のスタック構成と同様である。
(a)ブロードキャスト通信(例えば放送型データ配信)
(b)ユニキャスト(ブロードバンド)通信(例えばHTTP型のP2P通信)
これら2つの通信プロトコルスタックの少なくともいずれかに従った処理を行なう。
次に、送信装置(サーバ)20が提供し、主に受信装置(クライアント)30において利用されるサービスワーカー(SW:Service Worker)について説明する。
サービスワーカー(SW)は、放送サーバ21や、データ配信サーバ22等の送信装置20から受信装置に提供される。
あるいは、放送番組を配信するサーバとは別のデータ提供サーバが、サービスワーカー(SW)、アプリケーション、およびアプリケーションの実行時に利用されるデータファイルを受信装置30に提供する構成としてもよい。
図4は、受信装置30が、放送サーバ21等の送信装置20から、ある番組コンテンツを受信し、受信装置30の表示部に表示している状態を示している。
以下では、これらのアプリケーションおよびデータファイルを「リソース」と呼ぶ。
放送サーバ21は、さらに、これらの「リソース」を管理するリソース管理プログラムとして、サービスワーカー(SW)を、やはりNRTコンテンツ(ノンリアルタイムコンテンツ)として受信装置30に提供する。
このような、アプリケーションを利用したデータ表示は、これまでのデータ配信構成では、アプリケーションの提供される番組の終了とともに実行できなくなってしまう。
なお、天気情報表示アプリケーションは、例えばブラウザ上で表示されるプログラムである。
なお、アプリケーション等のリソースを格納する記憶部(永続キャッシュ)は、受信装置30の電源がオフとなっても格納データが消去されない不揮発性メモリとすることが好ましい。
このように、サービスワーカー(SW)を利用することで、様々な番組対応アプリケーションを、番組の表示、非表示と無関係に利用することが可能となる。
サービスワーカー(SW)は、各番組対応の設定とすることもできるが、複数番組を含む特定のチャンネル対応のリソースに対して、共通に利用可能としたサービスワーカー(SW)を設定することもできる。
サービスワーカー(SW)と、サービスワーカー(SW)によって管理されるリソース(アプリケーションおよびアプリ関連データ)は、受信装置30の記憶部(永続キャッシュ)に格納される。
図6には、受信装置30が送信装置20からリソースとしてのWebページ(例えば図4、図5に示す天気情報表示ページ)を取得して受信装置30の記憶部(永続キャッシュ)に格納して利用するシーケンスの一例を示している。
なお、Webページは、所定のWebページ表示アプリケーションと、表示用データによって構成されるリソースを利用して表示される。
図6には、受信装置内出力制御部90の構成要素として表示処理部91、サービスワーカー(SW)92、キャッシュ(記憶部)93を示している。
これは、例えば放送サーバ等の送信するNRTコンテンツから取得される。
この取得処理後、表示処理部91によって、Webページ95が、受信装置30の表示部に表示される。この表示は、このWebページを提供している番組に併せて表示されている状態であり、先に図3を参照して説明した表示状態に相当する。
具体的には、ステップS104に示すようにリソースをキャッシュ93に渡し、記憶部(永続キャッシュ)に格納する処理を行なう。
サービスワーカー(SW)92は、この閲覧要求の入力をフェッチイベントとして検出し、フェッチイベント検出に応じて、ステップS106において、リソース(Webページ)を記憶部(永続キャッシュ)から取得する。
表示処理部91は、ステップS107において、Webページ96を表示する。
Webページ表示プログラムであるブラウザに一種のプロキシサーバが実装され、いつでも、必要なときにプロキシサーバをアクセスしてWebページを取得して表示可能としたイメージである。
例えば、リソースへのアクセスリクエスト(リソースへのフェッチリクエスト)に応じて、ブラウザ側の処理(ローカルキャッシュやネットワークからのリソースの取得)がはじまる前に、サービスワーカー(SW)の処理が開始され、永続キャッシュからのリソースの提供が行われる。
また、サービスワーカー(SW)は、JavaScirpt(登録商標)で提供されるため、さまざまな手続きを組み込むことが可能であり、永続キャッシュのリソースの一部の更新等キャッシュ制御についての柔軟な処理記述が可能となっている。
例えば、ヘッダに設定された使用期限等に基づいて、使用期限が来ると、受信装置30は、新しいバージョンのサービスワーカ(SW)の取得処理を実行して、キャッシュに格納された旧バージョンのSWを置き換える更新処理を行なう。
上述したように、受信装置30は、サービスワーカー(SW)を利用して、任意のタイミングで、例えば図4、図5を参照して説明したような天気情報表示アプリケーション等のアプリケーション、すなわちサービスワーカ(SW)の管理対象てあるアプリケーションを実行することが可能となる。
受信装置30側のユーザは、任意タイミングでアプリケーションを実行することで、天気情報表示ページや、様々なWebページをいつでも閲覧することが可能となる。
図7を参照して、受信装置30におけるアプリケーション実行構成について説明する。
図7に示すように、受信装置30はミドルウェア110、HTTPプロキシサーバ120、出力制御部130を有する。
ミドルウェア110は、通信部(PHY/MAC)111、シグナリングデータを取得するシグナリング取得部112、シグナリングデータを解析するシグナリング解析部113、シグナリングデータ、および、映像、音声等の番組コンテンツデータや、アプリケーション等のNRTコンテンツ等のデータファイルを取得するファイル取得部114を有する。
プロキシサーバ120は、出力制御部130からのデータ要求をアドレス解決部123に入力し、要求されたデータをキャッシュ部(プロキシキャッシュ)121,122、または外部から取得して提供する。
出力制御部130は、表示データ(HTML/JavaScript(登録商標)等)取得&解析部131、表示処理部(Renderer)132を有する。
なお、受信装置30にLAN等のネットワークを介して接続された外部装置150の出力制御部141においてアプリケーション、およびパーツ(HTMLページやJavaScript)を転送して、外部装置140においてアプリケーションを実行することも可能である。
例えば先に図4、図5を参照して説明したように、任意タイミングでアプリケーションを利用した様々なデータ出力を行うことができる。また、出力制御部130は、必要に応じて、サービスワーカー(SW)や、リソース(アプリケーション、およびアプリ関連データ)の更新処理や削除処理などを行う。
例えば、出力制御部130が、アプリケーションを構成するHTMLページもしくはJavaScript(登録商標)の取得を要求すると(HTTPリクエスト)、それを受けたプロキシサーバ120は、アドレス解決部(Broadcast/Broadband Address Resolver)123において放送受信スタックを介して取得するか、ネット経由で取得するかの判断を行う。
シグナリング解析部(Signaling Parser)113は、シグナリング取得部(Signaling Retriever)112に対して、ATSC3.0のシグナリングデータに含まれるメタデータであるUSBD(USD,SDP等)の取得要求を行う。
シグナリング解析部(Signaling Parser)113は、通信部(ATSCチューナー:ATSC3.0PHY/MAC)111を介して放送受信するシグナリングデータ格納LCTパケットによって転送されるシグナリングデータに含まれるメタデータを抽出する。
先に説明したように、サービスワーカー(SW)は、送信装置20から受信装置30に提供され、受信装置(クライアント)30において実行されるアプリケーションや、アプリケーションの実行時に利用されるデータファイル等の取得処理や、記憶部(キャッシュ)に対する格納処理、さらに更新処理、削除処理等を実行するプログラムである。
さらに、サービスワーカー(SW)を適用することで、サービスワーカー(SW)管理データとして設定された新規のあるいは更新されたアプリケーションや、動画、静止画等のデータファイルを、随時取得する処理が可能である。
すなわち、サービスワーカー(SW)は受信装置30において取得可能な様々なデータの取得制御も実現する。
例えば、受信装置におけるデータ処理状況に応じて特定クラスのサービスワーカー(SW)を選択取得して利用する。データ処理状況は、例えば、受信装置におけるアプリケーションまたはデータの利用状況である。
受信装置30は、同時に配信される複数のクラスのサービスワーカー(SW)の中から、受信装置30にとって最適なクラスのサービスワーカ(SW)を選択して取得する。
この処理のためには、例えば受信装置30のブラウザ上で稼働するクライアントアプリケーションが最適なサービスワーカー(SW)を選択して、登録できるようにすることが必要となる。
例えば、シグナリングデータの1つであるUSDを適用してSWのクラス(キャッシングポリシーを反映するクラス)を通知する。
キャッシュ対象のストリームの候補が複数ある場合(高画質、中画質、低画質版等)、高画質版ストリームのみをキャッシュするよう記述されたサービスワーカー(SW)を選択できるようにする。
キャッシュ対象のストリームが、当日の夕方までは、ネット経由の低品質版で配信され、夜まで待つとさらに高画質版が放送配信される場合に、放送配信高画質版をキャッシュするよう記述されたクラスのサービスワーカー(SW)を選択できるようにする。
このケースの場合、ネット経由の低品質版をキャッシュするよう記述されたクラスのサービスワーカー(SW)を選択できるようにする。
なお、クラス分類されたサービスワーカー(SW)を選択取得するためには、シグナリングデータが利用される。
例えば、USD等のシグナリングデータを用いて、サービスワーカー(SW)のクラスを受信装置30に通知し、受信装置30がシグナリングデータに基づいて、自装置に最適なサービスワーカー(SW)を選択取得することで、上記のように、受信装置30側の状況やユーザの嗜好に応じた最適なデータを受信装置30が取得(キャッシング)することが可能となる。
次に、サービスワーカー(SW)の配信とキャッシュ制御処理について説明する。
サービスワーカー(SW)、あるいはサービスワーカー(SW)の管理対象となるアプリケーションやアプリケーションに適用するデータからなるリソースは、例えば受信装置30に実装されたブラウザからの取得要求を契機としてポーリング型で取得処理を行なう構成と、ブラウザからの取得要求に関わらず取得してブラウザに提供するプッシュ型の2つの態様がある。
以下、これらの処理態様、すなわち、
(A)ポーリング型のデータ取得処理例
(B)プッシュ型のデータ取得処理例
上記(A),(B)の2つの処理態様について、順次、説明する。
まず、ポーリング型のデータ取得処理を行なう場合の処理例について説明する。
まず、サービスワーカー(SW)を、送信装置20から受信装置30に送信される放送ストリームに付随するアプリケーションを利用して取得し、登録する処理例について説明する。
例えば、特定の番組の放送ストリームには、アプリケーションを起動するためのURL通知するトリガー情報が含まれ、再生アプリケーションは、このトリガー情報に基づいてアプリケーションを取得するためのURLを取得することができる。
アプリケーションは、このアプリケーション自身を管理対象として設定したサービスワーカー(SW)[SW.js]の取得処理と登録処理を行う。SW.jsのjsはJavaScript(登録商標)を意味する。
図8〜図10には、左から、以下の各構成要素を示している。
(a)送信装置20である放送サーバ
(b)送信装置20であるデータ配信サーバ
(c)受信装置30の構成要素であるミドルウェア
(d)受信装置30の構成要素であるプロキシサーバ
(e)受信装置30の構成要素である出力制御部
なお、図8〜図10の処理シーケンスの開始前に、受信装置30の出力制御部では、ネイティブのストリーム再生アプリケーション、もしくは、ブラウザ上のストリーム再生アプリケーションが起動されているものとする。
まず、受信装置30の構成要素である出力制御部は、放送コンテンツストリームのDASHストリーミングの制御ファイルであるMPDに記述されたコンテンツ格納セグメントのアクセス情報であるセグメントURLを取得して、取得したセグメントURLを用いて放送コンテンツを格納したコンテンツセグメントファイルの取得要求を実行する。
MPEG−DASH規格に従ってデータ送信を実行する送信装置20は、先に図2を参照して説明したように、大きく分けて以下の複数種類のデータの送信を行う。
(a)シグナリングデータ50
(b)AVセグメント60
(c)その他のデータ(ESG,NRTコンテンツ等)70
シグナリングデータ50は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報(URL等)、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報(符号化方式など)などからなる案内情報、制御情報によって構成される。
その他のデータ70は、例えばESG(Electronic Service Guide)、NRTコンテンツ等が含まれる。
ESGは、電子サービスガイド(Electronic Service Guide)であり、例えば番組表等の案内情報である。
NRTコンテンツはノンリアルタイム型のコンテンツである。
NRTコンテンツには、例えば、クライアントである受信装置のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。サービスワーカー(SW)も、NRTコンテンツに含まれる。
次に、受信装置30のプロキシサーバは、ステップS212において、セグメントURLで識別されるコンテンツセグメントファイルがプロキシサーバの管理するキャッシュに格納されていれば、キャッシュからコンテンツセグメントファイルを取得して取得したファイルをレスポンスとして出力制御部に返す。
一方、受信装置30のプロキシサーバは、ステップS213において、セグメントURLで識別されるコンテンツセグメントファイルがプロキシサーバの管理するキャッシュに格納されていないと判定した場合は、コンテンツセグメントファイルの取得要求をミドルウェアに出力する。
ステップS214の処理は、放送サーバ21によって継続的に実行される処理を示している。放送サーバ21は、番組コンテンツの配信に併せて、配信コンテンツに関する制御情報、管理情報等からなるシグナリングデータ(メタデータ等)を受信装置30に継続的に提供する。
ステップS215の処理は、ステップS213において、プロキシサーバからコンテンツセグメントファイルの要求が発生した場合に、ミドルウェアが実行する。
ミドルウェアは、放送サーバ21から受信するシグナリングデータ(メタデータ)に基づいて、プロキシサーバから取得要求のあったコンテンツセグメントファイルが放送によって受信可能か否かを判定し、判定情報をプロキシサーバに通知する。
プロキシサーバは、ミドルウェアからコンテンツセグメントファイルが放送によって受信可能であるとの通知を受けると、セグメントファイルのプロキシサーバ管理キュャッシュへの展開(格納)を待機する。
一方、ミドルウェアからコンテンツセグメントファイルが放送によって受信不可能であるとの通知を受けると、セグメントファイルのネット経由での取得要求をデータ配信サーバ22に対して実行する。
ステップS217〜S218の処理は、プロキシサーバから取得要求のあったコンテンツセグメントファイルが放送によって受信可能である場合に実行される処理である。
この場合、放送サーバ21は、ステップS217において、コンテンツセグメントファイルを放送波によって送信する。
受信装置30のミドルウェアは、ステップS218において、放送サーバ21から送信されたセグメントファイルを受信して、プロキシサーバの管理キャッシュに展開(格納)する。
ステップS219の処理は、プロキシサーバから取得要求のあったコンテンツセグメントファイルが放送によって受信不可能である場合に実行される処理である。
この場合、データ配信サーバ22は、ステップS219において、受信装置30から要求されたコンテンツセグメントファイルを受信装置30に対して送信する。
受信装置30のプロキシサーバは、送信されたセグメントファイルを受信して、プロキシサーバの管理キャッシュに展開(格納)する。
放送サーバ21、またはデータ配信サーバ22から取得されプロキシサーバ管理キャッシュ内に格納されたコンテンツセグメントファイルは、ステップS220において、プロキシサーバから、出力制御部に提供される。
ステップS221において、受信装置30の出力制御部は、プロキシサーバから取得したコンテンツの再生を開始する。
さらに、コンテンツ再生時にコンテンツに含まれるトリガー情報を取得し、トリガー情報に記録されたコンテンツ対応のアプリケーションのアクセス情報であるアプリケーションURLをトリガー情報から取得して、取得したアプリケーションURLを適用したアプリケーション取得要求をプロキシサーバに対して実行する。
ステップS223の処理は、ステップS221において再生中のコンテンツ(例えば放送番組)に対して設定されたアプリケーションの取得と実行処理である。
ステップS223では、ステップS212〜S219の処理(処理(A−1〜2))と同様の処理を、アプリケーションファイルに対して実行する。
すなわち、ステップS212〜S219の処理中に示す「セグメントファイル」を「アプリケーションファイル」に置き換えた処理を実行し、放送サーバ21、またはデータ配信サーバ22からアプリケーションファイルを取得してプロキシサーバの管理キャッシュに格納する。なお、すでにプロキシサーバの管理キャッシュに目的のアプリケーションファイルが展開(格納)されている場合は、新たな取得処理は不要である。
放送サーバ21、またはデータ配信サーバ22から取得されプロキシサーバ管理キャッシュ内に格納されたアプリケーションファイルは、ステップS224において、プロキシサーバから、出力制御部に提供される。
ステップS225において、受信装置30の出力制御部は、プロキシサーバから取得したアプリケーションを実行する。
例えば、番組コンテンツの表示に併せてWebページの表示処理等が実行される。なお、処理内容は、アプリケーションに応じて異なるものであり、必ずしもデータ表示が実行されるとは限らない。
ステップS226の処理は、ステップS225において実行中のアプリケーションの制御の下で実行される処理であり、サービスワーカー(SW)の取得と実行処理である。
ステップS226では、ステップS212〜S219の処理(処理(A−1〜2))と同様の処理を、サービスワーカー(SW)ファイルに対して実行する。
すなわち、ステップS212〜S219の処理中に示す「セグメントファイル」を「サービスワーカーファイル」に置き換えた処理を実行し、放送サーバ21、またはデータ配信サーバ22からサービスワーカーファイルを取得してプロキシサーバの管理キャッシュに格納する。なお、すでにプロキシサーバの管理キャッシュに目的のサービスワーカーファイルが展開(格納)されている場合は、新たな取得処理は不要である。
放送サーバ21、またはデータ配信サーバ22から取得されプロキシサーバ管理キャッシュ内に格納されたサービスワーカーファイルは、ステップS227において、プロキシサーバから、出力制御部に提供される。
ステップS228において、受信装置30の出力制御部は、プロキシサーバから取得したサービスワーカーの登録処理を実行する。
具体的には、サービスワーカー(SW)を記憶部(永続キャッシュ)に格納する処理を実行する。
前述したようにサービスワーカー(SW)をクラス分類して、受信装置において所定クラスのサービスワーカー(SW)を選択取得して適用することにより、例えば、受信装置30側のユーザ嗜好に応じたアプリケーションやデータを取得し実行、再生することが可能となる。
具体的には、例えば、特定のアプリケーションの提供元のチャンネル提供者(放送局)のシグナリングデータのみから目的のファイルURLを探せるようにしておく等の処理である。
この処理には、後述する検索スコープトークンが利用される。
図11〜図12には、左から、以下の各構成要素を示している。
(a)送信装置を構成する放送サーバ
(b)送信装置を構成するデータ配信サーバ
(c)受信装置のミドルウェア
(e)受信装置の出力制御部で実行されるアプリケーション
図11〜図12のシーケンス図に示す各ステップの処理について、順次、説明する。
ステップS251の処理は、受信装置の出力制御部で実行されるアプリケーションによって実行される。
アプリケーションが、サービスワーカー(SW)クラスの設定要求をミドルウェアに対して実行する。
具体的には、例えば図7に示すミドルウェア110のシグナリング解析部113に対して、シグナリングデータに含まれるどのクラスのサービスワーカー(SW)アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部113に検出すべきクラスのサービスワーカー(SW)アクセス情報を判別可能な状態に設定する。
ステップS252〜S253の処理は、受信装置の出力制御部で実行されるアプリケーションおよびサービスワーカーによって実行される。
ミドルウェアに対するサービスワーカー(SW)クラスの設定処理は、ステップS251で説明したように、アプリケーションの処理として実行してもよいが、サービスワーカー(SW)の処理として実行してもよい。
ステップS252〜S253の処理は、ミドルウェアに対するサービスワーカー(SW)クラスの設定処理をサービスワーカー(SW)の処理として実行する場合に行われる。
登録処理によってサービスワーカー(SW)は、記憶部(永続キャッシュ)に格納され、いつでも利用可能な状態になる。
次に、登録されたサービスワーカー(SW)が、サービスワーカー(SW)クラスの設定要求をミドルウェアに対して実行する。
サービスワーカー(SW)クラスの設定は、ステップS251の処理と同様の処理である。すなわち、例えば図7に示すミドルウェア110のシグナリング解析部113に対して、シグナリングデータに含まれるどのクラスのサービスワーカー(SW)アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部113に検出すべきクラスのサービスワーカー(SW)アクセス情報を判別可能な状態に設定する。
ステップS254の処理は、放送サーバによって継続的に実行されているシグナリングデータの送信処理である。
このシグナリングデータには、例えば、様々なクラス対応のサービスワーカー(SW)を取得するためのアクセス情報が記録されている。
ステップS255の処理は、受信装置30のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、アプリケーションまたはサービスワーカー(SW)から通知されたサービスワーカー(SW)クラスを設定し、設定したサービスワーカー(SW)クラスに基づいて、シグナリングデータから設定されたクラスのサービワーカー(SW)のアクセス情報検出を行う。
さらに、受信装置30のミドルウェアは、ステップS256において、シグナリングデータから取得したアクセス情報に基づいて、取得対象ファイルの配信スケジュール情報を取得し、これらを用いたサービスワーカー(SW)格納ファイル取得処理を開始する。
ステップS257の処理は、放送サーバによって継続的に実行されている各種ファイルの送信処理である。
送信ファイルには、アプリケーション、アプリケーション実行時に利用されるデータファイル等のアプリケーション関連データ、さらにサービスワーカー(SW)などが含まれる。
ステップS255の処理は、受信装置30のミドルウェアの処理である。ミドルウェアは、放送サーバの送信ファイルから、取得対象となるファイルを選択取得し、取得ファイルをプロキシサーバの管理キャッシュに展開(格納)する。
次に、受信装置における取得データの取得、選択処理を効率化した構成について説明する。
具体的には、トークンを適用して特定クラスのサービスワーカー(SW)の取得処理を効率化した構成について説明する。
受信装置30は、これらの膨大な数の送信ファイルから、自装置に最適なクラスのサービスワーカー(SW)を選択して取得する必要がある。
サービスワーカー(SW)は、例えばNRTコンテンツとして放送波を介して逐次、送信される。
さらに、サービスワーカー(SW)等のファイルを取得するために必要となるアクセス情報であるファイル対応のURLや各ファイルの送信タイミング情報等がシグナリングデータ(メタデータ)に記録されて受信装置30に提供される。
受信装置30は、シグナリングデータ(メタデータ)を解析して、取得すべきファイルのURLや送信タイミング等を知ることができる。
サービスAの記述を持つメタデータ、
サービスBの記述を持つメタデータ、
サービスCの記述を持つメタデータ、
このようにサービス単位(番組単位やチャンネル単位)のメタデータが記述されている。
さらに、各サービス単位のメタデータは、下位のメタデータとしてファイル転送セッション単位のメタデータを有する。
受信装置30は、このアクセス情報を利用して、先に図7参照して説明したシグナリング解析部113、アドレス解決部123の処理によって取得し、必要なファイルのURLにマッチするファイルアクセス情報を取得して、ファイルを取得することができる。
従って、シナリングデータに記録されたアクセス情報をすべて検索対象として調べる必要があり、検索時間に多大な時間を要することになる。
トークンやURLは、受信装置30の取得予定データに関するアクセス情報(メタデータ)を効率的に検索するための検索補助情報である。
例えば、特定のクラスのサービスワーカー(SW)や、特定のクラスのサービスワーカー(SW)の管理対象となるデータであるリソース(アプリケーションアプリ関連データ)に関するアクセス情報を効率的に検索するための検索補助情報である。
図14に示すように、
サービスAの記述を持つメタデータ、
サービスBの記述を持つメタデータ、
サービスCの記述を持つメタデータ、
このようにサービス単位(番組単位やチャンネル単位)のメタデータが記述されている。
さらに、各サービス単位のメタデータは、下位のメタデータとしてファイル転送セッション単位のメタデータを有する。
また、メタデータ151に含まれる下位のセッション単位のメタデータであるファイル転送セッション2の記述を持つメタデータ152と、ファイル転送セッション3の記述を持つメタデータ154には、トークン<SW−Class>とファイルURLの記述が含まれる。
また、メタデータ151に含まれる下位のセッション単位のメタデータであるファイル転送セッション1の記述を持つメタデータ153には、ファイルURLの記述が含まれる。
これら、<SW−Scope>、<SW−Class>やファイルURLが、受信装置において取得ファイルのアクセス情報を効率化するために適用されるトークンとして記述されるデータである。
「サービスワーカー(SW)検索スコープトークン」
である。
また、メタデータ152に記録されるトークン<SW−Class>は、特定のSWの管理、または更新対象となるファイル(キャッシュ対象ファイル)に関するURL情報がまとめて記録されていることを示すトークンであり、
「サービスワーカー(SW)クラス指定トークン」
である。
なお、これらのトークンは、いずれも特定のサービスワーカー(SW)対応のトークンとして設定されている。
受信装置30は、このトークンの記録されたメタデータを選択し、このメタデータ、およびこのメタデータの下位のメタデータを検索範囲として検索を行えば、受信装置の取得すべきクラスのサービスワーカー(SW)ファイルのアクセス情報を効率的に取得することができる。
すなわち、その他のメタデータを検索対象から除外することが可能となり、検索範囲を限定することで、検索効率を高めることが可能となる。
受信装置30は、このトークンの記録されたメタデータを選択し、このメタデータに記録されたアクセス情報のみを取得すれば、受信装置の取得すべきクラスのサービスワーカー(SW)ファイルのアクセス情報を効率的に取得することができる。
なお、図14に示すように、サービスワーカー(SW)検索スコープトークンを、シグナリングデータのサービス単位の記述パートに配置し、サービスワーカー(SW)クラス指定トークンを、シグナリングデータのファイル転送セッションの記述パートに配置する構成が検索効率を高めるトークン設定例の1つである。
この構成をとることにより、受信装置(クライアント)においてシグナリングデータを受信した場合のアクセス情報取得をより効率的に行うことが可能となる。
図15(1)に示すシグナリングデータ(メタデータ)は、最上位が番組やチャンネル単位で設定されるサービス単位のメタデータ(Service)である。
このサービス単位メタデータの下位にコンテンツ単位のメタデータ(Content)が設定される。
サービス単位のメタデータ(Service)、または、コンテンツ単位のメタデータ(Content)の下位には、配信スケジュールやアクセス情報を記述したメタデータ(Schedule&Access)が設定される。
なお、USDは、例えば配信メソッドに関する情報を格納し、例えば以下のシグナリングデータを含む。
SDP(セッションディスクリプション)
FDD(ファイルデリバリディスクリプション)
RFD(リペアフローディスクリプション)
SD(スケジュールディスクリプション)
さらに、USDは、コンテンツ(AVセグメント)に対応する様々な案内情報、制御情報を格納したマニフェスト・ファイルを持つシグナリングデータとして、
MPD(メディアプレゼンテーションディスクリプション)
を含む。
サービスメタデータ161に、「サービスワーカー(SW)検索スコープトークン<SW−Scope>」を記録している。
受信装置30は、このトークンに従って取得予定クラスのサービスワーカー(SW)ファイルのURLやアクセス情報の検索範囲を限定することができる。すなわち、図の点線枠で示す検索範囲を設定して取得予定ファイルのURLやアクセス情報の検索を行うことができる。
受信装置30は、このトークンに従って、このメタデータ162,163に特定クラスのサービスワーカー(SW)や、管理リソースファイルのURLやアクセス情報が記録されていることを知ることができる。
コンテンツメタデータ164に、「サービスワーカー(SW)検索スコープトークン<SW−Scope>」を記録している。
受信装置30は、このトークンに従って検索範囲を限定することができる。すなわち、図の点線枠で示す検索範囲を設定して取得予定ファイルのURLやアクセス情報の検索を行うことができる。
受信装置30は、このトークンに従って、このメタデータ165に特定クラスのサービスワーカー(SW)や、管理リソースを構成するグループの取得予定ファイルのURLやアクセス情報が記録されていることを知ることができる。
スケジュール&アクセスメタデータ166に、「サービスワーカー(SW)検索スコープトークン<SW−Scope>」を記録している。
受信装置30は、このトークンに従って取得予定クラスのサービスワーカー(SW)ファイルのURLやアクセス情報の検索範囲を限定することができる。すなわち、図の点線枠で示す検索範囲を設定して検索を行うことができる。
受信装置30は、このトークンに従って、このメタデータ167に特定クラスのサービスワーカー(SW)や管理リソースを構成するグループの取得予定ファイルのURLやアクセス情報が記録されていることを知ることができる。
USDメタデータの下位に設定されたスケジュールディスクリプションメタデータ168に、「サービスワーカー(SW)検索スコープトークン<SW−Scope>」を記録している。
受信装置30は、このトークンに従って検索範囲を限定することができる。すなわち、図の点線枠で示す検索範囲を設定して取得予定ファイルのURLやアクセス情報の検索を行うことができる。
受信装置30は、このトークンに従って、このメタデータ169に特定のサービスワーカー(SW)や、管理リソースを構成するグループの取得予定ファイルのURLやアクセス情報が記録されていることを知ることができる。
受信装置30は、例えば、放送データを受信するミドルウェアに、上述した検索範囲の限定や、検索対象ファイルのグループ特定等のフィルタリング処理に適用するトークンを検出するためのトークン検出用のトークン情報を通知(セット)し、セットされたトークン情報に従って、送信装置20から送信されるシグナリングデータを解析してトークンを検出し、検出したトークンを利用した効率的な検索処理を行ない、記憶部(永続キャッシュ)に格納するファイルの取得に必要なURL情報やアクセス情報、配信スケジュール情報等を取得する。なお、シグナリングデータにはファイルURLに併せて、各ファイルの配信スケジュール情報も記録されている。
なお、トークン情報のセット態様としては、以下の設定態様がある。
(1)サービスワーカー(SW)クラス指定トークン(SW−Class)
(2)サービスワーカー(SW)検索スコープトークン(SW−Scope)+)サービスワーカー(SW)クラス指定トークン(SW−Class)
また、特定クラスのサービスワーカー(SW)の管理データであるリソースの選択取得も併せて行う場合は、これらリソースのファイルURLをトークンに併せてパラメータ指定してもよい。
次に、受信装置30に格納されたサービスワーカー(SW)の更新処理について説明する。
受信装置30によって取得されたサービスワーカー(SW)は受信装置の記憶部(永続キャッシュ)に、サービスワーカー(SW)の管理対象となるリソース(アプリケーション、およびアプリ関連データ)とともに格納され、いつでも利用可能な設定となる。
例えば、この取得処理の際に(放送経由の場合もネット経由の場合も)、サービスワーカー(SW)の提供処理に際して送信装置20から受信装置30に対する通信データである「HTTPレスポンスヘッダ:Cache−control」にサービスワーカー(SW)自身の有効期限を指定することができる。
もしくは、ブラウザの設定した一定期限(例えば1日に一回等)がすぎると自動的にサービスワーカー(SW)についてローカルプロキシサーバに対する取得リクエストを行い、中身が更新されていれば再登録する処理がなされる。
図18〜図19には、左から、以下の各構成要素を示している。
(a)送信装置を構成する放送サーバ
(b)送信装置を構成するデータ配信サーバ
(c)受信装置のミドルウェア
(d)受信装置の出力制御部で実行されるブラウザ
さらに、
(e)受信装置の出力制御部で実行されるブラウザ上で実行されるサービスワーカー(SW)
これらの各構成要素を示している。
図18〜図19のシーケンス図に示す各ステップの処理について、順次、説明する。
ステップS271の処理は、放送サーバによって継続的に実行されているシグナリングデータの送信処理である。
このシグナリングデータには、例えば、先に図14〜図17を参照して説明したトークンが設定されている。
ステップS272の処理は、受信装置30のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、アプリケーションまたはサービスワーカー(SW)から通知されたトークン情報を設定し、設定したトークン情報に基づいて、シグナリングデータからのトークン(もしくはファイルURL)検出を実行する。
ステップS273の処理は、放送サーバによって継続的に実行されている各種ファイルの送信処理である。
送信ファイルには、アプリケーション、アプリケーション実行時に利用されるデータファイル等のアプリケーション関連データ、さらにサービスワーカー(SW)などが含まれる。
ステップS274の処理は、受信装置30のミドルウェアの処理である。ミドルウェアは、放送サーバの送信ファイルから、取得対象となるファイルを選択取得し、取得ファイルをプロキシサーバの管理キャッシュに展開(格納)する。
このキャッシュデータには、アプリケーション、アプリケーション実行時に利用されるデータファイル等のアプリケーション関連データ、さらにサービスワーカー(SW)などが含まれる。
サービスワーカー(SW)には、受信装置30が保持しているサービスワーカー(SW)の更新バージョンも含まれる。
ステップS275は、受信装置の出力制御部で実行されるブラウザの処理である。
ブラウザは、受信装置30の記憶部(永続キャッシュ)に格納された複数のサービスワーカー(SW)各々について、有効期限を確認し、有効期限になると自動的にローカルプロキシサーバに対する取得リクエストを行う。
もしくは、ブラウザの設定した一定期限(例えば1日に一回等)がすぎると自動的にサービスワーカー(SW)についてローカルプロキシサーバに対する取得リクエストを行う。
ステップS276の処理は、受信装置30のミドルウェアの処理である。ミドルウェアは、プロキシサーバの管理キャッシュに、ブラウザから取得要求のあった更新されたサービスワーカー(SW)の検索を行い、検出された場合、更新されたサービスワーカー(SW)をブラウザに出力する。
ステップS277は、受信装置の出力制御部で実行されるブラウザの処理である。
ブラウザは、プロキシサーバから受領した更新後のサービスワーカー(SW)を登録する。すなわち、記憶部(永続キャッシュ)に格納する。
ステップS278は、受信装置の出力制御部で実行されるサービスワーカー(SW)の処理である。ここでは、新たに登録された更新後のサービスワーカー(SW)の処理を示している。
更新後のサービスワーカー(SW)は、必要に応じて、トークン情報の設定要求をミドルウェアに対して実行する。
トークン情報の設定は、前述した図11のステップS251の処理と同様の処理である。すなわち、例えば図7に示すミドルウェア110のシグナリング解析部113に対して、シグナリングデータに含まれるどのクラスのサービスワーカー(SW)アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部113に検出すべきクラスのサービスワーカー(SW)のアクセス情報を判別可能な状態に設定する。
ステップS279の処理は、受信装置30のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、更新後のサービスワーカー(SW)から通知されたトークン情報を設定し、設定したトークン情報に基づいて、シグナリングデータからのトークン(もしくはファイルURL)検出を実行する。
次に、受信装置30に格納されたサービスワーカー(SW)による受信装置の記憶部(永続キャッシュ)の制御処理について説明する。
サービスワーカー(SW)によるリソース格納のトリガーとなるイベントを受け取るタイミングは、サービスワーカー(SW)の登録処理、または再登録(更新)処理時である。これらの時点でサービスワーカー(SW)は、登録(install)イベントを受領する。
その他、アプリケーションがHTMLページやJavaScript(登録商標)を要求する時点(フェッチ(fetch)イベントを受領)、あるいは、サービスワーカー(SW)自身が生成したタイマーにより再起動される時点等に上記のリソース格納処理のトリガーとなるイベントを受領する。
図20〜図21には、左から、以下の各構成要素を示している。
(a)送信装置を構成する放送サーバ
(b)送信装置を構成するデータ配信サーバ
(c)受信装置のミドルウェア
(d)受信装置のプロキシサーバ
(e)受信装置の出力制御部で実行されるブラウザの管理下の記憶部(永続キャッシュ)
(f)受信装置の出力制御部の実行するブラウザ上で実行されるサービスワーカー(SW)
(g)受信装置の出力制御部の実行するブラウザ上で実行されるアプリケーション
(h)受信装置の出力制御部で実行されるネィティブアプリケーション
これらの各構成要素を示している。
図20〜図21のシーケンス図に示す各ステップの処理について、順次、説明する。
ステップS301の処理は、ネィティブアプリケーションによるコンテンツ(番組)対応のアプリケーションの起動処理である。
上述したように、ネィティブアプリケーションは、コンテンツ(番組)対応のアプリケーションの起動処理等に用いられるアプリケーションである。
コンテンツ(番組)対応のアプリケーションが、例えば、番組中に埋め込まれたトリガー情報に基づいて起動する設定の場合は、このネィティブアプリケーションによる起動処理は不要である。
ステップS302において、起動されたアプリケーションが、サービスワーカー(SW)の登録処理を実行する。
登録処理によってサービスワーカー(SW)は、記憶部(永続キャッシュ)に格納され、いつでも利用可能な状態になる。
このサービスワーカー(SW)登録処理は、サービスワーカー(SW)自身からは、登録(install)イベントの検出として把握され、サービスワーカー(SW)は、この登録(install)イベント検出を契機として、ステップS303のキャッシュ制御を開始する。
サービスワーカー(SW)は、登録(install)イベントを検出すると、ステップS303において、例えばスクリプト記述に従った記憶部(永続キャッシュ)の制御を開始する。
具体的には、特定クラスのサービスワーカー(SW)、または特定クラスのサービスワーカー(SW)の管理対象となるリソース(アプリケーションや、アプリ関連データ)の取得、キャッシュ展開(格納)処理を開始する。
ステップS304では、先に図8〜図9を参照して説明したリソース送受信処理における図8〜9(A−1〜2)の各ステップのセグメントファイルに対する処理を、リソースに対する処理に置き換えた処理が実行される。
ステップS306において、アプリケーションがアプリケーションパーツ、例えばアプリケーションの実行に必要となる動画ファイルや静止画ファイル、あるいはJavaScript(登録商標)プログラム、音声データ等のアプリ関連データをサービスワーカー(SW)に要求する。
この要求処理は、サービスワーカー(SW)におけるフェッチ(fetch)イベント検出に相当する。
ステップS307〜S309において、サービスワーカー(SW)は、要求されたパーツを記憶部(永続キャッシュ)から取得して、アプリケーションに提供する。
ステップS310〜S311の処理は、サービスワーカー(SW)によるアクティベート(activate)イベント検出時の処理である。
アクティベート(activate)イベントは、例えば、ユーザによるリソースの削除要求の入力が実行された場合、あるいはアプリケーションの有効期限が切れた場合などに検出される。
サービスワーカー(SW)が、アクティベート(activate)イベントを検出すると、例えばスクリプト記述に従った記憶部(永続キャッシュ)の制御を開始する。
具体的には、特定クラスのサービスワーカー(SW)、または特定クラスのサービスワーカー(SW)の管理対象となるリソース(アプリケーションや、アプリ関連データ)の削除処理等を行なう。
ステップS312〜S315の処理は、サービスワーカー(SW)によるタイマーイベント検出時の処理である。
タイマーイベントは、例えば、アプリケーションの有効期限が切れた場合、更新期限がきた場合などに検出される。
タイマーイベントに応じた処理としては、例えばキャッシュリソースの削除、あるいは更新リソースや追加リソースの取得処理などがある。
ステップS314〜S315は、タイマーイベントに応じた更新リソースや追加リソースの取得処理のシーケンスを示している。
なお、ステップS314では、先に図8〜図9を参照して説明したリソース送受信処理における図8〜9(A−1〜2)の各ステップのセグメントファイルに対する処理を、リソースに対する処理に置き換えた処理が実行される。
前述したように、サービスワーカー(SW)、あるいはサービスワーカー(SW)の管理対象となるアプリケーションやアプリケーションに適用するデータからなるリソースは、例えば受信装置30に実装されたブラウザからの取得要求を契機としてポーリング型で取得処理を行なう構成と、ブラウザからの取得要求に関わらず取得してブラウザに提供するプッシュ型の2つの態様がある。
以下、ブラウザからの取得要求に関わらず、サービスワーカ(SW)やその管理リソース(アプリケーション、およびアプリ関連データ)を取得してブラウザに提供するプッシュ型の処理例について説明する。
プッシュ型処理においても、放送サーバ21から提供されるコンテンツ(番組)対応のアプリケーションを利用したサービスワーカー(SW)の取得、登録シーケンスは、先に図8〜図10を参照して説明したポーリング型の処理例と同様の処理となる。
先に図11〜図12を参照して説明したポーリングン型のトークン利用処理では、コンテンツ付随アプリケーション、もしくはサービスワーカー(SW)が、取得すべきリソースやサービスワーカー(SW)を含むファイルをミドルウェアにおいてフィルタリング取得するためのトークン情報(もしくはファイルURL)をセットする処理を実行するものとして説明した。
しかし、トークン情報の設定要求をしたアプリケーションやサービスワーカー(SW)は、プロキシサーバのキャッシュに、トークンに従って選択されたファイルが展開(格納)されたかどうかを受動的に検知することができない。
この処理は、キャッシュ有効期限/タイマー/ポーリング周期等が長いと、プロキシサーバのキャッシュで更新が行われたら即座にブラウザ側に引き込むというような、設定された時間間隔の粒度に依存しないような引き込みタイミング制御ができないという問題がある。
また、タイミング精度を上げるために時間間隔を短くすると、問い合わせ要求が頻繁になり、無駄な負荷を上げることとなる。
このプッシュ型のトークン適用データ選択取得処理シーケンスについて、図22〜図23のシーケンス図を参照して説明する。
(a)送信装置を構成する放送サーバ
(b)送信装置を構成するデータ配信サーバ
(c)受信装置のミドルウェア
(d)受信装置の出力制御部で実行されるサービスワーカー
(e)受信装置の出力制御部で実行されるアプリケーション
図22〜図23のシーケンス図に示す各ステップの処理について、順次、説明する。
ステップS321の処理は、受信装置の出力制御部で実行されるアプリケーションによって実行される。
アプリケーションが、トークン情報の設定要求をミドルウェアに対して実行する。
具体的には、例えば図7に示すミドルウェア110のシグナリング解析部113に対して、シグナリングデータに含まれるどのクラスのサービスワーカー(SW)アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部113に検出すべきクラスのサービスワーカー(SW)のアクセス情報を判別可能な状態に設定する。
具体的には、例えば、サービスワーカー(SW)識別子等をトークン情報として通知し、設定する。
これは、送信装置(放送サーバ、データ配信サーバ)から受信装置に送信されたデータ(アプリケーション、アブリケーション関連データ、サービスワーカ(SW)等)が、ミドルウェアのプロキシサーバ管理キャッシュに展開(格納)された場合に、アプリケーションに通知する処理の実行を各装置または構成部が承諾して実行することを確認する処理である。
ステップS322〜S323の処理は、受信装置の出力制御部で実行されるアプリケーションおよびサービスワーカーによって実行される。
ミドルウェアに対するトークン情報の設定処理は、ステップS321で説明したように、アプリケーションの処理として実行してもよいが、サービスワーカー(SW)の処理として実行してもよい。
ステップS322〜S323の処理は、ミドルウェアに対するトークン情報の設定処理をサービスワーカー(SW)の処理として実行する場合に行われる。
登録処理によってサービスワーカー(SW)は、記憶部(永続キャッシュ)に格納され、いつでも利用可能な状態になる。
次に、登録されたサービスワーカー(SW)が、トークン情報の設定要求をミドルウェアに対して実行する。
トークン情報の設定は、ステップS321の処理と同様の処理である。すなわち、例えば図7に示すミドルウェア110のシグナリング解析部113に対して、シグナリングデータに含まれるどのクラスのサービスワーカー(SW)アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部113に検出すべきクラスのサービスワーカー(SW)のアクセス情報を判別可能な状態に設定する。
これは、送信装置(放送サーバ、データ配信サーバ)から受信装置に送信されたデータ(アプリケーション、アブリケーション関連データ、サービスワーカ(SW)等)が、ミドルウェアのプロキシサーバ管理キャッシュに展開(格納)された場合に、アプリケーションに通知する処理の実行を各装置または構成部が承諾して実行することを確認する処理である。
ステップS324の処理は、放送サーバによって継続的に実行されているシグナリングデータの送信処理である。
このシグナリングデータには、例えば、先に図14〜図17を参照して説明したトークンが設定されている。
ステップS325の処理は、受信装置30のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、アプリケーションまたはサービスワーカー(SW)から通知されたトークン情報を設定し、設定したトークン情報に基づいて、シグナリングデータからのトークン(もしくはファイルURL)検出を実行する。
さらに、受信装置30のミドルウェアは、トークン(もしくはファイルURL)に基づいて、取得対象ファイルを決定し、選択ファイルの配信スケジュール情報に従って、ファイル取得処理を開始する。
ステップS326の処理は、放送サーバによって継続的に実行されている各種ファイルの送信処理である。
送信ファイルには、アプリケーション、アプリケーション実行時に利用されるデータファイル等のアプリケーション関連データ、さらにサービスワーカー(SW)などが含まれる。
ステップS327の処理は、受信装置30のミドルウェアの処理である。ミドルウェアは、放送サーバの送信ファイルから、取得対象となるファイルを選択取得し、取得ファイルをプロキシサーバの管理キャッシュに展開(格納)する。
これは、送信装置(放送サーバ、データ配信サーバ)から受信装置に送信されたデータ(アプリケーション、アブリケーション関連データ、サービスワーカ(SW)等)が、ミドルウェアのプロキシサーバ管理キャッシュに展開(格納)されたことを、アプリケーション、またはサービスワーカー(SW)に通知する処理である。
なお、図には、ステップS328a〜dの4本のイベント通知ラインを示しているが、ステップS328a,bについては、データ送信を実行したいずれかの装置がイベント通知を実行すればよい。
また、ステップS328c,dのミドルウェアからの通知処理は、トークン情報設定要求の発行元、すなわちアプリケーションまたはサービスワーカー(SW)のいずれかのみに対して実行すればよい。
次に、プッシュ型の処理を実行する場合のサービスワーカー(SW)の更新処理について説明する。
前述したように、サービスワーカー(SW)には、利用期限を定めることができ、受信装置30は、必要に応じて、受信装置の保持する利用期限の来たサービスワーカー(SW)を新たなサービスワーカー(SW)に置き換えるサービスワーカー(SW)更新処理を行なうことができる。
プッシュ型処理では、ミドルウェアの管理キャッシュに対して更新サービスワーカー(SW)の展開(格納)が実行された場合に、キャッシュ展開をブラウザ側に通知させるプッシュAPI等を利用したプッシュ型イベント通知機構を利用した処理を行なう。
図24には、左から、以下の各構成要素を示している。
(a)送信装置を構成する放送サーバ
(b)送信装置を構成するデータ配信サーバ
(c)受信装置のミドルウェア
(d)受信装置の出力制御部で実行されるブラウザ
さらに、
(e)受信装置の出力制御部で実行されるブラウザ上で実行されるサービスワーカー(SW)
これらの各構成要素を示している。
図24のシーケンス図に示す各ステップの処理について、順次、説明する。
すなわち、アプリケーション、ミドルウェア間、およびミドルウェアと送信装置(放送サーバ、データ配信サーバ)間において、例えば図22に示すステップS321a,bに示すイベント登録、承諾処理が実行されている。
これは、送信装置(放送サーバ、データ配信サーバ)から受信装置に送信されたデータ(アプリケーション、アブリケーション関連データ、サービスワーカ(SW)等)が、ミドルウェアのプロキシサーバ管理キャッシュに展開(格納)された場合に、アプリケーションに通知する処理の実行を各装置または構成部が承諾して実行することを確認する処理である。
図24のシーケンス図に示す各ステップの処理について、順次、説明する。
ステップS351a〜dは、送信装置(放送サーバ、データ配信サーバ)から受信装置に送信されたデータ(本例では、更新サービスワーカー(SW))が、ミドルウェアのプロキシサーバ管理キャッシュに展開(格納)されたことを、アプリケーション、またはサービスワーカー(SW)に通知する処理である。
なお、図には、ステップS351a〜dの4本のイベント通知ラインを示しているが、ステップS351a,bについては、データ送信を実行したいずれかの装置がイベント通知を実行すればよい。
また、ステップS351c,dのミドルウェアからの通知処理は、アプリケーションまたはサービスワーカー(SW)のいずれかのみに対して実行すればよい。
ステップS352は、受信装置の出力制御部で実行されるブラウザの処理である。
ブラウザは、イベント通知に基づいて、更新サービスワーカー(SW)のローカルプロキシサーバに対する取得リクエストを行う。
ステップS353の処理は、受信装置30のミドルウェアの処理である。ミドルウェアは、プロキシサーバの管理キャッシュに、ブラウザから取得要求のあった更新されたサービスワーカー(SW)の検索を行い、検出された場合、更新されたサービスワーカー(SW)をブラウザに出力する。
ステップS354は、受信装置の出力制御部で実行されるブラウザの処理である。
ブラウザは、プロキシサーバから受領した更新後のサービスワーカー(SW)を登録する。すなわち、記憶部(永続キャッシュ)に格納する。
ステップS355は、受信装置の出力制御部で実行されるサービスワーカー(SW)の処理である。ここでは、新たに登録された更新後のサービスワーカー(SW)の処理を示している。
更新後のサービスワーカー(SW)は、必要に応じて、トークン情報の設定要求をミドルウェアに対して実行する。
トークン情報の設定は、前述した図11のステップS251の処理と同様の処理である。すなわち、例えば図7に示すミドルウェア110のシグナリング解析部113に対して、シグナリングデータに含まれるどのクラスのサービスワーカー(SW)アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部113に検出すべきクラスのサービスワーカー(SW)のアクセス情報を判別可能な状態に設定する。
ステップS356の処理は、受信装置30のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、更新後のサービスワーカー(SW)から通知されたトークン情報を設定し、設定したトークン情報に基づいて、シグナリングデータからのトークン(もしくはファイルURL)検出を実行する。
プッシュ型処理においても、受信装置30に格納されたサービスワーカー(SW)による受信装置の記憶部(永続キャッシュ)の制御処理シーケンスは、先に図20〜図21を参照して説明したポーリング型の処理例と同様の処理となる。
先に、図14〜図17を参照して説明したように、例えば放送サーバ21等の送信装置20から送信されるシグナリングデータ(メタデータ)には、受信装置30における取得データの選択を効率化するためのトークン(もしくはURL)が記述されている。
図25は、例えば放送サーバ21等の送信装置20から送信されるシグナリングデータ(メタデータ)の構成例を示す図である。
(1)サービスレイヤ(OMA−ESG)
(2)ファイル転送セッションレイヤ(3GPP−MBMS−USD)
(3)FLUTE(ROUTE)パラメータレイヤ(FLUTE(ROUTE))
(2)ファイル転送セッションレイヤは、ファイルの転送パラメータ等を記述するレイヤである。
(3)FLUTE(ROUTE)パラメータレイヤは、FLUTE(ROUTE)プロトコル対応のパラメータを記述するレイヤである。
(a)サービス・フラグメント(Service Fragment)
(b)コンテンツ・フラグメント(Content Fragment)
(c)インタラクティビティデータ・フラグメント(InteractivityData Fragment)
(d)スケジュール・フラグメント(Schedule Fragment)
(e)アクセス・フラグメント(Access Fragment)
なお、OMA−ESGには、この他にも複数の属性情報(要素)記録領域(フラグメント)が設定されるが、上記の(a)〜(e)の属性情報(要素)記録領域(フラグメント)を前述したトークンの記録領域として設定した例について、後段で説明する。
例えば(a)サービス・フラグメントから、(d)スケジュール・フラグメントに延びる矢印は、(a)サービス・フラグメントに記録された個々のサービス(例えばチャンネルや番組)対応の配信スケジュール情報が(d)スケジュール・フラグメントに記録されていることを示す。
(f)スケジュール・フラグメント(Schedule Fragment)
(g)フィルタディスクリプション・フラグメント(FilterDescription Fragment)
先に図25を参照して説明したように、
シグナリングデータ(メタデータ)は、図25に示すように、以下の3つのレイヤを持つ。
(1)サービスレイヤ(OMA−ESG)
(2)ファイル転送セッションレイヤ(3GPP−MBMS−USD)
(3)FLUTE(ROUTE)パラメータレイヤ(FLUTE(ROUTE))
サービスレイヤ(OMA−ESG)に設定される属性情報(要素)記録領域(フラグメント)のうちトークンを格納するのにふさわしいフラグメントには、前述したように、以下の属性情報(要素)記録領域(フラグメント)がある。
(a)サービス・フラグメント(Service Fragment)
(b)コンテンツ・フラグメント(Content Fragment)
(c)インタラクティビティデータ・フラグメント(InteractivityData Fragment)
(d)スケジュール・フラグメント(Schedule Fragment)
(e)アクセス・フラグメント(Access Fragment)
(b)コンテンツ・フラグメント(Content Fragment)は、サービス・フラグメント(Service Fragment)を構成する各々のコンテンツ(サービスがチャネルを記述する場合は番組等の単位)を記述するフラグメントである。
例えば、OMAとは異なる標準化団体において、このスキーマ定義を利用して機能要素を追加するために新たな要素が必要となった場合には、この拡張領域下に、様々な要素を追加規定することができる。ただし、OMA自身でスキーマを拡張する場合、もしくは、他の標準化団体自身が全体のスキーマを変更できる場合には追加要素そのものをプライベート・エクステンション(PrivateExtension)要素上に格納するように定義される。
図26に示すように、プライベート・エクステンション(PrivateExtension)データ記録領域201の下位にトークン記録領域202を設定することができる。
トークンのXMLスキーマ定義は、例えば、以下の設定とする。
<xs:element name="SWClass" type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema"/>
上記設定の文字列表現としてエンコードする。
<Service>
・・・
<PrivateExt>
<SWClass>SWクラスの文字列</SWClass>
</PrivateExt>
</Service>
先に図25を参照して説明したように、
シグナリングデータ(メタデータ)は、図25に示すように、以下の3つのレイヤを持つ。
(1)サービスレイヤ(OMA−ESG)
(2)ファイル転送セッションレイヤ(3GPP−MBMS−USD)
(3)FLUTE(ROUTE)パラメータレイヤ(FLUTE(ROUTE))
サービス単位のシグナリングデータであるUSD(ユーザサービスディスクリプション)に設定される属性情報(要素)記録領域(フラグメント)のうちトークンを格納するのにふさわしいフラグメントには、前述したように、以下の属性情報(要素)記録領域(フラグメント)がある。
(f)スケジュール・フラグメント(Schedule Fragment)
(g)フィルタディスクリプション・フラグメント(FilterDescription Fragment)
USD(ユーザサービスディスクリプション)の全体構成例を図27に示す。
USD(ユーザサービスバンドルディスクリプション)210は、複数のUSD(ユーザサービスディスクリプション)211の集合である。
図27に示す白抜きひし形の矢印は、白抜き矢印側の要素が接続要素を含む(include)ことを意味する。
通常矢印は、参照(reference)関係を示す。
スケジュール(Schedule)要素212が設定される。なお、要素は、フラグメントと同意である。
スケジュール(Schedule)要素212の回に、スケジュールディスクリプション(Schedule Description)要素213、さらに、その下意にフィルタディスクリプション(Filter Description)要素214が設定される。
USD(ユーザサービスバンドルディスクリプション)210以下、
USD(ユーザサービスディスクリプション)要素211、
スケジュール(Schedule)要素212
これらの各要素が設定される。
このスケジュールディスクリプションURI 212aに基づいて、スケジュールディスクリプション(Schedule Description)要素213が特定される。
スケジュールディスクリプション(Schedule Description)要素213以下に、アトリビュート(属性)(Attribute)データ222が設定され、アトリビュート(属性)(Attribute)データ222内に、特定のフィルタディスクリプション要素を識別するための識別情報であるフィルタディスクリプションリファレンス(filter Description Reference)223が記録される。
フィルタディスクリプション(filter Description)要素231以下には、各フィルタ対応のデータを設定するフィルタデータ(filterData)要素232が設定される。
さらに、フィルタデータ(filterData)要素232のアトリビュート(属性)(attribute)233には、図29のデータ構成に示すフィルタID(filter ID)225に対応するidデータ234が記録される。
さらに、フィルタデータ(filterData)要素232以下のデータ記録領域に上述したトークン235を記録する。
トークンのXMLスキーマ定義は、例えば、以下の設定とする。
<xs:element name="SWClass" type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema"/>
として、文字列表現としてエンコードする。
<filterDescription>
・・・
<filterData>
<SWClass>SWクラスの文字列</SWClass>
</filterData>
</filterDescription>
受信装置30が、トークンを利用して選択取得するデータは、アプリケーション、およびアプリケーション関連データ、あるいはサービスワーカー(SW)等のファイルであり、これらは、FLUTE/ROUTEプロトコルに従って転送される。
受信装置30は、例えば上述したシグナリングデータであるUSD等に記載されたトークンに基づいて、FLUTE/ROUTEプロトコルに従って転送されるファイルを識別して取得することが必要となる。
以下、この処理のための構成について、図31以下を参照して説明する。
USD(ユーザサービスバンドルディスクリプション)210以下、
USD(ユーザサービスディスクリプション)要素211、
スケジュール(Schedule)要素212
これらの各要素が設定される。
v=・・・
o=・・・
s=・・・
t=・・・
a=ATSC−mode:Frequency PipeID(BBPStreamID) {周波数とその周波数内のmodulation/codingパラメータ等が異なる伝送パイプのID}
a=flute−tsi: (TSI−TransportSessionIdentifier)
s=sourceFilter: IN IP4 IP Address(ソースIPアドレス)
m=APPLICATION port(ポート番号) FLUTE/UDP
c=IN IP4 IPAddress(ディスティネーションIPアドレス)
この情報に従って特定されるファイル特定構成を図33に示す。
FLUTEの場合は、SDPで指示されるソースIPアドレス(SourceIPAddress)、ディスティネーションIPアドレス(DestinationIPAddress)、ポート番号(Port)、TSIにて特定される。これは、FLUTEセッション単位で実行される)。
また、LCTパケットに格納されるTOI(TransportObjectIdentifier)により所望のファイルが特定される。
TOIが0のLCTパケットにはFDT(File Description Table)が格納され、同じTSIで特定されるトランスポートセッションの内の他のファイルオブジェクトについて、各々のファイルURL(FDT−Instance/File/@ContentLocatoinに格納)と、対応するTOI(FDT−Instance/File/@TOIに格納)との関係が解決される。
v=・・・
o=・・・
s=・・・
t=・・・
a=ATSC−mode: Frequency PipeID(BBPStreamID) {周波数とその周波数内のmodulation/codingパラメータ等が異なる伝送パイプのID}
s=sourceFilter: IN IP4 IP Address(ソースIPアドレス)
m=APPLICATION port(ポート番号) ROUTE/UDP
c=IN IP4 IPAddress(ディスティネーションIPアドレス)
この情報に従って特定されるファイル特定構成を図35に示す。
ソースIPアドレス(SourceIPAddress)、ディスティネーションIPアドレス(DestinationIPAddress)がIPパケットの特定に、Port番号がUDPパケットの特定に利用される。
先に図25を参照して説明したように、
シグナリングデータ(メタデータ)は、図25に示すように、以下の3つのレイヤを持つ。
(1)サービスレイヤ(OMA−ESG)
(2)ファイル転送セッションレイヤ(3GPP−MBMS−USD)
(3)FLUTE(ROUTE)パラメータレイヤ(FLUTE(ROUTE))
例えばファイル(File)要素の属性であるコンテンツロケーション(Content−Location)属性に、ファイルURLが格納される。
このFDT−Instance要素の属性、もしくは、File要素の属性にトークンを記録する構成について、図36以下を参照して説明する。
FDTインスタンス(FDT Instance)要素301以下に、
FDTインスタンス対応のアトリビュート(属性)(Attribute)302、
ファイル(File)要素303が設定される。
さらに、ファイル(File)要素303以下に、
ファイル対応のアトリビュート(属性)(Attribute)304が設定される。
ファイル対応のアトリビュート(属性)(Attribute)304、
これらの詳細構成を図37に示す。
このデータ記録フィールド(any)311,312にトークンを記録する。
トークンのXMLスキーマ定義は、例えば、以下の設定とする。
<xs:attribute name="SWClass"type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema"/>
上記設定の文字列表現としてエンコードする。
<FDT−Instance・・SWClass="SWクラスの文字列"・・・>
・・・
</FDT−Instance>
一方、「サービスワーカー(SW)クラス指定トークン<SW−Class>」が配置された場合には、このファイル転送セッションの中のすべてのファイルが所望のサービスワーカー(SW)関連ファイルであることを示す。
<FDT−Instance>
・・・
<File・・・SWClass="SWクラスの文字列"・・・>
・・・
</FDT−Instance>
図38にROUTEで規定しているLSID以下のデータ構成を示す。
図38に示すように、
LSID要素351、
トランスポートセッション(TransportSession)要素352、
ソースフロー(SourceFlow)要素353、
EFDT要素354、
ファイル(File)要素355、
これらの階層設定となる。
(a)EFDT要素354単位のアトリビュート(属性)(Attribute)データ要素361、
(b)ファイル(file)355単位のアトリビュート(属性)(Attribute)データ要素362、
(c)EFDT要素354単位のアプリケーション識別子(ApplicationIdentifier)要素363
これらの各要素が候補となる。
(b)ファイル(File)355単位のアトリビュート(属性)(Attribute)データ要素362、
これらの詳細構成を図39に示す。
このデータ記録フィールド(any)371,372にトークンを記録する。
<LSID>
・・・
<TransportSession>
・・・
<SourceFlow>
・・・
<EFDT … SWClass="SWクラスの文字列"・・・ >
・・・
</EFDT>
・・・
</SourceFlow>
・・・
</TransportSession>
・・・
</LSID>
<LSID>
・・・
<TransportSession>
・・・
<SourceFlow>
・・・
<ApplicationIdentifier>SWクラスの文字列<ApplicationIdentifier>
・・・
</SourceFlow>
・・・
</TransportSession>
・・・
</LSID>
一方、「サービスワーカー(SW)クラス指定トークン<SW−Class>」が配置された場合には、このファイル転送セッションの中のすべてのファイルが所望のサービスワーカー(SW)関連ファイルであることを示す。
<EFDT>
・・・
<File … SWClass="SWクラスの文字列"・・・ >
・・・
</EFDT >
次に、受信装置30において実行するサービスワーカー(SW)の利用可能なAPIによるキャッシングの最適化処理例について説明する。
ひのモデルは、ポリシーの種類が少ない場合には、効果があるが、クライアントの環境に応じた非常にきめの細かな制御を行えるようにする場合には、サービスワーカー(SW)の種類(クラス)が膨大になる恐れがある。この問題に対処するため、サービスワーカー(SW)はできるだけ共通のもの(多くても数種類)を用意して、サービスワーカー(SW)のロジックの中で受信装置(クライアント)の環境属性を取得するAPIを適用してキャッシングの最適化を実現することも可能である。
すなわち、APIを適用してアプリケーション実行環境の状態情報やユーザの視聴情報の統計データ等を参照しながら、キャッシングポリシーを選択できるようにする実装モデルである。
図40〜図41には、左から、以下の各構成要素を示している。
(a)送信装置を構成する放送サーバ
(b)送信装置を構成するデータ配信サーバ
(c)受信装置のミドルウェア
(d)受信装置のプロキシサーバ
(e)受信装置の出力制御部で実行されるブラウザの管理下の記憶部(永続キャッシュ)
(f)受信装置の出力制御部の実行するブラウザ上で実行されるサービスワーカー(SW)
(g)受信装置の出力制御部の実行するブラウザ上で実行されるアプリケーション
(h)受信装置の出力制御部で実行されるネィティブアプリケーション
これらの各構成要素を示している。
図40〜図41のシーケンス図に示す各ステップの処理について、順次、説明する。
ステップS401の処理は、ネィティブアプリケーションによるコンテンツ(番組)対応のアプリケーションの起動処理である。
上述したように、ネィティブアプリケーションは、コンテンツ(番組)対応のアプリケーションの起動処理等に用いられるアプリケーションである。
コンテンツ(番組)対応のアプリケーションが、例えば、番組中に埋め込まれたトリガー情報に基づいて起動する設定の場合は、このネィティブアプリケーションによる起動処理は不要である。
ステップS402において、起動されたアプリケーションが、サービスワーカー(SW)の登録処理を実行する。
登録処理によってサービスワーカー(SW)は、記憶部(永続キャッシュ)に格納され、いつでも利用可能な状態になる。
このサービスワーカー(SW)登録処理は、サービスワーカー(SW)自身からは、登録(install)イベントの検出として把握され、サービスワーカー(SW)は、この登録(install)イベント検出を契機として、ステップS403のキャッシュ制御を開始する。
サービスワーカー(SW)は、登録(install)イベントを検出すると、ステップS403において、例えばスクリプト記述に従った記憶部(永続キャッシュ)の制御を開始する。
具体的には、特定クラスのサービスワーカー(SW)、または特定クラスのサービスワーカー(SW)の管理対象となるリソース(アプリケーションや、アプリ関連データ)の取得、キャッシュ展開(格納)処理を開始する。
APIを適用して得られる最適ファイル選択情報は、例えば、アプリケーション実行環境の状態情報やユーザの視聴情報統計データ等に基づいて得られる情報である。
ステップS404では、先に図8〜図9を参照して説明したリソース送受信処理における図8〜9(A−1〜2)の各ステップのセグメントファイルに対する処理を、リソースに対する処理に置き換えた処理が実行される。
ステップS406において、アプリケーションがアプリケーションパーツ、例えばアプリケーションの実行に必要となる動画ファイルや静止画ファイル、あるいはJavaScript(登録商標)プログラム、音声データ等のアプリ関連データをサービスワーカー(SW)に要求する。
この要求処理は、サービスワーカー(SW)におけるフェッチ(fetch)イベント検出に相当する。
ステップS407〜S409において、サービスワーカー(SW)は、要求されたパーツを記憶部(永続キャッシュ)から取得して、アプリケーションに提供する。
APIを適用して得られる最適ファイル選択情報は、例えば、アプリケーション実行環境の状態情報やユーザの視聴情報統計データ等に基づいて得られる情報である。
ステップS410〜S411の処理は、サービスワーカー(SW)によるアクティベート(activate)イベント検出時の処理である。
アクティベート(activate)イベントは、例えば、ユーザによるリソースの削除要求の入力が実行された場合、あるいはアプリケーションの有効期限が切れた場合などに検出される。
サービスワーカー(SW)が、アクティベート(activate)イベントを検出すると、例えばスクリプト記述に従った記憶部(永続キャッシュ)の制御を開始する。
具体的には、特定クラスのサービスワーカー(SW)、または特定クラスのサービスワーカー(SW)の管理対象となるリソース(アプリケーションや、アプリ関連データ)の削除処理等を行なう。
APIを適用して得られる最適ファイル選択情報は、例えば、アプリケーション実行環境の状態情報やユーザの視聴情報統計データ等に基づいて得られる情報である。
ステップS412〜S415の処理は、サービスワーカー(SW)によるタイマーイベント検出時の処理である。
タイマーイベントは、例えば、アプリケーションの有効期限が切れた場合、更新期限がきた場合などに検出される。
タイマーイベントに応じた処理としては、例えばキャッシュリソースの削除、あるいは更新リソースや追加リソースの取得処理などがある。
APIを適用して得られる最適ファイル選択情報は、例えば、アプリケーション実行環境の状態情報やユーザの視聴情報統計データ等に基づいて得られる情報である。
ステップS414〜S415は、タイマーイベントに応じた更新リソースや追加リソースの取得処理のシーケンスを示している。
なお、ステップS414では、先に図8〜図9を参照して説明したリソース送受信処理における図8〜9(A−1〜2)の各ステップのセグメントファイルに対する処理を、リソースに対する処理に置き換えた処理が実行される。
次に、通信装置である送信装置(サーバ)20と、受信装置(クライアント)30の装置構成例について、図42、図43を参照して説明する。
送信装置(サーバ)20は、データ処理部751、通信部752、記憶部753を有する。
受信装置(クライアント)30は、データ処理部771、通信部772、記憶部773、入力部774、出力部775を有する。
データ処理部には通信データ処理部771a、再生処理部771bが含まれる。
記憶部753は配信対象とするAVセグメント、アプリケーション、サービスワーカー(SW)、アプリケーションによって利用されるデータ、シグナリングデータなどが格納される。
さらに、記憶部753は、データ処理部751の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
通信部772は、送信装置(サーバ)20から配信されるデータ、例えばAVセグメントやアプリケーション、サービスワーカー(SW)、アプリケーションによって利用されるデータ、シグナリングデータ等を受信する。
具体的には、アプリケーションや、API、さらに、サービスワーカー(SW)を利用したデータ処理等を実行する。
再生データは表示部やスピーカ等の出力部775に出力される。
記憶部773はAVセグメント、サービスワーカー(SW)、アプリケーション、アプリケーションによって利用されるデータ、シグナリングデータなどが格納される。
さらに、記憶部773は、データ処理部771の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
以上、特定の実施例を参照しながら、本開示の実施例について詳解してきた。しかしながら、本開示の要旨を逸脱しない範囲で当業者が実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本開示の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。
(1) 受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのサービスワーカー(SW)を選択取得して利用するデータ処理部を有する受信装置。
受信装置におけるデータ処理状況に応じて特定クラスのサービスワーカー(SW)を選択取得する(1)に記載の受信装置。
送信装置の送信するメタデータであるシグナリングデータから、特定クラスのサービスワーカー(SW)のアクセス情報を取得し、取得したアクセス情報を利用して、サービスワーカー(SW)を取得する(1)〜(4)いずれかに記載の受信装置。
前記データ処理部は、
トークンを利用したアクセス情報検索処理を実行する(5)に記載の受信装置。
特定クラスのサービスワーカー(SW)のアクセス情報の検索範囲を限定可能としたサービスワーカー(SW)検索スコープトークンである(6)に記載の受信装置。
(a)ユーザ提示を目的としたサービスまたはコンテンツの属性情報を記述するサービスレイヤ、
(b)ファイル転送パラメータを記述したファイル転送セッションレイヤ、
(c)FLUTE(ROUTE)プロトコル対応のパラメータを記述したFLUTE(ROUTE)パラメータレイヤ、
上記(a)〜(c)のレイヤを有し、
少なくとも(a)〜(c)いずれかのレイヤにトークンが記録された構成である(6)〜(8)いずれかに記載の受信装置。
前記ミドルウェアは、トークン情報設定要求に応じて設定したトークン情報に基づいて、トークン検出を行う(1)〜(10)いずれかに記載の受信装置。
前記ミドルウェアは、トークン情報設定要求に応じて設定したトークン情報に基づいて、トークン検出を行う(1)〜(11)いずれかに記載の受信装置。
特定のサービスワーカー(SW)の管理対象となるデータに対応するアクセス情報の検索処理を効率化するための情報であり、
前記データ処理部は、
前記サービスワーカー(SW)の更新に応じて、前記ミドルウェアに対して、新たなトークン情報の設定要求を行う(12)に記載の受信装置。
受信装置において、特定クラスのサービスワーカー(SW)のアクセス情報を効率的に検索するための検索補助情報であるトークンを記録したメタデータであるシグナリングデータを送信する(14)に記載の送信装置。
特定クラスのサービスワーカー(SW)のアクセス情報の検索範囲を限定可能としたサービスワーカー(SW)検索スコープトークン、または、
特定クラスのサービスワーカー(SW)のアクセス情報が記録されていることを示すサービスワーカー(SW)クラス指定トークンである(15)に記載の送信装置。
前記受信装置のデータ処理部が、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのサービスワーカー(SW)を選択取得して利用するデータ処理方法。
受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)を送信するデータ処理方法。
具体的には、例えば、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのSWを選択取得して利用可能とした。例えば、受信装置におけるアプリケーション利用状況に応じて選択されるクラス対応のSWの利用を実現する。受信装置は、特定クラスのSWのアクセス情報を効率的に検索可能とするためのトークンを記録したシグナリングデータを利用して特定クラスのSWのアクセス情報を取得してSWを取得する。
本構成により、各々の受信装置に最適化したデータ管理を実行するサービスワーカー(SW)の選択取得および利用処理を可能とする装置、方法が実現される。
20 送信装置
21 放送サーバ
22 データ配信サーバ
30 受信装置
31 TV
32 PC
33 携帯端末
50 シグナリングデータ
60 AVセグメント
70 その他のデータ
110 ミドルウェア
111 通信部(PHY/MAC)
112 シグナリング取得部
113 シグナリング解析部
114 ファイル取得部
120 HTTPプロキシサーバ
121,122 キャッシュ部
123 アドレス解決部
130 出力制御部
131 表示データ(HTML/JavaScript(登録商標)等)取得&解析部
132 表示処理部(Renderer)
133 記憶部(永続キャッシュ)
140 外部装置
141 出力制御部
142 記憶部(永続キャッシュ)
751 データ処理部
752 通信部
753 記憶部
771 データ処理部
772 通信部
773 記憶部
774 入力部
775 出力部
801 CPU
802 ROM
803 RAM
804 バス
805 入出力インタフェース
806 入力部
807 出力部
808 記憶部
809 通信部
810 ドライブ
811 リムーバブルメディア
Claims (18)
- 受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのサービスワーカー(SW)を選択取得して利用するデータ処理部を有する受信装置。
- 前記データ処理部は、
受信装置におけるデータ処理状況に応じて特定クラスのサービスワーカー(SW)を選択取得する請求項1に記載の受信装置。 - 前記データ処理状況は、受信装置におけるアプリケーションまたはデータの利用状況である請求項2に記載の受信装置。
- 前記サービスワーカー(SW)は、管理対象データとしてアプリケーション、または画像、または音声、少なくともいずれかのデータファイルを含む請求項1に記載の受信装置。
- 前記データ処理部は、
送信装置の送信するメタデータであるシグナリングデータから、特定クラスのサービスワーカー(SW)のアクセス情報を取得し、取得したアクセス情報を利用して、サービスワーカー(SW)を取得する請求項1に記載の受信装置。 - 前記シグナリングデータには、特定クラスのサービスワーカー(SW)のアクセス情報を効率的に検索するための検索補助情報であるトークンが記録され、
前記データ処理部は、
トークンを利用したアクセス情報検索処理を実行する請求項5に記載の受信装置。 - 前記トークンは、
特定クラスのサービスワーカー(SW)のアクセス情報の検索範囲を限定可能としたサービスワーカー(SW)検索スコープトークンである請求項6に記載の受信装置。 - 前記トークンは、特定クラスのサービスワーカー(SW)のアクセス情報が記録されていることを示すサービスワーカー(SW)クラス指定トークンである請求項6に記載の受信装置。
- 前記シグナリングデータは、
(a)ユーザ提示を目的としたサービスまたはコンテンツの属性情報を記述するサービスレイヤ、
(b)ファイル転送パラメータを記述したファイル転送セッションレイヤ、
(c)FLUTE(ROUTE)プロトコル対応のパラメータを記述したFLUTE(ROUTE)パラメータレイヤ、
上記(a)〜(c)のレイヤを有し、
少なくとも(a)〜(c)いずれかのレイヤにトークンが記録された構成である請求項6に記載の受信装置。 - 前記データ処理部は、前記サービスレイヤ、または、前記ファイル転送セッションレイヤ、または、前記FLUTE(ROUTE)パラメータレイヤに記録されたトークンを取得する請求項9に記載の受信装置。
- 前記受信装置のデータ処理部において実行されるアプリケーションは、受信データの処理を実行するミドルウェアに対して、前記トークンを検出するためのトークン情報の設定要求を実行し、
前記ミドルウェアは、トークン情報設定要求に応じて設定したトークン情報に基づいて、トークン検出を行う請求項1に記載の受信装置。 - 前記受信装置のデータ処理部において実行されるデータ管理プログラムであるサービスワーカー(SW)は、受信データの処理を実行するミドルウェアに対して、前記トークンを検出するためのトークン情報の設定要求を実行し、
前記ミドルウェアは、トークン情報設定要求に応じて設定したトークン情報に基づいて、トークン検出を行う請求項1に記載の受信装置。 - 前記トークンは、
特定のサービスワーカー(SW)の管理対象となるデータに対応するアクセス情報の検索処理を効率化するための情報であり、
前記データ処理部は、
前記サービスワーカー(SW)の更新に応じて、前記ミドルウェアに対して、新たなトークン情報の設定要求を行う請求項12に記載の受信装置。 - 受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)を送信する送信装置。
- 前記送信装置は、
受信装置において、特定クラスのサービスワーカー(SW)のアクセス情報を効率的に検索するための検索補助情報であるトークンを記録したメタデータであるシグナリングデータを送信する請求項14に記載の送信装置。 - 前記トークンは、
特定クラスのサービスワーカー(SW)のアクセス情報の検索範囲を限定可能としたサービスワーカー(SW)検索スコープトークン、または、
特定クラスのサービスワーカー(SW)のアクセス情報が記録されていることを示すサービスワーカー(SW)クラス指定トークンである請求項15に記載の送信装置。 - 受信装置において実行するデータ処理方法であり、
前記受信装置のデータ処理部が、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのサービスワーカー(SW)を選択取得して利用するデータ処理方法。 - 送信装置において実行するデータ処理方法であり、
受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)を送信するデータ処理方法。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014219659 | 2014-10-28 | ||
JP2014219659 | 2014-10-28 | ||
PCT/JP2015/079645 WO2016067988A1 (ja) | 2014-10-28 | 2015-10-21 | 受信装置、送信装置、およびデータ処理方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPWO2016067988A1 true JPWO2016067988A1 (ja) | 2017-08-03 |
JP6583281B2 JP6583281B2 (ja) | 2019-10-02 |
Family
ID=55857329
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016556516A Expired - Fee Related JP6583281B2 (ja) | 2014-10-28 | 2015-10-21 | 受信装置、送信装置、およびデータ処理方法 |
Country Status (8)
Country | Link |
---|---|
US (1) | US10880024B2 (ja) |
EP (1) | EP3214844A4 (ja) |
JP (1) | JP6583281B2 (ja) |
KR (1) | KR102460099B1 (ja) |
CN (1) | CN107113471A (ja) |
CA (1) | CA2964719C (ja) |
MX (1) | MX2017005212A (ja) |
WO (1) | WO2016067988A1 (ja) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180007307A1 (en) * | 2016-07-02 | 2018-01-04 | Qualcomm Incorporated | Distributed Implementation Architecture for Broadcast Receiver |
CN108287737B (zh) * | 2017-07-13 | 2021-08-17 | 阿里巴巴(中国)有限公司 | Service Worker启动方法、装置及电子设备 |
CN109688179B (zh) * | 2017-10-19 | 2021-06-22 | 华为技术有限公司 | 通信方法和通信装置 |
US11064039B2 (en) | 2018-11-14 | 2021-07-13 | Citrix Systems, Inc. | Systems and methods for push notification service for SaaS applications |
CN111417130B (zh) * | 2019-01-07 | 2022-04-08 | 中国移动通信有限公司研究院 | 一种数据处理方法及设备 |
CA3138984A1 (en) | 2019-05-10 | 2020-11-19 | Jt International S.A. | Configuring a personal computing device for communication with an aerosol generation device |
ES2895027T3 (es) | 2019-05-10 | 2022-02-17 | Jt Int Sa | Configuración de un dispositivo informático personal para la comunicación con un dispositivo de generación de aerosol |
US11422829B1 (en) | 2021-11-17 | 2022-08-23 | Morgan Stanley Services Group Inc. | Systems and methods for resilient service worker bridge |
Family Cites Families (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE4446286C1 (de) | 1994-12-23 | 1996-06-20 | Siemens Ag | Responsives System zur Signalverarbeitung sowie Verfahren zur Herstellung eines responsiven Systems |
JP4261895B2 (ja) * | 2002-12-13 | 2009-04-30 | キヤノン株式会社 | デジタル放送受信機及びデジタル放送受信機の制御方法 |
CN101433089B (zh) * | 2006-09-13 | 2011-11-23 | Kddi株式会社 | 广播内容传输装置和广播内容传输方法 |
EP2146528A1 (en) | 2008-07-15 | 2010-01-20 | Gemplus | Method for accessing a service offered from a token, corresponding token and system |
KR101635889B1 (ko) * | 2008-11-18 | 2016-07-05 | 엘지전자 주식회사 | 비실시간 서비스 처리 방법 및 방송 수신기 |
CN102053984A (zh) | 2009-11-10 | 2011-05-11 | 杜卓 | 信息检索查询与信息发布的系统及方法 |
CN103222248B (zh) * | 2010-09-28 | 2016-02-03 | 英国电讯有限公司 | 多类别数据传输的方法和装置 |
TWI545955B (zh) * | 2011-04-28 | 2016-08-11 | Sony Corp | Signal receiving apparatus and method, a signal transmission apparatus and method, and program |
US9151630B2 (en) | 2011-07-05 | 2015-10-06 | Aisin Aw Co., Ltd. | Evaluation indication system, evaluation indication method and computer-readable storage medium |
CA2844605C (en) * | 2011-08-10 | 2016-10-25 | Lg Electronics Inc. | Method for transmitting broadcast service, method for receiving broadcast service, and apparatus for receiving broadcast service |
JP6348251B2 (ja) | 2012-09-13 | 2018-06-27 | サターン ライセンシング エルエルシーSaturn Licensing LLC | 端末装置、受信方法、およびプログラム |
US9264648B2 (en) * | 2012-10-09 | 2016-02-16 | Sony Corporation | Receiving device, receiving method, transmitting device, and transmitting method |
CN104871552B (zh) * | 2012-11-28 | 2018-05-01 | Lg电子株式会社 | 处理交互服务的设备和方法 |
WO2016018077A1 (ko) * | 2014-07-30 | 2016-02-04 | 엘지전자 주식회사 | 방송 전송 장치, 방송 수신 장치, 방송 전송 장치의 동작 방법 및 방송 수신 장치의 동작 방법 |
KR101973469B1 (ko) * | 2014-09-02 | 2019-04-29 | 엘지전자 주식회사 | 방송 수신 장치, 방송 수신 장치의 동작 방법, 방송 수신 장치와 연동하는 연동 장치 및 연동 장치의 동작 방법 |
EP3206392A4 (en) * | 2014-10-12 | 2018-04-04 | LG Electronics Inc. | Device for transmitting broadcast signal, device for receiving broadcast signal, method for transmitting broadcast signal, and method for receiving broadcast signal |
WO2016060410A1 (ko) * | 2014-10-14 | 2016-04-21 | 엘지전자 주식회사 | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 |
JP5880678B2 (ja) | 2014-12-25 | 2016-03-09 | 株式会社三洋物産 | 遊技機 |
US20170209867A1 (en) * | 2016-01-27 | 2017-07-27 | Size Reduction Specialists Corp. | Plastic granulator stationary cutting segment |
-
2015
- 2015-10-21 US US15/520,150 patent/US10880024B2/en active Active
- 2015-10-21 EP EP15854020.3A patent/EP3214844A4/en active Pending
- 2015-10-21 WO PCT/JP2015/079645 patent/WO2016067988A1/ja active Application Filing
- 2015-10-21 MX MX2017005212A patent/MX2017005212A/es unknown
- 2015-10-21 CA CA2964719A patent/CA2964719C/en active Active
- 2015-10-21 JP JP2016556516A patent/JP6583281B2/ja not_active Expired - Fee Related
- 2015-10-21 KR KR1020177010488A patent/KR102460099B1/ko active IP Right Grant
- 2015-10-21 CN CN201580057869.2A patent/CN107113471A/zh active Pending
Also Published As
Publication number | Publication date |
---|---|
JP6583281B2 (ja) | 2019-10-02 |
MX2017005212A (es) | 2017-07-27 |
WO2016067988A1 (ja) | 2016-05-06 |
EP3214844A4 (en) | 2018-05-30 |
US10880024B2 (en) | 2020-12-29 |
KR102460099B1 (ko) | 2022-10-31 |
KR20170074874A (ko) | 2017-06-30 |
EP3214844A1 (en) | 2017-09-06 |
CA2964719A1 (en) | 2016-05-06 |
CN107113471A (zh) | 2017-08-29 |
US20170317773A1 (en) | 2017-11-02 |
CA2964719C (en) | 2023-03-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6583281B2 (ja) | 受信装置、送信装置、およびデータ処理方法 | |
JP6614154B2 (ja) | 受信装置、送信装置、およびデータ処理方法 | |
CN107615774B (zh) | 接收装置、发送装置及数据处理方法 | |
JP6589879B2 (ja) | 受信装置、送信装置、およびデータ処理方法 | |
CA2964712C (en) | Reception device, transmission device, and data processing method | |
KR102611253B1 (ko) | 수신 장치, 송신 장치 및 데이터 처리 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20181019 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20181019 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20190514 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20190709 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20190806 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20190819 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 6583281 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
LAPS | Cancellation because of no payment of annual fees |