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 .
Response to Amendments / Arguments
Regarding the rejection(s) of claims under 35 USC 103:
Applicant’s arguments, in view of the amended claims, filed 06/12/2026, have been fully considered and are not persuasive.
Applicant argues that Yue does not teach "computing a target hash digest of a file to be detected" and "computing bit indices of the file to be detected in a preset Bloom filter based on hash functions of the preset Bloom filter and the target hash digest." For instance, Applicant argues that "the input of the Bloom filter is the viral signature code of the virus" rather than a computed hash digest, and that the claimed hash digest is "obtained by hash computation for the whole file to be detected, reflecting a global fingerprint of the file and without considering locations of the file code." In response, it is noted that the limitations upon which Applicant relies (computation over the whole file, a global fingerprint, and disregard of locations of the file code) do not appear in claim 1, which recites only "computing a target hash digest of a file to be detected." Limitations from the specification are not read into the claims. Paragraph [0009] of Yue recites that "[t]he virus signature of the file to be detected is hashed using multiple random mapping functions to obtain multiple hash indices," and paragraph [0065] recites that the retrieval intermediate layer comprises "a long binary bit array and a series of random mapping functions (unbiased hash functions)." Applicant's further argument that Yue "possibly fails to detect the virus" where other bytes are modified is directed to an unclaimed advantage.
Applicant further argues that in Yue, "no further virus detection or authentication is performed," and that the claimed two-stage mechanism addresses "the false positive issue of Bloom filter, which Yue fails to address." In response, it is noted that paragraph [0079] of Yue expressly recites that an unstored signature mapping to a set bit "leads to a false positive. Therefore, embodiments of the present invention use multiple random mapping functions for hash calculation," and paragraph [0080] recites that this "reduces the number of false positives recorded."
Applicant additionally argues that in Oliver, "no further virus detection or authentication is performed, and Oliver directly passes the file, or quarantines or deletes the file." In response, it is noted that Oliver recites "[o]ne efficient technique is to use a Bloom filter to perform these checks of the whitelist and blacklist" (Cols. 3-4); the filter performs checks of the lists rather than replacing them. Because a positive filter result indicates list membership without indicating which list, and because Oliver's actions differ between a whitelist hit ("pass") and a blacklist hit ("quarantine" or "delete"), the lists are consulted following the positive result. This teaches the claimed "performing virus detection on the file to be detected based on at least one of a preset whitelist, a preset blacklist, and an external storage device."
Finally, Applicant's arguments are directed to the references individually, whereas the rejection is over Yue in view of Oliver. Applicant does not dispute that Oliver computes hash values of files using CRC, MD5 or SHA-1 and checks them against a white list and black list of hash values by means of a Bloom filter, and Yue's recognition of false positives at paragraphs [0079]-[0080] provides the motivation to verify a positive filter result against the stored hash values as taught by Oliver.
Therefore, the identified claim language is considered to be taught by the combination of Yue and Oliver, and the rejection is maintained. Further, since Applicant has not presented additional arguments concerning the dependent claims, their rejections are likewise maintained.
DETAILED ACTION
This is a reply to the arguments filed on 06/12/2026, in which, claims 1-17 are pending. Claims 1 and 10 are independent.
When making claim amendments, the applicant is encouraged to consider the references in their entireties, including those portions that have not been cited by the examiner and their equivalents as they may most broadly and appropriately apply to any particular anticipated claim amendments.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 05/27/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 8-14 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Yue et al. (CN115688099A (human assisted translated), referred to as Yue), in view of Oliver (US 8375450 B1, referred to as Oliver).
In reference to claim 1, A virus detection method, the method comprising: computing a target hash digest of a file to be detected (Yue: [0009], [0073]-[0077] and claim 2 Provides for the hashing of a file's signature to produce index values.) computing bit indices of the file to be detected in a preset Bloom filter based on hash functions of the preset Bloom filter and the target hash digest (Yue: [0065] and [0073]-[0077] and claim 2 Provides for computing multiple bit/hash indices within a Bloom filter structure using the filter's own hash functions applied to the file's signature.) wherein bit indices of each known virus file in the preset Bloom filter are determined based on a hash digest of the corresponding known virus file (Yue: [0066] and Claim 4 Provides for establishing bit indices for each known virus by hashing its signature.) all of parameter values corresponding to the bit indices of each known virus file in the preset Bloom filter are a preset value (Yue: [0066] and Claim 4 Provides for setting all bit positions corresponding to known hash indices to a uniform preset value.)
determining whether the file to be detected is a threat file based on the preset Bloom filter and the bit indices corresponding to the file to be detected (Yue: [0074]-[0080] and Claim 3 Provides for determination based on Bloom filter bit values at the computed indices.)
querying target parameter values of the bit indices corresponding to the file to be detected in the preset Bloom filter (Yue: [0076]-[0077] Provides for directly querying the bit array values at the computed hash indices.)
Yue doesn't explicitly disclose determining the file is a virus. However, Oliver teaches:
Wherein the determined threat of the file is a virus file (Oliver: Col. 3-4 and Fig. 2A Provides for a determination of whether a file is malware by comparing its computed bit indices against the preset Bloom filter.)
in response to a determination that all the target parameter values of the bit indices are the preset value, performing virus detection on the file to be detected based on at least one of a preset whitelist, a preset blacklist, and an external storage device to identify whether the file to be detected is a virus file (Oliver: Col. 3-4 and Fig. 2A provides for escalating verification process triggered when initial filter checks produce a positive indication, consulting whitelist, blacklist, and external backend storage resources to make a final virus determination.)
wherein the preset whitelist stores hash digests of a plurality of non-virus files, the preset blacklist stores hash digests of a plurality of virus files, and the external storage device stores hash digests of each known virus file (Oliver: Col. 3-5 Provides for distinct whitelist and blacklist data structures storing hash digests of known non-virus and virus files respectively.)
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 Yue, which provides a method for detecting threat files using Bloom filters by computing hash digests and bit indices to determine whether files match known patterns, with the teachings of Oliver, which introduces specific determination that detected threats are virus files through Bloom filter comparison. One of ordinary skill in the art would recognize the ability to incorporate Oliver's virus-specific classification into Yue's Bloom filter-based threat detection system to provide more precise threat categorization. One of ordinary skill in the art would be motivated to make this modification in order to enable more targeted security responses by specifically identifying threats as viruses rather than generic threat files.
In reference to claim 2, The method according to claim 1, wherein computing the bit indices of the file to be detected in the preset Bloom filter based on the hash functions of the preset Bloom filter and the target hash digest comprises: computing hash values of the target hash digest respectively based on the hash functions of the preset Bloom filter (Yue: [0069]-[0075] Provides for applying each of the Bloom filter's hash functions separately to the input to produce individual hash values.)
determining the computed hash values as corresponding bit indices of the file to be detected in the preset Bloom filter (Yue: [0069]-[0075] Provides for treating the computed hash values as the operative bit indices used to query the Bloom filter structure.)
In reference to claim 3, The method according to claim 1, wherein determining whether the file to be detected is a virus file based on the preset Bloom filter and the bit indices corresponding to the file to be detected further comprises: in response to a determination that at least one of the target parameter values is not the preset value, determining that the file to be detected is not a virus file (Oliver: Col. 3 lines 5-40 Provides for a negative determination outcome when queried values do not match stored virus indicators.)
In reference to claim 4, The method according to claim 3, wherein performing virus detection on the file to be detected based on the preset whitelist and the preset blacklist comprises: in response to a determination that the target hash digest of the file to be detected exists in the preset whitelist, determining that the file to be detected is not a virus file (Oliver: Col. 3 and Fig. 2A Provides for an explicit and direct whitelist hash digest lookup resulting in a clean non-virus determination.)
in response to a determination that the target hash digest of the file to be detected does not exist in the preset whitelist but exists in the preset blacklist, determining that the file to be detected is a virus file (Oliver Col. 3 and Fig. 2A Provides for an explicit blacklist hash digest lookup resulting in a virus determination and remediation action.)
In reference to claim 5, The method according to claim 3, wherein performing virus detection on the file to be detected based on the preset whitelist, the preset blacklist, and the external storage device comprises: in response to a determination that the target hash digest of the file to be detected does not exist in both the preset whitelist and the preset blacklist but exists in the hash digests of known virus files stored in the external storage device, determining that the file to be detected is a virus file and storing the target hash digest of the file to be detected in the preset blacklist (Oliver: Col. 4 and Fig. 2B Provides for an escalating lookup to an external backend storage service that, upon confirming a file as malware, results in the file's hash digest being added to the local blacklist for future detection.)
in response to a determination that the target hash digest of the file to be detected does not exist in both the preset whitelist and the preset blacklist and does not exist in the hash digests of known virus files stored in the external storage device, determining that the file to be detected is not a virus file and storing the target hash digest of the file to be detected in the preset whitelist (Oliver: Col 4-5 and Fig. 2B Provides for a clean non-virus determination following exhaustion of all three lookup tiers resulting in population of the local whitelist with the file's hash digest.)
In reference to claim 8, The method according to claim 1, wherein determining bit indices of each known virus file in the preset Bloom filter based on a hash digest of the corresponding known virus file comprises: computing a hash digest of each known virus file according to a preset hash function (Yue: [0066] Provides for hashing known virus signatures.)
computing hash values of the hash digest of each known virus file respectively according to the hash functions of the preset Bloom filter (Yue: [0066] Provides for applying multiple Bloom filter hash functions to the input of each known virus to produce multiple hash values.)
determining the computed hash values corresponding to each known virus file as corresponding bit indices of the corresponding known virus file in the preset Bloom filter (Yue: [0066] and [0077] Provides for treating the computed hash function outputs as the operative bit index positions for each known virus within the Bloom filter structure.)
setting parameter values corresponding to the bit indices of the respective known virus files in the preset Bloom filter to the preset value (Yue: [0066] Provides for explicitly setting all bit positions corresponding to computed indices to the preset value of 1.)
In reference to claim 9, A non-transitory computer storage medium, wherein the computer storage medium stores a plurality of instructions, which are suitable for being loaded and executed by a processor, causing the processor to perform the method according to claim 1 (Yue: [0053] Provides for a computer-readable storage medium storing executable instructions that cause a processor to perform the claimed virus retrieval method.)
In reference to claim 10, An electronic device, wherein the electronic device comprises: a processor and a memory; wherein, the memory stores computer programs, which are suitable for being loaded and executed by the processor, causing the processor to perform operations comprising: computing a target hash digest of a file to be detected (Yue: [0009], [0073]-[0077] and claim 2 Provides for the hashing of a file's signature to produce index values.) computing bit indices of the file to be detected in a preset Bloom filter based on hash functions of the preset Bloom filter and the target hash digest (Yue: [0073]-[0077] and claim 2 Provides for computing multiple bit/hash indices within a Bloom filter structure using the filter's own hash functions applied to the file's signature.) wherein bit indices of each known virus file in the preset Bloom filter are determined based on a hash digest of the corresponding known virus file (Yue: [0066] and Claim 4 Provides for establishing bit indices for each known virus by hashing its signature.) all of parameter values corresponding to the bit indices of each known virus file in the preset Bloom filter are a preset value (Yue: [0066] and Claim 4 Provides for setting all bit positions corresponding to known hash indices to a uniform preset value.)
determining whether the file to be detected is a threat file based on the preset Bloom filter and the bit indices corresponding to the file to be detected (Yue: [0074]-[0077] and Claim 3 Provides for determination based on Bloom filter bit values at the computed indices.)
querying target parameter values of the bit indices corresponding to the file to be detected in the preset Bloom filter (Yue: [0076]-[0077] Provides for directly querying the bit array values at the computed hash indices.)
Yue doesn't explicitly disclose determining the file is a virus. However, Oliver teaches:
Wherein the determined threat of the file is a virus file (Oliver: Col. 3-4 and Fig. 2A Provides for a determination of whether a file is malware by comparing its computed bit indices against the preset Bloom filter.)
in response to a determination that all the target parameter values of the bit indices are the preset value, performing virus detection on the file to be detected based on at least one of a preset whitelist, a preset blacklist, and an external storage device to identify whether the file to be detected is a virus file (Oliver: Col. 3-4 and Fig. 2A provides for escalating verification process triggered when initial filter checks produce a positive indication, consulting whitelist, blacklist, and external backend storage resources to make a final virus determination.)
wherein the preset whitelist stores hash digests of a plurality of non-virus files, the preset blacklist stores hash digests of a plurality of virus files, and the external storage device stores hash digests of each known virus file (Oliver: Col. 3-5 Provides for distinct whitelist and blacklist data structures storing hash digests of known non-virus and virus files respectively.)
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 Yue, which provides a method for detecting threat files using Bloom filters by computing hash digests and bit indices to determine whether files match known patterns, with the teachings of Oliver, which introduces specific determination that detected threats are virus files through Bloom filter comparison. One of ordinary skill in the art would recognize the ability to incorporate Oliver's virus-specific classification into Yue's Bloom filter-based threat detection system to provide more precise threat categorization. One of ordinary skill in the art would be motivated to make this modification in order to enable more targeted security responses by specifically identifying threats as viruses rather than generic threat files.
In reference to claim 11, The electronic device according to claim 10,, wherein computing the bit indices of the file to be detected in the preset Bloom filter based on the hash functions of the preset Bloom filter and the target hash digest comprises: computing hash values of the target hash digest respectively based on the hash functions of the preset Bloom filter (Yue: [0069]-[0075] Provides for applying each of the Bloom filter's hash functions separately to the input to produce individual hash values.)
determining the computed hash values as corresponding bit indices of the file to be detected in the preset Bloom filter (Yue: [0069]-[0075] Provides for treating the computed hash values as the operative bit indices used to query the Bloom filter structure.)
In reference to claim 12, The electronic device according to claim 10, wherein determining whether the file to be detected is a virus file based on the preset Bloom filter and the bit indices corresponding to the file to be detected further comprises: in response to a determination that at least one of the target parameter values is not the preset value, determining that the file to be detected is not a virus file (Oliver: Col. 3 lines 5-40 Provides for a negative determination outcome when queried values do not match stored virus indicators.)
In reference to claim 13, The electronic device according to claim 12, wherein performing virus detection on the file to be detected based on the preset whitelist and the preset blacklist comprises: in response to a determination that the target hash digest of the file to be detected exists in the preset whitelist, determining that the file to be detected is not a virus file (Oliver: Col. 3 and Fig. 2A Provides for an explicit and direct whitelist hash digest lookup resulting in a clean non-virus determination.)
in response to a determination that the target hash digest of the file to be detected does not exist in the preset whitelist but exists in the preset blacklist, determining that the file to be detected is a virus file (Oliver Col. 3 and Fig. 2A Provides for an explicit blacklist hash digest lookup resulting in a virus determination and remediation action.)
In reference to claim 14, The electronic device according to claim 12, wherein performing virus detection on the file to be detected based on the preset whitelist, the preset blacklist, and the external storage device comprises: in response to a determination that the target hash digest of the file to be detected does not exist in both the preset whitelist and the preset blacklist but exists in the hash digests of known virus files stored in the external storage device, determining that the file to be detected is a virus file and storing the target hash digest of the file to be detected in the preset blacklist (Oliver: Col. 4 and Fig. 2B Provides for an escalating lookup to an external backend storage service that, upon confirming a file as malware, results in the file's hash digest being added to the local blacklist for future detection.)
in response to a determination that the target hash digest of the file to be detected does not exist in both the preset whitelist and the preset blacklist and does not exist in the hash digests of known virus files stored in the external storage device, determining that the file to be detected is not a virus file and storing the target hash digest of the file to be detected in the preset whitelist (Oliver: Col 4-5 and Fig. 2B Provides for a clean non-virus determination following exhaustion of all three lookup tiers resulting in population of the local whitelist with the file's hash digest.)
In reference to claim 17, The electronic device according to claim 10, wherein determining bit indices of each known virus file in the preset Bloom filter based on a hash digest of the corresponding known virus file comprises: computing a hash digest of each known virus file according to a preset hash function (Yue: [0066] Provides for hashing known virus signatures.)
computing hash values of the hash digest of each known virus file respectively according to the hash functions of the preset Bloom filter (Yue: [0066] Provides for applying multiple Bloom filter hash functions to the input of each known virus to produce multiple hash values.)
determining the computed hash values corresponding to each known virus file as corresponding bit indices of the corresponding known virus file in the preset Bloom filter (Yue: [0066] and [0077] Provides for treating the computed hash function outputs as the operative bit index positions for each known virus within the Bloom filter structure.)
setting parameter values corresponding to the bit indices of the respective known virus files in the preset Bloom filter to the preset value (Yue: [0066] Provides for explicitly setting all bit positions corresponding to computed indices to the preset value of 1.)
Claims 6-7 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Yue et al. (CN115688099A (human assisted translated), referred to as Yue), in view of Oliver (US 8375450 B1, referred to as Oliver) in further view of Bitran et al. (US 20140149192 A1, referred to as Bitran).
In reference to claim 6, The method according to claim 5, wherein the method further comprises: in response to a determination that the target hash digest of the file to be detected exists in the preset whitelist or the preset blacklist, obtaining a historical storage time of an existing hash digest that is identical to the target hash digest of the file to be detected (Bitran: [0019] and [0035]-[0036] Provides for tracking a temporal storage/verification timestamp associated with each hash entry in the whitelist.)
updating the historical storage time to a current time (Bitran: [0019] and [0035]-[0038] Provides for resetting or refreshing the time-based validity of a hash entry upon re-verification.)
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 Yue in view of Oliver, which together provide a method for detecting virus files using Bloom filters with hash-based matching against known malware patterns, with the teachings of Bitran, which introduces temporal tracking and updating of hash digest storage times in whitelist and blacklist systems. One of ordinary skill in the art would recognize the ability to incorporate Bitran's time-based hash management into the combined virus detection system to maintain freshness of known file classifications. One of ordinary skill in the art would be motivated to make this modification in order to improve the accuracy and relevance of virus detection by tracking when file hashes were last verified.
In reference to claim 7, The method according to claim 5, wherein storing the target hash digest of the file to be detected in the preset blacklist comprises: in a case where an amount of data in the preset blacklist reaches a preset amount, obtaining a hash digest with an earliest storage time from the preset blacklist; deleting the hash digest with the earliest storage time; storing the target hash digest of the file to be detected to the preset blacklist; or in a case where the amount of data in the preset blacklist does not reach the preset amount, directly storing the target hash digest of the file to be detected to the preset blacklist (Bitran: [0019] and [0034]-[0037] Provides for a blacklist of finite, manageable size from which entries can be removed and new entries added.)
setting a storage time of the target hash digest to a current time (Bitran: [0035]-[0038] Provides for time stamping hash entries upon storage or verification.)
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 Yue in view of Oliver, which together provide a method for detecting virus files using Bloom filters with hash-based matching and blacklist storage, with the teachings of Bitran, which introduces capacity-limited blacklist management with time-based entry eviction and timestamp recording. One of ordinary skill in the art would recognize the ability to incorporate Bitran's size-controlled storage mechanism into the combined virus detection system to maintain efficient blacklist operations. One of ordinary skill in the art would be motivated to make this modification in order to prevent unlimited blacklist growth that could degrade system performance.
In reference to claim 15, The electronic device according to claim 14, wherein the method further comprises: in response to a determination that the target hash digest of the file to be detected exists in the preset whitelist or the preset blacklist, obtaining a historical storage time of an existing hash digest that is identical to the target hash digest of the file to be detected (Bitran: [0019] and [0035]-[0036] Provides for tracking a temporal storage/verification timestamp associated with each hash entry in the whitelist.)
updating the historical storage time to a current time (Bitran: [0019] and [0035]-[0038] Provides for resetting or refreshing the time-based validity of a hash entry upon re-verification.)
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 Yue in view of Oliver, which together provide a method for detecting virus files using Bloom filters with hash-based matching against known malware patterns, with the teachings of Bitran, which introduces temporal tracking and updating of hash digest storage times in whitelist and blacklist systems. One of ordinary skill in the art would recognize the ability to incorporate Bitran's time-based hash management into the combined virus detection system to maintain freshness of known file classifications. One of ordinary skill in the art would be motivated to make this modification in order to improve the accuracy and relevance of virus detection by tracking when file hashes were last verified.
In reference to claim 16, The electronic device according to claim 14, wherein storing the target hash digest of the file to be detected in the preset blacklist comprises: in a case where an amount of data in the preset blacklist reaches a preset amount, obtaining a hash digest with an earliest storage time from the preset blacklist; deleting the hash digest with the earliest storage time; storing the target hash digest of the file to be detected to the preset blacklist; or in a case where the amount of data in the preset blacklist does not reach the preset amount, directly storing the target hash digest of the file to be detected to the preset blacklist (Bitran: [0019] and [0034]-[0037] Provides for a blacklist of finite, manageable size from which entries can be removed and new entries added.)
setting a storage time of the target hash digest to a current time (Bitran: [0035]-[0038] Provides for time stamping hash entries upon storage or verification.)
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 Yue in view of Oliver, which together provide a method for detecting virus files using Bloom filters with hash-based matching and blacklist storage, with the teachings of Bitran, which introduces capacity-limited blacklist management with time-based entry eviction and timestamp recording. One of ordinary skill in the art would recognize the ability to incorporate Bitran's size-controlled storage mechanism into the combined virus detection system to maintain efficient blacklist operations. One of ordinary skill in the art would be motivated to make this modification in order to prevent unlimited blacklist growth that could degrade system performance.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Applicant’s amendment necessitated the new ground(s) of rejection presented in this office action. Accordingly, THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AIDAN EDWARD SHAUGHNESSY whose telephone number is (703)756-1423. The examiner can normally be reached on Monday-Friday from 7:30am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Nickerson, can be reached at telephone number (469) 295-9235. 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 Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/usptoautomated-interview-request-air-form.
/A.E.S./Examiner, Art Unit 2432
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
Prosecution Insights