JP2022542643A - パーセプチュアルフレームハッシングを使用したビデオメタデータの識別および検索 - Google Patents

Abstract

ショッパブルビデオは、視聴者が、ビデオに現れる商品を識別して購入することを可能にする。ビデオのフレーム中のアイテムに関する情報を検索するために、再生装置は、そのフレームのパーセプチュアルハッシュを生成し、そのハッシュを使用して、ビデオの異なるバージョンのパーセプチュアルハッシュを保存している第１のデータベースに問い合わせる。データベースの問い合わせはフレームに対する識別子を返し、これが次に、アイテム情報を保存する第２のデータベースに問い合わせるために使用される。この問い合わせの結果は再生装置に返され、再生装置はそれらをユーザに示し、これにより視聴者はアイテムに関してさらに詳しく知り、それを購入することが可能になる。ビデオの異なるバージョンのパーセプチュアルハッシュに基づいた問い合わせを使用すると、フォーマットの違いにもかかわらず、マッチが返される可能性が高くなる。また、別々のハッシュデータベースおよびメタデータデータベースを使用することで、ハッシュを変更せずにメタデータを更新することが可能になる。【選択図】 図１

Description

関連出願の相互参照
本出願は、米国特許出願第６２／８７０，１２７号（２０１９年７月３日出願）の米国特許法１１９条（ｅ）の下での優先権利益を主張し、引用することによりその全体が本明細書の一部をなすものとする。

ショッパブルビデオ（shoppable video）は、ビデオを視聴している視聴者が、ファッション、アクセサリー、家庭用品、テクノロジーデバイス、さらにはビデオに表示されるメニューやレシピのアイテムを買い物することを可能にする。視聴者がビデオを見ると、視聴者は、購入したいアイテムがビデオに表示されるのを見い出す。視聴者はリモコンのボタンを押すか、リモコンのマイクに話しかけることで、価格や在庫情報など、そのアイテムに関する情報を得ることができる。テレビの中にあるかまたはテレビに結合されたプロセッサは、この要求を受信し、それをサーバに送信し、サーバはアイテムに関する情報をデータベースから検索し、それをプロセッサに返す。テレビは、アイテムに関する情報を視聴者に表示し、視聴者はアイテムを購入したり、類似製品に関する情報を要求したりすることができる。

ショッパブルビデオは、各ビデオフレーム中の製品を認識するために、手動で、または機械学習技術を使用して、通常、テレビに表示される前にタグ付けされる。タグ付けされた製品の製品メタデータは、対応するビデオフレームにマッチ（match：合致）され、データベースに保存される。視聴者が製品メタデータを要求すると、プロセッサは対応するビデオフレームを識別し、その後、それらのビデオフレームに対する製品メタデータを検索する。

ショッパブルビデオの課題の１つは、ビデオフレーム内の製品に関する情報に対する視聴者の要求を、データベース中の情報にマッチさせることである。同一のショッパブルビデオは、多くの異なるフォーマットのうちの１つで表示される場合があり、表示されているビデオフレームを対応するビデオフレームにマッチさせる能力を複雑にする。理由の１つとしては、可能なフォーマットの数は経時的に増加するため、それぞれの可能なフォーマットにタグを付け、対応するフレームのそれぞれについて情報を記憶することは実用的ではない。

本技術は、パーセプチュアルハッシング（perceptual hashing）を使用してソースビデオ（source video）のフレームを識別することにより、この課題に対処する。本方法の一実施例では、プロセッサは、ソースビデオの異なるバージョンのそれぞれのフレームに対してハッシュベクトル（hash vector）を生成する。これらのハッシュベクトルは、データベース中のソースビデオに関する情報と関連付けられている。スマートテレビ、セットトップボックス付きテレビ、コンピュータ、またはモバイルデバイスなどの再生装置（playback device）が、ソースビデオの第１のバージョンを再生するとき、ソースビデオの第１のバージョンの第１のフレームに対する第１のハッシュベクトルを生成する。この第１のハッシュベクトルは、例えば、データベースに問い合わせる（query）ためにアプリケーションプログラミングインターフェース（ＡＰＩ：application programming interface）を使用して、データベース中のハッシュベクトルの中のマッチするハッシュベクトルにマッチされる。第１のハッシュベクトルを、マッチするハッシュベクトルにマッチさせることに応答して、ソースビデオに関する情報が、データベースから検索される。

第１のハッシュベクトルがマッチするハッシュベクトルにマッチすると判断することには、第１のハッシュベクトルが、マッチするハッシュベクトルの閾値距離（threshold distance）内にあると判断することを含むことができる。マッチするハッシュベクトルは、ソースビデオの第１のバージョンとは異なるソースビデオの第２のバージョンのフレームに対するものとすることができる。

ハッシュベクトルおよび第１のハッシュベクトルは、パーセプチュアルハッシングプロセス（perceptual hashing process）、例えばパーセプションハッシング（ｐＨａｓｈ：perception hashing）、差分ハッシング（ｄＨａｓｈ：difference hashing）、平均ハッシング（ａＨａｓｈ：average hashing）、およびウェーブレットハッシング（ｗＨａｓｈ：wavelet hashing）を用いて生成することができる。第１のハッシュベクトルの生成にかかる時間は、約１００ミリ秒以下とするとができる。第１のハッシュベクトルは、４０９６ビット以下のサイズを有してもよい。第１のハッシュベクトルの生成は、一定の間隔（regular interval）で、および／または視聴者からのコマンドに応答して自動的に発生させることができる。

必要に応じて、ハッシュベクトル（hash vector）をシャード（shard：断片化）して、シャード化されたデータベース（shard database）に保存することができる。言い換えれば、ハッシュベクトルは、サブセットに分離または分割することができ、各サブセットは、データベースの異なるシャード（断片）に保存される。ハッシュベクトルは、ランダムに、またはハッシュベクトルがどの程度の頻度でアクセスされるかもしくはどの程度最近にアクセスされたか、ハッシュベクトル間の距離、および／またはハッシュベクトルの特徴に基づいて、サブセットに分割することができる。

本技術は、ソースビデオに関連付けられたメタデータを識別および取得するためにも使用することができる。再び、プロセッサは、ソースビデオの少なくとも１つのバージョンのそれぞれのフレームに対してハッシュベクトルを生成し、ハッシュベクトルを第１のデータベースに保存する。第２のデータベースは、それぞれのフレームに対応するメタデータ（metadata）を保存する。（このメタデータは、第１のデータベース中のハッシュベクトルを変更することなく更新することができる。）再生装置は、ソースビデオの第１のバージョンを再生する。再生装置または関連付けられたプロセッサは、ソースビデオの第１のバージョンの第１のフレームに対する第１のハッシュベクトルを生成する。ＡＰＩサーバは、第１のハッシュベクトルを、第１のデータベース中のハッシュベクトルの中のマッチするハッシュベクトルにマッチさせる。第１のハッシュベクトルをマッチするハッシュベクトルにマッチさせることに応答して、ＡＰＩは、第２のデータベースからマッチするハッシュベクトルに対応するメタデータを検索し、再生装置はメタデータを視聴者に表示する。

メタデータは、ソースビデオ内の位置、ソースビデオ中の俳優が着用する衣服、ソースビデオ中に現れる製品、またはソースビデオを再生する音楽のうちの少なくとも１つを表することができる。ハッシュベクトルは、それぞれのタイムスタンプ（timestamp）によってメタデータと関連付けることができる。

第１のハッシュベクトルをマッチするハッシュベクトルにマッチさせることは、第１のハッシュベクトルをＡＰＩサーバに送信することを含むことができる。ＡＰＩサーバは、第１のハッシュベクトルが、マッチするハッシュベクトルにマッチすると判定し、次いで、第１のデータベース中のマッチするハッシュベクトルと関連付けられたタイムスタンプを識別する。この場合、メタデータの検索は、タイムスタンプに基づいて第２のデータベースに問い合わせる（query）こと、およびタイムスタンプに関連付けられたメタデータを第２のデータベースから検索することをさらに含む。第１のハッシュベクトルがマッチするハッシュベクトルにマッチすると判断することは、第１のハッシュベクトルがマッチするハッシュベクトルの閾値距離内にあることを含むことができる。

ビデオに関連付けられたメタデータを識別、取得、および表示するための方法はまた、ディスプレイを介してビデオを再生することと、ビデオの第１のフレームに対する第１のハッシュベクトルを生成することと、第１のハッシュベクトルをＡＰＩサーバに送信することと、ＡＰＩサーバを介して、第１のフレームに関連付けられたメタデータをメタデータデータベースから取得することとを含むことができる。メタデータは、第１のハッシュベクトルを、ハッシュベクトルデータベースに格納された第２のハッシュベクトルにマッチさせることに応答して、第１のデータベースから検索される。ディスプレイは、第１のフレームと関連付けられたメタデータをユーザに表示する。

別の観点から、データベースは、ビデオの第１のフレームに対して生成された第１のハッシュベクトルを受信する。データベースは、第１のハッシュベクトルを保存し、第２のハッシュベクトルに基づいて再生装置からクエリまたは問い合わせ（query）を受信する。データベースは、第２のハッシュベクトルに対する問い合わせを実行し、第２のハッシュベクトルを第１のハッシュベクトルにマッチさせることに応答して、第１のハッシュベクトルと関連付けられたタイムスタンプをＡＰＩに送信する。このタイムスタンプは、メタデータをビデオの第１のフレームと関連付ける。

別の実施例では、プロセッサは、ソースビデオの第１のフレームに対する第１のハッシュベクトルを生成する。第１のデータベースは、第１のハッシュベクトルを第１のデータベースに保存する。再生装置は、ソースビデオの１つのバージョンを再生する。同じプロセッサまたは別のプロセッサが、ソースビデオのそのバージョンの第２のフレームに対して第２のハッシュベクトルを生成する。第２のハッシュベクトルは、第１のデータベース中の第１のハッシュベクトルにマッチさせられる。第２のハッシュベクトルを第１のハッシュベクトルにマッチさせることに応答して、第２のハッシュベクトルに対応するタイムスタンプが検索され、再生装置に送信されうる。

前述の概念および追加的概念のすべての組み合わせが（このような概念は相互に矛盾していないという前提で）以下でより詳細に論じられており、本明細書に開示する本発明の主題の一部である。特に、本開示に添付されて表わされる特許請求される主題のすべての組み合わせは、本明細書に開示する本発明の主題の一部である。引用することにより本明細書の一部をなすものとする、任意の開示においても現れる場合がある、本明細書に使用する用語には、本明細書に開示する特定の概念と最も一致する意味が与えるべきである。

当業者であれば、図面が主として例示的な目的で提示されていて、本明細書に記載の本発明の主題の範囲を制限することを意図していないことを理解するであろう。図面は必ずしも一定の比率ではなく、いくつかの実例では、本明細書に開示する本発明の主題のさまざまな態様は、異なる特徴の理解を容易にするために、図面内で誇張または拡大されて示される場合がある。図面では、同様の参照文字は概して、同様の特徴（例えば、機能的および／または構造的に類似した要素）を意味する。

図１は、ビデオ中の要素への即時アクセスを可能にするシステムを示す。 図２は、ソースビデオの異なるバージョンに対するハッシュベクトルを生成および保存するためのプロセスを示す流れ図である。 図３は、ソースビデオに対するメタデータを生成および保存するためのプロセスを示す流れ図である。 図４は、パーセプチュアルフレームハッシングを使用して、ビデオ中のオブジェクトに関するメタデータを検索するためのプロセスを示す流れ図である。

本明細書に開示される技術は、テレビ視聴者に、ビデオに示される製品、場所、およびその他の情報への即時アクセスを提供するのに役立つ。より具体的には、本明細書に開示される技術は、表示されているビデオ中の要素（例えば、製品、場所など）を識別することと、これらの要素に関する情報を視聴者に表示することとの間の時間および／または摩擦（friction）を低減する。その後、視聴者は、情報を保存する、および／またはビデオ中の好きな製品を購入することができる。

本技術は、パーセプチュアルハッシング（perceptual hashing）を使用して、再生装置上で視聴者に示されたビデオフレームを識別する。ビデオフレーム中のアイテムに関する情報を得るために、再生装置は、フレーム画像のパーセプチュアルハッシュ（perceptual hash）を生成し、そのハッシュ（hash）をサーバに送り、サーバは、様々な異なるフォーマットの様々なビデオからのフレームに対するパーセプチュアルハッシュおよびタイムスタンプ、または他の識別子を含むハッシュデータベース（hash database）に問い合わせ（query）る。この問い合わせ（query：クエリ）は識別子を返し、識別子を使用して、フレーム中のアイテムに関する情報もしくはメタデータのため、または視聴者の調査もしくはその他のデータ収集操作のために、別のデータベースに問い合わせることができる。別の方法として、メタデータは、ハッシュと同じデータベースに保存され、識別子と共に返すことができる。このメタデータには、ソースビデオからの位置、衣服、製品、音楽、もしくはスポーツスコアに関する情報、またはビデオ自体に関する詳細情報（例えば、ランタイム、概要、キャストなど）が含むことができる。サーバはこの情報またはメタデータを再生装置に返し、その後にそれをユーザに表示すことができる。

パーセプチュアルハッシュ（perceptual hash）を使用することは、ビデオフレームおよびそれらのビデオフレーム中のオブジェクトを識別するための他の技術よりもいくつかの利点を提供する。まず、パーセプチュアルハッシュの送信は、ビデオフレームまたは他の識別情報の送信よりも消費するアップストリーム帯域幅（upstream bandwidth）が少ない。パーセプチュアルハッシュを生成しマッチさせることは、専用のハードウェアを必要としない。パーセプチュアルハッシュは、ビデオ品質の劣化に対して非常に堅牢であり、より広範なビデオ視聴および送信条件にわたって、正しいマッチの可能性を高める。また、視聴者のプライバシーも保護される。ハッシュデータベースがない場合、パーセプチュアルハッシュを傍受する人物が、再生装置上に表示されているコンテンツを把握することは決してない。そして、視聴者のみが所有する任意のコンテンツ（例えば、ホームムービー）については、（前述したようなハッシュデータベースを用いても）いかなる人物も、ハッシュ値（hash value）に基づいて再生装置上に何が表示されているかを識別できる手段は、実際上ない。これは、同じハッシュ値をもたらす、生成できる画像の数がほぼ無限にあるため、ソース画像をハッシュから推測またはリバースエンジニアリングすることは事実上不可能である。（技術的には、複数のフレームが同じハッシュベクトルを生成することができるが、５１２ビットのハッシュベクトルについては、２^５１２個の可能なハッシュベクトル（１の後に１５４個のゼロ）が存在するため、圧縮されたハッシュ空間（hash space）は、同じハッシュベクトルを使用して異なるフレームをエンコードすることなく、ほぼ無限のフレームをエンコードするのに十分な大きさである。）

さらに、（同じデータベース中のハッシュと関連付けられたアイテム情報とは対照的に）ハッシュデータベースおよびメタデータデータベースを二分岐させる（bifurcate）ことによって、ハッシュデータベースに影響を与えることなく、所定のフレームと関連付けられたメタデータを更新することが可能になる。例えば、所与のコンテンツに表示される製品に関するメタデータは、ハッシュデータベースの変更を必要とせずに、その在庫／価格が変更するにつれて頻繁に更新することができる。

図１は、スマートテレビ、別個のセットトップボックスを備えたテレビ、コンピュータ、タブレット、またはコンテンツプロバイダ１２０に結合されたスマートフォンなどの再生装置１１０上のいくつかのフォーマット１２５の１つで表示することができる、ソースビデオ１２１中の要素への即時のアクセスを可能にするシステム１００を示す。このソースビデオ１２１は、コンテンツパートナー（例えば、Hallmark Channelは、放送前のエピソードに対するソースビデオ１２１を提供することができる）、配信パートナー（例えば、Comcast）、インターネットからのダウンロード（例えば、YouTube（登録商標）から）、またはライブビデオ供給からの取り込み（例えば、NBAゲームの供給のライブ取り込み）によって提供することができる。システム１００は、ハッシュデータベース１４０およびアプリケーションプログラミングインターフェース（ＡＰＩ）サーバ１３０に通信可能に結合されたメタデータデータベース１５０を含み、これは再生装置１１０にも通信可能に結合されている。例えば、再生装置１１０、コンテンツプロバイダ１２０、ＡＰＩサーバ１３０、ハッシュデータベース１４０、およびメタデータデータベース１５０は、同一または異なる地理的位置にあり、同一または異なる当事者によって操作され、インターネットまたは１つ以上の他の適切な通信ネットワークを介して互いに通信することができる。

（コンテンツソースに応じて、システム１００は、図１～４に示すものに加えて、いくつかのステップを実行しうる。例えば、セットトップボックスの場合、コンテンツは、コンテンツプロバイダ１２０（例えば、ディズニー）から、再生装置でコンテンツを再生するケーブル会社（例えば、Comcast）に配信されてもよい。）

図２～４は、ハッシュデータベース１４０およびメタデータデータベース１５０から情報を取り込みおよび検索するためのプロセスを示す。図２は、ハッシュ値ベクトル、ハッシュ値、またはハッシュとも呼ばれるハッシュベクトル１４５が、ハッシュデータベース１４０にどのように入力される（populate）かを示す。まず、ソースビデオ１２１が複数の個々のフレーム１２３ａ～１２３ｃ（総称して、フレーム１２３）に分割される（ブロック２０２）。この分割は、一定のフレームレート（例えば、１２フレーム／秒（fps））で行うことができ、またはビデオのコンテンツがフレーム間でどれほど大きく変化しているかを示す指標（metric）によって誘導することができ、ビデオのコンテンツが閾値を超えて変化するたびに分割が行われるが、これはハッシュマッチ閾値（hash-matching threshold）に基づくことができ、または所望のレベルのハッシュマッチ精度（hash-matching accuracy）に基づいて実験的に選択することができる。これにより、データベースに保存するハッシュの数が減少する。各ソースフレーム１２３の複数のバージョン１２５は、アスペクト比（例えば、１６×９の代わりに２１×９または４×３）、色値、または他のパラメータに対して行われた修正を用いて、ソースビデオ１２１が、ブロードキャストトランスコーディングシステム（broadcast transcoding system）などを経た後に再生装置１１０上に表示されうる様々な方法を複製することを目的として、生成することができる（ブロック２０４）。

各ソースフレーム１２３の各バージョン１２５は、ハッシュ生成プロセッサ（hash generation processor）１４２によりパーセプチュアルハッシングプロセスを通して実行される（ブロック２０６）。このハッシュ生成プロセッサ１３０は、各フレームバージョン１２５を対応するパーセプチュアル（perceputually：知覚的に）に有意義なハッシュベクトル１４５に変換する。ハッシュ生成プロセッサ１４２は、パーセプションハッシング（ｐＨａｓｈ）、差分ハッシング（ｄＨａｓｈ）、平均ハッシング（ａＨａｓｈ）、またはウェーブレットハッシング（ｗＨａｓｈ）などの１つ以上のパーセプチュアルハッシュプロセスを使用して、ハッシュベクトル１４５を生成することができる。ハッシュベクトル１４５は、固定サイズバイナリベクトル（Ｎ×１ベクトルで、ベクトルの各要素が１または０のいずれかを含む）または浮動小数点ベクトルとすることができる。ハッシュベクトル１４５は、１２８ビット、２５６ビット、５１２ビット、１０２４ビット、２０４８ビット、４０９６ビット、またはそれより大きいものを含むがこれらに限定されない、様々なサイズのいずれかとすることができる。同じソースフレーム１２３の異なるバージョン１２５に対するハッシュベクトル１４５は、それらの視覚的類似性に応じて、互いに近接または離れているものとすることができる。例えば、色がわずかに異なるバージョン１２５は、互いにマッチするのに十分近いハッシュベクトル１４５を有することができるのに対し、異なるアスペクト比（例えば、４：３対１６：９）を有するバージョン１２５は、互いに非常に離れているため互いにマッチしないハッシュベクトル１４５を有することができる。

パーセプチュアルハッシュプロセスおよびハッシュベクトル１４５のサイズを選択するための考慮事項には、以下が含まれる。
（１）どれほど迅速に、ハッシュを、再生装置１１０の安価なハードウェア（例えば、スマートテレビまたはセットトップボックス（ＳＴＢ）中のプロセッサ）上で計算できるか（ハッシュベクトルを計算する目標時間の例は、１００ミリ秒以下）。
（２）ハッシュベクトル１４５のサイズ。より小さいハッシュベクトル１４５は、再生装置１１０、ＡＰＩサーバ１２０、およびハッシュデータベース１４０間の帯域幅消費の低減、ハッシュデータベース１４０のメモリ要件の低減、および検索時間の短縮を可能にする。１６×１６のサイズのｄＨａｓｈは、５１２ビット出力を有する。より大きなハッシュベクトル１４５は、より正確なマッチを可能にするが、より多くの帯域幅を消費し、より長い検索時間を有する。
（３）衝突の可能性（２つの異なる画像が同じハッシュベクトルを生成する可能性）。ハッシュベクトルの計算速度およびサイズは、２つの、類似しているが異なる入力に対して正確に異なるハッシュを生成するハッシングプロセス（hashing process）の能力と比較検討するべきである。例えば、（１６×１６とは対照的に）３２×３２のサイズでｄＨａｓｈを実行すると、２０４８ビットのサイズのハッシュベクトルがもたらされ、メモリ記憶空間を４倍にするコストで、フレーム間のより正確な識別（すなわち、より高い精度）が可能となる。使用ケースによっては、これは価値のあるトレードオフである場合があるが、他の使用ケースではそうでない場合がある。

ハッシュベクトル１４５は、ハッシュデータベース１４０に保存され（ブロック２０８）、これは、ハッシュベクトル１４５の近似最近傍探索（approximate nearest-neighbor search）を、迅速（例えば、＜１００ミリ秒）かつ高スループット（例えば、毎秒数千回の検索）で可能にするように構成されている。図１は、このハッシュデータベース１４０を単一の実体として表しているが、実際には、ハッシュデータベース１４０は複数のシャードを含むことができ、その各々が、ハッシュベクトル１４５のサブセットを含有する。ハッシュベクトル１４５は、シャードにわたってランダムに分配することができ、または特定のスキームに従って意図的に分配することができる。例えば、ハッシュデータベース１４０は、類似の（距離が近い）ベクトル１４５を同じシャード上に保存することができる。または、ハッシュデータベース１４０は、最も頻繁に、または最も最近にアクセスされたベクトル１４５を同じシャード上に保存することができる。または、ハッシュデータベース１４０は、ハッシュの特徴を使用して、それをどのシャード上に置くかを決定することができる（例えば、局所性鋭敏型ハッシング（Locality Sensitive Hashing）、またはハッシュのサブセット上で訓練されるニューラルネットワークなどの学習プロセスを使用する）。

シャーディング（sharding）は、ベクトル１４５の各サブセットを同時に検索して結果を集計することを可能にし、多くのハッシュベクトル１４５が検索されているときでさえも、検索時間を低く保つ。シャードは、例えば、アクセス頻度別にシャードが整理されている場合に、最も頻繁にアクセスされるベクトル１４５を保存しているシャードが最初に検索され、次に、２番目に頻繁にアクセスされるベクトル１４５を保存しているシャードが２番目に検索されるなど、マッチが見つかるまで順次検索されることもできる。加えて、所与のビデオからの１つ以上のハッシュに対する検索ボリュームが増加した場合には、そのビデオの残りのハッシュに対するより多くの検索を予想して、そのビデオに対するハッシュのすべてが第１のシャードに同時に昇格することができるという点で、所与のビデオからの全てのハッシュは、このスキームまたはその他のスキームにおいてグループとして扱うことができる。（検証では、市販のハードウェアおよびソフトウェアを使用して、各データベースのシャードが少なくとも数億のハッシュベクトル１４５を処理でき、総システム１００が数十億のハッシュベクトル１４５を処理できることが示されている。）このシステム１００がライブイベント（すなわち、ライブのバスケットボールの試合）に使用された場合、新しいハッシュ１４５をデータベース１４０に挿入する時間から、そのハッシュベクトル１４５がインデックス化され検索に利用可能となるまでの時間は、短い（例えば、５秒未満）はずである。

各ハッシュベクトル１４５は、ハッシュデータベース１４０中で、対応するソースビデオ１０１を識別する情報ならびに対応するフレーム１２３／１２５のタイムスタンプおよび／またはフレーム番号／識別子に関連付けられている。一部の場合、同じソースフレーム１２３の異なるバージョン１２５は、コンテンツまたは長さの編集のために異なる絶対タイムスタンプを有することができる。これらの場合、各ハッシュベクトル１４５はまた、関連するフレームバージョン１２５のタイムスタンプとソースビデオ１０１の対応するフレーム１２３のタイムスタンプとの間の差を示す、タイムスタンプオフセットと関連付けることができる。ハッシュデータベース１４０は、メタデータデータベース１５０に問い合わせるためのハッシュベクトルの問い合わせに応答して、タイムスタンプ、タイムスタンプオフセット、およびソースビデオ情報を返すことができる。

図３は、ソースビデオ１２１に対するメタデータがどのように生成されるかを示す。ソースビデオ１２１は、メタデータ生成およびタグ付けのために、フレーム１２７ａ～１２７ｃ（総称して、フレーム１２７）の別のセットに分割される（ブロック３０２）。フレームレートは、パーセプチュアルハッシングに対してよりもメタデータ生成に対して低くすることができるため、メタデータ生成のためのフレーム１２７のセットは、ハッシングのためのフレーム１２３のセットよりも小さくすることができる。メタデータ生成のためのフレーム１２７間の分割は、ソースビデオ１２１に対する関連するメタデータ（例えば、画面上の俳優／キャラクターに関する情報、撮影場所、画面上のキャラクターが着用する衣服、および／または類似のもの）を生成するために選択される一方、パーセプチュアルハッシングのためのフレーム１２３間の分割は、自動コンテンツ認識（ＡＣＲ：automatic content recognition）を実行してソースビデオを識別するために選択される。例えば、被写体ブレ（motion blur）が大きいフレームは、被写体ブレが画面上に現れるアイテムの識別を困難または不可能にするほど十分深刻である場合、メタデータ生成のためには有効ではない場合があり、メタデータ生成から除外することができるが、視覚的に一意な画像（unique image）であるため、ＡＣＲのためには依然として有用とすることができる。分割は、異なる基準（criteria）に従って異なる選択をするため、メタデータ生成のために選択されるフレーム１２７は、ハッシュベクトル１２５を生成するために使用されるフレーム１２３とは直接にはマッチ、または整列（align）しない場合がある。結果として、同じソースビデオ１２１が、異なる数のフレーム１２３、１２７および／または異なるタイムスタンプを有するフレーム１２３、１２７を、ハッシュ生成（hash generation）およびメタデータ生成のために生じることができる。

メタデータ生成プロセッサ１５２は、メタデータ生成のために選択されたフレーム１２７上で動作し、対応するフレーム１２７のタイムスタンプまたは他の識別子と関連付けられたメタデータを、メタデータデータベース１５０に保存する（ブロック３０４および３０６）。メタデータ生成は、例えば、「Machine-Based Object Recognition of Video Content」と題する米国特許出願公開第２０２０／０１３４３２０ Ａ１号（これは引用することによりその全体が本明細書の一部をなすものとする）に開示されている技術を使用して、ユーザによって、または任意選択的なユーザの介在を伴って、自動的に達成されうる。自動化されたフレームの取り込み（ingestion）およびメタデータ生成により、メタデータをわずか数秒（例えば、５秒以下）で検索に利用できるようになり、本プロセスが、スポーツ、パフォーマンス、およびニュースなどのライブビデオのタグ付けおよび検索に適したものになる。メタデータプロセッサ１５２によって生成されうるメタデータの例には、画面上にどの俳優／キャラクターがいるか、どの衣服アイテムがそれらの俳優／キャラクターによって着用されているか、または画面上に描写された撮影場所についての情報を含むことができる。このメタデータ生成は、独立して、または図２に示されるフレームハッシング（frame hashing）と共同して行うことができる。

必要に応じて、ソースビデオ１０１のメタデータの一部またはすべては、メタデータデータベースが入力された後に更新することができる。例えば、ソースビデオ１０１にタグ付けされた製品が販売されている場合、もはや入手可能でない場合、または別のベンダーから入手可能である場合、メタデータデータベース１４０中の対応する入力を更新して、変更を反映させることができる。メタデータデータベース１４０の入力を更新して、他のベンダーから入手可能な類似の製品への参照を含めることもできる。これらの更新は、ハッシュデータベース１４０の入力のいずれも変更することなく実施することができる。そして、メタデータデータベース１５０中の入力が、フレーム１２７のタイムスタンプまたは他の識別情報を含む限り、それらはハッシュデータベース１４０中の対応するハッシュにマッチさせることができる。

一部の場合、メタデータデータベース１５０は、ソースビデオ１０１のみに連動または関連付けられ、ソースビデオの異なるバージョンには連動または関連付けられていないメタデータを保存する。このメタデータは、上述のタイムスタンプおよびタイムスタンプオフセットを使用して、ビデオの異なるバージョンに対して検索することができる。他の場合、メタデータデータベース１５０は、ソースビデオ１０１の異なるバージョン（例えば、劇場用リリースおよびテレビ用に編集された短いバージョン）に連動または関連付けられたメタデータを保存する。これらの場合、メタデータデータベースの問い合わせは、ソースビデオ１０１の対応するバージョンと関連付けられたメタデータを識別して返すことができる。

図４は、再生装置１１０およびＡＰＩサーバ１３０がどのようにハッシュデータベース１４０およびメタデータデータベース１５０に問い合わせを行うかを示す。再生装置１１０（例えば、スマートテレビ、セットトップボックス、または他のインターネット接続ディスプレイ）は、ソースビデオ１２１の潜在的に修正されたバージョンを視聴者に表示する。この変更されたバージョンは、編集（例えば、コンテンツまたは長さについて）、またはフォーマットを変更（例えば、レターボックスまたはトリミング（cropped）して再生することができる。また、コマーシャルおよびその他の休憩を含んでもよい。

視聴者がソースビデオの変更されたバージョンを見ると、ビデオ再生装置は、その画面上に表示されている画像をキャプチャ（capture）し、ハッシュデータベース１４０に保存されたハッシュベクトル１４５を生成するために使用されるのと同じパーセプチュアルハッシングプロセス（例えば、ｐＨａｓｈ、ｄＨａｓｈ、ａＨａｓｈ、またはｗＨａｓｈ）を使用して、その画像からハッシュベクトル１１５を生成する（ブロック４０４）。再生装置１１０は、例えば、１００ミリ秒以下など、待ち時間をできるだけ低く維持するために、ハッシュベクトル１１５を迅速に生成する。

再生装置１１０は、リモコン上のボタンを押すか、またはリモコンもしくは他のデバイス上のマイクに話しかけることによってなされる視聴者の要求またはコマンドに応答して、画像をキャプチャおよびハッシュすることができる。再生装置１１０はまた、または別の方法として、一定の間隔で（例えば、Ｎフレームごとまたは１～３００秒ごとに１フレーム）フレームをキャプチャしてハッシュし、最も最近に導出されたハッシュベクトル１１５を使用して、視聴者の要求に応答して検索を実行することができる。（再生装置１１０が、コマーシャルまたは他のプログラムの中断を感知できる場合、処理負荷および／または帯域幅の消費を低減するために、コマーシャル中はハッシュベクトル１１５の生成を停止することができる。）または、再生装置１１０は、代わりに、自動的に生成されたハッシュ１１５を使用して、バックグラウンドで検索を自動的に実行し、その後の視聴者の要求に応答してその検索結果を表示することができる。再生装置１１０はまた、自動的に検索された結果を使用して、現在表示されているビデオに対してメタデータが利用可能であることを画面上に通知することにより、視聴者に促すことができる。

再生装置１１０は、これらのハッシュベクトル１１５のうちの１つ以上、ならびに任意選択的に、画像中の人、アイテム、および／または場所を識別するために、フレームタイムスタンプおよびビデオコンテンツを識別する情報をＡＰＩサーバ１３０に送信する（ブロック４０６）。再生装置１１０は、各ハッシュベクトル１１５をＡＰＩサーバ１３０に送信することができ、またはハッシュベクトル１１５のサブセットのみをＡＰＩサーバ１３０に送信することができる。例えば、再生装置１１０が定期的にハッシュベクトル１１５を計算する場合、各ハッシュベクトル１１５をＡＰＩサーバ１３０に送信することができる。これはより多くの帯域幅を消費するが、ＡＰＩサーバ１３０からの情報の要求を送信し、視聴者からのコマンドを待たずにそれらの要求に対する応答を受信することによって、待ち時間を低減する可能性がある。結果として、再生装置１１０は、再生装置によって表示される人物、オブジェクト、または場所に関する情報についての視聴者の要求に対する応答を、データベースの問い合わせを待たずに表示することができるが、これは、それらの問い合わせがすでに実行されているためである。

別の方法として、または追加的に、再生装置１１０は、ハッシュベクトル１１５が定期的に生成されたか、または視聴者からのコマンドに応答して生成されたかに関わらず、視聴者からのコマンドに応答して、ハッシュベクトル１１５をＡＰＩサーバ１３０に送信することができる。これは、より少ない帯域幅を消費し、データベースの問い合わせの数を減少させることによって、ＡＰＩサーバ１３０、ハッシュデータベース１４０、およびメタデータデータベース１５０の処理負荷を低減する。しかし、視聴者が情報を要求するまでＡＰＩサーバ１３０を問い合わせることを待つことによって、待ち時間が増大する可能性がある。

一部の場合、再生装置１１０のコンテンツによって示されるソースビデオ１２１のアイデンティティ（identity：同一性）は、すでに既知であるとすることができ（例えば、スマートテレビまたはセットトップボックスは、テレビ上に示されるプログラムのアイデンティティを知っていてもよい）、システム１００は、ソースビデオ１２１の対応するフレームの正確なタイムスタンプを識別するためにのみ使用されてもよい。これらの場合、再生装置１１０は、ハッシュ値１１５に加えてコンテンツの識別子を送信することができる。例えば、コンテンツ識別子は、補助的ＡＣＲシステム（例えば、Gracenote）によって生成することができ、またはセットトップボックスを使用して電子プログラミングガイド（ＥＰＧ：electronic programming guide）情報から引き出することができる。次いで、コンテンツ識別子を使用して、指定されたコンテンツに基づいて、探索空間を制限する、またはハッシュデータベース１４０からの偽陽性マッチ（false-positive match）を取り除くことができる。

ＡＰＩサーバ１３０が、再生装置１１０からハッシュベクトル１１５を受信すると、ＡＰＩサーバ１３０は、ハッシュデータベース１４０に、マッチする保存されたハッシュベクトル１４５（ブロック４０８）を問い合わせる。ハッシングは１方向であるため、ハッシュが生成された正確なソース値（ビデオフレーム）を決定することは不可能でありうる。しかしながら、ハッシュ値１１５および１４５はパーセプチュアルハッシング（例えば、ｄＨａｓｈ）を使用して生成されているため、類似のソース画像のハッシングは類似のハッシュ値をもたらすため、ハッシュ値間の位置関係／距離には意味がある。これは、入力のわずかな摂動（perturbation）でさえも、劇的に異なるハッシュ値を生成するように設計されている、ＳＨＡまたはＭＤ５などの標準的な暗号化ハッシュアルゴリズム（hash algorithm）とは対照的である。

検索が、予め定義された厳しい閾値距離内の類似のハッシュベクトル１４５をもたらした（ブロック４１０）場合、ハッシュデータベース１４０は、マッチするフレームのタイムスタンプをＡＰＩサーバ１３０に返す。距離の閾値は、実験データおよび所与の使用事例に対する許容可能な偽陽性率（false positive rate）に基づいて決定することができる（より高い閾値は、より高い真陽性率を与える傾向があるが、高い偽陽性率も与える傾向がある）。例えば、システム１００は、異なる閾値を使用して検査および調整されて、既知のグラウンドトゥルースタイムスタンプ（ground-truth timestamp）を返すことができる。ハッシュベクトル間の距離は、例えば、Ｌ２（ユークリッド）距離またはハミング距離（ベクトルがバイナリである場合）などの様々な距離判定基準（distance metric）のうちの１つを使用して計算されうる。別の方法として、コサイン類似性または交差相関などの類似性の他の概念を使用して、ハッシュを比較することができる。加えて、閾値は、異なるビデオに対して、またはハッシュデータベースの異なるシャードに対して、異なる方法で設定することができる。

厳しい閾値距離（strict threshold distance）内にマッチが見つからない場合、厳しさの低い（より緩い）閾値を使用することができ（ブロック４１２）、偽陽性の精度を維持するためにコンセンサス法が用いられる。例えば、より緩い閾値を用いた３つの最も近いマッチが、すべて同じソースビデオ１０１からのものであり、互いに数秒以内のタイムスタンプを有する場合、これは、厳しい閾値の範囲外であったとしても最も近いマッチが正しいという、より大きな確信を提供する。しかし、３つの最も近いマッチが、異なるソースビデオ１０１からのものである場合、および／または数秒を超えて離れたタイムスタンプを有する場合、マッチがないと推測する方が安全とすることができる。マッチが見つからない場合、ＡＰＩサーバ１３０は、ヌルの結果を再生装置１１０に返す（ブロック４２０）。

ハッシュデータベース１４０中にマッチするハッシュがある場合、ハッシュデータベースの問い合わせは、マッチするハッシュについて、ソースビデオ１０１に関するタイムスタンプおよび関連情報をＡＰＩサーバ１３０に返す（ブロック４１４）。ＡＰＩサーバ１３０は、このタイムスタンプを再生装置１１０に送信し、および／またはこのタイムスタンプおよび関連するソースビデオ情報を使用して、メタデータデータベース１５０に、マッチするフレームのメタデータを問い合わせることができる（ブロック４１６）。メタデータデータベース１５０は、要求されたメタデータをＡＰＩサーバ１３０に返し、これは次に、要求されたメタデータを再生装置１１０に送信して、視聴者に表示する（ブロック４１８）。再生装置１１０は、要求された情報を、ビデオ上に現れるかまたはビデオと一体化するオーバーレイ（overlay）で視聴者に表示する。表示された情報は、再生装置１１０または、スマートフォンもしくはタブレットなどの別の装置を介して、視聴者が製品を購入することを可能にするリンクまたは他の情報を含むことができる。視聴者へのメタデータの表示に関する詳細は、例えば、「Dynamic Media-Product Searching Platform Apparatuses, Methods and Systems」と題する米国特許第＿＿＿＿＿号（米国特許出願第１４／５２７，８５４号から発行され、これはその全体が引用することにより本明細書の一部をなすものとする）を参照されたい。

結論
発明に関するさまざまな実施形態を本明細書に記述し、かつ例示してきたが、当業者は、本明細書に記載の機能を実施するための、ならびに／または結果および／もしくは１つ以上の利点を得るための、さまざまな他の手段および／または構造を容易に想定し、またこうした変形および／または修正のそれぞれは、本明細書に記載の発明に関する実施形態の範囲内であるものと見なされる。より一般的に、当業者は、本明細書に記載のすべてのパラメータ、寸法、材料、および構成が例示であることを意味することと、実際のパラメータ、寸法、材料、および／または構成が、本発明の教示が使用される特定の用途（複数可）に依存することとを容易に理解するであろう。当業者は、本明細書に記載の特定の発明に関する実施形態の多くの同等物を、単に通常の実験を用いて認識し、または確認することができるであろう。従って、前述の実施形態は、例としてのみ提示されていて、添付の特許請求の範囲およびその均等物の範囲内で、発明に関する実施形態は、具体的に記述および特許請求される以外の形で実践されうることが理解される。本開示の発明に関する実施形態は、本明細書に記載の各個々の特徴、システム、物品、材料、キット、および／または方法を対象とする。加えて、２つ以上のこうした特徴、システム、物品、材料、キット、および／または方法の任意の組み合わせは、こうした特徴、システム、物品、材料、キット、および／または方法が相互に矛盾しない場合、本開示の発明の範囲内に含まれる。

また、さまざまな発明に関する概念が、１つ以上の方法として具現化することができ、その例を提供してきた。方法の一部として行われる行為は、任意の好適なやり方で順序付けることができる。その結果、行為が例示するものとは異なる順序で実施される実施形態を構築することができ、それは、例示的な実施形態に連続する行為として示されている場合であってさえも、一部の行為を同時に実施することを含むことができる。

本明細書で定義および使用されるすべての定義は、辞書による定義、引用することにより本明細書の一部をなすものとする文書中の定義、および／または定義された用語の通常の意味を統制するものと理解されるべきである。

本明細書および特許請求の範囲で使用する不定冠詞「１つの（「a」および「an」）」は、明確にそうでないと示されない限り、「少なくとも１つ」を意味すると理解されるべきである。

本明細書および特許請求の範囲で使用する「および／または」という語句は、結合された要素の「いずれかまたは両方」を意味し、すなわち一部の場合において接続的に存在し、他の場合において離接的に存在する要素を意味すると理解されるべきである。「および／または」で挙げられる複数の要素は、同じ様式、すなわち等位接続される要素のうちの「１つ以上」と解釈されるべきである。具体的に識別される要素に関連するかまたは関連しないかにかかわらず、「および／または」節によって具体的に識別される要素以外に、他の要素が随意に存在し得る。それゆえに、非限定的な例として、「Ａおよび／またはＢ」への言及は、「含む」などの制限のない語法と連動して使われるときに、一実施形態においてＡのみ（任意選択的にＢ以外の要素を含む）、別の実施形態においてＢのみ（任意選択的にＡ以外の要素を含む）、さらに別の実施形態においてＡとＢの両方（任意選択的に他の要素を含む）などを指すことができる。

本明細書および特許請求の範囲において使用する場合、「または」は、上で定義した「および／または」と同じ意味を有すると理解されるべきである。例えば、リスト内の項目を分離するとき、「または」または「および／または」は包括的なもの、すなわち多数の要素または要素のリスト、および任意選択的にリストに無い追加の項目のうちの少なくとも１つを含むが、２つ以上も含むと解釈されるものとする。それとは反対であると明確に指示される用語、例えば「のうちの１つのみ」もしくは「のうちのまさに１つ」、または特許請求の範囲において使用する時の「から成る」などの用語のみが、多数のまたは列挙された要素のうちのまさに１つの要素を包含することを指すことになる。一般に、本明細書で使用する場合、「または」という用語は、「いずれか」、「のうちの１つ」、「のうちの１つのみ」、または「のうちのまさに１つ」など、排他的な用語が先行する時に、排他的な選択肢（すなわち「両方ではなく一方または他方」）を示すとのみ解釈されるものとする。「から本質的に成る」は、特許請求の範囲で使用する場合、特許法の分野において使用される通常の意味を有するものとする。

本明細書および特許請求の範囲で使用する場合、１つ以上の要素のリストに関連する「少なくとも１つ」という語句は、要素のリストの中の要素のいずれか１つ以上から選択される、少なくとも１つの要素を意味するが、要素のリスト内で具体的に列挙したありとあらゆる要素のうちの、少なくとも１つを必ずしも含むわけではなく、要素のリストのいかなる要素の組み合せも除外するものではないと理解されるべきである。またこの定義によって、「少なくとも１つ」という語句が指す、要素のリスト内で具体的に識別される以外の要素が、具体的に識別される要素に関連するかまたは関連しないかにかかわらず、任意選択的に存在しうることも許容される。それゆえに、非限定的な例として、「ＡおよびＢのうちの少なくとも１つ」（または等価的に「ＡまたはＢのうちの少なくとも１つ」、もしくは等価的に「Ａおよび／またはＢのうちの少なくとも１つ」）は、一実施形態においてＢは存在せず、任意選択的に２つ以上のＡを含む、少なくとも１つのＡ（任意選択的にＢ以外の要素を含む）、別の実施形態においてＡは存在せず、任意選択的に２つ以上のＢを含む、少なくとも１つのＢ（任意選択的にＡ以外の要素を含む）、また別の実施形態において任意選択的に２つ以上のＡを含む、少なくとも１つのＡ、および任意選択的に２つ以上のＢを含む、少なくとも１つのＢ（任意選択的に他の要素を含む）を指すことなどができる。

特許請求の範囲、ならびに上記の明細書において、すべての移行句、例えば「含む（comprising）」、「含む（including）」、「持つ（carrying）」、「有する（having）」、「包含する（containing）」、「伴う（involving）」、「保つ（holding）」、「から構成される（composed of）」、およびこれに類するものは制限がないと理解され、すなわち含むがそれに限定はされないということを意味する。「から成る（consisting of）」および「から本質的に成る（consisting essentially of）」という移行句のみが、米国特許局の特許審査手続便覧、セクション２１１１．０３に規定の通り、それぞれ閉鎖的または半閉鎖的な移行句であるものとする。

Claims (38)

1. ソースビデオのフレームを識別する方法であって、
   前記ソースビデオの異なるバージョンのそれぞれのフレームに対してハッシュベクトルを生成することと、
   前記ハッシュベクトルを、データベース中の前記ソースビデオに関する情報と関連付けることと、
   再生装置上で前記ソースビデオの第１のバージョンを再生することと、
   前記ソースビデオの前記第１のバージョンの第１のフレームに対して第１のハッシュベクトルを生成することと、
   前記第１のハッシュベクトルを、前記データベース中の前記ハッシュベクトルの中のマッチするハッシュベクトルにマッチさせることと、
   前記第１のハッシュベクトルを前記マッチするハッシュベクトルにマッチさせることに応答して、前記ソースビデオに関する情報を前記データベースから検索することと
   を含む方法。
2. 前記再生装置が、テレビ、セットトップボックス、コンピュータ、またはモバイルデバイスのうちの少なくとも１つを含む、請求項１に記載の方法。
3. 前記第１のハッシュベクトルが前記マッチするハッシュベクトルにマッチすると判定することが、前記第１のハッシュベクトルが、前記マッチするハッシュベクトルの閾値距離内にあると判定することを含む、請求項１に記載の方法。
4. 前記マッチするハッシュベクトルが、前記ソースビデオの前記第１のバージョンとは異なる前記ソースビデオの第２のバージョンのフレームに対するものである、請求項１に記載の方法。
5. 前記ハッシュベクトルおよび前記第１のハッシュベクトルが、パーセプチュアルハッシングプロセスを用いて生成される、請求項１に記載の方法。
6. 前記パーセプチュアルハッシングプロセスが、パーセプションハッシング（ｐＨａｓｈ）、差分ハッシング（ｄＨａｓｈ）、平均ハッシング（ａＨａｓｈ）、およびウェーブレットハッシング（ｗＨａｓｈ）から成る群の１要素である、請求項５に記載の方法。
7. 前記第１のハッシュベクトルを生成することが、約１００ミリ秒以内に起こる、請求項６に記載の方法。
8. 前記第１のハッシュベクトルが、４０９６ビット以下のサイズを有する、請求項６に記載の方法。
9. 前記ハッシュベクトルがどの程度の頻度でアクセスされたか、または前記ハッシュベクトルがどの程度最近にアクセスされたかのうちの少なくとも１つに基づいて、前記ハッシュベクトルをサブセットに分離することと、
   各サブセットを前記データベースの異なるシャードに保存することと
   をさらに含む請求項１に記載の方法。
10. 前記ハッシュベクトル間の距離に基づいて、前記ハッシュベクトルをサブセットに分離することと、
    各サブセットを前記データベースの異なるシャードに保存することと
    をさらに含む請求項１に記載の方法。
11. 前記ハッシュベクトルの特徴に基づいて、前記ハッシュベクトルをサブセットに分離することと、
    各サブセットを前記データベースの異なるシャードに保存することと
    をさらに含む請求項１に記載の方法。
12. 前記ハッシュベクトルをランダムにサブセットに分離することと、
    各サブセットを前記データベースの異なるシャードに保存することと
    をさらに含む請求項１に記載の方法。
13. 前記第１のハッシュベクトルを生成することは、一定の間隔で自動的に起こる、請求項１に記載の方法。
14. 前記第１のハッシュベクトルを生成することは、視聴者からのコマンドに応答して起こる、請求項１に記載の方法。
15. ソースビデオの異なるバージョンのそれぞれのフレームに対するハッシュベクトルを保存するデータベースであって、前記ハッシュベクトルは前記ソースビデオに関する情報と前記データベース中で関連付けられているものである、データベースと、
    再生装置上で再生された前記ソースビデオの第１のバージョンの第１のフレームに対する第１のハッシュベクトルを有する前記データベースに問い合わせるため、および前記ソースビデオに関する情報を、前記第１のハッシュベクトルと前記データベース中の前記ハッシュベクトルの中のマッチするハッシュベクトルとのマッチに応答して返すために、前記データベースに通信可能に結合されたアプリケーションプログラミングインターフェース（ＡＰＩ）と
    を備えるシステム。
16. ソースビデオに関連付けられたメタデータを識別および取得する方法であって、
    前記ソースビデオの少なくとも１つのバージョンのそれぞれのフレームに対してハッシュベクトルを生成することと、
    前記ハッシュベクトルを第１のデータベースに保存することと、
    前記それぞれのフレームに対応するメタデータを第２のデータベースに保存することと、
    再生装置上で前記ソースビデオの第１のバージョンを再生することと、
    前記ソースビデオの前記第１のバージョンの第１のフレームに対して第１のハッシュベクトルを生成することと、
    前記第１のハッシュベクトルを、前記第１のデータベース中の前記ハッシュベクトルの中のマッチするハッシュベクトルにマッチさせることと、
    前記第１のハッシュベクトルを前記マッチするハッシュベクトルにマッチさせることに応答して、前記第２のデータベースから前記マッチするハッシュベクトルに対応する前記メタデータを検索することと、
    前記再生装置を介して前記メタデータを前記視聴者に表示することと
    を含む方法。
17. 前記再生装置が、テレビ、セットトップボックス、コンピュータ、またはモバイルデバイスのうちの少なくとも１つを含む、請求項１６に記載の方法。
18. 前記メタデータが、前記ソースビデオ中の場所、前記ソースビデオ中の俳優が着用する衣服、前記ソースビデオ中に現れる製品、または前記ソースビデオを再生する音楽のうちの少なくとも１つを表す、請求項１６に記載の方法。
19. 前記ハッシュベクトルは、それぞれのタイムスタンプによって前記メタデータと関連付けられている、請求項１６に記載の方法。
20. 前記第１のハッシュベクトルを前記マッチするハッシュベクトルにマッチさせることが、
    前記第１のハッシュベクトルをアプリケーションプログラミングインターフェース（ＡＰＩ）サーバに送信することと、
    前記ＡＰＩサーバを介して、前記第１のハッシュベクトルが、前記第１のデータベース中の前記ハッシュベクトルの中の前記マッチするハッシュベクトルにマッチすると判定することと、
    前記第１のハッシュベクトルを前記マッチするハッシュベクトルにマッチさせることに応答して、前記第１のデータベース中の前記マッチするハッシュベクトルに関連付けられた前記タイムスタンプを識別することと
    を含み、前記メタデータを検索することがさらに、
    前記タイムスタンプに基づいて、前記第２のデータベースに問い合わせることと、
    前記第２のデータベースから、前記タイムスタンプと関連付けられた前記メタデータを検索することと
    を含む、請求項１９に記載の方法。
21. 前記第１のハッシュベクトルが前記マッチするハッシュベクトルにマッチすると判定することは、前記第１のハッシュベクトルが、前記マッチするハッシュベクトルの閾値距離内にあると判定することを含む、請求項１６に記載の方法。
22. 前記マッチするハッシュベクトルは、前記ソースビデオの前記第１のバージョンとは異なる前記ソースビデオの第２のバージョンのフレームに対するものである、請求項１６に記載の方法。
23. 前記ハッシュベクトルおよび前記第１のハッシュベクトルは、パーセプチュアルハッシングプロセスを用いて生成されるものである、請求項１６に記載の方法。
24. 前記パーセプチュアルハッシングプロセスは、パーセプションハッシング（ｐＨａｓｈ）、差分ハッシング（ｄＨａｓｈ）、平均ハッシング（ａＨａｓｈ）、およびウェーブレットハッシング（ｗＨａｓｈ）から成る群の１要素である、請求項２３に記載の方法。
25. 前記第１のハッシュベクトルを生成することは、約１００ミリ秒以内に起こる、請求項２４に記載の方法。
26. 前記第１のハッシュベクトルは、４０９６ビット以下のサイズを有する、請求項２４に記載の方法。
27. 前記ハッシュベクトルを保存することは、
    前記ハッシュベクトルがどの程度の頻度でアクセスされたか、または前記ハッシュベクトルがどの程度最近にアクセスされたかのうちの少なくとも１つに基づいて、前記ハッシュベクトルをサブセットに分離することと、
    各サブセットを前記第１のデータベースの異なるシャードに保存することと
    を含む、請求項１６に記載の方法。
28. 前記ハッシュベクトルを保存することは、
    前記ハッシュベクトル間の距離に基づいて、前記ハッシュベクトルをサブセットに分離することと、
    各サブセットを前記第１のデータベースの異なるシャードに保存することと
    を含む、請求項１６に記載の方法。
29. 前記ハッシュベクトルを保存することは、
    前記ハッシュベクトルの特徴に基づいて、前記ハッシュベクトルをサブセットに分離することと、
    各サブセットを前記第１のデータベースの異なるシャードに保存することと
    を含む、請求項１６に記載の方法。
30. 前記ハッシュベクトルを保存することが、
    前記ハッシュベクトルをランダムに等しいサブセットに分離することと、
    各サブセットを前記第１のデータベースの異なるシャードに保存することと
    を含む、請求項１６に記載の方法。
31. 前記第１のデータベース中の前記ハッシュベクトルを変更せずに、前記メタデータを更新することをさらに含む、請求項１６に記載の方法。
32. 前記第１のハッシュベクトルを生成することは、一定の間隔で自動的に発生する、請求項１６に記載の方法。
33. 前記第１のハッシュベクトルを生成することは、視聴者からのコマンドに応答して起こる、請求項１６に記載の方法。
34. ソースビデオの異なるバージョンのそれぞれのフレームに対するハッシュベクトルを保存するための第１のデータベースであって、前記ハッシュベクトルは前記ソースビデオに関する情報と前記第１のデータベース中で関連付けられているものである、第１のデータベースと、
    前記ソースビデオに関するメタデータを保存するための第２のデータベースと、
    再生装置上で再生される前記ソースビデオの第１のバージョンの第１のフレームに対する第１のハッシュベクトルを有する前記第１のデータベースに問い合わせるため、および前記第１のハッシュベクトルと前記データベース中の前記ハッシュベクトルの中のマッチするハッシュベクトルとのマッチに応答して、前記第１のデータベースから返される前記ソースビデオに関する前記情報に基づいて、前記ソースビデオに関する前記メタデータの少なくとも一部について、前記第２のデータベースに問い合わせるための、前記第１のデータベースおよび前記第２のデータベースに通信可能に結合されたアプリケーションプログラミングインターフェース（ＡＰＩ）と
    を備えるシステム。
35. ビデオに関連付けられたメタデータを識別、取得、および表示する方法であって、
    前記ビデオを、ディスプレイを介して再生することと、
    前記ビデオの第１のフレームに対して第１のハッシュベクトルを生成することと、
    前記第１のハッシュベクトルをアプリケーションプログラミングインターフェース（ＡＰＩ）サーバに送信することと、
    前記ＡＰＩサーバを介して、前記第１のフレームと関連付けられた前記メタデータをメタデータデータベースから取得することであって、前記メタデータが、前記第１のハッシュベクトルを、ハッシュベクトルデータベースに保存された第２のハッシュベクトルにマッチさせることに応答して、前記第１のデータベースから検索されることと、
    前記ディスプレイを介して、前記第１のフレームと関連付けられた前記メタデータをユーザに表示することと
    を含む方法。
36. データベースで、ビデオの第１のフレームに対して生成された第１のハッシュベクトルを受信することと、
    前記第１のハッシュベクトルを前記データベースに保存することと、
    前記データベースで、再生装置から第２のハッシュベクトルに基づいた問い合わせを受信することと、
    前記第２のハッシュベクトルに対して前記データベースの前記問い合わせを実行することと、
    前記第２のハッシュベクトルを前記第１のハッシュベクトルにマッチさせることに応答して、前記第１のハッシュベクトルと関連付けられたタイムスタンプをアプリケーションプログラミングインターフェース（ＡＰＩ）サーバに送信することであって、前記タイムスタンプはメタデータを前記ビデオの前記第１のフレームと関連付けることと
    を含む方法。
37. ソースビデオの第１のフレームに対して第１のハッシュベクトルを生成することと、
    前記第１のハッシュベクトルを第１のデータベースに保存することと、
    再生装置上で前記ソースビデオの１つのバージョンを再生することと、
    前記ソースビデオの前記バージョンの第２のフレームに対して第２のハッシュベクトルを生成することと、
    前記第２のハッシュベクトルを前記第１のデータベース中の前記第１のハッシュベクトルにマッチさせることと
    を含む方法。
38. 前記第２のハッシュベクトルを前記第１のハッシュベクトルにマッチさせることに応答して、前記第２のハッシュベクトルに対応するタイムスタンプを検索することと、
    前記タイムスタンプを前記再生装置に送信することと
    を含む、請求項３７に記載の方法。
    

Images