JP6739467B2 - 放送信号受信装置および放送信号受信方法 - Google Patents

放送信号受信装置および放送信号受信方法 Download PDF

Info

Publication number
JP6739467B2
JP6739467B2 JP2018083438A JP2018083438A JP6739467B2 JP 6739467 B2 JP6739467 B2 JP 6739467B2 JP 2018083438 A JP2018083438 A JP 2018083438A JP 2018083438 A JP2018083438 A JP 2018083438A JP 6739467 B2 JP6739467 B2 JP 6739467B2
Authority
JP
Japan
Prior art keywords
application
drm
broadcast signal
security management
type
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.)
Active
Application number
JP2018083438A
Other languages
English (en)
Other versions
JP2019193087A (ja
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.)
Toshiba Corp
Original Assignee
Toshiba 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 Toshiba Corp filed Critical Toshiba Corp
Priority to JP2018083438A priority Critical patent/JP6739467B2/ja
Publication of JP2019193087A publication Critical patent/JP2019193087A/ja
Application granted granted Critical
Publication of JP6739467B2 publication Critical patent/JP6739467B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本発明の実施形態は、放送信号受信装置に関する。
放送と通信を融合させたサービスであるハイブリッドキャストは、2013年に放送が開始され、現在では複数の放送局がサービスを提供している。ハイブリッドキャストは、オープンなプラットフォームであるHTML5をアプリケーションエンジンとして採用したことにより、HTML5をサポートする放送信号受信装置やアプリケーションの開発のコストが軽減されるとともに、アプリケーションにおける複雑な処理を放送信号受信装置だけでなくサーバ側と連携して行うことが可能となった。これにより放送通信連携サービスであるハイブリッドキャストの機能の充実が容易に行われるようになった。
HTML5の大きな特徴は、映像や音声を再生する機能であるvideo要素を持ったことである。これにより、それ以前のHTMLにおいて映像や音声の再生において必要であったプレーヤー機能を有するプラグインソフト(機能を追加するためのソフトウェア)のブラウザアプリケーションへの組み込みが不要となり、映像や音声の再生の命令を直接HTMLに記述することが可能となった。
映像や音声を配信する方式としては、映像配信専用サーバを用いたRTSP(Real Time Streaming Protocol)、RTMP(Real Time Messaging Protocol)、MMSP(Microsoft Media Server Protocol)に代わり、ウェブサーバー上のウェブページへのアクセスと同様に、HTTP(Hypertext Transfer Protocol)により映像を配信するHTTPストリーミングが一般的になっている。HTTPストリーミングの例としては,Apple HLS(HTTP Live Streaming),AdobeHDS(HTTP Dynamic Streaming)、Microsoft Smooth Streaming、MPEG−DASHなどがあり、Apple HLSやMPEG−DASHは、HTML5のMedia Source Extentions APIが対応しているブラウザアプリケーションで再生可能である。
「デジタル放送におけるMMTによるメディアトランスポート方式 標準規格」 ARIB STD-B60 1.11版 2018年1月22日改定、一般社団法人 電波産業会 「デジタル放送におけるマルチメディア符号化方式(第2世代)標準規格」 ARIB STD-B62 1.8版 2018年1月22日改定、一般社団法人 電波産業会 「高度広帯域衛星デジタル放送運用規定 技術資料」 ARIB TR-B39 1.6版 2018年1月22日改定、一般社団法人 電波産業会
高度BSデジタル放送および高度広帯域CSデジタル放送における通信による映像・音声を配信するサービスの運用では、通信による伝送を行う方式として、MPEG−DASHによる方式とMMTによる方式が非特許文献1および非特許文献3に規定されている。
MPEG−DASHによる方式は、アプリケーション符号化方式はARIB−HTML5を使用すること、伝送する映像や音声のコンテンツのセキュリティが必要な場合はDRM(Digital Rights Management)を運用することが決められている。従って映像や音声のコンテンツを配信する際にセキュリティが必要な場合は、コンテンツを配信するサービス事業者は、配信する映像または音声のコンテンツに対してDRMを適用する必要があり、放送信号受信装置は適用されたDRMをサポートしている必要がある。
DRMの種類は複数存在するため、放送信号受信装置は、受信装置自身がサポートしている種類のDRMが適用されたコンテンツを配信してもらう必要がある。
放送信号受信装置と映像や音声のコンテンツを配信するサーバが固定されている場合は、予めお互いに決められたDRMが適用されたコンテンツを配信してもらうことで、運用上問題がなかった。
一方で非特許文献1および非特許文献3に記載のデータコンテンツサービスにより、放送信号受信装置は、受信する放送番組に付加されたアプリケーション機能を、新規に追加することが可能である。
データコンテンツサービスにより放送信号受信装置に新規に追加されたアプリケーション機能を用いて映像や音声のコンテンツの配信を運用する場合、追加されたアプリケーションは、放送信号受信装置がサポートしているDRMの種類を把握する必要がある。
しかし現状の放送信号受信装置は、サポートしているDRMの種類をアプリケーションに提供する機能が存在していない、という問題があった。
そこで本発明の実施形態は、サポートしているDRMの種類をアプリケーションに提供する機能を持つ放送信号受信装置および放送信号受信方法を提供することを目的とする。
一実施形態の放送信号受信装置は、
番組を放送する放送波を受信した放送信号から分離される伝送制御信号を解析して、前記伝送制御信号に含まれる、前記番組に付加して特定処理を行うアプリケーションとなるアプリケーションデータに関する制御情報を取得する解析部と、前記制御情報に基づいて、通信ネットワーク上に存在する前記アプリケーションデータの存在場所を特定すると共に、前記アプリケーションの動作を制御するアプリケーション制御と、前記アプリケーション制御が特定した前記通信ネットワーク上の存在場所のアプリケーションデータを受信するアプリケーションデータ受信処理と、前記アプリケーションデータ受信処理が受信したアプリケーションデータからなるアプリケーションを管理し、前記アプリケーション制御部の前記制御により前記アプリケーションに特定処理を動作させるアプリケーションエンジンと、複数の書類のセキュリティ管理情報の内のいずれか一つの適用により保護を受けた少なくとも映像を含むコンテンツを通信により取得するためのコンテンツ受信処理部と、前記複数の種類のセキュリティ管理情報の内の少なくともいずれかをサポートし、サポートする種類のセキュリティ管理情報が適用されるコンテンツだけを処理するセキュリティ管理情報処理部と、を具備し、前記アプリケーションエンジンは、前記セキュリティ管理情報処理部がサポートする前記セキュリティ管理情報の種類の情報を前記アプリケーションに提供し、前記アプリケーションの動作で、前記アプリケーションエンジンから提供されるセキュリティ管理情報の種類の情報の中に前記特定処理を行うための種類が存在しているかの判定を行い(0068)、存在している場合には、その種類のセキュリティ管理情報が適用される前記コンテンツの配信先を決定し(0069)、前記コンテンツ受信処理部を通じて決定した配信先からのコンテンツを取得し(0069)、前記特定処理を行う、放送信号受信装置である。
図1Aは、本実施形態に係る放送信号送信装置、放送信号受信装置およびサービス事業者からなるシステム全体の構成例を示す図である。 図1Bは、本実施形態に係る放送信号送信装置、放送信号受信装置およびサービス事業者からなるシステム全体の他の構成例を示す図である。 図2は、図1Aに示す放送信号送信装置の構成例を概略的に示した図である。 図3は、図1Aに示す放送信号受信装置の構成例を概略的に示した図である。 図4Aは、アプリケーションデータの送信を放送波で行うタイプのデータコンテンツサービスの構成を示す図である。 図4Bは、アプリケーションデータの送信を放送波で行わないタイプのデータコンテンツサービスの構成を示す図である。 図5Aは、放送信号受信装置が、図4Bに示すタイプ2のデータコンテンツサービスによりアプリケーションデータを取得した場合の、映像あるいは音声のコンテンツの配信を受ける様子を示した図である。 図5Bは、放送信号受信装置が、図4Bに示すタイプ2のデータコンテンツサービスによりアプリケーションデータを取得した場合の、映像あるいは音声のコンテンツの配信を受ける様子の他の例を示した図である。 図5Cは、放送信号受信装置が、図4Aに示すタイプ1のデータコンテンツサービスによりアプリケーションデータを取得した場合の、映像あるいは音声のコンテンツの配信を受ける様子を示した図である。 図5Dは、放送信号受信装置が、図4Aに示したタイプ1のデータコンテンツサービスによりアプリケーションデータを取得した場合の、映像あるいは音声のコンテンツの配信を受ける様子の他の例を示した図である。 図5Eは、放送信号受信装置が、図4Bに示すタイプ2のデータコンテンツサービスによりアプリケーションデータを取得した場合の、映像あるいは音声のコンテンツの配信を受ける様子の他の例を示した図である。 図5Fは、放送信号受信装置が、図4Bに示すタイプ2のデータコンテンツサービスによりアプリケーションデータを取得した場合の、映像あるいは音声のコンテンツの配信を受ける様子の他の例を示した図である。 図5Gは、放送信号受信装置140が、図4Bに示すタイプ2のデータコンテンツサービスによりアプリケーションデータを取得した場合の、取得した複数のアプリケーションが、互いに連携して動作する場合の例である。 図5Hは、放送信号受信装置が、図4Aに示すタイプ1のデータコンテンツサービスによりアプリケーションデータを取得した場合の、映像あるいは音声のコンテンツの配信を受ける様子の他の例を示した図である。 図5Iは、放送信号受信装置が、セキュリティ管理情報処理部がサポートするDRMの種類をアプリケーションに提供する処理がない場合の、映像あるいは音声のコンテンツの配信を受ける様子の例を示した図である。 図6は、放送信号受信装置のセキュリティ管理情報処理部がサポートするDRMの種類をアプリケーションに提供するために、Capabilitiesオブジェクトを拡張した例である。 図7は、図6に示した、セキュリティ管理情報処理部がサポートするDRMの種類をアプリケーションに提供するために機能を用いた場合の、処理フローの例を示した図である。 図8Aは、図6に示した、セキュリティ管理情報処理部がサポートするDRMの種類をアプリケーションに提供するために機能を用いた場合の、処理フローの他の例を示した図である。 図8Bは、アプリケーションFが、セキュリティ管理情報処理部がサポートするDRMの種類を、C1システム(DRM−3)、A1システム(DRM−1)の順に判定した場合の処理フローの例を示した図である。 図8Cは、特定処理の一例を示す処理フローの例を示した図である。
以下、実施の形態について図面を参照して説明する。
図1Aは、本実施形態に係る放送信号送信装置、放送信号受信装置およびサービス事業者からなるシステム全体の構成例を示す図である。
100は、放送信号により番組を放送する放送信号送信装置A(放送局Aと呼んでもよい)である。放送信号送信装置A100は、放送番組サーバ101、放送信号送信基本機能102、アプリケーションデータ管理部103を備える。
101は、放送信号送信装置100として放送する番組、番組タイトル、番組概要、出演者名、放送日時、その他のデータ等を予め保存しておく放送番組サーバである。
102は、放送信号送信装置A100の基本的な機能であり、放送する番組の映像信号や音声信号等を符号化(エンコードとも言う)し、映像信号や音声信号の制御情報である伝送制御信号等と多重化し、放送信号として送出する機能を持つ放送信号送信基本機能である。
また放送信号送信装置A100は、非特許文献3に記載の、HTML5等で符号化されたアプリケーション機能を、放送する番組と同時に提供するデータコンテンツサービスを付加することができる。この場合放送信号送信装置100は、放送する番組にアプリケーション機能が付加されていることを示す第1の指定情報を伝送制御信号に配置し、放送信号送信基本機能102より放送信号として送出する。第1の指定情報は、例えば非特許文献1に記載のMPT(MMT Package Table)の中に配置されるアプリケーションサービス記述子である。
103は、放送番組にデータコンテンツサービスが付加されている場合、放送番組に付加するアプリケーション機能(アプリケーションデータ)の生成や管理を行うアプリケーション管理部である。
なおデータコンテンツサービスは、放送番組に付加するアプリケーション機能(アプリケーションデータ)を、放送波により提供する方法と、放送波により提供せずに通信により提供する方法の2通りの方法がある。放送番組に付加するアプリケーション機能(アプリケーションデータ)を通信により提供する場合は、サービス事業者120により行われる。データコンテンツサービスの構成は、図4Aおよび図4Bを用いて説明する。
放送信号送信装置は、複数存在してもよい。図1Aの例は、放送信号送信装置が放送信号A100と放送信号送信装置B100−2の2つが存在する例である。
120は、放送信号送信装置A100が放送する番組にデータコンテンツサービスが付加されている場合、放送信号送信装置100と連携して放送番組に付加するHTML5等で符号化されたアプリケーション機能(アプリケーションデータ)を、ネットワーク180を介して放送信号受信装置140に提供するサービス事業者である。
サービス事業者120は、アプリケーションデータ管理部121とアプリケーションサーバ122を含む。
121は、放送番組に付加するアプリケーション機能(アプリケーションデータ)の生成や管理を行い、生成したアプリケーション機能(アプリケーションデータ)を、ネットワーク180を介して放送信号受信装置140に配布するアプリケーションデータ管理部である。
122は、アプリケーションデータ管理部121で生成された、放送番組に付加するアプリケーション機能(アプリケーションデータ)を保存するアプリケーションサーバである。
サービス事業者120は、第1の指定情報を受信した放送信号受信装置140からの要求に対応して、アプリケーションサーバ122に保存してあるアプリケーション機能(アプリケーションデータ)を、アプリケーションデータ管理部121によりネットワーク180を介して放送信号受信装置140に送信する。
またサービス事業者A120は、アプリケーションサーバ122に、放送信号受信装置140に配信する映像や音声のコンテンツを保存していてもよい。サービス事業者120は、放送信号受信装置140からの要求に応じて、アプリケーションサーバ122に保存してある映像や音声のコンテンツを、アプリケーションデータ管理部121によりネットワーク180を介して放送信号受信装置140に配布してもよい。
サービス事業者は、複数存在してもよい。図1Aの例は、サービス事業者がサービス事業者A120とサービス事業者B120−2の2つが存在する例である。
140は、放送信号により送られてくる番組を受信する放送信号受信装置(テレビジョン受信装置と呼んでもよい)である。放送信号受信装置140は、放送信号受信基本機能141、通信制御機能142、アプリケーション制御機能143、端末連携機能144を含む。
141は、放送信号受信装置としての基本的な機能であり、放送信号送信装置A100から送られてくる放送波を受信し、放送波に含まれる符号化された映像信号(映像ストリームとも呼ぶ)、符号化された音声信号(音声ストリームとも呼ぶ)、アプリケーションデータおよび伝送制御信号を分離し、映像信号および音声信号をデコードしたり、アプリケーションデータを受信したり、伝送制御信号を解析したりする放送信号受信基本機能である。
また放送信号受信基本機能141は、放送信号受信装置140に接続されている周辺機器、例えば表示器(表示画面と呼んでもよい)160、スピーカ161、放送信号受信装置140にバインドされているHDD(Hrad Disk Drive)162、リムーバルメディア170、との接続やデータの送受信の管理も行う。表示器160は、スピーカ161を内蔵しており、放送信号受信基本機能141においてデコードされた映像信号を表示領域に表示したり、音声信号をスピーカ161に出力したりする。なお、表示器160に内蔵されているスピーカ161は、USB等のI/Fにより接続した外部のスピーカであってもよい。また図1の例では表示器160は、放送信号受信装置140と別体として記載しているが、放送信号受信装置140の1機能として放送信号受信装置140と一体であってもよい。
142は、放送信号受信装置140がネットワーク180を介してサービス事業者A120と通信を行うための通信制御機能である。
143は、データコンテンツサービスにより付加されたアプリケーションの管理や実行を行うアプリケーション制御機能である。またアプリケーション制御機能143は、放送信号受信装置140にもともと備わっているアプリケーション機能の管理や実行も行う。
144は、放送信号受信装置140が携帯端末175と連携して、映像や音声のサービスを行う携帯端末連携機能である。放送信号受信装置140と携帯端末175は、例えばBlueTooth(登録商標)等の近距離無線システムにより接続されている。
また映像や音声のコンテンツの配布だけを行うコンテンツサービス事業者が存在していてもよい。
図1Bは、本実施形態に係る放送信号送信装置、放送信号受信装置およびサービス事業者からなるシステム全体の他の構成例を示す図である。図1Aに示す放送信号送信装置A100、放送信号送信装置B100−2、サービス事業者A120、サービス事業者B120−2、放送信号受信装置140に加え、映像や音声のコンテンツの配布だけを行うコンテンツサービス事業者X127からなる。放送信号受信装置140は、映像や音声のコンテンツの配布を、コンテンツサービス事業者X127に要求してもよい。
図2は、図1Aに示す放送信号送信装置A100の構成の例を概略的に示した図である。放送信号送信基本機能102は、映像エンコーダ201、音声エンコーダ202、字幕エンコーダ203、アプリケーションデータ生成部204および伝送制御信号を生成する制御信号生成部205を含む。
201は、放送する番組として放送番組サーバ101から読み出された番組Aの映像のエンコードを行う映像エンコーダである。なお映像エンコーダ201のコーデック種別は、MPEG−2、H.264(AVC:Advance Video Coding)、H.265(HEVC:High Efficiency Video Coding)のいずれでもよいものとする。またコーデック種別は、これに限るものではない。
202は、放送する番組として放送番組サーバ101から読み出した番組Aの音声のエンコードを行う音声エンコーダである。
203は、放送する番組として放送番組サーバ101から読み出した番組Aの字幕のエンコードを行う字幕エンコーダである。
204は、放送する番組として放送番組サーバ101から読み出した番組AにHTML5等のアプリケーション機能(アプリケーションデータ)を同時に提供するサービスを付加する場合に、アプリケーションデータ管理部103に管理されているアプリケーション機能(アプリケーションデータ)を読み出し放送波として送信できるようにアプリケーションデータを生成するアプリケーションデータ生成部である。
205は、放送信号送信装置A100が放送する番組を構成している映像ストリーム、音声ストリーム、等番組を構成している放送信号に関する制御情報や放送する番組の番組名称や放送時間等番組の内容に関する制御情報である伝送制御信号を生成する制御信号生成部である。
制御信号生成部205は、アプリケーションデータ生成部204が生成した番組に付加するアプリケーション機能に関する伝送制御信号も生成する。
207は、映像エンコーダ201が出力する映像データ、音声エンコーダ202が出力する音声データ、字幕エンコーダ203が出力する字幕データ、アプリケーション生成部204が出力するアプリケーションデータ、制御信号生成部205が出力する伝送制御信号を多重化する多重化部である。多重化部207が多重化する多重化方式は、非特許文献1に記載のMMT(Mpeg Media Transport)方式とする。
208は、多重化部207から入力された多重化ストリームをスクランブルするスクランブラである。多重化部207は、スクランブルした多重化ストリームを送信機209に送信する。
209は、送られてきた多重化ストリームを、放送波によりアンテナから送信する送信機である。
図3は、図1の放送信号受信装置140の構成例を概略的に示した図である。放送信号受信装置140は、放送信号受信基本機能141、通信制御機能142、アプリケーション制御機能143、端末連携機能144を含む。また放送信号受信装置140は、表示器160およびスピーカ161とも接続している。
放送信号受信基本機能141は、放送チューナ301、デスクランブラ302、デマルチプレクサA303、映像デコーダA305、音声デコーダA306、字幕デコーダA307、アプリケーションデータ受信処理部A308、制御信号解析部309を含む。
301は、放送波で送られてきたストリーム(放送信号)を復調する放送チューナである。放送チューナ301は、復調したストリーム(放送信号)を、デスクランブラ302に入力する。
302は、放送チューナ301から入力された多重化されているストリームを、デスクランブルするデスクランブラである。デスクランブラ304は、デスクランブルしたストリームを、デマルチプレクサA303に入力する。
303は、デスクランブラ302から入力されたストリームを、映像ストリーム、音声ストリーム、字幕ストリーム、アプリケーションデータ、伝送制御信号に分離するデマルチプレクサである。デマルチプレクサA303は、映像ストリームを映像デコーダA305に、音声ストリームを音声デコーダA306に、字幕ストリームを字幕デコーダA307に、アプリケーションデータをアプリケーションデータ受信処理部A308に、伝送制御信号を制御信号解析部309に入力する。
305は、デマルチプレクサA303から送られてきた映像データをデコードする映像デコーダAである。
306は、デマルチプレクサA303から送られてきた音声データをデコードする音声デコーダAである。
307は、デマルチプレクサA303から送られてきた字幕データをデコードする字幕デコーダAである。
308は、デマルチプレクサA303から送られてきたアプリケーションデータの受信処理をするアプリケーションデータ受信処理部Aである。
309は、デマルチプレクサA303から送られてきた伝送制御信号を処理する制御信号解析部である。制御信号解析部309は、解析した伝送制御信号の中から抽出した、アプリケーションデータに関する制御情報であるMH−AIT(MH-Application Information Table)等を、アプリケーション制御部320に送る。
デコードされた映像データおよび字幕は、合成器310で合成され表示器160に出力される。またデコードされた音声データは、スピーカ161に出力される。
なお、映像デコーダ306のコーデック種別は、H.265とするが、これに限定されるものではなく、MPEG−2、H.264のいずれでもよい。またコーデック種別は、これに限るものではない。
通信制御機能142は、ネットワーク180とのI/Fである通信I/F330、サービス事業者A120、サービス事業者B120−2あるいはコンテンツサービス事業者X127から配信される映像あるいは音声のコンテンツを受信するためのコンテンツ受信処理部331、デマルチプレクサB332、配信される映像あるいは音声のコンテンツに適用された例えばDRM(Digital Rights Management)等コンテンツ保護の処理を行うセキュリティ管理情報処理部333、映像デコーダB334、音声デコーダB335、字幕デコーダB336、アプリケーションデータ受信処理部B337を含む。
330は、放送信号受信装置140が通信を行う場合のネットワーク180とのI/Fである通信I/Fである。放送信号受信装置140は、通信I/F330を介してサービス事業者A120あるいはサービス事業者B120−2あるいはコンテンツサービス事業者X127とコンテンツやデータの送受信を行う。
331は、放送信号受信装置140がサービス事業者A120あるいはサービス事業者B120−2あるいはコンテンツサービス事業者X127から配信される映像あるいは音声のコンテンツを受信するためのコンテンツ受信処理部である。サービス事業者A120あるいはサービス事業者B120−2あるいはコンテンツサービス事業者X127からコンテンツが配信される際の伝送方式は、例えばMPEG−DASHでも、Apple HLSでも、HTTPストリーミングであればいずれの方式であってもよい。
332は、配信されたコンテンツのストリームを、映像ストリーム、音声ストリーム、字幕ストリームに分離するデマルチプレクサBである。デマルチプレクサB332は、分離した映像ストリームを映像デコーダB334に、音声ストリームを音声デコーダB335に、字幕ストリームを字幕デコーダB336に入力する。
333は、ネットワーク180を介して取得した映像あるいは音声のコンテンツに適用されているセキュリティ管理情報を処理して、放送信号受信装置140に接続されている表示器160に映像を出来るようにしたり、スピーカ161から音声を出力できるようにしたりするセキュリティ管理情報処理部である。セキュリティ管理情報は、例えばDRMである。セキュリティ管理処理部333は、必要に応じて通信I/F330を経由してネットワークを介して接続されたセキュリティ情報サーバ(図示しない)と通信してもよい。
このようにネットワーク180を介して送られてくるコンテンツはセキュリティ管理情報が適用されているため、放送信号受信装置140は、セキュリティ管理情報処理部がサポートする種類のセキュリティ管理情報が適用されたコンテンツだけを再生することができる。
334は、デマルチプレクサB332から送られてきた映像データをデコードする映像デコーダBである。
335は、デマルチプレクサB332から送られてきた音声データをデコードする音声デコーダBである。
336は、デマルチプレクサB332から送られてきた字幕データをデコードする字幕デコーダBである。
336は、デマルチプレクサB332から送られてきた字幕データをデコードする字幕デコーダBである。
337は、通信I/F330から送られてきたアプリケーションデータの受信処理をするアプリケーションデータ受信処理部Bである。
アプリケーション制御機能143は、アプリケーション制御部320、アプリケーションエンジン321を含む。
320は、放送信号により送られてきた伝送制御信号から制御信号解析部309により抽出されたMH−AIT等アプリケーションデータに関する制御情報の管理や制御を行うアプリケーション制御部である。
321は、放送信号受信装置140に備わっている種々のアプリケーションとともに動作し各々のアプリケーションの動作を管理するアプリケーションエンジンである。またアプリケーションエンジン321は、データコンテンツサービスにより追加されたアプリケーションデータの動作の管理も行う。さらにアプリケーションエンジン321は、セキュリティ管理情報処理部333がサポートするセキュリティ管理情報の種類をアプリケーションに提供する機能も持つ。
データコンテンツサービスは、非特許文献3に記載のように2つのタイプが存在している。1つ目のタイプは、アプリケーションデータの送信を放送波で行うタイプである。もう1つのタイプは、アプリケーションデータの送信を放送波で行わないタイプである。データコンテンツサービスの2つのタイプについて、図4Aおよび図4Bを用いて説明する。また、図4に示すデータの処理の流れを、図3に示す放送信号受信装置140の機能を用いて説明する。
図4Aは、アプリケーションデータの送信を放送波で行うタイプ(タイプ1のデータコンテンツサービスとも呼ぶ)のデータコンテンツサービスの構成を示す図である。点線420で囲まれた範囲内に存在しているデータが、データコンテンツサービスを構成するデータ群である。
映像コンポーネント401は映像信号の伝送路を、音声コンポーネント402は音声信号の伝送路を、字幕コンポーネント403は字幕信号の伝送路を表している。またMMT−SI404は伝送制御信号の伝送路を、データコンポーネント1(405)およびデータコンポーネント2(406)は、アプリケーションデータの伝送路を示している。
映像コンポーネント401で送信される映像信号、音声コンポーネント402で送信される音声信号、および字幕コンポーネント403で送信される字幕データは、それぞれ図3の映像デコーダA305、音声デコーダA306、字幕デコーダ307でデコードされ、番組として表示器160に表示されたりスピーカ161から出力されたりする。
また、MMT−SI404で送信される伝送制御信号は、図3の制御信号解析部309で解析される。制御信号解析部309で解析された伝送制御信号のうち、アプリケーションデータ取得に必要な制御情報である、MPTに配置されているアプリケーションサービス記述子、MH−AIT(MH-Application Information Table)等は、アプリケーション制御部320に送られ、さらに解析される。
また、データコンポーネント1(405)、データコンポーネント2(406)で送信されるアプリケーションデータ410やアプリケーションデータ411は、図3のアプリケーションデータ受信処理部308で受信される。このアプリケーションデータ410やアプリケーションデータ411は、映像コンポーネント401および音声コンポーネント402で送信された映像信号や音声信号からなる放送番組に付加されたアプリケーション機能を実現するデータである。データコンポーネント1(405)、データコンポーネント2(406)で送信されるアプリケーションデータ410やアプリケーションデータ411は、MMT−SI404で送信される伝送制御信号に含まれるアプリケーションサービス記述子、MH−AIT、DDMT(Data Directory Management Table)、DAMT(Data Asset Management Table)を解析することで特定される。
MPTの中に配置されているアプリケーションサービス記述子は、アプリケーションデータの取得に必要なMH−AIT、DDMT、DAMT、DCCT(Data Content Configuration Table)を参照するための参照先の情報を保持している。図3のアプリケーション制御部320は、これらの参照先の情報をもとに、アプリケーションデータを取得するために必要なMH−AIT、DDMT、DAMTの情報にアクセスし、さらにこれらMH−AIT、DDMT、DAMTを解析することで、データコンポーネント1あるいはデータコンポーネント2で送られてくるアプリケーションデータ410、アプリケーションデータ411が放送波のどこに存在しているかの存在場所を特定することができる。
存在場所が特定されたアプリケーションデータ410およびアプリケーションデータ411は、アプリケーションデータ受信処理部A308により受信される。受信されたアプリケーションデータ410やアプリケーションデータ411からなるアプリケーションは、アプリケーションエンジン321に送られ、アプリケーションエンジン321とともに動作することで、アプリケーションとしての機能を発揮する。
タイプ1のデータコンテンツサービスで取得されるアプリケーションは、放送波であるデータコンポーネントから取得するだけでなく、MH−AITに記載されている情報をもとに、ネットワーク180上に存在するアプリケーションデータ412やアプリケーションデータ413の存在場所を特定し、ネットワーク180を介して通信によりアプリケーションデータを取得することも可能である。またデータコンテンツサービスで取得されるアプリケーションは、一部分をデータコンポーネントから取得し、その他の部分を、ネットワーク180を介して取得することも可能である。
図4Bは、アプリケーションデータの送信を放送波で行わないタイプ(タイプ2のデータコンテンツサービスとも呼ぶ)のデータコンテンツサービスの構成を示す図である。点線430で囲まれた範囲内に存在しているデータが、データコンテンツサービスを構成するデータ群である。
MPTの中に配置されているアプリケーションサービス記述子には、アプリケーションデータの取得に必要なMH−AITを参照するための参照先の情報を保持している。図3のアプリケーション制御部320は、この参照先の情報をもとに、アプリケーションデータを取得するために必要なMH−AITの情報にアクセスし、さらにMH−AITを解析することで、アプリケーションデータ412あるいはアプリケーションデータ413が、ネットワーク180を介してどこに存在しているかの存在場所を特定する。
存在場所が特定されたアプリケーションデータ412あるいはアプリケーションデータ413は、アプリケーションデータ受信処理部B337によって受信される。受信されたアプリケーションデータ412やアプリケーションデータ413からなるアプリケーションは、アプリケーションエンジン321に送られ、アプリケーションエンジン321とともに動作することで、アプリケーションとしての機能を発揮する。
このようにデータコンテンツサービスを行うためには、MMT−SI404として送られてくるMPTの中に、アプリケーションサービス記述子が配置されていることが必要であり、このアプリケーションサービス記述子を解析することで、データコンテンツサービスとして送られてくるアプリケーションの存在場所を特定することができる。
データコンテンツサービスのタイプであるタイプ1およびタイプ2の種別は、アプリケーションサービス記述子のDT_message_flagによって示される。
サービス事業者A120あるいはサービス事業者B120−2あるいはコンテンツサービス事業者X127が、放送信号受信装置140に映像や音声のコンテンツを配布する場合、そのコンテンツは、セキュリティ管理情報が適用されている必要がある。セキュリティ管理情報は、例えばDRMである。以下、セキュリティ管理情報としてDRMを例に説明する。
上述したように、データコンテンツサービスにより放送信号受信装置140に新規にアプリケーション機能が追加される場合、追加されたアプリケーション機能は、放送信号受信装置140がサポートするDRMの種類の情報に基づいて動作できることが望ましい。
そこで本実施形態の放送信号受信装置140は、サポートしているDRMの種類をアプリケーションに提示する機能を持つ。
以下、データコンテンツサービスにより追加されたアプリケーション機能がサポートするDRMの種類、放送信号受信装置140がサポートするDRMの種類、放送信号受信装置140に配信する映像あるいは音声のコンテンツに適用されているDRMの種類の観点から、放送信号を送る放送信号送信装置A100等、コンテンツを配信するサービス事業者A120等および放送信号を受信する放送信号受信装置140等における、コンテンツ配信の全体の処理の流れについて説明する。
なお放送信号受信装置140は、DRMの種類としてDRM−1、DRM−2、DRM−3の3種類のDRMをサポートしているものとし、放送信号受信装置140−2は、DRMの種類としてDRM−0をサポートしているものとする。またサービス事業者A120は、DRMの種類としてDRM−1を適用した映像あるいは音声のコンテンツを配信できるものとし、サービス事業者B120−2は、DRMの種類としてDRM−4を適用した映像あるいは音声のコンテンツを配信できるものとする。またコンテンツサービス事業者X127は、DRMの種類としてDRM−2を適用した映像あるいは音声のコンテンツを配信できるものとする。
図5Aは、放送信号受信装置140が、図4Bに示すタイプ2のデータコンテンツサービスによりアプリケーションデータを取得した場合の、映像あるいは音声のコンテンツの配信を受ける様子の例を示した図である。
なお図5Aの放送信号受信装置140に記載されているDRM−1、DRM−2、DRM−3は、図3に示すセキュリティ管理情報処理部333がサポートしているDRMの種類を表している。サービス事業者A120に記載されているDRM−1は、サービス事業者A120が配信するコンテンツに適用されるDRMの種類を表している。サービス事業者B120−2に記載されているDRM−4は、サービス事業者B120−2が配信するコンテンツに適用されるDRMの種類を表している。コンテンツサービス事業者X127に記載されているDRM−2は、コンテンツサービス事業者X127が配信するコンテンツに適用されるDRMの種類を表している。アプリケーションA(DRM−1)は、アプリケーションAが、アプリケーションエンジン321から取得したセキュリティ管理情報処理部333がサポートするDRMの種類の中にDRM−1が存在する場合に、アプリケーションAが特定処理をすることを表している。図5Bから図5Hにおいても同様の内容の記載とする。
放送信号受信装置140は、放送信号送信装置A100からデータコンテンツサービスとして送られてくるアプリケーションの制御情報であるアプリケーションサービス記述子やMH−AIT等のMMT−SIを受信する(S501)。放送信号受信装置140は、受信した制御情報を解析した結果、アプリケーションA(DRM−1)のアプリケーションデータを、ネットワーク180を介して通信によりサービス事業者A120より取得する(S502−2)
放送信号受信装置140は、S502−2で取得したアプリケーションA(DRM−1)を、図3のアプリケーションエンジン321とともに動作させる。アプリケーションA(DRM−1)は、動作する過程において、図3のセキュリティ管理情報処理部333がサポートするDRMの種類(DRM−1、DRM−2、DRM−3)の情報を、アプリケーションエンジン321より取得する。アプリケーションA(DRM−1)は、取得した情報の中に、特定処理を行うためのDRMの種類が存在しているかの判定を行い、存在している場合は特定処理を行う。
具体的にはアプリケーションA(DRM−1)は、取得したセキュリティ管理情報処理部333がサポートするDRMの種類の中に、特定処理を行うためのDRMの種類であるDRM−1が存在しているかの判定を行う。セキュリティ管理情報処理部333がサポートするDRMの種類の中にはDRM−1が存在しているので、アプリケーションA(DRM−1)は、特定処理として例えばDRM−1の種類のDRMを適用したコンテンツを配信するサービス事業者A120にアクセスし、コンテンツを取得する(S503−2)。
図5Bは、放送信号受信装置140が、図4Bに示すタイプ2のデータコンテンツサービスによりアプリケーションデータを取得した場合の、映像あるいは音声のコンテンツの配信を受ける様子の他の例を示した図である。図5Aとの違いは、追加されるアプリケーションが複数あり、追加されるアプリケーションは、アプリケーション提供元のサービス事業者Aとは異なるコンテンツサービス事業者X127から、コンテンツを取得する点である。
放送信号受信装置140は、放送信号送信装置A100からデータコンテンツサービスとして送られてくるアプリケーションの制御情報であるアプリケーションサービス記述子やMH−AIT等のMMT−SIを受信する(S511)。放送信号受信装置140は、受信した制御情報を解析した結果、アプリケーションB−1(DRM−2)のアプリケーションデータを、ネットワーク180を介して通信によりサービス事業者A120より取得し(S512−21)、アプリケーションB−2(DRM−4)のアプリケーションデータを、ネットワーク180を介して通信によりサービス事業者B120−2より取得する(S512−22)。
放送信号受信装置140は、S512−21で取得したアプリケーションB−1(DRM−2)およびS512−22で取得したアプリケーションB−2(DRM−4)を、図3のアプリケーションエンジン321とともに動作させる。アプリケーションB−1(DRM−2)およびアプリケーションB−2(DRM−4)は、動作する過程において、図3のセキュリティ管理情報処理部333がサポートするDRMの種類(DRM−1、DRM−2、DRM−3)の情報を、アプリケーションエンジン321より取得する。アプリケーションB−1(DRM−2)およびアプリケーションB−2(DRM−4)は、取得した情報の中に、特定処理を行うためのDRMの種類が存在しているかの判定を行い、存在している場合は特定処理を行う。
具体的にはアプリケーションB−1(DRM−2)は、取得したセキュリティ管理情報処理部333がサポートするDRMの種類の中に、特定処理を行うためのDRMの種類であるDRM−2が存在しているかの判定を行う。セキュリティ管理情報処理部333がサポートするDRMの種類の中にはDRM−2が存在しているので、アプリケーションB−1(DRM−2)は、特定処理として例えばDRM−2の種類のDRMを適用したコンテンツを配信するコンテンツサービス事業者X127にアクセスし、コンテンツを取得する(S513−4)。
同様にアプリケーションB−2(DRM−2)は、取得したセキュリティ管理情報処理部333がサポートするDRMの種類の中に、特定処理を行うためのDRMの種類であるDRM−4が存在しているかの判定を行う。セキュリティ管理情報処理部333がサポートするDRMの種類の中にはDRM−4が存在していないので、アプリケーションB−2(DRM−4)は、特定処理を行わない。
このようにデータコンテンツサービスにより放送信号受信装置140に追加されたアプリケーションは、セキュリティ管理情報処理部333がサポートするDRMの種類の情報をもとに動作を決定することが可能であり、例えばサービス事業者A120から映像あるいは音声のコンテンツの配信を受けたり、またはアプリケーションデータを取得したサービス事業者A120とは別のコンテンツサービス事業者X127からコンテンツの配信を受けたりすることが可能となる。
また放送信号受信装置140は、放送信号送信装置A100から受信したMMT−SIを解析することで、データコンテンツサービスとして複数のアプリケーションを取得することも可能である。この場合各アプリケーションが特定処理をする際に判定するDRMの種類が異なる場合がある。このような場合でも、各アプリケーションが、セキュリティ管理情報処理部333がサポートするDRMの種類の情報をもとに動作を決定することが可能であるため、追加されたアプリケーションの能力を有効に活用することができ、追加されたアプリケーションを含めて放送信号受信装置140全体として最適な機能の向上につなげることができる。
図5Cは、放送信号受信装置140が、図4Aに示すタイプ1のデータコンテンツサービスによりアプリケーションデータを取得した場合の、映像あるいは音声のコンテンツの配信を受ける様子の例を示した図である。
放送信号受信装置140は、放送信号送信装置A100からデータコンテンツサービスとして送られてくるアプリケーションの制御情報であるアプリケーションサービス記述子、MH−AIT、DDMT、DAMT等のMMT−SIを受信する(S521)。放送信号受信装置140は、受信した制御情報を解析した結果、アプリケーションC(DRM−1)のデータを、放送波により放送信号送信装置A100より取得する(S522−1)
放送信号受信装置140は、S522−1で取得したアプリケーションC(DRM−1)を、図3のアプリケーションエンジン321とともに動作させる。アプリケーションC(DRM−1)は、動作する過程において、図3のセキュリティ管理情報処理部333がサポートするDRMの種類(DRM−1、DRM−2、DRM−3)の情報を、アプリケーションエンジン321より取得する。アプリケーションC(DRM−1)は、取得した情報の中に、特定処理を行うためのDRMの種類が存在しているかの判定を行い、存在している場合は特定処理を行う。
具体的にはアプリケーションC(DRM−1)は、取得したセキュリティ管理情報処理部333がサポートするDRMの種類の中に、特定処理を行うためのDRMの種類であるDRM−1が存在しているかの判定を行う。セキュリティ管理情報処理部333がサポートするDRMの種類の中にはDRM−1が存在しているので、アプリケーションC(DRM−1)は、特定処理として例えばDRM−1の種類のDRMを適用したコンテンツを配信するサービス事業者A120にアクセスし、コンテンツを取得する(S523−2)。
なお放送波で送られてくるアプリケーションは、複数あってもよい。またこの場合各アプリケーションが特定処理を行う際に判定するDRMの種類は、図5Bに示すアプリケーションB−1(DRM−2)とアプリケーションB−2(DRM−4)のように各々異なっていてもよい。
図5Dは、放送信号受信装置が、図4Aに示したタイプ1のデータコンテンツサービスによりアプリケーションデータを取得した場合の、映像あるいは音声のコンテンツの配信を受ける様子の他の例を示した図である。図5Cとの違いは、複数の放送信号受信装置140および放送信号受信装置140−2において、セキュリティ管理情報処理部がサポートしているDRMの種類が異なる放送信号受信装置が存在する点である。放送信号受信装置140−2のセキュリティ管理情報処理部は、DRM−0の種類のDRMをサポートしているとする。
放送信号受信装置140および放送信号受信装置140−2はともに、放送信号送信装置A100からデータコンテンツサービスとして送られてくるアプリケーションの制御情報であるアプリケーションサービス記述子、MH−AIT、DDMT、DAMT等のMMT―SIを受信する(S531)。放送信号受信装置140および放送信号受信装置140−2は、受信した制御情報を解析した結果、アプリケーションD(DRM−1)のデータを、放送波により放送信号送信装置A100より取得する(S532−1)
放送信号受信装置140は、S532−1で取得したアプリケーションD(DRM−1)を、図3のアプリケーションエンジン321とともに動作させる。アプリケーションD(DRM−1)は、動作する過程において、図3のセキュリティ管理情報処理部333がサポートするDRMの種類(DRM−1、DRM−2、DRM−3)の情報を、アプリケーションエンジン321より取得する。アプリケーションD(DRM−1)は、取得した情報の中に、特定処理を行うためのDRMの種類が存在しているかの判定を行い、存在している場合は特定処理を行う。
具体的にはアプリケーションD(DRM−1)は、取得したセキュリティ管理情報処理部333がサポートするDRMの種類の中に、特定処理を行うためのDRMの種類であるDRM−1が存在しているかの判定を行う。セキュリティ管理情報処理部333がサポートするDRMの種類の中にはDRM−1が存在しているので、アプリケーションD(DRM−1)は、特定処理として例えばDRM−1の種類のDRMを適用したコンテンツを配信するサービス事業者A120にアクセスし、コンテンツを取得する(S533−2)。
同様に放送信号受信装置140−2は、S532−1で取得したアプリケーションD(DRM−1)を、図3のアプリケーションエンジン321とともに動作させる。アプリケーションD(DRM−1)は、動作する過程において、図3のセキュリティ管理情報処理部333がサポートするDRMの種類(DRM−0)の情報を取得する。アプリケーションDは、取得した情報の中に、特定処理を行うためのDRMの種類が存在しているかの判定を行い、存在している場合は特定処理を行う。具体的にはアプリケーションD(DRM−1)は、取得したセキュリティ管理情報処理部333がサポートするDRMの種類の中に、特定処理を行うためのDRMの種類であるDRM−1が存在しているかの判定を行う。セキュリティ管理情報処理部333がサポートするDRMの種類の中にはDRM−1が存在していないので、アプリケーションD(DRM−1)は、特定処理を行わない。
このように放送信号受信装置のセキュリティ管理情報処理部がサポートしているDRMの種類は、放送信号受信装置140、放送信号受信装置140−2のように放送信号受信装置ごとに異なる場合がある。
一方放送波によりアプリケーションデータが放送信号受信装置140に追加される場合は、放送信号受信装置140のセキュリティ管理情報処理部がサポートしているDRMの種類に関わらず、どの放送信号受信装置140に対しても同じアプリケーションとなる。このため放送信号受信装置140のセキュリティ管理情報処理部333がサポートするDRMの種類を、アプリケーションに提供する処理は、アプリケーションの能力を十分に活用するために非常に有効な処理である。
図5Eは、放送信号受信装置140が、図4Bに示すタイプ2のデータコンテンツサービスによりアプリケーションデータを取得した場合の、映像あるいは音声のコンテンツの配信を受ける様子の他の例を示した図である。
図5Aとの違いは、追加されたアプリケーションが特定処理を行うことができるDRMの種類を、図3に示すセキュリティ管理情報処理部333がサポートしていない点である。
放送信号受信装置140は、放送信号送信装置A100からデータコンテンツサービスとして送られてくるアプリケーションの制御情報であるアプリケーションサービス記述子やMH−AIT等のMMT−SIを受信する(S541)。放送信号受信装置140は、受信した制御情報を解析した結果、アプリケーションE(DRM−4)のアプリケーションデータを、ネットワーク180を介して通信によりサービス事業者A120より取得する(S542−2)
放送信号受信装置140は、S542−2で取得したアプリケーションE(DRM−4)を、図3のアプリケーションエンジン321とともに動作させる。アプリケーションE(DRM−4)は、動作する過程において、図3のセキュリティ管理情報処理部333がサポートするDRMの種類(DRM−1、DRM−2、DRM−3)の情報を、アプリケーションエンジン321より取得する。アプリケーションE(DRM−4)は、取得した情報の中に、特定処理を行うためのDRMの種類が存在しているかの判定を行い、存在している場合は特定処理を行う。
具体的にはアプリケーションE(DRM−4)は、取得したセキュリティ管理情報処理部333がサポートするDRMの種類の中に、特定処理を行うためのDRMの種類であるDRM−4が存在しているかの判定を行う。セキュリティ管理情報処理部333がサポートするDRMの種類の中にはDRM−4が存在していないので、アプリケーションE(DRM−4)は、特定処理を行わない。これによりアプリケーションE(DRM−4)は、コンテンツの配信を受けることが不可能となる。アプリケーションE(DRM−4)は、特定処理を行うためのDRMの種類が、セキュリティ管理情報処理部333がサポートするDRMの種類の中には存在していない旨をアプリケーションエンジン321に通知してもよい。
アプリケーションE(DRM−4)から、特定処理を行うためのDRMの種類が、セキュリティ管理情報処理部333がサポートするDRMの種類の中には存在していない旨の判定結果を受け取った図3のアプリケーションエンジン321は、例えば160−1に示すような表示できません、の通知を出す指示を表示器160に通知してもよい。このようにすることで、放送信号受信装置140の視聴者は、追加されたアプリケーションEは、映像あるいは音声のコンテンツの配信を受けることができないことを認識することができる。
図5Fは、放送信号受信装置140が、図4Bに示すタイプ2のデータコンテンツサービスによりアプリケーションデータを取得した場合の、映像あるいは音声のコンテンツの配信を受ける様子の他の例を示した図である。
図5Aとの違いは、追加されたアプリケーションが、特定処理を行うためのDRMの種類を複数持つ点である。アプリケーションF(DRM−1,DRM−3)は、処理を行うためのDRMの種類がDRM−1およびDRM−3であるとする。
放送信号受信装置140は、放送信号送信装置A100からデータコンテンツサービスとして送られてくるアプリケーションの制御情報であるアプリケーションサービス記述子やMH−AIT等のMMT−SIを受信する(S551)。放送信号受信装置140は、受信した制御情報を解析した結果、アプリケーションF(DRM−1,DRM−3)のアプリケーションデータを、ネットワーク180を介して通信によりサービス事業者A120より取得する(S552−2)
放送信号受信装置140は、S552−2で取得したアプリケーションF(DRM−1,DRM−3)を、図3のアプリケーションエンジン321とともに動作させる。アプリケーションF(DRM−1,DRM−3)は、動作する過程において、図3のセキュリティ管理情報処理部333がサポートするDRMの種類(DRM−1、DRM−2、DRM−3)の情報を、アプリケーションエンジン321より取得する。アプリケーションF(DRM−1,DRM−3)は、取得した情報の中に、特定処理を行うためのDRMの種類が存在しているかの判定を行い、存在している場合は特定処理を行う。
具体的にはアプリケーションF(DRM−1、DRM−3)は、取得したセキュリティ管理情報処理部333がサポートするDRMの種類の中に、特定処理を行うためのDRMの種類であるDRM−1、DRM−3が存在しているかの判定を行う。セキュリティ管理情報処理部333がサポートするDRMの種類の中にはDRM−1、DRM−3が存在しているので、アプリケーションF(DRM−1、DRM−3)は、特定処理として例えばDRM−1の種類に基づいた処理を行ってもよい。具体的にはアプリケーションF(DRM−1、DRM−3)は、例えばDRM−1の種類のDRMを適用したコンテンツを配信するサービス事業者A120にアクセスし、コンテンツを取得してもよい(S553−2)。あるいはアプリケーションF(DRM−1、DRM−3)は、DRM−3の種類に基づいた処理を行ってもよい。具体的にはアプリケーションF(DRM−1、DRM−3)は、例えばDRM−3の種類のDRMを適用したコンテンツを配信するサービス事業者C(図示しない)にアクセスし、コンテンツを取得してもよい。
このように放送信号受信装置140が、セキュリティ管理情報処理部333のサポートするDRMの種類の情報をアプリケーションに提供することにより、アプリケーションF(DRM−1、DRM−3)のような特定処理を行うためのDRMの種類が存在しているアプリケーションは、取得した情報をどのような優先度をつけて処理を行うかを自由に決めることが出来るため、アプリケーションとしての処理の自由度が増し、アプリケーションの能力を十分に発揮することができる。
図5Fの例は、特定処理を行うためのDRMの種類を複数持つアプリケーションが、サービス事業者A120から送られてきた例であるが、放送信号送信装置A100から送られてきてもよい。
データコンテンツサービスとして送られてくるアプリケーションは、複数のアプリケーションが互いに連携していてもよい。例えばあるアプリケーションG−1は、特定処理を行うためのDRMの種類が存在しているかの判定を行い、存在している場合は、存在しているDRMの種類に応じて、アプリケーションG−2あるいはアプリケーションG−3を呼び出し特定動作の処理を行わせてもよい。
図5Gは、放送信号受信装置140が、図4Bに示すタイプ2のデータコンテンツサービスによりアプリケーションデータを取得した場合の、取得した複数のアプリケーションが、互いに連携して動作する場合の例である。
放送信号受信装置140は、放送信号送信装置A100からデータコンテンツサービスとして送られてくるアプリケーションの制御情報であるアプリケーションサービス記述子やMH−AIT等のMMT−SIを受信する(S561)。放送信号受信装置140は、受信した制御情報を解析した結果、アプリケーションG−1、アプリケーションG−2(DRM−1)、アプリケーションG−3(DRM―2)の3つのアプリケーションデータを、ネットワーク180を介して通信によりサービス事業者A120より取得する(S562−21)(S562−22)(S562−23)。
放送信号受信装置140は、S562−21で取得したアプリケーションG−1を、図3のアプリケーションエンジン321とともに動作させる。アプリケーションG−1は、動作する過程で図3のセキュリティ管理情報処理部333がサポートするDRMの種類(DRM−1、DRM−2、DRM−3)の情報を、アプリケーションエンジン321より取得する。アプリケーションG−1は、取得した情報の中に、特定処理を行うためのDRMの種類が存在しているかの判定を行い、存在している場合は、該当する特定処理を行うアプリケーションを呼び出す。
具体的にはアプリケーションG−1は、取得したセキュリティ管理情報処理部333がサポートするDRMの種類の中に、特定処理を行うためのDRMの種類であるDRM−1、DRM−2が存在しているかの判定を行う。セキュリティ管理情報処理部333がサポートするDRMの種類の中にはDRM−1、DRM−2が存在しているので、アプリケーションG−1は、特定処理として例えばDRM−1の種類に基づいた処理を行ってもよい。具体的にはアプリケーションG−1は、DRM−1の種類にもとづいた特定処理を行うために、アプリケーションG−2(DRM−1)を呼び出し、図3のアプリケーションエンジン321とともに動作させる。アプリケーションG−2(DRM−2)は、例えばDRM−1の種類のDRMを適用したコンテンツを配信するサービス事業者A120にアクセスし、コンテンツを取得してもよい(S563−2)。あるいはアプリケーションG−1は、DRM−2の種類に基づいた特定処理を行ってもよい。この場合は、アプリケーションG−1は、DRM−2の種類にもとづいた特定処理を行うために、アプリケーションG−2(DRM−2)を呼び出し、図3のアプリケーションエンジン321とともに動作させればよい。
図5Hは、放送信号受信装置140が、図4Aに示すタイプ1のデータコンテンツサービスによりアプリケーションデータを取得した場合の、映像あるいは音声のコンテンツの配信を受ける様子の他の例を示した図である。図5Cとの違いは、複数の放送信号受信装置から送られてきたアプリケーションの制御情報にもとづいて、各々の制御情報に対応するアプリケーションを取得する点である。
放送信号受信装置140は、放送信号送信装置A100からデータコンテンツサービスとして送られてくるアプリケーションの制御情報であるアプリケーションサービス記述子、MH−AIT、DDMT、DAMT等のMMT−SIを受信し(S571)、また放送信号送信装置B100−2からデータコンテンツサービスとして送られてくるアプリケーションの制御情報であるアプリケーションサービス記述子、MH−AIT、DDMT、DAMT等のMMT−SIを受信する(S576)。放送信号受信装置140は、受信した制御情報を解析した結果、S571で取得したMMT−SIに対応してアプリケーションH−1(DRM−1)のアプリケーションデータを、放送波により放送信号送信装置A100より取得し(S572−1)、S576で取得したMMT−SIに対応してアプリケーションH−2(DRM−4)のアプリケーションデータを、放送波により放送信号送信装置B100−2より取得する(S577−1)。
放送信号受信装置140は、S572−1で取得したアプリケーションH−1(DRM−1)およびS577−1で取得したアプリケーションH−2(DRM−2)を、図3のアプリケーションエンジン321とともに動作させる。アプリケーションH−1(DRM−1)およびアプリケーションH−2(DRM−2)は、動作する過程において、図3のセキュリティ管理情報処理部333がサポートするDRMの種類(DRM−1、DRM−2、DRM−3)の情報を取得する。アプリケーションH−1(DRM−1)およびアプリケーションH−2(DRM−2)は、取得した情報の中に、特定処理を行うためのDRMの種類が存在しているかの判定を行い、存在している場合は特定処理を行う。
具体的にはアプリケーションH−1(DRM−1)は、取得したセキュリティ管理情報処理部333がサポートするDRMの種類の中に、特定処理を行うためのDRMの種類であるDRM−1が存在しているかの判定を行う。セキュリティ管理情報処理部333がサポートするDRMの種類の中にはDRM−1が存在しているので、アプリケーションH−1(DRM−1)は、特定処理として例えばDRM−1の種類のDRMを適用したコンテンツを配信するサービス事業者A120にアクセスし、コンテンツを取得する(S573−2)。
同様にアプリケーションH−2(DRM−2)は、取得したセキュリティ管理情報処理部333がサポートするDRMの種類の中に、特定処理を行うためのDRMの種類であるDRM−2が存在しているかの判定を行う。セキュリティ管理情報処理部333がサポートするDRMの種類の中にはDRM−2が存在しているので、アプリケーションH−2(DRM−2)は、特定処理として例えばDRM−2の種類のDRMを適用したコンテンツを配信するコンテンツサービス事業者X127にアクセスし、コンテンツを取得する(S578−4)。
図5Hのシーケンスの例は、例えば放送信号受信装置140が、複数のチューナを利用して複数番組を受信している場合が想定される。このように放送信号受信装置140のセキュリティ管理情報処理部333がサポートするDRMの種類をアプリケーションに提供する処理は、アプリケーションエンジン321とともに動作するアプリケーションが複数存在していても、各々のアプリケーションに対してサポートするDRMの種類をアプリケーションに提供することが可能である。
図5Iは、放送信号受信装置140が、セキュリティ管理情報処理部333がサポートするDRMの種類をアプリケーションに提供する処理がない場合の、映像あるいは音声のコンテンツの配信を受ける様子の例を示した図である。この場合は、アプリケーションIが、例えば予め放送信号受信装置140に備え付けられている場合である。
アプリケーションIは、セキュリティ管理情報処理部333がサポートするDRMの種類のDRMが適用されたコンテンツを配信する、予め決められたサービス事業者にアクセスし、映像あるいは音声のコンテンツを取得する。図5Iの例は、放送信号受信装置140に予め備え付けられたアプリケーションIが、予め決められたサービス事業者A120にアクセスしてDRM−1の種類のDRMが適用されたコンテンツを取得する(S583−2)例である。
本実施形態の放送信号受信装置は、端末連携機能144を有する。図5Eの例は、セキュリティ管理情報処理部333がサポートするDRMの種類の中に、サービス事業者B120−2からコンテンツの配信を受けるために必要なDRM−4が存在しないため、アプリケーションE(DRM−4)は、サービス事業者B120−2からコンテンツの配信を受けることができない。しかし本実施形態の放送信号受信装置140は、コンテンツの配信を受けるのに必要なDRMの種類をサポートしていない場合、コンテンツの配信を受けるのに必要なDRMの種類をサポートしている携帯端末と端末連携機能により連携することで、配信されたコンテンツを連携している携帯端末に送信することで、再生可能とすることができる。このように放送信号受信装置140は、端末連携機能を用いることで、接続された携帯端末のDRMの種類のサポート範囲を利用することで、配信されたコンテンツを再生することができる。
放送信号受信装置140のセキュリティ管理情報処理部333がサポートするDRMの種類をアプリケーションに提供する機能は、例えば非特許文献2、非特許文献3に規定のCapabilitiesオブジェクトを拡張することで構成されてもよい。
図6は、放送信号受信装置140のセキュリティ管理情報処理部333がサポートするDRMの種類をアプリケーションに提供する機能を構成するために、Capabilitiesオブジェクトを拡張した例である。
例えばquery=Video Elementのparm1に、新たにContent Protectionを追加することで放送信号受信装置140がサポートするセキュリティ管理情報の種類を提供する機能を追加する。pram2は、セキュリティ管理情報の種類を表し、param3は、pram2に示すセキュリティ管理情報のバージョンを表している。このように、セキュリティ管理情報の種類であるparam2およびparam2バージョンであるpram3の組み合わせを任意に追加することで、放送信号受信装置140がサポートするセキュリティ管理情報を提供する機能を拡張することが可能である。
図7は、図6に示した、セキュリティ管理情報処理部333がサポートするDRMの種類をアプリケーションに提供する機能を用いた場合の、処理フローの例を示した図である。図5Eに示すアプリケーションEが、セキュリティ管理情報処理部333がサポートするDRMの種類を取得する場合の処理フローを示す。
アプリケーションEは、セキュリティ管理情報処理部333がサポートするDRMの種類を取得するために、サポート種類取得処理Eを開始する(S700)。アプリケーションEは、セキュリティ管理情報処理部333が、D1システムをサポートしているかの判定を行う(S701)。具体的にはアプリケーションEは、CapabilitiesオブジェクトのhasCapabilityのqueryにVideo Elementを、parm1にContent Protectionを、parm2にD1を、parm3にD2を各々設定して呼び出し、その戻り値を見ることで判定する。
判定の結果サポートしている場合(S701がYes、戻り値がtrue)、アプリケーションEは、放送信号受信装置140がD1システム(DRM−4)をサポートしていると認識する(S702)。アプリケーションEは、特定処理Eを実行する(S703)。特定処理Eは、例えばDRM−4の種類のDRMを適用したコンテンツを配信するサービス事業者B120−2にアクセスし、コンテンツを取得する処理であってもよい。
判定の結果サポートしていない場合(S701がNo、戻り値がfalse)、アプリケーションEは、放送信号受信装置140がD1システム(DRM−4)をサポートしていないと認識する(S705)。アプリケーションEは、特定処理を行うためのDRMの種類が、セキュリティ管理情報処理部333がサポートするDRMの種類の中には存在していないため「受信装置がアプリケーションEのサービスに対応していない」旨を表示画面160に表示するように、アプリケーションエンジン321に指示(S706)してもよい。
図5Eに示す放送信号受信装置140においては、アプリケーションEは、S701の判定処理においてNoと判定するので、以降の処理としてS705、S706の処理を行い、サポート種類取得処理Eを終了する(S704)
図8Aは、図6に示した、セキュリティ管理情報処理部333がサポートするDRMの種類をアプリケーションに提供するために機能を用いた場合の、処理フローの他の例を示した図である。図5Fに示すアプリケーションFが、セキュリティ管理情報処理部333がサポートするDRMの種類を取得する場合の処理フローを示す。
アプリケーションFは、セキュリティ管理情報処理部333がサポートするDRMの種類を取得するために、サポート種類取得処理F−1を開始する(S800)。アプリケーションFは、セキュリティ管理情報処理部333が、A1システムをサポートしているかの判定を行う。具体的にはアプリケーションFは、CapabilitiesオブジェクトのhasCapabilityのqueryにVideo Elementを、parm1にContent Protectionを、parm2にA1を、parm3にA2を各々設定して呼び出し、その戻り値を見ることで判定する。
判定の結果サポートしている場合(S801がYes、戻り値がtrue)、アプリケーションFは、放送信号受信装置140がA1システム(DRM−1)をサポートしていると認識する(S802)。アプリケーションFは、特定処理F−1を実行する(S803)。特定処理F−1は、例えばDRM−1の種類のDRMを適用したコンテンツを配信するサービス事業者A120−1にアクセスし、コンテンツを取得する処理であってもよい。
判定の結果サポートしていない場合(S801のNo、戻り値がfalse)、アプリケーションFは、さらにセキュリティ管理情報処理部333が、C1システムをサポートしているかの判定を行う(S805)。具体的にはアプリケーションFは、CapabilitiesオブジェクトのhasCapabilityのqueryにVideo Elementを、parm1にContent Protectionを、parm2にC1を各々設定して呼び出し、その戻り値を見ることで判定する。
判定の結果サポートしている場合(S805がYes、戻り値がtrue)、アプリケーションFは、放送信号受信装置140がC1システム(DRM−3)をサポートしていると認識する(S806)。アプリケーションFは、特定処理F−2を実行する(S807)。特定処理F−2は、例えばDRM−3の種類のDRMを適用したコンテンツを配信するサービス事業者C(図示しない)にアクセスし、コンテンツを取得する処理であってもよい。
判定の結果サポートしていない場合(S805がNo、戻り値がfalse)、アプリケーションFは、放送信号受信装置140がA1システム(DRM−1)およびC1システム(DRM−3)をサポートしていないと認識する(S808)。アプリケーションFは、特定処理を行うためのDRMの種類が、セキュリティ管理情報処理部333がサポートするDRMの種類の中には存在していないため「受信装置がアプリケーションFのサービスに対応していない」旨を表示画面160に表示するように、アプリケーションエンジン321に指示(S809)してもよい。
図5Fに示す放送信号受信装置140においては、アプリケーションFは、S801の判定処理においてYesと判定するので、以降の処理としてS802、S803の処理を行い、サポート種類取得処理Fを終了する(S804)。
図8Aの処理の例は、アプリケーションFが、セキュリティ管理情報処理部333がサポートするDRMの種類を、A1システム(DRM−1)、C1システム(DRM−3)の順に判定した場合であるが、判定の順番はアプリケーションFが任意に変えることが可能である。
図8Bは、アプリケーションFが、セキュリティ管理情報処理部333がサポートするDRMの種類を、C1システム(DRM−3)、A1システム(DRM−1)の順に判定した場合の処理フローの例を示した図である。図8Aとの相違点は、セキュリティ管理情報処理部333がサポートするDRMの種類を判定の順番を変えただけである。
このようにセキュリティ管理情報処理部333がサポートするDRMの種類を判定の順番は、アプリケーション作成者が自由に変更することが可能であるため、アプリケーションとしての処理の自由度が増し、アプリケーションの能力を十分に発揮することができる。
図8Cは、特定処理の一例を示す処理フローの例を示した図である。図8Aに示したアプリケーションFの特定処理F−1の処理フローを示した図である。アプリケーションFは、図8AのS803の処理で特定処理F−1を開始する(S840)。
アプリケーションFは、放送信号受信装置140の表示画面160で、8Kの解像度、4Kの解像度、2Kの解像度のいずれの解像度のコンテンツを再生できる能力があるかの判定を行う。
アプリケーションFは、最初に放送信号受信装置140の表示画面160で、8Kの解像度を持つコンテンツを再生できるかどうかの判定を行う(S841)。8Kの解像度を持つコンテンツが、放送信号受信装置140の表示画面160で再生できるかどうかの判定は、例えばCapabilitiesオブジェクトのhasCapabilityのqueryにVideo Elementを、parm1にMPEG−DASHを、parm2に8Kを各々設定して呼び出し、その戻り値を見ることで判定してもよい。
判定の結果再生可能である場合(S841のYes、戻り値がtrue)、アプリケーションFは、放送信号受信装置140は、8Kの解像度を持つコンテンツを再生できると認識し、放送信号受信装置140が再生可能な8Kの解像度を持つコンテンツの配信を、サービス事業者A120に要求する(S846)。
判定の結果再生可能でない場合(S841のNo、戻り値がfalse)、アプリケーションFは、放送信号受信装置140の表示画面160で、4Kの解像度を持つコンテンツを再生できるかどうかの判定を行う(S843)。4Kの解像度を持つコンテンツが、放送信号受信装置140の表示画面160で再生できるかどうかの判定は、例えばCapabilitiesオブジェクトのhasCapabilityのqueryにVideo Elementを、parm1にMPEG−DASHを、parm2に4Kを各々設定して呼び出し、その戻り値を見ることで判定してもよい。
判定の結再生示可能である場合(S843のYes、戻り値がtrue)、アプリケーションFは、放送信号受信装置140の表示画面160は、4Kの解像度を持つコンテンツを再生できると認識し、放送信号受信装置140が再生可能な4Kの解像度を持つコンテンツの配信を、サービス事業者A120に要求する(S846)。
判定の結再生示可能でない場合(S843のNo、戻り値がfalse)、アプリケーショ
アプリケーションFは、放送信号受信装置140は、2Kの解像度を持つコンテンツを再生できると認識し、放送信号受信装置140が再生可能な2Kの解像度を持つコンテンツの配信を、サービス事業者A120に要求する(S846)。
これによりアプリケーションFは、セキュリティ管理情報処理部333がサポートするDRMの種類が適用されたコンテンツのうち、放送信号受信装置140に表示可能な解像度をもったコンテンツを取得することが可能である。
本発明のいくつかの実施形態を説明したが、これらの実施形態は例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。さらにまた、請求項の各構成要素において、構成要素を分割して表現した場合、或いは複数を合わせて表現した場合、或いはこれらを組み合わせて表現した場合であっても本発明の範疇である。また、複数の実施形態を組み合わせてもよく、この組み合わせで構成される実施例も発明の範疇である。
また、図面は、説明をより明確にするため、実際の態様に比べて、模式的に表される場合があるが、あくまで一例であって、本発明の解釈を限定するものではない。また、本明細書と各図において、既出の図に関して前述したものと同一又は類似した機能を発揮する構成要素には同一の参照符号を付し、重複する詳細な説明を適宜省略することがある。また請求項を制御ロジックとして表現した場合、コンピュータを実行させるインストラクションを含むプログラムとして表現した場合、及び前記インストラクションを記載したコンピュータ読み取り可能な記録媒体として表現した場合でも本発明の装置を適用したものである。また、使用している名称や用語についても限定されるものではなく、他の表現であっても実質的に同一内容、同趣旨であれば、本発明に含まれるものである。
100・・・放送信号送信装置A、101・・・放送番組サーバ、102・・・放送信号送信基本機能、103・・・アプリケーションデータ管理部、120・・・サービス事業者A、140・・・放送信号受信装置、141・・・放送信号受信基本機能、142・・・通信制御機能、143・・・アプリケーション制御機能、144・・・端末連携機能、321・・・アプリケーションエンジン、333・・・セキュリティ管理情報処理部。

Claims (6)

  1. 番組を放送する放送波を受信した放送信号から分離される伝送制御信号を解析して、前記伝送制御信号に含まれる、前記番組に付加して特定処理を行うアプリケーションとなるアプリケーションデータに関する制御情報を取得する解析部と、
    前記制御情報に基づいて、通信ネットワーク上に存在する前記アプリケーションデータの存在場所を特定すると共に、前記アプリケーションの動作を制御するアプリケーション制御と、
    前記アプリケーション制御が特定した前記通信ネットワーク上の存在場所のアプリケーションデータを受信するアプリケーションデータ受信処理と、
    前記アプリケーションデータ受信処理が受信したアプリケーションデータからなるアプリケーションを管理し、前記アプリケーション制御部の前記制御により前記アプリケーションに特定処理を動作させるアプリケーションエンジンと、
    複数の種類のセキュリティ管理情報の内のいずれか一つの適用により保護を受けた少なくとも映像を含むコンテンツを通信により取得するための、コンテンツ受信処理部と、
    前記複数の種類のセキュリティ管理情報の内の少なくともいずれかをサポートし、サポートする種類のセキュリティ管理情報が適用されるコンテンツだけを処理するセキュリティ管理情報処理部と、
    を具備し、
    前記アプリケーションエンジンは、前記セキュリティ管理情報処理部がサポートする前記セキュリティ管理情報の種類の情報を前記アプリケーションに提供し、
    前記アプリケーションの動作で、前記アプリケーションエンジンから提供されるセキュリティ管理情報の種類の情報の中に前記特定処理を行うための種類が存在しているかの判定を行い、存在している場合には、その種類のセキュリティ管理情報が適用される前記コンテンツの配信先を決定し、前記コンテンツ受信処理部を通じて決定した配信先からのコンテンツを取得し、前記特定処理を行う放送信号受信装置。
  2. 前記制御情報は、前記番組にアプリケーションデータが付加されていることを示すアプリケーション情報テーブルを備える、請求項1に記載の放送信号受信装置。(0039)
  3. 前記アプリケーションの符号化方式は、HTML5である、請求項1に記載の放送信号受信装置。
  4. 前記コンテンツを取得する際の伝送方式は、MPEG−DASHである、請求項1に記載の放送信号受信装置。
  5. 番組を放送する放送波を受信した放送信号から分離される伝送制御信号を解析して、前記伝送制御信号に含まれる、前記番組に付加した特定処理を行うアプリケーションとなるアプリケーションデータに関する制御情報を取得し、
    前記制御情報に基づいて、通信ネットワーク上に存在するアプリケーションデータの存在場所を特定し、
    前記通信ネットワーク上の存在場所から前記アプリケーションデータを受信し、
    受信した前記アプリケーションデータからなるアプリケーションを管理して、前記アプリケーションに特定処理を動作させ、
    複数の種類のセキュリティ管理情報の内のいずれか一つの適用により保護を受けた少なくとも映像を含むコンテンツを通信により取得し、
    前記複数の種類のセキュリティ管理情報の内の少なくともいずれかをサポートし、サポートする種類のセキュリティ管理情報が適用されるコンテンツだけを処理する放送信号受信方法であって、
    サポートする前記セキュリティ管理情報の種類の情報を前記アプリケーションに提供し、
    前記アプリケーションの動作で、提供された前記セキュリティ管理情報の種類の中に前記特定処理を行うための種類が存在しているかの判定を行い、存在している場合には、その種類のセキュリティ管理情報が適用される前記コンテンツの配信先を決定し、決定した配信先からのコンテンツを取得し、前記特定処理を行う放送信号受信方法。
  6. 番組と、前記番組に付加して特定処理を行うアプリケーションとなるアプリケーションデータに関する制御情報を含む伝送制御信号とを含む放送信号を送受信する放送信号送受信方法において、
    送信側では、通信ネットワーク上に存在する前記アプリケーションデータの存在場所を、前記制御情報に設定し、
    受信側では、前記制御情報に基づいて、前記通信ネットワーク上に存在する前記アプリケーションデータの存在場所を特定し、
    特定した前記通信ネットワーク上の存在場所から前記アプリケーションデータを受信し、
    受信した前記アプリケーションデータからなるアプリケーションに特定処理をアプリケーションエンジンにより行わせ
    前記アプリケーションが少なくとも映像を含むセキュリティ管理情報が適用されたコンテンツを通信により取得し、
    サポートする前記セキュリティ管理情報の種類の情報を前記アプリケーションに提供し、
    前記アプリケーションが、提供された前記セキュリティ管理情報の種類が前記特定処理を行うためのセキュリティ管理情報の種類の中に存在しているかの判定を行い、存在している場合は、その種類のセキュリティ管理情報が適用される前記コンテンツの配信先を決定し、決定した配信先からのコンテンツを取得して前記特定処理を行う放送信号送受信方法。
JP2018083438A 2018-04-24 2018-04-24 放送信号受信装置および放送信号受信方法 Active JP6739467B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2018083438A JP6739467B2 (ja) 2018-04-24 2018-04-24 放送信号受信装置および放送信号受信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018083438A JP6739467B2 (ja) 2018-04-24 2018-04-24 放送信号受信装置および放送信号受信方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2020123060A Division JP6871463B2 (ja) 2020-07-17 2020-07-17 放送信号受信装置および放送信号受信方法

Publications (2)

Publication Number Publication Date
JP2019193087A JP2019193087A (ja) 2019-10-31
JP6739467B2 true JP6739467B2 (ja) 2020-08-12

Family

ID=68391030

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018083438A Active JP6739467B2 (ja) 2018-04-24 2018-04-24 放送信号受信装置および放送信号受信方法

Country Status (1)

Country Link
JP (1) JP6739467B2 (ja)

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004024869A1 (de) * 2004-05-19 2006-01-19 Siemens Ag Verfahren zur Priorisierung von Telekommunikations-Netzwerken in einem Telekommunikations-Endgerät
EP2449501B1 (en) * 2009-06-30 2020-07-22 Nokia Technologies Oy Method, apparatus and computer program product for providing protected content to one or more devices by reacquiring the content from a service
JP2011215763A (ja) * 2010-03-31 2011-10-27 Mitsubishi Electric Corp コンテンツサーバ装置及びコンテンツ配信システム
EP2596452A4 (en) * 2010-07-19 2014-05-07 Samsung Electronics Co Ltd METHOD AND APPARATUS FOR PROVIDING DIGITAL RIGHTS MANAGEMENT SERVICE
KR101854919B1 (ko) * 2010-10-07 2018-05-04 삼성전자주식회사 Drm 서비스 제공 방법 및 장치
JP2013009344A (ja) * 2011-05-20 2013-01-10 Nippon Hoso Kyokai <Nhk> 受信機
KR20130085540A (ko) * 2011-12-19 2013-07-30 삼성전자주식회사 콘텐츠 서비스를 위한 다운로드할 수 있는 디지털 저작권 관리를 수행하는 방법 및 장치
US10037414B2 (en) * 2012-12-20 2018-07-31 Google Llc Enhanced user control for content protection solutions
US20150294122A1 (en) * 2014-04-14 2015-10-15 Samsung Electronics Co., Ltd. Method and apparatus for downloadable drm in a trusted execution environment
JP6761983B2 (ja) * 2016-03-10 2020-09-30 パナソニックIpマネジメント株式会社 広告配信サーバ、番組配信サーバ及び再生端末、並びに映像配信システム

Also Published As

Publication number Publication date
JP2019193087A (ja) 2019-10-31

Similar Documents

Publication Publication Date Title
JP7363992B2 (ja) 送信方法、送信装置、受信方法、及び、受信装置
JP6739467B2 (ja) 放送信号受信装置および放送信号受信方法
JP6739466B2 (ja) 放送信号受信装置および放送信号受信方法
JP6871462B2 (ja) 放送信号受信装置および放送信号受信方法
JP6871463B2 (ja) 放送信号受信装置および放送信号受信方法
JP7013551B2 (ja) 放送信号送信装置
JP2020010290A (ja) 放送信号の送受信方法
JP7013553B2 (ja) 放送信号送信装置
JP7013554B2 (ja) 放送信号送受信装置
JP2020010293A (ja) 放送信号の受信装置
JP2020010294A (ja) 放送信号受信装置の受信方法
JP6999600B2 (ja) 放送信号送信装置
JP2020010292A (ja) 放送信号送信装置の送信方法
JP2020010291A (ja) 放送信号の送信装置
JP7013552B2 (ja) 放送信号送受信装置
JP6972280B2 (ja) 放送信号送受信装置
JP7013555B2 (ja) 放送信号送信装置
JP6510091B1 (ja) 放送信号送受信装置
JP7013260B2 (ja) 放送信号送受信装置
JP6926007B2 (ja) 放送信号送受信装置
JP7013261B2 (ja) 放送信号送受信装置
JP6171074B2 (ja) 受信装置、及びプログラム
JP2021048633A (ja) 放送信号送受信装置
JP2021061604A (ja) 放送信号送受信装置
JP2021057906A (ja) 放送信号受信装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180907

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20191126

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200127

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: 20200707

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200721

R151 Written notification of patent or utility model registration

Ref document number: 6739467

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151