特表 2024-542402 アバタ・アタッチメント間の動的インタラクション

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

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

(11)【公表番号】

(43)【公表日】2024-11-15

(54)【発明の名称】アバタ・アタッチメント間の動的インタラクション

(51)【国際特許分類】

   G06F 3/0481 20220101AFI20241108BHJP

   A63F 13/577 20140101ALI20241108BHJP

   A63F 13/56 20140101ALI20241108BHJP

   A63F 13/75 20140101ALI20241108BHJP

   G06T 19/00 20110101ALI20241108BHJP

   G06T 13/40 20110101ALI20241108BHJP

【ＦＩ】

G06F3/0481

A63F13/577

A63F13/56

A63F13/75

G06T19/00 C

G06T13/40

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024526852

(86)(22)【出願日】2023-09-21

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

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

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

(87)【国際公開日】2024-04-18

(31)【優先権主張番号】17/966,540

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

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】524166282

【氏名又は名称】ブイアールチャット インコーポレイテッド

【氏名又は名称原語表記】ＶＲＣｈａｔ Ｉｎｃ．

【住所又は居所原語表記】５４８ Ｍａｒｋｅｔ Ｓｔ ＃９３０５３ Ｓａｎ Ｆｒａｎｃｉｓｃｏ， Ｃａｌｉｆｏｒｎｉａ ９４１０４， Ｕ．Ｓ．Ａ．

(74)【代理人】

【識別番号】110003281

【氏名又は名称】弁理士法人大塚国際特許事務所

(72)【発明者】

【氏名】グロズディーナ， チェイス アイリッシュ

(72)【発明者】

【氏名】ティン ニョ， デイヴィッド イー．

(72)【発明者】

【氏名】ミラー， ロナルド ジョン

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

5B050

5E555

【Ｆターム（参考）】

5B050AA03

5B050BA08

5B050BA09

5B050BA12

5B050CA07

5B050CA08

5B050DA01

5B050EA24

5B050EA26

5B050FA02

5B050FA05

5B050FA13

5B050FA17

5E555AA27

5E555AA79

5E555BA03

5E555BA04

5E555BA20

5E555BB03

5E555BB04

5E555BC08

5E555BE17

5E555DB32

5E555DC85

5E555FA00

(57)【要約】

本技術は、アバタ間の接触インタラクションのサポートに関する。例えば、本技術は、アバタ上のコライダとレシーバとの衝突をサポートし、その結果生じるエフェクトを実現する。別の例では、本技術は、アバタの部分から二次モーション動作をもたらす接触インタラクションをサポートする。アバタの部分は、二次モーションをするように構成されたアバタの部分に作用するコライダからの力によって操作することができる。アバタとアバタの部分との間のインタラクションをサポートすることに加えて、本技術は、アバタ間の接触インタラクションをサポートすることに付随する他の問題も解決する。そのような問題の一つは、アバタ間の接触に関わる同意の問題である。
【選択図】図１０

【特許請求の範囲】

【請求項1】

コライダと、衝突に反応するように構成されたアバタの部分との間の前記衝突に反応してアクションをトリガするための方法であって、
前記コライダと、前記衝突に反応するように構成された前記アバタの前記部分との間の衝突を検出することと、
前記検出された衝突を、前記アバタに関連付けられたアバタコントローラに報告することと、
前記衝突に対するリアクションをアニメーション化することと、
を含む、方法。

【請求項2】

前記衝突に反応するように構成された前記アバタの前記部分が、レシーバを含み、前記レシーバが、前記衝突に反応してアニメーションまたはエフェクトをトリガするように構成される、請求項１に記載の方法。

【請求項3】

前記コライダが第１のアバタ上にあり、前記衝突に反応するように構成された前記アバタの前記部分が第２のアバタ上にある、請求項１に記載の方法。

【請求項4】

前記衝突に反応するように構成された前記アバタの前記部分が、二次モーション動作を有するように構成される、請求項１に記載の方法。

【請求項5】

前記アクションが前記アバタへの永続的な状態変更に関連しているかどうかを判定することと、
前記アクションが前記アバタへの前記永続的な状態変更に関連していると判定された場合、前記第１のアバタと前記第２のアバタをレンダリングするアプリケーションのリモートインスタンスに状態変更通知を送信すること、
をさらに含む、請求項３に記載の方法。

【請求項6】

前記衝突に対する前記リアクションをアニメーション化する前に、前記検出された衝突から生じる前記リアクションを許可することに、前記第１のアバタと前記第２のアバタとの間に相互同意があるかどうかを判定すること、
をさらに含む、請求項３に記載の方法。

【請求項7】

前記検出された衝突から生じる前記リアクションを前記アニメーション化することがさらに、
前記構成された二次モーションに従って、前記コライダによって動くように操作される前記アバタの前記部分のモーションをアニメーション化することを含む、
請求項４に記載の方法。

【請求項8】

前記コライダと前記アバタの前記部分との間の前記衝突が、前記二次モーション動作で構成された前記アバタの前記部分を構成するトランスフォームのツリー内の一つのトランスフォームの物理シミュレーションをトリガすると判定すること、
をさらに含む、請求項４に記載の方法。

【請求項9】

前記コライダと前記アバタの前記部分との間の前記インタラクションが前記トランスフォームの前記物理シミュレーションをトリガすると判定された場合、前記インタラクションに関する情報を、プライマリスレッド以外のスレッドで処理されるジョブであって、前記トランスフォームの前記物理シミュレーションである前記ジョブに渡すこと、
をさらに含む、請求項８に記載の方法。

【請求項10】

命令を含む、非一時的なコンピュータで読み取り可能な記憶媒体であって、
前記命令は、コンピュータによって実行されると、前記コンピュータに、
コライダと、衝突に反応するように構成されたアバタの部分との間の前記衝突を検出することと、
前記検出された衝突をアバタコントローラに報告することと、
前記衝突に対するリアクションをアニメーション化することと、
を実行させる、
コンピュータで読み取り可能な記憶媒体。

【請求項11】

前記衝突に反応するように構成された前記アバタの前記部分が、レシーバを含み、前記レシーバが、前記衝突に反応してアニメーションまたはエフェクトをトリガするように構成される、請求項１０に記載のコンピュータで読み取り可能な記憶媒体。

【請求項12】

前記衝突に反応するように構成された前記アバタの前記部分が、二次モーション動作を有するように構成される、請求項１０に記載のコンピュータで読み取り可能な記憶媒体。

【請求項13】

前記衝突に対する前記リアクションを前記アニメーション化することが、前記検出された衝突から生じ、前記命令は、さらに、前記コンピュータを、
前記構成された二次モーションに従って、前記コライダによって動くように操作される前記アバタの前記部分のモーションをアニメーション化する、ように構成する、請求項１２に記載のコンピュータで読み取り可能な記憶媒体。

【請求項14】

前記命令は、さらに、前記コンピュータを、
前記コライダと前記アバタの前記部分との間の前記衝突が、前記二次モーション動作で構成された前記アバタの前記部分を構成するトランスフォームのツリー内の一つのトランスフォームの物理シミュレーションをトリガすると判定する、ように構成する、
請求項１２に記載のコンピュータで読み取り可能な記憶媒体。

【請求項15】

前記命令は、さらに、前記コンピュータを、
前記コライダと前記アバタの前記部分との間の前記インタラクションが前記トランスフォームの前記物理シミュレーションをトリガすると判定された場合、前記インタラクションに関する情報を、プライマリスレッド以外のスレッドで処理されるジョブであって、前記トランスフォームの前記物理シミュレーションであるジョブに渡す、ように構成する、
請求項１４記載のコンピュータで読み取り可能な記憶媒体。

【請求項16】

プロセッサと、
命令を記憶するメモリであって、前記命令は前記プロセッサによって実行されると、システムを、
コライダと、衝突に反応するように構成されたアバタの部分との間の前記衝突を検出することと、
前記検出された衝突をアバタコントローラに報告することと、
前記衝突に対するリアクションをアニメーション化すること、のように構成する、
を含むコンピューティングシステム。

【請求項17】

前記衝突に反応するように構成された前記アバタの前記部分が、レシーバを含み、前記レシーバが、前記衝突に反応してアニメーションまたはエフェクトをトリガするように構成される、請求項１６に記載のコンピューティングシステム。

【請求項18】

前記コライダが第１のアバタ上にあり、前記衝突に反応するように構成された前記アバタの前記部分が第２のアバタ上にある、請求項１６に記載のコンピューティングシステム。

【請求項19】

前記衝突に反応するように構成された前記アバタの前記部分が、二次モーション動作を有するように構成される、請求項１６に記載のコンピューティングシステム。

【請求項20】

前記衝突に対する前記リアクションを前記アニメーション化することが、前記検出された衝突から生じ、前記コンピューティングシステムは、
前記構成された二次モーションに従って、前記コライダによって動くように操作される前記アバタの前記部分のモーションをアニメーション化する、ように、構成される、請求項１９に記載のコンピューティングシステム。

【発明の詳細な説明】

【背景技術】

【0001】

コンピューティングシステムのユーザは、単純なチャットアプリケーションから、ビデオゲームアプリケーションやバーチャルリアリティアプリケーションで使用される精巧な３次元（３Ｄ）環境に至るまで、様々なアプリケーションにおいて、自分の物理的な存在の代わりとしてアバタを利用している。アバタの単純なバージョンは、いかなる区別する特徴もなしに、肩と頭の形状であり得る。いくつかのアバタは複雑であり得、詳細なグラフィック、テクスチャに関連付けられ得、様々なアニメーションが可能であり得る。例えば、アバタの中には、髪、尾、耳、衣服など、リアルな動きや非リアルな動きのために別々にアニメーション化される多くの部分を含むものもある。

【0002】

本開示に記載される主題の１つ以上の態様の詳細は、添付の図面および以下の説明に記載される。しかしながら、添付の図面は、本開示のいくつかの典型的な態様のみを例示するものであり、したがって、その範囲を限定するものとはみなされるべきではない。他の特徴、態様、および利点は、本明細書、図面、および特許請求の範囲から明らかになるであろう。

【図面の簡単な説明】

【0003】

【図1】図１は、本技術のいくつかの態様による、マルチプレーヤバーチャルリアリティ（ＶＲ）体験をプレイおよびホストするための例示的な仮想世界プラットフォームを示す。

【0004】

【図2】図２は、本技術のいくつかの態様による、クイックメニューの例を示す。

【0005】

【図3】図３は、本技術のいくつかの態様による、第１のアバタおよび第２のアバタとの衝突に応答するアクションをトリガするための例示的な方法を示す。

【0006】

【図4】図４は、本技術のいくつかの態様による、アバタの部分の二次モーションに影響を与えるインタラクションをサポートするための例示的な方法を示す。

【0007】

【図5A】図５Ａは、本技術のいくつかの態様による、アバタ接触インタラクションが許可されているかどうかを判断するための例示的な方法を示している。

【図5B】図５Ｂは、本技術のいくつかの態様による、アバタ接触インタラクションが許可されているかどうかを判断するための例示的な方法を示している。

【図5C】図５Ｃは、本技術のいくつかの態様による、アバタ接触インタラクションが許可されているかどうかを判断するための例示的な方法を示している。

【0008】

【図6】図６は、本技術のいくつかの態様による、サポートされる接触インタラクションを許可するために、ペアのアバタ間に相互同意があるかどうかを判定する例示的な方法を示す。

【0009】

【図7】図７は、本技術のいくつかの態様による、例示的な接触設定と、それらの設定によって接触インタラクションが許可されるか否かを示す例示的なテーブルを示す。

【0010】

【図8】図８は、本技術のいくつかの態様による、１つ以上のコライダで構成されたアバタの部分を示す。

【0011】

【図9A】図９Ａは、本技術のいくつかの態様による、接触インタラクションを行う２つのアバタを示す。

【0012】

【図9B】図９Ｂは、本技術のいくつかの態様による、ハイタッチ接触インタラクションが発生した直後の瞬間を示す。

【0013】

【図10】図１０は、本技術のいくつかの態様による、コライダとして構成された部分と、二次モーション動作として構成された部分とを有するアバタを示す。

【0014】

【図11】図１１は、本技術のいくつかの態様による、アバタの部分に二次モーション属性を設定するための例示的なインタフェースを示す。

【0015】

【図12】図１２は、本技術のある態様を実施するためのシステムの一例を示す。

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

【0016】

いくつかのバーチャルリアリティプラットフォームが主催するような仮想世界におけるユーザ間のインタラクションは進化し続けている。当初は、同じ世界で共存し、一緒にゲームをすることに限られたインタラクションであった。インタラクションはライブ・コミュニケーションへと進展し、やがてバーチャル・イベントに一緒に参加するようになった。最近では、ユーザはアバタの可動域を広げ、これらの仮想世界でより物理的なインタラクションができるようになった。例えば、仮想世界でエクササイズをしたり、ナイトクラブでダンスをしたりできるようになった。

【0017】

仮想世界における人間（アバタであるが）間のインタラクションにおける次の進歩は、物理的なインタラクションである。すなわち、当技術分野には、アバタ間の物理的なインタラクションをサポートする必要性があった。本技術は、この問題と、アバタ間の接触ベースのインタラクションに関連する他の関連する問題を解決する。

【0018】

以前は、アバタの部分が別のアバタの部分と接触することは可能であったが、これは空間内の２つのオブジェクト（物体）が近接する以上のものではなかった。それぞれのアバタが空間のボリュームを占め、互いにぶつかることはあっても、接触によるインタラクションやリアクションはなかった。本技術は、接触によるインタラクションを受けたアバタが、そのインタラクションにリアクションすることをサポートすることができる。いくつかの実施形態では、インタラクションに対するリアクションは、アニメーション、音、または他のエフェクトであり得る。本技術は、アバタの部分の間での継続的なインタラクションもサポートすることができる。例えば、本技術は、あるアバタが別のアバタの髪をとかすことを可能にすることができる。

【0019】

本技術は、ユーザがアバタの部分をコライダ（collider：物理衝突の判定処理のためのオブジェクトの表現）として定義できるアバタを構築するためのソフトウェア開発キットが含む。いくつかの実施形態では、手や他の付属物など、アバタの部分が、自動的にコライダとみなされ得る。また、本技術では、ユーザがアバタの部分をレシーバとして定義することを可能とする。レシーバは、コライダからの接触をレシーバが受けたときに、アニメーション、サウンド、その他のエフェクトをトリガすることができるアバタの部分である。

【0020】

本技術はまた、コライダとレシーバ間の衝突を検出し、その結果生じるエフェクトを有効にする方法にも関する。コライダは、物理的な衝突を目的としてオブジェクトの形状を定義する。一般に不可視であるコライダは、オブジェクトと完全に同じ形状である必要はなく、実際には、大まかな近似の方が効率的であり、ゲームプレイにおいて区別できないことが多い。いくつかの例では、コライダは固体オブジェクトとして振る舞う必要はなく、単に他のコライダがそれを通過することを可能とする。

【0021】

レシーバは、結果としてエフェクトを引き起こすトリガが設定されたコライダであり得る。オブジェクトがレシーバの空間に入ると、レシーバは、その上で、レシーバ用に設定されたスクリプトを実行するための関数を呼び出す。スクリプトシステムや物理エンジンは、コライダとレシーバの間で衝突が発生したことを検出し、アクションを開始することができる。

【0022】

本技術は、ユーザが継続的なインタラクションをサポートするために、アバタの部分を定義することを可能とするアバタを構築するためのソフトウェア開発キットを含む。アバタのいくつかの部分は、二次モーションを有するように構成されており、アバタのそのような部分は、二次モーションを有するように構成されたアバタの部分に及ぼされるコライダからの力によって操作することができる。本明細書で取り上げるように、アバタの部分（同じアバタまたは別のアバタ）上のコライダは、二次モーションを有するように構成されたアバタの部分とインタラクションして、二次モーションを有するように構成されたアバタの部分の動きを引き起こすことができる。

【0023】

一次モーションとは、手足を動かすための明示的な制御による手足の動きや、アバタが占める空間の体積が仮想世界内の異なる座標位置に変換されるような空間を通る動きなど、動きを駆動するための明示的な入力によって引き起こされるアバタの明示的な動きを指す。二次モーションとは、アバタの部分の動きに付随する物理的な力、風の吹き付け、他のアバタによって加えられる力など、環境の力によって引き起こされる動きを指す。これらの動きは、一次モーションの結果として、二次モーション属性で構成されたアバタの部分に加えられる物理的な力によって生成される。例えば、歩くという一次モーションの結果として、慣性力および重力が髪に加えられ、髪を跳ねさせる。

【0024】

アバタとアバタの部分との間のインタラクションをサポートすることに加えて、本技術はアバタ間のインタラクションをサポートすることに付随する他の問題も解決する。その一つが同意の問題である。接触インタラクションがサポートされているからといって、ユーザが自分のアバタに触れられることを望んでいることを意味しない。バーチャルリアリティ環境の本質は、ユーザが自分のアバタと密接につながることができることである。多くの場合、ユーザは一人称視点で世界を見ることを選択するので、その結果、あるアバタが別のアバタに触れるインタラクションは、一人称視点での接触として認識される。このように、現実世界では、一部の接触が歓迎されないように、仮想世界でも歓迎されない。したがって、本技術は、接触に対するユーザの同意を宣言し、接触が望まれない場合には接触を無効にする安全フレームワークを提供する。

【0025】

本技術が解決するもう一つの課題は、このような接触インタラクションをサポートするために必要とされる処理の効率を向上させることである。本技術は、接触インタラクションが行われていることを検出するための効率的なメカニズムを利用する。重なり合うボリュームの検出は困難な問題であるため、この判定を行うための効率的なメカニズムが考案された。効率向上のもう一つの領域は、接触インタラクションによって引き起こされる二次モーションを、仮想世界をレンダリングするために使用されるメインスレッドから分離することであり、これにより、これらのオブジェクトの二次モーションをより効率的にサポートすることができる。

【0026】

本技術のこれらおよびその他の利点については、本明細書でさらに述べる。

【0027】

図１は、本技術を実施するのに適した、マルチプレーヤバーチャルリアリティ（ＶＲ）体験を再生およびホストするための例示的な仮想世界プラットフォーム１０２を示す。仮想世界プラットフォーム１０２は、ウェブサービス１１０およびネットワーキングサービス１１２を介してクライアント１０４を接続し、仮想世界プラットフォーム１０２によってホストされる仮想世界において、一緒に社会的にインタラクトすることができる。

【0028】

仮想世界プラットフォーム１０２は、主に、クライアントデバイス１０６上で実行されるアプリケーションのインスタンスであるクライアント１０４を含む。クライアント１０４は、１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）を通じて様々なサービスを提供することによってクライアント１０４をサポートするウェブサービス１１０とネットワーク接続を介してインタラクションする。ウェブサービス１１０によって提供される主なサービスのいくつかは、ワールドＡＰＩ１２８を通じた仮想世界のサポート、ユーザＡＰＩ１３２を通じたユーザプロファイル、信頼ＡＰＩ１４４を通じた信頼および安全性、アバタＡＰＩ１３６を通じた複雑なアバタに関する。ウェブサービス１１０は一般に、他の機能の中でも、長期的な状態情報を保存し提供する。

【0029】

クライアント１０４はまた、ネットワーキングサービス１１２ともインタラクションし、ネットワーキングサービス１１２は、クライアント１０４、ネットワーキングサービス１１２、およびクライアント１０４のリモート・インスタンス（図示せず）の間で通信サービスを提供し、クライアント１０４の各インスタンス間で状態情報を共有する。特に、状態情報は、クライアント１０４の各インスタンスがそのローカルプレーヤ１１６を制御する際に、ネットワーキングサービス１１２によってクライアント１０４の複数のインスタンスから受信される。ネットワーキングサービス１１２は、それぞれのクライアント・インスタンスのローカルプレーヤ１１６がすべて同じ仮想世界でゲームプレイに従事しているときに、それぞれのプレーヤに関する状態情報をクライアント１０４の他のインスタンスに転送することができる。ネットワーキングサービス１１２は、最適化されたパケットルーティングサービス１４０を通じて最適化パケット・ルーティングを提供し、モデレーションサービス１４２を通じて１つ以上のクライアント間のモデレーションを提供する。

【0030】

クライアント１０４は、特定のクライアントデバイス１０６上で実行されるランタイム環境である。本明細書では、クライアント１０４、ローカルクライアント、およびリモートクライアントを指すことがあるが、すべて、それぞれのクライアントデバイス１０６上で実行されるクライアント１０４のインスタンスである。クライアント１０４の特定のインスタンスには、１つの特定のユーザアカウントがログインされる。ローカルクライアントおよびリモートクライアントは、クライアント１０４が、どのように、クライアント１０４が実行されているクライアントデバイス１０６のユーザからの一人称入力を処理し、リモートクライアントが実行されているクライアントデバイスを操作している別のユーザから受信した第三者入力を処理するかを説明するために区別される。

【0031】

クライアントデバイス１０６は、任意のコンピューティングデバイスとすることができる。クライアント１０４は、体験するためにＶＲヘッドセットを必要とするインタラクションを通じて没入型バーチャルリアリティ体験を提供することに特に適合しているが、クライアント１０４は、コンピュータおよびモバイルデバイスによっても実行可能である。一部の仮想世界または複雑なアバタは、特定のデバイスタイプでうまく動作するように構成されていない可能性があり、したがって、クライアント１０４は多くのプラットフォームおよびデバイス上で動作可能であるが、すべての仮想世界または複雑なアバタがすべてのクライアントデバイス１０６上で利用可能であるか、または完全な機能を有するわけではない。

【0032】

ユーザインタフェースサービス１０８は、クライアント１０４の一部であるサービスの１つである。ユーザインタフェースサービス１０８は、様々なユーザ設定、利用可能なワールド（世界）、保存された複雑なアバタ、友達リストなどを表示するメニューなどの様々なユーザインタフェース要素を提供するように構成される。ユーザインタフェースサービス１０８は、ウェブサービス１１０によって提供される１つ以上のＡＰＩとのインタラクションを通じてそのメニューを投入することができ、メニューの他の部分はユーザインタフェースサービス１０８から直接ロードされる。

【0033】

ユーザインタフェースサービス１０８は、クライアント１０４にログインしているユーザアカウントが入ることを許可されているワールドのリストを取得するためにワールドＡＰＩ１２８を呼び出すことによって、利用可能なワールドのメニューを提供することができる。ワールドＡＰＩ１２８は、ワールドアセットデータベース１３０からすべてのパブリックワールドを取得し、それらのリストをクライアント１０４に送信することができる。さらに、ワールドＡＰＩ１２８は、クライアント１０４にログインしたユーザアカウントに関連付けられた任意のプライベートワールドのワールドＩＤを要求し、ワールドアセットデータベース１３０からプライベートワールドを取得してクライアント１０４に送信することができる。ユーザインタフェースサービス１０８は、ワールドメニューをナビゲートし、訪問するワールドの選択を受け取るために、ハードウェアインタフェースを介してユーザ入力を受け取ることができる。

【0034】

ユーザインタフェースサービス１０８によって提供される別のユーザインタフェースは、様々なユーザ設定に関係する。このような設定は、人間のプレーヤが座っているか立っているかの設定、ＶＲでプレイするときに映像酔いしやすいプレーヤの映像酔いを最小限に抑えるための設定、複雑なアバタを選択するための設定、仮想世界でプレーヤがどのように見られるか、プレーヤが誰に見られるかに関する設定などに関係し得る。

【0035】

ユーザインタフェースサービス１０８によって提供される注目すべきユーザインタフェースの１つは、信頼および安全メニューである。ユーザインタフェースサービス１０８は、ユーザＡＰＩ１３２に連絡して、ユーザプロファイル・データベース１３４から現在の信頼および安全設定を取得し、これらの設定を信頼および安全メニューに表示することができる。信頼および安全メニューは、ユーザアカウントに、どのリモートプレーヤ１２４がユーザのアバタ（ローカルプレーヤ１１６）を見ることができるか、または両者が同じワールドにいるときにユーザのアバタに見られることができるかを決定する能力を提供する。例えば、仮想世界プラットフォーム１０２の新しいユーザは、仮想世界プラットフォーム１０２内で信頼関係を構築していないため、インタラクトを避けることが望ましい場合がある。また、ローカルユーザがログインしているクライアント１０４のインスタンスによって処理されるリモートプレーヤのアバタの機能を制限することも望ましい場合もある。これは、アバタによっては悪意のあるデータが埋め込まれている可能性があり、または、アバタが複雑すぎてクライアントデバイス１０６のパフォーマンスを低下させることなくレンダリングできない可能性があるからである。例えば、ユーザアカウントは、シェーダを回避するためにリモートアバタのライトをオフにする、カスタムアニメーションを許可しない、などを決定することができる。いくつかの実施形態では、これらの各オプションは、リモートプレーヤがどの程度信頼されているかに基づいて設定されてもよい。例えば、ユーザアカウントは、友人のアバタがフル機能を有することを許可することができ、他のユーザアカウントは基本的なアバタ機能のみを表示することができる。

【0036】

ユーザインタフェースサービス１０８は、また、特定のリモートプレーヤをミュートまたはブロックするオプションも提供することができる。さらに、ユーザインタフェースサービス１０８は、友人以外の人物を音声および視覚的にミュートするパニックモードを提供することができる。

【0037】

ユーザがユーザインタフェースサービス１０８によって提供されたメニューから仮想世界を選択した後、クライアント１０４は、ワールドＡＰＩ１２８を呼び出すことによって仮想世界のインスタンスをダウンロードすることができ、ワールドＡＰＩ１２８は、ワールドアセットデータベース１３０のワールドから仮想世界を取得し、実行のためにクライアント１０４に送信することができる。

【0038】

ワールドアセットは、仮想世界プラットフォーム１０２で使用するために提供されるソフトウェア開発キット（ＳＤＫ）を備えたエディタを使用して、ＵＮＩＴＹなどのゲームエンジン用に構築された大きなバイナリファイルである。ユーザがあるワールドに移動する場合、ワールドアセットデータベース１３０からそのワールドアセットをダウンロードする必要がある。そのワールドのインスタンスにすでに人がいる場合、クライアント１０４は、仮想世界のインスタンスでアバタをレンダリングすることができるように、それらの人のアバタのリストも必要とする。

【0039】

いくつかの実施形態では、ワールドＡＰＩ１２８の機能はユーザアカウントが要求されたワールドにアクセスできることを確認することができる。ユーザアカウントはユーザインタフェースメニューのパブリックワールドを見る能力のみを持つべきか、ユーザアカウントと共有されたワールドへのリンクの知識のみを持つべきであるが、ワールドＡＰＩ１２８は冗長性対策としてユーザアカウントが仮想世界にアクセスすることを許可されているか確認することができる。

【0040】

仮想世界のインスタンスをダウンロードすることに加えて、クライアント１０４は、仮想世界の特定のインスタンスについてネットワーキングサービス１１２とのセッションを確立することもできる。ネットワーキングサービス１１２は、仮想世界のインスタンスの現在の状態に関する情報を提供することができる。例えば、ネットワーキングサービス１１２は、仮想世界のインスタンスに存在するリモートアバタ１２６のリストをクライアント１０４に提供することができる。次に、クライアント１０４はアバタＡＰＩ１３６に連絡して、アバタアセットデータベース１３８からリモート複合アバタのリストの複合アバタアセットをダウンロードすることができる。

【0041】

クライアント１０４がローカルアバタ１１８のためのアセットを持っていない場合、クライアント１０４は、また、アバタＡＰＩ１３６に連絡してローカルアバタアセットを要求して受け取ることもできる。アバタアセットとは、アバタをレンダリングするために必要なテクスチャとモデルとアニメーションデータのすべてを含む単一のバイナリファイルのことである。場合によっては、パーティクルシステムや光源に関するデータ、アバタが仮想世界で確立された物理法則に従うべきか逆らうべきか、アバタが標準的でない動きのダイナミクスを持つ場合など、より複雑な機能を含めることができる。いくつかの実施形態では、アバタアセットは、アバタの部分に定義されたコライダおよびレシーバ、またはアバタの部分に二次モーション動作を示させるトランスフォームのツリーを含む（例えば、ダイナミックボーンまたは物理ボーン（別名phys.bones）は、アバタの部分に二次モーション動作を示すように構成できるシステムの例である）。

【0042】

ダウンロードされた仮想世界のインスタンスは、現在のワールド１２０としてクライアント１０４によって実行され得る。現在のワールド１２０は、ローカルプレーヤ１１６および各リモートプレーヤ１２４が位置する現在のワールド１２０内の座標を含み得る。ローカルプレーヤ１１６およびリモートプレーヤ１２４は、それぞれのローカルプレーヤ１１６またはリモートプレーヤ１２４が占有する空間の各衝突ボリュームである。

【0043】

ローカルアバタ１１８はローカルプレーヤ１１６にマッピングすることができ、それぞれのリモートアバタ１２６はそれぞれのリモートプレーヤ１２４にマッピングすることができ、それによって各プレーヤは現在のワールド１２０に自分のアバタとして現れることを可能にする。リモートアバタ１２６の動きは、それぞれのリモートアバタ／プレーヤに関する状態データを受信し、クライアント１０４によって動きまたは音声をレンダリングすることによって処理される。

【0044】

ＶＲトラッキングサービス１１４は、ＶＲトラッキング周辺機器にアクセスを有するクライアントデバイス１０６上で動作するクライアント１０４に関係する。例えば、ＶＲヘッドセットの中には、プレーヤの手足をトラッキングするためのカメラ（一体型または外付け）を有するものがある。多くのＶＲヘッドセットは、空間内のユーザの手の位置を報告できるコントローラとペアリングすることができる。クライアントデバイス１０６の中には、完全なスケルトントラッキングを行うように構成された他の周辺機器を含むものもある。ＶＲトラッキングサービス１１４は、クライアントに接続された全てのＶＲ入力を融合することができる。

【0045】

ＶＲトラッキングサービス１１４は、融合されたＶＲ入力をローカルプレーヤ１１６にマッピングして、ローカルプレーヤ１１６が現在のワールド１２０内で及び現在のワールド１２０とインタラクトできるようにすることができる。一方、ローカルプレーヤ１１６は、ローカルアバタ１１８とインタラクションして、ローカルアバタ１１８をローカルプレーヤにマッピングし、ローカルプレーヤ１１６を自分のアバタとして表示させることができる。

【0046】

いくつかの実施形態では、ユーザの身体のどの部分がＶＲトラッキングサービス１１４によってトラッキングされるかは多様である。あるユーザは完全なスケルトントラッキングを有するかもしれないが、多くのユーザはハンドトラッキングを行う能力しか持たないかもしれない。考えられるクライアントデバイス１０６のハードウェア能力のこのような違いに対応するために、ローカルプレーヤ１１６は、ＶＲトラッキングサービス１１４によってトラッキングされないスケルトンの部分を導き出すことができる。例えば、ＶＲトラッキングサービス１１４がユーザの手のトラッキングに関する情報しか提供しない場合でも、ローカルプレーヤはさらにユーザの完全なスケルトン導出し、手の動きに対応するようにスケルトンの一部を動かすことができる。このように、アバタの手は、アバタの他の部分から切り離された形で動くことはない。

【0047】

ローカルプレーヤ１１６は、現在のワールド１２０内の環境を動き回るエンティティである。それは、物を拾ったり置いたりすることができる。それは、アニメーションはなく、コリジョンボリュームである。それは、ワールド内のあらゆることができるが、外観がなく、アニメーションする必要もない。

【0048】

ローカルプレーヤは、ランタイムネットワーキングサービス１２２として示されるネットワーキング層にさらに接続され、ローカルプレーヤ１１６に関する状態情報を、現在のワールド１２０のインスタンス内の他のユーザにネットワーク経由でブロードキャストする。

【0049】

ローカルプレーヤ１１６とリモートプレーヤ１２４は、現在のワールド１２０の環境内を移動するコリジョンボリュームであるという点で類似している。主な違いは、ローカルプレーヤ１１６はクライアント１０４によって制御され、クライアント１０４のユーザが体験をオーサリングしていることである。対照的に、リモートプレーヤ１２４は、現在のワールド１２０に存在する他のプレーヤを表すクライアント１０４にブロードキャストされるアクションを表す再生メカニズムである。

【0050】

上述したように、ローカルアバタ１１８は、ユーザに視覚的な外観を与えるために、ローカルプレーヤ１１６とオーバーレイされる。ローカルプレーヤ１１６によるアクションは、ローカルプレーヤが現在のワールドとインタラクションするときにアニメーション化される。例えば、ローカルプレーヤ１１６は現在のワールド１２０でオブジェクトを手に取るためにインタラクションできるが、ローカルアバタ１１８がなければ、オブジェクトは空中に浮いているように見えるであろう。ローカルプレーヤ１１６の上にローカルアバタ１１８がオーバーレイされると、オブジェクトはアバタの手によって保持されているように見える。

【0051】

リモートプレーヤ１２４とリモートアバタ１２６は、リモートプレーヤ１２４を制御する入力がどこから来るかを除いて、ローカルプレーヤと同様に動作する。リモートプレーヤ１２４とリモートアバタ１２６は、ランタイムネットワーキングサービス１２２がネットワーキングサービス１１２から受信した状態情報のための再生デバイスである。図１は、１つのリモートプレーヤ１２４とリモートアバタ１２６のみを示すが、多数存在してもよい。

【0052】

クライアント１０４は、また、アバタ間、アバタの部分と同じアバタの別の部分、またはアバタの部分と仮想世界のオブジェクトとの接触インタラクションをサポートすることもできる。これらのインタラクションを検出するために、クライアント１０４は、衝突検出システム１４８を使用してオブジェクト間の衝突を検出するように構成され得る。いくつかの実施形態では、衝突検出システム１４８は、広帯域位相衝突検出システムとすることができる。

【0053】

また、現在のワールド１２０はネットワークを必要とする機能を備えている。現在のワールド１２０は、ユーザが手に取ることができるハサミや照明スイッチなどのオブジェクトを有することができ、オブジェクトは、現在のワールド１２０内の他のユーザがオブジェクトの現在の状態を見ることができるように、ネットワークを通じてその状態をブロードキャストする必要がある。

【0054】

ローカルプレーヤ１１６、現在のワールド１２０、およびリモートプレーヤ１２４のそれぞれは、ランタイムネットワーキングサービス１２２に接続される。ローカルプレーヤ１１６は主に、ローカルプレーヤ１１６の更新された状態情報を、同じ仮想世界をやはり実行しているクライアント１０４のリモートインスタンスに送信する。現在のワールド１２０は、仮想世界のインスタンスに関する状態情報を送受信することができる。クライアント１０４上で実行される現在のワールドは、状態変更がローカルプレーヤ１１６によって所有されるときに状態情報を送信し、状態変更がリモートプレーヤ１２４によって所有されるときに状態情報を受信する。

【0055】

ネットワーキングサービス１１２は、仮想世界プラットフォーム１０２のネットワーキング層のネットワーク側の部分である。いくつかの実施形態では、ネットワーキングサービス１１２の一部は、仮想世界のインスタンス内のすべてのユーザに状態情報をブロードキャストする、ＰＨＯＴＯＮネットワーキングエンジンなどのネットワーキングプラグインによって提供される。

【0056】

仮想世界のインスタンスとインタラクションするすべてのユーザに対する状態情報の一般的なブロードキャストに加えて、最適化されたパケットルーティングサービス１４０は、強化されたユーザ体験を提供し、信頼および安全構成などの他の仮想世界プラットフォーム１０２の機能を実施する、より高度な機能を提供する。

【0057】

例えば、強化されたユーザ体験を提供するために、最適化されたパケットルーティングサービス１４０は、現在のワールド１２０のインスタンスにおいてローカルプレーヤ１１６から遠く離れている可能性のあるリモートプレーヤ１２４から来る音声パケットをフィルタリングすることができる。そのような最適化が行われないと、ローカルプレーヤとインタラクションしていないか、またはローカルプレーヤには見えないリモートプレーヤ１２４が、数十または数百のリモートプレーヤ１２４から音声パケットを受信する可能性があり、リモートプレーヤ１２４の任意のサブセットと通信することが困難になる。

【0058】

別の例では、最適化されたパケットルーティングサービス１４０は、信頼および安全設定を実施することができる。上記で取り上げたように、信頼および安全設定は、ローカルプレーヤ１１６とインタラクションできないように、またはローカルプレーヤ１１６とのインタラクションが制限されるように、フィルタリングされる特定のユーザアカウントまたはユーザアカウントのグループを指定することができる。最適化されたパケットルーティングサービス１４０は、信頼ＡＰＩ１４４を呼び出して、信頼および安全設定を有するローカルプレーヤ１１６に対してクライアント１０４に向かうまたはクライアント１０４から来るネットワークトラフィックのあるレベルのフィルタリングまたはブロッキングを受ける必要があり得るリモートプレーヤ１２４のリストを知ることができる。

【0059】

信頼ＡＰＩ１４４は、どのリモートプレーヤ１２４がローカルプレーヤ１１６のためにブロックされるべきか、またはどのリモートプレーヤ１２４がその複雑なアバタの態様を制限されるべきかを決定することができる。これらの決定のいくつかは、仮想世界プラットフォーム１０２との過去のインタラクションの量と種類に基づいてリモートプレーヤ１２４を分類するロジックとルールに基づく。信頼ＡＰＩ１４４は、ローカルプレーヤ１１６のユーザプロファイルに保存された設定を使用し、これらの設定をリモートプレーヤ１２４のユーザプロファイルに保存されたデータと比較することによって、これらの決定を行うことができる。

【0060】

ネットワーキングサービス１１２のもう１つは、競合解決とアクセス制御を提供できるモデレーションサービス１４２である。例えば、ユーザがワールド、特にプライベートワールドにアクセスする前に、モデレーションサービス１４２は、ワールドＡＰＩ１２８を呼び出して、ユーザがワールドに入ることができることを確認することができる。別の例では、２つの異なるユーザがほぼ同時に仮想世界のオブジェクトの制御を要求しようとする場合があり得る。モデレーションサービス１４２は、オブジェクトの制御を放棄するまでオブジェクトを制御する特定のユーザを選択することによって、そのような種類の競合を処理することができる。オブジェクトを制御しているユーザは、リモートプレーヤ１２４にそのオブジェクトの状態を知らせるパケットをブロードキャストすることができる。

【0061】

いくつかの実施形態では、クライアント１０４、仮想世界、および複雑なアバタは、特定のゲームエンジン、特に３次元（３Ｄ）環境をサポートするゲームエンジンで動作するように構成することができる。２つの一般的なゲームエンジンには、ＵＮＩＴＹおよびＵＮＲＥＡＬ ＥＮＧＩＮＥが含まれる。

【0062】

いくつかの実施形態では、仮想世界プラットフォーム１０２によってサポートされるために、仮想世界および複雑なアバタは、ソフトウェア開発キット（ＳＤＫ）に準拠して開発される必要がある。例えば、複雑なアバタは、仮想世界プラットフォーム１０２で使用可能であるために特定のスクリプトを必要とする。別の例では、アバタのアニメーションを再生するために従わなければならない多くの要件があり得る。いくつかの実施形態では、ＳＤＫは、特定のクライアントデバイスをサポートするために必要な他の詳細を定義することができる。例えば、ＳＤＫは、アバタがＯＣＵＬＵＳ ＱＵＥＳＴ ＶＲヘッドセットで使用される場合に使用される特定のシェーダを定義することができる。

【0063】

いくつかの実施形態では、ＳＤＫは、ワールドが準拠した動作を有することを保証するために、仮想世界が特定のコーディング言語を利用することを要求する。例えば、ＳＤＫは、特定の仮想世界プラットフォーム１０２、ＶＲチャットに固有のプログラミング言語であるＵＤＯＮを使用して、ワールド内の動作が定義されることを要求することができる。いくつかの実施形態では、プログラミング言語は、仮想世界プラットフォーム１０２によって提供されるファイルアクセスの保護に準拠するように、プログラミング言語を使用して構築された世界を促進する。例えば、ワールドはハードドライブに対して何も読み書きできず、仮想世界プラットフォーム１０２上のワールドでは承認されたウェブページのみをレンダリングできる。

【0064】

いくつかの実施形態では、仮想世界プラットフォーム１０２はまた、簡略化アバタサービス１４６を含むことができる。本明細書で説明するように、簡略化アバタサービス１４６は、複雑なアバタの簡略化バージョンを作成し、複雑なアバタの簡略化バージョンのアバタアセットをアバタアセットデータベース１３８に保存することができる。

【0065】

仮想世界プラットフォーム１０２は、本技術を実施するのに適しているが、当業者であれば、本技術を他の環境でも使用できることを理解するであろう。

【0066】

図２は、本技術のいくつかの態様による、例示的なクイックメニュー２０２を示す。特に、クイックメニュー２０２は、クライアント１０４上のユーザインタフェースサービス１０８によって、仮想世界プラットフォーム１０２の任意の時間または場所で、表示することができる。

【0067】

クイックメニュー２０２には、ワールド、アバタ、友達をブラウズするメニューや、ユーザのプロフィールの安全設定を行う安全メニュー２０８など、一般的に使用される多くのメニューオプションを含むクイックリンク２０４セクションが含まれる。

【0068】

信頼および安全メニュー２０８は、両者が同じ世界にいるときに、どのリモートプレーヤ１２４がユーザのアバタ（ローカルプレーヤ１１６）を見ることができるか、またはユーザのアバタに見られるかを決定する能力をユーザアカウントに提供する。例えば、仮想世界プラットフォーム１０２のより新しいユーザは仮想世界プラットフォーム１０２内で信頼関係を構築していないため、より新しいユーザとのインタラクトを避けることが望ましい場合がある。また、ローカルユーザがログインしているクライアント１０４のインスタンスによって処理されるリモートプレーヤのアバタの機能を制限することが望ましい場合もある。これは、アバタによっては悪意のあるデータが埋め込まれていたる可能性があり、またはアバタが複雑すぎてクライアントデバイス１０６のパフォーマンスを低下させることなくレンダリングできない可能性があるからである。例えば、ユーザアカウントは、シェーダを回避するためにリモートアバタのライトをオフにする、カスタムアニメーションを許可しない、などを決定することができる。いくつかの実施形態では、これらの各オプションは、リモートプレーヤがどの程度信頼されているかに基づいて設定されてもよい。例えば、ユーザアカウントは、友人のアバタがフルの機能を有することを許可し、一方、他の人は基本的なアバタ機能のみしか表示することができない。

【0069】

ユーザインタフェースサービス１０８はまた、特定のリモートプレーヤをミュートまたはブロックするオプションも提供することができる。さらに、ユーザインタフェースサービス１０８は、パニックモードまたはセーフモード２１０を提供し、友人以外の人物を音声および視覚的にミュートすることができる。

【0070】

クイックメニュー２０２はまた、よく使うアクションを便利な場所で提供するためのクイックアクション２０６セクションを含めることもできる。いくつかの例示的なクイックアクションは、ホームワールドに移動するアクション、あなたが最後にいたワールドから再開するアクション、他のユーザのアバタを選択するアクション（個人的に通信するため、アバタまたはその他の機能をコピーするため）、および、ユーザとローカルプレーヤ１１６との間のインタラクションのオンまたはオフに切り替えるインタラクショントグル２１６を含む。

【0071】

クイックメニュー２０２はまた、他の機能の中でも特に、仮想カメラ、音量設定、設定メニューなどのいくつかの一般的な機能にもアクセスを提供するドック２１２を含む。

【0072】

本技術のこの説明を通して、アバタ、ユーザ、およびユーザアカウントについて言及する。アバタは仮想環境におけるユーザの表現であり、アバタに帰属する構成は、アバタに適用されるユーザアカウントに帰属する構成である場合があることは、当業者には理解されるであろう。したがって、アバタという用語は、場合によっては、ユーザアカウントの一態様を説明している場合がある。どの用語が使用されるかにかかわらず、適切な意味は当業者には理解されるであろう。

【0073】

図３は、第１のアバタおよび第２のアバタとの衝突に応答してアクションをトリガするための例示的な方法を示す。例示の方法は特定の動作シーケンスを示すが、シーケンスは本開示の範囲から逸脱することなく変更され得る。例えば、示される動作のいくつかは、並行して実行されてもよいし、方法の機能に実質的に影響を与えない異なる順序で実行されてもよい。他の例では、本方法を実施する例示的な装置またはシステムの異なる構成要素は、実質的に同時に、または特定の順序で機能を実行してもよい。

【0074】

上記で紹介したように、本技術は、接触インタラクションを受けたアバタがインタラクションにリアクションすることをサポートすることができる。
いくつかの実施形態では、インタラクションに対するリアクションは、アニメーション、音、または他のエフェクトであり得る。

【0075】

本技術は、ユーザがアバタの部分をコライダとして定義することを可能にするアバタを構築するためのソフトウェア開発キットを含む。いくつかの実施形態では、手や他の付属物の一部など、アバタの部分が自動的にコライダとみなされ得る。本技術はまた、ユーザがアバタの部分をレシーバとして定義することもできる。レシーバは、コライダからの接触をレシーバが受けると、アニメーション、サウンド、その他のエフェクトをトリガすることができる、アバタの部分である。本技術はまた、二次モーション動作を示すように構成されたアバタの部分をユーザが定義することもできる。二次モーション動作は、コライダによる接触によってトリガされるか、またはエフェクトをかけることができる。

【0076】

また、本技術は、図３の方法に記載されるように、コライダとレシーバ間の衝突を検出し、その結果生じるエフェクトを有効にする方法にも関する。

【0077】

いくつかの例によれば、本方法は、ブロック３０２において、第１のアバタに設定されたコライダと第２のアバタに設定されたレシーバとの間の衝突を検出することを含む。例えば、図１に示されるクライアント１０４は、第１のアバタ上に構成されたコライダと第２のアバタ上のレシーバとの間の衝突を検出することができる。第１のアバタは、ローカルアバタ１１８またはリモートアバタ１２６とすることができる。第２のアバタはリモートアバタ１２６とすることができる。言い換えると、衝突はローカルアバタと１つ以上のリモートアバタの間で起こり得るか、または２つ以上のリモートアバタの間で起こり得る。

【0078】

図５Ａおよび図５Ｂに関してより詳細に説明するようないくつかの実施形態では、コライダおよびレシーバは、アバタ間のインタラクションおよび接触に関する相互同意を管理するルールのセットに従ってオンまたはオフにされ得る。

【0079】

いくつかの実施形態では、衝突は、広帯域位相衝突検出システム１４８によって検出することができる。例えば、広帯域位相衝突検出システム１４８は、仮想世界のレンダリングされた領域をグリッドに分割するように構成することができる。一例では、グリッドは、１０ｍ×１０ｍの領域をカバーするグリッド領域とすることができるが、任意の適切な領域を使用することができる。グリッド内の各セルは、各グリッドのグリッド空間内のＸＹＺ座標から作成されたハッシュによって、迅速な検索のために辞書に入力される。各グリッド内で、広帯域位相衝突検出システム１４８は、グリッド内の領域内の軸を横切って順番に配置された全てのオブジェクトの、先入れ先出しメモリ構造内のソートされたリストを作成する。例えば、オブジェクトは、グリッド内の領域内で発生するようにＸ軸に沿って配列され得る。広帯域位相衝突検出システム１４８は、オブジェクトがソートされた順序で一度に１つずつ評価することにより、各オブジェクトが衝突に関与しているか否かを判定する。オブジェクトを評価することは、オブジェクトが衝突の影響を受ける性格のものであるか否かを判定することを含むことができる。例えば、オブジェクトがコライダでもレシーバでもない場合、衝突はそのオブジェクトには無関係である可能性があり、そのオブジェクトの処理を中止することができる。しかし、オブジェクトが衝突の影響を受ける可能性がある場合、広帯域位相衝突検出システム１４８は、オブジェクトが他のオブジェクトと重なる可能性があるか、または他のオブジェクトによって重ねられているかを判定する。

【0080】

いくつかの実施形態では、クライアント１０４による衝突の検出は、衝突に関連する物理的属性を決定することも含み得る。例えば、衝突が広帯域位相衝突検出システム１４８によって検出されると、クライアント１０４は、衝突に関連する物理的属性を決定することができる。物理的属性は、衝突するオブジェクトの力、速度、質量などの物理的力などの属性を含み得る。いくつかの実施形態では、アクションは物理属性に依存し得る。例えば、衝突がハイタッチ動作の結果であった場合、効果音は、コライダが閾値以上の速度で移動している場合にのみ生成され得る。

【0081】

いくつかの実施例によれば、本方法は、ブロック３０４において、接触を受けたプレーヤに検出された衝突を報告することを含む。例えば、図１に示されるクライアント１０４上で実行される広帯域位相衝突検出システム１４８は、検出された衝突を、図１に示されるローカルプレーヤ１１６またはリモートプレーヤ１２４などのアバタコントローラに報告してもよい。

【0082】

いくつかの例によれば、本方法は、ブロック３０６において、検出された衝突に応答して、レシーバに関連付けられたアバタ上のパラメータを更新することを含む。例えば、図１に示すローカルプレーヤ１１６またはリモートプレーヤ１２４などのアバタコントローラは、検出された衝突に応答して、レシーバに関連付けられたアバタ上のパラメータを更新することができる。例えば、リモートプレーヤ１２４が接触インタラクションのレシーバである場合、リモートプレーヤ１２４は、リモートアバタ１２６上のパラメータを更新することができる。いくつかの実施形態では、パラメータは、衝突が発生したことを示すバイナリパラメータとすることができる。いくつかの実施形態では、パラメータは、コライダのタイプ、衝突の物理（オブジェクトの一方の速度または衝突の力など）など、接触インタラクションの属性を記述することができる。

【0083】

レシーバは、レシーバがアクティブになったときに実行される関連する応答にリンクさせることができる。応答は、アバタパッケージの一部であるデータまたはアルゴリズムで具体化することができる。レシーバに関連付けら得る非限定的な例または応答は、アニメーションを再生させること、効果音を再生させること、または、状態を変化させることであり得る。例えば、２つのアバタ間のハイタッチのインタラクションでは、アバタの１つ上のレシーバは、平手打ち音をトリガしたり、カスタム変化や外観変化をアニメーション化したり、任意のタイプのアニメーションをトリガするように構成され得る。応答はアバタのパラメータの更新を通じてトリガされ得る。

【0084】

いくつかの実施形態では、衝突の当事者間の相互同意は、衝突がアバタコントローラ（ローカルプレーヤ１１６またはリモートプレーヤ１２４など）に報告された後、パラメータ変更がアバタ（ローカルアバタ１１８またはリモートアバタ１２６）に報告される前に確認され得る。

【0085】

いくつかの例によれば、相互同意がある場合、本方法はブロック３０８においてアクションをトリガすることを含む。例えば、図１に示されるクライアント１０４がアクションをトリガしてもよい。いくつかの実施形態では、アクションは、アバタ（ローカルアバタ１１８またはリモートアバタ１２６）に関連付けられたデータおよびパラメータに基づいてアバタをアニメーション化するアニメーションコントローラによってトリガされる。レシーバに関連付けられ得るいくつかの非限定的な例または応答は、アニメーションを再生させること、効果音を再生させること、または状態変更を発生させることであり得る。

【0086】

いくつかの例によれば、本方法は、判定ブロック３１０において、アクションが第２のアバタの永続的な状態変更に関連しているかどうかを判定することを含む。例えば、図１に示されるクライアント１０４は、アクションが第２のアバタの永続的な状態変更に関連付けられているかどうかを判定することができる。永続的な状態変更は、再生されたアニメーション以上の何らかのアクションを含むことができる。例えば、アバタは、その外観を変更することができ（プレーヤまたは別のインタラクションによって変更されるまで、または設定された持続時間の間、持続的に）、その変更された外観とのインタラクションを継続することができる。

【0087】

いくつかの例によれば、本方法は、ブロック３１４において、第１のアバタおよび第２のアバタをレンダリングするアプリケーションのリモートインスタンスに状態変更通知を送信することを含む。例えば、図１に示されるクライアント１０４は、ネットワーキングサービス１１２を介して、第１のアバタおよび第２のアバタをレンダリングするアプリケーションのリモートインスタンスに状態変更通知を送信することができる。

【0088】

図４は、アバタの部分の二次モーションに影響を与えるインタラクションをサポートするための例示的な方法を示す。例示の方法は特定の動作シーケンスを描いているが、本開示の範囲から逸脱することなくシーケンスは変更され得る。例えば、示される動作のいくつかは、並行して、または方法の機能に実質的に影響を与えない異なる順序で実行されてもよい。他の例では、本方法を実施する例示的な装置またはシステムの異なる構成要素は、実質的に同時に、または特定の順序で機能を実行してもよい。

【0089】

いくつかの例によれば、本方法は、ジョブシステムの一部として１つ以上のジョブをインスタンス化することを含む。ジョブは、衝突の評価、衝突の結果としての二次モーション動作の決定などのタスクの処理を担うことができる。ジョブシステムは、より大きなゲーム環境（仮想世界）をレンダリングするために使用されるプライマリスレッド以外の１つ以上のスレッドにジョブを割り当てることによって、そのタスクを実行することができる。ジョブは、プライマリスレッド以外のスレッド上で実行するために実行時にコンパイルされ得る。いくつかの実施形態では、ジョブの作成は、ＵＮＩＴＹレンダリングエンジンのＢＵＲＳＴ ＣＯＭＰＩＬＩＮＧ機能を利用して実行される。

【0090】

ジョブの実行は、ジョブシステムによって処理され、ジョブシステムは、ジョブが実行される順序に独自の優先順位を割り当てる。したがって、いくつかの実施形態では、クライアント１０４は、フレームがレンダリングされる必要があるときに、ジョブがジョブシステムによって完了されたことをチェックすることができる。ジョブが完了していない場合、本方法は、ジョブを終了するようにジョブシステムに指示することを含む。

【0091】

いくつかの例によれば、本方法はブロック４０２でアバタのパラメータをロードすることを含む。例えば、図１に示すクライアント１０４は、アバタ（例えば、リモートアバタまたはローカルアバタ１１８）のパラメータをロードすることができる。図１に関して述べたように、アバタはアバタアセットによって定義することができる。アバタアセットは、アバタをレンダリングするために必要なテクスチャ、モデル、およびアニメーションデータのすべてを含む単一のバイナリファイルである。いくつかの例では、パーティクルシステムや光源に関するデータ、アバタが仮想世界で確立された物理法則に従うべきか逆らうべきか、アバタが非標準的な動きのダイナミクスを持つ場合など、より複雑な機能を含めることができる。アバタアセットは、コライダおよびレシーバとして指定されるアバタの部分を定義することもできる。アバタアセットはまた、二次モーション動作を設定するアバタの部分を定義することもできる。アバタアセットは、人型アバタまたは非人型アバタの完全な骨格を定義することができ、アバタの任意の部分をコライダまたはレシーバとして構成することができる。さらに、アバタの任意の部分に二次モーション動作を設定することができる。ただし、二次モーション動作は、典型的には、アバタの可撓性または柔軟性の部分にのみ使用され、剛性のオブジェクトは、ほとんどの接触インタラクションのような小さな力に反応して知覚可能な動きで反応する可能性が低いため、アバタの主骨格のような剛性のオブジェクトには通常使用されない。

【0092】

アバタの二次モーションのために構成される部分は、トランスフォームのツリーによって定義される。例えば、トランスフォームのルートはアバタの頭部とすることができ、ルートからの枝には髪の束（または髪の束の集合体）を含めることができる。髪の束は、複数の追加の枝によって表すことができる。各枝は、トランスフォームのツリーに関連付けられたアバタの部分が引っ張られるかどうか、バネのような特性を持つかどうか、慣性力にどの程度影響されやすいか、重力の影響をどの程度受けるべきかなど、さまざまな特性に関連付けることができる。いくつかの実施形態では、トランスフォームは実行時にコンパイルされるように構成される。二次モーション動作を示すアバタの部分を定義するトランスフォームのツリーに関する詳細については、図１０および図１１を参照して説明される。

【0093】

いくつかの例によれば、本方法は、ブロック４０４において、二次モーション動作を示すように構成されたアバタの部分を含むアバタのパラメータをメモリに記憶することを含む。例えば、図１に示すクライアント１０４は、アバタの部分のパラメータを、ジョブシステムによってアクセス可能なメモリに記憶してもよい。

【0094】

いくつかの実施形態では、二次モーション動作を示すアバタの部分を定義するトランスフォームに関する情報を記憶するメモリ構造は、マルチコアプロセッサの複数のコア上で実行されるジョブシステムによって制御されるスレッドによってアクセス可能なメモリ構造に記憶される。いくつかの実施形態では、メモリ構造は、ＵＮＩＴＹによって提供されるＮＡＴＩＶＥ ＣＯＮＴＡＩＮＥＲのようなフラットメモリ構造である。ＮＡＴＩＶＥ ＣＯＮＴＡＩＮＥＲでは、ジョブを実行するセカンダリスレッドと、仮想世界とその中のオブジェクトのレンダリングを担当するメインスレッドによるデータへのアクセスを可能にする。

【0095】

いくつかの例によれば、本方法は、ブロック４０６において、アバタが接触を受け入れるように構成されたアクティブな接触アクセプタを有することを検出することを含む。例えば、図１に示すクライアント１０４は、アバタが接触を受け入れるように構成されたアクティブ接触アクセプタを有することを検出することができる。

【0096】

いくつかの実施形態では、接触アクセプタは、指定されたコライダからのインタラクションのみを受け取るように構成される。指定されたコライダは、指や手のコライダなどのコライダのクラスであってもよい。指定されたコライダは特定のアバタ上にあってもよく、指定されたコライダは人型アバタなどのアバタのカテゴリ上にあってもよい。

【0097】

いくつかの例によれば、本方法は、ブロック４０８において、コライダと、二次モーション動作を示すように構成されたアバタの部分との間のインタラクションを検出することを含む。例えば、図１に示されるクライアント１０４は、コライダと、二次モーション動作を示すように構成されたアバタの部分との間のインタラクションを検出してもよい。

【0098】

いくつかの実施形態では、コライダと、二次モーション動作を示すように構成されたアバタの部分との間のインタラクションの検出は、フレームごとに行われる。コライダと、二次モーション動作を示すように構成されたアバタの部分との間のインタラクションの検出は、図３に関して取り上げた広帯域位相衝突検出システム１４８によって実行され得る。広帯域位相衝突検出システムはまた、ジョブシステムの制御下にあるジョブによって処理することもできる。衝突ジョブは、衝突の近似を決定するだけであり、二次モーションに影響を与えることは保証されない。衝突ジョブによって検出された可能性のある衝突は、コライダが二次モーション動作を示すように構成されたアバタの部分に実際に接触しているかどうか、および結果として動く必要があるかどうかを実際に決定する二次モーションジョブに渡すことができる。これは、効率的な理由のためであり、衝突データは動きの計算にも必要とされるので、衝突データの全てを二次モーションジョブの内部に有する方が速いからである。

【0099】

いくつかの例によれば、設定された二次モーションに従ってコライダによって動くように操作されるとき、二次モーション動作を示すように構成されたアバタの部分のモーションをアニメーション化する前に、この方法は、判定ブロック４１０において、アニメーション化されたモーションを許可するために第１のアバタおよび第２のアバタのペアの間に相互同意があるかどうかを判定することを含む。例えば、図１に示されるクライアント１０４は、アニメーション化されたモーションを許可するために第１のアバタおよび第２のアバタのペアの間に相互同意があるかどうかを判定することができる。相互同意に関するさらなる詳細は、図５Ａおよび図５Ｂに関して説明される。アバタ間の相互同意がない場合、方法は４１２で終了する。

【0100】

いくつかの例によれば、アバタ間に相互同意がある場合、本方法は、ブロック４１４において、検出されたインタラクションをアバタコントローラに報告することを含む。例えば、広帯域位相衝突検出システム１４８は、検出されたインタラクションをローカルプレーヤ１１６またはリモートプレーヤ１２４などのアバタコントローラに報告することができる。

【0101】

いくつかの例によれば、この方法は、ブロック４１６において、コライダと、二次モーション動作を示すように構成されたアバタの部分との間のインタラクションが、トランスフォームのツリーの物理シミュレーションをトリガすることを判定することを含む。例えば、図１に示されるクライアント１０４は、コライダと、二次モーション動作を示すように構成されたアバタの部分との間のインタラクションが、トランスフォームの物理シミュレーションをトリガすると判定することができる。

【0102】

いくつかの例によれば、本方法は、判定ブロック４１８において、インタラクションがグラブ（ｇｒａｂ：掴む）インタラクションであるかどうかを判定することを含む。例えば、図１に示されるクライアント１０４は、インタラクションがグラブ（掴む）インタラクションであるかどうかを判定することができる。グラブ（掴む）インタラクションは、アバタの部分が掴むことを可能と指定されたときに発生し得る。

【0103】

インタラクションがグラブ（掴む）である場合、いくつかの例によれば、本方法は、ブロック４２０において、掴まれたアバタの部分に対する制御を割り当てることを含む。例えば、図１に示されるクライアント１０４は、掴まれたアバタの部分に対する制御を割り当てることができる。掴まれたアバタの部分は、アバタの部分が掴まれた位置にアタッチメントポイントを有する。グラブ（掴む）が発生したことを報告する情報は、ネットワークを介してクライアント１０４のリモートインスタンスにも送信される。グラブ（掴む）のインタラクションに関するさらなる詳細は、図１０に関して扱われる。

【0104】

いくつかの例によれば、本方法は、ブロック４２２において、設定された二次モーションに従って、コライダによって動くように操作されるアバタの部分のモーションをアニメーション化することを含む。例えば、図１に示されるクライアント１０４は、（トランスフォームのツリーによって構成される）構成された二次モーションに従って、コライダによって動くように操作されるアバタの部分のためのモーションをアニメーション化することができる。ジョブの実行は、局所物理を利用する。局所物理は、コライダとトランスフォームのツリーのプロパティとの間のインタラクションに限定され、仮想世界の他のオブジェクトに影響を与えない。上述のように、ジョブはメインスレッド以外のスレッド上で実行され、設定された二次モーションに従ってコライダによって動くように操作されるとき、アバタの部分の動きのアニメーションをもたらす。

【0105】

いくつかの実施形態では、二次モーション動作を示すように構成されたアバタの部分は、コライダによる操作の結果として、ピン止めされた状態のままにすることができる。いくつかの例によれば、本方法は、判定ブロック４２４において、アバタの部分がピン止めされたかどうかをジャン判定することを含む。例えば、図１に示されるクライアント１０４は、アバタの部分がピン止めされた状態のままであったかどうかを判定することができる。二次モーション動作を示すように構成されたアバタの部分は、コライダを有するアバタがアバタの部分をピン止めするためのトリガ入力を押したときに、ピン止めされた状態のままにすることができる。

【0106】

いくつかの例によれば、本方法は、ブロック４２８において、第１のアバタおよび第２のアバタをレンダリングするアプリケーションのリモートインスタンスに、状態変更に関する情報とともに状態変更通知を送信することを含む。例えば、図１に示すクライアント１０４は、第１のアバタおよび第２のアバタをレンダリングするアプリケーションのリモートインスタンスに、状態変更に関する情報とともに状態変更通知を送信することができる。例えば、状態変更に関する情報は、アバタの部分のピン止め状態に関する情報、またはアバタの部分が掴まれたこと、およびどのアバタがその部分を制御しているかに関する情報であり得る。

【0107】

いくつかの例によれば、本方法は、ブロック４２６においてアバタの部分がピン留めされていないと判定された場合、アバタの部分を元の状態に戻すことを含む。例えば、図１に示されるクライアント１０４は、アバタの部分がピン留めされていないと判定されたときに、アバタの部分を元の状態に戻すことができる。

【0108】

図４は、第１のアバタが第２のアバタとインタラクションするという文脈で説明されてきたが、二次モーション動作を示すように構成されたアバタの部分の操作は、同じアバタからであり得る。いくつかの実施形態では、アバタは自分の髪、尻尾、耳、衣服などを操作するために自分の手を使うことを望む場合がある。図４に関して説明したすべての態様は、二次モーション動作を示すように構成されたアバタの部分が自己とのインタラクションまたはアバタ同士のインタラクションによって操作される場合にも、自己とのインタラクションの場合には相互同意が必要でないことを除いて、同じように機能する。

【0109】

図５Ａ、図５Ｂ、および図５Ｃは、アバタ接触インタラクションが許可されているかどうかを判定するための例示的な方法を示す。例示的な方法は動作の特定のシーケンスを示すが、シーケンスは、本開示の範囲から逸脱することなく変更され得る。例えば、示される動作のいくつかは、並行して実行されてもよいし、方法の機能に実質的に影響を与えない別の順序で実行されてもよい。他の例では、本方法を実施する例示的な装置またはシステムの異なる構成要素が、実質的に同時に、または特定の順序で機能を実行してもよい。

【0110】

本技術は、アバタまたはアバタの部分同士のインタラクションを支援するためのものである。また、本技術は、インタラクションの参加者双方がインタラクションに同意していることを保証するためのメカニズムも提供する。接触インタラクションがアバタによってサポートされるからといって、ユーザが自分のアバタに触れられることを望んでいることを意味するわけではない。バーチャルリアリティ環境の性質は、ユーザは自分のアバタと密接に結びついていることである。多くの場合、ユーザは一人称視点で世界を見ることを選択するため、あるアバタが別のアバタに触れるインタラクションは、一人称視点での接触として認識され得る。ユーザにとって、その接触は現実の生活と同じように認識され得る。現実世界では歓迎されない接触があるように、仮想世界でも歓迎されない接触がある。したがって、本技術は、接触に対するユーザの同意を宣言し、接触が望まれない場合には接触を無効にする安全な枠組みを提供する。重要なことは、接触するすべての当事者から同意が得られなければならないことである。

【0111】

いくつかの例によれば、本方法は、ブロック５０２において、ワールドインスタンス内の第１のユーザおよび少なくとも１人の第２のユーザのアバタ接触設定を受信することを含む。例えば、図１に示されるクライアント１０４は、ワールドインスタンスにおいて、第１のユーザおよび少なくとも１人の第２のユーザのアバタ接触設定を受信することができる。

【0112】

アバタの接触設定には、接触カテゴリが含まれる。すべてのプレーヤは、接触カテゴリを使用して、接触を許可するかしないかをユーザプロファイルで設定する。コンテンツカテゴリは、（１）すべてのアバタとのアバタ接触インタラクションを許可する、（２）友達リスト内のアバタとのみアバタ接触インタラクションを許可する、（３）すべてのアバタ接触インタラクションを許可しない、である。

【0113】

アバタ接触設定はまた、接触カテゴリに起因して行われるいかなる判定からも除外される特定のユーザ／アバタを指定するための許可リストおよびブロックリストを含む。例えば、ローカルユーザの許可リストにあるユーザは、リモートユーザの設定がそのインタラクトを許可している場合、ローカルユーザのアバタとインタラクトすることが断定的に肯定的に許可される。同様に、ローカルユーザのブロックリストにあるユーザは、接触カテゴリが通常インタラクションを許可している場合であっても、ローカルユーザのアバタとインタラクションすることを断定的に許可されない。指定されたアバタの許可リストとブロックリストは、接触カテゴリを上書きする。

【0114】

ユーザアカウントに設定された任意の接触設定にかかわらず、ユーザアカウントはまた、図２に示されたインタラクショントグル２１６を使用して、他のすべてのアバタとのインタラクションのオン／オフを切り替えることもできる。したがって、他のすべてのアカウントとインタラクションする、またはすべての友達とインタラクションするユーザアカウント設定を持つユーザアカウントでも、インタラクショントグル２１６を利用して、接触インタラクションをすばやくオフにすることができる。インタラクショントグル２１６は、インタラクションをオフにするためにユーザアカウントに関連する任意の他の接触設定を上書きすることができるが、インタラクショントグル２１６が接触インタラクションを許可するように設定されている場合、許可されるインタラクションは、ユーザアカウント用に設定されたインタラクションによって制限される。

【0115】

いくつかの例によれば、この方法は、判定ブロック５０４において、アバタ接触インタラクションを許可するためにアバタのペアの間に相互同意があるかどうかを判定することを含む。例えば、図１に示されるクライアント１０４は、アバタ接触インタラクションを許可するために、ユーザのペアの間に相互同意があるかどうかを判定することができる。相互同意が存在するかどうかの判定は、ユーザがワールドに参加またはワールドから退出するたびに、またはワールド内のいずれかのユーザがアバタ設定または接触インタラクション設定を変更するたびに、更新される。いくつかの実施形態では、相互同意があるかどうかの判定は、アバタにインタラクションが設定されているかどうかを考慮せずに実行される。ユーザはいつでも自分のアバタを変更することができるが、ユーザがワールドを退出するか、またはワールドに参加することによって、相互同意の判定が更新されるまで、同意は同じままである。

【0116】

相互同意があるかどうかの判定は、ユーザのペアの接触設定の組み合わせの積である。図６は、サポートされる接触インタラクションを許可するために、ペア内のユーザ間に相互同意があるかどうかを判定する例示的な方法を示す。この方法は、最初に、判定ブロック６０２において、ペア内の第１のユーザが、ペア内の第２のユーザとの接触を許可するかどうかを判定する。次いで、本方法は、判定ブロック６０４において、ペア内の第２のユーザが第１のユーザとの接触を許可するか否かを判定する。判定ブロック６０２と判定ブロック６０４の両方に対する答えがイエスである場合、そのときだけ、ブロック６０６において接触インタラクションが許可される。判定ブロック６０２または判定ブロック６０４のいずれかに対する答えがノーであれば、ブロック６０８において接触インタラクションは許可されない。図６（および図５Ａ、図５Ｂ、および図５Ｃに関連する議論の多く）は、インタラクションするユーザのペアに関するものであるが、これは、特定の接触インタラクションに参加できる多くのユーザに拡大できることが理解されるべきである。接触インタラクションの一部となるべきいずれかのユーザが、インタラクションの他の当事者との接触インタラクションを許可しない場合、ユーザのグループは、その接触インタラクションに一緒に関与することができない。

【0117】

いくつかの例によれば、本方法は、判定ブロック５０６において、アバタのペア内のアバタのいずれかがアバタ接触インタラクションに関連付けられたレシーバを用いて構成されているかどうかを判定することを含む。例えば、図１に示されるクライアント１０４は、アバタのペア内のアバタのどちらかが、アバタ接触インタラクションに関連付けられたレシーバを用いて構成されているかどうかを判定することができる。このステップは、ローカルワールド内のすべてのアバタのペアに対してクライアント１０４によって実行される。このステップの目的は、インタラクションできるアバタのペアをすべて特定することである。いくつかの実施形態では、効率上の理由から、このステップは、クライアント１０４が視野内にレンダリングされていないワールド内のアバタのアニメーションをレンダリングしないため、ワールドインスタンス内でクライアント１０４によって実際にレンダリングされているアバタに対してのみ実行され得る。判定ブロック５０６において、アバタのペア内のどちらのアバタも、二次モーション動作を示すように構成されたレシーバまたはアバタの部分を有していないと判定されたとき、どちらのアバタも接触インタラクションを受信する方法を持たないので、クライアント１０４は、ブロック５０８において、そのアバタのペアの間には接触インタラクションが存在しないと判定することができる。

【0118】

事実上、判定ブロック５０６は、アバタのペアのうちいずれかのアバタが接触インタラクションをサポートしているかどうかを判定するために使用される。

【0119】

上述したように、図３に関して、クライアント１０４はアバタのインタラクションをローカルに検出し、アニメーション化する役割を果たすので、クライアント１０４はリモートアバタに関連して受信した入力を制御することができないが、２つのリモートアバタ間またはローカルアバタ１１８とリモートアバタ１２６間のインタラクションに起因して、リモートアバタに対して任意のアニメーションまたはエフェクトが再生されるべきかどうかを決定する役割を果たす。

【0120】

図７は、例示的な接触設定と、それらの設定によって接触インタラクションが許可されるか否かの例示的なテーブルを示す。

【0121】

行７０２において、両方のユーザが、すべてのインタラクションを許可するように接触カテゴリが設定され、このため、両方のユーザがすべての他者とのインタラクションを許可しているので、そのユーザが友人とみなされるかどうかは問題ではない。接触は許可される。

【0122】

行７０４において、一方のユーザは友達との接触インタラクションのみを許可し、他方のユーザはすべてのユーザとのインタラクションを許可している。ユーザは友達ではない（例えば、ユーザアカウントの友達リストにない）ため、インタラクションは許可されない。しかし、行７０６においては、同じユーザの接触カテゴリ設定でも、ユーザは友達であるため、接触インタラクションは許可される。

【0123】

行７０８において、ユーザのうちの１人が接触インタラクションを許可していないので、他のユーザの設定は無関係である。接触インタラクションは許可されない。

【0124】

行７１０において、第１のユーザは、第２のアバタに関連付けられたユーザアカウント以外の任意のユーザとの接触インタラクションを許可する。したがって、第１のユーザは第２のユーザとの接触インタラクションを許可しないので、接触は許可されない。

【0125】

行７１２において、第１のユーザは、第２のアバタに関連付けられたユーザアカウント以外のどのユーザとの接触インタラクションも許可しない。第２のアバタはすべてのインタラクションを許可している。したがって、両方のアバタが互いに接触インタラクションを許可しているので、接触が許可される。

【0126】

行７１４において、第１のユーザは、第２のアバタに関連付けられたユーザアカウント以外のいかなるユーザとの接触インタラクションも許可しない。第２のユーザは、第１のアバタに関連付けられたユーザアカウント以外のいかなるアバタとも接触インタラクションを許可しない。したがって、両方のユーザが互いに接触インタラクションを許可しているため、接触が許可される。

【0127】

図５Ａの議論に戻ると、これまで、特定のユーザ間で接触インタラクションが許可されるかどうかの判定がクライアント１０４によって行われるものとして説明してきたが、いくつかの実施形態では、アバタ接触インタラクションを許可するためにユーザのペア間で相互同意があるかどうかの判定は、モデレーションサービス１４２または別のサービスなどのネットワークサービスによって行うことができる。

【0128】

いくつかの実施形態では、相互同意がないアバタのペアが互いに閾値距離内にあるときに、目に見えない境界を作成して、接触インタラクションが試みられることさえないように確実にすることができる。いくつかの実施形態では、インタラクションが許可されていないリモートアバタは、リモートアバタが閾値の距離に近づくと、シーンのローカルプレーヤのビューから削除することができる。

【0129】

いくつかの例によれば、本方法は、ブロック５１０において、ワールドインスタンス内のアバタの個々のペア間で接触インタラクションが許可されているかどうかの判定を記憶することを含む。例えば、図１に示すクライアント１０４は、ワールドインスタンス内のアバタの個々のペア間で接触インタラクションが許可されているかどうかの判定を記憶してもよい。例えば、ワールドインスタンス内の任意のペアのアバタの間で接触インタラクションが許可されているかどうかの判定が行われると、これをテーブルに記録して、後の判定およびブロック５１２での使用のために保存することができる。

【0130】

いくつかの例によれば、本方法は、ブロック５１２において、アバタ接触インタラクションがローカルアバタとインジケータに関連付けられたリモートアバタとの間で許可されているかどうかを示すアバタ接触インタラクションステータスを示す、少なくとも１つのリモートアバタに関連付けられたインジケータを表示することを含む。例えば、図１に示されるクライアント１０４は、アバタ接触インタラクションステータスを示す少なくとも１つのリモートアバタに関連付けられたインジケータを表示することができる。いくつかの実施形態では、ローカルアバタ１１８がローカルアバタに関連付けられたユーザとインタラクションすることができるリモートアバタ１２６を識別することは有用であり得る。例えば、何の表示もないと、ローカルアバタ１１８をコントロールするユーザは、接触インタラクションをサポートしないか、ローカルアバタとの接触インタラクションを許可しないリモートアバタとの接触インタラクションに参加しようとして動き回るかもしれない。これにより、ユーザ体験が低下する可能性がある。したがって、接触インタラクションをサポートし、ローカルアバタ１１８が接触インタラクションに関与することを許可するリモートアバタは、ローカルアバタ１１８に関連付けられたユーザに識別され得る。インジケータは、リモートアバタ１２６に関連するネームプレイトのシンボルまたは色とすることができる。インジケータは、リモートアバタ１２６がローカルアバタ１１８との接触インタラクションを許可するときに、リモートアバタ上のレシーバの位置が強調表示されるか、または他の方法で示されることとすることができる。いくつかの実施形態では、リモートアバタ１２６に関連するインジケータは、アバタ接触インタラクションが許可されていないことも示すことができる。

【0131】

いくつかの例によれば、本方法は、ブロック５１４において、第１のアバタ上に構成されたコライダと第２のアバタ上のレシーバとの間の衝突を検出することを含む。例えば、図１に示されるクライアント１０４は、第１のアバタ上に構成されたコライダと第２のアバタ上のレシーバとの間の衝突を検出することができる。衝突は、図３のブロック３０２に関して説明したのと同様の内容で、広帯域位相衝突検出システム１４８によって検出することができる。

【0132】

いくつかの例によれば、本方法は、ブロック５１６において、検出された衝突をアバタコントローラに報告することを含む。例えば、図１に示されるクライアント１０４は、検出された衝突をアバタコントローラに報告することができる。

【0133】

この方法は、図５Ｂのブロック５１８に続く。

【0134】

いくつかの例によれば、本方法は、ブロック５２２において、ローカルアバタ上に設定されたコライダとリモートアバタ上のレシーバとの間の衝突を検出した後、ユーザのペア間に相互同意があることを確認することを含む。例えば、図１に示されるクライアント１０４は、ローカルアバタ上に設定されたコライダとリモートアバタ上のレシーバとの間の衝突を検出した後、ユーザのペア間に相互同意があることを確認することができる。判定ブロック５０４で相互同意は既に判定されたが、いくつかの実施形態では、クライアント１０４は、アクションをトリガする前に、相互同意がまだ存在することを確認してもよい。

【0135】

いくつかの例によれば、ユーザのペア間に相互同意が存在しない場合、本方法は、ブロック５３２において、アバタ接触インタラクションに関連するプロセスを終了することを含む。例えば、図１に示されるクライアント１０４は、アバタ接触インタラクションに関連するプロセスを終了することができる。

【0136】

いくつかの実施形態では、相互同意がないアバタのペアが互いに閾値距離内にあるときに、目に見えない境界を作成して、接触インタラクションが試みられることさえないように確実にすることができる。いくつかの実施形態では、インタラクションが許可されていないリモートアバタは、リモートアバタが閾値の距離に近づくと、シーンのローカルプレーヤのビューから削除することができる。

【0137】

場合によっては、ユーザ設定はまた、どのようなタイプのアニメーションに関与することを望むかを規制することもできる。例えば、ユーザは、接触インタラクションにおいて、他のアバタと関わりたいと思うかもしれないが、下品なコンテンツや示唆的なコンテンツをフィルタリングしたいかもしれない。このような実施形態では、受信者に好まれるアニメーションにはコンテンツフラグがラベル付けされ得る。これは、ユーザの権利、プライバシー、および境界を、コンテンツを受信するユーザの制御下に置くことができる別の方法である。

【0138】

いくつかの例によれば、本方法は、ブロック５２４において、アバタ接触インタラクションに関連するアニメーションにコンテンツフラグがラベル付けされていると判定することを含む。例えば、図１に示されるクライアント１０４は、アバタ接触インタラクションに関連付けられたアニメーションがコンテンツフラグでラベル付けされていると判定することができる。

【0139】

いくつかの例によれば、本方法は、ブロック５２６において、ローカルアバタに関連付けられたユーザアカウントが、コンテンツフラグでコンテンツをフィルタリングする設定に関連付けられていることを判定することを含む。例えば、図１に示されるクライアント１０４は、ユーザアカウントが、コンテンツフラグでコンテンツをフィルタリングする設定に関連付けられていると判定することができる。

【0140】

いくつかの例によれば、本方法は、ブロック５２８において、フィルタリングされたタイプのコンテンツでラベル付けされているために、アバタ接触インタラクションを終了することを含む。例えば、図１に示されるクライアント１０４は、フィルタリングされたタイプのコンテンツでラベル付けされているため、アバタ接触インタラクションを終了することができる。

【0141】

いくつかの例によれば、接触インタラクションが許可され、接触インタラクションから生じるアニメーションがコンテンツフラグの存在に起因してフィルタリングされない場合、本方法は、ブロック５３０においてアクションをトリガすることを含む。例えば、図１に示されるクライアント１０４は、受信者に好まれるアニメーションを再生することによって、または二次モーション動作を示すように構成されたアバタの部分に関連付けられたトランスフォームを実行することによって、アクションをトリガすることができる。

【0142】

図５Ａのブロック５０２においてアバタ設定を受信した後、本方法はブロック５２０に続いて図５Ｃに進み、コンテンツフラグでラベル付けされたコンテンツを処理する代替的および／または追加的な方法を示す。

【0143】

いくつかの例によれば、本方法は、ブロック５３４において、アバタ接触インタラクションに関連付けられたリモートアバタにコンテンツフラグがラベル付けされていると判定することを含む。例えば、図１に示されるクライアント１０４は、アバタ接触インタラクションに関連付けられているリモートアバタにコンテンツフラグがラベル付けされていると判定することができる。

【0144】

いくつかの例によれば、本方法は、ブロック５３６において、ローカルアバタが、コンテンツフラグでコンテンツをフィルタリングする設定に関連付けられていることを判定することを含む。例えば、図１に示されるクライアント１０４は、ローカルアバタが、コンテンツフラグでコンテンツをフィルタリングする設定に関連付けられていると判定することができる。

【0145】

いくつかの例によれば、本方法は、ブロック５３８において、コンテンツフラグに関連付けられていない代替リモートアバタをダウンロードすることを含む。例えば、図１に示されるクライアント１０４は、代替アセットを要求するためにアバタＡＰＩ１３６と対話することによって、コンテンツフラグに関連付けられていない代替リモートアバタをダウンロードすることができる。または、いくつかの実施形態では、コンテンツフラグでラベル付けされたアバタアセット内の特定のコンテンツは、コンテンツフラグに関連付けられた部分を除き、リモートアバタの残りの部分およびその機能が完全な状態ではダウンロードされない可能性がある。

【0146】

図８は、１つ以上のコライダで構成されたアバタの部分を示す図である。本技術は、ユーザがアバタの部分をコライダおよびレシーバとして定義できるアバタを構築するためのソフトウェア開発キットを含む。

【0147】

いくつかの実施形態では、アバタのいくつかの部分が自動的にコライダとみなされ得る。本技術はまた、ユーザがアバタの部分をレシーバとして定義することも可能とする。人型アバタや非人型アバタの部分を含め、アバタの任意の部分は、コライダまたはレシーバとして定義され得る。

【0148】

コライダは物理的な衝突の目的でオブジェクトの形状を定義する。一般的に目に見えないコライダは、オブジェクトと全く同じ形状である必要はなく、実際、ゲームプレイでは、大まかな近似の方が効率的であり、見分けがつかないことが多い。いくつかの例では、コライダはソリッドオブジェクトとして振る舞う必要はなく、単に他のコライダを通過させること可能とする。レシーバは、結果としてエフェクトを引き起こすトリガで構成されたコライダであり得る。コライダがその空間に入ると、レシーバに関連付けられたトリガは、レシーバ用に設定されたスクリプトを実行する関数を呼び出す。スクリプトシステムまたは物理エンジンは、衝突がコライダとレシーバとの間で発生したときを検出することができ、アクションを開始することができる。例えば、レシーバは、コライダからの接触をレシーバによって受けたとき、アニメーション、音、または他のエフェクトをトリガすることができる。

【0149】

いくつかの実施形態では、レシーバは、レシーバとインタラクションできるコライダまたはコライダのタイプを制限するタグに関連付けられる。このような実施形態では、アニメーションは、レシーバが指定するタグに一致するコライダからの接触によってのみトリガされ得る。

【0150】

例えば、図８は、指にコライダ８０２ａ、８０２ｂ、８０２ｃ、８０２ｄがあり、手のひらにコライダ８０２ｅがあるアバタの手を示す。コライダは、レシーバで構成されたアバタの、または、二次モーション属性で構成され、コライダによって加えられる力に反応するアバタの、アバタの他の部分にインタラクションを加えるように構成されている。

【0151】

図９Ａは、接触インタラクションに関わる２人のアバタを示す。より具体的には、２人のアバタがハイタッチをしており、第１のアバタの手９０２が第２のアバタの手９０４と接触している。両方の手がコライダで構成されてもよいが、少なくとも一方の手はレシーバで構成される。

【0152】

図９Ｂは、ハイタッチ接触インタラクションが発生した直後の瞬間を示す。手９０６は、パーカッシブバブル（衝撃泡）９０８のアニメーションを描画し、平手打ち音を再生するエフェクトにリンクされたレシーバで構成される。

【0153】

図１０は、コライダとして構成された部分と、二次モーション動作として構成された部分とを有するアバタを示す。例えば、アバタは、コライダ１００８で構成された手１０２０と、コライダ１００２で構成された手１０２２を有する。アバタはまた、二次モーション動作で構成された耳も有する。二次モーション動作は、ボーンのツリーによって提供され、ボーンのツリー内の各ボーンは、トランスフォームにリンクされ得、したがって、トランスフォームのツリーを作成することができる。例えば、ツリーとしてのアバタは、その耳を構成するように変形する。トランスフォームのルートには頭部１０１８があり、第１の骨１０１６、第２の骨１０１４、および第３の骨１０１２が続く。骨１０１６、１０１４、および１０１２のそれぞれは、耳が曲がる、または弾力的である、およびコライダ、慣性、または重力などによって加えられる力に反応することを可能にする特性を耳に提供する、１つ以上のトランスフォームで構成される。

【0154】

図１０に示されるアバタの耳と手はまた、トランスフォームのツリーに加えて、アタッチメントポイントでも構成される。例えば、図１０に示すように、手１０２０はアタッチメントポイント１００６を有し、手１０２２はアタッチメントポイント１００４を有し、アバタの右耳はアタッチメントポイント１０１０を有する。アタッチメントポイントは、オブジェクトを掴むことができる位置として使用され得る。図９において、アバタはアタッチメントポイント１０１０を掴むためのシューズハンド１０２０を有する。

【0155】

図１０に示すアバタは、手１０２０とアタッチメントポイント１０１０の間にスペースを有するが、手１０２０はアタッチメントポイント１０１０によって耳を掴んでいる。このスペースは、アバタを操作するユーザが、耳が動くように設定されているよりも遠くにアバタの手を動かしたという事実の結果である可能性がある。このスペースはまた、手が耳に重なった瞬間にユーザがアタッチメントポイントで耳をつかんだものの、手がいくらか動いた後までアタッチメントをトリガしなかったというアニメーションの遅延の結果である可能性もある。

【0156】

この説明にかかわらず、オブジェクトを掴むために、あるアタッチメントポイントが別のアタッチメントポイントに重なる必要はない場合がある。いくつかの実施形態では、アタッチメントポイント間のアタッチメントは、相対的な近接に基づいてもよく、手９２０のような手が、アタッチメントポイント１０１０で掴まれる耳の真上にあることを必要としなくてもよい。

【0157】

耳がアタッチメントポイント１０１０によって掴まれると、アバタは手を使って耳を様々なポーズに動かすことができ、現実の生活で起こり得たのと同様のエフェクトを提供する。アバタがアタッチメントポイント１０１０で耳を操作し終わったら、アバタは手を開いて耳を放すことができ、その場合、耳はデフォルトの位置に戻るか、アバタを操作するユーザがトリガボタンを押して耳をピン止めし、グラブ（掴む）を離す直前の位置に残すことができる。

【0158】

図１０は、アバタが自分の手を使用して自分の耳を操作する例を示すが、これは説明の便宜のためである。本明細書に記載されるように、別のアバタが自分のアバタのアタッチメントポイントを使用して、アタッチメントポイント１０１０で耳をアタッチメントして、掴むことも同様に可能である。

【0159】

二次モーション動作が設定された耳は、押したり引いたりすることによって操作することもできる。アバタはコライダを使って耳に力を加えることができ、二次モーション動作を示すように設定されたアバタの部分に関連付けられた属性に基づいて反応する。このようにして、アバタは髪、耳、尻尾、衣服、または他のアバタの同じ特徴を動かすことができる。アバタは自分の髪や他のアバタの髪をとかすこともできる。

【0160】

図１０ではアバタの頭部（耳）が二次モーションで構成されている様子を示しているが、これは単なる一例である。任意の部分に二次モーション動作を設定することができる。アバタは、人型アバタまたは非人型アバタの完全な骨格を含むことができ、ユーザ上の様々なコントローラを人型アバタまたは非人型アバタのスケルトンにマッピングして、骨格に一次モーションを行わせることができる。さらに、アバタの任意の部分に二次モーション動作を設定することができる。しかし、二次モーション動作は、典型的には、アバタの可撓性または柔軟性のある部分のために用意されたものであり、剛性のオブジェクトは、ほとんどの接触インタラクションのような小さな力に反応して知覚可能な動きで反応する可能性が低いため、アバタの一次骨格のような剛性のオブジェクトには通常使用されない。二次モーション動作を示すように構成されたアバタの部分の一般的な例としては、髪、耳、尻尾、衣服、皮膚、宝石などのアクセサリが含まれる。

【0161】

図１１は、アバタの部分に二次モーション属性を設定するためのインタフェースの例を示す。この例では、二次モーションは髪に適用される。このインタフェースは、髪のための折りたたまれたトランスフォームのツリー１１０２を含む。このトランスフォームのツリーは、アバタの頭部（Ｈｅａｄ）にそのベースを有し、髪を構成するさらなるボーンは、「髪のベース」（ＨａｉｒＢａｓｅ）という用語の下に折りたたまれる。

【0162】

図１１に示すメニューはまた、毛髪を構成する骨が様々な力に対してどのように反応すべきかを定義するために、ユーザがこれらの力に関連するパラメータを設定することを可能とする。例えば、引っ張る（Ｐｕｌｌ）力１１０４は、毛髪がアタッチメントポイントから引っ張られた場合に毛髪がどのように反応すべきかを定義するように構成され得る。バネ（Ｓｐｒｉｎｇ）力１１０６は、毛髪が引っ張られた後、どのくらい早く元の位置に戻るべきかを定義する。引っ張りは、アバタが髪を掴むことからや、またはアバタが歩いている間の重力などの別の力からであり得る。重力（Ｇｒａｖｉｔｙ）１１０８は、毛髪が重力に対してどの程度反応するかのエフェクトを定義する。弾力のある毛髪は、重くて長い毛髪よりも重力の影響をわずかに受けにくいかもしれない。これらの力および他の力は、真の毛髪を模倣するために所望のモーションダイナミクスを提供するように構成および調整され得る。

【0163】

図１１は、毛髪に設定された二次モーションを示すが、アバタの任意の部分に二次モーションを設定することができる。

【0164】

本技術はアバタ間の接触インタラクションに関して説明したが、本技術はアバタとアバタがインタラクションする環境との間のインタラクションにも適用できる。例えば、ワールドの一部、またはワールド内のオブジェクトは、コライダとレシーバを用いて構成することができ、二次モーション動作を示すように構成することができる。例えば、ユーザがアバタを操作してボールを蹴ることができ、この場合、アバタの足はコライダで構成され、ボールはまたコライダおよび／またはレシーバで構成される。別の例では、ユーザが草地を歩くと、二次モーション動作をするように設定された草が、アバタが草地を歩いたり、アバタが草地で尻尾を振ったりするときに、アバタの動きにより、曲がったり、動いたりすることができる。別の例では、ユーザが自分のアバタの各指にトラッカーを有し、個々の指の動きを十分にトラッキングされ得るようにし、指上の個々のコライダを利用して仮想キーボード上のキーに衝突させ、キーボードやピアノを演奏することを可能としてもよい。

【0165】

アバタとアバタの接触インタラクションに関してと同様に、ワールドまたはワールド内のオブジェクトは、インタラクションのための相互同意が存在する場合にのみ、ユーザアカウントがワールドまたはワールド内のオブジェクトのインタラクション可能な部分とインタラクションできるように、インタラクション許可を用いて構成され得る。

【0166】

したがって、本技術は主にアバタ同士のインタラクションに関して説明されてきたが、本技術は、アバタの一方または両方がオブジェクトまたはワールドの部分と置き換えられる場合にも同様に適用可能である。

【0167】

図１２は、コンピューティングシステム１２００の例を示し、例えば、クライアントデバイス１０６を構成する任意のコンピューティングデバイス、またはウェブサービス１１０、またはシステムの構成要素がコネクション１２０２を使用して互いに通信しているそれらの任意の構成要素であり得る。コネクション１２０２は、バスを介した物理的接続、またはチップセットアーキテクチャのようなプロセッサ１２０４への直接接続とすることができる。コネクション１２０２はまた、仮想接続、ネットワーク接続、または論理接続であってもよい。

【0168】

いくつかの実施形態において、コンピューティングシステム１２００は、本開示において説明される機能が、データセンタ、複数のデータセンタ、ピアネットワーク等内に分散され得る分散システムである。いくつかの実施形態では、説明されるシステム構成要素の１つ以上は、その構成要素が説明される機能の一部または全部をそれぞれが実行する多数のそのような構成要素を表す。いくつかの実施形態では、構成要素は物理デバイスまたは仮想デバイスであり得る。

【0169】

例示的なコンピューティングシステム１２００は、少なくとも１つのプロセッシングユニット（ＣＰＵまたはプロセッサ）１２０４と、読み取り専用メモリ（ＲＯＭ）１２１０およびランダムアクセスメモリ（ＲＡＭ）１２１２などのシステムメモリ１２０８を含む様々なシステム構成要素をプロセッサ１２０４に結合するコネクション１２０２とを含む。コンピューティングシステム１２００は、プロセッサ１２０４と直接接続されるか、プロセッサ１２０４に近接して接続されるか、またはプロセッサ１２０４の一部として統合された高速メモリ１２０６のキャッシュを含み得る。

【0170】

プロセッサ１２０４は、任意の汎用プロセッサと、記憶デバイス１２１４に記憶され、プロセッサ１２０４を制御するように構成されたサービス１２１６、１２１８、および１２２０などのハードウェアサービスまたはソフトウェアサービスと、ソフトウェア命令が実際のプロセッサ設計に組み込まれる特定用途のプロセッサとを含み得る。プロセッサ１２０４は、本質的に、複数のコアまたはプロセッサ、バス、メモリコントローラ、キャッシュなどを含む、完全に自己完結型のコンピューティングシステムであってもよい。マルチコアプロセッサは、対称型であっても非対称型であってもよい。

【0171】

ユーザとの対話を可能にするために、コンピューティングシステム１２００は、発話用のマイクロフォン、ジェスチャまたはグラフィカル入力用のタッチセンシティブスクリーン、キーボード、マウス、モーション入力、発話など、任意の数の入力機構を表すことができる、入力デバイス１２２６を含む。コンピューティングシステム１２００はまた、当業者に公知の多数の出力機構のうちの１つ以上であり得る出力デバイス１２２２を含むことができる。いくつかの例では、マルチモーダルシステムは、ユーザがコンピューティングシステム１２００と通信するために複数のタイプの入力／出力を提供することを可能にすることができる。コンピューティングシステム１２００は、一般に、ユーザ入力およびシステム出力を支配および管理することができる通信インタフェース１２２４を含むことができる。任意の特定のハードウェア配置で動作することに制限はなく、したがって、ここでの基本的な機能は、それらが開発されるにつれて、改良されたハードウェアまたはファームウェア構成に容易に置き換わり得る。

【0172】

記憶デバイス１２１４は、不揮発性メモリデバイスとすることができ、ハードディスク、または、磁気カセット、フラッシュメモリカード、ソリッドステートメモリデバイス、デジタル多用途ディスク、カートリッジ、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、および／またはこれらのデバイスのいくつかの組み合わせなど、コンピュータによってアクセス可能なデータを記憶することができる他のタイプのコンピュータ可読媒体とすることができる。

【0173】

記憶デバイス１２１４は、ソフトウェアサービス、サーバ、サービスなどを含むことができ、そのようなソフトウェアを定義するコードがプロセッサ１２０４によって実行されると、システムに機能を実行させる。いくつかの実施形態では、特定の機能を実行するハードウェアサービスは、その機能を実行するために必要なハードウェア構成要素、例えばプロセッサ１２０４、コネクション１２０２、出力デバイス１２２２等と接続してコンピュータ可読媒体に記憶されたソフトウェア構成要素を含むことができる。

【0174】

説明を明確にするために、場合によっては、本技術は、デバイス、構成要素、ソフトウェアで具現化された方法におけるステップまたはルーチン、あるいはハードウェアとソフトウェアの組み合わせを含む機能ブロックを含む個別の機能ブロックを含むものとして提示され得る。

【0175】

本明細書で説明するステップ、操作、機能、またはプロセスのいずれも、ハードウェアおよびソフトウェアのサービスまたはサービスの組み合わせによって、単独で、または他のデバイスと組み合わせて、実行または実装することができる。いくつかの実施形態では、サービスは、クライアントデバイスおよび／またはコンテンツ管理システムの１つ以上のサーバのメモリに常駐し、プロセッサがサービスに関連付けられたソフトウェアを実行するときに１つ以上の機能を実行するソフトウェアであり得る。いくつかの実施形態では、サービスは、特定の機能を実行するプログラムまたはプログラムの集まりである。いくつかの実施形態では、サービスはサーバとみなすことができる。メモリは、非一時的コンピュータ可読媒体であり得る。

【0176】

いくつかの実施形態では、コンピュータ可読記憶デバイス、媒体、およびメモリは、ビットストリームなどを含むケーブル信号またはワイヤレス信号を含むことができる。しかしながら、言及される場合、非一時的コンピュータ可読記憶媒体は、エネルギー、キャリア信号、電磁波、および信号それ自体のような媒体を明示的に除外する。

【0177】

上述した例による方法は、コンピュータ可読媒体から記憶されるか、そうでなければ利用可能なコンピュータ実行可能命令を用いて実施することができる。このような命令は、例えば、汎用コンピュータ、特定用途コンピュータ、または特定用途処理デバイスに、特定の機能または機能群を実行させるか、そうでなければ構成する命令およびデータを含むことができる。使用されるコンピュータリソースの一部は、ネットワークを介してアクセス可能であり得る。実行可能なコンピュータ命令は、例えば、バイナリ、アセンブリ言語などの中間フォーマット命令、ファームウェア、またはソースコードであってもよい。説明された例による方法中に、命令、使用される情報、および／または作成される情報を記憶するために使用され得るコンピュータ可読媒体の例は、磁気ディスクまたは光ディスク、ソリッドステートメモリデバイス、フラッシュメモリ、不揮発性メモリを備えるＵＳＢデバイス、ネットワーク化された記憶デバイスなどを含む。

【0178】

これらの開示による方法を実施するデバイスは、ハードウェア、ファームウェアおよび／またはソフトウェアを備えることができ、様々なフォームファクタのいずれかを取ることができる。そのようなフォームファクタの典型的な例としては、サーバ、ラップトップ、スマートフォン、小型フォームファクタのパーソナルコンピュータ、パーソナルデジタルアシスタントなどが挙げられる。本明細書で説明する機能はまた、周辺機器またはアドインカードで具現化され得る。このような機能はまた、さらなる例として、単一のデバイス内で実行される異なるチップまたは異なるプロセス間で回路基板上に実装され得る。

【0179】

命令、そのような命令を伝達するための媒体、それらを実行するためのコンピューティングリソース、およびそのようなコンピューティングリソースをサポートするための他の構成は、これらの開示に記載されている機能を提供するための手段である。

【0180】

添付の特許請求の範囲内の態様を説明するために様々な例および他の情報が使用されたが、当業者であればこれらの例を使用して多種多様な実装形態を導出することができるため、このような例における特定の特徴または構成に基づいて特許請求の範囲を限定することは示唆されるべきではない。さらに、いくつかの主題は、構造的特徴および／または方法ステップの例に特有の言語で説明されたかもしれないが、添付の特許請求の範囲に定義される主題は、必ずしもこれらの説明された特徴または動作に限定されないことを理解されたい。例えば、このような機能は、本明細書において特定された構成要素以外の構成要素において、異なるように分配され得るか、または実行され得る。むしろ、記載された特徴およびステップは、添付の特許請求の範囲内のシステムおよび方法の構成要素の例として開示される。

【0181】

態様１。第１のアバタおよび第２のアバタとの間の衝突に応答してアクションをトリガする方法であって、前記第１のアバタに設定されたコライダと前記第２のアバタに設定されたレシーバとの間の衝突を検出することと、前記検出された衝突をアバタコントローラに報告することと、前記レシーバに関連付けられた前記第２のアバタのアクションを決定することと、前記アクションをトリガすることとを含む方法。

【0182】

態様２。前記衝突は、前記第１のアバタおよび前記第２のアバタをレンダリングするアプリケーションのローカルインスタンスによって検出され、前記アクションは、前記アプリケーションの前記ローカルインスタンスによってトリガされる、態様１の方法。

【0183】

態様３。前記アクションが前記第２のアバタの永続的な状態変更に関連するかどうかを判定することと、前記アクションが前記第２のアバタの永続的な状態変更に関連すると判定された場合、前記第１のアバタおよび前記第２のアバタをレンダリングするアプリケーションのリモートインスタンスに状態変更通知を送信することと、をさらに含む、態様１から態様２のいずれかに記載の方法。

【0184】

態様４。前記第２のアバタがローカルアバタまたはリモートアバタであり得る、態様１から３のいずれかに記載の方法。

【0185】

態様５。前記アクションは、効果音を再生すること、またはアニメーションをレンダリングすることである、態様１から４のいずれかに記載の方法。

【0186】

態様６。前記コライダと前記レシーバとの間の前記衝突を前記検出することが、前記衝突に関連する物理的属性を決定することをさらに含み、前記アクションが前記物理的属性に依存し得る、態様１から５のいずれかに記載の方法。

【0187】

態様７。前記アクションをトリガする前に、前記検出された衝突から生じるアクションを許可するために、前記第１のアバタと前記第２のアバタの前記ペアの間に相互同意があるかどうかを判定することをさらに含む、態様１から６のいずれかに記載の方法。

【0188】

態様８。アバタの部分の二次モーションに影響を与えるインタラクションをサポートする方法であって、コライダと前記アバタの前記部分との間のインタラクションを検出することであって、前記アバタの前記部分が二次モーションを有するように設定されている、検出することと、前記検出されたインタラクションをアバタコントローラに報告することと、前記設定された二次モーションに従って前記コライダによって動くように操作される前記アバタの前記部分の動きをアニメーション化することと、を含む方法。

【0189】

態様９。前記アバタの前記部分のパラメータをロードすることと、前記アバタの前記部分の前記パラメータをメモリに格納することと、をさらに含む、態様８の方法。

【0190】

態様１０。前記アバタの部分がトランスフォームのツリーによって定義される、態様８から９のいずれかに記載の方法。

【0191】

態様１１。前記コライダと前記アバタの前記部分との間の前記インタラクションが、前記トランスフォームのツリー内の一つのトランスフォームの物理シミュレーションをトリガすると判定することをさらに含む、態様８から１０のいずれかに記載の方法。

【0192】

態様１２。前記コライダと前記アバタの前記部分との間の前記インタラクションが前記トランスフォームの物理シミュレーションをトリガすると判定された場合、プライマリスレッド以外のスレッドで処理されるジョブであって、前記トランスフォームの前記物理シミュレーションであるジョブを、レンダリングエンジンで作成すること、をさらに含む、態様８から１１のいずれかに記載の方法。

【0193】

態様１３。前記レンダリングエンジンによって前記ジョブが完了したことをチェックすることと、前記ジョブが完了していない場合、前記レンダリングエンジンに前記ジョブを完了するように指示することと、をさらに含む、態様８から１２のいずれかに記載の方法。

【0194】

態様１４。前記トランスフォームが実行時にコンパイルされるように構成され、前記ジョブの前記作成が、プライマリスレッド以外のスレッド上で実行するために実行時に前記トランスフォームをコンパイルすることを含む、態様８から１３のいずれかに記載の方法。

【0195】

態様１５。前記メインスレッド以外の前記スレッドで前記ジョブを実行して、前記設定された二次モーションに従って前記コライダによって動くように操作される前記アバタの前記部分の動きの前記物理シミュレーションをもたらすこと、をさらに含む、態様８から１４のいずれかに記載の方法。

【0196】

態様１６。前記ジョブの前記実行は、局所物理を利用し、局所物理は、前記コライダと前記トランスフォームのツリーの前記特性との間の前記インタラクションに限定される、態様８から１５のいずれかに記載の方法。

【0197】

態様１７。前記メモリは、複数のスレッド上で実行されるジョブによる前記メモリ内のデータへのアクセスをサポートするメモリ構造を含む、態様８から１６のいずれかに記載の方法。

【0198】

態様１８。コライダと前記アバタの前記部分との間の前記インタラクションの前記検出がフレームごとに行われる、態様８から１７のいずれかに記載の方法。

【0199】

態様１９。ローカルアバタに関連付けられたクライアントアプリケーションの第１のインスタンスによって、リモートアバタが接触を受け入れるように構成されたアクティブなレシーバを有することを検出すること、をさらに含む、態様８から１８のいずれかに記載の方法。

【0200】

態様２０。前記検出されたインタラクションがグラブ（掴む）であり、前記方法は、掴まれた前記アバタの前記部分に対する制御を割り当てることであって、掴まれた前記アバタの前記部分は、前記アバタの前記部分が掴まれた位置にアタッチメントポイントを有する、割り当てること、をさらに含む、態様８から１９のいずれかに記載の方法。

【0201】

態様２１。前記アバタの前記部分がピン留めされているかどうかを判定することをさらに含む、態様８から２０のいずれかに記載の方法。

【0202】

態様２２。前記アバタの前記部分がピン留めされていないと判定された場合、前記アバタの前記部分を元の状態に戻すことをさらに含む、態様８から２１のいずれかに記載の方法。

【0203】

態様２３。前記グラブ（掴む）によってアバタの部分にポーズが付けられたと判定することと、前記アバタの前記部分の前記ピン止め状態に関する情報を用いて、前記第１のアバタおよび前記第２のアバタをレンダリングするアプリケーションのリモートインスタンスに状態変更通知を送信することと、をさらに含む、態様８から２２のいずれかに記載の方法。

【0204】

態様２４。前記設定された二次モーションに従って前記コライダによって動くように操作される前記アバタの前記部分の動きをアニメーション化する前に、前記アニメーション化された動きを許可するために前記第１のアバタと前記第２のアバタの前記ペアの間に相互同意があるかどうかを判定することをさらに含む、態様８から２３のいずれかに記載の方法。

【0205】

態様２５。前記レシーバが、指定されたコライダからのインタラクションのみを受信するように構成される、態様８から２４のいずれかに記載の方法。

【0206】

態様２６。前記指定されたコライダは指または手のコライダなどのコライダのクラスであるか、前記指定されたコライダは特定のアバタ上にあるか、または、前記指定されたコライダは、人型アバタなどのアバタのカテゴリ上にある、態様８から２５のいずれかに記載の方法。

【0207】

態様２７。アバタ接触インタラクションが許可されているかどうかを判定する方法であって、ワールドインスタンス内のローカルアバタおよび少なくとも１つのリモートアバタのアバタ接触設定を受信することと、前記ワールドインスタンス内のアバタのペアについて、アバタ接触インタラクションを許可するためにアバタの前記ペアの間に相互同意があるかどうかを判定することと、前記ローカルアバタと前記リモートアバタの間でアバタ接触インタラクションが許可されているかどうかを示すアバタ接触インタラクションステータスを示す、少なくとも１つのリモートアバタに関連付けられたインジケータを表示することと、を含む方法。

【0208】

態様２８。アバタ接触インタラクションを許可するためにアバタの前記ペアの間に相互同意があるかどうかを前記判定することが、クライアントアプリケーションのインスタンス上で行われる、態様２７に記載の方法。

【0209】

態様２９。アバタ接触インタラクションを許可するためにアバタの前記ペアの間に相互同意があるかどうかを前記判定することが、ネットワーク化されたサービスによって実行される、態様２７から２８のいずれかに記載の方法。

【0210】

態様３０。前記アバタ接触設定が、すべてのアバタとのアバタ接触インタラクションを許可する接触カテゴリ、友達リスト内のアバタとのアバタ接触インタラクションのみを許可する接触カテゴリ、およびすべてのアバタ接触インタラクションを許可しない接触カテゴリを含む、態様２７から２９のいずれかに記載の方法。

【0211】

態様３１。前記設定に関連付けられた指定されたアバタの前記リストが前記接触カテゴリを上書きする、態様２７から３０のいずれかに記載の方法。

【0212】

態様３２。前記アバタ接触設定が、アバタ接触インタラクションを許可または不許可にする設定に関連付けられた指定されたアバタのリストを含む、態様２７から３１のいずれかに記載の方法。

【0213】

態様３３。前記ワールドインスタンス内のアバタの前記ペアについて、アバタ接触インタラクションを許可するためにアバタの前記ペアの間に相互同意があるかどうかの判定を、前記リモートアバタに関連付けられたメタデータに格納することをさらに含む、態様２７から３２のいずれかに記載の方法。

【0214】

態様３４。ローカルアバタ上に構成されたコライダとリモートアバタ上のレシーバとの間の衝突を検出することと、検出された衝突をアバタコントローラに報告することと、アバタ接触インタラクションを許可するためにアバタの前記ペア間に相互同意がある場合、レシーバに関連付けられたリモートアバタのアクションを決定することと、前記アクションをトリガすることと、をさらに含む、態様２７から３３のいずれかに記載の方法。

【0215】

態様３５。前記ローカルアバタに設定された前記コライダと前記リモートアバタに設定された前記レシーバとの間の前記衝突を検出した後、アバタの前記ペアの間に相互同意があることを確認することと、前記アクションをトリガすることと、をさらに含む、態様２７から３４のいずれかに記載の方法。

【0216】

態様３６。前記ローカルアバタ上に設定されたコライダと前記リモートアバタ上のレシーバとの間の衝突を検出することと、前記検出された衝突をアバタコントローラに報告することと、アバタ接触インタラクションを許可するためのアバタのペアの相互同意がない場合、前記アバタ接触インタラクションに関連するプロセスを終了するステップと、をさらに含む、態様２７から３５のいずれかに記載の方法。

【0217】

態様３７。いくつかの実施形態では、相互同意がないアバタの前記ペアが互いに閾値距離内にあるときに目に見えない境界が作成されることをさらに含む、態様２７から３６のいずれかに記載の方法。

【0218】

態様３８。システム安全設定がリモートアバタからのアニメーションを禁止していると判定することと、ローカルアバタ上に構成されたコライダとリモートアバタ上のレシーバとの間の衝突を検出することと、前記システム安全設定が前記アバタ接触インタラクションから生じるアニメーションを禁止しているため、前記アバタ接触インタラクションを終了することと、をさらに含む、態様２７から３７のいずれかに記載の方法。

【0219】

態様３９。システム安全性設定がリモートアバタからのアニメーションを禁止していることを判定することであって、アバタ接触インタラクションステータスを示す少なくとも１つのリモートアバタに関連付けられたインジケータが、システム安全性設定の結果としてアバタ接触インタラクションが許可されていないことを示すことをさらに含む、態様２７から３８のいずれかに記載の方法。

【0220】

態様４０。アバタ接触インタラクションに関連するアニメーションにコンテンツフラグが付けられていると判定することと、前記ローカルアバタに前記コンテンツフラグが付けられたコンテンツをフィルタリングする設定が関連付けられていると判定することと、フィルタリングされたタイプのコンテンツが付けられているため、前記アバタ接触インタラクションを終了することと、をさらに含む、態様２７から３９のいずれかに記載の方法。

【0221】

態様４１。アバタ接触インタラクションに関連付けられているリモートアバタにコンテンツフラグのラベルが付けられていると判定することと、前記ローカルアバタに前記コンテンツフラグの付いたコンテンツをフィルタリングする設定が関連付けられていると判定することと、前記コンテンツフラグに関連付けられていない代替リモートアバタをダウンロードすることとをさらに含む、態様２７から４０のいずれかに記載の方法。

【0222】

態様４２。アバタの前記ペアの間に相互同意があるかどうかを判定する前に、アバタの前記ペアのうちのいずれかのアバタが、アバタ接触インタラクションに関連付けられたレシーバを構成されているかどうかを判定することをさらに含む、態様２７から４１のいずれかに記載の方法。

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図5C】

【図6】

【図7】

【図8】

【図9A】

【図9B】

【図10】

【図11】

【図12】

【手続補正書】

【提出日】2024-06-04

【手続補正1】

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

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

コライダと、衝突に反応するように構成されたアバタの部分との間の前記衝突に反応してアクションをトリガするための方法であって、
前記コライダと、前記衝突に反応するように構成された前記アバタの前記部分との間の衝突を検出することと、
前記検出された衝突を、前記アバタに関連付けられたアバタコントローラに報告することと、
前記衝突に対するリアクションをアニメーション化することと、
を含む、方法。

【請求項2】

前記衝突に反応するように構成された前記アバタの前記部分が、レシーバを含み、前記レシーバが、前記衝突に反応してアニメーションまたはエフェクトをトリガするように構成される、請求項１に記載の方法。

【請求項3】

前記コライダが第１のアバタ上にあり、前記衝突に反応するように構成された前記アバタの前記部分が第２のアバタ上にある、請求項１に記載の方法。

【請求項4】

前記衝突に反応するように構成された前記アバタの前記部分が、二次モーション動作を有するように構成される、請求項１に記載の方法。

【請求項5】

前記アクションが前記アバタへの永続的な状態変更に関連しているかどうかを判定することと、
前記アクションが前記アバタへの前記永続的な状態変更に関連していると判定された場合、前記第１のアバタと前記第２のアバタをレンダリングするアプリケーションのリモートインスタンスに状態変更通知を送信すること、
をさらに含む、請求項３に記載の方法。

【請求項6】

前記衝突に対する前記リアクションをアニメーション化する前に、前記検出された衝突から生じる前記リアクションを許可することに、前記第１のアバタと前記第２のアバタとの間に相互同意があるかどうかを判定すること、
をさらに含む、請求項３に記載の方法。

【請求項7】

前記検出された衝突から生じる前記リアクションを前記アニメーション化することがさらに、
前記構成された二次モーションに従って、前記コライダによって動くように操作される前記アバタの前記部分のモーションをアニメーション化することを含む、
請求項４に記載の方法。

【請求項8】

前記コライダと前記アバタの前記部分との間の前記衝突が、前記二次モーション動作で構成された前記アバタの前記部分を構成するトランスフォームのツリー内の一つのトランスフォームの物理シミュレーションをトリガすると判定すること、
をさらに含む、請求項４に記載の方法。

【請求項9】

前記コライダと前記アバタの前記部分との間のインタラクションが前記トランスフォームの前記物理シミュレーションをトリガすると判定された場合、前記インタラクションに関する情報を、プライマリスレッド以外のスレッドで処理されるジョブであって、前記トランスフォームの前記物理シミュレーションである前記ジョブに渡すこと、
をさらに含む、請求項８に記載の方法。

【請求項10】

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

【請求項11】

請求項１０に記載のコンピュータプログラムを記憶するメモリと、
前記メモリに記憶されたコンピュータプログラムを実行可能な１つ以上のプロセッサと、を備える、コンピューティングシステム。

【国際調査報告】