JP4590062B2 - 放送受信機システム及び放送受信機システムの動作方法 - Google Patents
放送受信機システム及び放送受信機システムの動作方法 Download PDFInfo
- Publication number
- JP4590062B2 JP4590062B2 JP2000137169A JP2000137169A JP4590062B2 JP 4590062 B2 JP4590062 B2 JP 4590062B2 JP 2000137169 A JP2000137169 A JP 2000137169A JP 2000137169 A JP2000137169 A JP 2000137169A JP 4590062 B2 JP4590062 B2 JP 4590062B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- client
- broadcast
- broadcast receiver
- receiver system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H2201/00—Aspects of broadcast communication
- H04H2201/10—Aspects of broadcast communication characterised by the type of broadcast system
- H04H2201/20—Aspects of broadcast communication characterised by the type of broadcast system digital audio broadcasting [DAB]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H40/00—Arrangements specially adapted for receiving broadcast information
- H04H40/18—Arrangements characterised by circuits or components specially adapted for receiving
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Circuits Of Receivers In General (AREA)
- Stored Programmes (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、デジタル放送システムによって提供される情報サービスを利用するためのアプリケーションのインターフェースに関する。特に、本発明は、放送システムにおける受信機を制御するとともに、放送信号のチャンネルで搬送されるコンテンツへのアクセスを提供するアプリケーションプログラミングのインターフェース装置（以下、ＡＰＩと称する）に関する。
【０００２】
【従来の技術】
以下、本発明の背景について、ＤＡＢ規格「無線放送システム：移動、携帯及び固定受信機に対するデジタル音声放送（ＤＡＢ）（Radio broadcasting systems: Digital Audio Broadcasting (DAB) to mobile, portable, and fixed receivers）」、ETSI, ETS 300 401, １９９７年５月、第２版を例として説明する。ＤＡＢ規格は、送信側から任意数の受信側への種々の情報サービスの送信をサポートするデジタル放送システムを実現するための国際規格である。この情報サービスの例としては、オーディオストリームアプリケーション、ビデオストリームアプリケーション、ハイパーテキストアプリケーション、画像又はテキストスライドショーアプリケーション、ニュースティッカアプリケーション、Ｊａｖａベースアプリケーション等がある。
【０００３】
１つのＤＡＢ放送信号によって、約１．５Ｍｂｉｔ／ｓの速度で伝送されている情報に同時にアクセスすることができる。このような信号はアンサンブルと呼ばれる。１つのＤＡＢ受信機は、同じ位置において２以上のアンサンブルを受信することができるが、一度には１つしか受信することができない。各アンサンブルは、１つのサービスのみ又は多数のサービスを有するＤＡＢ信号を表している。アンサンブルは、異なる種類のアプリケーションを有するサービスを組み合わせることができる。一般的な例として、幾つかのラジオ局（オーディオストリームアプリケーション）と、ハイパーテキストアプリケーション又はスライドショーとして提供される気象、金融、イベント、ニュース等の情報サービスとにアクセスするアンサンブルがある。一般的に、これらの全てのサービスは、同一のアンサンブルに属しているときは、同時にアクセスすることができる。
【０００４】
図１５は、放送のソース信号の１タイムフレームの一般的な構造を示すフォーマットである。このタイムフレームは、ある周期、例えば２４ｍｓで繰り返される。タイムフレームは、同期チャンネル１、サービス情報チャンネル２、所定数（Ｎ）のサービスチャンネル３（サービス＃１〜＃Ｎ）によって構成される。デジタル放送システムの受信機は、同期チャンネル１を用いて信号の同期をとる。サービス情報チャンネル２は、利用可能なサービスの数、これらのサービスによって提供される情報の種類、これらのサービスへのアクセス方法についての情報を提供する。各サービスチャンネル３は、サービスデータを提供する。通常、これらのデータは、データ放送に適したフォーマットに符号化されている。
【０００５】
ＤＡＢシステムは、固定、携帯、移動の各環境において受信できるように設計されている。特に、移動環境では、受信状態が刻々変化する。受信品質は、受信障害のない状態、時折受信障害が発生する状態、全く受信できない状態等の様々である。ハードウェア又はソフトウェアのアプリケーションは、これらの様々な状態に対応しなければならない。受信障害は、移動環境においては一般的に発生し、その障害がユーザに感知されないようにしなければならない。各受信障害をエラーとして取り扱うのは適切ではない。したがって、アプリケーションには、受信状態に適切に対応できるように、受信状態を監視する手法を設ける必要がある。
【０００６】
双方向通信環境では、クライアントがある情報を要求する。配信される情報は、クライアントとサーバ間の現在のコンテキストの状態によって識別される。一方、一方向放送環境では、多数のクライアントのための情報が伝送される。したがって、データは、関係がある情報のみを抽出するために、自己記述的でなければならない。この情報は、全体としてサービスに関するものであれば、一般的にサービス情報チャンネル２で配信され、各サービスの情報オブジェクトのいずれかに関するものであれば、サービスチャンネル３のうちの１つで配信される。各サービスチャンネル３は、配信される情報に対してシステム固有のフォーマットを用いる。
【０００７】
【発明が解決しようとする課題】
本発明は、上述した実情に鑑みてなされたものであり、システム固有の符号化方式をわからせずに、またシステムに依存せずに、情報をアプリケーションに配信するために、情報サービスにアクセスするアプリケーションプログラミングのインターフェース装置を提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明の目的は、請求項１に記載するアプリケーションプログラミングのインターフェース装置及び請求項３１に記載するクライアントによって達成することができ、その好適な実施例については、それぞれ従属する請求項に定義される。
【０００９】
本発明を適用したＡＰＩ及びクライアントは、一方向放送受信機のクライアント／放送受信機インターフェースに対して双方向通信環境の機能を実現する。これは、クライアントが、ＡＰＩの全機能を定義するＡＰＩの独自要求サブインターフェースを介してＡＰＩに要求を送ることができ、また、ＡＰＩが、ＡＰＩによって定義される確認通知サブインターフェースを介して、要求された情報を含むことが可能な確認及び／又は通知メッセージをクライアントに送ることができるからである。
【００１０】
サービスのアクセス構造は、提供されるサービスの種類によって異なる。ラジオ番組等のオーディオストリームを有するサービスの場合、送信されるデータは全て、アプリケーションに受信及び供給されて処理されなければならない。ユーザが情報オブジェクト（例えば、ハイパーテキスト）のセットを自由にナビゲートするようなアプリケーションの場合、全ての情報が周期的に放送され、要求された情報のみが放送から抽出される。典型的なデータの流れを図１６に示す。図１６では、ある文書、すなわち、default.html、pic1.jpg、xyz.html、pic2.jpg、News.html、abc.htmlが周期的に放送される。一連の画像又はテキストをユーザに提供するスライドショーアプリケーションの場合、受信障害に対処するため、情報を提供すべきときに送信するか、あるいは、予め何度か情報を送信しておく。これらの場合、アプリケーション処理に対するサポートが与えられれば、アプリケーションプログラマ又は設計者が行う作業は簡単になる。
【００１１】
ハイパーテキストアプリケーションでは、あるＨＴＭＬページを参照するリンクがクリックされた後に、このページの要求がＡＰＩに与えられる。本発明を適用したＡＰＩの基礎となるシステムは、このページに対するフィルタを設定し、それが放送されるまで聴く。受信後は、このページはアプリケーションに提供される。受信後に要求を取り消してもよく、ＡＰＩは、放送を聴いて要求されたページの更新をアプリケーションに通知することができる。ＡＰＩによって供給されるこのアプリケーション処理サポートは、２以上のアプリケーションが同時にサービスにアクセスしているときや、キャッシュを考慮するときに特に有用である。後者の場合、アクセス時間を改善するため、受信したオブジェクトのコピーを記憶するためにメモリが使用される。したがって、基礎となるＡＰＩがサービスのアクセスを提供すれば、アプリケーションにとっては得である。
【００１２】
本発明は、放送システムによって提供される情報にアクセスするためのアプリケーションプログラミングのインターフェース装置を提供することがわかる。これは、いわゆるハイレベルＡＰＩであり、コマンドとして表す概念がアプリケーションプログラマ又は設計者のニーズを反映するようにされたものである。この分野のアプリケーションプログラマ又は設計者の作業は、情報サービスを魅力的なものとして提供することである。このため、アプリケーションプログラマ又は設計者は、不要なシステム固有の詳細事項に関心を持たない。本発明によれば、ハイレベルＡＰＩによって双方向通信環境が形成されるので、アプリケーションの開発時間が改善され、第三者によるアプリケーション形成の許容が増す。
【００１３】
さらに、ＡＰＩは、放送システムによって提供される情報サービスへのアクセスの全ての面を含む。すなわち、放送媒体及び提供されるサービスのコンテンツ自体へのアクセスを得るのに必要なデジタル放送システムの受信機を制御する。
【００１４】
放送システムでは、クライアントは送信装置において必要な情報を要求しない。その代わり、受信機で何が放送されるか聴き、所望の情報を抽出する必要がある。一般に、放送信号の構成はいつでも変化する可能性があり、情報オブジェクトへのアクセス時間は、双方向通信に基づく情報システムにおけるよりも大きく変化する可能性がある。これらの要件は、放送システム固有のものである。本発明を適用したＡＰＩによって、これらの詳細事項はアプリケーションプログラマにとって問題とはならず、異なる提供フォーマットでの情報サービスの処理をサポートする。本発明を適用したＡＰＩに接続されたクライアントは、必要な情報を要求することができ、この情報が利用可能になると直ちに要求しているクライアントに提供される。ＡＰＩのインターフェースは、アプリケーションプログラムとＡＰＩによって制御される放送システムとの高度のシステム始動通信に非常に良く合致する非同期メッセージ通信に基づくものである。
【００１５】
ＡＰＩは、幾つかのクライアントに対するサポートを同時に提供する。すなわち、２以上のクライアントがＡＰＩのサービスを使用することによって、リソースを共有することができる。
【００１６】
以下の本発明の詳細な説明では、本発明を適用したＡＰＩがＡＰＩの機能に関して非常に記述的であるＣ／Ｃ＋＋言語ソリューションで実現されるようなＤＡＢ受信機を用いて説明を行う。勿論、本発明は、他の放送システムに適用することもでき、例えばＡＰＩのハードウェアソリューション等の他のソリューションを有することもできる。
【００１７】
例におけるデジタル放送システムの受信機の制御の機能的分解は、以下のようになる。すなわち、放送ソースの選択、サービス情報チャンネルへのアクセス、サービスの選択、サービスコンテンツへのアクセス、受信状態の監視である。
【００１８】
デジタル放送システムの受信機の制御は、通信がサービスプロバイダからサービス消費者への一方向のみであることを示す。受信機は、何が放送されるか常に聴き、所望の情報を抽出しなければならない。放送データに変更があれば、放送を聴くことによって検知される。新たなサービスを追加することも、サービスを削除することもできる。あるサービスデータの流れにおけるオブジェクトの追加、削除、更新を行うこともできる。データの流れで放送されるオブジェクトへのアクセス時間は、数ミリ秒〜数分と広範囲で変化する。本発明を適用したＡＰＩでは、これをメッセージベースアプローチによって考える。
【００１９】
【発明の実施の形態】
以下、本発明に係るアプリケーションプログラミングのインターフェース装置及びその使用方法について、図面を参照しながら説明する。図１は、幾つかのアプリケーションプログラムを含む本発明を適用した具体的なモデルを示すブロック図である。
【００２０】
図１に示すように、アプリケーションプログラム４（以下、ＡＰＩクライアントともいう。）は、ＡＰＩ１２を用いてユーザに放送情報サービスを提供する。
ＡＰＩ１２自体は、例えばアンテナ１４を備えるデジタル放送システム受信機１３を介して、受信機制御ブロック１８により放送データにアクセスする。ＡＰＩ１２自体の典型的な構造は以下のようになる。受信機制御ブロック１８は、接続されたデジタル放送システム受信機１３のローレベル制御を行う。図１では、受信機制御ブロック１８とデジタル放送システム受信機１３を、何らかの手段で接続された個別のブロックとして示しているが、本発明は、この具体例に限定されるものではない。すなわち、この部分を１つのブロックに統合することもできる。本発明では、受信機制御ブロック１８の上方に示されるビルディングブロック５〜１１は全て、受信機制御ブロック１８によって提供されるサービスに基づくものである。
【００２１】
図１に示す具体例において、ＡＰＩ１２は、以下のビルディングブロック５〜１１を有する。
【００２２】
・クライアント登録ブロック５は、ＡＰＩクライアントの登録サービスを提供する。ＡＰＩ１２を使用しようとする各アプリケーションプログラム４は、予めＡＰＩクライアントとして登録する必要がある。登録によって、各ＡＰＩクライアントは、他のＡＰＩクライアントと識別するために、全ての準逐次コマンド（subsequent command）で使用されるクライアントＩＤを得る。
【００２３】
・サービスディレクトリブロック６は、１つ以上の放送ソースの利用可能なサービスに関する情報を提供する。
【００２４】
・放送ソース選択ブロック７は、放送ソースを直接選局する、又は放送ソースを検索する手段を提供する。
【００２５】
・サービス選択ブロック８は、サービスを開始又は停止するのに用いられる。
【００２６】
・サービスアクセスブロック９は、サービスのコンテンツにアクセスする手段を提供する。
【００２７】
・受信品質ブロック１０は、受信品質を監視する手段を提供する。
【００２８】
・サービススキャンブロック１１によって、ＡＰＩクライアントは、特定の検索領域の全ての利用可能な放送ソースにおける全ての利用可能なサービスを検索することができ、これによって、サービスディレクトリが更新されるとともに、申し込んだ情報に関する変更がＡＰＩクライアントに通知される。
【００２９】
各コマンドは、概して２つ又は３つのメッセージ種類に分類される。要求メッセージ(-)Reqは、ＡＰＩクライアントによってＡＰＩ１２に送られ、コマンドの実行が要求される。確認メッセージ(-)Cnfは、ＡＰＩ１２によってＡＰＩクライアントに送られ、コマンドの実行が確認される。通知メッセージ(-)Ntfは、長期間継続するコマンドの経過について通知するために、又は更新された情報を提供するために、ＡＰＩ１２によってＡＰＩクライアントに送られる。
【００３０】
各アプリケーションプログラム４は、その必要な情報に関する要求をＡＰＩ１２の要求サブインターフェース１６を介してビルディングブロック５〜１１のうちの１つ又は幾つかに送り、ビルディングブロック５〜１１のうちの１つ又は幾つかは、それらの情報を確認通知サブインターフェース１７を介してアプリケーションプログラム４、すなわちＡＰＩクライアントに提供する。
【００３１】
図２〜図４は、本発明を適用したこれらの３つのメッセージの異なる組合せによって、コマンドが形成されることを示す図である。
【００３２】
図２は、Req-Cnfコマンドのパターンを示す図であり、ステップＳ１において、要求メッセージがＡＰＩ１２に送られ、ステップＳ２において、コマンドが実行され、実行結果を提供する確認メッセージがＡＰＩクライアントに送られる。
【００３３】
図３は、処理に長い時間がかかるコマンドに使用されるReq-Ntf-Cnfコマンドのパターンを示す図である。ステップＳ３において、要求メッセージがＡＰＩ１２に送られ、ステップＳ４〜Ｓ６において、コマンドの実行が開始され、この具体例では、経過情報を提供する３つの通知メッセージがＡＰＩクライアントに送られ、ステップＳ７において、実行結果を提供する確認メッセージがＡＰＩクライアントに送られる。
【００３４】
図４は、申込サービスを提供するコマンドに使用されるReq-Cnf-Ntfコマンドのパターンを示す図である。この場合、ステップＳ８において、ある情報、例えば受信品質の配信を申し込む要求メッセージがＡＰＩ１２に送られる。ステップＳ９において、ＡＰＩ１２から、申込を確認する確認メッセージが、要求しているＡＰＩクライアントに送られる。ステップＳ１０〜Ｓ１２において、要求された情報自体が与えられた通知メッセージ、この具体例では３つの通知メッセージが送られる。すなわち、現在の状態を報告する通知メッセージが最初に送られ、申し込んだ情報が変更される毎に、通知メッセージが必ず送られる。この申込サービスは、他のコマンド実行によって取り消されるまで継続される。なお、現在の状態のみを要求し、必要ではないときは更新を要求しないようにしてもよい。この場合、申込サービスは、関連する通知メッセージによって、要求された情報の配信とともに自動的に取り消される。
【００３５】
本明細書で用いるメッセージという用語は、アプリケーションプログラマ又は設計者に全体として利益を与えるコマンド及びコマンドの実行と区別する必要がある。コマンドの実行は、非同期インターフェース手段を得るために、ＡＰＩ１２とＡＰＩクライアント間で送られる幾つかのメッセージに分割される。これによって、コマンドを同時に実行することができ、ＡＰＩクライアントは、長期間継続するコマンドを実行するときに阻止されることはない。これは、デジタル放送システム受信機１３の上述した特徴に合致する。メッセージという用語を用いることによって、本発明の範囲を、ＡＰＩ１２とＡＰＩクライアントをメッセージシステムによって接続した具体例に限定するものではない。
【００３６】
図５は、以下、本発明の説明に用いるＡＰＩ１２とＡＰＩクライアント１５をインターフェースさせる適切なモデルを示す図である。インターフェースは、ＡＰＩ１２によって定義されるが、要求インターフェース１６は、ＡＰＩ１２内に設けられ、確認通知インターフェース１７は、ＡＰＩクライアント１５に設けられる。以下の実施例では、機能エントリポイントを有するインターフェースとして各インターフェースを実現している。すなわち、メッセージ毎に１つの機能が設けられ、ＡＰＩクライアント１５によって要求メッセージのために呼び出されるとともに、ＡＰＩ１２によって確認及び通知メッセージのために呼び出される。
【００３７】
以下のＡＰＩの説明は、記述的Ｃ／Ｃ＋＋プログラム言語（descriptive c/c++ program language）で表記するが、これは、本発明の範囲を限定するものではない。上述のように、Ｊａｖａ、パスカル、ベーシック等の他のプログラミング言語や、ハードウェアソリューションを用いることもできる。
【００３８】
説明では、以下に示すＡＰＩ表記（convention）を適用する。
【００３９】
接尾辞としての大文字Ｅは、列挙型（enumeration type）を表す。列挙型によって、異なる定数値についての幾つかのシンボル名（symbolic name）を定義することができる。
【００４０】
接尾辞としての大文字Ｔは、データタイプを表す。データタイプ（data type）は、変数の値のみを記憶する手段を有するタイプ、又はある処理を行う機能をさらに含むタイプである。
【００４１】
接尾辞としての大文字ＰＴは、データタイプについてのポインタを表す。
【００４２】
あるデータタイプの変数は、そのデータタイプを示すために接頭辞を有している。小文字ｅは、列挙型の変数を表す。小文字ｂは、タイプブール（type bool）の変数を表す。本発明のドメイン（domain）に関して定義される他のデータタイプを、小文字ｔで表す。機能シグネチャ（function signature）における形式パラメータ（formal parameter）として用いられる変数は、下線が付された第１文字（first character）を有する。
【００４３】
以下の基本データ構造は、ＡＰＩを介して用いられるものである。
【００４４】
ResultE：コマンド実行状態が報告されるときに必ず使用される。この種類のマッピングは、ＡＰＩ１２が用いられる基本システムによって異なる。概して、列挙型として用いられ、異なる定数値について幾つかのシンボル名を定義することができる。各値は、別のコマンド実行状態を表す。共通の値のセットを以下のように定義する。
【００４５】
resOK：コマンドの実行は成功した。
【００４６】
resInvalidParameter：無効パラメータのためにコマンドは実行できなかった。
【００４７】
resNonApplicableFunction：現在の状態ではコマンドは実行できない。
【００４８】
これらは、単に基本的なエラーコードのセットの具体例である。放送情報システムでは、このセットを、何ら発明的技術を用いずに、システムの能力に応じてより詳細なエラーコードによって、容易に拡張することができる。
【００４９】
ClientIdT：ＡＰＩクライアント１５のＩＤのデータタイプとして使用される。このデータタイプの内部構造は、実際の実現方法に依存する。このデータタイプは、ＡＰＩ１２の基本システムによって定義される。各ＡＰＩクライアント１５は、ＡＰＩ１２と接続するときにこのデータタイプのＩＤを取得して、全ての準逐次コマンドに対して異なるＡＰＩクライアント１５を識別するのに用いられる。
【００５０】
ServiceIdT：放送情報サービスのＩＤのデータタイプとして使用される。このデータタイプの内部構造は、実際の実現方法に依存する。このデータタイプは、ＡＰＩ１２の基本システムによって定義される。サービスは、サービスディレクトリブロック６によって提供されるサービスディレクトリによって、サービスＩＤ及び他の属性とともに報告される。ＡＰＩクライアント１５は、サービスＩＤを用いてサービスに対する情報を得て、サービスの開始又は停止を行う。
【００５１】
ObjectIdT：例えば、ハイパーテキストページ、イメージ等の情報オブジェクトのＩＤのデータタイプとして使用される。このデータタイプの内部構造は、実際の実現方法に依存する。このデータタイプは、ＡＰＩ１２の基本システムによって定義される。オブジェクトＩＤは、ＡＰＩクライアント１５によってオブジェクトの提供を要求したり、提供されたオブジェクトを識別するのに使用される。
【００５２】
ObjectT：ある情報オブジェクトのコンテンツや、ある画像の有効期限又はテキスト記述等のオブジェクトに関する追加的な属性にアクセスするデータタイプとして使用される。このデータタイプの内部構造は、実際の実現方法に依存する。このデータタイプは、ＡＰＩ１２の基本システムによって定義される。各オブジェクトはオブジェクトＩＤによって識別される。
【００５３】
bool：値を真及び偽とすることができる演算データタイプ（boolean data type）。
【００５４】
以下の機能シグネチャにおけるパラメータの中には、イタリック体で記述されるものがある。これらのパラメータは、ＡＰＩ１２の基本システムと強い関連がある。すなわち、これらのデータタイプの詳細な定義は、基本システムに強く依存し、この記述では定義できない。ある放送システムがビットエラーレートを監視する手段を提供し、他のシステムが同期状態を監視する手段を提供し、さらに他のシステムがこれらの組合せ又は他のパラメータを監視する手段を提供することがある。システム専用の要件をマップする適切な方法は、１又は２以上のパラメータを使用することである。このような場合、正確なデータタイプの定義を付ける必要性があることを示すために、あるパラメータをイタリック体で記述する。当該技術分野の技術者にとっては、本発明の主旨を逸脱しない範囲でコマンドメッセージの定義を変更してもよいことは明らかである。
【００５５】
以下の具体例は、要求インターフェース１６と確認インターフェース１７のインターフェースの定義を示すものでる。
【００５６】
【表１】
【００５７】
【表２】
【００５８】
【表３】
【００５９】
【表４】
【００６０】
【表５】
【００６１】
【表６】
【００６２】
【表７】
【００６３】
ＡＰＩクライアント１５とＡＰＩ１２の２つのインスタンス（instance）は、これらのインターフェースを介して接続される。すなわち、ＡＰＩ１２は、要求インターフェース１６を実現し、ＡＰＩクライアント１５は、この要求インターフェース１６用い、要求インターフェース１６のインターフェース機能を呼び出すことによってＡＰＩ１２に要求メッセージを送る。ＡＰＩクライアント１５は、確認インターフェース１７を実現し、ＡＰＩ１２は、確認インターフェース１７を用い、確認通知インターフェース１７のインターフェース機能を呼び出すことによってＡＰＩクライアント１５に確認及び通知メッセージを送る。
【００６４】
以下、全てのコマンド及びメッセージの機能について詳細に説明する。コマンドとメッセージを使用する典型的な例を、メッセージシーケンスチャートに示す。なお、これらのチャートは、誤動作を考慮していない単純なシナリオを示すものである。記述したコンテキストにおいて重要なパラメータのみを列挙する。
【００６５】
クライアント登録
ＡＰＩ１２を使用しようとするアプリケーションプログラムはいずれも、図６に示すように、他のコマンドを実行する前にＡＰＩクライアント１５としてＡＰＩ１２に接続する必要があり、また、ＡＰＩコマンドの使用が終わると切断する必要がある。このような登録及び切断は、クライアント登録ブロック５を介して行われる。Openコマンドは、ＡＰＩクライアント１５を登録し、必要な全てのリソースを割り当て、全ての準逐次コマンドに使用されるクライアントＩＤを与える。ＩＤは、２つ以上のＡＰＩクライアント１５が同時にＡＰＩ１２を用いる場合に必要である。Openコマンドは、OpenReq及びOpenCnfメッセージによって構成される。Closeコマンドは、動作している全てのサービスを停止し、呼出を行っているＡＰＩクライアント１５のために取得されたリソースを解放し、ＡＰＩクライアント１５とＡＰＩ１２を切り離す。また、ＡＰＩコマンドを実行するためには、Openコマンドを予め実行する必要がある。Closeコマンドは、CloseReq及びCloseCnfメッセージによって構成される。ＡＰＩクライアント１５は、OpenコマンドとCloseコマンドの間に、ＡＰＩ１２を介してデジタル放送システム受信機１３の制御を行うか、あるいは単に提供されるサービスを「聴く」、すなわちコマンドを実行することができる。
【００６６】
Open及びCloseコマンドメッセージ機能のインターフェースは、以下のように定義される。
【００６７】
【表８】
【００６８】
まず、接続を開くために、ステップＳ４０において、ＡＰＩクライアント１５は、OpenReqメッセージをＡＰＩ１２に送り、ＡＰＩクライアント１５の確認通知インターフェース１７に対するポインタ（_ptInterface）が与えられる。ＡＰＩ１２は、ＡＰＩクライアント１５とＡＰＩ１２間の通信で発生する全ての確認及び通知メッセージを、この確認通知インターフェース１７に送る。
【００６９】
その後、ステップＳ４１において、ＡＰＩ１２は、Openコマンドの処理を報告するOpenCnfメッセージをＡＰＩクライアント１５に送る。パラメータ_eResultは、接続を確立することができたか否かを示す。値がresOKであるときは、接続が確立され、パラメータ_tClientIdによって、全ての準逐次コマンドに使用される有効ＩＤが与えられる。パラメータ_eResultによって報告される値が他の値であるときは、常にOpenコマンドは失敗し、接続は確立されない。この場合、パラメータ_tClientIdは、有効な値を有しない。
【００７０】
そして、コマンドが実行された後、ＡＰＩクライアント１５がＡＰＩコマンドの使用を終了すると、ステップＳ４２において、ＡＰＩクライアント１５は、CloseReqメッセージをＡＰＩ１２に送って、接続を閉じる。このメッセージの唯一のパラメータは、呼出を行っているＡＰＩクライアント１５を識別するためのクライアントＩＤである。そして、ステップＳ４３において、ＡＰＩ１２は、CloseCnfメッセージをＡＰＩクライアント１５に送ることによって、Closeコマンドの処理を報告する。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKであるときは接続が閉じられ、そうでないときはエラーが発生している。
【００７１】
放送ソースの選択
デジタル放送システム受信機１３によって提供されるコンテンツにアクセスするために、ＡＰＩクライアント１５は、放送ソース選択ブロック７を介して放送ソースを選択する。概して、放送ソースは直接選択することができるか、あるいはデジタル放送システム受信機１３が放送ソースを自動的に検索する何らかの手段を有している。したがって、２つのコマンドが設けられている。
【００７２】
Tuneコマンドは、放送ソースを直接選択するためのものである。ＡＰＩクライアント１５は、どこに放送ソースが位置するか知っており、必要なパラメータは、全てＡＰＩクライアント１５によって与えられるものとする。Tuneコマンドは、図７に示すように、TuneReq及びTuneCnfメッセージ機能によって構成される。
【００７３】
Searchコマンドは、放送ソースを検索するためのものである。検索方法は、例えば周波数範囲、周波数ステップ、方向等であり、ＡＰＩクライアント１５によって特定することができ、あるいはＡＰＩ１２によって自動的に行われる。検索は長時間かかるものと考えられる。したがって、検索が継続している限り経過情報が提供される。Searchコマンドは、図８に示すように、SearchReq、SearchNtf、SearchCnfメッセージ機能によって構成される。
【００７４】
Tune及びSearchコマンドメッセージ機能のインターフェースは、以下のように定義される。
【００７５】
【表９】
【００７６】
図７に示すように、ステップＳ５０において、ＡＰＩクライアント１５は、Tuneコマンドを開始するために、TuneReqメッセージをＡＰＩ１２に送る。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。放送ソースは、１又は幾つかのパラメータ（BroadcastSource）によって特定される。ＡＰＩ１２によるメッセージの受信後、特定された放送ソースへの同調（選局）が開始される。選局が行われた後、現在の受信品質が検出される。そして、ステップＳ５１において、ＡＰＩ１２からＡＰＩクライアント１５へのTuneCnfメッセージによって、コマンドの処理結果が報告される。これは、送信先のクライアント（_tClientId）を識別し、処理結果（_eResult）を示す。処理が成功したときは、パラメータ_eResultはresOKという値を示すが、そうでないときはエラーが発生している。処理結果とは独立して、現在選択されている放送ソース（CurrentBroadcastSource）及び現在の受信品質（ReceptionQuality）が報告される。
【００７７】
図８に示すように、ステップＳ６０において、ＡＰＩクライアント１５は、Searchコマンドを開始するため、SearchReqメッセージをＡＰＩ１２に送る。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。検索方法は。１つ以上のパラメータ（SearchMethod）によって特定される。検索には長時間がかかるので、ＡＰＩクライアント１５検索動作中に経過情報を要求することもある。このため、パラメータNotificationsによって、例えば各周波数ステップ等の所望の通知の種類を特定することができるようになっている。
【００７８】
その後、ステップＳ６１〜Ｓ６３において、ＡＰＩ１２は、SearchNtfメッセージを用いて、経過情報をＡＰＩクライアント１５に供給する。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別するためのものである。経過情報は、１つ以上のパラメータ（ProgressInfo）として供給される。ステップＳ６１において、最初に供給される通知は、検索が開始されたことを示している。通知される他のイベントは、ＡＰＩ１２の基本システムによって異なる。
【００７９】
そして、ステップＳ６４において、ＡＰＩ１２は、SearchCnfメッセージをＡＰＩクライアント１５に送ることによって、検索コマンド処理の完了を報告する。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKである場合、コマンドが成功し、放送ソースが見つかっている。そうでない場合は、エラーが発生している。いずれの場合も、現在選択されている放送ソース（CurrentBroadcastSource）及び現在の受信品質（ReceptionQuality）が報告される。
【００８０】
放送ソースの選択とともに、ＡＰＩクライアント１５は、この放送ソースに属する全ての情報サービスにアクセスする。別の放送ソースの情報サービスにアクセスするには、他の放送ソースを予め選択していなければならない。
【００８１】
受信状態の監視
受信状態を監視しようとするＡＰＩクライアント１５は、受信品質ブロック１０内で実現されるSelectReceptionInfoコマンドを使用する。SelectReceptionInfoコマンドは、図９に示すように、SelectReceptionInfoReq、SelectReceptionInfoCnf、ReceptionInfoNtfメッセージによって構成される。SelectReceptionInfoコマンドは、受信状態に関する状態変化の申込サービスを提供する。すなわち、SelectReceptionInfoReq及びSelectReceptionInfoCnfメッセージを用いてこのサービスを申し込むＡＰＩクライアント１５は、ＡＰＩクライアント１５によって申込が取り消されるまで、受信状態が変化するたびに通知メッセージReceptionInfNtfを受ける。なお、現在の受信状態の報告を一回だけ要求することも可能である。
【００８２】
SelectReceptionInfoコマンドメッセージ機能のインターフェースは、以下のように定義される。
【００８３】
【表１０】
【００８４】
先ず、受信品質の通知を申し込むために、ステップＳ７０において、ＡＰＩクライアント１５は、SelectReceptionInfoコマンドを開始するためにSelectReceptionInfoReqメッセージをＡＰＩ１２に送る。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。監視される情報の種類は、例えば同期状態、ビットエラーレート、その他の基本システムのための適切なパラメータのセット等であり、パラメータReceptionInfoSelectionによって特定される。監視するために、与えられた全てのパラメータあるいは１つのサブセットのみを選択することも、何も選択しないことも可能である。パラメータ_bNoSubscriptionは、情報がＡＰＩクライアント１５に一回だけ供給されるか否か、又は選択されたパラメータのうちの１つにおける各状態変化が報告される申込サービスが開始されるか否かを特定する。申込サービスは、初めて監視する幾つかのパラメータを選択することによって開始される。また、申込サービスは、与えられたパラメータのうちの１つも選択しないことによって停止される。監視するパラメータのセットを変更することも可能である。
【００８５】
その後、ステップＳ７１において、ＡＰＩ１２は、SelectReceptionInfoCnfメッセージをＡＰＩクライアント１５に送ることによって要求を確認する。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKであるときは、コマンドは成功であり、そうでないときはエラーが発生している。受信状態を監視するための現在の選択は、パラメータCurrentReceptionInfoSelectionによって報告される。監視を行うために、与えられたパラメータの幾つかを選択するとき、要求された情報が１つのReceptionInfoNtfメッセージとして続く。パラメータ_bNoSubscriptionを真に設定することによって情報を一回だけ要求したときは、その後には他のReceptionInfoNtfメッセージは続かない。パラメータ_bNoSubscriptionを偽に設定することによって申込サービスを開始したとき、選択されたパラメータのうちのいずれか１つの状態変化がReceptionInfoNtfメッセージによって報告される。
【００８６】
以下、ステップＳ７２及びＳ７３において、ＡＰＩクライアント１５に受信品質の変化を知らせ続けるために、ＡＰＩ１２によってReceptionInfoNtfメッセージがＡＰＩクライアント１５に送られる。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別するためのものである。ReceptionInfoNtfメッセージは、先に監視するために選択したパラメータのうちの１つ以上のパラメータの状態変化について報告する。パラメータReceptionInfoSelectorは、どのパラメータが更新されているのかを示す。更新された値自体は、パラメータReceptionInfoによって与えられる。申込サービスの場合、選択された全てのパラメータの初期状態が、最初のReceptionInfoNtfメッセージによって送られる。それ以降の全てのReceptionInfoメッセージは、選択されたパラメータの状態変化についての情報を提供する。一回のみの要求の場合、選択された全てのパラメータの現在の状態が、最初のReceptionInfoNtfメッセージのみで送られる。
【００８７】
そして、申込を停止するために、ステップＳ７４において、ＡＰＩクライアント１５は、SelectReceptionInfoReqメッセージをＡＰＩ１２に送り、ステップＳ７５において、このSelectReceptionInfoReqメッセージは、SelectReceptionInfoCnfメッセージをＡＰＩクライアント１５に送ることによって確認される。これら両メッセージのパラメータは、上述のようにステップＳ７０及びＳ７１における場合と同様に定義される。
【００８８】
サービスディレクトリへのアクセス
サービスディレクトリブロック６によって提供されるサービスディレクトリは、現在の又は他の放送ソースに属する全ての既知のサービスについての情報を提供するためのものである。この情報がどの程度信頼性があるかは、基本システムの方針（strategy）によって異なる。利用可能なサービスについての情報は放送ソース信号で送信されるが、一時的な受信障害やオフライン作業により、サービスディレクトリブロック６によって提供されるサービスディレクトリが常に最新なものとは限らない。しかし、デジタル放送システム受信機１３が接続されると直ちに、情報が更新され、接続された各クライアント４に変更が通知される。また、放送ソース受信機が１つである基本システムでは、他の放送ソースで発生する変化を監視することはできない。この情報が次に更新されるのは、この放送ソースにアクセスしたとき、又はScanコマンドを実行したときである。サービスディレクトリブロック６によって提供されるサービスディレクトリへのアクセスは、サービスディレクトリの動的性質に合うように離散的に行われる。これは、情報が通知メッセージとしてばらばらにＡＰＩクライアント１５に供給されるSelectServiceInfoコマンドの使用による申込サービスとして設計されている。例えば、新たなサービスが利用可能である場合、そのサービスの存在及び属性がＡＰＩクライアント１５に報告される。スタートアップの直後、サービスディレクトリブロック６によって提供されるサービスディレクトリのコンテンツが、上述の通知メッセージ上にマップされ、その後の変更については同様に報告される。SelectServiceInfoコマンドは、図１０に示すように、SelectServiceInfoReqメッセージ、SelectServiceInfoCnfメッセージ、ServiceInfoNtfメッセージによって構成される。
【００８９】
SelectServiceInfoコマンドメッセージ機能のインターフェースは、以下のように定義される。
【００９０】
【表１１】
【００９１】
サービスディレクトリ情報を申し込むために、ステップＳ８０において、ＡＰＩクライアント１５はSelectServiceInfoコマンドを開始するためのSelectServiceInfoReqメッセージをＡＰＩ１２に送る。SelectServiceInfoコマンドは、サービスディレクトリブロック６によって提供されるサービスディレクトリにおける変化に対して、申込サービスの開始、停止、変更を行う。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。サービスディレクトリブロック６によって提供されるサービスディレクトリは、例えばオーディオストリームアプリケーションを有するサービスや、スライドショー等のデータサービスを有するサービス等であり、異なるカテゴリーの情報を提供することもできる。したがって、ＡＰＩクライアント１５は、パラメータServiceInfoSelectionを用いて、関心のある情報の種類をカスタマイズすることができる。サポートしなければならない最小セットのイベントは、dscServiceElementAdded、dscServiceElementRemoved、dscServiceElementChangedである。dscServiceElementAddedの値は、新たなサービスエレメントが利用可能であることを示す。dscServiceElementRemovedの値は、サービスエレメントが除去されているので利用不可能であることを示す。dscServiceElementChangedの値は、サービスエレメントの属性が変化したこと、例えば、あるサービスを記述するテキスト情報、又は、あるサービスによって提供される現在のコンテンツの種類を記述する情報が、コンテンツとともに変更されていることを示す。後者の場合、ServiceInfoNtfメッセージのパラメータServiceUpdateが、その変更についてより詳細に通知する。パラメータServiceInfoSelectionによってどのイベントが特定されるかに応じて、ＡＰＩ１２は、これらのイベントに関連するServiceInfoNtfメッセージを送る。最後のパラメータ_bAutoDeliveryは、サービスディレクトリブロック６によって提供されるサービスディレクトリにおける変化が、ＡＰＩクライアント１５に通知されているか（偽に設定）、あるいは、変更された情報自体も変更通知とともに供給されているか（真に設定）を特定する。
【００９２】
その後、ステップＳ８１において、ＡＰＩ１２は、SelectServiceInfoコマンドの処理を確認するために、SelectServiceInfoCnfメッセージをＡＰＩクライアント１５に送る。パラメータ_tClientIdは送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKである場合はコマンドが成功し、そうでない場合はエラーが発生している。パラメータCurrentServiceInfoSelectionは、サービスディレクトリにおける変化に対する現在の申込レベルを示す。パラメータ_bAutoDeliveryは、サービスディレクトリのあるエレメントに対する変化が報告されているか（偽に設定）、あるいは、変更された情報自体も供給されているか（真に設定）を示す。申込サービスが開始されると、サービスディレクトリブロック６によって提供されるサービスディレクトリに知られている全ての情報が、ServiceInfoNtfメッセージとして供給される。
【００９３】
利用可能なサービスをＡＰＩクライアント１５に通知し続けるため、ステップＳ８２〜Ｓ８７において、ＡＰＩ１２によってServiceInfoNtfメッセージがＡＰＩクライアント１５に送られる。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別するためのものである。申込サービスの開始直後、ＡＰＩクライアント１５による選択と一致するサービスディレクトリの完全なコンテンツがServiceInfoNtfメッセージ上にマップされ、ＡＰＩクライアント１５に供給される。その後、ServiceInfoNtfメッセージを送ることによって、サービスディレクトリに対する変更のみが報告される。パラメータ_tServiceIdは、サービスディレクトリブロック６によって提供される変更されたサービスディレクトリのサービスエレメントを識別するためのものである。パラメータServiceInfoSelectorは、この通知の理由となるイベントを特定する。サポートされるイベントセットは、ＡＰＩ１２の基本システムによって異なるが、少なくとも上述のイベントdscServiceElementAdded、dscServiceElementRemoved、dscServiceElementChangedをサポートする必要がある。パラメータServiceUpdateは、dscServiceElementAddedのイベントの場合、サービスエレメントのうちのどのオプショナル部分について知られているかを示し、dscServiceElementChangedのイベントの場合、サービスエレメントのうちのどの部分が変化したかを示す。パラメータServiceInfoObjectは、変更された情報オブジェクト自体を有する。これは、SelectServiceInfoReqメッセージにおけるパラメータ_bAutoDeliveryを特定することによって申込サービスがこのモードで設定されている場合のみ、供給される。そうでない場合、情報オブジェクトを取得するために追加コマンドを実行しなければならない。
【００９４】
このため、コマンドGetServiceInfoが設けられている。これは、GetServiceInfoReqメッセージとGetServiceInfoCnfメッセージによって構成される。
【００９５】
GetServiceInfoコマンドメッセージ機能のインターフェースは、以下のように定義される。
【００９６】
【表１２】
【００９７】
ＡＰＩクライアント１５は、GetServiceInfoコマンドを開始するためにGetServiceInfoReqメッセージをＡＰＩ１２に送る。GetServiceInfoコマンドは、特定されたサービスエレメントについての情報の提供を要求する。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。サービスエレメントは、パラメータ_tServiceIdによって識別される。
【００９８】
ＡＰＩ１２は、GetServiceInfoCnfメッセージをＡＰＩクライアント１５に送ることによって要求を確認する。パラメータ_tClientIdは送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKである場合、コマンドは成功であり、そうでない場合はエラーが発生している。パラメータServiceInfoObjectは、要求された、サービスエレメントを表す情報オブジェクトを有する。このオブジェクトの完全な定義は、ＡＰＩ１２を介してアクセスされる基本システムによって異なる。
【００９９】
そして、申込を停止するため、ステップＳ８８において、ＡＰＩクライアント１５は、SelectServiceInfoReqメッセージをＡＰＩ１２に送り、これが、ステップＳ８９において、ＡＰＩ１２からSelectServiceInfoCnfメッセージをＡＰＩクライアント１５に送ることによって、確認される。これら両メッセージのパラメータは、上述のように、ステップＳ８０及びＳ８１における場合と同様に定義される。
【０１００】
サービスの選択
サービスのコンテンツにアクセスするには、予めサービスを開始しておく必要がある。ＡＰＩ１２の基本システムのサービス選択ブロック８は、必要とされるリソースを割り当て、このサービスで何が放送されるのか聴取を開始する。要求されたオブジェクトのＡＰＩクライアント１５によるアクセス時間を改善するため、放送オブジェクトをメモリに記憶するキャッシュ技術を用いてもよい。
【０１０１】
ＡＰＩクライアント１５は、SelectServiceコマンドを用いてサービスの開始又は停止を行う。SelectServiceコマンドは、図１１に示すように、SelectServiceReqメッセージ、SelectServiceCnfメッセージ、ServiceInfoNtfメッセージによって構成される。各サービスは、そのサービスＩＤによって識別される。ＡＰＩクライアント１５は、サービスディレクトリブロック６によって提供されるサービスディレクトリにアクセスすることによって、サービスについて知る。サービスの開始及び停止に加えて、１コマンドで現在動作している全てのサービスを停止させるとともに新たなサービスを開始することもサポートされる。放送システムでは、サービスを終了することは常に可能である。これは、ServiceInfoNtfメッセージによってＡＰＩクライアント１５に知らされる。すなわち、サービスの終了が報告され、サービスが現在選択されている場合、関連するServiceInfoNtfメッセージの供給とともに自動的に停止する。
【０１０２】
SelectServiceコマンドメッセージ機能のインターフェースは、以下のように定義される。
【０１０３】
【表１３】
【０１０４】
サービスを開始するのに、ステップＳ９０において、ＡＰＩクライアント１５は、SelectServiceコマンドを開始するためにSelectServiceReqメッセージをＡＰＩ１２に送る。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。サービスは、パラメータ_tServiceIdによって識別される。パラメータ_eSelectionModeは、特定されたサービスの選択モードを特定する。以下のモードがサポートされる。dscReplaceの値は、現在動作している全てのサービスを停止させ、パラメータ_tServiceIdによって特定されるサービスを開始する。dscAddの値は、パラメータ_tServiceIdによって特定されるサービスを開始し、現在開始されている全てのサービスについてはそのままにしておく。dscRemoveの値は、パラメータ_tServiceIdによって特定されるサービスのみを停止させる。dscRemoveAllの値は、開始された全てのサービスを停止させる。この最後の場合、パラメータ_tServiceIdは意味を持たない。
【０１０５】
そして、ステップＳ９１において、ＡＰＩ１２は、SelectServiceCnfメッセージを送ることによってコマンドの処理を確認する。パラメータ_tClientIdは送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKである場合、コマンドは成功であり、そうでない場合はエラーが発生している。パラメータ_tServiceIdは、パラメータ_eSelectionModeによって特定される選択モードに従って選択されたサービスを識別するためのものである。パラメータ_eSelectionModeの意味は、SelectServiceReqメッセージで使用するのと同じである。
【０１０６】
サービスのアクセス中、開始したサービスを放送から除去する場合、図１０に示すステップＳ８２〜Ｓ８７に関して説明したように、ＡＰＩ１２からＡＰＩクライアント１５にServiceInfoNtfメッセージを送ることによって、この変更がＡＰＩクライアント１５に通知される。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別するためのものである。パラメータServiceInfoSelectorは、この場合、dscServiceElementRemovedイベントを示す。サービスエレメントは、パラメータ_tServiceIdによって識別される。dscServiceElementRemovedエレメントが通知されたときは、パラメータServiceInfoObjectは意味を持たない。
【０１０７】
そして、サービスを停止するため、ステップＳ９２において、ＡＰＩクライアント１５はSelectServiceInfoReqメッセージをＡＰＩ１２に送り、これが、ステップＳ９３において、ＡＰＩ１２からＡＰＩクライアント１５にSelectServiceInfoCnfメッセージを送ることによって、確認される。これら両メッセージのパラメータは、上述のステップＳ９０及びＳ９１における場合と同様に定義される。
【０１０８】
サービスへのアクセス
放送サービスは、幾つかの方法で情報を提供することができる。以下、それら異なる方法について、アプリケーション種類の点から説明する。
【０１０９】
ローカルインタラクティブアプリケーション：
ローカルインタラクティブアプリケーションは、情報をばらばらに供給する。例えば、ハイパーテキストアプリケーションのユーザは、現在提供されている情報を読み、更なる情報に対するハイパーリンクを追跡することによって、与えられた情報をナビゲートする。各ハイパーテキストページには、テキスト情報、異なるフォーマットのイメージ等の埋込オブジェクト、他のハイパーテキストページや他のフォーマットのオブジェクトへのリンクが含まれている。放送システムでは、これらの情報オブジェクトが周期的に送信される。現在どの情報オブジェクトが必要かは、ユーザインタラクションによって異なる。
【０１１０】
オブジェクトの明示的要求を必要とする全てのアプリケーションについて、ＡＰＩ１２は、サービスアクセスブロック９を用いて、特定された情報オブジェクトの供給を要求するSelectObjectコマンドを与える。これは、SelectServiceコマンドを使用することによって関連するサービスを開始した後に、使用することができる。SelectObjectコマンドは、図１３に示すように、SelectObjectReqメッセージ、SelectObjectCnfメッセージ、ObjectNtfメッセージによって構成され、申込サービスを提供する。一回のみの供給を要求することも可能であり、また、更新供給のためにオブジェクトを選択することも可能である。すなわち、オブジェクトは、それがはじめて利用可能となった後に供給され、そのオブジェクトの更新は全て、選択が取り消されるまで追加的に報告される。オブジェクトの選択及び解放に加えて、１コマンドで現在の全ての選択を除去するとともに別の選択を行うことも可能である。別のパラメータによって、完全に受信されたオブジェクトのみが供給されるか、あるいは、部分的に供給されてもよいのかを特定することができる。後者の場合、開始から完全なオブジェクトの既に受信されたデータが全て供給される。最初の供給の後、何回か供給が行われる。供給毎に、供給されるオブジェクトが少しずつ完全になる。別のパラメータは、この情報オブジェクトがアプリケーションにとってどの程度重要かを示す、アプリケーションによるヒントである。
【０１１１】
スライドショーアプリケーション：
スライドショーアプリケーションは、アプリケーション自体によって予め定義された方法で情報を提供する。例えば、ピクチャスライドショーは、提示時刻が予め決定している一連の画像を提供する。ピクチャスライドショーを実現する簡単な方法は、画像を提示すべき時に放送することである。この場合、追加信号送信は必要ない。より複雑な方法としては、送信エラーに備えるため、提示時刻以前に画像を数回放送する。これによって、提示時刻になる前に提示オブジェクトを適切に受信する可能性が高くなる。
【０１１２】
提示時刻が予め決定している全てのアプリケーションについて、ＡＰＩ１２は、適切な提示時刻においてオブジェクトの復号化、記憶、提示の呼出を行う。上述のアプリケーションを有するサービスが開始した後、提示時刻になると、図１２に示すように、提示される各オブジェクトがObjectNtfメッセージとしてＡＰＩ１２によってＡＰＩクライアント１５に供給される。さらに、現在提示されているオブジェクトが提示用として有効でなくなったことを示すため、ObjectNtfメッセージが使用される。
【０１１３】
ストリーミングアプリケーション：
ストリーミングアプリケーションは、例えばオーディオ又はビデオストリーム等のアプリケーションプログラムによって準備されているデコーダに永続的に供給される連続データストリームである。このアプリケーションを有するサービスが開始された後、時間通りにデータを供給することが重要である。これは、遅れたデータは役に立たないからである。ＡＰＩ１２は、図１２に示すように、ストリーミングアプリケーションに対してスライドショーアプリケーションと同様のアプリケーション処理サポートを提供する。ストリーミングアプリケーションを有するサービスが開始されると、連続データストリームからのデータを包含するバッファを有するObjectNtfメッセージが送られる。このデータは、アプリケーションプログラムのデコーダに供給されなければならない。供給におけるジッタを補償するため、アプリケーションは、ObjectNtfメッセージを記憶するのにファーストインファーストアウトキューを用いてもよい。このキューが所定のメッセージ数まで満たされてはじめて、アプリケーションデコーダが開始する。アプリケーションデコーダは、１メッセージのデータを処理した後、次のメッセージが入る。ＡＰＩ１２によって供給されるその後のメッセージはいずれも、ファーストインファーストアウトキューに追加される。
【０１１４】
アプリケーションのビルトイン処理
実際の放送システムでは、あるアプリケーション種類用のビルトイン処理／プロセッサが得られることがある。例えば、ビルトインオーディオデコーダは、連続するオーディオストリームアプリケーションを処理する。このアプリケーションのビルトイン処理は、サービスの処理の開始又は停止を行うSelectServiceコマンドを用いて制御される。この場合、SelectObjectコマンドによるサポートは不要である。サービスアクセスブロック９に含まれるSelectObjectコマンドメッセージ機能のインターフェースは、以下のように定義される。
【０１１５】
【表１４】
【０１１６】
【表１５】
【０１１７】
図１３では、図１１で説明したように行われるステップＳ１１０及びＳ１１１の、ＡＰＩクライアント１５からＡＰＩ１２へのSelectServiceReqメッセージを有するサービスの開始、及び、SelectServiceCnfメッセージを送ることによるＡＰＩ１２のコマンドの確認の後、SelectObjectコマンドを開始することができる。
【０１１８】
その後、ステップＳ１１２において、SelectObjectコマンドを開始するため、ＡＰＩクライアント１５はSelectObjectReqメッセージをＡＰＩ１２に送る。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。選択されるオブジェクトは、パラメータ_tObjectIdによって識別される。オブジェクトが属しているサービスは、パラメータ_tServiceIdによって識別される。パラメータ_eObjectSelectionModeは、特定されたオブジェクトの選択モードを特定する。以下のモードがサポートされる。dscOnceの値は、特定されたオブジェクトの一回のみの供給を要求する。dscUpdateの値は、選択が取り消されるまで、特定のオブジェクトの供給及びオブジェクトの各更新の供給を要求する。dscOffの値は、現存のオブジェクト選択を取り消す。dscCacheHintの値は、このオブジェクトがＡＰＩクライアント１５にとってどの程度重要であるかを示すヒントをＡＰＩ１２に供給するためのみに、SelectObjectコマンドが使用されることを示す。この場合、オブジェクトは供給用に選択されない。重要性は、パラメータCacheHintによって特定される。ハイパーテキストアプリケーション等の幾つかのアプリケーションでは、１コマンドで新たなオブジェクトを選択するとともに同じサービスに属する現存の全ての選択を取り消すことが好都合である。これは、パラメータ_bReplaceSelectionsを使用することによってサポートされる。このパラメータが真に設定された場合、パラメータ_tServiceIdによって特定されるサービスに属する現存の全ての選択が取り消される。このパラメータが偽に設定された場合、現存の全ての選択が変更されるわけではない。dscCompleteに対して設定されたパラメータ_eDeliveryModeは、選択されたオブジェクトがオブジェクトの完全な受信後に供給されることを示す。dscPartialに対して設定されたパラメータ_eDeliveryModeは、選択されたオブジェクトを部分的に供給してもよいことを示す。すなわち、インデックス１〜ｎの範囲のバイトシーケンスからなるオブジェクトについて、最初の供給では、インデックス１〜ｍ（ｍはｎ以下）の範囲のバイトシーケンスからなる部分的に受信されたオブジェクトが得られる。次の供給では、１〜ｌ（ｌはｍより大でｎ以下）のシーケンスが得られ、同様に続く。これは、１〜ｎの範囲の全てのデータが供給されてオブジェクトが供給されると、終了する。
【０１１９】
パラメータCacheHintは、ＡＰＩ１２への、キャッシュを行うためのＡＰＩクライアント１５によるヒントを特定する。キャッシュでは、放送オブジェクトのコピーを記憶するため高速ローカルメモリを使用する。これによって、要求されたオブジェクトが既にキャッシュメモリに記憶されている場合、オブジェクトのアクセス時間が改善する。パラメータCacheHintは、キャッシュを行うオブジェクトを選択するためのヒントを与える。このパラメータの正確な定義は、基本システムによって異なる。一例としては、ＡＰＩクライアント１５にとっての重要性が最も低い０から重要性が最も高い１００までの範囲で優先パラメータを使用することである。キャッシュのためのヒントは、各オブジェクトモードdscOff、sdcOnce、dscUpdate、dscCacheについて有効である。
【０１２０】
そして、ステップＳ１１３において、ＡＰＩ１２は、SelectObjectCnfメッセージをＡＰＩクライアント１５に送ることによってコマンドの処理を確認する。パラメータ_tClientIdは送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKである場合、コマンドは成功であり、そうでない場合はエラーが発生している。パラメータ_tServiceIdは、選択されたオブジェクトが属しているサービスを識別するためのものである。パラメータ_tObjectIdは、選択されたオブジェクトを識別するためのものである。特定されたオブジェクトの現在の選択モードは、パラメータ_eObjectSelectionModeによって与えられる。パラメータAccessTimeは、選択されたオブジェクト自体がObjectNtfメッセージの使用によって与えられるまでの予想される遅延を示す、オブジェクトのアクセス時間を与える。
【０１２１】
オブジェクト及び更新を供給するため、ステップＳ１１４及びＳ１１５に示すように、ObjectNtfメッセージを送ることによって、ローカルインタラクティブアプリケーション等の選択されたオブジェクト、又は、スライドショーアプリケーション等の提示されるオブジェクト、又は、ストリーミングアプリケーション等の連続データストリームの１セグメントを有するオブジェクトがＡＰＩ１２からＡＰＩクライアント１５に供給される。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別するためのものである。パラメータ_tServiceIdは、オブジェクトが属しているサービスを識別するためのものである。パラメータ_tObjectIdは、オブジェクトを識別するためのものである。パラメータ_eSelectionStateは、オブジェクトの現在の選択状態を報告するものであり、ローカルインタラクティブアプリケーションのみで使用される。以下の状態がサポートされる。dscSelectionOKの値は、オブジェクトがこのメッセージとともに供給されることを示し、パラメータ_ptObjectによってアクセスすることができる。dscDelayedの値は、関連するSelectObjectCnfメッセージによって示された場合と比較して、オブジェクトの供給が遅延していることを示す。この場合、パラメータ_ptObjectは意味を持たない。
【０１２２】
dscTerminatedの値は、オブジェクトが放送されなくなり、供給することができないことを示す。この場合、パラメータ_ptObjectは意味を持たず、この選択は排除される。パラメータ_bCompleteObjectは、オブジェクトがこのメッセージとともに完全に供給されるか部分的に供給されるかを示す。このパラメータが真に設定された場合、完全なオブジェクトが供給される。このパラメータが偽に設定された場合、上述のようにオブジェクトは部分的に供給される。パラメータ_bObjectInvalidは、提示のためにアプリケーションに以前供給されたスライドショーオブジェクトの提示を停止しなければならないか否かを示す。このパラメータが真に設定された場合、オブジェクトの提示を停止しなければならない。例えば、画像をディスプレイから除去しなければならない。この場合、パラメータ_eSelectionState，_bCompleteObject，_ptObjectは意味を持たない。パラメータが偽に設定された場合、他のパラメータの意味によってメッセージの意味が決まる。
【０１２３】
オブジェクトの選択を停止するために、ステップ１１６において、ＡＰＩクライアント１５はSelectObjectReqメッセージをＡＰＩ１２に送り、これが、ステップＳ１１７において、SelectObjectCnfをＡＰＩクライアント１５に送ることによってＡＰＩ１２から確認される。これら両メッセージのパラメータは、上述のステップＳ１１２及びＳ１１３における場合と同様に定義される。
【０１２４】
そして、サービスを停止するために、ステップＳ１１８において、ＡＰＩクライアント１５は、SelectServiceReqメッセージをＡＰＩ１２に送り、ステップＳ１１９において、ＡＰＩクライアント１５にSelectServiceCnfメッセージを送ることによってＡＰＩ１２から確認される。これら両メッセージのパラメータは、上述のステップＳ１１０及びＳ１１１における場合と同様に定義される。
【０１２５】
図１２では、SelectObjectコマンドを使用せずに図１１において説明したように行われるステップＳ１００及びＳ１０１の、ＡＰＩクライアント１５からＡＰＩ１２へのSelectServiceReqメッセージを有するサービスの開始、及び、ＡＰＩクライアント１５にSelectServiceCnfメッセージを送ることによるＡＰＩ１２のコマンドの確認の直後、スライドショーオブジェクトを供給することもできる。この場合、ステップＳ１１４及びＳ１１５について説明したように定義されるステップＳ１０２〜Ｓ１０４に示すように、ObjectNtfメッセージを送ることによってＡＰＩ１２からＡＰＩクライアント１５に情報が供給される。その後、サービスを停止させるため、ステップＳ１０５において、ＡＰＩクライアント１５がSelectServiceReqメッセージをＡＰＩ１２に送り、これが、ステップＳ１０６において、ＡＰＩクライアント１５にSelectServiceCnfメッセージを送ることによってＡＰＩ１２から確認される。これら両メッセージのパラメータは、上述のステップＳ１００及びＳ１０１における場合と同様に定義される。
【０１２６】
利用可能な全放送ソースにおけるサービスのスキャン
放送環境における利用可能な全てのサービスの概要を得るために、Scanコマンドが設けられている。要求インターフェース１６を介したサービススキャンブロック１１へのScanコマンドの要求後、利用可能な全ての放送ソースの検索を開始し、各放送ソースでどのサービスが利用可能なのかを知るために放送ソースを１つずつ選択する。その結果は、サービスディレクトリブロック６によって供給されるサービスディレクトリに記憶され、ＡＰＩクライアント１５がアクセスすることができる。コマンドの処理中は、他のサービスにはアクセスできないことがある。これは、接続された放送受信機１３によって異なる。放送受信機が一時に１つの放送ソースへのアクセスしか行わない場合、他のアクセスは不可能である。
【０１２７】
検索方法は、例えば周波数範囲、周波数ステップ、方向等であり、ＡＰＩクライアント１５によって特定することができ、あるいはＡＰＩ１２によって自動的に行われる。このため、スキャンが継続している限り経過情報が与えられる。Scanコマンドは、図１４に示すように、ScanReqメッセージ、ScanNtfメッセージ、ScanCnfメッセージ機能によって構成される。Scanコマンドが実行され、ＡＰＩクライアント１５がサービスディレクトリからの通知を申し込んだ場合、サービスディレクトリにおける変更を通知するため、ServiceInfoNtfメッセージがＡＰＩ１２からＡＰＩクライアント１５に送られる。
【０１２８】
Scanコマンドメッセージ機能のインターフェースは、以下のように定義される。
【０１２９】
【表１６】
【０１３０】
まず、ステップＳ１２１において、ＡＰＩクライアント１５はScanコマンドを開始するためにScanReqメッセージをＡＰＩ１２に送る。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。検索方法は、１以上のパラメータ（SearchMethod）によって特定される。スキャンに長時間かかることがあるので、ＡＰＩクライアント１５はスキャン動作中に経過情報を要求してもよい。このため、パラメータNotificationsによって、例えば、各周波数ステップ後に所望の通知種類を特定することができる。
【０１３１】
その後、ステップＳ１２２〜Ｓ１２４に示すように、ＡＰＩ１２はＡＰＩクライアント１５に経過情報を供給するためにScanNtfメッセージを使用する。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別するためのものである。経過情報は、１以上のパラメータ（ProgressInfo）として供給される。
【０１３２】
そして、ステップＳ１２５において、ＡＰＩ１２は、ＡＰＩクライアント１５にScanCnfメッセージを送ることによって、Scanコマンドの処理の完了を報告する。パラメータ_tClientIdは送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKである場合、コマンドは成功であり、放送ソースが見つかっている。そうでない場合はエラーが発生している。いずれの場合も、現在選択されている放送ソース（CurrentBroadcastSource）及び現在の受信品質（ReceptionQuality）が報告される。
【０１３３】
放送ソースの選択によって、ＡＰＩクライアント１５は、この放送ソースに属する全ての情報サービスにアクセスを有する。他の放送ソースの情報サービスにアクセスするには、他の放送ソースを予め選択しておく必要があるが、サービスディレクトリブロック６が供給するサービスディレクトリによって、全放送ソースからの全サービスについての情報を得ることができる。これによって、ユーザに全サービスのリストを供給するアプリケーションプログラムを形成することができる。ユーザが、現在選択されているソースからあるサービスを選択する場合、SelectServiceコマンドのみ実行する必要がある。ユーザが、他の放送ソースからサービスを選択する場合、２つの選択肢が与えられる。ＡＰＩクライアント１５は、まずTuneコマンドを使用することによって放送ソースを選択し、次にSelectServiceコマンドを使用することによってサービスを選択する。あるいは、SelectServiceコマンドが他の放送ソースからのサービスについて実行される場合、ＡＰＩクライアント１５は、予めTuneコマンドを自動的に実行する。
【０１３４】
本発明を、Ｃ／Ｃ＋＋言語で実現される一実施例を用いて説明したが、これは限定ではなく、本発明を適用したＡＰＩ１２の機能を明確に説明するために用いたものであることは明らかである。他のプログラミング言語での実現やハードウェアによる実現も可能であり、同様の機能を示す。ＡＰＩ１２及び／又はＡＰＩクライアント１５については、１つの放送受信機内で又は別々の装置として実現することができる。これらをソフトウェアとして実現する場合、放送受信機内に又はそれぞれの装置内に配置することができる。あるいは、放送システムのチャンネルから、又は、放送受信機又はそれぞれの装置によってアクセスすることができる他のサーバからダウンロードすることができる。
【０１３５】
以下、本発明を適用した放送ＡＰＩの典型的な使用について、幾つかの現存の放送システムを用いて説明する。
【０１３６】
ＲＤＳ（ラジオデータシステム）を持たない標準ＦＭラジオは、ユーザインターフェースが１つである。すなわち、ＦＭラジオへのアクセスをユーザに与えるため、クライアントのみが放送ＡＰＩを同時に用いている。ＦＭラジオでは、通常、幾つかの放送ソースにアクセスする（周波数範囲８８〜１０８ＭＨｚ）。各放送ソースは、オーディオサービスを１つだけ提供する。オーディオサービスの処理はビルトインで行われる。すなわち、ＡＰＩによるサービスアクセスサポートは不要である。放送ソースを選択すると、自動的に１つのオーディオサービスのみが開始するとともに（サービス選択）、自動的にオーディオデータの処理が開始する（サービスアクセス）。移動環境では、受信品質は大きく変化する。しかし、非常に安価なものから高価なものまで広範囲のラジオが存在する。受信品質の監視は得られるときもあり、得られないときもある。
【０１３７】
オーディオサービスは、ＩＤ、ラベル、プログラム種類等の属性を有しない。したがって、ＦＭ信号からサービスディレクトリを作成することは不可能である。
【０１３８】
ＲＤＳを有するＦＭラジオは、上述のシステムと同じであるが、オーディオサービスについての更なる情報を与えるためにＦＭ信号とともに送られる追加データを有する。追加情報は、ＩＤ（Oxd999）、ラベル（"SWF3"）、プログラム種類（"POP"）、アナウンスメントサポート及びスイッチング（スポークントラフィックメッセージ）、ラジオテキスト（”追加テキスト情報”）からなる。これによって、幾つかの放送ソースを属性とともに有するサービスディレクトリを形成することができる。これは、あるプログラム種類（"Pop"）に合うサービスを選択するため、あるいは、ラベル（"SWF3"、"Antenne1"）に基づく１以上のリストからサービスを選択するのに使用することができる。一時に１つのオーディオサービスしか動作しないが、ラジオテキストスライドショーを付加的に行うことができる。
【０１３９】
通常のテレビジョン受像機は、クライアントが１つである。幾つかの利用可能な放送ソースから１つの放送ソース（チャンネル）を選択することができる。放送ソース毎に１ビデオストリームサービスが得られる。ラベル、タイム、ProgramInfo等の追加情報は、ビデオテキストによって示される。ビデオテキストは、テキスト情報を有するローカルインタラクティブサービスを提供する。ビデオ処理はビルトインで行われ、ビデオテキストデコーダもサポートされるならば得られる。しかし、ページへのアクセスにはサービスアクセスブロック９が必要である。サービスアクセスブロック９によって、ビデオテキストページをナビゲートすることができ、スライドショー効果はメインページ及びサブページに使用されることが多い。
【０１４０】
固定型の動作及び／又はケーブルネットワークであるため、受信状態が障害を受けることは稀である。
【０１４１】
チャンネルを選択するのに放送ソース選択が必要である。これによって、自動的にビデオサービスが開始する。ビデオテキストアクセスは、クライアントによる要求で開始する（サービス選択）。ビデオテキスト復号化は、より高速なアクセスを行うために予め開始されている。
【０１４２】
サービススキャンでは、全てのサービス（ビデオストリーム及びビデオテキスト）の検索を行い、それらを所定のボタンで自動的に記憶する。これらのサービスをサービスディレクトリに記憶し、現在使用されているチャンネル番号の代わりにチャンネル名リストを与えることも可能である。
【０１４３】
例えば、いかなる種類の金融情報にもアクセスする受信機等、特殊な受信機は、ＤＡＢ等の標準放送システムに基づくこともできるが、特定情報へのアクセスしか得られない。
【０１４４】
放送システムの構成として幾つかの構成が可能である。例えば、サーバＰＣに接続された１ハードウェア受信機と、ＰＣワークステーション上で動作する幾つかのクライアントアプリケーションとを有し、ローカルネットワークを介して情報にアクセスする構成がある。以下に示す構成が可能である。
【０１４５】
・１又は幾つかのクライアント。
【０１４６】
・１又は幾つかの放送ソース。
【０１４７】
・金融情報、ニューステキスト、ニュースティッカ、ハイパーテキスト、ニューススライドショー、株データ等を有する幾つかのサービス。
【０１４８】
・１放送ソースでは放送ソース選択は不要だが、２以上では必要。
【０１４９】
・２以上のサービスで異なる種類（ハイパーテキスト、ニュースティッカ）の場合、サービス選択が必要。
【０１５０】
・サービスマルチプレクスは変更してもよい。
【０１５１】
・サービスディレクトリによって柔軟なサービスマルチプレクスが可能である。
【０１５２】
・１放送ソースではサービススキャンは行わない。
【０１５３】
・例えば、株価を提供する場合、受信品質の監視は重要である。
【０１５４】
フルＤＡＢ及び／又はＤＶＢシステムには、本発明の好ましい実施例で説明したビルディングブロックの全機能が含まれている。
【０１５５】
一般に、放送ＡＰＩのビルディングブロックには必須のものと任意のものとがあるが、これは、この分野のサポートがクライアント（アプリケーション）にとって必要／有用であるか否かに常に関連している。例えば、１放送ソースにしかアクセスしないシステムの場合、放送ソース選択は不要である。これは、放送ソースを全く選択しなくてよいということではない。１放送ソースしか選択できず、ＡＰＩの基本システムによって自動的に選択が行われる、ということである。
【０１５６】
フルシステムにおいては、全てのビルディングブロックが必要であることは明らかである。実際のシステムの制限によって、サブセットのみが必要である。幾つかの簡単なシステムでは、除去することができるブロックもあり、合体することができるブロックもあるが、これは機能についてのみ有効である。ビルディングブロックのインターフェースを変更することが必要なときもある。その結果、新たなビルディングブロックが定義される。
【０１５７】
一般に、機能とそれに対応するビルディングブロックが必須であるか任意であるかの決定は容易になる。
【０１５８】
・２以上の放送ソースが利用可能であるときは必ず放送ソース選択が必要であり、選択されたいずれの放送ソースからも全サービスがわかるわけではない。他の全ての放送ソースにおける全サービスについての情報がわかる場合、システムは、スタートアップ後に１放送システムを選択し、利用可能な全てのサービスについて情報を得る。この場合、サービス選択を行うことで、サービスにアクセスするのに十分である。
【０１５９】
・提供されたサービスが予めわかっていないとき、また、提供されたサービスのセットを変更することができるとき、サービスディレクトリが必要である。幾つかの放送ソースがあり、選択された放送ソースにおけるサービスが限定的にしか示されていない場合、サービスディレクトリによって、再チューニングを行わずに利用可能な全サービスのリストを得ることができる。クライアントは、動的変更についての情報を得ることができる。
【０１６０】
・１放送ソースにおいて２以上のサービスが利用可能であるとき、また、２以上のサービスを同時に動作させるため、サービス選択が必要である。
【０１６１】
・更なる処理を行うためにデータをアプリケーションに供給する必要があるとき、サービスアクセスが必要である。
【０１６２】
・受信品質が動作中に変化する可能性があるとき、受信品質が必要である。
【０１６３】
・サービススキャンによって、サービス選択が容易になり、良好なユーザインターフェースを形成することができる。
【０１６４】
・２以上のクライアントがＡＰＩを用いているとき及び／又はインターフェーシングが必要なとき、クライアント登録が必要である。
【０１６５】
本発明を適用した放送ＡＰＩの他の適用例として、ＡＰＩクライアント１５に限定的なアクセスのみを提供する。すなわち、例えば、ＪａｖａＡｐｐｌｅｔは完全なＤＡＢ受信機の一部賭して動作している。ＤＡＢへのアクセスは、ＤＡＢ受信機の適応部分によって制御されるが、ＪａｖａＡｐｐｌｅｔは、例えば、ＤＡＢを介してダウンロードされ、あるデータサービスを提示する。したがって、サービスアクセスブロック９にアクセスする必要があり、他のブロックへのアクセスはできない。
【０１６６】
【発明の効果】
放送システムによって提供される情報サービスにクライアントがアクセスすることを可能にするアプリケーションプログラミングのインターフェース装置において、アプリケーションプログラミングのインターフェース装置内のビルディングブロックの情報サービスの処理を行う各機能を全て定義する要求サブインターフェースを有し、ビルディングブロックは、要求サブインターフェースを介してアドレス及び／又は要求される。これによって、クライアントは、放送システムの詳細を知らないでも、インターフェース装置を介して所望の情報サービスにアクセスすることができる。
【図面の簡単な説明】
【図１】本発明を適用したＡＰＩを有するデジタル放送システムの受信機のモデルを示すブロック図である。
【図２】本発明を適用したコマンドパターンの流れを示す図である。
【図３】本発明を適用したコマンドパターンの流れを示す図である。
【図４】本発明を適用したコマンドパターンの流れを示す図である。
【図５】本発明を適用したＡＰＩ及びＡＰＩクライアントを示すブロック図である。
【図６】本発明を適用したクライアント登録の流れを示す図である。
【図７】本発明を適用したチューンコマンドメッセージ通信の流れを示す図である。
【図８】本発明を適用した検索コマンドメッセージ通信の流れを示す図である。
【図９】本発明を適用したるselectreceptioninfoコマンドメッセージ通信の流れを示す図である。
【図１０】本発明を適用したselectserviceinfoコマンドメッセージ通信の流れを示す図である。
【図１１】本発明を適用したselectserviceコマンドメッセージ通信の流れを示す図である。
【図１２】本発明を適用したスライドショー処理の流れを示す図である。
【図１３】本発明を適用したハイパーテキストサービスの流れを示す図である。
【図１４】本発明を適用したスキャンコマンドメッセージ通信の流れを示す図である。
【図１５】ＤＡＢ規格による放送ソース信号のモデルを示す図である。
【図１６】従来の放送データのオブジェクト流れを示す図である。
【符号の説明】
４ アプリケーションプログラム、５ クライアント登録ブロック、６ サービスディレクトリブロック、７ 放送ソース選択ブロック、８ サービス選択ブロック、９ サービスアクセスブロック、１０ 受信品質ブロック、１１ サービススキャンブロック、１２ ＡＰＩ、１３ デジタル放送システム受信機
【発明の属する技術分野】
本発明は、デジタル放送システムによって提供される情報サービスを利用するためのアプリケーションのインターフェースに関する。特に、本発明は、放送システムにおける受信機を制御するとともに、放送信号のチャンネルで搬送されるコンテンツへのアクセスを提供するアプリケーションプログラミングのインターフェース装置（以下、ＡＰＩと称する）に関する。
【０００２】
【従来の技術】
以下、本発明の背景について、ＤＡＢ規格「無線放送システム：移動、携帯及び固定受信機に対するデジタル音声放送（ＤＡＢ）（Radio broadcasting systems: Digital Audio Broadcasting (DAB) to mobile, portable, and fixed receivers）」、ETSI, ETS 300 401, １９９７年５月、第２版を例として説明する。ＤＡＢ規格は、送信側から任意数の受信側への種々の情報サービスの送信をサポートするデジタル放送システムを実現するための国際規格である。この情報サービスの例としては、オーディオストリームアプリケーション、ビデオストリームアプリケーション、ハイパーテキストアプリケーション、画像又はテキストスライドショーアプリケーション、ニュースティッカアプリケーション、Ｊａｖａベースアプリケーション等がある。
【０００３】
１つのＤＡＢ放送信号によって、約１．５Ｍｂｉｔ／ｓの速度で伝送されている情報に同時にアクセスすることができる。このような信号はアンサンブルと呼ばれる。１つのＤＡＢ受信機は、同じ位置において２以上のアンサンブルを受信することができるが、一度には１つしか受信することができない。各アンサンブルは、１つのサービスのみ又は多数のサービスを有するＤＡＢ信号を表している。アンサンブルは、異なる種類のアプリケーションを有するサービスを組み合わせることができる。一般的な例として、幾つかのラジオ局（オーディオストリームアプリケーション）と、ハイパーテキストアプリケーション又はスライドショーとして提供される気象、金融、イベント、ニュース等の情報サービスとにアクセスするアンサンブルがある。一般的に、これらの全てのサービスは、同一のアンサンブルに属しているときは、同時にアクセスすることができる。
【０００４】
図１５は、放送のソース信号の１タイムフレームの一般的な構造を示すフォーマットである。このタイムフレームは、ある周期、例えば２４ｍｓで繰り返される。タイムフレームは、同期チャンネル１、サービス情報チャンネル２、所定数（Ｎ）のサービスチャンネル３（サービス＃１〜＃Ｎ）によって構成される。デジタル放送システムの受信機は、同期チャンネル１を用いて信号の同期をとる。サービス情報チャンネル２は、利用可能なサービスの数、これらのサービスによって提供される情報の種類、これらのサービスへのアクセス方法についての情報を提供する。各サービスチャンネル３は、サービスデータを提供する。通常、これらのデータは、データ放送に適したフォーマットに符号化されている。
【０００５】
ＤＡＢシステムは、固定、携帯、移動の各環境において受信できるように設計されている。特に、移動環境では、受信状態が刻々変化する。受信品質は、受信障害のない状態、時折受信障害が発生する状態、全く受信できない状態等の様々である。ハードウェア又はソフトウェアのアプリケーションは、これらの様々な状態に対応しなければならない。受信障害は、移動環境においては一般的に発生し、その障害がユーザに感知されないようにしなければならない。各受信障害をエラーとして取り扱うのは適切ではない。したがって、アプリケーションには、受信状態に適切に対応できるように、受信状態を監視する手法を設ける必要がある。
【０００６】
双方向通信環境では、クライアントがある情報を要求する。配信される情報は、クライアントとサーバ間の現在のコンテキストの状態によって識別される。一方、一方向放送環境では、多数のクライアントのための情報が伝送される。したがって、データは、関係がある情報のみを抽出するために、自己記述的でなければならない。この情報は、全体としてサービスに関するものであれば、一般的にサービス情報チャンネル２で配信され、各サービスの情報オブジェクトのいずれかに関するものであれば、サービスチャンネル３のうちの１つで配信される。各サービスチャンネル３は、配信される情報に対してシステム固有のフォーマットを用いる。
【０００７】
【発明が解決しようとする課題】
本発明は、上述した実情に鑑みてなされたものであり、システム固有の符号化方式をわからせずに、またシステムに依存せずに、情報をアプリケーションに配信するために、情報サービスにアクセスするアプリケーションプログラミングのインターフェース装置を提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明の目的は、請求項１に記載するアプリケーションプログラミングのインターフェース装置及び請求項３１に記載するクライアントによって達成することができ、その好適な実施例については、それぞれ従属する請求項に定義される。
【０００９】
本発明を適用したＡＰＩ及びクライアントは、一方向放送受信機のクライアント／放送受信機インターフェースに対して双方向通信環境の機能を実現する。これは、クライアントが、ＡＰＩの全機能を定義するＡＰＩの独自要求サブインターフェースを介してＡＰＩに要求を送ることができ、また、ＡＰＩが、ＡＰＩによって定義される確認通知サブインターフェースを介して、要求された情報を含むことが可能な確認及び／又は通知メッセージをクライアントに送ることができるからである。
【００１０】
サービスのアクセス構造は、提供されるサービスの種類によって異なる。ラジオ番組等のオーディオストリームを有するサービスの場合、送信されるデータは全て、アプリケーションに受信及び供給されて処理されなければならない。ユーザが情報オブジェクト（例えば、ハイパーテキスト）のセットを自由にナビゲートするようなアプリケーションの場合、全ての情報が周期的に放送され、要求された情報のみが放送から抽出される。典型的なデータの流れを図１６に示す。図１６では、ある文書、すなわち、default.html、pic1.jpg、xyz.html、pic2.jpg、News.html、abc.htmlが周期的に放送される。一連の画像又はテキストをユーザに提供するスライドショーアプリケーションの場合、受信障害に対処するため、情報を提供すべきときに送信するか、あるいは、予め何度か情報を送信しておく。これらの場合、アプリケーション処理に対するサポートが与えられれば、アプリケーションプログラマ又は設計者が行う作業は簡単になる。
【００１１】
ハイパーテキストアプリケーションでは、あるＨＴＭＬページを参照するリンクがクリックされた後に、このページの要求がＡＰＩに与えられる。本発明を適用したＡＰＩの基礎となるシステムは、このページに対するフィルタを設定し、それが放送されるまで聴く。受信後は、このページはアプリケーションに提供される。受信後に要求を取り消してもよく、ＡＰＩは、放送を聴いて要求されたページの更新をアプリケーションに通知することができる。ＡＰＩによって供給されるこのアプリケーション処理サポートは、２以上のアプリケーションが同時にサービスにアクセスしているときや、キャッシュを考慮するときに特に有用である。後者の場合、アクセス時間を改善するため、受信したオブジェクトのコピーを記憶するためにメモリが使用される。したがって、基礎となるＡＰＩがサービスのアクセスを提供すれば、アプリケーションにとっては得である。
【００１２】
本発明は、放送システムによって提供される情報にアクセスするためのアプリケーションプログラミングのインターフェース装置を提供することがわかる。これは、いわゆるハイレベルＡＰＩであり、コマンドとして表す概念がアプリケーションプログラマ又は設計者のニーズを反映するようにされたものである。この分野のアプリケーションプログラマ又は設計者の作業は、情報サービスを魅力的なものとして提供することである。このため、アプリケーションプログラマ又は設計者は、不要なシステム固有の詳細事項に関心を持たない。本発明によれば、ハイレベルＡＰＩによって双方向通信環境が形成されるので、アプリケーションの開発時間が改善され、第三者によるアプリケーション形成の許容が増す。
【００１３】
さらに、ＡＰＩは、放送システムによって提供される情報サービスへのアクセスの全ての面を含む。すなわち、放送媒体及び提供されるサービスのコンテンツ自体へのアクセスを得るのに必要なデジタル放送システムの受信機を制御する。
【００１４】
放送システムでは、クライアントは送信装置において必要な情報を要求しない。その代わり、受信機で何が放送されるか聴き、所望の情報を抽出する必要がある。一般に、放送信号の構成はいつでも変化する可能性があり、情報オブジェクトへのアクセス時間は、双方向通信に基づく情報システムにおけるよりも大きく変化する可能性がある。これらの要件は、放送システム固有のものである。本発明を適用したＡＰＩによって、これらの詳細事項はアプリケーションプログラマにとって問題とはならず、異なる提供フォーマットでの情報サービスの処理をサポートする。本発明を適用したＡＰＩに接続されたクライアントは、必要な情報を要求することができ、この情報が利用可能になると直ちに要求しているクライアントに提供される。ＡＰＩのインターフェースは、アプリケーションプログラムとＡＰＩによって制御される放送システムとの高度のシステム始動通信に非常に良く合致する非同期メッセージ通信に基づくものである。
【００１５】
ＡＰＩは、幾つかのクライアントに対するサポートを同時に提供する。すなわち、２以上のクライアントがＡＰＩのサービスを使用することによって、リソースを共有することができる。
【００１６】
以下の本発明の詳細な説明では、本発明を適用したＡＰＩがＡＰＩの機能に関して非常に記述的であるＣ／Ｃ＋＋言語ソリューションで実現されるようなＤＡＢ受信機を用いて説明を行う。勿論、本発明は、他の放送システムに適用することもでき、例えばＡＰＩのハードウェアソリューション等の他のソリューションを有することもできる。
【００１７】
例におけるデジタル放送システムの受信機の制御の機能的分解は、以下のようになる。すなわち、放送ソースの選択、サービス情報チャンネルへのアクセス、サービスの選択、サービスコンテンツへのアクセス、受信状態の監視である。
【００１８】
デジタル放送システムの受信機の制御は、通信がサービスプロバイダからサービス消費者への一方向のみであることを示す。受信機は、何が放送されるか常に聴き、所望の情報を抽出しなければならない。放送データに変更があれば、放送を聴くことによって検知される。新たなサービスを追加することも、サービスを削除することもできる。あるサービスデータの流れにおけるオブジェクトの追加、削除、更新を行うこともできる。データの流れで放送されるオブジェクトへのアクセス時間は、数ミリ秒〜数分と広範囲で変化する。本発明を適用したＡＰＩでは、これをメッセージベースアプローチによって考える。
【００１９】
【発明の実施の形態】
以下、本発明に係るアプリケーションプログラミングのインターフェース装置及びその使用方法について、図面を参照しながら説明する。図１は、幾つかのアプリケーションプログラムを含む本発明を適用した具体的なモデルを示すブロック図である。
【００２０】
図１に示すように、アプリケーションプログラム４（以下、ＡＰＩクライアントともいう。）は、ＡＰＩ１２を用いてユーザに放送情報サービスを提供する。
ＡＰＩ１２自体は、例えばアンテナ１４を備えるデジタル放送システム受信機１３を介して、受信機制御ブロック１８により放送データにアクセスする。ＡＰＩ１２自体の典型的な構造は以下のようになる。受信機制御ブロック１８は、接続されたデジタル放送システム受信機１３のローレベル制御を行う。図１では、受信機制御ブロック１８とデジタル放送システム受信機１３を、何らかの手段で接続された個別のブロックとして示しているが、本発明は、この具体例に限定されるものではない。すなわち、この部分を１つのブロックに統合することもできる。本発明では、受信機制御ブロック１８の上方に示されるビルディングブロック５〜１１は全て、受信機制御ブロック１８によって提供されるサービスに基づくものである。
【００２１】
図１に示す具体例において、ＡＰＩ１２は、以下のビルディングブロック５〜１１を有する。
【００２２】
・クライアント登録ブロック５は、ＡＰＩクライアントの登録サービスを提供する。ＡＰＩ１２を使用しようとする各アプリケーションプログラム４は、予めＡＰＩクライアントとして登録する必要がある。登録によって、各ＡＰＩクライアントは、他のＡＰＩクライアントと識別するために、全ての準逐次コマンド（subsequent command）で使用されるクライアントＩＤを得る。
【００２３】
・サービスディレクトリブロック６は、１つ以上の放送ソースの利用可能なサービスに関する情報を提供する。
【００２４】
・放送ソース選択ブロック７は、放送ソースを直接選局する、又は放送ソースを検索する手段を提供する。
【００２５】
・サービス選択ブロック８は、サービスを開始又は停止するのに用いられる。
【００２６】
・サービスアクセスブロック９は、サービスのコンテンツにアクセスする手段を提供する。
【００２７】
・受信品質ブロック１０は、受信品質を監視する手段を提供する。
【００２８】
・サービススキャンブロック１１によって、ＡＰＩクライアントは、特定の検索領域の全ての利用可能な放送ソースにおける全ての利用可能なサービスを検索することができ、これによって、サービスディレクトリが更新されるとともに、申し込んだ情報に関する変更がＡＰＩクライアントに通知される。
【００２９】
各コマンドは、概して２つ又は３つのメッセージ種類に分類される。要求メッセージ(-)Reqは、ＡＰＩクライアントによってＡＰＩ１２に送られ、コマンドの実行が要求される。確認メッセージ(-)Cnfは、ＡＰＩ１２によってＡＰＩクライアントに送られ、コマンドの実行が確認される。通知メッセージ(-)Ntfは、長期間継続するコマンドの経過について通知するために、又は更新された情報を提供するために、ＡＰＩ１２によってＡＰＩクライアントに送られる。
【００３０】
各アプリケーションプログラム４は、その必要な情報に関する要求をＡＰＩ１２の要求サブインターフェース１６を介してビルディングブロック５〜１１のうちの１つ又は幾つかに送り、ビルディングブロック５〜１１のうちの１つ又は幾つかは、それらの情報を確認通知サブインターフェース１７を介してアプリケーションプログラム４、すなわちＡＰＩクライアントに提供する。
【００３１】
図２〜図４は、本発明を適用したこれらの３つのメッセージの異なる組合せによって、コマンドが形成されることを示す図である。
【００３２】
図２は、Req-Cnfコマンドのパターンを示す図であり、ステップＳ１において、要求メッセージがＡＰＩ１２に送られ、ステップＳ２において、コマンドが実行され、実行結果を提供する確認メッセージがＡＰＩクライアントに送られる。
【００３３】
図３は、処理に長い時間がかかるコマンドに使用されるReq-Ntf-Cnfコマンドのパターンを示す図である。ステップＳ３において、要求メッセージがＡＰＩ１２に送られ、ステップＳ４〜Ｓ６において、コマンドの実行が開始され、この具体例では、経過情報を提供する３つの通知メッセージがＡＰＩクライアントに送られ、ステップＳ７において、実行結果を提供する確認メッセージがＡＰＩクライアントに送られる。
【００３４】
図４は、申込サービスを提供するコマンドに使用されるReq-Cnf-Ntfコマンドのパターンを示す図である。この場合、ステップＳ８において、ある情報、例えば受信品質の配信を申し込む要求メッセージがＡＰＩ１２に送られる。ステップＳ９において、ＡＰＩ１２から、申込を確認する確認メッセージが、要求しているＡＰＩクライアントに送られる。ステップＳ１０〜Ｓ１２において、要求された情報自体が与えられた通知メッセージ、この具体例では３つの通知メッセージが送られる。すなわち、現在の状態を報告する通知メッセージが最初に送られ、申し込んだ情報が変更される毎に、通知メッセージが必ず送られる。この申込サービスは、他のコマンド実行によって取り消されるまで継続される。なお、現在の状態のみを要求し、必要ではないときは更新を要求しないようにしてもよい。この場合、申込サービスは、関連する通知メッセージによって、要求された情報の配信とともに自動的に取り消される。
【００３５】
本明細書で用いるメッセージという用語は、アプリケーションプログラマ又は設計者に全体として利益を与えるコマンド及びコマンドの実行と区別する必要がある。コマンドの実行は、非同期インターフェース手段を得るために、ＡＰＩ１２とＡＰＩクライアント間で送られる幾つかのメッセージに分割される。これによって、コマンドを同時に実行することができ、ＡＰＩクライアントは、長期間継続するコマンドを実行するときに阻止されることはない。これは、デジタル放送システム受信機１３の上述した特徴に合致する。メッセージという用語を用いることによって、本発明の範囲を、ＡＰＩ１２とＡＰＩクライアントをメッセージシステムによって接続した具体例に限定するものではない。
【００３６】
図５は、以下、本発明の説明に用いるＡＰＩ１２とＡＰＩクライアント１５をインターフェースさせる適切なモデルを示す図である。インターフェースは、ＡＰＩ１２によって定義されるが、要求インターフェース１６は、ＡＰＩ１２内に設けられ、確認通知インターフェース１７は、ＡＰＩクライアント１５に設けられる。以下の実施例では、機能エントリポイントを有するインターフェースとして各インターフェースを実現している。すなわち、メッセージ毎に１つの機能が設けられ、ＡＰＩクライアント１５によって要求メッセージのために呼び出されるとともに、ＡＰＩ１２によって確認及び通知メッセージのために呼び出される。
【００３７】
以下のＡＰＩの説明は、記述的Ｃ／Ｃ＋＋プログラム言語（descriptive c/c++ program language）で表記するが、これは、本発明の範囲を限定するものではない。上述のように、Ｊａｖａ、パスカル、ベーシック等の他のプログラミング言語や、ハードウェアソリューションを用いることもできる。
【００３８】
説明では、以下に示すＡＰＩ表記（convention）を適用する。
【００３９】
接尾辞としての大文字Ｅは、列挙型（enumeration type）を表す。列挙型によって、異なる定数値についての幾つかのシンボル名（symbolic name）を定義することができる。
【００４０】
接尾辞としての大文字Ｔは、データタイプを表す。データタイプ（data type）は、変数の値のみを記憶する手段を有するタイプ、又はある処理を行う機能をさらに含むタイプである。
【００４１】
接尾辞としての大文字ＰＴは、データタイプについてのポインタを表す。
【００４２】
あるデータタイプの変数は、そのデータタイプを示すために接頭辞を有している。小文字ｅは、列挙型の変数を表す。小文字ｂは、タイプブール（type bool）の変数を表す。本発明のドメイン（domain）に関して定義される他のデータタイプを、小文字ｔで表す。機能シグネチャ（function signature）における形式パラメータ（formal parameter）として用いられる変数は、下線が付された第１文字（first character）を有する。
【００４３】
以下の基本データ構造は、ＡＰＩを介して用いられるものである。
【００４４】
ResultE：コマンド実行状態が報告されるときに必ず使用される。この種類のマッピングは、ＡＰＩ１２が用いられる基本システムによって異なる。概して、列挙型として用いられ、異なる定数値について幾つかのシンボル名を定義することができる。各値は、別のコマンド実行状態を表す。共通の値のセットを以下のように定義する。
【００４５】
resOK：コマンドの実行は成功した。
【００４６】
resInvalidParameter：無効パラメータのためにコマンドは実行できなかった。
【００４７】
resNonApplicableFunction：現在の状態ではコマンドは実行できない。
【００４８】
これらは、単に基本的なエラーコードのセットの具体例である。放送情報システムでは、このセットを、何ら発明的技術を用いずに、システムの能力に応じてより詳細なエラーコードによって、容易に拡張することができる。
【００４９】
ClientIdT：ＡＰＩクライアント１５のＩＤのデータタイプとして使用される。このデータタイプの内部構造は、実際の実現方法に依存する。このデータタイプは、ＡＰＩ１２の基本システムによって定義される。各ＡＰＩクライアント１５は、ＡＰＩ１２と接続するときにこのデータタイプのＩＤを取得して、全ての準逐次コマンドに対して異なるＡＰＩクライアント１５を識別するのに用いられる。
【００５０】
ServiceIdT：放送情報サービスのＩＤのデータタイプとして使用される。このデータタイプの内部構造は、実際の実現方法に依存する。このデータタイプは、ＡＰＩ１２の基本システムによって定義される。サービスは、サービスディレクトリブロック６によって提供されるサービスディレクトリによって、サービスＩＤ及び他の属性とともに報告される。ＡＰＩクライアント１５は、サービスＩＤを用いてサービスに対する情報を得て、サービスの開始又は停止を行う。
【００５１】
ObjectIdT：例えば、ハイパーテキストページ、イメージ等の情報オブジェクトのＩＤのデータタイプとして使用される。このデータタイプの内部構造は、実際の実現方法に依存する。このデータタイプは、ＡＰＩ１２の基本システムによって定義される。オブジェクトＩＤは、ＡＰＩクライアント１５によってオブジェクトの提供を要求したり、提供されたオブジェクトを識別するのに使用される。
【００５２】
ObjectT：ある情報オブジェクトのコンテンツや、ある画像の有効期限又はテキスト記述等のオブジェクトに関する追加的な属性にアクセスするデータタイプとして使用される。このデータタイプの内部構造は、実際の実現方法に依存する。このデータタイプは、ＡＰＩ１２の基本システムによって定義される。各オブジェクトはオブジェクトＩＤによって識別される。
【００５３】
bool：値を真及び偽とすることができる演算データタイプ（boolean data type）。
【００５４】
以下の機能シグネチャにおけるパラメータの中には、イタリック体で記述されるものがある。これらのパラメータは、ＡＰＩ１２の基本システムと強い関連がある。すなわち、これらのデータタイプの詳細な定義は、基本システムに強く依存し、この記述では定義できない。ある放送システムがビットエラーレートを監視する手段を提供し、他のシステムが同期状態を監視する手段を提供し、さらに他のシステムがこれらの組合せ又は他のパラメータを監視する手段を提供することがある。システム専用の要件をマップする適切な方法は、１又は２以上のパラメータを使用することである。このような場合、正確なデータタイプの定義を付ける必要性があることを示すために、あるパラメータをイタリック体で記述する。当該技術分野の技術者にとっては、本発明の主旨を逸脱しない範囲でコマンドメッセージの定義を変更してもよいことは明らかである。
【００５５】
以下の具体例は、要求インターフェース１６と確認インターフェース１７のインターフェースの定義を示すものでる。
【００５６】
【表１】
【表２】
【表３】
【表４】
【表５】
【表６】
【表７】
ＡＰＩクライアント１５とＡＰＩ１２の２つのインスタンス（instance）は、これらのインターフェースを介して接続される。すなわち、ＡＰＩ１２は、要求インターフェース１６を実現し、ＡＰＩクライアント１５は、この要求インターフェース１６用い、要求インターフェース１６のインターフェース機能を呼び出すことによってＡＰＩ１２に要求メッセージを送る。ＡＰＩクライアント１５は、確認インターフェース１７を実現し、ＡＰＩ１２は、確認インターフェース１７を用い、確認通知インターフェース１７のインターフェース機能を呼び出すことによってＡＰＩクライアント１５に確認及び通知メッセージを送る。
【００６４】
以下、全てのコマンド及びメッセージの機能について詳細に説明する。コマンドとメッセージを使用する典型的な例を、メッセージシーケンスチャートに示す。なお、これらのチャートは、誤動作を考慮していない単純なシナリオを示すものである。記述したコンテキストにおいて重要なパラメータのみを列挙する。
【００６５】
クライアント登録
ＡＰＩ１２を使用しようとするアプリケーションプログラムはいずれも、図６に示すように、他のコマンドを実行する前にＡＰＩクライアント１５としてＡＰＩ１２に接続する必要があり、また、ＡＰＩコマンドの使用が終わると切断する必要がある。このような登録及び切断は、クライアント登録ブロック５を介して行われる。Openコマンドは、ＡＰＩクライアント１５を登録し、必要な全てのリソースを割り当て、全ての準逐次コマンドに使用されるクライアントＩＤを与える。ＩＤは、２つ以上のＡＰＩクライアント１５が同時にＡＰＩ１２を用いる場合に必要である。Openコマンドは、OpenReq及びOpenCnfメッセージによって構成される。Closeコマンドは、動作している全てのサービスを停止し、呼出を行っているＡＰＩクライアント１５のために取得されたリソースを解放し、ＡＰＩクライアント１５とＡＰＩ１２を切り離す。また、ＡＰＩコマンドを実行するためには、Openコマンドを予め実行する必要がある。Closeコマンドは、CloseReq及びCloseCnfメッセージによって構成される。ＡＰＩクライアント１５は、OpenコマンドとCloseコマンドの間に、ＡＰＩ１２を介してデジタル放送システム受信機１３の制御を行うか、あるいは単に提供されるサービスを「聴く」、すなわちコマンドを実行することができる。
【００６６】
Open及びCloseコマンドメッセージ機能のインターフェースは、以下のように定義される。
【００６７】
【表８】
まず、接続を開くために、ステップＳ４０において、ＡＰＩクライアント１５は、OpenReqメッセージをＡＰＩ１２に送り、ＡＰＩクライアント１５の確認通知インターフェース１７に対するポインタ（_ptInterface）が与えられる。ＡＰＩ１２は、ＡＰＩクライアント１５とＡＰＩ１２間の通信で発生する全ての確認及び通知メッセージを、この確認通知インターフェース１７に送る。
【００６９】
その後、ステップＳ４１において、ＡＰＩ１２は、Openコマンドの処理を報告するOpenCnfメッセージをＡＰＩクライアント１５に送る。パラメータ_eResultは、接続を確立することができたか否かを示す。値がresOKであるときは、接続が確立され、パラメータ_tClientIdによって、全ての準逐次コマンドに使用される有効ＩＤが与えられる。パラメータ_eResultによって報告される値が他の値であるときは、常にOpenコマンドは失敗し、接続は確立されない。この場合、パラメータ_tClientIdは、有効な値を有しない。
【００７０】
そして、コマンドが実行された後、ＡＰＩクライアント１５がＡＰＩコマンドの使用を終了すると、ステップＳ４２において、ＡＰＩクライアント１５は、CloseReqメッセージをＡＰＩ１２に送って、接続を閉じる。このメッセージの唯一のパラメータは、呼出を行っているＡＰＩクライアント１５を識別するためのクライアントＩＤである。そして、ステップＳ４３において、ＡＰＩ１２は、CloseCnfメッセージをＡＰＩクライアント１５に送ることによって、Closeコマンドの処理を報告する。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKであるときは接続が閉じられ、そうでないときはエラーが発生している。
【００７１】
放送ソースの選択
デジタル放送システム受信機１３によって提供されるコンテンツにアクセスするために、ＡＰＩクライアント１５は、放送ソース選択ブロック７を介して放送ソースを選択する。概して、放送ソースは直接選択することができるか、あるいはデジタル放送システム受信機１３が放送ソースを自動的に検索する何らかの手段を有している。したがって、２つのコマンドが設けられている。
【００７２】
Tuneコマンドは、放送ソースを直接選択するためのものである。ＡＰＩクライアント１５は、どこに放送ソースが位置するか知っており、必要なパラメータは、全てＡＰＩクライアント１５によって与えられるものとする。Tuneコマンドは、図７に示すように、TuneReq及びTuneCnfメッセージ機能によって構成される。
【００７３】
Searchコマンドは、放送ソースを検索するためのものである。検索方法は、例えば周波数範囲、周波数ステップ、方向等であり、ＡＰＩクライアント１５によって特定することができ、あるいはＡＰＩ１２によって自動的に行われる。検索は長時間かかるものと考えられる。したがって、検索が継続している限り経過情報が提供される。Searchコマンドは、図８に示すように、SearchReq、SearchNtf、SearchCnfメッセージ機能によって構成される。
【００７４】
Tune及びSearchコマンドメッセージ機能のインターフェースは、以下のように定義される。
【００７５】
【表９】
図７に示すように、ステップＳ５０において、ＡＰＩクライアント１５は、Tuneコマンドを開始するために、TuneReqメッセージをＡＰＩ１２に送る。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。放送ソースは、１又は幾つかのパラメータ（BroadcastSource）によって特定される。ＡＰＩ１２によるメッセージの受信後、特定された放送ソースへの同調（選局）が開始される。選局が行われた後、現在の受信品質が検出される。そして、ステップＳ５１において、ＡＰＩ１２からＡＰＩクライアント１５へのTuneCnfメッセージによって、コマンドの処理結果が報告される。これは、送信先のクライアント（_tClientId）を識別し、処理結果（_eResult）を示す。処理が成功したときは、パラメータ_eResultはresOKという値を示すが、そうでないときはエラーが発生している。処理結果とは独立して、現在選択されている放送ソース（CurrentBroadcastSource）及び現在の受信品質（ReceptionQuality）が報告される。
【００７７】
図８に示すように、ステップＳ６０において、ＡＰＩクライアント１５は、Searchコマンドを開始するため、SearchReqメッセージをＡＰＩ１２に送る。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。検索方法は。１つ以上のパラメータ（SearchMethod）によって特定される。検索には長時間がかかるので、ＡＰＩクライアント１５検索動作中に経過情報を要求することもある。このため、パラメータNotificationsによって、例えば各周波数ステップ等の所望の通知の種類を特定することができるようになっている。
【００７８】
その後、ステップＳ６１〜Ｓ６３において、ＡＰＩ１２は、SearchNtfメッセージを用いて、経過情報をＡＰＩクライアント１５に供給する。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別するためのものである。経過情報は、１つ以上のパラメータ（ProgressInfo）として供給される。ステップＳ６１において、最初に供給される通知は、検索が開始されたことを示している。通知される他のイベントは、ＡＰＩ１２の基本システムによって異なる。
【００７９】
そして、ステップＳ６４において、ＡＰＩ１２は、SearchCnfメッセージをＡＰＩクライアント１５に送ることによって、検索コマンド処理の完了を報告する。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKである場合、コマンドが成功し、放送ソースが見つかっている。そうでない場合は、エラーが発生している。いずれの場合も、現在選択されている放送ソース（CurrentBroadcastSource）及び現在の受信品質（ReceptionQuality）が報告される。
【００８０】
放送ソースの選択とともに、ＡＰＩクライアント１５は、この放送ソースに属する全ての情報サービスにアクセスする。別の放送ソースの情報サービスにアクセスするには、他の放送ソースを予め選択していなければならない。
【００８１】
受信状態の監視
受信状態を監視しようとするＡＰＩクライアント１５は、受信品質ブロック１０内で実現されるSelectReceptionInfoコマンドを使用する。SelectReceptionInfoコマンドは、図９に示すように、SelectReceptionInfoReq、SelectReceptionInfoCnf、ReceptionInfoNtfメッセージによって構成される。SelectReceptionInfoコマンドは、受信状態に関する状態変化の申込サービスを提供する。すなわち、SelectReceptionInfoReq及びSelectReceptionInfoCnfメッセージを用いてこのサービスを申し込むＡＰＩクライアント１５は、ＡＰＩクライアント１５によって申込が取り消されるまで、受信状態が変化するたびに通知メッセージReceptionInfNtfを受ける。なお、現在の受信状態の報告を一回だけ要求することも可能である。
【００８２】
SelectReceptionInfoコマンドメッセージ機能のインターフェースは、以下のように定義される。
【００８３】
【表１０】
先ず、受信品質の通知を申し込むために、ステップＳ７０において、ＡＰＩクライアント１５は、SelectReceptionInfoコマンドを開始するためにSelectReceptionInfoReqメッセージをＡＰＩ１２に送る。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。監視される情報の種類は、例えば同期状態、ビットエラーレート、その他の基本システムのための適切なパラメータのセット等であり、パラメータReceptionInfoSelectionによって特定される。監視するために、与えられた全てのパラメータあるいは１つのサブセットのみを選択することも、何も選択しないことも可能である。パラメータ_bNoSubscriptionは、情報がＡＰＩクライアント１５に一回だけ供給されるか否か、又は選択されたパラメータのうちの１つにおける各状態変化が報告される申込サービスが開始されるか否かを特定する。申込サービスは、初めて監視する幾つかのパラメータを選択することによって開始される。また、申込サービスは、与えられたパラメータのうちの１つも選択しないことによって停止される。監視するパラメータのセットを変更することも可能である。
【００８５】
その後、ステップＳ７１において、ＡＰＩ１２は、SelectReceptionInfoCnfメッセージをＡＰＩクライアント１５に送ることによって要求を確認する。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKであるときは、コマンドは成功であり、そうでないときはエラーが発生している。受信状態を監視するための現在の選択は、パラメータCurrentReceptionInfoSelectionによって報告される。監視を行うために、与えられたパラメータの幾つかを選択するとき、要求された情報が１つのReceptionInfoNtfメッセージとして続く。パラメータ_bNoSubscriptionを真に設定することによって情報を一回だけ要求したときは、その後には他のReceptionInfoNtfメッセージは続かない。パラメータ_bNoSubscriptionを偽に設定することによって申込サービスを開始したとき、選択されたパラメータのうちのいずれか１つの状態変化がReceptionInfoNtfメッセージによって報告される。
【００８６】
以下、ステップＳ７２及びＳ７３において、ＡＰＩクライアント１５に受信品質の変化を知らせ続けるために、ＡＰＩ１２によってReceptionInfoNtfメッセージがＡＰＩクライアント１５に送られる。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別するためのものである。ReceptionInfoNtfメッセージは、先に監視するために選択したパラメータのうちの１つ以上のパラメータの状態変化について報告する。パラメータReceptionInfoSelectorは、どのパラメータが更新されているのかを示す。更新された値自体は、パラメータReceptionInfoによって与えられる。申込サービスの場合、選択された全てのパラメータの初期状態が、最初のReceptionInfoNtfメッセージによって送られる。それ以降の全てのReceptionInfoメッセージは、選択されたパラメータの状態変化についての情報を提供する。一回のみの要求の場合、選択された全てのパラメータの現在の状態が、最初のReceptionInfoNtfメッセージのみで送られる。
【００８７】
そして、申込を停止するために、ステップＳ７４において、ＡＰＩクライアント１５は、SelectReceptionInfoReqメッセージをＡＰＩ１２に送り、ステップＳ７５において、このSelectReceptionInfoReqメッセージは、SelectReceptionInfoCnfメッセージをＡＰＩクライアント１５に送ることによって確認される。これら両メッセージのパラメータは、上述のようにステップＳ７０及びＳ７１における場合と同様に定義される。
【００８８】
サービスディレクトリへのアクセス
サービスディレクトリブロック６によって提供されるサービスディレクトリは、現在の又は他の放送ソースに属する全ての既知のサービスについての情報を提供するためのものである。この情報がどの程度信頼性があるかは、基本システムの方針（strategy）によって異なる。利用可能なサービスについての情報は放送ソース信号で送信されるが、一時的な受信障害やオフライン作業により、サービスディレクトリブロック６によって提供されるサービスディレクトリが常に最新なものとは限らない。しかし、デジタル放送システム受信機１３が接続されると直ちに、情報が更新され、接続された各クライアント４に変更が通知される。また、放送ソース受信機が１つである基本システムでは、他の放送ソースで発生する変化を監視することはできない。この情報が次に更新されるのは、この放送ソースにアクセスしたとき、又はScanコマンドを実行したときである。サービスディレクトリブロック６によって提供されるサービスディレクトリへのアクセスは、サービスディレクトリの動的性質に合うように離散的に行われる。これは、情報が通知メッセージとしてばらばらにＡＰＩクライアント１５に供給されるSelectServiceInfoコマンドの使用による申込サービスとして設計されている。例えば、新たなサービスが利用可能である場合、そのサービスの存在及び属性がＡＰＩクライアント１５に報告される。スタートアップの直後、サービスディレクトリブロック６によって提供されるサービスディレクトリのコンテンツが、上述の通知メッセージ上にマップされ、その後の変更については同様に報告される。SelectServiceInfoコマンドは、図１０に示すように、SelectServiceInfoReqメッセージ、SelectServiceInfoCnfメッセージ、ServiceInfoNtfメッセージによって構成される。
【００８９】
SelectServiceInfoコマンドメッセージ機能のインターフェースは、以下のように定義される。
【００９０】
【表１１】
サービスディレクトリ情報を申し込むために、ステップＳ８０において、ＡＰＩクライアント１５はSelectServiceInfoコマンドを開始するためのSelectServiceInfoReqメッセージをＡＰＩ１２に送る。SelectServiceInfoコマンドは、サービスディレクトリブロック６によって提供されるサービスディレクトリにおける変化に対して、申込サービスの開始、停止、変更を行う。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。サービスディレクトリブロック６によって提供されるサービスディレクトリは、例えばオーディオストリームアプリケーションを有するサービスや、スライドショー等のデータサービスを有するサービス等であり、異なるカテゴリーの情報を提供することもできる。したがって、ＡＰＩクライアント１５は、パラメータServiceInfoSelectionを用いて、関心のある情報の種類をカスタマイズすることができる。サポートしなければならない最小セットのイベントは、dscServiceElementAdded、dscServiceElementRemoved、dscServiceElementChangedである。dscServiceElementAddedの値は、新たなサービスエレメントが利用可能であることを示す。dscServiceElementRemovedの値は、サービスエレメントが除去されているので利用不可能であることを示す。dscServiceElementChangedの値は、サービスエレメントの属性が変化したこと、例えば、あるサービスを記述するテキスト情報、又は、あるサービスによって提供される現在のコンテンツの種類を記述する情報が、コンテンツとともに変更されていることを示す。後者の場合、ServiceInfoNtfメッセージのパラメータServiceUpdateが、その変更についてより詳細に通知する。パラメータServiceInfoSelectionによってどのイベントが特定されるかに応じて、ＡＰＩ１２は、これらのイベントに関連するServiceInfoNtfメッセージを送る。最後のパラメータ_bAutoDeliveryは、サービスディレクトリブロック６によって提供されるサービスディレクトリにおける変化が、ＡＰＩクライアント１５に通知されているか（偽に設定）、あるいは、変更された情報自体も変更通知とともに供給されているか（真に設定）を特定する。
【００９２】
その後、ステップＳ８１において、ＡＰＩ１２は、SelectServiceInfoコマンドの処理を確認するために、SelectServiceInfoCnfメッセージをＡＰＩクライアント１５に送る。パラメータ_tClientIdは送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKである場合はコマンドが成功し、そうでない場合はエラーが発生している。パラメータCurrentServiceInfoSelectionは、サービスディレクトリにおける変化に対する現在の申込レベルを示す。パラメータ_bAutoDeliveryは、サービスディレクトリのあるエレメントに対する変化が報告されているか（偽に設定）、あるいは、変更された情報自体も供給されているか（真に設定）を示す。申込サービスが開始されると、サービスディレクトリブロック６によって提供されるサービスディレクトリに知られている全ての情報が、ServiceInfoNtfメッセージとして供給される。
【００９３】
利用可能なサービスをＡＰＩクライアント１５に通知し続けるため、ステップＳ８２〜Ｓ８７において、ＡＰＩ１２によってServiceInfoNtfメッセージがＡＰＩクライアント１５に送られる。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別するためのものである。申込サービスの開始直後、ＡＰＩクライアント１５による選択と一致するサービスディレクトリの完全なコンテンツがServiceInfoNtfメッセージ上にマップされ、ＡＰＩクライアント１５に供給される。その後、ServiceInfoNtfメッセージを送ることによって、サービスディレクトリに対する変更のみが報告される。パラメータ_tServiceIdは、サービスディレクトリブロック６によって提供される変更されたサービスディレクトリのサービスエレメントを識別するためのものである。パラメータServiceInfoSelectorは、この通知の理由となるイベントを特定する。サポートされるイベントセットは、ＡＰＩ１２の基本システムによって異なるが、少なくとも上述のイベントdscServiceElementAdded、dscServiceElementRemoved、dscServiceElementChangedをサポートする必要がある。パラメータServiceUpdateは、dscServiceElementAddedのイベントの場合、サービスエレメントのうちのどのオプショナル部分について知られているかを示し、dscServiceElementChangedのイベントの場合、サービスエレメントのうちのどの部分が変化したかを示す。パラメータServiceInfoObjectは、変更された情報オブジェクト自体を有する。これは、SelectServiceInfoReqメッセージにおけるパラメータ_bAutoDeliveryを特定することによって申込サービスがこのモードで設定されている場合のみ、供給される。そうでない場合、情報オブジェクトを取得するために追加コマンドを実行しなければならない。
【００９４】
このため、コマンドGetServiceInfoが設けられている。これは、GetServiceInfoReqメッセージとGetServiceInfoCnfメッセージによって構成される。
【００９５】
GetServiceInfoコマンドメッセージ機能のインターフェースは、以下のように定義される。
【００９６】
【表１２】
ＡＰＩクライアント１５は、GetServiceInfoコマンドを開始するためにGetServiceInfoReqメッセージをＡＰＩ１２に送る。GetServiceInfoコマンドは、特定されたサービスエレメントについての情報の提供を要求する。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。サービスエレメントは、パラメータ_tServiceIdによって識別される。
【００９８】
ＡＰＩ１２は、GetServiceInfoCnfメッセージをＡＰＩクライアント１５に送ることによって要求を確認する。パラメータ_tClientIdは送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKである場合、コマンドは成功であり、そうでない場合はエラーが発生している。パラメータServiceInfoObjectは、要求された、サービスエレメントを表す情報オブジェクトを有する。このオブジェクトの完全な定義は、ＡＰＩ１２を介してアクセスされる基本システムによって異なる。
【００９９】
そして、申込を停止するため、ステップＳ８８において、ＡＰＩクライアント１５は、SelectServiceInfoReqメッセージをＡＰＩ１２に送り、これが、ステップＳ８９において、ＡＰＩ１２からSelectServiceInfoCnfメッセージをＡＰＩクライアント１５に送ることによって、確認される。これら両メッセージのパラメータは、上述のように、ステップＳ８０及びＳ８１における場合と同様に定義される。
【０１００】
サービスの選択
サービスのコンテンツにアクセスするには、予めサービスを開始しておく必要がある。ＡＰＩ１２の基本システムのサービス選択ブロック８は、必要とされるリソースを割り当て、このサービスで何が放送されるのか聴取を開始する。要求されたオブジェクトのＡＰＩクライアント１５によるアクセス時間を改善するため、放送オブジェクトをメモリに記憶するキャッシュ技術を用いてもよい。
【０１０１】
ＡＰＩクライアント１５は、SelectServiceコマンドを用いてサービスの開始又は停止を行う。SelectServiceコマンドは、図１１に示すように、SelectServiceReqメッセージ、SelectServiceCnfメッセージ、ServiceInfoNtfメッセージによって構成される。各サービスは、そのサービスＩＤによって識別される。ＡＰＩクライアント１５は、サービスディレクトリブロック６によって提供されるサービスディレクトリにアクセスすることによって、サービスについて知る。サービスの開始及び停止に加えて、１コマンドで現在動作している全てのサービスを停止させるとともに新たなサービスを開始することもサポートされる。放送システムでは、サービスを終了することは常に可能である。これは、ServiceInfoNtfメッセージによってＡＰＩクライアント１５に知らされる。すなわち、サービスの終了が報告され、サービスが現在選択されている場合、関連するServiceInfoNtfメッセージの供給とともに自動的に停止する。
【０１０２】
SelectServiceコマンドメッセージ機能のインターフェースは、以下のように定義される。
【０１０３】
【表１３】
サービスを開始するのに、ステップＳ９０において、ＡＰＩクライアント１５は、SelectServiceコマンドを開始するためにSelectServiceReqメッセージをＡＰＩ１２に送る。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。サービスは、パラメータ_tServiceIdによって識別される。パラメータ_eSelectionModeは、特定されたサービスの選択モードを特定する。以下のモードがサポートされる。dscReplaceの値は、現在動作している全てのサービスを停止させ、パラメータ_tServiceIdによって特定されるサービスを開始する。dscAddの値は、パラメータ_tServiceIdによって特定されるサービスを開始し、現在開始されている全てのサービスについてはそのままにしておく。dscRemoveの値は、パラメータ_tServiceIdによって特定されるサービスのみを停止させる。dscRemoveAllの値は、開始された全てのサービスを停止させる。この最後の場合、パラメータ_tServiceIdは意味を持たない。
【０１０５】
そして、ステップＳ９１において、ＡＰＩ１２は、SelectServiceCnfメッセージを送ることによってコマンドの処理を確認する。パラメータ_tClientIdは送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKである場合、コマンドは成功であり、そうでない場合はエラーが発生している。パラメータ_tServiceIdは、パラメータ_eSelectionModeによって特定される選択モードに従って選択されたサービスを識別するためのものである。パラメータ_eSelectionModeの意味は、SelectServiceReqメッセージで使用するのと同じである。
【０１０６】
サービスのアクセス中、開始したサービスを放送から除去する場合、図１０に示すステップＳ８２〜Ｓ８７に関して説明したように、ＡＰＩ１２からＡＰＩクライアント１５にServiceInfoNtfメッセージを送ることによって、この変更がＡＰＩクライアント１５に通知される。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別するためのものである。パラメータServiceInfoSelectorは、この場合、dscServiceElementRemovedイベントを示す。サービスエレメントは、パラメータ_tServiceIdによって識別される。dscServiceElementRemovedエレメントが通知されたときは、パラメータServiceInfoObjectは意味を持たない。
【０１０７】
そして、サービスを停止するため、ステップＳ９２において、ＡＰＩクライアント１５はSelectServiceInfoReqメッセージをＡＰＩ１２に送り、これが、ステップＳ９３において、ＡＰＩ１２からＡＰＩクライアント１５にSelectServiceInfoCnfメッセージを送ることによって、確認される。これら両メッセージのパラメータは、上述のステップＳ９０及びＳ９１における場合と同様に定義される。
【０１０８】
サービスへのアクセス
放送サービスは、幾つかの方法で情報を提供することができる。以下、それら異なる方法について、アプリケーション種類の点から説明する。
【０１０９】
ローカルインタラクティブアプリケーション：
ローカルインタラクティブアプリケーションは、情報をばらばらに供給する。例えば、ハイパーテキストアプリケーションのユーザは、現在提供されている情報を読み、更なる情報に対するハイパーリンクを追跡することによって、与えられた情報をナビゲートする。各ハイパーテキストページには、テキスト情報、異なるフォーマットのイメージ等の埋込オブジェクト、他のハイパーテキストページや他のフォーマットのオブジェクトへのリンクが含まれている。放送システムでは、これらの情報オブジェクトが周期的に送信される。現在どの情報オブジェクトが必要かは、ユーザインタラクションによって異なる。
【０１１０】
オブジェクトの明示的要求を必要とする全てのアプリケーションについて、ＡＰＩ１２は、サービスアクセスブロック９を用いて、特定された情報オブジェクトの供給を要求するSelectObjectコマンドを与える。これは、SelectServiceコマンドを使用することによって関連するサービスを開始した後に、使用することができる。SelectObjectコマンドは、図１３に示すように、SelectObjectReqメッセージ、SelectObjectCnfメッセージ、ObjectNtfメッセージによって構成され、申込サービスを提供する。一回のみの供給を要求することも可能であり、また、更新供給のためにオブジェクトを選択することも可能である。すなわち、オブジェクトは、それがはじめて利用可能となった後に供給され、そのオブジェクトの更新は全て、選択が取り消されるまで追加的に報告される。オブジェクトの選択及び解放に加えて、１コマンドで現在の全ての選択を除去するとともに別の選択を行うことも可能である。別のパラメータによって、完全に受信されたオブジェクトのみが供給されるか、あるいは、部分的に供給されてもよいのかを特定することができる。後者の場合、開始から完全なオブジェクトの既に受信されたデータが全て供給される。最初の供給の後、何回か供給が行われる。供給毎に、供給されるオブジェクトが少しずつ完全になる。別のパラメータは、この情報オブジェクトがアプリケーションにとってどの程度重要かを示す、アプリケーションによるヒントである。
【０１１１】
スライドショーアプリケーション：
スライドショーアプリケーションは、アプリケーション自体によって予め定義された方法で情報を提供する。例えば、ピクチャスライドショーは、提示時刻が予め決定している一連の画像を提供する。ピクチャスライドショーを実現する簡単な方法は、画像を提示すべき時に放送することである。この場合、追加信号送信は必要ない。より複雑な方法としては、送信エラーに備えるため、提示時刻以前に画像を数回放送する。これによって、提示時刻になる前に提示オブジェクトを適切に受信する可能性が高くなる。
【０１１２】
提示時刻が予め決定している全てのアプリケーションについて、ＡＰＩ１２は、適切な提示時刻においてオブジェクトの復号化、記憶、提示の呼出を行う。上述のアプリケーションを有するサービスが開始した後、提示時刻になると、図１２に示すように、提示される各オブジェクトがObjectNtfメッセージとしてＡＰＩ１２によってＡＰＩクライアント１５に供給される。さらに、現在提示されているオブジェクトが提示用として有効でなくなったことを示すため、ObjectNtfメッセージが使用される。
【０１１３】
ストリーミングアプリケーション：
ストリーミングアプリケーションは、例えばオーディオ又はビデオストリーム等のアプリケーションプログラムによって準備されているデコーダに永続的に供給される連続データストリームである。このアプリケーションを有するサービスが開始された後、時間通りにデータを供給することが重要である。これは、遅れたデータは役に立たないからである。ＡＰＩ１２は、図１２に示すように、ストリーミングアプリケーションに対してスライドショーアプリケーションと同様のアプリケーション処理サポートを提供する。ストリーミングアプリケーションを有するサービスが開始されると、連続データストリームからのデータを包含するバッファを有するObjectNtfメッセージが送られる。このデータは、アプリケーションプログラムのデコーダに供給されなければならない。供給におけるジッタを補償するため、アプリケーションは、ObjectNtfメッセージを記憶するのにファーストインファーストアウトキューを用いてもよい。このキューが所定のメッセージ数まで満たされてはじめて、アプリケーションデコーダが開始する。アプリケーションデコーダは、１メッセージのデータを処理した後、次のメッセージが入る。ＡＰＩ１２によって供給されるその後のメッセージはいずれも、ファーストインファーストアウトキューに追加される。
【０１１４】
アプリケーションのビルトイン処理
実際の放送システムでは、あるアプリケーション種類用のビルトイン処理／プロセッサが得られることがある。例えば、ビルトインオーディオデコーダは、連続するオーディオストリームアプリケーションを処理する。このアプリケーションのビルトイン処理は、サービスの処理の開始又は停止を行うSelectServiceコマンドを用いて制御される。この場合、SelectObjectコマンドによるサポートは不要である。サービスアクセスブロック９に含まれるSelectObjectコマンドメッセージ機能のインターフェースは、以下のように定義される。
【０１１５】
【表１４】
【表１５】
図１３では、図１１で説明したように行われるステップＳ１１０及びＳ１１１の、ＡＰＩクライアント１５からＡＰＩ１２へのSelectServiceReqメッセージを有するサービスの開始、及び、SelectServiceCnfメッセージを送ることによるＡＰＩ１２のコマンドの確認の後、SelectObjectコマンドを開始することができる。
【０１１８】
その後、ステップＳ１１２において、SelectObjectコマンドを開始するため、ＡＰＩクライアント１５はSelectObjectReqメッセージをＡＰＩ１２に送る。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。選択されるオブジェクトは、パラメータ_tObjectIdによって識別される。オブジェクトが属しているサービスは、パラメータ_tServiceIdによって識別される。パラメータ_eObjectSelectionModeは、特定されたオブジェクトの選択モードを特定する。以下のモードがサポートされる。dscOnceの値は、特定されたオブジェクトの一回のみの供給を要求する。dscUpdateの値は、選択が取り消されるまで、特定のオブジェクトの供給及びオブジェクトの各更新の供給を要求する。dscOffの値は、現存のオブジェクト選択を取り消す。dscCacheHintの値は、このオブジェクトがＡＰＩクライアント１５にとってどの程度重要であるかを示すヒントをＡＰＩ１２に供給するためのみに、SelectObjectコマンドが使用されることを示す。この場合、オブジェクトは供給用に選択されない。重要性は、パラメータCacheHintによって特定される。ハイパーテキストアプリケーション等の幾つかのアプリケーションでは、１コマンドで新たなオブジェクトを選択するとともに同じサービスに属する現存の全ての選択を取り消すことが好都合である。これは、パラメータ_bReplaceSelectionsを使用することによってサポートされる。このパラメータが真に設定された場合、パラメータ_tServiceIdによって特定されるサービスに属する現存の全ての選択が取り消される。このパラメータが偽に設定された場合、現存の全ての選択が変更されるわけではない。dscCompleteに対して設定されたパラメータ_eDeliveryModeは、選択されたオブジェクトがオブジェクトの完全な受信後に供給されることを示す。dscPartialに対して設定されたパラメータ_eDeliveryModeは、選択されたオブジェクトを部分的に供給してもよいことを示す。すなわち、インデックス１〜ｎの範囲のバイトシーケンスからなるオブジェクトについて、最初の供給では、インデックス１〜ｍ（ｍはｎ以下）の範囲のバイトシーケンスからなる部分的に受信されたオブジェクトが得られる。次の供給では、１〜ｌ（ｌはｍより大でｎ以下）のシーケンスが得られ、同様に続く。これは、１〜ｎの範囲の全てのデータが供給されてオブジェクトが供給されると、終了する。
【０１１９】
パラメータCacheHintは、ＡＰＩ１２への、キャッシュを行うためのＡＰＩクライアント１５によるヒントを特定する。キャッシュでは、放送オブジェクトのコピーを記憶するため高速ローカルメモリを使用する。これによって、要求されたオブジェクトが既にキャッシュメモリに記憶されている場合、オブジェクトのアクセス時間が改善する。パラメータCacheHintは、キャッシュを行うオブジェクトを選択するためのヒントを与える。このパラメータの正確な定義は、基本システムによって異なる。一例としては、ＡＰＩクライアント１５にとっての重要性が最も低い０から重要性が最も高い１００までの範囲で優先パラメータを使用することである。キャッシュのためのヒントは、各オブジェクトモードdscOff、sdcOnce、dscUpdate、dscCacheについて有効である。
【０１２０】
そして、ステップＳ１１３において、ＡＰＩ１２は、SelectObjectCnfメッセージをＡＰＩクライアント１５に送ることによってコマンドの処理を確認する。パラメータ_tClientIdは送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKである場合、コマンドは成功であり、そうでない場合はエラーが発生している。パラメータ_tServiceIdは、選択されたオブジェクトが属しているサービスを識別するためのものである。パラメータ_tObjectIdは、選択されたオブジェクトを識別するためのものである。特定されたオブジェクトの現在の選択モードは、パラメータ_eObjectSelectionModeによって与えられる。パラメータAccessTimeは、選択されたオブジェクト自体がObjectNtfメッセージの使用によって与えられるまでの予想される遅延を示す、オブジェクトのアクセス時間を与える。
【０１２１】
オブジェクト及び更新を供給するため、ステップＳ１１４及びＳ１１５に示すように、ObjectNtfメッセージを送ることによって、ローカルインタラクティブアプリケーション等の選択されたオブジェクト、又は、スライドショーアプリケーション等の提示されるオブジェクト、又は、ストリーミングアプリケーション等の連続データストリームの１セグメントを有するオブジェクトがＡＰＩ１２からＡＰＩクライアント１５に供給される。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別するためのものである。パラメータ_tServiceIdは、オブジェクトが属しているサービスを識別するためのものである。パラメータ_tObjectIdは、オブジェクトを識別するためのものである。パラメータ_eSelectionStateは、オブジェクトの現在の選択状態を報告するものであり、ローカルインタラクティブアプリケーションのみで使用される。以下の状態がサポートされる。dscSelectionOKの値は、オブジェクトがこのメッセージとともに供給されることを示し、パラメータ_ptObjectによってアクセスすることができる。dscDelayedの値は、関連するSelectObjectCnfメッセージによって示された場合と比較して、オブジェクトの供給が遅延していることを示す。この場合、パラメータ_ptObjectは意味を持たない。
【０１２２】
dscTerminatedの値は、オブジェクトが放送されなくなり、供給することができないことを示す。この場合、パラメータ_ptObjectは意味を持たず、この選択は排除される。パラメータ_bCompleteObjectは、オブジェクトがこのメッセージとともに完全に供給されるか部分的に供給されるかを示す。このパラメータが真に設定された場合、完全なオブジェクトが供給される。このパラメータが偽に設定された場合、上述のようにオブジェクトは部分的に供給される。パラメータ_bObjectInvalidは、提示のためにアプリケーションに以前供給されたスライドショーオブジェクトの提示を停止しなければならないか否かを示す。このパラメータが真に設定された場合、オブジェクトの提示を停止しなければならない。例えば、画像をディスプレイから除去しなければならない。この場合、パラメータ_eSelectionState，_bCompleteObject，_ptObjectは意味を持たない。パラメータが偽に設定された場合、他のパラメータの意味によってメッセージの意味が決まる。
【０１２３】
オブジェクトの選択を停止するために、ステップ１１６において、ＡＰＩクライアント１５はSelectObjectReqメッセージをＡＰＩ１２に送り、これが、ステップＳ１１７において、SelectObjectCnfをＡＰＩクライアント１５に送ることによってＡＰＩ１２から確認される。これら両メッセージのパラメータは、上述のステップＳ１１２及びＳ１１３における場合と同様に定義される。
【０１２４】
そして、サービスを停止するために、ステップＳ１１８において、ＡＰＩクライアント１５は、SelectServiceReqメッセージをＡＰＩ１２に送り、ステップＳ１１９において、ＡＰＩクライアント１５にSelectServiceCnfメッセージを送ることによってＡＰＩ１２から確認される。これら両メッセージのパラメータは、上述のステップＳ１１０及びＳ１１１における場合と同様に定義される。
【０１２５】
図１２では、SelectObjectコマンドを使用せずに図１１において説明したように行われるステップＳ１００及びＳ１０１の、ＡＰＩクライアント１５からＡＰＩ１２へのSelectServiceReqメッセージを有するサービスの開始、及び、ＡＰＩクライアント１５にSelectServiceCnfメッセージを送ることによるＡＰＩ１２のコマンドの確認の直後、スライドショーオブジェクトを供給することもできる。この場合、ステップＳ１１４及びＳ１１５について説明したように定義されるステップＳ１０２〜Ｓ１０４に示すように、ObjectNtfメッセージを送ることによってＡＰＩ１２からＡＰＩクライアント１５に情報が供給される。その後、サービスを停止させるため、ステップＳ１０５において、ＡＰＩクライアント１５がSelectServiceReqメッセージをＡＰＩ１２に送り、これが、ステップＳ１０６において、ＡＰＩクライアント１５にSelectServiceCnfメッセージを送ることによってＡＰＩ１２から確認される。これら両メッセージのパラメータは、上述のステップＳ１００及びＳ１０１における場合と同様に定義される。
【０１２６】
利用可能な全放送ソースにおけるサービスのスキャン
放送環境における利用可能な全てのサービスの概要を得るために、Scanコマンドが設けられている。要求インターフェース１６を介したサービススキャンブロック１１へのScanコマンドの要求後、利用可能な全ての放送ソースの検索を開始し、各放送ソースでどのサービスが利用可能なのかを知るために放送ソースを１つずつ選択する。その結果は、サービスディレクトリブロック６によって供給されるサービスディレクトリに記憶され、ＡＰＩクライアント１５がアクセスすることができる。コマンドの処理中は、他のサービスにはアクセスできないことがある。これは、接続された放送受信機１３によって異なる。放送受信機が一時に１つの放送ソースへのアクセスしか行わない場合、他のアクセスは不可能である。
【０１２７】
検索方法は、例えば周波数範囲、周波数ステップ、方向等であり、ＡＰＩクライアント１５によって特定することができ、あるいはＡＰＩ１２によって自動的に行われる。このため、スキャンが継続している限り経過情報が与えられる。Scanコマンドは、図１４に示すように、ScanReqメッセージ、ScanNtfメッセージ、ScanCnfメッセージ機能によって構成される。Scanコマンドが実行され、ＡＰＩクライアント１５がサービスディレクトリからの通知を申し込んだ場合、サービスディレクトリにおける変更を通知するため、ServiceInfoNtfメッセージがＡＰＩ１２からＡＰＩクライアント１５に送られる。
【０１２８】
Scanコマンドメッセージ機能のインターフェースは、以下のように定義される。
【０１２９】
【表１６】
まず、ステップＳ１２１において、ＡＰＩクライアント１５はScanコマンドを開始するためにScanReqメッセージをＡＰＩ１２に送る。パラメータ_tClientIdは、ＡＰＩクライアント１５を識別するためのものである。検索方法は、１以上のパラメータ（SearchMethod）によって特定される。スキャンに長時間かかることがあるので、ＡＰＩクライアント１５はスキャン動作中に経過情報を要求してもよい。このため、パラメータNotificationsによって、例えば、各周波数ステップ後に所望の通知種類を特定することができる。
【０１３１】
その後、ステップＳ１２２〜Ｓ１２４に示すように、ＡＰＩ１２はＡＰＩクライアント１５に経過情報を供給するためにScanNtfメッセージを使用する。パラメータ_tClientIdは、送信先のＡＰＩクライアント１５を識別するためのものである。経過情報は、１以上のパラメータ（ProgressInfo）として供給される。
【０１３２】
そして、ステップＳ１２５において、ＡＰＩ１２は、ＡＰＩクライアント１５にScanCnfメッセージを送ることによって、Scanコマンドの処理の完了を報告する。パラメータ_tClientIdは送信先のＡＰＩクライアント１５を識別し、パラメータ_eResultは処理結果を示す。値がresOKである場合、コマンドは成功であり、放送ソースが見つかっている。そうでない場合はエラーが発生している。いずれの場合も、現在選択されている放送ソース（CurrentBroadcastSource）及び現在の受信品質（ReceptionQuality）が報告される。
【０１３３】
放送ソースの選択によって、ＡＰＩクライアント１５は、この放送ソースに属する全ての情報サービスにアクセスを有する。他の放送ソースの情報サービスにアクセスするには、他の放送ソースを予め選択しておく必要があるが、サービスディレクトリブロック６が供給するサービスディレクトリによって、全放送ソースからの全サービスについての情報を得ることができる。これによって、ユーザに全サービスのリストを供給するアプリケーションプログラムを形成することができる。ユーザが、現在選択されているソースからあるサービスを選択する場合、SelectServiceコマンドのみ実行する必要がある。ユーザが、他の放送ソースからサービスを選択する場合、２つの選択肢が与えられる。ＡＰＩクライアント１５は、まずTuneコマンドを使用することによって放送ソースを選択し、次にSelectServiceコマンドを使用することによってサービスを選択する。あるいは、SelectServiceコマンドが他の放送ソースからのサービスについて実行される場合、ＡＰＩクライアント１５は、予めTuneコマンドを自動的に実行する。
【０１３４】
本発明を、Ｃ／Ｃ＋＋言語で実現される一実施例を用いて説明したが、これは限定ではなく、本発明を適用したＡＰＩ１２の機能を明確に説明するために用いたものであることは明らかである。他のプログラミング言語での実現やハードウェアによる実現も可能であり、同様の機能を示す。ＡＰＩ１２及び／又はＡＰＩクライアント１５については、１つの放送受信機内で又は別々の装置として実現することができる。これらをソフトウェアとして実現する場合、放送受信機内に又はそれぞれの装置内に配置することができる。あるいは、放送システムのチャンネルから、又は、放送受信機又はそれぞれの装置によってアクセスすることができる他のサーバからダウンロードすることができる。
【０１３５】
以下、本発明を適用した放送ＡＰＩの典型的な使用について、幾つかの現存の放送システムを用いて説明する。
【０１３６】
ＲＤＳ（ラジオデータシステム）を持たない標準ＦＭラジオは、ユーザインターフェースが１つである。すなわち、ＦＭラジオへのアクセスをユーザに与えるため、クライアントのみが放送ＡＰＩを同時に用いている。ＦＭラジオでは、通常、幾つかの放送ソースにアクセスする（周波数範囲８８〜１０８ＭＨｚ）。各放送ソースは、オーディオサービスを１つだけ提供する。オーディオサービスの処理はビルトインで行われる。すなわち、ＡＰＩによるサービスアクセスサポートは不要である。放送ソースを選択すると、自動的に１つのオーディオサービスのみが開始するとともに（サービス選択）、自動的にオーディオデータの処理が開始する（サービスアクセス）。移動環境では、受信品質は大きく変化する。しかし、非常に安価なものから高価なものまで広範囲のラジオが存在する。受信品質の監視は得られるときもあり、得られないときもある。
【０１３７】
オーディオサービスは、ＩＤ、ラベル、プログラム種類等の属性を有しない。したがって、ＦＭ信号からサービスディレクトリを作成することは不可能である。
【０１３８】
ＲＤＳを有するＦＭラジオは、上述のシステムと同じであるが、オーディオサービスについての更なる情報を与えるためにＦＭ信号とともに送られる追加データを有する。追加情報は、ＩＤ（Oxd999）、ラベル（"SWF3"）、プログラム種類（"POP"）、アナウンスメントサポート及びスイッチング（スポークントラフィックメッセージ）、ラジオテキスト（”追加テキスト情報”）からなる。これによって、幾つかの放送ソースを属性とともに有するサービスディレクトリを形成することができる。これは、あるプログラム種類（"Pop"）に合うサービスを選択するため、あるいは、ラベル（"SWF3"、"Antenne1"）に基づく１以上のリストからサービスを選択するのに使用することができる。一時に１つのオーディオサービスしか動作しないが、ラジオテキストスライドショーを付加的に行うことができる。
【０１３９】
通常のテレビジョン受像機は、クライアントが１つである。幾つかの利用可能な放送ソースから１つの放送ソース（チャンネル）を選択することができる。放送ソース毎に１ビデオストリームサービスが得られる。ラベル、タイム、ProgramInfo等の追加情報は、ビデオテキストによって示される。ビデオテキストは、テキスト情報を有するローカルインタラクティブサービスを提供する。ビデオ処理はビルトインで行われ、ビデオテキストデコーダもサポートされるならば得られる。しかし、ページへのアクセスにはサービスアクセスブロック９が必要である。サービスアクセスブロック９によって、ビデオテキストページをナビゲートすることができ、スライドショー効果はメインページ及びサブページに使用されることが多い。
【０１４０】
固定型の動作及び／又はケーブルネットワークであるため、受信状態が障害を受けることは稀である。
【０１４１】
チャンネルを選択するのに放送ソース選択が必要である。これによって、自動的にビデオサービスが開始する。ビデオテキストアクセスは、クライアントによる要求で開始する（サービス選択）。ビデオテキスト復号化は、より高速なアクセスを行うために予め開始されている。
【０１４２】
サービススキャンでは、全てのサービス（ビデオストリーム及びビデオテキスト）の検索を行い、それらを所定のボタンで自動的に記憶する。これらのサービスをサービスディレクトリに記憶し、現在使用されているチャンネル番号の代わりにチャンネル名リストを与えることも可能である。
【０１４３】
例えば、いかなる種類の金融情報にもアクセスする受信機等、特殊な受信機は、ＤＡＢ等の標準放送システムに基づくこともできるが、特定情報へのアクセスしか得られない。
【０１４４】
放送システムの構成として幾つかの構成が可能である。例えば、サーバＰＣに接続された１ハードウェア受信機と、ＰＣワークステーション上で動作する幾つかのクライアントアプリケーションとを有し、ローカルネットワークを介して情報にアクセスする構成がある。以下に示す構成が可能である。
【０１４５】
・１又は幾つかのクライアント。
【０１４６】
・１又は幾つかの放送ソース。
【０１４７】
・金融情報、ニューステキスト、ニュースティッカ、ハイパーテキスト、ニューススライドショー、株データ等を有する幾つかのサービス。
【０１４８】
・１放送ソースでは放送ソース選択は不要だが、２以上では必要。
【０１４９】
・２以上のサービスで異なる種類（ハイパーテキスト、ニュースティッカ）の場合、サービス選択が必要。
【０１５０】
・サービスマルチプレクスは変更してもよい。
【０１５１】
・サービスディレクトリによって柔軟なサービスマルチプレクスが可能である。
【０１５２】
・１放送ソースではサービススキャンは行わない。
【０１５３】
・例えば、株価を提供する場合、受信品質の監視は重要である。
【０１５４】
フルＤＡＢ及び／又はＤＶＢシステムには、本発明の好ましい実施例で説明したビルディングブロックの全機能が含まれている。
【０１５５】
一般に、放送ＡＰＩのビルディングブロックには必須のものと任意のものとがあるが、これは、この分野のサポートがクライアント（アプリケーション）にとって必要／有用であるか否かに常に関連している。例えば、１放送ソースにしかアクセスしないシステムの場合、放送ソース選択は不要である。これは、放送ソースを全く選択しなくてよいということではない。１放送ソースしか選択できず、ＡＰＩの基本システムによって自動的に選択が行われる、ということである。
【０１５６】
フルシステムにおいては、全てのビルディングブロックが必要であることは明らかである。実際のシステムの制限によって、サブセットのみが必要である。幾つかの簡単なシステムでは、除去することができるブロックもあり、合体することができるブロックもあるが、これは機能についてのみ有効である。ビルディングブロックのインターフェースを変更することが必要なときもある。その結果、新たなビルディングブロックが定義される。
【０１５７】
一般に、機能とそれに対応するビルディングブロックが必須であるか任意であるかの決定は容易になる。
【０１５８】
・２以上の放送ソースが利用可能であるときは必ず放送ソース選択が必要であり、選択されたいずれの放送ソースからも全サービスがわかるわけではない。他の全ての放送ソースにおける全サービスについての情報がわかる場合、システムは、スタートアップ後に１放送システムを選択し、利用可能な全てのサービスについて情報を得る。この場合、サービス選択を行うことで、サービスにアクセスするのに十分である。
【０１５９】
・提供されたサービスが予めわかっていないとき、また、提供されたサービスのセットを変更することができるとき、サービスディレクトリが必要である。幾つかの放送ソースがあり、選択された放送ソースにおけるサービスが限定的にしか示されていない場合、サービスディレクトリによって、再チューニングを行わずに利用可能な全サービスのリストを得ることができる。クライアントは、動的変更についての情報を得ることができる。
【０１６０】
・１放送ソースにおいて２以上のサービスが利用可能であるとき、また、２以上のサービスを同時に動作させるため、サービス選択が必要である。
【０１６１】
・更なる処理を行うためにデータをアプリケーションに供給する必要があるとき、サービスアクセスが必要である。
【０１６２】
・受信品質が動作中に変化する可能性があるとき、受信品質が必要である。
【０１６３】
・サービススキャンによって、サービス選択が容易になり、良好なユーザインターフェースを形成することができる。
【０１６４】
・２以上のクライアントがＡＰＩを用いているとき及び／又はインターフェーシングが必要なとき、クライアント登録が必要である。
【０１６５】
本発明を適用した放送ＡＰＩの他の適用例として、ＡＰＩクライアント１５に限定的なアクセスのみを提供する。すなわち、例えば、ＪａｖａＡｐｐｌｅｔは完全なＤＡＢ受信機の一部賭して動作している。ＤＡＢへのアクセスは、ＤＡＢ受信機の適応部分によって制御されるが、ＪａｖａＡｐｐｌｅｔは、例えば、ＤＡＢを介してダウンロードされ、あるデータサービスを提示する。したがって、サービスアクセスブロック９にアクセスする必要があり、他のブロックへのアクセスはできない。
【０１６６】
【発明の効果】
放送システムによって提供される情報サービスにクライアントがアクセスすることを可能にするアプリケーションプログラミングのインターフェース装置において、アプリケーションプログラミングのインターフェース装置内のビルディングブロックの情報サービスの処理を行う各機能を全て定義する要求サブインターフェースを有し、ビルディングブロックは、要求サブインターフェースを介してアドレス及び／又は要求される。これによって、クライアントは、放送システムの詳細を知らないでも、インターフェース装置を介して所望の情報サービスにアクセスすることができる。
【図面の簡単な説明】
【図１】本発明を適用したＡＰＩを有するデジタル放送システムの受信機のモデルを示すブロック図である。
【図２】本発明を適用したコマンドパターンの流れを示す図である。
【図３】本発明を適用したコマンドパターンの流れを示す図である。
【図４】本発明を適用したコマンドパターンの流れを示す図である。
【図５】本発明を適用したＡＰＩ及びＡＰＩクライアントを示すブロック図である。
【図６】本発明を適用したクライアント登録の流れを示す図である。
【図７】本発明を適用したチューンコマンドメッセージ通信の流れを示す図である。
【図８】本発明を適用した検索コマンドメッセージ通信の流れを示す図である。
【図９】本発明を適用したるselectreceptioninfoコマンドメッセージ通信の流れを示す図である。
【図１０】本発明を適用したselectserviceinfoコマンドメッセージ通信の流れを示す図である。
【図１１】本発明を適用したselectserviceコマンドメッセージ通信の流れを示す図である。
【図１２】本発明を適用したスライドショー処理の流れを示す図である。
【図１３】本発明を適用したハイパーテキストサービスの流れを示す図である。
【図１４】本発明を適用したスキャンコマンドメッセージ通信の流れを示す図である。
【図１５】ＤＡＢ規格による放送ソース信号のモデルを示す図である。
【図１６】従来の放送データのオブジェクト流れを示す図である。
【符号の説明】
４ アプリケーションプログラム、５ クライアント登録ブロック、６ サービスディレクトリブロック、７ 放送ソース選択ブロック、８ サービス選択ブロック、９ サービスアクセスブロック、１０ 受信品質ブロック、１１ サービススキャンブロック、１２ ＡＰＩ、１３ デジタル放送システム受信機
Claims (34)
- 放送受信機システムであって、
放送システムによって提供される情報サービスを受信するように構成された放送システム受信機と、
クライアント（４、１５）が前記情報サービスにアクセスすることを可能にするアプリケーションプログラミングインターフェース（１２）とを含み、
前記アプリケーションプログラミングのインターフェースは要求サブインターフェースを有し、前記クライアントは、前記要求サブインターフェースを介して、アドレスする及び／又は要求するアプリケーションプログラミングインターフェース内のビルディングブロックにアクセスし、
前記アプリケーションプログラミングのインターフェースは、前記クライアントが前記情報サービスを要求することを可能にするコマンドの実行を要求するために、前記クライアントから前記アプリケーションプログラミングのインターフェースへ送信される要求メッセージを受信するように構成され、更に、前記コマンドの実行を確認するために確認メッセージを前記クライアントへ送信するように構成されることを特徴とする放送受信機システム。 - 前記アプリケーションプログラミングのインターフェースは、上記クライアントの登録サービスを行うクライアント登録ビルディングブロックを有することを特徴とする請求項１記載の放送受信機システム。
- 上記クライアント登録ビルディングブロックは、上記クライアントとの通信において上記クライアントを識別するために、使用する個々のクライアント識別子を、上記クライアントに与えることを特徴とする請求項２記載の放送受信機システム。
- 前記アプリケーションプログラミングのインターフェースは、１つ以上の放送ソースの利用可能なサービスについてのサービス情報を提供するサービスディレクトリビルディングブロックを有することを特徴とする請求項１乃至３のいずれか１項記載の放送受信機システム。
- 上記サービスディレクトリビルディングブロックは、各放送ソースにアクセスしたとき及び／又は前記アプリケーションプログラミングインターフェースが幾つかの受信可能な放送ソースから送信されるサービス情報を収集するためにスキャンコマンドを実行したときにそれぞれ更新される、現在の放送ソース及び／又は少なくとも１つの他の放送ソースから送信されるサービスについてのサービスに関するサービス情報を提供することを特徴とする請求項４記載の放送受信機システム。
- 上記サービスディレクトリビルディングブロックは、接続された上記クライアントに前記サービス情報の変更を通知することを特徴とする請求項４又は５記載の放送受信機システム。
- 前記アプリケーションプログラミングのインターフェースは、上記クライアントが１つの放送ソースを選局するする又は少なくとも１つの放送ソースを自動的に検索することを可能にする放送ソース選択ビルディングブロックを有することを特徴とする請求項１乃至６のいずれか１項記載の放送受信機システム。
- 前記アプリケーションプログラミングのインターフェースは、２つ以上のサービスを同時に開始又は停止可能にするサービス選択ビルディングブロックを有することを特徴とする請求項１乃至７のいずれか１項記載の放送受信機システム。
- 上記サービス選択ビルディングブロックは、現在動作中の全てのサービスを同時に停止するとともに新たなサービスを開始することを可能にすることを特徴とする請求項８記載の放送受信機システム。
- 上記サービス選択ビルディングブロックは、上記クライアントによって選択されたサービスの終了に関する情報を上記クライアントに送ることを特徴とする請求項８又は９記載の放送受信機システム。
- 前記アプリケーションプログラミングのインターフェースは、サービスの少なくとも１つのコンテンツへのアクセスを同時に開始及び／又は停止することを可能にするサービスアクセスビルディングブロックを有することを特徴とする請求項１乃至１０のいずれか１項記載の放送受信機システム。
- 上記サービスアクセスビルディングブロックは、現在アクセスしているサービスのコンテンツへのアクセスを同時に停止するとともにサービスの新たなコンテンツへのアクセスを可能にすることを特徴とする請求項１１記載の放送受信機システム。
- 上記サービスアクセスビルディングブロックは、前記放送システムにおいて周期的に又は繰り返し送信される情報オブジェクトのうちの選択された情報をローカルインタラクティブアプリケーションへ提供することを特徴とする請求項１１又は１２記載の放送受信機システム。
- 上記サービスアクセスビルディングブロックは、ストリーミング又はスライドショーアプリケーションをサポートするために、受信された前記情報サービスに含まれた受信情報を前記クライアントに提示するか、それとも、前記受信情報を格納しかつ前記クライアントに所定時刻に提示することを特徴とする請求項１１乃至１３のいずれか１項記載の放送受信機システム。
- 上記サービスアクセスビルディングブロックは、所定のアプリケーションのために前記放送システム受信機内に含まれたビルトインプロセッシングにアクセスすることを特徴とする請求項１１乃至１４のいずれか１項記載の放送受信機システム。
- 前記アプリケーションプログラミングのインターフェースは、前記放送システム受信機の受信品質を監視することを可能にする受信品質ビルディングブロックを有することを特徴とする請求項１乃至１５のいずれか１項記載の放送受信機システム。
- 上記受信品質ビルディングブロックは、上記クライアントが受信品質通知を申し込むことを可能にし、上記申し込んだクライアントが申込を取り消すまで、申し込んだクライアントに受信状態の変更がある毎に通知を行うことを特徴とする請求項１６記載の放送受信機システム。
- 前記アプリケーションプログラミングのインターフェースは、所定の検索領域の受信可能な全ての放送ソースにおける受信可能な全てのサービスを上記クライアントが検索することを可能にするサービススキャンビルディングブロックを有することを特徴とする請求項１乃至１７のいずれか１項記載の放送受信機システム。
- 前記アプリケーションプログラミングのインターフェースは、クライアントが特定の検索領域の使用可能な放送ソース内の全ての可能なサービスを検索することを可能にするサービススキャニングビルディングブロック（１１）を有し、
上記サービススキャニングビルディングブロックは、サービスディレクトリビルディングブロックに含まれているサービスディレクトリを更新することを特徴とする請求項４乃至６のいずれか１つに記載の放送受信機システム。 - 上記特定の検索領域は、１又は複数の周波数範囲であることを特徴とする請求項１８又は１９記載の放送受信機システム。
- 上記サービススキャンビルディングブロックは、検索が続く限り、進行情報を提供することを特徴とする請求項１８又は１９記載の放送受信機システム。
- 上記各ビルディングブロックは、前記アプリケーションプログラミングインターフェースとクライアントの間に、非同期メッセージングを提供することを特徴とする請求項１乃至２１のいずれか１項記載の放送受信機システム。
- 前記アプリケーションプログラミングのインターフェースは、更に
コマンドの進行に関する情報を通知するため、又は上記クライアントに要求された情報を提供するために、通知メッセージを前記クライアントに送信することを特徴とする請求項１乃至２２のいずれか１項に記載の放送受信機システム。 - 上記要求サブインターフェースは、機能的要求メッセージの使用を可能にすることを特徴とする請求項１乃至２３のいずれか１項記載の放送受信機システム。
- 前記アプリケーションプログラミングのインターフェースは、
幾つかのクライアントを同時にサポートすることを特徴とする請求項１乃至２４のいずれか１項記載の放送受信機システム。 - 前記アプリケーションプログラミングのインターフェースは、１つ又は幾つかのクライアントに、前記サービスアクセスビルディングブロック（９）への排他的なアクセスを提供することを特徴とする請求項１１乃至１５のいずれか１項記載の放送受信機システム。
- 前記アプリケーションプログラミングのインターフェースは、前記受信した情報サービスをキャッシュする（Ｃａｃｈｅ）ことを特徴とする請求項１乃至２６のいずれか１項記載の放送受信機システム。
- 上記キャッシュは、上記クライアントによって提供される優先値に基づいて行われることを特徴とする請求項２７記載の放送受信機システム。
- 前記放送システム受信機は、ＤＡＢ、ＤＶＢ、アナログラジオ又はアナログテレビジョン受信機である請求項１乃至２８のいずれか１項記載の放送受信機システム。
- 上記クライアントは、上記アプリケーションプログラミングのインターフェースによって定義された確認及び通知サブインターフェースを有し、
上記確認及び通知サブインターフェースは、上記アプリケーションプログラミングインターフェースが当該クライアントに確認及び／又は通知メッセージを送ることを可能にすることを特徴とする請求項１乃至２９のいずれか１項に記載の放送受信機システム。 - ソフトウェアプログラムとして実現されていることを特徴とする請求項３０記載の放送受信機システム。
- 上記ソフトウェアプログラムは、Ｃ、Ｃ＋＋又はＪａｖａで実現されていることを特徴とする請求項３１記載の放送受信機システム。
- 前記クライアントは前記放送システム受信機内に設けられる請求項３０乃至３２のいずれか１項記載の放送受信機システム。
- 前記放送受信機システムは、ＤＡＢ、ＤＶＢ、アナログラジオ又はアナログテレビジョン受信機である請求項３３に記載の放送受信機システム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP99108701.6 | 1999-04-30 | ||
| EP99108701A EP1049278A1 (en) | 1999-04-30 | 1999-04-30 | Broadcast API - an application programming interface for accessing information services provided by a broadcast system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001028571A JP2001028571A (ja) | 2001-01-30 |
| JP4590062B2 true JP4590062B2 (ja) | 2010-12-01 |
Family
ID=8238094
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000137169A Expired - Fee Related JP4590062B2 (ja) | 1999-04-30 | 2000-05-01 | 放送受信機システム及び放送受信機システムの動作方法 |
Country Status (2)
| Country | Link |
|---|---|
| EP (1) | EP1049278A1 (ja) |
| JP (1) | JP4590062B2 (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI20002402A (fi) * | 2000-11-01 | 2002-05-02 | Nokia Corp | Konfiguroinnin hallinta hajautetussa ympäristössä |
| CN100375013C (zh) * | 2002-04-08 | 2008-03-12 | 国际商业机器公司 | 用于在分布式企业应用中进行问题确定的方法和系统 |
| US20050097624A1 (en) | 2003-10-31 | 2005-05-05 | Nokia Corporation | System and associated terminal, method and computer program product for providing broadcast content |
| US7441058B1 (en) | 2006-09-11 | 2008-10-21 | Apple Inc. | Method and system for controlling an accessory having a tuner |
| KR100650739B1 (ko) | 2005-10-04 | 2006-11-29 | 한국전자통신연구원 | 개방형 ａｐｉ를 이용한 메시지 방송 서비스 제공 시스템및 방법 |
| GB2440199B (en) * | 2006-07-13 | 2008-11-12 | British Telecomm | Electronic programme guide for a mobile communications device |
| US8983639B2 (en) * | 2008-12-14 | 2015-03-17 | Apple Inc. | Techniques for facilitating interoperation between a host device and a digital RF tuner accessory |
| US8238893B2 (en) | 2009-09-03 | 2012-08-07 | Apple Inc. | Techniques for controlling a portable media device having a radio frequency tuner |
| JP5793871B2 (ja) * | 2011-01-25 | 2015-10-14 | ソニー株式会社 | 受信装置、受信方法、供給装置、供給方法、プログラム、および放送システム |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5339392A (en) * | 1989-07-27 | 1994-08-16 | Risberg Jeffrey S | Apparatus and method for creation of a user definable video displayed document showing changes in real time data |
| CA2153445C (en) * | 1994-09-08 | 2002-05-21 | Ashok Raj Saxena | Video optimized media streamer user interface |
| JP2000509216A (ja) * | 1996-04-15 | 2000-07-18 | エヌディーエス リミテッド | ディジタルビデオ放送システム |
| US6037932A (en) * | 1996-05-28 | 2000-03-14 | Microsoft Corporation | Method for sending computer network data as part of vertical blanking interval |
| GB2313981B (en) * | 1996-06-06 | 2001-04-18 | Roke Manor Research | Assymetric communications channel for a portable computer |
| JPH11513212A (ja) * | 1996-06-21 | 1999-11-09 | ベル コミュニケーションズ リサーチ，インコーポレイテッド | マルチメディア・オブジェクトを関連づけるシステムおよび方法 |
| JPH10333925A (ja) * | 1997-02-27 | 1998-12-18 | Zuno Ltd | オートノマス・エージェント・アーキテクチャ |
-
1999
- 1999-04-30 EP EP99108701A patent/EP1049278A1/en not_active Withdrawn
-
2000
- 2000-05-01 JP JP2000137169A patent/JP4590062B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001028571A (ja) | 2001-01-30 |
| EP1049278A1 (en) | 2000-11-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4422900B2 (ja) | テレビシステムにおいて複数の番組サービスを提供するシステムおよび方法 | |
| US6230324B1 (en) | Device for transmitting broadcast-program information and allowing other information sources to be accessed | |
| US8131875B1 (en) | Device profile assignment based on device capabilities | |
| US7519723B2 (en) | Scaling and delivering distributed applications | |
| CA2378709C (en) | Systems and methods for multimedia messaging in a cable or satellite subscriber system | |
| US20020032754A1 (en) | Method and apparatus for profiling in a distributed application environment | |
| US11962822B2 (en) | Extending data records for dynamic data and selective acceptance based on hardware profile | |
| JPH10275108A (ja) | データ分配方法、装置及びプリキャッシュ方法 | |
| CN103069831A (zh) | 接收设备、接收方法、发送设备、发送方法、程序和广播系统 | |
| JPH10177777A (ja) | 番組予約システム及び記録媒体 | |
| US20020129101A1 (en) | Event-driven information display system and event-driven information display method | |
| JP4590062B2 (ja) | 放送受信機システム及び放送受信機システムの動作方法 | |
| WO2008047192A2 (en) | System and method for managing and using electronic widgets | |
| US20020091792A1 (en) | Method and apparatus for client sharing of cached content | |
| JP2011044156A (ja) | プッシュコンテンツ処理プロトコル内をパスするメタデータ最適化方法およびシステム | |
| US7600045B2 (en) | Information processor | |
| WO2012157698A1 (ja) | 受信装置、プログラム及び受信方法 | |
| US20050071754A1 (en) | Pushing information to distributed display screens | |
| JP2003223387A (ja) | プログラムダウンロードシステム、放送通信融合端末およびプログラムダウンロード方法 | |
| JP3473823B2 (ja) | 送信装置および送信方法、受信装置および受信方法、並びに送受信システムおよび送受信方法 | |
| JP2004312223A (ja) | 放送番組受信装置、番組情報取得方法およびプログラム | |
| KR20070063571A (ko) | Ｍｈｐ 애플리케이션들의 시동 시간을 감소시키기 위한시스템 및 방법 | |
| JP2001157130A (ja) | テレビジョンシステムにおいて展開する要約を伝送し処理する方法、並びに、かかるシステムの受信器及び送信器 | |
| JP2011124675A (ja) | 双方向デジタル放送用ポータルサーバおよび双方向デジタル放送受信機 | |
| JP4844350B2 (ja) | 放送受信機、ダウンロードデータ取得方法及びそのプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070423 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20081002 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20081111 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090901 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20091201 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20091214 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20100104 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20100115 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100201 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100525 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100805 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100824 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100913 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130917 Year of fee payment: 3 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |