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 .
This communication is in response to Application No. 18/989,624 filed 12/20/2024. Claims 1-30 are pending.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 03/20/2025, 06/24/2025, and 10/10/2025 have been entered and considered. Initialed copies of the PTO-1449 by the examiner are attached.
Specification
The disclosure is objected to because of the following informalities:
At line 3 of paragraph [0036] should recite, in part, “and which data units shall not be used as a reference” to avoid typographical and/or clarity issues.
Appropriate correction is required.
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.
Claim 30 recite limitations that use words like “means” (or “step”) or similar terms with functional language and do invoke 35 U.S.C. 112(f):
Claim 30; recites the limitation, “device to …,”.
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.
After a careful analysis, as disclosed above, and a careful review of the specification the following limitations in claim 30:
“device” (Fig. 1, #102, #116. Paragraph [0038]- “Source device 102 and destination device 116 may comprise any of a wide range of devices, including desktop computers, notebook (i.e., laptop) computers, tablet computers, set-top boxes, telephone handsets such as smartphones, televisions, cameras, display devices, digital media players, video gaming consoles, video streaming devices, terrestrial or marine vehicles, spacecraft, aircraft, robots, LIDAR devices, satellites, or the like” thus, have sufficient structure or material wherein is any kind of LIDAR, smartphone, etc.).
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.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-5, 9-14, 18-21, 24-26, 29 and 30 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hannuksela (US 20230276073 A1, hereinafter referred to as “Hannuksela”).
Regarding claim 1, Hannuksela teaches a method of decoding point cloud data (“a source volume of a volumetric image, such as a point cloud frame, may be projected onto one or more projection surfaces... In other words, a three-dimensional (3D) scene model, comprising geometry primitives such as mesh elements, points, and/or voxel, is projected onto one or more projection surfaces. These projection surface geometries may be “unfolded” onto 2D planes (typically two planes per projected source volume: one for texture, one for depth). The “unfolding” may include determination of patches. 2D planes may then be encoded using standard 2D image or video compression technologies. Relevant projection geometry information may be transmitted alongside the encoded video files to the decoder. The decoder may then decode the coded image/video sequence and perform the inverse projection to regenerate the 3D scene model object in any desired representation format, which may be different from the starting format e.g. reconstructing a point cloud from original mesh model data” Hannuksela, [0262]), the method comprising:
determining a type-length-value (TLV) type of a current data unit of the point cloud data, the TLV type being indicative of a reference status of the current data unit (“The bitstream syntax of coding formats or standards may indicate whether a particular picture is a reference picture for inter prediction of any other picture. In many coding formats or standards, pictures of any coding type (I, P, B) can be reference pictures or non-reference pictures. One or more syntax structures for (decoded) reference picture marking may exist in a video coding system. An encoder generates an instance of a syntax structure e.g. in each coded picture, and a decoder decodes an instance of the syntax structure e.g. from each coded picture. For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0175]-[0176]);
determining, based on the TLV type, the reference status (“For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]); and
decoding the current data unit in accordance the reference status (“For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]).
Regarding claim 2, Hannuksela teaches the method of claim 1, wherein the reference status comprises the current data unit is eligible to be used for reference, the current data unit is not eligible to be used for reference, the current data unit shall be used for reference, or the current data unit shall not be used for reference (“For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]).
Regarding claim 3, Hannuksela teaches the method of claim 1, further comprising storing the current data unit in accordance with the reference status (“A Decoded Picture Buffer (DPB) may be used in the encoder and/or in the decoder. There are two reasons to buffer decoded pictures, for references in inter prediction and for reordering decoded pictures into output order... Hence, the DPB may include a unified decoded picture buffering process for reference pictures and output reordering. A decoded picture may be removed from the DPB when it is no longer used as a reference and is not needed for output” Hannuksela, [0183]).
Regarding claim 4, Hannuksela teaches the method of claim 3, wherein the reference status is indicative of the current data unit being used for reference, and wherein the method further comprises: storing the current data unit until a point in time that occurs after a current frame of the point cloud data is output from a storage buffer (“the DPB may include a unified decoded picture buffering process for reference pictures and output reordering. A decoded picture may be removed from the DPB when it is no longer used as a reference and is not needed for output” Hannuksela, [0183]; “A parameter set may be activated by a reference from an image segment, such as from a slice, or from another active parameter set or in some cases from another syntax structure such as a buffering period SEI [supplemental enhancement information] message” Hannuksela, [0166]).
Regarding claim 5, Hannuksela teaches the method of claim 3, wherein the reference status is indicative of the current data unit not being used for reference, and wherein the method further comprises: storing the current data unit until a current frame of the point cloud data is output from a storage buffer; and deleting or overwriting the current data unit such that the current data unit cannot be used as a reference for a future frame of the point cloud data (“the DPB may include a unified decoded picture buffering process for reference pictures and output reordering. A decoded picture may be removed from the DPB when it is no longer used as a reference and is not needed for output” Hannuksela, [0183]).
Regarding claim 9, Hannuksela teaches the method of claim 1, further comprising: based on the TLV type, determine at least one of a) a prediction type used for the current data unit, b) a prediction type used for a current frame of the point cloud data, the current frame including the current data unit, c) that the current data unit is an I-data unit, a P-data unit, or a B-data unit, d) that the current frame is an I-frame, a P-frame, or a B-frame, or e) that one or more particular syntax elements are signaled in a bitstream (“A Decoded Picture Buffer (DPB) may be used in the encoder and/or in the decoder. There are two reasons to buffer decoded pictures, for references in inter prediction and for reordering decoded pictures into output order... Hence, the DPB may include a unified decoded picture buffering process for reference pictures and output reordering. A decoded picture may be removed from the DPB when it is no longer used as a reference and is not needed for output” Hannuksela, [0183]; “For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]).
Regarding claim 10, Hannuksela teaches a device for decoding point cloud data, the device comprising (“electronic device 50 may for example be a mobile terminal or user equipment of a wireless communication system... any electronic device or apparatus which may require encoding and decoding or encoding or decoding video images” Hannuksela, [0046]):
one or more memories configured to store the point cloud data (“The recording storage 1570 may comprise any type of mass memory to store the coded media bitstream. The recording storage 1570 may alternatively or additively comprise computation memory, such as random access memory” Hannuksela, [0525]): and
one or more processors operatively coupled to the one or more memories, the one or more processors configured to (“implemented by computer software executable by a data processor of the mobile device, such as in the processor entity, or by hardware, or by a combination of software and hardware” Hannuksela, [0542]):
determine a type-length-value (TLV) type of a current data unit of the point cloud data, the TLV type being indicative of a reference status of the current data unit (“The bitstream syntax of coding formats or standards may indicate whether a particular picture is a reference picture for inter prediction of any other picture. In many coding formats or standards, pictures of any coding type (I, P, B) can be reference pictures or non-reference pictures. One or more syntax structures for (decoded) reference picture marking may exist in a video coding system. An encoder generates an instance of a syntax structure e.g. in each coded picture, and a decoder decodes an instance of the syntax structure e.g. from each coded picture. For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0175]-[0176]);
determine, based on the TLV type, the reference status (“For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]); and
decode the current data unit in accordance the reference status (“For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]).
Regarding claim 11, Hannuksela teaches the device of claim 10, wherein the reference status comprises the current data unit is eligible to be used for reference, the current data unit is not eligible to be used for reference, the current data unit shall be used for reference, or the current data unit shall not be used for reference (“For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]).
Regarding claim 12, Hannuksela teaches the device of claim 10, wherein the one or more processors are further configured to store the current data unit in the one or more memories in accordance with the reference status (“A Decoded Picture Buffer (DPB) may be used in the encoder and/or in the decoder. There are two reasons to buffer decoded pictures, for references in inter prediction and for reordering decoded pictures into output order... Hence, the DPB may include a unified decoded picture buffering process for reference pictures and output reordering. A decoded picture may be removed from the DPB when it is no longer used as a reference and is not needed for output” Hannuksela, [0183]).
Regarding claim 13, Hannuksela teaches the device of claim 12, wherein the reference status is indicative of the current data unit being used for reference, and wherein the one or more processors are configured to: store the current data unit in the one or more memories until a point in time that occurs after a current frame of the point cloud data is output from a storage buffer (“the DPB may include a unified decoded picture buffering process for reference pictures and output reordering. A decoded picture may be removed from the DPB when it is no longer used as a reference and is not needed for output” Hannuksela, [0183]; “A parameter set may be activated by a reference from an image segment, such as from a slice, or from another active parameter set or in some cases from another syntax structure such as a buffering period SEI [supplemental enhancement information] message” Hannuksela, [0166]).
Regarding claim 14, Hannuksela teaches the device of claim 12, wherein the reference status is indicative of the current data unit not being used for reference, and wherein the one or more processors are configured to: store the current data unit in the one or more memories until a current frame of the point cloud data is output from a storage buffer; and delete or overwrite the current data unit in the one or more memories such that the current data unit cannot be used as a reference for a future frame of the point cloud data (“the DPB may include a unified decoded picture buffering process for reference pictures and output reordering. A decoded picture may be removed from the DPB when it is no longer used as a reference and is not needed for output” Hannuksela, [0183]).
Regarding claim 18, Hannuksela teaches the device of claim 10, wherein the one or more processors are further configured to: determine, based on the TLV type, at least one of a) a prediction type used for the current data unit, b) a prediction type used for a current frame of the point cloud data, the current frame including the current data unit, c) that the current data unit is an I-data unit, a P-data unit, or a B-data unit, d) that the current frame is an I-frame, a P-frame, or a B-frame, or e) that one or more particular syntax elements are signaled in a bitstream (“A Decoded Picture Buffer (DPB) may be used in the encoder and/or in the decoder. There are two reasons to buffer decoded pictures, for references in inter prediction and for reordering decoded pictures into output order... Hence, the DPB may include a unified decoded picture buffering process for reference pictures and output reordering. A decoded picture may be removed from the DPB when it is no longer used as a reference and is not needed for output” Hannuksela, [0183]; “For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]).
Regarding claim 19, Hannuksela teaches the device of claim 10, further comprising a display to present imagery based on the point cloud data (display, Hannuksela, Fig. 3 #20, #22, #14 and #16).
Regarding claim 20, Hannuksela teaches a method of encoding point cloud data, the method comprising (“a source volume of a volumetric image, such as a point cloud frame, may be projected onto one or more projection surfaces... In other words, a three-dimensional (3D) scene model, comprising geometry primitives such as mesh elements, points, and/or voxel, is projected onto one or more projection surfaces. These projection surface geometries may be “unfolded” onto 2D planes (typically two planes per projected source volume: one for texture, one for depth). The “unfolding” may include determination of patches. 2D planes may then be encoded using standard 2D image or video compression technologies. Relevant projection geometry information may be transmitted alongside the encoded video files to the decoder. The decoder may then decode the coded image/video sequence and perform the inverse projection to regenerate the 3D scene model object in any desired representation format, which may be different from the starting format e.g. reconstructing a point cloud from original mesh model data” Hannuksela, [0262]):
determining a reference status of a current data unit of the point cloud data (“The bitstream syntax of coding formats or standards may indicate whether a particular picture is a reference picture for inter prediction of any other picture. In many coding formats or standards, pictures of any coding type (I, P, B) can be reference pictures or non-reference pictures. One or more syntax structures for (decoded) reference picture marking may exist in a video coding system. An encoder generates an instance of a syntax structure e.g. in each coded picture, and a decoder decodes an instance of the syntax structure e.g. from each coded picture. For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0175]-[0176]);
determining, based on the reference status, a type-length-value (TLV) type of the current data unit, the TLV type being indicative of the reference status (“One or more syntax structures for (decoded) reference picture marking may exist in a video coding system. An encoder generates an instance of a syntax structure e.g. in each coded picture, and a decoder decodes an instance of the syntax structure e.g. from each coded picture. For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]); and
encoding the current data unit in accordance with the TLV type (“An encoder generates an instance of a syntax structure e.g. in each coded picture, and a decoder decodes an instance of the syntax structure e.g. from each coded picture. For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]).
Regarding claim 21, Hannuksela teaches the method of claim 20, wherein the reference status comprises the current data unit is eligible to be used for reference, the current data unit is not eligible to be used for reference, the current data unit shall be used for reference, or the current data unit shall not be used for reference (“For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]).
Regarding claim 24, Hannuksela teaches the method of claim 20, further comprising: determining at least one of a) a prediction type used for the current data unit, b) a prediction type used for a current frame of the point cloud data, the current frame including the current data unit, c) that the current data unit is an I-data unit, a P-data unit, or a B-data unit, d) that the current frame is an I-frame, a P-frame, or a B-frame, or e) that one or more particular syntax elements are to be signaled in a bitstream (“A Decoded Picture Buffer (DPB) may be used in the encoder and/or in the decoder. There are two reasons to buffer decoded pictures, for references in inter prediction and for reordering decoded pictures into output order... Hence, the DPB may include a unified decoded picture buffering process for reference pictures and output reordering. A decoded picture may be removed from the DPB when it is no longer used as a reference and is not needed for output” Hannuksela, [0183]; “For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]); and
determining, based on the at least one of a) the prediction type used for the current data unit, b) the prediction type used for the current frame of the point cloud data, c) that the current data unit is the I-data unit, the P-data unit, or the B-data unit, d) that the current frame is the I-frame, the P-frame, or the B-frame, or e) that one or more particular syntax elements are to be signaled in the bitstream, a TLV type for the current data unit (“A Decoded Picture Buffer (DPB) may be used in the encoder and/or in the decoder. There are two reasons to buffer decoded pictures, for references in inter prediction and for reordering decoded pictures into output order... Hence, the DPB may include a unified decoded picture buffering process for reference pictures and output reordering. A decoded picture may be removed from the DPB when it is no longer used as a reference and is not needed for output” Hannuksela, [0183]; “For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]).
Regarding claim 25, Hannuksela teaches a device for encoding point cloud data, the device comprising (“electronic device 50 may for example be a mobile terminal or user equipment of a wireless communication system... any electronic device or apparatus which may require encoding and decoding or encoding or decoding video images” Hannuksela, [0046]):
one or more memories configured to store the point cloud data (“The recording storage 1570 may comprise any type of mass memory to store the coded media bitstream. The recording storage 1570 may alternatively or additively comprise computation memory, such as random access memory” Hannuksela, [0525]): and
one or more processors operatively coupled to the one or more memories, the one or more processors configured to (“implemented by computer software executable by a data processor of the mobile device, such as in the processor entity, or by hardware, or by a combination of software and hardware” Hannuksela, [0542]):
determine a reference status of a current data unit of the point cloud data (“The bitstream syntax of coding formats or standards may indicate whether a particular picture is a reference picture for inter prediction of any other picture. In many coding formats or standards, pictures of any coding type (I, P, B) can be reference pictures or non-reference pictures. One or more syntax structures for (decoded) reference picture marking may exist in a video coding system. An encoder generates an instance of a syntax structure e.g. in each coded picture, and a decoder decodes an instance of the syntax structure e.g. from each coded picture. For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0175]-[0176]);
determine, based on the reference status, a type-length-value (TLV) type of the current data unit, the TLV type being indicative of the reference status (“One or more syntax structures for (decoded) reference picture marking may exist in a video coding system. An encoder generates an instance of a syntax structure e.g. in each coded picture, and a decoder decodes an instance of the syntax structure e.g. from each coded picture. For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]); and
encode the current data unit in accordance with the TLV type (“An encoder generates an instance of a syntax structure e.g. in each coded picture, and a decoder decodes an instance of the syntax structure e.g. from each coded picture. For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]).
Regarding claim 26, Hannuksela teaches the device of claim 25, wherein the reference status comprises the current data unit is eligible to be used for reference, the current data unit is not eligible to be used for reference, the current data unit shall be used for reference, or the current data unit shall not be used for reference (“For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]).
Regarding claim 29, Hannuksela teaches the device of claim 25, wherein the one or more processors are further configured to: determine at least one of a) a prediction type used for the current data unit, b) a prediction type used for a current frame of the point cloud data, the current frame including the current data unit, c) that the current data unit is an I-data unit, a P-data unit, or a B-data unit, d) that the current frame is an I-frame, a P-frame, or a B-frame, or e) that one or more particular syntax elements are to be signaled in a bitstream (“A Decoded Picture Buffer (DPB) may be used in the encoder and/or in the decoder. There are two reasons to buffer decoded pictures, for references in inter prediction and for reordering decoded pictures into output order... Hence, the DPB may include a unified decoded picture buffering process for reference pictures and output reordering. A decoded picture may be removed from the DPB when it is no longer used as a reference and is not needed for output” Hannuksela, [0183]; “For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]); and
determine, based on the at least one of a) the prediction type used for the current data unit, b) the prediction type used for the current frame of the point cloud data, c) that the current data unit is the I-data unit, the P-data unit, or the B-data unit, d) that the current frame is the I-frame, the P-frame, or the B-frame, or e) that one or more particular syntax elements are to be signaled in the bitstream, a TLV type for the current data unit (“A Decoded Picture Buffer (DPB) may be used in the encoder and/or in the decoder. There are two reasons to buffer decoded pictures, for references in inter prediction and for reordering decoded pictures into output order... Hence, the DPB may include a unified decoded picture buffering process for reference pictures and output reordering. A decoded picture may be removed from the DPB when it is no longer used as a reference and is not needed for output” Hannuksela, [0183]; “For example, the decoding of the syntax structure may cause pictures to be adaptively marked as “used for reference” or “unused for reference”” Hannuksela, [0176]).
Regarding claim 30, Hannuksela teaches the device of claim 25, further comprising a device to generate the point cloud data (“Infrared, laser, time-of-flight and structured light technologies are examples of how such content may be constructed” Hannuksela, [0247]).
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) 6-8, 15-17, 22, 23, 27 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Hannuksela in view of Ramasubramonian et al. (WO 2024015901 A1, hereinafter referred to as “Ramasubramonian”) and in further view of OH et al. (US 20230388557 A1, hereinafter referred to as “OH”).
Regarding claim 6, Hannuksela teaches the method of claim 1, Hannuksela fails to explicitly teach determining to perform spherical coordinate conversion on the current data unit; determining a spherical coordinate for geometry of the current data unit; determining a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry; and decoding the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute.
However, Ramasubramonian teaches determining to perform spherical coordinate conversion on the current data unit; determining a spherical coordinate for geometry of the current data unit (“Motion compensation for inter prediction in predictive geometry coding (e.g., G- PCC coding) may include a step to convert the coordinates of a point from the Cartesian coordinates (e.g., (x, y, z)) to the spherical coordinates (e.g., (r, phi, i) as discussed above. In one example, G-PCC encoder 200 and G-PCC decoder 300 may be configured to perform a Cartesian to spherical (CartesianToSpherical)” Ramasubramonian, [0140]);
determining a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry (“According to the techniques of this disclosure, G-PCC encoder 200 and G-PCC decoder 300 may be configured to derive an azimuth value from Cartesian coordinates using a fixed-point implementation that includes applying a variable scale factor (or a variable shift). In some examples, the fixed-point implementation may further include applying an offset value associated with the scale factor (shift) before applying the scaling (shift)” Ramasubramonian, [0141]); and
decoding the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute (“Motion compensation for inter prediction in predictive geometry coding (e.g., G- PCC coding) may include a step to convert the coordinates of a point from the Cartesian coordinates (e.g., (x, y, z)) to the spherical coordinates (e.g., (r, phi, i) as discussed above. In one example, G-PCC encoder 200 and G-PCC decoder 300 may be configured to perform a Cartesian to spherical (CartesianToSpherical)... G-PCC use a fixed- point/integer implementation to convert from Cartesian coordinates to spherical coordinates (convertXyzToRpl) in the attribute coding process” Ramasubramonian, [0140]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to combine the teachings of Hannuksela of having a method of decoding point cloud data, the method comprising: determining a type-length-value (TLV) type of a current data unit of the point cloud data, the TLV type being indicative of a reference status of the current data unit, with the teachings of Ramasubramonian of having determining to perform spherical coordinate conversion on the current data unit; determining a spherical coordinate for geometry of the current data unit; determining a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry; and decoding the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute.
Wherein having Hannuksela’s coding method determining to perform spherical coordinate conversion on the current data unit; determining a spherical coordinate for geometry of the current data unit; determining a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry; and decoding the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute.
The motivation behind the modification would have been to obtain a coding and decoding method that provides syntax structure to apply to bitstreams, since both Hannuksela and Ramasubramonian are methods for coding and decoding of bitstreams such as point clouds. Wherein Hannuksela reduces the viewport quality update delay when a viewing orientation changes (e.g., the streaming bitrate of Virtual Reality video) by merging coded tile rectangles or tile sets from a first Representation having relatively long stream access point (SAP) intervals and from one or more second Representations having more frequent SAPs, while Ramasubramonian more accurately converts Cartesian coordinates to an azimuth value in a fixed-point implementation and increases coding efficiency by using variable shift value based on the number of bits used to encode the azimuth. Please see Hannuksela (US 20230276073 A1), Paragraph [0003] and Ramasubramonian et al. (WO 2024015901 A1), Paragraph [0006].
Hannuksela in view of Ramasubramonian fail to explicitly teach wherein the scale-offset computation is constrained to be a power of 2.
However, OH teaches wherein the scale-offset computation is constrained to be a power of 2 (“shift each axis to start from the origin such that projected point cloud data (e.g., geometry) has a positive value, or may correct the length of each axis to be a power of 2” OH, [0345]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to combine the teachings of Hannuksela of having a method of decoding point cloud data, the method comprising: determining a type-length-value (TLV) type of a current data unit of the point cloud data, the TLV type being indicative of a reference status of the current data unit, with the teachings of OH of having wherein the scale-offset computation is constrained to be a power of 2.
Wherein having Hannuksela’s coding method wherein the scale-offset computation is constrained to be a power of 2.
The motivation behind the modification would have been to obtain a coding and decoding method that provides syntax structure to apply to bitstreams, since both Hannuksela and OH are methods for coding and decoding of bitstreams such as point clouds. Wherein Hannuksela reduces the viewport quality update delay when a viewing orientation changes (e.g., the streaming bitrate of Virtual Reality video) by merging coded tile rectangles or tile sets from a first Representation having relatively long stream access point (SAP) intervals and from one or more second Representations having more frequent SAPs, while OH improves coding performance of attribute coding as well as increase the compression efficiency of the geometry by applying an improved coordinate system in prediction-based geometry coding. Please see Hannuksela (US 20230276073 A1), Paragraph [0003] and OH et al. (US 20230388557 A1), Paragraph [0689 and 0028].
Regarding claim 7, Hannuksela in view of Ramasubramonian and in further view of OH teach the method of claim 6, Hannuksela in view of OH fail to explicitly teach further comprising parsing a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value.
However, Ramasubramonian teaches further comprising parsing a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value (“In one example, to derive the azimuth value using the fixed-point implementation, G-PCC decoder 300 may derive the variable shift value based on a number of bits for coding the azimuth value. For example, G-PCC decoder 300 may derive the variable shift value according to a function: sh = 44 - (azimLog2 - 1), wherein sh is the variable shift value and azimLog2 is the number of bits for coding the azimuth value. In some examples, G-PCC decoder 300 may decode a syntax element indicating a value of azimLog2.” Ramasubramonian, [0154]; “G-PCC encoder 200 and G-PCC decoder 300 may further determine a shift value (sh) using the function int sh = 44 - (azimLog2 - 1). The shift value sh is based on the variable azimLog2, which indicates the number of bits used to code the azimuth value. Accordingly, the shift value is indicative of a scaling factor. For example, the scaling factor is l/(2.sup.sh)” Ramasubramonian, [0144]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to combine the teachings of Hannuksela of having a method of decoding point cloud data, the method comprising: determining a type-length-value (TLV) type of a current data unit of the point cloud data, the TLV type being indicative of a reference status of the current data unit, with the teachings of Ramasubramonian of having further comprising parsing a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value.
Wherein having Hannuksela’s coding method further comprising parsing a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value.
The motivation behind the modification would have been to obtain a coding and decoding method that provides syntax structure to apply to bitstreams, since both Hannuksela and Ramasubramonian are methods for coding and decoding of bitstreams such as point clouds. Wherein Hannuksela reduces the viewport quality update delay when a viewing orientation changes (e.g., the streaming bitrate of Virtual Reality video) by merging coded tile rectangles or tile sets from a first Representation having relatively long stream access point (SAP) intervals and from one or more second Representations having more frequent SAPs, while Ramasubramonian more accurately converts Cartesian coordinates to an azimuth value in a fixed-point implementation and increases coding efficiency by using variable shift value based on the number of bits used to encode the azimuth. Please see Hannuksela (US 20230276073 A1), Paragraph [0003] and Ramasubramonian et al. (WO 2024015901 A1), Paragraph [0006].
Regarding claim 8, Hannuksela in view of Ramasubramonian and in further view of OH teach the method of claim 6, Hannuksela in view of Ramasubramonian fail to explicitly teach wherein the current data unit is a first current data unit, the method further comprising: determining that a resultant scale value for a scale-offset computation for a second current data unit is equal to or greater than one; based on the resultant scale value being equal to or greater than one, determining not to perform spherical coordinate conversion on the second current data unit; and decoding the second current data unit without performing spherical coordinate conversion on the second current data unit.
However, OH teaches wherein the current data unit is a first current data unit, the method further comprising: determining that a resultant scale value for a scale-offset computation for a second current data unit is equal to or greater than one; based on the resultant scale value being equal to or greater than one, determining not to perform spherical coordinate conversion on the second current data unit (“The point cloud transmission device according to the embodiments may change positions of points based on scaling parameters (or referred to as scale factors or scale values) for each axis according to the distribution of the points. Also, when the value of the scaling parameter for each axis is greater than 1, the positions of the projected points may be more sparsely distributed than the positions of the points before the projection. On the other hand, when the value of the scaling parameter for each axis is less than 1, the positions of the projected points may be more densely distributed than the positions of the points before the projection” OH, [0703]); and
decoding the second current data unit without performing spherical coordinate conversion on the second current data unit (“when the value of the attr_coord_conv_enabled_flag field is 1, the point cloud reception device may perform coordinate conversion pre-process 4810 as a pre-process for attribute decoding” OH, [0705]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to combine the teachings of Hannuksela of having a method of decoding point cloud data, the method comprising: determining a type-length-value (TLV) type of a current data unit of the point cloud data, the TLV type being indicative of a reference status of the current data unit, with the teachings of OH of having wherein the current data unit is a first current data unit, the method further comprising: determining that a resultant scale value for a scale-offset computation for a second current data unit is equal to or greater than one; based on the resultant scale value being equal to or greater than one, determining not to perform spherical coordinate conversion on the second current data unit; and decoding the second current data unit without performing spherical coordinate conversion on the second current data unit.
Wherein having Hannuksela’s coding method wherein the current data unit is a first current data unit, the method further comprising: determining that a resultant scale value for a scale-offset computation for a second current data unit is equal to or greater than one; based on the resultant scale value being equal to or greater than one, determining not to perform spherical coordinate conversion on the second current data unit; and decoding the second current data unit without performing spherical coordinate conversion on the second current data unit.
The motivation behind the modification would have been to obtain a coding and decoding method that provides syntax structure to apply to bitstreams, since both Hannuksela and OH are methods for coding and decoding of bitstreams such as point clouds. Wherein Hannuksela reduces the viewport quality update delay when a viewing orientation changes (e.g., the streaming bitrate of Virtual Reality video) by merging coded tile rectangles or tile sets from a first Representation having relatively long stream access point (SAP) intervals and from one or more second Representations having more frequent SAPs, while OH improves coding performance of attribute coding as well as increase the compression efficiency of the geometry by applying an improved coordinate system in prediction-based geometry coding. Please see Hannuksela (US 20230276073 A1), Paragraph [0003] and OH et al. (US 20230388557 A1), Paragraph [0689 and 0028].
Regarding claim 15, Hannuksela teaches the device of claim 10, Hannuksela fails to explicitly teach determining to perform spherical coordinate conversion on the current data unit; determining a spherical coordinate for geometry of the current data unit; determining a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry; and decoding the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute.
However, Ramasubramonian teaches determining to perform spherical coordinate conversion on the current data unit; determining a spherical coordinate for geometry of the current data unit (“Motion compensation for inter prediction in predictive geometry coding (e.g., G- PCC coding) may include a step to convert the coordinates of a point from the Cartesian coordinates (e.g., (x, y, z)) to the spherical coordinates (e.g., (r, phi, i) as discussed above. In one example, G-PCC encoder 200 and G-PCC decoder 300 may be configured to perform a Cartesian to spherical (CartesianToSpherical)” Ramasubramonian, [0140]);
determining a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry (“According to the techniques of this disclosure, G-PCC encoder 200 and G-PCC decoder 300 may be configured to derive an azimuth value from Cartesian coordinates using a fixed-point implementation that includes applying a variable scale factor (or a variable shift). In some examples, the fixed-point implementation may further include applying an offset value associated with the scale factor (shift) before applying the scaling (shift)” Ramasubramonian, [0141]); and
decoding the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute (“Motion compensation for inter prediction in predictive geometry coding (e.g., G- PCC coding) may include a step to convert the coordinates of a point from the Cartesian coordinates (e.g., (x, y, z)) to the spherical coordinates (e.g., (r, phi, i) as discussed above. In one example, G-PCC encoder 200 and G-PCC decoder 300 may be configured to perform a Cartesian to spherical (CartesianToSpherical)... G-PCC use a fixed- point/integer implementation to convert from Cartesian coordinates to spherical coordinates (convertXyzToRpl) in the attribute coding process” Ramasubramonian, [0140]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to combine the teachings of Hannuksela of having a device for decoding point cloud data, the device comprising: one or more memories configured to store the point cloud data: and one or more processors operatively coupled to the one or more memories, the one or more processors configured to: determine a type-length-value (TLV) type of a current data unit of the point cloud data, the TLV type being indicative of a reference status of the current data unit, with the teachings of Ramasubramonian of having determining to perform spherical coordinate conversion on the current data unit; determining a spherical coordinate for geometry of the current data unit; determining a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry; and decoding the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute.
Wherein having Hannuksela’s coding method determining to perform spherical coordinate conversion on the current data unit; determining a spherical coordinate for geometry of the current data unit; determining a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry; and decoding the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute.
The motivation behind the modification would have been to obtain a coding and decoding method that provides syntax structure to apply to bitstreams, since both Hannuksela and Ramasubramonian are methods for coding and decoding of bitstreams such as point clouds. Wherein Hannuksela reduces the viewport quality update delay when a viewing orientation changes (e.g., the streaming bitrate of Virtual Reality video) by merging coded tile rectangles or tile sets from a first Representation having relatively long stream access point (SAP) intervals and from one or more second Representations having more frequent SAPs, while Ramasubramonian more accurately converts Cartesian coordinates to an azimuth value in a fixed-point implementation and increases coding efficiency by using variable shift value based on the number of bits used to encode the azimuth. Please see Hannuksela (US 20230276073 A1), Paragraph [0003] and Ramasubramonian et al. (WO 2024015901 A1), Paragraph [0006].
Hannuksela in view of Ramasubramonian fail to explicitly teach wherein the scale-offset computation is constrained to be a power of 2.
However, OH teaches wherein the scale-offset computation is constrained to be a power of 2 (“shift each axis to start from the origin such that projected point cloud data (e.g., geometry) has a positive value, or may correct the length of each axis to be a power of 2” OH, [0345]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to combine the teachings of Hannuksela of having a device for decoding point cloud data, the device comprising: one or more memories configured to store the point cloud data: and one or more processors operatively coupled to the one or more memories, the one or more processors configured to: determine a type-length-value (TLV) type of a current data unit of the point cloud data, the TLV type being indicative of a reference status of the current data unit, with the teachings of OH of having wherein the scale-offset computation is constrained to be a power of 2.
Wherein having Hannuksela’s coding method wherein the scale-offset computation is constrained to be a power of 2.
The motivation behind the modification would have been to obtain a coding and decoding method that provides syntax structure to apply to bitstreams, since both Hannuksela and OH are methods for coding and decoding of bitstreams such as point clouds. Wherein Hannuksela reduces the viewport quality update delay when a viewing orientation changes (e.g., the streaming bitrate of Virtual Reality video) by merging coded tile rectangles or tile sets from a first Representation having relatively long stream access point (SAP) intervals and from one or more second Representations having more frequent SAPs, while OH improves coding performance of attribute coding as well as increase the compression efficiency of the geometry by applying an improved coordinate system in prediction-based geometry coding. Please see Hannuksela (US 20230276073 A1), Paragraph [0003] and OH et al. (US 20230388557 A1), Paragraph [0689 and 0028].
Regarding claim 16, Hannuksela in view of Ramasubramonian and in further view of OH teach the device of claim 15, Hannuksela in view of OH fail to explicitly teach further configured to parse a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value.
However, Ramasubramonian teaches further configured to parse a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value (“In one example, to derive the azimuth value using the fixed-point implementation, G-PCC decoder 300 may derive the variable shift value based on a number of bits for coding the azimuth value. For example, G-PCC decoder 300 may derive the variable shift value according to a function: sh = 44 - (azimLog2 - 1), wherein sh is the variable shift value and azimLog2 is the number of bits for coding the azimuth value. In some examples, G-PCC decoder 300 may decode a syntax element indicating a value of azimLog2.” Ramasubramonian, [0154]; “G-PCC encoder 200 and G-PCC decoder 300 may further determine a shift value (sh) using the function int sh = 44 - (azimLog2 - 1). The shift value sh is based on the variable azimLog2, which indicates the number of bits used to code the azimuth value. Accordingly, the shift value is indicative of a scaling factor. For example, the scaling factor is l/(2.sup.sh)” Ramasubramonian, [0144]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to combine the teachings of Hannuksela of having a device for decoding point cloud data, the device comprising: one or more memories configured to store the point cloud data: and one or more processors operatively coupled to the one or more memories, the one or more processors configured to: determine a type-length-value (TLV) type of a current data unit of the point cloud data, the TLV type being indicative of a reference status of the current data unit, with the teachings of Ramasubramonian of having further configured to parse a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value.
Wherein having Hannuksela’s coding method further configured to parse a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value.
The motivation behind the modification would have been to obtain a coding and decoding method that provides syntax structure to apply to bitstreams, since both Hannuksela and Ramasubramonian are methods for coding and decoding of bitstreams such as point clouds. Wherein Hannuksela reduces the viewport quality update delay when a viewing orientation changes (e.g., the streaming bitrate of Virtual Reality video) by merging coded tile rectangles or tile sets from a first Representation having relatively long stream access point (SAP) intervals and from one or more second Representations having more frequent SAPs, while Ramasubramonian more accurately converts Cartesian coordinates to an azimuth value in a fixed-point implementation and increases coding efficiency by using variable shift value based on the number of bits used to encode the azimuth. Please see Hannuksela (US 20230276073 A1), Paragraph [0003] and Ramasubramonian et al. (WO 2024015901 A1), Paragraph [0006].
Regarding claim 17, Hannuksela teaches the device of claim 10, Hannuksela fails to explicitly teach wherein the current data unit is a first current data unit, and wherein the one or more processors are further configured to: determine that a resultant scale value for a scale-offset computation for a second current data unit is equal to or greater than one; based on the resultant scale value being equal to or greater than one, determine not to perform spherical coordinate conversion on the second current data unit; and decode the second current data unit without performing spherical coordinate conversion on the second current data unit.
However, OH teaches wherein the current data unit is a first current data unit, and wherein the one or more processors are further configured to: determine that a resultant scale value for a scale-offset computation for a second current data unit is equal to or greater than one; based on the resultant scale value being equal to or greater than one, determine not to perform spherical coordinate conversion on the second current data unit (“The point cloud transmission device according to the embodiments may change positions of points based on scaling parameters (or referred to as scale factors or scale values) for each axis according to the distribution of the points. Also, when the value of the scaling parameter for each axis is greater than 1, the positions of the projected points may be more sparsely distributed than the positions of the points before the projection. On the other hand, when the value of the scaling parameter for each axis is less than 1, the positions of the projected points may be more densely distributed than the positions of the points before the projection” OH, [0703]); and
decode the second current data unit without performing spherical coordinate conversion on the second current data unit (“when the value of the attr_coord_conv_enabled_flag field is 1, the point cloud reception device may perform coordinate conversion pre-process 4810 as a pre-process for attribute decoding” OH, [0705]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to combine the teachings of Hannuksela of having a method of decoding point cloud data, the method comprising: determining a type-length-value (TLV) type of a current data unit of the point cloud data, the TLV type being indicative of a reference status of the current data unit, with the teachings of OH of having wherein the current data unit is a first current data unit, and wherein the one or more processors are further configured to: determine that a resultant scale value for a scale-offset computation for a second current data unit is equal to or greater than one; based on the resultant scale value being equal to or greater than one, determine not to perform spherical coordinate conversion on the second current data unit; and decode the second current data unit without performing spherical coordinate conversion on the second current data unit.
Wherein having Hannuksela’s coding method wherein the current data unit is a first current data unit, and wherein the one or more processors are further configured to: determine that a resultant scale value for a scale-offset computation for a second current data unit is equal to or greater than one; based on the resultant scale value being equal to or greater than one, determine not to perform spherical coordinate conversion on the second current data unit; and decode the second current data unit without performing spherical coordinate conversion on the second current data unit.
The motivation behind the modification would have been to obtain a coding and decoding method that provides syntax structure to apply to bitstreams, since both Hannuksela and OH are methods for coding and decoding of bitstreams such as point clouds. Wherein Hannuksela reduces the viewport quality update delay when a viewing orientation changes (e.g., the streaming bitrate of Virtual Reality video) by merging coded tile rectangles or tile sets from a first Representation having relatively long stream access point (SAP) intervals and from one or more second Representations having more frequent SAPs, while OH improves coding performance of attribute coding as well as increase the compression efficiency of the geometry by applying an improved coordinate system in prediction-based geometry coding. Please see Hannuksela (US 20230276073 A1), Paragraph [0003] and OH et al. (US 20230388557 A1), Paragraph [0689 and 0028].
Regarding claim 22, Hannuksela teaches the method of claim 20, Hannuksela fails to explicitly teach determining to perform spherical coordinate conversion on the current data unit; determining a spherical coordinate for geometry of the current data unit; determining a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry; and encoding the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute.
However, Ramasubramonian teaches determining to perform spherical coordinate conversion on the current data unit; determining a spherical coordinate for geometry of the current data unit (“Motion compensation for inter prediction in predictive geometry coding (e.g., G- PCC coding) may include a step to convert the coordinates of a point from the Cartesian coordinates (e.g., (x, y, z)) to the spherical coordinates (e.g., (r, phi, i) as discussed above. In one example, G-PCC encoder 200 and G-PCC decoder 300 may be configured to perform a Cartesian to spherical (CartesianToSpherical)” Ramasubramonian, [0140]);
determining a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry (“According to the techniques of this disclosure, G-PCC encoder 200 and G-PCC decoder 300 may be configured to derive an azimuth value from Cartesian coordinates using a fixed-point implementation that includes applying a variable scale factor (or a variable shift). In some examples, the fixed-point implementation may further include applying an offset value associated with the scale factor (shift) before applying the scaling (shift)” Ramasubramonian, [0141]); and
encoding the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute (“Motion compensation for inter prediction in predictive geometry coding (e.g., G- PCC coding) may include a step to convert the coordinates of a point from the Cartesian coordinates (e.g., (x, y, z)) to the spherical coordinates (e.g., (r, phi, i) as discussed above. In one example, G-PCC encoder 200 and G-PCC decoder 300 may be configured to perform a Cartesian to spherical (CartesianToSpherical)... G-PCC use a fixed- point/integer implementation to convert from Cartesian coordinates to spherical coordinates (convertXyzToRpl) in the attribute coding process” Ramasubramonian, [0140]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to combine the teachings of Hannuksela of having a method of encoding point cloud data, the method comprising: determining a reference status of a current data unit of the point cloud data; determining, based on the reference status, a type-length-value (TLV) type of the current data unit, the TLV type being indicative of the reference status, with the teachings of Ramasubramonian of having determining to perform spherical coordinate conversion on the current data unit; determining a spherical coordinate for geometry of the current data unit; determining a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry; and encoding the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute.
Wherein having Hannuksela’s coding method determining to perform spherical coordinate conversion on the current data unit; determining a spherical coordinate for geometry of the current data unit; determining a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry; and encoding the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute.
The motivation behind the modification would have been to obtain a coding and decoding method that provides syntax structure to apply to bitstreams, since both Hannuksela and Ramasubramonian are methods for coding and decoding of bitstreams such as point clouds. Wherein Hannuksela reduces the viewport quality update delay when a viewing orientation changes (e.g., the streaming bitrate of Virtual Reality video) by merging coded tile rectangles or tile sets from a first Representation having relatively long stream access point (SAP) intervals and from one or more second Representations having more frequent SAPs, while Ramasubramonian more accurately converts Cartesian coordinates to an azimuth value in a fixed-point implementation and increases coding efficiency by using variable shift value based on the number of bits used to encode the azimuth. Please see Hannuksela (US 20230276073 A1), Paragraph [0003] and Ramasubramonian et al. (WO 2024015901 A1), Paragraph [0006].
Hannuksela in view of Ramasubramonian fail to explicitly teach wherein the scale-offset computation is constrained to be a power of 2.
However, OH teaches wherein the scale-offset computation is constrained to be a power of 2 (“shift each axis to start from the origin such that projected point cloud data (e.g., geometry) has a positive value, or may correct the length of each axis to be a power of 2” OH, [0345]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to combine the teachings of Hannuksela of having a method of encoding point cloud data, the method comprising: determining a reference status of a current data unit of the point cloud data; determining, based on the reference status, a type-length-value (TLV) type of the current data unit, the TLV type being indicative of the reference status, with the teachings of OH of having wherein the scale-offset computation is constrained to be a power of 2.
Wherein having Hannuksela’s coding method wherein the scale-offset computation is constrained to be a power of 2.
The motivation behind the modification would have been to obtain a coding and decoding method that provides syntax structure to apply to bitstreams, since both Hannuksela and OH are methods for coding and decoding of bitstreams such as point clouds. Wherein Hannuksela reduces the viewport quality update delay when a viewing orientation changes (e.g., the streaming bitrate of Virtual Reality video) by merging coded tile rectangles or tile sets from a first Representation having relatively long stream access point (SAP) intervals and from one or more second Representations having more frequent SAPs, while OH improves coding performance of attribute coding as well as increase the compression efficiency of the geometry by applying an improved coordinate system in prediction-based geometry coding. Please see Hannuksela (US 20230276073 A1), Paragraph [0003] and OH et al. (US 20230388557 A1), Paragraph [0689 and 0028].
Regarding claim 23, Hannuksela in view of Ramasubramonian and in further view of OH teach the method of claim 22, Hannuksela in view of OH fail to explicitly teach further comprising signaling a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value.
However, Ramasubramonian teaches further comprising signaling a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value (“In one example, to derive the azimuth value using the fixed-point implementation, G-PCC decoder 300 may derive the variable shift value based on a number of bits for coding the azimuth value. For example, G-PCC decoder 300 may derive the variable shift value according to a function: sh = 44 - (azimLog2 - 1), wherein sh is the variable shift value and azimLog2 is the number of bits for coding the azimuth value. In some examples, G-PCC decoder 300 may decode a syntax element indicating a value of azimLog2.” Ramasubramonian, [0154]; “G-PCC encoder 200 and G-PCC decoder 300 may further determine a shift value (sh) using the function int sh = 44 - (azimLog2 - 1). The shift value sh is based on the variable azimLog2, which indicates the number of bits used to code the azimuth value. Accordingly, the shift value is indicative of a scaling factor. For example, the scaling factor is l/(2.sup.sh)” Ramasubramonian, [0144]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to combine the teachings of Hannuksela of having a method of encoding point cloud data, the method comprising: determining a reference status of a current data unit of the point cloud data; determining, based on the reference status, a type-length-value (TLV) type of the current data unit, the TLV type being indicative of the reference status, with the teachings of Ramasubramonian of having further comprising signaling a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value.
Wherein having Hannuksela’s coding method further comprising signaling a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value.
The motivation behind the modification would have been to obtain a coding and decoding method that provides syntax structure to apply to bitstreams, since both Hannuksela and Ramasubramonian are methods for coding and decoding of bitstreams such as point clouds. Wherein Hannuksela reduces the viewport quality update delay when a viewing orientation changes (e.g., the streaming bitrate of Virtual Reality video) by merging coded tile rectangles or tile sets from a first Representation having relatively long stream access point (SAP) intervals and from one or more second Representations having more frequent SAPs, while Ramasubramonian more accurately converts Cartesian coordinates to an azimuth value in a fixed-point implementation and increases coding efficiency by using variable shift value based on the number of bits used to encode the azimuth. Please see Hannuksela (US 20230276073 A1), Paragraph [0003] and Ramasubramonian et al. (WO 2024015901 A1), Paragraph [0006].
Regarding claim 27, Hannuksela teaches the device of claim 25, Hannuksela fails to explicitly teach determine to perform spherical coordinate conversion on the current data unit; determine a spherical coordinate for geometry of the current data unit; determine a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry; and encode the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute.
However, Ramasubramonian teaches determine to perform spherical coordinate conversion on the current data unit;
determine a spherical coordinate for geometry of the current data unit (“Motion compensation for inter prediction in predictive geometry coding (e.g., G- PCC coding) may include a step to convert the coordinates of a point from the Cartesian coordinates (e.g., (x, y, z)) to the spherical coordinates (e.g., (r, phi, i) as discussed above. In one example, G-PCC encoder 200 and G-PCC decoder 300 may be configured to perform a Cartesian to spherical (CartesianToSpherical)” Ramasubramonian, [0140]);
determine a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry (“According to the techniques of this disclosure, G-PCC encoder 200 and G-PCC decoder 300 may be configured to derive an azimuth value from Cartesian coordinates using a fixed-point implementation that includes applying a variable scale factor (or a variable shift). In some examples, the fixed-point implementation may further include applying an offset value associated with the scale factor (shift) before applying the scaling (shift)” Ramasubramonian, [0141]); and
encode the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute (“Motion compensation for inter prediction in predictive geometry coding (e.g., G- PCC coding) may include a step to convert the coordinates of a point from the Cartesian coordinates (e.g., (x, y, z)) to the spherical coordinates (e.g., (r, phi, i) as discussed above. In one example, G-PCC encoder 200 and G-PCC decoder 300 may be configured to perform a Cartesian to spherical (CartesianToSpherical)... G-PCC use a fixed- point/integer implementation to convert from Cartesian coordinates to spherical coordinates (convertXyzToRpl) in the attribute coding process” Ramasubramonian, [0140]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to combine the teachings of Hannuksela of having a device for encoding point cloud data, the device comprising: one or more memories configured to store the point cloud data: and one or more processors operatively coupled to the one or more memories, the one or more processors configured to: determine a reference status of a current data unit of the point cloud data; determine, based on the reference status, a type-length-value (TLV) type of the current data unit, the TLV type being indicative of the reference status, with the teachings of Ramasubramonian of having determine to perform spherical coordinate conversion on the current data unit; determine a spherical coordinate for geometry of the current data unit; determine a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry; and encode the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute.
Wherein having Hannuksela’s coding method determine to perform spherical coordinate conversion on the current data unit; determine a spherical coordinate for geometry of the current data unit; determine a spherical coordinate for an attribute of the current data unit based on performing a scale-offset computation on the spherical coordinate for geometry; and encode the current data unit based on the spherical coordinate for the geometry and the spherical coordinate for the attribute.
The motivation behind the modification would have been to obtain a coding and decoding method that provides syntax structure to apply to bitstreams, since both Hannuksela and Ramasubramonian are methods for coding and decoding of bitstreams such as point clouds. Wherein Hannuksela reduces the viewport quality update delay when a viewing orientation changes (e.g., the streaming bitrate of Virtual Reality video) by merging coded tile rectangles or tile sets from a first Representation having relatively long stream access point (SAP) intervals and from one or more second Representations having more frequent SAPs, while Ramasubramonian more accurately converts Cartesian coordinates to an azimuth value in a fixed-point implementation and increases coding efficiency by using variable shift value based on the number of bits used to encode the azimuth. Please see Hannuksela (US 20230276073 A1), Paragraph [0003] and Ramasubramonian et al. (WO 2024015901 A1), Paragraph [0006].
Hannuksela in view of Ramasubramonian fail to explicitly teach wherein the scale-offset computation is constrained to be a power of 2.
However, OH teaches wherein the scale-offset computation is constrained to be a power of 2 (“shift each axis to start from the origin such that projected point cloud data (e.g., geometry) has a positive value, or may correct the length of each axis to be a power of 2” OH, [0345]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to combine the teachings of Hannuksela of having a device for encoding point cloud data, the device comprising: one or more memories configured to store the point cloud data: and one or more processors operatively coupled to the one or more memories, the one or more processors configured to: determine a reference status of a current data unit of the point cloud data; determine, based on the reference status, a type-length-value (TLV) type of the current data unit, the TLV type being indicative of the reference status, with the teachings of OH of having wherein the scale-offset computation is constrained to be a power of 2.
Wherein having Hannuksela’s coding method wherein the scale-offset computation is constrained to be a power of 2.
The motivation behind the modification would have been to obtain a coding and decoding method that provides syntax structure to apply to bitstreams, since both Hannuksela and OH are methods for coding and decoding of bitstreams such as point clouds. Wherein Hannuksela reduces the viewport quality update delay when a viewing orientation changes (e.g., the streaming bitrate of Virtual Reality video) by merging coded tile rectangles or tile sets from a first Representation having relatively long stream access point (SAP) intervals and from one or more second Representations having more frequent SAPs, while OH improves coding performance of attribute coding as well as increase the compression efficiency of the geometry by applying an improved coordinate system in prediction-based geometry coding. Please see Hannuksela (US 20230276073 A1), Paragraph [0003] and OH et al. (US 20230388557 A1), Paragraph [0689 and 0028].
Regarding claim 28, Hannuksela in view of Ramasubramonian and in further view of OH teach the device of claim 27, Hannuksela in view of OH fail to explicitly teach wherein the one or more processors are further configured to signal a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value.
However, Ramasubramonian teaches further comprising signaling a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value (“In one example, to derive the azimuth value using the fixed-point implementation, G-PCC decoder 300 may derive the variable shift value based on a number of bits for coding the azimuth value. For example, G-PCC decoder 300 may derive the variable shift value according to a function: sh = 44 - (azimLog2 - 1), wherein sh is the variable shift value and azimLog2 is the number of bits for coding the azimuth value. In some examples, G-PCC decoder 300 may decode a syntax element indicating a value of azimLog2.” Ramasubramonian, [0154]; “G-PCC encoder 200 and G-PCC decoder 300 may further determine a shift value (sh) using the function int sh = 44 - (azimLog2 - 1). The shift value sh is based on the variable azimLog2, which indicates the number of bits used to code the azimuth value. Accordingly, the shift value is indicative of a scaling factor. For example, the scaling factor is l/(2.sup.sh)” Ramasubramonian, [0144]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to combine the teachings of Hannuksela of having a device for encoding point cloud data, the device comprising: one or more memories configured to store the point cloud data: and one or more processors operatively coupled to the one or more memories, the one or more processors configured to: determine a reference status of a current data unit of the point cloud data; determine, based on the reference status, a type-length-value (TLV) type of the current data unit, the TLV type being indicative of the reference status, with the teachings of Ramasubramonian of having wherein the one or more processors are further configured to signal a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value.
Wherein having Hannuksela’s coding method wherein the one or more processors are further configured to signal a syntax element indicative of a scale value of the scale-offset computation, wherein the syntax element indicates the scale value as a log 2 of the scale value.
The motivation behind the modification would have been to obtain a coding and decoding method that provides syntax structure to apply to bitstreams, since both Hannuksela and Ramasubramonian are methods for coding and decoding of bitstreams such as point clouds. Wherein Hannuksela reduces the viewport quality update delay when a viewing orientation changes (e.g., the streaming bitrate of Virtual Reality video) by merging coded tile rectangles or tile sets from a first Representation having relatively long stream access point (SAP) intervals and from one or more second Representations having more frequent SAPs, while Ramasubramonian more accurately converts Cartesian coordinates to an azimuth value in a fixed-point implementation and increases coding efficiency by using variable shift value based on the number of bits used to encode the azimuth. Please see Hannuksela (US 20230276073 A1), Paragraph [0003] and Ramasubramonian et al. (WO 2024015901 A1), Paragraph [0006].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Iguchi et al. (US 20230007303 A1) - encoding process that executes a transform process on a numerical value indicated by the attribute information item and encodes the attribute information item or that encodes the attribute information item without executing the transform process, the transform process performing at least one of scaling or offset, the scaling performing at least one of a multiplication and division operation or a shift operation, the offset performing an addition and subtraction operation.
Ramasubramonian et al. (US 20210409714 A1) - A G-PCC encoder and G-PCC decoder may quantize and scale, respectively, a position of a child node. The G-PCC encoder may control the precision of the quantization and scaling using a quantization parameter (QP) value and a parameter value k, wherein the parameter value k specifies a number of QP points per doubling of a scaling step size to be used at the G-PCC decoder.
Hendry et al. (US 20230014844 A1) – a (G-PCC) file including the point cloud data, wherein the G-PCC file includes information on a sample group in which samples in the G-PCC file are grouped based on one or more temporal levels and wherein the G-PCC file further includes information on the temporal levels, and extracting one or more samples belonging to a target temporal level from the samples in the G-PCC file based on the information on the sample group and the information on the temporal levels.
Inquiries
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EMMANUEL SILVA-AVINA whose telephone number is (571)270-0729. The examiner can normally be reached Monday - Friday 11 AM - 8 PM 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, Chineyere Wills-Burns can be reached at (571) 272-9752. 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.
/EMMANUEL SILVA-AVINA/Examiner, Art Unit 2673
/CHINEYERE WILLS-BURNS/Supervisory Patent Examiner, Art Unit 2673
Prosecution Insights