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
The instant application having Application No. 18/896,763 is presented for examination by the examiner. Claims 1, 4, 8-12, 14, 16 and 18 are amended, claims 6-7, 13 are 15 cancelled, claims 21-24 are newly added, claims 1-5, 8-12, 14 and 16-24 have been examined.
Response to Arguments
Applicant' s arguments filed 06/03/2026, with respect to the rejection(s) of claim(s) 1, 12 and 18 under 35 U.S.C. 103 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claim 1-3, 5-7 and 9-20 is rejected under 35 U.S.C. § 103 as being unpatentable over Conway (US 2025/0013753 A1), in view of Deng N.P.L “PentestGPT: An LLM-empowered Automatic Penetration Testing Tool”, in view of Yao N.P.L “ReAct: Synergizing Reasoning and Acting in Language Models”, and further in view of Jin N.P.L “Binary Code Summarization: Benchmarking ChatGPT/GPT-4 and Other Large Language Models”.
Regarding Claim 1
Conway discloses a method for analyzing a function of a binary (Conway: [0023], [0077]-[0082]: analyzing an unknown binary to determine its contents, vulnerabilities, and to generate a reverse SBOM identifying components and their function) comprising:
(a) receiving the binary (Conway ¶[0035]-[0036], [0078]: receiving input data 212 comprising an unknown binary; FIG. 6, step 610);
(b) parsing the binary with one or more of a suite of tools (SOT) to create tool outputs (Conway ¶[0029], [0031], [0043]-[0049], [0068]: a suite of data collectors 232, e.g., disassemblers Binwalk, Radare2, a “strings” tool, and function-call-graph generators; process the binary to produce tool outputs such as disassembly data, function call graphs, strings data, and binary images);
(c) initializing a memory representation system (MRS) with the tool outputs (Conway: [0046]-[0048], [0065]: outputs of the data collectors are written to a primary datastore 236 managed by one or more schemas, the primary datastore serving as a unified data store from which subsequent tools and extractors retrieve data);
(g) modifying contents of the MRS with a subsequent tool output received from the tool (Conway: [0046]-[0048], [0063]: outputs of a subsequently executed tool are written back to the primary datastore, updating its contents for further analysis); and
(i) analyzing the function of the binary (Conway: [0051]-[0057], [0073]: information extractors analyze the binary to determine its function, components, and vulnerabilities).
Conway discloses that the sequence of tools applied to the binary is arranged into pipelines that are designed in advance by a subject matter expert using a builder. Conway does not explicitly disclose (d) sending a natural language prompt to a large language model (LLM) containing instructions to reason about the tool outputs in the MRS and to determine an investigatory step, or (h) iteratively repeating the reasoning and tool-execution steps until a termination condition is reached. However, Deng discloses: (d) sending a natural language prompt to an LLM, the natural language prompt containing instructions to reason about the tool outputs in the MRS and to determine an investigatory step (Deng: §5.3, Reasoning Module, FIG. 3 (steps 1-4), FIG. 4: the Reasoning Module obtains testing results and maintains a natural language encoded status tree (the Pentesting Task Tree) which it evaluates to identify and decide the next task to perform); and (h) iteratively repeating steps (d) to (g) until a termination condition is reached (Deng: §5.1, FIG. 5: the recommended step is generated, executed, and its outcome fed back to the Reasoning Module to update the status tree, and this process is repeated until the LLM completes the penetration testing process).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Conway's binary analysis method such that an LLM reasons over the tool outputs and determines the next investigatory step to perform in an iterative loop as taught by Deng. Conway and Deng are analogous art directed to automated security testing and analysis performed by executing a sequence of tools and using the outcome of each step to inform the next. The motivation to combine would be to overcome Conway's reliance on statically-built, subject-matter-expert-designed pipelines (Conway: [0007], [0030], [0041]) by adaptively determining the next step based on the outcomes of prior steps, consistent with Deng's own rationale that a fixed testing sequence must account for what is actually discovered as testing proceeds and consistent with the automation goals expressed by Conway itself.
Conway as modified by Deng discloses an LLM that determines a next step, but does not explicitly disclose (e) generating, by the LLM, instructions that specify a tool of the SOT and data stored in the MRS, or (f) parsing those instructions into structured information comprising the reasoning for using the tool, identification of the tool, and one or more operands, and translating that structured information into a call to the tool. However, Yao and Deng disclose: (e) generating, by the LLM, instructions to perform the investigatory step, wherein the instructions specify a tool of the SOT and data stored in the MRS (Yao: §3.1, Action Space: the LLM emits an action of the form specifying a discrete tool together with an operand on which the tool acts, e.g., search[entity]; Deng: §5.4, Generation Module, steps 5-6: the sub-task identified by the Reasoning Module is transformed by the Generation Module into a precise command specifying a tool and its operand); and (f) parsing the instructions to perform the investigatory step into structured information comprising the reasoning for using the tool, identification of the tool, and one or more operands for the tool (Yao: §2: the LLM's output is structured as a thought providing the reasoning, distinct from an action specifying the tool identity and its operand; Deng: §5.4: the Generation Module first expands the received sub-task into a sequence of detailed steps considering the possible tools and operations available within the testing environment, then transforms each expanded step into a precise command, a two-stage reasoning-then-command process expressly designed to address model inaccuracy and hallucination), and translating the structured information to data to generate a call to the tool, wherein translating the natural language to data uses context provided by expert knowledge regarding the function and use of individual tools in the SOT to generate the call to the tool (Yao: §3.1: a predefined action space defines each tool's required input format, which is used to construct the executable call; Deng: §5.4: the Generation Module's command generation step is directed to consider the possible tools and operations available in the testing environment in order to produce a precise, executable terminal command for the specific tool selected), and providing tool data from the MRS to the tool (Conway: [0046]-[0048]: data previously stored to the primary datastore is retrieved and provided as input to the subsequent tool).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to structure Conway/Deng's LLM step determination in the reasoning plus action form taught by Yao and generate the executable tool command via Deng's dedicated generation step. Yao and Deng are analogous art directed to LLMs that reason about and select external tools to accomplish a task, and the motivation to combine would be to reliably convert the LLM selected step into an actual tool call, reducing malformed or hallucinated invocations (Deng: §5.4; Yao: §3.3).
Conway as modified discloses analyzing the function of the binary (Conway: [0051]-[0057], [0073]); to the extent it is argued that Conway does not explicitly disclose that the analysis of the function of the binary is performed by the LLM, Jin discloses an LLM analyzing disassembled/decompiled binary code and producing an assessment of the function of that code (Jin: Abstract, §§1-3).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have the LLM of Conway/Deng/Yao perform the analysis of the binary's function as taught by Jin. Jin is analogous art directed to using LLMs to determine the function of binary code. The motivation to combine would be to leverage the same LLM already orchestrating the tool suite to synthesize the collected tool outputs into a determination of the binary's function, providing an interpretable result consistent with Conway's goal of trustworthy, reviewable analysis (Conway: [0009], [0060]).
Regarding Claim 2
Conway discloses:
The method of claim 1, wherein the SOT comprises software reverse engineering tools including at least one of a decompiler, a disassembler, a string deobfuscator, an unpacker, a control flow extractor, or a memory analysis tool (Conway: ¶[0023]: pipelined reverse engineering techniques are applied to the binary, where a pipeline may begin by applying a disassembler to the binary to obtain disassembly data; ¶[0068]: reverse engineering tools such as Radare2 perform disassembly and debugging of code extracted from the binary; ¶[0073]: reverse engineering tools including disassemblers, debuggers, static analysis tools, and dynamic analysis tools are used to extract and analyze data from the binary.).
Regarding Claim 3
Conway as modified discloses the method of claim 1. Conway as modified does not explicitly disclose the manner of generating the natural language prompt; however, Deng discloses wherein the natural language prompt is generated by: fetching the tool outputs from the MRS (Deng: §5.5: raw security testing tool outputs are obtained and processed by the Parsing Module; Conway: [0046]-[0048], [0060]: retrieving stored tool outputs from the datastore); translating the tool outputs to natural language text (Deng: §5.5: verbose tool outputs are condensed and their essential information extracted for use by the other modules; Jin: §§1-3: rendering binary/disassembly tool output into natural language text); and combining the natural language text with descriptions of individual tools in the SOT and requirements for using each of those tools (Deng §5.4: the prompt associated with the sub-task requires the LLM to consider the possible tools and operations available within the testing environment; Yao §3.1: the prompt enumerates the available actions and their required input formats). The motivation to combine is the same as set forth for claim 1, to ground the LLM's reasoning in the stored tool outputs and inform it of the tools it may invoke.
Regarding Claim 4
Conway as modified discloses the method of claim 3, wherein the tool outputs comprise runtime objects that are stored in the MRS (Conway: [0046]-[0048], [0065]: data collector outputs are stored as data objects in the primary datastore under a schema), and wherein translating the tool outputs to natural language text comprises generating a reference to a runtime object stored in the MRS without including the runtime object itself in the natural language prompt sent to the LLM (Conway: [0065]: the schema provides metadata linking and referencing stored data objects so that other processes may act on the referenced data; Deng: §§3-4: large tool outputs are represented in the prompt in condensed/summarized form referring to the stored result rather than embedding the entire object). The motivation to combine is the same as set forth for claims 1 and 3.
Regarding claim 5
Conway as modified discloses the method of claim 3, wherein translating the tool outputs to natural language text uses context provided by expert knowledge regarding the function and use of individual tools in the SOT to generate the natural language text (Deng: §5.5, Parsing Module: the module is devised to handle four distinct types of information where each category is paired with a set of carefully designed prompts, and for source code analysis a dedicated code interpreter is integrated to execute the task; Jin: §§1-3: an LLM translates binary/disassembly tool output into natural language using knowledge of what the disassembly/decompilation tool's output represents).
It would have been obvious to configure the translation of tool outputs to natural language using prompts and processing tailored to the category and source of each tool's output, as taught by Deng and Jin, so that the natural language text accurately reflects what each specific tool produced. The motivation to combine is the same as set forth for claims 1 and 3.
Regarding Claim 8
Conway as modified discloses the method of claim 1, wherein generation of the call to the tool comprises identifying a reference that indicates a runtime object in the MRS within the instructions to perform the investigatory step, retrieving the runtime object from the MRS based on the reference, and providing the runtime object to the tool as part of the call (Conway: [0046]-[0048], [0065]: a subsequent tool identifies the relevant stored data via the schema/metadata reference, retrieves that stored data object from the primary datastore, and receives it as input; Deng: §5.4, FIG. 5: the command generated by the Generation Module identifies the target on which the tool operates, e.g., the specific ports/services identified in the task tree, and the corresponding data is supplied to the tool when it is invoked). The motivation to combine is the same as set forth for claim 1.
Regarding Claim 9
Conway as modified discloses the method of claim 1, wherein the termination condition is the LLM determining the function of the binary, or reaching a time limit (Deng: §5.1: the iterative cycle of prompting, executing, and feedback is repeated until the LLM completes the entire penetration testing process; Yao: §3.1: the loop terminates upon a finish[answer] action indicating the task has been resolved; Jin: Abstract, §§1-3: the LLM produces a determination of the code's function). The claim recites the condition in the alternative ("or reaching a time limit"), and teaching either alternative satisfies the limitation; imposing a time limit on an automated analysis is further a well-known and obvious design expedient. The motivation to combine is the same as set forth for claim 1.
Regarding Claim 10
Conway discloses:
The method of claim 1, wherein accessing the function of the binary comprises classifying the binary as malware or not (Conway teaches analyzing a binary and determining whether the binary contains malicious code such as malware (¶0023). Conway further teaches comparing the function call graph of the binary to structures associated with known malware families and classifying the binary based on similarity scores exceeding a threshold (¶0057). Thus Conway teaches classifying the binary as malware or not.).
Regarding Claim 12
Conway as modified discloses an expert system for analyzing a function of a binary comprising:
a processing unit; a memory coupled to the processing unit and storing computer-executable instructions (Conway: [0026]-[0027]: one or more processors 112 and memory 114 storing instructions 116);
a memory representation system (MRS) configured to store tool outputs generated by a suite of tools (SOT) (Conway: [0046], [0065]: primary datastore 236 stores outputs generated by the data collectors/information extractors);
Conway does not explicitly disclose the following LLM-orchestration elements; however, Deng and Yao disclose:
a large language model (LLM) orchestrator (LO) configured to place calls to the SOT, fetch the tool outputs from MRS, and generate a natural language prompt containing instructions to reason about the tool outputs in the MRS and determine an investigatory step to analyze the function of the binary (Deng: §5.1, §5.3, FIG. 3: the framework's modules place calls to the tools, obtain prior testing results, and construct a natural-language prompt directing the LLM to reason over the task tree and determine the next task; Conway: [0032], [0039]: an analysis and execution engine / orchestration phase coordinates tool execution);
an LLM configured to receive the natural language prompt from the LO and generate natural language instructions to perform the investigatory step, wherein the natural language instructions are parsed by the LO and passed to the SOT (Deng: §5.3, §5.4: the LLM outputs a recommended sub-task which is passed to the Generation Module and transformed into commands passed to the testing tools; Yao: §2, §3.1: the LLM emits a thought and an action dispatched to the tool);
a data to natural language translator (D2NLT) configured to translate the tool outputs from the MRS into natural language text, wherein the D2NLT uses context provided by expert knowledge regarding the function and use of individual tools in the SOT to generate the natural language text, and wherein the natural language text is provided to the LLM (Deng: §5.5, Parsing Module: raw security testing tool outputs are condensed and their essential information extracted, each category of information being paired with a set of designed prompts, and the resulting condensed information is provided to the other modules; Jin: §§1-3: translating binary/disassembly tool output into natural language); and
a natural language to data translator (NL2DT) configured to translate the natural language instructions from the LLM to perform the investigatory step into a call to the SOT, wherein the NL2DT uses context provided by expert knowledge regarding the function and use of individual tools in the SOT to generate the call (Deng: §5.4, Generation Module, FIG. 5: the sub-task from the Reasoning Module is expanded considering the tools and operations available in the testing environment and then transformed into a precise executable terminal command; Yao: §3.1: the predefined action space supplies each tool's required input format used to construct the executable call). The rationale and motivation to combine Conway with Deng, Yao, and Jin are the same as set forth above in the rejection of claim 1, applied to the corresponding system elements.
Regarding Claim 14
Regarding claim 14, Conway as modified discloses the system of claim 12, wherein the LO, to generate the natural language prompt, is further configured to combine the natural language text with descriptions of individual tools in the SOT and requirements for using those tools (Deng: §5.4: the prompt associated with a sub-task requires the LLM to consider the possible tools and operations available within the testing environment; Yao: §3.1: the prompt enumerates the available actions and their required input formats). Same rationale applies here as above in rejecting claim 12.
Regarding Claim 17
Conway as modified discloses the system of claim 12, wherein the LO is further configured to provide a pre-determined prompt to the LLM upon a result of the investigatory step meeting a certain condition (Deng: §5.3, FIG. 3: four sets of designed prompts sequentially guide the Reasoning Module through its stages, and where the verification step identifies a discrepancy in the updated task tree the information is reverted to the LLM for correction and regeneration; §5.4: a fresh session with its associated prompt is initiated upon receipt of each new sub-task). Same rationale applies here as above in rejecting claim 12.
Regarding Claim 18
Claim 18 is directed to a storage media comprising instructions corresponding to the method in claim 1. Claim 18 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 19
Conway as modified discloses the computer-readable storage media of claim 18, wherein the instructions further cause the computing device to perform operations comprising: generating, by the LLM, a textual explanation of the function of the binary (Jin: Abstract, §§1-3: the LLM generates a natural-language summary/explanation describing the function of the binary code; Conway: [0073]: producing a human-readable characterization of the binary and its components). The motivation to combine is the same as set forth for claim 1 with respect to Jin, to provide an interpretable output identifying what the binary does, consistent with Conway's goal of producing trustworthy, reviewable analysis results (Conway: [0009], [0060]).
Regarding Claim 20
Conway discloses:
The computer-readable storage media of claim 18, wherein the instructions further cause the computing device to perform operations comprising:
classifying the binary as malware (Conway: ¶[0057]: comparing the structure of the function call graph to structures associated with known malware or malware families.).;
generating a signature of the binary (Conway: ¶[0061]: generate fingerprints associated with known vulnerabilities or malicious code.).; and
submitting the signature to a malware tracking database (Conway: ¶[0062]: the fingerprints are stored in a database to create a catalog of vulnerabilities.).
Regarding Claim 21
Conway as modified discloses the method of claim 1, wherein contents of the MRS are modified only by tools of the SOT and not directly by output of the LLM (Conway: [0046]: the data collectors 232 are configured to write their outputs to the datastore; in the combination, the LLM of Deng/Yao emits instructions that cause tools to execute, and it is the tools, not the LLM, that write outputs to the primary datastore). It would have been obvious to maintain Conway’s architecture, in which the tools are the components that write results to the datastore, when incorporating the LLM orchestration of Deng/Yao, because Conway already assigns datastore writes to the tools (Conway: [0046]) and the LLM’s role in Deng/Yao is to decide and direct actions rather than to persist tool results.
Regarding Claim 22
Conway as modified discloses the system of claim 12, wherein contents of the MRS are modified only by the SOT and the LLM is not configured to write directly to the MRS (Conway: [0046]: the tools write their outputs to the datastore; in the combination the LLM directs which tools run but does not itself write to the datastore). Same rationale applies here as above in rejecting claim 21.
Regarding Claim 23
Conway as modified discloses the computer-readable storage media of claim 18, wherein modifications to the contents of the MRS by tools of the SOT and not directly by the LLM prevents propagation of hallucinations generated by the LLM into the MRS (Conway [0046]: tool outputs, rather than model-generated content, populate the datastore; Yao §3.3, Table 2: an architecture that grounds the model's trajectory in externally retrieved observations rather than allowing the model's own generated content to populate the working record yields a materially lower rate of hallucinated output, 6% versus 14%, than an architecture without that restriction).
It would have been obvious to restrict writes to the MRS to the tools of the SOT rather than the LLM in order to obtain this same hallucination reducing benefit, since Yao demonstrates that excluding model generated content from the record the model itself relies on for further reasoning is what produces the reduction. Same rationale applies here as above in rejecting claims 21 and 22.
Regarding Claim 24
Conway as modified discloses the method of claim 1, wherein the LLM performs retrieval-augmented generation (RAG) using the tool outputs stored in the MRS as a knowledge base to generate a response to the natural language prompt (Deng: §5.3: the Reasoning Module retrieves prior testing results and maintains them in the task tree, which is provided to the LLM to generate its determination of the next step; §5.5: tool outputs are condensed by the Parsing Module before being supplied to the LLM as prompt context; Conway: [0046], [0065]: the primary datastore serves as the store of tool outputs from which data is retrieved for further processing). It would have been obvious to condition the LLM's response on the tool outputs retrieved from the datastore so that the analysis is grounded in data actually extracted from the binary rather than on the model's unsupported output. The motivation to combine is the same as set forth for claim 1.
Claims 4 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Conway (US 2025/0013753 A1), in view of Deng N.P.L “PentestGPT: An LLM-empowered Automatic Penetration Testing Tool”, in view of Yao N.P.L “ReAct: Synergizing Reasoning and Acting in Language Models”, and further in view of Jin N.P.L “Binary Code Summarization: Benchmarking ChatGPT/GPT-4 and Other Large Language Models” as applied to claim 1 above, and in further view of Nemtsov (US 12095806 B1).
Regarding Claim 4
Conway teaches storing and retrieving outputs generated by reverse-engineering analysis tools within a pipeline architecture and using those outputs in subsequent analysis stages to analyze a binary. Siracusano teaches generating natural language prompts for an LLM based on processed information and using those prompts in an iterative analysis framework. However, Conway and Siracusano are silent in explicitly teaching that the tool outputs comprise runtime objects. Nemtsov teaches representing detected cybersecurity objects as nodes in a security graph generated during inspection of a resource. For example, Nemtsov teaches that detected cybersecurity objects are represented in a security graph and that a node is generated to represent a malware object detected on a resource (Column 12, Lines 15-54). Nemtsov further teaches receiving runtime data from an inspected resource and generating definitions and mitigation logic based on detected cybersecurity objects and runtime data (Column 12, Lines 15-54). These teachings demonstrate that outputs produced by inspection and analysis tools may comprise objects representing detected entities derived from runtime information.
It would have been obvious to incorporate the object-based representation of analysis results taught by Nemtsov into the automated analysis pipeline of Conway, as modified by Siracusano, so that outputs of analysis tools are represented as runtime objects. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results. Representing analysis outputs as objects in a graph structure would predictably improve automated reasoning and correlation of detected cybersecurity entities across analysis steps.
Regarding Claim 8
Conway teaches storing and retrieving outputs generated by reverse-engineering analysis tools within a pipeline architecture and providing those outputs to subsequent analysis tools through a shared datastore used by the analysis pipeline. Siracusano teaches generating structured prompts and instructions within a processing pipeline to guide automated analysis tasks and tool execution. However, Conway and Siracusano are silent in explicitly teaching that a call to the tool indicates a runtime object in a MRS. On the other hand, Nemtsov teaches representing detected cybersecurity objects as nodes within a security graph stored in a graph database and generating instructions which, when executed, perform queries on the security graph to detect nodes representing resources or cybersecurity threats (Column 12, Lines 15 - Column 13, Line 50). Because the nodes in the security graph represent detected cybersecurity objects, these nodes correspond to runtime objects stored within the system’s memory representation structures. The generated query instructions operate on and reference these nodes when executed by the graph database. These teachings demonstrate that tool calls reference runtime objects represented within a system memory structure.
It would have been obvious to incorporate the object-based graph representation and query operations of Nemtsov into the automated analysis pipeline of Conway, as modified by Siracusano, so that calls to analysis tools reference runtime objects stored in the system’s memory representation structures. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results. Using runtime object representations within a shared memory structure and invoking tools that operate on those objects would predictably improve the system’s ability to correlate and analyze detected cybersecurity entities across analysis steps.
Allowable Subject Matter
Claims 11 and 16 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. The following is a statement of reasons for the indication of allowable subject matter: The prior art of record, including Conway, Deng, Yao, and Jin, does not teach or reasonably suggest, in combination with the remaining limitations of the respective base claims, the limitations of claim 11 (and correspondingly claim 16) directed to determining, without human feedback and before calling the tool of the SOT, that the instructions to perform the investigatory step are invalid; generating an explanation of why the instructions are invalid; providing that explanation as part of a prompt to revise the instructions to the LLM; and receiving revised instructions from the LLM.
Specifically, while Yao discloses a reasoning action loop and Deng discloses a parsing module that dispatches LLM-recommended operations to security tools, neither reference teaches an autonomous, pre-execution determination that the LLM’s generated instructions are invalid, coupled with generation of an explanation of the invalidity and a revision round-trip that returns corrected instructions from the LLM prior to any tool call. Yao’s corrective behavior is reactive to observations returned after an action is executed, not a determination of invalidity made before the tool is called; and the remaining references do not cure this deficiency. Accordingly, the examiner declines to map these limitations to the prior art of record and indicates claims 11 and 16 as containing allowable subject matter.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to the examiner of record.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD A ABDULLAH whose telephone number is (571) 272-1531. The examiner can normally be reached on Monday - Friday, 8:30am - 5:00pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SAAD AHMAD ABDULLAH/Examiner, Art Unit 2431
/SHIN-HON (ERIC) CHEN/Primary Examiner, Art Unit 2431
Prosecution Insights