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 . 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 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. There are a total of 20 claims and claims 1-20 are pending.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words. The form and legal phraseology often used in patent claims, such as "means" and "said," should be avoided. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, "The disclosure concerns," "The disclosure defined by this invention," "The disclosure describes," etc.
The abstract of the disclosure is objected to because it contains a phrase that can be implied (“Embodiments of the disclosure provide a solution for video processing”).
Appropriate correction is required. Also see MPEP 608.01(b), Paragraph C – “Language and Format”.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112, second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2-17, 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 2 through 17 are all interdependent claims which are dependent on the independent claim 1. However, due to the extensive use of “or” and “and/or” terms in the claim limitations, there are numerous antecedent basis violations in the claims. The identification of each and every antecedent violation is a tedious process. However, for example, the Examiner just provides one antecedent basis violation here. The Applicant is required to identify and fix all the violations similar to the following one.
Claim 2 recites “the method of claim 1, wherein the neighbor block comprises”. However, there is an antecedent basis issue of the term “the neighbor block”, because with BRI, claim 1 may only recite “a reference block” or “a first reference block” or “a second reference block” or “a target coding tool” but not “neighbor block”. After going through all the claims from 2 through 17, the Examiner encounters numerous antecedent violations like this.
Claims 5-6, 8 have multiple repetitions of a number of limitations. For example, in claim 5, the limitation “wherein if there is one neighbor block coded with inter mode, whether a reference block of the inter mode coded neighbor block is coded with a target mode is further checked, and if the reference block is coded with the target mode, the checking process is terminated, and it is perceived that OBMC is not applied to the current block” is repeated again later in the same claim. Similar issue exists in claims 6 and 8 and perhaps in other claims as well.
Claim 20 recites “A non-transitory computer-readable recording medium storing a bitstream of a video which is generated by a method performed by an apparatus for video processing”. Claim 20 is directed to a non-transitory storage medium storing a bitstream of a video wherein clauses that appear to describe how the bitstream is generated. These elements or steps are not performed by an intended computer, and the bitstream is not a form of programming that causes functions to be performed by an intended computer. This shows that the computer-readable medium merely serves as support for storing the bitstream and provides no functional relationship between the steps/elements that describe the generation of the bitstream and intended computer system. Therefore, those claim elements are not given patentable weight. Patentable weight is given to data stored on a computer-readable medium when there exists a functional relationship between the data and its associated substrate. See MPEP 2111.05 III. For example, if a claim is drawn to a computer-readable medium containing programming, a functional relationship exists if the programming “performs some function with respect to the computer with which it is associated.” However, if the claim recites that the computer-readable medium merely serves as a storage for information or data that is not meant for being executed, no functional relationship exists and the information or data is not given patentable weight. The Examiner suggests that the claim be amended so that it is directed to a functional relationship. For example, in this particular case, the claim should instead be recited as “A method of storing a bitstream of a video into a non-transitory computer-readable storage medium, wherein the bitstream is generated by a method performed by an apparatus for video processing”, followed by functional steps of the method and a step to store the generated bitstream into a non-transitory computer-readable storage medium.
Claim Rejections - 35 USC § 102
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.
Claims 1-4, 7-9, 12-20 are rejected under AIA 35 U.S.C. 102(a)(1) as being anticipated by Liu et al. (US PGPub 2016/0219302 A1).
Regarding claim 1, Liu et al. teach a method of video processing ([0007]), comprising:
determining, for a conversion between a video unit of a video and a bitstream of the video (Fig. 9 shows the conversion of input video data in to an encoded video bitstream), whether an overlap subblock based motion compensation (OBMC) is applied to a current block of the video unit ([0141]; It teaches that video encoder 20 may be configured to signal, and video decoder 30 may be configured to receive, an OBMC syntax element such as an OBMC flag having a value that indicates whether OBMC is enabled or disabled for a particular block. It is to be noted that the OBMC is performed on sub-block basis as described in [0094]) based on at least one of:
a prediction mode of neighbor block ([0125]; It teaches that video encoder 20 and/or video decoder 30 may be configured to perform OBMC for the current sub-block, sub-PU, or block using motion information (e.g., motion vectors) of each available neighboring sub-block, sub-PU, or block to generate a prediction block),
a prediction mode of a reference block,
a prediction mode of a first reference block of a second reference block, or
whether a target coding tool is enabled for the current block; and
performing the conversion based on the determining (Fig. 9 shows the conversion of input video data in to an encoded video bitstream).
Regarding claim 2, Liu et al. teach the method of claim 1, wherein the neighbor block comprises at least one of: a spatial neighbor block adjacent to the current block (Abstract; [0078]; it teaches that spatial MV candidates are derived from the neighboring blocks shown in Figs. 3A and 3B), a spatial neighbor block non-adjacent to the current block, a temporal neighbor block adjacent to the current block, or a temporal neighbor block non-adjacent to the current block, and/or
wherein the neighbor block is adjacent to the current block, and/or
wherein the neighbor block is non-adjacent to the current block, and/or
wherein the neighbor block is a spatial neighbor block inside a current picture, and/or
wherein the neighbor block is a temporal block in a reference picture, and/or
wherein the neighbor block is a subblock which is smaller than the current block, and/or
wherein the neighbor block is a video unit which is larger than or equal to the current block, and/or
wherein the neighbor block is a sample location.
Regarding claim 3, Liu et al. teach the method of claim 2, wherein the current block is inter merge coded, or the current block is inter advanced motion vector prediction (AMVP) coded ([0078]; It teaches that Figs. 3A and 3B show spatial neighboring MV candidates for merge and AMVP modes, respectively), and/or
wherein whether the OBMC is applied to the current block is based on whether there is a neighbor block coded with intra block copy (IBC), and/or
wherein whether the OBMC is applied to the current block is based on whether there is a neighbor block coded with Palette, and/or
wherein whether the OBMC is applied to the current block is based on whether there is a neighbor block coded with intra template matching prediction (intraTMP), and/or
wherein whether the OBMC is applied to the current block is based on whether there is a neighbor block coded with block differential pulse coded modulation (BDPCM), and/or
wherein whether the OBMC is applied to the current block is based on whether there is a neighbor block coded with transform skip.
Regarding claim 4, Liu et al. teach the method of claim 1, wherein a checking process is applied to a series of adjacent neighboring blocks or subblocks which is left and/or above the current block one by one to determine whether the OBMC is applied to the current block (Fig. 8A shows that for determining the OBMC for sub-blocks PN1, PN2, PN3, motion vector of left and above neighboring sub-blocks are used, which means the above and left neighboring sub-blocks are checked to determine whether OBMC is applied to the sub-blocks PN1, PN2, PN3), and/or
wherein a checking process is applied to a series of non-adjacent neighboring blocks or subblocks in an already coded area of a current picture one by one to determine whether the OBMC is applied to the current block, and/or
a checking process is applied to a series of temporal blocks or subblocks in a reference picture one by one to determine whether the OBMC is applied to the current block, and/or
wherein whether a block in a current picture is coded as a target mode is stored in a buffer, and the block is one of: the current block, the neighbor block or the reference block, and/or
wherein whether at least one of: a block or a reference block of the block is coded as a target mode is stored in a buffer, and the block is one of: the current block, the neighbor block or the second reference block, and/or
wherein the target coding tool comprises at least one of: IBC, Palette, intraTMP, BDPCM, or transform skip, and/or
wherein whether the OBMC is applied to the current block is dependent on the prediction mode of the reference block, and/or
wherein whether the OBMC is applied to the current block is dependent on the prediction mode of the first reference block of the second reference block.
Regarding claim 7, Liu et al. teach the method of claim 4, wherein the current block is inter merge coded, or wherein the current block is inter AMVP coded ([0078]; It teaches that Figs. 3A and 3B show spatial neighboring MV candidates for merge and AMVP modes, respectively), and/or
wherein the reference block is a block or subblock identified based on adding a displacement to a location of a first block, and/or
wherein the reference block is checked in case that the neighbor block is coded with INTER mode, and/or
wherein the reference block is checked in case that the neighbor block is coded with IntraTMP mode.
Regarding claim 8, Liu et al. teach the method of claim 7, wherein the first block is the current block, and/or
wherein the first block is a neighbor block adjacent to the current block, and/or
wherein the first block is a neighbor block non-adjacent to the current block, and/or
wherein the first block is a reference block of the current block, and/or
wherein the first block is a reference block of a neighbor block, and/or
wherein the reference block is identified based on a location of an inter mode coded current block and motion information associated to the current block, and/or
wherein the reference block is identified based on a location of an IntraTMP mode coded current block and motion information associated to the current block, and/or
wherein the reference block is identified based on a location of an inter mode coded neighbor block and motion information associated to the INTER mode coded neighbor block, and/or
wherein the reference block is identified based on a location of an IntraTMP mode coded neighbor block and motion information associated to the IntraTMP mode coded neighbor block, and/or
wherein the reference block is identified based on a location of an inter mode coded reference block and motion information associated to the inter mode coded reference block, and/or
wherein the reference block is identified based on a location of an IntraTMP mode coded reference block and motion information associated to the IntraTMP mode coded reference block, and/or
wherein if the neighbor block is coded with IntraTMP mode, a reference block is identified by adding a block vector associated with the IntraTMP coded neighbor block and a position of the IntraTMP coded neighbor block, and if the reference block is coded with the target mode, it is perceived that the OBMC is not applied to the current block, and/or
wherein the reference block is in a reference picture ([0169]; It teaches that to reconstruct the residual block in the pixel domain for later use as a reference block of a reference picture), and/or
wherein the reference block is in a current picture, and/or
wherein the reference block is in a reference picture, and/or
wherein the reference block is in a current picture, and/or
wherein the reference block is in another reference picture rather than a reference picture where the inter mode coded reference block locates at, and/or
wherein the reference block is in the same reference picture where the IntraTMP mode coded reference block locates at, and/or
wherein if the neighbor block is coded with inter mode, a reference block is identified by adding a motion vector associated with the inter coded neighbor block and a position of the inter coded neighbor block, and if the reference block is coded with the target mode, it is perceived that the OBMC is not applied to the current block.
Regarding claim 9, Liu et al. teach the method of claim 4, wherein the current block is inter merge coded, or the current block is inter AMVP coded ([0078]; It teaches that Figs. 3A and 3B show spatial neighboring MV candidates for merge and AMVP modes, respectively), and/or
wherein the first reference block of the second reference block is identified by adding a motion vector associated with the second reference block which is an inter mode coded reference block and a position of the second reference block, and/or
wherein the first reference block of the second reference block is identified by adding a block vector associated with the second reference block which is an IntraTMP mode coded reference block and a position of the second reference block, and/or
wherein a historical or propagated prediction mode is stored in a buffer, and/or
wherein whether the block is coded with IBC or Palette is stored using a shared parameter or buffer, and/or
wherein whether a block is coded with IBC or Palette or intraTMP or BDPCM is stored using individual parameters or buffers, and/or
wherein whether the block in a current picture is coded as a target mode is stored in a granularity of MxM subblock.
Regarding claim 12, Liu et al. teach the method of claim 4, wherein whether to apply the target coding tool is controlled by a first syntax element (SE), and/or
wherein whether to apply OBMC may be controlled by a second syntax element ([0141]; It teaches that video encoder 20 may be configured to signal, and video decoder 30 may be configured to receive, an OBMC syntax element such as an OBMC flag having a value that indicates whether OBMC is enabled or disabled for a particular block).
Regarding claim 13, Liu et al. teach the method of claim 12, wherein the second syntax element indicates the OBMC to be disabled if the first syntax element indicates the target coding tool is enabled, and/or
wherein it is set at an encoder the second syntax element indicates the OBMC to be disabled if the first syntax element indicates the target coding tool is enabled, and/or
wherein the first syntax element is indicated in one of: video parameter set (VPS), sequence parameter set (SPS), picture parameter set (PPS), slice header, coding tree unit (CTU) or coding unit (CU), or the second syntax element is indicated in one of: VPS, SPS, PPS, slice header, CTU, or CU (In [0141] it teaches that OBMC flag is included in the OBMC syntax and in [0052], it teaches that the slice header of a slice may be a syntax structure that includes syntax elements that provide information about the slice. The slice data may include coded CTUs of the slice).
Regarding claim 14, Liu et al. teach the method of claim 1, wherein an indication of whether to and/or how to determine whether the OBMC is applied to the current block is indicated at one of the followings: sequence level, group of pictures level, picture level, slice level, or tile group level, or
wherein an indication of whether to and/or how to determine whether the OBMC is applied to the current block is indicated in one of the following: a sequence header, a picture header, a sequence parameter set (SPS), a video parameter set (VPS), a decoding parameter set (DPS), a decoding capability information (DCI), a picture parameter set (PPS), an adaptation parameter sets (APS), a slice header, or a tile group header, or
wherein an indication of whether to and/or how to determine whether the OBMC is applied to the current block is included in one of the following: a prediction block (PB), a transform block (TB), a coding block (CB), a prediction unit (PU) ([0124]; It teaches video encoder 20 and/or video decoder 30 may be configured to perform OBMC on a block (e.g., a CU or PU)), a transform unit (TU), a coding unit (CU) ([0124]; It teaches video encoder 20 and/or video decoder 30 may be configured to perform OBMC on a block (e.g., a CU or PU)), a virtual pipeline data unit (VPDU), a coding tree unit (CTU), a CTU row, a slice, a tile, a sub-picture, or a region containing more than one sample or pixel.
Regarding claim 15, Liu et al. teach the method of claim 1, further comprising: determining, based on coded information of the video unit, whether and/or how to determine whether the OBMC is applied to the current block, the coded information including at least one of:
a block size ([0124]; it teaches video encoder 20 and/or video decoder 30 may be configured to perform OBMC on a block (e.g., a CU or PU) with special types or sizes e.g., predefined types or sizes),
a colour format,
a single and/or dual tree partitioning,
a colour component,
a slice type, or
a picture type.
Regarding claim 16, Liu et al. teach the method of claim 1, wherein the conversion includes encoding the video unit into the bitstream (Fig. 9).
Regarding claim 17, Liu et al. teach the method of claim 1, wherein the conversion includes decoding the video unit from the bitstream (Fig. 10).
Regarding claim 18, Liu et al. teach an apparatus for video processing comprising a processor and a non-transitory memory with instructions thereon, wherein the instructions upon execution by the processor ([0049]; It teaches that Video encoder 20 and video decoder 30 each may be implemented as a device to store instructions for the software in a suitable, non-transitory computer-readable storage medium and may execute the instructions in hardware using one or more processors), cause the processor to perform a method comprising:
determining, for a conversion between a video unit of a video and a bitstream of the video (Fig. 9 shows the conversion of input video data in to an encoded video bitstream), whether an overlap subblock based motion compensation (OBMC) is applied to a current block of the video unit ([0141]; It teaches that video encoder 20 may be configured to signal, and video decoder 30 may be configured to receive, an OBMC syntax element such as an OBMC flag having a value that indicates whether OBMC is enabled or disabled for a particular block. It is to be noted that the OBMC is performed on sub-block basis as described in [0094]) based on at least one of:
a prediction mode of neighbor block ([0125]; It teaches that video encoder 20 and/or video decoder 30 may be configured to perform OBMC for the current sub-block, sub-PU, or block using motion information (e.g., motion vectors) of each available neighboring sub-block, sub-PU, or block to generate a prediction block),
a prediction mode of a reference block,
a prediction mode of a first reference block of a second reference block, or
whether a target coding tool is enabled for the current block; and
performing the conversion based on the determining (Fig. 9 shows the conversion of input video data in to an encoded video bitstream).
Regarding claim 19, Liu et al. teach a non-transitory computer-readable storage medium storing instructions that cause a processor ([0049]; It teaches that Video encoder 20 and video decoder 30 each may be implemented as a device to store instructions for the software in a suitable, non-transitory computer-readable storage medium and may execute the instructions in hardware using one or more processors) to perform a method comprising:
determining, for a conversion between a video unit of a video and a bitstream of the video (Fig. 9 shows the conversion of input video data in to an encoded video bitstream), whether an overlap subblock based motion compensation (OBMC) is applied to a current block of the video unit ([0141]; It teaches that video encoder 20 may be configured to signal, and video decoder 30 may be configured to receive, an OBMC syntax element such as an OBMC flag having a value that indicates whether OBMC is enabled or disabled for a particular block. It is to be noted that the OBMC is performed on sub-block basis as described in [0094]) based on at least one of:
a prediction mode of neighbor block ([0125]; It teaches that video encoder 20 and/or video decoder 30 may be configured to perform OBMC for the current sub-block, sub-PU, or block using motion information (e.g., motion vectors) of each available neighboring sub-block, sub-PU, or block to generate a prediction block),
a prediction mode of a reference block,
a prediction mode of a first reference block of a second reference block, or
whether a target coding tool is enabled for the current block; and
performing the conversion based on the determining (Fig. 9 shows the conversion of input video data in to an encoded video bitstream).
Regarding claim 20, Liu et al. teach a non-transitory computer-readable recording medium storing a bitstream of a video which is generated by a method performed by an apparatus for video processing ([0049]; It teaches that Video encoder 20 and video decoder 30 each may be implemented as a device to store instructions for the software in a suitable, non-transitory computer-readable storage medium and may execute the instructions in hardware using one or more processors), wherein the method comprises:
determining, whether an overlap subblock based motion compensation (OBMC) is applied to a current block of a video unit of the video ([0141]; It teaches that video encoder 20 may be configured to signal, and video decoder 30 may be configured to receive, an OBMC syntax element such as an OBMC flag having a value that indicates whether OBMC is enabled or disabled for a particular block. It is to be noted that the OBMC is performed on sub-block basis as described in [0094]) based on at least one of:
a prediction mode of neighbor block ([0125]; It teaches that video encoder 20 and/or video decoder 30 may be configured to perform OBMC for the current sub-block, sub-PU, or block using motion information (e.g., motion vectors) of each available neighboring sub-block, sub-PU, or block to generate a prediction block),
a prediction mode of a reference block,
a prediction mode of a first reference block of a second reference block, or
whether a target coding tool is enabled for the current block; and
generating the bitstream based on the determining (Fig. 9 shows the conversion of input video data in to generate an encoded video bitstream).
Claim 20 is rejected under AIA 35 U.S.C. 102(a)(1) as being anticipated by Zhang et al. (US PGPub 2016/0277762 A1).
Claim 20’s recitation of “A non-transitory computer-readable recording medium storing a bitstream of a video which is generated by a method performed by an apparatus for video processing” is a product by process claim limitation where the product is the bit stream and the process is the method steps to generate the bitstream. MPEP §2113 recites “Product-by-Process claims are not limited to the manipulations of the recited steps, only the structure implied by the steps”. Thus, the scope of the claim is the storage medium storing the bitstream (with the structure implied by the method steps). The structure includes the information and samples manipulated by the steps. “To be given patentable weight, the printed matter and associated product must be in a functional relationship. A functional relationship can be found where the printed matter performs some function with respect to the product to which it is associated”. MPEP §2111.05(1)(A). When a claimed “computer-readable medium merely serves as a support for information or data, no functional relationship exists. MPEP §2111.05(III). The storage medium storing the claimed bitstream in claim 15 merely services as a support for the storage of the bitstream and provides no functional relationship between the stored bitstream and storage medium. Therefore, the structure bitstream, whose scope is implied by the method steps, is non-functional descriptive material and given no patentable weight. MPEP §2111.05(III). Thus, the claim scope is just a storage medium storing data and is anticipated by Zhang et al. which recites a storage medium storing a bitstream ([0151]).
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.
Claims 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Liu et al. (US PGPub 2016/0219302 A1) in view of Chang et al. (US PGPub 2023/0283770 A1).
Regarding claim 5, Liu et al. teach the method of claim 4.
But it does not explicitly teach that the target mode is at least one of: an IBC mode, a Palette mode, an intraTMP mode, a BDPCM mode, or a transform skip mode.
However, Chang et al., in the same field of endeavor (Abstract), teach a video coding method where the target mode is IBC mode or palette mode (Chang et al.; [0122]; It teaches that intra-prediction unit 226 may be configured to encode coding blocks of video data using intra block copy (IBC), and/or color palette mode).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine Liu et al’s invention of OBMC for video coding to include Chang et al's usage of IBC or palette mode coding, because a video decoder may achieve better prediction by varying, based on block characteristics, the amount of blending performed in an OBMC operation (Chang et al.; [0023]).
Regarding claim 6, Liu et al. and Chang et al. teach the method of claim 5, wherein the reference block is identified by adding a motion vector associated with the inter mode coded neighbor block and the position of the inter mode coded neighbor block, and/or
wherein the reference block is in a reference picture (Liu et al.; [0169]; It teaches that to reconstruct the residual block in the pixel domain for later use as a reference block of a reference picture), and/or
wherein the reference block is identified by adding a block vector associated with the intraTMP coded neighbor block and the position of intraTMP coded neighbor block, and/or
wherein the reference block is in a current picture, and/or
wherein the reference block is identified by adding a motion vector associated with the inter mode coded neighbor block and the position of the inter mode coded neighbor block, and/or
wherein the reference block is in a reference picture, and/or
wherein the reference block is identified by adding a block vector associated with the intraTMP coded neighbor block and the position of intraTMP coded neighbor block, and/or
wherein the reference block is in a current picture, and/or
wherein the reference block is identified by adding a motion vector associated with the inter mode coded temporal block and the position of the inter mode coded temporal block, and/or
wherein the reference block is identified by adding a block vector associated with the intraTMP coded temporal block and the position of intraTMP coded temporal block.
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Liu et al. (US PGPub 2016/0219302 A1) in view of Zhang et al. (US PGPub 2019/0246143 A1).
Regarding claim 10, Liu et al. teach the method of claim 9.
But it does not explicitly teach that a single parameter or buffer is needed for storing whether the block is coded with IBC or Palette.
However, Zhang et al., in the same field of endeavor ([0163]-[0166]), teach a coding method where a single parameter or buffer is needed for storing whether the block is coded with IBC or Palette (Zhang et al.; [0184]; It teaches that a flag may be signaled in SPS/VPS/PPS/Slice header/Tile header to indicate whether IBC could be enabled or disabled).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine Liu et al’s invention of OBMC for video coding to include Zhang et al's usage of IBC flag, because it can minimize signaling overhead when OBMC is enabled or disabled (Zhang et al.; [0185]).
Regarding claim 11, Liu et al. teach the method of claim 4.
But it does not explicitly teach that if the block or the reference block of the block is coded with IBC or Palette, a parameter equal to true is stored in a buffer.
However, Zhang et al., in the same field of endeavor ([0163]-[0166]), teach a coding method where if the block or the reference block of the block is coded with IBC or Palette, a parameter equal to true is stored in a buffer (Zhang et al.; [0184]; It teaches that a flag may be signaled in SPS/VPS/PPS/Slice header/Tile header to indicate whether IBC could be enabled or disabled, where the flag is the parameter and when the parameter is true then the block is coded with IBC).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine Liu et al’s invention of OBMC for video coding to include Zhang et al's usage of IBC flag, because it can minimize signaling overhead when OBMC is enabled or disabled (Zhang et al.; [0185]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
“OVERLAPPED BLOCK MOTION COMPENSATION” – Chang et al., US PGPub 2022/0201282 A1.
“METHOD AND APPARATUS OF CONSTRAINED OVERLAPPED BLOCK MOTION COMPENSATION IN VIDEO CODING” – Lin et al., US PGPub 2021/0274218 A1.
PREDICTION-DOMAIN FILTERING FOR VIDEO CODING” – Rusanovskyy et al., US PGPub 2020/0288158 A1.
“OVERLAPPED BLOCK MOTION COMPENSATION” – Xiu et al., WO 2019/089864 A1.
5. “A Parametric Window Design for OBMC with Variable Block Size Motion Estimates” – Chen et al., 2009 IEEE International Workshop on Multimedia Signal Processing, Date of Conference: 05-07 October 2009.
6. “Block-size dependent overlapped block motion compensation” – Kidani et al., 2020 IEEE International Conference on Image Processing (ICIP); Date of Conference: 25-28 October 2020.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAINUL HASAN whose telephone number is (571)272-0422. The examiner can normally be reached on MON-FRI: 10AM-6PM, Alternate FRIDAYS, EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, JAY PATEL can be reached on (571)272-2988. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see 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.
/Mainul Hasan/
Primary Examiner, Art Unit 2485
Prosecution Insights