【文献】
「Cover Story 携帯・家電に忍び寄るネットセキュリティの闇」,日経バイト,日本,日経BP社,2005年 7月22日,No.267,第26〜45頁,ISSN:0289-6508
【文献】
川端秀明(外6名),「Android OSにおける機能や情報へのアクセス制御機構の提案」,CSS2011 コンピュータセキュリティシンポジウム2011論文集(情報処理学会シンポジウムシリーズ Vol.2011, No.3),日本,[CD-ROM],一般社団法人情報処理学会,2011年10月12日,第161〜166頁,ISSN:1882-0840
【文献】
水野貴明,「ウェブのユーザビリティ向上計画 最終回」,OPEN DESIGN,日本,CQ出版株式会社,2002年12月 1日,2002年12月号(第9巻, 第12号),第118〜132頁
(58)【調査した分野】(Int.Cl.,DB名)
【発明の概要】
【発明が解決しようとする課題】
【0005】
特許文献1では、受信機の機能に対してAPIを設け、それらのAPIを公開してアクセスを許可することにより、受信機上で動作するアプリケーションの制作作業を効率化する。また、APIの数を増やすことにより、アプリケーションの多様性を高める。しかしながら、アクセスを許可するAPIを無制限にすると、受信機の機能や、受信機で処理するデータやコンテンツが不正に利用されるリスクが高まる。例えば、受信機が放送で受信した映像を読み込むAPIへのアクセスを無制限に許可した場合、そのAPIを用いて映像を取得し、取得した映像を複製してインターネット上に配信するようなアプリケーションであって、著作権を侵害するアプリケーションが制作されてしまうというリスクも考えられる。逆にリスクを高く見積もり、アクセスを許可するAPIの種類を制限してしまうと、アプリケーションの多様性を失うことが想定される。このように、受信機のAPIへのアクセスの許可や禁止の制御を、すべてのアプリケーションに対して同等に行うだけでは、アプリケーションの多様性とサービスに対するリスクを鑑みたときに、柔軟に両者のバランスをとることができないという問題がある。
【0006】
本発明は、このような事情を考慮してなされたもので、利用を許可するAPIをアプリケーションに応じて制限することができる受信装置
及びプログラ
ムを提供する。
【課題を解決するための手段】
【0007】
[1] 本発明の一態様は、
受信装置であって、放送信号の受信に関する制御あるいは受信した放送信号に対する処理を行う機能部と、ウェブコンテンツの記述言語により記述されたアプリケーションと、前記アプリケーションを特定するアプリ識別情報と、前記アプリケーションの種別とを対応づけて記憶するアプリケーション蓄積部と、前記アプリケーション蓄積部からアプリケーションを読み出して実行し、実行している前記アプリケーションに前記機能部の機能を利用するためのアプリケーションプログラミングインタフェースの呼び出しが記述されていた場合、前記アプリケーションのアプリ識別情報と、前記アプリケーションプログラミングインタフェースを特定するアプリケーションプログラミングインタフェース識別情報とを設定した前記アプリケーションプログラミングインタフェースの呼び出し命令を、ウェブサーバとクライアントの間で用いられるプロトコルにより出力するブラウザ部と、前記呼び出し命令に設定されている前記アプリ識別情報に対応して前記アプリケーション蓄積部に記憶されている種別に応じた判定に基づき前記アプリケーションプログラミングインタフェースへのアクセスを許可するか否かを判定するアクセス制御部と、前記ブラウザ部から前記呼び出し命令を受信して前記アプリケーションプログラミングインタフェースへのアクセスを許可するか否かを前記アクセス制御部に問い合わせるとともに、前記問い合わせに対応して前記アクセス制御部が判定した結果に応じて前記呼び出し命令を制御するウェブサーバ部と、を備え、前記アクセス制御部は、前記呼び出し命令に呼び出し元として設定されているロケーション情報が前記受信装置以外を示している場合、前記アプリケーションプログラミングインタフェースへのアクセスを拒否する受信装置である。
【0008】
この態様によれば、受信装置のブラウザ部は、ウェブコンテンツの記述言語により記述されたアプリケーションを実行し、この実行されているアプリケーションが、受信装置において提供される機能を利用するためのAPIにアクセスしようとした際、ウェブサーバ−クライアント間で用いられるプロトコルにより、API呼び出し命令を出力する。ウェブサーバ部は、アプリケーションの種別に応じてアクセス制御部が判定したAPIへのアクセス可否に従って、実行中のアプリケーションからのAPI呼び出し命令を制御する。
これにより、受信装置は、一般的なウェブコンテンツと同様の記述言語により記述されたアプリケーションを実行する。そして、受信装置は、実行しているアプリケーションからのAPIの利用可能範囲を、公式のアプリケーション、公式ではないが認定されたアプリケーションなど、アプリケーションの種別単位で制御することができる。
【0010】
さらに、受信装置は、タブレット端末や携帯端末などの他のデバイスにサーバ機能を提供しながらも、そのような他のデバイスから受信装置が提供するAPIが呼び出された場合、その呼び出しを拒否することができる。
【0011】
[
2] 本発明の
一態様は、
放送信号の受信に関する制御あるいは受信した放送信号に対する処理を行う機能部と、ウェブコンテンツの記述言語により記述されたアプリケーションと、前記アプリケーションを特定するアプリ識別情報と、前記アプリケーションの種別とを対応づけて記憶するアプリケーション蓄積部と、前記アプリケーション蓄積部からアプリケーションを読み出して実行し、実行している前記アプリケーションに前記機能部の機能を利用するためのアプリケーションプログラミングインタフェースの呼び出しが記述されていた場合、前記アプリケーションのアプリ識別情報と、前記アプリケーションプログラミングインタフェースを特定するアプリケーションプログラミングインタフェース識別情報とを設定した前記アプリケーションプログラミングインタフェースの呼び出し命令を、ウェブサーバとクライアントの間で用いられるプロトコルにより出力するブラウザ部と、前記呼び出し命令に設定されている前記アプリ識別情報に対応して前記アプリケーション蓄積部に記憶されている種別に応じた判定に基づき前記アプリケーションプログラミングインタフェースへのアクセスを許可するか否かを判定するアクセス制御部と、前記ブラウザ部から前記呼び出し命令を受信して前記アプリケーションプログラミングインタフェースへのアクセスを許可するか否かを前記アクセス制御部に問い合わせるとともに、前記問い合わせに対応して前記アクセス制御部が判定した結果に応じて前記呼び出し命令を制御するウェブサーバ部と、起動中のアプリケーションのアプリ識別情報及び種別を記憶する起動中アプリ管理リスト記憶部と、前記ブラウザ部において起動中のアプリケーションのアプリ識別情報及び種別を前記起動中アプリ管理リスト記憶部に書き込む起動中アプリ管理部と
を備え、前記アクセス制御部は、前記呼び出し命令に設定されている前記アプリ識別情報が前記起動中アプリ管理リスト記憶部に記憶されていない場合、前記アプリケーションプログラミングインタフェースへのアクセスを拒否
する受信装置である。
【0012】
この態様によれば、受信装置のアクセス制御部は、ブラウザ部において起動中のアプリケーション以外からのAPIへのアクセスを拒否する。
これにより、受信装置は、タブレット端末や携帯端末などの他のデバイスからAPIが呼び出された場合や、詐称したアプリケーション識別情報を用いてアプリケーションからAPIが呼び出された場合に、その呼び出しを拒否することができる。
【0013】
[3] 本発明の一態様は、放送信号の受信に関する制御あるいは受信した放送信号に対する処理を行う機能部と、ウェブコンテンツの記述言語により記述されたアプリケーションと、前記アプリケーションを特定するアプリ識別情報と、前記アプリケーションの種別とを対応づけて記憶するアプリケーション蓄積部と、前記アプリケーション蓄積部からアプリケーションを読み出して実行し、実行している前記アプリケーションに前記機能部の機能を利用するためのアプリケーションプログラミングインタフェースの呼び出しが記述されていた場合、前記アプリケーションのアプリ識別情報と、前記アプリケーションプログラミングインタフェースを特定するアプリケーションプログラミングインタフェース識別情報とを設定した前記アプリケーションプログラミングインタフェースの呼び出し命令を、ウェブサーバとクライアントの間で用いられるプロトコルにより出力するブラウザ部と、前記呼び出し命令に設定されている前記アプリ識別情報に対応して前記アプリケーション蓄積部に記憶されている種別に応じた判定に基づき前記アプリケーションプログラミングインタフェースへのアクセスを許可するか否かを判定するアクセス制御部と、前記ブラウザ部から前記呼び出し命令を受信して前記アプリケーションプログラミングインタフェースへのアクセスを許可するか否かを前記アクセス制御部に問い合わせるとともに、前記問い合わせに対応して前記アクセス制御部が判定した結果に応じて前記呼び出し命令を制御するウェブサーバ部と、前記アプリケーションを取得するアプリケーションマネージャ部と、前記アプリケーションマネージャ部が取得したアプリケーションに設定されている署名を検証し、検証が成功したか否かと、前記アプリケーションに設定されている前記アプリ識別情報とに基づいて種別を判定する署名検証部とを備え、前記アプリケーションマネージャ部は、取得した前記アプリケーションに対応付けて前記アプリ識別情報と、前記署名検証部が判定した種別を前記アプリケーション蓄積部に書き込む受信装置である。
この態様によれば、受信装置は、アプリケーション内に記述されている署名やアプリ識別情報によって種別を判定し、判定した種別とアプリケーションとを対応付けて記憶する。
これにより、受信装置は、必要に応じて外部からアプリケーションを取得し、取得したアプリケーションの種別を、そのアプリケーション内の記述から判定することができる。
よって、受信装置は、アプリケーションの取得後、他の装置等に問い合わせをすることなく署名を検証し、種別を判定することができるとともに、判定した種別によってAPIの利用可能範囲を制限するため、セキュリティが向上する。
[4] 本発明の
一態様において、前記受信装置は、映像を表示する映像表示部と、前記アプリケーションプログラミングインタフェースがユーザ許諾を必要とする場合、前記アプリケーションプログラミングインタフェースの利用を許可するか否かを入力するよう指示するメッセージを前記映像表示部に表示させる確認メッセージ出力部とをさらに備え、前記アクセス制御部は、前記メッセージに対応して利用を許可しない旨が入力された場合、前記アプリケーションプログラミングインタフェースへのアクセスを拒否しても良い。
【0014】
この態様によれば、受信装置のアクセス制御部は、アプリケーションから呼び出されたAPIが、ユーザ許諾を必要とするAPIであった場合、ユーザからの指示に従ってAPIの呼び出し可否を判定する。
これにより、受信装置は、現在受信中のチャンネルの情報を参照するなど個人的な情報を利用するAPIや、機能部の制御を行なうAPIなどについては、ユーザの許諾があったときのみAPIの呼び出しを許可するよう制御することができる。
【0017】
[
5] 本発明の第1の態様において、前記記述言語は、ハイパーテキストマークアップ言語であり、前記プロトコルは、ハイパーテキスト転送プロトコルであっても良い。
【0018】
この態様によれば、受信装置のブラウザ部は、HTML(Hypertext Markup Language)により記述されたアプリケーションを実行するとともに、ウェブサーバ部は、HTTP(Hypertext Transfer Protocol)によりデータを送受信する。
これにより、一般的に広く使用されているHLMLによりアプリケーションを記述することができるため、アプリケーションの作成が容易になる。また、受信装置のウェブサーバ部は、一般的にウェブに広くされているHTTPによって、他のデバイスにもサーバ機能を提供することができる。
【0019】
[
6] 本発明の
一態様は、放送信号の受信に関する制御あるいは受信した放送信号に対する処理を行う機能部を有する受信装置に用いられるコンピュータを、ウェブコンテンツの記述言語により記述されたアプリケーションと、前記アプリケーションを特定するアプリ識別情報と、前記アプリケーションの種別とを対応づけて記憶するアプリケーション蓄積部、前記アプリケーション蓄積部からアプリケーションを読み出して実行し、実行している前記アプリケーションに前記機能部の機能を利用するためのアプリケーションプログラミングインタフェースの呼び出しが記述されていた場合、前記アプリケーションのアプリ識別情報と、前記アプリケーションプログラミングインタフェースを特定するアプリケーションプログラミングインタフェース識別情報とを設定した前記アプリケーションプログラミングインタフェースの呼び出し命令を、ウェブサーバとクライアントの間で用いられるプロトコルにより出力するブラウザ部、前記呼び出し命令に設定されている前記アプリ識別情報に対応して前記アプリケーション蓄積部に記憶されている種別に応じた判定に基づき前記アプリケーションプログラミングインタフェースへのアクセスを許可するか否かを判定するアクセス制御部、前記ブラウザ部から前記呼び出し命令を受信して前記アプリケーションプログラミングインタフェースへのアクセスを許可するか否かを前記アクセス制御部に問い合わせるとともに、前記問い合わせに対応して前記アクセス制御部が判定した結果に応じて前記呼び出し命令を制御するウェブサーバ部、
として機能させ、前記アクセス制御部は、前記呼び出し命令に呼び出し元として設定されているロケーション情報が前記受信装置以外を示している場合、前記アプリケーションプログラミングインタフェースへのアクセスを拒否するように機能させるプログラムである。
[7] 本発明の一態様は、放送信号の受信に関する制御あるいは受信した放送信号に対する処理を行う機能部を有する受信装置に用いられるコンピュータを、ウェブコンテンツの記述言語により記述されたアプリケーションと、前記アプリケーションを特定するアプリ識別情報と、前記アプリケーションの種別とを対応づけて記憶するアプリケーション蓄積部、前記アプリケーション蓄積部からアプリケーションを読み出して実行し、実行している前記アプリケーションに前記機能部の機能を利用するためのアプリケーションプログラミングインタフェースの呼び出しが記述されていた場合、前記アプリケーションのアプリ識別情報と、前記アプリケーションプログラミングインタフェースを特定するアプリケーションプログラミングインタフェース識別情報とを設定した前記アプリケーションプログラミングインタフェースの呼び出し命令を、ウェブサーバとクライアントの間で用いられるプロトコルにより出力するブラウザ部、前記呼び出し命令に設定されている前記アプリ識別情報に対応して前記アプリケーション蓄積部に記憶されている種別に応じた判定に基づき前記アプリケーションプログラミングインタフェースへのアクセスを許可するか否かを判定するアクセス制御部、前記ブラウザ部から前記呼び出し命令を受信して前記アプリケーションプログラミングインタフェースへのアクセスを許可するか否かを前記アクセス制御部に問い合わせるとともに、前記問い合わせに対応して前記アクセス制御部が判定した結果に応じて前記呼び出し命令を制御するウェブサーバ部、起動中のアプリケーションのアプリ識別情報及び種別を記憶する起動中アプリ管理リスト記憶部、前記ブラウザ部において起動中のアプリケーションのアプリ識別情報及び種別を前記起動中アプリ管理リスト記憶部に書き込む起動中アプリ管理部、として機能させ、前記アクセス制御部は、前記呼び出し命令に設定されている前記アプリ識別情報が前記起動中アプリ管理リスト記憶部に記憶されていない場合、前記アプリケーションプログラミングインタフェースへのアクセスを拒否するように機能させるプログラムである。
【0020】
[8]
本発明の一態様は、放送信号の受信に関する制御あるいは受信した放送信号に対する処理を行う機能部を有する受信装置に用いられるコンピュータを、ウェブコンテンツの記述言語により記述されたアプリケーションと、前記アプリケーションを特定するアプリ識別情報と、前記アプリケーションの種別とを対応づけて記憶するアプリケーション蓄積部、前記アプリケーション蓄積部からアプリケーションを読み出して実行し、実行している前記アプリケーションに前記機能部の機能を利用するためのアプリケーションプログラミングインタフェースの呼び出しが記述されていた場合、前記アプリケーションのアプリ識別情報と、前記アプリケーションプログラミングインタフェースを特定するアプリケーションプログラミングインタフェース識別情報とを設定した前記アプリケーションプログラミングインタフェースの呼び出し命令を、ウェブサーバとクライアントの間で用いられるプロトコルにより出力するブラウザ部、前記呼び出し命令に設定されている前記アプリ識別情報に対応して前記アプリケーション蓄積部に記憶されている種別に応じた判定に基づき前記アプリケーションプログラミングインタフェースへのアクセスを許可するか否かを判定するアクセス制御部、前記ブラウザ部から前記呼び出し命令を受信して前記アプリケーションプログラミングインタフェースへのアクセスを許可するか否かを前記アクセス制御部に問い合わせるとともに、前記問い合わせに対応して前記アクセス制御部が判定した結果に応じて前記呼び出し命令を制御するウェブサーバ部、前記アプリケーションを取得するアプリケーションマネージャ部、前記アプリケーションマネージャ部が取得したアプリケーションに設定されている署名を検証し、検証が成功したか否かと、前記アプリケーションに設定されている前記アプリ識別情報とに基づいて種別を判定する署名検証部、として機能させ、前記アプリケーションマネージャ部は、取得した前記アプリケーションに対応付けて前記アプリ識別情報と、前記署名検証部が判定した種別を前記アプリケーション蓄積部に書き込むように機能させるプログラムである。
【発明の効果】
【0021】
本発明によれば、利用を許可するAPIをアプリケーションに応じて制限することができる。
【発明を実施するための形態】
【0023】
以下、図面を参照しながら本発明の実施形態を詳細に説明する。
図1は、本発明の一実施形態による受信装置1の構成を示すブロック図である。
図1では、本実施形態に関係する機能ブロックのみを抽出して示してある。
受信装置1は、例えば、テレビ、セットトップボックス、パーソナルコンピュータ、携帯端末等のデバイスであり、視聴者であるユーザが保有する。受信装置1は、放送送出装置7から放送される放送波を受信するとともに、インタフェースネットなどの通信ネットワーク9を介してアプリケーション配信装置8とデータの送受信を行う。
図1においては、放送送出装置7、アプリケーション配信装置8をそれぞれ1台のみ示しているが、複数台が設けられ得る。
【0024】
放送送出装置7は、放送事業者の放送設備であり、映像、音声、データ放送などを多重、変調し、放送波として送信する。アプリケーション配信装置8は、受信装置1上で実行されるアプリケーションプログラムファイル(以下、「アプリケーション」と記載する)を、通信ネットワーク9を経由して受信装置1に配信するコンピュータサーバである。
【0025】
受信装置1は、通信ネットワーク9を経由してアプリケーション配信装置8から通信で配信されるアプリケーションA1を実行する。アプリケーションは、ウェブコンテンツの記述言語により記述され、例えば、HTML(Hypertext Markup Language:ハイパーテキストマークアップ言語)ファイルと、そのHTMLファイルにリンクするJava(登録商標)Script、CSS(Cascading Style Sheets)などのファイルからなる。アプリケーションは、例えば、通信ネットワーク9上のコンテンツ配信装置(図示せず)からコンテンツデータを取得し、取得したコンテンツデータの映像や音声を、放送番組の映像や音声と同時に出力する。このようなアプリケーションを実行することによって、ユーザは、放送通信連携サービスを利用することができる。なお、アプリケーションは、通信ネットワーク9を経由して取得したコンテンツデータを表示させるものでなくともよく、例えば、予めアプリケーション内に記述されているコンテンツデータを表示させるものでもよい。
【0026】
アプリケーションは放送事業者や、サービス事業者、個人などにより作成される。一方、受信装置1は、この受信装置1内の複数の機能それぞれに対してAPI(Application Programming Interface:アプリケーションプログラミングインタフェース)を設けている。受信装置1がアプリケーションを実行することによって、アプリケーションがAPIを利用するためのAPIアクセスが実行される。これにより、アプリケーションは、受信装置1が有する機能や、受信装置1内で処理対象としている情報を扱う機能を利用することができる。その上で、受信装置1は、アプリケーションの種別に応じてAPIの利用可能範囲が異なるように制御する。
【0027】
本実施形態では、アプリケーションの種別が、Aアプリ、Bアプリ、Cアプリの3種類である場合について説明する。例えば、Aアプリは、第三者機関などにより公式と認定され、受信装置1上での起動が許可されたアプリケーションなどであり、すべてのAPIを利用可能とする。Bアプリは、公式のアプリケーションではないが、第三者機関などにより受信装置1上での起動が許可されたアプリケーションであり、所定の一部のAPIのみを利用可能とする。Cアプリは、認定されていないアプリケーションであり、受信装置1での起動を不可とする。そのため、Cアプリは、全てのAPIの利用が不可である。
【0028】
図1に示すように、受信装置1は、チューナー部10、レジデント部20、ブラウザ部30、出力部40、及びユーザ入力部50を備える。
【0029】
出力部40は、映像表示部41及び音声出力部42を備える。映像表示部41は、一般的なディスプレイであり、放送コンテンツデータ(以下、「放送コンテンツ」と記載する)の映像データを表示する。音声出力部42は、一般的なスピーカーあり、放送コンテンツの音声データを出力する。
ユーザ入力部50は、ユーザによる操作を受けるインタフェースである。ユーザ入力部50は、例えば、リモコン、キーボード、マウス、携帯電話、タブレット端末などにより入力されたデータを受ける。
【0030】
チューナー部10は、選局部11、放送コンテンツ取得部12、API実行部13を備える。
選局部11は、ユーザ入力部50が受けたユーザの操作に従って、受信するチャンネル選択し、選択したチャンネルの放送信号を復調する。
放送コンテンツ取得部12は、選局部11が復調した放送信号に含まれるMPEG(Moving Picture Experts Group)−2 TS(Transport Stream)信号から映像データ、音声データ、データ放送、字幕データ、PSI/SI(Program Specific Information / Service Information)など放送番組を構成する放送コンテンツを取得する。
【0031】
API実行部13は、受信装置1内の機能部に対して設けられたAPIを実行する。受信装置1が提供するAPIには、放送信号の受信に関する制御を行う機能部や、受信した放送信号に対する処理を行う機能部の制御を行ったり、動作状態を取得したりするAPIが含まれる。また、受信装置1が提供するAPIには、受信装置1の内部に記憶されているデータを参照するAPIなども含まれる。例えば、選局部11が提供するAPIには、選択されているチャンネルを参照するAPIやチャンネルの選局を制御するAPIなどがある。放送コンテンツ取得部12が提供するAPIには、放送コンテンツの参照を行うAPIなどがある。また、ユーザ入力部50からユーザが入力した情報を取得するAPIなどもあり得る。
【0032】
ブラウザ部30は、アプリケーションの実行環境であるHTMLウェブブラウザを提供する。ブラウザ部30は、放送コンテンツの表示画面のみを表示させるテンプレートや、放送コンテンツ及びアプリケーションの表示画面を同時に表示させるテンプレートを利用して、映像表示部41に映像を表示させる。テンプレートは、アプリケーションマネージャ部21に記憶されており、HTMLやCSSにより記述される。また、ブラウザ部30は、アプリケーションマネージャ部21から、アプリケーションの起動や停止の制御を受ける。起動が指示された場合、ブラウザ部30は、アプリケーションマネージャ部21のアプリケーション蓄積部211あるいはウェブサーバ部23のアプリケーション蓄積部231からアプリケーションを読み出して実行する。ブラウザ部30は、アプリケーションを実行することにより、アプリケーションの記述に従って、通信ネットワーク9を経由してコンテンツ配信装置(図示せず)からコンテンツデータを取得してアプリケーション表示画面として表示させたり、受信装置1内のAPIにアクセスしたりする。アプリケーションからAPIにアクセスする際、ブラウザ部30は、ウェブサーバとクライアントの間で用いられるプロトコルであるHTTP(Hypertext Transfer Protocol:ハイパーテキスト転送プロトコル)によりAPIの呼び出し命令をウェブサーバ部23に出力する。
【0033】
レジデント部20は、アプリケーションマネージャ部21、署名検証部22、ウェブサーバ部23、アクセス制御部24、及び確認メッセージ出力部25を備える。
【0034】
アプリケーションマネージャ部21は、放送や通信で配信されたアプリケーションを管理するとともに、アプリケーションの起動や停止を制御する。アプリケーションマネージャ部21は、アプリケーション配信装置8からアプリケーションを取得すると、署名検証部22に取得したアプリケーションを通知し、当該アプリケーションの検証結果としてアプリケーションの種別と、アプリケーションを特定する識別情報であるアプリID(アプリ識別情報)を受信する。アプリケーションマネージャ部21は、アプリケーションと、当該アプリケーションの種別及びアプリIDを対応づけて、アプリケーション蓄積部211またはアプリケーション蓄積部231に書き込む。さらに、アプリケーションマネージャ部21は、起動または停止したアプリケーションの種別及びアプリIDをアクセス制御部24に通知する。
アプリケーション蓄積部211は、Aアプリのアプリケーションや、ブラウザ部30が利用するテンプレートを記憶する。
【0035】
署名検証部22は、検証鍵を管理し、その検証鍵を用いて、アプリケーションマネージャ部21から入力されたアプリケーションに付与されている署名コード(以下、「署名」と記載する)を検証して改ざんの検知とアプリIDの取得を行い、取得したアプリIDによりアプリケーションの種別を判定する。署名検証部22は、アプリケーションの種別と、アプリケーションから取得したアプリIDをアプリケーションマネージャ部21に通知する。
【0036】
ウェブサーバ部23は、一般的なウェブサーバの機能を有し、ブラウザ部30や、外部のデバイスとの間でHTTPによりデータを送受信する。ウェブサーバ部23は、ブラウザ部30で実行されているアプリケーションからAPIにアクセスする際に経由するインタフェースとなる。ウェブサーバ部23は、APIを実行するためのHTTPリクエストであるAPI呼び出し命令をブラウザ部30から受信すると、そのAPIへのアクセスを許可するか否かをアクセス制御部24に問い合わせる。アクセス制御部24からAPIアクセスの許可を受信した場合、ウェブサーバ部23は、ブラウザ部30から受信したAPI呼び出し命令によりアクセスが要求されたAPIの実行を、API実行部13に指示する。
アプリケーション蓄積部231は、Bアプリ及びCアプリのアプリケーションを記憶する。
【0037】
アクセス制御部24は、ブラウザ部30により実行されているアプリケーションからのAPIアクセスを許可するか否かを判定する。ブラウザ部30により実行されているアプリケーションがAPIの呼び出し命令を送信することによりウェブサーバ部23を経由してAPIを呼び出す際、アクセス制御部24は、HTTPリクエスト(APIの呼び出し命令)の出力元、アプリケーションの種別、ユーザの許諾等に応じて、APIへのアクセスを許可するか否かを判定し、判定結果をウェブサーバ部23へ通知する。
【0038】
確認メッセージ出力部25は、アクセス制御部24からの命令に応じて、アプリケーションからのAPIアクセス時に、ユーザの利用許諾を求めるためのGUI(グラフィック・ユーザ・インタフェース)を映像表示部41に表示させる。確認メッセージ出力部25は、ユーザ入力部50により入力された許諾するか否かの選択結果をアクセス制御部24に通知する。
【0039】
図2は、アクセス制御部24の詳細な構成を示すブロック図である。
図2に示すように、アクセス制御部24は、起動中アプリ管理リスト記憶部241、起動中アプリ管理部242、ID・種別確認部243、APIアクセスリスト記憶部244、API確認部245、リファラ(Referer)確認部246、ユーザ許諾APIリスト記憶部247、及びユーザ許諾確認部248を備える。
【0040】
起動中アプリ管理リスト記憶部241は、起動中のアプリケーションのアプリID及び種別が記述された起動中アプリ管理リストデータを記憶する。起動中アプリ管理部242は、起動あるいは停止したアプリケーションのアプリID及び種別の通知をアプリケーションマネージャ部21から受け、起動中アプリ管理リストデータを更新する。
【0041】
ID・種別確認部243は、API呼び出し命令の変数として含まれるアプリIDと、起動中アプリ管理リスト記憶部241に記憶されている起動中アプリ管理リストデータの記述内容とを照合し、取得したアプリIDが起動中のアプリケーションのものであるかを判定する。ID・種別確認部243は、アプリIDが起動中のアプリケーションのものであると判定した場合、起動中アプリ管理リストデータからアプリIDに対応した種別を読み出す。一方、ID・種別確認部243は、アプリIDが起動中のアプリケーションのものではないと判定した場合、不正・不具合のあったアプリケーションと判定してAPIへのアクセスを拒否する。
【0042】
APIアクセスリスト記憶部244は、各種別のアプリケーションが利用できる(または利用できない)APIのリストを示すAPIアクセスリストデータを記憶する。API確認部245は、ID・種別確認部243が取得した種別と、アクセス先のAPIとにより、APIアクセスリスト記憶部244が記憶しているAPIアクセスリストデータの記述内容を照合し、アプリケーションが呼び出したAPIへのアクセスを許可するか否かを判定する。
【0043】
リファラ確認部246は、どこからAPIにアクセスしているのかを、API呼び出し命令として受信したHTTPのヘッダに記述されているリファラの値を用いて判定する。
このリファラは、API呼び出し命令の呼び出し元を示すロケーション情報である。リファラ確認部246は、受信装置1内からのアクセスではないと判定した場合、不正アクセスと判定し、APIへのアクセスを拒否する。
【0044】
ユーザ許諾APIリスト記憶部247は、ユーザの利用許諾を必要とするAPIを記述したユーザ許諾APIリストデータを記憶する。ユーザ許諾確認部248は、アクセス先のAPIがユーザの許諾を必要とするか否かを、ユーザ許諾APIリストデータの記述内容から判定する。ユーザの許諾が必要である場合、ユーザ許諾確認部248は、ユーザの利用許諾を求めるためのGUIの出力を確認メッセージ出力部25に指示し、ユーザによる許諾または拒否の結果の入力を受ける。拒否が入力された場合、ユーザ許諾確認部248は、APIへのアクセスを拒否する。
【0045】
図3は、アプリケーションが記述されたHTMLファイルの例を示す図である。
図3に示すように、アプリケーションが記述されたHTMLファイルには、<HEAD>タグから</HEAD>タグの間にヘッダが、<BODY>タグから</BODY>タグの間にアプリケーションプログラムが記述される。<HEAD>タグから</HEAD>タグまで、及び、<BODY>タグから</BODY>タグまでの部分が署名の対象である。この署名の対象部分R1から生成された署名101は、metaタグのsignature種別の値としてHTMLファイルに記述される。また、アプリID・102が、metaタグのid種別の値として記述される。なお、アプリIDは、Aアプリに使用される範囲、Bアプリに使用される範囲が予め決められている。また、アプリ名は、<HEAD>タグから</HEAD>タグまでの間のTitleタグに記述される。
【0046】
上記のように、署名がアプリケーション内に記述されるため、アプリケーションと署名を別データとして管理する必要がなく、各アプリケーションが協働して動作する場合でも、個別にアプリケーションの検証を行うことができる。また、署名及びアプリIDがmetaタグに記述されるため、画面に表示されることもない。
なお、アプリケーションプログラムには、API呼び出し命令の引数として、metaタグに書き込まれたアプリIDを用いるよう予め記述されている。
【0047】
図4は、アプリケーション蓄積部211、及びアプリケーション蓄積部231の記憶内容を示す図である。
図4に示すように、アプリケーション蓄積部211、及びアプリケーション蓄積部231には、アプリケーションと、種別、アプリID及びアプリ名とが対応付けて記憶されている。なお、アプリケーション蓄積部211には、種別がAアプリのアプリケーションのみが記憶されるため、種別は記憶されていなくともよい。
【0048】
図5は、起動中アプリ管理リスト記憶部241に記憶される起動中アプリ管理リストデータの例を示す図である。
図5に示すように、起動中アプリ管理リストデータには、起動中のアプリケーションのアプリID、種別及びアプリ名が記述されている。
【0049】
図6は、APIアクセスリスト記憶部244に記憶されるAPIアクセスリストデータの例を示す図である。種別がAアプリのアプリケーションについては、全てのAPIへのアクセスを許可し、種別がCアプリのアプリケーションについては、全てのAPIへのアクセスを禁止する。そのため、
図6に示すAPIアクセスリストデータには、Bアプリのみについてアクセス可能なAPIのAPI−ID(API識別情報)が記述されている。API−IDは、APIを一意に特定する識別情報である。
【0050】
図7は、ユーザ許諾APIリスト記憶部247に記憶されるユーザ許諾APIリストデータを示す図である。
図7に示すように、ユーザ許諾APIリストデータには、ユーザによる許諾が必要なAPIのAPI−IDとAPI名が記述されている。
【0051】
続いて、本実施形態の動作について説明する。
放送事業者や第三者機関などのアプリ認定機関は、放送局やサービス事業者などが作成したアプリケーションの認定を行うと、認定したアプリケーションの種別に応じた範囲の中から一意のアプリIDを付与する。さらに、アプリ認定機関は、アプリIDから署名鍵を生成すると、その署名鍵を用いてアプリケーションの署名対象部分から署名を生成する。第三者機関は、アプリケーションのmetaタグに、アプリIDと署名を書き込む。アプリIDと署名が付与されたアプリケーションは、アプリケーション配信装置8に登録される。
【0052】
図8は、受信装置1におけるアプリケーション取得処理の処理フローを示す図である。
まず、受信装置1のユーザ入力部50によりアプリケーション取得命令が入力される。あるいは、アプリケーションマネージャ部21が、選局部11が復調した放送信号に含まれるAIT(Application Information Table)からアプリケーション取得命令を分離する。アプリケーション取得命令には、アプリケーションの格納場所を示すロケーション情報が含まれている。ロケーション情報は、例えば、URL(Universal Resource Locator)により示される。なお、まだ受信装置1が取得していないアプリケーションの起動命令も、アプリケーション取得命令となる。
【0053】
アプリケーションマネージャ部21は、アプリケーション取得命令に設定されているロケーション情報を取得すると、そのロケーション情報が示す格納場所を宛先としてアプリケーション配信装置8にHTTPリクエストを送信し、アプリケーションの取得を要求する。アプリケーション配信装置8は、ロケーション情報に対応したアプリケーションを受信装置1に配信する(ステップS105)。
【0054】
受信装置1のアプリケーションマネージャ部21は、アプリケーション配信装置8から受信したアプリケーションを署名検証部22に出力する。署名検証部22は、アプリケーションに署名及びアプリIDが記述されているか否かを判定する(ステップS110)。
署名検証部22は、署名またはアプリIDが記述されていないと判定した場合(ステップS110:NO)、種別をCアプリと決定する(ステップS115)。
【0055】
署名及びアプリIDが記述されていると判定した場合(ステップS115:YES)、署名検証部22は、アプリケーションの署名対象部分と署名に対して、アプリIDと管理している検証鍵とを用いて署名検証を実行する。署名検証部22は、生成した署名と、アプリケーションに記述されている署名とを照合し、署名検証を行う。署名検証部22は、署名検証が失敗した場合(ステップS120:NO)、アプリケーションに改ざんがあったと判定し、種別をCアプリと決定する(ステップS115)。なお、署名方式は、ここに示した方法の限りではない。
【0056】
署名検証が成功した場合(ステップS120:YES)、署名検証部22は、アプリIDがAアプリの範囲であるか否かを判定する(ステップS125)。署名検証部22は、アプリIDがAアプリの範囲であると判定した場合(ステップS125:YES)、種別をAアプリと決定し(ステップS130)、Aアプリの範囲外であると判定した場合(ステップS125:NO)、種別をBアプリと決定する(ステップS135)。
【0057】
ステップS115、ステップS130、またはステップS135の後、署名検証部22は、アプリケーションから読み出したアプリID及びアプリ名と、決定した種別をアプリケーションマネージャ部21へ通知する。アプリケーションマネージャ部21は、署名検証部22から入力された種別がAアプリである場合、アプリケーションと、アプリID、アプリ名及び種別とを対応づけてアプリケーション蓄積部211に書き込む。一方、種別がBアプリまたはCアプリである場合、アプリケーションマネージャ部21は、アプリケーションと、アプリID、アプリ名及び種別とを対応づけてアプリケーション蓄積部231に書き込む(ステップS140)。
【0058】
なお、放送信号によりアプリケーションが配信された場合、アプリケーションマネージャ部21は、放送信号からアプリケーションを取得し、ステップS110からの処理を行う。
【0059】
図9は、受信装置1におけるアプリケーション実行処理の処理フローを示す図である。
まず、ユーザ操作や放送信号の命令により、アプリケーションマネージャ部21にアプリケーション起動指示が入力される(ステップS205)。
例えば、ユーザ入力部50は、ユーザ操作により起動対象のアプリケーションを示す情報の入力を受ける。アプリケーションマネージャ部21は、ユーザ入力部50により入力された情報が示す起動対象のアプリケーションに対応付けて記憶されているアプリID、種別及びアプリ名をアプリケーション蓄積部211またはアプリケーション蓄積部231から読み出す。
あるいは、アプリケーションマネージャ部21が、選局部11が復調した放送信号から起動対象のアプリケーションのアプリIDを取得する。アプリケーションマネージャ部21は、取得したアプリIDに対応付けて記憶されている種別及びアプリ名をアプリケーション蓄積部211またはアプリケーション蓄積部231から読み出す。
アプリケーションマネージャ部21は、読み出した種別がCアプリを示していると判定した場合(ステップS210:YES)、アプリケーションを起動せずに終了する。
【0060】
アプリケーションマネージャ部21は、種別がAアプリまたはBアプリを示していると判定した場合(ステップS210:NO)、アプリID、種別及びアプリ名をアクセス制御部24に通知する。アクセス制御部24の起動中アプリ管理部242は、アプリケーションマネージャ部21から入力されたアプリID、種別、及びアプリ名を、起動中アプリ管理リスト記憶部241に記憶されている起動中アプリ管理リストデータに書き込む(ステップS215)。
【0061】
続いて、アプリケーションマネージャ部21は、起動対象のアプリケーションの保存場所を示すロケーション情報が設定されたアプリ起動要求をブラウザ部30へ出力する。保存場所は、例えば、URL(Universal Resource Locator)により表される。ブラウザ部30は、アプリ起動要求を受信すると、ロケーション情報で示される保存場所に記憶されているアプリケーションをアプリケーション蓄積部211またはアプリケーション蓄積部231から読み出して実行する(ステップS220)。
【0062】
ブラウザ部30は、アプリケーションの実行が継続している場合(ステップS225:NO)、実行しているアプリケーションがAPIを使用するかを判定する(ステップS230)。ブラウザ部30は、実行しているアプリケーションがAPIを使用しない(APIにアクセスしない)と判定した場合(ステップS230:NO)、ステップS225からの処理を繰り返す。一方、実行しているアプリケーションがAPIを使用する(APIにアクセスする)と判定した場合(ステップS230:YES)、ブラウザ部30は、アプリケーションのHTMLファイルの記述に従って、API呼び出し命令をウェブサーバ部23へ出力する。
【0063】
ウェブサーバ部23は、アクセス制御部24にAPIのアクセスを許可するか否かを問い合わせ、アクセス制御部24は、APIアクセスを許可するか否かを判定する(ステップS235)。ウェブサーバ部23は、アクセス制御部24がAPIアクセスを許可すると判定した場合(ステップS235:YES)、API実行部13にAPI−IDを通知し、起動を指示する。API実行部13は、API−IDにより特定されるAPIを起動する(ステップS240)。これによりAPIが実行され、アプリケーションは、APIを利用することができる。受信装置1は、ステップS225からの処理を繰り返す。
一方、ウェブサーバ部23は、アクセス制御部24がAPIアクセスを拒否すると判定した場合(ステップS235:NO)、API実行させずにアプリケーションにSecurity Exceptionを返し、ステップS225からの処理を繰り返す。
【0064】
ブラウザ部30は、アプリケーションの実行が終了した場合(ステップS225:YES)、アプリケーションの実行終了通知を出力する。アプリケーションマネージャ部21は、実行終了通知を受信すると、実行が終了したアプリケーションのアプリIDをアクセス制御部24に通知する。アクセス制御部24の起動中アプリ管理部242は、アプリケーションマネージャ部21から入力されたアプリIDと、このアプリIDに対応付けて記述されている種別、及びアプリ名を、起動中アプリ管理リスト記憶部241に記憶されている起動中アプリ管理リストデータから削除する(ステップS245)。
【0065】
図10は、受信装置1におけるAPIアクセス制御処理の処理フローを示す図であり、
図9のステップS220〜ステップS240の詳細な処理を示す。
ブラウザ部30は、アプリ起動要求に設定されているロケーション情報で示される保存場所からアプリケーションを読み込み、実行する(ステップS305)。ブラウザ部30は、実行中のアプリケーションのHTMLファイルに記述されているAPI呼び出し命令103(例えば、GetXXX(‘App_ID’,‘http://localhost’))を読み出した場合、実行中のアプリケーションがAPIを使用すると判定し、読み出した記述に従ってAPI呼び出し命令をウェブサーバ部23へ出力する(ステップS310)。API呼び出し命令のプロトコルには、HTTPが使用され、呼び出すAPIのAPI−IDと、実行しているアプリケーションのアプリIDと、呼び出し命令送信元のフレームを示すロケーションが設定されたリファラとが含まれる。
図10においては、API呼び出し命令の「GetXXX」の「XXX」の部分がAPI−IDを示しており、引数「App_ID」がアプリIDを示している。また、リファラは、API呼び出し命令のHTTPヘッダに設定される。
【0066】
ウェブサーバ部23は、API呼び出し命令に設定さているアプリID、API−ID及びリファラをアクセス制御部24に出力し、APIのアクセスを許可するか否かを問い合わせる(ステップS315)。アクセス制御部24は、ウェブサーバ部23から入力された情報に基づいてAPIアクセスを許可するか否かを判定し、判定結果をウェブサーバ部23へ返送する(ステップS320)。ウェブサーバ部23は、アクセス制御部24からAPIへのアクセス許可を受信した場合、API−IDをAPI実行部13に通知し、アプリケーションとAPIのやり取りの実行を指示する(ステップS325)。これにより、APIを提供する機能部(モジュール)は、呼び出されたAPIに対応した機能を実行する。APIの実行結果を示す戻り値は、ウェブサーバ部23を介してブラウザ部30に返送される(ステップS330、S335)。このようにして、実行中のアプリケーションは、APIにアクセスし、受信装置1内のモジュールの機能を利用することができる。
【0067】
図11は、
図10のステップS315〜S320において実行されるAPIアクセス許可判定処理の処理フローを示す図である。
アクセス制御部24は、ウェブサーバ部23がAPI呼び出し命令から取得したAPI−ID、アプリID、及びリファラの入力を受ける。アクセス制御部24のID・種別確認部243は、起動中アプリ管理リスト記憶部241に記憶されている起動中アプリ管理リストデータに、ウェブサーバ部23から入力されたアプリIDが記述されているか否かを判定する(ステップS405)。
ID・種別確認部243は、起動中アプリ管理リストデータにアプリIDが記述されていないと判定した場合(ステップS405:NO)、APIへのアクセス拒否をウェブサーバ部23へ出力する(ステップS410)。
【0068】
ID・種別確認部243は、起動中アプリ管理リストデータにアプリIDが記述されていると判定した場合(ステップS405:YES)、起動中アプリ管理リストデータからアプリIDに対応づけて記憶されている種別を読み出し、API確認部245へ出力する(ステップS415)。API確認部245は、ID・種別確認部243から入力された種別がBアプリであると判定した場合(ステップS420:YES)、APIアクセスリスト記憶部244に記憶されているAPIアクセスリストデータに、ウェブサーバ部23から入力されたAPI−IDがアクセス許可対象として記述されているかを判定する(ステップS425)。
APIアクセスリストデータにAPI−IDがアクセス許可対象として記述されていないと判定した場合(ステップS425:NO)、API確認部245は、APIへのアクセス拒否をウェブサーバ部23へ出力する(ステップS410)。
【0069】
ID・種別確認部243において、ステップS420において種別がAアプリであると判定された場合(ステップS420:NO)、あるいは、APIアクセスリストデータにAPI−IDがアクセス許可対象として記述されていると判定された場合(ステップS425:YES)、リファラ確認部246は、ウェブサーバ部23から入力されたリファラを参照し、受信装置1の内部からアクセスされているかを判定する(ステップS430)。つまり、リファラが受信装置1の内部のロケーションを示していれば、受信装置1の内部からアクセスされていると判定する。受信装置1の内部以外からのアクセスであると判定した場合(ステップS430:NO)、リファラ確認部246は、APIへのアクセス拒否をウェブサーバ部23へ出力する(ステップS410)。
【0070】
一方、リファラ確認部246が、受信装置1の内部からのアクセスであると判定した場合(ステップS430:YES)、ユーザ許諾確認部248は、ウェブサーバ部23から入力されたAPI−IDが、ユーザ許諾APIリスト記憶部247に記憶されているユーザ許諾APIリストデータにユーザ許諾が必要な対象として記述されているかを判定する(ステップS435)。
【0071】
ユーザ許諾APIリストデータにユーザ許諾が必要な対象としてAPI−IDが記述されていると判定した場合(ステップS435:YES)、ユーザ許諾確認部248は、ユーザ許諾APIリストデータからAPI−IDに対応したAPI名を読み出す。さらに、ユーザ許諾確認部248は、起動中アプリ管理リスト記憶部241に記憶されている起動中アプリ管理リストデータからアプリIDに対応したアプリ名を読み出すと、API名とともに確認メッセージ出力部25に通知する。確認メッセージ出力部25は、ユーザ許諾確認部248から入力されたAPI名及びアプリ名と、APIアクセスを許可するか否かを入力するよう指示するメッセージとを映像表示部41に表示させる(ステップS440)。
【0072】
ユーザ入力部50により、APIアクセスを拒否する旨の指示が入力された場合(ステップS445:NO)、ユーザ許諾確認部248は、APIへのアクセス拒否をウェブサーバ部23へ出力する(ステップS410)。
ステップS435において、ユーザ許諾APIリストデータにユーザ許諾が必要な対象としてAPI−IDが記述されていないと判定した場合(ステップS435:NO)、あるいは、ステップS445において、ユーザ入力部50により、APIアクセスを許可する旨の指示が入力された場合(ステップS445:NO)、ユーザ許諾確認部248は、APIへのアクセス許可をウェブサーバ部23へ出力する(ステップS450)。
【0073】
なお、APIアクセスリスト記憶部244に記憶されるAPIアクセスリストデータ、ユーザ許諾APIリスト記憶部247に記憶されるユーザ許諾APIリストデータを、放送信号または通信により配信することによって更新してもよい。これにより、アプリケーションからのAPI利用可能範囲(API利用の許可または禁止)やユーザの許諾を得るAPIの利用可能範囲に対する放送事業者等の考え方が変わった場合においても、随時対応することができる。
【0074】
また、上記実施形態においては、種別をAアプリ、Bアプリ、Cアプリの3種類としたが、2種類、または、4種類以上でもよい。また、種別が他の種別を示すものでもよい。
複数の種別について一部のAPIのみの利用を許可する場合、APIアクセスリストデータに、種別と対応させて、各APIへのアクセスを許可するか否かの情報を記述しておく。そして、
図11のステップS420〜S425においては、一部のAPIの利用を許可する種別に対応して、API−IDがアクセス許可対象としてAPIアクセスリストデータに記述されているかを判定する。
【0075】
また、上記実施形態では、
図8のステップS140において、アプリケーションマネージャ部21は、Cアプリと判定したアプリケーションをアプリケーション蓄積部231に書き込んでいるが、Cアプリと判定したアプリケーションについては蓄積せずに破棄してもよい。
【0076】
上述したように、署名及びアプリIDが付加されたアプリケーションは、第三者機関が認定したアプリケーションである。一方、第三者機関による認定を受けていないアプリケーションは、非公式アプリケーションであり、アプリIDも署名も付与されない。受信装置1は、アプリケーションの取得時にアプリケーションに設定されているアプリIDを利用して署名を検証し、種別を判定すると、判定した種別をアプリケーションと紐づけて記憶する。また、上述したように、ユーザや放送からの指示に基づいて、認定されたアプリケーションがブラウザ部30により実行され、APIにアクセスしようとしたときには、ブラウザ部30からAPI−ID及びアプリIDがHTTPによりウェブサーバ部23に出力される。アクセス制御部24は、アプリIDにより特定されるアプリケーションから、API−IDにより特定されるAPIの利用を許可するか否かを判定する。
【0077】
アクセス制御部24は、アプリケーションが受信装置1内の機能を利用するために呼び出したAPIへのアクセスを許可する否かを、そのアプリケーションが受信装置1で実行中のアプリケーションであるか、APIの利用が許可された種別であるか、呼び出し元のロケーションが正しいか、ユーザがAPI利用を許諾したかなどに基づいて判定する。ウェブサーバ部23は、アクセス制御部24が判定したアクセス可否の結果に従って、アプリケーションからのAPI利用した各モジュールの機能の呼び出しを許可又は禁止するよう制御する。
これにより、アプリケーションの信頼性(受信装置1のユーザが不利益を被らない可能性)に応じて、APIの利用の許可または禁止をきめ細かく決めることができる。例えば、ユーザがいずれのチャンネルを見ているかなど個人的な趣向を特定するための情報を取得するAPIや、受信装置1の機能部を制御するAPIなどについては、公式のアプリケーション以外には利用させないようにすることが可能となる。よって、ユーザのアプリケーション利用における安全性の向上が見込まれる。
【0078】
また、APIアクセスリストデータやユーザ許諾APIリストデータなどのリストを利用するため、受信装置1(受信機)で実行するアプリケーションからのAPIアクセスの許可または禁止を柔軟に制御することができる。よって、数多くのAPIを開示して多様なアプリケーションが制作される環境においても、ユーザやコンテンツに対するセキュリティ脅威というリスクを軽減できるという効果がある。
【0079】
上述した受信装置1、放送送出装置7、及びアプリケーション配信装置8は、内部にコンピュータシステムを有している。そして、受信装置1のレジデント部20、及びブラウザ部30、放送送出装置7、ならびにアプリケーション配信装置8の動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータシステムが読み出して実行することによって、上記処理が行われる。ここでいうコンピュータシステムとは、CPU及び各種メモリやOS、周辺機器等のハードウェアを含む。
【0080】
また、「コンピュータシステム」は、WWWシステムを利用している場合であれば、ホームページ提供環境(あるいは表示環境)も含む。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶部のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含む。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。