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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/26/2024, 09/29/2025, 12/30/2025, 07/17/2026, 0723/2026, and 07/30/2026 were filed and are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement are being considered by the examiner.
Claim Objections
Claims 22 and 30 are objected to because of the following informalities: the claims recite: “determining whether the level of computational … comprises determining a level of detail of the element relative to to other elements”. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 36 is directed to non-statutory subject matter. The broadest reasonable interpretation of the claim in light of the specification concludes that the claim as a whole covers a transitory signal since the definition of “computer-readable medium” leaves open the possibility that the medium could be transitory. P. 4 Para. 4 discloses “The computer readable media may be transitory or non-transitory”.
The Examiner suggests amending to recite the computer-readable storage medium is non-transitory. Appropriate correction is required
Claims 37-39 are similarly rejected for their dependence on claim 36.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries 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, 23, 25-26, 28, 31, 33-34, 36, and 38-39 are rejected under 35 U.S.C. 103 as being unpatentable over Potetsianakis et al. (US 2024/0212294 A1, hereinafter Potetsianakis) in view of Cook (US 2014/0292803 A1, hereinafter Cook).
Regarding claims 1 and 28, Potetsianakis discloses
Claim 1: A computer-implemented method comprising:
Claim 28: A system comprising: one or more processors (Fig. 7, Para [0142]: “1002 Processor”), and one or more computer-readable media (Fig. 7, Para [0143]: “memory element”, Para [0269]: “The data processing system 1000 may include at least one processor 1002 coupled to memory elements 1004 through a system bus 1006. As such, the data processing system may store program code within memory elements 1004. Furthermore, processor 1002 may execute the program code accessed from memory elements 1004 via system bus 1006.”) that store instructions which, when executed by the one or more processors, cause the one or more processors to perform operations comprising:
obtaining content stream data (Para [0015]: “obtaining scene descriptor data, wherein the scene descriptor data may identify a set of 3D graphics objects representing at least part of the scene, wherein the scene descriptor data may be indicative of changes in a state of the scene over time”);
for each of multiple elements of the content stream data, determining whether a level of computational expense that a user electronic device requires to render the element of the content stream data is greater than or less than a threshold level (Para [0047]: “The decision to have a part of the scene rendered remotely, and the decision which part is to be rendered remotely, may be taken by the rendering device based on various information, such as a complexity of a 3D graphics object, a computational load of the rendering device, etc.”, Para [0052]: “For example, if a particular 3D graphics object is positioned, oriented, and/or assumes a particular pose at the requested time instance, the remote rendering system may render the 3D graphics object accordingly.”, Para [0075] - [0082]: “In an embodiment, the determining of the first part of the scene to be rendered locally and the second part of the scene to be rendered remotely may comprise determining whether a 3D graphical object is to be rendered locally or remotely based on at least one of: a latency, bandwidth or reliability, of a network between the rendering device and the remote rendering system; a latency, bandwidth or reliability, of a network between the rendering device and a content server, which content server is configured to host 3D graphics data defining the set of 3D graphics objects of the scene; a computational load of the rendering device; a computational load of the remote rendering system; a battery level of the rendering device; a complexity of the 3D graphical object; and a scene distance between a viewpoint in the scene from which the scene is rendered by the rendering device and the 3D graphical object in the scene.”, Para [0208]: “The decision for local rendering and remote rendering by the rendering server may additionally or alternatively be made depending on the position of the client within the scene. Such position-dependent adaptation may be advantageous as it may be resource intensive for the client to render the complete scene. By only rendering objects that are nearby, the client can save processing resources, such as computational resources or battery power, etc.”, Para [0211] - [0214]: “3. The client may determine its current position (Al) a. Based on the position in the scene, the client may determine which objects lie within its field of view and within a particular radius. b. At position Al, this may result in zero objects being identified, meaning that all other visible objects (e.g., outside of the particular radius) may be rendered remotely by the rendering server. c. The client may therefore fetch a video stream comprising a prerendered version of these objects from the rendering server.”, Para [0235]: “Additionally to the battery level, the client may take the complexity of the rendered objects into account since the rendering of highly complex objects may consume more power. For example, highly complex objects may be preferably remotely rendered, or if the scene contains on average more complex objects, the client may switch to remote rendering earlier.”);
encoding any of the multiple elements in which the level of computational expense is greater than the threshold level in a first portion of the content stream data (Para [0046]: “The scene descriptor data may be made available to a rendering device and a remote rendering system. The rendering device may represent a 'local' rendering device, in that it may be used by an end-user and/or comprise or be connected to a display on which the rendered scene is displayed. In particular, the rendering device may display the rendered scene as augmentation of a video object or of an external environment.”, Para [0215] – [0216]: “4. The client may move to the A2 position. a. The client may determine that object 1 lies within its field of view and within the particular radius and may therefore locally render object 1 and combine the locally rendered object 1 with the prerendered version of the remaining visible objects from the rendering server.”);
rendering any of the multiple elements in which the level of computational expense is less than the threshold level in a second portion of the content stream data (Para [0049]: “In response, the remote rendering system may render the part of the scene using known rendering techniques, such as rasterization or raytracing, and using its CPU(s) and/or GPU(s), to obtain a rendered version of the part of the scene. Such a rendered version may take various forms, such as an image or a video, which may be represented in 2D, in volumetric 3D, in stereoscopic 3D, as a point-cloud, etc., and which image or video may be transmitted in an encoded, and optionally compressed form, to the rendering device via the network.”, Para [0050]: “The transmitted rendered scene data may also be referred to as 'prerendered' scene data since it, from the perspective of the rendering device, may represent a prerendered version of the part of the scene, meaning that it may not be needed for the rendering device itself to perform the respective rendering step(s).”, Para [0215] – [0216]: “4. The client may move to the A2 position. a. The client may determine that object 1 lies within its field of view and within the particular radius and may therefore locally render object 1 and combine the locally rendered object 1 with the prerendered version of the remaining visible objects from the rendering server.”).
However, Potetsianakis does not explicitly disclose
transmitting, to the user electronic device, the content stream data including the first portion and the second portion.
Cook teaches
transmitting, to the user electronic device, the content stream data including the first portion and the second portion (Para [0056]: “FIG. 5B illustrates a flowchart of a method 550 for generating video data streamed to a client computer 220, in accordance with one embodiment. The method 550 begins with steps 102 and 104, described above in conjunction with FIG. 1. At step 552, the server computer 210 renders a second subset of graphic objects to generate image data for a current frame 510(N) of video. At step 554, the server computer 210 generates a compressed frame of video data based on one or more previously generated frames of video data (e.g., 510(N-1), 510 (N-2), etc.).”, Para [0057]: “FIG. 6A illustrates at least a portion of a client computer 220 that generates images for display by combining compressed video data 530 generated by a server computer 210 with additional image data 540 generated by the client computer 220, in accordance with one embodiment. As shown in FIG. 6A, the client computer 220 receives the compressed video data 530 from the server computer 210 via the NIC 225. The GPU 224 (or CPU 222) is configured to decode the compressed video data 530 to generate the frames 510 of video data stored in the memory 223. In addition, the client computer 220 receives the first subset of graphic objects 521 from the server computer 210. The data representing the first subset of graphic objects 521 may be sent at the beginning of a session established between the client computer 220 and the server computer 210.”, Para [0059]: “The client computer 220, via GPU 224, is configured to render the graphics data for the first subset of graphic objects 521 to generate additional image data 540 that represents the first subset of graphic objects 521. The first subset of graphic objects 521 may be transformed based on one or more commands embedded within the compressed video data 530 received from the server computer 210. Then, the additional image data 540 is blended with a corresponding frame 510 of video data to generate an image for display on the display device 250. The image is transmitted to the display device 250 via a video interface and displayed for a user.”).
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 Potetsianakis with transmitting rendered data and non-rendered data to client device of Cook, which is in the same field of endeavor of server-client communication and rendering of video data, to effectively reduce the latency of input on user device and the bandwidth required for rendering frames of video.
Regarding claims 23, 31, and 36, Potetsianakis discloses
Claim 23: A computer-implemented method comprising:
Claim 31: A system comprising: one or more processors (Fig. 7, Para [0142]: “1002 Processor”), and one or more computer-readable media (Fig. 7, Para [0143]: “memory element”, Para [0269]: “The data processing system 1000 may include at least one processor 1002 coupled to memory elements 1004 through a system bus 1006. As such, the data processing system may store program code within memory elements 1004. Furthermore, processor 1002 may execute the program code accessed from memory elements 1004 via system bus 1006.”) that store instructions which, when executed by the one or more processors, cause the one or more processors to perform operations comprising:
Claim 36: One or more computer-readable media that store instructions which, when executed by the one or more processors, cause the one or more processors to perform operations comprising:
obtaining content stream data that includes multiple 3D elements that exist within a 3D scene (Para [0015]: “obtaining scene descriptor data, wherein the scene descriptor data may identify a set of 3D graphics objects representing at least part of the scene, wherein the scene descriptor data may be indicative of changes in a state of the scene over time”);
for each of the multiple 3D elements of the content stream data, determining whether a distance between a virtual camera and the 3D element is greater than or less than a threshold distance (Para [0047]: “The decision to have a part of the scene rendered remotely, and the decision which part is to be rendered remotely, may be taken by the rendering device based on various information, such as a complexity of a 3D graphics object, a computational load of the rendering device, etc.”, Para [0052]: “For example, if a particular 3D graphics object is positioned, oriented, and/or assumes a particular pose at the requested time instance, the remote rendering system may render the 3D graphics object accordingly.”, Para [0075] - [0082]: “In an embodiment, the determining of the first part of the scene to be rendered locally and the second part of the scene to be rendered remotely may comprise determining whether a 3D graphical object is to be rendered locally or remotely based on at least one of: a latency, bandwidth or reliability, of a network between the rendering device and the remote rendering system; a latency, bandwidth or reliability, of a network between the rendering device and a content server, which content server is configured to host 3D graphics data defining the set of 3D graphics objects of the scene; a computational load of the rendering device; a computational load of the remote rendering system; a battery level of the rendering device; a complexity of the 3D graphical object; and a scene distance between a viewpoint in the scene from which the scene is rendered by the rendering device and the 3D graphical object in the scene.”, Para [0173]: “The XR client's request may contain information on the rendering context, for example by indicating a virtual camera position, head pose etc., and possibly environmental information captured by sensors located on the client side, such as an ambient light sensor capturing light data, a depth sensor capturing depth data, or an outward facing camera recording an image or video. The rendering server may, on the basis of the received request and associated information, render the requested part of the scene. After rendering, the resulting prerendered scene data may be compressed and sent to the XR client, possibly alongside accompanying information such as synchronization information, transformation matrices, codec properties etc., which accompanying information may be transmitted to the XR client in the form of metadata.”, Para [0208]: “The decision for local rendering and remote rendering by the rendering server may additionally or alternatively be made depending on the position of the client within the scene. Such position-dependent adaptation may be advantageous as it may be resource intensive for the client to render the complete scene. By only rendering objects that are nearby, the client can save processing resources, such as computational resources or battery power, etc.”, Para [0211] - [0214]: “3. The client may determine its current position (Al) a. Based on the position in the scene, the client may determine which objects lie within its field of view and within a particular radius. b. At position Al, this may result in zero objects being identified, meaning that all other visible objects (e.g., outside of the particular radius) may be rendered remotely by the rendering server. c. The client may therefore fetch a video stream comprising a prerendered version of these objects from the rendering server.”, Para [0235]: “Additionally to the battery level, the client may take the complexity of the rendered objects into account since the rendering of highly complex objects may consume more power. For example, highly complex objects may be preferably remotely rendered, or if the scene contains on average more complex objects, the client may switch to remote rendering earlier.”, Para [0238]: “Conceptually, the generation of the video-based representation by the rendering server may resemble a recording by a virtual camera in the scene. The resulting video frames may be placed by the client in the 3D environment representing the scene at the indicated position. Such placement may represent a virtual screen in the 3D environment on which the output of the virtual camera may be projected.”, Para [0245]: “For example, depending on the distance from the viewpoint rendered by the client to one or more objects in the scene, it may be desirable to either locally render objects, e.g., for nearby objects, or receive a video stream containing prerendered versions of objects, e.g., for far away objects.”);
encoding any of the multiple 3D elements in which the distance between the virtual camera and the 3D element is less than the threshold distance in a first portion of the content stream data (Para [0046]: “The scene descriptor data may be made available to a rendering device and a remote rendering system. The rendering device may represent a 'local' rendering device, in that it may be used by an end-user and/or comprise or be connected to a display on which the rendered scene is displayed. In particular, the rendering device may display the rendered scene as augmentation of a video object or of an external environment.”, Para [0215] – [0216]: “4. The client may move to the A2 position. a. The client may determine that object 1 lies within its field of view and within the particular radius and may therefore locally render object 1 and combine the locally rendered object 1 with the prerendered version of the remaining visible objects from the rendering server.”);
rendering any of the multiple 3D elements in which the distance between the virtual camera and the 3D element is greater than the threshold distance in a second portion of the content stream data (Para [0049]: “In response, the remote rendering system may render the part of the scene using known rendering techniques, such as rasterization or raytracing, and using its CPU(s) and/or GPU(s), to obtain a rendered version of the part of the scene. Such a rendered version may take various forms, such as an image or a video, which may be represented in 2D, in volumetric 3D, in stereoscopic 3D, as a point-cloud, etc., and which image or video may be transmitted in an encoded, and optionally compressed form, to the rendering device via the network.”, Para [0050]: “The transmitted rendered scene data may also be referred to as 'prerendered' scene data since it, from the perspective of the rendering device, may represent a prerendered version of the part of the scene, meaning that it may not be needed for the rendering device itself to perform the respective rendering step(s).”, Para [0215] – [0216]: “4. The client may move to the A2 position. a. The client may determine that object 1 lies within its field of view and within the particular radius and may therefore locally render object 1 and combine the locally rendered object 1 with the prerendered version of the remaining visible objects from the rendering server.”).
However, Potetsianakis does not explicitly disclose
transmitting, to the user electronic device, the content stream data including the first portion and the second portion.
Cook teaches
transmitting, to the user electronic device, the content stream data including the first portion and the second portion (Para [0056]: “FIG. 5B illustrates a flowchart of a method 550 for generating video data streamed to a client computer 220, in accordance with one embodiment. The method 550 begins with steps 102 and 104, described above in conjunction with FIG. 1. At step 552, the server computer 210 renders a second subset of graphic objects to generate image data for a current frame 510(N) of video. At step 554, the server computer 210 generates a compressed frame of video data based on one or more previously generated frames of video data (e.g., 510(N-1), 510 (N-2), etc.).”, Para [0057]: “FIG. 6A illustrates at least a portion of a client computer 220 that generates images for display by combining compressed video data 530 generated by a server computer 210 with additional image data 540 generated by the client computer 220, in accordance with one embodiment. As shown in FIG. 6A, the client computer 220 receives the compressed video data 530 from the server computer 210 via the NIC 225. The GPU 224 (or CPU 222) is configured to decode the compressed video data 530 to generate the frames 510 of video data stored in the memory 223. In addition, the client computer 220 receives the first subset of graphic objects 521 from the server computer 210. The data representing the first subset of graphic objects 521 may be sent at the beginning of a session established between the client computer 220 and the server computer 210.”, Para [0059]: “The client computer 220, via GPU 224, is configured to render the graphics data for the first subset of graphic objects 521 to generate additional image data 540 that represents the first subset of graphic objects 521. The first subset of graphic objects 521 may be transformed based on one or more commands embedded within the compressed video data 530 received from the server computer 210. Then, the additional image data 540 is blended with a corresponding frame 510 of video data to generate an image for display on the display device 250. The image is transmitted to the display device 250 via a video interface and displayed for a user.”).
Regarding claims 25, 33, and 38, dependent upon claims 23, 31, and 36 respectively, Potetsianakis in view of Cook and Bosse teaches everything regarding claims 23, 41, and 36.
Potetsianakis further discloses
determining a viewpoint of the virtual camera (Para [0161]: “In the request, or accompanying the request, the client may include information which may be relevant for the rendering server's rendering of part of the scene, such as information defining a user's viewpoint in the scene, e.g., in form of a viewing position and/or orientation.”, Para [0173]: “The XR client's request may contain information on the rendering context, for example by indicating a virtual camera position, head pose etc., and possibly environmental information captured by sensors located on the client side, such as an ambient light sensor capturing light data, a depth sensor capturing depth data, or an outward facing camera recording an image or video. The rendering server may, on the basis of the received request and associated information, render the requested part of the scene.”),
wherein the multiple 3D elements include 3D elements that are within the viewpoint of the virtual camera, and exclude other elements that are outside of the viewpoint of the virtual camera (Para [0159]: “In some examples, the client may download all 3D assets of the scene, while in other examples, the client may down load only part of all 3D assets, e.g., only those 3D assets which are visible from a user's viewpoint in the scene.”, Para [0216]: “a. The client may determine that object 1 lies within its field of view and within the particular radius and may therefore locally render object 1 and combine the locally rendered object 1 with the prerendered version of the remaining visible objects from the rendering server.”, Para [0238]: “Conceptually, the generation of the video-based representation by the rendering server may resemble a recording by a virtual camera in the scene. The resulting video frames may be placed by the client in the 3D environment representing the scene at the indicated position. Such placement may represent a virtual screen in the 3D environment on which the output of the virtual camera may be projected.”).
Regarding claims 26, 34, and 39, dependent upon claims 23, 31, and 36 respectively, Potetsianakis in view of Cook and Bosse teaches everything regarding claims 23, 41, and 36.
Potetsianakis further discloses
the virtual camera is positioned within the 3D scene at a location that is associated with a user (Para [0173]: “The XR client's request may contain information on the rendering context, for example by indicating a virtual camera position, head pose etc., and possibly environmental information captured by sensors located on the client side, such as an ambient light sensor capturing light data, a depth sensor capturing depth data, or an outward facing camera recording an image or video. The rendering server may, on the basis of the received request and associated information, render the requested part of the scene.”, Para [0238]: “Conceptually, the generation of the video-based representation by the rendering server may resemble a recording by a virtual camera in the scene. The resulting video frames may be placed by the client in the 3D environment representing the scene at the indicated position. Such placement may represent a virtual screen in the 3D environment on which the output of the virtual camera may be projected.”).
Claims 24, 32, and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Potetsianakis et al. (US 2024/0212294 A1, hereinafter Potetsianakis) in view of Cook (US 2014/0292803 A1, hereinafter Cook), Pasman et al. (Comparing Simplification and Image-Based Techniques for 3D Client-Server Rendering Systems, hereinafter Pasman), and Davis (Dynamic 2D Imposters: A Simple, Efficient DirectX 9 Implementation, hereinafter Davis)
Regarding claims 24, 32, and 37, dependent upon claims 23, 31, and 36 respectively, Potetsianakis in view of Cook teaches everything regarding claims 23, 41, and 36.
However, Potetsianakis in view of Cook does not explicitly teach
wherein the 3D elements in which the distance between the virtual camera and the 3D element is greater than the threshold distance are rendered as two- dimensional (2D) elements.
Pasman teaches
wherein the 3D elements in which the distance between the virtual camera and the 3D element is greater than the threshold distance are rendered as two-dimensional (2D) elements (Fig. 1, Abstract: “An example result is that, in typical viewing and rendering conditions and for objects with a radius in the order of one meter, imposter techniques can be used at viewing distances above 15 meters.”; Parsman only renders far away object as “imposters”, which does not have to be 2D version of the 3d object).
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 Potetsianakis in view of Cook with using imposter technique when an object is far away from field of view of Pasman, which is in the same field of endeavor of rendering objects, to effectively reduce the bandwidth and capacity need for a rendering engine and network.
However, Potetsianakis in view of Cook and Pasman does not explicitly teach
wherein the 3D elements in which the distance between the virtual camera and the 3D element is greater than the threshold distance are rendered as two-dimensional (2D) elements.
Davis teaches
wherein the 3D elements in which the distance between the virtual camera and the 3D element is greater than the threshold distance are rendered as two-dimensional (2D) elements (P. 3 Theory: “A 2D imposter is a simplification of a complex 3D object, implemented as a billboard that is textured with a rendered image of the 3D object. The purpose of using imposters is to reduce the time required to render a 3D scene.”, P. 5 Para. 1: “Once the imposter is cached it is used for multiple frames of rendering. Imposters are rendered into the final 3D scene using alpha testing or alpha blending and are placed at the position of the 3D object they are replacing. The key to imposters bringing a performance gain is to reuse cached imposters over as many frames as possible”).
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 Potetsianakis in view of Cook and Pasman with 2D imposter rendering of Davis, which is in the same field of endeavor of rendering objects, to effectively increasing the performance of rendering engine.
Claims 27 and 35 are rejected under 35 U.S.C. 103 as being unpatentable over Potetsianakis et al. (US 2024/0212294 A1, hereinafter Potetsianakis) in view of Cook (US 2014/0292803 A1, hereinafter Cook) and Pasman et al. (Comparing Simplification and Image-Based Techniques for 3D Client-Server Rendering Systems, hereinafter Pasman).
Regarding claims 27 and 35, dependent upon claims 23 and 31 respectively, Potetsianakis in view of Cook and Bosse teaches everything regarding claims 23, 41, and 36.
However, Potetsianakis in view of Cook does not explicitly teach
wherein the 3D elements in which the distance between the virtual camera and the 3D element is greater than the threshold distance are rendered with a reduced level of detail.
Pasman teaches
wherein the 3D elements in which the distance between the virtual camera and the 3D element is greater than the threshold distance are rendered with a reduced level of detail (Fig. 1, Abstract: “An example result is that, in typical viewing and rendering conditions and for objects with a radius in the order of one meter, imposter techniques can be used at viewing distances above 15 meters.”; Parsman only renders far away object as “imposters”, which does not have to be 2D version of the 3d object).
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 Potetsianakis in view of Cook with using imposter technique when an object is far away from field of view of Pasman, which is in the same field of endeavor of rendering objects, to effectively reduce the bandwidth and capacity need for a rendering engine and network.
Allowable Subject Matter
Claims 21-22 and 29-30 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Relevant Prior Art Directed to State of Art
Chen (US 2017 /0287097 A1, hereinafter Chen) is prior art not applied in the rejection(s) above. Chen discloses a server partitions a model representative of a scene into a first portion and a second portion based on proximities of objects within the scene to a client device, renders a first portion of an image representative of the scene based on the first portion of the model, and transmits information representative of the second portion of the model and the first portion of the image over a wireless or wired network. The client device receives information representative of the second portion of the model and the first portion of the image. The client device renders the second portion of the image based on the second portion of the model and combines the first and second portions of the image.
BOSSE et al. (DOCNUM, hereinafter Bosse) is prior art not applied in the rejection(s) above. Bosse discloses a concept for transmitting information from a client to a server is described, the client being for streaming visual content from the server and for integrating the visual content into a 3D scene of a user application, and the client being for obtaining a rendered view of the 3D scene.
Wang et al. (US 2023/0224512 A1, hereinafter Wang) is prior art not applied in the rejection(s) above. Wang discloses methods, apparatus, and computer readable media configured to provide video data for immersive media implemented by a server in communication with a client device.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA CHEN whose telephone number is (703)756-5394. The examiner can normally be reached M-Th: 9:30 am - 4:30pm ET F: 9:30 am - 2:30pm ET.
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, STEPHEN R KOZIOL can be reached at (408)918-7630. 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.
/J. C./ Examiner, Art Unit 2665
/Stephen R Koziol/ Supervisory Patent Examiner, Art Unit 2665
Prosecution Insights