DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after allowance or after an Office action under Ex Parte Quayle, 25 USPQ 74, 453 O.G. 213 (Comm'r Pat. 1935). Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, prosecution in this application has been reopened pursuant to 37 CFR 1.114. Applicant's submission filed on 05/26/2026 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-14 and 15-21 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Specifically, while the claim 1 recites “(ii) the application is signed and verified”, the specification lacks a detailed description of the method of verification of the signed application. Courts have in the past (see MPEP2161.01) found that generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed. Ariad, 598 F.3d at 1349-50, 94 USPQ2d at 1171 ("[A]n adequate written description of a claimed genus requires more than a generic statement of an invention’s boundaries.").
Independent 18 is also rejected for the same rational as claim 1.
Dependent claims 2-14, 17 and 19-21 are also rejected for inheriting the deficiencies of the independent claims from which they depend on.
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 1-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding claim 1, Key limitation, “(ii) the application is signed and verified” is indefinite because a person having ordinary skill in the art could not ascertain how the signed application is verified. Is it via a command line by a user or is it done automatically in the software. Without reasonable certainty, the claims are indefinite under 35 U.S.C § 112(b).
Independent 18 is also rejected for the same rational as claim 1.
Dependent claims 2-14, 17 and 19-21 are also rejected for inheriting the deficiencies of the independent claims from which they depend on.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 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.
Claims 1-2 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Schmugar et al. (Pub. No.: US 2021/0200867, hereinafter Schmugar) and DARLING et al. (US 2024/0419797).
Regarding claim 1: Schmugar teaches: A method for detecting a cyber-attack, the method comprising:
identifying an event occurring in a computer belonging to a computer system, the event comprising loading of an application to memory together with a Dynamic Link Library (DLL); (Schmugar - [0052]: the event monitor 210 detects an OS event, such as a process creation event, a service creation event, a load library event, etc. For example, the event monitor 210 can detect and/or otherwise determine that a DLL has been invoked by an event of the OS 112 of the first computing device 108),
applying to the event a filtering criterion, which verifies that (i) the application and the DLL are loaded from a same folder (Schmugar - [0053]: the DLL path determiner 220 to determine a path name of a referenced or invoked DLL. In some examples, the DLL path determiner 220 determines whether an invoked DLL is included in a launched executable (e.g., the application 124 of FIG. 1). In such examples, the DLL path determiner 220 can determine that the path name of the invoked DLL is a local path of the launched executable based on the invoked DLL being included in the launched executable);
(ii) the application is signed and verified (Schmugar - the fingerprint generator 230 extracts executable features from the executable such as a full path name of the executable, an imported functions list associated with and/or otherwise included in the executable, a digital signature of the executable (e.g., digital signature data or information associated with and/or based on the executable)),
(iii) the DLL does not have a valid signature (Schmugar - [0056]: the fingerprint generator 230 extracts DLL features from the DLL such as … a digital signature (e.g., information including the digital signature, digital signature information, etc.) of the DLL. [0060]: the fingerprint comparator 240 determines whether the DLL fingerprint deviates from any of the first reference fingerprint(s) 136 known to be associated with trusted DLL(s) (e.g., a trusted DLL fingerprint));
responsively to meeting the filtering criterion, applying to the event a profiling criterion, which verifies that prevalences of defined characteristics of the DLL in the computer system are below defined prevalence levels (Schmugar - [0109]: the DLL features 420 include features of a DLL (e.g., features extracted from the second file 134), such as a full path name, an exported functions list, a digital signature, a high-level language (HLL), a compiler, and a file version. [0180]: a fingerprint comparator to determine whether at least one of the first DLL fingerprint or the second DLL fingerprint satisfies a deviation threshold based on a comparison of the first DLL fingerprint and the second DLL fingerprint to a reference DLL fingerprint);
responsively to meeting the profiling criterion, deciding that the DLL is suspected of being malicious (Schmugar - [0180]: a security action enforcer to execute a security action to protect the computing device from the attack in response to the deviation threshold being satisfied [0118]: the security action includes at least one of generating a log, blocking a first execution of at least one of the first DLL or the second DLL, or preventing a second execution of an executable that triggered the OS event).
Schmugar discloses application is signed. However, Schmugar doesn’t explicitly teach the application is signed and verified. In an analogous art, DARLING discloses:
(ii) the application is signed and verified (DARLING - [0085]: At 512, it can be determined whether the application is signed with a certificate. [0097]: the digital signature details can show signer information 706 including a name of the entity signing the digital signature 706A, an email for the entity 706B, a timestamp for the digital signature 706C, and/or countersignatures for the digital certificate 706D. These details can be used to verify an application used to open a selected file),
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Schmugar with DARLING so that the signed executable file is verified. The modification would have allowed the system to improve security.
Regarding claim 2: Schmugar as modified teaches: further comprising initiating a responsive action upon deciding that the DLL is suspected (Schmugar - [0180]: a security action enforcer to execute a security action to protect the computing device from the attack in response to the deviation threshold being satisfied).
Regarding claim 18: Claim is directed to apparatus/system claims and do not teach or further define over the limitations recited in claim 1. Therefore, claim 18 is also rejected for similar reasons set forth in claim 1.
Claims 3 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Schmugar et al. (Pub. No.: US 2021/0200867, hereinafter Schmugar) and DARLING et al. (US 2024/0419797) and Zagorsky et al. (US 2020/0410096).
Regarding claims 3 and 19: Schmugar as modified doesn’t explicitly teach the limitations. However, in an analogous art, Zagorsky teaches: wherein applying the profiling criterion comprises verifying that the DLL was observed in the computer system (i) on less than a defined number of computers; and (ii) during less than a defined number of days (Zagorsky - [0076]: verdicts rendered by outside services to files of another group, the another group also being associated with the dominant developer associated with the group of files, wherein a frequency of running applications developed by the dominant developer among the users exceeds a predetermined threshold);
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Schmugar with DARLING and Zagorsky so that frequency of running applications is compared with a predetermined threshold. The modification would have allowed the system to improve security.
Claims 4 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Schmugar et al. (Pub. No.: US 2021/0200867, hereinafter Schmugar) and DARLING et al. (US 2024/0419797) and Zagorsky et al. (US 2020/0410096).
Regarding claims 4 and 20: Schmugar as modified discloses wherein applying the profiling criterion comprises verifying that a path to the DLL was observed, in the computer system, to contain DLLs having no valid signatures (Schmugar - [0181]: a DLL path determiner to determine whether the first DLL is included in the executable, and in response to determining that the first DLL is included in the executable, determine whether the second DLL is stored at the second OS path. [0056]: the fingerprint generator 230 extracts DLL features from the DLL such as … a digital signature (e.g., information including the digital signature, digital signature information, etc.) of the DLL. [0060]: the fingerprint comparator 240 determines whether the DLL fingerprint deviates from any of the first reference fingerprint(s) 136 known to be associated with trusted DLL(s) (e.g., a trusted DLL fingerprint));
However, Schmugar doesn’t explicitly teach the limitations. However, in an analogous art, Zagorsky teaches: wherein applying the profiling criterion comprises verifying that the DLL was observed in the computer system (i) on less than a defined number of computers; and (ii) during less than a defined number of days (Zagorsky - [0076]: verdicts rendered by outside services to files of another group, the another group also being associated with the dominant developer associated with the group of files, wherein a frequency of running applications developed by the dominant developer among the users exceeds a predetermined threshold);
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Schmugar with DARLING and Zagorsky so that frequency of running applications is compared with a predetermined threshold. The modification would have allowed the system to improve security.
Claims 5-7, 14 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Schmugar et al. (Pub. No.: US 2021/0200867, hereinafter Schmugar) and DARLING et al. (US 2024/0419797) and Dema et al. (US 2025/0133108).
Regarding claims 5 and 21: Schmugar as modified doesn’t explicitly teach the limitations. However, in an analogous art, Dema teaches: further comprising evaluating a score of the event responsively to meeting the profiling criterion, and deciding whether the DLL is suspected of being malicious depending on the score (Dema - [0064] After the confidence score is determined for the file, method 200 further determines (203) whether the score satisfies criteria to initiate an action at the computing device without requesting further processing from the cloud computing system. The criteria comprise thresholds for indicating that the file is not affected and thresholds for indicating that the file is infected. For example, the confidence score comprises a value between zero and one, wherein a value closer to one is more indicative of a potential ransomware affected file).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Schmugar with DARLING and Dema so that a confidence score is calculated to indicate if the file is malicious. The modification would have allowed the system to improve security.
Regarding claim 6: Schmugar as modified teaches: wherein evaluating the score comprises checking whether an entropy of the DLL is below a defined threshold (Dema - [0064]: the confidence score comprises a value between zero and one, wherein a value closer to one is more indicative of a potential ransomware affected file. The threshold for an affected file can be set to above 0.9 for an affected file and below 0.1 for an unaffected file).
The reason to combine is the same as the rational as claim 5.
Regarding claim 7: Schmugar as modified teaches: wherein evaluating the score comprises checking whether an entropy of the DLL is above a defined threshold (Dema - [0064]: the confidence score comprises a value between zero and one, wherein a value closer to one is more indicative of a potential ransomware affected file. The threshold for an affected file can be set to above 0.9 for an affected file and below 0.1 for an unaffected file).
The reason to combine is the same as the rational as claim 5.
Regarding claim 14: Schmugar as modified teaches: wherein evaluating the score comprises checking whether the application is signed by a security company (DARLING - [0085]: At 512, it can be determined whether the application is signed with a certificate. As described below; an application can be signed with a certificate specifying details about an entity that provides/develops the application. Details regarding identifying a certificate and verifying a validity of a certificate is described with respect to FIG. 7).
The reason to combine is the same as the rational as claim 1.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Schmugar et al. (Pub. No.: US 2021/0200867, hereinafter Schmugar) and DARLING et al. (US 2024/0419797) and Dema et al. (US 2025/0133108) and Hansen (US 2021/0312066).
Regarding claim 8: Schmugar as modified doesn’t explicitly teach the limitations. However, in an analogous art, Hansen teaches: wherein evaluating the score comprises checking whether the DLL was loaded from a folder defined as suspicious (Hansen - [0068]: each time a file of the suspicious folder or directory is received from the agent 22, it is checked as to whether it has the correct file extension, and size >4 Kb).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Schmugar with DARLING and Dema and Hansen so that file loaded from a suspicious fold is checked. The modification would have allowed the system to improve security.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Schmugar et al. (Pub. No.: US 2021/0200867, hereinafter Schmugar) and DARLING et al. (US 2024/0419797) and Dema et al. (US 2025/0133108) and Rowland et al. (US 2024/0086538).
Regarding claim 9: Schmugar as modified doesn’t explicitly teach the limitations. However, in an analogous art, Rowland teaches: wherein evaluating the score comprises checking whether the DLL was loaded from a folder having a single-character name (Rowland - [0870] looks for processes that are named as just one character which is commonly done with malware).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Schmugar with DARLING and Dema and Rowland so that file with one character is checked. The modification would have allowed the system to improve security.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Schmugar et al. (Pub. No.: US 2021/0200867, hereinafter Schmugar) and DARLING et al. (US 2024/0419797) and Dema et al. (US 2025/0133108) and Carson (US 2017/0032118).
Regarding claim 10: Schmugar as modified doesn’t explicitly teach the limitations. However, in an analogous art, Carson teaches: wherein evaluating the score comprises checking whether the DLL is included in a defined list of DLLs known to be malicious (Carson - [0074]: verify the entry's signature or a hash of the corresponding DLL/EXE is performed and checked against a known good list, a corresponding entry checked indicator/Boolean may be set to true).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Schmugar with DARLING and Dema and Carson so that DLL is checked with a known good list. The modification would have allowed the system to improve security.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Schmugar et al. (Pub. No.: US 2021/0200867, hereinafter Schmugar) and DARLING et al. (US 2024/0419797) and Dema et al. (US 2025/0133108) and POMERANTSEV (US 2022/0043911).
Regarding claim 11: Schmugar as modified doesn’t explicitly teach the limitations. However, in an analogous art, POMERANTSEV teaches: wherein evaluating the score comprises checking whether the DLL was compiled with a different file name (POMERANTSEV - [0038]: The malware applications that make up one family differ from each other in various kinds of modifications, as a result of which, their publicly available characteristics, such as checksum, file size, file name, etc., are different).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Schmugar with DARLING and Dema and POMERANTSEV so that application with modified file name can be malicious. The modification would have allowed the system to improve security.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Schmugar et al. (Pub. No.: US 2021/0200867, hereinafter Schmugar) and DARLING et al. (US 2024/0419797) and Dema et al. (US 2025/0133108) and Burckhardt et al. (US 2009/0328045).
Regarding claim 12: Schmugar as modified doesn’t explicitly teach the limitations. However, in an analogous art, Burckhardt teaches: wherein evaluating the score comprises checking whether a command line of the application has no arguments (Burckhardt - [0025]: when a command line argument is passed to the application, an execution parsing and responding to the command line arguments will be executed. When the application is run without a command line argument, a different execution may be taken).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Schmugar with DARLING and Dema and Burckhardt so that application run with or without argument is ckecked. The modification would have allowed the system to improve security.
Claims 13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Schmugar et al. (Pub. No.: US 2021/0200867, hereinafter Schmugar) and DARLING et al. (US 2024/0419797) and Dema et al. (US 2025/0133108) and Hen et al. (US 2025/0307420).
Regarding claims 13 and 15: Schmugar as modified doesn’t explicitly teach the limitations. However, in an analogous art, Hen teaches: wherein evaluating the score comprises checking whether a time duration between creation and execution of the DLL is below a defined threshold (Hen - [0133]: wherein the computer-executable instructions are executable by the processor system to at least: based at least on the confirmation of the existence of the identified code package, determine whether a time period between a creation date on which the identified code package was created and a current date is less than a threshold duration of time).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Schmugar with DARLING and Dema and Hen so that determination is done to determine whether a time period between a creation date on which the identified code package was created and a current date is less than a threshold duration of time. The modification would have allowed the system to improve security.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Schmugar et al. (Pub. No.: US 2021/0200867, hereinafter Schmugar) and DARLING et al. (US 2024/0419797) and Dema et al. (US 2025/0133108) and Buyukkayhan et al. (US 9,998,484).
Regarding claim 16: Schmugar as modified discloses wherein evaluating the score comprises identifying, within the computer system, that: the application was observed loading the DLL as signed with a first prevalence that is above a first defined prevalence level (Schmugar - [0060]: the fingerprint comparator 240 determines whether the DLL fingerprint deviates from any of the first reference fingerprint(s) 136 known to be associated with trusted DLL(s) (e.g., a trusted DLL fingerprint));
However, Schmugar as modified doesn’t explicitly teach the limitations. In an analogous art, Buyukkayhan teaches: the application was observed loading the DLL as unsigned with a second prevalence that is below a second defined prevalence level (Buyukkayhan - [Col. 18, Line 48-49]: Examples of IOCs include … autorun unsigned DLL(s) loaded in more than a threshold (e.g., 10) processes).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Schmugar with DARLING and Dema and Buyukkayhan so that loaded unsigned DLL is checked with a threshold value. The modification would have allowed the system to improve security.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Schmugar et al. (Pub. No.: US 2021/0200867, hereinafter Schmugar) and DARLING et al. (US 2024/0419797) and Dema et al. (US 2025/0133108) and Zagorsky et al. (US 2020/0410096), Buyukkayhan et al. (US 9,998,484) and Zagorsky et al. (US 2020/0410096).
Regarding claim 17: Schmugar as modified discloses within the computer system, signatures of a signature vendor associated with the application were observed with a second prevalence that is below a second defined prevalence level (Schmugar - [0060]: the fingerprint comparator 240 determines whether the DLL fingerprint deviates from any of the first reference fingerprint(s) 136 known to be associated with trusted DLL(s) (e.g., a trusted DLL fingerprint)).
However, Schmugar as modified doesn’t explicitly teach the other limitations. In an analogous art, Zagorsky teaches: wherein evaluating the score comprises identifying that: the application was observed loading the DLL as signed in more than a first defined number of computer systems (Zagorsky - [0076]: verdicts rendered by outside services to files of another group, the another group also being associated with the dominant developer associated with the group of files, wherein a frequency of running applications developed by the dominant developer among the users exceeds a predetermined threshold);
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Schmugar with DARLING and Dema and Zagorsky so that number of file runs is compared with a threshold. The modification would have allowed the system to improve security.
However, Schmugar as modified doesn’t explicitly teach but Buyukkayhan dislcoses: the application was observed loading the DLL as unsigned with a second prevalence that is below a second defined prevalence level (Buyukkayhan - [Col. 18, Line 48-49]: Examples of IOCs include … autorun unsigned DLL(s) loaded in more than a threshold (e.g., 10) processes).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Schmugar with DARLING and Dema and Zagorsky, Buyukkayhan so that loaded unsigned DLL is checked with a threshold value. The modification would have allowed the system to improve security.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mankin et al. US 20240296223 [0045] discloses: in the event that allocation, setting of permissions, loading, and execution events as described above each follow in close succession, the likelihood of a malicious attack is increased. Furthermore, by way of example and without limitation thereto, in the event that the loaded computer-executable instructions originate from a remote network address, originate from a script, originate from an unsigned executable file, or from a dynamically-linked library, as well as other examples wherein the loaded computer-executable instructions originate from non-local or non-trusted sources, the likelihood of a malicious attack is increased
Jun US 20140137245 [0031] discloses: In the signature verification, the management application module 21 acquires the application package file of the determination application module 22 that is saved in the storage device 30. Based on a certificate or the like contained in the application package file, the management application module 21 determines whether the determination application module 22 is an integral determination application. By this signature verification, it is verified whether the developer of the application package file of the determination application module 22 is correct or not. It is also verified whether the application package file is an unaltered authentic one.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MENG LI whose telephone number is (571)272-8729. The examiner can normally be reached M-F 8:30-5:30.
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, Alexander Lagor can be reached on (571) 270-5143. 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.
/MENG LI/
Primary Examiner, Art Unit 2437
Prosecution Insights