(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-07-18
(45)【発行日】2024-07-26
(54)【発明の名称】モード式ウィンドウを介したセキュアな認可
(51)【国際特許分類】
G06F 3/01 20060101AFI20240719BHJP
G06F 3/0481 20220101ALI20240719BHJP
G09G 5/36 20060101ALI20240719BHJP
G09G 5/00 20060101ALI20240719BHJP
G09G 5/14 20060101ALI20240719BHJP
G09G 5/37 20060101ALI20240719BHJP
G09G 5/373 20060101ALI20240719BHJP
G09G 5/377 20060101ALI20240719BHJP
G09G 5/02 20060101ALI20240719BHJP
G09G 5/38 20060101ALI20240719BHJP
H04L 67/131 20220101ALI20240719BHJP
H04L 67/02 20220101ALI20240719BHJP
H04L 67/51 20220101ALI20240719BHJP
G06F 21/33 20130101ALI20240719BHJP
【FI】
G06F3/01 510
G06F3/0481
G09G5/36 500
G09G5/00 510A
G09G5/00 555D
G09G5/14 A
G09G5/00 510H
G09G5/00 530T
G09G5/37 320
G09G5/373 200
G09G5/373 100
G09G5/373 300
G09G5/377
G09G5/02 B
G09G5/00 550C
G09G5/38 100
H04L67/131
H04L67/02
H04L67/51
G06F21/33
(21)【出願番号】P 2023111335
(22)【出願日】2023-07-06
(62)【分割の表示】P 2021575368の分割
【原出願日】2020-06-05
【審査請求日】2023-07-06
(32)【優先日】2019-06-21
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2019-08-23
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】514108838
【氏名又は名称】マジック リープ, インコーポレイテッド
【氏名又は名称原語表記】Magic Leap,Inc.
【住所又は居所原語表記】7500 W SUNRISE BLVD,PLANTATION,FL 33322 USA
(74)【代理人】
【識別番号】100078282
【氏名又は名称】山本 秀策
(74)【代理人】
【識別番号】100113413
【氏名又は名称】森下 夏樹
(74)【代理人】
【識別番号】100181674
【氏名又は名称】飯田 貴敏
(74)【代理人】
【識別番号】100181641
【氏名又は名称】石川 大輔
(74)【代理人】
【識別番号】230113332
【氏名又は名称】山本 健策
(72)【発明者】
【氏名】ジェネビーブ マック
【審査官】相川 俊
(56)【参考文献】
【文献】国際公開第2018/016464(WO,A1)
【文献】特開2005-122312(JP,A)
【文献】特開2012-109696(JP,A)
【文献】有山 圭二,話題の「Google Glass」用アプリを開発しよう,日経Linux,日本,日経BP社,2013年08月08日,第15巻 第9号,p.110-115
(58)【調査した分野】(Int.Cl.,DB名)
G06F 3/01
G06F 3/0481
G09G 5/36
G09G 5/00
G09G 5/14
G09G 5/37
G09G 5/373
G09G 5/377
G09G 5/02
G09G 5/38
H04L 67/131
H04L 67/02
H04L 67/51
G06F 21/33
(57)【特許請求の範囲】
【請求項1】
仮想コンテンツを3次元(3D)空間環境内に表示するためのディスプレイシステムであって、前記ディスプレイシステムは、
頭部搭載型ディスプレイであって、前記頭部搭載型ディスプレイは、前記仮想コンテンツを前記ディスプレイシステムのユーザの眼に提示するように構成される、頭部搭載型ディスプレイと、
前記頭部搭載型ディスプレイと通信する回路網であって、前記回路網は、
アプリケーション特有仮想コンテンツを前記ユーザに提示するように構成されるアプリケーションを実行することと、
前記ユーザをサービスに認可するための認可要求を前記アプリケーションから受信することと、
前記頭部搭載型ディスプレイが、認可サービスを実行することであって、前記認可サービスは、
前記サービスと関連付けられるネットワークアドレスを決定することと、
前記頭部搭載型ディスプレイに、前記アプリケーション特有仮想コンテンツを提示することから前記ネットワークアドレスと関連付けられるモード式認可ウィンドウを提示することに遷移させることであって、前記モード式認可ウィンドウは、認証証明書を含むユーザ入力を受け取るように構成され、前記遷移させることは、収縮する円形の内側に前記アプリケーション特有仮想コンテンツを提示させることと、前記円形が所定のサイズまで収縮した後に、前記円形を拡張させて、前記円形内に前記モード式認可ウィンドウを提示させることとを含み、前記モード式認可ウィンドウが提示されている間において、前記アプリケーションは、任意のユーザ入力を受信することを無効にされる、ことと、
前記認証証明書に少なくとも部分的に基づいた前記ユーザの認可成功に応答して、応答ステータスコードを生成することと、
前記応答ステータスコードを前記サービスに通信することと、
前記認可成功を示すアクセストークンを前記サービスから受信することと、
前記アクセストークンを前記アプリケーションに通信することと
を行うように構成される、ことと、
前記認可サービスを終了することと
を行うように構成される、回路網と
を備える、ディスプレイシステム。
【請求項2】
前記アプリケーションは、没入型アプリケーションまたはランドスケープアプリケーションのうちの少なくとも1つを備える、請求項1に記載のディスプレイシステム。
【請求項3】
前記回路網は、
前記ユーザの認可成功に応答して、前記頭部搭載型ディスプレイに、前記モード式認可ウィンドウを提示することから前記アプリケーション特有仮想コンテンツを提示することに遷移させ、前記アプリケーションがユーザ入力を受信することを可能にさせるようにさらに構成される、請求項1に記載のディスプレイシステム。
【請求項4】
前記モード式認可ウィンドウを提示することから前記アプリケーション特有仮想コンテンツを提示することに遷移させることは、前記円形を拡張させて、前記円形内に前記アプリケーション特有仮想コンテンツを提示させることを含む、請求項3に記載のディスプレイシステム。
【請求項5】
前記モード式認可ウィンドウが提示されている間に、前記3D空間環境内で実行されている少なくとも1つの他のアプリケーションへのアクセスが無効にされる、請求項1に記載のディスプレイシステム。
【請求項6】
前記回路網は、
前記ユーザの認可成功に応答して、前記少なくとも1つの他のアプリケーションへのアクセスを有効にするようにさらに構成される、請求項5に記載のディスプレイシステム。
【請求項7】
前記認可サービスは、
第2のアプリケーションからの第2の認可要求に応答して、前記応答ステータスコードを前記サービスに提供するようにさらに構成される、請求項1に記載のディスプレイシステム。
【請求項8】
前記遷移の間に、前記円形の外側の前記仮想コンテンツは、モノクロ背景として提示される、請求項1に記載のディスプレイシステム。
【請求項9】
前記サービスは、ウェブサービスである、請求項1に記載のディスプレイシステム。
【請求項10】
前記ウェブサービスは、前記ディスプレイシステムから遠隔でアクセスされる第三者ウェブサービスである、請求項9に記載のディスプレイシステム。
【請求項11】
前記頭部搭載型ディスプレイは、前記モード式認可ウィンドウを大まかな頭部係止設定において表示するように構成される、請求項1に記載のディスプレイシステム。
【請求項12】
前記頭部搭載型ディスプレイは、前記モード式認可ウィンドウを前記ユーザの頭部移動に応答して移動する位置に表示するように構成される、請求項1に記載のディスプレイシステム。
【請求項13】
前記認可サービスは、前記アプリケーションの子として実行される、請求項1に記載のディスプレイシステム。
【請求項14】
仮想コンテンツを3次元(3D)空間環境内に表示するように構成される頭部搭載型ディスプレイのユーザを認可するための方法であって、前記方法は、
アプリケーション特有仮想コンテンツを前記ユーザに提示するように構成されるアプリケーションを実行することと、
前記ユーザをサービスに認可するための認可要求を前記アプリケーションから受信することと、
認可サービスを実行することであって、前記認可サービスは、
前記サービスと関連付けられるネットワークアドレスを決定することと、
前記頭部搭載型ディスプレイに、前記アプリケーション特有仮想コンテンツを提示することから前記ネットワークアドレスと関連付けられるモード式認可ウィンドウを提示することに遷移させることであって、前記モード式認可ウィンドウは、認証証明書を含むユーザ入力を受け取るように構成され、前記遷移させることは、収縮する円形の内側に前記アプリケーション特有仮想コンテンツを提示させることと、前記円形が所定のサイズまで収縮した後に、前記円形を拡張させて、前記円形内に前記モード式認可ウィンドウを提示させることとを含み、前記モード式認可ウィンドウが提示されている間において、前記アプリケーションは、任意のユーザ入力を受信することを無効にされる、ことと、
前記認証証明書に少なくとも部分的に基づいた前記ユーザの認可成功に応答して、応答ステータスコードを生成することと、
前記応答ステータスコードを前記サービスに通信することと、
前記認可成功を示すアクセストークンを前記サービスから受信することと、
前記アクセストークンを前記アプリケーションに通信することと
を行うように構成される、ことと、
前記認可サービスを終了することと
を含む、方法。
【請求項15】
前記アプリケーションは、没入型アプリケーションまたはランドスケープアプリケーションのうちの少なくとも1つを備える、請求項14に記載の方法。
【請求項16】
前記ユーザの認可成功に応答して、前記頭部搭載型ディスプレイに、前記モード式認可ウィンドウを提示することから前記アプリケーション特有仮想コンテンツを提示することに遷移させ、前記アプリケーションがユーザ入力を受信することを可能にさせることをさらに含む、請求項14に記載の方法。
【請求項17】
前記モード式認可ウィンドウを提示することから前記アプリケーション特有仮想コンテンツを提示することに遷移させることは、前記円形を拡張させて、前記円形内に前記アプリケーション特有仮想コンテンツを提示させることを含む、請求項16に記載の方法。
【請求項18】
前記遷移の間に、前記円形の外側の前記仮想コンテンツは、モノクロ背景として提示される、請求項14に記載の方法。
【請求項19】
前記頭部搭載型ディスプレイは、前記モード式認可ウィンドウを大まかな頭部係止設定において表示するように構成される、請求項14に記載の方法。
【請求項20】
前記頭部搭載型ディスプレイは、前記モード式認可ウィンドウを前記ユーザの頭部移動に応答して移動する位置に表示するように構成される、請求項14に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
(優先権の主張)
本願は、それぞれ、参照することによってその全体として本明細書内に組み込まれる、2019年6月21日に出願され、「BROWSER FOR MIXED REALITY SYSTEM」と題された、米国仮出願第62/864,752号、および2019年8月23日に出願され、「SECURE AUTHORIZATION VIA MODAL WINDOW」と題された、米国仮出願第62/890,849号の優先権を主張する。
【0002】
本開示は、概して、空間3次元(3D)環境内に技術を実装するためのシステムおよび方法に関し、より具体的には、3D複合、拡張、または仮想現実環境内における仮想コンテンツのナビゲーションまたは操作に関する。
【背景技術】
【0003】
ウェブページを閲覧する典型的方法は、コンピュータ、スマートフォン、タブレット等のモニタ上でウェブページを開くことである。ユーザは、ウェブページを通してスクロールし、ウェブページ上に表示される異なるコンテンツを閲覧するであろう。通常、ユーザが、コンピュータモニタ、スマートフォン、またはタブレットを見ているかどうかにかかわらず、コンテンツがモニタ上で表示される方法に関して、固定フォーマットが存在する。ウェブページを3D環境内で視認するための課題が、存在する。
【発明の概要】
【課題を解決するための手段】
【0004】
3D複合現実環境内における仮想コンテンツのナビゲーションおよび操作のための改良されたシステムおよび方法が、提供される。本システムおよび方法は、空間3D環境内におけるユーザの認可を提供することができる。例えば、本システムおよび方法は、ユーザが、複合現実ディスプレイシステムを介して、複数のアプリケーションおよび/または他のウェブサービスを使用することを認可するように構成される、シングルサインオン(SSO)ウェブサービス等の複合現実ディスプレイシステム上で実行されるアプリケーションから、ユーザをウェブサービスに認可するための要求を受信するステップを含むことができる。いくつかの実施形態では、認可ウェブサービスは、ユーザに、ウェブサービスによる認可と関連付けられるユーザ入力を受け取り、アプリケーションまたは他のアプリケーションがユーザ入力を受信することを防止するように構成される、認可ウィンドウを表示し、ユーザ入力をウェブサービスに通信し、アクセストークンであって、ウェブサービスによる認可成功を示す、アクセストークンをウェブサービスから受信し、ユーザの認可のために、アクセストークンをアプリケーションに通信する。認可ウィンドウは、複合現実ディスプレイシステムによって没入型モードで表示される、モード式ウィンドウであることができる。
本発明は、例えば、以下を提供する。
(項目1)
仮想コンテンツを3次元(3D)空間環境内に表示するためのディスプレイシステムであって、前記ディスプレイシステムは、
頭部搭載型ディスプレイであって、前記頭部搭載型ディスプレイは、仮想コンテンツを前記ディスプレイシステムのユーザの眼に提示するように構成される、頭部搭載型ディスプレイと、
前記頭部搭載型ディスプレイと通信する回路網であって、前記回路網は、
アプリケーション特有仮想コンテンツを前記ユーザに提示するように構成されるアプリケーションを実行することと、
前記ユーザをウェブサービスに認可するための認可要求を前記アプリケーションから受信することと、
前記アプリケーションを背景化することと、
認可サービスを実行することであって、前記認可サービスは、
前記頭部搭載型ディスプレイに、前記ユーザにモード式認可ウィンドウを提示させることであって、前記モード式認可ウィンドウは、ユーザ入力を受け取り、前記アプリケーションまたは他のアプリケーションが前記ユーザ入力を受信することを防止するように構成される、ことと、
前記ウェブサービスによる認可と関連付けられる前記ユーザ入力を受信することと、
前記ユーザ入力を前記ウェブサービスに通信することと、
アクセストークンを前記ウェブサービスから受信することであって、前記アクセストークンは、前記ウェブサービスによる認可成功を示す、ことと、
前記アクセストークンを前記アプリケーションに通信することと
を行うように構成される、ことと、
前記認可サービスを終了することと、
前記アプリケーションを前景化することと
を行うように構成される、回路網と
を備える、ディスプレイシステム。
(項目2)
前記アプリケーションは、没入型アプリケーションを備える、項目1に記載のディスプレイシステム。
(項目3)
前記頭部搭載型ディスプレイは、前記アプリケーション特有仮想コンテンツを提示し、前記ディスプレイシステムによって実行される他のアプリケーションによって生成された仮想コンテンツを表示しないように構成される、項目1または項目2に記載のディスプレイシステム。
(項目4)
前記アプリケーションは、ランドスケープアプリケーションを備える、項目1-3のいずれか1項に記載のディスプレイシステム。
(項目5)
前記頭部搭載型ディスプレイは、前記アプリケーション特有仮想コンテンツを提示し、また、前記ディスプレイシステムによって実行される他のアプリケーションによって生成された仮想コンテンツを表示するように構成される、項目1-4のいずれか1項に記載のディスプレイシステム。
(項目6)
前記回路網は、前記アプリケーションの実行の間、任意の時点において、前記認可要求を前記アプリケーションから受信するように構成される、項目1-5のいずれか1項に記載のディスプレイシステム。
(項目7)
前記アプリケーションを背景化することは、前記回路網に、前記アプリケーションをより低い優先順位で実行すること、前記アプリケーション特有仮想コンテンツを隠すこと、前記アプリケーション特有仮想コンテンツの不透明度または輝度を低減させること、前記アプリケーション特有仮想コンテンツの透明度を増加させること、前記アプリケーション特有仮想コンテンツの表示深度を増加させること、前記アプリケーション特有仮想コンテンツのサイズを減少させること、または前記アプリケーションがユーザ入力を受信することを防止することのうちの1つ以上のものを実施させることを含む、項目1-6のいずれか1項に記載のディスプレイシステム。
(項目8)
前記アプリケーションを前景化することは、前記回路網に、前記アプリケーションをより高い優先順位で実行すること、アプリケーション特有仮想コンテンツを表示すること、前記アプリケーション特有仮想コンテンツの不透明度または輝度を増加させること、前記アプリケーション特有仮想コンテンツの透明度を減少させること、前記アプリケーション特有仮想コンテンツの表示深度を減少させること、前記アプリケーション特有仮想コンテンツのサイズを増加させること、または前記アプリケーションがユーザ入力を受信することを可能にすることのうちの1つ以上のものを実施させることを含む、項目1-7のいずれか1項に記載のディスプレイシステム。
(項目9)
前記頭部搭載型ディスプレイは、前記モード式認可ウィンドウを大まかな頭部係止設定において表示するように構成される、項目1-8のいずれか1項に記載のディスプレイシステム。
(項目10)
前記頭部搭載型ディスプレイは、前記モード式認可ウィンドウを前記ユーザの頭部移動に応答して移動する位置に表示するように構成される、項目1-9のいずれか1項に記載のディスプレイシステム。
(項目11)
前記位置は、前記ユーザの真正面にある、項目10に記載のディスプレイシステム。
(項目12)
前記位置は、前記モード式認可ウィンドウ内のテキストまたはグラフィックが前記ユーザにとって読みやすいような前記ユーザからの距離に対応する、項目10または項目11に記載のディスプレイシステム。
(項目13)
前記モード式認可ウィンドウは、前記アプリケーションの名称、前記ウェブサービスのウェブアドレスの少なくとも一部、前記認可要求をキャンセルするための選択可能ユーザ入力特徴、または前記ウェブサービスからの認可ウィンドウのうちの1つ以上のものを描写する、項目1-12のいずれか1項に記載のディスプレイシステム。
(項目14)
前記モード式認可ウィンドウは、第1のユーザ入力の受信に応じて、前記ウェブサービスの完全ウェブアドレスを表示するように構成される、項目13に記載のディスプレイシステム。
(項目15)
前記モード式認可ウィンドウは、前記ユーザが前記ウェブサービスのウェブアドレスを通してスクロールすることを可能にするように構成されるスクロールバーを表示するように構成される、項目13に記載のディスプレイシステム。
(項目16)
前記ウェブサービスからの認可ウィンドウは、サインオンウィンドウ、ユーザパスワードを受け取るように構成されるウィンドウ、またはユーザ支払証明書を受け取るように構成されるウィンドウのうちの1つ以上のものを備える、項目12-15のいずれか1項に記載のディスプレイシステム。
(項目17)
前記モード式認可ウィンドウは、ウェブブラウザウィンドウを備える、項目1-16のいずれか1項に記載のディスプレイシステム。
(項目18)
前記認可サービスは、前記アプリケーションの子として実行される、項目1-17のいずれか1項に記載のディスプレイシステム。
(項目19)
前記認可サービスは、アプリケーションプログラミングインターフェース(API)呼び出しを介して、前記アプリケーションから呼び出される、項目1-18のいずれか1項に記載のディスプレイシステム。
(項目20)
前記認可サービスは、ソフトウェア開発キット(SDK)呼び出しを介して、前記アプリケーションから呼び出される、項目1-19のいずれか1項に記載のディスプレイシステム。
(項目21)
前記ウェブサービスは、前記ディスプレイシステムから遠隔でアクセスされる第三者ウェブサービスである、項目1-20のいずれか1項に記載のディスプレイシステム。
(項目22)
複合現実ディスプレイシステムのユーザを認可するための方法であって、前記方法は、
前記複合現実ディスプレイシステム上で実行されるアプリケーションから、前記ユーザをウェブサービスに認可するための要求を受信することと、
認可ウィンドウを前記ユーザに表示することであって、前記認可ウィンドウは、前記ウェブサービスによる認可と関連付けられるユーザ入力を受け取り、前記アプリケーションまたは他のアプリケーションが前記ユーザ入力を受信することを防止するように構成される、ことと、
前記ユーザ入力を前記ウェブサービスに通信することと、
アクセストークンを前記ウェブサービスから受信することであって、前記アクセストークンは、前記ウェブサービスによる認可成功を示す、ことと、
前記アクセストークンを前記アプリケーションに通信することと
を含む、方法。
(項目23)
前記アプリケーションは、没入型アプリケーションまたはランドスケープアプリケーションを備える、項目22に記載の方法。
(項目24)
前記ユーザに前記認可ウィンドウを表示することに先立って、前記アプリケーションを背景化することと、前記アクセストークンを前記ウェブサービスから受信した後に、前記アプリケーションを前景化することとをさらに含む、項目22または項目23に記載の方法。
(項目25)
前記認可ウィンドウは、モード式ウィンドウを備える、項目22-24のいずれか1項に記載の方法。
(項目26)
前記認可ウィンドウは、前記アプリケーションの子である、項目22-25のいずれか1項に記載の方法。
(項目27)
複合現実ディスプレイシステムのユーザを認可するための方法であって、前記方法は、
アプリケーションを前記複合現実ディスプレイシステム上で実行することであって、前記アプリケーションは、前記ユーザへの表示のために、アプリケーション特有仮想コンテンツを生成する、ことと、
前記アプリケーションと関連付けられるウェブアドレスを登録することと、
前記アプリケーション特有仮想コンテンツを前記ユーザに表示しないように隠蔽しながら、前記ユーザに、モード式認可ウィンドウを表示することと、
前記モード式認可ウィンドウを介して打ち込まれるユーザ入力に応答して、ウェブ応答ステータスコードを受信することと、
前記アプリケーションと関連付けられる前記ウェブアドレスを使用して、前記ウェブ応答ステータスコードを前記アプリケーションに通信することと
を含む、方法。
(項目28)
前記アプリケーションは、没入型アプリケーションまたはランドスケープアプリケーションを備える、項目27に記載の方法。
(項目29)
前記アプリケーション特有仮想コンテンツを隠蔽することは、前記アプリケーション特有仮想コンテンツを表示しないこと、前記アプリケーション特有仮想コンテンツの不透明度または輝度を低減させること、前記アプリケーション特有仮想コンテンツの透明度を増加させること、前記アプリケーション特有仮想コンテンツの表示深度を増加させること、前記アプリケーション特有仮想コンテンツのサイズを減少させること、または前記モード式認可ウィンドウを没入型モードで表示することのうちの1つ以上のものを含む、項目27または項目28に記載の方法。
(項目30)
前記モード式認可ウィンドウは、前記アプリケーションまたは他のアプリケーションが前記ユーザ入力を受信することを防止する、項目27-29のいずれか1項に記載の方法。
(項目31)
前記モード式認可ウィンドウは、前記アプリケーションの子である、項目27-30のいずれか1項に記載の方法。
(項目32)
前記アプリケーションと前記モード式認可ウィンドウとの間の通信を提供するように構成されるソフトウェア開発キットを提供することをさらに含む、項目27-31のいずれか1項に記載の方法。
(項目33)
前記ウェブ応答ステータスコードを前記アプリケーションに通信後、
前記モード式認可ウィンドウを隠蔽することと、
前記アプリケーション特有仮想コンテンツを前記ユーザに表示することと
をさらに含む、項目27-32のいずれか1項に記載の方法。
(項目34)
前記モード式認可ウィンドウを隠蔽することは、前記モード式認可ウィンドウを表示しないこと、前記モード式認可ウィンドウの不透明度または輝度を低減させること、前記モード式認可ウィンドウの透明度を増加させること、前記モード式認可ウィンドウの表示深度を増加させること、前記モード式認可ウィンドウのサイズを減少させることのうちの1つ以上のものを含む、項目33に記載の方法。
【図面の簡単な説明】
【0005】
図面は、本開示の種々の実装の設計および有用性を図示する。図は、縮尺通りに描かれておらず、類似構造または機能の要素は、図全体を通して同様の参照番号によって表されることに留意されたい。本開示の種々の実装の上記に列挙されたものおよび他の利点および目的を得る方法をより深く理解するために、上記で簡単に説明された本開示のより詳細な説明が、添付の図面に図示される、その具体的実装を参照して与えられるであろう。これらの図面は、本開示の典型的実装のみを描写し、したがって、その範囲の限定と見なされないという理解の上、本開示は、添付の図面の使用を通して、付加的具体性および詳細とともに説明および解説されるであろう。
【0006】
【
図1】
図1は、いくつかの実装による、ユーザの3D環境内に表示されるべき2Dコンテンツを分解するための拡張現実環境を図示する。
【0007】
【
図2】
図2は、いくつかの実装による、2Dコンテンツの要素とユーザの3D環境の例示的マッピングを図示する。
【0008】
【
図3】
図3は、いくつかの実装による、3D環境内に表示されるべき2Dコンテンツを分解するための方法を図示する、フロー図である。
【0009】
【
図4】
図4は、いくつかの実装による、2Dコンテンツ内の要素を識別するための方法を図示する、フロー図である。
【0010】
【
図5】
図5は、いくつかの実装による、2Dコンテンツから分解された要素を記憶するためのテーブルの実施例を示す。
【0011】
【
図6】
図6は、いくつかの実装による、ユーザのローカル環境から表面を識別するための方法を図示する、フロー図である。
【0012】
【
図7】
図7は、いくつかの実装による、ユーザのローカル環境から識別された表面のインベントリを記憶するためのテーブルの実施例を示す。
【0013】
【
図8】
図8は、いくつかの実装による、2Dコンテンツからの要素を利用可能な表面にマッピングするための方法を図示する、フロー図である。
【0014】
【
図9】
図9は、いくつかの実装による、2Dコンテンツからの要素のユーザのローカル環境からの表面へのマッピングを記憶するためのテーブルの実施例を示す。
【0015】
【
図10】
図10は、ユーザのウィンドウの視認を実装するためのアプローチのフローチャートを図示する。
【0016】
【
図11A】
図11A-11Bは、ウィンドウの以前の物理的場所にかかわらず、ユーザのためにウィンドウを表示するためのプロセスを図示する。
【
図11B】
図11A-11Bは、ウィンドウの以前の物理的場所にかかわらず、ユーザのためにウィンドウを表示するためのプロセスを図示する。
【0017】
【
図12】
図12-13は、複数のウィンドウを複合現実インターフェース内に表示するための可能性として考えられるアプローチの例証を提供する。
【
図13】
図12-13は、複数のウィンドウを複合現実インターフェース内に表示するための可能性として考えられるアプローチの例証を提供する。
【0018】
【
図14】
図14は、複数のプリズムを複合現実システム内に表示するための可能性として考えられるアプローチを図示する。
【0019】
【
図15】
図15は、本開示の実装を実装するために好適な例証的コンピューティングシステムのブロック図である。
【0020】
【
図16A】
図16A-16Fは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。
【
図16B】
図16A-16Fは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。
【
図16C】
図16A-16Fは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。
【
図16D】
図16A-16Fは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。
【
図16E】
図16A-16Fは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。
【
図16F】
図16A-16Fは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。
【0021】
【
図17A】
図17A-17Dは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。
【
図17B】
図17A-17Dは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。
【
図17C】
図17A-17Dは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。
【
図17D】
図17A-17Dは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。
【0022】
【
図18】
図18は、没入型(例えば、モード式)認可サービスの実施例を示す、ブロック図である。
【0023】
【
図19】
図19は、認可サービスのための例示的システムアーキテクチャのブロック図である。
【0024】
【
図20A】
図20Aは、アプリケーション開発者のための認可フローの実施例を図示する。
【0025】
【
図20B】
図20Bは、ソフトウェア開発キット(SDK)を使用したアプリケーション開発者のための認可フローの実施例を図示する。
【発明を実施するための形態】
【0026】
種々の実装が、ここで、当業者が本開示を実践することを可能にするように本開示の例証的実施例として提供される、図面を参照して詳細に説明されるであろう。着目すべきこととして、下記の図および実施例は、本開示の範囲を限定することを意味するものではない。本開示のある要素が、公知のコンポーネント(または方法またはプロセス)を使用して、部分的または完全に実装される場合、本開示の理解のために必要なそのような公知のコンポーネント(または方法またはプロセス)のその部分のみが、説明され、そのような公知のコンポーネント(または方法またはプロセス)の他の部分の詳細な説明は、本開示を曖昧にしないように省略されるであろう。さらに、種々の実装は、例証として本明細書に参照されるコンポーネントの現在および将来的公知の均等物を包含する。
【0027】
下記に説明されるようなシステムおよび方法は、主に、ブラウザアプリケーションのコンテキスト内で説明されるが、当業者は、本明細書に説明されるシステムおよび方法がまた、1つ以上の他のアプリケーションのコンテキスト内にも同様に適用されてもよいことを理解するであろう。いくつかの実装では、ユーザの写真および/またはビデオを管理するためのアプリケーションが、下記に説明されるシステムおよび方法を利用してもよい。いくつかの実装では、カードゲームをプレーするためのアプリケーションが、下記に説明されるシステムおよび方法を利用してもよい。いくつかの実装では、天候アプリケーションが、下記に説明されるシステムおよび方法を利用してもよい。いくつかの実装では、3D仮想コンテンツをユーザに表示することが可能なデバイスおよび/またはシステム上でインストールおよび/または起動され得る、任意の他のアプリケーションが、下記に説明されるシステムおよび方法を利用してもよい。いくつかの実装では、単一アプリケーションが、下記に説明されるシステムおよび方法を利用してもよい。いくつかの実装では、1つを上回るアプリケーションが、下記に説明されるシステムおよび方法を利用してもよい。いくつかの実装では、3D仮想コンテンツをユーザに表示することが可能なデバイスおよび/またはシステム上でインストールおよび/または起動される、全てのアプリケーションが、下記に説明されるシステムおよび方法を利用してもよい。いくつかの実装では、アプリケーションの複数のインスタンスが、下記に説明されるシステムおよび方法を利用してもよい。
用語
【0028】
本明細書で議論されるシステムおよび方法の理解を促進するために、いくつかの用語が、下記に説明される。これらの用語および本明細書で使用される他の用語は、提供される説明、用語の通常および慣例的意味、および/または個別の用語に関する任意の他の含意される意味を含むものと解釈されるべきであって、そのような構造は、用語のコンテキストと一致する。したがって、下記の説明は、これらの用語の意味を限定するものではなく、例示的説明のみを提供する。
【0029】
モード式ウィンドウ:前景内(例えば、親アプリケーションの主要なウィンドウの上部)に表示される、グラフィカルウィンドウ(および/または他のユーザインターフェース要素)。モード式ウィンドウの表示は、親アプリケーションのうちの少なくとも一部(例えば、モード式ウィンドウを囲繞する部分)が、可視のままであることを可能にし得るが、ユーザは、親アプリケーションに戻り得る前に、モード式ウィンドウと相互作用しなければならない。
【0030】
ウェブサービス:ネットワークを介して利用可能にされる、サービス。ウェブサービスは、ネットワーク接続デバイスと通信するために、種々の通信モデルを使用してもよい。例えば、いくつかのウェブサービスは、SOAPメッセージを使用し、これは、例えば、HTTPとXMLを併用して伝送され得る。ウェブサービスの一実施例は、シングルサインオン(SSO)サービスであって、これは、概して、複数のアプリケーション(または他のウェブサービス)のそれぞれが別個のユーザ認証を提供することを必要としないように、ユーザが、複数のアプリケーション(または他のウェブサービス)を参照することを認可するように構成される。SSOサービスは、Open Authorization(OAuth)、Security Assertion Markup Language(SAML)、および/または他のサービス等を介して、種々の様式において提供されてもよい。具体的認証サービスが、本明細書の例示的実施形態に議論されるが、他の認証サービスもまた、使用されてもよい。
ウェブページ分解
【0031】
仮想現実、拡張現実、および/または複合現実システム(以降、集合的に、「複合現実」システムと称される)を用いることで、3次元環境が、ユーザへのコンテンツの表示のために提供される。2Dコンテンツをブラウザ内に表示するための従来のアプローチは、3D環境内で使用されるとき、あまり良好に機能しない。この理由の1つは、従来の2Dウェブブラウザを用いると、ディスプレイデバイスの表示エリアが、コンテンツを表示しているモニタの画面エリアに限定されるためである。その結果、従来のブラウザは、コンテンツをそのモニタ表示エリア内に編成および表示する方法のみを把握するように構成される。対照的に、3D環境は、モニタ表示エリアの厳密な範囲内に限定されない。したがって、従来の2Dブラウザは、従来のブラウジング技術が、コンテンツを表示するために3D環境を利用するための機能性または能力を有していないために、3D環境内で使用されるとき、準最適に性能を発揮する。
【0032】
例えば、ユーザが、複合現実機器を使用しており、異なる物理的場所と関連付けられた複数のブラウザウィンドウを設置しているときの状況を検討する。例えば、ユーザは、第1のブラウザウィンドウを第1の部屋内で開いており、第2のブラウザウィンドウを第2の部屋に居る間に開いている場合がある。従来の2Dベースのブラウザは、所与のモニタエリアの表示に限定されるため、これは、従来のブラウザが、物理的に遠隔のウィンドウの見当を付けるための技術さえ有しておらず、まして、複数の物理的場所内で開かれている複数のウィンドウを伴う本状況に対処する能力など有しておらず、ユーザが、これらの複数のウィンドウを効果的に閲覧し、そこにナビゲートし、使用することを不可能にすることを意味する。
【0033】
したがって、3D環境内においてブラウジング技術を実装するための改良されたアプローチの必要性が存在する。
【0034】
本開示の実装は、空間的に編成された3D環境内に表示されるべき2Dウェブページを分解する。2Dウェブページは、頭部搭載型システム、モバイルデバイス(例えば、携帯電話)、タブレット、テレビ、アプリケーション、および同等物のウェブブラウザ上で生じ得る。いくつかの実装では、2Dウェブページは、ラップトップコンピュータ、デスクトップコンピュータ、2Dウェブページへのリンクを伴う電子メールアプリケーション、2Dウェブページへのリンクを参照する、または含む、電子メッセージ、および同等物等の別のアプリケーションまたはデバイスから受信されてもよい。
【0035】
図1を参照すると、環境100は、物理的環境と、下記に説明されるプロセス(例えば、ユーザの物理的環境105内の3D表面上に表示されるべきウェブページから2Dコンテンツを分解する、またはアプリケーションのための、またはモード式ブラウザウィンドウを提供するための認証または認証を提供する)を実装するためのシステムとを表す。環境100の代表的物理的環境およびシステムは、頭部搭載型システム160を通してユーザ108によって視認されるようなユーザの物理的環境105を含む。環境100の代表的システムはさらに、ネットワーク120に動作可能に結合されるウェブブラウザ110を介して、2Dコンテンツ(例えば、ウェブページ)にアクセスするステップを含む。ネットワーク120は、インターネット、内部ネットワーク、プライベートクラウドネットワーク、パブリッククラウドネットワーク等であってもよい。ウェブブラウザ110はまた、ネットワーク120を介して、プロセッサ170に動作可能に結合される。プロセッサ170は、頭部搭載型システム160から別個の隔離されたコンポーネントとして示されるが、代替実装では、プロセッサ170は、頭部搭載型システム160の1つ以上のコンポーネントと統合されてもよく、および/または、例えば、ネットワーク120等の環境100内の他のシステムコンポーネントの中に統合され、コンピューティングネットワーク125および記憶デバイス130にアクセスしてもよい。プロセッサ170は、頭部搭載型システム160、ローカル記憶デバイス140、ウェブブラウザ110、コンピューティングネットワーク125、および記憶デバイス130から受信されるビデオ、オーディオ、コンテンツ等の情報を受信および処理するためのソフトウェア150とともに構成されてもよい。ソフトウェア150は、ネットワーク120を介して、コンピューティングネットワーク125および記憶デバイス130と通信してもよい。ソフトウェア150は、プロセッサ170上にインストールされてもよい、または別の実装では、ソフトウェアの特徴および機能性は、プロセッサ170の中に統合されてもよい。プロセッサ170はまた、ユーザ108の近傍からの外部記憶デバイス上に遠隔で記憶された情報に依拠せずに、迅速なアクセスのために、プロセッサ170によって使用される情報を記憶するためのローカル記憶デバイス140とともに構成されてもよい。他の実装では、プロセッサ170は、頭部搭載型システム160内に統合されてもよい。
【0036】
ユーザの物理的環境105は、ユーザが、動き回り、頭部搭載型システム160を通してユーザの物理的環境105を視認するにつれた、ユーザ108の物理的周囲である。例えば、
図1を参照すると、ユーザの物理的環境105は、2つの壁(例えば、主壁108および側壁184であって、主壁および側壁は、ユーザのビューに相対的である)と、テーブル188とを伴う、部屋を示す。主壁108上には、ある2Dコンテンツをその上に投影するための候補表面であり得る、物理的境界を伴う物理的表面(例えば、壁に掛けられた、またはそれに取り付けられた絵画、または窓等)を示すように黒色実線によって描写される、長方形表面182が、存在する。側壁184上には、物理的境界を伴う物理的表面(例えば、壁に掛けられた、またはそれに取り付けられた絵画、または窓等)を示すように黒色実線によって描写される、第2の長方形表面186が、存在する。テーブル188上には、異なるオブジェクト、すなわち、1)ある2Dコンテンツが記憶および表示され得る、仮想Rolodex190、2)ある2Dコンテンツをその上に投影するための物理的境界を伴う物理的表面を表すように黒色実線によって描写される、水平表面192、および3)例えば、ある2Dコンテンツが記憶および表示され得る、スタックされた仮想新聞を表すように黒色点線によって描写される、仮想四角形表面194の複数のスタックが存在してもよい。
【0037】
ウェブブラウザ110はまた、インターネットから、またはイントラネットまたはプライベートネットワーク内のブログページを表示してもよい。加えて、ウェブブラウザ110はまた、デジタル2Dコンテンツを表示する、任意の技術であってもよい。2Dコンテンツは、例えば、ウェブページ、ブログ、デジタル写真、ビデオ、ニュース記事、ニュースレター、または音楽を含んでもよい。2Dコンテンツは、ネットワーク120を介してユーザ108によってアクセス可能な記憶デバイス130内に記憶されてもよい。いくつかの実装では、2Dコンテンツはまた、ストリーミングコンテンツ、例えば、ライブビデオフィードまたはライブオーディオフィードであってもよい。記憶デバイス130は、例えば、データベース、ファイルシステム、持続的メモリデバイス、フラッシュドライブ、キャッシュ等を含んでもよい。いくつかの実装では、2Dコンテンツ(例えば、ウェブページ)を含有する、ウェブブラウザ110は、コンピューティングネットワーク125を介して表示される。
【0038】
コンピューティングネットワーク125は、記憶デバイス130にアクセスし、ウェブブラウザ110上のウェブページ内に表示するための2Dコンテンツを読み出し、記憶する。いくつかの実装では、ローカル記憶デバイス140は、着目2Dコンテンツをユーザ108に提供してもよい。ローカル記憶デバイス140は、例えば、フラッシュドライブ、キャッシュ、ハードドライブ、データベース、ファイルシステム等を含んでもよい。ローカル記憶デバイス140内に記憶される情報は、最近アクセスされた2Dコンテンツまたは3D空間内に最近表示されたコンテンツを含んでもよい。ローカル記憶デバイス140は、2Dコンテンツを分解し、2Dコンテンツを3D空間環境(例えば、ユーザの物理的環境105内の3D表面)上に表示することに役立てるためのソフトウェア150に、あるコンテンツをローカルで提供することによって、環境100のシステムに対して性能において改良を可能にする。
【0039】
ソフトウェア150は、非一過性コンピュータ可読媒体内に記憶され、ユーザの物理的環境105内に表示されるべき2Dコンテンツを分解する機能を果たす、ソフトウェアプログラムを含む。ソフトウェア150は、プロセッサ170上で起動されてもよく、プロセッサ170は、ユーザ108にローカルで取り付けられる、またはいくつかの実装では、ソフトウェア150およびプロセッサ170は、頭部搭載型システム160内に含まれてもよい。いくつかの実装では、ソフトウェア150の特徴および機能の一部は、ユーザ108から遠隔のコンピューティングネットワーク125上で記憶および実行されてもよい。例えば、いくつかの実装では、2Dコンテンツを分解するステップは、コンピューティングネットワーク125上で生じてもよく、分解の結果は、記憶デバイス130内に記憶されてもよく、分解された2Dコンテンツをその上に提示するためのユーザのローカル環境の表面のインベントリ化は、プロセッサ170内で生じてもよく、表面およびマッピングのインベントリは、ローカル記憶デバイス140内に記憶される。一実装では、2Dコンテンツを分解し、ローカル表面をインベントリ化し、2Dコンテンツの要素をローカル表面にマッピングし、2Dコンテンツの要素を表示するプロセスは全て、プロセッサ170およびソフトウェア150内でローカルで生じてもよい。
【0040】
頭部搭載型システム160は、ユーザインターフェースと、ユーザ感知システムと、環境感知システムと、プロセッサと(全て図示せず)を含む、仮想現実(VR)または拡張現実(AR)頭部搭載型システムであってもよい。頭部搭載型システム160は、ユーザ108に、デジタル世界と相互作用し、それを体験するためのインターフェースを提示する。そのような相互作用は、ユーザおよびデジタル世界、環境100とインターフェースをとる1人以上の他のユーザ、およびデジタルおよび物理的世界内のオブジェクトを伴い得る。
【0041】
ユーザインターフェースは、2Dコンテンツを受信するステップと、ユーザインターフェースを通したユーザ入力によって、2Dコンテンツ内の要素を選択するステップとを含んでもよい。ユーザインターフェースは、触覚的インターフェースデバイス、キーボード、マウス、ジョイスティック、モーションキャプチャコントローラ、光学追跡デバイス、およびオーディオ入力デバイスのうちの少なくとも1つまたはそれらの組み合わせであってもよい。触覚的インターフェースデバイスは、人間が、身体感覚および移動を通してコンピュータと相互作用することを可能にする、デバイスである。触覚的とは、コンピューティングデバイス上でアクションまたはプロセスを実施するための触知的フィードバックまたは他の身体感覚を包含する、人間とコンピュータの相互作用技術のタイプを指す。いくつかの実装では、制御インターフェースは、ユーザが、例えば、ユーザ入力をシステムに提供し、システムが対応するコマンドを実行することにより応答することによって、MRディスプレイシステムと相互作用し得るようなユーザインターフェースであってもよい。
【0042】
ユーザ感知システムは、頭部搭載型システム160を装着しているユーザ108に関連する、ある特徴、特性、または情報を検出するように動作可能な1つ以上のセンサ162を含んでもよい。例えば、いくつかの実装では、センサ162は、例えば、以下、すなわち、縮瞳/散瞳、各瞳孔の角度測定値/位置付け、球形度、眼形状(眼形状は、経時的に変化するため)、および他の解剖学的データのうちの1つ以上のもの等、ユーザ108のリアルタイム光学特性/測定値を検出することが可能なカメラまたは光学検出/走査回路を含んでもよい。本データは、頭部搭載型システム160によって使用され、ユーザの視認体験を向上させ得る、情報(例えば、ユーザの視覚的視点)を提供する、または計算するために使用されてもよい。
【0043】
環境感知システムは、データをユーザの物理的環境105から取得するために、1つ以上のセンサ164を含んでもよい。センサ164によって検出されるオブジェクトまたは情報は、頭部搭載型システム160への入力として提供されてもよい。いくつかの実装では、本入力は、仮想世界とのユーザ相互作用を表してもよい。例えば、デスク(例えば、テーブル188)上の仮想キーボードを視認しているユーザ(例えば、ユーザ108)は、ユーザが仮想キーボード上でタイプしているかのように、その指を用いてジェスチャしてもよい。移動している指の運動が、センサ164によって捕捉され、頭部搭載型システム160に入力として提供されてもよく、入力は、仮想世界を変化させる、新しい仮想オブジェクトを作成するために使用されてもよい。
【0044】
センサ164は、例えば、持続的および/または断続的に投影される赤外線構造化光を通して、例えば、場面情報を解釈するための概して外向きに面したカメラまたはスキャナを含んでもよい。環境感知システムは、静的オブジェクト、動的オブジェクト、人々、ジェスチャおよび種々の照明、周囲および音響条件を含む、ローカル環境を検出し、位置合わせすることによって、ユーザ108の周囲のユーザの物理的環境105の1つ以上の要素をマッピングするために使用されてもよい。したがって、いくつかの実装では、環境感知システムは、ローカルコンピューティングシステム(例えば、プロセッサ170)内に内蔵され、センサ164によって検出された1つ以上のオブジェクトまたは情報をデジタル的に再構築するように動作可能である、画像ベースの3D再構築ソフトウェアを含んでもよい。
【0045】
一例示的実装では、環境感知システムは、以下、すなわち、モーションキャプチャデータ(ジェスチャ認識を含む)、深度感知、顔認識、オブジェクト認識、一意のオブジェクト特徴認識、音声/オーディオ認識および処理、音響源位置特定、雑音低減、赤外線または類似レーザ投影、およびモノクロおよび/またはカラーCMOSセンサ(または他の類似センサ)、視野センサ、および種々の他の光学増強センサのうちの1つ以上のものを提供する。環境感知システムは、上記に議論されるもの以外の他のコンポーネントを含んでもよいことを理解されたい。
【0046】
上記に述べられたように、プロセッサ170は、いくつかの実装では、頭部搭載型システム160の他のコンポーネントと統合される、環境100のシステムの他のコンポーネントと統合されてもよい、または
図1に示されるように、隔離されたデバイス(ウェアラブルまたはユーザ108と別個)であってもよい。プロセッサ170は、物理的有線接続を通して、または、例えば、モバイルネットワーク接続(携帯電話およびデータネットワークを含む)、Wi-Fi、Bluetooth(登録商標)、または任意の他の無線接続プロトコル等の無線接続を通して、頭部搭載型システム160の種々のコンポーネントに接続されてもよい。プロセッサ170は、メモリモジュール、統合されたおよび/または付加的グラフィック処理ユニット、無線および/または有線インターネットコネクティビティ、およびソース(例えば、コンピューティングネットワーク125、および頭部搭載型システム160からのユーザ感知システムおよび環境感知システム)からのデータを画像およびオーディオデータに変換することが可能なコーデックおよび/またはファームウェアを含んでもよく、画像/ビデオおよびオーディオは、ユーザインターフェース(図示せず)を介して、ユーザ108に提示されてもよい。
【0047】
プロセッサ170は、頭部搭載型システム160の種々のコンポーネントのためのデータ処理と、頭部搭載型システム160とウェブブラウザ110およびコンピューティングネットワーク125によって表示またはアクセスされ得るウェブページからの2Dコンテンツとの間のデータ交換とをハンドリングする。例えば、プロセッサ170は、ユーザ108とコンピューティングネットワーク125との間のデータストリーミングをバッファおよび処理するために使用され、それによって、スムーズで、持続的で、かつ高忠実性のユーザ体験を可能にすることができる。
【0048】
ウェブページからの2Dコンテンツを要素に分解し、要素を3D環境内の表面に表示されるようにマッピングするステップは、知的かつ論理的様式において遂行されてもよい。所定のルールのセットが、2Dコンテンツ/ウェブページ内で識別されたあるタイプの要素/コンテンツを設置すべき場所を推奨、提案、または決定付けるために利用可能であり得る。例えば、あるタイプの2Dコンテンツ要素は、1つ以上の要素を記憶および表示するために適している物理的または仮想オブジェクト表面にマッピングされる必要があり得る、1つ以上の要素を有し得る一方、他のタイプの2Dコンテンツ要素は、ウェブページ内のメインビデオまたはメイン記事等の単一オブジェクトであり得、その場合、単一オブジェクトは、単一オブジェクトをユーザに表示するために最も道理にかなう表面にマッピングされ得る。
【0049】
図2は、いくつかの実装による、2Dコンテンツの要素とユーザの3D環境の例示的マッピングを図示する。環境200は、ウェブブラウザ110によって表示またはアクセスされる、2Dコンテンツ(例えば、ウェブページ)と、ユーザの物理的環境105とを描写する。矢印を伴う点線は、ユーザの物理的環境105上にマッピングおよび表示される、2Dコンテンツ(例えば、ウェブページ)からの要素(例えば、特定のタイプのコンテンツ)を描写する。2Dコンテンツからのある要素は、ウェブ設計者ヒントまたは事前に定義されたブラウザルールのいずれかに基づいて、ユーザの物理的環境105内のある物理的または仮想オブジェクトにマッピングされる。
【0050】
実施例として、ウェブブラウザ110によってアクセスまたは表示される、2Dコンテンツは、複数のタブを有する、ウェブページであってもよく、現在のアクティブなタブ260は、表示され、二次タブ250は、現在、ウェブブラウザ110上に表示するために選択されるまで隠蔽されている。アクティブタブ260内に表示されるものは、典型的には、ウェブページである。本特定の実施例では、アクティブタブ260は、メインビデオ220と、ユーザコメント230と、提案されるビデオ240とを含む、YOUTUBE(登録商標)ページを表示する。本例示的実施例である
図2に描写されるように、メインビデオ220は、垂直表面182上に表示されるようにマッピングされてもよく、ユーザコメント230は、水平表面192上に表示されるようにマッピングされてもよく、提案されるビデオ240は、垂直表面182と異なる垂直表面186上に表示されるようにマッピングされてもよい。加えて、二次タブ250は、仮想Rolodex190および/またはマルチスタック仮想オブジェクト194上に表示されるようにマッピングされてもよい。いくつかの実装では、二次タブ250内の具体的コンテンツは、マルチスタック仮想オブジェクト194内に記憶されてもよい。他の実装では、二次タブ250内に常駐するコンテンツ全体が、マルチスタック仮想オブジェクト194上に記憶および/または表示されてもよい。同様に、仮想Rolodex190は、二次タブ250からの具体的コンテンツを含有してもよい、または仮想Rolodex190は、二次タブ250内に常駐するコンテンツ全体を含有してもよい。
【0051】
垂直表面182は、窓ガラスまたは写真フレーム等の部屋(ユーザの物理的環境105として描写される)の主壁180上にすでにあり得る、任意のタイプの構造であってもよい。いくつかの実装では、垂直表面182は、空壁であってもよく、頭部搭載型システム160は、ユーザ108がメインビデオ220を閲覧するために適切な垂直表面182のフレームの最適サイズを決定する。垂直表面182のサイズの本決定は、少なくとも部分的に、主壁180からのユーザ108の距離、メインビデオ220のサイズおよび寸法、メインビデオ220の品質、非被覆壁空間の量、および/または主壁180を見ているときのユーザの姿勢に基づいてもよい。例えば、メインビデオ220の品質が、高精細である場合、垂直表面182のサイズは、メインビデオ220の品質が垂直表面182によって悪影響を受けないであろうため、より大きくてもよい。しかしながら、メインビデオ220のビデオ品質が、不良品質である場合、大垂直表面182を有することは、ビデオ品質を著しく下げ得、その場合、本開示の方法およびシステムは、垂直表面182をより小さくサイズ変更/再定義し、ピクシレーションからの不良ビデオ品質を最小限にしてもよい。
【0052】
垂直表面186は、垂直表面182のように、ユーザの物理的環境105内の隣接する壁(例えば、側壁184)上の垂直表面である。いくつかの実装では、ユーザ108の配向に基づいて、側壁184および垂直表面186は、勾配が付けられた傾斜表面であるように現れてもよい。勾配が付けられた傾斜表面は、垂直および水平表面に加えた、表面の配向のタイプであってもよい。YOUTUBE(登録商標)ウェブページから提案されるビデオ240は、側壁184上の垂直表面186上に設置され、ユーザ108が、本実施例では、単に、その頭部を若干右に移動させることによって、提案されるビデオを閲覧することが可能となることを可能にしてもよい。
【0053】
仮想Rolodex190は、頭部搭載型システム160によって作成され、ユーザ108に表示される、仮想オブジェクトである。仮想Rolodex190は、ユーザ108が、仮想ページのセットを通して双方向にサイクル表示させる能力を有してもよい。仮想Rolodex190は、ウェブページ全体を含有してもよい、または個々の記事またはビデオまたはオーディオを含有してもよい。本実施例に示されるように、仮想Rolodex190は、二次タブ250からのコンテンツの一部を含有してもよい、またはいくつかの実装では、仮想Rolodex190は、二次タブ250のページ全体を含有してもよい。ユーザ108は、単に、仮想Rolodex190内の特定のタブに合焦することによって、仮想Rolodex190内のコンテンツを通して、双方向にサイクル表示させてもよく、頭部搭載型システム160内の1つ以上のセンサ(例えば、センサ162)は、ユーザ108の眼焦点を検出し、仮想Rolodex190内のタブを通してサイクル表示し、故に、ユーザ108に関する関連情報を取得するであろう。いくつかの実装では、ユーザ108は、仮想Rolodex190からの関連情報を選定し、頭部搭載型システム160に、関連情報を利用可能な周囲表面またはユーザ108に近接近する仮想ディスプレイ(図示せず)等のさらに別の仮想オブジェクトのいずれか上に表示するように命令してもよい。
【0054】
仮想Rolodex190に類似する、マルチスタック仮想オブジェクト194は、1つ以上のタブからのフルコンテンツ、またはユーザ108が、ブックマークした、将来的閲覧のために保存した、または開いている(例えば、非アクティブタブ)、種々のウェブページまたはタブからの特定のコンテンツに及ぶ、コンテンツを含有してもよい。マルチスタック仮想オブジェクト194はまた、新聞の実世界スタックに類似する。マルチスタック仮想オブジェクト194内の各スタックは、特定の新聞記事、ページ、雑誌発行物、レシピ等に関連してもよい。当業者は、2Dコンテンツ要素または2Dコンテンツソースからのコンテンツを設置するための表面を提供する本同一目的を遂行するために、複数のタイプの仮想オブジェクトが存在し得ることを理解し得る。
【0055】
当業者は、ウェブブラウザ110によってアクセスまたは表示される2Dコンテンツが、単に、ウェブページ以上のものであってもよいことを理解し得る。いくつかの実装では、2Dコンテンツは、写真アルバムからの写真、映画からのビデオ、TV番組、YOUTUBE(登録商標)ビデオ、双方向フォーム等であってもよい。さらに他の実装では、2Dコンテンツは、電子書籍または書籍を表示する任意の電子手段であってもよい。最後に、他の実装では、2Dコンテンツは、2Dコンテンツが、概して、情報が現在提示される方法であるため、これまで説明されていない他のタイプのコンテンツであってもよい。電子デバイスが、2Dコンテンツを取り込むことができる場合、2Dコンテンツは、頭部搭載型システム160によって、2Dコンテンツを分解し、3D設定(例えば、AR)内に表示するために使用されることができる。
【0056】
いくつかの実装では、アクセスされた2Dコンテンツをマッピングするステップは、2Dコンテンツを抽出するステップ(例えば、ブラウザから)と、それを表面上に載上するステップ(コンテンツが、もはやブラウザ内になく、表面上にのみあるように)とを含んでもよく、いくつかの実装では、マッピングは、コンテンツを複製するステップ(例えば、ブラウザから)と、それを表面上に載上するステップ(コンテンツが、ブラウザ内および表面上の両方にあるように)とを含むことができる。
【0057】
2Dコンテンツを分解するステップは、インターネットおよびコンピュータ関連技術の領域に存在する、技術的問題である。ウェブページ等の2Dコンテンツは、HTML等のあるタイプのプログラミング言語を使用して構築され、コンピュータプロセッサおよび技術的コンポーネントに、ウェブページ内の要素をユーザのための画面上に表示する場所および方法を命令する。上記に議論されるように、ウェブ設計者は、典型的には、2Dキャンバス(例えば、画面)の限界内で作業し、要素(例えば、コンテンツ)を2Dキャンバス内で設置および表示する。HTMLタグは、HTMLドキュメントまたはHTMLドキュメント内の一部がフォーマットされる方法を決定するために使用される。いくつかの実装では、(抽出または複製された)2Dコンテンツは、HTMLタグ参照を維持することができ、いくつかの実装では、HTMLタグ参照は、再定義されてもよい。
【0058】
図3は、いくつかの実装による、3D環境内に表示されるべき2Dコンテンツを分解するための方法を図示する、フロー図である。本方法は、310において、2Dコンテンツを識別するステップと、320において、2Dコンテンツ内の要素を識別するステップと、330において、周囲表面を識別するステップと、340において、識別された2Dコンテンツ内の識別された要素を周囲表面を識別するステップから識別された表面にマッピングするステップと、350において、要素を仮想コンテンツとして選択された表面上に表示するステップとを含み、選択された表面は、要素と識別された表面のマッピングから選択される。
【0059】
310において、2Dコンテンツを識別するステップは、デジタルコンテンツを検索するために、頭部搭載型システム160の使用を伴ってもよい。310において、2Dコンテンツを識別するステップはまた、ネットワーク120に接続されるサーバ(例えば、記憶デバイス130)上のデジタルコンテンツにアクセスするステップを含んでもよい。310において、2Dコンテンツを識別するステップは、ユーザ108に関心があるウェブページに関して、インターネットをブラウジングするステップを含んでもよい。いくつかの実装では、310において、2Dコンテンツを識別するステップは、インターネット上でコンテンツを検索するためにユーザ108によって与えられる、音声アクティブ化コマンドを含んでもよい。例えば、ユーザ108は、デバイス(例えば、頭部搭載型システム160)と相互作用してもよく、ユーザ108は、ビデオを検索するためのコマンドを発し、次いで、ビデオの名称およびビデオの簡単な説明を伝えることにより、デバイスに特定のビデオを検索するように求めることによって、インターネット上の特定のビデオを検索する。デバイスは、次いで、インターネットを検索し、ビデオを2Dブラウザ上に取り込み、ユーザ108が、デバイスの2Dブラウザ上に表示されるにつれて、ビデオを見ることを可能にしてもよい。ユーザ108は、次いで、ビデオがユーザ108が空間3D環境内で閲覧することを所望するであろうビデオであることを確認してもよい。
【0060】
いったん2Dコンテンツが、識別されると、本方法は、320において、2Dコンテンツ内の要素を識別し、ユーザ108に表示するために、2Dコンテンツ内の利用可能な要素をインベントリ化する。2Dコンテンツ内の要素は、例えば、ウェブページ上に掲載されたビデオ、記事、およびニュースレター、ソーシャルメディアウェブサイト上のコメントおよびポスティング、ブログポスト、種々のウェブサイト上に掲載された写真、オーディオ書籍等を含んでもよい。2Dコンテンツ(例えば、ウェブページ)内のこれらの要素は、特定の要素が設置されるウェブページ上の場所、およびある場合には、要素がウェブページ上に表示されるべき時間および方法を定義するために、コンテンツ設計者によって提供されるHTMLタグと関連付けられた属性を有する、HTMLタグを含有してもよい。いくつかの実装では、本開示の方法およびシステムは、340におけるマッピングプロセスを補助し、要素を3D設定内に表示するための場所および方法を決定するために、これらのHTMLタグおよび属性をコンテンツ設計者によって提供されるヒントおよび提案として利用する。例えば、下記は、ウェブページ開発者によって提供される、例示的HTMLウェブページコードである。
【化1-1】
【化1-2】
【0061】
ウェブページ開発者によって提供される、例示的HTMLウェブページコードは、メインビデオをウェブページ上に表示する方法に関する選好と、推奨される(または提案される)ビデオを表示する方法に関する選好とを含む。特に、本HTMLウェブページコードは、「virtical」のタイプ値を使用して、ビデオを表示するための垂直表面を指定する、「style」のタグを使用して、メインビデオを表示するための方法を規定する。加えて、「style」タグ内に、ウェブページ開発者によって提供される付加的ヒントが、どのウェブページ(例えば、メインビデオ)内のHTML要素/コンテンツがどの潜在的表面積にマッピングされるべきかを優先順位化するために使用するためのマッチングアルゴリズムに関する「priority」選好を含んでもよい。例示的HTMLウェブページコードでは、優先順位は、垂直平面レイアウトを有するビデオに関して、100の値に設定され、本実施例では、より高い優先順位値は、より高い優先順位を示す。加えて、本実施例では、選好は、提案されるビデオを「horizontal」のタイプ値を有するスタック内にスタックレイアウトで設置するように、ウェブページ開発者によって示され、スタックされたオブジェクト(例えば、この場合、別の提案されるビデオに関連して提案されるビデオ)間の距離は、20cmである。
【0062】
図4は、いくつかの実装による、2Dコンテンツ内の要素を識別するための方法を図示する、フロー図である。
図4は、いくつかの実装による、
図3の320における2Dコンテンツ内の要素を識別するステップを開示する、詳細なフローである。
図4は、410において、
図3の320において2Dコンテンツ内の要素を識別するステップに類似する、2Dコンテンツ内の要素を識別するステップから開始する。本方法は、420において、タグからコンテンツの設置に関する属性を識別する次のブロックに進む。上記に議論されるように、ウェブページ設計者は、ウェブページを設計および構成する際、ウェブページ内の要素とHTMLタグを関連付け、各要素を表示するための場所および方法を定義し得る。これらのHTMLタグはまた、ウェブページの特定の部分上への要素の設置に関する属性を含んでもよい。頭部搭載型システム160が、検出し、システムの他のコンポーネントと協調し、特定の要素が表示され得る場所に関する入力として使用し得るものは、これらのHTMLタグおよびその属性である。
【0063】
ヒントまたはタグを各要素から抽出するステップが、430において実施される。ヒントまたはタグは、典型的には、2Dコンテンツ/ウェブページのコンテンツ設計者および/またはウェブページ開発者によって提供される、フォーマット化ヒントまたはフォーマット化タグである。上記に議論されるように、コンテンツ設計者は、例えば、「ウェブページ開発者によって提供される例示的HTMLウェブページコード」に示されるように、HTMLタグの形態において、命令またはヒントを提供し、ウェブブラウザ110に、2Dコンテンツの要素をページまたは画面の特定の部分内に表示するように命令してもよい。いくつかの実装では、ウェブページ設計者は、付加的HTMLタグ属性を使用して、付加的フォーマット化ルールを定義してもよい。例えば、ユーザが、具体的色(例えば、赤色)に対して低減された感度を有する場合、赤色を表示せず、代わりに、別の色を使用する、または上記に議論されるように、垂直表面上に表示されるべき選好を有するビデオが、垂直表面上に表示されることができない場合、代替として、ビデオを別の(物理的)表面上に表示する、または仮想表面を作成し、ビデオを仮想表面上に表示する。下記は、HTMLページを通して解析し、ヒント/タグをHTMLページ内の各要素から抽出するためにブラウザ内に実装される、例示的HTMLページパーサである。
【化2-1】
【化2-2】
【化2-3】
【化2-4】
【0064】
例示的HTMLページパーサは、2Dコンテンツ(例えば、ウェブページ)内の特定の要素/オブジェクトに関する表示選好を提供するために使用される、HTMLタグを含有するHTMLページが、解析および識別および/または抽出/複製され得る方法を示す。例示的HTMLページパーサに開示されるように、2Dコンテンツ(例えば、ウェブページ)内の要素は、開示されるサンプルコードを使用して解析されることができる。種々の要素名および値を使用する、あるHTMLタグが、HTMLページパーサ(例えば、ML.layout、ML.container等)によって識別/抽出され、特定の要素が3D環境内でユーザに表示されるための方法(例えば、要素を特定の表面にマッピングすることによって)を決定してもよい。
【0065】
1つ以上の要素のための代替表示形態をルックアップ/検索するステップが、440において実施される。あるフォーマット化ルールが、ウェブページ上の画像のために規定されてもよい。例えば、ウェブブラウザ110が、画像の3Dバージョンを表示することが可能である場合、ウェブページ設計者は、付加的タグを設置し、または特定のタグのある属性を定義し、ウェブブラウザ110が、画像が画像の代替バージョン(例えば、画像の3Dバージョン)を有し得ることを認識することを可能にしてもよい。ウェブブラウザ110は、次いで、3D対応ブラウザ内に表示されるべき画像の代替バージョン(例えば、画像の3Dバージョン)にアクセスしてもよい。
【0066】
2Dコンテンツ内の識別された要素を記憶するステップが、450において実施される。本方法は、マッピングルーチン(例えば、
図3の340における要素を識別された表面にマッピングするステップ)によって使用され、要素を特定の表面にマッピングするために、識別された要素を非一過性記憶媒体の中に記憶してもよい。非一過性記憶媒体は、記憶デバイス130またはローカル記憶デバイス140等のデータ記憶デバイスを含んでもよい。要素は、下記に説明される
図5に開示されるテーブル等の特定のテーブル内に記憶されてもよい。いくつかの実装では、2Dコンテンツ内の識別された要素は、一過性記憶媒体内に記憶されてもよい。
【0067】
図5は、いくつかの実装による、2Dコンテンツから分解された要素を記憶するためのテーブルの実施例を示す。要素テーブル500は、
図4の410において2Dコンテンツ内の要素を識別するステップの結果をデータベース内に記憶し得る、例示的テーブルである。要素テーブル500は、例えば、要素識別(ID)510、要素が3D表面上に設置され得る場所に関する選好インジケータ520、特定の要素が親要素内に含まれる場合の親要素ID530、要素が子要素を含有し得る場合の子要素ID540、および要素を表示するために使用される表面または仮想オブジェクトに要素の複数のバージョンを表示することと互換性を持たせる必要性を正当化し得る、要素が複数の実装を含有するかどうかを示すための多重エンティティインジケータ550を含む、2Dコンテンツ内の1つ以上の要素についての情報を含む。親要素は、サブ要素(例えば、子要素)を含有し得る、2Dコンテンツ内の要素/オブジェクトである。例えば、220の値を有する、要素ID(例えば、メインビデオ220)は、260の親要素ID値(例えば、アクティブタブ260)を有し、これは、メインビデオ220が、アクティブタブ260の子要素であることを示す。または換言すると、メインビデオ220は、アクティブタブ260内に含まれる。同一実施例を継続すると、メインビデオ220は、子要素ID230(例えば、ユーザコメント230)を有し、これは、ユーザコメント230がメインビデオ220と関連付けられることを示す。当業者は、要素テーブル500が、関係データベースまたは任意のタイプのデータベース内のテーブルであってもよいことを理解し得る。加えて、要素テーブル500は、
図4の410において2Dコンテンツ内の要素を識別するステップの結果を含有する、コンピュータメモリ(例えば、キャッシュ)内のアレイであってもよい。
【0068】
要素テーブル500内の行560の各行は、ウェブページ内からの要素に対応する。要素ID510は、要素毎の一意の識別子(例えば、要素ID)を含有する、列である。いくつかの実装では、要素の一意性は、テーブル内の要素ID510列と別の列(例えば、コンテンツ設計者によって識別される1つを上回る選好が存在する場合の選好520列)の組み合わせとして定義されてもよい。選好520は、その値が、少なくとも部分的に、コンテンツ設計者/開発者(例えば、ウェブページ設計者)によって定義され、
図4の430においてヒントまたはタグを各要素から抽出するステップに開示されるように、本システムおよび方法によって識別される、HTMLタグおよび属性に基づいて決定され得る、列である。他の実装では、選好520列は、少なくとも部分的に、所定のブラウザルールに基づいて決定され、ウェブページ内のあるタイプの要素が3D環境内に表示されるべき場所を規定してもよい。これらの所定のルールは、本システムおよび方法に、要素を3D環境内に最良に設置するための場所を決定するための提案を提供し得る。
【0069】
親要素ID530は、本行内の本特定の要素が、その中に表示される、またはそれに関連する、親要素の要素IDを含有する、列である。ウェブページ内の特定の要素は、内蔵される、ページの別の要素内に設置される、またはページ上の別の要素に関連してもよい。例えば、一実装では、要素ID510列の第1のエントリは、
図2のメインビデオ220に対応する要素ID220の値を記憶する。メインビデオ220に対応する選好520列内の選好値は、HTMLタグおよび/または属性に基づいて決定され、本実装では、本要素が、ユーザの物理的環境105の「主要」な場所内に設置されるべきであるとされる。ユーザ108の現在の場所に応じて、その主要な場所は、居間内の壁、またはユーザ108が現在見ている台所のコンロの上のフードであってもよい、または広開放空間内に居る場合、メインビデオ220がその上に投影され得る、ユーザ108の視線の正面に投影される仮想オブジェクトであってもよい。2Dコンテンツの要素がユーザ108に表示される方法に関するさらなる情報は、後の節に開示されるであろう。本実施例を継続すると、親要素ID530列は、
図2のアクティブタブ260に対応する、要素ID260の値を記憶する。したがって、メインビデオ220は、アクティブタブ260の子である。
【0070】
子要素ID540は、本行内の本特定の要素が、その中に表示されている、またはそれに関連する、子要素の要素IDを含有する、列である。ウェブページ内の特定の要素は、内蔵される、ページの別の要素内に設置される、またはページ上の別の要素に関連してもよい。本実施例を継続すると、子要素ID540列は、
図2のユーザコメント230に対応する、要素ID230の値を記憶する。
【0071】
多重エンティティインジケータ550は、要素を表示するために使用される表面または仮想オブジェクトに要素の複数のバージョンを表示することと互換性を持たせる必要性を正当化し得る、要素が多重エンティティを含有するかどうかを示す、列である(例えば、要素は、ユーザコメント230であってもよく、メインビデオ220に関して、利用可能な1つを上回るコメントが存在してもよい)。本実施例を継続すると、多重エンティティインジケータ550列は、「N」の値を記憶し、メインビデオ220が、複数のメインビデオをアクティブタブ260内に有していない、またはそれに対応しない(例えば、メインビデオ220の複数のバージョンが「ない」)ことを示す。
【0072】
本実施例を継続すると、要素ID510列の第2のエントリは、
図2のユーザコメント230に対応する、要素ID230の値を記憶する。ユーザコメント230に対応する、選好520列内の選好値は、「水平」の選好を示し、ユーザコメント230が、ユーザの物理的環境105内のいずれかの場所の「水平」表面上に設置されるべきであることを示す。上記に議論されるように、水平表面は、ユーザの物理的環境105内の利用可能な水平表面に基づいて決定されることができる。いくつかの実装では、ユーザの物理的環境105は、水平表面を有していない場合があり、その場合、本開示のシステムおよび方法は、水平表面を伴う仮想オブジェクトを識別/作成し、ユーザコメント230を表示してもよい。本実施例を継続すると、親要素ID530列は、
図2のメインビデオ220に対応する、値要素ID220を記憶し、多重エンティティインジケータ550列は、「Y」の値を記憶し、ユーザコメント230が1つを上回る値(例えば、1つを上回るユーザコメント)を含有し得ることを示す。
【0073】
要素テーブル500内の残りの行は、ユーザ108に関心がある残りの要素に関する情報を含有する。当業者は、410において2Dコンテンツ内の要素を識別するステップの結果を記憶することが、いったん本分析が2Dコンテンツ上で実施されると、別のユーザが同一2Dコンテンツに関心がある場合に、2Dコンテンツの将来的分析のために本システムおよび方法によって留保され得るため、コンピュータ自体の機能を改良することを理解し得る。本特定の2Dコンテンツを分解するためのシステムおよび方法は、以前にすでに完了されているため、回避されてもよい。
【0074】
いくつかの実装では、要素テーブル500は、記憶デバイス130内に記憶されてもよい。他の実装では、要素テーブル500は、最近閲覧した2Dコンテンツへの迅速なアクセスのために、または最近閲覧された2Dコンテンツへの可能性として考えられる再訪問のために、ローカル記憶デバイス140内に記憶されてもよい。さらに他の実装では、要素テーブル500は、ユーザ108から遠隔に位置する記憶デバイス130と、ユーザ108のローカルで位置するローカル記憶デバイス140との両方に記憶されてもよい。
【0075】
図3に戻ると、本方法は、330において、周囲表面を識別するステップを継続する。ユーザ108は、頭部搭載型システム160を通して、ユーザの物理的環境105を視認し、頭部搭載型システム160が、壁、テーブル、絵画、窓枠、コンロ、冷蔵庫、TV等の周囲表面を捕捉および識別することを可能にしてもよい。頭部搭載型システム160は、頭部搭載型システム160上のセンサおよびカメラのため、または任意の他のタイプの類似デバイスを用いて、ユーザの物理的環境105内の実オブジェクトを認知する。いくつかの実装では、頭部搭載型システム160は、ユーザの物理的環境105内で観察される実オブジェクトと記憶デバイス130またはローカル記憶デバイス140内に記憶される仮想オブジェクトをマッチングさせ、そのような仮想オブジェクトとともに利用可能な表面を識別してもよい。実オブジェクトは、ユーザの物理的環境105内で識別されたオブジェクトである。仮想オブジェクトは、ユーザの物理的環境内に物理的に存在しないが、仮想オブジェクトがユーザの物理的環境内に存在するかのように現れるようにユーザに表示され得る、オブジェクトである。例えば、頭部搭載型システム160は、ユーザの物理的環境105内のテーブルの画像を検出してもよい。テーブル画像は、記憶デバイス130またはローカル記憶デバイス140における迅速かつ効率的比較およびマッチングのために、3D点群オブジェクトに縮小されてもよい。実オブジェクトと(例えば、テーブルの)3D点群オブジェクトのマッチングが、検出される場合、本システムおよび方法は、テーブルを表す3D点群オブジェクトが水平表面を有するように定義されるため、水平表面を有するとテーブルを識別することができる。周囲表面を識別するステップのより詳細な説明は、下記の
図6に開示される。
【0076】
いくつかの実装では、仮想オブジェクトは、抽出されたオブジェクトであってもよく、抽出されたオブジェクトは、ユーザの物理的環境105内で識別された物理的オブジェクトであってもよいが、付加的処理および関連付けが、物理的オブジェクト自体上で行われることが不可能であろう、抽出されたオブジェクトに行われ得るように(例えば、物理的オブジェクトの色を変化させ、物理的オブジェクトの特定の特徴をハイライトする等のために)、物理的オブジェクトの場所内の仮想オブジェクトとしてユーザに表示される。加えて、抽出されたオブジェクトは、2Dコンテンツ(例えば、ブラウザからのウェブページ)から抽出され、ユーザ108に表示される、仮想オブジェクトであってもよい。例えば、ユーザ108は、ユーザの物理的環境105内に表示されるように、2Dコンテンツ/ウェブページ上に表示されるウェブページからの長椅子等のオブジェクトを選定してもよい。システムは、選定されたオブジェクト(例えば、長椅子)を認識し、抽出されたオブジェクト(例えば、長椅子)がユーザの物理的環境105内に物理的に存在するかのように、抽出されたオブジェクト(例えば、長椅子)をユーザ108に表示してもよい。加えて、仮想オブジェクトはまた、ユーザの物理的環境105に物理的に存在さえしないが、2Dコンテンツからのコンテンツを表示する観点から、あるコンテンツをユーザに提示するために理想的ディスプレイ表面であり得る、コンテンツを表示するための表面(例えば、あるコンテンツを閲覧するためにユーザに近接近する透明ディスプレイ画面)を有する、オブジェクトを含んでもよい。
【0077】
図6は、いくつかの実装による、ユーザのローカル環境からの表面を識別するための方法を図示する、フロー図である。
図6は、
図3の330において周囲表面を識別するステップを開示する、詳細なフローである。
図6は、610において、
図3の330における周囲表面を識別するステップに類似する、ユーザの現在の周囲を識別するステップから開始する。本方法は、620において、ユーザの姿勢を決定する次のブロックに進む。
【0078】
620において、ユーザの姿勢を決定するステップは、ユーザの姿勢が、ユーザの物理的環境105内のオブジェクトに関連してユーザ108に関する目線を提供することができるため、ユーザの現在の周囲を識別するためのブロックである。例えば、
図1に戻って参照すると、ユーザ108は、頭部搭載型システム160を使用して、ユーザの物理的環境105を観察する。620において、ユーザの姿勢(例えば、世界に対するベクトルおよび/または原位置情報)を決定するステップは、頭部搭載型システム160が、例えば、(1)地面に関連したユーザ108の身長、(2)ユーザ108が、部屋を動き回り、その画像を捕捉するために、その頭部を回転させる必要がある角度、および(3)ユーザ108と、テーブル188、主壁180、および側壁184との間の距離を理解することに役立つことができる。加えて、ユーザ108の姿勢はまた、垂直表面182および186を、ユーザの物理的環境105内の他の表面とともに観察するとき、頭部搭載型システム160の角度を決定するために有用である。
【0079】
630では、本方法は、周囲表面の寸法を識別する。ユーザの物理的環境105内の各候補表面は、タグ付けされ、対応する寸法とともにカテゴリ化される。いくつかの実装では、ユーザの物理的環境105内の各候補表面はまた、タグ付けされ、対応する配向とともにカテゴリ化される。本情報は、少なくとも部分的に、表面の寸法、表面の配向、特定の表面から離れたユーザ108の距離、および要素のために表示される必要がある情報のタイプに基づいて、どの要素がどの表面にマッピングされるべきであるかを識別するために有用となり得る。例えば、ビデオは、記事のテキストサイズが、小寸法を伴う離れた壁上に表示される場合、小さすぎてユーザが見ることができない場合がある、豊富な情報を含有し得る、ブログまたは記事より離れて示され得る。
【0080】
640では、本方法は、要素を特定の表面にマッピングするために、マッピングルーチン(例えば、要素を
図3の識別された表面340にマッピングするステップ)によって使用されるために、周囲表面のインベントリを非一過性記憶媒体の中に記憶する。非一過性記憶媒体は、記憶デバイス130またはローカル記憶デバイス140等のデータ記憶デバイスを含んでもよい。識別された表面は、下記に説明される
図7に開示されるテーブル等の特定のテーブル内に記憶されてもよい。いくつかの実装では、識別された表面は、一過性記憶媒体内に記憶されてもよい。
【0081】
図7は、いくつかの実装による、ユーザのローカル環境から識別された表面のインベントリを記憶するためのテーブルの実施例を示す。表面テーブル700は、周囲表面を識別するプロセスの結果をデータベース内に記憶し得る、例示的テーブルである。表面テーブル700は、例えば、表面ID710、幅720、高さ730、配向740、実または仮想インジケータ750、多重性760、および位置770を含む、データ列を有する、ユーザの物理的環境105内の表面についての情報を含む。当業者は、表面テーブル700が、関係データベースまたは任意のタイプのデータベース内のテーブルであってもよいことを理解し得る。加えて、表面テーブル700は、
図3の330において周囲表面を識別するステップの結果を記憶する、コンピュータメモリ(例えば、キャッシュ)内のアレイであってもよい。
【0082】
表面テーブル700内の行780の各行は、ユーザの物理的環境105からの表面、またはユーザの物理的環境105内でユーザ108に表示され得る、仮想表面に対応してもよい。表面ID710は、特定の表面を一意に識別するための一意の識別子(例えば、表面ID)を含有する、列である。特定の表面の寸法は、幅720および高さ730列内に記憶される。
【0083】
配向740は、ユーザ108に対する表面の配向(例えば、垂直、水平等)を示す、列である。実/仮想インジケータ750は、特定の表面が、ユーザ108によって頭部搭載型システム160を使用して知覚されるようなユーザの物理的環境105内の実オブジェクト上に位置するかどうか、または特定の表面が、頭部搭載型システム160によって生成され、ユーザの物理的環境105内に表示され得る、仮想オブジェクト上に位置するかどうかを示す、列である。頭部搭載型システム160は、ユーザの物理的環境105が、ユーザ108が表示することを所望するコンテンツの量を表示するための十分な表面を含有し得ない状況のために、仮想オブジェクトを生成する必要があり得る。これらの実装では、頭部搭載型システム160は、表示のために識別されたあるタイプの要素を表示するための適切な表面寸法を有し得る、既存の仮想オブジェクトのデータベースから検索してもよい。データベースは、記憶デバイス130またはローカル記憶デバイス140からのものであってもよい。
【0084】
多重性760は、表面/オブジェクトが要素の複数のバージョンを表示することと互換性があるかどうかを示す、列である(例えば、要素は、
図2の二次タブ250であってもよく、特定のウェブブラウザ110に関して、1つを上回る二次(例えば、非アクティブ)タブ(例えば、タブあたり1つのウェブページ)が存在してもよい。
図2の仮想Rolodex190に対応する190の値を記憶する、表面ID列の第4のエントリ、および
図2のマルチスタック仮想オブジェクト194に対応する194の値を記憶する、表面ID列の第5のエントリの場合等、複数の760列が、「多重」の値を有する場合、本システムおよび方法は、非アクティブタブに関する場合のように、要素の複数のバージョンを有し得る要素が存在する場合、これらが、複数のバージョンに適応し得る表面のタイプであることを決定することができる。
【0085】
位置770は、基準フレームまたは基準点に対する物理的表面の位置を示す、列である。物理的表面の位置は、
図7における位置770の列ヘッダに示されるように、表面の中心であると事前決定されてもよい。他の実装では、位置は、表面の別の基準点(例えば、表面の正面、背面、上面、または底面)であると事前決定されてもよい。位置情報は、ある基準フレームまたは基準点に対する物理的表面の中心からのベクトルおよび/または位置情報として表され得る。表面テーブル700内の位置を表すためのいくつかの方法が、存在し得る。例えば、表面テーブル700内の表面ID194に関する位置の値は、ベクトル情報および基準フレーム情報(例えば、「フレーム」添字)を例証するように理論上表される。x,y,zは、各空間寸法内の3D座標であって、フレームは、3D座標が対する基準フレームを示す。
【0086】
例えば、表面ID186は、実世界原点に対して(1.3、2.3、1.3)であるように、表面186の中心の位置を示す。別の実施例として、表面ID192は、ユーザ基準フレームに対して(x,y,z)であるように、表面192の中心の位置を示し、表面ID190は、別の表面182に対して(x,y,z)であるように、表面190の中心の位置を示す。基準フレームは、現在使用されている基準フレームを明確にするために重要である。基準フレームとしての実世界原点の場合、これは、概して、静的基準フレームである。しかしながら、基準フレームがユーザ基準フレームである、他の実装では、ユーザは、基準フレームを移動させ得、その場合、平面(またはベクトル情報)は、ユーザが、移動しており、ユーザ基準フレームが基準フレームとして使用される場合、ユーザに伴って移動および変化し得る。いくつかの実装では、表面毎の基準フレームは、同一(例えば、ユーザ基準フレーム)であってもよい。他の実装では、表面テーブル700内に記憶される表面のための基準フレームは、表面に応じて、異なり得る(例えば、ユーザ基準フレーム、世界基準フレーム、部屋内の別の表面またはオブジェクト等)。
【0087】
本実施例では、表面テーブル700内に記憶される値は、
図2のユーザの物理的環境105内で識別された物理的表面(例えば、垂直表面182および186および水平表面192)と、仮想表面(例えば、仮想Rolodex190およびマルチスタック仮想オブジェクト194)とを含有する。例えば、本実装では、表面ID710列の第1のエントリは、
図2の垂直表面182に対応する、表面ID182の値を記憶する。垂直表面182の幅および高さに対応する、幅720列内の幅値および高さ730列内の高さ値は、それぞれ、垂直表面182は、48インチ(W)×36インチ(H)の寸法を有することを示す。同様に、垂直表面182を示す、配向740列内の配向値は、「垂直」の配向を有する。加えて、垂直表面182を示す、実/仮想インジケータ750列内の実/仮想値は、「R」(例えば、実)表面である。複数の760列内の多重性値は、垂直表面182が「単一」(例えば、単一コンテンツのみを保持することができる)であることを示す。最後に、位置770列は、(2.5,2.3,1.2)
userのベクトル情報を用いて、ユーザ108に対する垂直表面182の位置を示す。
【0088】
表面テーブル700内の残りの行は、ユーザの物理的環境105内の残りの表面に関する情報を含有する。当業者は、いったん本分析が周囲表面上で実施されると、別のユーザまたは同一ユーザ108が同一物理的環境105内に居るが、異なる2Dコンテンツに関心がある場合に、ユーザの周囲表面の将来的分析のために、頭部搭載型システム160によって留保され得るため、
図3の330において周囲表面を識別するステップの結果を記憶することが、コンピュータ自体の機能を改良することを理解し得る。330において周囲表面を識別するための処理ブロックは、これらの処理ブロックが以前にすでに完了されているため、回避されてもよい。唯一の差異は、少なくとも部分的に、異なる2Dコンテンツを伴う要素を識別する要素テーブル500に基づいて、利用可能である付加的または異なる仮想オブジェクトを識別するステップを含み得る。
【0089】
いくつかの実装では、表面テーブル700は、記憶デバイス130内に記憶される。他の実装では、表面テーブル700は、最近閲覧した2Dコンテンツへの迅速アクセスのために、または最近閲覧した2Dコンテンツへの可能性として考えられる再訪問のために、ユーザ108のローカル記憶デバイス140内に記憶される。さらに他の実装では、表面テーブル700は、ユーザ108から遠隔に位置する記憶デバイス130と、ユーザ108のローカルで位置するローカル記憶デバイス140との両方に記憶されてもよい。
【0090】
図3に戻ると、本方法は、340において、320において2Dコンテンツ内の要素を識別するステップから識別された要素と、330において周囲表面を識別するステップから識別された周囲表面との組み合わせを使用して、いくつかの実装では、仮想オブジェクトを付加的表面として使用して、要素を識別された表面にマッピングするステップを継続する。識別された要素を識別された表面にマッピングするステップは、複数の要因を伴ってもよく、そのうちのいくつかは、上記に議論される例示的HTMLページパーサ等のHTMLページパーサを使用することによって、2Dコンテンツ設計者/制作者によって定義されたHTMLタグ要素を介して2Dコンテンツ設計者/制作者によって提供されるヒントを分析するステップを含んでもよい。他の要因は、ARブラウザ、ARインターフェース、および/またはクラウド記憶装置によって提供されるようなある2Dコンテンツをマッピングするための方法および場所の事前に定義されたルールのセットから選択するステップを含んでもよい。
図8は、2Dコンテンツからの1つ以上の要素を識別された表面にマッピングするマッピングプロセスの詳細なフローを提供する。
【0091】
図8は、いくつかの実装による、2Dコンテンツからの要素を表面にマッピングするための方法を図示する、フロー図を描写する。
図8は、要素を
図3の340において識別された表面にマッピングするステップを開示する、詳細なフローである。
【0092】
810では、本方法は、識別された要素が2Dコンテンツ設計者によって提供されるヒントを含有するかどうかを決定する。2Dコンテンツ設計者は、2Dコンテンツ設計者が2Dコンテンツを最初に設計したとき、特定の要素を最良に表示するための場所に関するヒントを提供してもよい。例えば、
図2のメインビデオ220は、アクティブタブ260内のウェブページ上に表示される、YOUTUBE(登録商標)ビデオであってもよい。2Dコンテンツ設計者(例えば、ウェブページ設計者)は、メインビデオ220が、ユーザ108の直視状態において、平坦垂直表面上に最良に表示されることを示すためのヒントを提供してもよい。いくつかの実装では、これは、2Dウェブページコンテンツのために最初に設計された既存のHTMLタグ要素を使用して、3Dディスプレイ環境が利用可能である場合、2Dコンテンツ内の特定のコンテンツ要素が表示され得る方法をさらに定義することによって、遂行されてもよい。別の実施例として、2Dコンテンツ設計者は、特定のウェブページに関する2D画像の代わりに、3D画像が利用可能であることを記述する、ヒントを提供してもよい。例えば、2D画像の場合、2Dコンテンツ設計者は、基本HTMLタグを提供し、2Dコンテンツのソースを識別することに加え、他の殆ど使用されないHTMLタグを提供して、2D画像の3Dバージョンのソースを識別し、加えて、画像の3Dバージョンが使用される場合、ユーザのビューの正面(例えば、3Dレイアウトのメインフレーム内)においてそれを顕著に表示させるためのヒントを提供してもよい。いくつかの実装では、2Dコンテンツ設計者は、2Dコンテンツをレンダリングするウェブブラウザ110が向上された3D画像を活用するための3D表示機能性を有し得る場合に備えて、本付加的「ヒント」を2D画像の3D画像場所に提供してもよい。当業者は、特定のコンテンツ要素が本明細書に開示されたもの以外の2Dレイアウトで設置されるべき場所に関して、2Dコンテンツ設計者がヒントを提供し得る、多くの他の方法が存在し、これらが、2Dコンテンツ設計者が2Dコンテンツ内のあるまたは全ての要素を最良に表示するためのヒントを提供し得る、異なる方法のいくつかの実施例であることを理解し得る。
【0093】
別の実装では、HTMLタグ規格は、上記に議論されるウェブページ開発者によって提供される例示的HTMLウェブページ等のAR/VR特有のタイプのブラウザのためのユーザの周囲内への3Dオブジェクト設置のヒントを提供するために、新しいHTMLタグまたは類似マークアップ言語の作成を含んでもよい。本書の時点で、これらの新しいHTMLタグは、HTML言語内の標準タグとしてまだ作成および/または採用されていない。しかしながら、いったんHTML規格が、これらのタイプの付加的タグを含むと、本方法およびシステムのある実装は、これらの新しいタグを活用し、さらに、識別された要素の識別された表面へのマッピングを提供する。当業者は、コンテンツ要素が3D環境内に表示されるべき方法に関するヒントをさらに提供するように修正または採用され得る、HTMLタグ以外の多くの他の言語が存在し、新しいHTMLタグ付け規格が、単に、そのような目標を達成するための1つの方法であることを理解し得る。
【0094】
820では、本方法は、2Dコンテンツ設計者によって提供されるヒントを使用するか、または2Dコンテンツからの1つ以上のコンテンツ要素をあるタイプの3D表面にマッピングするための事前に定義されたルールのセットを使用するかどうかを決定する。いくつかの実装では、特定のコンテンツ要素のための2Dコンテンツ設計者によって提供されるヒントが存在しない場合、本システムおよび方法は、事前に定義されたルールのセットを使用して、コンテンツ要素を表面にマッピングするための最良方法を決定してもよい。他の実装では、2Dコンテンツ設計者によって提供されるコンテンツ要素の設置のためのヒントが存在し得るときでも、本システムおよび方法はまた、事前に定義されたルールのセットを使用して、コンテンツ要素を表面にマッピングすることが最良であり得ることを決定してもよい。しかしながら、他の実装では、本システムおよび方法は、2Dコンテンツ設計者によって提供されるヒントが、十分であって、したがって、ヒントを使用して、コンテンツ要素を表面にマッピングすることを決定してもよい。最終的に、2Dコンテンツ設計者によって提供されるヒントを使用するか、または事前に定義されたルールを使用して、コンテンツ要素を表面にマッピングするかどうかを決定することは、ARブラウザの最終決定となる。
【0095】
830では、2Dコンテンツ設計者によって提供されるヒントを使用することが、進めるべき方法であると決定されたと仮定して、本方法は、ヒントを分析し、少なくとも部分的に、ヒントに基づいて(例えば、表面テーブル700にクエリする)、特定のコンテンツ要素を表示するために使用され得る、識別された周囲表面のインベントリを検索する。840では、本方法は、最良適合アルゴリズムを起動させ、提供されるヒントに基づいて、特定のコンテンツ要素のための最良適合表面を選定する。最良適合アルゴリズムは、例えば、特定のウェブページ内の特定のコンテンツ要素のための「メインコンテンツ」のヒントを得て、3D環境内のユーザ108に対して正面および中心にある利用可能な識別された周囲表面の中から3D表面を識別することを試み得る。例えば、
図2のメインビデオ220は、メインビデオ220が、「メイン」の選好値をアクティブタブ260内の
図5の要素テーブル500の選好520列内に有し、垂直表面182が、ユーザ108の直視状態にあって、メインビデオ220を表示するための最適定寸寸法を有する、表面であるため、垂直表面182にマッピングされる。
【0096】
850では、本方法は、表面が識別された周囲表面またはユーザの周囲環境内に表示される仮想オブジェクトかどうかにかかわらず、コンテンツ要素をそのそれぞれマッピングされた表面上に表示するために表示アルゴリズムによって使用されるように、要素の表面テーブルへのマッピングにおけるコンテンツ要素のためのマッピング結果を非一過性記憶媒体内に記憶する。非一過性記憶媒体は、記憶デバイス130またはローカル記憶デバイス140等のデータ記憶デバイスを含んでもよい。マッピング結果は、下記に説明される
図9に開示されるテーブル等の特定のテーブル内に記憶されてもよい。
【0097】
図9は、いくつかの実装による、2Dコンテンツからのコンテンツ要素の表面へのマッピングを記憶するためのテーブルの実施例を示す。マッピングテーブル900は、表面にマッピングされたコンテンツ要素の結果をデータベースの中に記憶する、例示的テーブルである。マッピングテーブル900は、例えば、コンテンツ要素(例えば、要素ID)およびコンテンツ要素がマッピングされた表面(例えば、表面ID)についての情報を含む。当業者は、マッピングテーブル900が、関係データベースまたは任意のタイプのデータベースまたは記憶媒体内に記憶されるテーブルであってもよいことを理解し得る。加えて、マッピングテーブル900は、
図3の340において要素の識別された周囲表面へのマッピングの結果を含有する、コンピュータメモリ(例えば、キャッシュ)内のアレイであってもよい。
【0098】
マッピングテーブル900の各行は、ユーザの物理的環境105内の表面、または仮想オブジェクトがユーザの物理的環境105内のオブジェクトであるように現れる、ユーザ108に表示される仮想オブジェクトのいずれかにマッピングされる、2Dコンテンツからのコンテンツ要素に対応する。例えば、本実装では、要素ID列の第1のエントリは、メインビデオ220に対応する、要素ID220の値を記憶する。メインビデオ220に対応する、表面ID列内の表面ID値は、垂直表面182に対応する、182である。このように、メインビデオ220は、垂直表面182にマッピングされる。同様に、ユーザコメント230は、水平表面192にマッピングされ、提案されるビデオ240は、垂直表面186にマッピングされ、二次タブ250は、仮想Rolodex190にマッピングされる。マッピングテーブル900内の要素IDは、
図5の要素テーブル500内に記憶される要素IDと関連付けられてもよい。マッピングテーブル900内の表面IDは、
図7の表面テーブル700内に記憶される表面IDと関連付けられてもよい。
【0099】
図8に戻ると、860では、所定のルールを使用することが、進めるべき方法であると決定されたと仮定して、本方法は、コンテンツ要素の表面へのマッピングルールを含有するデータベースにクエリし、ウェブページ内の特定のコンテンツ要素のために、コンテンツ要素をマッピングするために検討されるべき表面のタイプを決定する。例えば、
図2からのメインビデオ220のために返されるルールは、メインビデオ220が垂直表面にマッピングされるべきであることを示し得、したがって、表面テーブル700を検索後、複数の候補表面が、明らかにされる(例えば、垂直表面182および186および仮想Rolodex190)。870では、事前に定義されたルールのセットは、最良適合アルゴリズムを起動し、利用可能な候補表面から、本メインビデオ220のための最良適合である表面を選定してもよい。少なくとも部分的に、最良適合アルゴリズムに基づいて、候補表面の全てのうち、垂直表面182が、ユーザ108の直接通視線内にある表面であって、垂直表面182が、ビデオを表示するために最良寸法を有するため、メインビデオ220が垂直表面182にマッピングされるべきであることが決定される。いったん1つ以上の要素のマッピングが、850において決定されると、本方法は、上記に説明されるように、要素の表面テーブルへのマッピングにおけるコンテンツ要素のためのマッピング結果を非一過性記憶媒体内に記憶する。
【0100】
図3に戻ると、本方法は、350において、1つ以上の要素を仮想コンテンツとしてマッピングされた表面上に表示するステップを継続する。頭部搭載型システム160は、情報を表示するためのミニプロジェクタ(図示せず)等の1つ以上のディスプレイデバイスを頭部搭載型システム160内に含んでもよい。1つ以上の要素が、340においてマッピングされたように、個別のマッピングされた表面上に表示される。頭部搭載型システム160を使用して、ユーザ108は、コンテンツが個別のマッピングされた表面上に見え得る。当業者は、コンテンツ要素が、種々の表面(物理的または仮想)上に物理的に取り付けられるように現れるように表示されるが、コンテンツ要素は、実際には、ユーザ108によって知覚されるように物理的表面上に投影され、仮想オブジェクトの場合、仮想オブジェクトが、仮想オブジェクトの個別の表面上に取り付けられるように現れるように表示されることを理解し得る。当業者は、ユーザ108が、その頭部を方向転換させる、または上または下を見るとき、頭部搭載型システム160内のディスプレイデバイスが、コンテンツ要素がその個別の表面に継続して添着されたままにし、ユーザ108に、コンテンツがマッピングされた表面に添着されているという知覚をさらに提供し得ることを理解し得る。他の実装では、ユーザ108は、ユーザ108の頭部、手、眼によって行われる運動、または音声によって、ユーザの物理的環境105のコンテンツを変化させてもよい。
改良されたブラウザ/アプリケーション実装
【0101】
複合現実システムでは、ユーザの作業空間は、ディスプレイ画面のサイズによって限定されない。したがって、従来のブラウザと異なり、複合現実システム内のブラウザウィンドウは、ユーザの環境内の任意の場所に設置および保定されることができる。問題は、従来のブラウザ技術が、表示可能ブラウザ場所がディスプレイ画面の範囲に限定されなければならないという仮定とともに構成されることである。
【0102】
本開示の以下の部分は、複合現実環境内でウィンドウを閲覧するための改良されたアプローチを対象とする。複合現実機器を使用すると、ユーザが、ユーザの物理的空間と関連付けられ、その中に設置される、複数のブラウザウィンドウを有し得ることが可能性として考えられる。例えば、ユーザは、第1のブラウザウィンドウを第1の部屋内で開き、第2のブラウザウィンドウを第2の部屋内に居る間に開く場合がある。本開示の本部分によって対処される問題点は、ユーザが第2の場所に行くと、ブラウザウィンドウがもはや可視ではなくなるように、ブラウザウィンドウが第1の場所内の位置にアンカされるような様式で開かれる、状況に関する。問題は、ユーザが環境を変化させる(部屋間で移動する、または異なる地理的場所に行く等)につれて、ユーザが、なおも依然として、以前の地理的場所におけるその前のセッションにアクセスする必要があり得ることである。
【0103】
図10は、1つ以上の以前に開かれたウィンドウの場所に対するユーザに関する現在の場所にかかわらず、ユーザのウィンドウの閲覧を実装するためのアプローチのフローチャートを図示する。いくつかの実装では、制御インターフェースが、ユーザと関連付けられた全ておよび/または複数のウィンドウの表示のために、選択するために提供される。いくつかの実装では、制御インターフェースは、例えば、ユーザ入力をシステムに提供し、システムが対応するコマンドを実行することにより応答することによって、ユーザがMRディスプレイシステムと相互作用し得るように、ユーザインターフェースであってもよい。いくつかの実装では、ユーザは、MRシステムの視覚的、聴覚的、触知的、または他の側面と相互作用してもよい。いくつかの実装では、ユーザインターフェースは、ブラウザハブを備えてもよく、これは、いくつかの実装では、1つ以上のブラウザアプリケーションの1つ以上の側面の視覚的表現であってもよい。例えば、「全てのウィンドウ」アイコンが、ブラウザハブ内に提示されることができ、「全てのウィンドウ」アイコンの選択は、現在のウィンドウ場所(例えば、ウィンドウが開かれた場所)に対するユーザの場所にかかわらず、ユーザと関連付けられた複数のウィンドウの表示を開始する。
図10は、ブロック1702から開始し、システムが、全てまたは複数のウィンドウを表示するためのコマンドを受信する。いくつかの実装では、ブロック1702は、ユーザがブラウザハブユーザインターフェース内にあり得る「全てのウィンドウ」アイコンを選択すると生じてもよい。いくつかの実装では、システムは、1つを上回るウィンドウのための選択を受信する。いくつかの実装では、システムは、ユーザがユーザのシステムと関連付けられた1つを上回るウィンドウを閲覧することを所望することを示す、ユーザ入力を受信してもよい。
【0104】
1704では、ユーザと関連付けられた複数のウィンドウに関する情報が、読み出される。いくつかの実装では、ユーザは、ユーザと関連付けられた1つ以上のウィンドウを有してもよい。情報が集められるウィンドウは、別々の物理的場所に位置してもよい。いくつかの実装によると、VR/AR環境内のブラウザウィンドウを1対1ベースで各アプリケーションによって独立して管理する代わりに、ウィンドウは、代わりに、以降、「プリズム」と称され得る、境界された体積の中にレンダリングされてもよい。各プリズムは、ユニバースアプリケーションが、プリズム自体を管理することによって、VR/AR環境内の仮想コンテンツの設置および表示を管理し得るように、ユニバースアプリケーションがVR/AR環境内でプリズムを管理および表示することを可能にする、特性およびプロパティを有してもよい。プリズムを実装するためのアプローチに関するさらなる詳細は、「METHODS AND SYSTEM FOR MANAGING AND DISPLAYING VIRTUAL CONTENT IN A MIXED REALITY SYSTEM」と題され、2019年6月27日に公開された、米国特許公開第2019/0197785号(参照することによってその全体として本明細書に組み込まれる)に説明される。ウィンドウについての情報は、ユーザと関連付けられたプリズムのデータベースにアクセスすることによって、集められてもよく、プリズムは、1つ以上のウィンドウを規定された場所に表示し得る。複合現実環境内の仮想コンテンツを表示する、管理する、またはナビゲートすることに関する付加的詳細は、「MATCHING CONTENT TO A SPATIAL 3D ENVIRONMENT」と題された、2018年11月1日に公開された、米国特許公開第2018/0315248号(参照することによってその全体として本明細書に組み込まれる)に説明される。
【0105】
いくつかの実装では、「全てのウィンドウ」ビューが、ロードされ、全ての開いているウィンドウおよびタベッドウィンドウを示し、それぞれ、プレビュー、ファビコン、ドメイン名および/またはページタイトル、またはウィンドウの任意の他の好適な視覚的表現によって表される(1706)。いくつかの実装では、開いているウィンドウの実施例は、1人以上のユーザによってアクティブに相互作用されているウィンドウを含む。他の実施例は、開かれ/アクティブなステータス、一時停止ステータス、停止ステータス、閉じられたステータス等を有するかどうかにかかわらず、設置されたアプリケーション/ウィンドウ/ブラウザを含む。加えて、アプリケーションのインスタンスが、存在し/設置され、コンテンツを伴う1つ以上のタブを有する限り、いくつかの実装では、本発明のアプローチを使用して、遠隔でアクセスされることができる。付加的実施例として、開いているウィンドウは、そのステータス(アクティブ、一時停止、閉じられた等)にかかわらず、所与のアプリケーション(例えば、ブラウザ)と関連付けられた一部または全部のプリズムに対応し得、これは、本実装における「全てのウィンドウ」ビューを通して遠隔でアクセスされることができる。いくつかの実装では、「全てのウィンドウ」ビューは、実世界内の1つ以上の物理的場所における1つ以上のプリズム内に含有される、全てのブラウザウィンドウを備えてもよい。「全てのウィンドウ」および類似する「全てのアプリケーション」ビューの実施例は、
図12-14に示され、下記に説明される。「全てのウィンドウ」が、実施例として使用されるが、任意の他の単一アプリケーションも、代わりに使用され得る。「全てのアプリケーション」が、実施例として使用されるが、全てのアプリケーションの任意のサブセットが、代わりに使用されてもよい。
【0106】
ブロック1704において識別された種々のウィンドウは、このように、ユーザの現在の場所において表示されることができる。これは、ユーザの現在の物理的環境内の場所に対して識別されたウィンドウに関する場所パラメータを変化させ、事実上、ウィンドウをユーザに召集することによって遂行されてもよい。いくつかの実装では、これは、ウィンドウ情報のコピーを作成し、代わりに、新しい場所、例えば、ユーザの現在の場所またはその近傍における場所と情報を関連付けることによって遂行されてもよい。ウィンドウは、次いで、個別のウィンドウおよび/またはウィンドウのプリズムに割り当てられる座標において、レンダリングされ(プレビュー形態、サムネイル形態、および/またはフル形態において)、ユーザに表示される。
【0107】
本方法では随意である、1708では、ホバリング状態が、識別され、1つ以上のウィンドウに対して作用されてもよい。例えば、ホバリング状態では、ホバリングされているウィンドウは、前景の中に移動し得、他のウィンドウは、随意に、若干、後退し得る。複数のタブを伴うウィンドウは、背景タブを示すように、若干拡張してもよい。いくつかの実装では、ウィンドウの代わりに、ホバリングされたオブジェクトは、プレビュー、フル画面、または縮小画面等のブラウザウィンドウの任意の視覚的表現であってもよい。1710では、ユーザが、ウィンドウのうちの1つ以上のものを選択する。いくつかの実装では、ユーザは、コントローラ(例えば、トーテム)上のボタンをクリックすることによって、または具体的ジェスチャを実施することによって、または所定の時間周期にわたってウィンドウを見ることによって、ウィンドウを選択してもよい。ユーザが、ウィンドウを選択する場合、オリジナルウィンドウの複製が、ユーザのFOVの前景内にロードされ、全てのウィンドウビューは、閉じる。いくつかの実装では、複製は、ユーザ選択選好に応じて、オリジナルを更新するか、複製は、全てまたはいくつかの付加的コピーを更新するか、および/または複製は、オリジナルから独立するかのいずれかである。いくつかの実装では、前景内にロードされたコンテンツは、移動される(例えば、ピン固定が解除され、全体として移動される)、既存のプリズムに対応する。いくつかの実装では、前景内にロードされたコンテンツは、新しい関連付けられた場所情報とともに複製される、既存のプリズムに対応する。ユーザが、コンテキストメニューをアクティブ化する場合、ユーザは、ウィンドウを閉じる、それをコレクションに追加する、および/またはウィンドウを最小化するためのオプションを備える、ユーザメニューを提示されてもよい。コンテキストメニューは、選択されると、システムに具体的機能を実行するように伝える、所定のユーザインターフェースオプションを伴う、ユーザインターフェースであってもよい。いくつかの実装では、コンテキストメニューは、ウィンドウ等の選択可能オブジェクト上にホバリングしている間、トーテム上のタッチパッドの中心に対する押圧によってアクティブ化されてもよい。いくつかの実装では、コンテキストウィンドウは、アクションが、ユーザが、移動させる、閉じる等、選択されたオブジェクト上でアクションを実施することを可能にするという点で、デスクトップコンピュータ上の右クリックに類似し得る。
【0108】
図11A-Bは、ウィンドウの前の物理的場所にかかわらず、ユーザのためにウィンドウを表示するための本プロセスを図示する。複合現実実装では、ウィンドウは、デバイスおよび/または物理的空間と関連付けられてもよい。ユーザは、その自宅全体を通して、または1日を通して異なる地理的場所に、コンテンツを設置することができる。
図11Aでは、第1のブラウザウィンドウ1は、第1の物理的場所の中に設置されている一方、第2のブラウザウィンドウ2は、第2の物理的場所の中に設置されていることが分かる。ウィンドウは、複合現実実装では、具体的物理的場所/座標空間と関連付けられるため、これは、ウィンドウ1が、通常、ユーザ108が、物理的場所1内に位置するときのみ可視であって、ユーザ108が物理的場所2内に位置するときは、不可視であろうことを意味する。同様に、ウィンドウ2は、通常、ユーザ108が物理的場所2内に位置するときのみ可視であって、ユーザ108が物理的場所1内に位置するとき、不可視であろう。
【0109】
図11Bに示されるように、「全てのウィンドウ」ビュー1805は、ユーザ108が、物理的場所にかかわらず、開いているウィンドウを閲覧し、再び開き、閉じることを可能にする(「開いている」ウィンドウの実施例に関しては、前の段落参照)。したがって、ビュー1805は、これらのウィンドウが異なる物理的場所と関連付けられたという事実にもかかわらず、ウィンドウ1およびウィンドウ2の両方の操作可能なバージョン(例えば、視覚的表現)を表示することができる。ブラウザの制御ハブからアクセスされると、全てのウィンドウを閲覧する(または代替として、「全てのウィンドウ」)は、ユーザが、その物理的または地理的位置にかかわらず、全ての開いているウィンドウを見ることを可能にする。ウィンドウは、同一部屋、異なる部屋、または完全に別の空間内にあってもよい。スクリーンショット、ファビコン、ドメイン、および/またはページタイトルが、各ウィンドウを識別する(例えば、視覚的に表す)ために使用される。いくつかの実装では、複数のタブを伴うウィンドウは、ホバリング状態では、下層タブのスタックされたプレビューを示す。コンテキストメニューを用いることで、ユーザは、場所にかかわらず、ウィンドウの新しいインスタンスを開き、ウィンドウを閉じ、ウィンドウを最小化し、ウィンドウをブックマークし、ウィンドウをコレクションに追加することができる。全ての開いているウィンドウを閉じる、または最小化するために使用され得る、グローバルボタンもまた、提供されてもよい。
【0110】
図12-13は、複数のウィンドウを複合現実インターフェース内に表示するための可能性として考えられるアプローチの例証を提供する。これらの図は、複数のウィンドウがユーザに表示および提示される、インターフェースを実装するための例示的アプローチを図示する。ブラウザウィンドウのいずれかが、ユーザによってさらに閲覧するために、ポインティングデバイス等の好適なユーザ入力デバイスによって選択されることができる。インターフェース上に適合し得るウィンドウが多すぎる限りにおいて、いくつかの実装では、付加的ウィンドウが、視覚的に「残影化」されることができ(
図12および
図13の右側に示されるように)、スクロール制御が、付加的ウィンドウにスクロールするために提供される。
【0111】
したがって、説明されている内容は、複合現実環境内でウィンドウを閲覧するための改良されたアプローチであって、1つ以上の以前に開かれたウィンドウに対するユーザに関する現在の場所にかかわらず、ユーザのウィンドウのビューが提供される。これは、複合現実機器を使用するとき、ユーザが、1つ以上の異なる物理的場所と関連付けられた1つ以上のブラウザウィンドウにアクセスすることを所望し得る状況に対処し、それを解決する。
【0112】
上記の実装は、ブラウザアプリケーションの観点から説明されているが、請求項の範囲はまた、任意の他のアプリケーションまたはアプリケーションのセットを網羅する。いくつかの実装では、オペレーティングシステム内の全てのアプリケーションが、請求項に従って、選択および表示されることができる。そのような実装は、ウィンドウ内で解析されるブラウザコンテンツの代わりに、アプリケーションをプリズム内に有するであろう。
【0113】
そのような実装は、
図14に描写され、これは、複数のアプリケーションを複数のプリズム内に表示する。「全て」ボタンは、例示的ドロップダウンフィルタであって、表示および選択のために(例えば、カテゴリ別に)、アプリケーションオプションを通してソートすることに役立つ。9m~30mに及ぶ例示的スライダバーは、ユーザからの距離に基づいて、全てのアプリケーション/ランドスケープマネージャディスプレイ内に含まれるアプリケーションを選択するが、他の好適な選択またはフィルタリング方法および/またはインターフェースが、使用されてもよい。いくつかの実装では、ユーザは、スライダバーを部屋に対応するより小さい距離に設定し、その部屋内で利用可能な全てのアプリケーションを表示することができる。いくつかの実装では、ユーザは、スライダバーを家に対応するより大きい距離に設定し、家全体内で利用可能な全てのアプリケーションを表示することができる。いくつかの実装では、スライダバーは、場所にかかわらず、全てのアプリに対応する右端とともに設定されることができる。「全て閉じる」ボタンは、アプリケーションを制御および/または操作するための例示的ユーザインターフェース要素である。他のユーザインターフェース要素は、上記に説明されるように、「全て開く」、「移動」等であってもよい。
図14は、開かれたアプリケーション間の「HELIO」アプリケーションおよび「COLLECTION」アプリケーションの2つの異なるインスタンスを描写する。故に、「全て」ボタンは、アプリケーションおよび異なるアプリケーションの複数のインスタンスを表示することができる。本明細書に説明される種々の複合現実ウェブブラウジング技法およびアプリケーションは、時として、Helio技法またはアプリケーションとも称され、複合現実ウェブブラウザは、時として、Helioブラウザと称され得る。
システムアーキテクチャ概要
【0114】
図15は、本開示の実装を実装するために好適な例証的コンピューティングシステム1400のブロック図である。コンピューティングシステム1400は、情報を通信するためのバス1406または他の通信機構を含み、これは、プロセッサ1407、システムメモリ1408(例えば、RAM)、静的記憶デバイス1409(例えば、ROM)、ディスクドライブ1410(例えば、磁気または光学)、通信インターフェース1414(例えば、モデムまたはEthernet(登録商標)カード)、ディスプレイ1411(例えば、仮想コンテンツをユーザの眼に投影する、頭部搭載型システム160のディスプレイ)、入力デバイス1412(例えば、キーボードおよびマウス、ハンドヘルドトーテム等)等のサブシステムおよびデバイスを相互接続する。頭部搭載型システム160と関連付けられる、プロセッサ170は、プロセッサ1407を備えることができる。プロセッサ170またはプロセッサ1407は、本明細書に説明される機能性を実装することができる。
【0115】
一実装によると、コンピューティングシステム1400は、システムメモリ1408内に含有される1つ以上の命令の1つ以上のシーケンスを実行する、プロセッサ1407によって、具体的動作を実施する。そのような命令は、静的記憶デバイス1409またはディスクドライブ1410等の別のコンピュータ可読/使用可能媒体から、システムメモリ1408の中に読み取られてもよい。代替実装では、有線回路が、本開示に説明される機能性を実装するために、ソフトウェア命令の代わりに、またはそれと組み合わせて、使用されてもよい。したがって、本開示の実装は、ハードウェア回路および/またはソフトウェアの任意の具体的組み合わせに限定されない。一実装では、用語「論理」は、本開示の全部または一部を実装するために使用される、ソフトウェアまたはハードウェアの任意の組み合わせを意味するものとする。
【0116】
用語「コンピュータ可読媒体」または「コンピュータ使用可能媒体」は、本明細書で使用されるように、実行のために、命令をプロセッサ1407に提供する際に関与する、任意の媒体を指す。そのような媒体は、限定ではないが、不揮発性媒体および揮発性媒体を含む、多くの形態をとってもよい。不揮発性媒体は、例えば、ディスクドライブ1410等の光学または磁気ディスクを含む。揮発性媒体は、システムメモリ1408等の動的メモリを含む。
【0117】
一般的形態のコンピュータ可読媒体は、例えば、フロッピー(登録商標)ディスク、フレキシブルディスク、ハードディスク、磁気テープ、任意の他の磁気媒体、CD-ROM、任意の他の光学媒体、RAM、PROM、EPROM、FLASH-EPROM、任意の他のメモリチップまたはカートリッジ、またはそこからコンピュータが読み取り得る、任意の他の媒体を含む。
【0118】
本開示のある実装では、本開示を実践するための命令のシーケンスの実行は、単一コンピューティングシステム1400によって実施される。本開示の他の実装によると、通信リンク1415(例えば、LAN、PTSN、または無線ネットワーク)によって結合される、2つ以上のコンピューティングシステム1400が、相互に協調して、本開示を実践するための命令のシーケンスを実施してもよい。
【0119】
コンピューティングシステム1400は、通信リンク1415および通信インターフェース1414を通して、プログラム(例えば、アプリケーションコード)を含む、メッセージ、データ、および命令を伝送および受信してもよい。受信されたプログラムコードは、受信されるにつれて、プロセッサ1407によって実行され、および/または後の実行のためにディスクドライブ1410または他の不揮発性記憶装置内に記憶されてもよい。コンピューティングシステム1400は、データインターフェース1433を通して、外部記憶デバイス1431上のデータベース1432に通信してもよい。
複合現実におけるセキュアな認可
【0120】
複合現実ディスプレイシステム(例えば、
図1を参照して説明される頭部搭載型システム160)のユーザは、複合現実システムによって実行されている、1つ以上のアプリケーションと相互作用し得る。没入型アプリケーションは、その中で複合現実システムによって表示される実質的に全ての仮想コンテンツが、ユーザがアプリケーション内に没入されているかのように感じるように没入型アプリケーションによって生成される、単一アプリケーションを指し得る。没入型アプリケーションの実施例は、その中でユーザが相互作用するゲーム環境を体験する、ゲームである。ランドスケープアプリケーションは、ユーザがランドスケープアプリケーションのいくつかまたは全てと関連付けられる仮想コンテンツを視認し得るように、他の(例えば、1つ以上の)アプリケーションを用いて実行され得る、アプリケーションを指し得る。例えば、
図14を参照すると、ユーザは、ウェブブラウザ(例えば、Helio)、アプリケーション集合(例えば、
図14に示されるように、Whales)、視聴覚メディアプレーヤアプリケーション、ソーシャルメディアアプリケーション等の1つ以上のインスタンスと相互作用し得る。ランドスケープアプリケーションのそれぞれと関連付けられる、仮想コンテンツは、ユーザから異なる距離に現れるかのように提示され得る。ユーザは、したがって、開いている、可視である、かつ同時に相互作用可能である、複数のランドスケープアプリケーションを有し得る。
【0121】
ユーザが、没入型またはランドスケープ複合現実アプリケーションのいずれかと相互作用しているとき、アプリケーションは、機能性がアクセスされ得る前に、ユーザ認可を要求する、機能性を提供し得る。例えば、没入型ゲーム環境では、ゲームアプリケーションは、ユーザが仮想キャラクタに対するアップグレード(例えば、新しい衣類、新しいゲーム上のパワー等)を購入することを可能にする、機能性を提供し得る。同様に、電子商取引アプリケーションは、ユーザが、商品を購入することを可能にし得る。別の実施例として、ソーシャルメディアアプリケーションは、ユーザが、ソーシャルメディア連絡先(例えば、友達)を検索および発見することを可能にし得る。これらの状況のそれぞれでは、アプリケーションは、ユーザが、機能性にアクセスすることに先立って、別のサービスへのアクセスを認可する、またはその証明書を認証することを要求し得る。例えば、購入を行うことに先立って、ゲームまたは電子商取引アプリケーションは、詐欺を阻止するために、ユーザの認証および支払方法の選択(例えば、有効クレジットカードまたは支払アカウント)を要求し得る。別の実施例として、検索することを可能にすることに先立って、ソーシャルメディアアプリケーションは、ユーザが、ユーザのソーシャルネットワークを検索し、機密性を保つために、ユーザのソーシャルメディアアカウントにセキュアにログインすることを要求し得る。
【0122】
ユーザを認可または認証する(用語「~を認可する」または「~を認証する」は、本明細書では、文脈によって別様に明確に示されない限り、同義的に使用される)ための機能性を提供することによって、複合現実ユーザが、複合現実アプリケーション(例えば、ランドスケープまたは没入型)とセキュアに相互作用することを可能にする、システムおよび方法の実装が、説明されるであろう。時として、本明細書では「OAuth」とも称される、認可プロトコルは、アプリケーションまたはサービスが、アプリケーションのアセットへのアクセスを認可することを可能にする、オープン標準であり得、ユーザのログイン情報のいずれも共有し得ず、これは、認可プロセスのセキュリティを向上させる。
【0123】
ある場合には、アプリケーションは、複合現実システムの開発者によってではなく、第三者開発者によって開発される。アプリケーションプログラミングインターフェース(API)の実装が、アプリケーションの開発者が、例えば、直接、第三者アプリケーションから、認可機能性にアクセスすることを有効にするために提供されてもよい。そのようなAPIは、有利なこととして、セキュアな認可を開発者(APIを呼び出し、適切なウィンドウを開く、または適切な仮想コンテンツを表示し得る)に容易に利用可能にし得、また、そのような認可プロシージャを全てのアプリケーション間で比較的に類似させ得、これは、ユーザが認可プロシージャを行うことをより容易にする。例えば、APIは、認可機能性(例えば、サイトにセキュアにログインする、または支払証明書を認証する能力)を提供する、OAuthブラウザウィンドウを呼び出すために使用されてもよい。OAuthブラウザウィンドウは、限定された機能性のセット(例えば、セキュアな認可)のみを許可し、認可プロセスが進められている間、複合現実システムによって実行されている他のアプリケーションとの相互作用を無効にしてもよい。いったん認可が、完了されると、ユーザは、アプリケーションに戻るようにダイレクトされることができる。故に、OAuthサービスの実装は、アプリケーションフローの中への認可のシームレスな統合を可能にする。OAuthブラウザウィンドウの実装の挙動の実施例は、下記に説明されるであろう。そのような実施例は、例証であって、限定することを意図するものではない。他の実装では、ウェブブラウザウィンドウ、ユーザインターフェース、ボタン、およびデータエントリボックスは、示されるものと異なるように構成されることができる。
【0124】
図16A-16Fは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。これらの図では、アプリケーションは、没入型ゲームコンテンツ1604をユーザに表示する、没入型ゲーム等の没入型アプリケーションである。ゲームアプリケーションは、ユーザがゲームを一緒にプレーし得るように、ユーザが、現在オンラインであって、ゲームをプレーしている、友達を検索することを可能にする、機能性を提供してもよい。ゲームの間、アプリケーションは、ユーザの電子メール、連絡先、または検索エンジンによって提供される他のサービスにアクセスするために、別のサービス、例えば、検索エンジン(検索エンジンと称される)へのアクセスを要求してもよい。アプリケーションは、OAuthサービスをアプリ内の任意の場所から要求し得る。ゲームアプリケーションは、OAuthサービスを要求し得(例えば、API呼び出しを介して)、ウィンドウ1610が、ゲームが検索エンジンサービスにアクセスすることの同意を提供するために、ユーザに表示されてもよい。ウィンドウ1610は、不透明であってもよい(例えば、その背後のコンテンツを実質的にブロックする)、またはある量の透明度を有してもよい。例えば、
図16Aに示されるウィンドウ1610は、ウィンドウ1610の背後の仮想コンテンツが部分的に可視であるように、部分的に透明である(破線を使用して示される)。ユーザは、検索エンジンに接続するために、ボタン1614を選択する、または検索エンジンに接続するアプリケーションの試みをキャンセルするためのボタン1618を選択することができる。本明細書に説明されるように、ボタンを選択するために、ユーザは、コントローラ(例えば、トーテム)上のボタンをクリックする、具体的ジェスチャを実施する、または閾値時間周期にわたってボタンを見ることができる。
【0125】
ユーザが、接続を承認する場合、OAuthプロトコルは、次いで、仮想コンテンツの表示を没入型ゲームコンテンツ1604からOAuthウィンドウ(
図16Cを参照して下記に説明される)に遷移させ得る。例えば、消失、フェーディング、消去、カット等の任意の種類の視覚的効果遷移が、使用されてもよい。遷移の際のある瞬間の実施例が、
図16Bに示されており、収縮する円形の内側の仮想ゲームコンテンツ1604が、表示される一方、収縮する円形1612の外側の仮想コンテンツ1606は、モノクロ背景であってもよい。収縮する円形の半径が、十分に小さくなった後、ゲームコンテンツ1604は、もはや知覚不能となり、円形は、次いで、サイズが増加し、OAuth仮想コンテンツを表示し得る(
図16C参照)。
【0126】
図16Cは、没入型OAuth認可ウィンドウ1620の実施例を示す。ウィンドウ1620は、ユーザが、ダイレクトされているウェブサーバが、信頼されたサービスであって、フィッシングまたはスパムサービスではないことをチェックし得るように、ユーザ認可を要求する、アプリケーションの名称1624(この場合、没入型「ゲーム」アプリケーション)と、サービスのウェブアドレス1628(この場合、検索エンジン)とを表示する。ウェブアドレス1628は、統一資源ロケータ(URL)であることができる。本実施例では、1行のURL「https://account.serchengine.com/account…」のみが、示される。ある場合には、URLは、1行を上回る長さであってもよく、ユーザは、リンクのための完全URLを表示するためのウェブアドレス1628を示す、ウィンドウ1620の領域を選択してもよい。URLを表示することが、閾値数の行(例えば、6、8、10、以上の行)を上回る行、またはウィンドウサイズの閾値割合(例えば、ウィンドウの1/4、1/3、1/2、2/3、以上の)を上回る割合を要求する場合、URLは、ユーザがコンテンツをスクロールし、URLの全てを閲覧することを可能にする、スクロールバーとともに示されてもよい。いくつかの実装では、ユーザは、コントローラ上のボタン(例えば、トーテム上のホームボタン)をタップすることによって、またはURLを表示する領域の外側のウィンドウ1620の任意のエリアを選択することによって、完全URLを隠蔽することができる。
【0127】
ユーザは、サービスと関連付けられる、認可ウィンドウ1632を使用することによって、OAuthフローを通して認可を継続する。本実施例では、ウィンドウ1632は、SearchEngine.comサインインウィンドウであって、その中にユーザは、そのアカウント名を打ち込み、アクセスを認可することができる(例えば、認可ボタン1636を選択することによって)。
図16Cに示されるサインインウィンドウは、オンラインサービスによって提供される認証または認可ウィンドウのタイプの例証であるように意図され、限定することを意図するものではない。他の実施例では、ウィンドウ1632は、アカウントを作成する、パスワードを打ち込む(例えば、ユーザが、すでにサービスにサインインしている場合)、支払情報を提供する等のためのウィンドウであってもよい。OAuthプロトコルは、第三者サービスによって提供される、任意の認証または認可フローを承認することができる。ユーザが、認可プロトコルを継続しないことを選定する場合、ユーザは、ボタン1638を選択し、認可プロセスをキャンセルし、アプリケーション(この場合、没入型ゲーム)に戻ることができる。
【0128】
ユーザが、認可を継続することを選定する場合、ウィンドウ1632は、
図16Dにおけるウィンドウ1640に遷移する。第三者サービスは、背景におけるディスパッチシーケンス(
図18-20Bを参照して下記に説明される)を介して、1つ以上のアクセストークンを提供してもよい。本シーケンスの間、フロントエンドは、ウィンドウ1640を表示してもよく、これは、リンクされているサービスを表す、アイコン1642(例えば、SearchEngine.comに関する「S」アイコン)、または認可が進行中であることを示す、テキスト1643を示してもよい。ユーザが、認可をキャンセルすることを所望する場合、ボタン1644を選択し、非認可のまま呼び出し中のアプリケーション(例えば、ゲーム)に戻ることができる。ある場合には、認可を確立することに係る問題点または問題(例えば、正しくないユーザ名またはパスワードが打ち込まれた)が存在し得、ディスプレイは、問題点が生じたことのテキストインジケーション1652を提供し得る、ウィンドウ1648に遷移し得る。ユーザは、ボタン1656を選択し、認可プロセスをキャンセルし、呼び出し中のアプリケーション(例えば、ゲーム)に戻る、またはボタン1661を選択し、認可プロセスを再試行することができる(その場合、ディスプレイは、
図16Cに示されるウィンドウ1620に戻るように遷移し得る)。
【0129】
認可成功に応じて、呼び出し中のアプリケーション(本実施例では、ゲーム)は、前景化されてもよい。認可プロセスの間に背景化されていたとされる、他のアプリケーションもまた、前景化されてもよい。アプリケーションを前景化するステップは、アプリケーションをより高い優先順位で実行すること(背景において実行されるときと比較して)、アプリケーション特有仮想コンテンツをユーザに表示すること、アプリケーション特有仮想コンテンツの不透明度または輝度を増加させること、アプリケーション特有仮想コンテンツの透明度を減少させること、表示されるアプリケーション特有仮想コンテンツの表示深度またはサイズを変化させること(例えば、コンテンツをユーザのより近くにまたは増加されたサイズで表示する)、またはアプリケーションがユーザ入力を受信することを可能にすることを含むことができる。例えば、
図16Fに示されるように、ディスプレイは、サイズを増加させ、ユーザがゲームの中に戻るように没入させる、拡張する円形1660を介して、ゲーム仮想コンテンツ1604に戻るように遷移し得る。
【0130】
図17A-17Dは、認可ウィンドウを複合現実環境内に表示するための種々のアプローチを図示する。これらの図では、アプリケーションは、ソーシャルメディアコンテンツ1705をユーザに表示する、ソーシャルメディアアプリケーション等のランドスケープアプリケーションである。本実施例では、ユーザ(「MiaLeap」)は、オンラインであって、領域1706に示される友達「Alice」および「Bob」にリンクされる。アプリケーションは、アプリ内の任意の場所から、OAuthサービス等の認証サービス(例えば、他のアプリケーションにもまたアクセス可能なSSOサービス)を要求し得る。例えば、ユーザが、オンラインであり得る、付加的友達を検索することを所望する場合、ユーザは、ボタン1708を選択してもよい。ディスプレイは、
図17Bに示される、ウィンドウ1710に遷移し、これは、ユーザが友達を検索することを可能にする(例えば、ニックネームまたは電話番号を介して)機能性を含む。ウィンドウ1710はまた、第三者サービスにリンクし、ユーザが知り合いであり得る、友達を発見する機能性を含む。例えば、ユーザは、ボタン1712を選択し、ユーザの電子メールおよび連絡先情報を含む、検索エンジンアカウント(例えば、本実施例では、SearchEngine.comとも称される)にリンクすることができる。
【0131】
ユーザが、ボタン1712を選択する場合(例えば、そのアカウントにリンクするために)、ディスプレイは、
図17Cに示されるOAuth認可ウィンドウ1620に遷移する。呼び出し中のプログラムは、ランドスケープアプリケーション(ソーシャルメディアアプリケーション)であるため、本システムは、呼び出し中のアプリケーションを背景化し、没入型モードにおいて(ユーザが、OAuthウィンドウのみと相互作用し得るように)、OAuth認可ウィンドウをロードすることができる。他のランドスケープアプリケーション(任意のものが起動中の場合)は、認可プロセスの間、一時的に隠蔽され得る。アプリケーションを背景化するステップは、アプリケーションをより低い優先順位で実行すること(前景において実行されるときと比較して)、アプリケーション特有仮想コンテンツをユーザから隠蔽すること、アプリケーション特有仮想コンテンツの不透明度または輝度を低減させること、アプリケーション特有仮想コンテンツの透明度を増加させること、表示されるアプリケーション特有仮想コンテンツの表示深度またはサイズを変化させること(例えば、コンテンツをユーザからより遠くにまたは減少されたサイズで表示する)、またはアプリケーションがユーザ入力を受信することを防止することを含むことができる。本明細書にさらに説明されるように、認可プロセスが、成功した(またはユーザによってキャンセルされた後)、アプリケーションは、次いで、前景において実行されることができる。
【0132】
図17Cに示されるOAuthウィンドウ1620は、概して、
図16Cに示され、それを参照して説明される、OAuthウィンドウに類似し得る。例えば、ユーザ認可を要求する、アプリケーションの名称が、領域1625に示され得る。本実施例では、ソーシャルメディアプログラム「ソーシャル」は、SearchEngine.comへのアクセスを要求し、そのURLは、ウェブアドレス1628の領域に示される。サインインウィンドウ1632は、ユーザが、アクセスを認可することを可能にし、ユーザは、ボタン1638を選択することによって、認可をキャンセルすることができる。ユーザは、概して、没入型ゲームアプリケーションに関して上記に説明されるように、認可プロセスを継続し得る。
【0133】
OAuthプロトコルが、完了し、ユーザが、第三者サービスを正常に認可した後、ユーザは、呼び出し中のアプリケーション内の中断した場所に戻され、状態が、認可情報に基づいて取り込まれる。他のアプリケーション(任意のものが起動中の場合)も、前景またはアプリケーションの前の状態に戻され得る。本実施例では、ディスプレイは、友達発見ウィンドウ1730に遷移し、ここで、領域1734内に、SearchEngine.comによってユーザの連絡先から発見された連絡先「Caryn」および「Dana」が取り込まれる。本実施例では、ユーザは、個別の「+」ボタンを選択することによって、これらの連絡先をフォローするように選び得る。
【0134】
図16A-17Dを参照して説明される実施例は、OAuth認可プロトコルが没入型またはランドスケープアプリケーションによって呼び出され得る、方法を図示する。OAuthウィンドウ(例えば、
図16Cおよび17Cに示されるウィンドウ1620)は、セキュアな機密認可を確実にすることに有益に役立ち得る、いくつかの性質を有し得る。OAuthウィンドウの性質は、概して、同一であり得(どのアプリケーションがウィンドウを呼び出すかどうかにかかわらず)、これは、複合現実プラットフォーム上の全てのアプリケーションを横断して均一である、認可プロセスを提供し、ユーザにとって容易に学習されるプロセスを提供することに役立ち得る。OAuthウィンドウ性質の非排他的かつ非限定的実施例が、ここで説明されるであろう。これらの性質は、単独で、ともに、または任意の好適な組み合わせにおいて、使用されることができる。
【0135】
OAuthウィンドウは、限定された特徴セットを伴う、比較的に基本的ブラウザウィンドウであってもよい(例えば、ハッキングを防止するため、セキュリティおよび機密性を向上させるため、およびユーザが他のユーザインターフェース特徴によって注意を逸らされないように回避するため)。例えば、ウィンドウは、認可を要求する、アプリケーションの名称1624を示してもよい(例えば、
図16Cにおけるゲームアプリケーションおよび
図17Cにおけるソーシャルアプリケーション)。リンクされているサービスのウェブアドレス1628も、示されることができる。キャンセルボタン1638は、ユーザが任意の認可プロセスを容易にキャンセルし得るように、認可ウィンドウ1632の下方に表示されてもよい。OAuthウィンドウは、ユーザが、認可コンテンツに集中し、ディスプレイを通して視認可能な他の実または仮想コンテンツによって注意を逸らされ得ないように、実質的に不透明であってもよい。例えば、OAuthウィンドウの不透明度は、50%、60%、75%、80%、90%を上回る、または最大100%であってもよい。
【0136】
複合現実システムは、概して、ユーザが、コンテキストメニューを呼び出すことを可能にしてもよい。いったんOAuthウィンドウが、表示されると、本システムは、コンテキストメニューから利用可能な特徴を限定し得る。例えば、コンテキストメニューコマンドは、ズーム制御(ユーザが、ウィンドウコンテンツが快適に読み取られ得るまで、ズームインまたはズームアウトすることを有効にすることができる)を除き、隠蔽されてもよい。OAuthウィンドウからのオブジェクトまたはリンクの抽出は、禁止され得る。ユーザが、オブジェクトまたはリンクを抽出するように試みる場合、コマンドは、無視されることができる。いくつかの実装では、3次元(3D)コンテンツは、OAuthウィンドウ内に表示されない。
【0137】
OAuthウィンドウは、ユーザに表示される全ての仮想コンテンツがOAuthサービスから生じるように、(ランドスケープモードではなく)没入型モードにおいて実行するようにされてもよい。故に、OAuthウィンドウは、呼び出し中のアプリケーションのウィンドウまたは仮想コンテンツに従属するが、認可プロセスが進められている間、呼び出し中のアプリケーションの機能性を無効にする、モード式ウィンドウと称され得る。モード式、すなわち、没入型OAuthウィンドウは、他のアプリケーションがOAuthウィンドウ上のコンテンツにオーバーレイすることを防止することができ、これは、他のアプリケーションが、ユーザ入力またはコンテンツを盗取しないように、または読み取ることを防止する。OAuthウィンドウを没入型またはモード式にすることはまた、ユーザが、ユーザから複数の深度に表示されるウィンドウを有し得る、他のランドスケープアプリケーションから注意散漫になることを防止する。いくつかの実装では、ランドスケープまたは没入型アプリケーションは、OAuthサービスがアクティブである間、中断(例えば、一時停止)されてもよく、ランドスケープまたは没入型アプリケーションは、OAuthサービスが終了する(例えば、ゲームアプリケーションに戻る)と、再開(例えば、アプリケーションが以前に中断した場所から継続)してもよい。いくつかの実装では、ランドスケープまたは没入型アプリケーションは、アプリケーションが、OAuthサービスが終了するとき、OAuthサービスが開始するときと比較して、異なる状態になり得るように、本システムがランドスケープまたは没入型アプリケーションのためのユーザ相互作用を承認しないにもかかわらず、背景において起動され続けてもよい(例えば、現在の時間を示す、時計アプリケーション)。OAuthプロセスを没入型、すなわち、モード式モードで実行することによって、ユーザは、単一タスクに従事し、すなわち、OAuthウィンドウを介して、認可プロセスを完了する。有利なこととして、ユーザは、モード式OAuthウィンドウが、ユーザからの入力を受け取る、唯一のウィンドウであるため、偶発的に、入力を誤ったウィンドウの中に打ち込むことができない。
【0138】
複合現実コンテキストでは、いくつかの実装では、没入型(モード式)OAuthウィンドウは、随時または要求側アプリケーション内の任意の場所から実行されることができる。OAuthウィンドウは、要求側アプリケーション(親アプリケーション)の子として実行されることができ、子は、具体的OAuthプロセスが完了される(例えば、第三者サービスに正常にサインインする、支払証明書を提供する、認可プロセスをキャンセルする等)まで、親または任意の他のアプリケーションへのアクセスを無効にすることができる。具体的OAuthプロセスの完了後のみ、親または他のアプリケーションに戻されることができる。APIは、親アプリケーションがOAuthウィンドウを要求するとき、OAuthウィンドウの機能性、特徴セット、および特殊許可が、自動的に提供され、親または他のアプリケーションへのアクセスが、自動的に無効にされるように、子に特殊許可を与えるように構成されることができる。
【0139】
そのようなモード式機能性は、特に、異なるアプリケーションが、仮想コンテンツをユーザから異なる深度に提示し得、異なる可視性を有し得る、3D複合現実環境において有益であり得る。そのような環境では、有害因子(例えば、マルウェア)が、ユーザ入力(例えば、パスワードまたは他の機密情報)を受け取り、それによって、ユーザの入力を傍受する(ユーザが知らないうちに)ように構成される、不可視仮想コンテンツをウィンドウの正面に提示し得る。しかしながら、OAuthウィンドウをモード式にし、全ての他のアプリケーションへのアクセスを無効にすることによって、ユーザは、機密情報を認可プロセスに安全に入力し、セキュアにログインする、機密情報を転送すること等ができる。加えて、全てのアプリケーションへのアクセスがブロックされる、3D複合現実環境内におけるそのようなモード式ウィンドウは、2Dモバイルまたはデスクトップ環境内に実装されるいくつかのモード式ウィンドウと異なる。2D環境では、モード式ウィンドウは、親アプリケーションへのアクセスを無効にし得るが、ユーザは、アプリケーションを切り替え、ユーザデータを入力し続け得る(マルウェアによって傍受され得る)。
【0140】
複合現実ディスプレイシステムは、ウィンドウが、常時、ユーザの正面にあるように、OAuthウィンドウを提示してもよい。これは、ユーザが(例えば、システムまたはユーザの視野内の)ウィンドウを見失うことをより困難にし、ウィンドウが、物理的または仮想オブジェクトの背後に喪失または部分的にオクルードされないであろうため、有利であり得る。いくつかの実装では、OAuthウィンドウは、ウィンドウがユーザの頭部移動に応答して移動するように、ウィンドウがユーザの頭部位置に結び付けられる、大まかな頭部係止設定を使用して表示されてもよい。例えば、ユーザが、左または右を見る場合、ウィンドウは、左または右に移動し、それぞれ、ウィンドウをユーザの正面に保つ。同様に、ユーザが、上または下を見る場合、ウィンドウは、それぞれ、上または下に移動し、ウィンドウをユーザの正面に保つ。故に、OAuthウィンドウは、ユーザの頭部移動に応答して移動し、ユーザの視野を再芯合させる。再芯合は、ウィンドウの移動がそれがユーザに幾分緩く取り付けられているかのように感じさせるように、短時間の遅れと関連付けられ得る。OAuthウィンドウのための大まかな頭部係止設定の利点は、本システムがウィンドウをユーザの視野内に表示すべき場所を決定する必要はないことである。すなわち、本システムは、単に、ウィンドウをユーザの視野の中心に表示する。OAuthサービスと併用可能な種々のウィンドウ移動の実施例は、米国特許公開第2019/0197785号(参照することによってその全体として本明細書に組み込まれる)に説明される。
【0141】
複合現実ディスプレイシステムは、ウィンドウ内のテキストまたはグラフィックコンテンツの視認性を改良または最適化する、またはデータをOAuthウィンドウ内に打ち込むユーザの能力を改良または最適化する、ユーザからある距離に、OAuthウィンドウを提示してもよい。例えば、いくつかの実装では、OAuthウィンドウは、ユーザから700mmに複合現実システムによって表示され、600mm×500mmのウィンドウサイズを有する。他の実装では、これらのサイズまたは距離は、異なってもよく、いくつかの実装では、サイズまたは距離は、ユーザ調節可能であってもよい。上記に議論されるように、いくつかの実装では、ウィンドウのコンテキスト機能性は、ウィンドウの好適なサイズを選択する能力との併用を提供する、ズーム制御を除き、無効にされる。
【0142】
OAuthサービスは、複合現実ディスプレイシステム上で起動する任意のアプリケーションから呼び出されることができる(例えば、適切なAPI呼び出しを介して)。さらに、OAuthサービスは、
図16A-17Dを参照して説明される、ゲームおよびソーシャルメディア実施例に限定されず、他のアプリケーションまたはユースケースと併用されてもよい。例えば、アプリケーション開発者は、セキュア認証をその複合現実アプリケーション(ランドスケープまたは没入型)に追加し、それが所望する、任意のバックエンド認証サーバを使用することを所望し得る。開発者はまた、アクセス制御(例えば、シングルサインオン(SSO))または他の分析のためにクッキーが設定されることを有効にすることを所望し得る。アプリケーション開発者は、OAuth APIの呼び出しを用いて、本機能性を有効にすることができる。開発者がOAuth API呼び出しを複合現実アプリケーション内の任意の場所から行う能力の利点は、認証が複合現実アプリケーションのフロー内に統合された状態となるため、ユーザが複合現実アプリケーションに従事している状態を保つことである。
【0143】
別の実施例として、没入型電子商取引アプリケーションのためのアプリケーション開発者は、モード式ブラウザウィンドウを電子商取引ウェブサイトから示すことによって、アイテムの販売を成立させる、または直接没入型アプリケーションから、またはブラウザ検索からの、電子商取引ウェブサイトへの訪問間のクッキーを介して、印象を追跡することが可能となることを所望し得る。開発者はまた、没入型アプリケーションから設定されたクッキーを通して、アイテムを購買する、またはそれに関する広告を示す、またはユーザがアイテムを購入後に没入型アプリケーションに戻るようにダイレクトされる(例えば、ランドスケープアプリケーションに戻るようにダイレクトされるのではなく)ことを確実にすることを所望し得る。そのようなシナリオでは、開発者は、OAuth APIを利用して、没入型複合現実アプリケーションの内側から呼び出し可能な好適なモード式ウィンドウを提供することができる。
【0144】
別のアプリケーションでは、開発者は、ある種類のフォーマット化されたテキストをモード式ウィンドウ内に示すことを所望し得る。例えば、開発者は、ユーザに、ランドスケープまたは没入型複合現実アプリケーションのためのエンドユーザ使用許諾契約(EULA)を表示することを所望し得る。開発者は、ハイパーテキストマークアップ言語(html)を使用して、EULAをフォーマット化し、それをブラウザウィンドウとして提示し、EULAに翻訳のために異なるロケールを配慮させることを所望し得る。開発者は、EULAをサーバから遠隔で更新することが可能であることを所望し得る。そのようなシナリオでは、開発者は、ユーザが、複合現実アプリケーションに戻される前に、EULAのページに目を通し、同意を示さなければならないように、EULAをモード式ウィンドウ内に提示させることができる。EULAのユーザの承認または否認は、呼び出し中のアプリケーションに通信されることができる。
【0145】
図18は、没入型(例えば、モード式)OAuth認可サービス1804の実施例を示す、ブロック
図1800である。OAuthサービス1804は、
図16A-17Dを参照して説明される機能性を実装することができ、例えば、
図1を参照して説明される頭部搭載型ディスプレイシステム160のプロセッサ170または
図15を参照して説明されるコンピューティングシステム1400によって実施されることができる。OAuthサービス1804は、ユーザの情報を認可または検証し、アクセストークンを提供し、ユーザを認可する、ウェブベースのサービスであることができる。
【0146】
アプリケーション1806(アプリ)は、アプリケーション内の任意の場所からOAuthサービス1804を要求することができる(例えば、API呼び出しによって)。アプリケーション1806は、ランドスケープアプリケーションまたは没入型アプリケーションであることができる。OAuthサービス1804を開始することは、ディスプレイシステムを没入型ウェブブラウザインスタンス(例えば、Helioインスタンス)に遷移させ、認可プロセスを開始する。上記に説明されるように、没入型(例えば、モード式)ウェブブラウザインスタンスは、ディスプレイシステム上の全てのアプリケーションが、OAuthサービス1804を利用し、これが、ユーザが認可プロセスがセキュアであることを信用することにつながり得るため、ユーザの認可体験における一貫性を提供し得る。上記に説明されるように、没入型モードは、起動中であり得る、他のアプリケーションを無効にし、これは、認可プロセスの間、悪意のあるアプリケーション(マルウェア)がユーザ入力を傍受することを防止することができる。したがって、没入型モードは、中間者攻撃を防止することができる。
【0147】
ブロック1808では、OAuthサービスがロード中の間、本システムは、要求側アプリケーション1806(および起動中であり得る、他のアプリケーション)を背景化し、ユーザが認可プロセスに同意することを要求する、1つ以上のウィンドウ(例えば、
図16Aを参照して説明されるウィンドウ1610)を表示してもよい。ブロック1812では、本システムは、次いで、ディスプレイをOAuth認可プロセスのためのウィンドウに遷移させてもよい。OAuth認可ウィンドウの実施例は、
図16Cおよび17Cにおけるウィンドウ1620に示され、それを参照して説明される。認可は、要求される第三者サービスのためのサインインページ、支払情報を打ち込むためのページ等を含んでもよい。
【0148】
ブロック1816では、OAuthサービス1804は、認可プロセスを継続する。例えば、認可の間、本システムは、ユーザに、認可プロセスが継続中であることを示す、ウィンドウ(例えば、
図16Dを参照して説明されるウィンドウ1640)を表示してもよい。ウィンドウは、ユーザが、認可プロセスをキャンセルすることを可能にしてもよく(例えば、キャンセルボタン1644を選択することによって)、OAuthサービス1804は、終了し、ユーザは、要求側アプリケーション1806に戻されるであろう。
【0149】
ブロック1820では、ディスパッチシーケンスが、背景において実行されることができる。ディスパッチシーケンスは、
図19を参照して下記に説明される、ディスパッチサービスによって実施されることができる。ディスパッチサービスは、アプリケーション間でデータを共有し、アプリケーション間通信を提供するために使用される。ディスパッチシーケンスは、ユーザ情報(例えば、ユーザ名、パスワード、支払証明書等)を第三者サービスに通信し、アクセストークンを第三者サービスから受信してもよい。
【0150】
ブロック1824において、第三者サービスとの認可プロセスが、成功する場合、ユーザは、ブロック1828において、要求側アプリケーション1806に戻るように戻される。ブロック1824において、認可が、成功しない場合、OAuthサービス1804は、ブロック1830に進み、これは、認可プロセスにおけるエラー状態を示す。例えば、ウィンドウ(例えば、
図16Eを参照して説明されるウィンドウ1648)が、ユーザに表示され、認可プロセス中にエラーが発生したことを示してもよい。ユーザは、第三者サービスを認可し続けずに、OAuthプロセスをキャンセルすることを選定することができ(例えば、キャンセルボタン1656を選択することによって)、その場合、ユーザは、要求側アプリケーション1806に戻され、OAuthプロセスは、終了するであろう。代替として、ユーザは、認可を再試行することを選定することができ(例えば、再試行ボタン1661を選択することによって)、OAuthプロセスは、ブロック1816に戻り、認可を再試行するであろう。
【0151】
図19は、OAuth認可サービス1804のための例示的システムアーキテクチャのブロック図である。本例証的実施例では、本システムアーキテクチャは、認可サーバ1902と、ディスパッチサービス1906と、認可アプリケーション1817と、複合現実ブラウザ1910(例えば、Helioブラウザのインスタンス)とを含む。ディスパッチサービス1906は、データを異なるアプリケーション間でやりとりさせることに関与する。複合現実ブラウザ1910は、ウェブページナビゲーションおよびレンダリングに関与する。ブラウザ1910は、暗号化機構を使用してもよいが、そうである必要はない。
【0152】
図19は、OAuthサービス1804のこれらのコンポーネント間で生じ得る、メッセージングのタイプの実施例を示す。例えば、アプリケーションまたはサービスは、openOauthWindow(url)をディスパッチサービス1906から呼び出すことによって、OAuth認可を実施するように試み得る。関数呼び出しの引数urlは、アプリケーション自体を識別するスキームを有し、ディスパッチサービスが認識することが可能である、リダイレクトurl(統一資源ロケータ)を含む。
【0153】
本呼び出しの受信に応じて、ディスパッチサービス1906は、openOauthWindow(url)を呼び出し、ウェブブラウザ1910に、ブラウザウィンドウを開かせる。開かれるブラウザウィンドウは、例えば、urlバーを伴わない、特殊ウィンドウであることができる。本特殊ブラウザウィンドウの実施例は、
図16Cおよび17Cに示され、それを参照して説明される、ウィンドウ1620である。本明細書に説明されるように、ブラウザウィンドウは、ウィンドウが、常時、ユーザの正面にあるように、ユーザの頭部姿勢に大まかに頭部に係止されることができる。
【0154】
いったんユーザが、その証明書を打ち込み、認可サービスが、合致を示すと、http応答ステータスコード(例えば、302リダイレクト)が、ブラウザ1910によって傍受されることができ、ディスパッチサービス1906は、アプリケーションurlおよび認可コード(例えば、
図19では「1234」)を用いて呼び出されることができる。例えば、ディスパッチサービス1906は、tryOpen()を使用して呼び出されることができ、ブラウザウィンドウは、次いで、閉じられ得る。ディスパッチサービス1906は、スキームに合致する、アプリケーションを呼び出すことができ、アプリケーションは、OAuth認可において、以下のアクション、すなわち、認可サーバを呼び出し、アクセストークンのための認可コードを交換することを実施する。
【0155】
OAuthサービス1804は、1つ以上のシステムまたはカーネルエクスポートライブラリを提供することができる。例えば、libdispatchserviceが、tryOpen()API呼び出しを介して、ディスパッチサービス1906にアクセスするために使用されることができる。別の実施例として、libservice_connectorが、サービス登録を初期化およびハンドリングするために使用されることができる。
【0156】
開発者に提供されるAPIは、プロセス間エクスポートAPIおよびプロセス間インポートAPIを含むことができる。例えば、ウェブブラウザ1910(例えば、Helio)は、ライブラリまたはカーネルエクスポートAPIを使用して、openOauthWindow呼び出しを用いて開かれることができる。
【表1】
【0157】
libdispatchserviceは、以下のプロセス間エクスポートAPIを含むことができる。
【表2】
【0158】
libdispatchserviceは、以下のプロセス間インポートAPIを含むことができる。
【表3】
【0159】
図20Aは、アプリケーション開発者のための認可フロー2000aの実施例を図示する。本実施例では、2004において、アプリケーション1806は、アプリケーション自体を識別するスキームを有し、ディスパッチサービス1906が認識することが可能である、統一資源識別子(URI)を登録する。URIは、名称またはリソースを識別し、具体的プロトコルを使用して、ネットワーク(例えば、ワールドワイドウェブまたはインターネット)を経由して、リソースの表現との相互作用を有効にするために使用される、文字列を含んでもよい。URIはまた、アプリケーション内の具体的ユーザインターフェースコンテキスト、例えば、アプリケーションの設定ページ等のデバイス特有のリソースを識別してもよい。統一資源ロケータ(URL)は、識別されたリソースが利用可能である場所およびリソースを読み出すための機構を規定する、URIのサブセットであることができる。実施例として、具体的リソースおよびリソースにアクセスする方法を識別するために、構造化クエリ言語(SQL)データベースのためのURIは、mysql://localhost@databasename:passwordであり得る。URLは、データベースがネットワーク上で見出され得る場所および使用されるべきプロトコルを識別することができる。本実施例と関連付けられる、URLは、mysql://localhostであり得る。
【0160】
アプリケーションは、openOauthWindowを呼び出し、ウェブブラウザOAuthウィンドウ2008を開くように、ディスパッチサービス1906に要求することによって、OAuth認可を実施することができる。本関数呼び出しの引数は、アプリケーションのための登録されたURLおよびキャンセルurlである。ウェブブラウザウィンドウは、信頼されたユニバースAPI呼び出しを使用して、アプリケーションを隠蔽することができる(例えば、それを背景化するために)。いくつかの実装では、ユニバースは、ユーザの環境内のディスプレイシステムのための仮想コンテンツの設置および表示を管理する、ソフトウェアコードの1つ以上のセットを備えてもよい。いくつかの実装では、ユニバースは、ユーザの環境内における設置のために、シーングラフをディスプレイシステムの異なる部分(例えば、コンポーネントまたはモジュール)から受け取ってもよい。ユーザは、2016に継続し、例えば、第三者サービスにログインする、または認可プロセスをキャンセルする。アクセストークンを含む、リダイレクトURLが、ディスパッチサービス1906に返される。アプリケーションは、2020においてウェイクアップされ、アクセストークンは、ディスパッチサービス1906によって、要求側アプリケーション1806に返される。
【0161】
図20Bは、ソフトウェア開発キット(SDK)を使用したアプリケーション開発者のための認可フロー2000bの実施例を図示する。例示的フロー2000bは、概して、
図20Aを参照して説明される例示的フロー2000aに類似する。しかしながら、本実施例では、SDK2040およびCAPI2044が、提供される。
例示的実装
【0162】
本明細書に説明されるシステム、方法、およびデバイスはそれぞれ、いくつかの側面を有するが、そのうちの単一の1つが、その望ましい属性に関与するわけではない。本開示の範囲を限定することなく、いくつかの非限定的特徴が、ここで簡単に議論されるであろう。以下の段落は、本明細書に説明されるデバイス、システム、および方法の種々の例示的実装を説明する。1つ以上のコンピュータのシステムは、動作時、システムにアクションを実施させる、システム上にインストールされるソフトウェア、ファームウェア、ハードウェア、またはそれらの組み合わせを有することによって、特定の動作またはアクションを実施するように構成されることができる。1つ以上のコンピュータプログラムは、データ処理装置によって実行されると、装置にアクションを実施させる、命令を含むことによって、特定の動作またはアクションを実施するように構成されることができる。
【0163】
実施例1:仮想コンテンツを3次元(3D)空間環境内に表示するためのディスプレイシステムであって、仮想コンテンツをディスプレイシステムのユーザの眼に提示するように構成される、頭部搭載型ディスプレイと、頭部搭載型ディスプレイと通信する、回路網であって、アプリケーション特有仮想コンテンツをユーザに提示するように構成される、アプリケーションを実行し、ユーザをウェブサービスに認可するための認可要求をアプリケーションから受信し、アプリケーションを背景化し、頭部搭載型ディスプレイに、ユーザに、ユーザ入力を受け取り、アプリケーションまたは他のアプリケーションがユーザ入力を受信することを防止するように構成される、モード式認可ウィンドウを提示させ、ウェブサービスによる認可と関連付けられる、ユーザ入力を受信し、ユーザ入力をウェブサービスに通信し、アクセストークンをウェブサービスから受信し、アクセストークンは、ウェブサービスによる認可成功を示し、アクセストークンをアプリケーションに通信し、認可サービスを終了するように構成される、認可サービスを実行し、アプリケーションを前景化するように構成される、回路網とを備える、ディスプレイシステム。
【0164】
実施例2:アプリケーションは、没入型アプリケーションを備える、実施例1に記載のディスプレイシステム。
【0165】
実施例3:頭部搭載型ディスプレイは、アプリケーション特有仮想コンテンツを提示し、ディスプレイシステムによって実行される他のアプリケーションによって生成された仮想コンテンツを表示しないように構成される、実施例1または実施例2に記載のディスプレイシステム。
【0166】
実施例4:アプリケーションは、ランドスケープアプリケーションを備える、実施例1-3のいずれか1項に記載のディスプレイシステム。
【0167】
実施例5:頭部搭載型ディスプレイは、アプリケーション特有仮想コンテンツを提示し、また、ディスプレイシステムによって実行される他のアプリケーションによって生成された仮想コンテンツを表示するように構成される、実施例1-4のいずれか1項に記載のディスプレイシステム。
【0168】
実施例6:回路網は、アプリケーションの実行の間、任意の時点において、認可要求をアプリケーションから受信するように構成される、実施例1-5のいずれか1項に記載のディスプレイシステム。
【0169】
実施例7:アプリケーションを背景化することは、回路網に、アプリケーションをより低い優先順位で実行すること、アプリケーション特有仮想コンテンツを隠すこと、アプリケーション特有仮想コンテンツの不透明度または輝度を低減させること、アプリケーション特有仮想コンテンツの透明度を増加させること、アプリケーション特有仮想コンテンツの表示深度を増加させること、アプリケーション特有仮想コンテンツのサイズを減少させること、またはアプリケーションがユーザ入力を受信することを防止することのうちの1つ以上のものを実施させることを含む、実施例1-6のいずれか1項に記載のディスプレイシステム。
【0170】
実施例8:アプリケーションを前景化することは、回路網に、アプリケーションをより高い優先順位で実行すること、アプリケーション特有仮想コンテンツを表示すること、アプリケーション特有仮想コンテンツの不透明度または輝度を増加させること、アプリケーション特有仮想コンテンツの透明度を減少させること、アプリケーション特有仮想コンテンツの表示深度を減少させること、アプリケーション特有仮想コンテンツのサイズを増加させること、またはアプリケーションがユーザ入力を受信することを可能にすることのうちの1つ以上のものを実施させることを含む、実施例1-7のいずれか1項に記載のディスプレイシステム。
【0171】
実施例9:頭部搭載型ディスプレイは、モード式認可ウィンドウを大まかな頭部係止設定において表示するように構成される、実施例1-8のいずれか1項に記載のディスプレイシステム。
【0172】
実施例10:頭部搭載型ディスプレイは、モード式認可ウィンドウをユーザの頭部移動に応答して移動する位置に表示するように構成される、実施例1-9のいずれか1項に記載のディスプレイシステム。
【0173】
実施例11:位置は、ユーザの真正面にある、実施例10に記載のディスプレイシステム。
【0174】
実施例12:位置は、モード式認可ウィンドウ内のテキストまたはグラフィックがユーザにとって読みやすいようなユーザからの距離に対応する、実施例10または実施例11に記載のディスプレイシステム。
【0175】
実施例13:モード式認可ウィンドウは、アプリケーションの名称、ウェブサービスのウェブアドレスの少なくとも一部、認可要求をキャンセルするための選択可能ユーザ入力特徴、またはウェブサービスからの認可ウィンドウのうちの1つ以上のものを描写する、実施例1-12のいずれか1項に記載のディスプレイシステム。
【0176】
実施例14:モード式認可ウィンドウは、第1のユーザ入力の受信に応じて、ウェブサービスの完全ウェブアドレスを表示するように構成される、実施例13に記載のディスプレイシステムモード式。
【0177】
実施例15:モード式認可ウィンドウは、ユーザがウェブサービスのウェブアドレスを通してスクロールすることを可能にするように構成される、スクロールバーを表示するように構成される、実施例13に記載のディスプレイシステム。
【0178】
実施例16:ウェブサービスからの認可ウィンドウは、サインオンウィンドウ、ユーザパスワードを受け取るように構成される、ウィンドウ、またはユーザ支払証明書を受け取るように構成される、ウィンドウのうちの1つ以上のものを備える、実施例12-15のうちのいずれか1項に記載のディスプレイシステム。
【0179】
実施例17:モード式認可ウィンドウは、ウェブブラウザウィンドウを備える、実施例1-16のいずれか1項に記載のディスプレイシステム。
【0180】
実施例18:認可サービスは、アプリケーションの子として実行される、実施例1-17のいずれか1項に記載のディスプレイシステム。
【0181】
実施例19:認可サービスは、アプリケーションプログラミングインターフェース(API)呼び出しを介して、アプリケーションから呼び出される、実施例1-18のいずれか1項に記載のディスプレイシステム。
【0182】
実施例20:認可サービスは、ソフトウェア開発キット(SDK)呼び出しを介して、アプリケーションから呼び出される、実施例1-19のいずれか1項に記載のディスプレイシステム。
【0183】
実施例21:ウェブサービスは、ディスプレイシステムから遠隔でアクセスされる、第三者ウェブサービスである、実施例1-20のいずれか1項に記載のディスプレイシステム。
【0184】
実施例22:複合現実ディスプレイシステムのユーザを認可するための方法であって、複合現実ディスプレイシステム上で実行されるアプリケーションから、ユーザをウェブサービスに認可するための要求を受信するステップと、ユーザに、ウェブサービスによる認可と関連付けられるユーザ入力を受け取り、アプリケーションまたは他のアプリケーションがユーザ入力を受信することを防止するように構成される、認可ウィンドウを表示するステップと、ユーザ入力をウェブサービスに通信するステップと、アクセストークンをウェブサービスから受信するステップであって、アクセストークンは、ウェブサービスによる認可成功を示す、ステップと、アクセストークンをアプリケーションに通信するステップとを含む、方法。
【0185】
実施例23:アプリケーションは、没入型アプリケーションまたはランドスケープアプリケーションを備える、実施例22に記載の方法。
【0186】
実施例24:ユーザに認可ウィンドウを表示することに先立って、アプリケーションを背景化するステップと、アクセストークンをウェブサービスから受信した後に、アプリケーションを前景化するステップとをさらに含む、実施例22または実施例23に記載の方法。
【0187】
実施例25:認可ウィンドウは、モード式ウィンドウを備える、実施例22-24のいずれか1項に記載の方法。
【0188】
実施例26:認可ウィンドウは、アプリケーションの子である、実施例22-25のいずれか1項に記載の方法。
【0189】
実施例27:複合現実ディスプレイシステムのユーザを認可するための方法であって、アプリケーションを複合現実ディスプレイシステム上で実行するステップであって、アプリケーションは、ユーザへの表示のために、アプリケーション特有仮想コンテンツを生成するステップと、アプリケーションと関連付けられるウェブアドレスを登録するステップと、アプリケーション特有仮想コンテンツをユーザに表示しないように隠蔽しながら、ユーザに、モード式認可ウィンドウを表示するステップと、モード式認可ウィンドウを介して打ち込まれるユーザ入力に応答して、ウェブ応答ステータスコードを受信するステップと、アプリケーションと関連付けられるウェブアドレスを使用して、ウェブ応答ステータスコードをアプリケーションに通信するステップとを含む、方法。
【0190】
実施例28:アプリケーションは、没入型アプリケーションまたはランドスケープアプリケーションを備える、実施例27に記載の方法。
【0191】
実施例29:アプリケーション特有仮想コンテンツを隠蔽するステップは、アプリケーション特有仮想コンテンツを表示しないこと、アプリケーション特有仮想コンテンツの不透明度または輝度を低減させること、アプリケーション特有仮想コンテンツの透明度を増加させること、アプリケーション特有仮想コンテンツの表示深度を増加させること、アプリケーション特有仮想コンテンツのサイズを減少させること、またはモード式認可ウィンドウを没入型モードで表示することのうちの1つ以上のものを含む、実施例27または実施例28に記載の方法。
【0192】
実施例30:モード式認可ウィンドウは、アプリケーションまたは他のアプリケーションがユーザ入力を受信することを防止する、実施例27-29のいずれか1項に記載の方法。
【0193】
実施例31:モード式認可ウィンドウは、アプリケーションの子である、実施例27-30のいずれか1項に記載の方法。
【0194】
実施例32:アプリケーションとモード式認可ウィンドウとの間の通信を提供するように構成される、ソフトウェア開発キットを提供するステップをさらに含む、実施例27-31のいずれか1項に記載の方法。
【0195】
実施例33:ウェブ応答ステータスコードをアプリケーションに通信後、モード式認可ウィンドウを隠蔽するステップと、アプリケーション特有仮想コンテンツをユーザに表示するステップとをさらに含む、実施例27-32のいずれか1項に記載の方法。
【0196】
実施例34:モード式認可ウィンドウを隠蔽するステップは、モード式認可ウィンドウを表示しないこと、モード式認可ウィンドウの不透明度または輝度を低減させること、モード式認可ウィンドウの透明度を増加させること、モード式認可ウィンドウの表示深度を増加させること、モード式認可ウィンドウのサイズを減少させることのうちの1つ以上のものを含む、実施例33に記載の方法。
【0197】
上記に述べられたように、上記に提供される説明される実施例の実装は、ハードウェア、方法またはプロセス、および/またはコンピュータアクセス可能媒体上のコンピュータソフトウェアを含んでもよい。
さらなる考慮点
【0198】
本明細書に説明される、および/または添付される図に描写されるプロセス、方法、およびアルゴリズムはそれぞれ、具体的かつ特定のコンピュータ命令を実行するように構成される、1つ以上の物理的コンピューティングシステム、ハードウェアコンピュータプロセッサ、特定用途向け回路、および/または電子ハードウェアによって実行される、コードモジュールにおいて具現化され、それによって完全または部分的に自動化され得る。例えば、コンピューティングシステムは、具体的コンピュータ命令とともにプログラムされた汎用コンピュータ(例えば、サーバ)または専用コンピュータ、専用回路等を含むことができる。コードモジュールは、実行可能プログラムにコンパイルおよびリンクされる、動的リンクライブラリ内にインストールされ得る、またはインタープリタ型プログラミング言語において書き込まれ得る。いくつかの実装では、特定の動作および方法が、所与の機能に特有の回路によって実施され得る。
【0199】
さらに、本開示の機能性のある実装は、十分に数学的、コンピュータ的、または技術的に複雑であるため、(適切な特殊化された実行可能命令を利用する)特定用途向けハードウェアまたは1つ以上の物理的コンピューティングデバイスは、例えば、関与する計算の量または複雑性に起因して、または結果を実質的にリアルタイムで提供するために、機能性を実施する必要があり得る。例えば、ビデオは、多くのフレームを含み、各フレームは、数百万のピクセルを有し得、具体的にプログラムされたコンピュータハードウェアは、商業的に妥当な時間量において所望の画像処理タスクまたは用途を提供するようにビデオデータを処理する必要がある。
【0200】
コードモジュールまたは任意のタイプのデータは、ハードドライブ、ソリッドステートメモリ、ランダムアクセスメモリ(RAM)、読取専用メモリ(ROM)、光学ディスク、揮発性または不揮発性記憶装置、同一物の組み合わせ、および/または同等物を含む、物理的コンピュータ記憶装置等の任意のタイプの非一過性コンピュータ可読媒体上に記憶され得る。本方法およびモジュール(またはデータ)はまた、無線ベースおよび有線/ケーブルベースの媒体を含む、種々のコンピュータ可読伝送媒体上で生成されたデータ信号として(例えば、搬送波または他のアナログまたはデジタル伝搬信号の一部として)伝送され得、種々の形態(例えば、単一または多重化アナログ信号の一部として、または複数の離散デジタルパケットまたはフレームとして)をとり得る。開示されるプロセスまたはプロセスブロックまたはステップの結果は、任意のタイプの非一過性有形コンピュータ記憶装置内に持続的または別様に記憶され得る、またはコンピュータ可読伝送媒体を介して通信され得る。
【0201】
本明細書に説明される、および/または添付される図に描写されるフロー図における任意のプロセス、ブロック、状態、ステップ、または機能性は、プロセスにおいて具体的機能(例えば、論理または算術)またはステップを実装するための1つ以上の実行可能命令を含む、コードモジュール、セグメント、またはコードの一部を潜在的に表すものとして理解されたい。種々のプロセス、ブロック、状態、ステップ、または機能性は、組み合わせられる、再配列される、本明細書に提供される例証的実施例に追加される、そこから削除される、修正される、または別様にそこから変更されることができる。いくつかの実施形態では、付加的または異なるコンピューティングシステムまたはコードモジュールが、本明細書に説明される機能性のいくつかまたは全てを実施し得る。本明細書に説明される方法およびプロセスはまた、いずれの特定のシーケンスにも限定されず、それに関連するブロック、ステップ、または状態は、適切である他のシーケンスで、例えば、連続して、並行して、またはある他の様式で実施されることができる。タスクまたはイベントが、開示される例示的実施形態に追加される、またはそこから除去され得る。さらに、本明細書に説明される実装における種々のシステムコンポーネントの分離は、例証目的のためであり、全ての実装においてそのような分離を要求するものとして理解されるべきではない。説明されるプログラムコンポーネント、方法、およびシステムは、概して、単一のコンピュータ製品においてともに統合される、または複数のコンピュータ製品にパッケージ化され得ることを理解されたい。多くの実装変形例が、可能である。
【0202】
本プロセス、方法、およびシステムは、ネットワーク(または分散)コンピューティング環境において実装され得る。ネットワーク環境は、企業全体コンピュータネットワーク、イントラネット、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、パーソナルエリアネットワーク(PAN)、クラウドコンピューティングネットワーク、クラウドソースコンピューティングネットワーク、インターネット、およびワールドワイドウェブを含む。ネットワークは、有線または無線ネットワークまたは任意の他のタイプの通信ネットワークであり得る。
【0203】
本開示のシステムおよび方法は、それぞれ、いくつかの革新的側面を有し、そのうちのいかなるものも、本明細書に開示される望ましい属性に単独で関与しない、またはそのために要求されない。上記に説明される種々の特徴およびプロセスは、相互に独立して使用され得る、または種々の方法で組み合わせられ得る。全ての可能な組み合わせおよび副次的組み合わせが、本開示の範囲内に該当することが意図される。本開示に説明される実装の種々の修正が、当業者に容易に明白であり得、本明細書に定義される一般原理は、本開示の精神または範囲から逸脱することなく、他の実装に適用され得る。したがって、請求項は、本明細書に示される実装に限定されることを意図されず、本明細書に開示される本開示、原理、および新規の特徴と一貫する最も広い範囲を与えられるべきである。
【0204】
別個の実装の文脈において本明細書に説明されるある特徴はまた、単一の実装における組み合わせにおいて実装されることができる。逆に、単一の実装の文脈において説明される種々の特徴もまた、複数の実装において別個に、または任意の好適な副次的組み合わせにおいて実装されることができる。さらに、特徴がある組み合わせにおいて作用するものとして上記に説明され、さらに、そのようなものとして最初に請求され得るが、請求される組み合わせからの1つ以上の特徴は、いくつかの場合では、組み合わせから削除されることができ、請求される組み合わせは、副次的組み合わせまたは副次的組み合わせの変形例を対象とし得る。いかなる単一の特徴または特徴のグループも、あらゆる実施形態に必要または必須ではない。
【0205】
とりわけ、「~できる(can)」、「~し得る(could)」、「~し得る(might)」、「~し得る(may)」、「例えば(e.g.)」、および同等物等、本明細書で使用される条件文は、別様に具体的に記載されない限り、または使用されるような文脈内で別様に理解されない限り、概して、ある実装がある特徴、要素、ブロック、および/またはステップを含む一方、他の実施形態がそれらを含まないことを伝えることが意図される。したがって、そのような条件文は、概して、特徴、要素、ブロック、および/またはステップが、1つ以上の実装に対していかようにも要求されること、または1つ以上の実装が、著者の入力または促しの有無を問わず、これらの特徴、要素、ブロック、および/またはステップが任意の特定の実装において含まれる、または実施されるべきかどうかを決定するための論理を必然的に含むことを合意することを意図するものではない。用語「~を備える(comprising)」、「~を含む(including)」、「~を有する(having)」、および同等物は、同義語であり、非限定的方式で包括的に使用され、付加的要素、特徴、行為、動作等を除外しない。また、用語「または」は、その包括的意味において使用され(およびその排他的意味において使用されず)、したがって、例えば、要素のリストを接続するために使用されると、用語「または」は、リスト内の要素のうちの1つ、いくつか、または全てを意味する。加えて、本願および添付される請求項で使用されるような冠詞「a」、「an」、および「the」は、別様に規定されない限り、「1つ以上の」または「少なくとも1つ」を意味するように解釈されるべきである。
【0206】
本明細書で使用されるように、項目のリスト「~のうちの少なくとも1つ」を指す語句は、単一の要素を含む、それらの項目の任意の組み合わせを指す。ある実施例として、「A、B、またはCのうちの少なくとも1つ」は、A、B、C、AおよびB、AおよびC、BおよびC、およびA、B、およびCを網羅することが意図される。語句「X、Y、およびZのうちの少なくとも1つ」等の接続文は、別様に具体的に記載されない限り、概して、項目、用語等がX、Y、またはZのうちの少なくとも1つであり得ることを伝えるために使用されるような文脈で別様に理解される。したがって、そのような接続文は、概して、ある実装が、Xのうちの少なくとも1つ、Yのうちの少なくとも1つ、およびZのうちの少なくとも1つがそれぞれ存在するように要求することを示唆することを意図するものではない。
【0207】
同様に、動作は、特定の順序で図面に描写され得るが、これは、望ましい結果を達成するために、そのような動作が示される特定の順序で、または連続的順序で実施される、または全ての図示される動作が実施される必要はないと認識されるべきである。さらに、図面は、フローチャートの形態で1つ以上の例示的プロセスを図式的に描写し得る。しかしながら、描写されない他の動作も、図式的に図示される例示的方法およびプロセス内に組み込まれることができる。例えば、1つ以上の付加的動作が、図示される動作のいずれかの前に、その後に、それと同時に、またはその間に実施されることができる。加えて、動作は、他の実装において再配列される、または再順序付けられ得る。ある状況では、マルチタスクおよび並列処理が、有利であり得る。さらに、上記に説明される実装における種々のシステムコンポーネントの分離は、全ての実装におけるそのような分離を要求するものとして理解されるべきではなく、説明されるプログラムコンポーネントおよびシステムは、概して、単一のソフトウェア製品においてともに統合される、または複数のソフトウェア製品にパッケージ化され得ることを理解されたい。加えて、他の実装も、以下の請求項の範囲内である。いくつかの場合では、請求項に列挙されるアクションは、異なる順序で実施され、依然として、望ましい結果を達成することができる。