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 .
DETAILED ACTION
Response to Amendment
This is in response to applicant’s amendment/response filed on 03/30/2026, which has been entered and made of record. Claims 1-15 are pending in the application.
Response to Arguments
Applicant's arguments filed on 03/30/2026 have been fully considered but they are not persuasive.
Applicant submits “Ambrus fails to disclose or suggest a server that receives pose information from a client device twice, over two separate time periods, and estimates predicted poses twice, where the estimation and predictions then shift to the client device, which collects third pose information of the client device, estimates a third predicted pose, and the client device generates a third image from the second pose predicted by the sever.” (Remarks, Page 9.)
The examiner disagrees with Applicant’s premises and conclusion. Ambrus, Fig. 1, at step 108 and 110, ¶0034, “the process described above is continuously repeating, such that at any given moment in time, multiple steps of the process are being carried out simultaneously.”. Therefore, Ambrus teaches “a server that receives pose information from a client device twice, over two separate time periods, and estimates predicted poses twice”. At step 122, ¶0031, “a late stage reprojection machine of the virtual reality device 100 adjusts the virtual image before it is displayed.” “the late stage reprojection machine may adjust the image by shifting the virtual image by an amount that is proportional to a difference between the predicted future pose and the updated tracked pose.”. The late stage reprojection teaches “collects third pose information of the client device, estimates a third predicted pose, and the client device generates a third image from the second pose predicted by the sever”.
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 6-11, 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Ambrus et al. (US Pub 2017/0115488 A1) in view of Banerjee et al. (US Pub 2020/0104975 A1).
As to claim 1, Ambrus discloses a system comprising at least one server that is communicably coupled to at least one client device (Fig. 1), wherein the at least one server is configured to:
receive, from the at least one client device, first pose information indicative of at least a pose of the at least one client device over a first time period (¶0016, “At 106, one or more sensors track a pose of the virtual reality device. A pose may be defined as a set of variables establishing the virtual reality device's position and/or orientation at a specific moment in time.”);
estimate a first predicted pose corresponding to a future time instant, based on the first pose information (¶0017, “At 108, a pose prediction machine of virtual reality device 100 predicts a future pose of the virtual reality device at a future time. The future time may be any suitable time in the future, and may be established according to one or more criteria” ¶0018, “In order to predict the future pose, the pose prediction machine may make use of the virtual reality device's current pose and movement, as tracked by the one or more sensors. Then, the pose prediction machine may extrapolate the detected motion forward from the current time to the future time, thus generating a reasonable approximation of the position and/or orientation the virtual reality device 100 is likely to have at or near the future time.” ¶0021, “the pose prediction machine is shown as being part of the virtual reality device. However, in some embodiments, the pose prediction machine may be part of the remote computer. For example, the virtual reality device may send to the remote computer data from the one or more sensors, and the pose prediction machine of the remote computer may predict the future pose of the virtual reality device based on the sensor data, as described above.”);
generate a first image according to the first predicted pose (¶0026, “At 114, a virtual image renderer of the remote computer renders the virtual image for the virtual reality device as specified by the request.”);
receive, from the at least one client device, second pose information indicative of at least the pose of the at least one client device over a second time period that ends after the first time period (¶0051, “At 306, the virtual reality device adjusts the rendered virtual image before it is displayed. In this case, adjusting the virtual image comprises cropping the virtual image to the set resolution of the virtual reality display. At this time, the late stage reprojection machine may perform any other adjustment operations before the virtual image is displayed. For example, the late stage reprojection machine may shift the virtual image in order to account for differences between the predicted future pose and the updated tracked pose.”);
estimate a second predicted pose corresponding to the future time instant, based on the second pose information (¶0034, “the process described above is continuously repeating, such that at any given moment in time, multiple steps of the process are being carried out simultaneously. For example, at the same time a virtual image is being displayed by the virtual reality display, new future poses are being predicted, and new virtual images are being requested, rendered, and adjusted.”);
generate a second image by reprojecting the first image from the first predicted pose to the second predicted pose using a first reprojection algorithm (¶0046,”During remote rendering, virtual images may be rendered based on which virtual objects would be visible to a virtual reality device occupying a predicted future pose at a future time.”¶0047, “a virtual image may be rendered which is oversized relative to a set resolution of a virtual reality display, then cropped to match the set resolution before the virtual image is displayed.” ¶0052, “The late stage reprojection machine has cropped the rendered virtual image 304 to the set resolution of the virtual reality display.” “After adjustment, the cropped virtual image will be displayed by the virtual reality display at or near the future time corresponding to the previously predicted pose.” ¶0055, “a virtual reality device has recently moved slightly downward and to the left, and as a result, the virtual image has shifted slightly up and to the right in the virtual reality device's FOV, thereby compensating for differences between the predicted future pose and the updated tracked pose.” ¶0056, “in addition to one or more color values used to illuminate the display (e.g., RGB values), each pixel may also include underlying depth information (e.g., D value) which is not displayed, but which can be used to position the individual virtual objects on the display if the predicted pose differs from an updated tracked pose.”); and
send the second image to the at least one client device (¶0059, “the remote computer may render a three-dimensional image and transmit it to the virtual reality device for adjustment and display.” “the remote computer may render a two-dimensional RGB virtual image and send this virtual image to the virtual reality device along with an associated depth map. The late stage reprojection machine may then adjust the received virtual image according to differences between the predicted future pose and the updated tracked pose, and further according to information included in the received depth map.”),
wherein the at least one client device is configured to:
collect third pose information indicative of at least the pose of the at least one client device over a third time period that ends after the second time period (¶0031, “the rendered virtual image, which has a perspective corresponding to the predicted future pose, may be adjusted to have an updated perspective corresponding to an updated tracked pose of the virtual reality device.”);
estimate a third predicted pose corresponding to the future time instant, based on the third pose information (¶0032, “the pose prediction machine may begin continuously comparing the most recent updated tracked pose to the predicted future pose as soon as the virtual image is requested, dynamically determining which adjustments need to be made to the rendered virtual image before it is displayed.”);
generate a third image by reprojecting the second image from the second predicted pose to the third predicted pose using a second reprojection algorithm (¶0032, “the updated tracked pose used by the late stage reprojection machine will be the last possible pose which can be used before the virtual image is displayed, so as to ensure that the virtual image is adjusted according to the most recent possible information. The updated tracked pose used to adjust the rendered virtual image may represent the virtual reality device's position and/or orientation at a time either before the virtual image has been received, or after the virtual image has been received and before it is displayed.”); and
display the third image (¶0033, “At 124, a virtual reality display of the virtual reality device 100 displays the adjusted virtual image at or near the future time.”).
Examiner would like to point out that Ambrus gave examples and figures mostly focus on the pose prediction machine on the client side. However, Ambrus clearly suggests the pose prediction machine could be on the server side (Ambrush, ¶0093, “The pose prediction machine 806 and the late stage reprojection machine 808 may be implemented via logic machine 802 and storage machine 804 and/or any other suitable devices.”. “Further, the remote computer may include a pose prediction machine, as described above, which may be implemented via logic machine 818 and storage machine 820.”). Therefore, it will be obvious to implement a reprojection on the server side when the pose prediction machine is on the server side. Ambrus would teach all limitations of the claim when a server side reprojection is implemented.
Banerjee further suggests receive, from the at least one client device, second pose information indicative of at least the pose of the at least one client device over a second time period that ends after the first time period (Banerjee, Fig. 6, ¶0051, “system 600 includes server 602 and client 604. Server 602 includes renderer 610 and sample motion vectors 630.” “pose 622” ¶0052, “the entire motion vector production can be on the server 602” “if the server 602 or game engine understands the location of the next motion, it can be more accurate to generate the motion vectors at the server 602. As shown in the example in FIG. 6, motion vectors can be sampled in a grid formation”);
estimate a second predicted pose corresponding to the future time instant, based on the second pose information (Banerjee, ¶0052, “the entire motion vector production can be on the server 602” “if the server 602 or game engine understands the location of the next motion, it can be more accurate to generate the motion vectors at the server 602. As shown in the example in FIG. 6, motion vectors can be sampled in a grid formation”);
generate a second image by reprojecting the first image from the first predicted pose to the second predicted pose using a first reprojection algorithm (Banerjee, Fig.7, ¶0054, “Server 702 includes renderer 710, pose predictor 730, depth based reprojection unit 740, modification unit 742, e.g., where occluded motion vectors are modified to avoid z-fighting, and filtered motion vectors 744.” Server performs depth based reprojection.” ¶0055, “the example shown in FIG. 7 can build on the example in FIG. 6, e.g., motion vector generation can be performed on the server 702.” ¶0057, “it can be fairly easy to re-project grid vertices to the predicted display pose.” ¶0061-0062.); and
send the second image to the at least one client device (Fig. 7).
Ambrus and Banerjee are considered to be analogous art because all pertain to graphics processing. It would have been obvious before the effective filing date of the claimed invention to have modified Ambrus with the features of “receive, from the at least one client device, second pose information indicative of at least the pose of the at least one client device over a second time period that ends after the first time period; estimate a second predicted pose corresponding to the future time instant, based on the second pose information; generate a second image by reprojecting the first image from the first predicted pose to the second predicted pose using a first reprojection algorithm; and send the second image to the at least one client device” as taught by Banerjee. The suggestion/motivation would have been if the server or game engine understands the location of the next motion, it can be more accurate to generate the motion vectors at the server (Banerjee, ¶0052) and the complexity of motion vector generation can be moved to server 602 which results in less computations on the client end and more power benefits (Banerjee, ¶0053).
As to claim 2, claim 1 is incorporated and the combination of Ambrus and Banerjee teaches the second reprojection algorithm is different from the first reprojection algorithm (Ambrus, ¶0059, “Adjusting the two-dimensional virtual image to include information from the depth map may be done through any suitable technique including, for example, rendering the image on a tessellated plane as a heightmap, or building a voxel representation of the virtual environment.” Banerjee, ¶0041, asynchronous space warp.).
As to claim 3, claim 1 is incorporated and the combination of Ambrus and Banerjee teaches the second reprojection algorithm is same as the first reprojection algorithm (Ambrus, ¶0059, “according to information included in the received depth map..” Banerjee, ¶0041, asynchronous space warp.).
As to claim 4, claim 1 is incorporated and the combination of Ambrus and Banerjee teaches the at least one server is configured to:
generate a motion vector map corresponding to the second image, based on previously-generated second images, using at least one optical flow algorithm, wherein the motion vector map indicates motion vectors per pixel or per group of pixels (Banerjee, ¶0047, “Motion vectors may be generated by computer algorithms that compare the last received frame and previously aligned frames via patch matching or optical flow” ¶0052, “motion vectors can be sampled in a grid formation” ¶0053, “per-pixel motion vectors” ¶0058, “the game engine or server can provide a pixel-level z-map and a motion vector map”); and
send the motion vector map to the at least one client device (Banerjee, Fig. 6, ¶0052, “motion vectors can be generated and sampled at the server 602 and sent to the client 604”),
wherein the at least one client device is configured to utilize the motion vector map with the second reprojection algorithm, to perform a nine degrees-of-freedom (9DOF) reprojection (Banerjee, ¶0052, “After receiving the motion vectors, the client 604 can decode, extrapolate, and perform the warping.” Ambrus, ¶0073, “HMD 700 may include an accelerometer 708K, gyroscope 708L, and magnetometer 708M”. an accelerometer 708K, gyroscope 708L, and magnetometer 708M each comprising three degrees of freedom. When combined together will have a nine degree of freedom.).
As to claim 6, claim 2 is incorporated and the combination of Ambrus and Banerjee teaches the first reprojection algorithm performs any of: a six degrees-of-freedom (6DOF) reprojection, a nine degrees-of-freedom (9DOF) reprojection, while the second reprojection algorithm performs a three degrees-of-freedom (3DOF) reprojection (Ambrus, ¶0016, “Such variables may include the device's current three-dimensional coordinates (e.g., X, Y, and Z coordinates), comprising three degrees of freedom (3DOF). Further, the one or more sensors may track the virtual reality device's current pitch, roll, and yaw, providing an additional three degrees of freedom (3DOF), for a combined six degrees of freedom (6DOF).” Banerjee, ¶0041, “Asynchronous space warp (ASW) may overcome the limitations of ATW by additionally extrapolating segments with motion in the eye-buffer to an updated location based on motion vectors.” ¶0042-0043.)
As to claim 7, claim 1 is incorporated and the combination of Ambrus and Banerjee teaches the at least one server is configured to:
generate an acceleration structure based on at least a depth map corresponding to the second image (Ambrus, ¶0059, “the remote computer may render a two-dimensional RGB virtual image and send this virtual image to the virtual reality device along with an associated depth map.” “Adjusting the two-dimensional virtual image to include information from the depth map may be done through any suitable technique including, for example, rendering the image on a tessellated plane as a heightmap, or building a voxel representation of the virtual environment.” “Further, virtual images may be rendered and/or modified by the virtual reality device via ray tracing, constructed as a virtual mesh, or via virtually any other suitable techniques. Further, the virtual reality device may locally render a depth map, and use this locally rendered depth map to occlude portions of a received virtual image, thereby reducing the latency of any occlusion operations.” Banerjee, ¶0072, “the depth map can be used to prioritize foreground objects” ¶0061, “3D motion vectors can be extrapolated in world space to get 3D world point” ¶0057, “since full 3D geometry is available, it can be fairly easy to re-project grid vertices to the predicted display pose.”); and
send the acceleration structure to the at least one client device (Banerjee, ¶0065, “motion vectors or warp vectors sent to client can be directly used for ASW or warping the triangles” ¶0067.),
wherein the at least one client device is configured to utilize the acceleration structure with the second reprojection algorithm (Banerjee, ¶0065, “if the warp vectors are sent as is to the client, they can cause z-fighting artifacts.” ”the re-projection to pose C3 can provide the depth of each grid point in the rendered image at time T relative to the camera origin at C3.” “in a scene with foreground object moving towards the right and a background object moving towards the left, the extrapolated motion vectors or warp vectors can be indicated.”).
As to claim 8, claim 1 is incorporated and the combination of Ambrus and Banerjee teaches the at least one server is configured to:
estimate the future time instant as a time instant at which the third image is expected to be displayed at the at least one client device, based on at least one of: a time period elapsed between display of consecutive images at the at least one client device, time at which a previous third image was displayed at the at least one client device (Ambrus, ¶0017, “At 108, a pose prediction machine of virtual reality device 100 predicts a future pose of the virtual reality device at a future time. The future time may be any suitable time in the future, and may be established according to one or more criteria, as described in further detail below. In particular, the future time may be separated from the current time by a buffer period, and the size of the buffer period may depend upon one or more factors. The future pose is the pose prediction machine's prediction of what the pose of virtual reality device 100 will be at or near the future time, according to the device's current pose, movement, and/or other factors, as will be explained below.” ¶0030, “the pose prediction machine may need to predict the future pose for a future time which is relatively far in the future, in order to account for the time it will take before a requested virtual image has been remotely rendered and received.”); and
refine the future time instant prior to estimating the second predicted pose, based on a change in the time at which the previous third image was displayed (Ambrus, ¶0030, “A high communications latency may indicate relatively slow communication between the virtual reality device and the remote computer over the computer network. As such, the pose prediction machine may need to predict the future pose for a future time which is relatively far in the future, in order to account for the time it will take before a requested virtual image has been remotely rendered and received. However, when the communications latency is low, the pose prediction machine may be able to predict the future pose for a future time which is relatively closer to the current time, thereby increasing the accuracy of the prediction. Further, the current framerate for display of virtual images may be adjusted based on communications latency, and the communications latency may be taken into account when establishing a resolution of virtual images. For example, in cases of high communications latency, framerate and virtual image resolution may be dynamically reduced, in order to minimize network congestion related latency/delays.” ¶0099.).
As to claim 9, claim 1 is incorporated and the combination of Ambrus and Banerjee teaches the at least one client device is configured to refine the future time instant prior to estimating the third predicted pose, based on a time period elapsed between display of consecutive images at the at least one client device, actual time at which a previous third image was displayed at the at least one client device (Ambrus, ¶0017, “At 108, a pose prediction machine of virtual reality device 100 predicts a future pose of the virtual reality device at a future time. The future time may be any suitable time in the future, and may be established according to one or more criteria, as described in further detail below. In particular, the future time may be separated from the current time by a buffer period, and the size of the buffer period may depend upon one or more factors. The future pose is the pose prediction machine's prediction of what the pose of virtual reality device 100 will be at or near the future time, according to the device's current pose, movement, and/or other factors, as will be explained below.” ¶0030, “A high communications latency may indicate relatively slow communication between the virtual reality device and the remote computer over the computer network. As such, the pose prediction machine may need to predict the future pose for a future time which is relatively far in the future, in order to account for the time it will take before a requested virtual image has been remotely rendered and received. However, when the communications latency is low, the pose prediction machine may be able to predict the future pose for a future time which is relatively closer to the current time, thereby increasing the accuracy of the prediction. Further, the current framerate for display of virtual images may be adjusted based on communications latency, and the communications latency may be taken into account when establishing a resolution of virtual images. For example, in cases of high communications latency, framerate and virtual image resolution may be dynamically reduced, in order to minimize network congestion related latency/delays.”).
As to claim 10, the combination of Ambrus and Banerjee teaches a method comprising:
receiving, by at least one server from at least one client device, first pose information indicative of at least a pose of the at least one client device over a first time period;
estimating, at the at least one server, a first predicted pose corresponding to a future time instant, based on the first pose information;
generating, at the at least one server, a first image according to the first predicted pose;
receiving, at the at least one server from the at least one client device, second pose information indicative of at least the pose of the at least one client device over a second time period that ends after the first time period;
estimating, at the at least one server, a second predicted pose corresponding to the future time instant, based on the second pose information;
generating, at the at least one server, a second image by reprojecting the first image from the first predicted pose to the second predicted pose using a first reprojection algorithm;
sending the second image from the at least one server to the at least one client device;
collecting, at the at least one client device, third pose information indicative of at least the pose of the at least one client device over a third time period that ends after the second time period;
estimating, at the at least one client device, a third predicted pose corresponding to the future time instant, based on the third pose information;
generating, at the at least one client device, a third image by reprojecting the second image from the second predicted pose to the third predicted pose using a second reprojection algorithm; and
displaying the third image at the at least one client device (See claim 1 for detailed analysis.).
As to claim 11, claim 10 is incorporated and the combination of Ambrus and Banerjee teaches generating, at the at least one server, a motion vector map corresponding to the second image, based on previously-generated second images, using at least one optical flow algorithm, wherein the motion vector map indicates motion vectors per pixel or per group of pixels;
sending the motion vector map from the at least one server to the at least one client device; and
utilizing, at the at least one client device, the motion vector map with the second reprojection algorithm, to perform a nine degrees-of-freedom (9DOF) reprojection (See claim 4 for detailed analysis.).
As to claim 13, claim 10 is incorporated and the combination of Ambrus and Banerjee teaches generating, by the at least one server, an acceleration structure based on at least a depth map corresponding to the second image;
sending the acceleration structure from the at least one server to the at least one client device; and
utilizing, at the at least one client device, the acceleration structure with the second reprojection algorithm (See claim 7 for detailed analysis.).
As to claim 14, claim 10 is incorporated and the combination of Ambrus and Banerjee teaches estimating, at the at least one server, the future time instant as a time instant at which the third image is expected to be displayed at the at least one client device, based on at least one of: a time period elapsed between display of consecutive images at the at least one client device, time at which a previous third image was displayed at the at least one client device; and
refining, at the at least one server, the future time instant prior to estimating the second predicted pose, based on a change in the time at which the previous third image was displayed (See claim 8 for detailed analysis.).
As to claim 15, claim 10 is incorporated and the combination of Ambrus and Banerjee teaches refining, at the at least one client device, the future time instant prior to estimating the third predicted pose, based on at least one of: a time period elapsed between display of consecutive images at the at least one client device, actual time at which a previous third image was displayed at the at least one client device (See claim 9 for detailed analysis.).
Claims 5, 12 are rejected under 35 U.S.C. 103 as being unpatentable over Ambrus et al. (US Pub 2017/0115488 A1) in view of Banerjee et al. (US Pub 2020/0104975 A1) and Policarpo, Fabio, and Manuel M. Oliveira. ("Relaxed cone stepping for relief mapping." GPU gems 3.3 (2007): 409-428.).
As to claim 5, claim 1 is incorporated and the combination of Ambrus and Banerjee does not disclose the at least one server is configured to:
generate a cone angle map based on a depth map corresponding to the second image, wherein the cone angle map indicates cone angles per texel or per group of texels of the depth map, wherein a given cone angle for a given texel or a given group of texels indicates an angle of an imaginary cone whose apex is at the given texel or the given group of texels and within which a given viewing ray can intersect with at most one surface during ray marching; and send the cone angle map to the at least one client device, wherein the at least one client device is configured to utilize the cone angle map with the second reprojection algorithm, to perform ray marching for any of: a six degrees-of-freedom (6DOF) reprojection, a nine degrees-of-freedom (9DOF) reprojection.
However, applicant suggests that “The ray marching is well-known in the art. One such way of generating the cone angle map and utilising it for ray marching is well described, for example, in “Relaxed Cone Stepping for Relief Mapping” by F. Policarpo and Manuel M. Oliveira, published in GPU Gems 3, pp. 409-428, 2007”.
Policarpo teaches generate a cone angle map based on a depth map corresponding to the second image, wherein the cone angle map indicates cone angles per texel or per group of texels of the depth map, wherein a given cone angle for a given texel or a given group of texels indicates an angle of an imaginary cone whose apex is at the given texel or the given group of texels and within which a given viewing ray can intersect with at most one surface during ray marching (Policarpo, Page 415, “A cone map associates a circular cone to each texel of the depth texture. The angle of each cone is the maximum angle that would not cause the cone to intersect the height field.” Page 416, “advance the ray by intersecting it with the cone stored at (a, b), thus obtaining point 2 at texture coordinates (c, d ). Next, intersect the ray with the cone stored at (c, d ), obtaining point 3, and so on.” Page 416, “As in CSM, our approach requires that we assign a cone to each texel of the depth map.”); and
send the cone angle map to the at least one client device (This is obvious in view of client-server side rendering in Ambrus and Banerjee.),
wherein the at least one client device is configured to utilize the cone angle map with the second reprojection algorithm, to perform ray marching for any of: a six degrees-of-freedom (6DOF) reprojection, a nine degrees-of-freedom (9DOF) reprojection (Page 413, “Relief rendering is performed entirely on the GPU and can be conceptually divided into three steps.” Page 421, 18.4.4, “Rendering with Relaxed Cone Maps” Fig.18-10, Page 426, “Oliveira and Brauwers (2007) have shown how to use a 2D texture approach to intersect rays against depth maps generated under perspective projection and how to use these results to render real-time refractions of distant environments through deforming objects.”).
Ambrus, Banerjee and Policarpo are considered to be analogous art because all pertain to graphics processing. It would have been obvious before the effective filing date of the claimed invention to have modified Ambrus with the features of “generate a cone angle map based on a depth map corresponding to the second image, wherein the cone angle map indicates cone angles per texel or per group of texels of the depth map, wherein a given cone angle for a given texel or a given group of texels indicates an angle of an imaginary cone whose apex is at the given texel or the given group of texels and within which a given viewing ray can intersect with at most one surface during ray marching; and send the cone angle map to the at least one client device, wherein the at least one client device is configured to utilize the cone angle map with the second reprojection algorithm, to perform ray marching for any of: a six degrees-of-freedom (6DOF) reprojection, a nine degrees-of-freedom (9DOF) reprojection.” as taught by Policarpo. The suggestion/motivation would have been in order to combines the strengths of both cone step mapping and binary search (Policarpo, Page 411.)
As to claim 12, claim 11 is incorporated and the combination of Ambrus, Banerjee and Policarpo teaches generating, at the at least one server, a cone angle map based on a depth map corresponding to the second image, wherein the cone angle map indicates cone angles per texel or per group of texels of the depth map, wherein a given cone angle for a given texel or a given group of texels indicates an angle of an imaginary cone whose apex is at the given texel or the given group of texels and within which a given viewing ray can intersect with at most one surface during ray marching;
sending the cone angle map from the at least one server to the at least one client device; and
utilizing, at the at least one client device, the cone angle map with the second reprojection algorithm, to perform ray marching for any of: a six degrees-of-freedom (6DOF) reprojection, a nine degrees-of-freedom (9DOF) reprojection (See claim 12 for detailed analysis.).
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 extension fee 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YU CHEN whose telephone number is (571)270-7951. The examiner can normally be reached on M-F 8-5 PST Mid-day flex.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Xiao Wu can be reached on 571-272-7761. 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.
/YU CHEN/
Primary Examiner, Art Unit 2613