Selective hand occlusion over virtual projections onto physical surfaces using skeletal tracking

CROSS REFERENCE TO RELATED PATENT APPLICATIONS

0001This patent application claims the benefit of priority to U.S. Provisional Patent Application Ser. No. 61/468,937 entitled “Systems and Methods for Gesture Driven Interaction for Digitally Augmented Physical Spaces” filed on Mar. 29, 2011, the entire contents of which are hereby incorporated by reference for all purposes.

0002This patent application is also related to U.S. patent application Ser. No. ______ entitled “Modular Mobile Connected Pico Projectors For A Local Multi-User Collaboration” filed on ______, U.S. patent application Ser. No. ______ entitled “Anchoring Virtual Images to Real World Surfaces In Augmented Reality Systems” filed on ______, U.S. patent application Ser. No. ______ entitled “Cloud Storage Of Geotagged Maps” filed on ______, and U.S. patent application Ser. No. ______ entitled “System For The Rendering Of Shared Digital Interfaces Relative To Each User's Point Of View” filed on ______.

FIELD OF THE INVENTION

0003The present application relates to an augmented or virtual reality system using a head mounted display, or other mobile devices such as smartphones or tablets, that can place a virtual object or interface on a selected physical surface so that a single user or multiple users can collaborate to, view and interact with the virtual object on the physical surface.

BACKGROUND

0004Increasingly, people are collaborating around the globe on a variety of media, including presentations, documents, videos, graphs and photographs. Generally, large flat panel displays in a conference room are an excellent source to view media including Microsoft® PowerPoint® presentations. Additionally, some furniture may include touch screen input devices so users can view video directly on the surface of a table top. Often such large items are very expensive and provide limited support for collaboration between users in remote locations. Individuals would benefit from being able to break free from these restrictions and gain a big screen virtual or augmented reality experience that is shared between both co-located users and remote users.

SUMMARY OF THE INVENTION

0005The various embodiments include methods of rendering images in an augmented reality system, including capturing an image of a scene in which a virtual object is to be displayed, recognizing a body part present in the captured image, and adjusting a display of the virtual object based upon the recognized body part. In an embodiment, adjusting a display of the virtual object may include identifying a portion of the virtual object that overlaps the recognized body part, and suppressing the identified portion such that the recognized body part appears to occlude the identified portion of the virtual object. In a further embodiment, adjusting a display of the virtual object may include identifying a portion of the virtual object that overlaps the recognized body part, and superimposing the virtual object on the recognized body part such that the identified portion of the virtual object appears to occlude the recognized body part. In a further embodiment, adjusting the displayed virtual object may include adjusting displayed portions of the virtual object overlapping the recognized body part such that the virtual object is viewable through the recognized body part and such that the recognized body part appears semitransparent.

0006In a further embodiment, the method may include displaying the virtual object on a body mounted semitransparent display configured such that that an individual wearing the body mounted semitransparent display can view the scene through the display. In a further embodiment, capturing an image of a scene in which a virtual object is to be displayed may include capturing an image with a body mounted camera worn by a first individual, the method further including capturing spatial data with a body mounted sensor array worn by the first individual, recognizing objects within the captured image, and determining distances to the recognized objects within the captured image.

0007In a further embodiment, the method may include displaying the virtual object and the captured image on a head mounted display such that the scene is viewable to an individual wearing the body mounted semitransparent display. In a further embodiment, recognizing a body part present in the captured image may include applying an anatomical analysis to the captured image. In a further embodiment, applying an anatomical analysis to the image may include recognizing objects within the captured image, comparing the recognized objects to a skeletal model stored in memory, the stored skeletal model including relative position information about key joints, bones, and limbs of a human skeleton, and determining if any of the recognized objects match a portion of the skeletal model in response to comparing the recognized objects to the skeletal model.

0008In a further embodiment, the method may include determining whether the body part belongs to a first individual or to a second individual in response to recognizing a body part present in the captured image, determining a location and encompassed area of the virtual object, and determining whether the recognized body part overlaps at least one portion of the area encompassed by the virtual object. In a further embodiment, determining whether the body part belongs to a first individual or to a second individual may include determining whether the body part belongs to the first or second individual based on an orientation of the recognized body part. In a further embodiment, determining whether the body part belongs to a first individual or to a second individual may include determining that the body part belongs to the first or second individual based on a distance of the recognized body part from the body mounted camera.

0009In a further embodiment, determining whether the body part belongs to a first individual or to a second individual may include determining that the body part belongs to the first or second individual based on a number of body parts determined to be in the captured image. In a further embodiment, adjusting a display of the virtual object may include displaying the virtual object superimposed over the recognized body part of the second individual when it is determined that the body part belongs to the second individual, and displaying the virtual object so that the virtual object appears to be located beneath the recognized body part when it is determined that the body part belongs to the first individual. In a further embodiment, displaying the virtual object so that the virtual object appears to be located beneath the recognized body part may include not rendering portions of the virtual object which overlap the recognized body part. In a further embodiment, the method may include displaying an outline of portions of the recognized body part of the second individual that overlap a display area encompassed by the virtual object such that the outline is visible over the virtual object in the display.

0010Further embodiments include a system that may include a first head or body mounted device that may include a first head or body mounted camera, a first head or body mounted display, a first transceiver, and a first head or body mounted device processor coupled to the first camera, first display and first transceiver; and a second head or body mounted device comprising a second head or body mounted camera, a second head or body mounted display, a second transceiver, and a second head or body mounted device processor coupled to the second camera, second display and second transceiver. In further embodiments, the first and second head or body mounted device may be configured with processor-executable instructions to perform various operations corresponding to the method operations discussed above. Even further embodiments may include a server that may include a memory and a server processor coupled to the memory, the server processor being configured with server-executable instructions to perform operations corresponding to the various methods discussed above and/or for transmitting information to the first or second head or body mounted devices via a network.

0011Further embodiments include a computing device that may include a processor configured with processor-executable instructions to perform various operations corresponding to the methods discussed above. Further embodiments include a computing device that may include various means for performing functions corresponding to the method operations discussed above.

0012Further embodiments include a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor to perform various operations corresponding to the methods discussed above.

BRIEF DESCRIPTION OF THE DRAWINGS

0013The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate exemplary embodiments of the invention, and together with the general description given above and the detailed description given below, serve to explain the features of the invention.

0014<figref idref="DRAWINGS">FIG. 1</figref> is an illustration of a head mounted device with a virtual object anchored on a physical surface suitable for use with various embodiments.

0015<figref idref="DRAWINGS">FIG. 2</figref> is an illustration of two users standing at a table side by side from one another and wearing two head mounted devices for interacting with a virtual object.

0016<figref idref="DRAWINGS">FIG. 3</figref> is an illustration of two users sitting at a table across from one another and wearing two head mounted devices for interacting with a virtual object and with the virtual object being correctly oriented for each user.

0017<figref idref="DRAWINGS">FIG. 4</figref> is an illustration of two users at two different remote locations wearing two head mounted devices and collaborating and studying the same virtual object, which is correctly oriented for each user.

0018<figref idref="DRAWINGS">FIG. 5A</figref> is a high level component block diagram of a number of components of a head mounted device to interact with and to generate a virtual object.

0019<figref idref="DRAWINGS">FIG. 5B</figref> is a high level component block diagram of a system that enables users wearing a head mounted device to communicate with a server according to another embodiment.

0020<figref idref="DRAWINGS">FIG. 6</figref> is a process flow diagram of an embodiment method for using a head mounted device to anchor a virtual object on an anchor surface in which the virtual object remains fixed to the anchor surface on the head mounted display.

0021<figref idref="DRAWINGS">FIG. 7A</figref> is a process flow diagram of an embodiment method for anchoring a virtual object on a physical surface viewable in a display of a head mounted device.

0022<figref idref="DRAWINGS">FIG. 7B</figref> is a process flow diagram of an embodiment method for moving a virtual object between at least two different anchor points or surfaces by an input command.

0023<figref idref="DRAWINGS">FIG. 8A</figref> is a process flow diagram of an embodiment method for a head mounted device to project a virtual object so it appears anchored on a physical surface and for projecting a second virtual object on a second head mounted device so that it appears to a second user to be anchored on a different physical surface.

0024<figref idref="DRAWINGS">FIG. 8B</figref> is a process flow diagram of an embodiment method of rendering a shared virtual object that is oriented correctly for each user's point of view.

0025<figref idref="DRAWINGS">FIGS. 9A and 9B</figref> are process flow diagrams of an embodiment method for anchoring a virtual object on a physical surface and for using a second device to anchor a second virtual object on a different physical surface using a coordinate map.

0026<figref idref="DRAWINGS">FIG. 10</figref> is a process flow diagram of an embodiment method for discovering other head mounted devices to link and share data.

0027<figref idref="DRAWINGS">FIG. 11</figref> is a process flow diagram of an embodiment method for recognizing both gestures and audio from a user as a confirmed input command for controlling the head mounted device.

0028<figref idref="DRAWINGS">FIG. 12</figref> is a process flow diagram of an embodiment method for using a head mounted device that captures images of a user to recognize gestures as input commands.

0029<figref idref="DRAWINGS">FIG. 13</figref> is a process flow diagram of an embodiment method for controlling the rendering of certain objects within an image.

0030<figref idref="DRAWINGS">FIG. 14</figref> is a process flow diagram of an embodiment method for using a head mounted device to capture images associated with a user and to detect the user's and other individual's features, and when the other individual's features are detected, to superimpose the virtual object over the other individual's features so as to not occlude the virtual object.

0031<figref idref="DRAWINGS">FIG. 15</figref> is a top view of a head mounted display output showing a virtual object with a user's hands and with other individual's hands occluding the virtual object and with the virtual object displayed superimposed on the other individual's hands so they seem transparent.

0032<figref idref="DRAWINGS">FIG. 16</figref> is a side view of a head mounted device communicating with a mobile communication device via a high speed wireless data link so software is executed on the mobile communication device while the sensors capture data at the head mounted device.

0033<figref idref="DRAWINGS">FIG. 17</figref> is a process flow diagram of an embodiment method for using a head mounted device to wirelessly link to the mobile communication device to exchange data.

0034<figref idref="DRAWINGS">FIG. 18</figref> is a process flow diagram of an embodiment method for using a head mounted device to scan an area, calculate parameters of an area, and upload the calculated parameters of the area to a shared memory for access by another device.

0035<figref idref="DRAWINGS">FIG. 19</figref> is a process flow diagram of an embodiment method for using a head mounted device to generate a three-dimensional model of an area, tag the data with location data, and upload the model to share the data with other devices.

0036<figref idref="DRAWINGS">FIG. 20</figref> is a process flow diagram of an embodiment method for using a head mounted device to execute an application on a server and share the data with other devices.

0037<figref idref="DRAWINGS">FIG. 21</figref> is a process flow diagram of an embodiment method for using a head mounted device to discover other head mounted devices by a directory to share data with other devices and for collaboration.

0038<figref idref="DRAWINGS">FIGS. 22-23</figref> illustrate two head mounted devices accessing a shared service or a shared memory to exchange scanned data and to collaborate with one another.

0039<figref idref="DRAWINGS">FIG. 24</figref> is a process flow diagram of an embodiment method for using a head mounted device to scan an area, render a virtual object, tag calculated parameters with location data, and upload the tagged parameters to a shared memory for the benefit of other head mounted devices.

0040<figref idref="DRAWINGS">FIG. 25A</figref> is a high level illustration of several mobile devices communicating with a cloud server to provide shared data to the cloud server and to allow new devices to scan and map an area utilizing the shared data.

0041<figref idref="DRAWINGS">FIG. 25B</figref> is a process flow diagram of a method of storing tagged and scanned parameters in a cloud server for use by a second head mounted device to render a virtual object.

0042<figref idref="DRAWINGS">FIGS. 26-28B</figref> are process flow diagrams of embodiment methods for using a head mounted device to render a virtual object on a display and to superimpose the virtual object over a body part on the display.

0043<figref idref="DRAWINGS">FIG. 29</figref> is a process flow diagram of an embodiment method for using a head mounted device and a cloud server to share scanned and calculated data parameters with several other head mounted devices.

0044<figref idref="DRAWINGS">FIG. 30</figref> is a process flow diagram of an embodiment method for using two different head mounted devices and a server to share data and collaborate using two different software applications using a virtual object input device whereby conflicts are resolved between the two different software applications.

0045<figref idref="DRAWINGS">FIG. 31</figref> is a high level block diagram of several users sharing data and collaborating using different software applications.

0046<figref idref="DRAWINGS">FIG. 32</figref> is a process flow diagram of an embodiment method for using two different computing devices to share data and collaborate using two different word processing applications.

0047<figref idref="DRAWINGS">FIGS. 33-34</figref> are process flow diagrams of embodiment methods for using a head mounted device to recognize both gestures and audio commands, and to process the commands as confirmed input commands when a first command and a second command are detected in succession.

0048<figref idref="DRAWINGS">FIGS. 35-36</figref> are process flow diagrams of embodiment methods for using a head mounted device to recognize gesture commands to render a “virtual object input device” on the generated virtual object so the user may control the virtual object using the virtual input device.

0049<figref idref="DRAWINGS">FIG. 37</figref> is a high level block diagram of an embodiment using a gesture tracking camera and/or an RGB and distance measuring camera (or cameras) to provide the “virtual object input device” which is a virtual pointer device that is controlled by a user's finger to select icons on the virtual object.

0050<figref idref="DRAWINGS">FIGS. 38-39</figref> show high level block diagrams of a peer to peer based system and a central cloud configuration based system for using a head mounted device and a server to share data and enable user collaboration.

0051<figref idref="DRAWINGS">FIG. 40A</figref> is a high level block diagram of an embodiment system using a gesture tracking camera and a camera to provide the “virtual object input device” that forms a virtual pointer device where the virtual object may be rendered large on the head mounted display.

0052<figref idref="DRAWINGS">FIGS. 40B-40C</figref> show another embodiment of rendering a virtual object using a modular pico projector that may detect gestures and output a projection for a user.

0053<figref idref="DRAWINGS">FIG. 40D</figref> shows a process flow diagram of an embodiment method of projecting an image with a pico projector in a convenient location for a user by detecting one or more gestures.

0054<figref idref="DRAWINGS">FIG. 41</figref> is a component block diagram of a mobile computing device suitable for use with the various embodiments.

0055<figref idref="DRAWINGS">FIG. 42</figref> is a component block diagram of a server computing device suitable for use with the various embodiments.

DETAILED DESCRIPTION

0056The various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the invention or the claims.

0057The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any implementation described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other implementations.

0058As used herein, the terms “mobile device” and “handheld device” refer to any one of cellular telephones, smartphones, tablet computers, personal data assistants (PDA's), wireless electronic mail receivers, multimedia Internet enabled cellular telephones, Global Positioning System (GPS) receivers, wireless gaming controllers, netbooks, and similar personal electronic devices that include a programmable processor and memory, are configured to communicate with a wireless communication network, and have a web browser.

0059As used herein, the terms “computer,” “personal computer” and “computing device” refer to any programmable computer system that is known or that will be developed in the future. In a preferred embodiment a computer will be coupled to a network such as described herein. A computer system may be configured with processor-executable software instructions to perform the processes described herein.

0060As used herein, the term “component,” “module,” and “system,” is intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server may be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

0061As used herein, the term “head mounted device” (HMD) refers to a device that captures distance sensor data and has a display capability linked to a mobile processor, which may be a separate device relative to the head mounted device and as shown in <figref idref="DRAWINGS">FIG. 16</figref>. In an embodiment, the head mounted device <b>10</b> may be an accessory for a mobile device CPU (e.g., the processor of a cell phone, tablet computer, smartphone, etc.) with the main processing of the head mounted devices control system <b>1610</b> (“VIRT control system” in the figures) being performed on the processor of mobile device <b>1605</b>. In another embodiment, the head mounted device may comprise a processor, a memory, a display and a camera. In an embodiment, head mounted device <b>10</b> may be a mobile device (e.g., smartphone, etc.) that includes one or more sensors (e.g., a depth sensor, camera, etc.) for scanning or collecting information from an environment (e.g., room, etc.) and circuitry for transmitting the collected information to another device (e.g., server, second mobile device, etc.).

0062In another embodiment, the head mounted device may include a wireless interface for connecting with the Internet, a local wireless network, or another computing device. In another embodiment, a pico-projector may be associated in the head mounted device to enable projection of images onto surfaces. The head mounted device is preferably lightweight and constructed to avoid use of heavy components, which could cause the device to be uncomfortable to wear. The head mounted device may also be operable to receive audio/gestural inputs from a user. Such gestural or audio inputs may be spoken voice commands or a recognized user gesture, which when recognized by a computing device may cause that device to execute a corresponding command.

0063The term “peer-to-peer network” is intended to encompass any form of peer-to-peer network technology known or that may be developed in the future. While some embodiments refer to peer-to-peer networks that make use of hypertext transfer protocol (HTTP) messaging, such references are intended merely to serve as examples, and not to limit the scope of the claims to any particular networking technology.

0064For ease of reference, examples illustrating the functioning of various embodiments may refer to networks as first and second networks or users, or to networks and users A and B. For example, a first user may be referred to as “user A” and a second user may be referred to as “user B.” Such references in the figures and the descriptions are arbitrary and used to simplify network and user references, and thus are not intended to limit the scope of the claims to just two networks or just two users, or to limit particular users to particular networks, as the various embodiments support any number of networks and users.

0065Various embodiments will be presented in terms of systems that may include a number of components, and modules. It is to be understood and appreciated that the various systems may include additional components, modules, etc., and may not include all of the components, modules, etc. discussed in connection with the figures. A combination of these approaches may also be used.

0066Turning to <figref idref="DRAWINGS">FIG. 1</figref>, the various embodiments enable a head mounted device <b>10</b> to render a virtual object <b>14</b> displayed on an anchored surface <b>16</b> in order to provide an augmented reality experience that can facilitate interactions with a computing device and collaborations with other users. The various embodiments may include capturing an image with a camera that is head mounted or body mounted (e.g., on the neck, shoulder or arms of a user, or hand held). For ease of reference, the term “body mounted” as used herein and in the claims encompasses head mounted. In an embodiment, this camera may be a head or body mounted stereo camera, which can generate image data that a processor can analyze to estimate distances to objects in the image through trigonometric analysis of stereo images. Alternatively or in addition, the head mounted device may include one or more distance measuring sensors (e.g., a laser or sonic range finder) that can measure distances to various surfaces within the image. As discussed in more detail below, in the various embodiments a variety of different types of distance measuring sensors and algorithms may be used an imaged scene to measure for measuring distances to objects within a scene viewed by a user. Also, more than one sensor and type of sensor may be used in a head mounted device. Therefore, for ease of description and consistency, the various assemblages and types of distance measuring sensors that may be included on a head mounted device are referred to herein collectively or individually as “distance sensors.”

0067Further, the head mounted device <b>10</b> may include orientation sensors, such as accelerometers, gyroscopes, magnetic sensors, optical sensors, mechanical or electronic level sensors, and inertial sensors which alone or in combination can provide data to the device's processor regarding the up/down/level orientation of the device (e.g., by sensing the gravity force orientation) and thus the user's head position/orientation (and from that viewing perspective). Further, the head mounted device may include rotational orientation sensors, such as an electronic compass and accelerometers, that can provide data to the device's processor regarding left/right orientation and movement. Collectively, sensors (including accelerometers, gyroscopes, magnetic sensors, optical sensors, mechanical or electronic level sensors, inertial sensors, and electronic compasses) configured to provide data regarding the up/down and rotational orientation of the head mounted device (and thus the user's viewing perspective) are referred to herein as “orientation sensors.”

0068The system may be configured to recognize user inputs, which may be made through gestures that may be imaged by the camera, and identify surfaces or locations for positioning virtual objects within the imaged scene. A distance to the recognized object within the image may be determined from data gathered from a stereo image and/or a distance sensor. The head mounted device <b>10</b> may provide image and distance sensor data to and receive display information from a mobile processor which may be separate from the head mounted device, such as in a smartphone or other mobile device, as discussed in more detail below with reference to <figref idref="DRAWINGS">FIG. 16</figref>. This process of orienting the head mounted device with respect to the surroundings, and determining a distance to and orientation of various surfaces may be accomplished by each device being worn by a number of users so that a displayed virtual object is seen by each user from the perspective appropriate for each user. Further, this process may be accomplished continuously so that each head mounted device can triangulate its own position and angle of view as it moves in space by constantly referencing the shifts in the topography of scanned three-dimensional (3D) environment, thus performing Simultaneous Location and Mapping (SLAM) operations.

0069In an embodiment, the head mounted device <b>10</b> may receive a first user input indicating a first anchor surface <b>16</b> in a captured image. This input may be any of a variety of user inputs, such as in the form of a button press, a recognizable gesture performed in view of the head-mounted camera, a focused gaze by the user recognized as an image that remains relatively still for a predetermined period of time, or other recognizable input. The first anchor surface <b>16</b> may correspond to a first surface located in the image obtained by the camera of the head mounted device <b>10</b>. A processor coupled to or within the head mounted device <b>10</b> may generate a virtual object <b>14</b> and calculate display-relevant parameters, including distance and orientation with respect to the head mounted or body mounted camera that correspond to a display location of the virtual object <b>14</b>. When the user elects to display the virtual object <b>14</b> anchored to a designated anchor surface, the processor coupled to or within the head mounted device <b>10</b> may render the virtual object <b>14</b> on a display (or through a projector) so that the virtual object appears to be on the first anchor surface <b>16</b> when viewed through the display. The virtual object <b>14</b> may be any virtual object <b>14</b>, including, for example, text, graphics, images and 3D shapes. When presented in this manner, the projection of virtual objects positioned at/on designated locations within the surrounding environment can create the experience of virtual reality and enable user interactions with the virtual object. The various embodiments enable natural interactions with virtual objects and digital assets (documents, pictures, videos, etc.). Such natural interactions with virtual objects and digital assets may include gesture controls, touch manipulations, highlighting of touched portions of the virtual object, etc. Recognizable gestures may be stored or organized in the form of a gesture dictionary accessible by head mounted devices. Such a gesture dictionary may store movement data or patterns for recognizing gestures that may include pokes, pats, taps, pushes, guiding, flicks, turning, rotating, grabbing and pulling, two hands with palms open for panning images, drawing (e.g., finger painting), forming shapes with fingers (e.g., an “OK” sign), and swipes, all of which may be accomplished on, in close proximity to, or addressing the direction of (in relation to the user) the apparent location of a virtual object in a generated display. In this manner, the various embodiments enable natural interactions with virtual objects, which may include gesture controls or other suitable control input methods.

0070The various embodiments may be implemented using different types of head mounted displays. Some head mounted displays may be semitransparent enabling the user to view the scene beyond the display, with projected images appearing superimposed upon the background scene. In other embodiments, the head mounted display completely blocks the user's view of the room. In this embodiment, the head mounted display provides a virtual or augmented reality experience. In order to see the objects in the room, images obtained by a camera or cameras worn by the user may be used to project a view of the room onto the head mounted display. In this embodiment, virtual objects may be added to the images projected on head mounted display, thereby appearing as real as the actual images obtained by the cameras.

0071In embodiments in which the head mounted display is nontransparent (i.e. fully occluded), the head mounted device <b>10</b> may display images of the scene in front of the user with virtual objects at <b>14</b> included in the display so that they appear anchored to the selected anchor surface <b>16</b>. In this embodiment, the imaging sensors and head mounted device project onto the nontransparent display an image of the scene in front of the user. In order for the user to navigate to that scene, the user views the images obtained from the head mounted cameras on the head mounted display. This may include rendering into the display images of the user's hands, particularly when the user is moving his or her hands as part of a control gesture. If the virtual object <b>14</b> is anchored to a particular surface, the virtual object will not appear in the display when the user is looking away from the anchor surface. Since the head mounted display presents images generated by the head mounted device, including images obtained from body-mounted cameras, the system may display portions of the scene so virtual objects appear in front of the background. Thus, in this implementation, if a virtual image is presented on the head mounted display in front of the user's hands, the user's hands would not be visible to the user. As a result the virtual object may appear to be solid and nontransparent. This embodiment provides a virtual or augmented reality experience that includes displaying real images obtained by user-worn cameras combined with virtual objects presented on the same display.

0072In embodiments in which the head mounted display is semitransparent (i.e., user can see the background scene through the display), the head mounted device <b>10</b> may display the generated virtual object so the virtual object appears anchored to the first anchor surface <b>16</b> as seen by the user through the display. In this manner, the user may view a scene with a partially transparent head mounted display where real world objects, like a desk, a table and walls, are partially visible through the head mounted display which also places virtual objects within the visible scene. Visible virtual objects <b>14</b> may be anchored to or connected to real world objects <b>16</b>. This embodiment provides an augmented reality experience in which the display is see-through or video see-through, allowing the user to see the real world through the display with virtual objects appearing to be fixed in real locations or on real surfaces.

0073For example, a virtual object <b>14</b> may resemble a flat screen television and may be connected to or “anchor” to a real world object or a real world wall <b>16</b>, as illustrated in <figref idref="DRAWINGS">FIG. 1</figref>. As the user moves his or her head, the virtual object <b>14</b> normally would move on the display <b>10</b> with the user's field of vision. However, in this embodiment the virtual object <b>14</b> appears to remain on the anchor surface <b>16</b>, similar to how a real world flat panel display would remain on a surface if the user turned his or her head.

0074In an embodiment, users may move the anchor surface <b>16</b> in a manner similar to how the user selected the first anchor surface. The user may discover that for a certain task that a different anchor surface will be preferable. The head mounted device <b>10</b> may receive a second input (gesture, audio, from an input device, etc.) indicating a new or a second anchor surface <b>16</b> within the image that is different from the first anchor surface <b>16</b>. The second anchor surface <b>16</b> may correspond to a second different surface located in the image. Further, the first and second anchor surfaces may not be adjacent and the first surface may not be in view of the head mounted device cameras when the second/alternative surface is designated. For example, one surface might be a desktop <b>16</b> as shown in <figref idref="DRAWINGS">FIG. 2</figref>, while another surface may be a horizontal wall <b>16</b> or a ceiling as shown in <figref idref="DRAWINGS">FIG. 1</figref>. For example, a first user may select a first anchor surface <b>16</b> for personal usage and then select a second anchor surface <b>16</b> for a second user in a different geographic location. In an embodiment, the user inputs may be voice inputs, inputs provided using a tangible input device (keyboard or mouse), detected gestures, or may be provided by different users. A processor within or coupled to the head mounted device <b>10</b> may calculate parameters, including distance and orientation with respect to the head mounted or body mounted camera that corresponds to the second anchor surface <b>16</b>. The processor within or coupled to the head mounted device <b>10</b> may then display the generated virtual object <b>14</b> so the virtual object appears to the user to be anchored to the selected second anchor surface <b>16</b>. In another embodiment, instead of or in addition to a head mounted device <b>10</b>, a pico projector may be used to project a virtual object <b>14</b> onto the selected anchor surface <b>16</b>. The pico projector may be a separate modular device, and or may be included within the head mounted device <b>10</b>.

0075<figref idref="DRAWINGS">FIG. 1</figref> illustrates a user using a head mounted device <b>10</b>. The head mounted device <b>10</b> may enable the user to designate nearby surfaces, such as a wall <b>12</b>, as a virtual “flat panel screen” <b>16</b>. The user may identify a nearby surface <b>16</b> using an input command. When multiple users are equipped with head mounted devices <b>10</b> connected to a common network or database, some or all of those users may see the same virtual object <b>14</b> at the same time, which enables collaboration and group discussions regarding the virtual object as if it were a real world object.

0076The processor driving the display on the head mounted device <b>10</b> may continuously update the displayed image of the generated virtual object <b>14</b> so that the virtual object <b>14</b> appears anchored to the anchor surface <b>16</b> as the user turns his/her head and moves with respect to the selected anchor surface <b>16</b>. Thus, as the user moves and walks around the room, the virtual object <b>14</b> may appear to remain fixed on the physical surface <b>16</b>. As part of maintaining this impression, the processor may modify the appearance of the virtual object <b>14</b> so that its shape, size and orientation match the user's viewing perspective of the anchor surface. Adjusting the shape, size and orientation of virtual objects may help to provide an immersive virtual or augmented reality experience. Unless the user enters a predefined specific input to move the virtual object <b>14</b> to another anchor surface, the virtual object <b>14</b> may remain static and seemingly adhered to the anchor surface. This may be beneficial for collaboration among a group of users, because the virtual object <b>14</b> may be a collaborative focal point for a conversation regardless of the location and viewing perspective of each user. For example, a first user may read media on the anchor surface or watch a presentation given by a second user. This will give the first user the appearance that the virtual object <b>14</b> is a real world or physical object similar to a flat panel screen, except that the first user may change the anchor surface <b>16</b> to a different surface or object in the room without disruption.

0077In a non-limiting example, the virtual object <b>14</b> may be a display output of a software application intended for collaboration. For example, the virtual object <b>14</b> may include text, media, television channels, movies, document word processing applications, email, video, telephone calls, social network postings, RSS feeds, etc. Such objects may be presented on the display to appear fixed to or on an anchor surface, similar to how the objects might appear on a conventional flat panel display, except that any surface may serve as the display. Additionally, the size of the virtual object anchored to a selected surface may be controlled by the user to enable the displayed object to be made larger or smaller. In another embodiment, the virtual object <b>14</b> may have a different appearance, such as being rendered on non-planar and non-rectangular surfaces, or rendered with a spherical or a seemingly three-dimensional shape. The presentation of the virtual object <b>14</b> on the head mounted display allows users to view and interact with the object as if it were a part of the physical environment. In an embodiment, the virtual object <b>14</b> may look different to each user.

0078In an embodiment, the virtual object <b>14</b> may be a three-dimensional model that is not anchored to a physical surface <b>16</b>. In this embodiment, the virtual object <b>14</b> may be a three-dimensional model that appears floating in space. In this embodiment, the user may view the displayed virtual object <b>14</b> in free space with the virtual object <b>14</b> anchored to a selected three-dimensional position in free space which may be relative to walls, floors, furniture etc. In this embodiment, when the virtual object <b>14</b> is anchored to a particular location in space, the object will not appear to move as the user moves his/her head and moves around the anchor location, and thus around the virtual object. For example, the virtual object <b>14</b> may be presented on the partially transparent display so that it appears anchored in free space at a predetermined 3-D coordinate. In this embodiment, the display may display a prompt for the user to input a place or coordinates at which the system should display the virtual object <b>14</b> as free floating. The processor may recognize an input command via a detected gesture (e.g., a finger pointing to a point in space) or may recognize an audio command to place the virtual object <b>14</b> as free floating in free space. The processor may display the virtual object <b>14</b> anchored to the indicated spatial point, or may connect the virtual object <b>14</b> to a position of the head mounted display so the virtual object <b>14</b> has the illusion of floating in space. As the user moves relative to the virtual object <b>14</b> in free space, the perspective, size, and orientation of the virtual object <b>14</b> may also change accordingly. For example, the virtual object <b>14</b> may be anchored to empty space located adjacent to the wall or outside floating above the ground and outside of a window. In this manner, users may inspect all sides of the virtual object <b>14</b> by walking around the free floating virtual object <b>14</b> in the room.

0079In the various embodiments, the input to anchor the virtual object <b>14</b> on a selected anchor surface or point in space may be provided in a number of different ways. For example, the camera associated with the head mounted device <b>10</b>, or a second camera operatively connected to the head mounted device <b>10</b> may also track movements of the user. The processor may receive the images and may apply a detection algorithm to the tracked movements to detect a predetermined gesture made by the user. For example, the user may point to a surface, which the system may interpret as a specific input to the processor.

0080For example, the user may indicate with a gesture that a particular real world surface in the room is intended to be an anchor surface. The processor may execute a command corresponding to the predetermined gesture when the predetermined gesture is detected. For example, the processor may detect that a user is pointing to a particular surface. The processor may detect the surface and determine an angle of the surface with respect to the line of sight of the user, and anchor the virtual object <b>14</b> on the particular surface where the user pointed with an orientation and perspective consistent with the determined angle of the surface.

0081For example, the user may point to a desktop surface. The processor may be tracking the user's movements and may apply a detection algorithm to the tracked images. When the system images the user's arm outstretched with the index finger pointing and the remaining digits forming a fist, the processor may recognize such an image as user gesture and apply a corresponding command to anchor the virtual object <b>14</b> on the desktop where the user is pointing. For example, if the end of a user's finger contacts a surface to identify it as the anchor surface, the head mounted device may display the virtual object <b>14</b> as anchored to that surface.

0082In another example, a user may desire to move the virtual object <b>14</b> to “place” it on a different anchor surface <b>16</b>. To accomplish this, the user may provide or execute a second predetermined gesture that a processor coupled to the head mounted device <b>10</b> may recognize. The second predetermined gesture may be the same as that used to designate the first anchor surface, such as a general command to designate a surface within the captured image as an anchor surface <b>16</b>, or may be a different gesture. Many different gestures can be made and are within the scope of the present disclosure. For example, the detected predetermined gesture may be an “OK” sign, a fist, an open hand, pointing with one finger, pointing with two fingers, pointing with three or four fingers, an outstretched hand, a hand rotation, a wave, a movement of one or more fingers, a movement of a body part (e.g., movement of a foot), or other arbitrary movements.

0083Also, designation of an anchor surface <b>16</b> and other inputs or commands may be provided verbally with the input received by a microphone on or coupled to the head mounted device <b>10</b> or coupled to the processor in turn coupled to the head mounted device. The processor within or coupled to the head mounted device may receive audio signals from the microphone, and may process such signals using speech recognition processes. The processor may compare received audio signals to audio patterns of one or more commands stored in a memory in order to recognize a spoken command. For example, the processor may monitor audio inputs for a few predetermined command words. In this manner, the user may speak with colleagues and other networked users, such as to discuss virtual objects, without saying a command keyword. The processor may apply a detection algorithm to the received audio so that it only responds to particular predefined audio commands, or commands proceeded by a predefined attention command (e.g., “computer” or “execute” etc.). For example, the user may say “anchor image on desk” to cause the processor to anchor the virtual object to a desk within the field of view of the head mounted device camera. The processor within or coupled to the head mounted device <b>10</b> may recognize these spoken words as a command input, and implement corresponding actions to anchor the virtual object <b>14</b> “on” the desk or anchor surface <b>16</b>.

0084In another embodiment, the processor may be programmed to detect command inputs, but then wait for a confirmation prior to implementing any command. This confirmation may be advantageous to avoid inadvertently moving a virtual object <b>14</b> by an unintentional gesture or by an inadvertent audio command during a group collaboration regarding the object. In this embodiment, the virtual object <b>14</b> will not be placed, moved or anchored to a surface in response to a command unless a confirmation or confirming command is received. For example, the processor may process images from a camera to identify gesture commands and/or audio signals received from a microphone to identify spoken commands, such as a single word or a sentence. When a gesture or spoken command is recognized, the processor may prompt the user to confirm the command and await confirmation input, which may be in the form of a button press, a spoken word, a physical gesture, or combinations thereof. When the processor recognizes the appropriate confirmation or confirming command, it may execute the command associated with the first recognized gesture or audible command. If the confirmation command is not received, the processor may ignore the detected gesture or audible command.

0085In another embodiment, a mobile computing device, such as a smartphone with camera may operate as a ‘magic lens’ for users that are not wearing a head mounted display. In this embodiment, a user with a computing device connected to a system via a wireless data link may view the virtual objects on the device's display. This allows those users without a head mounted device to view the virtual objects and structures in the image, such as the anchor surface, in a manner similar to the way it appears on head mounted displays. For example, a first user may view a virtual object <b>14</b> connected to a wall on a head mounted display which communicates the image data to a second user's smartphone or PDA display so the second user may view the virtual object <b>14</b> as it appears anchored on a wall or other surface. In another embodiment, modular pico projectors may be linked to a mobile device and used to project images of virtual objects.

0086In various embodiments, the head mounted devices <b>10</b> include wireless communication capabilities which enable exchanging of data between two or more devices to enable two or more users to interact with and collaborate on documents, files and virtual objects. In this manner, the head mounted devices <b>10</b> can facilitate collaboration by multiple users over virtual objects, such as providing a virtual or augmented reality experience enabling users to interact with and view three-dimensional virtual objects from various perspectives. To enable such a collaboration experience, the head mounted devices <b>10</b> may transmit to each other three-dimensional virtual object models and/or data sets for rendering on their respective displays. The head mounted devices <b>10</b> may also receive data files, such as coordinate maps and three-dimensional virtual object models and/or data sets from other computing devices, such as network servers. Also, image data generated by one or more of the head mounted devices involved in a collaboration may be transmitted to and displayed on head mounted devices or other mobile devices such as smartphones or tablet computers used by non-participants, enabling others to view the collaboration in a virtual or augmented reality experience. Others viewing a collaboration session wearing head mounted devices or using another mobile device such as a smartphone or tablet may not only see the virtual objects and user interactions with them, but have limited interaction capabilities with the virtual augmentations seen by one of the head mounted device users. This limited interaction may include touching the augmentation to cause an effect, defining an interactive area or anchor point on the physical surface (effectively adding a new augmentation to the shared experience), and interacting with the shared mixed reality scene via gestural and/or audio inputs. Any of such changes in the virtual experience may be reflected in the head mounted displays worn by the other users.

0087<figref idref="DRAWINGS">FIG. 2</figref> illustrates two users using first and second head mounted devices <b>10</b><i>a</i>, <b>10</b><i>b </i>to view virtual objects anchored to a surface, such as a desk table top <b>16</b>. In the illustrated example, the anchor surface <b>16</b> corresponds to the desk top surface <b>16</b>, which is located within the image displayed by the first head mounted device <b>10</b><i>a</i>. The head mounted device <b>10</b><i>a </i>may generate a virtual object <b>14</b><i>a</i>, which is shown as a virtual screen in this illustration, and display the virtual object <b>14</b><i>a </i>as if it were connected to the desk top surface <b>16</b>. If the first user looks to the left, to the right or rearward, the virtual object <b>14</b><i>a </i>will not travel within the field of view of the head mounted device <b>10</b><i>a</i>, and instead will remain displayed on the desktop surface <b>16</b> anchored in place. For example, the virtual object <b>14</b><i>a </i>will no longer appear within the head mounted device screen if the first user looks away from the anchor surface <b>16</b>. Also, the virtual object <b>14</b><i>a </i>may be presented to the first user in the orientation, shape and size, as it would appear if the anchor surface <b>16</b> were a flat panel display. Thus, the virtual object <b>14</b><i>a </i>may be displayed with a shape and size resulting from projecting the object's shape onto the anchor surface from the user's perspective. To accomplish this, the processor within or coupled to the head mounted device <b>10</b><i>a </i>may calculate shape parameters including distance and orientation with respect to the head mounted or body mounted camera <b>10</b><i>a </i>and distance sensors in order the generate a virtual object image at or on the anchor surface. Such calculations may implement well known vector projection algorithms to yield the image that is presented in the head mounted display. By applying vector processing of the image consistent with normal experience (e.g., normal Euclidean geometric projections) and presenting the resulting virtual object <b>14</b><i>b </i>on a semitransparent display that also enables the user to see objects beyond the display, the result can fool the senses of the user so the virtual objects appear to behave as real objects.

0088For collaborative purposes, a second user may wear a second head mounted device <b>10</b><i>b </i>to view the same virtual object within the same physical space. The processor within or coupled to the second head mounted device <b>10</b><i>b </i>may render the virtual object on a user-selected anchor surface <b>16</b>. The second head mounted device <b>10</b><i>b </i>may display the virtual object <b>14</b><i>b </i>on the same anchor surface or position as designated for the first head mounted device <b>10</b><i>a</i>. The second user may also designate a different position or anchor surface for rendering the virtual object <b>14</b><i>b </i>as seen through the second head mounted device <b>10</b><i>b</i>. In order to enable the second head mounted device <b>10</b><i>b </i>to properly render the virtual object <b>14</b><i>b </i>on the anchor surface from the second user's perspective, the data transmitted from the first head mounted device to the second head mounted device may include the shape or object data. This data may enable the second head mounted device processor to render a displayed image of the virtual object corresponding to the second user's viewing perspective. The virtual object data may be in the form of a geometric model, coordinates and fill data, or similar rendering data that may be used in a three-dimensional object rendering module implemented in a processor within the second head mounted device <b>10</b><i>b. </i>

0089In some implementations or situations, the second head mounted device <b>10</b><i>b </i>may receive image data from the first head mounted device <b>10</b><i>a </i>showing the virtual object anchored to the anchor surface <b>16</b>. In such cases, the processor within or coupled to second head mounted device <b>10</b><i>a </i>may receive video data generated by the first head mounted device <b>10</b><i>a </i>via a wireless data link, and simply display the received video data as output video images. In this application, the second user views the scene and the anchored virtual object <b>14</b><i>a </i>on the second head mounted display from the first user's perspective. Thus, in this implementation the second user may experience the first user's viewing experience like a movie or TV video. This first-user-perspective may be very useful in some situations, such as when the first user is showing the second user how to do something for training or the second user is supervising the activities of the first user. In this situation, the data sent over the data link may be a simple video and audio stream, and the second head mounted device may simply project the received image onto the head mounted display with further processing or rendering of virtual objects. As described below, the video and image data from the first head mounted device may also be transmitted (e.g., via a network, server or peer-to-peer wireless data link) to other computing devices, such as smartphones, tablet computers, laptop computers or large video displays, to enable others to view and share in the virtual/augmented reality experience of the first user.

0090The second head mounted device <b>10</b><i>b </i>may display the virtual object <b>14</b><i>b </i>on the desk top surface <b>16</b>. Alternatively, the second user may designate another anchor surface on which the virtual object <b>14</b> should be displayed. When the virtual object <b>14</b><i>a </i>is displayed on the first anchor surface <b>16</b>, the second head mounted device <b>10</b><i>b </i>may modify the size and shape of the object so that it appears appropriate for the second user's perspective. For example, if two users are viewing the same object on either side of a table or desk, the object may appear upside down to one of the users, just as if it were a real object. Alternatively, both users may view the same object in the same manner, so that both view the object right side up.

0091For example, if the second user <b>10</b><i>b </i>moves closer to the desktop anchor surface <b>16</b>, the virtual object <b>14</b><i>b </i>may become larger. If the second user <b>10</b><i>b </i>moves further from the desktop anchor surface <b>16</b>, the virtual object <b>14</b><i>b </i>may become smaller. Further, if the second user <b>10</b><i>b </i>rotates the display relative to the horizontal, the virtual object <b>14</b><i>b </i>may similarly compensate for the rotation to appear anchored to the desktop anchor surface <b>16</b>. As a further example, the user may move with his/her arms and hands in a manner that appears to interact with the object <b>14</b><i>b </i>in order to close it or remove it from the display, such as sweeping an arm as if to brush the virtual object aside, closing fingers around the virtual object, or punching the virtual object <b>14</b><i>b</i>. As a further example, a second user <b>10</b><i>b </i>may execute gestures that attempt to pull or push the virtual object <b>14</b><i>b </i>and this pulling or pushing can be interpreted as an input command. As mentioned above, recognizable gestures may be stored in a gesture dictionary which may store movement data or patterns for recognizing gestures that may include pokes, pats, taps, pushes, guiding, flicks, turning, rotating, grabbing and pulling, two hands with palms open for panning images, drawing (e.g., finger painting), forming shapes with fingers (e.g., an “OK” sign), and swipes, all of which may be accomplished on or in close proximity to the apparent location of a virtual object in a generated display. In this manner, users may interact with a virtual object <b>14</b><i>b </i>anchored to a surface <b>16</b> using gestures that would be suitable for a real world object, thereby making interactions with virtual objects intuitive and easy to learn.

0092In an embodiment described in more detail below, the head mounted displays may be replaced by projectors so that the images are projected onto a surface. In such an embodiment, the operations and experience of the users may be similar to using head mounted displays as discussed above. Also, as new image presentation technologies are developed, such technologies may be implemented with the various embodiments to render virtual objects in conjunction with real world anchor surfaces and viewed by user from their perspectives.

0093<figref idref="DRAWINGS">FIG. 3</figref> illustrates the virtual object <b>14</b><i>a </i>presented to two users wearing head mounted devices <b>10</b><i>a</i>, <b>10</b><i>b </i>so the virtual object appears to each user upside up (i.e., not upside down) even though the two users are facing each other. This self-orientation of the virtual object allows both users to view the object data (e.g., a bar chart) correctly.

0094As mentioned above, this presentation of the virtual object <b>14</b><i>a</i>, <b>14</b><i>b </i>may be accomplished by the head mounted device <b>10</b><i>a </i>capturing an image of the table <b>16</b> utilizing a head mounted or body mounted camera. The image may be displayed in the head mounted display <b>10</b><i>a</i>, or the table may be viewed through a semi-transparent display. The virtual object <b>14</b><i>a </i>for a first user may be displayed on the head mounted device <b>10</b><i>a</i>. The first user may formulate a signal using the first head mounted device <b>10</b><i>a </i>indicating that a second virtual object <b>14</b><i>b </i>should be generated for a second user. The first user may also provide an input indicating the anchor surface <b>16</b> in the captured image. The processor within or coupled to the head mounted device <b>10</b><i>a </i>may calculate parameters including distance and orientation with respect to the head mounted or body mounted camera <b>10</b><i>a </i>that corresponds to the anchor desk top surface <b>16</b> that was selected by the first user. The head mounted device <b>10</b><i>a </i>displays the generated virtual object <b>14</b><i>a </i>so the virtual object <b>14</b><i>a </i>is anchored to the anchor surface <b>16</b> and include the first orientation. The first virtual object <b>14</b><i>a </i>may then be displayed by the display on the first head mounted display <b>10</b><i>a </i>as if connected to the first anchor surface <b>16</b><i>a. </i>

0095In <figref idref="DRAWINGS">FIG. 3</figref>, a second user wearing a second head mounted device <b>10</b><i>b </i>sits across from the first user. The second head mounted device <b>10</b><i>b </i>may either receive an input to select the desktop to be the anchor surface <b>16</b> or may receive data from the first head mounted device <b>10</b><i>a </i>identifying the selected anchor surface <b>16</b>. Using this information the second head mounted device <b>10</b><i>b </i>may generate a display of the virtual object <b>14</b><i>b </i>reoriented to appear right side up and with the proper perspective for the second user. To generate this display, the second head mounted device <b>10</b><i>b </i>may receive data regarding the virtual object to be rendered, such as its content and data regarding its general shape and orientation. The second head mounted device <b>10</b><i>b </i>may use the anchor surface selected by the first user (or another anchor surface selected by the second user) to determine a location, orientation and perspective for displaying the virtual object. This may include determining a proper top of the object, and an angle of projection of the object to match the anchor surface that results in the proper perspective of the rendered object. Thus, as illustrated in <figref idref="DRAWINGS">FIG. 3</figref>, the second user views the same virtual object <b>14</b><i>b </i>anchored to the desk top surface <b>16</b> but right side up from the second user's perspective.

0096In an alternative embodiment, first head mounted device <b>10</b><i>a </i>or another computing device in communication with both head mounted device may determine the proper orientation and perspective of the virtual object <b>14</b><i>b </i>for the second head mounted device <b>10</b><i>b</i>. In this case, the first head mounted device <b>10</b><i>a </i>may receive information sufficient to enable the device to determine an orientation of the second user or of the second head mounted device <b>10</b><i>b</i>. For example, images of the second user may be captured by cameras on the first head mounted device and processed using anatomical models to determine the second user's position and viewing perspective. The first head mounted device <b>10</b><i>a </i>may then transmit the virtual object data to the second head mounted device in a manner that correctly orients the virtual object <b>14</b><i>b </i>for the second user <b>10</b><i>b </i>based on the determined user orientation.

0097In various embodiments, the second user may provide inputs to the second head mounted device <b>10</b><i>b </i>to control or change the orientation, size, and shape (e.g., perspective) of the virtual object <b>14</b><i>b</i>. For example, the second user utilizing a detected gesture input command may drag the corners of the virtual object <b>14</b><i>b </i>to make it larger or smaller. As another example, the second user may minimize the virtual object <b>10</b><i>b </i>and open a new application or virtual object.

0098As illustrated in <figref idref="DRAWINGS">FIG. 4</figref> two users viewing the same virtual object need not be in the same room. For example, a first user wearing a first head mounted device <b>10</b><i>a </i>at a first location, for example, Cambridge, United Kingdom, may view a virtual object <b>14</b><i>a </i>(e.g., a presentation or graph) anchored on a first anchor surface <b>16</b><i>a </i>(e.g., a wall) and collaborate regarding the virtual object with a second user wearing a second head mounted device <b>10</b><i>b </i>at a second location, for example, San Diego, Calif., who may view the virtual object <b>14</b><i>b </i>anchored to a very different anchor surface <b>16</b><i>b</i>, such as a table top. The head mounted device <b>10</b><i>a </i>may communicate with the second head mounted device <b>10</b><i>b </i>via any computer network known in the art that interconnects the devices <b>10</b><i>a </i>and <b>10</b><i>b </i>and that allows users to share resources by wired and wireless communication links.

0099For example, the first head mounted device <b>10</b><i>a </i>may transmit via a communication network a signal correctly orienting the second virtual object <b>14</b><i>b </i>for the second head mounted device <b>10</b><i>b </i>and a signal generating the oriented second virtual object <b>14</b><i>b </i>for the second user <b>10</b><i>b</i>. The second head mounted device <b>10</b><i>b </i>may receive the signal from the communication network and may generate the second virtual object <b>14</b><i>b </i>for the second user <b>10</b><i>b. </i>

0100In another embodiment, images of the first and/or second users can be captured over time by the head mounted or body mounted camera and used to determine an appropriate orientation for virtual objects. An anatomical analysis can be applied to the captured images to determine the current posture and orientation of the user, such as with respect to a designated anchor surface. For example, the images may be compared to anatomical data stored in memory to detect a body part within the images and determine an orientation of the user. The second virtual object <b>14</b><i>b </i>for the second head mounted device <b>10</b><i>b </i>may be oriented correctly based on the detected body part in the images of either the first user (i.e., to present the image to the second user in the manner it appears to the first user) or the second user (i.e., to present the image in a manner suitable for the second user's posture). For example, images of the second user may be captured, tracked and compared to anatomical data stored in memory where the second user's head, shoulders, arms, torso, legs or any other body part or a portion thereof may be detected. The second head mounted device <b>10</b><i>b </i>may orient the virtual object based on the detected body parts. The second virtual object <b>14</b><i>b </i>may be oriented in the first orientation and displayed.

0101A time period later, the second user may move and the first orientation may not be appropriate based on the different orientation and the user's new location. For example, parameters may be calculated including distance and orientation with respect to the second head mounted or body mounted camera <b>10</b><i>b </i>that correspond to the second anchor surface <b>16</b><i>b </i>with the recognized object located in the image. An image size and an orientation may be determined that correspond to the determined orientation for the second virtual object <b>14</b><i>b </i>after such a movement. The second head mounted device <b>10</b><i>b </i>may then display the generated second virtual object <b>14</b><i>b </i>so the second virtual object <b>14</b><i>b </i>appears anchored and connected to the second anchor surface <b>16</b><i>b</i>. For example, the detected body part may be utilized to determine where the second user is looking and the second virtual object <b>14</b><i>b </i>may be oriented correctly based on where the second user is looking.

0102In another embodiment, the detected body parts may be utilized to determine whether the second user is sitting or standing. Based on the determination, the second virtual object <b>14</b><i>b </i>may be generated to be anchored to and oriented on a planar surface adjacent to the second user. If it is determined based on the detected body part that the second user is standing, the second virtual object <b>14</b><i>b </i>may be generated on a vertical surface adjacent to the second user.

0103In the illustration of <figref idref="DRAWINGS">FIG. 4</figref>, the anchor surface <b>16</b><i>a </i>is a wall located within the image displayed by the head mounted device <b>10</b><i>a</i>. For the first user, the head mounted device <b>10</b><i>a </i>may generate a virtual object <b>14</b><i>a </i>and display the virtual object <b>14</b><i>a </i>as though fixed or connected to the wall surface <b>16</b> and oriented so that it is right side up for the first user. The head mounted device <b>10</b><i>a </i>processor may calculate parameters for rendering the virtual object including distance and orientation from the head mounted device <b>10</b><i>a </i>to the wall <b>16</b> selected by the first user as the anchor surface. The head mounted device <b>10</b><i>a </i>may include or be coupled to a mobile CPU that is coupled to a transceiver configured to communicate with a router to communicate data via a network, such as the Internet, to the second head mounted device <b>10</b><i>b</i>. Similarly, the second head mounted device <b>10</b><i>b </i>may also include a transceiver to communicate with a network to send/receive data via a network, such as the Internet, an intranet, a wireless network, or any other appropriate telecommunications network.

0104Either of the first and second head mounted devices <b>10</b><i>a</i>, <b>10</b><i>b </i>may initiate a collaboration session and send a request for such a session to the other via a network, such as the Internet, such as by sending messages to the IP address associated with the other head mounted device. In another embodiment, the head mounted device <b>10</b><i>a </i>may communicate with the second head mounted device <b>10</b><i>b </i>via a server that includes program instructions to execute a service to share resources among the two devices <b>10</b><i>a </i>and <b>10</b><i>b. </i>

0105As an example, a collaboration session between a first and second user both equipped with head mounted devices may proceed as follows. When an asset or virtual object is added or anchored to a surface by one user, that user's head mounted device may transmit a message to the other user's head mounted device indicating a preferred placement of the new asset or object in a manner that is relative to an existing asset or virtual object already displayed on a previously selected anchor surface. This preferred placement of the new asset or object may then be overridden by the system automatically or users through user inputs (e.g., recognized movement gestures) if there is inadequate space for both objects on the original anchor surface. Also or alternatively, one or both of the users may execute an input or gesture in order to manually reposition the new asset or virtual object to position or surface of their preference.

0106In another embodiment, the first head mounted device <b>10</b><i>a </i>may deliver a message to the second head mounted device <b>10</b><i>b </i>data indicating a preferred or suggested placement of the virtual object <b>14</b><i>b</i>. For example, the first user may indicate that the preferred placement of the virtual object <b>14</b><i>b </i>should occur on a desk <b>16</b><i>b </i>or on a wall. For example, a message may be sent from the first head mounted device <b>10</b><i>a </i>indicating “Wall Surface Preferred” or “Desktop Surface Preferred” to the second head mounted device <b>10</b><i>b</i>. The second head mounted device <b>10</b><i>b </i>may generate a second virtual object <b>14</b><i>b </i>on the display. The message may also include one or more program instructions to correctly orient the virtual object <b>14</b> for the second user. The second head mounted device <b>10</b><i>b </i>may receive an input to select the desktop as the anchor surface <b>16</b><i>b </i>or may receive data from the first head mounted device <b>10</b><i>a </i>that the anchor surface <b>16</b> is selected as a wall. In the case of the latter alternative, a processor within or coupled to the second head mounted device <b>10</b><i>b </i>may detect a comparable wall within images obtained by a camera on the device. Program instructions may also be communicated to the processor for the user to accept or reject the suggested anchor surface from another user. The head mounted display <b>10</b><i>b </i>may receive an input command from the second user in the form of a spoken audio signal to accept or to reject the suggested anchor surface. The second head mounted device <b>10</b><i>b </i>may receive the message indicating a preferred placement of the second virtual object <b>14</b><i>b </i>and the second user may provide an input to the second head mounted device <b>10</b><i>b </i>confirming or rejecting the preferred placement of the second virtual object <b>14</b><i>b</i>. For example, the second user may provide an input indicating a desire to rotate and reorient the second virtual object <b>14</b><i>b</i>. The processor may determine distance and orientation based on the input for the second virtual object <b>14</b> and may generate the second virtual object <b>14</b><i>b </i>with the desired orientation.

0107The second head mounted device <b>10</b><i>b </i>may display the virtual object <b>14</b><i>b </i>on the desk top surface <b>16</b><i>b </i>at the second location. The second user may further provide inputs to change the orientation, size, and shape of the virtual object <b>10</b><i>b </i>to suit the anchor surface <b>16</b><i>b</i>. The virtual object <b>14</b><i>b </i>appears the same virtual object <b>14</b><i>a </i>and collaboration may occur between the users. Changes made at one location by one user may update and be shown at both the first and the second locations, i.e., changes to virtual object <b>14</b><i>a </i>in one location will be reflected in the virtual object <b>14</b><i>b </i>displayed in the other location. For example, the second user may delete a bar chart on the virtual object <b>14</b><i>b </i>and the same bar chart on the virtual object <b>10</b><i>a </i>may also be deleted at the first location.

0108In yet another embodiment, a third user wearing a third head mounted device may join in the collaboration and anchor a displayed virtual object on a surface selected by the third user or suggested by either of the first or second users. Also, as described above, image data generated by one or more of the head mounted devices involved in a collaboration may be transmitted to and displayed on other head mounted devices or other computing devices, such as smartphones or tablets used by non-participants. This embodiment enables others to view the collaboration in a virtual or augmented reality experience. Others viewing a collaboration session wearing head mounted devices or using another mobile device such as a smartphone or tablet computer may not only see the virtual objects and user interactions with them, but have limited interaction capabilities with the virtual augmentations seen by one of the head mounted device users. This limited interaction may include touching the augmentation to cause an effect, defining an interactive area or anchor point on the physical surface (effectively adding a new augmentation to the shared experience), and interacting with the shared mixed reality scene via gestural and/or audio inputs. Any of such changes in the virtual experience may be reflected in the head mounted displays worn by the other users.

0109In an embodiment, the second user wearing the second head mounted device <b>10</b><i>b </i>may provide an input to summon a new virtual object from a personal data space (e.g., cloud or mobile device) and add the new virtual object to a shared display so the first user also sees it in the first head mounted device <b>10</b><i>a</i>. In an embodiment, the first head mounted device <b>10</b><i>a </i>may receive a prompt which informs the user that a third virtual object is present and requests a user input or command to accept and display the third virtual object. The user may select a new physical surface to anchor the new virtual object to, or may accept the anchor surface selected by the second user.

0110In an embodiment, the processor within or coupled to the head mounted device <b>10</b><i>a </i>may receive an input indicating a standby location for a virtual object <b>14</b>. The standby location may be a location where an initial condition of the virtual object <b>14</b> can be displayed as not anchored or fixed to a real world surface. The standby location may be a location where the virtual object <b>14</b> is “free floating” on the display unconnected to a real world object. Alternatively, the standby location can be a different anchor surface <b>16</b> located in the image, for example, on a ceiling, or a repeated and familiar location for the user. The standby location may be a place or surface where the object can be “stored” until the user takes further action to anchor the virtual object <b>14</b> to an anchor surface. The processor within or coupled to the head mounted device <b>10</b><i>a </i>may calculate parameters including distance and orientation with respect to the head mounted or body mounted camera that corresponds to the standby location and the processor may display the virtual object <b>14</b> with the proper perspective for the standby location. The standby location may be displayed as free floating and may appear to be movable and unconnected to surfaces in the image as the user turns his/her head and moves about the room.

0111In an embodiment, the processor within or coupled to the head mounted device <b>10</b><i>a </i>may capture an image with a head mounted or body mounted camera or cameras which may be full-color video cameras. Distances to objects within the imaged scene may be determined via trigonometric processing of two (or more) images obtained via a stereo camera assembly. Alternatively or in addition, the head mounted device may obtain spatial data (i.e., distances to objects in the images) using a distance sensor which measures distances from the device to objects and surfaces in the image. In an embodiment, the distance sensor may be an infrared light emitter (e.g., laser or diode) and an infrared sensor. In this embodiment, the head mounted device may project infrared light as pulses or structured light patterns which reflect from objects within the field of view of the device's camera. The reflected infrared laser light may be received in a sensor, and spatial data may be calculated based on a measured time or phase shift between the emitted and received light. In another embodiment, the distance sensor may be an ultrasound emitter and receiver. In this embodiment, the head mounted device may emit ultrasound pulses, which reflect from objects within the field of view of the device's camera. An ultrasound receiver senses reflected ultrasound, and calculates spatial data based on a measured time between sound emissions and received reflected ultrasound. In a third embodiment, distances to objects may be estimated by measuring changes in angles in subsequent images in a video stream as the user's head moves and applying trigonometric analyses to the sequence of images. By including motion and/or relative position sensors in the head mounted device, changes in viewing angle may be correlated to changes in camera position, from which object/surface distances and locations may be calculated using trigonometric algorithms. Any combination of these distance-measuring methods may be combined to further refine the distance measurements obtained by the head mounted device.

0112In an embodiment, the processor within or coupled to the head mounted device <b>10</b> may store the spatial data in memory and may build a three-dimensional map of objects and surfaces within the vicinity of the device based on the captured video and the measured or calculated spatial data. This three-dimensional map may be shared with other head mounted devices within the vicinity or connected via a network, and/or uploaded to a server. Sharing such three-dimensional map data may assist other head mounted devices <b>10</b><i>b </i>(or more specifically the processors within or coupled to the other head mounted devices) to render virtual objects anchored to a designated anchor surface without having to image and process the room. Sharing of such three-dimensional map data may also enable multiple head mounted devices to collaboratively create an overall map of the vicinity of the multiple users, and reduce the workload imposed on any one head mounted device by avoiding the need to scan the same environment multiple times (i.e., the three-dimensional map only needs to be generated once). In a further application, the sharing of image and spatial data, such as a three-dimensional map of objects in the vicinity of a first user, may enable other users to view the same images as the first user even when they are located far away. For example, a second device may utilize the map where data can be transmitted that corresponds to captured spatial data so another user wearing a second head mounted device may display the virtual object <b>14</b> in the same manner as the first user.

0113As explained above, the display associated with the head mounted device <b>10</b><i>a </i>or <b>10</b><i>b </i>may be partially transparent or may substantially occlude all or a portion of the user's view. In another embodiment, the head mounted device <b>10</b><i>a </i>display may be positioned over only one eye so that it occludes only a portion of the user's vision, such as in the form of a monocular display so one user's eye is able to view the room unobstructed. In another embodiment, the head mounted device <b>10</b><i>a </i>or <b>10</b><i>b </i>may output the virtual object <b>14</b><i>a </i>or <b>14</b><i>b </i>content to a computing device display so that the images obtained by the head or body mounted cameras and any virtual objects may be viewed together on a conventional computer display.

0114As mentioned above, the head mounted displays may be replaced by projectors that project images onto a surface, or by other image generation technologies that may be developed. In such an embodiment, the operations and experience of the users may be similar to that using head mounted displays as discussed above.

0115<figref idref="DRAWINGS">FIG. 5A</figref> illustrates components that may be included in embodiments of head mounted devices <b>10</b>. <figref idref="DRAWINGS">FIG. 5B</figref> illustrates how head mounted devices <b>10</b> may operate as part of a system in which a sensor array <b>500</b> may provide data to a mobile processor <b>507</b> that performs operations of the various embodiments described herein, and communicates data to and receives data from a server <b>564</b>. It should be noted that the processor <b>507</b> head mounted device <b>10</b> may include more than one processor (or a multi-core processor) in which a core processor may perform overall control functions while a coprocessor executes applications, sometimes referred to as an application processor. The core processor and applications processor may be configured in the same microchip package, such as a multi-core processor, or in separate chips. Also, the processor <b>507</b> may be packaged within the same microchip package with processors associated with other functions, such as wireless communications (i.e., a modem processor), navigation (e.g., a processor within a GPS receiver), and graphics processing (e.g., a graphics processing unit or “GPU”).

0116The head mounted device <b>10</b> may communicate with a communication system or network that may include other computing devices, such as personal computers and mobile devices with access to the Internet. Such personal computers and mobile devices may include an antenna <b>551</b>, a transmitter/receiver or transceiver <b>552</b> and an analog to digital converter <b>553</b> coupled to a processor <b>507</b> to enable the processor to send and receive data via a wireless communication network. For example, mobile devices, such as cellular telephones, may access the Internet via a wireless communication network (e.g., a Wi-Fi or cellular telephone data communication network). Such wireless communication networks may include a plurality of base stations coupled to a gateway or Internet access server coupled to the Internet. Personal computers may be coupled to the Internet in any conventional manner, such as by wired connections via an Internet gateway (not shown) or by a wireless communication network.

0117Referring to <figref idref="DRAWINGS">FIG. 5A</figref>, the head mounted device <b>10</b> may include a scene sensor <b>500</b> and an audio sensor <b>505</b> coupled to a control system processor <b>507</b> which may configured with a number of software modules <b>510</b>-<b>550</b>. In an embodiment, the processor <b>507</b> or scene sensor <b>500</b> may apply an anatomical feature recognition algorithm to the images to detect one or more anatomical features. The processor <b>507</b> associated with the control system may review the detected anatomical features in order to recognize one or more gestures and process the recognized gestures as an input command. For example, as discussed in more detail below, a user may execute a movement gesture corresponding to an input command, such as pointing a finger at the virtual object to close the virtual object. In response to recognizing this example gesture, the processor <b>507</b> may remove the virtual object from the display. As another example, the user may touch the forefinger to the thumb on one hand to form the “OK” sign in order to confirm an instruction or option presented on the display.

0118The scene sensor <b>500</b>, which may include stereo cameras, orientation sensors (e.g., accelerometers and an electronic compass) and distance sensors, may provide scene-related data (e.g., images) to a scene manager <b>510</b> implemented within the processor <b>507</b> which may be configured to interpret three-dimensional scene information. In various embodiments, the scene sensor <b>500</b> may include stereo cameras (as described below) and distance sensors, which may include infrared light emitters for illuminating the scene for an infrared camera. For example, in an embodiment illustrated in <figref idref="DRAWINGS">FIG. 5A</figref>, the scene sensor <b>500</b> may include a stereo red-green-blue (RGB) camera <b>503</b><i>a </i>for gathering stereo images, and an infrared camera <b>503</b><i>b </i>configured to image the scene in infrared light which may be provided by a structured infrared light emitter <b>503</b><i>c</i>. As discussed below, the structured infrared light emitter may be configured to emit pulses of infrared light that may be imaged by the infrared camera <b>503</b><i>b</i>, with the time of received pixels being recorded and used to determine distances to image elements using time-of-flight calculations. Collectively, the stereo RGB camera <b>503</b><i>a</i>, the infrared camera <b>503</b><i>b </i>and the infrared emitter <b>503</b><i>c </i>may be referred to as an RGB-D (D for distance) camera <b>503</b>.

0119The scene manager module <b>510</b> may scan the distance measurements and images provided by the scene sensor <b>500</b> in order to produce a three-dimensional reconstruction of the objects within the image, including distance from the stereo cameras and surface orientation information. In an embodiment, the scene sensor <b>500</b>, and more particularly an RGB-D camera <b>503</b>, may point in a direction aligned with the field of view of the user and the head mounted device <b>10</b>. The scene sensor <b>500</b> may provide a full body three-dimensional motion capture and gesture recognition. The scene sensor <b>500</b> may have an infrared light emitter <b>503</b><i>c </i>combined with an infrared camera <b>503</b><i>c</i>, such as a monochrome CMOS sensor. The scene sensor <b>500</b> may further include stereo cameras <b>503</b><i>a </i>that capture three-dimensional video data. The scene sensor <b>500</b> may work in ambient light, sunlight or total darkness and may include an RGB-D camera as described herein. The scene sensor <b>500</b> may include a near-infrared (NIR) pulse illumination component, as well as an image sensor with a fast gating mechanism. Pulse signals may be collected for each pixel and correspond to locations from which the pulse was reflected and can be used to calculate the distance to a corresponding point on the captured subject.

0120In another embodiment, the scene sensor <b>500</b> may use other distance measuring technologies (i.e., different types of distance sensors) to capture the distance of the objects within the image, for example, ultrasound echo-location, radar, triangulation of stereoscopic images, etc. As discussed above, in an embodiment, the scene sensor <b>500</b> may include a ranging camera, a flash LIDAR camera, a time-of-flight (ToF) camera, and/or a RGB-D camera <b>503</b>, which may determine distances to objects using at least one of range-gated ToF sensing, RF-modulated ToF sensing, pulsed-light ToF sensing, and projected-light stereo sensing. In another embodiment, the scene sensor <b>500</b> may use a stereo camera <b>503</b><i>a </i>to capture stereo images of a scene, and determine distance based on a brightness of the captured pixels contained within the image. As mentioned above, for consistency any one or all of these types of distance measuring sensors and techniques are referred to herein generally as “distance sensors.” Multiple scene sensors of differing capabilities and resolution may be present to aid in the mapping of the physical environment, and accurate tracking of the user's position within the environment.

0121The head mounted device <b>10</b> may also include an audio sensor <b>505</b> such as a microphone or microphone array. An audio sensor <b>505</b> enables the head mounted device <b>10</b> to record audio, and conduct acoustic source localization and ambient noise suppression. The audio sensor <b>505</b> may capture audio and convert the audio signals to audio digital data. A processor associated with the control system may review the audio digital data and apply a speech recognition algorithm to convert the data to searchable text data. The processor may also review the generated text data for certain recognized commands or keywords and use recognized commands or keywords as input commands to execute one or more tasks. For example, a user may speak a command such as “anchor virtual object” to anchor the displayed virtual object on a selected surface. For example, the user may speak “close application” to close an application displayed on the display.

0122The head mounted device <b>10</b> may also include a display <b>540</b>. The display <b>540</b> may display images obtained by the camera within the scene sensor <b>500</b> or generated by a processor within or coupled to the head mounted device <b>10</b>. In an embodiment, the display <b>540</b> may be a micro display. The display <b>540</b> may be a fully occluded display. In another embodiment, the display <b>540</b> may be a semitransparent display that can display images on a screen that the user can see through to view the surrounding room. The display <b>540</b> may be configured in a monocular or stereo (i.e., binocular) configuration. Alternatively, the head-mounted device <b>10</b> may be a helmet mounted display device, worn on the head, or as part of a helmet, which may have a small display <b>540</b> optic in front of one eye (monocular) or in front of both eyes (i.e., a binocular or stereo display). Alternatively, the head mounted device <b>10</b> may also include two display units <b>540</b> that are miniaturized and may be any one or more of cathode ray tube (CRT) displays, liquid crystal displays (LCDs), liquid crystal on silicon (LCos) displays, organic light emitting diode (OLED) displays, Mirasol displays based on Interferometric Modulator (IMOD) elements which are simple micro-electro-mechanical system (MEMS) devices, light guide displays and wave guide displays, and other display technologies that exist and that may be developed. In another embodiment, the display <b>540</b> may comprise multiple micro-displays <b>540</b> to increase total overall resolution and increase a field of view.

0123The head mounted device <b>10</b> may also include an audio output device <b>550</b>, which may be a headphone and/or speaker collectively shown as reference numeral <b>550</b> to output audio. The head mounted device <b>10</b> may also include one or more processors that can provide control functions to the head mounted device <b>10</b> as well as generate images, such as of virtual objects <b>14</b>. For example, the device <b>10</b> may include a core processor, an applications processor, a graphics processor and a navigation processor. Alternatively, the head mounted display <b>10</b> may be coupled to a separate processor, such as the processor in a smartphone or other mobile computing device. Video/audio output may be processed by the processor or by a mobile CPU, which is connected (via a wire or a wireless network) to the head mounted device <b>10</b>. The head mounted device <b>10</b> may also include a scene manager block <b>510</b>, a user control block <b>515</b>, a surface manager block <b>520</b>, an audio manager block <b>525</b> and an information access block <b>530</b>, which may be separate circuit modules or implemented within the processor as software modules. The head mounted device <b>10</b> may further include a local memory and a wireless or wired interface for communicating with other devices or a local wireless or wired network in order to receive digital data from a remote memory <b>555</b>. Using a remote memory <b>555</b> in the system may enable the head mounted device <b>10</b> to be made more lightweight by reducing memory chips and circuit boards in the device.

0124The scene manager block <b>510</b> of the controller may receive data from the scene sensor <b>500</b> and construct the virtual representation of the physical environment. For example, a laser may be used to emit laser light that is reflected from objects in a room and captured in a camera, with the round trip time of the light used to calculate distances to various objects and surfaces in the room. Such distance measurements may be used to determine the location, size and shape of objects in the room and to generate a map of the scene. Once a map is formulated, the scene manager block <b>510</b> may link the map to other generated maps to form a larger map of a predetermined area. In an embodiment, the scene and distance data may be transmitted to a server or other computing device which may generate an amalgamated or integrated map based on the image, distance and map data received from a number of head mounted devices (and over time as the user moved about within the scene). Such an integrated map data made available via wireless data links to the head mounted device processors. The other maps may be maps scanned by the instant device or by other head mounted devices, or may be received from a cloud service. The scene manager <b>510</b> may identify surfaces and track the current position of the user based on data from the scene sensors <b>500</b>. The user control block <b>515</b> may gather user control inputs to the system, for example audio commands, gestures, and input devices (e.g., keyboard, mouse). In an embodiment, the user control block <b>515</b> may include or be configured to access a gesture dictionary to interpret user body part movements identified by the scene manager <b>510</b>, As discussed above a gesture dictionary may store movement data or patterns for recognizing gestures that may include pokes, pats, taps, pushes, guiding, flicks, turning, rotating, grabbing and pulling, two hands with palms open for panning images, drawing (e.g., finger painting), forming shapes with fingers (e.g., an “OK” sign), and swipes, all of which may be accomplished on or in close proximity to the apparent location of a virtual object in a generated display. The user control block <b>515</b> may also recognize compound commands. This may include two or more commands. For example, a gesture and a sound (e.g. clapping) or a voice control command (e.g. ‘OK’ detected hand gesture made and combined with a voice command or a spoken word to confirm an operation). When a user control <b>515</b> is identified the controller may provide a request to another subcomponent of the device <b>10</b>.

0125The head mounted device <b>10</b> may also include a surface manager block <b>520</b>. The surface manager block <b>520</b> may continuously track the positions of surfaces within the scene based on captured images (as managed by the scene manager block <b>510</b>) and measurements from distance sensors. The surface manager block <b>520</b> may also continuously update positions of the virtual objects that are anchored on surfaces within the captured image. The surface manager block <b>520</b> may be responsible for active surfaces and windows. The audio manager block <b>525</b> may provide control instructions for audio input and audio output. The audio manager block <b>525</b> may construct an audio stream delivered to the headphones and speakers <b>550</b>.

0126The information access block <b>530</b> may provide control instructions to mediate access to the digital information. Data may be stored on a local memory storage medium on the head mounted device <b>10</b>. Data may also be stored on a remote data storage medium <b>555</b> on accessible digital devices, or data may be stored on a distributed cloud storage memory, which is accessible by the head mounted device <b>10</b>. The information access block <b>530</b> communicates with a data store <b>555</b>, which may be a memory, a disk, a remote memory, a cloud computing resource, or an integrated memory <b>555</b>.

0127<figref idref="DRAWINGS">FIG. 6</figref> illustrates an embodiment method <b>600</b> for rendering a virtual object on an anchored surface based on a user input. Method <b>600</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>600</b>. In method <b>600</b>, the processor may commence upon receiving data from the head mounted device sensors regarding an orientation of the head mounted device in block <b>601</b>. In block <b>602</b>, the processor may receive data from stereo cameras on the head mounted device or on the shoulders or body of the user. In block <b>603</b>, the processor may calculate distance and orientation data of objects within the received stereo image. In block <b>604</b>, the processor may process the content for display using data from the distance and orientation sensors, and the camera.

0128In determination block <b>605</b>, the processor may review user inputs or gesture commands to determine whether to anchor a virtual object in the image. For example, a user input may be received from an input device, such as a keypad or touchscreen input. As another example, a user input may be received in the form of a detected gesture recognized in a sequence of images, such as a gesture indicating a desire to anchor the virtual object on an indicated surface located within the image. A third example of a user input may be an audio command that may be received by a microphone on the head mounted device. A user input may be a command indicating that an input for anchoring the virtual object to a particular location should be received from a second user's head mounted device. For example, the input may be received from a second head mounted device <b>10</b><i>b </i>during a collaboration session.

0129If the processor determines that it has received an input to anchor the virtual object at a particular location (e.g., an anchor surface <b>16</b>) (i.e., determination block <b>605</b>=“Yes”), the processor may determine the distance and orientation of the virtual object relative to the anchor surface from the user's position in block <b>606</b>. For example, the head mounted device <b>10</b> may determine that the anchor surface <b>16</b> includes a contour and a certain distance from the user. In general, virtual objects <b>14</b> may be three-dimensional virtual objects, such as in the form of three-dimensional mathematical models (e.g., spheres, cones, cylinders, etc.), three-dimensional data sets (e.g., data tables defining vertices, dimensions, and other coordinate and material data), or combinations of both, which a processor can use to generate an image of the object. In order for the processor to be able to display the virtual object <b>14</b> connected on the anchor surface <b>16</b>, the virtual object <b>14</b> may be adjusted to a size, viewing perspective and orientation to superimpose the virtual object on the anchor surface <b>16</b>. For example, a three-dimensional virtual object will need to be rendered as a two-dimensional image to be presented on a conventional display, or as two slightly different two-dimensional images to be presented on 3D displays on a head mounted device.

0130In block <b>607</b>, the processor may process the virtual object to place the virtual object in a virtual space and with a perspective, orientation and size that causes it to appear connected to the anchored surface. In block <b>608</b>, the processor may render the virtual object on the head mounted device display.

0131For example, the display may be a semitransparent display where certain features of the image are viewable through the display. The virtual object <b>14</b> may be superimposed or added to the features of the image on the display so the virtual object <b>14</b> remains anchored to, or fixed to, the desired anchored surface as the user moves. Alternatively, the virtual object <b>14</b><i>a </i>may be anchored in free space. For example, the virtual object <b>14</b><i>a </i>may be located outside of a window, or the virtual object <b>14</b><i>a </i>may be suspended in midair or a distance above the ground.

0132If the processor determines that it has not received an input to anchor the virtual object (i.e., determination block <b>605</b>=“No”), which may indicate that the user is not ready or does not want to anchor the virtual object to an anchor surface, the processor may render the virtual object in a standby location. Alternatively, the user may choose not to render the virtual object <b>14</b> in block <b>609</b>.

0133The processes of rendering the virtual object within the scene, such as on the anchor surface, may be performed continuously so that the virtual object appears stationary even as the user turns his/her head and moves about. As mentioned above, the process of orienting the head mounted device with respect to the surroundings, and determining distances to and relative orientation of various surfaces may be accomplished continuously by monitoring orientation sensors (e.g., accelerometers and gyroscopes) and triangulating its own position and angle of view as the device moves in space by constantly referencing shifts in the topography of the scanned three-dimensional (3D) environment, thus performing Simultaneous Location and Mapping (SLAM) operations.

0134<figref idref="DRAWINGS">FIG. 7A</figref> illustrates an embodiment method <b>700</b> for rendering an image with an anchored virtual object. Method <b>700</b> may be implemented in a computing device having a processor with processor-executable instructions to perform the operations of the method <b>700</b>. In method <b>700</b>, the virtual object <b>14</b> may be anchored as the position of the user moves through an area, such as a room. For example, the user may walk and move about in the room, but the displayed location of the virtual object on a surface in the room may remain fixed. In method <b>700</b> in block <b>701</b>, the processor may commence operation by receiving user position data such as the coordinates of a user's location, information related to the user's position within a room (e.g., distances from various surfaces), and information related to an orientation of the user's head. The positional data received in block <b>701</b> may be calculated from a range of sensor data, including distance sensors (e.g., an infrared emitter/receiver configure to calculate the round trip time of emitted infrared signals bouncing off of surfaces within the viewing perspective of the user with a fast gating mechanism). Alternatively or additionally, positional data may be provided by a GPS receiver unit (which may return geographic coordinates), triangulation of RF signals from transmitters at known locations (e.g., cellular telephone towers), inputs received from a second head mounted device (e.g., providing separation distance and/or information regarding relative positions of the two users), etc. Position data may also be calculated based on scene image and distance sensor data, or downloaded from a server in a cloud computing arrangement. Alternatively or in addition, the user may input coordinates of the user's location, such as by typing in a physical address and/or a room number, or touching or clicking on a map display to indicate the user's position on the map. In block <b>702</b>, the processor may calculate distance and orientation data of objects within the received camera image. In block <b>703</b>, the processor may calculate the position of the user relative to the anchored virtual object.

0135The scene sensor <b>500</b> of <figref idref="DRAWINGS">FIG. 5A</figref> may feature a near-infrared (NIR) pulse illumination component. The scene sensor <b>500</b> may also have an image sensor with a fast gating mechanism. Other image sensors may also be implemented within the scene sensor <b>500</b> as described herein. Based on the known speed of the infrared pulses, the coordinates, and the timing of infrared pulse wave emissions from the illuminator with the gating of the sensor <b>500</b>, a signal reflected from within a desired distance range is captured. In this embodiment, the time of arrival of infrared pulses may be collected for each pixel and used to calculate the distance from the sensor to each point in the image. Such processing of the image may be performed using a remote processor that is connected to the scene sensor <b>500</b> via a computer network. The method <b>700</b> is not limited to being implemented on a head mounted display and may be used with another computing device, such as a mobile communication device (e.g., a smartphone) or a fixed computing device (e.g., a personal computer or a server) in communication with the head mounted display or body mounted sensors.

0136In determination block <b>704</b>, the processor may determine whether the position of the user or the anchor surface has changed. For example, the user may anchor the image on a surface such as a wall or in free space and the user may walk away from the wall during collaboration with another user, thus changing position. If the position has changed (i.e., determination block <b>704</b>=“Yes”) which indicates the user has moved away from the anchored virtual object or the anchor surface has moved, the processor may determine and calculate a change of the anchored virtual object based on the new position in block <b>705</b>. In block <b>706</b>, the processor may render the image with the anchored virtual object on the head mounted display. If the processor determines that the virtual object has not moved (i.e., determination block <b>704</b>=“No”), the anchored virtual object may be rendered unchanged. The processor may render the virtual object in the image for the current position on the head mounted display in block <b>706</b>.

0137<figref idref="DRAWINGS">FIG. 7B</figref> illustrates an embodiment method <b>720</b> for moving a virtual object between anchor surfaces. Method <b>720</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>720</b>. A first input may be provided anchoring a virtual object on a first anchor surface. Later, the processor may receive a second input to anchor the virtual object on a second different anchor surface. In method <b>720</b>, the processor may commence operation by capturing an image in block <b>707</b>. In block <b>708</b>, the processor may capture spatial data and recognize objects within the image. In block <b>709</b>, the processor may determine a distance parameter of the objects in the image. In block <b>710</b>, the processor may receive an input indicating an anchor surface within the image.

0138For example, the processor may receive an input from an input device, or may detect a gestural input, or may receive a voice command to anchor the virtual object <b>14</b> within the image. In block <b>711</b>, the processor may generate the virtual object <b>14</b> that is displayed, such as by using an object model and/or an object image data set. In block <b>712</b>, the processor may calculate parameters including distance and orientation corresponding to the anchor surface, and may adjust the image of the virtual object consistent with those parameters to coincide with the viewer's perspective. In block <b>713</b>, the processor may display the virtual object on the head mounted display so the virtual object appears to be connected to the anchor surface.

0139The user may choose to change the anchor surface due to a preference or needs of the collaborative process with other users. The various embodiments enable each user to select the same or different anchor surfaces on which to view virtual objects <b>14</b>. So, in determination block <b>714</b> the processor may monitor user inputs (e.g., buttons, recognized movement gestures and/or spoken commands) and determine whether a second input is received indicating a second different anchor surface for the virtual object <b>14</b>. If a second input is not received (i.e., determination block <b>714</b>=“No”), the processor may return to block <b>711</b> to continue generating the virtual object in the image connected to the first anchor surface.

0140If a second input is received (i.e., determination block <b>714</b>=“Yes”), in block <b>715</b> the processor may detect one or more inputs that indicate a new anchor surface. When a new anchor surface is indicated, the processor may calculate parameters including distance and orientation corresponding to the new anchor surface that was selected in block <b>715</b>, and in block <b>716</b>, the processor may generate images presented on the head mounted display so that the virtual object <b>14</b> appears to be moved from the first anchor surface to the second new anchor surface. In block <b>717</b>, the processor may modify the image of virtual object to correspond to changes of position, and thus viewing perspective, of the user. For example, if the user walks closer the virtual object image size may increase. If the user walks a distance away from the virtual object, the virtual object's image size may decrease. The processes of modifying images of the virtual object to match changes in the user's viewing perspective in block <b>717</b>, as well as monitoring for user inputs in determination block <b>714</b> may continue to be performed in a continuous process throughout a collaboration session.

0141<figref idref="DRAWINGS">FIG. 8A</figref> illustrates an embodiment method <b>800</b> for rendering an image with an anchored virtual object for two users in an area, such as, for example, a room. In this embodiment, the displayed anchored virtual object <b>14</b> remains anchored to the selected anchor surface. Method <b>800</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>800</b>.

0142In method <b>800</b>, the processor may commence operation by processing an image using data from distance sensors, camera data and calculated distance data in block <b>801</b>. In block <b>802</b>, the processor may calculate parameters and may fix the virtual object to the anchor surface and fix the virtual object in the image that is presented on the head mounted display. In block <b>803</b>, the processor may render the image for display with the virtual object. In block <b>804</b>, the processor may control a transmitter/receiver or transceiver to transmit image and/or virtual object data to the second head mounted display. In block <b>804</b>, the first head mounted device may transmit the three-dimensional model and/or three-dimensional data set defining the virtual object to the second head mounted device in a format that enables the second device to generate an image of the same virtual object. Also in block <b>804</b>, the processor may transmit a map including positional coordinate information to the second head mounted device. The head mounted device may upload and/or download the room coordinate map from a server, or may transmit a map directly to a second head mounted device. In block <b>805</b>, a second processor may render an image of the virtual object for projection on the second head mounted display. The image may include the virtual object anchored or fixed to the anchor surface, which was selected by the first user in block <b>802</b>. For example, the first user may anchor the virtual object on a desktop surface. In block <b>805</b>, the processor may render the image. In the rendered image, the virtual object will appear on the desktop surface since it was selected by the first user in block <b>802</b> by the input.

0143In the various embodiments, a second head mounted device may display an image of the virtual object anchored to either the same anchor surface as designated by the user of the first head mounted device, or to a different anchor surface identified by the second user. In block <b>806</b>, for the second head mounted device, the second processor may determine a location and orientation where the second user is looking (which is related to the orientation of the head mounted device) in order to determine where within the displayed image an anchored virtual object should be rendered. For example, if the second user is looking at the anchor surface designated by the first user, then the second head mounted device may render an image of the virtual object in the head mounted display. However, if the second user is looking away from the anchor surface, the second head mounted device would not render an image of the virtual object since the anchor surface would be outside the user's field of view presented on the head mounted display.

0144Determining the orientation of the user's head and the head mounted device may be accomplished by capturing images by the cameras worn by the second user and data from orientation sensor (e.g., an inclinometer, gyroscopes and/or accelerometers) of the second user's head mounted device, and processing this information to infer the viewing angle and perspective of the second user. As discussed above, this process may be accomplished continuously such that each head mounted device can triangulate its own position and angle of view as it moves in space by constantly referencing the shifts in the topography of scanned three-dimensional (3D) environment, thus performing Simultaneous Location and Mapping (SLAM) operations. Also, if a portion of the second user's anatomy is captured in an image from the second user's head mounted or body mounted cameras, this may also include applying a detection algorithm to the captured image to recognize a body part, and from that infer where the body part's field of view is located.

0145In block <b>807</b>, the processor may process the virtual object data to generate image data for use in rendering an image of the object. In this operation, the processor may render the virtual object appropriately from the second user's perspective and so the second user can comfortably read content and view the virtual object. In block <b>808</b>, the processor may generate an image in the second head mounted display based on the location and the orientation of the anchor surface with respect to the user.

0146In determination block <b>809</b>, the processor may determine whether the second user would like to determine a new anchor surface. The determination may be from receiving an input signal indicating a desire to anchor the virtual object <b>14</b> in the image. For example, the second user may wish to anchor the image on a different surface than a current anchor surface. For example, the image may be fixed to a wall during a collaborative process with multiple users and then moved to a desktop.

0147As mentioned above, the user of the second head mounted device may elect to change the anchor surface, and thus move the image of the virtual object to another surface designated by the second user. If the head mounted device processor receives a user input indicating a desire to anchor the virtual object on a new surface (i.e., determination block <b>809</b>=“Yes”) which indicates the second user desires to determine a new anchor for the virtual object <b>14</b>, the processor may determine distance and orientation parameters of a new anchor of the virtual object on a second predetermined surface in block <b>810</b>. In block <b>811</b>, the processor may change or modify the virtual object to the parameters of the new anchor surface. The processor may process the virtual object <b>14</b> based on a distance and an orientation in block <b>812</b>. In block <b>813</b>, the second processor may render the image on the head mounted display with the anchored virtual object fixed on the second anchor surface.

0148If the processor does not receive a user input indicating a desire to anchor the virtual object on a new surface (i.e., determination block <b>809</b>=“No”), the processor may process the virtual object for rendering in block <b>807</b> with no change in anchor position but rendered for the second user's perspective. In a similar manner, the first or the second user may add another virtual object and anchor the additional virtual object on a third anchor surface.

0149<figref idref="DRAWINGS">FIG. 8B</figref> illustrates an embodiment method <b>815</b> for correctly orienting an anchored virtual object in an image that is output on a display of a first user from the first user's point of view, and on another display for a second user's point of view. Method <b>815</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method. In method <b>815</b> in block <b>820</b>, the processor may receive image data as the user scans a room and process the image data to identify/recognize surfaces, including surfaces suitable for serving as an anchor for virtual objects. For example, the processor may capture images from a head mounted or body mounted device. The processor of such a head or body mounted device may also receive information regarding distance and orientation of objects within the room from other types of sensors, such as a distance sensor. In block <b>822</b>, the processor may select a virtual object for display on a head mounted display, such as from another computer that is generating virtual objects for rendering. In block <b>824</b>, the processor may receive an input from the user indicating a surface on which to anchor the virtual object in block <b>824</b>. The processor may orient the virtual object in order to anchor it to a first anchor surface in block <b>826</b>, and generate an image of the virtual object on the first head mounted display in block <b>828</b>. The processor may also update the location and orientation of the virtual object to compensate for movement of the user in block <b>830</b>, such as to compensate or accommodate movement of the user's head.

0150In determination block <b>832</b>, the processor of the first head mounted device may determine whether the content selected or rendered by the first head mounted device will be transmitted to a second device. If not (i.e., determination block <b>832</b>=“No”), the processor may return to block <b>820</b> to repeat the process in order to generate a continuous display in which the virtual object appears to remain anchored to the same surface even as the user moves or turns his/her head.

0151If the processor determines that the selected content generated by the first head mounted device should be shared with a second head mounted device (i.e., determination block <b>832</b>=“Yes”), the processor of the first head mounted device may receive a second input from a second user indicating a second anchor surface in optional block <b>834</b>. In optional block <b>836</b>, the processor may optionally perform calculations to determine a display position and orientation in order to anchor the virtual object to the identified second anchor surface. In optional block <b>838</b>, the processor of the first or second head mounted device may determine a visual orientation of the second user, such as by using methods described herein based on sensor data and obtained images. As mentioned above, the process of orienting the head mounted device with respect to the surroundings, and determining distances to and relative orientation of various surfaces may be accomplished continuously by monitoring orientation sensors (e.g., accelerometers and gyroscopes) and triangulating its own position and angle of view as the device moves in space by constantly referencing shifts in the topography of the scanned three-dimensional (3D) environment, thus performing Simultaneous Location and Mapping (SLAM) operations.

0152In a further embodiment, the processor within the first head mounted device may determine the orientation of the second user based on images of the second user obtained by its own stereo cameras and using anatomical models. In optional block <b>840</b>, the first head mounted device may transmit data regarding the virtual object to the second head mounted device in an orientation based on the second user's orientation determined in block <b>838</b>. The second head mounted device may then render an image of the virtual object on the second head mounted display as described here. This process of determining user orientations and generating displays may continue in a loop so that the image continues to appear anchored to the selected surface while the first and second users move and turn their heads.

0153In various embodiments, either head mounted device may perform the calculations that enable rendering the virtual object in the proper perspective for the second user. For example, the processor of the first head mounted device may transmit data to the second head mounted device that provides the virtual object data in a manner that correctly orients the second virtual object for the second user. The process of orienting the virtual object by the first head mounted device may be based on the determined orientation of the second user that is transmitted from the second head mounted device to the first. In other words, the second head mounted device may inform the first head mounted device about its position and orientation, and the first head mounted device may use this information to orient the virtual object data. Alternatively, the first head mounted device may determine the orientation of the second head mounted device based on images of the second user, and use this determination to orient the virtual object data. For example, the processor may determine a proper orientation for the virtual object by capturing images of the second user over time and applying an anatomical analysis to the images to detect a body part within the images. Using this information, the processor of the first head mounted device may transmit data regarding the virtual object to the second head mounted device to enable its processor to render an image of the virtual object positioned at the second anchor surface consistent with the second user's perspective.

0154The processor may also orient the second virtual object based on the detected body part and structures in view. For example, a second user's head, neck and torso may be detected in images captured by the first head mounted device, and the processor of the first head mounted device may determine that there is a horizontal wall or vertical table close by the second user that is or has been selected by the second user as the anchor surface. As another example, the processor of the first head mounted device may recognize the second user's head, neck and torso in obtained images, and from the positions of these body parts, determine how the virtual object should be oriented so the second user can read text associated with the virtual object. For example, images of the second user's head and torso may be analyzed to define horizontal (e.g., from shoulder to shoulder) and vertical (e.g., from torso to head) coordinate axis that may then be used to determine a proper orientation for rendering the virtual object. Additionally, a viewing angle of the virtual object image may be determined, such as in terms of distances from the second user's head and torso of each pixel of the virtual object as presented on the head mounted display. This processing may include varying object brightness consistent with the view angle of various surfaces on the virtual object from the second user's perspective.

0155In another embodiment, the processor may capture images of the second user over time and may apply an anatomical analysis to the images to detect a body part within the images. For example, a pair of eyes (or the head mounted device) of the second user and a nose may be detected. The processor may utilize the body part and determine a location where the second user is looking and orient the second virtual object based on where the second user is looking. In yet another embodiment, the processor may determine from the captured images whether the second user is sitting or standing. The processor may generate the second virtual object as anchored to a planar surface adjacent to the second user if standing. If sitting, the processor may generate the second virtual object to appear anchored to a nearby surface adjacent to the second user.

0156If the processor determines not to deliver content from the first user to the second user in block <b>832</b> (i.e., determination block <b>832</b>=“No”) the processor may display a virtual object for the first user in block <b>838</b> and may update the virtual object for the movement of the first user in block <b>840</b>.

0157In an embodiment, the processor may communicate the signal correctly orienting the second virtual object for the second user. The processor may also communicate a signal generating the oriented second virtual object for the second user. These may be communicated to a communication network. The communication network may receive the signal and the second virtual object may be generated for the second user at a distance away from the first user. For example, the first and the second user may be located in the same room or in different cities. In yet another embodiment, the second user may provide additional inputs by way of a detected gesture or an audio command to move or reorient the virtual object. The processor may also receive an input from the second user indicating whether to confirm or reject a preferred placement of the second virtual object. The second user may also provide an input to rotate and reorient the virtual object as desired.

0158In addition to enabling a shared experience between two or more users wearing head mounted devices, image data generated by one or more of the head mounted devices involved in a collaboration may be transmitted to and displayed on head mounted devices or other mobile devices such as smartphones or tablet computers used by non-participants, enabling others to view the collaboration in a virtual or augmented reality experience. As described above, others viewing a collaboration session wearing head mounted devices or using another mobile device such as a smartphone or tablet may not only see the virtual objects and user interactions with them, but have limited interaction capabilities with the virtual augmentations seen by one of the head mounted device users. This limited interaction may include touching the augmentation to cause an effect, defining an interactive area or anchor point on the physical surface (effectively adding a new augmentation to the shared experience), and interacting with the shared mixed reality scene via gestural and/or audio inputs. Any such changes in the virtual experience may be reflected in the head mounted displays worn by the other users.

0159<figref idref="DRAWINGS">FIG. 9A</figref> illustrates an embodiment method <b>900</b> for rendering images of an anchored virtual object for two users in widely separated locations. For example, one user may be located in San Diego, Calif. and a second user may be located in a second location, such as, for example, Cambridge, United Kingdom. However, in both locations, the displayed anchored virtual object <b>14</b> remains anchored to the anchor surface in each location fixed to a predetermined area of the image. In some embodiments, one user may select an anchor surface for a virtual object for multiple other users. Method <b>900</b> illustrated in <figref idref="DRAWINGS">FIG. 9A</figref> may be implemented in computing devices having a processor configured with processor-executable instructions to perform the operations of the method <b>900</b>. In block <b>901</b> of method <b>900</b>, the processor may commence operation by processing an image using data from distance sensors, camera data and calculated distance data.

0160The scene sensor <b>500</b> described above with reference to <figref idref="DRAWINGS">FIG. 5A</figref> may include a near-infrared (NIR) pulse emitter <b>503</b><i>c </i>and an infrared camera <b>503</b><i>b </i>with a fast gating mechanism capable of determining time of flight information for reflected infrared pulses. Based on the speed of light and the timing of infrared emission pulses from the illuminator <b>503</b><i>c </i>and the gating of the infrared camera <b>503</b><i>b</i>, distances to objects within the captured image may be determined based on the timing of received pulses. The pulse signal may be collected for each pixel or groups of pixels in the image and used to determine a distance from the distance sensor to the objects in the scene, which may be recorded and stored in a storage medium.

0161In block <b>902</b>, the processor may calculate parameters to display the anchored virtual object in the image. The virtual object may be intended to be fixed to a predetermined surface after an input is received by the processor and the calculated parameters may relate to the desired surface. In block <b>903</b>, the processor may render the image for display with the virtual object. In block <b>904</b>, the processor may control a transmitter/receiver or transceiver to upload and/or download a room coordinate map to a server. Such a coordinate map may be any form of position defining information that enables the head mounted devices to determine locations of structures within the room within a convenient coordinate system. For example, a square room may be defined for purposes of such a room coordinate map in terms of Cartesian coordinates in which the X and Y dimensions correspond to major axes of the floor and the Z coordinate corresponds to the vertical dimension (i.e., floor to ceiling). Since the cameras and other sensors within the head mounted devices (and/or body mounted cameras) may locate the major structural dimensions of a room, such as the walls, floor and ceiling, the orientation of the room coordinates may be easily aligned to the walls and floor of the room. In this manner, the systems need not be concerned with geographic coordinates (e.g., from GPS sensors) or compass coordinates. On the other hand, when users are outside or within a space that lacks a convenient Cartesian reference frame, Cartesian coordinates may be aligned to GPS and compass coordinates.

0162With a coordinate frame of reference identified, structures and surfaces within view of the users may be identified or linked to the coordinate system by using distance measurements from the user (e.g., from distance sensors and/or processing of stereo images) to various coordinate defining surfaces (e.g., walls, floor and ceiling) and to various objects and surfaces in view of the head mounted display. A simple geometric coordinate translation algorithm may then be used to translate user-relative coordinates of objects and surfaces to a general room coordinate map. Thus, the result of this processing may be to generate a data set of coordinate vectors (e.g., 3 coordinate distances) for each object or surface in the room within a general reference frame. A head mounted device may use this coordinate database to determine its own location within the room. Then, knowing its own location within a coordinate database for the room, the processor can calculate distances and directions from the head mounted device to all objects and surfaces in the room using simple Cartesian coordinate transformation algorithms. In the situation of the users being outdoors, the general reference frame may be based upon geographic coordinates, which may be arbitrarily selected and tied to or determined from GPS system measurements.

0163In another embodiment, a room coordinate map may be stored in a local memory accessible to the head mounted device, such as in a memory coupled to a processor of the device, or in a mobile computing device (e.g., a smart phone) wirelessly coupled to the head mounted device. In block <b>916</b>, the virtual object may be rendered on the display on the first anchored surface, and the processor may continue to render the virtual object on the first anchored surface as the user moves and turns the head mounted display. In block <b>917</b>, an audio link may be established between the first and the second head mounted audio devices for communication and collaboration.

0164Turning to <figref idref="DRAWINGS">FIG. 9B</figref>, in block <b>905</b>, a processor in the second head mounted device, which may be located a geographic distance away from the first user, may determine a location and viewing orientation of the second user. This may be accomplished using any of the locating methods described herein, including obtaining coordinate location data, compass data, and accelerometer data to determine a location and viewing angle of the head mounted device. In some cases the second head mounted device may determine its viewing angle by recognizing a part of the user's body present within the image, and from that infer a likely viewing perspective using an anatomical model. In another embodiment, the second user may provide an input to designate a surface on which to render a virtual object, and indicate the user's viewing perspective. In block <b>906</b>, the processor may process the virtual object to render the virtual object appropriately for display from the second user's perspective. In block <b>907</b>, the processor may generate an image in the second head mounted display based on the location and the orientation of the second user.

0165In determination block <b>908</b>, the processor of the second head mounted device may determine whether the second user would like to select a new anchor surface to anchor the virtual object in the displayed image. For example, the second user may wish to anchor the image on a surface in the displayed image that may be convenient during collaboration such as a physical desk top. In an embodiment, the virtual object may be anchored on a virtual physical surface, such as, for example, a virtual table, which may appear within the rendered image.

0166If the processor determines that the second user desires to change the anchor surface for the virtual object (e.g., via an input) (i.e., determination block <b>908</b>=“Yes”), the processor may determine distance and orientation parameters of the newly designated anchor surface in block <b>909</b>. In block <b>910</b>, the processor may change the rendering of the virtual object based on the parameters of the anchor surface (desktop), and process the virtual object based on distance and orientation of the anchor surface of the second predetermined surface in block <b>911</b>. In block <b>912</b>, the second processor may render the image with the anchored virtual object on the anchor surface in the display of the second head mounted device.

0167In block <b>913</b>, updates of the virtual object received from the user wearing the second head mounted display may be transmitted to the first head mounted display for rendering. In this manner, the users of the two head mounted displays may collaboratively interact with the virtual object during a collaboration session. These updates may be transmitted between the two head mounted devices so each device displays the updated virtual image reflecting all changes made by either user. For example, in a word processing application, the virtual object may reflect changes from both users in a collaborative manner. In block <b>914</b>, an audio link may be established between the second and the first head mounted devices. The users may utilize the audio link to speak to one another, as well as other users in an audio conference format. This conference may occur at the same time as viewing the virtual object on the display in two different geographic locations. In an embodiment, the head mounted device may use video and audio conferencing software.

0168If the processor determines that the second user does not wish to anchor the virtual object in a new location (i.e., determination block <b>908</b>=“No”), the processor may render the virtual object in block <b>915</b>. For example, the second user may simply select to display the virtual object on original anchor surface or in a free floating arrangement on the head mounted display. For example, the processor may display the virtual object in a “stand-by mode” in block <b>915</b>.

0169<figref idref="DRAWINGS">FIG. 10</figref> illustrates an embodiment method <b>1000</b> for initiating a peer to peer discovery between a first head mounted device and a second head mounted device. Method <b>1000</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform operations of the method <b>1000</b>. Once two head mounted devices are linked through a peer-to-peer communication link, the two head mounted devices may share resources and may share and exchange data between the devices. Method <b>1000</b> is not limited to linking head mounted devices together, and may be applicable to other computing devices that may link with one or more head mounted devices. In an embodiment, the head mounted device <b>10</b> may be operable as an accessory of a mobile device having a CPU (e.g., phone, tablet, etc.) and a portion of the operations in method <b>1000</b> may be performed by a CPU of the mobile device while the head mounted device may perform fewer operations, serving as a “terminal” and may receive an output from the mobile device via a wireless interface. For example, the processing may be performed on a first mobile device and a display output may be delivered to the head mounted display which generates the viewable image of the anchored virtual object.

0170In block <b>1002</b> of method <b>1000</b> the processor may receive position data from a locating device associated with the head mounted device, such as a Global Positioning Unit (GPS) or any other space-based global navigation satellite system (GNSS) receiver, or navigation device associated with the head mounted device. For example, the location device may be a device that determines a location from a radio network base station. In another embodiment, the head mounted device may receive local positional data from a local device, such as a cloud server, or from a wireless communication network base station. In a further embodiment, the user may provide an input (e.g., a voice command or button press) indicating the head mounted device is entering a new location and/or starting a new collaboration session. In a further embodiment, the head mounted device may receive peer network advertisements from other devices and determine from a new advertisement that the device has entered a new location.

0171In determination block <b>1004</b>, the processor may determine whether the first head mounted device has entered a new location based on position data or other indications. If so (i.e., determination block <b>1004</b>=“Yes”), the head mounted device may initiate peer-to-peer discovery in block <b>1006</b> to determine if other computing devices or head mounted devices are in the vicinity and can be linked by wireless data connections. The process of initiating peer-to-peer discovery in block <b>1006</b> may continue until a response is received from a device that can be linked (i.e., so long as determination block <b>1008</b>=“No”). When a device capable of establishing a peer-to-peer communication link is identified (i.e., determination block <b>1008</b>=“Yes”), a peer-to-peer communication link may be negotiated in block <b>1010</b>, and a two-way communication established between the two devices in block <b>1012</b>.

0172In block <b>1014</b>, the head mounted device may receive map data from the computing device with which it has established a communication link. In this operation, the head mounted device may download any map data that has been stored on the other computing device (e.g., another head mounted device, another computing device or a distant server, etc.) so that the head mounted device can immediately orient itself within the new location. For example, if the computing device with which the head mounted device has established a communication link has access to a network or the Internet, map data may be downloaded from a remote server (e.g., from the “cloud”). The head mounted device may also scan its own internal memory to determine whether map data for the new location is already stored in memory. If map data is stored in memory, as part of the operations in block <b>1014</b>, the head mounted device may share some of that map data with the computing device with which the communication link has been established. Also, before exchanging map data, the communicating head mounted devices may determine whether they are close by each other, and only exchange map, distance, and orientation data if they are close enough together that sharing map data will reduce processing burdens on one or both device processors. Thus, if the head mounted device and the linked computing device are not in the same room, it may not make sense to share location, map or orientation data that would be irrelevant to the other device.

0173In block <b>1016</b>, the processor may receive data from the head mounted or body mounted stereo cameras, as well as distance measurements that may be obtained by distance sensors. In block <b>1018</b>, the processor may use any map data received in block <b>1014</b> in conjunction with the camera images and any distance measurements in order to orient the device within the map and scene. Optionally, in block <b>1018</b>, the processor may generate or update three-dimensional map data for any items or structures seen in the images that do not appear within the received map data. If no map data was received from another computing device and the device did not have a map for the location in memory, the processor may generate a new map in block <b>1018</b>.

0174In block <b>1020</b>, the head mounted device processor may process images obtained by the camera using the data from the various sensors, including distance sensors and orientation sensors. This processing may enable the device to locate itself within coordinates or locations within the map data. This processing may also include determining the distance to and orientation of an anchor surface to use in rendering virtual objects.

0175In block <b>1022</b>, the head mounted device processor may exchange display and virtual object data with the linked computing devices in order to enable the devices to generate the displays that may be used in collaboration. In block <b>1024</b>, the head mounted device may begin supporting the user with collaboration, such as by displaying virtual objects on anchor services, detecting and responding to user command gestures, and communicating changes and inputs to other coupled computing devices as described herein regarding the various embodiments.

0176<figref idref="DRAWINGS">FIG. 11</figref> illustrates an embodiment method <b>1100</b> for processing recognized gestures and detected audio as input commands. The gestures and detected audio may execute tasks and instructions on the head mounted display. Method <b>1100</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform operations of the method <b>1100</b>.

0177In this embodiment method, user input commands received in one form, such as recognized user gestures, may be confirmed by a user input in another form, such as a verbal command received by a microphone. For example, if a processor of the head mounted device recognizes a first command, such as by processing image data to recognize gestures, the processor may monitor other user inputs for a short period of time for a second command that confirms the recognized first command. In this embodiment, the processor may not implement an action or execute a task corresponding to the first recognized user input unless that action or task is confirmed by a second user input. The second user input may be a voice command received by a microphone, or a second gesture that is recognized within images gathered by the body mounted cameras. This embodiment may be useful since a number of normal user movements may be misinterpreted as command gestures; requiring the user to confirm gesture commands before they are executed and guard against unintended commands being executed. The process of waiting for a confirmatory user input may be invoked when a gesture made by the user is recognized within an image, or the processor believes it has received a verbal command. Generally, this two command confirmation process may avoid a situation where a stray gesture or an inadvertently spoken command may unintentionally be acted upon by the head mounted device. Instead, the head mounted device will await a second command before taking an action. This two-command process may also be implemented based upon the type of command that is recognized, such as when the action associated with a recognized command involves an operation that may be undesirable or irreversible, like deleting a piece of content.

0178In block <b>1101</b> of method <b>1100</b>, the processor may commence operation by receiving sensor data regarding the orientation of the head mounted device. In block <b>1102</b>, the processor may receive data from the cameras regarding the captured image. In block <b>1103</b>, the processor may calculate distance and orientation of objects in the image. In block <b>1104</b>, the processor may process the image using sensor data, camera data and the distance sensor data. In block <b>1105</b>, the processor may render the image on the display with the virtual object contained in the image.

0179In block <b>1106</b>, the camera data may be processed for determining whether any anatomical features are contained within the view of the camera. Generally, an anatomical feature detection algorithm may be applied to captured camera image data in order to determine whether any features are recognized as being part of the human. For example, the anatomical recognition algorithm may scan the images received from the body mounted camera to determine if an anatomical feature is recognized, such as a hand with five fingers and an arm. The process of recognizing anatomical features may also determine their orientation, such as the angle of a user's arm within the captured image. Positions and orientations of recognized anatomical features may be tracked in images over a time period and compared to a database or dictionary of user gestures to determine movements of the tracked anatomical features correspond to a recognized gesture. If a user gesture is recognized, the processor may output a command in response to the detected gesture. For example, the command may open a software application, or may provide a signal or input to a software application.

0180The processor is recognizing user gestures may be accomplished in determination block <b>1107</b> by comparing movements of recognized anatomical features to a database of predefined anatomical movements, such as may be maintained in a gesture dictionary. For example, a body part, such as a hand, may be recognized in the captured images and its movements tracked over a predetermined time interval. For example, if the processor, using the anatomical model, recognizes that the user's hand and the fingers are positioned in front of the body mounted camera with two fingers outstretched and three fingers are folded downwardly toward a palm of the user, the processor may determine by comparing this orientation of the user's hand and fingers to a gesture dictionary that the that the user is expressing a desire for the processor to take an action. The processor may recognize body part gestural arrangements by comparing image patterns and movements to movement data or patterns stored in a gesture dictionary. Such a gesture dictionary may store gesture data for movements that may include pokes, pats, taps, pushes, guiding, flicks, turning, rotating, grabbing and pulling, two hands with palms open for panning images, drawing (e.g., finger painting), forming shapes with fingers (e.g., an “OK” sign), and swipes, all of which may be accomplished on or in close proximity to the apparent location of a virtual object in a generated display. If the head mounted display recognizes a gesture in the camera image data that matches an entry within the gesture dictionary (i.e., determination block <b>1107</b>=“Yes”), the processor may process an input command that corresponds to the recognized gesture in block <b>1108</b>. In block <b>1109</b>, the input command may be executed by the processor. The input may also be any signal or data that is communicated to a software application, or a computing device, or a signal to provide an indication.

0181Again, as discussed above, the execution of a command based on the recognized gesture may not be accomplished until a second confirming user input is received. Thus, in such an embodiment, instead of executing the command, the processor may display a prompt (or generate a tone) for the user to confirm the recognized gesture command in block <b>1109</b>. In determination block <b>1110</b>, the processor may determine whether any audio (or other user input) is received from a microphone for a short period following recognition of a gesture command. If the audio is received within that period of time, the processor may process the audio to determine whether a confirmatory command was spoken to confirm the detected gesture. To accomplish this, audio inputs received from the microphone may be digitized and the resulting data compared to a voice command recognition database for words that correspond to one or more input commands. When the processor determines that an audio input matches a voice command pattern corresponding to command confirmation (i.e., determination block <b>1110</b>=“Yes”), the processor may process an input command that results in an action that corresponds to the audio in block <b>1111</b>. In block <b>1112</b>, the processor may execute the recognized command and an indication or the recognized task may be displayed on the head mounted in block <b>1113</b>.

0182For example, a user may gesture to anchor the virtual object <b>14</b> on a physical surface by pointing. Upon recognizing this gesture, the processor may generate a prompt, such as an audible tone or message presented in the head mounted display requesting the user to confirm the command. To do so, the user may speak words like “okay,” “confirm” or “make it so” to confirm that a gesture command recognized by the head mounted device should be executed. Thus, when the processor detects the confirmatory or audible command, the processor may present images in the head mounted display that shows the virtual object anchored on the physical surface to which the user is pointing.

0183If no audio is received that is recognized as corresponding to a spoken audio command (i.e., determination block <b>1110</b>=“No”), the processor may determine that the gesture that was detected was inadvertent and the processor may ignore the recognized gesture and input command and may continue to process camera data looking for anatomical gestures in block <b>1107</b>.

0184Returning to determination block <b>1107</b>, if the processor does not recognize a gesture within the image data (i.e., determination block <b>1107</b>=“No”), the processor may continue to process camera data for anatomical gestures for a further additional time interval in block <b>1106</b>. The processor may display a task identifier or icon on the head mounted display in block <b>1113</b> indicating that no gestures have been recognized. Alternatively, the processor may display a task identifier or icon as soon as a gesture command is been received, which may serve as a prompt for the user to issue a confirmatory command, such as a verbal command or an “OK” gesture command.

0185In another embodiment, different first and second commands may be used. In another embodiment, the processor may be configured to detect an audio command first and look for a confirmatory gesture command within received images, effectively swapping the operations performed in determination block <b>1107</b> and <b>1110</b>. In further embodiments, more than one type of confirmatory input may be required, such as an audible command in combination with a button press, etc.

0186<figref idref="DRAWINGS">FIG. 12</figref> illustrates an embodiment method <b>1200</b> for processing recognized gestures as input commands to execute software tasks on the head mounted device. Method <b>1200</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>1200</b>.

0187In method <b>1200</b> in block <b>1201</b>, the processor may commence operation by receiving sensor data regarding an orientation of the head mounted device <b>10</b>. In block <b>1202</b>, the processor may receive stereo image data from the stereo cameras, as well as data from any distance sensors included in the head mounted device <b>10</b> described above. Thus, in block <b>1202</b> the processor may obtain all information gathered by the head mounted device regarding images and distances to surfaces within the field of view of the camera(s). In block <b>1203</b>, the processor may calculate distance and orientation data of objects in the captured image. These calculations may use well known trigonometric methods when stereo images are provided in block <b>1202</b>, direct measurements when distance sensors are used to provide distance data, and combinations of distance information obtained from sensors and calculated from stereo images. In block <b>1204</b>, the processor may process the image using distance sensor data, camera data and the distance and orientation data. In block <b>1205</b>, the processor may render the image on the head mounted display with the virtual object. In block <b>1206</b>, the camera data may be tracked by the processor. The captured images may be processed and the processor may determine whether an anatomical feature is contained within the captured images. The processor may apply an anatomical feature detection algorithm to the captured images to determine if any features or at least one body part is located within the data. The processor may track the body part over a time interval to determine if a predetermined gesture is recognized.

0188In determination block <b>1207</b>, the processor may determine whether any gestures are recognized in the captured image. If so (i.e., determination block <b>1207</b>=“Yes”) which indicates the processor has recognized a gesture in the image, the processor may substantially match the determined gesture with an input command stored in memory in block <b>1208</b>. The processor may execute the input command that corresponds to the detected gesture in block <b>1209</b>. In block <b>1210</b>, processor may execute a task that corresponds to the input command. If the processor reaches a decision that there are no recognized gestures (i.e., determination block <b>1207</b>=“No”), the processor may continue tracking the captured images and applying the detection algorithm to the captured images in block <b>1211</b> to track for an input.

0189<figref idref="DRAWINGS">FIG. 13</figref> illustrates an embodiment method <b>1300</b> for detecting objects in the stereoscopic image and providing an interesting visual virtual reality effect based on the detection and interpretation of the detected objects. Method <b>1300</b> may display “deemed essential objects” on the head mounted display while the method <b>1300</b> may render other “unessential objects” as transparent on the head mounted display. Method <b>1300</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>1300</b>. In method <b>1300</b>, the processor may commence operation by receiving sensor data regarding orientation of the camera and head mounted device in block <b>1301</b>. In block <b>1302</b>, the processor may capture images and receive data from the cameras. In block <b>1303</b>, the processor may calculate distance and orientation of objects in the image. In block <b>1304</b>, the processor may process the image using distance sensor data, camera data, orientation, and the distance data.

0190In block <b>1305</b>, the process may render the image on the display with the virtual object <b>14</b>. In determination block <b>1306</b>, the processor may determine whether any objects are recognized within the images. For example, an anatomical detection algorithm may be applied to the detected images and data to determine if a body part is detected in the images. For example, an anatomical or a skeletal detection algorithm may be applied to the captured images to detect a body part, such as, an arm or a hand that may be rendered as visible or as transparent. If the processor determines that other objects are detected (i.e., determination block <b>1306</b>=“Yes”) which indicates the objects are detected, the processor may determine whether to render the object transparent by superimposing a virtual object on the object so as to make the object appear as if the object has been omitted from the image.

0191In the various embodiments, virtual objects may be presented with a variety of transparency characteristics. In some embodiments, a virtual object may be displayed as appearing over an outline of a real world object (arm, hands, fingers, and face). In such an embodiment, the virtual object may be changed in shape to match or cover over a real world object. In this manner, the real world object appears to be “see-through” in the image output on the head mounted display. In an embodiment, if the unnecessary object is in front of a wall or table, a virtual object may be generated that resembles the wall and/or table and superimpose the virtual wall/table over the unnecessary object. If the processor determines that no other objects are detected (i.e., determination block <b>1306</b>=“No”), the processor may continue and render the image with the virtual object in block <b>1310</b>.

0192In determination block <b>1307</b>, the processor may determine whether any objects are recognized within the images are necessary. For example, deemed “necessary objects” may be displayed while other deemed “unnecessary objects” may be rendered transparent to omit the object from the image. For example, a deemed necessary object may be a user's own hands in the image but another object that is deemed unnecessary may be a second individual's hands located over the virtual object. The unnecessary object may be displayed in an outline form with the virtual object superimposed over the unnecessary object. The terms necessary and unnecessary may be arbitrarily programmed and selected by the user utilizing a drop down menu or any supported gesture or method for the user to indicate a preference, such as gaze detection, a hand pointing gesture that may be recognized by the head mounted or body mounted cameras, etc. The user may program the head mounted device to display “other users' features” as transparent and display “my features always”, or vice versa. If the processor determines that the objects are necessary (i.e., determination block <b>1307</b>=“Yes”), the processor may provide program instructions to render the image in block <b>1310</b> with the necessary object and the virtual object. For example, a user's own hands may be deemed necessary and displayed in the image. The terms necessary and unnecessary are arbitrary parameters and may be determined by the user. For example, the user at a set up operating procedure may indicate the objects that are necessary and the objects that are unnecessary and should be rendered as transparent. For example, the user may determine using a drop down menu and an input device that the user's hands are necessary and that other user's body parts in the image are not necessary. For example, many different users may be present in the image and collaborating over an anchored virtual object. The scene may be cluttered with many users and many virtual objects. Therefore, some of the users may be rendered transparent so as to alleviate cluttering in order to enhance collaboration.

0193If the processor determines that the objects are unnecessary (i.e., determination block <b>1307</b>=“No”), the processor may render the image with the object as transparent in block <b>1308</b>. In block <b>1309</b>, the processor may also display the virtual object with the unnecessary object rendered as transparent or with the virtual object displayed over the unnecessary object. In another embodiment, the object may be rendered partially transparent only when the object occludes the virtual object <b>14</b> and may be rendered solid when the object does not occlude the virtual object <b>14</b>.

0194<figref idref="DRAWINGS">FIG. 14</figref> illustrates an embodiment method <b>1400</b> for rendering images on a head mounted display taking into account hands, arms and other human features (e.g., those of the user and another individual) that may appear in the image scene. In this embodiment, the head mounted device processor may capture an image of a scene in which a virtual object is to be displayed, recognize a body part present in the captured image, such as by processing the image using an anatomical model, and adjust the display of the virtual object based upon the recognized body part. The adjustment to the display may involve rendering the virtual object in front of, behind or blended with a recognized body part. For example, the processor may render a virtual object as partially transparent in places where a user's feature (e.g., hands and arms) occludes the virtual object and as nontransparent where the user's feature does not occlude the virtual object. In this manner, the user can see his/her hands in the vicinity of the image of a virtual object while the rest of the virtual object appears solid as if real. Alternatively, the processor may render the virtual object so the user's own features appear in front of or over a virtual object (i.e., solid) while the hands and arms (and other body parts) of another individual are rendered transparent so they are made invisible by the image of the virtual object (i.e., the virtual object blocks the user's view of the other person's hands/arms), or so that the virtual object can be viewed through the other person's hands and arms.

0195For example, the head mounted or body mounted camera may capture images of the scene which include hands and arms of the user and another individual. The device's processor may apply an anatomical algorithm to the captured image data to recognize body parts within the captured images. For example, the processor may detect a user's hands and a second individual's hands in the captured images by comparing the image shapes to an anatomical model.

0196Both sets of hands may occlude a virtual object. For example, five fingers and hand size data may be reviewed for the image. The processor may infer that hands which are oriented from top down on captured images are the second individual's hands while other hands that are oriented from bottom up within captured images are the user's hands. Additionally, the processor may capture distance data of the recognized object to formulate an inference. For example, when the processor determines that anatomical features (e.g., arm and hands) are at least a predetermined distance (twelve feet) away from the user, the processor may infer from this information that those features belong to another individual. Additional sensed parameters are also possible and within the scope of the present disclosure. For example, the height of the objects, the orientation of the objects, and the size of the objects may all be utilized.

0197In method <b>1400</b>, the processor may commence operation by receiving sensor data regarding the orientation of the cameras block <b>1401</b>. In block <b>1402</b>, the processor may receive data from the cameras. In block <b>1403</b>, the processor may calculate a distance and an orientation of objects in the image. In block <b>1404</b>, the processor may process the captured image using distance sensor data, camera data, orientation of the image and the distance data. In determination block <b>1405</b>, the processor may determine whether an object is recognized within the images that corresponds to a user's feature, for example, the user's hands, arms, legs, torso, etc. This determination may involve applying an anatomical analysis to the image by recognizing objects within the captured image, comparing the recognized objects to a skeletal model stored in memory, and determining if any of the recognized objects match a portion of the skeletal model in response to comparing the recognized objects to the skeletal model. The skeletal model may include relative position information about key joints, bones, and limbs of a human skeleton.

0198If a feature of a person is recognized within the image (i.e., determination block <b>1405</b>=“Yes”), in block <b>1409</b>, the processor may render the image with the virtual object and the user's features in the image. If no user's features are detected within the images (i.e., determination block <b>1405</b>=“No”), the processor may determine whether the feature is the second individual's features in determination block <b>1406</b>.

0199In determination block <b>1406</b>, the processor may determine whether the second individual's features are detected. This determination may involve determining whether the body part belongs to a first individual or to a second individual in response to recognizing a body part present in the captured image, determining a location and encompassed area of the virtual object, and determining whether the recognized body part overlaps at least one portion of the area encompassed by the virtual object. These features may be rendered transparent by the processor. The processor may omit the object(s) by generating and superimposing a virtual object on the detected feature. For example, the processor may render the virtual object over the second individual's hands on the display. If so (i.e., determination block <b>1406</b>=“Yes”) which indicates the second individual's hands are detected and are not necessary in the image, the processor may render the virtual object superimposed in the image over the second individual's hands in block <b>1407</b>.

0200If the processor is unable to determine whether the object is the second individual's hands (i.e., determination block <b>1406</b>=“No”), the processor may render the image with the virtual object in block <b>1408</b>. The processor may determine a number of pixels in the image that correspond to a desired object and then leave an outline of the desired object as displayed, but replace pixels in the image with a virtual object <b>14</b>. The outline size may vary and may include about 1 percent of the object image length.

0201<figref idref="DRAWINGS">FIG. 15</figref> illustrates a high level top down view of an illustration of a display output of the head mounted device <b>10</b>. The display output shows a virtual object <b>14</b>. The virtual object <b>14</b> is illustrated as a virtual flat panel screen that outputs data. In this embodiment, the virtual screen outputs a graphical table with a number of bar charts. Multiple users may collaborate over the virtual object in a virtual reality setting in that the virtual object <b>14</b> only appears in the output of the display but appears to be a tangible, real object to the viewer.

0202In the illustrated example, the processor detects a user's features or hands <b>1502</b> and detects two other individuals' features or hands <b>1500</b> and <b>1501</b> over the virtual object <b>14</b> within the stereoscopic image. As illustrated in <figref idref="DRAWINGS">FIG. 15</figref>, the user's hands are allowed to be displayed by the processor as an essential element in the display. The user's hands will appear over and will occlude the virtual object <b>14</b>. Additionally, two other individuals' features may be rendered seemingly transparent on portions of the virtual object <b>14</b> since these elements are deemed to be not essential and may distract or may clutter the view of the user of the head mounted device <b>10</b>. The virtual object <b>14</b> may be displayed by the processor as superimposed and fitted over the hands <b>1500</b> and <b>1501</b> so the hands <b>1500</b> and <b>1501</b> do not occlude the generated virtual object <b>14</b>.

0203In the illustrated example, the second user's hands <b>1501</b> are rendered by the processor as “transparent” and as shown by the outline of the second individual's hands <b>1501</b> rendered over the virtual object <b>14</b>. The virtual object <b>14</b> portion that should normally be occluded may be rendered directly on the second individual's hands <b>1501</b>. In the illustrated example, the second user's hands <b>1501</b> appear to be transparent with only an outline of the hands <b>1501</b> shown. The other user's hands <b>1502</b> are rendered as a “solid object” in the illustrated example, with those hands <b>1502</b> rendered over and occluding the virtual object <b>14</b>. In the illustrated example, the hands <b>1502</b> appear to be solid and the virtual object <b>14</b> may be not visible underneath. In an embodiment, the other individual's hands may be detected and rendered with an outline of the hands <b>1500</b> and <b>1501</b>. A remainder of the hands <b>1500</b> and <b>1501</b> are illustrated as being rendered beneath the virtual object <b>14</b>.

0204The head mounted or body mounted camera may capture images and apply an anatomical model to the captured image data to recognize a body part. For example, this may be a user's hands <b>1502</b> and a second individual's hands <b>1500</b> and a third individual's hands <b>1501</b> over the virtual object <b>14</b>. For example, five fingers, hand size data, a portion of the arm, the orientation of the hands, the orientation of the fingers, distance data and orientation data may be reviewed. The processor may infer that hands that are oriented from the top of the image and extending toward the bottom of the image are the second individual's hands <b>1500</b>. The processor may also infer that hands oriented from a right side of the image and a certain distance away from the camera <b>1501</b> are the other individual's hands <b>1501</b>. The processor may also infer that a third set of hands <b>1502</b> which are oriented so they extend from the bottom of the image up are the user's hands if they are within a distance range and positioned in the image with respect to the orientation of the head mounted device <b>10</b> consistent with an anatomical model. Additional sensed parameters may also be used by the processor in recognizing body parts. For example, when the user's hands or arms have been tracked, the processor may infer that all other hands in the displayed image belong to other users, and therefore the processor may render those remaining hands as outlines or transparent in the image presented on the head mounted display.

0205<figref idref="DRAWINGS">FIG. 16</figref> illustrates another embodiment of the head mounted device <b>1600</b> communicating with a mobile device <b>1605</b> across a high speed data link to leverage processing resources. <figref idref="DRAWINGS">FIG. 16</figref> illustrates a number of subcomponents of the head mounted device <b>1600</b>. The head mounted device <b>1600</b> may be operable as an accessory to a mobile CPU (phone, tablet etc.) with the main processing performed on the mobile CPU. Generally, the head mounted device <b>1600</b> may be made as lightweight as possible to be comfortably worn around the head of the user. The head mounted device <b>1600</b> may leverage the processing and data storage resources of a mobile device <b>1605</b> and a VIRT control system <b>1610</b> may be implemented within the software applications running on the mobile device <b>1605</b>. The mobile device <b>1605</b> may provide processing functions, increase memory, and conserve battery life of the head mounted device <b>1600</b> by performing the processing at the mobile device <b>1605</b>.

0206The head mounted device <b>1600</b> comprises a scene sensor (a RGB-D camera) <b>1615</b> connected to a processor. The head mounted device <b>1600</b> may also include an audio sensor (microphone) <b>1620</b> and a stereoscopic display <b>1625</b>. The display <b>1625</b> may be a semitransparent OLED video display <b>1625</b>. The head mounted device <b>1600</b> may also include an ear bud that includes a speaker or may alternatively include a pair of headphones <b>1630</b>. In another embodiment, the head mounted device <b>1600</b> may comprise a stripped down device <b>1600</b> to be lightweight. The device <b>1600</b> may comprise a wireless interface, a scene sensor <b>1615</b>, a battery and a display <b>1625</b>. The wireless interface may communicate data to a processor in the mobile device <b>1605</b> which may be configured to run a VIRT control system <b>1610</b> so the head mounted apparatus remains lightweight and comfortable on the user. As described in more detail below with reference to <figref idref="DRAWINGS">FIG. 41</figref>, a mobile device <b>1605</b> includes a processor and a memory, and in an embodiment the processor may be configured with a VIRT control software module <b>1610</b> that may be configured to interoperate with the head mounted device <b>1600</b>. The mobile device <b>1605</b> and the head mounted device <b>1600</b> may communicate using a high speed data link <b>1612</b>, which may be wired or wireless. For example, the high speed data link <b>1612</b> may be a short range wireless data link <b>1612</b> selected from any one or more of Bluetooth®, Wi-Fi®, Qualcomm's Peanut®, and ZigBee® wireless protocols.

0207For example, sensor data may be captured utilizing sensors <b>1615</b>, <b>1620</b> and <b>1630</b> and converted to digital data. The digital data may be communicated to a wireless device and the digital data may be communicated along link to the control system <b>1610</b> operable on the mobile device <b>1605</b>. The control system <b>1610</b> may process the sensed data and may render display data. For example, the control system <b>1610</b> may receive scanned images and distance data of the area and generate a virtual object on at least one surface in the room. The display data may be communicated back along the link and output on the head mounted display <b>1625</b>.

0208<figref idref="DRAWINGS">FIG. 17</figref> illustrates an embodiment method <b>1700</b> for using a high speed link between the mobile device and a head mounted device to enable off loading of sensor data processing to the mobile device. Method <b>1700</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>1700</b>. In block <b>1701</b>, the processor may receive sensor data regarding orientation of the head mounted device and its cameras. In block <b>1702</b>, the processor may receive image data from the device's cameras. In determination block <b>1704</b>, the processor may determine whether a mobile device is present, wirelessly communicating with the head mounted device and able to assist with processing and memory storage. If no (i.e., determination block=“No”), in block <b>1710</b>, the images may be processed by the head mounted device as described in other embodiments.

0209If a mobile device is present, wirelessly communicating with the head mounted device and able to assist with processing and memory storage (i.e., determination block=“Yes”), the head mounted device may send sensor data to the mobile device for processing by the mobile device processor in block <b>1705</b>. In block <b>1706</b>, the mobile device processor may calculate distance and orientation data for objects within the image based on the received data. In block <b>1707</b>, the mobile device processor may process the image data using sensor and camera data received from the head mounted device. In block <b>1708</b>, the mobile device processor may generate display data for the virtual object using the sensor and image data received from the head mounted device, and transmit the generated display data to the head mounted device. In block <b>1709</b>, that head mounted device may use display data received from the mobile device to render images on the head mounted display. This process may continue by returning to block <b>1701</b>, although once the head mounted device is determined that a mobile device is present (i.e., determination block <b>1704</b>=“Yes”), then a determination may not be repeated for a current session.

0210<figref idref="DRAWINGS">FIG. 18</figref> illustrates a method <b>1800</b> for communicating data to a shared user memory so a second head mounted device may access shared data. Method <b>1800</b> may alleviate a processing time to render an image or may alleviate processing time to generate a virtual object on a properly oriented display. For example, the processor may, in some embodiments, process image data and also receive image data, or location data from a storage medium to render a virtual object faster. Method <b>1800</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>1800</b>.

0211In method <b>1800</b>, the processor may commence operation by receiving sensor data regarding orientation of the cameras. In block <b>1802</b>, the images may be captured and the processor may receive stereo image data from the cameras. In block <b>1803</b>, the processor may calculate distance and orientation of objects in the image. In block <b>1804</b>, the processor may process image data from the sensors. In block <b>1805</b>, the image may be rendered with a virtual object. In block <b>1806</b>, a determination may be made regarding whether to share data to a remote storage medium so another head mounted device may receive the shared data and utilize the shared data. For example, the other head mounted device may obtain position data, or may use the shared data to render the image and the virtual object.

0212If the processor determines to share data to a remote storage medium (i.e., determination <b>1806</b>=“Yes”), the data may be communicated to a shared memory in block <b>1807</b>. If the processor determines not to share data to a remote storage medium (i.e., determination block <b>1812</b>=“No”), the processor may continue to block <b>1801</b> to continue to capture data. A second head mounted device <b>10</b><i>b </i>may access the data from the storage medium in block <b>1808</b> and may receive the data in block <b>1809</b>. In block <b>1810</b>, the distance data may be calculated and the image processed in block <b>1811</b>. A determination may be reached in determination block <b>1812</b> to share data that is aggregated by the second head mounted device <b>10</b><i>b</i>. For example, the data may be scanned sensor data or other data to collaborate. The data may be transmitted by the processor and stored at the storage medium. If the processor decides to share data aggregated by the second head mounted device (i.e., determination block <b>1812</b>=“Yes”), data may be communicated to a shared memory in block <b>1813</b>. If the processor decides not to share data aggregated by the second head mounted device (i.e., determination block <b>1812</b>=“No”), the processor may continue to block <b>1809</b> to continued to receive data regarding the image.

0213<figref idref="DRAWINGS">FIG. 19</figref> illustrates an embodiment method <b>1900</b> for sharing data over a communication network and for use by multiple devices. A head mounted device <b>10</b> may share resources with a second mobile communication device <b>10</b><i>b</i>. The method <b>1900</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>1900</b>.

0214In method <b>1900</b>, the processor may commence operation by receiving sensor data regarding orientation of the cameras. In block <b>1902</b>, the processor may receive stereo image data from the cameras. In block <b>1903</b>, the processor may calculate distance and orientation of objects in the image. The processor may convert the image data and the position and orientation data. The data may be tagged with position data for use by a second head mounted device. The second head mounted device may receive the distance, image, and the tagged positional data. The second head mounted device may utilize the data in order to render the image with the virtual object in the image with minimal processing.

0215In block <b>1904</b>, the processor may tag objects in the image to store the tagged information in a geometric three-dimensional model. The tag may comprise geographic position data that may be obtained from a GPS device. In an embodiment, the position data may describe objects in the room and the relative position of objects relative to one another. In another embodiment, each object may be assigned GPS coordinates including an orientation of the objects. In an embodiment, the tag may comprise at least four separated positional coordinates. In a further embodiment, data associated with the virtual object may also be tagged with position data. In block <b>1905</b>, the processor may process the image using sensor data, camera data, orientation of the image and the distance data. In block <b>1906</b>, the processor may render the physical environment in a model. The model may be uploaded and transmitted by the processor to a storage medium, which may be accessible by other head mounted device(s) or separate processors connected to other head mounted device(s). As mentioned herein, the head mounted devices may be configured to be light weight by leveraging external processors and storage media (e.g., a smart phone, personal computer, or server accessible via a local wireless network). A second head mounted device may determine its position and may form a request to a storage medium to access scanned data relating to a current position. The storage medium may receive the request. The storage medium may communicate the data to the head mounted device based on the position.

0216In determination block <b>1907</b>, the processor may determine whether to share the data. If so (i.e., determination block <b>1907</b>=“Yes”), the processor may share the data and communicate the data to a mobile device (block <b>1908</b>) associated with a second user, or to a storage medium, where a computing device may request data from the storage medium. For example, the storage medium may comprise another computing device, a server, or a network distributed computing device. If the processor determines not to share the data (i.e., determination block <b>1907</b>=“No”), the processor may continue to block <b>1901</b> to continue to receive data from the sensors regarding orientation of the camera and capture images in block <b>1902</b>. In block <b>1908</b>, a second head mounted device may access the shared data. The processor may utilize the shared data to display the virtual object in block <b>1909</b> while reducing the amount of processing to render the virtual object.

0217<figref idref="DRAWINGS">FIG. 20</figref> illustrates an embodiment method <b>2000</b> for using a server to share location coordinate data and scanned data between at least two head mounted devices to render a virtual object. For example, a processor may share data over a communication network for use by multiple devices so the devices may process image data, positional data, orientation data, distance data and more quickly render a virtual object in an image by obtaining shared data or may share other data useful for collaboration purposes between software applications. For example, one user may be able to access another user's files stored in memory. The method <b>2000</b> enables a processor to collaborate and share resources with other devices. Method <b>2000</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>2000</b>. In block <b>2001</b>, the processor may commence operation by executing an application associated with a first head mounted device.

0218In block <b>2002</b>, the processor may open an input/output channel that is associated with the head mounted device. The processor may execute an application with second head mounted device in block <b>2003</b> and open the channel in block <b>2004</b> to communicate over the channel. The processor may execute an application on a shared server in block <b>2005</b>. In block <b>2007</b>, the processor may create a connection to the server and both head mounted devices using the RF channel. The processor may collaborate using the first and the second head mounted devices and the server in block <b>2008</b>. In block <b>2009</b>, the processor may share audio data. In block <b>2010</b>, the processor may share data files and synchronize documents at the server. In block <b>2011</b>, the processor may detect audio gestures at the mobile devices for new commands.

0219Also, as described above, sharing of image and audio data generated by one or more of the head mounted devices with a server may enable others to observe the collaborations in a virtual or augmented reality experience by seeing and hearing the same thing as participants by wearing a head mounted device that receives image and audio data from the server. By enabling bi-directional communications between observer head mounted devices, and between the server and participant head mounted devices, the observers wearing head mounted devices may also have the ability to interact with virtual objects seen in the head mounted displays. Observer interactions with virtual objects may include touching the augmentation to cause an effect, defining an interactive area or anchor point on the physical surface (effectively adding a new augmentation to the shared experience), and interacting with the shared mixed reality scene via gestural and/or audio inputs. Any of such changes in the virtual experience made by observers may be reflected in the head mounted displays worn by the participants and other observers.

0220<figref idref="DRAWINGS">FIG. 21</figref> illustrates an embodiment method <b>2100</b> using a server to share data between at least two devices via an identifiable directory. The directory may identify other capable devices and head mounted devices in a predetermined area. Once a head mounted device enters an area, the head mounted device may register and may store address information on a directory, which may be shared with other head mounted devices. In alternative embodiments or in a possible implementation of the embodiments the scanning function may be performed by an attached processor unit, such as a smartphone. The use of a scanning of an area by a separate device may be particularly appropriate when a lightweight head mounted device is used. This way a head mounted device may quickly determine from a centralized location if other head mounted devices are available for collaboration and to share scanning resources. Method <b>2100</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>2100</b>. The directory may be computer readable data that provides information about available devices. This facilitates sharing data over a communication network for use by multiple devices. For example, the directory may include information about scanned areas in a building with geotags associated with the directory so a device <b>10</b> knowing its position may check the directory to obtain scanned data to render a virtual object <b>14</b>. For example, the data may include data about the virtual object <b>14</b>, may include data about one or more surfaces in the area, orientation data, object position data, or any other useful or processor intensive data, which can be obtained quickly.

0221Embodiment method <b>2100</b> enables collaboration and sharing resources to minimize an amount of processing performed by the head mounted devices themselves. In method <b>2100</b>, the processor may commence operation by receiving an input request to collaborate from a first head mounted device that may be running an application in block <b>2101</b>. In block <b>2102</b>, the processor may initiate a peer to peer search for near devices for collaboration. In determination block <b>2103</b>, the processor may determine whether to collaborate with discovered devices. If so (i.e., determination block <b>2103</b>=“Yes”), the processor may create a connection between the devices. The processor may collaborate using a two way communication link. The communication link may be formed between the first and the second head mounted devices <b>10</b> and <b>10</b><i>b </i>in block <b>2104</b>.

0222The processor may access a directory in a server. Processor utilizing the directory may determine if other users are available for collaboration in block <b>2105</b> by scanning the directory. In determination block <b>2106</b>, the processor may determine whether to select a new user. The processor may determine whether to select a new user based on an input or based on a decision rules engine that may collaborate based on one or more predefined relationship rules. If the processor determines to select a new user (i.e., determination block <b>2106</b>=“Yes”), the processor may proceed to determination block <b>2107</b> to determine whether to create a connection to the new user for collaborating. In determination block <b>2107</b>, the processor may determine whether to collaborate with the new user. If the processor determines to collaborate with the new user (i.e., determination block <b>2107</b>=“Yes”), the processor may create a connection to relevant devices and may collaborate using the first and the second head mounted devices in block <b>2108</b>.

0223If the processor determines not to collaborate with the new user (i.e., determination block <b>2106</b>=“No”), the processor will output a message to the user that no further users are expected and to commence collaboration in block <b>2109</b> with the existing participants. If the processor determines not to select a new user (i.e., determination block <b>2107</b>=“No”), the processor will assume that the collaboration is declined. The processor may output a message that no further users are expected and to commence collaboration in block <b>2109</b> with the existing participants.

0224<figref idref="DRAWINGS">FIG. 22</figref> shows a high level illustration of a first head mounted device <b>2205</b> and a second head mounted device <b>2210</b> being located at two different geographic locations. <figref idref="DRAWINGS">FIG. 22</figref> illustrates a number of components of the first and the second head mounted devices <b>2205</b>, <b>2210</b> and also a VIRT service component <b>2265</b> that may provide data exchange functions between the head mounted devices <b>2205</b>, <b>2210</b>. The first and the second head mounted devices <b>2205</b> and <b>2210</b> may share digital assets including a three-dimensional map of a scanned area to reduce processing at the new head mounted device entering the new location. The sharing may increase a battery life and may assist with rendering images in a rapid manner. In another embodiment, the scanned three-dimensional map of one user may supplement the map of a second user. In another embodiment, the map of one user may replace the map of a second user. In a further embodiment, the map of one user may be referenced and used to check another's scanned data. For example, this reference may occur within a predetermined time frame.

0225At the expiration of the time frame or in the event processing constraints are burdensome the second user may utilize the first user's map. In another embodiment, the first head mounted device <b>2205</b> and the second head mounted device <b>2210</b> may be located at two far geographic locations relative to one another and may not scan similar areas. Therefore, while digital assets and virtual objects would be shared between the head mounted devices <b>2205</b> and <b>2210</b>, there may be no need to share map data as such information would not be relevant to collaboration. Instead, the sharing of three-dimensional maps may be most useful for user's that are located close by or in the same building where the head mounted devices <b>2205</b> and <b>2210</b> are required to scan an area.

0226The first user operates the first head mounted display device <b>2205</b> that may have a display <b>2215</b>, a speaker <b>2220</b>, an image scene sensor <b>2225</b> and an audio sensor <b>2230</b>. The first head mounted device <b>2205</b> may also include a wireless or wired interface <b>2260</b> and a controller that include a number of control components. In another embodiment, the head mounted device may comprise a display <b>2215</b>, a wireless interface <b>2260</b>, a battery (not shown), a speaker <b>2220</b>, and a microphone/audio sensor <b>2230</b>. Components include a scene manager block <b>2235</b>, a user control block <b>2240</b>, a surface manager block <b>2245</b>, an audio manager block <b>2250</b> and an information access block <b>2255</b>.

0227The second user also operates the second head mounted device <b>2210</b>, which include similar components. Second device <b>2210</b> may have a display <b>2215</b><i>a</i>, a speaker <b>2220</b><i>a</i>, an image scene sensor <b>2225</b><i>a </i>and an audio sensor <b>2230</b><i>a</i>. The second device <b>2210</b> may also include a wireless or wired interface <b>2240</b><i>a </i>and a controller. Controller include a number of control components including a scene manager <b>2235</b><i>a</i>, a user control block <b>2240</b><i>a</i>, a surface manager block <b>2245</b><i>a</i>, an audio manager block <b>2250</b><i>a </i>and an information access block <b>2255</b><i>a. </i>

0228Each of the devices <b>2205</b> and <b>2210</b> communicate with a control provider <b>2265</b> that may provide service functionality for each of the devices <b>2205</b> and <b>2210</b>. The control provider <b>2265</b> may assist the two devices <b>2205</b> and <b>2210</b> and may provide services on behalf of the devices so the devices <b>2205</b> and <b>2210</b> remain lightweight and do not need to necessarily perform computational intensive processing locally. Like any two Internet connected devices, the control provider <b>2265</b> may have to implement firewalls <b>2285</b> and <b>2285</b><i>a </i>to protect them from hacking attacks and malware (e.g., may be provided by local software, Internet service providers and/or enterprise service providers). Firewalls <b>2285</b> and <b>2285</b><i>a </i>restrict access to the control provider <b>2265</b>. In another embodiment, the firewalls <b>2285</b> and <b>2285</b><i>a </i>are optional and are absent.

0229The control provider <b>2265</b> may include a directory <b>2280</b>, which maintains data pertaining to many devices including identification and routing information to the devices <b>2205</b> and <b>2210</b>. The control provider <b>2265</b> may also include a scene storage block <b>2270</b>. The scene storage block <b>2270</b> processes data relating to surface and contour information of scanned images. The surface and contour data may include distance, shape and orientation data. The scene storage block <b>2270</b> may permit a first user to map a first area, and store the data for the benefit of a second user's head mounted device to more rapidly render the scene or to verify scanned data parameters. The control provider <b>2265</b> facilitates sharing digital assets. The control provider <b>2265</b> may provide a communication link between the wireless interface <b>2260</b> and <b>2260</b><i>a</i>, which may be optimized. The control provider <b>2265</b> may also facilitate connectivity by different network topologies, firewalls and IP addressing architectures.

0230Each device <b>2205</b> and <b>2210</b> may embed location data into the data collected pertaining to the mapped and scanned image and scanned surfaces. For example, a first head mounted device <b>2205</b> may scan a room including objects in the room. The scanning may result in the aggregation and collection of positional data for the objects, contour data of the objects, distance data from the object to the head mounted device, and orientation data of the head mounted device and the objects. The scanning may result in data, which may be communicated to the router <b>2275</b>. Together with the data, the first head mounted device <b>2205</b> processor may embed location data into the scanned data. The location data may be coordinates in longitude, latitude and elevation. The first communication device <b>2205</b> designates each surface in a local physical environment. The processor may be able to identify which shared data may be placed on each surface so another device may quickly be able to located and utilize the data.

0231The first head mounted device <b>2205</b> may write data to a cloud based service <b>2265</b>. Such a service <b>2265</b> may provide computation, software, data access, and storage services for the head mounted devices. The head mounted devices do not require end-user knowledge of the physical location and configuration of the service <b>2265</b>. The cloud-based service <b>2265</b> may have a lookup directory <b>2280</b> stored thereon. Service <b>2265</b> resides on a server. The service <b>2265</b> resources may be dynamically provisioned to head mounted devices on a fine-grained, self-service basis over the Internet, via web applications/web services executable on the head mounted devices. The service <b>2265</b> may be located on an off-site third-party provider. The directory <b>2280</b> assists the first device <b>2205</b> and facilitates connectivity via a router <b>2275</b> between the remote users <b>2205</b>, <b>2210</b>. In this manner, the second head mounted device <b>2210</b> may determine that the head mounted device <b>2210</b> is in a particular location and may communicate the location to the router <b>2275</b>. The service <b>2265</b> may involve provisioning of dynamically scalable resources. Head mounted devices may be loaded with a web-based tool or an application that a user can access and use through a web browser as if the program was installed locally on their own head mounted device. The service <b>2265</b> may deliver applications via the internet, which are accessed from web browsers, while the software and data are stored on servers at a remote location. Service <b>2265</b> may be transmitted through shared data-centers and appearing as a single point of access for head mounted devices. In response, data from the scene store <b>2270</b> that was generated from the first head mounted device <b>2205</b> may be transmitted to the scene manager and surface manager blocks <b>2235</b><i>a </i>and <b>2245</b><i>a </i>to avoid additional computational processing to render the image. The second head mounted device <b>2210</b> may verify data generated by the scene sensor block <b>2225</b><i>a </i>or may utilize the data transmitted from the scene store block <b>2270</b> to render an image on the display <b>2215</b><i>a </i>to avoid additional computational processing to render the image.

0232<figref idref="DRAWINGS">FIG. 23</figref> illustrates a high level diagram for a first head mounted device <b>2205</b>. A first head mounted device <b>2205</b> may be located in close proximity to a second head mounted device <b>2210</b>. The head mounted devices <b>2205</b> and <b>2210</b> may exchange data via one or more fast wireless data links. The first head mounted display device <b>2205</b> may have a display <b>2215</b>, a speaker <b>2220</b>, an image scene sensor <b>2225</b> and an audio sensor <b>2230</b>. The first head mounted device <b>2205</b> may also include a wired interface connection to a user data store <b>2301</b>, where data may be written for access. The first device <b>2205</b> may also include a wired or wireless connection to shared data storage <b>2302</b>, which may be a memory that the second mobile communication device may access. First device <b>2205</b> may also have a controller that include a number of control components include a scene manager <b>2235</b>, a user control block <b>2240</b>, a surface manager block <b>2245</b>, an audio manager block <b>2250</b> and an information access block <b>2255</b>.

0233The second user also operates the second head mounted device <b>2210</b>, which include similar components to the first head mounted device <b>2205</b>. Second device <b>2210</b> may have a display <b>2215</b><i>a</i>, a speaker <b>2220</b><i>a</i>, an image scene sensor <b>2225</b><i>a </i>and an audio sensor <b>2230</b><i>a</i>. The second device <b>2210</b> may also include a wireless or wired interface. The second device <b>2210</b> may write and read data to/from a user data store memory <b>2303</b>. The second device <b>2210</b> may also read and write data to a shared data store memory <b>2302</b> accessible by the first device <b>2205</b>. The second device <b>2210</b> may also have a controller that includes a number of control components or modules. The second device <b>2210</b> may include a scene manager block <b>2235</b><i>a</i>, a user control block <b>2240</b><i>a</i>, a surface manager block <b>2245</b><i>a</i>, an audio manager block <b>2250</b><i>a</i>, and an information access block <b>2255</b><i>a. </i>

0234In this regard, users may share a set of scanned surface data that have been designated. Users may interact with virtual assets that are placed onto the surfaces as virtual objects. The first and second device <b>2205</b> and <b>2210</b> may communicate over a local fast wireless data carrier (for example Wi-Fi®, Qualcomm® Peanut® short range communication standard, and Qualcomm® FlashLinQ®). If additional users are present, the devices <b>2205</b>, <b>2210</b> may further communicate via peer-to-peer connections or a broadcast, unicast, or multicast.

0235<figref idref="DRAWINGS">FIG. 24</figref> illustrates an embodiment method <b>2400</b> using a server to tag data with location information and share the tagged data between at least two head mounted devices via a directory. Method <b>2400</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>2400</b>. The directory may provide information about scanned three-dimensional maps. For example, the head mounted device may emit infrared light and calculate a time of flight of the infrared light via a fast gating mechanism and may store the calculations to determine the distance certain objects are from the head mounted device <b>10</b>. Additionally, the head mounted device <b>10</b> may scan an area to determine an orientation of the objects, to determine surfaces, and structural information of the objects and height, width, length and distance information.

0236In block <b>2401</b> of method <b>2400</b>, the processor may commence operation by receiving data from a head mounted device. In block <b>2402</b>, the processor may receive image data. In block <b>2403</b>, the processor may calculate the distance and orientation. The processor may process the content for display in block <b>2404</b>. The processor may render the image with the virtual object contained within the displayed image in block <b>2405</b>. In determination block <b>2406</b>, the processor may determine whether to tag the image with location information so that another head mounted device may utilize the image data.

0237A second device may include a second processor that may calculate image data and may utilize the first device scanning capabilities as a resource to verify the scanned parameters as a reference. In another embodiment, the second device may import the scanned data. Using the imported data, the second device may render the displayed image with a virtual object anchored on at least one surface in the displayed image. This may occur when the second head mounted device <b>10</b><i>b </i>enters a location. The second head mounted device <b>10</b><i>b </i>may determine its location in an area, for example, a room and then communicate the location data thereby forming a requested for the first head mounted device's <b>10</b> scanned data.

0238If the processor decides to tag the image with location information (i.e., determination block <b>2406</b>=“Yes”), the processor may tag the scanned data with the location information for the directory and store the data on a server in block <b>2407</b> so another head mounted device <b>10</b><i>b </i>may access the scanned data. In an alternative, instead of storing the data on a server, in block <b>2407</b> the data may be stored in a shared memory, such as a memory accessible via a shared network. If the processor decides not to tag the image with location information (i.e., determination block <b>2406</b>=“No”), the processor may determine that no other devices are available to utilize the shared data and will continue scanning the area in block <b>2408</b> to render the virtual object for the instant user.

0239<figref idref="DRAWINGS">FIG. 25A</figref> illustrates an embodiment of a system <b>2500</b> with three mobile devices <b>2501</b>, <b>2502</b>, and <b>2503</b> and a server <b>2504</b>. The devices <b>2501</b>-<b>2503</b> and the server <b>2054</b> exchange scanned data and map information. The map may include scanned parameters of a room. The map may include an identification of surfaces in the image, such as a flat screen display <b>2530</b> and a table <b>2532</b>, including shapes and sizes of objects in the image. The map may also include a distance and angle that the objects are located from the device, or coordinate locations within a frame of reference linked to room or arbitrary coordinates. For example, the map may identify locations of objects in terms of a number of meters from an origin along three perpendicular coordinate axes, such as along the three axes (e.g., length, width, height) defining a particular corner of the room. The map may include a header that relates to a three-dimensional position and location of the device where the objects were captured. Map data may be uploaded to a server <b>2504</b> from each position where the device scans image data, and the server may use distance measurements and images from all head mounted devices and from all locations to build a map based on the frame of reference linked to the room. To do so, the server <b>2504</b> may perform a coordinate transformation on all received location data to transform distance measurements from head-mounted device-centric spherical coordinates (i.e., distance and angle from the head mounted device to each object) to an arbitrary rectilinear coordinate system, such as to locate objects with respect to room length, width and height coordinates. The mathematics and algorithms for accomplishing such coordinate transformations are well known in the art.

0240The embodiment of a system <b>2500</b> is not limited to a head mounted device but instead may further be applicable to a different computing device. Alternatively, the head mounted device <b>10</b> may be an accessory to a mobile CPU (phone, tablet etc.) with the main processing performed on the mobile CPU and data being exchanged by and between the mobile phone and a head mounted device (not shown). <figref idref="DRAWINGS">FIG. 25A</figref> illustrates how collaboration may occur to scan and to render the image quickly using a centralized database server <b>2504</b>. For example, the devices <b>2501</b>, <b>2502</b>, and <b>2503</b> may include a device for emitting and sensing light or ultrasound for measuring distances to objects and surfaces in a room via time of flight calculations. In another embodiment, a RGB-D camera may capture image data. The devices <b>2501</b>, <b>2502</b>, and <b>2503</b> may utilize the scanned data to generate a virtual object and anchor the virtual object on at least one surface of the image and render the virtual object together with the captured image to provide a virtual or augmented reality experience.

0241The first device <b>2501</b> may create a partial map and upload the map to a server <b>2504</b>. The partial map may include data pertaining to a first and a second object in the image for location 52.23.0.14. The map may include a header that identifies the location. The map may also include substantial data about the scanned images including distance from the device <b>2501</b>, object length, object width and object height, orientation of the objects, and distance that the objects are from a wall, ceiling, doorway, etc. The individual coordinates and positional data of each object may also be recorded and stored in the map.

0242The second device <b>2502</b> may report its location to the server <b>2504</b> via coordinates (52.23.0.14), which correspond to a predetermined location, which may have already been scanned by the first device <b>2501</b>. The second device <b>2502</b> may upload the location data to the server <b>2504</b>. The server <b>2504</b> may receive the location data. The second device <b>2502</b> may receive a message that a partial map is available. The second device <b>2502</b> may download a partial map formed by the first device <b>2501</b>. Substantially simultaneously, the second device <b>2502</b> may be scanning a different portion of the room. For example, the second device <b>2502</b> may scan a portion of the room adjacent a first table. The second device <b>2502</b> may utilize the scanned data and merge the scanned data with the downloaded map to render a displayed image with the virtual object. The second device <b>2502</b> may also upload the updated map to the server <b>2504</b>.

0243The third device <b>2503</b> may also provide its location data 52.23.0.14 in the form of a request. The server <b>2504</b> may receive the location data 52.23.0.14 and coordinates and select an appropriate data set and transmit the data set of scanned data in the form of a map to the third device <b>2503</b>. The third device <b>2503</b> may download the map data that include the first device's <b>2501</b> scanned data and the second device's <b>2502</b> scanned data, which may supplement the first device's <b>2501</b> scanned data. In another embodiment, the data may not supplement and instead the second device <b>2502</b> may scan to determine if the first data set is accurate and may verify the data set. In another embodiment, if the data is incorrect, the second device <b>2502</b> may replace the scanned data of the first device <b>2501</b>.

0244The third device <b>2503</b> may utilize the map to render a displayed image with a virtual object. As shown, the third device <b>2503</b> may quickly determines a location of objects in the image including a flat screen television <b>2530</b> and a table <b>2532</b> utilizing the updated map. The third device <b>2503</b> may further capture image data and may scan a new area of the room and may also upload data to the server <b>2504</b> corresponding to an update of the map. In this manner, each of the devices <b>2501</b>, <b>2502</b> and <b>2503</b> does not need to process the entire image locally and may obtain services to more quickly render the virtual object and displayed image.

0245Each of the devices <b>2501</b>, <b>2502</b> and <b>2503</b> and server <b>2504</b> may be optimized with one another to quickly receive the map and piece together the scanned data and map components to render the scene quickly. For example, if a device <b>2501</b> is in a new location and there have been no scanned images recorded, the device <b>2501</b> may scan an entire area. For example, the device <b>2501</b> may alternatively determine that the scanned data is old and was recorded some time ago. The device <b>2501</b> may determine that the scanned data is stale, and decide to scan an entire area.

0246Alternatively, the device <b>2501</b> may compare the age of the scanned data to a threshold value and may make a determination whether to scan the entire area. For example the device <b>2501</b> may calculate a time to scan an entire room and may accept or reject a stale map if the time to scan the entire room is above a predetermined limit based on a processing requirement. Alternatively, the device <b>2501</b> may monitor a location of other devices <b>2502</b>, <b>2503</b> and form a request to receive a scanned image based on the monitored location. For example, the device <b>2501</b> may determine that the devices <b>2502</b>, <b>2503</b> are in a different far area located far away and a request for a map is likely to render irrelevant data (not useful) and formulating a request is unnecessary. In yet another embodiment, if several devices <b>2501</b>, <b>2502</b> and <b>2503</b> are present each device may scan different areas in the room in order to scan a room in a more rapid manner.

0247<figref idref="DRAWINGS">FIG. 25B</figref> illustrates an embodiment method <b>2506</b> for cloud storage and retrieval of data utilized to generate a virtual object on a head mounted display. Method <b>2506</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operation of the method <b>2506</b>. Generating a virtual object may require intensive scanning of surfaces in a room to determine a distance of the objects, shape of the objects and the orientation of objects in order to anchor a virtual image to one or more surfaces in the room. Some head mounted devices may download their location to a cloud and instantly receive accurate data to assist with rendering a virtual object on a surface so as to avoid processing the data locally and to verify scanned data. In method <b>2506</b>, the processor may commence operation by capturing images of a user with a head mounted or body mounted camera in block <b>2508</b>. In block <b>2510</b>, the processor may provide program instructions to scan an area of a room to capture spatial data with a sensor array. This may be accomplished by scanning with an infrared light emitting device and measuring a time of flight of the infrared light reflected from the surfaces.

0248The data may be also provided to a processor that may generate a three-dimensional map of the room. The processor may recognize objects in the captured image and may determine a distance parameter of the objects in the captured image and may also determine an orientation of surfaces contained within the image in block <b>2512</b>. The processor may generate a virtual object in block <b>2514</b>. In an embodiment, the virtual object <b>14</b> may resemble a collaborative flat screen three-dimensional object <b>14</b> that emits content. The virtual object <b>14</b> may be anchored to a surface <b>16</b> in the image and the user may move around the room but the virtual object display parameters change so the virtual object remains anchored to a desired anchor surface. The processor may calculate parameters including distance and orientation to display the virtual object in block <b>2516</b> and may tag the calculated parameters and upload the calculated parameters to a cloud server in block <b>2518</b>. The processor may tag the calculated parameters with a location tag that may be a geotag. In another embodiment, the geotag may include latitude coordinates, longitude coordinates, altitude coordinates, bearing coordinates, distance coordinates, and accuracy data. The Geotag adds geographical identification metadata to various the uploaded parameters. The Geotag may help users find a wide variety of location-specific information in the three-dimensional map of the scanned area.

0249In determination block <b>2520</b> the processor may determine whether a second head mounted device has entered a location for which to receive complementary shared data to generate the virtual object faster for a particular location. For example, a second head mounted device may be in the same room and may emit a signal to a first head mounted device, or may emit a signal to the cloud server, which determines that the second device has entered a specific location. Processing an image can be burdensome for some devices. Also, scanning a room may also be time consuming. The second head mounted device, therefore, may take advantage of the work that the first head mounted device has already done and receive the calculated parameters pertaining to objects, and surfaces in the room to generate a virtual object for the second user faster.

0250If the processor determines that it has entered a new room (i.e., determination block <b>2520</b>=“Yes”), in block <b>2522</b>, the second head mounted device may transmit its location data from a navigation device and may download the tagged calculated parameters from the server. In block <b>2524</b>, the processor of the second head mounted device may generate the virtual object using the accessed and tagged calculated parameters. If the processor determines that it has not changed locations (i.e. determination block <b>2520</b>=“No”), the processor may perform operations to verify that the calculated parameters are correct in the event another third head mounted device already scanned the area and generated an anchored virtual object. In block <b>2526</b>, the first head mounted device may transmit its location from a navigation device and may download calculated parameters from a server. In block <b>2528</b>, the processor may verify the calculated parameters with the downloaded calculated parameters from the server.

0251In another embodiment, instead of calculated parameters including distance and orientation of objects, a three-dimensional map may be formed of a particular area and uploaded to the cloud server. The tag or location data may be embedded in the form of a header into the three-dimensional map message and the three-dimensional map may be transmitted and stored in a cloud server for access by the second head mounted device. For example, when a second head mounted device enters an area, the second head mounted device may upload its location coordinates and may download a three-dimensional map of a room, or predetermined area. The second head mounted device may recognize objects within the image and may determine the distance parameter of the objects within the image utilizing the three-dimensional map. This may occur with minimal processing of the spatial data and the image captured at the second head mounted computing device. In another embodiment, metadata may be stored to the cloud server. The metadata may include distance and orientation of objects that were captured, which may be accessed by different head mounted devices. The metadata may also include indoor location data relating to locations of objects in a room and an indication that the processor can use to determine whether the data is stale.

0252<figref idref="DRAWINGS">FIG. 26</figref> illustrates an embodiment method <b>2600</b> for displaying a virtual object superimposed over a detected body part, which is detected in tracked images by applying and comparing an anatomical model to the tracked images. Method <b>2600</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>2600</b>. In block <b>2601</b> of method <b>2600</b>, the processor may commence operation by receiving data from a head mounted device including sensors that provide data regarding orientation of the device (e.g., accelerometers, gyroscopes, electronic compass, etc.). In block <b>2602</b>, the processor may receive image data. In block <b>2603</b>, the processor may calculate the distance and orientation and process the content for display in block <b>2604</b> utilizing the distance sensor data, camera data, orientation data and distance data. The processor may render the image with the virtual object in block <b>2605</b>.

0253At determination block <b>2606</b>, a decision may be reached regarding whether to superimpose a virtual object over a surface of a detected body part contained in the displayed image of the head mounted display. If the processor decides to superimpose the virtual object over a surface of a detected body part (i.e., determination block <b>2606</b>=“Yes”), the processor may superimpose the virtual object over a body part in block <b>2607</b>. If the processor decides not to superimpose the virtual object over a surface of a detected body part (i.e., determination block <b>2606</b>=“No”), the processor will not superimpose the object over the body part in block <b>2608</b> and may allow the body part to occlude the virtual object or may render the virtual object in a different location of the display. For example, the virtual object may be superimposed according to an input by the user received by the processor.

0254<figref idref="DRAWINGS">FIG. 27</figref> illustrates an embodiment method <b>2700</b> where a user's hands may be occluded over a virtual object by tracking images and applying an anatomical model to the tracked images to detect body parts contained in the image. In block <b>2701</b> of method <b>2700</b>, the processor may commence operation by receiving data from a head mounted device including sensors that provide data regarding orientation. In block <b>2702</b>, the processor may track images. In block <b>2703</b>, the processor may apply an anatomical model to the tracked image. In block <b>2704</b>, the processor may identify the user's hands and render the image in block <b>2706</b>. For example, the processor may identify fingers, a hand, and an arm that originate from a bottom upwardly in the tracked images as a user's hand. While at the same time, an anatomical or skeletal tracking algorithm may be applied to detect a second body part. The second body part may also include fingers, a hand, and an arm. The processor may infer that a second body part originating at a top and extending downwardly in the image may be another user's body part. Additionally, the processor may infer that arms and hands that are a predetermined distance too far away from the user based on size and orientation in the image may be another user's determined body part.

0255At determination block <b>2706</b>, a decision may be reached regarding whether to occlude the user's hands over the virtual object. If the processor determines to render the user's hands over the virtual object (i.e., determination block <b>2706</b>=“Yes”), in block <b>2707</b>, the processor may render the virtual object with selective occlusion of the user's hands over the virtual object. For example, the user's hands may block the virtual object from the viewer. In block <b>2708</b>, the image may be updated by the processor. If the processor determines not to render the user's hands over the virtual object (i.e., determination block <b>2706</b>=“No”), in block <b>2709</b>, the processor will display the virtual object superimposed over the user's body part so the body part appears transparent. For example, the user may run his hand over the virtual object. However, the virtual object may be displayed over the body part and superimposed over the surface of the hand so the content on the virtual object remains seen, despite the fact that the user's hand should be blocking the virtual object. Once a command is detected and confirmed from the user by a detected gesture, or input command, the input results in execution of the task and action of the detected command and the virtual object content may be updated in block <b>2709</b>.

0256<figref idref="DRAWINGS">FIG. 28A</figref> illustrates an embodiment method <b>2800</b> where a second individual's hands may be rendered transparent or absent over a virtual object. Method <b>2800</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>2800</b>. In method <b>2800</b>, the processor may commence operation by receiving data from a head mounted device including sensors that provide data regarding orientation in block <b>2801</b>. In block <b>2802</b>, the processor may track captured images. In block <b>2803</b>, the processor may apply an anatomical model to the tracked image. For example, the anatomical model may be a skeletal tracking algorithm that compares tracked objects to a skeletal model to determine if there are any body parts contained in the image. If an object is not detected to be a body part by the processor, the processor may ignore the object.

0257In block <b>2804</b>, the processor may identify the user's hands and a second individual's hands. The processor may render the image in block <b>2805</b> on an anchor surface contained in the image, for example, on a desktop or on a wall. At determination block <b>2806</b>, the processor may determine whether to superimpose the virtual object over a body part. If the processor determines to superimpose the virtual object over a body part (i.e., determination block <b>2806</b>=“Yes”), in block <b>2807</b>, the processor may render the second individual's hands transparent or absent over the virtual object, or when the body part occludes the virtual object, the virtual object may be displayed over a top surface of the body part so the body part appears to be transparent. In another embodiment, an outline of the body part may still remain visible with virtual object superimposed over a body part surface. In block <b>2808</b>, the displayed image of the virtual object may be updated by the processor to account for changes in the content and movement of the body part. If the processor determines not to superimpose the virtual object over a body part (i.e., determination block <b>2806</b>=“No”), the processor will display the virtual object in block <b>2809</b> and update the virtual object for movement of the user.

0258<figref idref="DRAWINGS">FIG. 28B</figref> illustrates an embodiment method <b>2810</b> where a processor may infer which hands are the user's hands and which hands are other user's hands and the processor may render the other user's hands as transparent or absent when the hands occlude a virtual object. Method <b>2810</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>2810</b>. In method <b>2810</b>, the processor may commence operation by receiving data from a head mounted device including captured image data in block <b>2811</b>. In block <b>2812</b>, the processor may capture spatial data with a sensor array. In block <b>2813</b>, the processor may recognize objects in the image and determine a distance parameter of the objects in the image. In block <b>2814</b>, the processor may process images to track objects and the processor may apply an anatomical analysis via a skeletal model to the tracked image. This may include identification of a partial anatomy when the camera is mounted on the user or where another user is only partially visible in the field of view of the sensor. For example, the anatomical model may be a skeletal tracking algorithm that compares tracked objects to a skeletal model to determine if there are any body parts contained in the image. If an object is not detected to be a body part by the processor, the processor may ignore the object. For example, the processor may apply an anatomical analysis to the image to determine whether a body part is within the image. The processor may reference a stored anatomical or skeletal model within a memory and compare it to the tracked objects in the video image. The stored skeletal model may include anatomical data, for example, a relative position of key joints, bones and limbs in a human skeleton, and other data. The processor may compare the tracked objects in the image to the stored skeletal model to determine if the body part is in the image.

0259For example, the processor may detect the user's arm by detecting an arm and a number of fingers extending from a hand in a first orientation, or with an arm, a wrist and fingers progressing from a bottom of an image upwardly. The processor may detect the second individual's arm by detecting a second arm and a second number of fingers extending from the second hand in a second different orientation, or with an arm, a wrist and fingers progressing from a top of the image downwardly. In another embodiment, the processor may distinguish from between the user and another's body parts by reviewing the tracked images for orientation, object size, distance from the user, or by counting the number of body parts within the image.

0260In block <b>2815</b>, the processor may render the image with an anchored virtual object in the image. At determination block <b>2816</b>, the processor may determine whether the detected body part belongs to the user or to another individual. The processor may superimpose a virtual object over another user's body part. In the displayed image only the user's hands occlude the virtual object while other hands, arms and body parts will not occlude the virtual object and will appear transparent.

0261The user may see the virtual object as superimposed over the other user's body part so the other user's body part is rendered as transparent. The processor may determine an area in the image relevant to the other individual's body part and may display the virtual object over the image only when the other individual's body part occludes the anchored virtual object. If the processor determines that the detected body part belongs to the user (i.e., determination block <b>2816</b>=“Yes”), in block <b>2818</b>, the processor may render the user's body part as solid when the user's body part occludes the image in block <b>2817</b>. If the processor determines that the detected body part belongs to another individual, (i.e., determination block <b>2816</b>=“No”), the processor will display the virtual object, or a portion thereof as superimposed over the detected body part in block <b>2819</b> when the body part occludes the virtual object.

0262For example, the processor may determine an area in the image defined as an area (in pixels) over the body part of the other individual. The processor may form the superimposed virtual object over the area and not render the virtual object over the perimeter of a body part. When the body part is located over the anchored virtual object an outline of the body part of the second individual may still be shown and rendered. Therefore, the outline may be visible over the anchored virtual object while a remainder may be rendered as transparent. In block <b>2819</b>, the processor may update the virtual object for movement of the user to account for changes in the content and movement of the body part. For example, the processor may display the anchored virtual object as a rectangular virtual display on a surface. As described above, the processor may analyze captured images to detect user gestures. A seemingly virtual reality interaction with the anchored virtual object by the second individual and the user may occur. In another embodiment, the processor may detect a body part of a third individual. The processor may display a superimposed virtual object over the body part of the third individual when the body part of the third individual is located over the anchored virtual object. The processor may also not display the superimposed virtual object over the body part of the third individual and allow the body part to be displayed when the body part is determined to be located off the anchored virtual object and not occluding the virtual object.

0263<figref idref="DRAWINGS">FIG. 29</figref> illustrates an embodiment method <b>2900</b> where data may be transmitted from a server to multiple devices to provide services and to alleviate processing at the head mounted device. The method <b>2900</b> may be implemented within a system like that described above with reference to <figref idref="DRAWINGS">FIG. 25A</figref>, which may include a server and one or more head mounted devices configured with processor-executable instructions to perform the operations of the method <b>2900</b>. In method <b>2900</b>, the server <b>2504</b> may receive image and location data from a head mounted device including sensors that provide data regarding spectral data and images in block <b>2901</b>. In block <b>2902</b>, the processor may upload data to the server with position information relating to a location where the data was scanned. The server may output scanned data to a number of different head mounted devices. In block <b>2903</b>, the processor may output data to a second head mounted display as a reference.

0264In block <b>2904</b>, the processor may output data to a third head mounted device to supplement the third head mounted device's scanned data and to verify the captured scanned data. In block <b>2905</b>, the server may output data to a fourth head mounted device to enhance the data present on the device and in block <b>2906</b>, the server may upload data to conserve battery power and processing. Substantially simultaneously, each of the head mounted devices may be conducting their own scanning of the area to determine information about objects in the area. For example, the head mounted devices may scan the area to determine a shape and dimensions of objects in the image, and may scan the area to determine an orientation of the objects in the image and relative positions of surfaces in the image, which may be useful to anchor a virtual object for an immersive virtual or augmented reality experience. At determination block <b>2907</b>, the processor may determine whether to upload the updated scanned positional data from the devices to the server for storage on the server. If the processor determines to upload scanned positional data to the server (i.e., determination block <b>2907</b>=“Yes”), the processor may upload updated data and merge and combine the head mounted devices scanned data with the data stored on the server. If the processor determines not to upload scanned positional data to the server (i.e., determination block <b>2907</b>=“No”), the processor may display the virtual object in block <b>2908</b> and update the virtual object for movement of the user.

0265In another alternative embodiment, the processor of <figref idref="DRAWINGS">FIG. 29</figref> may operate as a ‘magic lens’. In this manner, the virtual object displayed on a physical surface in a room may be viewed on a conventional smartphone or computing device. Such a smartphone may output data to a server and may further link to the server. A user, without a head mounted device, and using a mobile communication device, may collaborate using the mobile communication device or smartphone with users wearing the head mounted displays. For example, a user may view an output of a virtual object anchored on a physical surface by watching a smartphone display and may communicate via a wireless audio link to the user utilizing a head mounted display.

0266The smartphone may be operatively connected to the server via a wireless RF link, such as a cellular data link (e.g., 3G, 4G, LTE, UTMS, etc.). The smartphone may output an image on a display of the smartphone. The image may correspond exactly to another user's head mounted display output. The user viewing the display on the smartphone may view the augmentations and virtual objects shown on physical surfaces. This display may occur in two or three dimensions on the display of the smartphone. The smartphone may also be operable to collaborate with the head mounted device <b>10</b> using a mobile communication device and a wireless interface to receive signals from the server. Alternatively, the smartphone may receive RF data signals using a short range communication protocol directly from the head mounted device <b>10</b>. In this manner, the user may hold up the smartphone and view the virtual or augmented reality experience of the users of the head mounted display for collaboration. In this embodiment the smartphone may manipulate the image to correct for the smartphone's own position and orientation in relation to near by surfaces using methods similar to those described herein.

0267<figref idref="DRAWINGS">FIG. 30</figref> illustrates an embodiment method <b>3000</b> where users may be collaborating using two head mounted devices. The two head mounted devices may be running different incompatible software applications from two different software providers. Generally, a first user using a first word processor cannot work with another user using a second different incompatible word processor at the same time in a collaborative fashion. In method <b>3000</b> a processor may reconcile and translate data so a first user using a first software application and a second user using a second software application can collaborate with one another and enter data that is viewable in real time.

0268The method <b>3000</b> is not limited to a head mounted device and may be implemented in other types of computing device. In method <b>3000</b>, the processor may commence operation by opening a first application in block <b>3001</b> and opening a second application in block <b>3002</b>. At determination block <b>3003</b>, the processor may decide whether to collaborate with other devices. If the processor decides to collaborate with other devices (i.e., determination block <b>3003</b>=“Yes”), in block <b>3004</b>, the processor may collaborate and provide a two way communication between the devices. If the processor decides not to collaborate with other devices (i.e., determination block <b>3003</b>=“No”), the processor will display the virtual object in block <b>3010</b> and update the virtual object for movement of the user.

0269In block <b>3005</b>, the processor will render a virtual screen as the virtual object. The virtual screen may provide a display output of a software application. The virtual screen updates for changes entered by at least two different users. In block <b>3006</b>, the processor will apply a conflict resolution program for two different software applications. The conflict resolution may provide a translation of the inputs and outputs of the two incompatible software programs to a generic format, which may be loaded to a third generic software program, which reconciles changes in the generic format, and translated the reconciled data back into the first and second incompatible formats. The third software program may provide a translation of the generic format back to the first and the second software programs to render the changes, and which can be viewable by the users in the original native program.

0270For example, data may be collected from a first software program pertaining to the inputs of the first user and communicated to a generic format and communicated to a third software program. Next, the data may be collected from a second software program pertaining to the inputs of the second user and communicated to a generic format and communicated to the third software program.

0271The third software program may reconcile the changes and may store the changes in a memory. Now, each of the users would like to view each other's changes to a document in real time. The third software program may translate the changes into a format understood by each of the first and the second software programs. The third software program may output the translated changes back to the first and the second software program so each of the users may view the total changes in their native program's formatting. In block <b>3007</b>, the processor may also identify an author of the changes. In block <b>3008</b>, the processor will update the document map and render the document image as the virtual object in block <b>3009</b> and the processor may update the virtual screen in block <b>3005</b>.

0272<figref idref="DRAWINGS">FIG. 31</figref> shows a high level block diagram of three different users operating a computing device shown as reference numeral <b>3100</b>, <b>3101</b> and <b>3102</b>. Each may be using a different software application. Data from each of the software programs may be stored on the server <b>3103</b>. For example, first local changes may be made in the relevant software program as conventionally known. Second remote changes may also be made and written to a shared storage medium <b>3106</b>. For example, the second remote data changes may be communicated to a library <b>3104</b>. Library <b>3104</b> may convert the input data and output data from each application from the remote changes into a generic format that can be input and read by a generic software program. The generic format may be stored on a library <b>3104</b> and may be written to a shared document format on storage medium <b>3106</b>.

0273The shared document format stored on the storage medium <b>3106</b> may aggregate the changes into a single generic program. The single generic program may also translate and output the changes rendered by each user in a single stream of data back to each of the software application in a format that may be specific to and understood by the relevant software application so each user <b>3100</b>, <b>3101</b>, and <b>3102</b> can view changes made by other users.

0274For example, the shared document format <b>3106</b> may include a conflict resolution functionality that may provide a translation of the inputs and outputs of the software programs to a generic format, which may be loaded to the third independent software program <b>3106</b>. There, the changes from all of the users are entered and stored. A translation of a number of different software word processing programs may be stored on the server <b>3103</b>. The processor may provide a translation of the generic format having all of the changes back to the first, the second and the third software programs <b>3100</b>, <b>3101</b> and <b>3102</b> to render and illustrate the changes therein.

0275<figref idref="DRAWINGS">FIG. 32</figref> illustrates an embodiment method <b>3200</b> where users may be collaborating using two computer systems. The users may be collaborating with one another utilizing different incompatible software applications from two different software providers. The method <b>3200</b> may reconcile the inputs and outputs of the data so any and all changes are viewable by multiple users utilizing multiple different incompatible computer software applications.

0276In method <b>3200</b>, the processor may commence operation by opening a first application in block <b>3201</b> and opening a second application in block <b>3202</b>. At determination block <b>3203</b>, a decision may be reached regarding whether to collaborate from the devices to a server. If the processor determines to collaborate with a server (i.e., determination block <b>3203</b>=“Yes”), the processor outputs program instructions for a collaboration and provide a two way communication between the devices (block <b>3204</b>). For example, changes on each of the incompatible software applications may be rendered locally and also transmitted to a remote location, where the changes may be aggregated and entered into a third software program. If the processor determines not to collaborate with a server (i.e., determination block <b>3203</b>=“No”), the processor will not establish the two way communication between the devices and render the screen in block <b>3210</b> and update changes made in a non-collaborative manner.

0277In block <b>3205</b>, the processor will render a screen and update the screen for changes. For example, changes on each of the software applications may be transmitted to the remote location, where the changes are aggregated and entered into the third compatible software program. In block <b>3206</b>, the processor will apply a conflict resolution program for two different software applications. The changes are then translated into a native format, and then are transmitted to each of the users in the native format for display on the respective applications. In block <b>3207</b>, the processor will identify an author of the changes. In block <b>3208</b>, the processor will update the document image and render the document image. In block <b>3209</b>, the processor will update the document image.

0278<figref idref="DRAWINGS">FIG. 33</figref> illustrates an embodiment method <b>3300</b> where an audio command may be processed and confirmed using a detected gesture. Method <b>3300</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>3300</b>. In method <b>3300</b>, the processor may commence operation by receiving scanned data from sensors that provide data regarding orientation of the head mounted device in block <b>3301</b>. In block <b>3302</b>, the processor may receive image data from the camera regarding images. In block <b>3303</b>, the processor may calculate distance and orientation of objects within the images. In block <b>3304</b>, the processor may process the image using data from sensors, camera data and distance data and in block <b>3305</b> the processor may render the image with the virtual object. Additionally, in block <b>3305</b>, the processor may track the user's movements to determine if there is a gestural input command that is to be executed. In block <b>3306</b>, the processor may receive an audio signal.

0279At determination block <b>3307</b>, the processor may determine whether an audio command spoken by the user is recognized. For example, the user may desire to enlarge a size of the virtual object to a larger virtual object rendered on the display and may speak the word “enlarge virtual object.” For example, the user may alternatively wish to change a shape of the virtual object from rectangular to a different shape and may speak a word “change virtual object to oval”. Other similar commands are also envisioned and possible and within the scope of the present disclosure. If the processor recognizes an audio command spoken by the user (i.e., determination block <b>3307</b>=“Yes”), in block <b>3308</b>, the processor may track video data for a gesture for a predetermined time period. The gestural command may be utilized to confirm the first audio command. For example, the user may be speaking and may simply inadvertently mention “enlarge” and “virtual object” in a sentence speaking to a second user, which may be received by the microphone and communicated to a processor. Thereafter, instead of blindly executing the command, a confirmation may be awaited in the form of a detected gesture. For example, the user may point in a direction or the user may give an “O.K.” sign with a thumb making an index finger and the remaining fingers being outstretched. This second command will confirm the first command. At determination block <b>3309</b>, the processor may determine whether a gesture is recognized confirming the audio command. If the processor recognizes that a gesture is confirming the audio command (i.e., determination block <b>3309</b>=“Yes”), the processor may execute the task in block <b>3310</b>.

0280If the processor does not recognize an audio command spoken by the user (i.e., determination block <b>3307</b>=“No”), the processor may continue to receive audio. If the processor does not recognize that a gesture is confirming the audio command (i.e., determination block <b>3309</b>=“No”) the processor may continue to receive and analyze audio data. For example, if the user may be speaking and may simply inadvertently mention “enlarge” and “virtual object” in a sentence speaking to a second user. However, if no confirmation is detected in the form of the detected gesture (pointing, O.K. sign, outstretched hand), the processor will not execute the first command and simply may continue to monitor audio for additional new commands. Many gestures may provide a confirmation and are not limited to any disclosed herein. Also, verbal commands (e.g., via speech recognition) and commands entered by user button presses (e.g., on a keyboard) may be accepted and processed by the processor. For example, verbal commands may be accepted to confirm or express the same information as gesture commands, thereby enabling the head mounted device and system to more accurately interpret a user's intent.

0281<figref idref="DRAWINGS">FIG. 34</figref> illustrates an embodiment method <b>3400</b> where a gesture command may be processed and confirmed using a detected audio command, which may be a different order of operation than disclosed above. Method <b>3400</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform operations of the method <b>3400</b>. In method <b>3400</b>, the processor may commence operation by receiving data from a head mounted device including sensors that provide data regarding orientation in block <b>3401</b>. In block <b>3402</b>, the processor may receive data from the camera regarding images.

0282In block <b>3403</b>, the processor may calculate distance and orientation of objects within the images. In block <b>3404</b>, the processor may process an image using data from orientation sensors, camera data, and distance data. In block <b>3405</b>, the processor may render the image with the virtual object and in block <b>3406</b> the processor may control the camera to track the user's movements.

0283At determination block <b>3407</b>, a decision may be reached regarding whether to recognize a gesture command, for example, by recognizing one or more selected gestures including pointing, clapping, snapping fingers, making an “O.K. gesture” by joining the thumb and finger. This may be performed using an anatomical model that may be applied to the tracked video data. If a gesture is detected (i.e., determination block <b>3407</b>=“Yes”), the processor may track audio data for a command for a time period in block <b>3408</b> to confirm the detected gestural command.

0284At determination block <b>3409</b>, a decision may be reached regarding whether to recognize an audio command as a confirmation of the gestural command. If the confirmation is received (i.e., determination block <b>3409</b>=“Yes”), the processor may execute the task in block <b>3410</b>.

0285If a gesture is not recognized (i.e., determination block <b>3407</b>=“No”), which may occur when the gesture is inadvertently detected, the processor may continue to track the captured video images for a new gestural command. Also, if no audio confirmation is recognized (i.e., determination block <b>3409</b>=“No”), the processor may continue to receive video and track the video and ignores the gestural command as no confirmation was detected. Also, mentioned above verbal commands and commands entered by user button presses may be accepted and processed by the processor, alone or in conjunction with gesture commands in order to enable the head mounted device and system to more accurately interpret a user's intent.

0286<figref idref="DRAWINGS">FIG. 35</figref> illustrates an embodiment method <b>3500</b> where a gestural command may be processed and recognized. In response to the gestural command, the processor may render a “virtual input device” on the virtual object so the user can utilize the virtual input device to manipulate the virtual object. The virtual input device may be a generated virtual object that can be controlled by tracking the movements of the user. For example, the virtual object may be a virtual pointer, or an icon or any other controllable virtual object selected by the user.

0287Method <b>3500</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>3500</b>. For example, the input device may be a virtual reality pointer object. The pointer may be generated automatically in a line of sight measured from the gesture/tracking cameras and a virtual object connected to the anchor surface. In method <b>3500</b>, the processor may commence operation by receiving data from a head mounted device including sensors that provide data regarding orientation in block <b>3501</b>. In block <b>3502</b>, the processor may receive captured image data from the camera regarding stereo images.

0288In block <b>3503</b>, the processor may calculate distance and orientation of objects within the images. In block <b>3504</b>, the processor may process image using data from orientation sensors, camera data and the distance data. In block <b>3505</b>, the processor may render the image with the virtual object and in block <b>3506</b> the processor may control the camera to track the user's movements.

0289At determination block <b>3507</b>, the processor may determine whether a gesture command is recognized, such as by applying an anatomical recognition algorithm to the tracked images. The processor may recognize one or more selected gestures including pointing, clapping, snapping fingers, making an “O.K. gesture” by joining the thumb and finger, etc. within the image. If the processor recognizes a gesture (i.e., determination block <b>3507</b>=“Yes”), the processor may have an indication to execute a virtual pointer task in block <b>3508</b>.

0290The pointer may be an “input device related virtual object” (a mouse icon, a laser pointer virtual object, an arrow input device) that is displayed on the display in three dimensions and that is placed on the virtual object and that can allow a user to highlight text, select, make input commands and provide inputs to the processor of the head mounted device. At determination block <b>3508</b>, a decision may be reached regarding whether to execute the pointer task. If the processor determines to execute the pointer task (i.e., determination block <b>3508</b>=“Yes”), the processor may execute the task and a type of pointer may be selected from a plurality of different virtual input devices in block <b>3509</b>. On block <b>3510</b>, a vector may be calculated from the head mounted or body mounted camera to the user's finger and to the virtual object. The vector may be used to render the pointer on the virtual object in block <b>3511</b>. In block <b>3512</b>, the virtual object and the virtual input device's display may be updated.

0291If the processor does not recognize a gesture (i.e., determination block <b>3507</b>=“No”), the processor may continue to process video images in order to recognize predetermined gestures. Also, if the processor determines not to execute the pointer task (i.e., determination block <b>3508</b>=“No”), the processor may continue to track video and ignore the gestural command as no task will be executed.

0292<figref idref="DRAWINGS">FIG. 36</figref> illustrates an embodiment method <b>3600</b> where a gesture command may be recognized and processed and a three-dimensional virtual reality type input device may be rendered on the virtual object to provide input commands. Additionally, the processor may recognize features of individuals, which may be rendered transparent when the features/body parts occlude the virtual object. Method <b>3600</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>3600</b>. For example, the input device may be a virtual reality pointer object that is only displayed on the head mounted display. The object may be displayed on the display and may be generated in a line of sight or in a vector that may be measured from the gesture/tracking cameras to the virtual object that is connected on the anchor surface. For example, a vector may be formed from the camera/or a user's finger to the virtual object on the display. The virtual pointer object may be placed and displayed as connected to the vector. The user may control the virtual pointer object by one or more detected gestures, audio commands, by an input device, or by another input command. In method <b>3600</b>, the processor in block <b>3601</b> may commence operation by receiving data from the camera regarding stereo images.

0293In block <b>3602</b>, the processor may calculate the distance and the orientation of the objects within the images. In block <b>3603</b>, the processor may process the image using data from orientation sensors, camera data and distance data. In block <b>3604</b>, the processor may render the image with the virtual object. In block <b>3605</b>, the processor may provide instructions to control the camera to track the user's movements by applying an anatomical algorithm to the tracked images to a detected body part and may track the body part over a predetermined time interval.

0294At determination block <b>3606</b>, the processor may decide whether gesture command is recognized, which may occur when there is a match among one or more gestures in a gesture dictionary with shapes and movement within the tracked images, the processor may correlate the detected gesture to an input command to execute a software application, or to take some predefined action. If the processor recognizes a gesture command (i.e., determination block <b>3606</b>=“Yes”), the processor may execute a pointer task in block <b>3607</b>.

0295The pointer may be a virtual input device (a mouse icon, a laser pointer virtual object) that is displayed on the head mounted display. The virtual input device may be associated with the virtual object that can allow a user to highlight text, select hyperlinks, formulate input commands and form inputs relative to the virtual object. For example, the virtual input device may be a three-dimensional virtual reality arrow displayed on the head mounted display. In such an embodiment, the arrow may be moveable in free space on the display in response to user gestures. For example, in response to the user moving a hand to the left, the system may render an image of the arrow moving to the left on the head mounted display. As another example, the user may input a command and the arrow may illustrate that the command is executed. For example, the user may speak the word “select” when the arrow is adjacent text on the virtual object and the arrow may indicate that the text is selected.

0296At determination block <b>3607</b>, the processor may determine whether to execute the pointer task and whether to select a virtual input device object from a number of predefined alternatives (e.g., an arrow, a pointer device, or various virtual icons). If so (i.e., determination block <b>3607</b>=“Yes”), the processor may execute the task and a virtual input device may be selected in block <b>3608</b> from an array of different pointer types stored in memory. In block <b>3609</b>, a vector may be calculated from the camera to the user's hand and to the virtual object. The virtual input device may be rendered and placed directly on the calculated vector and may be moveable on the display by tracking movement of the user's hand to provide for a virtual or augmented reality experience. In block <b>3610</b>, the virtual reality input device/pointer may be used to move, select, enlarge or highlight a portion of the virtual object on the display.

0297In block <b>3611</b>, optionally a user's features may come in contact with the virtual object and may occlude the virtual object. For example, a user's hand may pass over the virtual object and may occlude or block the view of the virtual object from the user's view point, which may not be favored. The processor may superimpose the virtual object on the user's body part so the virtual object may remain visible to the user, even though the user's body part should be occluding the virtual object on the display. In this manner, the body part may be rendered as seemingly transparent with only an outline of the body part shown. In block <b>3612</b>, the vector may be used to render the pointer on the virtual object. In block <b>3613</b>, the virtual input device may be updated. In block <b>3614</b>, the virtual input device may be displayed with the virtual object.

0298If no gesture command is recognized (i.e., determination block <b>3606</b>=“No”), the processor may continue to track video to determine if the processor recognizes a gesture. Also, if the processor decides not to execute or use a pointer (i.e., determination block <b>3607</b>=“No”), the processor may continue to track video and will not generate and display a virtual input device.

0299<figref idref="DRAWINGS">FIG. 37</figref> illustrates a high level illustration of a system <b>3700</b> that includes a virtual object reality input device or a virtual pointer <b>3706</b> that is visible on a head mounted display <b>3704</b> and a high level diagram of the virtual object <b>14</b>. The head mounted display <b>3704</b> may include a processor and a wireless communication device that includes an antenna (not shown). As discussed above with reference to <figref idref="DRAWINGS">FIG. 5A</figref>, the head mounted device <b>3704</b> may include a core processor which may include a coprocessor for executing applications, sometimes referred to as an application processor.

0300The head mounted device <b>3704</b> may also include multiple peer processors associated with important device capabilities including communications (e.g., a wireless modem processor), navigation (e.g., a GPS receiver processor), and graphics (e.g., a graphics processor unit (GPU)). The head mounted device <b>3704</b> may also include a cellular transceiver or modem (not shown), which in many cases include one or more processors whose main task is managing wireless communications. The head mounted device <b>3704</b> may also include other wireless transceivers for communicating over other types of wireless communications networks, such as a Wi-Fi modem (not shown) that may be a separate transceiver chip, in which case it may also include a separate programmable processor. Other wireless transceivers (not shown) which have embedded programmable processors may be included to connect to other types of wireless communication links, such as near field communications (NFC) links, Bluetooth® links, and links based on other wireless protocols.

0301In addition to the communications processors, the head mounted device <b>3704</b> may also include a GPS receiver (not shown) which may have a dedicated processor. Also, a graphics processor may be included in order to provide high-resolution graphics. The head mounted device <b>3704</b> may also include processors associated with wired communications, such as a USB port. As described above with reference to <figref idref="DRAWINGS">FIG. 5A</figref>, the head mounted display <b>3701</b> may include an RGB-D camera system which itself may combine a RGB camera <b>3704</b><i>a </i>with an infrared camera <b>3704</b><i>b </i>and a structured infrared light infrared emitter <b>3704</b><i>c. </i>

0302The processor measures a vector that may be captured from the head mounted or body mounted camera <b>3701</b> to the user's finger <b>3705</b> and from the finger <b>3705</b> to the virtual object <b>14</b>. Using the vector an input device virtual object <b>3706</b> may be generated and may be placed on the vector. The virtual input device <b>3706</b> may be generated and an orientation of the virtual input device <b>3706</b> may be calculated. The virtual input device <b>3706</b> may be generated to connect to the anchor surface <b>3703</b>, which may be where a virtual object <b>14</b> is connected. In this embodiment, the virtual object <b>14</b> may be rendered for display to a very large size, for example the size of a building as displayed on the head mounted display. The user using the virtual input device <b>3706</b> may select text or portions of the virtual object or content displayed with the virtual object <b>14</b> thereof.

0303<figref idref="DRAWINGS">FIG. 38</figref> illustrates a high level diagram of a first and a second head mounted device system <b>3800</b> and <b>3800</b><i>a </i>illustrating how a second head mounted device may provide pointing coordinates and gesture controls for implementation by a first head mounted device. The primary head mounted device system <b>3800</b> may include a first head mounted or body mounted camera array <b>3801</b> and a first processor <b>3804</b> operable with a peer to peer based arrangement. A first processor <b>3804</b> may be operable as a host processor and a second processor <b>3805</b> may be operable as a secondary system. A second head mounted device system <b>3800</b><i>a </i>may act as system that receives a generated image for display from a primary system <b>3800</b>. The second head mounted device system <b>3800</b><i>a </i>may include a head mounted or body mounted camera array <b>3802</b> and a second processor <b>3805</b>. A display system <b>3803</b> may be also be provided for the user to view three-dimensional images. The head mounted or body mounted camera array <b>3801</b> may provide the image and distance data to the first processor <b>3804</b>, which generates and provides the image data to the display system <b>3803</b>. The primary processor <b>3804</b> may provide the image to the second processor <b>3805</b>, and the second head mounted device may provide point coordinates and gesture controls to the primary processor <b>3804</b>. Image and distance data and provided to the processors <b>3804</b> and <b>3805</b> whereby a primary processor generates a virtual object and displays the image on a display system <b>3803</b> and also communicates the image to the second processor <b>3805</b> for display. The second processor <b>3805</b> may detect user gestures as user inputs, such as pointing to locations for anchor surfaces or moving objects and control commands, and provide those point and gesture controls to the first processor where the inputs may be processed.

0304<figref idref="DRAWINGS">FIG. 39</figref> illustrates a system <b>3900</b> that operates in a cloud configuration where point and gesture controls and image data information may be stored on and relayed to others (e.g., in a multicast) by a cloud server <b>3906</b>. This system enables virtual object and display data to be wirelessly communicated to collaborating head mounted display systems <b>3900</b><i>a </i>and <b>3900</b><i>b</i>. The system <b>3900</b> also enables other computing devices, including other head mounted devices, to monitor the data exchanges taking place between the collaborating head mounted display systems <b>3900</b><i>a </i>and <b>3900</b><i>b</i>. In this manner, the collaboration may be viewed by a wider audience.

0305The system <b>3900</b> may include a central processor operable on a central server <b>3906</b>. The first head mounted device <b>3900</b><i>a </i>may include a head mounted or body mounted camera <b>3902</b> and a first processor <b>3903</b>. A second head mounted device <b>3900</b><i>b </i>may include a head mounted or body mounted camera <b>3904</b> with a second processor <b>3905</b>. A display system <b>3901</b> also may be provided. An image may be provided from the server <b>3906</b> to the display system <b>3901</b>. The image also may be provided to the first processor <b>3903</b>. The first processor <b>3903</b> transmits data to the server <b>3906</b> including gestures, point coordinates, distance data, image data, orientation data, and sensed parameters. The image may be also provided to the second processor <b>3905</b>. The second processor <b>3905</b> also may provide the data including gestures, point coordinates, distance data, image data, orientation data, and sensed parameters to the server <b>3906</b>. The central processor operable on the central server <b>3906</b> may provide services to the head mounted devices to alleviate computational processing on the first and second processors <b>3903</b> and <b>3905</b> to render the virtual pointer object and a virtual object.

0306For example, the first user system <b>3900</b><i>a </i>may scan an area with infrared light and may measure a time of flight of the reflected infrared light to a gating mechanism. This may be utilized to determine the shape of objects in a predetermined area and may also be utilized to determine a distance parameter of the objects. The first user system <b>3900</b><i>a </i>may wirelessly communicate the distance parameter to the sever <b>3906</b>. The cloud server <b>3906</b> may utilize the scanned data to generate an image including a virtual object. The virtual object may be generated in an image and wirelessly communicated to the display system <b>3901</b> and the second head mounted device <b>3900</b><i>b </i>together with scanned data of the predetermined area.

0307Referring back to <figref idref="DRAWINGS">FIG. 37</figref>, an example of a gesture that may be tracked by a head mounted device is a pointing gesture indicating or selecting a virtual object. For example, a user may point to a virtual object <b>14</b> with a finger <b>3705</b>, and the camera system of the head mounted display may determine a vector from the head mounted or body mounted camera <b>3708</b> to the user's finger <b>3705</b> and from the finger <b>3705</b> to the virtual object <b>14</b>. Using this vector, the processor may generate an input device virtual object.

0308For example, an orientation of the virtual object <b>14</b> for display on the head mounted display may be determined. The virtual input device object <b>14</b> may be connected to the anchor surface <b>3704</b> and may connect to the virtual object <b>14</b> so the user may control the virtual input device object <b>14</b>. The virtual object <b>14</b> may be anchored on the anchor surface <b>3703</b> within images rendered on the head mounted display. In this embodiment, the virtual object <b>14</b> may be rendered for display, and using the virtual object input device, the user may select text or portions of the virtual object <b>14</b> which are recognized with the tracked video and captured gestures utilizing the gesture tracking camera <b>3708</b>. In this embodiment, the virtual input device object <b>14</b> may be displayed as a moveable three-dimensional object around the user or that the user can walk around. The virtual object <b>14</b> may be rendered as a very large virtual object in the displayed image, such as the size of a building. The user may utilize the virtual input device to specify a position in space on the very large virtual object <b>14</b> in the displayed image.

0309<figref idref="DRAWINGS">FIGS. 40A-40B</figref> illustrate another embodiment in which the head mounted display device <b>10</b> shown in <figref idref="DRAWINGS">FIG. 1</figref> may be replaced or supplemented with a pico projector <b>4005</b> that may be wirelessly connected to a mobile smartphone <b>4010</b> and that may generate a projected image on a surface where a user's gestures may be utilized to provide input commands. In this embodiment, the user does not wear any head mounted apparatus and merely may view the projected images on a horizontal or vertical surface. A handheld projector <b>4005</b> (also known as a pocket projector <b>4005</b>, mobile projector or pico projector) may be used with a handheld device <b>4010</b> to output the virtual object <b>14</b><i>a </i>shown in <figref idref="DRAWINGS">FIGS. 40A and 40B</figref>. The handheld projector <b>4005</b> may include miniaturized hardware and software that can project digital images <b>14</b><i>a </i>onto any nearby viewing surface <b>16</b>, such as a wall <b>16</b> shown in <figref idref="DRAWINGS">FIG. 1</figref> or a desk top <b>16</b><i>a </i>shown in <figref idref="DRAWINGS">FIG. 40B</figref>.

0310The pico projector <b>4005</b> may include a battery <b>4015</b>, an electronic motherboard <b>4005</b>, a diode laser, laser or other light source <b>4030</b>, a combiner optical element <b>4035</b>, and scanning mirrors <b>4040</b>. Various configurations of components in the handheld projector <b>4005</b> are possible and within the scope of the present disclosure. The processor <b>4020</b> may be coupled to a motherboard <b>4020</b>. Processor <b>4020</b> may control the laser diode <b>4030</b> and a projector to output an image where controlled by the processor <b>4020</b> utilizing the mirror and optic <b>4040</b> and <b>4035</b>.

0311Turning to <figref idref="DRAWINGS">FIG. 40A</figref>, the pico projector <b>4005</b> may include a projector element <b>4006</b>, an input sensor <b>4007</b>, a connector <b>4008</b>, and a wireless interface <b>4009</b> for connecting to a mobile device <b>4010</b> or other computing device. An input-sensing pico-projector may be connected to other units of the same type in a modular fashion. The projectors may create multiple, positional aware shared projected displays rendered as virtual objects <b>14</b><i>a </i>and <b>14</b><i>b </i>for a real time local digital collaboration between users. The pico projector <b>4005</b> may capture images for a first user and applying an anatomical algorithm to the captured images. The processor may detect a first user and project a first virtual object <b>14</b><i>a </i>on a desktop surface <b>16</b> in a convenient location for the first user. The pico projector <b>4005</b> using a peer-to-peer or other RF wireless communication link, or using captured image data may detect that a second user has joined the collaboration. The pico projector <b>4005</b> may output a second virtual object <b>14</b><i>b </i>oriented correctly for the second user based on the captured image data.

0312Each projector <b>4005</b> may connect to a mobile computing device <b>4010</b> (or other computing device) via high-speed wireless data links (e.g., 4G, Wi-Fi or Bluetooth®) and/or be linked via a peer-to-peer communication protocol. Each projector <b>4005</b> may also be linked to the mobile computing device <b>4010</b> (or other computing device) via a wired data link. The mobile computing device <b>4010</b> may act as a processing unit and data storage device for the pico projector <b>4005</b> and may generate the projected image and communicate the image to the pico projector <b>4005</b>. The pico projector <b>4005</b> may alternatively connect physically to other pico projectors, such as via strategically positioned connectors <b>4008</b> on each projector's <b>4005</b> housing. For example, two pico projectors <b>4005</b> may connect via respective connectors <b>4008</b>. The connectors <b>4008</b> may provide a reference data point for each of the pico projectors <b>4005</b> when two pico projectors <b>4005</b> are connected to one another. The pico projector <b>4005</b> may display a projected image on a surface <b>16</b><i>a</i>, which may be a predetermined distance from the reference data point.

0313The connections <b>4008</b> on each projector's <b>4005</b> housing may provide both physical support and may include a circuit for a high-speed data link between projectors <b>4005</b>, bridging communications between each projector's wirelessly connected mobile computing device <b>4010</b>. The connector <b>4008</b> and circuit may support USB, Firewire®, or any other high speed connector <b>4008</b> known in the art.

0314Additionally, the connections may provide a reference data point to software regarding each projector's physical orientation with respect to other projectors connected via connector <b>4008</b> shown in <figref idref="DRAWINGS">FIG. 40A</figref>. The connectors <b>4008</b> may be used to provide interface software and the ability to transfer digital assets across the projectors <b>4005</b>. The projector <b>4005</b> may output the virtual object <b>14</b><i>a </i>as a projection onto a surface. The projector <b>4005</b> may also use captured image data to sense objects in the image for tracking and for gesture recognition. The projected image <b>14</b><i>a </i>may be a virtual touch screen <b>14</b><i>a </i>and may also include a virtual input device on the virtual object. Gestures associated with the projected image may be detected and the processor may formulate input commands based on the detected gestures. This gesture recognition functionality may provide a simulated appearance that the user may be controlling a virtual input device.

0315<figref idref="DRAWINGS">FIG. 40B</figref> illustrates the pico projector <b>4005</b> rendering a first virtual object <b>14</b><i>a </i>and a second virtual object <b>14</b><i>b</i>. In an embodiment, a single pico projector <b>4005</b> may project at least two different images for each user. In another embodiment, the pico projector <b>4005</b> may be mated with a second pico projected which completes an electronic connection between the two projectors. The two different pico projectors <b>4005</b> may wirelessly connect with a mobile computing device <b>4010</b> or other available computing devices, and each may output two different images with one for each user. The projector <b>4005</b> linked to the mobile computing devices <b>4010</b> may use the processor of each mobile computing device <b>4010</b> to render the virtual object <b>14</b><i>a </i>and <b>14</b><i>b</i>. The processor of the mobile computing device <b>4010</b> and the image sensor may detect parameters associated with each user to render the virtual object <b>14</b><i>a </i>and <b>14</b><i>b </i>and to determine the correct orientation of the virtual object <b>14</b><i>a </i>and <b>14</b><i>b </i>for each of the users.

0316The input sensor <b>4007</b> may convert the image into an electronic signal. The electronic signal may drive the light sources with different colors and intensities down different optical paths. In the combiner optic <b>4035</b> the different light paths may be combined into one path demonstrating a number of colors. The mirrors <b>4040</b> reflect the image pixel-by-pixel and project the image. The handheld projector <b>4005</b> may project a clear image, regardless of the physical characteristics of the viewing surface <b>16</b>. For example, the projected image of the virtual object <b>14</b><i>a </i>may be a “virtual object input device,” such as a keyboard with a word processing application. The gestures of the user may be detected corresponding to the input device locations on the virtual objects <b>14</b><i>a</i>-<b>14</b><i>c </i>and recognized as one or more input commands.

0317In the illustrated embodiment, the image may project a virtual object <b>14</b><i>a </i>on a surface <b>16</b><i>a </i>shown in <figref idref="DRAWINGS">FIG. 40B</figref>, and the user may anchor the virtual object <b>14</b><i>a </i>on the physical surface <b>16</b><i>a</i>. As the user moves based on the output of the sensor <b>4007</b>, the virtual object <b>14</b><i>a </i>may change in shape, orientation and size to remain anchored to the physical surface <b>16</b><i>a</i>. For example, the user may be detected as moving backward or forwardly, or left or right relative to the projector <b>4005</b> by the sensor <b>4007</b>. The input sensor <b>4007</b> may communicate a position change by the user and the processor <b>4020</b> may control the projected image to become larger or smaller, or more the projected image to a comfortable viewing location associated with the user's new location. For example, the projected image may move from a horizontal surface to a vertical surface to follow the user.

0318A mobile computing device <b>4010</b>, such as a smartphone may be configured to support the gesture user interface functionality of the projector <b>4005</b>, which projects a computer generated image (such as a presentation slide, text document or photograph) onto a projection surface <b>16</b>. A camera (image sensor) <b>4007</b> (<figref idref="DRAWINGS">FIG. 40A</figref>) coupled to the mobile computing device <b>4010</b> may be positioned so its field of view encompasses at least part of the displayed image. In another embodiment, a user may also use a laser pointer to place a laser spot onto the displayed image, which may be detected by the camera <b>4007</b>.

0319The camera <b>4007</b> may obtain a digital image of the laser spot and at least part of the displayed image and provide the camera image to the processor <b>4020</b> of the mobile computing device <b>4010</b> with a location of the laser spot within the image. The mobile computing device <b>4010</b> processor <b>4020</b> may be configured with software instructions to analyze the image generated by the camera <b>4007</b> (referred to herein as the “received camera image”) to recognize at least a portion of the display content that is being projected onto the projection surface <b>16</b> and determine the location of the laser spot with respect to the content. Since laser pointers emit a bright beam of light at a specific wavelength, the laser spot can easily be recognized by the processor <b>4020</b> and distinguished from the projected image based upon the intensity and/or color elements. The camera <b>4007</b> may be further configured to track the movement of the laser spot and correlate that movement to predefined laser gestures. When a laser gesture is recognized, the processor <b>4020</b> may execute the corresponding function.

0320<figref idref="DRAWINGS">FIG. 40C</figref> is a high level diagram of a projector outputting multiple different projected images based on one or more detected users. <figref idref="DRAWINGS">FIG. 40C</figref> illustrates a projector <b>4005</b> that uses a mobile communication device processor <b>4010</b> (<figref idref="DRAWINGS">FIG. 40A</figref>) to detect gestures from tracked images of additional users that have joined the collaboration. In response to detecting the new user, the processor may render a third virtual object <b>14</b><i>c </i>in a modular fashion that is correctly oriented to the third user. Likewise, if an additional user joins and is detected, the processor may render a fourth virtual object (not shown) in a modular fashion where at least two projected images may render the same content and images. Further, a third or fourth user may use the mobile computing device <b>4010</b> to change the display of the projected images <b>14</b><i>a</i>, <b>14</b><i>b </i>and <b>14</b><i>c</i>. For example, the user may close the third object <b>14</b><i>c </i>and open a new object having different content.

0321Using the projector <b>4005</b>, the mobile user experience may be enhanced by providing a large input and display environment that is highly portable. Digital collaboration environments for multiple users may be set up in an ad hoc manner by using mobile devices <b>4010</b>. The physical connectors <b>4008</b> on the projectors <b>4005</b> may provide relative positional awareness between projectors. The position data may be provided with a high degree of accuracy. This allows users to easily create collaborative data presentations and manipulations using multiple projected virtual objects <b>14</b><i>a</i>-<b>14</b><i>c. </i>

0322<figref idref="DRAWINGS">FIG. 40D</figref> illustrates an embodiment method <b>4045</b> for projecting images in a convenient manner for a user based on a detected object/gesture. Method <b>4045</b> may be implemented in a computing device having a processor configured with processor-executable instructions to perform the operations of the method <b>4045</b>. In method <b>4045</b>, the processor may capture images of a user and may capture spatial data with a sensor array in blocks <b>4046</b> and <b>4047</b>. In block <b>4048</b>, the processor may recognize objects in the image and determine distances to the objects in the image. In block <b>4049</b>, the processor may track objects in the image and may apply an anatomical analysis to determine if there is a body part within the image.

0323For example, the processor may apply an anatomical analysis to the captured images to determine whether the captured image includes a head and shoulders, torso, and arms etc. or any other body part that would indicate a user or the direction in which a user is looking. If a body part is detected, the processor may determine if the detected body part over time conforms to gestures stored in a memory (e.g., in a gesture dictionary) and may apply a command when a gesture is recognized. In an embodiment, the pico projector may project the image in a specific location so the user can conveniently watch and interact with the projected images. For example, if a head and shoulders are determined to be in the image, the pico projector may project an image on a wall or on a table top conveniently near the user.

0324In a further embodiment, users may apply or wear on one or both hands or wrists gloves, rings, bracelets, and or other items that are colored or feature reflective features that can be recognized by one or both of the distance sensors and cameras in order to aid in distinguishing the user's hands and fingers and recognizing movement gestures. For example, a user may wear a glove that has different colors exhibited on each of the fingers, and the head mounted device may be configured to recognize each of the finger colors based on their respective red-green-blue intensity values within pixels of the scene image.

0325In blocks <b>4050</b> and <b>4051</b>, the processor receives a first and a second signal from the respective first and second pico projector to link and communicate data between the pico projectors and the processor. For example, the pico projectors may link with a mobile communication device so data content of a memory associated with the mobile communication device memory may be accessed and displayed or shared. In determination block <b>4052</b>, the processor determines whether to project images from the pico projectors based on a detected body part. If so, (i.e., determination block <b>4052</b>=“Yes”), the processor may display content utilizing the projected image at a surface convenient for a user in block <b>4053</b>. In block <b>4054</b>, the processor may share data between the users and a wireless data link between the pico projectors. For example, image files, word processing files, e-mails or any other data may be shared or displayed as a projected image. If the processor determines not to project the images based on the detected body part, (i.e., determination block <b>4052</b>=“No”), the processor may display a prompt to project an image and project the image in a conventional manner in blocks <b>4055</b> and <b>4056</b>. For example, the pico projector may hold off projecting the projections until an input is received and the user may manually detect the projected images. The projected images may include a virtual object and the head mounted devices may be configured to recognize user hand gestures interacting with or relating to the projected virtual object image as user inputs. In such embodiments, the processor may apply a command corresponding to a recognized hand gesture that is made when utilizing the projected virtual input device.

0326For example, a virtual mouse or virtual pointer may be displayed that can be moved with tracked movements of a user's hand. Additionally, using the detected gesture, the processor may correctly orient the projected images on a vertical or horizontal surface. In this manner, the projected image may be projected right side up based on the detected body part. For example, the first pico projector may be connected to the second projector in a back to back configuration and the projectors may project at least two different projected images with the projected images being separated by at least one hundred eighty degrees relative to one another. In yet another embodiment, the processor may define a reference point and determine an orientation of each of the first and the second projectors based on the reference point. The processor may orient the projected image for the users based on the reference point and the orientation of the first and the second projectors.

0327In another embodiment, the processor may detect a third user and project at least a third projected image based on a detected body part. Also, the processor may receive data from a third computing device associated with the third user for collaboration. In another embodiment, a fourth pico projector may be provided and at least four different projected images.

0328Various embodiments may include methods of projecting images from first and second pico projectors coupled to a computing device by capturing images of a scene in a vicinity of the first and second projectors, capturing spatial data in the vicinity of the first and second projectors with a sensor array, analyzing captured scene images to recognize body parts, and projecting images from each of the first and the second projectors with a shape and orientation determined based on the recognized body parts. In an embodiment, the first and the second projectors may be pico projectors. In a further embodiment, projecting images from each of the first and the second projectors with a shape and orientation determined based on the recognized body parts may include projecting images on a surface in front of users in the vicinity of the projectors.

0329In a further embodiment, the method may include orienting the projected images on a vertical or horizontal surface appropriate for users in the vicinity of the projectors. In a further embodiment, the method may include tracking movements of the recognized body parts, applying a detection algorithm to the tracked movements to detect a predetermined gesture, applying a command corresponding to the detected predetermined gesture, and modifying the projected images in response to the applied command. In a further embodiment, analyzing captured images to recognize body parts may include applying an anatomical analysis to the images to determine whether objects within the captured images match a portion of an anatomical model.

0330In a further embodiment, the projected images may be of a virtual input device, and applying a command corresponding to the detected predetermined gesture may include applying a command consistent with those of a user input device. In a further embodiment, applying a command corresponding to the detected predetermined gesture may include applying a command corresponding to moving the virtual object, and modifying the projected images in response to the applied command may include displaying the virtual object as moving from a first location to a second location in response to detecting the predetermined gesture. In a further embodiment, the method may include connecting the first projector to the second projector via connectors on the exterior of each projector in a back to back configuration, in which projecting images from each of the first and the second projectors with a shape and orientation determined based on the recognized body parts may include projecting at least two images in approximately opposite directions.

0331In a further embodiment, the method may include connecting the first projector to a third projector via connectors on exteriors of the projectors, and connecting the third projector to the second projector via connectors on exteriors of the projectors, in which projecting images from each of the first and the second projectors with a shape and orientation determined based on the recognized body parts may include projecting at least three projected images such that they are separated by approximately ninety degrees.

0332In a further embodiment, the method may include connecting the first projector to a third projector and a fourth projector via connectors on exteriors of the projectors, and connecting the third and fourth projectors to the second projector via connectors on exteriors of the projectors, in which projecting images from each of the first and the second projectors with a shape and orientation determined based on the recognized body parts may include projecting four images such that they are separated by approximately ninety degrees.

0333In a further embodiment, the method may include defining a reference point in the scene, determining an orientation of each of the first and the second projectors based on the defined reference point, and orienting the projected images based on the defined reference point and the orientation of the first and the second projectors. In a further embodiment, defining a reference point in the scene may include connecting the first projector to the second projector by a connection point, and defining the connection point as the reference point.

0334Various embodiments may include methods of rendering virtual images in an augmented reality system by capturing an image with a body mounted camera, capturing spatial data with a body mounted sensor array, recognizing an object within the captured image, receiving a first user input indicating a first anchor surface in the captured image that corresponds to a first surface located in the image, calculating parameters including distance and orientation with respect to the body mounted camera that correspond to the first anchor surface, displaying a virtual object so the virtual object appears anchored to the selected first anchor surface, receiving a second input indicating a second anchor surface within the captured image that is different from the first anchor surface, in which the second anchor surface corresponds to a second surface located in the image and the first and second surfaces are different, calculating parameters including distance and orientation with respect to the body mounted camera that corresponds to the second anchor surface, and displaying the virtual object so the virtual object appears to the user to be anchored to the selected second anchor surface and moved from the first anchor surface.

0335In an embodiment, the method may include continuously updating the display of the generated virtual object so the virtual object appears anchored to the selected first or second anchor surface as the user turns his/her head and moves with respect to the selected first or second anchor surface. In a further embodiment, displaying the virtual object may include displaying a virtual head mounted display. The method may further include outputting video images as if appearing on the head mounted display anchored to the selected first or second anchor surface. In a further embodiment, displaying the generated virtual object so the virtual object appears to the user to be anchored to the selected second anchor surface and moved from the first anchor surface may include generating the virtual object as a rectangular shaped virtual object that resembles a flat screen display, and displaying the generated virtual object on a semitransparent display with the virtual object superimposed on a real world surface visible through the semitransparent display.

0336In a further embodiment, the first or second anchor surface may include a wall in a room, and in which the virtual object remains anchored on the wall in the room as the user moves about in the room. In a further embodiment, displaying the generated virtual object so the virtual object appears anchored to the selected first or second anchor surface may include generating the virtual object so that it appears to be contacting the first or second anchor surface and so that the first or second anchor surface appear to be a rigid point of support for the anchored virtual object. In a further embodiment, displaying the generated virtual object so the virtual object appears anchored to the selected anchor surface may include generating the virtual object so that it appears to be spaced apart from the first or second anchor surface but hovering in a fixed position and spaced relative to the first or second anchor surface.

0337In a further embodiment, the method may include transmitting data by the captured spatial data, the generated virtual object and the image to a second head mounted display. In a further embodiment, the method may include receiving audio from the user utilizing a microphone, applying a detection algorithm to the received audio to detect a predetermined audio signal, and implementing the predefined user input when the predetermined audio signal is detected. In a further embodiment, applying a detection algorithm to the received audio to detect a predetermined audio signal may include applying a detection algorithm to the received audio to detect a predetermined audio signal spoken by the user corresponding to a predefined user input. In a further embodiment, the predefined user input corresponding to the detected predetermined audio signal is one of the first input, the second input or a confirmation of one of the first and second inputs.

0338In a further embodiment, the method may include capturing the image with the body mounted camera that is mounted and disposed together with a head mounted display, and displaying the virtual object on the head mounted display. In a further embodiment, the body mounted camera and head mounted display include a body mounted device. The method further may further include establishing a wireless data link between the body mounted device and a second body mounted device, receiving audio data from the second body mounted device via the wireless data link, and using the received audio data to output audio to the user. In a further embodiment, the method may include receiving video data via the wireless data link, and using the received video data to output video images on the head mounted display received from the second body mounted device, in which the video displays an anchored virtual object.

0339In a further embodiment, receiving video data via the wireless data link may include receiving one or more of a three dimensional model data for a virtual object, three dimensional data for an anchoring surface, three dimensional data for an anchoring point, three dimensional depth data, and three dimensional distance data. In a further embodiment, the method may include receiving a third input indicating a standby location for the virtual object, in which the standby location is different from the first and the second anchor surfaces, calculating parameters including distance and orientation with respect to the body mounted camera that corresponds to the standby location, and displaying the virtual object at the standby location. In a further embodiment, the standby location is displayed as free floating on a display, in which the virtual object appears on the display as movable and unconnected to surfaces in the image as the user turns his/her head and moves.

0340In a further embodiment, capturing an image with a body mounted camera may include capturing video data by a full-color video camera, and capturing spatial data with a body mounted sensor array may include capturing spatial data utilizing a distance sensor to determine distances to objects in the image. In a further embodiment, capturing spatial data with a body mounted sensor array may include capturing distance information of objects in the image using an infrared laser and an infrared sensor. In a further embodiment, the method may include building a three dimensional map based on the captured video data and the calculated spatial data. In a further embodiment, the method may include tracking movements of the user utilizing the body mounted camera, applying a detection algorithm to the tracked user movements to detect a predetermined gesture, and executing a command corresponding to the predetermined gesture when the predetermined gesture is detected.

0341In a further embodiment, the detected predetermined gesture is selected from the group consisting of an “OK” sign, a fist, an open hand, pointing with one finger, pointing with two fingers, pointing with three or four fingers, an outstretched hand, a hand rotation, a wave, a movement of one or more fingers, a movement of a body part or a foot, and any combination thereof. In a further embodiment, the predetermined gesture is retrieved from a gesture dictionary. In a further embodiment, the gesture dictionary defines one or more of a poke gesture, a pat gesture, or a tap gesture for target selection or toggling, a push gesture for guiding a screen object across a screen, a flick gesture for imparting momentum to the screen object, a turn gesture for rotating the screen object, a grab gesture or a pull gesture for zoom operations, a two hand move gesture for panning operations, a drawing hands apart gesture for resizing the screen object, and a swipe gesture for horizontal scrolling or shuttling through media.

0342In a further embodiment, receiving the first input indicating a first anchor surface in the captured image may include detecting a first predetermined gesture made by the user corresponding to a command to designate a surface within the captured image as an anchor surface and applying the command, and receiving the second input to anchor the virtual object in the image may include detecting a second predetermined gesture made by the user corresponding to a command to move the anchor surface to another surface in the captured image and applying the command. In a further embodiment, either of the first or second detected predetermined gestures may include the user pointing to a surface in the captured image. In a further embodiment, the method may include continuing tracking movements of the user after the first input is received, applying a detection algorithm to the tracked movements to detect a third predetermined gesture corresponding to a user input confirming the first input, and anchoring the virtual object to the selected anchor surface in response to the third predetermined gesture.

0343Various embodiments may include methods of storing spatial data for use in an augmented reality system by generating data regarding locations of surfaces and objects in a scene based on images and spatial data gathered from a first body mounted sensor device, generating a three dimensional map of the scene based on the generated data, adding geographical identification metadata to the three dimensional map of the scene, storing the geographical identification metadata and three dimensional map in a memory, and transmitting at least a portion of the geographical identification metadata and three dimensional map to a second body mounted sensor device. In an embodiment, generating data regarding locations of surfaces and objects in a scene based on images and spatial data gathered from a first body mounted sensor device may include capturing a scene image of the scene with a body mounted camera, capturing spatial data of objects within the scene with a body mounted sensor array, recognizing objects within the captured scene image, and determining distances from the first body mounted sensor device to the objects recognized within the scene image, and adding geographical identification metadata to the three dimensional map of the scene may include associating the determined distances with the objects recognized within the scene image.

0344In an embodiment, the method may include determining a location of the second body mounted sensor device, in which transmitting at least a portion of the geographical identification metadata and three dimensional map to the second body mounted sensor device may include transmitting a portion of the geographical identification metadata and three dimensional map relevant to the location of the second body mounted sensor device. In a further embodiment, the method may include receiving the transmitted portion of the geographical identification metadata and three dimensional map in the second body mounted sensor device, and generating a visual image on a display on the second body mounted sensor device based in part on the received portion of the geographical identification metadata and three dimensional map.

0345In a further embodiment, the method may include determining a location of the second body mounted sensor device, generating data regarding locations of surfaces and objects in the scene based on images and spatial data gathered from the second body mounted sensor device, and refining the geographical identification metadata and the three dimensional map based upon the data generated by the second body mounted sensor device. In a further embodiment, adding geographical identification metadata to the three dimensional map of the scene may include tagging the three dimensional map with a geotag. In a further embodiment, generating data regarding locations of surfaces and objects in a scene based on images and spatial data gathered from a first body mounted sensor device, generating a three dimensional map of the scene based on the generated data, and adding geographical identification metadata to the three dimensional map of the scene are accomplished in a processor within the first body mounted sensor device.

0346In a further embodiment, the method may include relaying images and spatial data gathered by the first body mounted sensor device to a processor in communication with the first body mounted sensor device, in which generating data regarding locations of surfaces and objects in a scene based on images and spatial data gathered from a first body mounted sensor device, generating a three dimensional map of the scene based on the generated data, and adding geographical identification metadata to the three dimensional map of the scene are accomplished in the processor in communication with the first body mounted sensor device. In a further embodiment, the method may include transmitting images and spatial data gathered by the first body mounted sensor device to a server via a network, in which generating data regarding locations of surfaces and objects in a scene based on images and spatial data gathered from a first body mounted sensor device, generating a three dimensional map of the scene based on the generated data, and adding geographical identification metadata to the three dimensional map of the scene are accomplished in the server based on the image and spatial data received from the first body mounted sensor device.

0347In a further embodiment, the method may include determining a location of the second body mounted sensor device, and transmitting a request from the second body mounted sensor device to the server for a portion of the geographical identification metadata and three dimensional map, the request including the determined location of the second body mounted sensor device, in which transmitting at least a portion of the geographical identification metadata and three dimensional map to the second body mounted sensor device may include transmitting from the server to the second body mounted sensor device a portion of the geographical identification metadata and three dimensional map that is relevant to the location of the second body mounted sensor device. In a further embodiment, generating a three dimensional map of the scene may include developing a mathematical representation of three-dimensional surfaces within the scene, and writing the geographical identification metadata into the mathematical representation. In a further embodiment, storing the geographical identification metadata and the three dimensional map to a memory may include storing the mathematical representation on a server accessible by the first and second body mounted sensor devices.

0348In a further embodiment, generating data regarding locations of surfaces and objects in a scene based on images and spatial data gathered from a first body mounted sensor device may include determining a location of the first body mounted sensor device, capturing a scene image of the scene with a body mounted camera, capturing spatial data of objects within the scene with a body mounted sensor array, recognizing objects within the captured scene image, and determining locations of the objects recognized within the scene image, and adding geographical identification metadata to the three dimensional map of the scene may include associating the determined locations with the objects recognized within the scene image. In a further embodiment, determining locations of the objects recognized within the image may include determining locations of the objects with respect to the determined location of the first body mounted sensor device. In a further embodiment, determining locations of the objects recognized within the image may include determining locations of the objects within a coordinate system used in determining the location of the first body mounted sensor device.

0349Various embodiments may include methods of rendering images in an augmented reality system by capturing an image of a scene in which a virtual object is to be displayed, recognizing a body part present in the captured image, and adjusting a display of the virtual object based upon the recognized body part. In an embodiment, adjusting a display of the virtual object may include identifying a portion of the virtual object that overlaps the recognized body part, and suppressing the identified portion such that the recognized body part appears to occlude the identified portion of the virtual object. In a further embodiment, adjusting a display of the virtual object may include identifying a portion of the virtual object that overlaps the recognized body part, and superimposing the virtual object on the recognized body part such that the identified portion of the virtual object appears to occlude the recognized body part.

0350In a further embodiment, adjusting the displayed virtual object may include adjusting displayed portions of the virtual object overlapping the recognized body part such that the virtual object is viewable through the recognized body part and such that the recognized body part appears semitransparent. In a further embodiment, the method may include displaying the virtual object on a body mounted semitransparent display configured such that that an individual wearing the body mounted semitransparent display can view the scene through the display. In a further embodiment, capturing an image of a scene in which a virtual object is to be displayed may include capturing an image with a body mounted camera worn by a first individual. The method may further include capturing spatial data with a body mounted sensor array worn by the first individual, recognizing objects within the captured image, and determining distances to the recognized objects within the captured image. In a further embodiment, the method may include displaying the virtual object and the captured image on a head mounted display such that the scene is viewable to an individual wearing the body mounted semitransparent display.

0351In a further embodiment, recognizing a body part present in the captured image may include applying an anatomical analysis to the captured image. In a further embodiment, applying an anatomical analysis to the image may include recognizing objects within the captured image, comparing the recognized objects to a skeletal model stored in memory, the stored skeletal model including relative position information about key joints, bones, and limbs of a human skeleton, and determining if any of the recognized objects match a portion of the skeletal model in response to comparing the recognized objects to the skeletal model. In a further embodiment, the method may include determining whether the body part belongs to a first individual or to a second individual in response to recognizing a body part present in the captured image, determining a location and encompassed area of the virtual object, and determining whether the recognized body part overlaps at least one portion of the area encompassed by the virtual object.

0352In a further embodiment, determining whether the body part belongs to a first individual or to a second individual may include determining whether the body part belongs to the first or second individual based on an orientation of the recognized body part. In a further embodiment, determining whether the body part belongs to a first individual or to a second individual may include determining that the body part belongs to the first or second individual based on a distance of the recognized body part from the body mounted camera. In a further embodiment, determining whether the body part belongs to a first individual or to a second individual may include determining that the body part belongs to the first or second individual based on a number of body parts determined to be in the captured image.

0353In a further embodiment, adjusting a display of the virtual object may include displaying the virtual object superimposed over the recognized body part of the second individual when it is determined that the body part belongs to the second individual, and displaying the virtual object so that the virtual object appears to be located beneath the recognized body part when it is determined that the body part belongs to the first individual. In a further embodiment, displaying the virtual object so that the virtual object appears to be located beneath the recognized body part may include not rendering portions of the virtual object which overlap the recognized body part. In a further embodiment, the method may include displaying an outline of portions of the recognized body part of the second individual that overlap a display area encompassed by the virtual object such that the outline is visible over the virtual object in the display.

0354Various embodiments may include methods of rendering images in an augmented reality system by first and second body mounted devices each including a body mounted camera and a head mounted display. The method may include capturing a first scene image of a scene with the body mounted camera of the first body mounted device, displaying on the head mounted display of the first body mounted device a first image of a virtual object, the first image displaying the virtual object as being anchored to a first anchor surface within the captured first scene image in a first orientation that is appropriate for a user of the first body mounted device, and displaying on the head mounted display of the second body mounted device a second image of the virtual object, the second image displaying the virtual object as being anchored to a second anchor surface in a second orientation that is appropriate for a user of the second body mounted device.

0355In a further embodiment, the method may include sending the virtual object from the first body mounted device to the second body mounted device, receiving the virtual object in the second body mounted device, capturing a second scene image of the scene with the body mounted camera of the second body mounted device, and analyzing the captured second scene image to identify a suitable anchor surface within the second scene image that is in a direction close to a direction that the user of the second body mounted device is looking, in which displaying on the head mounted display of the second body mounted device a second image may include displaying the second image such that the virtual object is anchored to the identified suitable anchor surface. In an embodiment, the method may include transmitting a signal from the first body mounted device to the second body mounted device indicating an orientation of the virtual object, in which displaying the second image may include displaying the second image such that virtual object is oriented based in part on the signal received from the first body mounted device.

0356In a further embodiment, the method may include transmitting a signal from the first body mounted device to the second body mounted device indicating a preferred orientation of the virtual object, informing the user of the second body mounted device of the indicated preferred orientation, and receiving input from the user of the second body mounted device accepting or rejecting the indicated preferred orientation, in which displaying on the head mounted display of the second body mounted device a second image of the virtual object may include displaying the second image such that the virtual object is oriented based in part on the indicated preferred orientation when the received input accepts the indicated preferred orientation and such that the virtual object is oriented in a manner different from the indicated preferred orientation when the received input rejects the indicated preferred orientation.

0357In a further embodiment, the first anchor surface and the second anchor surface are the same surface. In a further embodiment, the method may include transmitting the virtual object from the first body mounted device to the second body mounted device, in which displaying on the head mounted display of the second body mounted device a second image of the virtual object may include displaying the second image as being anchored to the first anchor surface in the second orientation. In a further embodiment, the first and second body mounted devices are located in different locations, the method may further include transmitting the virtual object to each the first and second body mounted devices via a network.

0358In a further embodiment, the method may include capturing a second scene image with the body mounted camera of the second body mounted device, and receiving input on the second body mounted device indicating the second anchor surface in the captured second scene image, the indicated second anchor surface being different from the first anchor surface, in which displaying on the head mounted display of the second body mounted device a second image may include displaying the virtual object as being anchored to the indicated second anchor surface in a configuration appropriate for the indicated second anchor surface and the user of the second body mounted device. In a further embodiment, the method may include transmitting a second virtual object from the second body mounted device to the first body mounted device, and displaying a third image on the head mounted display of the first body mounted device, the third image displaying the second virtual object as being anchored to the first anchor surface.

0359Further embodiments may include systems, servers, and/or computing devices configured to perform various operations corresponding to the various embodiment methods and/or operations discussed above. Even further embodiments may include non-transitory processor-readable storage mediums having stored thereon processor-executable instructions to cause a processor to perform operations corresponding to the various embodiment methods and/or operations discussed above.

0360<figref idref="DRAWINGS">FIG. 41</figref> is a system block diagram of a receiver device suitable for use with any of the embodiments. A typical receiver device <b>4100</b> may include a processor <b>4101</b> coupled to internal memory <b>4102</b>, a display <b>4103</b>, and to a speaker <b>4154</b>. Additionally, the receiver device <b>4100</b> may include an antenna <b>4104</b> for sending and receiving electromagnetic radiation that may be connected to a wireless data link and/or cellular telephone transceiver <b>4105</b> coupled to the processor <b>4101</b> and a mobile multimedia broadcast receiver <b>4106</b> coupled to the processor <b>4101</b>. Receiver devices <b>4100</b> typically also include menu selection buttons or rocker switches <b>4108</b> for receiving user inputs.

0361The various embodiments may be implemented on any of a variety of commercially available server devices, such as the server <b>4200</b> illustrated in <figref idref="DRAWINGS">FIG. 42</figref>. Such a server <b>4200</b> typically may include a processor <b>4201</b> coupled to volatile memory <b>4202</b> and a large capacity nonvolatile memory, such as a disk drive <b>4203</b>. The server <b>4200</b> may also include a floppy disc drive, compact disc (CD) or DVD disc drive <b>4206</b> coupled to the processor <b>4201</b>. The server <b>4200</b> may also include network access ports <b>4204</b> coupled to the processor <b>4201</b> for establishing data connections with a network <b>4205</b>, such as a local area network coupled to other broadcast system computers and servers.

0362The processors <b>3903</b>, <b>3905</b>, <b>4101</b>, <b>4201</b> may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described above. In some devices, multiple processors <b>3903</b>, <b>3905</b>, <b>4101</b> may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications may be stored in the internal memory <b>4102</b>, <b>4202</b>, <b>4203</b> before they are accessed and loaded into the processor <b>4101</b>, <b>4201</b>. The processor <b>4101</b>, <b>4201</b> may include internal memory sufficient to store the application software instructions. In many devices the internal memory may be a volatile or nonvolatile memory, such as flash memory, or a mixture of both. For the purposes of this description, a general reference to memory refers to memory accessible by the processor <b>3903</b>, <b>3905</b>, <b>4101</b>, <b>4201</b> including internal memory or removable memory plugged into the device and memory within the processor <b>3903</b>, <b>3905</b>, <b>4101</b>, <b>4201</b> itself.

0363The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the steps of the various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the order of steps in the foregoing embodiments may be performed in any order. Words such as “thereafter,” “then,” “next,” etc. are not intended to limit the order of the steps; these words are simply used to guide the reader through the description of the methods. Further, any reference to claim elements in the singular, for example, using the articles “a,” “an” or “the” is not to be construed as limiting the element to the singular.

0364The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

0365The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some steps or methods may be performed by circuitry that is specific to a given function.

0366In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on as one or more instructions or code on a non-transitory computer-readable medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module executed which may reside on a non-transitory computer-readable medium. Non-transitory computer-readable media include any storage media may be accessed by a computer. By way of example, and not limitation, such non-transitory computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to carry or store desired program code in the form of instructions or data structures and that may be accessed by a computer. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of non-transitory computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory machine readable medium and/or non-transitory computer-readable medium, which may be incorporated into a computer program product.

0367The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.