DETAILED ACTION
This action is responsive to the Applicant’s response filed 5/5/26.
As indicated in Applicant’s response, claims 1-17, 19 have been amended, claim 20 cancelled and claim 21 added. Claims 1-19, 21 are pending a next office action.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 8 is/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the 2-step analysis as following.
Step I: the claim is directed to a process category
Step IIA:
Prong One:
The steps recited as “analyzing” (set of compile-time … runtime parameters) to “identify” (a failure mode of … input interface and allocated safety requirements), and “analyzing” (mitigation data) to “identify” (architectural change to failure mode and input interface) are construed as activities that can be performed by a human using a mental process or via pen/paper, whereas the “architectural change” as recited and geared for an intended use (reduce a failure) does not change the fact that the identifying step remains internal to a human mind. The claim is directed to a Mental Process subset of the Abstract Idea type of Judicial Exception – MPEP 2106.04(a)
Prong Two:
The elements recited as “receiving” requirement data (for an input interface), “software element of a architecture”, “software element of target software architecture”; “receiving” compile-time and runtime parameters, respectively for compilation and influencing runtime are construed as extra-solution activity that precede the analyzing/identifying steps per prong One thus amount to well-understood activities – MPEP 2106.05(g) - provided as known routine of gathering data for a mental process of analyzing, thus no inventive transformation – MPEP 2106.05( c ) - is being conveyed here. The software element and target SW architecture are mere elements indicative of a field of use in which the Abstract Idea is being applied. MPEP 2105.05(h)
The recited acts of (i) “adjusting” (compile time parameters and runtime parameters) is recited in broad generic terms (“adjusted parameters applied to” the input interface) and mainly directed to an intended use, a desired outcome (“to reduce …a failure mode”) and of (ii) “adjusting” (source code … associated with the input interface) is expressed with a high level of generality and mainly geared to show an intended use or desired outcome (“mitigating … failure mode”). The “adjusting” per (i) fails to define any precise, structural configuration or constraint applied to the HW or parameters of a computer embodiment to realize a technical change. It does not state what specific compiler flags are modified, nor does it define which runtime parameters are mutated to alter the logical state of the interface. Instead, it merely recites the intended functional outcome: adjusting parameters so that the failure mode is mitigated. The “adjusting” per (i) or (ii) encapsulates a classic "result-oriented" functional clause. The claim provides no concrete depiction or granular mechanics of what structural code alterations have taken place (e.g., specific memory reallocations, thread-isolation boundaries, or dynamic syntax modifications). Merely reciting that "source code" is "adjusted" to execute an undefined "architectural change" is a high-level outcome that encompasses any and all ways of editing code to fix a bug.
Because these adjusting limitations do not recite a particular concrete solution, they do not improve the actual functioning of the computer itself under Enfish. Instead, they describe an abstract, high-level workflow instructing a generic computer to achieve a desired state of mitigation. As such, the additional elements do not provide a meaningful technological limitation and fail to integrate the abstract idea into a practical application under Step 2A, Prong Two.
Step IIB.
The additional elements of “receiving” (requirement data, parameters - from above) are construed as extra-solution pre-activities of no significance towards integrating the Abstract idea of analyzing/identifying into a practical application or adding significantly more to the mental process of analyzing - MPEP 2106.05(g) – while the elements recited as “adjusting” (to reduce effect … a failure mode, to mitigate effect … failure mode) in light of how they are ordered in the claim, are viewed as activities indicative of a intended use combined with the extra-solution activities to form a Abstract Idea method that fails to yield an "inventive concept" sufficient to transform this abstract idea (prong One) into a patent-eligible application because the steps describe routine, conventional, and high-level functional concepts executed on standard computing components. In other words, the claim is drafted at a high level of generality, it lacks any non-conventional data structures, specialized hardware dependencies, or concrete algorithms that would limit the claim to significantly more than the abstract concept of fixing software configuration errors. The "adjusting" steps are entirely dependent on the abstract step of "analyzing" the parameters; they merely represent the logical, well-understood downstream reaction to finding a system conflict.
Per In re Brian McFadden, high-level instructions for a standard computer to manipulate, alter, or optimize its internal settings based on statistical or algorithmic determinations fare no better than generic computing components. Because the claim simply instructs the practitioner to "adjust" variables and "adjust" code until the system safely works – i.e. monopolizing the basic concept of automated error mitigation without detailing the specific structural mechanism - the claim fails to provide an inventive concept under Step 2B. see MPEP 2106.05(b)(c )
In all, the method of claim 8 is deemed no-eligible under the 35 USC § 101 statute.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 1 is/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the 2-step analysis as following.
Step I: the claim 1 is directed to a medium/product category
Step IIA:
Prong One:
Claim 1 recites “analyzing” (initial compile-time … and runtime parameters) to “identify” (a failure mode of … input interface and allocated safety requirements), and “analyzing” (mitigation data) to “identify” (architectural change to failure mode and input interface), and as set forth in the Abstract Idea of claim 8, these are construed as activities than can be performed by a human via a mental process or pen/paper means. MPEP 2106.04(a). The product claim 1 is directed to mental process subset of an Abstract Idea type of Judicial Exception
Prong Two:
Claim 1 recites “receiving” requirement data (for an input interface), “software element of a architecture”, “software element of target software architecture”; “receiving” compile-time and runtime parameters, and these are construed as a typical extra-solution activity that precedes the analyzing/identifying steps per prong One; that is, these well-understood activities – MPEP 2106.05(g) – or routines of gathering data fail to show that any inventive transformation – MPEP 2106.05( c ) – to this computer/SW field is being conveyed here. The software element and target SW architecture (as recited) are mere elements indicative of a field of use in which the Abstract Idea is being applied. MPEP 2105.05(h)
The recited act of “adjusting” (compile time parameters and runtime parameters) is recited in broad generic terms (“adjusted parameters applied to” the input interface) and mainly directed to an intended use, a desired outcome (“to reduce …a failure mode”) and act of (“adjusting” (source code … associated with the input interface) is expressed with a high level of generality also set to show an intended use or desired outcome (“mitigating … failure mode”). The “adjusting” act from the above encapsulates a classic "result-oriented" functional clause. The claim provides no concrete depiction or granular mechanics of what structural code alterations have taken place (e.g., specific memory reallocations, thread-isolation boundaries, or dynamic syntax modifications). Merely reciting that "source code" is "adjusted" to execute an undefined "architectural change" is a high-level outcome that encompasses any and all ways of editing code to fix a bug
Because these adjusting limitations do not recite a particular concrete solution, they do not improve the actual functioning of the computer itself under Enfish. As such, the elements of “receiving” and “adjusting” do not provide a meaningful technological limitation and fail to integrate the abstract idea into a practical application under Step 2A, Prong Two.
Step IIB.
The additional elements of “receiving” (requirement data, parameters - from above) are construed as extra-solution pre-activities of no significance towards integrating the Abstract idea of analyzing/identifying into a practical application or adding significantly more to the mental process of analyzing - MPEP 2106.05(g) – while the additional elements recited as “adjusting” (to reduce effect … a failure mode, to mitigate effect … failure mode) in light of how they are ordered in the claim, are viewed as post-activities indicative of a intended use combined with the extra-solution activities of receiving to form an Abstract Idea method that fails to yield an "inventive concept" or non-conventional transformation sufficient to transform this abstract idea (prong One) into a patent-eligible application – as set forth above in the analysis of claim 8.
In all, the product claim 1 is deemed no-eligible under the 35 USC § 101 statute
Claim 15 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 15 is/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the 2-step analysis as following.
Step I: claim 15 is directed to a medium/machine system category
Step IIA:
Prong One: The elements equally recited here with analyzing, identifying have been set forth with the rejection of claims 1 and 8; therefore, per MPEP 2106.04(a), the medium claim 15 is directed to mental process subset of a Abstract Idea type of Judicial Exception.
Prong Two:
The additional elements equally recited here with receiving, adjusting have been set forth with the rejection of claims 1 and 8; therefore are viewed as mere extra-solution activities or well-understood routines that do not yield a transformation to the field of computer based analysis, the lack of inventive implementation especially evident in the steps of adjusting, whose expression only indicates a desired outcome or a intended use, as opposed to showing how technical limitations or detailed mechanism is/are provided to achieve the desired outcome. MPEP 2106.05 (c ) (g) (h)
Step IIB.
The additional elements of “receiving” (requirement data, parameters - from above) are construed as extra-solution pre-activities of no significance towards improving the technical underlying computer field in which the mental process of analyzing operates - MPEP 2106.05(g) – while the additional elements recited as “adjusting” (to reduce effect … a failure mode, to mitigate effect … failure mode) in light of how they are ordered in the claim, are viewed as post-activities indicative solely of a intended use. As combined with the extra-solution activities of receiving, the expression of a intended use (adjusting) cannot arrive as demonstrating an "inventive concept" or non-conventional transformation sufficient to convert this abstract idea (prong One) into a patent-eligible application – as set forth above in the analysis of claim 8.
In all, the product/system claim 15 is deemed no-eligible under the 35 USC § 101 statute
Step IIB analysis of dependent claims.
Claims 2 and 9, describe possible nature or type of failure mode with no explicit details to remedy a given failure mode or type; hence fail to add significantly more to the Abstract Idea.
Claims 3 and 10 describe one or more architectural change to resolve a corresponding issue; these limitations are mere expression of a desired outcome, without specifying a particular concrete solution or detailed particular mechanism conducive to that outcome; as such, they do not improve the actual functioning of the computer itself under Enfish – thus fail to add significantly more to the Abstract Idea
Claims 4 and 11, recite comparing safety requirements against each other for a correctness determination, and based on the determination, updating the safety requirements via add or remove. These steps can be performed (correlating) by a human mind, or via use of pen/paper to add and remove; hence do not add significantly more to the Abstract Idea.
Claims 5 and 12 recite determining dependency, analyzing diagram, evaluating dependency and adjusting parameters to mitigate effect of an error; the steps of determining, analyzing or evaluating do not add more to the mental process of the Abstract idea, notably when the intended use recited as “to mitigate” fails to set forth any concrete mechanism to implement this “adjusting” endeavor.
Claims 6 and 13 recite determining dependency, analyzing diagram, evaluating dependency and identifying a change based on the dependency; and as such, these limitations can be viewed as mental activities without further adding concrete limitations for significantly transforming the Abstract idea of the base claim.
Claims 7 and 14 recite evaluating dependencies for failure mode and modifying a change based thereon; the act of evaluating cannot be seen as HW implementation or explicit generation of SW, whereas the modifying act (as expressed without technical details) can be performed by a human mentally or via use pen/paper; and as such, no significant addition is provided to the Abstract idea for a practical application to be made possible.
Claims 16 and 17 recite the limitations of claim 2 and 3; hence fail to add significantly more to the Abstract idea of the base claim.
Claim 18 recites dependency correctness of a dependency and updating the requirement based thereon; these limitations are similar to those in claim 4 hence add more to the mental process of the Abstract idea
Claim 19 recites determining dependency and evaluating a failure mode and determining compile and runtime parameters based on the mode; and determining a architectural change based thereon. All these “determining” and “evaluating” are construed as activities that can be performed by a human mind.
Claim 20 recites target architecture and safety requirements as pertaining to a field of use; and this field of use (e.g. vehicle) cannot make the Abstract Idea to amount to significantly more than itself.
In all, claims 1, 8, 15 are non-eligible under the 35 § 101 statute.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-6, 8-10, 12-13, 15-17, 19 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Long et al, USPubN: 2024/0121261 (herein Long) in view of Oliphant et al, USPubN: 2016/0094576 (herein Oliphant), Lang et al, USPubN: 2024/0073238 (herein Lang) and Srinivasan, USPubN: 2020/0210310 (herein Srinivasan).
As per claim 1, Long discloses a non-transitory computer-readable medium comprising program code that is executable by one or more processors for causing the one or more processors to perform operations including:
receiving safety requirement data (test results to identify security vulnerabilities in the software library - para 0004; results to identify security vulnerabilities in the software library - para 0005, 0061; custom rules to better model the behavior of the third-party component if the function of the third-party component should be considered a pass through - para 0033; rules can check for
resource linkage issues - para 0035; custom rules pass through rule - para 0054) indicating an allocation of safety requirements (Note1: test results for exposing vulnerability of stored components
and pass through of undesirable data - para 0033 - and custom rules to check proper linkage - para
0035 - and invalidate/approve pass through - para 0056 - reads on one or more form of information requirements for allocating required safety for system components - e.g. system library; the
information being received into an SAST environment that further seeks and develops "tainted" data
calls as test implementation - Fig. 4-5 - aimed at mitigating issues on unchecked, vulnerability pass-
through or inroads by 3ʳᵈ party component into system library - para 0004-0005) to an external input
interface (plurality of entry points - para 0004; entry points - para 0020; all APIs in the third party component – para 0059) of a software element of a target software architecture (third party software component such as a software library – para 0023; third party component in multiple software applications – para 0020 ), wherein the target software architecture includes a plurality of standalone software elements (software library - para 0059; in multiple software applications – para 0020) configured to interact (e.g. APIs in the third party components - para 0059; calls all methods in a third component in the library - para 0023; calling all accessible methods within the third-party component - claim 1, pg. 5; interaction between the non-executable test application and the 3ʳᵈ party component - claim 20, pg. 6) with one another;
prior to deploying the target software architecture in a target computing environment:
receiving an initial set of compile-time parameters (rules … for example … prefix with tainted data is added to string – para 0063; rules to specify how to process RuleGen_AddTaint() – para 0060; see flags from below ) and runtime parameters (see below) pre-selected for the external input interface (identifying all APIs … then using rules to generate software code that can call – para 0059),
wherein the compile-time parameters include flags (analysis rules … flag data as tainted and check for tainted data – para 0024) used in a compilation process associated with the external input interface (see APIs from above), and wherein the runtime parameters include settings (e.g. Math.random > 0.5, string arg 0 is instantiated – para 0042; string argument, arg0 – para 0049-0050; RuleGen_CheckTaint (), Math.random() – para 0041-0042; RuleGen_AddTaint() – para 0046; methods and constructors … testing the accessible methods in a specific order, the order of the accessible methods in the test application code – para 0036; return value passed into a AddTaint() call and is then returned and passed to a return value or an object - para 0056) that influence runtime behavior (see AddTaint, Math.random from abvove) of the external input interface;
analyzing the initial set of compile-time parameters and runtime parameters (para 0032-0034 - Note2: using rules for tainting data under a SAST analyzer and test implementation of methods calls, their call order, arguments for a Math.random() mechanism in order to identify memory vulnerabilities attack via such tainted responses – para 0057 – and calls interface into a third party software reads on analyzing initial compile-time and runtime parameters to identify a failure mode predefined by the SAST via function calls or APIs - para 0032-0034) to identify at least one predefined failure mode (Math.random > 0.5 … segment 608 are analyzed again … this is to check whether any … vulnerabilities were caused by memory … when segment 608 was analyzed – para 0051; vulnerabilities were caused by memory changes when code 512 was analyzed – para 0044) that is associated with the external input interface (see APIs in the third party components - para 0059; calls all methods in a third component in the library - para 0023; calling all accessible methods within the third-party component - claim 1, pg. 5; interaction between the non-executable test application and the 3ʳᵈ party component - claim 20, pg. 6; every accessible method in the third party component is called – para 0036) and violates one or more of the safety requirements (see vulnerabilities from above) allocated to the external input interface (APIs in the third party components - para 0059; calls all methods in a third component in the library - para 0023; calling all accessible methods within the third-party component - claim 1, pg. 5; interaction between the non-executable test application and the 3ʳᵈ party component - claim 20, pg. 6 – Note3: vulnerabilities type memory faults or responses – para 0051, 0044 - from using rules, tainting techniques and argument for invoking method calls in a package test – Fig. 5; Fig .7 – reads on one or more SAST predefined failure modes – para 0020 - attributable or allocatable to an external input interfaces per effect of software calls interacting with a third party component, according to which a API, entry point for data into a third party SW fails to handle safe state of the memory, or constrain an untrusted data into a SW component, such failure identifiable via means of taint analysis on data entering that API or external input interface) in the safety requirement data; and
based on identifying (see above) the at least one predefined failure mode that violates (see Note3) the one or more safety requirements:
adjusting the compile-time parameters (false positives are found … rule can be created to flag an error whenever data is added …in the new software application – para 0062-0063) and runtime parameters (see modifying order of method calling from below) for the external input interface to mitigate the at least one predefined failure mode, such that the adjusted compile-time parameters and the adjusted runtime parameters are applied to the external input interface ( if … methodA is called a vulnerability can occur … to test … methodB() needs to be called before methodA() – para 0037).
Long does not explicitly disclose
analyzing stored mitigation data to identify at least one architectural change to the external input interface based on the at least one predefined failure mode, the at least one architectural change being configured to reduce an effect of the at least one predefined failure mode; and
adjusting source code associated with the external input interface to incorporate the at least one architectural change to the external input interface, thereby mitigating the effect of the at least one predefined failure mode.
Similar to identifying vulnerabilities issues and finding improvement to solve vulnerability issues in API-related method calls in software applications, Srinivasan discloses a infrastructure that analyze logs of services or web applications to evaluate performance for architectural compliance (see Abstract) from accessed data by the request patterns compared to expected usage models of architectural designs, the enforcement for compliance applied to software components and invocation repeatedly incurred at low level components that provide APIs to data accessing and software runs (para 0022) or as result from coupling between SW components via the APIs (para 0027), using a compliance analyzer to evaluates whether rate, static state or running instances of queries depart from expected usage models (para 0056), in identifying root cause of the departures; e.g. to improve architectural compliance (para 0057; steps 510, 520 - Fig. 5) based on which, mitigation can be performed; for instance, using a tool of a management resources suite and information from a database to identify root cause and a mitigation action (para 0058) such as load balancing techniques (para 0059) or addition of resources to alleviate demands that constitute departure from the expected usage models.
Hence, architectural infrastructure to enforce architectural compliance based on metrics and captured data from API and software runs using a mitigation tool that utilizes mitigation database to fetch a mitigation action to solve a identified departures from compliance norms is recognized.
Oliphant discloses SDK environment in which applications are developed with API access to retrieve status information from applications whereby security-related determination are made available so to enable certain actions based on thereon in terms of vulnerability, remediation (para 0036), the SDK framework exposing APIs to support security-related decisions via effect of accessing a database to determine whether a threat exists and should be blocked (para 0048), the vulnerability and remediation database (V&R database – Fig. 1) maintained to associate a plurality of device vulnerabilities to which computing devices can be subject with plurality of remediation techniques that collectively remediate the plurality of device vulnerabilities (para 0003), the V&R database having thereon updated list of security vulnerabilities in software, with corresponding identifier used to retrieve remediation information (para 0020-0021), e.g. the vulnerability identifier maintained on the database by which a server can locate a computer having a vulnerable software and determine whether it can be patched; that is, the security server, based on current software, patch, policy, configuration status, selects one or more remediation techniques from the database that remediates the particular vulnerability (para 0032)
Hence, analyzing stored mitigation data to identify at least one architectural change to the external input interface based on the at least one predefined failure mode, and adjusting applications associated with the external input interface to incorporate the at least one architectural change to the external input interface, thereby mitigating the effect of the at least one predefined failure mode is recognized.
Lang discloses use of a CI/CD, DevOps (para 0030) pipeline implementing with APIs within a deployment pipeline to enable a developer/user to push code change while coding and performing testing, tracking and detecting vulnerabilities, generating compliance mapping and use feedback to improve resiliency and readiness of the code(para 0115), where information containing different types of mitigations, and their mappings to vulnerabilities is maintained in a Mitigation database (para 0103) using a compliance mapping engine responsive to incident and risks to provide action as part of mitigation/remediation to stop a damage or restrict the attack by redeploying with security mechanisms(para 0124). Use of a mitigation database enabling vulnerability detection and compliancy mapping engine to implement remediation via pushing code change or remediation mechanism to restrict/stop/control damage to code or procedure calls observed under facilitation by an open-source framework is recognized.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the cycle of APIs configuration, code tracking, applying changes for retesting in Long system so that in response to identification of a vulnerability fault, the adapted code reconfiguration would include
1)analyzing stored mitigation data to identify at least one architectural change to the external input interface or APIs – as set forth in Srinivasan, Oliphant and Lang - based on the at least one predefined failure mode, the at least one architectural change being configured to reduce an effect of the at least one predefined failure mode – vulnerability issue as in Oliphant and Lang or architectural compliancy in Srinivasan; and
2) adjusting source code – as per Lang - associated with the external input interface or APIs to incorporate the at least one architectural change – as per Srinivasa, Oliphant, Lang - to the external input interface, thereby mitigating the effect of the at least one predefined failure mode – remediation to vulnerability issue as in Oliphant and Lang or architectural compliancy in Srinivasan; because
endpoints and APIs-associated interactions and data accesses that interrelate different application environments or instances entail increased likelihood of undesirable intrusion, untrusted incursion or cyber-security breach into software components substantially via external interfacing means like calls endpoints or executing APIs, and
by providing a tracking/analyzing module set at a higher layer to all SW applications of a network to monitor, snoop I/O, software behavior in line with how the software handles vulnerability risks at these endpoints and API calls and likely route by which untrusted intrusion, malware attacks or cyber-threat would pass through and be able to damage/compromise software or data integrity of running applications, using for instance, various OpenSource tools as set forth above (see Lang DevOps), this architectural tracking layer can be set to instrument SW runtime, method calls (by components of a target application) and able to detect and identify a mode or family of failures that particularly reflects an architectural type compliancy or security risk containment as set forth above, which in turn would enable a mitigation response entity to immediately effectuate identification and search for a remediation mechanism that would specifically address or mitigate impact of such architectural type of threat, notably when the mitigation entity cooperates with finding of the Opensource tool and is equipped with service of remediation database as set forth above, in that based on a type, a mode or category of this architectural fault determined from the Opensource engine, the mitigation entity be able to consult the database, - e.g. the remediation database as set forth above - find and fetch a matching patch or remediation package into the opensource environment, whereby software or source code in this Opensource environment can be modified to integrate the software adjustment or patch as part of the system wide intent or enterprise response to mitigate the vulnerability failure learned from instrumenting and tracking runtime calls as early as API entry points into respective runtime of SW components subjected for investigation by this mitigation layer as set forth above in the remediation approach by Lang, Oliphant and Srinivasan.
As per claim 2, Long does not explicitly disclose non-transitory computer-readable medium of claim 1, wherein the at least one predefined failure mode includes
(i)a first failure mode associated with a complexity of logic in the external input interface,
(ii)a second failure mode associated with mismanagement of data or hardware resources, and
(iii)a third failure mode associated with misbehavior of invoked interfaces of dependencies of the external input interface.
As for (iii), a issue set via rules of test code in Long includes that of resource linkage in the 3rd party code when an object goes out of scope prior to being closed (para 0035) hence, failure from mismanagement of dependencies by invoked interfaces is recognized – referred herein as (*).
As for (ii), mismanagement in terms of data or HW resources is shown in Srinivasan compliance architecture via management attempt of “load balancing” to reduce mismanaged effect of overburdened HW resources (para 0038) in conjunction with endeavor of administering, matching physical devices so to meet demand of interacting entities such as users, servers and SW components (para 0029, 0034) or virtual machines (para 0032) or number of requests reflected in logs (para 0036)
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement analysis of vulnerability and seeking mitigation to the issue or impact caused by the security and health state of SW application using code tracking approach in Long so that the type of failure determined thereby can stem to mismanagement of resources including
failure mode related to mismanagement of HW resources as in Srinivasan where countermeasure thereof include attempt to adjust load balancing among physical devices so to meet the demand thereof by software and executing entities at a given time
failure mode associated with misbehavior of invoked interfaces as part of dependencies tracking or boundaries containment or rules defining object behavior associated entry and exit of a external input interface, such as misbehavior of object not staying in bound when the interface is supposed to close as set forth above in (*); because
detected failure mode associated with administering hardware utilization or mismanaging of HW resources would enable a mitigation entity to readjust availability of HW resources or devices at a given time and rebalance its distribution to immediately fulfill part of the demand of applications or NW entities that are affected by this type of resources, and detected failure mode associated with boundaries check as part of dependencies to managed and observe in regard to proper behavior of invoked interfaces or objects, components to which the external input interface is related at runtime would enable a management module to detect a type of boundary misbehavior that can trigger a hard memory fault which if not addressed timely would unleash the undesirable propagation of this failure mode onto other parts of the applications whose health state the test and mitigation system in Long is configured to protect, maintain and stabilize.
As per claim 3, Long discloses non-transitory computer-readable medium of claim 2, wherein
the at least one architectural change includes
a first architectural change configured to resolve a problem in the complexity of the logic in the external input interface,
a second architectural mitigation-change configured to resolve the mismanagement of the data or the hardware resources, and
a third architectural change configured to resolve the misbehavior of the invoked interfaces of the dependencies of the external input interface.
Based on the obvious effect of seeking adjustment, mitigation responsive to identification of a failure mode caused by a mismanagement of HW resources or by a misbehavior of objects (and dependency thereto) associated with invocation with or by an external input interface as set forth above, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement a failure detection and code behavior tracking in Long so that when the failure mode is recognized as impacting resources and NW components on an architectural level , a mitigation engine in conjunction with a remediation database would be configured in conjunction with the code tracking, testing and opensource tool as set forth per the teachings by Lang, Oliphant and Srinivasan from rationale A above, to implement
1) architectural change configured to resolve the mismanagement of the data or the hardware resources as set forth per rationale in claim 2;
2) architectural change configured to resolve the misbehavior of the invoked interfaces of the dependencies of the external input interface as set forth in claim 2; because
using logged and database information on variety of architectural fault types or failure mode, on compliancy issues as well as plurality of recommended mitigation packages also made available with the database for mitigation and remediation effect as set forth with Lang, Srinivasan or Oliphant per rationale A in claim 1, would enable a mitigation portion of the instrumentation, test of OpenSource environment – see Lang DevOps per rationale A of claim 1 - to determine based observed behavior of a target/instrumented software, a specific area in which deficiency in interface dependencies or hardware resources can give way to a more general architectural threat that would require immediate attention or remediation, and with availability of resources from one such remediation database, a mitigation engine included with the test/development tool can query the DB and find a software patch that particularly matches the architectural context of resolving or mitigating either the interface dependencies or hardware resources type failure identified by instrumentation and test by the OpenSource environment, e.g. as root for a larger propagation of risk to other components part of the system.
As per claim 5, Long discloses non-transitory computer-readable medium of claim 1, wherein
the operations further comprise:
determining a dependency of the external input interface (vulnerable entry points every possible code path through plurality of code paths - para 0023; data flow pass through rule and data flow sink - para 0054; potential vulnerability identified through the ordered sequence of method calls all possible code paths are evaluated - claim 1, pg. 6) by analyzing the source code (method calls, static methods, constructors, setter methods – para 0005; para 0025; para 0042, 0049, 0056) for the external input interface (refer to claim 1);
evaluating the dependency (possible code paths, rule and data flow sink, sequence of calls through all possible code paths from above) for a corresponding failure mode (refer to claim 2); and
in response to detecting the corresponding failure mode associated with the dependency, adjusting the compile-time parameters and the runtime parameters (para 0041-0043 ; para 0049-
0050, para 0056 - refer to Note2) based on the corresponding failure mode associated with the dependency (see above) to mitigate an effect of the corresponding failure mode on the external input interface.
As per claim 6, Long discloses non-transitory computer-readable medium of claim 1, wherein
the operations further comprise:
determining a dependency of the external input interface (see possible code paths, rule and
data flow sink, sequence of calls through all possible code paths from above) by analyzing the source code (see claim 5 from above) for the external input interface;
evaluating the dependency for a corresponding failure mode (refer to rationale of claim 2); and
in response to detecting the corresponding failure mode (see above) associated with the dependency, identifying the at least one architectural change (refer to rationale of claim 3) based on the corresponding failure mode associated with the dependency.
As per claim 8, Long discloses a computer-implemented method comprising:
receiving safety requirement data indicating an allocation of safety requirements to an
external input interface of a software element of a target software architecture; and
prior to deploying the target software architecture in a target computing environment:
receiving an initial set of compile-time parameters and runtime parameters pre- selected for the external input interface, wherein the compile-time parameters include flags used in a compilation process associated with the external input interface, and wherein the runtime parameters include settings that influence runtime behavior of the external input interface;
analyzing the initial set of compile-time parameters and runtime parameters to identify at least one predefined failure mode that is associated with the external input interface and violates one or more of the safety requirements allocated to the external input interface in the safety requirement data; and
based on identifying the at least one predefined failure mode that violates the one or more safety requirements:
adjusting the compile-time parameters and runtime parameters for the external input interface to mitigate the at least one predefined failure mode, such that the adjusted compile-time parameters and the adjusted runtime parameters are applied to the external input interface;
analyzing stored mitigation data to identify at least one architectural change to the external input interface based on the at least one predefined failure mode, the at least one architectural change being configured to reduce an effect of the at least one predefined failure mode; and
adjusting source code associated with the external input interface to incorporate the at least one architectural change to the external input interface, thereby mitigating the effect of the at least one predefined failure mode.
(All of which having been addressed in claim 1)
As per claim 9, Long discloses method of claim 8, wherein the at least one predefined failure mode includes a first failure mode associated with a complexity of logic in the external input
interface, and a second failure mode associated with misbehavior of invoked interfaces of
dependencies of the external input interface (refer to rationale of claim 2).
As per claim 10, Long discloses method of claim 9, wherein the at least one architectural change includes a first architectural change configured to resolve a problem in the complexity of the logic in the external input interface, a second architectural mitigation change configured to resolve the misbehavior of the invoked interfaces of the dependencies of the external input interface (refer to rationale of claim 3)
As per claim 12, refer to claim 5
As per claim 13, refer to claim 6
As per claim 15, Long discloses a system comprising: one or more processors; and a non-transitory computer-readable medium comprising program code that is executable
by the one or more processors for causing the one or more processors to perform operations
including:
receiving safety requirement data indicating an allocation of safety requirements
to an external input interface of a software element of a target software architecture, wherein
the target software architecture includes a plurality of standalone software elements configured
to interact with one another; and
prior to deploying the target software architecture in a target computing environment:
receiving an initial set of compile-time parameters and runtime parameters pre-selected for the external input interface, wherein the compile-time parameters include flags used in a compilation process associated with the external input interface, and wherein the runtime parameters include settings that influence runtime behavior of the external input interface;
analyzing the initial set of compile-time parameters and runtime parameters to identify at least one predefined failure mode that is associated with the external input interface and violates one or more of the safety requirements allocated to the external input interface in the safety requirement data; and
based on identifying the at least one predefined failure mode that violates the one or more safety requirements:
adjusting the compile-time parameters and runtime parameters based on the external input
interface to mitigate the at least one predefined failure mode, such that the adjusted compile-
time parameters and the adjusted runtime parameters are applied to the external input interface;
analyzing stored mitigation data to identify at least one architectural change to the external input interface based on the at least one predefined failure mode, the at least one architectural change being configured to reduce an effect of the at least one predefined failure mode; and
adjusting source code associated with the external input interface to incorporate the at least one architectural change to the external input interface, thereby mitigating the effect of the at least one predefined failure mode.
(all of which having been addressed in claim 1)
As per claim 16, refer to claim 2.
As per claim 17, refer to claim 3.
As per claim 19, Long discloses system of claim 15, wherein the operations further comprise:
determining a dependency of the external input interface;
evaluating the dependency for a corresponding failure mode; and
in response to detecting associated with the dependency: determining the adjusted compile-time parameters and adjusted runtime parameters based on the associated with the dependency; and
determining the at least one architectural mitigation-change based on the one or
more failure modes associated with the dependency.
(refer to claim 5)
Claims 4, 11, 18 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Long et al, USPubN: 2024/0121261 (herein Long) in view of Oliphant et al, USPubN: 2016/0094576 (herein Oliphant), Lang et al, USPubN: 2024/0073238 (herein Lang) and Srinivasan, USPubN: 2020/0210310 (herein Srinivasan) further in view of Crabtree et al, USPubN: 2022/0014560 (herein Crabtree) and Benjamin, USPubN: 2006/0191010 (herein Benjamin)
As per claim 4, Long does not explicitly disclose non-transitory computer-readable medium of claim 1, wherein the operations further comprise:
(i) determining whether the safety requirements are correct by comparing the safety
requirements for the external input interface against another set of safety requirements for
another external input interface; and
(ii) based on determining that the safety requirements are incorrect because the safety
requirements include a missing safety requirement or an extraneous safety requirement,
updating the safety requirements to add the missing safety requirement or remove the extraneous
safety requirement.
Rules and requirements used in the Long’s SAST or code adjusting environment relates to method calls and interfaces observed on APIs (para 0059) and function entry points (para 0015) of the 3rd party software observed from rule-based technique – e.g. tainting (para 0020-0021) applied to access points of the methods (Fig. 4-5 ;para 0033-0034) generated by a SAST environment (Fig. 1) as part of investigating vulnerability risk (identifying security vulnerabilities – para 0029) in third party software; e.g. tainting techniques and rules therefor (para 0060-0064; Rules 116 – Fig. 2) where modification of techniques is based on observed vulnerability determination from the monitored sequence of calls implementing the tainting. Hence determining whether the safety requirements are correct by comparing the safety requirements for a first or another external input interface – referred herein as (*) - from results of the tainting technique is recognized.
As for (i)
Crabtree discloses analyzing a cyber-graph by a reconnaissance engine to collect vulnerability data or potential risk activity (Fig. 8) into a CPG (Fig 12) with use of a mapper that retrieve laws, policies and other rules from a authority database (para 0096; graph 1902 – Fig. 19) then compare reconnaissance data received into the reconnaissance engine to determine whether or to what extent the data receives indicates a violation of the pre-established rules, where patterns or trends thus identified would enable possibility to change a service to the client or contextual data to the client.
Hence, determining whether the safety requirements are correct by comparing the safety requirements against another set of safety requirements is recognized.
As for (ii)
Long discloses inspection of tested code in the SAST environment where upon determination that a false positive exist (para 0028-0029), need to adjust the simulation test to account for such false identification would improve (para 0053) the SAST purpose of checking security vulnerabilities in SW application in view of interaction with 3ʳᵈ party components, including manual inspection of test result and generating of custom rules (Fig. 2) that accommodate a new test configuration that more correctly expose insecure use by the external 3ʳᵈ party component; thus determination if there is a missing safety requirement and accordingly generating new requirement to update the set of custom safety requirements would have been obvious.
Benjamin, for instance, create new rule (Fig. 3) to support improvement to both the intrusion
detection component and the vulnerability-assessment component in the course of evaluation both
component via simulation (para 0041, 0059) geared for detecting attacks and detecting new weakness
in either component (para 0051); hence adding a missing rules indicative of safety requirement to
more properly implement/update intrusion detection and vulnerability-assessment software is
recognized
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the use of vulnerability assessment rules and requirements in Long’s SAST environment so that operations thereof include
1)determining whether the safety requirements are correct by comparing the safety
requirements for the external input interface against another set of safety requirements – as shown in the comparing by Crabtree – for one or another external input interface – as per (*); and
(ii) based on determining that the safety requirements are incorrect because the safety
requirements include a missing safety requirement or an extraneous safety requirement,
updating the safety requirements to add the missing safety requirement or remove the extraneous
safety requirement –as set forth in Benjamin adding made in response to a missing requirement; because
use of a authority or database to store reference rules, requirements or vulnerability assessment standards for use (e.g. comparison) by cyber-risk or vulnerability remediation environments toward updating their current set of rules and requirements would not only improve accuracy of these environment in assessing where and how a software component is able or unable to handle or filter data from external software source via entry points of function calls, according to which, the local set of rules of one such cyber remediation engine would also be augmented meaningfully so to include additional or new rules, when it is deemed that a risk detection requirement is missing when compared to the set of requirements accessed from at the reference authority storage or database as set forth in Crabtree.
As per claim 11, refer to rationale of claim 4.
As per claim 18, refer to rationale of claim 4.
Claims 7, 14 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Long et al, USPubN: 2024/0121261 (herein Long) in view of Oliphant et al, USPubN: 2016/0094576 (herein Oliphant), Lang et al, USPubN: 2024/0073238 (herein Lang) and Srinivasan, USPubN: 2020/0210310 (herein Srinivasan) further in view of view of Tahan, USPubN: 2009/0150899 (herein Tahan)
As per claim 7, Long does not explicitly disclose non-transitory computer-readable medium of claim 1, wherein the operations further comprise recursively evaluating dependencies of the external input interface for failure modes and modifying the at least one architectural change based on the failure modes.
In Long, all possible data path through which a 3ʳᵈ component interface with a library system via entry points is under analysis of the SAST for effect to indicate possible security vulnerabilities
incurred with the 3ʳᵈ party component (para 0016) although the analysis can revert to manual inspection to account for all possible security vulnerabilities in the 3rd party component (para 0017); i.e. revisiting test results to detect incorrectly identification of vulnerability intrusion entails effect of recursively evaluating (by the SAST) all dependent data paths (para 0016; code paths - para 0037) by which to determine illegal intrusion by a 3ʳᵈ party component via an entry point (untrusted data is passed into the entry point - para 0020) into the library system, to either affirm actual/positive vulnerability intrusion or else detect a "false positive" (para 0028-0029) according to which to
modify parameterization of the vulnerability detection code (para 0062-0063; Fig. 7) which is altered
with new rules (para 0053). Hence, modification the at least one architectural mitigation based on
one failure mode on basis of re-evaluate all dependencies associating SW components with the
external input interface is recognized.
Tahan discloses trust-determinant component (TDC) configured for resolving trust
dependency between modules within a system that relies of trust relationships for operation by the
platform components, where assessment of the trust-dependency by the TDC is recursive in that
parametric configuration as part of resolving this dependency is modified on basis of values
recursively retrieved from a measurement log (Figure 6-8; para 0042) that captures metrics returned
by the different components due to a challenge (challenge 601, reply 602 - Fig. 6) systematically
paused by the TDC, the trust dependency resolution as part of securing protection of links (Figure 9
para 0048) thus carried out recursively over communication paths (Fig. 7) of partitioned component
layers of the platform in order to assess integrity of data within partitioned platform's modules (Fig.
13-15) in accordance with maintaining confidentiality and integrity protection (Fig. 3) by the trusted
platform. Hence, recursive assessment of trusted links or communication paths inter-relating
partitions or modules within a platform by a trust-determinant module that modifies trust assessment
code in the course of recursively carrying out resolution related to trust dependency and integrity
protection is recognized.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to implement SAST evaluation of intrusion test result and assessing code
paths in regard to all possible data paths associated with SW interaction with entry points (external
input interface) in Long system, so that operations by the SAST would include recursively evaluating
- as in Tahan - dependencies in relevance with one or more external input interfaces, for one or more
failure modes such as integrity/vulnerability attack, and modifying the at least one architectural
mitigation based on one of the failure modes the recursive code re-adapting - as shown with Tahan
modifying resolution code - coordinating automated evaluation of test data with manual revisit of
code paths as in Long responsive to "false positives" assessment; because
trust dependency attestation performed by recursive evaluation of links and likely paths
between inter-communicating components of a system that endeavors data integrity and operational
trust when resolved granularly to ensure that a) integrity to internal component pervades throughout
the partitions of the system and b) to preclude adverse intrusion from external components, all as a
software-driven evaluation/assessment when executed in a recursive mode will enforce the targeted
protection (and reaffirm its validity) to all inter-component interface paths or interfacing ports,
notably when the affirmed resolution by this trust verification can be possibly misdirected by
potential ambiguity as set forth above in Long as "false positives" indicative of a deeply incorrect
assessment of a vulnerability determination, which in turn would be impeding realization of reliable
test or masking accuracy thereof toward system level endeavor and developers effort of automating
techniques or SW so as to properly expose and efficiently detect vulnerability risk into protected area
of a system, and
by coupling automated evaluation of vulnerability intrusion test with recursive evaluation
thereof using a non-automated approach as set forth in Long, more insight and hidden weakness in
implementing an intrusion test code can be discovered; e.g. so corrective modification to the test SW
can be adapted to improve the strength and accuracy of the vulnerability intrusion SW as endeavored
in Long system, the modification made all the more significant in view of scale of potential risks
associating multiple entry points into the protected assets of the system with external 3rd party components, as shown in Long implementation of test under a SAST analysis.
As per claim 14, refer to rationale of claim 7.
Claim 21 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Long et al, USPubN: 2024/0121261 (herein Long) in view of Oliphant et al, USPubN: 2016/0094576 (herein Oliphant), Lang et al, USPubN: 2024/0073238 (herein Lang) and Srinivasan, USPubN: 2020/0210310 (herein Srinivasan) further in view of Crabtree et al, USPubN: 2021/0136120 (herein Crabtree2)
As per claim 21, Long does not explicitly disclose system of claim 15, wherein the target software architecture is configured to be used in a vehicle, and wherein the safety requirement data defines functional and safety goals for vehicle systems.
Crabtree2 discloses a cyber decision platform in a configuration for use in investing vehicle management (para 0013) with analytics and predictive simulation to produce predictions applied in role of cyber security (Fig. 2; para 0052) associated with functionality that regulates trade and commerce capabilities; e.g. in the vehicle or automobile field such as to provide “security conscious” report or a implementation weight into technology of vehicle theft (para 0068; Fig. 6), insurance fields such as vehicle premium, policies (para 0069, 0071), the cyber decision platform employing distributed architecture extensible to meet the simulation and distribution of resources to meet the needs of the security field via collecting information from all sources and producing security score based thereon as well as analysis geared to reveal relationships and vulnerabilities (para 0058), including rating on cybersecurity in an evolving context to reflect changes in SW, HW update, and/or discovered or announced vulnerabilities (para 0059), to provide computing devices variation, changes adapted with, or combined with capabilities or functions of devices like in-vehicle computer systems or navigation in automobile (para 0088)
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement analysis of application software in regard to security vulnerabilities in Long SAST so that upon determination of extent and type of failure having a significant effect on the architectural aspect of a field or domain, the application of software mitigation via the SAST would be directed to manage software destined in this target software architecture such as that used in a vehicle field – as in Crabtree2 - according to which, the safety requirement data used by the mitigation framework defines functional and safety goals for vehicle systems – as set forth with the cyber security platform in Crabtree2; because
modern software and firmware is becoming increasing crucial in operation and control of automotive industry, in-vehicle technology such as multimedia, GPS, security sensor , theft control devices and embedded processors in the software-based automation aspects of the automobile field or applications, and providing a security and mitigation environment equipped with rules and safety requirement data to define how the software should operate to support the cyber-security protection and manage the vulnerability aspect of in this automobile field would enable provision of the needed cyber protection aspect and vulnerability management to the software provisioning for this industry, boosting thereby the marketability of the products, mobile software and automation devices destined for use in this highly demanded consumer field.
Response to Arguments
Applicant's arguments filed 5/15/26 have been fully considered but they are not persuasive. Following are the Examiner’s observations in regard thereto.
(A) Applicants have submitted that (Applicants Remarks pg. 1) from the claimed features about mitigation accomplished though dynamic adjustment of compile time and runtime parameters tailored based on a failure mode to reduce failures that would enhance functioning of computer systems, the claims thus submitted clearly embody technical improvements and that the § 101 rejection should be withdrawn. The features of the claim as submitted have been analyzed with proper prongs of the Mayo 2-steps eligibility determination. Any argument related to the newly amended language has to be held until a prima facie case of rebut be returned responsive to this latest Office action for the rebut to be discussed with due merits.
(B) Applicants have submitted that withdrawal to the § 103 rejection (Applicants Remarks pg. 2) be withdrawn in view of the extent of the amendment made to the independent claims. Any argument related to the newly amended language has to be held until a prima facie case of rebut be returned responsive to this latest Office action for the rebut to be discussed with due merits.
In all, the claims as submitted and amended will stand rejected as set forth above.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tuan A Vu whose telephone number is (571) 272-3735. The examiner can normally be reached on 8AM-4:30PM/Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Chat Do can be reached on (571)272-3721.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571-272-3609.
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 Group receptionist: 571-272-2100.
/Tuan A Vu/
Primary Examiner, Art Unit 2193
July, 03, 2026
Prosecution Insights