JP2001028571A

JP2001028571A - 放送システムによって提供される情報サービスにアクセスするアプリケーションプログラミングのインターフェース装置

Info

Publication number: JP2001028571A
Application number: JP2000137169A
Authority: JP
Inventors: Ralf Schafer; シェーファーラルフ; Rudolf Bittner; ビットナールドルフ
Original assignee: Sony International Europe GmbH
Current assignee: Sony Deutschland GmbH
Priority date: 1999-04-30
Filing date: 2000-05-01
Publication date: 2001-01-30
Anticipated expiration: 2020-05-01
Also published as: JP4590062B2; EP1049278A1

Abstract

(57)【要約】【課題】情報サービスにアクセスするアプリケーショ
ンプログラミングのインターフェース装置を提供する。【解決手段】要求サブインターフェース１６は、クラ
イアント４によって要求されるＡＰＩ１２内のアプリケ
ーションプログラム４、クライアント登録ブロック５、
サービスディレクトリブロック６、放送ソース選択ブロ
ック７、サービス選択ブロック８、サービスアクセスブ
ロック９、受信品質ブロック１０、サービススキャンブ
ロック１１の全ての機能を定義する。ＡＰＩ１２は、ク
ライアント４がＡＰＩ１２から情報を得るための確認通
知サブインターフェース１７を定義をする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、デジタル放送シス
テムによって提供される情報サービスを利用するための
アプリケーションのインターフェースに関する。特に、
本発明は、放送システムにおける受信機を制御するとと
もに、放送信号のチャンネルで搬送されるコンテンツへ
のアクセスを提供するアプリケーションプログラミング
のインターフェース装置（以下、ＡＰＩと称する）に関
する。

【０００２】

【従来の技術】以下、本発明の背景について、ＤＡＢ規
格「無線放送システム：移動、携帯及び固定受信機に対
するデジタル音声放送（ＤＡＢ）（Radio broadcasting
systems: Digital Audio Broadcasting (DAB) to mobi
le, portable, and fixed receivers）」、ETSI, ETS 3
00 401, １９９７年５月、第２版を例として説明する。
ＤＡＢ規格は、送信側から任意数の受信側への種々の情
報サービスの送信をサポートするデジタル放送システム
を実現するための国際規格である。この情報サービスの
例としては、オーディオストリームアプリケーション、
ビデオストリームアプリケーション、ハイパーテキスト
アプリケーション、画像又はテキストスライドショーア
プリケーション、ニュースティッカアプリケーション、
Ｊａｖａベースアプリケーション等がある。

【０００３】１つのＤＡＢ放送信号によって、約１．５
Ｍｂｉｔ／ｓの速度で伝送されている情報に同時にアク
セスすることができる。このような信号はアンサンブル
と呼ばれる。１つのＤＡＢ受信機は、同じ位置において
２以上のアンサンブルを受信することができるが、一度
には１つしか受信することができない。各アンサンブル
は、１つのサービスのみ又は多数のサービスを有するＤ
ＡＢ信号を表している。アンサンブルは、異なる種類の
アプリケーションを有するサービスを組み合わせること
ができる。一般的な例として、幾つかのラジオ局（オー
ディオストリームアプリケーション）と、ハイパーテキ
ストアプリケーション又はスライドショーとして提供さ
れる気象、金融、イベント、ニュース等の情報サービス
とにアクセスするアンサンブルがある。一般的に、これ
らの全てのサービスは、同一のアンサンブルに属してい
るときは、同時にアクセスすることができる。

【０００４】図１５は、放送のソース信号の１タイムフ
レームの一般的な構造を示すフォーマットである。この
タイムフレームは、ある周期、例えば２４ｍｓで繰り返
される。タイムフレームは、同期チャンネル１、サービ
ス情報チャンネル２、所定数（Ｎ）のサービスチャンネ
ル３（サービス＃１〜＃Ｎ）によって構成される。デジ
タル放送システムの受信機は、同期チャンネル１を用い
て信号の同期をとる。サービス情報チャンネル２は、利
用可能なサービスの数、これらのサービスによって提供
される情報の種類、これらのサービスへのアクセス方法
についての情報を提供する。各サービスチャンネル３
は、サービスデータを提供する。通常、これらのデータ
は、データ放送に適したフォーマットに符号化されてい
る。

【０００５】ＤＡＢシステムは、固定、携帯、移動の各
環境において受信できるように設計されている。特に、
移動環境では、受信状態が刻々変化する。受信品質は、
受信障害のない状態、時折受信障害が発生する状態、全
く受信できない状態等の様々である。ハードウェア又は
ソフトウェアのアプリケーションは、これらの様々な状
態に対応しなければならない。受信障害は、移動環境に
おいては一般的に発生し、その障害がユーザに感知され
ないようにしなければならない。各受信障害をエラーと
して取り扱うのは適切ではない。したがって、アプリケ
ーションには、受信状態に適切に対応できるように、受
信状態を監視する手法を設ける必要がある。

【０００６】双方向通信環境では、クライアントがある
情報を要求する。配信される情報は、クライアントとサ
ーバ間の現在のコンテキストの状態によって識別され
る。一方、一方向放送環境では、多数のクライアントの
ための情報が伝送される。したがって、データは、関係
がある情報のみを抽出するために、自己記述的でなけれ
ばならない。この情報は、全体としてサービスに関する
ものであれば、一般的にサービス情報チャンネル２で配
信され、各サービスの情報オブジェクトのいずれかに関
するものであれば、サービスチャンネル３のうちの１つ
で配信される。各サービスチャンネル３は、配信される
情報に対してシステム固有のフォーマットを用いる。

【０００７】

【発明が解決しようとする課題】本発明は、上述した実
情に鑑みてなされたものであり、システム固有の符号化
方式をわからせずに、またシステムに依存せずに、情報
をアプリケーションに配信するために、情報サービスに
アクセスするアプリケーションプログラミングのインタ
ーフェース装置を提供することを目的とする。

【０００８】

【課題を解決するための手段】本発明の目的は、請求項
１に記載するアプリケーションプログラミングのインタ
ーフェース装置及び請求項３１に記載するクライアント
によって達成することができ、その好適な実施例につい
ては、それぞれ従属する請求項に定義される。

【０００９】本発明を適用したＡＰＩ及びクライアント
は、一方向放送受信機のクライアント／放送受信機イン
ターフェースに対して双方向通信環境の機能を実現す
る。これは、クライアントが、ＡＰＩの全機能を定義す
るＡＰＩの独自要求サブインターフェースを介してＡＰ
Ｉに要求を送ることができ、また、ＡＰＩが、ＡＰＩに
よって定義される確認通知サブインターフェースを介し
て、要求された情報を含むことが可能な確認及び／又は
通知メッセージをクライアントに送ることができるから
である。

【００１０】サービスのアクセス構造は、提供されるサ
ービスの種類によって異なる。ラジオ番組等のオーディ
オストリームを有するサービスの場合、送信されるデー
タは全て、アプリケーションに受信及び供給されて処理
されなければならない。ユーザが情報オブジェクト（例
えば、ハイパーテキスト）のセットを自由にナビゲート
するようなアプリケーションの場合、全ての情報が周期
的に放送され、要求された情報のみが放送から抽出され
る。典型的なデータの流れを図１６に示す。図１６で
は、ある文書、すなわち、default.html、pic1.jpg、xy
z.html、pic2.jpg、News.html、abc.htmlが周期的に放
送される。一連の画像又はテキストをユーザに提供する
スライドショーアプリケーションの場合、受信障害に対
処するため、情報を提供すべきときに送信するか、ある
いは、予め何度か情報を送信しておく。これらの場合、
アプリケーション処理に対するサポートが与えられれ
ば、アプリケーションプログラマ又は設計者が行う作業
は簡単になる。

【００１１】ハイパーテキストアプリケーションでは、
あるＨＴＭＬページを参照するリンクがクリックされた
後に、このページの要求がＡＰＩに与えられる。本発明
を適用したＡＰＩの基礎となるシステムは、このページ
に対するフィルタを設定し、それが放送されるまで聴
く。受信後は、このページはアプリケーションに提供さ
れる。受信後に要求を取り消してもよく、ＡＰＩは、放
送を聴いて要求されたページの更新をアプリケーション
に通知することができる。ＡＰＩによって供給されるこ
のアプリケーション処理サポートは、２以上のアプリケ
ーションが同時にサービスにアクセスしているときや、
キャッシュを考慮するときに特に有用である。後者の場
合、アクセス時間を改善するため、受信したオブジェク
トのコピーを記憶するためにメモリが使用される。した
がって、基礎となるＡＰＩがサービスのアクセスを提供
すれば、アプリケーションにとっては得である。

【００１２】本発明は、放送システムによって提供され
る情報にアクセスするためのアプリケーションプログラ
ミングのインターフェース装置を提供することがわか
る。これは、いわゆるハイレベルＡＰＩであり、コマン
ドとして表す概念がアプリケーションプログラマ又は設
計者のニーズを反映するようにされたものである。この
分野のアプリケーションプログラマ又は設計者の作業
は、情報サービスを魅力的なものとして提供することで
ある。このため、アプリケーションプログラマ又は設計
者は、不要なシステム固有の詳細事項に関心を持たな
い。本発明によれば、ハイレベルＡＰＩによって双方向
通信環境が形成されるので、アプリケーションの開発時
間が改善され、第三者によるアプリケーション形成の許
容が増す。

【００１３】さらに、ＡＰＩは、放送システムによって
提供される情報サービスへのアクセスの全ての面を含
む。すなわち、放送媒体及び提供されるサービスのコン
テンツ自体へのアクセスを得るのに必要なデジタル放送
システムの受信機を制御する。

【００１４】放送システムでは、クライアントは送信装
置において必要な情報を要求しない。その代わり、受信
機で何が放送されるか聴き、所望の情報を抽出する必要
がある。一般に、放送信号の構成はいつでも変化する可
能性があり、情報オブジェクトへのアクセス時間は、双
方向通信に基づく情報システムにおけるよりも大きく変
化する可能性がある。これらの要件は、放送システム固
有のものである。本発明を適用したＡＰＩによって、こ
れらの詳細事項はアプリケーションプログラマにとって
問題とはならず、異なる提供フォーマットでの情報サー
ビスの処理をサポートする。本発明を適用したＡＰＩに
接続されたクライアントは、必要な情報を要求すること
ができ、この情報が利用可能になると直ちに要求してい
るクライアントに提供される。ＡＰＩのインターフェー
スは、アプリケーションプログラムとＡＰＩによって制
御される放送システムとの高度のシステム始動通信に非
常に良く合致する非同期メッセージ通信に基づくもので
ある。

【００１５】ＡＰＩは、幾つかのクライアントに対する
サポートを同時に提供する。すなわち、２以上のクライ
アントがＡＰＩのサービスを使用することによって、リ
ソースを共有することができる。

【００１６】以下の本発明の詳細な説明では、本発明を
適用したＡＰＩがＡＰＩの機能に関して非常に記述的で
あるＣ／Ｃ＋＋言語ソリューションで実現されるような
ＤＡＢ受信機を用いて説明を行う。勿論、本発明は、他
の放送システムに適用することもでき、例えばＡＰＩの
ハードウェアソリューション等の他のソリューションを
有することもできる。

【００１７】例におけるデジタル放送システムの受信機
の制御の機能的分解は、以下のようになる。すなわち、
放送ソースの選択、サービス情報チャンネルへのアクセ
ス、サービスの選択、サービスコンテンツへのアクセ
ス、受信状態の監視である。

【００１８】デジタル放送システムの受信機の制御は、
通信がサービスプロバイダからサービス消費者への一方
向のみであることを示す。受信機は、何が放送されるか
常に聴き、所望の情報を抽出しなければならない。放送
データに変更があれば、放送を聴くことによって検知さ
れる。新たなサービスを追加することも、サービスを削
除することもできる。あるサービスデータの流れにおけ
るオブジェクトの追加、削除、更新を行うこともでき
る。データの流れで放送されるオブジェクトへのアクセ
ス時間は、数ミリ秒〜数分と広範囲で変化する。本発明
を適用したＡＰＩでは、これをメッセージベースアプロ
ーチによって考える。

【００１９】

【発明の実施の形態】以下、本発明に係るアプリケーシ
ョンプログラミングのインターフェース装置及びその使
用方法について、図面を参照しながら説明する。図１
は、幾つかのアプリケーションプログラムを含む本発明
を適用した具体的なモデルを示すブロック図である。

【００２０】図１に示すように、アプリケーションプロ
グラム４（以下、ＡＰＩクライアントともいう。）は、
ＡＰＩ１２を用いてユーザに放送情報サービスを提供す
る。ＡＰＩ１２自体は、例えばアンテナ１４を備えるデ
ジタル放送システム受信機１３を介して、受信機制御ブ
ロック１８により放送データにアクセスする。ＡＰＩ１
２自体の典型的な構造は以下のようになる。受信機制御
ブロック１８は、接続されたデジタル放送システム受信
機１３のローレベル制御を行う。図１では、受信機制御
ブロック１８とデジタル放送システム受信機１３を、何
らかの手段で接続された個別のブロックとして示してい
るが、本発明は、この具体例に限定されるものではな
い。すなわち、この部分を１つのブロックに統合するこ
ともできる。本発明では、受信機制御ブロック１８の上
方に示されるビルディングブロック５〜１１は全て、受
信機制御ブロック１８によって提供されるサービスに基
づくものである。

【００２１】図１に示す具体例において、ＡＰＩ１２
は、以下のビルディングブロック５〜１１を有する。

【００２２】・クライアント登録ブロック５は、ＡＰＩ
クライアントの登録サービスを提供する。ＡＰＩ１２を
使用しようとする各アプリケーションプログラム４は、
予めＡＰＩクライアントとして登録する必要がある。登
録によって、各ＡＰＩクライアントは、他のＡＰＩクラ
イアントと識別するために、全ての準逐次コマンド（su
bsequent command）で使用されるクライアントＩＤを得
る。

【００２３】・サービスディレクトリブロック６は、１
つ以上の放送ソースの利用可能なサービスに関する情報
を提供する。

【００２４】・放送ソース選択ブロック７は、放送ソー
スを直接選局する、又は放送ソースを検索する手段を提
供する。

【００２５】・サービス選択ブロック８は、サービスを
開始又は停止するのに用いられる。

【００２６】・サービスアクセスブロック９は、サービ
スのコンテンツにアクセスする手段を提供する。

【００２７】・受信品質ブロック１０は、受信品質を監
視する手段を提供する。

【００２８】・サービススキャンブロック１１によっ
て、ＡＰＩクライアントは、特定の検索領域の全ての利
用可能な放送ソースにおける全ての利用可能なサービス
を検索することができ、これによって、サービスディレ
クトリが更新されるとともに、申し込んだ情報に関する
変更がＡＰＩクライアントに通知される。

【００２９】各コマンドは、概して２つ又は３つのメッ
セージ種類に分類される。要求メッセージ(-)Reqは、Ａ
ＰＩクライアントによってＡＰＩ１２に送られ、コマン
ドの実行が要求される。確認メッセージ(-)Cnfは、ＡＰ
Ｉ１２によってＡＰＩクライアントに送られ、コマンド
の実行が確認される。通知メッセージ(-)Ntfは、長期間
継続するコマンドの経過について通知するために、又は
更新された情報を提供するために、ＡＰＩ１２によって
ＡＰＩクライアントに送られる。

【００３０】各アプリケーションプログラム４は、その
必要な情報に関する要求をＡＰＩ１２の要求サブインタ
ーフェース１６を介してビルディングブロック５〜１１
のうちの１つ又は幾つかに送り、ビルディングブロック
５〜１１のうちの１つ又は幾つかは、それらの情報を確
認通知サブインターフェース１７を介してアプリケーシ
ョンプログラム４、すなわちＡＰＩクライアントに提供
する。

【００３１】図２〜図４は、本発明を適用したこれらの
３つのメッセージの異なる組合せによって、コマンドが
形成されることを示す図である。

【００３２】図２は、Req-Cnfコマンドのパターンを示
す図であり、ステップＳ１において、要求メッセージが
ＡＰＩ１２に送られ、ステップＳ２において、コマンド
が実行され、実行結果を提供する確認メッセージがＡＰ
Ｉクライアントに送られる。

【００３３】図３は、処理に長い時間がかかるコマンド
に使用されるReq-Ntf-Cnfコマンドのパターンを示す図
である。ステップＳ３において、要求メッセージがＡＰ
Ｉ１２に送られ、ステップＳ４〜Ｓ６において、コマン
ドの実行が開始され、この具体例では、経過情報を提供
する３つの通知メッセージがＡＰＩクライアントに送ら
れ、ステップＳ７において、実行結果を提供する確認メ
ッセージがＡＰＩクライアントに送られる。

【００３４】図４は、申込サービスを提供するコマンド
に使用されるReq-Cnf-Ntfコマンドのパターンを示す図
である。この場合、ステップＳ８において、ある情報、
例えば受信品質の配信を申し込む要求メッセージがＡＰ
Ｉ１２に送られる。ステップＳ９において、ＡＰＩ１２
から、申込を確認する確認メッセージが、要求している
ＡＰＩクライアントに送られる。ステップＳ１０〜Ｓ１
２において、要求された情報自体が与えられた通知メッ
セージ、この具体例では３つの通知メッセージが送られ
る。すなわち、現在の状態を報告する通知メッセージが
最初に送られ、申し込んだ情報が変更される毎に、通知
メッセージが必ず送られる。この申込サービスは、他の
コマンド実行によって取り消されるまで継続される。な
お、現在の状態のみを要求し、必要ではないときは更新
を要求しないようにしてもよい。この場合、申込サービ
スは、関連する通知メッセージによって、要求された情
報の配信とともに自動的に取り消される。

【００３５】本明細書で用いるメッセージという用語
は、アプリケーションプログラマ又は設計者に全体とし
て利益を与えるコマンド及びコマンドの実行と区別する
必要がある。コマンドの実行は、非同期インターフェー
ス手段を得るために、ＡＰＩ１２とＡＰＩクライアント
間で送られる幾つかのメッセージに分割される。これに
よって、コマンドを同時に実行することができ、ＡＰＩ
クライアントは、長期間継続するコマンドを実行すると
きに阻止されることはない。これは、デジタル放送シス
テム受信機１３の上述した特徴に合致する。メッセージ
という用語を用いることによって、本発明の範囲を、Ａ
ＰＩ１２とＡＰＩクライアントをメッセージシステムに
よって接続した具体例に限定するものではない。

【００３６】図５は、以下、本発明の説明に用いるＡＰ
Ｉ１２とＡＰＩクライアント１５をインターフェースさ
せる適切なモデルを示す図である。インターフェース
は、ＡＰＩ１２によって定義されるが、要求インターフ
ェース１６は、ＡＰＩ１２内に設けられ、確認通知イン
ターフェース１７は、ＡＰＩクライアント１５に設けら
れる。以下の実施例では、機能エントリポイントを有す
るインターフェースとして各インターフェースを実現し
ている。すなわち、メッセージ毎に１つの機能が設けら
れ、ＡＰＩクライアント１５によって要求メッセージの
ために呼び出されるとともに、ＡＰＩ１２によって確認
及び通知メッセージのために呼び出される。

【００３７】以下のＡＰＩの説明は、記述的Ｃ／Ｃ＋＋
プログラム言語（descriptive c/c++ program languag
e）で表記するが、これは、本発明の範囲を限定するも
のではない。上述のように、Ｊａｖａ、パスカル、ベー
シック等の他のプログラミング言語や、ハードウェアソ
リューションを用いることもできる。

【００３８】説明では、以下に示すＡＰＩ表記（conven
tion）を適用する。

【００３９】接尾辞としての大文字Ｅは、列挙型（enum
eration type）を表す。列挙型によって、異なる定数値
についての幾つかのシンボル名（symbolic name）を定
義することができる。

【００４０】接尾辞としての大文字Ｔは、データタイプ
を表す。データタイプ（data type）は、変数の値のみ
を記憶する手段を有するタイプ、又はある処理を行う機
能をさらに含むタイプである。

【００４１】接尾辞としての大文字ＰＴは、データタイ
プについてのポインタを表す。

【００４２】あるデータタイプの変数は、そのデータタ
イプを示すために接頭辞を有している。小文字ｅは、列
挙型の変数を表す。小文字ｂは、タイプブール（type b
ool）の変数を表す。本発明のドメイン（domain）に関
して定義される他のデータタイプを、小文字ｔで表す。
機能シグネチャ（function signature）における形式パ
ラメータ（formal parameter）として用いられる変数
は、下線が付された第１文字（first character）を有
する。

【００４３】以下の基本データ構造は、ＡＰＩを介して
用いられるものである。

【００４４】ResultE：コマンド実行状態が報告される
ときに必ず使用される。この種類のマッピングは、ＡＰ
Ｉ１２が用いられる基本システムによって異なる。概し
て、列挙型として用いられ、異なる定数値について幾つ
かのシンボル名を定義することができる。各値は、別の
コマンド実行状態を表す。共通の値のセットを以下のよ
うに定義する。

【００４５】resOK：コマンドの実行は成功した。

【００４６】resInvalidParameter：無効パラメータの
ためにコマンドは実行できなかった。

【００４７】resNonApplicableFunction：現在の状態で
はコマンドは実行できない。

【００４８】これらは、単に基本的なエラーコードのセ
ットの具体例である。放送情報システムでは、このセッ
トを、何ら発明的技術を用いずに、システムの能力に応
じてより詳細なエラーコードによって、容易に拡張する
ことができる。

【００４９】ClientIdT：ＡＰＩクライアント１５のＩ
Ｄのデータタイプとして使用される。このデータタイプ
の内部構造は、実際の実現方法に依存する。このデータ
タイプは、ＡＰＩ１２の基本システムによって定義され
る。各ＡＰＩクライアント１５は、ＡＰＩ１２と接続す
るときにこのデータタイプのＩＤを取得して、全ての準
逐次コマンドに対して異なるＡＰＩクライアント１５を
識別するのに用いられる。

【００５０】ServiceIdT：放送情報サービスのＩＤのデ
ータタイプとして使用される。このデータタイプの内部
構造は、実際の実現方法に依存する。このデータタイプ
は、ＡＰＩ１２の基本システムによって定義される。サ
ービスは、サービスディレクトリブロック６によって提
供されるサービスディレクトリによって、サービスＩＤ
及び他の属性とともに報告される。ＡＰＩクライアント
１５は、サービスＩＤを用いてサービスに対する情報を
得て、サービスの開始又は停止を行う。

【００５１】ObjectIdT：例えば、ハイパーテキストペ
ージ、イメージ等の情報オブジェクトのＩＤのデータタ
イプとして使用される。このデータタイプの内部構造
は、実際の実現方法に依存する。このデータタイプは、
ＡＰＩ１２の基本システムによって定義される。オブジ
ェクトＩＤは、ＡＰＩクライアント１５によってオブジ
ェクトの提供を要求したり、提供されたオブジェクトを
識別するのに使用される。

【００５２】ObjectT：ある情報オブジェクトのコンテ
ンツや、ある画像の有効期限又はテキスト記述等のオブ
ジェクトに関する追加的な属性にアクセスするデータタ
イプとして使用される。このデータタイプの内部構造
は、実際の実現方法に依存する。このデータタイプは、
ＡＰＩ１２の基本システムによって定義される。各オブ
ジェクトはオブジェクトＩＤによって識別される。

【００５３】bool：値を真及び偽とすることができる演
算データタイプ（boolean data type）。

【００５４】以下の機能シグネチャにおけるパラメータ
の中には、イタリック体で記述されるものがある。これ
らのパラメータは、ＡＰＩ１２の基本システムと強い関
連がある。すなわち、これらのデータタイプの詳細な定
義は、基本システムに強く依存し、この記述では定義で
きない。ある放送システムがビットエラーレートを監視
する手段を提供し、他のシステムが同期状態を監視する
手段を提供し、さらに他のシステムがこれらの組合せ又
は他のパラメータを監視する手段を提供することがあ
る。システム専用の要件をマップする適切な方法は、１
又は２以上のパラメータを使用することである。このよ
うな場合、正確なデータタイプの定義を付ける必要性が
あることを示すために、あるパラメータをイタリック体
で記述する。当該技術分野の技術者にとっては、本発明
の主旨を逸脱しない範囲でコマンドメッセージの定義を
変更してもよいことは明らかである。

【００５５】以下の具体例は、要求インターフェース１
６と確認インターフェース１７のインターフェースの定
義を示すものでる。

【００５６】

【表１】

【００５７】

【表２】

【００５８】

【表３】

【００５９】

【表４】

【００６０】

【表５】

【００６１】

【表６】

【００６２】

【表７】

【００６３】ＡＰＩクライアント１５とＡＰＩ１２の２
つのインスタンス（instance）は、これらのインターフ
ェースを介して接続される。すなわち、ＡＰＩ１２は、
要求インターフェース１６を実現し、ＡＰＩクライアン
ト１５は、この要求インターフェース１６用い、要求イ
ンターフェース１６のインターフェース機能を呼び出す
ことによってＡＰＩ１２に要求メッセージを送る。ＡＰ
Ｉクライアント１５は、確認インターフェース１７を実
現し、ＡＰＩ１２は、確認インターフェース１７を用
い、確認通知インターフェース１７のインターフェース
機能を呼び出すことによってＡＰＩクライアント１５に
確認及び通知メッセージを送る。

【００６４】以下、全てのコマンド及びメッセージの機
能について詳細に説明する。コマンドとメッセージを使
用する典型的な例を、メッセージシーケンスチャートに
示す。なお、これらのチャートは、誤動作を考慮してい
ない単純なシナリオを示すものである。記述したコンテ
キストにおいて重要なパラメータのみを列挙する。

【００６５】クライアント登録ＡＰＩ１２を使用しようとするアプリケーションプログ
ラムはいずれも、図６に示すように、他のコマンドを実
行する前にＡＰＩクライアント１５としてＡＰＩ１２に
接続する必要があり、また、ＡＰＩコマンドの使用が終
わると切断する必要がある。このような登録及び切断
は、クライアント登録ブロック５を介して行われる。Op
enコマンドは、ＡＰＩクライアント１５を登録し、必要
な全てのリソースを割り当て、全ての準逐次コマンドに
使用されるクライアントＩＤを与える。ＩＤは、２つ以
上のＡＰＩクライアント１５が同時にＡＰＩ１２を用い
る場合に必要である。Openコマンドは、OpenReq及びOpe
nCnfメッセージによって構成される。Closeコマンド
は、動作している全てのサービスを停止し、呼出を行っ
ているＡＰＩクライアント１５のために取得されたリソ
ースを解放し、ＡＰＩクライアント１５とＡＰＩ１２を
切り離す。また、ＡＰＩコマンドを実行するためには、
Openコマンドを予め実行する必要がある。Closeコマン
ドは、CloseReq及びCloseCnfメッセージによって構成さ
れる。ＡＰＩクライアント１５は、OpenコマンドとClos
eコマンドの間に、ＡＰＩ１２を介してデジタル放送シ
ステム受信機１３の制御を行うか、あるいは単に提供さ
れるサービスを「聴く」、すなわちコマンドを実行する
ことができる。

【００６６】Open及びCloseコマンドメッセージ機能の
インターフェースは、以下のように定義される。

【００６７】

【表８】

【００６８】まず、接続を開くために、ステップＳ４０
において、ＡＰＩクライアント１５は、OpenReqメッセ
ージをＡＰＩ１２に送り、ＡＰＩクライアント１５の確
認通知インターフェース１７に対するポインタ（_ptInt
erface）が与えられる。ＡＰＩ１２は、ＡＰＩクライア
ント１５とＡＰＩ１２間の通信で発生する全ての確認及
び通知メッセージを、この確認通知インターフェース１
７に送る。

【００６９】その後、ステップＳ４１において、ＡＰＩ
１２は、Openコマンドの処理を報告するOpenCnfメッセ
ージをＡＰＩクライアント１５に送る。パラメータ_eRe
sultは、接続を確立することができたか否かを示す。値
がresOKであるときは、接続が確立され、パラメータ_tC
lientIdによって、全ての準逐次コマンドに使用される
有効ＩＤが与えられる。パラメータ_eResultによって報
告される値が他の値であるときは、常にOpenコマンドは
失敗し、接続は確立されない。この場合、パラメータ_t
ClientIdは、有効な値を有しない。

【００７０】そして、コマンドが実行された後、ＡＰＩ
クライアント１５がＡＰＩコマンドの使用を終了する
と、ステップＳ４２において、ＡＰＩクライアント１５
は、CloseReqメッセージをＡＰＩ１２に送って、接続を
閉じる。このメッセージの唯一のパラメータは、呼出を
行っているＡＰＩクライアント１５を識別するためのク
ライアントＩＤである。そして、ステップＳ４３におい
て、ＡＰＩ１２は、CloseCnfメッセージをＡＰＩクライ
アント１５に送ることによって、Closeコマンドの処理
を報告する。パラメータ_tClientIdは、送信先のＡＰＩ
クライアント１５を識別し、パラメータ_eResultは処理
結果を示す。値がresOKであるときは接続が閉じられ、
そうでないときはエラーが発生している。

【００７１】放送ソースの選択デジタル放送システム受信機１３によって提供されるコ
ンテンツにアクセスするために、ＡＰＩクライアント１
５は、放送ソース選択ブロック７を介して放送ソースを
選択する。概して、放送ソースは直接選択することがで
きるか、あるいはデジタル放送システム受信機１３が放
送ソースを自動的に検索する何らかの手段を有してい
る。したがって、２つのコマンドが設けられている。

【００７２】Tuneコマンドは、放送ソースを直接選択す
るためのものである。ＡＰＩクライアント１５は、どこ
に放送ソースが位置するか知っており、必要なパラメー
タは、全てＡＰＩクライアント１５によって与えられる
ものとする。Tuneコマンドは、図７に示すように、Tune
Req及びTuneCnfメッセージ機能によって構成される。

【００７３】Searchコマンドは、放送ソースを検索する
ためのものである。検索方法は、例えば周波数範囲、周
波数ステップ、方向等であり、ＡＰＩクライアント１５
によって特定することができ、あるいはＡＰＩ１２によ
って自動的に行われる。検索は長時間かかるものと考え
られる。したがって、検索が継続している限り経過情報
が提供される。Searchコマンドは、図８に示すように、
SearchReq、SearchNtf、SearchCnfメッセージ機能によ
って構成される。

【００７４】Tune及びSearchコマンドメッセージ機能の
インターフェースは、以下のように定義される。

【００７５】

【表９】

【００７６】図７に示すように、ステップＳ５０におい
て、ＡＰＩクライアント１５は、Tuneコマンドを開始す
るために、TuneReqメッセージをＡＰＩ１２に送る。パ
ラメータ_tClientIdは、ＡＰＩクライアント１５を識別
するためのものである。放送ソースは、１又は幾つかの
パラメータ（BroadcastSource）によって特定される。
ＡＰＩ１２によるメッセージの受信後、特定された放送
ソースへの同調（選局）が開始される。選局が行われた
後、現在の受信品質が検出される。そして、ステップＳ
５１において、ＡＰＩ１２からＡＰＩクライアント１５
へのTuneCnfメッセージによって、コマンドの処理結果
が報告される。これは、送信先のクライアント（_tClie
ntId）を識別し、処理結果（_eResult）を示す。処理が
成功したときは、パラメータ_eResultはresOKという値
を示すが、そうでないときはエラーが発生している。処
理結果とは独立して、現在選択されている放送ソース
（CurrentBroadcastSource）及び現在の受信品質（Rece
ptionQuality）が報告される。

【００７７】図８に示すように、ステップＳ６０におい
て、ＡＰＩクライアント１５は、Searchコマンドを開始
するため、SearchReqメッセージをＡＰＩ１２に送る。
パラメータ_tClientIdは、ＡＰＩクライアント１５を識
別するためのものである。検索方法は。１つ以上のパラ
メータ（SearchMethod）によって特定される。検索には
長時間がかかるので、ＡＰＩクライアント１５検索動作
中に経過情報を要求することもある。このため、パラメ
ータNotificationsによって、例えば各周波数ステップ
等の所望の通知の種類を特定することができるようにな
っている。

【００７８】その後、ステップＳ６１〜Ｓ６３におい
て、ＡＰＩ１２は、SearchNtfメッセージを用いて、経
過情報をＡＰＩクライアント１５に供給する。パラメー
タ_tClientIdは、送信先のＡＰＩクライアント１５を識
別するためのものである。経過情報は、１つ以上のパラ
メータ（ProgressInfo）として供給される。ステップＳ
６１において、最初に供給される通知は、検索が開始さ
れたことを示している。通知される他のイベントは、Ａ
ＰＩ１２の基本システムによって異なる。

【００７９】そして、ステップＳ６４において、ＡＰＩ
１２は、SearchCnfメッセージをＡＰＩクライアント１
５に送ることによって、検索コマンド処理の完了を報告
する。パラメータ_tClientIdは、送信先のＡＰＩクライ
アント１５を識別し、パラメータ_eResultは処理結果を
示す。値がresOKである場合、コマンドが成功し、放送
ソースが見つかっている。そうでない場合は、エラーが
発生している。いずれの場合も、現在選択されている放
送ソース（CurrentBroadcastSource）及び現在の受信品
質（ReceptionQuality）が報告される。

【００８０】放送ソースの選択とともに、ＡＰＩクライ
アント１５は、この放送ソースに属する全ての情報サー
ビスにアクセスする。別の放送ソースの情報サービスに
アクセスするには、他の放送ソースを予め選択していな
ければならない。

【００８１】受信状態の監視受信状態を監視しようとするＡＰＩクライアント１５
は、受信品質ブロック１０内で実現されるSelectRecept
ionInfoコマンドを使用する。SelectReceptionInfoコマ
ンドは、図９に示すように、SelectReceptionInfoReq、
SelectReceptionInfoCnf、ReceptionInfoNtfメッセージ
によって構成される。SelectReceptionInfoコマンド
は、受信状態に関する状態変化の申込サービスを提供す
る。すなわち、SelectReceptionInfoReq及びSelectRece
ptionInfoCnfメッセージを用いてこのサービスを申し込
むＡＰＩクライアント１５は、ＡＰＩクライアント１５
によって申込が取り消されるまで、受信状態が変化する
たびに通知メッセージReceptionInfNtfを受ける。な
お、現在の受信状態の報告を一回だけ要求することも可
能である。

【００８２】SelectReceptionInfoコマンドメッセージ
機能のインターフェースは、以下のように定義される。

【００８３】

【表１０】

【００８４】先ず、受信品質の通知を申し込むために、
ステップＳ７０において、ＡＰＩクライアント１５は、
SelectReceptionInfoコマンドを開始するためにSelectR
eceptionInfoReqメッセージをＡＰＩ１２に送る。パラ
メータ_tClientIdは、ＡＰＩクライアント１５を識別す
るためのものである。監視される情報の種類は、例えば
同期状態、ビットエラーレート、その他の基本システム
のための適切なパラメータのセット等であり、パラメー
タReceptionInfoSelectionによって特定される。監視す
るために、与えられた全てのパラメータあるいは１つの
サブセットのみを選択することも、何も選択しないこと
も可能である。パラメータ_bNoSubscriptionは、情報が
ＡＰＩクライアント１５に一回だけ供給されるか否か、
又は選択されたパラメータのうちの１つにおける各状態
変化が報告される申込サービスが開始されるか否かを特
定する。申込サービスは、初めて監視する幾つかのパラ
メータを選択することによって開始される。また、申込
サービスは、与えられたパラメータのうちの１つも選択
しないことによって停止される。監視するパラメータの
セットを変更することも可能である。

【００８５】その後、ステップＳ７１において、ＡＰＩ
１２は、SelectReceptionInfoCnfメッセージをＡＰＩク
ライアント１５に送ることによって要求を確認する。パ
ラメータ_tClientIdは、送信先のＡＰＩクライアント１
５を識別し、パラメータ_eResultは処理結果を示す。値
がresOKであるときは、コマンドは成功であり、そうで
ないときはエラーが発生している。受信状態を監視する
ための現在の選択は、パラメータCurrentReceptionInfo
Selectionによって報告される。監視を行うために、与
えられたパラメータの幾つかを選択するとき、要求され
た情報が１つのReceptionInfoNtfメッセージとして続
く。パラメータ_bNoSubscriptionを真に設定することに
よって情報を一回だけ要求したときは、その後には他の
ReceptionInfoNtfメッセージは続かない。パラメータ_b
NoSubscriptionを偽に設定することによって申込サービ
スを開始したとき、選択されたパラメータのうちのいず
れか１つの状態変化がReceptionInfoNtfメッセージによ
って報告される。

【００８６】以下、ステップＳ７２及びＳ７３におい
て、ＡＰＩクライアント１５に受信品質の変化を知らせ
続けるために、ＡＰＩ１２によってReceptionInfoNtfメ
ッセージがＡＰＩクライアント１５に送られる。パラメ
ータ_tClientIdは、送信先のＡＰＩクライアント１５を
識別するためのものである。ReceptionInfoNtfメッセー
ジは、先に監視するために選択したパラメータのうちの
１つ以上のパラメータの状態変化について報告する。パ
ラメータReceptionInfoSelectorは、どのパラメータが
更新されているのかを示す。更新された値自体は、パラ
メータReceptionInfoによって与えられる。申込サービ
スの場合、選択された全てのパラメータの初期状態が、
最初のReceptionInfoNtfメッセージによって送られる。
それ以降の全てのReceptionInfoメッセージは、選択さ
れたパラメータの状態変化についての情報を提供する。
一回のみの要求の場合、選択された全てのパラメータの
現在の状態が、最初のReceptionInfoNtfメッセージのみ
で送られる。

【００８７】そして、申込を停止するために、ステップ
Ｓ７４において、ＡＰＩクライアント１５は、SelectRe
ceptionInfoReqメッセージをＡＰＩ１２に送り、ステッ
プＳ７５において、このSelectReceptionInfoReqメッセ
ージは、SelectReceptionInfoCnfメッセージをＡＰＩク
ライアント１５に送ることによって確認される。これら
両メッセージのパラメータは、上述のようにステップＳ
７０及びＳ７１における場合と同様に定義される。

【００８８】サービスディレクトリへのアクセスサービスディレクトリブロック６によって提供されるサ
ービスディレクトリは、現在の又は他の放送ソースに属
する全ての既知のサービスについての情報を提供するた
めのものである。この情報がどの程度信頼性があるか
は、基本システムの方針（strategy）によって異なる。
利用可能なサービスについての情報は放送ソース信号で
送信されるが、一時的な受信障害やオフライン作業によ
り、サービスディレクトリブロック６によって提供され
るサービスディレクトリが常に最新なものとは限らな
い。しかし、デジタル放送システム受信機１３が接続さ
れると直ちに、情報が更新され、接続された各クライア
ント４に変更が通知される。また、放送ソース受信機が
１つである基本システムでは、他の放送ソースで発生す
る変化を監視することはできない。この情報が次に更新
されるのは、この放送ソースにアクセスしたとき、又は
Scanコマンドを実行したときである。サービスディレク
トリブロック６によって提供されるサービスディレクト
リへのアクセスは、サービスディレクトリの動的性質に
合うように離散的に行われる。これは、情報が通知メッ
セージとしてばらばらにＡＰＩクライアント１５に供給
されるSelectServiceInfoコマンドの使用による申込サ
ービスとして設計されている。例えば、新たなサービス
が利用可能である場合、そのサービスの存在及び属性が
ＡＰＩクライアント１５に報告される。スタートアップ
の直後、サービスディレクトリブロック６によって提供
されるサービスディレクトリのコンテンツが、上述の通
知メッセージ上にマップされ、その後の変更については
同様に報告される。SelectServiceInfoコマンドは、図
１０に示すように、SelectServiceInfoReqメッセージ、
SelectServiceInfoCnfメッセージ、ServiceInfoNtfメッ
セージによって構成される。

【００８９】SelectServiceInfoコマンドメッセージ機
能のインターフェースは、以下のように定義される。

【００９０】

【表１１】

【００９１】サービスディレクトリ情報を申し込むため
に、ステップＳ８０において、ＡＰＩクライアント１５
はSelectServiceInfoコマンドを開始するためのSelectS
erviceInfoReqメッセージをＡＰＩ１２に送る。SelectS
erviceInfoコマンドは、サービスディレクトリブロック
６によって提供されるサービスディレクトリにおける変
化に対して、申込サービスの開始、停止、変更を行う。
パラメータ_tClientIdは、ＡＰＩクライアント１５を識
別するためのものである。サービスディレクトリブロッ
ク６によって提供されるサービスディレクトリは、例え
ばオーディオストリームアプリケーションを有するサー
ビスや、スライドショー等のデータサービスを有するサ
ービス等であり、異なるカテゴリーの情報を提供するこ
ともできる。したがって、ＡＰＩクライアント１５は、
パラメータServiceInfoSelectionを用いて、関心のある
情報の種類をカスタマイズすることができる。サポート
しなければならない最小セットのイベントは、dscServi
ceElementAdded、dscServiceElementRemoved、dscServi
ceElementChangedである。dscServiceElementAddedの値
は、新たなサービスエレメントが利用可能であることを
示す。dscServiceElementRemovedの値は、サービスエレ
メントが除去されているので利用不可能であることを示
す。dscServiceElementChangedの値は、サービスエレメ
ントの属性が変化したこと、例えば、あるサービスを記
述するテキスト情報、又は、あるサービスによって提供
される現在のコンテンツの種類を記述する情報が、コン
テンツとともに変更されていることを示す。後者の場
合、ServiceInfoNtfメッセージのパラメータServiceUpd
ateが、その変更についてより詳細に通知する。パラメ
ータServiceInfoSelectionによってどのイベントが特定
されるかに応じて、ＡＰＩ１２は、これらのイベントに
関連するServiceInfoNtfメッセージを送る。最後のパラ
メータ_bAutoDeliveryは、サービスディレクトリブロッ
ク６によって提供されるサービスディレクトリにおける
変化が、ＡＰＩクライアント１５に通知されているか
（偽に設定）、あるいは、変更された情報自体も変更通
知とともに供給されているか（真に設定）を特定する。

【００９２】その後、ステップＳ８１において、ＡＰＩ
１２は、SelectServiceInfoコマンドの処理を確認する
ために、SelectServiceInfoCnfメッセージをＡＰＩクラ
イアント１５に送る。パラメータ_tClientIdは送信先の
ＡＰＩクライアント１５を識別し、パラメータ_eResult
は処理結果を示す。値がresOKである場合はコマンドが
成功し、そうでない場合はエラーが発生している。パラ
メータCurrentServiceInfoSelectionは、サービスディ
レクトリにおける変化に対する現在の申込レベルを示
す。パラメータ_bAutoDeliveryは、サービスディレクト
リのあるエレメントに対する変化が報告されているか
（偽に設定）、あるいは、変更された情報自体も供給さ
れているか（真に設定）を示す。申込サービスが開始さ
れると、サービスディレクトリブロック６によって提供
されるサービスディレクトリに知られている全ての情報
が、ServiceInfoNtfメッセージとして供給される。

【００９３】利用可能なサービスをＡＰＩクライアント
１５に通知し続けるため、ステップＳ８２〜Ｓ８７にお
いて、ＡＰＩ１２によってServiceInfoNtfメッセージが
ＡＰＩクライアント１５に送られる。パラメータ_tClie
ntIdは、送信先のＡＰＩクライアント１５を識別するた
めのものである。申込サービスの開始直後、ＡＰＩクラ
イアント１５による選択と一致するサービスディレクト
リの完全なコンテンツがServiceInfoNtfメッセージ上に
マップされ、ＡＰＩクライアント１５に供給される。そ
の後、ServiceInfoNtfメッセージを送ることによって、
サービスディレクトリに対する変更のみが報告される。
パラメータ_tServiceIdは、サービスディレクトリブロ
ック６によって提供される変更されたサービスディレク
トリのサービスエレメントを識別するためのものであ
る。パラメータServiceInfoSelectorは、この通知の理
由となるイベントを特定する。サポートされるイベント
セットは、ＡＰＩ１２の基本システムによって異なる
が、少なくとも上述のイベントdscServiceElementAdde
d、dscServiceElementRemoved、dscServiceElementChan
gedをサポートする必要がある。パラメータServiceUpda
teは、dscServiceElementAddedのイベントの場合、サー
ビスエレメントのうちのどのオプショナル部分について
知られているかを示し、dscServiceElementChangedのイ
ベントの場合、サービスエレメントのうちのどの部分が
変化したかを示す。パラメータServiceInfoObjectは、
変更された情報オブジェクト自体を有する。これは、Se
lectServiceInfoReqメッセージにおけるパラメータ_bAu
toDeliveryを特定することによって申込サービスがこの
モードで設定されている場合のみ、供給される。そうで
ない場合、情報オブジェクトを取得するために追加コマ
ンドを実行しなければならない。

【００９４】このため、コマンドGetServiceInfoが設け
られている。これは、GetServiceInfoReqメッセージとG
etServiceInfoCnfメッセージによって構成される。

【００９５】GetServiceInfoコマンドメッセージ機能の
インターフェースは、以下のように定義される。

【００９６】

【表１２】

【００９７】ＡＰＩクライアント１５は、GetServiceIn
foコマンドを開始するためにGetServiceInfoReqメッセ
ージをＡＰＩ１２に送る。GetServiceInfoコマンドは、
特定されたサービスエレメントについての情報の提供を
要求する。パラメータ_tClientIdは、ＡＰＩクライアン
ト１５を識別するためのものである。サービスエレメン
トは、パラメータ_tServiceIdによって識別される。

【００９８】ＡＰＩ１２は、GetServiceInfoCnfメッセ
ージをＡＰＩクライアント１５に送ることによって要求
を確認する。パラメータ_tClientIdは送信先のＡＰＩク
ライアント１５を識別し、パラメータ_eResultは処理結
果を示す。値がresOKである場合、コマンドは成功であ
り、そうでない場合はエラーが発生している。パラメー
タServiceInfoObjectは、要求された、サービスエレメ
ントを表す情報オブジェクトを有する。このオブジェク
トの完全な定義は、ＡＰＩ１２を介してアクセスされる
基本システムによって異なる。

【００９９】そして、申込を停止するため、ステップＳ
８８において、ＡＰＩクライアント１５は、SelectServ
iceInfoReqメッセージをＡＰＩ１２に送り、これが、ス
テップＳ８９において、ＡＰＩ１２からSelectServiceI
nfoCnfメッセージをＡＰＩクライアント１５に送ること
によって、確認される。これら両メッセージのパラメー
タは、上述のように、ステップＳ８０及びＳ８１におけ
る場合と同様に定義される。

【０１００】サービスの選択サービスのコンテンツにアクセスするには、予めサービ
スを開始しておく必要がある。ＡＰＩ１２の基本システ
ムのサービス選択ブロック８は、必要とされるリソース
を割り当て、このサービスで何が放送されるのか聴取を
開始する。要求されたオブジェクトのＡＰＩクライアン
ト１５によるアクセス時間を改善するため、放送オブジ
ェクトをメモリに記憶するキャッシュ技術を用いてもよ
い。

【０１０１】ＡＰＩクライアント１５は、SelectServic
eコマンドを用いてサービスの開始又は停止を行う。Sel
ectServiceコマンドは、図１１に示すように、SelectSe
rviceReqメッセージ、SelectServiceCnfメッセージ、Se
rviceInfoNtfメッセージによって構成される。各サービ
スは、そのサービスＩＤによって識別される。ＡＰＩク
ライアント１５は、サービスディレクトリブロック６に
よって提供されるサービスディレクトリにアクセスする
ことによって、サービスについて知る。サービスの開始
及び停止に加えて、１コマンドで現在動作している全て
のサービスを停止させるとともに新たなサービスを開始
することもサポートされる。放送システムでは、サービ
スを終了することは常に可能である。これは、ServiceI
nfoNtfメッセージによってＡＰＩクライアント１５に知
らされる。すなわち、サービスの終了が報告され、サー
ビスが現在選択されている場合、関連するServiceInfoN
tfメッセージの供給とともに自動的に停止する。

【０１０２】SelectServiceコマンドメッセージ機能の
インターフェースは、以下のように定義される。

【０１０３】

【表１３】

【０１０４】サービスを開始するのに、ステップＳ９０
において、ＡＰＩクライアント１５は、SelectService
コマンドを開始するためにSelectServiceReqメッセージ
をＡＰＩ１２に送る。パラメータ_tClientIdは、ＡＰＩ
クライアント１５を識別するためのものである。サービ
スは、パラメータ_tServiceIdによって識別される。パ
ラメータ_eSelectionModeは、特定されたサービスの選
択モードを特定する。以下のモードがサポートされる。
dscReplaceの値は、現在動作している全てのサービスを
停止させ、パラメータ_tServiceIdによって特定される
サービスを開始する。dscAddの値は、パラメータ_tServ
iceIdによって特定されるサービスを開始し、現在開始
されている全てのサービスについてはそのままにしてお
く。dscRemoveの値は、パラメータ_tServiceIdによって
特定されるサービスのみを停止させる。dscRemoveAllの
値は、開始された全てのサービスを停止させる。この最
後の場合、パラメータ_tServiceIdは意味を持たない。

【０１０５】そして、ステップＳ９１において、ＡＰＩ
１２は、SelectServiceCnfメッセージを送ることによっ
てコマンドの処理を確認する。パラメータ_tClientIdは
送信先のＡＰＩクライアント１５を識別し、パラメータ
_eResultは処理結果を示す。値がresOKである場合、コ
マンドは成功であり、そうでない場合はエラーが発生し
ている。パラメータ_tServiceIdは、パラメータ_eSelec
tionModeによって特定される選択モードに従って選択さ
れたサービスを識別するためのものである。パラメータ
_eSelectionModeの意味は、SelectServiceReqメッセー
ジで使用するのと同じである。

【０１０６】サービスのアクセス中、開始したサービス
を放送から除去する場合、図１０に示すステップＳ８２
〜Ｓ８７に関して説明したように、ＡＰＩ１２からＡＰ
Ｉクライアント１５にServiceInfoNtfメッセージを送る
ことによって、この変更がＡＰＩクライアント１５に通
知される。パラメータ_tClientIdは、送信先のＡＰＩク
ライアント１５を識別するためのものである。パラメー
タServiceInfoSelectorは、この場合、dscServiceEleme
ntRemovedイベントを示す。サービスエレメントは、パ
ラメータ_tServiceIdによって識別される。dscServiceE
lementRemovedエレメントが通知されたときは、パラメ
ータServiceInfoObjectは意味を持たない。

【０１０７】そして、サービスを停止するため、ステッ
プＳ９２において、ＡＰＩクライアント１５はSelectSe
rviceInfoReqメッセージをＡＰＩ１２に送り、これが、
ステップＳ９３において、ＡＰＩ１２からＡＰＩクライ
アント１５にSelectServiceInfoCnfメッセージを送るこ
とによって、確認される。これら両メッセージのパラメ
ータは、上述のステップＳ９０及びＳ９１における場合
と同様に定義される。

【０１０８】サービスへのアクセス放送サービスは、幾つかの方法で情報を提供することが
できる。以下、それら異なる方法について、アプリケー
ション種類の点から説明する。

【０１０９】ローカルインタラクティブアプリケーショ
ン：ローカルインタラクティブアプリケーションは、情
報をばらばらに供給する。例えば、ハイパーテキストア
プリケーションのユーザは、現在提供されている情報を
読み、更なる情報に対するハイパーリンクを追跡するこ
とによって、与えられた情報をナビゲートする。各ハイ
パーテキストページには、テキスト情報、異なるフォー
マットのイメージ等の埋込オブジェクト、他のハイパー
テキストページや他のフォーマットのオブジェクトへの
リンクが含まれている。放送システムでは、これらの情
報オブジェクトが周期的に送信される。現在どの情報オ
ブジェクトが必要かは、ユーザインタラクションによっ
て異なる。

【０１１０】オブジェクトの明示的要求を必要とする全
てのアプリケーションについて、ＡＰＩ１２は、サービ
スアクセスブロック９を用いて、特定された情報オブジ
ェクトの供給を要求するSelectObjectコマンドを与え
る。これは、SelectServiceコマンドを使用することに
よって関連するサービスを開始した後に、使用すること
ができる。SelectObjectコマンドは、図１３に示すよう
に、SelectObjectReqメッセージ、SelectObjectCnfメッ
セージ、ObjectNtfメッセージによって構成され、申込
サービスを提供する。一回のみの供給を要求することも
可能であり、また、更新供給のためにオブジェクトを選
択することも可能である。すなわち、オブジェクトは、
それがはじめて利用可能となった後に供給され、そのオ
ブジェクトの更新は全て、選択が取り消されるまで追加
的に報告される。オブジェクトの選択及び解放に加え
て、１コマンドで現在の全ての選択を除去するとともに
別の選択を行うことも可能である。別のパラメータによ
って、完全に受信されたオブジェクトのみが供給される
か、あるいは、部分的に供給されてもよいのかを特定す
ることができる。後者の場合、開始から完全なオブジェ
クトの既に受信されたデータが全て供給される。最初の
供給の後、何回か供給が行われる。供給毎に、供給され
るオブジェクトが少しずつ完全になる。別のパラメータ
は、この情報オブジェクトがアプリケーションにとって
どの程度重要かを示す、アプリケーションによるヒント
である。

【０１１１】スライドショーアプリケーション：スライ
ドショーアプリケーションは、アプリケーション自体に
よって予め定義された方法で情報を提供する。例えば、
ピクチャスライドショーは、提示時刻が予め決定してい
る一連の画像を提供する。ピクチャスライドショーを実
現する簡単な方法は、画像を提示すべき時に放送するこ
とである。この場合、追加信号送信は必要ない。より複
雑な方法としては、送信エラーに備えるため、提示時刻
以前に画像を数回放送する。これによって、提示時刻に
なる前に提示オブジェクトを適切に受信する可能性が高
くなる。

【０１１２】提示時刻が予め決定している全てのアプリ
ケーションについて、ＡＰＩ１２は、適切な提示時刻に
おいてオブジェクトの復号化、記憶、提示の呼出を行
う。上述のアプリケーションを有するサービスが開始し
た後、提示時刻になると、図１２に示すように、提示さ
れる各オブジェクトがObjectNtfメッセージとしてＡＰ
Ｉ１２によってＡＰＩクライアント１５に供給される。
さらに、現在提示されているオブジェクトが提示用とし
て有効でなくなったことを示すため、ObjectNtfメッセ
ージが使用される。

【０１１３】ストリーミングアプリケーション：ストリ
ーミングアプリケーションは、例えばオーディオ又はビ
デオストリーム等のアプリケーションプログラムによっ
て準備されているデコーダに永続的に供給される連続デ
ータストリームである。このアプリケーションを有する
サービスが開始された後、時間通りにデータを供給する
ことが重要である。これは、遅れたデータは役に立たな
いからである。ＡＰＩ１２は、図１２に示すように、ス
トリーミングアプリケーションに対してスライドショー
アプリケーションと同様のアプリケーション処理サポー
トを提供する。ストリーミングアプリケーションを有す
るサービスが開始されると、連続データストリームから
のデータを包含するバッファを有するObjectNtfメッセ
ージが送られる。このデータは、アプリケーションプロ
グラムのデコーダに供給されなければならない。供給に
おけるジッタを補償するため、アプリケーションは、Ob
jectNtfメッセージを記憶するのにファーストインファ
ーストアウトキューを用いてもよい。このキューが所定
のメッセージ数まで満たされてはじめて、アプリケーシ
ョンデコーダが開始する。アプリケーションデコーダ
は、１メッセージのデータを処理した後、次のメッセー
ジが入る。ＡＰＩ１２によって供給されるその後のメッ
セージはいずれも、ファーストインファーストアウトキ
ューに追加される。

【０１１４】アプリケーションのビルトイン処理実際の放送システムでは、あるアプリケーション種類用
のビルトイン処理／プロセッサが得られることがある。
例えば、ビルトインオーディオデコーダは、連続するオ
ーディオストリームアプリケーションを処理する。この
アプリケーションのビルトイン処理は、サービスの処理
の開始又は停止を行うSelectServiceコマンドを用いて
制御される。この場合、SelectObjectコマンドによるサ
ポートは不要である。サービスアクセスブロック９に含
まれるSelectObjectコマンドメッセージ機能のインター
フェースは、以下のように定義される。

【０１１５】

【表１４】

【０１１６】

【表１５】

【０１１７】図１３では、図１１で説明したように行わ
れるステップＳ１１０及びＳ１１１の、ＡＰＩクライア
ント１５からＡＰＩ１２へのSelectServiceReqメッセー
ジを有するサービスの開始、及び、SelectServiceCnfメ
ッセージを送ることによるＡＰＩ１２のコマンドの確認
の後、SelectObjectコマンドを開始することができる。

【０１１８】その後、ステップＳ１１２において、Sele
ctObjectコマンドを開始するため、ＡＰＩクライアント
１５はSelectObjectReqメッセージをＡＰＩ１２に送
る。パラメータ_tClientIdは、ＡＰＩクライアント１５
を識別するためのものである。選択されるオブジェクト
は、パラメータ_tObjectIdによって識別される。オブジ
ェクトが属しているサービスは、パラメータ_tServiceI
dによって識別される。パラメータ_eObjectSelectionMo
deは、特定されたオブジェクトの選択モードを特定す
る。以下のモードがサポートされる。dscOnceの値は、
特定されたオブジェクトの一回のみの供給を要求する。
dscUpdateの値は、選択が取り消されるまで、特定のオ
ブジェクトの供給及びオブジェクトの各更新の供給を要
求する。dscOffの値は、現存のオブジェクト選択を取り
消す。dscCacheHintの値は、このオブジェクトがＡＰＩ
クライアント１５にとってどの程度重要であるかを示す
ヒントをＡＰＩ１２に供給するためのみに、SelectObje
ctコマンドが使用されることを示す。この場合、オブジ
ェクトは供給用に選択されない。重要性は、パラメータ
CacheHintによって特定される。ハイパーテキストアプ
リケーション等の幾つかのアプリケーションでは、１コ
マンドで新たなオブジェクトを選択するとともに同じサ
ービスに属する現存の全ての選択を取り消すことが好都
合である。これは、パラメータ_bReplaceSelectionsを
使用することによってサポートされる。このパラメータ
が真に設定された場合、パラメータ_tServiceIdによっ
て特定されるサービスに属する現存の全ての選択が取り
消される。このパラメータが偽に設定された場合、現存
の全ての選択が変更されるわけではない。dscComplete
に対して設定されたパラメータ_eDeliveryModeは、選択
されたオブジェクトがオブジェクトの完全な受信後に供
給されることを示す。dscPartialに対して設定されたパ
ラメータ_eDeliveryModeは、選択されたオブジェクトを
部分的に供給してもよいことを示す。すなわち、インデ
ックス１〜ｎの範囲のバイトシーケンスからなるオブジ
ェクトについて、最初の供給では、インデックス１〜ｍ
（ｍはｎ以下）の範囲のバイトシーケンスからなる部分
的に受信されたオブジェクトが得られる。次の供給で
は、１〜ｌ（ｌはｍより大でｎ以下）のシーケンスが得
られ、同様に続く。これは、１〜ｎの範囲の全てのデー
タが供給されてオブジェクトが供給されると、終了す
る。

【０１１９】パラメータCacheHintは、ＡＰＩ１２へ
の、キャッシュを行うためのＡＰＩクライアント１５に
よるヒントを特定する。キャッシュでは、放送オブジェ
クトのコピーを記憶するため高速ローカルメモリを使用
する。これによって、要求されたオブジェクトが既にキ
ャッシュメモリに記憶されている場合、オブジェクトの
アクセス時間が改善する。パラメータCacheHintは、キ
ャッシュを行うオブジェクトを選択するためのヒントを
与える。このパラメータの正確な定義は、基本システム
によって異なる。一例としては、ＡＰＩクライアント１
５にとっての重要性が最も低い０から重要性が最も高い
１００までの範囲で優先パラメータを使用することであ
る。キャッシュのためのヒントは、各オブジェクトモー
ドdscOff、sdcOnce、dscUpdate、dscCacheについて有効
である。

【０１２０】そして、ステップＳ１１３において、ＡＰ
Ｉ１２は、SelectObjectCnfメッセージをＡＰＩクライ
アント１５に送ることによってコマンドの処理を確認す
る。パラメータ_tClientIdは送信先のＡＰＩクライアン
ト１５を識別し、パラメータ_eResultは処理結果を示
す。値がresOKである場合、コマンドは成功であり、そ
うでない場合はエラーが発生している。パラメータ_tSe
rviceIdは、選択されたオブジェクトが属しているサー
ビスを識別するためのものである。パラメータ_tObject
Idは、選択されたオブジェクトを識別するためのもので
ある。特定されたオブジェクトの現在の選択モードは、
パラメータ_eObjectSelectionModeによって与えられ
る。パラメータAccessTimeは、選択されたオブジェクト
自体がObjectNtfメッセージの使用によって与えられる
までの予想される遅延を示す、オブジェクトのアクセス
時間を与える。

【０１２１】オブジェクト及び更新を供給するため、ス
テップＳ１１４及びＳ１１５に示すように、ObjectNtf
メッセージを送ることによって、ローカルインタラクテ
ィブアプリケーション等の選択されたオブジェクト、又
は、スライドショーアプリケーション等の提示されるオ
ブジェクト、又は、ストリーミングアプリケーション等
の連続データストリームの１セグメントを有するオブジ
ェクトがＡＰＩ１２からＡＰＩクライアント１５に供給
される。パラメータ_tClientIdは、送信先のＡＰＩクラ
イアント１５を識別するためのものである。パラメータ
_tServiceIdは、オブジェクトが属しているサービスを
識別するためのものである。パラメータ_tObjectIdは、
オブジェクトを識別するためのものである。パラメータ
_eSelectionStateは、オブジェクトの現在の選択状態を
報告するものであり、ローカルインタラクティブアプリ
ケーションのみで使用される。以下の状態がサポートさ
れる。dscSelectionOKの値は、オブジェクトがこのメッ
セージとともに供給されることを示し、パラメータ_ptO
bjectによってアクセスすることができる。dscDelayed
の値は、関連するSelectObjectCnfメッセージによって
示された場合と比較して、オブジェクトの供給が遅延し
ていることを示す。この場合、パラメータ_ptObjectは
意味を持たない。

【０１２２】dscTerminatedの値は、オブジェクトが放
送されなくなり、供給することができないことを示す。
この場合、パラメータ_ptObjectは意味を持たず、この
選択は排除される。パラメータ_bCompleteObjectは、オ
ブジェクトがこのメッセージとともに完全に供給される
か部分的に供給されるかを示す。このパラメータが真に
設定された場合、完全なオブジェクトが供給される。こ
のパラメータが偽に設定された場合、上述のようにオブ
ジェクトは部分的に供給される。パラメータ_bObjectIn
validは、提示のためにアプリケーションに以前供給さ
れたスライドショーオブジェクトの提示を停止しなけれ
ばならないか否かを示す。このパラメータが真に設定さ
れた場合、オブジェクトの提示を停止しなければならな
い。例えば、画像をディスプレイから除去しなければな
らない。この場合、パラメータ_eSelectionState，_bCo
mpleteObject，_ptObjectは意味を持たない。パラメー
タが偽に設定された場合、他のパラメータの意味によっ
てメッセージの意味が決まる。

【０１２３】オブジェクトの選択を停止するために、ス
テップ１１６において、ＡＰＩクライアント１５はSele
ctObjectReqメッセージをＡＰＩ１２に送り、これが、
ステップＳ１１７において、SelectObjectCnfをＡＰＩ
クライアント１５に送ることによってＡＰＩ１２から確
認される。これら両メッセージのパラメータは、上述の
ステップＳ１１２及びＳ１１３における場合と同様に定
義される。

【０１２４】そして、サービスを停止するために、ステ
ップＳ１１８において、ＡＰＩクライアント１５は、Se
lectServiceReqメッセージをＡＰＩ１２に送り、ステッ
プＳ１１９において、ＡＰＩクライアント１５にSelect
ServiceCnfメッセージを送ることによってＡＰＩ１２か
ら確認される。これら両メッセージのパラメータは、上
述のステップＳ１１０及びＳ１１１における場合と同様
に定義される。

【０１２５】図１２では、SelectObjectコマンドを使用
せずに図１１において説明したように行われるステップ
Ｓ１００及びＳ１０１の、ＡＰＩクライアント１５から
ＡＰＩ１２へのSelectServiceReqメッセージを有するサ
ービスの開始、及び、ＡＰＩクライアント１５にSelect
ServiceCnfメッセージを送ることによるＡＰＩ１２のコ
マンドの確認の直後、スライドショーオブジェクトを供
給することもできる。この場合、ステップＳ１１４及び
Ｓ１１５について説明したように定義されるステップＳ
１０２〜Ｓ１０４に示すように、ObjectNtfメッセージ
を送ることによってＡＰＩ１２からＡＰＩクライアント
１５に情報が供給される。その後、サービスを停止させ
るため、ステップＳ１０５において、ＡＰＩクライアン
ト１５がSelectServiceReqメッセージをＡＰＩ１２に送
り、これが、ステップＳ１０６において、ＡＰＩクライ
アント１５にSelectServiceCnfメッセージを送ることに
よってＡＰＩ１２から確認される。これら両メッセージ
のパラメータは、上述のステップＳ１００及びＳ１０１
における場合と同様に定義される。

【０１２６】利用可能な全放送ソースにおけるサービス
のスキャン放送環境における利用可能な全てのサービス
の概要を得るために、Scanコマンドが設けられている。
要求インターフェース１６を介したサービススキャンブ
ロック１１へのScanコマンドの要求後、利用可能な全て
の放送ソースの検索を開始し、各放送ソースでどのサー
ビスが利用可能なのかを知るために放送ソースを１つず
つ選択する。その結果は、サービスディレクトリブロッ
ク６によって供給されるサービスディレクトリに記憶さ
れ、ＡＰＩクライアント１５がアクセスすることができ
る。コマンドの処理中は、他のサービスにはアクセスで
きないことがある。これは、接続された放送受信機１３
によって異なる。放送受信機が一時に１つの放送ソース
へのアクセスしか行わない場合、他のアクセスは不可能
である。

【０１２７】検索方法は、例えば周波数範囲、周波数ス
テップ、方向等であり、ＡＰＩクライアント１５によっ
て特定することができ、あるいはＡＰＩ１２によって自
動的に行われる。このため、スキャンが継続している限
り経過情報が与えられる。Scanコマンドは、図１４に示
すように、ScanReqメッセージ、ScanNtfメッセージ、Sc
anCnfメッセージ機能によって構成される。Scanコマン
ドが実行され、ＡＰＩクライアント１５がサービスディ
レクトリからの通知を申し込んだ場合、サービスディレ
クトリにおける変更を通知するため、ServiceInfoNtfメ
ッセージがＡＰＩ１２からＡＰＩクライアント１５に送
られる。

【０１２８】Scanコマンドメッセージ機能のインターフ
ェースは、以下のように定義される。

【０１２９】

【表１６】

【０１３０】まず、ステップＳ１２１において、ＡＰＩ
クライアント１５はScanコマンドを開始するためにScan
ReqメッセージをＡＰＩ１２に送る。パラメータ_tClien
tIdは、ＡＰＩクライアント１５を識別するためのもの
である。検索方法は、１以上のパラメータ（SearchMeth
od）によって特定される。スキャンに長時間かかること
があるので、ＡＰＩクライアント１５はスキャン動作中
に経過情報を要求してもよい。このため、パラメータNo
tificationsによって、例えば、各周波数ステップ後に
所望の通知種類を特定することができる。

【０１３１】その後、ステップＳ１２２〜Ｓ１２４に示
すように、ＡＰＩ１２はＡＰＩクライアント１５に経過
情報を供給するためにScanNtfメッセージを使用する。
パラメータ_tClientIdは、送信先のＡＰＩクライアント
１５を識別するためのものである。経過情報は、１以上
のパラメータ（ProgressInfo）として供給される。

【０１３２】そして、ステップＳ１２５において、ＡＰ
Ｉ１２は、ＡＰＩクライアント１５にScanCnfメッセー
ジを送ることによって、Scanコマンドの処理の完了を報
告する。パラメータ_tClientIdは送信先のＡＰＩクライ
アント１５を識別し、パラメータ_eResultは処理結果を
示す。値がresOKである場合、コマンドは成功であり、
放送ソースが見つかっている。そうでない場合はエラー
が発生している。いずれの場合も、現在選択されている
放送ソース（CurrentBroadcastSource）及び現在の受信
品質（ReceptionQuality）が報告される。

【０１３３】放送ソースの選択によって、ＡＰＩクライ
アント１５は、この放送ソースに属する全ての情報サー
ビスにアクセスを有する。他の放送ソースの情報サービ
スにアクセスするには、他の放送ソースを予め選択して
おく必要があるが、サービスディレクトリブロック６が
供給するサービスディレクトリによって、全放送ソース
からの全サービスについての情報を得ることができる。
これによって、ユーザに全サービスのリストを供給する
アプリケーションプログラムを形成することができる。
ユーザが、現在選択されているソースからあるサービス
を選択する場合、SelectServiceコマンドのみ実行する
必要がある。ユーザが、他の放送ソースからサービスを
選択する場合、２つの選択肢が与えられる。ＡＰＩクラ
イアント１５は、まずTuneコマンドを使用することによ
って放送ソースを選択し、次にSelectServiceコマンド
を使用することによってサービスを選択する。あるい
は、SelectServiceコマンドが他の放送ソースからのサ
ービスについて実行される場合、ＡＰＩクライアント１
５は、予めTuneコマンドを自動的に実行する。

【０１３４】本発明を、Ｃ／Ｃ＋＋言語で実現される一
実施例を用いて説明したが、これは限定ではなく、本発
明を適用したＡＰＩ１２の機能を明確に説明するために
用いたものであることは明らかである。他のプログラミ
ング言語での実現やハードウェアによる実現も可能であ
り、同様の機能を示す。ＡＰＩ１２及び／又はＡＰＩク
ライアント１５については、１つの放送受信機内で又は
別々の装置として実現することができる。これらをソフ
トウェアとして実現する場合、放送受信機内に又はそれ
ぞれの装置内に配置することができる。あるいは、放送
システムのチャンネルから、又は、放送受信機又はそれ
ぞれの装置によってアクセスすることができる他のサー
バからダウンロードすることができる。

【０１３５】以下、本発明を適用した放送ＡＰＩの典型
的な使用について、幾つかの現存の放送システムを用い
て説明する。

【０１３６】ＲＤＳ（ラジオデータシステム）を持たな
い標準ＦＭラジオは、ユーザインターフェースが１つで
ある。すなわち、ＦＭラジオへのアクセスをユーザに与
えるため、クライアントのみが放送ＡＰＩを同時に用い
ている。ＦＭラジオでは、通常、幾つかの放送ソースに
アクセスする（周波数範囲８８〜１０８ＭＨｚ）。各放
送ソースは、オーディオサービスを１つだけ提供する。
オーディオサービスの処理はビルトインで行われる。す
なわち、ＡＰＩによるサービスアクセスサポートは不要
である。放送ソースを選択すると、自動的に１つのオー
ディオサービスのみが開始するとともに（サービス選
択）、自動的にオーディオデータの処理が開始する（サ
ービスアクセス）。移動環境では、受信品質は大きく変
化する。しかし、非常に安価なものから高価なものまで
広範囲のラジオが存在する。受信品質の監視は得られる
ときもあり、得られないときもある。

【０１３７】オーディオサービスは、ＩＤ、ラベル、プ
ログラム種類等の属性を有しない。したがって、ＦＭ信
号からサービスディレクトリを作成することは不可能で
ある。

【０１３８】ＲＤＳを有するＦＭラジオは、上述のシス
テムと同じであるが、オーディオサービスについての更
なる情報を与えるためにＦＭ信号とともに送られる追加
データを有する。追加情報は、ＩＤ（Oxd999）、ラベル
（"SWF3"）、プログラム種類（"POP"）、アナウンスメ
ントサポート及びスイッチング（スポークントラフィッ
クメッセージ）、ラジオテキスト（”追加テキスト情
報”）からなる。これによって、幾つかの放送ソースを
属性とともに有するサービスディレクトリを形成するこ
とができる。これは、あるプログラム種類（"Pop"）に
合うサービスを選択するため、あるいは、ラベル（"SWF
3"、"Antenne1"）に基づく１以上のリストからサービス
を選択するのに使用することができる。一時に１つのオ
ーディオサービスしか動作しないが、ラジオテキストス
ライドショーを付加的に行うことができる。

【０１３９】通常のテレビジョン受像機は、クライアン
トが１つである。幾つかの利用可能な放送ソースから１
つの放送ソース（チャンネル）を選択することができ
る。放送ソース毎に１ビデオストリームサービスが得ら
れる。ラベル、タイム、ProgramInfo等の追加情報は、
ビデオテキストによって示される。ビデオテキストは、
テキスト情報を有するローカルインタラクティブサービ
スを提供する。ビデオ処理はビルトインで行われ、ビデ
オテキストデコーダもサポートされるならば得られる。
しかし、ページへのアクセスにはサービスアクセスブロ
ック９が必要である。サービスアクセスブロック９によ
って、ビデオテキストページをナビゲートすることがで
き、スライドショー効果はメインページ及びサブページ
に使用されることが多い。

【０１４０】固定型の動作及び／又はケーブルネットワ
ークであるため、受信状態が障害を受けることは稀であ
る。

【０１４１】チャンネルを選択するのに放送ソース選択
が必要である。これによって、自動的にビデオサービス
が開始する。ビデオテキストアクセスは、クライアント
による要求で開始する（サービス選択）。ビデオテキス
ト復号化は、より高速なアクセスを行うために予め開始
されている。

【０１４２】サービススキャンでは、全てのサービス
（ビデオストリーム及びビデオテキスト）の検索を行
い、それらを所定のボタンで自動的に記憶する。これら
のサービスをサービスディレクトリに記憶し、現在使用
されているチャンネル番号の代わりにチャンネル名リス
トを与えることも可能である。

【０１４３】例えば、いかなる種類の金融情報にもアク
セスする受信機等、特殊な受信機は、ＤＡＢ等の標準放
送システムに基づくこともできるが、特定情報へのアク
セスしか得られない。

【０１４４】放送システムの構成として幾つかの構成が
可能である。例えば、サーバＰＣに接続された１ハード
ウェア受信機と、ＰＣワークステーション上で動作する
幾つかのクライアントアプリケーションとを有し、ロー
カルネットワークを介して情報にアクセスする構成があ
る。以下に示す構成が可能である。

【０１４５】・１又は幾つかのクライアント。

【０１４６】・１又は幾つかの放送ソース。

【０１４７】・金融情報、ニューステキスト、ニュース
ティッカ、ハイパーテキスト、ニューススライドショ
ー、株データ等を有する幾つかのサービス。

【０１４８】・１放送ソースでは放送ソース選択は不要
だが、２以上では必要。

【０１４９】・２以上のサービスで異なる種類（ハイパ
ーテキスト、ニュースティッカ）の場合、サービス選択
が必要。

【０１５０】・サービスマルチプレクスは変更してもよ
い。

【０１５１】・サービスディレクトリによって柔軟なサ
ービスマルチプレクスが可能である。

【０１５２】・１放送ソースではサービススキャンは行
わない。

【０１５３】・例えば、株価を提供する場合、受信品質
の監視は重要である。

【０１５４】フルＤＡＢ及び／又はＤＶＢシステムに
は、本発明の好ましい実施例で説明したビルディングブ
ロックの全機能が含まれている。

【０１５５】一般に、放送ＡＰＩのビルディングブロッ
クには必須のものと任意のものとがあるが、これは、こ
の分野のサポートがクライアント（アプリケーション）
にとって必要／有用であるか否かに常に関連している。
例えば、１放送ソースにしかアクセスしないシステムの
場合、放送ソース選択は不要である。これは、放送ソー
スを全く選択しなくてよいということではない。１放送
ソースしか選択できず、ＡＰＩの基本システムによって
自動的に選択が行われる、ということである。

【０１５６】フルシステムにおいては、全てのビルディ
ングブロックが必要であることは明らかである。実際の
システムの制限によって、サブセットのみが必要であ
る。幾つかの簡単なシステムでは、除去することができ
るブロックもあり、合体することができるブロックもあ
るが、これは機能についてのみ有効である。ビルディン
グブロックのインターフェースを変更することが必要な
ときもある。その結果、新たなビルディングブロックが
定義される。

【０１５７】一般に、機能とそれに対応するビルディン
グブロックが必須であるか任意であるかの決定は容易に
なる。

【０１５８】・２以上の放送ソースが利用可能であると
きは必ず放送ソース選択が必要であり、選択されたいず
れの放送ソースからも全サービスがわかるわけではな
い。他の全ての放送ソースにおける全サービスについて
の情報がわかる場合、システムは、スタートアップ後に
１放送システムを選択し、利用可能な全てのサービスに
ついて情報を得る。この場合、サービス選択を行うこと
で、サービスにアクセスするのに十分である。

【０１５９】・提供されたサービスが予めわかっていな
いとき、また、提供されたサービスのセットを変更する
ことができるとき、サービスディレクトリが必要であ
る。幾つかの放送ソースがあり、選択された放送ソース
におけるサービスが限定的にしか示されていない場合、
サービスディレクトリによって、再チューニングを行わ
ずに利用可能な全サービスのリストを得ることができ
る。クライアントは、動的変更についての情報を得るこ
とができる。

【０１６０】・１放送ソースにおいて２以上のサービス
が利用可能であるとき、また、２以上のサービスを同時
に動作させるため、サービス選択が必要である。

【０１６１】・更なる処理を行うためにデータをアプリ
ケーションに供給する必要があるとき、サービスアクセ
スが必要である。

【０１６２】・受信品質が動作中に変化する可能性があ
るとき、受信品質が必要である。

【０１６３】・サービススキャンによって、サービス選
択が容易になり、良好なユーザインターフェースを形成
することができる。

【０１６４】・２以上のクライアントがＡＰＩを用いて
いるとき及び／又はインターフェーシングが必要なと
き、クライアント登録が必要である。

【０１６５】本発明を適用した放送ＡＰＩの他の適用例
として、ＡＰＩクライアント１５に限定的なアクセスの
みを提供する。すなわち、例えば、ＪａｖａＡｐｐｌｅ
ｔは完全なＤＡＢ受信機の一部賭して動作している。Ｄ
ＡＢへのアクセスは、ＤＡＢ受信機の適応部分によって
制御されるが、ＪａｖａＡｐｐｌｅｔは、例えば、ＤＡ
Ｂを介してダウンロードされ、あるデータサービスを提
示する。したがって、サービスアクセスブロック９にア
クセスする必要があり、他のブロックへのアクセスはで
きない。

【０１６６】

【発明の効果】放送システムによって提供される情報サ
ービスにクライアントがアクセスすることを可能にする
アプリケーションプログラミングのインターフェース装
置において、アプリケーションプログラミングのインタ
ーフェース装置内のビルディングブロックの情報サービ
スの処理を行う各機能を全て定義する要求サブインター
フェースを有し、ビルディングブロックは、要求サブイ
ンターフェースを介してアドレス及び／又は要求され
る。これによって、クライアントは、放送システムの詳
細を知らないでも、インターフェース装置を介して所望
の情報サービスにアクセスすることができる。

【図面の簡単な説明】

【図１】本発明を適用したＡＰＩを有するデジタル放送
システムの受信機のモデルを示すブロック図である。

【図２】本発明を適用したコマンドパターンの流れを示
す図である。

【図３】本発明を適用したコマンドパターンの流れを示
す図である。

【図４】本発明を適用したコマンドパターンの流れを示
す図である。

【図５】本発明を適用したＡＰＩ及びＡＰＩクライアン
トを示すブロック図である。

【図６】本発明を適用したクライアント登録の流れを示
す図である。

【図７】本発明を適用したチューンコマンドメッセージ
通信の流れを示す図である。

【図８】本発明を適用した検索コマンドメッセージ通信
の流れを示す図である。

【図９】本発明を適用したるselectreceptioninfoコマ
ンドメッセージ通信の流れを示す図である。

【図１０】本発明を適用したselectserviceinfoコマン
ドメッセージ通信の流れを示す図である。

【図１１】本発明を適用したselectserviceコマンドメ
ッセージ通信の流れを示す図である。

【図１２】本発明を適用したスライドショー処理の流れ
を示す図である。

【図１３】本発明を適用したハイパーテキストサービス
の流れを示す図である。

【図１４】本発明を適用したスキャンコマンドメッセー
ジ通信の流れを示す図である。

【図１５】ＤＡＢ規格による放送ソース信号のモデルを
示す図である。

【図１６】従来の放送データのオブジェクト流れを示す
図である。

【符号の説明】

４アプリケーションプログラム、５クライアント登
録ブロック、６サービスディレクトリブロック、７
放送ソース選択ブロック、８サービス選択ブロック、
９サービスアクセスブロック、１０受信品質ブロッ
ク、１１サービススキャンブロック、１２ＡＰＩ、
１３デジタル放送システム受信機

───────────────────────────────────────────────────── フロントページの続き (72)発明者ラルフシェーファードイツ連邦共和国ディー−70736 フェルバッハシュトゥットゥガルターシュトラーセ 106 ソニーインターナショナル（ヨーロッパ）ゲゼルシャフトミットベシュレンクテルハフツングシュトゥットゥガルトテクノロジーセンター内 (72)発明者ルドルフビットナードイツ連邦共和国ディー−70736 フェルバッハシュトゥットゥガルターシュトラーセ 106 ソニーインターナショナル（ヨーロッパ）ゲゼルシャフトミットベシュレンクテルハフツングシュトゥットゥガルトテクノロジーセンター内

Claims

【特許請求の範囲】

【請求項１】放送システムによって提供される情報サ
ービスにクライアントがアクセスすることを可能にする
アプリケーションプログラミングのインターフェース装
置において、当該アプリケーションプログラミングのインターフェー
ス装置内のビルディングブロックの上記情報サービスの
処理を行う各機能を全て定義する要求サブインターフェ
ースを有し、上記ビルディングブロックは、上記要求サブインターフ
ェースを介してアドレス及び／又は要求されることを特
徴とするアプリケーションプログラミングのインターフ
ェース装置。
【請求項２】上記クライアントの登録及び／又はログ
オフサービスを行うクライアント登録ビルディングブロ
ックを有することを特徴とする請求項１記載のアプリケ
ーションプログラミングのインターフェース装置。
【請求項３】上記クライアント登録ビルディングブロ
ックは、上記クライアントを識別するために、上記クラ
イアントとの各通信において使用する個々のクライアン
ト識別子を、上記クライアントに与えることを特徴とす
る請求項２記載のアプリケーションプログラミングのイ
ンターフェース装置。
【請求項４】１つ以上の放送ソースの利用可能なサー
ビスについての情報を提供するサービスディレクトリビ
ルディングブロックを有することを特徴とする請求項１
乃至３のいずれか１項記載のアプリケーションプログラ
ミングのインターフェース装置。
【請求項５】上記サービスディレクトリビルディング
ブロックは、各放送ソースにアクセスしたとき及び／又
は幾つかの受信可能な放送ソースに属する情報を収集す
るためにスキャンコマンドを実行したときにそれぞれ更
新される、現在及び／又は少なくとも１つの他の放送ソ
ースに属するサービスについての情報を提供することを
特徴とする請求項４記載のアプリケーションプログラミ
ングのインターフェース装置。
【請求項６】上記サービスディレクトリビルディング
ブロックは、接続された上記クライアントにサービス情
報の変更を通知することを特徴とする請求項４又は５記
載のアプリケーションプログラミングのインターフェー
ス装置。
【請求項７】上記クライアントが１つの放送ソースを
直接選局するする又は少なくとも１つの放送ソースを自
動的に検索することを可能にする放送ソース選択ビルデ
ィングブロックを有することを特徴とする請求項１乃至
６のいずれか１項記載のアプリケーションプログラミン
グのインターフェース装置。
【請求項８】同時に少なくとも１サービスの開始及び
／又は停止を可能にするサービス選択ビルディングブロ
ックを有することを特徴とする請求項１乃至７のいずれ
か１項記載のアプリケーションプログラミングのインタ
ーフェース装置。
【請求項９】上記サービス選択ビルディングブロック
は、同時に、現在動作中の全てのサービスの停止ととも
に新たなサービスの開始を可能にすることを特徴とする
請求項８記載のアプリケーションプログラミングのイン
ターフェース装置。
【請求項１０】上記サービス選択ビルディングブロッ
クは、上記クライアントによって選択されたサービスの
終了時に上記クライアントに情報を送ることを特徴とす
る請求項８又は９記載のアプリケーションプログラミン
グのインターフェース装置。
【請求項１１】同時にサービスの少なくとも１つのコ
ンテンツのアクセスの開始及び／又は停止を可能にする
サービスアクセスビルディングブロックを有することを
特徴とする請求項１乃至１０のいずれか１項記載のアプ
リケーションプログラミングのインターフェース装置。
【請求項１２】上記サービスアクセスビルディングブ
ロックは、同時に、サービスのコンテンツ内の現在アク
セスされている全てのオブジェクトの停止とともにサー
ビスの新たなコンテンツへのアクセスを可能にすること
を特徴とする請求項１１記載のアプリケーションプログ
ラミングのインターフェース装置。
【請求項１３】上記サービスアクセスビルディングブ
ロックは、周期的に又は繰り返し送信される情報オブジ
ェクトのうちの選択された情報を提供することによっ
て、ローカルインタラクティブアプリケーションをサポ
ートすることを特徴とする請求項１１又は１２記載のア
プリケーションプログラミングのインターフェース装
置。
【請求項１４】上記サービスアクセスビルディングブ
ロックは、受信した情報を直接提示することによって、
又は受信した情報を記憶することによって、ストリーミ
ング又はスライドショーアプリケーションをサポート
し、所定時刻に情報を提示することを特徴とする請求項
１１乃至１３のいずれか１項記載のアプリケーションプ
ログラミングのインターフェース装置。
【請求項１５】上記サービスアクセスビルディングブ
ロックは、所定のアプリケーションのビルトイン処理を
有することを特徴とする請求項１１乃至１４のいずれか
１項記載のアプリケーションプログラミングのインター
フェース装置。
【請求項１６】受信品質を監視することを可能にする
受信品質ビルディングブロックを有することを特徴とす
る請求項１乃至１５のいずれか１項記載のアプリケーシ
ョンプログラミングのインターフェース装置。
【請求項１７】上記受信品質ビルディングブロック
は、上記クライアントが申し込むことを可能にし、上記
クライアントが申込を取り消すまで、申し込んだクライ
アントに受信状態の変更がある毎に通知を行うことを特
徴とする請求項１６記載のアプリケーションプログラミ
ングのインターフェース装置。
【請求項１８】特定の検索領域の利用可能な全ての放
送ソースにおける利用可能な全てのサービスを上記クラ
イアントが検索することを可能にするサービススキャン
ビルディングブロックを有することを特徴とする請求項
１乃至１７のいずれか１項記載のアプリケーションプロ
グラミングのインターフェース装置。
【請求項１９】上記サービスビルディングブロック
は、請求項４乃至６のいずれか１つに定義されたサービ
スディレクトリビルディングブロックに含まれているサ
ービスディレクトリを更新することを特徴とする請求項
１８記載のアプリケーションプログラミングのインター
フェース装置。
【請求項２０】上記特定の検索領域は、１又は複数の
周波数範囲であることを特徴とする請求項１８又は１９
記載のアプリケーションプログラミングのインターフェ
ース装置。
【請求項２１】上記サービススキャンビルディングブ
ロックは、経過についての通知を行うことを特徴等する
請求項１８又は１９記載のアプリケーションプログラミ
ングのインターフェース装置。
【請求項２２】上記各ビルディングブロックは非同期
メッセージングに基づくことを特徴とする請求項１乃至
２１のいずれか１項記載のアプリケーションプログラミ
ングのインターフェース装置。
【請求項２３】上記クライアントが情報サービスを要
求することを可能にするコマンドは、少なくとも、上記
コマンドの実行を要求するために上記クライアントから
当該アプリケーションプログラミングのインターフェー
ス装置に送られる要求メッセージ（Req）と、上記コマ
ンドの実行を確認するために当該アプリケーションプロ
グラミングのインターフェース装置から上記クライアン
トに送られる確認メッセージ（Cnf）と有することを特
徴とする請求項１乃至２２のいずれか１項記載のアプリ
ケーションプログラミングのインターフェース装置。
【請求項２４】上記クライアントが情報サービスを要
求することを可能にするコマンドは、少なくとも、長期
間継続するコマンドの経過について通知するため、又は
上記クライアントに要求された情報を提供するために、
当該アプリケーションプログラミングのインターフェー
ス装置から上記クライアントに送られる通知メッセージ
（Ntf）を有することを特徴とする請求項２３記載のア
プリケーションプログラミングのインターフェース装
置。
【請求項２５】上記要求サブインターフェースは、機
能的要求メッセージの使用を可能にすることを特徴とす
る請求項１乃至２４のいずれか１項記載のアプリケーシ
ョンプログラミングのインターフェース装置。
【請求項２６】幾つかのクライアントの同時にサポー
トすることを特徴とする請求項１乃至２５のいずれか１
項記載のアプリケーションプログラミングのインターフ
ェース装置。
【請求項２７】１つ又は幾つかのクライアントの限定
されたサポートを提供することを特徴とする請求項１乃
至２６のいずれか１項記載のアプリケーションプログラ
ミングのインターフェース装置。
【請求項２８】受信した情報サービスのキャッシュを
行うことを特徴とする請求項１乃至２７のいずれか１項
記載のアプリケーションプログラミングのインターフェ
ース装置。
【請求項２９】上記キャッシュは、上記クライアント
によって得られる優先値によって異なることを特徴とす
る請求項２８記載のアプリケーションプログラミングの
インターフェース装置。
【請求項３０】接続された放送システムの受信機のロ
ーレベル制御を行う受信機制御ブロックを有することを
特徴とする請求項１乃至２９のいずれか１項記載のアプ
リケーションプログラミングのインターフェース装置。
【請求項３１】請求項１乃至３０のいずれか１項記載
のアプリケーションプログラミングのインターフェース
装置にアクセスすることができるクライアントにおい
て、上記アプリケーションプログラミングのインターフ
ェース装置によって定義された確認通知サブインターフ
ェースを有し、上記確認通知サブインターフェースは、
上記アプリケーションプログラミングのインターフェー
ス装置が当該クライアントに機能的確認及び／又は通知
メッセージを送ることを可能にすることを特徴とするク
ライアント。
【請求項３２】ソフトウェアプログラムとして実現さ
れていることを特徴とする請求項３１記載のクライアン
ト。
【請求項３３】上記ソフトウェアプログラムは、Ｃ／
Ｃ＋＋又はＪａｖａで実現されていることを特徴とする
請求項３２記載のクライアント。
【請求項３４】放送受信機内に設けられ、請求項３１
乃至３３のいずれか１項記載のクライアントによって使
用される請求項１乃至３０のいずれか１項記載のアプリ
ケーションプログラミングのインターフェース装置の使
用方法。
【請求項３５】放送システムのチャンネルから放送受
信機にダウンロードされ、請求項３１乃至３３のいずれ
か１項記載のクライアントによって使用される請求項１
乃至３０のいずれか１項記載のアプリケーションプログ
ラミングのインターフェース装置の使用方法。
【請求項３６】ＤＡＢ、ＤＶＢ、アナログラジオ又は
アナログテレビジョン受信機内で用いられる請求項１乃
至３０のいずれか１項記載のアプリケーションプログラ
ミングのインターフェース装置の使用方法。
【請求項３７】ＤＡＢ、ＤＶＢ、アナログラジオ又は
アナログテレビジョン受信機内で用いられる請求項３１
乃至３３のいずれか１項記載のクライアントの使用方
法。