DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-13 are pending. Claims 1 and 12 are independent. Claims 1, 2, 5, 8, 10, 12, and 13 have been amended. No claims have been canceled. Amendment to the claims have been accepted.
Response to Arguments
Applicant’s arguments, see p.5 (p. 1 of Remarks), filed 10/09/2025, with respect to the objection(s) to claim(s) 1, 2, and 12 have been fully considered and are persuasive. The objection(s) to claim(s) 1, 2, and 12 has been withdrawn.
Applicant’s arguments, see pp.5-6 (pp. 1-2 of Remarks), filed 10/09/2025, with respect to the rejection(s) of claim(s) 1-13 under 35 U.S.C. § 112(a) have been fully considered and are persuasive. The rejection of claims 1-13 has been withdrawn.
Applicant’s arguments, see pp.5-6 (pp. 1-2 of Remarks), filed 10/09/2025, with respect to the rejection(s) of claim(s) 5, 8, and 10 under 35 U.S.C. § 112(b) have been fully considered and are persuasive. The rejection of claims 5, 8, and 10 has been withdrawn.
Applicant’s arguments, see pp. 6-12 (pp. 2-8 of Remarks), filed 10/09/2025, with respect to the rejection(s) of claim(s) 1, 5, and 12 under 35 U.S.C. § 103 as unpatentable over Amarasinghe (Amarasinghe et al., US 20060277539 A1) in view of Huang (Huang et al., US 8468595 B1) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of 35 U.S.C. § 103 as unpatentable over Amarasinghe in view of Jiang (JIANG et al., WO 2015117434 A1). The newly found prior art now accommodates for the limitations applicant argues were not present in the former prior art rejection.
Applicant’s arguments, see pp. 6-12 (pp. 2-8 of Remarks), filed 10/09/2025, with respect to the rejection(s) of claim(s) 2 and 3 under 35 U.S.C. § 103 as unpatentable over Amarasinghe in view of Huang, Kapoor (Kapoor et al., US 12244621 B1), and Mckee (McKEE et al., US 20130205415 A1), have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of 35 U.S.C. § 103 as unpatentable over Amarasinghe in view of Jiang and Kapoor.
Applicant’s arguments, see pp. 6-12 (pp. 2-8 of Remarks), filed 10/09/2025, with respect to the rejection(s) of claim(s) 4 under 35 U.S.C. § 103 as unpatentable over Amarasinghe in view of Huang and Kapoor have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of 35 U.S.C. § 103 as unpatentable over Amarasinghe in view of Jiang and Kapoor.
Applicant’s arguments, see pp. 6-12 (pp. 2-8 of Remarks), filed 10/09/2025, with respect to the rejection(s) of claim(s) 6 and 7 under 35 U.S.C. § 103 as unpatentable over Amarasinghe in view of Huang and Graf (‘eBPF: Rethinking the Linux kernel’, from the IDS) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of 35 U.S.C. § 103 as unpatentable over Amarasinghe in view of Jiang and Graf.
Applicant’s arguments, see pp. 6-12 (pp. 2-8 of Remarks), filed 10/09/2025, with respect to the rejection(s) of claim(s) 8 under 35 U.S.C. § 103 as unpatentable over Amarasinghe in view of Huang and Dynamic Linker (‘Dynamic linker’ article from Wikipedia, sourced Feb 21, 2021) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of 35 U.S.C. § 103 as unpatentable over Amarasinghe in view of Jiang and Dynamic Linker.
Applicant’s arguments, see pp. 6-12 (pp. 2-8 of Remarks), filed 10/09/2025, with respect to the rejection(s) of claim(s) 9 under 35 U.S.C. § 103 as unpatentable over Amarasinghe in view of Huang, Linker (‘Linker (computing)’ article from Wikipedia, sourced Feb 28, 2021), and Include Directive (‘Include directive’ article from Wikipedia, sourced Feb 19, 2021) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of 35 U.S.C. § 103 as unpatentable over Amarasinghe in view of Jiang, Linker, and Include Directive.
Applicant’s arguments, see pp. 6-12 (pp. 2-8 of Remarks), filed 10/09/2025, with respect to the rejection(s) of claim(s) 11 and 13 under 35 U.S.C. § 103 as unpatentable over Amarasinghe in view of Huang and Okihara (US 20160259944 A1) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of 35 U.S.C. § 103 as unpatentable over Amarasinghe in view of Jiang and Okihara.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1, 5 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Amarasinghe (Amarasinghe et al., US 20060277539 A1) in view of Jiang (JIANG et al., WO 2015117434 A1).
Regarding Claim 1 and substantially claim 12, Amarasinghe teaches a method for installing a mitigation program in a [kernel of] computing equipment to mitigate a vulnerability that may affect a function to be protected, the function running in a user space of said computing equipment (¶65, users protect applications (functions) using constraints (mitigation program)), the method comprising: sending a request including a unique identifier of said vulnerability to a security server (¶48, evidence that a particular vulnerability exists that identifies the vulnerability is sent to security laboratory (security server)); obtaining, in response to the request, a description file for describing said mitigation program (¶51, a constraint (mitigation program) is developed to detect the vulnerability and remediate against it. ¶59, "The constraint libraries 370 also include a constraint descriptor 376, discussed below in section 9." ¶51, "The constraints are extensively tested (step 150) before being released, e.g., to customers (step 155).", the constraints and the constraint descriptor (description files for describing mitigation program) are released to the customers for the identified vulnerability); obtaining object code of the mitigation program identified in said description file; (¶122, "A constraint injection system may require each constraint to provide machine instructions along with the constraint descriptor." , the constraint (mitigation program) is obtained along with its descriptor. ¶9, "The constraint code may include assembly code or machine instructions, for instance.", the code for the constraint can be assembly code (source code) or machine instructions (object code)) editing a link to resolve at least one symbol of the object code in order to generate executable code of said mitigation program specific to said computing equipment (¶124, the symbols of the machine code (object code) are resolved and linked for execution (executable code) by a loader. ¶28, the constraints targets a particular address in the application it is inserted (specific to the computing equipment)); said computing equipment including means to ensure that said mitigation program mitigates said vulnerability only for said function to be protected (¶227, "Constraints are built to fix the specific vulnerability in the application". ¶28, constraints have designated applications addressing only one vulnerability).
Amarasinghe does not teach but, in an analogous art, Jiang teaches installing the executable code in the kernel of said computing equipment (Jiang, p.5, "Optionally, the step of generating a patch module that replaces the replaced code according to the patch script includes: Converting the patch script into code of a predetermined type language and compiling it into a loadable kernel module; The kernel module is compiled into a patch module in the form of a binary program. "). Jiang also teaches means to ensure that said mitigation program mitigates said vulnerability only for said function to be protected (Jiang, p.14, “Step 102: Generate a patch module that replaces the replaced code according to the patch script. Step 103: Position a position of the replaced code in the source code to a start position and an end position of a corresponding instruction in the binary program, and add a start position and an end position of the corresponding instruction to the patch module.”)
It would be obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify Amarasinghe using Jiang to install the executable code in the kernel of said computing equipment because using a pre-defined kernel module, as a helper function, allows for smaller patches by replacing entire blocks of code with calls to the kernel module, improving efficiency (Jiang, p. 16, "The method provided in this embodiment can generate a patch for one or more lines of code in the source code. This patch can be used to replace one or more lines of code in the function source code to implement software upgrade; since the patch is made for the code line, the production process is simple and fast, and the software created by the invention is upgraded. Avoid replacing the entire function for a small problem, reducing the granularity of the repair of the program; in addition, applying the patch made by the method of the present invention can perform online upgrade of multiple functions in the original program, without considering the relationship between multiple functions. Mutual call relationship; compared with related technologies, it can improve the efficiency of software upgrade, reduce the complexity of patch production, and improve the security and reliability of patch upgrade.")
Regarding Claim 5, Amarasinghe in view of Jiang teaches the method of claim 1, wherein said description file includes an identifier of at least one support function (Amarasinghe, ¶121, Table 3 of Constraint Description, "Requires - A list of unique IDs (optional) - Constraints that are required in order to deploy this constraint", ¶55, "A predefined support functions library 350 represents the new constraints that get deployed similar to the way in which a signature of an anti-virus system is deployed, for instance.", the required constraints (with identifiers) can be considered support functions. ) that can be called by said program mitigation when executed by a processor of said computing equipment (Amarasinghe, ¶213, "The detector and remediator ABIs allow the detector and remediator, respectively, to call a predefined set of support functions,", ¶238, "FIG. 9 provides the source code (detector and protector functions) of the constraint.", the constraints (mitigation program) call on support functions. ¶84, an ABI is a description).
Claims 2 , 3, and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Amarasinghe in view of Jiang as applied to claim 1 and further in view of Kapoor (Kapoor et al., US 12244621 B1)
Regarding Claim 2, Amarasinghe in view of Jiang teaches the method of claim 1, further comprising: downloading a source code of said mitigation program (Amarasinghe, ¶144, "Users who wish to deploy the constraints, using a central management console, download the constraints and manage them, as discussed in connection with FIG. 4a. The controller 420 interfaces with a node manager at each server.", the constraints are downloaded. ¶9, the constraint code can be assembly code (source code)). Jiang further teaches compiling source code to obtain object code (Jiang, p.16, "For example, the patch script is translated into the C language code, and then the C language code is compiled and linked to generate a loadable kernel module; finally, the kernel module is compiled into a patch module in the form of a binary program.", the patch script is compiled, then linked, such that the intermediate stage of the code is object code) (see claim 1 for motivation to combine).
Amarasinghe in view of Jiang does not teach but, in an analogous art, Kapoor teaches downloading code from an address included in a description file (97:26-35, "Accordingly, in some embodiments, the remediation workflow may include links to download the client application for installation, descriptions for installation of the client application, and the like… the remediation workflow may include links to malware detection or remediation software, instructions for installation and use of such software, and the like", the client application (and thus, the code for it) is downloaded from a link in the workflow also containing a description for the application).
It would be obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify Amarasinghe in view of Jiang using Kapoor to download code from an address included in a description file because the remediation workflow mitigates potential harm to a user device (Kapoor, 97:12-17), and because using the description file for the process of downloading and installing the application allows for the user to follow instructions for purposes such as installation and confirmation of prior steps (Kapoor, 97:32-37).
Regarding Claim 3, Amarasinghe in view of Jiang and Kapoor teaches the method of claim 2. Kapoor further teaches that the source code is an eBPF language program (Kapoor, 63:42-43, "For example, Linux eBPF is mechanism for writing code to be executed in the Linux kernel space.") (see claim 2 for motivation to combine).
Regarding Claim 4, Amarasinghe in view of Jiang teaches the method of claim 1, further comprising: downloading said object code (Amarasinghe, ¶144, "Users who wish to deploy the constraints, using a central management console, download the constraints and manage them, as discussed in connection with FIG. 4a. The controller 420 interfaces with a node manager at each server.", the constraints are downloaded. ¶9, the constraint code can be machine instructions (object code)). Amarasinghe in view of Jiang does not teach but, in an analogous art, Kapoor teaches downloading code from an address included in a description file (97:26-35, "Accordingly, in some embodiments, the remediation workflow may include links to download the client application for installation, descriptions for installation of the client application, and the like… the remediation workflow may include links to malware detection or remediation software, instructions for installation and use of such software, and the like", the client application (and thus, the code for it) is downloaded from a link in the workflow also containing a description for the application).
It would be obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify Amarasinghe in view of Jiang using Kapoor to download code from an address included in a description file because the remediation workflow mitigates potential harm to a user device (Kapoor, 97:12-17), and because using the description file for the process of downloading and installing the application allows for the user to follow instructions for purposes such as installation and confirmation of prior steps (Kapoor, 97:32-37).
Claim 6 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Amarasinghe in view of Jiang as applied to claim 5 and further in view of Graf (‘eBPF: Rethinking the Linux kernel’, from the IDS received 9/1/2023)
Regarding Claim 6, Amarasinghe in view of Jiang teaches the method of claim 5, further comprising, before the editing of the link to resolve at least one symbol of the object code, verifying said at least one support function (Amarasinghe, Table 2, "Constraint_dll - Base name of constraint DLL or other library without path. Core assumes all DLLs will be in a DLL cache managed by Central Controller e.g., in a single directory. constraint_dll_hash - Hash value used by core to verify that "constraint_dll" hasn't been tampered with.d.", the libraries related the constraint are verified to have been tampered with or not. ¶59. "The constraint libraries 370 include a detector 372 and a remediator 374, which in turn may call a set of predefined functions from a predefined functions library 350.", the libraries that are verified include the support functions. Fig. 6, Hash Check 640, Match, Deploy Patch Point 650, hash checking is performed before the patch is deployed. ¶256, ¶124, the patch/constraint deployment is code insertion/injection, which occurs before linking).
Amarasinghe in view of Jiang does not teach but, in an analogous art, Graf teaches before the editing of the link to resolve at least one symbol of the object code, verifying that said at least one support function is installed in said kernel (Graf, 'eBPF', p.7, "The kernel will then take this program and will pass it through the BPF verifier. The verifier will ensure that the program is actually safe to run … if the BPF program is buggy or has some flaw, it cannot crash the kernel, the verifier will ensure that the program is safe to run.", the verifier ensures that the program can successfully run. 'Helpers', p.8, "If a function is being removed and your kernel module relies on it, the kernel module will no longer compile and if you load it, it will not load it, it will say, "I cannot resolve a certain symbol name."", a flaw with the program can be whether a helper function is installed on the kernel.)
It would be obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify Amarasinghe in view of Jiang using Graf to verify that said at least one support function is installed in said kernel because verification ensures that the program is safe to run ('eBPF', p.7, "The kernel will then take this program and will pass it through the BPF verifier. The verifier will ensure that the program is actually safe to run).
Regarding Claim 7, Amarasinghe in view of Jiang and Graf teaches the method of claim 6, wherein verifying includes verifying a hash of said support function included in said description file (Amarasinghe, Table 2, (Constraint Description), "Constraint_dll - Base name of constraint DLL or other library without path. Core assumes all DLLs will be in a DLL cache managed by Central Controller e.g., in a single directory. constraint_dll_hash - Hash value used by core to verify that "constraint_dll" hasn't been tampered with.d.", the libraries related the constraint are verified to have been tampered with or not using a hash in the description. ¶59. "The constraint libraries 370 include a detector 372 and a remediator 374, which in turn may call a set of predefined functions from a predefined functions library 350.", the libraries that are verified include the support functions) (see claim 6 for motivation to combine). As Graf suggests verifying that said at least one support function is installed in said kernel in claim 6, Amarasinghe in view of Jiang and Graf teaches the method of claim 6, wherein verifying that said at least one support function is installed in said kernel includes verifying a hash of said support function included in said description file.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Amarasinghe in view of Jiang as applied to claim 5 and further in view of Dynamic Linker (‘Dynamic linker’ article from Wikipedia, sourced Feb 21, 2021).
Regarding Claim 8, Amarasinghe in view of Jiang teaches the method of claim 5. Amarasinghe in view of Jiang does not teach the rest of claim 8. In an analogous art, Dynamic Linker teaches that the source code of the mitigation program includes a static function for calling said support function,
a call to said static function being replaced by a call to a dynamic function during the editing of the link to resolve at least one symbol of the object code ('Dynamic linker', p.1, "In computing, a dynamic linker is the part of an operating system that loads and links the shared libraries needed by an executable when it is executed (at "run time"), by copying the content of libraries from persistent storage to RAM, filling jump tables and relocating pointers…. a dynamic linker is a special part of an operating system that loads external shared libraries into a running process and then binds those shared libraries dynamically to the running process.", external shared libraries (static functions) are linked dynamically (dynamic functions) to fill a jump table (call to static function being replaced with a call to a dynamic function). 'macOS and iOS', p.3, "… it is even known that an executable might interact with the dynamic linker, causing it to load more libraries and resolve more symbols… ", the loading of libraries and actions of the dynamic linker resolves symbols).
It would be obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify Amarasinghe in view of Jiang using Dynamic Linker to implement a dynamic linker to replace static calls to libraries (static functions) with calls to dynamic functions in dynamic libraries because using a dynamic linker frees up memory space ('Efficiency', p.4, "Using shared, dynamic libraries means that, instead of linking each file to its own copy of a library at compilation time and potentially wasting memory space, only one copy of the library is ever stored in memory at a time, freeing up memory space to be used elsewhere.")
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Amarasinghe in view of Jiang as applied to claim 5 and further in view of Linker (‘Linker (computing)’ article from Wikipedia, sourced Feb 28, 2021) and Include Directive (‘Include directive’ article from Wikipedia, sourced Feb 19, 2021).
Regarding Claim 9, Amarasinghe in view of Jiang teaches the method of claim 5. Amarasinghe in view of Jiang does not teach the rest of claim 9. In an analogous art, Linker teaches that the editing of the link to resolve at least one symbol of the object code substitutes a unique identifier obtained from the identifier of the support function by an index representative of a location of the support function in the kernel of the computing equipment (Overview, p.1, "… these parts/modules do not need to be contained within a single object file, and in such cases refer to each other by means of symbols as addresses into other modules, which are mapped into memory addresses when linked for execution", the symbol for the to-be-linked module (unique identifier obtained from the identifier of the support function) is mapped to the module's memory address when linked for execution (substituted by an index representative of a location of the support function in the kernel of the computing equipment)).
It would be obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify Amarasinghe in view of Jiang using Linker to edit the link to resolve at least one symbol of object code to substitute a unique identifier from the identifier of the support function with an index representative of a location of the support function in the kernel of the computing equipment because linking, through (for example) dynamic linking, allows for the saving of limited memory and disk space (Linker, 'Dynamic linking', p.2, "Often-used libraries (for example the standard system libraries) need to be stored in only one location, not duplicated in every single executable file, thus saving limited memory and disk space.")
Amarasinghe in view of Jiang and Linker does not teach but, in an analogous art, Include Directive teaches using a header file configured to allow the substitution ('Include directive', p.1, "Many programming languages and other computer files have a directive, often called include (sometimes copy or import), that causes the contents of a second file to be inserted into the original file. These included files are called copybooks or header files. They are often used to define the physical layout of program data, pieces of procedural code and/or forward declarations while promoting encapsulation and the reuse of code.")
It would be obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify Amarasinghe in view of Jiang and Linker using Include Directive to use a header file configured to allow the substitution because it allows you to only have to write down the function in one file as opposed to having it be in each file (Include Directive, 'Purpose', p.2, "One drawback of this method is that the prototype must be present in all files that use the function. Another drawback is that if the return type or arguments of the function are changed, these prototypes will have to be updated. Putting the prototype in a single, separate file avoids these problems. ")
Claims 11 and 13 is rejected under 35 U.S.C. 103 as being unpatentable over Amarasinghe in view of Jiang as applied to claim 1 and further in view of Okihara (US 20160259944 A1).
Regarding Claim 11 and substantially claim 13, Amarasinghe in view of Jiang teaches the method of claim 1. Amarasinghe in view of Jiang does not teach the rest of claim 1. In an analogous art, Okihara teaches recording said mitigation program as a security policy (Fig. 6A-6B, ¶55, programmed rules are implemented as policies for security) in a kernel namespace dedicated to security management (Fig. 2A, ¶79 "Here, as with the first embodiment, the policy processor 114 functions as the kernel thread which does not have a user interface." ¶62, policies are stored in a policy DB (database) stored in the OS (kernel)), this kernel namespace being associated with at least one process of said function to be protected (¶54, "Then the policy processor 114 illustrated in FIG. 2A inputs policies for individual applications from the policy DB 113."), and wherein said kernel implements a security method for securing a system call triggered by a current process of said user space before executing at least one operation triggered by said at least one system call (¶34, "The policy processor 114 performs the following process when receiving… a system call from one of the applications 111 to be controlled and the process information 117… the policy processor 114 supplies a policy corresponding to the system call to an access controller 115."), said security method including: obtaining at least one kernel namespace dedicated to security management associated with said current process; determining whether said at least one namespace includes a security policy (¶40, a policy related to the application performing the system call is obtained from the policy DB and sent to the access controller); and executing said security policy (¶42, the security policy is executed).
It would be obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify Amarasinghe in view of Jiang using Okihara to implement the mitigation program as a kernel security policy triggered by the system call of the operation because kernel space is difficult for a user to access, thus preventing a malicious take-over (Okihara, ¶35, "Therefore, it is difficult for a user to access the kernel space unless a user interface for access from the user space is explicitly implemented. Accordingly, a take-over by the malicious person may be prevented.").
Allowable Subject Matter
Claim 10 allowed.
Claim 10 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
Regarding Claim 10, Amarasinghe in view of Jiang, Linker, and Include Directive teaches the method of claim 9.
Although Amarasinghe teaches a hash of the support function (see rejection for claim 7 as covered by Amarasinghe), Amarasinghe neither hints nor implies that the hash of the support function is a symbol to the support function that may be resolved (i.e., the unique identifier as taught by Linker). Amarasinghe in view of Jiang, Linker, and Include Directive does not teach that the unique identifier, obtained from the identifier of the support function, includes a hash of the support function.
The closest prior art of record are Russell (Russell et al., US 20080172658 A1) and Baentsch (Baentsch et al., US 20020059475 A1).
Russel teaches that a unique identifier includes a hash of the support function (Russel, ¶61, the signature (hash) of the helper method is used to check for invocations of the helper method). Similarly, Baentsch teaches that a unique identifier includes a hash of the support function (Baentsch, ¶13, a parametrized hash function is used to map symbol (unique identifier) onto linking identifiers. ¶9, 11, the linking identifiers bind to references and functions within (support function)). However, neither render obvious their combination with Amarasinghe in view of Jiang, Linker, and Include Directive as a whole, as they are related to programming as a whole rather than anything related to cybersecurity or management of software compilation and linking.
Therefore, claim 10 is allowable over the prior art of record.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ofek (OFEK et al., US 20190303585 A1) teaches identifying a vulnerability, a server creating mitigating code based off of the vulnerability as software hooks to be installed, and sending that code back to be installed, where that code may be machine code in the kernel.
Oliphant (Oliphant et al., US 20150271142 A1) teaches a security server that identifies vulnerabilities using vulnerability identifier, using the vulnerability data and remediation data to select a patch, and installing a patch to correct a vulnerability in the device's OS.
Tripp (US 20140101769 A1) teaches installing programs that serve to constrain applications with vulnerabilities.
Raber (RABER et al., US 20130347104 A1) teaches a kernel driver that acts as a mitigation program in the kernel space of a user's computer, which subverts anti-debugging protections in a suspect executable file.
Xia (XIA et al., WO 2017166446 A1) teaches obtaining vulnerability repair code from a server as a kernel module, then using that vulnerability repair code in the kernel as an executable to mitigate the vulnerability.
Stoler (US 10747875 B1) teaches running a kernel module inside the kernel space as an executable script, using an extended BPF (EBPF).
Diehl (Diehl et al., US20140109226 A1) teaches installing a security agent on a kernel of a computing device, which obtains healing instructions from a server to remediate a vulnerability.
Chelarescu (CHELARESCU et al., US 20200342106 A1) teaches installing a treatment program for a software virus in response to detecting the software virus in a client system.
Banzhof ( US 20050229256 A2) teaches constructing a remediation signature composing actions to remediate a vulnerability in a program, and downloading the remediation signature from a server to remediate the vulnerability.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR MAHDI HAJIABBASI whose telephone number is (703)756-5511. The examiner can normally be reached M-F 7:30-5 EST.
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, Catherine Thiaw can be reached at (571) 270-1138. 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.
/A.M.H./
Amir Mahdi Hajiabbasi Examiner, Art Unit 2407
/Catherine Thiaw/ Supervisory Patent Examiner, Art Unit 2407 1/13/2026