特表 2022-507911 受信パケットストリームのファイルを記憶するためのバッファ管理

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-01-18

(54)【発明の名称】受信パケットストリームのファイルを記憶するためのバッファ管理

(51)【国際特許分類】

   H04N 21/438 20110101AFI20220111BHJP

   H04N 21/433 20110101ALI20220111BHJP

   H04H 20/20 20080101ALI20220111BHJP

   H04H 60/82 20080101ALI20220111BHJP

【ＦＩ】

H04N21/438

H04N21/433

H04H20/20

H04H60/82

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2021528943

(86)(22)【出願日】2019-10-11

(85)【翻訳文提出日】2021-07-15

(86)【国際出願番号】 IB2019058667

(87)【国際公開番号】W WO2020104870

(87)【国際公開日】2020-05-28

(31)【優先権主張番号】16/199,117

(32)【優先日】2018-11-23

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＨＤＭＩ

２．ＪＡＶＡ

３．ＡＮＤＲＯＩＤ

(71)【出願人】

【識別番号】000002185

【氏名又は名称】ソニーグループ株式会社

(74)【代理人】

【識別番号】100092093

【弁理士】

【氏名又は名称】辻居 幸一

(74)【代理人】

【識別番号】100109070

【弁理士】

【氏名又は名称】須田 洋之

(74)【代理人】

【識別番号】100067013

【弁理士】

【氏名又は名称】大塚 文昭

(74)【代理人】

【識別番号】100109335

【弁理士】

【氏名又は名称】上杉 浩

(74)【代理人】

【識別番号】100120525

【弁理士】

【氏名又は名称】近藤 直樹

(74)【代理人】

【識別番号】100158551

【弁理士】

【氏名又は名称】山崎 貴明

(72)【発明者】

【氏名】クリフト グラハム

【テーマコード（参考）】

5C164

【Ｆターム（参考）】

5C164FA11

5C164UB21P

5C164UB36P

5C164UB41S

5C164UC27S

5C164YA21

(57)【要約】

ファイルを記憶するための、予め設定されたバイトサイズを有するバッファを管理する方法が、着信ファイルのファイル識別子及び長さを判定するステップを含む。方法は、着信ファイルが次の書き込み位置とバッファの最後との間のスペースに収まらないと判定するステップを含む。方法は、着信ファイルが収まらないとの判定に応答して、マップ内で、着信ファイルの範囲に少なくとも部分的に重なり合うファイルに対応する各エントリを削除するステップと、着信ファイルのためのエントリをマップ内に追加するステップとを含む。方法は、バッファ内の連続領域を着信ファイルのために割り当てた後に、次の書き込み位置を割り当て連続領域の最後に移動させるステップと、着信ファイルのパケットを受け取り、受け取られたパケットを割り当てられた連続領域に記憶するステップとをさらに含む。
【選択図】 図４

【特許請求の範囲】

【請求項1】

パケットストリームを介して受け取られたファイルを記憶するための、予め設定されたバイトサイズを有するバッファを管理する方法であって、
着信ファイルのファイル識別子及び長さを判定するステップと、
前記着信ファイルが次の書き込み位置と前記バッファの最後との間のスペースに収まらないと判定するステップと、
前記着信ファイルが前記次の書き込み位置と前記バッファの前記最後との間の前記スペースに収まらないとの前記判定に応答して、
前記バッファに記憶された１又は２以上のファイルを識別するマップにおいて、前記バッファの初期書き込み位置から開始する領域に少なくとも部分的に記憶されたファイルに対応し、かつ前記着信ファイルの前記長さに等しいサイズを有する各エントリを削除するステップと、
前記着信ファイルの前記ファイル識別子及び前記長さを含むエントリを、前記バッファ内の前記初期書き込み位置に関連付けて前記マップ内に追加するステップと、
前記バッファ内の前記初期書き込み位置から開始して前記着信ファイルの前記長さに等しい前記サイズを有する前記バッファ内の連続領域を割り当てた後に、前記次の書き込み位置を前記割り当てられた連続領域の前記最後に移動させるステップと、
前記着信ファイルのパケットを受け取り、該受け取られたパケットを前記割り当てられた連続領域に記憶するステップと、
を含むことを特徴とする方法。

【請求項2】

前記パケットストリームは、高度テレビジョンシステムズ委員会（ＡＴＳＣ）３．０デジタルテレビ信号の一部である、
請求項１に記載の方法。

【請求項3】

前記着信ファイルは、前記バッファに記憶された他のファイルと共通するトランスポートセッション識別子（ＴＳＩ）値を有する階層符号化トランスポート（ＬＣＴ）チャネルで受け取られ、
対応する異なるＴＳＩ値を有するファイルを記憶するために、新規バッファ及び別のマップが初期化される、
請求項２に記載の方法。

【請求項4】

前記マップ内の前記追加されたエントリは、前記着信ファイルの前記ファイル識別子及び前記長さを含む、
請求項１に記載の方法。

【請求項5】

前記着信ファイルの前記受け取られたパケットが、前記ファイルに割り当てられた前記バッファ内の前記連続領域を満たすまで、前記マップ内の前記追加されたエントリに不完全とのラベルを付けるステップをさらに含む、
請求項４に記載の方法。

【請求項6】

前記パケットストリームの各着信パケットについて、
対応するファイルのファイル識別子を判定するステップと、
前記対応するファイルの前記ファイル識別子を有し、かつ不完全とのラベルが付いた前記マップ内のエントリが存在するかどうかを判定するステップと、
前記対応するファイルの前記ファイル識別子を有する前記マップ内の不完全なエントリが存在するとの判定に応答して、
前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域に前記着信パケットを記憶するステップと、
前記着信パケットが、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域において前記ファイルを完成させるかどうかを判定するステップと、
前記着信パケットが、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域において前記ファイルを完成させるとの判定に応答して、
前記マップ内の前記エントリに関連する前記不完全ラベルを削除するステップと、
前記マップ内の前記エントリと同じファイル名を有する前記マップ内の他の全てのエントリを削除するステップと、
前記対応するファイルの前記ファイル識別子を有する前記マップ内の不完全なエントリが存在しないとの判定に応答して、前記着信パケットを新規着信ファイルとして処理するステップと、
をさらに含む、請求項５に記載の方法。

【請求項7】

前記ファイル識別子は、トランスポートオブジェクト識別子（ＴＯＩ）及びファイル名を含む、
請求項６に記載の方法。

【請求項8】

パケットストリームを介して受け取られたファイルを、予め設定されたバイトサイズを有するバッファに記憶するバッファ管理装置であって、
着信ファイルのファイル識別子及び長さを判定し、
前記着信ファイルが次の書き込み位置と前記バッファの最後との間のスペースに収まらないと判定し、
前記着信ファイルが前記次の書き込み位置と前記バッファの前記最後との間の前記スペースに収まらないとの前記判定に応答して、
前記バッファに記憶された１又は２以上のファイルを識別するマップにおいて、前記バッファの初期書き込み位置から開始する領域に少なくとも部分的に記憶されたファイルに対応し、かつ前記着信ファイルの前記長さに等しいサイズを有する各エントリを削除し、
前記着信ファイルの前記ファイル識別子及び前記長さを含むエントリを、前記バッファ内の前記初期書き込み位置に関連付けて前記マップ内に追加し、
前記バッファ内の前記初期書き込み位置から開始して前記着信ファイルの前記長さに等しい前記サイズを有する前記バッファ内の連続領域を割り当てた後に、前記次の書き込み位置を前記割り当てられた連続領域の前記最後に移動させ、
前記着信ファイルのパケットを受け取り、該受け取られたパケットを前記割り当てられた連続領域に記憶する、
ように構成された回路を備える、
ことを特徴とするバッファ管理装置。

【請求項9】

前記パケットストリームは、高度テレビジョンシステムズ委員会（ＡＴＳＣ）３．０デジタルテレビ信号の一部である、
請求項８に記載のバッファ管理装置。

【請求項10】

前記着信ファイルは、前記バッファに記憶された他のファイルと共通するトランスポートセッション識別子（ＴＳＩ）値を有する階層符号化トランスポート（ＬＣＴ）チャネルで受け取られ、
対応する異なるＴＳＩ値を有するファイルを記憶するために、新規バッファ及び別のマップが初期化される、
請求項９に記載のバッファ管理装置。

【請求項11】

前記マップ内の前記追加されたエントリは、前記着信ファイルの前記ファイル識別子及び前記長さを含む、
請求項８に記載のバッファ管理装置。

【請求項12】

前記回路は、前記着信ファイルの前記受け取られたパケットが、前記着信ファイルに割り当てられた前記バッファ内の前記連続領域を満たすまで、前記マップ内の前記追加されたエントリに不完全とのラベルを付けるようにさらに構成される、
請求項１１に記載のバッファ管理装置。

【請求項13】

前記回路は、前記パケットストリームの各着信パケットについて、
対応するファイルのファイル識別子を判定し、
前記対応するファイルの前記ファイル識別子を有し、かつ不完全とのラベルが付いた前記マップ内のエントリが存在するかどうかを判定し、
前記対応するファイルの前記ファイル識別子を有する前記マップ内の不完全なエントリが存在するとの判定に応答して、
前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域に前記着信パケットを記憶し、
前記着信パケットが、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域において前記ファイルを完成させるかどうかを判定し、
前記着信パケットが、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域において前記ファイルを完成させるとの判定に応答して、
前記マップ内の前記エントリに関連する前記不完全ラベルを削除し、
前記マップ内の前記エントリと同じファイル名を有する前記マップ内の他の全てのエントリを削除し、
前記対応するファイルの前記ファイル識別子を有する前記マップ内の不完全なエントリが存在しないとの判定に応答して、前記着信パケットを新規着信ファイルとして処理する、
ようにさらに構成される、請求項１２に記載のバッファ管理装置。

【請求項14】

前記ファイル識別子は、トランスポートオブジェクト識別子（ＴＯＩ）及びファイル名を含む、
請求項１３に記載のバッファ管理装置。

【請求項15】

コンピュータ可読命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記コンピュータ可読命令は、プロセッサによって実行された時に、パケットストリームを介して受け取られたファイルを記憶するための、予め設定されたバイトサイズを有するバッファを管理する方法を前記プロセッサに実行させ、前記方法は、
着信ファイルのファイル識別子及び長さを判定するステップと、
前記着信ファイルが次の書き込み位置と前記バッファの最後との間のスペースに収まらないと判定するステップと、
前記着信ファイルが前記次の書き込み位置と前記バッファの前記最後との間の前記スペースに収まらないとの前記判定に応答して、
前記バッファに記憶された１又は２以上のファイルを識別するマップにおいて、前記バッファの初期書き込み位置から開始する領域に少なくとも部分的に記憶されたファイルに対応し、かつ前記着信ファイルの前記長さに等しいサイズを有する各エントリを削除するステップと、
前記着信ファイルの前記ファイル識別子及び前記長さを含むエントリを、前記バッファ内の前記初期書き込み位置に関連付けて前記マップ内に追加するステップと、
前記バッファ内の前記初期書き込み位置から開始して前記着信ファイルの前記長さに等しい前記サイズを有する前記バッファ内の連続領域を割り当てた後に、前記次の書き込み位置を前記割り当てられた連続領域の前記最後に移動させるステップと、
前記着信ファイルのパケットを受け取り、該受け取られたパケットを前記割り当てられた連続領域に記憶するステップと、
を含む、ことを特徴とする非一時的コンピュータ可読記憶媒体。

【請求項16】

前記パケットストリームは、高度テレビジョンシステムズ委員会（ＡＴＳＣ）３．０デジタルテレビ信号の一部である、
請求項１５に記載の非一時的コンピュータ可読記憶媒体。

【請求項17】

前記着信ファイルは、前記バッファに記憶された他のファイルと共通するトランスポートセッション識別子（ＴＳＩ）値を有する階層符号化トランスポート（ＬＣＴ）チャネルで受け取られ、
対応する異なるＴＳＩ値を有するファイルのために、新規バッファ及び別のマップが初期化される、
請求項１６に記載の非一時的コンピュータ可読記憶媒体。

【請求項18】

前記マップ内の前記追加されたエントリは、前記着信ファイルの前記ファイル識別子及び前記長さを含み、前記ファイル識別子は、トランスポートオブジェクト識別子（ＴＯＩ）及びファイル名を含む、
請求項１５に記載の非一時的コンピュータ可読記憶媒体。

【請求項19】

前記着信ファイルの前記受け取られたパケットが、前記ファイルに割り当てられた前記バッファ内の前記連続領域を満たすまで、前記マップ内の前記追加されたエントリに不完全とのラベルを付けるステップをさらに含む、
請求項１８に記載の非一時的コンピュータ可読記憶媒体。

【請求項20】

前記パケットストリームの各着信パケットについて、
対応するファイルのファイル識別子を判定するステップと、
前記対応するファイルの前記ファイル識別子を有し、かつ不完全とのラベルが付いた前記マップ内のエントリが存在するかどうかを判定するステップと、
前記対応するファイルの前記ファイル識別子を有する前記マップ内の不完全なエントリが存在するとの判定に応答して、
前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域に前記着信パケットを記憶するステップと、
前記着信パケットが、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域において前記ファイルを完成させるかどうかを判定するステップと、
前記着信パケットが、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域において前記ファイルを完成させるとの判定に応答して、
前記マップ内の前記エントリに関連する前記不完全ラベルを削除するステップと、
前記マップ内の前記エントリと同じファイル名を有する前記マップ内の他の全てのエントリを削除するステップと、
前記対応するファイルの前記ファイル識別子を有する前記マップ内の不完全なエントリが存在しないとの判定に応答して、前記着信パケットを新規着信ファイルとして処理するステップと、
をさらに含む、請求項１９に記載の非一時的コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、着信パケットストリームのパケットをバッファリングしながら限られたメモリリソースの管理を最適化する方法、装置及びコンピュータ可読記憶媒体に関する。

【背景技術】

【0002】

様々なサービス及びアプリケーションは、パケットストリームの受信を伴う。例えば、高度テレビジョンシステムズ委員会（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍｓ Ｃｏｍｍｉｔｔｅｅ）（ＡＴＳＣ）３．０標準には、放送局が送信チャネルを介して受信機にインターネットプロトコル（ＩＰ）パケットを配信する放送方法が規定されている。具体的に言えば、ＡＴＳＣ標準では、ＡＴＳＣ標準Ａ／３２２－物理層プロトコル（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｐｒｏｔｏｃｏｌ）（文書Ａ／３２２：２０１７、２０１７年６月６日付）（以下、「Ａ／３２２標準」）、及びＡＴＳＣ標準Ａ／３２１－システム発見及びシグナリング（Ｓｙｓｔｅｍ Ｄｉｓｃｏｖｅｒｙ ａｎｄ Ｓｉｇｎａｌｉｎｇ）（文書Ａ／３２１：２０１６、２０１６年３月２３日付）（以下、「Ａ／３２１標準」）に物理層プロトコルが規定されており、これらの各文書はその全体が引用により本明細書に組み入れられる。これらのプロトコルは、全体が引用により本明細書に組み入れられるＡＴＳＣ標準：リンク層プロトコル（Ｌｉｎｋ－Ｌａｙｅｒ Ｐｒｏｔｏｃｏｌ）（Ａ／３３０）（文書Ａ／３３０：２０１６、２０１６年９月１９日付）（以下、「Ａ／３３０標準」）におけるリンク層プロトコルと共に実装されて上位層にＵＤＰ／ＩＰパケットを配信する。

【0003】

ＡＴＳＣ３．０受信装置の上位層プロトコルは、受信、復調及び下位層処理が行われる下位層からＵＤＰ／ＩＰパケットを受け取って解釈し、インターネット通信に共通する多くのプロトコルに基づいて設計される。これらは、全体が引用により本明細書に組み入れられるＡＴＳＣ提案標準（Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ）Ａ／３３１（文書Ｓ３３－３３１ｒ１、２０１７年１１月７日付）（以下、「Ａ／３３１標準）に記載されているＲＯＵＴＥ（Ｒｅａｌ－Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ））と呼ばれるファイル配信のための修正されたＦｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ：ＦＬＵＴＥ）プロトコル、及びインターネット技術特別調査委員会（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ：（ＩＥＴＦ））によって開発された他の多くのインターネットプロトコルの使用を含む。Ａ／３３１標準には、ＵＤＰ／ＩＰベースのトランスポートプロトコルも規定される。

【0004】

ＡＴＳＣ３．０テレビ受信機は、シグナリングを処理し、パケットを選択し、復号してユーザに提供するために、ストリーミングデータの受信を毎秒数十メガビットの速度で管理することができる。放送ストリーム内で配信されるオブジェクトはファイルである。主にシグナリングデータを搬送するこれらのいくつかは単一のＵＤＰ／ＩＰパケットに収まるのに対し、他のものは長さが数メガバイトになることもあり、従って複数のＵＤＰ／ＩＰパケットに断片化されて配信される。

【発明の概要】

【発明が解決しようとする課題】

【0005】

ＡＴＳＣ３．０受信機の設計は、メモリに関連する複数の検討事項に対処することができる。例えば、ＡＴＳＣ３．０受信機のメモリは限られており、従ってその動作はメモリ使用を最適化すべきである。別の限られたリソースはＣＰＵサイクルであり、従ってＡＴＳＣ３．０受信機における受信データの記憶及び処理はＣＰＵサイクルの数を最小化すべきである。他の検討事項としては、メモリリークの回避、並びに揮発性メモリから不揮発性メモリへの適切なデータ転送を含む揮発性メモリ（例えば、ＲＡＭ）及び不揮発性メモリ（例えば、ＦＬＡＳＨ）の適切な使用が挙げられる。最後に、ＡＴＳＣ３．０受信機は、利用可能なメモリが不十分な場合でも容認できる性能及びユーザ体験をサポートするように設計されるべきである。本開示では、これらの課題に対処する方策について説明する。

【課題を解決するための手段】

【0006】

本開示の実施形態によれば、パケットストリームを介して受け取られたファイルを記憶するための、予め設定されたバイトサイズを有するバッファを管理する方法が提供される。方法は、着信ファイルのファイル識別子及び長さを判定するステップと、着信ファイルが次の書き込み位置とバッファの最後との間のスペースに収まらないと判定するステップとを含む。方法は、着信ファイルが次の書き込み位置とバッファの最後との間のスペースに収まらないとの判定に応答して、バッファに記憶された１又は２以上のファイルを識別するマップにおいて、バッファの初期書き込み位置から開始する領域に少なくとも部分的に記憶されたファイルに対応し、かつ着信ファイルの長さに等しいサイズを有する各エントリを削除するステップを含む。方法は、削除するステップと共に、着信ファイルのファイル識別子及び長さを含むエントリを、バッファ内の初期書き込み位置に関連付けてマップ内に追加するステップと、バッファ内の初期書き込み位置から開始して着信ファイルの長さに等しいサイズを有するバッファ内の連続領域を割り当てた後に、次の書き込み位置を割り当てられた連続領域の最後に移動させるステップとを含む。最後に、方法は、着信ファイルのパケットを受け取り、受け取られたパケットを割り当てられた連続領域に記憶するステップを含む。

【0007】

本開示の実施形態によれば、パケットストリームを介して受け取られたファイルを、予め設定されたバイトサイズを有するバッファに記憶するバッファ管理装置が提供される。バッファ管理装置は、着信ファイルのファイル識別子及び長さを判定し、着信ファイルが次の書き込み位置とバッファの最後との間のスペースに収まらないと判定するように構成される。バッファ管理装置は、着信ファイルが次の書き込み位置とバッファの最後との間のスペースに収まらないとの判定に応答して、バッファに記憶された１又は２以上のファイルを識別するマップにおいて、バッファの初期書き込み位置から開始する領域に少なくとも部分的に記憶されたファイルに対応し、かつ着信ファイルの長さに等しいサイズを有する各エントリを削除するように構成される。バッファ管理装置は、削除すると共に、着信ファイルのファイル識別子及び長さを含むエントリを、バッファ内の初期書き込み位置に関連付けてマップ内に追加し、バッファ内の初期書き込み位置から開始して着信ファイルの長さに等しいサイズを有するバッファ内の連続領域を割り当てた後に、次の書き込み位置を割り当てられた連続領域の最後に移動させるように構成される。最後に、バッファ管理装置は、着信ファイルのパケットを受け取り、受け取られたパケットを割り当てられた連続領域に記憶するように構成される。

【0008】

本開示の実施形態によれば、プロセッサによって実行された時に、パケットストリームを介して受け取られたファイルを記憶するための、予め設定されたバイトサイズを有するバッファを管理する方法をプロセッサに実行させるコンピュータ可読命令を記憶した非一時的コンピュータ可読記憶媒体が提供される。方法は、着信ファイルのファイル識別子及び長さを判定するステップと、着信ファイルが次の書き込み位置とバッファの最後との間のスペースに収まらないと判定するステップとを含む。方法は、着信ファイルが次の書き込み位置とバッファの最後との間のスペースに収まらないとの判定に応答して、バッファに記憶された１又は２以上のファイルを識別するマップにおいて、バッファの初期書き込み位置から開始する領域に少なくとも部分的に記憶されたファイルに対応し、かつ着信ファイルの長さに等しいサイズを有する各エントリを削除するステップを含む。方法は、削除するステップと共に、着信ファイルのファイル識別子及び長さを含むエントリを、バッファ内の初期書き込み位置に関連付けてマップ内に追加するステップと、バッファ内の初期書き込み位置から開始して着信ファイルの長さに等しいサイズを有するバッファ内の連続領域を割り当てた後に、次の書き込み位置を割り当てられた連続領域の最後に移動させるステップとを含む。最後に、方法は、着信ファイルのパケットを受け取り、受け取られたパケットを割り当てられた連続領域に記憶するステップを含む。

【0009】

上述した段落は、概略紹介として示したものであり、以下の特許請求の範囲を限定するものではない。添付図面と併せて行う以下の詳細な説明を参照することにより、説明する実施形態及びさらなる利点が最も良く理解されるであろう。

【0010】

本開示のより完全な理解及びこれに付随する利点の多くは、添付図面と併せて検討する以下の詳細な説明を参照することによってこれらがより良く理解されるようになるにつれて容易に取得されるであろう。

【図面の簡単な説明】

【0011】

【図1】例示的なデジタルテレビ放送システムを示す図である。

【図2】例示的な受信装置を示す図である。

【図3】受信装置において実行される例示的なプロセスを示す図である。

【図4】受信装置において実行される例示的な「新規ファイル開始」サブプロセスを示す図である。

【図5A】例示的なバッファを示す図である。

【図5B】図５Ａの例示的なバッファに対応するハッシュテーブルを示す図である。

【図6A】例示的なバッファを示す図である。

【図6B】図６Ａの例示的なバッファに対応するハッシュテーブルを示す図である。

【図7A】例示的なバッファを示す図である。

【図7B】図７Ａの例示的なバッファに対応するハッシュテーブルを示す図である。

【図8A】例示的なバッファを示す図である。

【図8B】図８Ａの例示的なバッファに対応するハッシュテーブルを示す図である。

【図9A】例示的なバッファを示す図である。

【図9B】図９Ａの例示的なバッファに対応するハッシュテーブルを示す図である。

【図10A】例示的なバッファを示す図である。

【図10B】図１０Ａの例示的なバッファに対応するハッシュテーブルを示す図である。

【図11A】例示的なバッファを示す図である。

【図11B】図１１Ａの例示的なバッファに対応するハッシュテーブルを示す図である。

【図12A】例示的なバッファを示す図である。

【図12B】図１２Ａの例示的なバッファに対応するハッシュテーブルを示す図である。

【図13A】例示的なバッファを示す図である。

【図13B】図１３Ａの例示的なバッファに対応するハッシュテーブルを示す図である。

【図14A】例示的なバッファを示す図である。

【図14B】図１４Ａの例示的なバッファに対応するハッシュテーブルを示す図である。

【図15】コンピュータのハードウェア構成例を示す図である。

【発明を実施するための形態】

【0012】

本開示は多くの異なる形の実施形態が可能であるが、図面には特定の実施形態を示して本明細書ではこれらについて詳細に説明しており、このような実施形態の開示は本原理の一例とみなすべきであって、図示及び説明する特定の実施形態に本開示を限定することを意図するものではないと理解されたい。

【0013】

本明細書で使用する「１つの（英文不定冠詞）」という用語は、１つ又は１つよりも多くとして定義される。本明細書で使用する「複数の」という用語は、２つ又は２つよりも多くとして定義される。本明細書で使用する「別の」という用語は、少なくとも第２の又はそれ以降のとして定義される。本明細書で使用する「含む（ｉｎｃｌｕｄｉｎｇ）」及び／又は「有する（ｈａｖｉｎｇ）」という用語は、「備える（ｃｏｍｐｒｉｓｉｎｇ）」（すなわちオープンランゲージ）として定義される。本明細書で使用する「結合される（ｃｏｕｐｌｅｄ）」という用語は、「接続される」として定義されるが、必ずしも直接的なものではなく、必ずしも機械的なものでもない。本明細書で使用する「プログラム」又は「コンピュータプログラム」という用語又は同様の用語は、コンピュータシステム上で実行されるように設計された一連の命令として定義される。「プログラム」又は「コンピュータプログラム」は、実行可能アプリケーション、アプレット、サーブレット、ソースコード、オブジェクトコード、スクリプト、プログラムモジュール、共有ライブラリ／動的ロードライブラリ及び／又はコンピュータシステム上で実行するように設計されたその他の一連の命令におけるサブルーチン、プログラムモジュール、スクリプト、関数、手順、オブジェクト方法、オブジェクト実装を含むことができる。

【0014】

本明細書で使用する「プログラム（ｐｒｏｇｒａｍ）」という用語は、第２の文脈で使用することもできる（上記の定義を第１の文脈とする）。第２の文脈では、この用語は「テレビ番組」の意味で使用される。この文脈では、この用語は、単一のテレビ番組として解釈されて電子番組ガイド（ＥＰＧ）で伝えられるものなどのいずれかのコヒーレントな一連のオーディオビデオコンテンツを意味するために使用され、このコンテンツが映画、スポーツイベント、連続番組の一部、ニュース放送などのいずれであるかは関係ない。この用語は、ＥＰＧでは番組として伝えられないこともあるコマーシャルスポット及びその他の番組様コンテンツを含むと解釈することもできる。

【0015】

本明細書全体を通じて、「１つの実施形態」、「いくつかの実施形態」、「ある実施形態」、「ある実装」、「ある実施例」又は同様の用語に対する言及は、実施形態に関連して説明する特定の特徴、構造又は特性が、本開示の少なくとも１つの実施形態に含まれることを意味する。従って、本明細書を通じて至るところに出現するこのような語句は、必ずしも全てが同じ実施形態を意味するわけではない。さらに、これらの特定の特徴、構造又は特性は、１又は２以上の実施形態においていずれかの好適な方法で無制限に組み合わせることもできる。

【0016】

本明細書で使用する「又は（ｏｒ）」という用語は、包括的なもの、すなわちいずれか１つ又はいずれかの組み合わせを意味するものとして解釈されたい。従って、「Ａ、Ｂ又はＣ」は、「Ａ、Ｂ、Ｃ、ＡとＢ、ＡとＣ、ＢとＣ、ＡとＢとＣ」のうちのいずれかを意味する。この定義に対する例外は、要素、機能、ステップ又は行為の組み合わせが何らかの点で本質的に互いに相容れない場合にのみ生じる。

【0017】

ここで複数の図全体を通じて同一の又は対応する部分を同じ参照数字によって示す図面を参照すると、以下の説明は、受信パケットストリームのファイルを記憶するバッファ管理システムに関する。

【0018】

本開示の実施形態は、テレビ受信装置（例えば、ＡＴＳＣ３．０受信機）において受け取られたファイルを収集して記憶する方法に関する。この方法は、例えばＡＴＳＣ３．０放送送信の特性に基づいてＣＰＵサイクルが最小化されて動作が最適化されるように管理される１又は２以上の循環バッファを使用する。このようなＡＴＳＣ３．０送信の１つの特性は、特定のファイルが頻繁に繰り返される点である。頻繁に繰り返されるファイルの一例は、ストリーミングメディアの各要素（例えば、ビデオエレメンタリストリーム、オーディオエレメンタリストリームなど）の復号を開始するために必要な「初期化セグメント」（ＩＳ）ファイルである。

【0019】

本開示の実施形態は、以下の概念に基づく。
（１）例えばＡ／３３１標準に規定されるシグナリングによって着信ファイルの長さが予め分かっている。
（２）ファイルの断片を搬送する各パケットが、ファイルの開始からその断片が属するファイル内の地点までのオフセットを示すオフセットパラメータを含む。このオフセットパラメータは、バッファ内のどこに断片を配置すべきであるかを決定するためにテレビ受信装置によって使用されることにより、断片の順不同受信（ｏｕｔ－ｏｆ－ｏｒｄｅｒ ｒｅｃｅｐｔｉｏｎ）を可能にすることができる。
（３）ファイルが、バッファの非連続領域に分割されることなくバッファの連続バイトに書き込まれる。従って、ファイルの最初がバッファの最後の方に書き込まれて残りのファイルがバッファの先頭に書き込まれるような「ラッピング」が生じない。すなわち、「ラッピング」が生じると、ファイルの部分がバッファの不連続領域に、すなわちバッファの最後及びバッファの最初に存在するようになるので、本開示の実施形態では「ラッピング」が実行されない。
（４）（３）で上述したように「ラッピング」は実行されないが、所与のファイルが現在の書き込み位置とバッファの最後との間のバッファ領域に収まりきらない場合には、バッファの最初の１又は２以上のファイルを削除して場所を空け、現在の書き込み位置をバッファの最初又はその方向に移動できるという意味で、循環的にファイルを書き込むことができる。
（５）各バッファが、ビデオ、オーディオ及びキャプションの復号及び同期提示を維持するために必要な数のファイルを記憶できるように適切にサイズ設定される。
（６）既にバッファ内に存在するファイルの複製物である新規ファイルが受け取られた場合、新規ファイルの最後のバイトがバッファに記憶された後に、先に受け取られたファイルを記憶しているバッファの領域を解放することができる。

【0020】

本開示の実施形態で使用される各循環バッファは、メモリ（例えば、ＲＡＭ）内の固定された連続するメモリ範囲を占有してファイルオブジェクトを記憶する。各バッファでは、次の新規ファイルの最初のバイトが書き込まれるメモリ位置をポインタ（以下、「次の開始位置」）が識別することができる。各バッファは、割り当てられた固有のバッファ番号と、バッファ内のファイルを表すエントリを記載又は別様に識別する関連するハッシュテーブル（或いは他のテーブル又はデータ構造）とを有する。バッファのハッシュテーブル内の各エントリは、バッファに記憶された１つのファイルに対応し、１つの実施形態では、そのファイルに関する少なくともファイル名、Ａ／３３１標準に従うファイルの伝送に関連するトランスポートオブジェクト識別子（Ｔｒａｎｓｐｏｒｔ Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒ（ＴＯＩ）、ファイルの最初のバイトのバッファ内位置、及び総ファイル長といったパラメータを含む。Ａ／３３１に規定されるトランスポートプロトコルはＦＬＵＴＥに基づくので、Ａ／３３１のＴＯＩは、ＲＦＣ ６７２６に規定されるＦＬＵＴＥ標準のＴＯＩ値と同じ機能を実行する。

【0021】

図１は、テレビコンテンツへのアクセスを提供する例示的なデジタルテレビ放送システム１００である。このシステムは、サービスプロバイダ１０２、受信装置１２０及び入力装置１４０を含む。受信装置１０２は、アンテナを介してデータを受け取るように構成することができる。受信装置１０２は、データを受け取るためにインターネット１３０に接続するようにさらに構成することができる。

【0022】

１つの例では、サービスプロバイダ１０２がテレビコンテンツの放送局であり、受信装置１２０は、テレビとして動作するように構成された、フラット画面ＴＶ、ラップトップ、タブレット又はスマートフォンなどのいずれかの装置とすることができる。入力装置１４０は、受信装置１２０に物理的に又は無線で接続することができ、数字キー及び／又は英数字キーを有するリモコン、ＱＷＥＲＴＹキーボード、或いは受信装置１２０に適合するアプリケーションを実行するスマートフォンなどの、受信装置１２０を操作するのに適したいずれかの装置とすることができる。入力装置１４０のキーは、物理的ボタン、或いはタッチ画面上の数字又は英数字キーのデジタル表現とすることができる。本開示の実施形態は、他の放送コンテンツ（例えば、ＨＴＭＬ５アプリケーションなどの実行可能アプリケーション）へのアクセスを提供するために利用することができる。サービスプロバイダ１０２は、テレビコンテンツを含む放送ストリームを送信し、デジタルテレビ放送信号を介して配信することができる。

【0023】

１つの実施形態では、サービスプロバイダ１０２（例えば、放送エンティティ又は放送局）が、受信装置１２０にデータストリーム（例えば、放送ストリーム）でコンテンツ、アプリケーション及び／又はサービスを送信するように構成された送信機を有する送信装置を含むサービス配信システムを運用する。送信機は、例えばデジタル地上波放送を介して受信装置１２０にデータストリームを提供するように構成される。他の例では、デジタル地上波放送、携帯電話ネットワーク、インターネットなどのブロードバンドネットワーク、ケーブルネットワーク及び衛星リンクのうちの１つ又はこれらの組み合わせを介して受信装置１２０にデータストリームを送信することができる。サービス配信システムは、いずれか１つの又は様々な送信技術を使用して受信装置１２０にデータストリームを伝達することができる。

【0024】

１つの実施形態によるサービス配信システムは、ソースエンコーダ、チャネルエンコーダ及び変調器を含む。ソースエンコーダは、ソースから受け取られたオーディオデータ、ビデオデータ、シグナリングデータ、制御データ又はその他のデータを圧縮するデータエンコーダ、オーディオエンコーダ及びビデオエンコーダを含む。チャネルエンコーダは、圧縮されたメディアデータ及びシグナリングデータをランダム化し、インターレース化し、チャネルコード化してフレームマッピングする。例えば、チャネルエンコーダは、多くのデータセルを直行周波数分割多重（ＯＦＤＭ）記号で伝えられるシーケンスに形成するフレームビルダを含む。変調器（例えば、マルチプレクサ）は、処理されたデジタルデータを、例えばＯＦＤＭ記号とすることができる変調記号に変換する。次に、この多重化されたデータは、周波数領域信号を時間領域信号に変換する逆高速フーリエ変換器（ＩＦＴＦ）に受け渡される。時間領域信号は、記号間のガードインターバル（ＧＩ）を生成するガード挿入モジュールに供給された後に、デジタル－アナログ（Ｄ／Ａ）コンバータに供給される。その後、アップコンバージョン、ＲＦ増幅及びｏｖｅｒ－ｔｈｅ－ａｉｒ放送を実行して放送ストリームを送信する。

【0025】

他の実施形態では、送信装置又は受信装置のいくつかのコンポーネントが不要な場合もある。ＯＦＤＭ送信機及び受信機の詳細は、例えば、ＤＶＢ－Ｔ２標準（ＥＴＳＩ ＥＮ ３０２ ７５５ Ｖ１．４．１、２０１５年７月１日付）（引用により本明細書に組み入れられる）、Ａ／３２２標準及びＡ／３２１標準において見出すことができる。

【0026】

図２に、テレビコンテンツ及び放送局アプリケーションにアクセスするように構成された例示的な受信装置１２０を示す。受信装置１２０は、テレビ受像機、セットトップボックス、スマートフォン、タブレットコンピュータ、ラップトップ、ポータブルコンピュータ、又はテレビコンテンツを受け取るように構成された他のいずれかの装置などの固定装置又はモバイル装置とすることができる。さらに、受信装置１２０は、車両、或いは上述した固定装置又はモバイル装置のうちのいずれかに組み込まれたデジタルテレビ受信機とすることができる。

【0027】

受信装置１２０は、１又は２以上のサービスプロバイダ１０２からデータストリーム（例えば、放送ストリーム）を受け取るように構成された受信機回路と、受信装置１２０の様々な機能を実行するように構成された処理回路とを含む。１つの実施形態では、チューナ／復調器２０２が、放送ストリームを含む放送排出物（ｂｒｏａｄｃａｓｔ ｅｍｉｓｓｉｏｎｓ）を受け取る。これに代えて又はこれに加えて、受信装置２００は、実施形態によってはケーブルテレビ送信又は衛星放送を受信するように構成することもできる。

【0028】

チューナ／復調器２０２によってＡＴＳＣ３．０放送排出物が取得されると、現在説明中の実施形態に従って着信データパケットをワーキングメモリ２４０にバッファリングすることができる。いくつかの実施形態では、現在説明中の管理法に従ってバッファリングされたいくつかのファイルが、例えば永続ストレージ２８０、バッファ及びハッシュマップによって占有されていないワーキングメモリ２４０の部分、又は別のＲＡＭに選択的に移動される。このファイルが上書きされるバッファ以外のメモリへの選択的移動は、後の時点で参照（又は再びアクセス）される可能性があるファイルに適用される。例としては、シグナリングテーブル、及び放送局アプリケーションに関連するファイルが挙げられる。メディアに関連するファイル（例えば、ビデオ、オーディオ及びキャプション）は、これらが受け取られたバッファから直接レンダリングされて提示され、後の時点でこれらを再生できる永続ストレージに移動しないことができる。一方で、パーソナルビデオレコーダ（ＰＶＲ）機能を実装する受信装置では、メディアファイルがタイムシフト再生のために永続ストレージに移動される。

【0029】

デマルチプレクサ２０４は、ストレージ２８０からのいずれかの必要なファイルを使用してデータストリームを多重分離し、多重分離されたデータを、別個のオーディオ及びビデオ（Ａ／Ｖ）ストリームに復号するためにメディアエンジン２９０に供給することができる。メタデータ、低水準シグナリング（ＬＬＳ）及びサービス層シグナリング（ＳＬＳ）ファイル、メディアファイル、並びに電子サービスガイド（ＥＳＧ）ファイルなどの、デマルチプレクサ２０４によって出力されたファイルは、処理のためにＣＰＵ２３８に提供することができる。オーディオはオーディオデコーダ２１０によって復号され、ビデオはビデオデコーダ２１４によって復号される。さらに、利用可能な場合には、非圧縮Ａ／Ｖインターフェイス（例えば、ＨＤＭＩインターフェイス）を介して非圧縮Ａ／Ｖデータを受け取ることもできる。

【0030】

一般に、受信装置２００は、１又は２以上のバス（例えば、バス２５０）を介して永続ストレージ２８０、ワーキングメモリ２４０、プログラムメモリ２４２及びグラフィクスサブシステム２４４に結合されたＣＰＵ２３８などの少なくとも１つのプロセッサの制御下で動作する。１つの実施形態によれば、ＣＰＵ２３８は、受け取ったメディアをユーザに出力するためのユーザインターフェイスを生成するように構成される。グラフィクスサブシステム２４４によって出力されたグラフィクスは、ビデオディスプレイ上での表示に適した出力を生成する合成器及びビデオインターフェイス２６０によってビデオ画像と合成される。

【0031】

ＣＰＵ２３８は、例えばプログラムメモリ２４２に記憶されたＨＴＭＬ５ユーザエージェントを使用して放送局アプリケーション（例えば、ＨＴＭＬ５アプリケーション）、ネイティブ放送局アプリケーションなどに含まれるスクリプトオブジェクト（制御オブジェクト）を実行することを含む、受信装置２００の機能を実行するように動作する。

【0032】

１つの実施形態では、放送局アプリケーションを構成する一群のファイルを、例えば全体が引用により組み入れられるＡＴＳＣ標準Ａ／３３１（文書Ａ／３３１：２０１７、２０１７年１２月６日付）（以下、Ａ／３３１標準）に記載されているＲＯＵＴＥプロトコルを介して放送を通じてパッケージとして配信することができる。ＡＴＳＣ標準Ａ／３４４（文書Ａ／３３１：２０１７、２０１７年１２月１８日付）（以下、「Ａ／３３４標準」）には例示的な放送局アプリケーションが記載されており、この文書はその全体が引用により組み入れられる。

【0033】

いくつかの実施形態では、ＣＰＵ２３８を受信装置１２０のリソースのうちのいずれか１つ又はこれらの組み合わせに結合して、１又は２以上の機能の制御を集中化させることができる。１つの実施形態では、ＣＰＵ２３８が、チューナ／復調器２０２及びその他のテレビリソースを含む受信装置１２０の制御を監視するようにも動作する。

【0034】

１つの実施形態では、着信データパケットを通じて受け取られたファイルのバッファリングがＣＰＵ２３８によって制御される。図３を参照しながら、バッファリング管理プロセス３００について説明する。このプロセスは、パケットを受け取るステップＳ３０から開始する。このパケットは、初期化されたバッファ及び対応するハッシュテーブルにとっての最初に受け取られたパケットとすることも、或いはパケットストリームで受け取られた後続パケットのうちの１つとすることもできる。

【0035】

最初のパケットを受け取る前者のシナリオでは、所定のバイトサイズのバッファが初期化され、バッファに対応するハッシュテーブルが作成される。初期状態では、バッファ及びハッシュテーブルの両方が空であり、次の開始位置ポインタがバッファの先頭に初期化される。受信機がＡＴＳＣ３．０放送排出物にチューニングしてシグナリングテーブルが検索されると、要求されたサービスに関連する階層符号化トランスポート（Ｌａｙｅｒｅｄ Ｃｏｄｎｇ Ｔｒａｎｓｐｏｒｔ：ＬＣＴ）チャネルが識別される。例えば、ＬＣＴチャネルは、Ａ／３３１標準によって規定されるように、サービスリストテーブル（ＳＬＴ）と、サービスベースのトランスポートセッションインスタンス記述（Ｓｅｒｖｉｃｅ－ｂａｓｅｄ Ｔｒａｎｓｐｏｒｔ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）（Ｓ－ＴＳＩＤ）を含むサービス層シグナリング（ＳＬＳ）テーブルとを使用して識別することができる。

【0036】

各ＬＣＴチャネルは、発信元及び宛先のＩＰアドレス、ポート値及びＴＳＩ値の特定の組み合わせに関連する。同じ発信元及び宛先ＩＰアドレス及びポート値のＩＰパケット内で複数のＬＣＴチャネルを搬送することができる。１つの実施形態では、ＴＳＩ値が特定のＬＣＴチャネルを区別する。すなわち、受け取られた各ＬＣＴチャネルは、ＬＣＴチャネルのＴＳＩ値を有するパケットを記憶して管理する、対応する初期化されたバッファ及びハッシュテーブルを有する。

【0037】

ＡＴＳＣ Ａ／３３１標準には、ＲＯＵＴＥ／ＤＡＳＨ及びＭＰＥＧ ＭＭＴという２つの異なる可能なトランスポートプロトコルが規定されている。本開示によるバッファ管理プロセスの実施形態は、これらの両方のトランスポートプロトコルに適用可能である。ＭＰＥＧ ＤＡＳＨ標準は、ＩＳＯ／ＩＥＣ ２３００９－１：２０１４、「情報技術－Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）－第１部：メディアプレゼンテーション記述及びセグメントフォーマット」、国際標準化機構、２０１４年５月１５日付(以下、「ＭＰＥＧ ＤＡＳＨ標準」）に記載されており、この文書の内容は全体が引用により組み入れられる。

【0038】

再び図３のバッファ管理プロセス３００のステップＳ３０を参照すると、パケットを受け取った後のステップは、ステップＳ３２における対応するハッシュテーブルを通じた反復である。ハッシュテーブルを通じた反復の目的は、ステップＳ３４において、受信パケットと同じＴＯＩ番号を有する不完全とのラベルが付いたハッシュテーブル内のエントリが存在するかどうかを判定することである。いくつかの実施形態では、例えばＴＯＩ番号自体が一意的にファイル名を識別しない実施形態では、ステップＳ３４が、同じファイル識別子（例えば、ファイル名及びＴＯＩ）を有するハッシュテーブル内のエントリが存在するかどうかを判定することを含む。受信パケットの名前及びＴＯＩ番号に一致する不完全とのラベルが付いたハッシュテーブル内のエントリが見つかった場合には、この受信パケットが、既に部分的に受け取られてバッファリングされたファイルのセグメントであることの表れである。従って、このファイルには適切なバッファスペースが割り当てられており、受信パケットは、この割り当てられたバッファスペースに属する。

【0039】

従って、プロセス３００のステップＳ３４からのＹＥＳの分岐はステップＳ３６に進み、ハッシュテーブル内の見つかったエントリに対応するファイルの割り当てバッファ領域に受信パケットを記憶する。ハッシュテーブル内の見つかったエントリは、このファイルのために割り当てられたスペースの最初のバイトの位置を示す。上述したように、受信パケットは、ファイルの最初から受信パケットの断片が属するファイル内の地点までのオフセットを示すオフセットパラメータを含む。ステップＳ３６では、バッファ内のファイルの最初のバイトの位置に受信パケットのオフセットパラメータを追加することによって、受信パケットのファイル断片に適したバッファ内の位置を決定し、ファイル断片をバッファに記憶することができる。

【0040】

バッファに記憶されたファイルがファイル断片によって完成した場合、完成したファイルに対応するハッシュテーブル内のエントリから「不完全」ラベルが削除される。ファイルの最後のファイル断片が受け取られて、ハッシュテーブル内のエントリから「不完全」ラベルが削除されると、ハッシュテーブルの検索が実行されて、ハッシュテーブル内に同じ名前の別のファイルが既に存在するかどうか、すなわち過去に同じファイルが受け取られてバッファリングされているかどうかが判定される。ハッシュテーブル内でこのような重複エントリが見つかった場合、この重複エントリはハッシュテーブルから削除される。先に受け取られた重複ファイルのバイトはバッファ内に残って消去されないが、このファイルに対応するエントリがハッシュテーブルから削除されることにより、ハッシュテーブルは、先に受け取られた重複ファイルが書き込まれたバッファの領域への参照を含まないようになる。

【0041】

再びステップＳ３４を参照すると、受信パケットのＴＯＩ番号に一致する不完全とのラベルが付いたエントリがハッシュテーブル内で見つからない場合には、２つの可能性の一方が示される。受信パケットのＴＯＩ番号を有するエントリがハッシュテーブル内に存在しない場合、このパケットは、新規着信ファイルの最初のパケットである。或いは、ハッシュテーブル内に受信パケットと同じＴＯＩ番号を有するエントリが存在するが、このエントリに不完全とのラベルが付いていない場合には、同じファイルの以前の送信が過去の時点で完全にバッファリングされており、受信パケットがこのファイルの新たな送信の最初のパケットであることの表れである。

【0042】

上記のいずれの場合にも、受信パケットのＴＯＩ番号に一致する不完全とのラベルが付いたハッシュテーブル内のエントリが見つからなかったことを示すステップＳ３４のＮＯの分岐では、ステップＳ３８において新規ファイルを開始するプロセスが実行される。この新規ファイルを開始するプロセスを、図４を参照しながら新規ファイル開始動作４００として説明する。

【0043】

新規ファイル開始動作は、ステップＳ４０から開始してステップＳ４１に進み、新規ファイルがバッファ内の残りのスペースに収まるかどうかを判定する。この判定を行うために、例えばＡ／３３１標準において上述したように、シグナリングを通じて予め受け取られている新規ファイルのサイズを次の開始位置ポインタのバイト位置に追加する。結果として得られた位置がバッファの最後を越えている場合には、ステップＳ４１において、最初にさらなるスペースを利用可能にしない限り新規ファイルがバッファの残りスペースに収まらないと判定される。次の開始位置ポインタの位置とバッファの最後との間の残りのバッファ領域よりも新規ファイルのサイズの方が大きい場合、作成されるスペースはバッファの先頭から取られる。

【0044】

一方で、次の開始位置ポインタのバイト位置に新規ファイルのサイズを追加することによって得られる位置がバッファの最後を越えない場合には、ステップＳ４１において、ハッシュテーブル内のエントリを削除する必要なく新規ファイルがバッファ内の残りスペースに収まると判定される。この場合、プロセスはステップＳ４６に進み、新規ファイルの範囲がハッシュテーブル内にリストされる他のファイルに重なり合うかどうかを判定する。

【0045】

ステップＳ４１において、ファイルが次の開始位置とバッファの最後との間に収まると判定されたので、ステップＳ４６では、次の開始位置ポインタからファイルの書き込みが開始することが分かっている。従って、ステップＳ４６における新規ファイルの範囲は、次の開始位置から開始して新規ファイルの長さに及ぶ。ステップＳ４６では、この新規ファイルの範囲を考慮して、ハッシュテーブルにリストされたいずれかの（単複の）ファイルが新規ファイルの範囲に重なり合うかどうかを判定する。このプロセスでは、ハッシュテーブル内の各エントリの割り当てられた連続バッファ領域が、ファイルの最初のバイト位置のハッシュテーブルフィールドに示されるバイト番号から開始して、ハッシュテーブルエントリのファイル長フィールドに等しい長さであると判定される。次に、各それぞれのハッシュテーブルエントリの関連する連続バッファ領域が新規ファイルの範囲に重なり合うかどうかが判定される。換言すれば、ステップＳ４６は、仮に新規ファイルがバッファに記憶された場合に、ハッシュテーブルにリストされたいずれかの（単複の）ファイルが部分的に又は全体的に上書きされるかどうかを判定する。

【0046】

ステップＳ４６において、新規ファイルの範囲がハッシュテーブル内のファイルに重なり合わないと判定された場合、プロセスはステップＳ４７に進んで、次の開始位置から開始される新規ファイルのためにバッファ内の領域が割り当てられる。ステップＳ４７の割り当ての一部として、シグナリングを通じて予め受け取られていてステップＳ３０において受け取られたパケットに含まれている新規ファイルに関する情報に基づいて、ハッシュテーブル内で新規エントリが作成される。例えば、ファイル名、ファイルのＴＯＩ及びファイル長がハッシュテーブル内に１つのエントリとして追加される。ファイルの最初のバイトの位置は、次の開始位置ポインタの現在位置としてハッシュテーブル内に追加される。最後に、ステップＳ３０において受け取られたパケットがファイル全体を含んでいない場合、ハッシュテーブル内の新規エントリに不完全とのラベルが付けられる。

【0047】

従って、ステップＳ４７では、ハッシュテーブル内の作成されたエントリに基づいて、バッファ内の領域が新規ファイルのために割り当てられる。割り当てバッファ領域は連続し、次の開始位置ポインタの現在位置から開始する。割り当てバッファ領域のサイズは、新たに作成されたハッシュテーブルエントリに示されるファイルの長さである。ステップＳ４７においてバッファ内の領域が割り当てられると、ステップＳ４８において、次の開始位置ポインタの位置が割り当て領域の最初から割り当て領域の最後に移動し、或いは新規ファイルがバッファの最後までぴったりと埋まる場合にはバッファの先頭に移動する。本開示で使用する「バッファの先頭」は、バイト０又はそれに近接する別の位置とすることができるバッファの最初に近い位置を示す。

【0048】

次に、ステップＳ４９において、ステップＳ３０において受け取られたパケットを割り当て領域に記憶する。ステップＳ３０において受け取られたパケットは、必ずしも新規ファイルの最初の断片を搬送しているわけではないので、ステップＳ４９では、ステップＳ３６のものと同じオフセット判定が実行される。すなわち、受信パケットは、ファイルの最初から受信パケットの断片が属するファイル内の地点までのオフセットを示すオフセットパラメータを含む。ステップＳ４９では、バッファ内のファイルの最初のバイトの位置に受信パケットのオフセットパラメータを追加することによって、受信パケットのファイル断片に適したバッファ内の位置を決定し、このファイル断片をバッファに記憶することができる。

【0049】

再びステップＳ４６を参照すると、ステップＳ４６において、ハッシュテーブルに記憶された（単複の）ファイルの割り当てバッファ領域に新規ファイルの範囲が重なり合うと判定された場合には、このステップのＹＥＳ分岐をたどる。上述したように、新規ファイルの範囲は、次の開始位置から開始して新規ファイルの長さに及び、ハッシュテーブル内の各ファイルの割り当てバッファ領域は、ハッシュテーブルに記憶された情報に基づいて決定することができる。ハッシュテーブル内の少なくとも１つのファイルの割り当てバッファ領域が新規ファイルの範囲に重なり合うことが判明した場合、ステップＳ５０が実行される。ステップＳ５０において、新規ファイルの範囲に重なり合うことが判明したハッシュテーブル内の（単複の）ファイルをハッシュテーブルから削除する。これにより、プロセスは、新規ファイルの割り当て領域に重なり合うエントリをハッシュテーブル内に有することなく、新規ファイルにバッファ領域を割り当てるためのステップＳ４７に進むことができる。その後、上述したようにステップＳ４８及びＳ４９が実行される。

【0050】

再びステップＳ４１を参照すると、新規ファイルがバッファ内の残りスペースに収まらないと判定された場合には、このステップのＮＯ分岐をたどる。上述したように、この判定は、次の開始位置ポインタのバイト位置とバッファの最後との間に残っているバッファ領域よりも新規ファイルのサイズの方が大きい場合に行われる。この場合、ステップＳ４２において「スペース作成」動作が実行される。

【0051】

ステップＳ４２では、ステップＳ４１においてバッファ内の残りスペースに新規ファイルが収まらないと判定された結果として、スペース作成動作を開始する。従って、新規ファイルの範囲は、バッファの最初又はバッファの最初の方の初期書き込みバッファ位置から開始して、新規ファイルの長さに及ぶ。新規ファイルの範囲は、連続ブロック内でこの開始地点から新規ファイルの長さに及ぶ。

【0052】

上述したように、いくつかの実施形態では、必ずしもバッファの最初ではないとしても新規ファイルの長さを収容できる初期書き込みバッファ位置に新規ファイルが書き込まれる。上述したように、「バッファの先頭」は、バイト０又はそれに近接する別の位置とすることができるバッファの最初に近い位置を示すために使用される。すなわち、いくつかの実施形態における新規ファイルの範囲は、バイト０からではなく他の何らかの初期書き込みバッファ位置から開始して新規ファイルの長さに及ぶ。１つの実施形態では、新規ファイルの範囲が、新規ファイルを記憶するために上書きされるべきである以前に記憶されたファイル又は一群のファイルの最初のバイトに対応するバイト番号から開始する。別の実施形態では、新規ファイルの範囲が、新規ファイルを記憶するために必要なさらなるバイト数だけ次の開始位置を移動させることによって決定されるバイト番号から開始する。

【0053】

次に、ステップＳ４３において、新規ファイルの範囲に重なり合うハッシュテーブル内の各エントリを識別する。ステップＳ４１において、新規ファイルがバッファの残りスペースに収まらないことが判明しているので、上述したように、新規ファイルの範囲は、バッファの先頭又はその付近に存在し得る初期書き込みバッファ位置から開始して新規ファイルの長さに及ぶ。

【0054】

ステップＳ４３では、ハッシュテーブル内の各エントリについて、バッファ内のファイルの関連する連続領域が、ハッシュテーブルフィールドに示されるファイルの最初のバイトの位置のバイト番号から開始して、ハッシュテーブルエントリのファイル長フィールドに等しい長さであると判定される。次に、各それぞれのハッシュテーブルエントリの関連する連続バッファ領域が新規ファイルの範囲に重なり合うかどうかが判定される。換言すれば、ステップＳ４３は、仮に新規ファイルがバッファに記憶された場合に部分的に又は全体的に上書きされる、ハッシュテーブルにリストされた全てのファイルを識別する。

【0055】

ステップＳ４４において、ステップＳ４３において識別された全てのハッシュテーブルエントリをハッシュテーブルから削除する。このステップは、新規ファイルを書き込むことによって、ハッシュテーブルから削除されるエントリを有するファイルを部分的に又は全体的に上書きすることに備えて行われる。

【0056】

ステップＳ４４が完了すると、プロセスはステップＳ４５に進み、初期書き込み位置から開始するバッファ内の領域が新規ファイルに割り当てられる。ステップＳ４５における割り当ての一部として、ハッシュテーブル内で新規エントリが作成される。シグナリングを通じて予め受け取られていてステップＳ３０において受け取られたパケットに含まれている新規ファイルに関する情報に基づいて、ファイル名、ファイルのＴＯＩ及びファイル長がハッシュテーブル内に新規エントリとして追加される。新規エントリでは、初期書き込み位置がファイルの最初のバイトの位置として示される。上述したように、いくつかの実施形態では、バッファ容量を最適化するために、初期書き込み位置がバッファの先頭に配置される。他の実施形態では、初期書き込み位置とバッファの最後との間のスペースが新規ファイルのサイズを収容できる限り、初期書き込み位置が別のバッファ位置に配置される。最後に、ステップＳ３０において受け取られたパケットがファイル全体を含んでいない場合、ハッシュテーブル内の新規エントリに不完全とのラベルが付けられる。

【0057】

ステップＳ４５が完了すると、ステップＳ４８において、次の開始位置ポインタの位置を割り当て領域の最後に移動させ、ステップＳ４９において、ステップＳ３０で受け取られたパケットを割り当て領域に記憶する。上述したように、ステップＳ４９では、バッファ内のファイルの最初のバイトの位置（この位置は、ステップＳ４７においてバッファ領域が割り当てられた場合には次の開始位置ポインタの位置であり、或いはステップＳ４５においてバッファ領域が割り当てられた場合には初期書き込み位置である）に受信パケットのオフセットパラメータを追加することによってパケットの「順不同」受信に対応する。ステップＳ４９では、このような追加に従って受信パケットのファイル断片に適したバッファ内の位置を決定し、ファイル断片をバッファに記憶することができる。

【0058】

次に、図３及び図４を参照しながら上述したプロセスによるバッファ及びハッシュテーブルの動作例を示す。図５Ａ及び図５Ｂに、バッファ及び対応するハッシュテーブルの初期状態を示す。この例では、バッファの所定のバイトサイズが２０，０００，０００バイトである。いくつかの実施形態では、バッファがＲＡＭ内の連続するメモリブロックである。図５Ａの初期化状態では、次の開始位置ポインタの位置がバッファの先頭である。以下の例における０～２０，０００，０００のバイト番号は、バッファの連続するメモリブロック内の相対的位置を示すものであり、バッファが配置されるＲＡＭ内の絶対的メモリアドレス又は位置を示すものではない。

【0059】

上述したように、初期化されたバッファ及びハッシュテーブルは、同じＴＳＩ値のパケットを有する受け取られたＬＣＴチャネルに対応する。この図５Ａ及び図５Ｂの例では、選択されたサービスが、３つのＬＣＴチャネルを定めるＲＯＵＴＥセッションを含む。この例では、サービスのビデオコンポーネントのファイルが、ＴＳＩ値４４３に関連するＬＣＴチャネルで伝送されて、図５Ａの初期化済みバッファにバッファリングされる。いくつかの実施形態では、ＴＳＩ値がハッシュテーブル識別子に含まれる。

【0060】

図６Ａ及び図６Ｂに、ファイルに関するシグナリングを受け取って処理することによって導出された「ｃｈ４－２－ｖ００３９２．ｍｐ４」という名前のビデオＤＡＳＨメディアセグメントファイルに関する情報に基づいてプロセス３００を実行した結果を示す。１つの実施形態では、シグナリングが、選択されたサービスに関連するＳ－ＴＳＩＤにおいて見出される、Ａ／３３１標準による拡張ファイル配信テーブル（Ｅｘｔｅｎｄｅｄ Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｔａｂｌｅ：ＥＦＤＴ）である。図６Ａの例示的な実施形態では、このファイルを搬送するパケットがバッファに記憶され始めている。

【0061】

ファイルｃｈ４－２－ｖ００３９２．ｍｐ４に対応する最初に受け取られるパケットについては、ハッシュテーブルが依然として図５Ｂの初期化状態にあり、ファイルｃｈ４－２－ｖ００３９２．ｍｐ４と同じＴＯＩ番号を有する不完全なエントリが存在しないので、ステップＳ３４の判定はＮＯである。バッファは図５Ａの初期化状態にあるので、新規ファイル動作４００では、ステップＳ４１において、ファイルがバッファ内の残りスペースに収まると判定される。図６Ｂには、ファイルの受信前の次の開始位置ポインタの位置であったバイト０にファイルの最初のバイトが記憶されており、ファイルの長さが５，０００，０００バイトであることを示す、このファイルの新規エントリの作成を示す。

【0062】

図６Ａには、（ＴＯＩ＝３９２によって示す）バッファ内の領域が新規ファイルに割り当てられて、次の開始位置の位置が割り当て領域の最後（すなわち、バイト５，０００，０００）に移動したバッファの状態を示す。割り当て領域の網掛け部分は、ファイルを搬送するいくつかのパケットが受け取られてバッファに記憶されたが、未だファイルが完全でない状態を示す。

【0063】

図６Ｂに示すように、最初に、ファイルに関連する全てのバイトが取り出されるまでは、シグナリングで（例えば、ＥＦＤＴ．ＦＤＴ－Ｉｎｓｔａｎｃｅ，Ｆｉｌｅ＠Ｃｏｎｔｅｎｔ－Ｌｏｃａｔｉｏｎで）受け取られたファイル名文字列が、「．ｎｅｗ」が添付された状態でハッシュテーブルに保存される。「．ｎｅｗ」の存在は、ハッシュテーブルのエントリを不完全なものとして示す方法であり、バッファ内の受信が不完全なファイルをハッシュテーブル内のエントリが表していることを示す。ファイルの受信が完了していないことを示すには、別の識別子を添付し、又はハッシュテーブルに別のパラメータを追加することもできる。

【0064】

従って、図６Ｂのハッシュテーブルは、この時点でこのファイルの不完全なエントリを含んでいるので、ファイルを搬送する全ての後続の（すなわち、最初に受け取られたものではない）パケットの処理では、ステップＳ３４において、一致するＴＯＩを有するハッシュテーブル内の不完全なエントリが見つかる。従って、ファイルを搬送する後続の受信パケットは、ステップＳ３６に従って、図６Ａに示す割り当て領域に記憶される。

【0065】

ファイルの最後のバイトが受け取られると、ハッシュテーブル内でファイル名の「．ｎｅｗ」部分が削除され、最初のバイトの記録位置においてファイルにアクセスできるようになる。ファイル名の「．ｎｅｗ」部分が削除されることによってファイルに完全とのラベルが付けられると、ハッシュテーブル内に同じファイル名の別のエントリが存在するかどうかを調べるチェックが行われる。複製物が見つかった場合には、上述したようにハッシュテーブル内の同じファイル名を有する以前のエントリが削除される。１つの実施形態では、新バージョンのファイルが旧バージョンとは異なるＴＯＩ番号を有する。

【0066】

図７Ａ及び図７Ｂの例示的な実施形態では、第１のファイル（ｃｈ４－２－ｖ００３９２．ｍｐ４）の受け取りが完全に完了しており、このことは、ファイル名の最後に「．ｎｅｗ」が存在せず、バイト０～５，０００，０００の割り当てバッファ領域が完全な網掛け状態であることによって示される。例えばＥＦＤＴを解析することによって、第２のファイルに関する情報が発見されている。

【0067】

第２のファイルの最初の受信パケットについても、上記と同様にプロセス３００が実行される。第２のファイルの長さは、７，０００バイトとして伝えられる。第２のファイルの最初の受信パケットについては、ステップＳ３４における回答がＮＯであり、新規ファイル動作４００が実行される。ステップＳ４１において、第２のファイルの７，０００バイトが、全てバッファの最後を越えることなくバッファ内に収まると判定される。ステップＳ４６において、新規ファイルの範囲がハッシュテーブル内のいずれのファイルにも重なり合わないと判定される。従って、第２のファイルに対応するエントリがハッシュテーブルに追加される。図７Ｂには、第２のファイルが完全に受け取られた後のハッシュテーブルの状態を示しており、従って第２のファイルに対応するエントリはファイル名の最後の「．ｎｅｗ」で不完全としてラベル付けされていない。第２のファイルの最初のバイトは、図６Ａに示すように第２のファイルを受け取る前の次の開始位置ポインタの位置であったバイト５，０００，０００に存在する。図７Ａに示すように、第２のファイルにバッファスペースを割り当てた後には、次の開始位置ポインタの位置が、第２のファイルに割り当てられたバッファスペースの最後であるバイト５，００７，０００に移動する。

【0068】

第２のファイル「ｃｈ４－２－ｖ－ｉｎｉｔ．ｍｐ４」は、サービスのビデオエレメンタリストリーム要素のための初期化ファイル（すなわち、初期化セグメント）である。いくつかの実施形態では、何時でもストリームに参加する可能性がある受信装置へのアクセスを容易にするために、このような初期化ファイルがパケットストリーム内で頻繁に繰り返される。いくつかの実施形態では、初期化ファイルの利用可能性を常に確実にするために、バッファのサイズが、いかなる時点でも初期化ファイルを記憶できるほど十分に大きく設定される。例えば、バッファのサイズは、初期化ファイルの繰り返し率及びファイルストリームの他の要因を考慮して、次の初期化ファイルが受け取られてバッファに記憶される際に以前に受け取られた初期化ファイルがまだ上書きされていないようなサイズに設定することができる。いくつかの実施形態では、受信機を、着信放送ファイルのサイズに基づいてバッファサイズを動的に変化させるように構成することができる。いくつかの実施形態では、初期化ファイルをメモリの別の部分に移動させることによって、初期化ファイルが常に利用可能であって上書きされないことを保証することができる。

【0069】

次に、この例示的な実施形態では、放送ストリーム内で第３のファイルに関連するパケットが発見されて処理される。第３のファイルは、「ｃｈ４－２－ｖ００３９３．ｍｐ４」という名称の後続のビデオメディアセグメントである。長さは、４，０００，０００バイトとして伝えられる。ファイルｃｈ４－２－ｖ００３９３．ｍｐ４に対応する最初に受け取られるパケットについては、ハッシュテーブルが依然として図７Ｂの状態にあり、ファイルｃｈ４－２－ｖ００３９３．ｍｐ４と同じＴＯＩ番号を有する不完全なエントリが存在しないので、ステップＳ３４の判定はＮＯである。バッファは図７Ａに示す状態にあり、次の開始位置ポインタとバッファの最後との間のスペースは第３のファイルの４，０００，０００バイト長よりも大きいので、新規ファイル動作４００では、ステップＳ４１において、第３のファイルがバッファの残りスペースに収まると判定される。また、ステップＳ４６において、この新規ファイルの範囲はハッシュテーブル内のいずれのファイルにも重なり合わないと判定される。図８Ｂに、第３のファイルの受信前の図７Ａの次の開始位置ポインタの位置であったバイト５，００７，０００にファイルの最初のバイトが記憶されたことを示す、追加された第３のファイルの新規エントリを示す。

【0070】

図８Ａには、（ＴＯＩ＝３９３によって示す）バッファ内の領域が新規ファイルに割り当てられて、次の開始位置の位置が割り当て領域の最後（すなわち、バイト９，００７，０００）に移動したバッファの状態を示す。割り当て領域の網掛け部分は、ファイルを搬送するいくつかのパケットが受け取られてバッファに記憶されたが、未だファイルが完全でない状態を示す。

【0071】

従って、図８Ｂのハッシュテーブルは、この時点でこのファイルの不完全なエントリを含んでいるので、第３のファイルを搬送する全ての後続の（すなわち、最初に受け取られたものではない）パケットの処理では、ステップＳ３４において、一致するＴＯＩを有するハッシュテーブル内の不完全なエントリが見つかる。従って、第３のファイルを搬送する後続の受信パケットは、図８Ａに示す割り当て領域にステップＳ３６に従って記憶される。

【0072】

次に、この例示的な実施形態では、本実施形態のバッファ及びハッシュテーブルに対応するＬＣＴチャネル（ＴＳＩ＝４４３）において、第２のファイル（ｃｈ４－２－ｖ－ｉｎｉｔ．ｍｐ４）の反復インスタンスを搬送するパケットが発見される。この新規ファイルは、そのファイル名が第２のファイルのものと同じであって、両ファイルのＴＳＩ／ＴＯＩ値も同じであるため、第２のファイルの繰り返しであると識別される。新たに受け取られたファイルが第２のファイルの更新バージョンである場合には、ファイル名は同じであるがファイルのＴＯＩ番号が異なる。

【0073】

それにもかかわらず、１つの実施形態では、この新規ファイルの最初の受信パケットについてプロセス３００が実行される。第２のファイルの長さは、７，０００バイトとして伝えられる。第２のファイルの最初の受信パケットについては、新規ファイルと同じＴＯＩ番号（すなわち、２）を有するハッシュテーブルエントリに不完全とのラベルが付けられていないので、ステップＳ３４における回答はＮＯであり、従って新規ファイル動作４００が実行される。

【0074】

上述したように、受信機のいくつかの実施形態は、繰り返される初期化ファイルの利用可能性を常に必要とする。後述するように、このような実施形態では、初期化ファイルの新たな各コピーが受け取られてバッファリングされ、以前にバッファリングされた複製物が削除される。別の実施形態では、ファイルの利用可能性を確実にするために、初期化ファイルをバッファ外の別のメモリ部分に移動させることができる。初期化ファイルの利用可能性を常に必要としない他の実施形態では、重複する受信ファイルが記憶されず、同じＴＯＩ番号を有するハッシュテーブルエントリに対応する以前にバッファリングされたファイルが保持される。他の実施形態では、受信ファイルが不要であって受信装置によって読み出されないとの判定に応答して、重複する受信ファイルが記憶されない。

【0075】

ステップＳ４１において、第２のファイルの７，０００バイトが、全てバッファの最後を越えることなくバッファ内に収まると判定される。ステップＳ４６において、新規ファイルの範囲が、既にハッシュテーブル内に存在するいずれのファイルにも重なり合わないと判定される。従って、新規ファイルに対応するエントリが、第４のエントリとしてハッシュテーブルに追加される。図９Ｂには、新規ファイルのいくつかのパケットが受け取られた後のハッシュテーブルの状態を示すが、未だ全てのバイトが受け取られたわけではなく、従って新規ファイルに対応するエントリはファイル名の最後の「．ｎｅｗ」で不完全としてラベル付けされていない。図８Ａに示すように、新規ファイルの最初のバイトは、第２のファイルを受け取る前の次の開始位置ポインタの位置であったバイト９，００７，０００に存在する。

【0076】

図９Ａに示すように、新規ファイルにバッファスペースを割り当てた後には、次の開始位置ポインタの位置が、割り当てられたバッファスペースの最後であるバイト９，０１４，０００に移動する。繰り返されるｃｈ４－２－ｖ－ｉｎｉｔ．ｍｐ４ファイルの最後のバイトが受け取られた時点で、上述したようにハッシュテーブル内の各エントリがチェックされて、既にハッシュテーブル内に同じ名前のファイルが存在するかどうかが判定され、ハッシュテーブル内の識別された以前のエントリが削除される。

【0077】

図１０Ａに、繰り返されるｃｈ４－２－ｖ－ｉｎｉｔ．ｍｐ４ファイルが完全に受け取られてバッファに記憶される例示的な実施形態を示す。繰り返されるｃｈ４－２－ｖ－ｉｎｉｔ．ｍｐ４ファイルが完了すると、図９Ｂのハッシュテーブル内の第２のエントリは、新たに受け取られたファイルの複製物として識別される。従って、図１０Ｂに示すように、このファイルの最初のインスタンスは削除される。この時点で、例示的な実施形態では、受信装置がファイルｃｈ４－２－ｖ－ｉｎｉｔ．ｍｐ４を参照する必要がある場合、ハッシュテーブルは、このファイルがバッファのバイト９，００７，０００から開始して記憶されていることを示し、受信装置は、受け取られた最新のファイルのコピーを参照するようになる。

【0078】

図１０Ａでは、ｃｈ４－２－ｖ－ｉｎｉｔ．ｍｐ４ファイルの最初のコピーを記憶していたバッファの領域（すなわち、バイト５，０００，０００とバイト５，００７，０００との間の領域）を、このファイルのバイトがバッファに残っていることを示すように（前回と同様に）網掛けで示す。バイトは消去されていないが、ハッシュテーブルには単純にこのバッファ領域への参照が存在しない。

【0079】

次に、図１１Ａ及び図１１Ｂの例示的な実施形態では、第３のメディアセグメントファイル（ｃｈ４－２－ｖ００３９４．ｍｐ４）及び別の初期化セグメント（ｃｈ４－２－ｖ－ｉｎｉｔ．ｍｐ４）が受け取られてバッファリングされている。上述したように、新規ファイル動作４００のステップＳ４１では、新規着信ファイルの最初のパケットに遭遇する度に、次の開始位置から開始するバッファに完全なファイルが収まるかどうかの判定が行われる。図１１Ａに示すように、これらの２つの新規ファイルはバッファ内の残りスペースに収まり、従って各ファイルについてのステップＳ４１における回答はＹＥＳである。また、これらのファイルの範囲は、ハッシュテーブルに記憶された他のいずれのファイルにも重なり合わず、従ってステップＳ４６における回答はＮＯである。また、上述したように、繰り返される初期化セグメント（又はいずれかの繰り返されるファイル）を受け取ることは、新たな繰り返されるファイルを完全に受け取る際に、以前に受け取られたファイルのエントリをハッシュテーブルから削除することを伴う。この例示的な実施形態では、ハッシュテーブルが順序付けられておらず、従ってハッシュテーブル内のあらゆる位置に対してエントリの追加及び削除を行うことができる。

【0080】

図１１Ａの例示的な実施形態では、バッファがほぼ満杯である。この例示的な実施形態では、第４のメディアセグメントファイルのパケットが見つかり、ＥＦＤＴは、このファイルが５，５００，０００バイトの長さを有することを示す。第４のファイルの最初の受信パケットについては、新規ファイルと同じ名前及び同じＴＯＩ番号（すなわち、３９５）を有する、或いはいくつかの実施形態では同じＴＯＩ番号のみを有するエントリがハッシュテーブル内に存在しないので、ステップＳ３４における回答はＮＯであり、従って新規ファイル動作４００が実行される。

【0081】

しかしながら、この例示的な実施形態では、ステップＳ４１において、ファイルがバッファ内の残りスペースに収まらないと判定される。この判定が行われる理由は、本実施形態では１５，０２１，０００バイトに存在する次の開始位置ポインタの位置に５，５００，０００バイトであるファイル長さが追加されると、２０，０００，０００バイトのバッファサイズを超えるからである。従って、ステップＳ４３のスペース作成動作が実行されてスペースが作成される。

【0082】

ステップＳ４２から開始するスペース作成動作は、バッファ内の古いファイルが有用性を失っており、従ってこれらを廃棄できるとの認識に基づく。ステップＳ４３及びＳ４４では、ハッシュテーブル内の各エントリが検査され、着信ファイルが次の開始位置ではなく初期書き込み位置に記憶されると仮定して、対応するファイルのいずれかのバイトが着信ファイルによって占有される予定のスペースに重なり合う場合にエントリが削除される。

【0083】

この例示的な実施形態では、最初の２つのメディアセグメント（ＴＯＩ＝３９２及び３９３）が、バッファの最初の５，５００，０００バイト内に完全に又は部分的に含まれている。従って、ステップＳ４３においてハッシュテーブル内のこれらの両エントリが識別され、ステップＳ４４において削除される。その後、初期書き込み位置から開始するバッファ領域が新規ファイルに割り当てられ、新規ファイルのための新たなハッシュテーブルエントリが作成され、受信装置は、この時点でｃｈ４－２－ｖ００３９５．ｍｐ４という新規ファイルのパケットを初期書き込み位置から記憶し始めることができる。

【0084】

図１２Ａの例示的な実施形態では、新規ファイルが受け取られてバッファリングされている最中である。図１２Ａには、ハッシュテーブルエントリが削除されたいくつかのファイル又はその一部のバイトが新規ファイルの受信パケットによって上書きされるまでバッファ内に存在することを反映するように、これらのファイルを示す。図１２Ｂには、ステップＳ４３で識別されたメディアセグメントファイルが削除され、２つの以前に追加されたファイルが残っており（ＴＯＩ＝２及び３９４）、新規ファイルであるｃｈ４－２－ｖ００３９５．ｍｐ４が「．ｎｅｗ」というファイル名の拡張子で不完全として示されている、対応するハッシュテーブルの図を示す。

【0085】

この例を続けると、図１３Ａ及び図１３Ｂの例示的な実施形態には、長さが２，０００，０００バイトである別のメディアセグメントファイルの到着を示す。この新規ファイルは、バイト５，５００，０００における次の開始位置ポインタとバッファの最後との間のバッファスペースに収まり、従ってステップＳ４１における回答はＹＥＳである。次に、この新規ファイルは、バイト５，５００，０００における次の開始位置ポインタと、オフセット９，０１４，０００に記憶されたファイルの開始との間のバッファスペースに収まると判定され、従ってステップＳ４６における回答はＮＯである。図１３Ａにはバッファを示し、図１３には新規ファイルが完全に記憶された後のハッシュテーブルを示す。

【0086】

次に、図１４Ａ及び図１４Ｂの例示的な実施形態では、長さが５，０００，０００バイトであるメディアセグメントファイルに遭遇している。 このファイルは、バッファ内に収まる（例えば、次の開始位置＋５，０００，０００の値が２０，０００，０００を超えない）が、ファイルの範囲（次の開始位置＋５，０００，０００）がファイルｃｈ４－２－ｖ００３９４．ｍｐ４に割り当てられたスペースに重なり合うので、ステップＳ４６の判定の回答はＮＯである。従って、ステップＳ５０において、ファイルｃｈ４－２－ｖ００３９４．ｍｐ４がハッシュテーブルから削除される。図１４Ａには、新規ファイルｃｈ４－２－ｖ００３９７．ｍｐ４が部分的に記憶された時のバッファを示す。図１４Ｂには、ファイルｃｈ４－２－ｖ００３９４．ｍｐ４が削除され、新規ファイルｃｈ４－２－ｖ００３９７．ｍｐ４に不完全とのラベルが付けられた、図１４Ａに対応するハッシュテーブルの状態を示す。

【0087】

上述した例示的な実施形態を要約すると、ファイルに対応する受信パケットの処理は、最初にファイルのＬＣＴチャネルに対応するハッシュテーブル内のエントリを通じて反復し、ＴＯＩ／ファイル名の一致を検索することである。一致が見つかってファイル名に不完全とのラベルが付いている場合、受信パケットは、このファイルを記憶する予定であるメモリ領域内の適切な位置に記憶される。パケットの位置は、ファイルの最初に対するパケットの位置を示す、パケットに含まれるオフセットによって決定される。バッファに記憶されたファイルがパケットによって完成する場合、ハッシュテーブル内のファイルのエントリから「不完全」ラベルが削除され、同じファイルに対応するハッシュマップ内のいずれかの以前のエントリが削除される。ＴＯＩ／ファイル名の一致が見つからない場合には、「新規ファイル開始」動作が実行される。

【0088】

新規ファイル開始動作の例示的な実施形態は、最初にバッファ内の残りスペースにファイルが収まるかどうかを判定することとして要約することができる。次の開始位置＋ファイル長であるファイルの範囲がバッファのサイズを超える場合、回答はＮＯであり、この場合は「スペース作成」動作が実行される。そうでなければ、回答はＹＥＳである。新規ファイルがバッファ内の残りスペースに収まると判定された場合には、次の開始位置＋ファイル長である新規ファイルの範囲が、ハッシュテーブルにリストされたいずれかのファイルに重なり合うかどうかが判定される。重なり合う場合、このようなファイルは削除される。その後、次の開始位置における新規ファイルの割り当てバッファ領域を示す新規エントリがハッシュテーブル内で作成され、次の開始位置が割り当てバッファ領域の最後に移動され、ファイルの最初のバイト位置に対するバッファ内の対応する位置にパケットが記憶される。新規ファイルがその断片を含むパケットによって完成しない場合には、ハッシュテーブル内に作成された新規エントリに不完全とのラベルが付けられる。新規ファイルがバッファ内の残りスペースに収まらないと判定された場合には、スペース作成動作が実行される。

【0089】

例示的な実施形態では、「スペース作成」動作が、ハッシュテーブル内の各エントリについて、エントリに対応するそれぞれのファイルが、初期書き込み位置から開始して新規ファイルの長さに及ぶ新規ファイルの範囲に重なり合うかどうかを判定する。所与のハッシュテーブルエントリによって占められるバッファ領域は、エントリの最初のバイト位置及びファイル長に基づいて決定することができる。

【0090】

スペース作成動作の例示的な実施形態では、新規ファイルの範囲に重なり合うことが判明したハッシュテーブル内のエントリがいずれもハッシュテーブルから削除され、ハッシュテーブル内に新規ファイルのためのエントリを作成することを含め、初期書き込み位置から開始するバッファ領域が新規ファイルに割り当てられる。未だファイルの全てのバイトが受け取られていない場合、ハッシュテーブル内の新規エントリには不完全とのラベルが付けられる。

【0091】

新規ファイル開始動作の例示的な実施形態におけるバッファスペースの割り当て後、次の開始位置は割り当てバッファスペースの最後に移動し、新規ファイルに属する受信パケットは、上述したようにそのオフセットに従って割り当てバッファスペース内に配置される。

【0092】

上述した着信パケットを処理する例示的な実施形態は、ファイルのパケットが順番に受け取られない場合にも、ファイルを正しく受け取ってバッファリングすることができる。例えば、ファイルによっては、ファイルの内容を配信するパケットが一定期間にわたって連続的に繰り返される「カルーセル」で放送されるものもある。このような実施形態では、１日を通して５分のスパンで大容量ファイルが繰り返されることがある。受信装置が初めてチューニング行う場合、受信装置によって受け取られる最初のパケットがファイルの最初のバイトを含む可能性は低い。しかしながら、上述した実施形態によれば、受信装置は、たとえ受け取った最初のパケットがファイルの最初のパケットでない場合でもファイルをバッファリングすることができる。

【0093】

この機能性が達成される理由は、ＡＴＳＣ Ａ／３３１標準による各トランスポートパケットが各ＬＣＴパケット内にｓｔａｒｔ＿ｏｆｆｓｅｔと呼ばれるフィールドを含むからである。例示的な実施形態で上述したように、受信装置は、このオフセットフィールドを使用して、いずれかのパケットのバイトをファイルの最初のバイトのバッファ内位置に対してバッファ内のどこに記憶すべきかを決定する。従って、ファイルのパケットが受け取られると、たとえパケットが順不同で受け取られた場合でも、これらのパケットは、そのファイルに割り当てられたバッファ領域内に正しい順序で配置され、最終的に割り当て領域がパケットで満たされてバッファ内でファイルが再構成されるようになる。

【0094】

図１５は、受信装置及びサービス配信システムのいずれか一方又はこれらの組み合わせの機能を実行するように構成できるコンピュータのハードウェア構成の例を示すブロック図である。例えば、１つの実施形態では、コンピュータが、本明細書で受信装置１２０に関して説明した機能のうちの１つ又はこれらの組み合わせを実行するように構成される。

【0095】

図１５に示すように、コンピュータは、１又は２以上のバス１２０８を介して互いに相互接続されたＣＰＵ１２０２、ＲＯＭ（リードオンリメモリ）１２０４及びＲＡＭ（ランダムアクセスメモリ）１２０６を含む。１又は２以上のバス１２０８は、入力－出力インターフェイス１２１０にさらに接続される。入力－出力インターフェイス１２１０は、キーボード、マウス、マイク、リモコン装置などによって形成される入力部１２１２に接続される。入力－出力インターフェイス１２１０は、オーディオインターフェイス、ビデオインターフェイス、ディスプレイ及びスピーカなどによって形成される出力部１２１４、ハードディスクによって形成される記録部１２１６、不揮発性メモリ又はその他の非一時的コンピュータ可読記憶媒体、ネットワークインターフェイス、モデム、ＵＳＢインターフェイス、ファイアワイヤインターフェイスなどによって形成される通信部１２１８、並びに磁気ディスク、光学ディスク、磁気－光学ディスク、半導体メモリなどの取り外し可能媒体１２２２を駆動するドライブ１２２０にも接続される。

【0096】

１つの実施形態によれば、ＣＰＵ１２０２は、記録部１２１６に記憶されたプログラムを入力－出力インターフェイス１２１０及びバス１２０８経由でＲＡＭ１２０６にロードした後に、本明細書において受信装置１２０に関して説明した機能のうちの１つ又はこれらの組み合わせの機能を提供するように構成されたプログラムを実行する。

【0097】

図２及び図１５に示す構造例のうちのいずれか１つによって例示される上述したハードウェアの説明は、例えば図３及び図４を参照して上述したアルゴリズムを実行するようにプログラム又は構成された専門的な対応する構造を構成し又は含む。例えば、図３及び図４に示すアルゴリズムのうちのいずれか１つ又はこれらの組み合わせは、図２に示す単一の装置に含まれる回路によって完全に実行することができる。

【0098】

上記の教示に照らして、数多くの修正例及び変形例が可能なことが明らかである。従って、添付の特許請求の範囲内では、本明細書において具体的に説明したものとは別様に本開示を実施することができると理解されたい。

【0099】

従って、上記の説明は、本開示の例示的な実施形態を開示して説明したものにすぎない。当業者であれば理解するように、本開示は、本開示の趣旨又は基本的特徴から逸脱することなく他の特定の形態で具体化することもできる。従って、本開示は例示であることを意図するものであり、本開示及び他の請求項の範囲を限定するものではない。本開示は、本明細書における教示のあらゆる容易に識別できる変種を含め、本発明の主題が一般公衆に開放されないように、上述した請求項の用語の範囲を部分的に定義する。

【0100】

本開示の実施形態は、以下のような著しく有利な特徴を含む。
（１）ストリーミングマルチキャスト配信メディアデータの受信のために最適化されたバッファリング法。
（２）処理が、Ｊａｖａプログラミング言語の利点及び限界を考慮するように、具体的にはメモリリークを招く恐れがあるガベージコレクション動作に関連する非効率性及び不確実性を避けるように設計される。
（３）Ｊａｖａのバイト配列は断片に分割できないので、いずれか１つのファイルが複数の連続バイト配列を占有しないように処理が最適化される。
（ａ）処理が、バイト配列のみに作用するＳｙｓｔｅｍ．ａｒｒａｙＣｏｐｙネイティブＡｎｄｒｏｉｄ機能を採用してメモリのブロックを効率的に移動させるように設計される。
（ｂ）一般に、この処理はＡｎｄｒｏｉｄ上のＪａｖａのために最適化される。
（４）処理の最適化が以下を含む。
（ａ）ファイルが連続メモリに記憶されない場合に生じる複雑性及びＣＰＵオーバヘッドを避けるために、ファイルを連続バッファ領域に記憶すること。
（ｂ）不要なファイルのコピーを避けること。
（ｃ）重複ファイルの効率的処理。
（ｄ）新規ファイルの記憶に使用されるメモリの回復の効率的管理。
（５）処理が、順不同パケット配信モード及びカルーセルファイル配信モードをサポートする。

【0101】

上記の開示は、以下に列挙する実施形態も含む。

【0102】

（１）パケットストリームを介して受け取られたファイルを記憶するための、予め設定されたバイトサイズを有するバッファを管理する方法であって、着信ファイルのファイル識別子及び長さを判定するステップと、前記着信ファイルが次の書き込み位置と前記バッファの最後との間のスペースに収まらないと判定するステップと、前記着信ファイルが前記次の書き込み位置と前記バッファの前記最後との間の前記スペースに収まらないとの前記判定に応答して、前記バッファに記憶された１又は２以上のファイルを識別するマップにおいて、前記バッファの初期書き込み位置から開始する領域に少なくとも部分的に記憶されたファイルに対応し、かつ前記着信ファイルの前記長さに等しいサイズを有する各エントリを削除するステップと、前記着信ファイルの前記ファイル識別子及び前記長さを含むエントリを、前記バッファ内の前記初期書き込み位置に関連付けて前記マップ内に追加するステップと、前記バッファ内の前記初期書き込み位置から開始して前記着信ファイルの前記長さに等しい前記サイズを有する前記バッファ内の連続領域を割り当てた後に、前記次の書き込み位置を前記割り当てられた連続領域の前記最後に移動させるステップと、前記着信ファイルのパケットを受け取り、該受け取られたパケットを前記割り当てられた連続領域に記憶するステップとを含む方法。

【0103】

（２）前記パケットストリームは、高度テレビジョンシステムズ委員会（ＡＴＳＣ）３．０デジタルテレビ信号の一部である、特徴（１）に記載の方法。

【0104】

（３）前記着信ファイルは、前記バッファに記憶された他のファイルと共通するトランスポートセッション識別子（ＴＳＩ）値を有する階層符号化トランスポート（ＬＣＴ）チャネルで受け取られ、対応する異なるＴＳＩ値を有するファイルを記憶するために、新規バッファ及び別のマップが初期化される、特徴（１）又は（２）に記載の方法。

【0105】

（４）前記マップ内の前記追加されたエントリは、前記着信ファイルの前記ファイル識別子及び前記長さを含む、特徴（１）～（３）のいずれかに記載の方法。

【0106】

（５）前記着信ファイルの前記受け取られたパケットが、前記ファイルに割り当てられた前記バッファ内の前記連続領域を満たすまで、前記マップ内の前記追加されたエントリに不完全とのラベルを付けるステップをさらに含む、特徴（１）～（４）のいずれかに記載の方法。

【0107】

（６）前記パケットストリームの各着信パケットについて、対応するファイルのファイル識別子を判定するステップと、前記対応するファイルの前記ファイル識別子を有し、かつ不完全とのラベルが付いた前記マップ内のエントリが存在するかどうかを判定するステップと、前記対応するファイルの前記ファイル識別子を有する前記マップ内の不完全なエントリが存在するとの判定に応答して、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域に前記着信パケットを記憶するステップと、前記着信パケットが、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域において前記ファイルを完成させるかどうかを判定するステップと、前記着信パケットが、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域において前記ファイルを完成させるとの判定に応答して、前記マップ内の前記エントリに関連する前記不完全ラベルを削除するステップと、前記マップ内の前記エントリと同じファイル名を有する前記マップ内の他の全てのエントリを削除するステップと、前記対応するファイルの前記ファイル識別子を有する前記マップ内の不完全なエントリが存在しないとの判定に応答して、前記着信パケットを新規着信ファイルとして処理するステップとをさらに含む、特徴（１）～（５）のいずれかに記載の方法。

【0108】

（７）前記ファイル識別子は、トランスポートオブジェクト識別子（ＴＯＩ）及びファイル名を含む、特徴（１）～（６）のいずれかに記載の方法。

【0109】

（８）パケットストリームを介して受け取られたファイルを、予め設定されたバイトサイズを有するバッファに記憶するバッファ管理装置であって、着信ファイルのファイル識別子及び長さを判定し、前記着信ファイルが次の書き込み位置と前記バッファの最後との間のスペースに収まらないと判定し、前記着信ファイルが前記次の書き込み位置と前記バッファの前記最後との間の前記スペースに収まらないとの前記判定に応答して、前記バッファに記憶された１又は２以上のファイルを識別するマップにおいて、前記バッファの初期書き込み位置から開始する領域に少なくとも部分的に記憶されたファイルに対応し、かつ前記着信ファイルの前記長さに等しいサイズを有する各エントリを削除し、前記着信ファイルの前記ファイル識別子及び前記長さを含むエントリを、前記バッファ内の前記初期書き込み位置に関連付けて前記マップ内に追加し、前記バッファ内の前記初期書き込み位置から開始して前記着信ファイルの前記長さに等しい前記サイズを有する前記バッファ内の連続領域を割り当てた後に、前記次の書き込み位置を前記割り当てられた連続領域の前記最後に移動させ、前記着信ファイルのパケットを受け取り、該受け取られたパケットを前記割り当てられた連続領域に記憶するように構成された回路を含む、バッファ管理装置。

【0110】

（９）前記パケットストリームは、高度テレビジョンシステムズ委員会（ＡＴＳＣ）３．０デジタルテレビ信号の一部である、特徴（８）に記載のバッファ管理装置。

【0111】

（１０）前記着信ファイルは、前記バッファに記憶された他のファイルと共通するトランスポートセッション識別子（ＴＳＩ）値を有する階層符号化トランスポート（ＬＣＴ）チャネルで受け取られ、対応する異なるＴＳＩ値を有するファイルを記憶するために、新規バッファ及び別のマップが初期化される、特徴（８）又は（９）に記載のバッファ管理装置。

【0112】

（１１）前記マップ内の前記追加されたエントリは、前記着信ファイルの前記ファイル識別子及び前記長さを含む、特徴（８）～（１０）のいずれかに記載のバッファ管理装置。

【0113】

（１２）前記回路は、前記着信ファイルの前記受け取られたパケットが、前記着信ファイルに割り当てられた前記バッファ内の前記連続領域を満たすまで、前記マップ内の前記追加されたエントリに不完全とのラベルを付けるようにさらに構成される、特徴（８）～（１１）のいずれかに記載のバッファ管理装置。

【0114】

（１３）前記回路は、前記パケットストリームの各着信パケットについて、対応するファイルのファイル識別子を判定し、前記対応するファイルの前記ファイル識別子を有し、かつ不完全とのラベルが付いた前記マップ内のエントリが存在するかどうかを判定し、前記対応するファイルの前記ファイル識別子を有する前記マップ内の不完全なエントリが存在するとの判定に応答して、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域に前記着信パケットを記憶し、前記着信パケットが、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域において前記ファイルを完成させるかどうかを判定し、前記着信パケットが、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域において前記ファイルを完成させるとの判定に応答して、前記マップ内の前記エントリに関連する前記不完全ラベルを削除し、前記マップ内の前記エントリと同じファイル名を有する前記マップ内の他の全てのエントリを削除し、前記対応するファイルの前記ファイル識別子を有する前記マップ内の不完全なエントリが存在しないとの判定に応答して、前記着信パケットを新規着信ファイルとして処理するようにさらに構成される、特徴（８）～（１２）のいずれかに記載のバッファ管理装置。

【0115】

（１４）前記ファイル識別子は、トランスポートオブジェクト識別子（ＴＯＩ）及びファイル名を含む、特徴（８）～（１３）のいずれかに記載のバッファ管理装置。

【0116】

（１５）コンピュータ可読命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記コンピュータ可読命令は、プロセッサによって実行された時に、パケットストリームを介して受け取られたファイルを記憶するための、予め設定されたバイトサイズを有するバッファを管理する方法を前記プロセッサに実行させ、前記方法は、着信ファイルのファイル識別子及び長さを判定するステップと、前記着信ファイルが次の書き込み位置と前記バッファの最後との間のスペースに収まらないと判定するステップと、前記着信ファイルが前記次の書き込み位置と前記バッファの前記最後との間の前記スペースに収まらないとの前記判定に応答して、前記バッファに記憶された１又は２以上のファイルを識別するマップにおいて、前記バッファの初期書き込み位置から開始する領域に少なくとも部分的に記憶されたファイルに対応し、かつ前記着信ファイルの前記長さに等しいサイズを有する各エントリを削除するステップと、前記着信ファイルの前記ファイル識別子及び前記長さを含むエントリを、前記バッファ内の前記初期書き込み位置に関連付けて前記マップ内に追加するステップと、前記バッファ内の前記初期書き込み位置から開始して前記着信ファイルの前記長さに等しい前記サイズを有する前記バッファ内の連続領域を割り当てた後に、前記次の書き込み位置を前記割り当てられた連続領域の前記最後に移動させるステップと、前記着信ファイルのパケットを受け取り、該受け取られたパケットを前記割り当てられた連続領域に記憶するステップとを含む、非一時的コンピュータ可読記憶媒体。

【0117】

（１６）前記パケットストリームは、高度テレビジョンシステムズ委員会（ＡＴＳＣ）３．０デジタルテレビ信号の一部である、特徴（１５）に記載の非一時的コンピュータ可読記憶媒体。

【0118】

（１７）前記着信ファイルは、前記バッファに記憶された他のファイルと共通するトランスポートセッション識別子（ＴＳＩ）値を有する階層符号化トランスポート（ＬＣＴ）チャネルで受け取られ、対応する異なるＴＳＩ値を有するファイルのために、新規バッファ及び別のマップが初期化される、特徴（１５）又は（１６）に記載の非一時的コンピュータ可読記憶媒体。

【0119】

（１８）前記マップ内の前記追加されたエントリは、前記着信ファイルの前記ファイル識別子及び前記長さを含み、前記ファイル識別子は、トランスポートオブジェクト識別子（ＴＯＩ）及びファイル名を含む、特徴（１５）～（１７）のいずれかに記載の非一時的コンピュータ可読記憶媒体。

【0120】

（１９）前記着信ファイルの前記受け取られたパケットが、前記ファイルに割り当てられた前記バッファ内の前記連続領域を満たすまで、前記マップ内の前記追加されたエントリに不完全とのラベルを付けるステップをさらに含む、特徴（１５）～（１８）のいずれかに記載の非一時的コンピュータ可読記憶媒体。

【0121】

（２０）前記パケットストリームの各着信パケットについて、対応するファイルのファイル識別子を判定するステップと、前記対応するファイルの前記ファイル識別子を有し、かつ不完全とのラベルが付いた前記マップ内のエントリが存在するかどうかを判定するステップと、前記対応するファイルの前記ファイル識別子を有する前記マップ内の不完全なエントリが存在するとの判定に応答して、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域に前記着信パケットを記憶するステップと、前記着信パケットが、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域において前記ファイルを完成させるかどうかを判定するステップと、前記着信パケットが、前記マップ内の前記不完全なエントリに関連する前記割り当てられた連続領域において前記ファイルを完成させるとの判定に応答して、前記マップ内の前記エントリに関連する前記不完全ラベルを削除するステップと、前記マップ内の前記エントリと同じファイル名を有する前記マップ内の他の全てのエントリを削除するステップと、前記対応するファイルの前記ファイル識別子を有する前記マップ内の不完全なエントリが存在しないとの判定に応答して、前記着信パケットを新規着信ファイルとして処理するステップとをさらに含む、特徴（１９）に記載の非一時的コンピュータ可読記憶媒体。

【符号の説明】

【0122】

４００：新規ファイル開始動作
Ｓ４０：新規ファイル動作を開始
Ｓ４１：ファイルがバッファ内の残りスペースに収まるか？
Ｓ４２：スペース作成動作
Ｓ４３：新規ファイルの範囲に重なり合うハッシュテーブル内の全てのエントリを識別
Ｓ４４：識別された全てのエントリをハッシュテーブルから削除Ｓ４５：初期書き込み位置に新規ファイルのためのバッファ内領域を割り当て
Ｓ４６：新規ファイルの範囲がハッシュテーブル内のファイルに重なり合うか？
Ｓ４７：現在の次の開始位置に新規ファイルのためのバッファ内領域を割り当て
Ｓ４８：次の開始位置を割り当て領域の最後に移動
Ｓ４９：割り当て領域にパケットを記憶
Ｓ５０：新規ファイルの範囲に重なり合うハッシュテーブル内のエントリを削除

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図6A】

【図6B】

【図7A】

【図7B】

【図8A】

【図8B】

【図9A】

【図9B】

【図10A】

【図10B】

【図11A】

【図11B】

【図12A】

【図12B】

【図13A】

【図13B】

【図14A】

【図14B】

【図15】

【国際調査報告】