JP5986993B2 - 受信機及びプログラム - Google Patents

受信機及びプログラム Download PDF

Info

Publication number
JP5986993B2
JP5986993B2 JP2013516349A JP2013516349A JP5986993B2 JP 5986993 B2 JP5986993 B2 JP 5986993B2 JP 2013516349 A JP2013516349 A JP 2013516349A JP 2013516349 A JP2013516349 A JP 2013516349A JP 5986993 B2 JP5986993 B2 JP 5986993B2
Authority
JP
Japan
Prior art keywords
application
data
unit
policy
user
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.)
Expired - Fee Related
Application number
JP2013516349A
Other languages
English (en)
Other versions
JPWO2012161125A1 (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.)
Japan Broadcasting Corp
Original Assignee
Japan Broadcasting 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 Japan Broadcasting Corp filed Critical Japan Broadcasting Corp
Publication of JPWO2012161125A1 publication Critical patent/JPWO2012161125A1/ja
Application granted granted Critical
Publication of JP5986993B2 publication Critical patent/JP5986993B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H60/00Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/09Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/14Arrangements for conditional access to broadcast information or to broadcast-related services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H60/00Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/35Arrangements 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/45Arrangements 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • H04N21/2396Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests characterized by admission policies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866Management of end-user data
    • H04N21/25875Management of end-user data involving end-user authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/4104Peripherals receiving signals from specially adapted client devices
    • H04N21/4126The peripheral being portable, e.g. PDAs or mobile phones
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/441Acquiring end-user identification, e.g. using personal code sent by the remote control or by inserting a card
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H20/00Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/28Arrangements for simultaneous broadcast of plural pieces of information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H20/00Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86Arrangements characterised by the broadcast information itself
    • H04H20/91Arrangements characterised by the broadcast information itself broadcasting computer programmes

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Bioethics (AREA)
  • Computer Graphics (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

本発明は、放送を受信する受信機及びプログラムに関する。
本願は、2011年5月20日に、日本に出願された特願2011−114051号に基づき優先権を主張し、その内容をここに援用する。
放送波を受信する受信機として、テレビ番組のデータを受信して表示する機能に加えて、付加的な機能を有するものが知られている。例えば、非特許文献1には、データ放送において、セキュリティクラスに応じて実行可能な放送用拡張関数が規定されている。この規格を用いることで、セキュリティクラスに応じて実行可能な関数を選択することが可能となる。例えば、非特許文献1(p.109−116)では、受信機のユーザに関連する情報を受信機内の不揮発性メモリに読み書きする関数が規定されている。この関数を用いることで、受信機が、ユーザに応じた処理をおこなえるようになり、ユーザの利便性が向上し得る。また、非特許文献1(p.145−163)では、通信機能を利用するための関数が規定されている。
また、現在、放送と通信とを連携した放送通信連携サービスの実現に向けた研究開発が進められている(例えば、非特許文献2)。
「デジタル放送におけるデータ放送符号化方式と伝送方式 DATA CODING AND TRANSMISSION SPECIFICATION FOR DIGITAL BROADCASTING 標準規格 ARIB STANDARD ARIB STD-B24 5.4版(第二分冊)(1/2)」、社団法人 電波産業会、平成21年12月16日 加藤久和、「Hybridcastを目指して」、NHK技研 R&D、No.123、2010年9月、p.56−63
上述した通信機能を利用するための関数を利用可能な環境や、放送通信連携サービスを利用可能な環境など、放送と通信とを連携した環境においては、様々なサービス提供者が、通信を通じて個々のユーザに応じたきめ細かなサービスを提供することが期待される。
例えば、ユーザ毎の嗜好に応じた情報を当該ユーザに提供することが期待される。
しかしながら、非特許文献1に記載された放送用拡張関数を用いても、1台のテレビを複数のユーザが共用する場合に、テレビを視聴しているユーザ毎の嗜好に応じた情報を当該ユーザに提供することはできないという課題がある。ここで、アプリケーションが、テレビを視聴しているユーザに関連する情報を取得できれば、ユーザ毎に個別のサービスを提供することができる。例えば、データ放送や放送通信連携サービスにおいて各種情報を表示する際、ユーザの嗜好、性別あるいは年齢に応じて提供する情報を選択することで、ユーザ毎に適切な情報を提供し得る。ここで、全てのアプリケーションが、全てのユーザに関する情報へアクセスし得る仕組みを構築した場合、ユーザのプライバシーを保護することができないため、ユーザに関連する情報へのアクセスを管理することが好ましい。
本発明は、このような事情を考慮してなされたもので、ユーザ毎に個別のサービスを提供しつつ、受信機を使用しているユーザに関連する情報へのアクセスを管理してユーザのプライバシー保護を図ることのできる受信機、プログラム及び受信方法を提供する。
[1] 本発明の第1の態様は、放送信号を受信する放送受信部と、ユーザの識別情報と、当該ユーザに関連するデータと、前記データへのアクセス可否の判定基準を示すポリシーとを対応付けて記憶する関連データ記憶部と、端末装置と通信を行ってユーザの識別情報を取得する通信部と、前記通信部が取得する前記ユーザの識別情報に基づいて、当該ユーザの識別情報に対応付けられた前記ポリシーを、前記関連データ記憶部から読み出し、読み出された前記ポリシーに基づいて、前記ユーザの識別情報に対応するデータへのアクセスを許可するか否かを判定するポリシー判定部と、前記アクセスが許可された場合に、前記ユーザの識別情報に対応するデータを前記関連データ記憶部から読み出すデータ読出部と、前記放送信号に含まれるアプリケーション起動指令に従ってアプリケーションを起動し、前記データ読出部が読み出したデータを用いてアプリケーションを実行するアプリケーション実行部と、を具備する受信機である。
[3] 本発明の第1の態様は、上述した受信機であって、前記ポリシー判定部は、前記読み出したポリシーに基づき、前記識別情報が示すユーザに関連するデータへのアクセスを許可するか否かを示す操作入力に従って、アクセスを許可するか否かを判定しても良い。
[5] 本発明の第2の態様は、受信機に用いられるコンピュータを、放送信号を受信する放送受信部、ユーザの識別情報と、当該ユーザに関連するデータと、前記データへのアクセス可否の判定基準を示すポリシーとを対応付けて記憶する関連データ記憶部、端末装置と通信を行ってユーザの識別情報を取得する通信部、前記通信部が取得する前記ユーザの識別情報に基づいて、当該ユーザの識別情報に対応付けられた前記ポリシーを、前記関連データ記憶部から読み出し、読み出された前記ポリシーに基づいて、前記ユーザの識別情報に対応するデータへのアクセスを許可するか否かを判定するポリシー判定部、前記アクセスが許可された場合に、前記ユーザの識別情報に対応するデータを前記関連データ記憶部から読み出すデータ読出部、前記放送信号に含まれるアプリケーション起動指令に従ってアプリケーションを起動し、前記データ読出部が読み出したデータを用いてアプリケーションを実行するアプリケーション実行部、として機能させるプログラムである。
本発明によれば、ユーザ毎に個別のサービスを提供しつつ、受信機を使用しているユーザに関連する情報へのアクセスを管理してユーザのプライバシー保護を図ることができる。
本発明の一実施形態による受信機の構成を示すブロック図である。 本発明が適用される放送通信連携システムの一例を利用する者とその関係を示す図である。 放送通信連携システムの全体構成を示す図である。 放送通信連携システムの端末連携モデルを示す図である。 放送通信連携システムのサービス種別の概念図を示す。 放送通信連携システムに使用するAITのテキスト表現の例を示す図である。 放送通信連携システムにおけるアプリケーションのライフサイクルを示す図である。 放送通信連携システムにおける事業者間のデータの流れを示す図である。 放送通信連携システム全体におけるデータの流れを示す図である。 放送通信連携システムにおけるレコメンドサービスのシーケンスを示す図である。 放送通信連携システムにおける転送プロトコルスタックを示す図である。 放送通信連携システムにおけるアプリケーション管理モデルを示す図である。 放送通信連携システムにおけるセキュアマネージャーの機能モデルを示す。 放送通信連携システムにおける画面提示制御方式の概念を示す図である。 放送通信連携システムにおける画面提示制御の基本動作モデルを示す図である。 放送通信連携システムにおけるポリシーレベルに応じた画面提示制御の例を示す。 放送通信連携システムにおける緊急地震速報受信時の提示制御の例を示す。 本発明の一実施形態による放送通信連携システムの全体構成図である。 同実施形態による受信機の内部構成を示す機能ブロック図である。 同実施形態によるアプリケーション実行制御部の詳細な構成を示すブロック図である。 同実施形態による提示制御部の詳細な構成を示すブロック図である。 同実施形態におけるユーザ関連情報のデータ構造を示すデータ構造図である。 同実施形態において、アプリケーション実行部目的データを取得する際の、受信機の動作の例を示すシーケンス図である。 同実施形態におけるユーザ関連情報の、もう1つのデータ構造を示すデータ構造図である。 同実施形態におけるポリシー情報の第1のデータ構造を示すデータ構造図である。 同実施形態におけるポリシー情報の第2のデータ構造を示すデータ構造図である。 同実施形態におけるポリシー情報の第3のデータ構造を示すデータ構造図である。 同実施形態におけるポリシー情報の第4のデータ構造を示すデータ構造図である。 同実施形態において、アプリケーション実行部目的データを取得する際に、ポリシー判定部がポリシー判定を行う場合の、受信機の動作の第1例を示すシーケンス図である。 同実施形態において、アプリケーション実行部目的データを書き込む際に、ポリシー判定部がポリシー判定を行う場合の、受信機の動作の例を示すシーケンス図である。 同実施形態において、リソース制御部がデータを書き込んだ後の、ユーザ関連情報の例を示す図である。 同実施形態において、アプリケーション実行部目的データを取得する際に、ポリシー判定部がポリシー判定を行う場合の、受信機の動作の第2例を示すシーケンス図である。
以下、図面を参照しながら本発明の実施形態を詳細に説明する。
図1は、本発明の一実施形態による受信機の構成を示すブロック図である。図1に示すように、受信機4は、分離部402、通信入出力部411、アプリケーション実行制御部412、ローカル情報記憶部(関連データ記憶部)416及び外部インタフェース部(通信部)417を含む。アプリケーション実行制御部412は、アプリケーション記憶部431、アプリケーション制御部434、アプリケーション実行部435及びリソース制御部(データ読出部)439を含む。アプリケーション実行部435は、ログイン処理部461を備え、リソース制御部439は、利用状態判定部464と、アクセス制御部462と、ポリシー判定部463とを含む。
外部インタフェース部417は、端末装置と通信を行って、ユーザの操作入力を取得する。例えば外部インタフェース部417は、無線LANを介して自身に接続された端末装置と通信を行う。
ローカル情報記憶部416は、後述するように、ユーザの識別情報と対応付けてデータを記憶する。
ログイン処理部461は、ユーザのログインおよびログアウトを実行する。
利用状態判定部464は、ユーザのログイン状況に従って、利用状態情報を生成する。
リソース制御部439は、利用状態判定部464が生成する利用状態情報に対応付けられたデータを、ローカル情報記憶部416から取得する。
ポリシー判定部463は、リソース制御部439がローカル情報記憶部416からデータを取得する前処理として、データへのアクセス可否の判定基準を示すポリシーに基づいて、データ取得可否を判定する。
アクセス制御部462は、リソース制御部439のローカル情報記憶部416へのアクセスを制御する。
さらに詳細には、図22〜図29を用いて後述する。
[本発明が適用される放送通信連携システムの一例の説明]
ここで、本発明が適用される放送通信連携システムの一例について説明する。本発明が適用される放送通信連携システム(放送通信融合システム、放送通信システム、送受信システム)の一例は、例えば、Hybridcast(登録商標)(ハイブリッドキャスト)システムであり、放送通信連携サービス(Hybridcast(登録商標)サービス、放送通信融合サービス、放送通信サービス)を提供する。本発明が適用される放送通信連携システムの一例が実現する放送通信連携サービスは、デジタル放送サービスと、インターネットなどによる通信サービスとを連携する。例えば、放送通信連携サービスでは、デジタルテレビやパーソナルコンピュータ、携帯端末などの受信機は、放送により伝送された放送番組(以下、「番組」とも記載する。)の表示画面(以下、番組の表示画面の「放送画面」とも記載する。)に、この受信機に実装されているアプリケーションが通信により取得したサービスやコンテンツの表示画面(以下、「アプリケーション画面」、「アプリケーションの表示画面」とも記載する。)を合わせて同時に表示する。
[1. システムモデル]
[1.1 放送通信連携システムの利用者]
図2は、放送通信連携システムを利用する者とその関係を示す図である。
編成を伴う番組を送出する放送局は、放送電波あるいは通信網により番組を視聴者に配信する。放送局は、放送通信連携サービスを充実するために、番組に関連するメタデータをサービス事業者に提供する。
放送通信連携サービスを提供するサービス事業者は、視聴者に放送通信連携サービスを提供するためのコンテンツとアプリケーション(以下、「アプリ」とも記載する。)を制作し、配信する。以下では、単に「アプリケーション」と記載した場合、放送通信連携サービスを提供するためのアプリケーション(放送通信連携サービスのアプリケーション)を指す。コンテンツまたはアプリケーションの制作者と配信者が同一のサービス事業者である必要はない。放送局がサービス事業者を兼ねてもよい。サービス事業者は、他のサービス事業者へのリンク情報を提供することも可能である。サービス事業者は、提供するアプリケーションが公式であることを示すために、システム管理者にアプリケーションの登録を申請し、承認を得ることができる。承認されたアプリケーションは、受信機上での動作に制限を受けない。一方、承認されないアプリケーションが表示させる画面は、番組の表示画面および音声にオーバーラップすることはできないが、アプリケーションの表示画面を縮小して放送番組の画面の外に表示することができる。承認されたアプリケーションを公式アプリケーション、承認されないアプリケーションを非公式アプリケーションという。なお、公式アプリケーションを、登録アプリケーション、認証済アプリケーション、認定アプリケーション、公認アプリケーション、オーソライズドアプリケーション、A(Authorized)タイプアプリケーション、Aアプリケーションとも呼ぶ。また、非公式アプリケーションを、一般アプリケーション、非認証アプリケーション、非認定アプリケーション、非公認アプリケーション、U(Unauthorized)タイプアプリケーション、Uアプリケーションとも呼ぶ。
システム管理者は、視聴者に提供するアプリケーション(受信機アプリ)が公式であることを認定する機関である。申請されたアプリケーションを承認するか否かのシステム管理者の判断は、放送局からの委託による。
受信機メーカは、受信機を製造し、販売する。受信機メーカは、受信機の各種設定等を行なうためのアプリケーションを受信機にインストールしておくことによって、受信機を動作可能とすることができる。この際、受信機におけるアプリケーションの表示画面が番組の表示画面(映像)にオーバーラップしてもよい。
放送局により放送された番組を視聴する視聴者は、放送通信連携サービスを享受する。
視聴者は、自身の意思により、アプリケーションをダウンロードしたり、起動したりすることができる。また、視聴者は、自身の意思により、アプリケーションの表示画面を番組の表示画面(映像)にオーバーラップさせることができる。
[1.2 放送通信連携システムのシステム構成]
図3は、放送通信連携システムの全体構成を示す図である。放送通信連携システムは、電波を利用した現行の放送局設備に、機能的に「放送局サーバ群」、「サービス事業者サーバ群」、「受信機」を加えて構成される。
放送局は、放送局設備を保有する。さらに放送局は、放送局サーバ群あるいはサービス事業者サーバ群の両方を構成し、管理運営する。また、サービス事業者は、サービス事業者サーバ群を構成し、管理運営する。システム管理者は、リポジトリサーバを管理運営する。受信機メーカは、受信機を製造販売する。視聴者は受信機を保有し、放送通信連携サービスを享受する。
受信機(Hybridcast(登録商標)受信機、放送受信通信装置)は、標準化された共通のAPI(アプリケーションプログラムインタフェース:Application Program Interface)を搭載する。また、受信機は、地上デジタル放送、BS(broadcasting satellite)デジタル放送等の現行方式の放送を受信する。
放送局設備は、放送通信連携サービスを起動するための信号を放送波に多重化する。多重化の方式については後述する。
[1.3 放送局サーバ群の構成例]
放送局サーバ群は、放送局が持っているコンテンツやメタデータを管理し、配信する。
例えば、放送局サーバ群は、各種サーバ、データ蓄積部(DB(データベース))及びAPIを含み、放送局サーバ群のサーバは、コンテンツ管理サーバ、視聴者管理サーバ、コンテンツ配信サーバ、放送局サービスサーバを含む。
コンテンツを管理するコンテンツ管理サーバは、放送コンテンツである番組とメタデータを管理する。コンテンツ管理サーバには、放送された番組または放送される番組を管理する番組管理サーバや、番組に関連するメタデータを管理するメタデータ管理サーバが含まれる。メタデータは、例えば、番組タイトル、番組ID、番組概要、出演者、スタッフ、放送日時、台本、字幕、解説などを示す。
視聴者管理サーバは、視聴者(ユーザ)を管理し、コンテンツ配信サーバは、通信によりコンテンツデータを配信する。放送局サービスサーバは、放送局がサービス事業者に対してサービスを提供するためのサーバである。放送局サービスサーバが提供するサービスには、例えば、放送局が運営するソーシャルネットワークサービスや、放送番組毎のウェブログ(ブログ)などがある。
放送局サーバ群のデータ蓄積部は、放送局が持っているコンテンツ、メタデータを格納する部分とデータベースから構成される。蓄積されたデータには、管理しているサービス事業者のみがアクセス可能であり、他者からはアクセスできないように制限している。
放送局サーバ群のAPIは、サービス事業者サーバ群からの要求に応じてデータを提供するためのAPIである。APIは、アプリケーションがサービスを受けるために呼び出すプログラムおよびその実行部である。
[1.4 サービス事業者サーバ群の構成例]
サービス事業者が管理運営するサービスサーバ群は、アプリケーションとコンテンツを管理し、提供する。サービスサーバ群は、受信機アプリサーバ、サービスサーバ、コンテンツ配信サーバ、データ蓄積部(DB(データベース))及びAPIを含む。
受信機アプリサーバは、放送通信連携サービスのアプリケーションを管理するサーバである。サービス事業者は、受信機で動作するアプリケーションを保存、管理、配信する。
サービス事業者は、団体または個人で構成される。受信機アプリサーバは、受信機からの要求により、アプリケーションファイル(アプリケーションファイルについては後述する。)の保存場所を受信機に知らせるとともに、アプリケーションファイルを配信する。
サービスサーバは、受信機で動作しているアプリケーションからの要求によりサービスを提供するサーバである。サービスサーバには、例えば、多言語字幕サーバ、話速変換音声サーバ、ソーシャルTVサーバ、レコメンドサーバ、番組レビューサーバ、ブックマークサーバなどがある。
コンテンツ配信サーバは、受信機で動作しているアプリケーションからの要求によりコンテンツを提供するサーバである。コンテンツ配信サーバには、例えば、VOD(VideoOn Demand)配信サーバ、字幕配信サーバ、マルチビュー配信サーバなどがある。
サービス事業者サーバ群のデータ蓄積部は、コンテンツデータ、メタデータ、サービス事業者が作成したデータ、視聴者データ、アプリケーションファイルを保存する場所である。データ蓄積部に保存されたデータには、管理しているサービス事業者のみがアクセスでき、他者からはアクセスできない。
サービスサーバ群のAPIは、受信機で動作しているアプリケーションからの要求により、アプリケーションファイル、コンテンツ、サービスを提供するためのAPIである。
[1.5 受信機]
受信機は、現行方式の放送を受信し表示するとともに、放送通信連携サービスを実行する。現行方式の放送とは、地上デジタル放送、BSデジタル放送等の衛星放送、データ放送である。また、受信機は、インターネットに接続される。
受信機は、受信する放送波に多重された情報をもとにして、サービス事業者サーバにアプリケーションのダウンロード要求を行う。受信機が、ダウンロードしたアプリケーションファイルに含まれるアプリケーションプログラムを実行することによって、受信機上でアプリケーションが動作する。受信機上で動作しているアプリケーションは、サービス事業者サーバにアクセスしてコンテンツを取得する。
また、受信機は、同期機能、アプリ制御機能など放送通信連携サービスを実行するために必要な機能である放送通信連携機能を持つ。放送通信連携機能に対するAPIは共通化されているため、アプリケーションの制作が容易であるとともに、アプリケーションは受信機に依存しない。
放送通信連携サービスでは、パーソナルコンピュータや携帯端末などのデバイスとの連携のための機能も取り入れている。
放送通信連携機能には、放送通信連携基本機能と、必要に応じて実装するオプション機能とがある。受信機メーカは、放送通信連携基本機能を全ての受信機に実装する。アプリケーションは、APIを通して放送通信連携機能を利用する。放送通信連携機能は、後述するAPIに基づき動作する。
受信機が実装するAPIは、受信機に依存することなく、アプリケーションの動作が同じになるようにするために規定される。全てのアプリケーションは、APIを通して受信機の処理を行なうため、APIを介さずにアプリケーションが受信機固有の機能にアクセスすることはできない。
[1.6 端末連携モデル]
図4は、放送通信連携システムの端末連携モデルを示す図である。
受信機は、携帯端末などの端末と連携してサービスを提供することができる。連携する端末には、例えば、パーソナルコンピュータ、携帯電話、タブレット、スマートフォン、PDA(Personal Digital Assistant)などがある。受信機は、受信機機能として他の端末が利用可能な機能をAPIとして提供する。この他の端末が利用可能な機能を提供するAPIを端末連携APIという。例えば、携帯端末上で動作するアプリケーションは、端末連携APIを利用することで、番組情報の取得などの放送リソースにアクセスしたり、再生制御等の受信機機能を呼び出したりすることができる。
[1.6.1 端末連携API]
端末連携APIは、他の端末やその端末上で動作するアプリケーションが受信機の機能を利用するためのAPIである。連携する端末は、ホームネットワーク(LAN)上の端末及びインターネットを通してアクセスする端末を対象とする。各種動作を提供するAPIの規定は後述する。
[1.6.2 端末連携API提供プロセス]
受信機上で動作する端末連携API提供プロセスは、端末連携APIを動作させる。端末連携API提供プロセスは、常駐して動作する一種のデーモンプロセスのように動作する。
[1.6.3 APIを呼び出すプロトコル]
端末連携APIを呼び出すプロトコルには、例えば、RESTful(REST:Representational State Transfer)、UPnP(Universal Plug and Play)、XMPP(eXtensible Messaging and Presence Protocol)などが用いられる。
[1.6.4 プッシュ通知(Notification)機能]
受信機は、インターネット上のサーバ等が受信機に対してプッシュで情報を通知するNotification(通知)機能にも対応する。受信機はサーバ等からのプッシュにより通知された情報を受信する。Notification機能によって、なんらかの受信機動作を制御する場合があり、Notification機能も端末連携API仕様の一部として規定される。
[2. 放送通信連携アプリケーション]
[2.1 サービスとアプリケーションモデル]
放送通信連携システムのアプリケーションモデルは、DVB−GEM1.2のアプリケーションモデルの考え方をベースに追加、変更したモデルである。
[2.1.1 放送通信連携アプリケーション]
放送通信連携サービスのアプリケーションの動作は、AV(Audio Visual)コンテンツに連動した動作(連動)と、アプリケーション単独での動作(非連動)の2つのパターンに分類される。AVコンテンツとは、放送コンテンツ(番組)または通信コンテンツ(VoD等)である。
連動の場合、起動などのアプリケーションのライフサイクル制御は、放送または通信コンテンツに連動して行われる。アプリケーションは、AVコンテンツと一緒に配信されるAIT(Application Information Table)(アプリケーション情報テーブル、アプリケーション起動情報)をもとに起動される。この場合、視聴者による起動や終了の操作に加え、放送事業者などのAVコンテンツの提供者がアプリケーションの自動起動や、終了などのライフサイクルを制御することも可能である。
一方、非連動の場合、放送や通信コンテンツに連動せずに、アプリケーション単独で起動、終了される。この場合、アプリケーションの開始や終了などのアプリケーションのライフサイクルは、視聴者によってのみ制御される。
[2.1.2 サービス]
従来、サービスとは、放送事業者が編成し、スケジュールの一環として放送可能な番組の連続のことをいうが、放送通信連携システムにおいてはこの考え方を拡張し、ストリーム従属型サービスと独立型サービスの2つのサービス種別を定義する。
図5は、サービス種別の概念図を示す。
受信機において、ストリーム従属型サービス及び独立型サービスを擬似的に選局することで、関連するアプリケーションが起動することになる。
ストリーム従属型サービスは、従来の意味でのサービスの考え方を拡張したものであり、放送や通信で伝送するAVストリームに、それに連動して動作するアプリケーション(複数可)を加えて構成される。AVストリームの選択・再生(放送の場合は選局)によって連動してアプリケーションを起動することができる。
一方、独立型サービスは、映像・音声のストリームは含まず、アプリケーション(複数可)のみで構成される。視聴者が独立型サービスを選択することで、アプリケーションが起動される。
[2.1.3 オンザフライで取得するアプリ起動とインストールしたアプリの起動]
アプリケーションの起動には、オンザフライでアプリケーションファイルを取得して起動する方法と、予め受信機に蓄積(インストール)しておいたアプリケーションファイルを起動する方法の2つがある。オンザフライとは、アプリケーションの実行時に通信によってアプリケーションファイルを取得する方法であり、非インストール型、直接実行型ともいう。
なお、受信機は、後述するAITによるアプリケーションの周知をもとに、ローカルのファイルシステムにあるアプリケーションファイルのアプリケーションプログラムを起動する。受信機は、通信によりアプリケーションファイルを取得してインストールする際、関連するAITに設定されているロケーション階層内の情報(2.5.1節参照)をローカルのファイルシステム上のロケーションに書き換え、必要に応じて独立型サービスを識別する値(独立型サービスのAIT単位で必要)を生成する動作などが必要となる。
[2.2 アプリケーションの周知法(シグナリング)]
[2.2.1 アプリケーション起動情報(AIT)]
サービスに含まれるアプリケーションの周知は、サービス選択時に通知されるアプリケーション起動情報によって行う。アプリケーション起動情報としてARIB STD−B23(以下、ARIB−Jと記載)で定義されているAITを用いる。ストリーム従属型サービス、独立型サービスそれぞれで、そのサービス用のAITが周知される。各サービスにおけるAITの送り方の詳細を以下に示す。
図6は、放送通信連携システムに使用するAITのテキスト表現の例を示す図である。
放送通信連携システムにおいて使用するAITは、ARIB−Jで規定されるAITをベースとする。AITには、SI(Service Information)のテーブルで伝送するためのバイナリ表現と、XML(extensible markup language)形式によるテキスト表現(AIT File)とが存在し、図6では、テキスト表現の例を示している。AITには、アプリケーションを特定するアプリケーションID(applicationIdentifier)、アプリケーション状態を制御する制御コード(controlCode)、アプリケーションファイルの格納位置(格納場所)を示すロケーション情報(location)などが記述される。
[2.2.2 AVコンテンツに連動するアプリケーションの周知]
AVコンテンツに連動するアプリケーションの周知は、MPEG(Moving Picture Experts Group)−2 TS(トランスポートストリーム:Transport Stream)で伝送するAVコンテンツにAITを多重する場合と、別途AITの情報を送る場合がある。AVコンテンツと連動させてAITを伝送することにより、受信機において、放送番組に連動するアプリケーションの起動や、番組の進行に連動したダイナミックなアプリケーションの起動などのライフサイクル制御が可能となる。
周知方法には、例えば、(1)AIT用のES(エレメンタリーストリーム:Elementary Stream)追加、(2)EIT(イベント情報テーブル:EventInformationTable)への記述子追加、(3)カルーセルでの伝送、(4)通信でのAITファイルの取得、(5)通信でのダイナミックなAITファイルの伝送、などがある。
(1)AIT用のES追加の場合、ARIB−Jにおける規定と同様にAITのESを放送TSに多重する。
(2)EITへの記述子追加の場合、後述する提示制御と同様に、EIT(p/f)への記述子を追加し、AITで伝送される情報と同じ情報を伝送する。
(3)カルーセルでの伝送の場合、DSM−CC(Digital Storage Media Command and Control)データカルーセルでAITを伝送する。例えば、特定のモジュールでAITファイルを伝送する。カルーセルで伝送することで、取得時間のオーバーヘッドが想定されるが、現行の放送信号を変更する必要がない。
カルーセルでの運用例として、放送通信連携起動ファイル伝送用カルーセルのコンポーネントタグ、モジュールを固定する。例えば、コンポーネントタグに「AA」を、モジュールIDに「0000」を設定し、モジュールのType記述子にAITであることを示すタイプを設定する。受信機は、モジュールの更新を監視し、更新を検出するとAITを読み直し、AITにより指定された制御(アプリケーションのライフサイクル制御)を実行する。
(4)通信でのAITファイルの取得の場合、AVコンテンツの選択と同時に、別に用意されたAITファイルを取得する。例えば、再生するAVコンテンツの情報(コンテンツID)とアプリケーション起動情報(AIT)が記述された情報を起点に両者を取得する。サーバ型放送(ARIB TR−B27)の利用単位コンテンツやエントリーコンポーネントの考え方を利用することができる。
(5)通信でのダイナミックなAITの伝送の場合、AVコンテンツを再生中に、新たなアプリケーションを起動したり、起動中のアプリケーションを終了させたりする制御を通信で伝送するAITにより行う。なお、予め想定されていないタイミングでの制御を行なう場合、通信を経由したプッシュによる通知を行なう。
[2.2.3 独立して動作するアプリケーションの周知]
受信機は、独立して動作するアプリケーションの起動情報を含むAITを通信により取得する。独立アプリケーションは、既知のアプリケーションリポジトリから取得する。個々の独立アプリケーションの起動情報を取得するまでの手順を以下に示す。
(1)受信機にアプリケーションリポジトリのロケーションをセットする。出荷時に予め設定してもよく、複数のリポジトリを後から何らかの方法で追加してもよい。
(2)アプリケーションメニューを開くと、受信機はアプリケーションリポジトリからアプリケーションのリスト(各アプリのAITのロケーション記述を含む)を取得し、メニューにアプリを表示する。
(3)視聴者が選択したアプリケーションのAITを通信から取得する。
上記の手順は、リポジトリが提供するWEB(ウェブ) APIを利用して実行される。また、独立して動作するアプリケーションは、AVコンテンツと連動して動作するものではないため、予め指定したタイミングでの動的なライフサイクルコントロールは行わない。予め指定されていないタイミングでの制御(終了など)は、通信経由でのプッシュでの通知(Notification)により行なう。
[2.3 アプリケーションの起動と終了]
[2.3.1 アプリケーションのライフサイクル]
[2.3.1.1 ライフサイクル]
図7は、アプリケーションのライフサイクルを示す図である。
アプリケーションの状態は、ARIB−Jにおけるアプリケーションの状態に準じ、「Not Loaded(ロード前)」、「Loaded(ロード後)」、「Paused(休止)」、「Started(開始)」、「Destroyed(破壊)」の5つの状態を持つ。これら5つの状態において、アプリケーションがロード、実行されて終了するまでの一連の過程をアプリケーションのライフサイクルと呼び、各状態間の遷移の制御をライフサイクルコントロールと呼ぶ。
[2.3.1.2 AVコンテンツに連動するアプリケーションの基本的ライフサイクル制御]
AVコンテンツに連動するアプリケーションのライフサイクルの制御は、ストリーム従属型サービスの選択を通して行われることを基本とする。
ストリーム従属型サービスの選択は視聴者によって行われる。サービスは、AVコンテンツやアプリケーションを含む一連のコンテンツのセットであり、アプリケーションと一緒に送られるAITに含まれる制御コードよって起動や終了などのライフサイクルが制御される。一つのサービスに複数のアプリケーションが含まれ、それらが同時に動作する場合もある。
アプリケーション起動のトリガとなるサービスの選択は、受信機APIを通してアプリケーションから制御する場合や、受信機のレジデントアプリケーションとしてのナビゲータから制御する場合、放送サービスの場合はリモコンボタンを制御する場合、などがある。サービス切り替え時に、切り替え前後のサービスに含まれるコンテンツ(AVコンテンツやアプリケーション)の提示が切り替えられる。切り替え前後のサービスに含まれるアプリケーションが異なる場合は、切り替え前に起動していたアプリケーションはサービス切り替えによって終了し、切り替え後には異なるアプリケーションが起動可能となる。これらの動作の詳細は、2.4節に後述する。
[2.3.2 アプリケーションの起動]
[2.3.2.1 AITによる起動]
受信機においてサービス(ストリーム従属型サービス、独立型サービス)が選択されたとき、サービスと共に提供されるAITに含まれる制御コードで「auto-start」が指定されたアプリケーションは、視聴者からの明示的なアクションなしでサービス選択とともに自動的に起動する。サービス選択中は、そのサービスに対するアプリケーションシグナリングによってライフサイクルが制御される。例えば、放送サービスの場合は、放送と共に伝送されるAITを受信機が常に監視し、その変化に対応する。このように、AITの伝送などのアプリケーションシグナリングによって、受信機において新たなアプリケーションを途中で自動起動(auto-start)するよう制御できる。
AITによるアプリケーション起動情報において「auto-start」が指定されていないアプリケーションは、自動的には起動されず、視聴者による明示的な起動が必要となる。この明示的な起動は、受信機のレジデントアプリケーションのアプリケーションローンチャーによって行われる。例えば、放送サービス選択時に、リモコンの放送通信連携サービスボタンを押すことで、受信機においてアプリケーション起動用のメニューが開き、現在の放送(通信)サービスに連動するアプリケーション一覧が表示される。ここで視聴者は、受信機に対して、起動したいアプリケーションを選択・起動する操作を行う。
[2.3.2.2 放送通信連携アプリケーションからの起動]
サービス内で複数のアプリケーションを起動できるため、起動済のアプリケーションから同じサービスに含まれる他のアプリケーションを起動することもある。ARIB−Jアプリケーション実行環境では、アプリケーションIDを指定することにより他のアプリケーションを起動するAPIが規定されている。その他の実行環境の場合も、同様の機能をもったAPIを規定する。
[2.3.2.3 BML(Broadcast Markup Language)からの起動]
受信機は、放送通信連携アプリケーション実行環境に加えて、現行のBMLデータ放送の実行環境を備えることから、BMLのAPIとして放送通信連携アプリケーションの起動を制御するAPIを追加する。なお、BMLは、ARIB STD B24に規定されるマルチメディア符号化方式であり、現行の日本の地上・BS・CSデジタル放送におけるデータ放送方式として採用されている。
[2.3.2.4 独立して動作するアプリケーションの起動]
独立型サービスは、アプリケーションのみを含む仮想的なサービスであり、独立アプリケーションを選択することで、2.3.2.1節のAITによる起動と同じメカニズムによりAITを取得してアプリケーションが起動される。ただし、独立型サービスでは、少なくとも1つのauto-startアプリケーションが起動される。独立型サービスの選択は、例えば、アプリケーションローンチャーから行う。
[2.3.3 アプリケーションの終了]
[2.3.3.1 AITによる終了]
起動されたアプリケーションは、そのサービスに対するアプリケーションシグナリングによってライフサイクルが制御される。例えば、放送の場合は、放送と共に伝送されるAITを受信機が常に監視し、起動中のアプリケーションに対して制御コードdestroyを指定することで、アプリケーションを終了する。通信で伝送するストリーム従属型サービスにAITが多重されている場合も、連動するアプリケーションの終了制御が可能である。
[2.3.3.2 アプリケーション自身による終了]
アプリケーション自身が、終了用のAPIを用いて自ら終了する。
[2.3.3.3 他のアプリケーションによる終了]
アプリケーションが実行するアプリケーション終了用のAPIを用いて、起動中の他のアプリケーションを終了させる。この場合、他のアプリケーションを終了させる適切なセキュリティポリシーが必要である。
[2.3.3.4 別のサービスへの切替え時の終了]
受信機における別のサービスへの切り替え時、ストリーム従属型サービスに含まれるアプリケーションのうち、切り替え前のサービスに含まれるアプリケーションは終了し、新しいサービスでシグナリングされたアプリケーションが起動される。切り替え前後のサービスに同じアプリケーションが含まれる場合は、動作を継続することも可能とする。これは、AIT中のフラグで制御する。ストリーム従属型サービスに含まれるアプリケーションであるサービスバウンドアプリケーションの詳細は、4.2節に後述する。
[2.3.3.5 受信機による終了]
受信機は、指定したアプリケーションを受信機機能により終了する。例えば、受信機が起動中のアプリケーション一覧を表示し、視聴者の選択によって指定のアプリケーションを終了させる。
[2.3.3.6 動的なアプリケーション終了]
アプリケーションの終了を動的に制御するため、アプリケーションの終了を指示するAITのファイルを受信機に送信する。この場合、AITをプッシュ通知(Notification)する。
[2.3.4 複数アプリケーションの起動]
[2.3.4.1 同一サービス内でシグナリングされたアプリケーション]
受信機は、同一のサービスにおいてAITにリストされたアプリケーションを同時実行させることができる。
[2.3.4.2 AVコンテンツに連動するアプリケーションと独立して動作するアプリケーションの同時起動]
AVコンテンツに連動するアプリケーションは、ストリーム従属型サービス内でしか起動されない。一方、独立して動作するアプリケーションは、任意のタイミングでAVコンテンツに連動するアプリケーションや独立して動作する他のアプリケーションと同時に起動可能とする。
[2.3.4.3 複数アプリケーション起動時のリソース管理]
複数のアプリケーションが起動する場合、それらが同じ受信機のリソース(例えばディスプレイ)を必要とする場合がある。受信機は、リソースマネージャなどの仕組みを備えて、適切にリソースを割り振ったり、リソースが使用出来ない場合はアプリケーションの実行をやめたりするなどの動作を行う。
[2.4 アプリケーションのバウンダリ]
[2.4.1 バウンド/アンバウンドの基本的な扱い]
アプリケーションは編成サービスに紐付いた(対応付けられた)バウンドアプリケーションと紐付かない(対応付けられていない)アンバウンドアプリケーションの2種類がある。バウンドアプリケーションがどの編成サービスと紐付いているかは、当該アプリケーションの起動情報を含んでいるAITがどの編成サービスから得られたかで判定する。
バウンドアプリケーションは、紐付いている編成サービスを受信しているときに実行可能な状態になる。つまり、当該編成サービスからAITによって起動され、当該編成サービスの受信が終了したとき(受信している編成チャンネルが変更されたとき)には実行が終了する。バウンドアプリケーションから起動された別のアプリケーションもバウンドアプリケーションとして扱う。関連する一連のバウンドアプリケーション群の大本である最初に起動されたアプリケーションが終了したときには、それによって起動された他のアプリケーションも終了する。
アンバウンドアプリケーションは編成サービスに紐付いていないので、受信している編成サービスを変更してもアプリケーションの実行は継続される。編成サービスからはアプリケーションを起動するためのAITが得られないので、他の手段(例えば、アプリケーションと紐付いているAIT File(ファイル)を、アプリケーションローンチャー等を用いて入手するなど)によって起動情報が受信機に与えられ、起動される。アンバウンドアプリケーションから起動された別のアプリケーションもアンバウンドアプリケーションとして扱う。アプリケーションは、視聴者の操作によって明示的に終了することが基本であるが、受信している編成サービスから全てのアプリケーションを終了させる指示(KILLALL)がAITによって与えられた場合にも終了する。
[2.4.2 アンバウンドアプリケーション固有の扱い]
アンバウンドアプリケーションは編成サービスと紐付かないが、2.3.2.4節で示すように、仮想的な編成サービス(受信機の起動時に受信機内に生成される)に紐付けることにより、バウンドアプリケーションと同じ起動処理メカニズムが適用できる。
仮想的な編成サービスの生成方法は受信機の実装依存であり、その編成サービスにどのような識別値を与えるかは受信機実装によって異なる。しかし、アプリケーションファイルを受信機内に蓄積しておいて任意のタイミングでアプリケーションローンチャーから起動できるようにしておく場合、仮想的な編成サービスを識別するIDやアプリケーションファイルの取得先(サービス事業者サーバないしはリポジトリから取得したAITには当該サーバが取得先として記述されているので、受信機内の蓄積領域から取得するように変更する必要がある)などが受信機実装に合うようにAITの内容を受信機が更新する必要がある。
[2.5 アプリケーションの取得方法]
[2.5.1 AITをもとにした取得]
上記の記述のとおり、全てのアプリケーションの起動情報はAITにより与えられる。
アプリケーションファイルの取得は、AITに含まれるアプリケーションのロケーション情報により指示される。例えば、図3の例ではロケーション情報は、「/ApplicationList/Application/applicationSpecificDescriptor/dvbjDescriptor/location」の階層に記述される(XMLとしてはlocation要素の内容として記述される)。ロケーション情報の記述は、例えば、「http://192.168.11.37/demo.jar」となる。
上記は、HTTP(Hypertext Transfer Protocol)プロトコルを用いて、demo.jar(Java(登録商標)のアプリケーションアーカイブ)を取得する例である。使用するトランスポートプロトコルや、アプリケーションのパッケージフォーマットについては、後述する。
[2.5.2 アプリケーションのパッケージフォーマット]
アプリケーションのパッケージフォーマットは、アプリケーションフォーマット(Java(登録商標)やHTML5)などに依存する。受信機は、何らかのひとかたまりになったファイル、もしくはエントリーファイルを取得することによって、アプリケーション起動に必要な一連のファイル(プログラム本体や画像ファイルなど)を取得する。この一連のファイルがアプリケーションファイルである。例えば、アプリケーションファイルには、一連のファイルを圧縮したもの(zipファイル等)、Jarファイル(Java(登録商標)実行環境)、エントリーのHTMLファイル(HTML5実行環境の場合)、独自に規定したエントリーファイルなどのフォーマットが使用される。
[2.5.3 アプリケーションの伝送方法]
アプリケーションファイルをネットワーク経由で取得する際の伝送方法には、HTTPプロトコルによる取得と、FILEプロトコルによる取得とがある。
HTTPプロトコルによる取得の場合、GETメソッドにより取得する。AITのロケーションの指定は、「http://〜」とする。
一方、FILEプロトコルによる取得の場合、受信機のローカルに保存された(インストールされた)アプリケーションファイル(アプリケーションプログラム)を指定するときには、AITのロケーションの指定を「file:///〜」とする。
[3. インタフェース条件]
[3.1 放送波の放送通信連携サービス制御信号]
放送波には、2.2.2節で前述したアプリケーション起動情報を送出するメカニズムが必要である。さらに、緊急警報放送時などを想定して、全てのアプリケーションを強制終了させるために、ARIB STD−B23第二部 10.16.3.2節で規定するAITのアプリケーション制御コード(application_control_code)に「KILLALL」を追加する。表1は、追加する制御コード「KILLALL」の意味を示す。
[表1]
Figure 0005986993
また、アプリケーションとAVコンテンツの関係からアプリケーションの提示制御を行うために、EIT、AITに記述子を追加する。詳細は4.3節に後述する。
[3.2 放送局サーバ群API]
図8は、放送通信連携システムにおける事業者間のデータの流れを示す図であり、図9は、放送通信連携システム全体におけるデータの流れを示す図である。
ここでは、図8に示す、放送局サーバ群とサービス事業者サーバ群のサービス毎のサーバとの間、放送局サーバ群と放送通信連携基盤サーバとの間、及び、放送通信連携基盤サーバとサービス事業者サーバ群のサービス毎のサーバとの間のAPIの規定、図9に示す、受信機制御と放送通信連携基盤サーバとの間、メタデータとサービス毎のサーバとの間のAPIについて述べる。
[3.2.1 API]
放送局サーバ群を構成する各サーバである放送局サーバと、サービス事業者サーバ群を構成する各サーバであるサービス事業者サーバとの間の通信はREST形式とする。また、放送局サーバとサービス事業者サーバとの間は、提供するサービスに応じてサーバのディレクトリー構成が異なることが予想されるため、APIは双方間で取り決める。放送局サーバ及びサービス事業者サーバのURLの例を以下に示す。
http://hybridcast.org/{放送局名}/{サーバ名}/{コンテントID}/{管理するデータ}/{ソート方法}/{先頭アイテム},{個数}/?{パラメータ}={値}/
[3.2.2 レコメンドサービス]
図10は、レコメンドサービスのシーケンスを示す図である。サービス事業者サーバ群と、放送局サーバのインタフェース部との間で使用されるメソッドは、「GET」、「POST」、「PUT」、「DELETE」である。コマンドフォーマットの例を以下に示す。
(1)http://hybridcast.or.jp/{放送局名}/(サーバ名)/{コンテントID}/{管理するデータ}/{ソート方法}/{先頭アイテム},{個数}/
(2)http://hybridcast.or.jp/{放送局名}/(サーバ名)/{視聴者ID}/{管理するデータ}/{ソート方法}/{先頭アイテム},{個数}/
(3)http://hybridcast.or.jp/{放送局名}/(サーバ名)/{レビューID}/{管理するデータ}/{ソート方法}/{先頭アイテム},{個数}/
また、パラメータには、{放送局名}、{サーバ名}、{コンテントID}、{視聴者ID}、{レビューID}、{管理するデータ}、{ソート方法}、{先頭アイテム}、{個数}等々がある。
[3.2.3 管理対象のデータ]
管理対象のデータには、コンテンツ情報、ユーザ情報、ユーザ・ジェネレイテッド・コンテンツ情報、デバイス情報、認証情報がある。
コンテンツ情報は、タイトル、概要、ジャンル、放送日時、放送時間(尺)、映像モード、音声モード、字幕データ、台本、出演者、音楽、制作者、製作会社、著作、推薦番組、動画URI、再生回数、CM、タイムスタンプ情報、等を示すデータを含む。ユーザ情報は、ユーザ(視聴者)の名前、年齢、性別、地域、レビュー書込み数、コメント書込み数、お気に入り、フレンドリスト、再生場所(時刻)、再生終了場所(時刻)、番組視聴履歴等を示すデータを含む。ユーザ・ジェネレイテッド・コンテンツ情報は、コンテンツID、ユーザID、レビュー内容、レビュー書込み時刻、レビュー評価、等を示すデータを含む。デバイス情報は、デバイスIDを含む。認証情報は、認証IDを含む。
[3.3 トランスポートフォーマット]
[3.3.1 通信で扱う映像/音声について]
通信で扱う映像や音声は、デジタルテレビネットワーク機能仕様 ストリーミング機能仕様書 プロトコル編V1.1(デジタルテレビ情報化研究会)に準拠する。
[3.3.1.1 映像・音声のモノメディアフォーマットとの関連]
MPEG−2 VideoあるいはH.264/MPEG−4 AVC(Advanced Video Coding)で符号化された映像と、MPEG−1 Audio Layer II、MPEG−2 Audio AACで符号化された音声、および字幕等の多重化には、TTS(Timestamped Transport Stream)形式を使用する。ただし、MPEG2−TS、MMT(MPEG Media Transport)、MP4等も使用可能である。
[3.3.1.2 転送プロトコル関係]
図11は、転送プロトコルスタックを示す図である。
ストリーム伝送は、RTP(Real-Time Transport Protocol)/UDP(User Datagram protocol)およびHTTP/TCP(Transmission Control Protocol)を用いる。なお、RTP/UDPを用いる場合、オプションとして、誤り訂正の情報を伝送してもよい。また、HTTP/TCPを用いる場合、HTTPのコネクション、メソッド、ヘッダを利用してストリーム制御を行う。伝送がRTP(Real-time Transport Protocol)で行われる場合、ストリーム制御情報はRTSP(Real Time Streaming Protocol)を用いる。
[3.3.2 字幕関連]
多言語字幕は、Timed Text Markup Language(W3C(World Wide Web Consortium))に準拠する。なお、同期については別途アプリケーションレベルで実施する。また、各対応フォントはサーバから必要に応じてダウンロードする。例えば、HTTPのペイロードにフォントファイルを載せる。この場合、WebのDynamic Fonts、PFR(PortableFont Resource)を利用する。
フォントの容量は約5−35MB(メガバイト)程度が望ましい。
[3.4 モノメディアフォーマット]
放送通信連携サービスにおけるモノメディア符号化は下記に定義されたものを用いる。
[3.4.1 動画]
動画には、ARIB STD−B32 2.4版第1部3.1節で規定されるMPEG−2 Video方式および同3.2節で規定されるMPEG4−AVC方式が用いられ、同5.1節で規定されるテレビジョンサービスの符号化パラメータの制約条件が適用される。
[3.4.2 音声]
音声には、MPEG−2 Audioや、PCM(Pulse Code Modulation)(AIFF−C(Audio Interchange File Format Compression))を用いる。
MPEG−2 Audioの場合、ARIB STD−B32 2.4版第2部3.1節で規定されるMPEG−2 AAC方式が用いられ、同第5章で規定される符号化パラメータの制約条件が適用される。
PCMの場合、ARIB STD−B24 5.4版第一編第2部6.2節で規定される方式が用いられる。
付加音には、ARIB STD−B24 5.4版第一編第2部6.4節で規定される方式が用いられる。
[3.4.3 静止画]
JPEG(Joint Photographic Experts Group)の場合、ARIB STD−B24
5.4版第一編第2部5.2節で規定される符号化方式が用いられる。
PNG(Portable Network Graphics:ポータブル・ネットワーク・グラフィックス)の場合、ISO/IEC 15948:2003にて規定される方式が用いられる。これは、W3C Recommendation Portable Network Graphics (PNG) Specification (Second Edition)と同内容である
[3.4.4 文字]
文字符号化には、ARIB STD−B24 5.4版第一編第2部7.2節で規定される国際符号化文字集合が用いられる。
文字符号集合には、同7.2.1.1.3節で規定されるBMP(Basic Multilingual Plane)セットが用られ、表7−20が適用される。また、ISO/IEC10646:2003追補5および同追補6が適用される。
外字には、ARIB STD−B24 5.4版第一編第2部7.2.1.2節で規定される方式またはARIB STD−B23第一部5.2.1.2節で規定される方式などが適用される。
制御符号には、ARIB STD−B24 5.4版第一編第2部7.2.2.1節で規定されるC0制御符号のうち、APR(CR)、APD(LF)のみが用いられる。その他のC0制御符号およびC1制御符号は用いられない。
文字符号の変換は、ARIB STD−B24 5.4版第一編第2部付録規定Eに従う。
上記に規定する文字符号化方式以外の方式で情報が符号化されている場合、送出ないしは受信機内の適切なプロセスにおいて上記の文字符号化方式に変換し、処理を行う。すなわち、他の符号化方式による文字符号をアプリケーションからは直接扱わない。
[3.5 アプリケーションフォーマット]
受信機上で実行可能なアプリケーションの記述方法を示す。この記述方法により作成されたアプリケーションを実行するための実行環境と、セキュアマネージャとの結合については4章に示す。
[3.5.1 受信機で実行可能なアプリケーションフォーマット]
受信機で実行可能なアプリケーションの記述方式として、BML(ARIB STD−B24)、ARIB−J(ARIB STD−B23)、HTML5(W3C HTML5
Working draft − 2011/Jan/13)を規定する。
[3.5.2 BML]
受信機は、地上デジタル放送運用規定(ARIB TR−B14)またはBSデジタル放送運用規定(ARIB TR−B15)に準ずるBML文書を提示する機能を有する。
受信機は、地上デジタル放送またはBSデジタル放送で提供されるデータ放送サービスを既存の規格どおりに提示できなくてはならない。ただし、受信機は、放送でデータカルーセル方式によって配信されるBMLコンテンツの提示のみを必須とし、通信でHTTPプロトコルによって提供されるBMLコンテンツ(TR−B14 第三編第2部5.14節、TR−B15 第一部第三編8.14節)の提示は必須としない。
また、データ放送コンテンツ(BML)を起点として、以下に規定される通信アプリケーションの起動を行うための放送用拡張APIとして、browser.startHybridcastApp()、getAITInfo()を規定する。
表2は、browser.startHybridcastApp()の規定を示す。browser.startHybridcastApp()は、放送通信連携アプリケーションを起動するAPIである。
[表2]
Figure 0005986993
表3は、getAITInfo()の規定を示す。getAITInfo()は、受信中のサービスに含まれる最新のAIT情報を取得するAPIである。
[表3]
Figure 0005986993
[3.5.3 HTML5]
[3.5.3.1 記述方式]
受信機は、通信から提供されるプレゼンテーションエンジン型アプリケーションの記述方式としてHTML5をサポートする。JavaScript(登録商標)APIとして、下記のものをサポートする。なお、下記のAPIのうち、W3Cで検討が行われているものにはWorking Draft(WD)またはEditor’s Draft(ED)が含まれる。ただし、放送波で伝送されるデータカルーセルに関連するAPIは必須としない。
(1)System Information API(W3C Working Draft 02 Feb. 2010)(2)WebSocket API(W3C Editor’s Draft 28 Feb. 2011)(3)File API(W3C Working Draft 26 Oct. 2010)(4)Permission for File API, System Information API(Permissions for Device API Access, W3C Working Draft 05 Oct. 2010)(5)Device Description Repository Simple API(W3C Recommendation 05 Dec. 2008)(6)API for Media Resource 1.0(W3C Working Draft 08 June 2010)(7)Web Storage(W3C Working Draft 08 Feb. 2011)(8)Server-Sent Events(W3C Editor’s Draft 28 Feb. 2011)(9)Indexed Database API(W3C Working Draft 19 Aug. 2010)(10)SIアクセスAPI
(11)選局API
(12)印刷
(13)予約
[3.5.3.2 ブラウザ] 受信機のHTML5ブラウザは、JavaScript(登録商標)処理系、Web Workers(W3C Working Draft 08 Feb. 2011)、Widget Interface(W3C Working Draft 3 Feb. 2011)、HTML Canvas2D Context(W3C Editor’s Draft 28 Feb. 2011)の機能を実装する。Web Workersは、マルチタスクをサポートするため、Widget Interfaceは、独立アプリケーションをサポートするため、HTML Canvas 2D Contextは、2次元ベクトルグラフィックスをサポートするために必要である。
[3.5.4 ARIB−J]
受信機は、通信から提供されるアプリケーション実行エンジン型アプリケーションの記述方式としてARIB−Jをサポートする。また、複数ストリーム間の同期APIとしてDVB Bluebook A153(GEM Media Synchronization API)を用いる。
[3.6 受信機API]
以下に、HTML5およびARIB−Jで使用可能な受信機APIについて説明する。
[3.6.1 名前空間]
名前空間とは、サーバ上や受信機内に存在する、映像音声コンテンツ、アプリケーション、モノメディアファイルなど、放送通信連携システムで扱う様々なリソースの位置を特定するための文字列の記述規則である。3.5.2節以降で使用する各種リソースを参照するための名前空間の記法は分類毎に規定する。リソースには、インターネットサーバー上のリソース、アプリケーションキャッシュ上のリソース、放送のリソースがある。インターネットサーバー上のリソースには、VODコンテンツなどのストリームリソースや、アプリケーション、アプリケーションから参照されるその他のリソースなどのファイルリソースがある。放送のリソースには、放送中の番組、過去・未来の番組などのストリームリソースや、モジュール、イベントメッセージなどのカルーセルリソースがある。
[3.6.2 放送通信連携インタフェース]
放送通信連携インタフェースには、以下のインタフェースがある。
(1)getRunningApplications():実行中のアプリケーションの情報を取得する。getRunningApplicationsの戻り値は、apps[]と、アプリケーション毎のapplication_id及びrunning_levelとを含む。apps[]には、実行中アプリケーションのリストが設定される。application_idには、アプリケーションIDが設定され、アプリケーションが非公式の場合はnullである。running_levelには、実行レベル(認証結果および視聴者設定の状態)が設定される。
なお、セキュリティ上の観点から、他アプリケーションに関して取得できる情報は制限すべきである。
(2)queryApplicationInfo():指定したアプリケーションの情報を取得する。
(3)getProgramInfo():受信中の放送の情報を取得する。戻り値は、tuner_state、network_id、ts_id、orig_ts_id、service_id、event_id、content_idである。tuner_stateには、受信状態を表す値が設定される。
(4)getEPGInfo():受信中の放送のEIT(+SDT)中の各種情報を取得する。
(5)saveApplicationToCache():サーバ上のアプリケーションファイルをキャッシュに保存する。
(6)queryApplicationInCache():キャッシュ中のアプリケーションファイル(アプリケーションプログラム)を検索する。queryApplicationInCache()の引数は、application_id、getDSMCCModule()、addBroadcastSignalListener()、getListFromHybridcastMenu()である。application_idには、認証機関から発行されたアプリケーションIDが設定される。getDSMCCModule()は、放送波から指定のモジュールを取得する。addBroadcastSignalListener()は、SI、緊急情報、カルーセルおよびイベントメッセージの更新を監視するリスナを登録する。getListFromHybridcastMenu()は、トップメニューアプリケーションのリストを取得する。queryApplicationInCache()の戻り値は、user_apps[]、broadcaster_apps[]、vendor_apps[]である。
(7)addApplicationToHybridcastMenu():トップメニューにアプリケーションを追加する。
(8)getKeyFromBroadcast():放送から限定サーバーアクセスのための鍵情報を取得する。
(9)querySupportedFunction():アプリケーションブラウザの機能を問い合わせる。これは、機能/APIが利用可能かチェックすることを目的として使用される。
[3.6.3 BroadacastSignalListenerインタフェース]
BroadacastSignalListenerインタフェースは、放送から取得するSI、緊急情報、カルーセル、イベントメッセージを監視するためのリスナーインタフェースである。バウンドアプリケーション実行中に、紐付いている編成サービスが変更された場合にもこのインタフェースのイベントが発生する。
[3.6.4 LocalDatabaseインタフェース]
LocalDatabaseインタフェースは、視聴者情報を受信機内で保持・管理するためのインタフェースである。視聴者情報は、個人情報などサーバ側に出すべきでない情報であり、視聴者ID、受信機IDなど最低限の情報である。
[3.6.5 同期関連API]
SynchronizationManagerインタフェースとして、DVB Bluebook A153(GEM Stream Synchronization API)と同様のAPIを導入する。さらに、以下のインタフェースをAPIとして追加する。
(1)getCurrentSTC():現在のSTC(System Time Clock)値を取得する。なお、MPEG 2 Systems規格では、送信側のシステムクロック(STC)をMPEG2トランスポートストリーム中のPCR(Program Clock Reference)信号として多重し配信することで、受信機内部のシステムクロック(STC)が送信側のSTCと同期されるように規定している。
(2)getCurrentPositionInProgram():番組開始からの経過時間を取得する。
(3)delayStreamPresentation():提示中の放送ストリームの遅延提示を開始する。
(4)getCurrentDelay():提示中の放送ストリームの(本来の提示時刻からの)遅延時間量を取得する。
[3.6.6 SecurityExceptionインタフェース]
アプリケーションが、現在の実行レベルにおいて禁止されている関数呼び出しおよびプロパティ操作をした場合に発生する例外のインタフェースである。ecurityExceptionインタフェースは、上記各APIの呼び出し、あるいは、放送を参照するオブジェクト(HTML5なら<video>、ARIB−Jなら○○Controller)に対する各種操作によって発生する。
[3.7 受信機機能]
放送通信連携システムの受信機は、受信機機能として、アプリケーションローンチャーを備える。アプリケーションローンチャーは、受信機内に蓄積されたアプリケーションの起動、既知のリポジトリから独立アプリケーションの選択、AITによって起動指示が記述されたアプリケーションのうち、コントロールコードが「PRESENT」のアプリケーションの選択に用いる。
[4. セキュリティ]
[4.1 放送通信連携アプリケーションの管理]
放送事業者の要件を満たしつつ放送通信連携サービスを普及・活性化させるために、放送事業者およびその関係者だけではなく、幅広いサービス事業者や個人が参入できる枠組みが必要となる。本放送通信連携システムでは、セキュリティの観点からアプリケーションを「公式アプリケーション」と「非公式アプリケーション」に分類し、受信機において双方のアプリケーションを実行可能とする。
図12は、放送通信連携システムにおけるアプリケーション管理モデルを示す。「公式アプリケーション」は、登録管理者(第三者機関)への事前登録を行うことにより放送通信連携システムの仕様で期待する動作が保証される。「公式アプリケーション」は、登録時にIDと署名が付与され、受信機において2.2節で定義するセキュアマネージャーにより署名が検証され、すべてのAPIへのアクセスが可能となり、放送リソースを利用した番組連動サービスが行えるようになる。また、放送事業者から送出されるAITにより、放送事業者の要件に沿ったきめ細かい提示制御が可能となる。
一方、「非公式アプリケーション」は、事前の登録は不要であるが、放送通信連携システムの仕様で期待する動作は保証されず、アプリケーションから放送関連のAPIを扱うことはできない。「非公式アプリケーション」はIDと署名が付与されないため、個々のアプリケーションの指定は困難であるが、放送事業者の要件に基づいた提示制限を加えた上で実行させることは可能である。
[4.2 セキュアマネージャーの機能モデル]
図13は、セキュアマネージャーの機能モデルを示す。セキュアマネージャーは、受信機においてセキュリティを総合的に管理する機能である。
[4.2.1 アプリケーション監視・制御機能]
受信機において動作するアプリケーションは、アプリケーションファイルの配布の形態により、上述したように、「公式アプリケーション」と「非公式アプリケーション」の2種類に大別される。「公式アプリケーション」と「非公式アプリケーション」は、4.1節に示すようにIDと署名の有無によって区別され、受信機におけるAPIのアクセス範囲や放送事業者からの制御範囲が異なるなど、アプリケーション実行時の動作内容が異なる。アプリケーション監視・制御機能は、公式/非公式の種別の違いを識別し、確実にアプリケーション実行時の動作を制御することを目的とする。
(1)アプリケーション認証:受信機は、実行するすべてのアプリケーションについて、公式または非公式のいずれか、さらに公式であればIDを識別する。公式または非公式の区別は、アプリケーションファイル(アプリケーションプログラム)に付与された署名の有無を確認しこれを検証することによって行う。公式であれば、受信機はさらに、署名に記述されたアプリケーションIDを取得する。アプリケーションの識別は、アプリケーションの取得時、または、起動時に行う。
(2)画面提示制御:4.3節に後述する。
(3)リソースアクセス制御:受信機は、実行中のアプリケーションの放送リソース等のAPIへのアクセス制御を行う。アプリケーションがAPIにアクセスしようとする時に、当該アプリケーションが非公式のアプリケーションであれば、APIの種別によってアクセスを制限する。
また、アプリケーションがディスプレイへの画面表示APIにアクセスする際には、公式または非公式の種別と、選局中の放送事業者の提示ポリシーに基づき、画面提示制御を実行する。詳細は4.3節に後述する。
(4)リボケーション:アプリケーションのリボケーション機能を備える。
[4.2.2 受信機保護]
受信機は、視聴者情報保護およびウィルス対策等の保護機能を備える。
[4.3 アプリケーションの画面提示制御]
[4.3.1 画面提示制御の概要]
放送通信連携サービスでは、放送番組と同時に関連する通信アプリケーションを提示させることにより、放送サービスの利便性を拡張することができる。一方、通信サービスの利用により、受信機の画面上で放送番組と通信アプリケーションが混在して提示されることが想定される。提示方法によっては、放送番組に通信アプリケーションの画面が重なり、放送番組の一意性や作品性が損なわれるだけでなく、緊急地震速報などの緊急性の高い情報が正確に視聴者に伝えられなくなる恐れがある。画面提示制御により、放送通信連携サービスにおいて、放送事業者の意図に基づいたアプリケーションの提示制御を行う。
図14は、画面提示制御方式の概念を示す図である。画面提示制御方式は、個々の放送番組に対して通信アプリケーションをどのように画面上に提示させるかという放送事業者の提示ポリシーを受信機に反映させることを意図したもので、これをコンテンツの提示制御と呼ぶこととする。コンテンツの提示制御では、編成に応じた番組単位の提示制御、緊急地震速報などの番組中に発生するイベントに対する提示制御、アプリケーション単位の提示制御を実現する。
[4.3.2 画面提示制御の基本動作]
図15は、画面提示制御の基本動作モデルを示す図である。放送事業者の提示ポリシーを受信機に反映させるために、予め放送事業者が想定した、放送番組に対する通信コンテンツの提示方法を、提示ルールとして受信機で管理する。具体的には、通信コンテンツの提示方法として、重ね合わせの順序や並べ方の違いなどに応じてレベル分けを行い、提示レベル(ポリシーレベル)と提示方法のテーブルを提示ルールとして受信機内に保持する。放送事業者は指定する提示レベルを放送波に多重して伝送し、受信機はその提示レベルと提示ルールを照合し、提示方法を決定する。これにより、放送事業者の提示ポリシーに基づいた提示制御を実現することができる。
[4.3.3 制御情報の伝送・多重方式]
放送事業者の提示ポリシーを伝送する制御情報のフォーマットに関して、デジタル放送で使用されている番組配列情報を用いる方式として3つの具体例を挙げる。番組単位での画面提示制御として、既存のEIT(イベント情報テーブル:Event Information Table)を用いる方式と、EITを拡張して用いる方式(EIT+)がある。また、サービス(チャンネル)単位での画面提示制御として、放送信号のAITを拡張して用いる方式がある。さらに、番組中にリアルタイムに発生する事象単位での画面提示制御として、番組配列情報以外の放送局から送出される情報を用いる方式がある。以下に、4つの方式の詳細を記載する。
(1)EITの番組ジャンル(EIT):既存のEITのコンテント記述子に記述される番組ジャンルからポリシーレベルを判断する。受信機はそのために、番組ジャンルとポリシーレベルの対応表を管理する。ARIB規格との関連は、ARIB STD−B10
第2部 6.2.4、付録Hである。
表4は、番組ジャンルとポリシーレベルの関係の具体例を示す表である。番組ジャンル(program_genre)は、大分類を表す「content_nibble_level1」(0x0〜0xF)と、中分類を表す「content_nibble_level2」(0x0〜0xF)の2段階で構成される。受信機で管理するテーブルは中分類のジャンルまで対象とし、それぞれポリシーレベルの値を定義する。
[表4]
Figure 0005986993
(2)EITに新記述子追加(EIT+):EITのイベント情報セクションに新しい記述子を追加し、ポリシー情報を記述する。受信機は、この記述子を解釈し所望の処理を実行することで、番組単位でのポリシーレベルに応じた制御を実現する。ARIB規格との関連は、ARIB TR−B14(第二分冊) 第3部 31.3、ARIB STD−B10 第2編 5.2.7である。
表5は、イベントセキュリティ記述子の構造を示す表である。EIT+の場合、図15に示すイベントセキュリティ記述子を新規に定義し、EIT内の記述子領域にこのイベントセキュリティ記述子を格納して伝送する。イベントセキュリティ記述子には、ポリシーレベル(policy_level)、アプリケーションID(application_identifier)、制御コード(application_control_code)、優先度(application_priority)、プロトコル識別(protocol_id)、番組関連フラグ(associated_application_flag)を設定する。
[表5]
Figure 0005986993
policy_levelは、番組単位でのポリシーレベルを表す。ポリシーレベルは、1〜4の値とする。
application_identifier()は、アプリケーションを識別するための識別子である。表6は、application_identifier()の構造を示す。
[表6]
Figure 0005986993
organization_idは、アプリケーションを作成した組織を表し、0x00000063以降の値をとる。application_idは、アプリケーションを識別する番号を表す。application_idは、組織識別内で一意に付与される。
application_control_codeは、アプリケーション状態を制御する制御コードを規定する。表7は、制御コードの規定を示す。
[表7]
Figure 0005986993
application_priorityは、アプリケーション毎のポリシーレベルを示す。アプリケーション毎のポリシーレベルは、サービス内で告知されているアプリケーション間の相対的な優先度を示す。優先度は、1〜4の値とする。
protocol_idは、アプリケーションファイルを伝送するプロトコルを示す。表8は、protocol_idの規定を示す。
[表8]
Figure 0005986993
associated_application_flagは、番組に連動するアプリケーションであるか否かを示す。表9は、protocol_idの規定を示す。
[表9]
Figure 0005986993
(3)AITのテーブル定義および新記述子の追加(AIT+):AITを拡張してポリシー情報を伝送する。受信機は、このテーブルを解釈し所望の処理を実行することで、随時発生するイベントに対してポリシーレベルに応じた制御を実現する。ARIB規格との関連は、ARIB STD−B23 第2部 10.16である。
表10に、AITのデータ構造を示す。表10に示すAITは、ARIB STD−B23で規定されているAITのデータ構造を拡張したものである。AITには、ポリシーレベル、アプリケーションID、制御コードを記述する。なお、AITはセクション形式で送信され、イベント継続中は常時送信される。アプリケーションIDは、application_identifier()に記述し、制御コードはapplication_control_codeに記述する。
なお、これらの詳細は、(2)EITの拡張で記載したものと同様である。
さらに、ポリシーレベルを記述するために、新たにセキュリティポリシー記述子を定義し、AITの共通記述子ループに格納して伝送する。
[表10]
Figure 0005986993
表11は、新たに定義するセキュリティポリシー記述子の構造を示す。
[表11]
Figure 0005986993
(4)緊急警報放送および緊急地震速報(EWS/EEW):放送局から送出される緊急情報を用いてポリシーレベルを判断する。受信機においては予め緊急情報とポリシーレベルとの対応はなされているものとし、緊急警報放送であれば、TMCCの緊急警報放送用起動フラグを、緊急地震速報では文字スーパー管理パケットを監視することで、緊急情報の発生と終了が検知され、その際のポリシーレベルを判断することが可能になる。ARIB規格との関連は、ARIB STD−B31 3.15およびARIB STD−B24 第一編 第3部 第9章である。
なお、上記の(1)〜(4)のそれぞれの方式は並行して同時に送出することが可能である。したがって、どの方式で送られたものを優先させてポリシーレベルを決定するかを決めておく必要がある。優先順位は以下の通りである。
EWS/EEW> AIT+ > EIT+ > EIT
受信機はこの優先順位に基づき、ポリシーレベルを判断することで、放送事業者の意図に基づいた、緊急時の事象を優先させた画面提示制御が可能となる。
[4.3.4 画面提示制御の例]
図16は、ポリシーレベルに応じた画面提示制御の例を示す。
番組のポリシーレベルが「1」の場合、公式アプリケーションのアプリケーション画面のアプリケーション画面および非公式アプリケーションのアプリケーション画面の双方とも、放送画面上への重ね合わせが許可される。
番組のポリシーレベルが「2」の場合、公式アプリケーションのみが放送画面上への重ね合わせが許可され、非公式アプリケーションのアプリケーション画面については、放送画面上への重ね合わせは禁止され、放送画面の外側への表示のみが許可される。
番組のポリシーレベルが「3」の場合、公式アプリケーションのアプリケーション画面、及び、非公式アプリケーションのアプリケーション画面とも表示が許可されるが、全てのアプリケーション画面について、放送画面上への重ね合わせは禁止され、放送画面の外側への表示のみが許可される。
ポリシーレベルが「4」の場合、放送画面の全画面表示のみが許可される。
図17は、緊急地震速報受信時の提示制御の例を示す。番組Aの番組ポリシーレベルが「1」である場合、番組Aの放送時間帯においては、公式アプリケーションのアプリケーション画面、非公式アプリケーションのアプリケーション画面とも放送画面上に重ね合わせて表示される。しかし、受信機は、番組Aの放送時間帯の中でも緊急地震速報が発生している時間帯におけるポリシーレベルは、緊急地震速報のポリシーレベル「4」であると判断する。そのため、受信機は、番組Aの放送時間帯であっても、緊急地震速報が発生している時間帯では、公式アプリケーションのアプリケーション画面、及び、非公式アプリケーションのアプリケーション画面とも、放送画面上への重ね合わせを禁止する。
[上述した放送通信連携システムの一例を適用した本発明の実施形態の説明]
次に、図1に示す本発明の一実施形態を説明する。
図18は、本発明の一実施形態による放送通信連携システムの全体構成図である。図18に示すように、本実施形態の放送通信連携システムは、放送局が保有する放送事業者装置1、サービス事業者が保有するサービス事業者サーバ群2、システム管理者が保有するリポジトリサーバ3、及び、視聴者が保有する受信機4を備えて構成される。図18においては、受信機4を1台のみ示しているが、現実には複数台の受信機4が設けられる。
放送事業者装置1は、放送送出装置11及び放送局サーバ群12を備える。
放送送出装置11は、図3に示す放送局設備に相当し、番組編成設備、番組送出設備、送信設備等から構成されるデジタル放送用の放送設備である。
放送送出装置11は、放送関連データ管理部111、信号設定部112及び放送送出部113を備えて構成される。
放送関連データ管理部111は、各番組の番組セキュリティポリシーデータ、公式アプリケーションのアプリケーションセキュリティーポリシーデータ、その他のポリシーデータなどを管理する。
番組セキュリティポリシーデータは、番組のポリシーレベルを示すポリシーレベルデータ、番組にバウンドされたアプリケーションのアプリケーションID、番組にバウンドされたアプリケーションに対する制御コードなどを含む。
アプリケーションセキュリティポリシーデータは、アプリケーションがバウンドされている番組を特定する情報や、アプリケーションのプロトコル識別、ロケーション情報などを含む。ロケーション情報は、アプリケーションの格納位置(格納場所)を示し、例えば、アプリケーションをダウンロード可能な受信機アプリサーバ21やリポジトリサーバ3のURLである。プロトコル識別は、アプリケーションが放送により伝送されたか、通信により伝送されたかを示す。
なお、公式アプリケーションのみが番組にバウンドされる。
ポリシーデータは、提示ルールデータとポリシーレベルテーブルを含む。
提示ルールデータは、ポリシーレベル毎の提示方法を記述したデータである。提示方法は、画面表示方法と音声出力方法を含む。画面表示方法には、例えば、放送画面(番組の映像)のみ表示する、公式アプリケーション及び非公式アプリケーションともアプリケーション画面(アプリケーションの映像)を放送画面に重ねてあるいは放送画面の外に表示する、公式アプリケーションのアプリケーション画面のみ放送画面に重ねて表示し、非公式アプリケーションのアプリケーション画面は放送画面の外に表示する、などの方法がある。音声出力方法には、例えば、放送番組の音声のみを出力する、放送番組の音声と公式アプリケーションまたは非公式アプリケーションの音声を独立にあるいは混合して出力する、などの方法がある。
ポリシーレベルテーブルは、番組のジャンルに対応したポリシーレベルや、各イベントのポリシーレベルを記述したデータである。イベントとは、例えば、緊急警報信号や緊急地震速報など、番組とは必ずしも連動して発生しない放送の内容である。
信号設定部112は、放送送出部113が伝送する放送信号に各種データを設定する。
信号設定部112は、放送関連データ管理部111が管理している番組セキュリティポリシーデータやアプリケーションセキュリティーポリシーデータに基づいて、放送信号にAIT、番組のポリシーレベルデータを設定する。信号設定部112は、番組にバウンドされたアプリケーションのAITを独立したESとして放送信号(放送TS)に多重するか、データカルーセルに設定する。あるいは、信号設定部112は、番組にバウンドされたアプリケーションのAITと同等の情報をEITに設定する。また、信号設定部112は、番組のポリシーレベルデータをEIT(表5)、または、AIT(表11)に設定する。なお、番組のジャンルに対応するポリシーレベルを用いる場合には、ポリシーレベルデータを放送信号に設定しなくともよい。また、信号設定部112は、アプリケーションファイルをデータカルーセル等に設定する。また、信号設定部112は、放送関連データ管理部111が管理しているポリシーデータをセクション形式により放送信号に設定するか、エンジニアリングサービスあるいはデータカルーセルに設定する。
放送送出部113は、デジタル放送の放送信号を伝送する。放送信号は、信号設定部112により設定された情報を含む。
放送局サーバ群12は、図3に示す放送局サーバ群に相当し、コンテンツ管理サーバ13、コンテンツ配信サーバ16、放送局サービスサーバ17及び通知サーバ18を備えて構成される。
コンテンツ管理サーバ13は、番組管理サーバ14及びメタデータ管理サーバ15を備えて構成される。番組管理サーバ14は、すでに放送された番組や放送される番組を管理する。メタデータ管理サーバ15は、各番組に関するメタデータを管理する。メタデータは、例えば、番組タイトル、番組ID、番組概要、出演者、放送日時、台本、字幕、解説のデータを含む。
コンテンツ配信サーバ16は、インターネットなどの通信網9を介して受信機4と接続され、受信機4から要求されたコンテンツのコンテンツデータを配信する。
放送局サービスサーバ17は、サービス事業者サーバ群2に放送局のサービスのコンテンツデータを送信する。放送局のサービスには、例えば、ソーシャルネットサービス、ブログサービス等がある。
通知サーバ18は、通信網9を介して受信機4と接続され、放送送出装置11の放送関連データ管理部111から取得した番組セキュリティポリシーデータとアプリケーションセキュリティーポリシーデータとに基づいて、番組にバウンドされたアプリケーションのAIT(図6)及び番組のポリシーレベルデータを受信機4に配信する。また、通知サーバ18は、放送送出装置11の放送関連データ管理部111から取得したポリシーデータを受信機4に配信する。なお、これらの情報の全てまたは一部は、通知サーバ18からの配信を行なわず、放送送出装置11の放送送出部113が放送信号のみで伝送する場合もある。
サービス事業者サーバ群2は、図3に示すサービス事業者サーバ群に相当し、受信機アプリサーバ21、サービスサーバ22、コンテンツ配信サーバ23及び通知サーバ24を備えて構成される。受信機アプリサーバ21、サービスサーバ22、コンテンツ配信サーバ23及び通知サーバ24は、通信網9を介して受信機4と接続される。
受信機アプリサーバ21は、各アプリケーションを管理し、受信機4へアプリケーションファイルを配信する。
サービスサーバ22は、例えば、多言語字幕サーバ、話速変換音声サーバ、ソーシャルTVサーバ、レコメンドサーバ、ブックマークサーバなどであり、受信機4から要求されたサービスのコンテンツデータを配信する。
コンテンツ配信サーバ23は、例えば、VOD配信サーバ、字幕配信サーバ、マルチビュー配信サーバであり、受信機4から要求されたコンテンツのコンテンツデータを配信する。
通知サーバ24は、アプリケーションのAIT(図6)を受信機4に送信する。なお、公式アプリケーションの場合、通知サーバ24は、放送送出装置11の放送関連データ管理部111から取得した番組セキュリティポリシーデータやアプリケーションセキュリティーポリシーデータに基づいたAIT(図6)を送信してもよい。
リポジトリサーバ3は、図3に示すリポジトリに相当し、通信網9を介して受信機4と接続される。リポジトリサーバ3は、サービス事業者が生成したアプリケーションファイル(アプリケーションプログラム)に電子署名を行なうとともに、アプリケーションファイル(アプリケーションプログラム)の電子署名の認証に必要なデータを受信機4に送信する。また、リポジトリサーバ3は、公式アプリケーションの一覧を示すデータや、その公式アプリケーションのロケーション情報を受信機4に送信する。なお、リポジトリサーバ3が電子署名された公式アプリケーションのアプリケーションファイルを受信機4へ送信してもよく、受信機アプリサーバ21がリポジトリサーバ3から電子署名された公式アプリケーションのアプリケーションファイルを受信し、受信機4へ送信してもよい。また、リポジトリサーバ3は、公式アプリケーションのAITを受信機4に送信してもよい。
また、リポジトリサーバ3は、放送送出装置11の放送関連データ管理部111から受信した番組セキュリティポリシーデータやアプリケーションセキュリティーポリシーデータに基づいて、番組にバウンドされた公式アプリケーションのAIT(図6)を受信機4に送信してもよい。
受信機4は、図3に示す受信機に相当し、例えば、テレビ受像機、セットトップボックス、パーソナルコンピュータ、携帯端末等のデバイスである。
図19は、受信機4の内部構成を示す機能ブロック図である。図19に示すように、受信機4は、放送受信部401、分離部402、時計403、第1同期用バッファ404−1、第2同期用バッファ404−2、第1デコーダ405−1、第2デコーダ405−2、データ放送実行部406、映像制御部407、映像表示部408、音声制御部409、音声出力部410、通信入出力部411、アプリケーション実行制御部412、提示制御部413、操作入力部414、選局部415、ローカル情報記憶部416及び外部I/F部417を備えて構成される。
放送受信部401は、放送信号を受信するチューナである。放送信号は、無線放送信号及び有線放送信号またはいずれか一方である。無線放送信号は、放送局側の送信アンテナが送信した放送電波(地上波)や、衛星が中継する衛星波を、受信アンテナで受信することにより得られる信号である。有線放送信号は、光ケーブルや同軸ケーブル等を介して放送局側から伝送される信号である。放送受信部401は、放送信号を受信して復調し、放送ストリーム(TS)を出力する。
分離部402は、デマルチプレクサであり、放送受信部401から供給された放送ストリームを、PCR(Program Clock Reference)、映像データ、音声データ、字幕データ、データ放送、PSI(Program Specific Information)/SI(Service Information)、独立エレメンタリストリーム(ES)で送信されたAITなどの各種データに分離する。なお、AITはデータ放送に含まれる場合や、AITと同様の内容がSIを構成するEITに設定される場合もある。また、分離部402は、放送信号からアプリケーションファイルを分離して出力する場合もある。
通信入出力部411は、通信網9を介した通信によるデータの入出力を行う。通信入出力部411は、通信網9を経由して送信されたAITやアプリケーションファイルをアプリケーション実行制御部412に出力する。また、通信入出力部411は、通信網9を経由して送信された番組のポリシーレベルデータやポリシーデータを提示制御部413へ出力する。また、通信入出力部411は、アプリケーション実行制御部412により実行されるアプリケーションの指示に従って、コンテンツ配信サーバ16やコンテンツ配信サーバ23から配信されるコンテンツデータ、サービスサーバ22から配信されるコンテンツデータを通信網9を経由して受信し、第2同期用バッファ404−2に出力する。
操作入力部414は、視聴者による操作を受け付けるインタフェースであり、例えば、リモートコントローラ、携帯電話、タブレット端末等から視聴者が入力した情報を受信する受信装置や、キーボード、マウスなどである。操作入力部414は、視聴者が入力したメディア(地上/BS)やチャンネルの選択指示を選局部415に出力する。また、操作入力部414は、放送通信連携サービスの開始や終了の指示、アプリケーションに対する指示をアプリケーション実行制御部412に出力する。
選局部415は、操作入力部414に入力された操作に従って、放送受信部401において受信するメディアやチャンネルを制御する。
データ放送実行部406は、デジタル放送信号により送信されたデータ放送アプリケーションを実行し、データ放送の画像(グラフィック)データを映像制御部407へ出力する。データ放送実行部406は、放送通信連携サービスのアプリケーションを起動するためのAPIを備える。データ放送実行部406がデータ放送アプリケーションを実行して、放送通信連携サービスのアプリケーションを起動するAPIが呼び出された場合、データ放送実行部406は、アプリケーションの起動をアプリケーション実行制御部412に指示する。また、データ放送実行部406は、データカルーセルによって送信されたAITやアプリケーションファイルをデータ放送から取得してアプリケーション実行制御部412に出力する。また、データ放送実行部406は、データカルーセルによって送信されたポリシーデータをデータ放送から取得して提示制御部413に出力する。
アプリケーション実行制御部412は、放送通信連携サービスのアプリケーションを実行する。アプリケーション実行制御部412は、実行しているアプリケーションに従って、コンテンツ配信サーバ16、コンテンツ配信サーバ23、あるいは、サービスサーバ22から受信したコンテンツデータをデコードするように第2デコーダ405−2に指示する。コンテンツデータは、映像データ、音声データの一方または両方を含む。映像データは、例えば、動画、静止画、テキストデータなどである。また、アプリケーション実行制御部412は、実行しているアプリケーションに従って、映像制御部407にグラフィック(映像)データや映像制御指示を出力し、音声制御部409に音声データや音声制御指示を出力する。
時計403は、タイマーカウンタ値を出力する。時計403は、PCRが示すタイマーカウンタ値により発振器の周波数を調整し、放送送信側と時刻を同期させる。
第1同期用バッファ404−1は、分離部402から出力される映像データ、音声データ、字幕データを記憶する。映像データ、音声データ、字幕データのエレメンタリーストリーム(ES)から生成されたPES(Packetized Elementary Stream)は、放送ストリーム(TS)を構成するトランスポートパケット(Transport Packet)に分割されて設定される。PESのヘッダには、PTS(提示時刻情報:Presentation Time Stamp)が含まれる。第1同期用バッファ404−1は、分離部402から出力された映像データ、音声データ、字幕データを、第1デコーダ405−1の指示によりPESパケット単位で出力する。
第2同期用バッファ404−2は、通信入出力部411が受信したコンテンツやサービスのコンテンツデータを記憶する。あるいは、第2同期用バッファ404−2は、操作入力部414により入力された視聴者の指示に従って、分離部402から出力される映像データ、音声データ、字幕データを記憶する。第2同期用バッファ404−2は、記憶しているコンテンツデータあるいは番組の映像データ、音声データ、字幕データを第2デコーダ405−2の指示によりPESパケット単位で出力する。
第1デコーダ405−1は、時計403から出力された時刻に対応したPTSが設定されている第1同期用バッファ404−1内のPESパケットを特定し、特定したPESパケットからエンコードされた映像データ、音声データ、字幕データを読み出し、読み出したデータをデコードして出力する。
第2デコーダ405−2は、時計403から出力された時刻に対応するPTSが設定されている第2同期用バッファ404−2内のコンテンツデータあるいは番組のPESパケットを特定し、特定したPESパケットからエンコードされた映像データ、音声データ、字幕データを読み出し、読み出したデータをデコードして出力する。
提示制御部413は、選局されている番組のポリシーレベルあるいは発生中のイベントのポリシーレベルと、提示ルールデータとに従って提示方法(画面表示方法及び音声出力方法)を決定する。提示制御部413は、決定した画面表示方法により、放送画面、公式アプリケーションのアプリケーション画面、及び、非公式アプリケーションのアプリケーション画面を表示するよう映像制御部407に指示する。さらに、提示制御部413は、決定した音声出力方法により、放送の音声データによる音声、公式アプリケーションの音声データによる音声、及び、非公式アプリケーションの音声データによる音声を出力するよう音声制御部409に指示する。
映像制御部407は、第1デコーダ405−1から出力された番組の映像データ及び字幕データに基づく放送画面と、第2デコーダ405−2から出力されたコンテンツデータの映像データに基づく公式アプリケーション、非公式アプリケーションのアプリケーション画面とを、提示制御部413またはアプリケーション実行制御部412から指示された画面表示方法に従って映像表示部408に表示させる。また、アプリケーション実行制御部412からアプリケーションの実行によりグラフィック(映像)データが出力される場合、映像制御部407は、提示制御部413またはアプリケーション実行制御部412から指示された画面表示方法に従って、その映像データに基づく表示画面を併せて映像表示部408に表示させる。なお、第2デコーダ405−2からは、他の番組の映像データ及び字幕データが出力される場合もある。
映像表示部408は、一般的なディスプレイであり、放送およびアプリケーションの画面を表示する。例えば、映像表示部408は、番組の放送画面に、通信網9から受信したコンテンツデータの動画、静止画、テキストや、アプリケーションの実行によってアプリケーション実行制御部412から出力されたグラフィックなどのアプリケーション画面、または、他の番組の放送画面を合成した映像を表示する。
音声制御部409は、第1デコーダ405−1から出力された番組の音声データに基づく音声と、第2デコーダ405−2から出力されたコンテンツデータの音声データに基づく公式アプリケーションや非公式アプリケーションの音声と、アプリケーションの実行によってアプリケーション実行制御部412から出力された音声データに基づく音声とを、提示制御部413またはアプリケーション実行制御部412より指示された音声出力方法に従って音声出力部410から出力させる。なお、第2デコーダ405−2からは、他の番組の音声データが出力される場合もある。音声出力部410は、一般的なスピーカーあり、放送およびアプリケーションの音声を出力する。
ローカル情報記憶部416は、ユーザ情報などの各種データを記憶する。
外部インタフェース部(以下、「外部I/F部」と記載する。)417は、LAN(Local Area Network)などのホームネットワークなどに接続される機器8との間でデータを送受信する。機器8は、受信機4と連携動作する端末であり、例えば、パーソナルコンピュータ、携帯電話、タブレット、スマートフォン、PDAである。
なお、受信機4がセットトップボックスなどの場合、映像表示部408及び音声出力部410は、受信機4と接続される外部装置とする。
図20は、アプリケーション実行制御部412の詳細な構成を示すブロック図である。
図20に示すように、アプリケーション実行制御部412は、アプリケーション記憶部431、アプリケーション認証部432、アプリケーション管理部433、アプリケーション制御部434、アプリケーション実行部435、リソースアクセス制御部438及びリソース制御部439を備える。
アプリケーション記憶部431は、通信入出力部411が通信網9を介して受信したアプリケーションファイル、あるいは、データ放送実行部406がデータ放送から取得したアプリケーションファイル、または、分離部402が放送信号から分離したアプリケーションファイルを記憶する。アプリケーションファイルは出荷時などに予めアプリケーション記憶部431に記憶されていてもよい。アプリケーション記憶部431は、主記憶装置及びディスク等の補助記憶装置からなり、例えば、アプリケーションファイルはディスクに記憶され、実行時に主記憶装置に読み出される。この場合、オンザフライで実行されるアプリケーションのアプリケーションファイルは、ディスクには記憶されずに主記憶装置のみに記憶され、実行が終了した場合は主記憶装置から削除される。
アプリケーション認証部432は、リポジトリサーバ3から電子署名の認証に必要なデータを受信し、受信したデータを用いてアプリケーションファイル(アプリケーションプログラム)に付加された電子署名の検証を行う。例えば、アプリケーション認証部432は、リポジトリサーバ3から受信した公開鍵を用いて、電子署名されたアプリケーションファイルを復号する。その結果、所定のデータ列が得られた場合、アプリケーション認証部432は、電子署名の検証が成功したと判断する。アプリケーション認証部432は、電子署名の検証が成功した場合、公式アプリケーションであると判断し、電子署名の検証が不成功である場合、あるいは、電子署名が付加されていない場合、非公式アプリケーションであると判断する。
アプリケーション管理部433は、アプリケーション実行部435によるアプリケーションの起動または停止の状態、起動しているアプリケーションの出力状況を管理する。出力状況とは、動作中のアプリケーションから画像や音声が出力されているか否かの情報である。アプリケーション管理部433は、提示制御部413からの問い合わせを受け、起動されているアプリケーションの出力状況や、起動されているアプリケーションが公式アプリケーションであるか非公式アプリケーションであるかの応答を返送する。
アプリケーション制御部434は、番組にバウンドされているアプリケーションに対する制御コードや、操作入力部414により入力されたアプリケーションに対する指示に従って、アプリケーション実行部435におけるアプリケーションの起動や停止などを制御する。また、アプリケーション制御部434は、データ放送実行部406から起動が指示されたアプリケーションの起動をアプリケーション実行部435に指示する。アプリケーション制御部434は、操作入力部414からの入力に従ってチャンネルが変更される場合、変更前のチャンネルの番組にバウンドされているアプリケーションの終了と、変更後のチャンネルの番組にバウンドされているアプリケーションの起動をアプリケーション実行部435に指示する。なお、アプリケーション制御部434は、番組にバウンドされているアプリケーションや、バウンドされているアプリケーションに対する制御コードを、放送信号の独立ESもしくはデータ放送に含まれるAIT、放送信号のEITから得られるAITと同等の情報、または、通信入出力部411を介して通知サーバ18もしくは通知サーバ24から受信したAITから取得する。また、アプリケーション制御部434は、AITに設定されているロケーション情報を宛先としてアプリケーションファイルのダウンロード要求を送信する。受信機4からダウンロード要求を受信したリポジトリサーバ3、または、受信機アプリサーバ21は、アプリケーションファイルを受信機4に配信する。
アプリケーション実行部435は、受信機API部436及び端末連携API部437を備える。アプリケーション実行部435は、アプリケーション制御部434からの指示に従って、起動が指示されたアプリケーションのアプリケーションプログラムをアプリケーション記憶部431から読み出して実行する。アプリケーション実行部435がアプリケーションプログラムを実行することにより、受信機4上でアプリケーションが動作し、アプリケーション実行部435は通信網9を経由してコンテンツをコンテンツ配信サーバ16やコンテンツ配信サーバ23に要求したり、サービスをサービスサーバ22に要求したりする。また、アプリケーションプログラムを実行することにより、アプリケーション実行部435は、映像制御部407へグラフィックデータや映像制御指示を出力したり、音声制御部409に音声データや音声制御指示を出力したりする。
受信機API部436は、アプリケーション実行部435がアプリケーションを実行するにあたって受信機4内の各リソースを利用するためのAPIである受信機APIを実行する。受信機API部436が受信機APIを実行することにより、アプリケーション実行部435が実行しているアプリケーションプログラムから受信機4内のリソースが利用可能となる。
端末連携API部437は、外部I/F部417により通信可能なホームネットワーク上の機器8や、通信網9を介して接続される機器が受信機4の機能を利用するためのAPIである端末連携APIを実行する。端末連携API部437が端末連携APIを実行することにより、ホームネットワークを介して接続される機器8や通信網9を介して接続される機器から受信機4内のリソースが利用可能となる。
リソース制御部439は、受信機API部436や端末連携API部437から受信機4内のリソースである各機能部へのアクセスを制御する。
リソースアクセス制御部438は、受信機API部436や端末連携API部437から受信機4内の各機能部へのアクセスを許可するか否かを制御する。リソースアクセス制御部438は、この制御を、受信機API部436や端末連携API部437が実行する各APIの呼び出し元であるアプリケーションが公式アプリケーションであるか非公式アプリケーションであるかに従って行なう。
図21は、提示制御部413の詳細な構成を示すブロック図である。図21に示すように、提示制御部413は、ポリシーデータ管理部451、ポリシーデータ記憶部452、イベント解釈部453、ポリシーレベル照合部454、イベント制御部455、番組ポリシー記憶部456、ポリシー調停部457及びポリシーレベル記憶部458を備える。
ポリシーデータ記憶部452は、提示ルールデータ及びポリシーレベルテーブルを含むポリシーデータを記憶する。ポリシーデータ管理部451は、ポリシーデータ記憶部452に記憶されるポリシーデータを管理する。ポリシーデータ管理部451は、ポリシーデータ記憶部452から読み出したポリシーレベルテーブルをポリシーレベル照合部454に出力し、ポリシーデータ記憶部452から読み出した提示ルールデータをポリシー調停部457に出力する。また、ポリシーデータ管理部451は、放送により送信されたポリシーデータを分離部402あるいはデータ放送実行部406から受信し、通信により送信されたポリシーデータを通信入出力部411から受信する。ポリシーデータ管理部451は、ポリシーデータ記憶部452に記憶されているポリシーデータを、放送または通信により送信されたポリシーデータにより更新する。
イベント解釈部453は、放送受信部401が受信した放送信号や、分離部402が分離したデータ放送や字幕データを解析し、イベントの発生または終了を検出する。イベント解釈部453は、イベントの発生または終了を検出(解釈)すると、その検出したイベントのイベント番号と、発生または終了を示すステータスデータとをポリシーレベル照合部454に出力する。
ポリシーレベル照合部454は、ポリシーレベルテーブルを参照して、EITにより示される各番組のジャンルに対応したポリシーレベルと、イベント番号により特定されるイベントに対応したポリシーレベルを決定(照合)する。ポリシーレベル照合部454は、分離部402から入力されたSIより取得した番組の放送開始時刻及び放送終了時刻のデータと、当該番組のポリシーレベル(以下、「番組ポリシーレベル」と記載する。)をイベント制御部455に出力する。なお、番組ポリシーレベルがEITに設定されている場合、ポリシーレベル照合部454は、番組の放送開始時刻及び放送終了時刻のデータと、EITから取得した当該番組の番組ポリシーレベルをイベント制御部455に出力する。
また、ポリシーレベル照合部454は、AITから番組ポリシーレベルを取得した場合、取得した番組ポリシーレベルをポリシー調停部457に出力する。また、ポリシーレベル照合部454は、イベント番号に対応して決定したポリシーレベル(以下、「トリガーポリシーレベル」と記載する。)をポリシー調停部457に出力する。
番組ポリシー記憶部456は、番組開始時刻及び番組終了時刻と、番組ポリシーレベルを対応付けて記憶する。イベント制御部455は、ポリシーレベル照合部454から入力された番組開始時刻及び番組終了時刻のデータと、番組ポリシーレベルとを対応付けて番組ポリシー記憶部456に書き込み、番組ポリシー記憶部456に記憶されているこれらの情報を基に、表示制御を実行する時刻を管理する。イベント制御部455は、番組ポリシー記憶部456に記憶されている番組開始時刻のデータを参照し、実行時刻を通知すべき時刻となったことを検出した場合、実行時刻と、その実行時刻に対応した番組ポリシーレベルをポリシー調停部457に出力する。
ポリシーレベル記憶部458は、ポリシー調停部457に入力された実行時刻及び番組ポリシーレベルと、トリガーポリシーレベル及びステータスデータを記憶する。ポリシー調停部457は、イベント制御部455から入力された実行時刻及び番組ポリシーレベルと、ポリシーレベル照合部454から入力されたトリガーポリシーレベルとからポリシーレベルを決定する。例えば、トリガーポリシーレベルをポリシーレベルとして決定してもよく、番組ポリシーレベルとトリガーポリシーレベルのうちより高いほうをポリシーレベルとして決定してもよい。
なお、ポリシーレベル照合部454からAITにより取得した番組ポリシーレベルが入力された場合、ポリシー調停部457は、イベント制御部455から入力された番組ポリシーレベルよりも、ポリシーレベル照合部454から入力された番組ポリシーレベルを優先する。つまり、ポリシー調停部457は、AITより得られた番組ポリシーレベルと、トリガーポリシーレベルとからポリシーレベルを決定する。ポリシー調停部457は、提示ルールデータを参照し、決定したポリシーレベルと、アプリケーション管理部433から取得した動作中のアプリケーションが公式であるか否かの情報や出力状況から、画面表示方法及び音声出力方法(提示方法)を決定する。ポリシー調停部457は、決定した画面表示方法を映像制御部407に出力し、決定した音声出力方法を音声制御部409に出力する。
以下、図1についてさらに説明する。
図1において、放送受信部401は、放送信号を受信する。ここで、放送受信部401が受信する放送信号は、AITまたは拡張されたEITなどの各種データを含む。上述したように、AITは、受信機4が実行するアプリケーションの起動を指示する情報として用いられる。また、放送受信部401が受信する放送信号は、所定のパケットにポリシーを含む。
ここでいう、「ポリシー」は、図24および図25A〜図25Dを用いて後述するように、目的データへのアクセス可否の判定基準を示すデータである。このポリシーは、アクセス可否の判定基準を含み、当該判定基準と外部から入力されるデータとを比較し、比較結果に応じてデータへのアクセス可否を判定することを表すデータである。
ポリシーを含めて送信する所定のパケットとしては、様々なものを用いることができる。例えば、AITおよびEITと異なるパケットにポリシーが含まれるようにしてもよいし、あるいは、AITまたはEITが拡張され、当該拡張されたAITまたは拡張されたEITにポリシーが含まれるようにしてもよい。ポリシーの送信方法については、例えば、DMSS−CCデータカルーセルが用いられる。
分離部402は、放送受信部401が受信した放送信号から各種データを分離する。特に、分離部402は、放送信号からAITと拡張されたEITとを分離する。さらに、AITおよびEITと異なるパケットにポリシーが含まれる場合、分離部402は、当該ポリシーが含まれるパケットを放送信号から分離する。
アプリケーション制御部434は、分離部402が分離するAIT、または、通信入出力部からの起動指示に基づいて、アプリケーション実行部435を制御する。特に、アプリケーション制御部434は、AITに基づいて、アプリケーション実行指令をアプリケーション実行部435に出力する。
外部I/F部417は、端末装置と通信を行って、当該端末装置が受け付ける、ユーザの操作入力を取得する。特に、外部I/F部417は、ユーザ入力データを、端末装置から取得してアプリケーション実行装置435に出力する。また、外部I/F部417は、端末装置と通信を行ってユーザの識別情報を取得する。
ここでいう「ユーザ入力データ」は、ユーザが端末装置を用いて入力するデータである。ユーザ入力データとしては、例えば、ユーザ名、性別、年齢などがある。例えば、端末装置は、アプリケーション実行装置435が実行するアプリケーションからの要求に応じて、ユーザによって入力されたこれらのデータを外部I/F部417に送信する。
また、外部I/F部417が取得するユーザの識別情報は、端末装置を用いて受信機4にログインするユーザを識別する情報である。このユーザの識別情報は、ユーザによって端末装置に入力される。あるいは、端末装置の識別情報と、このユーザの識別情報とが対応付けられてローカル情報記憶部412が予め記憶しておいてもよい。
アプリケーション記憶部431は、各種アプリケーションプログラムを記憶する。このアプリケーションプログラムは、例えば、放送信号のAITに記述された情報を基にして取得され、アプリケーション記憶部431に予め記憶されている。
アプリケーション実行部435は、アプリケーション制御部434から出力されるアプリケーション起動指令に従って、アプリケーション記憶部431からアプリケーションプログラムを読み出して実行することで、アプリケーションを起動して実行する。
そして、アプリケーション実行部435は、実行するアプリケーションの処理に応じて、ユーザに関連するデータの保存要求を、リソース制御部439に出力する。
ここでいう「ユーザに関連するデータ」とは、受信機4のユーザの各々に関連する情報である。このユーザに関連するデータには、上述したユーザ入力データと、アプリケーションがユーザに対応付けて生成するデータとがある。アプリケーションがユーザに対応付けて生成するデータとしては、例えば、クイズ番組と同期して実行されるアプリケーションがユーザに対応付けて生成する、正解率情報や、クイズに正解して得られるポイントの情報などがある。
アプリケーション実行部435は、端末に関連する情報を書き込む要求をした要求元を表す要求元情報と、ポリシーと、キー情報とを対応付けて、ユーザに関連するデータの保存要求に含めて、リソース制御部439に出力する。
ここでいう「キー情報」とは、ユーザに関連するデータを読み出す際に検索キーとなる情報である。キー情報としては、例えば、ユーザの属性の項目を示す情報が用いられる。
ユーザの属性の項目を示す情報は、例えば、「氏名」、「性別」、「年齢」等の項目名である。また、例えば、ユーザに関連するデータが、アプリケーションがユーザに対応付けて生成するデータである場合、独自の項目名が用いられてもよい。
また、要求元情報は、アプリケーションが保存要求をした場合には、当該アプリケーションの提供元の識別情報であり、一方、ユーザ入力を受けた端末装置が保存要求をした場合には、ユーザが要求元であることを示す値「own」である。
また、アプリケーション実行部435は、放送信号に含まれるアプリケーション起動指令に従ってアプリケーションを起動し、リソース制御部439が読み出したデータを用いてアプリケーションを実行する。
アプリケーション実行部435が実行するアプリケーションは、例えば、放送受信部401の受信する放送信号に関連して、放送信号から得られるデータに対する処理、あるいは、放送番組の内容に関連する処理を行う。この、放送信号に関連した処理には、放送番組の視聴に関連してアプリケーションが実行するサービスや、放送信号に含まれるメタデータに関連してアプリケーションが実行するサービスや、放送番組の内容に関連してアプリケーションが実行するサービスがある。
放送番組の視聴に関連してアプリケーションが実行するサービスとして、例えば、番組の視聴に対する年齢制限がある。年齢制限のある番組の視聴に際して、アプリケーション実行部435の実行するアプリケーションは、目的データのうち、ユーザの年齢データに基づいて、ユーザが当該番組を視聴可能か否かを判定する。
また、メタデータに関連してアプリケーションが実行するサービスとしては、例えば、データ放送で送信される情報のフィルタリングがある。受信機4がデータ放送を受信して各種情報を表示する際、アプリケーション実行部435が実行するアプリケーションは、目的データのうち、例えばユーザの住所情報に基づいて、その地域に関連した情報を選択し、映像表示部408(図19)に表示させる。
また、放送番組の内容に関連してアプリケーションが実行するサービスとしては、例えば、テレビショッピングにおけるクレジットカード決済がある。テレビショッピングを視聴中のユーザが、受信機4を用いてオンラインでクレジットカード決済を行う際、アプリケーション実行部435が実行するアプリケーションは、目的データのうち、クレジットカード番号を読み出し、読み出したクレジットカード番号を含むクレジットカード決済要求情報を生成し、通信入出力部411を介して、ネットワーク上のクレジットカード決済サーバ装置に送信する。
ログイン処理部461は、ユーザの操作に従って、当該ユーザのログインおよびログアウトを行う。
ここでいう「ログイン」は、ローカル情報記憶部416の記憶するログインユーザ情報に、ユーザの識別情報を書き込む処理である。一方、「ログアウト」は、ローカル情報記憶部416の記憶するログインユーザ情報から、ユーザの識別情報を削除する処理である。また、ここでいう「ユーザの識別情報」は、ユーザを一意に識別する情報である。また、ここでいう「ログインユーザ情報」は、ログイン状態であることを示す情報と、ユーザの識別情報とが対応付けられた情報である。
例えば、ローカル情報記憶部416が、ユーザによって入力された、ユーザの識別情報とパスワードとを対応付けて予め記憶しておく。そして、ログイン処理部461は、ログイン要求を示す操作入力を、ユーザの識別情報およびパスワードと共に端末装置から取得すると、ローカル情報記憶部416を参照してユーザ認証を行う。そして、ログイン処理部461は、端末装置から取得したユーザの識別情報およびパスワードと、ローカル情報記憶部416に記憶されたユーザの識別情報およびパスワードとが一致する場合に、認証が成立すると判定し、一致しない場合には、認証が成立しないと判定する。そして、認証が成立すると判定すると、ログイン処理部461は、端末装置から取得したユーザの識別情報を含むログインユーザ情報をローカル情報記憶部416に書き込む。また、ログイン処理部461は、ログアウト要求を示す操作入力を、ユーザの識別情報と共に端末装置から取得すると、端末装置から取得したユーザの識別情報を含むログインユーザ情報をローカル情報記憶部416から削除する。
あるいは、各ユーザが端末装置を所持し、端末装置毎に当該端末装置を識別する端末装置識別情報が割り当てられている場合、ログイン処理部461が、パスワードではなく、この端末装置識別情報を用いてログインの認証を行うようにしてもよい。例えば、各ユーザが携帯電話機を所持し、この携帯電話機を端末装置として用いる場合、ローカル情報記憶部416は、ユーザの識別情報と、当該ユーザがログインに用いる携帯電話機のIMSI(International Mobile Subscriber Identity)とを対応付けて予め記憶しておく。このユーザの識別情報とIMSIとは、ユーザが、当該携帯電話機を用いてユーザの識別情報を登録することによって、対応付けられてローカル情報記憶部416に記憶される。
そして、ログイン処理部461は、携帯電話機から、ログイン要求を示す操作入力を当該携帯電話機のIMSIと共に取得すると、ローカル情報記憶部416を参照してユーザ認証を行う。そして、ログイン処理部461は、携帯電話機から取得したIMSIと、ローカル情報記憶部416に記憶されたIMSIとが一致する場合に、認証が成立すると判定し、一致しない場合には、認証が成立しないと判定する。そして、認証が成立すると判定すると、ログイン処理部461は、携帯電話機から取得したIMSIに対応付けられたユーザの識別情報をローカル情報記憶部416から読み出し、当該ユーザの識別情報を含むログインユーザ情報をローカル情報記憶部に書き込む。また、ログイン処理部461は、携帯電話機から、ログアウト要求を示す操作入力を当該携帯電話機のIMSIと共に取得すると、携帯電話機から取得したIMSIに対応付けられたユーザの識別情報をローカル情報記憶部416から読み出して、当該ユーザの識別情報を含むログインユーザ情報をローカル情報記憶部416から削除する。
なお、上述したIMSIに代えて、携帯電話機が有する通信インタフェースの物理アドレスを用いるようにしてもよい。
上述したログインユーザ情報を参照することにより、受信機4は、ログイン状態にあるユーザを示すユーザの識別情報を特定可能となる。これによって、後述するように、アプリケーション実行部435が実行するアプリケーションは、ローカル情報記憶部416が記憶する、ユーザに関連するデータのうち、ログイン状態にあるユーザに対応付けられたものを取得しうる。そして、アプリケーション実行部435が実行するアプリケーションは、取得したユーザに関連するデータを用いて、ユーザ毎に個別のサービスを提供することができる。
また、ローカル情報記憶部416は、端末装置を用いて受信機4にログインしている状態にあるユーザを示すユーザの識別情報を、上述したログインユーザ情報として記憶する。なお、この端末装置は、ユーザのログイン操作を受け付けて受信機4に出力する装置であればよく、受信機4と端末装置とが一体になっていてもよい。
利用状態判定部464は、ログインユーザ情報に基づいて、利用状態情報を生成し、アクセス制御部462に出力する。ここでいう「利用状態情報」とは、ログイン状態にあるユーザに応じたユーザの識別情報を示す情報であり、ログインユーザ情報を参照して、ログイン状態にあるユーザが1人の場合(ログインユーザ情報から得られるユーザの識別情報が1つである場合)には、そのユーザの識別情報、または、ログイン状態にあるユーザが1人以外(0人または複数)である場合(ログインユーザ情報から得られるユーザの識別情報がない、あるいは複数である場合)には、ログイン状態にあるユーザが1人以外であることを示す情報(例えば、値「family」)である。
リソース制御部439は、ログイン状態にあるユーザを示すユーザの識別情報と、ユーザに関連するデータと、キー情報と、要求元情報と、ポリシーとが対応付けられた、ユーザに関連するデータの保存要求を受けると、ユーザの識別情報と、ユーザに関連するデータと、キー情報と、要求元情報と、ポリシーとを対応付けて、ローカル情報記憶部416に書き込む。
その際、リソース制御部439は、利用状態判定部464から、利用状態情報を取得し、この利用状態情報に応じて書き込む。例えば、リソース制御部439は、利用状態情報が1人のユーザの識別情報を示す場合、当該ユーザの識別情報と、ユーザに関連するデータと、キー情報と、要求元情報と、ポリシーとを対応付けて書き込む。一方、リソース制御部439は、利用状態情報が値「family」を示す場合、この値「family」と、ユーザに関連するデータと、キー情報と、要求元情報と、ポリシーとを対応付けて書き込む。
また、リソース制御部439は、後述するポリシー判定部463がアクセスを許可した場合に、利用状態判定部464から出力される利用者状態情報に対応するデータをローカル情報記憶部416から読み出す。すなわち、利用者状態情報が1つのユーザの識別情報を示す場合は、当該ユーザの識別情報に対応付けられたデータをローカル情報記憶部416から読み出す。また、利用者状態情報が値「family」示す場合は、「family」に対応付けられた、ユーザに関連するデータをローカル情報記憶部416から読み出す。
また、リソース制御部439は、アプリケーション実行部435から指定されるキー情報に基づいて、利用状態判定部464から出力される利用者状態情報と当該キー情報との両方に対応する、ユーザに関連するデータを、ローカル情報記憶部416から読み出す。
ローカル情報記憶部416は、ユーザの識別情報と、当該ユーザに関連するデータと、データへのアクセス可否の判定基準を示すポリシーとを対応付けて記憶する(後述する)。
また、ローカル情報記憶部416は、ユーザに関連するデータと、ユーザに関連するデータへのアクセス可否の判定基準を示すポリシーとに対して、さらに要求元情報を対応付けて記憶する。
また、ローカル情報記憶部416は、1つのユーザの識別情報に対して、当該ユーザに関連するデータが複数対応付けられる場合には、ユーザに関連するデータと、当該ユーザに関連するデータへのアクセス可否の判定基準を示すポリシーと、要求元情報と、キー情報とを対応付けて記憶する。特に、ローカル情報記憶部416は、キー情報毎に対応して、ユーザに関連するデータを記憶する。
アクセス制御部462は、リソース制御部439が行うデータアクセスを制御する。特に、アクセス制御部462は、ユーザに関連するデータの保存要求を受けると、利用状態判定部464から利用状態情報を取得してリソース制御部439に出力する。また、アクセス制御部462は、ユーザに関連するデータの取得要求受けると、利用状態判定部464から利用状態情報を取得してポリシー判定部463に出力する。
ポリシー判定部463は、利用状態判定部464が生成する利用状態情報が示すユーザの識別情報に対応付けられたポリシーを、ローカル情報記憶部416から読み出し、読み出されたポリシーに基づいて、ユーザの識別情報に対応するデータへのアクセスを許可するか否かを判定する。
より具体的には、ポリシー判定部463は、読み出したポリシーに基づき、読み出し要求に含まれる識別情報が示すユーザに関連するデータに対応付けられたデータ書込要求元情報と、読出要求を出力したアプリケーションの識別情報とを比較して、一致する場合にアクセスを許可すると判定する。
また、ポリシー判定部は463、読み出したポリシーに基づき、読み出し要求に含まれる識別情報が示すユーザに関連するデータへのアクセスを許可するか否かを示す操作入力に従って、アクセスを許可するか否かを判定する。
通信入出力部411は、アプリケーションの起動指示をアプリケーション制御部434に出力する。例えば、通信入出力部411は、通信網9を介してサーバ装置から送信されるアプリケーションの起動指示を受信して、アプリケーション制御部434に出力する。
次に、本発明の一例においてローカル情報記憶部416の記憶するデータの構造、および、当該データにアクセスする際の受信機4の動作について説明する。
図22は、ローカル情報記憶部416の記憶するユーザ関連情報のデータ構造を示すデータ構造図である。図22において、項目<usr>の値は、ユーザの識別情報を示す。ローカル情報記憶部416は、ユーザに関連する情報をユーザの識別情報と対応付けて記憶することで、ユーザ毎に、各ユーザに関連する情報を記憶する。
ログイン状態にあるユーザの識別情報を示す。なお、項目<usr>の値「famly」は、ログイン状態にあるユーザを特定できない状態を示す。上述したように、ログイン状態にあるユーザを特定できない状態とは、例えば、ログイン状態にあるユーザがいない状態、および、ログイン状態にあるユーザが2人以上存在する場合である。
また、項目<value>には、ユーザ名、性別、年齢など、項目<usr>の値によって識別されるユーザに関連するデータが格納される。以下、項目<value>に格納されているデータを「目的データ」と称する。アプリケーション実行部435は、この目的データを用いてサービスを提供する。
また、項目<key>には、目的データを特定するためのキー情報が格納される。
図22に示すように、ローカル情報記憶部416は、目的データを、項目<key>と対応付け、さらに、項目<usr>と対応付けて記憶している。すなわち、ローカル情報記憶部416は、目的データをユーザの識別情報と対応付けて記憶している。
図23は、アプリケーション実行部435が、その実行するアプリケーションの処理に応じて目的データを取得する際の、受信機4の動作の例を示すシーケンス図である。
まず、アプリケーション制御部434が、上述のAITを、分離部402または通信入出力部411から取得し(シーケンスS101)、当該AITに従って、「アプリ001」という名称のアプリケーションの起動指令を、アプリケーション実行部435に出力する(シーケンスS102)。そして、アプリケーション実行部435は、アプリケーション制御部434から出力された起動指令に従って、アプリ001を起動して実行する(シーケンスS103)。
その後、アプリ001における処理に伴って、アプリケーション実行部435は、データ取得要求をアクセス制御部462に出力する(シーケンスS111)。このデータ取得要求は、目的データを要求する信号であり、要求する目的データを特定するための情報として、項目<key>を含む。図23の例では、アプリケーション実行部435は、項目<key>の値「name」をデータ取得要求に含めて出力している。この項目<key>の値「name」は、ローカル情報記憶部416の記憶するユーザ関連情報において、ユーザ名と対応付けられている。
データ取得要求の出力を受けたアクセス制御部462は、まず、利用状態判定要求を利用状態判定部464に出力する(シーケンスS121)。利用状態判定要求とは、ログイン状態にあるユーザの識別番号を問い合わせる要求である。そして、利用状態判定部464は、当該利用状態判定要求に従って、利用状態情報をアクセス制御部462に出力する(シーケンスS122)。
この利用状態情報は、ユーザのログイン状態を示す情報である。ここで、受信機4のユーザは、例えば、受信機4の使用開始時にログインし、受信機4の使用終了時にログアウトする。ユーザは、ログインすることによって、ユーザ毎に個別のサービスを受けることができる。ログイン状態にあるユーザが1人の場合は、利用状態情報は、当該ユーザを示すユーザの識別情報を含む。また、ログイン状態にあるユーザがいない場合または2人以上の場合、利用者状態情報は、不特定のユーザを示すユーザの識別情報「family」を含む。
そして、利用状態判定部464は、利用状態判定要求の出力を受けると、ローカル情報記憶部416がログインユーザ情報を読み出す。ログインユーザ情報が示すユーザの識別情報が1つである場合、利用状態判定部464は、利用状態情報として当該識別情報を出力する。一方、ログインユーザ情報が示すユーザの識別情報がない場合、あるいは、ログインユーザ情報が示すユーザの識別情報が複数ある場合、利用状態判定部464は、値を「family」とする利用状態情報を出力する。この利用状態情報の値「family」は、上述した項目<usr>の値「famly」と同様、ログイン状態にあるユーザを特定できない状態を示す。
図23に示す例では、1人のユーザがログイン状態になっており、利用状態判定部464は、当該ユーザの識別情報「usr001」をアクセス制御部462に出力している。
次に、アクセス制御部462は、読出要求をリソース制御部439に出力する(シーケンスS131)。この読出要求は、目的データの読出を要求する信号であり、要求する目的データを特定するための情報として利用状態判定部464から取得した項目<usr>の値と、項目<key>の値とを含む。ここでは、アクセス制御部462は、項目<usr>の値として、利用状態情報の値「usr001」を含み、また、データ取得要求に含まれていた項目<key>の値「name」を含む読出要求を出力している。
そして、リソース制御部439は、当該読出要求から項目<usr>の値と、項目<key>の値とを読み出し、これらの値に対応付けられている目的データを、ローカル情報記憶部416から読み出す(シーケンスS132)。ここでは、図22に示すように、ローカル情報記憶部416は、目的データ「山田花子」を、項目<usr>の値「usr001」および項目<key>の値「name」と対応付けて記憶している。そこで、リソース制御部439は、目的データ「山田花子」を読み出す。
そして、リソース制御部439は、読み出した目的データを、アプリケーション実行部435に出力する(シーケンスS133)。
以上により、アプリケーション実行部435は、外部I/F部417と通信可能なユーザの識別情報に対応付けられた目的データを取得する。ここで、利用状態判定部464がログイン状態にあるユーザを示すユーザの識別情報を取得して、利用状態情報を生成することで、受信機4を使用しているユーザが識別される。また、特定のユーザが受信機4を占有して利用しているか否かを判定することで、個々のユーザに関連するデータにアクセスするか、または受信機4の各ユーザに共通のデータにアクセスするかを制御することができる。従って、アプリケーション実行部435は、受信機4を使用しているユーザに応じたデータを取得することができ、当該データを用いて、受信機4を使用しているユーザに応じたサービスを提供することができる。
例えば、アプリケーション実行部435がユーザ名「山田花子」を取得した場合、受信機4の具備する表示部が当該ユーザ名を表示することで、ユーザに、自らがログインしているか否かを確認させることができる。ここで、他のユーザがログイン状態にある場合、受信機4が、当該他のユーザの識別情報と対応付けて、ログイン状態にあるユーザに関連する目的データを記憶する誤登録のおそれがある。ユーザ自らがログインしているか否かを確認させることで、かかる誤登録を防止することができる。
また、年齢制限のある番組の視聴に際して、アプリケーション実行部435が、ユーザの年齢データを取得し、アプリケーション実行部435の実行するアプリケーションが、当該データに基づいて、ユーザが当該番組を視聴可能か否かを判定することができる。
また、受信機4が情報を表示する際に、受信機4を使用しているユーザに応じて情報をフィルタリングすることもできる。例えば、アプリケーション実行部435が、その実行するアプリケーションの処理において、受信機4の具備する表示画面に広告を表示させる際、アプリケーション実行部435は、図23で説明した方法で、受信機4を使用しているユーザの年齢データや性別データを取得する。そして、アプリケーション実行部435は、表示候補として取得する広告を、ユーザの年齢や性別に基づいてフィルタリングする。
このように、受信機4が、当該受信機4を使用しているユーザに応じて情報をフィルタリングして提供することで、ユーザにとって有益な情報をより的確に提供し得る。
なお、ローカル情報記憶部416の記憶するデータを更新する場合も、図23で説明したのと同様、アプリケーション実行部435は、データ取得要求に項目<key>を含めて出力し、リソース制御部439は、当該データ取得要求に含まれる項目<key>の値と、利用状態判定部464が出力する利用状態情報とに基づいて目的データを特定して、データを更新する。
また、目的データを新たに保存する場合、アプリケーション実行部435は、目的データと、項目<key>とをデータ保存要求に含めて出力する。そして、リソース制御部439は、当該データ保存要求に含まれる項目<key>の値を読み出し、また、利用状態判定部464が出力する利用状態情報を、アクセス制御部462を介して取得する。そして、リソース制御部439は、目的データの値を、この項目<key>の値と、項目<usr>の値としての利用状態情報と対応付けて、ローカル情報記憶部416に書き込む。
なお、目的データへのアクセスを要求するアプリケーション、あるいは、当該アプリケーションの提供元に応じて、利用可能なデータを制限するようにしてもよい。
図24は、ローカル情報記憶部416の記憶するユーザ関連情報の、もう1つのデータ構造を示すデータ構造図である。図24に示すデータ構造では、図22で説明したデータ構造に加えて、項目<src>および項目<policy>が追加されている。
項目<src>には、目的データへのアクセス要求元を示すデータが格納される。項目<src>の値「own」は、ユーザ自身が目的データの格納を要求したことを示す。その他、項目<src>には、目的データの格納を要求したアプリケーションの識別情報、あるいは、当該アプリケーションの提供者の識別情報などが格納される。
また、項目<policy>には、ポリシーへのリンクとしてポリシー名が格納されている。
例えば、ポリシーがAITに含まれて送信される場合、放送受信部401が放送信号を受信すると、分離部402が放送信号からAITを分離して、アプリケーション実行制御部412に出力する。そして、アプリケーション実行制御部412は、AITからポリシーを読み出して、ローカル情報記憶部416に書き込む。ポリシーが拡張されたEITに含まれて送信される場合も同様である。
また、例えば、ポリシー判定部463が、ユーザの識別情報「usr001」と、キー情報「123456」とを出力して、ポリシーと、要求元情報とを要求すると、リソース制御部439は、「usr001」と「123456」とに対応したポリシー名「only_use_policy」に応じたポリシーと、要求元情報「アプリ101」とを、ローカル情報記憶部416から読み出してポリシー判定部463に出力する。
また、例えば、アプリケーション実行部435が、キー情報「123456」と、アプリケーション提供者の識別情報「アプリ101」とを出力してデータの読出を要求し、ポリシー判定部463が、データの読み出しを許可すると、リソース制御部439は、キー情報「name」と、利用状態判定部464から出力されるユーザの識別情報「usr001」と、に応じた目的データ「山田花子」を、ローカル情報記憶部416から読み出してアプリケーション実行部435に出力する。
図25A〜図25Dは、ローカル情報記憶部416の記憶するポリシー情報のデータ構造を示すデータ構造図である。図25A〜図25Dに示すように、ローカル情報記憶部416は、ポリシー名とポリシー本体とが対応付けられたポリシーを記憶している。ローカル情報記憶部416は、ポリシーとして、default_policyと、only_use_policyと、allow_all_policyと、src_or_popup_policyとを記憶している。
図25Aに示すコードC11は、only_use_policyを示すコードである。
このonly_use_policyは、目的データの登録を要求したアプリケーションと同一の提供者の提供するアプリケーションのみ、アクセス可能とするポリシーである。
なお、only_use_Policyが、アプリケーションの登録者に換えてアプリケーションに基づいて判定を行い、目的データの登録を要求したアプリケーションと同一アプリケーションのみ、アクセス可能とするようにしてもよい。
コードC11において、ポリシー名「only_use_policy」が、コード本体と対応付けられている。コード本体の変数「subject」には、目的データの取得を要求するアプリケーションの提供者の識別情報が格納される。また、変数「src」には、図24で説明した項目<src>に格納されている、目的データの格納を要求したアプリケーションの提供者の識別情報が格納される。
ポリシー判定部463は、only_use_policyの実行において、目的データの取得を要求するアプリケーションの提供者の識別情報と、目的データの格納を要求したアプリケーションの提供者の識別情報とが一致する場合は、条件「subject =
src」が満たされたと判定する。そして、ポリシー判定部463は、条件文「if ・・・ then ・・・ else ・・・」における「then」への分岐によって、アクセス可と回答するコード「allow_read」を実行する。これにより、ポリシー判定部463は、アクセス可を示す判定結果をアクセス制御部462に出力する。
一方、目的データの取得を要求するアプリケーションの提供者の識別情報と、目的データの格納を要求したアプリケーションの提供者の識別情報とが一致しない場合、ポリシー判定部463は、条件「subject = src」が満たされないと判定する。そして、ポリシー判定部463は、条件文「if ・・・ then ・・・ else ・・・」における「else」への分岐によって、アクセス不可と回答するコード「deny_read」を実行する。これにより、ポリシー判定部463は、アクセス不可を示す判定結果をアクセス制御部462に出力する。
図25Bに示すコードC12は、allow_all_policyを示すコードである。このallow_all_policyは、全てのアクセス要求元についてアクセス可とするポリシーである。
コードC12において、ポリシー名「allow_all_policy」が、コード本体に対応付けられている。コード本体のコード「allow_read」によって、ポリシー判定部463は、アクセス可を示す判定結果をアクセス制御部462に出力する。
図25Cに示すコードC13は、src_or_popup_policyを示すコードである。このsrc_or_popup_policyは、まず、アクセス要求元に応じてアクセス可否を判定し、アクセス不可と判定した場合は、目的データへのアクセスを許可するか否かをユーザに問い合わせるポリシーである。
コードC13において、ポリシー名「src_or_popup_policy」が、コード本体に対応付けられている。コードC11の場合と同様、目的データの格納を要求したアプリケーションの提供者の識別情報とが一致する場合は、条件「subject = src」が満たされ、ポリシー判定部463は、アクセス可を示す判定結果をアクセス制御部462に出力する。
一方、目的データの取得を要求するアプリケーションの提供者の識別情報と、目的データの格納を要求したアプリケーションの提供者の識別情報とが一致しない場合、ポリシー判定部463は、条件「subject = src」が満たされないと判定する。そして、ポリシー判定部463は、条件文「if ・・・ then ・・・ else if・・・」における「else if」への分岐によって、コード「popup−select」を実行する。このコード「popup−select」は、データへのアクセスを許可するか否かを問い合わせるポップアップウィンドウを端末装置に表示させて、ユーザの選択を取得するコードである。
コード「popup−select」において、データへのアクセスを許可するユーザ選択を取得すると、ポリシー判定部463は、条件文「else if ・・・ then ・・・ else ・・・」における「then」への分岐によって、アクセス可を回答するコード「allow_read」を実行する。これにより、ポリシー判定部463は、アクセス可を示す判定結果をアクセス制御部462に出力する。
一方、コード「popup−select」において、データへのアクセスを拒絶するユーザ選択をポリシー判定部463が取得すると、ポリシー判定部463は、条件文「else if ・・・ then ・・・ else ・・・」における「else」への分岐によって、アクセス不可を回答するコード「deny_read」を実行する。これにより、ポリシー判定部463は、アクセス不可を示す判定結果をアクセス制御部462に出力する。
図25Dに示すコードC14は、default_policyを示すコードである。このdefault_policyは、目的データへのアクセスを許可するか否かをユーザに問い合わせるポリシーである。このdefault_policyの場合、ポリシー判定部463は、例えば目的データの可否を問い合わせるポップアップ画面を端末装置に表示させ、端末装置の受け付けるユーザの選択を取得して、当該ユーザの選択に従ってアクセス可否を判定する。
コードC13で説明したように、コード「popup−select」は、データへのアクセスを許可するか否かを問い合わせるポップアップウィンドウを端末装置に表示させて、ユーザの選択を取得するコードである。
コード「popup−select」において、データへのアクセスを許可するユーザ選択をポリシー判定部463が取得すると、ポリシー判定部463は、条件文「if ・・・ then ・・・ else ・・・」における「then」への分岐によって、アクセス可を回答するコード「allow_read」を実行する。これにより、ポリシー判定部463は、アクセス可を示す判定結果をアクセス制御部462に出力する。
一方、コード「popup−select」において、データへのアクセスを拒絶するユーザ選択をポリシー判定部463が取得すると、ポリシー判定部463は、条件文「if ・・・ then ・・・ else ・・・」における「else」への分岐によって、アクセス不可を回答するコード「deny_read」を実行する。これにより、ポリシー判定部463は、アクセス不可を示す判定結果をアクセス制御部462に出力する。
図26は、アプリケーション実行部435が、その実行するアプリケーションの処理に応じて目的データを取得する際に、ポリシー判定部463がポリシー判定を行う場合の、受信機4の動作の第1例を示すシーケンス図である。
まず、アプリケーション制御部434が、上述のAITを、分離部402または通信入出力部411から取得し(シーケンスS201)、当該AITに従って、アプリ002という名称のアプリケーションの起動指令を、アプリケーション実行部435に出力する(シーケンスS202)。そして、アプリケーション実行部435は、アプリケーション制御部434から出力された起動指令に従って、アプリ002を起動して実行する(シーケンスS203)。
その後、アプリ002における処理に伴って、アプリケーション実行部435は、データ取得要求をアクセス制御部462に出力する(シーケンスS211)。この場合のデータ取得要求は、要求する目的データを特定するための情報として、ステップS111(図23)の場合における、項目<key>に加えて、項目<subject>を含む。この項目<subject>には、アクセス要求元を示す情報が格納されている。ポリシー判定において、データ取得要求元に応じてアクセス可否を決定できるようにするためである。
図26に示す例では、アプリケーション実行部435は、データ取得要求の項目<subject>にアプリ0002提供者の識別情報を格納し、項目<key>に値「name」を格納して出力している。
データ取得要求の出力を受けたアクセス制御部462は、まず、利用状態判定要求を利用状態判定部464に出力する(シーケンスS221)。そして、利用状態判定部464は、当該利用状態判定要求に従って、利用状態情報をアクセス制御部462に出力する(シーケンスS222)。図26に示す例ではステップS122(図23)の場合と同様、利用状態判定部464は、ユーザの識別情報「usr001」をアクセス制御部462に出力している。
次に、アクセス制御部462は、ポリシー判定要求をポリシー判定部463に出力する(シーケンスS231)。このポリシー判定要求は、ポリシー判定部463に対してポリシー判定を要求する信号であり、項目<subject>と、項目<usr>と、項目<key>とを含む。
ポリシー判定要求の出力を受けたポリシー判定部463は、当該ポリシー判定要求から項目<usr>の値と、項目<key>の値とを読み出し、これらの値を含むポリシー読出要求をリソース制御部439に出力する(シーケンスS232)。このポリシー読出要求は、ローカル情報記憶部416の記憶するポリシーと、ポリシー判定に用いるための項目<src>の値との読出しを要求する信号であり、ポリシーを特定するための情報として、項目<usr>と、項目<key>とを含む。
そして、リソース制御部439は、当該ポリシー読出要求から項目<usr>の値と、項目<key>の値とを読み出し、これらの値に対応付けられている項目<src>の値とポリシー名とを、ローカル情報記憶部416から読み出す。さらに、リソース制御部439は、読み出したポリシー名に対応付けられているポリシーを、ローカル情報記憶部416から読み出し(シーケンスS233)、読み出したポリシーと項目<src>の値とを、ポリシー判定部463に出力する(シーケンスS234)。図26に示す例では、リソース制御部439は、default_policyと、項目<src>の値「own」とを、ポリシー判定部463に出力している。
次に、ポリシー判定部463は、リソース制御部439から出力されるポリシーに従ってアクセス可否を判定する(シーケンスS235)。ここでは、ポリシー判定部463は、default_policyに従って、端末装置に問合せのポップアップ画面を表示させ、端末装置が受け付ける選択操作に従って、アクセス可と判定している。そして、ポリシー判定部463は、判定結果をアクセス制御部462に出力する(シーケンスS236)。
以下、シーケンスS241〜S243は、図23のシーケンスS131〜S133と同様である。なお、ポリシー判定部463がアクセス不可と判定した場合、アクセス制御部462は、目的データの取得を行わずに、アプリケーション実行部435にエラーコードを出力する。
図27は、アプリケーション実行部435が、その実行するアプリケーションの処理に応じて目的データを書き込む際に、ポリシー判定部463がポリシー判定を行う場合の、受信機4の動作の例を示すシーケンス図である。
まず、アプリケーション制御部434が、上述のAITを、分離部402または通信入出力部411から取得し(シーケンスS301)、当該AITに従って、アプリ003という名称のアプリケーションの起動指令を、アプリケーション実行部435に出力する(シーケンスS302)。そして、アプリケーション実行部435は、アプリケーション制御部434から出力された起動指令に従って、アプリ003を起動して実行する(シーケンスS303)。
その後、アプリ003における処理に伴って、アプリケーション実行部435は、データ保存要求をアクセス制御部462に出力する(シーケンスS311)。このデータ保存要求は、目的データの保存を要求する信号であり、目的データと、当該目的データと対応付けて保存する項目<key>、<src>および<policy>とを含む。
データ保存要求の出力を受けたアクセス制御部462は、まず、利用状態判定要求を利用状態判定部464に出力する(シーケンスS321)。そして、利用状態判定部464は、当該利用状態判定要求に従って、利用状態情報をアクセス制御部462に出力する(シーケンスS322)。図27に示す例では、利用状態判定部464は、受信機4を使用しているユーザを特定できない状態を示す値「family」をアクセス制御部462に出力している。
次に、アクセス制御部462は、書込要求をリソース制御部439に出力する(シーケンスS331)。この書込要求は、目的データの書込を要求する信号であり、データ保存要求に含まれる、目的データ、ならびに、当該目的データと対応付けて保存する項目<key>、<src>および<policy>に加えて、利用状態判定部464から取得した値「family」を項目<usr>の値として含む。
書込要求の出力を受けたリソース制御部439は、当該書込要求に含まれる目的データを各項目に対応付けて、ローカル情報記憶部416に書き込む(シーケンスS332)。
図28は、シーケンスS332でリソース制御部439がデータを書き込んだ後の、ローカル情報記憶部416が記憶するユーザ関連情報の例を示す図である。図28に示すように、ローカル情報記憶部416は、書込要求に含まれる目的データを、項目<usr>、<key>、<src>および<policy>に対応付けて記憶している。
データの書込を完了すると、リソース制御部439は、書込に成功したことを示す書込完了通知をアプリケーション実行部435に出力する(シーケンスS333)。
図29は、アプリケーション実行部435が、その実行するアプリケーションの処理に応じて目的データを取得する際に、ポリシー判定部463がポリシー判定を行う場合の、受信機4の動作の第2例を示すシーケンス図である。
まず、アプリケーション制御部434が、上述のAITを、分離部402または通信入出力部411から取得し(シーケンスS401)、当該AITに従って、アプリ004という名称のアプリケーションの起動指令を、アプリケーション実行部435に出力する(シーケンスS402)。そして、アプリケーション実行部435は、アプリケーション制御部434から出力された起動指令に従って、アプリ004を起動して実行する(シーケンスS403)。
その後、アプリ002における処理に伴って、アプリケーション実行部435は、データ取得要求をアクセス制御部462に出力する(シーケンスS411)。図29に示す例では、アプリケーション実行部435は、データ取得要求の項目<subject>にアプリ0004提供者の識別情報を格納し、項目<key>に値「20984721」を格納して出力している。
データ取得要求の出力を受けたアクセス制御部462は、まず、利用状態判定要求を利用状態判定部464に出力する(シーケンスS421)。そして、利用状態判定部464は、当該利用状態判定要求に従って、利用状態情報をアクセス制御部462に出力する(シーケンスS422)。図29に示す例ではステップS322(図27)の場合と同様、利用状態判定部464は、ユーザの識別情報「family」をアクセス制御部462に出力している。
次に、アクセス制御部462は、ポリシー判定要求をポリシー判定部463に出力する(シーケンスS431)。ポリシー判定要求の出力を受けたポリシー判定部463は、当該ポリシー判定要求から項目<usr>の値と、項目<key>の値とを読み出し、これらの値を含むポリシー読出要求をリソース制御部439に出力する(シーケンスS432)。
そして、リソース制御部439は、当該ポリシー読出要求から項目<usr>の値と、項目<key>の値とを読み出し、これらの値に対応付けられている項目<src>の値とポリシー名とを、ローカル情報記憶部416から読み出す。さらに、リソース制御部439は、読み出したポリシー名に対応付けられているポリシーを、ローカル情報記憶部416から読み出し(シーケンスS433)、読み出したポリシーと項目<src>の値とを、ポリシー判定部463に出力する(シーケンスS434)。図29に示す例では、リソース制御部439は、ony_use_policyと、項目<src>の値「family」とを、ポリシー判定部463に出力している。
次に、ポリシー判定部463は、リソース制御部439から出力されるポリシーに従ってアクセス可否を判定する(シーケンスS435)。ここでは、ポリシー判定部463は、ony_use_policyに従って、ポリシー判定要求に含まれる項目<subject>の値と、リソース制御部439から出力される項目<src>の値とを比較し、両者が異なることから、アクセス不可と判定している。そして、ポリシー判定部463は、判定結果をアクセス制御部462に出力する(シーケンスS436)。
アクセス不可の判定結果の出力を受けたアクセス制御部462は、ポリシーに基づいてアクセスを拒否されたことを示すエラーコードをアプリケーション実行部435に出力する(シーケンスS441)。
このように、ポリシー判定部463がポリシー判定を行い、アクセス可と判定された場合のみリソース制御部439が目的データを読み出すことで、目的データにアクセス可能なアクセス要求元を制限することができ、ユーザのプライバシー保護を図ることができる。
例えば、ローカル情報記憶部4が、クレジットカード番号を記憶しておく。そして、テレビショッピングの放送時など、ユーザがクレジット決済を行おうとする場合に、ユーザが許可するアプリケーションのみがクレジットカード番号を取得できるようにすることで、ユーザがクレジットカード番号を入力する手間を省き、かつ、クレジットカード番号の不正取得を防止し得る。
以上説明したように、アプリケーション実行部435は、外部I/F部417と通信可能なユーザの識別情報に対応付けられた目的データを取得することで、受信機4を使用しているユーザに応じたデータを取得する。これにより、受信機4は、当該データを用いて、当該受信機4を使用しているユーザ毎に個別のサービスを提供することができる。
また、ポリシー判定部463がポリシー判定を行い、アクセス可と判定された場合のみリソース制御部439が目的データを読み出すことで、受信機を使用しているユーザに関連するデータへのアクセスを管理してユーザのプライバシー保護を図ることができる。
また、ローカル情報記憶部416は、目的データとポリシーとに対して、さらにアプリケーションの識別情報を対応付けて記憶し、ポリシー判定部463は、読み出したポリシーに基づき、目的データに対応付けられたアプリケーションの識別情報と、読出要求を出力したアプリケーションの識別情報とを比較して、一致する場合にアクセスを許可する。
あるいは、ローカル情報記憶部416は、目的データとポリシーとに対して、さらにアプリケーションの提供元の識別情報を対応付けて記憶し、ポリシー判定部463は、読み出したポリシーに基づき、目的データに対応付けられたアプリケーションの提供元の識別情報と、読出要求を出力したアプリケーションの提供元の識別情報とを比較して、一致する場合にアクセスを許可する。
これによって、受信機4が、アプリケーション毎、あるいは、アプリケーションを提供する事業者毎に、ユーザに関連するデータへのアクセスを許可するか否かを判定して、ユーザのプライバシー保護を図ることができる。
また、ポリシー判定部463は、目的データへのアクセスを許可するか否を示す操作入力に従って、アクセスを許可するか否かを判定する。これによって、アクセスを許可するか否かの判定に際して、ユーザの意図を直接的に反映させることができる。
また、ローカル情報記憶部416は、キー情報毎に対応してデータを記憶し、リソース制御部439は、アプリケーション実行部435から指定されるキー情報に基づいて、ユーザの識別情報とキー情報との両方に対応付けられた目的データを読み出す。これによって、リソース制御部439は、ローカル情報記憶部416が1つのユーザの識別情報に対応付けて複数記憶する目的データの中から、所望の目的データを読み出すことができる。
上述した受信機4のアプリケーション実行制御部412及び提示制御部413は、内部にコンピュータシステムを有している。そして、受信機4のアプリケーション実行制御部412及び提示制御部413の動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータシステムが読み出して実行することによって、上記処理が行われる。ここでいうコンピュータシステムとは、CPU及び各種メモリやOS、周辺機器等のハードウェアを含む。
また、「コンピュータ読み取り可能な記録媒体」とは、非一時的に記憶する機能を有する記憶装置のことをいう。例えば、磁気ディスク、光磁気ディスク、CD−ROM、DVD−ROM、半導体ディスク(SSD)、半導体メモリ等をいうが、必ずしもこれらに限定されるものではない。
また、「記録媒体」とは、サーバやクライアントとなるコンピュータシステム内部の揮発性メモリのようにDRAMやSRAM等の揮発性媒体を含むが、必ずしもこれらに限定されるものではない。
さらに「記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の受信・送信装置、転送装置のように、短時間プログラムを保持するものを含むが、必ずしもこれらに限定されるものではない。
また、このコンピュータプログラムを放送や通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしてもよい。また上記プログラムは、上記処理の一部を実現するためのものであってもよく、さらに前述した処理をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。
本発明は、ユーザ毎に個別のサービスを提供しつつ、受信機を使用しているユーザに関連するデータへのアクセスを管理できる受信機、プログラム及び受信方法などに適用できる。
1…放送事業者装置
11…放送送出装置
111…放送関連データ管理部
112…信号設定部
113…放送送出部
12…放送局サーバ群
13…コンテンツ管理サーバ
14…番組管理サーバ
15…メタデータ管理サーバ
16…コンテンツ配信サーバ
17…放送局サービスサーバ
18…通知サーバ
2…サービス事業者サーバ群
21…受信機アプリサーバ
22…サービスサーバ
23…コンテンツ配信サーバ
24…通知サーバ
3…リポジトリサーバ
4…受信機
401…放送受信部
402…分離部
403…時計
404−1…第1同期用バッファ
404−2…第2同期用バッファ
405−1…第1デコーダ
405−2…第2デコーダ
406…データ放送実行部
407…映像制御部
408…映像表示部
409…音声制御部
410…音声出力部
411…通信入出力部
412…アプリケーション実行制御部
413…提示制御部
414…操作入力部
415…選局部
416…ローカル情報記憶部
417…外部I/F部
431…アプリケーション記憶部
432…アプリケーション認証部
433…アプリケーション管理部
434…アプリケーション制御部
435…アプリケーション実行部
436…受信機API部
437…端末連携API部
438…リソースアクセス制御部
439…リソース制御部
451…ポリシーデータ管理部
452…ポリシーデータ記憶部
453…イベント解釈部
454…ポリシーレベル照合部
455…イベント制御部
456…番組ポリシー記憶部
457…ポリシー調停部
458…ポリシーレベル記憶部
461…ログイン処理部
462…アクセス制御部
463…ポリシー判定部
464…利用状態判定部
9…通信網

Claims (3)

  1. 放送信号を受信する放送受信部と、
    ユーザの識別情報と、当該ユーザに関連するデータと、前記データへのアクセス可否の判定基準を示すポリシーとを対応付けて記憶する関連データ記憶部と、
    端末装置と通信を行ってユーザの識別情報を取得する通信部と、
    前記通信部が取得する前記ユーザの識別情報に基づいて、当該ユーザの識別情報に対応付けられた前記ポリシーを、前記関連データ記憶部から読み出し、読み出された前記ポリシーに基づいて、前記ユーザの識別情報に対応するデータへのアクセスを許可するか否かを判定するポリシー判定部と、
    前記アクセスが許可された場合に、前記ユーザの識別情報に対応するデータを前記関連データ記憶部から読み出すデータ読出部と、
    前記放送信号に含まれるアプリケーション起動指令に従ってアプリケーションを起動し、前記データ読出部が読み出したデータを用いてアプリケーションを実行するアプリケーション実行部と、
    を具備する受信機。
  2. 前記ポリシー判定部は、前記読み出したポリシーに基づき、前記識別情報が示すユーザに関連するデータへのアクセスを許可するか否かを示す操作入力に従って、アクセスを許可するか否かを判定する請求項1に記載の受信機。
  3. 受信機に用いられるコンピュータを、
    放送信号を受信する放送受信部、
    ユーザの識別情報と、当該ユーザに関連するデータと、前記データへのアクセス可否の判定基準を示すポリシーとを対応付けて記憶する関連データ記憶部、
    端末装置と通信を行ってユーザの識別情報を取得する通信部、
    前記通信部が取得する前記ユーザの識別情報に基づいて、当該ユーザの識別情報に対応付けられた前記ポリシーを、前記関連データ記憶部から読み出し、読み出された前記ポリシーに基づいて、前記ユーザの識別情報に対応するデータへのアクセスを許可するか否かを判定するポリシー判定部、
    前記アクセスが許可された場合に、前記ユーザの識別情報に対応するデータを前記関連データ記憶部から読み出すデータ読出部、
    前記放送信号に含まれるアプリケーション起動指令に従ってアプリケーションを起動し、前記データ読出部が読み出したデータを用いてアプリケーションを実行するアプリケーション実行部、
    として機能させるプログラム。
JP2013516349A 2011-05-20 2012-05-18 受信機及びプログラム Expired - Fee Related JP5986993B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2011114051 2011-05-20
JP2011114051 2011-05-20
PCT/JP2012/062826 WO2012161125A1 (ja) 2011-05-20 2012-05-18 受信機、プログラム及び受信方法

Publications (2)

Publication Number Publication Date
JPWO2012161125A1 JPWO2012161125A1 (ja) 2014-07-31
JP5986993B2 true JP5986993B2 (ja) 2016-09-06

Family

ID=47217202

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013516349A Expired - Fee Related JP5986993B2 (ja) 2011-05-20 2012-05-18 受信機及びプログラム

Country Status (4)

Country Link
US (1) US20140344846A1 (ja)
EP (1) EP2712188A4 (ja)
JP (1) JP5986993B2 (ja)
WO (1) WO2012161125A1 (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2713295A4 (en) * 2011-05-19 2015-04-22 Japan Broadcasting Corp COOPERATIVE RADIO COMMUNICATION RECEIVER, RESOURCE ACCESS CONTROL PROGRAM AND COOPERATIVE RADIO COMMUNICATION SYSTEM
US9374620B2 (en) * 2011-10-21 2016-06-21 Sony Corporation Terminal apparatus, server apparatus, information processing method, program, and interlocked application feed system
FR2995489A1 (fr) * 2012-09-07 2014-03-14 France Telecom Procede et dispositif de suggestion d'applications
US9519756B2 (en) * 2013-03-15 2016-12-13 Microsoft Technology Licensing, Llc Managing policy and permissions profiles
JP6109617B2 (ja) * 2013-03-26 2017-04-05 株式会社東芝 情報出力装置、情報操作装置、およびプログラム
JP6323753B2 (ja) 2013-06-14 2018-05-16 サン パテント トラスト 送信方法
EP3041238B1 (en) * 2013-08-28 2019-10-02 LG Electronics Inc. Signal transmission device and method for controlling same
JP6625318B2 (ja) * 2013-08-29 2019-12-25 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 送信方法および受信方法
JP6399683B2 (ja) * 2013-09-13 2018-10-03 日本放送協会 配信システム、配信装置、受信装置およびそれらのプログラム
JP6382664B2 (ja) * 2013-09-27 2018-08-29 日本放送協会 制御メッセージ生成装置、配信システム、受信装置およびそれらのプログラム
JP6213197B2 (ja) * 2013-12-05 2017-10-18 ソニー株式会社 情報処理装置および受信方法
JP2015211289A (ja) * 2014-04-24 2015-11-24 シャープ株式会社 表示装置、及び表示方法
KR102245105B1 (ko) * 2014-07-30 2021-04-28 에스케이플래닛 주식회사 클라우드 스트리밍 기반 방송 연동형 서비스 시스템, 방송 연동형 서비스 클라이언트 장치, 트리거 컨텐츠 제공 서버 및 이를 이용한 방법
JP6392365B2 (ja) 2014-10-15 2018-09-19 マクセル株式会社 放送受信装置および放送受信方法ならびに放送受信プログラム
KR20160065504A (ko) * 2014-12-01 2016-06-09 엘지전자 주식회사 멀티미디어 디바이스 및 그 제어 방법
JP6403583B2 (ja) * 2015-01-21 2018-10-10 キヤノン株式会社 アップデートされたアプリケーションを配信する配信管理サーバーおよび配信管理方法
JP6527757B2 (ja) * 2015-06-12 2019-06-05 日本テレビ放送網株式会社 視聴サービスシステム及び視聴サービス方法
CN110225370B (zh) * 2016-01-18 2021-04-02 上海交通大学 一种多媒体内容个性化呈现的时间线控制方法
JP6770871B2 (ja) * 2016-11-07 2020-10-21 日本放送協会 端末装置及びプログラム
JP6328290B2 (ja) * 2017-04-04 2018-05-23 Kddi株式会社 端末、アクセス制限方法およびプログラム
US10602338B2 (en) * 2017-07-25 2020-03-24 International Business Machines Corporation Emergency authorization to access data on proximate computing devices
JP6399714B2 (ja) * 2017-09-04 2018-10-03 日本放送協会 配信システム
JP6275316B2 (ja) * 2017-09-04 2018-02-07 日本放送協会 配信装置、受信装置、およびそれらのプログラム
US20200028879A1 (en) 2018-07-17 2020-01-23 Microsoft Technology Licensing, Llc Queryless device configuration determination-based techniques for mobile device management
US11184223B2 (en) * 2018-07-31 2021-11-23 Microsoft Technology Licensing, Llc Implementation of compliance settings by a mobile device for compliance with a configuration scenario
JP7274930B2 (ja) * 2019-05-17 2023-05-17 日本放送協会 放送通信連携サービスを実現する受信装置、端末装置及びプログラム

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003264748A (ja) * 2002-03-07 2003-09-19 Nec Corp デジタル放送受信機
JP2007135058A (ja) * 2005-11-11 2007-05-31 Nippon Hoso Kyokai <Nhk> コンテンツ提示制御装置及びそのプログラム、並びに、放送用コンテンツ配信装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8261356B2 (en) * 2005-04-08 2012-09-04 Electronics And Telecommunications Research Institute Tool pack structure and contents execution device
US8745661B2 (en) * 2006-07-31 2014-06-03 Rovi Guides, Inc. Systems and methods for providing enhanced sports watching media guidance
US20100229194A1 (en) * 2009-03-03 2010-09-09 Sony Corporation System and method for remote control based customization
US8761683B2 (en) * 2009-08-28 2014-06-24 Apple Inc. Electronic device instructions provided using radio signals
US20110072452A1 (en) * 2009-09-23 2011-03-24 Rovi Technologies Corporation Systems and methods for providing automatic parental control activation when a restricted user is detected within range of a device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003264748A (ja) * 2002-03-07 2003-09-19 Nec Corp デジタル放送受信機
JP2007135058A (ja) * 2005-11-11 2007-05-31 Nippon Hoso Kyokai <Nhk> コンテンツ提示制御装置及びそのプログラム、並びに、放送用コンテンツ配信装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JPN6012043355; 山森ほか: 'ワンセグと移動体通信の連携におけるアクセス制御方式' 映像情報メディア学会技術報告 Vol.30 No.44, 20060914, p.67-72, (社)映像情報メディア学会 *

Also Published As

Publication number Publication date
JPWO2012161125A1 (ja) 2014-07-31
EP2712188A1 (en) 2014-03-26
EP2712188A4 (en) 2015-03-11
US20140344846A1 (en) 2014-11-20
WO2012161125A1 (ja) 2012-11-29

Similar Documents

Publication Publication Date Title
JP5986993B2 (ja) 受信機及びプログラム
JP6271065B2 (ja) 受信機
JPWO2012161118A1 (ja) 端末連携システム、受信機及び受信方法
JP5965723B2 (ja) 受信機
JP2013009344A (ja) 受信機
JP5586657B2 (ja) 受信機
JP6068721B2 (ja) 受信機
JP2013009333A (ja) 受信機及び端末連携システム
JP2012257232A (ja) 受信機およびプログラム
JP2013009343A (ja) 放送通信連携システム
WO2012157718A1 (ja) 受信機および受信方法
JP2013009332A (ja) 受信機
JP6018798B2 (ja) 受信機
JP5965722B2 (ja) 受信機
JP5957291B2 (ja) 受信機
WO2012157767A1 (ja) 受信機および受信方法
JP2012257228A (ja) 受信機
JP5953111B2 (ja) 受信機
JP2013009320A (ja) 受信機
JP5586658B2 (ja) 受信機
JP6037656B2 (ja) 受信機
JP6018797B2 (ja) 受信機
JP2013008355A (ja) 受信機
JP2013009342A (ja) 受信機
JP2012257229A (ja) 受信機

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150401

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160510

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160622

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160808

R150 Certificate of patent or registration of utility model

Ref document number: 5986993

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees