IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ホーム ボックス オフィス, インコーポレイテッドの特許一覧

特開2022-137125拡張メタデータを含むビデオコンテンツグラフ
<>
  • 特開-拡張メタデータを含むビデオコンテンツグラフ 図1
  • 特開-拡張メタデータを含むビデオコンテンツグラフ 図2
  • 特開-拡張メタデータを含むビデオコンテンツグラフ 図3
  • 特開-拡張メタデータを含むビデオコンテンツグラフ 図4
  • 特開-拡張メタデータを含むビデオコンテンツグラフ 図5
  • 特開-拡張メタデータを含むビデオコンテンツグラフ 図6
  • 特開-拡張メタデータを含むビデオコンテンツグラフ 図7
  • 特開-拡張メタデータを含むビデオコンテンツグラフ 図8
  • 特開-拡張メタデータを含むビデオコンテンツグラフ 図9
  • 特開-拡張メタデータを含むビデオコンテンツグラフ 図10
  • 特開-拡張メタデータを含むビデオコンテンツグラフ 図11
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022137125
(43)【公開日】2022-09-21
(54)【発明の名称】拡張メタデータを含むビデオコンテンツグラフ
(51)【国際特許分類】
   H04N 21/235 20110101AFI20220913BHJP
   H04N 21/84 20110101ALI20220913BHJP
【FI】
H04N21/235
H04N21/84
【審査請求】有
【請求項の数】8
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2022105788
(22)【出願日】2022-06-30
(62)【分割の表示】P 2019566345の分割
【原出願日】2018-05-02
(31)【優先権主張番号】15/608,530
(32)【優先日】2017-05-30
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】303059369
【氏名又は名称】ホーム ボックス オフィス, インコーポレイテッド
(74)【代理人】
【識別番号】100108855
【弁理士】
【氏名又は名称】蔵田 昌俊
(74)【代理人】
【識別番号】100179062
【弁理士】
【氏名又は名称】井上 正
(74)【代理人】
【識別番号】100199565
【弁理士】
【氏名又は名称】飯野 茂
(74)【代理人】
【識別番号】100219542
【弁理士】
【氏名又は名称】大宅 郁治
(74)【代理人】
【識別番号】100153051
【弁理士】
【氏名又は名称】河野 直樹
(74)【代理人】
【識別番号】100162570
【弁理士】
【氏名又は名称】金子 早苗
(72)【発明者】
【氏名】グレゴリー・ジョン・ベリンハム
(72)【発明者】
【氏名】ウィリアム・エー.・マクナマラ
(72)【発明者】
【氏名】ブランドン・シー.・ファートワングラー
(57)【要約】      (修正有)
【課題】ビデオの部分を拡張メタデータのサブセットと関連付けて配信する方法を提供する。
【解決手段】データサービス110は、隠しストリーム内など、ビデオの一部を記述するイベントのような、ビデオに関連するメタデータをクライアントデバイス102に送ることを対象とする。拡張メタデータは、関係グラフの一部を構築するために使用されるノードを含む。これにより、関心のあるクライアントは、特徴再生とメタデータとのインタラクションを切り替えることができる。さらに、一致するビデオ部分を見つけるために、拡張メタデータのサーチを実行することができ、1または複数のビデオのサマリまたはハイライトを、拡張メタデータにおける情報にアクセスすることによって組み立てることができる。
【選択図】図1
【特許請求の範囲】
【請求項1】
ビデオの部分を拡張メタデータのサブセットと関連付けることと、前記拡張メタデータのサブセットの各々は、前記ビデオの対応する部分における少なくとも1つのアクションを記述し、
前記ビデオをクライアントデバイスへストリーミングすることと、
前記ビデオのどの部分がストリーミングされているかを決定することと、
ストリーミングされている前記ビデオの前記部分に対応する、前記拡張メタデータの選択されたサブセットを選択することと、
前記拡張メタデータの前記選択されたサブセットを前記クライアントデバイスにダウンロードすることと、
を備える方法。
【請求項2】
前記拡張メタデータの前記選択されたサブセットを前記クライアントデバイスにダウンロードすることは、ストリーム中の前記拡張メタデータの前記サブセットを、ストリーミングビデオストリームと並行して、または実質的に並行してストリーミングすることを備える、請求項1に記載の方法。
【請求項3】
前記拡張メタデータは、グラフのノードとして構成可能であり、ここにおいて、前記ビデオのどの部分がストリーミングされているかを決定することは、フレームのセットを決定することを備え、ここにおいて、ストリーミングされている前記ビデオの前記部分に対応する前記拡張メタデータの選択されたサブセットを選択することは、前記フレームのセットに基づいて少なくとも1つの拡張メタデータノードを選択することを備える、請求項1に記載の方法。
【請求項4】
前記拡張メタデータの前記選択されたサブセットを選択することは、前記ビデオの前記対応する部分におけるアクションを記述する情報を含む少なくとも1つの拡張メタデータノードを選択することを備える、請求項3に記載の方法。
【請求項5】
前記拡張メタデータの前記選択されたサブセットを選択することは、前記ビデオの前記対応する部分において、キャラクタもしくはロケーション、またはキャラクタとロケーションの両方を記述する情報を含む少なくとも1つの拡張メタデータノードを選択することを備える、請求項3に記載の方法。
【請求項6】
前記拡張メタデータ内の情報をサーチするための要求を受け取ることと、
前記要求に基づいてサーチ範囲を決定することと、
前記サーチ範囲に基づいてサーチするための前記拡張メタデータの1または複数の範囲内サブセットを決定することと、
前記要求における1または複数のサーチ基準に基づいて、一致情報について前記1または複数の範囲内サブセットをサーチすることと、
前記サーチによって決定された任意の一致情報を識別する、前記要求に対する応答を返すことと、
をさらに備える、請求項1に記載の方法。
【請求項7】
サマリまたはハイライトビデオを生成する要求を受け取ることと、
前記サマリまたはハイライトビデオに対応する前記拡張メタデータの1または複数の関連サブセットを探し出すことと、
前記サマリまたはハイライトビデオを生成するために、前記1または複数の関連サブセットにおける情報を使用することと、
をさらに備える、請求項1に記載の方法。
【請求項8】
前記ビデオを前記クライアントデバイスにストリーミングする前に、前記拡張メタデータの少なくとも1つのサブセットを、ユーザインタラクションに基づいて前記クライアントデバイスにダウンロードすることと、
前記拡張メタデータの前記サブセットの少なくとも一部の可視表現を前記クライアントデバイス上にレンダリングすることと、
前記可視表現とのユーザインタラクションを可能にすることと、
をさらに備える、請求項1に記載の方法。
【請求項9】
ビデオコンテンツプロバイダのデータサービスを備えるシステムであって、
前記データサービスは、ビデオをクライアントにストリームするよう構成され、
前記データサービスは、拡張メタデータノードに対応する情報を前記クライアントに送るようにさらに構成され、ビデオの部分に関連する前記拡張メタデータノードのサブセットを選択することと、クライアントに、ストリーミングされている前記ビデオの前記部分に関連する前記サブセットを送ることとを含む、システム。
【請求項10】
前記拡張メタデータノードは、チャプタノード、シーンノード、カットノード、もしくはイベントノード、またはチャプタノード、シーンノード、カットノード、もしくはイベントノードの任意の組合せのうちの少なくとも1つを備える、請求項9に記載のシステム。
【請求項11】
前記拡張メタデータノードは、両方が前記ビデオの同一部分に関連する少なくとも2以上の代替ノードを備える、請求項9に記載のシステム。
【請求項12】
前記ビデオの前記部分に関連する前記拡張メタデータノードの前記サブセットは、少なくとも1つの動詞および1つの名詞に対応する情報を有する前記ビデオの前記部分を記述する、請求項9に記載のシステム。
【請求項13】
前記データサービスが、サーチ基準に一致する1または複数のビデオ部分を識別するために、前記拡張メタデータノードの少なくともいくつかをサーチするように構成された、請求項9に記載のシステム。
【請求項14】
前記データサービスは、サマリまたはハイライトビデオを生成するように構成され、前記サマリまたはハイライトビデオのための1または複数のビデオ部分を選択するために、前記拡張メタデータノードの少なくともいくつかにおける情報にアクセスすることを含む、請求項9に記載のシステム。
【請求項15】
前記データサービスは、1または複数のデータソースからのデータを、拡張メタデータノードに組み立てるように構成される、請求項9に記載のシステム。
【請求項16】
前記クライアントは、前記拡張メタデータノードの前記サブセットを受け取りし、前記サブセットを、クライアントグラフの一部としてキャッシュする、請求項9に記載のシステム。
【請求項17】
1または複数の機械可読記憶媒体であって、実行されると、
クライアントデバイスにおいてストリーミングされたビデオの部分を受け取ることと、 前記クライアントデバイスにおいて拡張メタデータを受け取ることと、前記拡張メタデータは前記ストリーミングされたビデオの前記部分に対応し、
前記拡張メタデータをクライアントデバイスキャッシュにキャッシュすることと、
前記拡張メタデータにおける情報とのユーザインタラクションを可能にすることと、 を備えるステップを実行する、機械実行可能命令を有する、1または複数の機械可読記憶媒体。
【請求項18】
前記ストリーミングされたビデオの前記部分を受け取ることと、前記ストリーミングされたビデオの前記部分に対応する前記拡張メタデータを受け取ることは、前記クライアントデバイスにおいて並行して、または実質的に並行して行われる、請求項17に記載の1または複数の機械可読記憶媒体。
【請求項19】
拡張メタデータ追出ポリシに従って、前記クライアントデバイスキャッシュから少なくともいくつかの他の拡張メタデータを除去することを備える、さらなる機械実行可能命令を有する、請求項17に記載の1または複数の機械可読記憶媒体。
【請求項20】
サーチ範囲情報および1または複数のサーチ基準を含むサーチ要求を、前記拡張メタデータを提供するエンティティに送ることと、
前記サーチ範囲内の前記拡張メタデータのサーチに基づくサーチ結果を前記エンティティから受け取ることと、ここにおいて、前記サーチ結果は、前記1または複数のサーチ基準を満たす少なくとも1つのビデオ部分を識別する情報を含む、
を備える、さらなる機械実行可能命令を有する、請求項17に記載の1または複数の機械可読記憶媒体。

【発明の詳細な説明】
【関連出願への相互参照】
【0001】
[0001]この出願は、2017年5月30日に出願された「VIDEO CONTENT GRAPH INCLUDING ENHANCED METADATA」と題された米国特許出願第15/608,530号に基づきその優先権を主張し、その全体が参照によりここに組み込まれる。
【背景技術】
【0002】
[0002]クライアントユーザは、クライアントユーザが所望の選択を行うことができるデータアイテムのメニュー(例えば、ボタン、タイル、アイコン、および/またはテキスト)などのユーザインタフェースを介して情報とインタラクト(interact)することが多い。例えば、クライアントユーザは、映画またはテレビ番組などのコンテンツプロバイダによって提供されるビデオコンテンツを表すデータアイテムを含むスクロール可能なメニューを見て、視聴するための映画やテレビ番組を選択するメニューアイテムとインタラクトすることができる。
【0003】
[0003]一般に、比較的基本的な情報のみがユーザに利用可能とされる。例えば、ビデオ選択関連の例では、映画のタイトルに加えて、映画の関連データは、視聴のためにコンテンツを選択するかどうかを決定する際にユーザが有することを望むであろう、レーティング(rating)、映画を表す画像、プロットサマリ(plot summary)、主要なキャスト(cast)およびクルー(crew)情報などを含んでもよい(または含まなくてもよい)。
【0004】
[0004]一部のユーザは、選択決定を行うためにだけでなく、より多くの情報を所望するかもしれない。例えば、ある特定の毎週のテレビシリーズの熱心なファンは、次のエピソードを選択して視聴する可能性が高いが、俳優のインタビュー、ストーリー、実際の撮影場所(film locations)に関する情報などの追加のコンテンツにさらに関心がある場合がある。しかし、現在のところ、そのようなユーザは、一般に、望むものが他の第三者のソースから利用可能であることを調べるために、別個にインターネットを閲覧する必要がある。
【発明の概要】
【0005】
[0005]この概要は、以下の詳細な説明でさらに説明する代表的な概念の選択を簡略化した形で紹介するために提供される。この発明の概要は、請求される主題の重要なまたは本質的な特徴を特定することを意図したものではなく、請求される主題の範囲を限定するいかなる方法での使用も意図されていない。
【0006】
[0006]簡単に言うと、ここで説明する技術の1または複数の態様は、ビデオの部分を拡張メタデータのサブセットと関連付けることを対象とし、拡張メタデータの各サブセットは、ビデオの対応する部分における少なくとも1つのアクションを記述する。態様は、ビデオをクライアントデバイスにストリーミングすることと、ビデオのどの部分がストリーミングされているかを決定することと、ストリーミングされているビデオの部分に対応する拡張メタデータの選択されたサブセットを選択することと、拡張メタデータの選択されたサブセットをクライアントデバイスにダウンロードすることとを含む。
【0007】
[0007]他の利点は、図面と共に以下の詳細な説明から明らかになるであろう。
【0008】
[0008]ここに記載の技術は、例として示され、添付の図面に限定されず、添付の図面において、同様の参照番号は同様の要素を示す。
【図面の簡単な説明】
【0009】
図1】[0009]図1は、1または複数の例示的な実装による、クライアントユーザがインタラクトすることができる、拡張メタデータノードを含むグラフノードに対応するデータを取得するためにデータサービスと通信するクライアントデバイスの例示的なブロック図である。
図2】[0010]図2は、1または複数の例示的な実装による、拡張メタデータサブグラフを含むノードの例示的なクライアントグラフの一部を表現したものである。
図3】[0011]図3は、1または複数の例示的な実装による、例示的な拡張メタデータノードを含む例示的なクライアントグラフの一部を表現したものである。
図4】[0012]図4は、1または複数の例示的な実装による、拡張メタデータノード内で維持され得るいくつかの例示的な情報を表現したものである。
図5】[0013]図5は、1または複数の例示的な実装による、拡張メタデータイベントノードおよびサブイベントノード内で維持され得るいくつかの例示的な情報を表現したものである。
図6】[0014]図6は、1または複数の例示的な実装による、拡張メタデータを含む、ユーザが、選択のためのよりインタラクティブなデータを取得するために、グラフに基づいて要求を送るためにインタラクトすることができるユーザインタフェースの一例である。
図7】[0015]図7は、1または複数の例示的な実装による、ストリーミングビデオの1または複数の部分が、どのようにそれに関連付けられた対応する記述的拡張メタデータを有することができるかの一例である。
図8】[0016]図8は、1または複数の例示的な実装による、ビデオ(およびオーディオ)データに関連して、どのように拡張メタデータをクライアントデバイスにストリーミングすることができるかの例示的な表現である。
図9】[0017]図9は、1または複数の例示的な実装による、ビデオおよび付随する拡張メタデータをストリーミングするためにデータサービスが行うことができる例示的なロジック(logic)/ステップを示すフロー図である。
図10】[0018]図10は、1または複数の例示的な実装による、拡張メタデータをキャッシュするためにクライアントデバイスプラットフォームまたは他のソフトウェアによって行われ得る例示的なロジック/ステップを示すフロー図である。
図11】[0019]図11は、ここで説明する主題の態様を組み込むことができる、1または複数の例示的な実装による、例示的なコンピューティング環境を表すブロック図である。
【発明を実施するための形態】
【0010】
[0020]ここで説明する技術の様々な態様は、一般に、クライアントインタラクション(interaction)のための様々なデータをノードおよびエッジのグラフとして維持し、そのグラフを、ユーザにとって望ましい可能性が高い、何らかの形で、拡張メタデータで拡張することを対象とする。例えば、1つのビデオコンテンツ(例えば、映画またはテレビのエピソード(特徴と称されることもある)、ドキュメンタリ、ユーザがアップロードしたコンテンツなど)が視聴のために選択されると、そのコンテンツに対応する拡張インタラクティブな体験を提供するために、そのコンテンツに関連する拡張メタデータを、拡張メタデータノードセット(1または複数のノード)としてクライアントデバイスにダウンロードすることができる。より具体的な例として、ビデオコンテンツのある部分(例えば、一連のフレーム)の実際のビデオフレーム(例えば、ロマンチックなエピソード、戦闘(fight)など)に関連する記述情報は、ビデオに関連してクライアントデバイスにストリーミングされた1または複数の拡張メタデータノードを有することができ、1または複数のそのようなモードは、他の情報ノード、例えば、そのビデオの部分に現れる俳優のインタビュー、そのビデオの部分に関連する現実のまたは架空のマップ、カメラカットデータなどにリンクすることができる。これらの他の情報ノードは、さらに他のノードなどにリンクすることができる。したがって、ビデオは、それに対応するデータを、拡張されたインタラクティブなメタデータグラフノードセットとして維持することができ、ビデオの任意の部分は、通常、対応する関連する拡張メタデータグラフノードサブセットを有し、それは、関連するデータへの(ノードエッジを介した)リンクをさらに有することができる。
【0011】
[0021]1または複数の態様では、例えば、選択されたビデオに付随する隠しストリームにおいて、メタデータをダウンロードすることによって、ビデオコンテンツに関連するような拡張された追加の量のデータが、クライアントユーザに利用可能にされる。そのような付随する拡張メタデータは、一般に、ビデオコンテンツに対応し、通常、コンテンツプロバイダによってサポートおよび管理される情報であるが、いくつかの情報は外部から提供されてもよい。隠された、一般にビデオストリームと並列のデータストリームは、ビデオが再生され得る前に、再生を遅延させ得る、大量となり得るデータをダウンロードしなければならないことを回避する。隠しストリーム(hidden stream)は、別個のストリームであってもよく、および/または付随するパケットヘッダデータなどは、受け取ったデータブロックがビデオ再生データであるか、または何らかの拡張メタデータであるかを指定することができる。
【0012】
[0022]拡張メタデータの一例として、特徴の選択のために従来のメタデータ(例えば、タイトル、画像URL、レーティング、クレジットなど)のみを提供するのではなく、一旦特徴が選択されると、実際のビデオに加えて、キャラクタ(characters)、イベント、マップ、フォークロア(folklore)、背景(backstories)などに関連するより複雑であり、場合によっては特徴のないメタデータもダウンロードすることができる。これにより、関心のあるクライアントは、より多くの情報を探索する(explore)ことができるとともに、ビデオを再生し、通常の再生モードでビデオ再生を視聴することと、メタデータとインタラクトすることとの間で切り替えることができる。例えば、特定のエピソードの視聴者は、再生を一時停止し、関連するシーンサイト(scene sites)のマップを見て、特定の俳優がいる現在のシーンにおける他の特徴を見るなどのためにインタラクトすることができる。あるいは、視聴者は、拡張コンテンツと同時に再生を視聴するために、拡張メタデータの可視表現を有する視聴画面の部分を(少なくとも一時的に)専用化および/またはオーバーレイ(overlay)してもよい。
【0013】
[0023]さらに、コンテンツのある部分を選択することなく、および/または拡張メタデータの任意の並列(または事前)ダウンロードを行うことなく、視聴者は、データサービスの利用可能なコンテンツ全体のいくつかのサブセットに関連する拡張メタデータのためにデータサービスをサーチ(search)することができる。例えば、視聴者は、特定のシリーズを示し、そのシリーズのキャラクタXが剣闘(swordfight)に参加するエピソード、シーン、カット、および/またはイベント(例えば、カット内の)をサーチすることができる。そのようなサーチを用いて、視聴者は、インタラクティブなリストを介して個々に選択可能な関連するビデオ部分、またはそれらのすべてを一緒に視聴する(またはそれらのいくつかのさらに狭いサブセットを視聴する)ための連続ビデオストリームにさらに直接的にコンパイルされた(compiled)ビデオ部分などの、そのキャラクタの剣闘イベントのコンパイルを取得することができる。ここで使用されるように、ビデオコンテンツは、任意の方法を含む任意の数の方法で分割することができ、「チャプタ」、「シーン」、「カット」、「イベント」などのビデオコンテンツ分割を指す用語は、ここでは一般的な意味でのみ使用され、フィルム製造技術で時々使用されるような厳密な定義を正確に伝えることを意図しないことに留意されたい。
【0014】
[0024]一実装例では、各イベント(またはいくつかのイベント)が、情報でタグ付けされた、またはイベントを記述する他の情報にリンクされた拡張メタデータノードを備えることによって、リッチサーチ(rich searches)を達成することができる。ここで使用される「イベント」は、一般に、ビデオコンテンツの比較的細かいレベルの粒度であり、例えば、カットは、1または複数のイベントで構成されてもよく、シーンは、1または複数のカットで構成されてもよく、シリーズのシーズンのエピソード、シリーズ全体自体、映画のチャプタ、映画全体、映画および同様の映画を含むジャンルなど、より高いレベルまで、利用可能なコンテンツのデータサービスの完全なセットまで、などであることに留意されたい。さらに、イベント内にサブイベントを有すること、イベント内に複数のカットを有することなども可能であり、さらに、サブイベントよりも粒度の高いものを有すること、例えば、単一のビデオフレームまたはその画像まで有することも可能である。
【0015】
[0025]1または複数の実装では、ビデオ部分(例えば、イベント)記述は、一般に、名詞および動詞、例えば、シリーズZ、シーズン2、エピソード6、シーン8、カット3、イベント2:[キャラクタ=A、キャラクタ=B、ロケーション(location)=城・・・、アクション=口論(argument)、アクション=戦闘、アクション=剣闘、アクション=流血の争い(gore)・・・]で記述され得る。名詞および動詞は、限定された語彙を有することができ、シソーラス、辞書などを介して語彙にマッピングされたより多くのサーチ語を有する。名詞は、サーチ結果がより正確になるように動詞に結び付けられてもよい。上記の例を使用すると、キャラクタX、YおよびZは、キャラクタXおよびYが剣闘に参加するが、キャラクタZが参加しないイベントに現れるかもしれない。したがって、キャラクタZの剣闘を有するイベントのサーチは、キャラクタXおよびYの名詞が剣闘の動詞に結び付けられ、キャラクタZが結び付けられない場合、このイベントを返さない。形容詞および/または副詞、例えば、[「大声の」ダイアログ(dialog)、「残虐な(bloody)」戦闘]などを使用することもできる。
【0016】
[0026]シーンカットおよび/またはイベントは、典型的には、関連するロケーションを有するが、関連するキャラクタを有さなくてもよい。例えば、嵐の海のシーンは、場合によっては、必ずしも必要ではないが、1または複数の暗示されるキャラクタに対する将来のトラブルの前兆を示すことができる。ロケーションと共に、シーンカットおよび/またはイベントは、典型的には、ノードの識別されたアクションが「静止」、「カメラパン」、「カメラズーム」等である場合であっても、関連するアクションを有する。例えば、シーンは、動きがほとんどまたは全く生じない穏やかな草原を示すことができる。
【0017】
[0027]階層的に配置されたデータ構造は、いくつかの同様の拡張メタデータを提供することができ、したがって、1つの可能な実装であるが、グラフは、一般に、任意のノードが任意の他のノードにリンクすることを可能にし、したがって、より大量の情報へのアクセスを提供することを可能にすることによって、より高い柔軟性を有することができる。例えば、データサービスは、任意のメタデータノードを、コンテンツプロバイダによって利用可能にされ、サポートされるコンテンツを含む、コンテンツまたは拡張コンテンツを表す任意の他のノードにリンクすることができる(独立した第三者ソースとは対照的に、第三者ソースとともに、または第三者の情報が信頼でき、十分にサポートされる場合などは独立して)。より具体的な例として、コンテンツプロバイダは、複数の異なるカメラカットからキャプチャされた同じシーン、撮影されたが公開版から除去されたシーン、代替のシーン、ある国で公開されたが別の国で公開されていないシーンなどを見ることを可能にする拡張コンテンツを提供することができる。これを達成することができる1つの方法は、コンテンツの同じ部分(例えば、カメラ1イベントノードおよびカメラ2イベントノード)に対して代替のメタデータノードを有することである。代替のシーン、カットおよび/またはイベント(例えば、映画に対する異なるエンディング)は、例えば、ハッピーエンディングシーン・メタデータノードにおける情報または、悲しい(sad)エンディングシーン・メタデータノードにおける情報を介して、ユーザに対して選択可能にされ得る。レーティング等または、視聴者の年齢や嗜好情報は、あるシーン、カットまたはイベントの情報を含む異なるメタデータノード内の情報を参照することによって、別のものではなくそのシーン、カットまたはイベントを自動的に選択するために使用してもよい。
【0018】
[0028]拡張メタデータを用いて、視聴者は、ディレクタ(director)によって選択されたもの、または、同様のプロファイル/人口統計を有するものを含む他の視聴者によって何らかの方法で選択されたもののような、エピソードのハイライト/サマリのみを見ることを選択することができる。例えば、ビデオのストリーミングにおいては、コンテンツプロバイダに知られている視聴者の情報、例えば、チャプタ選択、巻き戻しおよび早送りデータ、以前のサーチ等、並びに、ソーシャルメディア入力などの外部情報がある。視聴者の行動およびフィードバックは、他の視聴者がエピソードのハイライトに関して最も重要であると考えるものを決定するために使用するために利用可能であることが多い。
【0019】
[0029]ここに示した実施例のいずれもが非限定的であることを理解されたい。例えば、いくつかの例は、映画、テレビ番組、ドキュメンタリなどを配信するストリーミングサービスからのビデオコンテンツ(オーディオを含む)のクライアント選択/サーチに関連するメタデータを参照する。しかしながら、ここで説明される技術は、任意の特定のタイプのコンテンツまたはメタデータとは独立しており、オブジェクトなどの可視表現としてそのようなメタデータを提示する任意の特定のユーザインタフェースとも独立している。したがって、ここで説明される実施形態、態様、概念、構造、機能、または例のいずれもが非限定的であり、本技術は、一般にデータ通信およびデータ処理において利益および利点を提供する様々な方法で使用され得る。
【0020】
[0030]1または複数の実装では、ノードのグラフが各クライアントによって構築され、各グラフノードは、データサービスを介して利用可能な基礎データの一部を表す(ここで使用されるように、「グラフ」は、ノードおよびエッジとして視覚的に表されるかどうかにかかわらず、ノード間の関係によって形成される)。所与のクライアントのためのノードのセットは、そのクライアントに現在関連する利用可能なデータサービスのデータのサブセット、例えば、クライアントユーザインタフェースが表示するもの、通常、現在表示されていない、いくつかのキャッシュされたノード、および、おそらく表示可能ではないが他のノードのためのデータを維持するノードを含む。
【0021】
[0031]したがって、ユーザインタラクションおよび自動化されたプロセスに基づいて、関連するノードのグラフを使用して、クライアントソフトウェアプラットフォームは、1または複数のグラフノードに対して、必要に応じてそれらのデータを取得するための要求を行う。クライアント要求は、データサービスの要求処理部分、例えば、インターネットを介してクライアントに結合されたクライアントインタフェース・フロントエンドデータサービスに対するものであってもよい。フロントエンドデータサービスは、各要求を解釈し、1または複数の実装では、フロントエンドキャッシュから、またはバックエンドキャッシュおよび/またはバッキングデータソース(backing data sources)からを含むバックエンドデータサービスを介して取得することができる、要求されたデータで応答する。このようにして、クライアントソフトウェアは、必要に応じて、一般に、リソース使用に関して非常に効率的であり、迅速な応答を得る、クライアントグラフの関連部分を構築する。グラフノードは、クライアントにおいてキャッシュされてもよく、それによって、データが必要とされるとき、クライアントプラットフォームは、まず、データサービスの要求処理部分に要求を行うことなく、クライアントキャッシュデータを使用することを試みてもよい。
【0022】
[0032]図1は、クライアントグラフを形成するために、拡張メタデータノードを含む、グラフノードについてのクライアント要求を処理するために使用され得る例示的なコンポーネントを表すブロック図である。一般に、クライアントグラフは、ルート(ホーム)メニュー、ジャンルメニュー、シリーズメニューなどを表すノードなどの、ユーザインタフェースの何らかのインタラクティブな部分を表すユーザインタフェースノードのセットを含む。クライアントデバイスは、少なくともメモリが許す限り、インタラクティブコンテンツを表すために現在使用されていないノードをキャッシュすることができる。例えば、対応するジャンルノードを有する「ジャンル」メニューは、他のインタラクティブ要素の中で「コメディ」インタラクティブ要素(対応するコメディノードを有する)を含むことができ、ユーザが「コメディ」メニューにナビゲートし(navigates)、次いで「ジャンル」メニューに戻る場合、ユーザがメニューの中でナビゲートするときにそれらを再ダウンロードすることを回避するために、ジャンルメニューおよびその他の子ノードをキャッシュすることができる。
【0023】
[0033]しかしながら、拡張メタデータノードは、この時点でダウンロードされる必要はないことに留意されたい(例えば、非常に人気のある番組について、または以前のユーザ挙動に基づいて例外が存在してもよい)。代わりに、ストリーミングビデオコンテンツのように、選択された特徴ノード等に対して再生が選択されたとき、またはユーザサーチまたは他の特定の要求に応答して、拡張メタデータノードがダウンロードされる。
【0024】
[0034]図1に例示されるように、クライアントデバイス102は、グラフ関連要求108を含むグラフノード106をデータサービス110から受け取るクライアントプラットフォームソフトウェア104を実行する。クライアントデバイス102は、最初に、例えば、クライアントデバイス102のクライアントユーザがデータサービス110で認証すると、タイプされたノードに対応する1または複数の開始ノードを自動的に受け取ることができる。例えば、ユーザがクライアントデバイス102にログインすると、認証の成功次第、クライアントデバイス102は、クライアントプラットフォームソフトウェア104が予期する(expects)、ユーザグラフノード、ルートグラフノードなどを受け取ることができる。このようにして、クライアントプラットフォーム104は、ユーザが他のロケーションにナビゲートすることができるボタン、アイコン、タイルなどを有するホーム/ルートメニューなどのルートノードに基づくルートメニューなどをレンダリングすることによって、初期ユーザインタフェース要素を提示することができる。1または複数の実装では、ルートグラフノードがインタラクティブユーザインタフェース112の開始点であるので、ルートグラフノードに加えて、ルートグラフノードによって参照される1または複数のノードを、事前にクライアントに自動的に通信することができる。しかしながら、これは1つの可能な最適化に過ぎず、代替的に、クライアントデバイスは、スタートアップ時のルートグラフノード、およびルートグラフノードの子であるノード等を含む、任意の必要なデータを要求するように構成されてもよい。
【0025】
[0035]1または複数の実装では、クライアントソフトウェアプログラムのUI要素などは、ノードについて、または基礎データがどのように維持、編成、検索などされるかについて知る必要なく、(例えば、データサービスレベルで)クライアントプラットフォームにデータアイテムを要求してもよい。例えば、テレビ番組を表すタイルオブジェクトは、(1または複数の実装ではグラフノードIDでもある)タイトルIDに対応するタイトルの要求をクライアントプラットフォームソフトウェアに直接送ることができ、そのタイトルを得る。理解されるように、UIレベルの下で、クライアントプラットフォームソフトウェアは、そのIDに対応する(特徴タイプ)グラフノードからタイトルを取得し、グラフノードデータは、クライアントキャッシュから取得することができ、キャッシュされていない場合には、ここで説明するように、データサービスからグラフノードを要求することによって取得することができる。
【0026】
[0036]上述のように、各ノードは、グラフ114を形成する1または複数の他のノードを参照することができる(例えば、一般にクライアントキャッシュ116または他の適切なデータストレージ内に維持される)。クライアントグラフ114は、ノードがインタラクティブユーザインタフェース112上のオブジェクトの可視表現としてレンダリングされるときなど、必要に応じてこれらの他のノードのデータを取得することによって構築される。グラフノードデータの例示的な可視表現は、メニュー、タイル、アイコン、ボタン、テキストなどを含んでもよい。例えば、すぐ必要となるであろう統計的な可能性に基づき、実際に必要となる前に、1または複数のノードを前もってキャッシュすることが可能である。例えば、ノードXYZを取得する多くのユーザは次にノードEFGを求める傾向があるので、ノードXYZがダウンロードされるとき、ノードEFGを取得することもできる。
【0027】
[0037]さらに、理解されるように、あるグラフノード、典型的には拡張メタデータグラフノードは、ビデオコンテンツと共にクライアントデバイス102に自動的にストリーミングされ得る。例えば、あるシーンのようなビデオコンテンツのある部分は、そのグラフに含めるためにクライアントデバイス102に自動的にストリーミングされるその特定の部分を記述する拡張メタデータグラフノードを有することができる。これにより、クライアントユーザは、要求に応じてこれらの拡張メタデータグラフノードを要求することなく、ビデオ部分に関連する拡張メタデータグラフノードと何らかの方法でインタラクトするように切り替えることができ、これらは、高効率のユーザインタラクションのために、有利なことにクライアントデバイスグラフ114/キャッシュ116に既に存在する。
【0028】
[0038]一般に、クライアントグラフ114は、データサービス110から利用可能なデータ全体のクライアント関連サブセット(client-relevant subset)を含む(データサービスで利用可能なデータは、実際にどのように維持されるかに関わらず、仮想グラフ全体と考えることができる)。クライアントプラットフォーム104では、基礎データがクライアントグラフ114を形成し、その少なくとも一部がユーザインタフェース112上の要素として表され得るので、ユーザは、非常に異なる種類のデータ間の関係、および/またはいくつかのユーザにとって無関係であると思われ得る関係を含む、(例えば、ストリーミングビデオサービスの)データサービス110が利用可能にすることを決定した、任意の関係についてのデータを受け取るためにインタラクトすることができる。時間とともに、データサービス110は、例えば、ユーザフィードバックに基づいて、および/または新しいノードおよび/またはグラフノードタイプが利用可能になると、新しい関係でリンクするために、必要に応じて、そのような参照を追加、削除、または変更することができる。
【0029】
[0039]ノード106を取得するために、クライアントプラットフォーム104は、例えば、クライアントインタフェース・フロントエンドデータサービス118を介して、インターネット120などのネットワークを介して、データサービス110とインタフェースする。様々なタイプのクライアントデバイスおよび/または様々なソフトウェアプラットフォームバージョンが、両方のエンティティが理解するプロトコルを介してフロントエンドデータサービス118と通信することを可能にするために、デバイスおよび/またはプラットフォームソフトウェアバージョン用にカスタマイズされ得るアプリケーションプログラミングインタフェース(API)122が存在し得る。
【0030】
[0040]フロントエンドデータサービス118は、クライアントプラットフォームソフトウェア104が予期する方法で、要求されたノード106を返す多数の負荷分散(load-balanced)物理サーバおよび/または仮想サーバ(別々に図示せず)を備えてもよい。グラフノードについての要求のいくつかは、クライアントプラットフォームソフトウェア104が単一のグラフノードにおいて予期する複数のサブ要求に対応してもよく、例えば、特徴(映画)を表すタイルグラフノードについての要求は、タイトル(テキスト)、URLなどの画像参照(image reference)、レーティング、プロットサマリなどについてのサブ要求(sub-requests)に対応してもよい。ユーザの「ウォッチリスト(watch list)」についての要求は、複数のタイルについてのサブ要求に対応してもよい。データサービス110は、グラフノードについてのクライアント要求に応答するために、各グラフノードのタイプに基づいて、場合によっては様々なソースから単一のグラフノードに、必要に応じてデータサブパーツをどのように取得し、組み立てる(assemble)かを理解する。
【0031】
[0041]対応するグラフノードは、複数のクライアントからの同様の要求を効率的に満たすことを可能にする、1または複数のフロントエンドキャッシュ124に含まれ得る。例えば、各負荷分散サーバは、頻繁に、または最近要求されたデータを含むメモリ内キャッシュを有してもよく、および/または、フロントエンドサーバによって共有される1または複数のフロントエンドキャッシュが存在してもよい。データは、典型的には、フルグラフノード(full graph node)(例えば、複数のサブ要求からのデータに対応するタイル)としてキャッシュされるが、フルグラフノードを提供するために集約されるサブパーツに少なくともいくつかのデータをキャッシュすることが可能である。
【0032】
[0042]要求されたデータの一部または全部は、フロントエンドキャッシュ124にキャッシュされなくてもよい(またはキャッシュされるが期限切れに(expired)されてもよい)。そのような必要とされるデータに関して、1または複数の実装では、フロントエンドデータサービス118は、バックエンドデータサービス132に、データ130についての要求128を行うように(例えば、イントラネットおよび/またはインターネットを含み得るネットワーク126を介して)結合される。
【0033】
[0043]バックエンドデータサービス132は、同様に、フロントエンドデータサービス118によって予期される方法で、要求されたデータを返す、いくつかの負荷分散物理サーバおよび/または仮想サーバ(別個に図示せず)を備えてもよい。要求されたデータは、1または複数のバックエンドデータキャッシュ134に含まれ得る。例えば、各負荷分散バックエンドサーバは、要求されたデータを含むメモリ内キャッシュを有してもよく、および/またはバックエンドサーバによって共有される1または複数のバックエンドキャッシュが存在してもよい。
【0034】
[0044]バックエンドデータサービス132に到達するが、いずれのバックエンドキャッシュ134からも満たすことができない要求については、バックエンドデータサービス132は、1または複数の様々なバッキングデータソース140(1)―140(n)に、データ138についての要求136を送るために、(例えば、イントラネットおよび/またはインターネット120を介して)さらに結合される。このようなデータソース140(1)―140(n)の非限定的な例は、キーバリューストア、リレーショナルデータベース(relational databases)、ファイルサーバなどを含むことができ、これらは、事実上任意の適切なフォーマットでデータを維持することができる。グラフノードデータについてのクライアント要求は、複数のサブ要求に対応することができ、これらのサブ要求は、データソースをバックアップするためのものであってもよい。データサービス110は、必要に応じて適切なフォーマットのデータについての要求を異なるバッキングデータソース140(1)―140(n)に行うように構成される。さらに、1つのデータストアのデータは、別のデータストアのデータをオーバーライドすることができ、例えば、テレビ番組のデータは、1つのデータストアから取得された一般的な画像URLを含むことができるが、「編集」のようなデータストアは、例えば、何らかの特徴のないエピソードについて、一般的な画像を異なる画像でオーバーライドすることができる。1または複数の実装では、非キャッシュ(non-cache)データソース140(1)-140(n)は、共通のキャッシュインタフェースを実装するラッパ(wrapper)を使用することができ、それによって、各リモートデータソース140(1)-140(n)は、バックエンドデータサービス132の観点から別のキャッシュのように扱われ得る。
【0035】
[0045]図2は、ルートメニューノード222およびユーザノード223を含む、簡略化されたユーザインタフェースグラフ220の例の概念を示す。ルートメニューノード222は、いくつかの例示的な子ノード224-226を有し、ユーザメニューノードは、(例えば、ユーザ指定のお気に入りとして)シリーズメニュー226の子でもあるシリーズノード235に結合される。各ノードは、例えば、表示画面上にレンダリングされると、メニュー、メニューアイテム、画像、テキスト、ビデオなどとして視覚的に表され得る。
【0036】
[0046]次に、子ノード224-226は、それぞれジャンルメニュー224のアクション、ロマンス、コメディノードに対応する子ノード230-232、および、シリーズメニュー226の「シリーズ」子ノード234、235などの子ノードを有してもよい。図2に示すように、典型的なシリーズメニューノードは、1または複数の「シーズン」子ノード、例えば、ノード237、238を有し、各シーズン子ノードは、そのシーズンのエピソードに対応する「エピソード」子ノード、例えば、ノード242および243を有する。なお、図2では、説明を明確にするために、いくつかの子ノード(例えば、アクションジャンル、シリーズZ、シリーズY/シーズン1についての子ノード)等は省略している。
【0037】
[0047]最終的に、サブメニューのユーザ選択などによってグラフをトラバースする(traversing)ことによって、再生可能なコンテンツアイテム(例えば、再生可能な映画を表すといった選択可能なメニューアイテム)の情報を含むノードを有するものに到達する。例えば、ノード240は、図2のある映画「X」を表す。選択可能なアイテムは、サーチクエリに応答して返されてもよい。
【0038】
[0048]図2の例では、ノード240は、再生ノード250および拡張メタデータノード252にリンクされる。ノード250の選択は、ビデオコンテンツの再生をもたらし(ブロック260)、一方、拡張メタデータノード252の選択は、利用可能であれば、ユーザが拡張メタデータグラフ262にナビゲートし、その拡張メタデータグラフ262内でナビゲートすることを可能にする。ここで説明されるように、ビデオコンテンツを再生するためのユーザ選択はまた、拡張メタデータグラフ262の少なくとも一部の並列または一般に並列のダウンロードを自動的にトリガすることができる。
【0039】
[0049]図3は、ノード332によって表されるエピソードの例示的な部分グラフ表現330を示す。エピソードビデオをどのように再生するかに関する情報、例えば、図2の再生ノード250に対応し得る、既に開始されたビデオの再生をどこで再開するかなどの、ビデオプレーヤによって必要とされる任意の情報は、ノード334に存在し得る。このような情報は、グラフ内のノードとして維持される必要はなく、この例ではノード334内に存在する。
【0040】
[0050]図3には、シーンノード338-340(この例では3つ)の親であるタイムラインノード336を含む、この例では一番上のノードを有する拡張メタデータグラフも示されている。タイムラインノードは、例えば、シーンの順序、ならびに、各シーン内のカットなどのさらなる情報をトラックすることができる。典型的には映画(および時にはエピソード)のような任意のコンテンツに対して、作者/ディレクタ/エディタ(editor)がコンテンツの部分をどのように分割することを望むかによって、チャプタノード等がシーンノードの上に(またはその代わりに)存在してもよい。
【0041】
[0051]この例では、図3のグラフ330は、シーンノード338ー340である。ノード338によって表されるシーン1は、子ノード341-343によって表される3つのカットに分割される。シーン2および3はそれぞれ、1または複数の類似の「カット」ノードを有してもよい。同じイベントノードが(エッジ参照データを介して)複数のカットノードに結び付けられてもよく、例えば、カット2ノード342およびカット3ノード343がそれぞれイベント1ノードE1にリンクされる(これは、グラフが階層よりも有利となり得る別の理由である)。あるいは、イベントノード(例えば、E4)は、複数のカットノード(例えば、C4、C5)に対する親ノードであってもよく、例えば、イベントノードは、シーンノードの直接の子であってもよい(例えば、イベント4ノードE4は、シーン3ノード340の子である)。例えば、キャラクタ間のダイアログなどの単一のイベントは、1つのキャラクタを示す1つのカットと、他のキャラクタを示す別のカットと、両方のキャラクタを示す可能性のあるさらに別のカットなどから構成され得る。対応するフレームデータは、任意のノードに保持される場合、非連続フレームのセットであってもよい。過度の複雑さを避けるために、必要に応じて、実際に同じ冗長データを含む別個の異なるノードを使用することができる。
【0042】
[0052]図3の例では、カット3(ノード343)が3つの異なるイベントノードE1-E3を有することが例示される。したがって、例えば、エピソードが架空の世界で展開されるストーリーを伝える場合、シーン1は1つの王国(kingdom)であり、シーン1のカット3は宮殿であり、カット内の別個のノードにより表されるキャラクタ登場(イベント1)、キャラクタ間の口論(イベント2)、戦闘(イベント3)などのイベントを有する。容易に理解されるように、シーンおよびカットは、ディレクタ/エディタなどによって、撮影中に既に決定されていることが多く、したがって拡張メタデータグラフ内の各シーンを表すノード、およびそのカットを有することは、実施するのが比較的簡単であることが多い。カット内の異なるイベントは、もしあれば、カットを、ここで例示される異なるアクション(登場、口論、戦闘)などの特定のピースに分割することを望むコンテンツプロバイダの従業員のチームなどによって、何らかの他の方法で決定されてもよい。理解されるように、カットノード(または場合によってはシーンノード)をイベントノードにさらに分割することにより、必要に応じて、リッチな(rich)、よりピンポイントのサーチ、より明確なビデオサマリ、他の関連コンテンツへのより正確なリンクなどが容易になる。
【0043】
[0053]イベントノードは、例えば、どのキャラクタが登場したか、イベントがどこで起こったか、イベント内で何が起こったかを含む、イベントについての特定の情報を含むことができる。上述のように、名詞および動詞は、イベントのこれらの態様を記述することができる。
【0044】
[0054]ここで説明されるように、拡張メタデータノードはサーチ可能であり、したがって、サーチエンジンによって理解される何らかの規則が必要とされ得る。例えば、サーチエンジンが各可能性のある関連ノードをトラバースするように、コンテンツの任意の部分は、少なくとも1つの単一のカットノードの親である少なくとも1つの子シーンノードを有する少なくとも1つの単一のチャプタノードによって表される必要があり、最下位レベルのノードまで同様である。あるいは、サーチエンジンが、最上部のノードから開始し、必要に応じて、子ノードのみに続くことを知っている規則を使用することができる。したがって、必要であれば、1つのノードのみが、コンテンツ全体の情報を含むことができ、そのカット内のチャプタ、シーン、カット、およびイベントの間のノードベースの区別はなく、それは、非常に短いビデオに適切であり得る。
【0045】
[0055]図4は、カットノード440が、イベントノード442および443を、それらのイベントノードを識別するエッジデータを介して、子のうちの2つとして含む例を示す。イベントノード442および443は、アクタ(actor)ノード445-447、マップノード449に対するエッジと、他のノードに対する可能性のある多くの他のエッジとともに示される。図4の簡略化された例には明示的に示されていないが、1または複数の実装におけるエッジ関連データは、任意の特定の関係を指定する情報を含むことができる。例えば、ノード440は、ノード442の親であるという情報を含むことができ、同様に、ノード442は、ノード440の子であるという情報を含むことができる。
【0046】
[0056]ノードの関連サブセット(relevant subset)は、現在選択されているビデオに関連する、および/またはサーチ可能なエピソードまたは映画のセットなどのコンテンツの関連するセット(connected set)に関連する様々なデータを含む。したがって、図4の例では、この例ではノード440によって表されるwwwとして識別されるカットの中には、ノード442、443によって図4において視覚的に表されるデータを有するイベントzzz、aaaaを含む、3つのイベントggg、zzz、aaaaがあることがわかる。イベントノード内の名詞および動詞は、他のノードから情報を取得するために、サーチされるか、インタラクトされてもよく、および/またはエッジが続いてもよい。
【0047】
[0057]図4の簡略化された例では、名詞は動詞に明示的に結合されないことに留意されたい。しかし、名詞を動詞にグループ化することによって、例えば、[アクション=戦闘(Fight) OR 剣闘(Swordfight)]AND[キャラクタ=ジョー(Joe)ORキャラクタ=モー(Moe)ORロケーション=宮廷(Palace) ORサブロケーション=階段(staircase)]などのブール演算子接続関係を含めることによって、そうすることは簡単である。いくつかの演算子は、明示的ではなく暗示的であってもよい。
【0048】
[0058]容易に理解されるように、実際の人間が読める名詞および動詞を含むノードの代わりに、コードを使用することができ、例えば、「戦闘」という用語に、各キャラクタ同様に、データサービス内で一意の何らかのアルファ/ニューメリック(alpha/numerical)コードを与えることができる。これは、ノードのデータを異なる言語辞書等に結び付けることを容易にする。同様に、全く同じ名前を有する二つのキャラクタまたは俳優を区別することができ、また、同じ名前を有する2つの映画(オリジナル映画とリメイク映画)、同じ名前を有する2つのロケーションなどを区別することができる。したがって、ここで使用されるように、ノードの情報(例えば、名詞、動詞、副詞、形容詞、あるアクション、ロケーション、俳優、タイトル、キャラクタなど)に保持されているものは、適切なテキスト/グラフィックス/オーディオ/画像データ/ビデオを取得することができる適切なデータセットにマッピングする実際のテキストまたはコードなどであってもよい。
【0049】
[0059]図4には示されていないが、キャプチャされたビデオイベントの簡単な説明がイベントノードに存在してもよい。例えば、ノード443については、「ジョーとモ―は、宮廷のボールルームで紹介され、口論になった後、宮廷の階段を下る剣闘になった」。記述を直接含む代わりに、そのような記述は、例えば、視聴者の好ましい言語に一致するオーディオおよび/またはテキストのデータストアへのURLといった、別のデータセットへの参照から得られてもよい。
【0050】
[0060]そのような情報を用いて、拡張メタデータグラフは、ユーザが、重要でリッチな情報を閲覧することを可能にし、また、リッチで、よりピンポイントのサーチを容易にする。コンテンツの現代の(contemporary)サーチは、一般に、タイトル、俳優、ジャンル、他の非常に高いレベルの情報によるサーチに限定されると考える。例えば、「ゲーム・オブ・スローンズ(登録商標)」(HBO(登録商標)シリーズ)の視聴者は、「キングスランディング」(ゲーム・オブ・スローンズ(登録商標)における架空の首都)における全てのシーンを見つけるためのサーチを望む場合がある。現在、従来のメタデータを使用して、ユーザは、「キングスランディング」がエピソードのタイトル内にたまたまある場合に、いくつかのエピソードのセットを取り出すことができる。
【0051】
[0061]対照的に、拡張メタデータグラフでは、視聴者は、サーチエンジンが、特定の拡張メタデータノード、例えば、図4の例ではイベントノードで記述されるコンテンツまでを見つけることを要求することができる。拡張メタデータグラフを用いて、ユーザは、例えば、シリーズ全体、そのシリーズ内のシーズン、特定のエピソード、またはエピソードのサブセット(例えば、シーズン1および2のすべてのエピソード等)など、サーチするコンテンツの任意のセットの範囲を指定することができる。サーチ範囲が決定されると、サーチは、例えば、特定のキャラクタXが「キングスランディング」に登場したすべてのイベントを見つける、イベントレベルといった任意の適切なレベルまで下げることができる。このために、例えば、サーチクエリに関して、そのエピソード内で関連するシーン、カット、および/またはイベントが発生したかどうかを決定するために、拡張メタデータグラフを含むデータサービスのグラフにおけるすべてのエピソードリンク(episode-linked)ノードに対してサーチを実行することができる。
【0052】
[0062]上記の例を使用して、ユーザは、したがって、キャラクタXが登場したかどうかに関して、エピソードの全シリーズ、またはエピソードの1つのシーズン(またはシーズンのサブセット)、または単一のエピソード内をサーチすることができる。ここで説明するように、視聴者は、例えば、キャラクタXが戦闘に参加するなどの何らかのアクションを行ったシーンを見つけるために、そのようなサーチをさらに絞り込むことができる。適切なメタデータがポピュレートされる(populated)(またはリンクされる)場合、拡張メタデータグラフ内のメタデータは、キャラクタXが戦闘に参加した各エピソードID、シーン番号、カット番号、およびそのような各イベントの正確なフレーム範囲などに関する情報を提供するとともに、そのようなクエリに回答することができる。別の例示的なサーチとしては、ある有名な俳優Wが馬に乗っている(サーチ範囲内で要求された基準に一致する俳優および行動)、ジャンル「西洋」(サーチ範囲)のすべての映画をサーチすることがある。
【0053】
[0063]別の態様に移ると、ユーザ指定のサーチ基準に加えて、拡張メタデータグラフ内の情報に基づいて、関連するビデオコンテンツを自動的に見つけ出し、生成/コンパイルすることによって、エピソード(または複数のエピソード)のハイライト/サマリを、視聴者のためにまとめることができる。サマリは、各ユーザの選択、示された嗜好、他の視聴者のフィードバック、コンテンツプロバイダチームの嗜好などに従って(例えば、重要であるとみなされるイベントにフラグを立てることによって)、コンテンツを選択するために、拡張メタデータグラフノードを自動的にサーチすることによって組み立てられてもよい。例えば、イベントノードのデータは、「サマリ」の「はい」または「いいえ」のフラグを含むことができ、それによって、エピソードサマリは、はいに設定されたフラグを含むイベント、例えば、[シーン1、カット2、イベント3、シーン2、イベント8、カット3、4、・・・]を介して組み立てられてもよい。
【0054】
[0064]フラグの代わりに、ユーザが、あるユーザ指定の閾値を超えるイベントのサブセットを得ることができるように、何らかの「みなし(deemed)」サマリ/ハイライト重要度値(例えば、1から10の範囲)を各イベントノード(または他のノード)のメタデータ内に含めることができる(フラグまたは重要度値をノード内に維持する代わりに、そのようなデータを、例えば、別個のデータベースを介して、ノードに関連付けてもよい)。ノードに含まれる重要度値は、重要度値=2を含むイベント442のデータおよび重要度値=7を含むイベント443のデータを介して図4に例示される。繰り返すと、そのような値は、例えば、コンテンツプロバイダ(作者、ディレクタ、編集チーム等)による設定、ユーザ嗜好データ(「ハイライト戦闘および対戦(battles)」)によって設定される、収集されたユーザ履歴(ユーザは、戦闘イベントを巻き戻すことが多い)、他のユーザアクション(多くのユーザは、このイベントの再生を要求しており、現在の視聴者と同様の人口統計を有する可能性がある)など、任意の方法または組み合わせた数の方法で決定され得る。任意のノードに関するそのような重要度値などを決定するために、時刻、曜日、視聴者の人口統計、レーティング、現在のニュースイベント、ソーシャルメディアコンテンツなどの状態データを、他の方法の代わりに、または他の方法に加えて使用することもできる。例えば、ユーザベースハイライト重要度値、データサービス割当サマリ重要度値など、複数のそのような値が存在してもよい。
【0055】
[0065]サマリの生成に関して、例えば、サマリを作成すべきイベントの関連するセットに対して値セットが決定されると、そのようなサマリ値を使用する別の方法は、ユーザがそれを見るのに費やしたい時間に基づいてサマリを自動的に提供することである。例えば、ユーザは、最も重要なイベントの非常に高速(約2分)のサマリを要求することができ、データサービスは、所望の時間にほぼ合致する重要度閾値(例えば、サマリ値9および10を有するもののみ)を計算することができる。ユーザが5分を要求した場合、7を超えるサマリ値を有するもののみを計算することができ、例えば、要求された時間により近似するために、6の値を有するものに対して何らかのランダムまたは時間ベースの選択を行うことができる。あるいは、実際の時間とは無関係に、主要な(major)サマリ、中程度の(medium)サマリ、および主要でない(minor)サマリなどのいくつかの他の選択基準を、重要度値に基づいて組み立てることができ、例えば、主要なサマリは、値8-10を有するイベントを選択し、中程度のサマリは、値5-10を有するイベントを選択し、主要でないサマリは、値3-10を有するイベントを有する。包含的な決定を行うために、そのような値またはフラグを使用する任意の他の方法を使用することができる。
【0056】
[0066]サマリ/ハイライトビデオの自動選択は、イベントの選択および順序付けにおいて、場合によっては視聴者入力によって制約されるように、所望の任意の規則に従うことができ、例えば、コンテンツのオリジナルタイムラインに従う必要はない。例えば、実際のエピソードでは、サマリのパートBのシーン、カット、またはイベントの一部がパートAのそれらのいくつかに先行したとしても、1つのキャラクタ(またはサイト)の重要なシーンをサマリのパートAとし、その後にパートBとして別のキャラクタ(またはサイト)の重要なシーンを続けることができる。
【0057】
[0067]別の態様に移ると、図5は、イベント552を複数のサブイベントに分離する方法の表現であり、554および555とラベル付けされた、2つのサブイベントが示される。図5の例では、同じイベントが2つの異なるカメラ、例えば、キャラクタに対して1つは頭上から(overhead)、1つはアイレベル(eye-level)で撮影されたとする。したがって、このイベントに対して2つの(またはそれ以上の)異なるセットのビデオフレームが存在し、それぞれがサブイベントノード554または555によって表される。ユーザの嗜好または他の何らかの選択データ(例えば、時刻、最後に示されたカメラの反対のカメラ角度などの状態データ)を使用して、それらの間で選択すること、および/またはディレクタのデフォルト選択をオーバーライドすることができる。
【0058】
[0068]同様に、異なるカメラ角度から同じコンテンツを提供する代わりに、サブイベントは、所与のイベントについて示されるべき完全に異なるコンテンツを提供してもよい。例えば、ある視聴者は、映画に対してハッピーエンディングを得ることができ、別の視聴者は、悲しいエンディングを得ることができ、さらに別の視聴者は、未解決のエンディングを得ることができる。このような3つのエンディングのそれぞれは、拡張メタデータグラフ内の異なるサブイベントノード内で識別される関連フレームを有することができる。異なるコンテンツ間で選択するために、シーン/カット/イベントレーティングに対するユーザの年齢を使用してもよい。
【0059】
[0069]この例では、サブイベントの中から選択するために、実際のビデオデータが再生のためにバッファに挿入されるか、またはバッファから取り出される必要があるポイントに到達すると、拡張メタデータグラフは、どの実際のビデオデータ(例えば、フレーム)を使用するかを選択するためにデータサービスによって調べられ(consulted)てもよい。この決定は、代替ビデオストリームをダウンロードした後にクライアント側で行ってもよく、あるいは、送信前に1つのストリームまたは別のストリームを選択することによってサーバ側で行ってもよい。1または複数のバッファを介することを含む代替コンテンツ選択の概念は、本出願の譲受人に譲渡され、参照によりその全体が本明細書に組み込まれる、「STREAMING MEDIA STATE MACHINE」と題された米国特許出願第15/135,783号に記載されている。
【0060】
[0070]容易に理解されるように、図5に図示されたサブイベント554および555は、図4のイベントノード442および443のいくつかと同様に、冗長情報を含む。そのような冗長な情報は、親ノードの子ノードにおいて一貫している場合、親ノードにおけるその情報の単一のインスタンスで置き換えられてもよく、子ノードは、他のノードからサーチし区別するために、親ノードの情報を効果的に継承する。これは、サーチメカニズムなどが、共通して継承される可能性のあるデータを見つけるために、異なるレベルのノードをトラバースしなければならない可能性があるという点で、グラフをトラバースすること(例えば、サーチすること)を複雑にする可能性があるが、ある例では、グラフまたは部分グラフにおけるデータの全体量を大幅に低減する可能性がある。
【0061】
[0071]別の態様に移ると、拡張メタデータグラフは、特定のシリーズ、シーズン、またはエピソード(または映画、または映画のチャプタなど)の対応するメタデータに限定されない。図3で一般的に表されるように(また、図4におけるエッジデータを介して)、拡張メタデータグラフの任意のノード(および通常のクライアントグラフ)は、データサービスによって所望されるように、データサービスから取得可能な任意の他のノードにリンクされ得る。これは、俳優、実際の撮影場所(架空の王国は、拡張メタデータグラフを介して、それが撮影された欧州の実際のロケーションにリンクされてもよい)、実際のカメラなどを含む実世界のエンティティなどの概念を、キャラクタ、架空の場所(sites)、架空のマップ、視点(頭上または前方を向くカメラ角度)などの架空のエンティティと結び付けることを可能にする。したがって、例えば、任意の適切なノードのデータとインタラクションに対応する視聴者選択は、俳優の実名またはステージ名にリンクすること、あるシリーズの俳優のキャラクタから別のユニバース(universe)(例えば、シリーズまたは映画)の同じ俳優のキャラクタにリンクすることなどができる。そのようなエッジが存在する場合、ユーザは、グラフを介して、シーン、カット、および/またはイベントが撮影された実際のロケーション(例えば、マップ、写真など)に関する情報を見ることができ、次いで、ユーザは、元のビデオに戻ること、より拡張されたメタデータの中でナビゲートすることを選択すること、新しいビデオ(オリジナルビデオのサマリ、完全に異なるビデオ、完全に異なるビデオのサマリ)を開始することなどができる。
【0062】
[0072]さらに、拡張メタデータグラフは、架空のユニバース間のクロスオーバを可能にする。例えば、漫画のキャラクタに基づく映画は、時には、別の架空のユニバースのキャラクタによる1または複数の名場面(cameo)または「ゲストスター(guest star)」の登場を含む。ノード間のエッジは、このようなクロスオーバの登場をモデル化することができる。同様に、医療ドラマ、刑事ドラマ、および消防ドラマのようなテレビ番組は、例えば、刑事ドラマのゲストスターの負傷した警官キャラクタが医療ドラマで同じキャラクタを演じるように、互いのエピソードに入り込むキャラクタを有することがある。メタデータ内のノードを接続する適切なエッジを単に提供することによって、拡張メタデータグラフは、そのような架空のユニバースのそれぞれにおけるかなりの量の所望の情報と、現実世界における情報との間でナビゲートする直接的な方法をユーザに提供することができる。データサービスがそのような情報/コンテンツを拡張メタデータグラフへのリンクを介して利用可能にする場合、ユーザは、公開されたバージョンから編集されたコンテンツ(および場合によっては視聴コンテンツ)の情報を取得することができる。ユーザツールなどを介して、ユーザがクライアントのグラフに、他のノードへのエッジを含むカスタムデータを含む場合に、いくつかのノードをカスタマイズすることは可能である。
【0063】
[0073]要約すると、ユーザは、様々な方法で拡張メタデータグラフとインタラクトすることができる。ここで説明する1つの方法は、基準選択(criteria-selected)ノードに基づいてサマリ/ハイライトビデオを介してインタラクトすることである。別の方法は、例えば、自由形式テキストサーチを介して、または支援を用いて(例えば、有効なサーチ語のドロップダウンメニューなどから)サーチすることによる。サーチの範囲/開始点は、例えば、グラフの最上部(例えば、ルートまたはユーザ)メニューからルートメニューの下の任意のレベルまで、ユーザによって選択され得る。
【0064】
[0074]さらに別の可能なタイプのユーザインタラクションは、(少なくともいくつか)メタデータグラフノード/その中のデータのレンダリングされた可視表現を伴う。図6は、例えば、いくつかの子イベント(および/または、場合によっては子カット)ノードを有するシーンノードを含む例示的な拡張メタデータグラフの一部であるいくつかのデータに基づくものであってもよい、様々なメニューオブジェクト660(a)-660(d)の仮想ユーザインタフェースを示す。図6では、(例えば、ルートメニューからジャンルメニューへ、特定のジャンル選択へナビゲートすることによって到達される)ムービー選択メニュー630(a)は、映画または他の情報にリンクするインタラクティブタイル(場合によっては、テキスト以外の情報を含む)であり得る、多数のインタラクティブボタンを提供する。この簡略化された例では、映画選択メニュー660(a)から、ユーザは、タイトル「X」の映画を選択するために、タイルまたはボタン662とインタラクトし、ユーザがその映画に関する選択を行うことができるメニュー660(b)にナビゲートする。オプションとして、「再生(play)」オプション(ボタン664)、「詳細(more)・・・」オプション(例えば、ユーザが映画についてより多く読む/見ることができるボタン666)、および、この例では、映画に対応する拡張メタデータグラフノードセット内の情報へのアクセスをユーザに提供する「拡張コンテンツ」オプション(ボタン668)を含む。前メニューまたは他の画面(サーチ入力ページなど)に戻るようにナビゲートするための戻る矢印ボタンも示されている。
【0065】
[0075]メニュー660(b)から、この例では、ユーザは、各ボタンがその一部として代表画像を表示するボタン671-673によって表されるシーンのメニュー660(c)を示すように変更する「拡張コンテンツ」オプション(ボタン668)を選択する。簡潔にするために、この特定の例では、3つのシーンのみが利用可能であり、シーン3は、3つのイベントまたはカットを有する(例えば、チャプタはない)。
【0066】
[0076]この例において、ユーザは、シーン3(ボタン673)を選択し、ユーザが、例えば、各ボタンが付随するテキスト記述および代表的な画像を有する、ボタン675-677によって表されるシーン3内のイベント(またはカット)に対応する、より具体的なコンテンツを選択することができる、メニュー660(d)を提供する。ボタン675ー677のうちの1つを選択することは、例えば、シーンの詳細なテキストおよび/またはオーディオ記述、1または複数のさらなる画像、そのイベントのフレームまたはそのいくつかのサブセットだけを再生するための「部分再生」ボタンなどを提供することができる。「詳細・・・」ボタン678は、1または複数のさらなるメニューによって、シーン内の俳優の俳優データ、マップ、キャラクタデータなどにリンクすることなどによって、関連するメタデータとのさらなるインタラクションを可能にする。
【0067】
[0077]図6は、ユーザが、選択されたビデオコンテンツに関して拡張コンテンツメタデータノードセットを介して、より直接的にナビゲートすることができるとともに、選択されたビデオコンテンツに直接関連付けられたリンクを超えるリンク(ノードエッジ)をたどることによって他のメタデータノードにナビゲートすることができる、単純化した仮想的な方法の1つにすぎない。別の方法は、ここに記載されるようなものを含むサーチによるものであり、例えば、サーチの範囲(例えば、シリーズA、シーズン1)を選択し、その範囲内のサーチ語に一致するイベントを見つけることによるもの、またはサーチにサマリを生成させることによるものである。
【0068】
[0078]拡張コンテンツメタデータ情報とインタラクトするさらに別の方法は、ビデオ再生が行われている間に、またはある時点で一時停止/停止されている間に、インタラクトすることによる。この時点での拡張コンテンツは、任意の数の既知の方法で表示されてもよく、例えば、メインビデオを縮小し、メタデータを表示するために現在利用可能な画面サイズ制限(screen real estate)を使用すること、テキストおよび/またはグラフィックスの形でメタデータを)オーバーレイすること(例えば、ある程度の不透過率を有する)、メインビデオを拡張コンテンツメタデータのフルスクリーンに置き換えることなどによって、ビデオが表示されたメタデータと共に一時停止/停止されるか、または再生を継続する間に、表示されたデータとのインタラクションを可能にする。
【0069】
[0079]再生中にインタラクトすることを選択する場合、典型的なユーザは、最初に、ユーザが一時停止したときに示されている宮廷の間取り図、都市のマップなど、現在の再生位置に関連する少なくともいくつかのメタデータを見ることを望む。また、典型的なユーザは、インタラクションを開始するために長時間待つことを望まない。しかし、クライアントデバイスのストレージおよび帯域幅は限られているので、フルビデオに関連する拡張メタデータグラフ全体は、通常、クライアントデバイスにキャッシュされない。その代わりに、ビデオバッファと同様に、ストリーミングビデオの位置に現在関連する拡張メタデータグラフの部分を、並列または実質的に並列の隠しストリームなどでクライアントキャッシュにダウンロードすることができる。
【0070】
[0080]図7は、ストリーミングビデオ770を示し、その各部分(例えば、フレーム772のセットなど)が、そのストリーミングビデオのための拡張メタデータノードセット776のサブセット774に対応する。図7の例では、クライアントキャッシュが、クライアントデバイスのビデオバッファ内に現在あるビデオデータに一般に対応する拡張メタデータと、場合によっては、直近に再生された(very recently-played)ビデオ部分とを含むように、いくつかの拡張メタデータノードのスライディング「ウィンドウ」777を、キャッシュのためにクライアントデバイスにダウンロードすることができる。この例では、第1のシーン全体S1は、(それらをストリーミングするために必要なデータパケットの数にかかわらず)キャッシュ/キャッシュ追出(eviction)のためのユニットとして、ウィンドウ777内で一緒にグループ化された拡張メタデータノードを有することができる。ユニットとして一緒にグループ化することができない場合、拡張メタデータノードを送る順序は、有用なサブグラフのキャッシュが最初に行われるために有用であり得るが、古い拡張メタデータノードの追出は、依然として必要とされるものを追出す可能性は低い。したがって、例えば、シーン1では、最下位レベルのノード、第1のカットのイベントノードE1、E2およびE3が、シーン1のカット1ノードの前、およびシーン1ノードの前に送られ、その後、カット2のイベント1ノードおよびカット2ノードが続く。この例では、3つのイベントノード、カット1ノード、シーン1ノードにおける情報は、最初の5つの拡張メタデータノードがストリーミングされた後にインタラクションのために利用可能であり、ビデオイベントが完了し、新しいノードが入ってくると、拡張メタデータノードを追出する必要がある場合、最も古いノードはイベント1ノードなどであり、これはもはや必要とされない可能性が最も高い。
【0071】
[0081]任意のリソース制約されたエンティティと同様に、データサービス自体は、ビデオの拡張メタデータノードの完全なセットをいかなるときも維持しなくてもよい(また、不明瞭な映画のようないくつかの提供されたコンテンツは、拡張メタデータを全く有しないか、または制限された量しか有しないことがある)。したがって、データサービスが維持する拡張メタデータノード778の中で、データサービスは、ビデオのノードセット776全体、いくつかの直接リンクノード(directly linked nodes)780および間接リンクノード(indirectly linked nodes)782を維持してもよい(または維持しなくてもよい)。その代わりに、データサービスは、例えば、様々なデータソース786(1)-786(n)で維持されるデータから、必要に応じて、またはそれらの必要性を予想して、拡張メタデータノードを要求に応じて組み立てることができる(ブロック784)。これらのデータソース786(1)-786(n)は、データをノード形式で維持しないことが多く、任意のノードは、そのデータを異なるデータソースから取得する必要がある場合がある。したがって、データサービスは、必要に応じて、またはすぐに必要とされることを予想して、様々なデータを拡張メタデータノードに処理することができる。
【0072】
[0082]図7に示すように、サーチエンジン790は、クライアントサーチ要求(例えば、サーチ範囲および1または複数のサーチ基準)を受け取り、メタデータノード内で見つけた情報、例えば、どのビデオのどのビデオ部分(例えば、フレーム)がサーチ要求と一致するかを返すように構成されている。さらに、図7に示すように、サマリ/ハイライトビデオジェネレータ792は、何らかの範囲および/または選択基準に基づいてビデオを生成するためにメタデータノードを使用する。
【0073】
[0083]クライアントバッファおよびキャッシュに関して、図8の実施例では、クライアントデバイス880は、例えば、コンテンツ配信ネットワークを介して、データサービス882から複数のストリームを受け取る。したがって、拡張メタデータのサブセットを、クライアントデバイス上で再生されているビデオと対応させるために、データサービスは、現在関連する拡張メタデータノードを、例えば、別個のメタデータストリームで、クライアントデバイスのキャッシュにダウンロードする。これは、典型的には、オーディオストリームのように、ビデオストリームと並行してまたは実質的に並行して行われるが、場合によっては、異なるポートに対して行われる。異なるデータがインターリーブされた(interleaved)、例えば、適切なバッファへのヘッダデータに基づいてソートされた、同じポートへの合成ストリームを有することも可能である。
【0074】
[0084]典型的には、クライアントは、ビデオデータをビデオバッファ884にバッファし、オーディオデータをオーディオバッファ886にバッファする(いくつかのシナリオでは、左および右チャネル、前方および後方、サブウーファなど、および/または2次オーディオのための異なるバッファリングが存在し得るが、図8には示されない)。ビデオ/オーディオ再生コンポーネント(ブロック887)は、別個のものであってもよく、オーディオ/ビデオ出力を生成するために、一般に従来の方法で動作してもよい。
【0075】
[0085]拡張メタデータストリームは、拡張メタデータグラフ処理890を介してクライアントグラフ892に処理される、拡張メタデータバッファ888に送られるように示されている。バッファ884、886、888の図示されたサイズおよびその中のブロック(例えば、パケットデータ)は、実際の相対的なサイズを表すことを意図していない。図10に関して以下で説明するように、拡張メタデータグラフ処理コンポーネント890は、ノード識別子のFIFOキューなどのトラッキングデータ構造894を維持してもよく、その結果、拡張メタデータノードを、他のキャッシュされたデータとは異なるポリシを介してキャッシュ内で管理することができる。
【0076】
[0086]容易に理解されるように、ビデオが再生されるときに、現在再生されているビデオに一般的に対応するために、クライアントデバイスは、一般的に、現在関連性の低い拡張メタデータを、より現在関連性の高い拡張メタデータと置換するように構成される。キャッシュサイズの考慮は、「過去の」拡張メタデータノードに関して、また、ある量の「未来の」拡張メタデータノードのバッファリングに関しても、追出/置換基準の一部として使用され得る。さらに、より重要であり、したがって任意の所与の時点(moment)にインタラクティブユーザによって使用される可能性がより高いと考えられるグラフノードなど、ある拡張メタデータノードと、より従来的なグラフノードを、ビデオストリームの現在の位置とは独立して(少なくともある程度)キャッシュすることができる。
【0077】
[0087]このようにして、キャッシュ内の拡張メタデータをビデオとほぼ同期させて、従来のビデオ再生を実行することができる。バッファサイズ、キャッシュサイズなどに対応するデバイスタイプ情報、使用されているビデオ圧縮のタイプは、異なるデバイス/デバイスクラスのためのデータサービスにより通信されるか、一般に知られるものであってよく、それらが一般に同期されるように、ビデオパケットおよびオーディオパケットに対して拡張メタデータパケットを送る頻度を決定するために使用されてもよい。ビデオ再生が一時停止または停止される場合、拡張メタデータストリーム/ダウンロードは、予想される順方向または逆方向動作を提供するため、および/または拡張メタデータとインタラクトすることを望むユーザを予想するためなど、キャッシュ内に余裕がある範囲まで修正(例えば、増加)され得る。容易に理解されるように、図8は一例に過ぎず、別個の情報をダウンロードする一方でその情報を同期させておくための多数の他の方法のうちの任意のものを代わりに使用することができる。
【0078】
[0088]より高い優先度のストリームおよびより低い優先度のストリームなど、拡張メタデータの2つの(またはそれより多くの)別個のストリームをダウンロードすることも可能である。例えば、帯域幅を節約するために、2つの拡張メタデータストリームが使用される場合、拡張メタデータパケットのより高い優先順位のストリームが、より低い優先順位のストリームがダウンロードされる前に、ある限度まで最初にダウンロードされてもよい。同様のメカニズムは、より低い優先順位のストリームのパケットに対して、より高い優先順位のストリームのパケットを異なるインターリーブ比率でインターリーブすることであり、例えば、各1つのより低い優先順位のストリームのパケットに対して3つのより高い優先順位のストリームのパケットをインターリーブすることである。
【0079】
[0089]図9は、ストリーミングビデオデータ(オーディオは別個に説明されない)と共に、拡張メタデータをクライアントデバイスにストリーミングするためにデータサービスが行うことができる例示的なステップを示すフロー図である。ステップ902は、ステップ904が適切なビデオパケットをフォーマットしてストリーミングすることにより、再生されているストリーミングされたビデオ(streamed video)内の位置を決定することを表し、ステップ902および904は、ビデオをクライアントビデオバッファにストリーミングするための従来の方法で実行される動作である。
【0080】
[0090]ステップ904と並行して、または実質的に並行して実行され得るステップ906および908は、ビデオに対応する拡張メタデータのどのサブセットをストリーミングすべきかを決定するために、ビデオ内の位置を使用する。ステップ908は、ステップ904でストリーミングされるビデオパケットに対応する適切な拡張メタデータパケットをフォーマットし、ストリーミングすることを表す。
【0081】
[0091]典型的には、ステップ910および912によって表されるように、ビデオバッファがいっぱいになるか、ユーザが再生を停止する何らかのアクションを実行しない限り、ビデオ位置が進み、ビデオおよび関連するメタデータがストリーミングし続ける。再生を停止することができる例示的なユーザアクションには、ビデオを一時停止すること、ビデオを停止すること、ビデオを早送りまたは巻き戻しすることなどが含まれる(ビデオの終わりに達することは、ステップ910でビデオを停止することと考えることができる)。他の何らかの方法(例えば、デバイスのリブート、ネットワークの切断)でビデオを終了することなどは、ここでは説明しない。
【0082】
[0092]ステップ910で検出されたそのようなイベントまたは状態で、ステップ914は、例えば、何らかのキャッシュサイズリミットまたはメタデータ拡張リミット(expansion limit)に達するまで、ステップ916でクライアントキャッシュ内のメタデータの量を拡張するために、選択的に実行され得る。上述のように、メタデータのこの拡張は、ユーザがこの時点でメタデータとインタラクトすることを望むことを予想して行うことができ、それによって、追加の拡張メタデータを事前にキャッシュすることは、クライアントユーザの拡張メタデータインタラクション体験を改善することができる。
【0083】
[0093]図10は、拡張メタデータに関してクライアントキャッシュを管理するためにクライアントデバイス(例えば、図8の拡張メタデータグラフ処理コンポーネント886)によって行われ得る例示的なステップを示すフロー図である。図10の例示的なロジックは、キャッシュに関して拡張メタデータを管理するための多くの可能な方法のうちの1つにすぎず、ロジックは、従来のユーザインタフェースノード(例えば、メニュー、サブメニュー、アイテム)と拡張メタデータノード(例えば、ここで説明するようなシーン、カット、イベントなど)の両方を維持する単一のクライアントキャッシュと共に動作する。これにより、拡張メタデータノードが1または複数の従来のユーザインタフェースノードに(例えば、エピソード、タイムラインノードまたはムービー、タイムラインノードを介して)リンクするため、従来のユーザインタフェースノードおよび拡張メタデータノードを含む単一の(部分)グラフをキャッシュすることができる。
【0084】
[0094]ステップ1002は、クライアントデバイスが、拡張メタデータストリームバッファ上で1または複数の拡張メタデータパケットを受け取ることを表す。ステップ1004は、パケットから拡張メタデータノードを抽出する。ステップ1006は、第1の拡張メタデータノードを選択する。各ノードは、データサービス内で一意の識別子(ID)を有する。
【0085】
[0095]ステップ1008は、ノードが、例えば、フラグなどによってノードのヘッダまたはデータにマークされているように、拡張メタデータストリームに到着した特別なノードであるかどうかを評価するオプションのステップである。ステップ1008を介して、そのようなノードは、それが伴うビデオ部分とは独立して、またはクライアントユーザによってすぐに必要とされる可能性が高いなど、何らかの形で重要であるとサービスによってみなされる場合に、(ステップ1018で)キャッシュされる。これにより、ここで説明するように、現在バッファされている、またはビデオの再生部分に関連付けられている拡張メタデータノードを追出/期限切れにするためのポリシとは対照的に、拡張メタデータストリームは、通常のキャッシュポリシに従って追出/期限切れにされるグラフノードをクライアントキャッシュにキャッシュすることができる。
【0086】
[0096]特別なノードでない場合、ステップ1010は、拡張メタデータノードのIDをFIFOキューまたは他の適切なデータ構造に追加する。ステップ1012は、キューがそのリミットにあるかどうかを評価する。
【0087】
[0097]キューリミット(queue limit)にない場合、拡張メタデータノードがキャッシュされる。逆に、キューリミットにある場合、拡張メタデータノード識別子(例えば、FIFOキューの場合は最も古い)がステップ1014でキューから除去され、対応する(例えば、最も古い)ノードがステップ1016でキャッシュから除去される。ノードは、この時点でキャッシュから実際に除去される必要はないが、追出のためにマークされることができ、期限切れのタイムスタンプを与えられることなどができ、それによって、キャッシュスペースが必要とされるときに、クリーンアッププロセスまたはより新しいノードがそれを置換することができる。ステップ1018は、拡張メタデータノードをキャッシュし、必要に応じて除去されたノードのスペースを上書きすることができる。
【0088】
[0098]Sep1020は、受け取った他の拡張メタデータノードごとにプロセスを繰り返す。何も残っていない場合、より多くの拡張メタデータノードが拡張メタデータノードバッファにストリーミングされるまで、プロセスは終了する。
【0089】
[0099]容易に理解できるように、図10の例示的なステップにより、クライアントデバイスプラットフォームソフトウェアは、一般にどの程度の拡張メタデータを維持すべきかに関する独自の制限を決定することができる。このようにして、より少ないリソースを有するデバイスは、より小さいキュー/より少ない拡張メタデータをキャッシュ内に有することができ、より多くのリソースを有するデバイスは、より大きいキュー/より多くの拡張メタデータをキャッシュ内に有することができる。帯域幅はまた、例えば、ビデオバッファが維持されているときにのみ、拡張メタデータが許容される場合に考慮されてもよい。同様に、データプランは、考慮されてもよく、限定されている場合にはユーザ入力を介して決定されてもよく、例えば、そうすることがユーザにコストを負担させる場合には、特に望まれない限りメタデータをダウンロードしない。
【0090】
[00100]上述したように、図10のように、キャッシュおよび除去のために拡張メタデータノードを個別に処理する代わりに、拡張メタデータノードのグループを一緒に処理することができる。例えば、シーン全体の拡張メタデータノードを含むサブグラフは、キャッシュから一緒に追出されることに関して1つのユニットとして(および、場合によってはキャッシュに追加されるときには1つのグループとして)扱われてもよい。どのノードが一緒にグループ化されるかのようなデータは、例えば、ノードとしてキャッシュされないが、グループが追出されるまでトラッキングデータ構造894(図8)の一部として保存される、特別な情報「メタノード」などとして、拡張メタデータノードとともにストリーミングされてもよい。
【0091】
[00101]理解されるように、ここでは、ストリーミングされたビデオに関連するメタデータをストリーミングするか、またはそうでなければダウンロードし、ユーザが、拡張されたユーザ体験のためにメタデータと選択的にインタラクトすることを可能にする技術が説明される。ユーザは、マップ、同じシーンの異なるカット、同じカットの異なるカメラビュー、イベント記述(テキストおよびキャスト/クルーインタビュー)、俳優、伝記テキストおよびインタビューのようなキャラクタ情報、この俳優(またはキャラクタ)がどのシーンに登場したかのサマリなどのデータを見るために、任意のリンク間でナビゲートするか、グラフノード上で直接ピボットする(pivot)ことができる。
【0092】
[00102]グラフは、現実世界(カメラ、実際のロケーションおよび俳優)などの異なる環境と、架空の世界およびキャラクタなどの代替ユニバースとの関係を可能にする。架空の世界を互いに関連付けることができる。視聴者は、イベントが最終バージョンからカットされたとしても、リンクをたどることによってイベントを見ることができる。グラフは、リッチサーチを可能にする。映画および/またはエピソードのサマリまたはハイライトは、1または複数の選択基準に基づいて関連コンテンツを自動的に生成することによって、視聴者のためにまとめられてもよい。
【0093】
[00103]1または複数の態様は、ビデオの部分を拡張メタデータのサブセットと関連付けることを対象とし、拡張メタデータのサブセットの各々は、ビデオの対応する部分における少なくとも1つのアクションを記述する。ビデオをクライアントデバイスにストリーミングする際に、ビデオのどの部分がストリーミングされているかを決定し、ストリーミングされているビデオの部分に対応する拡張メタデータの選択されたサブセットを選択し、拡張メタデータの選択されたサブセットをクライアントデバイスにダウンロードすることがここで説明される。
【0094】
[00104]拡張メタデータの選択されたサブセットをクライアントデバイスにダウンロードすることは、ストリーム中の拡張メタデータのサブセットを、ストリーミングビデオストリームと並行して、または実質的に並行してストリーミングすることを含んでもよい。
【0095】
[00105]拡張メタデータは、グラフのノードとして構成可能であってもよく、ビデオのどの部分がストリーミングされているかを決定することは、フレームのセットを決定することを含んでもよく、ストリーミングされているビデオの部分に対応する拡張メタデータの選択されたサブセットを選択することは、フレームのセットに基づいて少なくとも1つの拡張メタデータノードを選択することを含んでもよい。拡張メタデータの選択されたサブセットを選択することは、ビデオの対応する部分におけるアクションを記述する情報を含む少なくとも1つの拡張メタデータノードを選択することを含んでもよい。拡張メタデータの選択されたサブセットを選択することは、ビデオの対応する部分において、キャラクタもしくはロケーション、またはキャラクタとロケーションの両方を記述する情報を含む少なくとも1つの拡張メタデータノードを選択することを含んでもよい。
【0096】
[00106]記載の技術は、拡張メタデータ内の情報をサーチするための要求を受け取ることと、要求に基づいてサーチ範囲を決定することと、サーチ範囲に基づいてサーチするための拡張メタデータの1または複数の範囲内サブセットを決定することと、要求における1または複数のサーチ基準に基づいて、一致情報について1または複数の範囲内サブセットをサーチすることと、サーチによって決定された任意の一致情報を識別する、要求に対する応答を返すこととを可能にする。
【0097】
[00107]記載された技術は、サマリまたはハイライトビデオを生成する要求を受け取ること、サマリまたはハイライトビデオに対応する拡張メタデータの1または複数の関連サブセットを探し出す(locating)こと、およびサマリまたはハイライトビデオを生成するために1または複数の関連サブセットにおける情報を使用することを可能にする。
【0098】
[00108]さらに、クライアントデバイスにビデオをストリーミングする前に、例えば、クライアントデバイス上の拡張メタデータのサブセットの少なくとも一部の可視表現をレンダリングし、可視表現とのユーザインタラクションを可能にするために、拡張メタデータの少なくとも1つのサブセットを、ユーザインタラクションに基づいてクライアントデバイスにダウンロードしてもよい。
【0099】
[00109]1または複数の態様は、ビデオコンテンツプロバイダのデータサービスを対象とし、データサービスは、ビデオをクライアントにストリーミングするように構成される。データサービスは、拡張メタデータノードに対応する情報をクライアントに送るようにさらに構成され、ビデオの部分に関連する拡張メタデータノードのサブセットを選択することと、クライアントにストリーミングされているビデオの部分に関連するサブセットを送ることとを含む。
【0100】
[00110]拡張メタデータノードは、チャプタノード、シーンノード、カットノード、および/またはイベントノードのうちの少なくとも1つを含むことができる。ビデオの部分に関連する拡張メタデータノードのサブセットは、少なくとも1つの動詞および1つの名詞に対応する情報を有するビデオの部分を記述することができる。拡張メタデータノードは、両方がビデオの同一部分に関連する少なくとも2以上の代替ノードを含むことができる。
【0101】
[00111]データサービスは、サーチ基準(search criteria or a search criterion)に一致する1または複数のビデオ部分を識別するために、拡張メタデータノードの少なくともいくつかをサーチするように構成され得る。データサービスは、サマリまたはハイライトビデオを生成するように構成されてもよく、サマリまたはハイライトビデオのための1または複数のビデオ部分を選択するために、拡張メタデータノードのうちの少なくともいくつかにおける情報にアクセスすることを含む。データサービスは、1または複数のデータソースからのデータを、拡張メタデータノードに組み立てるように構成されてもよい。
【0102】
[00112]クライアントは、拡張メタデータノードのサブセットを受け取り、そのサブセットをクライアントグラフの一部としてキャッシュしてもよい。
【0103】
[00113]1または複数の態様は、クライアントデバイスにおいてストリーミングされたビデオの部分を受け取り、クライアントデバイスにおいて拡張メタデータを受け取ることに向けられ、拡張メタデータは、ストリーミングされたビデオの部分に対応する。ここでは、拡張メタデータをクライアントデバイスキャッシュにキャッシュし、拡張メタデータにおける情報とのユーザインタラクションを可能にすることについて説明する。ストリーミングされたビデオの部分を受け取ること、およびストリーミングされたビデオの部分に対応する拡張メタデータを受け取ることは、クライアントデバイスにおいて並列して、または実質的に並列して行われ得る。少なくともいくつかの他の拡張メタデータは、拡張メタデータ追出ポリシに従ってクライアントデバイスキャッシュから除去され得る。
【0104】
[00114]ここでは、サーチ範囲情報および1または複数のサーチ基準を含むサーチ要求を、拡張メタデータを提供するエンティティに送り、エンティティからサーチ結果を受け取る機能についても説明する。サーチ結果は、サーチ範囲内の拡張メタデータのサーチに基づくことができ、サーチ結果は、1または複数のサーチ基準を満たす少なくとも1つのビデオ部分を識別する情報を含む。
【0105】
コンピューティングデバイスの例
【0106】
[00115]ここで説明する技術は、プログラムおよびプロセスを実行することができる任意のデバイスまたはデバイス(マシン)のセットに適用することができる。したがって、パーソナルコンピュータ、ラップトップ、ハンドヘルド、ポータブル、および他のコンピューティングデバイス、ならびに携帯電話、タブレット/スレートコンピュータ、ゲーム/娯楽コンソールなどを含むあらゆる種類のコンピューティングオブジェクトが、ここで例示されたものを含む様々な実装に関連して使用するために考慮されることを理解することができる。物理および/または仮想マシンを含むサーバも同様に適切なデバイス/マシンである。したがって、以下の図11で説明する汎用コンピューティングメカニズムは、コンピューティングデバイスの一例にすぎない。
【0107】
[00116]実装は、デバイスまたはオブジェクトのためのサービスの開発者による使用のために、オペレーティングシステムを介して部分的に実装されることができ、および/または、ここで説明される様々な実装の1または複数の機能的態様を実行するように動作するアプリケーションソフトウェア内に含まれることができる。ソフトウェアは、クライアントワークステーション、サーバ、または他のデバイスなどの1または複数のコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストで説明することができる。当業者は、コンピュータシステムが、データを通信するために使用され得る種々の構成およびプロトコルを有し、従って、特定の構成またはプロトコルが限定的であると考えられないことを理解するであろう。
【0108】
[00117]したがって、図11は、ここで説明した実装の1または複数の態様を実装することができる適切なコンピューティングシステム環境1100の一例を示すが、上記で明らかにしたように、コンピューティングシステム環境1100は、適切なコンピューティング環境の一例にすぎず、使用または機能の範囲に関していかなる制限も示唆することを意図していない。さらに、コンピューティングシステム環境1100は、例示的なコンピューティングシステム環境1100に示されたコンポーネントのうちの任意の1または組合せに関連する任意の依存関係を有するものとして解釈されることを意図していない。
【0109】
[00118]図11を参照すると、1または複数の実装を実装するための例示的なデバイスは、コンピュータ1110の形態の汎用コンピューティングデバイスを含む。コンピュータ1110のコンポーネントは、処理ユニット1120、システムメモリ1130、およびシステムメモリを含む様々なシステムコンポーネントを処理ユニット1120に結合するシステムバス1122を含むことができるが、これらに限定されない。
【0110】
[00119]コンピュータ1110は、通常、様々なマシン(例えば、コンピュータ)可読媒体を含み、コンピュータ1110などのマシンによってアクセス可能な任意の利用可能な媒体とすることができる。システムメモリ1130は、読み出し専用メモリ(ROM)および/またはランダムアクセスメモリ(RAM)などの揮発性および/または不揮発性メモリの形態のコンピュータ記憶媒体、ならびにハードドライブ媒体、光記憶媒体、フラッシュ媒体などを含むことができる。限定ではなく例として、システムメモリ1130は、オペレーティングシステム、アプリケーションプログラム、他のプログラムモジュール、およびプログラムデータを含むこともできる。
【0111】
[00120]ユーザは、1または複数の入力デバイス1140を介してコンピュータ1110にコマンドおよび情報を入力することができる。モニタまたは他のタイプのディスプレイデバイスも、出力インタフェース1150などのインタフェースを介してシステムバス1122に接続される。モニタに加えて、コンピュータは、スピーカおよびプリンタなどの他の周辺出力デバイスも含むことができ、これらは、出力インタフェース1150を介して接続することができる。
【0112】
[00121]コンピュータ1110は、リモートコンピュータ1170などの1または複数の他のリモートコンピュータへのロジック接続を使用して、ネットワーク環境または分散環境で動作することができる。リモートコンピュータ1170は、パーソナルコンピュータ、サーバ、ルータ、ネットワークPC、ピアデバイス、または他の一般的なネットワークノード、あるいは任意の他のリモートメディア消費または送信デバイスとすることができ、コンピュータ1110に関して上述した要素のいずれかまたはすべてを含むことができる。図11に示すロジック接続は、ローカルエリアネットワーク(LAN)または広域ネットワーク(WAN)などのネットワーク1172を含むが、他のネットワーク/バスを含むこともできる。このようなネットワーク環境は、家庭、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいて一般的である。
【0113】
[00122]上述のように、様々なコンピューティングデバイスおよびネットワークアーキテクチャに関連して例示的な実装を説明したが、基礎となる概念は、任意のネットワークシステム、およびそのような技術を実装することが望ましい任意のコンピューティングデバイスまたはシステムに適用することができる。
【0114】
[00123]また、アプリケーションおよびサービスがここで提供される技術を利用することを可能にする、同一または類似の機能、例えば、適切なAPI、ツールキット、ドライバコード、オペレーティングシステム、制御、スタンドアロンまたはダウンロード可能なソフトウェアオブジェクトなどを実装するための複数の方法がある。したがって、ここに記載する実装は、API(または他のソフトウェアオブジェクト)の観点から、ならびにここで説明する1または複数の実装を実装するソフトウェアまたはハードウェアオブジェクトから考慮される。したがって、ここで説明される様々な実装は、全体的にハードウェアであり、部分的にハードウェアであり、部分的にソフトウェアであり、ならびに全体的にソフトウェアである態様を有することができる。
【0115】
[00124]用語「例」は、例、事例、または例示としての役割を果たすことを意味するためにここで使用される。疑義を避けるために、ここに開示される主題は、そのような例によって限定されない。さらに、ここで「例」として説明される任意の態様または設計は、必ずしも、他の態様または設計よりも好ましいまたは有利であると解釈されるべきではなく、当業者に知られている等価な例示的構造および技術を排除することを意味しない。さらに、「含む(include)」、「有する(has)」、「含有する(contains)」という用語、および他の類似の用語が使用される範囲では、疑義を避けるために、そのような用語は、請求項で使用される場合に追加の要素または他の要素を除外することなく、オープンな移行語として「備える(comprising)」という用語と同様に包括的であることが意図される。
【0116】
[00125]上述のように、ここで説明される様々な技術は、ハードウェアまたはソフトウェアとともに、あるいは、適切な場合には、両方の組合せとともに実装され得る。ここで使用されるように、「コンポーネント(component)」、「モジュール(module)」、「システム(system)」などの用語は、同様に、コンピュータ関連のエンティティ、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかを指すことが意図される。例えば、コンポーネントは、プロセッサ上で実行されるプロセス、プロセッサ、オブジェクト、実行可能なもの、実行スレッド、プログラム、および/またはコンピュータとすることができるが、これらに限定されない。例として、コンピュータ上で実行されるアプリケーションおよびコンピュータの両方がコンポーネントであり得る。1または複数のコンポーネントは、実行のプロセスおよび/またはスレッド内に存在することができ、コンポーネントは、1つのコンピュータ上に配置され、および/または2台以上のコンピュータ間に分散されることができる。
【0117】
[00126]前述のシステムは、いくつかのコンポーネント間のインタラクションに関して説明されている。そのようなシステムおよびコンポーネントは、それらのコンポーネントまたは指定されたサブコンポーネント、指定されたコンポーネントまたはサブコンポーネントのうちのいくつか、および/または追加のコンポーネントを、前述のものの様々な順列および組合せに従って含むことができることを理解されたい。サブコンポーネントは、親コンポーネント(階層)内に含まれるのではなく、他のコンポーネントに通信可能に結合されたコンポーネントとして実装することもできる。さらに、1または複数のコンポーネントは、集約機能を提供する単一のコンポーネントに組み合わされてもよく、またはいくつかの別個のサブコンポーネントに分割されてもよく、管理層などの任意の1または複数の中間層は、統合された機能を提供するために、そのようなサブコンポーネントに通信可能に結合するように提供されてもよいことに留意されたい。ここに記載の任意のコンポーネントは、ここに具体的に記載されていないが、当業者に一般に知られている1または複数の他のコンポーネントとインタラクトすることもできる。
【0118】
[00127]ここで説明される例示的なシステムを考慮すると、説明される主題に従って実装され得る方法は、様々な図のフローチャート/フロー図を参照しても理解され得る。説明を簡単にするために、方法は、一連のブロックとして示され説明されるが、いくつかのブロックは、ここで図示され、説明されるものとは異なる順序で、および/または他のブロックと同時に発生することができるので、様々な実装は、ブロックの順序によって限定されないことを理解されたい。非順次または分岐のフローがフローチャート/フロー図を介して示される場合、同じまたは類似の結果を達成する様々な他の分岐、フローパス、およびブロックの順序が実装され得ることが理解され得る。さらに、いくつかの図示されたブロックは、ここで説明される方法を実施する際にオプションである。
【0119】
結論
【0120】
[00128]本発明は、様々な修正および代替の構成が可能であるが、その特定の例示的な実装が図面に示され、上記で詳細に説明されている。しかし、本発明を開示された特定の形態に限定する意図はなく、逆に、本発明は、本発明の精神および範囲内にある全ての改変、代替の構成、および等価物を包含することが理解されるべきである。
【0121】
[00129]ここで説明される様々な実装に加えて、他の類似の実装を使用することができること、または対応する実装の同じまたは同等の機能を、それから逸脱することなく実行するために、説明される実装に修正および追加を行うことができることを理解されたい。さらに、複数の処理チップまたは複数のデバイスが、ここで説明する1または複数の機能の性能を共有することができ、同様に、複数のデバイスにわたってストレージを有効化することができる。従って、本発明は、いかなる単一の実施にも限定されず、むしろ、添付の特許請求の範囲に従って、領域、精神および範囲において解釈されるべきである。

図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
【手続補正書】
【提出日】2022-07-13
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
ビデオコンテンツプロバイダのデータサービスを備えるシステムであって、
前記データサービスは、ビデオをクライアントにストリームするよう構成され、
前記データサービスは、拡張メタデータノードに対応する情報を前記クライアントに送るようにさらに構成され、ビデオの部分に関連する前記拡張メタデータノードのサブセットを選択することと、クライアントに、ストリーミングされている前記ビデオの前記部分に関連する前記サブセットを送ることとを含む、システム。
【請求項2】
前記拡張メタデータノードは、チャプタノード、シーンノード、カットノード、もしくはイベントノード、またはチャプタノード、シーンノード、カットノード、もしくはイベントノードの任意の組合せのうちの少なくとも1つを備える、請求項に記載のシステム。
【請求項3】
前記拡張メタデータノードは、両方が前記ビデオの同一部分に関連する少なくとも2以上の代替ノードを備える、請求項に記載のシステム。
【請求項4】
前記ビデオの前記部分に関連する前記拡張メタデータノードの前記サブセットは、少なくとも1つの動詞および1つの名詞に対応する情報を有する前記ビデオの前記部分を記述する、請求項に記載のシステム。
【請求項5】
前記データサービスが、サーチ基準に一致する1または複数のビデオ部分を識別するために、前記拡張メタデータノードの少なくともいくつかをサーチするように構成された、請求項に記載のシステム。
【請求項6】
前記データサービスは、サマリまたはハイライトビデオを生成するように構成され、前記サマリまたはハイライトビデオのための1または複数のビデオ部分を選択するために、前記拡張メタデータノードの少なくともいくつかにおける情報にアクセスすることを含む、請求項に記載のシステム。
【請求項7】
前記データサービスは、1または複数のデータソースからのデータを、拡張メタデータノードに組み立てるように構成される、請求項に記載のシステム。
【請求項8】
前記クライアントは、前記拡張メタデータノードの前記サブセットを受け取りし、前記サブセットを、クライアントグラフの一部としてキャッシュする、請求項に記載のシステム。
【手続補正2】
【補正対象書類名】明細書
【補正対象項目名】0121
【補正方法】変更
【補正の内容】
【0121】
[00129]ここで説明される様々な実装に加えて、他の類似の実装を使用することができること、または対応する実装の同じまたは同等の機能を、それから逸脱することなく実行するために、説明される実装に修正および追加を行うことができることを理解されたい。さらに、複数の処理チップまたは複数のデバイスが、ここで説明する1または複数の機能の性能を共有することができ、同様に、複数のデバイスにわたってストレージを有効化することができる。従って、本発明は、いかなる単一の実施にも限定されず、むしろ、添付の特許請求の範囲に従って、領域、精神および範囲において解釈されるべきである。
以下に、出願当初の特許請求の範囲に記載の事項を、そのまま、付記しておく。
[C1]
ビデオの部分を拡張メタデータのサブセットと関連付けることと、前記拡張メタデータのサブセットの各々は、前記ビデオの対応する部分における少なくとも1つのアクションを記述し、
前記ビデオをクライアントデバイスへストリーミングすることと、
前記ビデオのどの部分がストリーミングされているかを決定することと、
ストリーミングされている前記ビデオの前記部分に対応する、前記拡張メタデータの選択されたサブセットを選択することと、
前記拡張メタデータの前記選択されたサブセットを前記クライアントデバイスにダウンロードすることと、
を備える方法。
[C2]
前記拡張メタデータの前記選択されたサブセットを前記クライアントデバイスにダウンロードすることは、ストリーム中の前記拡張メタデータの前記サブセットを、ストリーミングビデオストリームと並行して、または実質的に並行してストリーミングすることを備える、C1に記載の方法。
[C3]
前記拡張メタデータは、グラフのノードとして構成可能であり、ここにおいて、前記ビデオのどの部分がストリーミングされているかを決定することは、フレームのセットを決定することを備え、ここにおいて、ストリーミングされている前記ビデオの前記部分に対応する前記拡張メタデータの選択されたサブセットを選択することは、前記フレームのセットに基づいて少なくとも1つの拡張メタデータノードを選択することを備える、C1に記載の方法。
[C4]
前記拡張メタデータの前記選択されたサブセットを選択することは、前記ビデオの前記対応する部分におけるアクションを記述する情報を含む少なくとも1つの拡張メタデータノードを選択することを備える、C3に記載の方法。
[C5]
前記拡張メタデータの前記選択されたサブセットを選択することは、前記ビデオの前記対応する部分において、キャラクタもしくはロケーション、またはキャラクタとロケーションの両方を記述する情報を含む少なくとも1つの拡張メタデータノードを選択することを備える、C3に記載の方法。
[C6]
前記拡張メタデータ内の情報をサーチするための要求を受け取ることと、
前記要求に基づいてサーチ範囲を決定することと、
前記サーチ範囲に基づいてサーチするための前記拡張メタデータの1または複数の範囲内サブセットを決定することと、
前記要求における1または複数のサーチ基準に基づいて、一致情報について前記1または複数の範囲内サブセットをサーチすることと、
前記サーチによって決定された任意の一致情報を識別する、前記要求に対する応答を返すことと、
をさらに備える、C1に記載の方法。
[C7]
サマリまたはハイライトビデオを生成する要求を受け取ることと、
前記サマリまたはハイライトビデオに対応する前記拡張メタデータの1または複数の関連サブセットを探し出すことと、
前記サマリまたはハイライトビデオを生成するために、前記1または複数の関連サブセットにおける情報を使用することと、
をさらに備える、C1に記載の方法。
[C8]
前記ビデオを前記クライアントデバイスにストリーミングする前に、前記拡張メタデータの少なくとも1つのサブセットを、ユーザインタラクションに基づいて前記クライアントデバイスにダウンロードすることと、
前記拡張メタデータの前記サブセットの少なくとも一部の可視表現を前記クライアントデバイス上にレンダリングすることと、
前記可視表現とのユーザインタラクションを可能にすることと、
をさらに備える、C1に記載の方法。
[C9]
ビデオコンテンツプロバイダのデータサービスを備えるシステムであって、
前記データサービスは、ビデオをクライアントにストリームするよう構成され、
前記データサービスは、拡張メタデータノードに対応する情報を前記クライアントに送るようにさらに構成され、ビデオの部分に関連する前記拡張メタデータノードのサブセットを選択することと、クライアントに、ストリーミングされている前記ビデオの前記部分に関連する前記サブセットを送ることとを含む、システム。
[C10]
前記拡張メタデータノードは、チャプタノード、シーンノード、カットノード、もしくはイベントノード、またはチャプタノード、シーンノード、カットノード、もしくはイベントノードの任意の組合せのうちの少なくとも1つを備える、C9に記載のシステム。
[C11]
前記拡張メタデータノードは、両方が前記ビデオの同一部分に関連する少なくとも2以上の代替ノードを備える、C9に記載のシステム。
[C12]
前記ビデオの前記部分に関連する前記拡張メタデータノードの前記サブセットは、少なくとも1つの動詞および1つの名詞に対応する情報を有する前記ビデオの前記部分を記述する、C9に記載のシステム。
[C13]
前記データサービスが、サーチ基準に一致する1または複数のビデオ部分を識別するために、前記拡張メタデータノードの少なくともいくつかをサーチするように構成された、C9に記載のシステム。
[C14]
前記データサービスは、サマリまたはハイライトビデオを生成するように構成され、前記サマリまたはハイライトビデオのための1または複数のビデオ部分を選択するために、前記拡張メタデータノードの少なくともいくつかにおける情報にアクセスすることを含む、C9に記載のシステム。
[C15]
前記データサービスは、1または複数のデータソースからのデータを、拡張メタデータノードに組み立てるように構成される、C9に記載のシステム。
[C16]
前記クライアントは、前記拡張メタデータノードの前記サブセットを受け取りし、前記サブセットを、クライアントグラフの一部としてキャッシュする、C9に記載のシステム。
[C17]
1または複数の機械可読記憶媒体であって、実行されると、
クライアントデバイスにおいてストリーミングされたビデオの部分を受け取ることと、 前記クライアントデバイスにおいて拡張メタデータを受け取ることと、前記拡張メタデータは前記ストリーミングされたビデオの前記部分に対応し、
前記拡張メタデータをクライアントデバイスキャッシュにキャッシュすることと、
前記拡張メタデータにおける情報とのユーザインタラクションを可能にすることと、 を備えるステップを実行する、機械実行可能命令を有する、1または複数の機械可読記憶媒体。
[C18]
前記ストリーミングされたビデオの前記部分を受け取ることと、前記ストリーミングされたビデオの前記部分に対応する前記拡張メタデータを受け取ることは、前記クライアントデバイスにおいて並行して、または実質的に並行して行われる、C17に記載の1または複数の機械可読記憶媒体。
[C19]
拡張メタデータ追出ポリシに従って、前記クライアントデバイスキャッシュから少なくともいくつかの他の拡張メタデータを除去することを備える、さらなる機械実行可能命令を有する、C17に記載の1または複数の機械可読記憶媒体。
[C20]
サーチ範囲情報および1または複数のサーチ基準を含むサーチ要求を、前記拡張メタデータを提供するエンティティに送ることと、
前記サーチ範囲内の前記拡張メタデータのサーチに基づくサーチ結果を前記エンティティから受け取ることと、ここにおいて、前記サーチ結果は、前記1または複数のサーチ基準を満たす少なくとも1つのビデオ部分を識別する情報を含む、
を備える、さらなる機械実行可能命令を有する、C17に記載の1または複数の機械可読記憶媒体。
【外国語明細書】