DETAILED ACTION
This action is responsive to the Amendments and Remarks received 12/29/2025 in which claims 3, 15, 18, and 20 are cancelled, claims 1, 10, 11, 14, 17, 19, and 24 are amended, and no claims are added as new claims.
Response to Arguments
On pages 12–13 of the Remarks, Applicant attempts to overcome the rejection under 35 U.S.C. 112(b) by arguing that the distinction between dual tree and local dual tree is that dual tree applies globally whereas local dual tree only applies once the same split tree structure arrives at a certain size wherein the luma component is further split but the chroma component is not. Examiner finds Applicant has provided no evidence that one skilled in the art would interpret dual tree to be in reference to a “global” dual tree as averred. Attorney arguments and conclusory statements unsupported by factual evidence are entitled to little probative value. In re Geisler, 116 F.3d 1465, 1470 (Fed. Cir. 1997). Contrary to Applicant’s argument, and as explained in the preceding Office Action, Examiner finds, consistent with several prior art references cited as evidence, that Applicant’s “local dual tree” is equivalent to the prior art’s “dual tree.” Applicant previously explained, “for a dual tree structure, the split tree structure for the luma component is different from the split tree structure for the chroma component.” Then Applicant explained that local dual tree means that at a certain size, the luma component is split while the chroma is not. Such a definition of local dual tree is the same as Applicant’s definition of dual tree because Applicant’s local dual tree is also a split tree structure for the luma component different from the split tree structure of the chroma component. Examiner finds others in this art use the term, dual tree, to represent the concept that the luma and chroma splits are not the same and such a definition applies to Applicant’s scenario that the reason the splits are not the same is because of a size constraint. Luma is further split, chroma is not. This is how the prior art describes dual tree. Examiner finds explaining this process as local dual tree is unnecessary and suggests there is a difference when there is not. Examiner finds only Applicant uses the term. As a dictionary-type reference, Zhou (US 2022/0021892 A1) explains in paragraph [0169] that in dual tree, when the luma block size reaches a certain size (i.e. 8x8) that means a chroma block in 4:2:0 sampling reaches a minimum size (i.e. 4x4). In that case, for the chroma block but not the luma block, further splitting is not allowed. This is the difference between the prior art’s DUAL_TREE_LUMA and DUAL_TREE_CHROMA (see Zhou, ¶ 0093). It’s fine that Applicant has a name for what happens to the chroma component at a minimum size when dual tree is enabled, but it is not okay to suggest the behavior represents something different than prior art dual tree. By insisting there is a difference between dual tree and local dual tree, Applicant is erroneously suggesting prior art teachings of dual tree do not cover what Applicant is claiming. As Zhou evidences, Applicant’s supposed distinction between dual tree and local dual tree is not immediately comprehensible to the skilled artisan as Applicant’s arguments seem to aver. Indeed, largely only this Applicant utilizes the term in this art while others simply use “dual tree” to describe two separate partitioning structures for splitting luma and chroma (see also ¶ 0088 of Chuang (US 2021/021098 A1)) and then describe the behavior at minimum block sizes like Zhou does. Because the skilled artisan cannot be reasonably certain how to interpret and distinguish between dual tree and local dual tree as recited in Applicant’s claim, the rejection is maintained. See additional reference, Park, cited under the Conclusion Section of this Office Action, illustrating the behavior Applicant describes as “local dual tree” is just “dual tree” to everyone else. Specifically, Part states, “splitting of a chroma block whose size is equal to or smaller than a preset size is not allowed when a splitting tree type indicates a dual tree.” (¶ 0323). This statement of behavior by Park is identical to how Applicant has described Applicant’s “local dual tree” behaves. Accordingly, Examiner is unpersuaded of error.
On page 14 of the Remarks, Applicant contends the amendments to claims 19 and 24 overcome the rejection under 35 U.S.C. 102 because the claims are changed from product-by-process claims to method claims. Examiner agrees the amendments overcome the rejection of claims 19 and 24 under 35 U.S.C. 102, but notes the claims are still rejected under 35 U.S.C. 103. Accordingly, the rejection under 35 U.S.C. 102 is withdrawn.
On page 16 of the Remarks, Applicant contends that because Ye is silent regarding “local dual tree,” Ye is deficient in failing to teach or suggest the features of claim 1. Consistent with Examiner’s findings, articulated supra, regarding local dual tree being equivalent to dual tree in the prior art, Ye’s teachings are not actually deficient for failing to teach local dual tree. See supra, regarding Examiner’s finding that “local dual tree” is a fiction. It is Examiner’s finding that the prior art’s teaching of “dual tree” is equivalent to Applicant’s “local dual tree” as evidenced, supra. This is especially true in view of the prior art’s use of DUAL_TREE_CHROMA in the logic and syntax of the video coding standard. Because Applicant’s “local dual tree” is simply “dual tree” to everyone else, Examiner is unpersuaded that the prior art is deficient for failing to teach “local dual tree” as Applicant avers. Thus, the rejections are sustained.
On page 17 of the Remarks, Applicant contends Ye is deficient because it fails to disclose a relationship between the maximum number of entries in a first palette and a second palette wherein the first palette corresponds to use of single tree and the second palette corresponds to use of dual tree. Examiner disagrees for the reasons stated, infra, in the 35 U.S.C. 103 rejection of the claims. Particularly, and without repeating everything here, Ye teaches or suggests that single tree corresponds to the palette including all three color components (e.g. as triplet entries in the table corresponding to an index value), but that when the next block is dual tree, the palette is not shared among the luma and chroma components, and therefore the luma and chroma palette tables differ from each other. Obviously, a predictor table having only luma values (dual tree) has fewer entries than a table that has luma and chroma values (single tree). When you have to maintain separate palette tables for luma and chroma (dual tree) Examiner finds, consistent with the suggestions of Ye, the skilled artisan would be led to reduce the sizes of the tables in dual tree so that the tables do not consume more memory. For example, assume in single tree mode, where luma and chroma share the same palette, a maximum size is 64. The skilled artisan would understand that without modifying the maximum size of the palette table when dual tree is on, there would be two tables, one for luma and another for chroma, both of which are size 64, which would effectively double the amount of memory required. In order to avoid such a scenario in which the memory usage for palette mode doubles, one skilled in the art would be led to reduce the maximum size of the palettes, perhaps cutting the size in half, so that more memory is not consumed when using dual tree. There might be another reason too, namely that when the palette entries are triplets covering luma and chroma components, there is more variability in the number of possible entries, whereas in dual tree mode when a table only covers, e.g. the luma component, there are fewer possibilities that need to be covered by the table such that larger tables for a single component are less necessary/beneficial. Examiner finds Ye’s teaching of optionally separately handling palette sizes in ¶¶ 0167 and 0185 teaches the above to one skilled in the art. Therefore, Ye’s teachings regarding different palette sizes based on tree type, as articulated infra with respect to the claim rejections under 35 U.S.C. 103, would teach or suggest to one of ordinary skill in the art Applicant’s averred feature. Accordingly, the rejections are sustained.
Other claims are not argued separately. Remarks, 15, 18.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112:
(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.
Claim 10 is rejected under 35 U.S.C. 112(b) 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. Specifically, the second recited feature explains that dual tree is applied to the first video block and local dual tree is applied to the second video block. Examiner finds one skilled in the art would be confused about the difference between dual tree and local dual tree especially when Applicant’s Specification appears to be silent regarding the difference. Examiner requests an explanation with references to the Specification regarding the difference or evidence that particularly establishes the skilled artisan would understand the difference. Notice claim 3 recites “local dual tree” but contrasts it with “single tree.” This is why claim 3 did not create the same issue claim 10 has.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 4–6, 10, 12–14, 16, 17, 19, and 21–24 are rejected under 35 U.S.C. 103 as being unpatentable over Chao et al., “CE15-2: Palette mode of HEVC SCC,” JVET-L0336-v4, 12th Meeting: Macao, CN, Oct. 2018 (herein “Chao”), Ye (US 2020/0092546 A1), and Bross et al., “Versatile Video Coding (Draft 8),” JVET-Q2001-vB, 17th Meeting: Brussels, BE, January 2020 (herein “Bross”).
Regarding claim 1, the combination of Chao, Ye, and Bross teaches or suggests the method of processing video data, comprising: determining, for a conversion between a first video block of a video and a bitstream of the video, that a first prediction mode is applied to the first video block (Chao, Section 1: teaches signaling whether palette prediction mode is used for a block); maintaining a predictor palette table (Chao, Section 1: teaches maintaining a palette table); constructing, in the first prediction mode, a first palette comprising one or more palette predictors for the first video block based on the predictor palette table (Chao, Section 1: teaches the palette colors in the palette table are identified by their index values for a coded block; Examiner interprets Applicant’s “first palette” as Chao’s palette table that is used to code the current block and which is predicted from a palette predictor); and performing the conversion based on the first prediction mode, wherein in the first prediction mode, reconstructed samples of the first video block are represented by a set of representative color values, and the set of representative color values comprises at least one of 1) palette predictors derived from the first palette, 2) escaped samples, or 3) palette information included in the bitstream (Chao, Section 1: teaches palette predictors updated using a current palette; escape symbols for identifying when the color is not in the palette table, but rather explicitly signaled in the bitstream), wherein a first flag relating to coding tool offsets for chroma components is included in a picture parameter set (PPS) in the bitstream (Examiner finds that while Applicant’s Remarks, dated 03/19/2025, describe the first flag to be, for example, the pps_chroma_tool_offsets_present_flag, the name of the flag is arbitrary and it is the function that must be evaluated for obviousness; Bross, pg. 45: teaches a deblocking_filter_control_present_flag, when set to true, allows lower level syntax elements to control chroma deblocking filtering; Bross, pg. 43, Section 7.3.2.4: teaches the flag is in the PPS; Examiner notes Bross, pg. 44, also teaches the pps_chroma_tool_offsets_present_flag and uses that flag to control chroma qp offsets rather than deblocking offsets; Examiner finds that linking qp offsets and deblocking filter offsets using the same enabling syntax element would have advantages and disadvantages according to prevalence of use of qp offsets vs. deblocking filtering offsets; Using one or the other, when the two are linked, would create a disadvantageous linking and the prior art’s choice to control the qp offsets and deblocking offsets separately represents an obvious design choice and not a patentable distinction under 35 U.S.C. 103; Examiner notes another possibility is that the deblocking control syntax structure can be maintained, but could be conditioned initially on a broader application of the pps_chroma_tool_offsets_present_flag, i.e. not strictly limited to chroma qp offsets, but more broadly able to control both chroma qp offsets and chroma deblocking offsets; However, as currently claimed, Applicant is not particularly claiming a syntax hierarchy in which the pps_chroma_tool_offsets_present_flag and the deblocking_filter_control_present_flag have such connection/interplay), wherein whether a first set of syntax elements specifying chroma deblocking parameter offsets are included in the PPS in the bitstream is determined based on a value of the first flag (Examiner finds that while Applicant’s Remarks, dated 03/19/2025, describe the first syntax elements to be, for example, the pps_cb_beta_offset_div2 and pps_cb_tc_offset_div2, the name of the flag is arbitrary and it is the function that must be evaluated for obviousness; Bross, pg. 45, describes the same syntax elements read from the bitstream if the deblocking_filter_control_present_flag is set to true), wherein whether a second set of syntax elements specifying chroma deblocking parameter offsets for a video picture of the video are included in a picture header referring to the PPS is determined based on the value of the first flag (Examiner finds that while Applicant’s Remarks, dated 03/19/2025, describe the second syntax elements to be, for example, the ph_cb_beta_offset_div2 and ph_cb_tc_offset_div2, the name of the flag is arbitrary and it is the function that must be evaluated for obviousness; Bross, pg. 49, describes the same syntax elements read from the bitstream if the deblocking_filter_override_enabled_flag is set to true, which is only possible if the deblocking_filter_control_present_flag is true (see pg. 45)), wherein whether a third set of syntax elements specifying chroma deblocking parameter offsets for a slice of the video picture are included in a slice header referring to the PPS is determined based on the value of the first flag (Examiner finds that while Applicant’s Remarks, dated 03/19/2025, describe the third syntax elements to be, for example, the slice_cb_beta_offset_div2 and slice_cb_tc_offset_div2, the name of the flag is arbitrary and it is the function that must be evaluated for obviousness; Bross, pg. 60, describes the same syntax elements read from the bitstream if the deblocking_filter_override_enabled_flag is set to true, which is only possible if the deblocking_filter_control_present_flag is true (see pg. 45)), wherein the value of the first flag relates to a color format of the video picture (Bross, pg. 115: teaches that when ChromaArrayType is equal to zero, the value of pps_chroma_tool_offsets_present_flag shall be equal to zero), and wherein in case that the first flag has a first value, the first set of syntax elements, the second set of syntax elements, and the third set of syntax elements are not present (As explained, supra, for each of the three sets of syntax elements, the three sets are not parsed if the value of the deblocking_filter_control_present_flag is false; And as explained, supra, Bross’s use of the deblocking_filter_control_present_flag is functionally equivalent to Applicant’s use of the pps_chroma_tool_offsets_present_flag), wherein the first prediction mode is applied to a second video block of the video, and a second palette for the second video block is constructed based on the predictor palette table (Chao, Section 1: teaches the palette is used iteratively for each new video block such that the palette grows until a maximum palette size is reached; Examiner notes Ye also teaches how the palette predictor is constructed as new blocks are encountered for encoding), and wherein a maximum number of entries in the first palette is based on a tree type of the first video block (Chao, Section 1: mentions that palette mode for dual tree works differently than for single tree, i.e. palette mode for dual tree separately treats the luma component and chroma components; However, Chao does not teach in as much detail that which Ye teaches; Ye, ¶¶ 0113–0116: teaches basing palette mode configuration/implementation on tree type; Ye, ¶¶ 0118 and 0145: teaches that when dual tree is on, the palette predictor only keeps the luma sample values and discards the chroma values; Examiner finds this teaching would teach or suggest basing a number of palette entries on tree type; Ye, ¶¶ 0166, 0167, and 0185: In addition to the above teachings, Ye further teaches that the maximum palette size and palette predictor size can be different based on whether the color components are handled together or separately (i.e. whether dual tree is on or off); Ye, ¶ 0209: teaches, “a variable ‘treeType’ specified whether a single or dual tree is used….”), and in case that a single tree is applied to the first video block and a local dual tree is applied to the second video block, the maximum number of entries in the first palette is different from the maximum number of entries in the second palette (see supra regarding Examiner’s finding that Applicant’s “local dual tree” is just prior art “dual tree” and that Applicant essentially made up the term; Citations for dictionary-type references in this Office Action include Zhou, Chuang, and Park; Ye, ¶¶ 0135, 0167, and 0185: teach that updating a palette predictor when the block is dual tree could be handled by only updating the luma values of the palette table and not updating/adding chroma values in the table; Consistent with the language of original claim 4, Examiner interprets the claimed scenario to be that the first block is single tree, which means the palette includes all three color components (e.g. as triplet entries in the table corresponding to an index value), but that when the next block is dual tree, it means the palette is not shared among the luma and chroma components, and therefore the luma and chroma palette tables differ from each other; Ye teaches this in the paragraphs cited for the rejection of the claims; Obviously, a predictor table having only luma values has fewer entries than a table that has luma and chroma values; Examiner notes this is also true when you have to maintain separate palette tables for luma and chroma such that the skilled artisan would be led to reduce the sizes of the tables in dual tree so that the tables do not consume more memory; For example, assume in single tree mode, where luma and chroma share the same palette, a maximum size is 64; The skilled artisan would understand that without modifying the maximum size of the palette table when dual tree is on, there would be two tables, one for luma and another for chroma, both of which are size 64, which would effectively double the amount of memory required; In order to avoid such a scenario in which the memory usage for palette mode doubles, one skilled in the art would be led to reduce the maximum size of the palettes, perhaps cutting the size in half, so that more memory is not consumed when using dual tree; There might be another reason too, namely that when the palette entries are triplets covering luma and chroma components, there is more variability in the number of possible entries, whereas in dual tree mode when a table only covers, e.g. the luma component, there are fewer possibilities that need to be covered by the table such that larger tables for a single component are less necessary/beneficial; Examiner finds Ye’s teaching of optionally separately handling palette sizes in ¶¶ 0167 and 0185 teaches the above to one skilled in the art).
One of ordinary skill in the art, before the effective filing date of the claimed invention, would have been motivated to combine the elements taught by Chao, with those of Ye, because both references are drawn to the same field of endeavor, because the skilled artisan endeavoring to practice the art of palette coding in the state-of-the-art video compression standard would have consulted publications like these to establish an understanding of the technique, and because combining their generic features in a generic way amounts to a mere combination of prior art elements, according to known methods, to yield a predictable result. This rationale applies to all combinations of Chao and Ye used in this Office Action unless otherwise noted.
One of ordinary skill in the art, before the effective filing date of the claimed invention, would have been motivated to combine the elements taught by Chao and Ye, with those of Bross, because all three references are drawn to the same field of endeavor such that one wishing to practice the art of video compression would be led to their teachings, because the skilled artisan endeavoring to practice the art of palette coding in the state-of-the-art video compression standard would have consulted publication Bross’s Draft 8 Standard to establish an understanding of that technique and others, including deblocking filtering, and because combining their generic features in a generic way amounts to a mere combination of prior art elements, according to known methods, to yield a predictable result. This rationale applies to all combinations of Chao, Ye, and Bross used in this Office Action unless otherwise noted.
Regarding claim 2, the combination of Chao, Ye, and Bross teaches or suggests the method of claim 1, wherein the predictor palette table is updated based on the first palette (Chao, Section 1: “After encoding the current CU, the palette predictor will be updated using the current palette…”; Examiner notes Ye also describes how the palette table is constructed).
Regarding claim 3, the combination of Chao, Ye, and Bross teaches or suggests the method of claim 1, wherein the first prediction mode is applied to a second video block of the video, and a second palette for the second video block is constructed based on the predictor palette table (Chao, Section 1: teaches the palette is used iteratively for each new video block such that the palette grows until a maximum palette size is reached; Examiner notes Ye also teaches how the palette predictor is constructed as new blocks are encountered for encoding); and wherein in case that a single tree is applied to the first video block and a local dual tree is applied to the second video block, the maximum number of entries in the first palette is different from the maximum number of entries in the second palette (Ye, ¶¶ 0135, 0167, and 0185: teach that updating a palette predictor when the block is dual tree could be handled by only updating the luma values of the palette table and not updating/adding chroma values in the table; Consistent with the language of original claim 4, Examiner interprets the claimed scenario to be that the first block is single tree, which means the palette includes all three color components (e.g. as triplet entries in the table corresponding to an index value), but that when the next block is dual tree, it means the palette is not shared among the luma and chroma components, and therefore the luma and chroma palette tables differ from each other; Ye teaches this in the paragraphs cited for the rejection of the claims; Next, is the rationale for the rejection of claim 4, which applies here as well: Ye, ¶¶ 0135, 0167, and 0185: teach that updating a palette predictor when the block is dual tree could be handled by only updating the luma values of the palette table and not updating/adding chroma values in the table; Obviously, a predictor table having only luma values has fewer entries than a table that has luma and chroma values; Examiner notes this is also true when you have to maintain separate palette tables for luma and chroma such that the skilled artisan would be led to reduce the sizes of the tables in dual tree so that the tables do not consume more memory; For example, assume in single tree mode, where luma and chroma share the same palette, a maximum size is 64; The skilled artisan would understand that without modifying the maximum size of the palette table when dual tree is on, there would be two tables, one for luma and another for chroma, both of which are size 64, which would effectively double the amount of memory required; In order to avoid such a scenario in which the memory usage for palette mode doubles, one skilled in the art would be led to reduce the maximum size of the palettes, perhaps cutting the size in half, so that more memory is not consumed when using dual tree; There might be another reason too, namely that when the palette entries are triplets covering luma and chroma components, there is more variability in the number of possible entries, whereas in dual tree mode when a table only covers, e.g. the luma component, there are fewer possibilities that need to be covered by the table such that larger tables for a single component are less necessary/beneficial; Examiner finds Ye’s teaching of optionally separately handling palette sizes in ¶¶ 0167 and 0185 teaches the above to one skilled in the art).
Regarding claim 4, the combination of Chao, Ye, and Bross teaches or suggests the method of claim 1, wherein in case that the single tree is applied to the first video block and the local dual tree is applied to the second video block, the maximum number of entries in the second palette is less than the maximum number of entries in the first palette (Ye, ¶¶ 0135, 0167, and 0185: teach that updating a palette predictor when the block is dual tree could be handled by only updating the luma values of the palette table and not updating/adding chroma values in the table; Obviously, a predictor table having only luma values has fewer entries than a table that has luma and chroma values; Examiner notes this is also true when you have to maintain separate palette tables for luma and chroma such that the skilled artisan would be led to reduce the sizes of the tables in dual tree so that the tables do not consume more memory; For example, assume in single tree mode, where luma and chroma share the same palette, a maximum size is 64; The skilled artisan would understand that without modifying the maximum size of the palette table when dual tree is on, there would be two tables, one for luma and another for chroma, both of which are size 64, which would effectively double the amount of memory required; In order to avoid such a scenario in which the memory usage for palette mode doubles, one skilled in the art would be led to reduce the maximum size of the palettes, perhaps cutting the size in half, so that more memory is not consumed when using dual tree; There might be another reason too, namely that when the palette entries are triplets covering luma and chroma components, there is more variability in the number of possible entries, whereas in dual tree mode when a table only covers, e.g. the luma component, there are fewer possibilities that need to be covered by the table such that larger tables for a single component are less necessary/beneficial; Examiner finds Ye’s teaching of optionally separately handling palette sizes in ¶¶ 0167 and 0185 teaches the above to one skilled in the art).
Regarding claim 5, the combination of Chao, Ye, and Bross teaches or suggests the method of claim 4, wherein in case that the single tree is applied to the first video block and the local dual tree is applied to the second video block, the maximum number of entries in the second palette is half of the maximum number of entries in the first palette (Ye, ¶¶ 0135, 0167, and 0185: teach that updating a palette predictor when the block is dual tree could be handled by only updating the luma values of the palette table and not updating/adding chroma values in the table; Obviously, a predictor table having only luma values has fewer entries than a table that has luma and chroma values; Examiner notes this is also true when you have to maintain separate palette tables for luma and chroma such that the skilled artisan would be led to reduce the sizes of the tables in dual tree so that the tables do not consume more memory; For example, assume in single tree mode, where luma and chroma share the same palette, a maximum size is 64; The skilled artisan would understand that without modifying the maximum size of the palette table when dual tree is on, there would be two tables, one for luma and another for chroma, both of which are size 64, which would effectively double the amount of memory required; In order to avoid such a scenario in which the memory usage for palette mode doubles, one skilled in the art would be led to reduce the maximum size of the palettes, perhaps cutting the size in half, so that more memory is not consumed when using dual tree; There might be another reason too, namely that when the palette entries are triplets covering luma and chroma components, there is more variability in the number of possible entries, whereas in dual tree mode when a table only covers, e.g. the luma component, there are fewer possibilities that need to be covered by the table such that larger tables for a single component are less necessary/beneficial; Examiner finds Ye’s teaching of optionally separately handling palette sizes in ¶¶ 0167 and 0185 teaches the above to one skilled in the art).
Regarding claim 6, the combination of Chao, Ye, and Bross teaches or suggests the method of claim 1, wherein the second video block is a luma block, and the second video block has a tree type not equal to single tree and has a slice type not equal to I slice (The rationale already provided for other claim rejections applies here; Examiner notes Ye, ¶¶ 0100 and 0113 teaches that dual tree can be turned on for I slices, but such is not mandatory; In other words, Ye clearly indicates that it is also contemplated that the second video block can be dual tree even when the slice type is not an I slice).
Regarding claim 10, the combination of Chao, Ye, and Bross teaches or suggests the method of claim 1, wherein the first prediction mode is applied to a third video block of the video, and a third palette for the third video block is constructed based on the predictor palette table (Chao, Section 1: teaches the palette colors in the palette table are identified by their index values for a coded block; Examiner interprets Applicant’s “first palette” as Chao’s palette table that is used to code the current block and which is predicted from a palette predictor); and wherein in case that a dual tree is applied to the first video block and a local dual tree is applied to the third video block, the maximum number of entries in the predictor palette table is different for the first video block and the third video block (Examiner notes Applicant’s Specification does not appear to explain how dual tree is different from local dual tree; Examiner is confused about the difference; Ye, ¶¶ 0166, 0167, and 0185: In addition to the above teachings, Ye further teaches that the maximum palette size and palette predictor size can be different based on whether the color components are handled together or separately (i.e. whether dual tree is on or off); Ye, ¶ 0209: teaches, “a variable ‘treeType’ specified whether a single or dual tree is used….”).
Regarding claim 12, the combination of Chao, Ye, and Bross teaches or suggests the method of claim 1, wherein the conversion includes encoding the video into the bitstream (Ye, ¶ 0033: teaches the prior art is drawn to video encoding and decoding).
Regarding claim 13, the combination of Chao, Ye, and Bross teaches or suggests the method of claim 1, wherein the conversion includes decoding the video from the bitstream (Ye, ¶ 0033: teaches the prior art is drawn to video encoding and decoding).
Claim 14 lists the same elements as claim 1, but in apparatus form rather than method form. Therefore, the rationale for the rejection of claim 1 applies to the instant claim.
Claim 16 lists the same elements as claim 4, but in apparatus form rather than method form. Therefore, the rationale for the rejection of claim 4 applies to the instant claim.
Claim 17 lists the same elements as claim 1, but in CRM form rather than method form. Therefore, the rationale for the rejection of claim 1 applies to the instant claim.
Claim 19 lists the same elements as claim 1, but also includes a statement of intention in the preamble regarding perhaps another step of storing a bitstream. Therefore, the rationale for the rejection of claim 1 applies to the instant claim.
Claim 21 lists the same elements as claim 5, but in apparatus form rather than method form. Therefore, the rationale for the rejection of claim 5 applies to the instant claim.
Claim 22 lists the same elements as claim 4, but in CRM form rather than method form. Therefore, the rationale for the rejection of claim 4 applies to the instant claim.
Claim 23 lists the same elements as claim 5, but in CRM form rather than method form. Therefore, the rationale for the rejection of claim 5 applies to the instant claim.
Claim 24 lists the same elements as claim 4, but also includes a statement of intention in the preamble regarding perhaps another step of storing a bitstream. Therefore, the rationale for the rejection of claim 4 applies to the instant claim.
Claims 7–9 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Chao, Ye, Bross, and Park (US 2021/0218964 A1).
Regarding claim 7, the combination of Chao, Ye, Bross, and Park teaches or suggests the method of claim 1, wherein the second video block is a luma block, and the second video block is obtained by splitting a luma parent block of a coding tree node, wherein a chroma parent block of the coding tree node is disallowed to be split (Ye, Abstract: explains the dual tree structure can allow the luma block to have a different split tree structure than the chroma blocks; Examiner interprets this limitation to be simply explaining what the prior art means by dual tree, i.e. the luma and chroma color planes are handled differently; Park, ¶ 0239: teaches that when dual tree is on, if further splitting the parent node of a chroma block would yield too small a chroma block, chroma splitting is not allowed).
One of ordinary skill in the art, before the effective filing date of the claimed invention, would have been motivated to combine the elements taught by Chao, Ye, and Bross, with those of Park, because the references are drawn to the same field of endeavor, because the skilled artisan endeavoring to understand the art of dual tree coding mode in the state-of-the-art video compression standard would have consulted publications like these to establish an understanding of the technique, and because combining their generic features in a generic way amounts to a mere combination of prior art elements, according to known methods, to yield a predictable result. This rationale applies to all combinations of Chao, Ye, Bross, and Park used in this Office Action unless otherwise noted.
Regarding claim 8, the combination of Chao, Ye, Bross, and Park teaches or suggests the method of claim 7, wherein the first video block is a luma block, and a palette size of a chroma block corresponding to the first video block is greater than a palette size of the chroma parent block (Examiner is unsure how to interpret this claim in view of claim 7; Examiner interprets this claim to mean that both luma and chroma blocks were allowed to be split at a first depth, but that only luma and not chroma are allowed to be further split at a second depth; In any case, Ye’s teachings regarding the differing sizes of the palettes between luma and chroma is general in teaching simply that the sizes can be different; see e.g. Ye, ¶ 0185; According to a similar example provided for the rejection of claims 4 and 5, Examiner additionally or alternatively interprets this claim to mean that assuming the first block is single tree and the size is 64, in order to maintain a total size of memory used for separate palette tables, the luma palette would be 32 and each of the chroma palettes would be 16 such that the total memory used is still 64; In that case, in view of the requirements of claim 7, the parent chroma block would be 16 rather than the chroma block of the first video block being 64).
Regarding claim 9, the combination of Chao, Ye, Bross, and Park teaches or suggests the method of claim 7, wherein the second palette has a size greater than a palette size of the chroma parent block (Examiner is unsure how to interpret this claim in view of claim 7; Examiner interprets this claim to mean that both luma and chroma blocks were allowed to be split at a first depth, but that only luma and not chroma are allowed to be further split at a second depth; In any case, Ye’s teachings regarding the differing sizes of the palettes between luma and chroma is general in teaching simply that the sizes can be different; see e.g. Ye, ¶ 0185; According to a similar example provided for the rejection of claims 4 and 5, Examiner additionally or alternatively interprets this claim to mean that assuming the first block is single tree and the size is 64, in order to maintain a total size of memory used for separate palette tables, the luma palette would be 32 and each of the chroma palettes would be 16 such that the total memory used is still 64; In that case, in view of the requirements of claim 7, the parent chroma block would be 16 rather than the chroma block of the first video block being 64).
Regarding claim 11, the combination of Chao, Ye, Bross, and Park teaches or suggests the method of claim 10, wherein the first video block is a chroma block, wherein the third video block is a luma block, and the third video block is obtained by splitting a luma parent block of a coding tree node, wherein a chroma parent block of the coding tree node is disallowed to be split, and wherein a size of the first palette is greater than a palette size of the chroma parent block (Ye, Abstract: explains the dual tree structure can allow the luma block to have a different split tree structure than the chroma blocks; Examiner interprets this limitation to be simply explaining what the prior art means by dual tree, i.e. the luma and chroma color planes are handled differently; Park, ¶ 0239: teaches that when dual tree is on, if further splitting the parent node of a chroma block would yield too small a chroma block, chroma splitting is not allowed; see e.g. Ye, ¶ 0185; According to a similar example provided for the rejection of claims 4 and 5, Examiner additionally or alternatively interprets this claim to mean that assuming the first block is single tree and the size is 64, in order to maintain a total size of memory used for separate palette tables, the luma palette would be 32 and each of the chroma palettes would be 16 such that the total memory used is still 64).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Alakuijala (US 2020/0077122 A1) teaches palette size can mean number of entries (¶ 0098).
Examiner notes Version 11 of JVET-Q2001-vB is being used in the rejection. Below is an excerpt from the upload website for JVET evidencing when the publication was available to the public (01/27/2020), thus antedating Applicant’s earliest priority date.
PNG
media_image1.png
250
318
media_image1.png
Greyscale
Zhu (US 2022/0007013 A1) teaches qp adjustments based on, for example slice_beta_offset_div2 and slice_tc_offset_div2 (e.g. ¶ 0082) and the same for PPS (e.g. ¶ 0095). It also teaches chroma deblocking with chroma QP adjustments at the PPS and slice levels (e.g. ¶¶ 0362–0366), combining chroma QP offsets used during palette mode may also be used for deblocking or ACT (e.g. ¶¶ 0367–0369), and basing chroma QP offsets based on separate partition trees (dual tree) (e.g. ¶ 0370).
Park (US 2021/0235099 A1) teaches, “splitting of a chroma block whose size is equal to or smaller than a preset size is not allowed when a splitting tree type indicates a dual tree” (e.g. ¶ 0323) and further teaches, “When the splitting tree type indicates the dual tree, a tree structure of coding units of a luma image and a tree structure of coding units of a chroma image may be separately determined.” (¶ 0324). Notably, the behavior Applicant describes as “local dual tree” is just “dual tree” to everyone else.
Zhou (US 2022/0021892 A1) explains in paragraph [0169] that in dual tree, when the luma block size reaches a certain size (i.e. 8x8) that means a chroma block in 4:2:0 sampling reaches a minimum size (i.e. 4x4). In that case, for the chroma block but not the luma block, further splitting is not allowed. This is the difference between the prior art’s DUAL_TREE_LUMA and DUAL_TREE_CHROMA (see Zhou, ¶ 0093).
Chuang (US 2021/021098 A1) ¶ 0088 teaches, “Since two separate CU partitioning structures are used to split the video data of luma and chroma components when dual tree coding is enabled….” And Table 6, underneath that paragraph, explains how splitting is disabled logically utilizing DUAL_TREE_CHROMA
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Michael J Hess whose telephone number is (571)270-7933. The examiner can normally be reached Mon - Fri 9:00am-5:30pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, William Vaughn can be reached on (571)272-3922. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8933.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL J HESS/Examiner, Art Unit 2481