DETAILED ACTION
This action is responsive to the Application filed 2/15/2024.
Accordingly, claims 1-20 are submitted for prosecution on merits.
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 following 2 step analysis.
Step I: the claim as a method is directed to a statutory type category.
Step II, A:
The method of claim 8 includes steps of determining (a failure mode); determining (adjusted parameters); determining (mitigation) and absent any details showing how these steps are implemented to yield result such as a mode, parameters or mitigation, it is deemed that the “determining” (per step IIA, prong 1) can be performed by a mental process, as the “method” as claimed does not amount to significantly more than a mental process pertinent to an Abstract Idea type of Judicial Exception.
Per stepIIA, prong 2, there are no sufficient details surrounding these “determining” steps for one to see how these activities would require non-conventional implementation/techniques that otherwise require involvement of SW/HW much more than what mental activities can do. Hence, the “determining” step do not integrate the Judicial Exception into a Practical Application.
Step II, B:
The “additional element” recited as “program code that is executable by one or more … processors for causing … processors to perform operations” amount to instructions to implement an abstract idea on a generic computer, or merely use to the generic computer to perform the Abstract Idea.
The additional element such as “receiving” (safety requirements) can be dismissed as insignificant or routine activity to gather information as this “receiving” step fails to provide significantly more to the Abstract Idea of step IIA – see MPEP 2106.05(d). This “receiving’ amount to extra solution activity such as gathering, displaying, updating, transmitting and storing data, hence cannot integrate the judicial Exception into a Practical application. In other words, the courts have identified functions such as gathering, displaying, updating, transmitting and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception. See MPEP 2106.05(d).
The element recited as “applying the mitigation” constitutes a way to bring about result from the abstract concepts of “determining” and as a post-activity or field-of-use limitation; the “applying” therefore does not integrate the Judicial exception into a Practical Application see MPEP 2106.05(f)
The steps of “determining” and “applying” fail integration of the abstract method into a Practical application, nor are they accompanied with implementation details that improve the technical SW safety, while mere use of computer, and architecture as a generic tool to perform the process for determining a mitigation and applying it do not bring forth how specific the tool induces clear inventive progress to the “determining” or “applying”. Claim 8, therefore cannot be integrated into a Practical Application under MPEP 2106.05(f).
Claims 1 and 15 is/are 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 and 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 following 2 step analysis
Step I: Claim 1 recites a medium deemed a proper category; claim 15 recites a system also deemed a proper category.
Step IIA:
Claim 1 recites steps of determining (a failure mode); determining (adjusted parameters); determining (mitigation) and absent any details showing how these steps are implemented to yield inventive result, it is deemed the claim as a whole is not showing how improvement to a particular field of technology is being performed, but rather describes end result (mode, parameters or mitigation) to a mental step of “determining”. “Medium” claim 1 as recited, amount to activities that can be performed by a mental process constituting a Judicial Exception in the same manner the method of claim 8 is being directed to an Judicial Exception.
Claim 15 recites system processor configured to perform determining (a failure mode); determining (adjusted parameters); determining (mitigation) and, absent any details as to how improvement to a particular field of technology is being performed, it is deemed that the “determining” steps of the system claim amount to a mental process similar to that of method claim 1, that cannot be integrated into a practical Application.
Step II, B:
The additional elements of both claims 1 and 15 equally include “receiving” (safety requirements) which is dismissed as non-significant information gathering routine; “external input interface” and “software element”, “architecture” including “plurality of software elements” which are dismissed as mere use of computer interface means or tool; “applying the mitigation” which is dismissed as post-activity to dispatch or carrying out the result from the mental process as opposed to demonstrating how the mental process particularly results in improvement of the field of software safety - as set forth above per MPEP 2106.05 b, d, f, g, - Therefore, these additional elements fail to render the Judicial Exception per step IIA so it can amount to substantially much more.
Claims 1 and 15 are thus directed to a Judicial Exception in form of an Abstract Idea type that cannot be integrated into a Practical Application.
Eligibility per step IIB by the dependent claims.
Claim 2 recites types of failure mode thus does not teach additional ways to improve the field of SW safety by way of performing the “determining” steps of claim 1.
Claim 3 recites examples of mitigation such as to resolve a problem of a given nature. That is, presentation of end-purposes in terms of variety of resolution (to a mitigation) listed broadly without implementation details cannot demonstrate how specifically performing the abstracted steps of “determining” (of claim 1) would bring forth a inventive technique to the SW safety maintenance field.
Claim 4 recites “determining” (requirements) which can be dismissed as a mental process, and updating the requirement as post-activity that depends on result of a mental process.
Claim 5 recites determining (a dependency), evaluating (the dependency), and determining adjusted parameters based on a failure mode detection, which are all dismissed as activities that are performed by a mental process, which, absent any additional implementation details, cannot integrate claim 1 into a Practical Application.
Claim 6 recites determining (a dependency), evaluating (the dependency), and determining a mitigation based on a failure mode detection; and similar to claim 5, claim 6 fails to integrate base claim 1 into a Practical Application.
Claim 7, recites recursively evaluating dependencies and modifying at least one mitigation, which can be dismissed as (i) mere activities susceptible to be performed iteratively in a human mind; and (ii) a post-activity that necessary depends upon result of a mental process. Moreover, the broadly expressed activities in claim 7 fail to demonstrate how performing the (mental step of) “determining” and post-mental step of “modifying” would specifically bring forth an inventive technique to the SW safety maintenance field.
Claims 9-14 are respectively replication of claims 2-7; hence, for the same reasons set forth above, cannot render to Judicial Exception of claim 8 for it to amount to substantially much more.
Claims 16-20 are respective replication of claims 2-7 and for the same reasons, fail to integrate the mental process of claim 15 into a Practical Application.
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, 16-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 USPubN: 2020/0167512 (herein Chitra).
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 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 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 on requirement 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 3rd party component into system library – para 0004-0005) to an external input interface (plurality of entry points – para 0004; entry points – para 0020) of a software element (e.g. third party component – para 0015; third party component – para 0020) of a target software architecture (software library – para 0004), wherein the target software architecture includes a plurality of standalone software elements (software library – para 0059) 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 3rd party component – claim 20, pg. 6) with one another;
determining at least one failure mode (software vulnerability if untrusted data is passed into the entry point, the vulnerability can be comingled with other vulnerabilities … in the software application – para 0020; a SQL injection in the library … security vulnerability – para 0018; security vulnerability – para 0028; tainted data is passed … and results in a vulnerability in the third party component – para 0057; vulnerability … when tainted data is added to a string – para 0063) associated with the external input interface (see entry points from above);
determining adjusted compile-time parameters ( e.g. AddTaint(), CheckTaint(), includes definition for data types of … method call takes a parameter - para 0039; CheckTaint(), Math.Random, string argument, arg0 - para 0041-0043 ; arg0 -para 0049-0050 – Note2: arguments and parameters defined with source code for testing a pass-through by the SAST – para 0022, and return values expected of method calls reads on a) compile-time parameters for defining validation code adjusted on basis of vulnerability/pass-through threat and b) runtime parameters of test code executing calling by test software adjusted – see para 0028, 0062 - in response to said pass through vulnerability or false positives) and runtime parameters (return value … passed into a AddTaint() call and is then returned … and passed to a return value or an object – para 0056 – refer to Note2) based on the at least one failure mode (e.g. software vulnerability if untrusted data is passed into the entry point - para 0020);
determining at least one mitigation (reduce computer time and improve efficiencies in identifying vulnerabilities in software components, test application … reducing memory requirements, analysis process that is similar to the compilation process – para 0021) based on the at least one failure mode (see above), the at least one mitigation being configured to reduce an effect of the at least one failure mode (improving efficiencies in identifying vulnerabilities – para 0021); and
applying the at least one architectural mitigation (that automatically taints all entry points – para 0021) to the external input interface.
A) Long does not explicitly disclose processor operations for determining at least one mitigation based on the at least one failure mode as:
determining at least one architectural mitigation and applying the at least one architectural mitigation to reduce an effect of the at least one failure mode.
Similar to preventing vulnerabilities incursion into a storage of assets by Long, Chitra disclose effect of simulating operation interacting with a blockchain system, using stress test to detect how the system is affected by responsive to the stress testing (para 0100) to evaluate metrics (latencies – para 0102) related to performance degradation under prolonged duress simulation (para 0064) to estimate effect of changes to various security efficiency (para 0062-0063) for platform operators to optimize architectural consideration of a blockchain protocol (para 0019), promote architectural choices in achieving goals (para 0024) from architectural standpoint; e.g. tuning numerical parameters of the simulation in line with efficiency of the simulation and choices regarding architectural considerations and (para 0061), varying parameters values as part of censorship strategy governing blockchain operation as implementation in place for architectural measures (para 0184), the security aspect of simulation by the operator/designer exposing blockchain security to financial attacks, allowing potential vulnerabilities to be identified and attack to be avoided before it occurs (para 0185). Hence, measure to mitigate security attack and vulnerabilities issues to a system equipped with simulation and parametric refining thereof as architectural consideration or selected choices to mitigate the attack before they occur entails determining at least one architectural mitigation and applying the at least one such architectural mitigation to reduce an effect of the at least one failure mode such as security attack to a blockchain architecture or operation.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement simulated test for effect of mitigating and preventing vulnerabilities threat into persisted component or library asset in Long’s SAST system so that responsive to determination of at least one failure mode or type of untrusted incursion into the storage/library system, the SAST, the system would determine and elect considerations in terms of architectural measure – such as in Chitra blockchain system– implemented as at least one architectural mitigation and applying the at least one architectural mitigation to reduce an effect of the at least one failure mode such as vulnerabilities attacks as shown in Chitra via implementation of simulation-based testing; because
consideration of preventive implementation or programmatic measures taken at an architectural level to provide metrics via architecture wide implementation of tests or simulation as set forth above, with which to timely identify potential vulnerability issues, or foresee security threats with respect to a system wide SW store or a architecture level management of assets such as the security vulnerability prevention in Long, so to implement architectural type of mitigations specifically designed or configured to forestall or prevent threats such as uncontrolled pass-through thereof, infliction of damage to the system or corruption the assets therein, would afford assets and SW components under the secure maintenance of the system to be protected not only at the local level where components from individual tenants can be timely protected from local level vulnerabilities insurgence; but also at the business enterprise or architectural level, where system maintained components, shared library, containers as well as subscriber assets can be equally pre-scanned, simulated at respective point of entry – such as in Long and Chitra; and accordingly protected from external intrusion of entities or component that are deemed untrusted, or maliciously intrusive and damaging to the integrity of the assets under large scale protection and management by the system .
As per claim 2, Long disclosed non-transitory computer-readable medium of claim 1, wherein the at least one failure mode includes
a first failure mode associated with a complexity of logic in the external input interface,
a second failure mode associated with mismanagement of data or hardware resources ( result in a software vulnerability if untrusted data is passed into the entry point – para 0020), and
a third failure mode associated with misbehavior of invoked interfaces of dependencies 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; all possible data path through the 3rd party component is analyzed – para 0016).
As per claim 3, Long does not explicitly disclose non-transitory computer-readable medium of claim 2, wherein the at least one architectural mitigation includes
(i) a first architectural mitigation configured to resolve a problem in the complexity of the logic in the external input interface,
(ii) a second architectural mitigation configured to resolve the mismanagement of the data or the hardware resources, and
(iii) a third architectural mitigation configured to resolve the misbehavior of the invoked interfaces of the dependencies of the external input interface.
As for (ii) and (iii)
As for providing a architecture level of simulation to improve efficiency in identifying vulnerability issues, Chitra discloses stress test and monitored simulation as measure to make prediction on roles or smart-contract affecting secure performance of a blockchain or fair rewards on its users/stakeholders (para 0064-0065), or to account for operators/users with no-incentive, or malicious intents relative to a objective function (para 0110-0111), such as to detect flaw by malicious actors adding an improper entry into a ledger (para 0036). Hence, implementation of mitigation in form of test and simulation with metrics monitoring to track and identify misuse by operators, users and stakeholder entails mitigation software to resolve vulnerability to the system in accordance with mismanaging of resources or misbehavior by the entities maliciously interfacing with entry points into the system.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement resolution to threats associated with vulnerability to performance and safety of stored assets in Long so that at least one architectural mitigation includes one form of mitigation configured to resolve the mismanagement of the data – as set forth in the ill-use or mismanagement of resources by operators/users in Chitra blockchain system - and one form configured to resolve misbehavior of the invoked interfaces, by actors and operational dependencies affecting entry points to the system – as per malicious operators entering improper entry to ledger of the Chitra system; because
improper use of resources or mismanagement by the system allowing ill use of, unapproved interaction with system resources by different actors, business contracts or workflow entities, unapproved intents that breach the safety protection by the system, without timely implementation of mitigation measures as set forth above, can lead to degradation to the usability of resources made available by the system, including ill-effects, damaging inroads affecting one or more management features such as fairness of use and availability thereof, the secure access of resources, management on permission granting and expected performance of the system in servicing the users, as well as cost incurred by the system to actuate operational recovery caused by the security setbacks, misuse by mal-intent behavior or unchecked exploitation by the entities that pass as eligible for access to the resources via respective entry points but in fact operate as unauthorized, malicious actors that inflict vulnerability attack to the system resources.
As per claim 5, Long discloses non-transitory computer-readable medium of claim 1, wherein the operations further comprise:
determining a dependency (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) of the external input interface;
valuating the dependency (see 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 one or more failure modes associated with the dependency, determining the adjusted compile-time parameters and adjusted runtime parameters (para 0041-0043 ; para 0049-0050, para 0056 - refer to Note2) based on the one or more failure modes associated with the dependency (see above).
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);
evaluating the dependency for a corresponding failure mode (see claim 2); and
in response to detecting one or more failure modes associated with the dependency, determining the at least one architectural mitigation (refer to rationale of claim 3) based on the one or more failure modes associated with the dependency.
As per claim 8, Long discloses a 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;
determining at least one failure mode associated with the external input interface;
determining adjusted compile-time parameters and adjusted runtime parameters based on the at least one failure mode;
determining at least one architectural mitigation based on the at least one failure mode, the at
least one architectural mitigation being configured to reduce an effect of the at least one failure
mode; and
applying the at least one architectural mitigation to the external input interface.
(all of which having been addressed in claim 1)
As per claim 9, Long discloses method of claim 8, wherein the at least one 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 claim 2)
As per claim 10, Long discloses method of claim 9, wherein the at least one architectural mitigation includes a first architectural mitigation configured to resolve a problem in the complexity of the logic in the external input interface, a second architectural mitigation 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 rejection of claim 5.
As per claim 13, refer to rejection of 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;
determining at least one failure mode associated with the external input interface;
determining adjusted compile-time parameters and adjusted runtime parameters based on the at least one failure mode;
determining at least one architectural mitigation based on the at least one failure mode, the at least one architectural mitigation being configured to reduce an effect of the at least one failure mode; and
applying the at least one architectural mitigation to the external input interface.
(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 one or more failure modes associated with the dependency; (refer to claim 5 or 6)
determining the adjusted compile-time parameters and adjusted runtime parameters based on the one or more failure modes associated with the dependency; (refer to claim 5) and
determining the at least one architectural mitigation based on the one or more failure modes
associated with the dependency (refer to claim 6)
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 USPubN: 2020/0167512 (herein Chitra), further in view of 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:
determining whether the safety requirements are correct; and
updating the safety requirements in response to determining that there is a missing or extraneous safety requirement.
But rules involved in generating simulated tainted data (para 0033- 0034) as part of pass-through interacting with entry points by external SW components into a library system is shown in Long are rules that can be customized per need to implement each test (para 0022-0024) under the analysis, result scanning or flagging by a SAST layer; 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 3rd 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 3rd party component. Hence, generating additional rule indicative of safety requirements needed to implement an adjusted/more correct exposure of insecure attempts by external component affecting a host system entails determination if there is a missing safety requirement and accordingly generating new requirement to update the set of custom safety requirements.
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, based on scenario where additional rule be generated to account for incorrect (test results) assessment of false positives in Long, it would have been obvious at the time of the invention for one skill in the art to implement customizing vulnerability test and safety requirements associated therewith in Long so that custom rules indicative of these requirements can be updated – per Benjamin adding of rules - according to need/insufficiency of the vulnerability test, including updating the safety requirements or rules – as in Benjamin - in response to determining that there is a missing or extraneous safety requirement, on basis of recognizing if the safety requirements provided as rules are correct or in need for update; because
an intrusion and vulnerability detection/prevention system equipped with a comprehensive set of safety rules and requirements that at a given instant covers large complexity aspect or extensive scope on vulnerability attack or variety thereof, and further integrated with systemic flexibility to update, remove or add new rules or requirement intended as implementation guidance for implement software associated with intrusion detection and the vulnerability-assessment component as set forth above, would impart a degree of confidence to the users of the system when assets and application data relevant to users endeavors, interaction with the system, and business operations are expected to be properly maintained and administered via preventive maintenance and secure protection by the system, under service provision under SLA and provisioning claim of QAS.
As per claim 11, refer to rationale of claim 4.
As per claim 18, refer to rationale of claim 4.
Claims 7, 14, 20 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Long et al, USPubN: 2024/0121261 (herein Long) in view of USPubN: 2020/0167512 (herein Chitra) further in view of Tahan, USPubN: 2009/0150899 (herein Tahan)
As per claim 7, Long discloses 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 mitigation based on the failure modes.
All possible data path through which a 3rd component interface with a library system via entry points is under analysis of the SAST in Long for effect to indicate possible security vulnerabilities incurred with the 3rd 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); hence 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 3rd 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.
As per claim 20, refer to rationale of claim 7.
Conclusion
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.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/Tuan A Vu/
Primary Examiner, Art Unit 2193
February 07, 2026