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
Priority
Acknowledgment is made of applicant’s priority claim, for U.S. Application No. 18/438,392, to a U.S. Provisional Application filed on 11/09/2023.
Status of Claims
Claims 1–20 are pending in the application. Claims 1-7, 9-11, 12-17, 19, 20 are rejected.
Claims 8, 18 are objected to.
Allowable Subject Matter
Claims 8, 18 are objected to as being dependent upon a rejected base claim(s), but would be allowable if rewritten in independent form including all of the limitations of the base claim(s) and any intervening claim(s).
Overview of Grounds of Rejection
Ground of Rejection
Claim(s)
Statute(s)
Reference(s)
Ground 1
1, 6, 7, 9, 11, 12, 13, 14, 15, 19, 20
§ 103
Jeschke et al. (NPL); Trapp et al. (NPL)
Ground 2
2
§ 103
Jeschke et al. (NPL); Trapp et al. (NPL); Richebourg et al. (US20140184606A1)
Ground 3
3, 4
§ 103
Jeschke et al. (NPL); Trapp et al. (NPL); Sprite Editor (NPL)
Ground 4
5
§ 103
Jeschke et al. (NPL); Trapp et al. (NPL); Sprite Editor (NPL); AutoPolygon (NPL)
Ground 5
10
§ 103
Jeschke et al. (NPL); Trapp et al. (NPL); OpenGL Sphere Mapping (NPL)
Ground 6
16, 17
§ 103
Jeschke et al. (NPL); Trapp et al. (NPL); AutoPolygon (NPL)
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.
(Please see the cited paragraphs, sections, pages, or surrounding text in the references for the paraphrased content.)
Ground of Rejection 1
Claims 1, 6, 7, 9, 11, 12, 13, 14, 15, 19, 20 are rejected under 35 U.S.C. § 103 as being unpatentable over Jeschke et al. (NPL) in view of Trapp et al. (NPL).
As per Claim 1, Jeschke et al. teach the following portion of Claim 1, which recites:
“A method, comprising:
obtaining a representation of a three-dimensional scene, the representation comprising a plurality of discrete layers of scene content that are spatially distributed across the three-dimensional scene;”
“layered impostors are calculated and optimized for all view cells in the scene, and … Each layer is arranged similar to a cubic environment map around the view cell.” — Jeschke et al., §3 Overview; Fig. 2 (layer arrangement).
The cited passage shows a scene representation with multiple (“plurality”) layers that are spatially distributed across the scene via view cells and layer arrangement around each view cell.
Jeschke et al. teach the following portion of Claim 1, which recites:
“generating, from the representation comprising the plurality of discrete layers and for a plurality of objects represented in the three-dimensional scene, one or more coverage meshes corresponding to the plurality of objects;”
“extract the opaque texels … by splitting the texture into a number of smaller textures (microtextures) that tightly cover the opaque regions … and creating corresponding rectangular impostor polygons.” — Jeschke et al., §5.3 Generation of impostor polygons.
“partition the impostor polygon into smaller polygons that are well filled.” — Jeschke et al., §3 Overview → Preprocessing (c)(ii).
The rectangular impostor polygons are coverage meshes that tightly cover visible (non-transparent) scene content within the layers—i.e., meshes that correspond to the scene content attributable to objects represented in the layered scene.
Jeschke et al. alone does not explicitly teach all the limitation(s) of the claim. However, when combined with Trapp et al. (NPL), they collectively teach all of the limitation(s).
Jeschke et al. and Trapp et al. (NPL) teach the following portion of Claim 1, which recites: “storing a mesh atlas, the mesh atlas comprising the one or more coverage meshes corresponding to the plurality of objects, in association with a two-dimensional image containing representations of the plurality of objects;”
“pack microtextures into larger macrotextures… **The final result is a low number of relatively well-filled macrotextures that can be sent directly to graphics hardware. For storing them on disk, they are compressed using PNG compression.” — Jeschke et al., §5.4 Microtexture packing.
“…splitting the texture into … microtextures that tightly cover the opaque regions … and creating corresponding rectangular impostor polygons.” — Jeschke et al., §5.3.
Jeschke stores the packed macrotextures (a two-dimensional image structure that consolidates many regions) and maintains the corresponding impostor polygons (the coverage meshes for those regions). The set of coverage meshes + their packed macrotextures together constitute the claimed “mesh atlas … in association with a two-dimensional image containing representations of the plurality of objects.” The text squarely shows (i) creation of coverage meshes (impostor polygons), (ii) packing into a shared 2D texture image (macrotextures), and (iii) storing the packed image(s) on disk.
Further, Trapp et al. teach the following.
“render-to-texture atlas (RTTA) … enables dynamic generation of occlusion-free, image-based representations for multiple scene objects … using a single … texture-atlas as render target for all scene objects … it computes the texture-atlas parameterization and packaging per rendering frame … based on the projected boundary of each object … Each object is transformed into its respective atlas region.” — Trapp et al., Abstract; §2 Render-To-Texture Atlas; Fig. 1; §2.1–§2.2.
“We present a concept for … generation of a texture atlas containing image-based representations of projected scene objects.” — Trapp et al., §2 (bullet 1).
Trapp stores, per frame, a texture atlas (‘two-dimensional image’) that contains representations of a plurality of objects and associates each object with a designated region. This meets “in association with a two-dimensional image containing representations of the plurality of objects.” (The atlas that organizes per-object regions is the claimed “mesh atlas … comprising [coverage] meshes” in association with the 2D image.)
Jeschke et al. teach the following portion of Claim 1, which recites:
“providing the two-dimensional image and the mesh atlas for rendering of the three-dimensional scene.”
“Prefetch the geometry and impostors … [and] Render the impostor polygons for the current view cell.” — Jeschke et al., §3 Overview → Runtime (steps 2–4).
At runtime, the system provides the packed textures (2D images) and draws the impostor polygons (coverage meshes) to render the scene—matching the claim’s provision of the two-dimensional image and mesh atlas for rendering. Jeschke et al. further teach the following portion of Claim 1, which recites: “from any of multiple viewpoints within the three-dimensional scene.”
“Partition the space of possible viewing positions into view cells.” — Jeschke et al., §3 Overview. “The runtime component is a simple 3D viewer where the user can freely navigate through the 3D model.” — Jeschke et al., §3 Overview. “The runtime component only has to: 1. Determine the current view cell of the observer. 2. Prefetch the geometry and impostors of adjacent view cells …” — Jeschke et al., §3 Overview. “The impostor layers need to be placed so that every layer ‘faithfully’ represents the geometry it replaces as long as the observer stays within the associated view cell.” — Jeschke et al., §4.2 Layer placement calculation. These passages show that Jeschke is not limited to a single fixed viewpoint. Rather, Jeschke partitions the possible viewing positions into multiple view cells, allows the user to freely navigate through the three-dimensional model, and provides impostor representations that remain faithful for viewpoints throughout the associated view cell while adjacent view cells are prefetched as the observer moves. Accordingly, Jeschke teaches rendering the three-dimensional scene from any of multiple viewpoints within the three-dimensional scene.
Before the effective filing date of the claimed invention, a POSITA seeking to further improve batching and GPU efficiency in a layered impostor system like Jeschke et al. would have been naturally motivated to incorporate Trapp et al. (NPL), which “present[s] … a texture atlas containing image-based representations of projected scene objects” with per-object parameterization and packaging per frame to reduce state changes and manage many objects coherently. Applying Trapp’s atlas parameterization to Jeschke’s already packed macrotextures + impostor polygons yields the predictable benefit of more efficient association of per-object content with atlas regions, improved GPU utilization, and cleaner runtime management—without changing the underlying rendering paradigm.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 6, Jeschke et al. teach the limitation(s) of Claim 6 that recites:
“The method of claim 1, wherein generating the one or more coverage meshes corresponding to the plurality of objects comprises: generating the two-dimensional image containing the representations of the plurality of objects; and generating the one or more coverage meshes corresponding to the plurality of objects based on the two-dimensional image.”
Limitation: “generating the two-dimensional image containing the representations of the plurality of objects”
“Render the geometry for each impostor layer into a texture using conventional graphics hardware.” — Jeschke et al., §3 Overview (Preprocessing 3(b)).
“Each impostor layer represents geometry within a certain depth range … objects in front … objects to the back …” — Jeschke et al., §4.1 Layer arrangement (layers cover scene geometry within the range, i.e., multiple objects per layer).
The paper renders scene geometry into a 2D texture for each layer; each layer represents geometry (objects) in a depth range, so the texture contains representations of a plurality of objects.
Limitation: “generating the one or more coverage meshes … based on the two-dimensional image”
“…partition the impostor polygon into smaller polygons that are well filled.” — Jeschke et al., §3 Overview (Preprocessing 3(c)(ii)).
“…extract the opaque texels of every layer by splitting the texture into … microtextures … that tightly cover the opaque regions … and creating corresponding rectangular impostor polygons.” — Jeschke et al., §5.3 Generation of impostor polygons.
After the image is rendered, coverage meshes (impostor polygons) are derived from that texture by extracting opaque regions and partitioning into polygons—i.e., generated based on the 2D image.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 7, Jeschke et al. alone does not explicitly teach all the limitation(s) of the claim. However, when combined with Trapp et al. (NPL), they collectively teach all of the limitation(s) of Claim 7 that recites:
“The method of claim 1, wherein generating the one or more coverage meshes corresponding to the plurality of objects comprises generating the one or more coverage meshes corresponding to the plurality of objects based on the representation of the three-dimensional scene, and wherein the method further comprises generating the two-dimensional image based on the one or more coverage meshes corresponding to the plurality of objects and based on the representation of the three-dimensional scene.”
Limitation: “…generating the one or more coverage meshes … based on the representation of the three-dimensional scene”
“Its parameterization is computed per-frame, based on the projected boundary volume of each object (red lines).” — Trapp et al. (NPL), Fig. 1 caption / Abstract.
“Prior to RTTA, the texture-atlas parameterization needs to be determined, i.e., the mapping of a 3D boundary representation (Bworld) into a 2D texture domain (Batlas) …” — Trapp et al. (NPL), §2.2.
Trapp computes, from the 3D scene representation (Bworld), the projected boundary and maps it into atlas regions—i.e., generates the coverage regions/meshes based on the 3D representation.
Limitation: “…and … generating the two-dimensional image based on the one or more coverage meshes … and based on the representation of the three-dimensional scene”
“Our concept mainly consists of two phases … the view-dependent computation of the texture-atlas parameterization and subsequently, the rendering of the scene geometry into the texture atlas.” — Trapp et al. (NPL), §2.
“During off-screen rendering it uses screen-space vertex displacement … to transform each object into its respective atlas region prior to rasterization.” — Trapp et al. (NPL), §2 / §2.3.
After establishing the coverage/atlas regions from the 3D representation, Trapp renders the scene geometry into the atlas (a 2D image) using the computed regions - i.e., the 2D image is generated based on those coverage regions and the underlying 3D scene representation.
Before the effective filing date of the claimed invention, a POSITA using Jeschke et al. (NPL) for layered scene representation would readily adopt Trapp et al. (NPL)’s geometry-first atlas parameterization and rendering to obtain predictable efficiency: compute coverage regions from 3D boundaries then render into a 2D atlas per frame, reducing state changes and aligning with standard GPU flows. The combination yields expected performance gains without changing core principles.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 9, Jeschke et al. teach the limitation(s) of Claim 9 that recites:
“The method of claim 1, wherein each of the plurality of discrete layers of scene content represent a respective depth in the three-dimensional scene, and wherein the three-dimensional scene is renderable from any of the multiple viewpoints using the three-dimensional representation of the scene.”
“Figure 2 shows how impostor layers are arranged … around a particular view cell. Note that each impostor layer represents geometry within a certain depth range to the front and to the back of the layer. The borders show where the transition between two layers takes place …” — Jeschke et al., §4.1 Layer arrangement, Fig. 2.
Jeschke clearly states that each layer corresponds to a depth range, i.e., a respective depth in the scene, matching Claim 9.
Jeschke further explains layer placement and corresponding depth ranges are calculated automatically, reinforcing the depth-by-layer design. — Jeschke et al., §4.1–§4.2.
Further, Jeschke et al. teach the additional limitation of Claim 9 that recites: “and wherein the three-dimensional scene is renderable from any of the multiple viewpoints using the three-dimensional representation of the scene.”
“Partition the space of possible viewing positions into view cells.” — Jeschke et al., §3 Overview. “The runtime component is a simple 3D viewer where the user can freely navigate through the 3D model.” — Jeschke et al., §3 Overview. “The runtime component only has to: 1. Determine the current view cell of the observer. 2. Prefetch the geometry and impostors of adjacent view cells … 4. Render the impostor polygons for the current view cell.” — Jeschke et al., §3 Overview → Runtime. “The impostor layers need to be placed so that every layer ‘faithfully’ represents the geometry it replaces as long as the observer stays within the associated view cell.” — Jeschke et al., §4.2 Layer placement calculation.
These passages show that Jeschke is not limited to a single fixed viewpoint. Rather, Jeschke partitions the possible viewing positions into multiple view cells, allows the user to freely navigate through the three-dimensional model, and renders the scene from viewpoints within those cells using the layered three-dimensional representation of the scene. Accordingly, Jeschke teaches that the three-dimensional scene is renderable from any of the multiple viewpoints using the three-dimensional representation of the scene.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 11, Jeschke et al. teach the limitation(s) of Claim 11 that recites:
“The method of claim 9, wherein each of the plurality of discrete layers comprises a planar layer.”
“Each layer is arranged similar to a cubic environment map around the view cell.” — Jeschke et al., §3 Overview.
“Figure 2 shows how impostor layers are arranged as impostor cubes around a particular view cell… When generating an impostor layer, each side of its impostor cube is rendered from the reference viewpoint…” — Jeschke et al., §4.1 Layer arrangement.
“consider points on a border cube, i.e., points on a plane parallel to the impostor.” — Jeschke et al., §4.2.
Jeschke’s impostor layers are organized as cubes around the view cell; the sides (faces) rendered per layer are planar. The paper further refers to a “plane parallel to the impostor,” confirming that an impostor layer is treated as a plane. Thus, each discrete layer comprises a planar layer.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 12, Jeschke et al. alone do not explicitly teach all the limitation(s) of the claim. However, when combined with Trapp et al. (NPL), they collectively teach all of the limitation(s) of Claim 12 that recites: “A method, comprising: obtaining, by an electronic device, a two-dimensional image containing a plurality of representations of a plurality of respective objects; obtaining a mesh atlas associated with the two-dimensional image, wherein the mesh atlas and the two-dimensional image are based on a representation of a three-dimensional scene and configured for use in rendering the three-dimensional scene from any of various viewpoints, the representation of the three-dimensional scene comprising a plurality of discrete layers of scene content that are spatially distributed across the three-dimensional scene; obtaining a viewpoint for viewing the three-dimensional scene; and rendering the three-dimensional scene from the viewpoint using the mesh atlas and the two-dimensional image.”
Limitation: “obtaining … a two-dimensional image containing a plurality of representations of a plurality of respective objects;” “render-to-texture atlas (RTTA): … enables dynamic generation of occlusion-free, image-based representations for multiple scene objects … using a single … texture-atlas as render target for all scene objects.” — Trapp et al., Abstract / §2, Fig. 1.
“Our concept mainly consists of two phases … the view-dependent parameterization … and subsequently, the rendering of the scene geometry into the texture atlas.” — Trapp et al., §2. Trapp’s atlas is a 2D image that contains representations of multiple respective objects (each mapped to a region), satisfying the step.
Limitation: “obtaining a mesh atlas associated with the two-dimensional image, wherein the mesh atlas and the two-dimensional image are based on a representation of a three-dimensional scene and configured for use in rendering the three-dimensional scene from any of various viewpoints, the representation … comprising a plurality of discrete layers of scene content that are spatially distributed across the three-dimensional scene;” “layered impostors are calculated … for all view cells … Each layer is arranged … around the view cell.” — Jeschke et al., §3 Overview.
“Render the geometry for each impostor layer into a texture … then … partition the impostor polygon into smaller polygons that are well filled, … combine the textures for the smaller polygons into larger textures for efficient graphics hardware treatment … compress those textures … for storage on disk.” — Jeschke et al., §3 Overview (steps).
“The final result is a low number of relatively well-filled macrotextures … For storing them on disk, they are compressed …” — Jeschke et al., §5.4 Microtexture packing.
“Partition the space of possible viewing positions into view cells.” — Jeschke et al., §3 Overview.
“The runtime component is a simple 3D viewer where the user can freely navigate through the 3D model.” — Jeschke et al., §3 Overview.
“The runtime component only has to: 1. Determine the current view cell of the observer. 2. Prefetch the geometry and impostors of adjacent view cells …” — Jeschke et al., §3 Overview → Runtime.
“The impostor layers need to be placed so that every layer ‘faithfully’ represents the geometry it replaces as long as the observer stays within the associated view cell.” — Jeschke et al., §4.2 Layer placement calculation. Jeschke’s layered representation (plural “layers” arranged around view cells) yields textures (2D images) and their associated impostor polygons (coverage meshes), which are packed into macrotextures and stored—i.e., a mesh+image association arising from a layered 3D scene representation that is spatially distributed via view cells. Further, Jeschke partitions the possible viewing positions into multiple view cells, allows the user to freely navigate through the three-dimensional model, prefetches adjacent view cells, and places impostor layers so that they faithfully represent the geometry within the associated view cell. Accordingly, the mesh atlas and the two-dimensional image based on that layered representation are configured for use in rendering the three-dimensional scene from any of various viewpoints.
Limitation: “obtaining a viewpoint for viewing the three-dimensional scene;” “The runtime component only has to: 1. Determine the current view cell of the observer.” — Jeschke et al., §3 Overview (Runtime). Determining the current view cell corresponds to obtaining the viewpoint for viewing the scene.
Limitation: “rendering the three-dimensional scene from the viewpoint using the mesh atlas and the two-dimensional image.” “Render the impostor polygons for the current view cell.” — Jeschke et al., §3 Overview (Runtime).
“The final result is … macrotextures that can be sent directly to graphics hardware.” — Jeschke et al., §5.4. At runtime, Jeschke renders the meshes (impostor polygons) using the packed textures (2D images) from the layered representation - i.e., rendering the scene from the viewpoint using the mesh atlas and the 2D image.
Before the effective filing date, a POSITA implementing Jeschke’s layered impostor pipeline (meshes + packed textures rendered from a viewpoint) would reasonably adopt Trapp’s view-dependent texture-atlas scheme to ensure the 2D image contains per-object representations in a single atlas, simplifying batching and reducing state changes, while Jeschke’s multi-view-cell viewer architecture supports rendering as the observer navigates among various viewpoints. This combination yields a predictable efficiency improvement that integrates cleanly with the layered-scene basis.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 13, Jeschke et al. alone does not explicitly teach all the limitation(s) of the claim. However, when combined with Trapp et al. (NPL), they collectively teach all of the limitation(s) of Claim 13 that recites:
“The method of claim 12, wherein the rendering comprises: (i) identifying, using the mesh atlas, a portion of the two-dimensional image corresponding to an object in the three-dimensional scene; and (ii) rendering a portion of the three-dimensional scene by applying the portion of the two-dimensional image to a location in the three-dimensional scene, the location defined by the mesh atlas.”
Limitation: “identifying, using the mesh atlas, a portion of the two-dimensional image corresponding to an object …”
“For each object, a record RID **= (Bworld, Bviewport, Batlas, l, T ) … Batlas ∈ TA the occupied area within the texture atlas. An affine 2D transformation matrix T describes the transformation of Bviewport into Batlas …” — Trapp et al. (NPL) §2.1 Preliminaries.
The record contains Batlas, i.e., the atlas region (portion of the 2D atlas image) corresponding to the object, enabling identification using the mesh atlas.
Limitation: “…rendering … by applying the portion of the two-dimensional image to a location in the three-dimensional scene, the location defined by the mesh atlas.”
“The final compositing is performed on per-object level … rendered 2D sprites for each object … The four corner points are set according to Batlas and are then transformed to Bviewport using the inverse transformation matrix T.” — Trapp et al. (NPL) §3.2 Compositing from Texture Atlases.
Rendering applies the identified atlas region (Batlas) to the object’s screen-space location derived from the scene/view (Bviewport, T) - i.e., applying the portion of the 2D image to a location defined via the mesh-atlas parameters.
The rationale and motivation to combine the references as set forth for claim 13 are incorporated herein by reference for the present claim.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 14, Jeschke et al. teach the limitation(s) of Claim 14 that recites:
“The method of claim 12, wherein rendering the three-dimensional scene comprising rendering, based on the mesh atlas, at least a subset of the plurality of respective objects in an order from a nearest one of the subset of the plurality of respective objects to a furthest one of the subset of the plurality of respective objects.”
“The runtime component only has to: … 3. Render the near geometry not represented by impostors. 4. Render the impostor polygons for the current view cell.” — Jeschke et al., §3 Overview (Runtime).
“Render the near geometry … [then] Render the impostor polygons” is a clear near-to-far rendering order (nearest content first, then farther layers).
In this system, the impostor polygons are the coverage meshes and their packed macrotextures are the 2D atlas images; rendering them is therefore “based on the mesh atlas.” (See preprocessing where impostor textures are partitioned into polygons and “combine[d] … into larger textures”).
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 15, Jeschke et al. alone does not explicitly teach all the limitation(s) of the claim. However, when combined with Trapp et al. (NPL), they collectively teach all of the limitation(s) of Claim 15 that recites:
“The method of claim 12, wherein the mesh atlas comprises vertex information for each of the plurality of respective objects.”
“For each object, a record RID … RID = (Bworld, Bviewport, Batlas, l, T) … Bviewport … the clipped on-screen area … and Batlas … the occupied area within the texture atlas. An affine 2D transformation matrix T describes the transformation of Bviewport into Batlas …” — Trapp et al. (NPL), §2.1 Preliminaries.
“The final compositing is performed on per-object level … by generating and rendering 2D sprites for each object … Given the viewport setting VP, the four corner points are set according to Batlas and are then transformed to Bviewport using the inverse transformation matrix T−1.” — Trapp et al. (NPL), §3.2 Compositing from Texture Atlases.
Trapp’s per-object RID associates each object with Batlas (its atlas region) and T (transform). In compositing, the “four corner points” (i.e., the quad’s vertex information) are set from Batlas and transformed with T/T⁻¹. Thus, within the mesh-atlas framework, each object has vertex data derived from its atlas parameters - i.e., “the mesh atlas comprises vertex information for each … object.”
Before the effective filing date, a POSITA implementing Jeschke’s impostor/mesh-atlas pipeline would naturally include per-object vertex data (the quad’s corner points) as part of the atlas metadata, as shown by Trapp. This yields the predictable result of direct, per-object placement and compositing using the atlas, without changing the core rendering approach.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 19, Jeschke et al. teach the limitation(s) of Claim 19 that recites: “The method of claim 12, wherein each of the plurality of discrete layers of scene content represent a respective depth in the three-dimensional scene, and wherein the method further comprises: obtaining another viewpoint for viewing the three-dimensional scene; and rendering the three-dimensional scene from the other viewpoint using the mesh atlas and the two-dimensional image.”
“Figure 2 shows how impostor layers are arranged … around a particular view cell. Note that each impostor layer represents geometry within a certain depth range to the front and to the back of the layer …” — Jeschke et al., §4.1 Layer arrangement, Fig. 2. Jeschke states that each layer corresponds to a depth range, i.e., a respective depth in the scene, matching the requirement. Further discussion confirms that layer placement and corresponding depth ranges are computed automatically.
Further, Jeschke et al. teach the additional limitation(s) of Claim 19 that recites: “and wherein the method further comprises: obtaining another viewpoint for viewing the three-dimensional scene; and rendering the three-dimensional scene from the other viewpoint using the mesh atlas and the two-dimensional image.”
“Partition the space of possible viewing positions into view cells.” — Jeschke et al., §3 Overview. “The runtime component is a simple 3D viewer where the user can freely navigate through the 3D model.” — Jeschke et al., §3 Overview. “The runtime component only has to: 1. Determine the current view cell of the observer. 2. Prefetch the geometry and impostors of adjacent view cells … 3. Render the near geometry not represented by impostors. 4. Render the impostor polygons for the current view cell.” — Jeschke et al., §3 Overview → Runtime. “The impostor layers need to be placed so that every layer ‘faithfully’ represents the geometry it replaces as long as the observer stays within the associated view cell.” — Jeschke et al., §4.2 Layer placement calculation.
These passages show that Jeschke is not limited to a single fixed viewpoint. Rather, Jeschke partitions the possible viewing positions into multiple view cells, allows the user to freely navigate through the three-dimensional model, and renders the scene as the observer moves to another viewpoint by determining the current view cell, prefetching adjacent view cells, and rendering the corresponding impostor polygons and textures. Accordingly, Jeschke teaches obtaining another viewpoint for viewing the three-dimensional scene and rendering the three-dimensional scene from the other viewpoint using the mesh atlas and the two-dimensional image.
Support for the added “another viewpoint” paragraph comes from Jeschke’s Section 3 Overview and Section 4.2 discussion of view cells, free navigation, adjacent-cell prefetching, and faithful representation within the associated view cell.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
Device Claim 20 does not include any additional limitations that would significantly distinguish it from claim 12. Therefore, it is likewise rejected under 35 U.S.C. § 103 in view of the same references and for the same reasons set forth above.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
Ground of Rejection 2
Claim 2 is rejected under 35 U.S.C. § 103 as being unpatentable over Jeschke et al. (NPL) in view of Trapp et al. (NPL), and further in view of Richebourg et al. (US20140184606A1).
As per Claim 2, Jeschke et al. and Trapp et al. alone does not explicitly teach all the limitation(s) of the claim. However, when combined with Richebourg et al., they collectively teach all of the limitation(s).
Jeschke et al. and Trapp et al. teach the following additional portion of Claim 2 that recites: “The method of claim 1, wherein the one or more coverage meshes comprise a plurality of coverage meshes, respectively, for the plurality of objects, and”
“render-to-texture atlas (RTTA) … enables dynamic generation of occlusion-free, image-based representations for multiple scene objects … using a single … texture-atlas as render target for all scene objects … based on the projected boundary of each object … Each object is transformed into its respective atlas region.” — Trapp et al., Abstract; §2 Render-To-Texture Atlas; Fig. 1; §2.1–§2.2.
“For each object, a record RID = (Bworld, Bviewport, Batlas, l, T) … Batlas ∈ TA the occupied area within the texture atlas …” — Trapp et al., §2.1 Preliminaries.
“…splitting the texture into … microtextures that tightly cover the opaque regions … and creating corresponding rectangular impostor polygons.” — Jeschke et al., §5.3.
These passages show that Trapp provides a plurality of per-object atlas regions / records, respectively, for a plurality of objects, and Jeschke provides the corresponding coverage meshes. Accordingly, the combined teachings show that the claimed one or more coverage meshes comprise a plurality of coverage meshes, respectively, for the plurality of objects.
Richebourg teaches the following portion of Claim 2 that recites:
“wherein storing the mesh atlas comprises storing the mesh atlas as metadata for the two-dimensional image containing the representations of the plurality of objects.”
“…generates a texture atlas … (typically as a single JPG or PNG, but in any desired format), along with a manifest file in XML format that records the texture coordinates and dimensions in the texture atlas.” — Richebourg et al., ¶[0061].
“…locates the atlas file, loads it into the GPU, looks up the texture in the atlas … then provides an object representing the sub-rectangle of the atlas which contains the original image data…” — Richebourg et al., ¶[0062].
Richebourg’s “manifest file … records … coordinates and dimensions” is metadata for the atlas image (the “two-dimensional image”) that stores how regions/meshes map into that image. Persisting this manifest together with the atlas is storing the mesh-atlas association as metadata for the 2D image, as recited.
Jeschke already provides the packed 2D macrotextures and impostor polygons (coverage meshes) that are stored/used for rendering (e.g., “pack microtextures into larger macrotextures … For storing them on disk”; “creating corresponding rectangular impostor polygons”). — Jeschke et al., §5.4; §5.3.
Before the effective filing date of the claimed invention, a POSITA using Jeschke’s layered impostors (coverage meshes + packed atlas images) would reasonably adopt Richebourg’s practice of writing an XML manifest that “records the texture coordinates and dimensions in the texture atlas” to serialize the mesh/region-to-image mapping, enabling deterministic loading/lookup. This combination predictably improves asset management and runtime efficiency without changing core operations.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
Ground of Rejection 3
Claims 3, 4 are rejected under 35 U.S.C. § 103 as being unpatentable over Jeschke et al. (NPL) in view of Trapp et al. (NPL), and further in view of Sprite Editor (NPL).
As per Claim 3, Jeschke et al. and Trapp et al. alone does not explicitly teach all the limitation(s) of the claim. However, when combined with Sprite Editor (NPL), they collectively teach all of the limitation(s).
Sprite Editor (NPL) teaches the limitation(s) of Claim 3 that recites:
“The method of claim 1, wherein at least one of the one or more coverage meshes comprises vertex information for a boundary of one of the plurality of objects.”
“Use the Sprite Editor’s Edit Outline option to edit the generated Mesh for a Sprite, effectively editing its outline.” — Sprite Editor (NPL), p.1–2.
“The Sprite Editor displays the outline and control points of the Sprite.” — Sprite Editor (NPL), p.2.
“Use the Outline Tolerance slider to increase and decrease the number of outline control points … A higher Outline Tolerance creates more outline control points … a lower Outline Tolerance creates a tighter Mesh.” — Sprite Editor (NPL), p.6.
The Sprite Editor shows that a per-object Mesh is defined by an outline with editable control points (i.e., vertices) on the boundary of the sprite (object). Thus at least one coverage mesh comprises vertex information for a boundary of an object.
Before the effective filing date of the claimed invention, a POSITA implementing Jeschke’s coverage polygons would reasonably adopt the mainstream practice shown in Sprite Editor (NPL) of representing mesh outlines with boundary vertices/control points to achieve tighter silhouette fitting and predictable rendering efficiency. The combination yields a predictable improvement (precise boundary-following meshes) without altering core operations.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 4, Jeschke et al. and Trapp et al. alone does not explicitly teach all the limitation(s) of the claim. However, when combined with Sprite Editor (NPL), they collectively teach all of the limitation(s).
Sprite Editor (NPL) teaches the limitation(s) of Claim 4 that recites:
“The method of claim 3, further comprising determining a number of vertices for the one of the plurality of objects by performing an optimization process based on candidate numbers of the vertices and a number of transparent pixels associated with the one of the plurality of objects.”
“Use the Sprite Editor’s Edit Outline option to edit the generated Mesh for a Sprite, effectively editing its outline.” — Sprite Editor (NPL), p.1–2.
“Outline Tolerance … increase and decrease the number of outline control points … A higher Outline Tolerance creates more outline control points, while a lower Outline Tolerance creates a tighter Mesh (a Mesh with a smaller border of transparent pixels between the Sprite and the Mesh edges).” — Sprite Editor (NPL), p.6.
“Transparent areas in a Sprite can negatively affect your project’s performance … [this tool] ensures there are fewer transparent areas in the shape.” — Sprite Editor (NPL), p.1.
The Outline Tolerance control lets the system consider candidate numbers of vertices (“number of outline control points”) and choose a setting that yields a “tighter Mesh … with a smaller border of transparent pixels.” This is a canonical optimization process that balances vertex count against transparent pixels, thereby determining the number of vertices for the object’s boundary.
Before the effective filing date of the claimed invention, a POSITA implementing Jeschke’s teachings and per-object coverage meshes would naturally adopt the Sprite Editor practice of tuning vertex count (control points) to reduce transparent pixels, because it yields predictable improvements in silhouette accuracy and rendering efficiency with routine parameter adjustment (Outline Tolerance).
PNG
media_image1.png
13
460
media_image1.png
Greyscale
Ground of Rejection 4
Claim 5 is rejected under 35 U.S.C. § 103 as being unpatentable over Jeschke et al. (NPL) in view of Trapp et al. (NPL), further in view of Sprite Editor (NPL), and still further in view of AutoPolygon (NPL).
As per Claim 5, Jeschke et al., Trapp et al., and Sprite Editor (NPL) alone does not explicitly teach all the limitation(s) of the claim. However, when combined with AutoPolygon (NPL), they collectively teach all of the limitation(s).
AutoPolygon (NPL) teaches the limitation(s) of Claim 5 that recites:
“The method of claim 4, wherein generating the at least one of the one or more coverage meshes comprises generating the vertex information for the boundary of the one of the plurality of objects by obtaining the vertex information for each of the determined number of vertices for the one of the plurality of objects.”
“trace all the points along the outline of the image … a vector of vec2 of all the points found in clockwise order” — AutoPolygon (NPL), Class Reference → trace.
“reduce the amount of points … a vector of Vec2 of the remaining points” — AutoPolygon (NPL), reduce.
“Triangulate the input points … a Triangles object with points and indices.” — AutoPolygon (NPL), triangulate.
“a helper function, packing trace, reduce, expand, triangulate and calculate uv in one function” — AutoPolygon (NPL), generateTriangles.
AutoPolygon’s pipeline obtains per-vertex information along the object boundary (trace → vectors of points), optionally reduces them to a determined number of vertices, and then generates the mesh using those vertices (triangulate / generateTriangles). Thus it “generat[es] the vertex information … by obtaining the vertex information for each of the determined number of vertices.”
Before the effective filing date of the claimed invention, a POSITA implementing Jeschke’s teachings and coverage meshes would routinely adopt AutoPolygon-style steps - tracing boundary points, optionally reducing to a target vertex count, and triangulating - because this yields the predictable result of a compact boundary-aligned mesh ready for rendering, with per-vertex data directly derived from the selected set of boundary vertices.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
Ground of Rejection 5
Claim 10 is rejected under 35 U.S.C. § 103 as being unpatentable over Jeschke et al. (NPL) in view of Trapp et al. (NPL), and further in view of OpenGL Sphere Mapping (NPL).
As per Claim 10, Jeschke et al. and Trapp et al. alone does not explicitly teach all the limitation(s) of the claim. However, when combined with OpenGL Sphere Mapping (NPL), they collectively teach all of the limitation(s) of Claim 10 that recites:
“The method of claim 9, wherein each of the plurality of discrete layers comprises a spherical layer.”
“Sphere mapping is an implementation of environment mapping …” — OpenGL “Sphere Mapping” (NPL).
“…we often use a single environment map for an entire object … This approximation is correct if the object is a sphere …” — OpenGL “Sphere Mapping” (NPL).
Jeschke’s layers are arranged around a view cell with each layer covering a depth range (and are described “similar to a cubic environment map”). Replacing the cubic surfaces with spherical shells (i.e., spherical environment-map surfaces around the view cell) is a well-known alternative form of environment-map support, thus meeting “each … comprises a spherical layer.”
Before the effective filing date, a POSITA using Jeschke’s layered impostors (environment-map-like shells at successive depths) would reasonably choose spherical support surfaces instead of cube faces, given long-standing spherical environment mapping practice in graphics. Substituting spherical shells for the layer geometry is a predictable alternative that can reduce directional distortion/seams for omnidirectional capture, without altering the core layered-impostor pipeline.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
Ground of Rejection 6
Claims 16, 17 are rejected under 35 U.S.C. § 103 as being unpatentable over Jeschke et al. (NPL) in view of Trapp et al. (NPL), and further in view of AutoPolygon (NPL).
As per Claim 16, Jeschke et al. and Trapp et al. alone does not explicitly teach all the limitation(s) of the claim. However, when combined with AutoPolygon (NPL), they collectively teach all of the limitation(s).
AutoPolygon (NPL) teaches the limitation(s) of Claim 16 that recites:
“The method of claim 15, wherein the vertex information for each of the plurality of respective objects comprises a set of vertices corresponding to a boundary of that object.”
“trace all the points along the outline of the image … a vector of vec2 of all the points found in clockwise order.” — AutoPolygon (NPL), Class Reference → trace.
“reduce the amount of points … a vector of Vec2 of the remaining points in clockwise order.” — AutoPolygon (NPL), reduce.
AutoPolygon collects a set of vertices along the object’s boundary (the outline) and — after optional reduction — retains a set of boundary points. This is exactly “vertex information … compris[ing] a set of vertices corresponding to a boundary of that object.”
Before the effective filing date, a POSITA implementing Jeschke’s coverage meshes would routinely adopt an outline-tracing step like AutoPolygon’s to derive boundary vertex sets (trace → optional reduce), a predictable approach to encode per-object mesh vertices from the object’s silhouette for efficient rendering.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 17, Jeschke et al. and Trapp et al. alone does not explicitly teach all the limitation(s) of the claim. However, when combined with AutoPolygon (NPL), they collectively teach all of the limitation(s).
AutoPolygon (NPL) teaches the limitation(s) of Claim 17 that recites: “The method of claim 12, wherein the mesh atlas comprises, for one of the plurality of respective objects: (i) a first coverage mesh corresponding only to opaque pixels of the one of the plurality of respective objects; and (ii) a second coverage mesh corresponding to a set of opaque pixels of the one of the plurality of respective objects and to a set of transparent pixels outside a boundary of the one of the plurality of respective objects.”
Limitation: “a first coverage mesh corresponding only to opaque pixels …”
“trace all the points along the outline of the image … the value when alpha is greater than this value will be counted as opaque, … a vector of vec2 of all the points found in clockwise order.” — AutoPolygon (NPL), Class Reference → trace.
trace collects boundary points based on an opacity threshold, yielding vertex data that correspond only to opaque pixels; triangulation of these points gives the first coverage mesh.
Limitation: “…a second coverage mesh corresponding to a set of opaque pixels … and to a set of transparent pixels outside a boundary …”
“expand the points along their edge, … the expanded points will be clamped in this rect, ultimately resulting in a quad if the expansion is too great … the distance which the edges will expand … a vector of Vec2 as the result of the expansion.” — AutoPolygon (NPL), expand.
expand grows the boundary outward, producing vertices that extend beyond the original outline - i.e., a second mesh that includes the opaque region plus adjacent transparent pixels outside the boundary.
Before the effective filing date, a POSITA using Jeschke’s mesh-atlas pipeline would routinely generate (i) a tight, opaque-only boundary mesh (trace) and (ii) an expanded mesh (expand) to provide padding/bleed for packing and sampling - a predictable refinement that improves robustness while integrating cleanly with the layered impostor workflow.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
Final Remarks
Applicant’s amendments and arguments have been fully considered but are not persuasive. The response does not present amendments or arguments that clearly distinguish the claimed invention from the cited prior art. No significant technical differences have been identified that would warrant withdrawal of the rejection.
Accordingly, the rejection under 35 U.S.C. § 103 is maintained. Please see the 103 rejection above for more details as to how the prior art reads on the newly amended claim features of claim 1.
Examiner’s Suggested Amendments
If applicant elects to file a formal after-final response, the following amendment is suggested as a possible means to place the application in better condition for allowance and to potentially overcome the rejection under 35 U.S.C. § 103.
It is suggested that claim 8 be rewritten in independent form to include all of the limitations of the base claim(s) and any intervening claim(s).
Conclusion
The prior art made of record and relied upon in this action is as follows:
Patent Literature:
Richebourg et al. (US20140184606A1) — "Sprite Graphics Rendering System".
Non-Patent Literature (NPL):
Jeschke, Wimmer, Schuman — "Layered Environment-Map Impostors for Arbitrary Scenes" — 2002. Available at: [https://www.cg.tuwien.ac.at/research/vr/layeredimpostor/jeschke_gi2002.pdf]
Trapp, Döllner — "Interactive Rendering to View-Dependent Texture-Atlases" — 2010. Available at: [https://diglib.eg.org/server/api/core/bitstreams/d0b5ccc8-8889-4536-8a7a-73b0373370b5/content]
AutoPolygon — "AutoPolygon Class Reference" — 2016. Available at: [https://docs.cocos2d-x.org/api-ref/cplusplus/V3.10/db/da0/classcocos2d_1_1_auto_polygon.html]
Sprite Editor (Unity) — "Sprite Editor: Edit Outline" — 2017. Available at: [https://docs.unity3d.com/560/Documentation/Manual/SpriteOutlineEditor.html]
OpenGL — "9.3.2 Sphere Mapping" — 2017. Available at: [https://www.opengl.org/archives/resources/code/samples/advanced/advanced97/notes/node93.html]. For publication date: [https://www.opengl.org/archives/resources/code/samples/advanced/advanced97/notes/node259.html#SECTION000230000000000000000]
Note: A PDF copy of each NPL reference is attached with this Office Action. URLs are included for applicant convenience. If a link becomes unavailable in the future, the citation information may be used to locate the reference or access archived versions via the Wayback Machine.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is listed as follows:
Patent Literature:
(none)
Non-Patent Literature (NPL):
Selinger — "Potrace: a polygon-based tracing algorithm" — 2003
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ADEEL BASHIR whose telephone number is (571) 270-0440. The examiner can normally be reached Monday-Thursday.
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, Daniel Hajnik can be reached on (571) 276-7642. 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.
/ADEEL BASHIR/
Examiner, Art Unit 2616
/DANIEL F HAJNIK/Supervisory Patent Examiner, Art Unit 2616
Prosecution Insights