JP2005073239A - サービス実行装置 - Google Patents

Abstract

【課題】 複数のデバイスの「組」の制御を行うサービス実行装置を提供する。
【解決手段】 Ａｂｓｔｒａｃｔサービス用のＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８においてサービスを実行するサービス実行部５７０１と、アプリケーションがサービス実行部５７０１に対してサービスの実行を要求した際に、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８とサービスが使用する複数のリソースを示すリース組情報とを関連付けるメソッド６１１２と、そのメソッド６１１２により関連付けられたＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８とリソース組情報とを保持するＳｅｒｖｉｃｅＣｏｎｔｅｘｔ管理部２００１と、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ管理部２００１に保持されたリソース組情報をサービスに供給するＪＭＦ１７０５ａとを備える。
【選択図】 図１７

Description

本発明は、デジタルテレビに関するものであり、特に複数のビデオ等処理装置を備える端末に関するものである。

テレビやＳＴＢに代表される放送受信装置のハードウェア上では、異なる機能を持つ複数のデバイスが、他方の出力がもう一方の入力となるように互いに接続され、一連の流れを形成することで大機能を実現する構成を採る。例えば、デジタル放送受信装置で映像・音声を画面に出力する場合を例にとると、ハードウェア上では、放送信号を入力とし、周波数をキーとしてフィルタリングしてＭＰＥＧ２（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ−２）トランスポートストリームを出力する「チューナー」、ＭＰＥＧ２トランスポートストリームを入力とし、その中から所望の映像・音声、データ選別し、合致したＴＳパケットが伝送する、映像・音声データ、あるいはデータを出力する「ＴＳデコーダ」、ＴＳデコーダから伝送された映像・音声データをデコードし、画面表示可能な状態で出力する「オーディオデコーダ」、「ビデオデコーダ」、「ビデオデコーダ」あるいはＣＰＵから指示された映像等を合成する「表示デバイス」が述べた順で接続され、各々のデバイスがそれぞれの機能を果たすことで映像などを画面に表示し、音声を流すことを可能としている。

このような放送受信装置において、処理を並列化するために、同一種類のデバイスが複数個存在する場合がある。例えば「チューナー」「ビデオデコーダ」が複数存在する場合、同時に複数の映像データをデコードすることが可能となり、「Ｐｉｃｔｕｒｅ Ｉｎ Ｐｉｃｔｕｒｅ（以下ＰｉｎＰ）」と呼ばれる、例えば２種類の映像を同時に表示する機能を実現することが可能となる。このように複数の同一種類のデバイスが存在する場合、例えばどの「チューナー」と「ビデオデコーダ」が接続するかは自由に接続可能であるわけではなく、通常は特定の「チューナー」と特定の「ビデオデコーダ」が接続されているようにあらかじめ決まっており、一連のデバイスを「組」として扱う。そのような場合における各デバイスの利用手法の代表例として「特開平８−２８９２２０」（特許文献１）に開示された技術を挙げる。この発明は、２つの組「主チューナー」、「主映像用デコーダ」、「挿入用チューナー」、「挿入用デコーダ」を有し、ＰｉｎＰ表示の際は「挿入用チューナー」を利用することで既に選択済みの映像・音声を画面全域に表示したまま、選択候補の映像・音声を画面上の指定領域に出力することを可能としている。

現在、ＤＶＢ−ＭＨＰ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｍｕｌｔｉｍｅｄｉａ Ｈｏｍｅ Ｐｌａｔｆｏｒｍ ＥＴＳＩ ＴＳ １０１ ８１２ Ｖ１．２．１ （２００２−０６））（非特許文献１）と呼ばれる、放送受信装置上でサービスを動作させるための仕様が欧州で定義され、既に運用が開始されている。一方、米国ではＤＶＢ−ＭＨＰ仕様をベースとしてＯＣＡＰ（ＯｐｅｎＣａｂｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ＯＣＡＰ１．０ Ｐｒｏｆｉｌｅ ＯＣ−ＳＰ−ＯＣＡＰ１．０−Ｉ０７−０３０５２２）仕様を策定中であり、２００５年度中に運用が開始される予定である。また、その他各国でも同様の仕様の策定、運用が進められている。このようなサービス実行仕様に準拠する放送受信装置は、放送信号からダウンロードする等の手法を用いて入手したプログラムを実行する機能を備えている。このようなプログラムの代表例としてゲームやＥＰＧ（Ｅｌｅｃｔｏｒｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）アプリケーションを挙げることができる。
特開平８−２８９２２０号公報 ＤＶＢ−ＭＨＰ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｍｕｌｔｉｍｅｄｉａ Ｈｏｍｅ Ｐｌａｔｆｏｒｍ ＥＴＳＩ ＴＳ １０１ ８１２ Ｖ１．２．１ （２００２−０６））

放送受信装置上で実行されるサービスとして、前述したＰｉｎＰや高機能ＥＰＧ等、複数の映像・音声を同時に一画面に表示するようなアプリケーションは当然想定される。一画面に複数の映像・音声を同時に出力するためには、前述の特許に記載される例に代表されるように、複数デバイスの「組」の制御を行わなくてはならない。しかしながら、ＤＶＢ−ＭＨＰ／ＯＣＡＰ仕様では、複数のデバイスの「組」を制御する仕組みが明記されていない。

そこで、本発明は、複数のデバイスの「組」をＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラスによって特定するという概念を導入することで、複数のデバイスの「組」の制御を行うサービス実行装置を提供することを目的とする。また、他のＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラスによって特定されるデバイスの「組」を利用する仕組みを提供する。

上記目的を達成するために、本発明に係るサービス実行装置は、１または複数のリソースを使用するサービスを実行するためのサービス実行環境において前記サービスを実行するサービス実行手段と、アプリケーションが前記サービス実行手段に対してサービスの実行を要求した際に、前記サービス実行環境と前記サービスが使用する１または複数のリソースを示すリソース組情報とを関連付ける関連付け手段と、前記関連付け手段により関連付けられた前記サービス実行環境と前記リソース組情報とを保持する保持手段と、前記保持手段により保持されたサービス実行環境において、前記保持手段に保持された前記リソース組情報を前記サービスに供給するリソース管理手段とを備えることを特徴とする。

これにより、サービス実行環境であるＳｅｒｖｉｃｅＣｏｎｔｅｘｔと、サービスが使用する１または複数のリソースを示すリソース組情報とが関連付けられるため、サービスの実行に際して、１または複数のリソースをリソースの「組」として制御することができる。

本発明のサービス実行装置は、サービスの実行に際して、１または複数のリソースをリソースの「組」として制御することができるという作用効果を奏する。

以下本発明の実施の形態について、図面を参照しながら説明する。
（実施の形態１）
本発明に係るケーブルテレビシステムの実施の形態を、図面を参照しながら説明する。図１は、ケーブルシステムを構成する装置の関係を表したブロック図であり、ヘッドエンド１０１及び３個の端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３で構成される。本実施の形態では、１つのヘッドエンドに対して３つの端末装置が結合されているが、任意の数の端末装置をヘッドエンドに結合しても、本発明は実施可能である。

ヘッドエンド１０１は、複数の端末装置に対して映像・音声・データ等の放送信号を送信するとともに、端末装置からのデータ送信を受信する。これを実現するため、ヘッドエンド１０１と端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３間の伝送に用いられる周波数帯域は、分割して用いられる。

図２は、周波数帯域の分割の一例を示す表である。周波数帯域は、Ｏｕｔ Ｏｆ Ｂａｎｄ（略称ＯＯＢ）とＩｎ−Ｂａｎｄの２種類に大別される。５〜１３０ＭＨｚがＯＯＢに割り当てられ、主にヘッドエンド１０１と端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３間のデータのやり取りに使用される。１３０ＭＨｚ〜８６４ＭＨｚはＩｎ−Ｂａｎｄに割り当てられ、主として、映像・音声を含む放送サービスに使用される。ＯＯＢではＱＰＳＫ変調方式が、Ｉｎ−ＢａｎｄではＱＡＭ６４変調方式が使用される。変調方式技術については、本発明に関与が薄い公知技術であるので、詳細な説明は省略する。

図３は、ＯＯＢ周波数帯域の更に詳細な使用の一例である。７０ＭＨｚ〜７４ＭＨｚはヘッドエンド１０１からのデータ送信に使用され、全ての端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３が、ヘッドエンド１０１から同じデータを受け取ることになる。一方、１０．０ＭＨｚ〜１０．１ＭＨｚは端末装置Ａ１１１からヘッドエンド１０１へのデータ送信に使用され、１０．１ＭＨｚ〜１０．２ＭＨｚは端末装置Ｂ１１２からヘッドエンド１０１へのデータ送信に使用され、１０．２ＭＨｚ〜１０．３ＭＨｚは端末装置Ｃ１１３からヘッドエンド１０１へのデータ送信に使用される。これにより、各端末装置固有のデータを各端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３からヘッドエンド１０１に送信することができる。

図４は、Ｉｎ−Ｂａｎｄの周波数帯に対する使用の一例である。１５０〜１５６ＭＨｚと１５６〜１６２ＭＨｚはそれぞれテレビチャンネル１とテレビチャンネル２に割り当てられ、以降、６ＭＨｚ間隔でテレビチャンネルが割り当てられている。３１０ＭＨｚ以降は、１ＭＨｚ単位でラジオチャンネルに割り当てられている。これらの各チャンネルはアナログ放送として使用してもデジタル放送として使用してもよい。デジタル放送の場合は、ＭＰＥＧ２仕様に基づいたトラスポートパケット形式で伝送され、音声や映像に加え、各種データ放送用データも送信することができる。

ヘッドエンド１０１は、これらの周波数帯域に適切な放送信号を送信するため、ＱＰＳＫ変調部やＱＡＭ変調部等を有する。また、端末装置からのデータを受信するため、ＱＰＳＫ復調器を有する。また、ヘッドエンド１０１は、これら変調部及び復調部に関連する様々な機器を有すると考えられる。しかし、本発明は主として端末装置に関わるので、詳細な説明は省略する。

端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３は、ヘッドエンド１０１からの放送信号を受信し再生する。また、ヘッドエンド１０１に対して、各端末装置固有のデータを送信する。

本実施の形態では、端末装置のうち、例えばＰｉｃｔｕｒｅ ｉｎ Ｐｉｃｔｕｒｅ、Ｄｏｕｂｌｅ Ｗｉｎｄｏｗなどに代表される２画面同時表示できる端末装置を考える。なお、本発明は２画面に限定されるものではなく任意の数の画面同時表示できる端末でも実施可能である。

図５は、端末装置のハードウエア構成を表すブロック図である。５００は端末装置であり、チューナーＡ５０１ａ、チューナーＢ５０１ｂ、ＱＰＳＫ復調部５０２、ＱＰＳＫ変調部５０３、ＴＳデコーダＡ５０５ａ、ＴＳデコーダＢ５０５ｂ、オーディオデコーダＡ５０６ａ、オーディオデコーダＢ５０６ｂ、スピーカ５０７、ビデオデコーダＡ５０８ａ、ビデオデコーダＢ５０８ｂ、ディスプレイ５０９、２次記憶部５１０、１次記憶部５１１、ＲＯＭ５１２、入力部５１３、ＣＰＵ５１４、デマルチプレクサ５１５、マルチプレクサ５１６、表示デバイスＡ５２０ａ、表示デバイスＢ５２０ｂで構成される。また端末装置５００には、ＰＯＤ５０４が着脱できる。

図６は、端末装置５００の外観の一例である薄型テレビである。
６０１は、薄型テレビの筐体であり、ＰＯＤ５０４を除く、端末装置５００の構成要素をすべてを内蔵している。

６０２はディスプレイであり、図５におけるディスプレイ５０９に相当する。
６０３は複数のボタンで構成されるフロントパネル部であり、図５の入力部５１３に相当する。

６０４は信号入力端子であり、ヘッドエンド１０１との信号の送受信を行うためにケーブル線を接続する。信号入力端子は、図５のチューナーＡ５０１ａ、チューナーＢ５０１ｂ、ＱＰＳＫ復調部５０２、ＱＰＳＫ変調部５０３と接続されている。

６０５は、図５のＰＯＤ５０４に相当するＰＯＤカードである。ＰＯＤ５０４は、図６のＰＯＤカード６０５のように、端末装置５００とは独立した形態を取り、端末装置５００に着脱可能となっている。ＰＯＤ５０４の詳細は後述する。

６０６はＰＯＤカード６０５を挿入する挿入スロットである。
また、図５に示される本端末装置は、図８の表示画面８０１で示されるように全画面表示可能であると同時に、図９に示されるように２画面同時表示も可能である。図９において、ディスプレイ５０９は２つの画面を表示し、表示画面８０１は図５においてチューナーＡ５０１ａによってヘッドエンド１０１から送信されてきた信号が復調されたものを元に再生した映像・音声、表示画面９０１は図５において、チューナーＢ５０１ｂによってヘッドエンド１０１から送信されてきた信号が復調されたものを元に再生した映像・音声を示す。

図５を参照して、チューナーＡ５０１ａ、チューナーＢ５０１ｂは、ＣＰＵ５１４から指定された周波数を含むチューニング情報で、ヘッドエンド１０１でＱＡＭ変調され送信されてきた信号を復調し、マルチプレクサ５１６に渡す。マルチプレクサ５１６では多重化を行い、ＰＯＤ５０４に引き渡す。

ＱＰＳＫ復調部５０２は、ＣＰＵ５１４から指定された周波数を含むチューニング情報で、ヘッドエンド１０１でＱＰＳＫ変調され送信されてきた信号を復調し、ＰＯＤ５０４に引き渡す。

ＱＰＳＫ変調部５０３は、ＣＰＵ５１４から指定された周波数を含む復調情報で、ＰＯＤ５０４から渡された信号をＱＰＳＫ復調し、ヘッドエンド１０１に送信する。
ＰＯＤ５０４は、図６のように端末装置本体５００から着脱可能な形態をしている。端末本体５００とＰＯＤ５０４の接続インターフェースは、ＯｐｅｎＣａｂｌｅ（ＴＭ） ＨＯＳＴ−ＰＯＤ Ｉｎｔｅｒｆａｃｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＯＣ−ＳＰ−ＨＯＳＴＰＯＤ−ＩＦ−Ｉ１２−０３０２１０）及び、この仕様書から参照されている仕様書で定義されている。ここでは、詳細は省略し、本発明に関する部分のみを解説する。

図７は、ＰＯＤ５０４の内部構成を表すブロック図である。ＰＯＤ５０４は、第１デスクランブラ部７０１、第２デスクランブラ部７０２、スクランブラ部７０３、第１記憶部７０４、第２記憶部７０５、ＣＰＵ７０６で構成される。

第１デスクランブラ部７０１は、ＣＰＵ７０６からの指示により、端末装置５００のチューナーＡ５０１ａ、チューナーＢ５０１ｂから暗号化された信号がマルチプレクサ５１６によって多重化された信号を受け取り、復号を行う。そして、復号された信号を端末装置５００のデマルチプレクサ５１５に送り逆多重化を行い、ＴＳデコーダＡ５０５ａ、ＴＳデコーダＢ５０５ｂに送る。デコードに必要な鍵などの情報はＣＰＵ７０６から適宜与えられる。具体的には、ヘッドエンド１０１はいくつかの有料チャンネルを放送している。ユーザーが、この有料チャンネルを購買すると、第１デスクランブラ部７０１は、ＣＰＵ７０６から鍵等の必要な情報を受け取りデスクランブルすることで、ユーザーは有料チャンネルを閲覧することができる。鍵などの必要な情報が与えられない場合は、第１デスクランブラ部７０１は、デスクランブルを行わず、受け取った信号をそのまま、デマルチプレクサ５１５を経てＴＳデコーダＡ５０５ａ、ＴＳデコーダＢ５０５ｂに送る。

第２デスクランブラ部７０２は、ＣＰＵ７０６からの指示により、端末装置５００のＱＰＳＫ復調部５０２から暗号化された信号を受け取り、復号を行う。そして、復号されたデータをＣＰＵ７０６に引き渡す。

スクランブラ部７０３は、ＣＰＵ７０６からの指示により、ＣＰＵ７０６から受け取ったデータを暗号化し、端末装置５００のＱＰＳＫ変調部５０３に送る。
第１記憶部７０４は、具体的にはＲＡＭ等の一次記憶メモリーで構成され、ＣＰＵ７０６が処理を行う際、一時的にデータを保存するために使用される。

第２記憶部７０５は、具体的にはフラッシュＲＯＭ等の２次記憶メモリーで構成され、ＣＰＵ７０６が実行するプログラムを格納し、また、電源ＯＦＦになっても消去されては困るデータの保存に使用される。

ＣＰＵ７０６は、第２記憶部７０５が記憶するプログラムを実行する。プログラムは複数のサブプログラムで構成される。図１０は、第２記憶部７０５が記憶するプログラムの一例である。図１０では、プログラム１０００は、メインプログラム１００１、初期化サブプログラム１００２、ネットワークサブプログラム１００３、再生サブプログラム１００４、ＰＰＶサブプログラム１００５等複数のサブプログラムで構成されている。

ここでＰＰＶとはＰａｙ Ｐｅｒ Ｖｉｅｗの略であり、映画など特定の番組を有料で視聴できるようにするサービスである。ユーザーが暗証番号を入力すると、購入したことがヘッドエンド１０１に通知され、スクランブルが解除され、視聴することが出来る。この視聴により、ユーザーは後日、購入代金を支払うものである。

メインプログラム１００１は、ＣＰＵ７０６が電源投入時に最初に起動するサブプログラムであり、他のサブプログラムの制御を行う。
初期化サブプログラム１００２は、電源投入時にメインプログラム１００１によって起動され、端末装置５００との情報交換等を行い、初期化処理を行う。初期化処理の詳細は、ＯｐｅｎＣａｂｌｅ（ＴＭ） ＨＯＳＴ−ＰＯＤ Ｉｎｔｅｒｆａｃｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＯＣ−ＳＰ−ＨＯＳＴＰＯＤ−ＩＦ−Ｉ１２−０３０２１０）及び、この仕様書から参照されている仕様書で定義されている。また、仕様書に定義されていない初期化処理も行う。ここでは、その一部を紹介する。電源が投入されると、初期化サブプログラム１００２は、第２記憶部７０５が記憶する第１の周波数を端末装置５００のＣＰＵ５１４を通して、ＱＰＳＫ復調部５０２に通知する。ＱＰＳＫ復調部５０２は、与えられた第１の周波数でチューニングを行い、信号を第２デスクランブラ部７０２に送る。また、初期化サブプログラム１００２は、第２記憶部７０５が記憶する第１の鍵等の復号情報を第２デスクランブラ部７０２に与える。その結果、第２デスクランブラ部７０２は、デスクランブルを行い、初期化サブプログラム１００２を実行するＣＰＵ７０６に引き渡す。よって、初期化サブプログラム１００２は情報を受け取ることができる。本実施の形態では、初期化サブプログラム１００２はネットワークサブプログラム１００３を通して情報を受け取ることとする。詳細は後述する。

また、初期化サブプログラム１００２は、第２記憶部７０５が記憶する第２の周波数を端末装置５００のＣＰＵ５１４を通して、ＱＰＳＫ変調部５０３に通知する。初期化サブプログラム１００２は第２記憶部７０５が記憶する暗号化情報をスクランブラ部７０３に与える。初期化サブプログラム１００２が送信したい情報を、ネットワークサブプログラム１００３を介して、スクランブラ部７０３に与えると、スクランブラ部７０３は、与えられた暗号化情報を用いて、データを暗号化し、端末装置５００のＱＰＳＫ変調部５０３に与える。ＱＰＳＫ変調部５０３は、与えられた暗号化された情報を変調し、ヘッドエンド１０１に送信する。

この結果、初期化サブプログラム１００２は、端末装置５００、第２デスクランブラ部７０２、スクランブラ部７０３、ネットワークサブプログラム１００３を通して、ヘッドエンド１０１と双方向通信を行うことができる。

ネットワークサブプログラム１００３は、メインプログラム１００１、初期化サブプログラム１００２等の複数のサブプログラムから使用される、ヘッドエンド１０１との双方向通信を行うためのサブプログラムである。具体的には、ネットワークサブプログラム１００３を使用する他のサブプログラムに対して、ＴＣＰ／ＩＰによって、ヘッドエンド１０１と双方向通信を行っているように振舞う。ＴＣＰ／ＩＰは、複数の装置間で情報交換を行うためのプロトコルを規定した公知の技術であり、詳細な説明は省略する。ネットワークサブプログラム１００３は、電源投入時に初期化サブプログラム１００２に起動されると、予め第２記憶部７０５が記憶しているＰＯＤ５０４を識別する識別子であるＭＡＣアドレス（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌアドレスの略）を、端末装置５００を通してヘッドエンド１０１に通知し、ＩＰアドレスの取得を要求する。ヘッドエンド１０１は、端末装置５００を介してＰＯＤ５０４にＩＰアドレスを通知し、ネットワークサブプログラム１００３は、ＩＰアドレスを第１記憶部７０４に記憶する。以降、ヘッドエンド１０１とＰＯＤ５０４は、このＩＰアドレスを、ＰＯＤ５０４の識別子として使用し、通信を行う。

再生サブプログラム１００４は、第２記憶部７０５が記憶する第２の鍵等の復号情報や、端末装置５００から与えられる第３の鍵等の復号情報を第１デスクランブラ部７０１に与えて、デスクランブルを可能にする。また、ネットワークサブプログラム１００３を通して、第１デスクランブラ部７０１に入力されている信号が、ＰＰＶチャンネルであることの情報を受け取る。ＰＰＶチャンネルと知ったときは、ＰＰＶサブプログラム１００５を起動する。

ＰＰＶサブプログラム１００５は、起動されると、端末装置５００に番組の購入を促すメッセージを表示し、ユーザーの入力を受け取る。具体的には、端末装置５００のＣＰＵ５１４に画面に表示したい情報を送ると、端末装置５００のＣＰＵ５１４上で動作するプログラムが、端末装置５００のディスプレイ５０９上にメッセージを表示する。ユーザーは、端末装置５００の入力部５１３を通して暗証番号を入力すると、端末装置５００のＣＰＵ５１４が、それを受け取り、ＰＯＤ５０４のＣＰＵ７０６上で動作するＰＰＶサブプログラム１００５に通知する。ＰＰＶサブプログラム１００５は、受け取った暗証番号をネットワークサブプログラム１００３を通してヘッドエンド１０１に送信する。ヘッドエンド１０１は、暗証番号が正しければ、復号に必要な第４の鍵などの復号化情報をネットワークサブプログラム１００３を介して、ＰＰＶサブプログラム１００５に通知する。ＰＰＶサブプログラム１００５は受け取った第４の鍵などの復号化情報を第１デスクランブラ部７０１に与え、第１デスクランブラ部７０１は、入力されている信号をデスクランブルする。

図５を参照して、ＴＳデコーダＡ５０５ａ、ＴＳデコーダＢ５０５ｂは、デマルチプレクサ５１５を経てＰＯＤ５０４から受け取った信号のフィルタリングを実施し、必要なデータをオーディオデコーダＡ５０６ａ、オーディオデコーダＢ５０６ｂ及びビデオデコーダＡ５０８ａ、ビデオデコーダＢ５０８ｂ、１次記憶部５１０に引き渡す。図１１ＡはＴＳデコーダＡ５０５ａを示し、図１１ＢはＴＳデコーダＢ５０５ｂを示す。ＰＩＤフィルタ１１０１ａ〜１１０１ｆは指定されたパケットＩＤのフィルタリングを行う。ＰＩＤフィルタは、ＴＳデコーダ内に複数ある。セクションフィルタＡ１１０２ａ、セクションフィルタＢ１１０２ｂは、映像、音声以外のデータをフィルタリングし、１次記憶装置に格納する。ここで、ＰＯＤ５０４から来る信号はＭＰＥＧ２トランスポートストリームである。ＭＰＥＧ２トランスポートストリームの詳細はＭＰＥＧ規格書 ＩＳＯ／ＩＥＣ１３８１８１−１に記載されており、本実施の形態では詳細は省略する。ＭＰＥＧ２トランスポートストリームは、複数の固定長パケットで構成され、各パケットには、パケットＩＤが振られている。

図１２はパケットの構成図である。１２００はパケットであり、固定長の１８８バイトで構成される。先頭４バイトがヘッダー１２０１で、パケットの識別情報を格納しており、残り１８４バイトがペイロード１２０２で、送信したい情報を含んでいる。１２０３は、ヘッダー１２０１の内訳である。先頭から１２ビット目〜２４ビット目までの１３ビットにパケットＩＤが含まれている。図１３は送られてくる複数のパケットの列を表現した模式図である。パケット１３０１は、ヘッダーにパケットＩＤ「１」を持ち、ペイロードには映像Ａの１番目の情報が入っている。パケット１３０２は、ヘッダーにパケットＩＤ「２」を持ち、ペイロードには音声Ａの１番目の情報が入っている。パケット１３０３は、ヘッダーにパケットＩＤ「３」を持ち、ペイロードには音声Ｂの１番目の情報が入っている。パケット１３１０はパケットＩＤ「１００」を持ち、ペイロードにはデータ１の１番目の情報が入っている。

パケット１３０４は、ヘッダーにパケットＩＤ「１」を持ち、ペイロードには映像Ａの２番目の情報が入っており、これはパケット１３０１の続きになっている。同様にパケット１３０５、１３１１、１３２６、１３２７も他のパケットの後続データを格納している。このように、同じパケットＩＤを持つ、パケットのペイロードの内容を連結すると、連続した映像や音声を再生することができる。また、同じパケットＩＤを持つ、パケットのペイロードの内容を連結し、映像、音声以外のデータは、１次記憶部５１１に格納する。

図５を参照して、ＣＰＵ５１４がパケットＩＤ「１」と出力先として「ビデオデコーダＡ５０８ａ」をＴＳデコーダＡ５０５ａに指示すると、ＴＳデコーダＡ５０５ａのＰＩＤフィルタ１１０１ｂはＰＯＤ５０４からデマルチプレクサ５１５を経て受け取ったＭＰＥＧ２トランスポートストリームからパケットＩＤ「１」のパケットを抽出し、ビデオデコーダＡ５０８ａに引き渡す。図５においては、映像データのみをビデオデコーダＡ５０８ａに引き渡すことになる。同時に、ＣＰＵ５１４がパケットＩＤ「２」と「オーディオデコーダＡ５０６ａ」をＴＳデコーダＡ５０５ａに指示すると、ＴＳデコーダＡ５０５ａのＰＩＤフィルタ１１０１ａはＰＯＤ５０４から受け取ったＭＰＥＧ２トランスポートストリームからパケットＩＤ「２」のパケットを抽出し、オーディオデコーダＡ５０６ａに引き渡す。またＣＰＵ５１４がパケットＩＤ「１００」と「１次記憶部５１１」をＴＳデコーダＡ５０５ａに指示すると、ＴＳデコーダＡ５０５ａのＰＩＤフィルタ１１０１ｃはＰＯＤ５０４から受け取ったＭＰＥＧ２トランスポートストリームからパケットＩＤ「１００」のパケットを抽出し、１次記憶装置に引き渡す。

このパケットＩＤに応じて必要なパケットだけを取り出す処理が、ＴＳデコーダ５０５が行うフィルタリングである。ＴＳデコーダＡ５０５ａはＣＰＵ５１４から指示された複数のフィルタリングを同時に実行することができる。

図５を参照して、オーディオデコーダＡ５０６ａ、オーディオデコーダＢ５０６ｂは、それぞれＴＳデコーダＡ５０５ａ、ＴＳデコーダＢ５０５ｂから与えられたＭＰＥＧ２トランスポートストリームのパケットに埋め込まれたオーディオデータを連結し、デジタル−アナログ変換を行いスピーカ５０７に出力する。

スピーカ５０７は、オーディオデコーダＡ５０６ａ、オーディオデコーダＢ５０６ｂから与えられた信号を音声出力する。
ビデオデコーダＡ５０８ａ、ビデオデコーダＢ５０８ｂは、それぞれＴＳデコーダＡ５０５ａ、ＴＳデコーダＢ５０５ｂから与えられたＭＰＥＧ２トランスポートストリームのパケットに埋め込まれたビデオデータを連結し、デジタル−アナログ変換を行い表示デバイスＡ５２０ａ、表示デバイスＢ５２０ｂへ出力し、合成してディスプレイ５０９に表示する。表示デバイスＡ５２０ａ、表示デバイスＢ５２０ｂは図１５のように構成されている。図１５においてグラフィックスデバイス１５０１は、画像を表示するのに用いられる。ビデオデバイス１５０２は、映像を表示するのに用いられ、バックグラウンドデバイス１５０３は映像の背景を表示するのに用いられる。最終的には、各デバイスに表示された映像、画像を合成し、ディスプレイ５０９に出力する。表示デバイスＡ５２０ａ、表示デバイスＢ５２０ｂはまた、図１６のように１つにまとめられることもまた可能である。図１６において、１６１０は表示デバイスＡ５２０ａ、表示デバイスＢ５２０ｂをあわせたものを示す。図１６において、グラフィックスデバイスＡ１６０１、ビデオデバイスＡ１６０３、バックグラウンドデバイスＡ１５０５はそれぞれ表示デバイスＡ５２０ａの構成要素、グラフィックスデバイスＢ１６０２、ビデオデバイスＢ１５０４、バックグラウンドデバイスＢ１５０６はそれぞれ表示デバイスＢ５２０ｂの構成要素と考える。これらの各デバイスは、合成され、ディスプレイ５０９に出力される。

ディスプレイ５０９は、具体的にはブラウン管や液晶等で構成される。
２次記憶部５１０は、具体的には、フラッシュメモリーやハードディスク等で構成され、ＣＰＵ５１４から指示されたデータやプログラムを保存したり削除したりする。また、保存されているデータやプログラムはＣＰＵ５１４に参照される。保存されているデータやプログラムは、端末装置５００の電源が切断された状態でも保存しつづける。

１次記憶部５１１は、具体的には、ＲＡＭ等で構成され、ＣＰＵ５１４から指示されたデータやプログラムを一次的に保存したり削除したりする。また、保存されているデータやプログラムはＣＰＵ５１４に参照される。保存されているデータやプログラムは、端末装置５００の電源が切断された際に、抹消される。

ＲＯＭ５１２は、書き換え不可能なメモリーデバイスであり、具体的にはＲＯＭやＣＤ−ＲＯＭ、ＤＶＤなどで構成される。ＲＯＭ５１２には、ＣＰＵ５１４が実行するプログラムが格納されている。

入力部５１３は、具体的には、フロントパネルやリモコンで構成され、ユーザーからの入力を受け付ける。図１４は、フロントパネルで入力部５１３を構成した場合の一例である。１４００はフロントパネルであり、図６のフロントパネル部６０３に相当する。フロントパネル１４００は７つのボタン、上カーソルボタン１４０１、下カーソルボタン１４０２、左カーソルボタン１４０３、右カーソルボタン１４０４、ＯＫボタン１４０５、取消ボタン１４０６、ＥＰＧボタン１４０７、２画面ボタン１４０８、画面選択ボタン１４０９を備えている。ユーザーがボタンを押下すると、押下されたボタンの識別子が、ＣＰＵ５１４に通知される。

ＣＰＵ５１４は、ＲＯＭ５１２が記憶するプログラムを実行する。実行するプログラムの指示に従い、チューナーＡ５０１ａ、チューナーＢ５０１ｂ、ＱＰＳＫ復調部５０２、ＱＰＳＫ変調部５０３、ＰＯＤ５０４、ＴＳデコーダＡ５０５ａ、ＴＳデコーダＢ５０５ｂ、ディスプレイ５０９、２次記憶部５１０、１次記憶部５１１、オーディオデコーダＡ５０６ａ、オーディオデコーダＢ５０６ｂ、ビデオデコーダＡ５０８ａ、ビデオデコーダＢ５０８ｂ、ＲＯＭ５１２、表示デバイスＡ５２０ａ、表示デバイスＢ５２０ｂを制御する。

図１７は、ＲＯＭ５１２に記憶され、ＣＰＵ５１４に実行されるプログラムの構成図の一例である。
プログラム１７００は、複数のサブプログラムで構成され、具体的にはＯＳ１７０１、サービス再生部１７０２、Ｊａｖａ（登録商標）ＶＭ１７０３、サービスマネージャ１７０４、Ｊａｖａライブラリ１７０５で構成される。

ＯＳ１７０１は、端末装置５００の電源が投入されると、ＣＰＵ５１４が起動するサブプログラムである。ＯＳ１７０１は、オペレーティングシステムの略であり、Ｌｉｎｕｘ（登録商標）等が一例である。ＯＳ１７０１は、他のサブプログラムを平行して実行するカーネル１７０１ａ及びライブラリ１７０１ｂで構成される公知の技術の総称であり、詳細な説明は省略する。本実施の形態においては、ＯＳ１７０１のカーネル１７０１ａは、ＪａｖａＶＭ１７０３をサブプログラムとして実行する。また、ライブラリ１７０１ｂは、これらサブプログラムに対して、端末装置５００が保持する構成要素を制御するための複数の機能を提供する。

機能の一例として、チューニング機能を紹介する。チューニング機能は、他のサブプログラムから周波数を含むチューニング情報を受け取り、それをチューナーＡ５０１ａ、あるいはチューナーＢ５０１ｂに引き渡す。

ここでは、チューナーＡ５０１ａに引き渡す場合を考える。チューナーＡ５０１ａは与えられたチューニング情報に基づき復調処理を行い、復調したデータをマルチプレクサ５１６を経てＰＯＤ５０４に引き渡すことができる。この結果、他のサブプログラムはライブラリ１７０１ｂを通してチューナーＡ５０１ａを制御することができる。

サービス再生部１７０２はサービス識別子を用いて、サービスの再生を指示する。サービス再生部１７０２は１つのＪａｖａプログラムであり、ユーザーからの入力をＪａｖａＶＭ１７０３を通して受け付ける。サービスに関しては、後述する。サービスの識別子とサービスの関係は、サービス情報として、２次記憶部５１０に予め格納されている。図１８は２次記憶部５１０に格納されているサービス情報の一例である。サービス情報は表形式で格納されている。列１８０１は、サービスの識別子である。列１８０２は、サービス名である。列１８０３はチューニング情報である。ここで、チューニング情報は周波数や転送レート、符号化率などを含み、チューナーＡ５０１ａに与える値である。列１８０４はプログラムナンバーである。プログラムナンバーとは、ＭＰＥＧ２規格で規定されているＰＭＴを識別するための番号である。ＰＭＴに関しては、後述する。行１８１１〜１８１４の各行は、各サービスの識別子、サービス名、チューニング情報の組となる。行１８１１は識別子が「１」、サービス名が「チャンネル１」、チューニング情報に周波数「３１２ＭＨｚ」、プログラムナンバーが「１０１」を含む組となっている。サービス再生部１７０２は、サービスの再生を行うため、サービスの識別子をそのままサービスマネージャ１７０４に引き渡す。サービス再生部１７０２とサービスマネージャ１７０４とのやり取りの詳細は後述する。

また、図１８において、１８２０は最後に選択されたサービスの識別子を示す。再生中に、ユーザーがフロントパネル１４００の上カーソル１４０１と下カーソル１４０２を押下すると、入力部５１３からＣＰＵ５１４を通して、押下された通知を受け取り、再生しているサービスを変更する。まず、サービス再生部１７０２は、２次記憶部５１０に現在再生中のサービスの識別子を記憶する。図１９Ａ及び図１９Ｂ並びに図１９Ｃは、２次記憶部５１０に保存しているサービスの識別子の例である。図１９Ａでは識別子「３」が記憶されており、図１８を参照し、サービス名「ＴＶ ３」のサービスが再生中であることを示す。図１９Ａの状態で、ユーザーが上カーソル１４０１を押下するとサービス再生部１７０２は、図１８のサービス情報を参照し、表中の前のサービスであるサービス名「チャンネル２」のサービスに再生を切り変えるため、サービスマネージャにサービス名「チャンネル２」の識別子「２」を引き渡す。同時に、２次記憶部５１０に記憶されているサービス識別子「２」に書き換える。図１９Ｂは、サービス識別子が書き換えられた状態を表す。また、図１９Ａの状態で、ユーザーが下カーソル１４０２を押下するとサービス再生部１７０２は、図１８のサービス情報を参照し、表中の次のサービスであるサービス名「ＴＶ Ｊａｐａｎ」のサービスに再生を切り変えるため、サービスマネージャにサービス名「ＴＶ Ｊａｐａｎ」の識別子「４」を引き渡す。同時に、１次記憶部５１１に記憶されているサービス識別子「４」に書き換える。図１９Ｃは、サービス識別子が書き換えられた状態を表す。

ＪａｖａＶＭ１７０３は、Ｊａｖａ（ＴＭ）言語で記述されたプログラムを逐次解析し実行するＪａｖａバーチャルマシンである。Ｊａｖａ言語で記述されたプログラムはバイトコードと呼ばれる、ハードウエアに依存しない中間コードにコンパイルされる。Ｊａｖａバーチャルマシンは、このバイトコードを実行するインタープリタである。また、一部のＪａｖａバーチャルマシンは、バイトコードをＣＰＵ５１４が理解可能な実行形式に翻訳してから、ＣＰＵ５１４に引渡し、実行することも行う。ＪａｖａＶＭ１７０３は、カーネル１７０１ａに実行するＪａｖａプログラムを指定され起動される。本実施の形態では、カーネル１７０１ａは、実行するＪａｖａプログラムとしてサービスマネージャ１７０４を指定する。Ｊａｖａ言語の詳細は、書籍「Ｊａｖａ Ｌａｎｇｕａｇｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ ０−２０１−６３４５１−１）」等の多くの書籍で解説されている。ここでは、その詳細を省略する。また、ＪａｖａＶＭ自体の詳細な動作などは、「Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ ０−２０１−６３４５１―Ｘ）」等の多くの書籍で解説されている。ここでは、その詳細を省略する。

サービスマネージャ１７０４は、Ｊａｖａ言語で書かれたＪａｖａプログラムであり、ＪａｖａＶＭ１７０３によって逐次実行される。サービスマネージャ１７０４は、ＪＮＩ（Ｊａｖａ Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ）を通して、Ｊａｖａ言語で記述されていない他のサブプログラムを呼び出したり、または、呼び出されたりすることが可能である。ＪＮＩに関しても、書籍「Ｊａｖａ Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ」等の多くの書籍で解説されている。ここでは、その詳細を省略する。

サービスマネージャ１７０４は図２０のように構成される。サービスマネージャ１７０４はＳｅｒｖｉｃｅＣｏｎｔｅｘｔ管理部２００１とＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部２００２、ＸＡＩＴ情報取得部２００３、およびＸＡＩＴ情報保存部２００４からなる。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ管理部２００１はＳｅｒｖｉｃｅＣｏｎｔｅｘｔの識別子とＳｅｒｖｉｃｅＣｏｎｔｅｘｔを対にして保持する。図２１で示されるように、２１０１の列は、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの識別子を示し、２１０２の列は、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを表す。行２１０３はＳｅｒｖｉｃｅＣｏｎｔｅｘｔの識別子「１」がＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡと対応付けられることを表す。行２１０４はＳｅｒｖｉｃｅＣｏｎｔｅｘｔの識別子「２」によってＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＢを表す。行２１０５はＳｅｒｖｉｃｅＣｏｎｔｅｘｔの識別子「３」でＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを表す。

ここでいうＩｎ−ｂａｎｄのサービスとは映像・音声、Ｊａｖａプログラムなどを含む表示・実行をする単位であり、ＤＶＢ−ＭＨＰ規格（正式には、ＥＴＳＩ ＴＳ １０１ ８１２ ＤＶＢ−ＭＨＰ仕様Ｖ１．０．２）では９章に定義されているサービスのことをいう。

ＳｅｒｖｉｃｅＣｏｎｔｅｘｔはＪａｖａＴＶ（Ｊａｖａ ＴＶ ＡＰＩ Ｖｅｒｓｉｏｎ１．０ ｓｐｅｃｉｆｉｃａｔｉｏｎ）の仕様によって定義される。Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６，Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＢ２１０７とは、１つのサービスを動作させるために必要なリソースの組を特定し、そのリソースの組を用いて１つのＩｎ−ｂａｎｄのサービスを実行するものである。

図２２はＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６、あるいはＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＢ２１０７を示したものである。２２０１はサービス実行部であり、２２０２はリソースの組保持部、２２０３はリソースの組取得部である。サービス識別子をサービス実行部２２０１に渡すと、サービス実行部２２０１はリソースの組保持部２２０２によって示されたリソースの組を用いてＩｎ−ｂａｎｄのサービスを実行する。リソースの組保持部２２０２は、図２３によって示される。図２３は、リソースの組識別子２３０１とリソースの組２３０２（１又は複数のリソースを示すリソース組情報を含む情報）を対にして保持している例を示したものである。リソースの組取得部２２０３はリソースの組保持部２２０２によって保持されるリソースの組を取得する。本実施の形態ではリソースの組取得部２２０３はＪａｖａライブラリ１７０５からのみ利用される。

図２４ではリソースの一例を示す。図２４で示されるリソースはチューナーＡ５０１ａ，チューナーＢ５０１ｂ、ＴＳデコーダＡ５０５ａ，ＴＳデコーダＢ５０５ｂ、オーディオデコーダＡ５０６ａ，オーディオデコーダＢ５０６ｂ、ビデオデコーダＡ５０８ａ，ビデオデコーダＢ５０８ｂである。２４１０、２４１１はそれぞれのリソースの組を表す。チューナーＡ５０１ａ，チューナーＢ５０１ｂ、ＴＳデコーダＡ５０５ａ，ＴＳデコーダＢ５０５ｂ、オーディオデコーダＡ５０６ａ，オーディオデコーダＢ５０６ｂ、ビデオデコーダＡ５０８ａ，ビデオデコーダＢ５０８ｂは図５において説明したものであるので、ここでは省略する。

なお、本実施の形態では、リソースとして、チューナーＡ５０１ａ，チューナーＢ５０１ｂ、ＴＳデコーダＡ５０５ａ，ＴＳデコーダＢ５０５ｂ、オーディオデコーダＡ５０６ａ，オーディオデコーダＢ５０６ｂ、ビデオデコーダＡ５０８ａ，ビデオデコーダＢ５０８ｂを考えているが、他の構成、あるいは他のリソースがあっても本実施の形態は実施可能である。

１つのＩｎ−ｂａｎｄのサービスを動作させるためには、サービスマネージャ１７０４が管理するＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２００２，あるいはＳｅｒｖｉｃｅＣｏｎｔｅｘｔＢ２００３のサービス実行部２２０１に動作させたいサービス識別子を指定する。図２５はその一連のフローチャートを示す。例えばサービス再生部１７０２がＩｎ−ｂａｎｄのサービスを実行したい場合、サービス再生部１７０２はまずサービスマネージャ１７０４のＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部２００２に対してＳｅｒｖｉｃｅＣｏｎｔｅｘｔの取得要求を行う（ステップＳ２５０１）。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部２００２は取得要求に応じてＳｅｒｖｉｃｅＣｏｎｔｅｘｔ管理部２００１からＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６またはＳｅｒｖｉｃｅＣｏｎｔｅｘｔＢ２１０７を取得し、サービス再生部１７０２に通知する。（ステップＳ２５０２）。サービス再生部１７０２は取得したＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６、またはＳｅｒｖｉｃｅＣｏｎｔｅｘｔＢ２１０７のサービス実行部２２０１にサービス識別子を渡す（ステップＳ２５０３）。サービス識別子を渡されたＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６、またはＳｅｒｖｉｃｅＣｏｎｔｅｘｔＢ２１０７のサービス実行部２２０１は使用するリソースの組Ａ２４１０またはリソースの組Ｂ２４１１を用いてサービス識別子に対応するＩｎ−ｂａｎｄのサービスＡ２６０１またはサービスＢ２６０２を実行する（ステップＳ２５０４）。

図２６はサービスとＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースの組の関係を示す。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６はリソースの組Ａ２４１０を用いてＩｎ−ｂａｎｄのサービスＡ２６０１を実行する。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＢ２１０７はリソースの組Ｂ２４１１を用いてサービスＢ２６０２を実行する。その他の構成要素は図２４に示したとおりであるので省略する。

本実施の形態では、まず、ユーザーによって電源を投入され、その後、フロントパネル１４００の２画面ボタン４０８によって２画面表示される場合を考える。
ユーザーによって、電源を投入されると、２次記憶部５１０に記憶してある最後に選択したサービス識別子が示すＩｎ−ｂａｎｄのサービスを実行する。

サービス再生部１７０２はＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６のサービス実行部２２０１にサービス識別子を渡す。
Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６のサービス実行部２２０１は、最初にＪａｖａライブラリ１７０５の中にあるＴｕｎｅｒ１７０５ｃに、サービス識別子を引き渡し、チューニングを依頼する。チューニングを依頼するためにサービス実行部２２０１は図２７のフローチャートに示す動作をする。サービス実行部２２０１はＴｕｎｅｒ１７０５ｃにおいてチューナーＡ５０１ａのＪａｖａのクラスのインスタンスを取得要求する（ステップＳ２７０１）。Ｔｕｎｅｒ１７０５ｃはチューナーＡ５０１ａのＪａｖａのクラスのインスタンスを要求した呼び出し元を特定する（ステップＳ２７０２）。例えば、Ｔｕｎｅｒ１７０５ｃは、インスタンスを要求した呼び出し元をスレッドによって判断する。ここで、スレッドはそのスレッドが属する組によってＪａｖａプログラムを識別することができる。Ｊａｖａプログラムから属しているＳｅｒｖｉｃｅを取得し、そこから、サービスマネージャに問い合わせ、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６を特定することができる。Ｔｕｎｅｒ１７０５ｃはステップＳ２７０２で特定したＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６のリソースの組取得部２２０３より、リソースの組Ａ２４１０を取得する（ステップＳ２７０３）。Ｔｕｎｅｒ１７０５ｃはステップＳ２７０３において取得したリソースの組２４１０に含まれるチューナーＡ５０１ａを用いるチューナーを表現するＪａｖａのクラスのインスタンスを返す（ステップＳ２７０４）。サービス実行部２２０１はステップＳ２７０４で取得したインスタンスを指定してＴｕｎｅｒ１７０５ｃにチューニング要求を行う（ステップＳ２７０５）。Ｔｕｎｅｒ１７０５ｃはチューニング要求を受けると、２次記憶部５１０が記憶するサービス情報を参照し、チューニング情報を獲得する。Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２００１のサービス実行部２２０１がサービス識別子「２」をＴｕｎｅｒ１７０５ｃに引き渡すと、Ｔｕｎｅｒ１７０５ｃは、図１８の行１８１２を参照して、対応するチューニング情報「１５６ＭＨｚ」を獲得する。Ｔｕｎｅｒ１７０５ｃは、ＯＳ１７０１のライブラリ１７０１ｂを通して、チューナーＡ５０１ａにチューニング情報を引き渡す。チューナーＡ５０１ａは与えられたチューニング情報に従ってヘッドエンド１０１から送信されてきた信号を復調し、マルチプレクサ５１６を通してＰＯＤ５０４に引き渡す。

次にＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２００１のサービス実行部２２０１は、Ｊａｖａライブラリ１７０５の中にあるＣＡ１７０５ｄにデスクランブルを依頼する。ＣＡ１７０５ｄは、ＯＳ１７０１のライブラリ１７０１ｂを通して復号に必要な情報をＰＯＤ５０４に与える。ＰＯＤ５０４は、与えられた情報を元に、チューナーＡ５０１ａから与えられた信号を復号しデマルチプレクサ５１５を通してＴＳデコーダ５０５に引き渡す。

次にＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２００１のサービス実行部２２０１は、Ｊａｖａライブラリ１７０５の中にあるＪＭＦ１７０５ａにサービス識別子を与え、映像・音声の再生を依頼する。

図２８はフローチャートを示す。
まず、サービス実行部２２０１はＪＭＦ１７０５ａにおいて映像・音声を再生するためのリソース（ＴＳデコーダＡ５０５ａ、オーディオデコーダ５０６ａ、ビデオデコーダ５０８ａ）を表すＪａｖａのクラスのインスタンスの取得要求する（ステップＳ２８０１）。

ＪＭＦ１７０５ａは映像・音声を再生するためのリソースのＪａｖａのクラスのインスタンスを要求した呼び出し元を例えばスレッドによって判断する。（ステップＳ２８０２）。ここで、スレッドは、そのスレッドが属する組によってＪａｖａプログラムを識別することができ、そこから、サービスを特定し、サービスマネージャ１７０４に問い合わせることによってＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６を特定することができる。

ＪＭＦ１７０５ａはステップＳ２８０２で特定したＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６のリソースの組取得部２２０３より、リソースの組Ａ２４１０を取得する（ステップＳ２８０３）。

ＪＭＦ１７０５ａはステップＳ２８０３において取得したリソースの組２４１０に含まれる映像・音声を再生するためのリソースの組を表現するＪａｖａのクラスのインスタンスを返す（ステップＳ２８０４）。

サービス実行部２２０１はステップＳ２８０４で取得したインスタンスを用いてＪＭＦ１７０５ａに映像・音声の再生要求を行う（ステップＳ２８０５）。ＪＭＦ１７０５ａは再生要求を受けた後、再生すべき映像と音声を特定するためのパケットＩＤをＰＡＴ、ＰＭＴから取得する。ＰＡＴやＰＭＴはＭＰＥＧ２規格で規定されている、ＭＰＥＧ２トランスポートストリーム内の番組構成を表現するテーブルであり、ＭＰＥＧ２トランスポートストリームに含まれるパケットのペイロードに埋め込まれて、音声や映像と共に送信されるものである。詳細は規格書を参照されたい。ここでは、概略のみ説明する。

ＰＡＴは、Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅの略で、パケットＩＤ「０」のパケットに格納され送信されている。ＪＭＦ１７０５ａは、ＰＡＴを取得するため、ＯＳ１７０１のライブラリ１７０１ｂを通して、ＴＳデコーダＡ５０５ａにパケットＩＤ「０」とＣＰＵ５１４を指定する。ＴＳデコーダＡ５０５ａがパケットＩＤ「０」でフィルタリングを行い、ＣＰＵ５１４に引き渡すことでＪＭＦ１７０５ａは、ＰＡＴのパケットを収集する。

図２９は、収集したＰＡＴの情報の一例を模式的に表した表である。列２９０１は、プログラムナンバーである。列２９０２は、パケットＩＤである。列２９０２のパケットＩＤはＰＭＴを取得するために用いられる。行２９１１〜２９１３は、サービスのプログラムナンバーと対応するパケットＩＤの組である。ここでは、３つのサービスが定義されている。行２９１１はプログラムナンバー「１０１」とパケットＩＤ「５０１」の組が定義されている。

今、ＪＭＦ１７０５ａに与えられたサービス識別子が「２」とすると、ＪＭＦ１７０５ａは、図１８の行１８１２を参照して、対応するプログラムナンバー「１０２」を獲得し、次に、図２９のＰＡＴの行２９１２を参照し、プログラムナンバー「１０２」に対応するパケットＩＤ「５０２」を獲得する。ＰＭＴは、Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅの略で、ＰＡＴで規定されたパケットＩＤのパケットに格納され送信されている。ＪＭＦ１７０５ａは、ＰＭＴを取得するため、ＯＳ１７０１のライブラリ１７０１ｂを通して、ＴＳデコーダＡ５０５ａにパケットＩＤとＣＰＵ５１４を指定する。ここで、指定するパケットＩＤは「５０２」とする。ＴＳデコーダＡ５０５ａがパケットＩＤ「５０２」でフィルタリングを行い、ＣＰＵ５１４に引き渡すことでＪＭＦ１７０５ａは、ＰＭＴのパケットを収集する。

図３０は、収集したＰＭＴの情報の一例を模式的に表した表である。列３００１は、ストリーム種別であり、列３００２は、パケットＩＤである。列３００２で指定されるパケットＩＤのパケットには、ストリーム種別で指定された情報がペイロードに格納され送信されている。列３００３は補足情報である。行３０１１〜３０１４はエレメンタリ−ストリームと呼ばれる、パケットＩＤと送信している情報の種別の組である。行３０１１は、ストリーム種別「音声」とパケットＩＤ「５０１１」の組であり、パケットＩＤ「５０１１」のペイロードには音声が格納されていることを表す。ＪＭＦ１７０５ａは、ＰＭＴから再生する映像と音声のパケットＩＤを獲得する。図３０を参照して、ＪＭＦ１７０５ａは、行３０１１から音声のパケットＩＤ「５０１１」を、行３０１２から映像のパケットＩＤ「５０１２」を獲得する。

次に、ＪＭＦ１７０５ａは、ＯＳ１７０１のライブラリ１７０１ｂを通して、獲得した音声のパケットＩＤと出力先としてオーディオデコーダＡ５０６ａ、映像のパケットＩＤと出力先としてビデオデコーダ５０８ａの組を、ＴＳデコーダＡ５０５ａに与える。ＴＳデコーダＡ５０５ａは与えられたパケットＩＤと出力先に基づいて、フィルタリングを行う。ここではパケットＩＤ「５０１１」のパケットをオーディオデコーダＡ５０６ａに、パケットＩＤ「５０１２」のパケットをビデオデコーダＡ５０８ａに引き渡す。オーディオデコーダＡ５０６ａは、与えられたパケットのデジタル−アナログ変換を行いスピーカ５０７を通して音声を再生する。ビデオデコーダＡ５０８ａは、与えられたパケットのデジタル−アナログ変換を行い表示デバイスＡ５２０ａに出力し、合成してディスプレイ５０９に映像を表示する。

最後にＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６のサービス実行部２２０１は、Ｊａｖａライブラリ１７０５の中にあるＡＭ１７０５ｂにサービス識別子を与え、データ放送再生を依頼する。ここで、データ放送再生とは、ＭＰＥＧ２トランスポートストリームに含まれるＪａｖａプログラムを抽出し、ＪａｖａＶＭ１７０３に実行させることである。ＭＰＥＧ２トランスポートストリームにＪａｖａプログラムを埋め込む方法は、ＭＰＥＧ規格書 ＩＳＯ／ＩＥＣ１３８１８１−６に記述されたＤＳＭＣＣという方式を用いる。ここではＤＳＭＣＣの詳細な説明は省略する。ＤＳＭＣＣ方式は、ＭＰＥＧ２トランスポートストリームのパケットの中に、コンピュータで使用されているディレクトリやファイルで構成されるファイルシステムをエンコードする方法を規定している。また、実行するＪａｖａプログラムの情報はＡＩＴと呼ばれる形式で、ＭＰＥＧ２トランスポートストリームのパケットの中に埋め込まれ送信されている。ＡＩＴは、ＤＶＢ−ＭＨＰ規格（正式には、ＥＴＳＩ ＴＳ １０１ ８１２ ＤＶＢ−ＭＨＰ仕様Ｖ１．０．２）の１０章に定義されている、Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅの略である。

ＡＭ１７０５ｂは、利用するＴＳデコーダＡ５０５ａを呼び出し元のＪａｖａプログラムをスレッドによって判断し、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６を取得することによって特定する。まず、ＡＩＴを獲得するため、ＪＭＦ１７０５ａ同様ＰＡＴ、ＰＭＴを取得し、ＡＩＴが格納されているパケットのパケットＩＤを獲得する。今、与えられたサービス識別子が「２」で、図２９のＰＡＴ、図３０のＰＭＴが送信されていると、ＪＭＦ１７０５ａと同様の手順で、図３０のＰＭＴを獲得する。ＡＭ１７０５ｂは、ＰＭＴからストリーム種別が「データ」で補足情報として「ＡＩＴ」を持つエレメンタリ−ストリームからパケットＩＤを抽出する。図３０を参照して、行３０１３のエレメンタリ−ストリームが該当し、パケットＩＤ「５０１３」を獲得する。

ＡＭ１７０５ｂは、ＯＳ１７０１のライブラリ１７０１ｂを通してＴＳデコーダＡ５０５ａにＡＩＴのパケットＩＤと、出力先として１次記憶部５１１を与える。ＴＳデコーダＡ５０５ａは、与えられたパケットＩＤでフィルタリングを行い、DSMCC形式のデータを１次記憶部５１１に格納する。この結果、ＡＭ１７０５ｂは、ＡＩＴのパケットを収集することができる。図３１は、収集したＡＩＴの情報の一例を模式的に表した表である。列３１０１はＪａｖａプログラムの識別子である。列３１０２はＪａｖａプログラムの制御情報である。制御情報には「ａｕｔｏｓｔａｒｔ」「ｐｒｅｓｅｎｔ」「ｋｉｌｌ」などがあり、「ａｕｔｏｓｔａｒｔ」は即時に端末装置５００がこのプログラムを自動的に実行することを意味し、「ｐｒｅｓｅｎｔ」は自動実行しないことを意味し、「ｋｉｌｌ」はプログラムを停止することを意味する。列３１０３は、ＤＳＭＣＣ方式でＪａｖａプログラムを含んでいるパケットＩＤを抽出するためのＤＳＭＣＣ識別子である。列３１０４はＪａｖａプログラムのプログラム名である。行３１１１と３１１２は、Ｊａｖａプログラムの情報の組である。行３１１１で定義されるＪａｖａプログラムは、識別子「３０１」、制御情報「ａｕｔｏｓｔａｒｔ」、ＤＳＭＣＣ識別子「１」、プログラム名「ａ／ＴｏｐＸｌｅｔ」の組である。行３１１２で定義されるＪａｖａプログラムは、識別子「３０２」、制御情報「ｐｒｅｓｅｎｔ」、ＤＳＭＣＣ識別子「１」、プログラム名「ｂ／ＧａｍｅＸｌｅｔ」の組である。ここで２つのＪａｖａプログラムは同じＤＳＭＣＣ識別子を持つが、これは１つのＤＳＭＣＣ方式でエンコードされたファイルシステム内に２つのＪａｖａプログラムが含まれていることを表す。ここでは、Ｊａｖａプログラムに対して４つの情報しか規定しないが、実際にはより多くの情報が定義される。詳細はＤＶＢ−ＭＨＰ規格を参照されたい。

ＡＭ１７０５ｂは、ＡＩＴの中から「ａｕｔｏｓｔａｒｔ」のＪａｖａプログラムを見つけ出し、対応するＤＳＭＣＣ識別子及びＪａｖａプログラム名を抽出する。図３１を参照して、ＡＭ１７０５ｂは行３１１１のＪａｖａプログラムを抽出し、ＤＳＭＣＣ識別子「１」及びＪａｖａプログラム名「ａ／ＴｏｐＸｌｅｔ」を獲得する。

次にＡＭ１７０５ｂは、ＡＩＴから取得したＤＳＭＣＣ識別子を用いて、ＪａｖａプログラムをＤＳＭＣＣ方式で格納しているパケットのパケットＩＤをＰＭＴから獲得する。具体的には、ＰＭＴの中でストリーム種別が「データ」で、補足情報のＤＳＭＣＣ識別子が合致するエレメンタリ−ストリームのパケットＩＤを取得する。

今、ＤＳＭＣＣ識別子が「１」であり、ＰＭＴが図３０とすると、行３０１４のエレメンタリ−ストリームが合致し、パケットＩＤ「５０１４」を取り出す。
ＡＭ１７０５ｂは、ＯＳ１７０１のライブラリ１７０１ｂを通してＴＳデコーダＡ５０５ａにＤＳＭＣＣ方式でデータが埋めこめられたパケットのパケットＩＤと出力先として１次記憶部５１１を指定する。ここでは、パケットＩＤ「５０１４」を与える。ＴＳデコーダＡ５０５ａは、与えられたパケットＩＤでフィルタリングを行い、ＡＩＴを１次記憶部５１１に格納する。この結果、ＡＭ１７０５ｂは、必要なパケットを収集することができる。ＡＭ１７０５ｂは、収集したパケットから、ＤＳＭＣＣ方式に従ってファイルシステムを復元し、１次記憶部５１１に保存する。ＭＰＥＧ２トランスポート中のパケットからファイルシステム等のデータを取り出し１次記憶部５１１等の記憶手段に保存すことを以降、ダウンロードと呼ぶ。

図３２は、ダウンロードしたファイルシステムの一例である。図中、丸はディレクトリを四角はファイルを表し、３２０１はルートディレクトリ、３２０２はディレクトリ「ａ」，３２０３はディレクトリ「ｂ」，３２０４はファイル「ＴｏｐＸｌｅｔ．ｃｌａｓｓ」、３２０５はファイル「ＧａｍｅＸｌｅｔ．ｃｌａｓｓ」である。

次にＡＭ１７０５ｂは、１次記憶部５１１にダウンロードしたファイルシステム中から実行するＪａｖａプログラムをＪａｖａＶＭ１７０３に引き渡す。今、実行するＪａｖａプログラム名が「ａ／ＴｏｐＸｌｅｔ」とすると、Ｊａｖａプログラム名の最後に「．ｃｌａｓｓ」を付加したファイル「ａ／ＴｏｐＸｌｅｔ．ｃｌａｓｓ」が実行すべきファイルとなる。「／」はディレクトリやファイル名の区切りであり、図３２を参照して、ファイル３２０４が実行すべきＪａｖａプログラムである。次にＡＭ１７０５ｂは、ファイル３２０４をＪａｖａＶＭ１７０３に引き渡す。

ＪａｖａＶＭ１７０３は、引き渡されたＪａｖａプログラムを実行する。図３３はサービス識別子「２」によって示されるＩｎ−ｂａｎｄのサービスを実行している例を示す。５０９はディスプレイを表し、６０３、６０６は図６のとおりである。３３０１はサービス識別子「２」で示されるＩｎ−ｂａｎｄのサービスを表し、３３０２は、実行されたＪａｖａプログラムによって表示されたアイコンを示す。例えば、フロントパネルの「ＯＫ」ボタン１４０５をユーザーが押下することによって、図３４のように全画面に総合情報プログラム３４０１を表示することもできる。

次にユーザーがフロントパネル１４００の「２画面」ボタン１４０８を押下すると、２つのサービスが表示される。例えば、サービス再生部１７０２はＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＢ２１０７のサービス実行部２２０１にサービス識別子「１」を渡す。

この場合、図５のチューナーＢ５０１ｂ、ＴＳデコーダＢ５０５ｂ、オーディオデコーダＢ５０６ｂ、ビデオデコーダＢ５０８ｂを用いて同様にサービスＢ２６０２を実行する。図３５は２つのサービスが表示される例を示す。図３５において、３５０１はサービス識別子「１」によって表されるＩｎ−ｂａｎｄのサービスを表す。その他の構成要素は、図３３に示してあるので、説明は省略する。３５０２はカーソルを表し、入力部がフロントパネル１４００である場合、「画面選択」ボタン１４０９を押下することによって図３６で示されるようにカーソル３５０２が移動する。また、カーソル３５０２は、一定時間経過すると、自動的に消える。

図３６では、カーソル３５０２はサービス識別子「２」によって表されるＩｎ−ｂａｎｄのサービスをさしている。このとき、ユーザーが例えば下カーソルボタン１４０２を押下すると、サービス識別子「２」で表されるＩｎ−ｂａｎｄのサービスを実行しているＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２００２のサービス実行部２２０１は他のサービス識別子、例えばサービス識別子「３」を受け取り、Ｊａｖａライブラリ１７０５に含まれる各ライブラリを通してＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２００２で実行させているＩｎ−ｂａｎｄのサービスＡ２６０１に含まれる再生している映像・音声及びＪａｖａプログラムの実行を、同じくＪａｖａライブラリ１７０５に含まれる各ライブラリを通して停止し、新たに受け取ったサービス識別子「３」に基づいて、新たなＩｎ−ｂａｎｄのサービスに含まれる映像・音声の再生及びＪａｖａプログラムの実行を行う。その際、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＢ２４０３の上で実行しているＩｎ−ｂａｎｄのサービスＢ２６０２は停止されず、実行したままである。図３７はサービス識別子「３」とサービス識別子「１」を同時に表示している一例である。３７０１はサービス識別子「３」によって表されるＩｎ−ｂａｎｄのサービスである。 Ｊａｖａライブラリ１７０５は、ＲＯＭ５１２に格納されている複数のＪａｖａライブラリの集合である。本実施の形態では、ここでは、Ｊａｖａライブラリ１７０５は、ＪＭＦ１７０５ａ，ＡＭ１７０５ｂ，Ｔｕｎｅｒ１７０５ｃ，ＣＡ１７０５ｄ、ＰＯＤ Ｌｉｂ１７０５ｅ等を含んでいる。

なお本実施の形態では、ＲＯＭ５１２が保存する内容を２次記憶部５１０が保存することで、ＲＯＭ５１２を削除することも実施可能である。また、２次記憶部５１０は、複数のサブ２次記憶部で構成し、個々のサブ２次記憶部が異なる情報を保存しても実施可能である。例えば、１つのサブ２次記憶部は、チューニング情報のみ保存し、別のサブ２次記憶部は、ＯＳ１２０１のライブラリ１２０１ｂを保存し、更に別の２次記憶部は、ダウンロードしたＪａｖａプログラムを保存するなど、詳細に分割することが可能である。

Ａｂｓｔｒａｃｔサービスとは、１つまたは複数のＪａｖａのプログラムで構成されている。Ａｂｓｔｒａｃｔサービスは、チューニングには依存せず、例えば、ＥＰＧなどが実現できる。ＥＰＧはＥｌｅｃｔｒｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅの略である。ＥＰＧについては後述する。

Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔは、Ａｂｓｔｒａｃｔサービスを実行する。

図３９はＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを示したものである。Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８はサービス実行部３９０１とＳｅｒｖｉｃｅＣｏｎｔｅｘｔ設定部３９０２、およびＳｅｒｖｉｃｅＣｏｎｔｅｘｔ保持部３９０３からなる。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ設定部３９０２は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔと、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを関連付け、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ保持部３９０３に保持させることにより、サービス実行部３９０１においてサービスを実行する際、利用するリソースの組を特定する。

サービスマネージャ１７０４のＸＡＩＴ情報取得部２００３は、Ｊａｖａライブラリ１７０５に含まれるＰＯＤ Ｌｉｂ１７０５ｅを通してヘッドエンド１０１と双方向通信を行う。この双方向通信は、ＰＯＤ Ｌｉｂ１７０５ｅはＯＳ１７０１のライブラリ１７０１ｂ及び、ＰＯＤ５０４を介して、ＱＰＳＫ復調部５０２、ＱＰＳＫ変調部５０３を使用して実現される。

サービスマネージャ１７０４のＸＡＩＴ情報取得部２００３は、この通信を用いてヘッドエンド１０１から、端末装置５００が２次記憶部５１０に保存すべきＪａｖａプログラムの情報を受け取る。この情報をＸＡＩＴ情報と呼ぶ。ＸＡＩＴ情報は、ヘッドエンド１０１とＰＯＤ５０４間で、任意の形式で送信される。どのような送信形式を採用しても、ＸＡＩＴに必要とする情報が含まれていれば、本発明は実施可能である。

図４１は、ヘッドエンド１０１から取得したＸＡＩＴの情報の一例を模式的に表した表である。列４１０１はＡｂｓｔｒａｃｔサービスの識別子である。このＡｂｓｔｒａｃｔサービスの識別子はまた、それぞれ１つのＡｂｓｔｒａｃｔサービスに対応している。列４１０２はＡｂｓｔｒａｃｔサービスの制御情報である。制御情報には「ｔｒｕｅ」、「ｆａｌｓｅ」などがあり、「ｔｒｕｅ」は端末装置５００が電源投入時にこのプログラムを自動的に実行することを意味し、「ｆａｌｓｅ」は自動実行しないことを意味する。列４１０３は、ＤＳＭＣＣ方式でＪａｖａプログラムを含んでいるパケットＩＤを抽出するためのＤＳＭＣＣ識別子である。列４１０４はＪａｖａプログラムのプログラム名である。列４１０５は、Ｊａｖａプログラムの優先度である。列４１０６はＪａｖａプログラムの制御情報であり、サービスが実行したとき、「ａｕｔｏｓｔａｒｔ」ならば実行する。列４１０７はＪａｖａプログラムの識別子である。行４１１１、４１１２および４１１３は、Ｊａｖａプログラムの情報の組である。行４１１１で定義されるＪａｖａプログラムは、識別子「７０１」、サービス制御情報「ｔｒｕｅ」、Ｊａｖａプログラム識別子「７０１１」ＤＳＭＣＣ識別子「１」、プログラム名「ａ／ＥＰＧＸｌｅｔ」、Ｊａｖａプログラムの優先度「２００」、Ｊａｖａプログラムの制御情報「ａｕｔｏｓｔａｒｔ」の組である。ここでは、Ｊａｖａプログラムに対して７つの情報を規定しているが、より多くのあるいは少ない情報が定義されていても本発明は実施可能である。

サービスマネージャ１７０４はＸＡＩＴ情報取得部２００３によってＸＡＩＴ情報を受け取ると、ＡＩＴ情報からＪａｖａプログラムをダウンロードした手順と同じ手順で、ＭＰＥＧ２トランスポートストリームからファイルシステムをＸＡＩＴ情報保存部２００４によって１次記憶部５１１に保存する。その後、保存したファイルシステムを２次記憶部５１０に複写する。なお、１次記憶部５１１を介さず、直接２次記憶部５１０にダウンロードすることも実施可能である。

なお、本実施の形態では、２次記憶部５１０に複写するが、１次記憶部５１１に保存することも可能である。ただし、１次記憶部５１１に保存する場合、電源ＯＦＦ時に保存された情報は全て消える。

次に、サービスマネージャ１７０４のＸＡＩＴ情報保存部２００４は、ＸＡＩＴ情報にダウンロードしたファイルシステムの格納位置を対応つけて２次記憶部５１０に保存する。図４２は、２次記憶部５１０がＸＡＩＴ情報とダウンロードしたファイルシステムが対応つけられて保存されている一例を表す。図４２の中で、図４１と同じ番号の要素は図４１と同じなので、説明は省略する。列４４１１は対応するダウンロードしたファイルシステムの保存位置を格納する。図中、保存位置は矢印で示している。４２１０はダウンロードしたファイルシステムであり、内部にトップディレクトリ４２１１、ディレクトリ「ａ」４２１２、ディレクトリ「ｂ」４２１３、ファイル「ＥＰＧＸｌｅｔ．ｃｌａｓｓ」４２１４、ファイル「ＴＯＰＸｌｅｔ．ｃｌａｓｓ」４２１５、ファイル「ＰＰＶＸｌｅｔ．ｃｌａｓｓ」４２１６、を保持する。

ここで、Ｊａｖａプログラムを保存してから、ＸＡＩＴ情報を保存しているが、Ｊａｖａプログラムを保存する前に保存することも実施可能である。制御情報「ｔｒｕｅ」であるＡｂｓｔｒａｃｔサービスの識別子が示すＡｂｓｔｒａｃｔサービスは、端末装置５００によって自動的に動作させられる。

サービスマネージャ１７０４をＪａｖａＶＭ１７０３に指定し、ＪａｖａＶＭ１７０３がサービスマネージャ１７０４を起動した後、サービス再生部１７０２はＸＡＩＴ情報取得部２００３よりＸＡＩＴ情報保持部２００４から各Ａｂｓｔｒａｃｔサービスの制御情報を参照し「ｔｒｕｅ」であるＡｂｓｔｒａｃｔサービスを取得し、またＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部２００２からＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８を取得し、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８のサービス実行部２２０１によって実行する。

本実施の形態では、Ａｂｓｔｒａｃｔサービスに含まれるＪａｖａプログラムとして、ＥＰＧが実行している場合を考える。

図８１はＥＰＧの構成例を表す。ＥＰＧ８１０１はユーザーに番組一覧を表示及び、ユーザーからの入力を受け付ける番組表示部８１０２と、サービス選局を行う番組再生部８１０３で構成される。ユーザーが電源を投入した際には、ディスプレイ５０９は最後に実行していたサービスを表示しており、ＥＰＧ８１０１を表すＪａｖａのプログラムは、実行中ではあるが、画面には表示されない。入力部５１３が図１４で示されるフロントパネルで構成されている場合、ユーザーが、入力部５１３のＥＰＧボタン１４０７を押下することによってはじめてディスプレイ５０９に表示される。

本実施の形態では、ディスプレイ５０９が図３７に示すような表示のときに、ユーザーが、入力部５１３のＥＰＧボタン１４０７を押下した場合を考える。ユーザーが、入力部５１３のＥＰＧボタン１４０７を押下するとＥＰＧ８１０１の番組表示部８１０２は、この識別子を受け取り、番組情報をディスプレイ５０９に表示する。図３８はＥＰＧボタン１４０７が押下されたときのディスプレイ５０９を示す。３８０１はＥＰＧを表す。図４０Ａ及び図４０Ｂは、ディスプレイ５０９に表示されたＥＰＧ３８０１の一例である。図４０Ａを参照して、ディスプレイ５０９には、格子状に番組情報が表示されている。列４００１には、時刻情報が表示されている。列４００２には、サービス名「チャンネル１」と、列４００１の時刻に対応する時間帯に放映される番組が表示されている。「チャンネル１」では、９：００〜１０：３０に番組「ニュース９」が放映され、１０：３０〜１２：００は「映画ＡＡＡ」が放映されることを表す。列４００３も列４００２同様、サービス名「チャンネル２」と、列４００１の時刻に対応する時間帯に放映される番組が表示されている。９：００〜１１：００に番組「映画ＢＢＢ」が放映され、１１：００〜１２：００は「ニュース１１」が放映される。４０３０は、カーソルである。カーソル４０３０は、フロントパネル１４００の左カーソル１４０３と右カーソル１４０４を押下すると移動する。図４０Ａの状態で、右カーソル１４０４を押下すると、カーソル４０３０は右に移動し、図４０Ｂのようになる。また、図４０Ｂの状態で、左カーソル１４０３を押下すると、カーソル４０３０は左に移動し、図４０Ａのようになる。

図４０Ａの状態で、フロントパネル１４００のＯＫボタン１４０５が押下されると、番組表示部８１０２は、「チャンネル１」の識別子を再生部８１０３に通知する。図４０Ｂの状態で、フロントパネル１４００のＯＫボタン１４０５が押下されると、番組表示部１７０２ａは、「チャンネル２」の識別子を再生部１４０２ｂに通知する。

また、番組表示部８１０２は、表示する番組情報を、ＰＯＤ５０４を通してヘッドエンド１０１から定期的に、１次記憶部５１１に記憶しておく。一般的に、ヘッドエンドからの番組情報の取得は時間が掛かる。入力部５１３のＥＰＧボタン１４０７が押下された時、１次記憶部５１１に予め保存された番組情報を表示することで、素早く番組表を表示することができる。

図４０Ａ及び図４０Ｂにおいて４０１０、４０１１は、カーソルがあるサービスの映像、音声を再生したものである。Ａｂｓｔｒａｃｔサービスに含まれるＪａｖａプログラムは、映像・音声を再生するとき、プログラムＪＭＦ１７０５ａを用いて再生したい映像・音声の識別子を指定し、オーディオデコーダＡ５０６ａあるいはオーディオデコーダＢ５０６ｂ、ビデオデコーダＡ５０８ａあるいはビデオデコーダＢ５０８ｂを用いて再生される。

本実施の形態では、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ上で動作するＡｂｓｔｒａｃｔサービスに含まれるＪａｖａプログラムがどのリソースの組を用いて映像・音声を再生するかを指定するために、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６、あるいはＢ２１０７と関連付ける。

図３９にＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを示す。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ設定部３９０２はＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡを関連付ける。ＪａｖａプログラムがＳｅｒｖｉｃｅＣｏｎｔｅｘｔ設定部３９０２にＩｎ−ｂａｎｄのＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６を指定することによって、使用するリソースの組をリソースの組Ａ２４１０に特定することができる。

図４３はＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡを関連付けた図である。２１０８はＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを表し、ＡｂｓｔｒａｃｔサービスＥ４３０１はその上で動作する。その他の要素は図２６と同じなので、説明は省略する。図４３では、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８をＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６と関連付けることにより、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６が特定するリソースの組を指定できる。

図４４はＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを関連付けるための方法の一例である。
図４４においてＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔはＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス４４０２として定義する。ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス４４０２はＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔのＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス４４０１を継承する。図３９に示されるサービス実行部２２０１はＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス４４０１と同一のものである。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ設定部３９０２はメソッドを定義する。図４４では例としてｓｅｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ（ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）メソッド４４１０が定義されている。このメソッドの引数に関連付けたいＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを指定することによってＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔが保持するリソースの組を特定できる。

本実施の形態ではＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔはｓｅｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ（ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）の引数に２つのＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔのうちどちらかのＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを指定することによりリソースの組を特定でき、例えば図３７で表示している２つのＩｎ−ｂａｎｄのサービス３７０１、３５０１のどちらにＡｂｓｔｒａｃｔサービスを表示するかを指定することができる。

図４５はＡｂｓｔｒａｃｔサービスに含まれるＪａｖａプログラムが映像・音声を再生するときのフローチャートである。
本実施の形態では、図３８で示すようにＥＰＧを表すＪａｖａプログラムはＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡのリソースを用いる例を示す。ＪａｖａプログラムはＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを、サービスマネージャ１７０４のＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部から取得する（ステップＳ４５０１）。次にＪａｖａプログラムはＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８とＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６をｓｅｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ（ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）４４１０を用いて関連付ける。引数のＳｅｒｖｉｃｅＣｏｎｔｅｘｔは、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８のＳｅｒｖｉｃｅＣｏｎｔｅｘｔ保持部３９０３に保持される（ステップＳ４５０２）。ＪａｖａプログラムはＪＭＦ１７０５ａにリソースの組を表すＪａｖａのクラスのインスタンス（リソース組情報）を取得させ、そのインスタンスを用いて映像・音声の再生を要求する（ステップＳ４５０３）。ＪＭＦ１７０５ａは指定されたインスタンスが用いるリソースの組２４１０によって指定された映像・音声を再生する（ステップＳ４５０４）。ここで、ステップＳ４５０３の詳細は図２８に示したとおりである。

また、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔに含まれるＪａｖａプログラムが２つの映像・音声を同時に再生したい場合、図４６の手順によって映像・音声を同時に再生することも可能である。

まず、ＪａｖａプログラムはＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを、サービスマネージャ１７０４のＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部から取得する（ステップＳ４６０１）。次にＪａｖａプログラムはＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８とＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６をｓｅｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ（ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ）４４１０を用いて関連付ける（ステップＳ４６０２）。ＪａｖａプログラムはＪＭＦ１７０５ａにリソースの組を表すＪａｖａのクラスのインスタンスを取得させ、そのインスタンスを用いて映像・音声を指定することで、その映像・音声の再生を要求する（ステップＳ４６０３）。ＪＭＦ１７０５ａはそのインスタンスが特定するリソースの組Ａ２４１０によって指定された映像・音声を再生する（ステップＳ４６０４）。次にＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔをＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＢ２１０７とＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔのメソッドｓｅｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ（ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＢ）４４１０を用いて関連付ける（ステップＳ４６０５）。ＪａｖａプログラムはＪＭＦ１７０５ａにリソースの組を表すＪａｖａのクラスのインスタンスを取得させ、そのインスタンスを用いて映像・音声を指定することで、その映像・音声の再生を要求する（ステップＳ４６０６）。ＪＭＦ１７０５ａはそのインスタンスが特定するリソースの組Ａ２４１０を用いて指定された映像・音声を再生する（ステップＳ４６０７）。このように本実施の形態は、複数のリソースの組を操作することもまた可能である。 なお、本実施の形態では、明示的にＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔと関連付けたが、デフォルトで、あるＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔと関連付けておくことも可能である。

なお、本実施例では、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔと関連付けられるＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの例を示したが、他のＳｅｒｖｉｃｅＣｏｎｔｅｘｔと関連付けることができないＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔがあってもよい。

なお、本実施の形態では、ＰＯＤ５０４は着脱可能な形態としているが、内蔵していても実施可能である。なお、内蔵した場合、ＰＯＤ５０４のＣＰＵ７０６を取り外し、ＣＰＵ５１４がＣＰＵ７０６の動作も行うことも実施可能である。

ＰＯＤ Ｌｉｂ１７０５ｅに登録されるＪａｖａプログラムは、ダウンロードされたＪａｖａプログラムだけでなく、あらかじめ内蔵されているＪａｖａプログラムでも実施可能である。また、ＳＤメモリーカードなどの着脱可能な記憶媒体を着脱すると、スロット部を取り付け、そこからＪａｖａプログラムを取り込むことも可能である。また、ネットワークに接続するネットワーク部を取り付け、インターネットからＪａｖａプログラムを取り出すことも可能である。

（実施の形態２）
本実施の形態は実施の形態１において定義された、図３９のＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとは異なる構成のＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを定義する。それ以外の部分は、実施の形態１と同じなので、本実施の形態では、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの構成、特にＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＩｎ−ｂａｎｄのサービス用ＳｅｒｖｃｅＣｏｎｔｅｘｔの関連付け方に絞って説明を行う。

本実施の形態におけるＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを、図４７に示す。構成要素は、サービス実行部４７０１とＳｅｒｖｉｃｅＣｏｎｔｅｘｔ保持部３９０３からなる。サービス実行部４７０１は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８のサービス実行部４７０１においてサービス識別子を受け取るとき同時にＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを受け取ることで、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを関連付ける。受け取ったＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔはＳｅｒｖｉｃｅＣｏｎｔｅｘｔ保持部３９０３に保持される。図４９は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを関連付けるための方法の一例である。図４９において、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ４４０１は図４４に定義してある。ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス４９０２はＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス４４０１を継承する。サービス実行部４７０１は新たにサービスを実行するメソッドｓｅｌｅｃｔ（Ｓｅｒｖｉｃｅ、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）４９１１を持つ。このメソッドによって、引数に指定されたＡｂｓｔｒａｃｔサービスを実行すると同時に、引数に指定されたＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔをＳｅｒｖｉｃｅＣｏｎｔｅｘｔ保持部３９０３に保存し、関連付けられる。これによってＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ上で指定されたＡｂｓｔｒａｃｔサービスを実行する際、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔが特定するリソースの組を用いる。また、Ａｂｓｔｒａｃｔサービスに含まれるＪａｖａプログラムが何らかのリソースを必要としたとき（例えば映像・音声の再生）、ｓｅｌｅｃｔメソッドの引数に指定されたＳｅｒｖｉｃｅＣｏｎｔｅｘｔが特定するリソースを用いる。

本実施の形態のフローチャートを図５０に示す。サービス再生部１７０２はＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを、サービスマネージャ１７０４のＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部２００２から取得する（ステップＳ５００１）。サービス再生部１７０２はＡｂｓｔｒａｃｔサービスを実行する際、ＡｂｓｔｒａｃｔＳｅｒｖｃｅＣｏｎｔｅｘｔのｓｅｌｅｃｔ（Ｓｅｒｖｉｃｅ、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）メソッド４９１１にＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを指定することにより、サービス実行部４７０１は引数に指定されたＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔをＳｅｒｖｉｃｅＣｏｎｔｅｘｔ保持部３９０３に格納する（ステップＳ５００２）。ＪａｖａプログラムはＪＭＦ１７０５ａにリソースの組を表すＪａｖａのクラスのインスタンスを取得させ、そのインスタンスを用いて映像・音声を指定することで、その映像・音声の再生を要求する（ステップＳ５００３）。ＪＭＦ１７０５ａはステップＳ５００３で取得したインスタンスが特定するリソースの組Ａ２４１０、あるいはリソースの組Ｂ２４１１を用いて指定された映像・音声を再生する（ステップＳ５００４）。ここで、ステップＳ５００３の詳細は図２８に示したとおりである。

（実施の形態３）
本実施の形態は実施の形態１とは、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８とＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの関連付け方が異なる。それ以外の部分は、実施の形態１と同じなので、本実施の形態では、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＩｎ−ｂａｎｄのサービス用ＳｅｒｖｃｅＣｏｎｔｅｘｔの関連付け方に絞って説明を行う。

本実施の形態におけるサービスマネージャ１７０４の構成を図５１に示す。本実施の形態では、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの関連付けをサービスマネージャ１７０４のＳｅｒｖｉｃｅＣｏｎｔｅｘｔマッピング部５１０１によって実現する。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔマッピング部５１０１は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの関連を保持する。図５２はＳｅｒｖｉｃｅＣｏｎｔｅｘｔマッピング部５１０１の構成を示したものである。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔマッピング部５１０１はＳｅｒｖｉｃｅＣｏｎｔｅｘｔマッピング保持部５２０１、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部５２０２、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔのマッピング実現部５２０３からなる。図５３はＳｅｒｖｉｃｅＣｏｎｔｅｘｔマッピング保持部５２０１の一例を示す。図５３において列５３０３はＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、列５３０４はＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを示す。行５３０１，５３０２では同一の行にあるＩｎ−ｂａｎｄのサービス用とＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔがそれぞれ関連付けられている。同一の行であれば、同じリソースの組を用いる。

なお、図５３では１つのＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔに対して多くて１つのＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔが関連付けられているが、複数のＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔが同一のＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔに関連付けても本実施の形態は適用できる。

Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部５２０２は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔが関連付けられているＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔをＳｅｒｖｉｃｅＣｏｎｔｅｘｔマッピング保持部５２０３から取得し、返す。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔのマッピング実現部５２０３は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを関連付ける。図４８は、本実施の形態におけるＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを示したものである。Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔは、サービス実行部４８０１からなる。サービス実行部４８０１はサービス識別子を渡されると、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔマッピング部５１０１のＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを取得し、リソースの組を特定してサービスを実行する。

図５４は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを関連付けるための方法の一例である。図５４において、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔマッピング部はＳｅｒｖｉｃｅＣｏｎｔｅｘｔＭａｐクラス５４０１として表される。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔマッピング実現部５２０３を実現するために、ｖｏｉｄ ｓｅｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ（ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）５４１３を定義する。ｇｅｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ（ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）５４１２は引数のＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラスが現在関連付けられているＳｅｒｖｉｃｅＣｏｎｔｅｘｔをＳｅｒｖｉｃｅＣｏｎｔｅｘｔマッピング保持部５２０１を表現するｓｅｒｖｉｃｅＣｏｎｔｅｘｔＭａｐ５４１１から取得する。ｓｅｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ（ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）５４１３は引数の２つのＳｅｒｖｉｃｅＣｏｎｔｅｘｔを関連付け、ｓｅｒｖｉｃｅＣｏｎｔｅｘｔＭａｐに保存する。また、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部５２０２を実現するメソッドとして、ｓｅｒｖｉｃｅＣｏｎｔｅｘｔＭａｐ５４１１からＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを取得するＳｅｒｖｉｃｅＣｏｎｔｅｘｔ ｇｅｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ（ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）５４１２を定義する。

図５５は本実施の形態のフローチャートを示す。
Ａｂｓｔｒａｃｔサービスに含まれるＪａｖａプログラムはＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを、サービスマネージャ１７０４のＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部２００２から取得する（ステップＳ５５０１）。次にＪａｖａプログラムはＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８とＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ０１０６をｓｅｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ（ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅ、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）５４１３を用いて関連付ける（ステップＳ５５０２）。ＪａｖａプログラムはＪＭＦ１７０５ａにリソースの組を表すＪａｖａのクラスのインスタンスを取得させ、そのインスタンスを用いて映像・音声を指定することで、その映像・音声の再生を要求する（ステップＳ５５０３）。ＪＭＦ１７０５ａはステップＳ５５０３で取得したインスタンスが特定するリソースの組Ａ２４１０、あるいはリソースの組Ｂ２４１１を用いて指定された映像・音声を再生する（ステップＳ５５０４）。

（実施の形態４）
実施の形態１〜実施の形態３では、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを関連付けることによって、リソースの組を特定した。本実施の形態では、実施の形態１〜実施の形態３と異なり、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔに直接リソースの組を特定することにより実現する。それ以外の部分は、実施の形態１と同じなので、本実施の形態では、リソースの組とＡｂｓｔｒａｃｔサービス用ＳｅｒｖｃｉｃｅＣｏｎｔｅｘｔのマッピングの仕方に絞って説明を行う。本実施の形態におけるＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの構成を図２２に示す。また、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの構成を図５６に示す。Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔはサービス実行部５６１１、リソースの組指定部５６０１、リソースの組保持部５６０２からなる。図５６において、サービス実行部５６１１はサービス識別子を渡されると、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔのリソースの組取得部２２０３からリソースの組を取得し、リソースの組を特定しサービスを実行する。リソースの組指定部５６０１はリソースの組取得部２２０３で取得したリソースの組を指定することにより、そのリソースの組と関連付けられる。リソースの組指定部５６０１により指定されたリソースの組は、リソースの組保持部５６０２に保持される。図５８は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースの組を関連付けるための方法の一例である。図５８において、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔはリソースの組取得部２２０３として新たにｇｅｔＲｅｓｏｕｒｃｅＳｅｔ（）４４１１を定義する。このメソッドによって関連付けられているリソースの組を取得できる。ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス４４０２はＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラスを継承し、リソースの組指定部５６０１は新たにメソッドを定義する。図５８では例としてｓｅｔＲｅｓｏｕｒｃｅＳｅｔ（ＲｅｓｏｕｒｃｅＳｅｔ）４４１２というメソッドが定義されている。ここで引数のＲｅｓｏｕｒｃｅＳｅｔ５８０１はリソースの組を表すクラスである。このメソッドの引数に関連付けたいリソースの組を指定することによってリソースの組を特定できる。

図６０は本実施の形態のフローチャートを示す。
Ａｂｓｔｒａｃｔサービスに含まれるＪａｖａプログラムはＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを、サービスマネージャ１７０４のＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部から取得する（ステップＳ６００１）。次にＪａｖａプログラムは取得したＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔからｇｅｔＲｅｓｏｕｒｃｅＳｅｔ（）によってＲｅｓｏｕｒｃｅＳｅｔを取得する（ステップＳ６００２）。Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８とＲｅｓｏｕｒｃｅＳｅｔ５８０１をｓｅｔＲｅｓｏｕｒｃｅＳｅｔ（ＲｅｓｏｕｒｃｅＳｅｔ）を用いて関連付ける（ステップＳ６００３）。ＪａｖａプログラムはＪＭＦ１７０５ａにリソースの組を表すＪａｖａのクラスのインスタンスを取得させ、そのインスタンスを用いて映像・音声を指定することで、その映像・音声の再生を要求する（ステップＳ６００４）。ＪＭＦ１７０５ａはステップＳ６００３で取得したインスタンスが特定するリソースの組Ａ２４１０、あるいはリソースの組Ｂ２４１１を用いて指定された映像・音声を再生する（ステップＳ６００５）。

ここで、ステップＳ６００４の詳細なフローチャートを図５９に示す。まず、サービス実行部５６１１はＪＭＦ１７０５ａにおいて映像・音声を再生するためのリソース（ＴＳデコーダＡ５０５ａ、オーディオデコーダ５０６ａ、ビデオデコーダ５０８ａ）を表すＪａｖａのクラスのインスタンスの取得要求する（ステップＳ５９０１）。ＪＭＦ１７０５ａは映像・音声を再生するためのリソースのＪａｖａのクラスのインスタンスを要求した呼び出し元を例えばスレッドによって判断する（ステップＳ５９０２)。ここで、スレッドは、そのスレッドが属する組によってＪａｖａプログラムを識別することができ、そこから、サービスを特定し、サービスマネージャ１７０４に問い合わせることによってＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６を取得し、ＲｅｓｏｕｒｃｅＳｅｔ及びリソースの組を取得することができる（ステップＳ５９０３）。ＪＭＦ１７０５ａはステップＳ５９０３において取得したリソースの組２４１０に含まれる映像・音声を再生するためのリソースの組を表現するＪａｖａのクラスのインスタンスを返す（ステップＳ５９０４）。サービス実行部２２０１はステップＳ５９０４で取得したインスタンスを用いてＪＭＦ１７０５ａに映像・音声の再生要求を行う（ステップＳ５９０５）。即ち、ＪＭＦ１７０５ａは、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔＡ２１０６に関連付けられたリソースの組（リソース組情報を含む情報）を取得し、取得した前記リソース組情報をサービスに供給するリソース管理手段として機能する。

（実施の形態５）
本実施の形態は、実施の形態１〜実施の形態３と異なり、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔに直接リソースの組を特定することにより使用するリソースを特定する。それ以外の部分は、実施の形態１と同じなので、本実施の形態では、リソースの組とＡｂｓｔｒａｃｔサービス用ＳｅｒｖｃｉｃｅＣｏｎｔｅｘｔのマッピングの仕方に絞って説明を行う。

本実施の形態におけるＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの構成は、図２２に示されるので、その説明は省略する。
図５７はＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ（サービス実行環境）の構成図である。Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔはサービス実行部５７０１（サービス実行手段）とリソースの組保持部５７０２からなる。Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースの組（１または複数のリソースを示すリソース組情報を含む情報）は、図５７のＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔのサービス実行部５７０１においてサービスの識別子を受け取るとき同時にリソースの組を受け取ることによって、関連付けられる。また、受け取ったリソースの組は、リソースの組保持部５７０２によって保持される。即ち、このようなリソースの組保持部５７０２を有するＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８は、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ管理部２００１に保持されるため、このＳｅｒｖｉｃｅＣｏｎｔｅｘｔ管理部２００１が、互いに関連付けられたＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースの組とを保持する保持手段として機能する。

図６１は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースの組を関連付けるための方法の一例である。図６１において、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス６１０１はＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス６１０２はＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、ＲｅｓｏｕｒｃｅＳｅｔクラス５８０１はリソースの組を表す。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス６１０１はリソースの組取得部２２０３として新たにｇｅｔＲｅｓｏｕｒｃｅＳｅｔ（）６１１１を定義する。このメソッドによって使用しているリソースの組を取得できる。ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス６１０２はＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス６１０１を継承する。サービス実行部５７０１は新たにｓｅｌｅｃｔ（Ｓｅｒｖｉｃｅ、ＲｅｓｏｕｒｃｅＳｅｔ）メソッド６１１２を追加する。ここで、ＳｅｒｖｉｃｅはＡｂｓｔｒａｃｔサービスを表し、ＲｅｓｏｕｒｃｅＳｅｔはリソースの組を表すクラスである。このメソッドによって、引数に指定されたＡｂｓｔｒａｃｔサービスを実行すると同時に、引数に指定されたＲｅｓｏｕｒｃｅＳｅｔと関連付けられる。これによってＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ上でＡｂｓｔｒａｃｔサービスを実行する際、指定されたリソースの組を用いる。また、Ａｂｓｔｒａｃｔサービスに含まれるＪａｖａプログラムが何らかのリソースを必要としたとき（例えば映像・音声の再生）、ｓｅｌｅｃｔメソッドの引数に指定されたリソースの組を用いる。即ち、このｓｅｌｅｃｔ（Ｓｅｒｖｉｃｅ、ＲｅｓｏｕｒｃｅＳｅｔ）メソッド６１１２がサービス実行環境とリソースの組とを関連付ける関連付け手段として機能する。

このように本発明では、サービス実行環境であるＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースの組とが関連付けられるため、サービスの実行に際して、１または複数のリソースをリソースの「組」として制御することができる。

本実施の形態のフローチャートは図６２に示される。サービス再生部１７０２はＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを、サービスマネージャ１７０４のＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部から取得する（ステップＳ６２０１）。次にサービス再生部１７０２は取得したＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔからｇｅｔＲｅｓｏｕｒｃｅＳｅｔ（）によってＲｅｓｏｕｒｃｅＳｅｔを取得する（ステップＳ６２０２）。サービス再生部１７０２は、Ａｂｓｔｒａｃｔサービスを実行する際、ＡｂｓｔｒａｃｔＳｅｒｖｃｅＣｏｎｔｅｘｔのｓｅｌｅｃｔ（Ｓｅｒｖｉｃｅ、ＲｅｓｏｕｒｃｅＳｅｔ）メソッドにＲｅｓｏｕｒｃｅＳｅｔを指定し、使用するＲｅｓｏｕｒｃｅＳｅｔを特定する（ステップＳ６２０３）。つまり、ＡｂｓｔｒａｃｔＳｅｒｖｃｅＣｏｎｔｅｘｔとＲｅｓｏｕｒｃｅＳｅｔを関連付ける。ＪａｖａプログラムはＪＭＦ１７０５ａにリソースの組を表すＪａｖａのクラスのインスタンスを取得させ、そのインスタンスを用いて映像・音声を指定することで、その映像・音声の再生を要求する（ステップＳ６２０４）。ＪＭＦ１７０５ａはステップＳ６２０３で関連付けられたＲｅｓｏｕｒｃｅＳｅｔが特定するリソースの組Ａ２４１０、あるいはリソースの組Ｂ２４１１を用いて指定された映像・音声を再生する（ステップＳ６２０５）。ここで、ステップＳ６２０４の詳細なフローチャートは図５９に示す。

（実施の形態６）
本実施の形態は、実施の形態１〜実施の形態３と異なり、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔに直接リソースの組を特定することにより使用するリソースを特定する。それ以外の部分は、実施の形態１と同じなので、本実施の形態では、リソースの組とＡｂｓｔｒａｃｔサービス用ＳｅｒｖｃｉｃｅＣｏｎｔｅｘｔのマッピングの仕方に絞って説明を行う。

本実施の形態は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースの組のマッピングをサービスマネージャ１７０４において行う。図６３に本実施の形態におけるサービスマネージャ１７０４の構成を示す。図６３において６３０１はＳｅｒｖｉｃｅＣｏｎｔｅｘｔ−リソースの組マッピング部である。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ−リソースの組マッピング部の構成は、図６４に示す。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ−リソースの組マッピング部６３０１は、リソースの組保持部６４０１、リソースの組取得部６４０２、リソースの組マッピング実現部６４０３からなる。リソースの組保持部６４０１を図６５に示す。図６５において、列６５０４は、Ａｂｓｔｒａｃｔサービス用、あるいはＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを表す。列６５０５は、リソースの組を表す。行６５０１〜６５０３はそれぞれ関連付けられているＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースの組を表す。

リソースの組取得部６４０２は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、あるいはＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔが関連付けられているリソースの組を取得する。リソースの組マッピング実現部６４０３は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースの組を関連付ける。

図６６は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースの組を関連付けるための方法の一例である。図６６において、リソースの組保持部６４０１はｒｅｓｏｕｒｃｅＳｅｔＭａｐクラス６２１１として表される。リソースの組取得部６４０２を実現するメソッドとして、ｇｅｔＲｅｓｏｕｒｃｅＳｅｔ（ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）６２１２を定義する。また、リソースの組マッピング実現部６４０３を実現するために、ｖｏｉｄ ｓｅｔＲｅｓｏｕｒｃｅＳｅｔ（ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、ＲｅｓｏｕｒｃｅＳｅｔ）メソッド６２１３を定義する。ｇｅｔＲｅｓｏｕｒｃｅＳｅｔ（ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）６２１２は引数のＳｅｒｖｉｃｅＣｏｎｔｅｘｔと関連付けられているＲｅｓｏｕｒｃｅＳｅｔを、リソースの組保持部６４０１を表現するＲｅｓｏｕｒｃｅＭａｐから取得する。ｓｅｔＲｅｓｏｕｒｃｅＳｅｔ（ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、ＲｅｓｏｕｒｃｅＳｅｔ）６２１３は引数のＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＲｅｓｏｕｒｃｅＳｅｔを関連付け、ＲｅｓｏｕｒｃｅＳｅｔＭａｐに保存する。ここで、ｒｅｓｏｕｒｃｅＳｅｔ５８０１はリソースの組を表すクラスである。

本実施の形態のフローチャートは図６７に示される。
Ａｂｓｔｒａｃｔサービスに含まれるＪａｖａプログラムはＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを、サービスマネージャ１７０４のＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部から取得する（ステップＳ６７０１）。次にＪａｖａプログラムは取得したＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを用いてｇｅｔＲｅｓｏｕｒｃｅＳｅｔ（ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）６２１２によってＲｅｓｏｕｒｃｅＳｅｔを取得する（ステップＳ６７０２）。ＪａｖａプログラムはＲｅｓｏｕｒｃｅＳｅｔＭａｐ６２０１のｓｅｔＲｅｓｏｕｒｃｅＳｅｔ（ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ，ＲｅｓｏｕｒｃｅＳｅｔ）６２１３メソッドによってＲｅｓｏｕｒｃｅＳｅｔを指定し、使用するＲｅｓｏｕｒｃｅＳｅｔを特定する（ステップＳ６７０３）。つまり、ＪａｖａプログラムがＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＲｅｓｏｕｒｃｅＳｅｔを関連付ける。Ｊａｖａプログラムは、ＪＭＦ１７０５ａにリソースの組を表すＪａｖａのクラスのインスタンスを取得させ、そのインスタンスを用いて映像・音声を指定することで、その映像・音声の再生を要求する（ステップＳ６７０４）。ＪＭＦ１７０５ａはステップＳ６７０３で関連付けられたＲｅｓｏｕｒｃｅＳｅｔが特定するリソースの組Ａ２４１０、あるいはリソースの組Ｂ２４１１を用いて指定された映像・音声を再生する（ステップＳ６７０５）。ここで、ステップＳ６７０４の詳細なフローチャートは図５９に示す。

（実施の形態７）
本実施の形態は、実施の形態１〜実施の形態６と異なり、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔに直接リソースを指定することにより、そのリソースを含むリソースの組を特定する。それ以外の部分は、実施の形態１と同じなので、本実施の形態では、リソースの組とＡｂｓｔｒａｃｔサービス用ＳｅｒｖｃｉｃｅＣｏｎｔｅｘｔのマッピングの仕方に絞って説明を行う。

本実施の形態では、サービスマネージャ１７０４がＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースの組のマッピング、リソースの組と個々のリソースのマッピングを行い、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔに個々のリソースを指定することによって、自動的にそのＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔにリソースの組を指定する。図６８に本実施の形態におけるサービスマネージャ１７０４の構成を示す。図６８において６８０１はＳｅｒｖｉｃｅＣｏｎｔｅｘｔ−リソースマッピング部である。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ−リソースマッピング部の構成は、図６９に示す。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ−リソースマッピング部６８０１は、リソース保持部６９０１、リソースの組保持部６４０１、リソース取得部６９０２、リソースの組取得部６４０２、リソースマッピング実現部６９０３からなる。リソースの組取得部６４０２、リソースの組保持部６４０１は図６４に示されるので、ここでは説明を省略する。リソース保持部６９０１の一例は図７０に示される。行７００１はリソースの組、行７００２はチューナー、行７００３はＴＳデコーダ、行７００４はオーディオデコーダ、行７００５はビデオデコーダを示す。また、列７００６はリソースの組Ａ２４１０とリソースの組Ａ２４１０に含まれるリソース、列７００７はリソースの組Ｂ２４１１とリソースの組Ｂ２４１１に含まれるリソースを表す。

なお、リソース保持部６９０１はリソースとして、上記チューナー、ＴＳデコーダ、オーディオデコーダ、ビデオデコーダを保持しているが、他の構成でも本実施の形態は実施可能である。

リソース取得部６９０２は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、あるいはＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔが関連付けられているリソースを取得する。リソースマッピング実現部６９０３は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースを関連付ける。

図７１は、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースの組を関連付けるための方法の一例である。
図７１において、リソースの組保持部６４０１はｒｅｓｏｕｒｃｅＳｅｔＭａｐ６２１１として表される。リソース保持部６９０１はｒｅｓｏｕｒｃｅＭａｐ７１１１として表される。リソースの組取得部６４０２を実現するメソッドとして、ｇｅｔＲｅｓｏｕｒｃｅＳｅｔ（ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）６２１２を定義する。リソース取得部６９０２として、ｇｅｔＲｅｓｏｕｒｃｅ（ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、Ｓｔｒｉｎｇ）メソッド７１１２を定義する。また、リソースマッピング実現部６９０３を実現するために、ｖｏｉｄ ｓｅｔＲｅｓｏｕｒｃｅ（ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、Ｏｂｊｅｃｔ）メソッド７１１３を定義する。ｇｅｔＲｅｓｏｕｒｃｅ（ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、Ｓｔｒｉｎｇ）７１１２は引数のＳｅｒｖｉｃｅＣｏｎｔｅｘｔが現在利用しているＲｅｓｏｕｒｃｅＳｅｔに含まれるＳｔｒｉｎｇで表されるリソースを、ｒｅｓｏｕｒｃｅＳｅｔＭａｐ６２１１、ｒｅｓｏｕｒｃｅＭａｐ７１１１を用いて取得する。Ｓｔｒｉｎｇにはリソースの名前、例えば、"Ｔｕｎｅｒ"などの文字列によって指定し、その結果、返り値として例えば、ＴｕｎｅｒＡ５０１ａを表すＯｂｊｅｃｔが返される。ｓｅｔＲｅｓｏｕｒｃｅ（ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、Ｏｂｊｅｃｔ）７１１３は引数のＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔと引数で指定したＯｂｊｅｃｔが表すリソースが含まれるＲｅｓｏｕｒｃｅＳｅｔを関連付け、ｒｅｓｏｕｒｃｅＳｅｔＭａｐ６２１１に保存する。ここで、ＲｅｓｏｕｒｃｅＳｅｔ５８０１はリソースの組を表すクラスである。

本実施の形態のフローチャートは図７２に示される。
Ａｂｓｔｒａｃｔサービスに含まれるＪａｖａプログラムはＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを、サービスマネージャ１７０４のＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得部から取得する（ステップＳ７２０１）。次にＪａｖａプログラムは取得したＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔと取得したいリソースの名前を用いてｇｅｔＲｅｓｏｕｒｃｅ（ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、Ｓｔｒｉｎｇ）によってリソースをあらわすＯｂｊｅｃｔを取得する(例えばチューナーを表すＯｂｊｅｃｔ)（ステップＳ７２０２）。ＪａｖａプログラムはＲｅｓｏｕｒｃｅＭａｐのｓｅｔＲｅｓｏｕｒｃｅＳｅｔ（ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔ，Ｏｂｊｅｃｔ）メソッドによってＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔにリソースのＯｂｊｅｃｔを指定し、使用するＲｅｓｏｕｒｃｅＳｅｔを特定する（ステップＳ７２０３）。つまり、Ｊａｖａプログラムは、ＡｂｓｔｒａｃｔＳｅｒｖｉｃｅＣｏｎｔｅｘｔと、ステップＳ７２０２で取得したリソースが含まれるＲｅｓｏｕｒｃｅＳｅｔとを関連付ける。Ｊａｖａプログラムは、ＪＭＦ１７０５ａにリソースの組を表すＪａｖａのクラスのインスタンスを取得させ、そのインスタンスを用いて映像・音声を指定して、その映像・音声の再生を要求する（ステップＳ７２０４）。ＪＭＦ１７０５ａはステップＳ７２０３で関連付けられたＲｅｓｏｕｒｃｅＳｅｔが特定するリソースの組Ａ２４１０、あるいはリソースの組Ｂ２４１１を用いて指定された映像・音声を再生する（ステップＳ７２０５）。ここで、ステップＳ７２０４の詳細は図５９に示したとおりである。

（実施の形態８）
本実施の形態では、実施の形態１から実施の形態７では、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔとＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、あるいはリソースの組を関連付けることによって、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔからリソースの組、あるいはリソースを特定するオブジェクトを指定した。しかし、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔが例えば、２つのビデオデコーダを使用したい場合、ビデオデコーダを操作するたびに、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔあるいはリソースの組を関連付ける煩雑さがある。図７５は２つのビデオデコーダを使用する一例である。７５０１はＣＭの映像である。その他の構成要素は図３８で示してあるので省略する。

本実施の形態では、Ｊａｖａライブラリ１７０５を用いて、実際のリソースと関連付けられたＪａｖａのオブジェクトを取得することによって、リソースを特定する。他は、実施の形態１と同じであるので、本実施の形態では、リソースの特定方法を中心に述べる。

実施の形態１において参照した図１７のＪａｖａライブラリ１７０５が図７３のように構成されている場合を考える。図７３において、ＳＦＬ７３０１はセクションフィルタを表す。ＳＦＬ７３０１は、図１１Ａ及び図１１Ｂで示したセクションフィルタＡ１１０２ａ、セクションフィルタＢ１１０２ｂを用いて、セクションのフィルタリングを行い、１次記憶部５１１に格納する。Ｄｅｖｉｃｅ７３０２は図５で示した表示デバイスＡ５２０ａ、表示デバイスＢ５２０ｂを制御する。サウンド７３０３はオーディオデコーダＡ５０６ａ、あるいはオーディオデコーダＢ５０６ｂを用いて音声を再生する。その他の構成要素は、図１７において説明したので省略する。

これらのライブラリは、物理的なリソースを表す、あるいはリソースを特定し、実行することができるＪａｖａのクラスを定義する。それぞれのクラスと実際のリソースの関係を記す図７４は、物理的なリソースを表す、あるいはリソースを特定し、実行することができるＪａｖａのクラスと実際のリソースの関係を記す。図７４において、７４２０の中にはＪａｖａのクラスのインスタンス、７４２１の中には実際のリソースを表す。ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅクラス７４０１は、ＤＡＶＩＣ仕様（ＤＡＶＩＣ１．４．１ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｐａｒｔ９、Ｃｏｍｐｌｅｔｅ ＤＡＶＩＣ Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ、以下ＤＡＶＩＣ仕様と呼ぶ）で定義されており、ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅクラスのインスタンスを管理するクラスＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅＭａｎａｇｅｒにメソッドｐｕｂｌｉｃ ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅ［］ ｇｅｔＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅｓ（）、あるいはｐｕｂｌｉｃ ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅ ｇｅｔＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅ（ＴｒａｎｓｐｏｒｔＳｔｒｅａｍ）によって取得されることができる。ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅクラスはＴｕｎｅｒ１７０５ａに定義され、チューナーＡ５０１ａを内部的に特定する。ＳｅｃｔｉｏｎＦｉｌｔｅｒＧｒｏｕｐ７４０２は、ＤＡＶＩＣ仕様で定義され、ＳｅｃｔｉｏｎＦｉｌｔｅｒＧｒｏｕｐのコンストラクタで取得できる。ＳｅｃｔｉｏｎＦｉｌｔｅｒＧｒｏｕｐクラスはＳＦＬ７３０１に定義され、セクションフィルタ７４１１を利用する。Ｐｌａｙｅｒ７４０３はインタフェースでその実装クラスは映像を再生する。ＰｌａｙｅｒはＪａｖａ Ｍｅｄｉａ Ｆｒａｍｅｗｏｒｋ仕様（Ｊａｖａ Ｍｅｄｉａ Ｆｒａｍｅｗｏｒｋ ＡＰＩ Ｖｅｒｓｉｏｎ １．０ Ｃｏｎｓｔａｎｔｓ）において定義される。Ｐｌａｙｅｒの実装クラスのインスタンスは、Ｐｌａｙｅｒを生成するクラスＭａｎａｇｅｒのメソッドｃｒｅａｔｅＰｌａｙｅｒ（ＤａｔａＳｏｕｒｃｅ）、ｃｒｅａｔｅＰｌａｙｅｒ（ＭｅｄｉａＬｏｃａｔｏｒ）、ｃｒｅａｔｅＰｌａｙｅｒ（ＵＲＬ）によって取得することができる。ＰｌａｙｅｒはＪＭＦ１７０５ａに定義され、その実装クラスは内部的には、ＴＳデコーダ５０５ａ、オーディオデコーダＡ５０６ａ、ビデオデコーダＡ５０８ａを用いて実現される。ＨＳｏｕｎｄ７４０４は音を再生する。ＨＳｏｕｎｄクラスは、ＨＡＶｉ仕様（ＨＡＶｉ ｖ１．１ Ｊａｖａ Ｌ２ ＡＰＩｓ、 １５−Ｍａｙ−２００１ 以下ＨＡＶｉ仕様と呼ぶ）で定義され、ＨＳｏｕｎｄクラスのコンストラクタによって取得できる。ＨＳｏｕｎｄクラスは、サウンド７３０３に定義され、オーディオデコーダＡ５０６ａを利用する。ＨＧｒａｐｈｉｃｓＤｅｖｉｃｅ７４０５、ＨＶｉｄｅｏＤｅｖｉｃｅ７４０６、ＨＢａｃｋｇｒｏｕｎｄＤｅｖｉｃｅ７４０７は、ＨＡＶｉ仕様で定義され、それぞれのクラスのインスタンスは、ＨＧｒａｐｈｉｃｓＤｅｖｉｃｅ７４０５、ＨＶｉｄｅｏＤｅｖｉｃｅ７４０６、ＨＢａｃｋｇｒｏｕｎｄＤｅｖｉｃｅ７４０７を管理するＨＳｃｒｅｅｎクラスのメソッドｐｕｂｌｉｃ ＨＧｒａｐｈｉｃｓＤｅｖｉｃｅ［］ ｇｅｔＨＶｉｄｅｏＤｅｖｉｃｅｓ（）、ｐｕｂｌｉｃ ＨＶｉｄｅｏＤｅｖｉｃｅ［］ ｇｅｔＨＶｉｄｅｏＤｅｖｉｃｅｓ（）、ｐｕｂｌｉｃ ＨＢａｃｋｇｒｏｕｎｄＤｅｖｉｃｅ［］ ｇｅｔＨＢａｃｋｇｒｏｕｎｄＤｅｖｉｃｅｓ（）、あるいはｐｕｂｌｉｃ ＨＧｒａｐｈｉｃｓＤｅｖｉｃｅ ｇｅｔＤｅｆａｕｌｔＨＧｒａｐｈｉｃｓＤｅｖｉｃｅ（）、ｐｕｂｌｉｃ ＨＶｉｄｅｏＤｅｖｉｃｅ ｇｅｔＤｅｆａｕｌｔＨＶｉｄｅｏＤｅｖｉｃｅ（）、ｐｕｂｌｉｃ ＨＢａｃｋｇｒｏｕｎｄＤｅｖｉｃｅ ｇｅｔＤｅｆａｕｌｔＨＢａｃｋｇｒｏｕｎｄＤｅｖｉｃｅ（）によって取得できる。ＨＧｒａｐｈｉｃｓＤｅｖｉｃｅ７４０５、ＨＶｉｄｅｏＤｅｖｉｃｅ７４０６、ＨＢａｃｋｇｏｕｎｄＤｅｖｉｃｅ７４０７はデバイス７３０２に定義され、それぞれ、グラフィックスデバイス７４１２、ビデオデバイス７４１３、バックグラウンドデバイス７４１４を示す。

なお、本実施の形態では、リソースを表す、あるいは利用するＪａｖａのクラスのインスタンスと物理的なリソースをそれぞれ図７４に示す構成で考えたが、他の構成でも本実施の形態は実施可能である。

図７６はＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの一例を示す。Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔは、ｇｅｔＲｅｓｏｕｒｃｅＳｅｔ（）メソッド７６１１を定義し、ＲｅｓｏｕｒｃｅＳｅｔインスタンスを返す。ＲｅｓｏｕｒｃｅＳｅｔ７６０２は、リソースの組を表し、ｇｅｔＲｅｓｏｕｒｃｅ（Ｓｔｒｉｎｇ）７６１２を定義する。ｇｅｔＲｅｓｏｕｒｃｅ（Ｓｔｒｉｎｇ）７６１２は、Ｓｔｒｉｎｇにリソースを利用するＪａｖａのクラスを指定することにより、このリソースの組に含まれるリソースを表す、あるいは、使用するＪａｖａのインスタンスを返す。例えば、ｇｅｔＲｅｓｏｕｒｃｅ（"ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅ"）と指定することにより、ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅクラスのインスタンスを取得できる。この引数は、Ｓｔｒｉｎｇ（文字列）で指定しているが、リソースの識別子等、指定できるものであれば何でもよい。また、ｇｅｔＲｅｓｏｕｒｃｅｓ（）メソッド７６１３はすべてのリソースを表現するＪａｖａのクラスのインスタンスを返す。例えば、ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅクラスのインスタンス７４０１、ＳｅｃｔｉｏｎＦｉｌｔｅｒＧｒｏｕｐクラスのインスタンス７４０２、Ｐｌａｙｅｒクラスのインスタンス７４０３、ＨＳｏｕｎｄクラスのインスタンス７４０４、ＨＧｒａｐｈｉｃｓＤｅｖｉｃｅクラスのインスタンス７４０５、ＨＶｉｄｅｏＤｅｖｉｃｅクラスのインスタンス７４０６、ＨＢａｃｋｇｒｏｕｎｄＤｅｖｉｃｅクラスのインスタンス７４０７を返す。Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ２１０８は、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔのｇｅｔＲｅｓｏｕｒｃｅ（Ｓｔｒｉｎｇ）、あるいは、ｇｅｔＲｅｓｏｕｒｃｅｓ（）を呼ぶことによって、リソースに関連付けられたＪａｖａのインスタンスを取得することができ、リソースを特定できる。

なお、１つのＳｅｒｖｉｃｅＣｏｎｔｅｘｔが複数のＲｅｓｏｕｒｃｅＳｅｔを保持していても、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ７６０１にｐｕｂｌｉｃ ＲｅｓｏｕｒｃｅＳｅｔ［］ ｇｅｔＲｅｓｏｕｒｃｅＳｅｔ（）を定義することによって実現できる。

なお、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔにｐｕｂｌｉｃ Ｏｂｊｅｃｔ［］ ｇｅｔＲｅｓｏｕｒｃｅｓ（）、ｐｕｂｌｉｃ Ｏｂｊｅｃｔ ｇｅｔＲｅｏｕｓｒｃｅ（Ｓｔｒｉｎｇ）を定義して、リソースを表すクラスのインスタンスを取得してもよい。

（実施の形態９）
実施の形態８では、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔからＪａｖａのクラスのインスタンスを取得することによってリソースを特定できた。しかし、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔが直接Ｊａｖａライブラリ１７０５から、物理的なリソースを表すインスタンス、あるいはリソースを利用するＪａｖａのクラスのインスタンスを取得した場合、どのＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔによって特定されるリソースの組にリソースが含まれるかはわからない。本実施の形態では、Ｊａｖａライブラリから取得したインスタンスをＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔにたずねることによってＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔが特定するリソースの組にリソースが含まれるかどうかを決定する。他は、実施の形態１と同じであるので、本実施の形態では、リソースの特定方法を中心に述べる。

図７７はＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの一例を示す。７７０１はＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを表す。ｉｓＣｏｎｔａｉｎｅｄ（Ｏｂｊｅｃｔ）メソッド７７１１は引数に指定された物理的なリソースを表す、あるいはリソースを利用するＪａｖａのクラスのインスタンスをとり、その引数に指定されたインスタンスが、そのＳｅｒｖｉｃｅＣｏｎｔｅｘｔが特定するリソースの組に含まれるリソースを用いるかどうかを判断する。そのＳｅｒｖｉｃｅＣｏｎｔｅｘｔが特定するリソースを用いる場合、ｔｒｕｅを返し、用いない場合、ｆａｌｓｅを返す。これによって、引数のＯｂｊｅｃｔで指定したリソースがどのリソースの組に含まれるかを特定できる。

（実施の形態１０）
実施の形態９ではＪａｖａのクラスのインスタンスがＳｅｒｖｉｃｅＣｏｎｔｅｘｔの特定するリソースの組に含まれるリソースを用いるかどうかを判断した。しかしながら、たとえば、図５の表示デバイスが１つであらわされ、かつその構成要素が図７８に示されるようにビデオデバイス７８０１が１つである場合、２つのＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔは１つのビデオデバイスを共有するということもありうる。このような場合、あるＳｅｒｖｉｃｅＣｏｎｔｅｘｔに関連付けられているかどうかの判断以外にも共有しているかどうかを見分ける方法が必要である。図７９はＩｎ−ｂａｎｄのＳｅｒｖｉｃｅＣｏｎｔｅｘｔの一例を示す。図７９では、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを表すＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス７９０１に図７７に示されるｉｓＣｏｎｔａｉｎｅｄメソッド７７１１のほかに新たにメソッドｉｓＳｈａｒｅｄ（Ｏｂｊｅｃｔ）７９１１を定義する。このメソッド７９１１は２つのＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ間でリソースを共有していれば、例えば、同じビデオデバイス７８０１を共有していればこのメソッドはｔｒｕｅを返し、共有していなければｆａｌｓｅを返す。

（実施の形態１１）
実施の形態９に加えて、物理リソースが使用中であるかどうかを調べるメソッドを追加する。これによって、空いているリソースを特定することができる。図８０はＩｎ−ｂａｎｄのＳｅｒｖｉｃｅＣｏｎｔｅｘｔの一例を示す。図８０において、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス８００１はＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを表す。ＳｅｒｖｉｃｅＣｏｎｔｅｘｔクラス８００１において、ｉｓＵｓｅｄ（Ｏｂｊｅｃｔ）メソッド８０１１は、引数に渡されたＪａｖａのクラスのインスタンスが使用する物理的なリソースが現在使用中であればｔｒｕｅ、使用していなければｆａｌｓｅを返す。ｉｓＣｏｎｔａｉｎｅｄ（Ｏｂｊｅｃｔ）７７１１は図７７に示したので省略する。

なお、実施の形態８と実施の形態９から実施の形態１１のいずれかの組み合わせを同時に定義すること可能である。

（実施の形態１２）
実施の形態９から実施の形態１１においてＪａｖａライブラリ１７０５から、リソースを表すインスタンス、あるいはリソースを利用するクラスのインスタンスを取得するとき、使用したいリソースの組に関連付けられたインスタンスを取得できない可能性がある。コンストラクタからインスタンスを生成する場合、あるいはＰｌａｙｅｒを取得するときには、つねにある特定のリソースの組を利用するインスタンス、例えば、ＳｅｃｔｉｏｎＦｉｌｔｅｒＧｒｏｕｐ、ＨＳｏｕｎｄのインスタンス等しか取得できない可能性もある。そのとき、これらのメソッドに対して、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔにおいて、例えばｐｕｂｌｉｃ ｖｏｉｄ ｃｏｎｎｅｃｔＲｅｓｏｕｒｃｅ（Ｏｂｊｅｃｔ）メソッドを定義することによって、関連付けるリソースの組を変更することができるようにする。引数のＯｂｊｅｃｔには、リソースを表すインスタンス、あるいはリソースを利用するクラスのインスタンスを指定する。

なお、本実施の形態は、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔにｐｕｂｌｉｃ ｖｏｉｄ ｃｏｎｎｅｃｔＲｅｓｏｕｒｃｅ（Ｏｂｊｅｃｔ）メソッドを定義することによってリソースを特定しているが、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔに、ｐｕｂｌｉｃ ｖｏｉｄ ｃｏｎｎｅｃｔＲｅｓｏｕｒｃｅ（ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、Ｏｂｊｅｃｔ）を定義することによっても実現可能である。ここで、引数のＳｅｒｖｉｃｅＣｏｎｔｅｘｔには、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを指定する。

なお、本実施の形態は、引数のＯｂｊｅｃｔに指定するリソースを表すインスタンス、あるいはリソースを利用するクラスのインスタンスを特定のものに限定しても実施可能である。例えば、実施の形態８に述べたインスタンスのうちＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅクラスのインスタンスは、現実のリソースと関連付けられたインスタンスをすべて取得することができるので、本実施の形態のメソッドの引数に指定することができないようにする等が考えられる。

（実施の形態１３）
実施の形態８では、Ｉｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔからＪａｖａのクラスのインスタンスを取得することによってリソースを特定できた。しかし、Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔが直接Ｊａｖａライブラリ１７０５から物理的なリソースを表すインスタンス、あるいはリソースを利用するＪａｖａのクラスのインスタンス取得した場合、どのＩｎ−ｂａｎｄのＳｅｒｖｉｃｅＣｏｎｔｅｘｔによって特定されるリソースの組にリソースが含まれるかはわからない。

本実施の形態では、物理的なリソースを表すインスタンス、あるいはリソースを利用するＪａｖａのクラスのインスタンスを取得するときに、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを引数に与えることによって、使用するリソース、およびリソースの組を特定する。他は、実施の形態１と同じであるので、本実施の形態では、リソースの特定方法を中心に述べる。以下のメソッドを、Ｊａｖａライブラリ１７０５を用いて定義する。

ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅクラスのインスタンスを取得するときは、ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅクラスのインスタンスを管理するクラスＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅＭａｎａｇｅｒにメソッドｐｕｂｌｉｃ ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅ［］ ｇｅｔＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅｓ（ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）を追加することにより、物理的なリソースを特定するＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅクラスのインスタンスを取得する。ＳｅｃｔｉｏｎＦｉｌｔｅｒＧｒｏｕｐのコンストラクタにおいて、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔを引数に与えることにより、物理的なリソースを特定するＳｅｃｔｉｏｎＦｉｌｔｅｒＧｒｏｕｐクラスのインスタンスを取得する。引数にＳｅｒｖｉｃｅＣｏｎｔｅｘｔを与えるメソッドｃｒｅａｔｅＰｌａｙｅｒ（ＤａｔａＳｏｕｒｃｅ、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）、ｃｒｅａｔｅＰｌａｙｅｒ（ＭｅｄｉａＬｏｃａｔｏｒ、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）、ｃｒｅａｔｅＰｌａｙｅｒ（ＵＲＬ、ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ）のいずれか、あるいはすべてを、Ｐｌａｙｅｒを生成するクラスＭａｎａｇｅｒのメソッドに追加することにより、物理的なリソースを特定するＰｌａｙｅｒクラスのインスタンスを取得する。ここで、ＤａｔａＳｏｕｒｃｅ、ＭｅｄｉａＬｏｃａｔｏｒ、ＵＲＬは再生するＡＶのソースの場所を指定する。

ＨＧｒａｐｈｉｃｓＤｅｖｉｃｅ、ＨＶｉｄｅｏＤｅｖｉｃｅ、ＨＢａｃｋｇｒｏｕｎｄＤｅｖｉｃｅは、ＨＳｃｒｅｅｎクラスのメソッドｐｕｂｌｉｃ ＨＧｒａｐｈｉｃｓＤｅｖｉｃｅ［］ ｇｅｔＨＶｉｄｅｏＤｅｖｉｃｅｓ（ＳｅｒｖｉｃｅＣｏｎｅｘｔ）、ｐｕｂｌｉｃ ＨＶｉｄｅｏＤｅｖｉｃｅ［］ ｇｅｔＨＶｉｄｅｏＤｅｖｉｃｅｓ（ＳｅｒｖｉｃｅＣｏｎｅｘｔ）、ｐｕｂｌｉｃ ＨＢａｃｋｇｒｏｕｎｄＤｅｖｉｃｅ［］ ｇｅｔＨＢａｃｋｇｒｏｕｎｄＤｅｖｉｃｅｓ（ＳｅｒｖｉｃｅＣｏｎｅｘｔ）、あるいはｐｕｂｌｉｃ ＨＧｒａｐｈｉｃｓＤｅｖｉｃｅ ｇｅｔＤｅｆａｕｌｔＨＧｒａｐｈｉｃｓＤｅｖｉｃｅ（ＳｅｒｖｉｃｅＣｏｎｅｘｔ）、ｐｕｂｌｉｃ ＨＶｉｄｅｏＤｅｖｉｃｅ ｇｅｔＤｅｆａｕｌｔＨＶｉｄｅｏＤｅｖｉｃｅ（ＳｅｒｖｉｃｅＣｏｎｅｘｔ）、ｐｕｂｌｉｃ ＨＢａｃｋｇｒｏｕｎｄＤｅｖｉｃｅ ｇｅｔＤｅｆａｕｌｔＨＢａｃｋｇｒｏｕｎｄＤｅｖｉｃｅ（ＳｅｒｖｉｃｅＣｏｎｅｘｔ）を追加することによって、物理リソースを特定する。

なお、本実施の形態では、引数にＳｅｒｖｉｃｅＣｏｎｔｅｘｔを指定したが、リソースの組を特定するクラスＲｅｓｏｕｒｃｅＳｅｔを定義し、それを引数に指定するなど、リソースの組を表す識別子を指定することによっても実現可能である。

なお、本実施の形態では、上記リソースを表すインスタンス、あるいはリソースを利用するクラスのインスタンスの取得方法として、上記のメソッドを考えているが、これらのメソッド以外でも、引数にＳｅｒｖｉｃｅＣｏｎｔｅｘｔ、あるいはＲｅｓｏｕｒｃｅＳｅｔクラスのインスタンスを指定することにより、実施可能である。

以上のように本発明によれば、１ないし複数のサービスを実行するサービス実行手段と、前記サービスが使用するリソース集合を特定する実行環境を保持する実行環境保持手段と前記実行環境保持手段が保持する実行環境と前記サービスを対応付けることにより前記サービスと前記実行環境が特定するリソース集合を対応付ける実行環境選定手段を備えることにより、前記実行環境で動作する前記サービス内の映像、音声、プログラムなどを実行する際に必要となるリソース集合を割り当てることができる。

また、前記実行環境を表す実行環境識別子を前記実行環境保持手段から取得する実行環境識別子取得手段を備え、前記実行環境識別子はサービスの識別子を受け取るサービスの識別子受け取り部を備えることにより、前記サービスは前記リソース集合を割り当てて実行することができる。

また、前記実行環境保持手段は、複数の実行環境を保持し、前記実行環境を表す実行環境識別子を前記実行環境保持手段から取得する実行環境識別子取得手段を備え、前記実行環境識別子は、第二の実行環境識別子を受け取る実行環境識別子受け取り部を有し、前記実行環境識別子受け取り部が前記第二の実行環境識別子を受け付けたとき、実行環境選定手段は、前記実行環境識別子が示す実行環境で動作するサービスと前記第二の実行環境識別子が示す実行環境のリソース集合を対応付けることによって、前記実行環境で動作する前記サービスに含まれる映像、音声、プログラムを実行する際に必要となるリソース集合として任意の実行環境が特定するリソース集合を割り当てることができ、また、複数のリソース集合を交互に割り当てることで、複数のリソース集合の制御ができる。

また、前記実行環境識別子が示す実行環境で動作するサービスは、前記実行環境識別子取得手段により第二の実行環境識別子を取得し、前記第二の実行環境識別子のサービスの識別子受け取り部に第二のサービスを渡し、前記第二のサービスを動作させることによって、前記実行環境で動作するサービスが前記第二の実行環境識別子が示す実行環境で第二のサービスを動作させることができる。

また、前記実行環境識別子が示す実行環境で動作するサービスのうち限定されたものだけが、前記実行環境識別子取得手段により第二の実行環境識別子を取得し、前記第二の実行環境識別子のサービス受け取り部に第二のサービスを渡し、前記第二のサービスを動作させることによって、実行環境で動作するサービスのうち、限定されたサービスが第二の実行環境識別子が示す実行環境で第二のサービスを動作させることができる。

また、前記サービスの識別子受け取り部はサービスの識別子を受け取ると同時に実行環境識別子も受け取り、前記サービスの識別子受け取り部がサービスの識別子とともに前記実行環境識別子取得手段により取得した第二の実行環境識別子を受け取ったとき、実行環境選定手段は、前記実行環境識別子が示す実行環境で動作するサービスと前記第二の実行環境識別子が示す実行環境のリソース集合を対応付けることによって、前記実行環境で動作するサービスに含まれる映像、音声、プログラムを実行する際に必要となるリソース集合として他の実行環境によって特定されるリソース集合を割り当てることができ、柔軟なリソース集合の制御ができる。

また、前記実行環境を表す実行環境識別子を前記実行環境保持手段から取得する実行環境識別子取得手段を備え、前記実行環境識別子は、前記実行環境識別子が示す実行環境が特定するリソース集合を取得するリソース集合取得部を有することにより、リソース集合を取得することができ、装置内のリソース集合を知ることができる。

また、前記実行環境保持手段は、複数の実行環境を保持し、前記実行環境識別子は、前記実行環境識別子取得手段から取得した第二の実行環境識別子の前記リソース集合取得部から取得したリソース集合を受け取るリソース集合受け取り部を有し、前記リソース集合受け取り部が前記リソース集合を受け付けたとき、前記実行環境選定手段は、前記実行環境識別子が示す実行環境で動作するサービスと前記実行環境が特定する前記リソース集合を対応付けることによって、前記実行環境で動作するサービス内の映像、音声、プログラムなどを実行する際に必要となるリソース集合として前記リソース集合を明示的に割り当てることができ、柔軟なリソース集合の制御ができる。

また、前記リソース集合は個々のリソースを取得する個別リソース取得部を有することにより、個々のリソースの制御が可能となり、リソースの集合を特定して映像、音声、プログラムなどを個別に実行できる。

また、前記個別リソース取得部が、前記リソース集合に含まれる全てのリソースを取得することによって、前記リソース集合に含まれる全リソースを知ることができる。
また、前記実行環境を表す実行環境識別子を前記実行環境保持手段から取得する実行環境識別子取得手段を備え、前記実行環境識別子は、前記実行環境識別子が示す実行環境が特定するリソース集合に含まれる個々のリソースを取得するリソース取得部を有することにより、リソース集合に含まれる個々のリソースを取得することができ、リソース集合を特定して映像、音声、プログラムなどを個別に実行できる。

また、前記リソース取得部が、前記リソース集合の全てリソースを取得することにより、全てのリソースを取得することができ、前記リソース集合に含まれる全リソースを知ることができる。

また、前記実行環境保持手段が保持する実行環境が特定するリソース集合に含まれる個々のリソースを取得できる個別リソース取得手段を備えることにより、全ての実行環境のリソース集合に含まれる個々のリソースを取得することができ、リソース集合を特定して、映像、音声、プログラムなどを個別に実行できる。

また、前記実行環境を表す実行環境識別子を前記実行環境保持手段から取得する実行環境識別子取得手段を備え、前記実行環境識別子が示す実行環境が特定するリソース集合が前記個別リソース取得手段によって取得したリソースを含むか否かを判定するリソース判定部を備えることにより、個々のリソースが含まれるリソース集合を特定することによって、特定のリソース集合に含まれるリソースを判別でき、リソース集合を特定して、映像、音声、プログラムなどを個別に実行できる。

また、前記実行環境識別子取得手段によって取得した第二の実行環境識別子が示す実行環境が特定するリソース集合と前記実行環境識別子が示す実行環境が特定するリソース集合が前記個別リソース取得手段によって取得したリソースを共有するか否かを判定するリソース共有判定部を備えることにより、個々のリソースが複数のリソース集合によって共有されているか否かを判定できることによって、共有されていない場合は、前記実行環境識別子が示す実行環境で動作するプログラムが、そのリソースを、排他的に使うことを保障でき、他のサービスに影響を与えずに映像、音声、プログラムなどを個別に実行できる。

また、前記実行環境識別子が示す実行環境は、前記個別リソース取得手段によって取得した前記リソースが、実行環境識別子取得手段から取得した実行環境識別子が示す実行環境が使用中であるか否かを判定するリソース使用判定部を備えることにより、個々のリソースが、現在使用中であるか否かを判定できることによって、空いているリソースを用いて映像、音声、プログラムなどを個別に実行できる。

また、前記実行環境を表す実行環境識別子を前記実行環境保持手段から取得する実行環境識別子取得手段を備え、前記実行環境識別子は前記実行環境識別子が示す実行環境が特定するリソース集合と前記個別リソース取得手段によって取得したリソースを対応付けるリソース接続部を備えることにより、前記リソースを前記リソース集合に含めることによって、リソースを制御したいリソースの集合に含めることができる。

また、前記実行環境を表す実行環境識別子を前記実行環境保持手段から取得する実行環境識別子取得手段を備え、前記個別リソース取得手段は前記実行環境識別子取得手段によって取得した実行環境識別子を指定することにより、前記実行環境識別子が示す実行環境の特定するリソース集合に含まれるリソースを取得することによって、前記実行環境が特定するリソース集合に含まれるリソースを用いて映像、音声、プログラムなど個別に実行できる。

また、前記実行環境保持手段は、複数の実行環境を保持し、前記実行環境を表す実行環境識別子を前記実行環境保持手段から取得する実行環境識別子取得手段と、前記実行環境識別子と前記実行環境識別子取得手段により取得した第二の実行環境識別子を対応付ける実行環境対応付け手段を備え、前記実行環境対応付け手段により前記実行環境識別子と前記第二の実行環境識別子を対応付けたとき、実行環境選定手段は、前記実行環境識別子が示す実行環境で動作するサービスと前記第二の実行環境識別子が示す実行環境のリソース集合を対応付けることによって、実行環境で動作するサービス内の映像、音声、プログラムなどを実行する際に必要となるリソース集合として第二の実行環境識別子が示す実行環境が特定するリソース集合を割り当てることができる。

また、前記実行環境保持手段は、複数の実行環境を保持し、前記実行環境を表す実行環境識別子を前記実行環境保持手段から取得する実行環境識別子取得手段を備え、前記実行環境識別子は、前記実行環境識別子が示す実行環境が特定するリソース集合を取得するリソース集合取得部を有し、前記実行環境識別子と第二の実行環境識別子のリソース集合取得部から取得したリソース集合を対応付けるリソース集合対応付け手段を備え、前記リソース集合対応付け手段により前記実行環境識別子と前記リソース集合を対応付けたとき、実行環境選定手段は、前記実行環境識別子が示す実行環境で動作するサービスと前記リソース集合を対応付ける実行環境とリソース集合を対応付けることによって、実行環境で動作するサービス内の映像、音声、プログラムなどを実行する際に必要となるリソース集合として第二の実行環境識別子が示す実行環境が特定するリソース集合を割り当てることができる。

また、コンピュータ読み取り可能な記憶媒体であって、１ないし複数のサービスを実行するサービス実行手段と、前記サービスが使用するリソース集合を特定する実行環境を保持する実行環境保持手段と前記実行環境保持手段が保持する実行環境と前記サービスを対応付けることにより前記サービスと前記実行環境が特定するリソース集合を対応付ける実行環境選定手段の各機能を発揮するプログラムを記録したコンピュータ読み取り可能な記録媒体であることにより、可搬性を高めることができる。

本発明にかかるサービス実行装置は、１ないし複数のサービスを実行するサービス実行手段と、前記サービスが使用するリソース集合を特定する実行環境を保持する実行環境保持手段と、前記実行環境保持手段が保持する実行環境と前記サービスを対応付けることにより前記サービスと前記実行環境が特定するリソース集合を対応付ける実行環境選定手段を備えることによって、デジタル放送受信機において、サービスに含まれるプログラムがＰｉｃｔｕｒｅ ｉｎ ＰｉｃｔｕｒｅやＤｏｕｂｌｅ Ｗｉｎｄｏｗなどの複数のリソース集合を制御する際に有用である。またデジタル放送受信機に限らずパーソナルコンピュータや携帯電話などソフトウエアによって制御される情報機器の複数のリソース集合を制御などの用途にも応用できる。

本発明に係るケーブルテレビシステムの実施の形態１の構成図である。 本発明に係るケーブルテレビシステムにおいてヘッドエンドと端末装置間の通信に使用される周波数帯域の使い方の一例を示す図である。 本発明に係るケーブルテレビシステムにおいてヘッドエンドと端末装置間の通信に使用される周波数帯域の使い方の一例を示す図である。 本発明に係るケーブルテレビシステムにおいてヘッドエンドと端末装置間の通信に使用される周波数帯域の使い方の一例を示す図である。 本発明に係るケーブルテレビシステムにおいて端末装置の構成図である。 本発明に係るケーブルテレビシステムにおいて端末装置の外観の一例を示す図である。 本発明に係るＰＯＤ５０４のハードウェア構成の構成図である。 本発明に係るディスプレイ５０９の表示の一例を示す図である。 本発明に係るディスプレイ５０９の表示の一例を示す図である。 本発明に係るＰＯＤ５０４が保存するプログラム構成の構成図である。 （ａ）は、本発明に係るＴＳデコーダＡの構成図であり、（ｂ）は、本発明に係るＴＳデコーダＢの構成図である。 ＭＰＥＧ規格で定義されているパケットの構成図である。 ＭＰＥＧ２トランスポートストリームの一例を示す図である。 入力部５１３をフロントパネルで構成した場合の外観の一例を示す図である。 本発明に係る表示デバイスＡ５２０ａ、あるいは表示デバイスＢ５２０ｂの構成図である。 本発明に係る表示デバイスの構成図である。 本発明に係る端末装置５００が保存するプログラム構成の構成図である。 本発明に係る２次記憶部５１０が保存する情報の一例を示す図である。 （ａ）は、本発明に係る１次記憶部５１１が保存する情報の一例を示す図であり、（ｂ）は、本発明に係る１次記憶部５１１が保存する情報の他の例を示す図であり、（ｃ）は、本発明に係る１次記憶部５１１が保存する情報のさらに他の例を示す図である。 本発明に係るサービスマネージャ１７０４の構成図である。 本発明に係るＳｅｒｖｉｃｅＣｏｎｔｅｘｔ管理部の一例を示す図である。 本発明に係るＩｎ−ｂａｎｄのサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの一例を示す図である。 本発明に係るリソースの組保持部の一例を示す図である。 本発明に係るリソースの組の一例を示す図である。 本発明に係るＳｅｒｖｉｃｅＣｏｎｔｅｘｔ取得に関するフローチャートである。 本発明に係るＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースの組の関係を示す図である。 本発明に係るチューナーを表すＪａｖａのクラスのインスタンスを取得するフローチャートである。 本発明に係る映像、音声を再生するＪａｖａのクラスのインスタンスを取得するフローチャートである。 本発明に係るＭＰＥＧ２規格が規定するＰＡＴの内容を表す模式図である。 本発明に係るＭＰＥＧ２規格が規定するＰＭＴの内容を表す模式図である。 本発明に係るＤＶＢ−ＭＨＰ規格が規定するＡＩＴの内容を表す模式図である。 本発明に係るＤＳＭＣＣ方式で送信されるファイルシステムを表す模式図である。 本発明に係るディスプレイ５０９の表示の一例を示す図である。 本発明に係るディスプレイ５０９の表示の一例を示す図である。 本発明に係るディスプレイ５０９の表示の一例を示す図である。 本発明に係るディスプレイ５０９の表示の一例を示す図である。 本発明に係るディスプレイ５０９の表示の一例を示す図である。 本発明に係るディスプレイ５０９の表示の一例を示す図である。 本発明に係るＡｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの構成図である。 （ａ）は、本発明に係るディスプレイ５０９の表示の一例を示す図であり、（ｂ）は、本発明に係るディスプレイ５０９の表示の他の例を示す図である。 本発明に係るＸＡＩＴの内容を表す模式図である。 本発明に係る２次記憶部５１０が保存する情報の一例を示す図である。 本発明に係るＳｅｒｖｉｃｅＣｏｎｔｅｘｔとリソースの組の関係を示す図である。 本発明に係るＪａｖａのクラスを示す図である。 本発明に係る映像・音声を再生するフローチャートである。 本発明に係る映像・音声を再生するフローチャートである。 Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの構成図である。 Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの構成図である。 本発明に係るＪａｖａのクラスを示す図である。 本発明に係る映像・音声を再生するフローチャートである。 本発明に係るサービスマネージャ１７０４の構成図である。 本発明に係るＳｅｒｖｉｃｅＣｏｎｔｅｘｔマッピング部の構成図である。 本発明に係るＳｅｒｖｉｃｅＣｏｎｔｅｘｔマッピング保持部の一例を示す図である。 本発明に係るＪａｖａのクラスを示す図である。 本発明に係る映像・音声を再生するフローチャートである。 Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの構成図である。 Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔの構成図である。 本発明に係るＪａｖａのクラスを示す図である。 本発明に係る映像、音声を再生するＪａｖａのクラスのインスタンスを取得するフローチャートである。 本発明に係る映像・音声を再生するフローチャートである。 本発明に係るＪａｖａのクラスを示す図である。 本発明に係る映像、音声を再生するＪａｖａのクラスのインスタンスを取得するフローチャートである。 本発明に係るサービスマネージャ１７０４の構成図である。 本発明に係るＳｅｒｖｉｃｅＣｏｎｔｅｘｔ―リソースの組マッピング部の構成図である。 本発明に係るリソースの組保持部の一例を示す図である。 本発明に係るＪａｖａのクラスを示す図である。 本発明に係る映像・音声を再生するフローチャートである。 本発明に係るサービスマネージャ１７０４の構成図である。 本発明に係るＳｅｒｖｉｃｅＣｏｎｔｅｘｔ−リソースマッピング部の構成図である。 本発明に係るリソース保持部の一例を示す図である。 本発明に係るＪａｖａのクラスを示す図である。 本発明に係る映像・音声を再生するフローチャートである。 本発明に係るＪａｖａライブラリ１７０５の構成図である。 本発明に係るＪａｖａのクラスと物理的なリソースの関係を示した図である。 本発明に係るディスプレイ５０９の表示の一例を示す図である。 本発明に係るＪａｖａのクラスを示す図である。 本発明に係るＪａｖａのクラスを示す図である。 本発明に係る表示デバイスの構成図である。 本発明に係るＪａｖａのクラスを示す図である。 本発明に係るＪａｖａのクラスを示す図である。 本発明に係るＥＰＧを示す図である。

符号の説明

１７０１ ＯＳ
１７０２ サービス再生部
１７０３ ＪａｖａＶＭ
１７０４ サービスマネージャ
１７０５ Ｊａｖａライブラリ
１７０５ａ ＪＭＦ
２００１ ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ管理部
２１０８ Ａｂｓｔｒａｃｔサービス用ＳｅｒｖｉｃｅＣｏｎｔｅｘｔ
５７０１ サービス実行部
５７０２ リソースの組保持部
６１１２ メソッド

Claims (5)

1. １または複数のリソースを使用するサービスを実行するためのサービス実行環境において前記サービスを実行するサービス実行手段と、
   アプリケーションが前記サービス実行手段に対してサービスの実行を要求した際に、前記サービス実行環境と前記サービスが使用する１または複数のリソースを示すリソース組情報とを関連付ける関連付け手段と、
   前記関連付け手段により関連付けられた前記サービス実行環境と前記リソース組情報とを保持する保持手段と、
   前記保持手段により保持されたサービス実行環境において、前記保持手段に保持された前記リソース組情報を前記サービスに供給するリソース管理手段と
   を備えることを特徴とするサービス実行装置。
2. 前記リソース管理手段は、前記サービス実行環境に関連付けられた前記リソース組情報を取得し、取得した前記リソース組情報を前記サービスに供給する
   ことを特徴とする請求項１記載のサービス実行装置。
3. 前記リソースは選局手段であることを特徴とする請求項１記載のサービス実行装置。
4. １または複数のリソースを使用するサービスの実行がアプリケーションから要求された際に、前記サービスを実行するためのサービス実行環境と、前記サービスが使用する１または複数のリソースを示すリソース組情報とを関連付ける関連付けステップと、
   前記関連付けステップで関連付けられた前記サービス実行環境と前記リソース組情報とを記憶媒体に格納する格納ステップと、
   前記記憶媒体に格納された前記サービス実行環境において、前記記憶媒体に格納された前記リソース組情報を前記サービスに供給するリソース管理ステップと
   前記リソース管理ステップで供給されたリソース組情報により示される１または複数のリソースを使用することにより、前記サービス実行環境において前記サービスを実行するサービス実行ステップと
   を含むことを特徴とするサービス実行方法。
5. １または複数のリソースを使用するサービスの実行がアプリケーションから要求された際に、前記サービスを実行するためのサービス実行環境と、前記サービスが使用する１または複数のリソースを示すリソース組情報とを関連付ける関連付けステップと、
   前記関連付けステップで関連付けられた前記サービス実行環境と前記リソース組情報とを記憶媒体に格納する格納ステップと、
   前記記憶媒体に格納された前記サービス実行環境において、前記記憶媒体に格納された前記リソース組情報を前記サービスに供給するリソース管理ステップと
   前記リソース管理ステップで供給されたリソース組情報により示される１または複数のリソースを使用することにより、前記サービス実行環境において前記サービスを実行するサービス実行ステップと
   をコンピュータに実行させることを特徴とするプログラム。

Images