特表 2024-545176 シーンベースの没入型メディアをゲームエンジンにストリーミングするためのスマートクライアント

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

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

(11)【公表番号】

(43)【公表日】2024-12-05

(54)【発明の名称】シーンベースの没入型メディアをゲームエンジンにストリーミングするためのスマートクライアント

(51)【国際特許分類】

   H04N 21/462 20110101AFI20241128BHJP

   H04N 21/442 20110101ALI20241128BHJP

   H04N 21/6587 20110101ALI20241128BHJP

【ＦＩ】

H04N21/462

H04N21/442

H04N21/6587

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024534586

(86)(22)【出願日】2023-04-04

(85)【翻訳文提出日】2024-06-10

(86)【国際出願番号】 US2023017398

(87)【国際公開番号】W WO2023204969

(87)【国際公開日】2023-10-26

(31)【優先権主張番号】63/332,853

(32)【優先日】2022-04-20

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】63/345,814

(32)【優先日】2022-05-25

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】63/346,105

(32)【優先日】2022-05-26

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】63/351,218

(32)【優先日】2022-06-10

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】63/400,364

(32)【優先日】2022-08-23

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】18/126,120

(32)【優先日】2023-03-24

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】520353802

【氏名又は名称】テンセント・アメリカ・エルエルシー

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾 直樹

(72)【発明者】

【氏名】アリアンヌ・ハインズ

(72)【発明者】

【氏名】ステファン・ヴェンガー

(72)【発明者】

【氏名】ポール・スペンサー・ドーキンス

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

5C164

【Ｆターム（参考）】

5C164TC13P

5C164UA31S

5C164UB26S

5C164UB41P

5C164UB81S

5C164UC21P

5C164YA18

5C164YA20

(57)【要約】

本開示の態様は、メディア処理のための方法及び装置（電子デバイス）を提供する。幾つかの例において、電子デバイスは、没入型メディアストリーミングネットワークへの電子デバイスのクライアントインタフェースであるスマートクライアントのプロセスを行うための処理回路を含む。メディア処理のための方法は、電子デバイスのクライアントインタフェースにより、没入型メディアストリーミングネットワーク内のサーバデバイスに対して、シーンベースの没入型メディアを再生するための電子デバイスの能力及び利用可能性の情報を送信するステップを含む。更に、方法は、クライアントインタフェースにより、シーンベースの没入型メディアのための適応したメディアコンテンツを搬送するメディアストリームを受信するステップを含む。適応したメディアコンテンツは、能力及び利用可能性の情報に基づいてサーバデバイスによってシーンベースの没入型メディアから生成される。その後、方法は、適応したメディアコンテンツに従ってシーンベースの没入型メディアを再生するステップを含む。

【特許請求の範囲】

【請求項1】

電子デバイスにおけるメディア処理の方法において、
前記電子デバイスのクライアントインタフェースにより、没入型メディアストリーミングネットワーク内のサーバデバイスに対し、シーンベースの没入型メディアを再生するための前記電子デバイスの能力及び利用可能性の情報を送信するステップと、
前記クライアントインタフェースにより、前記シーンベースの没入型メディアのための適応したメディアコンテンツを搬送するメディアストリームを受信するステップであって、前記適応したメディアコンテンツは、前記能力及び利用可能性の情報に基づいて前記サーバデバイスにより前記シーンベースの没入型メディアから生成される、ステップと、
前記適応したメディアコンテンツに従って前記シーンベースの没入型メディアを再生するステップと
を含む、方法。

【請求項2】

前記クライアントインタフェースにより、第1のシーンと関連付けられる第1のメディアアセットが初めて受信され、前記適応したメディアコンテンツに従って1つ以上のシーンで再利用されるべきであると決定するステップと、
前記第1のメディアアセットを、前記電子デバイスによってアクセス可能なキャッシュデバイスに記憶するステップと
を更に含む、請求項1に記載の方法。

【請求項3】

前記クライアントインタフェースにより、前記メディアストリームから前記第1のシーン内の固有のアセットの第1のリストを抽出するステップであって、前記固有のアセットの第1のリストは、前記第1のメディアアセットを1つ以上の他のシーンで使用されるべき前記第1のシーン内の固有のアセットとして識別する、ステップ、
を更に含む、請求項2に記載の方法。

【請求項4】

前記能力及び利用可能性の情報を送信する前記ステップは、
前記クライアントインタフェースにより、前記電子デバイスにおける前記第1のメディアアセットの利用可能性を示す信号を前記サーバデバイスに送信するステップであって、前記信号は、前記サーバデバイスに、前記適応したメディアコンテンツ内の前記第1のメディアアセットの代わりにプロキシを使用させる、ステップ、
を含む、請求項2に記載の方法。

【請求項5】

前記シーンベースの没入型メディアを再生する前記ステップは、
前記クライアントインタフェースにより、前記第1のメディアアセットが前記適応したメディアコンテンツ内の前記プロキシに従って前記キャッシュデバイスに以前に記憶されていると決定するステップと、
前記第1のメディアアセットを取り出すために前記キャッシュデバイスにアクセスするステップと
を更に含む、請求項4に記載の方法。

【請求項6】

前記第1のメディアアセットの前記利用可能性を示す前記信号を送信する前記ステップは、
前記サーバデバイスから前記第1のメディアアセットに関する問合せ信号を受信するステップと、
前記問合せ信号に応答して、前記電子デバイスにおける前記第1のメディアアセットの前記利用可能性を示す前記信号を送信するステップと
を含む、請求項4に記載の方法。

【請求項7】

前記能力及び利用可能性の情報を送信する前記ステップは、
前記クライアントインタフェースにより、前記サーバデバイスからデバイス属性及びリソース状態を取得する要求を受信するステップと、
前記電子デバイスの属性と前記シーンベースの没入型メディアを処理するためのリソース利用可能性とに関して前記電子デバイスの1つ以上の内部構成要素及び／又は前記電子デバイスと関連付けられる1つ以上の外部構成要素に問い合わせるステップと、
前記電子デバイスの前記属性及び前記リソース利用可能性を前記サーバデバイスに送信するステップと
を含む、請求項1に記載の方法。

【請求項8】

ユーザインタフェースから前記シーンベースの没入型メディアの要求を受信するステップと、
前記クライアントインタフェースにより、前記シーンベースの没入型メディアの前記要求を前記サーバデバイスに転送するステップと
を更に含む、請求項1に記載の方法。

【請求項9】

前記シーンベースの没入型メディアを再生する前記ステップは、
前記クライアントインタフェースの制御下で、前記メディアストリームのデコーディング及びメディア再構成に基づいて再構成されたシーンベースの没入型メディアを生成するステップと、
前記電子デバイスのゲームエンジンのアプリケーションプログラミングインタフェース（API）を介して、前記再構成されたシーンベースの没入型メディアを再生するために前記ゲームエンジンに提供するステップと
を更に含む、請求項1に記載の方法。

【請求項10】

前記シーンベースの没入型メディアを再生する前記ステップは、
前記クライアントインタフェースにより、前記メディアストリームをデパケット化して、デパケット化されたメディアデータを生成するステップと、
前記電子デバイスのゲームエンジンのアプリケーションプログラミングインタフェース（API）を介して、前記デパケット化されたメディアデータを前記ゲームエンジンに提供するステップと、
前記ゲームエンジンにより、前記デパケット化されたメディアデータに基づいて再生するための再構成されたシーンベースの没入型メディアを生成するステップと
を更に含む、請求項1に記載の方法。

【請求項11】

処理回路を備える電子デバイスであって、前記処理回路は、
没入型メディアストリーミングネットワーク内のサーバデバイスに対し、シーンベースの没入型メディアを再生するための前記電子デバイスの能力及び利用可能性の情報を送信し、
前記シーンベースの没入型メディアのための適応したメディアコンテンツを搬送するメディアストリームを受信し、前記適応したメディアコンテンツは、前記能力及び利用可能性の情報に基づいて前記サーバデバイスにより前記シーンベースの没入型メディアから生成され、
前記適応したメディアコンテンツに従って前記シーンベースの没入型メディアを再生する、
ように構成される、電子デバイス。

【請求項12】

前記処理回路は、
第1のシーンと関連付けられる第1のメディアアセットが初めて受信され、前記適応したメディアコンテンツに従って1つ以上のシーンで再利用されるべきであると決定し、
前記第1のメディアアセットを、前記電子デバイスによってアクセス可能なキャッシュデバイスに記憶する、
ように構成される、請求項11に記載の電子デバイス。

【請求項13】

前記処理回路は、
前記メディアストリームから前記第1のシーン内の固有のアセットの第1のリストを抽出し、前記固有のアセットの第1のリストは、前記第1のメディアアセットを1つ以上の他のシーンで使用されるべき前記第1のシーン内の固有のアセットとして識別する、
ように構成される、請求項12に記載の電子デバイス。

【請求項14】

前記処理回路は、
前記電子デバイスにおける前記第1のメディアアセットの利用可能性を示す信号を前記サーバデバイスに送信し、前記信号は、前記サーバデバイスに、前記適応したメディアコンテンツ内の前記第1のメディアアセットの代わりにプロキシを使用させる、
ように構成される、請求項12に記載の電子デバイス。

【請求項15】

前記処理回路は、
前記第1のメディアアセットが前記適応したメディアコンテンツ内の前記プロキシに従って前記キャッシュデバイスに以前に記憶されていると決定し、
前記第1のメディアアセットを取り出すために前記キャッシュデバイスにアクセスする、
ように構成される、請求項14に記載の電子デバイス。

【請求項16】

前記処理回路は、
前記サーバデバイスから前記第1のメディアアセットに関する問合せ信号を受信し、
前記問合せ信号に応答して、前記電子デバイスにおける前記第1のメディアアセットの前記利用可能性を示す前記信号を送信する、
ように構成される、請求項14に記載の電子デバイス。

【請求項17】

前記処理回路は、
前記サーバデバイスからデバイス属性及びリソース状態を取得する要求を受信し、
前記電子デバイスの属性と前記シーンベースの没入型メディアを処理するためのリソース利用可能性とに関して前記電子デバイスの1つ以上の内部構成要素及び／又は前記電子デバイスと関連付けられる1つ以上の外部構成要素に問い合わせ、
前記電子デバイスの前記属性及び前記リソース利用可能性を前記サーバデバイスに送信する、
ように構成される、請求項11に記載の電子デバイス。

【請求項18】

前記処理回路は、
ユーザインタフェースから前記シーンベースの没入型メディアの要求を受信し、
前記シーンベースの没入型メディアの前記要求を前記サーバデバイスに転送する、
ように構成される、請求項11に記載の電子デバイス。

【請求項19】

前記処理回路は、
前記メディアストリームのデコーディング及びメディア再構成に基づいて再構成されたシーンベースの没入型メディアを生成し、
前記電子デバイスのゲームエンジンのアプリケーションプログラミングインタフェース（API）を介して、前記再構成されたシーンベースの没入型メディアを再生するために前記ゲームエンジンに提供する、
ように構成される、請求項11に記載の電子デバイス。

【請求項20】

前記処理回路は、
前記メディアストリームをデパケット化して、デパケット化されたメディアデータを生成し、
前記電子デバイスのゲームエンジンのアプリケーションプログラミングインタフェース（API）を介して、前記デパケット化されたメディアデータを前記ゲームエンジンに提供し、
前記ゲームエンジンにより、前記デパケット化されたメディアデータに基づいて再生するための再構成されたシーンベースの没入型メディアを生成する、
ように構成される、請求項11に記載の電子デバイス。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、2022年4月20日に出願された米国仮出願第63／332，853号「シーンベースの没入型メディアをゲームエンジンにストリーミングするためのスマートクライアント」に対する優先権の利益を主張する2023年3月24日に出願された米国特許出願第18／126，120号「シーンベースの没入型メディアをゲームエンジンにストリーミングするためのスマートクライアント」、2022年5月25日に出願された米国仮出願第63／345，814号「パーソナル化された経験のための視覚的没入型メディアアセットの置換」、2022年5月26日に出願された米国仮出願第63／346，105号「パーソナル化された経験のための非視覚的没入型メディアアセットの置換」、2022年6月10日に出願された米国仮出願第63／351，218号「ネットワークベースのメディア適応のためのスマートコントローラ」、及び2022年8月23日に出願された米国仮出願第63／400，364号「異種レンダリングベースのクライアントをサポートするためのクライアントのシーンベースの没入型メディアプロファイル」に対する優先権の利益を主張する。先の出願の開示全体は、参照によりその全体が本明細書に組み込まれる。

【0002】

本開示は、一般にメディア処理及び配信に関する実施形態を説明する。

【背景技術】

【0003】

本明細書で提供される背景技術の説明は、本開示の文脈を一般的に提示することを目的とする。この背景技術の項に記載されている限りにおいて、本発明者らの研究、並びに出願時に先行技術として認められない可能性がある説明の態様は、本開示に対する先行技術として明示的にも暗示的にも認められない。

【0004】

没入型メディアは、一般に、タイムド2次元（2D）ビデオ及び「レガシーメディア」として知られている対応するオーディオのために既存の商用ネットワークを介して配信されるものを超えるなど、任意の又は全ての人間の感覚システム（視覚、聴覚、体性感覚、嗅覚、及び場合によっては味覚）を刺激して、メディアの体験に物理的に存在するユーザの知覚を作成又は強化するメディアを指す。没入型メディアとレガシーメディアの両方は、タイムドメディア又は非タイムドメディアのいずれかとして特徴付けられ得る。

【0005】

タイムドメディアは、時間に従って構造化され提示されるメディアを指す。例としては、映画の特集、ニュース報道、エピソードコンテンツが挙げられ、これらは全て、期間に従って編成される。従来のビデオ及びオーディオは、一般にタイムドメディアであると考えられている。

【0006】

非タイムドメディアは、時間によって構造化されず、むしろ、論理的、空間的及び／又は時間的関係によって構造化されたメディアである。一例は、ユーザがゲームデバイスによって作成された体験を制御するビデオゲームを含む。非タイムドメディアの他の例は、カメラによって撮影された静止画像写真である。非タイムドメディアは、例えば、ビデオゲームのシーンの連続的にループされたオーディオ又はビデオセグメントにタイムドメディアを組み込んでもよい。逆に、タイムドメディアは、例えば背景として固定静止画像を有するビデオなどの非タイムドメディアを組み込んでもよい。

【0007】

没入型メディア対応デバイスは、没入型メディアにアクセス、解釈、及び提示する能力を備えたデバイスを指すことができる。そのようなメディア及びデバイスは、メディアの数及びフォーマット、並びにそのようなメディアを大規模に配信するために、すなわち、ネットワークを介してレガシービデオ及びオーディオメディアと同等の配信を達成するために必要なネットワークリソースの数及びタイプに関して異種である。対照的に、ラップトップディスプレイ、テレビ、及びモバイルハンドセットディスプレイなどのレガシーデバイスは、これらのデバイスの全てが長方形のディスプレイスクリーンで構成され、それらのプライマリメディアフォーマットとして2D長方形のビデオ又は静止画像を消費するため、それらの能力において均一である。

【発明の概要】

【課題を解決するための手段】

【0008】

本開示の態様は、メディア処理のための方法及び装置（電子デバイス）を提供する。幾つかの例において、電子デバイスは、電子デバイスのクライアントインタフェースであるスマートクライアントのプロセスを行うための処理回路を含む。メディア処理のための方法は、電子デバイスのクライアントインタフェースにより、ネットワーク内のサーバデバイス（例えば、没入型メディアストリーミングネットワーク）に対して、シーンベースの没入型メディアを再生するための電子デバイスの能力及び利用可能性の情報を送信するステップを含む。更に、方法は、クライアントインタフェースにより、シーンベースの没入型メディアのための適応したメディアコンテンツを搬送するメディアストリームを受信するステップを含む。適応したメディアコンテンツは、能力及び利用可能性の情報に基づいてサーバデバイスによりシーンベースの没入型メディアから生成される。その後、方法は、適応したメディアコンテンツに従ってシーンベースの没入型メディアを再生するステップを含む。

【0009】

幾つかの例において、方法は、クライアントインタフェースにより、第1のシーンと関連付けられる第1のメディアアセットが初めて受信され、適応したメディアコンテンツに従って1つ以上のシーンで再利用されるべきであると決定するステップと、第1のメディアアセットを、電子デバイスによってアクセス可能なキャッシュデバイスに記憶するステップとを含む。

【0010】

幾つかの例において、方法は、クライアントインタフェースにより、メディアストリームから第1のシーン内の固有のアセットの第1のリストを抽出するステップを含み、固有のアセットの第1のリストは、第1のメディアアセットを1つ以上の他のシーンで使用されるべき第1のシーン内の固有のアセットとして識別する。

【0011】

幾つかの例において、方法は、クライアントインタフェースにより、電子デバイスにおける第1のメディアアセットの利用可能性を示す信号をサーバデバイスに送信するステップを含む。信号は、サーバデバイスに、、適応したメディアコンテンツ内の第1のメディアアセットの代わりにプロキシを使用させる。

【0012】

幾つかの例において、方法は、クライアントインタフェースにより、第1のメディアアセットが適応したメディアコンテンツ内のプロキシに従ってキャッシュデバイスに以前に記憶されていると決定するステップと、第1のメディアアセットを取り出すためにキャッシュデバイスにアクセスするステップとを含む。

【0013】

幾つかの例において、方法は、サーバデバイスから第1のメディアアセットに関する問合せ信号を受信するステップと、問合せ信号に応答して、電子デバイスにおける第1のメディアアセットの利用可能性を示す信号を送信するステップとを含む。

【0014】

幾つかの例において、方法は、クライアントインタフェースにより、サーバデバイスからデバイス属性及びリソース状態を取得する要求を受信するステップと、電子デバイスの属性とシーンベースの没入型メディアを処理するためのリソース利用可能性とに関して電子デバイスの1つ以上の内部構成要素及び／又は電子デバイスと関連付けられる1つ以上の外部構成要素に問い合わせるステップと、電子デバイスの属性及びリソース利用可能性をサーバデバイスに送信するステップとを含む。

【0015】

幾つかの例において、方法は、ユーザインタフェースからシーンベースの没入型メディアの要求を受信するステップと、クライアントインタフェースにより、シーンベースの没入型メディアの要求をサーバデバイスに転送するステップとを含む。

【0016】

幾つかの例において、方法は、クライアントインタフェースの制御下で、メディアストリームのデコーディング及びメディア再構成に基づいて再構成されたシーンベースの没入型メディアを生成するステップと、電子デバイスのゲームエンジンのアプリケーションプログラミングインタフェース（API）を介して、再構成されたシーンベースの没入型メディアを再生するためにゲームエンジンに提供するステップとを含む。

【0017】

幾つかの例において、方法は、クライアントインタフェースにより、メディアストリームをデパケット化して、デパケット化されたメディアデータを生成するステップと、電子デバイスのゲームエンジンのアプリケーションプログラミングインタフェース（API）を介して、デパケット化されたメディアデータをゲームエンジンに提供するステップと、ゲームエンジンにより、デパケット化されたメディアデータに基づいて再生するための再構成されたシーンベースの没入型メディアを生成するステップとを含む。

【0018】

本開示の態様はまた、コンピュータによって実行されると、コンピュータにメディア処理のための方法を行わせる命令を記憶する非一時的コンピュータ可読媒体を提供する。

【0019】

開示された主題の更なる特徴、性質及び様々な利点は、以下の詳細な説明及び添付の図面から、より明らかになり得る。

【図面の簡単な説明】

【0020】

【図1】幾つかの例におけるメディアフロープロセスを示す。

【図2】幾つかの例におけるメディア変換意思決定プロセスを示す。

【図3】一例ではタイムドである異種没入型メディアにおけるフォーマットの表示を示す。

【図4】一例では非タイムドである異種没入型メディアにおけるストリーミング可能フォーマットの表示を示す。

【図5】幾つかの例における自然コンテンツからインジェストフォーマットにメディアを合成するプロセスを示す図を示す。

【図6】幾つかの例における合成メディアのインジェストフォーマットを作成するプロセスの図を示す。

【図7】一実施形態に係るコンピュータシステムの概略図である。

【図8】幾つかの例においてクライアントエンドポイントとして様々なレガシー及び異種没入型メディア対応ディスプレイをサポートするネットワークメディア配信システムを示す。

【図9】幾つかの例におけるレガシー及び異種没入型メディア対応ディスプレイにサービスを提供することができる没入型メディア配信モジュールの図を示す。

【図10】幾つかの例におけるメディア適応プロセスの図を示す。

【図11】幾つかの例における配信フォーマット作成プロセスを示す。

【図12】幾つかの例におけるパケタイザプロセスシステムを示す。

【図13】幾つかの例においてインジェストフォーマットにおける特定の没入型メディアを特定の没入型メディアクライアントエンドポイントのためのストリーミング可能で適切な配信フォーマットに適応させるネットワークのシーケンス図を示す。

【図14】幾つかの例におけるシーンベースのメディア処理のための仮想ネットワーク及びクライアントデバイスを有するメディアシステムの図を示す。

【図15】幾つかの例におけるネットワークを介したクライアントデバイスへのメディア配信のためのメディアフロー処理の図である。

【図16】幾つかの例におけるゲームエンジンプロセスへのアセット再利用を伴うメディアフロープロセスの図を示す。

【図17】幾つかの例におけるクライアントデバイスのためのアセット再利用論理及び冗長キャッシュを伴うメディア変換意思決定プロセスの図を示す。

【図18】幾つかの例におけるスマートクライアントを用いたアセット再利用論理の図である。

【図19】幾つかの例におけるスマートクライアントで取得されたデバイス状態及びプロファイルのためのプロセスの図を示す。

【図20】クライアントデバイスのゲームエンジンに代わってネットワークからストリーミングされるメディアを要求及び受信するクライアントデバイスにおけるスマートクライアントを示すためのプロセスの図を示す。

【図21】幾つかの例における降順の頻度により順序付けられたタイムドメディア表示の図を示す。

【図22】幾つかの例における頻度によって順序付けられた非タイムドメディア表示の図を示す。

【図23】幾つかの例における順序付けられた頻度を用いた配信フォーマット作成プロセスを示す。

【図24】幾つかの例におけるメディア再利用分析器のための論理フローのフローチャートを示す。

【図25】幾つかの例におけるクライアントデバイス内のスマートクライアント及びゲームエンジンと通信するネットワークプロセスの図を示す。

【図26】本開示の一実施形態に係るプロセスを概説するフローチャートを示す。

【図27】本開示の一実施形態に係るプロセスを概説するフローチャートを示す。

【図28】幾つかの例における視覚アセットの置換のシグナリングを伴うタイムドメディア表示の図を示す。

【図29】幾つかの例における視覚アセットの置換のシグナリングを伴う非タイムドメディア表示の図を示す。

【図30】幾つかの例における非視覚アセットにおける置換のシグナリングを伴うタイムドメディア表示の図を示す。

【図31】幾つかの例における非視覚アセットの置換のシグナリングを伴う非タイムドメディア表示の図を示す。

【図32】本開示の幾つかの実施形態に係るクライアントデバイスにおいてユーザ提供のアセットでアセット置換を行うプロセスを示す。

【図33】本開示の幾つかの実施形態に係るクライアントデバイスにおいてユーザ提供メディアキャッシュをポピュレートするためのプロセスを示す。

【図34】本開示の一実施形態に係るプロセスを概説するフローチャートを示す。

【図35】幾つかの例におけるネットワークベースのメディア変換を行うためのプロセスを示す。

【図36】幾つかの例におけるネットワーク内のスマートコントローラにおいてネットワークベースのメディア適応を行うためのプロセスを示す。

【図37】本開示の一実施形態に係るプロセスを概説するフローチャートを示す。

【図38】幾つかの例におけるクライアントメディアプロファイルの図を示す。

【図39】本開示の一実施形態に係るプロセスを概説するフローチャートを示す。

【図40】本開示の一実施形態に係るプロセスを概説するフローチャートを示す。

【発明を実施するための形態】

【0021】

本開示の態様は、ビデオ、オーディオ、幾何（3D）オブジェクト、触覚、関連するメタデータ、又はクライアントデバイスのための他のコンテンツを含むメディアを配信するためのアーキテクチャ、構造、構成要素、技法、システム、及び／又はネットワークを提供する。幾つかの例では、アーキテクチャ、構造、構成要素、技法、システム及び／又はネットワークは、異種没入型及び対話型クライアントデバイス、例えばゲームエンジンにメディアコンテンツを配信するように構成される。

【0022】

没入型メディアは、一般に、任意の又は全ての人間の感覚システム（視覚、聴覚、体性感覚、嗅覚、及び場合によっては味覚）を刺激して、メディアの体験に物理的に存在するユーザの知覚を作成又は強化する、すなわち、タイムド2次元（2D）ビデオ及び「レガシーメディア」として知られている対応するオーディオのために既存の商用ネットワークを介して配信されるものを超えるメディアを指す。幾つかの例では、没入型メディアは、速度論及び物理法則のデジタルシミュレーションを通じて物理世界を作成又は模倣しようとするメディアを指し、それにより、現実世界又は仮想世界を描写するシーン内に物理的に存在するというユーザによる知覚を作成するように、任意又は全ての人間の感覚システムを刺激する。没入型メディアとレガシーメディアの両方は、タイムドメディア又は非タイムドメディアのいずれかとして特徴付けられ得る。

【0023】

タイムドメディアは、時間に従って構造化され提示されるメディアを指す。例としては、映画の特集、ニュース報道、エピソードコンテンツが挙げられ、これらは全て、期間に従って編成される。従来のビデオ及びオーディオは、一般にタイムドメディアであると考えられている。

【0024】

非タイムドメディアは、時間によって構造化されず、むしろ、論理的、空間的及び／又は時間的関係によって構造化されたメディアである。一例は、ユーザがゲームデバイスによって作成された体験を制御するビデオゲームを含む。非タイムドメディアの他の例は、カメラによって撮影された静止画像写真である。非タイムドメディアは、例えば、ビデオゲームのシーンの連続的にループされたオーディオ又はビデオセグメントにタイムドメディアを組み込んでもよい。逆に、タイムドメディアは、例えば背景として固定静止画像を有するビデオなどの非タイムドメディアを組み込んでもよい。

【0025】

没入型メディア対応デバイスは、没入型メディアにアクセスし、解釈し、提示するのに十分なリソース及び能力を備えたデバイスを指すことができる。そのようなメディア及びデバイスは、メディアの数及びフォーマット、並びにそのようなメディアを大規模に配信するために、すなわち、ネットワークを介してレガシービデオ及びオーディオメディアと同等の配信を達成するために必要なネットワークリソースの数及びタイプに関して異種である。同様に、メディアは、このようなメディアを大規模に配信するのに必要なネットワークリソースの量及び種類の点で異質である。「大規模に」とは、ネットワークを介したレガシーのビデオ及びオーディオメディアの配信と同等の配信を達成するサービスプロバイダによるメディアの配信、例えば、Netflix、Hulu、Comcastのサブスクリプション、及びSpectrumのサブスクリプションを指すことがある。

【0026】

対照的に、ラップトップディスプレイ、テレビ、及びモバイルハンドセットディスプレイなどのレガシーデバイスは、これらのデバイスの全てが長方形のディスプレイスクリーンで構成され、それらのプライマリメディアフォーマットとして2D長方形のビデオ又は静止画像を消費するため、それらの能力において均一である。同様に、レガシーデバイスでサポートされるオーディオフォーマットの数は、比較的少ないセットに制限される。

【0027】

「フレームベースの」メディアという用語は、視覚メディアが画像の1つ以上の連続した矩形フレームで構成されるという特性を指す。対照的に、「シーンベースの」メディア（例えば、シーンベースの没入型メディア）は、幾つかの例では、各シーンが視覚シーンを集合的に記述する個々のアセットを指す「シーン」によって編成された視覚メディアを指す。

【0028】

フレームベースの視覚メディアとシーンベースの視覚メディアとの比較例は、フォレストを示す視覚メディアを使用して記述することができる。フレームベースの表示では、フォレストは、カメラ付きの携帯電話などのカメラデバイスを使用して捕捉される。ユーザは、カメラデバイスがフォレストに焦点を合わせることを可能にすることができ、カメラデバイスによってインジェストされるフレームベースのメディアは、ユーザによって開始されるカメラデバイスの任意の動きを含む、カメラデバイスに提供されるカメラビューポートを通してユーザが見るものと同じである。結果として得られるフォレストのフレームベースの表示は、通常30フレーム／秒又は60フレーム／秒の標準レートでカメラデバイスによって記録される一連の2D画像である。各画像は、各画素に記憶された情報が次の画素と一致する画素の集合である。

【0029】

対照的に、フォレストのシーンベースの表示は、フォレスト内のオブジェクトのそれぞれを記述する個々のアセットから構成される。例えば、シーンベースの表示は、「木」と呼ばれる個々のオブジェクトを含むことができ、各木は、「幹」、「枝」、及び「葉」と呼ばれるより小さなアセットの集合で構成される。各木の幹は、木の幹の完全な3Dジオメトリと、木の幹の色及び放射輝度特性を捕捉するために木の幹メッシュに適用されるテクスチャとを記述するメッシュ（木の幹メッシュ）によって個別に更に記述することができる。更に、木の幹は、その滑らかさもしくは粗さ又は光を反射する能力に関して木の幹の表面を記述する追加の情報を伴うことができる。シーンを構成する個々のアセットは、各アセットに記憶される情報のタイプと量が異なる。

【0030】

シーンベースのメディアとフレームベースのメディアとの間の更に別の違いは、フレームベースのメディアでは、シーンに対して作成されるビューは、ユーザがカメラを介して取り込んだ、すなわちメディアが作成されたときのビューと同一であることである。フレームベースのメディアがクライアントによって提示されるとき、提示されるメディアのビューは、例えばビデオを記録するために使用されたカメラによってメディアにインジェストされたビューと同じである。しかしながら、シーンベースのメディアでは、ユーザがシーンを見るための複数の方法が存在し得る。

【0031】

シーンベースのメディアをサポートするクライアントデバイスは、様々なシーンベースのメディアフォーマットをインジェストするクライアントデバイスの全能力を特徴付けるために、その能力及びサポートされる機能が集合的に上限又は上限を含むレンダラ及び／又はリソース（例えば、GPU、CPU、ローカルメディアキャッシュストレージ）を装備することができる。例えば、モバイル・ハンドセット・クライアント・デバイスは、特にリアルタイムアプリケーションのサポートのために、モバイル・ハンドセット・クライアント・デバイスがレンダリングすることができる幾何学的アセットの複雑さ、例えば幾何学的アセットを記述するポリゴンの数が制限され得る。このような制限は、モバイルクライアントがバッテリによって電力を供給されるという事実に基づいて確立することができ、したがって、リアルタイムレンダリングを行うために利用可能な計算リソースの量も同様に制限される。そのようなシナリオでは、クライアントデバイスは、クライアントが指定された上限以下のポリゴンカウントで幾何学的アセットにアクセスすることを好むことをネットワークに通知することが望ましい場合がある。更に、クライアントからネットワークに伝達される情報は、明確に定義された属性の語彙を活用する明確に定義されたプロトコルを使用して最良に伝達され得る。

【0032】

同様に、メディア配信ネットワークは、様々な機能を有する様々なクライアントへの様々なフォーマットでの没入型メディアの配信を容易にする計算リソースを有することができる。そのようなネットワークでは、ネットワークが、明確に定義されたプロファイルプロトコル、例えば、明確に定義されたプロトコルを介して通信される属性の語彙に従ってクライアント固有の能力を知らされることが望ましい場合がある。そのような属性の語彙は、ネットワークがその異種クライアントにメディアをどのようにサービスするかについての優先順位をより良好に確立することができるように、リアルタイムでメディアをレンダリングするために必要なメディア又は最小計算リソースを記述するための情報を含むことができる。更に、クライアントが提供するプロファイル情報がクライアントのドメインにわたって収集される集中データストアは、どのタイプのアセットで、どのフォーマットで需要が高いかの要約を提供するのに役立つ。どのタイプのアセットがより高い需要とより低い需要とにあるかに関する情報でプロビジョニングされることにより、最適化されたネットワークは、より高い需要にあるアセットの要求に応答するタスクを優先することができる。

【0033】

幾つかの例では、ネットワークを介したメディアの配信は、入力又はネットワーク「インジェスト」メディアフォーマットから配信メディアフォーマットにメディアを再フォーマットするメディア配信システム及びアーキテクチャを採用することができる。一例では、配信メディアフォーマットは、ターゲットクライアントデバイス及びそのアプリケーションによってインジェストされるのに適しているだけでなく、ネットワークを介して「ストリーミング」されるのにも役立つ。幾つかの例では、ネットワークによってインジェストされたメディアに対して行われる2つのプロセス、すなわち、1）メディアをフォーマットAから、ターゲットクライアントデバイスによって、すなわち、特定のメディアフォーマットをインジェストするクライアントデバイスの能力に基づいて、インジェストされるのに適したフォーマットBに変換するプロセス、及び2）ストリーミングされるメディアを準備するプロセスがあり得る。

【0034】

幾つかの例では、メディアの「ストリーミング」は、処理されたメディアがメディアの時間的又は空間的構造のいずれか又は両方に従って論理的に編成及びシーケンス化された連続したより小さいサイズの「チャンク」でネットワークを介して配信され得るように、メディアの断片化及び／又はパケット化を広く指す。幾つかの例では、フォーマットAからフォーマットBへのメディアの「変換」（「トランスコーディング」と呼ばれることもある）は、ターゲットクライアントデバイスにメディアを配信する前に、通常はネットワーク又はサービスプロバイダによって行われるプロセスであってもよい。そのようなトランスコーディングは、フォーマットBが、何らかの形で、ターゲットクライアントデバイスによってインジェストされ得る好ましいフォーマットであるか、又は唯一のフォーマットであるか、又は商用ネットワークなどの制約のあるリソース上での配信により適しているという事前知識に基づいて、フォーマットAからフォーマットBにメディアを変換することを含むことができる。メディアの変換の一例は、シーンベース表示からフレームベース表示へのメディアの変換である。幾つかの例では、メディアを変換し、ストリーミングされるメディアを準備する両方のステップは、ネットワークからターゲットクライアントデバイスによってメディアを受信し処理することができる前に必要である。クライアントが好むフォーマットに関するそのような事前知識は、様々なクライアントデバイスにわたって好まれるシーンベースのメディアの特性を要約する、合意された属性の語彙を利用する明確に定義されたプロファイルプロトコルの使用を介して取得することができる。

【0035】

幾つかの例では、上記の1つ又は2ステップのプロセスは、ネットワークによってインジェストされたメディアに作用し、すなわち、ターゲットクライアントデバイスにメディアを配信する前に、「配信メディアフォーマット」又は単に「配信フォーマット」と呼ばれるメディアフォーマットをもたらす。一般に、これらのステップは、所与のメディアデータオブジェクトに対して行われる場合、そうでなければそのようなメディアの変換及びストリーミングを複数回トリガすることになる複数の機会のためにターゲットクライアントデバイスが変換及び／又はストリーミングされたメディアオブジェクトを必要とすることを示す情報にネットワークがアクセスできる場合、1回だけ行われることができる。すなわち、メディアの変換及びストリーミングのためのデータの処理及び転送は、一般に、潜在的にかなりの量のネットワーク及び／又は計算リソースの消費を必要とするレイテンシの発生源と見なされる。したがって、クライアントデバイスがそのキャッシュに既に記憶されているか、又はクライアントデバイスに対してローカルに記憶されている特定のメディアデータオブジェクトを既に有している可能性があるときを示すための情報にアクセスすることができないネットワーク設計は、そのような情報にアクセスすることができるネットワークに対して準最適に行われる。

【0036】

幾つかの例では、レガシープレゼンテーションデバイスの場合、配信フォーマットは、プレゼンテーションを作成するためにクライアントデバイス（例えば、クライアントプレゼンテーションデバイス）によって最終的に使用される「プレゼンテーションフォーマット」と同等又は十分に同等であり得る。例えば、プレゼンテーション・メディア・フォーマットは、そのプロパティ（解像度、フレームレート、ビット深度、色域など…）がクライアントプレゼンテーションデバイスの能力に密接に調整されているメディアフォーマットである。配信フォーマット対プレゼンテーションフォーマットの一部の例は、ネットワークによって解像度（3840画素列×2160画素行）の超高解像度（UHD）クライアントデバイスに配信される高解像度（HD）ビデオ信号（1920画素列×1080画素行）を含む。例えば、UHDのクライアントデバイスでは、HDの配信フォーマットに「超解像」と呼ばれる処理を適用して、ビデオ信号の解像度をHDからUHDに上げることができる。したがって、UHDクライアントデバイスによって提示される最終的な信号フォーマットは、この例ではUHD信号である「プレゼンテーションフォーマット」であるが、HD信号は配信フォーマットを含む。本例では、HD信号配信フォーマットは、両方の信号が直線ビデオフォーマットであることから、UHD信号プレゼンテーションフォーマットに非常に類似しており、HDフォーマットをUHDフォーマットに変換するプロセスは、比較的簡単であり、ほとんどのレガシークライアントデバイス上で行うのが容易なプロセスである。

【0037】

幾つかの例では、ターゲットクライアントデバイスのための好ましいプレゼンテーションフォーマットは、ネットワークによって受信されたインジェストフォーマットとは大きく異なり得る。それにもかかわらず、ターゲットクライアントデバイスは、メディアをインジェストフォーマットからターゲットクライアントデバイスによるプレゼンテーションに適した必要なプレゼンテーションフォーマットに変換するのに十分な計算、記憶、及び帯域幅リソースにアクセスすることができる。このシナリオでは、ネットワークは、インジェストされたメディアをフォーマットAからフォーマットBに再フォーマットするステップ、例えばメディアを「トランスコード」するステップをバイパスすることができるが、これは単に、クライアントが、ネットワークがそうする必要なしに全てのメディア変換を行うのに十分なリソースにアクセスできるからである。しかしながら、ネットワークは、メディアがターゲットクライアントデバイスにストリーミングされ得るように、インジェストメディアを断片化及びパッケージ化するステップを依然として行うことができる。

【0038】

幾つかの例では、ネットワークによって受信されたインジェストされたメディアは、ターゲットクライアントデバイスの好ましいプレゼンテーションフォーマットとは著しく異なり、ターゲットクライアントデバイスは、メディアを好ましいプレゼンテーションフォーマットに変換するのに十分な計算、記憶、及び／又は帯域幅リソースにアクセスできない。そのようなシナリオでは、ネットワークは、インジェストフォーマットから、ターゲットクライアントデバイスに代わってターゲットクライアントデバイスの好ましいプレゼンテーションフォーマットと同等又はほぼ同等のフォーマットへの変換の一部又は全部を行うことによって、ターゲットクライアントデバイスを支援することができる。幾つかのアーキテクチャ設計では、ターゲットクライアントデバイスに代わってネットワークによって提供されるそのような支援は、「分割レンダリング」と呼ばれる。

【0039】

図1は、幾つかの例におけるメディアフロープロセス100（プロセス100とも称される）を示す。メディアフロープロセス100は、ネットワーククラウド（又はエッジデバイス）104で実行することができる第1のステップと、クライアントデバイス108で実行することができる第2のステップとを含む。幾つかの例では、インジェストメディアフォーマットAのメディアは、ステップ101でコンテンツプロバイダからネットワークによって受信される。ネットワークプロセスステップであるステップ102は、メディアをフォーマットBにフォーマットすることによって、又はクライアントデバイス108にストリーミングされるメディアを準備することによって、クライアントデバイス108に配信するためにメディアを準備することができる。ステップ103において、メディアは、ネットワーク接続105を介してネットワーククラウド104からクライアントデバイス108にストリーミングされる。クライアント108は、配信メディアを受信し、106によって示されるレンダリングプロセスを介してプレゼンテーションのためにメディアを準備することができる。レンダリングプロセス106の出力は、107によって示されるように、更に別の潜在的に異なるフォーマットCのプレゼンテーションメディアである。

【0040】

図2は、例えばネットワーク内の1つ以上のデバイスによって、ネットワーク（ネットワーククラウドとも呼ばれる）内のインジェストされたメディアを処理するためのネットワーク論理フローを示すメディア変換意思決定プロセス200（プロセス200とも呼ばれる）を示す。201において、メディアは、コンテンツプロバイダからネットワーククラウドによってインジェストされる。ターゲットクライアントデバイスの属性は、まだ知られていない場合、202で取得される。意思決定ステップ203は、必要に応じて、ネットワークがメディアの変換を支援すべきかどうかを決定する。インジェストされたメディアは、意思決定ステップ203がネットワークが変換を支援すべきであると決定した場合に、メディアをフォーマットAからフォーマットBに変換して、変換されたメディア205を生成するプロセスステップ204によって変換される。206において、変換された又はその元の形態のいずれかのメディアは、ストリーミングされるように準備される。207において、準備されたメディアは、ゲームエンジンクライアントデバイスなどのターゲットクライアントデバイスに適切にストリーミングされる。

【0041】

図2の論理に対する重要な態様は、自動化プロセスによって行われ得る意思決定プロセス203である。その意思決定ステップは、メディアをその元のインジェストフォーマットAでストリーミングできるかどうか、又はターゲットクライアントデバイスによるメディアのプレゼンテーションを容易にするためにメディアを異なるフォーマットBに変換する必要があるかどうかを決定することができる。

【0042】

幾つかの例では、意思決定プロセスステップ203は、最適な選択を行うために、すなわち、メディアをターゲットクライアントデバイスにストリーミングする前にインジェストメディアの変換が必要かどうか、又はメディアを元のインジェストフォーマットAでターゲットクライアントデバイスに直接ストリーミングできるかどうかを決定するために、意思決定プロセスステップ203を支援するように、インジェストメディアの態様又は特徴を記述する情報へのアクセスを必要とする場合がある。

【0043】

本開示の一態様によれば、シーンベースの没入型メディアのストリーミングは、ストリーミングフレームベースのメディアとは異なり得る。例えば、フレームベースのメディアのストリーミングは、ビデオのフレームのストリーミングと同等であってもよく、各フレームは、クライアントデバイスによって提示されるシーン全体の完全なピクチャ又はオブジェクト全体の完全なピクチャを捕捉する。フレームのシーケンスは、クライアントデバイスによってそれらの圧縮形式から再構成され、視聴者に提示されると、没入プレゼンテーション全体又はプレゼンテーションの一部を含むビデオシーケンスを作成する。フレームベースのメディアストリーミングの場合、フレームがネットワークからクライアントデバイスにストリーミングされる順序は、汎用オーディオ視覚サービスのためのITU－T勧告H．264アドバンストビデオコーディングなどの所定の仕様と一致し得る。

【0044】

しかしながら、シーンは、それ自体が互いに独立していてもよい個々のアセットから構成されてもよいので、メディアのシーンベースのストリーミングは、フレームベースのストリーミングとは異なる。所与のシーンベースのアセットは、特定のシーン内で、又は一連のシーンにわたって複数回使用することができる。クライアントデバイス、又は任意の所与のレンダラが特定のアセットの正しいプレゼンテーションを作成する必要がある時間量は、アセットのサイズ、レンダリングを行うための計算リソースの利用可能性、及びアセットの全体的な複雑さを記述する他の属性を含むがこれらに限定されない多くの要因に依存し得る。シーンベースのストリーミングをサポートするクライアントデバイスは、シーン内の各アセットのレンダリングの一部又は全部が、シーンのプレゼンテーションのいずれかが開始できる前に完了されることを必要とする場合がある。したがって、アセットがネットワークからクライアントデバイスにストリーミングされる順序は、全体的な性能に影響を与える可能性がある。

【0045】

本開示の一態様によれば、フォーマットAから別のフォーマットへのメディアの変換が完全にネットワークによって、完全にクライアントデバイスによって、又はネットワークとクライアントデバイスの両方の間で共同で行われ得る上記の各シナリオを考えると、例えば、分割レンダリングのために、クライアントデバイスとネットワークの両方が変換作業を特徴付ける完全な情報を有するように、メディアフォーマットを記述する属性の語彙が必要とされ得る。更に、例えば、利用可能な計算リソース、利用可能なストレージリソース、及び帯域幅へのアクセスに関して、クライアントデバイスの能力の属性を提供する語彙が同様に必要とされ得る。更に、インジェストフォーマットの計算、ストレージ、又は帯域幅の複雑さのレベルを特徴付けるメカニズムが必要とされる場合があり、その結果、ネットワークとクライアントデバイスが一緒に、又は単独で、ネットワークがクライアントデバイスにメディアを配信するための分割レンダリングステップを採用するかどうか、又はいつ採用するかを決定することができる。更に、メディアのプレゼンテーションを完了するためにクライアントデバイスによって必要とされる、又は必要とされる特定のメディアオブジェクトの変換及び／又はストリーミングを回避することができる場合、ネットワークは、クライアントデバイスがメディアのクライアントデバイスのプレゼンテーションを完了するために必要とする可能性があるメディアオブジェクトへのアクセス又は利用可能性を有すると仮定して、変換及びストリーミングのステップをスキップすることができる。クライアントデバイスがその最大限の能力で行う能力を促進するために、ネットワークからクライアントデバイスにシーンベースのアセットがストリーミングされる順序に関して、ネットワークがクライアントデバイスの性能を向上させるためにそのような順序を決定できるように、ネットワークが十分な情報を装備することが望ましい場合がある。例えば、特定のプレゼンテーションにおいて複数回使用されるアセットの反復的な変換及び／又はストリーミングステップを回避するのに十分な情報を有するそのようなネットワークは、そのように設計されていないネットワークよりも最適に行うことができる。同様に、クライアントへのアセットの配信を「インテリジェントに」順序付けることができるネットワークは、クライアントデバイスがその最大限の能力で行う能力、すなわち、エンドユーザにとってより楽しめる体験を作り出す能力を促進することができる。更に、クライアントデバイスとネットワーク（例えば、ネットワーク内のサーバデバイス）との間のインタフェースは、クライアントデバイスの動作状態の特性、クライアントデバイスにおける、又はクライアントデバイスに対してローカルなリソースの利用可能性、ストリーミングされるメディアのタイプ、及び使用されるアセットの頻度、又は多数のシーンにわたって伝達される、1つ以上の通信チャネルを使用して実装されてもよい。したがって、異種クライアントへのシーンベースのメディアのストリーミングを実装するネットワークアーキテクチャは、計算及び記憶リソースにアクセスするクライアントデバイスの能力に関連する現在の条件を含む、各シーンの処理に関連する情報をネットワークサーバプロセスに提供及び更新することができるクライアントインタフェースへのアクセスを必要とする場合がある。そのようなクライアントインタフェースはまた、クライアントデバイス上で実行される他のプロセス、特に没入体験をエンドユーザに配信するクライアントデバイスの能力に代わって本質的な役割を果たすことができるゲームエンジンと密接に対話することができる。ゲームエンジンが果たすことができる本質的な役割の例は、対話型体験の配信を可能にするためのアプリケーションプログラムインタフェース（API）を提供することを含む。クライアントデバイスに代わってゲームエンジンによって提供され得る別の役割は、クライアントデバイスの能力と一致する視覚体験を提供するためにクライアントデバイスによって必要とされる正確な視覚信号のレンダリングである。

【0046】

本開示で使用される幾つかの用語の定義は、以下の段落で提供される。

【0047】

シーングラフ：ベクトルベースのグラフィックス編集アプリケーション及び最新のコンピュータゲームによって通常使用される一般的なデータ構造であって、グラフィックシーンの論理的かつ多くの場合（必ずしもそうとは限らないが）空間的な表示を構成し、グラフ構造におけるノード及び頂点の集合である。

【0048】

シーン：コンピュータグラフィックスの文脈では、シーンは、オブジェクト（例えば、3Dアセット）、オブジェクト属性、並びに、特定の設定を記述する視覚的、音響的、及び物理ベースの特性を含む他のメタデータの集合であり、その設定内のオブジェクトの相互作用に関して、空間又は時間のいずれかによって境界が定められる。

【0049】

ノード：視覚、オーディオ、触覚、嗅覚、味覚、又は関連する処理情報の論理的、又は空間的、又は時間的な表示に関連する情報で構成されるシーングラフの基本要素であり、各ノードには、最大で1つの出力エッジ、0以上の入力エッジ、及び少なくとも1つのエッジ（入力又は出力のいずれか）が接続されているものとする。

【0050】

ベース層：アセットの公称表示であり、通常、アセットをレンダリングするのに必要な計算リソースもしくは時間、又はネットワークを介してアセットを送信する時間を最小化するように定式化される。

【0051】

強化層：アセットのベース層表示に適用される場合、ベース層でサポートされない機能又は能力を含むようにベース層を増強させる情報のセット。

【0052】

属性：基準形式又はより複雑な形式のいずれかでそのノードの特定の特性又は特徴を記述するために使用されるノードに関連付けられたメタデータ（例えば、別のノードに関して）。

【0053】

コンテナ：シーングラフ及びシーンのレンダリングに必要な全てのメディアリソースを含む全ての自然シーン、全ての合成シーン、又は合成シーンと自然シーンとの組合せを表すための情報を記憶し、かつ交換するための直列化フォーマット。

【0054】

シリアル化：データ構造又はオブジェクト状態を、（例えば、ファイル又はメモリバッファに）記憶することができ、又は（例えば、ネットワーク接続リンクを介して）送信することができ、後で（場合によっては異なるコンピュータ環境で）再構成することができるフォーマットに変換するプロセス。結果として得られた一連のビットがシリアル化フォーマットに従って再読み取りされると、これを使用して、元のオブジェクトと意味的に同一のクローンを作成することができる。

【0055】

レンダラ：音響物理学、光物理学、視覚知覚、オーディオ知覚、数学、及びソフトウェア開発に関連する学問分野の選択的な組合せに基づく（典型的にはソフトウェアベースの）アプリケーション又はプロセスであり、入力シーングラフ及びアセットコンテナが与えられると、ターゲットデバイス上でのプレゼンテーションに適した、又はシーングラフ内のレンダリングターゲットノードの属性によって指定された所望のプロパティに適応した、典型的な視覚信号及び／又はオーディオ信号を発する。視覚ベースのメディアアセットの場合、レンダラは、ターゲットディスプレイに適した、又は（例えば、別のコンテナに再パッケージ化された、すなわち、グラフィックスパイプラインでの一連のレンダリングプロセスにおいて使用される）中間アセットとしての記憶に適した視覚信号を発することができ、オーディオベースのメディアアセットの場合、レンダラは、マルチチャネルラウドスピーカ及び／又はバイノーラル化されたヘッドフォンでのプレゼンテーションのために、又は別の（出力）コンテナに再パッケージ化するために、オーディオ信号を発することができる。レンダラの一般的な例は、ゲームエンジンのUnity EngineやUnreal Engineのリアルタイムレンダリング機能を含む。

【0056】

評価：出力を要約から具体的な結果に移動させる結果（例えば、ウェブページのための文書オブジェクトモデルの評価と同様）を生成する。

【0057】

スクリプト言語：シーングラフノードに加えられる動的な入力及び可変の状態変化を処理するために、実行時にレンダラによって実行され得るインタプリタ型プログラミング言語であり、この変化は、空間的及び時間的なオブジェクトのトポロジ（物理的な力、制約、逆運動学、変形、衝突を含む）のレンダリング及び評価並びにエネルギーの伝播及び輸送（光、音）に影響を及ぼす。

【0058】

シェーダ：コンピュータプログラムの一種で、元々はシェーディング（画像内の適切なレベルの明暗及び色の生成）に使用されていたが、現在では、コンピュータグラフィックスの特殊効果の様々な分野で様々な特殊機能を行い、又はシェーディングとは無関係のビデオ後処理を行い、又はグラフィックスとは全く無関係の機能さえも行う。

【0059】

パス追跡（Path Tracing）：シーンの照明が現実に忠実になるように3次元シーンをレンダリングするコンピュータグラフィックス方法。

【0060】

タイムドメディア：時間によって順序付けられたメディアであって、例えば、特定のクロックに従った開始時刻及び終了時刻を有する。

【0061】

非タイムドメディア：例えば、ユーザが行った行動に従って実現される対話型体験のように、空間的、論理的、又は時間的関係によって編成されたメディアである。

【0062】

ニューラルネットワークモデル：元の信号によっては明示的に提供されなかった視覚信号の新しいビューの補間を含むことができる改善された視覚出力に到達するために、視覚信号に適用される、明確に定義された数学的演算で使用される重み（すなわち、数値）を定義するパラメータ及びテンソル（例えば、行列）の集合。

【0063】

フレームベースのメディア：関連するオーディオの有無にかかわらず、2Dビデオ。

【0064】

シーンベースのメディア：オーディオ、視覚、触覚、及び他の主要なタイプのメディア、並びにシーングラフを使用して論理的及び空間的に編成されたメディア関連情報。

【0065】

過去10年間に、ヘッドマウントディスプレイ、拡張現実メガネ、ハンドヘルドコントローラ、マルチビューディスプレイ、触覚手袋、及びゲーム機を含む、幾つかの没入型メディア対応デバイスが消費者市場に導入されてきた。同様に、ホログラフィックディスプレイ及び他の形態の容積型ディスプレイも、今後3～5年以内に消費者市場に出現する準備が整っている。これらのデバイスの即時の、又は差し迫った利用可能性にもかかわらず、商用ネットワークを介した没入型メディアの配信のための一貫したエンドツーエンドエコシステムは、幾つかの理由で実現されていない。

【0066】

商用ネットワークを介した没入型メディアの配信のための一貫したエンドツーエンドエコシステムを実現することに対する障害の1つは、没入型ディスプレイのこのような配信ネットワークのエンドポイントとして機能するクライアントデバイスが全て非常に多様であることである。これらの中には、特定の没入型メディアフォーマットをサポートするものもあれば、サポートしないものもある。これらの中には、レガシーなラスタベースのフォーマットから没入型体験を作り出すことができるものもあれば、そうでないものもある。レガシーメディアの配信のためにだけ設計されたネットワークとは異なり、多様なディスプレイクライアントをサポートしなければならないネットワークは、このようなネットワークが適応プロセスを用いて、メディアを各ターゲットディスプレイ及び対応するアプリケーションに適したフォーマットに変換可能となる前に、各クライアントの能力の詳細及び配信されるメディアのフォーマットに関するかなりの量の情報を必要とする。このようなネットワークは、少なくとも、入力メディアソースをターゲットディスプレイ及びアプリケーションに適したフォーマットに有意に適応させる方法をネットワークが確認するために、各ターゲットディスプレイの特性とインジェストされたメディアの複雑さとを記述する情報にアクセスする必要がある。同様に、効率のために最適化されたネットワークは、そのようなネットワークに接続されたクライアントデバイスによってサポートされるメディアのタイプ及びそれらの対応する属性のデータベースを維持したい場合がある。

【0067】

同様に、異種クライアントをサポートする理想的なネットワークは、入力メディアフォーマットから特定のターゲットフォーマットに適応されたアセットの幾つかが同様の表示ターゲットのセットにわたって再利用され得るという事実を活用すべきである。すなわち、ターゲットディスプレイに適したフォーマットに変換されると、一部のアセットは、同様の適応要件を有する幾つかのこのようなディスプレイにわたって再利用されてもよい。したがって、このような理想的なネットワークは、適応されたアセットを比較的不変である、すなわち、レガシーネットワークで使用されているコンテンツ配信ネットワーク（CDN）の使用と同様である領域に記憶するために、キャッシングメカニズムを用いることになる。

【0068】

更に、没入型メディアは、シーン記述としても知られるシーングラフによって記述される「シーン」、例えば「シーンベースのメディア」に編成することができる。シーングラフの範囲は、プレゼンテーションの一部である特定の設定を含む視覚、オーディオ、及び他の形態の没入型アセットを記述することであり、例えば、映画などのプレゼンテーションの一部である建物内の特定の場所で行われる俳優及びイベントである。単一のプレゼンテーションを含む全てのシーンのリストは、シーンのマニフェストに定式化されてもよい。

【0069】

このような手法の更なる利点は、このようなコンテンツを配信しなければならない前に準備されるコンテンツの場合、プレゼンテーション全体で使用されるアセットの全てと、プレゼンテーション内の様々なシーンにわたって各アセットが使用される頻度とを特定する「部品表」を作成することができることである。理想的なネットワークは、特定のプレゼンテーションのアセット要件を満たすために使用することができるキャッシュされたリソースの存在の知識を有する必要がある。同様に、一連のシーンを提示しているクライアントは、複数のシーンにわたって使用される任意の所与のアセットの頻度に関する知識を有することを望む場合がある。例えば、メディアアセット（「オブジェクト」としても知られる）が、クライアントによって処理される、又は処理される複数のシーンにわたって複数回参照される場合、クライアントは、その特定のアセットを必要とする最後のシーンがクライアントによって提示されるまで、そのアセットをそのキャッシングリソースから破棄することを避けるべきである。

【0070】

最後に、これらに限定されるものではないが、Oculus Rift、Samsung Gear VR、Magic Leapゴーグル、全てのLooking Glass Factoryディスプレイ、Light Field LabによるSolidLight、Avalon Holographicディスプレイ、及びDimencoディスプレイを含む多くの新興の先進撮像ディスプレイは、それぞれのディスプレイがディスプレイ上にレンダリング及び提示されるコンテンツをインジェストすることができる機構としてゲームエンジンを利用する。現在、この前述のディスプレイのセットにわたって採用されている最も人気のあるゲームエンジンには、Epic GameによるUnreal Engine、及びUnity TechnologiesによるUnityが含まれる。すなわち、高度な画像化ディスプレイは、現在、ディスプレイがそのような高度な画像化ディスプレイによってレンダリング及び提示されるメディアを取得することができる機構としてこれらのゲームエンジンの一方又は両方を採用して設計及び出荷されている。Unreal Engine及びUnityはいずれも、フレームベースのメディアではなくシーンベースのメディアをインジェストするように最適化されている。しかしながら、既存のメディア配信エコシステムは、フレームベースのメディアのみをストリーミングすることができる。現在のメディア配信エコシステムには、メディアを「大規模に」、例えばフレームベースのメディアが配信されるのと同じ規模で配信することができるように、出現しつつある先進的な撮像ディスプレイへのシーンベースのコンテンツの配信を可能にするための標準（デジュール又はデファクトスタンダード）及び最良の慣行を含む大きな「ギャップ」が存在する。

【0071】

開示された主題は、ゲームエンジンが利用されてシーンベースのメディアをインジェストするクライアントデバイスに代わって、ネットワークサーバプロセスに応答し、本明細書に記載のネットワークと没入型クライアントアーキテクチャの組合せに関与する機構又はプロセスの必要性に対処する。そのような「スマートクライアント」機構は、メディアの配信が効率的に行われ、ネットワーク全体を構成する様々な構成要素の能力の制約内で、没入型異種インタラクティブクライアントデバイスにシーンベースのメディアをストリーミングするように設計されたネットワークに特に関連する。「スマートクライアント」は、特定のクライアントデバイスに関連付けられ、シーンベースのメディアのプレゼンテーションをレンダリング及び作成するためのクライアントデバイス上のリソースの利用可能性を含む、その関連付けられたクライアントデバイスの現在の状態に関する情報を求めるネットワークの要求に応答する。「スマートクライアント」は、ゲームエンジンが採用されるクライアントデバイスとネットワーク自体との間の「仲介者」としての役割も果たす。

【0072】

開示された主題の残りの部分は、一般性を失うことなく、特定のクライアントデバイスの代わりに応答することができるスマートクライアントが、1つ以上の他のアプリケーション（すなわち、ゲームエンジンアプリケーションではない）がアクティブであるクライアントデバイスの代わりに応答することもできることを想定していることに留意されたい。すなわち、クライアントデバイスの代わりに応答するという問題は、1つ以上の他のアプリケーションがアクティブであるクライアントの代わりに応答するという問題と同等である。

【0073】

更に、「メディアオブジェクト」及び「メディアアセット」という用語は互換的に使用することができ、両方とも特定のフォーマットのメディアの特定のインスタンスを指すことに留意されたい。「クライアントデバイス」又は「クライアント」（限定なし）という用語は、メディアのプレゼンテーションが最終的に行われるデバイス及びその構成要素を指す。「ゲームエンジン」という用語は、UnityもしくはUnrealエンジン、又は配信ネットワークアーキテクチャにおいて役割を果たす任意のゲームエンジンを指す。「スマートクライアント」という用語は、本文書の主題を指す。

【0074】

図1に戻って参照すると、メディアフロープロセス100は、ネットワーク104を通るメディアの流れ、又はゲームエンジンが使用されるクライアントデバイス108への配信を示す。図1において、インジェストメディアフォーマットAの処理は、クラウド又はエッジデバイス104における処理によって行われる。101において、メディアはコンテンツプロバイダ（図示せず）から取得される。プロセスステップ102は、インジェストされたメディアの任意の必要な変換又は調整を行って、配信フォーマットBとしてのメディアの潜在的な代替表示を作成する。メディアフォーマットA及びBは、特定のメディアフォーマット仕様の同じ構文に従う表示であってもなくてもよいが、フォーマットBは、TCP又はUDPなどのネットワークプロトコルを介したメディアの配信を容易にする方式に調整される可能性が高い。そのような「ストリーミング可能な」メディアは、クライアントデバイス108にストリーミングされるメディアとしてネットワーク接続105を介してストリーミングされるように示されている。クライアントデバイス108は、106として示されている幾つかのレンダリング機能にアクセスすることができる。そのようなレンダリング機能106は、クライアントデバイス108及びクライアントデバイス上で動作しているゲームエンジンの種類に応じて、初歩的であってもよく、又は同様に洗練されていてもよい。レンダリングプロセス106は、第3のフォーマット仕様、例えばフォーマットCに従って表示されてもされなくてもよいプレゼンテーションメディアを作成する。幾つかの例では、ゲームエンジンを使用するクライアントデバイスでは、レンダリングプロセス106は、通常、ゲームエンジンによって提供される機能である。

【0075】

図2を参照すると、メディア変換意思決定プロセス200を使用して、クライアントデバイスにメディアを配信する前にネットワークがメディアを変換する必要があるかどうかを決定することができる。図2では、フォーマットAで表されるインジェストされたメディア201は、コンテンツプロバイダ（図示せず）によってネットワークに提供される。プロセスステップ202は、ターゲットクライアント（図示せず）の処理能力を記述する属性を取得する。意思決定プロセスステップ203は、ネットワーク又はクライアントが、メディアがクライアントにストリーミングされる前に、例えば、特定のメディアオブジェクトのフォーマットAからフォーマットBへの変換など、インジェストされたメディア201内に含まれるメディアアセットのいずれかのフォーマット変換を行うべきかどうかを決定するために用いられる。メディアアセットのいずれかがネットワークによって変換される必要がある場合、ネットワークは、メディアオブジェクトをフォーマットAからフォーマットBに変換するためにプロセスステップ204を使用する。変換されたメディア205は、プロセスステップ204からの出力である。変換されたメディアは、ゲームエンジンクライアント（図示せず）にストリーミングされるメディアを準備するために準備プロセス206にマージされる。プロセスステップ207は、例えば、準備されたメディアをゲームエンジンクライアントにストリーミングする。

【0076】

図3は、一例においてタイムドである異種没入型メディアのためのストリーミング可能フォーマット300の表示を示し、図4は、一例において非タイムドである異種没入型メディアのためのストリーミング可能フォーマット400の表示を示す。図3の場合、図3はタイムドメディアのシーン301を参照する。図4の場合、図4は非タイムドメディアのシーン401を参照する。どちらの場合も、シーンは、様々なシーン表示又はシーン記述によって具現化されてもよい。

【0077】

例えば、幾つかの没入型メディア設計では、シーンはシーングラフによって、又は多平面画像（MPI）として、又は多球面画像（MSI）として具現化されてもよい。MPI及びMSI技術の両方は、自然なコンテンツ、すなわち1つ以上のカメラから同時に捕捉された現実世界の画像についてディスプレイに依存しないシーン表示の作成を支援する技術の例である。一方、シーングラフ技術は、自然画像とコンピュータ生成画像の両方を合成表示の形式で表示するために使用され得るが、そのような表示は、コンテンツが1つ以上のカメラによって自然シーンとして捕捉される場合に作成するために特に計算集約的である。すなわち、自然に捕捉されたコンテンツのシーングラフ表示は、作成するのに時間と計算集約的であり、ターゲットの没入型クライアントディスプレイの視錐台を満たすのに十分かつ適切な数のビューを補間するために後で使用できる合成表示を作成するために、写真測量又は深層学習又はその両方の技術を用いた自然画像の複雑な解析を必要とする。結果として、そのような合成表示は、リアルタイム配信を必要とするユースケースを考慮するためにリアルタイムで実際に作成することができないため、自然なコンテンツを表示するための候補として考慮するには現在実用的ではない。幾つかの例では、コンピュータ生成画像の最良の候補表示は、3Dモデリングプロセス及びツールを使用してコンピュータ生成画像が作成されるので、合成モデルを有するシーングラフの使用を使用することである。

【0078】

自然コンテンツとコンピュータ生成コンテンツの両方の最適表示におけるこのような2分法は、自然に捕捉されたコンテンツの最適なインジェストフォーマットが、リアルタイム配信アプリケーションに必須ではないコンピュータ生成コンテンツ又は自然コンテンツの最適なインジェストフォーマットとは異なることを示唆している。したがって、開示された主題は、物理的なカメラの使用によって自然に作成されるか、コンピュータによって作成されるかにかかわらず、視覚的没入型メディアの複数のインジェストフォーマットをサポートするのに十分に堅牢であることを目標としている。

【0079】

以下は、コンピュータ生成技術を使用して作成された視覚的没入型メディア、又は自然に捕捉されたコンテンツを表示するのに適したフォーマットとして、シーングラフを具体化する例示的な技術であり、そのために深層学習又は写真測量技術が採用されて、自然なシーンの対応する合成表示を作成するものであり、すなわち、リアルタイム配信アプリケーションには必須ではない。

【0080】

1．OTOY社のORBX（登録商標）
OTOY社のORBXは、光線追跡可能、レガシー（フレームベース）、立体及び他のタイプの、合成又はベクトルベースの視覚フォーマットを含む、タイムド又は非タイムドの任意のタイプの視覚メディアをサポートすることが可能な幾つかのシーングラフ技術のうちの1つである。一態様によれば、ORBXは、メッシュ、点群、及びテクスチャのための自由に利用可能な及び／又はオープンソース形式のネイティブサポートを提供するので、ORBXは他のシーングラフから固有である。ORBXは、シーングラフ上で動作する複数のベンダ技術にわたる交換を容易にすることを目的として意図的に設計されたシーングラフである。更に、ORBXは、豊富な素材システム、オープンシェーダ言語のサポート、堅牢なカメラシステム、及びLuaスクリプトのサポートを提供する。ORBXはまた、没入型デジタル体験アライアンス（IDEA）によって使用料無料の条件でライセンスのために公開された没入型技術メディアフォーマットの基礎でもある。メディアのリアルタイム配信の状況では、自然なシーンのORBX表示を作成及び配信する能力は、カメラによって捕捉されたデータの複雑な分析及び同じデータの合成表示への合成を行うための計算リソースの利用可能性の関数である。今日まで、リアルタイム配信のための十分な計算の利用可能性は実際的ではないが、それにもかかわらず不可能ではない。

【0081】

2．Pixar社のユニバーサルシーン記述
Pixar社によるユニバーサルシーン記述（USD）は、ビジュアルエフェクト（VFX）及びプロフェッショナルコンテンツ制作コミュニティにおいて使用され得る他のシーングラフである。USDは、Nvidia社のGPUを用いた3Dモデル作成及びレンダリングのための開発者向けツールのセットであるNvidia社のOmniverseプラットフォームに統合されている。USDのサブセットは、USDZとしてApple社及びPixar社によって公開された。USDZは、Apple社のARKitによってサポートされている。

【0082】

3．Khronos社のglTF2．0
glTF2．0は、Khronos 3D Groupによって書かれたグラフィックス言語伝送フォーマット仕様の最新バージョンである。このフォーマットは、「png」及び「jpeg」画像フォーマットを含む、一般にシーン内の静的（非タイムド）オブジェクトをサポートすることができる単純なシーングラフフォーマットをサポートする。glTF2．0は、単純なアニメーションをサポートし、glTFプリミティブを使用して記述された基本形状、すなわち幾何学的オブジェクトの並進、回転、及びスケーリングをサポートする。glTF2．0はタイムドメディアをサポートしておらず、したがって、ビデオもオーディオもサポートしていない。

【0083】

没入型視覚メディアの上記のシーン表示は、例えば提供されているにすぎず、入力没入型メディアソースをクライアントエンドポイントデバイスの特定の特性に適したフォーマットに適応させるプロセスを指定するその能力において開示された主題を限定しないことに留意されたい。

【0084】

更に、上記の例示的なメディア表示のいずれか又は全ては、錐台の特定の寸法に基づいて特定のディスプレイの視錐台を満たすために特定のビューの選択を可能にするか又は容易にするニューラルネットワークモデルを訓練して作成するために、深層学習技術を現在用いているか、又は用いることができる。特定のディスプレイの視錐台のために選択されたビューは、シーン表示において明示的に提供される既存のビューから、例えば、MSI又はMPI技術から補間されてもよく、又はこれらのレンダリングエンジンのための特定の仮想カメラ位置、フィルタ、又は仮想カメラの記述に基づいてレンダリングエンジンから直接レンダリングされてもよい。

【0085】

したがって、開示された主題は、自然に（例えば、1つ以上のカメラを用いて）捕捉されるか、又はコンピュータ生成技術を使用して作成されるメディアのリアルタイム又は「オンデマンド」（例えば、非リアルタイム）配信の両方の要件を十分に満たすことができる、比較的小さいがよく知られている没入型メディアインジェストフォーマットのセットがあることを考慮するのに十分に堅牢である。

【0086】

ニューラルネットワークモデル又はネットワークベースのレンダリングエンジンのいずれかの使用による没入型メディアインジェストフォーマットからのビューの補間は、モバイルネットワーク用の5G及び固定ネットワーク用の光ファイバケーブルなどの高度なネットワーク技術が展開されるにつれて更に容易になる。すなわち、これらの高度なネットワーク技術は、そのような高度なネットワークインフラストラクチャがますます大量の視覚情報の伝送及び配信をサポートすることができるので、商用ネットワークの容量及び能力を増加させる。マルチアクセスエッジコンピューティング（MEC）、ソフトウェア定義ネットワーク（SDN）、及びネットワーク機能仮想化（NFV）などのネットワークインフラ管理技術は、商用ネットワークサービスプロバイダが、特定のネットワークリソースに対する需要の変化に適応するように、例えば、ネットワークスループット、ネットワーク速度、往復遅延、及び計算リソースに対する需要の動的な増減に応答するように、それらのネットワークインフラを柔軟に構成することを可能にする。更に、動的ネットワーク要件に適応するこの固有の能力は、同様に、異種クライアントエンドポイントのための潜在的に異種の視覚メディアフォーマットを有する様々な没入型メディアアプリケーションをサポートするために、没入型メディアインジェストフォーマットを適切な配信フォーマットに適応させるネットワークの能力を容易にする。

【0087】

没入型メディアアプリケーション自体はまた、ゲームの状態でリアルタイム更新に応答するために著しく低いネットワーク待ち時間を必要とするゲームアプリケーション、ネットワークのアップリンク部分及びダウンリンク部分の両方に対して対称的なスループット要件を有するテレプレゼンスアプリケーション、及びデータを消費しているクライアントのエンドポイントのディスプレイのタイプに応じてダウンリンクリソースに対する需要が増加する可能性のある受動的閲覧アプリケーションを含む、ネットワークリソースに対する様々な要件を有してもよい。一般に、任意の消費者向けアプリケーションは、記憶、計算及び電力のための様々なオンボードクライアント機能、並びに特定のメディア表示のための同じく様々な要件を含む様々なクライアントエンドポイントによってサポートされてもよい。

【0088】

したがって、開示された主題は、十分に装備されたネットワーク、すなわち、最新のネットワークの特性の一部又は全てを用いるネットワークが、以下の中で指定された特徴に従って複数のレガシー及び没入型メディア対応デバイスを同時にサポートすることを可能にする。

【0089】

1．メディアの配信のためのリアルタイム及び「オンデマンド」のユースケースの両方に実用的なメディアインジェストフォーマットを活用する柔軟性を提供する。

【0090】

2．レガシー及び没入型メディア対応のクライアントエンドポイントの両方について、自然コンテンツ及びコンピュータ生成コンテンツの両方をサポートする柔軟性を提供する。

【0091】

3．タイムドメディア及び非タイムドメディアの両方をサポートする。

【0092】

4．クライアントエンドポイントの機能及び能力に基づいて、並びにアプリケーションの要件に基づいて、ソースメディアインジェストフォーマットを適切な配信フォーマットに動的に適応させるためのプロセスを提供する。

【0093】

5．配信フォーマットがIPベースのネットワーク上でストリーミング可能であることを保証する。

【0094】

6．ネットワークが、レガシー及び没入型メディア対応デバイスの両方を含み得る複数の異種クライアントエンドポイントに同時にサービスを提供できるようにする。

【0095】

7．シーン境界に沿った配信メディアの編成を容易にする例示的なメディア表示フレームワークを提供する。

【0096】

開示された主題によって可能にされる改善のエンドツーエンドの実施形態は、以下の詳細な説明に記載される処理及び構成要素に従って達成される。

【0097】

図3及び図4はそれぞれ、特定のクライアントエンドポイントの能力に一致するようにインジェストソースフォーマットから適応され得る例示的な包括的な配信フォーマットを採用する。前述したように、図3に示されているメディアはタイムドであり、図4に示されているメディアは非タイムドである。特定の包含フォーマットは、その構造において、各層がメディアのプレゼンテーションに寄与する顕著な情報の量に基づいてそれぞれが階層化され得る多種多様なメディア属性に対応するのに十分に堅牢である。レイヤリングプロセスは、例えば、プログレッシブJPEG及びスケーラブルビデオアーキテクチャ（例えば、ISO／IEC14496－10スケーラブルアドバンストビデオコーディングに規定されている）に適用され得ることに留意されたい。

【0098】

一態様によれば、包含するメディアフォーマットに従ってストリーミングされるメディアは、レガシー視覚メディア及びオーディオメディアに限定されず、機械と相互作用して人間の視覚、音、味、触覚、及び匂いを刺激する信号を生成することができる任意のタイプのメディア情報を含むことができる。

【0099】

他の態様によれば、包含するメディアフォーマットに従ってストリーミングされるメディアは、タイムドメディアもしくは非タイムドメディアの両方、又は両方の混合であり得る。

【0100】

他の態様によれば、包含するメディアフォーマットは、ベース層及び強化層アーキテクチャを使用することによってメディアオブジェクトの階層表示を可能にすることによって更に流線型化可能である。一例では、別々のベース層及び強化層は、各シーン内のメディアオブジェクトについての多重解像度又は多重モザイク化の解析技術の適用によって計算される。これは、ISO／IEC 10918－1（JPEG）及びISO／IEC 15444－1（JPEG2000）で指定されたプログレッシブレンダリング画像フォーマットに類似しているが、ラスタベースの視覚フォーマットに限定されない。一例では、幾何学的オブジェクトのプログレッシブ表示は、ウェーブレット解析を使用して計算されたオブジェクトの多重解像度表示であり得る。

【0101】

メディアフォーマットの階層化表示の別の例では、強化層は、ベース層によって表される視覚オブジェクトの表面の材料特性を改良するなど、ベース層に異なる属性を適用する。更に別の例では、属性は、表面を滑らかなテクスチャから多孔質のテクスチャに、又はつや消しの表面から光沢のある表面に変更するなど、ベース層オブジェクトの表面のテクスチャを改良することができる。

【0102】

階層化表示の更に別の例では、シーン内の1つ以上の視覚オブジェクトの表面は、ランバート（Lambertian）面からレイトレース可能（ray－traceable）な表面に変更されてもよい。

【0103】

階層化表示の更に別の例では、ネットワークは、ベース層表示をクライアントに配信し、その結果、クライアントは、ベース表示の解像度又は他の特性を改良するために追加の強化層の送信を待機している間に、シーンの公称プレゼンテーションを作成することができる。

【0104】

他の態様によれば、強化層における属性の解像度又は精緻化情報は、既存のMPEGビデオ及びJPEG画像標準規格において現在のようにベース層におけるオブジェクトの解像度と明示的に結合されない。

【0105】

他の態様によれば、包含するメディアフォーマットは、プレゼンテーションデバイス又はマシンによって提示又は作動され得る任意のタイプの情報メディアをサポートし、それによって異種クライアントエンドポイントへの異種メディアフォーマットのサポートを可能にする。メディアフォーマットを配信するネットワークの一実施形態では、ネットワークは、最初にクライアントの能力を決定するためにクライアントエンドポイントに問い合わせ、クライアントがメディア表示を有意にインジェストすることができない場合、ネットワークは、クライアントによってサポートされていない属性の層を除去するか、又はメディアをその現在のフォーマットからクライアントエンドポイントに適したフォーマットに適応させる。そのような適応の1つの例では、ネットワークは、ネットワークベースのメディア処理プロトコルを使用することによって、ボリュームの視覚メディアアセットを同じ視覚アセットの2D表示に変換する。このよう適応の別の例では、ネットワークは、ニューラルネットワークプロセスを用いて、メディアを適切なフォーマットに再フォーマットするか、又は任意選択で、クライアントエンドポイントによって必要とされるビューを合成することができる。

【0106】

他の態様によれば、完全な又は部分的に完全な没入型体験（ライブストリーミングイベント、ゲーム、又はオンデマンドアセットの再生）のためのマニフェストは、プレゼンテーションを作成するためにレンダリング及びゲームエンジンが現在インジェストし得る最小量の情報であるシーンによって編成される。マニフェストは、クライアントによって要求された没入型体験の全体がレンダリングされる個々のシーンのリストを含む。各シーンには、シーンジオメトリのストリーミング可能なバージョンに対応するシーン内の幾何学的オブジェクトの1つ以上の表示が関連付けられている。シーン表示の一実施形態は、シーンの幾何学的オブジェクトの低解像度バージョンに関する。同じシーンの別の実施形態は、同じシーンの幾何学的オブジェクトに更なる詳細を追加するか、又はモザイク化を増加させるための、シーンの低解像度表示のための強化層に関する。前述したように、各シーンは、シーンの幾何学的オブジェクトの詳細を漸進的に増加させるために2つ以上の強化層を有してもよい。

【0107】

他の態様によれば、シーン内で参照されるメディアオブジェクトの各層は、リソースがネットワーク内でアクセスされ得る場所のアドレスを指すトークン（例えば、URI）に関連付けられる。このようなリソースは、コンテンツがクライアントによってフェッチされ得るCDNに類似している。

【0108】

他の態様によれば、幾何学的オブジェクトの表示のためのトークンは、ネットワーク内の位置又はクライアント内の位置を指すことができる。すなわち、クライアントは、そのリソースがネットワークベースのメディア処理のためにネットワークに利用可能であることをネットワークにシグナリングしてもよい。

【0109】

図3は、幾つかの例におけるタイムドメディア表示300を示す。タイムドメディア表示300は、タイムドメディアのための包括的なメディアフォーマットの例を記述する。タイムドシーンマニフェスト300Aは、シーン情報301のリストを含む。シーン情報301は、シーン情報301内にある処理情報及びメディアアセットのタイプを別々に記述する構成要素302のリストを指す。構成要素302は、ベース層304及び属性強化層305を更に示すアセット303を指す。図3の例では、ベース層304のそれぞれは、プレゼンテーションのシーンのセットにわたってアセットが使用された回数を示す数値頻度メトリックを指す。他のシーンにおいて以前に使用されたことがない固有のアセットのリストが、307において提供される。プロキシ視覚アセット306は、再利用された視覚アセットの固有の識別子などの再利用された視覚アセットの情報を含み、プロキシオーディオアセット308は、再利用されたオーディオアセットの固有の識別子などの再利用されたオーディオアセットの情報を含む。

【0110】

図4は、幾つかの例における非タイムドメディア表示400を示す。非タイムドメディア表示400は、非タイムドメディアのための包括的なメディアフォーマットの例を記述する。非タイムドシーンマニフェスト（図示せず）は、シーン1．0に分岐することができる他のシーンがないシーン1．0を参照する。シーン情報401は、クロックに応じた開始時間及び終了時間に関連付けられていない。シーン情報401は、シーンを構成する処理情報及びメディアアセットのタイプを別々に記述する構成要素402のリストを指す。構成要素402は、ベース層404並びに属性強化層405及び406を更に指すアセット403を指す。図4の例では、ベース層404のそれぞれは、プレゼンテーションのシーンのセットにわたってアセットが使用された回数を示す数字頻度値を指す。また、シーン情報401は、非タイムドメディア用の他のシーン情報401を参照することができる。シーン情報401は、タイムドメディアシーンのためのシーン情報407も参照することができる。リスト408は、高次（例えば、親）シーンで以前に使用されたことがない特定のシーンに関連付けられた固有のアセットを識別する。

【0111】

図5は、自然コンテンツからインジェストフォーマットを合成するためのプロセス500の図を示す。プロセス500は、コンテンツ捕捉のための第1のサブプロセスと、自然画像のためのインジェストフォーマット合成のための第2のサブプロセスと、を含む。

【0112】

図5の例では、第1のサブプロセスでは、自然画像コンテンツ509を捕捉するために、カメラユニットが使用され得る。例えば、カメラユニット501は、人物のシーンを捕捉するために単一のカメラレンズを使用することができる。カメラユニット502は、リング状の物体の周囲に5つのカメラレンズを装着することで、5つの発散する視野のシーンを捕捉することができる。カメラユニット502内の配置は、VRアプリケーション用の全方位コンテンツを捕捉するための例示的な配置である。カメラユニット503は、球体の内径部分に7つのカメラレンズを装着することによって、7つの視野が集束するシーンを捕捉する。カメラユニット503内の配置は、光照射野又はホログラフィック没入型ディスプレイ用の光照射野を捕捉するための例示的な配置である。

【0113】

図5の例では、第2のサブプロセスにおいて、自然画像コンテンツ509が合成される。例えば、自然画像コンテンツ509は、一例では、捕捉ニューラルネットワークモデル508を生成するために訓練画像506の集合を使用するニューラルネットワーク訓練モジュール505を使用することができる合成モジュール504への入力として提供される。訓練プロセスの代わりに一般的に使用される他のプロセスは写真測量である。モデル508が図5に示すプロセス500中に作成される場合、モデル508は、自然コンテンツのインジェストフォーマット507のアセットのうちの1つになる。インジェストフォーマット507の例示的な実施形態は、MPI及びMSIを含む。

【0114】

図6は、合成メディア608、例えばコンピュータ生成画像のインジェストフォーマットを作成するプロセス600の図を示す。図6の例では、LIDARカメラ601はシーンの点群602を捕捉する。合成コンテンツを作成するためのコンピュータ生成画像（CGI）ツール、3Dモデリングツール、又は他のアニメーションプロセスは、ネットワークを介して604のCGIアセットを作成するためにコンピュータ603上で使用される。センサ605Aを有するモーション捕捉スーツが、行為者605に装着されて、行為者605の動きのデジタル記録を捕捉して、アニメーション化されたモーション捕捉（MoCap）データ606を生成する。データ602、604、及び606は、合成モジュール607への入力として提供され、合成モジュールも同様に、例えば、ニューラルネットワーク及び訓練データを使用して、ニューラルネットワークモデル（図6には示されていない）を作成することができる。

【0115】

本開示における異種没入型メディアを表示、ストリーミング、及び処理するための技術は、コンピュータ可読命令を使用するコンピュータソフトウェアとして実装され、1つ以上のコンピュータ可読メディアに物理的に記憶され得る。例えば、図7は、開示された主題の特定の実施形態を実装するのに適したコンピュータシステム700を示す。

【0116】

1つ以上のコンピュータ中央処理ユニット（CPU）、グラフィック処理ユニット（GPU）などによって直接実行するか、又は解釈、マイクロコード実行などを介して実行することができる命令を含むコードを作成するために、アセンブリ、コンパイル、リンクなどの機構に依存する可能性のある任意の適切な機械コード又はコンピュータ言語を使用して、コンピュータソフトウェアをコーディングすることができる。

【0117】

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム機、モノのインターネットデバイスなどを含む様々なタイプのコンピュータ又はコンピュータの構成要素上で実行されることができる。

【0118】

コンピュータシステム700について図7に示される構成要素は、本質的に例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲又は機能に関するいかなる限定も示唆することは意図されていない。また、構成要素の構成は、コンピュータシステム700の例示的な実施形態に示された構成要素のいずれか1つ又は組合せに関連するいかなる依存関係又は要件も有すると解釈されるべきではない。

【0119】

コンピュータシステム700は、特定のヒューマンインタフェース入力デバイスを含み得る。そのようなヒューマンインタフェース入力デバイスは、例えば、触知入力（キーストローク、スワイプ、データグローブの動きなど）、オーディオ入力（声、拍手など）、視覚入力（ジェスチャなど）、嗅覚入力（図示されていない）を介した1人以上の人間ユーザによる入力に応答し得る。ヒューマンインタフェースデバイスはまた、オーディオ（例えば、音声、音楽、周囲音）、画像（例えば、走査画像、静止画像カメラから取得される写真画像）、ビデオ（二次元ビデオ、立体ビデオを含む三次元ビデオなど）など、必ずしも人間による意識的な入力に直接関連しない特定のメディアをインジェストするために使用されることもできる。

【0120】

入力ヒューマンインタフェースデバイスは、キーボード701、マウス702、トラックパッド703、タッチスクリーン710、データグローブ（図示せず）、ジョイスティック705、マイク706、スキャナ707、カメラ708のうちの1つ以上（それぞれのうちの1つのみが図示される）を含んでもよい。

【0121】

コンピュータシステム700はまた、特定のヒューマンインタフェース出力デバイスを含んでもよい。そのようなヒューマンインタフェース出力デバイスは、例えば、触覚出力、音、光、及び匂い／味を介して、1人又は複数の人間ユーザの感覚を刺激し得る。そのようなヒューマンインタフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン710、データグローブ（図示せず）、又はジョイスティック705による触覚フィードバック、ただし入力デバイスとして機能しない触覚フィードバックデバイスもあり得る）、オーディオ出力デバイス（例えば、スピーカ709、ヘッドフォン（図示せず））、視覚出力デバイス（例えば、CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含み、それぞれがタッチスクリーン入力機能を有するか又は有さず、それぞれが触覚フィードバック機能を有するか又は有さず、これらのうちの幾つかは、ステレオ出力などの手段を介して二次元視覚出力又は三次元超出力を出力可能であるスクリーン710、仮想現実メガネ（図示せず）、ホログラフィックディスプレイ、及びスモークタンク（図示せず））、及びプリンタ（図示せず）を含んでもよい。

【0122】

コンピュータシステム700はまた、CD／DVD又は同様の媒体721を含むCD／DVD ROM／RW（720）を含む光学媒体、サムドライブ722、リムーバブルハードドライブ又はソリッドステートドライブ723、テープ及びフロッピーディスクなどのレガシー磁気媒体（図示せず）、セキュリティドングルなどの専用のROM／ASIC／PLDベースのデバイス（図示せず）など、人間がアクセス可能な記憶デバイス及びそれらの関連媒体も含むことができる。

【0123】

当業者はまた、本開示の主題に関連して使用される「コンピュータ可読媒体」という用語が、伝送媒体、搬送波、又は他の一時的な信号を包含しないことも理解するはずである。

【0124】

コンピュータシステム700はまた、1つ以上の通信ネットワーク755へのインタフェース754も含むことができる。ネットワークは例えば、無線ネットワーク、有線ネットワーク、光学ネットワークであり得る。ネットワークは更に、ローカル、ワイドエリア、メトロポリタン、車両及び産業用、リアルタイム、遅延耐性、などとすることができる。ネットワークの例は、イーサネット、無線LANなどのローカルエリアネットワーク、GSM、3G、4G、5G、LTEなどを含むセルラネットワーク、ケーブルTV、衛星TV及び地上波放送TVを含むTV有線又は無線ワイドエリアデジタルネットワーク、CANBusを含む車両及び産業用などを含む。特定のネットワークは一般に、特定の汎用データポート又は周辺バス749（例えば、コンピュータシステム700のUSBポートなど）に取り付けられた外部ネットワークインタフェースアダプタを必要とし、他のものは一般に、以下に説明するようなシステムバスへの取り付けによってコンピュータシステム700のコアに統合される（例えば、PCコンピュータシステムへのイーサネットインタフェース又はスマートフォンコンピュータシステムへのセルラネットワークインタフェース）。これらのネットワークのいずれかを使用して、コンピュータシステム700は他のエンティティと通信することができる。このような通信は、単方向受信専用（例えば、テレビ放送）、単方向送信専用（例えば、特定のCANbusデバイスへのCANbus）、又は例えば、ローカルもしくは広域デジタルネットワークを使用する他のコンピュータシステムへの双方向であり得る。特定のプロトコル及びプロトコルスタックが、前述されたように、それらのネットワーク及びネットワークインタフェースのそれぞれで使用されることができる。

【0125】

前述のヒューマンインタフェースデバイス、人間がアクセス可能な記憶デバイス、及びネットワークインタフェースは、コンピュータシステム700のコア740に取り付けられ得る。

【0126】

コア740は、1つ以上の中央処理ユニット（CPU）741、グラフィックス処理ユニット（GPU）742、フィールドプログラマブルゲートエリア（FPGA）743の形態の専用プログラマブル処理ユニット、特定のタスク用のハードウェアアクセラレータ744、グラフィックスアダプタ750などを含むことができる。これらのデバイスは、読み出し専用メモリ（ROM）745、ランダムアクセスメモリ746、内部の非ユーザアクセス可能ハードドライブ、SSDなど747の内部大容量記憶部と共に、システムバス748を介して接続され得る。幾つかのコンピュータシステムでは、システムバス748は、追加のCPU、GPUなどによる拡張を可能にするために、1つ又は複数の物理プラグの形態でアクセス可能であり得る。周辺デバイスは、コアのシステムバス748に直接取り付けることも、周辺バス749を介して取り付けることもできる。一例では、スクリーン710をグラフィックスアダプタ750に接続することができる。周辺バス用のアーキテクチャには、PCI、USBなどを含む。

【0127】

CPU741、GPU742、FPGA743、及びアクセラレータ744は、組み合わさって前述のコンピュータコードを構成することができる特定の命令を実行することができる。そのコンピュータコードを、ROM745又はRAM746に記憶することができる。過渡的なデータをRAM746に記憶することもでき、一方永続的なデータを、例えば、内部大容量記憶部747に記憶することができる。メモリデバイスのいずれかへの高速記憶及び取り込みを、1つ以上のCPU741、GPU742、大容量記憶部747、ROM745、RAM746などと密接に関連付けることができるキャッシュメモリの使用によって可能にすることができる。

【0128】

コンピュータ可読媒体は、様々なコンピュータ実装動作を行うためのコンピュータコードを有することができる。媒体及びコンピュータコードは、本開示の目的のために特別に設計及び構築されたものとすることもできるし、又はコンピュータソフトウェア技術の当業者に周知の利用可能な種類のものとすることもできる。

【0129】

限定ではなく、例として、アーキテクチャ700を有するコンピュータシステム、具体的にはコア740は、プロセッサ（CPU、GPU、FPGA、アクセラレータなどを含む）が1つ以上の有形のコンピュータ可読媒体において具現化されたソフトウェアを実行した結果として機能を提供することができる。このようなコンピュータ可読媒体は、前述したようなユーザアクセス可能な大容量ストレージ、並びにコア内部大容量記憶部747又はROM745などの非一時的な性質のものであるコア740の特定のストレージに関連付けられた媒体とすることができる。本開示の様々な実施形態を実施するソフトウェアを、そのようなデバイスに記憶し、コア740によって実行することができる。コンピュータ可読メディアは、特定の必要性に応じて、1つ以上のメモリデバイス又はチップを含むことができる。ソフトウェアは、コア740、具体的にはコア中のプロセッサ（CPU、GPU、FPGAなどを含む）に、RAM746に記憶されたデータ構造を定義すること、及びソフトウェアによって定義されたプロセスに従ってそのようなデータ構造を変更することを含む、本明細書に記載される特定のプロセス又は特定のプロセスの特定の部分を実行させることができる。これに加えて又は代えて、コンピュータシステムは、本明細書に記載される特定のプロセス又は特定のプロセスの特定の部分を実行するためにソフトウェアの代わりに、又はソフトウェアと一緒に動作することができる、回路において配線又はそれ以外の方法で具体化された論理（例えば、アクセラレータ744）の結果としての機能を提供することもできる。必要に応じて、ソフトウェアへの参照は論理を包含することができ、その逆も同様である。コンピュータ可読媒体への言及は、必要に応じて、実行のためのソフトウェアを記憶する回路（集積回路（IC）など）、実行のための論理を具体化する回路、又はその両方を包含することができる。本開示は、ハードウェアとソフトウェアの任意の適切な組合せを包含する。

【0130】

図8は、幾つかの例においてクライアントエンドポイントとして様々なレガシー及び異種没入型メディア対応ディスプレイをサポートするネットワークメディア配信システム800を示す。図8の例では、コンテンツ取得モジュール801は、図6又は図5の例示的な実施形態を使用してメディアを捕捉又は作成する。インジェストフォーマットは、コンテンツ準備モジュール802において作成され、次いで、送信モジュール803を使用してネットワークメディア配信システム内の1つ以上のクライアントエンドポイントに送信される。ゲートウェイ804は、顧客宅内機器にサービスして、ネットワークの様々なクライアントエンドポイントへのネットワークアクセスを提供することができる。セットトップボックス805はまた、ネットワークサービスプロバイダによる集約コンテンツへのアクセスを提供するための顧客宅内機器として機能し得る。無線復調器806は、（例えば、モバイルハンドセット及びディスプレイ813と同様に）モバイルデバイスのためのモバイルネットワークアクセスポイントとして機能し得る。1つ以上の実施形態では、レガシー2Dテレビ807は、ゲートウェイ804、セットトップボックス805、又はWiFiルータ808に直接接続されてもよい。レガシー2Dディスプレイ809を有するコンピュータラップトップは、WiFiルータ808に接続されたクライアントエンドポイントであってもよい。ヘッドマウント2D（ラスタベース）ディスプレイ810はまた、ルータ808に接続されてもよい。レンチキュラーライトフィールドディスプレイ811はゲートウェイ804に接続されてもよい。ディスプレイ811は、ローカル計算GPU811A、記憶デバイス811B、及び光線ベースのレンチキュラー光学技術を使用して複数のビューを作成する視覚プレゼンテーションユニット811Cから構成することができる。ホログラフィックディスプレイ812は、セットトップボックス805に接続されてもよく、ローカル計算CPU812A、GPU812B、記憶デバイス812C、及びフレネルパターン、波ベースのホログラフィック視覚化ユニット812Dを含んでもよい。拡張現実ヘッドセット814は、無線復調器806に接続することができ、GPU814A、記憶デバイス814B、バッテリ814C、及び体積視覚プレゼンテーション構成要素814Dを含むことができる。高密度光照射野ディスプレイ815は、WiFiルータ808に接続することができ、複数のGPU815A、CPU815B、及び記憶デバイス815C；視線追跡デバイス815D；カメラ815E；及び高密度光線ベースのライトフィールドパネル815Fを含むことができる。

【0131】

図9は、図8に前述したようにレガシー及び異種の没入型メディア対応ディスプレイにサービスを提供することができる没入型メディア配信モジュール900の図を示す。コンテンツは、それぞれ自然コンテンツ及びCGIコンテンツについて図5及び図6に具現化されるモジュール901において作成又は取得される。次いで、コンテンツは、作成ネットワークインジェストフォーマットモジュール902を使用してインジェストフォーマットに変換される。モジュール902の幾つかの例は、それぞれ自然コンテンツ及びCGIコンテンツについて図5及び図6に具体化されている。インジェストメディアは、任意選択で更新され、メディア再利用分析器911から、複数のシーンにわたって再利用される可能性のあるアセットに関する情報を記憶する。インジェストメディアフォーマットは、ネットワークに送信され、記憶デバイス903に記憶される。幾つかの他の例では、記憶デバイスは没入型メディアコンテンツ制作者のネットワーク内に存在し、二等分する破線で示すように没入型メディアネットワーク配信モジュール900によってリモートでアクセスされてもよい。クライアント及びアプリケーション固有の情報は、幾つかの例では、リモート記憶デバイス904で利用可能であり、これは、例では代替クラウドネットワークに任意選択的に遠隔に存在してもよい。

【0132】

図9に示すように、ネットワークオーケストレータ905は、配信ネットワークの主要なタスクを実行するための情報の主要なソース及びシンクとして機能する。この特定の実施形態では、ネットワークオーケストレータ905は、ネットワークの他の構成要素と統一された形式で実装されてもよい。それにもかかわらず、図9のネットワークオーケストレータ905によって示されるタスクは、幾つかの例では、開示された主題の要素を形成する。ネットワークオーケストレータ905は、ソフトウェアで実装することができ、処理を行うために処理回路によって実行されることができる。

【0133】

本開示の幾つかの態様によれば、ネットワークオーケストレータ905は、クライアントデバイスと通信するための双方向メッセージプロトコルを更に用いて、クライアントデバイスの特性に従ってメディア（例えば、没入型メディア）の処理及び配信を容易にすることができる。更に、双方向メッセージプロトコルは、異なる配信チャネル、すなわち、制御プレーンチャネル及びデータプレーンチャネルにわたって実装されてもよい。

【0134】

ネットワークオーケストレータ905は、図9のクライアント908（クライアントデバイス908とも呼ばれる）などのクライアントデバイスの特徴及び属性に関する情報を受信し、更に、クライアント908上で現在実行されているアプリケーションに関する要件を収集する。この情報は、デバイス904から取得されてもよく、又は代替の実施形態では、クライアント908に直接問い合わせることによって取得されてもよい。幾つかの例では、ネットワークオーケストレータ905とクライアント908との間の直接通信を可能にするために双方向メッセージプロトコルが使用される。例えば、ネットワークオーケストレータ905は、クライアント908に直接に問合せを送信することができる。幾つかの例では、スマートクライアント908Eは、クライアント908に代わってクライアント状態及びフィードバックの収集及び報告に参加することができる。スマートクライアント908Eは、処理回路によって実行されてプロセスを行うことができるソフトウェアに実装することができる。

【0135】

ネットワークオーケストレータ905はまた、図10に記載されるメディア適応及びフラグメンテーションモジュール910を起動して通信する。インジェストメディアがモジュール910によって適応され断片化されると、メディアは、幾つかの例では、配信記憶デバイス909のために準備されたメディアとして示されたメディア間記憶デバイスに転送される。配信メディアが準備されてデバイス909に記憶されると、ネットワークオーケストレータ905は、没入型クライアント908が、そのネットワークインタフェース908Bを介して、プッシュ要求を介して配信メディア及び対応する記述情報906を受信するか、又はクライアント908自体が記憶デバイス909からメディア906のプル要求を開始できることを保証する。幾つかの例では、ネットワークオーケストレータ905は、双方向メッセージインタフェース（図9には示されていない）を使用して、没入型クライアント908によって「プッシュ」要求を行ったり、「プル」要求を開始したりしてもよい。一例では、没入型クライアント908は、ネットワークインタフェース908B、GPU（又は図示しないCPU）908C、及びストレージ908Dを使用することができる。更に、没入型クライアント908は、ゲームエンジン908Aを使用することができる。ゲームエンジン908Aは、視覚化構成要素908A1及び物理エンジン908A2を更に使用することができる。ゲームエンジン908Aは、ゲームエンジンAPI及びコールバック機能908Fを介してメディアの処理をまとめて編成するためにスマートクライアント908Eと通信する。メディアの配信フォーマットは、クライアント908の記憶デバイス又はストレージキャッシュ908Dに記憶される。最後に、クライアント908は、視覚化構成要素908A1を介してメディアを視覚的に提示する。

【0136】

没入型メディアを没入型クライアント908にストリーミングするプロセス全体を通して、ネットワークオーケストレータ905は、クライアント進捗状況及び状態フィードバックチャネル907を介してクライアントの進捗状況を監視することができる。状態の監視は、スマートクライアント908Eに実装され得る双方向通信メッセージインタフェース（図9には示されていない）によって行われ得る。

【0137】

図10は、一部の例では、インジェストされたソースメディアが没入型クライアント908の要件に適応するように適切に適応され得るように、メディア適応プロセス1000の図を示す。メディア適応及びフラグメンテーションモジュール1001は、没入型クライアント908のための適切な配信フォーマットへのインジェストメディアの適応を容易にする複数の構成要素から構成される。図10において、メディア適応及びフラグメンテーションモジュール1001は、ネットワーク上の現在のトラフィック負荷を追跡するために入力ネットワーク状態1005を受信する。没入型クライアント908の情報は、属性及び特徴記述、アプリケーション特徴及び記述、並びにアプリケーションの現在状態、及びクライアントの錐台のジオメトリをインジェスト没入型メディアの補間機能にマッピングするのを助けるクライアントニューラルネットワークモデル（利用可能な場合）を含むことができる。そのような情報は、図9に908Eとして示されているスマートクライアントインタフェースを用いて双方向メッセージインタフェース（図10には示されていない）によって取得することができる。メディア適応及びフラグメンテーションモジュール1001は、適応出力が作成されると、それがクライアント適応メディア記憶デバイス1006に記憶されることを保証する。メディア再利用分析器1007は、図10に、事前に、又はメディアの配信のためのネットワーク自動化プロセスの一部として実行され得るプロセスとして示されている。

【0138】

幾つかの例では、メディア適応及びフラグメンテーションモジュール1001は、論理コントローラ1001Fによって制御される。一例では、メディア適応及びフラグメンテーションモジュール1001は、特定のインジェストソースメディアをクライアントに適したフォーマットに適応させるために、レンダラ1001B又はニューラルネットワークプロセッサ1001Cを使用する。一例では、メディア適応及びフラグメンテーションモジュール1001は、一例ではサーバデバイスなどのクライアントインタフェースモジュール1003からクライアント情報1004を受信する。クライアント情報1004は、クライアント記述及び現在状態を含むことができ、アプリケーション記述及び現在状態を含むことができ、クライアントニューラルネットワークモデルを含むことができる。ニューラルネットワークプロセッサ1001Cは、ニューラルネットワークモデル1001Aを用いる。そのようなニューラルネットワークプロセッサ1001Cの例には、MPI及びMSIに記載されているようなディープビューニューラルネットワークモデル生成器が含まれる。幾つかの例では、メディアは2Dフォーマットであるが、クライアントは3Dフォーマットを必要とし、次いで、ニューラルネットワークプロセッサ1001Cは、ビデオに描写されたシーンの立体表示を導出するために2Dビデオ信号から高度に相関した画像を使用するプロセスを呼び出すことができる。そのようなプロセスの例は、カリフォルニア大学バークレー校で開発された1つ又は少数の画像プロセスからのニューラル放射場であり得る。適切なレンダラ1001Bの一例は、メディア適応及びフラグメンテーションモジュール1001と直接対話するように修正されるOTOY Octaneレンダラ（図示せず）の修正バージョンであってもよい。メディア適応及びフラグメンテーションモジュール1001は、幾つかの例では、インジェストメディアのフォーマット及び没入型クライアント908によって必要とされるフォーマットに関するこれらのツールの必要性に応じて、メディア圧縮器1001D及びメディア解凍器1001Eを使用することができる。

【0139】

図11は、幾つかの例における配信フォーマット作成プロセス1100を示す。適応メディアパッケージングモジュール1103は、クライアント適応メディア記憶デバイス1102上に現在置かれているメディア適応モジュール1101（図10のプロセス1000として示されている）からメディアをパッケージングする。パッケージングモジュール1103は、メディア適応モジュール1101からの適応メディアをロバストな配信フォーマット1104、例えば、図3又は図4に示される例示的なフォーマットにフォーマットする。マニフェスト情報1104Aは、クライアント908に、受信することが期待され得るシーンデータアセットのリスト1104Bを提供するとともに、各アセットによる頻度を記述するオプションのメタデータが、プレゼンテーションを構成するシーンのセットにわたって使用される。リスト1104Bは、それぞれが対応するメタデータを有する視覚アセット、オーディオアセット、及び触覚アセットのリストを示す。この例示的な実施形態では、リスト1104B内の各アセットは、プレゼンテーションを構成する全てのシーンにわたって特定のアセットが使用された回数を示す数字頻度値を含むメタデータを参照する。

【0140】

図12は、幾つかの例におけるパケタイザプロセスシステム1200を示す。図12の例では、パケタイザ1202は、適応メディア1201を、ネットワーク上のクライアントエンドポイント1204として示される没入型クライアント908へのストリーミングに適した個々のパケット1203に分離する。

【0141】

図13は、幾つかの例において、インジェストフォーマットの特定の没入型メディアを特定の没入型メディアクライアントエンドポイントのためのストリーミング可能で適切な配信フォーマットに適応させるネットワークのシーケンス図1300を示す。

【0142】

図13に示す構成要素及び通信は以下のように説明される。すなわち、クライアント1301（幾つかの例では、クライアントエンドポイント、クライアントデバイスとも呼ばれる）は、ネットワークオーケストレータ1302（幾つかの例ではネットワーク配信インタフェースとも呼ばれる）に対するメディア要求1308を開始する。メディア要求1308は、URN又は他の標準的な命名法のいずれかによってクライアント1301によって要求されたメディアを識別するための情報を含む。ネットワークオーケストレータ1302は、クライアント1301がその現在利用可能なリソースに関する情報（クライアントの現在の動作状態を特徴付けるための計算、記憶、バッテリ充電率、及び他の情報を含む）を提供することを要求するプロファイル要求1309でメディア要求1308に応答する。プロファイル要求1309はまた、ニューラルネットワーク推論のためにネットワークによって使用されて正しいメディアビューを抽出又は補間してクライアントのプレゼンテーションシステムの特徴に一致させられ得る1つ以上のニューラルネットワークモデルがクライアントにおいて利用可能である場合、そのようなモデルをクライアントが提供することを要求する。クライアント1301からネットワークオーケストレータ1302への応答1310は、クライアントトークン、アプリケーショントークン、及び1つ以上のニューラルネットワークモデルトークンを提供する（そのようなニューラルネットワークモデルトークンがクライアントで利用可能である場合）。次いで、ネットワークオーケストレータ1302は、クライアント1301にセッションIDトークン1311を提供する。次いで、ネットワークオーケストレータ1302は、要求1308で識別されたメディアのURN又は標準名称を含むインジェストメディアリクエスト1312を用いてインジェストメディアサーバ1303を要求する。インジェストメディアサーバ1303は、インジェストメディアトークンを含む応答1313で要求1312に応答する。次いで、ネットワークオーケストレータ1302は、呼び出し1314において応答1313からのメディアトークンをクライアント1301に提供する。次いで、ネットワークオーケストレータ1302は、適応インジェスト1304にインジェストメディアトークン、クライアントトークン、アプリケーショントークン、及びニューラルネットワークモデルトークン1315を提供することによって、メディア要求1308に対する適応プロセスを開始する。適応インジェスト1304は、インジェストメディアアセットへのアクセスを要求する呼び出し時のインジェストメディアトークン1316をインジェストメディアサーバ1303に提供することによって、インジェストメディアへのアクセスを要求する。インジェストメディアサーバ1303は、適応インジェスト1304に対する応答1317において、インジェストメディアアクセストークンを有する要求1316に応答する。次いで、適応インジェスト1304は、メディア適応モジュール1305が、1313において作成されたセッションIDトークンに対応するクライアント、アプリケーション、及びニューラルネットワーク推論モデルのためにインジェストメディアアクセストークンに位置するインジェストメディアを適応させることを要求する。適応インジェスト1304からメディア適応モジュール1305への要求1318は、必要なトークンとセッションIDとを含む。メディア適応モジュール1305は、更新1319において、適応されたメディアアクセストークン及びセッションIDをネットワークオーケストレータ1302に提供する。ネットワークオーケストレータ1302は、インタフェース呼び出し1320において、パッケージングモジュール1306に、適応されたメディアアクセストークン及びセッションIDを提供する。パッケージングモジュール1306は、応答メッセージ1321においてパッケージ化されたメディアアクセストークン及びセッションIDと共に応答1321をネットワークオーケストレータ1302に提供する。パッケージングモジュール1306は、応答1322において、セッションIDのためのパッケージ化されたアセット、URN、及びパッケージ化されたメディアアクセストークンをパッケージ化されたメディアサーバ1307に提供する。クライアント1301は、要求1323を実行して、応答メッセージ1321で受信したパッケージ化されたメディアアクセストークンに対応するメディアアセットのストリーミングを開始する。クライアント1301は、他の要求を実行し、メッセージ1324内の状態更新をネットワークオーケストレータ1302に提供する。

【0143】

図14は、幾つかの例におけるシーンベースのメディア処理のための仮想ネットワーク及びクライアントデバイス1418（ゲームエンジンクライアントデバイス1418とも呼ばれる）を有するメディアシステム1400の図を示す。図4において、MPEGスマートクライアントプロセス1401によって示されるようなスマートクライアントは、ゲームエンジンクライアントデバイス1418内の他のエンティティによって、及び他のエンティティのために、並びにゲームエンジンクライアントデバイス1418の外部に存在するエンティティのために処理されるべきメディアを準備するための中央コーディネータとして機能することができる。幾つかの例では、スマートクライアントは、MPEGスマートクライアントプロセス1401（幾つかの例ではMPEGスマートクライアント1401とも呼ばれる）などのプロセスを行うために処理回路によって実行されることができるソフトウェア命令として実装される。ゲームエンジン1405は、主に、エンドユーザが体験するプレゼンテーションを作成するためにメディアをレンダリングする役割を担う。触覚構成要素1413、視覚化構成要素1415、及びオーディオ構成要素1414は、ゲームエンジン1405が触覚、視覚、及びオーディオメディアをそれぞれレンダリングするのを支援することができる。エッジプロセッサ又はネットワークオーケストレータデバイス1408は、ネットワークインタフェースプロトコル1420を介してMPEGスマートクライアント1401に情報及びシステムメディアを伝達し、MPEGスマートクライアントから状態更新及び他の情報を受信することができる。ネットワークインタフェースプロトコル1420は、複数の通信チャネル及びプロセスにわたって分割され、複数の通信プロトコルを使用することができる。幾つかの例では、ゲームエンジン1405は、制御論理14051、GPUインタフェース14052、物理エンジン14053、レンダラ14054、圧縮デコーダ14055、及びデバイス固有プラグイン14056を含むゲームエンジンデバイスである。MPEGスマートクライアント1401は、ネットワークとクライアントデバイス1418との間の主要なインタフェースとしても機能する。例えば、MPEGスマートクライアント1401は、ゲームエンジンAPI及びコールバック機能1417を使用してゲームエンジン1405と対話することができる。一例では、MPEGスマートクライアント1401は、ゲームエンジン1405に再構成されたメディアを処理させるためにゲームエンジン制御論理14051によって管理されるゲームエンジンAPI及びコールバック機能1417を呼び出す前に、1420で伝達されたストリーミングメディアを再構成する役割を果たすことができる。そのような例では、MPEGスマートクライアント1401は、圧縮デコーダプロセス1406を利用することができるクライアントメディア再構成プロセス1402を利用することができる。

【0144】

幾つかの他の例では、MPEGスマートクライアント1401は、API及びコールバック機能1417を呼び出す前に、1420でストリーミングされたパケット化メディアの再構成を担当しなくてもよい。そのような例では、ゲームエンジン1405は、メディアを解凍及び再構成することができる。更に、そのような例では、ゲームエンジン1405は、圧縮デコーダ14055を使用してメディアを解凍することができる。再構成されたメディアを受信すると、ゲームエンジン制御論理14051は、GPUインタフェース14052を使用して、レンダラプロセス14054を介してメディアをレンダリングすることができる。

【0145】

幾つかの例では、レンダリングされたメディアはアニメーション化され、次いで物理エンジン14053は、シーンのアニメーションにおける物理の法則をシミュレートするためにゲームエンジン制御論理14051によって使用され得る。

【0146】

幾つかの例では、クライアントデバイス1418によるメディアの処理全体を通して、ニューラルネットワークモデル1421は、MPEGスマートクライアント1401によって調整された動作を支援するために、ニューラルネットワークプロセッサ1403によって採用され得る。幾つかの例では、再構成プロセス1402は、ニューラルネットワークモデル1421及びニューラルネットワークプロセッサ1403を使用してメディアを完全に再構成する必要があり得る。同様に、クライアントデバイス1418は、メディアが再構成された後にネットワークから受信したメディアをクライアント適応メディアキャッシュ1404にキャッシュするか、又はメディアがレンダリングされた後にレンダリングされたメディアをレンダリングされたクライアントメディアキャッシュ1407にキャッシュするように、ユーザによってユーザインタフェース1412を介して構成することができる。更に、幾つかの例では、MPEGスマートクライアント1401は、システム提供の視覚的／非視覚アセットを、ユーザ提供メディアキャッシュ1416からのユーザ提供の視覚的／非視覚アセットで置き換えることができる。そのような実施形態では、ユーザインタフェース1412は、ユーザ提供の視覚的／非視覚アセットをユーザ提供メディアキャッシュ1419（例えば、クライアントデバイス1418の外部）からクライアントアクセス可能なユーザ提供メディアキャッシュ1416（例えば、クライアントデバイス1418の内部）にロードするステップを実行するようにエンドユーザを案内することができる。幾つかの実施形態では、MPEGスマートクライアント1401は、レンダリングされたアセットをレンダリングされたメディアキャッシュ1411に記憶する（潜在的な再利用又は他のクライアントとの共有のため）ように構成することができる。

【0147】

幾つかの例では、メディア分析器1410は、ゲームgngine 1405によるレンダリングのための潜在的な優先順位付けのため、及び／又はMPEGスマートクライアント1401を介した再構成処理のために、（ネットワーク内の）クライアント適応メディア1409を検査して、アセットの複雑さ、又はアセットが1つ以上のシーン（図示せず）にわたって再利用される頻度を決定することができる。そのような例では、メディア分析器1410は、1409に記憶されたメディアに複雑さ、優先順位付け、及びアセット使用頻度情報を記憶する。

【0148】

本開示では、プロセスが示され説明されているが、プロセスはソフトウェアモジュール内の命令として実施することができ、命令はプロセスを行うために処理回路によって実行されることができることに留意されたい。本開示では、モジュールが示され説明されているが、モジュールは命令を有するソフトウェアモジュールとして実装することができ、命令はプロセスを行うために処理回路によって実行されることができることにも留意されたい。

【0149】

本開示の第1の態様によれば、ゲームエンジンにシーンベースの没入型メディアを提供するために、ゲームエンジンを備えたクライアントデバイスにスマートクライアントを実装するために様々な技術を使用することができる。スマートクライアントは、1つ以上のプロセスによって具現化することができ、クライアントデバイスプロセスとネットワークサーバプロセスとの間に1つ以上の通信チャネルが実装される。幾つかの例では、スマートクライアントは、ネットワークサーバプロセスと、幾つかの例ではクライアントデバイス内のメディアレンダリングエンジンとして機能することができるクライアントデバイスのゲームエンジンとの間の特定のクライアントデバイス上でのシーンベースのメディアの処理を容易にするために、メディア及びメディア関連情報を受信及び伝達するように構成される。メディア及びメディア関連情報は、メタデータ、コマンドデータ、クライアント状態情報、メディアアセット、及びネットワーク内の1つ以上の動作態様の最適化を容易にする情報を含むことができる。同様に、クライアントデバイスの場合、スマートクライアントは、ネットワークからストリーミングされたシーンベースの没入型メディアの再生を効率的に可能にするために、ゲームエンジンによって提供されるアプリケーションプログラミングインタフェースの利用可能性を使用することができる。没入型メディア処理デバイスの異種集合をサポートすることを目的としたネットワークアーキテクチャでは、本明細書に記載のスマートクライアントは、ネットワークサーバプロセスが特定のクライアントデバイスと対話し、特定のクライアントデバイスにシーンベースのメディアを配信するためのメインインタフェースを提供するネットワークアーキテクチャの構成要素である。同様に、クライアントデバイスについて、スマートクライアントは、ゲームエンジンによるレンダリングのためのシーンベースのアセットの効率的な管理及び配信を引き起こすために、クライアントデバイスのゲームエンジンによって使用されるプログラミングアーキテクチャを利用する。

【0150】

図15は、幾つかの例における、ネットワークを介したクライアントデバイスへのメディア配信のためのメディアフロープロセス1530（プロセス1530とも呼ばれる）の図である。プロセス1530は、図1に示されたプロセス100と同様であるが、「クラウド」又は「エッジ」に示されたメディア配信のための明示的なプロセスを有する。更に、図15のクライアントデバイスは、クライアントデバイスに代わって実行するプロセスのうちの1つとしてゲームエンジンプロセスの使用を明示的に示している。スマートクライアントプロセスはまた、クライアントデバイスに代わって実行するプロセスの1つとして示されている。

【0151】

プロセス1530は、図1のプロセス100と同様であるが、明示的なメディアストリーミングプロセス1536が示されており、スマートクライアントプロセス1539の論理がクライアントデバイス15312の構成部分として示されている。スマートクライアントプロセス1539は、メディア配信ネットワークがクライアントデバイス15312と通信するための主要インタフェースとして機能する。幾つかの例では、クライアントデバイス15312は、メディアをレンダリングするためにゲームエンジンを使用し、メディアプレゼンテーションフォーマットC 15311は、フレームベースのメディアではなくシーンベースである。したがって、そのようなスマートクライアントプロセスは、シーンベースのメディアから頻繁に再利用されるアセットがクライアントデバイス15312によって既に受信されており、ネットワークがそれらを再びクライアントデバイス15312にストリーミングする必要がないネットワークに通信する重要な役割を果たすことができる。プロセス1530は、一連のステップを含み、プロセス（ステップ）1531で開始する。プロセス1531において、メディアは、コンテンツプロバイダ（図示せず）によってネットワークにインジェストされる。次に、配信メディアプロセス（ステップ）1532は、メディアを配信フォーマットBに変換する。次に、プロセス（ステップ）1533は、配信フォーマットBのメディアを、ネットワークを介してパケット化及びストリーミングすることができる別のフォーマット1535に変換する。次いで、メディアストリーミングプロセス1536は、ネットワークを介してゲームエンジンクライアントデバイス15312にメディア1537を配信する。スマートクライアントプロセス1539は、クライアントデバイス15312に代わってメディアを受信し、情報チャネル1538を介して進捗状況、状態、及び他の情報をネットワークに返す。スマートクライアントプロセス1539は、レンダリングプロセス15310を介してメディアを更に別のフォーマットプレゼンテーションフォーマットC 15311に変換することを含むことができるクライアントデバイス15312の構成部分を用いて、ストリーミングされたメディア1537の処理を調整する。

【0152】

図16は、幾つかの例におけるゲームエンジンプロセスへのアセット再利用を伴うメディアフロープロセス1640（プロセス1640とも呼ばれる）の図を示す。プロセス1640は、図15に示すプロセス1530と同様であるが、クライアントデバイスが問題のアセットへのアクセスを既に持っているかどうかを決定するために問合せ論理が明示的に示されており、したがってネットワークはアセットを再度ストリーミングする必要がない。図16では、クライアントデバイスは、クライアントデバイスの一部として存在するスマートクライアント及びゲームエンジンと共に示されている。

【0153】

プロセス1640は、図15に示すプロセス1530と同様であるが、クライアントデバイス（例えば、ゲームエンジンを持つ）16412がターゲットのメディアアセットに既にアクセスしているかどうかを決定するために問合せ論理が明示的に示されており、したがって、ネットワークはアセットを再度ストリーミングする必要がない。図15に示すプロセス1530と同様に、図16に示すプロセス1640は、プロセス（ステップ）1641から始まる一連のステップを含む。プロセス1641において、メディアは、コンテンツプロバイダ（図示せず）によってネットワークにインジェストされる。プロセス（ステップ）1642は、問題のメディアアセットが以前にクライアントデバイスにストリーミングされており、したがって再びストリーミングされる必要がないかどうかを決定する。プロセス1642の関連するステップの幾つかは、問題のメディアアセットが以前にクライアントデバイスにストリーミングされており、したがって再びストリーミングされる必要がないかどうかを決定する論理を示すために明示的に示されている。例えば、配信メディア作成開始プロセス1642Aは、プロセス1642の論理シーケンスを開始する。意思決定プロセス1642Bは、スマートクライアントフィードバック及び状態1648に含まれる情報によって、メディアをクライアントデバイス16412にストリーミングする必要があるか否かを決定する。メディアがクライアントデバイス16412にストリーミングされる必要がある場合、プロセス1642Dは、ストリーミングされるメディアを準備し続ける。メディアがクライアントデバイス16412にストリーミングされるべきでない場合、プロセス1642Cは、メディアアセットがストリーミングされたメディア1647に含まれないことを示す（したがって、別のソース、例えばクライアントデバイスに利用可能なリソースキャッシュから取得することができる）。プロセス1642Eは、プロセス1642の終了をマークする。次いで、プロセス1643は、配信フォーマットBのメディアを、ネットワークを介してパケット化及びストリーミングすることができる別のフォーマット1645に変換する。次いで、メディアストリーミングプロセス1646は、ネットワークを介してクライアントデバイス16412（ゲームエンジンを持つ）にメディア1647を配信する。スマートクライアントプロセス1649は、クライアントデバイス16412に代わってメディアを受信し、情報チャネル1648を介して進捗状況、状態、及び他の情報をネットワークに返す。スマートクライアントプロセス1649は、レンダリングプロセス16410を介してメディアを更に別のフォーマットプレゼンテーションフォーマットC 16411に変換することを含むことができるクライアントデバイス16412の構成部分を用いて、ストリーミングされたメディア1647の処理を調整する。

【0154】

図17は、クライアントデバイス（例えば、ゲームエンジンクライアントデバイス）のためのアセット再利用論理及び冗長キャッシュを有するメディア変換意思決定プロセス1730（プロセス1730とも称される）の図を示す。プロセス1730は、図2のプロセス200と同様であるが、（別のフォーマット又はその元のフォーマットに変換された）元のメディア自体の代わりに元のメディアへのプロキシをストリーミングする必要があるかどうかを決定するための論理が追加されている。

【0155】

図17では、ネットワークを通るメディアのフローは、クライアントデバイスにメディアを配信する前にネットワークがメディアを変換する必要があるかどうかを決定するために、2つの意思決定プロセスを使用する。図17において、プロセスステップ1731において、フォーマットAで表されるインジェストされたメディアは、コンテンツプロバイダ（図示せず）によってネットワークに提供される。プロセスステップ1732は、クライアントデバイス（図示せず）の処理能力を記述する属性を取得する。意思決定プロセスステップ1733は、ネットワークが以前に特定のメディアオブジェクト（メディアアセットとも呼ばれる）をクライアントデバイスにストリーミングしたかどうかを決定するために用いられる。メディアオブジェクトが以前にクライアントデバイスにストリーミングされている場合、プロセスステップ1734は、クライアントデバイスがそのローカルキャッシュ又は他のキャッシュから以前にストリーミングされたメディアオブジェクトのコピーにアクセスできることを示すために、メディアオブジェクトの代わりにプロキシ（例えば、識別子）を使用する。メディアオブジェクトが以前にストリーミングされていない場合、メディアオブジェクトがクライアントデバイスにストリーミングされる前に、例えば、特定のメディアオブジェクトのフォーマットAからフォーマットBへの変換など、ネットワーク又はクライアントデバイスが、プロセスステップ1731において、インジェストされたメディア内に含まれるメディアアセットのいずれかのフォーマット変換を行う必要があるかどうかを決定するために、意思決定プロセスステップ1735が用いられる。メディアアセットのいずれかがネットワークによって変換される必要がある場合、ネットワークは、メディアアセットをフォーマットAからフォーマットBに変換するためにプロセスステップ1738を使用する。変換されたメディア1739は、プロセスステップ1738からの出力である。変換されたメディア1739は、クライアントデバイス（図示せず）にストリーミングされるメディアを準備するために準備プロセスステップ1736にマージされる。プロセス1737は、メディアをクライアントデバイスにストリーミングする。

【0156】

幾つかの例では、クライアントデバイスはスマートクライアントを含む。スマートクライアントは、受信したメディアアセットが初めてストリーミングされ、再利用されるかどうかを決定するプロセスステップ17310を行うことができる。受信されたメディアアセットが初めてストリーミングされ、再利用される場合、スマートクライアントは、クライアントデバイスによってアクセス可能なキャッシュ（冗長キャッシュとも呼ばれる）内に再利用可能なメディアアセットのコピーを作成するプロセスステップ17311を行うことができる。キャッシュは、クライアントデバイスの内部キャッシュとすることができ、クライアントデバイスからの外部キャッシュデバイスとすることができる。

【0157】

図18は、ゲームエンジンクライアントプロセス1840（プロセス1840とも呼ばれる）のためのスマートクライアントを用いたアセット再利用論理の図である。プロセス1840は、図17に示すプロセス1730と同様であるが、図17に示すアセット問合せ論理プロセス1733は、図18に示すアセット問合せ論理1843によって実装され、特定のアセットがクライアントデバイスに既にアクセス可能であるどうかを決定する際のクライアントデバイスのスマートクライアントの役割を示す。メディアは、プロセスステップ1841においてネットワークにインジェストされる。プロセスステップ1842は、ターゲットクライアント（図示せず）の処理能力を記述する属性を取得する。次いで、ネットワークは、メディアアセットをクライアントデバイスにストリーミングする必要があるか否かを決定するために、アセット問合せ論理1843を開始する。スマートクライアントプロセスステップ1843Aは、プレゼンテーションに必要なメディアアセットに関する情報をネットワーク（例えば、ネットワークサーバプロセス）から受信する。スマートクライアントは、データベース（例えば、ローカルキャッシュ、クライアントデバイスによってアクセス可能なネットワークストレージ）1843Bからの情報にアクセスして、問題のメディアアセットがクライアントデバイスに既にアクセス可能であるかどうかを決定する。スマートクライアントプロセス2043Cは、問題のメディアアセットをストリーミングする必要があるか否かに関する情報をネットワークサーバのアセット問合せ論理1843に返す。アセットをストリーミングする必要がない場合、プロセスステップ1844は、問題のメディアアセットのプロキシを作成し、そのプロキシを、プロセスステップ1846でクライアントデバイスへのストリーミングに備えるメディアに挿入する。メディアアセットがクライアントデバイスにストリーミングされる必要がある場合、ネットワークサーバプロセスステップ1845は、ネットワークがクライアントデバイスにストリーミングされるメディアの任意の変換を支援する必要があるかどうかを決定する。そのような変換が必要であり、その変換がネットワークの利用可能なリソースによって行われる必要がある場合、ネットワークプロセス1848は変換を行う。次いで、変換されたメディア1849は、変換されたメディアをクライアントデバイスにストリーミングされるべきメディアにマージするためにプロセスステップ1846に提供される。ネットワークプロセスステップ1845において、ネットワークがメディアのそのような変換を行わないように決定がなされる場合、プロセスステップ1846は、クライアントデバイスにストリーミングされる元のメディアアセットを有するメディアを準備する。プロセスステップ1846に続いて、メディアは、プロセスステップ1847においてクライアントデバイスにストリーミングされる。

【0158】

図19は、クライアントデバイス1952Bのスマートクライアント1952Aを用いて（例えば、ゲームエンジンを用いて）取得されるデバイス状態及びプロファイルのためのプロセス1950の図を示す。プロセス1950は、図18に示すプロセス1840と同様であるが、メディアをレンダリングするためのリソースの利用可能性を含むクライアントデバイスの能力に関する情報を取得する際のスマートクライアントの役割を示すために、スマートクライアントからクライアントデバイスの属性を取得するためのプロセス1952によって実施される、図18に示すクライアントプロセス1842の属性を取得する。メディアは、プロセスにおいてネットワークにインジェストされ、プロセスステップ1951においてゲームエンジンクライアントデバイス（図示せず）によって要求される。プロセス1952は、クライアントデバイスのデバイス属性及びリソース状態を取得するためにスマートクライアントへの要求を開始する。例えば、スマートクライアント1952Aは、クライアントデバイス1952B及びその追加のリソース（もしあれば）1952Cに対する問合せを開始して、クライアントデバイスに関する記述属性、及び将来の作業を処理するためのリソース利用可能性を含むそのリソースに関する情報をそれぞれ取り出す。クライアントデバイス1952Bは、クライアントデバイス（例えば、インジェストされたメディアのためのターゲットクライアントデバイス）の処理能力を記述するクライアントデバイス属性を配信する。クライアントデバイス上のリソースの状態及び利用可能性は、追加のリソース1952Cからスマートクライアント1952Aに返される。次いで、ネットワークは、アセット（メディアアセット）をクライアントデバイスにストリーミングする必要があるかどうかを決定するために、アセット問合せ論理1953を開始する。アセットをストリーミングする必要がない場合、プロセスステップ1954は、問題のアセットのプロキシを作成し、そのプロキシを、プロセスステップ1956でクライアントデバイスへのストリーミングに備えてメディアに挿入する。アセットがクライアントデバイスにストリーミングされる必要がある場合、ネットワークサーバプロセスのステップ1955は、そのような変換が必要な場合、ネットワークがクライアントにストリーミングされるメディアの任意の変換を支援する必要があるかどうかを決定する。そのような変換が必要であり、その変換がネットワークの利用可能なリソースによって行われる必要がある場合、ネットワークプロセスステップ1958は変換を行う。次いで、変換されたメディア1959は、変換されたメディアをクライアントデバイスにストリーミングされるべきメディアにマージするために、プロセスステップ1956に提供される。ネットワークプロセスステップ1955において、ネットワークがそのようなメディアの変換を行う必要がないように決定がなされた場合、プロセスステップ1956は、クライアントデバイスにストリーミングされる元のメディアアセットを有するメディアを準備する。プロセスステップ1956に続いて、メディアは、プロセスステップ1957においてクライアントデバイスにストリーミングされる。

【0159】

図20は、クライアントデバイスのゲームエンジンに代わってネットワークからストリーミングされたメディアを要求及び受信するクライアントデバイスにおけるスマートクライアントを説明するためのプロセス2060の図を示す。プロセス2060は、図19に示すプロセス1950又は図17のプロセス1730と同様であるが、クライアントデバイス20611の代わりにスマートクライアント20610によって管理されるメディアの要求及び受信が明示的に追加されている。図20において、ユーザは、プロセスステップ20612において特定のメディアを要求する。リクエストは、クライアントデバイス20611により受信される。クライアントデバイス20611は、メディアの要求をスマートクライアント20610に転送する。スマートクライアント20610は、プロセスステップ2061において、メディア要求をサーバに転送する。プロセスステップ2061のサーバはメディア要求を受信する。プロセスステップ2062において、サーバは、デバイス属性及びリソース状態を取得するためのステップを開始する（属性及びリソース状態を取得するための正確なステップは図示せず）。クライアントデバイス上のリソースの状態及び利用可能性は、プロセスステップ2062においてサーバに返される。次いで、ネットワーク（例えば、サーバ）は、アセット（メディアアセット）をクライアントデバイスにストリーミングする必要があるかどうかを決定するために、アセット問合せ論理2063を開始する。アセットをストリーミングする必要がない場合、プロセスステップ2064は、問題のアセットのプロキシを作成し、そのプロキシを、プロセスステップ2066でクライアントデバイスへのストリーミングに備えてメディアに挿入する。アセットがクライアントデバイスにストリーミングされる必要がある場合、ネットワークサーバは、プロセスステップ2065で、そのような変換が必要な場合、ネットワークがクライアントデバイスにストリーミングされるメディアの任意の変換を支援する必要があるかどうかを決定する。そのような変換が必要であり、その変換がネットワークの利用可能なリソースによって行われる必要がある場合、プロセスステップ2068でネットワーク（例えば、ネットワークサーバ）が変換を行う。次いで、変換されたメディア2069は、変換されたメディアをクライアントデバイスにストリーミングされるべきメディアにマージするためにプロセスステップ2066に提供される。ネットワークプロセス2065において、ネットワークがそのようなメディアの変換を行わないように決定がなされた場合、プロセスステップ2066は、クライアントデバイスにストリーミングされる元のメディアアセットを有するメディアを準備する。プロセスステップ2066に続いて、プロセス2067において、メディアはクライアントデバイスにストリーミングされる。幾つかの例では、メディアは、クライアントデバイス20611にアクセス可能なメディアストア20613に到達する。クライアントデバイス20611は、メディアストア20613からメディアにアクセスする。メディアストア20613は、一例ではクライアントデバイス20611内にあってもよい。別の例では、メディアストア20613は、クライアントデバイス20611と同じローカルネットワーク内のデバイス内など、クライアントデバイス20611の外部にあり、クライアントデバイス20611はメディアストア20613にアクセスすることができる。

【0160】

図21は、幾つかの例における降順の頻度により順序付けられたタイムドメディア表示の図2130を示す。タイムドメディア表示は、図3に示すタイムドメディア表示に類似しているが、図21の図2130のタイムドメディア表示のアセットは、各アセットタイプ内のアセットタイプ及び降順頻度値によってリスト内で順序付けられる。具体的には、タイムドシーンマニフェスト2103Aは、シーン情報2131のリストを含む。シーン情報2131は、シーン情報2131内の処理情報及びメディアアセットのタイプを別々に記述する構成要素2132のリストを指す。構成要素2132は、ベース層2134及び属性強化層2135を更に示すアセット2133を指す。図21の例では、ベース層2134のそれぞれは、対応する頻度メトリックの降順の値に従って順序付けられている。他のシーンにおいて以前に使用されたことがない固有のアセットのリストが、2137において提供される。プロキシ視覚アセット2136は再利用された視覚アセットの情報を含み、プロキシオーディオアセット2138は再利用されたオーディオアセットの情報を含む。

【0161】

幾つかの例では、降順の頻度による順序付けは、遅延を低減するために、クライアントデバイスが最初に高周波再利用でメディアアセットを処理することを可能にすることができる。

【0162】

図22は、幾つかの例における頻度によって順序付けられた非タイムドメディア表示の図2240を示す。非タイムドメディア表示は、図4に示す非タイムドメディア表示に類似しているが、図22の図2240の非タイムドメディア表示のアセットは、各アセットタイプ内のアセットタイプと頻度値によってリストで順序付けられる。非タイムドシーンマニフェスト（図示せず）は、シーン1．0に分岐することができる他のシーンがないシーン1．0を参照する。シーン1．0のシーン情報2241は、クロックによる開始時間及び終了時間に関連付けられていない。シーン情報2241はまた、シーン情報2241内の処理情報及びメディアアセットのタイプを別々に記述する構成要素2242のリストを指す。構成要素2242は、ベース層2244並びに属性強化層2245及び2246を更に指すアセット2243を指す。図22の例では、ベース層2244のそれぞれは、プレゼンテーションのシーンのセットにわたってアセットが使用された回数を示す数字頻度値を指す。例えば、触覚アセット2243は頻度値を増加させることによって編成され、オーディオアセット2243は頻度値を減少させることによって編成される。また、シーン情報2241は、非タイムドメディア用の他のシーン情報2241を参照する。シーン情報2241は、タイムドメディアシーンのためのシーン情報2247も参照する。リスト2248は、高次（例えば、親）シーンで以前に使用されたことがない特定のシーンに関連付けられた固有のアセットを識別する。

【0163】

本開示における頻度による順序付けは説明のためのものであり、メディア配信を最適化するために、アセットは任意の適切な増減頻度値による順序付けとすることができることに留意されたい。幾つかの例では、アセットの順序は、クライアントデバイスからネットワークへのフィードバック信号でネットワークに提供できるクライアントデバイスの処理能力、リソース、及び最適化戦略に従って決定される。

【0164】

図23は、順序付けられた頻度を有する分布フォーマット作成プロセス2340を示す。プロセス2340は、図11のプロセス1100と同様であり、これは、同じ適応ソースメディアを表示及びストリーミングに適したデータモデルにネットワークフォーマットすることを示す。しかしながら、処理2340に示す結果として得られる分布形式は、アセットが最初にアセットタイプによって順序付けられ、次に、例えば、アセットタイプに基づく昇順又は降順頻度値のいずれかで、プレゼンテーション全体にわたってアセットが使用される頻度によって順序付けられることを示す。

【0165】

図23において、適応メディアパッケージングプロセス2343は、クライアント適応メディア（クライアントに適応したメディア）を記憶するように構成されている記憶デバイス2342上に今置かれているメディア適応プロセス2341（図10のプロセス1000として示されている）からメディアをパッケージ化する。パッケージングプロセス2343は、プロセス2341からの適応メディアを、例えば図3又は図4に示される例示的なフォーマットであるロバストな配信フォーマット2344にフォーマットする。マニフェスト情報2344Aは、クライアントデバイスに、受信することが期待できるシーンデータアセット2344Bのリスト、並びにプレゼンテーション全体のシーンのセットにわたって全てのアセットが使用される頻度を示すオプションのメタデータを提供する。リスト2344Bは、視覚アセット、オーディオアセット、及び触覚アセットのリストを示し、それぞれが対応するメタデータを有する。図23の例では、パッケージングプロセス2343は、2344Bのアセットを順序付け、すなわち、2344Bの視覚アセットは頻度を下げることによって順序付けられ、一方、2344Bのオーディオ及び触覚アセットは頻度を上げることによって順序付けられる。

【0166】

図24は、図9に描写されたメディア再利用分析器911のようなメディア再利用分析器のための論理フロー（プロセス）のフローチャート2400を示す。プロセスは、ステップ2401で開始して、シーン間でのアセット再利用のためにプレゼンテーションを最適化する。ステップ2402は、反復子「i」を0に初期化し、図3又は図4に示すように、プレゼンテーションの全てのシーンにわたって遭遇する固有のアセットを識別するリストのセット2404（シーンごとに1つのリスト）を更に初期化する。リスト2404は、プレゼンテーション全体に対して固有のアセットを記述する情報のサンプルリストエントリを示し、アセットのメディアのタイプ（例えば、メッシュ、オーディオ、又はボリューム）、アセットの固有の識別子、及びプレゼンテーションのシーンのセットにわたってアセットが使用された回数のインジケータを含む。一例として、シーンNー1の場合、シーンNー1に必要な全てのアセットがシーン1及びシーン2でも使用されるアセットとして識別されているため、そのリストに含まれるアセットはない。ステップ2403は、反復子「i」がプレゼンテーション内のシーンの総数（図3又は図4に示すように）未満であるかどうかを決定する。反復子「i」がプレゼンテーション内のシーン数Nに等しい場合、再利用分析はステップ2405で終了する。そうではなく、反復子「i」がシーンの総数よりも小さい場合、プロセスはステップ2406に進み、反復子「j」が0に設定される。ステップ2407は、反復子「j」をテストして、反復子「j」が現在のシーン「i」内のメディアアセットの総数（メディアオブジェクトとも呼ばれる）未満であるかどうか決定する。反復子「j」がシーン「i」のメディアアセットの総数より小さければ、プロセスはステップ2408に進む。そうでなければ、プロセスはステップ2412に進み、そこで反復子「i」がステップ2403に戻る前に1だけインクリメントされる。「j」の値がシーン「i」のアセットの総数より小さければ、プロセスは条件ステップ2408に続き、メディアアセットの特徴が現在のシーン「i」の前のシーンから以前に分析されたアセットと比較される。アセットがシーン「i」の前のシーンで使用されたアセットとして識別された場合、ステップ2411で、アセットがシーン0からN－1にわたって使用された回数（例えば、頻度）が1だけインクリメントされる。そうではなく、アセットが固有のアセットである場合、すなわち、反復子「i」のより小さい値に関連付けられたシーンにおいて以前に分析されたことがない場合、ステップ2409において、シーン「i」のリスト2404に固有のアセットエントリが作成される。ステップ2409はまた、アセットのエントリに固有の識別子を作成して割り当て、アセットがシーン0～N－1にわたって使用された回数を1に設定する。ステップ2409に続いて、プロセスはステップ2410に進み、そこで反復子「j」が1だけインクリメントされる。ステップ2410の後、プロセスはステップ2407に戻る。

【0167】

図25は、クライアントデバイス内のスマートクライアント及びゲームエンジンと通信するネットワークプロセスの図2500を示す。ネットワークオーケストレーションプロセス2501は、ネットワークインタフェースプロセス2502を介して状態更新及び他の情報2503に情報及びメディアを伝達し、状態更新及び他の情報を受信する。同様に、ネットワークインタフェースプロセス2502は、情報及びメディアをクライアントデバイス2504に伝達し、状態更新及び他の情報をクライアントデバイスから受信する。クライアントデバイス2504は、ゲームエンジンクライアントデバイスの特定の実施形態を示している。スマートクライアント2504Aは、ネットワークとクライアントデバイス2504内の他のメディア関連プロセス及び／又は構成要素との間の主要インタフェースとして機能する。例えば、スマートクライアント2504Aは、ゲームエンジン2504Gと対話するためにゲームエンジンAPI及びコールバック機能（図示せず）を使用することができる。幾つかの例では、スマートクライアント2504Aは、ゲームエンジン2504Gに再構成されたメディアを処理させるためにゲームエンジン制御論理2504G1によって管理されるゲームエンジンAPI（図示せず）を呼び出す前に、2503で伝達されたストリーミングメディアを再構成する役割を果たすことができる。そのような例では、スマートクライアント2504Aは、圧縮デコーダプロセス2504Bを利用することができるクライアントメディア再構成プロセス2504Hを利用することができる。幾つかの他の例では、スマートクライアント2504Aは、ゲームエンジン2504Gにメディアを解凍及び処理させるためにゲームエンジンAPI（図示せず）を呼び出す前に、2503でストリーミングされたパケット化メディアを再構成することのみを担当することができる。そのような例では、ゲームエンジン2504Gは、圧縮デコーダ2504G6を使用してメディアを解凍することができる。再構成されたメディアを受信し、任意選択的にメディアを解凍すると（例えば、メディアは、スマートクライアント2504Aを介してクライアントデバイスに代わって解凍されていてもよい）、ゲームエンジン制御論理2504G1は、GPUインタフェース2504G5を使用して、レンダラプロセス2504G3を介してメディアをレンダリングすることができる。レンダリングされたメディアがアニメーション化される場合、シーンのアニメーションにおける物理の法則をシミュレートするために、物理エンジン2504G2がゲームエンジン制御論理2504G1によって使用され得る。

【0168】

クライアントデバイス2504によるメディアの処理全体を通して、ニューラルネットワークモデル2504Eを使用して、クライアントデバイスによって行われる動作を案内することができる。例えば、場合によっては、再構成プロセス2504Hは、ニューラルネットワークモデル2504E及びニューラルネットワークプロセッサ2504Fを使用してメディアを完全に再構成する必要があり得る。同様に、クライアントデバイス2504は、クライアントデバイス制御論理2504Jを介して、再構成された後にネットワークから受信したメディアをキャッシュし、又はレンダリングされた後にメディアをキャッシュするように構成することができる。そのような実施形態では、クライアント適応メディアキャッシュ2504Dは、再構成されたクライアントメディアを記憶するために利用されてもよく、レンダリングされたクライアントメディアキャッシュ2504Iは、レンダリングされたクライアントメディアを記憶するために利用されてもよい。更に、クライアントデバイス制御論理2504Jは、クライアントデバイス2504に代わってメディアのプレゼンテーションを完了することを担当することができる。そのような実施形態では、視覚構成要素2504Cは、クライアントデバイス2504による最終視覚プレゼンテーションの作成を担当することができる。

【0169】

図26は、本開示の一実施形態によるプロセス2600の概要を示すフローチャートを示す。プロセス2600は、クライアントデバイスをネットワークとインタフェース接続するためのスマートクライアントを有するクライアントデバイスなどの電子デバイスで実行することができる。幾つかの実施形態では、プロセス2600はソフトウェア命令で実施され、したがって、処理回路がソフトウェア命令を実行すると、処理回路はプロセス2600を行う。例えば、スマートクライアントはソフトウェア命令で実装され、ソフトウェア命令は処理回路によって実行されて、プロセス2600を含むことができるスマートクライアントプロセスを行うことができる。プロセスは、S2601で開始し、S2610へ進む。

【0170】

S2610において、電子デバイスのクライアントインタフェース（例えば、スマートクライアント）は、ネットワーク内のサーバデバイスに、電子デバイスでシーンベースの没入型メディアを再生するための能力及び利用可能性の情報を送信する。

【0171】

S2620において、クライアントインタフェースは、シーンベースの没入型メディアに適応したメディアコンテンツを搬送するメディアストリームを受信し、適応したメディアコンテンツは、能力及び利用可能性の情報に基づいてサーバデバイスによってシーンベースの没入型メディアから生成される。

【0172】

S2630において、シーンベースの没入型メディアは、適応したメディアコンテンツに従って電子デバイスで再生される。

【0173】

幾つかの例では、クライアントインタフェースは、適応したメディアコンテンツから、第1のシーンと関連付けられた第1のメディアアセットが初めて受信され、1つ以上のシーンで再利用されるべきであると決定する。クライアントインタフェースは、第1のメディアアセットを、電子デバイスによってアクセス可能なキャッシュデバイスに記憶させることができる。

【0174】

幾つかの例では、クライアントインタフェースは、メディアストリームから第1のシーン内の固有のアセットの第1のリストを抽出することができる。第1のリストは、第1のメディアアセットを第1のシーン内の固有のアセットとして識別し、1つ以上の他のシーンで再利用される。

【0175】

幾つかの例では、クライアントインタフェースは、信号をサーバデバイスに送信することができ、信号は、電子デバイスにおける第1のメディアアセットの利用可能性を示す。信号は、サーバデバイスに、適応したメディアコンテンツ内の第1のメディアアセットの代わりにプロキシを使用させる。

【0176】

幾つかの例では、シーンベースの没入型メディアを再生するために、クライアントインタフェースは、適応したメディアコンテンツ内のプロキシに従って、第1のメディアアセットがキャッシュデバイスに以前に記憶されていると決定する。クライアントインタフェースは、キャッシュデバイスにアクセスして第1のメディアアセットを取り出すことができる。

【0177】

一例では、クライアントインタフェースは、サーバデバイスから、第1のメディアアセットのための問合せ信号を受信し、問合せ信号に応答して、第1のメディアアセットがキャッシュデバイスに記憶されているときに電子デバイスにおける第1のメディアアセットの利用可能性を示す信号を送信する。

【0178】

幾つかの例では、クライアントインタフェースは、サーバデバイスから、デバイス属性及びリソース状態を取得する要求を受信する。クライアントインタフェースは、電子デバイスの属性及びシーンベースの没入型メディアを処理するためのリソース利用可能性について、電子デバイスの1つ以上の内部構成要素及び／又は電子デバイスに関連付けられた1つ以上の外部構成要素に問い合わせる。クライアントインタフェースは、電子デバイスの属性及び電子デバイスのリソース利用可能性など、電子デバイスの内部構成要素及び電子デバイスに関連する外部構成要素から受信した情報をサーバデバイスに送信することができる。

【0179】

幾つかの例では、電子デバイスは、ユーザインタフェースからシーンベースの没入型メディアの要求を受信し、クライアントインタフェースは、シーンベースの没入型メディアの要求をサーバデバイスに転送する。

【0180】

幾つかの例では、シーンベースの没入型メディアを再生するために、クライアントインタフェースの制御下で、メディアストリームのデコーディング及びメディア再構成に基づいて再構成されたシーンベースの没入型メディアが生成される。次いで、再構成されたシーンベースの没入型メディアは、電子デバイスのゲームエンジンのアプリケーションプログラミングインタフェース（API）を介して、再生のためにゲームエンジンに提供される。

【0181】

幾つかの他の例では、クライアントインタフェースは、メディアストリームをデパケット化して、デパケット化されたメディアデータを生成する。デパケット化されたメディアデータは、電子デバイスのゲームエンジンのアプリケーションプログラミングインタフェース（API）を介してゲームエンジンに提供される。次いで、ゲームエンジンは、デパケット化されたメディアデータに基づいて再生するための再構成されたシーンベースの没入型メディアを生成する。

【0182】

そして、プロセス2600は、S2699に進み、終了する。

【0183】

プロセス2600は、様々なシナリオに適切に適応させることができ、それに応じてプロセス2600内のステップを調整することができる。プロセス2600内のステップのうちの1つ以上を、適応、省略、繰り返し、及び／又は組み合わせることができる。プロセス2600を実施するために、任意の適切な順序を使用することができる。更なるステップを追加することができる。

【0184】

図27は、本開示の一実施形態によるプロセス2700の概要を示すフローチャートを示す。プロセス2700は、ネットワーク内のサーバデバイスなどのネットワーク内で実行することができる。幾つかの実施形態では、プロセス2700はソフトウェア命令で実施され、したがって、処理回路がソフトウェア命令を実行すると、処理回路はプロセス2700を行う。プロセスは、S2701で開始し、S2710に進む。

【0185】

S2710において、サーバデバイスは、電子デバイスのクライアントインタフェースから、電子デバイスでシーンベースの没入型メディアを再生するための能力及び利用可能性の情報を受信する。

【0186】

S2720において、サーバデバイスは、電子デバイスにおける能力及び利用可能性の情報に基づいて、電子デバイス用のシーンベースの没入型メディアの適応したメディアコンテンツを生成する。

【0187】

S2730において、サーバデバイスは、適応したメディアコンテンツを搬送するメディアストリームを電子デバイスに送信する（例えば、電子デバイスのクライアントインタフェース）。

【0188】

幾つかの例では、サーバデバイスは、第1のシーン内の第1のメディアアセットが以前に電子デバイスにストリーミングされたと決定し、第1のシーン内の第1のメディアアセットを、第1のメディアアセットを示すプロキシと置き換える。

【0189】

幾つかの例では、サーバデバイスは、各シーンの固有のアセットのリストを抽出する。

【0190】

幾つかの例では、サーバデバイスは、電子デバイスでの第1のメディアアセットの利用可能性を示す信号を受信する。一例では、信号はクライアントデバイスのクライアントインタフェースから送信される。次いで、サーバデバイスは、第1のシーン内の第1のメディアアセットを、第1のメディアアセットを示すプロキシと置き換える。

【0191】

幾つかの例では、サーバデバイスは、第1のメディアアセットのための問合せ信号をクライアントデバイスに送信し、問合せ信号に応答して、電子デバイスにおける第1のメディアアセットの利用可能性を示す信号を受信する。

【0192】

幾つかの例では、サーバデバイスは、デバイス属性及びリソース状態を取得する要求を送信し、次いで、電子デバイスの属性並びに能力及び利用可能性の情報を受信する。

【0193】

そして、プロセス2700は、S2799に進み、終了する。

【0194】

プロセス2700は、様々なシナリオに適切に適応させることができ、それに応じてプロセス2700内のステップを調整することができる。プロセス2700内のステップのうちの1つ以上を、適応、省略、繰り返し、及び／又は組み合わせることができる。プロセス2700を実施するために、任意の適切な順序を使用することができる。更なるステップを追加することができる。

【0195】

本開示の第2の態様によれば、本開示に開示された様々な技術は、コンテンツ制作者提供の視覚アセットの代わりにユーザ提供の視覚アセットを置き換えることにより、エンドユーザへのよりパーソナライズされたメディア体験のプレゼンテーションを可能にするシーンベースの没入型メディアのストリーミングに使用される。幾つかの例では、クライアントデバイス内のスマートクライアントは、幾つかの技術で実装され、スマートクライアントは、1つ以上のプロセスによって具現化することができ、1つ以上の通信チャネルは、クライアントデバイスプロセスとネットワークサーバプロセスとの間に実装される。幾つかの例では、没入型メディアストリーム内のメタデータは、ユーザ提供の視覚アセットとの交換に適した視覚アセットの利用可能性をシグナリングすることができる。クライアントデバイスは、ユーザ提供のアセットのリポジトリにアクセスすることができ、そのようなアセットのそれぞれは、置換プロセスを支援するためにメタデータで注釈付けされる。クライアントデバイスは、ネットワーク内のサーバデバイスからストリーミングされたシーンベースのメディアプレゼンテーションへのその後の置換のために、アクセス可能なキャッシュ（ユーザ提供メディアキャッシュとも呼ばれる）へのユーザ提供の視覚アセットのロードを可能にするために、エンドユーザインタフェースを更に使用することができる。

【0196】

本開示の第3の態様によれば、本開示に開示された様々な技術は、コンテンツ制作者提供の（「システム」としても知られる）非視覚アセットの代わりにユーザ提供の非視覚アセット（例えば、オーディオ、体性感覚、嗅覚）を置換することにより、エンドユーザに対してよりパーソナライズされたメディア体験のプレゼンテーションを可能にするシーンベースの没入型メディアのストリーミングに使用される。幾つかの例では、クライアントデバイス内のスマートクライアントは、幾つかの技術で実装され、スマートクライアントは、1つ以上のプロセスによって具現化することができ、1つ以上の通信チャネルは、クライアントデバイスプロセスとネットワークサーバプロセスとの間に実装される。幾つかの例では、没入型メディアストリーム内のメタデータは、ユーザ提供の非視覚アセットとの交換に適した非視覚アセットの利用可能性をシグナリングするために使用される。幾つかの例では、スマートクライアントは、ユーザ提供のアセットのリポジトリにアクセスすることができ、そのようなアセットのそれぞれは、置換プロセスを支援するためにメタデータで注釈付けされる。クライアントデバイスは、ネットワークサーバからストリーミングされたシーンベースのメディアプレゼンテーションへのその後の置換のために、ユーザ提供の非視覚アセットをクライアントアクセス可能なユーザ提供メディアキャッシュにロードすることを可能にするために、エンドユーザインタフェースを更に使用することができる。

【0197】

図28は、幾つかの例における視覚アセットの置換のシグナリングを伴うタイムドメディア表示2810の図を示す。タイムドメディア表示2810は、シーン2811のリストの情報を含むタイムドシーンマニフェスト2810Aを含む。シーン2811は、シーン2811内の処理情報及びメディアアセットのタイプを別々に記述する構成要素2812のリストを指す。構成要素2812は、ベース層2814及び属性強化層2815を更に示すアセット2813を指す。視覚アセットのベース層2814には、対応するアセットがユーザ提供のアセット（図示せず）で置換される候補であるか否かを示すためのメタデータが供給される。他のシーン2811（例えば、前のシーン）で以前に使用されたことのないアセットのリスト2817が各シーン2811に提供される。

【0198】

図28の例では、視覚アセット1のベース層は、視覚アセット1が置換可能であることを示し、視覚アセット2のベース層は、視覚アセット2が置換可能であることを示し、視覚アセット3のベース層は、視覚アセット3が置換不可能であることを示す。

【0199】

図29は、幾つかの例における視覚アセットの置換のシグナリングを伴う非タイムドメディア表示2910の図を示す。幾つかの例では、非タイムドシーンマニフェスト（図示せず）は、シーン1．0に分岐することができる他のシーンがないシーン1．0を参照する。図29のシーン情報2911には、クロックに応じた開始時間と終了時間とが対応付けられていない。シーン情報2911は、シーンの処理情報及びメディアアセットのタイプを別々に記述する構成要素2912のリストを指す。構成要素2912は、ベース層2914並びに属性強化層2915及び2916を更に指すアセット2913を指す。「視覚的」タイプのアセット2913には、対応するアセットがユーザ提供のアセット（図示せず）で置換される候補であるか否かを示すためのメタデータが更にプロビジョニングされる。更に、シーン情報2911は、非タイムドメディアのための他のシーン情報2911を参照することができる。シーン情報2911は、タイムドメディアシーンのためのシーン情報2917を参照することもできる。リスト2918は、高次（例えば、親）シーンで以前に使用されたことがない特定のシーンに関連付けられた固有のアセットを識別する。

【0200】

図30は、幾つかの例における非視覚アセットにおける置換のシグナリングを伴うタイムドメディア表示3010の図を示す。タイムドメディア表示3010は、シーン3011のリストの情報を含むタイムドシーンマニフェスト3010Aを含む。シーン3011の情報は、シーン3011内の処理情報及びメディアアセットのタイプを別々に記述する構成要素3012のリストを指す。構成要素3012は、ベース層3014及び属性強化層3015を更に示すアセット3013を指す。非視覚アセットのベース層3014には、対応するアセットがユーザ提供アセット（図示せず）で置換される候補であるか否かを示すためのメタデータが供給される。他のシーン3011で以前に使用されたことがないアセットのリスト3017は、各シーン3011に提供される。

【0201】

図31は、幾つかの例における非視覚アセットの置換のシグナリングを伴う非タイムドメディア表示3110の図を示す。非タイムドシーンマニフェスト（図示せず）は、シーン1．0に分岐することができる他のシーンがないシーン1．0を参照する。シーン3111の情報は、クロックによる開始及び終了継続時間と関連付けられていない。シーン3111の情報は、シーン内の処理情報及びメディアアセットのタイプを別々に記述する構成要素3112のリストを指す。構成要素3112は、ベース層3114並びに属性強化層3115及び3116を更に指すアセット3113を指す。「視覚的」タイプではないアセット3113には、対応するアセットがユーザ提供のアセット（図示せず）によって置換される候補であるか、又は候補ではないことを示すためのメタデータが更にプロビジョニングされる。更に、シーン3111の情報は、非タイムドメディアのための他のシーン情報3111を参照することができる。シーン3111の情報は、タイムドメディアシーンのためのシーン情報3117を参照することもできる。リスト3118は、高次（例えば、親）シーンで以前に使用されたことがない特定のシーンに関連付けられた固有のアセットを識別する。

【0202】

図32は、本開示の幾つかの実施形態にかかるクライアントデバイスにおいてユーザ提供のアセットでアセット置換を行うためのプロセス（置換論理とも呼ばれる）3200を示している。幾つかの例では、プロセス3200は、クライアントデバイス内のスマートクライアントによって実行することができる。プロセスステップ3201から開始して、アセット内のメタデータを調べて、問題のアセットが置換される候補であるかどうかを決定する。アセットが置換の候補でない場合、プロセスはプロセスステップ3207でアセット（例えば、コンテンツプロバイダによって提供される）で継続する。そうではなく、アセットが置換の候補である場合、意思決定ステップ3202が実行される。クライアントデバイスが、ユーザ提供のアセットを記憶する能力を備えていない場合（例えば、図14にメディアキャッシュ1415として示されている）、プロセスは、プロセスステップ3207においてコンテンツプロバイダによって提供されるアセットを用いて継続する。そうではなく、クライアントデバイスがユーザ提供のアセットキャッシュでプロビジョニングされている場合（例えば、図14のユーザ提供メディアキャッシュ1416）、プロセスはプロセスステップ3203で継続する。プロセスステップ3203は、コンテンツプロバイダによって提供されるアセットの代わりに適切なユーザ提供アセットを取り出すために、アセットキャッシュ（例えば、図14のユーザ提供メディアキャッシュ1415）の問合せを構築する。意思決定ステップ3204は、適切なユーザ提供アセットを使用できるかどうかを決定する。適切なユーザ提供アセットが利用可能である場合、プロセスはプロセスステップ3205に続き、コンテンツプロバイダによって提供されるアセットへの参照は、メディア内のユーザ提供アセットへの参照に置き換えられる。その後、プロセスは、置換論理3200の終わりを示すプロセスステップ3206に続く。適切なユーザ提供のアセットがアセットキャッシュから利用できない場合（例えば、図14のユーザ提供メディアキャッシュ1416）、プロセスは、プロセスステップ3207でコンテンツプロバイダによって提供されるアセットで継続する、すなわち、置換は行われない。プロセスステップ3207から、プロセスは、置換論理3200の終了を示すプロセスステップ3206に続く。

【0203】

幾つかの例では、プロセス3200は視覚アセットに適用される。一例では、人は、より良い体験のために、メディア内のキャラクタの視覚アセットを人の視覚的外観に置き換えたい場合がある。別の例では、人は、シーン内の建物の視覚的アッセイを実際の建物の視覚的外観の視覚的外観に置き換えたい場合がある。幾つかの例では、プロセス3200は非視覚アセットに適用される。一例では、視覚障害を有する人の場合、その人は、コンテンツプロバイダから提供されるハプティクスアセットを置き換えるようにカスタマイズされたハプティクスアセットを有することができる。別の例では、アクセントを有する領域からの人の場合、人は、コンテンツプロバイダから提供されるオーディオアセットを置き換えるために、アクセントを有するオーディオアセットを有することができる。

【0204】

図33は、本開示の幾つかの実施形態にかかるクライアントデバイスにおいてユーザ提供メディアキャッシュをポピュレートするためのプロセス（ポピュレーティング論理とも呼ばれる）3300を示している。プロセスはプロセスステップ3301で開始し、クライアントデバイス（例えば、図14のクライアントデバイス1418）の表示パネルは、アセットをキャッシュ（例えば、図14のユーザ提供メディアキャッシュ1416）にロードするオプションをユーザに提示する。次いで、意思決定ステップ3302が実行されて、ユーザがクライアントデバイスに（例えば、図14のユーザ提供メディア記憶装置1419などの外部記憶装置から）ロードするアセットが更にあるかどうかを決定する。ユーザがクライアントデバイスにロードするためのより多くのアセットを有する場合、プロセスは意思決定ステップ3303に進む。ユーザがクライアントデバイスにロードする（それ以上の）アセットを有していない場合、プロセスはプロセスステップ3306に進む。プロセスステップ3306は、ポピュレーティング論理3300の終わりを示す。意思決定ステップ3303は、ユーザ提供のアセットを記憶するのに十分な記憶装置がクライアントデバイス（例えば、図14のユーザ提供メディアキャッシュ1416）にあるかどうかを決定する。クライアントデバイスに十分な記憶装置がある場合（例えば、図14のユーザ提供メディアキャッシュ1416）、プロセスはプロセスステップ3304に進む。ユーザ提供のアセットを記憶するのに十分な記憶装置がない場合、プロセスはプロセスステップ3305に進む。プロセスステップ3305は、クライアントデバイスがユーザのアセットを記憶するのに十分な記憶装置を有していないことをユーザに通知するメッセージを発行する。メッセージがプロセスステップ3305で発行されると、プロセスはプロセスステップ3306に進み、プロセスステップは、ポピュレーティング論理3300の終了を示す。アセットに十分な記憶装置がある場合、プロセスステップ3304は、ユーザのアセットをクライアントデバイスにコピーする（例えば、図14のユーザ提供メディアキャッシュ1416）。プロセスステップ3304でアセットがコピーされると、プロセスはステップ3302に戻り、ユーザがクライアントデバイスにロードするアセットが更にあるかどうかを問い合わせる。

【0205】

幾つかの例では、プロセス3300は、視覚アセット（例えば、ユーザ提供の視覚アセット）に適用される。幾つかの例では、プロセス3300は、非視覚アセット（例えば、ユーザ提供の非視覚アセット）に適用される。

【0206】

図34は、本開示の一実施形態によるプロセス3400の概要を示すフローチャートを示す。プロセス3400は、クライアントデバイスをネットワークとインタフェース接続するためのスマートクライアントを有するクライアントデバイスなどの電子デバイスで実行することができる。幾つかの実施形態では、プロセス3400はソフトウェア命令で実施され、したがって、処理回路がソフトウェア命令を実行すると、処理回路はプロセス3400を行う。例えば、スマートクライアントはソフトウェア命令で実装され、ソフトウェア命令は、プロセス3400を含むスマートクライアントプロセスを行うために実行されることができる。プロセスは、S3401から開始し、S3410に進む。

【0207】

S3410において、シーンベースの没入型メディアを搬送するメディアストリームが受信される。シーンベースの没入型メディアはシーンと関連付けられた複数のメディアアセットを含む。

【0208】

S3420において、複数のメディアアセットの中の第1のメディアアセットが置換可能であると決定される。

【0209】

S3430で、第2のメディアアセットを第1のメディアアセットの代わりに使用して、更新されたシーンベースの没入型メディアを生成する。

【0210】

幾つかの例では、第1のメディアアセットのベース層のメタデータは、第1のメディアアセットが置換可能であることを示すことができる。一例では、第1のメディアアセットはタイムドメディアアセットである。別の例では、第1のメディアアセットは、非タイムドメディアアセットである。

【0211】

幾つかの例では、第1のメディアアセットは視覚アセットである。幾つかの例では、第1のメディアアセットは、オーディオアセット、触覚アセットなどの非視覚アセットである。

【0212】

幾つかの例では、クライアントデバイスの記憶デバイス（例えば、キャッシュ）にアクセスして、第1のメディアアセットに対応する第2のメディアアセットがクライアントデバイスで利用可能であるかどうかを決定する。一例では、スマートクライアントは、第1のメディアアセットに対応する第2のメディアアセットが利用可能かどうかをたずねる問合せを作成する。

【0213】

幾つかの例では、クライアントデバイスは、ユーザ提供のメディアアセットを記憶デバイスにロードするためのポピュレーティングプロセスを行うことができる。例えば、クライアントデバイスは、ユーザインタフェースを介して第2のメディアアセットをキャッシュにロードすることができる。幾つかの例では、第2のメディアアセットはユーザ提供のメディアアセットである。

【0214】

そして、プロセス3400は、S3499に進み、終了する。

【0215】

プロセス3400は、様々なシナリオに適切に適応させることができ、それに応じてプロセス3400内のステップを調整することができる。プロセス3400内のステップのうちの1つ以上を、適応、省略、繰り返し、及び／又は組み合わせることができる。プロセス3400を実施するために、任意の適切な順序を使用することができる。更なるステップを追加することができる。

【0216】

スマートクライアント構成要素（例えば、スマートクライアントプロセス、ソフトウェア命令など）は、シーンベースのメディアをクライアントデバイス（例えば、没入型クライアントデバイス）にストリーミングするように設計された配信ネットワーク内のクライアントデバイスに代わって、ストリーミングされたメディアの受信及び処理を管理することができることに留意されたい。スマートクライアントは、クライアントデバイスに代わって、1）配信ネットワークからのメディアリソースの要求、2）クライアントの好ましいメディアフォーマットを記述する属性を含む、クライアントデバイスリソースの現在の状態又は構成に関する報告、3）以前に変換され、クライアントデバイスに適したフォーマットで記憶され得る、すなわち、別の同様の又は同じクライアントデバイスによって以前に処理され、その後の再利用のためにデータストレージにキャッシュされているメディアにアクセスすること、4）システム提供のメディアアセットの代わりにユーザ提供のメディアアセットを置換することを含む多くの機能を行うように構成することができる。更に、幾つかの例では、クライアントデバイス内のスマートクライアントと同様の機能を行うためにネットワークデバイスに幾つかの技術を実装することができるが、没入シーンベースのメディアを複数の異種クライアントデバイスに配信するネットワークの有効性に寄与するためにフォーマットAからフォーマットBへのメディアの適応に焦点を合わせるように調整することができる。幾つかの例では、これらの技術は、ネットワークデバイスにソフトウェア命令として組み込むことができ、ソフトウェア命令は、ネットワークデバイスの処理回路によって実行されることができ、ソフトウェア命令又はソフトウェア命令に従って処理回路によって行われるプロセスは、メディアが特定のクライアントデバイスへの配信に利用可能になる前に、インジェストメディアをクライアント固有のフォーマットに適応させるためのリソースをスマートコントローラが設定、開始、管理、終了、及び破棄するという意味で、スマートコントローラと呼ぶことができる。

【0217】

本開示の第4の態様によれば、本開示に開示された様々な技術は、クライアントデバイスに代わってメディアをクライアント固有のフォーマットに変換するネットワークに代わってメディアの適応を管理することができる。幾つかの例では、ネットワークサーバデバイス内のスマートコントローラは、幾つかの技術に従って実装され、スマートコントローラは、スマートコントローラプロセスとネットワークプロセスとの間に実装された1つ以上の通信チャネルを有する1つ以上のプロセスによって具現化されてもよい。幾つかの例では、幾つかの技法は、メディアの変換プロセスの意図された結果を十分に記述するためのメタデータを含む。幾つかの例では、幾つかの技法は、以前に変換されたメディアを含み得るメディアキャッシュへのアクセスを提供することができる。幾つかの例では、幾つかの技法は、1つ以上のレンダラプロセッサへのアクセスを提供することができる。幾つかの例では、幾つかの技法は、十分なGPU及び／又はCPUプロセッサへのアクセスを提供することができる。幾つかの例では、幾つかの技術は、得られた変換メディアを記憶するのに十分な記憶デバイスへのアクセスを提供することができる。

【0218】

図35は、幾つかの例におけるネットワークベースのメディア変換を行うためのプロセス3510を示す。ネットワークベースのメディア変換は、ネットワークサーバデバイス内のスマートコントローラなどによって、クライアントデバイスの情報に基づいて、ネットワーク内で行われる。クライアントデバイスの情報は、幾つかの例では、クライアントデバイス内のスマートクライアントから提供される。

【0219】

具体的には、図35において、プロセスステップ3511において、クライアントデバイスによって要求されたメディアがネットワークにインジェストされる。次に、プロセスステップ3515において、ネットワークは、クライアントデバイスのデバイス属性及びリソース状態を取得する。例えば、ネットワークは、デバイス属性及びリソース状態を取得するために、（例えば、プロセスステップ3512に示すように）スマートクライアントへの要求を開始する。プロセスステップ3512において、スマートクライアントは、クライアントデバイスに関する記述属性及び将来の作業を処理するためのリソース利用可能性を含むクライアントデバイスのリソースに関する情報をそれぞれ取り出すために、クライアントデバイス3513及び追加のリソース（存在する場合）3514に対する問合せを開始する。クライアントデバイス3513は、クライアントデバイスの処理能力を記述するクライアントデバイス属性を配信する。クライアントデバイス上のリソースの状態及び利用可能性は、追加のリソース3514からスマートクライアントに返される。次に、スマートクライアントは、プロセスステップ3515に示すように、クライアントデバイス上のリソースの状態及び利用可能性をネットワークに提供する。プロセスステップ3516において、ネットワークは、次に、例えばクライアントデバイス上のリソースの状態及び利用可能性に基づいて、メディアがクライアントデバイスにストリーミングされる前にネットワークがメディアを変換する必要があるかどうかを決定する。そのような変換が必要とされる場合、例えば、クライアントデバイスがバッテリによって電力供給され、処理能力を欠いている場合、スマートコントローラ3517は変換を行う。スマートコントローラ3517は、変換を支援するために、レンダラ3517A、GPU3517B、メディアキャッシュ3517C、及びニューラルネットワークプロセッサ3517Dを利用することができる。次いで、変換されたメディア3519は、変換されたメディアをクライアントデバイスにストリーミングされるべきメディアにマージするためにプロセスステップ3518に提供される。プロセスステップ3516において、ネットワークがメディアのそのような変換を行わないように決定がなされる場合、例えば、クライアントデバイスが十分な処理能力を有する場合、プロセスステップ3518は、クライアントデバイスにストリーミングされる元のメディアアセットを有するメディアを準備する。プロセスステップ3518に続いて、メディアは、プロセスステップ3520においてクライアントにストリーミングされる。

【0220】

図36は、ネットワーク内のスマートコントローラにおいてネットワークベースのメディア適応を行うプロセス3600を示す。プロセスステップ3601は、メディアの適応を行うためにリソースをインスタンス化及び／又は初期化する。そのようなリソースは、例えば、メディアを同じメディアの非圧縮表示に戻すなど、メディアを元の状態に戻すためにレンダラ及び／又はデコーダのインスタンスを管理するための別個の計算スレッドを含むことができる。意思決定プロセスステップ3602は、メディアが最初に再構成及び／又は解凍プロセスを受ける必要があるかどうかを決定する。メディアがクライアントデバイスへの配信のために適応される前に最初に再構成及び／又は解凍される必要がある場合、プロセスステップ3603は、メディアを再構成及び／又は解凍するタスクを行う。再構成及び／又は解凍されたメディアは、チャネルを介してスマートコントローラに返される。次に、プロセスステップ3604において、スマートコントローラは、クライアントフレンドリーなフォーマットにメディアを適応させるのを支援するために、クライアントデバイスに代わってネットワークに提供又は記憶されるニューラルネットワーク及び場合によってはニューラルネットワークモデル（図示せず）を使用してメディアを更に洗練させるべきかどうかを決定する。スマートコントローラが、ニューラルネットワークの適用を行う必要があると決定した場合、プロセスステップ3606において、ニューラルネットワークプロセッサは、ニューラルネットワークモデルをメディアに適用することができる。ニューラルネットワーク処理から得られたメディアは、チャネルを介してスマートコントローラに戻される。プロセスステップ3604において、ニューラルネットワークプロセッサを使用してメディアを改良する必要がない場合、ニューラルネットワーク処理はスキップされる。プロセスステップ3608において、スマートコントローラは、メディア（例えば、ニューラルネットワーク処理から再構成及び／又は解凍されたメディア又は結果として生じるメディア）を特定のクライアントデバイスに適したフォーマットに変換する。そのような変換プロセスは、レンダラツール、3Dモデリングツール、ビデオデコーダ及び／又はビデオエンコーダを使用することができる。プロセスステップ3608によって行われる処理は、クライアントデバイスによってアセットをレンダリングするための計算の複雑さがクライアントデバイスの計算能力の能力と一致するように、特定のアセットのポリゴンカウントを減らすことを含むことができる。例えば、特定のアセットを異なるテクスチャ解像度に置き換えることを含む他の要因も、変換プロセスステップ3608の一部として対処することができる。例えば、特定のメッシュベースのアセットのUVテクスチャを特定の解像度で、例えば超高解像度（UHD）ではなく高解像度（HD）で提供する必要がある場合、変換プロセス3608はまた、メッシュアセットのUVテクスチャのHD表示を作成できる。別の例は、一般的なネットワークメディア内の特定のアセットが特定の3Dフォーマットの仕様、例えば、FBX、glTF、OBJに従って記述され、クライアントデバイスがその特定のフォーマット仕様に従って表示されるメディアをインジェストすることができない場合、変換プロセス3608は、メディアアセットをクライアントデバイスによってインジェストすることができるフォーマットに変換するために3Dツールを用いることができる。変換プロセス3608の完了に続いて、メディアは、クライアントデバイス（図示せず）によるその後のアクセスのためにクライアント適応メディアキャッシュ3609に記憶される。必要に応じて、スマートコントローラは、次に、スマートコントローラのために3601で以前に割り当てられた計算及びストレージリソースの破棄又は割り当て解除プロセス3610を行う。

【0221】

図37は、本開示の一実施形態によるプロセス3700の概要を示すフローチャートを示す。プロセス3700は、ネットワーク内のサーバデバイスなどのネットワーク内で実行することができる。幾つかの実施形態では、プロセス3700はソフトウェア命令で実施され、したがって、処理回路がソフトウェア命令を実行すると、処理回路はプロセス3700を行う。例えば、プロセス3700は、スマートコントローラ内のソフトウェア命令として実装され、処理回路は、スマートコントローラプロセスを行うためにソフトウェア命令を実行することができる。プロセスは、S3701から開始し、S3710に進む。

【0222】

S3710において、サーバデバイスは、クライアントデバイスの能力情報に基づいて第1のメディアフォーマットを決定する。第1のメディアフォーマットは、能力情報を有するクライアントデバイスによって処理可能である。

【0223】

S3720において、サーバデバイスは、第2のメディアフォーマットのメディアを第1のメディアフォーマットの適応メディアに変換する。幾つかの例では、メディアはシーンベースの没入型メディアである。

【0224】

S3730において、第1のメディアフォーマットの適応メディアがクライアントデバイスに提供される（例えば、ストリーミング）。

【0225】

幾つかの例では、スマートコントローラは、レンダリング、ビデオデコーダ、ビデオエンコーダ、ニューラルネットワークモデルなどを含むことができる。幾つかの例では、第2のメディアフォーマットは、ネットワークのインジェストメディアフォーマットである。スマートコントローラは、ネットワークのインジェストメディアフォーマットのメディアを中間メディアフォーマットに変換し、次いで、メディアをインターメディアメディアフォーマットから第1のメディアフォーマットに変換することができる。幾つかの例では、スマートコントローラは、インジェストメディアフォーマットのメディアをデコーディングし、再構成されたメディアを生成することができ、次いで、スマートコントローラは、再構成されたメディアを第1のメディアフォーマットのメディアに変換することができる。

【0226】

幾つかの例では、スマートコントローラは、ニューラルネットワークプロセッサに、再構成されたメディアにニューラルネットワークモデルを適用させて再構成されたメディアを改良させ、次いで改良されたメディアを第1のメディアフォーマットのメディアに変換させることができる。

【0227】

幾つかの例では、第2のメディアフォーマットのメディアは、ネットワーク伝送及び記憶のための汎用メディアタイプである。

【0228】

幾つかの例では、クライアントデバイスの能力情報は、クライアントデバイスによる計算の能力及びクライアントデバイスのアクセス可能な記憶リソースの能力のうちの少なくとも1つを含む。

【0229】

幾つかの例では、スマートコントローラは、要求メッセージをクライアントデバイスに送信させることができ、要求メッセージはクライアントデバイスの能力を要求する。次いで、スマートコントローラは、クライアントデバイスの能力情報を有する応答を受信することができる。

【0230】

そして、プロセス3700は、S3799に進み、終了する。

【0231】

プロセス3700は、様々なシナリオに適切に適応させることができ、それに応じてプロセス3700内のステップを調整することができる。プロセス3700内のステップのうちの1つ以上を、適応、省略、繰り返し、及び／又は組み合わせることができる。プロセス3700を実施するために、任意の適切な順序を使用することができる。更なるステップを追加することができる。

【0232】

本開示の第5の態様によれば、様々な技術を使用して、クライアントデバイスがインジェストすることができるメディアに関してクライアントデバイスの能力を特徴付けることができる。幾つかの例では、キャラクタライゼーションは、シーンベースの没入型メディアアセットタイプ、アセットタイプごとの詳細レベル、アセットタイプごとのバイト単位の最大サイズ、アセットタイプごとのポリゴンの最大数、並びにクライアントデバイスがネットワークから直接インジェストすることができるメディアのタイプ及びそのメディアの特性を記述する他のパラメータの記述を伝えるのに役立つクライアントメディアプロファイルによって表すことができる。次いで、クライアントデバイスからクライアントメディアプロファイルを受信するネットワークは、インジェストされたメディアをクライアントデバイスによって配信及び／又はアクセスされるように準備するという点で、より効率的に動作することができる。

【0233】

図38は、幾つかの例におけるクライアントメディアプロファイル3810の図を示す。図38の例では、クライアントデバイスによってサポートされるメディアフォーマット、メディアコンテナ、及びメディアに関する他の属性に関する情報は、ネットワークに均一に（すなわち、図38に示されていない仕様に従って）伝達される。

【0234】

例えば、クライアントデバイスがサポートすることができるメディアフォーマットのタイプは、リスト3811として示されている。データ要素3812は、クライアントデバイスがサポートすることができる最大ポリゴンカウントを伝達する。データ要素3813は、クライアントデバイスが物理ベースのレンダリングをサポートするか否かを示す。リスト3814は、クライアントデバイスがサポートするアセットメディアコンテナを識別する。リスト3815は、クライアントデバイスのメディアプリファレンスを特徴付けるために完全なメディアプロファイルを含むことができる他のメディア関連項目があることを示している。開示された主題は、ソースプロセスとシンクプロセスとの間の高精細マルチメディアインタフェースのための仕様を介して交換される情報（サポートされている色フォーマット、色深度、ビデオ、及びオーディオフォーマットを含む）に起因する没入型メディアシーンに基づくメディアと見なすことができる。

【0235】

図39は、本開示の一実施形態によるプロセス3900の概要を示すフローチャートを示す。プロセス3900は、クライアントデバイスをネットワークとインタフェース接続するためのスマートクライアントを有するクライアントデバイスなどの電子デバイスで実行することができる。幾つかの実施形態では、プロセス3900はソフトウェア命令で実施され、したがって、処理回路がソフトウェア命令を実行すると、処理回路はプロセス3900を行う。プロセスは、S3901から開始し、S3910に進む。

【0236】

S3910において、クライアントデバイスは、メディア（例えば、シーンベースの没入型メディア）をクライアントデバイスにストリーミングするネットワークから要求メッセージを受信し、要求メッセージはクライアントデバイスの能力情報を要求する。

【0237】

S3920において、クライアントデバイスは、クライアントデバイスによって処理可能な1つ以上のメディアフォーマットを示すメディアプロファイルを生成する。

【0238】

S3930において、クライアントデバイスは、メディアプロファイルをネットワークに送信する。

【0239】

幾つかの例では、メディアプロファイルは、図38の3811に示すように、クライアントデバイスによってサポートされるシーンベースのメディアの1つ以上のタイプを定義する。

【0240】

幾つかの例では、メディアプロファイルは、図38の3812、3813、3814によって示されるように、クライアントデバイスの処理能力と一致する方法でメディアの特定のバリエーションをサポートするためにクライアントデバイスの能力を特徴付けるメディアパラメータのリストを含む。

【0241】

そして、プロセス3900は、S3999に進み、終了する。

【0242】

プロセス3900は、様々なシナリオに適切に適応させることができ、それに応じてプロセス3900内のステップを調整することができる。プロセス3900内のステップのうちの1つ以上を、適応、省略、繰り返し、及び／又は組み合わせることができる。プロセス3900を実施するために、任意の適切な順序を使用することができる。更なるステップを追加することができる。

【0243】

図40は、本開示の一実施形態によるプロセス4000の概要を示すフローチャートを示す。プロセス4000は、ネットワーク内のサーバデバイスなどのネットワーク内で実行することができる。幾つかの実施形態では、プロセス4000はソフトウェア命令で実施され、したがって、処理回路がソフトウェア命令を実行すると、処理回路はプロセス4000を行う。プロセスは、S4001から開始し、S4010に進む。

【0244】

S4010において、第1のメディアフォーマットは、クライアントデバイスによって処理可能な1つ以上のメディアフォーマットを示すクライアントのメディアプロファイルに基づいて、例えばサーバデバイスによって決定される。例えば、クライアントメディアプロファイルは、図38のクライアントメディアプロファイル3810とすることができる。

【0245】

S4020において、第2のメディアフォーマットのメディアは、第1のメディアフォーマットの適応メディアに変換される。幾つかの例では、メディアは、ネットワークのインジェストメディアフォーマットのシーンベースの没入型メディアである。サーバデバイスは、ネットワークのインジェストメディアフォーマットのメディアを、クライアントデバイスによって処理可能な第1のメディアフォーマットに変換することができる。

【0246】

S4030において、第1のメディアフォーマットの適応メディアがクライアントデバイスに提供される（例えば、ストリーミング）。

【0247】

幾つかの例では、メディアプロファイルは、図38の3811に示すように、クライアントデバイスによってサポートされるシーンベースのメディアの1つ以上のタイプを定義する。

【0248】

幾つかの例では、メディアプロファイルは、図38の3812、3813、3814によって示されるように、クライアントデバイスの処理能力と一致する方法でメディアの特定のバリエーションをサポートするためにクライアントデバイスの能力を特徴付けるメディアパラメータのリストを含む。

【0249】

そして、プロセス4000は、S4099に進み、終了する。

【0250】

プロセス4000は、様々なシナリオに適切に適応させることができ、それに応じてプロセス4000におけるステップを調整することができる。プロセス4000におけるステップのうちの1つ以上を、適応、省略、繰り返し、及び／又は組み合わせることができる。プロセス4000を実施するために、任意の適切な順序を使用することができる。更なるステップを追加することができる。

【0251】

本開示は幾つかの例示的な実施形態を説明しているが、本開示の範囲内に入る変更例、置換例、及び様々な代替の均等物が存在する。したがって、当業者は、本明細書に明示的に示されていないか又は記載されていないが、本開示の原理を具現化し、したがって本開示の趣旨及び範囲内にある多数のシステム及び方法を考案することができることが理解されよう。

【符号の説明】

【0252】

100 メディアフロープロセス、104 ネットワーク、クラウド又はエッジデバイス、105 ネットワーク接続、106 レンダリングプロセス、レンダリング機能、108 クライアントデバイス、200 メディア変換意思決定プロセス、201 メディア、202 プロセスステップ、203 意思決定プロセスステップ、204 プロセスステップ、205 メディア、206 準備プロセス、207 プロセスステップ、300 ストリーミング可能フォーマット、タイムドメディア表示、300A タイムドシーンマニフェスト、301 シーン情報、302 構成要素、303 アセット、304 ベース層、305 属性強化層、306 プロキシ視覚アセット、307 固有のアセットのリスト、308 プロキシオーディオアセット、400 ストリーミング可能フォーマット、401 シーン情報、402 構成要素、403 アセット、404 ベース層、405 属性強化層、406 属性強化層、407 シーン情報、408 リスト、500 プロセス、501 カメラユニット、502 カメラユニット、503 カメラユニット、504 合成モジュール、505 ニューラルネットワーク訓練モジュール、506 訓練画像、507 インジェストフォーマット、508 ニューラルネットワークモデル、509 自然画像コンテンツ、600 プロセス、601 LIDARカメラ、602 点群、データ、603 コンピュータ、604 CGIアセット、データ、605 行為者、605A センサ、606 モーション捕捉（MoCap）データ、607 合成モジュール、608 合成メディア、700 コンピュータシステム、701 キーボード、702 マウス、703 トラックパッド、705 ジョイスティック、706 マイク、707 スキャナ、708 カメラ、709 スピーカ、710 タッチスクリーン、720 CD／DVD ROM／RW、721 CD／DVD又は同様の媒体、722 サムドライブ、723 リムーバブルハードドライブ又はソリッドステートドライブ、740 コア、741 中央処理ユニット（CPU）、742 グラフィックス処理ユニット（GPU）、743 フィールドプログラマブルゲートエリア（FPGA）、744 ハードウェアアクセラレータ、745 読み出し専用メモリ（ROM）、746 ランダムアクセスメモリ、747 内部大容量記憶部、748 システムバス、749 周辺バス、750 グラフィックスアダプタ、754 インタフェース、755 通信ネットワーク、800 ネットワークメディア配信システム、801 コンテンツ取得モジュール、802 コンテンツ準備モジュール、803 送信モジュール、804 ゲートウェイ、805 セットトップボックス、806 無線復調器、807 レガシー2Dテレビ、808 WiFiルータ、809 レガシー2Dディスプレイ、810 ヘッドマウント2D（ラスタベース）ディスプレイ、811 ディスプレイ、811A ローカル計算GPU、811B 記憶デバイス、811C 視覚プレゼンテーションユニット、812 ホログラフィックディスプレイ、812A ローカル計算CPU、812B GPU、812C 記憶デバイス、812D 視覚化ユニット、813 モバイルハンドセット及びディスプレイ、814 拡張現実ヘッドセット、814A GPU、814B 記憶デバイス、814C バッテリ、814D 体積視覚プレゼンテーション構成要素、815 高密度光照射野ディスプレイ、815A GPU、815B CPU、815C 記憶デバイス、815D 視線追跡デバイス、815E カメラ、815F 高密度光線ベースのライトフィールドパネル、900 没入型メディア配信モジュール、901 モジュール、902 モジュール、903 記憶デバイス、904 リモート記憶デバイス、905 ネットワークオーケストレータ、906 配信メディア及び対応する記述情報、907 クライアント進捗状況及び状態フィードバックチャネル、908 没入型クライアント、908A ゲームエンジン、908A1 視覚化構成要素、908A2 物理エンジン、908B ネットワークインタフェース、908C GPU、908D ストレージ、908E スマートクライアント、908F コールバック機能、909 配信記憶デバイス、910 メディア適応及びフラグメンテーションモジュール、911 メディア再使用分析器、1000 メディア適応プロセス、1001 メディア適応及びフラグメンテーションモジュール、1001A ニューラルネットワークモデル、1001B レンダラ、1001C ニューラルネットワークプロセッサ、1001D メディア圧縮器、1001E メディア解凍器、1001F 論理コントローラ、1003 クライアントインタフェースモジュール、1004 クライアント情報、1005 入力ネットワーク状態、1006 クライアント適応メディア記憶デバイス、1007 メディア再利用分析器、1100 配信フォーマット作成プロセス、1101 メディア適応モジュール、1102 クライアント適応メディア記憶デバイス、1103 適応メディアパッケージングモジュール、1104 ロバストな配信フォーマット、1104A マニフェスト情報、1104B シーンデータアセットのリスト、1200 パケタイザプロセスシステム、1201 適応メディア、1202 パケタイザ、1203 パケット、1204 クライアントエンドポイント、1300 シーケンス図、1301 クライアント、1302 ネットワークオーケストレータ、1303 インジェストメディアサーバ、1304 適応インジェスト、1305 メディア適応モジュール、1306 パッケージングモジュール、1307 パッケージ化されたメディアサーバ、1308 メディア要求、1309 プロファイル要求、1310 応答、1311 セッションIDトークン、1312 インジェストメディアリクエスト、1313 応答、1314 呼び出し、1315 ニューラルネットワークモデルトークン、1316 要求、1317 応答、1318 要求、1319 更新、1320 ンタフェース呼び出し、1321 応答メッセージ、1322 応答、1323 要求、1324 メッセージ、1400 メディアシステム、1401 MPEGスマートクライアントプロセス、1402 クライアントメディア再構成プロセス、1403 ニューラルネットワークプロセッサ、1404 クライアント適応メディアキャッシュ、1405 ゲームエンジン、14051 制御論理、14052 GPUインタフェース、14053 物理エンジン、14054 レンダラ、14055 圧縮デコーダ、14056 デバイス固有プラグイン、1406 圧縮デコーダプロセス、1407 レンダリングされたクライアントメディアキャッシュ、1408 エッジプロセッサ又はネットワークオーケストレータデバイス、1409 クライアント適応メディア、1410 メディア分析器、1411 レンダリングされたメディアキャッシュ、1412 ユーザインタフェース、1413 触覚構成要素、1414 オーディオ構成要素、1415 視覚化構成要素、1416 ユーザ提供メディアキャッシュ、1417 ゲームエンジンAPI及びコールバック機能、1418 ゲームエンジンクライアントデバイス、1419 メディアキャッシュ、1420 ネットワークインタフェースプロトコル、1421 ニューラルネットワークモデル、1530 プロセス、1531 プロセス、1532 プロセス、1533 プロセス、1535 フォーマット、1536 メディアストリーミングプロセス、1537 メディア、1538 情報チャネル、1539 スマートクライアントプロセス、15310 レンダリングプロセス、15311 プレゼンテーションフォーマットC、15312 ゲームエンジンクライアントデバイス、1640 プロセス、1641 プロセス、1642 プロセス、1642A 配信メディア作成開始プロセス、1642B 意思決定プロセス、1642C プロセス、1642D プロセス、1642E プロセス、1643 プロセス、1645 別のフォーマット、1646 メディアストリーミングプロセス、1647 ストリーミングされたメディア、1648 スマートクライアントフィードバック及び状態、1649 スマートクライアントプロセス、16410 レンダリングプロセス、16411 プレゼンテーションフォーマットC、16412 ゲームエンジンクライアントデバイス、1645 フォーマット、1646 メディアストリーミングプロセス、1647 メディア、1648 スマートクライアントフィードバック及び状態、1649 スマートクライアントプロセス、1730 メディア変換意思決定プロセス、1731 プロセスステップ、1732 プロセスステップ、1733 プロセスステップ、1734 プロセスステップ、1735 プロセスステップ、1736 プロセスステップ、1737 プロセス、1738 プロセスステップ、1739 変換されたメディア、17310 プロセスステップ、17311 プロセスステップ、1840 ゲームエンジンクライアントプロセス、1841 プロセスステップ、1842 プロセスステップ、1843 問合せ論理、1843A プロセスステップ、1843B データベース、1844 プロセスステップ、1845 プロセスステップ、1846 プロセスステップ、1847 プロセスステップ、1848 ネットワークプロセス、1849 変換されたメディア、1950 プロセス、1951 プロセスステップ、1952 プロセス、1952A スマートクライアント、1952B クライアントデバイス、1952C 追加のリソース、1953 アセット問合せ論理、1954 プロセスステップ、1955 プロセスステップ、1956 プロセスステップ、1957 プロセスステップ、1958 プロセスステップ、1959 変換されたメディア、2043C スマートクライアントプロセス、2060 プロセス、2061 プロセスステップ、20610 スマートクライアント、20611 クライアントデバイス、20612 プロセスステップ、20613 メディアストア、2062 プロセスステップ、2063 アセット問合せ論理、2064 プロセスステップ、2065 プロセスステップ、2066 プロセスステップ、2067 プロセス、2068 プロセスステップ、2069 変換されたメディア、2103A タイムドシーンマニフェスト、2131 シーン情報、2132 構成要素、2133 アセット、2134 ベース層、2135 属性強化層、2136 プロキシ視覚アセット、2137 リスト、2138 プロキシオーディオアセット、2240 非タイムドメディア表示の図、2241 シーン情報、2242 構成要素、2243 アセット、2244 ベース層、2245 属性強化層、2246 属性強化層、2247 シーン情報、2248 リスト、2340 分布フォーマット作成プロセス、2341 メディア適応プロセス、2342 記憶デバイス、2343 メディアパッケージングプロセス、2344 配信フォーマット、2344A マニフェスト情報、2344B リスト、2400 フローチャート、2404 リスト、2500 ネットワークプロセスの図、2501 ネットワークオーケストレーションプロセス、2502 ネットワークインタフェース、2503 情報、2504 クライアントデバイス、2504A スマートクライアント、2504B 圧縮デコーダプロセス、2504C 視覚化構成要素、2504D クライアント適応メディアキャッシュ、2504E ニューラルネットワークモデル、2504F ニューラルネットワークプロセッサ、2504G ゲームエンジン、2504G1 制御論理、2504G2 物理エンジン、2504G3 レンダラプロセス、2504G5 GPUインタフェース、2504G6 圧縮デコーダ、2504H クライアントメディア再構成プロセス、2504I レンダリングされたクライアントメディアキャッシュ、2504J クライアントデバイス制御論理、2600 プロセス、2700 プロセス、2810A タイムドシーンマニフェスト、2811 シーン、2812 構成要素、2813 アセット、2814 ベース層、2815 属性強化層、2817 リスト、2911 シーン情報、2912 構成要素、2913 アセット、2914 ベース層、2915 属性強化層、2916 属性強化層、2917 シーン情報、2918 リスト、3010 タイムドメディア表示、3010A タイムドシーンマニフェスト、3011 シーン、3012 構成要素、3013 アセット、3014 ベース層、3015 属性強化層、3017 リスト、3111 シーン、3112 構成要素、3113 アセット、3114 ベース層、3115 属性強化層、3116 属性強化層、3117 シーン情報、3118 リスト、3200 プロセス、3201 プロセスステップ、3202 意思決定ステップ、3203 プロセスステップ、3204 意思決定ステップ、3205 プロセスステップ、3206 プロセスステップ、3207 プロセスステップ、3300 ポピュレーティング論理、3301 プロセスステップ、3302 意思決定ステップ、3303 意思決定ステップ、3304 プロセスステップ、3305 プロセスステップ、3306 プロセスステップ、3400 プロセス、3510 プロセス、3511 プロセスステップ、3512 プロセスステップ、3513 クライアントデバイス、3514 追加のリソース、3515 プロセスステップ、3516 プロセスステップ、3517 スマートコントローラ、3517A レンダラ、3517B GPU、3517C メディアキャッシュ、3517D ニューラルネットワークプロセッサ、3518 プ
ロセスステップ、3519 変換されたメディア、3520 プロセスステップ、3600 プロセス、3601 プロセスステップ、3602 プロセスステップ、3603 プロセスステップ、3604 プロセスステップ、3606 プロセスステップ、3608 プロセスステップ、3609 クライアント適応メディアキャッシュ、3610 プロセス、3700 プロセス、3810 クライアントメディアプロファイル、3811 リスト、3812 データ要素、3813 データ要素、3814 リスト、3815 リスト、3900 プロセス、4000 プロセス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】

【手続補正書】

【提出日】2024-06-10

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

電子デバイスが実行するメディア処理の方法において、
前記電子デバイスのクライアントインタフェースにより、没入型メディアストリーミングネットワーク内のサーバデバイスに対し、シーンベースの没入型メディアを再生するための前記電子デバイスの能力及び利用可能性の情報を送信するステップと、
前記クライアントインタフェースにより、前記シーンベースの没入型メディアのための適応したメディアコンテンツを搬送するメディアストリームを受信するステップであって、前記適応したメディアコンテンツは、前記能力及び利用可能性の情報に基づいて前記サーバデバイスにより前記シーンベースの没入型メディアから生成される、ステップと、
前記適応したメディアコンテンツに従って前記シーンベースの没入型メディアを再生するステップと
を含む、方法。

【請求項2】

前記クライアントインタフェースにより、第1のシーンと関連付けられる第1のメディアアセットが初めて受信され、前記適応したメディアコンテンツに従って1つ以上のシーンで再利用されるべきであると決定するステップと、
前記第1のメディアアセットを、前記電子デバイスによってアクセス可能なキャッシュデバイスに記憶するステップと
を更に含む、請求項1に記載の方法。

【請求項3】

前記クライアントインタフェースにより、前記メディアストリームから前記第1のシーン内の固有のアセットの第1のリストを抽出するステップであって、前記固有のアセットの第1のリストは、前記第1のメディアアセットを1つ以上の他のシーンで使用されるべき前記第1のシーン内の固有のアセットとして識別する、ステップ、
を更に含む、請求項2に記載の方法。

【請求項4】

前記能力及び利用可能性の情報を送信する前記ステップは、
前記クライアントインタフェースにより、前記電子デバイスにおける前記第1のメディアアセットの利用可能性を示す信号を前記サーバデバイスに送信するステップであって、前記信号は、前記サーバデバイスに、前記適応したメディアコンテンツ内の前記第1のメディアアセットの代わりにプロキシを使用させる、ステップ、
を含む、請求項2に記載の方法。

【請求項5】

前記シーンベースの没入型メディアを再生する前記ステップは、
前記クライアントインタフェースにより、前記第1のメディアアセットが前記適応したメディアコンテンツ内の前記プロキシに従って前記キャッシュデバイスに以前に記憶されていると決定するステップと、
前記第1のメディアアセットを取り出すために前記キャッシュデバイスにアクセスするステップと
を更に含む、請求項4に記載の方法。

【請求項6】

前記第1のメディアアセットの前記利用可能性を示す前記信号を送信する前記ステップは、
前記サーバデバイスから前記第1のメディアアセットに関する問合せ信号を受信するステップと、
前記問合せ信号に応答して、前記電子デバイスにおける前記第1のメディアアセットの前記利用可能性を示す前記信号を送信するステップと
を含む、請求項4に記載の方法。

【請求項7】

前記能力及び利用可能性の情報を送信する前記ステップは、
前記クライアントインタフェースにより、前記サーバデバイスからデバイス属性及びリソース状態を取得する要求を受信するステップと、
前記電子デバイスの属性と前記シーンベースの没入型メディアを処理するためのリソース利用可能性とに関して前記電子デバイスの1つ以上の内部構成要素及び／又は前記電子デバイスと関連付けられる1つ以上の外部構成要素に問い合わせるステップと、
前記電子デバイスの前記属性及び前記リソース利用可能性を前記サーバデバイスに送信するステップと
を含む、請求項1に記載の方法。

【請求項8】

ユーザインタフェースから前記シーンベースの没入型メディアの要求を受信するステップと、
前記クライアントインタフェースにより、前記シーンベースの没入型メディアの前記要求を前記サーバデバイスに転送するステップと
を更に含む、請求項1に記載の方法。

【請求項9】

前記シーンベースの没入型メディアを再生する前記ステップは、
前記クライアントインタフェースの制御下で、前記メディアストリームのデコーディング及びメディア再構成に基づいて再構成されたシーンベースの没入型メディアを生成するステップと、
前記電子デバイスのゲームエンジンのアプリケーションプログラミングインタフェース（API）を介して、前記再構成されたシーンベースの没入型メディアを再生するために前記ゲームエンジンに提供するステップと
を更に含む、請求項1に記載の方法。

【請求項10】

前記シーンベースの没入型メディアを再生する前記ステップは、
前記クライアントインタフェースにより、前記メディアストリームをデパケット化して、デパケット化されたメディアデータを生成するステップと、
前記電子デバイスのゲームエンジンのアプリケーションプログラミングインタフェース（API）を介して、前記デパケット化されたメディアデータを前記ゲームエンジンに提供するステップと、
前記ゲームエンジンにより、前記デパケット化されたメディアデータに基づいて再生するための再構成されたシーンベースの没入型メディアを生成するステップと
を更に含む、請求項1に記載の方法。

【請求項11】

請求項1～10のいずれか一項に記載の方法を行うように構成された、電子デバイス。

【請求項12】

コンピュータに、請求項1～10のいずれか一項に記載の方法を実行させるためのコンピュータプログラム。

【国際調査報告】