Prosecution Insights
Last updated: August 18, 2026
Application No. 17/944,586

PROVIDING MULTIPLE PERSPECTIVES FOR VIEWING LOSSLESS TRANSMISSIONS OF VR SCENES

Final Rejection §103
Filed
Sep 14, 2022
Examiner
VAUGHN, ALEXANDER JOSEPH
Art Unit
2675
Tech Center
2600 — Communications
Assignee
T-Mobile USA Inc.
OA Round
4 (Final)
79%
Grant Probability
Favorable
5-6
OA Rounds
0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 79% — above average
79%
Career Allowance Rate
22 granted / 28 resolved
+16.6% vs TC avg
Strong +24% interview lift
Without
With
+24.1%
Interview Lift
resolved cases with interview
Typical timeline
2y 10m
Avg Prosecution
16 currently pending
Career history
40
Total Applications
across all art units

Statute-Specific Performance

§101
7.0%
-33.0% vs TC avg
§103
56.3%
+16.3% vs TC avg
§102
28.1%
-11.9% vs TC avg
§112
8.6%
-31.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 28 resolved cases

Office Action

§103
Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/27/2026 has been entered. Response to Amendment This action is responsive to applicant’s amendments and remarks received on 04/27/2026. Response to Arguments Applicant's arguments filed on 04/27/2026 have been fully considered but they are not persuasive. Applicant argues: Neeter does not teach a client device receiving uncompressed scene data transmitted losslessly from a source device because Neeter is silent on uncompressed data and whether received data is uncompressed prior to rendering. Neeter does not teach that the data received by the client device comprises scene data and tracking data and the tracking data includes a description of a movement and a position of one or more of a hand, a head, and an eye of a user associated with the source device. Lee does not teach a client device receiving uncompressed scene data transmitted losslessly from a source device because Lee teaches compressing data before transmission to another device prior to rendering. Lee does not teach that the data received by the client device comprise scene data and tracking data where the tracking data includes a description of a movement and a position of one or more of a hand, a head, and an eye of a user associated with the source device. Examiner’s response: Neeter is silent on compressed data. Under broadest reasonable interpretation, the data is transmitted in its natural uncompressed state. Compression would be an extra step. Neeter is silent on losslessly transmitting data. However, Lee discloses losslessly transmitting data (Para. 5, see rejection below.) Neeter discloses tracking data and hand movement and position of a hand. (See Para. 10, 55, 132, 185) The hand motions are tracked and rendered between client and server devices in real time. Lee discloses transmitting data losslessly (See Para. 5). Neeter discloses transmitting uncompressed data (Neeter is silent on compressed data. Under broadest reasonable interpretation, the data is transmitted in its natural uncompressed state. Compression would be an extra step). Lee discloses tracking a persons body, including hands and head. (Para. 10 see “the sparse feature information can include feature points such as points associated with aspects of the person's body (e.g., head, feet, hands, arms). As the person moves in the scene, the sensor and server computing device need only capture and transmit the positional changes associated with these feature points to the viewing device—instead of the entire model—and the viewing device can update the 3D model at the remote location using the sparse feature information to track the person's movements through the scene.”). Neeter discloses tracking data and hand movement and position of a hand. (See Para. 10, 55, 132, 185. See rejection below.) The hand motions are tracked and rendered between client and server devices in real time. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1, 3-6, 8-9, 11-13, 15-18, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Neeter (US 20200005538 A1), hereinafter Neeter, in view of Lee et al. (US 20180101966 A1), hereinafter Lee. Regarding claim 1, Neeter teaches A method comprising: receiving, at a client device, data indicating a 3D scene associated with a source device; the data comprising uncompressed scene data and tracking data, (Para. 45 see "the remote client virtual reality device 140 updates the remote MR scene 145 based on the updated real scene MR scene model 135". Para. 46 and Figs. 2A-2G see "the user interface 142 presents the user 110 with the data captured by the client virtual reality device 125 at the real scene 130, which may include, for example, images, 360 degree videos, 3D scans, or audio". Para. 10 and 55 discloses enactment models which may record and track position, orientation, scale, etc. of scene objects to simulate interaction with a scene in motion as a function of time enabling a user in a virtual environment to play back the recorded enactment. (Examiner Note: the "client virtual reality device" is the source device, the "remote client virtual reality device" is the client device. This is silent on compressed data. Under broadest reasonable interpretation, the data is transmitted in its natural uncompressed state.)). wherein the data is received by the client device prior to the 3D scene being rendered (Para. 45 see "the remote client virtual reality device 140 creates the remote MR scene 145 based on the real scene MR scene model 135." Para. 46 see "the real scene 130 is recreated in the remote MR scene 145". (Examiner Note: the real scene data is received before it is possible to recreate it with the remote client virtual reality device.)). thereby allowing the client to render the 3D scene with high fidelity, and wherein the tracking data includes a description of a movement and a position of one or more of a hand, a head, and an eye of a user associated with the source device; (Para. 132 see "The expert user then performs simulated VR actions on the VR panel to show the specific tasks and hand motions that the novice user would need to perform at the real panel at the remote location. The expert user's actions and instructions are recorded in VR, transmitted in real time and reproduced in MR by the technician at the substation." Para. 177 see "Regardless of the sensor type, we wish to obtain a texture-mapped, photorealistic mesh that can be transmitted to the central location with minimal lag. The mesh is a form of abstraction of the remote location and the objects of interest, and, in some cases, it may be desirable to simplify the geometry and approximate it with larger, planar faces connecting the most reliably reconstructed points."). based on the received data, determining, at the client device a set of view parameters for rendering the 3D scene at a client device; (Para. 45 see "the client virtual reality device 125 configures the VRE operable from the real scene 130 with the real scene MR scene model 135 generated from the real scene model based on the 3D geometry of the real scene 130." Para. 62 see "the initial data set may be created/collected by a client while operating at a remote location. In an illustrative example, the initial data set may include a scene's 3D geometry data." Para. 176 see "The goal in both cases is to generate a 3D representation of the scene that can be transmitted to the central location. The availability of a 3D model would enable the expert to manipulate it in the VRE, attach annotations and simulate the necessary operations to the technician more effectively than using a 2D representation for the same purposes." Para. 52 discloses using sensor/camera pose data. Para. 122-123 discloses tracking a path and state of a camera over time and rendering the frames to a surveillance screen using an enactment. (Examiner Note: The real scene model from the client device includes 3D data which is received and rendered by the remote client virtual reality device by mapping the real scene to the remote scene described in para. 45-46.)). and generating a rendering of the 3D scene according to the set of view parameters (Para. 45 see "the remote client virtual reality device 140 creates the remote MR scene 145 based on the real scene MR scene model 135." Para. 46 see "the real scene 130 is recreated in the remote MR scene 145". Para. 163 and 178 discloses rendering based on 3D data.). Neeter does not teach that is transmitted losslessly from the source device and responsive to user input, the set of view parameters allowing the client device to render the 3D scene from a perspective different than a perspective of the source device; resulting in the rendering having the perspective that is different from the perspective of the source device. However, Lee teaches that is transmitted losslessly from the source device (Para. 5 see "Therefore, what is needed are methods and systems for lossless (or slightly lossy) compression to transmit a live three-dimensional scene"). and responsive to user input, (Para. 6 see "the technology described herein can be used to capture a scene (including objects in the scene) of a first location as one or more 3D models, transfer the 3D model(s) in real time to a second location that is remote from the first location, and then render viewing images of the 3D model from a different viewing perspective using the pose of a viewing element." Para . 52 see "the viewing device 112 can be used to ‘walk around’ the virtual scene which is a true 3D copy of the first location (such as via a VR viewing device)." (Examiner note: The user walks around as input, the device responds.)). the set of view parameters allowing the client device to render the 3D scene from a perspective different than a perspective of the source device; (Para. 52 see "the viewing device 112 is not tied to the original video capture perspective of the sensor 103 because the complete 3D model is recreated at the viewing device 112. Therefore, the viewing device (e.g., the CPU 114 and GPU 116) at the second location can manipulate the 3D model(s) locally in order to produce a completely independent perspective of the model(s) than what is being captured by the sensor 103 at the first location." Para. 60 see "the headset can render a different viewpoint of the scene and objects in the scene from that being captured by the sensor device. As such, the viewer at the remote location can traverse the scene and view the action from a completely independent perspective from the sensor that is viewing the scene locally providing an immersive and unique experience for the viewer."). resulting in the rendering having the perspective that is different from the perspective of the source device. (Para. 52 see "the viewing device 112 is not tied to the original video capture perspective of the sensor 103 because the complete 3D model is recreated at the viewing device 112. Therefore, the viewing device (e.g., the CPU 114 and GPU 116) at the second location can manipulate the 3D model(s) locally in order to produce a completely independent perspective of the model(s) than what is being captured by the sensor 103 at the first location." Para. 60 see "the headset can render a different viewpoint of the scene and objects in the scene from that being captured by the sensor device. As such, the viewer at the remote location can traverse the scene and view the action from a completely independent perspective from the sensor that is viewing the scene locally providing an immersive and unique experience for the viewer."). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Neeter to incorporate the teachings of Lee to determine a set of view paramters at the client device responding to user input and to allow the client device to render the scene from a different perspective and transmit data losslessly. Doing so would predictably increase user experience by automatically responding to the input of the user to determine view parameters, creating a seamless and immersive experience. Additionally, this would predictably increase user experience by allowing the user to view the scene from a different perspective than the source device, giving the user a feeling of independence as opposed to simply being an observer in the 3D environment. Furthermore, this would predictably increase the quality of the rendered scene on the client device by transmitting data losslessly. Regarding claim 3, Neeter in view of Lee teaches The method of claim 1. In addition, Neeter teaches wherein determining the set of view parameters comprises receiving virtual camera data associated with the client device. (Para. 52 discloses using the relative position of a virtual camera to provide the camera pose.). Regarding claim 4, Neeter in view of Lee teaches The method of claim 1. In addition, Neeter teaches wherein the method further comprises: receiving tracking data associated with the source device; (Para. 52 discloses using sensor tracking information.). and using the tracking data to determine the set of view parameters. (Para. 52 discloses using tracking information to provide the camera pose.). Regarding claim 5, Neeter in view of Lee teaches The method of claim 1. In addition, Neeter teaches wherein generating the rendering is performed by the client device. (Para. 45 see " the client virtual reality device 125 configures the VRE operable from the real scene 130 with the real scene MR scene model 135 generated from the real scene model based on the 3D geometry of the real scene 130", Para. 163 and 178 discloses rendering based on 3D data.). Regarding claim 6, Neeter in view of Lee teaches The method of claim 1. In addition, Neeter teaches wherein the 3D scene associated with the source device is mapped to a first physical environment and the rendering is mapped to a second physical environment. (Para. 50-51 discloses using sensors to create a 3D MR scene model. Points/features are used to align the remote and HQ scene models in 3D space. Para. 130 discloses connecting two physical locations into a shared virtual environment.). Regarding claim 8, Neeter in view of Lee teaches The method of claim 1. In addition, Neeter teaches wherein the data indicating the 3D scene associated with the source device is generated using at least a virtual reality device. (Para. 46 and Figs. 2A-2G see "the user interface 142 presents the user 110 with the data captured by the client virtual reality device 125 at the real scene 130, which may include, for example, images, 360 degree videos, 3D scans, or audio".). Regarding claim 9, Neeter teaches A system comprising: one or more processors; (Para. 74 discloses computer-executable instructions, program memory, and a processor to execute.). and one or more computer storage hardware devices storing computer-usable instructions that when used by the one or more processors, cause the one or more processors to: (Para. 74 and Fig. 30 see "the block diagram of the exemplary client virtual reality device 125 includes processor 3005 and memory 3010", Para. 205 further discloses computing devices.). at a client device, receive data indicating a 3D scene associated with a source device, the data comprising uncompressed scene data and tracking data, (Para. 45 see "the remote client virtual reality device 140 updates the remote MR scene 145 based on the updated real scene MR scene model 135", Para. 46 and Figs. 2A-2G see "the user interface 142 presents the user 110 with the data captured by the client virtual reality device 125 at the real scene 130, which may include, for example, images, 360 degree videos, 3D scans, or audio". Para. 10 and 55 discloses enactment models which may record and track position, orientation, scale, etc. of scene objects to simulate interaction with a scene in motion as a function of time enabling a user in a virtual environment to play back the recorded enactment. (Examiner Note: the "client virtual reality device" is the source device, the "remote client virtual reality device" is the client device.)). wherein the data is received by the client device prior to the 3D scene being rendered (Para. 45 see "the remote client virtual reality device 140 creates the remote MR scene 145 based on the real scene MR scene model 135." Para. 46 see "the real scene 130 is recreated in the remote MR scene 145". (Examiner Note: the real scene data is received before it is possible to recreate it with the remote client virtual reality device.)). thereby allowing the client to render the 3D scene with high-fidelity, and wherein the tracking data includes a description of a movement and a position of one or more of a hand, a head, and an eye of a user associated with the source device; (Para. 132 see "The expert user then performs simulated VR actions on the VR panel to show the specific tasks and hand motions that the novice user would need to perform at the real panel at the remote location. The expert user's actions and instructions are recorded in VR, transmitted in real time and reproduced in MR by the technician at the substation." Para. 177 see "Regardless of the sensor type, we wish to obtain a texture-mapped, photorealistic mesh that can be transmitted to the central location with minimal lag. The mesh is a form of abstraction of the remote location and the objects of interest, and, in some cases, it may be desirable to simplify the geometry and approximate it with larger, planar faces connecting the most reliably reconstructed points."). determine a set of view parameters for presentation of the 3D scene at a client device (Para. 45 see "the client virtual reality device 125 configures the VRE operable from the real scene 130 with the real scene MR scene model 135 generated from the real scene model based on the 3D geometry of the real scene 130." Para. 62 see "the initial data set may be created/collected by a client while operating at a remote location. In an illustrative example, the initial data set may include a scene's 3D geometry data." Para. 46 and Figs. 2A-2G see "the user interface 142 presents the user 110 with the data captured by the client virtual reality device 125 at the real scene 130, which may include, for example, images, 360 degree videos, 3D scans, or audio". Para. 176 see "The goal in both cases is to generate a 3D representation of the scene that can be transmitted to the central location. The availability of a 3D model would enable the expert to manipulate it in the VRE, attach annotations and simulate the necessary operations to the technician more effectively than using a 2D representation for the same purposes." Para. 52 discloses using sensor/camera pose data. Para. 122-123 discloses tracking a path and state of a camera over time and rendering the frames to a surveillance screen using an enactment. (Examiner Note: The real scene model from the client device includes 3D data which is received and rendered by the remote client virtual reality device by mapping the real scene to the remote scene described in para. 45-46. This is then presented to the user via the user interface.)). generate a rendering of the 3D scene according to the set of view parameters (Para. 45 see "the remote client virtual reality device 140 creates the remote MR scene 145 based on the real scene MR scene model 135." Para. 46 see "the real scene 130 is recreated in the remote MR scene 145". Para. 163 and 178 discloses rendering based on 3D data.). and transmit the rendering of the 3D scene to the client device. (Para. 45 see "the remote client virtual reality device 140 transmits the calibrated remote MR scene 165 to the client virtual reality device 125 via the collaboration server 120". Para. 52 discloses using sensor/camera pose data. Para. 122-123 discloses tracking a path and state of a camera over time and rendering the frames to a surveillance screen using an enactment.). Neeter does not teach that is transmitted losslessly from the source device and responsive to user input, the set of view parameters allowing the client device to render the 3D scene from a perspective different than a perspective of the source device; resulting in the rendering having the perspective that is different from the perspective of the source device;. However, Lee teaches that is transmitted losslessly from the source device (Para. 5 see "Therefore, what is needed are methods and systems for lossless (or slightly lossy) compression to transmit a live three-dimensional scene"). and responsive to user input, the set of view parameters allowing the client device to render the 3D scene from a perspective different than a perspective of the source device; (Para. 6 see "the technology described herein can be used to capture a scene (including objects in the scene) of a first location as one or more 3D models, transfer the 3D model(s) in real time to a second location that is remote from the first location, and then render viewing images of the 3D model from a different viewing perspective using the pose of a viewing element." Para . 52 see "the viewing device 112 can be used to ‘walk around’ the virtual scene which is a true 3D copy of the first location (such as via a VR viewing device)." (Examiner note: The user walks around as input, the device responds.) Para. 66 see "a keyboard and a pointing device, e.g., a mouse, a trackball, a touchpad, or a motion sensor, by which the user can provide input to the computer" Para. 52 see "the viewing device 112 is not tied to the original video capture perspective of the sensor 103 because the complete 3D model is recreated at the viewing device 112. Therefore, the viewing device (e.g., the CPU 114 and GPU 116) at the second location can manipulate the 3D model(s) locally in order to produce a completely independent perspective of the model(s) than what is being captured by the sensor 103 at the first location." Para. 60 see "the headset can render a different viewpoint of the scene and objects in the scene from that being captured by the sensor device. As such, the viewer at the remote location can traverse the scene and view the action from a completely independent perspective from the sensor that is viewing the scene locally providing an immersive and unique experience for the viewer."). resulting in the rendering having the perspective that is different from the perspective of the source device; (Para. 52 see "the viewing device 112 is not tied to the original video capture perspective of the sensor 103 because the complete 3D model is recreated at the viewing device 112. Therefore, the viewing device (e.g., the CPU 114 and GPU 116) at the second location can manipulate the 3D model(s) locally in order to produce a completely independent perspective of the model(s) than what is being captured by the sensor 103 at the first location." Para. 60 see "the headset can render a different viewpoint of the scene and objects in the scene from that being captured by the sensor device. As such, the viewer at the remote location can traverse the scene and view the action from a completely independent perspective from the sensor that is viewing the scene locally providing an immersive and unique experience for the viewer."). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Neeter to incorporate the teachings of Lee to determine a set of view paramters at the client device responding to user input and to allow the client device to render the scene from a different perspective and transmit data losslessly. Doing so would predictably increase user experience by automatically responding to the input of the user to determine view parameters, creating a seamless and immersive experience. Additionally, this would predictably increase user experience by allowing the user to view the scene from a different perspective than the source device, giving the user a feeling of independence as opposed to simply being an observer in the 3D environment. Furthermore, this would predictably increase the quality of the rendered scene on the client device by transmitting data losslessly. Regarding claim 11, Neeter in view of Lee teaches The system of claim 9. In addition, Neeter teaches wherein determining the set of view parameters comprises receiving virtual camera data associated with the client device. (Para. 52 discloses using the relative position of a virtual camera to provide the camera pose.). Regarding claim 12, Neeter in view of Lee teaches The system of claim 9. In addition, Neeter teaches wherein the data indicating the 3D scene comprises virtual reality ("VR") tracking data associated with the source device used to determine the set of view parameters. (Para. 52 discloses using sensor tracking information.). Regarding claim 13, Neeter in view of Lee teaches The system of claim 9. In addition, Neeter teaches wherein the 3D scene associated with the source device is mapped to a first physical environment and the rendering is mapped to a second physical environment associated with the client device. (Para. 50-51 discloses using sensors to create a 3D MR scene model. Points/features are used to align the remote and HQ scene models in 3D space. Para. 130 discloses connecting two physical locations into a shared virtual environment.). Regarding claim 15, Neeter in view of Lee teaches The system of claim 9. In addition, Neeter teaches wherein the data indicating the 3D scene associated with the source device is generated using at least a virtual reality device. (Para. 46 and Figs. 2A-2G see "the user interface 142 presents the user 110 with the data captured by the client virtual reality device 125 at the real scene 130, which may include, for example, images, 360 degree videos, 3D scans, or audio".). Regarding claim 16, Neeter teaches One or more non-transitory computer-readable media having computer-executable instructions embodied thereon that, when executed, perform a method comprising: (Para. 74 discloses computer-executable instructions, program memory, and a processor to execute.). receiving data corresponding to a 3D scene associated with a source device, wherein the source device comprises one or more virtual reality ("VR") sensors, the data comprising uncompressed scene data and tracking data, (Para. 45 see "the remote client virtual reality device 140 updates the remote MR scene 145 based on the updated real scene MR scene model 135" and "the client virtual reality device 125 creates a real scene model based on the sensor data captured from the scan of the real scene 130", Para. 46 and Figs. 2A-2G see "the user interface 142 presents the user 110 with the data captured by the client virtual reality device 125 at the real scene 130, which may include, for example, images, 360 degree videos, 3D scans, or audio". Para. 10 and 55 discloses enactment models which may record and track position, orientation, scale, etc. of scene objects to simulate interaction with a scene in motion as a function of time enabling a user in a virtual environment to play back the recorded enactment. (Examiner Note: the "client virtual reality device" is the source device, the "remote client virtual reality device" is the client device.)). and wherein the data is received by the client device prior to the 3D scene being rendered (Para. 45 see "the remote client virtual reality device 140 creates the remote MR scene 145 based on the real scene MR scene model 135." Para. 46 see "the real scene 130 is recreated in the remote MR scene 145". (Examiner Note: the real scene data is received before it is possible to recreate it with the remote client virtual reality device.)). thereby allowing the client to render the 3D scene with high-fidelity, and wherein the tracking data includes a description of a movement and a position of one or more of a hand, a head, and an eye of a user associated with the source device; (Para. 132 see "The expert user then performs simulated VR actions on the VR panel to show the specific tasks and hand motions that the novice user would need to perform at the real panel at the remote location. The expert user's actions and instructions are recorded in VR, transmitted in real time and reproduced in MR by the technician at the substation." Para. 177 see "Regardless of the sensor type, we wish to obtain a texture-mapped, photorealistic mesh that can be transmitted to the central location with minimal lag. The mesh is a form of abstraction of the remote location and the objects of interest, and, in some cases, it may be desirable to simplify the geometry and approximate it with larger, planar faces connecting the most reliably reconstructed points."). determining a set of view parameters for rendering the 3D scene at a client device (Para. 45 see "the client virtual reality device 125 creates a real scene model based on the sensor data captured from the scan of the real scene 130"). wherein the set of view parameters comprises an attribute associated with a virtual camera associated with the 3D scene; (Para. 45 see "the client virtual reality device 125 creates a real scene model based on the sensor data captured from the scan of the real scene 130", Para. 52 discloses using sensor/camera pose data and relative position of a virtual camera to provide the camera pose.). and generating a rendering, at the client device, of the 3D scene in accordance with the set of view parameters. (Para. 45 see " the client virtual reality device 125 configures the VRE operable from the real scene 130 with the real scene MR scene model 135 generated from the real scene model based on the 3D geometry of the real scene 130", Para. 163 and 178 discloses rendering based on 3D data.). Neeter does not teach that is transmitted losslessly from the source device and responsive to user input, and allows the client device to render the 3D scene from a perspective different than a perspective of the source device; resulting in the rendering having the perspective that is different from the perspective of the source device. However, Lee teaches that is transmitted losslessly from the source device (Para. 5 see "Therefore, what is needed are methods and systems for lossless (or slightly lossy) compression to transmit a live three-dimensional scene"). and responsive to user input, (Para. 6 see "the technology described herein can be used to capture a scene (including objects in the scene) of a first location as one or more 3D models, transfer the 3D model(s) in real time to a second location that is remote from the first location, and then render viewing images of the 3D model from a different viewing perspective using the pose of a viewing element." Para . 52 see "the viewing device 112 can be used to ‘walk around’ the virtual scene which is a true 3D copy of the first location (such as via a VR viewing device)." (Examiner note: The user walks around as input, the device responds.)). and allows the client device to render the 3D scene from a perspective different than a perspective of the source device; (Para. 52 see "the viewing device 112 is not tied to the original video capture perspective of the sensor 103 because the complete 3D model is recreated at the viewing device 112. Therefore, the viewing device (e.g., the CPU 114 and GPU 116) at the second location can manipulate the 3D model(s) locally in order to produce a completely independent perspective of the model(s) than what is being captured by the sensor 103 at the first location." Para. 60 see "the headset can render a different viewpoint of the scene and objects in the scene from that being captured by the sensor device. As such, the viewer at the remote location can traverse the scene and view the action from a completely independent perspective from the sensor that is viewing the scene locally providing an immersive and unique experience for the viewer."). resulting in the rendering having the perspective that is different from the perspective of the source device. (Para. 52 see "the viewing device 112 is not tied to the original video capture perspective of the sensor 103 because the complete 3D model is recreated at the viewing device 112. Therefore, the viewing device (e.g., the CPU 114 and GPU 116) at the second location can manipulate the 3D model(s) locally in order to produce a completely independent perspective of the model(s) than what is being captured by the sensor 103 at the first location." Para. 60 see "the headset can render a different viewpoint of the scene and objects in the scene from that being captured by the sensor device. As such, the viewer at the remote location can traverse the scene and view the action from a completely independent perspective from the sensor that is viewing the scene locally providing an immersive and unique experience for the viewer."). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Neeter to incorporate the teachings of Lee to determine a set of view paramters at the client device responding to user input and to allow the client device to render the scene from a different perspective and transmit data losslessly. Doing so would predictably increase user experience by automatically responding to the input of the user to determine view parameters, creating a seamless and immersive experience. Additionally, this would predictably increase user experience by allowing the user to view the scene from a different perspective than the source device, giving the user a feeling of independence as opposed to simply being an observer in the 3D environment. Furthermore, this would predictably increase the quality of the rendered scene on the client device by transmitting data losslessly. Regarding claim 17, Neeter in view of Lee teaches The media of claim 16. In addition, Neeter teaches wherein the 3D scene associated with the source device is mapped to a first physical environment and the rendering is mapped to a second physical environment associated with the client device. (Para. 50-51 discloses using sensors to create a 3D MR scene model. Points/features are used to align the remote and HQ scene models in 3D space. Para. 130 discloses connecting two physical locations into a shared virtual environment.). Regarding claim 18, Neeter in view of Lee teaches The media of claim 16. In addition, Neeter teaches wherein the rendering is presented in a user interface of the client device. (Para. 46 and Figs. 2A-2G see "the user interface 142 presents the user 110 with the data captured by the client virtual reality device 125 at the real scene 130, which may include, for example, images, 360 degree videos, 3D scans, or audio".). Regarding claim 20, Neeter in view of Lee teaches The media of claim 16. In addition, Neeter teaches wherein the attribute associated with the virtual camera comprises a position, direction, field of view, depth of field, or tracked object. (Para. 52 discloses using the relative position of a virtual camera to provide the camera pose.). Claims 7, 14, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Neeter (US 20200005538 A1), hereinafter Neeter, in view of Lee et al. (US 20180101966 A1), hereinafter Lee, and Bergmann et al. (US 20190098255 A1), hereinafter Bergmann. Regarding claim 7, Neeter in view of Lee teaches The method of claim 1. Neeter does not teach further comprising determining a second set of view parameters for rendering the 3D scene at a second client device; and generating a second rendering of the 3D scene according to the second set of view parameters. However, Bergmann teaches further comprising determining a second set of view parameters for rendering the 3D scene at a second client device; and generating a second rendering of the 3D scene according to the second set of view parameters. ((Para. 8 discloses transmitting 3D point cloud data to a plurality of meeting participants in a VR environment. Para. 40 discloses rendering based on points and position of the VR viewer.). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Neeter and Lee to incorporate the teachings of Bergmann to allow a second client device to receive and render 3D scene data. Doing so would allow multiple users to view the ongoing session between an expert and technician for purposes such as supervision, additional expert input, or training of additional users. Regarding claim 14, Neeter in view of Lee teaches The system of claim 9. Neeter does not teach wherein a second set of view parameters for presentation of the 3D scene at a second client device is determined and a second rendering of the 3D scene is rendered according to the second set of view parameters. However, Bergmann teaches wherein a second set of view parameters for presentation of the 3D scene at a second client device is determined and a second rendering of the 3D scene is rendered according to the second set of view parameters. (Para. 8 discloses transmitting 3D point cloud data to a plurality of meeting participants in a VR environment. Para. 40 discloses rendering based on points and position of the VR viewer.). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Neeter and Lee to incorporate the teachings of Bergmann to allow a second client device to receive and render 3D scene data. Doing so would allow multiple users to view the ongoing session between an expert and technician for purposes such as supervision, additional expert input, or training of additional users. Regarding claim 19, Neeter in view of Lee teaches The media of claim 16. Neeter does not teach wherein the method further comprises determining a second set of view parameters for rendering the 3D scene at a second client device and generating a second rendering, at the second client devices, of the 3D scene in accordance with the second set of view parameters. However, Bergmann teaches wherein the method further comprises determining a second set of view parameters for rendering the 3D scene at a second client device and generating a second rendering, at the second client devices, of the 3D scene in accordance with the second set of view parameters. (Para. 8 discloses transmitting 3D point cloud data to a plurality of meeting participants in a VR environment. Para. 40 discloses rendering based on points and position of the VR viewer.). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Neeter and Lee to incorporate the teachings of Bergmann to allow a second client device to receive and render 3D scene data. Doing so would allow multiple users to view the ongoing session between an expert and technician for purposes such as supervision, additional expert input, or training of additional users. Conclusion THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. French (US 20180063205 A1) discloses shared virtual reality environments among users as well as rendering and displaying real and virtual environments constructed from 3D maps. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALEXANDER J VAUGHN whose telephone number is (571) 272-5253. The examiner can normally be reached M-F 8:30-5. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, ANDREW MOYER can be reached on (571) 272-9523. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /ALEXANDER JOSEPH VAUGHN/Examiner, Art Unit 2675 /EDWARD PARK/Primary Examiner, Art Unit 2675
Read full office action

Prosecution Timeline

Show 2 earlier events
Jun 09, 2025
Response Filed
Jul 14, 2025
Final Rejection mailed — §103
Nov 12, 2025
Response after Non-Final Action
Dec 12, 2025
Request for Continued Examination
Jan 14, 2026
Response after Non-Final Action
Jan 27, 2026
Non-Final Rejection mailed — §103
Apr 27, 2026
Response Filed
Jun 23, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12694645
SYSTEMS AND METHODS FOR AUTOMATICALLY DETECTING SUBSTANCES IN MEDICAL IMAGING
3y 7m to grant Granted Jul 28, 2026
Patent 12694668
METHODS AND SYSTEMS FOR ASSIGNING A TASK TO A CONSTELLATION OF SATELLITES
2y 8m to grant Granted Jul 28, 2026
Patent 12682473
MEASUREMENT SYSTEM, INSPECTION SYSTEM, MEASUREMENT DEVICE, MEASUREMENT METHOD, INSPECTION METHOD, AND PROGRAM
3y 0m to grant Granted Jul 14, 2026
Patent 12675977
METHOD AND SYSTEM FOR PREPROCESSING OPTIMIZATION OF STREAMING VIDEO DATA USING MACHINE LEARNING
3y 11m to grant Granted Jul 07, 2026
Patent 12664677
IMAGE ANALYSIS APPARATUS, IMAGE ANALYSIS METHOD, AND A NON-TRANSITORY STORAGE MEDIUM
2y 12m to grant Granted Jun 23, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

5-6
Expected OA Rounds
79%
Grant Probability
99%
With Interview (+24.1%)
2y 10m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 28 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month