(57)【要約】クリティカル・データの損失を最小にする方法及びシステムが、記録媒体に書き込まれている（図１Ａ、３２）。クリティカル・デジタルデータが、小さなブロック又はセグメントでデジタル記録媒体に書き込まれている（図１Ａ、２０）。前記セグメントは記憶媒体に転送されると、ファイルアロケーションテーブルが更新され、ファイルが閉じられる（図１Ａ、２４）。ファイルをより小さなファイルセグメントにセグメントすることによって、システム故障又は電源損失の結果として失われるクリティカル・データ量は低減される。再生中、ファイルセグメントは、動的に組み立てられ、デジタルデータの再生を連続的な方法で可能にする。
2005527044.tif 000002
【特許請求の範囲】
【請求項１】
電源の損失から生じるデータ損失のリスクを最小にするデータ記録システムであって、
データを記録するための記録サブシステムであって、所定のデータブロックを複数のセグメントされたファイルに記録し、セグメントされたファイルの各々がロードされた後に前記セグメントされたファイルを閉じるシステムを含む記録サブシステムを備えているデータ記録システム。
【請求項２】
サイズによって定義される前記セグメントされたファイルを組立てて、所定の標準的なメディアプレーヤーで前記セグメントされたファイルを同期再生するための時間を記録する再生サブシステムをさらに含んでいる請求項１に記載のデータ記録システム。
【請求項３】
前記記録システムは、セグメントのファイルサイズをユーザ定義できるようにするシステムを含んでいることを特徴とする請求項１に記載のデータ記録システム。
【請求項４】
サイズは、長さに対応することを特徴とする請求項３に記載のシステム。
【請求項５】
サイズは、記録時間に対応することを特徴とする請求項３に記載のシステム。
【請求項６】
前記記録システムは、複数チャンネル記録システムであることを特徴とする請求項１に記載のシステム。
【請求項７】
前記記録システムは、各々のチャンネルを識別する上位レベルディレクトリを作成することを特徴とする請求項６に記載のシステム。
【請求項８】
チャンネル数は、ユーザ定義されることを特徴とする請求項６に記載のシステム。
【請求項９】
前記記録サブシステムは、デフォルトファイル名が上位レベルディレクトリにおける各々の前記ファイルに提供されることを特徴とする請求項７に記載のシステム。
【請求項１０】
前記記録サブシステムは、前記上位レベルディレクトリのファイル名をユーザ特定できるようにすることを特徴とする請求項７に記載のシステム。
【請求項１１】
前記記録システムは、セッションファイルそれぞれがタイムスタンプされる第１レベルサブディレクトリを含み、別々の記録セッションに対応することを特徴とする請求項７に記載のシステム。
【請求項１２】
前記ファイルは、実際のファイルセグメントに対するポインタとして指定されることを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記セッションファイルは、記録セッション開始時間を含むように指定されることを特徴とする請求項１１に記載のシステム。
【請求項１４】
各記録セッションファイルに対する１又は複数のセグメントファイルを作成するためにデータ収集フィルタをさらに含んでいる請求項１１に記載のシステム。
【請求項１５】
前記セグメントファイルのサイズは、ユーザ定義されていることを特徴とする請求項１４に記載のシステム。
【請求項１６】
セグメントされたデータファイルを再生するためのデータ再生システムであって、
ファイル内のファイルセグメントのファイルリストに基づいてセグメントされたビデオファイルを組立てるシステムを備えているデータ再生サブシステム。
【請求項１７】
前記データ再生サブシステムは、リアルタイムで前記ファイルのセグメントを再生するように構成されていることを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記再生サブシステムは、複数のデータチャンネルを再生するように構成されていることを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記再生サブシステムは、フォルダ／サブフォルダの指定する規則に基づいてセグメントされたファイルをソートするように構成されていることを特徴とする請求項１７に記載のシステム。
【請求項２０】
前記再生サブシステムは、コンテナによってセグメントされたファイルをソートし、チャンネルコンテナを作成するように構成されていることを特徴とする請求項１９に記載のシステム。
【請求項２１】
前記再生サブシステムは、セッション構成を作成してセッションによって前記チャンネルコンテナの前記セグメントされたファイルをソートするように構成されていることを特徴とする請求項２０に記載のシステム。
【請求項２２】
前記再生サブシステムは、最後に変更される時間までにセッションコンテナからセグメントされたファイルをソートするように構成されていることを特徴とする請求項２１に記載のシステム。
【請求項２３】
前記再生サブシステムは、正確な開始と停止の時間を用いてセグメントされたファイルのファイルリストを構築するように構成されていることを特徴とする請求項２２に記載のシステム。
【請求項２４】
前記再生はメディアプレーヤーを含んでいることを特徴とする請求項２２に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、記憶媒体にクリティカル・デジタルデータを記録するシステム及び方法に関し、より詳細には、システム故障の結果としてのクリティカル・データの損失を低減するためにクリティカル・データがセグメントで記憶媒体に書き込まれる一方で、クリティカル・データは記憶媒体及び再生システムに書き込まれ、セグメントがリアルタイムで再生されるシステム及び方法に関する。
【背景技術】
【０００２】
【特許文献１】米国特許番号６，３８５，００６
【特許文献２】米国特許番号６，３６６，９８０
【特許文献３】米国特許番号６，３４１，３１８
【特許文献４】米国特許番号６，３５６，９０１
【特許文献５】米国特許番号６，３８４，９９７
【０００３】
様々なタイプの記憶媒体にデータを書き込むための様々なシステムが知られている。典型的なタイプの記憶媒体は、例えば、公的所有されている特許文献１に開示されるようなディスクドライブである。前記記憶媒体にデータを書き込むためのシステムの例は、特許文献２、特許文献３、特許文献４、及び特許文献５に開示されている。前記システムは、カラー動画像データ圧縮標準規格（ＭＰＥＧ）フォーマット；ビデオ及びオーディオ圧縮の一般規格のような様々なフォーマットのストリーミングデジタルデータを含むデジタルデータを記録することは周知である。
【０００４】
コンピュータオペレーティングシステムは、１つのファイル又は複数のファイルを開いて、データが記憶媒体へ及び記憶媒体から転送されるようにそのファイルを更新することは周知である。より詳細には、周知のオペレーティングシステムは、各ファイルが変更されると共に更新されるファイル・アロケーション・テーブル（ＦＡＴ）を利用している。ファイルは、データ転送が完了する時に閉じられる。万一、ファイルが閉じられる前にシステム故障又は電源損失が起こる場合には、ファイルに関連するデータは、通常は失われる。それゆえ、ビデオ及び／又はオーディオデータのようなクリティカル・データは、記憶媒体に書き込まれている間に失われ得る。従って、前記データが記憶媒体に書き込まれている際のシステム故障の結果としてのクリティカル・データの損失を低減するシステムが必要である。
【発明の開示】
【課題を解決するための手段】
【０００５】
本発明は、前記データが記憶媒体に書き込まれている間のクリティカル・データの損失を低減する方法及びシステムに関する。特に、本発明の重要な特徴に従って、クリティカル・デジタルデータは小さなブロック又はセグメントで記憶媒体に書き込まれる。各セグメントが記憶媒体に転送されると、ファイル・アロケーション・テーブルは更新され、ファイルが閉じられる。ファイルをより小さなファイルセグメントに分けることによって、システム故障又は電源損失の結果としてクリティカル・データ損失量は低減される。再生中、ファイルセグメントは動的に組み立てられ、連続的な方法でデジタルデータの再生を可能にする。
【０００６】
これら及び他の本発明の利点は、以下の詳述及び添付図面を参照して容易に理解されるであろう。
【発明を実施するための最良の形態】
【０００７】
本発明は、例えば、システム故障又は電源故障の結果としてのＭＰＥＧストリーミングビデオデータなどのオーディオ及びビデオデータであるクリティカル・デジタルデータの損失のリスクを低減する一方で、前記デジタルデータが、例えば公的所有されている特許文献１に開示され、参照によってこの中に取りこまれているディスクドライブのような記憶媒体に書き込まれる方法及びシステムに関するものである。本発明の原理は、ＭＩＬ−ＳＴＤ−１５５３フォーマット及びミッションデータレコーダーである例えばＴＥＡＣによって製造されるようなＭＤＲ−８０ミッションデータレコーダーに記録され得る実質的に任意のデータフォーマットのような、様々な他のフォーマットのデジタルデータと同様に、パルスコード変調（ＰＣＭ）データ形態のデジタルデータのような様々な他のタイプのデジタルデータに適用可能である。
【０００８】
本発明の重要な特徴に従って、クリティカル・デジタルデータは、セグメントに記録され、リアルタイムで再生され、本発明は記録サブシステム及び再生サブシステムを含んでいる。記録サブシステムは、データ収集フィルタを含んでおり、セグメント化されたファイルを作成する。再生システムは、一実施例では、ファイルリストを受信し、単一の連続したファイルとしてそれを取り扱う再生デコーダを含んでいる。
【０００９】
記録サブシステムの上位レベルブロック図は、図１Ａに例証され、概して参照番号２０で識別されている。示されているように、記録サブシステム２０は、ボックス２２内に示されるパーソナルコンピュータ（ＰＣ）ベースのハードウェアシステム及び概して参照番号２４で識別されるソフトウェアシステムを含んでいる。ＰＣハードウェアシステム２２は、典型的なものに過ぎず、ディスクドライブであって、例えば一般に所有されている特許文献１に詳細に説明されており、参照によってこの中に取り込まれているディスクのような中央処理装置（ＣＰＵ）２６、ＰＣＩバス２８、ＩＤＥバス３０、及び記憶媒体を含んでいる。示されている典型システムでは、クリティカル・デジタルデータは、デジタルデータをＭＰＥＧフォーマットにエンコードするために、概して参照番号３４で識別される１又は複数のＭＰＥＧエンコーダに与えられる。前記ＭＰＥＧエンコーダは、ＰＣＩバス２８を介してシステムに接続される。
【００１０】
【特許文献６】米国特許番号６，２４０，１３７
【００１１】
ＭＰＥＧエンコーダは、一般に技術的に既知である。典型的なＭＰＥＧエンコーダは、特許文献６に開示されており、参照によってこの中に取り込まれている。複数のＭＰＥＧエンコーダ３４は、以下により詳細に述べられるようにユーザ選択可能なチャンネルの番号と一致するように提供される。
【００１２】
上位レベルのディレクトリは、記録サブシステム２０によって作成される。上位レベルディレクトリのサブディレクトリ数は、装置のユーザ選択可能なチャンネル数に対応している。デフォルト上位レベルディレクトリは、図２に例証され、参照番号３６で識別される。ユーザ定義の上位レベルディレクトリ３８は、図３に例証される。チャンネル名と同様にチャンネル数は、ユーザ選択可能であり、例えば初期化ファイル４２（図１Ａ）に記憶される。上位レベルディレクトリのサブディレクトリは、各記録チャンネルを識別するのに用いられる。例えば、デフォルト上位レベルディレクトリ３６は、ユーザ定義のチャンネル名が定義されていない場合には、デフォルトファイル名である例えばｃｈａｎｎｅｌ０１、ｃｈａｎｎｅｌ０２、ｃｈａｎｎｅｌ０３、及びｃｈａｎｎｅｌ＿ｎを識別する。
【００１３】
上位レベルディレクトリ（ＴＬＤ）は、ホスト記憶媒体３２のいずれかに記憶されている。上位レベルディレクトリは、オペレーティングシステムによって定義されるルートディレクトリにあることが必要であるとは限らない。以下により詳細に述べるように、再生アプリケーションは、自動的に検出し、上位レベルディレクトリに基づいて再生する。
【００１４】
任意の所定チャンネルへの記録は、任意の所定時間に開始して停止し得る。ビデオ記録の予測できない性質に順応するために、ビデオ記録セッションは分離されている。特に、第１レベルサブディレクトリは、タイムスタンプ記録セッションのリストを提供し、システムが、再生中にセグメントを上手く組み立てることができるようにする。典型的な数の複数記録セッションに対する典型的な第１レベルサブディレクトリが図４に例証される。図４から明らかなように、典型的な４つのチャンネル記録レコーダーが示されており、それぞれは複数の独立した記録セッションを有している。この例では、上位レベルディレクトリは、サブディレクトリ名：“Ｅｌｂｏｗ  Ｃａｍｅｒａ−Ａ”；“Ｅｌｂｏｗ  Ｃａｍｅｒａ−Ｂ”；“ＨＵＤ”及び“ＭＦＤ”で識別される。これらサブディレクトリの各々の下には、各ファイルの複数の記録セッションを表しているファイルリストがある。各記録セッションファイルは、以下に述べるデータ収集フィルタによってタイムスタンプされ、記録アプリケーションの部分を形成する。図４に示すように、タイムスタンプ“０２＿０１１＿１７＿２１＿３２＿０９７”は、“Ｅｌｂｏｗ  Ｃａｍｅｒａ  Ａ”記録セッションが２００２年の１１日目、１７時間（ミリタリータイム）、２１分、３２．０９７秒に開始したことを表している。
【００１５】
記録及び再生アプリケーションによって用いられるセグメントされたファイル構造が図５に例証される。特に、各セグメントは、ファイルがシステムクロックによって与えられる時間に基づいて最後に変更された時に示しているタイプスタンプと同様のタイムスタンプシーケンス番号を含むファイル名を利用する。タイムスタンプは、ファイルセグメントからのデータファイルの結合を容易にする。図５は、基本セグメント方式及びその個々の構成要素を定義する。図５に示されるように、１つは、２００２年の１２日目、１１：１７：５４．７９８に始まったマルチファンクションディスプレイ（ＨＵＤ）に対するファイル記録セッションをセグメントした。この例では、セグメントサイズは時間に基づいている。実際の時間は、例えば、記録ビットレート及び要求された時間に適した数式に基づいている。
【００１６】
記録アプリケーション
記録アプリケーションである、例えば図１Ａで識別されるアプリケーション４６は、スタートアップの初期化ファイル４２又はシステムレジストリ４４を読み出す。本発明の重要な側面に従って、記録セグメントの長さは、時間又はサイズのどちらかでユーザによって定義されるようになっており、例えば初期化ファイル４２に記憶される。時間又はサイズが、ゼロに設定され得ることは、システムが連続するセグメントされていないファイルを記録する場合である。加えて、記録チャンネルの各々は独立して定義され得る。より詳細には、各記録チャンネルは、特定のセグメントサイズを有するように選定される。
【００１７】
初期化ファイル４２又はシステムレジストリ４４が開始時に読み出された後、最初に、記録アプリケーション４６はディレクトリ構造である例えばデフォルト上位レベルディレクトリ構造４６又は図３に例証されるユーザ定義のディレクトリ名を有するユーザディレクトリを作成する。上述したように、また、上位レベルディレクトリのチャンネル数は、ユーザによって定義され、初期化ファイル４２又はシステムレジストリ４４のどちらかに記憶される。ユーザによって定義されるディレクトリ情報に基づいて、記録アプリケーション４６は、必要なディレクトリ構造を作成し、情報を以下に述べるデータ収集フィルタ及びＭＰＥＧエンコーダ３９に渡す（図１Ａ）。
【００１８】
記録アプリケーション４６は、外部装置への入力に基づいて独立したチャンネルの開始及び停止を制御する。start_recordコマンドが受信される時、記録アプリケーション４６はこの情報をデータ収集フィルタに渡し、順番に、図４に例証されるような第１レベルサブディレクトリを作成し、ユーザ定義される記録システムクロックを介して全てのセッションファイル名をタイムスタンプする。一度、セッションディレクトリが開かれると、記録が始まる。一度、記録が始まると、記録アプリケーション４６は、マルチスレッドソフトウェア環境を介して構成される記録のステータスを監視し、stop_recordコマンドが受信され、データ収集フィルタに渡されるか、又はデータ収集フィルタが記録エラーを記録アプリケーションに記録するか、のいずれかまで記録を続ける。記録アプリケーション４６が記録エラーステータスを受信すると、セッションが閉じられ、データ収集フィルタステータスが監視される。データ収集フィルタから記録アプリケーション４６に報告されるエラーが除去及び訂正される場合であって、記録アプリケーションが停止記録コマンドをまだ受信していない場合には、記録アプリケーション４６は、自動的に、新たなセッションディレクトリの下で記録を再スタートする。一度、セッションが開かれると、データ収集フィルタは、初期化ファイル４２によって定義される間隔での記録を物理的に停止するハードウェアコマンドを発行する。
【００１９】
例えば、図４に例証される各セッションファイルは、例えばＭＰＥＧ−１又はＭＰＥＧ−２のファイルを再生できる標準的なメディアプレーヤーで再生するために必要な全ての情報を有する独立型ファイルである。各ファイルセグメントの唯一の特徴は、タイムスタンプを含むセッションファイル名である。第１レベルサブディレクトリタイムスタンプのように、セッションファイル名は、記録システムクロックに基づいており、一定時間後に、セグメントを連続するメディアファイルに将来的に再結合できるようにする。各ファイルセグメントは、初期化ファイル４２で特定される所要期間に従って完成されるので、ファイルが閉じられると、システムファイルアロケーションテーブルが更新される。ファイルが閉じられた後の任意のポイントで、電源損失のようなシステム故障は既に書き込まれたファイルに影響を及ぼすことはなく閉じられる。
【００２０】
データ収集フィルタは、記録の重要な特徴を形成する。データ収集フィルタは、２つの独特の特徴を有している。第１に、データ収集フィルタは、複数のフィルタと共存し、複数チャンネルの同時記録を可能にする。第２に、データ収集フィルタは、正確なタイムスタンプを用いてこの中に述べられているファイルセグメントを作成し、時間内に複数同期化される連続形式の将来的な結合及び再生を可能にする。一般には、システムのオペレーティングシステム４０に依存するファイル４２又はシステムレジストリ４４からのユーザ特定情報は、記録アプリケーション４６によって読み出され、データ収集フィルタに渡される。初期化ファイル４２又はシステムレジストリ４４からの情報は、ビデオである例えば記録されることになるＭＰＥＧビデオに関する全ての必要な情報を含んでいる。記録アプリケーション４６から受信される情報に基づいて、データ収集フィルタは、例えば数秒から無限の範囲に及ぶ個々のファイルセグメントを作成する。初期化ファイル４２から受信される情報に基づいて、データ収集フィルタは、セグメント情報によって特定される所要期間に対する完全な独立型ファイルを作成する。各ファイルは、データ収集フィルタによってタイムスタンプされ、将来の結合のために適切なセッションディレクトリに配置される。ディレクトリ及びファイル名の管理は、データ収集フィルタの完全な制御下にある。初期化ファイル情報は、セグメントサイズ及び上位レベルディレクトリを定義する。セグメントの全ての他の特徴は、データ収集フィルタによって制御される。
【００２１】
データ収集フィルタは、関連するＭＰＥＧエンコーダ３４と密接に動作する。ハードウェアエンコーダの各生成は、専用データ収集フィルタを有し、特殊な特徴のハードウェアの実現を容易にする。しかしながら、本発明の基本概念は、同じままである。特殊なセグメント及びそれらのサイズの情報は、記録アプリケーション４６を介して初期化ファイル４２からデータ収集フィルタに渡され、システム全体に対して透過性のあるハードウェア変更を可能にする。
【００２２】
記録アプリケーションの典型的なフロー図
記録アプリケーション４６の典型的なフロー図が図６に例証される。初めに、システムは、ステップ５６に示されるように、start_recordコマンドが受信される際に初期化される。start_recordコマンドが受信された後、システムは、ビデオ信号が存在するか否かを決定するためにステップ５８でハードウェアエンコーダ３４をチェックする。存在しない場合、エラーがステップ６０で記録され、記録アプリケーションセッションは終了する。システムが、ビデオ信号が存在することをステップ５８で決定する場合には、フォルダがそれぞれのセッションに対して作成され、上述のようなセッションファイル名が指定される。システムは、フォルダが作成されたか否かを決定するためにステップ６４でチェックする。作成されていない場合には、エラーがステップ６６で記録され、セッションは終了される。フォルダがステップ６４で決定された際に作成されていた場合、システムは、ステップ６８でデータ収集フィルタにファイルパス名を提供する。図５に示されるように、データ収集フィルタは、その後、ファイルセグメントを作成する。セグメントサイズは、セグメント所要期間及び各チャンネルに対するビットレートに基づいて決定される。セグメントは、フィルタグラフがスレッド初期化の部分として作成される際にデータ収集フィルタに渡される。システムは、その後、ステップ７２で記録が開始しているか否かを決定するためにチェックする。開始していない場合、エラーがステップ７４で記録される。システムは、連続的に、ステップ５８に折り返し、前記チャンネルの特定のセグメント数が記録されるまで新たなファイルセグメントを作成する。
【００２３】
図７は、本発明に従って記録アプリケーション４６を利用するためのデータ収集フィルタの典型図である。初めに、ステップ７６で、一度、記録セッションが記録アプリケーション４６によって開かれると、データ収集フィルタである例えば標準的なＭｉｃｒｏｓｏｆｔ  ｄｉｒｅｃｔＸ  フィルタがステップ７６でメディアサンプルを受信し、ファイルセグメントである例えば図５に例証されるファイルセグメントナンバー７８を発生させ、そのデータを最新のファイルセグメントにステップ８０で書き込む。ステップ８２では、システムは、最新のファイルサイズがセグメントファイルサイズ８２より大きいか否かをチェックする。大きくない場合、システムは戻って、追加のメディアサンプルが記録アプリケーション４６から受信されるのを待つ。新たなサンプルが記録アプリケーションから受信されると、追加のセグメントファイルが、例えばベースファイル名及び複数の特性シーケンスナンバーを用いて作成される。例えば、ファイル名がd:/channel1/02_064_14_32_51_620/ch1.mpgである場合、第１のセグメントは、例えば、次のセグメントがd:/channel1/02_064_14_32_51_620/ch1002.mpgである状態でd:/channel1/02_064_14_32_51_620/ch1001.mpgである。最新ファイルがセグメントファイルサイズよりも大きい場合、最新ファイルはステップ８４で閉じられ、次のセグメントのファイルはステップ８６で作成される。ステップ８８では、位置ポインタがステップ８８における新たなファイルのためにリセットされる。
【００２４】
再生システム
再生システムは、再生サブシステム及び再生アプリケーションを含んでいる。再生システムは、標準的なメディアファイルを分割し、デコードし、表示するシステムであり、マイクロソフトメディアプレーヤーのような様々な標準的なメディアプレーヤー及び例えばＭＰＥＧベースのビデオファイルの再生を可能とする任意の他のフィルタプラグインを含み得る。再生システムは、単一のメディアファイルとは対照的にファイルリストを処理する。上述したように、各メディアファイルはファイルセグメント群から構成される。ファイルセグメントは独立型エンティティであるが、ファイルセグメントは全体としてファイルセグメントを見ることができるように結合される。ファイルは記録後に連結され、任意の標準的なメディアプレーヤーに渡り、前記アプリケーションに必要とされる時間がシステムを扱いにくくする。この問題を緩和するために、再生サブシステムは（単一ファイルと対照的に）ファイルリストを受信し、リアルタイムでデータを組み立てる。
【００２５】
再生アプリケーションは、再生サブシステムより上位のレベルで動作し、一般には、再生サブシステムを制御する。再生アプリケーションは、リアルタイムでの複数チャンネル、セッション、及びセグメントの調整に対応する。再生アプリケーションは、最初に再生メディアを走査し、再生のための有効なファイルセグメントを探す。一度、有効なセグメントが確立されると、再生アプリケーションはセッション時間及び記録チャンネルを決定するためにディレクトリ構造を介して上位方向に動作し、記録チャンネル、セッション時間、及びセグメント情報のコンテナに対するテーブルを構築する。この情報は、再生システムによって再生を管理するために操作される。
【００２６】
再生アプリケーションは、複数ビデオチャンネルの同期再生を可能にする様々な個々の構成要素を含んでいる。最初に、再生アプリケーションは、実際のセグメントされたビデオファイルが存在するか否かを決定する。この処理は、ファイル名に関係なく行われ、有効データにのみ基づいている。一度、有効なファイルが確立されると、システムは最新のディレクトリをチェックし、同タイプのシステムの複数のファイルが特定のディレクトリに存在しているか否かを決定する。追加ファイルが存在する場合、タイムスタンプは、その後、ファイルが共通セッションからのものであるか否かを決定するために、ディレクトリ内のファイルについて照合調整される。ファイルが共通セッションからのものである場合、この情報は再生中に利用するためのコンテナに追加される。独立したファイルとそのファイルが最後に変更された時間をチェックすることは、全体システムに対する別のレベルのデータセキュリティーを有する。セグメントされたセッションの部分として発生していない複数のファイルが共通ディレクトリで見つけられる場合、ファイル名は別々のエンティティとして再生リストに追加される。これは、時間内の不連続性によりデータが破棄されないことを保障する。
【００２７】
一度、有効なセグメントが確立されると、再生アプリケーションは、セッションが作成された時を決定するためにディレクトリ構造において上位方向に移動する。セッション開始時間を確立するためには２つの方法がある。一の方法では、セッションディレクトリ名が分析される。前に述べたように、セッションディレクトリ名は、タイムスタンプ情報を含み、セッションが作成された時を指示する。タイムスタンプ情報がディレクトリ名内にある場合、再生アプリケーションは、実際のセッション時間に近いディレクトリが作成された時に基づいてシステムのタイムスタンプを利用する。一度、セッション時間が確立されると、再生アプリケーションは、実際の記録がなされたチャンネルを決定するために上のディレクトリ階層に移動する。チャンネルは名前又は番号によって識別され得る。より詳細には、再生アプリケーションは、セグメントされたファイルに対するポインタをセグメント再生システムに渡す。再生アプリケーションによって用いられる全ての他の情報は、複数の記録の再同期のために再生アプリケーションそれ自体によって用いられる。
【００２８】
２つの再生アプリケーションについて考える。最初の再生アプリケーションでは、特定のフィルタは、各セグメント及びそのそれぞれの内容に基づいて、再生システムによって動的に必要とされる全てのメディア情報を作成するのに用いられる。この実施例では、スケジュールがセグメントの再生のために開発されている。セグメントの再生後、フィルタである例えばマイクロソフトダイレクトショウフィルタが、標準的なメディアプレーヤーによって再生可能なようにスケジュールに従って、次のセグメントに切り替えるのに用いられる。前記アプリケーションは、メディアプレーヤーは、それが単一ファイルを再生するのと同じ手法でファイルリストを実際に再生する。これにより、オリジナルヘッダ情報を含む初期のセグメントされたファイルを介在させずに個々のセグメントの実際の再生が可能となる。再生の第２の方法は、フィルタを含んでいないが、それでも、セグメントされたファイルを標準のウィンドウズ（登録商標）又はＭａｃベースのＭＰＥＧメディアプレーヤーで再生できるようにする。この方法では、全てのメディアファイルの結合が、再生に優先する。結合は、任意の標準的な必要とされるユーティリティを用いることによって成し遂げられ、グループファイルの結合を可能にする。
【００２９】
再生サブシステムの典型的なフロー図
図１Ｂは、本発明に従う再生サブシステムの上位レベルソフトウェアフロー図を例証する。最初に、再生モードの動作では、システムは、再生コマンドに応答し、ステップ９０に示される上述したフォルダ／サブフォルダと称する規則に基づいてセグメントされたファイルを見つけ出す。これらのフォルダは、ステップ９２に示されるようにチャンネルコンテナを作成しているチャンネルによってソートされる。チャンネルコンテナは、さらに、ステップ９４に示されるようにセッションコンテナを含むセッションによってソートされる。セッションコンテナは、ステップ９６に示されるように最後に変更された時間によってソートされる。最後に変更された時間は、最後の一部分のデータがファイルに書き込まれた時である。ファイルリストとしてのセッションにおける全てのセグメントをユーザに与える前に、ファイルリストが再生可能かどうかの判断がなされる。例えば、ＭＰＥＧの場合には、プレゼンテーション・タイムスタンプに任意の切れ目があるべきではない。第２に、ファイルリストのセッション開始時間が決定される必要がある。特定の場合には、一時的な再生システムが設定される。ＭＰＥＧファイルの場合には、マイクロソフトダイレクトショウ再生システムが利用され得る。このシステムは一時的であり、上の２つのタスクが決定された後に消去される。再生のために利用できない点でこのシステムは不完全であるが、ファイルの有効なリスト及びファイルリストの所要期間を提供するためにユーザにとっては明確な手法で利用される。セグメントの最後に変更された時間から所要期間を差し引くことによって、セッションコンテナ開始時間が容易に決定される。セッションコンテナ開始時間が決定された後、一時的かつ不完全な再生が消去される。ステップ１００では、セッション開始時間は、セッションの最後に変更された時間及び所要期間に基づいて決定される。ステップ１０２では、セグメントされたファイルのリストは、正確なセッション開始及び停止時間を用いて作成され、ステップ１０４で再生コマンドに応答して再生される。
【００３０】
より詳細のフロー図は、図８Ａ−８Ｄに例証される。最初に、ステップ１０６では、システムは、システムのフォルダの全てに応答指令信号を送り、フォルダは、図１及び５に例証されるように、ステップ１０８でパターンに適合するファイル名を有しているか否かを決定する。ステップ１１０では、システムは、各フォルダ内の全てのファイルに応答指令信号を送り、ファイル名がパターンに適合するか否かをステップ１１２で決定する。一度、ファイル名がパターンに適合することが決定されると、チャンネル番号がステップ１１４で決定される。上述したように、コンテナが、ステップ１１６、１１８、及び１２０で各チャンネル番号に対して作成される。
【００３１】
図８Ｂ−８Ｄは、セッションによってチャンネルコンテナをソートし、セッションコンテナを包含することに関する。最初に図８Ｄを参照すると、ファイルが初めにステップ１２２において番号によってソートされる。ステップ１２４では、システムはファイル番号に空所があるか否かを決定する。空所がある場合、システムはエラーを返す。空所がない場合、ファイルはステップ１２６で最後の変更時間によってソートされ、ファイルのリストはステップ１２８で構築される。ステップ１３０では、例えばマイクロソフトダイレクトショウフィルタリストがステップ１３０で構築される。続いて、ステップ１３２では、システムはファイルが例えばＭＰＥＧ−２準拠ファイルであるか否かを決定する。準拠している場合、ファイルのリストはステップ１３４で得られ、開始時間はステップ１３６において最後のファイル変更時間及び合計の所要期間に基づいている。
【００３２】
チャンネルコンテナ処理は、図８Ｂ及び図８Ｃに例証される。図８Ｂを参照すると、システムはチャンネルコンテナが存在するか否かをステップ１３８で決定する。複数のチャンネルコンテナが存在すると想定すると、システムは、全てのチャンネルコンテナがステップ１４６で指示されるように応答指令信号を送られるまで、ステップ１４０、１４２、及び１４４でセッションファイルのために全てのチャンネルコンテナをソートする。セッションファイルは、その後、ステップ１４８、１５０、及び１５２で各チャンネルに対して再生される。
【００３３】
図８Ｃは、セッションファイルにチャンネルコンテナをソートするフロー図を例証する。最初に、ステップ１５４で、システムは任意の非応答ファイルが存在するか否かを決定する。存在する場合、システムはステップ１５６でファイルパスからセッション名を得る。ステップ１５８において、システムは、コンテナがステップ１５６で見つけられるセッション名に対して存在するか否かを決定する。存在しない場合、新たなシステムコンテナがステップ１６０で作成され、ステップ１６２においてセッションコンテナファイルに追加される。
【００３４】
全てのファイルが応答指令信号を送られている場合、システムは任意のセッションコンテナが存在するか否かをステップ１６４で決定し、ステップ１６６、１６８、及び１７０のおいて最新のファイル変更時間及び合計の所要期間に基づいて開始時間を得る。この処理は、全てのコンテナがステップ１７２で処理されるまで続けられる。
【００３５】
明らかに、本発明の多くの改良及び変化が上記教示に照らして可能である。従って、添付した請求項の範囲内において、本発明が特別に上述した以外のものに実行され得ることが理解されることになる。
【図面の簡単な説明】
【００３６】
【図１Ａ】本発明の一部を形成する記録サブシステムのブロック図である。
【図１Ｂ】本発明に従う再生サブシステムのブロック図である。
【図２】本発明に従って用いられるデフォルト上位レベルディレクトリ構造の例である。
【図３】本発明に従うユーザ定義の上位レベルディレクトリ構造の例である。
【図４】本発明に従う典型的な複数記録セッションを用いて示される第１レベルサブディレクトリの例である。
【図５】本発明に従う典型的なセグメント化されたファイル構造である。
【図６】本発明に従う記録サブシステムのソフトウェアフロー図である。
【図７】本発明の一部を形成するデータ収集フィルタのソフトウェアフロー図である。
【図８Ａ】本発明に従う再生サブシステムのソフトウェアフロー図である。
【図８Ｂ】本発明に従う再生サブシステムのソフトウェアフロー図である。
【図８Ｃ】本発明に従う再生サブシステムのソフトウェアフロー図である。
【図８Ｄ】本発明に従う再生サブシステムのソフトウェアフロー図である。
【図１Ａ】
2005527044.tif 000003
【図１Ｂ】
2005527044.tif 000004
【図２】
2005527044.tif 000005
【図３】
2005527044.tif 000006
【図４】
2005527044.tif 000007
【図５】
2005527044.tif 000008
【図６】
2005527044.tif 000009
【図７】
2005527044.tif 000010
【図８Ａ】
2005527044.tif 000011
【図８Ｂ】
2005527044.tif 000012
【図８Ｃ】
2005527044.tif 000013
【図８Ｄ】
2005527044.tif 000014
【国際調査報告】
2005527044.tif 000015