JP2019504528A - メディア・ストリーミング - Google Patents

Abstract

複数のメディア・ストリームのコンポジションをユーザに提示するためのメディア再生システムを提供する。このメディア再生システムは、シナリオ・データセットを受信し、メディアのセグメントを定義する視聴時間の選択とコンポジション選択のためのユーザ入力を受信し、前記ユーザによる視聴が認可された前記シナリオ・データセットからのメディアのセグメントのリストを出力するように構成したメディア選択構成部を備える。メディア再生システムはさらに、前記出力したセグメントのリストからの少なくとも前記メディアのセグメントをメディア格納庫から検索し、該メディアのセグメントをデコードし、コンポジション指示書をコンパイルするように構成した再生制御構成部を備える。メディア再生システムはさらに、前記再現されたメディアと前記コンポジション指示書を受信するように構成したメディア再生構成部を備える。

Description

本出願は、２０１５年１１月２０日に出願された米国仮特許出願第62/257,966の優先権を主張する。

本出願は、メディアデータ・ストリーミングの分野に関する。

マルチメディア（例えば、音声、映像）などのメディア・ストリームが格納および検索され、上記ストリームに対して認可されたユーザのみが確実にアクセスを有するように用いられる関連づけられた認可機構により多数のユーザが受信する、多数の出願がある。いくらかの出願はセキュリティ監視の分野であり、警察の捜査業務の分野の出願もいくらかある。

最初に、セキュリティ監視システムは、映像と音声のストリームを記録、格納および中継することのみに用いられる。これらは、上記アナログ映像記録システムが提供する最適の性能である。従って、サポートされるシナリオと対応するシステム・アーキテクチャーは極めて簡素である。当該レコーダーに対するアクセスを有する人は誰でも上記ストリームを利用できる以上、上記音声・映像アーカイブに対するアクセスを制御するために、物理的なアクセスは必須である。そこで、多少ともより高度な性能が付加され、例えば、テキストおよび形状オーバーレイ、１つのカメラにより生成される多数の映像の供給、１回のレコーディングにおける多数のカメラ供給の並列などである。

しかし、セキュリティ、プライバシー、協働、および格納の要件がより差し迫るにつれて、セキュリティ監視と捜査のシナリオの複雑さが増大し、その結果として、より複雑なシステム・アーキテクチャーと実施が生ずる。例えば、プライバシー要件が１つのシナリオの全ストリーム（例えば、建築物の特定の位置に関する映像、音声および任意の他のメタデータのストリームなど）の暗号化を要求するとき、いくらかのストリームが第１のユーザ群のみに対してアクセス可能であって、かつ、いくらかの他のストリームが第２のユーザ群のみに対してアクセス可能である場合には、アクセスを要求するユーザに対する各ストリームのアクセス制御を、従来のシステム・アーキテクチャーで実施することが困難になる。これは、ストリームが時間と共に変動する制限のない情報量を代表するためである。さらに、１つのストリームの一部のみが特定のユーザに付与されるように要求されて、当該ユーザがそのストリームの残り部分にアクセスできなくなり得る。しかし、その同じストリームに対して、別のユーザ群に許可が付与されるかもしれない。特定のストリーム（またはその一部のみ）に対するアクセスを有するユーザはさらに、別のユーザにアクセスを提供することもできる。しかし、それらのシナリオを実現する従来の方法では、完全なデータ・ストリームの複号と再暗号化を当然伴うことになり、極めてリソースを消費する操作であって、今日では容認可能な解決策ではない。

データ・ストリームの配信に固有の課題は、データのストリーム内に埋め込まれた個人の身元を識別できる情報のデータ（ＰＩＩ）が捜査人によりアクセス、共有、利用および保持されることに対する感受性の高まりによって、さらに激化している。捜査人は、データ・ストリームの任意の組合せの内容、または、その組合せについての情報を調査する際に利害関係を隠匿するユーザである（例えば、法執行官、検察官、国家保安または準軍事的組織の構成員、警備保障業者、私立探偵、犯罪学的捜査または監視が可能な請負行商人、犯罪分析者、市場売買または産業スパイ活動分析者、捜査人の機能を実行する自動化システムなど）。米国商務省の米国基準・科学技術協会（Special Publication 800-122）によれば、ＰＩＩとは、「（１）個人の身元を見分ける、または追跡するために利用可能な任意の情報、および（２）個人に結びつく、または結びつき可能な任意の情報を含む個人についての〜任意の情報である。〜結びつく情報とは、個人についての、または個人に関する情報であって、当該個人についての他の情報と必然的に関連づけられるものである。他方、結びつき可能な情報とは、個人についての、または個人に関する情報であって、当該個人についての他の情報と必然的に関連づけられる可能性があるものである」。

データ・ストリームの配信に固有のデータ管理に対する課題は、ＰＩＩが当事者（「発信者」）により捕捉され、そのデータ・ストリームに含有される、または当該データ・ストリームについての情報の統合、合成および意味の明確化を行う第三者（「統合者」）に提供される状況において、さらに激化するかもしれない。実例として、発信者は、そのクライアントの特定のＰＩＩが捜査人によってアクセスされる合法的な必要性がある場合にのみ、そのアクセスを確実に行なうことに関心があるソーシャル・メディアのサービスプロバイダ、または小売商人であってもよい。そのとき、ＰＩＩ情報を含有するソーシャル・メディアの給送がデフォルトにより暗号化され、匿名バージョンに対するアクセスのみを与える。上記ソーシャル・メディアの給送の匿名バージョンを一般大衆に提供することによって、プロフィール分析および他の非認可の使用が回避できる。

その結果として、最新のシステムは、離散型のデータブロック間のそれらの唯一のリンクとしてのデータベース・インデックスを有する当該データブロックに主に基づいて、現行のシステム・アーキテクチャーを用いて管理するのが困難である、より複雑なシナリオに対してサポートを提供しなければならない。より高機能のアーキテクチャーを作成して、それらの複雑なシナリオと関連づけられた新しいシステム要件を解決しなければならず、そのための例を本明細書で記載している。開示しているのは、容易に用いて論理回路のシナリオの構成ストリームを収集、格納、管理および中継でき、そのシナリオを再現するときに当該ストリームが非同期的に格納および同期させられるように、メタデータのストリーム、すなわち（他のストリームであってもよい）データについての当該データのストリームに基づいたシステム・アーキテクチャーである。

メディア・ストリームは、当該メディア・ストリームを結びつけ、かつ、同期させるデータの階層構造として系統立てられることを、出願人は見出した。その結果、そのメディアのストリーミングを、１つまたは２つ以上のサーバから行先ノードに多数の別個のストリームとして取り扱うことができ、その後、当該行先ノードがメディア・ストリームのデータの同期化を取り扱うことができる。この配設では、上記ストリームにアクセスする認証は、ストリームのサーバ間で１つに集中または分配される。

ストリームの暗号化は、時間により変動するセッションキー（キー）を用いて行うことができ、暗号化されたストリームは、対称のセッションキーストリームと共に行先ノードに配信されることを、出願人はさらに見出した。そのセッションキーストリームの暗号化は、非対称のキーを用いて行うことができるので、当該セッションキーストリームに含有される上記セッションキーを検索するためには、上記行先ノードに補完キーを使用させる必要がある。上記暗号化されたメディア・ストリームと上記セッションキーストリームの同期化は、適正なセッションキーを適用するように、それらのストリームの同期化方法を当該行先ノードに指定するルート・ストリームを用いて実現できる。

本出願では、上述の用語「ストリーム」は、その標準の意味、すなわち、安定した連続的な流れとして、インターネットまたは他のデータネットワークを介して、データ（特に、映像および音声の資料であるが、他の種類のデータであってもよい）を送信または受信するという意味に従っており、ストリームは本質的に同期またはタイムスタンプのデータを有し、かつ、ストリームは時間で基準化される一連のイベントであり得るＧＰＳ座標、画像、画像の注釈またはテキストのコメントのようなデータを含むことができるという条件で用いられている。

本発明は、添付の図面を参照して、本発明の実施の形態の下記の詳細な説明によって、より効果的に理解されるであろう。

ルート・ストリームと複数のノード・ストリームを有するストリーム階層を実行可能なデバイスのコンピュータネットワークの概略図である。

再生ワークステーションの概略図である。

フュージョンストリームのアーキテクチャーの概略図である。

例示的なフュージョンノードの概略図である。

フュージョンノードの時間間隔の概略図である。

シナリオ再現のためのセグメント・ストリームの選択の概略図である。

主に再生装置に関連づけられたソフトウェアおよびハードウェアのモジュールの概略ブロック図である。

フュージョンストリームの再生に伴うステップのフローチャートである。

２つの表題を示すプレーヤー適用インターフェースの概略スクリーンショットの例である。

すべての画像で検出されたモーションの比率を示すタイムラインである。

一実施の形態による映像の暗号化を伴うカメラ・ソース、アーカイブサーバおよびクライアント・ワークステーションを示す概略システム図である。

フュージョンストリームによる基礎ストリームの統合の一例を示す概略図である。

フュージョンストリームにより認められる許可の付与の一例を示す概略図である。

フュージョンストリームのプログラム作成インターフェースの例示的な定義を示す概略図である。

音声および映像ストリームを記録するために用いる標準のアーカイバーの例示的なアーキテクチャーを示す概略図である。

フュージョンストリーム用に作り変えられた標準のアーカイバーの性能を利用するフュージョン・アーカイバーの例示的なアーキテクチャーを示す概略図である。

ストリームのセグメントの読出しと再現に伴う一組の例示的なステップを示すフローチャート図である。

図１に示すように、再生ワークステーション１０は、サーバ１１および１２にネットワーク１４を介して接続される。再生ワークステーション１０は、デスクトップコンピュータ、タブレットコンピュータ、スマートフォン、またはスマートテレビなどであり得る。サーバ１１は、１つまたは複数のサーバ１２からのメディア・ストリームを処理する際に、コンピュータ１０を案内するシナリオ・データをホストするものとして示されている。サーバ１１上のシナリオ・データは、サーバ１２上のリソース・データと共同ホストされる。サーバ１２は、例えば、セキュリティ用ビデオカメラ、動作センサー、カード読取り機、マイクロフォン、ＧＰＳ、分析システムなどのストリーム・ソース１３ａから受信したファイルを格納する。上記シナリオまたはフュージョンストリームのデータは事情に応じて、ソース１３ａから別個の構成部であるように図１に示すモジュール１３ｂによっても生成される。しかし、ソース１３ａは、セグメントのファイル、基礎ストリーム、フュージョンノードおよびフュージョンストリームを生成するように作り変えられることができる。図１のシステムの構成部はすべて、共通のネットワークを介して相互接続されるものとして示されているが、直接の接続、および特定の接続用の別個のネットワークを用いてもよい。

図２に示すように、コンピュータ１０は、従来のコンピュータ計算プラットフォームを備えることができる。制限しない様式で示しているように、コンピュータ１０は、ＣＰＵ１０ａ、バス１０ｂ、プログラム記憶素子１０ｃ、ネットワーク・インターフェース１０ｄ（有線または無線）、図形用ハードウェア１０ｅ、ディスプレイ１０ｆおよびオーディオ電子機器１０ｇを備えることができる。プログラム記憶素子１０ｃは典型的に、オペレーティング・システムとアプリケーション・プログラムを含む。

フュージョンストリーム

表示すべき画像を提供する一連のフレームを含有する映像ストリーム、または、音声データを含有する音声ストリームと同様に、「フュージョンストリーム」は、安全、追跡可能かつ制御される協働および共有を可能にする所定の論理回路のシナリオ用の基礎ストリーム（または他のフュージョンストリーム）のコンポジションからなるバージョン化されたデータ・ストリームとして定義され得る。そのフュージョンストリームは、上記論理回路のシナリオを再現するために必要とされる情報を含有する一連の「フュージョンノード」を提供し、映像、音声、モーションのレベル、お気に入り、オーバーレイ、イベント、許可、暗号化キーなどを含むことができる。

２つの主な要素：１）（フュージョンノードからなる）フュージョンストリームと、２）（セグメントからなる）基礎ストリームとがある。それらの要素は両方とも、ストリーミングのディメンションにおいて漸進的に変化する（すなわち、それらのデータは時間の関数として変動する）。しかし、フュージョンストリームはさらに、コンポジションのバージョン化（すなわち、そのコンポジションは時間と共に変動する）も有する。

フュージョンストリームは階層データ構造であり、その要素を図３で示し、以下のように定義する。
- フュージョンストリーム：時間と共に変動する基礎ストリーム（または他のフュージョンストリーム）の論理回路コンポジション（コンポジションのバージョン化と呼ばれる）。そのフュージョンストリームは、当該フュージョンストリームの基礎ストリームのコンポジションを所定の時間に描写する、一連のフュージョンノードからなる制限のない一連のデータから形成される。従って、フュージョンストリームは、フュージョンノードのリストを有する。
- フュージョンノード：一組のキー・値の対（属性）とセグメントのリストをシナリオの特定の時間Ｔに対して提供する論理回路の存在物。そのセグメントは、独立して格納された異なる基礎ストリームに属する。ストリームは制限のない一連のデータであるから、フュージョンストリームは、シナリオの基礎ストリームのコンポジションを任意の所定の時間に描写する、一連のフュージョンノードとして表されてもよい。フュージョンノードは、時間Ｔにおける上記フュージョンストリームのコンポジションと、時間Ｔに対してデータを提供するそのセグメントのすべてを記録する。
- 基礎ストリーム：ストリーミング時間のすべてに亘って、単一のソース（カメラ、マイクロフォン、ＧＰＳなど）から入ってくるフレームの完全なリストを提供する論理回路の存在物。これは、一意的なソースからのセグメントのリストからなり、それらのセグメントのどれも重複しない。
基礎ストリームは、以下のような特徴を有する。
・ 本来、境界がなく、無限であり、かつ純粋に付着増加する（新しいデータは常に、その端部に添付され、現存データは決して修正されない）。
・ 不変である（すなわち、それらのデータは決して変化しない）有限のセグメントに任意に分割できる。
・ 一意的なソースから発信される。
・ 時間の関数（例えば、ストリーミング時間）として変動するデータを含有する。
・ 所定の時間に対して、データを提供することができない。
・ 別のフュージョンストリームであることもできる。
- セグメント：基礎ストリームを構成するデータの有限の下位セット（例えば、フレームの有限のリスト）を含有する論理回路の存在物。セグメントは、開始時間と終了時間を有する。典型的に、セグメントはディスク上に格納されたファイルに相当し、数個のセグメントを用いて基礎ストリームを構成する。

従って、論理回路のシナリオの記録によって包含された任意の時点（すなわち、ストリーミング時間のディメンション）に対して、上記フュージョンストリームは以下を提供する。
・ 再現されるシナリオを構成するセグメントのリスト。
・ 各セグメントの位置；すなわち、その格納場所（サーバ、ディスク、クラウドのプラットフォームなど）。
・ セグメントを同期させて適切に組み合わせる方法に関する情報）。

上記フュージョンストリームをその同一性により参照するとき、そのデータ構造のルート要素を参照する。そのリーフは全部または一部において、基礎ストリーム、あるいは他のフュージョンストリームのどちらかであり得る。

最新のセキュリティ監視および事件捜査のシステムでは、下記のキー要件は一般に、任意の新しい配置にとって必須である。すなわち、情報の秘匿、利害関係者間の協働、情報の共有、クラウドのプラットフォームにおける格納スケーリング、および情報の論理回路分類である。

プライバシー

すべてのストリームは個別に、次のように暗号化できる。
・ データ・ストリームは、周期的に変化する無作為に生成した対称キーを用いて暗号化される。
・ 次に、上記の結果から生じる一連の対称キーが、当該ストリームに対する視聴許可が付与されるべき人の公開キー（非対称暗号化）を用いて暗号化される。
・ 当該暗号化プロセスの上記の結果から生じるストリームは、クライアント特定キーのストリームである。
・ 視聴許可が付与されるべき人と同数のクライアント特定キーのストリームがあり得る。
・ 視聴許可が所定の一連（１つのストリームの一部）に制限されなければならない場合には、上記クライアント特定キーのストリームの長さは、マスターキーストリームの下位セットを単に暗号化することにより制限できる。これにより、誰がコンテンツを見れるかに関して、粒状性の制御を可能にする。

１つまたは複数のストリームにアクセスするための許可を付与された人に対する暗号化されたデータ・ストリームと関連づけられたキーストリームは、フュージョンストリームによって実行された論理回路のシナリオの下で組み合わせられる。

協働

上記フュージョンストリームと関連づけられた２つの重要な時間のディメンションがある。
・ 上記フュージョンノードが記録したようなストリーミング時間。例えば、ストリーミング時間Ｔに、当該フュージョンストリームはストリームＡ，ＢおよびＣから構成される。
・ 上記フュージョンストリームのバージョン（コンポジションのバージョン化）。当該フュージョンストリームが新しいストリームを付着増加でき、そのコンポジションが時間と共に変化できるためである。例えば:
・ Ｖ１:ストリーミング時間Ｔに、当該フュージョンストリームはストリームＡ，ＢおよびＣから構成され、そのフュージョンストリームのバージョン１を表す。
・ Ｖ２:ストリーミング時間Ｔ（Ｖ１と同じ時間）に、当該フュージョンストリームはここで、ストリームＡ，Ｂ，ＣおよびＤから構成され、そのバージョン２を表す。

新しいストリームを取り入れる、あるいは、新しいストリームを導出する（例えば、新しいクライアント特定キーのストリームを作成すること、事後分析論など）ことによって、上記フュージョンストリームのコンポジションは、同じ時間Ｔの間、時間と共に漸進的に変化できる。

上記フュージョンストリームのバージョン化は、組み込まれた監査証跡として機能し、これは協働を行う上で望ましい特徴である。さらに、これにより、（ちょうど、ソース制御マネージャーまたはWikipediaのように）望ましくない修正のロールバックが可能になる。

共有

上記秘匿および協働用キーの要件により、複数の新しいクライアント特定キーのストリームを作成して上記フュージョンストリームに付着増加できる共有が可能になる。このような共有の粒状性により、そのフュージョンストリームの基礎ストリームの下位セットのみにアクセスが与えられると共に、上記複数のストリーム内の制限された時間間隔のみにアクセスが与えられることになる。当該フュージョンストリームのバージョンを変更することにより、ちょうど任意の他のストリームのように、クライアント特定キーのストリームを付加、取替えまたは削除することが可能になる。

クラウドのスケーリング

並べて配置する必要がないセグメントを指し示すことにより、フュージョンノードには、上記フュージョンストリームのコンポジションが描写される。非認可の人によってアクセスが行われた場合でも、秘密性を損なわないように、大量の基礎ストリームが暗号化され、クラウドのプラットフォーム上に格納することができる。

セグメントは本来、不変であり、クラウド向きのオブジェクト格納を想定すれば、多数のフュージョンストリームにより再使用できる（例えば、身体装着型カメラ（ＢＭＣ）による記録は、２つ以上の論理回路のシナリオに属し得る）。利害関係者と上記フュージョンストリームのバージョンの間の協働に対する集中により、上記セグメントが極めてクラウド・プラットフォーム向きになる。すなわち、当該セグメントを実際は信用できないサーバ上に安全に格納できる。

論理回路分類

フュージョンストリームは、捜査中の事件であるか、一意的な警官と関連づけられデータであるか、都市を通って移動する車両の後を追う据付けカメラからのデータであるかなどの単一の論理回路のシナリオの下で、独立した基礎ストリームを意図的に分類し直す。基礎ストリーム、または、そのセグメントのいくらかは、２つ以上のフュージョンストリームにより同時に基準化することができる。

フュージョンストリームは、２つの部分を有し得る。
１． 定義
２． フュージョンノードのリスト（コンポジション）

フュージョンストリームは、人および機械が読み出すことができる任意のマークアップ言語フォーマットにおいて定義できるが、本発明を説明する目的で、この例では、フュージョンストリームの構造を定義するために、ＪＳＯＮフォーマットを用いている。

フュージョンストリームの構造：

上述のように、フュージョンストリームの定義は、シナリオに関するスタティック情報を提供する。すなわち、そのフュージョンストリームの一部である任意の従属したフュージョンノードに対して、同一のままのキー・値の属性である。例えば、フュージョンストリーム内で特定の時間に探索を行うとき、ショートネーム、記載事項および作成日時の属性は変化しないであろう。

上記定義は、以下の属性を提供する。
・ fusion-guid:上記フュージョンストリームの一意的な識別名。
・ fusion-composition-version: 当該フュージョンストリームの現行バージョンであり、時間と共にそれになされた変化を追跡するために用いたフュージョンストリームのバージョン化に関する。
・ short-name and description: ユーザがより容易に記録の分類、および見つけ出しを行うために典型的に入力したテキストの情報。
・ creation-date: 当該フュージョンストリームが作成された日付と時間。
・ created-by: 当該フュージョンストリームを作成したユーザ。
・ read/write-permission-level: 当該フュージョンストリームの読出し、および修正を行うために必要なアクセスの権利。
・ tags:本システムが、システムおよびアプリケーション特定要件に従って、当該フュージョンストリームを分類するために用いるプロパティ（例えば、本システムで当該フュージョンストリームと関連づけられた存在物の種類）。

他方、フュージョンノードは、上記シナリオに関するダイナミック情報を提供する。すなわち、当該シナリオを再現するとき、特定の時間ＴＸにおけるそのコンポジションである。フュージョンノードはセグメントのリストを含有し、それらの各々は、異なる基礎ストリームに属する。図４は、５個のフュージョンノードを有するフュージョンストリームと、セグメントを有する関連のある基礎ストリームの一例の概略図である。フュージョンノードは、時間ＴＸに上記フュージョンストリームのコンポジションを記録する。すなわち、時間ＴＸに対してデータを提供するすべての関連づけられたセグメントである。各ストリームのクロックが、その他のクロックと完全に同期していない場合に、そのフュージョンノードは、当該フュージョンストリームのストリーミング時間に対するセグメントの時間オフセットが格納できる場所である。

フュージョンストリームは、その記録が極めて短いときに単一のノードを有することができるが、一般的に、（例えば、多数のファイルで記録される映像ストリームであり、それぞれが２０分の映像を含有し、１つのファイルが１つのセグメントに対応する）基礎ストリームを格納するために用いる多様なセグメントを考慮して、多数のノードを有する。音声セグメントは、他の種類のストリームに関しては、異なる期間中にデータを含有できる。

有限の期間中に映像セグメントと音声セグメントを含有するフュージョンノードの一例を以下に示す。

フュージョンノードの構造：

各フュージョンノードは、以下の属性を提供する。
・ fusion-node-guid:上記フュージョンノードの一意的な識別名。
・ streaming-time:当該フュージョンノードのコンポジションが、再現されているシナリオにおいて実行される時間。この時間の前には、先行するフュージョンノードのコンポジションが適用され、この時間の後には、別のフュージョンノードが、そのストリーミング時間の値に従って適用されてよい。
・ segments:当該フュージョンノードを構成するセグメントのリスト。
・ stream-guid:そのセグメントを所有する上記基礎ストリームの一意的な識別名。
・ segment-guid:当該セグメントの一意的な識別名。
・ URI: 当該セグメントのロケーション（サーバ名、パス、ファイル名など）。
・ SHA-1: 当該セグメントのシグネチャーを表すハッシュ値。これは、当該セグメントに対する一意的な格納パスを作成するために用いられる。
・ start-time:当該セグメントがデータを提供できる最初の時間。
・ end-time:当該セグメントがデータを提供できる最終の時間。

選択的に、フュージョンノードは、１つまたは複数のコンポジション属性を提供してもよい。制限しない例として、映像ストリーム上に重ね合わせられよう静止画像は、そのコンポジション属性として、当該画像が別のフレーム内で現れるであろう場所のスケーリング・パラメータと座標を有することができる。ＧＰＳ座標の場合では、キャラクターの大きさと、そのキャラクターが現れて背景と少しでも対比すべき別の画像フレーム内のロケーションは、上記フュージョンノードで指定できる。さらに、上記コンポジション属性が組み合わされる、もしくは、混合される他のフュージョンノードの指定を含むことも可能である。再生または再現のときに、ユーザは、より効果的なストリームの組合せを提供するために、コンポジションのパラメータを変更するインターフェースにおける機会を与えられてもよい。

上記フュージョンストリーム（とフュージョンノード）にコンポジション属性を含むことにより、フュージョンストリームの著者は、組み合わされる当該ストリームだけでなく、ストリームが再現されるときに組み合わされる、提案された、もしくは必須の方法も定義する。いくらかの場合では、上記セグメントの単なる選択に固有ではない組合せの本質において、特定の結果または効果が実現され、上記フュージョンストリームの著者は、その結果または効果が実現できるように、所望の、もしくは提案された組合せを指定する機構が提供される。これにより、新しい要件が導入されるとき、新しいシステム性能の開発のための順応性のあるアーキテクチャーもさらに提供される。

その同じフュージョンストリームに対する第２のフュージョンノードは、以下のようなもの（太字で強調している修正された属性を有する）であり得る。

同じフュージョンストリームの第２のフュージョンノード：

多数の他の属性を、上記フュージョンストリームの構造と上記フュージョンノードの構造に付加することにより、提示されている任意の新しいアプリケーション、シナリオまたは要件に本発明を作り変え得ることに注目すべきである。上記ユーザ・インターフェースはさらに、当該新しいアプリケーション、シナリオまたは要件を提示できるように開発した新しい性能に対するアクセスをユーザに与えるように作り変えられてもよい。

上記フュージョンストリームとフュージョンノードの両方をデータベースに格納し、特定のそれらの格納と問合せを容易にできることにさらに注目すべきである。さらに、それらをディスク上のファイルとして格納し、データベースにおいて、それらのファイルの識別名にインデックスを付けることもできる。フュージョンストリームのコンテンツは、他のデータ・ストリーム（典型的に、映像および音声）と比較するときに無視できるため、データベースを用いるときに複雑なシナリオを格納するための順応性のある、大きさの変更が可能な解決策が提供できる。

アプリケーション（プレーヤー、ビュワー、エディターなど）が、フュージョンストリームにより提供されるデータを取得かつ操作するための方法を説明する。プログラム作成インターフェースをソフトウェア・アプリケーションにより用いて、上記フュージョンストリームをデータ構造として用いてもよい。クライアント・アプリケーションがデータ・ストリームと共に作動して論理回路のシナリオを記録、修正かつ再生する必要がある場合には、図１４で示すプログラム作成インターフェースなどのプログラム作成インターフェースを介して、当該フュージョンストリームを用いてもよい。そのバックエンドは、ディスク上のアーカイブ保管、保持期間、暗号化およびストリーミングを管理してもよい。いくらかの実施の形態では、当該バックエンドがそのような性能を管理するので、上記クライアント・アプリケーションがそれらの性能を管理する必要はなくてもよい。

フュージョンストリームにアクセスすることにより、そのシナリオを再現するアプリケーションは、検索する当該フュージョンストリームの同一性、当該シナリオを再現するストリーミング時間ＴＸ、および、コンポジションのバージョン（選択的である）を認識しながら、そのコンポジションの一部であるすべてのセグメントのリストを検索できるので、これらのセグメントを組合せて再現することが可能になる。

例えば、警官が、カメラで昨晩２３時３０分頃に撮影された記録の検索を所望する。その記録は、映像記録と音声記録を含み、それらは両方とも単一のフュージョンストリームにより基準化される。これを実現するために、上記プレーヤー・アプリケーションは、カメラで２３時３０分に撮影された記録を本システムに問い合わせる。フュージョンストリームのリストがユーザに戻され、そのユーザは適切な記録と関連づけられたフュージョンストリームを選択できる。そのフュージョンストリームＩＤを用い、かつ、上記 GetFusionStreamInfo方法を呼び出して、当該プレーヤーは、そのフュージョンストリームの定義を検索して、ユーザにその定義を表示できる。

CompositionVersionが提供されていない場合には、本システムは上記フュージョンストリームのその最新のバージョンに戻る。上記方法で提供されたCompositionVersionの値は、上記fusion-composition-versionの属性に格納された上記フュージョンストリームのコンポジションの特定バージョンに相当する。そのコンポジションが修正されるたびに、例えば基礎ストリームが付加されるとき、当該fusion-composition-versionの値が増加されて、一意的なバージョン数を提供する。フュージョンノードが不変のデータ存在物を表し、決して修正されないということを考慮して、その変化を格納するために新しいフュージョンノードを作成することにより、時間と共にフュージョンストリームに対してなされた当該変化を追跡する性能が提供される。その後、先に生じた変化の廃棄を所望する、あるいは、監査通報の提供を所望する場合に、必要なときにフュージョンストリームのより古いバージョンの検索が可能になる。

上記ユーザは次に、プレーをクリックすることにより、上記シナリオの再現を開始できる。このときに、そのプレーヤーは、上記GetFusionStreamComposition方法を呼び出して、上記フュージョンストリームのコンポジションを２３時３０分に取得できる。すなわち、当該シナリオをＴＸ＝２３：３０に対して再現するために必要とされる特定のセグメントを含有する上記フュージョンノードである。

再度、CompositionVersionが提供されていない場合には、本システムは上記最新のバージョンに戻る。

上記GetStreamInfo方法をさらに用いて、上記プレーヤーが再現しなければならない種類のセグメント（または基礎ストリーム）を取得する。

例えば、上記方法により、以下の構造が映像ストリームと音声ストリームのそれぞれに対して戻される。

映像ストリーム情報の一例：

音声ストリーム情報の一例：

上記GetStreamSegments方法はさらに、制限された時間中に基礎ストリームのすべてのセグメントを検索するために役に立ち得る。

上記方法により、所定の基礎ストリームからなるセグメントのリストが戻される。以下の例では、２３時３０分と００時１０分の間に利用できる当該セグメントに対する問合せが行われる。

上記フュージョンストリームと上記フュージョンノードの構造、および、それらを検索するために用いることができる方法を定義したので、本システム、上記エディターおよび上記プレーヤー・アプリケーションがフュージョンストリームと共に作動し、それらを解釈できるように、フュージョンストリームがどのように実行され得るかに関する例を説明する。

基本的なシナリオ：データ・ストリームの記録

映像監視システムの主要な目標は、事件が発生して証拠を見つけなければならない場合に、監視カメラによって送信される映像ストリームを記録し、かつ、その記録を実現かつ再生することである。上述のように、フュージョンストリームを用いて、本システムはさらに、ストリーム・ソース１３ａから基礎ストリーム（映像、音声など）を記録するが、それと同時に、モジュール１３ｂは、上記シナリオの記録に対する新しい入力点（またはルート・ノード）になるフュージョンストリームの作成および記録を行う。

現在の基本的なシナリオでは、本システムは、自動的に映像ストリーム、音声ストリーム、メタデータのストリームを記録するように構成される（この例では、ＧＰＳ座標）。これらは、図１のブロック図のストリーム・ソース１３ａのすべての部分である。シティー・バスには、映像を記録するカメラが設置可能になっており、その同じバスに設置した別個のデバイスにより、音声とＧＰＳ、座標のストリームが生成できる。各基礎ストリームを記録するときに、本システムのモジュール１３ｂはさらに、関係しているセグメントを基準化するために多数のフュージョンノードを作成することによって、フュージョンストリームも記録する。各セグメントは、特定の量のデータ、しかるに有限の時間を含有するファイルを基準化する。

以下に示すのは、２２時５５分と２３時０５分の間にデータを探索したときに戻されるノードを有するフュージョンストリームであり、先行するフュージョンノードと次のフュージョンノードにより制限された現行のフュージョンノードの時間間隔である。この例では、次のフュージョンノードは、２３時０５分に開始される。さらに、当該セグメントを検索するために、当該サーバのcloudarchiving.genetec.comの問合せを行い得ることも示している。

フュージョンストリーム：

フュージョンノード：

図５は、上記フュージョンノードの時間間隔の概略図である。

シナリオ／フュージョンストリーム生成器１３ｂは、セキュリティ監視システムにおいて、フュージョンストリームの格納を維持し、かつ管理するためのソフトウェア構成部であってもよい。モジュール１３ｂは、セキュリティ監視システムの中核となるアーカイブ保管構成部上に構築されてもよい。

ここで、図１６を参照して、フュージョンストリームをサポートするために作り変えられた、セキュリティ監視システムの作り変えられた中核となるアーカイブ保管構成部である例示的なフュージョンのアーカイバー２１０を示している。フュージョンのアーカイバー２１０は、フュージョンのエンジン２０９と標準のアーカイバー１１０を有する。標準のアーカイバー１１０は、ソース・デバイス、典型的に映像と音声のエンコーディング・デバイスからの映像ストリーム、音声ストリーム、および他のデータ・ストリーム（例えば、映像の分析論）を記録するために用いられる。標準のアーカイバー１００を用いることにより、どのデバイスを記録するか、多数のストリーム（例えば、H.264、MPEG-4およびMJPEG）がデバイスから利用できるときに、どの特定のストリームを記録するか、当該ディスクの空きが不十分になるときにその記録が自動削除から保護されることになっている場合に、かつ、当該記録が別の標準のアーカイバー１１０に複写されて重複機能を果たすアーカイブ保管を提供することになっている場合に、当該記録用にどの計画を用いるかを指定してもよい。これらはすべて、標準のアーカイバー１１０が現行で提供する重要な性能である。ディスクの管理は、標準のアーカイバー１１０が提供する別の性能でもある。アーカイブを記録している最中のある時点で、格納されるより新しい記録のためのディスクの空きが不十分になるかもしれない。標準のアーカイバー１１０は、当該ディスクの空きが新しい記録のために不十分になるたびに、より古い記録がそのディスクから自動的に削除されるべきかどうかを決定するために、環境設定の選択肢を提供してもよい。いくらかの実施の形態では、上記環境設定の選択肢はさらに、最も古い記録を別のバックアップ用の格納デバイスに移動させることもできる。いくらかの実施の形態では、新しい記録は、そのディスクが一杯になるときは単に廃棄されてもよいが、その場合には、即座の応答を要求するために、システムの警報が発せられよう。

図１５は、ソース・デバイスからのデータ・ストリームの記録に関係している例示的な標準のアーカイバー１１０の内部の構成部を示す。標準のアーカイバー１１０を統制するものは、アーカイブ・マネージャー１００である。アーカイブ・マネージャー１００は、ソース・デバイスのリスト、記録する各ソース・デバイスからの１つまたは多数のストリーム、環境設定データベース１０４においてアーカイブ・マネージャー１００によって維持されるリストを用いて構成されてもよい。アーカイブ・マネージャー１００はさらに、各ソースに関連する記録計画のリストを用いて構成されてもよい。各ソースに関連する記録計画のリストも、環境設定データベース１０４に維持される。これらの環境設定パラメータは、クライアント・アプリケーションからアーカイバー・インターフェース１０１を介して受信される。そのクライアント・アプリケーションは、例えば、ユーザから上記環境設定パラメータを収集するユーザ・インターフェースを有するアプリケーションであってもよい。そのクライアント・アプリケーションはさらに、ファイルから当該環境設定パラメータを読取り、それらがアーカイバー・インターフェース１０１を介してアーカイブ・マネージャー１００に送信されるファイル読取り機であってもよい。いくらかの他の実施の形態では、クライアント・アプリケーションは、環境設定の変更を必要とする上記セキュリティ監視システムの別の構成部であってもよい。これらの他の実施の形態では、当該環境設定パラメータは、アーカイバー・インターフェース１０１を介して送信されてもよい。アーカイブ・マネージャー１００は、環境設定データベース１０４に維持されている上記環境設定された記録計画に従って、自動的に上記記録の開始および停止を行ってもよい。アーカイブ・マネージャー１００はさらに、アーカイバー・インターフェース１０１から受信した指令に続けて、当該記録の開始および停止を行ってもよい。そのような指令は、ユーザがクライアント・アプリケーションを用いて当該記録の開始および停止を手動で行ったときに、あるいは、上記セキュリティ監視システムに特定のイベントが引き起こされたときに記録が開始されたときに、生成されてもよい。そのような場合では、上記クライアント・アプリケーションは、イベントが受信されたときに記録を開始するように構成したイベント取扱いモジュールであってもよい。アーカイブ・マネージャー１００により自動的であろうと、アーカイバー・インターフェース１０１から受信した指令により手動であろうと、記録が開始するといつでも、アーカイブ・マネージャー１００は、その記録を取り扱うために、ストリーム・レコーダー１０２を作成する。アーカイブ・マネージャー１００は、上記ソース・デバイスのＵＲＬに記録するストリームの同一性を提供する。アーカイブ・マネージャー１００は記録しながら、そのストリーム・プロパティをストリーム・レコーダー１０２からリアルタイムで受信し、ストリームデータベース１０５にそれらを格納する。当該ストリーム・プロパティは、ストリーム・レコーダー１０２が作成した各セグメントのファイルのＵＲＬ、記録されたストリームの種類（映像、音声、マスキング、テキストなど）、ストリームのバイトの大きさ、およびその時間の長さを含む。当該ストリーム・プロパティはさらに、保護と複写のインジケータ、および、例えば映像ストリームと関連づけられた音声ストリームなど、他のストリームとのリンクを含むことができる。ストリームデータベース１０５に格納されたそのような情報はその後、標準のアーカイバー１１０がアーカイバー・インターフェース１０１を介して問合せを受けたときに用いることにより、ディスク上で利用できるアーカイブのリストを戻すことができる。

クライアント・アプリケーションにより、アーカイバー・インターフェース１０１が用いられ、アーカイブ・マネージャー１００の環境設定と操作を行われる。アーカイバー・インターフェース１０１は、ソースの付加および削除、記録計画の付加および削除、各ソースに対して記録するストリームの選択、記録の開始および停止などを行う指令を受信してもよい。アーカイバー・インターフェース１０１はさらに、各指令の状態を戻すことができる。これは、ブール値を用いて行われるが、このブール値は、その指令は成功した、もしくは、実行できなかったことを指し示し、どちらの場合でも、エラーの状態が指示と共に戻される。アーカイバー・インターフェース１０１を介して、クライアント・アプリケーションはさらに、環境設定データベース１０４に格納された上記現行の環境設定パラメータ、ストリームデータベース１０５に格納された上記ストリーム・プロパティ、または、リソースサーバ１０６が格納したアーカイブのファイル自体に対して、アーカイブ・マネージャー１００に問合せを行うことができる。ストリームデータベース１０５は、どのリソースサーバ１０６が記録に関連する各ファイルを格納するかについての詳細を提供する。アーカイバー・インターフェース１０１を介して、アプリケーションにより、手動で記録を開始することもできる。アーカイブ・マネージャー１００は、記録を開始するとき、ストリームデータの格納を管理するためにストリーム・レコーダー１０２を作成し、今度は、上記ソースから上記データを受信するために、ストリーム・レコーダー１０２がストリーム・ソース受信器１０３を作成してもよい。標準のアーカイバー１１０はさらに、再生目的のために、アーカイブを要求してもよい（図示略）。

標準のアーカイバー１１０は、ソースからのデータのストリームの記録を管理するために、１つまたは複数のストリーム・レコーダー１０２の例を提供してもよい。ソースから記録する各ストリームに対して、アーカイブ・マネージャー１００は、そのソースのＵＲＬと記録する特定のストリームを渡すことによって、ストリーム・レコーダー１０２を作成する。従って、一意的なソースから記録する１つのストリームごとに、１つのストリーム・レコーダー１０２の例がある。このストリーム・レコーダー１０２は、上記ストリームデータの格納を管理する。このストリーム・レコーダー１０２は、記録中に上記セグメントのファイルを作成するが、各ファイルはそのストリームの一部を含有する。ストリーム・レコーダー１０２は、それらのストリーム・プロパティを、ストリームデータベース１０５にそれらを格納するアーカイブ・マネージャー１００に戻す。ストリーム・レコーダー１０２は、今度は、上記ＵＲＬを用いて上記ソースに接続して、それから当該ストリームデータを受信するために、ストリーム・ソース受信器１０３を作成する。ストリーム・ソース受信器１０３は、当該ストリームデータを取得するために、ストリーム・レコーダー１０２から受信される要求に応じて、そのデータを一時的に格納するために用いるデータ・バッファを有する。この時点で、ストリーム・ソース受信器１０３は、そのデータ・バッファに一時的に格納されたデータをストリーム・レコーダー１０２に戻し、今度はそれが、リソースサーバ１０６上に作成された上記現行のセグメントのファイルに当該データを格納する。ストリーム・ソース受信器１０３は、そのソースに対する接続を維持し、上記ストリームデータを受信して一時的に格納し、ストリーム・ソース受信器１０３がストリーム・レコーダー１０２によって削除されるまで、当該ストリームデータを戻す。ストリーム・レコーダー１０２による、このストリーム・ソース受信器１０３の削除は、記録が停止されるときに、ストリーム・レコーダー１０２自体がアーカイブ・マネージャー１００によって削除される前に行われる。

記録しているときに、ストリーム・レコーダー１０２は、環境設定データベース１０４に維持された上記環境設定パラメータに従って、リソースサーバ１０６上に上記ストリームの部分（セグメント）を格納するために必要なファイルを作成する。クライアント・アプリケーションが、そのような環境設定パラメータをアーカイブ・マネージャー１００にアーカイバー・インターフェース１０１を介して提供する。その環境設定パラメータは、当該ファイルが含有すべき、ファイルごとに最大限のバイトの大きさ、または最大限の（例えば、分単位の）長さを含んでもよい。各ファイルは、ストリームのセグメントを表し、各セグメントはリソースサーバ１０６上に格納される。ストリーム・レコーダー１０２は、上記環境設定パラメータに続けて、当該ストリームのセグメントを格納するためにリソースサーバ１０６上に必要な数量のファイルを作成する。各セグメントのプロパティ（ストリーム・プロパティ）は、ストリームデータベース１０５に格納するために、アーカイブ・マネージャー１００に送信される。別の実施の形態では、ストリーム・レコーダー１０２はさらに、そのストリーム・プロパティをストリームデータベース１０５に直接に書き込むことによって、アーカイブ・マネージャー１００が後に必要なときにそれらを問い合わせてもよい。リソースサーバ１０６は、上記ストリームを記録するために十分なスペースを提供できるファイル・サーバ、ＮＡＳ、クラウドのプラットフォーム上の格納ロケーションなどを用いて、実行されてもよい。

本明細書に記載しているように、ストリームデータベース１０５は、セグメントのファイルについての情報（ストリーム・プロパティ）を格納する。すなわち、ファイルのロケーション（ＵＲＬ）、ファイルの大きさ、セグメントの長さ、保護インジケータ、他のストリームとのリンクである。データベースを用いて、情報にインデックスを付けることにより、問合せを促進できるが、情報をファイルに維持することもできる。データベースが用いられるときに、データベース管理システム（例えば、MySQL、Microsoft SQL Server、Oracleなど）を用いて、情報を構造化してもよい。同様に、環境設定データベース１０４は、アーカイブ・マネージャー１００の上記環境設定パラメータを格納する。すなわち、ソースのリスト、記録計画、記録するストリームなどである。その環境設定パラメータを、データベース管理システム（例えば、MySQL、Microsoft SQL Server、Oracleなど）を用いて格納してもよいし、かつ／あるいは、ファイルに維持することもできる。

上述した現在の標準のアーカイバー１１０があれば、リソースサーバ１０６に格納されたストリームの間に存在する明確な関連がないことを、当業者は理解するであろう。ストリームの間、例えば、映像ストリームとその音声ストリームの間の関連は、別個にストリームデータベース１０５に格納されて、アーカイブ・マネージャー１００により維持される。ストリームデータベース１０５が失われた場合には、リソースサーバ１０６に格納されたストリームの間の関連は、手動の介在なしにリストアされないかもしれない。しかし、この問題を、フュージョンストリームを用いて解決してもよい。

図１６を参照して、フュージョンストリームの作成と管理をサポートするために、フュージョンのエンジン２０９を用いて改良された標準のアーカイバー１１０を有する上記例示的なフュージョンのアーカイバー２１０を示している。フュージョンのエンジン２０９は、４個の構成部からなる。それらは、フュージョン・マネージャー２００、フュージョン・インターフェース２０１、フュージョン・レコーダー２０２およびフュージョンストリーム・リポジトリ２０６である。フュージョン・マネージャー２００は、フュージョンのエンジン２０９と、フュージョンのアーカイバー２１０を統制するものである。標準のアーカイバー１１０の観点から見れば、フュージョンのエンジン２０９は、アーカイバー・インターフェース１０１を介して、アーカイブ・マネージャー１００と通信するクライアント・アプリケーションであり、それは他のクライアント・アプリケーションでも行うであろう。フュージョンのエンジン２０９は、フュージョンストリームの性能を提供するために、標準のアーカイバー１１０の上に追加のインターフェース層を提供する。この層を付加することにより、フュージョンのアーカイバー２１０は、標準のアーカイバー１１０が提供するロバスト性能を使用して、そのアーカイブ（保護、保持、重複機能の実行、ディスク管理）を管理する。これは、当該アーカイブが、標準のアーカイバー１１０によって自動的に生成される（計画通りの記録、手動による記録）、もしくは、基礎ストリームがフュージョンストリームに含められるように用いられる場合であっても行われる。

フュージョン・マネージャー２００は、フュージョンストリーム・リポジトリ２０６において、フュージョンストリームのリストを維持するが、論理回路のシナリオとも呼ばれる。各フュージョンストリームに対して、フュージョンストリーム・リポジトリ２０６は、上記フュージョンストリーム・プロパティを格納する。すなわち、一意的な識別名（ＧＵＩＤ）、コンポジション・パラメータおよびフュージョンノードである。フュージョンストリーム・リポジトリ２０６は、バージョン化システムを実行して、フュージョンストリームに対してなされたすべての変化を追跡して、各ストリームの過去のバージョンを保つことができる。フュージョンストリーム・リポジトリ２０６は、Gitモデルと類似したバージョン化システムを用いるが、Apache SubversionおよびSVNなどの他のバージョン化システムを用いることができる。バージョン化システムを用いるときに、フュージョンストリーム・リポジトリ２０６が、それを管理する。フュージョンストリームのコンポジションが変化するときに（フュージョンノードの付加または削除が行われる、コンポジション・パラメータが修正されるなど）、フュージョンストリーム・リポジトリ２０６は、そのフュージョンストリームの新しいバージョンを作成する。より古いバージョンは、当該バージョン化システムによって自動的に保たれる。フュージョンストリームのより古いバージョンは、そのバージョン番号をフュージョンストリーム・リポジトリ２０６に渡すことによって要求できるため、当該バージョン化システムからその適切なバージョンを検索できる。フュージョンストリーム・リポジトリ２０６は、データベース管理システムを用いて情報にインデックスを付けることにより、問合せを促進できるが、その同じ情報をファイルに維持することもできる。任意のデータベース管理システム（例えば、MySQL、Microsoft SQL Server、Oracleなど）を用いて、フュージョンストリーム・リポジトリ２０６を実行してもよい。

各フュージョンストリームは、一連のフュージョンノードである。各フュージョンノードは、当該フュージョンノードが包含する期間中、論理回路のシナリオを構成している基礎ストリームのセグメントを提供する。いくらかの実施の形態では、上記フュージョンストリームに含まれる当該基礎ストリームのセグメントは、フュージョン・マネージャー２００によって維持されない。その代わりに、当該フュージョンノードは、フュージョン・インターフェース２０１を介して、アーカイブ・マネージャー１００によって、もしくは、クライアント・アプリケーションによって提供されるストリーム・プロパティから、それらを基準化する。当該基礎ストリーム（より正確には、それらのセグメント）は、アーカイブ・マネージャー１００によって維持され、標準のアーカイバー１１０内のリソースサーバ１０６上に格納される。自動的に記録を開始できるアーカイブ・マネージャー１００とは逆に、フュージョン・マネージャー２００は、自動的にフュージョンストリームの記録を開始しない。その代わりに、フュージョン・マネージャー２００は、フュージョン・インターフェース２０１を介して、クライアント・アプリケーションから記録の指令を受信する。クライアント・アプリケーションは、フュージョン・インターフェース２０１を用いて指令をフュージョン・マネージャー２００に送信することにより、フュージョンストリームのリスト（または、問合せフィルターに従って下位セット）の取得、フュージョンストリームの作成または削除、フュージョンストリームの保護または自由なアクセス可能、ストリームの暗号化に用いる認証物の付加または削除、フュージョンストリームから基礎ストリームの付加または削除、および、基礎ストリームに対する新しいシーケンスの付加を行う。フュージョン・インターフェース２０１はさらに、各指令の状態を戻して、その指令が成功したかどうかの指摘を提供し、どの場合にエラーの原因を有するエラー・メッセージがあるかということも戻される。フュージョン・インターフェース２０１はさらに、クライアント・アプリケーションが問い合わせたフュージョンストリーム、基礎ストリームに対する参照、基礎ストリームのセグメント、およびフュージョン・レコーダー２０２の例を戻す。

クライアント・アプリケーションが新しいフュージョンストリームを作成して、それに映像の基礎ストリームを付加するときに、フュージョンのエンジン２０９は、標準のアーカイバー１１０と共に作動してもよい。フュージョンのエンジン２０９は、そのクライアント・アプリケーションに利用できるDirect Link Liberty （ＤＬＬ）ファイルとして実行される。ＤＬＬにリンクさせることにより、当該クライアント・アプリケーションは、フュージョンのエンジン２０９にリンクされて、ＤＬＬで定義されたフュージョン・インターフェース２０１に対するアクセスを取得する。フュージョン・インターフェース２０１を介して、当該クライアント・アプリケーションは、フュージョンのアーカイバー２１０に接続され、当該クライアント・アプリケーションはそこから、フュージョンストリーム・リポジトリ２０６にアクセスすることを所望する。当該クライアント・アプリケーションは、archiverRoleのパラメータで、接続されるフュージョンのアーカイバー２１０を指定することによって、フュージョン・インターフェース２０１が提供する以下の方法を用いる。

クライアント・アプリケーションは、フュージョンのエンジン２０９を用いて、ネットワーク上で利用できるフュージョンのアーカイバー２１０に接続してもよい。その所有者のパラメータを用いれば、フュージョンストリームを一意的な所有者の識別名のもとで分類することが可能になる。これは、多数のフュージョンストリーム・リポジトリ２０６を同じサーバ上に格納できることを意味する。例えば、Owner_Aのもとで作成されたフュージョンストリームは、Owner_Aのリポジトリを検索するときにしか容易に見られないであろう。他の所有者に属するフュージョンストリームは、戻されないであろう。そのリポジトリに一度接続すれば、上記クライアント・アプリケーションは、フュージョンストリーム・リポジトリ２０６上に格納されたフュージョンストリームのリストを取得できる。この例では、新しいフュージョンストリームは、フュージョン・インターフェース２０１が提供する以下の方法を用いて、当該リポジトリで作成される。

フュージョン・マネージャー２００は、フュージョン・インターフェース２０１を介して、フュージョンストリームを作成する指令を受信し、フュージョンストリーム・リポジトリ２０６に新しいフュージョンストリームを作成する。そのフュージョンストリームは、どんな基礎ストリームもまだ含有していないが、１つのフュージョンノードが、基礎ストリームに対する参照なしに付加される。それから、フュージョン・マネージャー２００は、その新しく作成したフュージョンストリームにFusionStreamの参照を戻す。手元のフュージョンストリームをこのように参照して、上記クライアント・アプリケーションはここで、基礎ストリームをそのコンポジションに付加してもよい。これは、戻されたフュージョンストリームの参照の上で、以下の方法を用いることによりなされてもよい。

例えば、上記フュージョンストリームの参照がそのコードでfsRefと呼ばれる場合には、次のように、上記方法をfsRef上で呼び出してもよい。

フュージョン・マネージャー２００は基礎ストリームを管理しないので、フュージョン・マネージャー２００はアーカイブ・マネージャー１００に依存する。その基礎ストリームは、標準のアーカイバー１１０にすでに存在するかもしれないし、あるいは、それはまったく新しいかもしれない（それまでに記録されたデータがない）。基礎ストリームが付加されるときに、フュージョン・マネージャー２００は、新しいフュージョンノードを作成し、それをフュージョンストリーム・リポジトリ２０６に格納する。フュージョンノードは、基礎ストリームが上記フュージョンストリームを構成するという指摘を含有する。基礎ストリームがすでに存在している場合には、フュージョン・マネージャー２００は、アーカイバー・インターフェース１０１を介して、アーカイブ・マネージャー１００に要求を送ることにより、特定のＧＵＩＤで識別された、それに該当する基礎ストリームのストリーム・プロパティを取得する。ユーザは、どの基礎ストリームを当該フュージョンストリームに付加したいかを認識しているので、上記クライアント・アプリケーションは、上記ＧＵＩＤをフュージョン・マネージャー２００に提供できる。今度は、上記ＧＵＩＤをアーカイブ・マネージャー１００に提供する。さらに正確に言えば、フュージョン・マネージャー２００は、上記ＧＵＩＤで識別された上記基礎ストリームを構成する各セグメントのプロパティを要求する。アーカイブ・マネージャー１００から受信した各セグメントに対して、フュージョン・マネージャー２００は、そのセグメントのＵＲＬと、それが包含する期間とを指し示すフュージョンノードを作成する。上記ＵＲＬは、当該セグメントと、まさにそのファイルとをそのサーバ上に格納するリソースサーバ１０６を提供する。

この例では、上記基礎ストリームのために記録されたデータはまだない。単独で機能する標準のアーカイバー１１０の例とは違って、フュージョンのアーカイバー２１０は、クライアント・アプリケーションが標準のアーカイバー１１０の既存の性能に対抗して、一連のデータを予期しないで、かつ非同期的にフュージョンのアーカイバー２１０にプッシュできるという利点を有する。それにより、（クライアント・アプリケーションではなく）ソースに接続して、そのソースから直接にストリームデータを同期的に、かつ連続的な方式で受信する。フュージョンストリームがあれば、事後に基礎ストリームを記録することが可能になる。すなわち、それは既に過去に属するデータを用いる。標準のアーカイバー１１０により、既知のソースから予測可能に受信されるように、データがリアルタイムで記録されて、受信するとすぐにそれを格納する。フュージョンストリームがあれば、標準のアーカイバー１１０は、過去のデータに対する新しい基礎ストリームを記録する性能を有し、上記ソースはここで、予測不可能な、かつ連続的でない方式で有限の一連のデータを送信するであろうクライアント・アプリケーションであるということが認識される。標準のアーカイバー１１０は、フュージョン・インターフェース２０１を介して、クライアント・アプリケーションによってデータを大量にそれにプッシュすること可能にする。従って、そのモデルは、標準のストリームと比較して、フュージョンストリームに対して逆になっている。さらに、標準のアーカイバー１１０は、既存の基礎ストリーム内のデータ挿入を可能にして、そのデータは過去に属する。フュージョンストリームをサポートするために、標準のアーカイバー１１０は、新しいフュージョンストリームを過去のデータと共に記録し、過去のデータを既存の基礎ストリーム内に挿入できる。

さらに、フュージョンのアーカイバー２１０のアーカイバー・インターフェース１０１は、新しい指令がアーカイブ・マネージャー１００に送られることを可能にする。その新しい指令により、データがフュージョン・レコーダー２０２からストリーム・レコーダー１０２に直接にプッシュされようことが、アーカイブ・マネージャー１００に指し示される。ストリーム・ソース受信器１０３が標準のアーカイバー１１０である場合と同様のソースである代わりに、フュージョン・レコーダー２０２はそれ自体で、あるいは、図１６に示すようにストリーム・ソース受信器１０３と組み合わせて、効果的なストリーム・ソース受信器になり得る。さらに、ソースに接続して、そのストリームデータを標準のアーカイバー１１０内で受信する必要がないので、ストリーム・ソース受信器１０３を例証する必要がない。ストリーム・レコーダー１０２はさらに、ストリームデータがフュージョン・レコーダー２０２から、それにプッシュされることを可能にしてもよい。アーカイブ・マネージャー１００とストリーム・レコーダー１０２に送信され得る新しい指令により、ストリーム・ソース受信器１０３の代わりに上記ソースであるような、このようなフュージョン・レコーダー２０２の選択が可能になる。

一例では、上記クライアント・アプリケーションは、過去の映像データを用いて新しいセグメントを作成し、先行して作成された当該映像の基礎ストリームにそれを付加する。フュージョン・インターフェース２０１の以下の方法を用いることにより、これを実現できる。

上述の方法AddNewVideoElementaryStreamによって戻されるIElementaryStreamのオブジェクトが、上述の方法AddNewVideoSequenceに渡されて、ISequenceWriterのオブジェクトが取得され、それを用いて、上記クライアント・アプリケーションは、そのデータを上記新しいセグメントに書き込んでもよい。ISequenceWriterのオブジェクトは、図１６のフュージョン・レコーダー２０２に相当する。それから、そのアプリケーションは、このオブジェクトを用いて、下記の方法WriteAsyncを呼び出して、その映像シーケンスのフレームをストリーム・レコーダー１０２にプッシュすることができる。

フュージョン・レコーダー２０２は、上記クライアント・アプリケーションから上記基礎ストリームに付加されるデータを受信する。それから、フュージョン・レコーダー２０２は、ストリーム・ソース受信器１０３の代わりにフュージョン・レコーダー２０２から直接に、そのデータを受信する用意ができたストリーム・レコーダー１０２に、そのデータをプッシュする。上記セグメントはなお、ストリーム・レコーダー１０２に管理されていて、それは環境設定データベース１０４に格納された環境設定パラメータに従って、当該データを格納するために必要な同数のセグメントを作成する。ストリーム・レコーダー１０２はさらに、上記ストリーム・プロパティ（セグメントの識別名、ロケーション、ファイル名など）を、フュージョン・マネージャー２００にアーカイブ・マネージャー１００とアーカイバー・インターフェース１０１を介して戻す。それから、フュージョン・マネージャー２００は、当該ストリーム・プロパティをフュージョン・レコーダー２０２に転送することにより、時間と共に上記フュージョンストリームのコンポジションを描写するフュージョンノードを作成し、上記基礎ストリームの新しいセグメントがそれぞれ、ストリーム・レコーダー１０２により生成されるときに基準化される。

既存の基礎ストリームをフュージョンストリームに付加するときに、フュージョン・マネージャー２００は、新しいフュージョンノードを作成して、そのフュージョンストリームに付加する。この状況で、フュージョン・マネージャー２００は、アーカイバー・インターフェース１０１を介して、上記ストリーム・プロパティを問い合わせ、アーカイブ・マネージャー１００によって戻される、上記基礎ストリームの各セグメントのロケーションを指し示す当該新しいフュージョンノードを用いて、上記フュージョンストリームを更新する。上記クライアント・アプリケーションが基礎ストリームに関連するデータをプッシュする状況で、アーカイブ・マネージャー１００とアーカイバー・インターフェース１０１を介して、ストリーム・レコーダー１０２から受信する上記ストリーム・プロパティに従って、フュージョン・レコーダー２０２によって、上記フュージョンノードが作成されて付与される。別の実施の形態では、そのストリーム・プロパティはさらに、フュージョン・インターフェース２０１を介して、上記クライアント・アプリケーションによっても提供されることもでき、その場合では、当該ストリーム・プロパティは、上記基礎ストリームを付加する指令を用いて渡すことができる。

フュージョンストリームの再現

上記プログラム作成インターフェースを用いて、フュージョンストリームのプレーヤーは、上記ストリーム情報を検索できるが、この場合では、暗号化されない上述したH.264のフォーマットを用いてエンコードされる映像ストリームである。上記プレーヤーはさらに、そのストリームのソースのデバイス識別名を検索できる。その同じ論理が、当該フュージョンストリームの一部である、すべての基礎ストリーム（セグメント）にも適用される。

上記ユーザが例えば、図６に示すように、２３時３０分にその記録の再生を所望する場合には、そのプレーヤーは最初に、上記フュージョンストリームの定義を読み出し、当該要求された時間に対応する上記フュージョンノードを検索し、それらのロケーションで用いるセグメント（ファイル・サーバ、ディスクドライブ、ＮＡＳなど）を検索し、選択的なオフセット属性に従って、それらを組み合わせる。

すべてのセグメントを同じ時間ＴＸにプレーさせることによって、上記基礎ストリームの同期化を行う。特定のセグメントに対して、時間ＴＸに利用できるデータがない場合には、読み出されているセグメントの種類に依存して、最後の利用できるデータ（暗号化キーなど）を探すための探索を行う、あるいは、このストリームに対して再現されるデータが単に存在しない（時間ＴＸに音声または映像データが存在しないなど）。このような最後の利用できるデータを探索する、もしくは、例えばキーのストリームに対する映像または音声ストリームなどのストリームの種類に依存しない判定は、上記コンポジション・パラメータの一部である。オフセット属性が提供される場合に、上記プレーヤーのアプリケーションは、当該セグメントのすべてを組み合わせるときに、このオフセットを再生時間に適用する。オフセットの説明は後述するが、ここでは省略する。

図７のブロック図は、特定の実施の形態を行うために実行されるアプリケーション・プログラムのモジュールを示す。図７に示すモジュールは、プログラム記憶素子１０ｃ（図２に示す）におけるソフトウェアにより駆動できるが、評価されているように、グラフィックス再現用のコンピュータ・ハードウェア、音声生成、およびネットワーク通信との相互作用を伴うことができる。

モジュール１５は、シナリオを選択し、検索するためのユーザ・インターフェースを提供する。図８では、これはステップＳ１およびＳ２に対応する。上述したように、そのユーザは、ロケーションと時間の範囲を指定でき、モジュール１５は、符合するフュージョンストリームを求めて、格納装置１１をサーチし、それらを検索し、フュージョンストリームのリストを当該ユーザに提示する。このリストから、当該ユーザは、そのユーザが探している特定のフュージョンストリームを選択できる。モジュール１７は、シナリオを再生し始める時間（ＴＸ、図８のステップＳ３）を選択するためのユーザ・インターフェースを提供する。次に、モジュール１７は、上述の説明から理解され得るように、ＴＸに対応するフュージョンノードのデータセットから当該セグメントのリストを抽出し、上記同一物をモジュール２１に提供する（図８のステップＳ４およびＳ５）。モジュール１７はさらに、その許可レベル、または任意の他の適切な許可制御データを抽出し、上記同一物をモジュール１９に提供する。モジュール１９は、当該ユーザが当該セグメントのそれぞれを視聴するように認可されているかどうかを判定する。

モジュール１９は、上記許可レベルをコンピュータ１０の設定値と比較する数行のコードと同じくらい単純であり得る。そこでは、コンピュータ１０が固定された認可レベルを有するように決定される。モジュール１９は、そのユーザが認可されているかどうかを判定するために、コンピュータ１０および／または当該ユーザと相互作用する認可サーバ（図示略）との相互作用を伴い得る。ＩＣカード読取り機または虹彩スキャナーを、例えば、ユーザに認可のために、ワークステーション１０内に統合することができる。コンピュータ１０が個人または組織の特定レベルの認可と一意的に関連づけられているときに、コンピュータ１０のハードウェアに基づいたセキュリティの特徴を用いることもできる。さらに、許可が、そのユーザの認証物をセグメントに、より一般的には、ストリームのソースにリンクさせることによって付与され得る。さらに加えて、当該セグメントが暗号化される場合に、モジュール１９は、当該ユーザが適切な個人キーを有するセグメントであるかを判定できる。一度、許可が判定されたなら、次に、モジュール１９はモジュール２１に、そのセグメントに対する認可情報を提供する。

モジュール２１は、視聴のために、１つまたは複数の利用できる許可されたセグメントを選択するためのユーザ・インターフェースを、任意の特定の時間のマーカー（すなわち、開始時間、または選択的に１つまたは複数の時間の範囲）、および、オフセット、ウインドー、映像ウインドーのテキスト・オーバーレイ（例えば、ビルディングのセキュリティ・バッジ読取り機のデータ、ＧＰＳデータのオーバーレイ、ナンバープレートの認識のオーバーレイ、ユーザの注釈、またはテキスト生成注釈に対するスピーチ）、テキストの表示、静止画像の表示、サウンドトラックの相対的音量などのコンポジションの詳細と共に、提供する。これは、図８のステップＳ６である。モジュール２１はさらに、ステップＳ７で、必要とされる場合にオフセットを適用するためのオフセット属性／指令モジュール２５があるかを判定する。モジュール２１はさらに、ダウンロード・モジュール２３に対して、認可され、かつユーザが選択したセグメントを検索するように要求する（図８のステップＳ８）。いくらかのセグメントが、他のセグメントのために必要とされ得るようにしてもよい。一例は、音声または映像データに対する暗号キーのストリームである。この場合には、ユーザが認可されたストリームをプレーするように求めるときに、それに対応する複号キーのストリームもダウンロードされる。ノード・データは、このような複号のための要件と、ストリームを複号するために必要な当該複号キーのストリームのソースを整理して並べる。

要求され得る映像オーバーレイの第１の例は、副題と類似したテキスト注釈である。このような副題が付いたテキスト・ファイルの作成は、映像ストリームのプレーヤーを含み、かつ、ユーザが、そのテキスト注釈および選択的に当該テキストの位置、大きさと色のプロパティと共に、いつテキスト注釈が現れ、その後当該オーバーレイから削除されることを指定できる、ユーザ・インターフェースを用いて行うことができる。注釈テキスト・ファイルは、データ・ストリームとしても見られるが、上述のプロパティを定義するためにマークアップ言語を用いてフォーマットし、別の基礎ストリームとしてフュージョンストリームに貼り付けることができる。テキスト注釈を取り扱うための注釈処理モジュール２７はそれゆえ、テキスト注釈ストリーム用の読取り機からなり、上記映像ストリームと混合される適切なオーバーレイ画像ストリームを生成するが、それは、所望されるような上記注釈テキストの外観と削除を適正な時間に提供するために上記映像ストリームに関連づけられている。その混合は、デコーディング・モジュール２７内で、または再生デバイス３０で行われ得る。テキストに対するスピーチのアプリケーションはそれから、フュージョンストリームを用いて、上記テキスト・ストリームをそれが適用する上記映像および音声ストリームと関連づけて、格納することできる。

要求され得る映像オーバーレイの第２の例は、画像注釈である。このような画像注釈データの作成は、映像ストリームのプレーヤーを含み、かつ、ユーザが編集および注釈機能を行い得るユーザ・インターフェースを用いて行うことができる。このような機能の制限しない例は、その画像の明るさとコントラストを対象とする選択領域の内側でおよび／または外側で調節し、（対象とするオブジェクトまたは人を丸で囲む、対象とするオブジェクトまたは人を指す矢印を描くなどの）マークアップ線を描き、対象とされない映像の一部の画像内で拡大とオーバーレイのために対象とする領域を選択することである。画像注釈ファイルは、データ・ストリームとしても見られるが、上記対象とする領域、および／または線または形状の形成を定義するためにマークアップ言語を用いてフォーマットし、別の基礎ストリームとして上記フュージョンストリームに貼り付けることができる。テキスト注釈を取り扱うための注釈処理モジュール２７はそれゆえ、画像注釈ストリーム用の読取り機からなり、上記映像ストリームと混合される適切なオーバーレイ画像ストリームを生成するが、それは、所望されるような上記画像注釈の外観と削除を適正な時間に提供するために上記映像ストリームに関連づけられている。その混合は、デコーディング・モジュール２７内で、または再生デバイス３０で行われ得る。

既に説明したように、ダウンロード・モジュール２３は、上記フュージョンノードで見つけられた選択したセグメントの定義から、検索されるリソースのロケーションを識別し、リソースサーバ１２から受信したデータのダウンロード要求とバッファリングを管理する。

図７の実施の形態では、実行を容易にするために、モジュール２１は、モジュール２７および／または再生デバイス３０で利用できるデコーディングおよびコンポジション・リソースについての特定の環境設定または知識なしに、コンポジション・パラメータを提供する。このような直接の制御が可能であってもよいが、コンポジション指示書のコンパイラモジュール２５を導入することにより、ユーザ・インターフェース２１から発信される指令が、ソフトウェアおよび／またはハードウェアのデコーダ、および運転者特定および／またはオペレーティング・システム特定の指示書に変換可能になる。モジュール２５は、検索するストリームの種類を提供し、上記ダウンロードしたストリームまたはファイル（セグメント）をデコードするために、どのデコーダを用いるべきかを判定する。例えば、デコーディングのパラメータは、モジュール２５が送るソフトウェア・モジュール呼出しパラメータにより提供できる。上述した音声混合、映像オーバーレイ／重ね合わせ、映像ウインドーの大きさ、および位置パラメータは、当該呼出しにより、再現のエンジン、デバイスの運転者および／または上記オペレーティング・システムに提供できる。

次に、コンポジション指示書のコンパイラ２５、ストリーム・デコーディングのモジュール２７および再生デバイス３０は協働して、プレーされている上記シナリオのコンポジションに存在する上記音声および／または映像ストリーム（図８のステップＳ９）および／または上記任意の他の基礎ストリームを再現、表示または生成する。

事後に新しいコンテンツを付加

この例では、ユーザは、新しいコンテンツを既存のフュージョンストリームに付加することを所望する。現行の技術を用いて、新しいコンテンツを既存のストリームに付加することは通常、それが映像ストリーム、音声ストリームまたはメタデータ・ストリームであろうと、極めて複雑である。データ・ストリームは、記録後に修正されない不変のデータを含有する。さらに、映像および音声のフォーマットは典型的に、新しい種類のメタデータをそれらのフレーム内で付加するのに十分に順応性のある機構を提供しない。メタデータはそれでもなお、ユーザに対して再現されるときに別のモジュールによって、別個に（例えば、別個のデータベースに）格納し、組み合わせることができるが、関係するデータは、多数のデータベースとサーバに容易に散在され得る。フュージョンストリームは、任意の種類のストリーム（映像、音声、メタデータ、暗号化キーなど）を単一の存在物の中に格納する性能を提供する。このために、ストリームを操作して、記録後に、新しいコンテンツをそれらに付加することがさらに容易になる。

例えば、映像、音声およびＧＰＳの位置のストリームがシティー・バスから記録された場合で、先行するシナリオの記録を考えてみよう。昨晩にバスの中で２人の乗客の間にある出来事が発生し、誰かがスマートフォンで音声／映像の記録を行ったことが事後に見つけられたとしよう。その捜査人は、映像監視システムを用いて、その新しい音声／映像の記録を当該既存のフュージョンストリームに付加するが、それは、捜査の事件を表して知識が向上される。フュージョンストリームの編集アプリケーション（上記映像監視システムとは別個または一部であり得る）、すなわち図１の生成器１３ｂと同じか、あるいは類似しているかのどちらかであるソフトウェア・モジュールを用いて、上記捜査人は、その現存する記録（フュージョンストリーム）を選択し、証拠を付加するためにクリックし、音声と映像のファイルを選択する。ストリームの種類ごとに別個のファイルがあり得る。これを行うために、上記編集アプリケーションは、図４に示したプログラム作成インターフェースからAddNewVideoElementaryStreamおよびAddNewAudioElementaryStreamの方法を呼び出すであろう。ファイルが付加されるとき、モジュール１３ｂは、上記フュージョンストリームを更新して、上記新しい映像および音声のセグメント（以下に、太字で強調）を含むことになる。

フュージョンストリーム

フュージョンノード

上記フュージョンストリームの初期バージョンに対してなされる以下の変更に注意すべきである。
- fusion-composition-version: 上記フュージョンストリームのバージョンは、その元のストリームになされた変更の追跡を保つために増加されるが、その同じＩＤを有する。これにより、組み込まれた監査証跡性能が提供される。
- creation-date: 上記フュージョンストリームの新しいバージョンが作成された日付と時間。
- created-by: 上記フュージョンストリームの新しいバージョンを作成したユーザ。
- fusion-node-guid: 上記フュージョンストリームの新しいバージョンを探すためのフュージョンノードのＩＤ。フュージョンノードは不変なので、新しいセグメントがフュージョンストリームに付加されるときに、新しいフュージョンノードが作成される。
- segments: スマートフォンで行った上記新しい映像と音声記録をリンクさせるために、上記フュージョンノードでは、２つのセグメントが付加される。

別の実施の形態では、図１２は、シナリオの完成を向上させるために、どのようにして、音声コメンタリーのトラックが上記フュージョンストリームに付加され、対応する映像ストリームに容易に関連づけられ得るのかを示す。新しいフュージョンノードを作成し、上記フュージョンストリームのバージョンを変更する同じ機構を用いて、音声コメンタリーのトラックと関連づけられた音声キーのストリームは、その元の映像ストリームまたは映像キーのストリームを修正する必要なしに、上記フュージョンストリームに付加できる。

同期化の調節

プレーヤー・アプリケーションのシステム１０を用いて、上記捜査人は、再生する上記フュージョンストリームを選択する（ステップＳ１）。そのプレーヤーは、上記フュージョンストリームの情報を検索し（ステップＳ２）、上記セグメントのすべてをロードし、それらのプレーを当該ストリームの始まり（Ｔ０）に同期させて開始する。すべてのストリームが常に、時間により同期されるので、タイムスタンプＴＸを有するすべてのフレームが同時にプレーされる。この例では、そのストリームは時間Ｔ０に開始する。

再生中に、上記捜査人は、構成部３０の一部であって図９に示す当該捜査人のディスプレイ・デバイスのタイル１でプレーされるストリームとタイル２でプレーされるストリームの間にオフセットがあることを観察する。これは、上記ストリームが当該同じデバイスによって記録されないときに起こり得るものであり、それらの間にクロックの相違を有し得る。

例えば、上記オフセットが編集された後に格納装置１１に保存され得る、モジュール２１によって、または代わりにモジュール３０を用いて提供された同期化機能を用いて（図８のステップＳ７）、上記捜査人は、オフセットをタイル２のストリームに設定し、それらをタイル１のストリームと適切に同期化させることができる。上記フュージョンストリームを保存しているときに、このように見えるが、付加された情報を以下に太字で強調している。

フュージョンストリーム：

フュージョンノード：

以下の変更は、上記フュージョンストリームの先行するバージョンに対してなされる。
- fusion-composition-version: 上記フュージョンストリームのバージョンが増加される。
- creation-date: 上記フュージョンストリームのこの新しいバージョンの作成の日付と時間。
- fusion-node-guid: 上記フュージョンストリームの新しいバージョンを探すためのフュージョンノードのＩＤ。フュージョンノードは不変なので、新しいセグメントがフュージョンストリームに付加されるときに、新しいフュージョンノードが作成される。
- offset: 上記現行の例において、上記スマートフォンで記録されたセグメントに付加されるコンポジション属性。これは、それらのストリームをBus#1に設置したデバイスによって記録されたストリームと同期化させるために必要とされるミリセカンド単位の遅延を表すことができる。この属性を読み出しているときに、上記プレーヤーは遅延を付加することを認識する。

協働を可能にする

フュージョンストリームは、協働および証拠管理性能を提供しなければならないセキュリティのシステムを設計するときに極めて有用になる。協働により、多数の個人、部門および組織が協働環境で共に働くことが可能になるので、既存のコンテンツを共有できるが、さらに重要なことは、新しいコンテンツを付加することにより、シナリオに関連する知識を向上させることが可能になる。このようなシステムの設計は、フュージョンストリームを用いれば、多大に簡素化されよう。

例えば、上述の事件の捜査人は、その映像ストリームを２つの別個の部門に送信する。第１の部門は動作の分析を行い、第２の部門は、その映像が公開された場合に、（事件の関係する人を除く）乗客が識別されないように画像にマスキングをする。動作の分析は、入力で提供された上記映像ストリームを分析し、その動作レベルを含有する別個のストリームのメタデータを生成する映像分析システムを用いて行う。映像マスキングは、上記映像ストリームを再生するユーザが手動で行い、タッチスクリーン上で当該マウスまたは指をリアルタイムでドラッグすることにより、識別されない状態のままにしなければならない各乗客の顔をマスキングする。これらのマスキングはそれぞれ、別個のマスキングのメタデータ・ストリームを生成する。

ここで、上記２つの部門は、当該作業を完了し、その捜査事件に結果として取得したストリームを付加する用意が今できているとみなそう。当該ストリームには、その事件に対する識別名が提供される。ウェブ・ブラウザを用いて、各部門のユーザは、上記フュージョンストリームが格納されているサーバにログオンし、上記捜査事件に対応するフュージョンストリームを選択し、それに上記新しいストリームを付加する。それらのストリームのすべてが上記フュージョンストリームに付加されるとき、そのフュージョンストリームは下記の例で示すように更新されよう。

フュージョンストリーム：

以下の変更は、上記フュージョンストリームの先行するバージョンに対してなされる。
- fusion-composition-version: 上記フュージョンストリームのバージョンは、上記２つの部門がそれらの新しいコンテンツを付加した後に、５まで増加される。
- creation-date: 上記フュージョンストリームのこの新しいバージョンの作成の日付と時間。
- fusion-node-guid: 上記フュージョンストリームの新しいバージョンを探すためのフュージョンノードのＩＤ。
- segments: 上記新しい動作と上記マスキング・ストリームをリンクさせるために、上記フュージョンノードでは、２つのセグメントが付加される。複数の乗客が隠されるべき場合には、多数のマスキング・ストリームもあり得るであろう。しかし、例示目的のために、１つのマスキング・ストリームのみを付加する。

上記シナリオを再生のために選択するときに、そのプレーヤーは、上記フュージョンストリームを検索し、そのコンポジションを選択した時間に探す。その再生が当該事件が発生した時間（２３時００分）に開始される場合には、当該プレーヤーは、当該フュージョンストリーム内でこの時間に向けて探索し、先に示した７個のセグメントを含有するフュージョンノードを検索する。次に、当該プレーヤーは、その同じ時間ＴＸに同時に各ストリームをプレーして、完全なシナリオを再現する。一例として、図１０に示すように、その全画像で検出される動作の割合を示す縦方向のバーを用いて、動作レベルをそのタイムライン上に示すことができる。

プレーヤー・アプリケーション３０は、ユーザに対して再現されるセグメントのすべてを組み合せて同期化させる能力を有する構成部である。

セグメントは、必要な場合に、フュージョンストリームから削除できる。この場合には、上記プレーヤー・アプリケーションは、図１４に示すプログラム作成インターフェースからRemoveElementaryStreamの方法を用いることができる。バージョン化機構を用いて、時間と共にフュージョンストリームになされた変更のすべてを追跡することができるので、より古い。バージョンを検索することが常に可能になる。フュージョンストリームのバージョン化はさらに、監査が行われるときに有用になり得る環境設定変更の通報（監査証跡）を提供する。

これらの実施の形態が、メタデータの各ストリームをどのように構造化すべきかを定義するものではないことに注目すべきである（動作ストリームなど）。当該プレーヤーは、標準のフォーマット（H.264など）を用いる各セグメントのデコード方法、ならびに、所有者のフォーマットを用いてエンコードされるセグメントを認識していると想定される。

情報の保護

そのデータがローカル・サーバ上に、もしくはクラウドに格納されていようと、当該データを非認可のアクセスから保護することが一般に望ましい。データの保護は、今日、設置されるセキュリティ・システムのほとんどにとって必須の要件になるかもしれない。データの保護を必要とするとき、データ・ストリームを暗号化でき、任意の他のストリームのようなフュージョンストリームによって基準化できる。

２種類のストリームを検討すべきである。
- データ・ストリーム: 映像、音声、メタデータ。
- キーのストリーム: 暗号化キー。

暗号化ができるときに、本システムは、周期的に変化する対称のキーを用いて個別に各データ・ストリームを暗号化するが、マスターキーのストリームに対応する。対称暗号化を用いることができるが、非対称暗号化よりも高速であり、より少ない処理リソースしか必要としないためである。これは、極めて大量のデータを表し得る映像および音声ストリームに対処するときに、極めて重要な利点を表す。図１１に示すように、データ・ストリームごとに、本システムは、１つの暗号化したデータ・ストリーム（大量のデータ）と１つまたは複数のマスターキーのストリーム（少量のデータ）を生成する。そのマスターキーのストリームは、当該データ・ストリームを暗号化するために用いる対称のキーを含有する。

図１１に示すように、アーカイバー・サーバは、暗号化されていない映像および音声を受信し、暗号化された映像（および任意の音声、図示略）とそれと関連づけられたマスターキーのストリームをリダイレクトまたは送り出す。その一方で、暗号化とマスターキーのストリームの生成は、カメラまたは他のソース・デバイスにて、もしくは、それらとのローカルな関連づけで行ってもよい。

非対称暗号化を用いて、本システムは次に、各ユーザの認証物（公開キー）を用いて上記マスターキーのストリームを暗号化するが、それに対するアクセスが付与された当該認証物である。非対称暗号化を行うことは、対称暗号化よりも多量のリソースを必要とするが、当該マスターキーのストリームは少量のデータを表すので、より容認可能となる。別個に暗号化されたクライアント特定キーのストリームは、この例で示すように、ユーザ認証物とデータ・ストリームの各組合せに対して生成される。
・ １つの映像ストリームと１つの音声ストリームを有するカメラ。
・ 各ストリームは、２つのユーザ認証物（ＡおよびＢ）を用いて暗号化される。
・ 認証物Ｂを有するユーザは、ライブ映像（音声はなし）を見ている。

キーのストリームとデータ・ストリームは、その同じストリーミング時間のディメンションの一部ということに注目すべきである。すなわち、それらは当該フュージョンストリームのコンポジションの同じバージョン（同じfusion-composition-versionの値）に属し、その同じストリーミング時間ＴＸが適用される。複号されたデータはディスク上で持続されない（不揮発性メモリ）。しかし、一度、暗号化されると、新しいユーザに対して当該データへのアクセスを付与するときに、もしくは、それらへのアクセスを拒否するときに、データ・ストリームは再度、暗号化される必要は決してない。そのデータに対するアクセスの付与または拒否を行うために、クライアント特定キーのストリーム（またはクライアント特定キーのストリームの一部）の付加または削除のみが必要とされる。

フュージョンストリームを用いて、上記暗号化されたデータと、上記データに対するアクセスを付与された、上記暗号化されたマスターキーのストリームおよびすべてのユーザのクライアント特定キーのストリームとを組み合わせたシナリオを構成できる。言い換えれば、そのフュージョンストリームは、その論理回路のシナリオを構成する、上記暗号化されたデータ・ストリームと暗号化されたキーのストリームの両方に対するアクセスの単一の点を表し得る。本システムが２つの認証物（ＡおよびＢ）を用いて上記ストリームの記録および暗号化を行った後に、フュージョンストリームがどのように見えるかを以下に示す。

フュージョンストリーム：

フュージョンノード：

一実施の形態では、その元の映像および音声ストリームが、ＶＥＫおよびＡＥＫファイルでそれぞれ暗号化されて、ＫＥＫファイルで格納された４個の暗号化キーのセグメントが認証物ＡおよびＢに対して付加された。これらのファイルファイルの拡張は例として提供され、かつ、他のファイルの拡張はその同じ機能性を実現するために用いてもよいことに注目すべきである。上記フュージョンノードに提供された６個のセグメントを、下記の順番でリストしている。
１．暗号化された映像
２．暗号化された音声
３．映像キーのストリームＡ
４．映像キーのストリームＢ
５．音声キーのストリームＡ
６．音声キーのストリームＢ

ユーザの認証物は、このシステム環境設定の一部である。ストリームが暗号化されるときに、本システムは、これらの認証物を用いて上記キーのストリームを暗号化できる。アプリケーションが上記プログラム作成インターフェースのAddCertificateとRemoveCertificateの方法を呼出し、フュージョンストリームと関連づけられた認証物を管理できる。

この例を簡素化するために、すべてのセグメントは、その同じ期間を包含する。すなわち、当該同じ時間間隔（開始時間および終了時間の値）を有する。しかし、フュージョンノードによって基準化された各セグメントは、各種類のストリーム（映像、音声、ＧＰＳなど）がそのファイルを作成するために用いるそれ自体のアルゴリズムを有し得ることを考慮して、相違する時間間隔を有してもよい。例えば、映像のファイルは、生成された映像データの量がより重要であるために１０分間継続できるが、他方、音声のファイルは２０分間継続でき、メタデータのファイルは１時間またはそれ以上継続できる。それらはまた、その同じ長さを有し得るが、同時に作成されないので、相違する期間のデータを含有する。

暗号化されたストリームに含有されているストリームの種類を判定するために、そのプレーヤーはGetStreamInfo(guid StreamID)の方法を呼び出すことができる。

映像ストリームに対する例

音声ストリームに対する例

キーのストリームに対する例

この例では、認証物Ａを有するユーザＡと認証物Ｂを有するユーザＢは両方とも、本システムによって記録された映像および音声ストリームにアクセスできる。しかし、他のシナリオでは、ユーザが特定の種類のストリームに対して認可されたユーザのリストに付加、もしくは、そこから削除されなければならないシナリオが存在するかもしれない。例えば、ユーザＢがその音声ストリームに対するアクセスを拒否される場合には、そのセグメントの音声キーのストリームは、上記プログラム作成インターフェースからRemoveElementaryStreamの方法を用いて、当該フュージョンストリームから削除される。追加のセキュリティ目的のために、上記キーのストリームは、その同じ方法を用いて、上記ファイル・システムから削除することもできる。

フュージョンストリームから削除されるセグメント

フュージョンストリームは、２つの層の暗号化機構を実行する性能を提供する。すなわち、第１の層は、一連の対称キーを用いて、そのデータ・ストリームの対称暗号化であり、第２の層は、上記ユーザの認証物を用いて、上記一連の対称キーの非対称暗号化である。この理由により、上記データまたはそれのいくらかの部分に対するアクセスの付与および拒否を行うことが大いに容易になる。このような場合には、上記データ・ストリームの複号および再暗号化を行う必要がない。ユーザが上記データに対するアクセスを付与されるときに、本システムは、上記キーのストリームを複号し、新しいユーザの認証物を用いて、それを暗号化することができるので、新しいクライアント特定キーのストリームが作成される。上記キーのストリームの複号は、上記新しいユーザを付加することを所望する認可されたユーザの個人キーを用いて行われる。ユーザがアクセスを拒否されるときに、それに対応するキーのストリーム（または、その一部のみ）が、上記フュージョンストリームから削除され、上記ファイル・システムから削除もできる。

さらに、アクセスの権利をセグメントのレベルで制御することも可能である。どのセグメントをユーザの認証物で暗号化するかを判定することによって、ユーザがどの特定のセグメントを視聴できるかを制御することが可能である。新しいユーザがセグメントに対するアクセス必要とする場合に、その新しいユーザの認証物を用いて、そのセグメントの複号および再暗号化を行う必要がない。その代わりに、その認証物に対して、新しいクライアント特定キーのストリームを生成し、それを基礎ストリームとして、それに対応するフュージョンストリームに付加することのみが必要とされる。

例えば、いくらかの司法制度では、公共の領域から映像を記録することは違法であるが、警察がアクセスして違法に作られた裁判記録で用いることは合法である。これは他の国では違法でないかもしれないが、それでもなお、プライバシーに対する懸念を表し得る。そのような司法制度では、コンビニエンス店の所有者が意図的損壊および強盗から、その所有者の資産を保護することを所望する場合に、当該所有者はカメラを設置して映像を記録することができない。しかし、フュージョンストリームにより可能になった上記２つの層の暗号化機構を用いて、その所有者は、警察のみがアクセスできる暗号化した映像と音声ストリームを記録することが可能になろう。従って、当該所有者がその所有者の事業を保護する手段が提供される。

図１３は、フュージョンストリームを構成する基礎ストリームから、セグメントのいくらかの部分に対してのみアクセスを付与することも可能であることを示す。この例では、その映像ストリームと音声コメンタリーのストリームは、ユーザＡにより完全にアクセス可能である。しかし、ユーザＢは、点線の四角形で示す部分に対してのみアクセスを有する。これは、映像キーストリームＢと音声キーストリームＢは、このデータ部分を複号するのに必要なキーのみを含むためである。そのデータを暗号化したキーが変更されると、当該制限している四角形の外側のコンテンツ視聴するアクセスが拒否されるユーザＢには、当該データは提供されない。

フュージョンストリームのプレーヤー

フュージョンストリームがフュージョンのアーカイバー２１０により生成され、フュージョンストリーム・リポジトリ２０６で利用できるとき、当該フュージョンストリームは、再生されるリポジトリから検索できる。これは、フュージョンストリームのプレーヤーがプレーに入る場所である。フュージョンストリームを作成するアプリケーションは、後にそれらをプレーするアプリケーションと必ずしも同じである必要はない。しかし、フュージョンストリームの生成とプレーのタスクの両方を行うために、単一のアプリケーションを開発できる。

図７を参照して、シナリオ・データセットのユーザ選択と検索モジュール１５は、シナリオ・データ格納庫１１に格納されたフュージョンストリームを問い合わせるために、ユーザ・インターフェースを提供するが、それは図６のフュージョンストリーム・リポジトリ２０６に対応する。シナリオ・データセットのユーザ選択と検索モジュール１５は、戻される結果の数量を制限するフィルターを提供できる。フィルターが提供されて、特定の時間の範囲を包含し、特定のシナリオ名を有し、その名称または描写のする特定のワードを含有し、特定のロケーションで格納され、特定の基礎ストリームから構成され、特定の属性を有するなどのフュージョンストリームをサーチできる。シナリオ・データセットのユーザ選択と検索モジュール１５は、フュージョンのエンジン２０９のＤＬＬファイルによって提供されるフュージョン・インターフェース２０１を用いることにより、以下の方法でフュージョンのアーカイバー２１０に接続する。ここで、archiverRoleは、アクセスするリポジトリを管理するフュージョンのアーカイバー２１０である。

多数のフュージョンのアーカイバー２１０がネットワーク上に存在するときに、上記フュージョンストリームのプレーヤー・アプリケーションは、到達すべきフュージョンのアーカイバー２１０を選択するためのインターフェースを提供できる。一度、選択すれば、シナリオ・データセットのユーザ選択と検索モジュール１５は、上述したように、所有者ＧＵＩＤによって所有されたシナリオ・データ格納庫１１から利用できるフュージョンストリームのリストを検索する。シナリオ・データセットのユーザ選択と検索モジュール１５は、フュージョン・インターフェース２０１が提供する以下の方法を用いて、そのフュージョンストリームを検索する。

その結果、フュージョン・マネージャー２００は、IFusionStreamのオブジェクトの収集物を戻す。各オブジェクトは、その一意的な識別名（ＧＵＩＤ）、名称、環境設定、保持期間、重複機能を果たすアーカイブ保管インジケータなどのフュージョンストリーム・プロパティと、上記フュージョンストリームを構成する基礎のストリームの収集物を含有する。シナリオ・データ格納庫１１が、フュージョンストリームの過去のバージョンの追跡を保つバージョン化システムを実行する場合には、これらの多数の過去のバージョンも、明確に識別できるＧＵＩＤと、バージョン・プロパティを用いて戻してもよい。シナリオ・データセットのユーザ選択と検索モジュール１５は、フュージョンストリームのリスト（その同じリストの最新およびより古いバージョン）をそれらのプロパティを用いて表示でき、そのユーザはそこから、興味があるものを選択できる。ユーザ・インターフェースはさらに、必要に応じて結果の数量を減少させるために、これらのプロパティに基づいてフィルターを提供することもできる。シナリオ・データセットのユーザ選択と検索モジュール１５は次に、上記選択したフュージョンストリームのＧＵＩＤをシナリオ・ノードデータセットの視聴時間と検索のユーザ選択モジュール１７に送信し、そこでは、ユーザ・インターフェースが、シナリオの再生を開始する時間ＴＸの選択を可能にする。選択／検索モジュール１７はさらに、そのシナリオの開始、停止、早送り、巻き戻しまたは探索を行うための再生制御を提供する。選択／検索モジュール１７は、上記フュージョンストリームからＴＸに適用するフュージョンノードを抽出する。そのフュージョンノードは、ＴＸに適用するフュージョンストリームを構成する基礎ストリームのまさにそのセグメントを提供する。そのフュージョンノードはさらに、オフセット値、当該セグメントを読み出すために必要なアクセス・レベル、それらの位置と大きさのプロパティを有するテキストのラベルなどを提供することもできる。選択／検索モジュール１７は、フュージョン・マネージャー２００に要求指令を送り、フュージョン・インターフェース２０１が提供する以下の方法を用いて、ＴＸに適用可能なセグメントのすべてを取得する。

この方法では、指定した時間の範囲のために上記セグメントのリストが戻されて、フィルターが指定されていない場合には、いくらかの基礎ストリームまたはすべての基礎ストリームによってフィルターがかけられる。選択／検索モジュール１７はさらに、上記再生の入力される時間の範囲と関連づけられたセグメントを抽出することもできるので、その許可のチェックと当該セグメントの検索がリソースサーバ１２から前もって行えて、その再生のタイムラグが回避できる。QuerySequencesAsyncの方法を用いて上記フュージョンノードから検索した上記セグメントのリストが、許可制御器１９に送信される。選択／検索モジュール１７はさらに、認可されたセグメントとコンポジションのユーザ選択モジュール２１に当該同じリストを送信する。

許可制御モジュール１９は、複数のチェックを行って、ユーザが基礎ストリームのセグメントによって提供されたコンテンツを視聴する許可を有しているかを判定する。許可制御モジュール１９が行う第１のチェックは、そのセグメントに対して指定された最小限のアクセス・レベルと、上記セキュリティ監視システムで環境設定されたユーザのアクセス・レベルを比較することである。例えば、ユーザまたはユーザ群は、１００のユーザ・レベルで構成できる。そのユーザ・レベルまたはユーザ群レベルが、セグメントに対して指定された最小限のアクセス・レベル（すなわち、８０）に符合するか、もしくは、それを超える場合には、そのユーザは、そのセグメントのコンテンツを視聴することができる。そうでない場合には、そのユーザは、当該セグメント全体に対するアクセスが拒否される。許可制御モジュール１９が行う第２のチェックは、ユーザがそのセグメントを視聴する特権を有しているかを実証することである。複数のユーザ特権の環境設定を行うことにより、次に示す項目において、ユーザを許可したり、拒否したりできる。それらは、映像コンテンツを見ること、音声コンテンツを聴くこと、映像および音声記録の作成、編集または削除、映像のエクスポート、映像のブロックまたはアンブロック、映像記録を保護することまたは保護しないことなどである。この第２のチェックを用いることにより、許可制御モジュール１９は、例えば、そのユーザが映像コンテンツを見る、かつ、音声コンテンツを聴く特権を有しているを実証する。ある種類のコンテンツに対するアクセスは、管理者によって、本システムで環境設定された当該ユーザの特権により、そのようなアクセスが許可された場合にのみ付与される。この特権は、フュージョンストリームに格納されないが、その代わりにシステム環境設定に格納される。しかし、モジュール１９が、どの種類の情報をセグメントが含有しているかを認識しているために、それとそれに対応するユーザの特権とを比較することができる。許可制御モジュール１９が行う第３のチェックは、暗号化されたセグメントに対して、当該ユーザがそのセグメントを複号できるかを実証することである。すなわち、例えば、その暗号化されたセグメントが遠隔の格納サーバから取得される、および、当該セグメントが、そのユーザが当該セグメントを複号するための個人キーを有してない再現時間に実現されるという効率の悪い状況を回避するためである。許可制御モジュール１９は、ユーザの認証物を上記フュージョンストリームと関連づけられた認証物の収集と比較する。以下の方法を用いて、許可制御モジュール１９は、フュージョン・インターフェース２０１を介して、フュージョン・マネージャー２００から上記セグメントが属するフュージョンストリームに関連する認証物の収集を要求できる。

許可制御モジュール１９は、ＳＨＡ−１のハッシュ機能を用いて、各認証物の拇印（ユーザの認証物および当該フュージョンストリームと関連づけられた認証物）を作成する。許可制御モジュール１９は次に、上記セグメントを視聴するために要求している当該ユーザの認証物の拇印と、フュージョン・マネージャー２００によって戻された各認証物の拇印とを比較する。そのセグメントが当該ユーザの認証物（公開キー）で暗号化されたことが確認されるときに、つまり、そのユーザが当該セグメントを複号するために、それに対応する個人キーを有することを意味するが、モジュール１９は、当該セグメントにアクセスする許可を提供する。許可制御モジュール１９が符号を見つけられない場合には、任意の無用な複号操作を行う必要なしに、アクセスを拒否する。フュージョンストリームは、ＩＴＵ−ＴのＸ．５０９の標準を用いて実行され、ユーザの認証物を管理する。暗号解読法において、このＸ．５０９は、デジタルの認証物と公開キーの暗号化を管理するために用いるPublic Key Infrastrcture（ＰＫＩ）に対して、国際的に広範に受け入れられている重要な標準である。Ｘ．５０９の標準は、２つのコンピュータ間の通信を安全にするために用いるTransport Layer Security（ＴＬＳ）のキーの部分である。上記Ｘ．５０９の標準は、公開キーの認証物、認証物取消しのリスト、属性の認証物、および、認証パスの認証アルゴリズムに対して、フォーマットを指定している。さらに正確に言えば、Ｘ．５０９の認証物は、公開キーが効果的にその認証物内に含有されたユーザ、コンピュータまたは職務上の身元に属することを実証するためのＸ．５０９のＰＫＩ標準を用いるデジタルの認証物である。当業者は、本発明の教示から逸脱することなく、他の標準および認証物を用いてもよいことを容易に認識するであろう。

一度、許可制御モジュール１９がこれらのチェックを完了したら、ユーザのアクセスが拒否されたセグメントは、前もって認識され、リソースサーバ１２から無用に検索されないであろう。許可制御モジュール１９は次に、認可されたセグメントとコンポジションのユーザ選択モジュール２１に、選択／検索モジュール１７によって元は提供された各セグメントに対する認可のトークンを送信する。そのトークンは、その認可の判定と上記セグメントＧＵＩＤを関連づけるが、それはブールの「拒否される」または「付与される」である。

認可されたセグメントとコンポジションのユーザ選択モジュール２１は、許可制御モジュール１９から受信した上記認可のトークンが指し示すように、ユーザの視聴が認可された上記フュージョンストリームのセグメントを示すユーザ・インターフェースを提供する。図９に示すように、少なくとも１つのセグメントのコンテンツがそのシナリオ内で利用できる期間を示すために、タイムラインを生成し、表示する。このタイムラインは、任意の所定の時間に対して認可されたコンテンツを示す。これはさらに、データが利用できないギャップを示す。認可されたセグメントとコンポジションのユーザ選択モジュール２１はさらに、当該シナリオの再生で読み出すための特定の認可されたセグメントを選択する手段を提供することもできる。しかし、好ましい実施の形態では、この選択はフュージョンストリームのプレーヤーによって提示されないが、そこでは、認可されたセグメントとコンポジションのユーザ選択モジュール２１は、そのユーザの視聴が認可されたセグメントのすべてを再生する。しかし、追加の特徴を提示しているフュージョンストリームのエディター・アプリケーションでは、この性能を当該ユーザに提供できる。認可されたセグメントとコンポジションのユーザ選択モジュール２１は次に、リソースサーバ１２から検索するセグメントのリストを、必要なセグメント・リソースと検索の識別モジュール２３の識別名に送信する。当該セグメントは、多数のリソースサーバ１２の間で配信され得るので、必要なセグメント・リソースと検索の識別モジュール２３は、当該セグメントのプロパティを用いて、セグメントを格納するリソースサーバ１２、ならびに、リソースサーバ１２から要求するファイルの場所を捜し出す。コンポジション指示書のコンパイラモジュール２５とストリーム・デコーディングのモジュール２７に利用できる上記第１のデータを作る前に、リソースサーバ１２からアーカイブのファイルを完全に受信する必要はない。The Real-time Transport Protocol（ＲＴＰ）のトランスポート・プロトコルを用いてストリームデータを送信するので、本明細書で説明しているように、コンポジション指示書のコンパイラモジュール２５とストリーム・デコーディングのモジュール２７に対して、それらの作業を行い始めるために数個のＲＴＰパケットで十分であろう。

認可されたセグメントとコンポジションのユーザ選択モジュール２１が行う重要なタスクは、コンポジション指示書のコンパイラ２５が用いるコンポジション・パラメータを生成することである。コンポジション指示書のコンパイラモジュール２５は、各セグメントの関係についての任意の知識を有することなしに、独立して各セグメントと共に作動するので、認可されたセグメントとコンポジションのユーザ選択モジュール２１は、当該シナリオを統制するものであり、そのような関係を指し示す上記コンポジション・パラメータをコンポジション指示書のコンパイラモジュール２５に提供する。そのコンポジション・パラメータは、当該シナリオが適切に再現するようにフュージョンノードから解釈され得る、暗号化キー、マスキングのオーバーレイ、テキストのオーバーレイ、時間のオフセット、表示層、ウインドーイングなどを含む。従って、認可されたセグメントとコンポジションのユーザ選択モジュール２１は、当該シナリオを統制するために必要とされるコンポジション・パラメータ（指令）を生成するフュージョンノードのインタープリタである。例えば、いくらかの実施の形態では、セグメントは頻繁に暗号化されることにより、非認可のアクセスから保護されよう。この要件は、新しい設置が常に配備される状態で時間と共にさらに重要になる。上記H.264のフォーマットを用いてエンコードされる映像セグメントVSeg_1と上記G.711のフォーマットを用いてエンコードされる音声セグメントASeg_1が、ユーザ（UCer_1）の認証物（公開キー）を用いて暗号化されるときに、上記フュージョンノードは自動的に、その対称暗号化された映像セグメントを複号するために必要な非対称暗号化されたユーザ特定キーセグメント（VUKey_1）を提供する。上記フュージョンノードはさらに、その対称暗号化された音声セグメントを複号するために必要な第２の非対称暗号化されたユーザ特定キーセグメント（AUKey_1）を提供する。この情報を用いて、認可されたセグメントとコンポジションのユーザ選択モジュール２１は、モジュール２５に送信される以下のコンポジション・パラメータを生成し、ここで、VSeg_1, UKey_1, ASeg_1, AUKey_1およびUCer_1は、上記セグメントと上記ユーザ認証物に対する参照である。

この例で観察できるように、コンポジション・パラメータは、そのセグメント間の関係を確立するために、コンポジション指示書のコンパイラモジュール２５に送られる指令である。その結果、コンポジション指示書のコンパイラモジュール２５は、それらを組み合わせて、当該所望の結果を取得する方法を認識する。別の実施の形態では、特定の映像セグメントVSeg_1と関連づけられたマスキング・データ（MSeg_1）を提供する暗号化されたセグメントが、以下のコンポジション・パラメータとして、コンポジション指示書のコンパイラモジュール２５に提供される。ここで、VSeg_1, MSeg_1, MUKey_1およびUCer_1は、上記セグメントと上記ユーザ認証物に対する参照である。

コンポジション指示書のコンパイラモジュール２５は、認可されたセグメントとコンポジションのユーザ選択モジュール２１が用いるインターフェースを提供して、そのコンポジション・パラメータを指令の形態のもとで渡す。
・ 複号（srcSegment, keySegment, userCertificate）
・ そのユーザ認証物に対応する個人キーを用いて、そのキーセグメントを複号した後、その複号されたキーセグメントを用いて、そのソース・セグメントを複号。
・ デコード（srcSegment, SegmentType）
・ 指定したデコーディング・モジュールを用いて、上記ソース・セグメントをデコード。
・ 映像セグメントに対するH264, MPEG4, MJPEG4, HEVCなど。
・ 音声セグメントに対するAAC, G711, G723, GSM（登録商標）0610, MPGAなど。
・ オーバーレイ・セグメントに対するMASK, TEXT, POLYGONSなど。
・ オフセット（srcSegment, delay）
・ Ｘミリセカンドのオフセットを再現に先立って上記ソース・セグメントに適用。
・ 融合（srcSegment, addedSegment）
・ 上記ソース・セグメントを用いて、付加されたセグメントの再現を融合（同期化）。

コンポジション・パラメータは容易に作り変えられ、そのインターフェースに新しい指令を付加することによって、今後の性能をサポートできる。コンポジション・パラメータの指令は、タスクを行うために必要とされるデコーディング・モジュールの利用可能性にもかかわらず、コンポジション指示書のコンパイラモジュール２５に送ることができる。図１７は、コンポジション指示書のコンパイラ２５と、ストリームのデコーディング・モジュール２７と、音声／映像の再生３０との間のワークフローを示す。

図１７は、コンポジション指示書のコンパイラ２５、ストリームのデコーディング・モジュール２７および音声／映像の再生３０を用いて、映像ストリーム、音声ストリームおよび任意の他のデータ・ストリームのセグメントを読み出す、かつ、再現するためのストリームのパイプラインの例示的なフローチャートである。一例では、コンポジション指示書のコンパイラモジュール２５、ストリームのデコーディング・モジュール２７および音声／映像の再生３０は、Microsoft Windowsのオペレーティング・システムに対して利用できる標準のデコーダとフレームワークを用いる。

図１７の例示的なストリームのパイプラインは、映像ストリームに関するものであるが、図１７のようなストリームのパイプラインは、音声ストリームなどの他のデータ・ストリームのために用いてもよいことが理解されよう。そのパイプラインの端部には、再現エンジン（音声／映像の再生３０）がある。その再現エンジンは、上記映像パイプラインが出力するときに、未補正のＹＵＶフォーマットで提供されるフレームを採用し、それをモニター上に表示する。このパイプラインに入る前に、認可されたセグメントとコンポジションのユーザ選択モジュール２１は、利用するコーデック（H264, MPEG4など）を用いて再現すべきストリームの種類（映像、音声など）を指し示すコンポジション・パラメータを提供する。このパイプラインの最初に、コンポジション指示書のコンパイラモジュール２５は、ＲＴＰパケットを受信し、それらを群に新たに組み合わせることにより、ステップＰ１でフレームを取得する。一度、このフレームを新たに組み合わせると、コンポジション指示書のコンパイラモジュール２５は、上記ストリームの残りから独立した完全なフレームである再生時間に近い第１のキーフレームを探す。ステップＰ２でオフセットが適用される場合には、コンポジション指示書のコンパイラモジュール２５は、上記コンポジション・パラメータが指定するように、再生時間にオフセットをプラスまたはマイナスした値に近いキーフレームをサーチする。一度、そのキーフレームを識別すると、コンポジション指示書のコンパイラモジュール２５は、それがステップＰ３で複号されなければならないかをチェックする。これがその場合であるならば、コンポジション指示書のコンパイラモジュール２５は、そのユーザ認証物がステップＰ４で利用できるかを実証し、次に、ステップＰ５で必要な複号アルゴリズムと関連づけられたストリームのデコーディング・モジュール２７を用いる。最初の複号の段階に対して、上記ユーザ特定キーセグメントは、そのユーザの公開キーを用いて非対称暗号化が行われるので、コンポジション指示書のコンパイラモジュール２５は、ステップＰ６で上記ＲＳＡアルゴリズムを用いて上記ユーザ特定キーセグメントを複号するために、上記Windowsのオペレーティング・システムのthe Crypt Applicatoin Programming Interface（ＡＰＩ）に対するアクセスを提供するストリームのデコーディング・モジュール２７を例証する。このプロセスの結果は、ここでは暗号化されていない上記ユーザ特定キーセグメントである。コンポジション指示書のコンパイラモジュール２５は次に、この暗号化されていないキーセグメントで、上記キーフレームを複号するために必要とされる特定の対称キーの場所を捜し出す。この第２の段階に対して、コンポジション指示書のコンパイラモジュール２５は、上記ＡＥＳアルゴリズムを用いて上記フレーム・フレームを複号するために、上記Windowsのオペレーティング・システムの上記CryptのＡＰＩに対するアクセスを提供するストリームのデコーディング・モジュール２７を例証する。一度、複号されたなら、上記フレームは、ＲＴＰトランスポート層ヘッダを削除させ、その残りのデータは統合のために分析され、欠けているパケットがないことを確実にするために、これらのタスクが、例えば、第三者のライブラリーによって提供されるthe Secure Real-time Transport Protcol（ＳＲＴＰ）によって行われる。これにより、上記デコーダに送ることができる実映像フレーム（例えば、H264）が作り出される。

コンポジション指示書のコンパイラモジュール２５は、その要求されたデコーダが、ステップＰ７で再現する種類のフレームのために利用できるかをチェックする。上記例示的なプロセスが、H264の映像フレームに対して説明しているとしても、この同じプロセスは、ストリームのデコーディング・モジュール２７が上記種類のフレームを取り扱うために提供されている限りは、任意の標準または所有者のフォーマットに対しても適用されてもよいことが理解されよう。例えば、上記フュージョン・プレーヤーのアプリケーションがサポートする各映像フォーマットは、それが利用できる映像デコーダを有するが、H.264, MPEG-4, MJPEG, HEVCなどである。これはさらに、音声フォーマットに対しても適用可能であり、AAC, G711, G723, GSM（登録商標）0610, MPGAなどである。国際的に既知の映像標準に対して、現行のコーデックを用いることができる（例えば、Windows Media Codecs, FFmpeg AvCodec, DivX）。このようなコーデックを用いて、そのフレームはシステムのメモリ内にある。さらに、図形用カード（NVidia, Intel）によって提供されるデコーダを用いることもできる。そのような場合には、そのフレームは映像のメモリ内にある。必要なデコーダが利用できる場合には、コンポジション指示書のコンパイラモジュール２５は、それに対応するストリームのデコーディング・モジュール２７を例証して、そのフレームをデコードする。所有者のフレーム・フォーマットに対しては、例えば、マスキングのオーバーレイの場合において、所有者のデコーダを実行して、必要な情報を抽出する。このような所有者のデコーダは、そのフレーム情報を解釈し、音声／映像の再生モジュール３０がサポートする指令にそれを変換する。例えば、音声／映像の再生モジュール３０は、上記マスキング・オーバーレイのフレームを特定の大きさと位置を有する長方形であるように解釈する。ストリームのデコーディング・モジュール２７は、Ｌ個のピクセルの長さとＨ個のピクセルの高さを有する形状（例えば、長方形）を抽出するが、それは黒色で満たされて、その位置はウインドーの左下からＸ個およびＹ個のピクセルにより定義される。この座標系は、一例として提供している。再現エンジン３０（例えば、音声／映像再生モジュール）がそれと同じ座標系を用いている限りは、任意の座標系を用いることができる。上記マスキング・オーバーレイのストリーム用に受信される次のフレームは結果として、Ｌ，Ｈ，ＸおよびＹになり、時間と共に変化して融合される映像フレームに続いてもよい。その映像フレームの一例では、一度、デコードされたなら、コンポジション指示書のコンパイラモジュール２５は、ストリームのデコーディング・モジュール２７から、上記パイプラインから出力されるＹＵＶフォーマットの未補正の映像フレームを取得するが、再現エンジン３０（例えば、音声／映像再生モジュール）によって表示させる必要がある、まさにその時間に出力されるコンポジション指示書のコンパイラモジュール２５は次に、その映像フレームを音声／映像の再生モジュール３０に表示するために提供する。音声／映像の再生３０は、上記フレームを取得し、必要な場合には、いくらかの変形を適用できる。音声／映像の再生モジュール３０は、その映像フレームが魚眼カメラに属する場合に、ゆがむを減少させる変形を適用できる。いくらかの場合に、音声／映像の再生モジュール３０は、回転変形を適用でき、ユーザの指令に続くズーム変形を適用でき、あるいは、そのカラー・フォーマットを変換して上記再生フレームワークと互換性のある画像を取得することができる。音声／映像の再生モジュール３０は次に、上記未補正の画像を、それが表示されなければならないまさにその時間に、the Windows Presentation Foundation（ＷＰＦ）表示フレームワークに提供する。それは、今度は、DirectXを用いて、モニター上にその画像を表示する。

例えば、上記映像セグメントを用いて融合させるべきマスキング・オーバーレイのセグメントがさらにある場合には、その同じパイプラインが当該オーバーレイのフレームに適用される。必要な場合には、そのオーバーレイのフレームは、複号およびデコードが行われて、そのオーバーレイ自体についての情報を抽出する。すなわち、ディスプレイ上に描写される形状およびプロパティである。ストリームのデコーディング・モジュール２７から、それらの形状およびプロパティを受信したときに、上記映像フレーム上で行われる変形プロセスと同等物において、コンポジション指示書のコンパイラモジュール２５は、指令を音声／映像の再生モジュール３０に送ることによって、当該形状をそれらのプロパティ（大きさ、位置、輪郭の色、内部の色など）と共に描く。環境設定によって、音声／映像の再生モジュール３０は、オーバーレイ層を提供して当該形状を描き、自動的にそのｚオーダーを制御して、映像層上にそのオーバーレイ層を表示する。音声／映像の再生モジュール３０は、ポリゴンとラインを描き、それらの大きさと位置を設定し、輪郭の色と内部の色を指定するために、コンポジション指示書のコンパイラモジュール２５にインターフェースを提供する。コンポジション指示書のコンパイラモジュール２５に関して、再現エンジンまたは音声／映像の再生モジュール３０は、指定したセキュリティ監視システムのために必要な制御を提供する。上記映像およびオーバーレイ画像の最終の再現を行うことは、上記ＷＰＦフレームワークに依存してもよく、今度は、DirectXに依存する。いくらかの他の実施の形態では、好ましくない例は、上記映像フレームを修正してその形状を付加し、次に、その画像を上記既成の映像層によってサポートされるMPEG-4などの標準のフォーマットで、再度のエンコードを行うことであるかもしれない。しかし、この例は結果として、所望されないスケーラビリティの損失になり、そのソース・フレームの修正が必要になる。いくらかの他の実施の形態では、例示的なフュージョンストリームのプレーヤー３０は、当該ファイルに格納されたフュージョンストリームを構成する基礎ストリームを読み出してデコードするために、上記G64Xの所有者ファイル・フォーマットをサポートし、上記格納庫からそのシナリオの権利をプレーしてもよい。

コンポジション指示書のコンパイラモジュール２５が行う次のステップは、ステップＰ９で、フュージョンが１つまたは複数のフレームの間で行われなければならないかをチェックすることである。一例では、そのソース・フレームは表示される画像であり、当該融合されたフレームは、そのオーバーレイ画像である。これら２つのフレームの融合は、認可されたセグメントとコンポジションのユーザ選択モジュール２１によってコンポジション・パラメータを介して指令される。再現する映像フレームのみがある（融合されたフレームはない）場合には、コンポジション指示書のコンパイラモジュール２５は、ステップＰ１０Ａで上述のように再現するために、音声／映像の再生モジュール３０に、その映像画像を単に提供するだけである。融合されたフレームがある場合には、コンポジション指示書のコンパイラモジュール２５は、上記映像フレームとオーバーレイ・フレームが音声／映像の再生モジュール３０によって同期的に再現されることを確実にする。しかし、それら２つのフレームは、ステップＰ１０Ｂでその同じインターフェースを用いて提供されていない。当業者は、音声／映像の再生モジュール３０のインターフェースが、画像と他の種類の容易に見られるオブジェクトをディスプレイ上で再現するためのMicrosoft Windowsのプラットフォーム上で、上記既知のＷＰＦフレームワークによって提供されるものであることを理解されよう。

他の可能性のあるアプリケーション

フュージョンストリームが提供する多大な順応性により、まだ発明されていない多数の今後のアプリケーションの実行が簡素化できる。フュージョンストリームを定義するために用いられるJSON（またはXML, あるいはその他）マークアップ・フォーマットにより、タグが容易に付加されて、新しい要件に作り変えることができる。新しいタグ（コンポジション属性とも呼ぶ）がプレーヤーによってサポートされない場合には、単にそれらを無視し、それがサポートするタグを用いて、そのシナリオをなお再生し続けることができる。次に、当該プレーヤーは後に更新されて、上記新しいタグをサポートできるので、システムの更新を配置しているときに、多大な順応性が提供される。新しいタグの例は以下のようである。

さらなるタグの例

フュージョンストリームの能力は、それのコンポジションが作成され、基礎ストリームが記録された後に、ストリームの全体またはその一部にアクセスするユーザの許可を変更するために、かつ、変更の追跡を保つバージョン化機構を提供するために、当該コンポジションを修正する性能にもある。

新しいメタデータのストリーム・フォーマットは、その構造を作り直す必要なしに、既存のフュージョンストリームに容易に付加することもできる。例えば、映像ストリーム上に表示されるオーバーレイを含有する新しいストリーム・フォーマットを作成することは望ましい。オーバーレイは、形状の種類、色、テクスチュア、大きさ、および位置属性を有する幾何学的形状を含有できる。すべての要件を満たし得る標準のフォーマットはめったに存在しないので、新しいストリーム・フォーマットを作成することが必要になり得る。このようなメタデータ・ストリームは次に、フュージョンストリームによって、それらの構造を修正する必要になしに、基準化することができる。そのプレーヤーが上記新しいストリームをデコードし、提供されたコンポジション属性を用いる方法を認識している限り、そのフュージョンストリームの構造は、修正される必要がなく、そのような新しいコンテンツを容易に格納できる。

ストリームは、映像に限定されなくてもよい。相違するソースから入ってくるタイムスタンプされたデータの任意の論理回路コンポジションを、フュージョンストリームに対して用いてもよい。

ソーシャル・メディア

フュージョンストリームは、例えば、ソーシャル・メディアに適用されることができる。例えば、特定の判断基準（地理的ロケーション、日付と時間の適用範囲、ポスト・コンテンツなど）（すなわち、論理回路のシナリオ）に符合する、あるソーシャル・メディアからのデータを統合する必要があるかもしれない。そこでは、フュージョンストリームは、その目的のために作成されてもよい。

フュージョンストリームは、基礎ストリームのバージョン化されたコンポジションであり、そこでは、所定のソーシャル・メディア上の各ユーザは、基礎ストリームの一意的なソースであると推定してもよい。１つの基礎ストリームを別の基礎ストリームから導出することは可能であるので、ソーシャル・メディアのソースの匿名バージョンに対応する新しい基礎ストリームは、論理回路のシナリオと符合するが、それを作成してもよい。そのストリームの元のもの（すなわち、非匿名バージョン）は、例えば、当該フュージョンストリーム暗号化を用いて暗号化できる。これにより、さらに、その元のストリームに対して、認証物特定キーのストリームを生成することもできる。

最終的に、そのフュージョンストリームは、我々の論理回路のシナリオと符合するすべてのソーシャル・メディアのソース（すなわち、所定のユーザ）に対して、以下のものを含有するであろう（このソーシャル・メディア上の当該ユーザからの所定のストリームのポスト）。
・ 上記元のソーシャル・メディアのデータ・ストリーム（一連の無作為に生成された対称キーを用いて暗号化される）。
・ 認証物特定キーのストリーム（すなわち、元のストリームを複号するために、または、視聴許可を（統合的にまたは部分的に）他の者に付与するために、認可されてよい存在物の公開キーを用いてさらに暗号化された、元のストリームを暗号化するために用いられる上記一連の対称キー）。
・ 上記ストリームの匿名バージョン（暗号化されていない）。

新聞

フュージョンストリームを用いて、新聞を形作ってもよい。所定の出版物（例えば、the New York Times）は、論理回路のシナリオ（すなわち、フュージョンストリーム）であり得る。出版物は、デジタル・コンテンツの収集物（例えば、記事、年代記）である。個別の記事は、それらの記者（一意的なソース）の基礎ストリームから入ってくる。これにより、それらが当該シナリオの外側で存続することができ、別の出版物（すなわち、別のフュージョンストリーム）で潜在的に再び用いられ得る。

上記出版物は、データ・ストリームの論理回路コンポジションとして解釈してよいので、基礎ストリームの表記（例えば、著者、出版者、代理業者）は、特定の必要性に依存して変更してもよい。

いくらかの実施の形態では、新聞のモデルはさらに、米国特許出願に記載されたフュージョンストリームの暗号化と結びつけ、所望の粒状性を用いてデジタル購読モデルを定義してもよい。この出版物購読例では、キーストリームは、満了期間（例えば、そのキーストリームが削除される所定の日付まで完全なアクセス）を有してもよいし、あるいは、スライディング・ウインドーの形態（例えば、データの最後のＸ日にアクセスを付与）を採用してもよい。

ナンバープレートの認識

上記フュージョンストリームは、捕捉デバイスからプレートの読出しを格納するためのLicense Plate Recognition（ＬＰＲ）システムによるデータ構造として用いることができる。そのデバイス全体に対して、１つのフュージョンストリームがあり得るが、そこでは、１つの基礎ストリームが当該デバイス上で利用できる各センサーに対して作成され得る。例えば、これは、捕捉デバイス（例えば、ＬＰＲカメラ）が２つの種類のセンサー、しかるに、プレートの読出しごとに、２つの相違する種類の画像（コンテクストのカラー画像、および赤外線プレート画像）を提供するときに有用であり得る。各画像ストリームは次に、上記捕捉デバイスを表すフュージョンストリームを構成する基礎ストリームに格納してもよい。

身体装着型カメラ

Body Wearable Camera（ＢＷＣ）を管理するシステムも、フュージョンストリームを用いることができる。このようなシステムは、フュージョンストリームによって提示される論理回路分類性能を用い得る。それは、単一のカメラはある日に、１人の警官が用いて、翌日に別の警官が用いるためである。しかし、いくらかの例では、用られたカメラに関係なく、所定の警官と関連づけられたすべての記録を追跡するために、ユーザごとに１つのフュージョンストリーム（すなわち、論理回路のシナリオ）があり、各フュージョンストリームは、相違する身体装着型カメラと関連づけられた基礎ストリームを有するであろう。フュージョンストリームはさらに、会話に対して用いることができ、そこでは、MP4のストリーム（上記ＢＷＣからの元のフォーマット）が受信され、上記セキュリティ監視システムによって取り扱われた新しいトラックG64（所有者のフォーマット）を作成する。上記元のストリームと変換されたストリームは両方とも、その同じフュージョンストリームの一部である。

モーションのぼけ付け

モーションのぼけ付けの特徴も、それが生成するデータの記録、格納および管理を行うために、フュージョンストリームを用いることができる。映像ストリームは、新しいストリーム（モーション・マスクのストリーム）を作り出す１つのモーション検出アルゴリズムに供給され、それは、当該現場の部分の一部のマスキングを必要とするその現場の論理回路のシナリオを表すフュージョンストリームに付加される別の基礎ストリームとして記録される。モーション・マスクは、クライアントの側で（例えば、ワークステーションで再生中に）未補正の映像上に適用できるが、当該ユーザ（例えば、捜査人）がマスクしていない現場を見る適切な許可を有する場合には、そのマスクを削除することもできる。この同じ論理を任意の種類のオーバーレイで用いることができる。

映像の分析論

映像分析論システムから生成されるメタデータも、フュージョンストリームを用いて格納できる。このような場合には、論理回路のシナリオは、ビデオカメラをよって記録される現場により表される。基礎ストリームを用いて、映像分析論メタデータは、その映像の記録および格納が既に行われた後に、上記フュージョンストリームに付加され得る。フュージョンストリームを用いて、新しいストリームを既存の論理回路のシナリオに付加することは容易である。それらのストリームは、今度は、犯罪学的なサーチと分析を可能にし、さらに、その同じシナリオの一部である新しい結果のストリームを生成できよう。

フュージョンストリームのアプリケーションのプログラム作成インターフェース

図１４は、書き手／生成者および読み手／プレーヤーのアプリケーションが、それらの必要性に応じて、フュージョンストリームを操作できるように開発したアプリケーションのプログラム作成インターフェース（ＡＰＩ）のグラフを提供する。一例では、上記ＡＰＩは、Microsoft .NETのフレームワーク上で構築され、C#に書き込まれる。このフュージョンストリーム上には、上記ＡＰＩの相違するセクションがある。
１- リポジトリ
２- フュージョンストリーム
３- 基礎ストリーム
４- シーケンスの読み手
５- シーケンスの書き手

リポジトリの取得
上記リポジトリは、上記フュージョンストリームにアクセスする主要なゲートである。上記リポジトリを取得するために、ユーザは、the FusionStreamRepositoryFactoryを用いる。

パラメータ。
・ owner: その所有者のＧＵＩＤ。いくらかの例では、それは、上記フュージョンストリームを用いるクライアント・アプリケーションのＧＵＩＤであろう。それはさらに、相違する群のフュージョンストリームを区分するために用い得る無作為のＧＵＩＤであり得よう。所有者Ａのもとで作成されるすべてのストリームは、所有者Ａのリポジトリを取得するときのみ、容易に見られるよう。
・ archiverRole: 上記フュージョンストリームのリポジトリを維持するフュージョン・アーカイバー。
・ proxy: 本システム内の相違する構成部に対するアクセスを制御する通信モジュール。

リポジトリのインターフェース

一度、上記リポジトリを取得すれば、the IFusionStreamRepositoryのインターフェースに対するアクセスが付与される。

・ UpdateAsync: 上記フュージョンおよび基礎ストリームになされた変更をコミットする。成功のときは正しい、そうでないときは（例えば、接続が低下したとき）間違っている旨をリターンする。
・ CreateFusionStream: 新しいフュージョンストリームを作成する。変更は、UpdateAsync.を呼び出した後にのみ、適用される。上記IFusionStreamのインターフェースをリターンする。
・ DeleteFusionStream: 上記フュージョンストリームと上記根元的な基礎ストリームのすべてを削除する。
・ FusionStreams: 既存のフュージョンストリームの収集。
・ QuerySequencesAsync: その指定した時間の範囲に対して、シーケンスのリストをリターンしてフュージョンストリームによってフィルターがかけられるか、あるいは、フィルターが指定されていない場合にはすべてのフュージョンストリームをリターンする。
・ ProtectFusionStreamAsync: その所望の持続期間中、上記指定した時間の範囲の間に上記指定したフュージョンストリームの基礎ストリームのシーケンスのすべてを保護する。
・ UnprotectFusionStreamAsync: ProtectFusionStreamAsyncによって前もって保護された上記指定した時間の範囲の間にシーケンスを保護しない。
・ GetWriterFactory: 上記基礎ストリームに対して、シーケンスの書き手を作成するためのファクトリーを取得する。
・ GetReaderFactory: 上記基礎ストリームのシーケンスに対して、読み手を作成するためのファクトリーを取得する。

フュージョンストリームのインターフェース

上記IFusionStreamのインターフェースを用いて、上記フュージョンストリームの属性と基礎ストリームの関係を操作する。上記フュージョンストリームの環境設定上でなされたすべての変更は、上記UpdateAsyncの方法が上記リポジトリ上で呼び出された後に適用される。

・ Id: 上記フュージョンストリームのＧＵＩＤ。
・ Name: 上記フュージョンストリームの名称。
・ UserConfig:上記特定のフュージョンストリームに対して、描写などのユーザ環境設定可能なコンテンツ。
・ Certificates:暗号化目的のために、上記フュージョンストリームと関連づけられたX.509の認証物のリスト。
・ ElementaryStreams: 上記現行のフュージョンストリームに属する基礎ストリームの収集。
・ RetentionPeriodInDays:シーケンスが自動的に削除される前に、そのシーケンスの保持に対する環境設定可能な値。
・ RedundantArchiving:上記フュージョンストリームが、本システムの上記フェイルオーバーの環境設定に依存して、多数のアーカイバーによってアーカイブに保管されるべきかを指定する。
・ UseCustomRecordingSettings:正しい値は、上記フュージョンストリームに対して、特定の環境設定を用いることを指し示す。間違いは、上記アーカイバーの環境設定を用いることを指し示す。
・ AddNewElementaryStream: 新しい基礎ストリームを上記フュージョンストリームのもとで作成する。
・ AddNewAudioElementaryStream: 特定の音声メディア種類の新しい基礎ストリームを上記フュージョンストリームのもとで作成する。
・ AddNewVideoElementaryStream: 特定の映像メディア種類の新しい基礎ストリームを上記フュージョンストリームのもとで作成する。
・ AddNewEventElementaryStream: 特定のイベントメディア種類の新しい基礎ストリームを上記フュージョンストリームのもとで作成する。
・ RemoveElementaryStream:上記フュージョンストリームから上記基礎ストリームを削除して、根元的なシーケンスを削除する。
・ AddCertificate:上記フュージョンストリームに暗号化認証物を付加する。付加されたすべての新しいシーケンスは、上記リスト上の認証物のすべてを用いて暗号化される。
・ RemoveCertificate: 上記フュージョンストリームから認証物を削除する。
・ QuerySequencesAsync: その指定した時間の範囲に対して、シーケンスのリストをリターンして基礎ストリームによってフィルターがかけられるか、あるいは、フィルターが指定されていない場合にはすべての基礎ストリームをリターンする。

基礎ストリームのインターフェース

上記IElementaryStreamのインターフェースは、特定の基礎ストリームと関連づけられた情報を提供する。

・ Id: 上記基礎ストリームのＧＵＩＤ。
・ Name: 上記基礎ストリームの名称。
・ eMediaType: その根元的なデータの種類（例えば、一般、音声、映像、イベント）を決定するために用いられる。
・ QuerySequencesAsync: その指定した時間の範囲に対して、および、この特定の礎ストリームに対して、シーケンスのリストをリターンする。

フュージョンストリームに対するデータの書込み

上記IWriterFactoryのインターフェースは、相違する種類のシーケンスの書き手に対するアクセスを提供する。その用いられる時間は、上記ＳＱＬ時間に調節される。上記拡張方法のAdjustToSqlTimeは、上記インターフェース上で用いられるすべての時間に適用される。

・ AddNewSequence:指定した時間の範囲に対してシーケンスの書き手を提供する。既存のシーケンスと重複がある場合には、上記除外のFusionStreamOverlappingExceptionが行われよう。
・ AddNewLiveSequence:先と同じであるが、無期限の範囲を有する（停止時間はなし）。エラーに対して除外を行う。

特定の書き手。
・ AddNewEventSequence:iイベントと指定した時間の範囲に対してシーケンスの書き手を提供する。既存のシーケンスと重複がある場合には、上記除外のFusionStreamOverlappingExceptionが行われよう。
・ AddNewLiveEvent:先と同じであるが、無期限の範囲を有する（停止時間はなし）。エラーに対して除外を行う。
・ AddNewVideoSequence:音声と指定した時間の範囲に対してシーケンスの書き手を提供する。既存のシーケンスと重複がある場合には、上記除外のFusionStreamOverlappingExceptionが行われよう。
・ AddNewLiveVideo:先と同じであるが、無期限の範囲を有する（停止時間はなし）。エラーに対して除外を行う。
・ AddNewAudioSequence:映像と指定した時間の範囲に対してシーケンスの書き手を提供する。既存のシーケンスと重複がある場合には、上記除外のFusionStreamOverlappingExceptionが行われよう。
・ AddNewLiveAudio:先と同じであるが、無期限の範囲を有する（停止時間はなし）。エラーに対して除外を行う。

書き手に基づいた階級

上記IWriterのインターフェースは、データを基礎ストリームに書き込んでいるときに、休止と再開機能性を提供する。

・ Pause:上記セグメントを閉じることなく、そのシーケンスの書込みを一時的に休止する。それは、上記セグメントのファイルを閉じることなく、そのアーカイバー上でイベント記録停止を挿入する。
・ Resume:新しいセグメントのファイルを作成することなく、その同じシーケンス上で書込みを再開する。開始シーケンスが挿入され、そこでは、その同じアーカイブに対して、相違するセグメントがあってもよい。

一般のシーケンス書き手

上記ISequenceWriterのインターフェースは、基本的な書込みインターフェースを提供する。

・ WriteAsync:上記アーカイバーにデータを送る。上記タイムスタンプは、そのフレームの時間を決定する。この時間は、その読み手と共に上記シーケンスを回復するために、後に用いることができる。isKeyFrame. は、これが問合せに関する結果として、示されるべきか否かを指し示す。

イベントの書き手

上記IEventWriterのインターフェースは、単一の基礎ストリーム上で相違する種類のイベントを書き込んでいるときに、さらにいくらかの順応性を可能にする。

・ WriteAsync: イベントを上記基礎ストリームに書き込む。

ストリーム・イベントの階級

フュージョンストリームからのデータの読出し

上記IReaderFactoryのインターフェースは、そのシーケンス情報を読み出すために、上記書き手のファクトリーによって用いられる種類と符合する特定の読み手を取得する方法を提供する。

シーケンスの読み手

上記ISequenceReaderのインターフェースは、上記基礎ストリーム上に格納されたシーケンスのデータに対するアクセスを提供する。

・ SeekAsync: 上記セグメント内の所望のフレームの位置をフェッチする。
・ ReedAsync: 指定された位置から１つのフレームを読み出す。データは、そのリターンされたバッファ上のオフセットでもよい。この場合には、有効なデータがそのデータのオフセットの後に見つけられる。

イベントの読み手

上記IEventReaderのインターフェースは、ストリームのデータを読み出し得る特別の読み手に、イベントの種類のフィルターを提供する。

・ SeekAsync: 上記セグメント内の所望のフレームの位置をフェッチする。
・ ReedAsync: 指定された位置から１つのフレームを読み出す。フィルターが指定される場合には、そのフィルターに含まれるイベントのみがリターンされる。データは、そのリターンされたバッファ上のオフセットでもよい。この場合には、有効なデータがそのデータのオフセットの後に見つけられる。

シークエンス・サーチの結果

上記ISequenceのインターフェースは、上記QuerySequenceの方法によってリターンされた情報を提供して、格納された情報があるとき、および、そのセグメントはどの基礎ストリームと関連づけられているかを見つけることが可能になる。

・ Range: 上記セグメント上で含有される時間の範囲。
・ ElementaryStream: 上記セグメントが属する基礎ストリーム。

共通接続インターフェース

上記IConnectionのインターフェースは、上記リポジトリ、読み手および書き手に対する接続状態を取り扱うために用いられる。

・ StartConnectingAsync: その接続プロセスを開始する。接続したときにのみ、リターンする。取り消された場合は、間違いをリターンする。
・ DisconnectAsync: その根元的な接続を分離する。完全に分離されたときにのみ、リターンする。取り消された場合は、間違いをリターンする。
・ Connected:接続または再接続がおこなわれたときに、点火したイベント。
・ ConnectionLost:手動でまたは自動的に分離がおこなわれたときに、点火したイベント。
・ IsConnected:現行の接続状態を取得する。
実フュージョンストリームＡＰＩを用いた概念の方法のマッピング

以下の概念の方法は、より描写的な方式でフュージョンストリームにそのインターフェースを提示するために用いてもよい。
・ GetFusionStreamInfo（guid FusionID, int CompositionVersion）
・ GetFusionStreamComposition（guid FusionID, DateTime StreamingTime, int CompositionVersion）
・ GetStreamInfo（guid StreamID）
・ GetStreamSegments（guid StreamID, DateTime FromDateTime, DateTime ToDateTime）

これらの方法は、上記フュージョンストリームのＡＰＩ方法に対して、以下のようにマッピングを行うことができる。
GetFusionStreamInfo（guid FusionID, int CompositionVersion）

以下は、所定のフュージョンストリームＧＵＩＤを用いて、IFusionStreamのオブジェクトを取得することである。

GetFusionStreamComposition（guid FusionID, DateTime StreamingTime, int CompositionVersion）

この方法は、以下のIFusionStreamのオブジェクトの方法に対して、マッピングを行う。

GetStreamInfo（guid StreamID）

FsObjectから提供された識別名のeguidを用いて、上記基礎ストリームを検索。

GetStreamSegments（guid StreamID, DateTime FromDateTime, DateTime ToDateTime）

基礎ストリーム（例えば、eStream object）に関する以下の方法を用いて、そのセグメントのリストを取得する。

コードの例

本明細書に提供されたコードの例は、上記フュージョンストリームのＡＰＩ方法を用いることにより、基本的な接続を作成してデータの書込みと読出しを行う方法に関して、即座の論証を提供する。

下記のコードの例は、音声および映像のデータをどのようにしてフュージョンストリームに書き込むかを論証している。

Claims (31)

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. 前記制御ストリームは、前記メディア・ストリームのタイムスタンプ間の関係を判定するために、オペレータ入力を受信することにより生成される、
    ことを特徴とする請求項２０〜３０のいずれか１項に記載の方法。
    

Images