JP5813756B2 - ファイルシステム抽象化、ブロードキャストスケジュールメッセージおよび選択的受信を使用した、ブロードキャストネットワーク上でのファイル配信 - Google Patents

Description

関連出願
本出願は、その内容全体が参照により本明細書に組み込まれる、２０１０年５月２８日に出願された「File Delivery Over A Broadcast Network Using File System Abstraction, Broadcast Schedule Messages And Selective Reception」と題する米国仮出願第６１／３４９，５９８号の優先権の利益を主張する。

ワイヤレス通信技術は、過去数年にわたって爆発的成長を経験してきた。この成長は、モバイル大衆に移動の自由を与え、有線通信システムへの束縛を断ち切る、ワイヤレスサービスによって加速された。サービス拡張の結果として、ワイヤレスサービスの人気は急速に成長し続けることが予想される。ワイヤレス通信サービスへの最近の追加は、受信機デバイスにテレビジョンおよび他のコンテンツをブロードキャストする能力である。モバイル順方向リンク専用ブロードキャストサービスは、ユーザが、テレビ番組などのマルチメディア番組を閲覧することと、モバイルブロードキャスト送信を受信するように構成されたモバイル受信機デバイスを使用して、ニュース、エンターテインメント、スポーツ、ビジネス、および他のブロードキャスト番組のモバイル版を受信することとを可能にする。マルチメディアブロードキャストサービスの成長は、多種多様なコンテンツを配信することと、ユーザと対話することとを行うための魅力的な通信プラットフォームを表す。

様々な実施形態は、受信機デバイス上で実行しているアプリケーションにファイルを配信するためにブロードキャストおよび／またはマルチキャストベースのファイル配信フレームワーク（ＦＤＦ：File Delivery Framework）を利用するためのシステム、デバイス、および方法を与える。詳細には、様々な実施形態は、ブロードキャストおよび／またはマルチキャストネットワークのＦＤＦサービスを使用してブロードキャストシステム上で受信機デバイスにファイルを効率的に配信するための機構およびシステムを与える。ブロードキャストおよび／または受信のためのファイルおよびデータグラムパケットが、ブロードキャストスケジュールメッセージ（ＢＳＭ：Broadcast Schedule Message）をブロードキャストすることによってブロードキャストネットワークによって事前に広告されていることがある。将来指定された時間にブロードキャストされることになるファイルおよびデータグラムパケットを受信機デバイスに通知するために、ＢＳＭは事前に送信され得る。様々な実施形態は、よりタイムリーでコヒーレントで有効な方法でファイルを配信するために、ＦＤＦサービスによって与えられるビルトイン冗長性、誤り訂正および信頼性機構を利用する。

本明細書に組み込まれ、本明細書の一部をなす添付の図面は、本発明の例示的な実施形態を示し、上記の概略的な説明および下記の発明を実施するための形態とともに、本発明の特徴を説明するのに役立つ。

一実施形態において使用するのに好適なモバイルマルチメディアブロードキャスト通信システムおよびセルラー「ユニキャスト」通信システムを示す通信システムブロック図。 順方向リンク専用ブロードキャストシステムのブロードキャスト通信システムブロック図の代替表現。 一実施形態による、ブロードキャストネットワークを介してファイルを配信することに関与する機能ブロックを示すブロードキャスト通信システムの要素のシステムブロック図。 様々な実施形態の主要な機能構成要素を示す概観システムブロック図。 一実施形態による、特定のアプリケーション（天気アプリケーション）のためのファイルの取込みおよび受信を示すシステムブロック図。 一実施形態による、特定のアプリケーション（ｉＴＶアプリケーション）のためのファイルの取込みおよび受信を示すシステムブロック図。 ブロードキャストパイプにおいて送信される特定のファイルのタイミングおよび受信パラメータを受信機デバイスに通知するためにブロードキャストスケジュールメッセージがどのように送信され得るかを示すタイミング図。 ブロードキャストパイプにおいて送信される特定のファイルのタイミングおよび受信パラメータを受信機デバイスに通知するためにブロードキャストスケジュールメッセージがどのように送信され得るかを示すタイミング図。 ブロードキャストスケジュールメッセージにおいて使用するのに好適な例示的なデータ構造の図。 ブロードキャストスケジュールメッセージにおいて使用するのに好適な別の例示的なデータ構造の図。 次のブロードキャストスケジュール期間（ＢＳＰ：broadcast schedule period）のブロードキャストスケジュールフロー（ＢＳＦ：broadcast schedule flow）においてブロードキャストスケジュールメッセージ（ＢＳＭ）を更新するためにブロードキャストスケジュールメッセージの次のモニタ時間データフィールドがどのように使用され得るかを示すタイミング図。 ブロードキャストスケジュールメッセージを処理するための一実施方法のプロセスフロー図。 ブロードキャストスケジュールフロー上で更新検出を実装するための一実施方法のプロセスフロー図。 受信機デバイスが様々な時間にブロードキャストネットワークのおよび／またはブロードキャストフローのカバレージエリアの外にあり得ることを示すタイミング図。 初期収集フロー（ＩＡＦ：initial acquisition flow）をサポートするシステム上でブロードキャストスケジュールフロー（ＢＳＦ）の更新を検出するための一実施方法を示すタイミング図。 同じスーパーフレーム内で、ブロードキャストスケジュールメッセージの２つの異なるバージョンを受信するための一実施方法を示すタイミング図。 初期収集フロー（ＩＡＦ）システムからのサポートを用いてブロードキャストスケジュールメッセージ（ＢＳＭ）を処理するための一実施方法のプロセスフロー図。 受信機デバイスとブロードキャストサーバとの間で更新されたブロードキャストスケジュールメッセージ（ＢＳＭ）のブロードキャストのタイミングをはかるための一実施方法を示すタイミング図。 受信機デバイス上のファイル配信フレームワーク（ＦＤＦ）の階層化図を示すシステムブロック図。 異なるアプリケーションにわたるファイル共有をサポートするファイル配信フレームワーク（ＦＤＦ）を実装するための一実施方法のプロセスフロー図。 異なるアプリケーションにわたってファイルを共有するために使用され得る構造、データフローおよびハイレベルステップを示すシステムブロック図。 受信機デバイス上のファイル配信フレームワーク（ＦＤＦ）の構造およびデータフローと、ファイル配信フレームワークがそれによってファイルを受信または拒絶することを選択する決定プロセスとを示すシステムブロック図。 受信機デバイス上のファイル配信フレームワーク（ＦＤＦ）の構造およびデータフローと、受信機デバイス上のファイル配信フレームワークがそれによってファイルを受信および記憶するプロセスとを示すシステムブロック図。 アプリケーションが関係している要素のみを選択的に受信するための一実施方法のプロセスフロー図。 ブロードキャストスケジューリング記録を処理するための一実施方法のプロセスフロー図。 受信機デバイス上のファイル配信フレームワーク（ＦＤＦ）の構造およびデータフローと、ブロードキャストスケジュール記録がそれによって処理されるプロセスとを示すシステムブロック図。 ファイル配信フレームワーク上でのファイルの受信のための一実施方法を示すシステムブロック図。 スクラッチスペース管理の構造、データフローと、ファイル配信コア（ＦＤＣ：file delivery core）において実装され得るプロセスとを示すシステムブロック図。 要素を処理し、記憶するための一実施方法のプロセスフロー図。 スクラッチスペースから削除すべきアイテムを選択するための一実施方法のプロセスフロー図。 データをソートし、編成する一実施方法の構造およびデータフローを示すシステムブロック図。 緊急ファイルが緊急データフロー上でどのように同時に配信され得るかを示すタイムライン図。 ファイルが別個のブロードキャストサービスフロー上でのフローのためにどのように処理され得るかを示すメッセージフロー図。 複数周波数ネットワーク（ＭＦＮ：multi frequency network）において、受信機デバイスが、どのように、ブロードキャストサービスフローの更新があることを検出し得るが、同時に、受信機デバイスがその更新を受信することができないことを識別し得るかを示すタイムライン図。 新しいマルチプレックスに移動する受信機デバイスが新しいマルチプレックスのためのＢＳＭを受信することをどのように強制され得るかを示すタイムライン図。 ２つ以上のマルチプレックスが同じ無線周波数上にある、ファイル配信フレームワーク構成を示すタイムライン／ブロック図。 ファイル配信コア（ＦＤＣ）が、異なる無線周波数上で独立してファイルダウンロードをスケジュールするように構成された、ファイル配信フレームワーク構成を示すタイムライン／ブロック図。 ファイル配信パイプ（ＦＤＰ：file delivery pipe）ペイロードの構造を示すシステムブロック図。 ファイル名とストレージ名とのファイル配信フレームワークマッピングを示すメッセージフロー図。 管理要素テーブル（ＭＥＴ：managed element table）を示すブロック図。 アプリケーションのためのストレージスペースを管理するための一実施方法のプロセスフロー図。 アプリケーションのために受信されるべき要素のためのストレージスペースを確認するための一実施方法のプロセスフロー図。 アプリケーションのために受信されるべき要素のためのストレージスペースを確認するための、アプリケーションレイヤとファイル配信フレームワークとの間のデータフローおよび対話を示すフロー図。 アプリケーションストレージスペースへの受信したファイルの移動のための一実施方法のプロセスフロー図。 受信したファイルをアプリケーションストレージスペースに移動させる間の、アプリケーションレイヤ（アプリレイヤ）と、ファイル配信コア（ＦＤＣ）レイヤと、ファイル配信ファイル管理（ＦＤＭ：file delivery file management）レイヤとの間のデータフローおよび対話を示すフロー図。 ファイル配信ファイル管理（ＦＤＭ）レイヤの管理要素テーブルにおいて複数のファイル名を同じストレージ名にマッピングするための一実施方法のプロセスフロー図。 受信したファイルのための十分なアプリケーションストレージスペースがない状況を扱うための一実施方法のプロセスフロー図。 受信したファイルのための十分なアプリケーションストレージスペースがない状況を扱う際の、アプリケーションレイヤ（アプリレイヤ）とファイル配信フレームワーク（ＦＤＦ）との間のデータフローおよび対話を示すフロー図。 削除機能を扱うための一実施方法のプロセスフロー図。 ファイル配信フレームワーク上にファイルバンドル機能を実装するための一実施方法のプロセスフロー図。 ファイル配信フレームワーク上のファイルバンドル機能における、アプリケーションレイヤ（アプリレイヤ）と、ファイル配信コア（ＦＤＣ）レイヤと、ファイル配信ファイル管理（ＦＤＭ）レイヤとの間のデータフローおよび対話を示すフロー図。 保存されるべきファイルバンドル中のファイルを選択するためにファイル配信ファイル管理レイヤによって使用されるべき選択ストリングを生成するための一実施方法のプロセスフロー図。 ファイル配信フレームワーク上のファイルバンドル機能によって使用されるべき選択ストリングを判断する際の、アプリケーションレイヤ（アプリレイヤ）と、ファイル配信コア（ＦＤＣ）レイヤと、ファイル配信ファイル管理（ＦＤＭ）レイヤとの間の例示的なデータフローおよび対話を示すフロー図。 ファイルバンドルが受信されるべきかどうかを判断するための一実施方法のプロセスフロー図。 ファイルバンドルが受信されるべきかどうかを判断する際の、アプリケーションレイヤ（アプリレイヤ）と、ファイル配信コア（ＦＤＣ）レイヤと、ファイル配信ファイル管理（ＦＤＭ）レイヤとの間の例示的なデータフローおよび対話を示すフロー図。 ファイルバンドル中のファイルを保存する際の、アプリケーションレイヤ（アプリレイヤ）と、ファイル配信コア（ＦＤＣ）レイヤと、ファイル配信ファイル管理（ＦＤＭ）レイヤとの間の例示的なデータフローおよび対話を示すフロー図。 管理要素テーブル（ＭＥＴ）中の例示的なファイルバンドルエントリを示すメッセージフロー図。 ファイルバンドルを受信し、アプリケーションストレージスペースに保存するための一実施方法のプロセスフロー図。 ファイルバンドルを受信し、アプリケーションストレージスペースに保存する際の、アプリケーションレイヤ（アプリレイヤ）と、ファイル配信コア（ＦＤＣ）レイヤと、ファイル配信ファイル管理（ＦＤＭ）レイヤとの間の例示的なデータフローおよび対話を示すフロー図。 ファイルバンドルから受信したファイルを削除するための一実施方法のプロセスフロー図。 ファイルバンドルから受信したファイルを削除することに関与する論理および例示的なデータフローを示すフロー図。 前に受信したファイルバンドルを受信する際の、アプリケーションレイヤ（アプリレイヤ）と、ファイル配信コア（ＦＤＣ）レイヤと、ファイル配信ファイル管理（ＦＤＭ）レイヤとの間の対話を表示する例示的なデータフローを示すフロー図。 ファイル配信コア（ＦＤＣ）とファイル配信ファイル管理（ＦＤＭ）レイヤとの間でデータを交換するために使用される様々なファイル配信コアペイロードフォーマットを示すデータ構造図。 別の例示的なファイル配信コアペイロードフォーマットを示すデータ構造図。 ２つの名前を有する単一のファイルである要素のための例示的なファイル配信コアペイロードフォーマットを示すデータ構造図。 ２つの名前を有するファイルを有するファイルバンドルである要素のための例示的なファイル配信コアペイロードフォーマットを示すデータ構造図。 ブロードキャストスケジュールメッセージを生成し、送信するための一実施方法のプロセスフロー図。 一実施形態による、複数のアプリケーションのためのファイルの取込みおよび受信を示すシステムブロック図。 一実施形態による、ファイルをファイル取込みシステムにサブミットするのに好適な例示的なデータスキーマの図。 一実施形態による、ファイルをファイル取込みシステムにサブミットするのに好適な例示的なデータスキーマの図。 一実施形態による、ファイル取込みシステムの一部としてのファイル送信スケジューリングを示すタイムライン図。 ファイルの送信のスケジューリングとファイル配信サービスが、ブロードキャストスケジュール内で、ファイル取込みシステムによって受信された新しい緊急ファイルに適応するために、どのように動的であり得るかを示すタイムライン図。 ファイルの送信のスケジューリングとファイル配信サービスが、ブロードキャストスケジュール内で、ファイル取込みシステムによって受信された新しい緊急ファイルに適応するために、どのように動的であり得るかを示すタイムライン図。 ファイルの送信のスケジューリングとファイル配信サービスが、ブロードキャストスケジュール内で、ファイル取込みシステムによって受信された新しい緊急ファイルに適応するために、どのように動的であり得るかを示すタイムライン図。 ファイルの送信のスケジューリングとファイル配信サービスが、ブロードキャストスケジュール内で、ファイル取込みシステムによって受信された新しい緊急ファイルに適応するために、どのように動的であり得るかを示すタイムライン図。 ファイル取込みシステムによるファイルの取込みが、ブロードキャストスケジュールメッセージの生成と、ブロードキャストスケジュールメッセージにおいて記載されているスケジュールされた時間における取り込まれたファイルの送信とにどのようにつながるかについての図。 ファイル取込みシステムによるファイルの取込みが、ブロードキャストスケジュールメッセージの生成と、ブロードキャストスケジュールメッセージにおいて記載されているスケジュールされた時間における取り込まれたファイルの送信とにどのようにつながるかについての図。 ブロードキャストファイル配信サービスを介して配信のためのファイルを取り込み、処理するための一実施方法のプロセスフロー図。 ワイドマルチプレックスとローカルマルチプレックスとからなる異なる信号マルチプレックスが、異なるローカルオペレーティングインフラストラクチャにおいてどのようにブロードキャストされ得るかを示す図。 一実施形態に従って、異なる容量のファイル配信パイプが、異なるワイドマルチプレックス信号においてどのように割り振られ得るかについての図。 ファイル配信送信が、異なる容量のファイル配信パイプ上でどのように送信され得るかを示す図。 ファイル配信送信が、異なる容量のファイル配信パイプ上でどのように送信され得るかを示す図。 一実施形態による、データ送信編成態様を示すタイムライン図。 ファイル配信送信が、異なるファイル配信パイプ上でどのように区分され、送信され得るかを示す図。 ファイル配信送信が、異なるファイル配信パイプ上でどのように区分され、送信され得るかを示す図。 ファイル配信送信が、異なるファイル配信パイプ上でどのように区分され、送信され得るかを示す図。 様々な実施形態による、データ送信編成詳細を示す追加のタイムライン図。 様々な実施形態による、データ送信編成詳細を示す追加のタイムライン図。 異なるファイルが並列ファイル配信パイプ上でのブロードキャストのためにどのようにスケジュールされ得るかを示す図。 ファイルがファイル配信パイプ内で送信され得る方法を示す図。 ファイルがファイル配信パイプ内で送信され得る方法を示す図。 ファイルがファイル配信パイプ内で送信され得る方法を示す図。 ファイル配信パイプ内の大きいファイルの送信が緊急ファイルの送信によってどのように中断され得るかを示す図。 ファイル配信パイプ内の大きいファイルの送信が緊急ファイルの送信によってどのように中断され得るかを示す図。 ファイル配信パイプを介してファイルをスケジュールし、送信するための実施方法のプロセスフロー図。 ファイル配信パイプを介してファイルをスケジュールし、送信するための実施方法のプロセスフロー図。 様々な実施形態とともに使用するのに好適なモバイル受信機デバイスのソフトウェアアーキテクチャ図。 受信機デバイス内で動作しているアプリケーションが、ファイル配信サービスモジュールによる受信のためのファイルをどのように指定し得るかについての図。 一実施形態による、ファイル配信カタログにおいて使用され得る例示的なデータスキーマの図。 ブロードキャストファイル配信サービスを介して配信されたファイルを受信するための、受信機デバイス内に実装され得る実施方法のプロセスフロー図。 ブロードキャストファイル配信サービスを介して配信されたファイルを受信するための、受信機デバイス内に実装され得る実施方法のプロセスフロー図。 一実施形態において使用するのに好適な受信機デバイスの構成要素ブロック図。 一実施形態において使用するのに好適なサーバデバイスの構成要素ブロック図。

様々な実施形態について添付の図面を参照しながら詳細に説明する。可能な場合はいつでも、同じまたは同様の部分を指すために図面全体にわたって同じ参照番号を使用する。特定の例および実装形態になされる言及は、説明のためであり、本発明の範囲または特許請求の範囲を限定するものではない。

「例示的」という単語は、本明細書では、「例、事例、または例示の働きをすること」を意味するために使用する。「例示的」として本明細書で説明するいかなる実施形態も、必ずしも他の実装形態よりも好ましいまたは有利であると解釈されるべきではない。

「モバイルデバイス」および「受信機デバイス」という用語は、本明細書では、モバイルメディアブロードキャスト受信機と、セルラー電話と、パーソナルテレビジョンデバイスと、個人情報端末（ＰＤＡ）と、パームトップコンピュータと、ワイヤレス電子メール受信機（たとえば、ＢｌａｃｋＢｅｒｒｙ（登録商標）およびＴｒｅｏ（登録商標）デバイス）と、マルチメディアインターネット対応セルラー電話（たとえば、ＢｌａｃｋＢｅｒｒｙ Ｓｔｏｒｍ（登録商標））と、全地球測位システム（ＧＰＳ）受信機と、ワイヤレスゲームコントローラと、車両（たとえば、自動車）内の受信機と、メディアＦＬＯ（ＭｅｄｉａＦＬＯ）のＦＬＯ ＴＶブロードキャストなどのモバイルＴＶブロードキャスト送信を受信し、処理するためのプログラマブルプロセッサおよびメモリおよび／または順方向リンク専用モバイルＴＶブロードキャスト受信機回路を含む同様のパーソナル電子デバイスとのうちのいずれか１つまたはすべてを指すために互換的に使用する。ただし、「モバイルデバイス」および「受信機デバイス」という用語は、受信機の列挙されたリストに限定されるべきではなく、モバイルブロードキャストテレビジョンサービスのいずれかを受信すること、および／または以下で説明するブロードキャスト規格のいずれかを実装することが可能な任意のデバイスを含み得る。

「ブロードキャスト」および「マルチキャスト」という単語は、本明細書では、データが多数の受信デバイスによって同時に受信され得るようなデータ（情報パケット）の送信を意味するために互換的に使用する。ブロードキャストメッセージの例は、コンテンツブロードキャスト（コンテンツフロー）とメタデータメッセージなどのオーバーヘッド情報ブロードキャスト（オーバーヘッドフロー）とを含むモバイルテレビジョンサービスブロードキャスト信号である。

本明細書で使用する「ファイル」という用語は、コンピューティングデバイスに記憶され得る多種多様なデータ構造、データの集合、およびデータベースファイルのうちのいずれかを指す。

本明細書および図面では、ブロードキャストスケジュールメッセージ（ＢＳＭ）、ブロードキャストスケジュール記録（ＢＳＲ：Broadcast Schedule Record）、ブロードキャストスケジュール期間（ＢＳＰ）、ブロードキャストスケジュールフロー（ＢＳＦ）、ブロードキャストスケジュール監視記録（ＢＳＭＲ：Broadcast Schedule Monitoring Record）、限定アクセスソリューション（ＣＡＳ：Conditional Access Solution）、固定ビットレート（ＣＢＲ：Constant Bit Rate）または可変ビットレート（ＶＢＲ：Variable Bit Rate）、ディレクトリ情報メッセージ（ＤＩＭ：Directory Information Message）、ＤＩＳＴ（構成されたレートでファイルとオーバーヘッドメッセージとを送信する配信構成要素）、ファイル配信フレームワーク（ＦＤＦ）、ファイル配信パイプ（ＦＤＰ）、ファイル取込みシステム（ＦＩＳ：File Ingestion System）、フローブロードキャストスケジュール記録（ＦＢＳＲ：Flow Broadcast Schedule Record）、前方誤り訂正（ＦＥＣ：Forward Error Correcting）コード、ＦＬＯサービングノードまたはＦＳＮ（特定のトランスポート技術への適応を行う、ＦＬＯではトランスポートネットワーク固有ＦＳＮであり得、または他のブロードキャスト技術では概してＢＳＮであり得る、実際のＯＴＡ送信に関与する構成要素）、初期収集フロー（ＩＡＦ）、ＩＰデータサービス（ＩＰＤＳ：IP Data Service）、ローカルマルチプレックス（ＬＭ：Local Multiplex）、ローカルオペレーティングインフラストラクチャ（ＬＯＩ：Local Operating Infrastructure）、サービス品質（ＱｏＳ：Quality of Service）、オーバーヘッドスケジューリングサーバまたはＯＳＳ（オーバーヘッドメッセージ、メタデータおよび／またはバージョン変更を管理し、広告する構成要素）、無線周波数（ＲＦ：Radio Frequency）、リアルタイム（ＲＴ：Real Time）、タイプ−値−長さ（ＴＬＶ：Type-Value-Lengt
h）、ビデオオンデマンド（ＶＯＤ：Video-On-Demand）アプリケーション（ｖｏｄＡｐｐ）、およびワイドマルチプレックス（ＷＭ：Wide Multiplex）という用語および略語を使用する。

そのすべてが様々な実施形態を実装し、そこから利益を得ることがある、いくつかの異なるモバイルブロードキャストテレビジョンサービスおよびブロードキャスト規格が利用可能であるかまたは将来企図される。そのようなサービスおよび規格は、たとえば、オープン・モバイル・アライアンス・モバイル・ブロードキャスト・サービス・イネイブラー・スイート（ＯＭＡ ＢＣＡＳＴ：Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ Ｍｏｂｉｌｅ Ｂｒｏａｄｃａｓｔ Ｓｅｒｖｉｃｅｓ Ｅｎａｂｌｅｒ Ｓｕｉｔｅ）、ＭｅｄｉａＦＬＯ、デジタル・ビデオ・ブロードキャスト・アイピー・データキャスティング（ＤＶＢ−ＩＰＤＣ：Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔ ＩＰ Ｄａｔａｃａｓｔｉｎｇ）、デジタル・ビデオ・ブロードキャスチング−ハンドヘルド（ＤＶＢ−Ｈ：Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｈａｎｄｈｅｌｄ）、デジタル・ブロードキャスティング−ハンドヘルドに対するサテライト・サービス（ＤＶＢ−ＳＨ：Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｓａｔｅｌｌｉｔｅ ｓｅｒｖｉｃｅｓ ｔｏ Ｈａｎｄｈｅｌｄｓ）、デジタル・ビデオ・ブロードキャスチング−ハンドヘルド２（ＤＶＢ−Ｈ２：Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｈａｎｄｈｅｌｄ ２）、アドバンスド・テレビジョン・スステム委員会−モバイル／ハンドヘルド（ＡＴＳＣ−Ｍ／Ｈ：Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍｓ Ｃｏｍｍｉｔｔｅｅ−Ｍｏｂｉｌｅ／Ｈａｎｄｈｅｌｄ）、および中国マルチメディア・モバイル・ブロードキャスティング（ＣＭＭＢ：Ｃｈｉｎａ Ｍｕｌｔｉｍｅｄｉａ Ｍｏｂｉｌｅ Ｂｒｏａｄｃａｓｔｉｎｇ）を含む。これらのブロードキャストフォーマットの各々はブロードキャスト通信チャネルに関与する。参照しやすいように、様々な実施形態について、ＦＬＯ ＴＶブロードキャストシステムにおいて実装されるＭｅｄｉａＦＬＯシステムに関して説明する。ただし、ＭｅｄｉａＦＬＯ用語および技術的詳細への言及は説明のためにすぎず、請求項の文言に明記されていない限り、特許請求の範囲を特定のＦＬＯ通信システムまたは技術に限定するものではない。

様々な実施形態は、ブロードキャストシステム上でモバイルデバイスにファイルを効率的に配信するための機構およびシステムを与える。ブロードキャストおよび受信のためのファイルは、ファイルシステムにおけるディレクトリに属するものとして論理的に識別され得る。受信機デバイスへのファイルのブロードキャストのためにこのファイルシステム抽象化をバッテリー効率良く利用するために、ブロードキャストシステムは、ダウンロードのために利用可能なファイルと、これらのファイルがブロードキャストされるべき時間とに関する情報を搬送するための機構を使用し得る。様々な実施形態では、これは、ファイルのブロードキャストより前に、またはそれとともに、ブロードキャストスケジュールメッセージ（ＢＳＭ）をブロードキャストすることによって達成され得る。

概して、ＢＳＭは、将来ブロードキャストされることになるファイルを、ならびにそれらのファイルがブロードキャストされることを受信機デバイスが予想することができる特定の時間フレームを、受信機デバイスに通知する。各ＢＳＭは、様々なサービスまたはアプリケーションとの、ブロードキャストされているファイルの関連付け（たとえば、アプリケーション固有ディレクトリ上のサービスＩＤまたはファイル名）、ブロードキャストされているファイルが新しいファイルであるのか、更新されたファイルであるのか、反復ファイルであるのかについての識別情報（たとえば、ファイルＩＤ／要素ＩＤまたはバージョン番号）、ファイルが受信され得るブロードキャストトランスポートストリーム（たとえば、ＩＰアドレスとＵＤＰポート番号とによって識別されるフローＩＤ、ＩＰフロー）、ファイルがブロードキャストされることになる時間（たとえば、配信ウィンドウ）、および配信スケジュール情報（たとえば、ＢＳＭ）が新しい情報でいつ更新され得るかなど、ファイルコンテンツおよびブロードキャストスケジュール情報を含み得る。

ＢＳＭは、所与の周波数（たとえば、チャネル５５）上で、その周波数における送信スペクトルの一部分（たとえば、ＭｅｄｉａＦＬＯローカルマルチプレックス対ワイドマルチプレックス）上で、および／またはトランスポート技術（たとえば、ＭｅｄｉａＦＬＯまたはＡＴＳＣ）について、ブロードキャストされるファイルについての配信スケジュール情報を与える（たとえば、フローＩＤ、ＩＰアドレスおよびＵＤＰポート番号などによって定義された）オーバーヘッドトランスポートストリームの一部として搬送され得る。これらのオーバーヘッドフローの利用可能性と、そのような送信のために使用されるチャネル、フローまたは周波数と、ＢＳＭがブロードキャストされる信号の部分またはスーパーフレームと、ＢＳＭを送信するために使用されるトランスポート技術は、ブートストラップオーバーヘッドフロー（たとえば、ＭｅｄｉａＦＬＯ送信におけるＩＡＦ）を介して発見され得る。

本実施形態に従って構成された受信機デバイスは、広告されている異なるファイルブロードキャストからファイルを選択するためにＢＳＭメッセージを利用し得る。受信機デバイスは、ファイルが関連付けられたサービスまたはアプリケーションに基づいて、ファイルが新しいのか、再送信であるのか、前に受信したファイルの更新であるのかに基づいて、あるいは様々な他のファクタに基づいて、特定のファイルを受信するためにＢＳＭを使用し得る。様々な実施形態では、ＢＳＭは、アプリケーション／サービスＩＤのエイリアシングの、および／またはファイルのバンドルをトランスポートすることについての、記述をサポートし得る。様々な実施形態では、各ＢＳＭは、一度にブロードキャストスケジュール情報の一部分のみを広告し得る。これは、コンテンツフレッシュネスと、ＢＳＭの最新のバージョンを用いて最新のままであるために受信機デバイスが消費しなければならないバッテリー電力の量との間のトレードオフを与える。

様々な実施形態は、ブロードキャストネットワーク内の、またはそれと通信している、ファイル取込みシステム（ＦＩＳ）を含み得、これは、コンテンツプロバイダが、ブロードキャストすべき新しいファイルをブロードキャストシステムに通知するために使用することができる、インターフェースを与え得る。コンテンツプロバイダは、各ファイルの適時性要求（たとえば、レイテンシ許容差）および送信ロバストネス要求（たとえば、前方誤り訂正のレベルまたは再送信の数）など、ファイルについてのブロードキャストトランスポート要求を指定するためにファイル取込みシステムを使用し得る。ファイル取込みシステムは、新しいファイル取込みのときにコンテンツプロバイダによって指定されたトランスポート要求を使用し、送信のためにすでに受け入れられスケジュールされたファイルとともに新しいファイルをブロードキャスト送信ストリームにパックすることを試み得る。様々な実施形態では、新しいファイルをブロードキャスト送信ストリームにパックすることが成功しなかった（すなわち、新しいファイルが、送信のためにすでにスケジュールされたファイルとともに送信ストリーム内に収まり得ない）とき、ファイル取込みは失敗したと見なされ得る。様々な実施形態では、ファイル取込みシステムは、パックすることが初めに成功しなかったとき、前に取り込まれたファイルの送信を抑制するという犠牲を払って新しいファイル取込みが成功することになるように、複数のファイルにわたって優先度を考慮し得る。

新しいファイルがファイル取込みシステムによって処理されると、ファイル取込みシステムは、ブロードキャストスケジュール期間（ＢＳＰ）にわたって正常にスケジュールされたファイルの一部分のみを広告するＢＳＭを生成し得る。受信機デバイスは、ファイルブロードキャストの受信機デバイスの受信を計画するためにＢＳＭ中の情報を使用し得る。したがって、受信機デバイスは、デバイス上のアプリケーションにとって関係があるファイルがブロードキャストされることになると判断すると、広告されたブロードキャストスケジュール期間の間に受信機回路のアクティベーションをスケジュールすることができる。正常にスケジュールされたファイルの一部分のみを広告することによって、新しいファイル取込みは、最後にブロードキャストされたＢＳＭによってカバーされる時間期間に続いてブロードキャストスケジュール中に新しいファイルを挿入することと、修正されたスケジュールを用いて新しいＢＳＭをブロードキャストすることとによって適応され得る。様々な実施形態では、ブロードキャストシステムは、既存のスケジュール情報に基づいてＢＳＭの更新とファイルの送信とを制御し得る。

上記で説明したように、所与の時間に、ＢＳＭは、ブロードキャストスケジュール情報の一部分のみを広告し得る。これは、一方ではコンテンツのフレッシュネスおよびスケジューリングフレキシビリティと、他方では受信機デバイスによる電力消費量との間のトレードオフを与える。コンテンツフレッシュネスは、各ＢＳＭ中のブロードキャストスケジュール情報の量を制限することによって最大にされ得る。これにより、新たに取り込まれたファイルを挿入するためにブロードキャストスケジュールのより大きい部分（すなわち、ＢＳＭにおいて告知されなかった部分）が調整され得るので、より大きいファイル送信スケジューリングフレキシビリティが可能になる。ＢＳＭが頻繁に変化することを可能にすることによって、放送事業者は、より短い通知を用いてファイルをブロードキャストし、ファイル配信優先度およびスケジュールの変化に適応し得る。しかしながら、ＢＳＭを頻繁に変更することは、受信機デバイスが新しいＢＳＭを受信するためにより頻繁に電源投入することを必要とする。各電源投入は、受信機デバイスのバッテリー電力のさらなる量を消費する。したがって、ＢＳＭの頻繁な更新により、受信機デバイスはより多くのバッテリー電力を消費し得る。したがって、受信機デバイスによる電力消費量は、各ＢＳＭにおいて対処されるブロードキャストスケジュールの量を最大にすることによって最小限に抑えられ得る。したがって、放送事業者は、ユーザエクスペリエンスを向上させるために、スケジューリングフレキシビリティとデバイス電力消費量との間で、ＢＳＭの更新の頻度のバランスをとり得る。

また、ファイル取込みシステムは、ファイルに関連付けられた属性の取込みをサポートし得る。ファイル取込みシステムは、ファイル属性がオーバーヘッドメッセージ（たとえば、ＢＳＭ）を介して搬送され得るようにファイル属性をフォーマットし得る。様々な実施形態では、受信機デバイスは、受信およびダウンロードのためのファイルを選択するためにこれらのファイル属性を使用し得る。様々な実施形態では、受信機デバイスは、それらのファイル属性に基づいてファイルを選択するためにフィルタ処理基準を使用し得る。

様々な実施形態では、ファイル取込みシステムは、一度に２つ以上のファイルを取り込むことをサポートし得る。これらの実施形態では、ファイル取込みシステムは、単一のファイルとしての送信のために、またはより大きいファイルのより小さいセットとしての送信のために、２つ以上のファイルを互いにバンドルし得る。ファイルが互いにバンドルされ得ない場合、ファイル取込みシステムは、送信のために各ファイルを独立してスケジュールし得る。ファイルを互いにバンドルすることは、前方誤り訂正（ＦＥＣ）保護のより効率的な適用を可能にし、送信されるファイル内に含まれているデータの完全性を改善する。

様々な実施形態では、ブロードキャストリソース（たとえば、ブロードキャスト信号の帯域幅またはセグメント）が、システムの総合効率およびリソース予約目標を改善するためのトラフィックエンジニアリングツールとしてファイル配信「パイプ」に編成され得る（たとえば、小さいファイルのためのパイプおよび大きいファイルのためのパイプ）。ファイル配信パイプは、ファイルトランスポートのためのリソース割振りをキャプチャし、いくつかの異なるファイルを１つまたは複数の送信ストリーム上に多重化することをサポートする。ブロードキャストリソースをファイル配信パイプに編成することは、アグリゲート割振りリソース上でファイルを時分割多重化する、ファイルの集中型スケジューリングを可能にすることによって、効率を改善し得る。したがって、リソースが編成される方法は、効率的であり、異なるファイル配信アプリケーションに関連付けられた異なる要求に対処すべきである。様々な実施形態では、リソースは複数のファイル配信パイプに編成され得、ファイル取込みシステムは、ブロードキャストシステムにおいて定義された様々なファイル配信パイプを通知され得る。そのように通知されると、ファイル取込みシステムは、各ファイルについて指定されたアプリケーション固有配信要求に対処するような形で、および異なるパイプ（たとえば、大きいファイルの転送中に小さいファイルのヘッドオブラインブロッキングを回避するための小さいファイルのためのパイプおよび大きいファイルのためのパイプ）のセットアップを薦めていることがあるトラフィックエンジニアリング目標に従って、送信リソース上でのブロードキャストのためにファイルをスケジュールし得る。

様々な実施形態は、ファイル配信パイプを定義することと、異なるパイプ上での送信のためにファイルをスケジュールすることとを行うための様々なストラテジを実装することをサポートする。たとえば、様々な実施形態では、アプリケーションのクラスは特定のパイプにマッピングされ得、たとえば、低レイテンシ要求がある小さいファイルは専用パイプ上でブロードキャストされ得る。様々な実施形態では、ファイル取込みシステムは、短いファイルの送信を可能にするために大きいファイルの送信を独立ブロードキャストウィンドウに分割し得る。様々な実施形態では、ファイル取込みシステムは、異なるフローを介して同じパイプ上での複数の同時ファイル送信をスケジュールし得る。

様々な実施形態では、ブロードキャスト側アプリケーションまたはサービスは、トランスポートに好適である１つまたは複数のファイルへのアセンブリのために多数のファイルをファイル取込みシステムにサブミットし得る。対応する受信機側アプリケーションまたはサービスは、ブロードキャストされているファイルの小さいサブセットのみに適合するか、またはそれに関係していることがある。この場合、ブロードキャスト側アプリケーションまたはサービスは、受信機側アプリケーションまたはサービスによって使用され得る識別メタデータを含むＢＳＭまたは同様のオーバーヘッドファイル（たとえば、カタログファイル）をシステムが構築することを可能にするために、適用性メタデータをファイル配信サービスに供給し得る。たとえば、ＢＳＭオーバーヘッドファイルは、ブロードキャストされるべきファイルについての識別または適用性情報とともに、ブロードキャスト期間内にブロードキャストされることになるファイルのすべてを記載し得る。そのような識別メタデータは、ファイルを受信することができるかまたは受信すべきであるアプリケーションまたはサービスの名前または識別子など、アプリケーション固有属性を含み得る。受信機デバイス上で、ＢＳＭオーバーヘッドファイルは、受信機デバイスによって受信され、対応する受信機側アプリケーションによって受信のためのファイルを選択するために使用され得る。様々な実施形態では、受信機側アプリケーションは、様々なアプリケーション固有論理および利用可能な属性に基づいて、およびＢＳＭオーバーヘッドファイル中に含まれている識別または適用性情報を使用することによって、この選択を行い得る。

様々な実施形態では、受信機側アプリケーションは、所望のアプリケーションまたはサービスファイル名、あるいは所望のファイルについての識別子を受信機デバイス上のファイル配信サービスモジュールに示すことによって、ファイル配信サービスからの、ＢＳＭにおいて記述された選択されたファイルの受信を要求し得る。受信機デバイス上のファイル配信サービスモジュールは、所望のファイルを含んでいる示されたファイルが、いつ、およびどのチャネル／フロー／ブロードキャストリソース上でブロードキャストされるべきかをＢＳＭから判断し得る。受信機デバイス中のプロセッサは、ブロードキャストが、受信機側アプリケーションによって要求されたファイル、または受信機側アプリケーションに適合するファイルを含んでいる可能性があるときのみ受信機回路を「起動する」ためにこの情報を使用し得る。ＢＳＭ中の情報により、受信機デバイス上のプロセッサは、受信機がオンでありデータをリッスンしている必要がある厳密な時間フレームを特定することも可能になり得る。受信機がオンである必要がある厳密な時間フレームを特定することによって、受信機デバイスは、他のタスクのために処理リソースを利用可能にしながら、かなりのバッテリー電力を温存し得る。

様々な実施形態では、ファイル配信サービス（たとえば、ＦＤＦサービス）を使用するブロードキャスト側アプリケーションは、ファイルがトランスポートのためにファイル取込みシステムにサブミットされるときに、ファイルに関連付けられたアプリケーション固有属性を与え得る。そのようなアプリケーション固有属性はＢＳＭを介して受信機デバイスにトランスポートされ得る。受信機側アプリケーションは、関係があるファイルを特徴づけるアプリケーション固有パラメータ内の正規表現または論理表現を示すことによって、受信機デバイスのファイル配信サービスモジュールからのファイルキャプチャを要求し得る。関係があるファイルを特徴づけるための正規表現または論理表現を使用することによって、受信機デバイスは、受信のためのファイルを選択するためのフィルタ処理基準としてアプリケーション固有パラメータを使用し得る。受信機デバイスのファイル配信サービスモジュールは、所望のファイルの特性（日／時間、フローＩＤなど）をＢＳＭから識別することによって、ブロードキャストされているファイルのサブセットのみを受信するために、そのようなフィルタ処理基準を使用し得る。

様々な実施形態は、図１にその一例を示す様々なモバイルマルチメディアブロードキャストシステム内に実装され得る。ＭｅｄｉａＦＬＯブロードキャストネットワークなどのモバイルマルチメディアブロードキャストネットワーク１は、一般に、本明細書ではブロードキャストオペレーションセンター４（または図では「ＢＯＣ」）と呼ぶモバイルブロードキャストネットワーク制御センターによって制御される複数のブロードキャスト送信機２を含む。ブロードキャストネットワーク１は、ブロードキャスト送信機２から、モバイルテレビジョン受信機、スマートフォン、セルラー電話、携帯情報端末（ＰＤＡ）、双方向ゲームデバイス、ノートブック、スマートブック、ネットブック、データ処理装置、または他のそのような電子デバイスなどの受信機デバイス１０が受信するためのモバイルブロードキャスト送信３としてコンテンツをブロードキャストする。（ブロードキャストオペレーションセンターまたは「ＢＯＣ」とも呼ばれる）モバイルブロードキャストネットワーク制御センター４内には、一般に、リアルタイムコンテンツブロードキャストと、コンテンツブロードキャストに関する電子サービスガイド、カタログメッセージ、およびＢＳＭの生成と、マルチメディアブロードキャストネットワーク１のオーバーヘッドフローを介したブロードキャストのためのメタデータメッセージの生成とを管理するための１つまたは複数のサーバおよびシステムがあることになる。

通常のコンテンツ配信システムに加えて、モバイルブロードキャストネットワーク１は、モバイルブロードキャストネットワーク１を介したブロードキャストのためにファイルを受信し、記憶し、スケジュールし、およびフォーマットするためのファイル取込みシステムサーバ（ＦＩＳ）３１をも含み得る。ファイル取込みシステムサーバ３１は、直接ネットワーク接続、またはインターネット７などの間接的ネットワーク接続のいずれかを介してファイルコンテンツプロバイダ９からブロードキャストのためのファイルを受信し得る。

モバイルマルチメディアブロードキャストネットワーク１に加えて、受信機デバイス１０はまた、一般に、セルラー電話ネットワークなどのユニキャストネットワーク１１を介して通信するように構成されることになる。典型的なセルラー電話ネットワークは、固定電話線（たとえば、ＰＯＴＳネットワーク、図示せず）やインターネット７などを介して、モバイルデバイス１０と他のネットワーク宛先との間のボイスおよびデータ呼を接続するように動作する、ネットワークオペレーションズセンター１４に結合された複数のセルラー基地局１２を含む。受信機デバイス１０とユニキャストネットワーク１１との間の通信は、４Ｇ、３Ｇ、ＣＤＭＡ、ＴＤＭＡ、および他のセルラー電話通信技術などの双方向ワイヤレス通信リンク１３を介して達成される。インターネットデータ通信を可能にするために、ユニキャストネットワーク１１は、一般に、インターネット７への接続を与える、ネットワークオペレーションズセンター１４に結合されたまたはその内部の１つまたは複数のサーバ１６を含むことになる。さらなる実施形態では、ユニキャストネットワーク１１は、ＷｉＦｉ、ＷｉＭＡＸなどのワイヤレスワイドエリアネットワークであり得る。受信機デバイス１０は、ブロードキャストサービスにサブスクライブすることと、ユーザ対話メッセージを放送事業者に送信することとを行うために、インターネット７を経由したブロードキャストネットワークサーバ６へのＩＰデータ呼を介してなど、ユニキャストネットワーク１１を介してブロードキャストネットワーク１と通信し得る。

図２に、一実施形態によるブロードキャストネットワーク１（たとえば、ＭｅｄｉａＦＬＯブロードキャストネットワーク）の一部分内の情報フローを示す。ファイルコンテンツプロバイダ９は、ブロードキャストファイル配信サービスを介した送信のためのファイルをファイル取込みサーバ３１に与え得る。ファイル取込みサーバ３１は、以下でより十分に説明するように、ブロードキャストのためにそれらのファイルをスケジュールし、記憶し得る。スケジュールブロードキャスト時間に、ファイル取込みサーバ３１は、スケジュールされたファイルをブロードキャストオペレーションセンター４（ＢＯＣ）に与え得、そこで、コンテンツフロー２６とオーバーヘッドフロー２８とを含む情報のマルチプレックスとしてブロードキャスト信号が生成される。したがって、ファイル配信サービスを介した送信のためのファイルはコンテンツフロー２６の一部として送信され得、ＢＳＭは１つまたは複数のオーバーヘッドフロー２８の一部として送信される。受信機デバイス１０は、マルチプレックス信号を受信し、また、ＢＳＭを含むオーバーヘッドフロー２８と他のオーバーヘッド情報ストリーム（たとえば、制御チャネル）とを別個に受信することと、コンテンツフロー２６から特定のファイルを受信するためにＢＳＭ中の情報を使用することとが可能である。

典型的なマルチメディアモバイルブロードキャストシステムでは、情報は、複数のスーパーフレームに編成されたワイヤレス信号中で送信される。各スーパーフレームは、ブロードキャストコンテンツとオーバーヘッド情報とを通信する複数のデータパケットを符号化する、ある周波数帯域内の周波数と設定された時間境界（たとえば、スーパーフレーム境界）内の時間とに関して編成された複数の信号を備える。たとえば、ＭｅｄｉａＦＬＯブロードキャストシステムでは、ブロードキャスト送信は、６ＭＨｚ周波数帯域（たとえば、７１６ＭＨｚ〜７２２ＭＨｚ）にわたる１秒スーパーフレームに編成される。ＭｅｄｉａＦＬＯブロードキャスト信号は他の周波数帯域上で送られ得、複数の信号は、複数の別個の周波数帯域を使用することによって同時に送られ得る。各スーパーフレームは、オーバーヘッドフローに専用の部分と、コンテンツフローに関連付けられた複数のチャネルを搬送する部分とを含み得る。上述のように、オーバーヘッドフローおよび他のオーバーヘッドストリーム（たとえば、制御チャネル）内の情報は、その特定のコンテンツフローがスーパーフレーム内のどこで取得され得るか、ならびにいくつのパケットがそのコンテンツフローのストリームに関連付けられるかを受信機デバイスに知らせる。

図３に、ファイル配信サービスを介してファイルを配信するための様々な実施形態を実装するのに好適なブロードキャスト通信システムの放送事業者側のシステム機能構成要素を示す。リアルタイムコンテンツプロバイダサーバ８は、リアルタイムコンテンツ（たとえば、オーディオ、ビデオ、テキストなど）をブロードキャストオペレーションセンター４内のリアルタイムエンコーダ３９に送り得る。ファイルコンテンツプロバイダ９は、ファイル配信サービスを介した配信のためのファイルをファイル取込みサーバ３１に与え得る。ファイル取込みサーバ３１は、受信したファイルをローカルデータベース３２に記憶し、受信したファイルをブロードキャストのためにスケジュールし得る。スケジュールされたブロードキャスト時間に関する情報、ならびにファイル属性データは、ＢＳＭにおいてオーバーヘッドバージョン変更を管理および広告する構成要素であるオーバーヘッドシグナリングサーバ（ＯＳＳ：overhead signaling server）３４に与えられ得る。以下でより十分に説明するように、ファイル取込みサーバ３１によるファイルの取込みと、ファイルの送信のスケジューリングは、スケジュールされたブロードキャスト時間の頻繁な変更がオーバーヘッドシグナリングサーバ３４に通信され得るように、動的であり得る。

オーバーヘッドシグナリングサーバ３４は、構成されたレートでファイルとオーバーヘッドメッセージとを送信する構成要素である配信サーバ３３に更新されたＢＳＭを与え得る。配信サーバ３３は、送信のためのＢＳＭを順方向リンク専用（ＦＬＯ：forward link only）サービスノード（ＦＳＮ）３５に与え得、ＦＬＯサービスノード３５は、ブロードキャストネットワーク１を介した送信のためにＢＳＭをオーバーヘッドデータ配信システム３６に向ける。ファイルを送信するためのスケジュールされた時間の近くで、ファイル取込みサーバ３１は、ローカルデータベース３２とともに、送信のためのファイルを配信サーバ３３に与え得る。配信サーバ３３は、各ファイルがいつブロードキャストされるべきかを指定する制御データとともに、それらのファイルをＦＬＯサービスノード３５に与え得る。ＦＬＯサービスノード３５は、送信のためのファイルをファイル配信システム３８に配信し得、ファイル配信システム３８は、ブロードキャストネットワーク１を介してそれらのファイルを送信する。次いで、モバイルデバイス１０は、ワイヤレスデータ送信を介してブロードキャストネットワーク１からファイルを受信し得る。

図３は、ファイル配信システムの構成要素を別個のユニットまたはサーバとして示しているが、単一のサーバまたは図３に示すよりも少数のサーバ内に異なる機能的プロセスの一部または全部が実装され得ることを当業者なら諒解されよう。たとえば、オーバーヘッドサービスサーバ３４、配信サーバ３３およびフローサービスノード３５は、ファイル取込みシステム３１とともに単一のサーバデバイス内に実装され得、これらの機能の各々は、異なるソフトウェアモジュールまたは統合ソフトウェアシステムによって達成される。

様々な実施形態の一例として、図４に、ＭｅｄｉａＦＬＯファイル配信フレームワーク（ＦＤＦ）４０に関与するトップレベル構成要素を示す。ファイル配信フレームワーク４０は、異なるファイル配信アプリケーションのためのサポートを同時に与え得る。論理概念の形態のファイルの配信は、ファイルが、コンテンツプロバイダから受信され、ブロードキャストシステムを介して送信され、受信機デバイスによって受信されるとき、ファイルの操作および管理のために使用される、実施方法に関与する。ハイレベルでは、ブロードキャストファイル配信システム４０は、通信システムのブロードキャスト側であるヘッドエンドと、送信されたファイルを選択的に受信し、記憶する受信機デバイスとを備える。

ヘッドエンドでは、本明細書では「ヘッドエンドアプリ」４２、４３と呼ぶ、送信のためのファイルを与えるアプリケーションが、配信のためのファイルを定義する。ヘッドエンドにおけるサーバ内で、ファイル取込みシステム３１は、ファイルコンテンツプロバイダまたはヘッドエンドアプリ４２、４３からトランスポートのためのファイルを受信し、ブロードキャストスケジュールにおいて配信のためにそれらのファイルをスケジュールし得る。ファイル取込みシステム３１はまた、ファイルトランスポートネットワーク４１上での後のトランスポートのために、正常にスケジュールされたファイルをメモリに記憶し得る。ヘッドエンドアプリ４２、４３によって与えられたファイルは１つまたは複数のトランスポートファイルにパッケージングされて、ファイル取込みシステム３１を介して取り込まれ、ファイルトランスポートネットワーク４１を介して受信機デバイスに配信され得る。

ＭｅｄｉａＦＬＯ受信機デバイスなどの受信機デバイス上では、デバイスアプリケーション４５、４６が、受信されるべきであるファイルを特徴づけるかまたは識別し、それらのファイルをファイル配信サービスモジュール４４に要求し得る。ファイル配信サービスモジュール４４は、デバイスアプリケーション４５、４６にファイルキャプチャサービスを与えるように構成されたソフトウェアとして受信機デバイスにおいて実装され得る。ファイル配信サービスモジュール４４は、ファイルについての要求に応答して、配信およびスケジューリング情報を使用して、要求されたフローをキャプチャし、それらをメモリに記憶し得る。ファイル配信サービスモジュール４４は、ファイルの受信、記憶および維持を管理し得る。

送信されるべきファイルをアセンブルする際に、ファイル取込みシステム３１はファイルシステムアナロジーを使用してトランスポートファイルを作成し得、その場合、アプリケーション固有ディレクトリ構造におけるファイルパス名が、アプリケーションのセットのためのファイルを一意に識別する。上記で説明したように、ブロードキャストシステムのヘッドエンドにおけるサーバ内で、ファイル取込みシステム３１は、トランスポートのためのファイルを受信することと、ブロードキャストスケジュールにおいて配信機会のためにそれらのファイルをスケジュールすることと、ブロードキャストネットワークのファイルトランスポートネットワーク４１上での後のトランスポートのために、正常にスケジュールされたファイルをメモリに記憶することとを行うために与えられ得る。ファイル取込みシステム３１は、ファイル名、ファイルを記述するパラメータ（たとえば、ジャンル、ファイルタイプなど）、ファイルコンテンツを記述するパラメータ（たとえば、個々のデータグラムパケットのソースおよびロケーション、ファイル中に含まれるデータグラムパケットの識別情報、アプリケーションまたはファイルタイプなど）、およびトランスポートのためのファイルのコンテンツに関連付けられた他の情報など、ファイルに関する追加の属性を指定し得る。ファイル取込みシステム３１は、各ファイルのブロードキャスト配信要求を記述するパラメータをも指定し得る。様々な実施形態では、ファイル取込みシステム３１は、バージョニング目的で使用され得る、および前方誤り訂正（ＦＥＣ）コードの効率的な適用のために、サブミットされたファイルを組み合わせられたパッケージにバンドルするために使用され得る、一意の識別子（たとえば、ｆｉｌｅＩＤ）をファイルに割り当て得る。ファイル取込みシステム３１はまた、取り込まれたファイルのブロードキャストトランスポート信頼性を改善するために前方誤り訂正コードを取り込まれたファイルに適用し得る。

一実施形態では、ファイル取込みシステム３１は、トランスポートのための新たに受信したファイルのためのブロードキャスト配信機会をスケジュールし得る。このプロセスの一部として、ファイル取込みシステム３１は、様々なパラメータに基づいて送信スケジュールを判断し得る。たとえば、一実施形態では、ファイル取込みシステム３１は、ファイルサイズと利用可能なリソースとに応じて送信スケジュールを作成し得る。また、別の実施形態では、送信スケジュールは、コンテンツプロバイダによってファイルに割り当てられた優先度を考慮に入れ得る。様々な実施形態では、ファイルブロードキャスト時間のスケジューリングは、新たに受信したファイルと前に取り込まれたファイルとについてのブロードキャスト配信要求が満たされるように、送信のための開始時間を判断するためにアルゴリズム的に達成され得る。ファイル取込みシステム３１は、ファイルトランスポートネットワーク４１上での後のトランスポートのために、正常にスケジュールされたファイルを記憶し得る。ファイル取込みシステム３１は、適切な時間に、ファイル取込みシステム３１によって前に判断されたファイルスケジュール情報に従って、スケジュールされたファイルをブロードキャストネットワークにディスパッチし得る。

送信のためにファイルをスケジュールする際に、ファイル取込みシステム３１は、ファイルトランスポートネットワーク４１において定義されたファイル配信パイプなどの送信リソースに気づいていることがある。ファイル配信パイプの利用可能性に関する情報を使用して、ファイル取込みシステム３１は、ファイルコンテンツプロバイダによって定義されたアプリケーション固有配信要求に対処するように様々な送信リソース上でファイルをスケジュールし得る。いくつかの実施形態では、ファイル取込みシステム３１は、アプリケーションのいくつかのクラスのために特定のパイプを使用するように構成され得る。たとえば、低レイテンシ要求がある小さいファイルは、専用送信パイプ上でブロードキャストされ得る。代替的に、ファイル取込みシステム３１は、低減された遅延とともに短いファイルの送信を可能にするために大きいファイルの送信を独立ブロードキャストウィンドウに分割し得る。ファイル取込みシステム３１はまた、異なる送信パイプを介して同じタイプの複数の同時送信をスケジュールし得る。

様々な実施形態では、ファイルトランスポートネットワーク４１は、ＭｅｄｉａＦＬＯネットワークまたは他のブロードキャストネットワークであり得る。様々な実施形態では、ファイルトランスポートネットワーク４１は、ブロードキャストネットワークとユニキャストネットワークの組合せであり得る。トランスポートネットワークがブロードキャストネットワークであるとき、ファイル送信は、送信されている異なるファイルのすべてにわたってブロードキャストチャネルが効果的に共有され得るように、スケジュールされ得る。さらに、ブロードキャストチャネルが複数のメディアストリームを同時にサポートすることができる場合、データファイルの送信は複数のメディアストリームのうちの１つに関連付けられ得る。

ファイル配信フレームワーク４０の一部として、一連のＢＳＭが、ブロードキャストトランスポートネットワークにおいて利用可能であるオーバーヘッドメッセージフローにおいてブロードキャストされ得る。上記で説明したように、ＢＳＭは、受信機デバイスが、ブロードキャストされているファイルを特定のサービスまたはアプリケーションに関連付けることを可能にする、情報を与え得る。ＢＳＭはまた、ブロードキャストされているファイルに関するファイルＩＤ／要素ＩＤまたはバージョン情報と、ファイルが受信され得るトランスポートストリームに関する情報と、ファイルがいつブロードキャストされることになるかに関する情報（たとえば、配信ウィンドウ）と、配信スケジュールまたはＢＳＭが新しい情報でいつ更新されることになるかに関する情報とを含み得る。

上記で説明したように、ブロードキャストおよび受信のためのファイルは、ファイルシステムにおけるディレクトリに属するものとして論理的に識別され得る。様々な実施形態では、このファイルシステム抽象化により、ファイルをアプリケーション固有ディレクトリ構造に属するものとして定義することが可能になり、アプリケーション固有ディレクトリ構造では、ルート（最上位の）ディレクトリがアプリケーションを識別する。たとえば、アプリケーションｔｅｓｔＡｐｐに属するファイルｔｅｓｔＦｉｌｅは「／ｔｅｓｔＡｐｐ／ｔｅｓｔＦｉｌｅ」として定義され得る。様々な実施形態では、ファイルは、ファイルの意味論的性質を記述するための機構としてサブディレクトリにおいてさらに編成され得る。たとえば、ファイルは、ファイルのコンテンツとブロードキャストチャネル（たとえば、ＣＮＮ、ＡＢＣなど）との間の関連付けに基づいて編成され得る。したがって、ビデオオンデマンドアプリケーション（ｖｏｄＡｐｐ）についてのファイルは、／ｖｏｄＡｐｐ／ＣＮＮ／または／ｖｏｄＡｐｐ／ＡＢＣ／など、アプリケーション固有ディレクトリに属するものとして編成され得る。

ファイルシステム抽象化のさらなる一例として、天気アプリケーション（ｗｅａＡｐｐ）は、特定の都市に関連付けられたファイルを識別するサブフォルダを用いて、都市ごとに天気の更新に関するファイルを編成し得る。たとえば、「／ｗｅａＡｐｐ／ＬＡ／」という句を含むファイル名は、ロサンゼルスについての天気の更新に関するファイルを含み得、「／ｗｅａＡｐｐ／ＮＹ／」という句を含むトランスポートファイル名は、ニューヨークについての天気の更新に関するファイルを含み得る。たとえば、都市ごとに特定のファイルを識別し、グループ化することを可能にするために、ｗｅａＡｐｐファイルは「ｗｅａＡｐｐ／ＬＡ／ｆ１．ｊｐｇ」および「／ｗｅａＡｐｐ／ＮＹ／ｆ４．ｊｐｇ」と命名され得る。

このファイルシステム抽象化は、ブロードキャストファイル配信サービスを介してトランスポートされるファイルの定義および管理を簡略化する。アプリケーション開発者はブロードキャストトランスポートシステムの詳細に関与する必要がないので、ファイルシステム抽象化はアプリケーション開発プロセスをも簡略化する。

図５に、ファイルシステム抽象化の一実装形態を示す。詳細には、図５は、ファイルトランスポートネットワーク４１を介して天気アプリケーション４４が使用するファイルのトランスポートにおいて使用され得るファイル名を示している。図示の例では、送信側天気アプリケーション４３は、適切に命名されたファイルを用いて送信コマンドを発行することによってファイルが送られることを要求し得る。たとえば、天気アプリケーション４３は、ＬＡ天気ファイルが送られることを要求するためにコマンドｓｅｎｄＦｉｌｅ（／ｗｅａＡｐｐ／ＬＡ／０１２５１０Ｕｐｄａｔｅ．ｊｐｇ）を使用し得る。ファイル取込みシステム３１は、これらのファイルを受信し、ファイル名をＢＳＭメッセージ内に含める。

受信機デバイス側では、受信機デバイスのプロセッサ内で機能するデバイスアプリケーションが、ヘッドエンド側で使用されるのと同じファイル名構造を使用することによってファイルを要求し得る。これは図５に示されており、クライアント天気アプリケーション４６が、ファイル配信サービス４４に登録し得、すべての関係するファイルが単一のコマンドでキャプチャされることを要求し得ることが示されている。たとえば、受信機デバイスが（ユーザ選好、またはＧＰＳのような位置判断機能に基づいて判断され得るように）ニューヨーク市の近傍にある場合、デバイスアプリケーション４６は、キャプチャコマンドを発行することと、適切に命名されたディレクトリを与えることとによって、すべてのニューヨーク市関係の天気ファイルが受信されることを要求し得る。図示の例では、クライアント天気アプリケーション４６は「ｃａｐｔｕｒｅＡｌｌ」コマンドを発行し、要求されたディレクトリ名として「／ｗｅａＡｐｐ／ＮＹＣ／」を与え得る（「／」は、ディレクトリ名をファイル名と区別するための規則として使用され得る）。したがって、図示の例では、クライアントアプリケーション４６は、ヘッドエンドアプリケーション４２からすべての関係するニューヨーク市天気ファイルを受信するために、「ｃａｐｔｕｒｅＡｌｌ（／ｗｅａＡｐｐ／ＮＹＣ／）」コマンドを発行するだけでよい。ファイルシステム抽象化を使用することによってファイルを要求し、送るこの方法は、ファイル送信およびアプリケーション開発プロセスを大幅に簡略化する。

図６に、ファイルシステム抽象化の別の実装形態を示す。詳細には、図６は、ヘッドエンド双方向性アプリケーション（ｉＴＶＡｐｐ）６０が画像ファイルとオーバーヘッドファイルとしてのカタログとをサブミットするシナリオを示している。カタログファイル（／ｉｔｖ／ｓｉｇ／ｃａｔ．ｘｍｌ）は、双方向性アプリケーションから入手可能なファイルに関する情報を与える。ヘッドエンド双方向性アプリケーション６０がトランスポートのための新しいファイルをサブミットするとき、それらのファイルとともに、更新された双方向性カタログもサブミットされ得る。更新された双方向性カタログは、新たに追加された双方向性ファイルを記述し得る。したがって、図示の例では、双方向性アプリケーションサーバ６０は、送信コマンドとともに、カタログファイルと３つの双方向性ファイルとをファイル取込みシステム３１に与える。図示の例では、送信コマンドは「ｓｅｎｄＦｉｌｅ（／ｉｔｖ／ｓｉｇ／ｃａｔ．ｘｍｌ、／ｉｔｖ／ｒｅｓ／ｓｖｃ＿５／ｆ１．ｊｐｇ、／ｉｔｖ／ｒｅｓ／ｓｖｃ＿５／ｆ２．ｊｐｇ、／ｉｔｖ／ｒｅｓ／ｓｖｃ＿５／ｆ３．ｊｐｇ）」であり得る。受信機側では、クライアントアプリケーション６２が、カタログファイルの更新の継続的キャプチャのために要求コマンドをファイル配信サービスモジュール４４に発行し得る。図示の例では、この要求コマンドは「ｃａｐｔｕｒｅＡｌｌ（／ｉｔｖ／ｓｉｇ／ｃａｔ．ｘｍｌ）」であり得、サービス要求に対する引数としてディレクトリ名ではなくファイル名（「／」によって終了しない引数）が使用された。要求コマンドを発行した後に、クライアントアプリケーション６２は、カタログファイル中のアプリケーション固有情報のアプリケーション固有処理に従って、カタログ情報の更新に基づいて特定のファイルをキャプチャするための要求コマンドを発行し得る。たとえば、クライアントアプリケーション６２は、関係がある単一のファイル「ｆ２．ｊｐｇ」をキャプチャするために「ｓｉｎｇｌｅＣａｐｔｕｒｅ（／ｉｔｖ／ｒｅｓ／ｓｖｃ＿５／ｆ２．ｊｐｇ）」コマンドを発行し得、これらのファイルのためのコンテンツは変化することが予想されないので、ｓｉｎｇｌｅＣａｐｔｕｒｅ（）は、要求されたファイルの更新を監視し続けない。

様々な実施形態では、上記で説明したファイルシステム抽象化システムを実装するアプリケーションは、ファイルトランスポートネットワーク４１を介した受信のために利用可能なファイルを発見および要求する他の方法を実装するアプリケーションと混合され得る。したがって、様々な実施形態では、異なるファイル抽象化および／またはファイル要求／送信技法を実装するクライアントアプリケーションとヘッドエンドアプリケーションの両方を使用するハイブリッドシステムが採用され得る。このハイブリッドシステムは、単一のフレームワーク上で様々なタイプのファイル配信アプリケーションを同時にサポートするファイル配信フレームワーク（ＦＤＦ）の能力に寄与し得る。

図７に、送信リソースを共有するためにファイル配信パイプにおいてファイルを時間多重化することによる、取り込まれたファイルのスケジューリングを示す。上記で説明したように、様々な実施形態では、システムの総合効率を改善するためにリソースがファイル配信パイプに編成され得る。ファイルトランスポートサービス（たとえば、ＦＤＦサービス）を与えるたいていのブロードキャストネットワークは一般にリソース制限があるので、リソースをファイル配信パイプに編成することは効率を改善する。様々な実施形態では、ファイル配信パイプは、送信プロセスに専用であるリソースの特定のグループであり得る。様々な実施形態では、ファイル配信パイプは専用ブロードキャストリソースであり得る。様々な実施形態では、専用リソースは、特定のファイルトランスポートプロセスに専用であるネットワークリソースを含み得る。様々な実施形態では、１つまたは複数のファイル配信パイプは、ファイル配信ネットワーク上で１つまたは複数のファイルをトランスポートするために使用され得る。

図７は、ファイルのシーケンスを搬送するようにスケジュールされたファイル配信パイプ７２をも示している。各ファイルは、異なるトランスポートファイルＩＤおよび／または要素ＩＤ（たとえば、ｆＩＤ＿１〜ｆＩＤ＿４）を用いて識別される。トランスポートファイルＩＤおよび／または要素ＩＤは、ファイルを一意に識別し、暗黙的バージョニングサポートの形態を与え得る（すなわち、ファイルの各サブミットされたバージョンが新しいファイルＩＤ／要素ＩＤを割り当てられ得る）。図７は、各ファイルが特定のブロードキャストウィンドウ（ＢＷ）内にブロードキャストされるようにスケジュールされ得ることを示しており、各ブロードキャストウィンドウ（たとえば、ＢＷ_{fID_2}）は、ファイル（たとえば、ｆＩＤ＿２）が送信され得る時間期間に対応する。様々な実施形態では、専用パイプ上で各ファイルを送信するために必要とされるブロードキャストウィンドウは、トランスポートパイプデータレートと、送信されているファイルのサイズとに応じて定義され得る。様々な実施形態では、ブロードキャストウィンドウは、ファイルパイプデータレートによって除算されたファイルサイズに比例し得る。

図７は、トランスポートのためのファイル、それらのブロードキャストウィンドウならびに送信メタデータを記述する、ブロードキャストスケジュールメッセージ（ＢＳＭ）を搬送するためにブロードキャストスケジュールフロー（ＢＳＦ）７０が使用され得ることをも示している。様々な実施形態では、ブロードキャストスケジュールフロー７０は、コンテンツフローとは別個のオーバーヘッドフローであり得る。様々な実施形態では、受信機デバイスが、それらの所望のファイルを受信するのに間に合うように受信機回路をアクティブにし得るように、ブロードキャストスケジュールメッセージはファイルより先に送信され得る。様々な実施形態では、受信機デバイスによるブロードキャストスケジュールメッセージの確実な受信を保証するために、同じブロードキャストスケジュールメッセージが、あらゆるスーパーフレームにおいてなど、頻繁に再ブロードキャストされ得る。

上記で説明したように、様々な実施形態では、各ブロードキャストスケジュールメッセージ（ＢＳＭ）は、スケジュールされたファイルの一部分のみを記述し得る。これは、多数のファイルがオーバージエア送信のために利用可能でありスケジュールされている状況をサポートするためのものであり、単一のブロードキャストスケジュールメッセージにおいてすべてのスケジュールされたファイルを定義することは実際的ではない。ブロードキャストスケジュールメッセージにおいてスケジュールされたファイルの部分のみを広告することは、新しいファイルが送信のために断続的にサブミットされるにつれてスケジュールが頻繁に変化し得る状況をもサポートする。したがって、様々な実施形態では、ブロードキャストスケジュールメッセージは、スケジュールされたファイルの一部分のみを記述するように生成され得る。これらの実施形態では、ブロードキャストスケジュールメッセージは、所与のブロードキャストスケジュール期間（ＢＳＰ）内にブロードキャストされることになる一連のファイルを記述し得る。

図７は、各ＢＳＭが各ブロードキャストスケジュール期間（ＢＳＰ）内の一連のファイルを記述し得ることをも示している。詳細には、図７は、３つの一意のファイル（ｆＩＤ＿１〜ｆＩＤ＿３）のみが第１のブロードキャストスケジュール期間（ＢＳＰ₁）においてブロードキャストされる例を示している。様々な実施形態では、各ブロードキャストスケジュール期間は、対応するブロードキャストスケジュールメッセージ中に含まれる広告されたファイルブロードキャストスケジュールの数を表す量を定義し得る。これらのブロードキャストスケジュールメッセージは、同じブロードキャストスケジュールフロー７０内で繰り返し送信され得る。たとえば、図７は、ＢＳＰ₁期間内のブロードキャストのためにスケジュールされたファイルのすべてを記述する同じＢＳＭ₁メッセージが、ＢＳＭ７０ａ〜７０ｄによって示すように、ブロードキャストスケジュールフロー７０において数回ブロードキャストされることを示している。

様々な実施形態では、ファイル配信システムは、ブロードキャストスケジュール期間（ＢＳＰ）が比較的短くなるように、およびブロードキャストスケジュールメッセージ（ＢＳＭ）がブロードキャストスケジュールフロー（ＢＳＦ）７０内で定期的に更新されるように、構成され得る。短いブロードキャストスケジュール期間を使用するようにシステムを構成し、ブロードキャストスケジュールメッセージを定期的に更新することによって、ファイル配信システムの効率およびフレキシビリティ、ならびに連続的に更新されたファイルを管理するファイル配信システムの能力は、大幅に改善され得る。

図７は、ブロードキャストスケジュールフロー（ＢＳＦ）７０内に含まれるブロードキャストスケジュールメッセージ（ＢＳＭ）が定期的に更新されている例を示している。詳細には、図７は、ＢＳＭ₁７０ｄが、ＢＳＰ₂内にブロードキャストされることになるファイルに対応するＢＳＭ₂７０ｅに更新され得ることを示している。図７は、ブロードキャストスケジュールメッセージ（たとえば、ＢＳＭ₁およびＢＳＭ₂）が２つのＢＳＰ（たとえば、ＢＳＰ₁およびＢＳＰ₂）の境界上で更新され得ることをも示している。

図７は、ｆＩＤ＿１について示すように、単一のファイルについて複数のブロードキャストウィンドウがブロードキャストスケジュール期間（ＢＳＰ）中に存在するシナリオを示していることに留意されたい。単一のファイルのための複数のブロードキャストウィンドウは、ファイル送信についての成功率を改善するためにファイルが繰り返し送信されるときに使用され得、これは、高優先度ファイルに適していることがある。単一のファイルのための複数のブロードキャストウィンドウはまた、他のファイルを同時に送信することを可能にするために、あるファイルが独立部分に分割されなければならないほど大きいときに、必要であり得る。単一のファイルのための複数のブロードキャストウィンドウがあるとき、それらの複数のブロードキャストウィンドウは、同じブロードキャストスケジュール期間内に、または異なるブロードキャストスケジュール期間において現れ得る。

図８に、ブロードキャストスケジュール期間内にブロードキャストされた複数のファイルについてのブロードキャストウィンドウおよび受信情報を与えるために、各ブロードキャストスケジュールメッセージ（たとえば、ＢＳＭ₁およびＢＳＭ₂）が、あらゆるスーパーフレームにおいてなど、定期的に繰り返され得ることを示す。図８は、ファイル配信パイプデータフローにおいて送信されるファイルが異なるサイズのものであり得るので、それらのファイルは異なるブロードキャスト持続時間のものであり得ることをも示している。

上記で説明したように、ＢＳＭは、送信スケジュールを広告するための機構を与える。ＢＳＭはまた、追加情報のアレイを受信機デバイスに与え得る。図９に、例示的なＢＳＭのハイレベルフォーマットを示す。図９に示すように、ブロードキャストスケジュールメッセージはブロードキャストスケジュール監視記録（ＢＳＭＲ）を含み得る。ブロードキャストスケジュール監視記録は、受信機デバイスが、更新されたＢＳＭについてブロードキャストスケジュールフローを監視すべきである、次の時間を指定する次のモニタ時間データフィールド（Ｎｅｘｔ＿Ｍｏｎｉｔｏｒ＿Ｔｉｍｅ）を含み得る。また、このデータフィールドは、次のブロードキャストスケジュール期間が開始し得る時間を定義し得る。以下でより十分に説明するように、ＢＳＭが更新されることになる時間を指定することにより、受信機デバイスは、冗長ＢＳＭがブロードキャストスケジュールフロー（ＢＳＦ）７０上で搬送されているときに受信機デバイスの受信機回路を非アクティブにすることによってバッテリー電力を温存することが可能になる。

図９は、ＢＳＭがフローブロードキャストスケジュール記録（ＦＢＳＲ）をも含み得ることを示している。フローブロードキャストスケジュール記録は、現在のブロードキャストスケジュール期間（ＢＳＰ）中に（たとえば、ファイルブロードキャストパイプ内で）コンテンツフロー上でブロードキャストされているファイルについてのブロードキャストスケジュールを記述し得る。ＢＳＭは複数のフローブロードキャストスケジュール記録を含み得る。各フローブロードキャストスケジュール記録は、フローブロードキャストスケジュール記録ヘッダ（ＦＢＳＲヘッダ）およびフローブロードキャストスケジュール記録ボディ（ＦＢＳＲボディ）という２つの主要な部分を含む値部分（すなわち記録データ）を用いたタイプ−値−長さ（ＴＬＶ）構造の形態のものであり得る。

フローブロードキャストスケジュール記録ヘッダ（ＦＢＳＲヘッダ）は、トランスポートストリーム、周波数、および／またはブロードキャストシステムに関する情報を搬送し得る。フローブロードキャストスケジュール記録ヘッダは、フローＩＤとフローデータレートとを含み得る。フローＩＤは、ファイルの送信のために使用されるブロードキャストフローについての識別子であり得る。フローデータレートは、フローＩＤの下でブロードキャストスケジュールメッセージにおいて記述されたファイルが送信されるべきであるデータレートであり得る。

フローブロードキャストスケジュール記録ボディ（ＦＢＳＲボディ）は、ＢＳＲ₁およびＢＳＲ₂によって示されるように、１つまたは複数のブロードキャストスケジュール記録を搬送し得る。各ブロードキャストスケジュール記録（ＢＳＲ）は、所与のブロードキャストスケジュール期間（ＢＳＰ）７０内にコンテンツフロー上でブロードキャストされている単一のファイルに関するブロードキャスト情報を与え得る。ブロードキャストスケジュール記録ボディ（ＢＳＲボディ）は、ブロードキャストデジタル記録タイプ（ＢＳＲ＿Ｔｙｐｅ）と、ファイルＩＤおよび／または要素ＩＤ（たとえば、Ｆｉｌｅ＿ＩＤ）と、スケジュール情報と、タイプ−値−長さ（ＴＬＶ）符号化において符号化されたパラメータのシーケンスとを含み得る。ブロードキャストデジタル記録タイプ（たとえば、ＢＳＲ＿Ｔｙｐｅ）は、単一のファイル、ファイルのバンドルなど、ブロードキャストされているファイルのタイプに関する情報を与え得る。ファイルＩＤおよび／または要素ＩＤ（たとえば、Ｆｉｌｅ＿ＩＤ）は、ブロードキャストされているファイルコンテンツを識別し得る。スケジュール情報は、所与のファイルについてのブロードキャストウィンドウを記述し、ブロードキャストスケジュール期間全体にわたる多くのブロードキャスト送信を記述し得る。ブロードキャストウィンドウは、ブロードキャストウィンドウ開始時間（ＢＷ＿Ｓｔａｒｔ＿Ｔｉｍｅ）とブロードキャスト持続時間（ＢＷ＿Ｄｕｒａｔｉｏｎ）とによって定義され得る。ブロードキャストウィンドウ開始時間は、ファイルのブロードキャストが始まる時間として定義され得る。ブロードキャスト持続時間は、ファイルがブロードキャストされることになるブロードキャストウィンドウ開始時間を超えた時間の長さとして定義され得る。

フローブロードキャストスケジュール記録ボディは、受信機デバイスによるフィルタ処理および選択を可能にし得る形で特定のファイルＩＤおよび／または要素ＩＤのファイルをさらに識別し得る追加情報を搬送するためにＢＳＭの拡張性を与える、タイプ−値−長さ（ＴＬＶ）符号化におけるパラメータのシーケンスをさらに含み得る。以下で、フローブロードキャストスケジュール記録ボディ中に含まれ得るパラメータの３つのタイプについて説明する。

第１のタイプ（たとえば、タイプ＝１）中には、ファイルＩＤおよび／または要素ＩＤによって識別されるファイルコンテンツが関連付けられ得る可能な複数のファイルまたはディレクトリ名を識別する、プレフィックスマッチングストリングが含まれ得る。たとえば、ブロードキャストスケジュール記録は１つのプレフィックスマッチングストリングのみを含み得、その場合、データが「／ｉｔｖ／ｒｅｓ／ｓｖｃ＿５／ｆ２．ｊｐｇ」などのファイル名である。別の例として、ブロードキャストスケジュール記録は複数のプレフィックスマッチングストリングを含み得、その場合、各ＴＬＶが、あるＴＬＶでは「／ｉｔｖ／ｒｅｓ／ｓｖｃ＿５／ｆ２．ｊｐｇ」、および別のＴＬＶでは「／ｉｔｖ／ｒｅｓ／ｓｖｃ＿１５／ｆ２．ｊｐｇ」など、異なるファイル名を有する。この状況は、サービス５（たとえば、ＥＳＰＮ）およびサービス１５（たとえば、ＥＳＰＮ２）上で双方向性のために同じファイル「ｆ２．ｊｐｇ」を使用し、したがって、「ｆ２．ｊｐｇ」が「／ｉｔｖ／」ファイルディレクトリ構造において２つのエイリアスを有する、双方向性（ｉｔｖ）アプリケーションの場合であり得る。第３の例では、受信機デバイスは、ｓｉｎｇｌｅＣａｐｔｕｒｅ（／ｉｔｖ／ｒｅｓ／ｓｖｃ＿１５／ｆ２．ｊｐｇ）またはｃａｐｔｕｒｅＡｌｌ（／ｉｔｖ／ｒｅｓ／ｓｖｃ＿５／）の形態でファイルをキャプチャしたいという要求を受信し得、その場合、受信デバイスは、プレフィックスマッチングストリングＬＴＶ中の値を用いて２ウェイプレフィックスマッチングを実行し得る。

第２のタイプ（たとえば、タイプ＝２）では、属性ストリングが、ファイルＩＤおよび／または要素ＩＤによって識別されたファイルコンテンツ、あるいはそのファイルコンテンツが好適であるアプリケーションまたは受信機デバイスを特徴づける、複数の属性（たとえば、性別＝男性、年齢＝２０〜３０など）を与え得る。この場合、属性ストリングを使用する受信機デバイスは、＆＆が論理ＡＮＤ演算を表すｃａｐｔｕｒｅＡｌｌ（性別＝男性＆＆年齢＝２０〜３０）など、いくつかの属性に関する論理表現にマッチするファイルをキャプチャしたいという要求を受信していることになる。

第３のタイプ（たとえば、タイプ＝３）では、所与のアプリケーションまたはサービスの範囲内のファイルＩＤおよび／または要素ＩＤを識別する、アプリケーションまたはサービス固有識別子（たとえば、ｉｔｖ：１２３またはｓｖｃ＿３：２２３４など）がファイルに与えられる。アプリケーションまたはサービス識別子を使用する受信機デバイスは、利用可能なファイルと、関連付けられた属性と、ファイルについての対応するアプリケーションまたはサービス識別子とを記述するために、カタログファイルを利用することになる。次いで、アプリケーションまたはサービスは、関係があるファイルのキャプチャをｓｉｎｇｌｅＣａｐｔｕｒｅ（ｉｔｖ：１２３）などの単一キャプチャとして要求し得る。

図１０に、別の例示的なブロードキャストスケジュールメッセージについてのハイレベルフォーマットを示す。図１０に示すように、ＢＳＭは、複数のブロードキャストスケジュール情報記録（ＢＳＩＲ₁〜ＢＳＩＲ_M）を含んでいることがある。各ブロードキャストスケジュール情報記録は、１つまたは複数のフロー上のブロードキャストスケジュールに関する情報を含んでいることがある。各ブロードキャストスケジュール情報記録は、更新されたブロードキャストスケジュールを受信するために受信機デバイスが使用することができる監視スケジュールをも含んでいることがある。

図１０に示すように、各ブロードキャストスケジュール情報記録（たとえば、ＢＳＩＲ₁〜ＢＳＩＲ_M）はヘッダ部分（ＢＳＩＲヘッダ）とボディ部分（ＢＳＩＲボディ）とを有し得る。ヘッダ部分は、次のモニタ時間（たとえば、Ｎｅｘｔ＿Ｍｏｎｉｔｏｒ＿Ｔｉｍｅ）フィールドと監視期間（たとえば、Ｍｏｎｉｔｏｒｉｎｇ＿Ｐｅｒｉｏｄ）フィールドとを含み得る。様々な実施形態では、ヘッダ部分中のフィールド（たとえば、Ｎｅｘｔ＿Ｍｏｎｉｔｏｒ＿Ｔｉｍｅ、Ｍｏｎｉｔｏｒｉｎｇ＿Ｐｅｒｉｏｄなど）は、ファイル配信フレームワーク（ＦＤＦ）が異なるレイテンシにおいてデータを配信することを可能にするために、使用され得る。様々な実施形態では、受信機デバイスが第１のブロードキャストスケジュール情報記録のみを処理するように、ある監視期間内のブロードキャストスケジュール情報記録（ＢＳＩＲ）のすべてが降順にソートされ得る。様々な実施形態では、ブロードキャストスケジュール情報記録は、システムが初期収集フロー（ＩＡＦ）システムをサポートしないと判断されたときのみ次のモニタ時間（たとえば、Ｎｅｘｔ＿Ｍｏｎｉｔｏｒ＿Ｔｉｍｅ）フィールドを含むように構成され得る。

様々な実施形態では、ブロードキャストスケジュール情報記録のボディ部分（ＢＳＩＲボディ）は複数のフローブロードキャストスケジュール記録（ＦＢＳＲ₁〜ＦＢＳＲ_N）を含み得る。フローブロードキャストスケジュール記録は、ブロードキャストスケジュール期間（ＢＳＰ）内にフロー上でブロードキャストされた要素のブロードキャストスケジュールを記述するファイル配信データフロー記録である。各フローブロードキャストスケジュール記録は、値部分がヘッダ部分（ＦＢＳＲヘッダ）とボディ部分（ＦＢＳＲボディ）とを含む、タイプ−値−長さ（ＴＬＶ）構造を有し得る。フローブロードキャストスケジュール記録のヘッダ部分は、フローＩＤ、データレートなど、データフローに関する情報を含んでいることがある。フローブロードキャストスケジュール記録のボディ部分は、１つまたは複数のブロードキャストスケジュール記録（ＢＳＲ₁〜ＢＳＲ_N）を含んでいることがある。様々な実施形態では、フローブロードキャストスケジュール記録のボディ部分は、ブロードキャストスケジュール期間（ＢＳＰ）内にフロー上でブロードキャストされた各要素についてのブロードキャストスケジュール記録を含んでいることがある。様々な実施形態では、各ブロードキャストスケジュール記録は、各要素（すなわち、データフロー上でブロードキャストされるデータユニット）についての要素ＩＤ（Ｅｌｅｍｅｎｔ＿ＩＤ）と、その要素中の（１つまたは複数の）ファイルについての１つまたは複数のファイル／ディレクトリ名と、ブロードキャストスケジュール情報とを有し得る。一実施形態では、ファイルおよびディレクトリ名は、ＵＮＩＸ（登録商標）ベースのファイル命名規則に従い得る。一実施形態では、要素ＩＤ（たとえば、Ｅｌｅｍｅｎｔ＿ＩＤ）によって表される要素は、特定のバージョンのファイルか、または複数のファイルからなる特定のバージョンのファイルバンドルのいずれかに対応し得る。様々な実施形態では、同じファイルまたはファイルバンドルの異なるバージョンが、異なる要素に対応し得る。様々な実施形態では、要素ＩＤは、ファイル配信フレームワーク（ＦＤＦ）によって各要素に割り当てられたグローバル一意ＩＤであり得る。

図１１に、ＢＳＭの次のモニタ時間データフィールドを使用するための一実施方法を示す。上記で説明したように、ＢＳＭは、受信機デバイスが、更新されたＢＳＭについてブロードキャストスケジュールフローを監視すべきである、次の時間を指定する次のモニタ時間データフィールド（たとえば、図１０中のＮｅｘｔ＿Ｍｏｎｉｔｏｒｉｎｇ＿Ｔｉｍｅフィールド）を含み得る。図１１は、次のブロードキャストスケジュール期間（次のＢＳＰ）の間にブロードキャストスケジュールフロー（ＢＳＦ）７０において第２のＢＳＭ（ＢＳＭ₂）を更新するために第１のＢＳＭ（ＢＳＭ₁）の次のモニタ時間データフィールドがどのように使用され得るかを示している。図１１は、受信機デバイスがＢＳＭ（たとえば、ＢＳＭ₁）を受信するとき、受信機がＢＳＭ₁中の次の監視時間に従ってブロードキャストスケジュールフロー（ＢＳＦ）を監視するために次の起動時間をスケジュールし得ることを示している。

図１２は、ブロードキャストスケジュールメッセージを処理するための実施方法１２００である。図１２は、判断ステップ１２０１において、受信機デバイスが、最初に、受信したＢＳＭが、前に処理されたブロードキャストスケジュールメッセージのバージョンプロパティと同じバージョンプロパティを有するかどうかを判断し得ることを示している。バージョンが同じである場合（すなわち、判断ステップ１２０１＝「はい」）、受信機デバイスは判断ステップ１２１６に進み得る。バージョンが同じでない場合（すなわち、判断ステップ１２０１＝「いいえ」）、ステップ１２０２において、受信機デバイスは、前のＢＳＭを削除し、新たに受信したＢＳＭを保存する。ファイル配信フレームワーク（ＦＤＦ）は、ファイルをキャプチャするための要求をアプリケーションから受信するたびに、保存されたＢＳＭを再処理するためにその要求中の新しい情報を使用すべきであるので、新しいＢＳＭを保存することは必要である。

判断ステップ１２０４において、受信機デバイスは、ブロードキャストスケジュールメッセージからブロードキャストスケジュールメッセージ記録を読み取ることを試み得る。成功した場合（すなわち、判断ステップ１２０４＝「はい」）、判断ステップ１２０６において、受信機デバイスは、ＢＳＭ中の記録（たとえば、ＢＳＭＲ、ＦＢＳＲ）を処理し、その記録がブロードキャストスケジュール監視記録（ＢＳＭＲ）であるかどうかを判断し得る。記録がブロードキャストスケジュール監視記録である場合（すなわち、判断ステップ１２０６＝「はい」）、ステップ１２０８において、デバイスは、ブロードキャストスケジュール監視記録中の次の監視時間フィールド（たとえば、ＮＥＸＴ＿ＭＯＮＩＴＯＲＩＮＧ＿ＴＩＭＥ）を新しい次の監視時間として使用し得る。記録がブロードキャストスケジュール監視記録でない場合（すなわち、判断ステップ１２０６＝「いいえ」）、判断ステップ１２１２において、受信機デバイスは、記録がフローブロードキャストスケジュール記録（ＦＢＳＲ）であるかどうかを判断し得る。記録がフローブロードキャストスケジュール記録でない場合（すなわち、判断ステップ１２１２＝「いいえ」）、受信機デバイスは、判断ステップ１２０４に戻って、新しいブロードキャストスケジュールメッセージ記録を読み取る。記録がフローブロードキャストスケジュール記録である場合（すなわち、判断ステップ１２１２＝「はい」）、ステップ１２１４において、デバイスは、フローブロードキャストスケジュール記録を処理し、データフィルタ処理決定を行い、次いで、判断ステップ１２０４に戻って、新しいブロードキャストスケジュールメッセージ記録を読み取り得る。

判断ステップ１２０４において、受信機デバイスがＢＳＭからブロードキャストスケジュールメッセージ記録を読み取ることに失敗した場合（すなわち、判断ステップ１２０４＝「いいえ」）、ステップ１２１０において、受信機デバイスは、新しいＢＳＭにおいて指定されていない、前にスケジュールされたダウンロードをキャンセルし、判断ステップ１２１６に進む。様々な実施形態では、ファイル配信コア（ＦＤＣ）が、新しいＢＳＭにおいて指定されていない、前にスケジュールされたダウンロードをキャンセルし得る。様々な実施形態では、ブロードキャストサーバが、更新されたＢＳＭを送ることによって、ブロードキャストされた要素をキャンセルするために、この特徴を使用し得る。ファイル配信コアについては、以下で図１９を参照しながらより詳細に説明する。

図１２に戻ると、ブロードキャストスケジュールメッセージ中のすべてのフィールドを処理した後に、または前に処理されたＢＳＭを受信すると（すなわち、判断ステップ１２０１＝「はい」）、判断ステップ１２１６において、受信機デバイスは、次の監視時間（たとえば、ＮＥＸＴ＿ＭＯＮＩＴＯＲＩＮＧ＿ＴＩＭＥ）が現在時間よりも後であるかどうか、すなわち、現在時間と次の監視時間との間の差が、デバイスプロビジョニングパラメータ（たとえば、ＭＡＸ＿ＢＳＦ＿ＭＯＮＩＴＯＲＩＮＧ＿ＰＥＲＩＯＤ）によって指定された時間期間以下であるかどうかを確認し得る。次の監視時間が現在時間よりも後でない場合（すなわち、判断ステップ１２１６＝「いいえ」）、プロセスは終了し、デバイスは、ブロードキャストスケジュールフローブロードキャストスケジュールフローを監視することを停止し、次の更新されたＢＳＭを受信するのを待ち得る。次の監視時間が現在時間よりも後であり、現在時間と次の監視時間との間の差が、指定された時間期間以下である場合（すなわち、判断ステップ１２１６＝「はい」）、ステップ１２１８において、受信機デバイスは、ブロードキャストスケジュールフローを登録解除し（すなわち、現在のブロードキャストスケジュールフローを受信することを停止し）、次の監視時間にブロードキャストスケジュールフローを受信することをスケジュールする。他の場合、デバイスはブロードキャストスケジュールフローを受信し続け得る。

図１３に、ブロードキャストスケジュールフロー（ＢＳＦ）７０上で更新検出を実装するための実施方法１３００を示す。図１３は、判断ステップ１３０１において、デバイスが、最初に、受信したブロードキャストスケジュールメッセージ（ＢＳＭ）中の第１のブロードキャストスケジュール情報記録（ＢＳＩＲ）のバージョンが、前に処理されたブロードキャストスケジュール情報記録のバージョンと同じであるかどうかを確認し得ることを示している。バージョンが同じである場合（すなわち、判断ステップ１３０１＝「はい」）、デバイスは判断ステップ１３１０に進み得る。バージョンが同じでない場合（すなわち、判断ステップ１３０１＝「いいえ」）、ステップ１３０２において、受信機は、前に保存されたブロードキャストスケジュール情報記録を削除し、新しいブロードキャストスケジュール情報記録を保存する。新しいブロードキャストスケジュール情報記録を保存することにより、ファイル配信フレームワーク（ＦＤＦ）は、ファイル配信フレームワークがアプリケーションから新しいファイルキャプチャ要求を受信するたびに、保存されたブロードキャストスケジュール情報記録を再処理するためにその要求中の新しい情報を使用することが可能になる。ステップ１３０４において、デバイスは、ブロードキャストスケジュール情報記録中の次の監視時間フィールド（たとえば、ＮＥＸＴ＿ＭＯＮＩＴＯＲＩＮＧ＿ＴＩＭＥ）を新しい次の監視時間として使用し得る。ステップ１３０６において、受信機デバイスは、ブロードキャストスケジュール情報記録中のフローブロードキャストスケジュール記録（ＦＢＳＲ）のすべてを処理する。様々な実施形態では、デバイスは、データフィルタ処理決定を行うためにフローブロードキャストスケジュール記録の処理を使用し得る。ステップ１３０８において、ファイル配信コア（ＦＤＣ）は、新しいブロードキャストスケジュール情報記録において指定されていない、前にスケジュールされたダウンロードをキャンセルする。様々な実施形態では、ブロードキャストサーバは、更新されたブロードキャストスケジュールメッセージを送ることによって、ブロードキャストされた要素をキャンセルするために、この特徴を使用することができる。

ブロードキャストスケジュール情報記録（ＢＳＩＲ）中のすべてのフィールドを処理した後に、判断ステップ１３１０において、受信機デバイスは、次の監視時間が現在時間よりも後であるかどうか、すなわち、現在時間と次の監視時間との間の差が、デバイスプロビジョニングパラメータ（たとえば、ＭＡＸ＿ＢＳＦ＿ＭＯＮＩＴＯＲＩＮＧ＿ＰＥＲＩＯＤ）以下であるかどうかを確認し得る。様々な実施形態では、次の監視時間が現在時間よりも後でない場合（すなわち、判断ステップ１３１０＝「いいえ」）、デバイスはブロードキャストスケジュールフロー７０を監視することを停止し得る。次の監視時間が現在時間よりも後であり、現在時間と次の監視時間との間の差がデバイスプロビジョニングパラメータ（ＭＡＸ＿ＢＳＦ＿ＭＯＮＩＴＯＲＩＮＧ＿ＰＥＲＩＯＤ）以下である場合（すなわち、判断ステップ１３１０＝「はい」）、ステップ１３１２において、受信機デバイスは、ブロードキャストスケジュールフローを登録解除し（すなわち、ＢＳＦを受信することを停止し）、次の監視時間にブロードキャストスケジュールフロー７０を受信することをスケジュールする。他の場合、デバイスはブロードキャストスケジュールフロー７０を受信し続け得る。

図１２および図１３を参照しながら上記で説明した実施方法では、受信機デバイスは、指定された監視時間にフローカバレージ外にある場合、ブロードキャストスケジュールフロー７０を受信するためにいつ再起動すべきかを知らないことがある。このシナリオは図１４に示されており、受信機デバイスが様々な時間にカバレージエリアの外にあり得ることが示されている。

図１４は、受信機デバイスが、ブロードキャストスケジュールフロー送信のタイミングに関係する様々な時間に、どのようにブロードキャストネットワークのおよび／またはブロードキャストフローのカバレージエリアの外にあり得るか（１４０１、１４０２）を示すタイムライン図である。そのような場合、受信機デバイスは、ブロック１４０１によって表されるように、次の指定された監視時間の前にカバレージエリアに再び入ることがある。またある時には、受信機デバイスは、ブロック１４０２によって表されるように、次の指定された監視時間が過ぎるまでカバレージエリアに再び入らないことがある。図１４は、様々な実施形態では、受信機デバイスが、フローカバレージエリア外にあった後にフローカバレージに再び入るたびに、ブロードキャストスケジュールフロー７０を受信し得ることを示している。いくつかの実施形態では、受信機デバイスは、それが、指定された監視時間にフローカバレージ外にあったと判断することに基づいて、受信機デバイスがブロードキャストスケジュールフロー７０を受信すべきかどうかに関して個別の判断を行い得る。様々な実施形態では、受信機デバイスは、フローカバレージエリアに戻るときにブロードキャストスケジュールフロー７０を受信することを強制され得る（「ＢＳＦを受信することを強制される」として図示）。他の実施形態では、受信機デバイスは、サービスコアが開始するたびに、ブロードキャストスケジュールフロー７０を受信するように構成され得る。他の実施形態では、受信機デバイスは、次の指定された監視時間が過ぎたかどうかに関する判断を行い、受信機デバイスがブロードキャストスケジュールフローの最新のバージョンを受信していることを保証するために必要に応じて調整を行うことができる。

図１５に、初期収集フロー（ＩＡＦ）をサポートするシステム上でブロードキャストスケジュールフロー（ＢＳＦ）７０の更新を検出するための一実施方法を示す。詳細には、図１５は、初期収集フローに基づいてブロードキャストスケジュールフロー７０の更新を検出するためのタイムラインを示している。様々な実施形態では、ブロードキャストスケジュールフロー７０上のブロードキャストスケジュールメッセージ（ＢＳＭ）の更新の検出は、初期収集フロー上のディレクトリ情報メッセージ（ＤＩＭ）メッセージのコンテンツに基づき得る。様々な実施形態では、受信機デバイスが、前のディレクトリ情報メッセージにおいて指定された次のモニタ時間値（たとえば、ＮＥＸＴ＿ＭＯＮＩＴＯＲＩＮＧ＿ＴＩＭＥ）に従って周期的に起動し得る。様々な実施形態では、受信機デバイスは、初期収集フローから最新のディレクトリ情報メッセージを受信し、ブロードキャストスケジュールメッセージバージョン情報（たとえば、ＢＳＭ＿ＶＥＲＳＩＯＮ）を最新の、未経過の、処理されたブロードキャストスケジュールメッセージのバージョン情報と比較し得る。これらの実施形態では、比較されたバージョンが異なる場合、受信機デバイスは、ブロードキャストスケジュールメッセージの更新があったと判断し得、また、ブロードキャストスケジュールフロー７０上で、更新されたブロードキャストスケジュールメッセージを受信するために、受信機デバイス中の受信機回路をアクティブにし得る。様々な実施形態では、受信機デバイスは、共通のオーバーヘッドフロー受信機構を使用して、更新されたブロードキャストスケジュールメッセージを受信し得る。様々な実施形態では、受信機デバイス上のファイル配信フレームワーク（ＦＤＦ）は、ブロードキャストスケジュールメッセージが満了したことを示すためのブロードキャストスケジュールメッセージデバイスパラメータ（たとえば、ＦＤＦ＿ＢＳＭ＿ＥＸＰＩＲＹ＿ＴＩＭＥ）を、ブロードキャストスケジュールメッセージが処理された数秒後に設定し得る。これらの実施形態では、ブロードキャストスケジュールメッセージが満了したことを示すことによって、受信機デバイスは、そのデバイスが、ある時間期間の間にフローカバレージ外にあった場合であって、古いブロードキャストスケジュールメッセージを有する場合に対処することができる。様々な実施形態では、受信機デバイスは、それが古いブロードキャストスケジュールメッセージを有することを検出したときはいつでも、新しいブロードキャストスケジュールメッセージを受信するために受信機回路をアクティブにし得る。

図１６は、同じスーパーフレーム内で、ブロードキャストスケジュールメッセージの２つの異なるバージョン（たとえば、ＢＳＭ₁、ＢＳＭ₂）を受信するための一実施方法を示すタイムライン図である。上記で説明したように、様々な実施形態では、情報は、複数のスーパーフレームに編成されたワイヤレス信号中で送信され得る。各スーパーフレームは、ブロードキャストコンテンツを通信する複数のデータパケットを備える、周波数帯域内のおよび設定された時間境界内の信号を含み得る。図１６は、ブロードキャストスケジュールメッセージの２つの異なるバージョン（ＢＳＭ₁、ＢＳＭ₂）が単一のスーパーフレームの設定された時間境界内で受信され得ることを示している。

図１７に、初期収集フロー（ＩＡＦ）システムからのサポートを用いてブロードキャストスケジュールメッセージ（ＢＳＭ）を処理するための実施方法１７００を示す。判断ステップ１７０１において、受信機デバイスは、ブロードキャストスケジュールメッセージ中のバージョンパラメータ（たとえば、ＢＳＭ＿ＶＥＲＳＩＯＮ）が、ディレクトリ情報メッセージ（ＤＩＭ）において示されるバージョンパラメータと同じであるかどうかを判断し得る。バージョンが異なる場合（すなわち、判断ステップ１７０１＝「いいえ」）、デバイスは、受信したブロードキャストスケジュールメッセージを無視し、処理を終了する。様々な実施形態では、デバイスは、図１６によって示されるように、あるスーパーフレーム内で同じブロードキャストスケジュールメッセージの複数のバージョンを受信し得るので、これは必要であり得る。そのようなシナリオでは、デバイスは、ディレクトリ情報メッセージによって示される最新のバージョン（たとえば、ＢＳＭ₂）のみを処理し得る。様々な実施形態では、サーバは、初期収集フローの次の監視時間の数秒（またはマイクロ秒）前に、更新されたブロードキャストスケジュールメッセージをブロードキャストすることによって、同じスーパーフレーム内の複数のバージョンのブロードキャストスケジュールメッセージを防ぐことができる。

図１７に戻ると、バージョンパラメータが同じであると判断された場合（すなわち、判断ステップ１７０１＝「はい」）、ステップ１７０２において、受信機デバイスは、前に保存されたブロードキャストスケジュールメッセージを削除し、新しいブロードキャストスケジュールメッセージを保存する。様々な実施形態では、ファイル配信フレームワークは、ファイルをキャプチャしたいという要求をアプリケーションから受信するたびに、保存されたブロードキャストスケジュールメッセージを再処理するためにその要求中の新しい情報を使用し得るので、新しいブロードキャストスケジュールメッセージを保存することは重要であり得る。判断ステップ１７０４において、受信機デバイスは、ブロードキャストスケジュールメッセージからブロードキャストスケジュールメッセージ記録（ＢＳＭＲ）を読み取ることを試み得る。ＢＳＭＲ読取りが成功した場合（すなわち、判断ステップ１７０４＝「はい」）、判断ステップ１７０６において、受信機デバイスは、受信したブロードキャストスケジュールメッセージ中の記録（たとえば、ＢＳＭＲ）を処理し、その記録がフローブロードキャストスケジュール記録（ＦＢＳＲ）であるかどうかを判断し得る。そうである場合（すなわち、判断ステップ１７０６＝「はい」）、ステップ１７０８において、受信機デバイスは、フローブロードキャストスケジュール記録を処理し、データフィルタ処理決定を行い得る。このプロセスは、ブロードキャストスケジュールメッセージ中のすべてのフィールドが処理されるまで、判断ステップ１７０４に戻ることによって繰り返され得、これは、失敗したＢＳＭＲ読取り試みによって判断されることになる。受信機デバイスが、判断ステップ１７０４において、ブロードキャストスケジュールメッセージを正常に読み取ることができなかった場合（すなわち、判断ステップ１７０４＝「いいえ」）、ファイル配信コア（ＦＤＣ）が、ステップ１７１０において、新しいブロードキャストスケジュールメッセージにおいて指定されていない、前にスケジュールされたダウンロードをキャンセルする。

図１８は、受信機デバイスとブロードキャストサーバとの間で更新されたブロードキャストスケジュールメッセージ（ＢＳＭ）のブロードキャストのタイミングを制御するための一実施方法を示すタイムライン図である。図１８は、様々な実施形態では、ブロードキャストサーバが、ブロードキャストスケジュール期間（ＢＳＰ）開始時間より可変秒数（たとえば、ＢＳＦ＿ＭＯＮＩＴＯＲＩＮＧ＿ＡＤＶＡＮＣＥ＿ＴＩＭＥ）前になるように次の監視フィールドデバイスプロビジョンパラメータ（たとえば、次の監視時間）を設定し得ることを示している。これにより、受信機デバイスは、ブロードキャストスケジュールメッセージ更新を検出することと、対応するブロードキャストスケジュール期間の開始の前に、更新されたブロードキャストスケジュールメッセージを受信することとを行うのに十分な時間を有することが可能になり得る。

図１８は、様々な実施形態では、サーバが、更新されたブロードキャストスケジュールメッセージを送ることをサーバが開始するための開始時間を判断するために、サーバからデバイスまでの遅延を識別する最大ネットワーク遅延デバイスプロビジョンパラメータ（たとえば、最大ネットワーク遅延）を使用し得ることをも示している。様々な実施形態では、サーバは、ローカルエリアブロードキャストスケジュールメッセージとワイドエリアブロードキャストスケジュールメッセージとの中の次の監視時間を同じ値になるように設定し得る。これにより、デバイスはエネルギーを節約することが可能になる。受信機デバイスがマルチプレックス間で（たとえば、あるブロードキャスト領域から別のブロードキャスト領域に）移動し得るので、受信機デバイスは、受信機が新しいマルチプレックスに移動するたびに、新しいマルチプレックス上でブロードキャストスケジュールフロー（ＢＳＦ）７０を受信し得る。

次の監視時間が、ある秒数（たとえば、ＭＡＸ＿ＢＳＦ＿ＭＯＮＩＴＯＲＩＮＧ＿ＰＥＲＩＯＤ）以下だけ現在時間よりも後である場合、受信機デバイスは、受信したブロードキャストスケジュールメッセージ中のフィールドを処理した後に、ブロードキャストスケジュールフロー７０を登録解除し得る。受信したブロードキャストスケジュールメッセージ中のフィールドを処理した後に、受信機デバイスは、次の監視時間が現在時間よりも後でないという条件で、ブロードキャストスケジュールフロー７０を受信し続け得る。受信したブロードキャストスケジュールメッセージ中のフィールドを処理した後に、デバイスは、次の監視時間がある秒数（たとえば、ＭＡＸ＿ＢＳＦ＿ＭＯＮＩＴＯＲＩＮＧ＿ＰＥＲＩＯＤ）超だけ現在時間よりも後である場合、ブロードキャストスケジュールフロー７０を受信し続け得る。

受信機デバイスは、次の監視時間にブロードキャストスケジュールフロー（ＢＳＦ）７０を受信することをスケジュールし得る。デバイスがブロードキャストスケジュールフローの監視時間にフローカバレージ外にある場合、デバイスは、フローカバレージエリアに再び入るときにブロードキャストスケジュールフロー７０を受信し得る。受信機デバイスは、デバイス上のファイル配信フレームワーク（ＦＤＦ）が開始するときはいつでも、ブロードキャストスケジュールフロー７０を受信し得る。デバイス上のファイル配信フレームワークは、ブロードキャストスケジュールメッセージ（ＢＳＭ）が処理されてからある秒数（たとえば、ＦＤＦ＿ＢＳＭ＿ＥＸＰＩＲＹ＿ＴＩＭＥ）後にＢＳＭを満了させ得る。デバイス上のファイル配信フレームワークは、前にスケジュールされたダウンロードが、最新のブロードキャストスケジュールメッセージにおいて、もはや指定されていない場合、前にスケジュールされたダウンロードをキャンセルし得る。サーバは、ローカルエリアブロードキャストスケジュールメッセージとワイドエリアブロードキャストスケジュールメッセージとの中の次の監視時間を同じ値になるように設定し得る。サーバは、対応するブロードキャストスケジュール期間開始時間よりある秒数（たとえば、ＢＳＦ＿ＭＯＮＩＴＯＲＩＮＧ＿ＡＤＶＡＮＣＥ＿ＴＩＭＥ）前になるようにブロードキャストスケジュールフロー７０のための次の監視時間を設定し得る。受信機デバイスは、初期収集フロー（ＩＡＦ）から受信したディレクトリ情報メッセージ（ＤＩＭ）中の所与のマルチプレックスのためのブロードキャストスケジュールメッセージのバージョン（たとえば、ＢＳＭ＿ＶＥＲＳＩＯＮ）が、デバイスが処理した同じマルチプレックスのための最新のブロードキャストスケジュールメッセージのバージョンとは異なるとき、ブロードキャストスケジュールフロー７０上で、更新されたブロードキャストスケジュールメッセージを受信し得る。

様々な実施形態では、サーバは、次のブロードキャストスケジュール期間（ＢＳＰ）の開始時間よりある秒数（たとえば、ＢＳＦ＿ＭＯＮＩＴＯＲＩＮＧ＿ＡＤＶＡＮＣＥ＿ＴＩＭＥ）先に初期収集フロー（ＩＡＦ）の次の監視時間を設定し得る。サーバは、次のモニタ時間にディレクトリ情報メッセージ（ＤＩＭ）中の更新されたブロードキャストスケジュールメッセージについてのバージョン識別子（たとえば、ＢＳＭ＿ＶＥＲＳＩＯＮ）を上げる前に、そのブロードキャストスケジュールメッセージをブロードキャストし得る。受信機デバイスは、ブロードキャストスケジュールフロー７０上で受信したブロードキャストスケジュールメッセージのバージョン識別子（たとえば、ＢＳＭ＿ＶＥＲＳＩＯＮ）が、最新のディレクトリ情報メッセージ中の同じブロードキャストスケジュールフロー７０のバージョン識別子に等しい場合、そのブロードキャストスケジュールメッセージを処理し得る。デバイスは、ブロードキャストスケジュールフロー７０上で受信したブロードキャストスケジュールメッセージのＢＳＭ＿ＶＥＲＳＩＯＮが、最新のディレクトリ情報メッセージ中の同じブロードキャストスケジュールフロー７０についてのＢＳＭ＿ＶＥＲＳＩＯＮに等しい場合、そのブロードキャストスケジュールメッセージを保存し得る。デバイスは、新しいマルチプレックスに移動するとき、新しいマルチプレックス上でブロードキャストスケジュールフロー７０を受信し得る。

図１９に、受信機デバイス上のファイル配信フレームワーク（ＦＤＦ）のソフトウェアアーキテクチャを示す。詳細には、図１９は、ファイル配信フレームワークがファイル配信コア（ＦＤＣ）レイヤとファイル配信ファイル管理（ＦＤＭ）レイヤとを含み得ることを示している。ファイル配信コアは、データをトランスポートすること（たとえば、ＢＳＦを処理すること）と、データフローからデータを受信することと、受信したデータに対して様々な他の機能（たとえば、ＦＥＣ復号）を実行することとを担当し得る。ファイル配信ファイル管理レイヤは、ファイル配信コアレイヤによって受信されたデータをファイルとして管理することを担当し得る。ファイル管理はデバイスプラットフォーム依存である（たとえば、Ｌｉｎｕｘ（登録商標）とＷｉｎｄｏｗｓ（登録商標） Ｍｏｂｉｌｅは異なるファイル名規則を有する）ので、様々な実施形態では、各アプリケーションは、ファイル配信ファイル管理レイヤのそれ自体のインスタンスであり得る。これにより、ファイル配信コアがそれの上で動作するユニバーサルモバイル受信機（ＵＭＲ：universal mobile receiver）デバイスは、様々なタイプのデバイス上のアプリケーションとともに動作することが可能になる。

図２０に、異なるアプリケーションにわたるファイル共有をサポートするファイル配信フレームワークを実装するための実施方法２０００を示す。図２０は、ステップ２００２において、アプリケーションが、ファイルまたはディレクトリをキャプチャしたいという要求をファイル配信ファイル管理レイヤに発行することを示している。このキャプチャ要求は、「１回キャプチャ」要求または「自動キャプチャ」要求であり得る。ステップ２００４において、ファイル配信ファイル管理レイヤはファイルおよびディレクトリ名をファイル配信コアに渡し、ファイル配信コアはそれらを「希望ストリング（wanted string）」としてテーブルに記憶する。

ステップ２００６において、ファイル配信コアは、対応するブロードキャストスケジュール期間（ＢＳＰ）においてブロードキャストされた要素ごとに１つずつ、１つまたは複数のブロードキャストスケジュール記録（ＢＳＲ）を有する更新されたブロードキャストスケジュールメッセージ（ＢＳＭ）をブロードキャストスケジュールフロー（ＢＳＦ）から受信する。ステップ２００８において、ファイル配信コアは、各ブロードキャストスケジュール記録について、ブロードキャストスケジュール記録中のファイル／ディレクトリ名を希望ストリングと比較する。マッチがある場合、ステップ２０１０において、ファイル配信コアは、マッチしたブロードキャストスケジュール記録中の要素ＩＤによって識別される要素をデバイスがすでに有するかどうかを確かめるために、ファイル配信ファイル管理（ＦＤＭ）レイヤに確認する。その要素を有しない場合、ステップ２０１４において、ファイル配信コア（ＦＤＣ）は、マッチしたブロードキャストスケジュール記録（ＢＳＲ）中のブロードキャストスケジュール情報に従って要素を受信することをスケジュールする。ステップ２０１６において、ファイル配信コアは、スケジュールされた時間に、希望要素のための１つまたは複数のファイル配信プロトコル（ＦＤＰ：file delivery protocol）および／またはファイル配信制御プロトコル（ＦＤＣＰ：file delivery control protocol）メッセージを受信し、要素データを復元するために前方誤り訂正（ＦＥＣ）復号を実行する。ステップ２０１８において、ファイル配信コアは、受信した要素をファイル配信ファイル管理レイヤにフォワーディングする。ステップ２０２０において、ファイル配信ファイル管理レイヤは、アプリケーションのストレージポリシーに従って、（ファイルの形態の）要素をアプリケーションのストレージスペースに保存する。様々な実施形態では、ファイル配信ファイル管理レイヤはまた、要素が記憶されたメモリロケーションおよび要素のＩＤなど、様々ないくつかの追加情報を維持し得る。ステップ２０２２において、ファイル配信ファイル管理は、アプリケーションのためにファイルが受信されたことをアプリケーションに通知する。

図２１〜図２３は、受信機デバイス上のファイル配信フレームワーク（ＦＤＦ）の構造およびデータフローを示すソフトウェアアーキテクチャ図である。図２１は、異なるレイヤ間の対話を管理することと、「希望ストリング」テーブルを追跡し、維持することとを行うためにフレームワークによって使用され得る構造、データフローおよびハイレベルステップを示している。詳細には、図２１は、ファイル配信ファイル管理（ＦＤＭ）レイヤとファイル配信コア（ＦＤＣ）レイヤとの間の実施機能区分を示しており、ファイル配信ファイル管理レイヤはアプリケーション要求をファイル配信コアレイヤに渡す。たとえば、図２０は、アプリケーションが、ファイルを１回キャプチャしたい、あるいはファイルまたはディレクトリを自動キャプチャしたいという要求をファイル配信ファイル管理レイヤに発行し得る（矢印２１０１）ことを示している。この要求２００１は、図２０を参照しながら上記で説明したステップ２００２に対応する。図２１に示す実施形態では、ファイルおよびディレクトリはそれらの名前によって指定される。他の実施形態では、ファイルおよびディレクトリは、様々な命名および／または識別規則を使用することによって指定され得、それらのいくつかの例については以下で説明する。

図２１を参照すると、要求がアプリケーションによって発行された後、ファイル配信フレームワーク（ＦＤＦ）は、（たとえば、Ｃａｐｔｕｒｅ＿Ｏｎｃｅコマンドを介して）１回キャプチャされるように要求されたファイルまたはディレクトリの名前を、そのファイルまたはディレクトリ中のいくつかのファイルが正常に受信されるまで維持し得る。ファイル配信フレームワークはまた、（たとえば、Ａｕｔｏ＿Ｃａｐｔｕｒｅコマンドを介して）自動的にキャプチャされるようにアプリケーションによって要求されたファイルまたはディレクトリの名前を、アプリケーションがその要求をキャンセルするまで維持し得る。ファイル配信ファイル管理レイヤは、ファイルおよびディレクトリ名をファイル配信コアに渡し得る（矢印２１０２）。ファイル配信コアは、ファイルおよびディレクトリ名を「希望ストリング」としてテーブルに記憶し得る。

図２２は、受信機デバイス上のファイル配信フレームワーク（ＦＤＦ）の構造およびデータフローと、ファイル配信フレームワークがそれによってファイルを受信することを選択する決定プロセスとを示している。たとえば、ファイル配信コア（ＦＤＣ）レイヤは、ブロードキャストスケジュールフロー（ＢＳＦ）から更新されたブロードキャストスケジュールメッセージ（ＢＳＭ）を受信し得る（矢印２２０１）。ブロードキャストスケジュールメッセージは、対応するブロードキャストスケジュール期間（ＢＳＰ）においてブロードキャストされた要素ごとに１つずつ、１つまたは複数のブロードキャストスケジュール記録（ＢＳＲ₁、ＢＳＲ₂）を有し得る。ブロードキャストスケジュール記録は、対応する要素についての要素ＩＤと、要素中の（１つまたは複数の）ファイルについての１つまたは複数のファイル／ディレクトリ名と、ブロードキャストスケジュール情報とを含んでいることがある。ファイル配信コアは、各ブロードキャストスケジュール記録について、ブロードキャストスケジュール記録中のファイル／ディレクトリ名を希望ストリングと比較し得る（矢印２２０２）。マッチがある場合、ファイル配信コアは、マッチしたブロードキャストスケジュール記録中の要素ＩＤによって識別される要素をデバイスがすでに有するかどうかを確かめるために、ファイル配信ファイル管理レイヤに確認し得る（矢印２２０３）。その要素を有しない場合、ファイル配信コアは、マッチしたブロードキャストスケジュール記録中のブロードキャストスケジュール情報に従って要素を受信することをスケジュールし得る。様々な実施形態では、ファイルの異なるバージョンが異なる要素ＩＤを有し得ることに留意されたい。また、様々な実施形態では、以下でより詳細に説明するように、ファイル配信フレームワークが、デバイス上にすでに存在するファイルの更新を受信することを可能にするために、要素ＩＤに基づくフィルタ処理が使用され得ることに留意されたい。

図２２は、様々な実施形態では、ファイル配信ファイル管理（ＦＤＭ）レイヤが、管理要素テーブル（ＭＥＴ）を維持し得ることをも示している。管理要素テーブルは、ファイル配信フレームワークによって受信されたすべての要素に関する情報を含んでいることがある。様々な実施形態では、管理要素テーブルは、要素ＩＤ、ファイル名、（ある要素が複数のファイル名を有することができる実施形態における）エイリアス、ストレージ名、および他の属性など、様々ないくつかの追加情報をも含んでいることがある。管理要素テーブルについては、以下で図４０および図５７を参照しながらより詳細に説明する。

図２２に戻ると、様々な実施形態では、ファイル配信ファイル管理（ＦＤＭ）レイヤは、希望ストリングテーブル（希望ストリング）を維持し得る。希望ストリングテーブルは、アプリケーションによって要求されたファイルまたはディレクトリ名など、様々ないくつかの情報を含み得る（たとえば、ストリング）。希望ストリングテーブルは、アプリケーションからの要求を一意に識別する要求ハンドル（たとえば、Ｒｅｑ Ｉｎｓｔ）をも含み得る。様々な実施形態では、ファイル配信コアは、ファイル配信コアが特定の要求にマッチする要素を受信するとき、通知されるべきであるファイル配信ファイル管理レイヤインスタンスを識別するために、要求ハンドルを使用し得る。

図２２は、ファイル配信コア（ＦＤＣ）が、ブロードキャストスケジュールフロー（ＢＳＦ）上で、更新されたブロードキャストスケジュールメッセージ（ＢＳＭ）を受信し得ることをも示している。ファイル配信コアはまた、アプリケーションが関係している要素のみを選択的に受信するデータフィルタ処理ユニット２２１０を有し得る。すなわち、データフィルタ処理ユニット２２１０は、ブロードキャストスケジュールメッセージによって判断された、アプリケーションがそれを受信するために登録した、要素を選択的に受信することを担当し得る。様々な実施形態では、データフィルタ処理ユニットは、アプリケーションが関係している要素のいずれかがブロードキャストされることになるかどうかを判断するために、最新のブロードキャストスケジュールメッセージ中のフローブロードキャストスケジュール記録（ＦＢＳＲ）を処理し得る。様々な実施形態では、データフィルタ処理ユニットは、アプリケーションが関係している要素のダウンロードのために受信機デバイスをスケジュールするために、ブロードキャストスケジュールメッセージ内に含まれているブロードキャストスケジュール情報とともに、フローブロードキャストスケジュール記録を使用し得る。様々な実施形態では、ファイル配信コアは、アプリケーションが関係している要素を受信するためにスケジュールされた時間に受信機回路を起動するためにこのスケジュールを使用し得る。

図２３は、受信機デバイス上のファイル配信フレームワーク（ＦＤＦ）の例示的な構造およびデータフローと、受信機デバイス上のファイル配信フレームワークがそれによってファイルを受信および記憶し得るプロセスとを示している。図示の例では、ファイル配信コア（ＦＤＣ）は、スケジュールされた時間に、希望要素のためのＦＤＰ／ＦＤＣＰメッセージを受信し（矢印２３０１）、それをスクラッチスペース２３１０に記憶する。いくつかの実施形態では、ファイル配信コアはまた、要素データを復元するために、（それぞれ、ＦＥＣ被符号化シンボルおよびＦＥＣ符号化情報を搬送する）ＦＤＰ／ＦＤＣＰメッセージに対して前方誤り訂正復号を実行し得る。ファイル配信コアは、受信した要素をファイル配信ファイル管理（ＦＤＭ）レイヤにフォワーディングし得る（矢印２３０２）。ファイル配信ファイル管理レイヤは、アプリケーションのストレージポリシーに従って、ファイルの形態の要素をアプリケーションのストレージスペース２３１５に保存し得る（矢印２３０３）。様々な実施形態では、ファイル配信ファイル管理レイヤはまた、要素が記憶された場所（ストレージ）および要素のＩＤ（ＥＩＤ）など、様々ないくつかの追加情報を維持し得る。要素をアプリケーションのストレージスペースに保存した後に、ファイル配信ファイル管理レイヤは、アプリケーションのためにファイルが受信されたことをアプリケーションに通知し得る（矢印２３０４）。

図２４に、アプリケーションが関係している要素のみを選択的に受信することであって、受信がブロードキャストスケジュールメッセージ中の情報に基づいて判断される、受信することを行うために、ファイル配信コアにおいてデータフィルタ処理ユニット２２１０を実装するための実施方法２４００を示す。ステップ２４０２において、データフィルタ処理ユニット２２１０は、ブロードキャストスケジュール記録（ＢＳＲ）名または特性を識別するためにフローブロードキャストスケジュール記録（ＦＢＳＲ）ヘッダを処理する。判断ステップ２４０４において、データフィルタ処理ユニット２２１０は、受信したブロードキャストスケジュールメッセージ中に、関係がある未処理ブロードキャストスケジュール記録がある（すなわち、要求アプリケーションによって指定された命名規則または選択基準を記録が満たす）かどうかを判断し得る。ない場合（すなわち、判断ステップ２４０４＝「いいえ」）、データフィルタ処理ユニット２２１０は停止し得る。しかしながら、関係がある未処理ブロードキャストスケジュール記録がある場合（すなわち、判断ステップ２４０４＝「はい」）、ステップ２４０６において、データフィルタ処理ユニット２２１０は、フローブロードキャストスケジュール記録ボディ（たとえば、ＦＢＳＲボディ）から未処理ブロードキャストスケジュール記録を読み取る。ステップ２４０８において、データフィルタ処理ユニット２２１０は、ブロードキャストスケジュール記録を処理し、また、判断ステップ２４０４に戻って、関係があるすべてのフローブロードキャストスケジュール記録が処理されたかどうかを判断し得る。このプロセスは、関係があるすべてのフローブロードキャストスケジュール記録が処理されるまで（すなわち、判断ステップ２４０４＝「いいえ」）、続き得る。

図２５に、フローブロードキャストスケジュール記録中のブロードキャストスケジュール記録を処理するための実施方法２５００を示す。判断ステップ２５０２において、ファイル配信コアのデータフィルタ処理ユニット２２１０は、ブロードキャストスケジュール記録中に未処理フィールドがあるかどうかを判断する。未処理フィールドがある場合（すなわち、判断ステップ２５０２＝「はい」）、ファイル配信コアは、ブロードキャストスケジュール記録によって記述された要素を受信すべきかどうかを判断する。様々な実施形態では、対応するブロードキャストスケジュール記録が、希望ストリングに２ウェイトークンプレフィックスマッチする（two-way-token-prefix-match）少なくとも１つの属性ストリングを有し、要素がファイル配信コアのスクラッチスペース中に存在せず、および要素がアプリケーションのストレージスペース中に存在しないときはいつでも、ファイル配信コアは、その要素を受信することを決定し得る。ファイル配信コアがそれによって要素を受信することを決定するプロセスについては、以下でより詳細に説明する。

図２５に戻ると、要素が受信されるべきかどうかを判断することが、ステップ２５０４において開始し得、データフィルタ処理ユニット２２１０が、未処理ブロードキャストスケジュール記録から関係があるフィールドを読み取る。判断ステップ２５０６において、データフィルタ処理ユニット２２１０は、関係があるフィールド、または要素が、プレフィックスマッチングフィールドであるかどうかを判断し得る。要素がプレフィックスマッチングフィールドでない場合（すなわち、判断ステップ２５０６＝「いいえ」）、データフィルタ処理ユニット２２１０は、判断ステップ２５０２に戻って、ブロードキャストスケジュール記録中にそれ以上の未処理フィールドがあるかどうかを判断し得る。しかしながら、関係があるフィールドがプレフィックスマッチングフィールドである場合（すなわち、判断ステップ２５０６＝「はい」）、判断ステップ２５１０において、データフィルタ処理ユニット２２１０は、要素が希望ストリングに「２ウェイトークンプレフィックスマッチする」かどうかを判断し得る。

様々な実施形態では、ｓ１がｓ２のトークンプレフィックスであるか、またはｓ２がｓ１のトークンプレフィックスであるときはいつでも、ストリングｓ１はストリングｓ２に「２ウェイトークンプレフィックスマッチする」。様々な実施形態では、ファイル配信フレームワークにおけるトークンプレフィックスマッチは、ファイル中の構成要素として定義されたトークン、またはスラッシュ「／」句読文字によって分離されたディレクトリ名として定義されたトークンに基づき得る。たとえば、そのような実施形態では、ファイル名「／ｃｎｎ／ｔｅｃｈ／ｆ１．ｍｐ４」は、３つのトークン、すなわち、ｃｎｎ、ｔｅｃｈ、およびｆ１．ｍｐ４を有すると判断されることになる。したがって、ｓ１がトークンｔ１，１，ｔ１，２，．．．，ｔ１，Ｋを有するか、ｓ２がトークンｔ２，１，ｔ２，２，ｔ２，３，．．．，ｔ２，Ｌを有するか、ｋがＬ以下であるか、ｊ＝１，２，．．．，Ｋの場合にｔ１，ｊがｔ２，ｊに等しいか、のいずれかが当てはまる場合、ファイル配信フレームワークは、ストリングｓ１がストリングｓ２のプレフィックスであると見なし得る。これらの実施形態では、ブロードキャストスケジュール記録が、「／ｃｎｎ／ｔｅｃｈ／」についてファイルがブロードキャストされたことを示し、アプリケーションが「／ｃｎｎ／」下のいずれかのファイルを希望する場合、ファイル配信コアは、／ｃｎｎ／ｔｅｃｈ／についてブロードキャストされたファイルを受信すべきである。同様に、ブロードキャストスケジュール記録が、「／ｃｎｎ」についてファイルがブロードキャストされたことを示し、アプリケーションが「／ｃｎｎ／ｔｅｃｈ／」下のいずれかのファイルを希望する場合、ファイル配信コアは、「／ｃｎｎ／ｔｅｃｈ／」下にあり得るいかなるファイルをも逃すことを回避するように、／ｃｎｎについてブロードキャストされたファイルを受信すべきである。一実施形態では、すべてのストリングマッチはケースセンシティブであり得る。一実施形態では、ファイル配信コアは、ブロードキャストスケジュール記録がファイルのためのものであるのか、ファイルバンドルのためのものであるのかにかかわらず、同じストリングマッチングアルゴリズムを適用し得る。

図２５に戻ると、要素が希望ストリングに２ウェイプレフィックスマッチする場合（すなわち、判断ステップ２５１０＝「はい」）、フローは判断ステップ２５１２に進み得、データフィルタ処理ユニット２２１０が、ファイル配信ファイル管理（ＦＤＭ）レイヤが要素をすでに含んでいるかどうかを判断し得る。含んでいる場合（すなわち、判断ステップ２５１２＝「はい」）、処理は停止する。ファイル配信ファイル管理レイヤが要素を含んでいない場合（すなわち、判断ステップ２５１２＝「いいえ」）、データフィルタ処理ユニット２２１０は、対応する要素がすでにスケジュールされていなければ、ステップ２５１４において、対応する要素を受信することをスケジュールする。様々な実施形態では、対応する要素は、フローｉｄ（たとえば、ＦＬＯＷ＿ＩＤ）上のブロードキャストスケジュール記録（たとえば、ＢＣＡＳＴ＿ＳＣＨＥＤＵＬＥ＿ＲＥＣＯＲＤ）に従ってスケジュールされ得る。ステップ２５１６において、データフィルタ処理ユニット２２１０は、ブロードキャストスケジュール記録中の他のフィールドを処理する。

図２６に、受信機デバイス上のファイル配信フレームワーク（ＦＤＦ）の構造およびデータフローと、ブロードキャストスケジュール記録がそれによって処理され得るプロセスとを示す。上記で説明したように、対応するブロードキャストスケジュール記録（ＢＳＲ）が、希望ストリングに２ウェイトークンプレフィックスマッチする少なくとも１つの属性ストリングを有し、および要素がファイル配信コア（ＦＤＣ）のスクラッチスペース中に存在しない場合、ファイル配信コアは、その要素を受信し得る。矢印２６０１は、ファイル配信コアのデータフィルタ処理ユニット２２１０が、それによって、未処理ブロードキャストスケジュール記録から要素を読み取り、その要素がプレフィックスマッチングフィールドであるかどうかを判断し、その要素が希望ストリングに２ウェイトークンプレフィックスマッチするかどうかを判断する、データフローおよびプロセスを示している。矢印２６０２は、ファイル配信コアのデータフィルタ処理ユニット２２１０が、それによって、ファイル配信ファイル管理（ＦＤＭ）レイヤが要素をすでに含んでいるかどうかを判断する、データフローおよびプロセスを示している。ファイル配信ファイル管理レイヤが要素を含んでいない場合、ファイル配信コアは、対応する要素がすでにスケジュールされていなければ、対応する要素を受信することをスケジュールし得る。決定が、要素を受信することである場合、ファイル配信コア中のスケジューラ２６０５が、ブロードキャストスケジュール記録において指定されたブロードキャストウィンドウにおいて要素を受信することをスケジュールし得る。様々な実施形態では、ブロードキャストスケジュール記録が、アプリケーションによって要求されたファイルまたはディレクトリ名に２ウェイトークンプレフィックスマッチする少なくとも１つの属性ストリングを有し、およびブロードキャストスケジュール記録によって記述された要素がデバイス上にすでに存在しない場合、受信機デバイス上のファイル配信フレームワークは、その要素を受信することをスケジュールし得る。

図２７は、ファイルがブロードキャストされている時間中にファイルの受信が中断された状況を示すタイムライン図である。様々な実施形態では、部分的なファイルをスクラッチスペース２３１０に記憶することによって、ファイル配信コアは、ファイル転送が再開するのを待ち、ダウンロードされたファイルに対して前方誤り訂正コードを適用することの実現可能性に関して第２の判断を行うことができる。

図２８に、ダウンロードされたデータ２８０５がどのようにスクラッチスペースメモリ２３１０に渡され、記憶され得るかを示す。上記で説明したように、ファイル配信コアは、ダウンロードされたファイルに対して前方誤り訂正（ＦＥＣ）復号を適用する前にダウンロードされたファイルを記憶するための、ならびに復号されたファイルを保持するための、スクラッチスペースメモリ２３１０を有し得る。様々な実施形態では、ファイル配信コアは、未完了のダウンロードと、完了したが復号されていないダウンロードと、復号されたダウンロードとをスクラッチスペース２３１０に記憶する。

様々な状況では、スクラッチスペース２３１０は未完了のダウンロードを記憶し得る。たとえば、ダウンロードされたデータは、前方誤り訂正復号のためにスクラッチスペースに記憶され得る（すなわち、ダウンロードは未完了である）。様々な実施形態では、ダウンロードされたデータは、ブロードキャストが終わるまでスクラッチスペース２３１０において保たれ得、これは、図２７に示す中断されたデータ受信の状況に適応し得る。

上記で説明したように、スクラッチスペース２３１０は、完了したが復号されていないダウンロードをも記憶し得る。すなわち、様々な状況では、ダウンロードは、前方誤り訂正（ＦＥＣ）復号の成功に十分なデータを有し得るが、前方誤り訂正復号はまだ完了していない（すなわち、ダウンロードは完了したが復号されていない）。これらの状況では、ファイル配信コアは、これらのファイルが復号され得るまで、これらのファイルをスクラッチスペースに記憶し得る。いくつかの実施形態では、プロセッサ使用を制限するために、前方誤り訂正デコーダは、一度に１つのファイルを復号し得る。いくつかの実施形態では、前方誤り訂正デコーダは、デバイスがファイル配信データをダウンロードしているとき、ファイルを復号することを妨げられ得る。いくつかの実施形態では、スクラッチスペース２３１０は、要求アプリケーションにまだ配信されていない復号されたダウンロードを記憶し得る。

一実施形態では、スクラッチスペース２３１０は受信デバイスの内部メモリ上にあり得る。他の実施形態では、受信機デバイスは、内部メモリと外部メモリの両方の上にスクラッチスペース２３１０を有し得る。これらの実施形態では、ファイル配信フレームワークアプリケーションは、内部メモリストレージポリシーと外部メモリストレージポリシーの両方を有し得る。様々な実施形態では、ファイル配信コアは、内部メモリストレージポリシーを使用するアプリケーションには内部スクラッチスペースを使用し、外部メモリストレージポリシーを使用するアプリケーションには外部スクラッチスペースを使用し得る。

様々な実施形態では、スクラッチスペース管理ポリシーは、様々なメモリロケーションの間でデータを移動させるためのポリシーおよび機能を含み得る。スクラッチスペース管理ポリシーは、正常に復号された要素をスクラッチスペース２３１０からアプリケーションストレージスペースに移動させるための機能を含み得る。スクラッチスペース管理ポリシーは、スクラッチスペース２３１０上の無用なデータを周期的に削除するための機能を含み得る。スクラッチスペース管理ポリシーは、スクラッチスペース２３１０が、スペースを使い切るかまたはスペースを使い切ろうとしているとき、スクラッチスペース２３１０上のデータを削除するための機能を含み得る。デバイス上のファイル配信フレームワークは、様々なアプリケーションに内部メモリまたは外部メモリ中のスクラッチスペース２３１０を使用し得る。デバイス上のファイル配信フレームワークは、内部メモリストレージポリシーを使用するアプリケーションには内部メモリ中のスクラッチスペース２３１０を使用し得る。デバイス上のファイル配信フレームワークは、外部メモリストレージポリシーを使用するアプリケーションには外部メモリ中のスクラッチスペース２３１０を使用し得る。デバイス上のファイル配信フレームワークは、内部メモリおよびストレージポリシーと外部メモリおよびストレージポリシーとの任意の組合せとともにスクラッチスペース２３１０を使用し得る。

図２９に、要素を処理し、記憶するための実施方法２９００を示す。ステップ２９０２において、ファイル配信コアは、単一のファイルに対応する要素を正常に前方誤り訂正（ＦＥＣ）復号する。ステップ２９０４において、ファイル配信コアは、要素が受信されたことをファイル配信ファイル管理（ＦＤＭ）レイヤに通知する。ステップ２９０６において、ファイル配信ファイル管理レイヤは、要素におけるファイルについての記憶ロケーションを判断する。ステップ２９０８において、ファイル配信ファイル管理レイヤは、要素をスクラッチスペース２３１０から記憶ロケーションに移動させるようにファイル配信コアに指示する。ステップ２９１０において、デバイス上のファイル配信フレームワークは、アプリケーションのための要素を正常に受信した後、アプリケーションのストレージスペース２３１０中に十分なスペースがある場合、その要素をアプリケーションのストレージスペースに移動させる。

様々な実施形態では、ファイル配信コアは、スクラッチスペース上の無用なデータを周期的に削除し得る。様々な実施形態では、ファイル配信コアは、ブロードキャストが終了しており、ブロードキャストのためのユニキャストフォールバック機構がない、未完了のダウンロード中のデータを削除することによって、スクラッチスペースを周期的にクリーンアップし得る。様々な実施形態では、ファイル配信コアは、アプリケーションストレージスペースに移動されることに失敗した正常に復号された要素であって、デバイスプロビジョンパラメータ（たとえば、ＦＤＦ＿ＭＡＸ＿ＥＬＥＭＥＮＴ＿ＴＩＭＥ＿ＩＮ＿ＳＣＲＡＴＣＨ＿ＳＰＡＣＥ）によって示される秒数にわたってスクラッチスペース中にあった要素の中のデータを削除することによって、スクラッチスペースを周期的にクリーンアップし得る。様々な実施形態では、クリーンアップ期間は、ＦＤＦ＿ＳＣＲＡＴＣＨ＿ＳＰＡＣＥ＿ＣＬＥＡＮ＿ＵＰ＿ＰＥＲＩＯＤなどのデバイス構成パラメータによって制御され得る。様々な実施形態では、周期スクラッチスペースクリーンアップ機構は、スクラッチスペースのフットプリントを小さく保ち得る。一実施形態では、ファイル配信フレームワークは、ブロードキャストが終了しており、ブロードキャストのためのユニキャストフォールバックがない、未完了のダウンロードデータ（データは、ＦＥＣ復号の成功には十分でない）を、数（たとえば、ＦＤＦ＿ＳＣＲＡＴＣＨ＿ＳＰＡＣＥ＿ＣＬＥＡＮ＿ＵＰ＿ＰＥＲＩＯＤ）秒ごとに１回削除する。一実施形態では、ファイル配信フレームワークは、可変秒数（たとえば、ＤＦ＿ＭＡＸ＿ＥＬＥＭＥＮＴ＿ＴＩＭＥ＿ＩＮ＿ＳＣＲＡＴＣＨ＿ＳＰＡＣＥ秒）超前に正常に復号されたデータであって、アプリケーションストレージスペースに移動されることに失敗したデータを削除する。

様々な実施形態では、ファイル配信コアは、スクラッチスペースサイズが上限しきい値限界に到達した場合、ファイル配信コアがスクラッチスペースを使い切ったと判断し得る。ファイル配信コアは、スクラッチスペースが存在するメモリスペースが一杯である場合も、ファイル配信コアがスクラッチスペースを使い切ったと判断し得る。一実施形態では、内部スクラッチスペース上限が、相手先商標製造会社（ＯＥＭ）プロビジョニングデバイスパラメータ（たとえば、ＦＤＦ＿ＭＡＸ＿ＩＮＴＥＲＮＡＬ＿ＳＣＲＡＴＣＨ＿ＳＰＡＣＥ＿ＳＩＺＥ）によって指定され得る。ＯＥＭプロビジョニングデバイスパラメータ（たとえば、ＦＤＦ＿ＭＡＸ＿ＩＮＴＥＲＮＡＬ＿ＳＣＲＡＴＣＨ＿ＳＰＡＣＥ＿ＳＩＺＥ）がない場合、受信機デバイスは、内部スクラッチスペース上限としてパラメータのデフォルト値を使用し得る。様々な実施形態では、外部スクラッチスペース上限が、ＦＤＦ＿ＭＡＸ＿ＥＸＴＥＲＮＡＬ＿ＳＣＲＡＴＣＨ＿ＳＰＡＣＥ＿ＳＩＺＥなどのデバイスデバッグパラメータによって指定され得る。

図３０に、スクラッチスペースメモリから削除すべきアイテムを選択するための実施方法３０００を示す。様々な実施形態では、ファイル配信コアは、データがスクラッチスペースからいつ削除される必要があるか、およびどのデータが削除されるべきかを判断するために、一連のルールを使用する。たとえば、ファイル配信コアは、どのデータが削除されるべきかを判断するために、いくつかの優先ルール（たとえばルール１およびルール２）を使用し得、その優先ルールでは、ルールが優先順位で実装される（たとえば、ルール１はルール２よりも高い優先度を有する）。たとえば、第１のルール（ルール１）は、復号された要素が最高優先度を有することであり得、第２のルール（ルール２）は、完了したダウンロードが未完了のダウンロードよりも高い優先度を有することであり得る。様々な実施形態では、ファイル配信コアは、スクラッチスペースにおける各データ部分のためのエントリを用いたソートされたリストを維持し得る。様々な実施形態では、ファイル配信コアは、図３０に示すようにリストをソートするために優先ルール（たとえば、ルール１およびルール２）を使用し得る。

図３０のステップ３００２において、ファイル配信コアは、リストをソートするために第１のルール（ルール１）を適用する。ステップ３００４において、ファイル配信コアは、同じレベル（たとえば、レベル１）バケット中のエントリが、第１のルール（たとえば、ルール１）に従って同じ順位または優先度を有するように、数個のレベル１バケットを作成する。ステップ３００６において、ファイル配信コアは、ステップ３００４において生成された第１のレベル（たとえば、レベル１）バケットの各々に第２のルール（たとえば、ルール２）を適用する。これは、ステップ３００８に示すように、第１のレベル（たとえば、レベル１）バケットの各々を数個のより小さい第２のレベルバケットに分割することになる。これにより、同じレベル（たとえば、レベル２）バケット中のエントリは、第１および第２のルール（たとえば、ルール１およびルール２）に従って同じ順位または優先度を有し得る。一実施形態では、このプロセスは、スクラッチスペースに記憶されたアイテムのリスト中のエントリにすべてのルールが適用されるまで続けられ得る。

図３１に、スクラッチスペースに記憶されたアイテムのリストのリストへの方法３０００の適用例を示す。詳細には、図３１は、第１のルール（たとえば、ルール１）が、削除の対象となる、スクラッチスペース中のすべてのデータに適用され得ることを示している。第１のルールの適用により、スクラッチスペース中のデータはいくつかの第１のレベルバケット（レベル１バケット）に分離される。次いで、第２のルール（たとえば、ルール２）が第１のレベルバケットの各々に適用されて、データはいくつかの第２のレベルバケット（レベル２バケット）にさらに分離される。一実施形態では、第２のレベルバケットは、それらの最大スペースサイズに従って編成され得る。

様々な実施形態では、ファイル配信コアが要素のためのデータフローからデータを受信するたびに、また、スクラッチスペース中の、完了したが復号されていないダウンロードが前方誤り訂正（ＦＥＣ）復号のために選択されたとき、ファイル配信コアは、それがスクラッチを使い切ることになるかどうかを判断し得る。異なるサイズの符号化された要素が、前方誤り訂正復号のためにスクラッチスペース中の一時メモリの異なる量を必要とし得るので、後者の検査は必要であり得る。

様々な実施形態では、ファイル配信コアは、それがスクラッチスペースを使い切ることになることを検出した場合、ソートされたリスト中の最低順位をもつデータを削除し得る。ファイル配信コアは、新しいスペース要求が満たされ得るまで、データを削除し続け得る。様々な実施形態では、最低順位を有する複数のデータユニットがある場合、ファイル配信コアは、削除すべき１つまたは複数をランダムに選び得る。未完了のダウンロードが削除される必要があり、それのダウンロードがまだ進行中である場合、ＦＤＦは、削除の前にダウンロードをアボートし得る。ファイル配信コアは、要素をダウンロードすることを開始するとき、その要素ためのエントリをソートされたリストに追加し得る。スクラッチスペースを使い切るので、ダウンロードされている要素が削除されるように選択された場合、ファイル配信フレームワークは、それのダウンロードをキャンセルし得る。

様々な実施形態では、デバイス上のファイル配信フレームワークは、バイトでの内部スクラッチスペースサイズがＯＥＭプロビジョニングデバイスパラメータ（たとえば、ＦＤＦ＿ＭＡＸ＿ＩＮＴＥＲＮＡＬ＿ＳＣＲＡＴＣＨ＿ＳＰＡＣＥ＿ＳＩＺＥ）に等しいかまたはそれよりも大きいかどうかに基づいて、ファイル配信フレームワークが内部スクラッチスペースを使い切ることになると判断し得る。一実施形態では、ＯＥＭプロビジョニングデバイスパラメータ（たとえば、ＦＤＦ＿ＭＡＸ＿ＩＮＴＥＲＮＡＬ＿ＳＣＲＡＴＣＨ＿ＳＰＡＣＥ＿ＳＩＺＥ）がデバイス上にない場合、デバイスは、内部スクラッチスペースの上限としてパラメータのデフォルト値を使用し得る。一実施形態では、デバイス上のファイル配信フレームワークは、外部スクラッチスペースサイズがデバイスデバッグパラメータ（たとえば、ＦＤＦ＿ＭＡＸ＿ＥＸＴＥＲＮＡＬ＿ＳＣＲＡＴＣＨ＿ＳＰＡＣＥ＿ＳＩＺＥ）に等しいかまたはそれよりも大きいかどうかに基づいて、ファイル配信フレームワークが外部スクラッチスペースを使い切ることになると判断し得る。一実施形態では、デバイス上のファイル配信フレームワークは、スクラッチスペースが存在するメモリカードがスペースを使い切るかどうかに基づいて、ファイル配信フレームワークがスクラッチスペースを使い切ることになると判断し得る。一実施形態では、デバイス上のファイル配信フレームワークは、内部メモリストレージポリシーを使用するアプリケーションのためのデータフローからデータを受信したとき、ファイル配信フレームワークが内部スクラッチスペースを使い切ることになるかどうかを確認して判断し得る。一実施形態では、デバイス上のファイル配信フレームワークは、外部メモリストレージポリシーを使用するアプリケーションのためのデータフローからデータを受信したとき、ファイル配信フレームワークが外部スクラッチスペースを使い切ることになるかどうかを確認して判断し得る。一実施形態では、デバイス上のファイル配信フレームワークは、スクラッチスペース中の要素を前方誤り訂正（ＦＥＣ）復号することを開始するとき、ファイル配信フレームワークがスクラッチスペースを使い切ることになるかどうかを確認して判断し得る。一実施形態では、デバイス上のファイル配信フレームワークは、スクラッチスペースを使い切った場合、データをスクラッチスペースに書き込むことを停止し得る。一実施形態では、新しいニーズのための十分なスクラッチスペースがないことを検出したとき、デバイス上のファイル配信フレームワークは、新しいストレージ要求を満たすことを可能にする必要最小限の量のデータのみをスクラッチスペースから削除し得る。一実施形態では、スクラッチスペースを使い切ることに応答してスクラッチスペースからデータを削除するとき、デバイス上のファイル配信フレームワークは、ルール１がルール２よりも高い優先度を有し、ルール１−復号された要素が最高優先度を有する、およびルール２−完了したダウンロードが未完了のダウンロードよりも高い優先度を有する、という２つのルールに従って判断された、最低順位または優先度を有するデータを削除し得る。一実施形態では、スクラッチスペースを使い切ることに応答して、ダウンロードされている要素が削除されるように選択された場合、デバイス上のファイル配信フレームワークは、それのダウンロードをキャンセルし得る。

様々な実施形態では、ファイル配信フレームワークは、ファイル配信サービスの需要を十分にサポートするために複数のファイル配信データフローを使用し得る。これは、複数のマルチプレックス（たとえば、ワイドマルチプレックスおよびローカルマルチプレックス、または複数周波数ネットワーク展開における複数の無線周波数上の２つ以上のマルチプレックス）があり、マルチプレックスのうちの２つ以上が１つまたは複数のファイル配信データフローを有する場合であり得る。様々な実施形態では、これらのマルチプレックスはすべて、ＭｅｄｉａＦＬＯ技術などの同じブロードキャスト技術、異なるブロードキャスト技術（たとえば、ＭｅｄｉａＦＬＯ、ＩＳＤＢ−Ｔなど）、またはブロードキャスト技術の任意の組合せを使用し得る。

上記で説明したように、ファイル配信フレームワークは、複数のマルチプレックスがあるとき、複数のファイル配信データフローを使用し得る。一実施形態では、ファイル配信フレームワークは、２つ以上のデータフローをもつ単一のマルチプレックスがあるときも、複数のファイル配信データフローを使用し得る。たとえば、図３２は、複数のファイル配信データフローが、ファイル送信を搬送するための２つのデータフローを有する単一のマルチプレックス上でどのように使用され得るかを示すタイムライン図である。詳細には、図３２は、標準ファイル送信を搬送するために第１のデータフローがどのように与えられるか、およびより緊急のファイル送信を搬送するために別のデータフローがどのように与えられるかを示している。この実施形態では、より大きい下位優先度ファイル（たとえば、ファイル１）が送信されている間に緊急ファイル（たとえば、ファイル２）が送信のために受信された場合、緊急ファイル（すなわち、ファイル２）は、他の下位優先度ファイル（すなわち、ファイル１）の送信の結論を待つ必要なしに緊急データフロー上で送信され得る。このようにして、ファイル配信フレームワークは、単一のマルチプレックスを使用しながら、低優先度ファイルおよび高優先度ファイル、ならびに遅く到着した緊急ファイルの迅速な送信に適応することができる。

様々な実施形態では、ファイル配信フレームワークは、少なくとも１つのファイル配信データフローを有する各マルチプレックスについてブロードキャストスケジュールフローを含み得る。図３３に示すように、ブロードキャストスケジュールフロー上でブロードキャストされたブロードキャストスケジュールメッセージは、それぞれのマルチプレックス上のデータフローについてのブロードキャストスケジュールのみを記述し得る。言い換えれば、様々な実施形態では、マルチプレックスごとに１つのブロードキャストスケジュールメッセージ（ＢＳＭ）のみがあり得る。したがって、様々な実施形態では、単一のブロードキャストスケジュールメッセージが、異なるマルチプレックス上の送信についてのブロードキャストスケジュール情報を搬送し得る。図３３は、これらの実施形態では、異なるマルチプレックス（ＷＭ１、ＷＭ２）上の、さらには異なるブロードキャストネットワーク上の、ブロードキャストスケジュールフロー（ＢＳＦ１、ＢＳＦ２）の異なるバージョン（バージョン１、バージョン２）が、ディレクトリ情報メッセージ（ＤＩＭ）中の異なる記録によってどのようにシグナリングされ得るかを示している。受信機デバイスは、他のブロードキャストスケジュールフロー（たとえば、ＢＳＦ２）から独立して、あるブロードキャストスケジュールフロー（たとえば、ＢＳＦ１）上で、更新されたブロードキャストスケジュールメッセージを検出し、受信し得る。したがって、図３３に示すように、ディレクトリ情報メッセージ（ＤＩＭ）は、第１のワイドマルチプレックス（たとえば、ＷＭ１）が、第１のバージョン（たとえば、バージョン１）の第１のブロードキャストスケジュールフロー（たとえば、ＢＳＦ１）を含むことと、第２のワイドマルチプレックス（たとえば、ＷＭ１）が、第２のバージョン（たとえば、バージョン２）の第２のブロードキャストスケジュールフロー（たとえば、ＢＳＦ２）を含むこととを指定し得る。様々な実施形態では、ブロードキャストスケジュールフロー（たとえば、ＢＳＦ１、ＢＳＦ２）は、異なる無線周波ネットワーク（たとえば、ＲＦ１、ＲＦ２）上で同時にブロードキャストされ得る。様々な実施形態では、ディレクトリ情報メッセージは、ブロードキャストスケジュールメッセージを搬送するためにブロードキャストネットワーク中のトランスポートストリーム識別子（たとえば、ブロードキャストスケジュールフローについてのフローＩＤ）が使用されるブロードキャストネットワークに関するブートストラッピング情報を与えるために初期収集フロー（ＩＡＦ）において搬送される、オーバーヘッドメッセージであり得る。

図３４に、複数周波数ネットワーク（ＭＦＮ）において、受信機デバイスが、ブロードキャストスケジュールフローの更新があることを検出するが、同時に、受信機デバイスがその更新を受信することができないことを識別することが、どのように可能であるかの一例を示す。図３４に示す例では、初期収集フロー（たとえば、ＩＡＦ）は、第２の無線周波ネットワーク（たとえば、ＲＦ２）上のブロードキャストスケジュールフロー（たとえば、ＢＳＦ２）が更新されることを示している。しかしながら、デバイスは第２の無線周波ネットワーク（たとえば、ＲＦ２）に切り替えることができない。そのような状況では、受信機デバイスは、第２の無線周波ネットワーク（たとえば、ＲＦ２）上の（ＢＳＦ２によって表される）ファイル配信データフローを受信することができないので、ファイル配信フレームワークは追加のデータ損失を経験し得る。一実施形態では、受信機デバイスは、更新の存在を検出し、その更新を受信不可能と識別し得る。一実施形態では、受信機デバイスが更新を受信不可能と識別したとき、受信機デバイスは、データ損失を緩和するために復元プロセスをアクティブにし得る。

図３５に、受信機デバイスが、新しいマルチプレックスに移動したときに新しいマルチプレックスのためのブロードキャストスケジュールメッセージを受信することを強制され得るように、どのように構成され得るかを示す。様々な実施形態では、このモビリティ挙動は、ローカルマルチプレックス（たとえば、ＬＭ１、ＬＭ２）とワイドマルチプレックス（たとえば、ＷＭ１、ＷＭ２）の両方に適用可能であるように実装され得る。

図３６に、同じ無線周波数上の２つ以上のマルチプレックスをサポートするファイル配信フレームワーク構成を示す。すなわち、様々な実施形態では、異なるマルチプレックスが、必ずしも異なる無線周波数上になければならないとは限らない。たとえば、第１の無線周波数（たとえば、ＲＦ１）はローカルマルチプレックス（たとえば、ＬＭ＿Ｂ）とワイドマルチプレックス（たとえば、ＷＭ１）の両方を含んでいることがある。ファイル配信コアが同じ無線周波数上で複数のデータフローを受信するとき、それらのフローの総レートは、デバイスプラットフォーム固有パラメータ（たとえば、ＦＤＦ＿ＭＡＸ＿ＦＤ＿ＲＥＣＥＩＶＥ＿ＲＡＴＥ）以下であるべきである。ファイル配信フレームワークはバックグラウンドで動作し得るので、総フローレートのこの限界は、リアルタイムビデオ受信および表示のようなフォアグラウンドタスクに対するファイル配信フレームワークの影響を低減し得る。様々な実施形態では、データフローレートは、ブロードキャストスケジュールメッセージにおいてシグナリングまたは指定され得る。一実施形態では、ファイル配信コアが、データフィルタ処理決定に従って、同じ無線周波数上で複数のデータフローを同時に受信する必要があり、また、それらのフローの総レートが特定のパラメータ（たとえば、ＦＤＦ＿ＭＡＸ＿ＦＤ＿ＲＥＣＥＩＶＥ＿ＲＡＴＥ）を超える場合、ファイル配信コアは、選ばれたデータフローの総レートが特定のパラメータ（たとえば、ＦＤＦ＿ＭＡＸ＿ＦＤ＿ＲＥＣＥＩＶＥ＿ＲＡＴＥ）以下であるように、受信すべきデータフローのサブセットをランダムに選び得る。様々な実施形態では、ファイル配信フレームワークは、２つの異なるマルチプレックス上の２つのデータフローが同じ無線周波数上にあるかどうかを、それらの無線周波数ＩＤをフロープロトコルスタック（ＦＰＳ）から取得することによって判断し得る。

図３７に、ファイル配信コアが、異なる無線周波数上で独立してファイルダウンロードをスケジュールするように構成された、ファイル配信フレームワーク構成を示す。すなわち、複数周波数ネットワーク展開では、ファイル配信コアは、他の無線周波数（たとえば、ＲＦ２）の存在にかかわらず、ある無線周波数（たとえば、ＲＦ１）上でファイル配信データフロー（たとえば、データフロー１〜２）を受信することをスケジュールし、ファイル配信データフローをフロープロトコルスタック（たとえば、ＦＰＳ）に登録し得る。異なる無線周波数（たとえば、ＲＦ１、ＲＦ２）上で同時にブロードキャストされることになる複数のファイル（たとえば、ファイル１〜４）がある場合、ファイル配信コアは、１つの無線周波数しか受信することができないにもかかわらず、異なる周波数のすべてを受信することをスケジュールし得る。この実施形態では、デバイスが扱う必要があるサービスのすべて（ファイル配信サービスよりも高い優先度を有するリアルタイムサービスを含む）に関する情報をフロープロトコルスタックのみが所有するので、それがどの無線周波数を受信することができるかを決定することは、フロープロトコルスタックの責任である。一実施形態では、デバイス上のファイル配信フレームワークが、同じ無線周波数上で複数のデータフローを同時に受信する必要があり、また、それらのフローの総データレートが特定のパラメータ（たとえば、ＦＤＦ＿ＭＡＸ＿ＦＤ＿ＲＥＣＥＩＶＥ＿ＲＡＴＥ）を超えるとき、ファイル配信フレームワークは、選ばれたデータフローの総レートが特定のパラメータ（たとえば、ＦＤＦ＿ＭＡＸ＿ＦＤ＿ＲＥＣＥＩＶＥ＿ＲＡＴＥ）以下であるように、受信すべきデータフローのサブセットをランダムに選び得る。一実施形態では、デバイス上のファイル配信フレームワークは、他の無線周波数の存在にかかわらず、ある無線周波数上で（１つまたは複数の）ファイル配信データフローを受信することをスケジュールし得る。

図３８に、ファイル配信パイプ（ＦＤＰ）ペイロード（すなわち、ＦＤＣＰ／ＦＤＰサブレイヤによって実行されたＦＥＣ復号の結果）が、ファイル配信コアペイロード（ＦＤＣペイロード）および巡回冗長検査（ＣＲＣ）トレーラという２つの部分をどのように含み得るかを示す。ファイル配信パイプペイロードは、要素とファイル配信コアペイロードトレーラとを含み得る。一実施形態では、巡回冗長検査トレーラは、標準ＣＲＣ−ＣＣＩＴＴ生成多項式を使用して生成された１６ビットチェックサムであり得る。様々な実施形態では、ファイル配信コアは、１６ビット巡回冗長検査チェックサムトレーラに基づいて、受信したファイル配信コアペイロードに対して巡回冗長検査を実行し得る。巡回冗長検査が成功した場合、ファイル配信コアは、巡回冗長検査チェックサムを取り去り、ファイル配信コアペイロードをファイル配信ファイル管理（ＦＤＭ）レイヤに渡し得る。一実施形態では、デバイス上のファイル配信フレームワークは、ペイロード中の１６ビット巡回冗長検査チェックサムに基づいて、受信したファイル配信コアペイロードに対して巡回冗長検査を実行するために、ＣＲＣ−ＣＣＩＴＴ生成多項式を使用し得る。一実施形態では、デバイス上のファイル配信フレームワークは、受信したファイル配信コアペイロードに対するチェックサムが失敗した場合、そのペイロードを廃棄し得る。様々な実施形態では、アプリケーションが終了するとき、ファイル配信フレームワークは、そのアプリケーションに割り振られたリソースをリリースし得る。リリースされる割り振られたリソースは、希望ストリングテーブル中のエントリを含み得る。

上記で説明したように、ファイル配信ファイル管理（ＦＤＭ）レイヤは、ファイル配信コア（ＦＤＣ）によって受信されたデータをファイルとして管理することを担当し得る。ファイル配信フレームワークによって配信された各ファイルは、ＵＮＩＸファイル命名規則に従う１つまたは複数のデバイスプラットフォーム非依存ファイル名を有し得る（たとえば、ルートディレクトリが「／」によって表され、ディレクトリまたはファイルベース名が「／」によって分離される）。デバイス上のファイル配信フレームワークによって受信された各ファイルは、ファイルの物理記憶ロケーションを指定するストレージ名をも有し得る。ストレージ名はデバイスプラットフォーム依存であり得る。たとえば、ファイル名「／ｔａｄ／ｆ１．ｍｐ４」をもつファイルは、Ｗｉｎｄｏｗ ＭｏｂｉｌｅベースのデバイスおよびＬｉｎｕｘベースのデバイス上で、それぞれ「ｃ：＼ｆｄｒｏｏｔ＼ｔａｄ＼ｆ１．ｍｐ４」および「／ｅｘｔ／ｆｄｒｏｏｔ／ｔａｄ／ｆ１．ｍｐ４」に記憶され得る。様々な実施形態では、ファイル配信フレームワークとデバイスアプリケーションとの間の通信は、デバイスプラットフォーム依存ストレージ名にではなく、デバイスプラットフォーム非依存ファイル名に基づき得ることに留意されたい。

ファイル配信フレームワークは、アプリケーションのためのファイルを受信するとき、アプリケーションのストレージポリシーに従ってそれのファイル名をストレージ名に自動的にマッピングし、ストレージ名によって示されるロケーションにファイルを記憶し得る。アプリケーションのストレージポリシーは、ファイル配信フレームワークがアプリケーションのために受信したファイルを記憶するために使用することができる、メモリのタイプ（内部または外部）を指定し得る。一実施形態では、ファイル配信フレームワークに登録するとき、アプリケーションは、内部メモリのみ、最初に内部および次いで外部、外部メモリのみ、ならびに最初に外部および次いで内部、というストレージポリシーのうちの１つを指定し得る。一実施形態では、受信機デバイスは、「内部メモリのみ」ポリシーのみをサポートするように構成され得る。別の実施形態では、受信機デバイスは、「内部メモリのみ」および「外部メモリのみ」ポリシーのみをサポートするように構成され得る。さらに他の実施形態では、受信機デバイスは、すべてのストレージポリシー、またはそれらの任意の組合せをサポートするように構成され得る。

図３９に、一実施形態による、例示的なファイル命名規則と、ファイル名とストレージ名とのマッピングとを示す。この例では、ファイル配信フレームワークは、ファイル名における各セパレータ「／」がデバイスプラットフォーム依存セパレータ（たとえば、「＼」）に変換され、また、変換されたストリングが、アプリケーションのストレージポリシーによって選択されたメモリタイプ（たとえば、内部、外部）に対応する物理ベースディレクトリ（たとえば、Ｃ：、Ｄ：）の後に付加されるように、ファイル名をストレージ名にマッピングする。一実施形態では、アプリケーションは、登録段階中に物理ベースディレクトリを与え得る。一実施形態では、アプリケーションは、ファイル配信フレームワークによって受信されたファイルにアプリケーションが最初にアクセスする前に、それのファイル名をストレージ名にマッピングすることと、次いでファイルにアクセスするためにストレージ名を使用することとを行うようにファイル配信フレームワークに依頼し得る。

図４０に、例示的な管理要素テーブル（ＭＥＴ）を示す。上記で説明したように、各アプリケーションのファイル配信ファイル管理（ＦＤＭ）レイヤは、ファイル配信フレームワークがアプリケーションのために受信しており、デバイス上にまだ存在する、すべての要素（ファイルまたはファイルバンドル）に関する情報を有する管理要素テーブルを維持し得る。管理要素テーブルは、要素ＩＤ（ＥＩＤ）、ファイル名（名前）、ストレージ名（ストレージ）、参照番号（Ｒｅｆ）および他の属性（Ａｔｔｒ）など、様々ないくつかの情報を含んでいることがある。一実施形態では、ファイル配信フレームワークは、ファイル名におけるルートディレクトリ「／」を、ストレージポリシーに従って選択された物理メモリのルートにおける「ｆｄｒｏｏｔ」にマッピングすることと、ルートディレクトリ「／」の後のファイル名の残部における各セパレータ「／」をデバイスプラットフォーム依存セパレータに変換することと、変換されたストリングを「ｆｄｒｏｏｔ／」の後に付加することとによって、ファイル名をストレージ名にマッピングし得る。

一実施形態では、デバイス上のファイル配信フレームワークは、ファイル名における各セパレータ「／」をデバイスプラットフォーム依存セパレータに変換することと、次いで、変換されたストリングを、アプリケーションのストレージポリシーによって選択されたメモリタイプに対応する物理ベースディレクトリの後に付加することとによって、ファイル名をストレージ名にマッピングし得る。一実施形態では、デバイス上のファイル配信フレームワークは、アプリケーションのための「内部メモリのみ」ストレージポリシーをサポートし得る。一実施形態では、デバイス上のファイル配信フレームワークは、アプリケーションのための「外部メモリのみ」ストレージポリシーをサポートし得る。

様々な実施形態では、アプリケーションは、ファイル配信フレームワークに登録するとき、アプリケーションのストレージポリシーと、ファイル配信フレームワークがアプリケーションのために受信されたすべてのファイルを保存し得る、アプリケーションの物理ベースディレクトリと、アプリケーションのストレージクォータ（quota）とを指定し得る。様々な実施形態では、メモリタイプごとに１つずつ、複数のベースディレクトリがあり得る。これらの実施形態では、ファイル配信フレームワークは、どのベースディレクトリが使用されるべきかを決定するためにアプリケーションのストレージポリシーを使用し得る。一実施形態では、登録はファイル配信ファイル管理レイヤによって扱われ得る。一実施形態では、デバイス上のファイル配信フレームワークは、ストレージポリシーと、物理ベースディレクトリと、ストレージクォータとを用いてアプリケーション登録をサポートし得る。一実施形態では、デバイス上のファイル配信フレームワークは、登録中に指定されたアプリケーションのストレージスペース上のクォータをエンフォースし得る。

図４１に、ファイル配信ファイル管理（ＦＤＭ）レイヤが、それによって、アプリケーションのストレージスペースを管理し、それと対話するように構成され得る、実施方法４１００を示す。ステップ４１０２において、ファイル配信ファイル管理レイヤは、ファイル配信フレームワーク（ＦＤＦ）へのアプリケーションの登録を扱い、アプリケーションが登録中にそれのストレージポリシーを指定することを可能にする。ステップ４１０４において、ファイル配信ファイル管理レイヤは、受信されるべきファイルのためのアプリケーションストレージスペースがあるかどうかを確認する。ステップ４１０６において、ファイル配信ファイル管理レイヤは、アプリケーションのストレージポリシーに従って、受信したファイルをアプリケーションストレージスペースに保存する。ステップ４１０８において、ファイル配信ファイル管理レイヤは、アプリケーションの要求に従って、アプリケーションのストレージスペースに記憶されたファイルを削除する。

図４２に、受信されるべき要素のためのアプリケーションのストレージスペースを確認するための、ファイル配信フレームワーク（ＦＤＦ）において実装され得る実施方法４２００を示す。ステップ４２０１において、ファイル配信フレームワークは、ＦＤＰ／ＦＤＣＰメッセージから要素サイズ情報を取得し、その要素のためにアプリケーションのストレージスペース中に十分なスペースがあるかどうかを判断する。ステップ４２０２において、ファイル配信フレームワークは、受信されるべき要素を記憶するのに十分なアプリケーションストレージスペースがないかどうかをアプリケーションに通知する。ステップ４２０３において、ファイル配信フレームワークは、ダウンロードがアプリケーションによってキャンセルされない限り、要素を受信し続ける。

図４３に、アプリケーションのストレージが、ブロードキャストスケジュール記録中の属性ストリングにマッチする受信されるべき要素（たとえば、ファイルまたはファイルバンドル）のための十分なスペースを有するかどうかを判断するための上記で説明した方法４２００において実装され得る、アプリケーションレイヤ（アプリレイヤ）とファイル配信フレームワーク（ＦＤＦ）との間のデータフローおよびコールフロー対話を示す。動作４３０１において、ファイル配信フレームワークは、ＦＤＰ／ＦＤＣＰメッセージから要素サイズ情報を取得し、その要素を受信および記憶するためにアプリケーションのストレージスペース中に十分なスペースがないかどうかを判断し得る。コールフロー４３０２において、ファイル配信フレームワークは、受信されるべき要素のための不十分なアプリケーションストレージスペースがあるかどうかをアプリケーションに通知する。動作４３０３において、ファイル配信フレームワークは、アプリケーションがそれのストレージスペースから何らかのデータを削除するのを待ち、要素を受信し続け得る。コールフロー４３０４において、アプリケーションは、要素を受信することを停止するようにファイル配信フレームワークに命令するキャンセル通知をファイル配信フレームワークに発行し得る。

図４４に、対応するアプリケーションのストレージスペースへの受信したファイルの移動のための、ファイル配信フレームワークにおいて実装され得る実施方法４４００を示す。ステップ４４０２において、ファイル配信コアは、ファイルに対応するファイル配信コアペイロードを正常に受信する。ステップ４４０４において、ファイル配信コアは、ファイル配信コアペイロードが受信されたことをファイル配信ファイル管理レイヤに通知し、スクラッチスペースにおけるファイル配信コアペイロードの記憶ロケーションをファイル配信ファイル管理レイヤに渡す。ステップ４４０６において、ファイル配信ファイル管理レイヤは、ファイル配信コアペイロード中のトレーラを処理し、渡されたファイル配信コアペイロード中の要素が単一のファイルに対応するかどうかを判断する。ファイル配信ファイル管理レイヤは、ファイルの名前をストレージ名（たとえば、Ｐ１）にマッピングし得る。一実施形態では、ファイルが複数の名前を有する場合、ファイル配信ファイル管理レイヤは、第１の名前のみをストレージ名にマッピングし得る。ステップ４４０８において、ファイル配信ファイル管理レイヤは、ファイル配信コアペイロードのための十分なアプリケーションストレージスペースがあるかどうかを判断し、そのペイロードをスクラッチスペースメモリから、ストレージ名（たとえば、Ｐ１）によって識別されるアプリケーションストレージスペースロケーションに移動させる。一実施形態では、ファイルの名前のうちの１つが管理要素テーブル（ＭＥＴ）中にすでに存在する場合、十分なアプリケーションストレージスペースがあるかどうかを判断するために、ファイル配信コアペイロードのための追加のメモリが使用され得る。一実施形態では、この追加のメモリは、ＦＤＣ＿ｐａｙｌｏａｄ＿ｓｉｚｅとｏｌｄ＿ｆｉｌｅ＿ｓｉｚｅとの間の差など、２つの変数の値の間の差を表すロケーションとして定義され得る。ステップ４４１０において、ファイル配信ファイル管理レイヤは、ファイルの移動が完了したことをファイル配信コアに通知する。ステップ４４１２において、ファイル配信ファイル管理レイヤは、記憶されたファイル配信コアペイロード（たとえば、Ｐ１に記憶されたペイロード）からトレーラを取り去り、ファイルのためのエントリを管理要素テーブル中に追加する（たとえば、図４０参照）。一実施形態では、ファイル配信コアペイロード中のトレーラが、ファイルが複数のファイル名を有することを示す場合、ファイル配信ファイル管理レイヤは、ファイル名のすべてを名前付き記憶ロケーション（たとえば、Ｐ１）にマッピングする情報を管理要素テーブルに追加し得る。ステップ４４１４において、ファイル配信ファイル管理レイヤは、ファイルがキャプチャされたことをアプリケーションに通知する。

図４５に、ファイル配信フレームワーク（ＦＤＦ）が受信したファイルをアプリケーションストレージスペースに移動させる間に方法４４００において起こり得る、アプリケーションレイヤ（アプリレイヤ）と、ファイル配信コア（ＦＤＣ）レイヤと、ファイル配信ファイル管理（ＦＤＭ）レイヤとの間のデータフローおよび対話を示す。動作４５０１において、ファイル配信コアはファイル配信コアペイロードを受信する。コールフロー４５０２において、ファイル配信コアは、ファイル配信コアペイロードが受信されたことをファイル配信ファイル管理レイヤに通知する。動作４５０３において、ファイル配信ファイル管理レイヤは、ファイル名をストレージ名（たとえば、Ｐ１）にマッピングする。動作４５０４において、ファイル配信ファイル管理レイヤは、十分なストレージスペースがある場合、ファイル配信コアペイロードをスクラッチスペースから記憶ロケーション（たとえば、Ｐ１）に移動させる。コールフロー４５０５において、ファイル配信ファイル管理レイヤは、ファイル配信コアペイロードの移動が完了したことをファイル配信コアに通知する。動作４５０６において、ファイル配信ファイル管理レイヤは、記憶ロケーション（たとえば、Ｐ１）に記憶されたファイル配信コアペイロードからトレーラを取り去る。コールフロー４５０７において、ファイル配信ファイル管理レイヤは、キャプチャが完了したことをアプリケーションレイヤに通知する。

一実施形態では、受信したファイルが、デバイス上にすでに存在するファイルの古いバージョンを置き換えるべきであると判断され、その置換が失敗した（たとえば、古いバージョンが、図４５の第５のステップ４５０５においてロックされている）場合、ファイル配信コアは、コールフロー４５０７において、エラーメッセージをファイル配信ファイル管理レイヤに送り得る。このエラーメッセージを受信した後に、ファイル配信ファイル管理レイヤは、ファイル配信コアから「移動完了」メッセージを受信するまで、またはコールフロー４５０５における要求を所定の回数（たとえば、ＦＤＦ＿ＭＡＸ＿ＦＩＬＥ＿ＲＥＰＬＡＣＥ＿ＲＥＴＲＹ＿ＮＵＭ）繰り返すまで、コールフロー４５０５における要求を周期的に再試行し得る。一実施形態では、再試行期間（または回数）は、ある秒数などのデバイスパラメータ（たとえば、ＦＤＦ＿ＦＩＬＥ＿ＲＥＰＬＡＣＥ＿ＲＥＴＲＹ＿ＰＥＲＩＯＤ）によって定義され得る。すべての試行が失敗した場合、ファイル配信フレームワークは、データをスクラッチスペースからアプリケーションストレージスペースに移動させることを断念し得る。

一実施形態では、デバイスパラメータ（たとえば、ＦＤＦ＿ＭＡＸ＿ＥＬＥＭＥＮＴ＿ＴＩＭＥ＿ＩＮ＿ＳＣＲＡＴＣＨ＿ＳＰＡＣＥ）によって示されるような、あらかじめ定義された秒数超にわたってスクラッチスペース中にあった完了したダウンロードが、周期クリーンアップ機構において削除され得る。一実施形態では、デバイス上のファイル配信フレームワークは、受信したファイルをアプリケーションストレージスペースに移動させることに失敗した場合、その移動が成功するまで、またはあらかじめ定義された最大数の再試行が試みられるまで、数秒ごとに１回ファイルを移動させることを再試行し続け得る。その後、周期クリーンアップ機構は、適切な時間に、移動されていないファイルをスクラッチスペースから削除し得る。

図４６に、複数のファイル名が単一のストレージ名にどのようにマッピングされ得るかを示すソフトウェアアーキテクチャおよびデータ構造図を示す。詳細には、図４６は、複数のファイル名（たとえば、／ｍｐｖ／ｃｎｎ／ｆ１．ｍｐ４、／ｍｐｖ／ｃｎｎｈｌ／ｆ１．ｍｐ４）が、管理要素テーブル（ＭＥＴ）において同じストレージ名（たとえば、Ｄ：＼ｆｄｒｏｏｔ＼ｃｎｎ＼ｆ１．ｍｐ４）にマッピングされる実施形態を示している。ファイルが受信されたとき（コールフロー４６０２）、ファイルはリネームされ得、そのファイル名および記憶ロケーションは管理要素テーブルに保存され得る（コールフロー４６０３）。この図は、複数のファイル名が、管理要素テーブルにおいて識別される単一のストレージ名にどのようにマッピングされ得るかをも示している。

図４７に、受信したファイルを記憶するのに不十分なアプリケーションストレージスペースがある状況を扱うための、ファイル配信フレームワークにおいて実装され得る実施方法４７００を示す。上記で説明したように、ファイル配信ファイル管理（ＦＤＭ）レイヤが、ファイル配信コアペイロードのための不十分なアプリケーションストレージスペースがあると判断するか、またはアプリケーションストレージスペースが一杯であると判断した場合、配信ファイル管理レイヤは、ステップ４７０２において、アプリケーションがスペースを解放することを要求する要求をアプリケーションレイヤに発行し得る。このメッセージに応答して、ステップ４７０４において、アプリケーションは一部のファイルを削除する。ステップ４７０６において、アプリケーションは、ファイル削除によって一部のストレージスペースが解放されたことをファイル配信フレームワークに通知する。ステップ４７０８において、ファイル配信フレームワークは、受信したファイルをスクラッチスペースからアプリケーションストレージスペースに移動させる。ステップ４７１０において、ファイル配信ファイル管理レイヤは、ファイルがキャプチャされたことをアプリケーションに通知する。ファイル配信フレームワークが、ストレージスペースが解放されたという通知をアプリケーションから一度も受信しない場合、受信したファイルは、スクラッチスペース周期クリーンアップ機構によって削除されるまでスクラッチスペースにおいて保たれ得る。

図４８に、方法４７００の実行における、アプリケーションレイヤ（アプリレイヤ）とファイル配信フレームワーク（ＦＤＦ）との間のデータフローおよびコールフロー対話を示す。コールフロー４８０１において、ファイル配信フレームワークは、ファイル配信コアペイロードのための不十分なアプリケーションストレージスペースがあることをアプリケーションに通知するための通知をアプリケーションレイヤに送る。コールフロー４８０２において、アプリケーションレイヤは、アプリケーションストレージスペースからファイルの一部を削除するようにとの命令をファイル配信ネットワークに直接送る。コールフロー４８０３において、アプリケーションレイヤは、（たとえば、ファイルを削除することによって）ストレージスペースが利用可能になったことを示す通知をファイル配信フレームワークに送る。動作４８０４において、ファイル配信フレームワークは、ファイルをスクラッチスペースからアプリケーションストレージスペースに移動させる。コールフロー４８０５において、ファイル配信フレームワークは、ファイルキャプチャが完了したことをアプリケーションレイヤに通知する。

図４９に、ファイル配信フレームワークがファイルを削除するというアプリケーション要求に応答してアプリケーションストレージスペースからファイルを削除するための、ファイル配信フレームワークによって実装され得る例示的な方法４９００を示す。あるファイル名によって識別されるファイルを削除したいという、アプリケーションからの要求に応答して、ステップ４９０２において、ファイル配信フレームワークは、そのファイル名に対応する、管理要素テーブル（ＭＥＴ）中のエントリを探索し、見つける。判断ステップ４９０３において、ファイル配信フレームワークは、管理要素テーブルから、ファイルが２つ以上のファイル名を有するかどうかを判断し得る。エントリが２つ以上のファイル名を有する場合（すなわち、判断ステップ４９０３＝「はい」）、ステップ４９０４において、ファイル配信フレームワークは、単にエントリからファイル名を除去し、プロセスを終了する。したがって、一実施形態では、削除のために指定されたファイルが複数のファイル名を有する場合、ファイル配信フレームワークは、そのファイルを削除することなしにファイル名を除去し得る。ファイル配信フレームワークが、削除のために識別されたファイルに関連付けられたただ１つのファイル名があると判断した場合（すなわち、判断ステップ４９０３＝「いいえ」）、ステップ４９０６において、ファイル配信フレームワークは、記憶ロケーション中のそのファイルを削除し、管理要素テーブルからエントリを除去する。判断ステップ４９０８において、ファイル配信フレームワークは、ファイル削除が成功したかどうかを判断し得る。削除が成功した場合（すなわち、判断ステップ４９０８＝「はい」）、プロシージャは終了する。削除が成功しなかった場合（すなわち、判断ステップ４９０８＝「いいえ」）、ステップ４９１０において、ファイル配信フレームワークは、削除要求を再試行することなしに、アプリケーションにエラーを返し、プロシージャを終了する。一実施形態では、デバイス上のファイル配信フレームワークは、ファイル名によって指定されたファイルの削除をアプリケーションがそれを介して要求し得るインターフェースを与え得る。

上記で説明したように、ファイル配信フレームワークは、複数のファイルを互いにバンドルすることと、ファイルバンドルを単一の要素としてブロードキャストすることとをサポートし得る。前述のように、これは、前方誤り訂正（ＦＥＣ）オーバーヘッドを低減する（すなわち、要素が大きくなるほど、必要とされるＦＥＣオーバーヘッドは少なくなる）ことと、配信信頼性を改善する（すなわち、要素が大きくなるほど、時間ダイバーシティは大きくなる）こととに役立つ。ファイルバンドリングは、特に、複数の小さいファイルを配信するのに有用である。様々な実施形態では、ファイルバンドル機能は、ファイル配信コアに対する最小の影響を有するファイル配信ファイル管理レイヤ機能として実装され得る。様々な実施形態では、ファイルバンドル機能は、アプリケーションにとって透過的な機能を与える形で実装され得る。

図５０に、ファイル配信フレームワーク内のファイルバンドル機能として実装され得る例示的な方法５０００を示す。ステップ５００２において、ファイル配信コアは、ファイルバンドルについてのブロードキャストスケジュール記録（ＢＳＲ）がいずれかのアプリケーション要求にマッチするかどうかを判断するために、２ウェイプレフィックスマッチング方式を使用する。一実施形態では、これは、図２５〜図２６を参照しながら上記で説明したような、個々のファイルに対して使用される同じ２ウェイプレフィックスマッチング方式であり得る。判断ステップ５００４において、ファイル配信コアは、２ウェイプレフィックスマッチがあるかどうかを判断し得る。マッチがない場合（すなわち、判断ステップ５００４＝「いいえ」）、ファイル配信コアはファイルバンドルを無視する。マッチがある場合（すなわち、判断ステップ５００４＝「はい」）、ステップ５００６において、ファイル配信コアは、選択ストリングをファイル配信ファイル管理レイヤに渡す。この選択ストリングは、アプリケーションがそれを受信することに関係しているファイルバンドル内のファイルを指定し得る。ステップ５００８において、ファイル配信コアは、ファイルバンドルが受信されるべきか否かを判断するようにファイル配信ファイル管理レイヤに要求するメッセージをファイル配信ファイル管理レイヤに送り得る。一実施形態では、ステップ５００８におけるこの要求の一部として、選択ストリングがファイル配信ファイル管理レイヤに渡され得る。一実施形態では、ステップ５００６とステップ５００８は組み合わせられて、ファイルバンドルが受信されるべきかどうかを判断するようにとの要求の一部として選択ストリングを渡す１つのユニット／関数呼出しになり得る。

判断ステップ５０１０において、ファイル配信ファイル管理レイヤは、ファイルバンドルがファイル配信ファイル管理レイヤによって受信され得るかどうか、ならびにファイルバンドルが受信される必要があるかどうかを判断し得る。ファイル配信ファイル管理レイヤが、ファイルバンドルが受信される必要がないと判断した場合（すなわち、判断ステップ５０１０＝「いいえ」）、ファイルバンドルは無視される。ファイルバンドルがファイル配信ファイル管理レイヤによって受信される必要がある場合（すなわち、判断ステップ５０１０＝「はい」）、ステップ５０１２において、ファイル配信ファイル管理レイヤは、ファイルバンドルに対応する要素のための要素ＩＤおよび選択ストリングを維持する。ステップ５０１４において、ファイル配信コアは、ファイルバンドルに対応するファイル配信コアペイロードを受信し、それをファイル配信ファイル管理レイヤに渡し得る。ステップ５０１６において、ファイル配信コアは、ファイル配信コアペイロードをファイル配信ファイル管理レイヤに渡す。ステップ５０１８において、ファイル配信ファイル管理レイヤは、ファイル配信コアペイロードトレーラを処理し、ファイル配信コアペイロードがファイルバンドルであるかどうかを判断する。ステップ５０２０において、ファイル配信ファイル管理レイヤは、保存されるべきであるファイルバンドル内のファイルを識別するために、ファイル配信ファイル管理レイヤがファイルバンドルのために保存した選択ストリングを使用する。

図５１に、方法５０００の動作を実装する際の、アプリケーションレイヤ（アプリレイヤ）と、ファイル配信コア（ＦＤＣ）レイヤと、ファイル配信ファイル管理（ＦＤＭ）レイヤとの間のデータフローおよび対話コールフローを示す。動作５１０１において、ブロードキャストスケジュール記録（ＢＳＲ）マッチングエントリを生成するために、ファイルバンドルブロードキャストスケジュール記録が、ファイル配信コアによって受信され、２ウェイプレフィックスマッチする。コールフロー５１０２において、ファイル配信コアは、選択ストリングと要素ｉｄと要素タイプとをファイル配信ファイル管理レイヤに渡し、そこで、ファイルがすでに存在するかどうか、およびファイルバンドルがファイル配信ファイル管理レイヤによって受信されるべきかどうかが確認される。動作５１０３において、ファイルバンドルに対応する要素、またはファイル配信コアペイロードが、ファイル配信コアによって受信され、ファイル配信ファイル管理レイヤに渡される。動作５１０４において、ファイル配信ファイル管理レイヤは、ファイル配信コアペイロードを処理して、受信したファイルバンドルから特定のファイルを選択し、選択されたファイルをメモリに保存する。

図５２に、保存するために受信したファイルバンドル中のファイルを選択するためにファイル配信ファイル管理レイヤによって使用されるべき選択ストリングを生成するために使用され得る例示的な方法５２００を示す。ステップ５２０２において、ファイル配信コアは、ブロードキャストスケジュール記録中のストリングが希望ストリング（すなわち、受信のためのファイルを選択するためにアプリケーションによって識別されたストリング）に２ウェイトークンプレフィックスマッチするかどうかを判断する。マッチする場合、ステップ５２０４において、ファイル配信コアは、最長ストリングをファイル配信コアの選択ストリングとして設定し、選択ストリングをファイル配信ファイル管理レイヤに渡す。ステップ５２０６において、ファイル配信ファイル管理レイヤは、ファイルがすでに存在するかどうかを確認する。ステップ５２０８において、ファイル配信ファイル管理レイヤは、ファイルバンドルがファイル配信ファイル管理レイヤによって受信されるべきかどうかを判断する。ファイル配信ファイル管理レイヤが、ファイルバンドルが受信されるべきであると判断した場合、ステップ５２１０において、ファイル配信ファイル管理レイヤは、ファイルバンドルに対応する要素のための選択ストリングを維持する。

図５３に、方法５２００における、アプリケーションレイヤ（アプリレイヤ）と、ファイル配信コア（ＦＤＣ）レイヤと、ファイル配信ファイル管理（ＦＤＭ）レイヤとの間のデータフローおよび対話コールフローの一例を示す。上記で説明したように、選択ストリングは、保存されるべきファイルバンドル中のファイルを選択するためにファイル配信ファイル管理レイヤによって使用され得る。ブロードキャストスケジュール記録上のストリングが希望ストリングに２ウェイトークンプレフィックスマッチする場合、ファイル配信コアは、これらの２つのうちの最長ストリングを選択ストリングとして使用し、それをファイル配信ファイル管理レイヤに渡し得る。図５３の図示の例では、動作５３０１において、（ストリング「／ｉｔｖ／ｃｎｎ／」を有する）ファイルバンドルブロードキャストスケジュール記録が、ファイル配信コアによって受信され、希望ストリング「／ｉｔｖ／ｃｎｎ／ｅ１／」に２ウェイプレフィックスマッチする。動作５３０２において、ファイル配信コアは、選択ストリング「／ｉｔｖ／ｃｎｎ／ｅ１／」を生成し、選択ストリングと要素ｉｄと要素タイプとをファイル配信ファイル管理レイヤに渡し、それらは、ファイルがすでに存在するかどうか、およびファイルバンドルがファイル配信ファイル管理レイヤによって受信されるべきかを判断する際に使用される。ファイル配信ファイル管理レイヤが、ファイルバンドルがファイル配信ファイル管理レイヤによって受信され得、受信される必要があると判断した場合、動作５３０３において、ファイル配信ファイル管理レイヤは、ファイルバンドルに対応する要素のための選択ストリング「／ｉｔｖ／ｃｎｎ／ｅ１／」を維持する。一実施形態では、デバイス上のファイル配信フレームワークは、ファイルバンドルブロードキャストスケジュール記録中の属性ストリングが希望ストリングのプレフィックスであると判断した場合、ファイルバンドルのための選択ストリングとして希望ストリングを使用する。

図５４に、ファイルバンドルが受信されるべきかどうかを判断するために例示的な方法５４００が使用され得ることを示す。ステップ５４０２において、ファイル配信コアは、ファイルバンドルが受信されるべきかどうかをファイル配信ファイル管理（ＦＤＭ）レイヤが示すことを要求する、ファイルバンドル情報と選択ストリングとを含む、要求をファイル配信ファイル管理レイヤに送る。判断ステップ５４０４において、ファイル配信ファイル管理レイヤは、管理要素テーブル中にファイルバンドルに対応する要素のためのエントリがあるかどうかを判断する。そのようなエントリが存在しない場合（すなわち、判断ステップ５４０４＝「いいえ」）、ステップ５４０６において、ファイル配信ファイル管理レイヤは、ファイルバンドルが受信されるべきであることをファイル配信コアに示す。管理要素テーブル中にエントリが存在する場合（すなわち、判断ステップ５４０４＝「はい」）、判断ステップ５４０８において、ファイル配信ファイル管理レイヤは、ファイル配信コア要求中に、管理要素テーブル中のエントリに関連付けられたどの既存の選択ストリングのプレフィックスでもない、少なくとも１つの選択ストリングがあるかどうかを判断する。上記選択ストリングがある場合（すなわち、判断ステップ５４０８＝「はい」）、ファイル配信ファイル管理レイヤは、ステップ５４０６において、ファイルバンドルが受信されるべきであることをファイル配信コアに示す。他の場合（すなわち、判断ステップ５４０８＝「いいえ」）、ファイル配信ファイル管理レイヤは、ステップ５４１０において、ファイルバンドルが受信されるべきでないことをファイル配信コアに示す。

図５５に、方法５４００において行われ得る、アプリケーションレイヤ（アプリレイヤ）と、ファイル配信コア（ＦＤＣ）レイヤと、ファイル配信ファイル管理（ＦＤＭ）レイヤとの間の例示的なデータフローおよび対話コールフローを示す。動作５５０１において、ストリング「／ｉｔｖ／ｃｎｎ／」を有するファイルバンドルブロードキャストスケジュール記録（ＢＳＲ）が、ファイル配信コアによって受信され、希望ストリング「／ｉｔｖ／ｃｎｎ／ｅ１／」に２ウェイプレフィックスマッチし得る。コールフロー５５０２において、ファイル配信コアは、選択ストリング「／ｉｔｖ／ｃｎｎ／ｅ１／」を生成し、選択ストリングと要素ｉｄと要素タイプとをファイル配信ファイル管理レイヤに渡し得、ファイル配信ファイル管理レイヤは、ファイルがすでに存在するかどうか、およびファイルバンドルがファイル配信ファイル管理レイヤによって受信されるべきかを判断するためにこのストリングを使用し得る。すなわち、コールフロー５５０２において、ファイル配信コアは、ファイルバンドルが受信されるべきかどうかに関する決定についての要求をファイル配信ファイル管理レイヤに送る。動作５５０３において、ファイル配信ファイル管理レイヤは、ファイルを受信すべきかどうかを判断する。ファイル配信ファイル管理レイヤは、管理要素テーブル（ＭＥＴ）中にファイルバンドルに対応する要素のためのエントリがない場合、ファイルを受信するためのこの決定を行い得る。

ファイル配信ファイル管理レイヤが、管理要素テーブル中にファイルバンドルのためのエントリが存在すると判断した場合、ファイル配信ファイル管理レイヤは、選択ストリングのうちの少なくとも１つがエントリ中のどの既存の選択ストリングのプレフィックスでもない場合、そのファイルを受信することを依然として選択し得る。これは、図５５に示されており、デバイスのファイル配信ファイル管理レイヤが、／ｉｔｖ／ｃｎｎ／ｅ１下のファイルをすでに有する。これは、管理要素テーブルの第２の行（ＥＩＤ＝１９８８）の選択ストリング列において選択ストリング値「／ｉｔｖ／ｃｎｎ／ｅ１／」によって示されている。アプリケーションが、／ｉｔｖ／ｃｎｎ／下のすべてのファイルを受信したいという新しい要求を発行しており、ストリング「／ｉｔｖ／ｃｎｎ」がストリング「／ｉｔｖ／ｃｎｎ／ｅ１」よりも広いので、デバイスはファイルバンドル全体を再びダウンロードする必要がある。したがって、コールフロー５５０４において、ファイル配信ファイル管理レイヤは、デバイスがファイルバンドルを再びダウンロードし得るように、ファイル配信コアがファイルバンドルを受信することを要求し得る。したがって、一実施形態では、デバイス上のファイル配信フレームワークは、ブロードキャストスケジュール記録が、希望ストリングに２ウェイトークンプレフィックスマッチする少なくとも１つの属性ストリングを有し、ファイルバンドルがデバイス上に存在し、および（ブロードキャストスケジュール記録から判断されるように）選択ストリングのうちの１つがブロードキャストされることになり、ならびに、希望ストリングが、既存のファイルバンドルに関連付けられたどの既存の選択ストリングのトークンプレフィックスでもない場合、ブロードキャストスケジュール記録によって記述されたファイルバンドル要素を受信することをスケジュールし得る。

図５６に、ファイルバンドル中のファイルがファイル名プレフィックスに基づいてどのように選択され、保存され得るかを示す。上記で説明したように、ファイル配信ファイル管理レイヤは、アプリケーションによって要求されたファイル／ディレクトリ名のうちの１つが、ファイルの名前のプレフィックスである場合、ファイルバンドル中のそのファイルを保存し得る。これは図５６に示されており、ファイル名プレフィックス「／ｉｔｖ／ａｔｔ」を有するファイルのみが保存され、それにより、バンドル中の４つのファイルのうちの２つが保存されたことが示されている。アプリケーションが「／ｉｔｖ／ｖｚｗ／ｓ１／ｆ３」を受信するとすれば、ファイル配信フレームワークはファイルバンドルを再び受信しなければならないことがある。

図５７は、管理要素テーブル（ＭＥＴ）中の例示的なファイルバンドルエントリを示すデータ構造図である。図５７に示すように、一実施形態では、管理要素テーブル中のファイルバンドルに対応する要素のためのエントリは、ファイルバンドルに対応する要素のＩＤ（ＥＩＤ）、要素がファイルバンドルであることを示すフラグ（ＦＢ）、ファイルバンドル中のどのファイルが保存されたかを指定する選択ストリング（選択ストリング）、およびファイルバンドル中の各要素についての（１つまたは複数の）ファイル名と、要素ＩＤと、ストレージ名とを有するサブエントリ、という情報を有し得る。

図５８に、ファイルバンドルを受信し、アプリケーションストレージスペースに保存するための例示的な方法５８００を示す。上記で説明したように、ファイルバンドルに対応する要素を正常に受信した後に、ファイル配信フレームワークは、バンドル中のファイルをアプリケーションストレージスペースに保存し得る。ステップ５８０２において、ファイル配信コアは、ファイルバンドルに対応するファイル配信コアペイロードを正常に受信する。ステップ５８０４において、ファイル配信コアは、ファイル配信コアペイロードが受信されたことをファイル配信ファイル管理レイヤに通知し、スクラッチスペースにおけるファイル配信コアペイロードのロケーションをファイル配信ファイル管理レイヤに渡す。ステップ５８０６において、ファイル配信ファイル管理レイヤは、ファイル配信コアペイロードのための十分なスペースがあると判断し、そのペイロードをスクラッチスペースからアプリケーションのストレージスペースに移動させる。ステップ５８０８において、ファイル配信ファイル管理レイヤは、ファイル配信コアペイロードがスクラッチスペースから除去されたことをファイル配信コアに通知する。ステップ５８１０において、ファイル配信ファイル管理レイヤは、メモリ（たとえば、Ｐ１）に記憶されたファイル配信コアペイロードからトレーラを取り去る。ステップ５８１２において、ファイル配信ファイル管理レイヤは、アプリケーションのメモリ管理ポリシーに従ってファイルバンドル中のファイルを適切なロケーションに保存する。ステップ５８１４において、ファイル配信ファイル管理レイヤは、ファイルバンドルのためのエントリを管理要素テーブルに追加する。ステップ５８１６において、ファイル配信ファイル管理レイヤは、ファイルがキャプチャされたことをアプリケーションに通知する。

図５９は、方法５８００における、アプリケーションレイヤ（アプリレイヤ）と、ファイル配信コア（ＦＤＣ）レイヤと、ファイル配信ファイル管理（ＦＤＭ）レイヤとの間のデータフローおよび対話コールフローの一例である。動作５９０１において、ファイル配信コアは、ファイルバンドルに対応するファイル配信コアペイロードを正常に受信する。コールフロー５９０２において、ファイル配信コアは、ファイル配信コアペイロードが受信されたことをファイル配信ファイル管理レイヤに通知する。次いで、ファイル配信コアは、スクラッチスペースにおけるファイル配信ペイロードのロケーションをファイル配信ファイル管理レイヤに渡す。動作５９０３において、ファイル配信ファイル管理レイヤは、ファイル配信コアペイロードのための十分なスペースがあるかどうかを判断し、そのファイルをスクラッチスペースからアプリケーションのストレージスペースに移動させる。コールフロー５９０４において、ファイル配信ファイル管理レイヤは、ファイル配信コアペイロードがスクラッチスペースから除去されたことをファイル配信コアに通知する。動作５９０５において、ファイル配信ファイル管理レイヤは、メモリ（たとえば、Ｐ１）に記憶されたファイル配信コアペイロードからトレーラを取り去り、ファイルバンドル中のファイルを保存し、ファイルバンドルのためのエントリを管理要素テーブルに追加する。コールフロー５９０６において、ファイル配信ファイル管理レイヤは、ファイルがキャプチャされたことをアプリケーションに通知する。一実施形態では、デバイス上のファイル配信フレームワークは、ファイルバンドル内に含まれているファイルを正常に保存した後に、受信したファイルバンドルを削除し得る。

図６０に、ファイルバンドルから受信したファイルを削除するための例示的な方法６０００を示す。ステップ６００２において、アプリケーションが、ファイルバンドルにおいて受信されたファイルを削除したいという要求をファイル配信フレームワークに発行する。ステップ６００４において、ファイル配信ファイル管理レイヤは、そのファイルのためのサブエントリを有する、管理要素テーブル中のファイルバンドルエントリを見つける。判断ステップ６００６において、ファイル配信ファイル管理レイヤは、サブエントリが、それに関連付けられた２つ以上のファイル名を有するかどうかを判断し得る。ファイル配信ファイル管理レイヤは、サブエントリが２つ以上のファイル名を有すると判断した場合（すなわち、判断ステップ６００６＝「はい」）、ステップ６００８において、サブエントリからファイル名を除去する。サブエントリが２つ以上のファイル名を有しない場合（すなわち、判断ステップ６００６＝「いいえ」）、ステップ６０１０において、ファイル配信ファイル管理レイヤは、記憶ロケーション中のそのファイルを削除し、管理要素テーブルからサブエントリを除去する。ファイルバンドルエントリ中にファイルサブエントリがない（すなわち、ファイルバンドルにおいて受信されたすべてのファイルが削除された）場合、ステップ６０１２において、ファイル配信ファイル管理レイヤは、メモリからファイルバンドルエントリを削除する。一実施形態では、ファイルバンドル要素のファイルのサブセットが削除された場合、ファイルバンドル要素は存在すると見なされ得る。一実施形態では、ファイル配信フレームワークは、削除されたファイルが再びダウンロードされないように、ファイル削除プロセスがアプリケーションによって開始されるときはいつでも通知され得る。一実施形態では、デバイス上のファイル配信フレームワークは、ファイルバンドル中の少なくとも１つのファイルがデバイス上に存在するとき、ファイルバンドル要素を存在するものとして見なし得る。

図６１は、ファイルバンドルから受信したファイルを削除することに関与する論理および例示的なデータフローを示すデータ構造図である。図６１は、サブエントリが、それに関連付けられたただ１つのファイル名を有するとき（たとえば、ＥＩＤ ２００９）、ファイル配信ファイル管理レイヤが、どのように記憶ロケーション中のファイルを削除し、サブエントリ全体を除去し得るかを示している（ＥＩＤ ２００９を通る線によって示されている）。図６１は、サブエントリが、それに関連付けられた２つ以上のファイル名を有する場合（たとえば、ＥＩＤ １９８８）、ファイル配信ファイル管理レイヤがどのようにサブエントリからファイル名のみを除去し得るかをも示している（ファイル名／ｉｔｖ／ａｔｔ／ｓ１／ｆ１ ２００１とストレージパスＤ：／ｆｄｒｏｏｔ／ａｔｔ／ｓ１／ｆ１とを通る線によって示されている）。

図６２に、前に受信したファイルバンドルを受信する際の、アプリケーションレイヤ（アプリレイヤ）と、ファイル配信コア（ＦＤＣ）レイヤと、ファイル配信ファイル管理（ＦＤＭ）レイヤとの間の例示的なデータフローおよび対話コールフローを示す。動作６２０１において、ファイルバンドルブロードキャストスケジュール記録（ＢＳＲ）が、ファイル配信コアによって受信され、２ウェイプレフィックスマッチする。コールフロー６２０２において、ファイル配信コアは、選択ストリングと要素ｉｄと要素タイプとをファイル配信ファイル管理レイヤに渡し、その結果、ファイル配信ファイル管理レイヤは、ファイルがすでに存在するかどうかを判断し、ファイルバンドルが受信されるべきかどうかを判断し得る。動作６２０３において、ファイル配信ファイル管理レイヤは、ファイルバンドルに対応する要素のための選択ストリング（「／ｉｔｖ／ｖｗｚ／ｓ１／ｆ３」および「／ｉｔｖ／ｖｗｚ／ｓ１／ｆ４」）を維持する。コールフロー６２０４において、ファイルバンドルに対応する要素、またはファイル配信コアペイロードが、ファイル配信コアによって受信され、ファイル配信ファイル管理レイヤに渡される。図６２に示すように、ファイルバンドルは、４つのファイル、すなわち、／ｉｔｖ／ｖｚｗ／ｓ１／ｆ３と、／ｉｔｖ／ｖｚｗ／ｓ２／ｆ４と、／ｉｔｖ／ａｔｔ／ｓ１／ｆ１と、／ｉｔｖ／ａｔｔ／ｓ２／ｆ２とを有し得る。図示の例では、ファイル配信ファイル管理レイヤは、ファイル配信フレームワークが、ファイルバンドルを以前受信したが、上記ファイルのうちの２つ、すなわち、／ｉｔｖ／ｖｚｗ／ｓ１／ｆ３と、／ｉｔｖ／ｖｚｗ／ｓ２／ｆ４とのみを保存したと判断する。これは、たとえば、アプリケーションレイヤ上で実行しているアプリケーションが、ファイルバンドル中の上記ファイルのうちの２つ（たとえば、／ｉｔｖ／ａｔｔ／ｓ１／ｆ１、および／ｉｔｖ／ａｔｔ／ｓ２／ｆ２）を前に要求しており、次いで、偶然最初の２つのファイルと同じファイルバンドル中にある２つの新しいファイル（たとえば、／ｉｔｖ／ａｔｔ／ｓ１／ｆ３および／ｉｔｖ／ａｔｔ／ｓ２／ｆ４）についての別の要求を発行した場合であり得る。コールフロー６２０３において、ファイル配信ファイル管理レイヤは、ファイル配信コアからファイルバンドルを再び受信し、ファイルバンドル中の２つの新たに要求されたファイル（たとえば、／ｉｔｖ／ｖｚｗ／ｓ１／ｆ３および／ｉｔｖ／ｖｚｗ／ｓ２／ｆ４）のみをメモリに保存する。

図６３に、ファイル配信コアとファイル配信ファイル管理レイヤとの間でデータを交換するために使用され得る例示的なファイル配信コアペイロードフォーマットを示す。一実施形態では、ファイル配信コアとファイル配信ファイル管理レイヤは、複数のファイル配信コアペイロードフォーマットを同時にサポートするように構成され得る。一実施形態では、ファイル配信コアペイロードフォーマットは、ブロードキャストスケジュール記録中のパラメータ、フラグ、またはビット（たとえば、ＦＤ＿ＭＯＤＥ）によって指定され得る。一実施形態では、ＦＤ＿ＭＯＤＥビットを０に設定することにより、第１のフォーマットが選択され、ＦＤ＿ＭＯＤＥビットを１に設定することにより、第２のフォーマットが選択される。

図６４に、図６３に示す後方互換フォーマット（ＢＣＦ：backward compatible format）に対応する例示的なファイル配信コアペイロードフォーマットを示す。図６４に示すファイル配信コアペイロードフォーマットは、単一のファイルか、または複数のファイルを含むファイルバンドルのいずれかを含んでいることがある。ＢＣＦファイル配信コアペイロードフォーマットは、最後にクリップメタデータを含み得る。ファイル配信コアペイロードフォーマットは、クリップメタデータ中のｃｌｉｐ＿ｄｅｆ＿ｒｅｃ ＸＭＬ要素におけるファイルバンドル中の１つまたは複数のファイルについてｎｏｎ＿ｒｅａｌｔｉｍｅ＿ｐｒｅｓｅｎｔａｔｉｏｎ ＸＭＬ要素に追加された随意の要素ＩＤと（１つまたは複数の）ファイル名とを含み得る。様々な実施形態では、受信機デバイスは、要素ＩＤとファイル名とを受信し、それらへのアクセスを有し得る。一実施形態では、受信機デバイスは、受信機デバイスが認識しない新しいフィールドを無視し得る。

図６５および図６６に、図６３に示すフォーマットに対応する例示的なファイル配信コアペイロードフォーマットを示す。詳細には、図６５は、２つの名前を有する単一のファイルである要素のための例示的なファイル配信コアペイロードフォーマットを示している。図６６は、２つの名前を有するファイル（たとえば、ファイル１）を含むファイルバンドルである要素のための例示的なファイル配信コアペイロードフォーマットを示している。図６５および図６６に示すファイル配信コアペイロードフォーマットは、単一のファイルか、または複数のファイルの連結を備えるファイルバンドルのいずれかである、要素部分を含んでいることがある。図示のファイル配信コアペイロードフォーマットは、Ｔｒａｉｌｅｒ Ｄａｔａ Ｌｅｎｇｔｈ、Ｔｒａｉｌｅｒ Ｄａｔａ、および要素ＩＤという情報フィールドを含んでいる、トレーラセクションを有する。Ｔｒａｉｌｅｒ Ｄａｔａフィールドは、ファイル配信コアペイロードの要素部分上でどの圧縮方式が適用されるべきかを指定するＣｏｍｐｒｅｓｓｉｏｎ Ｔｙｐｅフィールドをさらに含み得る。一実施形態では、Ｅｌｅｍｅｎｔ Ｔｙｐｅフィールドは、要素がファイルなのかファイルバンドルなのかを示し得る。要素がファイルである場合、図６５に示すように、トレーラは、要素タイプとファイル名とのための追加の情報フィールドをも含み得る。要素がファイルバンドルである場合、図６６に示すように、トレーラは、バンドル中の各ファイルのための要素ＩＤと、オフセットと、ファイル名とのための情報フィールドを含み得る。

図４を参照しながら上記で説明したように、アプリケーション（たとえば、ヘッドエンドアプリ４２、４３）は、送信のためのファイルをファイル取込みサーバ３１に与える。ファイル取込みサーバ３１は、ブロードキャストスケジュールメッセージとともに、それらのファイルをファイルトランスポートネットワーク４１を介して受信機デバイスに配信する。図６７に、ファイルを取り込み、送信のためにそれらのファイルをスケジュールし、ブロードキャストスケジュールメッセージを生成し、生成されたブロードキャストスケジュールメッセージをブロードキャストするための例示的な方法６７００を示す。方法６７００では、ステップ６７０２において、ファイル取込みサーバ３１など、ヘッドエンドシステムにおけるサーバが、１つまたは複数のヘッドエンドアプリケーション４２、４３から送信のためのファイルを受信する。ステップ６７０４において、サーバは、取込みプロセスの一部として、ファイルおよび／または要素を生成し、ブロードキャストされるべきファイルについてのファイルまたは要素識別子を取得／生成する。ステップ６７０６において、取込みプロセスの一部として、サーバは、上記で説明したように、ファイルサイズ、ならびに、ファイル属性ストリング、またはアプリケーション／サービス識別子など、ファイルに関する他の情報を取得する。ステップ６７０８において、取込みプロセスの一部として、サーバは、データファイルを搬送することになるコンテンツフローのデータレートを判断する。データレートは、ブロードキャストリソース利用可能性に応じて変動し得る。データレートはまた、特定のファイル配信タイプのために指定されている場合など、固定のままであり得る。

取込みプロセスの一部として、ステップ６７１０において、サーバは、ファイルサイズをファイル配信データレートで除算することなどによって、各ファイルのブロードキャスト持続時間を判断する。ステップ６７１１において、サーバは、送信持続時間に基づいて、どのファイルが次のブロードキャストスケジュール期間（ＢＳＰ）内にブロードキャストされるべきであるかを判断する。スケジューリングプロセスとＢＳＭ生成プロセスは独立プロセスであり、ここでは簡潔のためにそれらのプロセスについて一緒に説明することに留意されたい。たとえば、ファイルスケジューリングプロセスは次の１５分の期間に制限されないことがあり（たとえば、ファイルは、取込みから３時間後の送信のためにスケジュールされ得る）、ＢＳＭ生成プロセスは、次の期間（たとえば、１５分）に対して定義された現在の送信スケジュールとしてＢＳＭのコンテンツを周期的に（たとえば、１５分ごとに）判断し得る。取込み時のファイルスケジューリングとＢＳＭ生成とのプロセスについては、以下でさらにより詳細に説明する。

ステップ６７１２において、サーバは、ブロードキャストスケジュール期間内の送信のためにファイルをスケジュールする。ブロードキャストスケジュール期間内の送信のためにファイルをスケジュールすることの一部として、ステップ６７１４において、サーバは、ブロードキャストスケジュール期間内の各ファイルについてのブロードキャストウィンドウ開始時間を識別する。ステップ６７１６において、サーバは、ブロードキャストスケジュールメッセージと、記録タイプ、記録データリンク、およびブロードキャストスケジュールメッセージの次の更新の時間（たとえば、次の監視時間）を指定するブロードキャストスケジュール監視記録（ＢＳＭＲ）とを生成する。

ブロードキャストスケジュールメッセージを生成することの一部として、サーバは、ステップ６７１８において、１つまたは複数のフローブロードキャストスケジュール記録（ＦＢＳＲ）を生成する。ブロードキャストスケジュールメッセージを生成することの一部として、サーバは、次いで、ステップ６７２０において、受信し生成された情報からブロードキャストスケジュールメッセージをアセンブルし、これは、ＢＳＰ内にブロードキャストされることになるファイルの各々についてのブロードキャストウィンドウを識別することを含む。ステップ６７２２において、サーバは、アセンブルされたブロードキャストスケジュールメッセージをブロードキャストネットワークにサブミットして、ブロードキャストスケジュールフロー上で繰り返し送信を開始し、ステップ６７２４において、サーバは、ブロードキャストスケジュールメッセージにおいて指定されたブロードキャストスケジュールに従ってブロードキャストのためのファイルがファイル配信データフロー上で送信され得るように、それらのファイルをブロードキャストネットワークにサブミットし得る。このプロセスは、サーバが、次のＢＳＰの間にブロードキャストスケジュールメッセージを展開することを開始するためにステップ６７０２に戻ることによって、繰り返し得る。

上記で説明したように、ファイルコンテンツプロバイダ９内のファイル配信アプリケーションがブロードキャストネットワーク１上でのトランスポートのためのファイルをサブミットすると、ファイル取込みシステム３１は、ファイルトランスポートに専用のブロードキャストリソースを使用してブロードキャストのためにそれらのファイルをスケジュールし得る。これらの専用ブロードキャストリソースは、概念的にファイル配信パイプと見なされ得る。上記で説明したように、様々な実施形態では、ブロードキャストネットワーク上でファイルをブロードキャストするために２つ以上のファイル配信パイプが使用され得る。１つまたは複数のファイル配信パイプにおける取り込まれたファイルのスケジューリング、およびファイルの時分割多重化が、図７に示されている。

上記で説明したように、ファイル取込みシステム３１は、多種多様なフォーマットで多種多様なソース（すなわち、ヘッドエンドアプリケーション）からファイルを受信し得る。ファイル取込みシステム３１は、様々な受信したファイルが、ブロードキャストスケジュールメッセージ内で広告されたブロードキャストウィンドウ内にブロードキャストされることを保証するために、ブロードキャストスケジュールメッセージを生成し、ファイルトランスポートネットワーク４１と協調して、それらのファイルをスケジュールする。

図６８に、２つのヘッドエンドアプリケーションがファイルトランスポートネットワーク４１上でのトランスポートのためにファイルをファイル取込みシステム３１にサブミットする、例示的な実施形態を示す。この図示の例では、２つのヘッドエンドアプリケーションは、天気アプリケーション４３および双方向性アプリケーション４９である。この例では、天気アプリケーション４３は、ファイルトランスポートネットワーク４１を使用して、受信機デバイス上で動作している天気アプリケーション４６にアプリケーションファイルを配信することになる。同様に、双方向性アプリケーション４９は、ファイルトランスポートネットワーク４１を使用して、受信機デバイス上の双方向性アプリケーション４７に双方向性リソースおよびファイルを配信することになる。様々な実施形態では、ヘッドエンドアプリケーション４３、４９は、単に、ｓｅｎｄＦｉｌｅ（／ｗｅａＡｐｐ／ＬＡ／ｆ１．ｊｐｇ）などの適切なファイルコマンド、および図６８に示すデータスキーマにおける他のパラメータとともに、ファイルを与えることによって、ファイル取込みシステム３１と対話することができる。一連のファイルを送るために、ヘッドエンドアプリケーション４３、４９は、ｓｅｎｄＦｉｌｅ（／ｉｔｖ／ｓｉｇ／ｃａｔ．ｘｍｌ、ｉｔｖ／ｒｅｓ／ｓｖｃ＿５／ｆ１．ｊｐｇ、／ｉｔｖ／ｒｅｓ／ｓｖｃ＿５／ｆ２．ｊｐｇ、／ｉｔｖ／ｒｅｓ／ｓｖｃ＿５／ｆ３．ｊｐｇ）などの単一のコマンドでファイルを指定し得る。

図６８に示すように、一部のアプリケーションは、コンテンツファイルのみをサブミットし得（たとえば、天気アプリはｊｐｅｇ画像をサブミットし得）、他のアプリケーションは、コンテンツファイルとオーバーヘッドファイルとをサブミットし得る（たとえば、双方向性アプリはｊｐｅｇ画像とｃａｔ．ｘｍｌオーバーヘッドファイルとをサブミットし得る）。さらに他のアプリケーションは、追加の属性情報とともにコンテンツファイルをサブミットし得る（たとえば、双方向性アプリは、代替的に、ｊｐｅｇ画像と、ファイルについての特性を記述する関連する属性とをサブミットし得る）。

オーバーヘッドファイルをファイル取込みシステムにサブミットするアプリケーションは、そのようなオーバーヘッドファイルについて異なる目的を有し得る。そのようなオーバーヘッドファイルは、デバイスアプリケーションのために利用可能なファイルに関する情報を受信機デバイスに与えるために使用され得る。一実施形態では、そのようなオーバーヘッドファイルは、カタログファイルまたはｃａｔ．ｘｍｌファイルの形態のものであり得る。ｃａｔ．ｘｍｌファイルは、受信機デバイスが受信のためのファイルを選択することを可能にし得る属性のリストを与えるために使用され得る。また、同じ属性リスト情報は、図６９に示すデータスキーマを与えることなどによって、取込みインターフェースを介して利用可能になり得る。追加または代替として、属性リストはブロードキャストスケジュールメッセージにおいて搬送され得る。

ファイルをファイル取込みシステム３１にサブミットするために使用され得る例示的なデータスキーマを図６９および図７０に示す。また、ファイル取込みシステムは、配信基準など、送信されるべきファイルに関する情報を受信するためのインターフェースを与え得る。たとえば、図７０に示すデータスキーマに示すように、ファイル取込みインターフェースファイル配信要求は、送信されるべきファイルについての所望の開始時間、および満了時間、またはブロードキャストスケジュールを指定し得る。ブロードキャストスケジュールが指定される場合、ファイル配信要求は、ファイルが送信されるべきである期間と、ファイル送信が試みられるべきである回数とを識別し得る。また、ブロードキャストスケジュールは、それの後にファイルが送信されるべきでない終了時間を含み得る。

ファイル配信要求動作は、送信のためにサブミットされるファイルを識別するための機構、複数のファイルを同時にサブミットするための機構、アプリケーションレベルで互いに関係し得るファイルをグループ化するための機構、関係するファイルの各グループについての異なる配信基準要求の定義、および、前にサブミットされたアイテムの配信基準が更新され得るように、２回目にサブミットされたファイルを再サブミッションとして認識することを可能にする機構、という特徴をファイル配信アプリケーションに与え得る。

送信のためにサブミットされるファイルを識別するための機構は、ファイル取込み動作を介してサブミットされ得る。この動作において、ファイル取込みサービスによってファイルがブロードキャストのためにそこから取り出され得るロケーションを与える、コンテンツユニフォームリソースロケータ（ＵＲＬ）が識別され得る。上記機構は、ブロードキャストのために取り込まれているファイルのコンテンツおよびコンテキストにさらに関連付けられた追加のパラメータをも識別し得る。たとえば、追加のパラメータは、アプリケーションディレクトリ構造においてファイルのためのディレクトリを示すために使用され得るファイル名を含み得る。追加のパラメータは、受信機デバイスが受信のための特定のファイルをフィルタ処理および選択することを可能にするために、ファイルを特徴づけるパラメータを与える、属性リストを含み得る。

複数のファイルのサブミッションを同時に可能にする機構は、アプリケーションが、関係するファイルを識別することを可能にし得る。たとえば、ファイル配信要求中の単一のファイル情報ユニット上の特定のディレクトリ下のすべての双方向性ファイルが、関係すると見なされ得る。ヘッドエンドアプリケーションは、相互依存性をもつファイルが、ブロードキャストのために場合によっては互いにバンドルされ、スケジュールされることを保証することができ得る。たとえば、図６８に記載されている双方向性ファイルは、新しいファイルが受信機デバイスにとって利用可能になったとき、双方向性カタログファイルを更新し得る。このインターフェースを用いると、ディレクトリ／ｉｔｖ／ｒｅｓ／ｓｖｃ＿５／下の新しいファイルが場合によってはバンドルとして送信される前に、／ｉｔｖ／ｓｉｇ／ｃａｔ．ｘｍｌファイルは、送信されることと、受信機デバイス上で利用可能になることとを要求され得る。

関係するファイルをアプリケーションレイヤで互いにグループ化することを可能にするための機構は、関係するファイルが、同じ配信基準にかけられ、受信機デバイスによって等しく必要とされることを保証し得る。ファイル取込みシステムは、オーバージエアでファイルを送信するとき、前方誤り訂正コーディングのより効率的な使用のために、同様であるファイルをバンドルし得る。ファイルインジェクションサービスは、関係するファイルを互いにバンドルするために、この関係性情報を使用し得る。また、ファイルのバンドリングを決定するための他の基準が考慮され得る。たとえば、ファイル取込みシステムは、サービスに関連付けられサブスクライブされた、異なるファイルを互いにグループ化し得る。したがって、１つのサービスのための１つのファイルを受信する権利がある受信機デバイスは、互いにサブスクライブされた、他のサービスのためのファイルを受信する権利もあり得る。

関係するファイルの各グループについての送信要求のための異なる配信基準をヘッドエンドアプリケーションが定義することを可能にする機構は、アプリケーションが、取り込まれたファイルのブロードキャストについてのサービス品質（ＱｏＳ）レベルまたは送信要求を要求することを可能にし得る。サービス品質は、適時性（たとえば、フレッシュネス）および配信の成功（たとえば、配信障害が克服されることを保証するための冗長送信）に関して、対象とするユーザ集団に対するトランスポートサービスの品質を表し得る。ファイル取込みシステム３１は、関係するファイルの要求された配信基準が満たされるように、関係するファイルの各グループをスケジュールし得る。新しいファイルをスケジュールする場合、ファイル取込みシステムは、優先度スケジューリングが考慮されるとき、前に取り込まれたファイルの配信基準が損なわれないことを保証し得る。前にスケジュールされたファイルは、優先度ベースのスケジューリングにおいて新しいファイルのための場所をあけるために廃棄され得る。ファイル取込みシステムは、同じファイルが２回目または３回目にサブミットされるとき、そのファイルが、前に送信されたファイルの再サブミッションまたは更新として認識され、その結果、前にサブミットされたファイルのための配信基準が再利用され得るように、構成され得る。

図７１に示すように、ファイル取込みシステム３１が、第１のブロードキャストスケジュール期間中などに、取込みのためのファイルを受信したとき、新しいファイルが送信のために最も早くスケジュールされ得るのは、次のブロードキャストスケジュール期間においてである。たとえば、ファイルｆ₈、ｆ₉およびｆ₁₀が第１のブロードキャストスケジュール期間（ＢＳＰ₁）中にファイルコンテンツプロバイダ９から受信されたとき、ファイル取込みシステム３１は、次のまたは後のブロードキャストスケジュール期間（ＢＳＰ₂）の間のファイル送信をスケジュールする。ファイルが送信のためにスケジュールされたとき、それらのファイルはデータストア３２に記憶され得る。また、得られた更新されたブロードキャストスケジュールが、データベースなどのメモリに記憶され得る。

図７１に示すように、現在のブロードキャストスケジュール期間中に受信されたファイルは、次のまたは後続のブロードキャストスケジュール期間における送信のためにスケジュールされることのみを許される。これは、現在のブロードキャストスケジュール期間におけるスケジュール情報が、現在のブロードキャストスケジュールメッセージを介して受信機デバイスにすでに広告されているからである。ブロードキャストスケジュールメッセージがブロードキャストされた後、受信機デバイスは、関係があるファイルが、ブロードキャストスケジュール中の送信のためにブロードキャストスケジュールメッセージに記載されていない場合、電力を温存するために受信機回路を非アクティブにしていることがあるので、受信機デバイスは、ブロードキャストスケジュールメッセージによってカバーされるブロードキャストスケジュール期間において後続のスケジュール変更を検出することが可能でないことがある。したがって、ブロードキャストスケジュール期間持続時間の選択は、コンテンツの可能なフレッシュネスと、デバイスが、更新されたブロードキャストスケジュールメッセージをどのくらい頻繁に受信する必要があることになるかとの間の折衷であり得る。ブロードキャストスケジュール期間が小さくなると、新たに受信したファイルをより早く送信することが可能になるが、受信機デバイスが、更新されたブロードキャストスケジュールメッセージを頻繁に受信する必要は、受信機デバイスのバッテリー寿命に影響を及ぼし得る。

したがって、ファイル取込みシステム３１内のスケジューラは、現在のブロードキャストスケジュール期間を、新たに受信したファイルを搬送するために利用不可能であると見なす。しかしながら、現在のブロードキャストスケジュール期間を超えるいかなる時間期間も、そのスケジュールが受信機デバイスにまだ広告されていないので、修正され得る。図７２Ａ〜図７２Ｄに、ファイルがいつ受信されたかと、ファイルの緊急度とに応じて、ブロードキャストスケジュールがどのように修正され得るかを示す。

たとえば、図７２Ａは、新しいファイルｆ₈〜ｆ₁₀がトランスポートのためにファイル取込みサービス３１にサブミットされる前のスケジューリング状態を示している。図７２Ｂは、ファイルｆ₈が緊急配信要求を指定する状況のためのスケジューリング状態を示している。この状況では、ファイル取込みシステム３１により、下位優先度またはあまり制限的でない時間配信要求をもつ他のファイル（たとえば、ｆ₅₁）は遅延され得る（すなわち、それらのファイルのスケジュールされたブロードキャストウィンドウは延期される）。さらなる遅延を許容することができない他のファイル（たとえば、ｆ₅）は再スケジュールされず、それらのファイルは、元のブロードキャストウィンドウにおけるブロードキャストのためにスケジュールされ続ける。図７２Ｃは、次のブロードキャストスケジュール期間におけるファイルが、ファイルｆ₉が取り込まれる時間までのさらなる遅延を許容することができず、したがってファイルｆ₉が後続のブロードキャストスケジュール期間における送信のためにスケジュールされる、状況を示している。図７２Ｄは、次のブロードキャストスケジュール期間におけるファイルがさらなる遅延を許容することができない時間にｆ₁₀が取り込まれ、ファイルｆ₁₀がファイルｆ₉よりも高い緊急度を有し、その結果、ファイルｆ₉が後のブロードキャストスケジュール期間に押し込まれた、状況を示している。

また、ファイル取込みシステムは、ブロードキャストネットワークへのファイルの配信またはブロードキャスト送信を協調させることを担当し得る。図７３に示すように、このプロセスは、ブロードキャストスケジュールメッセージ（ＢＳＭ）情報のブロードキャストに関与し得る。図７４に示すように、このプロセスは、ブロードキャストネットワークへのファイルのディスパッチングに関与し得る。

オーバージエアで送信されているブロードキャストスケジュールメッセージを更新することに関与するプロセスは、図７３に示されており、図７５に示す例示的な方法７５００のプロセスフロー図において終了する。現在のブロードキャストスケジュール期間の終了の前のある時間に、ファイル取込みシステム３１は、ステップ７５０２において、それのストレージ３２から現在のスケジュール情報をフェッチし、ステップ７５０３において、次のブロードキャストスケジュール期間を記述するために新しいブロードキャストスケジュールメッセージを作成する（動作Ａ）。ステップ７５０４において、ファイル取込みシステムは、ＯＳＳとともにブロードキャストスケジュールメッセージバージョンを更新し、ＯＳＳは、オーバーヘッドバージョン変更を管理および広告する補足物である。ステップ７５０６において、ファイル取込みシステムは、更新されたブロードキャストスケジュールメッセージを配信サーバ（ＤＩＳＴ）に送り、ＤＩＳＴは、ブロードキャストのための構成されたレートでファイルおよびオーバーヘッドメッセージを送信する構成要素である。ステップ７５０８において、ＯＳＳは、更新されたブロードキャストスケジュールメッセージバージョンを、初期収集フロー（ＩＡＦ）において搬送されるメッセージに追加し、ステップ７５１０において、更新されたＩＡＦメッセージを配信サーバに送る（通信Ｂ）。配信サーバは、構成されたブロードキャストスケジュールフローデータレートでブロードキャストスケジュールフロー上で、更新されたブロードキャストスケジュールメッセージをフローサービスノード（ＦＳＮ）に送り、ＦＳＮは、送信を介した現実に関与するブロードキャストネットワーク内の構成要素である。

送信されたブロードキャストスケジュールメッセージを更新することに関与するプロセスは、図７４および図７５に示されている。また、ファイル取込みシステム３１は、上記で説明したように、それのバージョンがＯＳＳを介して広告され、それのコンテンツが配信サーバを介して送られる、現在のブロードキャストスケジュールメッセージに関するスケジュール情報を利用する。ステップ７５１６において、ファイル取込みシステムは、受信機デバイスに広告されたブロードキャストスケジュールメッセージに従ってファイルがオーバージエアでブロードキャストされるようにそれらのファイルを送信することを開始するように配信サーバにシグナリングする（動作１）。そうする際に、ファイル取込みサービスは、現在のブロードキャストスケジュールメッセージにおいて記述された情報に一致するファイルを送信するときに使用されるべきフローＩＤおよびデータレートを記述し得る。ステップ７５１８において、配信サーバは、次にブロードキャストされるべきファイルコンテンツをフェッチし（動作２）、次いで、ステップ７５２０において、ファイルの送信のために使用されるフローＩＤのために定義されたデータレートでファイルをＦＳＮに送信する（動作３）。

上記で説明したように、ＭｅｄｉａＦＬＯ技術ブロードキャストネットワークなどのブロードキャストネットワークにおける送信リソースは、ＭｅｄｉａＦＬＯでは１秒持続時間であるスーパーフレーム内のＯＦＤＭシンボルに関して定義され得る。そのようなスーパーフレーム上のシンボルは、ローカルおよびワイドエリアマルチプレックスシンボルにさらに分割され得る。異なるブロードキャストネットワークは、共有ブロードキャストリソース上でのメディアのトランスポートのための他の（すなわち、ＯＦＤＭとは異なる）時間、周波数または符号多重化機構を有し得る。「マルチプレックス」という用語は、本明細書では概して、ブロードキャストネットワークを介した（たとえば、所与の無線周波数帯域幅上での）メディアトランスポートのために利用可能なブロードキャストリソースを指すために使用する。ファイルをトランスポートするために利用可能なブロードキャストリソースの量は、無線周波数帯域幅と、トランスポート符号化機構と、ブロードキャスト信号によっても搬送されるリアルタイムコンテンツおよびオーバーヘッドデータなど、他のメディアまたはデータの量との関数であり得る。

ＭｅｄｉａＦＬＯネットワークなどのマルチメディアブロードキャストネットワークでは、ローカルエリアコンテンツまたはローカルマルチプレックス（ＬＭ）と呼ばれる、ローカルエリア用に指定されたコンテンツ、およびワイドマルチプレックス（ＷＭ）のためのワイドエリアコンテンツと呼ばれる、複数のローカルエリア放送事業者に与えられるコンテンツを含む、様々なコンテンツが同時にブロードキャストされ得る。ローカルマルチプレックスとワイドマルチプレックスは、所与の無線周波数帯域幅を使用するマルチプレックスの（たとえば、ＯＦＤＭフレームの）異なる部分であり得る。ローカルエリアコンテンツは、地域ブロードキャストなど、ローカルオペレーションズインフラストラクチャ（ＬＯＩ：local operations infrastructure）に固有であるコンテンツであり得る。

図７６に、所与のローカルオペレーションズインフラストラクチャ中に複数の無線周波信号が存在し得ることを示す。図示の例では、ローカルオペレーティングインフラストラクチャ１（ＬＯＩ１）は、第１のワイドマルチプレックス（ＷＭ１）と第１のローカルマルチプレックス（ＬＭ１）成分とを含む単一の無線周波信号（ＲＦ１）を含む。ローカルオペレーティングインフラストラクチャ２（ＬＯＩ２）は、各々がワイドマルチプレックス（ＷＭ２、ＷＭ１）とローカルマルチプレックス（ＬＭ２、ＬＭ１）とからなる２つの無線周波信号（ＲＦ２およびＲＦ３）を含む。図示の例では、ローカルオペレーティングインフラストラクチャ３（ＬＯＩ３）は、ワイドマルチプレックス（ＷＭ２）とローカルマルチプレックス（ＬＭ３）とからなる単一の無線周波信号（ＲＦ４）を含む。

図７６に示すように、いずれかの無線周波信号において搬送されるワイドおよびローカルマルチプレックス成分は、他の無線周波信号中のワイドおよびローカルマルチプレックス成分と同じであるか、またはそれらとは異なり得る。さらに、異なる無線周波信号はまた、ＭｅｄｉａＦＬＯ技術、ＩＳＤＢ−Ｔ、ＡＴＳＣ−Ｍ／Ｈなど、異なるトランスポート技術を使用し得る。図７６は、所与のマルチプレックス（たとえば、ＷＭ１またはＬＭ２）が、異なるローカルオペレーティングインフラストラクチャでは異なる無線周波信号において搬送され得ることを示している。また、所与のローカルオペレーティングインフラストラクチャが、利用可能な複数の無線周波信号を有し得る。

図７７に、マルチプレックスごとに複数のファイル配信タイプが定義され得ることを示す。上記で説明したように、様々な実施形態は、マルチプレックスごとに、毎秒のシンボル（たとえば、ＯＦＤＭシンボル）の量など、単一の共通リソースプールを共有するファイル送信を用いて実装され得る。上記で説明したように、そのようなリソースプールは、ファイル配信フレームワーク内の１つまたは複数のファイル配信パイプ（ＦＤＰ）として抽出され、定義され得る。図７７は、これらのファイル配信パイプの多くが単一のマルチプレックスにおいて定義され得ることを示している。詳細には、図７７は、ワイドマルチプレックス（ＷＭ１）が２つのファイル配信パイプ（ＦＤパイプ１、ＦＤパイプ２）を含み得、これにより、マルチプレックス帯域幅の残部が、リアルタイムおよびＩＰデータサービス（ＲＴ＋ＩＰＤＳ）を送信することに専用であることが可能になることを示している。同様に、第２のワイドマルチプレックス（ＷＭ２）が３つのファイル配信パイプ（ＦＤパイプ３〜５）を含み得、マルチプレックス帯域幅の残部が、リアルタイムおよびＩＰデータサービスを送信することに専用である。

様々な実施形態では、ファイル配信パイプは、マルチプレックス（たとえば、ファイル配信パイプの地理的リーチ）と、送信データレートと、パイプフローＩＤのセットとによって定義された論理エンティティとして、ブロードキャストネットワーク内で編成され得る。パイプのために定義される送信データレートは、パイプに割り振られるマルチプレックス帯域幅の部分に依存し得る。様々な実施形態では、ファイル配信パイプに割り振られるリソースの量は、展開された受信機デバイスによってサポートされるデータレートに応じた構成で、構成可能であり得る。

図７７は、様々な実施形態では、ファイル配信パイプがそれらのデータレートによって定義され、編成され得ることをも示している。ファイル配信パイプのデータレートの差異は、各パイプの直径によって示されている（たとえば、ＷＭ１中のファイル配信パイプは、ＷＭ２中のファイル配信パイプよりも、高いデータレートを有し、したがってより太い）。ファイル配信パイプをより高いおよび／またはより低いデータレートのグループに定義し、編成することは、展開された受信機デバイスの多様なセットから生じる制限に対処するのに役立つ。たとえば、初期世代の受信機デバイスは、一般に、制限された最大データレートをサポートし、後の世代の受信機デバイスは、より高いデータレートをサポートすることが可能であり得る。ファイル配信パイプのデータレートによってファイル配信パイプを定義し、編成することにより、ファイル配信サービスは、初期世代の受信機デバイスと後の世代の受信機デバイスの両方をサポートすることが可能になる。

図７８Ａおよび図７８Ｂに、ファイル配信パイプが、時間ダイバーシティ考慮事項にも対処するようにサイズ決定され、編成され得ることを示す。たとえば、マルチプレックス中のファイル配信パイプは、大きいファイルを搬送する場合は高い帯域／高い容量のファイル配信パイプを与え、より小さいファイルを搬送する場合はより低い帯域幅／より低い容量のファイル配信パイプを与えるように編成され得る。そのような編成は、ブロードキャストシステムが小さい緊急ファイルを周期的にトランスポートすることを要求されるときに有用であり得る。様々な実施形態では、ファイル配信パイプは、図７８Ａに示す「太い」ファイル配信パイプ、または図７８Ｂに示す「細い」ファイル配信パイプのいずれかであるものとして定義され得る。マルチプレックス内で「細い」ファイル配信パイプを定義することによって、ブロードキャストネットワークは、そのような緊急ファイルが受信されたとき、遅延なしに、または「太い」ファイル配信パイプ上で搬送されている大きいファイルの送信を中断することなしに、それらの緊急ファイルに適応することができる。

図７９Ａ〜図７９Ｇに示すように、ファイル配信パイプは、あるパイプ上では高レイテンシの大きいファイルを搬送しながら、別個のパイプ上では低レイテンシの小さいファイルをサポートするようになど、異なるタイプのファイルトラフィックを分離するようにも編成され得る。様々な実施形態では、ファイル配信パイプは、情報をトランスポートするための「レイテンシセンシティブ」データキャスティングをサポートするように構成され得る。様々な実施形態では、システムは、すべてのデータキャストトランスポートの一様な処理を可能にするように構成され得る。様々な実施形態では、低レイテンシトラフィックは１つまたは複数の配信パイプ上にアグリゲートされ得る。様々な実施形態では、様々なプリセットおよび動的レイテンシターゲットをサポートするために複数のＢＳＭが使用され得る。様々な実施形態では、アプリケーションは、レイテンシセンシティブデータのトランスポートより前に前方誤り訂正（ＦＥＣ）保護を適用し得る。

図７９Ａは、１５分、１分および３０秒のレイテンシ制限があるファイルのための別個のファイル配信パイプを定義することなど、異なる特定のレイテンシ要求をサポートするようにファイル配信パイプを定義し得ることを示している。また、特定のファイル配信パイプへのファイルのプロビジョニングは優先度に基づき得る。たとえば、図７８Ａ〜図７８Ｂおよび図７９Ａは、一部のファイル配信パイプは低レイテンシ（すなわち、緊急）アプリケーションファイルに専用であり得、他のファイル配信パイプは中〜高レイテンシ（すなわち、非緊急）アプリケーションファイルを搬送することに専用であり得ることを示している。

図７９Ｂは、リアルタイム（ＲＴ）コンテンツが、ストリームごとに、または全体で、マルチプレックスから帯域幅を割り振られ得ることを示している。レイテンシトレラントコンテンツは、異なるレイテンシトレラントデータキャスティングストリームにわたって共有されるＦＤパイプのセット（ＦＤパイプ１〜２）上でアグリゲート帯域幅を割り振られ得る。レイテンシセンシティブコンテンツは、個々のレイテンシセンシティブデータキャスティングストリームに専用のＩＰＤＳフロー（ＩＰＤＳフロー１〜４）上で送信され得る。パイプ帯域幅がデバイス制限によって制約され得るので、レイテンシセンシティブコンテンツは、ピークおよび平均データレートと、バーストサイズ要求とに基づいて帯域幅を割り振られ得る。これは図７９Ｃに示されており、アグリゲート帯域幅がピーク（Ｂｗ_Peak）および平均（Ｂｗ_Avg）データレートと、バーストサイズ要求とに基づき得ることが示されている。しかしながら、いくつかの状況では、ピーク（Ｂｗ_Peak）および平均（Ｂｗ_Avg）データレートに基づいて最適アグリゲート帯域幅を推定することが困難であり得る。たとえば、推定値があまりに控えめである場合、失われた過剰帯域幅は、復元するのが難しい。帯域幅割振りストラテジがあまりに大胆である場合、異なるストリーム上の同期バーストは、パケットロスを引き起こすか、またはリアルタイム送信に影響を及ぼし得る。したがって、様々な実施形態では、アグリゲートレイテンシセンシティブフローは、ＢＳＭを介してデータブロードキャストを広告し得るデータキャスティング配信フレームワーク（ＤＤＦ：datacasting delivery framework）を使用して、パイプにおいて「パケット化」され、ストリーミングされ得る。たとえば、図７９Ｄは、レイテンシセンシティブデータと、レイテンシトレラントデータと、リアルタイムデータが、分離され、個々のストリーム上で送信される、レイテンシトレラントコンテンツおよびレイテンシセンシティブコンテンツのためのトランスポートのための統合システムを示している。図７９Ｄは、レイテンシセンシティブデータはパイプの１つのセット（レイテンシセンシティブデータパイプ１〜２）上で送信され得、レイテンシトレラントデータはパイプの別のセット（レイテンシトレラントデータパイプ１〜２）上で送信され得ることを示している。

上記で説明したように、様々な実施形態では、データブロードキャストはＢＳＭを介して広告され得る。様々な実施形態では、ＢＳＭは、より小さいブロードキャストスケジュール期間（ｂｓｐ：３０秒〜５分）（ＢＳＰは一般に１５分）にわたってのみスケジュール情報を広告し得る。様々な実施形態では、異なるレイテンシ要求に対処することをサポートするために複数のスケジュール期間が使用され得る。これは、低レイテンシデータのためのバッテリー効率を改善し、データ変更のはるかに大きい期間を可能にする（たとえば、システムは毎秒監視される必要がない）。さらに、低レイテンシ（３０秒強）を有するＣＢＲストリームデータの場合、データのパケット化により、システムはデータストリームを毎秒監視することを回避することが可能になる。

図７９Ｅは、レイテンシトレラントコンテンツおよびレイテンシセンシティブコンテンツのためのトランスポートのための別の統合システムを示している。図７９Ｅは、レイテンシトレラントコンテンツおよびレイテンシセンシティブコンテンツの統合トランスポートのために様々なレベルのスケジュールブロードキャストグラニュラリティが追加され、階層化され得ることを示している。たとえば、第１のレベルでは、ブロードキャストスケジュール期間は長期スケジュール期間を指定し得る。これらの長期スケジュール期間は５分の倍数単位であり得る。一実施形態では、長期スケジュール期間は１５分の長さであり得る。様々な実施形態では、長期スケジュール期間は、１５分を上回るレイテンシを許容することができるアプリケーション用に指定され得る。第２のレベルでは、中間スケジュール期間が使用され得る。この中間スケジュール期間はＩＡＦモニタ期間と同じであり得る。様々な実施形態では、中間スケジュール期間は、長期スケジュール期間よりも短い任意の持続時間であり得る。たとえば、一実施形態では、中間スケジュール期間は、５分の長さであり、５分ＢＳＰレイテンシ制約をもつアプリケーションに適応するために使用され得る。図７９Ｅは、第１および第２のレベルに加えて、様々な実施形態では、長期および中間スケジューリング期間に加えて、複数の短期スケジュール期間が使用され得ることをも示している。これらの短期スケジュール期間は、ＩＡＦ監視期間よりもはるかに小さく（３０秒〜５分）、低レイテンシ（３０秒〜５分）データをサポートするように定義され得る。

図７９Ｆは、レイテンシトレラントコンテンツおよびレイテンシセンシティブコンテンツのためのトランスポートのためのさらに別の統合システムを示している。図７９Ｆは、複数の短期スケジュール期間をサポートする際に、ＢＳＦが複数の論理ＢＳＭを搬送し得ることを示している。各ＢＳＭは、特定のターゲットレイテンシをカバーするスケジュールを記述し得、各ＢＳＭは、ＢＳＭが次にいつ更新されるべきかを識別する次のモニタ時間を搬送し得る。一実施形態では、ＢＳＭについての数および期間は、アプリケーションによって構成可能であり、駆動され得る。様々な実施形態では、ＢＳＭは、期間変更時にはより頻繁に、およびその後はより低い頻度で送られ得る。様々な実施形態では、デバイスアプリケーションは、所望のレイテンシにおいて監視することを要求し得る。たとえば、図７９Ｇは、デバイス／サーバデータキャスティングアプリケーションがレイテンシ要求について知り得ることと、データキャスティング配信フレームワークが、トランスポート／キャプチャ要求を、レイテンシ要求を満たすＢＳＭ期間にマッピングし得ることとを示している。様々な実施形態では、デバイスデータキャスティング配信フレームワーク（ＤＤＦ）は、アプリケーションのレイテンシ要求を満たす最低更新期間においてＢＳＭを監視し得る。

図８０に、送信リソース（すなわち、パイプ）が特定のコンテンツプロバイダおよび／またはワイヤレスネットワーク事業者に専用であるようにもファイル配信パイプが編成されて、これらの編成がブロードキャストネットワークのトランスポートサービスを活用することが可能になり得ることを示す。たとえば、図８０は、他のパイプを使用することについての競合なしに、所与のコンテンツプロバイダ／ワイヤレス事業者からのファイル（たとえば、ｅＩＤ＿１〜ｅＩＤ＿４）のためのコンテンツが常に１つのパイプにおいて搬送されることを示している。

ファイル配信パイプは、論理ファイル配信パイプ上でファイルをトランスポートするために使用される実際の送信フローを識別するパイプフローＩＤのセットによって定義され得る。図８１Ａ〜図８１Ｃに、ファイル配信パイプのための３つの代替編成を示す。たとえば、図８１Ａに示すように、ファイル配信パイプフローＩＤは、特定のアプリケーションまたはサービスに専用であり得る（たとえば、各アプリケーションは別個のパイプフローＩＤを有し得る）。そのようなサービスへのアクセスは、そのようなアプリケーションまたはサービスへのサブスクリプションに制約され得、ファイル配信パイプフローへのアクセスは、限定アクセスソリューションを介して保護され得る。様々な実施形態では、限定アクセスソリューションの専用リソースのアプリケーションまたはサービス発見は、システム情報送信などの別個の機構を介して行われ得る。たとえば、一実施形態では、ブロードキャストスケジュールメッセージは、各送信についてのフローＩＤを記述し得る。

別の例として、図８１Ｂは、限定アクセスソリューション保護が必要でなく、システム情報ベースのサービス発見が必要とされないように、サブスクリプションを条件としない異なるアプリケーションまたはサービスにわたっていくつかのフローが共有され得る（たとえば、異なるアプリケーションに対して単一／共有パイプフローＩＤがある）、実装形態を示している。そのようなアプリケーションは、専用フローＩＤ割当てを必要とせず、したがって、ファイル配信パイプに対する時分割多重に関して同じフローＩＤを共有し得る。

第３の例として、図８１Ｃは、アグリゲートタイプリソースを超えない限り、ファイル取込みシステム上のファイル配信パイプスケジューリングアルゴリズムが、異なるファイルを同時にスケジュールすることの追加のフレキシビリティで構成され得、図８２Ａ／Ｂに示すように、より大きいファイルの送信を中断することなしに、より小さいファイルがより低いデータレートで送信される、編成を示している。すなわち、より大きいファイルの送信の中断を防ぐ方法として、小さいファイルが同じパイプにおいてスケジュールされ得るように、異なる別個のパイプフローＩＤが使用され得る。そのような実装形態では、ファイル配信パイプは、複数の同時送信に適応するために複数のフローＩＤで構成され得る。

複数のファイル配信パイプの導入とともに、受信機デバイス上でのファイルの同時知覚の問題が起こり得る。これは、図７８Ａ／Ｂ、図７９Ａ、および図８０に示されており、（異なるパイプを使用する異なるプロバイダからのコンテンツへのアクセスをデバイスが有することができると仮定すると）複数のパイプが利用可能であり、したがって、各パイプを介して１つずつ、複数のファイルが同時に送信され得る、システムが示されている。

図８２Ａおよび図８２Ｂに、大きいファイルとともに小さいファイルの送信を扱うことの代替形態を示す。前述のように、ファイル配信パイプを用いたブロードキャストネットワークは、ファイルをパイプに関連付けることと、ファイルブロードキャストをスケジュールすることとを行うための方法を必要とすることになる。ファイルをパイプに関連付けることと、ファイルの送信をスケジュールすることとを行うために、プロビジョニングと入力パラメータの組合せがファイル取込みシステムスケジューラによって使用され得る。様々な実施形態では、パイプは、パイプへのロケーションリーチ（すなわち、パイプファイルがブロードキャストされる場所）を用いてプロビジョニングされ得る。様々な実施形態では、アプリケーション／サービスは地理的側面を有し得る。たとえば、ファイルシステム抽象化を使用する天気アプリケーションは、ディレクトリにおいてファイル名を／ｗｅａＡｐｐ／Ｅａｓｔ／ＮＹＣ／または／ｗｅａＡｐｐ／Ｗｅｓｔ／ＬＡ／として定義し得る。そのような場合、天気アプリケーションのためのファイルのプロビジョニングは、米国の東部においてブロードキャストされることになるワイドマルチプレックス上ではパイプＸ上の／ｗｅａＡｐｐ／Ｅａｓｔ／、および米国の西部においてブロードキャストされることになるワイドマルチプレックス上ではパイプＹ上の／ｗｅａＡｐｐ／Ｗｅｓｔ／であり得る。様々な実施形態では、（たとえば、低レイテンシアプリケーションファイルのための）優先度パイプがあり得る。様々な実施形態では、複数のパイプが、異なるファイルサイズおよびレイテンシ要求（たとえば、１５分、１分、および３０秒）をターゲットにし得る。様々な実施形態では、ファイル取込みシステムは、パイププロビジョニング情報へのアクセスを有し得る。様々な実施形態では、ブロードキャストすべきファイルを受信すると、ファイル取込みシステムは、プロビジョニングされた地理的リーチおよびポリシーに基づいて適切なパイプ上で、またはレイテンシ要求を保証するのに最も好適であるパイプ上で、ファイルをスケジュールし得る。様々な実施形態では、ファイル取込みシステムは、ファイルのサイズに応じてファイルをスケジュールし得る。たとえば、ファイル取込みシステムは、低帯域幅パイプを選ぶか、または低データレートで送信をスケジュールする太いパイプ上のフローＩＤを選択し得る。一実施形態では、図８２Ａおよび図８２Ｂに示すように、ファイル取込みシステムは、太いパイプ上でのより大きいファイルの送信を分割し得る。図８２Ｂに示すように、そのような独立送信は、あるファイルについての送信ウィンドウを、他のファイルの送信によって分離される複数の独立ウィンドウに分け得る。様々な実施形態では、ＢＳＭは、そのような独立送信を記述するための特徴および情報を含み得る。様々な実施形態では、受信機デバイスは、異なる独立ウィンドウの中からファイルを集めるように構成され得る。

したがって、様々な実施形態では、ファイル取込みシステムは、プロビジョニングと入力パラメータの組合せに基づいて（異なるパイプにおいて）ファイルを同時にスケジュールすることを試みるスケジューラを含み得る（たとえば、異なるワイヤレスキャリアのデバイスにとって利用可能であるファイルが同時にスケジュールされ得る）。代替的に、スケジューラは、第１の送信において同時ファイルのうちの一方を受信することを選択したデバイスが第２の送信上で他方のファイルをさらに受信することを可能にする方法として、同時に送信され得るファイルの複数の送信を計画し得る。

様々な実施形態では、ファイル取込みシステムは、各ファイルのデータパイプのブロードキャストリーチ（すなわち、ファイル配信パイプが受信され得る地理的エリア）に基づいてファイルをプロビジョニングし得る。すなわち、これらのファイル配信能力を利用するアプリケーションおよびサービスは、様々な地理的考慮事項を有し得る。たとえば、ファイルシステム抽象化を使用する天気アプリケーションは、予報ファイルが該当する地域を識別するファイル名およびディレクトリを定義し得る。したがって、ファイル取込みシステムは、ファイル配信パイプが、示された地域にファイルを配信することになるかどうかに基づいて、各天気アプリケーションファイルを特定のファイル配信パイプにプロビジョニングするために、天気アプリケーションファイル名を使用し得る。たとえば、ファイルディレクトリストリング「／ｗｅａＡｐｐ／Ｅａｓｔ／ＮＹＣ／」をもつファイルは、米国の東部においてブロードキャストされることになるワイドマルチプレックス内のファイル配信パイプに向けられ得、ファイルディレクトリストリング「／ｗｅａＡｐｐ／Ｗｅｓｔ／ＬＡ／」をもつファイルは、米国の東部においてブロードキャストされることになるワイドマルチプレックス内のファイル配信パイプに向けられ得る。

また、ファイルがファイル配信パイプの特定のセットにどのようにプロビジョニングされ得るかを定義するために、ポリシー考慮事項が使用され得る。たとえば、ビデオクリップ配信アプリケーションは、ＡＢＣチャネルのＡＢＣおよびＤｉｓｎｅｙ上のビデオクリップのファイルには「／ｃｌｉｐＡｐｐ／ＡＢＣ／ａｂｃ／」および「／ｃｌｉｐＡｐｐ／ＡＢＣ／Ｄｉｓｎｅｙ／」、ＥＳＰＮチャネル上のビデオクリップのファイルには「／ｃｌｉｐＡｐｐ／ＥＳＰＮ／ｅｓｐｎ／」および「／ｃｌｉｐＡｐｐ／ＥＳＰＮ／ｅｓｐｎ２／」など、ビデオクリップのソースに従ってファイルディレクトリにおいてビデオクリップ配信アプリケーションのファイルを編成し得る。そのように編成されると、ポリシー考慮事項は、ＡＢＣからのファイルはファイル配信パイプ１上へのプロビジョンであるべきであり、ＥＳＰＮビデオクリップファイルはファイル配信パイプ２上へのプロビジョンであるべきであることを指示し得る。

また、特定のファイル配信パイプへのファイルのプロビジョニングは時間ダイバーシティ要求に依存し得る。たとえば、小さいファイルは、より高い受信信頼性を可能にするために再送信間の若干の時間分離を用いて複数回送信されるか、またはより長い時間期間にわたってより低いデータレートで送信され得る。

様々な実施形態では、ファイル取込みシステムは、ファイル配信パイププロビジョニング情報へのアクセスを有し得る。ブロードキャストネットワークを介してトランスポートのためのファイルを受信すると、ファイル取込みシステムは、地理的リーチおよびポリシー考慮事項に基づいて、受信したファイルを適切なファイル配信パイプにプロビジョニングし得る。追加または代替として、ファイル取込みシステムは、受信したファイルのために指定されたレイテンシ要求が満たされることを保証するために、受信したファイルをファイル配信パイプにプロビジョニングし得る。追加または代替として、ファイル取込みシステムは、ファイルのサイズに応じて、受信したファイルをファイル配信パイプにプロビジョニングし得、低帯域幅パイプを選ぶこと、または高帯域（「太い」）ファイル配信パイプ上のフローＩＤを選択することおよび低データレート送信を指定することが、図８１Ｃに示されている。

さらに、ファイル取込みシステムは、図８２Ｂに示すように、大きいファイルが複数の独立送信ウィンドウに分けられ得、その結果、他のより小さいファイルが中間に送信され得るように、独立した形で送信のために大きいファイルをスケジュールし得る。受信機デバイスが、異なる独立ブロードキャストウィンドウからファイル部分を受信することと、受信時にファイル部分を元のファイルに再アセンブルすることとを可能にするために、独立送信ウィンドウの編成に関する情報は、ブロードキャストスケジュールメッセージ中に含まれ得る。特定のファイル配信パイプ内でスケジュールされたすべてのファイルについてのブロードキャストウィンドウを定義するために、ファイル配信パイプデータレート、および各ファイルのサイズが使用され得る。

図８３Ａに、一実施形態による、受信したファイルをファイル配信パイプに割り振るためにファイル取込みシステム内に実装され得る例示的な方法８３００を示す。方法８３００では、ステップ８３０２において、ファイル取込みシステムは、帯域幅特性（たとえば、データレート）などのファイル配信パイプ識別子、およびポリシー制限を判断する。ステップ８３０４において、ファイル取込みシステムは、利用可能なファイル配信パイプに関するこの知識を使用して、受信したファイルを特定のファイル配信パイプに割り振る。上記で説明したように、配信パイプへのファイルのこの割振りは、（たとえば、ターゲット受信機デバイスを包含する地理的エリアにファイルが配信されることを保証するための）複数のカバレージエリア、ファイルレイテンシ制限（すなわちファイル緊急度）、ファイルサイズ、パイプデータレート、および他のポリシー考慮事項に基づき得る。ファイルが特定の配信パイプに割り振られると、ファイル取込みシステムは、ステップ８３０６において、トランスポートの要求された品質に従って、各ファイル配信パイプによって搬送されているファイルについてのブロードキャストスケジュール（すなわち、ブロードキャストウィンドウ）を判断する。上記で説明したように、ブロードキャストスケジュールは、ファイルサイズをファイル配信パイプデータレートで除算することによって判断され得る、各ファイルについてのブロードキャスト持続時間に基づき得る。ファイルは、ブロードキャストスケジューリング期間においてより緊急のファイルをより早くブロードキャストすることなどによって、ファイルの相対的な緊急度に基づいてブロードキャストスケジューリング期間内のブロードキャストのためにスケジュールされ得る。ステップ８３０８において、ファイル取込みサービスは、ファイル識別子、ファイルブロードキャストウィンドウ、ファイルパラメータなどとともに、ファイル配信パイプＩＤをブロードキャストスケジュールメッセージ中に含める。ステップ８３１０において、ファイル取込みシステムは、ブロードキャストスケジュールフローにおいてブロードキャストスケジュールメッセージをブロードキャストするようにブロードキャストシステムに指示し得、ステップ８３１２において、ブロードキャストスケジュールメッセージにおいて指定されたブロードキャストウィンドウに従って、識別されたファイル配信パイプを介してファイルを送信することを開始することを、ブロードキャストシステムに行わせ得る。

図８３Ｂに、複数のパイプ上での送信のためにファイルをスケジュールすることをサポートするスケジューラのための例示的な方法８３５０を示す。そのようなスケジューラは、ファイル取込みプロセスの一部として、ファイル取込みのときに与えられたスケジュール制約に従って複数のパイプ上でファイルを同時に送信することを選択的に可能にする。複数パイプスケジューラは、ファイルの単一のインスタンスが複数パイプ上でスケジュールされる、重複しない状況と、異なるファイルの２つのインスタンスが重複する、重複する複数ファイルと、同じファイルの２つのインスタンスが重複する、重複する単一ファイルの場合とを含む、複数の重複する場合に対処し得、これは、厳しい送信デッドラインを用いてファイルをプッシュするために、または異なるレーンにおいて同じファイルの異なるインスタンスを送るために使用され得る。図８３Ｂを参照すると、複数パイプスケジューラが、ステップ８３５２において、開始時間に残差ファイルのセット（Ｒ）を計算し、削除されたファイルを残差ファイルから減算し、追加のファイルを残差ファイル中に含め、ディレクトリファイルを計算し、それらを残差ファイル中に含める。

スケジューラは、ステップ８３５４において、スケジュールされるべき各ディレクトリおよびファイルの第１のインスタンスについてのスケジュールウィンドウ（ＳＷ）を計算する。ステップ８３５６において、スケジューラは、次いで、時間的に最も早いスケジュールウィンドウをもつ利用可能なファイルインスタンスＫを選択し、ディレクトリ情報ファイルのほうを優先してタイブレークする。スケジューラは、次いで、ステップ８３５８において、現在のスケジューリング制約のためのゴーストブロードキャストウィンドウおよび復号持続時間ウィンドウを作成する。ステップ８３６０において、スケジューラは、図８３Ｂに示す計算に基づいて個々のファイルを選択する。ステップ８３６２において、スケジューラは、次いで、最も早いスケジュール可能時間をもつレーンまたはパイプを選択する。そうする際に、スケジューラは、スケジュールウィンドウ開始時間と前にスケジュールされたファイルとの間の最小ギャップをもつレーンを選択することによって、同等のものの中から選択し得る。これによりタイになった場合、スケジューラは１つをランダムに選び得る。

判断ステップ８３６４において、スケジューラは、ブロードキャストウィンドウが（もしあれば）既存のブロードキャストウィンドウおよび復号持続時間と重複するかどうかを判断し得る。重複する場合（すなわち、判断ステップ８３６４＝「はい」）、スケジューラは、ステップ８３６６において、ファイルｊのｋ番目のインスタンスの復号ウィンドウおよび時間を重複配信ウィンドウの時間まで進めて、ステップ８３６０においてファイルｊの次のインスタンスｋを選ぶことに戻り得る。ブロードキャストウィンドウ重複がない場合（すなわち、判断ステップ８３６４＝「いいえ」）、スケジューラは、ステップ８３６８において、利用可能なファイルインスタンスを更新し、判断ステップ８３７０において、ファイルｊのｋ番目のインスタンスの復号ウィンドウおよび時間が、いずれかの利用可能なファイルインスタンスのスケジュールウィンドウから外れるかどうかを判断し得る。外れる場合（すなわち、判断ステップ８３７０＝「はい」）、スケジューラは、ステップ８３７２において、変更を廃棄し、スケジューリングが失敗したことを示す。外れない場合（すなわち、判断ステップ８３７０＝「いいえ」）、スケジューラは、判断ステップ８３７４において、ファイルｊの現在のインスタンスがファイルディレクトリ中の直接インスタンスの数未満であるどうかを判断し得る。上記直接インスタンスの数未満でない場合（すなわち、判断ステップ８３７４＝「いいえ」）、スケジューラは、ステップ８３８０において、残差ファイルからファイルを除去する。判断ステップ８３８２において、スケジューラは、残差ファイルが空であるかどうかを判断する。残差ファイルが現在空である場合（すなわち、判断ステップ８３８２＝「はい」）、スケジューラは、ステップ８３８４において、変更をコミットし、スケジューリングが成功したことを示す。残差ファイルが空でない場合（すなわち、判断ステップ８３８２＝「いいえ」）、スケジューラは、ステップ８３５６に戻って、最も早いスケジュールウィンドウ終了時間をもつ利用可能なファイルインスタンスを選択する。

スケジューラが、インスタンスＫがインスタンスのファイルディレクトリ数未満であると判断した場合（すなわち、判断ステップ８３７４＝「はい」）、スケジューラは、ステップ８３７６において、現在のインスタンスを１に設定し、ファイルを断片化し、他の断片デッドラインを調整する。次いで、スケジュールは、ステップ８３７８において、スケジュールされた時間を計算し、ファイルｊのＫ番目のインスタンスについてのスケジュールウィンドウを計算し、その後、ステップ８３５６に戻って、最も早いスケジュールウィンドウおよび時間をもつ利用可能なファイルインスタンスを選択する。

ファイルコンテンツプロバイダは、ファイルをファイル取込みシステムに与えるためにｓｅｎｄＦｉｌｅＲｅｑｕｅｓｔ演算を使用し得る。ｓｅｎｄＦｉｌｅＲｅｑｕｅｓｔ演算は、（たとえば、ｆｉｌｅＦｅｔｃｈＩｎｆｏを介して）送信のためにサブミットされるファイルを識別するための機構と、各ファイルまたはファイルのグループについての異なる配信基準または送信要求を定義するための機構とを含み得る。ファイルは、ファイルがブロードキャストのためにそこから取り出され得るロケーションを与える、コンテンツＵＲＬに基づいて識別され得る。また、ファイル識別は、アプリケーションディレクトリ構造においてファイルのためのディレクトリを示すために使用され得るファイル名（たとえば、／ｉｔｖ／ｒｅｓ／ｓｖｃ＿５／ｆ１．ｊｐｇ）、およびファイルを特徴づけるパラメータを与え得る属性リスト（たとえば、ジャンル＝ドラマ、性別＝男性、年齢＝２０〜３０など）など、コンテキストを、取り込まれているファイルにさらに割り当てるかまたは関連付ける、追加のパラメータを識別し得る。受信機デバイス上に実装される受信機アプリケーションが、キャプチャされるべきであるブロードキャストされているファイルを識別することを可能にするために、これらの追加のパラメータは、ブロードキャストスケジュールメッセージにおいてトランスポートされ得る。

属性リストが、ｃａｔ．ｘｍｌにおいて搬送されるのか、ブロードキャストスケジュールメッセージにおいて直接搬送されるのかは、ファイルをサブミットするアプリケーションによって何のサービスが望まれるかの関数である。サブミットするアプリケーションが、ダウンロードすべきファイルを受信機デバイスがより良く選択することを可能にするためにカタログファイルをユーザに与えるためなどに、カタログファイルを管理することを選好する場合、アプリケーションは、カタログファイルを管理することができ、また、カタログをどのように使用すべきかに関する論理を受信機デバイスにおいて（たとえば、ファイルを受信しようとするデバイスアプリケーションにおいて）与えることができる。アプリケーションが、能力の劣る受信機デバイス、または対応するデバイスアプリケーションで構成されていない受信機デバイスのための、単純な実装形態を有する必要がある場合、アプリケーションは、上記で説明した方法を使用して属性リストを配信するためにブロードキャストスケジュールメッセージに依拠することができる。

図８４に、様々な実施形態を実装するのに好適な受信機デバイス１０内に実装され得る機能モジュールを示す。受信機デバイス１０のソフトウェアモジュールは、図８４に示すものと同様のソフトウェアアーキテクチャ８４００で編成され得る。ブロードキャスト送信は、受信機デバイス物理レイヤによって受信され、ＦＬＯトランスポートネットワークモジュール８４０１などのブロードキャスト受信機モジュールによって処理され得る。ファイルトランスポートネットワーク８４０１によって受信されたビデオおよびオーディオストリームはメディア受信機モジュール（図示せず）によって処理され得る。ファイルトランスポートネットワーク８４０１上で受信されたファイル転送ストリームは、ファイルパケットを受信し、それらをデバイスソフトウェアアーキテクチャ８４００内の適切なモジュールおよびアプリケーションに向けるように機能する、ファイルマネージャモジュール４４に与えられ、それによって処理され得る。オーバーヘッドデータストリームは、オーバーヘッドデータパケットを処理し、受信したメタデータとオーバーヘッドデータとをデバイスシステムアーキテクチャ８４００内の適切なモジュールに向けるように機能する、オーバーヘッドデータ収集モジュール８４０８に渡され得る。サービスＳＩ収集モジュール８４０７は、オーバーヘッドデータストリームからサービスＳＩデータを収集し、この情報をファイル配信システムモジュール４４およびオーバーヘッドデータ収集モジュール８４０８にフォワーディングし得る。受信したサービスＳＩデータから、ファイル配信システムモジュール４４は、双方向性リソースデータを搬送するファイルデータフローのフローＩＤを判断し得る。受信したサービスＳＩデータから、オーバーヘッドデータ収集モジュール８４０８は、双方向性シグナリングデータを搬送するシグナリングフローを判断し得る。双方向性イベントをサポートするために、デバイスソフトウェアアーキテクチャ８４００は、双方向性イベントを受信し、管理し、記憶するための、ユーザインターフェース（ＵＩ）アプリケーション８４０４とファイルトランスポートネットワーク８４０１との間のインターフェースとして働くファイル受信サービス８４０２を含み得る。双方向性サービス８４０２とＵＩアプリケーション８４０４は一緒に、双方向性アプリケーション８５０２として編成され得る。ユーザインターフェースアプリケーションモジュール８４０４は、いくつかの双方向性アプリケーションとユーザエージェントとを含み得る。

様々な実施形態では、ファイル配信サービスモジュール４４は、いくつかのサービスをデバイスアプリケーションに与え得る。単一ファイルキャプチャサービスにより、デバイスアプリケーションは単一のファイルのキャプチャを要求することが可能になり得る。そうするために、デバイスアプリケーションは、ｓｉｎｇｅＣａｐｔｕｒｅ（／ｉｔｖ／ｒｅｓ／ｓｖｃ＿５／ｆ２．ｊｐｇ）のような要求などにおいて、ファイル配信サービスモジュール４４にアプリケーション固有ファイル名を与える。

上記で説明したように、ファイル配信サービスモジュール４４によって与えられ得る別のサービスは連続ファイルキャプチャサービスであり、これにより、デバイスアプリケーションは、単一のファイル名の、または所与のディレクトリ下のすべてのファイルの、更新の連続キャプチャを要求することが可能になる。デバイスアプリケーションは、指定されたファイルのすべての更新が受信されるべきであることを示すために、ｃａｐｔｕｒｅ ａｌｌ要求においてアプリケーション固有ファイル名を指定し得る。このサービスについての一般的な用途は、カタログファイルなどのアプリケーションオーバーヘッドファイルの変更を追跡することであろう。たとえば、双方向性アプリケーションカタログファイルのすべての更新を受信するために、アプリケーションはｃａｐｔｕｒｅＡｌｌ（／ｉｔｖ／ｓｉｇ／ｃａｔ．ｘｍｌ）要求を発行し得る。デバイスアプリケーションは、そのアプリケーションが、受信機デバイスに現在記憶されていないアプリケーション固有ディレクトリ中のすべてのファイルを受信することに関係しているとき、そのディレクトリを指定し得る。たいていの場合、これは、所望のディレクトリ下のすべての新しいファイルであることになる。たとえば、天気アプリケーションでは、そのような要求は、ＮＹＣサブディレクトリファイル名をもつすべてのファイルのダウンロードを要求するためのｃａｐｔｕｒｅＡｌｌ（／ｗｅａＡｐｐ／ＮＹＣ／）であり得る。単一ファイルキャプチャサービスとは異なり、ｃａｐｔｕｒｅ ａｌｌサービスは、要求されたファイルの、または指定されたディレクトリ下の新しいファイルの、新しい送信を監視し続ける。このサービスは、新しいファイルがいつ受信のために利用可能であるか、またはファイルの新しいバージョンがいつ利用可能であるかをシグナリングすることが不可能であるファイルトランスポートネットワークに依存する。そのような情報は、新しいファイル名の形態で、またはファイルメタデータ中に含まれる更新されたバージョン番号を用いた同じファイル名の形態で、ブロードキャストスケジュールメッセージにおいて与えられ得る。同じファイルを移動回数受信することはデバイスバッテリーを不必要に消耗させることになるので、受信機デバイス上のファイル配信サービスモジュール４４は、同じファイルを移動回数受信することを回避するために、メモリに記憶されたファイルのバージョンを追跡することと、ブロードキャストスケジュールメッセージにおいて与えられるバージョン情報を追跡することとを行うように構成され得る。

図８５に示すように、サービスアイコンアプリケーション８５０１、双方向性アプリケーション８５０２、およびマルチプレゼンテーションリストビュー（ＭＰＶ：Multi-Presentation list View）アプリケーション８５０３などのデバイスアプリケーションは、実行されるべきファイル収集のタイプ（すなわち、ｃａｐｔｕｒｅＯｎｃｅまたはａｕｔｏＣａｐｔｕｒｅ）とともに、収集されるべきファイルを指定し得る。ファイル名またはファイル拡張子を識別するために、デバイスアプリケーションは、オーバーヘッドブロードキャスト送信の一部として与えられるチャネルシステム情報（ＳＩ：system information）８５０４および／またはサービスＳＩ８５０５、８５０６からそのような情報を受信し得る。また、いくつかのデバイスアプリケーションは、様々なデバイスアプリケーションがそれにサブスクライブしたブロードキャストサービスへの登録およびサブスクリプションを管理するアプリケーションであり得る、サブスクリプションマネージャ８５０７によってサポートされ得る。

ファイル配信サービスモジュール４４において提供され得る第３のサービスは、デバイスアプリケーションが、ファイルの単一キャプチャ（ｓｉｎｇｌｅＣａｐｔｕｒｅ）をキャンセルすること、あるいはファイルまたはディレクトリの連続キャプチャ（ｃａｐｔｕｒｅＡｌｌ）をキャンセルすることを可能にする、キャンセルサービスである。アクティブにされると、キャンセルサービスは、ファイル配信サービスモジュール４４が、キャンセルされた元の要求に関連付けられたファイルを収集することを試みるのを停止させる。

図８６に、一実施形態による、ブロードキャストのためにスケジュールされたファイルのカタログにおいてファイルのために使用され得る例示的なデータスキーマ８６００を示す。図８６に示すように、カタログファイル８６０１がファイル情報８６０２を備え得、ファイル情報８６０２は、それ自体が、ファイル名データフィールド８６０３と、随意のフィルタ処理属性データフィールド８６０４と、随意のアプリケーションパラメータデータフィールド８６０５とを備え得る。ファイル名データフィールド８６０４は、ルートディレクトリとサブディレクトリとを含むファイル名ストリングなどの完全修飾された抽象的なファイル名を含み得る。随意のフィルタ処理属性データフィールド８６０４は、サブディレクトリ、ファイルタイプまたはファイル拡張子、あるいは他の好適なファイル記述パラメータなど、フィルタ処理に有用な追加情報を含み得る。随意のアプリケーションパラメータデータフィールド８６０５は、個々のファイルが受信されるべきかどうかを判断するのに有用であり得る、データファイルがそれを対象とするアプリケーションに関する情報を含み得る。

ファイルキャプチャサービスを与えるために、ファイル配信サービスモジュール４４は、どのファイルを受信すべきか、およびそれらをいつ受信すべきかを判断するために、ブロードキャストスケジュールメッセージにおいて与えられる情報を使用する。図８７Ａに、受信機デバイスのプロセッサまたは集積受信機／プロセッサチップが、デバイスアプリケーションからｓｉｎｇｌｅＣａｐｔｕｒｅサービスファイルダウンロード要求を受信することに応答して実装し得る、実施方法８７００ａを示す。方法８７００ａでは、ステップ８７０２において、受信機デバイスのプロセッサは、デバイスアプリケーション（すなわち、受信機デバイスのプロセッサ内で動作しているアプリケーション）からファイルダウンロード要求を受信する。

上記で説明したように、ブロードキャストスケジュールメッセージは、ファイル配信サービスモジュール４４が受信のためのファイルを選択するために必要とする情報とともに、ブロードキャストされることになるファイルの名前を含む。したがって、ステップ８７０４において、プロセッサ内に実装されたファイル配信デバイスモジュール４４は、受信したブロードキャストスケジュールメッセージを監視する。ステップ８７０４は、オーバーヘッドフローからブロードキャストスケジュールメッセージを受信するのに十分長く受信機デバイスの受信機回路を瞬間的にアクティブにすること、ならびに受信したブロードキャストスケジュールメッセージの含まれた情報を取得するために、そのブロードキャストスケジュールメッセージを処理することに関与し得る。ステップ８７０６において、プロセッサは、ブロードキャストされることになる１つまたは複数のファイルの（それらのファイル拡張子を含む）名前を取得する。上述のように、ファイル拡張子であったそのようなファイル名は、ブロードキャストスケジュールメッセージのブロードキャストスケジュール記録（ＢＳＲ）内に含まれ得る。ステップ８７０８において、プロセッサは、ブロードキャストスケジュールメッセージから取得されたファイル名またはファイル拡張子ストリングを、ステップ８７０２において与えられた要求デバイスアプリケーションによって指定されたファイル名またはファイル拡張子と比較する。判断ステップ８７１０において、プロセッサは、ブロードキャストスケジュールメッセージにおいて指定されたファイル名またはファイル拡張子と、デバイスアプリケーションによって要求されたファイル名またはファイル拡張子との間にマッチがあるかどうかを判断する。マッチがない場合（すなわち、判断ステップ８７１０＝「いいえ」）、プロセッサは、ステップ８７１１において、ブロードキャストスケジュールメッセージが更新されることになる、ブロードキャストスケジュールメッセージにおいて示される時間まで待つ。上記で説明したように、同じブロードキャストスケジュールメッセージが更新時間まで繰り返しブロードキャストされ得る。更新されたメッセージがいつブロードキャストされることになるかをブロードキャストスケジュールメッセージにおいて指定することによって、受信機デバイスは、新しいブロードキャストスケジュールメッセージが送信されていることになるまで、受信機デバイスの受信機回路を非アクティブのままにしておくことによって、バッテリー電力を温存することができる。現在時間が、識別されたブロードキャストスケジュールメッセージ更新時間に等しいとき、プロセッサは、ステップ８７０４に戻って、更新されたブロードキャストスケジュールメッセージを受信し、処理する。

プロセッサは、ブロードキャストスケジュールメッセージにおいて指定されたファイル名またはファイル拡張子が、ステップ８７０２においてデバイスアプリケーションによって指定されたファイル名または拡張子にマッチすると判断した場合（すなわち、判断ステップ８７１０＝「はい」）、マッチしたファイルの受信をスケジュールし得る。これは、ステップ８７１２において、マッチしたファイルについてのブロードキャスト時間および受信情報（たとえば、フローＩＤ、ＩＰアドレスによるＩＰフロー識別子、および／またはＵＤＰポート番号）をブロードキャストスケジュールメッセージから取得することと、ステップ８７１４において、ブロードキャスト時間に基づいてマッチしたファイルの受信をスケジュールすることとによって、達成され得る。マッチしたファイルの受信をスケジュールすることは、判断ステップ８７１６において、たとえば、現在時間が、メモリに記憶された時間にマッチするとき、ファイル受信ルーチンを開始するための割込みを生成するために、現在時間と頻繁に比較される取得されたブロードキャスト時間をメモリレジスタに記憶することによって、達成され得る。現在時間が、スケジュールされたブロードキャスト時間にマッチしない間（すなわち、判断ステップ８７１６＝「いいえ」）、（ステップ８７０４〜８７１１に関して上記で説明したように）ブロードキャストスケジュールメッセージの受信処理が並列に続き得るので、プロセッサは、ステップ８７１１を実行して、ブロードキャストスケジュールメッセージが更新される時間を待つ。スケジュールされたブロードキャスト時間の直前に（すなわち、判断ステップ８７１６＝「はい」のとき）、プロセッサは、ステップ８７１８において受信機デバイス受信機回路を起動し、ステップ８７２０において、広告されたトランスポートストリームから選択されたファイルを受信する。ステップ８７２０の一部として、プロセッサ内で動作しているファイル配信サービスモジュール４４は、上記で説明したように、受信したファイルをメモリに記憶し、いくつかの実施形態では、そのファイルのバージョン番号をノートし得る。ステップ８７２２において、プロセッサ内で動作しているファイル配信サービスモジュール４４は、上記で説明したプロセスを使用して、受信したファイルを要求アプリケーションに渡し、これにより、元のアプリケーション要求が満たされる。ファイルを受信した後に、プロセッサは、受信機回路を非アクティブにし、ステップ８７１１に戻って、ブロードキャストスケジュールメッセージが更新されることになる時間を待つ。

デバイスアプリケーションがｓｉｎｇｌｅＣａｐｔｕｒｅサービスを使用してファイルダウンロードを要求するとき、ステップ８７０２において、１つまたは複数の特定のファイル名がデバイスアプリケーションによって指定され得る。指定されたファイルが受信され、メモリに記憶され、および／または要求デバイスアプリケーションに渡されると、ファイルダウンロード要求は、同じファイルの後続のブロードキャストが受信されないように、プロセッサによってキャンセルされ得る。

ブロードキャストネットワークを介してトランスポートされているファイルに関する情報が、トランスポートのためのファイルをサブミットするヘッドエンド側アプリケーションによって与えられるカタログファイルにおいて識別されるとき、カタログファイルは、図８６に示すデータスキーマにおいて識別される情報を含み得る。そのようなカタログファイルにおいて与えられた情報を使用して、デバイスアプリケーションは、ファイルシステム抽象化が使用されるときのファイルのファイル名、および／または各ファイルに関連付けられ得るフィルタ処理属性に基づいて、キャプチャのためのファイルを指定し得る。次いで、受信機デバイス上のアプリケーションは、受信機デバイスまたはユーザの属性にマッチする属性をもつダウンロードファイルを選択するために、アプリケーションにとって知られている（受信機デバイスユーザの性別および年齢などの）情報と組み合わせて、受信したカタログファイルを使用し得る。ファイル名はカタログファイル中に含まれ得るので、デバイスアプリケーションは、ｓｉｎｇｌｅＣａｐｔｕｒｅ演算においてファイルのファイル名を使用してファイルのキャプチャを要求し得る。

図８７Ｂに、ｃａｐｔｕｒｅ ａｌｌサービスを達成するために受信機デバイスのプロセッサ内に実装され得る実施方法８７００ｂを示す。デバイスアプリケーションが、特定のファイルについてのすべての更新を受信し続けるためなどに、連続キャプチャ要求サービス（たとえば、ａｕｔｏＣａｐｔｕｒｅ（ｉｔｖ／ｓｉｇ／ｃａｔ．ｘｍｌ）またはａｕｔｏＣａｐｔｕｒｅ（ｉｔｖ：１））を使用してファイルダウンロードを要求するとき、図８７Ａを参照しながら上記で説明した動作は、マッチするファイルが受信され、メモリに記憶された後、ファイルダウンロード要求が自動的にキャンセルされないということを除いて、実行され得る。ファイルダウンロード要求がアクティブのままであるので、プロセッサは、ファイル拡張子基準にマッチするファイルを受信し続け得る。（信頼できる受信を保証するためにファイルが複数回ブロードキャストされ得るので）冗長ファイルの受信を回避することによってバッテリー電力を温存するために、プロセッサは、ブロードキャストスケジュールメッセージにおいて指定されたマッチしたファイルについてのファイル名またはバージョン番号を、メモリに記憶されたファイル名および／またはバージョン番号と比較するという追加の判断ステップ８７１３を実行し得る。マッチしたファイルが、メモリに記憶されたファイルと同じファイル名、ファイルＩＤ／要素ＩＤまたはバージョン番号を有する場合（すなわち、判断ステップ８７１３＝「はい」）、そのファイルを再び受信する必要はなく、したがって、プロセッサは、ステップ８７１１に進んで、ブロードキャストスケジュールメッセージが更新されるまで待つ。しかしながら、ブロードキャストスケジュールメッセージにおいて識別されるマッチしたファイルのファイル名、ファイルＩＤ／要素ＩＤまたはバージョン番号が、メモリに記憶されたものとは異なるファイル名またはバージョン番号を有する場合（すなわち、判断ステップ８７１３＝「いいえ」）、プロセッサは、続いて、図８７Ａを参照しながら上記で説明したようにステップ８７１２〜８７２２に進むことによって、識別されたファイルの受信をスケジュールし得る。ファイル配信要求は、マッチするファイルの受信時に自動的にキャンセルされないので、プロセッサ内で動作しているファイル配信サービスモジュール４４は、その要求がアクティブのままである限り、ブロードキャストスケジュールメッセージを監視することと、すべてのマッチするファイルの更新をキャプチャすることとを続け得る。

ブロードキャストシステム、ユニキャストネットワーク、またはブロードキャストネットワークとユニキャストネットワークの組合せを介した、ファイル配信のためのファイル名抽象化の使用により、展開するのが簡単であるファイル配信サービスが可能になる。よく知っているファイル拡張子概念が利用され得るので、そのような通信ネットワークを使用したアプリケーションは、開発するのがより容易であり得る。ファイルを取り込むためのヘッドエンドシステム（たとえば、ファイル取込みシステム）を与えることと、ファイルシステムにおけるパスの一部としてブロードキャストのためのファイルを命名することとによって、様々な実施形態が既存のブロードキャストシステム内に実装され得る。ファイル取込みシステムは、ブロードキャストネットワークにおけるブロードキャストスケジュールメッセージオーバーヘッドフローなどの何らかのソリューション固有シグナリング機構を介して、ファイルを取り込むためのインターフェースを与え、（ブロードキャストネットワーク上で送信される場合は）ファイルトランスポート機会をスケジュールし、利用可能なファイルをデバイスに広告する。受信機デバイス内では、ヘッドエンドシグナリングを理解し、ブロードキャストファイルをキャプチャしたいというデバイスアプリケーション要求を受信し、ならびに適切な状態情報を維持して、重複ファイル受信を回避し、ファイル更新を検出するために、ソフトウェア更新などにおいて、ファイル配信サービスモジュールが実装され得る。そのようなシステムでは、アプリケーションは、ブロードキャストサービスからの受信のためのファイルを指定するために、アプリケーションのルートディレクトリおよびアプリケーション固有サブディレクトリ編成を知っているだけでよいので、デバイスアプリケーション開発は簡略化される。その場合、アプリケーションは、システム情報など、さらなる発見機構またはブロードキャストシステムの知識を必要とすることなしにファイルがキャプチャされることを要求することができる。ファイルキャプチャ要求は、登録プロセスを介して、あるいはアプリケーションツーファイル配信フレームワークインターフェースまたはＡＰＩを通して行われ得る。アプリケーション開発者にとって、このファイル拡張子パラダイムは、ファイルシステム上のファイルへのアクセスを要求すること、またはＦＴＰとしてファイル転送プロトコルを介してファイルをフェッチすることに類似する。

ブロードキャストスケジュールメッセージの形態のオーバーヘッド情報を送信するブロードキャストファイルトランスポートネットワークは、ブロードキャストされることになるファイルに関する情報、ならびにコンテキストを各ファイルに関連付けるための追加情報（たとえば、アプリケーションディレクトリスペース上のディレクトリ名、または属性特性のリストなど）を受信デバイスに与える。そのようなコンテキスト情報は、広告されている異なるファイルブロードキャストから、受信機デバイス上に常駐するサービスまたはアプリケーションに関係するファイルを受信のために選択するために、受信デバイスによって使用され得る。また、ブロードキャストスケジュールメッセージにおいて与えられるファイルＩＤおよび／または要素ＩＤ情報により、受信機デバイスは、ファイルが、新しいファイルであるのか、前に受信したファイルの更新であるのかを判断することが可能になり得る。ブロードキャストスケジュールメッセージ構成体は、アプリケーションファイル名または属性ストリングのエイリアシングを記述することをサポートする。ブロードキャストスケジュールメッセージ構成体はまた、トランスポートされているファイルのタイプ、たとえば、単一のファイル対ファイルのバンドルを識別することを可能にする。ブロードキャストスケジュールメッセージにおいて利用可能な情報、または場合によってはファイル配信カタログシステムを使用して、受信機デバイスは、受信機回路が、受信機デバイス上に常駐するアプリケーションに有用であるファイルを受信するためにのみアクティブにされるように、受信のために関係があるファイルを受信のために識別する（すなわち、フィルタ処理し、選択する）ことができる。

ファイル取込みシステムは、ファイルを識別し、特徴づけることと、共有され、しばしば乏しいブロードキャストリソース上でファイルがどのくらい適時におよびどのくらい確実に搬送される必要があるかを規定する送信要求を定義することとをファイルコンテンツプロバイダが行うことを可能にすることによって、ブロードキャストネットワーク上でのトランスポートのためのファイルの取込みを可能にする。適時性および受信機バッテリー制約は、ブロードキャストシステムが一度に少量のスケジュール情報のみを広告することを必要とし得る。ファイル取込みシステムのスケジューリング機能は、新しいファイル送信要求を前に取り込まれたファイルのファイル送信要求と比較考量することによって、新しいファイル送信要求に適応し得る。さらに、ファイル取込みシステムは、定期的に更新されたブロードキャストスケジュールメッセージの形態などの、フレッシュなスケジュール情報のフローが、受信機デバイスにとって適時に利用可能になることと、ファイルが、広告されたスケジュールごとに送信されることとを保証するように構成され得る。

制限されたブロードキャストリソース内でファイルの効率的な送信を可能にするために、ブロードキャストネットワーク上でのファイルのトランスポートのためのリソース割振りを概念的にキャプチャするための機構として、ファイル配信がファイル配信パイプに編成され得る。アプリケーションが、本明細書で説明するファイルシステム抽象化を使用するとき、アプリケーションファイルをパイプにバインドするように複数パイプ構成およびプロビジョニングを調整するために、異なるストラテジが実装され得る。スケジューリングアルゴリズムは、ブロードキャストネットワークの帯域幅および動作条件内でアプリケーション配信要求を満たすために、異なるパイプ構成を利用し得る。

様々な実施形態は、ファイルをブロードキャストし、受信し、扱うことに関して、いくつかの利点および有用な特徴を与える。これらは、ブロードキャスト配信システム上でファイルを配信するときにファイルシステム抽象化を使用してファイルを命名するための機構、ブロードキャスト配信システム上での取込みおよびトランスポートのためのファイルをサブミットするときにそれらのファイルを識別する手段としてファイル名をシグナリングするための機構、ファイルシステム抽象化を介して利用可能なファイルを記述するブロードキャスト配信システムからのファイルのダウンロードを要求するための機構、ならびにアプリケーションに関連付けられたディレクトリおよびサブディレクトリに基づいてファイルをファイル配信アプリケーションにバインドするための機構を含む。

ファイル配信フレームワーク（ＦＤＦ）は、バックグラウンドでファイルをデバイスに配信するためのフレキシブルな機構を与える。ＦＤＦは、フレキシブルなファイルブロードキャストスケジュール、すなわち、ファイルブロードキャストウィンドウが、動的にスケジュールされ、デバイスにシグナリングされ得ることと、多数のアプリケーションでスケーラブル、すなわち、ＦＤＦが、システムにおけるデータフローの数を著しく低減するために複数のアプリケーションからのデータを同じフローに多重化することができることと、電力効率、すなわち、デバイスが、ユーザが関係しているデータを選択的に受信する際にのみエネルギーを消費することと、という主要な設計目的を有する。

ブロードキャストスケジュールメッセージは、ファイル名、属性、およびアプリケーション／サービス識別子を介してファイルをサービスまたはアプリケーションに関連付ける、ブロードキャストネットワーク上でのファイルの送信についてのスケジュールを広告する機構を与える。ブロードキャストスケジュールメッセージはまた、受信機デバイスがファイルの単一のまたはすべての更新されたバージョンをキャプチャするように構成され得るように、ブロードキャストされているファイルが新しいファイルであるのか、更新されたファイルであるのか、または反復ファイルであるのかを識別し得る。ブロードキャストスケジュールメッセージは、ブロードキャストウィンドウと、ファイルがいつブロードキャストされ得るかについての可能な複数のインスタンスの識別とに加えて、ファイルが受信され得るトランスポートストリームをシグナリングし得る。ブロードキャストスケジュールメッセージはまた、ブロードキャストスケジュールメッセージが新しいスケジュール情報でいつ更新されることになるかを識別し得る。ブロードキャストスケジュールメッセージはまた、トランスポートされているファイルについてのアプリケーション／サービスＩＤおよびエイリアシング情報を記述し得る。ブロードキャストスケジュールメッセージは、コンテンツフレッシュネスと、受信機デバイスに対するバッテリーの影響とのバランスをとるために、一度にファイルブロードキャストスケジュール情報の不変の部分のみを広告し得る。

また、様々な実施形態は、受信機デバイスが、ブロードキャストネットワークトランスポート技術と、使用される周波数と、所与の周波数におけるトランスポートの部分と、ブロードキャスト技術を介して送信されるファイルについての配信スケジュール情報を与える、ブロードキャストネットワークトランスポート技術および上記周波数におけるトランスポートストリームとを発見することを可能にする機構を与える。受信機デバイスは、ファイルが関連付けられたサービスまたはアプリケーションに基づいて、およびファイルが新しいのか、前に受信したファイルの更新であるのかに基づいて、受信のためのファイルを選択するために、ブロードキャストスケジュールメッセージにおいて与えられる広告されたスケジュールを利用し得る。

様々な実施形態は、異なる配信要求、異なる受信機制約に対処するか、またはトラフィック分離を行うために、異なる配信および異なる地理的カバレージ要求のファイルの多重化されたトランスポートのためにブロードキャスト送信リソースを専用化することと、異なるファイル配信パイプ上でのファイルトランスポートのために利用可能なリソースの区分とを含み得る。異なる配信要求、異なる受信機制約を満たすか、またはトラフィック分離を行うために、ファイルの異なるクラスがファイル配信パイプのセットにバインドされ得る。異なるファイルを搬送するトランスポートストリームは、ファイルトランスポートのための専用リソースが限界まで利用されるように、多重化され得る。トランスポートストリームは、さらに、異なる不連続送信上でのファイルのトランスポートが、より小さいファイルのインターリービングを可能にすることを可能にするように構成され得る。異なる配信要求、異なる受信機制約を満たすか、またはトラフィック分離を行うために、ファイルのクラスがリソースのセットにバインドされ得る。ファイル配信要求と、利用可能なファイル配信パイプと、ファイルのクラスをリソースのセットにバインドすることとに基づいて、ファイルはファイル配信パイプに割り振られ得る。送信側のアプリケーションおよびサービスは、オーバーヘッドファイルと、アプリケーションがアプリケーション固有属性とともにブロードキャストまたは他の（たとえば、ユニキャスト）トランスポートのために利用可能にしているすべてのファイルを記載する、カタログファイルとを構築するために、ブロードキャストシステムのファイル配信サービスを使用し得る。

ファイル取込みシステムは、ファイルコンテンツプロバイダから、他のアプリケーション固有ファイルとともにカタログファイルを受信し、トランスポートし得、受信機デバイスは、そのようなカタログファイル中の情報に基づいて、ファイルが受信だったことを選択するように構成され得る。受信機デバイス上に常駐するアプリケーションは、カタログに記載されている、各ファイルを特徴づける利用可能な属性上に適用されるアプリケーション固有論理に基づいて、関係があるファイルを判断するために、更新されたカタログファイルを使用し得る。

図８８は、実施形態のいずれかで使用するのに好適な受信機デバイスのシステムブロック図である。典型的な受信機デバイス８８００は、内部メモリ８８０２とディスプレイ８８０３とスピーカー８８５４とに結合されたプロセッサ８８０１を含み得る。さらに、受信機デバイス８８００は、プロセッサ８８０１に結合されたワイヤレスデータリンクおよび／またはセルラー電話トランシーバ８８０５に接続され得る、電磁放射を送信および受信するためのアンテナ８８０４と、プロセッサ８８０１に結合されたモバイルマルチメディアブロードキャスト受信機８８０６とを有し得る。受信機デバイス８８００は、一般に、ユーザ入力を受信するためのメニュー選択ボタンまたはロッカースイッチ８８０８をも含む。

双方向性イベントシグナリングメッセージを受信し、処理するための様々な実施方法は、マルチメディアブロードキャスト受信機８８２４と、プロセッサ８８０１およびメモリ８８０２の部分とによって実行され得る。代替的に、マルチメディアブロードキャスト受信機８８２４内のまたはそれに結合された専用モジュールが実施方法を実行し得る。

上記で説明したブロードキャスト側の様々な実施形態は、図８９に示すサーバ８９００など、様々な市販のサーバデバイスのいずれにも実装され得る。そのようなサーバ８９００は、一般に、揮発性メモリ８９０２と、ディスクドライブ８９０３などの大容量不揮発性メモリとに結合されたプロセッサ８９０１を含む。サーバ８９００は、プロセッサ８９０１に結合されたフロッピー（登録商標）ディスクドライブ、コンパクトディスク（ＣＤ）またはＤＶＤディスクドライブ８９０６をも含み得る。サーバ８９００はまた、他のブロードキャストシステムコンピュータとサーバとに結合されたローカルエリアネットワークなど、ネットワーク８９０５とのデータ接続を確立するための、プロセッサ８９０１に結合されたネットワークアクセスポート８９０４を含み得る。

プロセッサ８８０１、８９０１は、以下で説明する様々な実施形態の機能を含む、様々な機能を実行するようにソフトウェア命令（アプリケーション）によって構成され得る任意のプログラマブルマイクロプロセッサ、マイクロコンピュータあるいは１つまたは複数の多重プロセッサチップであり得る。モバイル受信機デバイスによっては、１つのプロセッサをワイヤレス通信機能専用とし、１つのプロセッサを他のアプリケーションの実行専用とするなど、複数のプロセッサ８９０１を設け得る。一般に、ソフトウェアアプリケーションは、アクセスされ、プロセッサ８８０１、８９０１にロードされる前に内部メモリ８８０２、８９０２、８９０３に記憶され得る。プロセッサ８８０１、８９０１は、アプリケーションソフトウェア命令を記憶するのに十分な内部メモリを含み得る。

上記の方法の説明およびプロセスフロー図は、単に説明のための例として提供したものであり、様々な実施形態のステップが提示された順序で実行されなければならないことを要求または暗示するものではない。当業者なら諒解するように、上記の実施形態におけるステップの順序は、どんな順序でも実行され得る。「その後」、「次いで」、「次に」などの単語は、ステップの順序を限定するものではなく、これらの単語は、単に、読者に方法の説明を案内するために使用される。さらに、たとえば、冠詞「ａ」、「ａｎ」または「ｔｈｅ」を使用する単数形の請求項要素への言及は、その要素を単数形に限定するものと解釈すべきではない。

本明細書で開示する実施形態に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得る。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップについて、上記では概してそれらの機能に関して説明した。そのような機能をハードウェアとして実装するか、ソフトウェアとして実装するかは、特定の適用例および全体的なシステムに課せられた設計制約に依存する。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装し得るが、そのような実装の決定は、本発明の範囲からの逸脱を生じるものと解釈すべきではない。

本明細書で開示する態様に関して説明した様々な例示的な論理、論理ブロック、モジュール、および回路を実装するために使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブル論理デバイス、個別ゲートまたはトランジスタ論理、個別ハードウェア構成要素、あるいは本明細書で説明した機能を実行するように設計されたそれらの任意の組合せを用いて実装または実行され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、ＤＳＰとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。代替的に、いくつかのステップまたは方法は、所与の機能に固有の回路によって実行され得る。

１つまたは複数の例示的な態様では、説明する機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され得る。本明細書で開示する方法またはアルゴリズムのステップは、有形の非一時的コンピュータ可読記憶媒体上に常駐し得る、プロセッサ実行可能ソフトウェアモジュールで実施され得る。有形の非一時的コンピュータ可読記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく、例として、そのような非一時的コンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは命令またはデータ構造の形態で所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備え得る。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（ＣＤ：compact disc）、レーザディスク、光ディスク、デジタル多用途ディスク（disc）（ＤＶＤ：digital versatile disc）、フロッピー（登録商標）ディスク（disk）、およびブルーレイディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザで光学的に再生する。上記の組合せも非一時的コンピュータ可読媒体の範囲内に含めるべきである。さらに、方法またはアルゴリズムの動作は、コンピュータプログラム製品に組み込まれ得る、有形の非一時的機械可読媒体および／またはコンピュータ可読媒体上のコードおよび／または命令の１つまたは任意の組合せまたはセットとして常駐し得る。

開示する実施形態の上記の説明は、当業者が本発明を製作または使用できるように提供したものである。これらの実施形態への様々な修正は当業者には容易に明らかとなり、本明細書で定義した一般原理は、本発明の趣旨または範囲から逸脱することなく他の実施形態に適用され得る。したがって、本発明は、本明細書で示した実施形態に限定されるものではなく、以下の特許請求の範囲ならびに本明細書で開示する原理および新規の特徴に合致する最も広い範囲を与えられるべきである。
以下に本件出願当初の特許請求の範囲に記載された発明を付記する。
［１］ブロードキャスト通信ネットワーク上で受信機デバイスにファイルを配信するための方法であって、
コンテンツプロバイダからトランスポートのためのファイルを受信することであって、前記受信したファイルが、ファイル名を有し、ファイルコンテンツと通信要件とに関する情報を含んでいる、受信することと、
ブロードキャスト送信内でファイルデータフローを介して送信のために前記受信したファイルをスケジュールすることと、
ブロードキャストスケジューリング期間内でファイルがいつブロードキャストされることになるかと、それらのファイルに関する情報と、各ファイルについてのスケジュールされたブロードキャスト時間ウィンドウとを示すブロードキャストスケジューリングメッセージを生成することと、
前記ブロードキャストネットワークを介して前記生成されたブロードキャストスケジューリングメッセージをブロードキャストすることと、
前記ブロードキャストスケジューリングメッセージ内に含まれる前記スケジュールされたブロードキャスト時間ウィンドウに従って前記ブロードキャストネットワークの前記ファイルデータフローを介して前記受信したファイルをブロードキャストすることと
を備える、方法。
［２］前記受信したファイルが、相対的な緊急度に基づいてブロードキャストのためにスケジュールされる、［１］に記載の方法。
［３］前記受信したファイルが、１つまたは複数のファイル配信パイプに編成された送信リソース上でブロードキャストされる、［１］に記載の方法。
［４］受信機デバイス内で動作しているアプリケーションから、ファイルをキャプチャしたいという要求を受信することであって、前記要求が１つまたは複数の受信基準を指定する、受信することと、
前記受信機デバイスにおいて前記ブロードキャストスケジューリングメッセージを受信することと、
前記受信基準にマッチするファイルについて前記受信機デバイスにおいて前記ブロードキャストスケジューリングメッセージを監視することと、
前記ブロードキャストスケジューリングメッセージから、前記受信基準にマッチするファイルがブロードキャストされることになる前記スケジュールされたブロードキャスト時間ウィンドウを識別することと、
前記マッチするファイルについての前記識別されたスケジュールされたブロードキャスト時間ウィンドウにおいて前記受信機デバイスの受信機回路をアクティブにすることと、
前記受信したブロードキャストスケジューリングメッセージ中のファイル情報に基づいて受信のためのファイルを選択することと、
前記受信機デバイスにおいて前記ブロードキャスト送信から前記選択されたファイルを受信することと、
前記受信機デバイス内で動作している前記要求アプリケーションに前記選択されたファイルを渡すことと
をさらに備える、［１］に記載の方法。
［５］前記受信機デバイスにおいて前記ブロードキャスト送信から前記選択されたファイルを受信することは、前記受信機デバイス中のメモリにバージョン識別情報を記憶することをさらに含み、前記バージョン識別情報が前記受信したファイルのバージョンを識別し、前記方法は、
前記受信したファイルのより新しいまたは更新されたバージョンがブロードキャストされていることを示すバージョン識別情報を有するファイルについて前記受信機デバイスにおいて前記ブロードキャストスケジューリングメッセージを監視することと、
前記ファイルの新しいまたは更新されたバージョンがブロードキャストされていることを前記ブロードキャストスケジューリングメッセージが示すとき、前記受信機デバイスにおいて前記ブロードキャストネットワークから前記要求されたファイルの更新されたバージョンを受信することと
をさらに備える、［４］に記載の方法。
［６］受信機デバイス内で動作しているアプリケーションから、ファイルをキャプチャしたいという要求を受信することが、前記要求されたファイルを含んでいるファイルを１回キャプチャするためのコマンドの形態で、または前記ファイルのすべてのインスタンスをキャプチャするためのコマンドとして、前記受信機デバイスによる前記キャプチャ要求を受信することをさらに含む、［４］に記載の方法。
［７］前記生成されたブロードキャストスケジューリングメッセージは、前記ブロードキャストスケジューリングメッセージが更新されることになる時間をさらに識別し、前記方法は、
前記ブロードキャストスケジューリング期間内に前記ブロードキャストスケジューリングメッセージを複数回ブロードキャストすることと、
前記ブロードキャストスケジューリングメッセージが受信された後に前記受信機デバイス中の受信機回路を非アクティブにすることと、
現在時間が、前記ブロードキャストスケジューリングメッセージが更新されることになる前記時間に等しいときを判断することと、
前記現在時間が、前記ブロードキャストスケジューリングメッセージが更新されることになる前記時間に等しいとき、前記受信機デバイス中の前記受信機回路を再度アクティブにすることと、
更新されたブロードキャストスケジューリングメッセージを受信することと
をさらに備える、［４］に記載の方法。
［８］前記受信機デバイス内で動作している前記要求アプリケーションに前記選択されたファイルを渡すことが、前記受信機デバイスに前記ファイルを配信するために使用される前記配信方法に前記受信機デバイス内で動作している前記アプリケーションを公開しないような形で、前記受信機デバイス内で動作している前記アプリケーションに前記ファイルを渡すことを含む、［４］に記載の方法。
［９］受信機デバイス内で動作しているアプリケーションから、ファイルをキャプチャしたいという要求を受信することが、ファイルディレクトリを指定するファイルをキャプチャしたいという要求を受信することを備え、
前記受信したブロードキャストスケジューリングメッセージ中のファイル情報に基づいて受信のためのファイルを選択することが、前記識別されたファイルディレクトリにマッチするファイル識別子に基づいて受信のためのファイルを選択することを備える、
［４］に記載の方法。
［１０］前記生成されたブロードキャストスケジューリングメッセージをブロードキャストすることが、所与の周波数上でブロードキャストされるファイルについての配信スケジュール情報を与えるオーバーヘッドトランスポートストリームの一部として前記ブロードキャストスケジューリングメッセージをブロードキャストすることを含む、［１］に記載の方法。
［１１］前記生成されたブロードキャストスケジューリングメッセージをブロードキャストすることが、所与の周波数上でブロードキャストされるファイルについての配信スケジュール情報を与えるオーバーヘッドトランスポートストリームの一部として前記ブロードキャストスケジューリングメッセージをブロードキャストすることを含み、前記配信スケジュール情報が、前記ブロードキャストスケジューリングメッセージによって広告される配信スケジュールを設定する、［１］に記載の方法。
［１２］前記ブロードキャストスケジューリングメッセージが、ブロードキャストスケジュール期間にわたってすべての正常にスケジュールされたファイルを広告する、［１１］に記載の方法。
［１３］前記ブロードキャストスケジューリングメッセージが、ブロードキャストスケジュール期間にわたって前記正常にスケジュールされたファイルの一部分のみを広告する、［１１］に記載の方法。
［１４］送信のためにすでに受け入れられたが、前記ブロードキャストスケジューリングメッセージによって配信スケジュールがまだ広告されていない前記ファイルを判断することと、
送信のためにすでに受け入れられたが、前記ブロードキャストスケジューリングメッセージによって配信スケジュールがまだ広告されていない前記ファイルの前記配信スケジュール情報を修正することと
をさらに備える、［１３］に記載の方法。
［１５］前記コンテンツプロバイダが、前記受信したファイルの各々についてのブロードキャストトランスポート要件を指定する、［３］に記載の方法。
［１６］ファイル取込みシステムを介して前記受信したファイルを取り込むことと、
前記ファイル取込みシステムから、前記取り込まれたファイルの前記ブロードキャストネットワークと、前記取り込まれたファイルの前記ブロードキャストトランスポート要件とを通知する通知を送ることと、
前記ファイル取込みシステムにおいて、１つまたは複数のブロードキャスト送信ストリーム上で前記取り込まれたファイルの送信時間をスケジュールすることと
をさらに備える、［１５］に記載の方法。
［１７］２つ以上の取り込まれたファイルを、ブロードキャスト送信ストリーム上でのトランスポートに好適である１つまたは複数のトランスポートファイルにアセンブルすること
をさらに備える、［１６］に記載の方法。
［１８］前記コンテンツプロバイダによって指定された前記ブロードキャストトランスポート要件の各々が、適時性要件とロバストネス要件とを備える、［１６］に記載の方法。
［１９］前記適時性要件が、前記取り込まれたファイルについてのレイテンシ許容差を備える、［１８］に記載の方法。
［２０］前記ロバストネス要件が、前記取り込まれたファイルに必要な前方誤り訂正のレベルを備える、［１８］に記載の方法。
［２１］前記ブロードキャストスケジューリングメッセージが、前記受信したファイルの配信スケジュールを広告し、前記方法は、
前記ブロードキャスト送信ストリーム上での送信のためにすでにスケジュールされたが、前記ブロードキャストスケジューリングメッセージによってまだ広告されていないファイルを識別することと、
前記識別されたファイルとともに、新たに取り込まれたファイルを前記ブロードキャスト送信ストリームにパックするために、前記コンテンツプロバイダによって指定された前記トランスポート要件を使用することと
をさらに備える、［１６］に記載の方法。
［２２］前記ファイル配信パイプを使用していくつかの異なるファイルを前記ブロードキャスト送信ストリームの各々の上に多重化することをさらに備える、［１６］に記載の方法。
［２３］前記コンテンツプロバイダによって指定されたアプリケーション固有配信要件に対処するような形で前記ファイル配信パイプ上で前記取り込まれたファイルをスケジュールすることをさらに備え、前記アプリケーション固有配信要件が、前記受信機デバイス上で実行しているアプリケーションによって前記コンテンツプロバイダに発行される、［２２］に記載の方法。
［２４］送信側アプリケーションをクラスに編成することと、
アプリケーションの前記クラスを特定のファイル配信パイプにマッピングすることと
をさらに備える、［２２］に記載の方法。
［２５］各受信したファイルを一意に識別し、バージョニングサポートを与える、トランスポートファイルＩＤに前記ファイルを関連付けることと、
前記トランスポートファイルＩＤに基づいて前記受信したファイルのシーケンスを搬送するように各ファイル配信パイプをスケジュールすることと
をさらに備える、［３］に記載の方法。
［２６］各ファイルが、専用ファイル配信パイプ上でブロードキャストウィンドウ内にブロードキャストされるようにスケジュールされ、各ブロードキャストウィンドウがあるサイズを有する、［３］に記載の方法。
［２７］各ファイル配信パイプの前記ブロードキャストウィンドウの前記サイズが、前記ファイル配信パイプのデータレートと、前記ファイル配信パイプ上で送信されている前記ファイルのサイズとに応じて計算される、［２６］に記載の方法。
［２８］各ファイル配信パイプの前記ブロードキャストウィンドウの前記サイズが、前記ファイル配信パイプのデータレートによって除算された、前記ファイル配信パイプ上で送信されている前記ファイルのサイズに比例する、［２６］に記載の方法。
［２９］ブロードキャストスケジューリングメッセージを生成することが、前記ブロードキャストスケジュール期間内にブロードキャストされることになる一連のファイルを記述するように前記ブロードキャストスケジュールメッセージを生成することを備え、各ブロードキャストスケジュール期間が、前記ブロードキャストスケジュールメッセージ中に含まれる広告されたファイルブロードキャストスケジュールの数を表す量を定義する、［１］に記載の方法。
［３０］少なくとも１つの受信したファイルが、単一のブロードキャストスケジュール期間における２つ以上のブロードキャスト時間ウィンドウ内にブロードキャストされるようにスケジュールされる、［１］に記載の方法。
［３１］ブロードキャストスケジューリングメッセージを生成することが、単一のブロードキャストスケジュール期間内にブロードキャストされるべき複数のファイルについての受信情報を含むように前記ブロードキャストスケジュールメッセージを生成することを備え、
前記ブロードキャストネットワークを介して前記生成されたブロードキャストスケジューリングメッセージをブロードキャストすることが、同じブロードキャスト時間ウィンドウにおいて前記ブロードキャストスケジュールメッセージを繰り返し送信することを備える、［１］に記載の方法。
［３２］前記ブロードキャストスケジュールメッセージが各ブロードキャストスーパーフレームにおいて再ブロードキャストされる、［１２］に記載の方法。
［３３］前記ファイルデータフロー上で送信されている単一のファイルに関連付けられたブロードキャストスケジュール期間中に複数のブロードキャストウィンドウが存在する、［３２］に記載の方法。
［３４］前記単一のファイルが、独立部分に分割され、他のファイルでインターリーブされ、前記ファイルデータフロー上で他のファイルとともに送信される、［３３］に記載の方法。
［３５］ブロードキャストスケジューリングメッセージを生成することは、前記受信機デバイスが、更新されたブロードキャストスケジュールメッセージについてブロードキャストスケジュールフローを監視すべきである、次の時間を指定する次のモニタ時間データフィールドを有するブロードキャストスケジュール監視記録を備えるように前記ブロードキャストスケジューリングメッセージを生成することを備える、［１］に記載の方法。
［３６］ブロードキャストスケジューリングメッセージを生成することが、前記ファイルデータフロー上でブロードキャストされた前記ファイルについての前記ブロードキャストスケジュールを記述するフローブロードキャストスケジュール記録を備えるように前記ブロードキャストスケジュールメッセージを生成することを備える、［１］に記載の方法。
［３７］ブロードキャストスケジューリングメッセージを生成することが、前記ファイルデータフロー上でブロードキャストされた前記ファイルに関連付けられたファイルコンテンツを識別する複数のファイルを識別するプレフィックスマッチングストリングを備えるように前記ブロードキャストスケジュールメッセージを生成することを備える、［１］に記載の方法。
［３８］ブロードキャストスケジューリングメッセージを生成することが、前記ファイルデータフロー上でブロードキャストされた前記ファイルに関連付けられたファイルコンテンツを識別する複数のディレクトリ名を識別するプレフィックスマッチングストリングを備えるように前記ブロードキャストスケジュールメッセージを生成することを備える、［１］に記載の方法。
［３９］前記ブロードキャストスケジュール記録が、ファイル名に関連付けられたファイルコンテンツを識別する厳密に１つのプレフィックスマッチングストリングを備える、［３７］に記載の方法。
［４０］前記受信機デバイスが、前記プレフィックスマッチングストリング中の値を用いて２ウェイプレフィックスマッチングを実行するように構成された、［３７］に記載の方法。
［４１］前記ブロードキャストスケジュール記録が、ファイル名に関連付けられたファイルコンテンツを識別する厳密に１つのプレフィックスマッチングストリングを備える、［３８］に記載の方法。
［４２］前記受信機デバイスが、前記プレフィックスマッチングストリング中の前記値を用いて２ウェイプレフィックスマッチングを実行するように構成された、［３８］に記載の方法。
［４３］ブロードキャストスケジューリングメッセージを生成することが、前記ファイルコンテンツを特徴づける複数の属性を与える属性ストリングを備えるように前記ブロードキャストスケジュールメッセージを生成することを備える、［１］に記載の方法。
［４４］ブロードキャストスケジューリングメッセージを生成することが、ブロードキャストスケジュール情報記録を備えるように前記ブロードキャストスケジュールメッセージを生成することを備える、［１］に記載の方法。
［４５］ブロードキャストスケジュール情報記録を備えるように前記ブロードキャストスケジュールメッセージを生成することが、ヘッダ部分とボディ部分とを備えるように前記ブロードキャストスケジュールメッセージの前記ブロードキャストスケジュール情報記録を生成することを備える、［４４］に記載の方法。
［４６］前記ブロードキャストスケジュール情報記録を生成することが、次のモニタ時間データフィールドと監視期間データフィールドとを備えるように前記ブロードキャストスケジュール情報記録の前記ヘッダ部分を生成することを備える、［４５］に記載の方法。
［４７］前記ブロードキャストスケジュール情報記録の前記ヘッダ部分から前記次のモニタ時間データフィールドと前記監視期間データフィールドとを抽出することと、
異なるレイテンシにおいてデータを配信するために前記抽出された次のモニタ時間データフィールドと前記抽出された監視期間データフィールドとを使用することと
をさらに備える、［４６］に記載の方法。
［４８］前記ブロードキャストスケジュール情報記録を生成することは、
前記システムが初期収集フロー（ＩＡＦ）システムをサポートするかどうかを判断することと、
監視期間データフィールドを備えるように、および前記システムが初期収集フロー（ＩＡＦ）システムをサポートしないと判断された場合、次のモニタ時間フィールドを含むように、前記ブロードキャストスケジュール情報記録の前記ヘッダ部分を生成することと
を備える、［４５］に記載の方法。
［４９］前記ブロードキャストスケジュール情報の前記ヘッダ部分を生成することが、前記ファイルデータフローに関する情報を含んでいる情報フィールドを備えるように前記ヘッダ部分を生成することを備える、［４６］に記載の方法。
［５０］情報フィールドを備えるように前記ヘッダ部分を生成することが、フローＩＤデータフィールドとデータレートデータフィールドとを備えるように前記情報フィールドを生成することを備える、［４９］に記載の方法。
［５１］前記次のモニタ時間データフィールドは、前記受信機デバイスが、更新されたブロードキャストスケジュールメッセージについて前記ブロードキャストスケジュールフローを監視すべきである、前記次の時間を指定する、［４６］に記載の方法。
［５２］前記ブロードキャストスケジュールメッセージについての新しいバージョンをシグナリングするために初期収集フロー（ＩＡＦ）システムを使用すること
をさらに備える、［１］に記載の方法。
［５３］前記受信機デバイスにおいて初期収集フロー（ＩＡＦ）から最新のディレクトリ情報メッセージを受信することと、前記最新のディレクトリ情報メッセージから抽出された受信したブロードキャストスケジュールメッセージのバージョン情報を未経過の処理されたブロードキャストスケジュールメッセージのバージョン情報と比較する比較演算を実行することとをさらに備える、［１］に記載の方法。
［５４］前記比較演算の結果が、前記バージョンが異なることを示す場合、前記更新されたブロードキャストスケジュールメッセージを受信するために前記受信機デバイス中の受信機回路をアクティブにすることをさらに備える、［５３］に記載の方法。
［５５］前記受信機デバイスにおいて前記ブロードキャストスケジュールメッセージを受信することと、前記受信したブロードキャストスケジュールメッセージ中のバージョンパラメータをディレクトリ情報メッセージユニット中のバージョンパラメータと比較することと、前記比較されたバージョンが異なる場合、前記受信したブロードキャストスケジュールメッセージを無視することとをさらに備える、［１］に記載の方法。
［５６］前記ブロードキャストネットワークが、前記ブロードキャストスケジュール期間の開始時間より可変秒数前になるように次の監視フィールドデバイスプロビジョンパラメータを設定し、前記方法が、前記受信機デバイスにおいてブロードキャストスケジュールメッセージ更新を検出することと、前記ブロードキャストスケジュール期間の前記開始の前に、更新されたブロードキャストスケジュールメッセージを受信することとをさらに備える、［１２］に記載の方法。

Claims (51)

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. ブロードキャストスケジューリングメッセージを生成することが、前記ブロードキャストスケジューリング期間内にブロードキャストされることになる一連のファイルを記述するように前記ブロードキャストスケジュールメッセージを生成することを備え、各ブロードキャストスケジュール期間が、前記ブロードキャストスケジュールメッセージ中に含まれる広告されたファイルブロードキャストスケジュールの数を表す量を定義する、請求項１に記載の方法。
26. 少なくとも１つの受信したファイルが、単一のブロードキャストスケジュール期間における２つ以上のブロードキャスト時間ウィンドウ内にブロードキャストされるようにスケジュールされる、請求項１に記載の方法。
27. ブロードキャストスケジューリングメッセージを生成することが、単一のブロードキャストスケジュール期間内にブロードキャストされるべき複数のファイルについての受信情報を含むように前記ブロードキャストスケジュールメッセージを生成することを備え、
    前記ブロードキャストネットワークを介して前記生成されたブロードキャストスケジューリングメッセージをブロードキャストすることが、同じブロードキャスト時間ウィンドウにおいて前記ブロードキャストスケジュールメッセージを繰り返し送信することを備える、
    請求項１に記載の方法。
28. 前記ブロードキャストスケジュールメッセージが各ブロードキャストスーパーフレームにおいて再ブロードキャストされる、請求項１０に記載の方法。
29. 前記ファイルデータフロー上で送信されている単一のファイルに関連付けられたブロードキャストスケジュール期間中に複数のブロードキャストウィンドウが存在する、請求項２８に記載の方法。
30. 前記単一のファイルが、独立部分に分割され、他のファイルでインターリーブされ、前記ファイルデータフロー上で他のファイルとともに送信される、請求項２９に記載の方法。
31. ブロードキャストスケジューリングメッセージを生成することが、前記ファイルデータフロー上でブロードキャストされた前記ファイルについての前記ブロードキャストスケジュールを記述するフローブロードキャストスケジュール記録を備えるように前記ブロードキャストスケジュールメッセージを生成することを備える、請求項１に記載の方法。
32. ブロードキャスト通信ネットワーク上で受信機デバイスにファイルを配信するための方法であって、
    コンテンツプロバイダからトランスポートのためのファイルを受信することであって、前記受信したファイルが、ファイル名を有し、ファイルコンテンツと通信要件とに関する情報を含んでいる、受信することと、
    ブロードキャスト送信内でファイルデータフローを介して送信のために前記受信したファイルをスケジュールすることと、
    ブロードキャストスケジューリング期間内でファイルがブロードキャストされることになる１以上の時間と、それらのファイルに関する情報と、各ファイルについてのスケジュールされたブロードキャスト時間ウィンドウとを示すブロードキャストスケジューリングメッセージを生成することと、
    前記ブロードキャストネットワークを介して前記生成されたブロードキャストスケジューリングメッセージをブロードキャストすることと、
    前記ブロードキャストスケジューリングメッセージ内に含まれる前記スケジュールされたブロードキャスト時間ウィンドウに従って前記ブロードキャストネットワークの前記ファイルデータフローを介して前記受信したファイルをブロードキャストすることと
    を備え、
    前記ブロードキャストスケジューリングメッセージは、前記ファイルデータフロー上でブロードキャストされた前記ファイルに関連付けられたファイルコンテンツを識別する複数のファイルを識別するプレフィックスマッチングストリングを備える、方法。
33. ブロードキャスト通信ネットワーク上で受信機デバイスにファイルを配信するための方法であって、
    コンテンツプロバイダからトランスポートのためのファイルを受信することであって、前記受信したファイルが、ファイル名を有し、ファイルコンテンツと通信要件とに関する情報を含んでいる、受信することと、
    ブロードキャスト送信内でファイルデータフローを介して送信のために前記受信したファイルをスケジュールすることと、
    ブロードキャストスケジューリング期間内でファイルがブロードキャストされることになる１以上の時間と、それらのファイルに関する情報と、各ファイルについてのスケジュールされたブロードキャスト時間ウィンドウとを示すブロードキャストスケジューリングメッセージを生成することと、
    前記ブロードキャストネットワークを介して前記生成されたブロードキャストスケジューリングメッセージをブロードキャストすることと、
    前記ブロードキャストスケジューリングメッセージ内に含まれる前記スケジュールされたブロードキャスト時間ウィンドウに従って前記ブロードキャストネットワークの前記ファイルデータフローを介して前記受信したファイルをブロードキャストすることと
    を備え、
    前記ブロードキャストスケジューリングメッセージは、前記ファイルデータフロー上でブロードキャストされた前記ファイルに関連付けられたファイルコンテンツを識別する複数のディレクトリ名を識別するプレフィックスマッチングストリングを備える、方法。
34. 前記ブロードキャストスケジューリングメッセージが、ファイル名に関連付けられたファイルコンテンツを識別する厳密に１つのプレフィックスマッチングストリングを備える、請求項３２に記載の方法。
35. 前記受信機デバイスが、前記プレフィックスマッチングストリング中の値を用いて２ウェイプレフィックスマッチングを実行するように構成された、請求項３２に記載の方法。
36. 前記ブロードキャストスケジューリングメッセージが、ファイル名に関連付けられたファイルコンテンツを識別する厳密に１つのプレフィックスマッチングストリングを備える、請求項３３に記載の方法。
37. 前記受信機デバイスが、前記プレフィックスマッチングストリング中の前記値を用いて２ウェイプレフィックスマッチングを実行するように構成された、請求項３３に記載の方法。
38. ブロードキャストスケジューリングメッセージを生成することが、前記ファイルコンテンツを特徴づける複数の属性を与える属性ストリングを備えるように前記ブロードキャストスケジュールメッセージを生成することを備える、請求項１に記載の方法。
39. ブロードキャストスケジューリングメッセージを生成することが、ブロードキャストスケジュール情報記録を備えるように前記ブロードキャストスケジュールメッセージを生成することを備える、請求項１に記載の方法。
40. ブロードキャストスケジュール情報記録を備えるように前記ブロードキャストスケジュールメッセージを生成することが、ヘッダ部分とボディ部分とを備えるように前記ブロードキャストスケジュールメッセージの前記ブロードキャストスケジュール情報記録を生成することを備える、請求項３９に記載の方法。
41. ブロードキャスト通信ネットワーク上で受信機デバイスにファイルを配信するための方法であって、
    コンテンツプロバイダからトランスポートのためのファイルを受信することであって、前記受信したファイルが、ファイル名を有し、ファイルコンテンツと通信要件とに関する情報を含んでいる、受信することと、
    ブロードキャスト送信内でファイルデータフローを介して送信のために前記受信したファイルをスケジュールすることと、
    ブロードキャストスケジューリング期間内でファイルがブロードキャストされることになる１以上の時間と、それらのファイルに関する情報と、各ファイルについてのスケジュールされたブロードキャスト時間ウィンドウとを示すブロードキャストスケジューリングメッセージを生成することであって、前記ブロードキャストスケジューリングメッセージは、ヘッダ部分とボディ部分とを有するブロードキャストスケジュール情報記録を備え、前記ブロードキャストスケジュール情報記録の前記ヘッダ部分が、次のモニタ時間データフィールドと監視期間データフィールドとを備える、前記生成することと、
    前記ブロードキャストネットワークを介して前記生成されたブロードキャストスケジューリングメッセージをブロードキャストすることと、
    前記ブロードキャストスケジューリングメッセージ内に含まれる前記スケジュールされたブロードキャスト時間ウィンドウに従って前記ブロードキャストネットワークの前記ファイルデータフローを介して前記受信したファイルをブロードキャストすることと
    を備える、方法。
42. 前記ブロードキャストスケジュール情報記録の前記ヘッダ部分から前記次のモニタ時間データフィールドと前記監視期間データフィールドとを抽出することと、
    異なるレイテンシにおいてデータを配信するために前記抽出された次のモニタ時間データフィールドと前記抽出された監視期間データフィールドとを使用することと
    をさらに備える、請求項４１に記載の方法。
43. ブロードキャスト通信ネットワーク上で受信機デバイスにファイルを配信するための方法であって、
    コンテンツプロバイダからトランスポートのためのファイルを受信することであって、前記受信したファイルが、ファイル名を有し、ファイルコンテンツと通信要件とに関する情報を含んでいる、受信することと、
    ブロードキャスト送信内でファイルデータフローを介して送信のために前記受信したファイルをスケジュールすることと、
    ブロードキャストスケジューリング期間内でファイルがブロードキャストされることになる１以上の時間と、それらのファイルに関する情報と、各ファイルについてのスケジュールされたブロードキャスト時間ウィンドウとを示すブロードキャストスケジューリングメッセージを生成することであって、前記ブロードキャストスケジューリングメッセージは、ヘッダ部分とボディ部分とを有するブロードキャストスケジュール情報記録を備え、前記ヘッダ部分が、監視期間データフィールドを備える、前記生成することと、
    前記ブロードキャストネットワークが初期収集フロー（ＩＡＦ）システムをサポートするかどうかを判断することと、
    前記ブロードキャストネットワークが初期収集フロー（ＩＡＦ）システムをサポートしないと判断された場合、次のモニタ時間フィールドを含むように、前記ブロードキャストスケジュール情報記録の前記ヘッダ部分を生成することと、
    前記ブロードキャストネットワークを介して前記生成されたブロードキャストスケジューリングメッセージをブロードキャストすることと、
    前記ブロードキャストスケジューリングメッセージ内に含まれる前記スケジュールされたブロードキャスト時間ウィンドウに従って前記ブロードキャストネットワークの前記ファイルデータフローを介して前記受信したファイルをブロードキャストすることと
    を備える、方法。
44. 前記ヘッダ部分が、前記ファイルデータフローに関する情報を含んでいる情報フィールドを備える、請求項４１に記載の方法。
45. 前記情報フィールドが、フローＩＤデータフィールドとデータレートデータフィールドとを備える、請求項４４に記載の方法。
46. 前記次のモニタ時間データフィールドは、前記受信機デバイスが、更新されたブロードキャストスケジュールメッセージについて前記ブロードキャストスケジュールフローを監視すべきである、前記次の時間を指定する、請求項４１に記載の方法。
47. 前記ブロードキャストスケジュールメッセージについての新しいバージョンをシグナリングするために初期収集フロー（ＩＡＦ）システムを使用すること
    をさらに備える、請求項１に記載の方法。
48. 前記受信機デバイスにおいて初期収集フロー（ＩＡＦ）から最新のディレクトリ情報メッセージを受信することと、前記最新のディレクトリ情報メッセージから抽出された受信したブロードキャストスケジュールメッセージのバージョン情報を未経過の処理されたブロードキャストスケジュールメッセージのバージョン情報と比較する比較演算を実行することとをさらに備える、請求項１に記載の方法。
49. 前記比較演算の結果が、前記バージョンが異なることを示す場合、前記更新されたブロードキャストスケジュールメッセージを受信するために前記受信機デバイス中の受信機回路をアクティブにすることをさらに備える、請求項４８に記載の方法。
50. 前記受信機デバイスにおいて前記ブロードキャストスケジュールメッセージを受信することと、前記受信したブロードキャストスケジュールメッセージ中のバージョンパラメータをディレクトリ情報メッセージユニット中のバージョンパラメータと比較することと、前記比較されたバージョンが異なる場合、前記受信したブロードキャストスケジュールメッセージを無視することとをさらに備える、請求項１に記載の方法。
51. ブロードキャスト通信ネットワーク上で受信機デバイスにファイルを配信するための方法であって、
    コンテンツプロバイダからトランスポートのためのファイルを受信することであって、前記受信したファイルが、ファイル名を有し、ファイルコンテンツと通信要件とに関する情報を含んでいる、受信することと、
    ブロードキャスト送信内でファイルデータフローを介して送信のために前記受信したファイルをスケジュールすることと、
    ブロードキャストスケジューリング期間内でファイルがブロードキャストされることになる１以上の時間と、それらのファイルに関する情報と、各ファイルについてのスケジュールされたブロードキャスト時間ウィンドウとを示すブロードキャストスケジューリングメッセージを生成することであって、前記ブロードキャストスケジューリングメッセージは、ブロードキャストスケジュール期間にわたってすべての正常にスケジュールされたファイルを広告する、前記生成することと、
    所与の周波数上でブロードキャストされるファイルについての配信スケジュール情報を与えるオーバーヘッドトランスポートストリームの一部として前記ブロードキャストネットワークを介して前記生成されたブロードキャストスケジューリングメッセージをブロードキャストすることであって、前記配信スケジュール情報が、前記ブロードキャストスケジューリングメッセージによって広告される配信スケジュールを設定する、前記ブロードキャストすることと、
    前記ブロードキャストスケジューリングメッセージ内に含まれる前記スケジュールされたブロードキャスト時間ウィンドウに従って前記ブロードキャストネットワークの前記ファイルデータフローを介して前記受信したファイルをブロードキャストすることと
    を備え、
    前記ブロードキャストネットワークが、前記ブロードキャストスケジュール期間の開始時間より可変秒数前になるように次の監視フィールドデバイスプロビジョンパラメータを設定し、前記方法が、前記受信機デバイスにおいてブロードキャストスケジュールメッセージ更新を検出することと、前記ブロードキャストスケジュール期間の前記開始の前に、更新されたブロードキャストスケジュールメッセージを受信することとをさらに備える、方法。

Images