(57)【特許請求の範囲】
【請求項１】
オーディオ・コンポーネントとビデオ・コンポーネントとインタラクティブ・コンポーネントとから成るＡＶＩコンポジット信号に含まれることになるインタラクティブ・コンポーネントのデータ・ストリームであってアプリケーション・プログラムを構成するために使用される複数のモジュールを含む前記データ・ストリームを生成する方法において、
前記アプリケーション・プログラムに含まれるプログラム・ファイルを生成するステップと、
前記インタラクティブ・コンポーネントのデータ構造を定義するフロー・データを生成するステップであって、前記フロー・データは、
前記アプリケーション・プログラムを構成するために使用される前記モジュールを指定するデータと、
前記プログラム・ファイルを前記モジュールに関連付けるデータと、
送信すべき前記モジュールをスケジューリングするデータを含む、ステップと、
プログラム・ファイルをモジュールに関連づける前記データに応じて、前記プログラム・ファイルの形式を整えて前記モジュールに格納するステップと、
モジュールをスケジューリングする前記データに応じて、送信すべき前記モジュールをスケジューリングするステップと、
前記モジュールを送信するステップ
を含むことを特徴とする方法。
【請求項２】
前記スケジューリングは、
プログラミング・ステートメントからリクエストされたスケジュール・タイムが既にスケジュールされているモジュールのインスタンスに重なるか否かを判定することであって、前記インスタンスは、前記インタラクティブ・コンポーネント・データ・ストリーム内でのモジュールの出現であること、
前記リクエストされたスケジュール・タイムが既にスケジュールされているモジュールのインスタンスに重ならない場合には、インスタンス開始タイムを前記リクエストされたスケジュール・タイムに設定すること、
指定されたモジュールの完全なインスタンスを前記インタラクティブ・コンポーネント・データ・ストリームに挿入するための十分な時間があるか否かを判定することであって、前記完全なインスタンスは、前記指定されたモジュールの全ての出現であること、
前記十分な時間がある場合には、前記インスタンス開始タイムに、前記モジュールの完全なインスタンスを前記インタラクティブ・コンポーネント・データ・ストリームに挿入すること、
前記十分な時間がない場合には、前記インスタンス開始タイムを起点とする前記インタラクティブ・コンポーネント・データ・ストリーム内の一連の複数の利用可能なタイム・スロットに前記モジュールを挿入すること
を含むことを特徴とする請求項１記載の方法。
【請求項３】
スケジューリングのリクエストの１つは、リクエストされたスケジュール・タイムにディレクトリ・モジュールをスケジュールするためのリクエストであって、前記ディレクトリ・モジュールは、前記アプリケーション・プログラムを形成するモジュールであって前記ディレクトリ・モジュール以外のモジュールであることを特徴とする請求項２記載の方法。
【請求項４】
前記フロー・データを、前記アプリケーション・プログラムに含まれるデータと、モジュールと当該モジュールの型又は優先度といった特性を指定するデータと、プログラム・ファイルをモジュールに関連づけるデータと、前記インタラクティブ・コンポーネント内のモジュールをスケジューリングするデータとに分解するステップと、
前記アプリケーション・プログラムに含まれる前記データと、モジュールと当該モジュールの特性を指定するデータに応じて、ディレクトリ・モジュールを構成するステップ
をさらに含むことを特徴とする請求項３記載の方法。
【請求項５】
前記モジュールをスケジューリングするステップは、前記インタラクティブ・コンポーネント・データ・ストリーム内に最初のモジュールとしてディレクトリ・モジュールを最初にスケジューリングするステップを含むことを特徴とする請求項４記載の方法。
【請求項６】
モジュールをスケジューリングする前記データは、各々がモジュールを指定する一連のスケジューリング・リクエストを含み、
各スケジューリング・リクエストは、前記インタラクティブ・コンポーネント・データ・ストリーム内にモジュールを挿入する所定時間を指定する固定タイム・モジュール・リクエストと、前記インタラクティブ・コンポーネント・データ・ストリーム内に挿入する時間が固定していないことを示すフレキシブル・タイム・モジュール・リクエストと、前記インタラクティブ・コンポーネント・データ・ストリーム内に所定のモジュールを挿入可能なだけ挿入することを示す最大挿入・モジュール・リクエストの中から選択され、
前記モジュールをスケジューリングするステップは、
前記インタラクティブ・コンポーネント・データ・ストリーム内に最初のモジュールとして前記ディレクトリ・モジュールを自動的にスケジューリングするステップと、
前記インタラクティブ・コンポーネント・データ・ストリーム内に固定タイム・モジュール・リクエストをスケジューリングするステップと、
前記ディレクトリ・モジュールを指定するスケジューリング・リクエストが前記一連のスケジューリング・リクエストの中にない場合は、前記ディレクトリ・モジュールを前記インタラクティブ・コンポーネント・データ・ストリーム内に自動的にスケジューリングするステップと、
フレキシブル・タイム・モジュール・リクエストを前記インタラクティブ・コンポーネント・データ・ストリーム内にスケジューリングするステップと、
最大挿入・モジュール・リクエストを前記インタラクティブ・コンポーネント・データ・ストリーム内にスケジューリングするステップを
含むことを特徴とする請求項４記載の方法。
【請求項７】
前記一連のスケジューリング・リクエストの１つはauto-execモジュールを指定し、
前記ディレクトリ・モジュールを指定するスケジューリング・リクエストが前記一連のスケジューリング・リクエストの中にない場合にディレクトリ・モジュールを自動的にスケジューリングするステップは、
前記auto-execモジュールと同じ頻度で前記インタラクティブ・コンポーネント・データ・ストリーム内にディレクトリ・モジュールをスケジューリングするステップを含むことを特徴とする請求項６記載の方法。
【請求項８】
前記モジュールをスケジューリングするデータは、モジュールを各々指定する一連のスケジューリング・リクエストを含み、前記モジュールをスケジューリングするステップは、スケジューリング・リクエスト毎に、
前記スケジューリング・リクエストと既にスケジュールされているモジュールとの間に競合が存在するか否かを判定する競合判定ステップと、
競合が存在する場合には、競合解決プロセスを実行する競合解決ステップと、
競合が存在しない場合には、前記指定されたモジュールのインスタンスを前記インタラクティブ・コンポーネント・データ・ストリーム内にスケジューリングするステップ
を含むことを特徴とする請求項１記載の方法。
【請求項９】
前記スケジューリング・リクエストは、リクエストされたスケジュール・タイムに固定タイム・モジュールをスケジュールするリクエストであり、
前記競合判定ステップは、
前記リクエストされたスケジュール・タイムから挿入開始タイムを決定するステップと、
前記識別されたモジュールのサイズと所定の送信速度とから挿入終了タイムを決定するステップと、
前記挿入開始タイムと前記挿入終了タイムのいずれか一方が、既にスケジュールされているモジュールのインスタンスと重なり合うか否かを判定するステップと、
前記挿入開始タイムと前記挿入終了タイムのいずれか一方が、既にスケジュールされているモジュールのインスタンスと重なり合う場合に競合を検出するステップ
を含むことを特徴とする請求項８記載の方法。
【請求項１０】
前記競合解決ステップは、
前記スケジューリング・ステップが失敗したことを検出するステップと、
診断メッセージを発行するステップ
を含むことを特徴とする請求項９記載の方法。
【請求項１１】
前記指定されたモジュールは、ディレクトリ・モジュールであることを特徴とする請求項１０記載の方法。
【請求項１２】
前記一連のスケジューリング・リクエストの１つは、リクエストされたスケジュール・タイムにフレキシブル・タイム・モジュールをスケジュールするリクエストであり、
前記インスタンスをスケジューリングするステップは、
前記リクエストされたスケジュール・タイムが、既にスケジュールされているモジュールのインスタンスに重なり合うか否かを判定するステップと、
前記リクエストされたスケジュール・タイムが既にスケジュールされているモジュールと重なり合わない場合には、インスタンス開始タイムを前記リクエストされたスケジュール・タイムに設定し、前記インスタンスを設定するステップと、
前記リクエストされたスケジュール・タイムが、既にスケジュールされているモジュールと重なり合う場合には、スケジュールされたモジュールが存在しない前記インタラクティブ・コンポーネント・データ・ストリーム内の次のタイムに前記インスタンス開始タイムを設定するステップと、
前記指定されたモジュールのサイズと所定の送信速度から、前記指定されたモジュールの完全なインスタンスを前記インタラクティブ・コンポーネント・データ・ストリームに挿入するのに十分な時間があるか否かを判定するステップと、
十分な時間があれば前記インスタンス開始タイムに、前記モジュールの完全なインスタンスを前記インタラクティブ・コンポーネント・データ・ストリームに挿入し、十分な時間がなければ前記インスタンス開始タイムを起点とする、前記インタラクティブ・コンポーネント・データ・ストリーム内の一連の複数の利用可能なタイム・スロットに前記モジュールを挿入するステップを
含むことを特徴とする請求項８記載の方法。
【請求項１３】
前記スケジューリング・リクエストは、前記リクエストされたスケジュール・タイムと、指定されたモジュール挿入タイム内に、前記フレキシブル・タイム・モジュールをスケジュールするリクエストであり、
前記競合判定ステップは、
前記インスタンス開始タイムが前記挿入タイム内にあるか否かを判定するステップと、
前記インスタンス開始タイムが前記挿入タイム内にない場合には、競合を検出するステップ
を含むことを特徴とする請求項１２記載の方法。
【請求項１４】
前記競合解決ステップは、
前記スケジューリング・ステップが失敗したことを検出するステップと、
診断メッセージを発行するステップ
を含むことを特徴とする請求項１３記載の方法。
【請求項１５】
前記スケジューリング・リクエストの１つは、モジュール・スペーシング・タイムだけ離隔した前記リクエストされたスケジュール・タイムからフレキシブル・タイム・モジュールの複数のインスタンスをスケジュールするリクエストであり、
前記モジュールをスケジューリングするステップは、前記アプリケーション・プログラムが完了するまで、前記モジュール・スペーシング・タイムだけインクリメントされた前記前の開始タイムに等しい所望の開始タイムで前記インスタンス・スケジュール・ステップを繰り返すステップを更に含み、
前記競合判定ステップは、
前記既にスケジュールされた前記指定されたモジュールのインスタンスに対する終了挿入タイムを決定するステップと、
前記終了挿入タイムが前記指定されたモジュールの現在のインスタンスに対する前記インスタンス開始タイムより後か否かを判定するステップと、
前記終了挿入タイムが前記指定されたモジュールの現在のインスタンスに対する前記インスタンス開始タイムより後の場合には競合を検出するステップを含み、
前記競合解決ステップは、
前記スケジュール・ステップが失敗したことを検出するステップと、
診断メッセージを発行するステップ
を含むことを特徴とする請求項８記載の方法。
【請求項１６】
モジュールの特性は優先度であり、
前記ディレクトリ・モジュールを構成するステップは、モジュールとそれらの特性を指定する前記データに応じて、優先度をモジュールに割り当てるステップを含み、
前記一連のスケジューリング・リクエストのサブセットは、リクエストされたスケジュール・タイムにフレキシブル・タイム・モジュールをスケジュールするリクエストであり、
前記インスタンスをスケジューリングするステップは、
最高の優先度が割り当てられた前記モジュールを指定するスケジューリング・リクエストの前記サブセットのうちの１つを初めに選択するステップと、
前記選択されたスケジューリング・リクエストに対して前記繰り返しステップを実行するステップと、
次に低い優先度が割り当てられたモジュールを指定するスケジューリング・リクエストの前記サブセットのうちの次の１つを選択するステップと、
前記選択されたスケジューリング・リクエスト内の指定された前記モジュールに割り当てられた前記優先度が最低の優先度になるまで、前記実行ステップと前記選択ステップを繰り返し、その後、前記最初に選択するステップを繰り返すステップとを含むことを特徴とする請求項１５記載の方法。
【請求項１７】
前記繰り返しステップは、前記アプリケーション・プログラムの終了まで前記インスタンス・スケジューリング・ステップを繰り返すことを特徴とする請求項１６記載の方法。
【請求項１８】
前記スケジューリング・リクエストの１つは、モジュール・スペーシング・タイムだけ離隔した前記リクエストされたスケジュール・タイムからフレキシブル・タイム・モジュールの複数のインスタンスをスケジュールするリクエストであり、前記インスタンスは、指定された継続期間内にスケジュールされ、前記繰り返しステップは、前記挿入タイム期間が終了するまで、前記リクエストされたスケジュール・タイムから前記インスタンス・スケジューリング・ステップを繰り返すことを特徴とする請求項１６記載の方法。
【請求項１９】
前記指定されたモジュールは、前記ディレクトリ・モジュールであることを特徴とする請求項１８記載の方法。
【請求項２０】
前記一連のスケジューリング・リクエストの１つは、リクエストされたスケジュール・タイムに最大挿入・モジュールをスケジュールするリクエストであり、
前記インスタンス・スケジュール・ステップは、
前記要求されたスケジュール・タイムで起点とする、スケジュールされたモジュールがない前記インタラクティブ・コンポーネント・データ・ストリーム内の次のタイムにインスタンスの開始タイムを設定するステップと、
前記指定されたモジュールのサイズと所定の送信速度から前記指定されたモジュールの完全なインスタンスを前記インタラクティブ・コンポーネント・データ・ストリームに挿入するのに十分な時間があるか否かを判定するステップと、
十分な時間がある場合には、前記インスタンス開始タイムに前記インタラクティブ・コンポーネント・データ・ストリームに前記モジュールの完全なインスタンスを挿入し、十分な時間がない場合には、前記インスタンス開始タイムを起点とする前記インタラクティブ・コンポーネント・データ・ストリーム内の複数の利用可能なタイム・スロットに前記モジュールを挿入するステップと、
前記設定、前記判定、および前記挿入ステップを繰り返すステップ
を含むことを特徴とする請求項８記載の方法。
【請求項２１】
前記繰り返すステップは、前記アプリケーション・プログラムの終了まで繰り返す請求項２０記載の方法。
【請求項２２】
前記スケジューリング・リクエストの１つは、指定されたモジュール挿入タイム期間のリクエストされたスケジュール・タイムで、最大挿入・モジュールをスケジュールするリクエストであり、前記繰り返すステップは、前記挿入タイム期間の終了まで繰り返すことを特徴とする請求項２０記載の方法。
【請求項２３】
モジュールの特性は優先度であり、
インタラクティブ・コンポーネント・データ・ストリームを生成するステップは、モジュールとそれらの特性とを指定する前記データに応じてモジュールに優先度を割り当てるステップを更に含み、
前記一連のスケジューリング・リクエストのサブセットは、リクエストされたスケジュール・タイムに最大挿入・モジュールをスケジュールするリクエストであり、
前記インスタンス・スケジューリング・ステップは、
最高の優先度が割り当てられた前記モジュールを指定するスケジューリング・リクエストの前記サブセットのうちの１つを最初に選択するステップと、
前記選択されたスケジューリング・リクエストに対して、前記設定ステップ、前記判定ステップ及び前記挿入ステップを実行するステップと、
次に低い優先度が割り当てられたモジュールを指定するスケジューリング・リクエストの前記サブセットのうちの次の１つを選択するステップと、
前記選択されたスケジューリング・リクエスト内で指定された前記モジュールに割り当てられた前記優先度が最低の優先度になるまで前記実行ステップと前記選択ステップを繰り返し、その後、前記最初に選択するステップを繰り返すステップを更に含むことを特徴とする請求項２０記載の方法。
【請求項２４】
前記繰り返すステップは、前記アプリケーション・プログラムの終了まで繰り返すことを特徴とする請求項２３記載の方法。
【請求項２５】
前記スケジューリング・リクエストの前記１つは、指定されたモジュール挿入タイム期間のリクエストされたスケジュール・タイムで最大挿入・モジュールをスケジュールするリクエストであり、
前記繰り返すステップは、前記挿入タイム期間の終了まで繰り返すことを特徴とする請求項８記載の方法。
【請求項２６】
前記モジュールをスケジューリングするステップは、前記インタラクティブ・コンポーネント・データ・ストリーム内の最初のモジュールとして最初にディレクトリ・モジュールをスケジューリングするステップを含むことを特徴とする請求項２記載の方法。
【請求項２７】
前記モジュール・スケジューリングを示すデータは、各々がモジュールを指定する連続スケジューリング・リクエストを含み、各リクエストは、固定タイム・モジュール・リクエストと、フレキシブル・タイム・モジュール・リクエストと、最大挿入・モジュール・リクエストとから成る組から選択され、
前記モジュールをスケジューリングするステップは、
前記インタラクティブ・コンポーネント・データ・ストリーム内の最初のモジュールとして前記ディレクトリ・モジュールを自動的にスケジューリングするステップと、
前記インタラクティブ・コンポーネント・データ・ストリーム内の固定タイム・モジュール・リクエストをスケジューリングするステップと、
前記ディレクトリ・モジュールを指定するスケジューリング・リクエストが前記一連のスケジューリング・リクエストの中にない場合には、前記ディレクトリ・モジュールを前記インタラクティブ・コンポーネント・データ・ストリーム内に自動的にスケジューリングするステップと、
フレキシブル・タイムモジュール・リクエストを前記インタラクティブ・コンポーネント・データ・ストリーム内にスケジューリングするステップと、
最大挿入・モジュール・リクエストを前記インタラクティブ・コンポーネント・データ・ストリーム内にスケジューリングするステップを含むことを特徴とする請求項１記載の方法。
【請求項２８】
前記一連のスケジューリング・リクエストの１つは、auto-exec モジュールを指定し、前記ディレクトリ・モジュールを指定するスケジューリング・リクエストが前記一連のスケジューリング・リクエストの中にない場合には、ディレクトリ・モジュールを自動的にスケジューリングするステップは、前記auto-exec モジュールと同じ頻度で前記インタラクティブ・コンポーネント・データ・ストリーム内にディレクトリ・モジュールをスケジュールするステップを含むことを特徴とする請求項２７記載の方法。
【請求項２９】
オーディオ・コンポーネントとビデオ・コンポーネントとインタラクティブ・コンポーネントとから成るＡＶＩコンポジット信号に含まれることになるインタラクティブ・コンポーネントであってアプリケーション・プログラムを構成するために使用される複数のモジュールを含む前記インタラクティブ・コンポーネントを生成する装置において、
前記インタラクティブ・コンポーネントは、
前記アプリケーション・プログラムに含まれるプログラム・ファイルのソースと、
前記インタラクティブ・コンポーネントのデータ構造を定義するフロー・データのソースであって、前記フロー・データは、
前記アプリケーション・プログラムを構成するために使用される前記モジュールを指定するデータと、
前記プログラム・ファイルを前記モジュールに関連付けるデータと、
送信すべき前記モジュールをスケジューリングするデータを含む、フロー・データのソースと、
前記フロー・データのソースからのデータに応じて、前記プログラム・ファイルのソースから得たデータを前記インタラクティブ・コンポーネントに選択的に挿入するフロー・ビルダーを含み、
前記フロー・ビルダーは、
前記フロー・データを、前記アプリケーション・プログラムに含まれるデータと、モジュールと当該モジュールの型又は優先度といった特性を指定するデータと、プログラム・ファイルをモジュールに関連づけるデータと、前記インタラクティブ・コンポーネント内のモジュールをスケジューリングするデータとに分解するパーサと、
前記プログラムグラム・ファイルをモジュールに関連づける前記分解されたデータに応じて、各々が関連づけられたプログラム・ファイルとモジュールについてのレコードを含むモジュール・ファイルを構成するモジュール・フォーマッタと、
前記モジュールをスケジューリングする前記分解されたデータに応じて、各プログラム・ファイルが送信されるべきシーケンスを生成するモジュール・スケジューラ
を備えることを特徴とする装置。
【請求項３０】
前記アプリケーション・プログラムに含まれる前記分解されたデータと、モジュールとそれらの特性を指定する前記分解されたデータに応じて、アプリケーション・データを含む１つのレコードと、データを示すモジュールを含む各指定されたモジュールに対する１つのレコードを含むディレクトリ・モジュール・ファイルを構成するディレクトリ・モジュール・コンストラクタを更に備えることを特徴とする請求項２９記載の装置。
【請求項３１】
前記モジュール・スケジューラは、スケジュール・ファイルを構築するように構成され、前記フロー・ビルダーは、前記スケジュール・ファイルと前記モジュール・ファイル内の前記データを処理することによってインタラクティブ・コンポーネント・データ・ストリームを生成するように構成されたデータ・ストリーム・ジェネレータを更に備えることを特徴とする請求項３０記載の装置。
【請求項３２】
前記フロー・ビルダーは、プロセッサによって実行可能なプログラム命令を含むことを特徴とする請求項２９記載の装置。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、オーディオ・ビデオ・インタラクティブ（audio video interactive ：ＡＶＩ）送信システムのためのフロー・ビルダー（flow builder）に関する。
【０００２】
なお、本明細書の記述は本件出願の優先権の基礎たる米国特許出願第０８／２６９，２９１号（１９９４年６月３０日出願）の明細書の記載に基づくものであって、当該米国特許出願の番号を参照することによって当該米国特許出願の明細書の記載内容が本明細書の一部分を構成するものとする。
【０００３】
【背景技術】
オーディオ・ビデオ・インタラクティブ（ＡＶＩ）システムは、提案された放送エンターテインメント・システムであり、それでは、コンポジット信号が放送局（broadcast location）から受信局（receiving locations ）に放送される。ＡＶＩ信号は、現在のテレビ・システムと同様にオーディオ成分（コンポーネント）とビデオ成分（コンポーネント）とを含み、また、インタラクティブ・アプリケーション成分（コンポーネント）を含んでいる。受信局は、インタラクティブ・アプリケーション・コンポーネントを抽出し、放送ビデオとオーディオ上に重畳されたスクリーン・ディスプレイとサウンドをそれぞれ提供し、インタラクティブ・アプリケーション・コンポーネントに応答して看者（viewer）入力の全てに応答するデータ・プロセッサを含んでいる。受信局のデータ・プロセッサは、また、インタラクティブ・アプリケーション・コンポーネントに応答してモデムのような、看者から放送者へあるいは広告者のような第三者に情報を通信するための通信装置を含んでいる。
【０００４】
インタラクティブ・アプリケーション・コンポーネントは、ディレクトリー・モジュールを含む複数のモジュールを具備し、ディレクトリー・モジュールは、インタラクティブ・プログラム・コンポーネントを構築する他のモジュールに対する内容のテーブルとして働く。加えて、そこには受信局のデータ・プロセッサによって実行される実行可能コードを含む少なくとも１つのコード・モジュールがある。特に、auto-exec モジュールが指定される１コード・モジュールはインタラクティブ・アプリケーションの実行を開始するために必要な実行可能なコードを含んでいる。このauto-exec モジュールは、インタラクティブ・アプリケーション・コンポーネントから自動的に抽出され、受信局のデータ・プロセッサがインタラクティブ・アプリケーション・コンポーネントの存在をまず検出するとき実行される。コード・モジュールあるいはモジュール内の実行可能なコードに従って受信局のデータ・プロセッサにより処理されるべきデータを含む１以上のデータ・モジュールがまた存在してもよい。最後に、ＡＶＩコンポジット信号は、インタラクティブ・アプリケーションにメッセージを送信するための信号モジュールを含んでもよい。
【０００５】
看者がいつでもＡＶＩアプリケーションに参加することができ、彼ら自身のペースで対話をしながら進行し、受信局のデータ・プロセッサ内で必要とされるメモリ量を最小にすることができるためには、コード・モジュールとデータ・モジュールがＡＶＩ信号内で連続して繰り返されるということが考えられる。あるモジュールが他のモジュールよりより高い頻度で繰り返されることが必要であろう。例えば、ＡＶＩコンポジット信号がまず看者により同調されるときと、看者が会話を始める時の間の時間を最小にするために、インタラクティブ・コンポーネント内の他のモジュールより高い頻度でディレクトリー・モジュールとauto-exec モジュールの両方を繰り返すことが望ましいであろう。加えて、特定のモジュールがある予め決められた時間だけ受信局に送信されることを確保することが必要かもしれない。たとえば、サブタイトルの場合には、サブタイトルを含むデータ・モジュールが、それらのワードを話すオーディオ・コンポーネントの前に受信者に到着していることが必要である。
【０００６】
アプリケーション・プログラマーは、アプリケーションがプログラムされつつあるとき、どのモジュールが他のモジュールより高い頻度で繰り返されるべきか、および／あるいはどのモジュールが予め決められた時間だけ送信されなければならないかを知っている。こうして、アプリケーション・プログラマーは、どのモジュールがインタラクティブ・アプリケーション・コンポーネント中に含まれるべきかを指定するデータを提供し、アプリケーションの準備の一部としてそれらのモジュールに対するスケジュール・データを提供することができる。このようにして提供されたモジュールとスケジュール・データを解析し、要求されるスケジュールの制約を満足するインタラクティブ・コンポーネント・データ・ストリームを生成し、他のスケジュール制約との了解を最大とするための機構を提供することが望ましい。
【０００７】
【発明の概要】
本発明の原理によれば、オーディオ・ビデオ・インタラクティブ（ＡＶＩ）・コンポジット信号のための、アプリケーション・プログラムを表す、インタラクティブ・コンポーネント・データ・ストリームを生成するための方法は、以下のステップを具備する。まず、アプリケーション・プログラムを表すプログラム・ファイルが生成される。その後、インタラクティブ・コンポーネントのデータ構造を定義するフロー・データが生成される。最後に、データ・ストリームが、フロー・データに応答してプログラム・ファイルをデータ・ストリームに選択的に挿入することにより生成される。インタラクティブ・コンポーネント・データ・ストリームを生成するための装置は、アプリケーション・プログラムを表すプログラム・ファイルのソースと、インタラクティブ・コンポーネントのデータ構造を定義するフロー・データソースとを具備する。フロー・ビルダーは、フロー・データソースからのデータに応答してファイルのソースからのファイルをインタラクティブ・コンポーネントに選択的に挿入する。
【０００８】
【実施例】
図１は、本発明によるフロー・ビルダー（flow builder）を含む送信局の一部を示すブロック・ダイアグラムである。図１において、アプリケーション・コンポーネント・データ・ストリーム内に含まれるべきモジュールを特定し、それらのモジュールに対して情報をスケジュールするフロー・データとコード・ファイル、データ・ファイルのようなアプリケーション・ファイルとが両方ともフロー・ビルダー１０の各入力端子にアプリケーション・プログラマーにより供給される。フロー・ビルダー１０の出力端子はトランスポート・パケッタイザー（transport packetizer）２０の入力端子に接続されている。トランスポート・パケッタイザー２０の出力端子はマルチプレクサ３０の第一の入力端子に接続されている。マルプレサ３０の出力端子はＡＶＩデータ・ストリームを搬送するトランスポート媒体に接続されている。マルチプレクサ３０の第二の入力端子はパケット化ビデオ表現データ信号を受信するように接続され、マルチプレクサ３０の第三の入力端子はパケット化オーディオ表現データ信号を受信するように接続されている。
【０００９】
図２は、本発明によるフロー・ビルダー１０を含むデータ処理システムを示すブロック・ダイアグラムである。図２において、中央処理ユニット（ＣＰＵ）１１は、リード・ライト・メモリ（ＲＡＭ）１２とリード・オンリー・メモリ（ＲＯＭ）にシステム・バス１４を介して接続されている。図２のデータ処理システムは、さらに、アプリケーション・プログラマーにデータを提供するためのユーザー入力装置１６と、アプリケーション・プログラマーからのデータを受信するための表示装置１５を含み、両者はシステム・バスに接続されている。大規模格納装置１７は、また、システム・バスに接続され、アプリケーション・プログラマーにより使用されるアプリケーション・ビルダー・プログラムと、アプリケーション・ファイルと、フロー・データ・ファイルとを含むファイルを一時的に格納するために使用される。ＣＰＵ１１、ＲＡＭ１２、ＲＯＭ１３、表示装置１５、ユーザー入力装置１６、および大規模格納装置１７は、データ処理システムとして既知のように動作し、それらの動作は詳細には説明しない。例えば、こうして説明される図２のデータ処理システムは、パーソナル・コンピューター（ＰＣ）あるいはワーク・ステーションとして実現される。ネットワーク・アダプター、モデム、プリンター、バス拡張器等のような他の既知の装置が、データ処理システムのシステム・バスに接続されてもよい。
【００１０】
付加的な出力ポートがパケッタイザー出力アダプター１８により提供され、そのアダプターは（図１の）トランスポート・プロセッサ２０へのインターフェイスとして働く。パケッタイザー出力アダプター１８は、また、システム・バス１４に接続されていて、プリンターへのインターフェイスとして現在使用されているような単なるシリアルあるいはパラレル出力ポートであってもよい。しかしながら、特に設計された出力アダプターが必要とされてもよい。データ処理システム・インターフェイス設計の当業者は、そのような出力アダプターをどのように設計し実現するか理解できよう。パケッタイザー出力アダプター１８の出力端子はフロー・ビルダー１０の出力端子１９に接続されている。出力端子１９は、トランスポート・パケッタイザー２０の入力端子に接続されている。
【００１１】
図１と図２を参照して、動作に際し、アプリケーション・プログラマーは、ユーザー入力装置１６と表示装置１５を用いて、コードとデータ・ファイルのためのソース・データを生成する。ソース・データは、マス格納装置１７内に一時的に格納される。大規模格納装置１７に同様に格納されたコンパイラーは、アプリケーション・ビルダー内で、ソース・データを既知のようにして実行可能なコード・ファイルと関連するデータ・ファイルとに変換し、大規模格納装置１７にこれらのファイルを格納する。同様にして、アプリケーション・プログラマーは、インタラクティブ・コンポーネントに含まれるモジュールとそれらの特性とを指定し、そのモジュールのインタラクティブ・コンポーネントのデータ・ストリーム内への挿入をスケジュールするためのソース・フロー・データを生成する。このソース・データの内容は、以下に詳細に説明する。フロー・ビルダー１０は、ソース・フロー・データを処理し、コード・ファイルとデータ・ファイルをモジュールと関連づけ、モジュールのアプリケーション・コンポーネント・データ・ストリーム内への挿入をスケジュールし、そのデータ・ストリームを生成する。フロー・ビルダー１０の出力は、インタラクティブ・コンポーネント・データ・ストリームであり、そのデータ・ストリーム内の各指定されたモジュールは適切にシーケンスされ、適当な時間に現れる。その出力は出力端子１９を介してトランスポート・パケッタイザー２０に供給される。トランスポート・パケッタイザー２０は、既知の方法でインタラクティブ・コンポーネント・データ・ストリームをパケット化する。パケット化データ・ストリームと、パケット化ビデオおよびオーディオのコンポーネントはマルチプレクサ３０でマルチプレクスされ、既知の方法でＡＶＩデータ・ストリームを形成する。
【００１２】
図３は、図１と図２に示されるフロー・ビルダー１０の動作を示すデータ・フロー図である。図３において、アプリケーションビルダー５は、アプリケーション・プログラマーから、実行可能なコードとデータからなるインタラクティブ・アプリケーション・プログラムを表すソース・データを受信する。アプリケーション・ビルダー５は、コードファイルとデータ・ファイルを含むファイル・セット１０４を作成する。それは、また、フロー・ビルダー１０内でモジュールを生成することが可能である。例えば、信号モジュールおよび／あるいは微小データ・モジュールがフロー・ビルダー１０内で生成され、内部的に処理されてもよい（いずれかのタイプのモジュールが生成される間に、コードとより大きなデータ・モジュールがアプリケーションビルダー５により実際に作成される）。図３の残りの部分は、フロー・ビルダー１０を通してのデータ・フローを示す。
【００１３】
フロー・ビルダー１０は、アプリケーション・プログラマーにより提供されるソース・フロー・データを解析する。ソース・フロー・データのフォーマットは、以下に詳細に説明する。フロー・データは、（１）アプリケーションと関連するデータ、（２）アプリケーションに含まれるべきモジュールとその特性を特定するデータ、（３）コードファイルとデータ・ファイルとをモジュールと関連づけるデータ、（４）アプリケーション・コンポーネント・データ・ストリーム内でのモジュールの出現をスケジュールするためのデータを含んでいる。フロー・データはプロセス１０２で処理され、特に、解析される。アプリケーションに関連するデータとモジュールとそれらの特性を特定するデータとはプロセス１０６に導かれる。プロセス１０６は、ディレクトリー・モジュールを構築し、ディレクトリー・ファイル１０８内に構築されたディレクトリー・モジュールを格納する。
【００１４】
図４は、ディレクトリー・ファイル１０８の構造を示すメモリレイアウト図である。図４において、ディレクトリー・ファイル１０８内のデータ・フィールドは水平方向のバンドで示され、レコード（records ）は太い水平線により分離されている。ディレクトリー・ファイル１０８は、アプリケーションのための識別子、アプリケーションをランさせるために必要なデコーダー・メモリ、およびアプリケーションでのモジュールの全体数を含むアプリケーション・データを含む第一のレコードを持つ。アプリケーションに関連づけられたデータがプロセス１０６により受信されると、それは格納され、解析される。適切なデータがディレクトリー・ファイル１０８の第一のレコードの対応するフィールドにおかれる。ディレクトリー・ファイル１０８は、さらに、モジュール識別子、このモジュールをランさせるために必要なメモリ上のモジュール長、および他のフラグを含むアプリケーション内の各モジュールに対するレコードを持っている。モジュールとその特性とを特定するデータがプロセス１０６により受信されると、また、それは格納され、解析される。このデータは、新しく定義されたモジュールに関するものならば、新しいレコード・ディレクトリー・ファイル１０８内で作成される。適切なモジュール・データが新しいレコード内の対応するフィールドにおかれる。データがプロセス１０６により受信されるにつれて、以前に定義されたレコード内のフィールドは更新される。例えば、モジュールが新たに定義されるごとに、アプリケーション内のモジュールの全体数を特定するアプリケーション・レコード内のフィールドはインクリメントされることにより更新される。
【００１５】
アプリケーション・データを含むソース・フロー・データ・ステートメントは、
Application(APPLN_ID,APPLN_MEMORY)
である。
【００１６】
（実際のプログラム・ステートメントは、異なる形式であってもよいし、および／あるいは異なるあるいは付加的なアーギュメントを含んでもよい。それらは簡略化のため省略されている。さらに、そのようなプログラミング・ステートメントを生成して処理するためシステム・プログラミングの当業者は、オブジェクト指向のプログラミングのようなプログラム・パラダイム、Ｃ＋＋プログラミング環境のようなプログラミング環境を選択することが可能である。）プロセス１０２がフロー・データ中にこのステートメントを認識すると、ディレクトリー・モジュール・プロセス１０６を構築するように導かれる。そのプロセスは、ディレクトリー・モジュール・ファイル１０８を初期化し、アプリケーション識別子（Applicatioin_ID ）と要求されるアプリケーションメモリ（APPLN_MEMORY）とを第一のレコードの対応するフィールドに挿入する。
【００１７】
モジュールとその特性を特定するための４つの可能なソース・フロー・データステートメントがある。すなわち、
appAutoExec(MODULE_ID,MODULE_MEMORY)
appCode(MODULE_ID,MODULE_MEMORY)
appData(MODULE_ID,MODULE_MEMORY)
appSignal()
である。
【００１８】
第一のプログラミング・ステートメントは、インタラクティブ・コンポーネントが受信局でまず検出されるときに自動的に実行されるコードを含む自動実行（ａｕｔｏ−ｅｘｅｃ）モジュールを識別する。第二のプログラミング・ステートメントは、実行可能なコードを含むモジュールを識別し、第三のプログラミング・ステートメントはデータを含むモジュールを識別する。これらのプログラミング・ステートメントのうちの１つがプロセス１０２により認識されると、それは、ディレクトリー・モジュール・プロセス１０６を構築するように導かれ、そのプロセス１０６は、新しいモジュール・レコードを作成し、モジュール識別子（ＭＯＤＵＬＥ＿ＩＤ）と要求されるモジュール・メモリ（ＭＯＤＵＬＥ＿ＭＥＭＯＲＹ）を新たに作成されたモジュール・レコード内の対応するフィールドに挿入する。これらのプログラミング・ステートメントの最後のものは、信号モジュールを特定する。これは、受信局に信号を送るための特別なモジュールである。実施例では、信号モジュールは、１２０キャラクターに制限され、モジュール名が割り当てられない。
【００１９】
図３を再び参照して、フロー・データがプロセス１０２で解読されるにつれて、コード・ファイルとデータ・ファイルをモジュールと関連づけるデータはプロセス１１０に供給される。プロセス１１０は、ファイル・セット１０４から適切なコード・ファイルおよび／あるいはデータ・ファイルを、ディレクトリー・ファイル１０８内の関連するモジュール・レコードからデータを引き出す。引き出されたデータを用いて、プロセス１１０は、そのファイルのためのデータを含むファイルをフォーマットして生成し、それをモジュール・ファイルセット１１２に格納する。
【００２０】
図５の右側は、モジュール・ファイル１１２の構造を示すメモリ・レイアウト図である。インタラクティブ・コンポーネント・データ・ストリーム内に含まれる各モジュールはモジュール・ファイル１１２内にレコードを有して、受信局にトランスポート媒体上を送信されるとき、そのモジュールを実際に構成するデータを含む。図５に示されるように、各モジュールは、そのモジュールに関連するデータを含むヘッダー・フィールドと、モジュール・データ・フィールドを含む。ヘッダー・フィールドは、モジュール識別子と、モジュール・バージョン番号と、モジュール長を含み、この場合、それは巡回冗長チェック（ＣＲＣ）コードを含む。この情報のいくつかは、ファイル・セット１０４内のコード・ファイルあるいはデータ・ファイルから決定されてもよく、いくつかは、プロセス１０６により維持されているモジュール関連データにより供給されてもよい。モジュール・データ・フィールドは、そのモジュールを構築する実行可能なコードあるいはデータを含み、それは、ファイルセット１０４内の特定されたコード・ファイルあるいはデータ・ファイルから引き出される。好適実施例では、ヘッダー・データ・フィールドはヘッダー・パケット内に形成され、モジュール・データ・フィールドは（図１の）トランスポート・パケッタイザー２０内の複数の等しいサイズのデータ・パケット内にパケット化される。
【００２１】
コード・ファイルとデータ・ファイルをモジュールに関連づけるデータを含むソース・フロー・データ・ステートメントは、
MODULE_ID.moduleSource(ModuleFile)
あるいは、
MODULE_ID.moduleSource(ModuleBuffer)
である。最初のステートメントは、ファイル・セット１０４からのコード・ファイルあるいはデータ・ファイルを以前に定義されたモジュールと関連づけ、第二のステートメントはソース・フロー・データ内の適切なプログラミング・ステートメント（図示せず）により以前に定義されたメモリ・バッファを以前に定義されたモジュールと関連づける。第二のステートメントは、アプリケーション・プログラマーが上記のようにソース・フロー・データ内のモジュール・データを定義することを可能とする。プロセス１０２は、フロー・データ内のこれら２つのステートメントのいずれか一方を認識するとき、フォーマット・モジュール・プロセス１１０に導かれ、それは、モジュール・ファイル１１２内に新しいレコードを作成し、プログラミング・ステートメントからのモジュール識別子（MODULE_ID ）と、（このステートメントが同じモジュールに対して複数回コールされれば、プロセス１１０により自動的に維持される）モジュール・バージョン番号と、（ディレクトリー・ファイル１０８内の対応するレコードからの）モジュール長とをモジュール・ファイル１１２内の新たに作成されたレコードのヘッダー・フィールド内に置く。その後、（第一のステートメントに対する）ファイル・セット１０４からの特定のコードファイルあるいはデータ・ファイルの内容、あるいは（第二のステートメントに対する）メモリ・バッファがモジュール・ファイル１１２内の新たに作成されたレコードのモジュール・データ・フィールド内にコピーされる。
【００２２】
図３を再び参照して、フロー・データがプロセス１０２において解読されるとき、アプリケーション・コンポーネント・データ・ストリーム内のモジュールの出現をスケジュールするためのデータはプロセス１１４に導かれる。プロセス１１４は、アプリケーション・プログラマーにより提供されるスケジュール情報の全てを集める。集められたスケジュール・データは、モジュールのための要求されたスケジュール時間とオプションとしてのスケジュール時間の両方を含んでいる。異なる形式のスケジュール・リクエストを以下に詳細に説明する。全ての情報が集められたとき、インストラクションがプロセス１１４に与えられ、モジュールをスケジュールする。集められたスケジュール・データは処理され、集められたスケジュール・データに従ってモジュールをスケジュールすることが実行される。要求されたスケジュール時間の全てが満足されないときには、スケジュール・リクエストは失敗し、診断メッセージがアプリケーション・プログラマーに戻される。他に、モジュールをインタラクティブ・コンポーネント・データ・ストリーム内に置くためのタイミング情報が生成され、スケジュール・ファイル１１６に格納される。スケジュール・ファイル１１６を生成するためのプロセスを以下に詳細に説明する。
【００２３】
図５の左側は、スケジュール・ファイル１１６の構造を示すメモリ・レイアウト図である。スケジュール・ファイル１１６は、インタラクティブ・コンポーネント・データストリーム内でのモジュールの出現（また、インスタンスと呼ばれる）の度に１つのレコードを持ち、インタラクティブ・プログラムの初めからその出現までの時間オフセットと、その時間オフセットにインタラクティブ・コンポーネント・データ・ストリーム内に置かれるべきモジュール・データを含むモジュール・ファイル１１２内のレコードを指すポインターと、データ・ストリーム内に置かれるべき送信単位の長さと、スケジュールされた送信単位に含まれるべきデータのモジュール・データ・フィールド内のオフセットとを含んでいる。スケジュール・ファイル１１６内のレコードは、先頭のスケジュールされたモジュールに関連するレコードから、最後にスケジュールされたモジュールに関連するレコードまで、時間オフセット順に維持されている。これらのフィールドの詳細を以下に説明する。
【００２４】
図５において、スケジュール・ファイル１１６内の最初のレコードは、そのレコードのモジュール・ポインター・フィールドからモジュール・ファイル１１２内の最初のレコードまで走る矢印により示されるように、モジュール・ファイル１１２内の最初のモジュールをインタラクティブ・コンポーネント・データ・ストリームに挿入するためのスケジュール・データを含んでいる。スケジュール・ファイル１１６内の２番目のレコードは、モジュール・ファイル１１２内の４番目のモジュールに関連し、スケジュール・ファイル１１６内の３番目のレコードはモジュール・ファイル１１２内の３番目のモジュールに関連する。
【００２５】
上記のように、アプリケーション・プログラマーは、要求されたスケジュール時間とオプションスケジュール時間とを含むフロー・ビルダー１０にスケジュール・データを供給する。実施例では、モジュール・スケジュール・リクエストの４つのカテゴリーがある。すなわち、ディレクトリー・モジュール、固定時間モジュール、フレックスタイムモジュール、最大挿入（max-insert）モジュールである。
【００２６】
上記のように、フロー・ビルダー１０内のプロセス１０６は、アプリケーション・プログラマーからのフロー・データに応答してディレクトリー・モジュールを自動的に生成する。スケジュール・モジュール・プロセス１１４は、インタラクティブ・コンポーネント・データ・ストリームの初め（時間オフセット＝０）にディレクトリー・モジュールのインスタンスを自動的におく。実施例では、これは、変更できず、このときに他のいずれかのモジュールに対する要求されたスケジュール・リクエストは競合状態となり、エラーであり、診断メッセージが発行される。
【００２７】
ディレクトリー・モジュールの他のインスタンスは、以下の２つのプログラミング・ステートメントの内の一方を用いて、アプリケーション・プログラマーからのフロー・データに応答してスケジュールされる。
【００２８】
insertDirectory(insertionTime)
または、
insertDirectory(insertionTime, moduleSpacing, insertionDuration)
最初のステートメントは、ディレクトリー・モジュールのインスタンスが時間オフセットinsertionTime でインタラクティブ・コンポーネント・データ・ストリーム内に挿入されることをリクエストする。２番目のステートメントは、ディレクトリー・モジュールの多数のインスタンスが挿入され、時間オフセットinsertionTime で始まり、insertionDuration の期間、時間オフセットmoduleSpacing だけ離されている。insertionDuration アーギュメントが省略されると、ディレクトリー・モジュールの多くのインスタンスはインタラクティブ・プログラムが終了するまで挿入される。これらのプログラミング・ステートメント（と続くそれら）により表現される挿入リクエストと関連するデータは、フロー・ビルダー１０内の内部データ構造（図示せず）に一時的に格納される。アプリケーション・プログラマーからのそのようないずれのスケジュール・リクエストもないときには、ディレクトリー・モジュールはauto-exec モジュール（後述）と同じ周期で自動的にスケジュールされる。
【００２９】
固定時間モジュール・リクエストは、以下のプログラミング・ステートメントを用いてなされる。
【００３０】
MODULE_ID.insertModule(insertionTime)
このステートメントは、モジュールMODULE_ID のインスタンスが時間オフセットinsertionTime でデータ・フロー内に挿入されることをリクエストする。そのようなスケジュール・リクエストの数は、いずれのモジュールに対してもなされる。固定時間スケジュール・リクエストはスケジュール・リクエストを要求する。固定時間スケジュール・リクエストの全ては、スケジュールが成功するために競合無しで満足されなければならない。そのようなスケジュール・リクエストの全てに関連するデータは、フロー・ビルダー１０内の内部データ構造に格納される。
【００３１】
フレックス・タイム・モジュール・スケジュール・リクエストは、スケジュール時間のある程度の柔軟性があるものである。フレックス・タイム・モジュール・スケジュール・リクエストにはいくつかの形式がある。最初の形式は、ここで説明していないプログラミング・ステートメントを用いてフロー・ビルダー１０により維持される時間オフセット値である現在のシステム時間の後最初に利用可能となる時間にインタラクティブ・コンポーネント・データ・ストリームに挿入されるべきリクエストされたモジュールの単一のインスタンスに対するリクエストである。フレックス・タイム・モジュールのこの種のものをスケジュールすることをリクエストするためのプログラミング・ステートメントは、
MODULE_ID.insertModule()
であり、それは、特に指定された挿入時間オフセットを持たない（上記）フレックス・タイム・スケジュール・リクエストと同じ形式である。
【００３２】
フレックス・タイム・モジュール・スケジュール・リクエストの２番目の形式は、インタラクティブ・コンポーネント・データ・ストリームに挿入されるべきリクエストされたモジュールの多数のインスタンスに対する１つである。この種のフレックス・タイム・モジュールのスケジュールをリクエストするためのプログラミング・ステートメントは、
MODULE_ID.insertModule(insertionTime,moduleSpacing,insertionPeriod)
である。このステートメントは、リクエストされたモジュールMODULE_ID の多数のインスタンスがインタラクティブ・コンポーネント・データ・ストリームに挿入されるべきことをリクエストする。最初のインスタンスは、insertionTime 後に最初に利用可能となった時間オフセットで挿入されるべきである。リクエストされたモジュールMODULE_ID のインスタンス間の区間は、時間オフセット期間moduleSpacing である。インスタンスは、insertionTime からの時間オフセット期間insertionPeriod の間に挿入される。insertionPeriod アーギュメントが省略されると、リクエストされたモジュールの多くのインスタンスはinsertionTime とインタラクティブ・アプリケーションの終了の間に挿入される。多数のインスタンスの内のいずれかがスケジュールできなければ、スケジュールは失敗であり、診断メッセージが発行される。最大挿入モジュール・スケジュールのためのプログラミング・ステートメントは、
MODULE_ID.insertModule(insertionTime,MAXIMUM_INSERTION,insertionPeriod)
このステートメントは、moduleSpacing アーギュメントとして供給される、予め定義された定数MAXIMUM_INSERTION つきのフレックス・タイム・モジュール・リクエストの多数インスタンス形式と同様である。この場合、リクエストされたモジュールの多くのインスタンスとして適合するようなMODULE_ID は、insertionPeriod 時間オフセット期間の間にインタラクティブ・コンポーネント・データ・ストリームに挿入されるべきであろう。しかしながら、この場合、スケジュールできるインスタンスがなければ、スケジュールは成功であり、診断メッセージは発行されない。
【００３３】
上記のように、スケジュール・リクエストの全てが受信され、処理された後、インストラクションがインタラクティブ・コンポーネント・データ・ストリームをスケジュールするように供給される。そのようなインストラクションに対するプログラミング・ステートメントは、
scheduleFlow()
である。このインストラクションに応答して、上記のようにフロー・ビルダー１０内の内部データ構造に格納された、前にエンターされたスケジュール・リクエストの全てを表す前に格納されたデータは解析され、スケジュール・ファイル１１６が生成される。
【００３４】
一般に、いずれかのモジュール・リクエストがスケジュールされるとき、インタラクティブ・コンポーネント・データ・ストリーム内の開始時間オフセットはそのリクエストから決定され、そのモジュールに対する終了時間オフセットはモジュールの長さと、インタラクティブ・コンポーネントの送信レートとから決定される。スケジュール・リクエストにより表される時間のブロックは、何らかの競合が存在するか否かを決定するために既にスケジュールされたモジュールに対してチェックされる。競合が存在すれば、解決行動がとられ、それは、処理されるべきスケジュール・リクエストの形式（フィックスト（fixed ）・タイム、フレックス・タイム等）に依存する。他に、新しいレコードが新たにスケジュールされたモジュールを表す（図５の）スケジュール・ファイル１１６内に作成される。
【００３５】
図５を参照して、スケジュール・ファイル１１６の新しいレコードでは、開始時間オフセットは時間オフセット・フィールドに挿入され、その時間オフセットに送信されるべきモジュールを含むモジュール・ファイル１１２内のエントリーを指すポインターがモジュール・ポインター・フィールドに挿入される。モジュールの長さは、モジュール・ヘッダーから引き出され、送信単位長フィールドに挿入され、送信単位オフセットは初めに０に設定される。これらの最後の２つのフィールドは、以下に説明するように、競合解決手順の一部として変更されることができる。
【００３６】
図６は、scheduleFlow()プログラミング・ステートメントに応答して図３のスケジュール・モジュール・プロセスにより実行される処理２００のフロー図であり、図７は図６に示されるスケジュール・プロセスを理解する際に有益なタイミング図である。図７では、モジュールは、各時間ライン上に四角として表され、その四角の中にはモジュールの識別子が示されている。各時間ラインは、スケジュール・プロセス内の異なる時間におけるインタラクティブ・コンポーネント・データ・ストリームの同じ部分を表す。
【００３７】
図６で、ステップ２０２でプロセスは始まる。ステップ２０４で、最初のディレクトリー・モジュールが、上記のように、時間オフセット０でインタラクティブ・コンポーネント・データ・ストリームに挿入される。図５を参照して、スケジュール・ファイル１１６内の最初のレコードは、この最初のディレクトリー・モジュールを表し、モジュール・ファイル１１２内の最初のレコードはディレクトリー・モジュールを含んでいる。この場合、時間オフセット・フィールドの値は０であり、モジュール・ポインターはモジュール・ファイル１１２内のディレクトリー・モジュール・エントリーを指している。送信単位長は、ディレクトリー・モジュールの長さを含み、その送信単位オフセットは０である。図７を参照して、時間ラインａ）は最初のディレクトリー・モジュール３００が時間０に挿入された後のデータ・ストリームを示している。
【００３８】
ステップ２０６では、全ての固定時間モジュール・リクエストがスケジュールされる。上記のように、固定時間モジュール・リクエストは、ディレクトリー・モジュールを含めて、いずれの種類のモジュールに対しても存在する。最初に、全ての固定時間ディレクトリー・モジュール・リクエストがスケジュールされる。その後、残りの固定時間モジュール・リクエストがその順番にスケジュールされ、それらのリクエストは（図３の）ソース・データ・フロー内で生じる。上記のように、各固定時間モジュール・リクエストに対する開始と終了の時間オフセットは決定される。これらの時間オフセットのいずれかが前にスケジュールされたモジュールと重なれば、競合が存在する。この場合、スケジュールは失敗であり、診断メッセージが発行される。
【００３９】
例えば、図７の時間ラインｂ）は、ステップ２０６の完了後のデータ・ストリームを示している。この例では、固定時間ディレクトリー・モジュール・リクエストは時間ｔ１の間になされていた。このリクエストに応答して、ディレクトリー・モジュールのインスタンス３０２がデータ・ストリームに挿入された。その後、auto-exec モジュールに対する固定時間モジュール・リクエストが時間ｔ２の間になされ、そしてコード１モジュールに対する固定時間モジュール・リクエストが時間ｔ３の間にその順番でなされた。これらのリクエストに応答して、auto-exec モジュールのインスタンス３０４は時間ｔ２にデータ・ストリームに挿入され、コード１モジュールのインスタンス３０６が時間ｔ３でデータ・ストリームに挿入される。固定時間モジュール・リクエストが時間ｔ４の間に後でなされれば、しかしながら、以前にスケジュールされたコード１モジュールとの競合が生じ、スケジュールは失敗であり、診断メッセージが発行される。
【００４０】
ステップ２０８では、フロー・ビルダー１０により、（上記のようにauto-exec モジュールと同じ繰り返しレートで）自動的に生成される、あるいは、アプリケーション・プログラマーにより多数インスタンス・フレックス時間リクエストであるかのどちらかであるそれらのディレクトリー・モジュール・スケジュール・リクエストが処理される。ディレクトリー・モジュールの多数のインスタンスは、最初にリクエストされまたは自動的に生成された最後（すなわち、インタラクティブ・プログラムの終り）に対するインスタンスからスタートするようにスケジュールされる。各リクエストされたインスタンスでは、望ましい開始時間が計算される。モジュールが既にその望ましい開始時間にスケジュールされていれば、その望ましい開始時間の前後で、他のモジュールがスケジュールされていないその望ましい開始時間にできるだけ近い時間が探される。ディレクトリー・モジュールはスケジュールされ、そのときに始まる。
【００４１】
完全なディレクトリー・モジュールが利用可能なタイム・スロット内に適合することができなければ、ディレクトリー・モジュールは多数の送信単位内に分割される。最初に利用可能な時間スロット内に適合するものがデータ・ストリーム中の送信単位に挿入され、ディレクトリー・モジュールの残りのものが完全なディレクトリー・モジュールが送信されるまで、引き続いての利用可能なタイム・スロットの全てを占拠する送信単位に適合する。ディレクトリー・モジュールに対する最後の送信単位が、次のディレクトリー・モジュール・インスタンスの所望の開始時間を超えて延長すると、スケジュールは失敗し、診断メッセージが生じる。
【００４２】
図５を参照して、モジュールが分割されるとき、スケジュール・ファイル１１６内の分離レコードがデータ・ストリーム内に挿入される各送信単位に対して生成される。最初のレコードが生成され、その時間オフセットはモジュールの最初の部分の開始時間であり、モジュール・ポインターは望ましいモジュール（この場合、ディレクトリー・モジュール）を含むモジュール・ファイル１１２のレコードを指している。送信単位長は、最初の部分で送信されることができるバイト数に設定され、送信単位オフセットは０に設定される。スケジュール・ファイル１１６の２番目のレコードはその後生成され、その時間オフセットはデータ・ストリーム内の次に使用可能なタイム・スロットの開始時間であり、モジュール・ポインターはまだ、望ましいモジュールを含むモジュール・ファイル１１２内のレコードを指している。この場合、送信単位長は、２番目の部分で送信されることができるバイト数を含み、送信単位オフセットは、送信されるべきモジュール・ファイル１１２内の望ましいモジュール・レコードのモジュール・フィールド内の次のバイトを指すように設定される。スケジュール・ファイル１１６内の後続のレコードは、モジュールが完全に送信されるまで同様に生成される。
【００４３】
図７を参照して、時間ラインｃ）は、ステップ２０８の完了後の時間ラインを示している。この例では、プログラマー・フレックス・タイム・ディレクトリー・モジュール・リクエストは、望ましい時間ｔ５で始まるディレクトリー・モジュールの多数のインスタンスを挿入するようにさせられる。モジュールは、インタラクティブ・コンポーネント・データ・ストリームの終了まで、インスタンス間に距離ＳＰＡＣＩＮＧ離れている。この場合には、望ましい時間ｔ５は、前にスケジュールされたauto-exec モジュール３０４とオーバーラップしている。ｔ５にもっとも近い使用可能な時間はｔ６であり、すなわちauto-exec モジュール３０４の終了時である。ディレクトリー・モジュールの全体を送信するのに十分な自由時間があり、それでスケジュール・ファイル１１６のエントリーは、時間ｔ６でデータ・ストリーム内にディレクトリー・モジュールの完全なインスタンス３０８を挿入させられる。ディレクトリー・モジュールの次のインスタンスのための望ましい開始時間は時間ｔ７である。この時間が利用可能であるが、ディレクトリー・モジュールの完全なインスタンスを含むために十分な時間はなく、ディレクトリー・モジュールは分割されなければならない。
【００４４】
（“Ｄ”とラベルが付いた）  ディレクトリー・モジュールのインスタンスの最初の部分３１０は時間ｔ７で始まり、時間ｔ３で終わる。これは、以前にスケジュールされたコード１モジュールのインスタンス３０６の開始時間である。（“ＩＲ”とラベルが付いた）ディレクトリー・モジュール・インスタンスの２番目の部分３１２は、時間ｔ８で始まり、時間ｔ９で終わる。時間ｔ８は、コード１モジュール・インスタンス３０６の終了時である。最初の部分３１０と２番目の部分３１２の結合は、図７に連結部分３１０と３１２により示されるように、ディレクトリー・モジュールの完全なインスタンスを含んでいる。
【００４５】
上記のように、（図５の）スケジュールファイル１１６内の２つのレコードはディレクトリー・モジュールのこのインスタンスのために生成される。この最初のレコードは、コード１モジュール・レコードの前に置かれ、ｔ７の時間オフセットと、最初の部分にバイト数Ｂ１を含む送信長フィールドと、０の送信単位オフセットとを含んでいる。２番目のレコードは、コード１モジュール・レコードの後におかれ、ｔ８の時間オフセットと、２番目の部分にバイト数Ｂ２を含む送信長フィールドと、Ｂ１＋１の送信単位オフセットとを含んでいる。前記２つのレコードのためのモジュール・ポインターは、ディレクトリー・モジュールを含むモジュール・ファイル１１２内のレコードを指す。
【００４６】
図７を再び参照して、ディレクトリー・モジュールの次のインスタンスのための望ましい開始時間は時間ｔｌＯであり、それは時間ｔ７＋ＳＰＡＣＩＮＧである。この時間が利用可能なので、また、ディレクトリー・モジュールの完全なインスタンスのための十分な利用可能な時間があるので、（図５の）スケジュールファイル１１６の単一のレコードは、上記のようにして、ディレクトリー・モジュールのインスタンス３１４を時間ｔｌＯで始まるデータストリームに挿入させられる。ディレクトリー・モジュールの前のインスタンス（３１０、３１２）の終了時間ｔ９が次のインスタンスの望ましい開始時間ｔｌＯより後ならば（例えば、コード１モジュール・インスタンス３０６の期間が長ければ、起きるであろう）、スケジュールは失敗であり、診断メッセージが発行されるであろう。ＳＰＡＣＩＮＧだけ離されたディレクトリー・モジュールのインスタンスを挿入する上記のプロセスは、インタラクティブ・コンポーネント・プログラムが終了するまで続けられる。（上記のように）モジュールの多数のインスタンスをデータ・ストリームに挿入するための時間期間を指定することもできる。そのようなリクエストがなされると、ディレクトリー・モジュール・インスタンスはインスタンスの望ましい開始時間が指定された時間期間内にある限り挿入されるであろう。
【００４７】
再び図６を参照して、ステップ２１０で、フレックス・タイム・モジュールはスケジュールされる。上記のように、２つの形式のフレックス・タイム・モジュール・リクエストが存在する。最初の形式は、単一インスタンス・フレックス・タイム・モジュール・リクエストであり、２番目の形式は多数インスタンス・フレックス・タイム・モジュール・リクエストである。ステップ２１０では、まず、（ディレクトリー・モジュールの単一のインスタンスに対するリクエストを含めて）全ての単一インスタンス・フレックス・タイム・モジュール・リクエストが、ソース・フロー・データ内にアプリケーション・プログラマーにより供給される順番にスケジュールされる。上記のように、望ましい開始時間は、ソース・フロー・データ内のリクエストから決定される。望ましい開始時間が利用可能ならば、レコードはスケジュール・ファイル１１６内に生成され、望ましい開始時間は時間オフセット・フィールドに格納され、モジュール・ポインターは望ましいモジュールを含むモジュール・ファイル１１２内のレコードを指している。望ましいモジュールの完全なインスタンスを搬送するのに利用可能時間が十分でなければ、上記のように、モジュールはセクションに分割される。望ましい開始時間が利用可能でなければ、望ましいモジュールは次の利用可能時間に挿入され、必要ならば部分に分割されてもよい。上記のように、挿入期間は、アプリケーション・プログラマーにより指定できる。望ましいモジュールが望ましい開始時間の挿入期間内にスケジュールされることができなければ、スケジュールは失敗であり、診断メッセージが発行される。
【００４８】
図７を参照して、時間ラインｄ）はステップ２１０の最初の部分の完了後のデータ・ストリームを示している。時間ラインｄ）では、挿入期間ＰＥＲＩＯＤ内の時間ｔ３で信号モジュールＳのインスタンスをスケジュールするリクエストが処理される。時間ｔ３は、しかしながら、利用可能ではなく、次の利用可能なタイム・スロットが探される。このタイム・スロットは時間ｔ９であり、それはディレクトリー・モジュールのインスタンスの２番目の部分３１２の終了時である。このタイム・スロットは挿入期間ＰＥＲＩＯＤ内にあるので、信号モジュールＳのインスタンス３１６は以下に説明するようにして時間ｔ９で始まるデータ・ストリームに挿入される。挿入期間ＰＥＲＩＯＤは短縮化され、時間ｔ９まで延びていなければ、このスケジュール・リクエストは失敗し、診断メッセージが発行される。
【００４９】
図６を再び参照して、多数インスタンス・フレックス・タイム・モジュール・リクエストがステップ２１０でスケジュールされる。モジュールの全てのリクエストされたインスタンスは、次のモジュール・リクエストがスケジュールされる前にスケジュールされる。そのようなスケジュール・リクエストに対するスケジュール・プロセスは、詳細に説明したように、多数インスタンス・ディレクトリー・モジュール・リクエストに対するそれと同様であり、ここでは詳細には説明しない。インスタンスは、データ・ストリーム内の最初の望ましいインスタンスから始まり最後までスケジュールされる。望ましい開始時間は、スケジュール・リクエストから決定される。望ましい開始時間が利用可能ならば、レコードはその時間に望ましいモジュールのインスタンスを挿入するためにスケジュール・ファイル１１６内に生成される。望ましい時間が自由でなければ、次の利用可能な時間が探され、インスタンスはそのときに挿入される。完全なインスタンスを挿入するのに十分な時間がなければ、インスタンスはいくつかの部分に分割される。完全なインスタンスが次のインスタンスの望ましい開始時間前にスケジュールされることができなければ、スケジュールは失敗であり、診断メッセージが発行される。
【００５０】
多数のインスタンス・フレックス・タイム・モジュール・リクエストがスケジュールされる順番は、アプリケーション・プログラマーにより２つの方法でなされることができる。最初に、各モジュールは、ソース・フロー・データ内のプログラミング・ステートメントにより優先度が与えられる。モジュールに優先度を割り当てるプログラミング・ステートメントは、
MODULE_ID.setPriority(priorityValue)
である。実施例では、０のpriorityValue が最高の優先度であり、より低い値はより高い値よりも高い優先度を持っている。多数のインスタンス・フレックス・タイム・モジュール・リクエストがスケジュールされるとき、より高い優先度を持つモジュールの全てのインスタンスはより低い優先度のモジュールのどのインスタンスがスケジュールされるより前にスケジュールされる。
【００５１】
第二に、アプリケーション・プログラマーがいずれかのモジュールに対する優先度を設定しないとしても、モジュールはそれらがソース・フロー・データ内に定義された順番に従って優先度を受け、ソース・フロー・データ内で早く定義されたモジュールは後で定義されたものより高い優先度を有する。この場合、多数インスタンス・フレックス・タイム・モジュールリクエストがスケジュールされつつあるとき、ソース・フロー・データ内で先に定義されたモジュールの全てのインスタンスは、後で定義されたモジュールの全てのインスタンスがスケジュールされる前にスケジュールされる。
【００５２】
図７を再び参照して、時間ラインｅ）は、ステップ２１０の２番目の部分が完了した後のデータストリームを示している。時間ラインｅ）では、インスタンス間にモジュール距離ＳＰＡＣＩＮＧで時間ｔ１０に始まる、データ・モジュールの多数のインスタンスを挿入するフレックスタイムリクエストが処理される。時間ｔ１０は利用可能ではないので、データモジュールのインスタンス３１８は次の利用可能な時間ｔ１１に挿入される。次の望ましい挿入時間ｔ１２は時間ｔ１０後にＳＰＡＣＩＮＧ時間がある。再び時間ｔ１２は利用可能ではなく、データ・モジュールの次のインスタンス３２０は次に利用可能な時間ｔ１３に挿入される。次の望ましい時間ｔ１４は時間ｔ１２からＳＰＡＣＩＮＧ時間ある。この時間は利用可であり、データ・モジュールのインスタンス３２２は、（図７に部分的に示されるだけだが）時間ｔ１４で挿入される。
【００５３】
図６を再び参照して、全ての最大挿入モジュール・リクエストはステップ２１２で処理される。各最大挿入モジュール・リクエストは、開始時間と時間期間を含み、その時間期間にリクエストされたモジュールのできるだけ多くのインスタンスがデータ・ストリームに挿入される。どの単一のインスタンスに対しても、次に利用可能な時間が探される。レコードはスケジュール・ファイル１１６内に生成され、時間オフセットはこの時間に設定され、モジュール・ポインターは望ましいモジュールを含むモジュール・ファイル内のレコードを指している。望ましいモジュールの完全なインスタンスを挿入するのに十分な時間があれば、送信単位長はモジュールの長さに設定され、送信オフセットは０に設定される。他に、上記のようにモジュールは分割される。
【００５４】
アプリケーション・プログラマーにより多くの最大挿入モジュール・リクエストが提供されてもよい。（setPriority プログラミング・ステートメントを使用してアプリケーションプログラマーにより明確に、あるいは上記のように、ソース・データ・フロー内のモジュール定義ステートメントの位置により）各モジュールに割り当てられた優先度はモジュールのインスタンスをスケジュールする際に影響を与える。最高の優先度レベルで始めて、その優先度レベルで各リクエストされた項目から１つの項目が次の利用可能な時間にスケジュールされる。その後、次に低い優先度レベルが処理され、再びその優先度レベルの各リクエストされた項目から１つのインスタンスが次の利用可能な時間にスケジュールされる。これは、最低の優先度レベルの各項目のインスタンスがスケジュールされるまで続く。その後、プロセスは、最高の優先度レベルから繰り返される。フロー・ビルダー１０は、もはや利用可能なものが残っていなくなるまで、優先度レベル・インスタンス・スケジュールを通して繰り返される。
【００５５】
図７を参照して、最大挿入モジュール・リクエストは３つの小さいデータ・モジュールＡ、Ｂ、Ｃを処理した。Ａは、最高の優先度レベルを持ち、Ｂは中間の優先度レベルを持ち、Ｃは最低の優先度レベルを持つ。データ・モジュールＡは最高の優先度を持つので、データ・モジュールＡの１つのインスタンス３２４は、次に利用可能な時間ｔ１５でまずスケジュールされる。その後、次に低い優先度のデータモジュールＢの１つのインスタンス３２６は次に利用可能な時間ｔ１６でスケジュールされる。その後、次に低い優先度のデータ・モジュールＣの１つのインスタンス３２８が次に利用可能な時間ｔ１７でスケジュールされる。モジュールＣは最低の優先度を持つので、フロービルダー１０は最高の優先度レベルに戻るまでループする（loops ）。再び、最高の優先度のデータモジュールＡの１つのインスタンス３３０が次に利用可能な時間ｔ１８でスケジュールされる。その後、次に低い優先度のデータモジュールＢの１つのインスタンス３３２が次に利用可能な時間ｔ１９でスケジュールされる。その後、最低の優先度のデータ・モジュールＣの１つのインスタンスが次に利用可能な時間ｔ２０でスケジュールされる。しかしながら、モジュールＣの完全なインスタンスは時間ｔ２０で始まる利用可能な時間に適合しない。そこで、データモジュールＣは上記のように、２つの部分に分割される。最初の部分３３４は時間ｔ２０でスケジュールされ、２番目の部分３３６は時間ｔ２１でスケジュールされる。これは、全ての利用可能なタイム・スロットがデータ・モジュールＡ、Ｂ、Ｃのインスタンスで満たされるまで続く。
【００５６】
図３を再び参照して、利用可能な時間の全てが最大挿入モジュールで満たされたとき、スケジュール・ファイル１１６は完了する。その後、プロセス１１８は、スケジュール・ファイル１１６とモジュール・ファイル１１２内のデータを処理することにより、リアルタイムでインタラクティブ・コンポーネント・データ・ストリームを生成する。プロセス１１８は、（図１の）送信システム内のシステム・クロック（図示せず）からクロック信号（図示せず）を受信する。インタラクティブ・プログラムが開始されたとき、スケジュール・ファイル内の最初のレコードはプロセス１１８により読み出される。その後、システムクロックからの時間がその最初のレコード内の時間オフセット・フィールドと比べられる。システム・クロック時間が時間オフセットと同じになったときは、スケジュールされたモジュールがパケット化されるべき時である。まず、ヘッダー・データが（図１の）パケッタイザー２０に供給される。このデータは、モジュール識別子、モジュール・ファイル１１２内のヘッダー・フィールドからのモジュール・バージョン、およびスケジュールファイル１１６内の対応するフィールドからの送信単位長とオフセットを含んでいる。このヘッダー・データはヘッダーあるいは補助のパケットと呼ばれる特別の形式の単一のパケットにパケット化される。第二にモジュール・ポインターによりポイントされているモジュール・ファイル１１２のレコードからのモジュール・データがモジュール・ファイル１１２から引き出され、トランスポート・パケッタイザー２０に供給される。スケジュール・ファイル１１６の現在のレコードからの送信単位長はトランスポートパケッタイザー２０に供給されるべきモジュール・データのバイト数を示し、送信単位オフセット・フィールドはモジュール・データのためのモジュール・データ・ファイル１１２内の指示されたレコードのモジュール・データ・フィールドの開始位置を示す。トランスポート・パケッタイザー２０はモジュール・データを連続するパケットにパケット化し、それをマルチプレクサ３０に供給する。マルチプレクサ３０は、オーディオとビデオのパケットとインタラクティブ・コンポーネント・パケットを結合し、トランスポート媒体にマルチプレクスされたパケット・ストリームを供給する。その後、プロセス１１８は、次のエコー度を読み、インタラクティブ・プロセスが完了するまでそのプロセスを繰り返す。
【図面の簡単な説明】
【図１】本発明によるフロー・ビルダーを含む送信局の一部のブロック・ダイアグラムを示す図である。
【図２】本発明によるフロー・ビルダーを含むデータ処理システムのブロック・ダイアグラムを示す図である。
【図３】図１に示されるフロー・ビルダーの動作を示すデータ・フロー図である。
【図４】図３に示されるフロー・ビルダーの動作を理解する際に有益な、ディレクトリー・ファイルの構造を示すメモリレイアウト図である。
【図５】図３に示されるフロー・ビルダーで使用されるスケジュール・ファイルとモジュール・ファイルの構造と関係を示すメモリレイアウト図である。
【図６】図３に示されるフロー・ビルダー内のスケジュール・モジュールにより実行される処理のフロー図である。
【図７】図６に示されるスケジュール・プロセスを理解する際に有益なタイミング図である。
【符号の説明】
１０  フロー・ビルダー
２０  トランスポート・パケッタイザー
３０  マルチプレクサ
【図１】
0004087466.tif 000002
【図２】
0004087466.tif 000003
【図３】
0004087466.tif 000004
【図４】
0004087466.tif 000005
【図５】
0004087466.tif 000006
【図６】
0004087466.tif 000007
【図７】
0004087466.tif 000008