DETAILED ACTION
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 .
CLAIM INTERPRETATION
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: create block, integrate block, select block, reordering block, depth pass module, color pass module in claim 1, 2, 4, 6, 7 and 9.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
The Specification discloses:
In [0039], “... the information processing system 300 includes a hardware (HW) engine 310, a software (SW) module 320 and a main memory 330... the hardware engine includes a select block 340 and an integrate block 350... the software module 320 includes a create block 360.” In [0040], “... the integrate block 350 includes a depth pass module 351 and a color pass module 355.” The corresponding structure for the select block and the integrate block, which includes the depth pass module and the color pass module, is the hardware engine. And, the corresponding structure for the create block, which includes the reordering block, is the information processing system.
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.
Claim(s) 1; 2, 3, 4, 5 and 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Thyagharajan et al. U.S. Pub. No. 2020/0327396 in view of Correll et al. EP 1 054 384 A2 and Nguyen U.S. Patent No. 10,891,779.
Re: claim 1, Thyagharajan teaches
1. (Currently Amended) An apparatus comprising: a create block configured to receive a plurality of input block voxel indices and configured to generate a reordered list based on the plurality of input block voxel indices; (“Fig. 3 depicts a block diagram 300 illustrating reordering of input data elements. In this case the input date is for sparse voxels 302. The data for the sparse voxels 302 is subject to reordering 304 to produce a chunk 305... ”; Thyagharajan, [0033], Fig. 3)
Fig. 3 illustrates reordering 304 (create block) that receives plural sparse voxels and reorders the sparse voxels to produce a chunk (receive a plurality of input block voxel indices). Reordering 304 is coupled to processing logic 308.
(“The reordering may work with an input list of voxels Vin may be expressed as Vin=[vi], where vi is dimensional location/index of the ith voxel in Vin. An occupancy map M may be defined. The occupancy map M maps a tuple of indices of each occupied voxel to the index of the voxel in then list Vin and is undefined everywhere else.”; Thyagharajan, [0034])
The reordering works with an input list of voxels Vin, expressed as vi, which is a dimension/location index of the ith voxel in Vin. An occupancy map is defined which maps a tuple of indices of each occupied voxel to the index of the voxel in the list Vin. The input list of voxels is then reordered (generate a reordered list based on the plurality of input block voxel indices).
Thyagharajan is silent regarding the reordered list separates a neighborhood of input block voxel indices of the plurality of input block voxel indices into one of a plurality of grids and wherein the input block voxel indices are located within the neighborhood, however, Correll teaches this limitation.
wherein the reordered list separates a neighborhood of input block voxel indices of the plurality of input block voxel indices into one of a plurality of grids and wherein the input block voxel indices are located within the neighborhood; (“Referring now to Figure 13, the mini-blocks are further arranged in groups corresponding to banks of the DRAMs... Each group of 4×4×4 mini-blocks is labeled with a large numeral. Each numeral depicts the assignment of each mini-block of that group to the bank with the same numeral in its assigned DRAM module. For example, the group of mini-blocks 312 in the figure is labeled with numeral 0. This means that each mini-block within group 312 is stored in bank 0 of its respective memory module.”; Correll, [0082], Fig. 13)
Fig. 13 illustrates that the voxels have been divided into 4x4x4 mini-blocks (separates a neighborhood of input block voxel indices of the plurality of input block voxel indices into a plurality of grids). The mini-blocks are arranged in groups corresponding to banks of the DRAMs. Each group of mini-blocks is assigned a large numeral (index) that corresponds to its assigned bank in the DRAM. For example, the each mini-block in group 312 (the input block voxel indices are located within the neighborhood) is stored in bank 0. Correll is combined with Thyagharajan such that the indexed mini-blocks of Correll are the reordered lists of Thyagharajan. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Thyagharajan by adding the feature of the reordered list separates a neighborhood of input block voxel indices of the plurality of input block voxel indices into one of a plurality of grids and wherein the input block voxel indices are located within the neighborhood, in order to maximize efficiency of the DRAM bandwidth by allowing access to consecutive mini-blocks within a bank such that they are not delayed by intervening idle cycles, as taught by Correll ([0084]-[0085]).
Thyagharajan and Correll are silent regarding an integrate block coupled to the create block, the integrate block configured to use the reordered list to deliver integrate depth data for generating a plurality of output block voxel indices, however, Nguyen teaches
and an integrate block coupled to the create block, the integrate block configured to use the reordered list to deliver integrate depth data for generating a plurality of output block voxel indices. (“From experiments, we can well predict the number of reconstructed surface voxels for each use case. Given such a number, we can pre-allocate the array of reconstructed voxel blocks 201. Each voxel block consists of 8x8x8 voxels. This indexing mechanism is extremely efficient for creating, accessing and modifying the voxels; this indexing mechanism enables a fast preparation step before integrating the newly observed depth map into the reconstructed scene.”; Nguyen, col. 4, lines 58-65)
The indexing mechanism creates, accesses and modifies voxels and enables a fast preparation step before integrating the depth map into the reconstructed scene. Fig. 1 illustrates a preparation block (create block) coupled to the integration block (integrate block).
(“The preparation step will result in a list of existing voxels and non-existing voxels which are close to the observed depth map. This prepared list makes it efficient for later integration of the depth map to the reconstructed scene.”; Nguyen, col. 5, lines 29-31)
The preparation step results in, for example, a list of existing voxels, which is used for integration of the depth map to the reconstructed scene. Nguyen is combined with Thyagharajan and Correll such that the indexed voxels of Nguyen are the reordered indexed voxels of Thyagharajan and the reordered indexed voxels of Thyagharajan are used as the prepared list of for integration of the depth map to the reconstructed scene of Nguyen and the preparation block of Nguyen includes the reordering of Thyagharajan. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Thyagharajan by adding the feature of an integrate block coupled to the create block, the integrate block configured to use the reordered list to deliver integrate depth data for generating a plurality of output block voxel indices, in order to quickly and efficiently create, access and modify voxels before integrating the newly observed depth map into the reconstructed scene, as taught by Nguyen (col. 4, lines 62-65).
Re: claim 2, Thyagharajan, Correll and Nguyen teach
2. (Original) The apparatus of claim 1, further comprising a select block coupled to the create block, the select block configured to send the plurality of input block voxel indices to the create block. (“Fig. 3 depicts a block diagram 300 illustrating reordering of input data elements. In this case the input data is for sparse voxels 302. The data for the sparse voxels 302 is subject to reordering 304 to produce a chunk 306...”; Thyagharajan, [0033], Fig. 3)
Fig. 3 illustrates sparse voxels block 302 (select block) coupled to reordering block 304 (create block), where the sparse voxels block sends the input voxels to the reordering block (send the plurality of input block voxel indices to the create block).
Re: claim 3, Thyagharajan, Correll and Nguyen teach
3. (Original) The apparatus of claim 2, further comprising a memory coupled to the create block, the memory configured for storing the plurality of input block voxel indices. (“The data for the sparse voxels 302 is subject to reordering 304 to produce a chunk 306... The chunk 306 is then passed to the processing logic 308 and stored in a memory 310 used by the processing logic for processing... The reordering may work with an input list of voxels Vin may be expressed as Vin=[vi], where vi is dimensional location/index of the ith voxel in Vin. An occupancy map M may be defined. The occupancy map M maps a tuple of indices of each occupied voxel to the index of the voxel in then list Vin and is undefined everywhere else”; Thyagharajan, [0033], [0034])
Fig. 3 illustrates that the sparse voxels block 302 sends sparse voxels to the reordering block to produce a chunk, which is stored in the memory of the processing logic (a memory coupled to the create block, the memory configured for storing the plurality of input block voxel indices).
Re: claim 4, Thyagharajan, Correll and Nguyen teach
4. (Original) The apparatus of claim 3, wherein the create block includes a reordering block, the reordering block configured to generate the reordered list. (“The reordering may work with an input list of voxels Vin may be expressed as Vin=[vi], where vi is dimensional location/index of the ith voxel in Vin. An occupancy map M may be defined. The occupancy map M maps a tuple of indices of each occupied voxel to the index of the voxel in then list Vin and is undefined everywhere else.”; Thyagharajan, [0034], Fig. 3)
The reordering works with an input list of voxels Vin, expressed as vi, which is a dimension/location index of the ith voxel in Vin. The input list of voxels is reordered (generate a reordered list based on the plurality of input block voxel indices). Fig. 3 illustrates a reordering block 304 (create block includes a reordering block) that reorders an input list of voxels (the reordering block configured to generate the reordered list).
Re: claim 5, Thyagharajan, Correll and Nguyen teach
5. (Original) The apparatus of claim 3, wherein the memory is configured to store one or more of the following: a depth image, one or more 3D voxels, a depth and voxel set, one or more voxels, a meta data buffer, an updated voxel, a color image, or an updated voxel with color. (“Fig. 3 depicts a block diagram 300 illustrating reordering of input data elements. In this case the input data is for sparse voxels 302. The data for the sparse voxels 302 is subject to reordering 304 to produce a chunk 306...The chunk 306 is then passed to the processing logic 308 and stored in a memory 310 used by the processing logic for processing.”; Thyagharajan, [0033], Fig. 3)
Fig. 3 illustrates a memory 310 that stores chunk 306, which includes reordered voxels. The memory stores chunk 306, which is considered to include, one or more 3D voxels, one or more voxels or an updated voxel.
Re: claim 6, Thyagharajan, Correll and Nguyen teach
6. (Original) The apparatus of claim 3, wherein the integrate block includes a depth pass module, the depth pass module configured to receive a depth image and one or more 3D voxels, (“... and an integration step, in which the collected and cached voxels of the preparation step are updated with a newly captured depth map frame (403);”; Nguyen, col. 3, lines 1-4)
The integration step (integrate block) receives the collected and cached voxels (one or more 3D voxels) and a newly captured depth map (depth image). Fig. 1 illustrates an integration block 106, which is considered to include a depth pass module, which receives the collected and cached voxels (one or more 3D voxels) and a newly captured depth map (depth image).
and the depth pass module further configured to generate a depth image data based on the depth image and the one or more 3D voxels. (“This indexing mechanism is extremely efficient for creating, accessing and modifying the voxels; this indexing mechanism enables a fast preparation step before integrating the newly observed depth map into the reconstructed scene.”; Nguyen, col. 4, lines 62-65)
(“The preparation step will result in a list of existing voxels and non-existing voxels which are close to the observed depth map. This prepared list makes it efficient for later integration of the depth map to the reconstructed scene.”; Nguyen, col. 5, lines 9-12)
The preparation step results in, for example, a list of existing voxels (one or more 3D voxels), which is used for integration of the depth map (depth image) into the reconstructed scene (generate a depth image data based on the depth image and the one or more 3D voxels). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Thyagharajan by adding the feature of the integrate block includes a depth pass module, the depth pass module configured to receive a depth image and one or more 3D voxels, and the depth pass module further configured to generate a depth image data based on the depth image and the one or more 3D voxels, in order to quickly and efficiently create, access and modify voxels before integrating the newly observed depth map into the reconstructed scene, as taught by Nguyen (col. 4, lines 62-65).
Claim(s) 7 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Thyagharajan in view of Correll and Nguyen as applied to claim 6 above, and further in view of Hasegawa et al. U.S. Pub. No. 2021/0344815 and Chen et al. U.S. Pub. No. 2020/0175644.
Re: claim 7, Thyagharajan, Correll and Nguyen are silent regarding the depth pass module is further configured to deliver the depth image data to a meta data buffer, however Hasegawa and Chen teach
7. (Original) The apparatus of claim 6, wherein the depth pass module is further configured to deliver the depth image data to a meta data buffer. (“On receiving the depth map and the tracking data, the sensor information integration unit 11 integrates the depth map and the tracking data to transmit the integrated data to the reception unit 12, storing the data into the buffer 13 (step S11).”; Hasegawa, [0059], Figs. 2 and 7)
Fig. 2 illustrates an integration unit 11, which is considered to include the depth pass module, that integrates the depth map (depth image data) with tracking data and stores the integrated data in the buffer 13 via the reception unit 12. Thyagharajan, Nguyen and Hasegawa are silent regarding the buffer 13 being a metadata buffer, however, Chen teaches
(“... the RAM such as a DRAM 130 may comprise a color buffer 132 and a metadata buffer 134, where the color buffer 132 and the metadata buffer 134 may be implemented with different buffer regions in the RAM such as DRAM 130.”; Chen, [0025], Fig. 1)
Fig. 1 illustrates that the metadata buffer is included in the DRAM 130.
(“For example, the set of metadata of the aforementioned at least one subsequent frame may comprise one or a combination of depth information regarding deferred shading... ”; Chen, [0029])
The metadata includes depth information regarding deferred shading (depth image data). Hasegawa and Chen are combined with Thyagharajan, Correll and Nguyen such that the buffer of Hasegawa is the metadata buffer of Chen, which is included in the method of Thyagharajan. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Thyagharajan by adding the feature of the depth pass module is further configured to deliver the depth image data to a meta data buffer, in order to generate location information for each label without waiting until all pieces of location information are available thereby suppressing delay over the entire system as taught by Hasegawa ([0076) and in order to enhance overall display performance of an electronic device, as taught by Chen ([0003]).
Re: claim 8, Thyagharajan, Correll, Nguyen, Hasegawa and Chen teach
8. (Original) The apparatus of claim 7, wherein the meta data buffer is a component of the memory. (“... the RAM such as a DRAM 130 may comprise a color buffer 132 and a metadata buffer 134, where the color buffer 132 and the metadata buffer 134 may be implemented with different buffer regions in the RAM such as DRAM 130.”; Chen, [0025], Fig. 1)
Fig. 1 illustrates that the metadata buffer is included in the DRAM 130. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Thyagharajan by adding the feature of - the meta data buffer is a component of the memory, in order to enhance overall display performance of an electronic device, as taught by Chen ([0003]).
Claim(s) 9 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Thyagharajan, Correll, Nguyen, Hasegawa and Chen as applied to claim 7 above, and further in view of Gruber U.S. Patent No. 10,796,478.
Re: claim 9, Thyagharajan, Correll, Nguyen, Hasegawa and Chen are silent regarding integrate block includes a color pass module, the color pass module configured to receive the depth image data from the meta data buffer, and further configured to generate an updated voxels with color based on the depth image data, however, Gruber teaches
9. (Original) The apparatus of claim 7, wherein integrate block includes a color pass module, the color pass module configured to receive the depth image data from the meta data buffer, and further configured to generate an updated voxels with color based on the depth image data. (“The contents of the depth buffer or depth surface 308 may only be inputted into the GPU 302 during the color render pass, such that any non-visible pixels are culled and processing time and/or resources are not wasted on non-visible pixels.”; Gruber, col. 17, lines 41-46, Fig. 3B)
The GPU (integrate block includes a color pass module), receives the contents of the depth buffer (receive the depth image data from the meta data buffer), culls non-visible pixels and colors/shades visible pixels.
(“The first pass of the depth pre-pass may be able to identify the non-visible portion of triangles 404 and 406, such that the non-visible portions may be skipped and are not rendered, which saves processing resources. The first pass may identify the visible portions of triangles 404 and 406, which may in turn save processing resources during the second pass or the color render pass, because the non-visible portions of triangles 404 and 406 do not need to be colored.”; Gruber, col. 18, lines 8-16, Fig. 4)
The first pass or the depth pass identifies visible portions and the second pass or the color render pass colors the visible portions (generate updated voxels with color based on depth image data). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Thyagharajan by adding the feature of integrate block includes a color pass module, the color pass module configured to receive the depth image data from the meta data buffer, and further configured to generate an updated voxels with color based on the depth image data, in order to save color or shading resources on non-visible pixels by generating a complete depth buffer, as taught by Gruber (col. 16, line 66-col. 17, line 2).
Re: claim 10, Thyagharajan, Correll, Nguyen, Hasegawa, Chen and Gruber teach
10. (Original) The apparatus of claim 9, wherein the color pass module includes a color cache memory, the color cache memory configured to receive a color image for the generation of the updated voxels with color. (“Fig. 3B provides an example hardware architecture 320 of the second pass of the depth pre-pass... The architecture 320 may include the GPU 320, a color command buffer 314, the vertex buffer 306, the depth surface 308, the color surface 310, and a texture surface 312.”; Gruber, col. 17, lines 33-39, Fig. 3B)
Fig. 3B illustrates the architecture of the second pass (color pass) of the depth pre-pass. The GPU is considered to include the color pass module and the color surface 310 is considered to be the color buffer (color cache) (the color pass module includes a color cache memory).
(“In a visibility pass, the GPU 502 may be configured to generate visibility information associated with the color. The output of the color visibility pass may include generating a final visibility stream that may include the results of any late occluders. The low res depth surface 508 may be read as input by the GPU 502 during the color visibility pass when the visibility streams are being generated. The final visibility streams are stored in the visibility streams 514.”; Gruber, col. 19, lines 17-25, Fig. 5B)
Fig. 5B illustrates a GPU 502 that generates visibility information associated with color. The GPU receives the low res depth surface during the color visibility pass and generates visibility streams, which are stored in the visibility streams buffer 514 (color cache memory configured to receive a color image for the generation of the updated voxels with color). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Thyagharajan by adding the feature of the color pass module includes a color cache memory, the color cache memory configured to receive a color image for the generation of the updated voxels with color, in order to save color or shading resources on non-visible pixels by generating a complete depth buffer, as taught by Gruber (col. 16, line 66-col. 17, line 2).
Response to Arguments
Applicant's arguments filed 4/27/2026 have been fully considered but they are not persuasive. Applicant Argues regarding claim 1:
“As recited in the pending claims, the element of "wherein the reordered list separates a neighborhood of input block voxel indices of the plurality of input block voxel indices into one of a plurality of grids and wherein the input block voxel indices are located within the neighborhood" is not disclosed by Thyagharajan since Thyagharajan's reordering operation is based on a graph with active voxels represented as vertices of the graph and adjacency as shown by edges connecting the vertices (as represented visually in FIG. 7), which is different from the grid representation visually shown in FIG 5 of the present application and recited in the pending claims... Nguyen discloses generating a list of voxels near an observed depth map. However, the preparation step does not involve a reordering and specifically does not disclose the element of "wherein the reordered list separates a neighborhood of input block voxel indices of the plurality of input block voxel indices into one of a plurality of grids and wherein the input block voxel indices are located within the neighborhood" as recited in the pending claims, as amended.”
Examiner disagrees. Correll teaches this amended limitation of claim 1. Correll illustrates in Fig. 13 that the voxels have been divided into 4x4x4 mini-blocks (separates a neighborhood of input block voxel indices of the plurality of input block voxel indices into a plurality of grids). The mini-blocks are arranged in groups corresponding to banks of the DRAMs. Each group of mini-blocks is assigned a large numeral (index) that corresponds to its assigned bank in the DRAM. For example, the each mini-block in group 312 (the input block voxel indices are located within the neighborhood) is stored in bank 0.
Applicant's arguments filed 4/27/2026 have been fully considered but they are not persuasive. Applicant Argues regarding claims 7-8:
“Specifically, Hasegawa does not disclose the element of "wherein the reordered list separates a neighborhood of input block voxel indices of the plurality of input block voxel indices into one of a plurality of grids and wherein the input block voxel indices are located within the neighborhood" as recited in the pending claims, as amended. Instead, Hasegawa discloses synchronization of location information with a reference timestamp with no mention of a "reordered list"... Specifically, Chen does not disclose the element of "wherein the reordered list separates a neighborhood of input block voxel indices of the plurality of input block voxel indices into one of a plurality of grids and wherein the input block voxel indices are located within the neighborhood" as recited in the pending claims, as amended.”
Examiner disagrees. As discussed above, Correll teaches this amended limitation of claim 1
Applicant's arguments filed 4/27/2026 have been fully considered but they are not persuasive. Applicant Argues regarding claims 9-10:
“Specifically, Gruber does not disclose the element of "wherein the reordered list separates a neighborhood of input block voxel indices of the plurality of input block voxel indices into one of a plurality of grids and wherein the input block voxel indices are located within the neighborhood" as recited in the pending claims, as amended.”
Examiner disagrees. As discussed above, Correll teaches this amended limitation of claim 1.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONNA J RICKS whose telephone number is (571)270-7532. The examiner can normally be reached on M-F 7:30am-5pm EST (alternate Fridays off).
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, Devona Faulk can be reached on 571-272-7515. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Donna J. Ricks/Examiner, Art Unit 2618
/DEVONA E FAULK/Supervisory Patent Examiner, Art Unit 2618
Prosecution Insights