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 .
Status of the Application
Claims 1-20 are currently pending in this application.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/22/2025 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory 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 conflicting claims 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); 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 nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined 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 § 2146 et seq. 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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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 www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 3, 4, 6, 7, 9, 14, 15, and 17-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 3, 6, 11-13, and 16-19 of U.S. Patent No. 12,041,268 in view of Pham Van et al. (Hereafter, “Pham”) [US 2020/0021839 A1] in further view of Park et al. (Hereafter, “Park”) [US 2021/0120236 A1]. Although the claims at issue are not identical, they are not patentably distinct from each other because they cover mutually associated subject matter. Thus, a terminal disclaimer is required. An analysis of the claims can be seen in Table 1 below.
Table 1: Instant Application No. 19/335,694 vs. U.S. Patent No. 12,041,268
Instant Application No. 19/335,694 Claims (Difference Emphasis Added)
U.S. Patent No. 12,041,268 Claims (Difference Emphasis Added)
1. A method of video processing, comprising: resetting, for a conversion between a video unit of a video and a bitstream of the video, a history-based motion vector prediction (HMVP) table of size N by adding K HMVP motion candidates to the HMVP table, wherein the K HMVP motion candidates have default values, wherein N and K are positive integers, and wherein K≤N; and performing the conversion between the video unit and the bitstream using the HMVP table that results from the resetting.
1. A method of video processing, comprising: resetting, for a conversion between a video unit of a video and a bitstream of the video, a history-based motion vector prediction (HMVP) table of size N by adding K HMVP motion candidates to the HMVP table, wherein the K HMVP motion candidates have default values, wherein each of the K HMVP motion candidates are identical, wherein N and K are positive integers, and wherein K≤N; and performing the conversion between the video unit and the bitstream using the HMVP table resulting from the resetting.
3. The method of claim 1, wherein at least one of the K HMVP motion candidates is a uni-prediction motion candidate.
3. The method of claim 1, wherein at least one of the K HMVP motion candidates is a uni-prediction motion candidate,
4. The method of claim 3, wherein a reference index of the uni-prediction motion candidate is set to a value less than a number of reference pictures in a prediction direction, and wherein the prediction direction of the uni-prediction motion candidate is set to list 0 (L0) or list 1 (L1).
3. or, the video unit is a P slice or P picture, and wherein a prediction direction of the uni-prediction motion candidate is set to list 0 (L0), or the video unit is a B slice or B picture, and wherein a prediction direction of the uni-prediction motion candidate is set to list 0 (L0) or list 1 (L1).
6. The method of claim 1, wherein at least one of the K HMVP motion candidates is a bi-prediction motion candidate.
6. The method of claim 1, wherein at least one of the K HMVP motion candidates is a bi-prediction motion candidate,
7. The method of claim 6, wherein a reference index of the bi-prediction motion candidate is set to a value less than a number of reference pictures in at least one prediction direction, and wherein the at least one prediction direction of the bi-prediction motion candidate is set to list 0 (L0) or list 1 (L1).
6. the video unit is a P slice or picture, and wherein each prediction direction of the bi-prediction motion candidate is set to list 0 (L0); or the video unit is a B slice or B picture, and wherein at least one prediction direction of the bi-prediction motion candidate is set to list 0 (L0) or list 1 (L1).
9. The method of claim 1, wherein the K HMVP motion candidates used for the HMVP table are different than HMVP motion candidates used for another HMVP table.
13. The method of claim 11, wherein the K HMVP motion candidates used for the HMVP table is different than that used for another HMVP table, optionally, a selection of the K HMVP motion candidates is based on the HMVP table used for a coding mode associated with a video block of the video unit.
14. The method of claim 12, wherein the video unit comprises a picture, a slice, a tile group, a tile, or a coding tree unit (CTU) row.
12. The method of claim 11, wherein the video unit comprises a first coding tree unit (CTU) row, and wherein the second video unit comprises a second CTU row; or the video unit comprises a first tile, and wherein the second video unit comprises a second tile.
15. The method of claim 1, wherein the HMVP table is updated by adding an additional HMVP motion candidate to the HMVP table before all existing HMVP motion candidates in the HMVP table.
11. The method of claim 1, further comprising: adding, to the history-based motion vector prediction (HMVP) table for the video unit, HMVP motion candidates from a first set of K HMVP motion candidates, wherein the first set of K HMVP motion candidates for the video unit is adaptively changed from a second set of K HMVP motion candidates included in the HMVP table for a second video unit of the video, wherein the second video unit is different from the video unit, wherein the first set of K HMVP motion candidates and the second set of K HMVP motion candidates have default values, wherein the HMVP table has a size of N, wherein N and K are positive integers, and wherein K≤N; and wherein the bitstream includes syntax elements indicative of the first set of K HMVP motion candidates added to a HMVP table.
17. The method of claim 1, wherein the conversion includes encoding the video unit into the bitstream.
16. The method of claim 1, wherein the conversion includes encoding the video unit into the bitstream.
18. The method of claim 1, wherein the conversion includes decoding the video unit from the bitstream.
17. The method of claim 1, wherein the conversion includes decoding the video unit from the bitstream.
Claim 19 is the same as claim 1 but in apparatus form.
Claim 18 is the same as claim 1 but in apparatus form.
Claim 20 is the same as claim 1 but in non-transitory computer-readable recording medium form.
Claim 19 is the same as claim 1 but in non-transitory computer-readable recording medium form.
Some of the differences in the claim limitations in the U.S. Patent are narrower than the instant application, and thus it would have been obvious to make the claim limitations in the instant application broader by removing the specific language found in the U.S. Patent.
The U.S. Patent fails to explicitly disclose wherein a reference index of the uni-prediction motion candidate is set to a value less than a number of reference pictures in a prediction direction, and wherein a reference index of the bi-prediction motion candidate is set to a value less than a number of reference pictures in at least one prediction direction, and wherein the video unit comprises a picture, a slice, a tile group, a tile, or a coding tree unit (CTU) row; wherein the HMVP table is updated by adding an additional HMVP motion candidate to the HMVP table before all existing HMVP motion candidates in the HMVP table.
Pham discloses wherein a reference index of the uni-prediction motion candidate is set to a value less than a number of reference pictures in a prediction direction ([0053] In some examples, video encoder 200 may predict the current CU using uni-directional prediction or bi-directional prediction. [0085] FIG. 8 is a conceptual diagram illustrating an example of motion information used for HMVP. [0091] Video encoder 200 and video decoder 300 may pre-fill the history MVP buffer of each CTU line with zero motion vectors with different reference frame index and/or inter-prediction directions, or other pre-defined or derived motion information. [0100] Motion vectors in the buffer can be uni-directional (L0 or L1), bi-directional, or any other motion model MV.), and wherein a reference index of the bi-prediction motion candidate is set to a value less than a number of reference pictures in at least one prediction direction ([0053] In some examples, video encoder 200 may predict the current CU using uni-directional prediction or bi-directional prediction. [0085] FIG. 8 is a conceptual diagram illustrating an example of motion information used for HMVP. [0091] Video encoder 200 and video decoder 300 may pre-fill the history MVP buffer of each CTU line with zero motion vectors with different reference frame index and/or inter-prediction directions, or other pre-defined or derived motion information. [0100] Motion vectors in the buffer can be uni-directional (L0 or L1), bi-directional, or any other motion model MV.), and wherein the video unit comprises a picture, a slice, ([0004] For block-based video coding, a video slice (e.g., a video picture or a portion of a video picture) may be partitioned into video blocks, which may also be referred to as coding tree units (CTUs), coding units (CUs) and/or coding nodes. [0131] CTU row; wherein the HMVP table is updated by adding an additional HMVP motion candidate to the HMVP table before all existing HMVP motion candidates in the HMVP table ([0069] In some examples, video encoder 200 and video decoder 300 may use a first-in-first-out (FIFO) rule to remove motion vectors from the MVP buffer when the MVP buffer becomes full. That is, in order to add a new motion vector to the MVP buffer, video encoder 200 and video decoder 300 may remove an earliest-inserted motion vector from the MVP buffer, and insert the new motion vector into the MVP buffer. In this manner, the MVP buffer may have a queue-like behavior.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention with the teachings of Pham. The motivation behind this modification would have been to improve motion vector prediction in the video coding system [See Pham].
Park discloses wherein the video unit comprises a picture, a slice, a tile group, a tile, or a coding tree unit (CTU) row ([0015] a CTU row in a current tile);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention with the teachings of Park. The motivation behind this modification would have been to improve coding efficiency [See Park].
Claims 1 and 17-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 15-18 of U.S. Patent No. 12,445,643. Although the claims at issue are not identical, they are not patentably distinct from each other because they cover mutually associated subject matter. Thus, a terminal disclaimer is required. An analysis of the claims can be seen in Table 2 below.
Table 2: Instant Application No. 19/335,694 vs. U.S. Patent No. 12,445,643
Instant Application No. 19/335,694 Claims (Difference Emphasis Added)
U.S. Patent No. 12,445,643 Claims (Difference Emphasis Added)
1. A method of video processing, comprising: resetting, for a conversion between a video unit of a video and a bitstream of the video, a history-based motion vector prediction (HMVP) table of size N by adding K HMVP motion candidates to the HMVP table, wherein the K HMVP motion candidates have default values, wherein N and K are positive integers, and wherein K≤N; and performing the conversion between the video unit and the bitstream using the HMVP table that results from the resetting.
1. A method of video processing, comprising: resetting, for a conversion between a video unit of a video and a bitstream of the video, a history-based motion vector prediction (HMVP) table of size N by adding K HMVP motion candidates to the HMVP table, wherein the K HMVP motion candidates have default values, wherein N and K are positive integers, and wherein K≤N; and performing the conversion between the video unit and the bitstream using the HMVP table resulting from the resetting, wherein, for a plurality of P slices or a plurality of P pictures, at least one of the K HMVP motion candidates comprises a motion vector set to (Mv(0,0), i), wherein i is a reference picture index which is in a range between 0 and a number of reference pictures in list 0 minus 1, inclusive, wherein the video unit is a P slice from the plurality of P slices or the video unit is a P picture from the plurality of P pictures, and wherein a counter of available HMVP motion candidates in the HMVP table is excluded from the bitstream of the video in response to K being equal to N.
17. The method of claim 1, wherein the conversion includes encoding the video unit into the bitstream.
15. The method of claim 1, wherein the conversion includes encoding the video unit into the bitstream.
18. The method of claim 1, wherein the conversion includes decoding the video unit from the bitstream.
16. The method of claim 1, wherein the conversion includes decoding the video unit from the bitstream.
Claim 19 is the same as claim 1 but in apparatus form.
Claim 17 is the same as claim 1 but in apparatus form.
Claim 20 is the same as claim 1 but in non-transitory computer-readable recording medium form.
Claim 18 is the same as claim 1 but in non-transitory computer-readable recording medium form.
The differences in the claim limitations in the U.S. Patent are narrower than the instant application, and thus it would have been obvious to make the claim limitations in the instant application broader by removing the specific language found in the U.S. Patent.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Pham Van et al. (Hereafter, “Pham”) [US 2020/0021839 A1].
Regarding claim 20, the claim limitations and recitations of, “non-transitory computer-readable recording medium storing a bitstream of a video which is generated by a method performed by a video processing apparatus, …” is a non- functional descriptive material, wherein no functional relationship exists between the recording medium and the data. "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(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 computer-readable recording medium storing the bitstream in claim 20 merely services as a support for the storage of the bitstream and provides no functional relationship between the bitstream and the computer-readable recording medium. Therefore, the structure data is non-functional descriptive material and given no patentable weight. MPEP §2111.05(III). Thus, the claim scope is just a computer-readable recording medium storing a bitstream generated by a method and is anticipated by Pham which recites a computer-readable recording medium storing the bitstream ([0033] Source device 102 may then output the encoded video data via output interface 108 onto computer-readable medium 110 for reception and/or retrieval by, e.g., input interface 122 of destination device 116. [0172] CPB memory 320 may store video data, such as an encoded video bitstream, to be decoded by the components of video decoder 300. The video data stored in CPB memory 320 may be obtained, for example, from computer-readable medium 110 (FIG. 1).).
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 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 nonobviousness.
Claim(s) 1-4, 6, 7, 9, 11, and 15-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pham Van et al. (Hereafter, “Pham”) [US 2020/0021839 A1] in view of “CE4-related: History-based Motion Vector Prediction” (Hereafter, “Zhang”).
Regarding claim 1, Pham discloses a method of video processing ([0005] A video coder (encoder or decoder) may maintain a table with multiple HMVP candidates during a coding (encoding or decoding) process. The video coder may empty the table when a new slice occurs. When there is an inter-coded block, the video coder may append motion information associated with the inter-coded block to the table.), comprising: resetting, for a conversion between a video unit of a video and a bitstream of the video, a history-based motion vector prediction (HMVP) table of size N by adding K HMVP motion candidates to the HMVP table ([0091] Video encoder 200 and video decoder 300 may reset the history MVP buffer of each CTU line to be empty. Video encoder 200 and video decoder 300 may pre-fill the history MVP buffer of each CTU line with zero motion vectors with different reference frame index and/or inter-prediction directions, or other pre-defined or derived motion information. Video encoder 200 and video decoder 300 may pre-fill the history MVP buffer of each CTU line with motion information from the coded frames (pictures) in the same temporal layer or lower temporal layers (reference pictures that are available for the current frame/picture).), wherein the K HMVP motion candidates have default values ([0091] Video encoder 200 and video decoder 300 may reset the history MVP buffer of each CTU line to be empty. Video encoder 200 and video decoder 300 may pre-fill the history MVP buffer of each CTU line with zero motion vectors with different reference frame index and/or inter-prediction directions, or other pre-defined or derived motion information. Video encoder 200 and video decoder 300 may pre-fill the history MVP buffer of each CTU line with motion information from the coded frames (pictures) in the same temporal layer or lower temporal layers (reference pictures that are available for the current frame/picture).), wherein N and K are positive integers, and wherein K≤N; and performing the conversion between the video unit and the bitstream using the HMVP table that results from the resetting ([0005] A video coder (encoder or decoder) may maintain a table with multiple HMVP candidates during a coding (encoding or decoding) process. The video coder may empty the table when a new slice occurs. When there is an inter-coded block, the video coder may append motion information associated with the inter-coded block to the table.).
Zhang discloses a method of video processing ([Section 2] History-Based MVP method), comprising: resetting ([Section 2] the table is emptied when a new slice is encountered), for a conversion between a video unit of a video and a bitstream of the video, a history-based motion vector prediction (HMVP) table of size N by adding K HMVP motion candidates to the HMVP table ([Section 2] the table size S is set to be 16, which indicates up to 16 HMVP candidates may be added to the table), wherein the K HMVP motion candidates have default values ([Section 2] a HMVP candidate is defined as the motion information of a previously coded block), wherein N and K are positive integers, and wherein K≤N ([Section 2] the table size S is set to be 16, which indicates up to 16 HMVP candidates may be added to the table); and performing the conversion between the video unit and the bitstream using the HMVP table resulting from the resetting ([Fig. 2] decode a block with HMVP candidates using the updated/reset table with decoded motion information).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Pham with the teachings of Zhang in order to improve the coding efficiency of the system.
Regarding claim 2, the limitations of claim 1 have been addressed. Pham discloses wherein at least one motion candidate with a default value is added multiple times into the HMVP table ([0091] Video encoder 200 and video decoder 300 may reset the history MVP buffer of each CTU line to be empty. Video encoder 200 and video decoder 300 may pre-fill the history MVP buffer of each CTU line with zero motion vectors with different reference frame index and/or inter-prediction directions, or other pre-defined or derived motion information. Video encoder 200 and video decoder 300 may pre-fill the history MVP buffer of each CTU line with motion information from the coded frames (pictures) in the same temporal layer or lower temporal layers (reference pictures that are available for the current frame/picture).).
Regarding claim 3, the limitations of claim 1 have been addressed. Pham discloses wherein at least one of the K HMVP motion candidates is a uni-prediction motion candidate ([0053] In some examples, video encoder 200 may predict the current CU using uni-directional prediction or bi-directional prediction. [0085] FIG. 8 is a conceptual diagram illustrating an example of motion information used for HMVP. [0100] Motion vectors in the buffer can be uni-directional (L0 or L1), bi-directional, or any other motion model MV.).
Regarding claim 4, the limitations of claim 3 have been addressed. Pham discloses wherein a reference index of the uni-prediction motion candidate is set to a value less than a number of reference pictures in a prediction direction ([0053] In some examples, video encoder 200 may predict the current CU using uni-directional prediction or bi-directional prediction. [0085] FIG. 8 is a conceptual diagram illustrating an example of motion information used for HMVP. [0091] Video encoder 200 and video decoder 300 may pre-fill the history MVP buffer of each CTU line with zero motion vectors with different reference frame index and/or inter-prediction directions, or other pre-defined or derived motion information. [0100] Motion vectors in the buffer can be uni-directional (L0 or L1), bi-directional, or any other motion model MV.), and wherein the prediction direction of the uni-prediction motion candidate is set to list 0 (L0) or list 1 (L1) ([0108] Video encoder 200 and video decoder 300 may utilize motion information for predicting a block of video data. For each block, a set of motion information can be available. The set of motion information contains motion information for forward and backward prediction directions. Here, forward and backward prediction directions are two prediction directions corresponding to reference picture list 0 (RefPicList0) and reference picture list 1 (RefPicList1) of a current picture or slice.).
Regarding claim 6, the limitations of claim 1 have been addressed. Pham discloses wherein at least one of the K HMVP motion candidates is a bi-prediction motion candidate ([0053] In some examples, video encoder 200 may predict the current CU using uni-directional prediction or bi-directional prediction. [0085] FIG. 8 is a conceptual diagram illustrating an example of motion information used for HMVP. [0091] Video encoder 200 and video decoder 300 may pre-fill the history MVP buffer of each CTU line with zero motion vectors with different reference frame index and/or inter-prediction directions, or other pre-defined or derived motion information. [0100] Motion vectors in the buffer can be uni-directional (L0 or L1), bi-directional, or any other motion model MV.).
Regarding claim 7, the limitations of claim 6 have been addressed. Pham discloses wherein a reference index of the bi-prediction motion candidate is set to a value less than a number of reference pictures in at least one prediction direction ([0053] In some examples, video encoder 200 may predict the current CU using uni-directional prediction or bi-directional prediction. [0085] FIG. 8 is a conceptual diagram illustrating an example of motion information used for HMVP. [0091] Video encoder 200 and video decoder 300 may pre-fill the history MVP buffer of each CTU line with zero motion vectors with different reference frame index and/or inter-prediction directions, or other pre-defined or derived motion information. [0100] Motion vectors in the buffer can be uni-directional (L0 or L1), bi-directional, or any other motion model MV.), and wherein the at least one prediction direction of the bi-prediction motion candidate is set to list 0 (L0) or list 1 (L1) ([0108] Video encoder 200 and video decoder 300 may utilize motion information for predicting a block of video data. For each block, a set of motion information can be available. The set of motion information contains motion information for forward and backward prediction directions. Here, forward and backward prediction directions are two prediction directions corresponding to reference picture list 0 (RefPicList0) and reference picture list 1 (RefPicList1) of a current picture or slice.).
Regarding claim 9, the limitations of claim 1 have been addressed. Pham discloses wherein the K HMVP motion candidates used for the HMVP table are different than HMVP motion candidates used for another HMVP table ([0181] In accordance with the techniques of this disclosure, decoded picture buffer 314 may include one or more history MVP buffers for lines of CTUs. In some examples, video decoder 300 may maintain different respective MVP buffers for each of a variety of motion models, such as, for example, affine motion model, motion information of intra block copy mode, motion information of local illumination compensation, sub-block MVP, and temporal motion prediction.).
Regarding claim 11, the limitations of claim 1 have been addressed. Pham discloses wherein the K HMVP motion candidates added to the HMVP table are signaled in a video parameter set (VPS), a decoder parameter set (DPS), a sequence parameter set (SPS), an adaptation parameter set (APS), a picture parameter set (PPS), a picture header, a slice header, or a tile group header ([0062] Video encoder 200 may further generate syntax data, such as block-based syntax data, picture-based syntax data, and sequence-based syntax data, to video decoder 300, e.g., in a picture header, a block header, a slice header, or other syntax data, such as a sequence parameter set (SPS), picture parameter set (PPS), or video parameter set (VPS). Video decoder 300 may likewise decode such syntax data to determine how to decode corresponding video data. [0096] signaling can be applied to indicate which MVs are selected (e.g., video encoder 200 may encode signaled data, and video decoder 300 may decode the signaled data)).
Regarding claim 15, the limitations of claim 1 have been addressed. Pham discloses wherein the HMVP table is updated by adding an additional HMVP motion candidate to the HMVP table before all existing HMVP motion candidates in the HMVP table ([0069] In some examples, video encoder 200 and video decoder 300 may use a first-in-first-out (FIFO) rule to remove motion vectors from the MVP buffer when the MVP buffer becomes full. That is, in order to add a new motion vector to the MVP buffer, video encoder 200 and video decoder 300 may remove an earliest-inserted motion vector from the MVP buffer, and insert the new motion vector into the MVP buffer. In this manner, the MVP buffer may have a queue-like behavior.).
Regarding claim 16, the limitations of claim 15 have been addressed. Pham discloses wherein an entry index of the HMVP table having a smallest value indicates a latest HMVP motion candidate in the HMVP table, and wherein the additional HMVP motion candidate is added before the latest HMVP motion candidate added to the HMVP table ([Fig. 4 and 0069] In some examples, video encoder 200 and video decoder 300 may use a first-in-first-out (FIFO) rule to remove motion vectors from the MVP buffer when the MVP buffer becomes full. That is, in order to add a new motion vector to the MVP buffer, video encoder 200 and video decoder 300 may remove an earliest-inserted motion vector from the MVP buffer, and insert the new motion vector into the MVP buffer. In this manner, the MVP buffer may have a queue-like behavior.).
Regarding claim 17, the limitations of claim 1 have been addressed. Pham discloses wherein the conversion includes encoding the video unit into the bitstream ([0005] A video coder (encoder or decoder) may maintain a table with multiple HMVP candidates during a coding (encoding or decoding) process. The video coder may empty the table when a new slice occurs. When there is an inter-coded block, the video coder may append motion information associated with the inter-coded block to the table.).
Regarding claim 18, the limitations of claim 1 have been addressed. Pham discloses wherein the conversion includes decoding the video unit from the bitstream ([0005] A video coder (encoder or decoder) may maintain a table with multiple HMVP candidates during a coding (encoding or decoding) process. The video coder may empty the table when a new slice occurs. When there is an inter-coded block, the video coder may append motion information associated with the inter-coded block to the table.).
Claim 19 lists all the same elements of claim 1, but in apparatus form rather than method form. Therefore, the supporting rationale of the rejection to claim 1 applies equally as well to claim 19.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pham in view of Zhang in further view of Xiu et al. (Hereafter, “Xiu”) [US 2016/0360210 A1].
Regarding claim 5, the limitations of claim 3 have been addressed. Pham fails to explicitly disclose wherein a reference picture is set to a current picture associated with the video unit, and wherein a syntax element that indicates that an intra block copy (IBC) mode is enabled for a video block of the video unit is set to 1.
Xiu discloses wherein a reference picture is set to a current picture associated with the video unit, and wherein a syntax element that indicates that an intra block copy (IBC) mode is enabled for a video block of the video unit is set to 1 ([0049] When the IBC mode is enabled (e.g., by setting a flag curr_pic_as_ref_enabled_flag to true), a reference picture list (e.g., reference picture list L0) of the current picture may be constructed in a specific order (e.g., one or more temporal reference pictures before the current picture, one or more temporal reference pictures after the current picture, and the pseudo reference picture (referred to herein as “currPic”)). [0070] IBC mode is enabled when flag is set to 1).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Pham with the teachings of Xiu in order to improve the signalling and efficiency of the system.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pham in view of Zhang in further view of Han et al. (Hereafter, “Han”) [US 2020/0260113 A1].
Regarding claim 10, the limitations of claim 9 have been addressed. Pham fails to explicitly disclose wherein the K HMVP motion candidates used for a video block coded using an inter-coding mode are different than HMVP motion candidates used for a video block coded using an intra block copy (IBC) mode, and wherein the video block belongs to the video unit.
Han discloses wherein the K HMVP motion candidates used for a video block coded using an inter-coding mode are different than HMVP motion candidates used for a video block coded using an intra block copy (IBC) mode, and wherein the video block belongs to the video unit ([0020] In other cases, a video coder may utilize different orders of sources for generating motion vector candidate lists for blocks predicting using inter-mode and blocks predicted using IBC. Where the video coder uses different orders, there may still be some overlap in the candidates considered. For instance, the video coder may evaluate HMVP candidates for inclusion in the motion vector candidate list for both blocks coded using inter and IBC with the condition that a last candidate in the motion vector candidate list cannot be a HMVP candidate.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Pham with the teachings of Han in order to improve efficiency of the video coding device/system using such video coding techniques.
Claim(s) 12-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pham in view of Zhang in further view of Park et al. (Hereafter, “Park”) [US 2021/0120236 A1].
Regarding claim 12, the limitations of claim 1 have been addressed. Pham discloses wherein multiple sets of K HMVP motion candidates are predefined ([0091] Video encoder 200 and video decoder 300 may pre-fill the history MVP buffer of each CTU line with zero motion vectors with different reference frame index and/or inter-prediction directions, or other pre-defined or derived motion information. Video encoder 200 and video decoder 300 may pre-fill the history MVP buffer of each CTU line with motion information from the coded frames (pictures) in the same temporal layer or lower temporal layers (reference pictures that are available for the current frame/picture).), and
Park discloses wherein a representation of the bitstream includes an index of the K HMVP motion candidates within the multiple sets of default K HMVP motion candidates for the video unit ([0102] For example, a motion information candidate list may be constructed based on neighboring blocks of the current block, and a flag or index information indicating which candidate is selected (used) to derive a motion vector and/or a reference picture index of the current block may be signaled. [0235] As another example, if MVP mode is applied to the current block, the HMVP candidate belonging to the HMVP candidate set may be included as a candidate of the merge candidate list, and the HMVP candidate may be indicated among candidates belonging to the MVP candidate list based on an MVP flag (or MVP index) obtained from a bitstream.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Pham with the teachings of Park in order to improve prediction efficiency.
Regarding claim 13, the limitations of claim 1 have been addressed. Pham fails to explicitly disclose wherein multiple sets of K HMVP motion candidates are predefined, wherein a representation of the bitstream includes an index of a coding mode for a video block of the video unit, and wherein the index of the coding mode indicates that the K HMVP motion candidates within the multiple sets of default K HMVP motion candidates are to be used for the video unit.
Park discloses wherein multiple sets of K HMVP motion candidates are predefined, wherein a representation of the bitstream includes an index of a coding mode for a video block of the video unit, and wherein the index of the coding mode indicates that the K HMVP motion candidates within the multiple sets of default K HMVP motion candidates are to be used for the video unit ([0102] For example, a motion information candidate list may be constructed based on neighboring blocks of the current block, and a flag or index information indicating which candidate is selected (used) to derive a motion vector and/or a reference picture index of the current block may be signaled. [0109] The prediction information is related to the prediction process, which includes prediction mode information (for example, skip flag, merge flag, or mode index) and information about motion information. The information about motion information may include candidate selection information (for example, merge index, MVP flag or MVP index) which is the information for deriving a motion vector. [0220] For example, if merge mode is applied to the current block, the HMVP candidate belonging to the HMVP candidate set is included as a candidate of a merge candidate list, and the HMVP candidate may be indicated based on a merge index among candidates belonging to the merge candidate list. The merge index may be included in the image/video information described later as prediction-related information. In this case, an index may be assigned to the HMVP candidate within the merge candidate list with priority lower than spatial merge candidates and temporal merge candidate belonging to the merge candidate list. [0235] As another example, if MVP mode is applied to the current block, the HMVP candidate belonging to the HMVP candidate set may be included as a candidate of the merge candidate list, and the HMVP candidate may be indicated among candidates belonging to the MVP candidate list based on an MVP flag (or MVP index) obtained from a bitstream.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Pham with the teachings of Park in order to improve prediction efficiency.
Regarding claim 14, the limitations of claim 12 have been addressed. Pham discloses wherein the video unit comprises a picture, a slice, a tile group, a tile, or a coding tree unit (CTU) row ([0004] For block-based video coding, a video slice (e.g., a video picture or a portion of a video picture) may be partitioned into video blocks, which may also be referred to as coding tree units (CTUs), coding units (CUs) and/or coding nodes. [0131] CTU row).
Allowable Subject Matter
Claim 8 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Kaitlin A Retallick whose telephone number is (571)270-3841. The examiner can normally be reached Monday-Friday 8am-5pm.
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, Chris Kelley can be reached at (571) 272-7331. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/KAITLIN A RETALLICK/Primary Examiner, Art Unit 2482
