特許 7311643 モード式ウィンドウを介したセキュアな認可

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-07-10

(45)【発行日】2023-07-19

(54)【発明の名称】モード式ウィンドウを介したセキュアな認可

(51)【国際特許分類】

   G06F 3/01 20060101AFI20230711BHJP

   G06F 3/0481 20220101ALI20230711BHJP

   G06F 3/14 20060101ALI20230711BHJP

   G09G 5/00 20060101ALI20230711BHJP

   G09G 5/10 20060101ALI20230711BHJP

   G09G 5/373 20060101ALI20230711BHJP

   G09G 5/377 20060101ALI20230711BHJP

   G09G 5/38 20060101ALI20230711BHJP

   G09G 5/34 20060101ALI20230711BHJP

   G06T 19/00 20110101ALI20230711BHJP

   H04L 67/131 20220101ALI20230711BHJP

【ＦＩ】

G06F3/01 510

G06F3/0481

G06F3/14 350A

G09G5/00 510A

G09G5/00 555D

G09G5/00 530M

G09G5/10 B

G09G5/373 100

G09G5/373 200

G09G5/377 100

G09G5/38 100

G09G5/00 550C

G09G5/34 A

G06T19/00 A

H04L67/131

【請求項の数】 19

(21)【出願番号】P 2021575368

(86)(22)【出願日】2020-06-05

(65)【公表番号】

(43)【公表日】2022-08-19

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

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

(87)【国際公開日】2020-12-24

【審査請求日】2023-05-30

(31)【優先権主張番号】62/864,752

(32)【優先日】2019-06-21

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

(31)【優先権主張番号】62/890,849

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

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

【早期審査対象出願】

(73)【特許権者】

【識別番号】514108838

【氏名又は名称】マジック リープ， インコーポレイテッド

【氏名又は名称原語表記】Ｍａｇｉｃ Ｌｅａｐ，Ｉｎｃ．

【住所又は居所原語表記】７５００ Ｗ ＳＵＮＲＩＳＥ ＢＬＶＤ，ＰＬＡＮＴＡＴＩＯＮ，ＦＬ ３３３２２ ＵＳＡ

(74)【代理人】

【識別番号】100078282

【弁理士】

【氏名又は名称】山本 秀策

(74)【代理人】

【識別番号】100113413

【弁理士】

【氏名又は名称】森下 夏樹

(74)【代理人】

【識別番号】100181674

【弁理士】

【氏名又は名称】飯田 貴敏

(74)【代理人】

【識別番号】100181641

【弁理士】

【氏名又は名称】石川 大輔

(74)【代理人】

【識別番号】230113332

【弁護士】

【氏名又は名称】山本 健策

(72)【発明者】

【氏名】マック， ジェネビーブ

【審査官】田川 泰宏

(56)【参考文献】

【文献】国際公開第２０１５／１９２１１７（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０１５／００８９６２２（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１４／００２００７０（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１２／０２３５９００（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１６／０２９３１３３（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１２／００５８７７４（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１４／０１２５５７４（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ３／０１－３／０４８９５

Ｇ０６Ｆ ３／１４

Ｇ０９Ｇ ５／００－５／４２

Ｇ０６Ｔ １９／００

Ｈ０４Ｌ ６７／１３１

(57)【特許請求の範囲】

【請求項1】

仮想コンテンツを３次元（３Ｄ）空間環境内に表示するためのディスプレイシステムであって、前記ディスプレイシステムは、
頭部搭載型ディスプレイであって、前記頭部搭載型ディスプレイは、仮想コンテンツを前記ディスプレイシステムのユーザの眼に提示するように構成される、頭部搭載型ディスプレイと、
前記頭部搭載型ディスプレイと通信する回路網であって、前記回路網は、
アプリケーション特有仮想コンテンツを前記ユーザに提示するように構成されるアプリケーションを実行することと、
前記ユーザをウェブサービスに認可するための認可要求を前記アプリケーションから受信することと、
前記３Ｄ空間環境内に表示されている前記アプリケーション特有仮想コンテンツの表示深度を増加させることを含む、前記アプリケーションを背景化することと、
前記頭部搭載型ディスプレイが、認可サービスを実行することであって、前記認可サービスは、
前記ウェブサービスと関連付けられるウェブアドレスを決定することと、
前記頭部搭載型ディスプレイに、前記ユーザに前記ウェブアドレスと関連付けられるモード式認可ウィンドウを提示させることであって、前記モード式認可ウィンドウは、認証証明書を含むユーザ入力を受け取るように構成され、前記モード式認可ウィンドウは、前記アプリケーションが背景化されている一方で、前記アプリケーション特有仮想コンテンツの前記表示深度未満である前記３Ｄ空間環境内の深度において提示され、前記モード式認可ウィンドウが提示されている一方で、前記アプリケーションは、任意のユーザ入力を受信することを無効にされ、前記３Ｄ空間環境内のすべての他のアプリケーションへのアクセスは、無効にされる、ことと、
前記ユーザ入力を認可することと、
前記ユーザ入力を認可することに応答して、ウェブ応答ステータスコードを生成することと、
前記ウェブ応答ステータスコードを前記ウェブサービスに通信することであって、前記認可サービスは、第２のアプリケーションからの第２の認可要求に応答して、前記ウェブ応答ステータスコードを前記ウェブサービスにも提供するように構成される、ことと、
アクセストークンを前記ウェブサービスから受信することであって、前記アクセストークンは、前記ウェブサービスによる認可成功を示す、ことと、
前記アクセストークンを前記アプリケーションに通信することと
を行うように構成される、ことと、
前記認可サービスを終了することと、
前記３Ｄ空間環境内に表示されている前記アプリケーション特有仮想コンテンツの前記表示深度を減少させることを含む、前記アプリケーションを前景化することと
を行うように構成される、回路網と
を備える、ディスプレイシステム。

【請求項2】

前記アプリケーションは、没入型アプリケーションを備える、請求項１に記載のディスプレイシステム。

【請求項3】

前記頭部搭載型ディスプレイは、前記アプリケーション特有仮想コンテンツを提示し、前記ディスプレイシステムによって実行される他のアプリケーションによって生成された仮想コンテンツを表示しないように構成される、請求項１に記載のディスプレイシステム。

【請求項4】

前記アプリケーションは、ランドスケープアプリケーションを備える、請求項１に記載のディスプレイシステム。

【請求項5】

前記頭部搭載型ディスプレイは、前記アプリケーション特有仮想コンテンツを提示し、また、前記ディスプレイシステムによって実行される他のアプリケーションによって生成された仮想コンテンツを表示するように構成される、請求項１に記載のディスプレイシステム。

【請求項6】

前記アプリケーションを背景化することは、前記回路網に、前記アプリケーションをより低い優先順位で実行すること、前記アプリケーション特有仮想コンテンツを隠蔽すること、前記アプリケーション特有仮想コンテンツの不透明度または輝度を低減させること、前記アプリケーション特有仮想コンテンツの透明度を増加させること、または前記アプリケーション特有仮想コンテンツのサイズを減少させることのうちの１つ以上のものを実施させることをさらに含む、請求項１に記載のディスプレイシステム。

【請求項7】

前記アプリケーションを前景化することは、前記回路網に、前記アプリケーションをより高い優先順位で実行すること、アプリケーション特有仮想コンテンツを表示すること、前記アプリケーション特有仮想コンテンツの不透明度または輝度を増加させること、前記アプリケーション特有仮想コンテンツの透明度を減少させること、前記アプリケーション特有仮想コンテンツのサイズを増加させること、または前記アプリケーションがユーザ入力を受信することを可能にすることのうちの１つ以上のものを実施させることをさらに含む、請求項１に記載のディスプレイシステム。

【請求項8】

前記頭部搭載型ディスプレイは、前記モード式認可ウィンドウを大まかな頭部係止設定において表示するように構成される、請求項１に記載のディスプレイシステム。

【請求項9】

前記頭部搭載型ディスプレイは、前記モード式認可ウィンドウを前記ユーザの頭部移動に応答して移動する位置に表示するように構成される、請求項１に記載のディスプレイシステム。

【請求項10】

前記ウェブサービスからの前記モード式認可ウィンドウは、サインオンウィンドウ、ユーザパスワードを受け取るように構成されるウィンドウ、またはユーザ支払証明書を受け取るように構成されるウィンドウのうちの１つ以上のものを備える、請求項９に記載のディスプレイシステム。

【請求項11】

前記認可サービスは、前記アプリケーションの子として実行される、請求項１に記載のディスプレイシステム。

【請求項12】

前記認可サービスは、アプリケーションプログラミングインターフェース（ＡＰＩ）呼び出しを介して、前記アプリケーションから呼び出される、請求項１に記載のディスプレイシステム。

【請求項13】

前記ウェブサービスは、前記ディスプレイシステムから遠隔でアクセスされる第三者ウェブサービスである、請求項１に記載のディスプレイシステム。

【請求項14】

仮想コンテンツを３次元（３Ｄ）空間環境内に表示するように構成される複合現実ディスプレイシステムのユーザを認可するための方法であって、前記方法は、
前記複合現実ディスプレイシステム上で実行されるアプリケーションから、前記ユーザをウェブサービスに認可するための要求を受信することと、
前記３Ｄ空間環境内に表示されている前記アプリケーションのためのアプリケーション特有仮想コンテンツの表示深度を増加させることを含む、前記アプリケーションを背景化することと、
認可ウィンドウを前記ユーザに表示することであって、前記認可ウィンドウは、前記ウェブサービスによる認可と関連付けられる認証証明書を含むユーザ入力を受け取るように構成され、前記認可ウィンドウは、前記複合現実ディスプレイシステムが前記アプリケーションのための前記アプリケーション特有仮想コンテンツを表示する表示深度未満である前記３Ｄ空間環境内の深度において、前記複合現実ディスプレイシステムによって前記ユーザに表示され、前記認可ウィンドウが提示されている一方で、前記アプリケーションは、任意のユーザ入力を受信することを無効にされ、前記３Ｄ空間環境内のすべての他のアプリケーションへのアクセスは、無効にされる、ことと、
前記ユーザ入力を認可することと、
前記ユーザ入力を認可することに応答して、ウェブ応答ステータスコードを生成することと、
前記ウェブ応答ステータスコードを前記ウェブサービスに通信することであって、前記複合現実ディスプレイシステムは、第２のアプリケーションからの第２の認可要求に応答して、前記ウェブ応答ステータスコードを前記ウェブサービスにも提供するように構成される、ことと、
アクセストークンを前記ウェブサービスから受信することであって、前記アクセストークンは、前記ウェブサービスによる認可成功を示す、ことと、
前記アクセストークンを前記アプリケーションに通信することと、
前記３Ｄ空間環境内に表示されている前記アプリケーション特有仮想コンテンツの前記表示深度を減少させることを含む、前記アプリケーションを前景化することと
を含む、方法。

【請求項15】

前記アプリケーションの前記背景化は、前記ユーザに前記認可ウィンドウを表示することに先立つ、請求項１４に記載の方法。

【請求項16】

前記認可ウィンドウは、モード式ウィンドウを備える、請求項１５に記載の方法。

【請求項17】

前記認可ウィンドウは、前記アプリケーションの子である、請求項１５に記載の方法。

【請求項18】

仮想コンテンツを３次元（３Ｄ）空間環境内に表示するように構成される複合現実ディスプレイシステムのユーザを認可するための方法であって、前記方法は、
アプリケーションを前記複合現実ディスプレイシステム上で実行することであって、前記アプリケーションは、前記複合現実ディスプレイシステムによって前記３Ｄ空間環境内で前記ユーザに表示されるアプリケーション特有仮想コンテンツを生成する、ことと、
前記アプリケーションと関連付けられるウェブサービスのウェブアドレスを登録することと、
前記アプリケーション特有仮想コンテンツを前記ユーザに表示しないように隠蔽している一方で、前記ユーザに、モード式認可ウィンドウを表示することであって、前記アプリケーション特有仮想コンテンツを隠蔽することは、前記３Ｄ空間環境内に表示されている前記アプリケーション特有仮想コンテンツの表示深度を増加させることを含み、前記モード式認可ウィンドウは、前記アプリケーション特有仮想コンテンツが隠蔽されている一方で、前記アプリケーション特有仮想コンテンツの前記表示深度未満である前記３Ｄ空間環境内の深度において提示され、前記アプリケーション特有仮想コンテンツが提示されている一方で、前記アプリケーションは、任意のユーザ入力を受信することを無効にされ、前記３Ｄ空間環境内のすべての他のアプリケーションへのアクセスは、無効にされる、ことと、
前記モード式認可ウィンドウを介して打ち込まれるユーザ入力に応答して、ウェブ応答ステータスコードを受信することであって、前記ユーザ入力は、認証証明書を含み、前記ウェブ応答ステータスコードは、ディスパッチサービスを介して前記ウェブサービスに提供される、ことと、
前記ディスパッチサービスが、前記ウェブ応答ステータスコードを前記アプリケーションに提供することと、
前記ユーザを認可するための要求を前記アプリケーションから受信することと、
前記アプリケーションに提供される前記ウェブ応答ステータスコードとの交換において前記アプリケーションのためのアクセストークンを生成することであって、前記アクセストークンは、前記ウェブサービスによる認可成功を示す、ことと、
前記アプリケーションと関連付けられる前記ウェブアドレスを使用して、前記アクセストークンを前記アプリケーションに通信することと、
前記３Ｄ空間環境内に表示されている前記アプリケーション特有仮想コンテンツの前記表示深度を減少させることを含む、前記アプリケーションを前景化することと
を含む、方法。

【請求項19】

前記アプリケーション特有仮想コンテンツを隠蔽することは、前記アプリケーション特有仮想コンテンツを表示しないこと、前記アプリケーション特有仮想コンテンツの不透明度または輝度を低減させること、前記アプリケーション特有仮想コンテンツの透明度を増加させること、前記アプリケーション特有仮想コンテンツのサイズを減少させること、または前記モード式認可ウィンドウを没入型モードで表示することのうちの１つ以上のものをさらに含む、請求項１８に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

（優先権の主張）
本願は、それぞれ、参照することによってその全体として本明細書内に組み込まれる、２０１９年６月２１日に出願され、「ＢＲＯＷＳＥＲ ＦＯＲ ＭＩＸＥＤ ＲＥＡＬＩＴＹ ＳＹＳＴＥＭ」と題された、米国仮出願第６２／８６４，７５２号、および２０１９年８月２３日に出願され、「ＳＥＣＵＲＥ ＡＵＴＨＯＲＩＺＡＴＩＯＮ ＶＩＡ ＭＯＤＡＬ ＷＩＮＤＯＷ」と題された、米国仮出願第６２／８９０，８４９号の優先権を主張する。

【0002】

本開示は、概して、空間３次元（３Ｄ）環境内に技術を実装するためのシステムおよび方法に関し、より具体的には、３Ｄ複合、拡張、または仮想現実環境内における仮想コンテンツのナビゲーションまたは操作に関する。

【背景技術】

【0003】

ウェブページを閲覧する典型的方法は、コンピュータ、スマートフォン、タブレット等のモニタ上でウェブページを開くことである。ユーザは、ウェブページを通してスクロールし、ウェブページ上に表示される異なるコンテンツを閲覧するであろう。通常、ユーザが、コンピュータモニタ、スマートフォン、またはタブレットを見ているかどうかにかかわらず、コンテンツがモニタ上で表示される方法に関して、固定フォーマットが存在する。ウェブページを３Ｄ環境内で視認するための課題が、存在する。

【発明の概要】

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

【0004】

３Ｄ複合現実環境内における仮想コンテンツのナビゲーションおよび操作のための改良されたシステムおよび方法が、提供される。本システムおよび方法は、空間３Ｄ環境内におけるユーザの認可を提供することができる。例えば、本システムおよび方法は、ユーザが、複合現実ディスプレイシステムを介して、複数のアプリケーションおよび／または他のウェブサービスを使用することを認可するように構成される、シングルサインオン（ＳＳＯ）ウェブサービス等の複合現実ディスプレイシステム上で実行されるアプリケーションから、ユーザをウェブサービスに認可するための要求を受信するステップを含むことができる。いくつかの実施形態では、認可ウェブサービスは、ユーザに、ウェブサービスによる認可と関連付けられるユーザ入力を受け取り、アプリケーションまたは他のアプリケーションがユーザ入力を受信することを防止するように構成される、認可ウィンドウを表示し、ユーザ入力をウェブサービスに通信し、アクセストークンであって、ウェブサービスによる認可成功を示す、アクセストークンをウェブサービスから受信し、ユーザの認可のために、アクセストークンをアプリケーションに通信する。認可ウィンドウは、複合現実ディスプレイシステムによって没入型モードで表示される、モード式ウィンドウであることができる。
本発明は、例えば、以下を提供する。
（項目１）
仮想コンテンツを３次元（３Ｄ）空間環境内に表示するためのディスプレイシステムであって、前記ディスプレイシステムは、
頭部搭載型ディスプレイであって、前記頭部搭載型ディスプレイは、仮想コンテンツを前記ディスプレイシステムのユーザの眼に提示するように構成される、頭部搭載型ディスプレイと、
前記頭部搭載型ディスプレイと通信する回路網であって、前記回路網は、
アプリケーション特有仮想コンテンツを前記ユーザに提示するように構成されるアプリケーションを実行することと、
前記ユーザをウェブサービスに認可するための認可要求を前記アプリケーションから受信することと、
前記アプリケーションを背景化することと、
認可サービスを実行することであって、前記認可サービスは、
前記頭部搭載型ディスプレイに、前記ユーザにモード式認可ウィンドウを提示させることであって、前記モード式認可ウィンドウは、ユーザ入力を受け取り、前記アプリケーションまたは他のアプリケーションが前記ユーザ入力を受信することを防止するように構成される、ことと、
前記ウェブサービスによる認可と関連付けられる前記ユーザ入力を受信することと、
前記ユーザ入力を前記ウェブサービスに通信することと、
アクセストークンを前記ウェブサービスから受信することであって、前記アクセストークンは、前記ウェブサービスによる認可成功を示す、ことと、
前記アクセストークンを前記アプリケーションに通信することと
を行うように構成される、ことと、
前記認可サービスを終了することと、
前記アプリケーションを前景化することと
を行うように構成される、回路網と
を備える、ディスプレイシステム。
（項目２）
前記アプリケーションは、没入型アプリケーションを備える、項目１に記載のディスプレイシステム。
（項目３）
前記頭部搭載型ディスプレイは、前記アプリケーション特有仮想コンテンツを提示し、前記ディスプレイシステムによって実行される他のアプリケーションによって生成された仮想コンテンツを表示しないように構成される、項目１または項目２に記載のディスプレイシステム。
（項目４）
前記アプリケーションは、ランドスケープアプリケーションを備える、項目１－３のいずれか１項に記載のディスプレイシステム。
（項目５）
前記頭部搭載型ディスプレイは、前記アプリケーション特有仮想コンテンツを提示し、また、前記ディスプレイシステムによって実行される他のアプリケーションによって生成された仮想コンテンツを表示するように構成される、項目１－４のいずれか１項に記載のディスプレイシステム。
（項目６）
前記回路網は、前記アプリケーションの実行の間、任意の時点において、前記認可要求を前記アプリケーションから受信するように構成される、項目１－５のいずれか１項に記載のディスプレイシステム。
（項目７）
前記アプリケーションを背景化することは、前記回路網に、前記アプリケーションをより低い優先順位で実行すること、前記アプリケーション特有仮想コンテンツを隠すこと、前記アプリケーション特有仮想コンテンツの不透明度または輝度を低減させること、前記アプリケーション特有仮想コンテンツの透明度を増加させること、前記アプリケーション特有仮想コンテンツの表示深度を増加させること、前記アプリケーション特有仮想コンテンツのサイズを減少させること、または前記アプリケーションがユーザ入力を受信することを防止することのうちの１つ以上のものを実施させることを含む、項目１－６のいずれか１項に記載のディスプレイシステム。
（項目８）
前記アプリケーションを前景化することは、前記回路網に、前記アプリケーションをより高い優先順位で実行すること、アプリケーション特有仮想コンテンツを表示すること、前記アプリケーション特有仮想コンテンツの不透明度または輝度を増加させること、前記アプリケーション特有仮想コンテンツの透明度を減少させること、前記アプリケーション特有仮想コンテンツの表示深度を減少させること、前記アプリケーション特有仮想コンテンツのサイズを増加させること、または前記アプリケーションがユーザ入力を受信することを可能にすることのうちの１つ以上のものを実施させることを含む、項目１－７のいずれか１項に記載のディスプレイシステム。
（項目９）
前記頭部搭載型ディスプレイは、前記モード式認可ウィンドウを大まかな頭部係止設定において表示するように構成される、項目１－８のいずれか１項に記載のディスプレイシステム。
（項目１０）
前記頭部搭載型ディスプレイは、前記モード式認可ウィンドウを前記ユーザの頭部移動に応答して移動する位置に表示するように構成される、項目１－９のいずれか１項に記載のディスプレイシステム。
（項目１１）
前記位置は、前記ユーザの真正面にある、項目１０に記載のディスプレイシステム。
（項目１２）
前記位置は、前記モード式認可ウィンドウ内のテキストまたはグラフィックが前記ユーザにとって読みやすいような前記ユーザからの距離に対応する、項目１０または項目１１に記載のディスプレイシステム。
（項目１３）
前記モード式認可ウィンドウは、前記アプリケーションの名称、前記ウェブサービスのウェブアドレスの少なくとも一部、前記認可要求をキャンセルするための選択可能ユーザ入力特徴、または前記ウェブサービスからの認可ウィンドウのうちの１つ以上のものを描写する、項目１－１２のいずれか１項に記載のディスプレイシステム。
（項目１４）
前記モード式認可ウィンドウは、第１のユーザ入力の受信に応じて、前記ウェブサービスの完全ウェブアドレスを表示するように構成される、項目１３に記載のディスプレイシステム。
（項目１５）
前記モード式認可ウィンドウは、前記ユーザが前記ウェブサービスのウェブアドレスを通してスクロールすることを可能にするように構成されるスクロールバーを表示するように構成される、項目１３に記載のディスプレイシステム。
（項目１６）
前記ウェブサービスからの認可ウィンドウは、サインオンウィンドウ、ユーザパスワードを受け取るように構成されるウィンドウ、またはユーザ支払証明書を受け取るように構成されるウィンドウのうちの１つ以上のものを備える、項目１２－１５のいずれか１項に記載のディスプレイシステム。
（項目１７）
前記モード式認可ウィンドウは、ウェブブラウザウィンドウを備える、項目１－１６のいずれか１項に記載のディスプレイシステム。
（項目１８）
前記認可サービスは、前記アプリケーションの子として実行される、項目１－１７のいずれか１項に記載のディスプレイシステム。
（項目１９）
前記認可サービスは、アプリケーションプログラミングインターフェース（ＡＰＩ）呼び出しを介して、前記アプリケーションから呼び出される、項目１－１８のいずれか１項に記載のディスプレイシステム。
（項目２０）
前記認可サービスは、ソフトウェア開発キット（ＳＤＫ）呼び出しを介して、前記アプリケーションから呼び出される、項目１－１９のいずれか１項に記載のディスプレイシステム。
（項目２１）
前記ウェブサービスは、前記ディスプレイシステムから遠隔でアクセスされる第三者ウェブサービスである、項目１－２０のいずれか１項に記載のディスプレイシステム。
（項目２２）
複合現実ディスプレイシステムのユーザを認可するための方法であって、前記方法は、
前記複合現実ディスプレイシステム上で実行されるアプリケーションから、前記ユーザをウェブサービスに認可するための要求を受信することと、
認可ウィンドウを前記ユーザに表示することであって、前記認可ウィンドウは、前記ウェブサービスによる認可と関連付けられるユーザ入力を受け取り、前記アプリケーションまたは他のアプリケーションが前記ユーザ入力を受信することを防止するように構成される、ことと、
前記ユーザ入力を前記ウェブサービスに通信することと、
アクセストークンを前記ウェブサービスから受信することであって、前記アクセストークンは、前記ウェブサービスによる認可成功を示す、ことと、
前記アクセストークンを前記アプリケーションに通信することと
を含む、方法。
（項目２３）
前記アプリケーションは、没入型アプリケーションまたはランドスケープアプリケーションを備える、項目２２に記載の方法。
（項目２４）
前記ユーザに前記認可ウィンドウを表示することに先立って、前記アプリケーションを背景化することと、前記アクセストークンを前記ウェブサービスから受信した後に、前記アプリケーションを前景化することとをさらに含む、項目２２または項目２３に記載の方法。
（項目２５）
前記認可ウィンドウは、モード式ウィンドウを備える、項目２２－２４のいずれか１項に記載の方法。
（項目２６）
前記認可ウィンドウは、前記アプリケーションの子である、項目２２－２５のいずれか１項に記載の方法。
（項目２７）
複合現実ディスプレイシステムのユーザを認可するための方法であって、前記方法は、
アプリケーションを前記複合現実ディスプレイシステム上で実行することであって、前記アプリケーションは、前記ユーザへの表示のために、アプリケーション特有仮想コンテンツを生成する、ことと、
前記アプリケーションと関連付けられるウェブアドレスを登録することと、
前記アプリケーション特有仮想コンテンツを前記ユーザに表示しないように隠蔽しながら、前記ユーザに、モード式認可ウィンドウを表示することと、
前記モード式認可ウィンドウを介して打ち込まれるユーザ入力に応答して、ウェブ応答ステータスコードを受信することと、
前記アプリケーションと関連付けられる前記ウェブアドレスを使用して、前記ウェブ応答ステータスコードを前記アプリケーションに通信することと
を含む、方法。
（項目２８）
前記アプリケーションは、没入型アプリケーションまたはランドスケープアプリケーションを備える、項目２７に記載の方法。
（項目２９）
前記アプリケーション特有仮想コンテンツを隠蔽することは、前記アプリケーション特有仮想コンテンツを表示しないこと、前記アプリケーション特有仮想コンテンツの不透明度または輝度を低減させること、前記アプリケーション特有仮想コンテンツの透明度を増加させること、前記アプリケーション特有仮想コンテンツの表示深度を増加させること、前記アプリケーション特有仮想コンテンツのサイズを減少させること、または前記モード式認可ウィンドウを没入型モードで表示することのうちの１つ以上のものを含む、項目２７または項目２８に記載の方法。
（項目３０）
前記モード式認可ウィンドウは、前記アプリケーションまたは他のアプリケーションが前記ユーザ入力を受信することを防止する、項目２７－２９のいずれか１項に記載の方法。
（項目３１）
前記モード式認可ウィンドウは、前記アプリケーションの子である、項目２７－３０のいずれか１項に記載の方法。
（項目３２）
前記アプリケーションと前記モード式認可ウィンドウとの間の通信を提供するように構成されるソフトウェア開発キットを提供することをさらに含む、項目２７－３１のいずれか１項に記載の方法。
（項目３３）
前記ウェブ応答ステータスコードを前記アプリケーションに通信後、
前記モード式認可ウィンドウを隠蔽することと、
前記アプリケーション特有仮想コンテンツを前記ユーザに表示することと
をさらに含む、項目２７－３２のいずれか１項に記載の方法。
（項目３４）
前記モード式認可ウィンドウを隠蔽することは、前記モード式認可ウィンドウを表示しないこと、前記モード式認可ウィンドウの不透明度または輝度を低減させること、前記モード式認可ウィンドウの透明度を増加させること、前記モード式認可ウィンドウの表示深度を増加させること、前記モード式認可ウィンドウのサイズを減少させることのうちの１つ以上のものを含む、項目３３に記載の方法。

【図面の簡単な説明】

【0005】

図面は、本開示の種々の実装の設計および有用性を図示する。図は、縮尺通りに描かれておらず、類似構造または機能の要素は、図全体を通して同様の参照番号によって表されることに留意されたい。本開示の種々の実装の上記に列挙されたものおよび他の利点および目的を得る方法をより深く理解するために、上記で簡単に説明された本開示のより詳細な説明が、添付の図面に図示される、その具体的実装を参照して与えられるであろう。これらの図面は、本開示の典型的実装のみを描写し、したがって、その範囲の限定と見なされないという理解の上、本開示は、添付の図面の使用を通して、付加的具体性および詳細とともに説明および解説されるであろう。

【0006】

【図1】図１は、いくつかの実装による、ユーザの３Ｄ環境内に表示されるべき２Ｄコンテンツを分解するための拡張現実環境を図示する。

【0007】

【図2】図２は、いくつかの実装による、２Ｄコンテンツの要素とユーザの３Ｄ環境の例示的マッピングを図示する。

【0008】

【図3】図３は、いくつかの実装による、３Ｄ環境内に表示されるべき２Ｄコンテンツを分解するための方法を図示する、フロー図である。

【0009】

【図4】図４は、いくつかの実装による、２Ｄコンテンツ内の要素を識別するための方法を図示する、フロー図である。

【0010】

【図5】図５は、いくつかの実装による、２Ｄコンテンツから分解された要素を記憶するためのテーブルの実施例を示す。

【0011】

【図6】図６は、いくつかの実装による、ユーザのローカル環境から表面を識別するための方法を図示する、フロー図である。

【0012】

【図7】図７は、いくつかの実装による、ユーザのローカル環境から識別された表面のインベントリを記憶するためのテーブルの実施例を示す。

【0013】

【図8】図８は、いくつかの実装による、２Ｄコンテンツからの要素を利用可能な表面にマッピングするための方法を図示する、フロー図である。

【0014】

【図9】図９は、いくつかの実装による、２Ｄコンテンツからの要素のユーザのローカル環境からの表面へのマッピングを記憶するためのテーブルの実施例を示す。

【0015】

【図10】図１０は、ユーザのウィンドウの視認を実装するためのアプローチのフローチャートを図示する。

【0016】

【図11A】図１１Ａ－１１Ｂは、ウィンドウの以前の物理的場所にかかわらず、ユーザのためにウィンドウを表示するためのプロセスを図示する。

【図11B】図１１Ａ－１１Ｂは、ウィンドウの以前の物理的場所にかかわらず、ユーザのためにウィンドウを表示するためのプロセスを図示する。

【0017】

【図12】図１２－１３は、複数のウィンドウを複合現実インターフェース内に表示するための可能性として考えられるアプローチの例証を提供する。

【図13】図１２－１３は、複数のウィンドウを複合現実インターフェース内に表示するための可能性として考えられるアプローチの例証を提供する。

【0018】

【図14】図１４は、複数のプリズムを複合現実システム内に表示するための可能性として考えられるアプローチを図示する。

【0019】

【図15】図１５は、本開示の実装を実装するために好適な例証的コンピューティングシステムのブロック図である。

【0020】

【図16A】図１６Ａ－１６Ｆは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。

【図16B】図１６Ａ－１６Ｆは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。

【図16C】図１６Ａ－１６Ｆは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。

【図16D】図１６Ａ－１６Ｆは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。

【図16E】図１６Ａ－１６Ｆは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。

【図16F】図１６Ａ－１６Ｆは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。

【0021】

【図17A】図１７Ａ－１７Ｄは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。

【図17B】図１７Ａ－１７Ｄは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。

【図17C】図１７Ａ－１７Ｄは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。

【図17D】図１７Ａ－１７Ｄは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。

【0022】

【図18】図１８は、没入型（例えば、モード式）認可サービスの実施例を示す、ブロック図である。

【0023】

【図19】図１９は、認可サービスのための例示的システムアーキテクチャのブロック図である。

【0024】

【図20A】図２０Ａは、アプリケーション開発者のための認可フローの実施例を図示する。

【0025】

【図20B】図２０Ｂは、ソフトウェア開発キット（ＳＤＫ）を使用したアプリケーション開発者のための認可フローの実施例を図示する。

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

【0026】

種々の実装が、ここで、当業者が本開示を実践することを可能にするように本開示の例証的実施例として提供される、図面を参照して詳細に説明されるであろう。着目すべきこととして、下記の図および実施例は、本開示の範囲を限定することを意味するものではない。本開示のある要素が、公知のコンポーネント（または方法またはプロセス）を使用して、部分的または完全に実装される場合、本開示の理解のために必要なそのような公知のコンポーネント（または方法またはプロセス）のその部分のみが、説明され、そのような公知のコンポーネント（または方法またはプロセス）の他の部分の詳細な説明は、本開示を曖昧にしないように省略されるであろう。さらに、種々の実装は、例証として本明細書に参照されるコンポーネントの現在および将来的公知の均等物を包含する。

【0027】

下記に説明されるようなシステムおよび方法は、主に、ブラウザアプリケーションのコンテキスト内で説明されるが、当業者は、本明細書に説明されるシステムおよび方法がまた、１つ以上の他のアプリケーションのコンテキスト内にも同様に適用されてもよいことを理解するであろう。いくつかの実装では、ユーザの写真および／またはビデオを管理するためのアプリケーションが、下記に説明されるシステムおよび方法を利用してもよい。いくつかの実装では、カードゲームをプレーするためのアプリケーションが、下記に説明されるシステムおよび方法を利用してもよい。いくつかの実装では、天候アプリケーションが、下記に説明されるシステムおよび方法を利用してもよい。いくつかの実装では、３Ｄ仮想コンテンツをユーザに表示することが可能なデバイスおよび／またはシステム上でインストールおよび／または起動され得る、任意の他のアプリケーションが、下記に説明されるシステムおよび方法を利用してもよい。いくつかの実装では、単一アプリケーションが、下記に説明されるシステムおよび方法を利用してもよい。いくつかの実装では、１つを上回るアプリケーションが、下記に説明されるシステムおよび方法を利用してもよい。いくつかの実装では、３Ｄ仮想コンテンツをユーザに表示することが可能なデバイスおよび／またはシステム上でインストールおよび／または起動される、全てのアプリケーションが、下記に説明されるシステムおよび方法を利用してもよい。いくつかの実装では、アプリケーションの複数のインスタンスが、下記に説明されるシステムおよび方法を利用してもよい。
用語

【0028】

本明細書で議論されるシステムおよび方法の理解を促進するために、いくつかの用語が、下記に説明される。これらの用語および本明細書で使用される他の用語は、提供される説明、用語の通常および慣例的意味、および／または個別の用語に関する任意の他の含意される意味を含むものと解釈されるべきであって、そのような構造は、用語のコンテキストと一致する。したがって、下記の説明は、これらの用語の意味を限定するものではなく、例示的説明のみを提供する。

【0029】

モード式ウィンドウ：前景内（例えば、親アプリケーションの主要なウィンドウの上部）に表示される、グラフィカルウィンドウ（および／または他のユーザインターフェース要素）。モード式ウィンドウの表示は、親アプリケーションのうちの少なくとも一部（例えば、モード式ウィンドウを囲繞する部分）が、可視のままであることを可能にし得るが、ユーザは、親アプリケーションに戻り得る前に、モード式ウィンドウと相互作用しなければならない。

【0030】

ウェブサービス：ネットワークを介して利用可能にされる、サービス。ウェブサービスは、ネットワーク接続デバイスと通信するために、種々の通信モデルを使用してもよい。例えば、いくつかのウェブサービスは、ＳＯＡＰメッセージを使用し、これは、例えば、ＨＴＴＰとＸＭＬを併用して伝送され得る。ウェブサービスの一実施例は、シングルサインオン（ＳＳＯ）サービスであって、これは、概して、複数のアプリケーション（または他のウェブサービス）のそれぞれが別個のユーザ認証を提供することを必要としないように、ユーザが、複数のアプリケーション（または他のウェブサービス）を参照することを認可するように構成される。ＳＳＯサービスは、Ｏｐｅｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ（ＯＡｕｔｈ）、Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＳＡＭＬ）、および／または他のサービス等を介して、種々の様式において提供されてもよい。具体的認証サービスが、本明細書の例示的実施形態に議論されるが、他の認証サービスもまた、使用されてもよい。
ウェブページ分解

【0031】

仮想現実、拡張現実、および／または複合現実システム（以降、集合的に、「複合現実」システムと称される）を用いることで、３次元環境が、ユーザへのコンテンツの表示のために提供される。２Ｄコンテンツをブラウザ内に表示するための従来のアプローチは、３Ｄ環境内で使用されるとき、あまり良好に機能しない。この理由の１つは、従来の２Ｄウェブブラウザを用いると、ディスプレイデバイスの表示エリアが、コンテンツを表示しているモニタの画面エリアに限定されるためである。その結果、従来のブラウザは、コンテンツをそのモニタ表示エリア内に編成および表示する方法のみを把握するように構成される。対照的に、３Ｄ環境は、モニタ表示エリアの厳密な範囲内に限定されない。したがって、従来の２Ｄブラウザは、従来のブラウジング技術が、コンテンツを表示するために３Ｄ環境を利用するための機能性または能力を有していないために、３Ｄ環境内で使用されるとき、準最適に性能を発揮する。

【0032】

例えば、ユーザが、複合現実機器を使用しており、異なる物理的場所と関連付けられた複数のブラウザウィンドウを設置しているときの状況を検討する。例えば、ユーザは、第１のブラウザウィンドウを第１の部屋内で開いており、第２のブラウザウィンドウを第２の部屋に居る間に開いている場合がある。従来の２Ｄベースのブラウザは、所与のモニタエリアの表示に限定されるため、これは、従来のブラウザが、物理的に遠隔のウィンドウの見当を付けるための技術さえ有しておらず、まして、複数の物理的場所内で開かれている複数のウィンドウを伴う本状況に対処する能力など有しておらず、ユーザが、これらの複数のウィンドウを効果的に閲覧し、そこにナビゲートし、使用することを不可能にすることを意味する。

【0033】

したがって、３Ｄ環境内においてブラウジング技術を実装するための改良されたアプローチの必要性が存在する。

【0034】

本開示の実装は、空間的に編成された３Ｄ環境内に表示されるべき２Ｄウェブページを分解する。２Ｄウェブページは、頭部搭載型システム、モバイルデバイス（例えば、携帯電話）、タブレット、テレビ、アプリケーション、および同等物のウェブブラウザ上で生じ得る。いくつかの実装では、２Ｄウェブページは、ラップトップコンピュータ、デスクトップコンピュータ、２Ｄウェブページへのリンクを伴う電子メールアプリケーション、２Ｄウェブページへのリンクを参照する、または含む、電子メッセージ、および同等物等の別のアプリケーションまたはデバイスから受信されてもよい。

【0035】

図１を参照すると、環境１００は、物理的環境と、下記に説明されるプロセス（例えば、ユーザの物理的環境１０５内の３Ｄ表面上に表示されるべきウェブページから２Ｄコンテンツを分解する、またはアプリケーションのための、またはモード式ブラウザウィンドウを提供するための認証または認証を提供する）を実装するためのシステムとを表す。環境１００の代表的物理的環境およびシステムは、頭部搭載型システム１６０を通してユーザ１０８によって視認されるようなユーザの物理的環境１０５を含む。環境１００の代表的システムはさらに、ネットワーク１２０に動作可能に結合されるウェブブラウザ１１０を介して、２Ｄコンテンツ（例えば、ウェブページ）にアクセスするステップを含む。ネットワーク１２０は、インターネット、内部ネットワーク、プライベートクラウドネットワーク、パブリッククラウドネットワーク等であってもよい。ウェブブラウザ１１０はまた、ネットワーク１２０を介して、プロセッサ１７０に動作可能に結合される。プロセッサ１７０は、頭部搭載型システム１６０から別個の隔離されたコンポーネントとして示されるが、代替実装では、プロセッサ１７０は、頭部搭載型システム１６０の１つ以上のコンポーネントと統合されてもよく、および／または、例えば、ネットワーク１２０等の環境１００内の他のシステムコンポーネントの中に統合され、コンピューティングネットワーク１２５および記憶デバイス１３０にアクセスしてもよい。プロセッサ１７０は、頭部搭載型システム１６０、ローカル記憶デバイス１４０、ウェブブラウザ１１０、コンピューティングネットワーク１２５、および記憶デバイス１３０から受信されるビデオ、オーディオ、コンテンツ等の情報を受信および処理するためのソフトウェア１５０とともに構成されてもよい。ソフトウェア１５０は、ネットワーク１２０を介して、コンピューティングネットワーク１２５および記憶デバイス１３０と通信してもよい。ソフトウェア１５０は、プロセッサ１７０上にインストールされてもよい、または別の実装では、ソフトウェアの特徴および機能性は、プロセッサ１７０の中に統合されてもよい。プロセッサ１７０はまた、ユーザ１０８の近傍からの外部記憶デバイス上に遠隔で記憶された情報に依拠せずに、迅速なアクセスのために、プロセッサ１７０によって使用される情報を記憶するためのローカル記憶デバイス１４０とともに構成されてもよい。他の実装では、プロセッサ１７０は、頭部搭載型システム１６０内に統合されてもよい。

【0036】

ユーザの物理的環境１０５は、ユーザが、動き回り、頭部搭載型システム１６０を通してユーザの物理的環境１０５を視認するにつれた、ユーザ１０８の物理的周囲である。例えば、図１を参照すると、ユーザの物理的環境１０５は、２つの壁（例えば、主壁１０８および側壁１８４であって、主壁および側壁は、ユーザのビューに相対的である）と、テーブル１８８とを伴う、部屋を示す。主壁１０８上には、ある２Ｄコンテンツをその上に投影するための候補表面であり得る、物理的境界を伴う物理的表面（例えば、壁に掛けられた、またはそれに取り付けられた絵画、または窓等）を示すように黒色実線によって描写される、長方形表面１８２が、存在する。側壁１８４上には、物理的境界を伴う物理的表面（例えば、壁に掛けられた、またはそれに取り付けられた絵画、または窓等）を示すように黒色実線によって描写される、第２の長方形表面１８６が、存在する。テーブル１８８上には、異なるオブジェクト、すなわち、１）ある２Ｄコンテンツが記憶および表示され得る、仮想Ｒｏｌｏｄｅｘ１９０、２）ある２Ｄコンテンツをその上に投影するための物理的境界を伴う物理的表面を表すように黒色実線によって描写される、水平表面１９２、および３）例えば、ある２Ｄコンテンツが記憶および表示され得る、スタックされた仮想新聞を表すように黒色点線によって描写される、仮想四角形表面１９４の複数のスタックが存在してもよい。

【0037】

ウェブブラウザ１１０はまた、インターネットから、またはイントラネットまたはプライベートネットワーク内のブログページを表示してもよい。加えて、ウェブブラウザ１１０はまた、デジタル２Ｄコンテンツを表示する、任意の技術であってもよい。２Ｄコンテンツは、例えば、ウェブページ、ブログ、デジタル写真、ビデオ、ニュース記事、ニュースレター、または音楽を含んでもよい。２Ｄコンテンツは、ネットワーク１２０を介してユーザ１０８によってアクセス可能な記憶デバイス１３０内に記憶されてもよい。いくつかの実装では、２Ｄコンテンツはまた、ストリーミングコンテンツ、例えば、ライブビデオフィードまたはライブオーディオフィードであってもよい。記憶デバイス１３０は、例えば、データベース、ファイルシステム、持続的メモリデバイス、フラッシュドライブ、キャッシュ等を含んでもよい。いくつかの実装では、２Ｄコンテンツ（例えば、ウェブページ）を含有する、ウェブブラウザ１１０は、コンピューティングネットワーク１２５を介して表示される。

【0038】

コンピューティングネットワーク１２５は、記憶デバイス１３０にアクセスし、ウェブブラウザ１１０上のウェブページ内に表示するための２Ｄコンテンツを読み出し、記憶する。いくつかの実装では、ローカル記憶デバイス１４０は、着目２Ｄコンテンツをユーザ１０８に提供してもよい。ローカル記憶デバイス１４０は、例えば、フラッシュドライブ、キャッシュ、ハードドライブ、データベース、ファイルシステム等を含んでもよい。ローカル記憶デバイス１４０内に記憶される情報は、最近アクセスされた２Ｄコンテンツまたは３Ｄ空間内に最近表示されたコンテンツを含んでもよい。ローカル記憶デバイス１４０は、２Ｄコンテンツを分解し、２Ｄコンテンツを３Ｄ空間環境（例えば、ユーザの物理的環境１０５内の３Ｄ表面）上に表示することに役立てるためのソフトウェア１５０に、あるコンテンツをローカルで提供することによって、環境１００のシステムに対して性能において改良を可能にする。

【0039】

ソフトウェア１５０は、非一過性コンピュータ可読媒体内に記憶され、ユーザの物理的環境１０５内に表示されるべき２Ｄコンテンツを分解する機能を果たす、ソフトウェアプログラムを含む。ソフトウェア１５０は、プロセッサ１７０上で起動されてもよく、プロセッサ１７０は、ユーザ１０８にローカルで取り付けられる、またはいくつかの実装では、ソフトウェア１５０およびプロセッサ１７０は、頭部搭載型システム１６０内に含まれてもよい。いくつかの実装では、ソフトウェア１５０の特徴および機能の一部は、ユーザ１０８から遠隔のコンピューティングネットワーク１２５上で記憶および実行されてもよい。例えば、いくつかの実装では、２Ｄコンテンツを分解するステップは、コンピューティングネットワーク１２５上で生じてもよく、分解の結果は、記憶デバイス１３０内に記憶されてもよく、分解された２Ｄコンテンツをその上に提示するためのユーザのローカル環境の表面のインベントリ化は、プロセッサ１７０内で生じてもよく、表面およびマッピングのインベントリは、ローカル記憶デバイス１４０内に記憶される。一実装では、２Ｄコンテンツを分解し、ローカル表面をインベントリ化し、２Ｄコンテンツの要素をローカル表面にマッピングし、２Ｄコンテンツの要素を表示するプロセスは全て、プロセッサ１７０およびソフトウェア１５０内でローカルで生じてもよい。

【0040】

頭部搭載型システム１６０は、ユーザインターフェースと、ユーザ感知システムと、環境感知システムと、プロセッサと（全て図示せず）を含む、仮想現実（ＶＲ）または拡張現実（ＡＲ）頭部搭載型システムであってもよい。頭部搭載型システム１６０は、ユーザ１０８に、デジタル世界と相互作用し、それを体験するためのインターフェースを提示する。そのような相互作用は、ユーザおよびデジタル世界、環境１００とインターフェースをとる１人以上の他のユーザ、およびデジタルおよび物理的世界内のオブジェクトを伴い得る。

【0041】

ユーザインターフェースは、２Ｄコンテンツを受信するステップと、ユーザインターフェースを通したユーザ入力によって、２Ｄコンテンツ内の要素を選択するステップとを含んでもよい。ユーザインターフェースは、触覚的インターフェースデバイス、キーボード、マウス、ジョイスティック、モーションキャプチャコントローラ、光学追跡デバイス、およびオーディオ入力デバイスのうちの少なくとも１つまたはそれらの組み合わせであってもよい。触覚的インターフェースデバイスは、人間が、身体感覚および移動を通してコンピュータと相互作用することを可能にする、デバイスである。触覚的とは、コンピューティングデバイス上でアクションまたはプロセスを実施するための触知的フィードバックまたは他の身体感覚を包含する、人間とコンピュータの相互作用技術のタイプを指す。いくつかの実装では、制御インターフェースは、ユーザが、例えば、ユーザ入力をシステムに提供し、システムが対応するコマンドを実行することにより応答することによって、ＭＲディスプレイシステムと相互作用し得るようなユーザインターフェースであってもよい。

【0042】

ユーザ感知システムは、頭部搭載型システム１６０を装着しているユーザ１０８に関連する、ある特徴、特性、または情報を検出するように動作可能な１つ以上のセンサ１６２を含んでもよい。例えば、いくつかの実装では、センサ１６２は、例えば、以下、すなわち、縮瞳／散瞳、各瞳孔の角度測定値／位置付け、球形度、眼形状（眼形状は、経時的に変化するため）、および他の解剖学的データのうちの１つ以上のもの等、ユーザ１０８のリアルタイム光学特性／測定値を検出することが可能なカメラまたは光学検出／走査回路を含んでもよい。本データは、頭部搭載型システム１６０によって使用され、ユーザの視認体験を向上させ得る、情報（例えば、ユーザの視覚的視点）を提供する、または計算するために使用されてもよい。

【0043】

環境感知システムは、データをユーザの物理的環境１０５から取得するために、１つ以上のセンサ１６４を含んでもよい。センサ１６４によって検出されるオブジェクトまたは情報は、頭部搭載型システム１６０への入力として提供されてもよい。いくつかの実装では、本入力は、仮想世界とのユーザ相互作用を表してもよい。例えば、デスク（例えば、テーブル１８８）上の仮想キーボードを視認しているユーザ（例えば、ユーザ１０８）は、ユーザが仮想キーボード上でタイプしているかのように、その指を用いてジェスチャしてもよい。移動している指の運動が、センサ１６４によって捕捉され、頭部搭載型システム１６０に入力として提供されてもよく、入力は、仮想世界を変化させる、新しい仮想オブジェクトを作成するために使用されてもよい。

【0044】

センサ１６４は、例えば、持続的および／または断続的に投影される赤外線構造化光を通して、例えば、場面情報を解釈するための概して外向きに面したカメラまたはスキャナを含んでもよい。環境感知システムは、静的オブジェクト、動的オブジェクト、人々、ジェスチャおよび種々の照明、周囲および音響条件を含む、ローカル環境を検出し、位置合わせすることによって、ユーザ１０８の周囲のユーザの物理的環境１０５の１つ以上の要素をマッピングするために使用されてもよい。したがって、いくつかの実装では、環境感知システムは、ローカルコンピューティングシステム（例えば、プロセッサ１７０）内に内蔵され、センサ１６４によって検出された１つ以上のオブジェクトまたは情報をデジタル的に再構築するように動作可能である、画像ベースの３Ｄ再構築ソフトウェアを含んでもよい。

【0045】

一例示的実装では、環境感知システムは、以下、すなわち、モーションキャプチャデータ（ジェスチャ認識を含む）、深度感知、顔認識、オブジェクト認識、一意のオブジェクト特徴認識、音声／オーディオ認識および処理、音響源位置特定、雑音低減、赤外線または類似レーザ投影、およびモノクロおよび／またはカラーＣＭＯＳセンサ（または他の類似センサ）、視野センサ、および種々の他の光学増強センサのうちの１つ以上のものを提供する。環境感知システムは、上記に議論されるもの以外の他のコンポーネントを含んでもよいことを理解されたい。

【0046】

上記に述べられたように、プロセッサ１７０は、いくつかの実装では、頭部搭載型システム１６０の他のコンポーネントと統合される、環境１００のシステムの他のコンポーネントと統合されてもよい、または図１に示されるように、隔離されたデバイス（ウェアラブルまたはユーザ１０８と別個）であってもよい。プロセッサ１７０は、物理的有線接続を通して、または、例えば、モバイルネットワーク接続（携帯電話およびデータネットワークを含む）、Ｗｉ－Ｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、または任意の他の無線接続プロトコル等の無線接続を通して、頭部搭載型システム１６０の種々のコンポーネントに接続されてもよい。プロセッサ１７０は、メモリモジュール、統合されたおよび／または付加的グラフィック処理ユニット、無線および／または有線インターネットコネクティビティ、およびソース（例えば、コンピューティングネットワーク１２５、および頭部搭載型システム１６０からのユーザ感知システムおよび環境感知システム）からのデータを画像およびオーディオデータに変換することが可能なコーデックおよび／またはファームウェアを含んでもよく、画像／ビデオおよびオーディオは、ユーザインターフェース（図示せず）を介して、ユーザ１０８に提示されてもよい。

【0047】

プロセッサ１７０は、頭部搭載型システム１６０の種々のコンポーネントのためのデータ処理と、頭部搭載型システム１６０とウェブブラウザ１１０およびコンピューティングネットワーク１２５によって表示またはアクセスされ得るウェブページからの２Ｄコンテンツとの間のデータ交換とをハンドリングする。例えば、プロセッサ１７０は、ユーザ１０８とコンピューティングネットワーク１２５との間のデータストリーミングをバッファおよび処理するために使用され、それによって、スムーズで、持続的で、かつ高忠実性のユーザ体験を可能にすることができる。

【0048】

ウェブページからの２Ｄコンテンツを要素に分解し、要素を３Ｄ環境内の表面に表示されるようにマッピングするステップは、知的かつ論理的様式において遂行されてもよい。所定のルールのセットが、２Ｄコンテンツ／ウェブページ内で識別されたあるタイプの要素／コンテンツを設置すべき場所を推奨、提案、または決定付けるために利用可能であり得る。例えば、あるタイプの２Ｄコンテンツ要素は、１つ以上の要素を記憶および表示するために適している物理的または仮想オブジェクト表面にマッピングされる必要があり得る、１つ以上の要素を有し得る一方、他のタイプの２Ｄコンテンツ要素は、ウェブページ内のメインビデオまたはメイン記事等の単一オブジェクトであり得、その場合、単一オブジェクトは、単一オブジェクトをユーザに表示するために最も道理にかなう表面にマッピングされ得る。

【0049】

図２は、いくつかの実装による、２Ｄコンテンツの要素とユーザの３Ｄ環境の例示的マッピングを図示する。環境２００は、ウェブブラウザ１１０によって表示またはアクセスされる、２Ｄコンテンツ（例えば、ウェブページ）と、ユーザの物理的環境１０５とを描写する。矢印を伴う点線は、ユーザの物理的環境１０５上にマッピングおよび表示される、２Ｄコンテンツ（例えば、ウェブページ）からの要素（例えば、特定のタイプのコンテンツ）を描写する。２Ｄコンテンツからのある要素は、ウェブ設計者ヒントまたは事前に定義されたブラウザルールのいずれかに基づいて、ユーザの物理的環境１０５内のある物理的または仮想オブジェクトにマッピングされる。

【0050】

実施例として、ウェブブラウザ１１０によってアクセスまたは表示される、２Ｄコンテンツは、複数のタブを有する、ウェブページであってもよく、現在のアクティブなタブ２６０は、表示され、二次タブ２５０は、現在、ウェブブラウザ１１０上に表示するために選択されるまで隠蔽されている。アクティブタブ２６０内に表示されるものは、典型的には、ウェブページである。本特定の実施例では、アクティブタブ２６０は、メインビデオ２２０と、ユーザコメント２３０と、提案されるビデオ２４０とを含む、ＹＯＵＴＵＢＥ（登録商標）ページを表示する。本例示的実施例である図２に描写されるように、メインビデオ２２０は、垂直表面１８２上に表示されるようにマッピングされてもよく、ユーザコメント２３０は、水平表面１９２上に表示されるようにマッピングされてもよく、提案されるビデオ２４０は、垂直表面１８２と異なる垂直表面１８６上に表示されるようにマッピングされてもよい。加えて、二次タブ２５０は、仮想Ｒｏｌｏｄｅｘ１９０および／またはマルチスタック仮想オブジェクト１９４上に表示されるようにマッピングされてもよい。いくつかの実装では、二次タブ２５０内の具体的コンテンツは、マルチスタック仮想オブジェクト１９４内に記憶されてもよい。他の実装では、二次タブ２５０内に常駐するコンテンツ全体が、マルチスタック仮想オブジェクト１９４上に記憶および／または表示されてもよい。同様に、仮想Ｒｏｌｏｄｅｘ１９０は、二次タブ２５０からの具体的コンテンツを含有してもよい、または仮想Ｒｏｌｏｄｅｘ１９０は、二次タブ２５０内に常駐するコンテンツ全体を含有してもよい。

【0051】

垂直表面１８２は、窓ガラスまたは写真フレーム等の部屋（ユーザの物理的環境１０５として描写される）の主壁１８０上にすでにあり得る、任意のタイプの構造であってもよい。いくつかの実装では、垂直表面１８２は、空壁であってもよく、頭部搭載型システム１６０は、ユーザ１０８がメインビデオ２２０を閲覧するために適切な垂直表面１８２のフレームの最適サイズを決定する。垂直表面１８２のサイズの本決定は、少なくとも部分的に、主壁１８０からのユーザ１０８の距離、メインビデオ２２０のサイズおよび寸法、メインビデオ２２０の品質、非被覆壁空間の量、および／または主壁１８０を見ているときのユーザの姿勢に基づいてもよい。例えば、メインビデオ２２０の品質が、高精細である場合、垂直表面１８２のサイズは、メインビデオ２２０の品質が垂直表面１８２によって悪影響を受けないであろうため、より大きくてもよい。しかしながら、メインビデオ２２０のビデオ品質が、不良品質である場合、大垂直表面１８２を有することは、ビデオ品質を著しく下げ得、その場合、本開示の方法およびシステムは、垂直表面１８２をより小さくサイズ変更／再定義し、ピクシレーションからの不良ビデオ品質を最小限にしてもよい。

【0052】

垂直表面１８６は、垂直表面１８２のように、ユーザの物理的環境１０５内の隣接する壁（例えば、側壁１８４）上の垂直表面である。いくつかの実装では、ユーザ１０８の配向に基づいて、側壁１８４および垂直表面１８６は、勾配が付けられた傾斜表面であるように現れてもよい。勾配が付けられた傾斜表面は、垂直および水平表面に加えた、表面の配向のタイプであってもよい。ＹＯＵＴＵＢＥ（登録商標）ウェブページから提案されるビデオ２４０は、側壁１８４上の垂直表面１８６上に設置され、ユーザ１０８が、本実施例では、単に、その頭部を若干右に移動させることによって、提案されるビデオを閲覧することが可能となることを可能にしてもよい。

【0053】

仮想Ｒｏｌｏｄｅｘ１９０は、頭部搭載型システム１６０によって作成され、ユーザ１０８に表示される、仮想オブジェクトである。仮想Ｒｏｌｏｄｅｘ１９０は、ユーザ１０８が、仮想ページのセットを通して双方向にサイクル表示させる能力を有してもよい。仮想Ｒｏｌｏｄｅｘ１９０は、ウェブページ全体を含有してもよい、または個々の記事またはビデオまたはオーディオを含有してもよい。本実施例に示されるように、仮想Ｒｏｌｏｄｅｘ１９０は、二次タブ２５０からのコンテンツの一部を含有してもよい、またはいくつかの実装では、仮想Ｒｏｌｏｄｅｘ１９０は、二次タブ２５０のページ全体を含有してもよい。ユーザ１０８は、単に、仮想Ｒｏｌｏｄｅｘ１９０内の特定のタブに合焦することによって、仮想Ｒｏｌｏｄｅｘ１９０内のコンテンツを通して、双方向にサイクル表示させてもよく、頭部搭載型システム１６０内の１つ以上のセンサ（例えば、センサ１６２）は、ユーザ１０８の眼焦点を検出し、仮想Ｒｏｌｏｄｅｘ１９０内のタブを通してサイクル表示し、故に、ユーザ１０８に関する関連情報を取得するであろう。いくつかの実装では、ユーザ１０８は、仮想Ｒｏｌｏｄｅｘ１９０からの関連情報を選定し、頭部搭載型システム１６０に、関連情報を利用可能な周囲表面またはユーザ１０８に近接近する仮想ディスプレイ（図示せず）等のさらに別の仮想オブジェクトのいずれか上に表示するように命令してもよい。

【0054】

仮想Ｒｏｌｏｄｅｘ１９０に類似する、マルチスタック仮想オブジェクト１９４は、１つ以上のタブからのフルコンテンツ、またはユーザ１０８が、ブックマークした、将来的閲覧のために保存した、または開いている（例えば、非アクティブタブ）、種々のウェブページまたはタブからの特定のコンテンツに及ぶ、コンテンツを含有してもよい。マルチスタック仮想オブジェクト１９４はまた、新聞の実世界スタックに類似する。マルチスタック仮想オブジェクト１９４内の各スタックは、特定の新聞記事、ページ、雑誌発行物、レシピ等に関連してもよい。当業者は、２Ｄコンテンツ要素または２Ｄコンテンツソースからのコンテンツを設置するための表面を提供する本同一目的を遂行するために、複数のタイプの仮想オブジェクトが存在し得ることを理解し得る。

【0055】

当業者は、ウェブブラウザ１１０によってアクセスまたは表示される２Ｄコンテンツが、単に、ウェブページ以上のものであってもよいことを理解し得る。いくつかの実装では、２Ｄコンテンツは、写真アルバムからの写真、映画からのビデオ、ＴＶ番組、ＹＯＵＴＵＢＥ（登録商標）ビデオ、双方向フォーム等であってもよい。さらに他の実装では、２Ｄコンテンツは、電子書籍または書籍を表示する任意の電子手段であってもよい。最後に、他の実装では、２Ｄコンテンツは、２Ｄコンテンツが、概して、情報が現在提示される方法であるため、これまで説明されていない他のタイプのコンテンツであってもよい。電子デバイスが、２Ｄコンテンツを取り込むことができる場合、２Ｄコンテンツは、頭部搭載型システム１６０によって、２Ｄコンテンツを分解し、３Ｄ設定（例えば、ＡＲ）内に表示するために使用されることができる。

【0056】

いくつかの実装では、アクセスされた２Ｄコンテンツをマッピングするステップは、２Ｄコンテンツを抽出するステップ（例えば、ブラウザから）と、それを表面上に載上するステップ（コンテンツが、もはやブラウザ内になく、表面上にのみあるように）とを含んでもよく、いくつかの実装では、マッピングは、コンテンツを複製するステップ（例えば、ブラウザから）と、それを表面上に載上するステップ（コンテンツが、ブラウザ内および表面上の両方にあるように）とを含むことができる。

【0057】

２Ｄコンテンツを分解するステップは、インターネットおよびコンピュータ関連技術の領域に存在する、技術的問題である。ウェブページ等の２Ｄコンテンツは、ＨＴＭＬ等のあるタイプのプログラミング言語を使用して構築され、コンピュータプロセッサおよび技術的コンポーネントに、ウェブページ内の要素をユーザのための画面上に表示する場所および方法を命令する。上記に議論されるように、ウェブ設計者は、典型的には、２Ｄキャンバス（例えば、画面）の限界内で作業し、要素（例えば、コンテンツ）を２Ｄキャンバス内で設置および表示する。ＨＴＭＬタグは、ＨＴＭＬドキュメントまたはＨＴＭＬドキュメント内の一部がフォーマットされる方法を決定するために使用される。いくつかの実装では、（抽出または複製された）２Ｄコンテンツは、ＨＴＭＬタグ参照を維持することができ、いくつかの実装では、ＨＴＭＬタグ参照は、再定義されてもよい。

【0058】

図３は、いくつかの実装による、３Ｄ環境内に表示されるべき２Ｄコンテンツを分解するための方法を図示する、フロー図である。本方法は、３１０において、２Ｄコンテンツを識別するステップと、３２０において、２Ｄコンテンツ内の要素を識別するステップと、３３０において、周囲表面を識別するステップと、３４０において、識別された２Ｄコンテンツ内の識別された要素を周囲表面を識別するステップから識別された表面にマッピングするステップと、３５０において、要素を仮想コンテンツとして選択された表面上に表示するステップとを含み、選択された表面は、要素と識別された表面のマッピングから選択される。

【0059】

３１０において、２Ｄコンテンツを識別するステップは、デジタルコンテンツを検索するために、頭部搭載型システム１６０の使用を伴ってもよい。３１０において、２Ｄコンテンツを識別するステップはまた、ネットワーク１２０に接続されるサーバ（例えば、記憶デバイス１３０）上のデジタルコンテンツにアクセスするステップを含んでもよい。３１０において、２Ｄコンテンツを識別するステップは、ユーザ１０８に関心があるウェブページに関して、インターネットをブラウジングするステップを含んでもよい。いくつかの実装では、３１０において、２Ｄコンテンツを識別するステップは、インターネット上でコンテンツを検索するためにユーザ１０８によって与えられる、音声アクティブ化コマンドを含んでもよい。例えば、ユーザ１０８は、デバイス（例えば、頭部搭載型システム１６０）と相互作用してもよく、ユーザ１０８は、ビデオを検索するためのコマンドを発し、次いで、ビデオの名称およびビデオの簡単な説明を伝えることにより、デバイスに特定のビデオを検索するように求めることによって、インターネット上の特定のビデオを検索する。デバイスは、次いで、インターネットを検索し、ビデオを２Ｄブラウザ上に取り込み、ユーザ１０８が、デバイスの２Ｄブラウザ上に表示されるにつれて、ビデオを見ることを可能にしてもよい。ユーザ１０８は、次いで、ビデオがユーザ１０８が空間３Ｄ環境内で閲覧することを所望するであろうビデオであることを確認してもよい。

【0060】

いったん２Ｄコンテンツが、識別されると、本方法は、３２０において、２Ｄコンテンツ内の要素を識別し、ユーザ１０８に表示するために、２Ｄコンテンツ内の利用可能な要素をインベントリ化する。２Ｄコンテンツ内の要素は、例えば、ウェブページ上に掲載されたビデオ、記事、およびニュースレター、ソーシャルメディアウェブサイト上のコメントおよびポスティング、ブログポスト、種々のウェブサイト上に掲載された写真、オーディオ書籍等を含んでもよい。２Ｄコンテンツ（例えば、ウェブページ）内のこれらの要素は、特定の要素が設置されるウェブページ上の場所、およびある場合には、要素がウェブページ上に表示されるべき時間および方法を定義するために、コンテンツ設計者によって提供されるＨＴＭＬタグと関連付けられた属性を有する、ＨＴＭＬタグを含有してもよい。いくつかの実装では、本開示の方法およびシステムは、３４０におけるマッピングプロセスを補助し、要素を３Ｄ設定内に表示するための場所および方法を決定するために、これらのＨＴＭＬタグおよび属性をコンテンツ設計者によって提供されるヒントおよび提案として利用する。例えば、下記は、ウェブページ開発者によって提供される、例示的ＨＴＭＬウェブページコードである。

【化1-1】

【化1-2】

【0061】

ウェブページ開発者によって提供される、例示的ＨＴＭＬウェブページコードは、メインビデオをウェブページ上に表示する方法に関する選好と、推奨される（または提案される）ビデオを表示する方法に関する選好とを含む。特に、本ＨＴＭＬウェブページコードは、「ｖｉｒｔｉｃａｌ」のタイプ値を使用して、ビデオを表示するための垂直表面を指定する、「ｓｔｙｌｅ」のタグを使用して、メインビデオを表示するための方法を規定する。加えて、「ｓｔｙｌｅ」タグ内に、ウェブページ開発者によって提供される付加的ヒントが、どのウェブページ（例えば、メインビデオ）内のＨＴＭＬ要素／コンテンツがどの潜在的表面積にマッピングされるべきかを優先順位化するために使用するためのマッチングアルゴリズムに関する「ｐｒｉｏｒｉｔｙ」選好を含んでもよい。例示的ＨＴＭＬウェブページコードでは、優先順位は、垂直平面レイアウトを有するビデオに関して、１００の値に設定され、本実施例では、より高い優先順位値は、より高い優先順位を示す。加えて、本実施例では、選好は、提案されるビデオを「ｈｏｒｉｚｏｎｔａｌ」のタイプ値を有するスタック内にスタックレイアウトで設置するように、ウェブページ開発者によって示され、スタックされたオブジェクト（例えば、この場合、別の提案されるビデオに関連して提案されるビデオ）間の距離は、２０ｃｍである。

【0062】

図４は、いくつかの実装による、２Ｄコンテンツ内の要素を識別するための方法を図示する、フロー図である。図４は、いくつかの実装による、図３の３２０における２Ｄコンテンツ内の要素を識別するステップを開示する、詳細なフローである。図４は、４１０において、図３の３２０において２Ｄコンテンツ内の要素を識別するステップに類似する、２Ｄコンテンツ内の要素を識別するステップから開始する。本方法は、４２０において、タグからコンテンツの設置に関する属性を識別する次のブロックに進む。上記に議論されるように、ウェブページ設計者は、ウェブページを設計および構成する際、ウェブページ内の要素とＨＴＭＬタグを関連付け、各要素を表示するための場所および方法を定義し得る。これらのＨＴＭＬタグはまた、ウェブページの特定の部分上への要素の設置に関する属性を含んでもよい。頭部搭載型システム１６０が、検出し、システムの他のコンポーネントと協調し、特定の要素が表示され得る場所に関する入力として使用し得るものは、これらのＨＴＭＬタグおよびその属性である。

【0063】

ヒントまたはタグを各要素から抽出するステップが、４３０において実施される。ヒントまたはタグは、典型的には、２Ｄコンテンツ／ウェブページのコンテンツ設計者および／またはウェブページ開発者によって提供される、フォーマット化ヒントまたはフォーマット化タグである。上記に議論されるように、コンテンツ設計者は、例えば、「ウェブページ開発者によって提供される例示的ＨＴＭＬウェブページコード」に示されるように、ＨＴＭＬタグの形態において、命令またはヒントを提供し、ウェブブラウザ１１０に、２Ｄコンテンツの要素をページまたは画面の特定の部分内に表示するように命令してもよい。いくつかの実装では、ウェブページ設計者は、付加的ＨＴＭＬタグ属性を使用して、付加的フォーマット化ルールを定義してもよい。例えば、ユーザが、具体的色（例えば、赤色）に対して低減された感度を有する場合、赤色を表示せず、代わりに、別の色を使用する、または上記に議論されるように、垂直表面上に表示されるべき選好を有するビデオが、垂直表面上に表示されることができない場合、代替として、ビデオを別の（物理的）表面上に表示する、または仮想表面を作成し、ビデオを仮想表面上に表示する。下記は、ＨＴＭＬページを通して解析し、ヒント／タグをＨＴＭＬページ内の各要素から抽出するためにブラウザ内に実装される、例示的ＨＴＭＬページパーサである。

【化2-1】

【化2-2】

【化2-3】

【化2-4】

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

開発者に提供されるＡＰＩは、プロセス間エクスポートＡＰＩおよびプロセス間インポートＡＰＩを含むことができる。例えば、ウェブブラウザ１９１０（例えば、Ｈｅｌｉｏ）は、ライブラリまたはカーネルエクスポートＡＰＩを使用して、ｏｐｅｎＯａｕｔｈＷｉｎｄｏｗ呼び出しを用いて開かれることができる。

【表1】

【0157】

ｌｉｂｄｉｓｐａｔｃｈｓｅｒｖｉｃｅは、以下のプロセス間エクスポートＡＰＩを含むことができる。

【表2】

【0158】

ｌｉｂｄｉｓｐａｔｃｈｓｅｒｖｉｃｅは、以下のプロセス間インポートＡＰＩを含むことができる。

【表3】

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

同様に、動作は、特定の順序で図面に描写され得るが、これは、望ましい結果を達成するために、そのような動作が示される特定の順序で、または連続的順序で実施される、または全ての図示される動作が実施される必要はないと認識されるべきである。さらに、図面は、フローチャートの形態で１つ以上の例示的プロセスを図式的に描写し得る。しかしながら、描写されない他の動作も、図式的に図示される例示的方法およびプロセス内に組み込まれることができる。例えば、１つ以上の付加的動作が、図示される動作のいずれかの前に、その後に、それと同時に、またはその間に実施されることができる。加えて、動作は、他の実装において再配列される、または再順序付けられ得る。ある状況では、マルチタスクおよび並列処理が、有利であり得る。さらに、上記に説明される実装における種々のシステムコンポーネントの分離は、全ての実装におけるそのような分離を要求するものとして理解されるべきではなく、説明されるプログラムコンポーネントおよびシステムは、概して、単一のソフトウェア製品においてともに統合される、または複数のソフトウェア製品にパッケージ化され得ることを理解されたい。加えて、他の実装も、以下の請求項の範囲内である。いくつかの場合では、請求項に列挙されるアクションは、異なる順序で実施され、依然として、望ましい結果を達成することができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11A】

【図11B】

【図12】

【図13】

【図14】

【図15】

【図16A】

【図16B】

【図16C】

【図16D】

【図16E】

【図16F】

【図17A】

【図17B】

【図17C】

【図17D】

【図18】

【図19】

【図20A】

【図20B】