Door for artificial reality universe crossing

Abstract

Aspects of the present disclosure relate to creating a virtual gate within an artificial reality (XR) universe for traversing within the XR universe and between other XR universe. Users may create virtual doors that control access to their private properties (e.g., the world, parcel, house, etc.) in the XR universe. For example, an owner of a virtual door may manually lock the door to prevent any user from entering their property through the virtual door. As another example, an owner of a virtual door may configure door permissions and / or privacy settings that act as heuristic information from which a door access control manager determines whether to authorize access to a particular user, XR world, and / or XR universe. The XR universe traversing system can control the execution environment to be smoothly converted between different applications, so that a user can traverse between different XR universe under the condition that the user does not need to leave the XR environment.

Description

Technical Field

[0001] The present disclosure relates to providing virtual doors within an artificial reality (hyper-reality (XR)) universe for traversal through within the XR universe and between other XR universes and experiences. Background Art

[0002] A user interacting with an artificial reality (XR) device can view content in an artificial reality environment that includes real-world objects and / or two-dimensional (2D) virtual objects and / or three-dimensional (3D) virtual objects. For example, an artificial reality environment can be a virtual environment depicted by a virtual reality (VR) device that shows a set of virtual objects. As another example, an artificial reality environment can be a mixed reality environment that has real-world objects and virtual objects that are supplemented on top of the real-world objects. Users can view objects in the artificial reality environment and modify content in the artificial reality environment.

[0003] The virtual land within the entire virtual world or XR world can be divided into multiple plots and allocated, which can be owned by different users. In some cases, a user can own plots located near other users (e.g., within a virtual city). Users within the XR world can navigate the environment and access virtual properties built and maintained by other users. Typically, access to user properties in a virtual world or XR world or universe is unrestricted, allowing users to freely navigate and view between other users' virtual properties.

[0004] Furthermore, accessing a given XR experience typically involves launching a web application or native application that can retrieve assets from a server and / or blockchain and render a portion of the XR experience within some proximity of the user's avatar. As a result, switching between XR experiences typically involves exiting the current XR experience application, launching a different application, and logging into that XR experience application - which can be inconvenient, cumbersome, and potentially disruptive to the user's immersion in the XR environment. Summary of the invention

[0005] According to one aspect, a method for creating a virtual door for a user to traverse one or more artificial reality (XR) worlds is provided, the method comprising:

[0006] Receiving, at a computing system, a first request from a first user to create a first virtual door within a first XR world, the first virtual door linking the first XR world to a second XR world; obtaining one or more rules defining restrictions on creating virtual doors in the first XR world, the restrictions defining one or more of who can create virtual doors and / or where a virtual door from the first world can lead to, wherein if the one or more rules are satisfied, the user can create the virtual door; determining, based on at least one of the first user and the second XR world, that one or more rules related to restrictions defining one or more of who can create virtual doors and / or where a virtual door from the first world can lead to are satisfied; and generating, within the first XR world, a first virtual door linking to the second XR world based on determining that the one or more rules are satisfied.

[0007] The one or more rules may include a rule defining an allow list of users. Determining that the one or more rules are satisfied may include determining that the allow list of users includes the first user.

[0008] The one or more rules may include a rule defining a user block list.Determining that the one or more rules are satisfied may include determining that the user block list does not include the first user.

[0009] The one or more rules may include a rule defining an allowed list of worlds. Determining that the one or more rules are satisfied may include determining that the allowed list of worlds includes the second XR world.

[0010] The one or more rules may include a world block list.Determining that the one or more rules are satisfied may include determining that the world block list does not include the second XR world.

[0011] The one or more rules may include a rule specifying a world rating minimum threshold. Determining that the one or more rules are satisfied may include: determining a world rating associated with the second XR world; and determining that the one or more rules are satisfied based at least in part on determining that the world rating is above the world rating minimum threshold.

[0012] The one or more rules may include a rule specifying a minimum threshold of world similarity. Determining that the one or more rules are satisfied may include: determining a similarity score indicating a degree of similarity between the first XR world and the second XR world; and determining that the one or more rules are satisfied based at least in part on determining that the similarity score is above the minimum threshold of world similarity.

[0013] The similarity score may be based at least in part on one or more first tags associated with the first XR world and one or more second tags associated with the second XR world.

[0014] The similarity score may be based at least in part on a first content type associated with the first XR world and a second content type associated with the second XR world.

[0015] The first XR world and the second XR world may be located within the same XR universe hosted by an XR universe server system.

[0016] The first XR world may be located within a first XR universe hosted by a first XR universe server system, and the second XR world may be located within a second XR universe hosted by a second XR universe server system.

[0017] According to another aspect, a computer-readable storage medium is provided, the computer-readable storage medium storing instructions, which, when executed by a computing system, cause the computing system to perform the above method.

[0018] According to another aspect, a computing system is provided, which includes one or more processors and one or more memories storing instructions, which, when executed by the one or more processors, enable the computing system to execute the above method.

[0019] According to yet another aspect, a computer-readable storage medium is provided, the computer-readable storage medium storing instructions that, when executed by a computing system, cause the computing system to perform operations for accessing a virtual door for a user to traverse one or more artificial reality XR worlds, the operations comprising: receiving, at the computing system, a first request from a first user to access a first virtual door within a first XR world, the first virtual door being linked to a second XR world; obtaining one or more rules that define restrictions on accessing the virtual door in the first XR world, wherein the user is able to access the virtual door if the one or more rules are satisfied; determining, based at least in part on the first user, that the one or more rules are satisfied; and causing the first user to traverse through the first virtual door to reach the second XR world based on determining that the one or more rules are satisfied.

[0020] The one or more rules may include: rules defining a user allow list, and determining that the one or more rules are satisfied may include determining that the user allow list includes the first user; and / or a user block list, and determining that the one or more rules are satisfied may include determining that the user block list does not include the first user.

[0021] The one or more rules may include rules defining time limits for a day, and determining that the one or more rules are satisfied may include: determining a current time of day; and determining that the one or more rules are satisfied based at least in part on determining that the current time of day is outside the time limits for the day.

[0022] According to yet another aspect, a computing system for accessing a virtual door for a user to traverse one or more artificial reality (XR) worlds is provided, the computing system comprising: one or more processors; and one or more memories storing instructions that, when executed by the one or more processors, cause the computing system to perform operations, the operations comprising: receiving, at the computing system, a first request from a first user to access a virtual door within an XR world, the virtual door being linked to an XR experience; obtaining one or more rules defining restrictions on accessing the virtual door in the XR world, wherein if the one or more rules are satisfied, the user is able to access the virtual door; determining, based at least in part on the first user, that the one or more rules are satisfied; and causing the first user to traverse the virtual door to reach the XR experience based on determining that the one or more rules are satisfied.

[0023] The above operations may also include: receiving a second request from the first user to return to the XR world from within the XR experience; and upon receiving the second request, causing the first user to exit the XR experience and return to the XR world.

[0024] Receiving the second request may include receiving: a voice command from the first user within the XR experience, and / or a menu input selection from the first user within the XR experience.

[0025] The one or more memories may also store thereon an XR universe application that interfaces with the XR world and an XR experience application that interfaces with the XR experience, and wherein causing the first user to pass through the virtual door to reach the XR experience includes: launching the XR experience application; and causing the computing system to switch from the XR universe application to the XR experience application.

[0026] It will be appreciated that any feature described herein as being suitable for incorporation into one or more aspects or one or more embodiments of the present disclosure is intended to be universal in any and all aspects and embodiments of the present disclosure. Other aspects of the present disclosure may be understood by those skilled in the art based on the specification, claims and drawings of the present disclosure. The above general description and the following detailed description are exemplary and illustrative only, and are not limitations of the claims.

[0027] According to another aspect, there is a kind of according to another aspect, there is a kind of according to another aspect, there is a kind of accompanying drawing description

[0028] Figure 1 is a block diagram showing an overview of various devices on which some embodiments of the present technology may operate.

[0029] Figure 2Ais a line diagram illustrating a virtual reality headset that may be used in some embodiments of the present technology.

[0030] Figure 2B is a line diagram illustrating a mixed reality head mounted viewer that may be used in some embodiments of the present technology.

[0031] Figure 2C is a line diagram illustrating a controller that, in some implementations, a user may hold with one or both hands to interact with an artificial reality environment.

[0032] Figure 3 is a block diagram illustrating an overview of an environment in which some embodiments of the present technology may operate.

[0033] Figure 4 is a block diagram illustrating some components that may be used in some implementations in a system employing the disclosed technology.

[0034] Figure 5 is a flow chart illustrating a process for creating a new virtual door between two locations in an XR universe in some embodiments of the present technology.

[0035] Figure 6 is a flow chart illustrating a process for providing user-settings-based access control to a virtual door connecting two locations in an XR universe in some embodiments of the present technology.

[0036] Figure 7 is a flow chart illustrating a process for providing key-based access control to a virtual door connecting two locations in an XR universe in some embodiments of the present technology.

[0037] Fig. 8A is a flow chart illustrating a process for authorizing the creation of a virtual door between a first XR world and a second XR world in some embodiments of the present technology.

[0038] Figure 8B is a flow chart illustrating a process for a user to discover and traverse a virtual door in an XR universe in some embodiments of the present technology.

[0039] Figure 8C is a flow chart illustrating a process for creating blockchain-based door keys to facilitate user access control to virtual doors in the XR universe in some embodiments of the present technology.

[0040] Fig. 9A and Fig. 9B is a flow chart illustrating a process for creating and accessing virtual doors connecting locations in different XR universes or experiences in some embodiments of the present technology.

[0041] Fig. 10A , Fig. 10B and Fig. 10C is a conceptual diagram illustrating an example architecture for enabling inter-universe interoperability to facilitate intra-universe traversal across different XR universes or experiences.

[0042] Fig.11 is a conceptual diagram showing an example of traversing a virtual door connecting different XR universes or experiences.

[0043] Fig.12 is a conceptual diagram illustrating an example user interface (UI) for managing virtual doors.

[0044] The technology described herein may be better understood by referring to the following detailed description in conjunction with the accompanying drawings, in which like reference numbers refer to identical or functionally similar elements. DETAILED DESCRIPTION

[0045] Aspects of the present disclosure relate to providing virtual doors within an artificial reality (XR) universe for traversing within the XR universe and between other XR universes and experiences. The XR universe traversal system can facilitate the creation, access, and interoperability of virtual doors that serve as shortcuts, entrances, or gateways between different locations within the XR universe and / or between different XR universes. Users can create virtual doors that control access to the user's private property in the XR universe (e.g., a world or a plot in a world). For example, the creator of a virtual world can define rules such as which doors can be linked to the world; and where doors created in the world can lead to. As another example, the owner of a virtual door can manually lock the door to prevent any user from entering their property through the virtual door. As another example, the owner of a virtual door can configure door permissions and / or privacy settings that act as heuristics by which the door access control manager determines whether to authorize access to a particular user, XR world, and / or XR universe (e.g., based on a user friend list, a user allow list, a user block list, an XR world allow list, an XR world block list, a limit on the number of visitors at a given time, etc.).

[0046] In some examples, a user, a group of users, or an entity ("owner") can create and maintain an XR world within an XR universe. The owner of the XR world can specify policies or privacy preferences for users accessing the world: which users are allowed to create new virtual doors, and / or are allowed to access existing virtual doors to or from the XR world. For example, the XR world owner can configure a creation policy that defines which one or more users can and cannot create new virtual doors within their world; the types of XR worlds in which new virtual doors can be created (e.g., worlds of the same or similar type, worlds with ratings that meet or exceed a threshold rating, etc.); and / or possible restrictions on the creation of new virtual doors. Similarly, the XR world owner can configure an access policy that defines which one or more users can and cannot access virtual doors within their world; specific time periods during which users can and cannot access virtual doors within their world; specific time periods during which users can and cannot access their world via other virtual doors; and / or other possible restrictions on the use of virtual doors that connect the virtual world to other virtual worlds.

[0047] Virtual doors can also allow users to travel between XR worlds (e.g., a shared XR environment that is typically an open world experience) and XR experiences (e.g., XR applications that one or more users can view or participate in, such as XR games, XR simulations, XR movies, or some other XR experiences). For example, one or more users gathered in an XR world can enter a virtual door in the world to play a multiplayer XR game together. The XR experience can provide a similar mechanism (e.g., a virtual door, a menu, or another user interface) to allow the one or more users to return to the original XR world. In this way, virtual doors can allow users to switch between different XR experiences without leaving the XR environment.

[0048] In some embodiments, the owner of a virtual door can mint a key that provides access to the virtual door to a specific user. The XR universe traversal system can interface with a service system (service) and / or a data repository external to the XR universe to facilitate the creation of door keys. For example, the XR universe traversal system can interface with the blockchain to create new non-fungible tokens (NFTs), which are transferred to the cryptocurrency wallet of a specific user. When the recipient of the NFT key wishes to go to the user's property through the virtual door, the recipient can authenticate themselves and present proof of ownership of the door key to "unlock" the virtual door. In this way, the key to the virtual door can be managed as an asset independent of any particular XR universe, thereby preventing potential manipulation of XR universe applications and enabling interoperable access to virtual keys across different XR universes.

[0049] In some embodiments, the XR universe traversal system may be implemented as a set of features within a particular XR universe that facilitate intra-universe traversal. In these embodiments, the XR universe traversal system may provide convenient tools and / or user interfaces (UIs) that allow users to create new virtual doors and link these virtual doors to specific destinations, so that the user's property can be used as a hub or gateway to multiple destinations within the XR universe that the user frequently travels to (e.g., markets, entertainment, friends' properties, etc.). If a user wishes to create a new virtual door connected to a private plot or location in a world within the XR universe (e.g., if the owner of the destination world or plot has configured its virtual door permissions to require the owner's explicit authorization), the system may facilitate the owner of the destination plot to authorize the creation of a new virtual door. This tool for creating and authorizing the creation of virtual doors can enable non-technical users to implement convenient and quick travel shortcuts without having to design virtual objects (e.g., artifacts, canvases, etc.) and upload them to their virtual property, and without having to understand any specific software development kit (SDK), application programming interface (API), uniform resource identifier (URI) scheme, or other technical method for creating interactable objects that transport a user's avatar to a specific destination.

[0050] In some embodiments, the XR universe traversal system can facilitate the creation and use of virtual doors that connect different XR universes and / or experiences for traversal between universes and experiences. In an example embodiment, a host server may provide a virtual door controller that provides interoperable communications between different XR universes, where each XR universe separately implements a digital interface for external requests to create a virtual door within the corresponding XR universe. For example, two different XR universes may each provide an API endpoint for creating and linking virtual doors in each corresponding universe. When a user in a first XR universe requests the XR universe traversal system to create a virtual door to a second XR universe, the XR universe traversal system may execute a sequence of operations (e.g., an API function call to each universe server) that instantiates and links the virtual door for each corresponding XR universe. When a user enters one of the multiple virtual doors, the XR universe traversal system can cause the user's XR system or computing device to open a separate XR application (e.g., a web application, a containerized application, a local application, etc.) with metadata indicating that the newly opened XR application logs the user into the universe of the XR application and positions the user's avatar at or near the corresponding door in the XR universe. As another example, if the user enters a virtual door linked to an XR experience associated with an XR application stored on (or downloadable to) the user's device, the virtual door controller can cause the user's device to launch the XR application and automatically switch context to the XR application, allowing the user to traverse from one XR experience to another without having to enter a different XR world. In this way, the XR universe traversal system can allow the user to quickly "hop" between XR universes or experiences without having to manually exit the current XR application, launch a different XR application, log into the destination XR universe, and navigate to a desired location within the XR universe.

[0051] In some cases, a user may access the XR universe in a web browser. In this case, the XR universe traversal system may control various aspects of the web browser to facilitate smooth transitions between different web applications, such as performing secure hypertext transfer protocol (HTTPS) requests, launching uniform resource locators (URLs) / URIs, facilitating authentication through authentication services, and / or by utilizing browser plug-ins (e.g., plug-ins that link to a user's cryptocurrency wallet, plug-ins that enhance 3D graphics rendering, plug-ins for managing user credentials and / or passwords, plug-ins that interface with the XR universe traversal system, etc.). The web browser may act as a runtime environment or virtual machine in which a user may (e.g., use WebGL TM, WebXR, WebAssembly, etc.) to execute XR universe applications, and the web browser can also facilitate communication between various web applications (for example, using inter-process communication (IPC), information recording procedures (cookies), broadcast channel APIs, service workers, etc.). For XR universes that rely on blockchain-based authentication, the browser plug-in can provide access to one or more blockchain wallets of the user to facilitate logging into a given XR universe.

[0052] As a specific example, a user instructs their avatar in a first XR universe to pass through a virtual door linked to a location in a second XR universe. Upon interacting with the door, the first XR application retrieves metadata and / or other information indicating the destination XR universe and the destination location within the XR universe (e.g., a deep link encoding the XR universe and the destination within the XR universe). The XR universe traversal system may parse the information about the destination universe and launch a new browser tab or window to open an XR web application for the destination XR universe on the user's computer. The XR universe traversal system may retrieve additional information (e.g., user credentials from a wallet or password manager, a stored session token indicating a recent authentication, and / or other authentication information) to facilitate the user's login to the destination XR universe. Upon entering the XR universe, the XR universe traversal system may instruct the newly opened XR application to update the user's avatar location in the XR universe to the destination location associated with the virtual door. Some or all of these steps may be performed in the background while the user remains in the original XR universe, so that the user experiences only a brief interruption when traversing the XR universe. Various aspects of the animation and functionality of the virtual door can help maintain user immersion, for example, by presenting a loading screen, by placing the user in an environment that obscures the loading, and / or using strategic user experience design elements (e.g., waiting rooms, elevators, twist animations, etc.).

[0053] In some cases, a user may access the XR universe within a local application of a computing device (e.g., a laptop or an XR head-mounted viewer). The XR application may be executed locally within a containerized environment (e.g., operating system (OS) level virtualization) and / or within a virtual machine. Regardless of the execution environment, the XR universe traversal system may facilitate conversion and / or communication between XR applications that interact with different XR environments. For example, the XR universe traversal system may launch an XR application in the background (e.g., execute a script, launch a container, etc.) and prepare the user's avatar in the destination XR universe while the user remains in the original XR universe. If the user does not have the necessary XR application for the destination XR universe installed on their device, the XR universe traversal system may download and install the application of the destination XR universe in the background, which may be beneficial when the user wishes to explore a new universe. Once the destination XR universe application is ready and the user's avatar in the destination XR universe is positioned at the corresponding virtual door, the XR universe traversal system may cause the user's device to switch applications, giving the user the effect of "jumping" to the new universe.

[0054] In some embodiments, the XR universe application may implement a framework and / or interface with external services or plug-ins for instantiating applications and / or web browsers within the XR universe. Within the operating system, an embedded application or browser may be executed on a separate thread, browser, or container that runs in parallel with the current XR universe application. The XR universe traversal system may utilize such a runtime environment to launch XR applications of different XR universes, which may be visible and accessible to users within the current XR universe. Some embodiments may use one or more inter-process communication (IPC) methods (e.g., WebSocket, Web Real-Time Communication (WebRTC), remote procedure call (RPC), messaging queues, etc.) to stream information between the current XR universe application and other XR universe applications, such as the user's avatar position and orientation, the position and orientation of the virtual camera, user credentials or identity, and / or other information. By combining an embedded browser or application with IPC, a virtual window to another XR universe can be synthesized in the current XR universe application, giving the user the feeling that they are walking from one universe into another when they enter through the virtual door connecting the two universes.

[0055] If the current XR universe application is executing as a web application in a web browser, a virtual door to an XR universe accessible to other web applications can be implemented as a browser session "inside" the current web application. In some embodiments, the XR universe traversal system launches a second browser in the background, instructs the second browser to open to another XR universe web application, and causes the current XR universe to graphically render a portion of the second browser as a virtual door or portal overlaid or synthesized within the current XR universe. If the user moves their avatar through the virtual door or portal, the XR universe traversal system can change the context to the second browser session while keeping the first browser session running in the background. IPC between browser sessions can help transmit information about the position and orientation of the avatar within one XR world to another XR world, allowing the two sessions to operate in parallel as if the two XR web applications were a single application.

[0056] In the event that the user's device does not have sufficient computing power to run multiple XR Universe applications simultaneously, an external server can be used to launch a separate XR Universe application and stream a portion of its content to an object within the current XR Universe (e.g., by performing server-side rendering, receiving input controls from the user's device, and transmitting audio and video to the user's device).

[0057] In various embodiments, the XR universe traversal system may implement tools that allow users to manage virtual doors linked to their virtual property and / or to various destinations in the metaverse. For example, (e.g., if the user is designing a new feature on their property, if the user is designing an art gallery and wants to prevent others from seeing him before it is completed, if the user is having a private meeting at their property and does not want any additional guests to appear, etc.) the user may want to manually lock all entrance doors at their property for a period of time. As another example, the user may want to add or remove specific users from the allowed list and / or blocked list (e.g., all doors, some doors, or specific doors). In an embodiment where door keys can be made and these door keys can be distributed to others, the user may want to make new keys, revoke existing keys, or otherwise view the keys of each virtual door leading to their property that was previously created. In some embodiments, the XR universe traversal system may implement tools that allow XR world owners to manage creation policies, access policies, and / or privacy preferences, which define how users who access their worlds can create and access virtual doors within their worlds. For example, a user may want to manage permissions that allow other users to create new doors leading to the user's property. The XR Universe Traversal System may provide a UI that allows the user to manage these different access control settings and / or permissions for their virtual doors (e.g., see Fig.12 ).

[0058] As described herein, the term "XR universe" generally refers to an XR application, environment, or platform consisting of one or more virtual worlds, in which multiple users can explore, meet, and interact with other users, objects, and artifacts supported by the same application service. Typically, an XR universe can define a set of primitives and / or rules that define user identity and ownership of virtual assets, XR world physics, and other mechanisms. In addition, an XR universe typically represents an environment with a predetermined level of fidelity and artistic style. Some XR universes can retrieve digital assets, such as virtual buildings, artworks (e.g., images, videos, non-fungible tokens (NFTs), etc.), web content. In addition, the XR universe can be interfaced with centralized financial systems and / or decentralized financial systems to enable an intra-universe economy. Users can be represented by avatars in the XR universe, which allow them to interact with other users and provide player characters to navigate the XR universe. One or more XR worlds may be created and operated within an XR universe, where each XR world is managed by one or more users and / or entities ("owners"). The XR universe may be accessed through a two-dimensional (2D) interface (e.g., a web browser on a computer, an application on a mobile device, etc.) and / or an XR interface (e.g., a head-mounted XR display), depending on the particular application.

[0059] As used herein, the term "XR world" generally refers to a virtual space within an XR universe where a user, a group of users, and / or an entity ("owner") can build and maintain a virtual land that can be accessed by other users accessing the XR world. In some embodiments, a user can traverse between XR worlds within the same XR universe without leaving a particular XR application or web application.

[0060] As described herein, the term "XR experience" generally refers to an XR world associated with a particular game, activity, or viewing experience. In some cases, an XR experience may be a game that can be interacted with an XR input device (e.g., a head-mounted viewer, a controller, etc.), and in some instances may allow multiple users to participate simultaneously. As a specific example, an XR experience may be a music-based game in which users swing virtual objects in sync with the music to hit targets. Accessing some XR experiences may involve launching an application specific to that XR experience on the user's device.

[0061] As described herein, the term "metaverse" may describe a superset of all virtual spaces, XR worlds, XR experiences, and / or XR universes in which users (e.g., represented by avatars) can interact with virtual environments, virtual objects, and each other. A metaverse may include multiple metaverses, each hosted by one organization or multiple different organizations, and a metaverse may be the top level of a conceptual hierarchy of metaspaces. Although it is contemplated that a host server may host multiple XR universes, it is also contemplated that multiple host servers may host a single XR universe.

[0062] Embodiments of the disclosed technology may include an artificial reality system, or may be implemented in conjunction with an artificial reality system. Artificial reality or extra reality (XR) is a form of reality that has been adjusted in some way before being presented to a user. Artificial reality or extra reality may include, for example, virtual reality (VR), augmented reality (AR), mixed reality (MR), hybrid reality, or some combination and / or derivative thereof. Artificial reality content may include fully generated content, or generated content combined with collected content (e.g., photos of the real world). Artificial reality content may include video, audio, tactile feedback, or some combination thereof, any of which may be presented in a single channel or multiple channels (e.g., stereoscopic video that produces a three-dimensional effect to the viewer). In addition, in some embodiments, artificial reality may be associated with an application, product, accessory, service, or some combination thereof, which is used, for example, to create content in artificial reality, and / or for artificial reality (e.g., performing activities in artificial reality). Artificial reality systems that provide artificial reality content can be implemented on a variety of platforms, including a head-mounted display (HMD) connected to a host computer system, a standalone HMD, a mobile device or computing system, a "cave-like" environment or other projection system, or any other hardware platform capable of providing artificial reality content to one or more viewers.

[0063] As used herein, "virtual reality" or "VR" refers to an immersive experience in which a user's visual input is controlled by a computing system. "Augmented reality" or "AR" refers to a system in which a user views images of the real world after they have passed through a computing system. For example, a tablet with a camera on the back can capture multiple images of the real world, which can then be displayed on a screen on the side of the tablet opposite the camera. The tablet can process and adjust or "enhance" the images as they pass through the system, such as by adding virtual objects. "Mixed reality" or "MR" refers to a system in which the light entering the user's eyes is partially generated by a computing system and partially consists of light reflected from objects in the real world. For example, an MR head-mounted viewer can be formed as a pair of glasses with a pass-through display that allows light from the real world to pass through a waveguide that simultaneously emits light from a projector in the MR head-mounted viewer, thereby allowing the MR head-mounted viewer to present virtual objects mixed with real objects that the user can see. As used herein, “artificial reality,” “hyperreality,” or “XR” refers to any of VR, AR, MR, or any combination or mixture thereof.

[0064] Existing XR universe traversal systems have many obvious shortcomings. For example, intra-universe XR teleportation can be achieved by placing a virtual object at a specific location, and when interacting with the virtual object, causing the user's avatar to perform a one-way teleportation to a different fixed location in the XR universe. Typically, the system requires the user to encode a fixed coordinate or address in the XR universe to an arbitrary object, and attach a teleportation "link" to an object that represents its function in a visual and / or textual form (e.g., "teleport to TOWM SQUARE"). If the user wants to return to their previous location, a corresponding "teleportation back" object must be created at the destination. This teleportation is usually unrestricted, allowing any user to travel quickly between teleportation nodes. Regarding inter-universe XR teleportation, users usually have to exit the current XR universe application, open a different XR universe application, log in to the different XR universe, and navigate to their desired destination in the XR universe.

[0065] Embodiments of the present application address these and other problems by providing a system for generating virtual doors that control access to a user's virtual property and enable rapid intra-universe, inter-universe, and / or inter-XR experience travel. While existing intra-universe teleportation allows any user to navigate between fixed locations within an XR universe, the virtual doors described herein can be used to provide rapid travel to and from a user's virtual property when the user (e.g., manually locked or unlocked by the user at a specific time, by the holder of a door key made by the user, etc.) allows travel to and from the user's virtual property. In addition, the virtual door can be configured to travel between XR universes and / or between XR experiences by utilizing interoperable interfaces of various XR universes (e.g., inter-process communication, callback URLs, APIs, etc.) to enable rapid conversion between XR applications - thereby allowing users to travel between XR universes without leaving the XR application, and / or automatically execute (and in some cases automatically obtain) an alternative XR application to obtain another XR experience. In some embodiments, a virtual door can be instantiated at a destination location, which allows users to quickly return to their original location.

[0066] By providing fast and convenient XR universe traversal, users can more easily access their friends' virtual properties, travel to popular destinations, and explore the virtual reality in the context of the virtual reality (i.e., without having to leave the virtual reality and navigate to different web pages or launch different applications). It is worth noting that the XR universe traversal system disclosed herein can help keep users on a specific XR universe as their "home base", thereby allowing users to access other XR universes while encouraging these users to operate primarily outside the "home" XR universe. Therefore, when users want to obtain items in a new universe and build their virtual properties, users are encouraged to spend virtual currency in the home XR universe, which makes it easier to enter other XR universes for virtual reality exploration than other XR universes with traditional XR universe traversal systems. In addition, the embodiments described herein overcome the existing defects of the above-mentioned XR universe traversal methods, and provide a technical solution rooted in XR universe access control and traversal between XR universes through computer networks for different devices and platforms.

[0067] Several embodiments are discussed in more detail below with reference to the accompanying drawings. Figure 11 is a block diagram showing an overview of various devices on which some embodiments of the disclosed technology may run. These devices may include hardware components of a computing system 100 that provide virtual doors within an artificial reality (XR) universe for traversing within the XR universe and between other XR universes. In various embodiments, the computing system 100 may include a single computing device 103 or multiple computing devices (e.g., computing device 101, computing device 102, and computing device 103) that communicate via a wired channel or a wireless channel to distribute processing and share input data. In some embodiments, the computing system 100 may include a standalone head-mounted viewer that is capable of providing a computer-created or enhanced experience to a user without the need for external processing or sensors. In other embodiments, the computing system 100 may include multiple computing devices, such as a head-mounted viewer and a core processing component (e.g., a console, a mobile device, or a server system), wherein some processing operations are performed on the head-mounted viewer and other processing operations are offloaded to the core processing component. The following is combined with Figure 2A and Figure 2B In some implementations, the location data and environmental data may be collected solely by sensors integrated into the head mounted device, while in other implementations, one or more non-head mounted device computing devices may include sensor components that may track environmental data or location data.

[0068] The computing system 100 may include one or more processors 110 (e.g., a central processing unit (CPU), a graphical processing unit (GPU), a holographic processing unit (HPU), etc.). The processor 110 may be a single processing unit or multiple processing units, which are located in one device or distributed in multiple devices (e.g., distributed in two or more computing devices among the computing devices 101 to 103).

[0069] The computing system 100 may include one or more input devices 120 that provide input to the processors 110, thereby informing the processors of actions. These actions may be transmitted by a hardware controller that interprets the signals received from the input devices and transmits the information to the processor 110 using a communication protocol. Each input device 120 may include, for example, a mouse, a keyboard, a touch screen, a touchpad, a wearable input device (e.g., a tactile glove, a bracelet, a ring, an earring, a necklace, a watch, etc.), a camera (or other light-based input device, such as an infrared sensor), a microphone, or other user input device.

[0070] The processor 110 can be coupled to other hardware devices, for example, by using an internal bus or an external bus or a wireless connection, such as a peripheral component interconnect standard (PCI) bus, a small computer system interface (SCSI) bus. The processor 110 can communicate with a hardware controller of a device (e.g., a display 130). The display 130 can be used to display text and graphics. In some embodiments, the display 130 includes an input device, such as when the input device is a touch screen or the input device is equipped with an eye movement direction monitoring system, the input device is part of the display. In some embodiments, the display is separated from the input device. Examples of display devices include: a liquid crystal display (LCD) display screen; a light emitting diode (LED) display screen; a projection, holographic, or augmented reality display (e.g., a head-up display device or a head-mounted device), etc. Other input / output (I / O) devices 140 may also be coupled to the processor, such as a network chip or card, a video chip or card, an audio chip or card, a universal serial bus (USB), FireWire or other external devices, a camera, a printer, a speaker, a compact disc read-only memory (CD-ROM) drive, a digital video disc (DVD) drive, a disk drive, etc.

[0071] In some embodiments, input from I / O devices 140 (e.g., cameras, depth sensors, inertial motion unit (IMU) sensors, GPS units, LiDAR or other time-of-flight sensors, etc.) can be used by the computing system 100 to identify and map the user's physical environment while tracking the user's position within the environment. This simultaneous localization and mapping (SLAM) system can generate a map (e.g., topology, grid, etc.) for an area (which can be a room, building, outdoor space, etc.), and / or obtain a map previously generated by the computing system 100 or another computing system that has mapped the area. The SLAM system can track users within the area based on factors such as GPS data, match identified objects and structures with mapped objects and structures, monitor acceleration and other position changes, etc.

[0072] The computing system 100 may include a communication device capable of wireless or wire-based communication with other local computing devices or network nodes. The communication device may communicate with another device or server over a network using, for example, the Transmission Control Protocol / Internet Protocol (TCP / IP). The computing system 100 may utilize the communication device to distribute operations among multiple network devices.

[0073] The processor 110 can access the memory 150, which can be included in one of the multiple computing devices of the computing system 100, or can be distributed on multiple computing devices of the computing system 100, or multiple other external devices. The memory includes one or more hardware devices for volatile storage or non-volatile storage, and can include both read-only memory and writable memory. For example, the memory may include one or more of the following: random access memory (RAM), various cache memories, CPU registers, read-only memory (ROM), and writable non-volatile memory, such as flash memory, hard drive, floppy disk, compact disk (CD), DVD, magnetic storage device, tape drive, etc. The memory is not a propagation signal separated from the underlying hardware; therefore, the memory is non-transient. The memory 150 may include a program memory 160 for storing programs and software, such as an operating system 162, an XR universe traversal system 164, and other applications 166. The memory 150 may also include a data memory 170, which may include, for example, virtual addresses, virtual door metadata, virtual keys, virtual key metadata, user privacy preferences, intra-universe traversal libraries, inter-universe traversal libraries, XR application container configurations, user allow lists, user block lists, configuration data, settings, user options or preferences, etc., which may be provided to the program memory 160 or any element of the computing system 100.

[0074] Some embodiments may operate with many other computing system environments or configurations. Examples of computing systems, environments, and / or configurations that may be suitable for use with the present technology include, but are not limited to, XR headsets, personal computers, server computers, handheld or laptop devices, cellular phones, wearable electronic devices, game consoles, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronic devices, networked personal computers (PCs), minicomputers, mainframe computers, or distributed computing environments that include any of the above systems or devices, etc.

[0075] Figure 2A2 is a line diagram of a virtual reality head mounted display (HMD) 200 according to some embodiments. HMD 200 includes a front rigid body 205 and a band 210. Front rigid body 205 includes one or more electronic display elements of an electronic display 245, an inertial motion unit (IMU) 215, one or more position sensors 220, a plurality of locators 225, and one or more computing units 230. Position sensors 220, IMU 215, and computing units 230 may be located inside HMD 200 and may not be visible to the user. In various embodiments, IMU 215, position sensors 220, and locators 225 may track the movement and position of HMD 200 in the real world and artificial reality environments with three degrees of freedom (3DoF) or six degrees of freedom (6DoF). For example, locators 225 may emit infrared beams that produce light spots on real objects around HMD 200. As another example, the IMU 215 may include, for example: one or more accelerometers; one or more gyroscopes; one or more magnetometers; other non-camera-based position, force, or orientation sensors; or a combination thereof. One or more cameras (not shown) integrated with the HMD 200 may detect light points. The computing unit 230 in the HMD 200 may use the detected light points to infer the position and movement of the HMD 200, and to recognize the shape and position of real objects around the HMD 200.

[0076] The electronic display 245 can be integrated with the front rigid body 205 and can provide image light to the user as directed by the computing unit 230. In various embodiments, the electronic display 245 can be a single electronic display or multiple electronic displays (e.g., one display for each eye of the user). Examples of the electronic display 245 include: a liquid crystal display (LCD), an organic light-emitting diode (OLED) display, an active-matrix organic light-emitting diode display (AMOLED), a display including one or more quantum dot light-emitting diode (QOLED) sub-pixels, a projector unit (e.g., micro-LED, laser (LASER)), some other display, or some combination thereof.

[0077] In some embodiments, the HMD 200 can be coupled to a core processing component such as a personal computer (PC) (not shown) and / or one or more external sensors (not shown). The external sensors can monitor the HMD 200 (e.g., through light emitted from the HMD 200), and the PC can use the HMD in conjunction with the outputs from the IMU 215 and the position sensor 220 to determine the position and movement of the HMD 200.

[0078] Figure 2B 25 is a line diagram of a mixed reality HMD system 250, which includes a mixed reality HMD 252 and a core processing component 254. The mixed reality HMD 252 and the core processing component 254 can communicate via a wireless connection (e.g., a 60 GHz link) as indicated by link 256. In other embodiments, the mixed reality system 250 includes only a head-mounted viewer without an external computing device, or includes other wired or wireless connections between the mixed reality HMD 252 and the core processing component 254. The mixed reality HMD 252 includes a transparent display 258 and a frame 260. The frame 260 can accommodate various electronic components (not shown), such as light projectors (e.g., lasers, LEDs, etc.), cameras, eye tracking sensors, micro-electromechanical systems (MEMS) components, network components, etc.

[0079] The projector can be coupled to a transparent display 258, for example, via an optical element, to display media to the user. The optical element can include one or more waveguide components, one or more reflectors, one or more lenses, one or more mirrors, one or more collimators, one or more gratings, etc. for directing light from the projector to the user's eyes. Image data can be transmitted from the core processing component 254 to the HMD 252 via a link 256. The controller in the HMD 252 can convert the image data into a plurality of light pulses from the projector, which can be transmitted to the user's eyes as output light via an optical element. The output light can be mixed with the light passing through the display 258, allowing the output light to present the following virtual objects: these virtual objects appear to exist in the real world.

[0080] Similar to the HMD 200, the HMD system 250 may also include motion and position tracking units, cameras, light sources, etc., which allow the HMD system 250 to track itself, for example, with 3DoF or 6DoF, track various parts of the user (e.g., hands, feet, head, or other body parts), draw virtual objects to appear stationary when the HMD 252 moves, and make virtual objects react to gestures and other real-world objects.

[0081] Figure 2C A plurality of controllers 270 are shown (including controllers 276A and 276B), which in some embodiments can be held by a user with one or both hands to interact with the artificial reality environment presented by the HMD 200 and / or HMD 250. The controllers 270 can communicate directly with the HMD, or can communicate with the HMD via an external device (e.g., the core processing component 254). The controllers can have their own IMU units, position sensors, and / or can emit additional light points. The HMD 200 or HMD 250, external sensors, or sensors in the controllers can track these controller light points to determine the controller position and / or orientation (e.g., to track the controllers with 3DoF or 6DoF). The computing unit 230 or the core processing component 254 in the HMD 200 can combine the IMU output and the position output and use this tracking to monitor the user's hand position and movement. The controllers may also include various buttons (eg, buttons 272A-272F) and / or levers (eg, levers 274A and 274B) that a user may actuate to provide input and interact with objects.

[0082] In various embodiments, HMD 200 or HMD 250 may also include a number of additional subsystems to monitor indications of user interaction and intent, such as an eye tracking unit, an audio system, various network components, etc. For example, in some embodiments, instead of or in addition to a controller, one or more cameras included in HMD 200 or HMD 250, or one or more cameras from a plurality of external cameras, may monitor the position and posture of a user's hands to determine gestures and other hand and body movements. As another example, one or more light sources may illuminate either or both of a user's eyes, and HMD 200 or HMD 250 may use eye-facing cameras to capture reflections of that light to determine eye position (e.g., based on a set of reflections around the user's corneas) to model the user's eyes and determine gaze direction.

[0083] Figure 3305B may be an HMD 200 or an HMD system 250. The client computing device 305 may be a logical connection to one or more remote computers (e.g., a server computing device) through a network 330.

[0084] In some implementations, server 310 may be an edge server that receives multiple client requests and coordinates the fulfillment of these requests through other servers (e.g., servers 320A to 320C). Server computing devices 310 and 320 may include computing systems, such as computing system 100. Although each server computing device 310 and 320 is logically shown as a single server, the multiple server computing devices may each be a distributed computing environment that includes multiple computing devices located at the same physical location or at geographically different physical locations.

[0085] The client computing device 305 and the server computing devices 310 and 320 can each act as a server or client for one or more other server / client devices. The server 310 can be connected to a database 315. The servers 320A to 320C can each be connected to corresponding databases 325A to 325C. As described above, each server 310 or 320 can correspond to a group of servers, and each of these servers can share a database or can have its own database. Although the databases 315 and 325 are logically shown as a single unit, the databases 315 and 325 can each be a distributed computing environment containing multiple computing devices, which can be located in its corresponding server, or can be located at the same physical location or geographically different physical locations.

[0086] Network 330 may be a local area network (LAN), a wide area network (WAN), a mesh network, a hybrid network, or other wired or wireless network. Network 330 may be the Internet or some other public or private network. Client computing device 305 may be connected to network 330 via a network interface, for example, by wired or wireless communication. Although the connections between server 310 and server 320 are shown as separate connections, these connections may be any type of local area network, wide area network, wired or wireless network including network 330 or a separate public or private network.

[0087] Figure 4 4 is a block diagram showing a plurality of components 400 that can be used in a system that employs the disclosed technology in some embodiments. The plurality of components 400 can be included in one device of the computing system 100, or can be distributed across multiple devices in the computing system 100. These components 400 include a plurality of hardware 410, middleware 420, and a plurality of dedicated components 430. As described above, the system implementing the disclosed technology can use various hardware, including a processing unit 412, a working memory 414, input and output devices 416 (e.g., a camera, a display, an IMU unit, a network connection, etc.), and a storage memory 418. In various embodiments, the storage memory 418 can be one or more of the following: a local device, an interface to a remote storage device, or a combination thereof. For example, the storage memory 418 can be one or more hard drives or flash drives accessible via a system bus, or can be a cloud storage provider (e.g., in a storage device 315 or 325) or other network storage device accessible via one or more communication networks. In various implementations, component 400 may be implemented in a client computing device (eg, client computing device 305 ), or on a server computing device (eg, server computing devices 310 or 320 ).

[0088] The middleware 420 may include components that transfer resources between the hardware 410 and the plurality of specialized components 430. For example, the middleware 420 may include an operating system, a service system, a driver, a basic input output system (BIOS), a controller circuit, or other hardware or software systems.

[0089] The dedicated components 430 may include software or hardware configured to perform the following operations: provide a virtual door within the XR universe to traverse within the XR universe and between other XR universes. The multiple dedicated components 430 may include a virtual door creator 434; a door key maker 436; a door access control manager 438; an intra-universe traversal function 440; an inter-universe traversal function 442; an XR universe application environment 444; an XR universe application hypervisor 446; user privacy preferences 448; and multiple components and APIs (e.g., interfaces 432) that can be used to provide a user interface, transfer data, and control the dedicated components. In some embodiments, the component 400 may be located in a computing system distributed across multiple computing devices, or may be an interface to a server-based application that executes one or more of the multiple dedicated components 430. Although the multiple dedicated components 430 are depicted as separate components, these dedicated components may be logical functions or other non-physically distinguished functions, and / or may be sub-modules or code blocks of one or more applications.

[0090] The virtual door creator 434 can interface with one or more XR universe applications to facilitate the creation and operation of a virtual door connecting two locations in the same XR universe and / or a virtual door connecting two locations in different XR universes. Each XR universe can implement its own HTTP URL pattern, RPC protocol, API, and / or other programmatic access to request the creation, access, modification, or deletion of assets within the XR universe. The virtual door creator 434 can provide a common interface that converts common commands (e.g., a request to create a virtual door A at location A in universe A that links to virtual door B at location B in universe B) into corresponding function calls to the relevant XR universe server to effectively create a bridge or portal connecting two locations in the virtual reality. In some embodiments, the virtual door creator 434 can also provide middleware to resolve requests that jump across XR worlds or XR universes, thereby enhancing interoperability between XR universes without having to comply with any specific standards or protocols.

[0091] In some embodiments, the virtual door creator 434 may provide graphical assets rendered within the XR universe. For example, the virtual door creator 434 may be configured to generate graphical representations of the same or similar doors in different XR universes—thereby providing a consistent design language across potentially different styles of XR universes and enabling users to intuitively identify doors or portals that enter different XR universes or return to the original XR universe. The virtual door creator 434 may use graphics compositing techniques to overlay, composite, or otherwise superimpose virtual doors into an XR universe (server-side or client-side), such that the same or similar techniques may be used to render virtual doors in various XR universes without having to create and store new assets for each XR universe.

[0092] The virtual door creator 434 can be coupled with various dedicated components 430 to facilitate the creation and use of virtual doors. For example, the virtual door creator 434 can be coupled with a door key maker 436 to request the creation or manufacture of a new virtual door key when requested by a user. The virtual door creator 434 can be coupled with an intra-universe traversal function 440 and an inter-universe traversal function 442 to determine one or more operations to be performed to allow a user to traverse from one location in a virtual reality to another location. In some embodiments, the virtual door creator 434 can be operated as a service within a web browser or on an operating system and communicate with the XR universe application via an XR universe application environment 444 and / or an XR universe application manager 446. In addition, the virtual door creator 434 can be coupled with a user privacy preference 448 when creating a new virtual door to determine the initial privacy configuration of the virtual door, which initial privacy configurations can then be stored as metadata associated with the virtual door and accessed by the door access control manager 438 when determining whether to authorize a specific user to access the virtual door.

[0093] The door key maker 436 can create, generate, or cause the manufacture and / or issuance of a new key that provides access to a virtual door. In some embodiments, the door key maker 436 can be a function of the XR universe or an external service hosted in a central server that generates ownership of door keys and assigns the ownership to XR universe users. The door key maker 436 can centrally manage the generated keys, the owners of these keys, and the permissions associated with these keys. The door key maker 436 can provide an API or other programming interface to allow the virtual door creator 434 to request the creation of new keys and / or store metadata about each key.

[0094] In some embodiments, the door key maker 436 can interface with the blockchain to create cryptographically verified, NFT-based door keys - each of which can be configured to be redistributable or sellable or non-distributable depending on the specific application. For example, the door key maker 436 can operate as a smart contract-based decentralized application ("dAPP") that can receive information about the virtual door (e.g., identification, metadata, etc.), the owner of the virtual door, and the recipient of the key, and then manufacture an NFT that is permanently linked to a document containing metadata about the door key (e.g., on a peer-to-peer blockchain-based distributed file system) and transmit the NFT to the recipient's cryptocurrency wallet address.

[0095] The door access control manager 438 may determine whether a user's attempt to access a virtual door is authorized and / or permitted. For example, the door access control manager 438 may interface with the user privacy preferences 448 to determine whether a virtual door leading to the owner's virtual property is unlocked or locked (e.g., the owner's manual lock setting) (based on a schedule that defines when the door is locked or unlocked, based on the owner's allow list and / or block list, etc.). The door access control manager 438 may also facilitate communications with the user to obtain their permission to allow other users to access one or more of their virtual doors. For example, an owner may place a virtual door on their property that is locked by default, but allow others to access the user's property if the owner explicitly grants a request to access the door (e.g., if a user wants to create a gateway to their property that is effectively locked by default, but can be unlocked for a particular user upon request).

[0096] In some cases, one user may wish to create a dedicated virtual door that links to another user's private virtual property. Door access control manager 438 may process authorization requests from virtual property owners to add new virtual doors on their properties. For example, if two people meet in a virtual reality and become friends, they may wish to create a virtual door connecting their properties so that they can quickly and easily visit each other. If one of these users requests to create a new virtual door between their property and their friend's property, door access control manager 438 may request authorization from the friend to create a new virtual door on the friend's property.

[0097] In general, the virtual door creator 434, the door key maker 436, and the door access control manager 438 may function as a virtual door controller that facilitates the creation and access of virtual doors. As used herein, the term "virtual door controller" may refer to any application or service that executes locally or on a server and provides an interoperable virtual door system for connecting different locations within a virtual reality.

[0098] The intra-universe traversal functionality 440 may be any SDK, API, RPC, or other programming interface that can be used to quickly move a user's avatar from one location within the XR universe to another. For example, some XR universes may provide intra-universe traversal functionality in the form of a URL or URI pattern that defines a semantically meaningful hierarchy of locations or coordinates within the XR universe. As another example, the XR universe may provide a REST API that allows a user to issue an HTTP GET or HTTP POST request to traverse between locations within the XR universe. In some cases, the XR universe application may provide in-app tools that simplify access to such APIs or SDKs.

[0099] The inter-universe traversal function 442 can be any SDK, API, or programming interface that can trigger a transition whereby the user exits the current XR universe and enters a different XR universe. For example, the inter-universe traversal function 442 may include parameterized functions (e.g., intra-universe traversal function 440) that can convert or transform generic requests to travel to different XR universes into XR universe-specific function calls. In addition, the inter-universe traversal function 442 can call in-browser or OS-level operations to create a new browser window, launch a container or virtual machine, and / or launch an application. For example, the inter-universe traversal function 442 can access an application library and a known path to an application binary, launch a new browser and go to a specific URL, launch a virtual machine or container, or otherwise interact with the environment that executes the XR application on a specific computing device.

[0100] The XR universe application environment 444 can be any runtime environment in which the XR universe application is executed, such as a browser. The XR universe application environment 444 may also include plug-ins, libraries, service systems, and / or other assets that facilitate graphics rendering, interfaces with input devices (e.g., VR head-mounted viewer, controller, mouse, keyboard, etc.), and / or may otherwise help provide a runtime environment for XR applications. In some embodiments, the XR universe application environment 444 can provide a substantially standardized interface between a peripheral device or input device and one or more XR applications, so that the same peripheral device or input device can be used as an input end for two or more XR applications at the same time.

[0101] The XR universe application environment 444 may provide a canvas, graphics layer, and / or framework for rendering 2D graphics or 3D graphics to a display (e.g., Web Graphics Library (WebGL)), which allows one or more applications to render graphical assets, 2D objects, and / or 3D objects to the display. For example, one application may access the document object model (DOM) of a browser to render a 3D environment that is part of an XR universe, while another application modifies the DOM and / or renders additional objects within the same canvas, effectively allowing the second application to perform masking, blending, and / or composite rendering of additional assets or objects. Thus, the XR universe application environment 444 may provide a framework and / or API that enables a virtual door controller to render a virtual door within the XR universe from the user's perspective, where the virtual door is potentially rendered on the client side by an application separate from the XR universe application.

[0102] The XR universe application manager 446 can be any OS-level application runtime environment in which the XR universe application is executed, such as a shell, a container execution engine, a virtual machine, and / or other runtime environment. The XR universe application manager 446 can provide similar functionality to the XR universe application environment 444, but may involve executing applications locally or within a container rather than within a web browser. The XR universe application manager 446 can start and stop the execution of different XR applications and enable IPC between multiple XR applications (e.g., through message queues, message protocols, etc.). In some embodiments, the XR universe application manager 446 can execute services that implement various aspects of a virtual gate controller on a device, such as an application that communicates with a virtual gate controller service running on a server over the Internet.

[0103] User privacy preferences 448 may include data storage for an API that manages user virtual door permissions and privacy preferences. In some embodiments, the XR universe application may interface with user privacy preferences 448 to provide users with tools or UIs to manage their privacy preferences, particularly as they relate to virtual doors within and between XR universes. Fig.12 An example UI rendered in an XR environment that enables a user to manage their virtual door privacy preferences is shown. Example privacy preferences may include: providing, configuring, and removing door keys; updating allow lists and block lists; locking and / or unlocking a door; configuring default privacy settings; and / or configuring a door lock schedule to allow access to a user-owned virtual door only during certain times of the day.

[0104] Those skilled in the art will appreciate that the above Figures 1 to 4 The components shown in the flowcharts and in each of the flowcharts discussed below may be changed in various ways. For example, the order of the logic may be rearranged, sub-steps may be performed in parallel, the logic shown may be omitted, other logic may be included, etc. In some embodiments, one or more of the above-mentioned multiple components may perform one or more of the multiple processes described below.

[0105] Figure 5 is a flow chart illustrating a process 500 for creating a virtual door between two locations in an XR universe in some embodiments. In some embodiments, process 500 may be performed in response to a user request to create a new virtual door. Figure 1The XR universe traversal system 164 performs process 500 on a server (e.g., a host server described herein) or a combination of multiple servers over a network, or performs process 500 locally on a user system or device (i.e., an XR device (e.g., a head-mounted display) or a 2D device (e.g., a computer or other display or processing device)). In some embodiments, some steps of process 500 can be performed on a server, while other steps of process 500 can be performed locally on a user device. Although process 500 is shown as having only one iteration, it is contemplated that process 500 can be performed multiple times, repeatedly, continuously, simultaneously, in parallel, etc. when a request to create a virtual door is received from one or more user devices or when a request to create a virtual door is received at one or more user devices. Some steps of process 500 may describe changes to various aspects of the XR universe, such as instantiating or removing objects within the environment, moving user avatars in the environment, etc., which can be performed on the client side within the XR application or on the server side within the XR universe server.

[0106] At block 502, process 500 receives a request from a user to create a virtual door between a first XR world and a second XR world. In various embodiments, the first XR world and the second XR world are within the same XR universe, but are created and maintained by different owners. In other embodiments, the first XR world is a world within the first XR universe, and the second XR world is a world within the second XR universe—where the first XR universe and the second XR universe may be hosted by different entities. In some cases, the first XR world is a world within the XR universe, and the second XR world is hosted by a different XR experience (e.g., an XR game, an XR movie, etc. that is not controlled by the first XR world).

[0107] In this example, a user (e.g., a visitor to an XR world) sends a request to a virtual door controller. For example, a user visiting an XR world may invoke an in-game or in-app menu and select an option to create a new virtual door within the world. The request may include some combination of: metadata about the user making the request; metadata about the first XR world and the second XR world (e.g., tags, content type, age restrictions, categories, one or more ratings, the XR universe containing each XR world, one or more owners or one or more operators of the respective XR worlds, etc.); and / or other details that may be used by the virtual door controller to process the request.

[0108] At block 504, the process 500 obtains one or more rules that define any privacy preferences, creation policies, and / or any other restrictions on the creation of virtual doors by users accessing the first XR world. For example, the owner of the first XR world may provide age-appropriate content for children within the world, and accordingly may define a rule that prevents the creation of virtual doors that link to XR worlds or XR experiences that contain adult content or are rated as exceeding a threshold age limit. As another example, the owner of the first XR world may define a rule that only allows the creation of virtual doors to other XR worlds that share one or more common characteristics (e.g., categories, content types, tags, themes, or other criteria that define the characteristics of an XR world). In some cases, the owner of the first XR world may maintain a user allow list that explicitly allows specific users to create virtual doors while denying users who are not on the allow list from creating virtual doors. Similarly, the owner of the first XR world may maintain a user block list that explicitly denies specific users from creating virtual doors while allowing users who are not on the block list to create virtual doors. The creation policy may also restrict the creation of new virtual doors to XR worlds that meet or exceed a threshold rating, such that virtual doors within a first XR world only link to other highly rated XR worlds. In some implementations, the owner of the first XR world may specify rules that require the owner's explicit approval of the creation of new virtual doors within the first XR world by other users, allowing the owner to also manually regulate links from their XR world to other XR worlds. These rules may be stored on a host server operating a virtual door controller and / or by an XR universe server hosting the first XR world.

[0109] At block 506, the process 500 determines whether the obtained one or more rules are satisfied based at least in part on the information contained in the request. For example, the request may include metadata about the second XR world (e.g., age ratings for content, tags, ratings, types or categories of content in the second XR world) and / or other information about the second XR world. The process 500 may compare the metadata associated with the second XR world with the one or more rules to determine whether the conditions of the one or more rules are satisfied. For example, if the rule requires that the second XR world have a rating above a minimum threshold rating, the process 500 may determine whether the rating of the second XR world exceeds the minimum threshold rating. If the one or more rules include a user allow list or a user block list, the process 500 may determine whether the user making the request is on the allow list or the block list, and accordingly determine whether the rule has been satisfied (e.g., the user making the request is included in the allow list or not in the block list). In the event that the one or more rules require the owner of the first XR world to explicitly consent to the creation of a new virtual door, block 506 may involve sending a request to the owner and receiving a response from the owner indicating that they approve or deny the request. If multiple rules are specified in the one or more rules, process 500 can determine whether each rule is satisfied, and if at least one of the multiple rules is violated, the one or more rules can be considered collectively unsatisfied. The operation of processing the request according to the one or more rules can be triggered by the request and automatically performed.

[0110] If process 500 determines that the one or more rules are not satisfied, process 500 proceeds to box 508. At box 508, process 500 removes or prevents the creation of a virtual door within the first XR world. In some embodiments, a graphical object representing an unapproved virtual door in the first XR world can be rendered in the XR environment of the user device. For example, an unapproved virtual door can be rendered as translucent or otherwise graphically indicated that the virtual door is not yet functional. In such an embodiment, the "pending" virtual door in the first XR world can be removed from the XR environment. Then, at box 510, process 500 can notify the user that the creation of a new virtual door was denied because the request failed to satisfy one or more rules, conditions, and / or criteria that restrict the creation of virtual doors within the first XR world.

[0111] Alternatively, if process 500 determines that the one or more rules have been satisfied (i.e., the request does not violate any of the one or more rules), process 500 proceeds to box 512. At box 512, process 500 can instantiate (or cause instantiation) a corresponding virtual door in the first XR world. In some embodiments, the XR universe of the first XR world can create a new asset representing the virtual door in the XR universe. In other embodiments, the virtual door controller can render the virtual door within the first XR world (e.g., as a graphical overlay or composite). In either case, the virtual door can become visible to the user from their respective perspectives, and the user's avatar can interact with the virtual door within one or more XR universes.

[0112] At block 514, process 500 may move the user's avatar from the first XR world to the second XR world through a virtual door. For example, a virtual door controller may receive a request from the user to pass through a virtual door, thereby triggering process 500 to move and / or instantiate the user's avatar in the second XR world. If the first XR world and the second XR world are located in the same XR universe, process 500 may update the position of the user's avatar within the XR universe. Alternatively, if the first XR world and the second XR world are located in different XR universes, process 500 may simulate the user's avatar passing through the virtual door by launching an application of the destination XR universe (if the universe is served by different applications on the user's artificial reality device); instantiating the user's avatar within the destination XR universe (e.g., using a different account, a different avatar, etc.); and switching the user's device from the current XR universe application to the destination XR universe application. Similarly, if the second XR world is an XR experience, process 500 may simulate the user passing through the virtual door by launching an application of the XR experience and switching the user's device from the XR universe application to the XR experience. Thus, process 500 may not necessarily "move" the same user avatar across different XR universes, but rather give the user the impression that their virtual presence is transferred from their current avatar at their current location in the current XR universe to a different avatar at a different location in a different XR universe. It will be appreciated that the phrase "moving the user's avatar" may be used to describe a process that gives the user the impression of traveling through a virtual reality even if the locations of the different avatars do not move between different XR universes.

[0113] refer to Fig. 9A , Fig. 9B , FIG. 10A to FIG. 10C and Fig.11Various techniques for implementing such inter-universe traversal are shown and described in more detail, and these techniques may differ slightly from those described above. For example, traversing from one XR universe to another XR universe may involve creating a browser within the XR universe, launching a web application within the browser to enter a different XR universe, and then "entering" the browser to experience the different XR universe rendered "within" the current XR universe.

[0114] In some embodiments, a corresponding virtual door that "links back" to a corresponding virtual door in the first XR world may be created in the second XR world. In other embodiments, the second XR world may not instantiate the virtual door as a graphical object within the XR environment, and the user may traverse back to the first XR world by selecting an option within a menu, speaking a voice command, and / or opening a control panel (e.g., an overlaid graphical UI provided by the virtual door control) while in the second XR world and selecting an option to return to the first XR world, as well as other possible return mechanisms. At box 516, the process 500 may move the user's avatar from the second XR world back to the first XR world through the virtual door. The virtual door may provide a two-way shortcut between the first XR world and the second XR world. In some embodiments, (e.g., if multiple users from different original XR worlds use the same virtual door of the second XR world) the virtual door controller may determine the second XR world based on the identity of the user. The virtual door controller may also store a record of each user's traversal, so that a user who "returns" through the virtual door at the destination traverses back to his previous location.

[0115] Figure 6 6 is a flow chart illustrating a process 600 for providing user-setup-based access control to a virtual door connecting two locations in an XR universe in some embodiments. In some embodiments, process 600 may be performed in response to a user request to create a new virtual door and / or a user attempting to access another virtual door. Figure 1The XR universe traversal system 164 performs process 600 on a server (e.g., a host server described herein) or a combination of multiple servers over a network, or performs process 600 locally on a user system or device (i.e., an XR device (e.g., a head-mounted display) or a 2D device (e.g., a computer or other display or processing device)). In some embodiments, some steps of process 600 can be performed on a server, while other steps of process 600 can be performed locally on a user device. Although process 600 is shown as having only one iteration, it is contemplated that process 600 can be performed multiple times, repeatedly, continuously, simultaneously, in parallel, etc. when a request to create a virtual door is received from or at one or more user devices. Some steps of process 600 can describe various aspects of changes to the XR universe, such as instantiating or removing objects within the environment, moving user avatars in the environment, etc., which can be performed on the client side within the XR application or on the server side within the XR universe server.

[0116] At block 602, process 600 receives a request from an owner to create a virtual door at a destination location (e.g., within the owner's virtual property). In this example, the owner may wish to create a virtual door to their property to grant other users access to their virtual property. The request may include some combination of: metadata about the user making the request; the destination location; the destination XR universe, and / or other details that may be used by a virtual door controller to process the request.

[0117] At block 604, process 600 may create a virtual door and publish the existence of the virtual door to an XR Universe door directory, database, or list. In some cases, the owner of a property may design their property and intend to grant other users access to the property, such as during an open house, celebration, or some other event. In other cases, the owner may wish to list the virtual door of their property with a directory to allow friends and / or other users to find the door (e.g., to create a virtual door or portal that links to the owner's virtual door). Process 600 may add the newly created virtual door to a searchable list, thereby encouraging others to discover or find their property.

[0118] At block 606, process 600 receives a request from the user to travel to a destination location using the owner's virtual door. Block 606 may be similar to the above referenced virtual door except that the destination virtual door has been created at block 604. Figure 5Described block 502. In this example, another user (e.g., friend, coworker, etc.) may want to create a virtual door at their property as a shortcut or portal to the owner's virtual property. In some embodiments, the user may be able to travel to the owner's virtual door without having to create a virtual door on their property (e.g., creating a temporary portal, simply quickly traveling / traversing to a virtual door such as a waypoint, etc.).

[0119] In this example, the owner may have configured privacy settings and / or permissions that define access control rules, allow lists, and / or block lists for the virtual door. Thus, users wishing to travel to the owner's virtual door and / or link a different virtual door to the owner's virtual door may have to satisfy the privacy settings, permissions, and / or authenticate themselves before the virtual door controller allows access to the owner's virtual door.

[0120] At block 608, the process 600 determines whether the virtual door is locked. In some embodiments, the virtual door may be manually locked or unlocked by the owner, which prevents the user from accessing and / or linking to the owner's virtual door. If the virtual door is locked, the process 600 proceeds to block 610. At block 610, the process 600 denies the request to use the owner's virtual door. In some embodiments, the process 600 may proceed to block 612 to notify the user that the virtual door cannot be accessed because it is locked by the owner. The content of the notification and the level of detail regarding the reason for the denial may vary in different embodiments.

[0121] However, if the virtual door is not locked, process 600 proceeds to block 614, where process 600 determines whether the owner permission criteria have been met. In some cases, the owner may choose to have their virtual door unlocked, but to explicitly deny other users access to the virtual door at certain times of the day, certain days of the year, to prevent specific users in a block list from accessing the door at any time, to only allow users with certain affiliations and / or reputations to enter the virtual door, and / or to deny other users access to the virtual door based on any other suitable criteria. If process 600 determines that the permission criteria are not met, process 600 proceeds to block 616, where process 600 denies the user's request to use the virtual door. Then, at block 618, process 600 may notify the user that they are not allowed to access the virtual door.

[0122] Alternatively, if the permissive criteria are met, process 600 proceeds to block 620 where process 600 moves the user's avatar to the destination location. Block 620 may be similar to the above referenced Figure 5 Block 516 is described similarly.

[0123] Figure 7is a flow chart illustrating a process 700 for providing key-based access control to a virtual door connecting two locations in an XR universe in some embodiments. In some embodiments, process 700 may be performed in response to a user request to create a new virtual door and / or a user attempting to access another virtual door. Figure 1 The XR universe traversal system 164 performs process 700 on a server (e.g., a host server described herein) or a combination of multiple servers over a network, or performs process 700 locally on a user system or device (i.e., an XR device (e.g., a head-mounted display) or a 2D device (e.g., a computer or other display or processing device)). In some embodiments, some steps of process 700 can be performed on a server, while other steps of process 700 can be performed locally on a user device. Although process 700 is shown as having only one iteration, it is contemplated that process 700 can be performed multiple times, repeatedly, continuously, simultaneously, in parallel, etc. when a request to create a virtual door is received from one or more user devices or when a request to create a virtual door is received at one or more user devices. Some steps of process 700 may describe various aspects of changes to the XR universe, such as instantiating or removing objects within the environment, moving user avatars in the environment, etc., which can be performed on the client side within the XR application or on the server side within the XR universe server.

[0124] At block 702, process 700 receives a request from an owner to create a virtual door at a destination location (e.g., within the owner's virtual property). Block 702 may be similar to the above referenced Figure 6 Block 602 is similar or identical to that described.

[0125] At block 704, process 700 receives a request from a virtual door owner to create a new door key for a user. In some embodiments, a virtual door controller may implement functionality for generating new keys (e.g., universally unique identifiers (UUIDs), unique hash codes, keys encrypted using an encryption process (e.g., RSA), etc.), which may be stored in a memory or data storage device and maintained by the virtual door controller. Such keys may be maintained by the virtual door controller and associated with a configuration modifiable by the virtual door owner.

[0126] In other embodiments, the virtual door controller may interface with one or more blockchains to create a unique asset or token (e.g., an ERC-721 token, or an ERC-1155 token, etc.) representing a digital key associated with a virtual door. For example, a decentralized application or smart contract may be configured to generate a unique, immutable token on a blockchain that points to metadata about the digital key stored on a distributed file system, such as the identity of the virtual door, the identity of the owner, the owner's wallet address, and / or other relevant information. The decentralized application or smart contract may be configured to "manufacture" or issue a newly generated token to a specific cryptocurrency wallet address (e.g., a wallet address associated with a user). The smart contract may be configured to prevent the door key from being transferred to other parties (i.e., specifying that the key is for use with only one user), or may be configured to allow the key to be transferred to another user (e.g., a sellable key).

[0127] At box 706, process 700 receives an authenticated request from the user to travel through a virtual door to a destination location. In this example, an authentication service can be used to authenticate the request to identify the user. In some embodiments, the request can be authenticated by including a token, key, or other data within the payload of the request. In a blockchain-based NFT door key implementation, the request can also be authenticated by the user providing a blockchain wallet address, public key, and / or other identifying information to confirm that the user is the owner of the wallet. In these cases, authentication of the user can be used to verify that they are the owner of the NFT-based door key. Therefore, at box 714, process 700 can verify the identity of the user and compare that identity with the owner of the NFT to determine whether to authorize the request. As a specific example, the user's device may include a plug-in that connects to their cryptocurrency wallet that allows other applications such as the XR Universe application to confirm the user's identity and obtain publicly available information about the contents of their wallet.

[0128] At block 708, process 700 determines whether the virtual door is locked. If the door is locked, process 700 may proceed to block 710 and deny the request to use the virtual door. Blocks 708, 710, and 712 may be respectively similar to those described above with reference to FIG. Figure 6 Blocks 608, 610, and 612 are described as being similar or identical.

[0129] If the virtual door is not locked, the process 700 proceeds to block 714 where it determines whether the door key and user are verified and authenticated. As described above, the process 700 may compare the authenticated identity of the user to a stored list or registry of door keys issued by the virtual controller, or may verify ownership of the NFT-based virtual door key.

[0130] If the user and door key cannot be verified and authenticated, the process 700 proceeds to block 716. At block 716, the process 700 may deny the request to use the virtual door. Block 716 may be similar or identical to block 710. Then, at block 718, the process 718 may notify the user that the request to access the owner's virtual door was denied. In some embodiments, the notification may inform the user of the reason for the denial, such as lack of satisfactory authentication (i.e., the user cannot be identified), an invalid door key, a blocked or deleted door key, and / or because the identified user is not the owner of the door key.

[0131] If the user and door key are verified and authenticated, process 700 may proceed to block 720 where process 700 moves the user's avatar to the destination location. Block 720 may be similar to the above referenced Figure 5 Block 516 is described similarly.

[0132] Fig. 8A is a flow chart illustrating a process 800 for authorizing the creation of a virtual door between a first XR world and a second XR world in some embodiments of the present technology. The process 800 may be similar to the process of Figure 5 The process 800 is similar to the process 500 shown and described. The process 800 may be performed by: a user A device 802 (e.g., operated by a visitor to a first XR world); a user B device 804 (e.g., an owner or administrator of the first XR world); a host server 806; and a universe server 808. The user A device 802 and the user B device 804 may be any suitable XR device or component of an XR system, such as an HMD (e.g., Figure 2A HMD 200 or Figure 2B The host server 806 may be a standard remotely accessible web server that hosts websites and / or other web-based data, services, and applications, or may be a locally executed server, service, or application running in a web browser, virtual machine, or operating system. The universe server 808 may be a server that hosts the universe and related data called by the user A device 802 and the user B device 804.

[0133] like Fig. 8AAs shown, at box 812, the user A device 802 may issue a request to a virtual door controller 814 running on a host server 806 to create a new virtual door linked to a second XR world in a first XR world owned and / or maintained by user B. The virtual door controller 814 may communicate with the universe server 808 to retrieve virtual door creation rules (e.g., user permissions, user privacy preferences, virtual door creation policies, virtual door access policies, etc.) at box 816. The virtual door controller 814 may then process the request against one or more virtual door creation rules to determine whether the request violates any of the one or more rules. In some cases, such as where the one or more virtual door creation rules include a rule requiring the owner to explicitly approve the creation of a new virtual door, the virtual door controller 814 may send a request to the user B device 804 and receive a response from the user B device 804 to grant permission to the user A's request to create a new virtual door in the first XR world. If the one or more rules have been met, the virtual door controller 814 proceeds to box 820.

[0134] At block 820, the virtual door controller 814 may communicate with the universe server 808 to create a virtual door between the first XR world and the second XR world. Information about the virtual door (e.g., the location of the virtual door in the first XR world, the location of the virtual door in the second XR world (if the virtual door is instantiated in the second XR world), access permissions, graphics information, etc.) may be returned by the universe server 808 to the virtual controller 814 (i.e., metadata is stored to facilitate intra-universe traversal operations of the virtual door).

[0135] Then, at block 822, user A's device 802 controls user A's avatar to enter a virtual door created within the first XR world and linked to the second XR world. In some embodiments, at block 824, the action of moving through or interacting with the virtual door triggers the virtual door controller 814 to perform a traversal of user A's avatar into the universe of the second XR world. In other embodiments, the virtual door controller 814 may instruct the universe server 808 to create new virtual objects, which the universe server 808 stores with appropriate metadata to facilitate subsequent traversal within the universe without intervention by the virtual door controller 814.

[0136] Figure 8B is a flow chart showing a process 830 for a user to discover and traverse a virtual door in an XR universe in some embodiments of the present technology. Process 830 may be similar to reference Figure 6 The process 830 is shown and described similarly to the process 600. The process 830 may be performed by the user A device 802, the user B device 804, the host server 806, and the universe server 808.

[0137] like Figure 8B As shown, at block 832, user A device 802 may issue a request to the virtual door controller 814 to create a new virtual door at its own virtual property within the XR universe. In response, at block 834, the virtual door controller 814 may engage with the universe server 808 to create a virtual door at user A's property (e.g., at a location manually specified by user A, at a preconfigured location of a virtual door (e.g., a gateway room or hub within user A's property), etc.). In some cases, the virtual door controller 814 may publish the existence of the virtual door to a database, list, or other data repository that other users may access in order to locate a virtual door to go to.

[0138] Then, at block 836, user B device 804 may access a virtual door directory that includes a list of virtual doors at user A's property. Then, at block 838, user B device 804 may request access to a virtual door linked to user A's property (e.g., create a virtual door at user B's property that is directly linked to a virtual door at user A's property). In this example, user A previously configured their privacy preferences to allow other users to access their virtual door and to keep the door unlocked. Therefore, at block 840, virtual door controller 814 determines that user B's request is automatically approved based on user A's privacy preferences, and sends the approval to user B at block 842.

[0139] In some implementations, the virtual door controller 814 may instantiate a virtual door near the location of user B that is directly linked to the virtual door of user A. Thus, when user B requests to traverse the virtual door to user A's property at block 844, the virtual door controller 814 may instruct the universe server 808 to traverse the avatar of user B from its current location to a location at or near the virtual door on user A's property. Depending on the particular implementation, the virtual door controller 814 may or may not act as an intermediary to facilitate traversal, such as where the virtual door is created as an asset stored and maintained by the universe server 808 and implements one or more in-universe traversal functions separately from the virtual door controller 814, the virtual door controller 814 may not act as an intermediary to facilitate traversal.

[0140] Figure 8C is a flow chart illustrating a process 850 for creating a blockchain-based door key to facilitate user access control to a virtual door in an XR universe in some embodiments of the present technology. Process 850 may be similar to reference Figure 7 The process 850 shown and described is similar to the process 700. The process 850 can be performed by the user A device 802, the user B device 804, the host server 806, the universe server 808 and the blockchain 810.

[0141] like Figure 8C As shown, at box 852, user A device 802 may issue a request to create a new virtual door at their own virtual property within the XR universe - the request is granted by the virtual door controller 814 and the universe server 808 at box 854. After the virtual door is created, at box 856, user A may request the virtual door controller 814 to make a new door key for user B on the blockchain 810. In response, at box 858, the virtual door controller 814 interacts with the blockchain 810 to manufacture a new NFT door key to the cryptocurrency wallet associated with user B. In some cases, the virtual door controller 814 may store a record of the blockchain transaction (e.g., a transaction hash, a destination wallet address, information about the request, information about user A and / or user B, etc.) to enable user A to view previously issued door keys.

[0142] Then, at block 860, user B issues a request to access the virtual door of user A's property to the virtual door controller 814, which may include information about the identities and / or cryptocurrency wallets of user A and user B that is used to verify user B's ownership of the NFT door key. In response, at block 862, the virtual door controller 814 may access the blockchain 810 to verify ownership of the NFT door key. Once user B's ownership of the door key is verified, the virtual door controller 814 may send an approval message to user B device 804 at block 864.

[0143] In some implementations, the virtual gate controller 814 may instantiate a virtual gate near the location of user B that is directly linked to the virtual gate of user A. Then, when user B requests to traverse the virtual gate to user A's property at block 866, the virtual gate controller 814 may instruct the universe server 808 to traverse user B's avatar from its current location to a location at or near the virtual gate on user A's property. As with other example implementations described herein, the virtual gate controller 814 may or may not act as an intermediary to facilitate the traversal.

[0144] Fig. 9A and Fig. 9B 900 is a flow chart showing a process 900 for creating and accessing virtual doors connecting locations in different XR universes (i.e., inter-universe travel) in some embodiments of the present technology. Process 900 can be performed by a user A device 902, a universe A server 904, a host server 906, a universe B server 908, and a user B device 910.

[0145] At block 912, user A device 902 issues a request to virtual controller 914 to create a new virtual door at user B's property. In response, virtual door controller 914 issues a subsequent request to user B device 910 at block 916 to obtain user B's authorization to create the new virtual door. If user B authorizes the request, virtual door controller 914 may interface with universe A server 904 at block 918 to create the virtual door at user A's property, and virtual door controller 914 may interface with universe B server 908 to create the virtual door at user B's property. In some implementations, universe A server 904 and universe B server 908 each separately store an in-universe asset (e.g., a 2D or 3D model, texture, metadata, etc.) representing the virtual door. In other cases, the virtual door controller 914 may store these virtual door positions in Universe A and Universe B, respectively, and may be coupled with the user A device 902 and the user B device 910 to perform composite graphics rendering so as to overlay graphic objects representing these virtual doors from the perspectives of the user A device 902 and the user B device 910, respectively.

[0146] At block 922, user A controls their avatar in Universe A to enter the virtual door created at block 918. By interacting with the virtual door, at block 924, Universe A server 904 may initiate a request to virtual door controller 914 to "jump" to Universe B. For example, Universe A server 904 may create an asset, artifact, or other virtual object that is linked to virtual door controller 914 - such that virtual door controller 914 acts as a middleware or XR universe router to facilitate the transition from Universe A to Universe B. In other embodiments, user A device 902 may interact directly with host server 906 when accessing a virtual door (e.g., if virtual door controller is a standalone application that creates and renders virtual doors independently of Universe A).

[0147] Regardless of the specific implementation, at block 926, the user A device 902 may receive a command, instruction, or other message that facilitates traversal to Universe B. For example, the virtual gate controller 914 may provide instructions, commands, one or more URLs, and / or information that enables the user A device 902 to transition between XR Universe applications. FIG. 10A to FIG. 10C Additional details regarding techniques for converting between XR universe applications are shown and described in more detail.

[0148] At block 928, user A device 902 launches an XR universe application (e.g., a web browser pointing to a particular URL, an application executable by the OS of user A device 902, etc.) connected to universe B. The operations of block 928 may involve passing arguments, parameters, or other data to universe B server 908 to facilitate user A's login to universe B, and may involve instantiating user A's avatar at or near a virtual door of user B's property created in universe B at block 920. In some embodiments, blocks 928 and 930 may be performed substantially in the background of user A device 902 so that user A experiences a smooth transition between XR universe applications.

[0149] After user A has explored universe B, they may wish to return to their properties in universe A. Fig. 9B As shown, at box 942, user A can control their avatar in universe B to enter the virtual door created in box 920. By interacting with the virtual door, the universe B server 908 (or the user B device 910) can issue a request to the virtual door controller 914 to "jump" back to universe A at box 944. In response, the virtual door controller 914 can provide one or more instructions and / or one or more commands, which, when executed by the user A device 902, causes the user A device 902 to context switch back to the XR universe application of universe A (if the XR universe application of universe A is still running), or reopen or start the XR application of universe A (if the XR universe application of universe A is exited or closed after switching to universe B).

[0150] At box 948, user A device 902 opens the XR universe application of universe A. In some cases, user A device 902 may notify the virtual gate controller 914 that user A has returned to universe A. In response, at box 952, the virtual gate controller 914 may log user A out and / or cancel initialization from the universe B server. In addition, user A device 902 may close the XR application of universe B at box 950 after returning to universe A (e.g., to prevent overloading of computing resources of user A device 902). In this way, the host server 906 may facilitate the user A device to transition between XR universe applications in a manner that gives user A the impression that it is traveling between XR universes, which may each be supported by different servers, have different avatars and / or art styles, and may require different application or web browser instances to access them.

[0151] Fig. 10A , Fig. 10B and Fig. 10C 1000, 1020, and 1040, respectively, illustrate example architectures for implementing inter-universe interoperability to facilitate intra-universe traversal across different XR universes. Fig. 10A As shown, the web browser 1010 can act as an execution environment for running web clients that implement the Universe A web application 1012, the Universe B web application 1014, and the virtual door controller 1018. In addition, the various applications running in the web browser 1010 can access external authentication services (which can run on external servers) to facilitate user authentication (e.g., single sign-on (SSO) authorization, which can provide authentication of the user's identity across multiple applications at the same time).

[0152] Universe A web application 1012 and Universe B web application 1014 may be adapted to participate in IPC on the client side and / or across the Internet (e.g., via WebSocket, etc.). Interoperable communication between Universe A web application 1012 and Universe B web application 1014 may allow one of multiple applications to share information to create an immersive transition between the two applications, such as: the position, orientation of the avatar; camera angle; input from peripherals, controllers, and / or VR head-mounted viewer; graphics settings (e.g., resolution, window size, etc.) and / or any other information that generally represents the state of the XR application. Thus, a user within Universe A web application 1012 may view Universe B web application 1014 through a virtual door, where the shared information synchronizes the camera angles and fields of view in the two XR universes to give the impression that the two applications are running as one application.

[0153] In some embodiments, the virtual door controller 1018 can provide a canvas within the browser 1010 to which both the Universe A web application 1012 and the Universe B web application 1014 can render graphics, thereby enabling the two applications to be composited on the same canvas (e.g., so that the user does not have to switch to different web browsers or experience jarring context switches). Additionally and / or alternatively, the virtual door controller 1018 can overlay, composite, or otherwise change the canvas of the Universe A web application to graphically render the UI of additional objects (e.g., virtual doors) for creating and managing virtual doors and / or other objects.

[0154] In some embodiments, Universe A web application 1012 and Universe B web application 1014 can each interface with an external authentication service 1016. Although a user logged into Universe A may have a different account than Universe B, authentication service 1016 can enable SSO, which allows the user to conveniently log into Universe A web application 1012 and Universe B web application 1014 instantly, thereby enabling virtual door controller 1018 to launch a new universe web application and log the user into the new XR universe without requiring the user to manually log into the new XR universe application.

[0155] Fig. 10B Shown with Fig. 10A However, in Fig. 10B In the example, the hypervisor 1030 running on the device's operating system can manage the starting, execution, and stopping of different applications (e.g., system and service managers, containerized applications, and virtualization managers, etc.). In this example, the Universe A container 1032 and the Universe B container 1034 can execute software that is essentially compiled for native execution by the device's operating system. However, as Fig. 10A As in the example of , universe A container 1032 and universe B container 1034 can communicate with each other via IPC, similar to Fig. 10A Similarly, hypervisor 1030 may execute a virtual gate controller 1038 that communicates with both Universe A container 1032 and Universe B container 1034 to facilitate creation and operation of a virtual gate connecting locations between Universe A and Universe B. Additionally, authentication service 1036 may be accessed by various services or applications maintained by hypervisor 1030 to facilitate user authentication in each XR Universe application container.

[0156] In some embodiments, the hypervisor 1030 may provide tools (e.g., APIs, command line interfaces (CLIs), etc.) that the virtual gate controller 1038 may use to start and stop XR universe application containers—thus enabling the virtual gate controller 1038 to automatically start new XR universe applications without manual intervention by the user. In addition, the virtual gate controller 1038 may be adapted to access external resources and / or libraries to download containers for new XR universes that the user has not previously accessed. In this way, the techniques of this disclosure may be performed at the OS level to enable in-application traversal across XR universes.

[0157] Fig. 10C Shown with Fig. 10A However, in Fig. 10CIn the example operation, the universe A application 1052 can act as a host or environment in which other XR universe applications can be executed. For example, the universe A application 1052 can be a local application executed directly by the operating system 1050 of the user device. The universe A application 1052 can implement the following in-application web browsers: these in-application web browsers are capable of rendering 3D graphics and passing input from the universe A application 1052 to these web browser sessions. In an example operation, a user within universe A can instantiate a new in-application web browser that launches the universe B web application 1056 and / or the universe C web application 1058 (e.g., where the URL and / or data payload is determined by the virtual door controller 1054). A user within universe A can interact with the web browser to "enter" the 3D environment of universe B or universe C (i.e., the virtual 3D simulation opens the web browser and enters full screen or kiosk mode). By doing so, users can effectively travel between XR universes.

[0158] In some cases, the virtual door controller 1054 can provide graphics assets, textures, and / or other information to the Universe A application 1052 to render the in-application browser as a door, elevator, portal, or another object other than a 2D surface reminiscent of a web browser. By "repackaging" the browser as a doorway or portal, a more immersive experience can be created, giving the feeling of walking through a virtual reality.

[0159] Fig.11 1100 is a conceptual diagram illustrating an example of traversing a virtual door connecting different XR universes. In this example, an avatar 1112 in an XR universe 1110 instructs a virtual door controller to create a virtual door 1114 that connects to a corresponding virtual door 1124 in an XR universe 1130. When the avatar 1112 interacts with or moves through the virtual door 1114, the user is logged into the XR universe 1130, and the user's avatar within the XR universe is instantiated near the virtual door 1124. In this way, the user has actually traversed different XR universes.

[0160] In this example, XR universe 1110 and XR universe 1130 have different art styles. Therefore, the user's avatar 1112 in XR universe 1110 has a different appearance than the user's avatar 1122 in XR universe 1130. Therefore, the user's avatar may not necessarily travel through the virtual reality, but the same user can experience switching from their current avatar to their avatar in the destination XR universe.

[0161] Additionally, users within XR universe 1110 may access directory 1116 of virtual doors in XR universe 1110 and / or XR universe 1130. Users may view directory 1116 of virtual doors to discover new places to visit and / or find virtual doors connected to their friends or users they follow.

[0162] Fig.12 1 is a conceptual diagram 1200 illustrating an example user interface (UI) for managing virtual doors. Fig.12 As shown, a virtual interface can be created within the XR universe application that enables users to view their privacy preferences (e.g., user privacy preferences 448), manage door keys, lock existing doors, unlock existing doors, view and / or update their one or more allow lists and one or more block lists, and / or create new virtual doors. In some embodiments, the user privacy interface can be a web page hosted by a virtual door controller that is rendered in a virtual browser within the XR application. In some cases, the user privacy preferences can be implemented by the XR application itself. Regardless of the specific implementation, the virtual management interface can enable users to manage their virtual door privacy preferences without having to exit the virtual reality.

[0163] References in this specification to "embodiments" (e.g., "some embodiments," "various embodiments," "one embodiment," "an embodiment," etc.) mean that a particular feature, structure, or characteristic described with respect to that embodiment is included in at least one embodiment of the present disclosure. The appearances of these phrases in different places in the specification do not necessarily all refer to the same embodiment, nor are they necessarily separate embodiments or alternative embodiments that are mutually exclusive of other embodiments. In addition, various features are described that may be exhibited by some embodiments but not by other embodiments. Similarly, various requirements are described that may be requirements for some embodiments but not for other embodiments.

[0164] As used herein, being above a threshold value means that the value of the comparison item is higher than other specified values, the comparison item is located in a certain specified number of items with a maximum value, or the value of the comparison item is within a specified maximum percentage value. As used herein, being below a threshold value means that the value of the comparison item is lower than other specified values, the comparison item is located in a certain specified number of items with a minimum value, or the value of the comparison item is within a specified minimum percentage value. As used herein, being within a threshold value means that the value of the comparison item is between two other specified values, the comparison item is located in an intermediate specified number of items, or the value of the comparison item is within an intermediate specified percentage range. In the absence of additional definition, relative terms (such as high or unimportant) can be understood as assigning a value and determining how the value compares to a given threshold value. For example, the phrase "selecting a fast connection" can be understood to mean selecting a connection with an assigned value corresponding to a connection speed that is higher than a threshold value.

[0165] As used herein, the word "or" refers to any possible arrangement of a group of items. For example, the phrase "A, B or C" refers to at least one of A, B, C, or any combination thereof, such as any of the following: A; B; C; A and B; A and C; B and C; A, B and C; or a plurality of any items, such as A and A; B, B and C; A, A, B, C and C; etc.

[0166] Although the subject matter has been described in language specific to structural features and / or method actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Specific embodiments and implementations have been described herein for illustrative purposes, but various modifications may be made without departing from the scope of these embodiments and implementations. The specific features and actions described above are disclosed as example forms of implementing the appended claims. Therefore, the embodiments and implementations are not limited except as limited by the appended claims.

Claims

1. A method for creating a virtual door for a user to traverse one or more artificial reality (XR) worlds, the method comprising: receiving, at a computing system, a first request from a first user to create a first virtual door within a first XR world, the first virtual door linking the first XR world to a second XR world; obtaining one or more rules defining restrictions on creating a virtual door in the first XR world, the restrictions defining one or more of who can create a virtual door and / or where a virtual door from the first world can lead to, wherein if the one or more rules are satisfied, a user can create a virtual door; determining, based on at least one of the first user and the second XR world, that the one or more rules associated with the restrictions defining one or more of who can create a virtual door and / or where a virtual door from the first world can lead to are satisfied; and Based on determining that the one or more rules are satisfied, the first virtual door is generated within the first XR world linking to the second XR world.

2. The method according to claim 1, wherein: The one or more rules include: defining rules for a user allow list, and wherein determining that the one or more rules are satisfied comprises determining that the user allow list includes the first user, and / or Rules for a user block list are defined, and wherein determining that the one or more rules are satisfied includes determining that the user block list does not include the first user.

3. The method according to claim 1 or 2, wherein: The one or more rules include: defining rules for an allowed list of worlds, and wherein determining that the one or more rules are satisfied comprises determining that the allowed list of worlds includes the second XR world, and / or A world blocking list, and wherein determining that the one or more rules are satisfied comprises determining that the world blocking list does not include the second XR world.

4. A method according to any preceding claim, wherein: The one or more rules include a rule that specifies: A world rating minimum threshold, and wherein determining that the one or more rules are satisfied comprises: determining a world rating associated with the second XR world; and determining that the one or more rules are satisfied based at least in part on determining that the world rating is above the world rating minimum threshold, and / or A minimum world similarity threshold, and wherein determining that the one or more rules are satisfied comprises: determining a similarity score indicating a degree of similarity between the first XR world and the second XR world; and Satisfaction of the one or more rules is determined based at least in part on determining that the similarity score is above the world similarity minimum threshold.

5. The method according to claim 4, wherein: The similarity score is based at least in part on one or more first tags associated with the first XR world and one or more second tags associated with the second XR world.

6. The method according to claim 4 or 5, wherein: The similarity score is based at least in part on a first content type associated with the first XR world and a second content type associated with the second XR world.

7. A method according to any preceding claim, wherein: The first XR world and the second XR world are located in the same XR universe hosted by an XR universe server system.

8. A method according to any preceding claim, wherein: The first XR world is located within a first XR universe hosted by a first XR universe server system, and wherein the second XR world is located within a second XR universe hosted by a second XR universe server system.

9. A computer-readable storage medium storing instructions that, when executed by a computing system, cause the computing system to perform operations for accessing a virtual door for a user to traverse one or more artificial reality (XR) worlds, the operations comprising: receiving, at a computing system, a first request from a first user to access a first virtual door within a first XR world, the first virtual door being linked to a second XR world; obtaining one or more rules, the one or more rules defining restrictions on access to a virtual door in the first XR world, wherein if the one or more rules are satisfied, the user is able to access the virtual door; determining that the one or more rules are satisfied based at least in part on the first user; and Based on determining that the one or more rules are satisfied, the first user is caused to traverse the first virtual door to reach the second XR world.

10. The computer-readable storage medium of claim 9, wherein: The one or more rules include: defining rules for a user allow list, and wherein determining that the one or more rules are satisfied comprises determining that the user allow list includes the first user, and / or A user block list, and wherein determining that the one or more rules are satisfied comprises determining that the user block list does not include the first user.

11. The computer-readable storage medium according to claim 9 or 10, wherein: The one or more rules include a rule defining a time of day restriction, and wherein determining that the one or more rules are satisfied includes: Determine the current time of day; and The one or more rules are determined to be satisfied based at least in part on determining that the current time of day is outside of the time of day constraints.

12. A computing system for accessing a virtual door for a user to traverse one or more artificial reality (XR) worlds, the computing system comprising: one or more processors; as well as One or more memories storing instructions that, when executed by the one or more processors, cause the computing system to perform operations including: receiving, at the computing system, a first request from a first user to access a virtual door within an XR world, the virtual door being linked to an XR experience; Obtaining one or more rules, the one or more rules defining restrictions on access to a virtual door in the XR world, wherein a user is able to access the virtual door if the one or more rules are satisfied; determining that the one or more rules are satisfied based at least in part on the first user; and Based on determining that the one or more rules are satisfied, the first user is caused to traverse the virtual door to reach the XR experience.

13. The computing system of claim 12, wherein: The operations also include: receiving a second request from the first user to return to the XR world from within the XR experience; and Upon receiving the second request, the first user is caused to exit the XR experience and return to the XR world.

14. The computing system of claim 13, wherein: Receiving the second request includes receiving: a voice command from the first user within the XR experience, and / or A menu input selection from the first user within the XR experience.

15. The computing system of claim 13 or 14, wherein: The one or more memories further have stored thereon an XR universe application engaged with the XR world and an XR experience application engaged with the XR experience, and wherein causing the first user to traverse the virtual door to reach the XR experience comprises: Launching the XR experience application; and The computing system is caused to switch from the XR universe application to the XR experience application.

Images