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 .
Information Disclosure Statement
The information disclosure statement (IDS), submitted on 10/14/2025, is being considered by the examiner.
Objections
The drawings are objected to under 37 CFR 1.83(a). The drawings must show every feature of the invention specified in the claims. Therefore, “a regular merge mode”, “a combined inter and intra prediction (CIIP) merge mode”, “a first group of merge modes”, “a second group of merge modes”, “Context-Adaptive Binary Arithmetic Coding (CABAC) with multiple context models” must be shown or the feature must be canceled from the claims 1-16. No new matter should be entered.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Double Patenting
The no statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/forms/. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
5. Claims 1-16 are rejected on the ground of nonstatutory double patenting as being unpatentable over related claims of the U.S. Patent 12,470,729 B2. Although the conflicting claims are not identical, they are not patentably distinct from each other because the instant claims are similar to the claims in the US Patent 12,470,729 B2 to meet the limitations claimed in the co-pending applications. Table 1 shows comparisons between the instant claims and the US Patent 12,470,729 B2 claims. It is noted that “video coding” can be interpreted as “video encoding” or “video decoding”.
Table 1: Comparison of claims in the instant Application 19334176 vs. the U.S. Patent 12,470,729 B2.
Instant Application 19358406
U.S. Patent 12,470,729 B2
1. A method for video coding, comprising: obtaining a plurality of variables for determining enablement statuses of a plurality of merge modes in a second group of merge modes; in response to determining from the plurality of variables that no merge mode in the second group of merge modes is enabled, determining information of merge modes for deriving motion information of a current block of a plurality of blocks partitioned from a frame, wherein the information of merge modes comprises a flag indicating whether to apply a merge mode in a first group of merge modes; and
in response to determining from the plurality of variables that the plurality of merge modes in the second group of merge modes are enabled, determining information of merge modes for deriving motion information of the current block, wherein the information of merge modes comprises a flag indicating whether to apply one of the plurality of enabled merge modes in the second group of merge modes, wherein the first group of merge modes comprises a regular merge mode, and the second group of merge modes comprises a combined inter and intra prediction (CIIP) merge mode; and wherein in response to determining that a certain merge mode is enabled but a corresponding flag is not signaled, a value of the corresponding flag is inferred to be opposite to an explicitly signaled merge mode flag for the current block.
1. A method for video decoding, comprising:
obtaining, by a decoder, a plurality of variables for determining enablement statuses of a plurality of merge modes in a second group of merge modes;
in response to determining, by the decoder, from the plurality of variables that no merge mode in the second group of merge modes is enabled, determining, by the decoder, information of merge modes for deriving motion information of a current block, wherein the information of merge modes comprises a flag indicating whether to apply a merge mode in a first group of merge modes;
in response to determining, by the decoder, that a certain merge mode is enabled but a corresponding flag is not signaled, inferring, by the decoder, a value of the corresponding flag as opposite to an explicitly signaled merge mode flag for the current block; and
in response to determining, by the decoder, from the plurality of variables that a plurality of merge modes in the second group of merge modes are enabled, determining, by the decoder, information of merge modes for deriving motion information of the current block, wherein the information of merge modes comprises a flag indicating whether to apply one of the plurality of enabled merge modes in the second group of merge modes,
wherein the first group of merge modes comprises a regular merge mode, and the second group of merge modes comprises a combined inter and intra prediction (CIIP) merge mode.
2. The method of claim 1, further comprising: in response to determining that the information of merge modes comprises a flag indicating application of a merge mode in the first group of merge modes, deriving motion information of the current block using a merge mode in the first group of merge modes.
2. The method of claim 1, further comprising:
in response to determining, by the decoder, that the information of merge modes comprises a flag indicating application of a merge mode in the first group of merge modes, deriving, by the decoder, motion information of the current block using a merge mode in the first group of merge modes.
3. The method of claim 1, further comprising: in response to determining that the information of merge modes comprises a flag indicating non-application of a merge mode in the first group of merge modes, deriving motion information of the current block using a merge mode in the second group of merge modes.
3. The method of claim 1, further comprising:
in response to determining, by the decoder, that the information of merge modes comprises a flag indicating non-application of a merge mode in the first group of merge modes, deriving, by the decoder, motion information of the current block using a merge mode in the second group of merge modes
4. The method of claim 1, wherein the flag indicating whether to apply one of the plurality of enabled merge modes in the second group of merge modes is derived according to a sequence parameter set (SPS) flag, and size constraints of the one of the plurality of enabled merge modes.
4. The method of claim 1, wherein the flag indicating whether to apply one of the plurality of enabled merge modes in the second group of merge modes is derived according to a sequence parameter set (SPS) flag, and size constraints of the one of the plurality of enabled merge modes.
5. The method of claim 1, wherein the regular merge mode is signaled using Context-Adaptive Binary Arithmetic Coding (CABAC) with multiple context models and selection of the multiple context models is based on a skip flag of the current block.
5. The method of claim 1, wherein the regular merge mode is signaled using Context-Adaptive Binary Arithmetic Coding (CABAC) with multiple context models and selection of the multiple context models is based on a skip flag of
the current block.
Note: Claims 6-15 of this invention are also similar as claims 6-15 of the US Patent 12,470,729 B2, respectively
Claim Rejection – 35 U.S.C. § 112
The following is a quotation of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode contemplated by the inventor of carrying out his invention.
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 pre-AIA 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 1-16 are rejected under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, as failing to comply with the written description requirement. The claims contain subject matters, which were not described in the specification in such a way as to reasonably enable a person skilled in the art to make the invention commensurate in scope with the claims. To satisfy the written description requirement, the specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventors had possession of the claimed invention. Original claims fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. In this application, several limitations are not explained in sufficient details in the specification. For example, claims 1, 6, and 11 recite “obtaining a plurality of variables for determining enablement statuses of a plurality of merge modes in a second group of merge modes”. It is noted that claims 1, 6, and 11 can be interpreted as encoding claims, and the “plurality of variables” is mentioned only three times in the specification. It is not clear to readers that where does “a plurality of variables for determining enablement statuses of a plurality of merge modes” come from, and how the encoder can obtain them. Accordingly, these limitations do not satisfy the written description requirement. It is not enough information for one skilled in the art could write a program or implement in an apparatus to achieve the claimed function because the specification must explain how the inventors achieve the claimed function to satisfy the written description requirement. For the reasons discussed above, claims 1, 6, 11, and their dependent claims are rejected under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph.
Claims 1-16 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 pre-AIA the applicant regards as the invention. Claims 1, 6, and 11 recite “obtaining a plurality of variables for determining enablement statuses of a plurality of merge modes in a second group of merge modes”. It is not clear to readers that where does “a plurality of variables for determining enablement statuses of a plurality of merge modes” come from, and how the encoder can obtain them. Therefore, claims 1, 6, 11, and their dependent claims are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph.
Claims 1-16 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 pre-AIA the applicant regards as the invention. Claims 1, 6, and 11 recite “a plurality of merge modes in a second group of merge modes”. Claims 1, 6, and 11 further define, “the second group of merge modes comprises a combined inter and intra prediction (CIIP) merge mode”. The claims indicate that there are multiple merge modes in the second group. However, it is not clear from the claim language what are other merge modes in the second group of merge modes. Therefore, claims 1, 6, 11, and their dependent claims are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph.
Claims 1-16 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 pre-AIA the applicant regards as the invention. Claims 1, 6, and 11 recite “a first group of merge modes”. Claims 1, 6, and 11 further define, “the first group of merge modes comprises a regular merge mode”. The claims indicate that there are multiple merge modes in the first group. However, it is not clear from the claim language what are other merge modes in the first group of merge modes. Therefore, claims 1, 6, 11, and their dependent claims are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph.
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.
Claim 11-13 and 15 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Jang (US Patent US 10,812,807 B2), (“Jang”).
Regarding claim 11, claim 11 directed to a non-transitory computer readable storage medium (CRM) storing a bitstream generated by a video coding method. The claim does not recite that the CRM contains executable instructions, that when executed, implement the encoding method. The bitstream is a product produced by the encoding method. Therefore, the claims are not limited to the recited steps, only the structure implied by the steps (See MPEP 2113 - Product-by-Process claims).
To be given patentable weight, the CRM and the bitstream (i.e. descriptive material) must be in a functional relationship. A functional relationship can be found where the descriptive material performs some function with respect to the CRM to which it is associated. See MPEP §2111.05(I)(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 CRM storing the claimed bitstream in claim 11 merely services as a support for the CRM of the bitstream and provides no functional relationship between the stored bitstream and the CRM. Therefore, the structure bitstream, which scope is implied by the encoding 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 Jang, which recites a storage medium storing a bitstream (The bitstream may be transmitted to the decoding device through a network or a storage medium) [Jang: col. 26, line 63-65] and an encoding method (an encoding method) [Jang: col. 6, line 37].
Regarding claim 12, Jang meets the claim limitations as set forth in claim 11. Jang further meets the claim limitations as follow.
in response to determining that the information of merge modes comprises a flag indicating application of a merge mode in the first group of merge modes (information required for inter-prediction of the current block provided by the video encoding device, for example, a motion vector and information about a reference picture index may be acquired or derived based on the information about prediction) [Jang: col. 8, line 40-46; Fig. 4], deriving motion information of the current block using a merge mode in the first group of merge modes (The predictor 250 may derive the prediction sample for the current block using one of the skip mode, the merge mode and the MVP mode) [Jang: col. 8, line 40-42].
Regarding claim 13, Jang meets the claim limitations as set forth in claim 11. Jang further meets the claim limitations as follow.
in response to determining that the information of merge modes comprises a flag indicating non-application of a merge mode in the first group of merge modes (In the case that the determined intra prediction mode is not belonged to the non-CIIP mode, the decoding device parses and checks a CIIP flag) [Jang: col. 12, line 29-31; Fig. 4], deriving motion information of the current block using a merge mode in the second group of merge modes (Whether to apply the CIIP may be determined based on a CIIP flag. In the case that the CIIP flag is 1, the CIIP scaling is applied) [Jang: col. 10, line 47-49].
Regarding claim 15, Jang meets the claim limitations as set forth in claim 11. Jang further meets the claim limitations as follow.
wherein the regular merge mode (the merge mode) [Jang: col. 6, line 2] is signaled using Context-Adaptive Binary Arithmetic Coding (CABAC) with multiple context models ((The entropy encoder 135 may perform entropy-encoding on the quantized transform coefficients. The entropy encoding may include an encoding method, for example, an exponential Golomb, a context-adaptive variable length coding (CAVLC), a context-adaptive binary arithmetic coding (CABAC), or the like. The entropy encoder 135 may perform encoding together or separately on information) [Jang: col. 6, line 35-41]; (decode information in the bitstream based on a coding method such as exponential Golomb encoding, CAVLC, CABAC, or the like, and may output a value of a syntax element required for video reconstruction and a quantized value of a transform coefficient regarding a residual. More specifically, a CABAC entropy decoding method can receive a bin corresponding to each syntax element in a bitstream, determine a context model using decoding target syntax element information and decoding information of neighboring and decoding target blocks or information of amabol/bin decoded in a previous step, predict bin generation probability according to the determined context model and perform arithmetic decoding of the bin to generate a symbol corresponding to each syntax element value. Here, the CABAC entropy decoding method can update the context model using information of a symbol/bin decoded for a context model of the next symbol/bin after determination of the context mod) [Jang: col. 8, line 37-46] and selection of the multiple context models is based on a skip flag of the current block (In the case of inter-prediction, the predictor 250 may derive a prediction sample for a current block based on a sample specified in a reference picture according to a motion vector. The predictor 250 may derive the prediction sample for the current block using one of the skip mode, the merge mode and the MVP mode) [Jang: col. 8, line 37-46].
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.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under pre-AIA 35 U.S.C. 103(a) are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
This application currently names joint inventors. In considering patentability of the claims under pre-AIA 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were made absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and invention dates of each claim that was not commonly owned at the time a later invention was made in order for the examiner to consider the applicability of pre-AIA 35 U.S.C. 103(c) and potential pre-AIA 35 U.S.C. 102(e), (f) or (g) prior art under pre-AIA 35 U.S.C. 103(a).
Claims 1-16 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang et al. (WO 2019/006363 A1), (“Zhang”), in view of ITU-T (Versatile Video Coding (Draft 4)), (“ITU-T”), in view of Ikai et al. (US 10,939,137 B2)), (“Ikai”).
Regarding claim 1, Zhang meets the claim limitations as follow.
A method (i.e. methods) [Zhang: para. 0003] for video coding ((i.e. a video encoding) [Zhang: para. 0012; Fig. 2]; (i.e. a video decoding) [Zhang: para. 0013; Fig. 3]), comprising:
obtaining (i.e. One or more (e.g., all) the prediction information of the current block may be obtained) [Zhang: para. 0132; Fig. 3] a plurality of variables ((i.e. LIC flag) [Zhang: para. 0135; Fig. 12]; (i.e. The variable i may be checked) [Zhang: para. 0139; Fig. 13]) for determining enablement status (i.e. When the techniques described herein are applied for ATMVP and/or STMVP, the illumination compensation process may be disabled for the sub-CU blocks that are coded by bi-prediction, and the LIC operation or process may be enabled for the sub-CU blocks which are coded by uni-prediction. The LIC flag may be set for a (e.g., each) sub-CU block, for example, when the CU level LIC flag indicates that LIC is to be applied.) [Zhang: para. 0135]; (i.e. A determination may be made as to whether the CU-level illumination compensation indication has a value that indicates UC process may be enabled at 1316. If the CU-level illumination compensation indication has a value that indicates LIC process may be enabled, the LIC process may be performed for the sub-CU1 at 1318.) [Zhang: para. 0140; Fig. 13]) of a plurality of merge modes in a second group of merge modes ((i.e. Various prediction modes may be used for motion compensation. Motion compensation may be affected by illumination changes between a current block and one or more reference blocks. A decoder may use illumination compensation to address illumination changes that affect the motion compensation. One or more prediction modes may be indicative of continuous motion changes between the current block and one or more reference blocks.) [Zhang: para. 0003]; (i.e. The signaling of the illumination compensation indication may be bypassed for certain ATMVP and/or STMVP merge modes. For ATMVP and/or STMVP merge candidates, the LIC flag may be derived from the first merge candidate in the merge candidate list. For an ATMVP and/or STMVP merge mode, whether the CU is uni- or bi-predicted may be determined or defined using different approaches. For bi-prediction within an explicit inter prediction or regular merge CU, two motion vectors may be provided for the CU) [Zhang: para. 0134]; (i.e. The decoder may perform prediction (e.g., motion compensation) on the current CU based on the determination whether to parse the illumination compensation indication for the current CU) [Zhang: para. 0144; Fig. 3]; (i.e. The syntax table for an illumination compensation indication (e.g., an LIC flag) may be used to determine whether to encode the illumination compensation indication. The syntax table may be shared across an encoder and/or decoder) [Zhang: para. 0115]; (i.e. The signaling of the illumination compensation indication may be bypassed for certain FRUC merge modes (e.g., a FRUC bi-lateral mode). The CU structure of a FRUC merge candidate may resemble the CU structure of a merge candidate or other prediction modes (e.g., a ATMVP or STMVP merge candidate). An illumination compensation indication (e.g., an UC flag) for certain FRUC merge modes may not be signaled. An FRUC merge mode may include a bi-lateral mode and/or a template mode) [Zhang: para. 0142; Fig. 13]); in response to determining (i.e. based on the determination) [Zhang: para. 0139] from the plurality of variables that no merge mode in the second group of merge modes is enabled ((i.e. based on the determination to disable the LIC process, for example, by setting the CU level illumination compensation indication to a value that indicates LIC process may be disabled) [Zhang: para. 0139]; (i.e. When the techniques described herein are applied for ATMVP and/or STMVP, the illumination compensation process may be disabled for the sub-CU blocks that are coded by bi-prediction) [Zhang: para. 0135]), determining (i.e. a value that indicates LIC process may be disabled. Motion compensation may be performed on the current CU without LIC based on the determination to disable the LIC process, for example, by setting the CU level illumination compensation indication to a value that indicates LIC process may be disabled) [Zhang: para. 0137; Fig. 13], by the decoder (i.e. a decoder) [Zhang: para. 0003; Fig. 3], information of merge modes for deriving motion information of a current block (i.e. The decoder may perform prediction (e.g., motion compensation) on the current CU based on the determination whether to parse the illumination compensation indication for the current CU. The decoder may determine to disable the illumination compensation process on the current CU if the decoder determines to bypass parsing the illumination compensation indication for the current CU.) [Zhang: para. 0144; Fig. 3] of a plurality of blocks partitioned from a frame (i.e. A CU may be partitioned into prediction units or PU, for which separate prediction methods may be applied. For each input video block (e.g., MB or CU), spatial prediction 760 and/or temporal motion prediction 762 may be performed. Spatial prediction (e.g., or intra prediction) may use pixels from the already coded neighboring blocks in the same video picture and/or slice to predict the current video block) [Zhang: para. 0081], wherein the information of merge modes (i.e. The technique of deriving the motion information from a current block's spatial and/or temporal neighbors may be referred to as a merge mode) [Zhang: para. 0096] comprises a flag (i.e. The syntax table for an illumination compensation indication (e.g., an LIC flag) may be used to determine whether to encode the illumination compensation indication. The syntax table may be shared across an encoder and/or decoder) [Zhang: para. 0115] indicating whether to apply a merge mode in a first group of merge modes ((i.e. the prediction mode (e.g., MC prediction mode) for the current CU is a regular merge mode) [Zhang: para. 0133]; (i.e. The signaling of the illumination compensation indication may be bypassed for certain FRUC merge modes (e.g., a FRUC bi-lateral mode). The CU structure of a FRUC merge candidate may resemble the CU structure of a merge candidate or other prediction modes (e.g., a ATMVP or STMVP merge candidate). An illumination compensation indication (e.g., an UC flag) for certain FRUC merge modes may not be signaled. An FRUC merge mode may include a bi-lateral mode and/or a template mode) [Zhang: para. 0142; Fig. 13]); and in response to determining (i.e. based on the determination) [Zhang: para. 0139] from the plurality of variables that the plurality of merge modes in the second group of merge modes are enabled (i.e. FIG. 13 illustrates an example UC flag derivation for ATMVP and/or STMVP CU. As shown in FIG. 13, ATMVP and/or STMVP prediction information may be received. An LIC flag may be derived (e.g., from a neighboring merge candidate) at 1302. CU-level motion vectors may be derived at 1304. At 1306, it may be determined whether a CU-level illumination compensation indication has a value that indicates LIC process may be enabled) [Zhang: para. 0138] information of merge modes for deriving motion information of the current block (i.e. The GBi mode may be extended to temporal prediction techniques that support bi-prediction, including one of more of merge modes, advance temporal motion vector prediction (ATMVP), spatial temporal motion vector prediction (STMVP), and/or frame-rate up conversion (FRUC). A merge mode may be performed. Motion information from spatial and/or temporal neighboring blocks may be derived. The motion information may not be searched using motion estimation. The technique of deriving the motion information from a current block's spatial and/or temporal neighbors may be referred to as a merge mode) [Zhang: para. 0095-0096], wherein the information of merge modes (i.e. The technique of deriving the motion information from a current block's spatial and/or temporal neighbors may be referred to as a merge mode) [Zhang: para. 0096] comprises a flag (i.e. The syntax table for an illumination compensation indication (e.g., an LIC flag) may be used to determine whether to encode the illumination compensation indication. The syntax table may be shared across an encoder and/or decoder) [Zhang: para. 0115] indicating whether to apply one of the plurality of enabled merge modes in the second group of merge modes ((i.e. The LIC flag may be a CU level flag that may be signaled for an inter prediction mode (e.g., explicit inter prediction mode)) [Zhang: para. 0128]; (i.e. The GBi mode may be extended to temporal prediction techniques that support bi-prediction, including one of more of merge modes, advance temporal motion vector prediction (ATMVP), spatial temporal motion vector prediction (STMVP), and/or frame-rate up conversion (FRUC). A merge mode may be performed. Motion information from spatial and/or temporal neighboring blocks may be derived. The motion information may not be searched using motion estimation. The technique of deriving the motion information from a current block's spatial and/or temporal neighbors may be referred to as a merge mode) [Zhang: para. 0095-0096]),wherein the first group of merge modes comprises a regular merge mode (i.e. the prediction mode (e.g., MC prediction mode) for the current CU is a regular merge mode) [Zhang: para. 0133], and the second group of merge modes comprises a combined inter and intra prediction (CIIP) merge mode (i.e. LIC may be combined with some prediction techniques (e.g., some advanced prediction techniques). For example, the advanced prediction techniques may include ATMVP, STMVP, and FRUC) [Zhang: para. 0122]; and wherein in response to determining that (i.e. based on the determination) [Zhang: para. 0139] a certain merge mode is enabled (i.e. When the techniques described herein are applied for ATMVP and/or STMVP, the illumination compensation process may be disabled for the sub-CU blocks that are coded by bi-prediction, and the LIC operation or process may be enabled for the sub-CU blocks which are coded by uni-prediction. The LIC flag may be set for a (e.g., each) sub-CU block, for example, when the CU level LIC flag indicates that LIC is to be applied.) [Zhang: para. 0135]; (i.e. A determination may be made as to whether the CU-level illumination compensation indication has a value that indicates UC process may be enabled at 1316. If the CU-level illumination compensation indication has a value that indicates LIC process may be enabled, the LIC process may be performed for the sub-CU1 at 1318.) [Zhang: para. 0140; Fig. 13]) but a corresponding flag is not signaled (i.e. A CU that is coded using an intra mode and/or regular affine motion prediction mode may not code the LIC flag (e.g., since LIC does not apply to such a CU)) [Zhang: para. 0115; Fig. 3]; (i.e. When LIC_Flag[x0 ][y0] is not present) [Zhang: para. 0152]), inferring (i.e. When LIC_Flag[x0 ][y0] is not present, the inferred value of LIC_Flag[x0][y0] may be equal to 0) [Zhang: para. 0152], a value of the corresponding flag is inferred to be opposite to an explicitly signaled merge mode flag for the current block (i.e. When LIC_Flag[x0 ][y0] is not present, the inferred value of LIC_Flag[x0][y0] may be equal to 0) [Zhang: para. 0152].
Zhang does not explicitly disclose the following claim limitations (Emphasis added).
the second group of merge modes comprises a combined inter and intra prediction (CIIP) merge mode.
a value of the corresponding flag is inferred to be opposite to an explicitly signaled merge mode flag for the current block
However, in the same field of endeavor ITU-T further discloses the claim limitations as follows:
the second group of merge modes comprises a combined inter and intra prediction (CIIP) merge mode (i.e. ciip_flag[x0 lly0] specifies whether the combined inter-picture merge and intra-picture prediction is applied for the current coding unit. The array indices x0, y0 specify the location (x0, y0 ) of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture. When ciip_flag[ x0 II y0 ] is not present, it is inferred to be equal to 0. The syntax elements ciip_Iuma_mpm_flag[ x0 II y0 ], and ciip_Iuma_mpm_idx[ x0 II y0] specify the intra prediction mode for luma samples used in combined inter-picture merge and intra-picture predictio11 The array indices x0, y0 specify the location ( x0 , y0 ) of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture. The intra prediction mode is derived according to clause 8.5.6) [ITU-T: page 95].
inferring, …, a value of the corresponding flag as opposite to explicitly signaled merge mode flags for the current block (i.e. sps explicit_ mts intra_ enabled_ flag equal to 1 specifies that tu_ mts idx may be present in the transform unit syntax for intra coding units. sps explicit_ rnts intra_ enabled_ flag equal to 0 specifies that tu_ rnts idx is not present in the transform unit syntax for intra coding units. When not present, the value of sps_explicit_rnts_intra_enabled_flag is inferred to be equal to 0. sps explicit_ mts inter_ enabled_ flag equal to 1 specifies that tu_ rnts idx may be present in the transform unit syntax for inter coding units. sps explicit_ rnts inter_ enabled_ flag equal to 0 specifies that tu_ rnts idx is not present in the transform unit syntax for inter coding units. When not present, the value of sps_explicit_rnts_inter_enabled_flag is inferred to be equal to 0) [ITU-T: page 66]).
It would have been obvious to one with an ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhang with ITU-T to implement the ITU-T VVC standard.
Therefore, the combination of Zhang with ITU-T will enable the system to be compliant with the VVC international video coding standard.
In the same field of endeavor, Ikai further discloses the claim limitations as follows:
a value of the corresponding flag is inferred to be opposite to an explicitly signaled merge mode flag for the current block (i.e. Alternatively, partial_split_mode_flag,
which includes opposite meaning of split_mode_flag, may be used) [Ikai: col. 28, line 50-52].
It would have been obvious to one with an ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhang and ITU-T with Ikai to implement Ikai’s method.
Therefore, the combination of Zhang and ITU-T with Ikai will enable the system to improve coding efficiency [Ikai: col. 4, line 53-56].
Regarding claims 2, 7, and 12, Zhang meets the claim limitation as set forth in claims 1, 6, and 11. Zhang further meets the claim limitation as follow.
in response to determining (i.e. based on the determination) [Zhang: para. 0139] that the information of merge modes (i.e. The technique of deriving the motion information from a current block's spatial and/or temporal neighbors may be referred to as a merge mode) [Zhang: para. 0096] comprises a flag (i.e. The syntax table for an illumination compensation indication (e.g., an LIC flag) may be used to determine whether to encode the illumination compensation indication. The syntax table may be shared across an encoder and/or decoder) [Zhang: para. 0115] indicating application of a merge mode in the first group of merge modes ((i.e. The decoder may perform prediction (e.g., motion compensation) on the current CU based on the determination whether to parse the illumination compensation indication for the current CU.) [Zhang: para. 0144; Fig. 3]; (i.e. The syntax table for an illumination compensation indication (e.g., an LIC flag) may be used to determine whether to encode the illumination compensation indication. The syntax table may be shared across an encoder and/or decoder) [Zhang: para. 0115]; (i.e. the prediction mode (e.g., MC prediction mode) for the current CU is a regular merge mode) [Zhang: para. 0133]), deriving (i.e. FIG. 13 illustrates an example LIC flag derivation for ATMVP and/or STMVP coding unit (CU)) [Zhang: para. 0023; Fig. 13] motion information of the current block using a merge mode in the first group of merge modes ((i.e. The order of checking the merge candidates may be predefined. If the order of checking the merge candidate is predefined, each of the merge candidate may be indexed (e.g., by the encoder). The index may be signaled to the decoder. By decoding the merge candidate index in the decoder side, the decoder may gain the knowledge about from which block prediction information may be copied. A PU may be reconstructed using the prediction information) [Zhang: para. 0098]; (i.e. the prediction mode (e.g., MC prediction mode) for the current CU is a regular merge mode) [Zhang: para. 0133]).
Regarding claims 3, 8, 13, Zhang meets the claim limitations as set forth in claims 1, 6, and 11. Zhang further meets the claim limitations as follow.
in response to determining (i.e. based on the determination) [Zhang: para. 0139] that the information of merge modes (i.e. The technique of deriving the motion information from a current block's spatial and/or temporal neighbors may be referred to as a merge mode) [Zhang: para. 0096] comprises a flag (i.e. The syntax table for an illumination compensation indication (e.g., an LIC flag) may be used to determine whether to encode the illumination compensation indication. The syntax table may be shared across an encoder and/or decoder) [Zhang: para. 0115] indicating non-application of a merge mode ((i.e. The decoder may perform prediction (e.g., motion compensation) on the current CU based on the determination whether to parse the illumination compensation indication for the current CU.) [Zhang: para. 0144; Fig. 3]; (i.e. A CU that is coded using an intra mode and/or regular affine motion prediction mode may not code the LIC flag (e.g., since LIC does not apply to such a CU)) [Zhang: para. 0115; Fig. 3]) in the first group of merge modes (i.e. the prediction mode (e.g., MC prediction mode) for the current CU is a regular merge mode) [Zhang: para. 0133], deriving (i.e. FIG. 13 illustrates an example LIC flag derivation for ATMVP and/or STMVP coding unit (CU)) [Zhang: para. 0023; Fig. 13], by the decoder (i.e. decoder) [Zhang: para. 0003], motion information of the current block using a merge mode in the second group of merge modes (i.e. The syntax table for an illumination compensation indication (e.g., an LIC flag) may be used to determine whether to encode the illumination compensation indication. The syntax table may be shared across an encoder and/or decoder) [Zhang: para. 0115]; (i.e. The signaling of the illumination compensation indication may be bypassed for certain FRUC merge modes (e.g., a FRUC bi-lateral mode). The CU structure of a FRUC merge candidate may resemble the CU structure of a merge candidate or other prediction modes (e.g., a ATMVP or STMVP merge candidate). An illumination compensation indication (e.g., an UC flag) for certain FRUC merge modes may not be signaled. An FRUC merge mode may include a bi-lateral mode and/or a template mode) [Zhang: para. 0142; Fig. 13]).
Regarding claims 4, 9, 14, Zhang meets the claim limitations as set forth in claim 1, 6, 11.Zhang further meets the claim limitations as follow.
wherein the flag indicating whether to apply one of the plurality of enabled merge modes (i.e. the illumination compensation process may be disabled for the sub-CU blocks that are coded by bi-prediction, and the LIC operation or process may be enabled for the sub-CU blocks which are coded by uni-prediction. The LIC flag may be set for a (e.g., each) sub-CU block, for example, when the CU level LIC flag indicates that LIC is to be applied.) [Zhang: para. 0135] in the second group of merge modes (i.e. The signaling of the illumination compensation indication may be bypassed for certain FRUC merge modes (e.g., a FRUC bi-lateral mode). The CU structure of a FRUC merge candidate may resemble the CU structure of a merge candidate or other prediction modes (e.g., a ATMVP or STMVP merge candidate). An illumination compensation indication (e.g., an UC flag) for certain FRUC merge modes may not be signaled. An FRUC merge mode may include a bi-lateral mode and/or a template mode) [Zhang: para. 0142; Fig. 13]) is derived according to a sequence parameter set (SPS) flag (i.e. The syntax table for an illumination compensation indication (e.g., an LIC flag) may be used to determine whether to encode the illumination compensation indication. The syntax table may be shared across an encoder and/or decoder) [Zhang: para. 0115]; (i.e. The signaling of the illumination compensation indication may be bypassed for certain FRUC merge modes (e.g., a FRUC bi-lateral mode). The CU structure of a FRUC merge candidate may resemble the CU structure of a merge candidate or other prediction modes (e.g., a ATMVP or STMVP merge candidate). An illumination compensation indication (e.g., an UC flag) for certain FRUC merge modes may not be signaled. An FRUC merge mode may include a bi-lateral mode and/or a template mode) [Zhang: para. 0142; Fig. 13]), and size constraints of the one of the plurality of enabled merge mode (i.e. the threshold T may be determined based on the block size of the current CU and/or based on local statistics (e.g., the sample variance of the current block)) [Zhang: para. 0157].
Zhang does not explicitly disclose the following claim limitations (Emphasis added).
wherein the flag indicating whether to apply one of the at least one enabled merge mode in the second group of merge modes is derived according to a sequence parameter set (SPS) flag.
However, in the same field of endeavor ITU-T further discloses the claim limitations as follows:
wherein the flag indicating whether to apply one of the at least one enabled merge mode in the second group of merge modes is derived (i.e. ciip_flag[x0 lly0] specifies whether the combined inter-picture merge and intra-picture prediction is applied for the current coding unit. The array indices x0, y0 specify the location (x0, y0 ) of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture. When ciip_flag[ x0 II y0 ] is not present, it is inferred to be equal to 0. The syntax elements ciip_Iuma_mpm_flag[ x0 II y0 ], and ciip_Iuma_mpm_idx[ x0 II y0] specify the intra prediction mode for luma samples used in combined inter-picture merge and intra-picture predictio11 The array indices x0, y0 specify the location ( x0 , y0 ) of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture. The intra prediction mode is derived according to clause 8.5.6) [ITU-T: page 95] according to a sequence parameter set (SPS) flag ((i.e. Incorporated multiple transfrom selection (MTS) for both intra and inter, each controlled by an SPS flag.) [ITU-T: page 2]; (i.e. conditioned combined merge/intra syntax on sps_ciip_ enabled_ flag) [ITU-T: page 3]).
It would have been obvious to one with an ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhang and Li with ITU-T to implement the ITU-T VVC standard.
Therefore, the combination of Zhang and Li with ITU-T will enable the system to be compliant with the VVC international video coding standard.
Regarding claims 5, 10, 15, Zhang meets the claim limitations as set forth in claim 1, 6, 11.Zhang further meets the claim limitations as follow.
wherein the regular merge mode (i.e. the prediction mode (e.g., MC prediction mode) for the current CU is a regular merge mode) [Zhang: para. 0133] is signaled ((i.e. a FIG. 11 illustrates an example local illumination compensation (LIC) flag signaling for an explicit inter prediction mode) [Zhang: para. 0021; Fig. 11]; (i.e. the MC prediction mode is a bi-prediction mode and that a first motion vector associated with a first bi-prediction signal versus a second motion vector associated with a second bi-prediction signal is proportional to a first temporal distance between the first bi-prediction signal and the current coding unit versus a second temporal distance between the second bi-prediction signal and the current coding unit) [Zhang: claim 16]) using Context-Adaptive Binary Arithmetic Coding (CABAC) with multiple context models and selection of the multiple context models (i.e. If the difference between Vt-3 and Vt is greater than at least one of a minimum illumination change, a minimal illumination change, a threshold illumination change, or a selected illumination change, poor motion-compensated prediction may ensue, and/or illumination compensation may be needed. If the difference between Vt-3 and Vt is less than or equal to at least one of a minimum illumination change, a minimal illumination change, a threshold illumination change, or a selected illumination change, illumination compensation may not be needed) [Zhang: para. 0117] is based on a skip flag of the current block (i.e. For a regular merge, ATMVP merge, and/or STMVP merge mode, the signaling of the LIC flag may be skipped (e.g., bypassed). The LIC flag of the current block may be derived from the current block's spatial and/or temporal neighboring block(s)) [Zhang: para. 0115; Table 1].
Zhang does not explicitly disclose the following claim limitations (Emphasis added).
wherein the regular merge mode is signaled using Context-Adaptive Binary Arithmetic Coding (CABAC) with multiple context models and selection of the multiple context models is based on a skip flag of the current block.
However, in the same field of endeavor ITU-T further discloses the claim limitations as follows:
using Context-Adaptive Binary Arithmetic Coding (CABAC) (i.e. CABAC Context-based Adaptive Binary Arithmetic Coding) [ITU-T: page 7] with multiple context models (i.e. cabac init flag specifies the method for determining the initialization table used in the initialization process for context variables.) [ITU-T: page 78; Please also read more detail description of CABAC with multiple contexts in Section 9.5; Figures. 9-1 to 9-7; Tables 9-4 to 9-16]).
It would have been obvious to one with an ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhang and Li with ITU-T to implement the ITU-T VVC standard.
Therefore, the combination of Zhang and Li with ITU-T will enable the system to be compliant with the VVC international video coding standard.
Regarding claim 6, Zhang meets the claim limitations as follow.
An apparatus for video coding ((i.e. a video encoding) [Zhang: para. 0012; Fig. 2]; (i.e. a video decoding) [Zhang: para. 0013; Fig. 3]), comprising: one or more processors (i.e. a computer or processor) [Zhang: para. 0161]; and a memory (i.e. a computer-readable medium) [Zhang: para. 0161] configured to store instructions executable by the one or more processors (i.e. the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor.) [Zhang: para. 0161]; wherein the one or more processors (i.e. a computer or processor) [Zhang: para. 0161], upon execution of the instructions, are configured to (i.e. the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor.) [Zhang: para. 0161]:
obtain (i.e. One or more (e.g., all) the prediction information of the current block may be obtained) [Zhang: para. 0132; Fig. 3] a plurality of variables ((i.e. LIC flag) [Zhang: para. 0135; Fig. 12]; (i.e. The variable i may be checked) [Zhang: para. 0139; Fig. 13]) for determining enablement status (i.e. When the techniques described herein are applied for ATMVP and/or STMVP, the illumination compensation process may be disabled for the sub-CU blocks that are coded by bi-prediction, and the LIC operation or process may be enabled for the sub-CU blocks which are coded by uni-prediction. The LIC flag may be set for a (e.g., each) sub-CU block, for example, when the CU level LIC flag indicates that LIC is to be applied.) [Zhang: para. 0135]; (i.e. A determination may be made as to whether the CU-level illumination compensation indication has a value that indicates UC process may be enabled at 1316. If the CU-level illumination compensation indication has a value that indicates LIC process may be enabled, the LIC process may be performed for the sub-CU1 at 1318.) [Zhang: para. 0140; Fig. 13]) of a plurality of merge modes in a second group of merge modes ((i.e. Various prediction modes may be used for motion compensation. Motion compensation may be affected by illumination changes between a current block and one or more reference blocks. A decoder may use illumination compensation to address illumination changes that affect the motion compensation. One or more prediction modes may be indicative of continuous motion changes between the current block and one or more reference blocks.) [Zhang: para. 0003]; (i.e. The signaling of the illumination compensation indication may be bypassed for certain ATMVP and/or STMVP merge modes. For ATMVP and/or STMVP merge candidates, the LIC flag may be derived from the first merge candidate in the merge candidate list. For an ATMVP and/or STMVP merge mode, whether the CU is uni- or bi-predicted may be determined or defined using different approaches. For bi-prediction within an explicit inter prediction or regular merge CU, two motion vectors may be provided for the CU) [Zhang: para. 0134]; (i.e. The decoder may perform prediction (e.g., motion compensation) on the current CU based on the determination whether to parse the illumination compensation indication for the current CU) [Zhang: para. 0144; Fig. 3]; (i.e. The syntax table for an illumination compensation indication (e.g., an LIC flag) may be used to determine whether to encode the illumination compensation indication. The syntax table may be shared across an encoder and/or decoder) [Zhang: para. 0115]; (i.e. The signaling of the illumination compensation indication may be bypassed for certain FRUC merge modes (e.g., a FRUC bi-lateral mode). The CU structure of a FRUC merge candidate may resemble the CU structure of a merge candidate or other prediction modes (e.g., a ATMVP or STMVP merge candidate). An illumination compensation indication (e.g., an UC flag) for certain FRUC merge modes may not be signaled. An FRUC merge mode may include a bi-lateral mode and/or a template mode) [Zhang: para. 0142; Fig. 13]); in response to determining (i.e. based on the determination) [Zhang: para. 0139] from the plurality of variables that no merge mode in the second group of merge modes is enabled ((i.e. based on the determination to disable the LIC process, for example, by setting the CU level illumination compensation indication to a value that indicates LIC process may be disabled) [Zhang: para. 0139]; (i.e. When the techniques described herein are applied for ATMVP and/or STMVP, the illumination compensation process may be disabled for the sub-CU blocks that are coded by bi-prediction) [Zhang: para. 0135]), determining (i.e. a value that indicates LIC process may be disabled. Motion compensation may be performed on the current CU without LIC based on the determination to disable the LIC process, for example, by setting the CU level illumination compensation indication to a value that indicates LIC process may be disabled) [Zhang: para. 0137; Fig. 13] information of merge modes for deriving motion information of a current block (i.e. The decoder may perform prediction (e.g., motion compensation) on the current CU based on the determination whether to parse the illumination compensation indication for the current CU. The decoder may determine to disable the illumination compensation process on the current CU if the decoder determines to bypass parsing the illumination compensation indication for the current CU.) [Zhang: para. 0144; Fig. 3] of a plurality of blocks partitioned from a frame (i.e. A CU may be partitioned into prediction units or PU, for which separate prediction methods may be applied. For each input video block (e.g., MB or CU), spatial prediction 760 and/or temporal motion prediction 762 may be performed. Spatial prediction (e.g., or intra prediction) may use pixels from the already coded neighboring blocks in the same video picture and/or slice to predict the current video block) [Zhang: para. 0081], wherein the information of merge modes (i.e. The technique of deriving the motion information from a current block's spatial and/or temporal neighbors may be referred to as a merge mode) [Zhang: para. 0096] comprises a flag (i.e. The syntax table for an illumination compensation indication (e.g., an LIC flag) may be used to determine whether to encode the illumination compensation indication. The syntax table may be shared across an encoder and/or decoder) [Zhang: para. 0115] indicating whether to apply a merge mode in a first group of merge modes ((i.e. the prediction mode (e.g., MC prediction mode) for the current CU is a regular merge mode) [Zhang: para. 0133]; (i.e. The signaling of the illumination compensation indication may be bypassed for certain FRUC merge modes (e.g., a FRUC bi-lateral mode). The CU structure of a FRUC merge candidate may resemble the CU structure of a merge candidate or other prediction modes (e.g., a ATMVP or STMVP merge candidate). An illumination compensation indication (e.g., an UC flag) for certain FRUC merge modes may not be signaled. An FRUC merge mode may include a bi-lateral mode and/or a template mode) [Zhang: para. 0142; Fig. 13]); and in response to determining (i.e. based on the determination) [Zhang: para. 0139] from the plurality of variables that the plurality of merge modes in the second group of merge modes are enabled (i.e. FIG. 13 illustrates an example UC flag derivation for ATMVP and/or STMVP CU. As shown in FIG. 13, ATMVP and/or STMVP prediction information may be received. An LIC flag may be derived (e.g., from a neighboring merge candidate) at 1302. CU-level motion vectors may be derived at 1304. At 1306, it may be determined whether a CU-level illumination compensation indication has a value that indicates LIC process may be enabled) [Zhang: para. 0138] information of merge modes for deriving motion information of the current block (i.e. The GBi mode may be extended to temporal prediction techniques that support bi-prediction, including one of more of merge modes, advance temporal motion vector prediction (ATMVP), spatial temporal motion vector prediction (STMVP), and/or frame-rate up conversion (FRUC). A merge mode may be performed. Motion information from spatial and/or temporal neighboring blocks may be derived. The motion information may not be searched using motion estimation. The technique of deriving the motion information from a current block's spatial and/or temporal neighbors may be referred to as a merge mode) [Zhang: para. 0095-0096], wherein the information of merge modes (i.e. The technique of deriving the motion information from a current block's spatial and/or temporal neighbors may be referred to as a merge mode) [Zhang: para. 0096] comprises a flag (i.e. The syntax table for an illumination compensation indication (e.g., an LIC flag) may be used to determine whether to encode the illumination compensation indication. The syntax table may be shared across an encoder and/or decoder) [Zhang: para. 0115] indicating whether to apply one of the plurality of enabled merge modes in the second group of merge modes ((i.e. The LIC flag may be a CU level flag that may be signaled for an inter prediction mode (e.g., explicit inter prediction mode)) [Zhang: para. 0128]; (i.e. The GBi mode may be extended to temporal prediction techniques that support bi-prediction, including one of more of merge modes, advance temporal motion vector prediction (ATMVP), spatial temporal motion vector prediction (STMVP), and/or frame-rate up conversion (FRUC). A merge mode may be performed. Motion information from spatial and/or temporal neighboring blocks may be derived. The motion information may not be searched using motion estimation. The technique of deriving the motion information from a current block's spatial and/or temporal neighbors may be referred to as a merge mode) [Zhang: para. 0095-0096]),wherein the first group of merge modes comprises a regular merge mode (i.e. the prediction mode (e.g., MC prediction mode) for the current CU is a regular merge mode) [Zhang: para. 0133], and the second group of merge modes comprises a combined inter and intra prediction (CIIP) merge mode (i.e. LIC may be combined with some prediction techniques (e.g., some advanced prediction techniques). For example, the advanced prediction techniques may include ATMVP, STMVP, and FRUC) [Zhang: para. 0122]; and wherein in response to determining that (i.e. based on the determination) [Zhang: para. 0139] a certain merge mode is enabled (i.e. When the techniques described herein are applied for ATMVP and/or STMVP, the illumination compensation process may be disabled for the sub-CU blocks that are coded by bi-prediction, and the LIC operation or process may be enabled for the sub-CU blocks which are coded by uni-prediction. The LIC flag may be set for a (e.g., each) sub-CU block, for example, when the CU level LIC flag indicates that LIC is to be applied.) [Zhang: para. 0135]; (i.e. A determination may be made as to whether the CU-level illumination compensation indication has a value that indicates UC process may be enabled at 1316. If the CU-level illumination compensation indication has a value that indicates LIC process may be enabled, the LIC process may be performed for the sub-CU1 at 1318.) [Zhang: para. 0140; Fig. 13]) but a corresponding flag is not signaled (i.e. A CU that is coded using an intra mode and/or regular affine motion prediction mode may not code the LIC flag (e.g., since LIC does not apply to such a CU)) [Zhang: para. 0115; Fig. 3]; (i.e. When LIC_Flag[x0 ][y0] is not present) [Zhang: para. 0152]), inferring (i.e. When LIC_Flag[x0 ][y0] is not present, the inferred value of LIC_Flag[x0][y0] may be equal to 0) [Zhang: para. 0152], a value of the corresponding flag is inferred to be opposite to an explicitly signaled merge mode flag for the current block (i.e. When LIC_Flag[x0 ][y0] is not present, the inferred value of LIC_Flag[x0][y0] may be equal to 0) [Zhang: para. 0152].
Zhang does not explicitly disclose the following claim limitations (Emphasis added).
the second group of merge modes comprises a combined inter and intra prediction (CIIP) merge mode.
a value of the corresponding flag is inferred to be opposite to an explicitly signaled merge mode flag for the current block
However, in the same field of endeavor ITU-T further discloses the claim limitations as follows:
the second group of merge modes comprises a combined inter and intra prediction (CIIP) merge mode (i.e. ciip_flag[x0 lly0] specifies whether the combined inter-picture merge and intra-picture prediction is applied for the current coding unit. The array indices x0, y0 specify the location (x0, y0 ) of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture. When ciip_flag[ x0 II y0 ] is not present, it is inferred to be equal to 0. The syntax elements ciip_Iuma_mpm_flag[ x0 II y0 ], and ciip_Iuma_mpm_idx[ x0 II y0] specify the intra prediction mode for luma samples used in combined inter-picture merge and intra-picture predictio11 The array indices x0, y0 specify the location ( x0 , y0 ) of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture. The intra prediction mode is derived according to clause 8.5.6) [ITU-T: page 95].
inferring, …, a value of the corresponding flag as opposite to explicitly signaled merge mode flags for the current block (i.e. sps explicit_ mts intra_ enabled_ flag equal to 1 specifies that tu_ mts idx may be present in the transform unit syntax for intra coding units. sps explicit_ rnts intra_ enabled_ flag equal to 0 specifies that tu_ rnts idx is not present in the transform unit syntax for intra coding units. When not present, the value of sps_explicit_rnts_intra_enabled_flag is inferred to be equal to 0. sps explicit_ mts inter_ enabled_ flag equal to 1 specifies that tu_ rnts idx may be present in the transform unit syntax for inter coding units. sps explicit_ rnts inter_ enabled_ flag equal to 0 specifies that tu_ rnts idx is not present in the transform unit syntax for inter coding units. When not present, the value of sps_explicit_rnts_inter_enabled_flag is inferred to be equal to 0) [ITU-T: page 66]).
It would have been obvious to one with an ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhang with ITU-T to implement the ITU-T VVC standard.
Therefore, the combination of Zhang with ITU-T will enable the system to be compliant with the VVC international video coding standard.
In the same field of endeavor, Ikai further discloses the claim limitations as follows:
a value of the corresponding flag is inferred to be opposite to an explicitly signaled merge mode flag for the current block (i.e. Alternatively, partial_split_mode_flag,
which includes opposite meaning of split_mode_flag, may be used) [Ikai: col. 28, line 50-52].
It would have been obvious to one with an ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhang and ITU-T with Ikai to implement Ikai’s method.
Therefore, the combination of Zhang and ITU-T with Ikai will enable the system to improve coding efficiency [Ikai: col. 4, line 53-56].
Regarding claim 11, Zhang meets the claim limitations as follow.
A non-transitory computer readable storage medium (i.e. a computer-readable medium) [Zhang: para. 0161] having a bitstream stored therein, wherein the bitstream is to be decoded (i.e. the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor.) [Zhang: para. 0161] by a method (i.e. methods) [Zhang: para. 0003] for video decoding comprising (i.e. a video decoding) [Zhang: para. 0003; Fig. 3]:
obtaining (i.e. One or more (e.g., all) the prediction information of the current block may be obtained) [Zhang: para. 0132; Fig. 3] a plurality of variables ((i.e. LIC flag) [Zhang: para. 0135; Fig. 12]; (i.e. The variable i may be checked) [Zhang: para. 0139; Fig. 13]) for determining enablement status (i.e. When the techniques described herein are applied for ATMVP and/or STMVP, the illumination compensation process may be disabled for the sub-CU blocks that are coded by bi-prediction, and the LIC operation or process may be enabled for the sub-CU blocks which are coded by uni-prediction. The LIC flag may be set for a (e.g., each) sub-CU block, for example, when the CU level LIC flag indicates that LIC is to be applied.) [Zhang: para. 0135]; (i.e. A determination may be made as to whether the CU-level illumination compensation indication has a value that indicates UC process may be enabled at 1316. If the CU-level illumination compensation indication has a value that indicates LIC process may be enabled, the LIC process may be performed for the sub-CU1 at 1318.) [Zhang: para. 0140; Fig. 13]) of a plurality of merge modes in a second group of merge modes ((i.e. Various prediction modes may be used for motion compensation. Motion compensation may be affected by illumination changes between a current block and one or more reference blocks. A decoder may use illumination compensation to address illumination changes that affect the motion compensation. One or more prediction modes may be indicative of continuous motion changes between the current block and one or more reference blocks.) [Zhang: para. 0003]; (i.e. The signaling of the illumination compensation indication may be bypassed for certain ATMVP and/or STMVP merge modes. For ATMVP and/or STMVP merge candidates, the LIC flag may be derived from the first merge candidate in the merge candidate list. For an ATMVP and/or STMVP merge mode, whether the CU is uni- or bi-predicted may be determined or defined using different approaches. For bi-prediction within an explicit inter prediction or regular merge CU, two motion vectors may be provided for the CU) [Zhang: para. 0134]; (i.e. The decoder may perform prediction (e.g., motion compensation) on the current CU based on the determination whether to parse the illumination compensation indication for the current CU) [Zhang: para. 0144; Fig. 3]; (i.e. The syntax table for an illumination compensation indication (e.g., an LIC flag) may be used to determine whether to encode the illumination compensation indication. The syntax table may be shared across an encoder and/or decoder) [Zhang: para. 0115]; (i.e. The signaling of the illumination compensation indication may be bypassed for certain FRUC merge modes (e.g., a FRUC bi-lateral mode). The CU structure of a FRUC merge candidate may resemble the CU structure of a merge candidate or other prediction modes (e.g., a ATMVP or STMVP merge candidate). An illumination compensation indication (e.g., an UC flag) for certain FRUC merge modes may not be signaled. An FRUC merge mode may include a bi-lateral mode and/or a template mode) [Zhang: para. 0142; Fig. 13]); in response to determining (i.e. based on the determination) [Zhang: para. 0139] from the plurality of variables that no merge mode in the second group of merge modes is enabled ((i.e. based on the determination to disable the LIC process, for example, by setting the CU level illumination compensation indication to a value that indicates LIC process may be disabled) [Zhang: para. 0139]; (i.e. When the techniques described herein are applied for ATMVP and/or STMVP, the illumination compensation process may be disabled for the sub-CU blocks that are coded by bi-prediction) [Zhang: para. 0135]), determining (i.e. a value that indicates LIC process may be disabled. Motion compensation may be performed on the current CU without LIC based on the determination to disable the LIC process, for example, by setting the CU level illumination compensation indication to a value that indicates LIC process may be disabled) [Zhang: para. 0137; Fig. 13], by the decoder (i.e. a decoder) [Zhang: para. 0003; Fig. 3], information of merge modes for deriving motion information of a current block (i.e. The decoder may perform prediction (e.g., motion compensation) on the current CU based on the determination whether to parse the illumination compensation indication for the current CU. The decoder may determine to disable the illumination compensation process on the current CU if the decoder determines to bypass parsing the illumination compensation indication for the current CU.) [Zhang: para. 0144; Fig. 3] of a plurality of blocks partitioned from a frame (i.e. A CU may be partitioned into prediction units or PU, for which separate prediction methods may be applied. For each input video block (e.g., MB or CU), spatial prediction 760 and/or temporal motion prediction 762 may be performed. Spatial prediction (e.g., or intra prediction) may use pixels from the already coded neighboring blocks in the same video picture and/or slice to predict the current video block) [Zhang: para. 0081], wherein the information of merge modes (i.e. The technique of deriving the motion information from a current block's spatial and/or temporal neighbors may be referred to as a merge mode) [Zhang: para. 0096] comprises a flag (i.e. The syntax table for an illumination compensation indication (e.g., an LIC flag) may be used to determine whether to encode the illumination compensation indication. The syntax table may be shared across an encoder and/or decoder) [Zhang: para. 0115] indicating whether to apply a merge mode in a first group of merge modes ((i.e. the prediction mode (e.g., MC prediction mode) for the current CU is a regular merge mode) [Zhang: para. 0133]; (i.e. The signaling of the illumination compensation indication may be bypassed for certain FRUC merge modes (e.g., a FRUC bi-lateral mode). The CU structure of a FRUC merge candidate may resemble the CU structure of a merge candidate or other prediction modes (e.g., a ATMVP or STMVP merge candidate). An illumination compensation indication (e.g., an UC flag) for certain FRUC merge modes may not be signaled. An FRUC merge mode may include a bi-lateral mode and/or a template mode) [Zhang: para. 0142; Fig. 13]); and in response to determining (i.e. based on the determination) [Zhang: para. 0139] from the plurality of variables that the plurality of merge modes in the second group of merge modes are enabled (i.e. FIG. 13 illustrates an example UC flag derivation for ATMVP and/or STMVP CU. As shown in FIG. 13, ATMVP and/or STMVP prediction information may be received. An LIC flag may be derived (e.g., from a neighboring merge candidate) at 1302. CU-level motion vectors may be derived at 1304. At 1306, it may be determined whether a CU-level illumination compensation indication has a value that indicates LIC process may be enabled) [Zhang: para. 0138] information of merge modes for deriving motion information of the current block (i.e. The GBi mode may be extended to temporal prediction techniques that support bi-prediction, including one of more of merge modes, advance temporal motion vector prediction (ATMVP), spatial temporal motion vector prediction (STMVP), and/or frame-rate up conversion (FRUC). A merge mode may be performed. Motion information from spatial and/or temporal neighboring blocks may be derived. The motion information may not be searched using motion estimation. The technique of deriving the motion information from a current block's spatial and/or temporal neighbors may be referred to as a merge mode) [Zhang: para. 0095-0096], wherein the information of merge modes (i.e. The technique of deriving the motion information from a current block's spatial and/or temporal neighbors may be referred to as a merge mode) [Zhang: para. 0096] comprises a flag (i.e. The syntax table for an illumination compensation indication (e.g., an LIC flag) may be used to determine whether to encode the illumination compensation indication. The syntax table may be shared across an encoder and/or decoder) [Zhang: para. 0115] indicating whether to apply one of the plurality of enabled merge modes in the second group of merge modes ((i.e. The LIC flag may be a CU level flag that may be signaled for an inter prediction mode (e.g., explicit inter prediction mode)) [Zhang: para. 0128]; (i.e. The GBi mode may be extended to temporal prediction techniques that support bi-prediction, including one of more of merge modes, advance temporal motion vector prediction (ATMVP), spatial temporal motion vector prediction (STMVP), and/or frame-rate up conversion (FRUC). A merge mode may be performed. Motion information from spatial and/or temporal neighboring blocks may be derived. The motion information may not be searched using motion estimation. The technique of deriving the motion information from a current block's spatial and/or temporal neighbors may be referred to as a merge mode) [Zhang: para. 0095-0096]),wherein the first group of merge modes comprises a regular merge mode (i.e. the prediction mode (e.g., MC prediction mode) for the current CU is a regular merge mode) [Zhang: para. 0133], and the second group of merge modes comprises a combined inter and intra prediction (CIIP) merge mode (i.e. LIC may be combined with some prediction techniques (e.g., some advanced prediction techniques). For example, the advanced prediction techniques may include ATMVP, STMVP, and FRUC) [Zhang: para. 0122]; and wherein in response to determining that (i.e. based on the determination) [Zhang: para. 0139] a certain merge mode is enabled (i.e. When the techniques described herein are applied for ATMVP and/or STMVP, the illumination compensation process may be disabled for the sub-CU blocks that are coded by bi-prediction, and the LIC operation or process may be enabled for the sub-CU blocks which are coded by uni-prediction. The LIC flag may be set for a (e.g., each) sub-CU block, for example, when the CU level LIC flag indicates that LIC is to be applied.) [Zhang: para. 0135]; (i.e. A determination may be made as to whether the CU-level illumination compensation indication has a value that indicates UC process may be enabled at 1316. If the CU-level illumination compensation indication has a value that indicates LIC process may be enabled, the LIC process may be performed for the sub-CU1 at 1318.) [Zhang: para. 0140; Fig. 13]) but a corresponding flag is not signaled (i.e. A CU that is coded using an intra mode and/or regular affine motion prediction mode may not code the LIC flag (e.g., since LIC does not apply to such a CU)) [Zhang: para. 0115; Fig. 3]; (i.e. When LIC_Flag[x0 ][y0] is not present) [Zhang: para. 0152]), inferring (i.e. When LIC_Flag[x0 ][y0] is not present, the inferred value of LIC_Flag[x0][y0] may be equal to 0) [Zhang: para. 0152], a value of the corresponding flag is inferred to be opposite to an explicitly signaled merge mode flag for the current block (i.e. When LIC_Flag[x0 ][y0] is not present, the inferred value of LIC_Flag[x0][y0] may be equal to 0) [Zhang: para. 0152].
Zhang does not explicitly disclose the following claim limitations (Emphasis added).
the second group of merge modes comprises a combined inter and intra prediction (CIIP) merge mode.
a value of the corresponding flag is inferred to be opposite to an explicitly signaled merge mode flag for the current block
However, in the same field of endeavor ITU-T further discloses the claim limitations as follows:
the second group of merge modes comprises a combined inter and intra prediction (CIIP) merge mode (i.e. ciip_flag[x0 lly0] specifies whether the combined inter-picture merge and intra-picture prediction is applied for the current coding unit. The array indices x0, y0 specify the location (x0, y0 ) of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture. When ciip_flag[ x0 II y0 ] is not present, it is inferred to be equal to 0. The syntax elements ciip_Iuma_mpm_flag[ x0 II y0 ], and ciip_Iuma_mpm_idx[ x0 II y0] specify the intra prediction mode for luma samples used in combined inter-picture merge and intra-picture predictio11 The array indices x0, y0 specify the location ( x0 , y0 ) of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture. The intra prediction mode is derived according to clause 8.5.6) [ITU-T: page 95].
inferring, …, a value of the corresponding flag as opposite to explicitly signaled merge mode flags for the current block (i.e. sps explicit_ mts intra_ enabled_ flag equal to 1 specifies that tu_ mts idx may be present in the transform unit syntax for intra coding units. sps explicit_ rnts intra_ enabled_ flag equal to 0 specifies that tu_ rnts idx is not present in the transform unit syntax for intra coding units. When not present, the value of sps_explicit_rnts_intra_enabled_flag is inferred to be equal to 0. sps explicit_ mts inter_ enabled_ flag equal to 1 specifies that tu_ rnts idx may be present in the transform unit syntax for inter coding units. sps explicit_ rnts inter_ enabled_ flag equal to 0 specifies that tu_ rnts idx is not present in the transform unit syntax for inter coding units. When not present, the value of sps_explicit_rnts_inter_enabled_flag is inferred to be equal to 0) [ITU-T: page 66]).
It would have been obvious to one with an ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhang with ITU-T to implement the ITU-T VVC standard.
Therefore, the combination of Zhang with ITU-T will enable the system to be compliant with the VVC international video coding standard.
In the same field of endeavor, Ikai further discloses the claim limitations as follows:
a value of the corresponding flag is inferred to be opposite to an explicitly signaled merge mode flag for the current block (i.e. Alternatively, partial_split_mode_flag,
which includes opposite meaning of split_mode_flag, may be used) [Ikai: col. 28, line 50-52].
It would have been obvious to one with an ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Zhang and ITU-T with Ikai to implement Ikai’s method.
Therefore, the combination of Zhang and ITU-T with Ikai will enable the system to improve coding efficiency [Ikai: col. 4, line 53-56].
Regarding claim 16, Zhang meets the claim limitations as set forth in claim 1. Zhang further meets the claim limitations as follow.
performing the method for video coding according to claim 1 to generate the bitstream (Together with the prediction information, some control information from General Control Information and filter control information from Filter Control Analysis may be entropy encoded by the Header Formatting & CABAG block to arrive at the desired encoding bitstream) [Zhang: para. 0082]; and storing the bitstream (The reconstructed block may be put in the reference picture store 764 and used to code future video blocks. To form the output video bit-stream 720, coding mode (e.g., inter or intra), prediction mode information, motion information, and/or quantize d residual coefficients may be sent to the entropy coding unit 708 to be compressed and/or packed to form the bit-stream) [Zhang: para. 0083; Fig. 1] on a non-transitory computer-readable storage medium (the processor 118 may access information from, and store data in, any type of suitable memory) [Zhang: para. 0046; Fig. 1].
Reference Notice
Additional prior arts, included in the Notice of Reference Cited, made of record and not relied upon is considered pertinent to applicant's disclosure.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Philip Dang whose telephone number is (408) 918-7529. The examiner can normally be reached on Monday-Thursday between 8:30 am - 5:00 pm (PST).
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, Sath Perungavoor can be reached on 571-272-7455. 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./Philip P. Dang/Primary Examiner, Art Unit 2488
