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 .
Detailed Action
Claims 1-20 are pending
Priority
This application claims no priority. Therefore, the effective filing date of this application is 12/16/2024.
Specification
The specification filed on 12/16/2024 is acceptable for examination proceedings.
Drawings
The drawings are objected to because figures 6 and 9 contain text that is not legible. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 12/16/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements have been considered by the examiner.
Double Patenting
No double patenting rejection warranted at the time of this office action.
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.
Claims 2, 3, 9, 10, 18, 19, and 20 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.
Claims 2, 3, 9, 10, 18, and 19 recite the limitations “categorizing the pickle file as a normal computer behavior” and “categorizing the pickle file as an abnormal computer behavior”. However, a file itself cannot be categorized as abnormal or normal behavior. It is the operations executed by the file that can be categorized as normal or abnormal behavior. Examiner suggests amending these claims to recite ““categorizing the pickle file as representing a normal computer behavior” and “categorizing the pickle file as representing an abnormal computer behavior”. This is supported in para. 0006 of the specification “If the pickle file represents normal computer activities, then the AI/ML model may be safe to use. If, however, the pickle file represents abnormal or even malicious computer activities, then the AI/ML model is unsafe to use”. Appropriate correction is required.
Claim 20 recites the limitation “categorizing the pickle file as the safe or the unsafe”. However, claim 14 recites “and predicting the AI model is safe or unsafe”. There is no antecedent basis for a pickle file being safe or unsafe. Examiner suggests amending this limitation to “categorizing the AI model as safe or unsafe”. Appropriate correction is required.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 15 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claim 15 recites the limitation “generating a cybersecurity prediction based on the comparing of the pickle file function call trace associated with the pickle file to the pickle file function call trace profile generated by the machine learning model”. However, independent claim 14 already recites “predicting the AI model is safe or unsafe based on the comparing of the pickle file function call trace associated with the pickle file to the pickle file function call trace profile generated by the machine learning model”. Claim 15 recites “generating a cybersecurity prediction” and claim 14 recites “predicting the AI model is safe or unsafe”. The prediction of claim 15 is the same prediction that is being done in claim 14. Predicting if an AI model is safe or unsafe is the same thing as generating a cybersecurity prediction. Applicant may cancel the claim, amend the claim to place the claim in proper dependent form, rewrite the claim in independent form, or present a sufficient showing that the dependent claim complies with the statutory requirements.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because they directed to an abstract idea.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites a judicial exception (an abstract idea) that is not integrated into a practical application.
Step 1: Statutory Category
Claims 1 satisfies the statutory category requirement because it is directed to a method under 35 U.S.C. 101(a).
Step 2A, Prong 1 – Judicial Exception (Abstract Area)
The claim recites of a computer system that assesses an artificial intelligence (AI) model, comprising: conducting, by the computer system, a dynamic emulation of a pickle file associated with the AI model; and determining, by the computer system, a cybersecurity threat associated with the AI model based on the dynamic emulation of the pickle file.
The limitation of a computer system that assesses an artificial intelligence (AI) model, comprising: conducting, by the computer system, a dynamic emulation of a pickle file associated with the AI model, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually emulate dynamically a pickle file associated a AI model.
The limitation of determining, by the computer system, a cybersecurity threat associated with the AI model based on the dynamic emulation of the pickle file, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually determine a cybersecurity threat associated with the AI model.
Step 2A, Prong 2 – Integration into a practical Application
This judicial exception is not integrated into a practical application. The claim recites of conducting dynamic emulation of a pickle file, and determine a cybersecurity threat associated with the AI model. However, merely determining a cybersecurity threat associated with the AI model does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Simply making a determination does not prevent the cybersecurity threat and does not overcome the abstract idea.
Step 2B- “Significantly More” (Inventive concept)
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. In particular, the claim only recites one additional element of “executed by a computer system” recited at a high-level of generality (i.e., as a generic computer implementing the method) such that it amounts no more than mere instructions to apply the exception using a generic computer. Mere instructions to apply an exception using a generic computer cannot provide an inventive concept. The claim is not patent eligible.
Claim 2 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of categorizing the pickle file as a normal computer behavior. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually categorize the pickle file as a normal computer behavior.
Claim 3 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of categorizing the pickle file as an abnormal computer behavior. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually categorize the pickle file as an abnormal computer behavior.
Claim 4 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of conducting a static emulation of the pickle file associated with the AI model. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually conduct a static emulation of the pickle file associated with the AI model.
Claim 5 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of generating a cybersecurity prediction based on the dynamic emulation of the pickle file associated with the AI model. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually generate a cybersecurity prediction.
Claim 6 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of comparing a function call associated with the pickle file to function calls associated with known AI models previously assessed. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually compare a function call associated with the pickle file to function calls associated with known AI models previously assessed.
Claim 7 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of categorizing the pickle file as safe or unsafe based on the comparing of the function call to the function calls associated with the known AI models previously assessed. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually categorize the pickle file as safe or unsafe based on the comparing of the function call to the function calls associated with the known AI models previously assessed.
Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites a judicial exception (an abstract idea) that is not integrated into a practical application.
Step 1: Statutory Category
Claims 8 satisfies the statutory category requirement because it is directed to a computer system comprising memory and a processor to perform operations under 35 U.S.C. 101(a).
Step 2A, Prong 1 – Judicial Exception (Abstract Area)
The claim recites of a computer system that assesses an artificial intelligence (AI) model, comprising: at least one central processing unit; and at least one memory device storing instructions that, when executed by the at least one central processing unit, perform operations, the operations comprising: generating a function call trace by statically emulating a pickle file associated with the AI model; conducting a dynamic emulation of an incomplete portion of the function call trace generated by the statically emulating of the pickle file; and determining a cybersecurity threat associated with the AI model based on the dynamic emulation of the incomplete portion of the function call trace.
The limitation of generating a function call trace by statically emulating a pickle file associated with the AI model, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually generate a function call trace by statically emulating a pickle file.
The limitation of conducting a dynamic emulation of an incomplete portion of the function call trace generated by the statically emulating of the pickle file, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually conduct a dynamic emulation of an incomplete portion of the function call.
The limitation of determining a cybersecurity threat associated with the AI model based on the dynamic emulation of the incomplete portion of the function call trace, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually determine a cybersecurity threat associated with the AI model.
Step 2A, Prong 2 – Integration into a practical Application
This judicial exception is not integrated into a practical application. The claim recites of generating a function call trace, conducting dynamic emulation of a pickle file, and determine a cybersecurity threat associated with the AI model. However, merely determining a cybersecurity threat associated with the AI model does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Simply making a determination does not prevent the cybersecurity threat and does not overcome the abstract idea.
Step 2B- “Significantly More” (Inventive concept)
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. In particular, the claim only recites one additional element of “at least one central processing unit” recited at a high-level of generality (i.e., as a generic processor implementing the operations) such that it amounts no more than mere instructions to apply the exception using a generic processor. Mere instructions to apply an exception using a generic processor cannot provide an inventive concept. The claim is not patent eligible.
Claim 9 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the operations further comprise categorizing the pickle file as a normal computer behavior. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually categorize the pickle file as a normal computer behavior.
Claim 10 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the operations further comprise categorizing the pickle file as an abnormal computer behavior. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually categorize the pickle file as an abnormal computer behavior.
Claim 11 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the operations further comprise generating a cybersecurity prediction based on the dynamic emulation of the incomplete portion of the function call trace. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually generate a cybersecurity prediction.
Claim 12 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the operations further comprise comparing the function call trace associated with the pickle file to historical function call traces associated with AI models previously assessed. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually compare the function call trace associated with the pickle file to historical function call traces associated with AI models previously assessed.
Claim 13 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the operations further comprise categorizing the pickle file as safe or unsafe based on the comparing of the function call trace to the historical function call traces associated with the AI models previously assessed. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually categorize the pickle file as safe or unsafe based on the comparing of the function call trace to the historical function call traces.
Claim 14 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites a judicial exception (an abstract idea) that is not integrated into a practical application.
Step 1: Statutory Category
Claims 14 satisfies the statutory category requirement because it is directed to a memory device storing instructions that cause a processor to perform operations under 35 U.S.C. 101(a). Furthermore, the specification describes the memory as either USB flash memory drive (para. 0053) or non-volatile DIMMs (NV-DIMMs) (para. 0047).
Step 2A, Prong 1 – Judicial Exception (Abstract Area)
The claim recites of generating a pickle file function call trace by statically emulating a pickle file associated with an artificial intelligence (AI) model; identifying an incomplete portion of the pickle file function call trace generated by the statically emulating of the pickle file; completing the pickle file function call trace associated with the pickle file by dynamically emulating the incomplete portion of the pickle file function call trace; comparing the pickle file function call trace associated with the pickle file to a pickle file function call trace profile generated by a machine learning model trained using historical pickle file function call traces associated with pickle files previously assessed; and predicting the AI model is safe or unsafe based on the comparing of the pickle file function call trace associated with the pickle file to the pickle file function call trace profile generated by the machine learning model trained using the historical pickle file function call traces associated with the pickle files previously assessed.
The limitation of generating a pickle file function call trace by statically emulating a pickle file associated with an artificial intelligence (AI) model, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually generate a pickle file function call trace by statically emulating a pickle file.
The limitation of identifying an incomplete portion of the pickle file function call trace generated by the statically emulating of the pickle file, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually identify an incomplete portion of the pickle file function call trace.
The limitation of completing the pickle file function call trace associated with the pickle file by dynamically emulating the incomplete portion of the pickle file function call trace, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually complete the pickle file function call trace associated with the pickle file.
The limitation of comparing the pickle file function call trace associated with the pickle file to a pickle file function call trace profile generated by a machine learning model trained using historical pickle file function call traces associated with pickle files previously assessed, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually compare the pickle file function call trace associated with the pickle file to a pickle file function call trace profile generated by a machine learning model.
The limitation of predicting the AI model is safe or unsafe based on the comparing of the pickle file function call trace associated with the pickle file to the pickle file function call trace profile generated by the machine learning model trained using the historical pickle file function call traces associated with the pickle files previously assessed, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually predict the AI model is safe or unsafe based on the comparing of the pickle file function call trace.
Step 2A, Prong 2 – Integration into a practical Application
This judicial exception is not integrated into a practical application. The claim recites of generating a function call trace, identifying an incomplete portion of the pickle file, completing the pickle file function call trace, comparing the pickle file function call trace, and predicting if the AI model is safe or unsafe. However, merely predicting if the AI model is safe or unsafe does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Simply making a prediction does not prevent the cybersecurity threat and does not overcome the abstract idea.
Step 2B- “Significantly More” (Inventive concept)
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. In particular, the claim only recites one additional element of “memory device storing instructions that, when executed by at least one central processing unit, perform operations” recited at a high-level of generality (i.e., as a generic processor implementing the instructions) such that it amounts no more than mere instructions to apply the exception using a generic processor. Mere instructions to apply an exception using a generic processor cannot provide an inventive concept. The claim is not patent eligible.
Claim 15 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the operations further comprise generating a cybersecurity prediction based on the comparing of the pickle file function call trace associated with the pickle file to the pickle file function call trace profile generated by the machine learning model. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually generate a cybersecurity prediction based on the comparing of the pickle file function call trace associated with the pickle file to the pickle file function call trace profile generated by the machine learning model.
Claim 16 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the operations further comprise associating the pickle file with a normal operation in response to determining that the pickle file function call trace conforms to the pickle file function call trace profile generated by the machine learning model. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually associate the pickle file with a normal operation in response to determining that the pickle file function call trace conforms to the pickle file function call trace profile generated by the machine learning model.
Claim 17 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the operations further comprise associating the pickle file with an abnormal operation in response to determining that the pickle file function call trace fails to conform to the pickle file function call trace profile generated by the machine learning model. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually associate the pickle file with an abnormal operation in response to determining that the pickle file function call trace fails to conform to the pickle file function call trace profile generated by the machine learning model.
Claim 18 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the operations further comprise categorizing the pickle file as a normal operation. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually categorize the pickle file as a normal operation.
Claim 19 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the operations further comprise categorizing the pickle file as an abnormal operation. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually categorize the pickle file as an abnormal operation.
Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of categorizing the pickle file as the safe or the unsafe based on the comparing of the pickle file function call trace to the pickle file function call trace profile generated by the machine learning model. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually categorize the pickle file as the safe or the unsafe based on the comparing of the pickle file function call trace to the pickle file function call trace profile generated by the machine learning model.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 2, 3, and 5 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by CASEY (“A Large-Scale Exploit Instrumentation Study of AI/ML Supply Chain Attacks in Hugging Face Models”).
Regarding claim 1, CASEY teaches “A method executed by a computer system that assesses an artificial intelligence (AI) model, comprising: conducting, by the computer system, a dynamic emulation of a pickle file associated with the AI model; ([CASEY, Abstract] “The development of machine learning (ML) techniques has led to ample opportunities for developers to develop and deploy their own models. Hugging Face serves as an open source platform where developers can share and download other models in an effort to make ML development more collaborative. In order for models to be shared, they first need to be serialized. Certain Python serialization methods are considered unsafe, as they are vulnerable to object injection.”) ([CASEY, Section II AI/ML SUPPLY CHAIN ATTACK VIA UNTRUSTED MODELDESERIALIZATION] “Pickle is Python’s built-in serialization format that can be used by all model development frame works. Besides Python’s Pickle module, models developed using PyTorch can also choose to use its torch.save method to serialize a model [23] or torch.jit.save to serialize torch scripts1.”) ([CASEY, B. Untrusted Model Deserialization] “Exploiting Pickle and Pickle-based Formats: Python’s Pickle module implements a stack-based serialization protocol in which objects are deserialized in a binary format containing opcodes with values placed on a stack and an indexed data structure (memo) [32]. Thus, when an object is serialized using Pickle, this module encodes the object’s state as a sequence of instruction codes (opcodes) corresponding to a specific operation to be performed using values from the stack.”) ([CASEY, G. Identifying Malicious Models] “To identify malicious models, we develop a dynamic tracer to Track the calls made when deserializing a model file. This dynamic tracer relies on Python’s sysmodule (sys.settrace)[43] as well as the strace command[44] to get a full view of both the calls made within the loading Python functions, and system calls made for the operation. … Thus, we also use the strace command Provided by Linux to trace the system calls made during model deserialization. After using strace, we also use strace2csv[45] to convert strace’s produced trace files to CSV. Next, we combine the calls monitored from sys and strace to obtain a holistic view of all the functions/methods invoked during model deserialization. Since we have to load these files in order to run the trace and analyze the behavior, we run our tracer in a Docker container to protect ourselves from any potentially malicious files.”) [Examiner’s note: Examiner is interpreting running the dynamic tracer in a Docker container as dynamic emulation of the pickle file] and determining, by the computer system, a cybersecurity threat associated with the AI model based on the dynamic emulation of the pickle file. ([CASEY, G. Identifying Malicious Models] “Since we have to load these files in order to run the trace and analyze the behavior, we run our tracer in a Docker container to protect ourselves from any potentially malicious files. … In our experiment, we analyzed a total of 12,973 models. After collecting the system and Python call traces and converting them to CSVs, we look for key commands which can be indicative of malicious behaviors, i.e., socket, connect, execve, and chmod. We also check the strace logs for commands such as exec and eval. The presence of these commands could mean that an attacker is trying to connect to a socket to create a backdoor, execute arbitrary code on the victim’s machine, or change file permissions to gain access to sensitive files. If these commands are found, we write them to a csv or txt file that corresponds to that model file. We then manually analyze these files to see if the detected commands are malicious.”) ([CASEY, IX Conclusion] “Finally, we investigate how many models on Hugging Face are malicious and find 14 models that execute a payload. This exhibits the real threat that this type of vulnerability has on model sharing platforms such as Hugging Face.”)
Regarding claim 2, CASEY teaches all limitations of claim 1. CASEY further teaches “further comprising categorizing the pickle file as a normal computer behavior. ([CASEY, D. RQ4:Deliberately malicious model files] “Table IV shows a summary of the malicious models we found, broken down by payload type and by the system command(s) that our tracer flagged to find the malicious behavior. Our tracer flagged 86 model files out of the 12,973 we analyzed. Out of the 86 flagged files, we found 14 malicious model files. Out of these 14 malicious models, 9 (64%) were connecting to an external socket. Three of these models open a web browser and print a message, and then deletes the web browser entry from sys.modules. One ran the command ’ls’, and the final one ran ’echo ’pwnd!’. …To ensure we did not miss any potentially malicious files, we took a random sample of 383 models and manually analysed them. We found that none of them were malicious, and that our tracer did not miss any malicious models.”)
Regarding claim 3, CASEY teaches all limitations of claim 1. CASEY further teaches “further comprising categorizing the pickle file as an abnormal computer behavior. ([CASEY, D. RQ4: Deliberately malicious model files] “Table IV shows a summary of the malicious models we found, broken down by payload type and by the system command(s) that our tracer flagged to find the malicious behavior. Our tracer flagged 86 model files out of the 12,973 we analyzed. Out of the 86 flagged files, we found 14 malicious model files. Out of these 14 malicious models, 9 (64%) were connecting to an external socket. Three of these models open a web browser and print a message, and then deletes the web browser entry from sys.modules. One ran the command ’ls’, and the final one ran ’echo ’pwnd!’. …To ensure we did not miss any potentially malicious files, we took a random sample of 383 models and manually analysed them. We found that none of them were malicious, and that our tracer did not miss any malicious models.”)
Regarding claim 5, CASEY teaches all limitations of claim 1. CASEY further teaches “further comprising generating a cybersecurity prediction based on the dynamic emulation of the pickle file associated with the AI model. ([CASEY, I Introduction] “This feature in Hugging Face relies on identifying model import methods, such as pickle imports, that are known to injection vulnerabilities. We examine how well this flagging system reports potentially vulnerable models.”) ([CASEY, III Methodology] “Whenever a new model is published on Hugging Face, the platform scans binary model files for use of unsafe Pickle based serialization methods. Upon encountering a potentially unsafe method, the model file is flagged. In this question, we examine to what extent Hugging Face’s flagging approach pro vides good coverage of unsafe serialization methods.”) ([CASEY, G. Identifying Malicious Models] “Since we have to load these files in order to run the trace and analyze the behavior, we run our tracer in a Docker container to protect ourselves from any potentially malicious files.”) [Examiner’s Note: Examiner is interpreting flagging a model as potentially malicious as a cybersecurity prediction]
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.
Claims 4, 6, and 7 are rejected under 35 U.S.C. 103 as being unpatentable over CASEY in view of ZHAO (“Models Are Codes: Towards Measuring Malicious Code Poisoning Attacks on Pre-trained Model Hubs”), hereinafter CASEY-ZHAO.
Regarding claim 4, CASEY teaches all limitations of claim 1. However, CASEY does not teach “further comprising conducting a static emulation of the pickle file associated with the AI model.”.
In analogous teaching ZHAO teaches “further comprising conducting a static emulation of the pickle file associated with the AI model. ([ZHAO, 4.2 Model File Analysis] “Model deserialization is a crucial step in our security analysis pipeline, designed to uncover potentially malicious code or suspicious operations within model files. … As illustrated in Figure 2, our process begins with extracting the data.pkl file from the model archive (Step#1). We then use pickletools[70] to disassemble the pickle bytecode into human-readable opcodes (Step#2). This disassembly reveals the underlying structure of the serialized data, such as the GLOBAL op code (Step#2, line 2), which imports the runpy._run_codefunction, a potential vector for code execution. Through a systematic manual audit of all opcodes mentioned in pickle [68], we identify and summarize the potentially unsafe opcodes associated with code execution. The results of this analysis are presented in Table 4. We scan these opcodes for unsafe operations that could lead to code injection. Upon detecting such unsafe opcodes, we employ Fickling[54] to further decompile the pickle file into an AST, as depicted in Step#3. This higher-level representation exposes the structure of the potentially malicious code. From the AST, we extract suspicious code snippets by analyzing function call arguments. In Figure 2, we identify a function call to runpy._run_code with a constant argument that appears to be a Python script (Step#3, line 10-12), which is extracted as potentially malicious code.”) ([ZHAO, 4.3 In-depth Taint Analysis] “After extracting suspicious code snippets from dataset loading scripts and model files (PyTorch&Keras), MalHug implements a focused taint analysis, which has been proven to be good at detecting a wide range of malicious code poisoning attack patterns in previous studies[12,40]. To perform this analysis, we build MalHug on an open-source static analysis framework”)
Thus, given the teaching of ZHAO, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of static analysis by ZHAO into the teaching of a method executed by a computer system that assesses an artificial intelligence (AI) model by CASEY. One of ordinary skill in the art would have been motivated to do so because ZHAO recognizes the need to detect attacks on machine learning models ([ZHAO, Abstract] “recent security reports have uncovered vulnerabilities and instances of malicious attacks within these platforms, highlighting growing security concerns. This paper presents the first systematic study of malicious code poisoning attacks on pre-trained model hubs, focus ing on the Hugging Face platform. … To address these challenges, we propose MalHug, an end-to-end pipeline tailored for Hugging Face that combines dataset loading script extraction, model deserialization, in-depth taint analysis, and heuristic pattern matching to detect and classify malicious code poisoning attacks in datasets and models.”)
Regarding claim 6, CASEY teaches all limitations of claim 1. However, CASEY does not teach “further comprising comparing a function call associated with the pickle file to function calls associated with known AI models previously assessed”
In analogous teaching ZHAO teaches “further comprising comparing a function call associated with the pickle file to function calls associated with known AI models previously assessed. ([ZHAO, 4.1 Dataset Loading Scripts Analysis] “We begin by extracting the loading script associated with each dataset obtained from Hugging Face. Once the relevant scripts are extracted, we perform an initial analysis to identify unsafe libraries and APIs. This process involves scanning the script contents for import statements and function calls and cross-referencing them against a curated list of potentially unsafe libraries and APIs. To ensure a comprehensive and accurate review, we synthesize the static analysis rules used in Pyre [18] and Semgrep [74], thereby compiling a more extensive list of insecure libraries and APIs … The risky Libraries and APIs including known dangerous functions (e.g., eval, exec), libraries associated with command execution (e.g., os, subprocess), and networking modules that could indicate unauthorized data trans mission (e.g., requests, urllib). We employ regular expressions and AST (Abstract Syntax Tree) parsing to efficiently identify these elements within the code.”) ([ZHAO, 5.2 Industrial Deployment & Measurement] “Our comprehensive analysis reveals the distribution of suspicious APIs across models and dataset loading scripts, as shown in Table 5. In model files, we observe 27 occurrences of __builtin__.exec, 23 of __builtin__.eval, and 18 instances of os.system or posix.system. Dataset loading scripts exhibit a higher frequency of eval and execution functions, with 56 cases of __builtin__.compile and 74 of __builtin__.eval.”)
The same motivation to combine CASEY with ZHAO as in the rejection of claim 4 applies.
Regarding claim 7, CASEY-ZHAO teaches all limitations of claim 6. ZHAO further teaches “further comprising categorizing the pickle file as safe or unsafe based on the comparing of the function call to the function calls associated with the known AI models previously assessed. ([ZHAO, 4.1 Dataset Loading Scripts Analysis] “We begin by extracting the loading script associated with each dataset obtained from Hugging Face. Once the relevant scripts are extracted, we perform an initial analysis to identify unsafe libraries and APIs. This process involves scanning the script contents for import statements and function calls and cross-referencing them against a curated list of potentially unsafe libraries and APIs. To ensure a comprehensive and accurate review, we synthesize the static analysis rules used in Pyre [18] and Semgrep [74], thereby compiling a more extensive list of insecure libraries and APIs”) ([ZHAO, 4.2 Model File Analysis] “higher-level representation exposes the structure of the potentially malicious code. From the AST, we ex tract suspicious code snippets by analyzing function call arguments. In Figure 2, we identify a function call to runpy._run_code with a constant argument that appears to be a Python script (Step#3, line 10-12), which is extracted as potentially malicious code.”) ([ZHAO, 5.2 Industrial Deployment & Measurement] “Our comprehensive analysis reveals the distribution of suspicious APIs across models and dataset loading scripts, as shown in Table 5. In model files, we observe 27 occurrences of __builtin__.exec, 23 of __builtin__.eval, and 18 instances of os.system or posix.system. Dataset loading scripts exhibit a higher frequency of eval and execution functions, with 56 cases of __builtin__.compile and 74 of __builtin__.eval.”) ([ZHAO, 5.2 Industrial Deployment & Measurement] “Notably, the getattr function is overwhelmingly used despite Huggingface’s clear “unsafe” label, accounting for 91.2% of dangerous API usage (3,775 instances in models and 456 in dataset loading scripts).
The same motivation to combine CASEY with ZHAO as in the rejection of claim 4 applies.
Claims 8-13 are rejected under 35 U.S.C. 103 as being unpatentable over ZHAO (“Models Are Codes: Towards Measuring Malicious Code Poisoning Attacks on Pre-trained Model Hubs”) in view of SHUKLA (US-20190180036-A1), hereinafter ZHAO-SHUKLA.
Regarding claim 8, ZHAO teaches “A computer system that assesses an artificial intelligence (AI) model, comprising: at least one central processing unit; and at least one memory device storing instructions that, when executed by the at least one central processing unit, perform operations, the operations comprising: generating a function call trace by statically emulating a pickle file associated with the AI model; ([ZHAO, Abstract] “This paper presents the first systematic study of malicious code poisoning attacks on pre-trained model hubs, focusing on the Hugging Face platform. We conduct a comprehensive threat analysis, develop a taxonomy of model formats, and perform root cause analysis of vulnerable formats. … To address these challenges, we propose MalHug, an end-to-end pipeline tailored for Hugging Face that combines dataset loading script extraction, model deserialization, in-depth taint analysis, and heuristic pattern matching to detect and classify malicious code poisoning attacks in datasets and models.”) ([ZHAO, 4.2 Model File Analysis] “Model deserialization is a crucial step in our security analysis pipeline, designed to uncover potentially malicious code or suspicious operations within model files. … As illustrated in Figure 2, our process begins with extracting the data.pkl file from the model archive (Step#1). We then use pickletools[70] to disassemble the pickle bytecode into human-readable opcodes (Step#2). This disassembly reveals the underlying structure of the serialized data, such as the GLOBAL op code (Step#2, line 2), which imports the runpy._run_codefunction, a potential vector for code execution. Through a systematic manual audit of all opcodes mentioned in pickle [68], we identify and summarize the potentially unsafe opcodes associated with code execution. The results of this analysis are presented in Table 4. We scan these opcodes for unsafe operations that could lead to code injection. Upon detecting such unsafe opcodes, we employ Fickling[54] to further decompile the pickle file into an AST, as depicted in Step#3. This higher-level representation exposes the structure of the potentially malicious code. From the AST, we extract suspicious code snippets by analyzing function call arguments. In Figure 2, we identify a function call to runpy._run_code with a constant argument that appears to be a Python script (Step#3, line 10-12), which is extracted as potentially malicious code.”) ([ZHAO, 4.3 In-depth Taint Analysis] “After extracting suspicious code snippets from dataset loading scripts and model files(PyTorch&Keras), MalHug implements a focused taint analysis, which has been proven to be good at detecting a wide range of malicious code poisoning attack patterns in previous studies[12,40]. To perform this analysis, we build MalHug on an open-source static analysis framework”) ([ZHAO, 5.1 Experimental Setup] “Environment. The prototype of MalHug runs on a server with Ubuntu Linux 22.04, equipped with two AMD EPYC Milan 7713 CPUs”)
However, ZHAO does not teach “conducting a dynamic emulation of an incomplete portion of the function call trace generated by the statically emulating of the [pickle] file; and determining a cybersecurity threat associated with the [AI model] based on the dynamic emulation of the incomplete portion of the function call trace.”
In analogous teaching SHUKLA teaches “conducting a dynamic emulation of an incomplete portion of the function call trace generated by the statically emulating of the [pickle] file; ([SHUKLA, para. 0049] “FIG. 4 illustrates an example process 400 for the generation of rules used in the validation of API calls made by the individual script files, according to some embodiments. The interpreted code can be statically analyzed in step 410 to generate a list of the potential API calls that may be made. This list can be obtained through lexical analysis of both the original text of the interpreted code and its generated byte code. Dynamic analysis is performed in step 420 on the interpreted code of the script file by executing it in a controlled environment and recording the API calls made. All observed event’ (e.g. an API call, etc.) can be validated in step 430 by examining the code contained in the script file to ensure that the calls are consistent with the structure of the interpreted code. As an example, consistency can be checked by using knowledge about the API call and its arguments. How the arguments used by the API call are loaded into the registers serves as partial validation; the check can be further enhanced by validating the type of each argument.”) [Examiner’s Note: Examiner is interpreting an API call that is not executed as incomplete, SHUKLA teaches of static analysis generating a list of potential API calls and the dynamic analysis executing API calls and recording the events.] and determining a cybersecurity threat associated with the [AI model] based on the dynamic emulation of the incomplete portion of the function call trace. ([SHUKLA, para. 0054] “The observed API calls are matched against the rule set for the script file in step 660. If a rule is violated, an event is logged, and default action is performed in step 670. Otherwise the program continues its normal execution and continues monitoring new requests and process 600 returns to step 620.”) ([SHUKLA, para. 0055] “The rule server then further analyzes the event to determine if the event represents a real attack or an incompleteness of the rule list for that script. When the cause for the event is an incomplete rule set, an update can be sent to the application server. In case the event has resulted from a potential attack, the rule server may send instructions that include, but are not limited to, stopping the execution of the script and terminating the network connection responsible for the event.”) ([SHUKLA, para. 0039] “Authentication of API calls executed by interpreted code for preventing cyber-attacks can be deterministic and does not rely on the user to configure any rules or heuristics. It can also provide the ability to detect and block cyber-attacks before any harmful malicious instructions are executed.”)
SHUKLA does not teach of pickle files or of a cybersecurity threat associated with an AI model. However, these features are taught by ZHAO as seen in the rejection above. The same rejection applies.
Thus, given the teaching of SHUKLA, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of dynamic emulation of an incomplete portion of the function call trace by SHUKLA into the teaching of a computer system that assesses an artificial intelligence (AI) model by ZHAO. One of ordinary skill in the art would have been motivated to do so because SHUKLA recognizes the need to protect computer systems from malicious code ([SHUKLA, para. 0006] “a need exists for systems and methods to protect computer systems from attacks that exploit vulnerabilities in interpreted code.) ([SHUKLA, para. 0034] “a method and system are provided for a deterministic technique that prevents unauthorized API calls by interpreted code by isolating characteristics of individual files and generating rules specific to them to improve defensive capabilities.”)
Regarding claim 9, ZHAO-SHUKLA teach all limitations of claim 8. ZHAO further teaches “wherein the operations further comprise categorizing the pickle file as a normal computer behavior. ([ZHAO, 5.2 Industrial Deployment & Measurement ] “Notably, the getattr function is overwhelmingly used despite Huggingface’s clear “unsafe” label, accounting for 91.2% of dangerous API usage (3,775 instances in models and 456 in dataset Loading scripts).Upon closer inspection of the parameters passed to getattr, we do not identify any instances of actual malicious exploitation. … Following the filtering of unsafe APIs/Libs, we perform extensive malicious behavior detection on these suspicious code snippets. So far, based on a three-month continuous detection on the Ant Group mirrored HuggingFace instance, MalHug has identified 91 malicious models and 9 malicious dataset loading scripts. Among the 91 malicious models, we found 76 Pickle variants and 15 models using Keras custom Lambda layers for malicious purposes. The publication dates of these malicious artifacts range from March 2022 to June 2024. Figure 4 presents a classification of malicious behaviors based on code snippets extracted from these identified malicious artifacts, categorized through static analysis techniques and meticulous manual reviews by experienced researchers.”)
Regarding claim 10, ZHAO-SHUKLA teach all limitations of claim 8. ZHAO further teaches “wherein the operations further comprise categorizing the pickle file as an abnormal computer behavior. ([ZHAO, 5.2 Industrial Deployment & Measurement] “Notably, the getattr function is overwhelmingly used despite Huggingface’s clear “unsafe” label, accounting for 91.2% of dangerous API usage (3,775 instances in models and 456 in dataset Loading scripts).Upon closer inspection of the parameters passed to getattr, we do not identify any instances of actual malicious exploitation. … Following the filtering of unsafe APIs/Libs, we perform extensive malicious behavior detection on these suspicious code snippets. So far, based on a three-month continuous detection on the Ant Group mirrored HuggingFace instance, MalHug has identified 91 malicious models and 9 malicious dataset loading scripts. Among the 91 malicious models, we found 76 Pickle variants and 15 models using Keras custom Lambda layers for malicious purposes. The publication dates of these malicious artifacts range from March 2022 to June 2024. Figure 4 presents a classification of malicious behaviors based on code snippets extracted from these identified malicious artifacts, categorized through static analysis techniques and meticulous manual reviews by experienced researchers.”)
Regarding claim 11, ZHAO-SHUKLA teach all limitations of claim 8. SHUKLA further teaches “wherein the operations further comprise generating a cybersecurity prediction based on the dynamic emulation of the incomplete portion of the function call trace. ([SHUKLA, para. 0049] “Dynamic analysis is performed in step 420 on the interpreted code of the script file by executing it in a controlled environment and recording the API calls made. All observed event’ (e.g. an API call, etc.) can be validated in step 430 by examining the code contained in the script file to ensure that the calls are consistent with the structure of the interpreted code. ”) ([SHUKLA, para. 0054] “The observed API calls are matched against the rule set for the script file in step 660. If a rule is violated, an event is logged, and default action is performed in step 670. “) ([SHUKLA, para. 0055] “The event is reported to the rule server. The rule server then further analyzes the event to determine if the event represents a real attack or an incompleteness of the rule list for that script.”) [Examiner’s note: Examiner is interpreting a rule violation as a cybersecurity prediction of a potential attack.]
The same motivation to modify ZHAO with SHUKLA as in the rejection of claim 8 applies.
Regarding claim 12, ZHAO-SHUKLA teach all limitations of claim 8. ZHAO further teaches “wherein the operations further comprise comparing the function call trace associated with the pickle file to historical function call traces associated with AI models previously assessed. ([ZHAO, 4.1 Dataset Loading Scripts Analysis] “We begin by extracting the loading script associated with each dataset obtained from Hugging Face. Once the relevant scripts are extracted, we perform an initial analysis to identify unsafe libraries and APIs. This process involves scanning the script contents for import statements and function calls and cross-referencing them against a curated list of potentially unsafe libraries and APIs. To ensure a comprehensive and accurate review, we synthesize the static analysis rules used in Pyre [18] and Semgrep [74], thereby compiling a more extensive list of insecure libraries and APIs”) ([ZHAO, 4.2 Model File Analysis] “higher-level representation exposes the structure of the potentially malicious code. From the AST, we extract suspicious code snippets by analyzing function call arguments. In Figure 2, we identify a function call to runpy._run_code with a constant argument that appears to be a Python script (Step#3, line 10-12), which is extracted as potentially malicious code.”) ([ZHAO, 5.2 Industrial Deployment & Measurement] “Our comprehensive analysis reveals the distribution of suspicious APIs across models and dataset loading scripts, as shown in Table 5. In model files, we observe 27 occurrences of __builtin__.exec, 23 of __builtin__.eval, and 18 instances of os.system or posix.system. Dataset loading scripts exhibit a higher frequency of eval and execution functions, with 56 cases of __builtin__.compile and 74 of __builtin__.eval.”) ([ZHAO, 5.2 Industrial Deployment & Measurement] “Notably, the getattr function is overwhelmingly used despite Huggingface’s clear “unsafe” label, accounting for 91.2% of dangerous API usage (3,775 instances in models and 456 in dataset loading scripts).
Regarding claim 13, ZHAO-SHUKLA teach all limitations of claim 12. ZHAO further teaches “wherein the operations further comprise categorizing the pickle file as safe or unsafe based on the comparing of the function call trace to the historical function call traces associated with the AI models previously assessed. ([ZHAO, 4.1 Dataset Loading Scripts Analysis] “We begin by extracting the loading script associated with each dataset obtained from Hugging Face. Once the relevant scripts are extracted, we perform an initial analysis to identify unsafe libraries and APIs. This process involves scanning the script contents for import statements and function calls and cross-referencing them against a curated list of potentially unsafe libraries and APIs. To ensure a comprehensive and accurate review, we synthesize the static analysis rules used in Pyre [18] and Semgrep [74], thereby compiling a more extensive list of insecure libraries and APIs”) ([ZHAO, 4.2 Model File Analysis] “higher-level representation exposes the structure of the potentially malicious code. From the AST, we extract suspicious code snippets by analyzing function call arguments. In Figure 2, we identify a function call to runpy._run_code with a constant argument that appears to be a Python script (Step#3, line 10-12), which is extracted as potentially malicious code.”) ([ZHAO, 5.2 Industrial Deployment & Measurement] “Our comprehensive analysis reveals the distribution of suspicious APIs across models and dataset loading scripts, as shown in Table 5. In model files, we observe 27 occurrences of __builtin_ .exec, 23 of __builtin__.eval, and 18 instances of os.system or posix.system. Dataset loading scripts exhibit a higher frequency of eval and execution functions, with 56 cases of __builtin__.compile and 74 of __builtin__.eval. … Notably, the getattr function is overwhelmingly used despite Huggingface’s clear “unsafe” label, accounting for 91.2% of dangerous API usage (3,775 instances in models and 456 in dataset loading scripts … Among the 91 malicious models, we found 76 Pickle variants and 15 models using Keras custom Lambda layers for malicious purposes. The publication dates of these malicious artifacts range from March 2022 to June 2024. Figure 4 presents a classification of malicious behaviors based on code snippets extracted from these identified malicious artifacts).
Allowable Subject Matter
Claim 14-20 recite of allowable subject matter. Based on claims 15-20 depending on claim 14 they are also indicated as allowable. A reason for allowance will be noted in a Notice of Allowance once all other rejections have been overcome.
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to Applicant’s
disclosure.
COHEN (US-12028368-B1): This prior art teaches of a system and method for detecting a combined cybersecurity risk for an artificial intelligence (AI) model is presented. The method includes: inspecting a computing environment for an AI model deployed therein; generating a representation of the AI model in a security database, the security database including a representation of the computing environment; detecting a first cybersecurity risk respective of the AI model; inspecting the computing environment for a cybersecurity object; determining that the AI model is exposed to a toxic combination cybersecurity risk based on the detected first cybersecurity risk and the cybersecurity object; and initiating a mitigation action based on the toxic combination cybersecurity risk.
BERGER (US-11757907-B1): This prior art teaches of a cybersecurity system is provided for automated cybersecurity insights, remediation recommendations, and service provisioning. The cybersecurity system can generate threat insights and/or generate remediation recommendations using machine learning models and cybersecurity data obtained from target networks, partners, and the like. To provision cybersecurity services, cybersecurity system may collect metadata regarding the network connections and use cases desired for one or more services. Once the metadata has been collected, the cybersecurity assessment system automatically provisions the selected services based on the provided data, such as duration of time elected, service metrics, and the like.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AFAQ ALI whose telephone number is (571)272-1571. The examiner can normally be reached Mon - Fri 7:30am - 5:30pm EST.
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, ALI SHAYANFAR can be reached at (571) 270-1050. 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.
/A.A./
08/07/2026
/AFAQ ALI/Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights