JP7659535B2 - オブジェクトストア内のメディア記録の記憶及び検索 - Google Patents

Description

本開示は、デジタルデータストレージ技術に関する。特に、本発明は、オブジェクトストア内でメディア記録を記憶及び検索し、メディア記録が記憶されているオブジェクトストアのメンテナンスを実行するための方法及びデバイスを提案する。

ファイルがディレクトリ構造（フォルダツリー）に編成される古典的なファイルシステムと並んで、非階層的データストレージアーキテクチャは、様々な業界の部門で関心を集めており、大量のデータがネットワーク化された（クラウド）メモリに記憶されるアプリケーションでの使用が増えている。ネットワーク接続を介して記憶及びアクセスされる大量の非構造化データによく適したアーキテクチャはオブジェクトストレージであり、データはファイル階層又はブロック階層なしでオブジェクトとして管理される。オブジェクトストアがメモリドライブ上に実装される場合、メモリドライブの下位プロトコル層は、オブジェクトストアのユーザ（例えば、人間のユーザ、ソフトウェアアプリケーション、及び接続クライアントコンピュータ）から抽象化される。

ビデオ監視及び同様の使用の場合では、ストレージは安全で信頼性の高いアーカイブであるだけでなく、記憶されたデータアイテムの効率的な検索を可能にする検索ツールが更に必要とされている。有用な検索ツールは、良好な精度及び再現率を許容可能な実行時間と組み合わせるべきである。多くの利用可能なストレージソリューションは、検索の前にデータをインデックス化又はタグ付けすることによってこれを達成する。インデックス付け及びタグ付けは、かなりの量のオーバーヘッドデータを追加する可能性がある計算的に非常に費用のかかる前処理工程であり、並列化が困難であることが多い。

米国特許第１０２１０１９１号明細書は、オブジェクトストレージ技術を使用して記憶されたデータにアクセスするための方法を開示している。記憶動作は、ファイルシステムを利用してオブジェクトストア内にオブジェクトを作成することと、オブジェクトと関連付けられたＩノードについてのインデックスノード（Ｉノード）識別子（ＩＤ）を取得することと、オブジェクトのオブジェクトＩＤを作成することであって、オブジェクトＩＤは、オブジェクトストア内の任意の他のオブジェクトＩＤから特有である、オブジェクトのオブジェクトＩＤを作成することと、ＩノードＩＤをオブジェクトＩＤにマージして、その全体がＩノードＩＤを含むマージされたオブジェクトＩＤを作成することであって、ＩノードＩＤは、マージされたオブジェクトＩＤから抽出可能である、マージされたオブジェクトＩＤを作成することと、少なくともマージされたオブジェクトＩＤを含むようにＩノードを修正することと、を含む。アクセス動作は、ファイルシステムを利用して、オブジェクトストアに記憶されたオブジェクトに関連付けられたオブジェクトＩＤから、ＩノードＩＤ全体を抽出することと、ＩノードＩＤに関連付けられたＩノードにアクセスし、そこに記憶されたオブジェクトＩＤを決定することと、Ｉ－ノードからのオブジェクトＩＤが、Ｉ－ノードＩＤが抽出されたオブジェクトに関連付けられたオブジェクトＩＤと一致するか否かを判定することと、オブジェクトに対して操作を実行することと、を含む。米国特許第１０２１０１９１号では、Ｉノードベースのアクセスは、オブジェクトＩＤを直接使用する簡単なオプションよりも便利にアップスケールできることが示唆されている。本開示は、最新技術によるこのストレージ／アクセス設定及び同様の技術に対する代替案を提案する。

認知的側面に注目して、米国特許出願公開第２０２１０１１２１５４号明細書は、携帯電話のカメラによって見られるシーンを分析するためのソフトウェアアプリケーションを提案している。シーンに適用され、音声コマンド等の追加情報によって支援され得る画像処理タスクは、電話内でローカルに実行することができるが、関連するインデックス付けタスクは、ネットワーク化された処理リソースに委ねることができる。特に、ローカル処理の目的は、カメラの視野内の識別可能な視覚的オブジェクト又は特徴を潜在的に描写するピクセルグループ（「塊」）を識別することであり得る。各ピクセルの塊は「シンボル」を持ち、この「塊ＩＤ」は、塊が物体として視覚的に認識され得る場合、「オブジェクトＩＤ」として同様に利用され得る。更に、認識された視覚的オブジェクトは、「ローカルデバイスに知られている各データオブジェクトがクラウド内のデータを介してインスタンス化される」ように、クラウドベースのレジストリ内の「要素クラウドベースの形態」に記憶された属性のセットを構成する「キーベクトル」でアノテートすることができる。属性は、記録時間及び記録ソースを含むことができる。画素データは電話機自身のメモリに記憶される。

本開示の１つの目的は、メディア記録をオブジェクトストアに記憶するために利用可能な方法及び装置を作製することである。そのような方法及び装置では、メディア記録が、記憶されるとすぐに、又は限られた量の追加の処理のみで、検索可能になることが望ましい。別の目的は、オブジェクトストアに記憶されているメディア記録の中から関連するメディア記録を検索するために利用可能な方法及び装置を作製することである。そのような方法及び装置の効率及び性能は、関連するメディア記録が、オブジェクトストアへの不要な呼び出しなしに、かつオブジェクトストアへのトラフィック及びオブジェクトストアからのトラフィックの量が制限された状態で位置特定され得る場合に改善され得る。更なる目的は、記憶されたメディア記録を含むオブジェクトストアのメンテナンスを実行するために利用可能な方法及びデバイスを作製することである。メンテナンスは、関連するメディア記録の後の検索を容易にし、及び／又は古いメディア記録のクリーンアップを容易にするようなものでなければならない。汎用のカスタマイズされていない技術（例えば、オブジェクト・ストレージ・ソリューション）を可能な限り最大限に使用してこれを達成し、この技術で既に利用可能なそのような機能を活用することが包括的な目的である。

これらの目的の少なくともいくつかは、独立請求項によって定義される本発明によって達成される。従属請求項は、本発明の有利な実施形態に関する。

本発明の第１の態様では、メタデータに関連するメディアデータを含むメディア記録を記憶する方法が提供される。方法は、記録識別子ＩＤをメディア記録に割り当てることと、オブジェクトストア内の一又は複数のデータオブジェクトにメディアデータを記憶することであって、各データオブジェクトは記録ＩＤを持つ、メディアデータを記憶することと、メタデータをオブジェクトストア内の属性オブジェクトに記憶することであって、属性オブジェクトは記録ＩＤを持つ、メタデータを記憶することと、メタデータのハッシュを計算することと、ハッシュ、記録ＩＤ、記録間隔、及びメディア記録の記録ソースを、オブジェクトストア内のインデックスオブジェクトに記憶することと、インデックスオブジェクトを既存のインデックスオブジェクトと連結することと、を含む。

インデックスオブジェクトを既存のインデックスオブジェクトと連結すると、オブジェクトストア内のインデックスオブジェクトの総数が減少する傾向がある。その結果、メディア記録の徹底的な検索が実行されるときに検査される必要があるインデックスオブジェクトの数が制限される。以下で詳細に説明するように、メタデータのハッシュのインデックスオブジェクトの包含は、ローカルキャッシュのサポートによる検索を実行することを可能にし、これは、オブジェクトストアへの及びオブジェクトストアからのトラフィックを低減するのに役立つ。好ましくは、連結工程は、前述の工程を実行する一又は複数のコンポーネントとは別個のコンポーネントで実行される。例えば、連結工程は、メンテナンスコンポーネントに委ねられてもよく、前述の工程は、同じ場所又は異なる場所にあるインジェストコンポーネントに委ねられてもよい。提案された責任の分離は、新しいメディア記録の便利で迅速な記憶のためにインジェストコンポーネントを最適化できる一方で、メンテナンスコンポーネントは独立して動作できることを意味する。更に、メンテナンスコンポーネントは、強制的な実行時間制約を受けないため、計算負荷が低い期間中に共有処理リソース上で実行するようにスケジュールすることができる。

本発明の第２の態様では、メタデータに関連するメディアデータを含むメディア記録を検索する方法が提供され、方法は、オブジェクトストアへのアクセス及びキャッシュへのローカルアクセスを有する検索コンポーネントにおいて実施される。ローカルアクセスは、容量に関して実質的に無制限であり、及び／又は非常に高速であるため、全体の実行時間にあまり寄与しないことが理解される。オブジェクトストアへのアクセスは、リモートアクセス又はネットワークアクセスの場合のように、オブジェクトストアとのデータ交換がコスト、遅延、又はある程度の輻輳を意味するという意味で、より制限され得る。

この第２の態様による方法は、検索クエリを受信することと、オブジェクトストア内の一又は複数のインデックスオブジェクトに基づいて、検索クエリに一致するマッチングメディア記録を識別することであって、インデックスオブジェクトのうちの少なくとも１つは、複数のメディア記録を参照し、メディア記録ごとに、記録識別子、ＩＤ、及びメディア記録のメタデータのハッシュを記憶する、マッチングメディア記録を識別することと、一致メディア記録のハッシュがキャッシュ内の任意のメタデータ（すなわち、１つのメディア記録のメタデータに対応する任意のメタデータアイテム）のハッシュと一致するかどうかを判定することと、を含む。次の工程は、判定の結果に依存する。一致する場合、一致メディア記録のメタデータがキャッシュから取得される。一致しない場合、一致メディア記録の属性オブジェクトがオブジェクトストアから検索され、そのメタデータが検索された属性オブジェクトから取得される。ハッシュが一致することが分かったか否かにかかわらず、一致メディア記録の一又は複数のデータオブジェクトがオブジェクトストアから検索される。

インデックスオブジェクトの少なくともいくつかは、各々が複数のメディア記録（例えば、連結の結果として）を参照するので、識別工程は、限られた数のインデックスオブジェクトを検査することによって実行することができる。属性オブジェクトを検索する目的でのオブジェクトストアへの不要な呼び出しは、インデックスオブジェクトがメディア記録のメタデータのハッシュを保持するという事実のおかげで都合よく回避される。

本発明の第３の態様では、複数のメディア記録を記憶するオブジェクトストアのメンテナンスを実行する方法が提供され、各メディア記録はメタデータに関連付けられたメディアデータを含み、オブジェクトストアは一又は複数のインデックスオブジェクトを含み、各インデックスオブジェクトは、少なくとも１つのメディア記録を参照し、メディア記録について、メディア記録のメタデータの記録識別子、ＩＤ、及びハッシュを記憶する。方法は、共通期間に含まれるそれぞれの記録間隔を有するメディア記録を参照するオブジェクトストア内に、２つ以上のインデックスオブジェクトを配置することと、インデックスオブジェクトを連結することと、を含む。

２つ以上のインデックスオブジェクトの連結は、オブジェクトストア内のインデックスオブジェクトの総数を減らす傾向がある。その結果、メディア記録の徹底的な検索が実行されるときに検査される必要があるインデックスオブジェクトの数が制限される。特許請求の範囲の意味における「期間」は、「記録間隔」よりも長いことが理解され、「記録間隔」は、記録を管理するのに適した粒度（例えば、数分、数時間）を表すことができるが、「期間」は、古いメディア記録のバッチのクリーンアップを管理するのに適した粒度（例えば、数時間、数日、数週間）に対応することができる。したがって、連結されるインデックスオブジェクトが共通の期間（例えば、同じ記録日）に属するという条件は、インデックスオブジェクトが２つの異なる期間（例えば、異なる日付）からの記録を参照しないことを保証し、その結果、特定の日付からの全てのメディア記録の所望のパージを複雑さなしに達成することができる。

本発明の第４の態様は、インジェストコンポーネントと、記憶方法を実行するように構成されたメンテナンスコンポーネントとを備えるシステムに関する。

本発明の第５の態様は、検索方法を実行するように構成された検索コンポーネントを備えるシステムに関する。

本発明の第６の態様は、メンテナンス方法を実行するように構成されたメンテナンスコンポーネントを備えるシステムに関する。

本発明の第７の態様は、連結工程を除いて記憶方法を実行するように構成されたインジェストコンポーネントを備えるシステムに関する。

本発明は更に、コンピュータ、特に上記のインジェスト、メンテナンス、及び／又は検索コンポーネントに、上記の方法又は方法工程を実行させるための命令を含むコンピュータプログラムに関する。コンピュータプログラムは、データキャリアに記憶又は配布することができる。本明細書で使用される場合、「データキャリア」は、変調された電磁波若しくは光波等の一時的データキャリア、又は非一時的データキャリアであってもよい。非一時的データキャリアは、磁気、光学、又はソリッドステートタイプの永続的及び非永続的ストレージメディア等の揮発性及び不揮発性メモリを含む。依然として「データキャリア」の範囲内で、そのようなメモリは固定的に取り付けられてもよく、又は携帯可能であってもよい。

本発明によるシステム及びコンピュータプログラムは、一般に、上記で概説した第１、第２及び第３の態様の効果及び利点を共有し、それらは対応する程度の技術的変形を伴って実施することができる。

一般に、特許請求の範囲で使用される全ての用語は、本明細書で特に明示的に定義されない限り、技術分野におけるそれらの通常の意味に従って解釈されるべきである。「ａ／ａｎ／要素、装置、コンポーネント、手段、工程等」への全ての言及は、特に明記しない限り、要素、装置、コンポーネント、手段、工程等の少なくとも１つの例を指すものとして広く解釈されるべきである。本明細書に開示される任意の方法の工程は、明示的に述べられていない限り、記載された正確な順序で実行される必要はない。

ここで、以下、添付の図面を参照して、態様及び実施形態を例として説明する。

本発明の実施形態による、オブジェクトストア内のメディア記録を記憶及び検索するためのコンポーネントと、オブジェクトストアのメンテナンスを実行するための更なるコンポーネントとを有するシステムを示す図である。 本発明の実施形態による方法のフローチャートである。 本発明の実施形態による方法のフローチャートである。 本発明の実施形態による方法のフローチャートである。 オブジェクトストア内のメディア記録を記憶及び検索するために使用される例示的なインデックスオブジェクトを示す図である。 オブジェクトストア内のメディア記録を記憶及び検索するために使用される例示的なインデックスオブジェクトを示す図である。

ここで、本開示の態様は、本発明の特定の実施形態が示されている添付の図面を参照して、以下でより完全に説明される。しかしながら、これらの態様は、多くの異なる形態で具現化されてもよく、限定するものとして解釈されるべきではなく、むしろ、これらの実施形態は、本開示が徹底的かつ完全であり、本発明の全ての態様の範囲を当業者に完全に伝えるように、例として提供される。説明全体を通して、同様の番号は同様の要素を指す。

図１は、オブジェクトストア１２３内のメディア記録１５０を記憶及び検索するためのコンポーネント１００、１１０、１２０、１３０、１９０と、オブジェクトストア１２３のメンテナンスを実行するための更なるコンポーネントとを有するシステムを示す。メディア記録１５０は、メディアデータ１５１及びメタデータ１５２からなり、メタデータ１５２は、メディア記録１５０の再生中に必ずしもユーザにレンダリングされないが、レンダリングがどのように実行されるかに定量的及び定性的に影響を及ぼし得る技術的又は管理的性質の情報を含む。メタデータ１５２はまた、メディアデータ１５１の指定された符号化フォーマットが吸収することができない追加のコンテンツ関連データのために利用されてもよい。メディア記録１５０には、記録間隔１５３及び記録ソース１５４が更にアノテートされてもよい。記録間隔１５３は、基準クロック（例えば、ネットワーク時間、ＧＭＴ）を参照して、メディア記録１５０の取得の開始及び終了を示す。記録間隔１５３は、例えば、｛開始、終了｝、｛開始、継続｝又は｛継続、終了｝として表されてもよく、ここで、エントリの開始及び終了は当該基準クロックを指す。記録ソース１５４が所与の時点で最大でも１つのメディア記録１５０を生成することを理解すると、記録間隔１５３と記録ソース１５４との組合わせを検索クエリとして使用して、関連するメディア記録１５０を識別することができる。

図１に示す例では、メディア記録１５０はビデオ記録であり、メディアデータ１５１及びメタデータ１５２はビデオメタデータに関連するビデオデータを含む。そのようなビデオ記録を取得するのに適したビデオカメラ１３０が図１に示されている。ビデオカメラ１３０は、デジタルビデオカメラ、デジタル監視ビデオカメラ、又はデジタル監視カメラであってもよい。メタデータ１５２は、解像度、毎秒のフレーム数、符号化フォーマット等のビデオ記録の技術的特性に関連し得る。メタデータは、ビデオ記録を正確かつ効率的にレンダリング（再生）するために依拠され得る。

インジェストコンポーネント１９０は、データオブジェクト１６０、属性オブジェクト１７０、及びインデックスオブジェクト１８０として記録するメディアをオブジェクトストア１２３に記憶するように構成される。データオブジェクト１６０、属性オブジェクト１７０及びインデックスオブジェクト１８０は、いくつかの実施形態では、オブジェクトストア１２３が構成される同じオブジェクトタイプのインスタンスであってもよい。他の実施形態では、データオブジェクト１６０、属性オブジェクト１７０、及びインデックスオブジェクト１８０は、例えば、それらの指定されたペイロードサイズ又は関連する動作に関して異なる、２つ以上の異なるオブジェクトタイプに対応する。

検索コンポーネント１１０は、検索クエリを処理し、それに基づいて関連するメディア記録１５０を検索するように構成される。この目的のために、検索コンポーネント１１０は、処理回路１１２と、キャッシュ１１１として機能するメモリとを備える。処理回路１１２は、局所化された回路であってもよく、又は、１つ若しくは複数のプロセッサコアを有する分散回路であってもよい。キャッシュ１１１へのアクセスは、知覚可能な速度、コスト又は容量の制約が適用されないという意味でローカルである。

システムは、メモリ１２１及び処理回路１２２を含み、オブジェクトストア１２３を実装するストレージコンポーネント１２０（又はサーバ）を更に備える。オブジェクトストア１２３は、インジェストコンポーネント１９０からデータを受け取るように動作可能である。オブジェクトストア１２３は、検索コンポーネント１１０からの検索要求を受け入れて処理し、それに応答して検索結果を転送するように更に動作可能である。更に、検索コンポーネント１１０は、オブジェクトストア１２３からオブジェクトを検索することができ、すなわち、それらをストレージコンポーネント１２０から検索コンポーネント１１０に転送することができる。図１の介在する通信ネットワーク１４０によって示唆されるように、検索コンポーネント１１０がオブジェクトストア１２３へのリモートアクセスを有する場合、これらのコンポーネント間のコール数及びトラフィック容量は、遅延、ネットワーク輻輳へのわずかな寄与、及び／又は処理労力に関してコストを被る可能性がある。本開示において、オブジェクトストア１２３は、オブジェクトストレージアーキテクチャに従うストレージ技術のインスタンス（リポジトリ）である。任意選択で、オブジェクトストア１２３は、情報技術規格国際委員会によって発行されたＩＮＣＩＴＳ４５８－２０１１（情報技術－ＳＣＳＩオブジェクトベースのストレージデバイスのコマンド－２；ＯＳＤ－２）及びＩＮＣＩＴＳ４００－２００４（情報技術－ＳＣＳＩオブジェクトベースのストレージデバイスのコマンド；ＯＳＤ）等の規格に準拠し得る。
Ａｍａｚｏｎ Ｓｉｍｐｌｅ Ｓｔｏｒａｇｅ Ｓｅｒｖｉｃｅ（商標）（Ａｍａｚｏｎ Ｓ３）及びＭｉｃｒｏｓｏｆｔ Ａｚｕｒｅ Ｂｌｏｂ Ｓｔｏｒａｇｅ（商標）は、例示的なクラウドベースのオブジェクトストアサービスである。

オブジェクトストア１２３に対してメンテナンス（インデックスオブジェクト連結を含む）を実行するためのメンテナンスコンポーネント１２４が更に設けられる。メンテナンスコンポーネント１２４は、ストレージコンポーネント１２０の内部又は外部の専用ハードウェア（図示せず）に対応してもよく、又はストレージコンポーネント１２０の処理回路１２２上で、又はストレージコンポーネント１２０の外部の処理回路１２２上で実行されるソフトウェアコードとして実装されてもよい。メンテナンスコンポーネント１２４は、任意選択的に、オブジェクトストア１２３に現在記憶されているデータ構造の検査、並びにこれらの障害の防止、発見、及び修正に関する更なる責任を有し得る。オブジェクトストア１２３が実装されるメモリドライブ（複数可）の下位層態様は、別個のメンテナンスを受けることができることが理解される。

システムの記載されたコンポーネントは、実行時にそれらの間でデータ、メッセージ、及び／又は命令を交換することができる。コンポーネントは、共通の管理又は所有権の下にある必要はなく、例えば、オブジェクトストア１２３は、メディア記録１５０を提供する組織（例えば、セキュリティ会社）とは異なる組織（例えば、クラウドサービスプロバイダ）によってホストされてもよく、これは、メディア記録１５０を通常検索して閲覧する当事者（例えば、セキュリティ会社の顧客）とは異なる。したがって、コンポーネントが互いに物理的に近接して配置される必要もない。実装者がローカル配置と分散配置との間に有する柔軟な選択を説明するために、図１は、いくつかの対のコンポーネントが通信ネットワーク１４０（又は複数の通信ネットワーク１４０）を介して接続されることを示し、その各々がローカルエリア又はワイドエリアネットワークであってもよく、一方他のコンポーネントは直接接続を有する。

いくつかの実施形態では、メディア記録１５０のソース（例えば、任意選択的に後処理コンポーネントを備えたビデオカメラ１３０）は、ストレージコンポーネント１２０及びメンテナンスコンポーネント１２４と同じ場所に配置される。インジェストコンポーネント１９０は、ストレージコンポーネント１２０と同じ場所に配置されてもよく、又はストレージコンポーネントに実装されてもよく、又はインジェストコンポーネント１９０は独立したコンポーネントであってもよい。検索コンポーネント１１０（例えば、ＡＰＩ）は、ストレージコンポーネント１２０と同じ場所に配置することができ、又は検索コンポーネント１２０は、独立したコンポーネントとすることができる。いくつかの実施形態では、ユーザ（例えば、人のユーザ、ソフトウェアアプリケーション、クライアントコンピュータの接続）は、検索コンポーネント１１０に直接アクセスし、他の実施形態では、図１に示すように、ユーザは、ユーザ側コンポーネント１００上で実行するユーザインターフェース１０１（例えば、ウェブインターフェース）を介して検索コンポーネント１１０と対話する。これは、一方では、ストレージコンポーネント１２０と検索コンポーネント１１０との間のトラフィック容積が、通常、検索コンポーネント１１０とユーザ側コンポーネント１００との間のトラフィック量よりも大きくなり、他方では、検索コンポーネント１１０をストレージコンポーネント１２０のより近くに配置することができるため、有利である。

図２は、メディア記録１５０を記憶するための方法２００のフローチャートであり、これについては、引き続き図１を参照して説明する。方法２００の工程は、異なる方法で割り当てることができる。一実施形態では、全ての工程が同じコンポーネントによって実行される。別の実施形態では、割当て工程２１０、記憶工程２１２、２１４、２１８、及び計算工程２１６は、第１のコンポーネント（例えば、図１のインジェストコンポーネント１９０）で実行され、連結工程２２０は、独立した第２のコンポーネント（例えば、メンテナンスコンポーネント１２４）で実行される。この他の実施形態は、ストレージ動作を高速化することができ、及び／又は処理の大部分がより低い総処理負荷の期間に延期される、より経済的な実施に役立つことができる。更に別の実施形態では、初期工程２１０、２１２、２１４、２１６、２１８は図２に示す通りであるが、連結工程２２０は連結を開始する工程に置き換えられ、方法２００は同じコンポーネントによってその全体が実行される。連結を開始することは、メンテナンスコンポーネント１２４にコマンドを発行すること、又は連結が実行されるべきであることをメンテナンスコンポーネント１２４に示す状態でオブジェクトストア１２４に記憶されたデータを残すことを含むことができる。指示は暗黙的であってもよく、例えば、メンテナンスコンポーネント１２４は、閾値サイズを下回るオブジェクトストア１２３内のインデックスオブジェクト１８０を探すように、又は閾値サイズを下回るインデックスオブジェクト１８０の総数を定期的にカウントするように構成されてもよい。いずれの方法でも、インジェストコンポーネント１９０による新しいインデックスオブジェクト１８０の作成は、メンテナンスコンポーネント１２４によって通知され、したがって連結の開始として理解され得る。指示は明示的であってもよく、例えば、インデックスオブジェクトは「連結されていない」を表すフラグを持つ。

方法２００の最初の工程２１０において、記録識別子（ＩＤ）がメディア記録１５０に割り当てられる。図１、図５及び図６の例ＩＤ９８７４、ＩＤ９８７５、ＩＤ９８７６が示唆するように、記録ＩＤは、適切な長さを有する連続番号等の任意の数又は英数字文字列であってもよい。記録ＩＤは、オブジェクトストア１２４に記憶されている限り、メディア記録１５０に固有であることが好ましい。削除された古いメディア記録１５０の記録ＩＤは、新しいメディア記録１５０に再割り当てすることができる。記録ＩＤは、オブジェクトストア１２３が各記憶されたオブジェクトに割り当てることができるどのオブジェクト識別子とも無関係であることに留意されたい。

第２の工程２１２において、メディア記録１５０のメディアデータ１５１は、オブジェクトストア１２３内の一又は複数のデータオブジェクト１６０に記憶され、各データオブジェクト１６０は記録ＩＤを持つ。記録ＩＤは、データオブジェクト１６０のオブジェクト識別子に含まれてもよいし、オブジェクトメタデータアイテムに含まれてもよい。機能的には、記録ＩＤは、オブジェクトストア１２３が指定された記録ＩＤを有する全てのデータオブジェクト１６０の効率的な検索（例えば、専用の要求によって）を可能にするように、データオブジェクト１６０によって持たれる。データオブジェクト１６０は、メディアデータ１５１のみを記憶するために使用されてもよく、又はメディアデータ１５１に加えてデータを含んでもよい。いくつかの実施形態では、データオブジェクト１６０は、メディア記録１５０が生成されている間に、例えば所定の時間間隔で、又はメディアデータキャッシュが所定のレベルを超えたときに、オブジェクトストア１２３に漸進的に記憶されてもよい。他の実施形態では、方法２００は、メディア記録１５０が完了するまで実行されない。この場合、使用されるデータオブジェクト１６０の数は、オブジェクトストア１２３内のオブジェクトの最大許容サイズによって決定され得る。

方法２００の第３の工程２１４において、メディア記録１５０のメタデータ１５２は、属性オブジェクト１７０に記憶される。１つのメディア記録１５０のメタデータ１５２を、本開示では「メタデータアイテム」と表記する場合がある。第２の工程２１２で説明したように、属性オブジェクト１７０は、オブジェクトストア１２３が、指定された記録ＩＤを有する属性オブジェクト１７０の効率的な検索を可能にするように記録ＩＤを持つ。工程２１４は、新しい属性オブジェクト１７０を形成すること２１４．１と、その中にメタデータ１５２を記憶することと、を含むことができる。あるいは、メタデータ１５２は、修正（編集）２１４．２された既存のメタデータオブジェクト１５２に記憶されてもよい。更に代替的に、一又は複数の以前に記憶されたメディア記録のメタデータを含む既存の属性オブジェクト１７０は、以前に記憶されたメディア記録（複数可）のメタデータ、及び方法２００が実行されているメディア記録１５０のメタデータを含む新しい属性オブジェクト１７０によって置き換えられる。特にメタデータ１５２が工程２１４の後に変化することが予想されない場合、好ましい選択肢は、新たに形成された２１４．１属性オブジェクト１７０にメタデータ１５２を記憶することであり、それにより、オブジェクトストア１２３内の各属性オブジェクト１７０は、単一のメディア記録１５０のみのメタデータ１５２を含む。

第４の工程２１６において、メタデータ１５２のハッシュ１７１が計算される。これは、ハッシュ関数

によってメタデータ１５２をマッピングすることを含む。ハッシュ関数又は一方向関数は、ハッシュが検索コンポーネント１１０で再生成され得るように、事前定義されるものとする（例えば、再生可能であるものとする）。ハッシュ関数は、ＳＨＡ－２５６、ＳＨＡ３－５１２、及びＲＳＡ－１０２４等の暗号化又は非暗号化ハッシュ関数であってもよい。ハッシュ関数は方法２００内で安全関連の目的に使用されないため、衝突確率が許容可能に小さい限り、比較的単純なハッシュ関数を採用することができる。ハッシュ衝突は、検索コンポーネント１１０をキャッシュされたメタデータアイテムに誤って依存させる可能性があるが、許可されていない当事者にメタデータを公開しない。

異なる実施形態では、工程２１６は、メタデータ１５２全体をハッシュすること、又は所定の決定論的規則に従って抽出されたそのサブセットをハッシュすることを含むことができる。ハッシュ１７１は、メタデータ１５２と暗号ソルトとの組合わせに基づくことができる。これらの選択にかかわらず、メタデータ１５２のハッシュ１７１は、記録ＩＤとは無関係であることが有利であり、すなわち、記録ＩＤは、好ましくは、ハッシュ関数

への入力データの一部を形成すべきではない。このようにして、検索コンポーネント１１０は、このメタデータが以前のメディア記録１５０のメタデータと一致することをハッシュが示す場合に、オブジェクトストア１２３から後のメディア記録のメタデータを検索することを取り止めることができる。

方法２００の第５の工程２１８において、ハッシュ１７１、記録ＩＤ、並びにメディア記録１５０の記録間隔１５３及び記録ソース１５４の表示は、オブジェクトストア１２３内のインデックスオブジェクト１８０に記憶される。第５の工程２１８の後、方法２００の実行により、図１に示すデータオブジェクト１６０、属性オブジェクト１７０、及びインデックスオブジェクト１８０が生成される。より正確には、ハッシュ１７１、記録ＩＤ、並びに記録間隔１５３と記録ソース１５４との間の表示を、
－新しく形成された（２１８．１）インデックスオブジェクト１８０－２において（ＩＤ９８７６が、記憶されるべきメディア記録１５０の記録ＩＤである、図６Ｂを参照されたい）、
－修正された２１８．２インデックスオブジェクト１８０－１において（図５Ａに示されるようにインデックスオブジェクト１８０－１にメディア記録ＩＤ９８７６に関する情報を付加する可能な結果を示す図５Ｂを参照されたい）、又は
－情報が付加され、オブジェクトストア１２３内の既存の以前に記憶されたインデックスオブジェクトを置換する（２１８．３）代替インデックスオブジェクトにおいて、
記憶することができる。
説明のために、この例では、ハッシュ１７１、記録ＩＤ、並びに記録間隔１５３及び記録ソース１５４の表示は、新たに形成されたインデックスオブジェクト１８０－２に記憶されていると仮定する。この場合、新たに形成されたインデックスオブジェクト１８０－２は、任意で、記録ＩＤを持ってもよい（すなわち、記録ＩＤを含むことに加えて）。インデックスオブジェクト１８０が記録ＩＤを持つ場合、オブジェクトストア１２３に単一のリスト操作を発行することによって、複数のインデックスオブジェクトを便利にリストすることが可能になる。そうではなく、インデックスオブジェクト１８０が記録ＩＤを持たない場合、それぞれの記録ＩＤを読み取るために、インデックスオブジェクトが存在するのと同じ数の検索動作（例えば、取得する）が必要とされ得る。

方法２２０の第６の工程２２０では、次に、新しく形成されたインデックスオブジェクト１８０－２が既存のインデックスオブジェクト１８０－１と連結される。例示すると、図６Ａ、図６Ｂ及び図６Ｃは、３つの連続する時点におけるオブジェクトストア１２３のコンテンツのサブセットを示す。コンテンツは、メディア記録ＩＤ９８７４及びＩＤ９８７５の情報を保持する既存のインデックスオブジェクト１８０－１；記憶方法２００の実行によって記憶されることになるメディア記録ＩＤ９８７６についての情報を保持する新たに形成されたインデックスオブジェクト１８０－２；並びに既存及び新しく形成されたインデックスオブジェクト１８０－１、１８０－２の連結から生じるインデックスオブジェクト１８０－３を含む。連結から再送信されるインデックスオブジェクト１８０－３は、３つ全てのメディア記録ＩＤ９８７４、ＩＤ９８７５、ＩＤ９８７６の情報を含むので、検索コンポーネント１１０は、より少ない１つのインデックスオブジェクトを検査することによって検索クエリを徹底的に評価することができる。既存のインデックスオブジェクト１８０－１は、以前のメディア記録１５０を記憶した結果としてオブジェクトストア１２３に記憶されていてもよい。方法２００の特定の実施形態では、第６の工程２２０は、スケジュールされた間隔（例えば、

ごと、

ごと、各作業日の終わりに）で、及び／又は手頃な処理リソースが利用可能なときはいつでも実行される。第６の工程２２０は、記録間隔１５３が共通期間内に含まれるメディア記録１５０を参照するとすぐに、２つのインデックスオブジェクトが連結されるように構成されてもよい。このようにして、第６の工程２２０が十分に多数回実行された後、単一のインデックスオブジェクト１８０はその期間からの全てのメディア記録１５０を参照し、これにより後続の検索が簡素化される。「期間」（例えば、数時間、数日、数週間）は、典型的な「記録間隔」（例えば、数分、数時間）よりも長く構成されることが好ましいことが想起される。２つのインデックスオブジェクトＩＯ１、ＩＯ２の連結は、
－ＩＯ１のコンテンツをＩＯ２に付加し、オブジェクトストア１２３からＩＯ１を削除すること、
－ＩＯ２のコンテンツをＩＯ１に付加し、オブジェクトストア１２３からＩＯ２を削除すること、又は
－ＩＯ１及びＩＯ２の結合されたコンテンツを保持し、オブジェクトストア１２３内のＩＯ１及びＩＯ２を置き換える新しいインデックスオブジェクトＩＯ３を形成すること、
を含み得る。

最初に発表されたように、及び当業者が本開示を検討した後に理解するように、方法２００は、異なる一連の工程で実行することができる。例えば、工程２１８は工程２１４の前に実行することができ、工程２１６は工程２１４の前に実行することができる。

次に、図３を参照して、ここで、メディア記録１５０を検索する方法３００について説明する。方法３００は、オブジェクトストア１２３へのアクセスを有し、キャッシュ１１１へのローカルアクセスを有する検索コンポーネント１１０による実行に適している。方法３００は、キャッシュ１１１が多数のメディア記録１５０のメタデータ１５２を含むような時点で実行することができる。キャッシュ内のメタデータ１５２は、例えば、以前の検索の副産物として、又はオブジェクトストア１２３内の全てのメタデータ１５２のスナップショットの専用記憶の結果として、オブジェクトストア１２３内の属性オブジェクト１７０のメタデータアイテムのコピーであってもよい。異なる実施形態では、キャッシュ１１１は、そのようなメタデータアイテムを含むフリーメタデータアイテム又は属性オブジェクト１７０を保持することができる。

方法３００の第１の工程３１０において、検索クエリが受け取られる。検索コンポーネント１１０は、ユーザ、例えば人のユーザ、ソフトウェアアプリケーション、又は接続クライアントコンピュータから検索クエリを受信することができる。検索クエリの許容されるフォーマットは、特にオブジェクトストア１２３がサポートする検索要求の結果として、異なる実施形態間で異なり得る。例えば、検索クエリは、記録間隔、記録ソースの識別子若しくは他の属性、及び／又は記録ＩＤを参照することができる。メディア記録１５０のメタデータ１５２は、オブジェクトストア１２３内のインデックスオブジェクト１８０の外部に記憶されるため、この例では、メタデータ１５２に関して定式化された検索クエリを処理することは不可能であり得る。

オブジェクトストア１２３が、検索要求によって指定された属性を有する記録ソース１５４によって取得された、及び／又は検索要求によって指定された間隔と重複する記録間隔１５３で取得されたメディア記録１５０を参照する全てのインデックスオブジェクト１８０（例えば、それらのオブジェクトＩＤによって）を識別するために検索要求を処理することができる場合、オブジェクトストア１２３内の属性オブジェクト１８０を検索することなく（すなわち、属性オブジェクト１８０を検索コンポーネント１１０に転送することなく）、検索クエリを評価することができる。これは、実行フローが、一致メディア記録１５０を識別する工程３１４に直接進むことを意味し、識別３１４は、オブジェクトストア１２３によって保持されるインデックスオブジェクトに基づいて実行される。この検索能力を欠くオブジェクトストア１２３に適合された代替実施形態では、方法３００は、インデックスオブジェクト１８０を検索すること（３１２）を含み（例えば、検索コンポーネント１１０がローカルアクセスを有するメモリにインデックスオブジェクト１８０を転送する）、その後、検索されたインデックスオブジェクト１８０に基づいて一致メディア記録１５０の識別３１４が実行される。どちらの方法でも、工程３１４で識別される一致メディア記録１５０は、検索クエリに一致するようなものである。

記憶方法２００の前述の説明を考慮すると、インデックスオブジェクト１８０のうちの少なくとも１つは、連結２２０の結果であり得る複数のメディア記録１５０を参照することが理解され得る。インデックスオブジェクト１８０は、メディア記録１５０ごとに、メディア記録１５０のメタデータ１５２の記録ＩＤ及びハッシュ１７１を記憶する。任意選択で、インデックスオブジェクト１８０は、メディア記録１５０ごとに、記録間隔１５３及び記録ソース１５４の指示を更に記憶する。

検索方法３００の次の工程３１６では、一致メディア記録１５０のハッシュ１７１（すなわち、一致メディア記録１５０のメタデータ１５２のハッシュ）がキャッシュ１１１内の（任意のメタデータアイテムの）任意のメタデータ１５２のハッシュ１７１と一致するかどうかが判定される。キャッシュ１１１内のメタデータアイテムのハッシュ１７１は、メタデータアイテムがキャッシュ１１１に記憶されたときに、記憶方法２００で使用されたものと同一のハッシュ関数

を使用して計算されていてもよい。ハッシュが一致する場合（例えば、それらの値は同一である。ブロック３１６からの「はい」の分岐）、キャッシュされた属性オブジェクト１７０にローカルにアクセスすることによってメタデータ１５２を便利に取得すること（３２０．１）ができる。ハッシュが一致しない場合（ブロック３１６からの「いいえ」の分岐）、対応する属性オブジェクト１７０がオブジェクトストア１２３から検索され（３１８）、メタデータ１５２が、検索された属性オブジェクト１７０から検索される（３２０．２）。検索コンポーネント１１０がオブジェクトストア１２３への非ローカルアクセスを有するシステムでは、そのような検索３１８は、遅延、ネットワーク輻輳へのわずかな寄与、及び／又は処理労力に関してコストを被る可能性がある。

メタデータ１５２は、いずれのオプションによって取得されても（３２０）、検索クエリを受信したユーザと共有することができる（３１０）。任意選択的に、方法３００の後続の工程３２２、３２４は、メタデータ１５２を検査する機会を得た後にユーザがこれを承認した場合にのみ実行されるという意味で条件付きとすることができる。

方法３００の次の工程３２２において、一致メディア記録１５０のデータオブジェクト１６０がオブジェクトストア１２３から検索される。このとき、メディアデータ１５１とメタデータ１５２とを結合してメディア記録１５０を復元することができる。このようにして、メディア記録１５０は、再生３２４等の様々な目的のために利用可能になる。再生３２４は、再生アプリケーション又は再生デバイス（図示せず）を使用して、メタデータ１５２にしたがって実行されてもよい。

いくつかの実施形態では、属性オブジェクト１７０の検索３１８及び／又は一若しくは複数のデータオブジェクト１６０の検索３２２は、一致メディア記録１５０の記録ＩＤを使用してオブジェクトストア１２３に要求を発行することを含む。そのような要求は、上述したように、属性オブジェクト１７０及びデータオブジェクト１６０が記録ＩＤを持つので、比較的低コストで実行することができる。

方法３００の更なる発展形態では、一致メディア記録１５０の属性オブジェクト１７０を検索する工程３１８は、検索された属性オブジェクト１７０をキャッシュ１１１に記憶することを含む。このようにして、属性オブジェクト１７０の比較的高価な検索３１８は、現在の検索だけでなく、一致メディア記録１５０が同一であるか又は同一のメタデータ１５２を有する任意の潜在的な後の検索にも利益をもたらす。

メタデータハッシュ２１６は、記憶方法２００の必須ではない工程であることに留意されたい。記憶方法２００が工程２１６を含まない実施形態では、以下の工程２１８は、記録ＩＤ、記録間隔１５３、及び記録ソース１５４のみをインデックスオブジェクト１８０に記憶することを含む。これに対応して、検索方法３００は、判定３１６が省略され、実行フローが工程３１４から工程３１８及び３２０．２に直接進むように適合されてもよく、すなわち、属性オブジェクト１７０は常にオブジェクトストア１２３から検索される。

図４を参照すると、説明したタイプの複数のメディア記録１５０を記憶するためのオブジェクトストア１２３のメンテナンスを実行する方法４００が更に提供される。したがって、メンテナンス方法４００は、オブジェクトストア１２３が一又は複数のインデックスオブジェクト１８０を保持するときに実行されるのに適しており、各インデックスオブジェクト１８０は、少なくとも１つのメディア記録１５０を参照し、メディア記録１５０について、メディア記録１５０のメタデータ１５２の記録ＩＤ及びハッシュ１７１を記憶する。

メンテナンス方法４００は、それぞれの記録間隔１５３が共通の期間に含まれるメディア記録１５０を参照する２つ以上のインデックスオブジェクト１８０を見つける工程４１０から始まる。「期間」（例えば、数時間、数日、数週間）は、典型的な「記録間隔」（例えば、数分、数時間）よりも長く構成されることが好ましいことが想起される。

そのようなインデックスオブジェクト１８０がオブジェクトストア１２３内に見つかった場合、方法４００は、インデックスオブジェクト１８０をより少数のインデックスオブジェクト１８０、好ましくは単一のインデックスオブジェクトに連結することを含む。図６Ｂ及び図６Ｃは、オブジェクトストア１２３のコンテンツが連結の結果としてどのように変化するかを示す。同様に実行することができる記憶方法２００の工程２２０の上記の説明を参照する。

上述したように、メンテナンス方法４００は、連結の進行を加速させるための特定の理由がない限り、例えばバックグラウンドプロセスとして、低い優先度で実行されてもよい。方法４００の実施形態は、オブジェクトストア１２３が実装されるメモリドライブの低層アスペクトのメンテナンスを実行すること、又はオブジェクトストア１２３に現在記憶されているデータ構造の検査、並びにこれらの障害の防止、発見、及び修正に対応することを含むことができる。

本開示の態様は、いくつかの実施形態を参照して主に上述されている。しかしながら、当業者によって容易に理解されるように、添付の特許請求の範囲によって定義されるように、上記で開示されたもの以外の他の実施形態も本発明の範囲内で等しく可能である。

Claims (11)

1. ビデオメタデータ（１５２）に関連付けられたビデオデータ（１５１）を含むビデオ記録（１５０）を、検索コンポーネント（１１０）において検索する方法（３００）であって、前記ビデオメタデータ（１５２）は、前記ビデオ記録の再生中に依拠される前記ビデオ記録（１５０）の技術的特性に関連し、且つ解像度、毎秒のフレーム数、及び符号化フォーマットのうち１つ以上を含み、前記方法は、オブジェクトストレージアーキテクチャによるオブジェクトストア（１２３）へのアクセス及びキャッシュ（１１１）へのローカルアクセスを有する検索コンポーネント（１１０）において実装され、前記方法は、
   検索クエリを受信すること（３１０）と、
   前記オブジェクトストア（１２３）内の一又は複数のインデックスオブジェクト（１８０）に基づいて、前記検索クエリに一致する、一致ビデオ記録（１５０）を識別すること（３１４）であって、前記一又は複数のインデックスオブジェクト（１８０）のうちの少なくとも１つは、複数のビデオ記録（１５０）を参照し、ビデオ記録（１５０）ごとに、前記ビデオ記録（１５０）のメタデータ（１５２）の記録ＩＤ、ハッシュ（１７１）、並びに前記ビデオ記録（１５０）の記録間隔（１５３）及び記録ソース（１５４）を記憶する、一致ビデオ記録（１５０）を識別すること（３１４）と、
   前記一致ビデオ記録（１５０）のビデオメタデータ（１５２）のハッシュ（１７１）が前記キャッシュ（１１１）内の属性オブジェクト（１７０）に含まれる任意のビデオメタデータ（１５２）のハッシュ（１７１）と一致するか否かを判定すること（３１６）であって、前記一致ビデオ記録（１５０）の前記ビデオメタデータ（１５２）の前記ハッシュ（１７１）及び前記キャッシュ（１１１）内の各ビデオメタデータ（１５２）のハッシュ（１７１）は、所定のハッシュ関数によって計算される、一致するか否かを判定すること（３１６）と、
   一致する場合、前記キャッシュ（１１１）内の前記属性オブジェクト（１７０）から前記メタデータ（１５２）を取得すること（３２０．１）と、
   一致しない場合、前記一致ビデオ記録（１５０）の、前記ビデオメタデータ（１５２）を記憶し且つ前記記録ＩＤを持つ属性オブジェクト（１７０）を前記オブジェクトストア（１２３）から検索し（３１８）、検索された前記属性オブジェクト（１７０）から前記ビデオメタデータ（１５２）を取得し（３２０．２）、且つ検索された前記属性オブジェクト（１７０）を前記キャッシュ（１１１）内に記憶することと、
   前記一致ビデオ記録（１５０）の一又は複数のデータオブジェクト（１６０）を前記オブジェクトストア（１２３）から検索すること（３２２）と、
   を含む、方法（３００）。
2. 前記検索クエリが、記録時刻及び／又は記録ソースを指定する、
   請求項１に記載の方法。
3. 複数のビデオ記録を指す前記一又は複数のインデックスオブジェクト（１８０）のうちの前記少なくとも１つが、一又は複数のインデックスオブジェクトの連結によって形成されている、請求項１に記載の方法。
4. 前記オブジェクトストア（１２３）から前記一又は複数のインデックスオブジェクト（１８０）を検索すること（３１２）を更に含む、請求項１に記載の方法。
5. インジェストコンポーネント（１９０）において、
   前記記録ＩＤを前記ビデオ記録（１５０）に割り当てること（２１０）と、
   オブジェクトストレージアーキテクチャに従って、前記オブジェクトストア（１２３）内の一又は複数のデータオブジェクト（１６０）内に前記ビデオデータ（１５１）を記憶すること（２１２）であって、各データオブジェクト（１６０）は、前記記録ＩＤを持つ、前記ビデオデータ（１５１）を記憶すること（２１２）と、
   前記ビデオメタデータ（１５２）を、前記オブジェクトストア（１２３）内の、前記記録ＩＤを持つ前記属性オブジェクト（１７０）に記憶すること（２１４）と、
   所定のハッシュ関数を使用して前記ビデオメタデータ（１５２）の前記ハッシュ（１７１）を計算すること（２１６）と、
   前記ビデオ記録（１５０）の前記ハッシュ（１７１）、前記記録ＩＤ、前記記録間隔（１５３）及び前記記録ソース（１５４）を、前記オブジェクトストア（１２３）内のインデックスオブジェクト（１８０，１８０－２）に記憶すること（２１８）と、
   メンテナンスコンポーネント（１２４）において、
   前記インデックスオブジェクト（１８０－２）を既存のインデックスオブジェクト（１８０－１）と連結すること（２２０）と、
   を更に含む、請求項１に記載の方法。
6. 前記既存のインデックスオブジェクト（１８０－１）が、記憶される前記ビデオ記録（１５０；ＩＤ９８７６）と同じ期間に含まれる記録間隔（１５３）を有する少なくとも１つのビデオ記録（１５０；ＩＤ９８７４、ＩＤ９８７５）を指す、請求項５に記載の方法。
7. 前記ハッシュ（１７１）、前記記録ＩＤ、前記記録間隔（１５３）及び前記記録ソース（１５４）が記憶される、新しいインデックスオブジェクト（１８０－２）を形成すること（２１８．１）を更に含む、請求項５に記載の方法。
8. 前記ビデオメタデータ（１５２）の前記ハッシュ（１７１）が、前記記録ＩＤとは無関係である、請求項５に記載の方法。
9. 前記ビデオメタデータ（１５２）を前記記憶すること（２１４）が、新しい属性オブジェクトを形成すること（２１４．１）を含む、請求項５に記載の方法。
10. ビデオ記録（１５０）を検索するように構成されたシステムであって、前記システムが、オブジェクトストレージアーキテクチャによるオブジェクトストア（１２３）へのアクセス及びキャッシュ（１１１）へのローカルアクセスを有する検索コンポーネント（１１０）を備え、前記検索コンポーネント（１１０）が、請求項１に記載の方法を実行するように構成されている、システム。
11. ビデオ記録（１５０）を記憶するように更に構成され、前記システムが、請求項５に記載の方法を実行するように更に構成された、インジェストコンポーネント（１９０）とメンテナンスコンポーネント（１２４）とを更に備える、請求項１０に記載のシステム。

Images