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 .
Claim Interpretation
Patentable weight is given to data stored on a computer-readable medium when there exists a functional relationship between the data and its associated substrate. MPEP 2111.05 III. For example, if a claim is drawn to a computer-readable medium containing programming, a functional relationship exists if the programming “performs some function with respect to the computer with which it is associated.” Id. However, if the claim recites that the computer-readable medium merely serves as a support for information or data, no functional relationship exists and the information or data is not given patentable weight. Id.
At present claim 20, is directed to “a non-transitory computer-readable recording medium storing a bitstream of a video which is generated by a method performed by an apparatus for video processing”, the generating method comprising a plurality of steps. While the generating method may be performed by an intended computer, the generating method is not stored on the computer readable recording medium. Rather, only a resulting bitstream is stored on the computer readable recording medium. It is the bitstream itself, therefore, that must have a functional relationship. Because there are no recitations of the bitstream causing an intended computer to perform some function, Examiner finds that there is no disclosed or claimed functional relationship between the stored bitstream and the medium. Instead, the medium is merely a support or carrier for the bitstream being stored. Therefore, the bitstream stored and the way such bitstream is decoded are not given patentable weight. As such, claim 20 is subject to a prior art rejection based on any non-transitory computer readable recording medium known before the earliest effective filing date of the present application.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), 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 3, 4, 11, and 12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 3 and 4, the claims recite the limitation “latter block” in line 4 and line 2, respectively. Claim 1, the claims upon which both claims 3 and 4 properly depend only recites “a current block” in line 3. It is therefore unclear whether the limitation “latter block” is referring to the previously recited “current block” or a block other than the current block.
Regarding claim 11, the claim recites the limitation “a target mode” in line 1. The claim, however, further recites the limitation “a target mode” in line 3. It is unclear whether the “target mode” of line 3 is intended to refer to the “target mode” of line 1 or a different target mode. For the purposes of examination on the merits, examiner interprets “a target mode” of line 1 and “ a target mode” of line 3 to be the same target mode.
Claim 12 properly depends on claim 11 and is therefore likewise rejected.
Examiner Remarks
Examiner interprets the claims in the alternative only.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Chang et al. (US 2022/0201282) (hereinafter Chang).
Regarding claim 20:
As discussed above, claim 20 has been interpreted as nonfunctional descriptive material under MPEP 2111.05(III) and associated case law cited therein because claim 20 recites “a non-transitory computer readable recording medium storing a bitstream of a video which is generated by a method performed by an apparatus for video processing.” As such, claim 20 is subject to a prior art rejection based on any non-transitory computer readable recording medium known before the earliest effective filing date of the present application. In other words, the proper interpretation of claim 20 is merely a machine-readable media in which the media is merely support or carrier for the bitstream being stored wherein the bitstream stored and the way such bitstream is generated should not be given patentable weight. Chang teaches a computer readable recording medium storing a bitstream comprising video information (Chang, e.g. Fig. 1, element 108, and par. 100: depicting and describing a computer readable storage medium storing encoded video data, wherein encoded video data is the equivalent of the bitstream).
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 no obviousness.
Claim(s) 1 – 12 and 16 - 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lin et al. (US 2020/0021845) (hereinafter Lin), as cited by applicant, in view of Chang et al. (US 2022/0201282) (hereinafter Chang).
Regarding claims 1, 18, 19, and 20, Lin teaches a method of video processing, an apparatus for video processing comprising a processor and a non-transitory memory with instruction thereon, wherein the instructions upon execution by the processor cause the processor to perform the method, a non-transitory computer readable storage medium storing instructions that cause a processor to perform the method, and a non-transitory computer readable recoding medium storing a bitstream of a video which generated by the method, the method comprising:
determining, for a conversion between a video unit of a video and a bitstream of the video, whether an overlap subblock based motion compensation (OBMC) is applied to a current block of the video unit based on motion information of neighboring blocks (e.g. pars. 39 – 40: describing that the system determines whether overlapped block based motion compensation (OBMC) is applied to a current block based on motion information of neighboring blocks, wherein OBMC is performed on a sub-block level [see, e.g. Figs. 3A and 3B, and par. 11: describing that OBMC is performed on a sub-block basis], and wherein motion information of neighboring blocks is the equivalent of a motion vector candidate [see, e.g. par. 11: describing that the current block is coded using merge, affine and advanced temporal motion vector prediction (ATMVP) modes, wherein it is known to those of ordinary skill in the art that a block coded in merge, affine, and ATMVP modes necessarily uses motion vector candidates in a motion vector candidate list derived from neighboring blocks]); and
performing the conversion based on the determining (e.g. Fig. 8 and par. 158: depicting and describing that the system performs coding of the coding block based on a determination of whether OBMC is applied to the current block or not).
Lin does not explicitly teach:
Wherein the determining based on motion information of neighboring blocks is determining based on an inheritance from a motion vector candidate.
Chang, however, teaches a method of video processing:
Wherein the determining based on motion information of neighboring blocks is determining based on an inheritance from a motion vector candidate (e.g. par. 65: describing that the system determines whether OBMC is applied to a current block based on an OBMC flag, the OBMC flag copied from neighboring blocks in a way similar to motion information is copied from neighboring blocks in merge mode, wherein the OBMC flag being copied from neighboring blocks in a way similar to motion information is copied from neighboring blocks in merge mode is the equivalent of the inheritance from a motion vector candidate).
It therefore would have been obvious to one of ordinary skill in the art to modify the teachings of Lin by adding the teachings of Chang in order for the determining based on motion information of neighboring blocks to be determining based on an inheritance from a motion vector candidate. One of ordinary skill in the art would have been motivated to make such a modification because the modification improves video coding (Chang, e.g. par. 48: describing a desire to improve video coding).
Turning to claim 2, Lin and Chang teach all of the limitations of claim 1, as discussed above. Lin further teaches:
wherein an OBMC parameter of the video unit is stored in a buffer (e.g. par. 41: describing that OBMC information is stored in a buffer, wherein OBMC information is the equivalent of the OBMC parameter).
Regarding claim 3, Lin and Chang teach all of the limitations of claims 1 and 2, as discussed above. Lin further teaches:
wherein the OBMC parameter comprises a flag of OBMC, and/or wherein the OBMC parameter is stored in a granularity of Mx subblock, wherein M is an integer number, and/or wherein the OBMC parameter is used for coding of latter block (e.g. par. 21: describing that OBMC information includes OBMC syntax wherein OBMC syntax is the equivalent of the flag of OBMC; e.g. Figs. 3A and 3B, and par. 11: describing that OBMC is performed in a granularity of a subblock, the sub-block size being 4x4, wherein performing OBMC in a granularity of a sub-block reasonably suggests that OBMC information is also stored in a granularity of a sub-block; and e.g. par. 41: describing that the OBMC information is used for coding of a later block).
Turning to claim 4, Lin and Chang teach all of the limitations of claims 1 – 3, as discussed above. Lin further teaches:
wherein M is equal to 4 or 8, and/or wherein the OBMC parameter is inherited for coding of latter block (Figs. 3A and 3B, and par. 11: describing that OBMC is performed in a granularity of a subblock, the sub-block size being 4x4; e.g. pars. 39 – 40: describing that the system determines OBMC information based on neighboring blocks, wherein determining OBMC information based on neighboring blocks is the equivalent of the OBMC parameter being inhere tied for coding of latter block).
Regarding claim 5, Lin and Chang teach all of the limitations of claim 1, as discussed above. Lin further teaches:
wherein whether the OBMC is applied to the current block is inherited from the motion vector candidate, and/or wherein the motion vector candidate is a candidate in an inter merge list, and/or wherein the inheritance is based on a type of motion vector candidate of the current block (e.g. pars. 11 and 39 – 40: describing that the system determines whether OBMC is applied to the current block based on motion information of neighboring blocks, wherein the motion information of neighboring blocks is the equivalent of the motion vector candidate, wherein the motion vector candidate is a candidate in an inter merge list [see, e.g. par. 11: describing that current block is coded in inter merge mode wherein it is known to those of ordinary skill in the art that motion information of neighboring blocks is included in the merge candidate list]).
Turning to claim 6, Lin and Chang teach all of the limitations of claims 1 and 5, as discussed above. Lin further teaches:
wherein the motion vector candidate is in an inter Affine merge list, or wherein the motion vector candidate is in an inter regular merge list, or wherein the motion vector candidate is in an inter template matching (TM) merge list, or wherein the motion vector candidate is in an inter block matching (BM) merge list, or wherein the motion vector candidate is in an inter geometric (GEO) merge list, or wherein the motion vector candidate is in an inter combined inter and intra prediction (ClIP) merge list, or wherein the motion vector candidate is in an inter merge mode with motion vector difference (MMVD) merge list, or wherein the motion vector candidate is in an inter subblock-based temporal motion vector prediction (SbTMVP)merge list, and/or wherein the OBMC parameter is inherited from a spatial neighbor block adjacent to the current block, and/or wherein the OBMC parameter is inherited from a spatial neighbor block non-adjacent to the current block, and/or wherein the OBMC parameter is inherited from a motion candidate from a history based motion vector predictor (HMVP) table, and/or wherein the OBMC parameter is set to a default value for a temporal motion vector, and/or wherein the OBMC parameter is inherited from a temporal motion vector, and/or wherein the OBMC parameter is set to a default value for a pairwise motion vector, and/or wherein the OBMC parameter is inherited from one direction of a motion vector that constructs a pairwise motion vector, and/or wherein the OBMC parameter is set to a default value for a zero motion vector, and/or wherein a default value indicates that the OBMC is used to the current block, and/or wherein a default value indicates that the OBMC is not used to the current block (e.g. par. 11: describing that the current block is coded using merge or affine mode, wherein it is known to those of ordinary skill in the art that blocks coded using merge mode or affine mode obtain motion information from neighboring blocks, the motion information of neighboring blocks being in a merge candidate list or an affine merge candidate list).
Regarding claim 7, Lin and Chang teach all of the limitations of claim 1, as discussed above. Lin further teaches:
wherein the inheritance is based on whether the motion vector candidate is local illumination compensation (LIC) coded, and/or wherein the inheritance is based on block dimensions of the current block, and/or wherein the inheritance is based on a prediction mode of the current block (e.g. pars. 39 – 40: describing that the system determines whether to apply OBMC to a current block based on the size, shape, width, and/or height of the current block, wherein the size, shape, width, and/or height of the current block is the equivalent of the block dimensions of the current block).
Turning to claim 8, Lin and Chang teach all of the limitations of claims 1 and 7, as discussed above. Lin further teaches:
wherein the OBMC parameter which is inherited is equal to a value indicating that the OBMC is not applied to the current block, if at least one of the following conditions is met: W*H <T1 wherein H represent a height of the current block, W represents a width of the current block, and T1, T2, T3, T4, TS, T6, T7, T8, T9 and T10 are integer numbers, respectively (e.g. par. 41: describing that the system determines whether the OBMC is applied to the current block or not based on whether the size of the current block is less than a predefined value, wherein the size of the current block being less than a predefined value is the equivalent of the W*H < T1).
Regarding claim 9, Lin and Chang teach all of the limitations of claims 1 and 7 – 8, as discussed above. Lin further teaches:
wherein T1, T2, T3, T4, T5, T6, T7, T8, T9 and T10 are constant values, respectively (e.g. par. 41: describing that the predefined value is a constant value [exemplified as 64]).
Turning to claim 10, Lin and Chang teach all of the limitations of claims 1 and 7 – 9, as discussed above. Lin further teaches:
wherein T1= 32 (e.g. par. 44: describing that the predefined threshold value is 32).
Regarding claim 11, Lin and Chang teach all of the limitations of claims 1 and 7, as discussed above. Lin further teaches:
wherein if the current block is coded with a target mode, the OBMC parameter is inherited for the current block, and/or wherein if the current block is coded with a target mode, the OBMC parameter is not inherited for the current block (e.g. par. 141: describing that if the current block is in a specific inter mode, OBMC is implicitly determined to not be applied, wherein implicitly determining that OBMC is not applied based on coding mode is the equivalent of the OBMC parameter is not inherited for the current block if the current block is coded with a target mode).
Turning to claim 12, Lin and Chang teach all of the limitations of claims 1, 7, and 11, as discussed above. Lin does not explicitly teach:
wherein the target mode comprises at least one of: affine merge, inter merge, inter advanced motion vector prediction (AMVP), regular inter merge, multi-hypothesis prediction (MHP), GEO, a variant of GEO, CIp, a variant of ClIP, inter MMVD, affine MMVD, inter TM , inter BM, AMVP-MERGE, or sbTMVP, or wherein the target mode comprises at least one of: inter AMVP, AMVP-MERGE, intra block copy (IBC) merge, or IBC AMVP.
Chang, however, teaches a method of video processing:
wherein the target mode comprises at least one of: affine merge, inter merge, inter advanced motion vector prediction (AMVP), regular inter merge, multi-hypothesis prediction (MHP), GEO, a variant of GEO, CIp, a variant of ClIP, inter MMVD, affine MMVD, inter TM , inter BM, AMVP-MERGE, or sbTMVP, or wherein the target mode comprises at least one of: inter AMVP, AMVP-MERGE, intra block copy (IBC) merge, or IBC AMVP (e.g. par. 65: describing that the OBMC flag is inherited when the current block is coded using merge mode, wherein merge mode is the equivalent of inter merge and regular inter merge, the OBMC flag not being inherited when the current block is not coded in merge mode).
It therefore would have been obvious to one of ordinary skill in the art to modify the teachings of Lin by adding the teachings of Chang in order for the target mode to comprise at least one of: affine merge, inter merge, inter advanced motion vector prediction (AMVP), regular inter merge, multi-hypothesis prediction (MHP), GEO, a variant of GEO, CIp, a variant of ClIP, inter MMVD, affine MMVD, inter TM , inter BM, AMVP-MERGE, or sbTMVP, or in order for the target mode to comprise at least one of: inter AMVP, AMVP-MERGE, intra block copy (IBC) merge, or IBC AMVP. One of ordinary skill in the art would have been motivated to make such a modification because the modification improves video coding (Chang, e.g. par. 48: describing a desire to improve video coding).
Regarding claim 16, Lin and Chang teach all of the limitations of claim 1, as discussed above. Lin further teaches:
wherein an indication of whether to and/or how to determine whether the OBMC is applied to the current block is indicated at one of the followings: sequence level, group of pictures level, picture level, slice level, or tile group level, or wherein an indication of whether to and/or how to determine whether the OBMC is applied to the current block is indicated in one of the following: a sequence header, a picture header, a sequence parameter set (SPS), a video parameter set (VPS), a decoding parameter set (DPS), a decoding capability information (DCI), a picture parameter set (PPS), an adaptation parameter sets (APS), a slice header, or a tile group header, or wherein an indication of whether to and/or how to determine whether the OBMC is applied to the current block is included in one of the following: a prediction block (PB), a transform block (TB), a coding block (CB), a prediction unit (PU), a transform unit (TU), a coding unit (CU), a virtual pipeline data unit (VPDU), a coding tree unit (CTU), a CTU row, a slice, a tile, a sub-picture, or a region containing more than one sample or pixel, or wherein the method further comprises: determining, based on coded information of the video unit, whether and/or how to determine whether the OBMC is applied to the current block, the coded information including at least one of: a block size, a colour format, a single and/or dual tree partitioning, a colour component, a slice type, or a picture type (e.g. pars. 47 – 48: describing that the system determines how and whether to apply OBMC to a current block based on syntax information and block information, the syntax information signaled at the SPS, PPS, slice, or tile levels).
Turning to claim 17, Lin and Chang teach all of the limitations of claim 1, as discussed above. Lin further teaches:
wherein the conversion includes encoding the video unit into the bitstream, or wherein the conversion includes decoding the video unit from the bitstream (Lin, e.g. Fig. 8 and par. 158: depicting and describing that the coding includes encoding the block into the bitstream or decoding the block from the bitstream).
Claim(s) 13 - 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lin et al. (US 2020/0021845) (hereinafter Lin), as cited by applicant, in view of Chang et al. (US 2022/0201282) (hereinafter Chang) as applied to claim 1 above, and further in view of Liu et al. (WO 2020/084507) (hereinafter Liu).
Regarding claim 13, Lin and Chang teach all of the limitations of claim 1, as discussed above. Lin does not explicitly teach:
wherein the inheritance of a block which is an affine merge coded and/or variant of affine merge coded block is dependent on OBMC of an affine candidate, and/or wherein the motion vector candidate is a candidate in an inter AMVP list, and/or wherein the inheritance of a MHP coded block is dependent on a prediction mode of a base hypothesis.
Liu, however, teaches a method of video processing:
wherein the inheritance of a block which is an affine merge coded and/or variant of affine merge coded block is dependent on OBMC of an affine candidate, and/or wherein the motion vector candidate is a candidate in an inter AMVP list, and/or wherein the inheritance of a MHP coded block is dependent on a prediction mode of a base hypothesis (e.g. par. 289, section 5.2.f and section 5.2.h: describing that the system determines whether a coding tool parameter/flag is inherited based on whether the block is coded in an affine merge mode, the block inheriting the coding tool flag/parameter when the block is coded in affine mode from the determined affine mode candidate, wherein the coding tool is the equivalent of OBMC [see discussion above]).
It therefore would have been obvious to one of ordinary skill in the art to modify the teachings of Lin by adding the teachings of Liu in order for the inheritance of a block which is an affine merge coded and/or variant of affine merge coded block is dependent on OBMC of an affine candidate, or in order for the motion vector candidate is a candidate in an inter AMVP list, or in order for the inheritance of a MHP coded block is dependent on a prediction mode of a base hypothesis. One of ordinary skill in the art would have been motivated to make such a modification because the modification improves latency issues (See, Liu, e.g. pars. 288 – 289: depicting and describing a desire to resolve latency issues that arise with the use of OBMC coding tools).
Turning to claim 14, Lin, Chang, and Liu teach all of the limitations of claims 1 and 13, as discussed above. Lin does not explicitly teach:
wherein an OBMC parameter of an affine merge candidate is inherited to the block which is affine merge coded and/or variant of affine merge coded, and/or wherein the motion vector candidate is in an inter regular AMVP list, or wherein the motion vector candidate is in an inter AMVP-merge list, or wherein the motion vector candidate is in an inter affine AMVP list, and/or wherein the base hypothesis of the MHP coded block is inter merge coded, and/or wherein the base hypothesis of the MHP coded block is inter AMVP coded.
Liu, however, teaches a method of processing video:
wherein an OBMC parameter of an affine merge candidate is inherited to the block which is affine merge coded and/or variant of affine merge coded, and/or wherein the motion vector candidate is in an inter regular AMVP list, or wherein the motion vector candidate is in an inter AMVP-merge list, or wherein the motion vector candidate is in an inter affine AMVP list, and/or wherein the base hypothesis of the MHP coded block is inter merge coded, and/or wherein the base hypothesis of the MHP coded block is inter AMVP coded (e.g. par. 289, section 5.2.f and section 5.2.h: describing that the system determines whether a coding tool parameter is inherited based when the block is coded in affine mode from the determined affine mode candidate, wherein the coding tool is the equivalent of OBMC [see discussion above]).
It therefore would have been obvious to one of ordinary skill in the art to modify the teachings of Lin by adding the teachings of Liu in order for an OBMC parameter of an affine merge candidate is inherited to the block which is affine merge coded and/or variant of affine merge coded, or in order for the motion vector candidate is in an inter regular AMVP list, or in order for the motion vector candidate is in an inter AMVP-merge list, or in order for the motion vector candidate is in an inter affine AMVP list, or in order for the base hypothesis of the MHP coded block is inter merge coded, or in order for the base hypothesis of the MHP coded block is inter AMVP coded. One of ordinary skill in the art would have been motivated to make such a modification because the modification improves latency issues (See, Liu, e.g. pars. 288 – 289: depicting and describing a desire to resolve latency issues that arise with the use of OBMC coding tools).
Regarding claim 15, Lin, Chang, and Liu teach all of the limitations of claims 1 and 13, as discussed above. Lin does not explicitly teach:
wherein if the base hypothesis of the MHP coded block is inter merge coded, the OBMC parameter of a merge candidate of the base hypothesis is inherited to the MHP coded block, and/or wherein if the base hypothesis of the MHP coded block is inter merge coded, the OBMC parameter is set to a value indicating that the OBMC is used to the MHP coded block, and/or wherein if the base hypothesis of the MHP coded block is inter AMVP coded, the OBMC parameter is indicated in the bitstream to indicate whether the OBMC is used to the MHP coded block.
Liu, however, teaches a method of video processing:
wherein if the base hypothesis of the MHP coded block is inter merge coded, the OBMC parameter of a merge candidate of the base hypothesis is inherited to the MHP coded block, and/or wherein if the base hypothesis of the MHP coded block is inter merge coded, the OBMC parameter is set to a value indicating that the OBMC is used to the MHP coded block, and/or wherein if the base hypothesis of the MHP coded block is inter AMVP coded, the OBMC parameter is indicated in the bitstream to indicate whether the OBMC is used to the MHP coded block (e.g. par. 289, section 5.11.b: describing that when a block is MHP coded in merge mode, the coding tool flag/parameter of the merge candidate is inherited to the block, wherein the coding tool is the equivalent of OBMC [see discussion above]).
It therefore would have been obvious to one of ordinary skill in the art to modify the teachings of Lin by adding the teachings of Liu in order if the base hypothesis of the MHP coded block is inter merge coded, the OBMC parameter of a merge candidate of the base hypothesis is inherited to the MHP coded block, or in order for if the base hypothesis of the MHP coded block is inter merge coded, the OBMC parameter is set to a value indicating that the OBMC is used to the MHP coded block, or in order for if the base hypothesis of the MHP coded block is inter AMVP coded, the OBMC parameter is indicated in the bitstream to indicate whether the OBMC is used to the MHP coded block. One of ordinary skill in the art would have been motivated to make such a modification because the modification improves latency issues (See, Liu, e.g. pars. 288 – 289: depicting and describing a desire to resolve latency issues that arise with the use of OBMC coding tools).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHANIKA M BRUMFIELD whose telephone number is (571)270-3700. The examiner can normally be reached M-F 8:30 - 5 PM AWS.
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, David Czekaj can be reached at 571-272-7327. 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.
SHANIKA M. BRUMFIELD
Examiner
Art Unit 2487
/SHANIKA M BRUMFIELD/Examiner, Art Unit 2487
/Dave Czekaj/Supervisory Patent Examiner, Art Unit 2487
Prosecution Insights