Prosecution Insights
Last updated: October 01, 2026
Application No. 19/170,020

METHOD, APPARATUS, AND MEDIUM FOR POINT CLOUD CODING

Non-Final OA §103§112
Filed
Apr 03, 2025
Priority
Oct 04, 2022 — CN PCT/CN2022/123705 +1 more
Examiner
TSWEI, YU-JANG
Art Unit
Tech Center
Assignee
Bytedance Inc.
OA Round
1 (Non-Final)
84%
Grant Probability
Favorable
1-2
OA Rounds
9m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 84% — above average
84%
Career Allowance Rate
388 granted / 464 resolved
+23.6% vs TC avg
Strong +16% interview lift
Without
With
+16.0%
Interview Lift
resolved cases with interview
Typical timeline
2y 3m
Avg Prosecution
45 currently pending
Career history
507
Total Applications
across all art units

Statute-Specific Performance

§101
5.9%
-34.1% vs TC avg
§103
72.8%
+32.8% vs TC avg
§102
6.0%
-34.0% vs TC avg
§112
7.4%
-32.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 464 resolved cases

Office Action

§103 §112
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 . Priority Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. [ PCT/CN2022/123705], filed on [10/04/2022]. Should applicant desire to obtain the benefit of foreign priority under 35 U.S.C. 119(a)-(d) prior to declaration of an interference, a certified English translation of the foreign application must be submitted in reply to this action. 37 CFR 41.154(b) and 41.202(e). Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claim 6 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. Claim 6 recite the limitation “the point position" in page 1, line 36. There is insufficient antecedent basis for this limitation in the claim. Claim Objections Claim 9 is objected to because of the following informalities: "the neighbour nodes are nodes that shares" → should be "share." Also "neighbours nodes" (plural-plural) should be "neighbour nodes". Appropriate correction is required. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhang (US 20210385494 A1), in view of Wan et al. (US 20220327746 A1, hereinafter Wan). Regarding Claim 1, Zhang teaches A method for point cloud coding, comprising: (Zhang, Paragraph [0021], "The following described exemplary embodiments provide a system, method and computer program that optimizes hash-based accessing of geometry occupancy information for point cloud coding."; and Zhang, Paragraph [0017], "optimize hash-based accessing of occupancy data for point cloud coding"); determining, for a conversion between a point cloud sequence comprising at least one point cloud (PC) sample associated with a plurality of nodes and a bitstream of the point cloud sequence, (Zhang, Paragraph [0028], "the geometry encoding proceeds as follows. First, a cubical axis-aligned bounding box B is defined by two points (0,0,0) and (2M−1, 2M−1, 2M−1), where 2M−1 defines the size of B and M is specified in the bitstream. The octree structure 200A is then built by recursively subdividing B. At each stage, a cube is subdivided into 8 sub-cubes <read on a plurality of nodes> . An 8-bit code, namely the occupancy code, is then generated"; and Zhang, Paragraph [0029], "The occupancy code 204 of each node is then compressed by an arithmetic encoder."; and Zhang, Paragraph [0031], "The decoding process starts by parsing the dimensions of the bounding box B from bitstream. The same octree structure is then built by subdividing B according to the decoded occupancy codes."; it is noted the bitstream carries the occupancy codes of the nodes; the encoding/decoding acts constitute the recited "conversion"); a node index of a first node of the plurality of nodes, (Zhang, Paragraph [0033], "For each octree partition depth d, a hash table Hd is maintained, where the key is the Morton code of an octree node in depth d, i.e., Mi d=Morton(xi d, yi d, zi d), where (xi d, yi d, zi d) is the 3D coordinates of the octree node."; it is noted the Morton code M<sub>i</sub><sup>d</sup> is the node index of the first node); wherein the first node is stored in a data structure and is indicated in the data structure by the node index (Zhang, Paragraph [0033], "A hash table < read on data structure > may be used to store occupancy information. … Using the Morton code Mi d as the key < read on node index> , one can access its occupancy value in the hash table Hd."; it is noted each octree node's occupancy is stored in H<sub>d</sub> and is looked-up/indicated via its Morton-code key); and performing the conversion based on a position indication and occupancy information. (Zhang, Paragraph [0033], "the key is the Morton code of an octree node in depth d, i.e., Mi d=Morton(xi d, yi d, zi d), where (xi d, yi d, zi d) is the 3D coordinates < read on position indication >1of the octree node."; and Zhang, Paragraph [0034], "When encoding/decoding the occupancy value of current node, the occupancy information of neighboring nodes is obtained from the hash table Hd. After encoding/decoding < read on conversion> an occupancy value of the current node, the coded occupancy value is then stored in Hd.") However, Zhang does not explicitly recite the term "point cloud sequence" in temporal-series sense. However, Wan teaches a conversion between a point cloud sequence comprising at least one point cloud (PC) sample … and a bitstream of the point cloud sequence (Wan, Paragraph [0062], "After the Morton code of each point is obtained, the encoder may sort all Morton codes of all points in the point cloud in an order from smallest to largest, to generate a point cloud sequence set corresponding to the point cloud. All Morton codes of all points in the point cloud are stored in the point cloud sequence set."; and Wan, Paragraph [0031], "geometric information of a point cloud and attribute information corresponding to each point cloud are encoded separately. In the process of geometric encoding, … Then points in the leaf nodes are arithmetically encoded to generate a binary geometric bit stream, i.e., geometric bitstream."), and a node index … a converted code of a node position — specifically Morton codes used as identifiers to index into lookup tables (Wan, Paragraph [0044], "the binarized value of x may be used as an index for searching for a required entry Mx in the Morton code lookup table Tx. The binarized value of y may be used as an index for searching for a required entry My in the Morton code lookup table Ty. The binarized value of z may be used as an index for searching for a required entry Mz in the Morton code lookup table Tz."). Wan and Zhang are analogous — both are directed to G-PCC/point-cloud coding using Morton-code-keyed lookup structures to accelerate node-level operations. Zhang provided a way of storing per-node occupancy in a Morton-code-keyed hash table for fast neighbor access during (en/de)coding. Wan provided a way of using Morton-code lookup tables so that the encoder and decoder can share the same efficient indexing scheme for point-cloud coding with sequence-level Morton ordering. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Wan with the modified invention of Zhang such that hash-table-based per-node access is applied within a G-PCC "point cloud sequence" pipeline as taught by Wan, yielding a method for point cloud coding that determines a Morton-coded node index of a first node stored in the hash table (data structure) and performs the conversion based on the node's 3D coordinates (position indication) and its stored occupancy value (occupancy information). The motivation is to reduce storage consumption and computational complexity while improving encoding/decoding efficiency, expressly discussed by Wan in Paragraph [0005]. Regarding Claim 2, the combination of Zhang and Wan teaches the invention in Claim 1. The combination further teaches wherein the first node is stored at a decoder and/or an encoder side (Zhang, Paragraph [0034], "When encoding/decoding the occupancy value of current node, the occupancy information of neighboring nodes is obtained from the hash table Hd. After encoding/decoding an occupancy value of the current node, the coded occupancy value is then stored in Hd."; it is noted the H<sub>d</sub> is maintained at both encoder and decoder); wherein the data structure further comprises the occupancy information indicating whether there is a point in the first node (Zhang, Paragraph [0033], "A hash table may be used to store occupancy information."; and Paragraph [0028], "each sub-cube in order to indicate whether it contains points (i.e., full and has value 1) or not (i.e., empty and has value 0)."; it is noted the stored occupancy value tells whether the node contains a point); and /or wherein the data structure is in the form of an array, a list, or a map (Zhang, Paragraph [0033], "A hash table < read on map > may be used to store occupancy information."; a hash table is a key→value associative structure); and/or wherein the node index is a node position of the first node in the data structure (Zhang, Paragraph [0033], "the key is the Morton code of an octree node in depth d, i.e., Mi d=Morton(xi d, yi d, zi d), where (xi d, yi d, zi d) is the 3D coordinates of the octree node."; the Morton key is derived from the node position and functions as the position-of-the-node in the hash); or wherein the node index is a pointer that points to the first node in the data structure, and/or wherein the at least one PC sample comprises one of the following: a frame, a picture, a slice, a sub- frame, a sub-picture, a tile, or a segment (Zhang, Paragraph [0035], "sent in the bitstream as part of high-level syntax, such as sequence parameter set, geometry parameter set or slice header, etc."; the presence of a slice header indicates coding is organized in slices "read on slice"). Regarding Claim 3, the combination of Zhang and Wan teaches the invention in Claim 1. The combination further teaches wherein the node index is stored in a lookup table (Zhang, Paragraph [0033], "A hash table < read on lookup table > may be used to store occupancy information. For each octree partition depth d, a hash table Hd is maintained, where the key is the Morton code of an octree node in depth d"; Paragraph [0030], "an adaptive look up table (A-LUT)"). Regarding Claim 4, the combination of Zhang and Wan teaches the invention in Claim 3. The combination further teaches wherein in the lookup table, the node index is denoted as T[f], wherein f indicates a converted code of a node position of the first node, wherein the converted code is one of: a Morton code, a Hilbert code, a converted code of partial bits of the node position, or a converted code of all bits of the node position (Zhang, Paragraph [0033], "For each octree partition depth d, a hash table Hd is maintained, where the key is the Morton code of an octree node in depth d, i.e., Mi d=Morton(xi d, yi d, zi d), where (xi d, yi d, zi d) is the 3D coordinates of the octree node.") — H<sub>d</sub>[M<sub>i</sub><sup>d</sup>] "read on T[f]", with f = Morton code of the node position (all-bits variant);[[ or a converted code of all bits of the node position, or wherein in the lookup table, the node index is denoted as T[x][y][z], wherein x, y and z indicate a node position of the first node, wherein a point position is indicated by partial bits of the node position, or wherein the point position is indicated by all bits of the node position, and/or ]] wherein the lookup table is one of:1D, 2D, 3D, a 3D array, or a hash table (Zhang, Paragraph [0033], "A hash table may be used to store occupancy information."). Zhang does not explicitly disclose but Wan teaches or a converted code of all bits of the node position, or wherein in the lookup table, the node index is denoted as T[x][y][z], wherein x, y and z indicate a node position of the first node, wherein a point position is indicated by partial bits of the node position, or wherein the point position is indicated by all bits of the node position (Wan, Paragraph [0044], "For G-PCC, the triple variable (s, t, u) may be a three-dimensional coordinate (x, y, z) of a certain point in a point cloud."; and Wan, Paragraph [0044], "Specifically, the binarized value of x may be used as an index for searching for a required entry Mx in the Morton code lookup table Tx. The binarized value of y may be used as an index for searching for a required entry My in the Morton code lookup table Ty. The binarized value of z may be used as an index for searching for a required entry Mz in the Morton code lookup table Tz."; it is noted Wan discloses three separate coordinate-indexed lookup tables T<sub>x</sub>[x], T<sub>y</sub>[y], T<sub>z</sub>[z] where each of x, y, z is the binarized value ("read on all bits") of a coordinate component of the node position; a POSITA would recognize the combined addressing (Tx[x], Ty[y], Tz[z]) as functionally equivalent to a 3D-indexed table T[x][y][z] whose entry is looked up by the three coordinate-components of the node position (either partial bits or all bits, per Wan's "binarized value" language covering the full bit-string of the component). Wan and Zhang are analogous since both of them are dealing with G-PCC Morton-code-based indexing for point-cloud coding. Zhang provided a way of using Morton-keyed hash table. Wan provided a way of using coordinate-indexed within toolkit for trading hash-collision cost against direct-address memory cost. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Wan into modified invention of Zhang, the motivation is use the encoder and the decoder can only store and use one Morton code lookup table, the computational complexity and storage space can be reduced effectively, thereby improving the encoding and decoding efficiency which is discussed by Wan in Paragraph [0048]. Regarding Claim 5, the combination of Zhang and Wan teaches the invention in Claim 3. The combination further teaches wherein a node index in the lookup table is a converted code of a node position of one of the plurality of nodes (Zhang, Paragraph [0033], "For each octree partition depth d, a hash table Hd is maintained, where the key is the Morton code of an octree node in depth d, i.e., Mi d=Morton(xi d, yi d, zi d), where (xi d, yi d, zi d) is the 3D coordinates of the octree node.") — M<sub>i</sub><sup>d</sup> "read on node index in the lookup table," and it is a converted code (Morton function applied to) the node position (x<sub>i</sub><sup>d</sup>, y<sub>i</sub><sup>d</sup>, z<sub>i</sub><sup>d</sup>); wherein the converted code is a Morton code or a Hilbert code (Zhang, Paragraph [0033], "the key is the Morton code of an octree node in depth d"); wherein the converted code is a converted code of partial bits of the node position, or wherein the converted code is a converted code of all bits of the node position (Zhang, Paragraph [0033], "Mi d=Morton(xi d, yi d, zi d), where (xi d, yi d, zi d) is the 3D coordinates of the octree node."; it is noted because Morton is computed from the full 3D coordinate triple (x<sub>i</sub><sup>d</sup>, y<sub>i</sub><sup>d</sup>, z<sub>i</sub><sup>d</sup>) of the octree node at depth d, the resulting M<sub>i</sub><sup>d</sup> is a converted code of all bits of the node position). Regarding Claim 6, the combination of Zhang and Wan teaches the invention in Claim 3. The combination further teaches [[wherein a node index of the lookup table is a node position, wherein the point position is indicated by partial bits of the node position, or all bits of the node position, and/or ]] wherein an empty index is used to indicate that one node does not exist, wherein the empty index is a pre-defined index, wherein the pre-defined index can only be used when the corresponding node does not exist [[ , and/or wherein the empty index is -1 ]] (Zhang, Paragraph [0033], "The occupancy value of the octree node i in depth d can be obtained as follows: OC i d = { H d(M i d) if H d(M i d) != NULL 0 otherwise") — the pre-defined value NULL "read on empty index / pre-defined index" is used exactly when the lookup returns nothing (i.e., the node does not exist). Regarding Claim 7, the combination of Zhang and Wan teaches the invention in Claim 3. The combination further teaches wherein nodes whose indices are stored in the lookup table are in a limited region (Zhang, Paragraph [0035], "When the hash table reaches the maximum capacity, the hash table will shrink itself by removing partial elements in it."; and Zhang, Paragraph [0036], "the block size can be (2M, 2M, 2M) in 3D space. Therefore, the positions with the coordinates (2im−1, 2jM−1, 2kM−1), where i, j, k=1, 2, 3, . . . , are boundaries. Therefore, all the hash element with the key value Morton(2iM−1, 2jM−1, 2kM−1) are kept and all the rest elements can be deleted from the table."; it is noted after shrinking, only hash elements within the retained block/boundary region remain in the table "read on limited region"); wherein the nodes whose indices are stored in the lookup table share the same tree level [[or have different tree levels, ]] wherein a tree level comprises an octree depth (Zhang, Paragraph [0033], "For each octree partition depth d, a hash table Hd is maintained"; it is noted each H<sub>d</sub> holds only nodes at the same octree depth d. Regarding Claim 8, the combination of Zhang and Wan teaches the invention in Claim 7. The combination further teaches wherein the limited region is a regular region, wherein the limited region is a rectangular region or a square region, wherein the square region corresponds to one octree node in one octree depth (Zhang, Paragraph [0036], "the block size can be (2M, 2M, 2M) in 3D space < read on square region / cubic region>. Therefore, the positions with the coordinates (2im−1, 2jM−1, 2kM−1), where i, j, k=1, 2, 3, . . . , are boundaries."; it is noted block in 3D space is a regular region and, being a power-of-two axis-aligned cube, corresponds to one octree node at a particular octree depth). Regarding Claim 9, the combination of Zhang and Wan teaches the invention in Claim 7. The combination further teaches [[ wherein the limited region contains a rectangular region and its neighbour nodes, or wherein the limited region contains a square region and its neighbour nodes, wherein the neighbour nodes are nodes that shares at least one of a face, or an edge, or a vertex with the rectangular region or the square region, and/or ]] wherein the neighbours nodes share a same octree depth with the first node (Zhang, Paragraph [0030], "each bin is encoded by referring to the occupancy status of neighboring nodes and child nodes of neighboring nodes, where the neighboring nodes are in the same level of current node."; the neighbors used in Zhang's coding are expressly at the same octree level (i.e., same octree depth) as the current node). Regarding Claim 10, the combination of Zhang and Wan teaches the invention in Claim 7. The combination further teaches wherein at least one indication is used to indicate a size of the limited region, wherein the indication is the size of the limited region (Zhang, Paragraph [0036], "Note that the boundary size M can be either fixed for all cases or can be configured differently case by case and sent in the bitstream as part of high-level syntax, such sequence parameter set, geometry parameter set or slice header, etc."; M is the indication and it is the (log-)size of the limited region); wherein the size of the limited region is a function of a value of the indication (Zhang, Paragraph [0036], "the block size can be (2M, 2M, 2M) in 3D space.") — block size = 2<sup>M</sup> is a (power/exponential) function of the indication M) wherein the indication indicates a size of one dimension of the limited region, or wherein the indication is indicated to a decoder (Zhang, Paragraph [0036], "The block boundary can be defined according to the position coordinates of current node. Usually, the block size is defined as a power of two. For example, the block size can be (2M, 2M, 2M) in 3D spac"; it is noted M is signaled to the decoder and specifies the size of each spatial dimension of the block). Regarding Claim 11, the combination of Zhang and Wan teaches the invention in Claim 10. The combination further teaches wherein the function comprises at least one of a linear function, a power function, an exponential function [[a logarithmic function]] (Zhang, Paragraph [0036], "the block size can be (2M, 2M, 2M) in 3D space."; block size = 2<sup>M</sup> "read on power function / exponential function" of the indication M) [[ , and/or wherein the indication is coded with at least one of fixed-length coding, unary coding, or truncated unary coding ]] or wherein the indication is coded with at least one context in arithmetic coding (Zhang, Paragraph [0031], "encoded by using a binary arithmetic encoder."; and Zhang, Paragraph [0029], "Either way performs arithmetic coding with context modeling to encode the occupancy code 204, where the context status is initialized at the beginning of the whole coding process and is updated during the coding process."; it is noted the coding infrastructure expressly uses binary arithmetic coding with context modeling for the syntax elements it produces, [[or wherein the indication is bypass coded, or wherein the indication is coded in a predictive way ]] wherein the indication is a constant that is same at a decoder side and an encoder side (Zhang, Paragraph [0036], "the boundary size M can be either fixed for all cases or can be configured differently case by case and sent in the bitstream as part of high-level syntax, such sequence parameter set, geometry parameter set or slice header, etc.") — the "fixed for all cases" option makes M a constant that is identical at both encoder and decoder). Regarding Claim 12, the combination of Zhang and Wan teaches the invention in Claim 3. The combination further teaches wherein the lookup table is used for neighbour search (Zhang, Paragraph [0034], "When encoding/decoding the occupancy value of current node, the occupancy information of neighboring nodes is obtained from the hash table Hd."; the hash table is expressly consulted to obtain occupancy of neighbors); wherein an empty index is used to indicate that one node does not exist (Zhang, Paragraph [0033], "Using the Morton code Mi d as the key, one can access its occupancy value in the hash table Hd. The occupancy value of the octree node i in depth d can be obtained as follows: OC i d = { H d(M i d) if H d(M i d) != NULL 0 otherwise"); the sentinel value NULL returned by H<sub>d</sub>(M<sub>i</sub><sup>d</sup>) "read on empty index" signals that the octree node with Morton key M<sub>i</sub><sup>d</sup> is absent from the hash table (i.e., "one node does not exist"), and when NULL is encountered the code falls into the "otherwise" branch that returns occupancy 0 (unoccupied). Thus NULL is the explicit sentinel used to indicate node non-existence) wherein the empty index is a pre-defined index (Zhang, Paragraph [0033], "OC i d = { H d(M i d) if H d(M i d) != NULL 0 otherwise"; NULL is a standardized, predetermined constant value in hash-table implementations that is fixed by the coding scheme itself rather than derived dynamically from data; accordingly, NULL "read on pre-defined index”); wherein the pre-defined index is only used if a corresponding node does not exist, [[, or wherein the pre-defined index is -1. ]] (Zhang, Paragraph [0033], "OC i d = { H d(M i d) if H d(M i d) != NULL 0 otherwise") — the conditional structure of the equation shows that NULL appears exclusively as the sentinel returned when the hash-table entry for M<sub>i</sub><sup>d</sup> is absent (i.e., when the "corresponding node does not exist" in H<sub>d</sub>). Whenever the node does exist, the "if" branch evaluates and returns H<sub>d</sub>(M<sub>i</sub><sup>d</sup>) — the actual stored occupancy — never NULL. Thus NULL is used only when the corresponding node does not exist, precisely meeting sub-limitation (iv); Zhang, Paragraph [0034], "After encoding/decoding an occupancy value of the current node, the coded occupancy value is then stored in Hd.”) Regarding Claim 13, the combination of Zhang and Wan teaches the invention in Claim 3. The combination further teaches wherein the lookup table is used for neighbour search (Zhang, Paragraph [0034], "When encoding/decoding the occupancy value of current node, the occupancy information of neighboring nodes is obtained from the hash table Hd.") — H<sub>d</sub> is expressly consulted to obtain neighbouring-node occupancy). Regarding Claim 14, the combination of Zhang and Wan teaches the invention in Claim 3. The combination further teaches wherein an indication is used to indicate a memory size of the lookup table (Zhang, Paragraph [0035], "In one or more embodiments, a maximum hash table size may be defined."), wherein the indication is the memory size of the lookup table (Zhang, Paragraph [0035], "It may be appreciated that the maximum size can be either fixed for all cases or can be configured differently case by case and sent in the bitstream as part of high-level syntax, such as sequence parameter set, geometry parameter set or slice header, etc."; it is noted the "maximum hash table size" value itself directly signals the memory-size of the hash table "read on lookup table," meeting (i) and (ii)) [[ or wherein the memory size of the lookup table is a function of the indication value, wherein the function is one of a linear function, a power function, an exponential function or a logarithmic function]] wherein the indication is indicated to a decoder (Zhang, Paragraph [0035], "sent in the bitstream as part of high-level syntax, such as sequence parameter set, geometry parameter set or slice header, etc.") — sending the value in the bitstream inherently signals it to the decoder, meeting (iv)) [[or wherein the indication is coded with one of a fixed-length coding, a unary coding, or a truncated unary coding]] wherein the indication is coded with at least one context in arithmetic coding (Zhang, Paragraph [0031], "encoded by using a binary arithmetic encoder."; and Zhang, Paragraph [0029], "Either way performs arithmetic coding with context modeling to encode the occupancy code 204, where the context status is initialized at the beginning of the whole coding process and is updated during the coding process.") — Zhang's bitstream syntax elements are carried by its binary arithmetic encoder with context modeling; the max-size indication signaled in HLS shares this arithmetic-coding infrastructure, meeting (iv-b); [[or wherein the indication is bypass coded]] [[wherein the indication is coded in a predictive way]] wherein the indication is a constant that is same at a decoder side and an encoder side (Zhang, Paragraph [0035], "the maximum size can be either fixed for all cases") — the "fixed for all cases" option makes the max-size a constant identical at both encoder and decoder, meeting (v) Regarding Claim 15, the combination of Zhang and Wan teaches the invention in Claim 3. The combination further teaches wherein an indication is used to indicate whether the lookup table is used to store the node index (Zhang, Paragraph [0031], "A binary flag indicating whether S is the A-LUT or not is encoded. If S is in the A-LUT, the index in the A-LUT is encoded by using a binary arithmetic encoder.") — the binary flag "read on indication" signals whether the A-LUT "read on lookup table" is used to store/hold the current symbol's index, meeting (i); or wherein the indication is indicated to the decoder (Zhang, Paragraph [0031], "A binary flag indicating whether S is the A-LUT or not is encoded.") — the flag being encoded into the bitstream means it is signaled to the decoder for parsing, meeting (ii)), [[wherein the indication is coded with one of a fixed-length coding, a unary coding, or a truncated unary coding]], wherein the indication is coded with at least one context in arithmetic coding (Zhang, Paragraph [0031], "encoded by using a binary arithmetic encoder."; and Zhang, Paragraph [0029], "Either way performs arithmetic coding with context modeling to encode the occupancy code 204, where the context status is initialized at the beginning of the whole coding process and is updated during the coding process."; it is noted the flag is arithmetically coded within the same context-modeled arithmetic-coding framework, meeting (ii-b); [[ or wherein the indication is bypass coded]] [[ or wherein the indication is coded in a predictive way]] [[or wherein the indication is a constant that is same at a decoder side and an encoder side]] Regarding Claim 16, the combination of Zhang and Wan teaches the invention in Claim 3. The combination further teaches wherein the lookup table is built up at a decoder and/or an encoder (Zhang, Paragraph [0034], "After encoding/decoding an occupancy value of the current node, the coded occupancy value is then stored in Hd.") — H<sub>d</sub> is built up incrementally at both encoding and decoding sides through the store-back operation, meeting (i); [[if the lookup table is a 3D table and a node position is the node index of the lookup table, a memory is assigned to the lookup table and each entry in the lookup table is initialized by an empty index]] [[the lookup table is initialized by setting a corresponding node index in the lookup table for every node in a limited region]] or wherein the lookup table is built up depending on information indicated from an encoder to a decoder (Zhang, Paragraph [0035], "the maximum size can be either fixed for all cases or can be configured differently case by case and sent in the bitstream as part of high-level syntax, such as sequence parameter set, geometry parameter set or slice header, etc.") — the maximum-size parameter of the hash table is signaled from encoder to decoder in HLS, which controls how the hash table is built up (its capacity), meeting (ii)) [[wherein if the lookup table is a 3D table and the node position is the node index of the lookup table, a memory is assigned to the lookup table and each entry in the lookup table is initialized by an empty index ]] wherein a size of the memory of the lookup table is determined by an indication, and the indication is indicated from an encoder to a decoder (Zhang, Paragraph [0035], "a maximum hash table size may be defined."; and Zhang, Paragraph [0035], "sent in the bitstream as part of high-level syntax, such as sequence parameter set, geometry parameter set or slice header, etc.") — the max-hash-table-size indication that governs the memory allocated to H<sub>d</sub> is signaled from encoder to decoder, meeting the memory-size-indication sub-limitation within (ii-a); [[wherein each entry in the lookup table is initialized by an empty index (in the 3D-table contingent)]] [[the lookup table is initialized by setting a corresponding node index in the lookup table for every node in the limited region]] Regarding Claim 18, it recites limitations similar in scope to the limitations of claim 1, but in a Apparatus. As shown in the rejection, the combination of Zhang and Wan disclose the limitations of claims 1. Additionally, Zhang discloses an Apparatus that maps to Fig. 8 and Paragraph [0005], [0045], [0047] (Zhang, Paragraph [0005], "a computer system for decoding point cloud data is provided. The computer system may include one or more processors, one or more computer-readable memories, one or more computer-readable tangible storage devices, and program instructions stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, whereby the computer system is capable of performing a method."; and Zhang, Paragraph [0045], "each of the sets of internal components 800 include one or more processors 820, one or more computer-readable RAMs 822 and one or more computer-readable ROMs 824"; and Zhang, Paragraph [0047], "one or more computer-readable tangible storage devices 830 for execution by one or more of the respective processors 820"). Thus, Claim 11 is met by Caskey according to the mapping presented in the rejection of claims 1, given the method corresponds to the Apparatus. Regarding Claim 19, it recites limitations similar in scope to the limitations of claim 1 and the combination of Zhang and Wan teaches all the limitations as of Claim 1. And Zhang discloses these features can be implemented on a computer readable storage medium (Zhang, Paragraph [0005], "a computer system for decoding point cloud data is provided. The computer system may include one or more processors, one or more computer-readable memories, one or more computer-readable tangible storage devices, and program instructions stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, whereby the computer system is capable of performing a method."; and Zhang, Paragraph Paragraph [0047], "one or more computer-readable tangible storage devices 830 for execution by one or more of the respective processors 820"), Regarding Claim 20, Zhang teaches A non-transitory computer-readable recording medium storing a bitstream of a point cloud sequence which is generated by a method performed by an apparatus for point cloud coding, wherein the method comprises: (Zhang, Paragraph [0075], "The computer readable medium may include a computer-readable non-transitory storage medium (or media) having computer readable program instructions thereon"; and Zhang, Paragraph [0076], "The computer readable storage medium can be a tangible device that can retain and store instructions … A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM) …"; and Zhang, Paragraph [0028], "M is specified in the bitstream. The octree structure 200A is then built … An 8-bit code, namely the occupancy code, is then generated"; and Zhang, Paragraph [0029], "The occupancy code 204 of each node is then compressed by an arithmetic encoder.") — an encoding apparatus generates a bitstream carrying M and the arithmetic-coded occupancy codes; that bitstream is stored on the non-transitory medium of [0076]), determining a node index of a first node of a plurality of nodes, wherein the point cloud sequence comprises at least one point cloud (PC) sample associated with the plurality of nodes, and the first node is stored in a data structure and is indicated in the data structure by the node index; (Zhang, Paragraph [0033], "For each octree partition depth d, a hash table Hd is maintained, where the key is the Morton code of an octree node in depth d, i.e., Mi d=Morton(xi d, yi d, zi d), where (xi d, yi d, zi d) is the 3D coordinates of the octree node. Using the Morton code Mi d as the key, one can access its occupancy value in the hash table Hd."), and generating the bitstream based on a position indication and occupancy information. (Zhang, Paragraph [0034], "After encoding/decoding an occupancy value of the current node, the coded occupancy value is then stored in Hd."; and Zhang, Paragraph [0029], "The occupancy code 204 of each node is then compressed by an arithmetic encoder."; and Zhang, Paragraph [0035], "sent in the bitstream as part of high-level syntax, such as sequence parameter set, geometry parameter set or slice header, etc.") — the encoder generates the bitstream using the node's coordinates (x<sub>i</sub><sup>d</sup>, y<sub>i</sub><sup>d</sup>, z<sub>i</sub><sup>d</sup>) "read on position indication" and its occupancy value ("read on occupancy information"). However, Zhang does not explicitly recite the term "point cloud sequence" in temporal-series sense. However, Wan teaches a conversion between a point cloud sequence comprising at least one point cloud (PC) sample … and a bitstream of the point cloud sequence (Wan, Paragraph [0062], "After the Morton code of each point is obtained, the encoder may sort all Morton codes of all points in the point cloud in an order from smallest to largest, to generate a point cloud sequence set corresponding to the point cloud. All Morton codes of all points in the point cloud are stored in the point cloud sequence set."; and Wan, Paragraph [0031], "geometric information of a point cloud and attribute information corresponding to each point cloud are encoded separately. In the process of geometric encoding, … Then points in the leaf nodes are arithmetically encoded to generate a binary geometric bit stream, i.e., geometric bitstream."), and a node index … a converted code of a node position — specifically Morton codes used as identifiers to index into lookup tables (Wan, Paragraph [0044], "the binarized value of x may be used as an index for searching for a required entry Mx in the Morton code lookup table Tx. The binarized value of y may be used as an index for searching for a required entry My in the Morton code lookup table Ty. The binarized value of z may be used as an index for searching for a required entry Mz in the Morton code lookup table Tz."). Wan and Zhang are analogous — both are directed to G-PCC/point-cloud coding using Morton-code-keyed lookup structures to accelerate node-level operations. Zhang provided a way of storing per-node occupancy in a Morton-code-keyed hash table for fast neighbor access during (en/de)coding. Wan provided a way of using Morton-code lookup tables so that the encoder and decoder can share the same efficient indexing scheme for point-cloud coding with sequence-level Morton ordering. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Wan with the modified invention of Zhang such that hash-table-based per-node access is applied within a G-PCC "point cloud sequence" pipeline as taught by Wan, yielding a method for point cloud coding that determines a Morton-coded node index of a first node stored in the hash table (data structure) and performs the conversion based on the node's 3D coordinates (position indication) and its stored occupancy value (occupancy information). The motivation is to reduce storage consumption and computational complexity while improving encoding/decoding efficiency, expressly discussed by Wan in Paragraph [0005]. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 12423873 B2 Method for constructing morton codes, encoder, decoder, and storage medium US 12200231 B2 Nearest neighbor search method, apparatus, device, and storage medium US 11785216 B2 Point cloud coding methods, encoder, and decoder US 20230224506 A1 METHOD FOR ENCODING AND DECODING, ENCODER, AND DECODER US 20220292639 A1 TECHNIQUES AND APPARATUS FOR ALPHABET-PARTITION CODING OF TRANSFORM COEFFICIENTS FOR POINT CLOUD COMPRESSION US 20210407148 A1 Point Cloud Geometry Compression Using Octrees with Multiple Scan Orders US 20200314435 A1 VIDEO BASED POINT CLOUD COMPRESSION-PATCH ALIGNMENT AND SIZE DETERMINATION IN BOUNDING BOX US 10762667 B2 Method and apparatus for compression of point cloud data US 10694210 B2 Scalable point cloud compression with transform, and corresponding decompression US 20190394496 A1 POINT CLOUD GEOMETRY COMPRESSION USING OCTREES AND BINARY ARITHMETIC ENCODING WITH ADAPTIVE LOOK-UP TABLES US 10223810 B2 Region-adaptive hierarchical transform and entropy coding for point cloud compression, and corresponding decompression Any inquiry concerning this communication or earlier communications from the examiner should be directed to YUJANG TSWEI whose telephone number is (571)272-6669. The examiner can normally be reached 8:30am-5:30pm EST. 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, Kent Chang can be reached on (571) 272-7667. 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. /YuJang Tswei/Primary Examiner, Art Unit 2614 1
Read full office action

Prosecution Timeline

Apr 03, 2025
Application Filed
Sep 23, 2026
Non-Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12743679
SYSTEMS AND METHODS FOR TEMPLATE IMAGE EDITS
2y 5m to grant Granted Sep 22, 2026
Patent 12743795
Determining Object Structure Using Camera Devices With Views Of Moving Objects
2y 4m to grant Granted Sep 22, 2026
Patent 12718420
INFORMATION PROCESSING DEVICE AND METHOD
2y 2m to grant Granted Aug 25, 2026
Patent 12675993
AUGMENTED, VIRTUAL AND MIXED-REALITY CONTENT SELECTION & DISPLAY FOR BANK NOTE
4y 4m to grant Granted Jul 07, 2026
Patent 12670628
COMPOSITIONAL IMAGE GENERATION AND MANIPULATION
2y 9m to grant Granted Jun 30, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

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

Prosecution Projections

1-2
Expected OA Rounds
84%
Grant Probability
99%
With Interview (+16.0%)
2y 3m (~9m remaining)
Median Time to Grant
Low
PTA Risk
Based on 464 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

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

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

Free tier: 3 strategy analyses per month