JP2020523825A - 拡張メタデータを含むビデオコンテンツグラフ - Google Patents

Abstract

本技術は、隠しストリーム内など、ビデオの一部を記述するイベントのような、ビデオに関連するメタデータをクライアントデバイスに送ることを対象とする。１または複数の実装では、拡張メタデータは、関係グラフの一部を構築するために使用されるノードを含む。これにより、関心のあるクライアントは、特徴再生とメタデータとのインタラクションを切り替えることができる。さらに、一致するビデオ部分を見つけるために、拡張メタデータのサーチを実行することができ、１または複数のビデオのサマリまたはハイライトを、拡張メタデータにおける情報にアクセスすることによって組み立てることができる。

Description

関連出願への相互参照

[0001]この出願は、２０１７年５月３０日に出願された「ＶＩＤＥＯ ＣＯＮＴＥＮＴ ＧＲＡＰＨ ＩＮＣＬＵＤＩＮＧ ＥＮＨＡＮＣＥＤ ＭＥＴＡＤＡＴＡ」と題された米国特許出願第１５／６０８，５３０号に基づきその優先権を主張し、その全体が参照によりここに組み込まれる。

[0002]クライアントユーザは、クライアントユーザが所望の選択を行うことができるデータアイテムのメニュー（例えば、ボタン、タイル、アイコン、および／またはテキスト）などのユーザインタフェースを介して情報とインタラクト（ｉｎｔｅｒａｃｔ）することが多い。例えば、クライアントユーザは、映画またはテレビ番組などのコンテンツプロバイダによって提供されるビデオコンテンツを表すデータアイテムを含むスクロール可能なメニューを見て、視聴するための映画やテレビ番組を選択するメニューアイテムとインタラクトすることができる。

[0003]一般に、比較的基本的な情報のみがユーザに利用可能とされる。例えば、ビデオ選択関連の例では、映画のタイトルに加えて、映画の関連データは、視聴のためにコンテンツを選択するかどうかを決定する際にユーザが有することを望むであろう、レーティング（ｒａｔｉｎｇ）、映画を表す画像、プロットサマリ（ｐｌｏｔ ｓｕｍｍａｒｙ）、主要なキャスト（ｃａｓｔ）およびクルー（ｃｒｅｗ）情報などを含んでもよい（または含まなくてもよい）。

[0004]一部のユーザは、選択決定を行うためにだけでなく、より多くの情報を所望するかもしれない。例えば、ある特定の毎週のテレビシリーズの熱心なファンは、次のエピソードを選択して視聴する可能性が高いが、俳優のインタビュー、ストーリー、実際の撮影場所（ｆｉｌｍ ｌｏｃａｔｉｏｎｓ）に関する情報などの追加のコンテンツにさらに関心がある場合がある。しかし、現在のところ、そのようなユーザは、一般に、望むものが他の第三者のソースから利用可能であることを調べるために、別個にインターネットを閲覧する必要がある。

[0005]この概要は、以下の詳細な説明でさらに説明する代表的な概念の選択を簡略化した形で紹介するために提供される。この発明の概要は、請求される主題の重要なまたは本質的な特徴を特定することを意図したものではなく、請求される主題の範囲を限定するいかなる方法での使用も意図されていない。

[0006]簡単に言うと、ここで説明する技術の１または複数の態様は、ビデオの部分を拡張メタデータのサブセットと関連付けることを対象とし、拡張メタデータの各サブセットは、ビデオの対応する部分における少なくとも１つのアクションを記述する。態様は、ビデオをクライアントデバイスにストリーミングすることと、ビデオのどの部分がストリーミングされているかを決定することと、ストリーミングされているビデオの部分に対応する拡張メタデータの選択されたサブセットを選択することと、拡張メタデータの選択されたサブセットをクライアントデバイスにダウンロードすることとを含む。

[0007]他の利点は、図面と共に以下の詳細な説明から明らかになるであろう。

[0008]ここに記載の技術は、例として示され、添付の図面に限定されず、添付の図面において、同様の参照番号は同様の要素を示す。

[0009]図１は、１または複数の例示的な実装による、クライアントユーザがインタラクトすることができる、拡張メタデータノードを含むグラフノードに対応するデータを取得するためにデータサービスと通信するクライアントデバイスの例示的なブロック図である。 [0010]図２は、１または複数の例示的な実装による、拡張メタデータサブグラフを含むノードの例示的なクライアントグラフの一部を表現したものである。 [0011]図３は、１または複数の例示的な実装による、例示的な拡張メタデータノードを含む例示的なクライアントグラフの一部を表現したものである。 [0012]図４は、１または複数の例示的な実装による、拡張メタデータノード内で維持され得るいくつかの例示的な情報を表現したものである。 [0013]図５は、１または複数の例示的な実装による、拡張メタデータイベントノードおよびサブイベントノード内で維持され得るいくつかの例示的な情報を表現したものである。 [0014]図６は、１または複数の例示的な実装による、拡張メタデータを含む、ユーザが、選択のためのよりインタラクティブなデータを取得するために、グラフに基づいて要求を送るためにインタラクトすることができるユーザインタフェースの一例である。 [0015]図７は、１または複数の例示的な実装による、ストリーミングビデオの１または複数の部分が、どのようにそれに関連付けられた対応する記述的拡張メタデータを有することができるかの一例である。 [0016]図８は、１または複数の例示的な実装による、ビデオ（およびオーディオ）データに関連して、どのように拡張メタデータをクライアントデバイスにストリーミングすることができるかの例示的な表現である。 [0017]図９は、１または複数の例示的な実装による、ビデオおよび付随する拡張メタデータをストリーミングするためにデータサービスが行うことができる例示的なロジック（ｌｏｇｉｃ）／ステップを示すフロー図である。 [0018]図１０は、１または複数の例示的な実装による、拡張メタデータをキャッシュするためにクライアントデバイスプラットフォームまたは他のソフトウェアによって行われ得る例示的なロジック／ステップを示すフロー図である。 [0019]図１１は、ここで説明する主題の態様を組み込むことができる、１または複数の例示的な実装による、例示的なコンピューティング環境を表すブロック図である。

[0020]ここで説明する技術の様々な態様は、一般に、クライアントインタラクション（ｉｎｔｅｒａｃｔｉｏｎ）のための様々なデータをノードおよびエッジのグラフとして維持し、そのグラフを、ユーザにとって望ましい可能性が高い、何らかの形で、拡張メタデータで拡張することを対象とする。例えば、１つのビデオコンテンツ（例えば、映画またはテレビのエピソード（特徴と称されることもある）、ドキュメンタリ、ユーザがアップロードしたコンテンツなど）が視聴のために選択されると、そのコンテンツに対応する拡張インタラクティブな体験を提供するために、そのコンテンツに関連する拡張メタデータを、拡張メタデータノードセット（１または複数のノード）としてクライアントデバイスにダウンロードすることができる。より具体的な例として、ビデオコンテンツのある部分（例えば、一連のフレーム）の実際のビデオフレーム（例えば、ロマンチックなエピソード、戦闘（ｆｉｇｈｔ）など）に関連する記述情報は、ビデオに関連してクライアントデバイスにストリーミングされた１または複数の拡張メタデータノードを有することができ、１または複数のそのようなモードは、他の情報ノード、例えば、そのビデオの部分に現れる俳優のインタビュー、そのビデオの部分に関連する現実のまたは架空のマップ、カメラカットデータなどにリンクすることができる。これらの他の情報ノードは、さらに他のノードなどにリンクすることができる。したがって、ビデオは、それに対応するデータを、拡張されたインタラクティブなメタデータグラフノードセットとして維持することができ、ビデオの任意の部分は、通常、対応する関連する拡張メタデータグラフノードサブセットを有し、それは、関連するデータへの（ノードエッジを介した）リンクをさらに有することができる。

[0021]１または複数の態様では、例えば、選択されたビデオに付随する隠しストリームにおいて、メタデータをダウンロードすることによって、ビデオコンテンツに関連するような拡張された追加の量のデータが、クライアントユーザに利用可能にされる。そのような付随する拡張メタデータは、一般に、ビデオコンテンツに対応し、通常、コンテンツプロバイダによってサポートおよび管理される情報であるが、いくつかの情報は外部から提供されてもよい。隠された、一般にビデオストリームと並列のデータストリームは、ビデオが再生され得る前に、再生を遅延させ得る、大量となり得るデータをダウンロードしなければならないことを回避する。隠しストリーム（ｈｉｄｄｅｎ ｓｔｒｅａｍ）は、別個のストリームであってもよく、および／または付随するパケットヘッダデータなどは、受け取ったデータブロックがビデオ再生データであるか、または何らかの拡張メタデータであるかを指定することができる。

[0022]拡張メタデータの一例として、特徴の選択のために従来のメタデータ（例えば、タイトル、画像ＵＲＬ、レーティング、クレジットなど）のみを提供するのではなく、一旦特徴が選択されると、実際のビデオに加えて、キャラクタ（ｃｈａｒａｃｔｅｒｓ）、イベント、マップ、フォークロア（ｆｏｌｋｌｏｒｅ）、背景（ｂａｃｋｓｔｏｒｉｅｓ）などに関連するより複雑であり、場合によっては特徴のないメタデータもダウンロードすることができる。これにより、関心のあるクライアントは、より多くの情報を探索する（ｅｘｐｌｏｒｅ）ことができるとともに、ビデオを再生し、通常の再生モードでビデオ再生を視聴することと、メタデータとインタラクトすることとの間で切り替えることができる。例えば、特定のエピソードの視聴者は、再生を一時停止し、関連するシーンサイト（ｓｃｅｎｅ ｓｉｔｅｓ）のマップを見て、特定の俳優がいる現在のシーンにおける他の特徴を見るなどのためにインタラクトすることができる。あるいは、視聴者は、拡張コンテンツと同時に再生を視聴するために、拡張メタデータの可視表現を有する視聴画面の部分を（少なくとも一時的に）専用化および／またはオーバーレイ（ｏｖｅｒｌａｙ）してもよい。

[0023]さらに、コンテンツのある部分を選択することなく、および／または拡張メタデータの任意の並列（または事前）ダウンロードを行うことなく、視聴者は、データサービスの利用可能なコンテンツ全体のいくつかのサブセットに関連する拡張メタデータのためにデータサービスをサーチ（ｓｅａｒｃｈ）することができる。例えば、視聴者は、特定のシリーズを示し、そのシリーズのキャラクタＸが剣闘（ｓｗｏｒｄｆｉｇｈｔ）に参加するエピソード、シーン、カット、および／またはイベント（例えば、カット内の）をサーチすることができる。そのようなサーチを用いて、視聴者は、インタラクティブなリストを介して個々に選択可能な関連するビデオ部分、またはそれらのすべてを一緒に視聴する（またはそれらのいくつかのさらに狭いサブセットを視聴する）ための連続ビデオストリームにさらに直接的にコンパイルされた（ｃｏｍｐｉｌｅｄ）ビデオ部分などの、そのキャラクタの剣闘イベントのコンパイルを取得することができる。ここで使用されるように、ビデオコンテンツは、任意の方法を含む任意の数の方法で分割することができ、「チャプタ」、「シーン」、「カット」、「イベント」などのビデオコンテンツ分割を指す用語は、ここでは一般的な意味でのみ使用され、フィルム製造技術で時々使用されるような厳密な定義を正確に伝えることを意図しないことに留意されたい。

[0024]一実装例では、各イベント（またはいくつかのイベント）が、情報でタグ付けされた、またはイベントを記述する他の情報にリンクされた拡張メタデータノードを備えることによって、リッチサーチ（ｒｉｃｈ ｓｅａｒｃｈｅｓ）を達成することができる。ここで使用される「イベント」は、一般に、ビデオコンテンツの比較的細かいレベルの粒度であり、例えば、カットは、１または複数のイベントで構成されてもよく、シーンは、１または複数のカットで構成されてもよく、シリーズのシーズンのエピソード、シリーズ全体自体、映画のチャプタ、映画全体、映画および同様の映画を含むジャンルなど、より高いレベルまで、利用可能なコンテンツのデータサービスの完全なセットまで、などであることに留意されたい。さらに、イベント内にサブイベントを有すること、イベント内に複数のカットを有することなども可能であり、さらに、サブイベントよりも粒度の高いものを有すること、例えば、単一のビデオフレームまたはその画像まで有することも可能である。

[0025]１または複数の実装では、ビデオ部分（例えば、イベント）記述は、一般に、名詞および動詞、例えば、シリーズＺ、シーズン２、エピソード６、シーン８、カット３、イベント２：［キャラクタ＝Ａ、キャラクタ＝Ｂ、ロケーション（ｌｏｃａｔｉｏｎ）＝城・・・、アクション＝口論（ａｒｇｕｍｅｎｔ）、アクション＝戦闘、アクション＝剣闘、アクション＝流血の争い（ｇｏｒｅ）・・・］で記述され得る。名詞および動詞は、限定された語彙を有することができ、シソーラス、辞書などを介して語彙にマッピングされたより多くのサーチ語を有する。名詞は、サーチ結果がより正確になるように動詞に結び付けられてもよい。上記の例を使用すると、キャラクタＸ、ＹおよびＺは、キャラクタＸおよびＹが剣闘に参加するが、キャラクタＺが参加しないイベントに現れるかもしれない。したがって、キャラクタＺの剣闘を有するイベントのサーチは、キャラクタＸおよびＹの名詞が剣闘の動詞に結び付けられ、キャラクタＺが結び付けられない場合、このイベントを返さない。形容詞および／または副詞、例えば、［「大声の」ダイアログ（ｄｉａｌｏｇ）、「残虐な（ｂｌｏｏｄｙ）」戦闘］などを使用することもできる。

[0026]シーンカットおよび／またはイベントは、典型的には、関連するロケーションを有するが、関連するキャラクタを有さなくてもよい。例えば、嵐の海のシーンは、場合によっては、必ずしも必要ではないが、１または複数の暗示されるキャラクタに対する将来のトラブルの前兆を示すことができる。ロケーションと共に、シーンカットおよび／またはイベントは、典型的には、ノードの識別されたアクションが「静止」、「カメラパン」、「カメラズーム」等である場合であっても、関連するアクションを有する。例えば、シーンは、動きがほとんどまたは全く生じない穏やかな草原を示すことができる。

[0027]階層的に配置されたデータ構造は、いくつかの同様の拡張メタデータを提供することができ、したがって、１つの可能な実装であるが、グラフは、一般に、任意のノードが任意の他のノードにリンクすることを可能にし、したがって、より大量の情報へのアクセスを提供することを可能にすることによって、より高い柔軟性を有することができる。例えば、データサービスは、任意のメタデータノードを、コンテンツプロバイダによって利用可能にされ、サポートされるコンテンツを含む、コンテンツまたは拡張コンテンツを表す任意の他のノードにリンクすることができる（独立した第三者ソースとは対照的に、第三者ソースとともに、または第三者の情報が信頼でき、十分にサポートされる場合などは独立して）。より具体的な例として、コンテンツプロバイダは、複数の異なるカメラカットからキャプチャされた同じシーン、撮影されたが公開版から除去されたシーン、代替のシーン、ある国で公開されたが別の国で公開されていないシーンなどを見ることを可能にする拡張コンテンツを提供することができる。これを達成することができる１つの方法は、コンテンツの同じ部分（例えば、カメラ１イベントノードおよびカメラ２イベントノード）に対して代替のメタデータノードを有することである。代替のシーン、カットおよび／またはイベント（例えば、映画に対する異なるエンディング）は、例えば、ハッピーエンディングシーン・メタデータノードにおける情報または、悲しい（ｓａｄ）エンディングシーン・メタデータノードにおける情報を介して、ユーザに対して選択可能にされ得る。レーティング等または、視聴者の年齢や嗜好情報は、あるシーン、カットまたはイベントの情報を含む異なるメタデータノード内の情報を参照することによって、別のものではなくそのシーン、カットまたはイベントを自動的に選択するために使用してもよい。

[0028]拡張メタデータを用いて、視聴者は、ディレクタ（ｄｉｒｅｃｔｏｒ）によって選択されたもの、または、同様のプロファイル／人口統計を有するものを含む他の視聴者によって何らかの方法で選択されたもののような、エピソードのハイライト／サマリのみを見ることを選択することができる。例えば、ビデオのストリーミングにおいては、コンテンツプロバイダに知られている視聴者の情報、例えば、チャプタ選択、巻き戻しおよび早送りデータ、以前のサーチ等、並びに、ソーシャルメディア入力などの外部情報がある。視聴者の行動およびフィードバックは、他の視聴者がエピソードのハイライトに関して最も重要であると考えるものを決定するために使用するために利用可能であることが多い。

[0029]ここに示した実施例のいずれもが非限定的であることを理解されたい。例えば、いくつかの例は、映画、テレビ番組、ドキュメンタリなどを配信するストリーミングサービスからのビデオコンテンツ（オーディオを含む）のクライアント選択／サーチに関連するメタデータを参照する。しかしながら、ここで説明される技術は、任意の特定のタイプのコンテンツまたはメタデータとは独立しており、オブジェクトなどの可視表現としてそのようなメタデータを提示する任意の特定のユーザインタフェースとも独立している。したがって、ここで説明される実施形態、態様、概念、構造、機能、または例のいずれもが非限定的であり、本技術は、一般にデータ通信およびデータ処理において利益および利点を提供する様々な方法で使用され得る。

[0030]１または複数の実装では、ノードのグラフが各クライアントによって構築され、各グラフノードは、データサービスを介して利用可能な基礎データの一部を表す（ここで使用されるように、「グラフ」は、ノードおよびエッジとして視覚的に表されるかどうかにかかわらず、ノード間の関係によって形成される）。所与のクライアントのためのノードのセットは、そのクライアントに現在関連する利用可能なデータサービスのデータのサブセット、例えば、クライアントユーザインタフェースが表示するもの、通常、現在表示されていない、いくつかのキャッシュされたノード、および、おそらく表示可能ではないが他のノードのためのデータを維持するノードを含む。

[0031]したがって、ユーザインタラクションおよび自動化されたプロセスに基づいて、関連するノードのグラフを使用して、クライアントソフトウェアプラットフォームは、１または複数のグラフノードに対して、必要に応じてそれらのデータを取得するための要求を行う。クライアント要求は、データサービスの要求処理部分、例えば、インターネットを介してクライアントに結合されたクライアントインタフェース・フロントエンドデータサービスに対するものであってもよい。フロントエンドデータサービスは、各要求を解釈し、１または複数の実装では、フロントエンドキャッシュから、またはバックエンドキャッシュおよび／またはバッキングデータソース（ｂａｃｋｉｎｇ ｄａｔａ ｓｏｕｒｃｅｓ）からを含むバックエンドデータサービスを介して取得することができる、要求されたデータで応答する。このようにして、クライアントソフトウェアは、必要に応じて、一般に、リソース使用に関して非常に効率的であり、迅速な応答を得る、クライアントグラフの関連部分を構築する。グラフノードは、クライアントにおいてキャッシュされてもよく、それによって、データが必要とされるとき、クライアントプラットフォームは、まず、データサービスの要求処理部分に要求を行うことなく、クライアントキャッシュデータを使用することを試みてもよい。

[0032]図１は、クライアントグラフを形成するために、拡張メタデータノードを含む、グラフノードについてのクライアント要求を処理するために使用され得る例示的なコンポーネントを表すブロック図である。一般に、クライアントグラフは、ルート（ホーム）メニュー、ジャンルメニュー、シリーズメニューなどを表すノードなどの、ユーザインタフェースの何らかのインタラクティブな部分を表すユーザインタフェースノードのセットを含む。クライアントデバイスは、少なくともメモリが許す限り、インタラクティブコンテンツを表すために現在使用されていないノードをキャッシュすることができる。例えば、対応するジャンルノードを有する「ジャンル」メニューは、他のインタラクティブ要素の中で「コメディ」インタラクティブ要素（対応するコメディノードを有する）を含むことができ、ユーザが「コメディ」メニューにナビゲートし（ｎａｖｉｇａｔｅｓ）、次いで「ジャンル」メニューに戻る場合、ユーザがメニューの中でナビゲートするときにそれらを再ダウンロードすることを回避するために、ジャンルメニューおよびその他の子ノードをキャッシュすることができる。

[0033]しかしながら、拡張メタデータノードは、この時点でダウンロードされる必要はないことに留意されたい（例えば、非常に人気のある番組について、または以前のユーザ挙動に基づいて例外が存在してもよい）。代わりに、ストリーミングビデオコンテンツのように、選択された特徴ノード等に対して再生が選択されたとき、またはユーザサーチまたは他の特定の要求に応答して、拡張メタデータノードがダウンロードされる。

[0034]図１に例示されるように、クライアントデバイス１０２は、グラフ関連要求１０８を含むグラフノード１０６をデータサービス１１０から受け取るクライアントプラットフォームソフトウェア１０４を実行する。クライアントデバイス１０２は、最初に、例えば、クライアントデバイス１０２のクライアントユーザがデータサービス１１０で認証すると、タイプされたノードに対応する１または複数の開始ノードを自動的に受け取ることができる。例えば、ユーザがクライアントデバイス１０２にログインすると、認証の成功次第、クライアントデバイス１０２は、クライアントプラットフォームソフトウェア１０４が予期する（ｅｘｐｅｃｔｓ）、ユーザグラフノード、ルートグラフノードなどを受け取ることができる。このようにして、クライアントプラットフォーム１０４は、ユーザが他のロケーションにナビゲートすることができるボタン、アイコン、タイルなどを有するホーム／ルートメニューなどのルートノードに基づくルートメニューなどをレンダリングすることによって、初期ユーザインタフェース要素を提示することができる。１または複数の実装では、ルートグラフノードがインタラクティブユーザインタフェース１１２の開始点であるので、ルートグラフノードに加えて、ルートグラフノードによって参照される１または複数のノードを、事前にクライアントに自動的に通信することができる。しかしながら、これは１つの可能な最適化に過ぎず、代替的に、クライアントデバイスは、スタートアップ時のルートグラフノード、およびルートグラフノードの子であるノード等を含む、任意の必要なデータを要求するように構成されてもよい。

[0035]１または複数の実装では、クライアントソフトウェアプログラムのＵＩ要素などは、ノードについて、または基礎データがどのように維持、編成、検索などされるかについて知る必要なく、（例えば、データサービスレベルで）クライアントプラットフォームにデータアイテムを要求してもよい。例えば、テレビ番組を表すタイルオブジェクトは、（１または複数の実装ではグラフノードＩＤでもある）タイトルＩＤに対応するタイトルの要求をクライアントプラットフォームソフトウェアに直接送ることができ、そのタイトルを得る。理解されるように、ＵＩレベルの下で、クライアントプラットフォームソフトウェアは、そのＩＤに対応する（特徴タイプ）グラフノードからタイトルを取得し、グラフノードデータは、クライアントキャッシュから取得することができ、キャッシュされていない場合には、ここで説明するように、データサービスからグラフノードを要求することによって取得することができる。

[0036]上述のように、各ノードは、グラフ１１４を形成する１または複数の他のノードを参照することができる（例えば、一般にクライアントキャッシュ１１６または他の適切なデータストレージ内に維持される）。クライアントグラフ１１４は、ノードがインタラクティブユーザインタフェース１１２上のオブジェクトの可視表現としてレンダリングされるときなど、必要に応じてこれらの他のノードのデータを取得することによって構築される。グラフノードデータの例示的な可視表現は、メニュー、タイル、アイコン、ボタン、テキストなどを含んでもよい。例えば、すぐ必要となるであろう統計的な可能性に基づき、実際に必要となる前に、１または複数のノードを前もってキャッシュすることが可能である。例えば、ノードＸＹＺを取得する多くのユーザは次にノードＥＦＧを求める傾向があるので、ノードＸＹＺがダウンロードされるとき、ノードＥＦＧを取得することもできる。

[0037]さらに、理解されるように、あるグラフノード、典型的には拡張メタデータグラフノードは、ビデオコンテンツと共にクライアントデバイス１０２に自動的にストリーミングされ得る。例えば、あるシーンのようなビデオコンテンツのある部分は、そのグラフに含めるためにクライアントデバイス１０２に自動的にストリーミングされるその特定の部分を記述する拡張メタデータグラフノードを有することができる。これにより、クライアントユーザは、要求に応じてこれらの拡張メタデータグラフノードを要求することなく、ビデオ部分に関連する拡張メタデータグラフノードと何らかの方法でインタラクトするように切り替えることができ、これらは、高効率のユーザインタラクションのために、有利なことにクライアントデバイスグラフ１１４／キャッシュ１１６に既に存在する。

[0038]一般に、クライアントグラフ１１４は、データサービス１１０から利用可能なデータ全体のクライアント関連サブセット（ｃｌｉｅｎｔ−ｒｅｌｅｖａｎｔ ｓｕｂｓｅｔ）を含む（データサービスで利用可能なデータは、実際にどのように維持されるかに関わらず、仮想グラフ全体と考えることができる）。クライアントプラットフォーム１０４では、基礎データがクライアントグラフ１１４を形成し、その少なくとも一部がユーザインタフェース１１２上の要素として表され得るので、ユーザは、非常に異なる種類のデータ間の関係、および／またはいくつかのユーザにとって無関係であると思われ得る関係を含む、（例えば、ストリーミングビデオサービスの）データサービス１１０が利用可能にすることを決定した、任意の関係についてのデータを受け取るためにインタラクトすることができる。時間とともに、データサービス１１０は、例えば、ユーザフィードバックに基づいて、および／または新しいノードおよび／またはグラフノードタイプが利用可能になると、新しい関係でリンクするために、必要に応じて、そのような参照を追加、削除、または変更することができる。

[0039]ノード１０６を取得するために、クライアントプラットフォーム１０４は、例えば、クライアントインタフェース・フロントエンドデータサービス１１８を介して、インターネット１２０などのネットワークを介して、データサービス１１０とインタフェースする。様々なタイプのクライアントデバイスおよび／または様々なソフトウェアプラットフォームバージョンが、両方のエンティティが理解するプロトコルを介してフロントエンドデータサービス１１８と通信することを可能にするために、デバイスおよび／またはプラットフォームソフトウェアバージョン用にカスタマイズされ得るアプリケーションプログラミングインタフェース（ＡＰＩ）１２２が存在し得る。

[0040]フロントエンドデータサービス１１８は、クライアントプラットフォームソフトウェア１０４が予期する方法で、要求されたノード１０６を返す多数の負荷分散（ｌｏａｄ−ｂａｌａｎｃｅｄ）物理サーバおよび／または仮想サーバ（別々に図示せず）を備えてもよい。グラフノードについての要求のいくつかは、クライアントプラットフォームソフトウェア１０４が単一のグラフノードにおいて予期する複数のサブ要求に対応してもよく、例えば、特徴（映画）を表すタイルグラフノードについての要求は、タイトル（テキスト）、ＵＲＬなどの画像参照（ｉｍａｇｅ ｒｅｆｅｒｅｎｃｅ）、レーティング、プロットサマリなどについてのサブ要求（ｓｕｂ−ｒｅｑｕｅｓｔｓ）に対応してもよい。ユーザの「ウォッチリスト（ｗａｔｃｈ ｌｉｓｔ）」についての要求は、複数のタイルについてのサブ要求に対応してもよい。データサービス１１０は、グラフノードについてのクライアント要求に応答するために、各グラフノードのタイプに基づいて、場合によっては様々なソースから単一のグラフノードに、必要に応じてデータサブパーツをどのように取得し、組み立てる（ａｓｓｅｍｂｌｅ）かを理解する。

[0041]対応するグラフノードは、複数のクライアントからの同様の要求を効率的に満たすことを可能にする、１または複数のフロントエンドキャッシュ１２４に含まれ得る。例えば、各負荷分散サーバは、頻繁に、または最近要求されたデータを含むメモリ内キャッシュを有してもよく、および／または、フロントエンドサーバによって共有される１または複数のフロントエンドキャッシュが存在してもよい。データは、典型的には、フルグラフノード（ｆｕｌｌ ｇｒａｐｈ ｎｏｄｅ）（例えば、複数のサブ要求からのデータに対応するタイル）としてキャッシュされるが、フルグラフノードを提供するために集約されるサブパーツに少なくともいくつかのデータをキャッシュすることが可能である。

[0042]要求されたデータの一部または全部は、フロントエンドキャッシュ１２４にキャッシュされなくてもよい（またはキャッシュされるが期限切れに（ｅｘｐｉｒｅｄ）されてもよい）。そのような必要とされるデータに関して、１または複数の実装では、フロントエンドデータサービス１１８は、バックエンドデータサービス１３２に、データ１３０についての要求１２８を行うように（例えば、イントラネットおよび／またはインターネットを含み得るネットワーク１２６を介して）結合される。

[0043]バックエンドデータサービス１３２は、同様に、フロントエンドデータサービス１１８によって予期される方法で、要求されたデータを返す、いくつかの負荷分散物理サーバおよび／または仮想サーバ（別個に図示せず）を備えてもよい。要求されたデータは、１または複数のバックエンドデータキャッシュ１３４に含まれ得る。例えば、各負荷分散バックエンドサーバは、要求されたデータを含むメモリ内キャッシュを有してもよく、および／またはバックエンドサーバによって共有される１または複数のバックエンドキャッシュが存在してもよい。

[0044]バックエンドデータサービス１３２に到達するが、いずれのバックエンドキャッシュ１３４からも満たすことができない要求については、バックエンドデータサービス１３２は、１または複数の様々なバッキングデータソース１４０（１）―１４０（ｎ）に、データ１３８についての要求１３６を送るために、（例えば、イントラネットおよび／またはインターネット１２０を介して）さらに結合される。このようなデータソース１４０（１）―１４０（ｎ）の非限定的な例は、キーバリューストア、リレーショナルデータベース（ｒｅｌａｔｉｏｎａｌ ｄａｔａｂａｓｅｓ）、ファイルサーバなどを含むことができ、これらは、事実上任意の適切なフォーマットでデータを維持することができる。グラフノードデータについてのクライアント要求は、複数のサブ要求に対応することができ、これらのサブ要求は、データソースをバックアップするためのものであってもよい。データサービス１１０は、必要に応じて適切なフォーマットのデータについての要求を異なるバッキングデータソース１４０（１）―１４０（ｎ）に行うように構成される。さらに、１つのデータストアのデータは、別のデータストアのデータをオーバーライドすることができ、例えば、テレビ番組のデータは、１つのデータストアから取得された一般的な画像ＵＲＬを含むことができるが、「編集」のようなデータストアは、例えば、何らかの特徴のないエピソードについて、一般的な画像を異なる画像でオーバーライドすることができる。１または複数の実装では、非キャッシュ（ｎｏｎ−ｃａｃｈｅ）データソース１４０（１）−１４０（ｎ）は、共通のキャッシュインタフェースを実装するラッパ（ｗｒａｐｐｅｒ）を使用することができ、それによって、各リモートデータソース１４０（１）−１４０（ｎ）は、バックエンドデータサービス１３２の観点から別のキャッシュのように扱われ得る。

[0045]図２は、ルートメニューノード２２２およびユーザノード２２３を含む、簡略化されたユーザインタフェースグラフ２２０の例の概念を示す。ルートメニューノード２２２は、いくつかの例示的な子ノード２２４−２２６を有し、ユーザメニューノードは、（例えば、ユーザ指定のお気に入りとして）シリーズメニュー２２６の子でもあるシリーズノード２３５に結合される。各ノードは、例えば、表示画面上にレンダリングされると、メニュー、メニューアイテム、画像、テキスト、ビデオなどとして視覚的に表され得る。

[0046]次に、子ノード２２４−２２６は、それぞれジャンルメニュー２２４のアクション、ロマンス、コメディノードに対応する子ノード２３０−２３２、および、シリーズメニュー２２６の「シリーズ」子ノード２３４、２３５などの子ノードを有してもよい。図２に示すように、典型的なシリーズメニューノードは、１または複数の「シーズン」子ノード、例えば、ノード２３７、２３８を有し、各シーズン子ノードは、そのシーズンのエピソードに対応する「エピソード」子ノード、例えば、ノード２４２および２４３を有する。なお、図２では、説明を明確にするために、いくつかの子ノード（例えば、アクションジャンル、シリーズＺ、シリーズＹ／シーズン１についての子ノード）等は省略している。

[0047]最終的に、サブメニューのユーザ選択などによってグラフをトラバースする（ｔｒａｖｅｒｓｉｎｇ）ことによって、再生可能なコンテンツアイテム（例えば、再生可能な映画を表すといった選択可能なメニューアイテム）の情報を含むノードを有するものに到達する。例えば、ノード２４０は、図２のある映画「Ｘ」を表す。選択可能なアイテムは、サーチクエリに応答して返されてもよい。

[0048]図２の例では、ノード２４０は、再生ノード２５０および拡張メタデータノード２５２にリンクされる。ノード２５０の選択は、ビデオコンテンツの再生をもたらし（ブロック２６０）、一方、拡張メタデータノード２５２の選択は、利用可能であれば、ユーザが拡張メタデータグラフ２６２にナビゲートし、その拡張メタデータグラフ２６２内でナビゲートすることを可能にする。ここで説明されるように、ビデオコンテンツを再生するためのユーザ選択はまた、拡張メタデータグラフ２６２の少なくとも一部の並列または一般に並列のダウンロードを自動的にトリガすることができる。

[0049]図３は、ノード３３２によって表されるエピソードの例示的な部分グラフ表現３３０を示す。エピソードビデオをどのように再生するかに関する情報、例えば、図２の再生ノード２５０に対応し得る、既に開始されたビデオの再生をどこで再開するかなどの、ビデオプレーヤによって必要とされる任意の情報は、ノード３３４に存在し得る。このような情報は、グラフ内のノードとして維持される必要はなく、この例ではノード３３４内に存在する。

[0050]図３には、シーンノード３３８−３４０（この例では３つ）の親であるタイムラインノード３３６を含む、この例では一番上のノードを有する拡張メタデータグラフも示されている。タイムラインノードは、例えば、シーンの順序、ならびに、各シーン内のカットなどのさらなる情報をトラックすることができる。典型的には映画（および時にはエピソード）のような任意のコンテンツに対して、作者／ディレクタ／エディタ（ｅｄｉｔｏｒ）がコンテンツの部分をどのように分割することを望むかによって、チャプタノード等がシーンノードの上に（またはその代わりに）存在してもよい。

[0051]この例では、図３のグラフ３３０は、シーンノード３３８ー３４０である。ノード３３８によって表されるシーン１は、子ノード３４１−３４３によって表される３つのカットに分割される。シーン２および３はそれぞれ、１または複数の類似の「カット」ノードを有してもよい。同じイベントノードが（エッジ参照データを介して）複数のカットノードに結び付けられてもよく、例えば、カット２ノード３４２およびカット３ノード３４３がそれぞれイベント１ノードＥ１にリンクされる（これは、グラフが階層よりも有利となり得る別の理由である）。あるいは、イベントノード（例えば、Ｅ４）は、複数のカットノード（例えば、Ｃ４、Ｃ５）に対する親ノードであってもよく、例えば、イベントノードは、シーンノードの直接の子であってもよい（例えば、イベント４ノードＥ４は、シーン３ノード３４０の子である）。例えば、キャラクタ間のダイアログなどの単一のイベントは、１つのキャラクタを示す１つのカットと、他のキャラクタを示す別のカットと、両方のキャラクタを示す可能性のあるさらに別のカットなどから構成され得る。対応するフレームデータは、任意のノードに保持される場合、非連続フレームのセットであってもよい。過度の複雑さを避けるために、必要に応じて、実際に同じ冗長データを含む別個の異なるノードを使用することができる。

[0052]図３の例では、カット３（ノード３４３）が３つの異なるイベントノードＥ１−Ｅ３を有することが例示される。したがって、例えば、エピソードが架空の世界で展開されるストーリーを伝える場合、シーン１は１つの王国（ｋｉｎｇｄｏｍ）であり、シーン１のカット３は宮殿であり、カット内の別個のノードにより表されるキャラクタ登場（イベント１）、キャラクタ間の口論（イベント２）、戦闘（イベント３）などのイベントを有する。容易に理解されるように、シーンおよびカットは、ディレクタ／エディタなどによって、撮影中に既に決定されていることが多く、したがって拡張メタデータグラフ内の各シーンを表すノード、およびそのカットを有することは、実施するのが比較的簡単であることが多い。カット内の異なるイベントは、もしあれば、カットを、ここで例示される異なるアクション（登場、口論、戦闘）などの特定のピースに分割することを望むコンテンツプロバイダの従業員のチームなどによって、何らかの他の方法で決定されてもよい。理解されるように、カットノード（または場合によってはシーンノード）をイベントノードにさらに分割することにより、必要に応じて、リッチな（ｒｉｃｈ）、よりピンポイントのサーチ、より明確なビデオサマリ、他の関連コンテンツへのより正確なリンクなどが容易になる。

[0053]イベントノードは、例えば、どのキャラクタが登場したか、イベントがどこで起こったか、イベント内で何が起こったかを含む、イベントについての特定の情報を含むことができる。上述のように、名詞および動詞は、イベントのこれらの態様を記述することができる。

[0054]ここで説明されるように、拡張メタデータノードはサーチ可能であり、したがって、サーチエンジンによって理解される何らかの規則が必要とされ得る。例えば、サーチエンジンが各可能性のある関連ノードをトラバースするように、コンテンツの任意の部分は、少なくとも１つの単一のカットノードの親である少なくとも１つの子シーンノードを有する少なくとも１つの単一のチャプタノードによって表される必要があり、最下位レベルのノードまで同様である。あるいは、サーチエンジンが、最上部のノードから開始し、必要に応じて、子ノードのみに続くことを知っている規則を使用することができる。したがって、必要であれば、１つのノードのみが、コンテンツ全体の情報を含むことができ、そのカット内のチャプタ、シーン、カット、およびイベントの間のノードベースの区別はなく、それは、非常に短いビデオに適切であり得る。

[0055]図４は、カットノード４４０が、イベントノード４４２および４４３を、それらのイベントノードを識別するエッジデータを介して、子のうちの２つとして含む例を示す。イベントノード４４２および４４３は、アクタ（ａｃｔｏｒ）ノード４４５−４４７、マップノード４４９に対するエッジと、他のノードに対する可能性のある多くの他のエッジとともに示される。図４の簡略化された例には明示的に示されていないが、１または複数の実装におけるエッジ関連データは、任意の特定の関係を指定する情報を含むことができる。例えば、ノード４４０は、ノード４４２の親であるという情報を含むことができ、同様に、ノード４４２は、ノード４４０の子であるという情報を含むことができる。

[0056]ノードの関連サブセット（ｒｅｌｅｖａｎｔ ｓｕｂｓｅｔ）は、現在選択されているビデオに関連する、および／またはサーチ可能なエピソードまたは映画のセットなどのコンテンツの関連するセット（ｃｏｎｎｅｃｔｅｄ ｓｅｔ）に関連する様々なデータを含む。したがって、図４の例では、この例ではノード４４０によって表されるｗｗｗとして識別されるカットの中には、ノード４４２、４４３によって図４において視覚的に表されるデータを有するイベントｚｚｚ、ａａａａを含む、３つのイベントｇｇｇ、ｚｚｚ、ａａａａがあることがわかる。イベントノード内の名詞および動詞は、他のノードから情報を取得するために、サーチされるか、インタラクトされてもよく、および／またはエッジが続いてもよい。

[0057]図４の簡略化された例では、名詞は動詞に明示的に結合されないことに留意されたい。しかし、名詞を動詞にグループ化することによって、例えば、［アクション＝戦闘（Ｆｉｇｈｔ） ＯＲ 剣闘（Ｓｗｏｒｄｆｉｇｈｔ）］ＡＮＤ［キャラクタ＝ジョー（Ｊｏｅ）ＯＲキャラクタ＝モー（Ｍｏｅ）ＯＲロケーション＝宮廷（Ｐａｌａｃｅ） ＯＲサブロケーション＝階段（ｓｔａｉｒｃａｓｅ）］などのブール演算子接続関係を含めることによって、そうすることは簡単である。いくつかの演算子は、明示的ではなく暗示的であってもよい。

[0058]容易に理解されるように、実際の人間が読める名詞および動詞を含むノードの代わりに、コードを使用することができ、例えば、「戦闘」という用語に、各キャラクタ同様に、データサービス内で一意の何らかのアルファ／ニューメリック（ａｌｐｈａ／ｎｕｍｅｒｉｃａｌ）コードを与えることができる。これは、ノードのデータを異なる言語辞書等に結び付けることを容易にする。同様に、全く同じ名前を有する二つのキャラクタまたは俳優を区別することができ、また、同じ名前を有する２つの映画（オリジナル映画とリメイク映画）、同じ名前を有する２つのロケーションなどを区別することができる。したがって、ここで使用されるように、ノードの情報（例えば、名詞、動詞、副詞、形容詞、あるアクション、ロケーション、俳優、タイトル、キャラクタなど）に保持されているものは、適切なテキスト／グラフィックス／オーディオ／画像データ／ビデオを取得することができる適切なデータセットにマッピングする実際のテキストまたはコードなどであってもよい。

[0059]図４には示されていないが、キャプチャされたビデオイベントの簡単な説明がイベントノードに存在してもよい。例えば、ノード４４３については、「ジョーとモ―は、宮廷のボールルームで紹介され、口論になった後、宮廷の階段を下る剣闘になった」。記述を直接含む代わりに、そのような記述は、例えば、視聴者の好ましい言語に一致するオーディオおよび／またはテキストのデータストアへのＵＲＬといった、別のデータセットへの参照から得られてもよい。

[0060]そのような情報を用いて、拡張メタデータグラフは、ユーザが、重要でリッチな情報を閲覧することを可能にし、また、リッチで、よりピンポイントのサーチを容易にする。コンテンツの現代の（ｃｏｎｔｅｍｐｏｒａｒｙ）サーチは、一般に、タイトル、俳優、ジャンル、他の非常に高いレベルの情報によるサーチに限定されると考える。例えば、「ゲーム・オブ・スローンズ（登録商標）」（ＨＢＯ（登録商標）シリーズ）の視聴者は、「キングスランディング」（ゲーム・オブ・スローンズ（登録商標）における架空の首都）における全てのシーンを見つけるためのサーチを望む場合がある。現在、従来のメタデータを使用して、ユーザは、「キングスランディング」がエピソードのタイトル内にたまたまある場合に、いくつかのエピソードのセットを取り出すことができる。

[0061]対照的に、拡張メタデータグラフでは、視聴者は、サーチエンジンが、特定の拡張メタデータノード、例えば、図４の例ではイベントノードで記述されるコンテンツまでを見つけることを要求することができる。拡張メタデータグラフを用いて、ユーザは、例えば、シリーズ全体、そのシリーズ内のシーズン、特定のエピソード、またはエピソードのサブセット（例えば、シーズン１および２のすべてのエピソード等）など、サーチするコンテンツの任意のセットの範囲を指定することができる。サーチ範囲が決定されると、サーチは、例えば、特定のキャラクタＸが「キングスランディング」に登場したすべてのイベントを見つける、イベントレベルといった任意の適切なレベルまで下げることができる。このために、例えば、サーチクエリに関して、そのエピソード内で関連するシーン、カット、および／またはイベントが発生したかどうかを決定するために、拡張メタデータグラフを含むデータサービスのグラフにおけるすべてのエピソードリンク（ｅｐｉｓｏｄｅ−ｌｉｎｋｅｄ）ノードに対してサーチを実行することができる。

[0062]上記の例を使用して、ユーザは、したがって、キャラクタＸが登場したかどうかに関して、エピソードの全シリーズ、またはエピソードの１つのシーズン（またはシーズンのサブセット）、または単一のエピソード内をサーチすることができる。ここで説明するように、視聴者は、例えば、キャラクタＸが戦闘に参加するなどの何らかのアクションを行ったシーンを見つけるために、そのようなサーチをさらに絞り込むことができる。適切なメタデータがポピュレートされる（ｐｏｐｕｌａｔｅｄ）（またはリンクされる）場合、拡張メタデータグラフ内のメタデータは、キャラクタＸが戦闘に参加した各エピソードＩＤ、シーン番号、カット番号、およびそのような各イベントの正確なフレーム範囲などに関する情報を提供するとともに、そのようなクエリに回答することができる。別の例示的なサーチとしては、ある有名な俳優Ｗが馬に乗っている（サーチ範囲内で要求された基準に一致する俳優および行動）、ジャンル「西洋」（サーチ範囲）のすべての映画をサーチすることがある。

[0063]別の態様に移ると、ユーザ指定のサーチ基準に加えて、拡張メタデータグラフ内の情報に基づいて、関連するビデオコンテンツを自動的に見つけ出し、生成／コンパイルすることによって、エピソード（または複数のエピソード）のハイライト／サマリを、視聴者のためにまとめることができる。サマリは、各ユーザの選択、示された嗜好、他の視聴者のフィードバック、コンテンツプロバイダチームの嗜好などに従って（例えば、重要であるとみなされるイベントにフラグを立てることによって）、コンテンツを選択するために、拡張メタデータグラフノードを自動的にサーチすることによって組み立てられてもよい。例えば、イベントノードのデータは、「サマリ」の「はい」または「いいえ」のフラグを含むことができ、それによって、エピソードサマリは、はいに設定されたフラグを含むイベント、例えば、［シーン１、カット２、イベント３、シーン２、イベント８、カット３、４、・・・］を介して組み立てられてもよい。

[0064]フラグの代わりに、ユーザが、あるユーザ指定の閾値を超えるイベントのサブセットを得ることができるように、何らかの「みなし（ｄｅｅｍｅｄ）」サマリ／ハイライト重要度値（例えば、１から１０の範囲）を各イベントノード（または他のノード）のメタデータ内に含めることができる（フラグまたは重要度値をノード内に維持する代わりに、そのようなデータを、例えば、別個のデータベースを介して、ノードに関連付けてもよい）。ノードに含まれる重要度値は、重要度値＝２を含むイベント４４２のデータおよび重要度値＝７を含むイベント４４３のデータを介して図４に例示される。繰り返すと、そのような値は、例えば、コンテンツプロバイダ（作者、ディレクタ、編集チーム等）による設定、ユーザ嗜好データ（「ハイライト戦闘および対戦（ｂａｔｔｌｅｓ）」）によって設定される、収集されたユーザ履歴（ユーザは、戦闘イベントを巻き戻すことが多い）、他のユーザアクション（多くのユーザは、このイベントの再生を要求しており、現在の視聴者と同様の人口統計を有する可能性がある）など、任意の方法または組み合わせた数の方法で決定され得る。任意のノードに関するそのような重要度値などを決定するために、時刻、曜日、視聴者の人口統計、レーティング、現在のニュースイベント、ソーシャルメディアコンテンツなどの状態データを、他の方法の代わりに、または他の方法に加えて使用することもできる。例えば、ユーザベースハイライト重要度値、データサービス割当サマリ重要度値など、複数のそのような値が存在してもよい。

[0065]サマリの生成に関して、例えば、サマリを作成すべきイベントの関連するセットに対して値セットが決定されると、そのようなサマリ値を使用する別の方法は、ユーザがそれを見るのに費やしたい時間に基づいてサマリを自動的に提供することである。例えば、ユーザは、最も重要なイベントの非常に高速（約２分）のサマリを要求することができ、データサービスは、所望の時間にほぼ合致する重要度閾値（例えば、サマリ値９および１０を有するもののみ）を計算することができる。ユーザが５分を要求した場合、７を超えるサマリ値を有するもののみを計算することができ、例えば、要求された時間により近似するために、６の値を有するものに対して何らかのランダムまたは時間ベースの選択を行うことができる。あるいは、実際の時間とは無関係に、主要な（ｍａｊｏｒ）サマリ、中程度の（ｍｅｄｉｕｍ）サマリ、および主要でない（ｍｉｎｏｒ）サマリなどのいくつかの他の選択基準を、重要度値に基づいて組み立てることができ、例えば、主要なサマリは、値８−１０を有するイベントを選択し、中程度のサマリは、値５−１０を有するイベントを選択し、主要でないサマリは、値３−１０を有するイベントを有する。包含的な決定を行うために、そのような値またはフラグを使用する任意の他の方法を使用することができる。

[0066]サマリ／ハイライトビデオの自動選択は、イベントの選択および順序付けにおいて、場合によっては視聴者入力によって制約されるように、所望の任意の規則に従うことができ、例えば、コンテンツのオリジナルタイムラインに従う必要はない。例えば、実際のエピソードでは、サマリのパートＢのシーン、カット、またはイベントの一部がパートＡのそれらのいくつかに先行したとしても、１つのキャラクタ（またはサイト）の重要なシーンをサマリのパートＡとし、その後にパートＢとして別のキャラクタ（またはサイト）の重要なシーンを続けることができる。

[0067]別の態様に移ると、図５は、イベント５５２を複数のサブイベントに分離する方法の表現であり、５５４および５５５とラベル付けされた、２つのサブイベントが示される。図５の例では、同じイベントが２つの異なるカメラ、例えば、キャラクタに対して１つは頭上から（ｏｖｅｒｈｅａｄ）、１つはアイレベル（ｅｙｅ−ｌｅｖｅｌ）で撮影されたとする。したがって、このイベントに対して２つの（またはそれ以上の）異なるセットのビデオフレームが存在し、それぞれがサブイベントノード５５４または５５５によって表される。ユーザの嗜好または他の何らかの選択データ（例えば、時刻、最後に示されたカメラの反対のカメラ角度などの状態データ）を使用して、それらの間で選択すること、および／またはディレクタのデフォルト選択をオーバーライドすることができる。

[0068]同様に、異なるカメラ角度から同じコンテンツを提供する代わりに、サブイベントは、所与のイベントについて示されるべき完全に異なるコンテンツを提供してもよい。例えば、ある視聴者は、映画に対してハッピーエンディングを得ることができ、別の視聴者は、悲しいエンディングを得ることができ、さらに別の視聴者は、未解決のエンディングを得ることができる。このような３つのエンディングのそれぞれは、拡張メタデータグラフ内の異なるサブイベントノード内で識別される関連フレームを有することができる。異なるコンテンツ間で選択するために、シーン／カット／イベントレーティングに対するユーザの年齢を使用してもよい。

[0069]この例では、サブイベントの中から選択するために、実際のビデオデータが再生のためにバッファに挿入されるか、またはバッファから取り出される必要があるポイントに到達すると、拡張メタデータグラフは、どの実際のビデオデータ（例えば、フレーム）を使用するかを選択するためにデータサービスによって調べられ（ｃｏｎｓｕｌｔｅｄ）てもよい。この決定は、代替ビデオストリームをダウンロードした後にクライアント側で行ってもよく、あるいは、送信前に１つのストリームまたは別のストリームを選択することによってサーバ側で行ってもよい。１または複数のバッファを介することを含む代替コンテンツ選択の概念は、本出願の譲受人に譲渡され、参照によりその全体が本明細書に組み込まれる、「ＳＴＲＥＡＭＩＮＧ ＭＥＤＩＡ ＳＴＡＴＥ ＭＡＣＨＩＮＥ」と題された米国特許出願第１５／１３５，７８３号に記載されている。

[0070]容易に理解されるように、図５に図示されたサブイベント５５４および５５５は、図４のイベントノード４４２および４４３のいくつかと同様に、冗長情報を含む。そのような冗長な情報は、親ノードの子ノードにおいて一貫している場合、親ノードにおけるその情報の単一のインスタンスで置き換えられてもよく、子ノードは、他のノードからサーチし区別するために、親ノードの情報を効果的に継承する。これは、サーチメカニズムなどが、共通して継承される可能性のあるデータを見つけるために、異なるレベルのノードをトラバースしなければならない可能性があるという点で、グラフをトラバースすること（例えば、サーチすること）を複雑にする可能性があるが、ある例では、グラフまたは部分グラフにおけるデータの全体量を大幅に低減する可能性がある。

[0071]別の態様に移ると、拡張メタデータグラフは、特定のシリーズ、シーズン、またはエピソード（または映画、または映画のチャプタなど）の対応するメタデータに限定されない。図３で一般的に表されるように（また、図４におけるエッジデータを介して）、拡張メタデータグラフの任意のノード（および通常のクライアントグラフ）は、データサービスによって所望されるように、データサービスから取得可能な任意の他のノードにリンクされ得る。これは、俳優、実際の撮影場所（架空の王国は、拡張メタデータグラフを介して、それが撮影された欧州の実際のロケーションにリンクされてもよい）、実際のカメラなどを含む実世界のエンティティなどの概念を、キャラクタ、架空の場所（ｓｉｔｅｓ）、架空のマップ、視点（頭上または前方を向くカメラ角度）などの架空のエンティティと結び付けることを可能にする。したがって、例えば、任意の適切なノードのデータとインタラクションに対応する視聴者選択は、俳優の実名またはステージ名にリンクすること、あるシリーズの俳優のキャラクタから別のユニバース（ｕｎｉｖｅｒｓｅ）（例えば、シリーズまたは映画）の同じ俳優のキャラクタにリンクすることなどができる。そのようなエッジが存在する場合、ユーザは、グラフを介して、シーン、カット、および／またはイベントが撮影された実際のロケーション（例えば、マップ、写真など）に関する情報を見ることができ、次いで、ユーザは、元のビデオに戻ること、より拡張されたメタデータの中でナビゲートすることを選択すること、新しいビデオ（オリジナルビデオのサマリ、完全に異なるビデオ、完全に異なるビデオのサマリ）を開始することなどができる。

[0072]さらに、拡張メタデータグラフは、架空のユニバース間のクロスオーバを可能にする。例えば、漫画のキャラクタに基づく映画は、時には、別の架空のユニバースのキャラクタによる１または複数の名場面（ｃａｍｅｏ）または「ゲストスター（ｇｕｅｓｔ ｓｔａｒ）」の登場を含む。ノード間のエッジは、このようなクロスオーバの登場をモデル化することができる。同様に、医療ドラマ、刑事ドラマ、および消防ドラマのようなテレビ番組は、例えば、刑事ドラマのゲストスターの負傷した警官キャラクタが医療ドラマで同じキャラクタを演じるように、互いのエピソードに入り込むキャラクタを有することがある。メタデータ内のノードを接続する適切なエッジを単に提供することによって、拡張メタデータグラフは、そのような架空のユニバースのそれぞれにおけるかなりの量の所望の情報と、現実世界における情報との間でナビゲートする直接的な方法をユーザに提供することができる。データサービスがそのような情報／コンテンツを拡張メタデータグラフへのリンクを介して利用可能にする場合、ユーザは、公開されたバージョンから編集されたコンテンツ（および場合によっては視聴コンテンツ）の情報を取得することができる。ユーザツールなどを介して、ユーザがクライアントのグラフに、他のノードへのエッジを含むカスタムデータを含む場合に、いくつかのノードをカスタマイズすることは可能である。

[0073]要約すると、ユーザは、様々な方法で拡張メタデータグラフとインタラクトすることができる。ここで説明する１つの方法は、基準選択（ｃｒｉｔｅｒｉａ−ｓｅｌｅｃｔｅｄ）ノードに基づいてサマリ／ハイライトビデオを介してインタラクトすることである。別の方法は、例えば、自由形式テキストサーチを介して、または支援を用いて（例えば、有効なサーチ語のドロップダウンメニューなどから）サーチすることによる。サーチの範囲／開始点は、例えば、グラフの最上部（例えば、ルートまたはユーザ）メニューからルートメニューの下の任意のレベルまで、ユーザによって選択され得る。

[0074]さらに別の可能なタイプのユーザインタラクションは、（少なくともいくつか）メタデータグラフノード／その中のデータのレンダリングされた可視表現を伴う。図６は、例えば、いくつかの子イベント（および／または、場合によっては子カット）ノードを有するシーンノードを含む例示的な拡張メタデータグラフの一部であるいくつかのデータに基づくものであってもよい、様々なメニューオブジェクト６６０（ａ）−６６０（ｄ）の仮想ユーザインタフェースを示す。図６では、（例えば、ルートメニューからジャンルメニューへ、特定のジャンル選択へナビゲートすることによって到達される）ムービー選択メニュー６３０（ａ）は、映画または他の情報にリンクするインタラクティブタイル（場合によっては、テキスト以外の情報を含む）であり得る、多数のインタラクティブボタンを提供する。この簡略化された例では、映画選択メニュー６６０（ａ）から、ユーザは、タイトル「Ｘ」の映画を選択するために、タイルまたはボタン６６２とインタラクトし、ユーザがその映画に関する選択を行うことができるメニュー６６０（ｂ）にナビゲートする。オプションとして、「再生（ｐｌａｙ）」オプション（ボタン６６４）、「詳細（ｍｏｒｅ）・・・」オプション（例えば、ユーザが映画についてより多く読む／見ることができるボタン６６６）、および、この例では、映画に対応する拡張メタデータグラフノードセット内の情報へのアクセスをユーザに提供する「拡張コンテンツ」オプション（ボタン６６８）を含む。前メニューまたは他の画面（サーチ入力ページなど）に戻るようにナビゲートするための戻る矢印ボタンも示されている。

[0075]メニュー６６０（ｂ）から、この例では、ユーザは、各ボタンがその一部として代表画像を表示するボタン６７１−６７３によって表されるシーンのメニュー６６０（ｃ）を示すように変更する「拡張コンテンツ」オプション（ボタン６６８）を選択する。簡潔にするために、この特定の例では、３つのシーンのみが利用可能であり、シーン３は、３つのイベントまたはカットを有する（例えば、チャプタはない）。

[0076]この例において、ユーザは、シーン３（ボタン６７３）を選択し、ユーザが、例えば、各ボタンが付随するテキスト記述および代表的な画像を有する、ボタン６７５−６７７によって表されるシーン３内のイベント（またはカット）に対応する、より具体的なコンテンツを選択することができる、メニュー６６０（ｄ）を提供する。ボタン６７５ー６７７のうちの１つを選択することは、例えば、シーンの詳細なテキストおよび／またはオーディオ記述、１または複数のさらなる画像、そのイベントのフレームまたはそのいくつかのサブセットだけを再生するための「部分再生」ボタンなどを提供することができる。「詳細・・・」ボタン６７８は、１または複数のさらなるメニューによって、シーン内の俳優の俳優データ、マップ、キャラクタデータなどにリンクすることなどによって、関連するメタデータとのさらなるインタラクションを可能にする。

[0077]図６は、ユーザが、選択されたビデオコンテンツに関して拡張コンテンツメタデータノードセットを介して、より直接的にナビゲートすることができるとともに、選択されたビデオコンテンツに直接関連付けられたリンクを超えるリンク（ノードエッジ）をたどることによって他のメタデータノードにナビゲートすることができる、単純化した仮想的な方法の１つにすぎない。別の方法は、ここに記載されるようなものを含むサーチによるものであり、例えば、サーチの範囲（例えば、シリーズＡ、シーズン１）を選択し、その範囲内のサーチ語に一致するイベントを見つけることによるもの、またはサーチにサマリを生成させることによるものである。

[0078]拡張コンテンツメタデータ情報とインタラクトするさらに別の方法は、ビデオ再生が行われている間に、またはある時点で一時停止／停止されている間に、インタラクトすることによる。この時点での拡張コンテンツは、任意の数の既知の方法で表示されてもよく、例えば、メインビデオを縮小し、メタデータを表示するために現在利用可能な画面サイズ制限（ｓｃｒｅｅｎ ｒｅａｌ ｅｓｔａｔｅ）を使用すること、テキストおよび／またはグラフィックスの形でメタデータを）オーバーレイすること（例えば、ある程度の不透過率を有する）、メインビデオを拡張コンテンツメタデータのフルスクリーンに置き換えることなどによって、ビデオが表示されたメタデータと共に一時停止／停止されるか、または再生を継続する間に、表示されたデータとのインタラクションを可能にする。

[0079]再生中にインタラクトすることを選択する場合、典型的なユーザは、最初に、ユーザが一時停止したときに示されている宮廷の間取り図、都市のマップなど、現在の再生位置に関連する少なくともいくつかのメタデータを見ることを望む。また、典型的なユーザは、インタラクションを開始するために長時間待つことを望まない。しかし、クライアントデバイスのストレージおよび帯域幅は限られているので、フルビデオに関連する拡張メタデータグラフ全体は、通常、クライアントデバイスにキャッシュされない。その代わりに、ビデオバッファと同様に、ストリーミングビデオの位置に現在関連する拡張メタデータグラフの部分を、並列または実質的に並列の隠しストリームなどでクライアントキャッシュにダウンロードすることができる。

[0080]図７は、ストリーミングビデオ７７０を示し、その各部分（例えば、フレーム７７２のセットなど）が、そのストリーミングビデオのための拡張メタデータノードセット７７６のサブセット７７４に対応する。図７の例では、クライアントキャッシュが、クライアントデバイスのビデオバッファ内に現在あるビデオデータに一般に対応する拡張メタデータと、場合によっては、直近に再生された（ｖｅｒｙ ｒｅｃｅｎｔｌｙ−ｐｌａｙｅｄ）ビデオ部分とを含むように、いくつかの拡張メタデータノードのスライディング「ウィンドウ」７７７を、キャッシュのためにクライアントデバイスにダウンロードすることができる。この例では、第１のシーン全体Ｓ１は、（それらをストリーミングするために必要なデータパケットの数にかかわらず）キャッシュ／キャッシュ追出（ｅｖｉｃｔｉｏｎ）のためのユニットとして、ウィンドウ７７７内で一緒にグループ化された拡張メタデータノードを有することができる。ユニットとして一緒にグループ化することができない場合、拡張メタデータノードを送る順序は、有用なサブグラフのキャッシュが最初に行われるために有用であり得るが、古い拡張メタデータノードの追出は、依然として必要とされるものを追出す可能性は低い。したがって、例えば、シーン１では、最下位レベルのノード、第１のカットのイベントノードＥ１、Ｅ２およびＥ３が、シーン１のカット１ノードの前、およびシーン１ノードの前に送られ、その後、カット２のイベント１ノードおよびカット２ノードが続く。この例では、３つのイベントノード、カット１ノード、シーン１ノードにおける情報は、最初の５つの拡張メタデータノードがストリーミングされた後にインタラクションのために利用可能であり、ビデオイベントが完了し、新しいノードが入ってくると、拡張メタデータノードを追出する必要がある場合、最も古いノードはイベント１ノードなどであり、これはもはや必要とされない可能性が最も高い。

[0081]任意のリソース制約されたエンティティと同様に、データサービス自体は、ビデオの拡張メタデータノードの完全なセットをいかなるときも維持しなくてもよい（また、不明瞭な映画のようないくつかの提供されたコンテンツは、拡張メタデータを全く有しないか、または制限された量しか有しないことがある）。したがって、データサービスが維持する拡張メタデータノード７７８の中で、データサービスは、ビデオのノードセット７７６全体、いくつかの直接リンクノード（ｄｉｒｅｃｔｌｙ ｌｉｎｋｅｄ ｎｏｄｅｓ）７８０および間接リンクノード（ｉｎｄｉｒｅｃｔｌｙ ｌｉｎｋｅｄ ｎｏｄｅｓ）７８２を維持してもよい（または維持しなくてもよい）。その代わりに、データサービスは、例えば、様々なデータソース７８６（１）−７８６（ｎ）で維持されるデータから、必要に応じて、またはそれらの必要性を予想して、拡張メタデータノードを要求に応じて組み立てることができる（ブロック７８４）。これらのデータソース７８６（１）−７８６（ｎ）は、データをノード形式で維持しないことが多く、任意のノードは、そのデータを異なるデータソースから取得する必要がある場合がある。したがって、データサービスは、必要に応じて、またはすぐに必要とされることを予想して、様々なデータを拡張メタデータノードに処理することができる。

[0082]図７に示すように、サーチエンジン７９０は、クライアントサーチ要求（例えば、サーチ範囲および１または複数のサーチ基準）を受け取り、メタデータノード内で見つけた情報、例えば、どのビデオのどのビデオ部分（例えば、フレーム）がサーチ要求と一致するかを返すように構成されている。さらに、図７に示すように、サマリ／ハイライトビデオジェネレータ７９２は、何らかの範囲および／または選択基準に基づいてビデオを生成するためにメタデータノードを使用する。

[0083]クライアントバッファおよびキャッシュに関して、図８の実施例では、クライアントデバイス８８０は、例えば、コンテンツ配信ネットワークを介して、データサービス８８２から複数のストリームを受け取る。したがって、拡張メタデータのサブセットを、クライアントデバイス上で再生されているビデオと対応させるために、データサービスは、現在関連する拡張メタデータノードを、例えば、別個のメタデータストリームで、クライアントデバイスのキャッシュにダウンロードする。これは、典型的には、オーディオストリームのように、ビデオストリームと並行してまたは実質的に並行して行われるが、場合によっては、異なるポートに対して行われる。異なるデータがインターリーブされた（ｉｎｔｅｒｌｅａｖｅｄ）、例えば、適切なバッファへのヘッダデータに基づいてソートされた、同じポートへの合成ストリームを有することも可能である。

[0084]典型的には、クライアントは、ビデオデータをビデオバッファ８８４にバッファし、オーディオデータをオーディオバッファ８８６にバッファする（いくつかのシナリオでは、左および右チャネル、前方および後方、サブウーファなど、および／または２次オーディオのための異なるバッファリングが存在し得るが、図８には示されない）。ビデオ／オーディオ再生コンポーネント（ブロック８８７）は、別個のものであってもよく、オーディオ／ビデオ出力を生成するために、一般に従来の方法で動作してもよい。

[0085]拡張メタデータストリームは、拡張メタデータグラフ処理８９０を介してクライアントグラフ８９２に処理される、拡張メタデータバッファ８８８に送られるように示されている。バッファ８８４、８８６、８８８の図示されたサイズおよびその中のブロック（例えば、パケットデータ）は、実際の相対的なサイズを表すことを意図していない。図１０に関して以下で説明するように、拡張メタデータグラフ処理コンポーネント８９０は、ノード識別子のＦＩＦＯキューなどのトラッキングデータ構造８９４を維持してもよく、その結果、拡張メタデータノードを、他のキャッシュされたデータとは異なるポリシを介してキャッシュ内で管理することができる。

[0086]容易に理解されるように、ビデオが再生されるときに、現在再生されているビデオに一般的に対応するために、クライアントデバイスは、一般的に、現在関連性の低い拡張メタデータを、より現在関連性の高い拡張メタデータと置換するように構成される。キャッシュサイズの考慮は、「過去の」拡張メタデータノードに関して、また、ある量の「未来の」拡張メタデータノードのバッファリングに関しても、追出／置換基準の一部として使用され得る。さらに、より重要であり、したがって任意の所与の時点（ｍｏｍｅｎｔ）にインタラクティブユーザによって使用される可能性がより高いと考えられるグラフノードなど、ある拡張メタデータノードと、より従来的なグラフノードを、ビデオストリームの現在の位置とは独立して（少なくともある程度）キャッシュすることができる。

[0087]このようにして、キャッシュ内の拡張メタデータをビデオとほぼ同期させて、従来のビデオ再生を実行することができる。バッファサイズ、キャッシュサイズなどに対応するデバイスタイプ情報、使用されているビデオ圧縮のタイプは、異なるデバイス／デバイスクラスのためのデータサービスにより通信されるか、一般に知られるものであってよく、それらが一般に同期されるように、ビデオパケットおよびオーディオパケットに対して拡張メタデータパケットを送る頻度を決定するために使用されてもよい。ビデオ再生が一時停止または停止される場合、拡張メタデータストリーム／ダウンロードは、予想される順方向または逆方向動作を提供するため、および／または拡張メタデータとインタラクトすることを望むユーザを予想するためなど、キャッシュ内に余裕がある範囲まで修正（例えば、増加）され得る。容易に理解されるように、図８は一例に過ぎず、別個の情報をダウンロードする一方でその情報を同期させておくための多数の他の方法のうちの任意のものを代わりに使用することができる。

[0088]より高い優先度のストリームおよびより低い優先度のストリームなど、拡張メタデータの２つの（またはそれより多くの）別個のストリームをダウンロードすることも可能である。例えば、帯域幅を節約するために、２つの拡張メタデータストリームが使用される場合、拡張メタデータパケットのより高い優先順位のストリームが、より低い優先順位のストリームがダウンロードされる前に、ある限度まで最初にダウンロードされてもよい。同様のメカニズムは、より低い優先順位のストリームのパケットに対して、より高い優先順位のストリームのパケットを異なるインターリーブ比率でインターリーブすることであり、例えば、各１つのより低い優先順位のストリームのパケットに対して３つのより高い優先順位のストリームのパケットをインターリーブすることである。

[0089]図９は、ストリーミングビデオデータ（オーディオは別個に説明されない）と共に、拡張メタデータをクライアントデバイスにストリーミングするためにデータサービスが行うことができる例示的なステップを示すフロー図である。ステップ９０２は、ステップ９０４が適切なビデオパケットをフォーマットしてストリーミングすることにより、再生されているストリーミングされたビデオ（ｓｔｒｅａｍｅｄ ｖｉｄｅｏ）内の位置を決定することを表し、ステップ９０２および９０４は、ビデオをクライアントビデオバッファにストリーミングするための従来の方法で実行される動作である。

[0090]ステップ９０４と並行して、または実質的に並行して実行され得るステップ９０６および９０８は、ビデオに対応する拡張メタデータのどのサブセットをストリーミングすべきかを決定するために、ビデオ内の位置を使用する。ステップ９０８は、ステップ９０４でストリーミングされるビデオパケットに対応する適切な拡張メタデータパケットをフォーマットし、ストリーミングすることを表す。

[0091]典型的には、ステップ９１０および９１２によって表されるように、ビデオバッファがいっぱいになるか、ユーザが再生を停止する何らかのアクションを実行しない限り、ビデオ位置が進み、ビデオおよび関連するメタデータがストリーミングし続ける。再生を停止することができる例示的なユーザアクションには、ビデオを一時停止すること、ビデオを停止すること、ビデオを早送りまたは巻き戻しすることなどが含まれる（ビデオの終わりに達することは、ステップ９１０でビデオを停止することと考えることができる）。他の何らかの方法（例えば、デバイスのリブート、ネットワークの切断）でビデオを終了することなどは、ここでは説明しない。

[0092]ステップ９１０で検出されたそのようなイベントまたは状態で、ステップ９１４は、例えば、何らかのキャッシュサイズリミットまたはメタデータ拡張リミット（ｅｘｐａｎｓｉｏｎ ｌｉｍｉｔ）に達するまで、ステップ９１６でクライアントキャッシュ内のメタデータの量を拡張するために、選択的に実行され得る。上述のように、メタデータのこの拡張は、ユーザがこの時点でメタデータとインタラクトすることを望むことを予想して行うことができ、それによって、追加の拡張メタデータを事前にキャッシュすることは、クライアントユーザの拡張メタデータインタラクション体験を改善することができる。

[0093]図１０は、拡張メタデータに関してクライアントキャッシュを管理するためにクライアントデバイス（例えば、図８の拡張メタデータグラフ処理コンポーネント８８６）によって行われ得る例示的なステップを示すフロー図である。図１０の例示的なロジックは、キャッシュに関して拡張メタデータを管理するための多くの可能な方法のうちの１つにすぎず、ロジックは、従来のユーザインタフェースノード（例えば、メニュー、サブメニュー、アイテム）と拡張メタデータノード（例えば、ここで説明するようなシーン、カット、イベントなど）の両方を維持する単一のクライアントキャッシュと共に動作する。これにより、拡張メタデータノードが１または複数の従来のユーザインタフェースノードに（例えば、エピソード、タイムラインノードまたはムービー、タイムラインノードを介して）リンクするため、従来のユーザインタフェースノードおよび拡張メタデータノードを含む単一の（部分）グラフをキャッシュすることができる。

[0094]ステップ１００２は、クライアントデバイスが、拡張メタデータストリームバッファ上で１または複数の拡張メタデータパケットを受け取ることを表す。ステップ１００４は、パケットから拡張メタデータノードを抽出する。ステップ１００６は、第１の拡張メタデータノードを選択する。各ノードは、データサービス内で一意の識別子（ＩＤ）を有する。

[0095]ステップ１００８は、ノードが、例えば、フラグなどによってノードのヘッダまたはデータにマークされているように、拡張メタデータストリームに到着した特別なノードであるかどうかを評価するオプションのステップである。ステップ１００８を介して、そのようなノードは、それが伴うビデオ部分とは独立して、またはクライアントユーザによってすぐに必要とされる可能性が高いなど、何らかの形で重要であるとサービスによってみなされる場合に、（ステップ１０１８で）キャッシュされる。これにより、ここで説明するように、現在バッファされている、またはビデオの再生部分に関連付けられている拡張メタデータノードを追出／期限切れにするためのポリシとは対照的に、拡張メタデータストリームは、通常のキャッシュポリシに従って追出／期限切れにされるグラフノードをクライアントキャッシュにキャッシュすることができる。

[0096]特別なノードでない場合、ステップ１０１０は、拡張メタデータノードのＩＤをＦＩＦＯキューまたは他の適切なデータ構造に追加する。ステップ１０１２は、キューがそのリミットにあるかどうかを評価する。

[0097]キューリミット（ｑｕｅｕｅ ｌｉｍｉｔ）にない場合、拡張メタデータノードがキャッシュされる。逆に、キューリミットにある場合、拡張メタデータノード識別子（例えば、ＦＩＦＯキューの場合は最も古い）がステップ１０１４でキューから除去され、対応する（例えば、最も古い）ノードがステップ１０１６でキャッシュから除去される。ノードは、この時点でキャッシュから実際に除去される必要はないが、追出のためにマークされることができ、期限切れのタイムスタンプを与えられることなどができ、それによって、キャッシュスペースが必要とされるときに、クリーンアッププロセスまたはより新しいノードがそれを置換することができる。ステップ１０１８は、拡張メタデータノードをキャッシュし、必要に応じて除去されたノードのスペースを上書きすることができる。

[0098]Ｓｅｐ１０２０は、受け取った他の拡張メタデータノードごとにプロセスを繰り返す。何も残っていない場合、より多くの拡張メタデータノードが拡張メタデータノードバッファにストリーミングされるまで、プロセスは終了する。

[0099]容易に理解できるように、図１０の例示的なステップにより、クライアントデバイスプラットフォームソフトウェアは、一般にどの程度の拡張メタデータを維持すべきかに関する独自の制限を決定することができる。このようにして、より少ないリソースを有するデバイスは、より小さいキュー／より少ない拡張メタデータをキャッシュ内に有することができ、より多くのリソースを有するデバイスは、より大きいキュー／より多くの拡張メタデータをキャッシュ内に有することができる。帯域幅はまた、例えば、ビデオバッファが維持されているときにのみ、拡張メタデータが許容される場合に考慮されてもよい。同様に、データプランは、考慮されてもよく、限定されている場合にはユーザ入力を介して決定されてもよく、例えば、そうすることがユーザにコストを負担させる場合には、特に望まれない限りメタデータをダウンロードしない。

[00100]上述したように、図１０のように、キャッシュおよび除去のために拡張メタデータノードを個別に処理する代わりに、拡張メタデータノードのグループを一緒に処理することができる。例えば、シーン全体の拡張メタデータノードを含むサブグラフは、キャッシュから一緒に追出されることに関して１つのユニットとして（および、場合によってはキャッシュに追加されるときには１つのグループとして）扱われてもよい。どのノードが一緒にグループ化されるかのようなデータは、例えば、ノードとしてキャッシュされないが、グループが追出されるまでトラッキングデータ構造８９４（図８）の一部として保存される、特別な情報「メタノード」などとして、拡張メタデータノードとともにストリーミングされてもよい。

[00101]理解されるように、ここでは、ストリーミングされたビデオに関連するメタデータをストリーミングするか、またはそうでなければダウンロードし、ユーザが、拡張されたユーザ体験のためにメタデータと選択的にインタラクトすることを可能にする技術が説明される。ユーザは、マップ、同じシーンの異なるカット、同じカットの異なるカメラビュー、イベント記述（テキストおよびキャスト／クルーインタビュー）、俳優、伝記テキストおよびインタビューのようなキャラクタ情報、この俳優（またはキャラクタ）がどのシーンに登場したかのサマリなどのデータを見るために、任意のリンク間でナビゲートするか、グラフノード上で直接ピボットする（ｐｉｖｏｔ）ことができる。

[00102]グラフは、現実世界（カメラ、実際のロケーションおよび俳優）などの異なる環境と、架空の世界およびキャラクタなどの代替ユニバースとの関係を可能にする。架空の世界を互いに関連付けることができる。視聴者は、イベントが最終バージョンからカットされたとしても、リンクをたどることによってイベントを見ることができる。グラフは、リッチサーチを可能にする。映画および／またはエピソードのサマリまたはハイライトは、１または複数の選択基準に基づいて関連コンテンツを自動的に生成することによって、視聴者のためにまとめられてもよい。

[00103]１または複数の態様は、ビデオの部分を拡張メタデータのサブセットと関連付けることを対象とし、拡張メタデータのサブセットの各々は、ビデオの対応する部分における少なくとも１つのアクションを記述する。ビデオをクライアントデバイスにストリーミングする際に、ビデオのどの部分がストリーミングされているかを決定し、ストリーミングされているビデオの部分に対応する拡張メタデータの選択されたサブセットを選択し、拡張メタデータの選択されたサブセットをクライアントデバイスにダウンロードすることがここで説明される。

[00104]拡張メタデータの選択されたサブセットをクライアントデバイスにダウンロードすることは、ストリーム中の拡張メタデータのサブセットを、ストリーミングビデオストリームと並行して、または実質的に並行してストリーミングすることを含んでもよい。

[00105]拡張メタデータは、グラフのノードとして構成可能であってもよく、ビデオのどの部分がストリーミングされているかを決定することは、フレームのセットを決定することを含んでもよく、ストリーミングされているビデオの部分に対応する拡張メタデータの選択されたサブセットを選択することは、フレームのセットに基づいて少なくとも１つの拡張メタデータノードを選択することを含んでもよい。拡張メタデータの選択されたサブセットを選択することは、ビデオの対応する部分におけるアクションを記述する情報を含む少なくとも１つの拡張メタデータノードを選択することを含んでもよい。拡張メタデータの選択されたサブセットを選択することは、ビデオの対応する部分において、キャラクタもしくはロケーション、またはキャラクタとロケーションの両方を記述する情報を含む少なくとも１つの拡張メタデータノードを選択することを含んでもよい。

[00106]記載の技術は、拡張メタデータ内の情報をサーチするための要求を受け取ることと、要求に基づいてサーチ範囲を決定することと、サーチ範囲に基づいてサーチするための拡張メタデータの１または複数の範囲内サブセットを決定することと、要求における１または複数のサーチ基準に基づいて、一致情報について１または複数の範囲内サブセットをサーチすることと、サーチによって決定された任意の一致情報を識別する、要求に対する応答を返すこととを可能にする。

[00107]記載された技術は、サマリまたはハイライトビデオを生成する要求を受け取ること、サマリまたはハイライトビデオに対応する拡張メタデータの１または複数の関連サブセットを探し出す（ｌｏｃａｔｉｎｇ）こと、およびサマリまたはハイライトビデオを生成するために１または複数の関連サブセットにおける情報を使用することを可能にする。

[00108]さらに、クライアントデバイスにビデオをストリーミングする前に、例えば、クライアントデバイス上の拡張メタデータのサブセットの少なくとも一部の可視表現をレンダリングし、可視表現とのユーザインタラクションを可能にするために、拡張メタデータの少なくとも１つのサブセットを、ユーザインタラクションに基づいてクライアントデバイスにダウンロードしてもよい。

[00109]１または複数の態様は、ビデオコンテンツプロバイダのデータサービスを対象とし、データサービスは、ビデオをクライアントにストリーミングするように構成される。データサービスは、拡張メタデータノードに対応する情報をクライアントに送るようにさらに構成され、ビデオの部分に関連する拡張メタデータノードのサブセットを選択することと、クライアントにストリーミングされているビデオの部分に関連するサブセットを送ることとを含む。

[00110]拡張メタデータノードは、チャプタノード、シーンノード、カットノード、および／またはイベントノードのうちの少なくとも１つを含むことができる。ビデオの部分に関連する拡張メタデータノードのサブセットは、少なくとも１つの動詞および１つの名詞に対応する情報を有するビデオの部分を記述することができる。拡張メタデータノードは、両方がビデオの同一部分に関連する少なくとも２以上の代替ノードを含むことができる。

[00111]データサービスは、サーチ基準（ｓｅａｒｃｈ ｃｒｉｔｅｒｉａ ｏｒ ａ ｓｅａｒｃｈ ｃｒｉｔｅｒｉｏｎ）に一致する１または複数のビデオ部分を識別するために、拡張メタデータノードの少なくともいくつかをサーチするように構成され得る。データサービスは、サマリまたはハイライトビデオを生成するように構成されてもよく、サマリまたはハイライトビデオのための１または複数のビデオ部分を選択するために、拡張メタデータノードのうちの少なくともいくつかにおける情報にアクセスすることを含む。データサービスは、１または複数のデータソースからのデータを、拡張メタデータノードに組み立てるように構成されてもよい。

[00112]クライアントは、拡張メタデータノードのサブセットを受け取り、そのサブセットをクライアントグラフの一部としてキャッシュしてもよい。

[00113]１または複数の態様は、クライアントデバイスにおいてストリーミングされたビデオの部分を受け取り、クライアントデバイスにおいて拡張メタデータを受け取ることに向けられ、拡張メタデータは、ストリーミングされたビデオの部分に対応する。ここでは、拡張メタデータをクライアントデバイスキャッシュにキャッシュし、拡張メタデータにおける情報とのユーザインタラクションを可能にすることについて説明する。ストリーミングされたビデオの部分を受け取ること、およびストリーミングされたビデオの部分に対応する拡張メタデータを受け取ることは、クライアントデバイスにおいて並列して、または実質的に並列して行われ得る。少なくともいくつかの他の拡張メタデータは、拡張メタデータ追出ポリシに従ってクライアントデバイスキャッシュから除去され得る。

[00114]ここでは、サーチ範囲情報および１または複数のサーチ基準を含むサーチ要求を、拡張メタデータを提供するエンティティに送り、エンティティからサーチ結果を受け取る機能についても説明する。サーチ結果は、サーチ範囲内の拡張メタデータのサーチに基づくことができ、サーチ結果は、１または複数のサーチ基準を満たす少なくとも１つのビデオ部分を識別する情報を含む。

コンピューティングデバイスの例

[00115]ここで説明する技術は、プログラムおよびプロセスを実行することができる任意のデバイスまたはデバイス（マシン）のセットに適用することができる。したがって、パーソナルコンピュータ、ラップトップ、ハンドヘルド、ポータブル、および他のコンピューティングデバイス、ならびに携帯電話、タブレット／スレートコンピュータ、ゲーム／娯楽コンソールなどを含むあらゆる種類のコンピューティングオブジェクトが、ここで例示されたものを含む様々な実装に関連して使用するために考慮されることを理解することができる。物理および／または仮想マシンを含むサーバも同様に適切なデバイス／マシンである。したがって、以下の図１１で説明する汎用コンピューティングメカニズムは、コンピューティングデバイスの一例にすぎない。

[00116]実装は、デバイスまたはオブジェクトのためのサービスの開発者による使用のために、オペレーティングシステムを介して部分的に実装されることができ、および／または、ここで説明される様々な実装の１または複数の機能的態様を実行するように動作するアプリケーションソフトウェア内に含まれることができる。ソフトウェアは、クライアントワークステーション、サーバ、または他のデバイスなどの１または複数のコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストで説明することができる。当業者は、コンピュータシステムが、データを通信するために使用され得る種々の構成およびプロトコルを有し、従って、特定の構成またはプロトコルが限定的であると考えられないことを理解するであろう。

[00117]したがって、図１１は、ここで説明した実装の１または複数の態様を実装することができる適切なコンピューティングシステム環境１１００の一例を示すが、上記で明らかにしたように、コンピューティングシステム環境１１００は、適切なコンピューティング環境の一例にすぎず、使用または機能の範囲に関していかなる制限も示唆することを意図していない。さらに、コンピューティングシステム環境１１００は、例示的なコンピューティングシステム環境１１００に示されたコンポーネントのうちの任意の１または組合せに関連する任意の依存関係を有するものとして解釈されることを意図していない。

[00118]図１１を参照すると、１または複数の実装を実装するための例示的なデバイスは、コンピュータ１１１０の形態の汎用コンピューティングデバイスを含む。コンピュータ１１１０のコンポーネントは、処理ユニット１１２０、システムメモリ１１３０、およびシステムメモリを含む様々なシステムコンポーネントを処理ユニット１１２０に結合するシステムバス１１２２を含むことができるが、これらに限定されない。

[00119]コンピュータ１１１０は、通常、様々なマシン（例えば、コンピュータ）可読媒体を含み、コンピュータ１１１０などのマシンによってアクセス可能な任意の利用可能な媒体とすることができる。システムメモリ１１３０は、読み出し専用メモリ（ＲＯＭ）および／またはランダムアクセスメモリ（ＲＡＭ）などの揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体、ならびにハードドライブ媒体、光記憶媒体、フラッシュ媒体などを含むことができる。限定ではなく例として、システムメモリ１１３０は、オペレーティングシステム、アプリケーションプログラム、他のプログラムモジュール、およびプログラムデータを含むこともできる。

[00120]ユーザは、１または複数の入力デバイス１１４０を介してコンピュータ１１１０にコマンドおよび情報を入力することができる。モニタまたは他のタイプのディスプレイデバイスも、出力インタフェース１１５０などのインタフェースを介してシステムバス１１２２に接続される。モニタに加えて、コンピュータは、スピーカおよびプリンタなどの他の周辺出力デバイスも含むことができ、これらは、出力インタフェース１１５０を介して接続することができる。

[00121]コンピュータ１１１０は、リモートコンピュータ１１７０などの１または複数の他のリモートコンピュータへのロジック接続を使用して、ネットワーク環境または分散環境で動作することができる。リモートコンピュータ１１７０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノード、あるいは任意の他のリモートメディア消費または送信デバイスとすることができ、コンピュータ１１１０に関して上述した要素のいずれかまたはすべてを含むことができる。図１１に示すロジック接続は、ローカルエリアネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）などのネットワーク１１７２を含むが、他のネットワーク／バスを含むこともできる。このようなネットワーク環境は、家庭、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいて一般的である。

[00122]上述のように、様々なコンピューティングデバイスおよびネットワークアーキテクチャに関連して例示的な実装を説明したが、基礎となる概念は、任意のネットワークシステム、およびそのような技術を実装することが望ましい任意のコンピューティングデバイスまたはシステムに適用することができる。

[00123]また、アプリケーションおよびサービスがここで提供される技術を利用することを可能にする、同一または類似の機能、例えば、適切なＡＰＩ、ツールキット、ドライバコード、オペレーティングシステム、制御、スタンドアロンまたはダウンロード可能なソフトウェアオブジェクトなどを実装するための複数の方法がある。したがって、ここに記載する実装は、ＡＰＩ（または他のソフトウェアオブジェクト）の観点から、ならびにここで説明する１または複数の実装を実装するソフトウェアまたはハードウェアオブジェクトから考慮される。したがって、ここで説明される様々な実装は、全体的にハードウェアであり、部分的にハードウェアであり、部分的にソフトウェアであり、ならびに全体的にソフトウェアである態様を有することができる。

[00124]用語「例」は、例、事例、または例示としての役割を果たすことを意味するためにここで使用される。疑義を避けるために、ここに開示される主題は、そのような例によって限定されない。さらに、ここで「例」として説明される任意の態様または設計は、必ずしも、他の態様または設計よりも好ましいまたは有利であると解釈されるべきではなく、当業者に知られている等価な例示的構造および技術を排除することを意味しない。さらに、「含む（ｉｎｃｌｕｄｅ）」、「有する（ｈａｓ）」、「含有する（ｃｏｎｔａｉｎｓ）」という用語、および他の類似の用語が使用される範囲では、疑義を避けるために、そのような用語は、請求項で使用される場合に追加の要素または他の要素を除外することなく、オープンな移行語として「備える（ｃｏｍｐｒｉｓｉｎｇ）」という用語と同様に包括的であることが意図される。

[00125]上述のように、ここで説明される様々な技術は、ハードウェアまたはソフトウェアとともに、あるいは、適切な場合には、両方の組合せとともに実装され得る。ここで使用されるように、「コンポーネント（ｃｏｍｐｏｎｅｎｔ）」、「モジュール（ｍｏｄｕｌｅ）」、「システム（ｓｙｓｔｅｍ）」などの用語は、同様に、コンピュータ関連のエンティティ、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかを指すことが意図される。例えば、コンポーネントは、プロセッサ上で実行されるプロセス、プロセッサ、オブジェクト、実行可能なもの、実行スレッド、プログラム、および／またはコンピュータとすることができるが、これらに限定されない。例として、コンピュータ上で実行されるアプリケーションおよびコンピュータの両方がコンポーネントであり得る。１または複数のコンポーネントは、実行のプロセスおよび／またはスレッド内に存在することができ、コンポーネントは、１つのコンピュータ上に配置され、および／または２台以上のコンピュータ間に分散されることができる。

[00126]前述のシステムは、いくつかのコンポーネント間のインタラクションに関して説明されている。そのようなシステムおよびコンポーネントは、それらのコンポーネントまたは指定されたサブコンポーネント、指定されたコンポーネントまたはサブコンポーネントのうちのいくつか、および／または追加のコンポーネントを、前述のものの様々な順列および組合せに従って含むことができることを理解されたい。サブコンポーネントは、親コンポーネント（階層）内に含まれるのではなく、他のコンポーネントに通信可能に結合されたコンポーネントとして実装することもできる。さらに、１または複数のコンポーネントは、集約機能を提供する単一のコンポーネントに組み合わされてもよく、またはいくつかの別個のサブコンポーネントに分割されてもよく、管理層などの任意の１または複数の中間層は、統合された機能を提供するために、そのようなサブコンポーネントに通信可能に結合するように提供されてもよいことに留意されたい。ここに記載の任意のコンポーネントは、ここに具体的に記載されていないが、当業者に一般に知られている１または複数の他のコンポーネントとインタラクトすることもできる。

[00127]ここで説明される例示的なシステムを考慮すると、説明される主題に従って実装され得る方法は、様々な図のフローチャート／フロー図を参照しても理解され得る。説明を簡単にするために、方法は、一連のブロックとして示され説明されるが、いくつかのブロックは、ここで図示され、説明されるものとは異なる順序で、および／または他のブロックと同時に発生することができるので、様々な実装は、ブロックの順序によって限定されないことを理解されたい。非順次または分岐のフローがフローチャート／フロー図を介して示される場合、同じまたは類似の結果を達成する様々な他の分岐、フローパス、およびブロックの順序が実装され得ることが理解され得る。さらに、いくつかの図示されたブロックは、ここで説明される方法を実施する際にオプションである。

結論

[00128]本発明は、様々な修正および代替の構成が可能であるが、その特定の例示的な実装が図面に示され、上記で詳細に説明されている。しかし、本発明を開示された特定の形態に限定する意図はなく、逆に、本発明は、本発明の精神および範囲内にある全ての改変、代替の構成、および等価物を包含することが理解されるべきである。

[00129]ここで説明される様々な実装に加えて、他の類似の実装を使用することができること、または対応する実装の同じまたは同等の機能を、それから逸脱することなく実行するために、説明される実装に修正および追加を行うことができることを理解されたい。さらに、複数の処理チップまたは複数のデバイスが、ここで説明する１または複数の機能の性能を共有することができ、同様に、複数のデバイスにわたってストレージを有効化することができる。従って、本発明は、いかなる単一の実施にも限定されず、むしろ、添付の特許請求の範囲に従って、領域、精神および範囲において解釈されるべきである。

Claims (20)

1. ビデオの部分を拡張メタデータのサブセットと関連付けることと、前記拡張メタデータのサブセットの各々は、前記ビデオの対応する部分における少なくとも１つのアクションを記述し、
   前記ビデオをクライアントデバイスへストリーミングすることと、
   前記ビデオのどの部分がストリーミングされているかを決定することと、
   ストリーミングされている前記ビデオの前記部分に対応する、前記拡張メタデータの選択されたサブセットを選択することと、
   前記拡張メタデータの前記選択されたサブセットを前記クライアントデバイスにダウンロードすることと、
   を備える方法。
2. 前記拡張メタデータの前記選択されたサブセットを前記クライアントデバイスにダウンロードすることは、ストリーム中の前記拡張メタデータの前記サブセットを、ストリーミングビデオストリームと並行して、または実質的に並行してストリーミングすることを備える、請求項１に記載の方法。
3. 前記拡張メタデータは、グラフのノードとして構成可能であり、ここにおいて、前記ビデオのどの部分がストリーミングされているかを決定することは、フレームのセットを決定することを備え、ここにおいて、ストリーミングされている前記ビデオの前記部分に対応する前記拡張メタデータの選択されたサブセットを選択することは、前記フレームのセットに基づいて少なくとも１つの拡張メタデータノードを選択することを備える、請求項１に記載の方法。
4. 前記拡張メタデータの前記選択されたサブセットを選択することは、前記ビデオの前記対応する部分におけるアクションを記述する情報を含む少なくとも１つの拡張メタデータノードを選択することを備える、請求項３に記載の方法。
5. 前記拡張メタデータの前記選択されたサブセットを選択することは、前記ビデオの前記対応する部分において、キャラクタもしくはロケーション、またはキャラクタとロケーションの両方を記述する情報を含む少なくとも１つの拡張メタデータノードを選択することを備える、請求項３に記載の方法。
6. 前記拡張メタデータ内の情報をサーチするための要求を受け取ることと、
   前記要求に基づいてサーチ範囲を決定することと、
   前記サーチ範囲に基づいてサーチするための前記拡張メタデータの１または複数の範囲内サブセットを決定することと、
   前記要求における１または複数のサーチ基準に基づいて、一致情報について前記１または複数の範囲内サブセットをサーチすることと、
   前記サーチによって決定された任意の一致情報を識別する、前記要求に対する応答を返すことと、
   をさらに備える、請求項１に記載の方法。
7. サマリまたはハイライトビデオを生成する要求を受け取ることと、
   前記サマリまたはハイライトビデオに対応する前記拡張メタデータの１または複数の関連サブセットを探し出すことと、
   前記サマリまたはハイライトビデオを生成するために、前記１または複数の関連サブセットにおける情報を使用することと、
   をさらに備える、請求項１に記載の方法。
8. 前記ビデオを前記クライアントデバイスにストリーミングする前に、前記拡張メタデータの少なくとも１つのサブセットを、ユーザインタラクションに基づいて前記クライアントデバイスにダウンロードすることと、
   前記拡張メタデータの前記サブセットの少なくとも一部の可視表現を前記クライアントデバイス上にレンダリングすることと、
   前記可視表現とのユーザインタラクションを可能にすることと、
   をさらに備える、請求項１に記載の方法。
9. ビデオコンテンツプロバイダのデータサービスを備えるシステムであって、
   前記データサービスは、ビデオをクライアントにストリームするよう構成され、
   前記データサービスは、拡張メタデータノードに対応する情報を前記クライアントに送るようにさらに構成され、ビデオの部分に関連する前記拡張メタデータノードのサブセットを選択することと、クライアントに、ストリーミングされている前記ビデオの前記部分に関連する前記サブセットを送ることとを含む、システム。
10. 前記拡張メタデータノードは、チャプタノード、シーンノード、カットノード、もしくはイベントノード、またはチャプタノード、シーンノード、カットノード、もしくはイベントノードの任意の組合せのうちの少なくとも１つを備える、請求項９に記載のシステム。
11. 前記拡張メタデータノードは、両方が前記ビデオの同一部分に関連する少なくとも２以上の代替ノードを備える、請求項９に記載のシステム。
12. 前記ビデオの前記部分に関連する前記拡張メタデータノードの前記サブセットは、少なくとも１つの動詞および１つの名詞に対応する情報を有する前記ビデオの前記部分を記述する、請求項９に記載のシステム。
13. 前記データサービスが、サーチ基準に一致する１または複数のビデオ部分を識別するために、前記拡張メタデータノードの少なくともいくつかをサーチするように構成された、請求項９に記載のシステム。
14. 前記データサービスは、サマリまたはハイライトビデオを生成するように構成され、前記サマリまたはハイライトビデオのための１または複数のビデオ部分を選択するために、前記拡張メタデータノードの少なくともいくつかにおける情報にアクセスすることを含む、請求項９に記載のシステム。
15. 前記データサービスは、１または複数のデータソースからのデータを、拡張メタデータノードに組み立てるように構成される、請求項９に記載のシステム。
16. 前記クライアントは、前記拡張メタデータノードの前記サブセットを受け取りし、前記サブセットを、クライアントグラフの一部としてキャッシュする、請求項９に記載のシステム。
17. １または複数の機械可読記憶媒体であって、実行されると、
    クライアントデバイスにおいてストリーミングされたビデオの部分を受け取ることと、
    前記クライアントデバイスにおいて拡張メタデータを受け取ることと、前記拡張メタデータは前記ストリーミングされたビデオの前記部分に対応し、
    前記拡張メタデータをクライアントデバイスキャッシュにキャッシュすることと、
    前記拡張メタデータにおける情報とのユーザインタラクションを可能にすることと、
    を備えるステップを実行する、機械実行可能命令を有する、１または複数の機械可読記憶媒体。
18. 前記ストリーミングされたビデオの前記部分を受け取ることと、前記ストリーミングされたビデオの前記部分に対応する前記拡張メタデータを受け取ることは、前記クライアントデバイスにおいて並行して、または実質的に並行して行われる、請求項１７に記載の１または複数の機械可読記憶媒体。
19. 拡張メタデータ追出ポリシに従って、前記クライアントデバイスキャッシュから少なくともいくつかの他の拡張メタデータを除去することを備える、さらなる機械実行可能命令を有する、請求項１７に記載の１または複数の機械可読記憶媒体。
20. サーチ範囲情報および１または複数のサーチ基準を含むサーチ要求を、前記拡張メタデータを提供するエンティティに送ることと、
    前記サーチ範囲内の前記拡張メタデータのサーチに基づくサーチ結果を前記エンティティから受け取ることと、ここにおいて、前記サーチ結果は、前記１または複数のサーチ基準を満たす少なくとも１つのビデオ部分を識別する情報を含む、
    を備える、さらなる機械実行可能命令を有する、請求項１７に記載の１または複数の機械可読記憶媒体。

Images