DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This communication is in response to the application filed on 01/22/2026. Claims 1-19, and 21 are currently pending in the application.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 01/22/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements have been considered by the examiner.
Response to Arguments
Applicant’s arguments with respect to claim 1 have been considered but are moot based on the rejections made below with a new reference that addresses applicant concerns in response to applicant’s amendments.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 6-9, 13-17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. PGPub. No. 20200125732 Iyer et al. (hereinafter Iyer) in view of Pat. No. 11150888 to Beard; Daniel (hereinafter Beard).
Regarding claim 1, Iyer discloses a method for monitoring a computing system (¶0062, “…the analysis module 130 monitors electronic inputs from other processes executing on the processor 110, electronic communications received via a network communication interface, intra-process (i.e., within the integrated development environment (IDE) communications, I/O inputs from machine interface devices connected with the computing device (e.g., keyboard), file system resources, and so on.”) comprising:
determining an observation phase during which execution paths of valid transfers of a
process are observed: (¶0102-¶0103, “…The runtime checks monitor execution of the program to ensure data integrity, program control flow integrity, and fault prevention.”)…the runtime checks may function to ensure the program is not directed outside of the execution paths represented by the graph 170, ensure that data (i.e., variables) is not maliciously modified outside of identified permissible uses/modifications identified from the source code, ensure that conditions that can result in faults do not occur or, if they do occur, ensure the faults are handled without catastrophic failure of the program…”), (claim 7, “… the runtime checks monitor at least execution paths in the program to ensure program flow integrity and prevent the faults identified by the fault tree from occurring.”)
generating observed telemetry data representing the execution paths of the valid transfers;
(¶0063-¶0064, “…the analysis module 130, in one embodiment, also includes instructions to analyze the source code to identify control flow characteristics, safety-related functions, and fault characteristics of the source code…In one embodiment, the control flow characteristics include intra-procedural and/or inter-procedural control flow transfers of the program such as function calls, and return address along with symbolic names, function arguments and return values, along with a calling convention, and so on. More generally, the control flow characteristics relate to aspects that influence the execution of the program resulting in handovers, exits, jumps, etc.”, wherein control flow characteristics, safety-related functions, and fault characteristics of the source code etc. are interpreted as the claimed observed telemetry data), (¶0079, “… upon detecting the noted modification, the analysis module 130 proceeds to identify control flow characteristics at block 720. Of course, while the method 700 is discussed in relation to real-time detection and generation of the graph 170, in further aspects, the analysis module 130 detects an electronic request or other indication at 710 that may be generated when the source code is complete, or at another time and that initiates the analysis of the source code.”).
generating, by a processor and using the observed telemetry data, a control flow directed graph (CFDG) that represents the execution paths of the valid transfers of the process (¶0068, “the graph module 140 includes, in one embodiment, computer-readable instructions that when executed by the processor 110, cause the processor 110 to generate the control flow graph 170 according to the control flow characteristics…”), (¶0084, “the graph module 140 generates the control flow graph 170. In one embodiment, the graph module 140 uses the control flow characteristics identified at 720 in order to form nodes and directed edges of the graph 170. Moreover, in one embodiment, the graph module 140 generates the graph 170 in a piecewise manner as aspects are added to the source code. Furthermore, consider that the control flow graph 170 generally represents execution paths through the program…”), see also ¶0043.
receiving by the processor, an indication of a vulnerability within the process (¶0052, “As shown in the fault tree 400, the or-gate 450 produces an indication of a potential fault/failure at output block 460 if any of the logic 440, 430, or 420 indicate an occurrence of noted conditions…”), (¶0090, “… the analysis module 130 performs fault tree analysis and uses Boolean logic gates with the execution states to represent when the faults occur and which execution paths in the program are hazardous. The conditions include at least execution states of the program derived from inputs to the program and internally produced values of the program that result in the faults…”), see also ¶0055;
modifying the CFDG such that the particular execution path that is associated with the vulnerability is prevented from completing execution (¶0029, “…As will be better understood through the accompanying explanation, the control flow graph generally functions to represent vulnerabilities in relation to program flow and data flow for the program. That is, the control flow graph, in a basic form, is generated to represent which aspects of the program are vulnerable to malicious attacks that attempt to redirect the program, alter data associated with the program, and so on.”), (¶0033, “the fault control system also uses the control flow graph to generate a visual representation of the execution flow of the program and possible faults…”), (¶0058, “…the instrumentation may include security instrumentation to prevent malicious manipulation of the program flow and/or data values that could result in an accident and injury to passengers if the program is manipulated through a malicious attack. As a further example, where one or more known fault conditions exist in the program, the instrumentation redirects the program flow to a safe exit procedure upon detecting the occurrence of the condition.”), (¶0073, “… the instrumentation module 150 adds instrumentation into the source code that provides runtime checks within the program when executing. The runtime checks act as supervisory processes to ensure program flow, data integrity, and to prevent faults/failures arising in the program due to the combination of conditions identified in the fault tree.”), see also ¶0075 and ¶0103;
executing, at runtime the process and using the CFDG to prevent execution the particular execution path associated with the vulnerability (¶0005, “a fault control system that integrates fault trees and control flow graphs to ensure both functional safety and program flow integrity of various paths in the program is disclosed. Moreover, the fault control system, in one embodiment, uses the integrated control flow graph to provide additional functionality such as the automatic instrumentation of source code of the program with runtime checks that validate program flow and avoid fault conditions identified in the fault tree.”), (¶0075, “…the instrumentation included by the instrumentation module 150 is to enforce runtime checks within the program by ensuring execution of the program follows the control flow graph 170, ensuring the integrity of particular data arguments, and/or monitoring the conditions associated with the fault tree to prevent the faults. Thus, the instrumentation module 150 generally uses the knowledge conveyed via the graph 170 in order to know how to include instrumentation within the source code. Thus, the instrumentation module 150, in one embodiment, includes instrumentation to perform address checks (e.g., memory addresses for data and program flow), variable/function return type checks, data-bound checks, opcode checks, match call-return pairs (non-single class), and so on.”), (¶0103, “the runtime checks may function to ensure the program is not directed outside of the execution paths represented by the graph 170, ensure that data (i.e., variables) is not maliciously modified outside of identified permissible uses/modifications identified from the source code, ensure that conditions that can result in faults do not occur or, if they do occur, ensure the faults are handled without catastrophic failure of the program. In one approach, the instrumentation implements the runtime checks to catch the faults and thereby redirect the program to a failover routine where the program can recover or handover control to a backup process that prevents injury or damage to the associated device”).
However, Iyer does not explicitly disclose the following limitations:
receiving a software bill of materials (SBOM) for the process;
determining, by the processor, and using the SBOM, a particular execution path of the execution paths represented in the CFDG associated with the vulnerability;
Beard discloses:
receiving a software bill of materials (SBOM) for the process (abstract, “Each of a plurality of medical devices is configured to generate a device specific Software Bill of Materials (SBOM), and communicate the device specific SBOM to a validator system(s)…”,), (Col. 3, lines 37-60, “device instructions may be configured to cause a device processor to communicate a device specific SBOM to at least one of a plurality of validator systems. The device specific SBOM may be communicated to a specific destination such as at least one central authority system and/or at least one validator system. A validator system and a medical device may share at least one hardware component…”);
determining, by the processor, and using the SBOM, a particular execution path of the execution paths represented in the CFDG associated with the vulnerability (Col. 4, lines 17-67 to Col. 5, lines 1-27, “…The validator instructions may be configured to cause the validator processor to validate at least one update in the device specific SBOM based on a vulnerability database. The new block may comprise device specific SBOM changes communicated from at least one medical device. The validator instructions may be configured to cause the validator processor to validate at least one update in the device specific SBOM in response to the device specific SBOM not being completely contained in the SBOM hash tree. A request for validation may be communicated to a central authority system. New entries may be added to the vulnerability database in response to at least one of the at least one update in the device specific SBOM not being contained in the vulnerability database. The validator instructions may be configured to cause the validator processor to communicate the new block to at least one other validator system in the plurality of validator systems in response to the new block being added to the SBOM blockchain. The validator instructions may be configured to cause the validator processor to generate a SBOM score. The SBOM score may be based on the device specific SBOM and the vulnerability database. The validator instructions may be configured to cause the validator processor to add the SBOM score to the new block.”, wherein the SBOM hash tree built on data in a SBOM blockchain is interpreted as determining a control flow graph using SBOM and the built SBOM hash tree is the claimed CFDG).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Iyer to include determination of CFDG (SBOM hash) associated with vulnerability using of software bill of materials (SBOM) as disclosed by Beard and be motivated in doing so in order generate a score for the SBOM based on the vulnerability-Beard Col. 4, lines 58-67 to Col. 5 lines 1-27 in parts.
Regarding claim 2, Iyer in view of Beard discloses the method of claim 1.
Iyer further discloses wherein the vulnerability is received
via a cloud-based system (¶0039, “… the fault control system 100 may be embodied as a cloud-computing system, a cluster-computing system, a distributed computing system, a software-as-a-service (SaaS) system, and so on…”).
Regarding claim 3, Iyer in view of Beard discloses the method of claim 1.
Beard further discloses wherein the SBOM is received from a cloud-based resource of a provider of the process (Col. 4, lines 17-57, “…The original SBOM may be based on a specific medical device type. The original SBOM may be provided with the medical device by a medical device manufacturer. The original SBOM may be the first SBOM generated once a specific medical device is put into operation…”), (Col. 12, lines 24-54, “…a medical device may be a user-based client, portable equipment, broadcast equipment, virtual, application(s) distributed over a broad combination of computing devices, part of a cloud, and/or the like…”)
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Iyer and Beard to include receiving the SBOM from a cloud-based resource of a provider as disclosed by BEARD and be motivated in doing so in order to ensure real-time visibility and automated vulnerability tracking which improves security of the process.
Regarding claim 4, Iyer in view of Beard discloses the method of claim 1.
Iyer further discloses wherein determining the particular execution path comprises running a vulnerability scanner on an image of the process (¶0029, “… the control flow graph, in a basic form, is generated to represent which aspects of the program are vulnerable to malicious attacks that attempt to redirect the program, alter data associated with the program, and so on.”), (¶0083, “the analysis module 130, in one embodiment, further identifies which statements of the source code include vulnerabilities by comparing the control flow characteristics with the graph policy 180. In one embodiment, the graph policy 180 defines conditions indicative of security vulnerabilities and performance bottlenecks. Accordingly, the additional information about vulnerabilities and bottlenecks can also be included within the control flow characteristics such that the information is subsequently integrated with the graph 170 to provide further indications about characteristics of different portions of the source code…”), (¶0091, “the analysis module 130, in one embodiment, further identifies which statements of the source code are associated with vulnerabilities that lead to the faults by comparing aspects of the graph policy 180 that are indicative of the faults with the statements in the source code. In one embodiment, the graph policy 180 defines conditions indicative of the faults. In an alternative embodiment, the analysis module 130 implements software fault tree analysis (FTA) as may be appreciated in the art…”).
Regarding claim 6, Iyer in view of Beard discloses the method of claim 1.
Iyer further discloses wherein modifying the CFDG comprises excluding one or more nodes of the CFDG based on removing the particular execution path associated with the nodes from the CFDG (¶0071, “the graph module 140, in one embodiment, further includes instructions to electronically provide the control flow graph 170 to facilitate adjustments in the source code such as inclusion of instrumentation. The graph 170 represents possible execution paths and associated conditions related to the execution. Accordingly, the graph 170 provides insights into potential errors within the source code (e.g., infinite loops, exposed functions, unsecured data, faults, etc.) that can be leveraged by various modules and systems to improve the source code in order to avoid difficulties (e.g., security holes, program faults, etc.) in the program once compiled.”, wherein avoiding security holes which is understood as unintended, illegal, or unsafe execution paths (edges) between code blocks (nodes) that allow a program to deviate from its designed behavior is interpreted as excluding the nodes of the control flow graph), (¶0103, “…the instrumentation implements the runtime checks to catch the faults and thereby redirect the program to a failover routine where the program can recover or handover control to a backup process that prevents injury or damage to the associated device…”)
Regarding claim 7, Iyer in view of Beard discloses the method of claim 1.
Iyer further discloses wherein determining the CFDG is based on the valid transfer of the process during the observation phase and SBOM interpolation (¶0045, “…The directed edges, in one embodiment, indicate intra-procedural and/or inter-procedural control flow transfers between the blocks/segments. That is, the edges represent handovers, function calls, concrete and/or symbolic function arguments, and so on. In general, the directed edges illustrate transfers in the execution of the program between the separate blocks…”), (¶0048, “…the segments/blocks that comprise the nodes and conditions that define the directed edges and annotations of the fault tree integrated therewith are specified according to a graph policy. The graph policy 180 defines templates, example segments, and/or metrics for identifying the blocks/segments, conditions, transitions, and so on. As a general matter, the graph policy 180 is defined, for example, with various rules that are based on the characteristics associated with faults, intra-procedural and/or inter-procedural control flow, data arguments, and so on such that the analysis module 130 can identify the various aspects when parsing the source code. Moreover, the graph policy 180, in one approach, further defines how the fault tree derived from the safety-related function(s) is integrated with the graph 170 (e.g., which portions are annotated and with what information), (¶0077, “the instrumentation module 150 analyzes the source code and the control flow graph 170 to integrate instrumentation within the source code. In particular, the instrumentation module 150 identifies segments of the source code that are to be instrumented according to correlations between the control flow graph 170 and the source code such as procedural transitions within the source code as identified by directed edges in the graph 170, locations where a data argument is used/modified as identified in the graph 170, hazardous paths where particular conditions generate faults, and so on…”), Beard discloses SBOM interpolation in Col. 2, lines 28-35, “the SBOM blockchain may be employed to validate updates to a device specific SBOM for each of a plurality of medical devices. In this disclosure, updates to a device specific SBOM may include: installation of additional software, installation of additional hardware, removal of installed software, removal of installed hardware, combinations thereof, and/or the like.”, wherein SBOM interpolation (enrichment or augmentation) is understood as filling in of missing information, enhancing, or correcting a SBOM after its initial generation).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Iyer and Beard to include software bill of materials (SBOM) interpolation as disclosed by beard and be motivated in doing so in order to enhance the accuracy, completeness, and actionability of the SBOM by filling the missing information or correcting the errors.
Regarding claims 8, Iyer discloses a system comprising:
one or more processors (FIG. 1, “processors 110”); and
one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising (¶0013, “a non-transitory computer-readable medium is disclosed. The computer-readable medium stores instructions that when executed by one or more processors cause the one or more processors to perform the disclosed functions…”):
determining an observation phase during which execution paths of valid transfers of a
process are observed: (¶0102-¶0103, “…The runtime checks monitor execution of the program to ensure data integrity, program control flow integrity, and fault prevention.”)…the runtime checks may function to ensure the program is not directed outside of the execution paths represented by the graph 170, ensure that data (i.e., variables) is not maliciously modified outside of identified permissible uses/modifications identified from the source code, ensure that conditions that can result in faults do not occur or, if they do occur, ensure the faults are handled without catastrophic failure of the program…”), (claim 7, “… the runtime checks monitor at least execution paths in the program to ensure program flow integrity and prevent the faults identified by the fault tree from occurring.”)
generating observed telemetry data representing the execution paths of the valid transfers;
(¶0063-¶0064, “…the analysis module 130, in one embodiment, also includes instructions to analyze the source code to identify control flow characteristics, safety-related functions, and fault characteristics of the source code…In one embodiment, the control flow characteristics include intra-procedural and/or inter-procedural control flow transfers of the program such as function calls, and return address along with symbolic names, function arguments and return values, along with a calling convention, and so on. More generally, the control flow characteristics relate to aspects that influence the execution of the program resulting in handovers, exits, jumps, etc.”, wherein control flow characteristics, safety-related functions, and fault characteristics of the source code etc. are interpreted as the claimed observed telemetry data), (¶0079, “… upon detecting the noted modification, the analysis module 130 proceeds to identify control flow characteristics at block 720. Of course, while the method 700 is discussed in relation to real-time detection and generation of the graph 170, in further aspects, the analysis module 130 detects an electronic request or other indication at 710 that may be generated when the source code is complete, or at another time and that initiates the analysis of the source code.”).
determining, using the observed telemetry data, a control flow directed graph (CFDG) for process executed on the system (¶0068, “the graph module 140 includes, in one embodiment, computer-readable instructions that when executed by the processor 110, cause the processor 110 to generate the control flow graph 170 according to the control flow characteristics…”), (¶0084, “the graph module 140 generates the control flow graph 170. In one embodiment, the graph module 140 uses the control flow characteristics identified at 720 in order to form nodes and directed edges of the graph 170. Moreover, in one embodiment, the graph module 140 generates the graph 170 in a piecewise manner as aspects are added to the source code. Furthermore, consider that the control flow graph 170 generally represents execution paths through the program…”), see also ¶0043.
determining a vulnerability within the process, the vulnerability corresponding to a zero-day or a code reuse vulnerability (¶0029, “…the control flow graph generally functions to represent vulnerabilities in relation to program flow and data flow for the program. That is, the control flow graph, in a basic form, is generated to represent which aspects of the program are vulnerable to malicious attacks that attempt to redirect the program, alter data associated with the program, and so on.”, wherein redirecting a program execution flow by an attacker is a core component of code reuse vulnerabilities);
modifying the CFDG based on removing or marking a node associated with the particular execution path from the CFDG, wherein marking the node prevents execution of the particular execution path (¶0031, “the fault control system, in one embodiment, integrates the fault tree into the control flow graph in order to further identify important aspects (e.g., hazardous paths) of the program using a single representation. In one aspect, the fault control system integrates the fault tree by annotating nodes/edges of the control flow graph with the conditions identified by the fault tree. Thus, various blocks of the source code that are associated with the conditions identified by the fault tree are annotated in the control flow graph to further identify the hazardous paths in the control flow graph for which certain conditions may result in faults/errors.”), (¶0058, “…the instrumentation may include security instrumentation to prevent malicious manipulation of the program flow and/or data values that could result in an accident and injury to passengers if the program is manipulated through a malicious attack. As a further example, where one or more known fault conditions exist in the program, the instrumentation redirects the program flow to a safe exit procedure upon detecting the occurrence of the condition.”), (¶0073, “… the instrumentation module 150 adds instrumentation into the source code that provides runtime checks within the program when executing. The runtime checks act as supervisory processes to ensure program flow, data integrity, and to prevent faults/failures arising in the program due to the combination of conditions identified in the fault tree.”), see also ¶0010, ¶0092 and ¶0103;
executing, the process and using CFDG to prevent execution the particular execution path associated with the vulnerability (¶0005, “a fault control system that integrates fault trees and control flow graphs to ensure both functional safety and program flow integrity of various paths in the program is disclosed. Moreover, the fault control system, in one embodiment, uses the integrated control flow graph to provide additional functionality such as the automatic instrumentation of source code of the program with runtime checks that validate program flow and avoid fault conditions identified in the fault tree.”), (¶0075, “…the instrumentation included by the instrumentation module 150 is to enforce runtime checks within the program by ensuring execution of the program follows the control flow graph 170, ensuring the integrity of particular data arguments, and/or monitoring the conditions associated with the fault tree to prevent the faults. Thus, the instrumentation module 150 generally uses the knowledge conveyed via the graph 170 in order to know how to include instrumentation within the source code. Thus, the instrumentation module 150, in one embodiment, includes instrumentation to perform address checks (e.g., memory addresses for data and program flow), variable/function return type checks, data-bound checks, opcode checks, match call-return pairs (non-single class), and so on.”), (¶0103, “the runtime checks may function to ensure the program is not directed outside of the execution paths represented by the graph 170, ensure that data (i.e., variables) is not maliciously modified outside of identified permissible uses/modifications identified from the source code, ensure that conditions that can result in faults do not occur or, if they do occur, ensure the faults are handled without catastrophic failure of the program. In one approach, the instrumentation implements the runtime checks to catch the faults and thereby redirect the program to a failover routine where the program can recover or handover control to a backup process that prevents injury or damage to the associated device”).
However, Iyer does not explicitly disclose the following limitations:
receiving a software bill of materials (SBOM) for the process;
determining, by the processor, and using the SBOM, a particular execution path of the execution paths represented in the CFDG associated with the vulnerability;
Beard discloses:
receiving a software bill of materials (SBOM) for the process (abstract, “Each of a plurality of medical devices is configured to generate a device specific Software Bill of Materials (SBOM), and communicate the device specific SBOM to a validator system(s)…”,), (Col. 3, lines 37-60, “device instructions may be configured to cause a device processor to communicate a device specific SBOM to at least one of a plurality of validator systems. The device specific SBOM may be communicated to a specific destination such as at least one central authority system and/or at least one validator system. A validator system and a medical device may share at least one hardware component…”);
determining, using the SBOM, a particular execution path of the execution paths represented in the CFDG associated with the vulnerability (Col. 4, lines 17-67 to Col. 5, lines 1-27, “…The validator instructions may be configured to cause the validator processor to validate at least one update in the device specific SBOM based on a vulnerability database. The new block may comprise device specific SBOM changes communicated from at least one medical device. The validator instructions may be configured to cause the validator processor to validate at least one update in the device specific SBOM in response to the device specific SBOM not being completely contained in the SBOM hash tree. A request for validation may be communicated to a central authority system. New entries may be added to the vulnerability database in response to at least one of the at least one update in the device specific SBOM not being contained in the vulnerability database. The validator instructions may be configured to cause the validator processor to communicate the new block to at least one other validator system in the plurality of validator systems in response to the new block being added to the SBOM blockchain. The validator instructions may be configured to cause the validator processor to generate a SBOM score. The SBOM score may be based on the device specific SBOM and the vulnerability database. The validator instructions may be configured to cause the validator processor to add the SBOM score to the new block.”, wherein the SBOM hash tree built on data in a SBOM blockchain is interpreted as determining a control flow graph using SBOM and the built SBOM hash tree is the claimed CFDG).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Iyer to include determination of CFDG (SBOM hash) associated with vulnerability using of software bill of materials (SBOM) as disclosed by Beard and be motivated in doing so in order generate a score for the SBOM based on the vulnerability-Beard Col. 4, lines 58-67 to Col. 5 lines 1-27 in parts.
Regarding claims 9, Iyer in view of Beard discloses the system of claim 8.
Iyer further discloses wherein the vulnerability is based at least in part on a publicly identified vulnerability in the process (¶0039, “… the fault control system 100 may be embodied as a cloud-computing system, a cluster-computing system, a distributed computing system, a software-as-a-service (SaaS) system, and so on…”).
Regarding claims 13, Iyer in view of Beard discloses the system of claim 8.
Iyer further discloses wherein determining the CFDG is based on the valid transfer of the process during the observation phase and SBOM interpolation (¶0045, “…The directed edges, in one embodiment, indicate intra-procedural and/or inter-procedural control flow transfers between the blocks/segments. That is, the edges represent handovers, function calls, concrete and/or symbolic function arguments, and so on. In general, the directed edges illustrate transfers in the execution of the program between the separate blocks…”), (¶0048, “…the segments/blocks that comprise the nodes and conditions that define the directed edges and annotations of the fault tree integrated therewith are specified according to a graph policy. The graph policy 180 defines templates, example segments, and/or metrics for identifying the blocks/segments, conditions, transitions, and so on. As a general matter, the graph policy 180 is defined, for example, with various rules that are based on the characteristics associated with faults, intra-procedural and/or inter-procedural control flow, data arguments, and so on such that the analysis module 130 can identify the various aspects when parsing the source code. Moreover, the graph policy 180, in one approach, further defines how the fault tree derived from the safety-related function(s) is integrated with the graph 170 (e.g., which portions are annotated and with what information), (¶0077, “the instrumentation module 150 analyzes the source code and the control flow graph 170 to integrate instrumentation within the source code. In particular, the instrumentation module 150 identifies segments of the source code that are to be instrumented according to correlations between the control flow graph 170 and the source code such as procedural transitions within the source code as identified by directed edges in the graph 170, locations where a data argument is used/modified as identified in the graph 170, hazardous paths where particular conditions generate faults, and so on…”), Beard discloses SBOM interpolation in Col. 2, lines 28-35, “the SBOM blockchain may be employed to validate updates to a device specific SBOM for each of a plurality of medical devices. In this disclosure, updates to a device specific SBOM may include: installation of additional software, installation of additional hardware, removal of installed software, removal of installed hardware, combinations thereof, and/or the like.”, wherein SBOM interpolation (enrichment or augmentation) is understood as filling in of missing information, enhancing, or correcting a SBOM after its initial generation).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Iyer and Beard to include software bill of materials (SBOM) interpolation as disclosed by beard and be motivated in doing so in order to enhance the accuracy, completeness, and actionability of the SBOM by filling the missing information or correcting the errors.
Regarding claims 14, Iyer in view of Beard discloses the system of claim 8.
Iyer further discloses wherein determining the particular execution path of the process comprises running a vulnerability scanner on an image of the process (¶0029, “… the control flow graph, in a basic form, is generated to represent which aspects of the program are vulnerable to malicious attacks that attempt to redirect the program, alter data associated with the program, and so on.”), (¶0083, “the analysis module 130, in one embodiment, further identifies which statements of the source code include vulnerabilities by comparing the control flow characteristics with the graph policy 180. In one embodiment, the graph policy 180 defines conditions indicative of security vulnerabilities and performance bottlenecks. Accordingly, the additional information about vulnerabilities and bottlenecks can also be included within the control flow characteristics such that the information is subsequently integrated with the graph 170 to provide further indications about characteristics of different portions of the source code…”), (¶0091, “the analysis module 130, in one embodiment, further identifies which statements of the source code are associated with vulnerabilities that lead to the faults by comparing aspects of the graph policy 180 that are indicative of the faults with the statements in the source code. In one embodiment, the graph policy 180 defines conditions indicative of the faults. In an alternative embodiment, the analysis module 130 implements software fault tree analysis (FTA) as may be appreciated in the art…”).
Regarding claim 15, Iyer discloses one or more non-transitory computer readable media storing computer readable instructions that, when executed by one or more processors, cause the one or more processors to (¶0013, “a non-transitory computer-readable medium is disclosed. The computer-readable medium stores instructions that when executed by one or more processors cause the one or more processors to perform the disclosed functions…”):
determine an observation phase during which execution paths of valid transfers of a
process are observed: (¶0102-¶0103, “…The runtime checks monitor execution of the program to ensure data integrity, program control flow integrity, and fault prevention.”)…the runtime checks may function to ensure the program is not directed outside of the execution paths represented by the graph 170, ensure that data (i.e., variables) is not maliciously modified outside of identified permissible uses/modifications identified from the source code, ensure that conditions that can result in faults do not occur or, if they do occur, ensure the faults are handled without catastrophic failure of the program…”), (claim 7, “… the runtime checks monitor at least execution paths in the program to ensure program flow integrity and prevent the faults identified by the fault tree from occurring.”)
generate observed telemetry data representing the execution paths of the valid transfers;
(¶0063-¶0064, “…the analysis module 130, in one embodiment, also includes instructions to analyze the source code to identify control flow characteristics, safety-related functions, and fault characteristics of the source code…In one embodiment, the control flow characteristics include intra-procedural and/or inter-procedural control flow transfers of the program such as function calls, and return address along with symbolic names, function arguments and return values, along with a calling convention, and so on. More generally, the control flow characteristics relate to aspects that influence the execution of the program resulting in handovers, exits, jumps, etc.”, wherein control flow characteristics, safety-related functions, and fault characteristics of the source code etc. are interpreted as the claimed observed telemetry data), (¶0079, “… upon detecting the noted modification, the analysis module 130 proceeds to identify control flow characteristics at block 720. Of course, while the method 700 is discussed in relation to real-time detection and generation of the graph 170, in further aspects, the analysis module 130 detects an electronic request or other indication at 710 that may be generated when the source code is complete, or at another time and that initiates the analysis of the source code.”).
determine, using the observed telemetry data, a control flow directed graph (CFDG) for process executed on the system (¶0068, “the graph module 140 includes, in one embodiment, computer-readable instructions that when executed by the processor 110, cause the processor 110 to generate the control flow graph 170 according to the control flow characteristics…”), (¶0084, “the graph module 140 generates the control flow graph 170. In one embodiment, the graph module 140 uses the control flow characteristics identified at 720 in order to form nodes and directed edges of the graph 170. Moreover, in one embodiment, the graph module 140 generates the graph 170 in a piecewise manner as aspects are added to the source code. Furthermore, consider that the control flow graph 170 generally represents execution paths through the program…”), see also ¶0043.
determine a vulnerability within the process, the vulnerability corresponding to a zero-day attack or a code reuse attack (¶0029, “…the control flow graph generally functions to represent vulnerabilities in relation to program flow and data flow for the program. That is, the control flow graph, in a basic form, is generated to represent which aspects of the program are vulnerable to malicious attacks that attempt to redirect the program, alter data associated with the program, and so on.”, wherein redirecting a program execution flow by an attacker is a core component of code reuse vulnerabilities);
modifying the CFDG that excludes the particular execution path (¶0071, “the graph module 140, in one embodiment, further includes instructions to electronically provide the control flow graph 170 to facilitate adjustments in the source code such as inclusion of instrumentation. The graph 170 represents possible execution paths and associated conditions related to the execution. Accordingly, the graph 170 provides insights into potential errors within the source code (e.g., infinite loops, exposed functions, unsecured data, faults, etc.) that can be leveraged by various modules and systems to improve the source code in order to avoid difficulties (e.g., security holes, program faults, etc.) in the program once compiled.”, wherein avoiding security holes which is understood as unintended, illegal, or unsafe execution paths (edges) between code blocks (nodes) that allow a program to deviate from its designed behavior is interpreted as excluding the particular execution path), (¶0103, “…the instrumentation implements the runtime checks to catch the faults and thereby redirect the program to a failover routine where the program can recover or handover control to a backup process that prevents injury or damage to the associated device…”);
execute the process and using the CFDG to prevent execution the particular execution path associated with the vulnerability (¶0005, “a fault control system that integrates fault trees and control flow graphs to ensure both functional safety and program flow integrity of various paths in the program is disclosed. Moreover, the fault control system, in one embodiment, uses the integrated control flow graph to provide additional functionality such as the automatic instrumentation of source code of the program with runtime checks that validate program flow and avoid fault conditions identified in the fault tree.”), (¶0075, “…the instrumentation included by the instrumentation module 150 is to enforce runtime checks within the program by ensuring execution of the program follows the control flow graph 170, ensuring the integrity of particular data arguments, and/or monitoring the conditions associated with the fault tree to prevent the faults. Thus, the instrumentation module 150 generally uses the knowledge conveyed via the graph 170 in order to know how to include instrumentation within the source code. Thus, the instrumentation module 150, in one embodiment, includes instrumentation to perform address checks (e.g., memory addresses for data and program flow), variable/function return type checks, data-bound checks, opcode checks, match call-return pairs (non-single class), and so on.”), (¶0103, “the runtime checks may function to ensure the program is not directed outside of the execution paths represented by the graph 170, ensure that data (i.e., variables) is not maliciously modified outside of identified permissible uses/modifications identified from the source code, ensure that conditions that can result in faults do not occur or, if they do occur, ensure the faults are handled without catastrophic failure of the program. In one approach, the instrumentation implements the runtime checks to catch the faults and thereby redirect the program to a failover routine where the program can recover or handover control to a backup process that prevents injury or damage to the associated device”).
However, Iyer does not explicitly disclose the following limitations:
receiving a software bill of materials (SBOM) for the process;
determine, using the SBOM a particular execution path of the execution paths represented in the CFDG associated with the vulnerability;
modifying the CFDG to generate a revised SBOM that excludes the particular execution path;
Beard discloses:
receiving a software bill of materials (SBOM) for the process (abstract, “Each of a plurality of medical devices is configured to generate a device specific Software Bill of Materials (SBOM), and communicate the device specific SBOM to a validator system(s)…”,), (Col. 3, lines 37-60, “device instructions may be configured to cause a device processor to communicate a device specific SBOM to at least one of a plurality of validator systems. The device specific SBOM may be communicated to a specific destination such as at least one central authority system and/or at least one validator system. A validator system and a medical device may share at least one hardware component…”);
determining, using the SBOM, a particular execution path of the execution paths represented in the CFDG associated with the vulnerability (Col. 4, lines 17-67 to Col. 5, lines 1-27, “…The validator instructions may be configured to cause the validator processor to validate at least one update in the device specific SBOM based on a vulnerability database. The new block may comprise device specific SBOM changes communicated from at least one medical device. The validator instructions may be configured to cause the validator processor to validate at least one update in the device specific SBOM in response to the device specific SBOM not being completely contained in the SBOM hash tree. A request for validation may be communicated to a central authority system. New entries may be added to the vulnerability database in response to at least one of the at least one update in the device specific SBOM not being contained in the vulnerability database. The validator instructions may be configured to cause the validator processor to communicate the new block to at least one other validator system in the plurality of validator systems in response to the new block being added to the SBOM blockchain. The validator instructions may be configured to cause the validator processor to generate a SBOM score. The SBOM score may be based on the device specific SBOM and the vulnerability database. The validator instructions may be configured to cause the validator processor to add the SBOM score to the new block.”, wherein the SBOM hash tree built on data in a SBOM blockchain is interpreted as determining a control flow graph using SBOM and the built SBOM hash tree is the claimed CFDG).
modifying the CFDG to generate a revised SBOM (Col. 4, lines 17-57, “…The SBOM hash tree may be based on data in the SBOM blockchain. The SBOM hash tree may comprise a root node with an original SBOM. The original SBOM may be based on a specific medical device type. The original SBOM may be provided with the medical device by a medical device manufacturer. The original SBOM may be the first SBOM generated once a specific medical device is put into operation. The root node may comprise SBOM data that is empty (NUL). The SBOM hash tree may comprise at least one leaf node. Each of the at least one leaf node may comprise a distinct SBOM update. The distinct SBOM update may comprise at least one update in a device specific SBOM. The distinct SBOM update may comprise at least one update from the original SBOM in the root node plus all of the previous distinct SBOM updates of the parent leaf nodes. In the case where the leaf node is directly connected to the root node, the distinct SBOM update may comprise at least one update from the original SBOM in the root node. Therefore, a device specific SBOM may be equivalent to a combination of the original SBOM and all of the distinct SBOM updates in all of the parent leaf nodes. In the case where the SBOM data in the root node is empty, each of the leaf nodes directly connected to the root node may comprise a distinct SBOM update that is equivalent to a device specific SBOM communicated from a medical device.”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Iyer to include determination of CFDG (SBOM hash) associated with vulnerability using of software bill of materials (SBOM) as disclosed by Beard and be motivated in doing so in order generate a score for the SBOM based on the vulnerability-Beard Col. 4, lines 58-67 to Col. 5 lines 1-27 in parts.
Regarding claim 16, Iyer in view of Beard discloses the one or more non-transitory computer-readable media of claim 15.
Iyer further discloses wherein the vulnerability is determined on an observed deviation from the control flow directed graph (CFDG) (¶0029, “…the control flow graph generally functions to represent vulnerabilities in relation to program flow and data flow for the program. That is, the control flow graph, in a basic form, is generated to represent which aspects of the program are vulnerable to malicious attacks that attempt to redirect the program, alter data associated with the program, and so on.”), (¶0091, “the analysis module 130, in one embodiment, further identifies which statements of the source code are associated with vulnerabilities that lead to the faults by comparing aspects of the graph policy 180 that are indicative of the faults with the statements in the source code…”).
Regarding claim 17, Iyer in view of Beard discloses the one or more non-transitory computer-readable media of claim 15.
Iyer further discloses wherein the vulnerability is determined based at least in part on a publicly identified vulnerability in the process (¶0039, “… the fault control system 100 may be embodied as a cloud-computing system, a cluster-computing system, a distributed computing system, a software-as-a-service (SaaS) system, and so on…”).
Regarding claim 19, Iyer in view of Beard discloses the one or more non-transitory computer-readable media of claim 15.
Iyer further discloses wherein executing the process and using the CFDG occurs at runtime (¶0005, “… the fault control system, in one embodiment, uses the integrated control flow graph to provide additional functionality such as the automatic instrumentation of source code of the program with runtime checks that validate program flow and avoid fault conditions identified in the fault tree.”), (¶0026, “…Thus, the fault control system, in one embodiment, uses the enhanced control flow graph to automatically instrument the program thereby automatically accounting for runtime checks that validate program/data flow and avoid fault conditions to ensure compliance with functional safety standards.”).
Claims 5, 10-12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. PGPub. No. 20200125732 Iyer et al. (hereinafter Iyer) in view of Pat. No. 11150888 to Beard; Daniel (hereinafter Beard) and further in view of U.S. PGPub. No 20230367882 to BUSSELL et al. (hereinafter BUSSELL).
Regarding claim 5, Iyer in view of Beard discloses the method of claim 1.
However, Iyer in view of Beard does not explicitly disclose the limitation of:
wherein determining the particular execution path comprises mapping SBOM metadata associated with the particular execution path to a binary image of the process;
BUSSELL discloses wherein determining the particular execution path comprises mapping SBOM metadata associated with the particular execution path to a binary image of the process (¶0091, “the evidence 380 also includes information about which libraries, objects, and symbols were selected for inclusion into a final binary based on use of private debug symbols generated during compilation. Then, based on knowledge of how the objects were produced, the chunk SBOM generator 350 and/or a build SBOM generator 360 (discussed below) can determine which source files were needed to build objects that were actually used by the final binary (e.g., as being statically or dynamically linked into the binary), (¶0088, “the disclosed systems are configured to export this information as computer-parsable structured metadata, such as with a preprocessor…”). See also FIGs 8 and 9.
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Iyer and Beard to include mapping SBOM metadata associated with the particular execution path as disclosed by BUSSELL and be motivated in doing so in order that the computing system 300 will automatically determine that a region of interest within the code resource 370 has been entirely excluded prior to reaching the compiler-BUSSELL ¶0088 in parts.
Regarding claim 10, Iyer in view of Beard discloses the system of claim 8.
However, Iyer in view of Beard does not explicitly disclose further comprising determining the SBOM using a code analyzing tool to generate the SBOM from a binary image of the process
BUSSELL discloses further comprising determining the SBOM using a code analyzing tool to generate the SBOM from a binary image of the process (¶0091, “the evidence 380 also includes information about which libraries, objects, and symbols were selected for inclusion into a final binary based on use of private debug symbols generated during compilation. Then, based on knowledge of how the objects were produced, the chunk SBOM generator 350 and/or a build SBOM generator 360 (discussed below) can determine which source files were needed to build objects that were actually used by the final binary (e.g., as being statically or dynamically linked into the binary)”), (¶0103, “…These segments are identified by a machine learning module or parsing engine (not shown) and which may be incorporated into the build SBOM generator…”), (¶0054, “… the scope of the invention is directed more broadly to embodiments for creating, modifying and utilizing SBOMs, regardless of the standard and formats used by those SBOMs. And, even more broadly, the disclosed embodiments include various systems and method for facilitating the creation, modification and use of SBOMs that have (i) different file declarations that identify different files or code segments that are included in a program, as well as attributes and characteristics of those files/code segments, as well as (ii) dependency declarations that identify one or more related files or code segments that are relied upon by files in the program or that are incorporated into functionality of the files of the program corresponding to the SBOM, regardless of the particular format and standard used to make the declarations.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Iyer and Beard to include code analyzing tool to generate the SBOM as disclosed by BUSSELL and be motivated in doing so in order to facilitate the creation, modification and use of SBOMs that have different file declarations that identify different files or code segments that are included in a program, as well as attributes and characteristics of those files/code segments-BUSSELL ¶0054 in parts.
Regarding claim 11, Iyer in view of Beard discloses the system of claim 8.
However, Iyer in view of Beard does not explicitly disclose the limitation of: wherein modifying the CFDG comprises generating a revised SBOM that excludes the particular execution path.
BUSSELL discloses wherein modifying the CFDG comprises generating a revised SBOM that excludes the particular execution path (¶0088, “In such embodiments, the program performing that phase may be enhanced to export computer-parsable structured metadata indicating that the function was entirely excluded for a generated file (or alternatively, exhaustively list all remaining functions)”), (¶0085, “… the evidence 380 may indicate that a function defined in the code resource 370 was not used in a final binary (e.g., build 334 and/or the media build 336), even if that function was included in an object file or static library, or was excluded by the preprocessor”), (¶0090, “… and the chunk SBOM generator 350 and/or a build SBOM generator 360 (discussed below) can determine that a corresponding region of interest (e.g., function) may be excluded from an SBOM, based on optimization information included in evidence 380 that includes data on functions included and/or excluded for a generated file”).
Thus, one of ordinary skill in the art would have found it obvious before the effective
filing date of applicant’s claimed invention to modify the system of Iyer and Beard to include excluding the code portion to generate a revised SBOM as disclosed by BUSSELL and be motivated in doing so in order to facilitate risk assessment and threat mitigation for corresponding programs, and particularly for large programming builds-BUSSELL abstract in parts.
Regarding claim 12, Iyer in view of Beard discloses the system of claim 8.
However, Iyer in view of Beard does not explicitly disclose the limitation of:
wherein determining the particular execution path of the process comprises mapping SBOM metadata associated with the particular execution path to a binary image of the process
BUSSELL discloses wherein determining the particular execution path of the process comprises mapping SBOM metadata associated with the particular execution path to a binary image of the process (¶0091, “the evidence 380 also includes information about which libraries, objects, and symbols were selected for inclusion into a final binary based on use of private debug symbols generated during compilation. Then, based on knowledge of how the objects were produced, the chunk SBOM generator 350 and/or a build SBOM generator 360 (discussed below) can determine which source files were needed to build objects that were actually used by the final binary (e.g., as being statically or dynamically linked into the binary), (¶0088, “the disclosed systems are configured to export this information as computer-parsable structured metadata, such as with a preprocessor…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Iyer and Beard to include mapping SBOM metadata associated with the particular execution path as disclosed by BUSSELL and be motivated in doing so in order that the computing system 300 will automatically determine that a region of interest within the code resource 370 has been entirely excluded prior to reaching the compiler-BUSSELL ¶0088 in parts.
Regarding claim 18, Iyer in view of Beard discloses the one or more non transitory computer-readable media of claim 15.
However, Iyer in view of Beard does not explicitly disclose the limitation of:
wherein determining the particular execution path of the process comprises mapping SBOM metadata associated with the particular execution path to a binary image of the process
BUSSELL discloses wherein determining the particular execution path of the process comprises mapping SBOM metadata associated with the particular execution path to a binary image of the process (¶0091, “the evidence 380 also includes information about which libraries, objects, and symbols were selected for inclusion into a final binary based on use of private debug symbols generated during compilation. Then, based on knowledge of how the objects were produced, the chunk SBOM generator 350 and/or a build SBOM generator 360 (discussed below) can determine which source files were needed to build objects that were actually used by the final binary (e.g., as being statically or dynamically linked into the binary), (¶0088, “the disclosed systems are configured to export this information as computer-parsable structured metadata, such as with a preprocessor…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the computer-readable media of Iyer and Beard to include mapping SBOM metadata associated with the particular execution path as disclosed by BUSSELL and be motivated in doing so in order that the computing system 300 will automatically determine that a region of interest within the code resource 370 has been entirely excluded prior to reaching the compiler-BUSSELL ¶0088 in parts.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. PGPub. No. 20200125732 Iyer et al. (hereinafter Iyer) in view of Pat. No. 11150888 to Beard; Daniel (hereinafter Beard) and further in view of U.S. PGPub. No. 20170212829 to Bales et al. (hereinafter Bales)
Regarding claim 21, Iyer in view of Beard discloses the system of claim 8. further comprising:
Beard further discloses further discloses generating, based on the new code portion, an updated SBOM comprising the new code portion (Col. 2, lines 28-35, “…In this disclosure, updates to a device specific SBOM may include: installation of additional software, installation of additional hardware, removal of installed software, removal of installed hardware, combinations thereof, and/or the like.”), (Col. 4, lines 17-57, “…The distinct SBOM update may comprise at least one update from the original SBOM in the root node plus all of the previous distinct SBOM updates of the parent leaf nodes (new code portion). In the case where the leaf node is directly connected to the root node, the distinct SBOM update may comprise at least one update from the original SBOM in the root node. Therefore, a device specific SBOM may be equivalent to a combination of the original SBOM and all of the distinct SBOM updates in all of the parent leaf nodes…”);
and executing the process based on the updated SBOM (Col. 4, lines 1-16, “…The central authority instructions may be configured to cause the central authority processor to authorize a plurality of validator systems to add a new block to a SBOM blockchain. The SBOM blockchain may be structured to contain at least one update in a device specific SBOM for each of a plurality of medical devices.”), (Col. 4, lines 58-67 to Col. 5, lines 1-27, “…The validator instructions may be configured to cause the validator processor to validate at least one update in the device specific SBOM in response to the device specific SBOM not being completely contained in the SBOM hash tree. A request for validation may be communicated to a central authority system. New entries may be added to the vulnerability database in response to at least one of the at least one update in the device specific SBOM not being contained in the vulnerability database. The validator instructions may be configured to cause the validator processor to communicate the new block to at least one other validator system in the plurality of validator systems in response to the new block being added to the SBOM blockchain…”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Iyer and Beard to include an updated SBOM as disclosed by Beard and be motivated in doing so in order to provide a real-time, comprehensive inventory of software components, and rapid identification of vulnerabilities.
However, Iyer in view of Beard does not explicitly disclose receiving a new code portion representing a patch of the vulnerability
Bales discloses receiving a new code portion representing a patch of the vulnerability
(¶0088, “…source code repairer 120 can also include suggestion generator 124. Suggestion generator 124, according to some embodiments, performs operations to generate one or more fixes or patches to remedy the defect detected by fault detector 122…”), (¶0101, “…source code repairer 120 can receive a request for fix suggestions to an identified defect. In some embodiments, the request for fix suggestions can come from a developer selecting a user interface element displayed by developer computer system 150 that is part of an IDE plug-in that communicates with source code repairer 120. Once the request is received, source code repairer 120 can generate one or more suggestions to fix the defective source code…”), (¶0103, “At step 550, source code repairer 120 receives the accepted suggestion from developer computer system 150 and incorporates the accepted source code suggestion into the source code repository…”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Iyer and Beard to include receiving a new code portion representing a patch of the vulnerability as disclosed by Bales and be motivated in doing so in order to strengthen the security of the system by protect the system from exploitations, data breaches and ransomware.
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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUDASIRU K OLAEGBE whose telephone number is (571)272-2082. The examiner can normally be reached MON-FRI. 7.30AM-5.30PM.
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, Farid Homayounmehr can be reached at 5712723739. 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.
/MUDASIRU K OLAEGBE/ Examiner, Art Unit 2495
/MAUNG T LWIN/ Primary Examiner, Art Unit 2495
Prosecution Insights