JPH0846935A - オーディオ・ビデオ対話信号を処理する方法と装置 - Google Patents

Abstract

(57)【要約】 【目的】 データフローを効率よく監視し、できるだけ
速やかに所望のモジュールを処理する。 【構成】 要求されたパケットサービス内のパケットが
プログラムコンポーネント検出器３０により受信され、
しかも、ＤＭＡにより、ＲＡＭ４１２内の前に特定され
たバッファロケーションに書き込まれた後に、ビデオ処
理装置４２０とオーディオ処理装置４１８が、検出器３
０の制御により、ＤＭＡ読み出し技法を用いて、各パケ
ットサービスと関連するＲＡＭ４１２バッファロケーシ
ョンからデータを読み出す。ビデオ処理装置４２０とオ
ーディオ処理装置４１８は、圧縮され、符号化されたデ
ータを復号し、出力端子１５にＡＶＩビデオ信号を出力
し、出力端子２５にＡＶＩオーディオ信号を出力する。
データコンポーネントパケットサービスパケットは、Ｃ
ＰＵ４１０の制御により処理される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、オーディオ・ビデオ対
話（ＡＶＩ：ａｕｄｉｏ ｖｉｄｅｏ ｉｎｔｅｒａｃ
ｔｉｖｅ）信号を受信して処理する方法と装置に関す
る。

【０００２】

【発明の背景】対話型テレビジョンシステムが提案され
ている。対話型テレビジョンシステムでは、テレビジョ
ン受信機は、放送機器によりプログラム可能であり、ユ
ーザにより入力されたデータに応答し、放送されたビデ
オ上にオーバレイされたオンスクリーン・グラフィック
・ディスプレイを生成し、放送されたオーディオと合成
された音声を生成し、かつ／あるいは、放送機器、また
は他の外部のデータ処理サービスとデータを交換する処
理装置を含む。そのようなシステムでは、放送ロケーシ
ョンはコンピュータシステムを含み、このコンピュータ
システムは、対話型アプリケーションプログラム情報を
生成し、追加のコンポーネントとしての対話型アプリケ
ーションプログラム情報と、関連するテレビジョン信号
のビデオおよびオーディオ・コンポーネントとを合成す
る。テレビジョン受信器の処理装置は、対話型アプリケ
ーションプログラム情報を放送機器から受信し、その情
報により表された対話型アプリケーションプログラムを
実行し、テレビジョンの映像とオーディオとに合成され
るグラフィックスと音声を生成し、リモートコントロー
ルユニットを介して受信されるユーザ入力を処理する。

【０００３】提案されているＡＶＩシステムでは、放送
機器からのＡＶＩ信号はパケットデータストリームの形
態で放送され、複数の時間多重されたパケットサービス
を含む。各パケットサービスはＡＶＩ信号の異なる信号
コンポーネントを有する。例えば、あるサービスはビデ
オコンポーネントを有し、あるサービスはオーディオコ
ンポーネントを有し、あるサービスは対話型アプリケー
ションプログラム情報を有する。また、あるサービスは
ステレオとＳＡＰオーディオチャンネル、および／また
は、クローズドキャプション情報等を有する。さらに、
パケットデータストリームの中には、２つ以上のＡＶＩ
プログラムに対するコンポーネントを有するパケットサ
ービスを含むことができるものもある。各パケットサー
ビスは、パケットサービスに関連する一意のサービスコ
ンポーネント識別子（ＳＣＩＤ）を有し、そのパケット
サービス内のパケットは、それぞれ、そのサービス識別
子を含む。米国特許出願第２３４，７７３号（発明の名
称：ＡＰＰＡＲＡＴＵＳＡＮＤ ＭＥＴＨＯＤ ＦＯＲ
ＦＯＲＭＵＬＡＴＩＮＧ ＡＮ ＩＮＴＥＲＡＣＴＩ
ＶＥ ＴＶ ＳＩＧＮＡＬ を参照されたい。この米国
特許出願番号を付して、このようなパケットデータスト
リームがどのように形成されるかを詳細に説明する説明
の一部とする。

【０００４】さらに、提案されたＡＶＩシステムでは、
１つのパケットサービスがプログラムガイドを有し、予
め定めたサービス識別子を含む。プログラムガイドパケ
ットサービスにより運ばれるデータは、ＡＶＩプログラ
ムのコンポーネントと、それらのコンポーネントを運ぶ
パケットサービスのサービス識別子とを関係付ける。こ
のデータを用いて、望ましいＡＶＩプログラムのコンポ
ーネントを運ぶパケットサービスを、パケットストリー
ムから取り出すことができる。

【０００５】ＡＶＩ信号パケットデータストリーム内の
コンポーネントは、複数のパケットからなる１以上の伝
送ユニットにより運ばれる。任意の伝送ユニット内の最
初のパケットはヘッダパケットであり、残りのパケット
は関連するデータパケットである。ヘッダパケットは後
続データについての情報を含み、関連するデータパケッ
トはコンポーネントのその部分を構成するデータを運
ぶ。異なる伝送ユニットは異なる数のデータパケットを
含み、モジュールの伝送ユニットへの分割は、所望の時
間に、視聴者のロケーションに完全なモジュールを供給
するために必要なタイミングにより影響されるか、ある
いは、他のリアルタイムに考慮すべきことにより影響さ
れる。

【０００６】対話型アプリケーションプログラム情報コ
ンポーネントは、１つ以上の（実行可能なコードを含
む）コードモジュールと、可能な場合は、１つ以上のデ
ータモジュールと、ディレクトリモジュールとによりな
る。このディレクトリモジュールは対話型アプリケーシ
ョンプログラムのコンポーネントを構成するコードモジ
ュールとデータモジュールを記述するデータを含む。こ
れらのモジュールは、アプリケーション・プログラム・
コンポーネントのフロー内で連続して繰り返される。既
に述べたが、モジュールは伝送ユニットにより運ばれ
る。伝送ユニット内のヘッダパケットは、さらに、後続
のデータパケット内のデータが属するモジュール内のロ
ケーションを含む。

【０００７】ＡＶＩ受信機の処理装置は、最初、データ
フローからディレクトリモジュールを取り出し、そのデ
ィレクトリに含まれた情報を利用して、どのコードモジ
ュールを最初に実行するべきかを決定する。そして、そ
のコードモジュールがデータフローから取り出され、メ
モリ内の周知のロケーションにロードされる。最初のコ
ードモジュールがメモリ内に完全にロードされると、処
理装置がそのコードモジュールを実行し始める。実行し
ている間、そのコードモジュールは、ディレクトリモジ
ュール内で識別されたデータモジュールからのデータを
要求することができる。そして、これらのデータモジュ
ールが取り出され、メモリ内にロードされる。データモ
ジュールがメモリ内に完全にロードされると、要求され
ているコードモジュールが通知され、引き続きそのデー
タを処理する。１つのコードモジュールを後続のコード
モジュールにチェインすることも可能である。このよう
な場合、現コードモジュールは、ディレクトリモジュー
ルにリストアップされた新しいコードモジュールにチェ
インする要求を発行し、そのメモリ空間は解放される。
そして、要求されたコードモジュールはデータフローか
ら取り出され、メモリにロードされる。要求されたコー
ドモジュールがメモリに完全にロードされると、実行さ
れる。他の機能も可能であり、次に説明する。

【０００８】メモリ容量が充分な場合は、２つ以上のコ
ードモジュールを、メモリの個々の部分に同時に貯える
ことができる。そのような場合、モジュールからモジュ
ールにチェイニングすると、必然的に、新たなモジュー
ルの実行を開始するステップと、新しいモジュールがフ
ローからロードされるまで待機する要件を除くステップ
とを伴う。メモリに２つ以上のデータモジュールをロー
ドすることも可能である。データモジュールの変更はコ
ードモジュールよりも頻繁なので、データモジュールが
コードモジュールにより要求されると、データモジュー
ルがデータフローから取り出されることが考えられる。

【０００９】提案されているＡＶＩ受信機の処理装置
は、大容量記憶装置や、プリロードされたＡＶＩプログ
ラムを持つ必要がない。代わりに、対話型アプリケーシ
ョン・プログラム・パケット・サービスで運ばれるモジ
ュールが連続して繰り返されるので、必要なときは、ど
のモジュールもデータフローから取り出すことができ、
大容量記憶装置は必要でない。しかしながら、このた
め、ＡＶＩ受信機の処理装置は、要求されたモジュール
がデータフローに存在するか否かを連続的に監視しなけ
ればならない。データフローを効率よく監視し、できる
だけ速やかに所望のモジュールを処理する方法と装置が
要望されている。

【００１０】

【課題を解決するための手段】本発明の原理によれば、
オーディオ・ビデオ対話型（ＡＶＩ）受信機は、複数の
モジュールを含むパケットサービスを受信する。各モジ
ュールは名前を持ち、時間多重された伝送ユニットを含
む。各伝送ユニットはヘッダパケットを含み、ヘッダパ
ケットはモジュールの名前を含む。このような受信機で
モジュールを処理する方法は次のスッテップを含む。最
初に、名前により識別されたモジュールに対するプロセ
スを実行する要求が受信され、受信されたモジュール名
と要求されたされたプロセスを含むエントリがエントリ
リストに挿入される。そして、パケットサービスのヘッ
ダパケットが検出される。検出されたヘッダパケット内
のモジュール名がリストのエントリの名前と一致した場
合、パケット処理回路が一致するエントリでプロセスを
実行する。最後に、プロセスがパフォームされたことを
示すメッセージが送信される。

【００１１】本発明の原理による装置は、複数のモジュ
ールを含むパケットデータストリームのソースを含む。
各モジュールは名前を持ち、時間多重された伝送ユニッ
トを含む。各伝送ユニットはモジュールの名前を含むヘ
ッダパケットを含む。メモリは複数のエントリを含む要
求キューを貯える。各エントリは処理要求とモジュール
の名前を含む。メモリはヘッダパケットバッファも貯え
るッダパケットバッファはモジュール名前を含むロケー
ションを含む。要求処理回路は名前により識別されたモ
ジュールに対する処理を実行する要求を受信し、識別さ
れたモジュールの名前と、要求された処理とを含む要求
キューにエントリを貯える。ヘッダパケット・メモリ・
ストア・コントローラは、ヘッダパケットがデータスト
リームに現れると、ヘッダパケットをヘッダパケットバ
ッファにストアし、ヘッダパケット受信信号を生成す
る。モジュール処理回路はヘッダパケット受信信号に応
答して、ヘッダパケットバッファからモジュール名を読
み出し、要求バッファの各エントリの名前と、モジュー
ル名を比較し、ヘッダパケットのモジュール名がエント
リ名と一致すると、一致要求キューエントリで、要求さ
れた処理を実行する。

【００１２】

【実施例】図１は本発明に係るオーディオ・ビデオ対話
型信号デコーダの一部を示すブロック図である。図１に
示すデコーダは、オーディオ・ビデオ対話型プログラム
への参加を希望する視聴者ロケーションに設けられてい
る。図１において、トランスポート機構（図示せず）は
デコーダの入力端子５に接続されている。入力端子５は
チューナ１０の入力端子に接続されている。チューナ１
０の出力端子は、オーディオ・ビデオ対話型プログラム
・コンポーネント検出器３０のデータ入力端子に接続さ
れている。プログラム・コンポーネント検出器３０のデ
ータ出力端子は、処理ユニット４０のシステムバス４１
６に接続されている。処理ユニット４０は、ＣＰＵ（ｃ
ｅｎｙｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）４１
０と、リード／ライトメモリ（ＲＡＭ）４１２と、ＲＯ
Ｍ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）４１４を含
み、共に、システムバス４１６に周知の方法で接続され
ている。ストリームＩ／Ｏアダプタ４０８は、システム
バス４１６と、プログラム・コンポーネント検出器３０
の制御端子間に双方向接続される。

【００１３】オーディオ処理装置４１８はシステムバス
４１６に接続されており、オーディオ・ビデオ対話型オ
ーディオ出力端子２５にオーディオ信号を供給する。ビ
デオ処理装置４２０も、システムバス４１６に接続され
ており、ビデオ信号をオーディオ・ビデオ対話型ビデオ
出力端子１５に供給する。さらに、入出力機能がＩ／Ｏ
ポート４２２により与えられ、双方向端子４５を介し
て、図示しないローカル処理装置に結合されている。ユ
ーザＩ／Ｏアダプタ４２４はユーザからのデータを入力
端子３５を介して受信する。モデム４２６は双方向端子
５５を介して外部コンピュータ（図示せず）に接続され
ている。ユーザＩ／Ｏアダプタ４２４と、モデム４２６
も、周知の方法でシステムバス４１６に接続される。他
の装置、例えば、数値計算プロセッサ、他のＩ／Ｏアダ
プタ等を、周知の方法で、システムバス４１６に接続す
ることができる。その上、デコーダのケースの外部のケ
ース内の他の機器と接続するためのバス拡張装置を含ま
せることができる。

【００１４】動作時、トランスポート機構は、例えばデ
コーダへの直接ＲＦ衛星リンクか、ケーブルシステムフ
ィード（ｃａｂｌｅ ｓｙｓｔｅｍ ｆｅｅｄ）か、あ
るいは光ファイバーリンクでも可能であり、複数のオー
ディオ・ビデオ対話型信号を搬送する。複数のオーディ
オ・ビデオ対話型信号は、ユーザにより選択され視聴さ
れる。直接衛星リンクでは、例えば、複数のオーディオ
・ビデオ対話型データストリームは、個々のＲＦ搬送波
信号を変調することにより、トランスポート機構上で周
波数多重化されたものでもよい。各ＲＦ搬送波信号は、
衛星内の各トランスポンダから視聴者に再び放送され
る。チューナ１０は、周波の方法で、処理ユニット４０
の制御により、所望のＲＦ変調信号を選択する。例え
ば、直接衛星システムでは、所望のオーディオ・ビデオ
対話型プログラム信号のコンポーネントを運ぶパケット
サービスを含むＲＦ変調信号を、周知のＲＦチューナに
より同調をとることができる。チューナ１０の出力は、
それらのパケットサービスを含むベースバンドのデジタ
ル・パケット・データストリームである。

【００１５】ＣＰＵ４１０は、次のようにして、所望の
パケットサービスをプログラム・コンポーネント検出器
３０に対して要求する。すなわち、所望のサービス識別
子とＲＡＭ４１２バッファのロケーションを、ストリー
ムＩ／Ｏアダプタ４０８を介して、適正なＳＣＩＤ（ｓ
ｅｒｖｉｃｅ ｃｏｍｐｏｎｅｎｔ ｉｄｅｎｔｉｆｉ
ｅｒ）と、プログラム・コンポーネント検出器３０内の
ＤＭＡ（ｄｉｒｅｃｔｍｅｍｏｒｙ ａｃｃｅｓｓ）コ
ントローラ・レジスタとに書き込むことにより、要求を
行っている。そして、プログラム・コンポーネント検出
器３０は、所望のパケットサービスのため、パケットデ
ータストリームを監視する。所望のパケットサービスか
ら、ヘッダパケットが受信されると、そのヘッダパケッ
トは、周知のＤＭＡ書き込み技法を用いて、ＲＡＭ４１
２内の予め定めたヘッダパケットバッファに貯えられ、
ヘッダパケット割り込みが発生される。所望のパケット
サービスからデータパケットが受信されると、そのデー
タパケットは周知のＤＭＡ書き込み技法を使用して、Ｒ
ＡＭ４１２内の前もって特定されているバッファロケー
ションに貯えられる。伝送ユニット内の全てのデータパ
ケットが受信されると、データ完了割り込みが発生され
る。パケットサービスからのヘッダパケット、および／
または、データパケットの受信は、ＣＰＵ４１０の制御
によりイネーブルにされるか、あるいは、ディスエーブ
ルにされる。１９９４年４月２２日に出願された米国特
許出願第２３２，７８７号（発明者：Ｋ．Ｅ．Ｂｒｉｄ
ｇｅｗａｔｅｒ外、発明の名前：ＰＡＣＫＥＴ ＶＩＤ
ＥＯ ＳＩＧＮＡＬ ＩＮＶＥＲＳＥ ＴＲＡＮＳＰＯ
ＲＴ ＰＲＯＣＥＳＳＯＲ ＭＥＭＯＲＹ ＡＤＤＲＥ
ＳＳ ＤＩＲＣＵＩＴＲＹ）を参照されたい。ここに、
この特許出願番号を付して、プログラム・コンポーネン
ト検出器３０の詳細な説明の一部とする。

【００１６】例えば、新しいＲＦ変調信号がチューナ１
０により同調されると、固定されたプログラムガイドサ
ービス識別子を、プログラム・コンポーネント検出器３
０内のサービス識別子レジスタに供給することにより、
プログラムガイドを含むパケットサービスが、ＣＰＵ４
１０により要求される。プログラムガイドパケット内の
データが受信され、メモリに貯えられると、そのデータ
により、ＣＰＵ４１０は所望のオーディオ・ビデオ対話
型プログラムのためのパケットデータサービスを要求す
ることができる。

【００１７】要求されたパケットサービス内のパケット
がプログラム・コンポーネント検出器３０により受信さ
れ、しかも、ＤＭＡにより、ＲＡＭ４１２内の予め特定
されたバッファロケーションに書き込まれた後に、ビデ
オ処理装置４２０とオーディオ処理装置４１８が、プロ
グラム・コンポーネント検出器３０の制御の下に、周知
のＤＭＡ読み出し技法を用いて、各パケットサービスと
関連するＲＡＭ４１２バッファロケーションからデータ
を読み出す。そして、ビデオ処理装置４２０とオーディ
オ処理装置４１８は、圧縮され、符号化されたデータを
復号し、出力端子１５にオーディオ・ビデオ対話型ビデ
オ信号を出力し、出力端子２５にオーディオ・ビデオ対
話型オーディオ信号を出力する。ＣＰＵ４１０は、復号
プロセスにおいて、ビデオ処理装置４２０および／また
はオーディオ処理装置４１８と協力することも可能であ
る。データコンポーネントパケットサービスパケット
は、次のような方法により、ＣＰＵ４１０の制御の下に
処理される。

【００１８】上述したように、プログラム・コンポーネ
ント検出器３０により、要求されたパケットサービスか
らヘッダパケットが受信されるごとに、そのヘッダパケ
ットはそのパケットサービスのためにＲＡＭ４１２内の
予め定めたロケーションに貯えられ、ヘッダパケット割
り込み信号がＣＰＵ４１０のために生成される。ヘッダ
パケット割り込み信号に応答して、割り込みハンドラ
（ｈａｎｄｌｅｒ）が実行される。割り込みハンドラ
は、ヘッダパケットの内容を解析し、プログラム・コン
ポーネント検出器３０内のＤＭＡレジスタのＲＡＭ４１
２バッファロケーションを適正に更新し、ＤＭＡ転送を
イネーブルにするか、あるいは伝送ユニットが望まれて
いない場合は、ＤＭＡ転送をディスエーブルにする。Ｄ
ＭＡ転送が一度イネーブルにされると、データパケット
内のデータはＤＭＡ制御によりＲＡＭ４１２内にロード
される。データパケットのロードが完了すると、プログ
ラム・コンポーネント検出器３０はデータ完了割り込み
信号を発生する。データ完了割り込み信号に応答して、
割り込みハンドラが実行され、クリーンアップ（ｃｌｅ
ａｎ−ｕｐ）機能を実行し、次のヘッダパケットのため
の準備をする。

【００１９】図２は、図１に示す処理ユニット４０によ
り実行されるソフトウェア２００の構造を示す。図２は
オーディオ・ビデオ対話型処理マルチタスク・オペレー
ティングシステムを構成する主なソフトウェア・コンポ
ーネントを示す。図２を説明する。コンポーネントは全
てＲＯＭ４１４に貯えられる。ただし、黒く塗られたア
プリケーション・プログラムは除く。アプリケーション
・プログラムは、オーディオ・ビデオ対話型信号のデー
タコンポーネントにより運ばれ、放送ロケーションから
受信され、ＲＡＭ４１２に貯えられる。図２に示すソフ
トウェア・コンポーネントは、実行可能なコードおよび
関連する定数データを表す。コードが実行されると、変
数データを生成し、変数データにアクセスする。変数デ
ータはＲＡＭ４１２に貯えられる。

【００２０】提案されたオーディオ・ビデオ対話型放送
システムでは、例えば、異なる製造業者からの異なる命
令セットを用いて、異なるデコーダはＣＰＵを使用する
ことができる。このシステムでは、アプリケーション・
プログラムは、プロセッサに無関係な中間コードであ
る。各デコーダのソフトウェアは、アプリケーション中
間コードを解釈するコンポーネント（ＩＮＴＥＲＰＲＥ
ＴＥＲ：インタプリタ）を含む。インタプリタにより、
放送されたアプリケーション・プログラムは、どのよう
な形式のＣＰＵ４１０を含むデコーダ上でも実行するこ
とができる。このインタープリタは、ＲＡＭ４１２から
オーディオ・ビデオ対話型データコンポーネント命令を
中間コードの形で読み出し、メモリを操作し、ＡＰＩ
（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅ
ｒｆａｃｅ）を介して、他のソフトウェア・コンポーネ
ントを介してハードウェアと対話する。このＡＰＩは、
基本的には、アプリケーション・プログラムで利用可能
なサブルーチンのリストであって、サブルーチンを呼び
出すのに必要な情報である。ＡＰＩはアプリケーション
・プログラムにより発行され、デコーダ要素をアクセス
するために、アプリケーション・プログラムにより使用
することができる。

【００２１】数学ライブラリは整数演算と浮動小数点演
算を実行するのに必要な機能を全て実行する。フロー・
オペレーティング・システムは、オーディオ・ビデオ対
話型信号のデータコンポーネントを監視するのに必要な
全てのドライバーと、プロセス要求されたモジュールと
を制御する。このことは後程詳細に説明する。ユーザイ
ンターフェース管理コンポーネントは、ユーザとの対話
を全て扱い、ユーザと通信するため、イベントマネジャ
とグラフィックス・ライブラリを利用する。このグラフ
ィックス・ライブラリは、受信されたオーディオ・ビデ
オ対話型ビデオ上にオーバレイする全てのグラフィック
イメージを生成し、数学ライブラリを用いて、複雑な曲
線を描く。

【００２２】デコーダソフトウェアの異なるソフトウェ
アコンポーネントは、互いにメッセージを送信して、他
と非同期に通信する。各プログラムコンポーネントは、
メッセージキュー（ｍｅｓｓａｇｅ ｑｕｅｕｅ）を有
し、そのキューから次のメッセージを繰り返し読み出
し、そのメッセージを処理し、他のプログラムコンポー
ネントにメッセージを送信することにより、オペレート
する。メッセージ保留がない場合は、次のメッセージを
待つ。イベントマネジャは、メッセージを適正にルーテ
ィングし、メッセージキューを維持することにより、他
のソフトウェアコンポーネントとの間でのメッセージ通
信を管理する。

【００２３】各ハードウェアアダプタは、関連するソフ
トウェアドライバも含む。ドライバは、関連するハード
ウェアアダプタ内のレジスタとＣＰＵ４１０との間で、
システムバス４１６を介して、実際の対話を行う。例え
ば、モデム４２６と、外部Ｉ／Ｏポート４２２と、スト
リームＩ／Ｏアダプタ４０８と、ユーザＩ／Ｏ ４２４
に対して、ドライバが存在する。さらに、別のドライバ
がソフトウェアタイマを保守し、デコーダのフロントパ
ネルを操作する。これらのドライバはイベントマネジャ
に密接に依存している。上記のコンポーネントは、全
て、マルチタスクカーネルにより供給される共通の機能
を使用する。例えば、カーネルは、プロセスの優先順位
と、アクティブタスクキューと、信号と、セマフォア
と、プリエンプティブ・スイッチング・クロック・チッ
クと、割り込み（ハードウェアおよびソフトウェア）
と、プロセススタックを保守する。さらに、カーネル
は、ハードウェア初期化を行い、システムローダである
最初のシステムタスクを開始する。

【００２４】開始時に、システムローダはフロー・オペ
レーティング・システムへのＡＰＩコールを実行し、フ
ロー・オペレーティング・システムはストリームドライ
バをコールし、ストリームＩ／Ｏアダプタ４０８を介し
て、プログラム・コンポーネント検出器３０に適正なデ
ータを送る。システムローダからのこれらのＡＰＩコー
ルにより、ディレクトリ・モジュールに対して、データ
コンポーネントパケットサービスのスキャンを開始す
る。この方法は以下に詳細に説明する。ディレクトリ・
モジュールが見つけられると、ディレクトリ・モジュー
ルがＲＡＭ４１２にロードされ、そのプログラムを実行
するのに必要な資源が全て利用可能か否かを知るため、
チェックされる。肯定判定された場合は、システムロー
ダはオートスタート・モジュールと呼ばれる最初のモジ
ュールに対してオーディオ・ビデオ対話型データコンポ
ーネントの走査を開始し、それによりオーディオ・ビデ
オ対話型プログラムは起動されることになる。オートス
タートモジュールが見つかると、データコンポーネント
・パケットサービスから取り出され、ＲＡＭ４１２にロ
ードされる。このオートスタートモジュールは、中間コ
ードの形式であり、インタプリタによりインタプリート
されて実行される。オートスタートモジュールは初期化
の残りを実行し、オーディオ・ビデオ対話型プログラム
の実行を開始する。このプログラムは他のコードモジュ
ールとデータモジュールをロードすることができ、全
て、ＡＰＩコールにより、他のコードモジュールとチェ
イン（ｃｈａｉｎ）することができる。このようにし
て、システムローダはクラシックのＵＮＩＸ（登録商
標）シェルと同様に動作する。

【００２５】さらに、システムローダは引き続きデータ
コンポーネント・パケットサービスをスキャンし、伝送
されたディレクトリ・モジュールと、ＲＡＭ４１２内の
現在のディレクトリ・モジュールとを比較する。伝送さ
れたディレクトリ・モジュールがＲＡＭ４１２に格納さ
れているディレクトリ・モジュールと異なる場合、デー
タコンポーネント・パケットサービスが変更されたこ
と、例えば、視聴者がチャンネルを変えたときとか、対
話型コマーシャルが放送されているときのようなことを
示す。この場合、メッセージが、イベントマネジャを介
して、ＡＰＩを用いて、アプリケーション・プログラム
に送られる。このメッセージに応答して、アプリケーシ
ョン・プログラムは全ての資源の割り振りを解除し、処
理要素４０内に最小限存在するように維持する。例え
ば、コードモジュールとデータモジュールの全てを格納
するために使用されるメモリを解放することができ、ア
プリケーションの実行状態だけがＲＡＭ４１２に保たれ
る。アプリケーション・プログラムの最小化が完了する
と、メッセージがシステムローダに送られる。

【００２６】そして、新しいディレクトリモジュールに
より表わされるオーディオ・ビデオ対話型プログラムを
実行するのに必要な資源を、システムローダは割り振
る。新しいディレクトリ・モジュールがオーディオ・ビ
デオ対話型データコンポーネント・パケットサービス内
で検出されたとき、前に最小化されたアプリケーション
のリストが検索される。そして、新しいディレクトリに
より表されるアプリケーションが存在する場合は、その
アプリケーションは、データコンポーネントフローか
ら、必要なコードモジュールとデータモジュールを再ロ
ードすることにより再開される。また、前に停止した所
から実行を再開することにより再開される。このモジュ
ールは、介在する対話型コマーシャルの終了時に起き
る。このプロセスは繰り返すことができる。ただし、第
２のオーディオ・ビデオ対話型プログラムに、第３のオ
ーディオ・ビデオ対話型プログラムが割りこむことがで
きる。後に、再起動される。

【００２７】図３はフローとメモリのレイアウトを示
す。図４はオーディオ・ビデオ対話型プログラム中のデ
ータコンポーネントからのモジュール抽出を理解するの
に有用な詳細なメモリレイアウトと（図１の）プログラ
ム・コンポーネント検出器３０の更に詳細なブロック図
である。図４において、（図１の）チューナ１０からの
ベースバンドのデジタルパケットストリームが、プログ
ラム・コンポーネント検出器３０内でヘッダパケットＤ
ＭＡコントローラ３４と、データＤＭＡコントローラ３
２との各データ入力端子に接続されている。データＤＭ
Ａコントローラ３２と、ヘッダパケットＤＭＡコントロ
ーラ３４の各データ出力端子は、処理ユニット４０のシ
ステムバス４１６に接続されている。ストリームＩ／Ｏ
アダプタ４０８は、システムバス４１６と、データＤＭ
Ａコントローラ３２の制御入力端子と、ヘッダパケット
ＤＭＡコントローラ３４の制御入力端子との間に接続さ
れている。動作時には、ストリームＩ／Ｏアダプタ４０
８は、（図１の）ＣＰＵ４１０から、データＤＭＡコン
トローラ３２とヘッダパケットＤＭＡコントローラ３４
に、制御情報、例えば、バッファロケーション開始アド
レスおよび終了アドレスと、読み出しアドレス／書き込
みアドレスと、転送計数値を、周知の方法で供給する。
そして、ＣＰＵ４１０の制御の下に、ストリームＩ／Ｏ
アダプタ４０８は、データＤＭＡコントローラ３２およ
び／またはヘッダパケットＤＭＡコントローラ３４をイ
ネーブルにして、周知の方法で、データパケットまたは
ヘッダパケットを、パケットストリームからバッファに
転送するか、あるいは、このような転送をディスエーブ
ルにする。データＤＭＡコントローラ３２がデータ転送
を完了すると、ＣＰＵ４１０に対して、データ完了割り
込みを生成する。ヘッダパケットＤＭＡコントローラ３
４がヘッダパケットのローディンを完了すると、ＣＰＵ
４１０に対して、ヘッダパケット割り込みを生成する。

【００２８】図４でも、ＲＡＭ４１２を大きなブロック
で表し、データ構造を大きなブロック内の小さいブロッ
クで表す。図４のブロックは図示のためだけであり、絶
対記憶位置または相対記憶位置の何れかを示すものでは
なく、データ構造に対して、ＲＡＭ４１２に割り振られ
たサイズを示すものでもない。参照番号４１２に、モジ
ュールリクエストキュー３２２と、ヘッダパケットバッ
ファ３２４と、ディレクトリ・モジュールバッファ３２
６と、モジュールバッファ３２８のデータ構造を示す。
テータ構造内の情報のフィールドは、そのフィールド内
に含まれる情報のタイプの名前を含む水平スライスとし
て示されている。これらについては以下に詳細に説明す
る。

【００２９】図３は、ヘッダパケットデータコンポーネ
ント・パケットサービスからモジュールを取り出し、し
かも、そのモジュールをＲＡＭ４１２内のバッファに格
納する際の後続の手順を示す。同様な手順は他のモジュ
ール処理に対しても続けられる。これも以下に説明す
る。図３では、アプリケーション・プログラム（または
システムローダ）で取られるアクションを、“ＡＰＰＬ
ＮＰＲＯＧ”のヘッドを付けた左カラムに示す。ブロッ
ク３０２で、アプリケーション・プログラムは、ＡＰＩ
を用いて、フロー・オペレーティング・システムにリク
エストを出し、識別子ＩＤを有するモジュールを、オー
ディオ・ビデオ対話型プログラムコンポーネントパケッ
トサービスからロードする。上述したように、ＡＰＩコ
ールは、基本的には、オペレーティングシステム機能へ
のサブルーチンコールである。したがって、プログラム
の実行はフロー・オペレーティング・システム（ＦＯ
Ｓ）に移行される。フロー・オペレーティング・システ
ムのアクションは“フロー・オペレーティング・システ
ム”のヘッドを付けた右隣のカラムに示す。リクエスト
はモジュールのロードを含むので、ブロック３１２で、
フロー・オペレーティング・システムはモジュールのロ
ーディングを含むので、ブロック３１２にて、フロー・
オペレーティング・システムは、メモリマネジャから、
そのモジュールを含むだけのサイズのメモリの割り振り
をリクエストする。例えば、リクエストされたモジュー
ルがコードモジュールまたはデータモジュールである場
合は、（図４の）前に格納されたディレクトリ・モジュ
ール３２６は、モジュールＩＤの長さ（ＬＥＮＧＴＨ）
を含んでいるフィールドを含む。この場合、メモリマネ
ジャは、開始アドレスＳＴＡＲＴと終了アドレスＥＮＤ
を有するモジュールメモリバッファ（図４の３２８）を
割り振る。そして、ブロック３１４においてリクエス
ト、例えば、モジュールの識別子ＩＤと、リクエストＲ
ＥＱＵＥＳＴ（この場合はモジュールを取り出しロード
するリクエスト）のタイプを示す情報と、割り振られた
バッファ開始アドレスＳＴＡＲＴと終了アドレスＥＮＤ
が、全て、リクエストキュー（ＱＶＥＶＥ）３２２内の
エントリに格納される。そして、ヘッダパケットがパケ
ットストリーム内に生じたとき、ヘッダパケットＤＭＡ
コントローラがイネーブルにされ、ヘッダパケットをＲ
ＡＭ４１２にロードする。

【００３０】リクエストがディレクトリ・モジュールに
対するものである場合は、その長さが元々分かっていな
い。この場合、比較的大きいメモリ割り振りがリクエス
トされる。この割り振りがあまりにも小さい場合は、よ
り大きなメモリ割り振りをリクエストした後、ディレク
トリ・モジュールがロードされるか、あるいはそれをロ
ードするだけのメモリがないと決定されるまでリクエス
トは繰り返えされ、その場合、オーディオ・ビデオ対話
型プログラムをランさせる試みは放棄される。

【００３１】また、フロー・オペレーティング・システ
ムはコールしたアプリケーション・プログラムに直ちに
戻る。次いで、アプリケーション・プログラムは他の処
理、例えば、他のモジュールのリクエストを発し、他の
初期化等の処理を実行することができる。リクエストさ
れたモジュールへのアクセスが必要とされると、アプリ
ケーション・プログラムは、ブロック３０４にて、カー
ネル内の待ち機能にＡＰＩコールを発する。この機能に
より、リクエストされたモジュールのロードが成功した
ことを示すメッセージが、そのアプリケーション・プロ
グラムにより受信されるまで、アプリケーション・プロ
グラムの実行は中断させられる。そのようなメッセージ
が受信されると、アプリケーション・プログラムは再び
アクティベートされ、そのメッセージを処理する。ある
いはまた、例えば、より速くユーザ入力に応答するた
め、アプリケーション・プログラムはアクティブのまま
であり、そのメッセージキューを周期的にポーリング
し、リクエストされたモジュールロードの成功を示すメ
ッセージをチェックし、そのメッセージが受信されたと
き、メッセージを処理するようにしてもよい。

【００３２】上述したように、ヘッダパケットＤＭＡコ
ントローラ３４は、メモリマネジャにより、前に割り振
られたＲＡＭ４１２のヘッダパケット（ＨＤＲ ＰＫ
Ｔ）バッファ３２４（図４）にヘッダパケットをロード
し、ＣＰＵ４１０にヘッダパケット割り込みを発する。
カーネル内のヘッダ割り込みハンドラにより実行される
処理の一部を、図３に“ＨＥＡＤＥＲ ＩＮ ＴＲ”の
ヘッドを付して示す。ブロック３３２にて、伝送ユニッ
トに入れて運ばれているモジュールの識別子、この場
合、ヘッダパケットは、ヘッダパケットバッファ３２４
内の知られたロケーション、すなわち、ＩＤから取り出
される。ブロック３３４にて、リクエストキュー３２２
が試験され、このモジュールに対する保留中のリクエス
トが存在かるか否かが判定される。

【００３３】そのモジュールに対する保留中のリクエス
トがある場合には、ブロック３３６において、プログラ
ム・コンポーネント検出器３０のデータパケットＤＭＡ
コントロール３２は、リクエストキュー３２２からのア
ドレスＳＴＡＲＴで始まり、アドレスＥＮＤで終了する
モジュールバッファ３２８と；モジュールバッファ３２
８の開始アドレスＳＴＡＲＴと送信ユニットのデータオ
フセットＯＦＦＳＥＴの和、すなわち（ＳＴＡＲＴ＋Ｏ
ＦＦＳＥＴ）である書き込みアドレスと；ＳＴＡＲＴ＋
ＯＦＦＳＥＴ＋ＳＩＺＥ（あるいは代りに、最後の書き
込みアドレスに代わってヘッダパケットバッファ３２４
からのサイズＳＩＺＥであるロード計数値）である最後
の書き込みアドレスと；で初期化される。そして、デー
タパケットＤＭＡコントローラ３２がイネーブルにされ
る。

【００３４】ブロック３３８にて、これがロードリクエ
ストの行われた後受信された最初のヘッダパケットであ
る場合は、リクエストキュー３２２に格納される最初の
書き込みアドレスのポインタＦＩＲＳＴが、この最初の
送信ユニットの書き込みアドレス（すなわち、ＦＩＲＳ
Ｔ＝ＳＴＡＲＴ＋ＯＦＦＳＥＴ）に初期化される。さら
に、予想される次の書き込みアドレスを指すポインタＮ
ＥＸＴも、リクエストキュー３２２に格納されており、
最初の送信ユニットの書き込みアドレス（すなわち、Ｎ
ＥＸＴ＝ＳＴＡＲＴ＋ＯＦＦＳＥＴ）に初期化される。
そして、他の処理がブロック３３８にて行われる。これ
については以下に詳細に説明する。例えば、現在処理さ
れているリクエストのリクエストキュー３２２内のロケ
ーションを指す特殊なポインタＣＵＲＲ ＲＥＱは、Ｒ
ＡＭ４１２内の予め決められたロケーション（図示せ
ず）に格納される。その後、ブロック３３９にて、割り
込みハンドラーはリターンする（３３９）。

【００３５】データパケットＤＭＡコントローラ３２
は、先に受信した書き込みアドレス（ＳＴＡＲＴ＋ＯＤ
ＤＳＥＴ）を指す書き込みポインタ（ＷＰ）を初期化
し、オーディオ・ビデオ対話型プログラムコンポーネン
トパケットサービス内の後続のデータパケットから、デ
ータをＲＡＭ４１２内のモジュールバッファ３２８内の
順次ロケーションにロードする。送信ユニット内の全て
のデータがＲＡＭ４１２にロードされると、データ完了
割り込みが生成される。カーネル内のデータ完了割り込
みハンドラにより実行される処理の一部を、図３の右カ
ラムに“ＤＡＴＡＣＯＭＰＬ ＩＮＴＲ”のヘッドを付
けて示す。

【００３６】ブロック３４２にて、ＤＭＡ転送の現在の
状態に関連するクリーンアップ機能が実行される。現在
のリクエストポインタ（ＣＶＲＲ ＲＥＱ）は、ヘッダ
パケット割り込みハンドラ内に前にセットされており、
リクエストキュー３２２内のエントリーを指しており、
伝送ユニットはリクエストキューへのロードを丁度終了
したばかりである。現在のリクエスト内で、予想される
次の書き込みアドレスポインタＮＥＸＴは、ヘッダパケ
ットバッファ３２４からの値ＳＩＺＥによりインクリメ
ントされ、次の伝送ユニットに対して予想される書き込
みアドレスを指している。予想される次の書き込みアド
レスポインタ、ＮＥＸＴの値が、モジュールバッファ３
２８の終了アドレス、ＥＮＤに等しい場合は、ラップア
ランドして、書き込みアドレスポインタＮＥＸＴはモジ
ュールバッファ３２８の開始アドレスＳＴＡＲＴにリセ
ットされる。

【００３７】ブロック３４４にて、リクエストされたモ
ジュールの全体がメモリにロードされたか否かが判定さ
れる。予想される次の書き込みアドレスポインタ、ＮＥ
ＸＴの値は、最初のロードされたアドレス，ＳＴＡＲＴ
の値と比べられるそれらの値が同じである場合は、モジ
ュール全体はロードされている。ブロック３４６で、メ
ッセージは、イベントマネジャにより、リクエストして
いるアプリケーション・プログラムに送られ、リクエス
ト・モジュールが、図３に破線で示すように、完全に取
り出されたことを示す。さらに、リクエストはリクエス
トキュー３２２から除去される。予想される次の書き込
みアドレス ＮＥＸＴの値が最初にロードされたアドレ
ス，ＳＴＡＲＴと同じでない場合は、データ完了割り込
みハンドラはリターンし（３４９）、リクエストされた
モジュールのためのデータを含む次の伝送ユニットが、
先に説明したように、ヘッダパケット割り込みハンドラ
により処理される。どちらの場合も、現在のリクエスト
ポインタ（ＣＶＲＲ ＲＥＱ）はクリアされる。

【００３８】伝送ユニットのある部分がプログラム・コ
ンポーネント検出器３０により適正に受信されない場
合、後続のヘッダパケットが受信されてから、先行する
ヘッダパケットからのデータ完了割り込み信号がプログ
ラム・コンポーネント検出器３０内のＤＭＡ回路により
生成される。よって、先行するデータ完了割り込み信号
が生成される前に後続のヘッダパケット割り込み信号が
生成される。ヘッダパケット割り込みハンドラとデータ
完了割り込みハンドラは、協力して処理し、このような
状況を識別することができ、そのようなエラーを処理す
ることができる。

【００３９】ヘッダパケット割り込みハンドラでは、デ
ータパケットＤＭＡコントローラ３４がイネーブルにさ
れて、次の伝送ユニットを受信した後、そのような処理
が（図３の）ブロック３３８で実行される。受信された
各ヘッダパケットに対し、データ完了割り込みハンドラ
によって前に更新された現在のリクエストキューエント
リの予想される次の書き込みアドレス，ＮＥＸＴが、新
たに受信されるヘッダパケットのための書き込みアドレ
ス（ＳＴＡＲＴ＋ＯＦＦＳＥＴ）と比較される。それら
のアドレスが同じである場合は、前の伝送ユニットの受
信が成功したことになる。しかしながら、最後の終了ア
ドレスが新らしいオフセットと同じでない場合は、前の
伝送ユニットのＤＭＡ転送が完全に成功しなかったこと
を意味する。この場合、前の伝送ユニットのＤＭＡ転送
が完全に成功しなかったことを意味する。この場合、最
初の書き込みアドレス，ＦＩＲＳＴと、予想される次の
書き込みアドレス，ＮＥＸＴは、現在の書き込みアドレ
ス（ＳＴＡＲＴ＋ＯＦＦＳＥＴ）に更新される。すなわ
ち、前にロードされた伝送ユニットは必然的に破棄さ
れ、モジュールのロードは現在の伝送ユニットから再ス
タートされる。前に成功りにロードされた伝送ユニット
は、再ロードされるときエラーを生じるかもしれないの
で、データ紛失というエラーから回復する時間が長くか
かることがある。しかしなから、このような回復を用い
ることにより、ヘッダパケット割り込みハンドラと、デ
ータ完了割り込みハンドラにより実行されるタスクを、
最小化することができ、２つのポインタのみがメモリに
必要なだけである。

【００４０】モジュール完了メッセージ処理の一部とし
て、イベントハンドラが、受信されたモジュールに対し
てエラーチェックを行う。例えば、ＣＲＣ（ｃｙｃｌｉ
ｃｒｅｄｕｎｄａｎｃｙ ｃｈｅｃｋ）コードがモジュ
ールの埋め込み部分として伝送される。イベントハンド
ラは、ＲＡＭ４１２内のモジュールバッファ３２８内の
受信されたモジュール全体のＣＲＣを計算し、そのＣＲ
Ｃと埋め込みＣＲＣとを比較する。新たに計算されたＣ
ＲＣが埋め込みＣＲＣと等しい場合は、モジュールは正
しく受信されたことを示し、そうでない場合は、エラー
が起きたことを示し、モジュールは先に述べたように再
ロードされる。

【００４１】リクエストされたモジュールがメモリ内に
完全にロードされると、アプリケーションモジュールに
よる更なる処理が、図３に、待ち機能３０４に対するＡ
ＰＩコールの底から直線で示すように、推論により続行
することができる。しかしながら、アプリケーション・
プログラム内の別のタスクが、そのアプリケーション・
プログラムのメッセージキューからのメッセージの受信
に応答してアクティブにされる。

【００４２】先に説明したＡＰＩすなわちアプリケーシ
ョン・プログラム・インタフェースは、インタプリタを
介してアプリケーション・プログラムか、またはシステ
ムローダによりデータストリームへアクセスする機能を
含んでいる。アプリケーションプログラマは、発行され
たＡＰＩ記述を用いて、望ましいデータストリーム機能
へアクセスするためのＡＰＩコールを定式化することに
なる。最初のグループの機能は、モジュールのディレク
トリに関する。最初の機能ＤＩＲ＿ＮＥＷは、新しいデ
ィレクトリのリクエストである。先に説明したように、
このＡＰＩ機能に応答して、メモリの割り振りがなさ
れ、その後、リクエストはデータストリームに次のディ
レクトリ・モジュールをロードするためにエンキューさ
れ、ＡＰＩ機能はリターンする。ディレクトリがロード
されたとき、メッセージは、リクエスト・プログラムに
送られる。他の機能ＤＩＲ＿ＦＲＥＥは、現在のディレ
クトリにより占められているメモリ空間を解放する。機
能ＤＩＲ＿ＳＥＬＥＣＴは、どのディレクトリ・モジュ
ールが後続のＡＰＩコールで使用されるかを示した。機
能ＤＩＲ＿ＣＵＲＲＥＮＴは、現在選択されているディ
レクトリにハンドラを戻る。

【００４３】機能ＤＩＲ＿ＳＰＹとＤＩＲ＿ＳＴＯＰ＿
ＳＰＹはＤＩＲ＿ＮＥＷ機能と同様である。ＤＩＲ＿Ｓ
ＰＹ ＡＰＩコールに応答して、リクエストは、ディレ
クトリ・モジュールのリクエストキューにエンキューさ
れる。しかし、ディレクトリ・モジュールをロードし、
しかも、ディレクトリ・モジュールがロードされたとき
メッセージを送信する代わりに、この機能は、ディレク
トリモジュールがデータフロー（ディレクトリ・モジュ
ールはロードされていない）内で検出されたときにはい
つでもメッセージを送る。また、リクエストは、ＤＩＲ
＿ＳＴＯＰ＿ＳＰＹ ＡＰＩコールが行われるまで、リ
クエストキュー内に残ったままである。ＤＩＲ＿ＳＴＯ
Ｐ＿ＳＰＹ ＡＰＩコールがなされたとき、リクエスト
キュー内にディレクトリ・スパイ・リクエストを検索
し、そのエントリが除去される。これらの機能は、デー
タストリーム内の現在のディレクトリから何らかの変更
をスパイするのに有用である。最後に、現在のディレク
トリについての情報を抽出するためのＡＰＩコール、す
なわちＤＩＲ＿ＩＤＥＮＴＩＦＩＥＲと、ＤＩＲ＿ＲＥ
ＱＵＩＲＥＭＥＮＴと、ＤＩＲ＿ＮＢ＿ＭＯＤＵＬＥＳ
が存在する。

【００４４】モジュール内に埋め込みＣＲＣコードがあ
るので、モジュールをロードするためのメモリ割り振り
リクエストは、このコードを考慮しなければならない。
３つのＡＰＩコールがこれを処理するために与えられて
いる。機能ＭＯＤＵＬＥ＿ＡＬＬＯＣは、ＣＲＣまたは
メモリ要件を考慮して、引数としてモジュール識別子を
取り、そのモジュールをロードするための適当なメモリ
容量割り振りをリクエストする。機能ＭＯＤＵＬＥ＿Ｆ
ＲＥＥは、モジュールにより取られるメモリ領域を解放
する。機能ＭＯＤＵＬＥ＿ＣＨＥＣＫは、ロードされた
モジュールのＣＲＣチェックを行い、その結果を戻す。
これは、ＣＲＣがメモリ内にロードされたモジュール内
に埋め込まれているので、何時なされてもよい。

【００４５】ＡＰＩコールの他のセットは、モジュール
を取り扱い、現在選択されているディレクトリを用いて
それらを識別する。モジュールについての情報を抽出す
るためのＡＰＩコールがあり、それらは、ＭＯＤＵＬＥ
＿ＲＥＱＵＩＲＥＭＥＮＴとＭＯＤＵＬＥ＿ＳＩＺＥ
と、ＭＯＤＵＬＥ＿ＦＬＡＧである。これらにより、シ
ステムは、モジュールがロードおよび／または実行する
ことができるか否かを判定する。機能ＭＯＤＵＬＥ＿Ｒ
ＵＮは、先に述べたように実行可能なモジュールをロー
ドし、新しいプロセスを作成し、モジュールのエントリ
ポイントで実行を開始するために使用される。この機能
は、オーディオ・ビデオ対話型プログラムの実行を開始
するためのシステムローダにより使用される。機能ＭＯ
ＤＵＬＥ＿ＣＨＡＩＮは、後続の実行可能なモジュール
をロードし、現在のモジュールの実行を終了し、そのエ
ントリポイントで新たにロードされるモジュールの実行
を開始するために使用される。この場合には新しいプロ
セスは生成されるが、実行を開始しない。上述したよう
に、メッセージは、モジュールのロードが完了したと
き、リクエスト・プログラムに送られる。機能ＭＯＤＵ
ＬＥ＿ＥＸＥＣは、新たなプロセスを生成し、ＭＯＤＵ
ＬＥ＿ＬＯＡＤ ＡＰＩコールにより前にロードされて
いるモジュールの実行をエントリポイントで開始するた
めに使用される。

【００４６】機能ＭＯＤＵＬＥ＿ＬＩＮＫは、現在のプ
ロセスと、資源と、変数を用いて新しいモジュールを実
行する。それは、新しいモジュールへの動的なリンクを
与えることにより、モジュール内からのサブルーチンの
ようなコールを許可する。これにより、必要なときだけ
ダイナミックにリンクすることができる、より小さいモ
ジュールにオーディオ・ビデオ対話型プログラムを分割
することができる。ＭＯＤＵＬＥ＿ＬＩＮＫ機能は、リ
ロケーションとジャンプテーブルを保持する。ＭＯＤＵ
ＬＥ＿ＳＰＹとＭＯＤＵＬＥ＿ＳＴＯＰ＿ＳＰＹは、Ｄ
ＩＲＥＣＴＲＹ＿ＳＰＹとＤＩＲＥＣＴＲＹ＿ＳＴＯＰ
＿ＳＰＹと同様に作動する。ただし、識別されたモジュ
ールに対してである。ＭＯＤＵＬＥ＿ＳＰＹ ＡＰＩコ
ールは、モジュールの識別子を含むリクエストキュー内
にエントリを挿入する。同じ識別子を有するヘッダモジ
ュールがデータストリーム内に検出されたときにはいつ
でも、メッセージがリクエスト・プログラムに送られ
る。これは、ＭＯＤＵＬＥ＿ＳＴＯＰ ＳＰＹ ＡＰＩ
コールがなされるまで続く。ＭＯＤＵＬＥ＿ＳＴＯＰ＿
ＳＰＹ ＡＰＩコールに応答して、識別されたモジュー
ルに対するスパイリクエストを含むエントリが、リクエ
ストキューから除去される。ＭＯＤＵＬＥ＿ＳＴＯＰ＿
ＬＯＡＤ機能はプロセス内の現在のモジュールロードリ
クエストを停止し、リクエストキューからロードリクエ
ストエントリを除去する。機能ＦＬＯＷ＿ＭＥＳＳＡＧ
ＥとＦＬＯＷ＿ＳＴＯＰ＿ＭＥＳＳＡＧＥは、データス
トリームに関して、中断されたデータフローか、あるい
はデータフローの終了のような特別な連絡パケットが生
起したとき、メッセージシのリクエストを除去する。そ
のようなイベントが生起したとき、メッセージはリクエ
スト・プログラムに送られる。

【００４７】先に説明したように、システムローダは、
システムの初期化を実行し、アプリケーション・プログ
ラムの実行が受信されたオーディオコンポーネントとビ
デオコンポーネントとに同期することを確実にするため
にデータストリームを監視する。図５は、システムロー
ドの初期化機能を示すフロー図である。図５のブロック
５２で、（１７の）デコーダの種々のハードウェアとソ
フトウェアのコンポーネントが初期化される。また、Ｒ
ＡＭ４１２内のロケーションが、種々のデータ構造のた
めに割り振られ初期化される。これらの初期化機能は周
知であり、デコーダの他のソフトウェアコンポーネント
に依存する。システムプログラマは、どのハードウェア
とソフトウェアの初期化が必要か、どのデータ構造が必
要か、初期化をどのように行うかを理解するであろう。
従って、このブロックは以下では詳細に説明しない。

【００４８】ブロック５４にて、上述したＤＩＲ＿ＮＥ
Ｗ ＡＰＩコールが行われる。このＡＰＩコールは、オ
ーディオ・ビデオ対話型プログラム・コンポーネント・
パケットサービス内に現れる次のディレクトリ・モジュ
ールを、ＲＡＭ４１２内の割り振られたバッファ内にロ
ードする。このＡＰＩコールは、ディレクトリが後まで
ＲＡＭ４１２内にロードされないとしても直ちにシステ
ムローダに戻る。システムローダは、他の機能を実行
し、必要なら、ディレクトリ・モジュールがロードされ
たことを示すメッセージが、イベントマネジャにより、
受信されるまで、ＡＰＩコール（図示せず）を実行す
る。ブロック５６にて、（図１の）デコーダで使用可能
な資源はディレクトリモジュール内で必要な資源を示す
データと比較される。デコーダが、オーディオ・ビデオ
対話型プログラムを実行するだけの資源を有している場
合は、ＭＯＤＵＬＥ＿ＲＵＮ ＡＰＩコールが、上述し
たように、前にロードされているディレクトリモジュー
ル内で識別されるオートスタートコードモジュールをロ
ードするために行われる。再び、ＡＰＩコールは直ちに
リターンし、コードモジュールは、ある時間が経過する
まで、データストリームから完全にはロードされなくて
もよい。オートスタートコードモジュールが完全にロー
ドされた後、他のタスクが、インタプリタを介してオー
ディオ・ビデオ対話型プログラムを実行するためのマル
チタスクカーネルを用いて周知の方法で生成される。

【００４９】ブロック５８にて、システムローダは、実
行信号とディレクトリの変更のためのオーディオ・ビデ
オ対話型プログラムのコンポーネントを監視し始め、以
下に説明するオーディオ・ビデオ対話型プログラムへメ
ッセージを送ることにより、オーディオ・ビデオ対話型
プログラムの実行を制御する。図６は、システムローダ
の監視機能を示す状態遷移図であり、システムローダの
動作を理解するのに有用である。ディレクトリがオーデ
ィオ・ビデオ対話型プログラム・コンポーネント・パケ
ットサービス内で検出された場合は、視聴者が選択した
プログラムは対話型プログラムである。ディレクトリが
ＲＡＭ４１２内に一且ロードされ、オートスタートコー
ドモジュールがオーディオ・ビデオ対話型コンポーネン
トパケットサービスからリクエストされると、システム
ローダの制御により、オーディオ・ビデオ対話型プログ
ラムはＩＮＡＣＴＩＶＥ状態６１に入る。ＩＮＡＣＴＩ
ＶＥ状態６１では、アプリケーションを開始するための
全ての資源は割り振られており、アプリケーションは部
分的に、あるいは完全にロードされるが、視聴者との対
話はない。例えば、オートスタートモジュールがロード
されているとき、オーディオ・ビデオ対話型プログラム
はＩＮＡＣＴＩＶＥ状態６１のままである。その上、オ
ートスタートモジュールがロードされた後でさえ、視聴
者はオーディオ・ビデオ対話型プログラムを運ぶチャン
ネルを介してチャンネルを変更するだけであり、オーデ
ィオ・ビデオ対話型プログラムと対話する意図はない。
あるいは、視聴者は対話を決意する前に、オーディオ・
ビデオ対話型プログラムを観察したいかもしれない。ど
の場合にも、リモートコントロールが対話モードではな
く、通常のチャンネル変更モードで働くと言うことが重
要である。これがＩＮＡＣＴＩＶＥ状態６１の目的であ
る。見ているチャンネルが対話型プログラムを放送して
いることを視聴者に知らせるために、特別の対話型プロ
グラムロゴまたはアイコンがオーディオ・ビデオ対話型
ビデオ上に重ね合わされる。

【００５０】視聴者がオーディオ・ビデオ対話型プログ
ラムと実際に対話し始めるため、ＡＣＴＩＶＡＴＥ Ｋ
ＥＹと呼ばれる特別なキーがリモートコントロール上に
設けられている。対話型プログラムロゴまたはアイコン
が表示されているとき、視聴者はＡＣＴＩＶＡＴＥ Ｋ
ＥＹを押すことができる。ＡＣＴＩＶＡＴＥ ＫＥＹの
押下に応答して、システムローダはＡＣＴＩＶＡＴＥメ
ッセージをＡＣＴＩＶＡＴＥ状態６３に入るオーディオ
・ビデオ対話型プログラムに送る。ＡＣＴＩＶＥ状態６
３では、インタプリタはそのエントリポイントで、前に
ロードされたオーディオ・ビデオ対話型プログラムを実
際に実行し始める。オーディオ・ビデオ対話型プログラ
ムのオートスタートモジュールが実行を開始するとき、
それは、ＲＡＭ４１２内にそれ自身のデータ構造を割り
振り、初期化し、他のコードモジュールおよび／または
データモジュールをロードし、リモートコントロールと
フロントコントロールパネルの全てのユーザアクション
を制御する。

【００５１】オーディオ・ビデオ対話型プログラムは全
てのユーザ対話を制御するので、それはユーザがチャン
ネルを変更することを妨げるか、あるいは他の通常のリ
モートコントロール機能を実行することを妨げる。通常
のリモートコントロール機能に戻るには、視聴者は、先
ず現在のオーディオ・ビデオ対話型プログラムを停止し
なければならない。視聴者がＡＣＴＩＶＡＴＥ ＫＥＹ
を再び押下すると、プログラムは非アクティブにされ
る。このキーの押下に応答して、システムローダは、Ｄ
ＥＡＣＴＩＶＡＴＥメッセージを実行中のオーディオ・
ビデオ対話型プログラムに送り、そのプログラムは、Ａ
ＣＴＩＶＥ状態６３を離れ、ＩＮＡＣＴＩＶＥ状態６１
に戻る。再び、特別の対話型プログラムロゴまたはアイ
コンが表示され、オーディオ・ビデオ対話型プログラム
はロードされているが実行されていないということを示
す。視聴者は、その後、チャンネルを変更し、あるいは
他の通常のリモートコントロール機能を実行し、あるい
はＡＣＴＩＶＥ ＫＥＹを再び押下することによりオー
ディオ・ビデオ対話型プログラムを再びアクティブにし
てもよい。こうして、ＡＣＴＩＶＡＴＥ ＫＥＹは、そ
れが押されたとき、ＡＣＴＩＶＥ状態６３とＩＮＡＣＴ
ＩＶＥ状態６１との間で切り替わるトグルとして働く。
ＡＣＴＩＶＥとＤＥＡＣＴＩＶＡＴＥのメッセージはＡ
ＣＴＩＶＥ ＴＯ ＧＧＬＥメッセージとして考えても
よく、その意味（ＡＣＴＩＶＥあるいはＤＥＡＣＴＩＶ
Ｅ）はＡＣＴＩＶＡＴＥ ＫＥＹが押下されるとき、オ
ーディオ・ビデオ対話型プログラムの状態（それぞれＩ
ＮＡＣＴＩＶＥまたはＡＣＴＩＶＥ）に依存する。

【００５２】オーディオ・ビデオ対話型プログラムがＡ
ＣＴＩＶＥ状態６３にて実行されると、その実行を中断
したいときがある。例えば、非対話型コマーシャルが放
送されるべきとき、送信されたオーディオとビデオは
（図１の）デコーダ１０により生成される音やグラフィ
ックスとは一致せず、視聴者が、通常通り、リモートコ
ントロールを使用することができることが望ましい。し
かしながら、アプリケーションのプログラマはそのよう
な中断が必要となることを前もって知ることはできな
い。こうして、この場合、オーディオ・ビデオ対話型プ
ログラムとは独立な放送機器はオーディオ・ビデオ対話
型プログラム・コンポーネント・パケットサービス内に
中断信号パケットと呼ばれる（上記のような）特別の信
号パケットを繰り返し含めてもよい。このような各パケ
ットは現在実行中のオーディオ・ビデオ対話型プログラ
ムが実行を中断すべきであるということを示すデータを
含んでいる。

【００５３】ＦＬＯＷ＿ＭＥＳＳＡＧＥ ＡＰＩコール
を介して、システムローダは、そのようなパケットがオ
ーディオ・ビデオ対話型プログラム・コンポーネント・
パケットサービス内で認識されたときにはいつでもメッ
セージを受信する。例えば、中断信号パケットが受信さ
れたとき、システムローダは、中断信号メッセージを受
信し、最初の中断信号メッセージに応答してオーディオ
・ビデオ対話型プログラムにＳＵＳＰＥＮＤメッセージ
を送り、そのプログラムは、実行を中断してＳＵＳＰＥ
ＮＤＥＤ状態６５に入る。ＳＵＳＰＥＮＤＥＤ状態６５
では、オーディオ・ビデオ対話型プログラムの実行は、
それを、中断されたポイントから再び開始することがで
きるように停止する。すなわち、オーディオ・ビデオ対
話型プログラムを実行するために必要な資源の全てが割
り当てられたままであり、オーディオ・ビデオ対話型プ
ログラムの実行状態はＲＡＭ４１２内のあるロケーショ
ンに格納される。また、前に実行中の対話型プログラム
が中断されたが、許可されたとき回復の用意ができてい
ることを示す第２のロゴまたはアイコンが現在のビデオ
画像上に重ね合わされる。

【００５４】割り込み（例えば、非対話型コマーシャ
ル）が終わったとき、放送機器はオーディオ・ビデオ対
話型プログラム・コンポーネント・パケットサービス内
に中断信号パケットを含めることを止める。システムロ
ーダは、中断信号メッセージを受信することなく予め決
められた期間後、オーディオ・ビデオ対話型プログラム
にＣＯＮＴＩＮＵＥメッセージを送り、そのプログラム
は前に中断されたところから実行を再開して、上記のＡ
ＣＴＩＶＥ状態６３に入る。

【００５５】上述したＳＵＳＰＥＮＤ／ＣＯＮＴＩＮＵ
Ｅ信号構成の他の実施例は、放送機器がオーディオ・ビ
デオ対話型プログラムの実行を中断することを望むと
き、オーディオ・ビデオ対話型プログラム・コンポーネ
ント・パケットサービス内に単一の中断信号パケットを
含めることである。その後、放送機器は、オーディオ・
ビデオ対話型プログラムの実行を再開することが望まれ
るとき、オーディオ・ビデオ対話型プログラム・コンポ
ーネント・パケットサービス内に継続信号パケットと呼
ばれる他の特別な信号パケットを含める。このパケット
は現在中断されているオーディオ・ビデオ対話型プログ
ラムが実行を再開することを指令するデータを含む。シ
ステムローダは、継続信号パケットを認識し、オーディ
オ・ビデオ対話型プログラムにＣＯＮＴＩＮＵＥメッセ
ージを送り、そのプログラムは実行を再開し、上述した
ようにＡＣＴＩＶＥ状態６３に入る。

【００５６】視聴者が、中断されたオーディオ・ビデオ
対話型プログラムの実行を停止することも可能である。
プログラム中断ロゴまたはアイコンが表示されていると
き、視聴者が、ＤＥＡＣＴＩＶＡＴＥメッセージを、中
断されたオーディオ・ビデオ対話型プログラムに送り、
そのプログラムは上述したＩＮＡＣＴＩＶＥ状態６１に
入る。視聴者がＡＣＴＩＶＡＴＥ ＫＥＹを押したと
き、プログラムは、ＩＮＡＣＴＩＶＥ状態６１から実行
を再開するだけであり、システムローダにオーディオ・
ビデオ対話型プログラムに対してＡＣＴＩＶＡＴＥメッ
セージを送らせ、そのプログラムにＡＣＴＩＶＥ状態６
３に入らせる。システムローダが依然として中断信号パ
ケットを受信している場合は、別のＳＵＳＰＥＮＤメッ
セージが直ちにオーディオ・ビデオ対話型プログラムに
送られ、そのプログラムは再びＳＵＳＰＥＮＤＥＤ状態
６５に入る。ＩＮＡＣＴＩＶＥ状態６１と、ＡＣＴＩＶ
Ｅ状態６３と、ＳＵＳＰＥＮＤＥＤ状態６５は、オーデ
ィオ・ビデオ対話型プログラムがシステムローダから送
られるメッセージに応答して切り替わる状態である。し
かしながら、システムローダにより直接コントロールさ
れて入る２つの他の状態が存在する。

【００５７】オーディオ・ビデオ対話型プログラムはそ
の実行の終了に到達することができる。例えば、放送機
器は、実行終了信号パケットと呼ばれる他の特別な信号
パケットをオーディオ・ビデオ対話型プログラム・コン
ポーネント・パケットサービスに含めてもよい。システ
ムローダは、実行終了信号パケットがオーディオ・ビデ
オ対話型プログラム・コンポーネント・パケットサービ
ス内に認識された時、ＦＬＯＷ＿ＭＥＳＳＡＧＥ ＡＰ
Ｉコールを介して実行終了メッセージを受信する。実行
終了メッセージに応答して、システムローダは、ＥＸＩ
Ｔメッセージをオーディオ・ビデオ対話型プログラムに
送る。オーディオ・ビデオ対話型プログラムが、ＩＮＡ
ＣＴＩＶＥ状態６１か、ＡＣＴＩＶＥ状態６３か、ある
いはＳＵＳＰＥＮＤＥＤ状態６５のどの状態にあるかに
かかわらず、オーディオ・ビデオ対話型プログラムは、
その資源の割り振りを解除し、（図１の）デコーダ１０
からそれ自体の全てのレコードを除去することによりＥ
ＸＩＴメッセージに応答する。このプログラムはＨＡＬ
ＴＥＤ状態６９に入ったと思い、デコーダ１０から消え
る。プログラムそれ自身がユーザコマンドを介してある
いはそれ自身の実行により、その実行が終了に達したこ
とを認識することができる場合もある。オーディオ・ビ
デオ対話型プログラムがその実行の終了を認識したと
き、ＥＸＩＴメッセージが受信された場合に行われる同
じ処理を行い、それ自身によりＨＡＬＴＥＤ状態６９に
入る。

【００５８】オーディオ・ビデオ対話型プログラムがＳ
ＵＳＰＥＮＤＥＤ状態にあるとき、別の対話型オーディ
オ・ビデオ対話型プログラムを、オーディオ・ビデオ対
話型プログラム・コンポーネント・データフロー上で受
信することが可能である。例えば、オーディオ・ビデオ
対話型プログラムがコマーシャルにより中断されていれ
ば、そのコマーシャルはそれ自身対話型プログラムであ
ってもよいし、ユーザが別のオーディオ・ビデオ対話型
プログラムを放送するチャンネルにチャンネルを変更し
てもよい。これら両方の場合は、新しいオーディオ・ビ
デオ対話型プログラムはディレクトリ・モジュールを含
み、中断されたオーディオ・ビデオ対話型プログラムの
ディレクトリ・モジュールとは異なる。

【００５９】システムローダは、ＤＩＲ＿ＳＰＹ ＡＰ
Ｉコールを介して、ディレクトリがオーディオ・ビデオ
対話型プログラム・コンポーネント・パケットサービス
内に検出されるときにはいつでもメッセージを受信す
る。システムローダは、現在アクティブなディレクトリ
を検出されたばかりのディレクトリと比較する。システ
ムローダが、別のディレクトリがオーディオ・ビデオ対
話型プログラム・コンポーネント・パケットサービス内
に存在すると認識すると、それはそのディレクトリによ
り表わされるオーディオ・ビデオ対話型プログラムのロ
ードを始める。

【００６０】最初に、メッセージが現在中断されている
オーディオ・ビデオ対話型プログラムに送られ、プログ
ラム・コンポーネント・パケットサービスはそのプログ
ラムをもはや放送していないということ、あるいはプロ
グラムは“フローを失った”ということを示す。このメ
ッセージは現在実行しているプログラムがそれ自身を最
小にするリクエストであり、すなわちＭＩＮＩＭＩＺＥ
メッセージである。ＭＩＮＩＭＩＺＥメッセージに応答
して、現在中断しているオーディオ・ビデオ対話型プロ
グラムは、先ずその現在の実行状態と環境を、持続時間
とオーディオ・ビデオ対話型プログラムの識別子を含め
て、ＲＡＭ４１２内の小さいブロック内に格納する。こ
れらについては以下に説明する。それから、中断された
プログラムはその資源の割り振りを開始する。最小化さ
れたオーディオ・ビデオ対話型プログラムはどんなコー
ドも含まず、メッセージに応答して状態を変更すること
はできず、それ自身再スタートすることもできない。

【００６１】システムローダは新たに検出されたディレ
クトリとオートスタートモジュールをロードし、新しい
オーディオ・ビデオ対話型プログラムをＩＮＡＣＴＩＶ
Ｅ状態６１におき、先に説明したように対話型プログラ
ムロゴまたはアイコンを表示する。視聴者は、ＡＣＴＩ
ＶＡＴＥ ＫＥＹを押すことにより、この新しいオーデ
ィオ・ビデオ対話型プログラムとの対話を開始あるいは
停止することができ、そのプログラムをそれ自身中断し
てもよいし継続してもよい。

【００６２】最小化プロセスは繰り返しプロセスであ
る。例えば、この新しいオーディオ・ビデオ対話型プロ
グラムは、中断された場合、さらに他のオーディオ・ビ
デオ対話型プログラムがオーディオ・ビデオ対話型プロ
グラム・コンポーネント・パケットサービス内に検出さ
れた場合、最小化することができる。この場合、メモリ
の他のブロックが割り振られ、オーディオ・ビデオ対話
型プログラムの実行状態と環境が、その識別子と継続時
間と共に、このメモリブロックに格納される。その後先
に説明したように、新たに検出されたプログラムの実行
状態と環境を含む全てのメモリブロックを格納するのに
必要なメモリ量によってのみ制限される。

【００６３】新しいディレクトリ・モジュールをロード
するか、あるいは前にロードされているディレクトリ・
モジュールにより表わされるプログラムを実行するのに
十分な使用可能なメモリ空間がない場合であって、しか
も、最小化されたプログラムを表わす割り振られたメモ
リブロックがある場合には、システムローダは充分なメ
モリ空間を得るという意図で、（最も古いメモリブロッ
クの割り振りを最初に解除するか、あるいは、元のアプ
リケーションにより拡張可能とマークされたメモリブロ
ックの割り振りを最初に解除するというような）アルゴ
リズムにしたがって、メモリブロックの全て、あるいは
いくらかの割り振りを自動的に解除することができる。
あるいは、システムローダは、視聴者に最小化されたア
プリケーションのリストを提供し、削除すべきアプリケ
ーションを視聴者が選択することができるようにしても
よい。そして、選択された最小化アプリケーションを表
すブロックは、充分なメモリ空間を得るため割り振りが
解除される。

【００６４】一方、前に最小化されたオーディオ・ビデ
オ対話型プログラムの実行状態と環境を含むメモリブロ
ックは、メモリ内に割り振られたままである。上述した
ように、そのようなメモリブロック内には継続時間があ
る。あるブロック内の継続時間を超えたとき、前に最小
化されたオーディオ・ビデオ対話型プログラムはタイム
アウトする。この場合、そのプログラムはＨＡＬＴＥＤ
状態６９に入ったと考えられ、実行状態と環境を含むメ
モリブロックは割り振りが解除され、前に最小化された
オーディオ・ビデオ対話型プログラムの全ての記録は失
われる。

【００６５】しかしながら、（２３の）デコーダ１０
は、前に最小化されたオーディオ・ビデオ対話型プログ
ラムのディレクトリと、コードモジュールと、データモ
ジュールを含むオーディオ・ビデオ対話型プログラム・
コンポーネントを再び受信することができるか、あるい
はそのオーディオ・ビデオ対話型プログラムは“フロー
を再取得”することができる。例えば、対話型コマーシ
ャルが終了し、ＨＡＬＴＥＤ状態６９に入ってもよい
し、視聴者がこのチャンネルにチャンネルを戻してもよ
い。システムローダは、“新しい”ディレクトリをオー
ディオ・ビデオ対話型プログラム・コンポーネント・パ
ケットサービス内にロードし始める。新しいディレクト
リがロードされるといつでも、アプリケーション識別子
とＲＡＭ４１２内に現在格納されている実行状態と環境
を含む全てのブロック内の識別子とが比較される。一致
するブロックが見つかった場合は、コードモジュールと
データモジュールがロードされ、オーディオ・ビデオ対
話型プログラムはＩＮＡＣＴＩＶＥ状態６１におかれ
る。しかし、その実行状態は、それが最小化される直前
の実行状態に更新される。視聴者がＡＣＴＩＶＡＴＥ
ＫＥＹを押すと、オーディオ・ビデオ対話型プログラム
はＡＣＴＩＶＥ状態６３に入り、それが前に停止された
場所から実行を開始する。このようにして、他のオーデ
ィオ・ビデオ対話型プログラムをランするためオーディ
オ・ビデオ対話型プログラムを一時的に停止してもよ
く、それから両方のプログラムのために充分な資源を必
要とすることなくメモリ内に同時に残るように再開して
もよい。

【００６６】

【発明の効果】以上説明したように、本発明によれば、
パケットストリームを受信するオーディオ・ビデオ対話
型受信機において、オーディオ・ビデオ対話型プログラ
ムを効率的に実行する制御方法が得られる。

【図面の簡単な説明】

【図１】本発明に係るオーディオ・ビデオ対話型信号デ
コーダの一部を示すブロック図である。

【図２】図１に示す処理ユニット４０により実行される
ソフトウェアの構造を示す図である。

【図３】オーディオ・ビデオ対話型プログラムのデータ
コンポーネントからモジュールを抽出することを理解す
る際に有用なフロー図とメモリレイアウト図である。

【図４】オーディオ・ビデオ対話型プログラムのデータ
コンポーネントからモジュールを抽出することを理解す
る際に有用な部分的にブロック形式の、また部分的にメ
モリレイアウト形式の図である。

【図５】システムローダの初期化機能を示すフロー図で
ある。

【図６】システムローダのデータストリーム監視機能を
示す状態遷移図である。

【符号の説明】

１０ チューナ １５ オーディオ・ビデオ対話型ビデオ出力端子 ２５ オーディオ・ビデオ対話型オーディオ出力端子 ３０ プログラム・コンポーネント検出器 ３２ データパケットＤＭＡコントローラ ３４ ヘッダパケットＤＭＡコントローラ ４０ 処理ユニット ４５ ローカル処理装置 ５５ 外部コンピュータ ４０８ ストリームＩ／Ｏ ４１０ ＣＰＵ ４１２ ＲＡＭ ４１４ ＲＯＭ ４１８ オーディオ処理装置 ４２０ ビデオ処理装置 ４２２ Ｉ／Ｏポート ４２６ モデム

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｈ０４Ｎ 7/173 (72)発明者 ジーン−レネ メナンド アメリカ合衆国 カリフオルニア州 マリ ナ・デル・レイ パラワン・ウエイ 14001 (72)発明者 アラン デルパツク アメリカ合衆国 カリフオルニア州 ロス アンゼルスパーネル・アベニユー 2221

Claims (25)

【特許請求の範囲】
1. 【請求項１】 複数のモジュールを含むパケットサービ
   スを受信するオーディオ・ビデオ対話型受信機であっ
   て、各モジュールは名前を有し、時間多重化伝送ユニッ
   トを含み、各伝送ユニットはモジュールの名前を含むヘ
   ッダパケットを含むオーディオ・ビデオ対話型受信機に
   おけるモジュールを処理する方法において、名前により
   識別されたモジュールに関するプロセスを実行するリク
   エストを受信し、受信された名前とリクエストされたプ
   ロセスを含むエントリをエントリリストに挿入するステ
   ップと、 前記パケットサービス内でヘッダパケットを検出するス
   テップと、 検出されたヘッダパケット内の名前が前記リスト内のあ
   るエントリの名前と一致するかどうかを判定するステッ
   プと、 一致するエントリが存在する場合は、一致するエントリ
   内のプロセスを実行するステップと、 前記プロセスが実行されたことを示すメッセージを送信
   するステップとを具備したことを特徴とするモジュール
   を処理する方法。
2. 【請求項２】 請求項１において、前記受信するステッ
   プは、完全なモジュールを処理するためのリクエストを
   受信するステップを含み、 前記送信するステップは、前記完全なモジュールが処理
   されるとき前記リストから前記一致するエントリを除去
   するステップを含むことを特徴とする方法。
3. 【請求項３】 請求項１において、名前により識別され
   るモジュールのプロセスを実行するためのリクエストを
   受信するステップと、 前記受信された名前とリクエストされたプロセスを含む
   エントリを前記エントリリストから除去することを停止
   するステップとをさらに備えたことを特徴とする方法。
4. 【請求項４】 請求項１において、各伝送ユニットは各
   ヘッダパケットと関連する複数のデータパケットを具備
   し、 前記受信するステップは、前記モジュールをメモリにロ
   ードすることにより前記モジュールを実行するためのリ
   クエストを受信するステップと、前記モジュールを含む
   ように前記メモリ内のバッファを割り振るステップとを
   具備し、 前記実行するステップは、前記割り振られたバッファ内
   の各ロケーションに前記検出されたヘッダパケットと関
   連する各データパケットを貯えるステップと、前記モジ
   ュール内の各伝送ユニット内の各データパケットが前記
   割り振られたバッファ内に格納されたとき、前記リスト
   内の一致するエントリを除去するステップとを具備した
   ことを特徴とする方法。
5. 【請求項５】 請求項４において、伝送ユニット内の各
   ヘッダパケットと関連する前記複数のデータパケット
   は、前記モジュールの開始から個々のオフセット位置に
   位置する前記モジュール内のデータを含み、 前記ヘッダパケットは前記関連する複数のデータパケッ
   ト内に前記データのオフセット位置をさらに含み、 前記格納するステップは、前記割り振られたバッファの
   オフセット位置であって、前記ヘッダパケット内の前記
   オフセット位置に等しいオフセット位置に、前記関連す
   る複数のデータパケットを格納するステップを具備した
   ことを特徴とする方法。
6. 【請求項６】 請求項５において、前記パケットサービ
   スは、前記モジュールの前記開始から、順次オフセット
   位置におかれたモジュールデータを含む連続的な時間多
   重された伝送ユニットにより運ばれるモジュールを、連
   続的かつ繰り返し供給し、 前記検出するステップは、前記検出されたヘッダパケッ
   トのオフセット位置を指す書き込みポインタを設定する
   ステップをさらに具備し、 前記実行するステップは、モジュールをロードするリク
   エストが開始ロード位置として受信された後、最初に検
   出されたヘッダパケット内に前記オフセット位置を格納
   するステップをさらに具備し、 前記格納するステップは、 前記書き込みポインタにより指された位置の検出された
   ヘッダパケットと関連する各データパケットを格納する
   ステップと、 そして、前記データパケットが格納された後、前記割り
   振られたバッファ内の次の順次位置を指す前記書き込み
   ポインタを更新するステップと、 その後、前記書き込みポインタと前記格納された開始ロ
   ード位置とを比較し、それらが等しいとき、前記除去す
   るステップを実行するステップとを具備したことを特徴
   とする方法。
7. 【請求項７】 請求項６において、前記検出するステッ
   プは、前記設定するステップの前に、 前記書き込みポインタと、前記検出されたヘッダパケッ
   ト内の前記オフセット位置とを比較するステップと、 それらが等しくないとき、前記検出されたヘッダパケッ
   ト内の前記オフセット位置と前記開始ロード位置を交換
   するステップとをさらに具備したことを特徴とする方
   法。
8. 【請求項８】 請求項４において、各モジュールは埋め
   込みエラー検出コードをさらに含み、 前記格納するステップは、前記埋め込みエラー検出コー
   ドを前記割り振られたバッファ内に格納し、 前記送信するステップは、 前記埋め込みエラー検出コードを用いてエラーを検出す
   るため、前記割り振られたバッファ内の前記データをチ
   ェックするステップと、 前記チェックするステップでエラーが検出された場合、
   エラーメッセージを送信するステップと、 エラーが検出されない場合は、モジュールにロードされ
   たメッセージを送信するステップとをさらに具備したこ
   とを特徴とする方法。
9. 【請求項９】 請求項８において、前記埋め込みエラー
   検出コードは埋め込みＣＲＣコードであり、 前記チェックするステップは、前記割り振られたバッフ
   ァ内の前記データに対するＣＲＣ値を計算し、計算され
   たＣＲＣ値と前記埋め込みＣＲＣコードとを比較し、そ
   れらが異なる場合、エラーを検出することを特徴とする
   方法。
10. 【請求項１０】 請求項４において、各伝送ユニットは
    複数のデータパケットを具備し、 前記受信するステップは、 前記検出されたヘッダパケットと関連する各データパケ
    ットを格納するステップと、 格納された伝送ユニットと関連する各データパケットに
    エラーがないか否かを判定するステップと、 前記伝送ユニットのデータパケットにエラーがある場合
    は、伝送ユニット全体を破棄するステップとを具備した
    ことを特徴とする方法。
11. 【請求項１１】 請求項１において、前記受信するステ
    ップは、前記パケットサービス内のモジュールをスパイ
    するリクエストを受信するステップを具え、 前記実行するステップは、一致するエントリがあるとき
    にはいつでもメッセージを送信するステップを具備した
    ことを特徴とする方法。
12. 【請求項１２】 複数のモジュールを含むパケットデー
    タのソースであり、各モジュールは名前を持ち、時間多
    重化伝送ユニットを含み、各伝送ユニットはモジュール
    の名前を含むヘッダパケットを含み、複数のモジュール
    を含むパケットデータストリームのソースと、 複数のエントリを含むリクエストキューを格納するため
    のメモリであって、前記複数のエントリが処理リクエス
    トとモジュールの名前を含むメモリと、モジュール名前
    を含むロケーションを含むヘッダパケットバッファと、 前記メモリに接続されたリクエスト処理回路であって、
    名前で識別されるモジュールに対する処理を実行するリ
    クエストを受信し、前記識別されたモジュールの名前
    と、前記リクエストされた処理とを含む前記リクエスト
    キューにエントリを格納するリクエスト処理回路と、 前記データストリームソースと前記メモリの間に接続さ
    れたヘッダパケットメモリ格納コントローラであって、
    ヘッダパケットが前記データストリームに現れたとき、
    前記ヘッダパケットを前記ヘッダパケットバッファに格
    納し、ヘッダパケット受信信号を生成するヘッダパケッ
    トメモリ格納コントローラと、 前記ヘッダパケット受信信号に応答するモジュール処理
    回路であって、前記ヘッダパケットバッファから前記モ
    ジュール名を読み出し、前記リクエストバッファ内の各
    エントリ内の名前と前記モジュール名を比較し、前記モ
    ジュール名前がエントリ名前と一致した場合、前記一致
    リクエストキューエントリ内のリクエストされた処理を
    行い、その後メッセージを送信するモジュール処理回路
    とを具備したことを特徴とするオーディオ対話型受信
    機。
13. 【請求項１３】 請求項１２において、前記モジュール
    処理回路はプロセッサを備え、前記ヘッダパケット受信
    信号は前記プロセッサに対する割り込み信号であること
    を特徴とする受信機。
14. 【請求項１４】 請求項１２において、前記ヘッダパケ
    ットメモリ格納コントローラはダイレクト・メモリ・ア
    クセス・コントローラであることを特徴とする受信機。
15. 【請求項１５】 請求項１２において、前記リクエスト
    処理回路は完全なモジュールを処理するためのリクエス
    トを受信し、 前記モジュール処理回路は前記完全なモジュールのリク
    エストされた処理を行った後、前記リクエストキューエ
    ントリを除去することを特徴とする受信機。
16. 【請求項１６】 請求項１５において、前記メモリバッ
    ファはモジュールバッファをさらに格納し、 前記データストリームソースは、伝送ユニット内に含ま
    れた前記ヘッダパケットと関連する複数のデータパケッ
    トをそれぞれ含む前記伝送ユニットを生成し、 前記受信機は前記データストリームソースと前記メモリ
    の間に接続され、データパケットが前記データストリー
    ムに現れたとき、伝送ユニットからの前記複数のデータ
    パケットを選択的にモジュールバッファに格納し、その
    後イネーブル信号に応答してデータ完了信号を生成する
    モジュールメモリ格納コントローラをさらに備え、 前記リクエスト処理回路は名前により識別された完全な
    モジュールをロードするための処理リクエストを受信
    し、前記識別された名前と前記ロードリクエストとを含
    む前記リクエストキュー内にエントリを格納し、 前記モジュール処理回路は前記モジュール名前とエント
    リ名前が一致した場合に、前記イネーブル信号を生成
    し、前記完全モジュールを前記モジュールバッファにロ
    ードした後、前記データ完了信号に応答して、前記リク
    エストキューエントリを除去することを特徴とする受信
    機。
17. 【請求項１７】 請求項１６において、前記データスト
    リームソースは、埋め込みエラー検出コードを含む各モ
    ジュールを生成し、 前記モジュール処理回路は、前記完全なモジュールが前
    記モジュールバッファ内にロードされた後、前記埋め込
    みエラー検出コードを用いて、前記モジュールバッファ
    内の前記データをエラーチェックし、エラーが検出され
    た場合は、エラーメッセージを送信し、そうでない場合
    は、モジュールロードメッセージを送信することを特徴
    とする受信機。
18. 【請求項１８】 請求項１７において、前記埋め込みエ
    ラー検出コードはＣＲＣコードであり、前記モジュール
    処理回路は、前記モジュールバッファ内の前記データに
    対するＣＲＣ値を計算し、計算されたＣＲＣ値と前記埋
    め込みＣＲＣコードとを比較し、それらが異なる場合は
    エラーを検出することを特徴とする受信機。
19. 【請求項１９】 請求項１６において、前記データスト
    リームソースは、前記モジュールの開始から順次オフセ
    ット位置に位置するモジュールデータを含む連続的な伝
    送ユニットを生成し、前記関連するデータパケットの前
    記データの前記オフセット位置をさらに含む前記ヘッダ
    パケットを生成し、 前記メモリの前記ヘッダパケットバッファは、前記オフ
    セット位置を含む位置をさらに含み、 前記モジュール処理回路は、前記ヘッダパケットバッフ
    ァから前記オフセット位置を抽出し、そのオフセット位
    置を前記モジュールメモリ格納コントローラに供給し、 前記モジュールメモリ格納コントローラは、前記モジュ
    ール処理回路からの前記オフセット位置で書き込みポイ
    ンタを初期化し、該書き込みポインタにより指された位
    置にデータパケットをそれぞれロードし、その後、伝送
    ユニットの全てのデータパケットがロードされるまで、
    前記モジュールバッファ内の次の順次位置を指すように
    前記書き込みポインタを更新し、その後、前記データ完
    了信号を生成することを特徴とする受信機。
20. 【請求項２０】 請求項１９において、前記データスト
    リームソースは、モジュールを連続的かつ繰り返し生成
    し、 前記メモリは開始ロードアドレス位置をさらに含み、 前記モジュール処理回路は、最初の一致を引き起こす前
    記ヘッダパケットがロードされた後、前記ヘッダパケッ
    トバッファから前記オフセット位置を抽出し、前記開始
    ロードアドレス位置に前記オフセット位置を格納し、前
    記モジュールメモリ格納コントローラからの前記データ
    完了信号に応答して、前記モジュールメモリ格納コント
    ローラからの前記書き込みポインタを前記開始ロードア
    ドレス位置と比較し、それらが等しいとき前記メッセー
    ジを送信することを特徴とする受信機。
21. 【請求項２１】 請求項２０において、前記モジュール
    処理回路は、前記ヘッダパケット受信信号に応答して、
    前記書き込みポインタと前記オフセット位置を比較し、
    それらが等しくないとき、前記オフセット位置で前記開
    始ロードアドレス位置を交換することを特徴とする受信
    機。
22. 【請求項２２】 請求項１６において、前記モジュール
    処理回路は、プロセッサを備え、前記データ完了信号は
    前記プロセッサへの割り込み信号であることを特徴とす
    る受信機。
23. 【請求項２３】 請求項１６において、前記モジュール
    メモリ格納コントローラはダイレクト・メモリ・アクセ
    ス・コントローラであることを特徴とする受信機。
24. 【請求項２４】 請求項１２において、前記リクエスト
    処理回路は、名前により識別されたモジュールの処理を
    停止するためのリクエストを受信し、前記識別されたモ
    ジュールの名前と、停止するようリクエストされた前記
    処理とを含む前記リクエストキュー内の前記エントリを
    除去することを特徴とする受信機。
25. 【請求項２５】 請求項１２において、前記ヘッダパケ
    ットメモリ格納コントローラは、イネーブル信号に応答
    してヘッダパケットを選択的に格納し、 前記リクエスト処理回路は、エントリが前記リクエスト
    キュー内に格納された後、前記イネーブル信号を生成
    し、 前記モジュール処理回路は、前記リクエストキュー内に
    エントリがない場合、前記処理がなされた後、前記イネ
    ーブル信号をさらに除去することを特徴とする受信機。