Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This is the initial office action based on the application filed on July 5th, 2023, which claims 1-20 are presented for examination.
Status of Claims
Claims 1-20 are pending in the application and have been examined below, of which, claims 1, 13, and 20 are presented in independent form.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Internet E-mail
A written authorization by Applicant is required for the Examiner to respond via
internet e-mail to any Internet correspondence which contains information subject to the
confidentiality requirement as set forth in 35 U3.0. 122, such as proposed Examiner’s
Amendments or interview agenda items (MPEP 502.03; See Internet Usage Policy, 64
PR 33056 (June 21, 1999)). To authorize e-mail communications from the Examiner
(e.g. proposed Examiner’s Amendments), the Applicant must place a written
authorization in the record. Applicant may authorize electronic and email communication
by the Examiner via PTO Automated Interview Request web service. To schedule an
interview, applicant is encouraged to use the USPTO Automated Interview Request
(AER) at http://www.uspto.gov/interviewpractice.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on February 3rd, 2025 and December 31st, 2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Allowable Subject Matter
Claims 8-9 and 12 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim Objections
Claims 6-7 and 17-18 are objected to because of the following informalities:
Claims 6 and 17 recite the limitation “the particular portion of the program” in line 2. The limitation should be -- the particular portion of the program code --.
Claims 7 and 18 depend on claims 6 and 17, respectively, but not cure the deficiencies of those claims. Accordingly, they are objected for the same reasons.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-7, 10-11, 13-18, and 17-20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claims 1-12 are directed to methods and fall within the statutory category of processes; Claims 13-19 are directed to systems and fall within the statutory category of machines; and Claim 20 is directed to tangible computer-readable medium and falls within the statutory category of articles of manufacture. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Claims 1, 13, and 20: recite the limitations of “
generating, by a processor, a modeling language diagram that is indicative of a compiled version of program code, wherein the modeling language diagram comprises at least one node corresponding to at least one function in the program code;
identifying, by the processor, at least one function signature associated with a node state transition between nodes in the modeling language diagram;
identifying, by the processor and using a large language model, a particular policy to attribute to the at least one function signature associated with the node state transition; and
performing, by the processor and using the large language model, a policy compliance operation that ensures a particular portion of the program code complies with the particular policy, wherein the particular portion of the program code is associated with the node state transition, and wherein performing the policy compliance operation comprises generating a policy-compliant version of the particular portion of the program code.”
Step 2A Prong 1:
Steps (a), (b) and (c) as drafted, can be done in human mind with the aid of pen and paper (mental process).
Step 2A Prong 2:
Claims 1, 13, and 20: The judicial exception is not integrated into a practical application. In particular, the claims recite the following additional elements – “processor,” “modeling language diagram,” “compiled version of program code,” “a large language model,” “system,” “memory,” “non-transitory computer-readable medium,” and “instructions that, when executed by a processor,”, which are merely recitations of generic computing components and functions merely applying the abstract idea using (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application. Furthermore, step (d) is merely applying the abstract idea and field of use/technological environment.
Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
After having evaluating the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1, 13, and 20 not only recite a judicial exception but that the claim is directed to the judicial exception as the judicial exception has not been integrated into practical application.
Step 2B:
Claims 1, 13, and 20: The additional elements, considering them both individually and in combination, do not amount to significantly more than the judicial exception.
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, claims 1, 13, and 20 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Regarding claims 2 and 14, the claims recite additional element recitations of “generating, by the processor and using the large language model, one or more security controls; generating, by the processor, a policy-compliant version of the node state transition based on the one or more security controls; and generating, by the processor, an updated version of the modeling language diagram based on the policy-compliant version of the node state transition” which is merely a field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate the judicial exception into practical application. Moreover, claims 2 and 14 do not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 2 and 14 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as they have not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, claims 2 and 14 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Regarding claims 3 and 15, the claims recite additional element recitations of “generating, by the processor using the large language model, policy-compliant program code based on data from a policy-compliant version of the node state transition, and wherein the policy-compliant program code corresponds to the policy-compliant version of the particular portion of the program code; and modifying, by the processor, the particular portion of the program code based on the policy-compliant program code” which is merely a field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate the judicial exception into practical application. Moreover, claims 3 and 15 do not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 3 and 15 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as they have not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, claims 3 and 15 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Regarding claim 4, the claim recites additional element recitations of “wherein an input to the large language model includes the particular portion of the program code” which is merely a field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate the judicial exception into practical application. Moreover, claim 4 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 4 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, claim 4 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Regarding claims 5 and 16, the claims recite additional element recitations of “replacing the particular portion of the program code with the policy-compliant program code” which is merely a field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate the judicial exception into practical application. Moreover, claims 5 and 16 do not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 5 and 16 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as they have not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, claims 5 and 16 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Regarding claims 6 and 17, the claims recite additional element recitations of “wherein a user is prompted to approve the policy-compliant program code prior to modifying the particular portion of the program based on the policy-compliant program code” which is merely a field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate the judicial exception into practical application. Moreover, claims 6 and 17 do not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 6 and 17 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as they have not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, claims 6 and 17 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Regarding claims 7 and 18, the claims recite additional element recitations of “wherein the particular portion of the program code is modified based on the policy-compliant program code in response to the user approving the policy-compliant program code” which is merely a field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate the judicial exception into practical application. Moreover, claims 7 and 18 do not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 7 and 18 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as they have not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, claims 7 and 18 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Regarding claim 10, the claim recites additional element recitations of “wherein the modeling language diagram comprises a Unified Modeling Language (UML) diagram” which is merely a field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate the judicial exception into practical application. Moreover, claim 10 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 10 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, claim 10 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Regarding claim 11, the claim recites additional element recitations of “wherein the particular policy corresponds to a security policy” which is merely a field of use/technological environment (see MPEP § 2106.05(h)) which does not integrate the judicial exception into practical application. Moreover, claim 11 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 11 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, claim 11 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim Rejections - 35 U.S.C § 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-7, 1-11, 13-18, and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over Kulkarni et al. (Pub. No.: US 2019/0238563 – hereinafter, Kulkarni – IDS filed 12/31/2025) in view of Alpern et al. (Pub. No.: US2005/0015752 – hereinafter, Alpern – IDS filed 2/3/2025) and further in view of Licato (Pub. No.: US 2024/0311619 – hereinafter, Licato).
Regarding claim 1:
Kulkarni discloses a method comprising:
generating, by a processor, a modeling language diagram that is indicative of a compiled version of program code, wherein the modeling language diagram comprises at least one node corresponding to at least one function in the program code (FIG. 2 and associated text, such as, “Disassembler 220 receives application binaries 210, such as racinggame.apk, and constructs a model of program logic, for example from the byte code. Application binaries may also include assembly instructions, scripts, macros, and other executable objects by way of non-limiting example… This results in application logic model (ALM) 250, which is provided to a behavioral heuristics and rules engine (BHRE) 280… ALM 250 may model application logic in memory to identify malicious behavior, for example by stepping through the model. ALM 250 may include data flow structures and control flow structures” (See paras [0034] – [0035]));
identifying, by the processor, at least one function [[signature associated with a node state transition between nodes]] in the modeling language diagram (“<Rule><Run><Dataflow><ReadOperation>of <red subsystem>to a <WriteOperation>of <any subsystem>” (See para [0038]). FIG. 2 and associated text, such as, “BHRE 280 may include rules that enable recognition of definite sequences of code as performing a given function, or that enable it to recognize that certain sequences of behavior are usually associated with a given action.” (See para [0045]). FIG. 6 and associated text, such as, “In block 620, remediation engine 200 disassembles the executable object to identify potentially harmful logic, subroutines, or behavior.” (See para [0080]));
identifying, by the processor and [[using a large language model]], a particular policy to attribute to the at least one function (“In the foregoing application, the XML object ‘Policies’ indicates that the object includes policies for one or more applications such as racinggame.apk, each identified by a ‘PackageName’ object, such as ‘com.software.racinggame’ and ‘walkingtexter’ in this example. Each package includes one or more policies, identified by ‘Policy’ objects, which identify a ‘Behavior’ (such as SMS leak, international mobile equipment identity (IMEI) leak, contacts leak, location leak, or similar). A policy may also include a ‘Destination’ object, indicating for example where leaked information is delivered to, as well as a ‘DestinationStatus,’ which may contain a reputation for the destination. For example, if the destination is a known malware author, the destination status may be designated ‘Harmful,’ whereas if the destination is legitimate, the status may be ‘Harmless.’ For unknown destinations, the status may be ‘Unknown.’ Numerous other grades and variations of destinations are also possible, including for example ‘Grayware,’ ‘Suspect,’ ‘Adware,’ or other similar designations.” (See para [0062])) [[signature associated with the node state transition]]; and
performing, by the processor and [[using the large language model]], a policy compliance operation that ensures a particular portion of the program code complies with the particular policy, [[wherein the particular portion of the program code is associated with the node state transition]], and wherein performing the policy compliance operation comprises generating a policy-compliant version of the particular portion of the program code (FIG. 6 and associated text, such as, “ In block 630, remediation engine 200 rebuilds the logic in a more desirable way. In block 640, remediation engine 200 builds a behavior model, which may be structured in XML as described above. Notably, in some cases, only one of block 630 and block 640 are necessary. In this specification, when remediation engine rebuilds the actual application binary, which may include altering behavior or inserting operating system control hooks, it is referred to as ‘healing’ the application.” (See para [0080])).
But Kulkarni does not explicitly teach:
function signature associated with a node state transition between nodes;
identifying, using a large language model, a particular policy;
However, Alpern discloses:
function signature associated with a node state transition between nodes (FIG. 7 and associated text, such as, “Specifically, given the inter procedural control flow graph (or one of its subgraphs) 710, a graph traversal as depicted at step 720 is performed to add or remove edges respectively to extend or reduce reachability in the manner as described herein. In one example depicted, the reachability traversal of the graph 730 is implemented to search for a node attribute which is the method whose signature is X. When X is found, a report is generated. The difference between the two rules, ‘Never Call X’ and ‘Never Call X from Y’ is the selection of the head node(s) from where the graph traversal is initiated.” (See para [0061]). FIG. 8 and associated text, such as, “FIG. 8 outlines a SABER rule that checks whether a set of methods are being called when a monitor may be held by the thread of execution. This rule may be referred to as ‘Never Call X When Synchronized’. Given the inter procedural control flow graph (or one of its subgraphs) 810, a graph traversal is first performed at step 820 to add or remove edges to respectively extend or reduce reachability. Synchronization is then computed at those call sites where synchronization (i.e., monitors possibly held by the thread) may occur as indicated at step 830. Using the inter procedural control flow graph, it is determined whether method X is called, i.e., is reachable in the traversed graph, at step 840. If X is reachable, it is determined at step 850 whether the thread at the call site may hold a monitor 850. If a monitor is held at the call site, a report is generated indicating synchronization” (See para [0062]));
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Alpern into the teachings of Kulkarni because that would have provided a technique for applying the new set of rules to any given application is greatly simplified. Such a categorization permits the easy extension of the set of rules to new Best Practices as they are discovered and simplifies the application of the new set of rules to any given application as suggested by Alpern (See para [0015]).
Kulkarni and Alpern do not explicitly teach:
identifying, using a large language model, a particular policy;
However, Licato discloses:
identifying, using a large language model, a particular policy (“A study was performed using implementations of the present disclosure to perform rule analysis using machine learning models, including large language models. Given a set of rules expressed in real-world regulatory language and an action, can state-of-the-art large language models determine whether the action is permissible? If not, why not, and what additional information is needed before they can perform this task well? These questions are of significant interest for developing machine learning models that can be used for applications requiring consistent formal outputs. Existing work studying how well LMs can interpret those rules focuses on a narrow set of domains, with little focus on cases where those rules have the complexity of real-world legal systems” (See para [0114]));
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Licato into the teachings of Kulkarni and Alpern because that would have provided techniques for structuring and analyzing formal data (e.g., the patterns in a simulation) using trained machine learning models. Methods of structuring the inputs to machine learning models improve the accuracy of those models by providing formal inputs that can be mapped to formal outputs (e.g., data to machine code) as suggested by Licato (See para [0049]).
Regarding claim 2:
The rejection of claim 1 is incorporated, Kulkarni further discloses wherein performing the policy compliance operation comprises:
generating, by the processor and [[using the large language model]], one or more security controls (“In block 440, client device 130 acts on remedial data received from remediation server 110. In some cases, the action may be simply replacing the original application binary with a modified application binary provided by remediation server 110… If, on the other hand, racinggame.apk requires access to SMS for some legitimate functions but abuses its SMS privileges by sending spam SMS messages, then operating system hooks may be inserted to selectively block only certain subroutines from SMS, or a firewall rule or similar may be provided to either block racinggame.apk from sending SMS to specified addresses (blacklisting), or to allow racinggame.apk to send SMS only specified addresses (whitelisting).” (See para [0074]));
generating, by the processor, a policy-compliant version of the [[node state transition]] based on the one or more security controls (FIG. 6 and associated text, such as, “In block 630, remediation engine 200 rebuilds the logic in a more desirable way. In block 640, remediation engine 200 builds a behavior model, which may be structured in XML as described above. Notably, in some cases, only one of block 630 and block 640 are necessary. In this specification, when remediation engine rebuilds the actual application binary, which may include altering behavior or inserting operating system control hooks, it is referred to as ‘healing’ the application.” (See para [0080])); and
generating, by the processor, an updated version of the modeling language diagram based on the policy-compliant version of [[the node state transition]] (FIG. 6 and associated text, such as, “In block 630, remediation engine 200 rebuilds the logic in a more desirable way. In block 640, remediation engine 200 builds a behavior model, which may be structured in XML as described above. Notably, in some cases, only one of block 630 and block 640 are necessary. In this specification, when remediation engine rebuilds the actual application binary, which may include altering behavior or inserting operating system control hooks, it is referred to as ‘healing’ the application.” (See para [0080])).
But Kulkarni does not explicitly teach:
a node state transition between nodes;
using a large language model;
However, Alpern discloses:
a node state transition between nodes (FIG. 7 and associated text, such as, “Specifically, given the inter procedural control flow graph (or one of its subgraphs) 710, a graph traversal as depicted at step 720 is performed to add or remove edges respectively to extend or reduce reachability in the manner as described herein. In one example depicted, the reachability traversal of the graph 730 is implemented to search for a node attribute which is the method whose signature is X. When X is found, a report is generated. The difference between the two rules, ‘Never Call X’ and ‘Never Call X from Y’ is the selection of the head node(s) from where the graph traversal is initiated.” (See para [0061]));
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Alpern into the teachings of Kulkarni because that would have provided a technique for applying the new set of rules to any given application is greatly simplified. Such a categorization permits the easy extension of the set of rules to new Best Practices as they are discovered and simplifies the application of the new set of rules to any given application as suggested by Alpern (See para [0015]).
Kulkarni and Alpern do not explicitly teach:
using a large language model;
However, Licato discloses:
using a large language model (“A study was performed using implementations of the present disclosure to perform rule analysis using machine learning models, including large language models. Given a set of rules expressed in real-world regulatory language and an action, can state-of-the-art large language models determine whether the action is permissible? If not, why not, and what additional information is needed before they can perform this task well? These questions are of significant interest for developing machine learning models that can be used for applications requiring consistent formal outputs. Existing work studying how well LMs can interpret those rules focuses on a narrow set of domains, with little focus on cases where those rules have the complexity of real-world legal systems” (See para [0114]));
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Licato into the teachings of Kulkarni and Alpern because that would have provided techniques for structuring and analyzing formal data (e.g., the patterns in a simulation) using trained machine learning models. Methods of structuring the inputs to machine learning models improve the accuracy of those models by providing formal inputs that can be mapped to formal outputs (e.g., data to machine code) as suggested by Licato (See para [0049]).
Regarding claim 3:
The rejection of claim 1 is incorporated, Kulkarni further discloses wherein performing the policy compliance operation comprises:
generating, by the processor [[using the large language model]], policy-compliant program code based on data from a policy-compliant version of [[the node state transition]], and wherein the policy-compliant program code corresponds to the policy-compliant version of the particular portion of the program code (FIG. 6 and associated text, such as, “Blocks 620, 630, and 640 represent operations that, in some embodiments, are carried out by remediation engine 200. In block 620, remediation engine 200 disassembles the executable object to identify potentially harmful logic, subroutines, or behavior. In block 630, remediation engine 200 rebuilds the logic in a more desirable way. In block 640, remediation engine 200 builds a behavior model, which may be structured in XML as described above. Notably, in some cases, only one of block 630 and block 640 are necessary. In this specification, when remediation engine rebuilds the actual application binary, which may include altering behavior or inserting operating system control hooks, it is referred to as ‘healing’ the application. When remediation engine 200 instead uses external control to modify the application, it is referred to herein as ‘personalizing’ the applications behavior. In some cases, an application may be both healed and personalized, in other cases, an application is either healed or personalized, and in yet other cases, neither is necessary.” (See para [0080])); and
modifying, by the processor, the particular portion of the program code based on the policy-compliant program code (FIG. 6 and associated text, such as, “Blocks 620, 630, and 640 represent operations that, in some embodiments, are carried out by remediation engine 200. In block 620, remediation engine 200 disassembles the executable object to identify potentially harmful logic, subroutines, or behavior. In block 630, remediation engine 200 rebuilds the logic in a more desirable way. In block 640, remediation engine 200 builds a behavior model, which may be structured in XML as described above. Notably, in some cases, only one of block 630 and block 640 are necessary. In this specification, when remediation engine rebuilds the actual application binary, which may include altering behavior or inserting operating system control hooks, it is referred to as ‘healing’ the application. When remediation engine 200 instead uses external control to modify the application, it is referred to herein as ‘personalizing’ the applications behavior. In some cases, an application may be both healed and personalized, in other cases, an application is either healed or personalized, and in yet other cases, neither is necessary.” (See para [0080])).
But Kulkarni does not explicitly teach:
a node state transition between nodes;
using a large language model;
However, Alpern discloses:
a node state transition between nodes (FIG. 7 and associated text, such as, “Specifically, given the inter procedural control flow graph (or one of its subgraphs) 710, a graph traversal as depicted at step 720 is performed to add or remove edges respectively to extend or reduce reachability in the manner as described herein. In one example depicted, the reachability traversal of the graph 730 is implemented to search for a node attribute which is the method whose signature is X. When X is found, a report is generated. The difference between the two rules, ‘Never Call X’ and ‘Never Call X from Y’ is the selection of the head node(s) from where the graph traversal is initiated.” (See para [0061]));
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Alpern into the teachings of Kulkarni because that would have provided a technique for applying the new set of rules to any given application is greatly simplified. Such a categorization permits the easy extension of the set of rules to new Best Practices as they are discovered and simplifies the application of the new set of rules to any given application as suggested by Alpern (See para [0015]).
Kulkarni and Alpern do not explicitly teach:
using a large language model;
However, Licato discloses:
using a large language model (“A study was performed using implementations of the present disclosure to perform rule analysis using machine learning models, including large language models. Given a set of rules expressed in real-world regulatory language and an action, can state-of-the-art large language models determine whether the action is permissible? If not, why not, and what additional information is needed before they can perform this task well? These questions are of significant interest for developing machine learning models that can be used for applications requiring consistent formal outputs. Existing work studying how well LMs can interpret those rules focuses on a narrow set of domains, with little focus on cases where those rules have the complexity of real-world legal systems” (See para [0114]));
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Licato into the teachings of Kulkarni and Alpern because that would have provided techniques for structuring and analyzing formal data (e.g., the patterns in a simulation) using trained machine learning models. Methods of structuring the inputs to machine learning models improve the accuracy of those models by providing formal inputs that can be mapped to formal outputs (e.g., data to machine code) as suggested by Licato (See para [0049]).
Regarding claim 4:
The rejection of claim 3 is incorporated, Kulkarni further discloses wherein an input to the large language model includes the particular portion of the program code (FIG. 7 and associated text, such as, “In block 730, if healing is available and is elected by the user, then in block 760 then the application is provided to modification engine 760. Modification engine 760 may be a separate logical method or device, or may be logical portions of remediation engine 200 that are configured to handle healing. In an example, remediation engine 200 may include platform API intelligence 270, GTI 290, and parts of BHRE 280.” (See para [0086])).
Regarding claim 5:
The rejection of claim 3 is incorporated, Kulkarni further discloses wherein modifying the particular portion of the program code comprises replacing the particular portion of the program code with the policy-compliant program code (FIG. 6 and associated text, such as, “Blocks 620, 630, and 640 represent operations that, in some embodiments, are carried out by remediation engine 200. In block 620, remediation engine 200 disassembles the executable object to identify potentially harmful logic, subroutines, or behavior. In block 630, remediation engine 200 rebuilds the logic in a more desirable way. In block 640, remediation engine 200 builds a behavior model, which may be structured in XML as described above. Notably, in some cases, only one of block 630 and block 640 are necessary. In this specification, when remediation engine rebuilds the actual application binary, which may include altering behavior or inserting operating system control hooks, it is referred to as ‘healing’ the application. When remediation engine 200 instead uses external control to modify the application, it is referred to herein as ‘personalizing’ the applications behavior. In some cases, an application may be both healed and personalized, in other cases, an application is either healed or personalized, and in yet other cases, neither is necessary.” (See para [0080])).
Regarding claim 6:
The rejection of claim 3 is incorporated, Kulkarni further discloses wherein a user is prompted to approve the policy-compliant program code prior to modifying the particular portion of the program based on the policy-compliant program code (FIG. 7 and associated text, such as, “In block 712, if an application is designated as ‘good,’ then the user may be prompted whether to install the application. Note that because existing remediation data may have already been retrieved from remediation database 140, this prompting still may involve operations from remediation client software 322.” (See para [0084])).
Regarding claim 7:
The rejection of claim 6 is incorporated, Kulkarni further discloses wherein the particular portion of the program code is modified based on the policy-compliant program code in response to the user approving the policy-compliant program code (FIG. 7 and associated text, such as, “In block 712, if an application is designated as ‘good,’ then the user may be prompted whether to install the application. Note that because existing remediation data may have already been retrieved from remediation database 140, this prompting still may involve operations from remediation client software 322.” (See para [0084])).
Regarding claim 10:
The rejection of claim 1 is incorporated, Kulkarni further discloses wherein the modeling language diagram comprises a Unified Modeling Language (UML) diagram (FIG. 2 and associated text, such as, “Disassembler 220 receives application binaries 210, such as racinggame.apk, and constructs a model of program logic, for example from the byte code. Application binaries may also include assembly instructions, scripts, macros, and other executable objects by way of non-limiting example… This results in application logic model (ALM) 250, which is provided to a behavioral heuristics and rules engine (BHRE) 280… ALM 250 may model application logic in memory to identify malicious behavior, for example by stepping through the model. ALM 250 may include data flow structures and control flow structures” (See paras [0034] – [0035])).
Regarding claim 11:
The rejection of claim 1 is incorporated, Kulkarni further discloses wherein the particular policy corresponds to a security policy (“In block 440, client device 130 acts on remedial data received from remediation server 110. In some cases, the action may be simply replacing the original application binary with a modified application binary provided by remediation server 110… If, on the other hand, racinggame.apk requires access to SMS for some legitimate functions but abuses its SMS privileges by sending spam SMS messages, then operating system hooks may be inserted to selectively block only certain subroutines from SMS, or a firewall rule or similar may be provided to either block racinggame.apk from sending SMS to specified addresses (blacklisting), or to allow racinggame.apk to send SMS only specified addresses (whitelisting).” (See para [0074])).
Regarding claim 13:
This is a system version of the rejected method claim 1 above, wherein all the limitations of this claim have been noted in the rejection of claim 1, and is therefore rejected under similar rationale.
Regarding claim 14:
The rejection of base claim 13 is incorporated. All the limitations of this claim have been noted in the rejection of claim 2, and is therefore rejected under similar rationale.
Regarding claim 15:
The rejection of base claim 13 is incorporated. All the limitations of this claim have been noted in the rejection of claim 3, and is therefore rejected under similar rationale.
Regarding claim 16:
The rejection of base claim 13 is incorporated. All the limitations of this claim have been noted in the rejection of claim 5, and is therefore rejected under similar rationale.
Regarding claim 17:
The rejection of base claim 13 is incorporated. All the limitations of this claim have been noted in the rejection of claim 6, and is therefore rejected under similar rationale.
Regarding claim 18:
The rejection of base claim 13 is incorporated. All the limitations of this claim have been noted in the rejection of claim 7, and is therefore rejected under similar rationale.
Regarding claim 20:
This is a non-transitory computer-readable medium version of the rejected method claim 1 above, wherein all the limitations of this claim have been noted in the rejection of claim 1, and is therefore rejected under similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
De Peuter (Pub. No.: US 2021/0174032) discloses techniques for generating a compliance graph based on a compliance rule to implement in a software program product for determining user compliance. To generate a compliance graph, an encoder receives a compliance rule in a source language and generates a set of corresponding vectors. The decoder, which has been trained using verified training pairs and synthetic data, generates a sequence of operations based on the vectors from the encoder. The sequence of operations is the used to build a graph in which each operation is a node in the graph and each node is connected to at least one other node in the same graph or a separate graph.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HANH THI MINH BUI whose telephone number is (571)270-1976. The examiner can normally be reached Monday - Friday: 7-3.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S. Sough can be reached at 571-272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HANH THI-MINH BUI/Primary Examiner, Art Unit 2192 July 21st, 2026
Prosecution Insights