JPH0851596A - オーディオ・ビデオ対話型プログラムの実行を制御する方法 - Google Patents

Abstract

(57)【要約】 【目的】 オーディオ・ビデオ対話型受信機において、
効率的にオーディオ・ビデオ対話型プログラムを実行す
る制御方法を提供する。 【構成】 ディレクトリと、関連する識別子をディレク
トリ中に有するオーディオ・ビデオ対話型プログラムと
を含むパケットストリームを受信するオーディオ・ビデ
オ対話型受信機において、最初に、パケットストリーム
内のオーディオ・ビデオ対話型プログラムの存在に応答
して、メモリにオーディオ・ビデオ対話型プログラムを
ロードし、次いで、ロードされたオーディオ・ビデオ対
話型プログラムの実行を開始し、それから、別のオーデ
ィオ・ビデオ対話型プログラムを識別するディレクトリ
がパケットストリーム中に検出されたとき、実行中のオ
ーディオ・ビデオ対話型プログラムを最小化する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、オーディオビデオ対話
型（ａｕｄｉｏ ｖｉｄｅｏ ｉｎｔｅｒａｃｔｉｖ
ｅ）実行可能なプログラム・コンポーネントの実行を制
御する方法に関する。

【０００２】

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

【０００３】提案されているオーディオ・ビデオ対話型
システムでは、放送機器からのオーディオ・ビデオ対話
型信号はパケットデータ・ストリームの形式で放送さ
れ、複数の時間多重されたパケットサービスを含む。各
パケットサービスは複合オーディオ・ビデオ対話型信号
の異なる信号コンポーネントを有する。例えば、あるサ
ービスはビデオコンポーネントを有し、あるサービスは
オーディオコンポーネントを有し、あるサービスは対話
型アプリケーション・プログラム情報を有する。また、
あるサービスはステレオとＳＡＰオーディオチャンネ
ル、および／またはクローズド・キャプション情報等を
有する。さらに、パケットデータ・ストリームの中に
は、２つ以上のオーディオ・ビデオ対話型プログラムに
対するコンポーネントを有するパケットサービスを含む
ことができるものもある。各パケットサービスは、パケ
ットサービスに関連するる一意のサービスコンポーネン
ト識別子（ＳＣＩＤ）を有し、そのパケットサービス内
のパケットは、それぞれ、そのサービス識別子を含む。

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

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

【０００６】対話型アプリケーション・プログラム情報
コンポーネントは、１つまたはそれ以上の（実行可能な
コードを含む）コードモジュールと、恐らくは、１つま
たはそれ以上のデータモジュールと、ディレクトリモジ
ュールとによりなる。このディレクトリモジュールは対
話型アプリケーション・プログラムのコンポーネントを
構成するコードモジュールとデータモジュールを記述す
るデータを含む。これらのモジュールは、アプリケーシ
ョン・プログラム・データ・コンポーネントのフロー内
で連続して繰り返される。既に述べたが、モジュールは
それぞれ個別に識別され、伝送ユニットにより運ばれ
る。伝送ユニット内のヘッダパケットは、後続のデータ
パケット内のデータが属するモジュール内のモジュール
の識別子とロケーションを含む。対話型アプリケーショ
ン・プログラム情報コンポーネントは、オーディオ・ビ
デオ対話型のアプリケーション・プログラムの実行を制
御するための特別な信号も含む。例えば、ある信号は、
現在実行中のオーディオ・ビデオ対話型のアプリケーシ
ョン・プログラムに対して実行を中断するように命令す
る。また、別の信号は、現在中断されているオーディオ
・ビデオ対話型のアプリケーション・プログラムについ
て実行を再開するように命令する。さらに、他の信号
は、現在実行中のオーディオ・ビデオ対話型のアプリケ
ーション・プログラムに対して実行を停止するように命
令する。これらの信号は、オーディオ・ビデオ対話型プ
ログラム・コンポーネント・パケットサービス内の信号
パケットに組み込まれる。

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

【０００８】他のディストリビューティッドのコンピュ
ータシステムとは異なり、オーディオ・ビデオ対話型受
信機により受信されているオーディオ・ビデオ対話型プ
ログラム・コンポーネントは何時でも変わることがあ
る。例えば、オーディオ・ビデオ対話型プログラムは、
非オーディオ・ビデオ対話型コマーシャルまたはオーデ
ィオ・ビデオ対話型コマーシャルにより割り込まれるこ
とがある。もちろん、このオーディオ・ビデオ対話型コ
マーシャルは別個のオーディオ・ビデオ対話型プログラ
ムを含んでいる。あるいは、視聴者は或るオーディオ・
ビデオ対話型プログラムから別のオーディオ・ビデオ対
話型プログラムへチャンネルを変えることがある。オー
ディオ・ビデオ対話型型実行可能なコードと、そのコー
ドにより発生されている音声およびグラフィックス、受
信されているオーディオコンポーネントおよびビデオコ
ンポーネントとの間の適正な同期を保持することが必要
である。

【０００９】

【発明の概要】本発明の原理によると、ディレクトリと
ディレクトリ中に関連する識別子を有するオーディオ・
ビデオ対話型プログラムを含んでいるパケットストリー
ムを受信するオーディオ・ビデオ対話型受信機におい
て、オーディオ・ビデオ対話型プログラムの実行を制御
する方法であって、該方法は次のステップを含んでい
る。最初に、パケットストリーム中にオーディオ・ビデ
オ対話型プログラムの存在に応答して、オーディオ・ビ
デオ対話型プログラムをメモリにロードするステップを
含む。次に、ロードされたオーディオ・ビデオ対話型プ
ログラムの実行を開始するステップ、それから、異なる
オーディオ・ビデオ対話型プログラムを識別するディレ
クトリがパケットストリーム中に検出されるとき、実行
中のオーディオ・ビデオ対話型プログラムを最小化する
ステップを含む。

【００１０】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００６４】

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

【図面の簡単な説明】

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

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

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

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

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

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

【符号の説明】

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

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジーン−レネ メナンド アメリカ合衆国 カリフオルニア州 マリ ナ・デル・レイ パラワン・ウエイ 14001 (72)発明者 アラン デルパツク アメリカ合衆国 カリフオルニア州 ロス アンゼルスパーネル・アベニユー 2221

Claims (18)

【特許請求の範囲】
1. 【請求項１】 ディレクトリとディレクトリ中に関連す
   る識別子を有するオーディオ・ビデオ対話型プログラム
   とを含むパケットストリームを受け取るオーディオ・ビ
   デオ対話型受信機において、オーディオ・ビデオ対話型
   プログラムの実行を制御する方法であって、 パケットストリーム中のオーディオ・ビデオ対話型プロ
   グラムの存在に応答して、メモリにオーディオ・ビデオ
   対話型プログラムをロードするステップと、 ロードされたオーディオ・ビデオ対話型プログラムの実
   行を開始するステップと、 異なるオーディオ・ビデオ対話型プログラムを識別する
   ディレクトリがパケットストリーム中に検出されると
   き、実行中のオーディオ・ビデオ対話型プログラムを最
   小化するステップとを含む、前記方法。
2. 【請求項２】 実行中のオーディオ・ビデオ対話型プロ
   グラムを最小化するステップが、 オーディオ・ビデオ対話型プログラムの実行を停止する
   ステップと、 オーディオ・ビデオ対話型プログラムの識別子と、オー
   ディオ・ビデオ対話型プログラムの実行状態および環境
   とをメモリのブロックに貯えるステップと、 メモリからオーディオ・ビデオ対話型プログラムをアン
   ロードするステップとを含む、請求項１記載の方法。
3. 【請求項３】 オーディオ・ビデオ対話型プログラムを
   ロードするステップが、 オーディオ・ビデオ対話型プログラムの識別子に一致す
   る識別子を含んでいるブロックについて予め貯えられた
   メモリ・ブロックをサーチするステップと、 一致するメモリ・ブロックが存在すると、ロードされた
   オーディオ・ビデオ対話型プログラムの実行状態と環境
   をメモリの一致するブロックのものにセットするステッ
   プとを含む、請求項２記載の方法。
4. 【請求項４】 パケットストリームが更に実行信号を含
   んでおり、かつパケットストリーム中の終り実行信号に
   応答してメモリからオーディオ・ビデオ対話型プログラ
   ムをアンロードするステップを含んでいる、請求項１記
   載の方法。
5. 【請求項５】 パケットストリームが更に実行信号を含
   んでおり、更に、 パケットストリーム中の中断実行信号に応答して、オー
   ディオ・ビデオ対話型プログラムの実行を中断するステ
   ップと、 パケットストリーム中の継続実行信号に応答して、予め
   中断されたオーディオ・ビデオ対話型プログラムの実行
   を継続するステップとを含んでいる、請求項１記載の方
   法。
6. 【請求項６】 パケットストリーム中の終了実行信号に
   応答して、実行を中止し、かつメモリからオーディオ・
   ビデオ対話型プログラムをアンロードするステップを更
   に含んでいる、請求項５記載の方法。
7. 【請求項７】 オーディオ・ビデオ対話型プログラムと
   実行信号を含んでいるオーディオ・ビデオ対話型受信機
   において、オーディオ・ビデオ対話型プログラムの実行
   を制御する方法であって、 パケットストリーム中のオーディオ・ビデオ対話型プロ
   グラムの存在に応答して、メモリにオーディオ・ビデオ
   対話型プログラムをロードするステップと、 ロードされたプログラムの実行を開始するステップと、 パケットストリーム中の終了実行信号に応答して、実行
   を停止し且つメモリからオーディオ・ビデオ対話型プロ
   グラムをアンロードするステップとを含んでいる、前記
   方法。
8. 【請求項８】 パケットストリーム中の終了実行信号が
   終了実行信号パケットにより表される、請求項７記載の
   方法。
9. 【請求項９】 パケットストリーム中の中断実行信号に
   応答して、オーディオ・ビデオ対話型プログラムの実行
   を中断するステップと、 パケットストリーム中の継続実行信号に応答して、予め
   中断されたオーディオ・ビデオ対話型プログラムの実行
   を継続するステップとを更に含んでいる、請求項７記載
   の方法。
10. 【請求項１０】 パケットストリーム中の中断実行信号
    が、中断時間期間の間、反復性の中断実行信号パケット
    により表わされ、かつ継続実行信号が非反復性の中断実
    行信号パケットにより表わされる、請求項９記載の方
    法。
11. 【請求項１１】 パケットストリーム中の中断実行信号
    が中断実行信号パケットにより表わされ、かつ継続実行
    信号が継続実行信号パケットにより表わされる、請求項
    ９記載の方法。
12. 【請求項１２】 オーディオ・ビデオ対話型プログラム
    と実行信号を含み、且つオーディオ・ビデオ対話型プロ
    グラムの実行を制御する実行コントローラを含んでいる
    パケットストリームを受け取るオーディオ・ビデオ対話
    型受信機において、オーディオ・ビデオ対話型プログラ
    ムの実行を制御する方法であって、 実行コントローラにおいて、 パケットストリーム中のオーディオ・ビデオ対話型プロ
    グラムの存在に応答して、メモリにオーディオ・ビデオ
    対話型プログラムをロードするステップと、 ユーザの入力に応答して、アクティベイト・トグル・メ
    ッセージをオーディオ・ビデオ対話型プログラムに送る
    ステップと、 パケットストリーム中の終了実行信号に応答して、出口
    メッセージをオーディオ・ビデオ対話型プログラムに送
    るステップと、 パケットストリーム中に中断実行信号に応答して、オー
    ディオ・ビデオ対話型プログラムに中断メッセージを送
    るステップと、 パケットストリーム中の継続実行信号に応答して、オー
    ディオ・ビデオ対話型プログラムに継続メッセージを送
    るステップと、 オーディオ・ビデオ対話型プログラムにおいて、 オーディオ・ビデオ対話型プログラムが非作動である非
    作動状態；オーディオ・ビデオ対話型プログラムが実行
    中である作動状態；オーディオ・ビデオ対話型プログラ
    ムの実行が中断されている中断状態；の中の１つにおい
    て実行するステップと、 メモリにオーディオ・ビデオ対話型プログラムをロード
    するのに応答して、非作動状態に入るステップと、 出口メッセージに応答して、実行を中止し、メモリから
    オーディオ・ビデオ対話型プログラムをアンロードする
    ステップと、 非作動状態にあるとき、能動トグル・メッセージに応答
    して、作動状態に入るステップと、 作動状態にあるとき、能動トグル・メッセージに応答し
    て、非作動状態に入るステップと、 中断メッセージに応答して、中断状態に入るステップ
    と、 継続メッセージに応答して、作動状態に入るステップ
    と、 能動トグル・メッセージに応答して、非作動状態に入る
    ステップとを含んでいる、前記方法。
13. 【請求項１３】 パケットストリーム中の中断実行信号
    が、中断時間の間、反復性の中断実行信号パケットによ
    り表わされ、かつ継続実行信号が非反復性中断実行信号
    パケットにより表わされ、 実行コントローラにおいて中断メッセージを送るステッ
    プが第１の中断実行信号パケットに応答して中断メッセ
    ージを送るステップを含み、 実行コントロールにおいて継続メッセージを送るステッ
    プが、中断実行信号パケットが受け取られてない所定時
    間期間の後、継続メッセージを送るステップを含む、請
    求項１２記載の方法。
14. 【請求項１４】 パケットストリーム中の中断実行信号
    が中断実行信号パケットにより表わされ、かつ継続実行
    信号が継続実行信号パケットにより表され、 実行コントローラにおいて中断メッセージを送るステッ
    プが、中断実行信号パケットに応答して中断メッセージ
    を送るステップと、 実行コントローラにおいて継続メッセージを送るステッ
    プが、継続実行信号パケットに応答して継続メッセージ
    を送るステップとを含む、請求項１２記載の方法。
15. 【請求項１５】 ユーザの制御の下に、複数のパケット
    ストリームの中の１つを選択的に受け取るオーディオ・
    ビデオ対話型受信機において、各パケットストリーム
    は、識別子と実行信号を有するオーディオ・ビデオ対話
    型プログラムを含んでおり、前記受信機はオーディオ・
    ビデオ対話型プログラムの実行を制御する実行コントロ
    ーラを含んでおり、オーディオ・ビデオ対話型プログラ
    ムの実行を制御する方法が、 実行コントローラにおいて、 複数のパケットストリームの選択された１つにおいてオ
    ーディオ・ビデオ対話型プログラムの存在に応答して、
    メモリにオーディオ・ビデオ対話型プログラムをロード
    し、メモリの各ロケーションにロードされたアプリケー
    ション・プログラムの識別子を貯え、最小化されたオー
    ディオ・ビデオ対話型プログラムの識別子を含んでいる
    メモリに予め貯えられたブロックをサーチし、ブロック
    に含まれている識別子がメモリにロードされたオーディ
    オ・ビデオ対話型プログラムの識別子に一致すると、新
    しくロードされたオーディオ・ビデオ対話型プログラム
    の実行状態と環境を一致するブロックに含まれている実
    行状態と環境にセットするステップと、 ユーザ入力に応答してオーディオ・ビデオ対話型プログ
    ラムに能動トグル・メッセージを送るステップと、 複数のパケットストリームの選択された１つにおける終
    了実行信号に応答し、オーディオ・ビデオ対話型プログ
    ラムに出口メッセージを送るステップと、 複数のパケットストリームの選択された１つにおける中
    断実行信号に応答してオーディオ・ビデオ対話型プログ
    ラムに中断メッセージを送るステップと、 複数のパケットストリームの中の選択された１つにおけ
    る継続実行信号に応答し、オーディオ・ビデオ対話型プ
    ログラムに継続メッセージを送るステップと、 メモリの各ロケーション中の識別子とは異なる識別子を
    有するデータストリームにおけるオーディオ・ビデオ対
    話型プログラムの存在に応答して、オーディオ・ビデオ
    対話型プログラムに最小化メッセージを送るステップ
    と、 オーディオ・ビデオ対話型プログラムにおいて、 オーディオ・ビデオ対話型プログラムが非作動である非
    作動状態；オーディオ・ビデオ対話型プログラムが実行
    中である能動状態；オーディオ・ビデオ対話型プログラ
    ムの実行が中断している中断状態；オーディオ・ビデオ
    対話型プログラムの実行を中止し；次いで、オーディオ
    ・ビデオ対話型プログラムの識別子と、オーディオ・ビ
    デオ対話型プログラムの実行状態および環境とをメモリ
    のブロックに貯え、それからメモリからオーディオ・ビ
    デオ対話型プログラムをアンロードするステップを含む
    最小化状態；の中の１つにおいて実行するステップと、 メモリにオーディオ・ビデオ対話型プログラムをロード
    するのに応答して、非作動状態に入るステップと、 出力メッセージに応答して、実行を中止し、メモリから
    オーディオ・ビデオ対話型プログラムをアンロードする
    ステップと、 非作動状態のとき、能動トグル・メッセージに応答し
    て、能動状態に入るステップと、 能動状態にあるとき、 能動トグル・メッセージに応答して、非作動状態に入る
    ステップと、 中断メッセージに応答して、中断状態に入るステップ
    と、 中断状態にあるとき、 継続メッセージに応答して能動状態に入るステップと、
    作動トグル・メッセージに応答して非作動状態に入る
    ステップと、 最小化メッセージに応答して最小化状態に入るステップ
    とを含んでいる、前記方法。
16. 【請求項１６】 アプリケーション・プログラムにおい
    て最小化状態で実行するステップにおける貯えるステッ
    プが、 メモリのブロックに貯えられたデータがメモリに留まる
    時間の期間を示す時間期間をメモリのブロックに貯え、
    該時間期間が経過したのち、メモリのブロックに貯えら
    れたデータを取り除くステップを更に含んでいる、請求
    項１５記載の方法。
17. 【請求項１７】 複数のパケットストリーム中の選択さ
    れた１つにおける中断実行信号が、中断時間期間の間、
    反復性の中断実行信号パケットにより表わされ、かつ継
    続実行信号が非反復性の中断実行信号パケットにより表
    わされ、 実行コンローラにおいて中断メッセージを送るステップ
    が、第１の中断実行信号パケットに応答して中断メッセ
    ージを送るステップを含み、 実行コントローラにおいて継続メッセージを送るステッ
    プが、中断実行信号パケットが受け取られない所定の時
    間期間の後、継続メッセージを送るステップを含む、請
    求項１５記載の方法。
18. 【請求項１８】 中断実行信号が中断実行信号パケット
    により表わされ、継続実行信号が継続実行信号パケット
    により表わされ、 実行コントローラにおいて中断メッセージを送るステッ
    プが、中断実行信号パケットに応答して中断メッセージ
    を送るステップを含み、 実行コントローラにおいて継続メッセージを送るステッ
    プが、継続実行信号パケットに応答して継続メッセージ
    を送るステップを含む、請求項１５記載の方法。