Patent Description:
However, creation of these experiences is typically limited to developers that possess high-level skills and technical capabilities. For example, to create an experience, a person must have the technical capability to program the spatial aspects of a three-dimensional scene, the motion of objects in the three-dimensional scene, the texture of objects in the three-dimensional scene, the lighting of objects in the three-dimensional scene, and so forth. The average person does not possess these high-level skills and technical capabilities, and thus, the average person is typically unable to create these types of experiences.

Furthermore, conventional platforms used to create these experiences are limited in that they do not provide an effective and efficient way for a group of users to create the experience together in a three-dimensional immersive environment. Stated another way, the conventional platforms do not enable a collaborative and interactive approach to creating an experience in a three-dimensional immersive environment. <CIT> discloses a shared collaboration system for enabling an active user to interact with one or more additional users and with collaboration items. A head-mounted display device is operatively connected to a computing device that includes a collaboration engine program. The program receives observation information of a physical space from the head-mounted display device along with a collaboration item. The program visually augments an appearance of the physical space as seen through the head-mounted display device to include an active user collaboration item representation of the collaboration item. The program populates the active user collaboration item representation with additional user collaboration item input from an additional user. <CIT> discloses a system for storing and simultaneous multi-user editing of documents, including text documents, presentation documents, graphic image documents, audio/visual clips and other types of documents. US <NUM>/<NUM> A1 discloses a method for collaborative editing that may include enabling a user to define a partitioning constraint for a design space and partitioning the design space into editing regions according to the partitioning constraint and assigning users to specific editing regions. It is the object of the present invention to provide an improved method for efficiently editing a scene in a three-dimensional immersive environment.

The techniques described herein provide a platform that enables multiple users to dynamically and concurrently create a scene of an experience that is viewable in a three-dimensional immersive environment. The three-dimensional immersive environment can be provided via a display of a head-mounted display device. The creation of the scene may be referred to herein as "editing" the scene. In other words, provided a "canvas" (e.g., a blank canvas, a canvas template with pre-configured three-dimensional content, a previously created canvas, etc.), multiple users can provide edits by altering existing content in the canvas, by adding content to the canvas, and/or by removing content from the canvas. The content can include three-dimensional content (e.g., three-dimensional objects) and two-dimensional content (e.g., a two-dimensional photo, a two-dimensional logo, etc.).

In various implementations described herein, the editing occurs while multiple users are concurrently viewing a scene in a three-dimensional immersive environment. Thus, the users can visually see updates to the scene in real-time and in a dynamic manner. Stated another way, while a first user is providing edits to content in the scene, the first user and other users can visually see the response to the content in the scene being edited by the first user. This enables a collaborative and interactive approach to scene editing and provides efficiencies with respect to scene creation. For instance, a scene created for augmented reality, mixed reality, and/or virtual reality experience can be complex and can include a large amount of content. Having multiple users providing concurrent input on scene creation allows the final scene to be realized in more effective and efficient manner.

To avoid problems and user frustrations that may occur when multiple users have the ability to edit a scene in a three-dimensional immersive environment, the techniques described herein use region locking so that content being edited by one user viewing and editing the scene in a three-dimensional immersive environment cannot be edited by another user concurrently viewing and editing the same scene in the three-dimensional immersive environment. A region comprises a three-dimensional space in the scene. The three-dimensional space in the scene consumed by a region includes a subset of a total amount of three-dimensional space in the scene. To this end, the scene can be divided into multiple regions. In a specific example, if the scene comprises a living room setting, then a first region can include a first three-dimensional space in which a couch is positioned, and a second region can include a second three-dimensional space, adjacent to the first three-dimensional space, in which a chair and a coffee table are positioned.

By dividing, or separating, the scene into multiple regions that can be locked, the techniques described herein provide an element of protection against user interference that can result when two users are editing, or attempting to edit, the same content. For instance, when a first user requests to edit first content (e.g., a three-dimensional object, a collection of three-dimensional objects, etc.) in the scene, a region of the scene in which the first content is positioned is locked so that other users are unable to edit content in the region even though they can dynamically preview the content being edited by the first user in real-time in the three-dimensional immersive environment. However, the other users can edit content in other regions of the scene outside the region that was locked for the first user. These other regions may be referred to as unlocked regions that are available for editing in a multi-user editing environment. Consequently, region locking limits user interference and further avoids user frustration and user distraction that can result when multiple users attempt to edit the same scene content in a three-dimensional immersive environment.

In various examples, the techniques described herein can be implemented via a Web-enabled application accessible via a browser executing on a head-mounted display device, or on a computing device connected to a head-mounted display device. The Web-enabled application can allow multiple users to access and edit a scene of an experience in a three-dimensional immersive environment. Accordingly, the Web-enabled application can include functionality that is executed: on a network device (e.g., a server of a network provider), on a head-mounted display device, on a computing device connected to a head-mounted display device, or across a combination of any of these devices. Alternatively, the techniques described herein can be implemented via an application executing on a user device (e.g., a head-mounted display device, a laptop, a smartphone, etc.) that is configured to communicate (e.g., peer-to-peer communications) with other user devices to enable a multi-user editing approach to a scene in a three-dimensional immersive environment.

While a region is locked for a user to edit content therein, the user is provided with editing controls. The editing controls for a region are specifically configured for a user for which the region is locked. Stated another way, other users cannot view and/or activate the editing controls for a locked region. The editing controls enable the user to add content, remove content, or alter content (e.g., change a property of an object) displayed in the scene. Consequently, the techniques described herein provide an ability for multiple users to implement a collaborative and interactive approach to scene creation in which each of the users can preview all the content in the scene, but individual users are limited to editing a subset of all the content in the scene via region locking.

In various examples, editing content may comprise moving content from one locked region to another. For example, a user may provide editing input to increase a size of an object so that the object is displayed outside a boundary of an initial locked region. In another example, a user may provide editing input to change the position of the object so that the object is partly positioned or fully positioned outside a boundary of an initial locked region. Therefore, in association with the moving, the techniques described herein can lock another region to which the content is moved so that other users are unable to edit content in the other region. Alternatively, in association with the moving, the techniques described herein can expand the initially locked region to include an area to which the object is moved.

This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The term "techniques," for instance, may refer to system(s), method(s), computer-readable instructions, module(s), algorithms, hardware logic, and/or operation(s) as permitted by the context described above and throughout the document.

The same reference numbers in different figures indicate similar or identical elements.

Techniques configured to enable multiple users to dynamically and concurrently edit a scene that is viewable in a three-dimensional immersive environment are described herein. The techniques use region locking so that content being edited by one user viewing and editing the scene in a three-dimensional immersive environment cannot be edited by another user concurrently viewing and editing the same scene in the three-dimensional immersive environment. Accordingly, a scene can be divided into multiple regions that can be locked to provide an element of protection against user interference that can result when two users are editing, or attempting to edit, the same content.

Various examples, scenarios, and aspects are described below with reference to <FIG>.

<FIG> is a diagram <NUM> illustrating an example of how multiple different users (e.g., user <NUM>, user <NUM>, user <NUM>) can dynamically and concurrently edit a scene <NUM> in a three-dimensional immersive environment. The editing of the scene <NUM> can be implemented via a head-mounted display device. That is, user <NUM> can use head-mounted display device <NUM> to view and/or to edit the scene <NUM>. User <NUM> can use head-mounted display device <NUM> to view and/or to edit the scene <NUM>. User <NUM> can use head-mounted display device <NUM> to view and/or to edit the scene <NUM>.

In various examples, a network provider <NUM> can operate a system <NUM> to enable access to, and creation of, the scene <NUM> over network(s) <NUM>. In these examples, the network provider <NUM> includes a multi-user editing module <NUM> that can access scene(s) <NUM> (which include scene <NUM>) and implement region locking <NUM> so that multiple users <NUM>, <NUM>, <NUM> can view the same scene and edit different content in the scene concurrently (e.g., at the same time).

Consequently, while viewing the scene <NUM> via head-mounted display device <NUM>, user <NUM> can provide input requesting to edit content in a first region. For instance, user <NUM> can provide input (e.g., click on a graphical user interface control <NUM>) to edit a balloon object <NUM> displayed in the scene. Similarly, while viewing the scene <NUM> via head-mounted display device <NUM>, user <NUM> can provide input requesting to edit content in a second region (e.g., a dog object <NUM> displayed in different space of the scene). And while viewing the scene <NUM> via head-mounted display device <NUM>, user <NUM> can provide input requesting to edit content in a third region (e.g., the plant object <NUM> displayed in different space of the scene). As further described herein, the regions comprise different three-dimensional spaces in the scene <NUM>. Via region locking, the users <NUM>, <NUM>, <NUM> can collaborate on the editing of scene without interfering with one another and/or frustrating one another with respect to the editing process. While three users are shown in <FIG>, and further examples described herein, it is understood in the context of this disclosure that any numbers of users can concurrently edit a scene (e.g., two, four, five, ten, etc.).

As described above, a user can edit content in a locked region by altering existing content in the locked region (e.g., the balloon object <NUM>, the dog object <NUM>, the plant object <NUM>), by adding content to the locked region, and/or by removing content from the locked region. When a region is locked for a specific user, the user is provided with editing controls for his or her locked region. Since the region is locked for the specific user, other users editing the scene cannot see the editing controls configured for the specific user. However, the other users can preview, in real-time, the results of any edits (e.g., the altering of a property of an object, the addition of an object, the removal of an object, etc.).

As used herein, a "control" can comprise a displayed graphical user interface (GUI) element (e.g., a button, an object, etc.) that is activated based on an interaction between the GUI element and user input (e.g., a user selects or clicks on the GUI element). A control can alternatively be configured to accept and/or detect other forms of input such as a recognized voice command or a detected gesture. Thus, a control may be configured to receive user input but may not necessarily be displayed as a GUI element.

An object can be a three-dimensional object (e.g., a figure, shape, etc.) or a two-dimensional object (e.g., an image such as a photo or a logo, a document, etc.). The object may be associated with a widget. A widget comprises information (e.g., instructions) useable to access and display data configured to model an object in a three-dimensional immersive environment. For example, a widget can comprise a uniform resource locator (URL) that refers to an accessible network location at which the data is stored and from which the data can be retrieved and rendered for display. Accordingly, while editing a locked region, a user can add an object to a scene and/or remove an object from a scene via the use of a widget. In some instances, a widget can be configured to access and display a collection of related objects that share an environment attribute. For instance, a widget may be configured to access a pair of skis, ski boots, and ski poles since they each share a common attribute - a single user uses them to ski down a hill. A widget may be selected from a library of available widgets stored locally at a user device or from a network library of available widgets stored remotely at the one or more network provider(s) <NUM> (note that network providers(s) may be disparate content and/or service provider(s)). In this situation, the widget, as well as the object and/or the collection of objects, can be retrieved and downloaded to the head-mounted display devices <NUM>, <NUM>, <NUM> via network(s) <NUM>.

In addition to adding or removing an object, a user can alter or change a property of an object in a locked region. In various examples, a property of an object can comprise a transform property such as a display orientation of the object, a scale (e.g. a size) of the object, a shading of the object, or a texture of the object. A property of an object can also or alternatively comprise a display position of the object, whether the object is moveable or animated or is only displayed in a fixed location, whether a consuming user can move the object, a color of the object, a display association between the object and another object in the scene (e.g., a grouping of objects such that if a consuming user moves one object the other object also moves), or a display association between the object and another scene (e.g., if the user selects or clicks on the object then the user will be taken to another scene in the experience). Further properties of an object include: a sound associated with or produced by the object or a display ability of the object to adapt to a real-world scene (e.g., always place a picture on a real-world wall rather than on a real-world floor in an augmented or mixed reality environment).

In various examples, a computing device <NUM> connected to a head-mounted display device <NUM> can be used to establish a network connection and effect an edit while a user <NUM> is viewing the scene <NUM> via the head-mounted display device <NUM>. Accordingly, in some instances, the head-mounted display device <NUM> may not include a processor or computer-readable media and/or cannot establish network connections on its own. Rather, the head-mounted display device <NUM> may comprise an output device configured to render data stored on the computing device <NUM> for display. Therefore, interfaces of the computing device <NUM> and the head-mounted display device <NUM> can be configured to communicate via a wired and/or wireless Universal Serial Bus ("USB") connection, a BLUETOOTH connection, a High-Definition Multimedia Interface ("HDMI") connection, and so forth.

Examples of a head-mounted display device include, but are not limited to: OCCULUS RIFT, GOOGLE DAYDREAM VIEW, MICROSOFT HOLOLENS, HTC VIVE, SONY PLAYSTATION VR, SAMSUNG GEAR VR, GOOGLE CARDBOARD, SAMSUNG HMD ODYSSEY, DELL VISOR, HP HEADSET, LENOVO EXPLORER, ACER HEADSET, ASUS WINDOWS MIXED REALITY HEADSET, or any augmented reality, mixed reality, and/or virtual reality devices.

A computing device <NUM> useable to edit a scene can include, but is not limited to: a game console, a desktop computer, a laptop computer, a gaming device, a tablet computer, a personal data assistant (PDA), a mobile phone/tablet hybrid, a telecommunication device, a network-enabled television, a terminal, an Internet of Things (IoT) device, a work station, a media player, or any other sort of computing device. In some implementations, a user device (e.g., a head-mounted display device, computing device <NUM>) includes input/output (I/O) interfaces that enable communications with input/output devices such as user input devices including peripheral input devices (e.g., a game controller, a keyboard, a mouse, a pen, a voice input device, a touch input device, a gestural input device, and the like) and/or output devices including peripheral output devices (e.g., a display screen, a touch screen, a printer, audio speakers, a haptic output device, and the like).

Network(s), such as network(s) <NUM>, can include, for example, public networks such as the Internet, private networks such as an institutional and/or personal intranet, or some combination of private and public networks. Network(s) can also include any type of wired and/or wireless network, including but not limited to local area networks (LANs), wide area networks (WANs), satellite networks, cable networks, Wi-Fi networks, WiMax networks, mobile communications networks (e.g., <NUM>, <NUM>, and so forth) or any combination thereof. Network(s) can utilize communications protocols, including packet-based and/or datagram-based protocols such as internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), or other types of protocols. Moreover, network(s) can also include a number of devices that facilitate network communications and/or form a hardware basis for the networks, such as switches, routers, gateways, access points, firewalls, base stations, repeaters, backbone devices, and the like.

In various examples, a user can access a template to start scene editing. The template can provide a starting point for scene creation. To this end, a template can be selected and retrieved from a library of available templates. A template comprises an environment file that includes representations of models (e.g., models that define the spatial geometry of a background for a three-dimensional scene, models that define the spatial geometry of a panorama for a three-dimensional scene, etc.).

<FIG> is a diagram <NUM> that illustrates an example of how a scene (e.g., scene <NUM>) can be divided into multiple regions <NUM>(<NUM>) through <NUM>(N) (where N is a positive integer number) capable of being locked by users <NUM>, <NUM>, <NUM> that are concurrently editing the scene. The regions <NUM>(<NUM>) through <NUM>(N) may be collectively referred to as regions <NUM>. In this example, a number of regions <NUM> into which a scene is divided can include a predetermined number of regions (e.g., six regions as shown, two regions, three regions, four regions, ten regions, twenty regions, etc.).

Moreover, the three-dimensional space that a region consumes can be preconfigured. For instance, the diagram <NUM> of <FIG> illustrates that the scene is divided into regions <NUM>(<NUM>) through <NUM>(N) that comprise a three-dimensional space based on radial "lanes" or "zones". Using a point on the ground in the room setting of the scene (e.g., the middle of the room), an individual region comprises a three-dimensional space with a boundary (represented by the dashed lines) extended from the point to an edge (e.g., a wall) of the room. The boundaries for each region are determined based on an angle (e.g., the angles of each region may be the same or different) and the three-dimensional space includes the space between the ground and the ceiling.

Note that while each of users <NUM>, <NUM>, <NUM> are consuming the same scene via their respective head-mounted display devices, the actual content displayed to, and/or viewed by, an individual user at a given time may vary based on where the individual user has positioned himself or herself in the scene and/or how the individual user has oriented himself or herself in the scene (e.g., body orientation, head orientation, etc.).

Continuing the example of <FIG>, user <NUM> may provide input requesting to edit the balloon object. Upon receiving this input and this request, the multi-user editing module <NUM> locks region <NUM>(<NUM>) based on a position of the balloon object (e.g., the balloon object is positioned in region <NUM>(<NUM>)). As shown in the view into the scene for user <NUM>, region <NUM>(<NUM>) is locked (e.g., shaded) to indicate to user <NUM> that other users <NUM>, <NUM> consuming the scene cannot edit content in region <NUM>(<NUM>). Once region <NUM>(<NUM>) is locked, the multi-user editing module <NUM> configures balloon editing controls <NUM> for user <NUM> to interact with. Again, the balloon editing controls <NUM> are specific to user <NUM> since region <NUM>(<NUM>) is locked for user <NUM>.

Furthermore, the multi-user editing module <NUM> generates and displays a graphical indication to users <NUM>, <NUM>. One element <NUM> of the graphical indication can indicate that region <NUM>(<NUM>) is locked, and therefore, is not available for users <NUM>, <NUM> to edit. Another element <NUM> of the graphical indication can inform users <NUM>, <NUM> of the identity of user <NUM> (e.g., display a photo, a name, or another form of a user identifier).

Similarly, user <NUM> may provide input requesting to edit the dog object. Upon receiving this input and this request, the multi-user editing module <NUM> locks region <NUM>(N) based on a position of the dog object (e.g., the dog object is positioned in region <NUM>(N)). As shown in the view into the scene for user <NUM>, region <NUM>(N) is locked (e.g., shaded) to indicate to user <NUM> that other users <NUM>, <NUM> consuming the scene cannot edit content in region <NUM>(N). Once region <NUM>(N) is locked, the multi-user editing module <NUM> configures dog editing controls <NUM> for user <NUM> to interact with.

Furthermore, the multi-user editing module <NUM> generates and displays a graphical indication to users <NUM>, <NUM>. One element <NUM> of the graphical indication can indicate that region <NUM>(N) is locked, and therefore, is not available for user <NUM>, <NUM> to edit. Another element <NUM> of the graphical indication can inform users <NUM>, <NUM> of the identity of user <NUM>.

Via the display of the graphical indication, when user <NUM> joins the collaborative editing session and views the scene, he can quickly notice that regions <NUM>(<NUM>) and <NUM>(N) are already being edited by other users, and thus, are locked. Consequently, if user <NUM> wants to edit content, he will have to edit content within one or more of regions <NUM>(<NUM>), <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>) that are available for editing.

In various examples, a region boundary is not fixed, but rather, an adjustable boundary. For instance, a boundary may be automatically adjusted by the multi-user editing module <NUM> so that content to be edited is completely positioned within a single region (e.g., an object does not span multiple regions). In the example diagram <NUM> of <FIG>, an angle can be changed to accommodate the complete placement of an object in one region.

While the example of <FIG> is implemented in response to a user request to edit an object, regions can also or alternatively be locked based on a general request to edit a region (e.g., the user does not have to request to edit a specific object). Accordingly, the multi-user editing module <NUM> may outline an initial set of regions and provide a control for a user to request to lock a particular region for editing. Once locked, the user can add content to the region, remove content from the region, and/or change a property of existing content in the region.

<FIG> is a diagram <NUM> that illustrates another example of how a scene (e.g., scene <NUM>) can be divided into multiple regions <NUM>(<NUM>) through <NUM>(N) (where N is a positive integer number) capable of being locked by users <NUM>, <NUM>, <NUM> that are concurrently editing the scene. The regions <NUM>(<NUM>) through <NUM>(N) may be collectively referred to as regions <NUM>.

The diagram <NUM> of <FIG> illustrates a different way in which the scene can be divided into regions <NUM>. In this example, a three-dimensional space of a region is based on a block. For instance, a first region <NUM>(<NUM>) may be the upper left side of a room, a second region <NUM>(<NUM>) may be the upper right side of the room, a third region <NUM>(<NUM>) may be the lower right side of the room, and a fourth region <NUM>(N) may the lower left side of the room. The number of regions may be a predetermined number and the size of the regions may be of equal or different size.

Revisiting the example of <FIG>, user <NUM> may provide input requesting to edit the balloon object. Upon receiving this input and this request, the multi-user editing module <NUM> locks region <NUM>(<NUM>) based on a position of the balloon object (e.g., the balloon object is positioned in region <NUM>(<NUM>)). As shown in the view into the scene for user <NUM>, region <NUM>(<NUM>) is locked so that other users <NUM>, <NUM> consuming the scene cannot edit content in region <NUM>(<NUM>). Once region <NUM>(<NUM>) is locked, the multi-user editing module <NUM> configures balloon editing controls <NUM> for user <NUM> to interact with.

Similar to the discussion above with respect to <FIG>, the multi-user editing module <NUM> generates and displays a graphical indication to users <NUM>, <NUM>. The graphical indication can indicate that region <NUM>(<NUM>) is locked (via the "closed lock" symbol), and therefore, is not available for users <NUM>, <NUM> to edit. The graphical indication can also inform users <NUM>, <NUM> of the identity of user <NUM> (e.g., display a photo, a name, or another form of a user identifier).

Further, user <NUM> may provide input requesting to edit the dog object. Upon receiving this input and this request, the multi-user editing module <NUM> locks region <NUM>(N) based on a position of the dog object (e.g., the dog object is positioned in region <NUM>(N)). As shown in the view into the scene for user <NUM>, region <NUM>(N) is locked so that other users <NUM>, <NUM> consuming the scene cannot edit content in region <NUM>(N). Once region <NUM>(N) is locked, the multi-user editing module <NUM> configures dog editing controls <NUM> for user <NUM> to interact with.

Similar to the discussion above with respect to <FIG>, the multi-user editing module <NUM> generates and displays a graphical indication to users <NUM>, <NUM>. The graphical indication can indicate that region <NUM>(N) is locked (via the "closed lock" symbol), and therefore, is not available for users <NUM>, <NUM> to edit. The graphical indication can also inform users <NUM>, <NUM> of the identity of user <NUM>.

The example diagram <NUM> of <FIG> shows that another graphical indication <NUM> (e.g., an "opened lock" symbol) can be associated with regions that are available for editing. Therefore, when user <NUM> joins the collaborative editing session and views the scene, he can quickly notice which regions <NUM>(<NUM>) and <NUM>(<NUM>) are available for editing.

<FIG> is a diagram <NUM> that illustrates yet another example of how a scene (e.g., scene <NUM>) can be divided into multiple regions capable of being locked by users <NUM>, <NUM>, <NUM> that are concurrently editing the scene. In one example, the boundaries of a region in the diagram <NUM> of <FIG> can be defined based on user input. For instance, the user can outline a region that he or she wants to have locked for editing purposes. More specifically, the user can walk through and/or around the scene (e.g., the room) and a use a pointing mechanism to define boundaries of the region.

In another example, the boundaries of a region in the diagram <NUM> of <FIG> can be determined by the multi-user editing module <NUM>. For instance, based on a request to edit an object, the multi-user editing module <NUM> can dynamically define the boundaries of a region in which the object lies. The boundaries may be determined based on a size of the object being edited, a position of the object relative to a position of another object in the scene (e.g., a connected or a related object) that has a property affected by the object being edited, a distance between a position of the object and a position of the user (e.g., the region includes both the object and the user), or a combination of these factors. Stated another way, the boundaries of the region can be defined by the multi-user editing module <NUM> to fully contain an object and/or to contain objects likely to be edited together.

As shown in the diagram <NUM> of <FIG>, and again revisiting the example of <FIG>, user <NUM> may provide input that defines boundaries of a region <NUM> that contains the balloon object and that is locked for user <NUM>. The view into the scene provided to user <NUM> shows that region <NUM> is "your locked region". Moreover, the multi-user editing module <NUM> may define boundaries of a region <NUM> that contains the dog object and that is locked for user <NUM>. The boundaries of this region <NUM> may be defined so that the dog object and the chair object are both completely within the region <NUM> since the chair is related or connected to the dog (e.g., the dog is sitting on the chair). Similarly, the view into the scene provided to user <NUM> shows that region <NUM> is "your locked region".

As described above, the multi-user editing module <NUM> generates and displays a graphical indication to user <NUM> indicating that regions <NUM> and <NUM> are locked (via the "closed lock" symbol) and that users <NUM> and <NUM> are the current editors of these regions. Moreover, the multi-user editing module <NUM> can provide a graphical indication of area(s) and/or content in the scene that are not locked and that are available for editing <NUM>.

<FIG> is a diagram <NUM> that illustrates an example of locking an additional region for a user based on content editing that occurs outside an initially locked region. On the left side, the diagram <NUM> starts with a view into the scene provided to user <NUM>, as illustrated in <FIG> (e.g., region <NUM>(<NUM>) is locked for user <NUM> so she can edit the balloon object). As shown, user <NUM> may move <NUM> the balloon object from a position in locked region <NUM>(<NUM>) to a position in unlocked region <NUM>(<NUM>) which is not yet locked for user <NUM>. Alternatively, the user may increase <NUM> a size of the balloon object so it spans both locked region <NUM>(<NUM>) and unlocked region <NUM>(<NUM>).

Based on this editing input, the multi-user editing module <NUM> is configured to add a locked region <NUM> for user <NUM>. On the right side, the diagram <NUM> illustrates an updated view into the scene provided to user <NUM>, in which the multi-user editing module <NUM> also locks <NUM> region <NUM>(<NUM>) for user <NUM> (e.g., region <NUM>(<NUM>) is also shaded to the user <NUM> can continue to edit the balloon object without interference from others). Consequently, the user <NUM> is provided with an expanded locked area in the scene (e.g., multiple locked regions).

<FIG> is a diagram <NUM> that illustrates an example of expanding a locked region for a user based on content editing that occurs outside an initially locked region. On the left side, the diagram <NUM> starts with a view into the scene provided to user <NUM>, as illustrated in <FIG> (e.g., region <NUM> is locked for user <NUM> so she can edit the balloon object). As shown, user <NUM> may move <NUM> the balloon object from a position in locked region <NUM> to an area outside the locked region <NUM>. Alternatively, the user may increase <NUM> a size of the balloon object so it spans the locked region <NUM> and the area outside the locked region.

Based on this editing input, the multi-user editing module <NUM> is configured to expand the locked region <NUM> for user <NUM>. On the right side, the diagram <NUM> illustrates an updated view into the scene provided to user <NUM>, in which the multi-user editing module <NUM> expands <NUM> the region <NUM> for user <NUM> so she can continue to edit the balloon object without interference from others. Consequently, the user <NUM> is again provided with an expanded locked area in the scene (e.g., an expanded locked region).

<FIG> is a diagram of an example device <NUM> that can implement the techniques described herein. The device <NUM> can comprise a network device (e.g., a server that comprises or is part of a system <NUM>), a head-mounted display device, and/or a computing device in communication with the head-mounted display device. For instance, the device <NUM> can include, but is not limited to: a server computer, a game console, a desktop computer, a laptop computer, a gaming device, a tablet computer, a personal data assistant (PDA), a mobile phone/tablet hybrid, a telecommunication device, a network-enabled television, a terminal, an Internet of Things (IoT) device, a work station, a media player, or any other sort of computing device.

The device <NUM> can include processor(s) <NUM> and computer-readable media <NUM>. As used herein, a "processor" can represent, for example, a CPU-type processing unit, a GPU-type processing unit including a virtual GPU (VGPU), a field-programmable gate array (FPGA), a digital signal processor (DSP), or other hardware logic components that may, in some instances, be driven by a CPU. For example, and without limitation, illustrative types of hardware logic components that can be used include Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), System-on-a-Chip Systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc..

As used herein, "computer-readable media" can store instructions executable by a processor and/or data (e.g., model data for a scene, a template, or an object). Computer-readable media can also store instructions executable by external processing units such as by an external CPU, an external GPU, and/or executable by an external accelerator, such as an FPGA type accelerator, a DSP type accelerator, or any other internal or external accelerator. In various examples, at least one CPU, GPU, and/or accelerator is incorporated in a computing device, while in some examples one or more of a CPU, GPU, and/or accelerator is external to a computing device.

Computer-readable media can include computer storage media and/or communication media. Computer storage media can include one or more of volatile memory, nonvolatile memory, and/or other persistent and/or auxiliary computer storage media, removable and non-removable computer storage media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Thus, computer storage media includes tangible and/or physical forms of memory included in a device and/or a hardware component that is part of a device or external to a device, including but not limited to random-access memory (RAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), phase change memory (PCM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, compact disc read-only memory (CD-ROM), digital versatile disks (DVDs), optical cards or other optical storage media, magnetic cassettes, magnetic tape, magnetic disk storage, magnetic cards or other magnetic storage devices or media, solid-state memory devices, storage arrays, network attached storage, storage area networks, hosted computer storage or any other storage memory, storage device, and/or storage medium that can be used to store and maintain information for access by a computing device.

In contrast to computer storage media, communication media can embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transmission mechanism. As defined herein, computer storage media does not include communication media. That is, computer storage media does not include communications media consisting solely of a modulated data signal, a carrier wave, or a propagated signal, per se.

In some implementations, the device <NUM> includes input/output (I/O) interfaces that enable communications with input/output devices such as user input devices including peripheral input devices (e.g., a game controller, a keyboard, a mouse, a pen, a voice input device, a touch input device, a gestural input device, a motion input device, and the like) and/or output devices including peripheral output devices (e.g., a display screen, a printer, audio speakers, a haptic output device, and the like).

Device <NUM> also includes connection interfaces <NUM> that enable the device <NUM> to communicate over network(s) such as local area networks (LANs), wide area networks (WANs), satellite networks, cable networks, Wi-Fi networks, WiMax networks, mobile communications networks (e.g., <NUM>, <NUM>, and so forth), etc. In various implementations, connection interfaces <NUM> of a computing device and/or a head-mounted display device can be configured to operate in accordance with, and communicate over, a personal area network (PAN) that uses a wired and/or a wireless connection. For example, a PAN connection can operate in accordance with Infrared Data Association ("IrDA"), BLUETOOTH, wired and/or wireless USB, Z-Wave, ZIGBEE, or other short-range wireless technology.

The device <NUM> further includes a multi-user editing module <NUM> (e.g., multi-user editing module <NUM>) that is configured to cause scene(s) <NUM> to be rendered and displayed to a plurality of users in a three-dimensional immersive environment via a plurality of head-mounted display devices. Moreover, the multi-user editing module <NUM> enables region locking <NUM> to be implemented in the scene(s) <NUM> so the users can concurrently edit separate content without interfering with other users' editing.

Furthermore, the device <NUM> can include a communication module <NUM> that can be executed in association with the multi-user editing module <NUM>. The communication module <NUM> enables voice and/or messaging communications so the users can collaborate and interact with one another while they are concurrently editing a scene.

The modules provided in <FIG> are an example, and the number of modules used to implement the techniques described herein can vary higher or lower. That is, functionality described herein in association with the illustrated modules can be performed by a fewer number of modules or a larger number of modules on one device or spread across multiple devices.

<FIG> is a diagram <NUM> illustrating an example experience <NUM>, of which scene(s) being concurrently being edited by multiple users can be a part. As shown, the experience <NUM> can include two-dimensional scenes and/or three-dimensional scenes. Generally, an experience <NUM> includes related and/or linked content that can be accessed and/or displayed for a particular purpose. As a specific example, the experience <NUM> can include company content an employer wants a new employee to know, to be informed about, or to learn, and thus, the new employee can access the experience <NUM> when he or she starts a new job. In another specific example, the experience <NUM> can include lesson content a school teacher wants a student to know, to be informed about, or to learn, and thus, the student can access the experience when he or she dives into a particular lesson. In accordance with these examples and others, the display of restricted and/or tailored content based on user identities can be implemented.

An experience <NUM> can include one or more spaces <NUM>(<NUM>) through <NUM>(N) (where N is a positive integer number such as one, two, three, four, and so forth). A space comprises a segment or type of content within the broader experience <NUM>. There is no limitation how one segment or type of content can be distinguished from another segment or type of content in the same experience <NUM>. Moreover, an experience may only include a single space. Continuing an example from above and to further illustrate, space <NUM>(<NUM>) can include company content that relates to job training for a new employee, while space <NUM>(N) can include company content related to different interest and activity groups for which the employer provides a budget (e.g., a hiking group, a skiing group, a chess group, a religious study group, etc.). The employer may have a policy to inform a new employee about these interest and activity groups when he or she starts a new job, so the new employee can join if a common interest is shared. This example shows how the two types of content relate to a situation where a new employee is beginning employment with a company, yet the types of content are different and therefore different spaces can be created and/or consumed within a broader experience <NUM>.

As described above, a space can include three-dimensional scenes. In various implementations, an entry point for a user to consume a space can comprise a Web page or an Intranet page (e.g., a URL), accessed via a head-mounted display device or a computing device connected to the head-mounted display device. For instance, a new employee can visit "www. companyABC. com/employeetraining" on his or her computing device to enter space <NUM>(<NUM>) that is part of the broader experience <NUM>. The new employee can also visit "www. companyABC. com/employeegroups" on his or her computing device to enter space <NUM>(N) that is part of the broader experience <NUM>. In a specific example, space <NUM>(<NUM>) may include a home page that displays two-dimensional content (e.g. text and a few images). This home page may include a first link to three-dimensional scene <NUM>, which may contain links to three-dimensional scene <NUM> and three-dimensional scene <NUM>. The three-dimensional scenes <NUM>, <NUM>, and <NUM> may also include links, or anchor points, that enable navigation to one another in a three-dimensional immersive environment. The new employee can consume the three-dimensional scenes <NUM>, <NUM>, and <NUM> in a three-dimensional immersive environment using a head-mounted display device. These three-dimensional scenes <NUM>, <NUM>, and <NUM>, can also comprise URLs that are part of the Web page (e.g., "www. companyABC. com/employeetraining/3Dscene708" and "www. companyABC. com/employeetraining/3Dscene710"). Moreover, a scene <NUM> in a first space <NUM>(<NUM>) can provide a link <NUM> (e.g., via the selection of a two-dimensional or three-dimensional object) to a three-dimensional scene <NUM> in a second space <NUM>(N).

Accordingly, the editing of scenes, as described herein, can be implemented in association with creation of an experience <NUM> designed for a particular type of user (e.g., a new employee, a student of a class, etc.). In various examples, the experience <NUM> can be associated with one or more Web pages, yet aspects of the experience <NUM> can include, for example, one or more virtual reality (VR) three-dimensional scenes, one or more augmented reality (AR) three-dimensional scenes, and/or one or more mixed reality (MR) three-dimensional scenes. While the experience <NUM> shown in the example diagram <NUM> of <FIG> shows a limited number of spaces and scenes, it is understood in the context of this disclosure, that an experience can include any number of spaces (e.g., one, two, three, four, five, ten, twenty, one hundred) for related content and any number of scenes (e.g., one, two, three, four, five, ten, twenty, one hundred, etc.).

<FIG> contains a flowchart of a method. It should be understood that the operations of the methods disclosed herein are not presented in any particular order and that performance of some or all of the operations in an alternative order(s) is possible and is contemplated. The operations have been presented in the demonstrated order for ease of description and illustration. Operations may be added, omitted, and/or performed simultaneously, without departing from the scope of the appended claims.

It also should be understood that the illustrated methods can end at any time and need not be performed in their entireties. Some or all operations of the methods, and/or substantially equivalent operations, can be performed by execution of computer-readable instructions included on a computer-storage media, as defined below. The term "computer-readable instructions," and variants thereof, as used in the description and claims, is used expansively herein to include routines, applications, application modules, program modules, programs, components, data structures, algorithms, and the like. Computer-readable instructions can be implemented on various system configurations, including single-processor or multiprocessor systems, minicomputers, mainframe computers, personal computers, hand-held computing devices, wearable computing devices, microprocessor-based, programmable consumer electronics, combinations thereof, and the like.

Thus, it should be appreciated that the logical operations described herein are implemented (<NUM>) as a sequence of computer implemented acts or program modules running on a computing system and/or (<NUM>) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as states, operations, structural devices, acts, or modules. These operations, structural devices, acts, and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof.

Additionally, the operations described herein can be implemented as a sequence of computer implemented acts or program modules running on a computing system (e.g., system <NUM>, a head-mounted display device <NUM>, computing device <NUM>, and/or device <NUM>).

<FIG> is a diagram of an example flowchart <NUM> that illustrates operations directed to enabling multiple users to concurrently edit content of a scene displayed in three-dimensional immersive environment.

At operation <NUM>, a scene is caused to be displayed in a three-dimensional immersive environment via a plurality of head-mounted display devices associated with a plurality of users. Due to the nature of a scene displayed in a three-dimensional immersive environment, the actual content displayed to, and/or viewed by, the users at a given time may vary based on where an individual user has positioned himself or herself in the scene and/or how the individual user has oriented himself or herself in the scene (e.g., body orientation, head orientation, etc.).

At operation <NUM>, request(s) for user(s) to edit content in the scene are received. For example, a user may request to edit specific content (e.g., an object) displayed in the scene. In another example, a user may request to edit a region of the scene.

At operation <NUM>, region(s) are determined for editing. Examples of how a scene can be divided into regions are provided above with respect to <FIG>, <FIG>, and <FIG>.

At operation <NUM>, region(s) are locked based on the request(s) so that users other than the requesting user are unable to edit content in a region.

At operation <NUM>, the displayed scene is caused to be updated with graphical indications that indicate region(s) are locked and/or that identify user(s) as editor(s) of the region(s).

At operation <NUM>, content is edited in the scene based on concurrent editing input received from the plurality of users via the plurality of head-mounted display devices.

At operation <NUM>, region(s) are unlocked based on user input indicating content is no longer being edited or a predetermined time period expiring.

Although the techniques have been described in language specific to structural features and/or methodological acts, it is to be understood that the appended claims are not necessarily limited to the features or acts described. Rather, the features and acts are described as example implementations of such techniques.

The operations of the example processes are illustrated in individual blocks and summarized with reference to those blocks. The processes are illustrated as logical flows of blocks, each block of which can represent one or more operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the operations represent computer-executable instructions stored on one or more computer-readable media that, when executed by one or more processors, enable the one or more processors to perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, modules, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be executed in any order, combined in any order, subdivided into multiple sub-operations, and/or executed in parallel to implement the described processes. The described processes can be performed by resources associated with one or more device(s) such as one or more internal or external CPUs or GPUs, and/or one or more pieces of hardware logic such as FPGAs, DSPs, or other types of accelerators.

All of the methods and processes described above may be embodied in, and fully automated via, software code modules executed by one or more general purpose computers or processors. The code modules may be stored in any type of computer-readable storage medium or other computer storage device. Some or all of the methods may alternatively be embodied in specialized computer hardware.

Conditional language such as, among others, "can," "could," "might" or "may," unless specifically stated otherwise, are understood within the context to present that certain examples include, while other examples do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that certain features, elements and/or steps are in any way required for one or more examples or that one or more examples necessarily include logic for deciding, with or without user input or prompting, whether certain features, elements and/or steps are included or are to be performed in any particular example. Conjunctive language such as the phrase "at least one of X, Y or Z," unless specifically stated otherwise, is to be understood to present that an item, term, etc. may be either X, Y, or Z, or a combination thereof.

Claim 1:
A method (<NUM>) comprising:
causing (<NUM>), by one or more processors, a scene (<NUM>) to be displayed in a three-dimensional immersive environment via a plurality of head-mounted devices (<NUM>, <NUM>, <NUM>) respectively associated with a plurality of users (<NUM>, <NUM>, <NUM>);
wherein the scene (<NUM>) includes a plurality of objects capable of being separately edited by individual ones of the plurality of users;
receiving (<NUM>) a request for a first user (<NUM>) of the plurality of users (<NUM>, <NUM>, <NUM>) to edit an object in the scene (<NUM>);
dividing the scene into a predetermined number of regions;
locking (<NUM>) a region (<NUM>) so that users (<NUM>, <NUM>) other than the first user (<NUM>) are unable to edit content in the region (<NUM>), wherein the region comprises the object and at least one other object; and
causing (<NUM>) the displayed scene (<NUM>) to be updated with a graphical indication (<NUM>, <NUM>) that identifies the first user (<NUM>) as an editor of the region (<NUM>).