特開 2017-98948 ビデオストリームで実行される対話型アプリケーション

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】特開2017-98948(P2017-98948A)

(43)【公開日】2017年6月1日

(54)【発明の名称】ビデオストリームで実行される対話型アプリケーション

(51)【国際特許分類】

   H04N 21/472 20110101AFI20170428BHJP

   G06F 13/00 20060101ALI20170428BHJP

   H04N 21/43 20110101ALI20170428BHJP

   H04N 5/765 20060101ALI20170428BHJP

   H04N 5/91 20060101ALI20170428BHJP

   H04N 5/93 20060101ALI20170428BHJP

【ＦＩ】

   H04N21/472

   G06F13/00 540A

   H04N21/43

   H04N5/91 L

   H04N5/91 Z

   H04N5/93 Z

【審査請求】有

【請求項の数】22

【出願形態】ＯＬ

【外国語出願】

【全頁数】18

(21)【出願番号】特願2016-214103(P2016-214103)

(22)【出願日】2016年11月1日

(31)【優先権主張番号】14/932,252

(32)【優先日】2015年11月4日

(33)【優先権主張国】US

(31)【優先権主張番号】15/095,987

(32)【優先日】2016年4月11日

(33)【優先権主張国】US

(71)【出願人】

【識別番号】515186563

【氏名又は名称】ユビタス インコーポレイテッド

【氏名又は名称原語表記】Ｕｂｉｔｕｓ Ｉｎｃ．

(74)【代理人】

【識別番号】100107364

【弁理士】

【氏名又は名称】斉藤 達也

(72)【発明者】

【氏名】ジュン−チャン クオ

(72)【発明者】

【氏名】シェン−ラン ヤン

【テーマコード（参考）】

5B084

5C053

5C164

【Ｆターム（参考）】

5B084AA01

5B084AA02

5B084AA12

5B084AB07

5B084AB31

5B084AB35

5B084BA03

5B084BB12

5B084DA15

5B084DB02

5B084DC02

5B084DC13

5C053GB06

5C053LA11

5C053LA14

5C164MB13S

5C164MC06S

5C164UB04P

5C164UB36P

5C164UD41S

(57)【要約】      （修正有）

【課題】ビデオストリームで実行されるコンピューター計算負荷の低い対話型アプリケーションを提供する。
【解決手段】第１のユーザー要求に応答してリニア再生ビデオの再生を開始する。リニア再生ビデオの時間位置に関連して、タイムスタンプを構成する第２のユーザー要求を受け取り、タイムスタンプに基づいて、特定の対話型ビデオスクリプト、対応するメタデータに保存された事前録画されたストリーミングビデオのセットから成る特定の対話型ビデオスクリプトを選択する。メタデータに基づき、ユーザー入力への応答を含め、特定の場所から、特定の対話型ビデオスクリプトを再生する。
【選択図】図１

【特許請求の範囲】

【請求項1】

対話型ビデオスクリプトを再生するための方法であって、
第１のユーザー要求に応答してリニア再生ビデオの再生を開始すること、
リニア再生ビデオの時間位置に関連して、タイムスタンプを構成する第２のユーザー要求を受け取ること、
タイムスタンプに基づいて、特定の対話型ビデオスクリプト、対応するメタデータに保存された事前録画されたストリーミングビデオのセットから成る特定の対話型ビデオスクリプトを選択することと、
メタデータに基づき、さらなるユーザー入力への応答を含め、特定の場所から、特定の対話型ビデオスクリプトを再生することである。

【請求項2】

リニア再生ビデオの再生に戻ることをさらに含むことを特徴とする請求項１に記載の方法。

【請求項3】

リニア再生ビデオの再生に戻ることは、対話型ビデオスクリプトの終了によってトリガーされることを特徴とする請求項２に記載の方法。

【請求項4】

リニア再生ビデオの再生に戻ることは、第３のユーザー要求によってトリガーされることを特徴とする請求項２に記載の方法。

【請求項5】

ストリーミングビデオクリップが、マルチメディアコンテナ形式に従ってフォーマットされることを特徴とする請求項１に記載の方法。

【請求項6】

リニア再生ビデオが、ビデオストリーミングインフラストラクチャを介して配信されることを特徴とする請求項１に記載の方法。

【請求項7】

対話型ビデオスクリプトが、ビデオストリーミングインフラストラクチャを介して配信されることを特徴とする請求項１に記載の方法。

【請求項8】

特定の対話型ビデオスクリプトが、複数の対話型ビデオスクリプトから選択されることを特徴とする請求項１に記載の方法。

【請求項9】

特定の場所が開始ポイントとなることを特徴とする請求項１に記載の方法。

【請求項10】

第１のユーザー要求に応答してリニア再生ビデオの再生を開始すること、
リニア再生ビデオに関して、ユーザーの介入を構成する第２のユーザー要求を受け取ること、
ユーザー介入の特徴を使用して、対話型ビデオスクリプトで特定の場所を選択すること、
事前選択されたメタデータに基づき、さらなるユーザー入力への応答を含め、特定の場所から、特定の対話型ビデオスクリプトを再生する方法と、
対話型ビデオスクリプトの終わりに、リニア再生ビデオに戻ることを特徴とする対話型ビデオスクリプトを再生するための方法である。。

【請求項11】

第２のユーザー要求が、対話型ビデオスクリプトの特定の場所を選択するために使用されるリンクをクリックすることを含む請求項１０に記載の方法。

【請求項12】

第２のユーザー要求が、対話型ビデオスクリプトの特定の場所を選択するために使用されるボイスコマンドを含む請求項１０に記載の方法。

【請求項13】

第２のユーザー要求が、対話型ビデオスクリプトの特定の場所を選択するために使用される物理ボタン押しを含む請求項１０に記載の方法。

【請求項14】

第２のユーザー要求が、リニア再生ビデオが再生を開始してから経過した時間に基づき、対話型ビデオスクリプトの特定の場所を選択するために使用されるタイムスタンプを含む請求項１０に記載の方法。

【請求項15】

第１のユーザー要求がボイス広告を表すリンクのクリックを含む請求項１０に記載の方法。

【請求項16】

１つ以上のリニアビデオと１つ以上の対話型ビデオスクリプトを交互に再生するシステムであって、ユーザーデバイス、ビデオストリーミングインフラストラクチャ、対話型ビデオスクリプトを構成し、
ユーザーデバイスはリニアビデオの再生を受け取って表示し、対話型ビデオスクリプトの再生に対するユーザーの要求を受け入れ、対話型ビデオスクリプトプレーヤーへの対応するタイムスタンプと連動してユーザーの要求を伝送し、
対話型ビデオスクリプトは、タイムスタンプに基づいて対話型ビデオスクリプトの特定の場所から特定の対話型ビデオスクリプトを選択して再生するように設定され、
ビデオストリーミングインフラストラクチャは、１つ以上のリニアビデオと対話型ビデオスクリプトをユーザーデバイスに配信するように設定される。

【請求項17】

ユーザーデバイスは、対話型ビデオスクリプトが終わるとリニアビデオの再生を再開するように設定される請求項１６に記載のシステム。

【請求項18】

ユーザーデバイスは、第２の対話型ビデオスクリプトの再生に対して第２のユーザー要求を受け入れ、対話型ビデオスクリプトプレーヤーへの第２のタイムスタンプと連動して第２のユーザー要求を伝送するように設定される請求項１７に記載のシステム。

【請求項19】

対話型ビデオスクリプトプレーヤーが、第２のタイムスタンプに基づいて第２の特定の対話型ビデオスクリプトを選択して再生するように設定される請求項１８に記載のシステム。

【請求項20】

対話型ビデオスクリプトプレーヤーが、対応するメタデータと連動して、データベースに保存された事前録画されたストリーミングビデオクリップのセットを構成する請求項１６に記載のシステム。

【請求項21】

ユーザーデバイスはタッチ画面から成るスマートフォンである請求項１６に記載のシステム。

【請求項22】

コンピュータープロセッサーにより実行されるインフラストラクチャから成る、持続性コンピューター可読メディアのコンピュータープログラム製品であって、
第１のユーザー要求に応答してリニア再生ビデオの再生を開始すること、
タイムスタンプから成る第２のユーザー要求を受け取ること、
タイムスタンプに基づき、特定の対話型ビデオスクリプトの特定の場所を選択することと、
事前選択されたメタデータに基づき、さらなるユーザー入力への応答を含め、特定の場所から、特定の対話型ビデオスクリプトを再生する。

【発明の詳細な説明】

【技術分野】

【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】

【図1】本発明の１つの実施例に従って対話型リアルタイムマルチメディアアプリケーションをサポートする、分散型クライアント−サーバーコンピューターシステムのブロック図である。

【図2】ビデオクリップを配信するために本発明の実施例により利用されている、コンテンツデリバリネットワーク（ＣＤＮ）と複数のインターネットデータセンター（ＩＤＣ）から成る、ビデオストリーミングインフラストラクチャのブロック図である。

【図3】本発明の実施例に従って、対話型ビデオクリップ生産と再生システムを描く図である。

【図4】本発明の実施例に従った、ビデオクリップ生産と再生プロセスのフロー図である。

【図5】本発明の実施例に従って、ビデオクリップのグラフ構造化されたセットを描く。

【図6】本発明の実施例に従って、リニアビデオから対話型ビデオスクリプトにリンクさせるためのシステムを描く。

【図7】本発明の実施例に従って、リニアビデオから対話型ビデオスクリプトにリンクさせるための方法を描く。

【符号の説明】

【0068】

１０００分散型クライアント−サーバーコンピューターシステム
１０１サーバーコンピューター
１０２ネットワーク
１０３ユーザーデバイス
１１０中央処理装置ＣＰＵ
１１１ストレージ
１１２メモリ
１２０中央処理装置（ＣＰＵ）
１２１ストレージ
１２２メモリ
１３１コンピュータープログラム製品
２０００ビデオストリーミングインフラストラクチャ
２００コンテンツデリバリーネットワーク（ＣＤＮ）
２０１メディアファイル
２０２ファイルストレージ
２１０−２６０ＩＤＣ
２１１−２６１メディアファイルのコピー
３０００システム
３１０コンピュータープログラム
３２０プログラム出力
３３０プログラム入力
３４０アプリケーション相互作用コンテナ
３５０入力周辺機器
３６０コンピュータープログラムビデオ処理プラットフォーム
３７０ビデオセグメントまたはクリップ
３８０メタデータ
３９０データベース
４１０−４９０ステップ
５０００ビデオクリップセット
５１０ビデオクリップ
５２０ビデオクリップ
５３０ビデオクリップ
５４０ビデオクリップ
５５０ビデオクリップ
５６０ビデオクリップ
５７０ビデオクリップ
６０２ビデオストリーミングインフラストラクチャ
６０４対話型ビデオ配信インフラストラクチャ
６０６ユーザーデバイス
６０７画面
６０８ユーザーは画面の場所
７１０−７９０ステップ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【外国語明細書】

2017098948000001.pdf