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 .
Response to Amendment
2. The Amendment filed July 24, 2026, has been entered. Claims 11, 13 and 16 have been amended. Claims 17-20 were canceled. Claim 1-16 and 21-24 are presented for examination.
Claim Rejections - 35 USC § 112
3. The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
4 Claim 5 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 5 recites the limitation "based on the function mapping table”. There is insufficient antecedent basis for this limitation in the claim. Claim 4, from which claim 5 depends, recites a code path mapping table, no function mapping table is previously recited. For examination purposes, the function mapping table is interpreted as the code path mapping table of claim 4. This rejection was set forth in the prior Office action. Applicant’s reply did not address it. The rejection is maintained.
Claim Rejections - 35 USC § 102
5. 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 (i.e., changing from AIA to pre-AIA ) 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.
6. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
7. Claim 1, 2, 10, 16 and 24 are rejected under 35 U.S.C. § 102 (a)(1) and 35 U.S.C. § 102 (a)(2) as being anticipated by Le et al. (US 2023/0069035 A1), hereafter Le.
Regarding claim 1, Le discloses a method comprising: obtaining an input request to fence one or more program objects in a program code, wherein the program objects are disabled; {Le [0024] “When the threshold is exceeded, the runtime agent determines which basic blocks to inactivate from memory 320.” [0040] “At predefined process 580, the process performs the Enforce Thresholding routine… If the threshold is breached, then this routine operates to inactivate one or more basic blocks…” [0045] “At step 680, the process identifies one or more types of code to remove from memory area 320... At step 685, the process removes the basic blocks associated with identified types of code by writing trap code to the memory spaces of the basic blocks being inactivated and further marks each of these basic blocks as being ‘inactive’ in basic block metadata 310.”} The claimed input request is the Enforce Thresholding routine’s determination, issued when the threshold is exceeded, to inactivate identified basic blocks of the debloated program file, the claimed program code ([0029] and [0030]). The basic block manager obtains that request input as the input invoking the inactivation processing of steps 680-685 ([0045]). The claimed disabled program objects are the blocks identified for inactivation. The identification at step 680 designates the blocks as disabled, and the trap-code writing at step 685 fences them, with the ‘inactive’ designation recorded in metadata 310 ([0045]). Le likewise fences code already in the inactive state. At program launch, blocks not yet activated receive trap code at their starting addresses ([0037]). Le refers to these blocks as “inactivated code” ([0039]). Also see [0023], [0025] and [0049].
identifying, based on the input request, code areas of the one or more disabled program objects that should be fenced off; {Le [0037] “When the selected basic block is not the starting block then, at step 550, the process writes trap code at selected block's starting address.”} The claimed code areas are the starting addresses and memory spaces of the block selected for inactivation ([0037], [0045]). They are identified based on the input request because they are the areas of the blocks that the thresholding determination selected (Le, [0024]). Also see [0025] and [0035].
and inserting hard fencing code for fencing the code areas to generate fenced code areas, wherein hardware cannot execute code within the fenced code areas. {Le [0025] “When the runtime agent inactivates a basic block from memory, a set of trap code (instructions) are written to the memory area where the inactivated block resided. In one embodiment, the remainder of the memory area where the inactivated block resided is written over (e.g., writing zeros to all memory in the memory area except for the trap code, etc.).”} The claimed hard fencing code is the trap code together with the zeros written over the remainder of the area ([0025]). After the insertion, the inactivated block’s code is no longer present in the fenced area and cannot be executed by hardware. See also [0037] and [0045] of Le. The present specification itself identifies overwriting code with binary zeros as a hard fencing method by which hardware cannot execute within the overwritten areas (Specification, [0049]).
Claim 2:
Regarding claim 2, Le discloses the elements of claim 1 as outlined above. Le further teaches wherein obtaining the input request further comprises receiving the input request from one of a parameter library, a command line, a Graphical User Interface (GUI), an automation function, or system interrupt. {Le “At predefined process 580, the process performs the Enforce Thresholding routine… If the threshold is breached, then this routine operates to inactivate one or more basic blocks…”} The claimed automation function is the Enforce Thresholding routine executed by the runtime agent, which generates and acts on the inactivation request without human intervention ([0040]). Claim 2 recites its sources in the alternative.; the rejection relies on the automation function. See also [0025] and [0045].
Claim 10:
Regarding claim 10, Le discloses the elements of claim 1 as stated. Le further discloses receiving an input request to unfence one or more program objects in the program code; and applying hard fencing code to unfence the fenced code areas, enabling execution of program instructions within the unfenced code areas. {Le [Para. 0041, FIG. 6] “A trap is encountered when an actively running basic block makes a call to a basic block that has been inactivated with the code at the inactivated block being trap code that calls the basic block manager so that the basic block manager can load the code into the memory space of the requested basic block and then execute the basic block.” [0043] “At step 650, the process writes the basic block code to the assigned memory address area… overwriting the trap code... At step 660, the process marks block as ‘active’ in the metadata...” [0046] “At step 690, the process executes the requested basic block.”} Also see [0026] and [0042]. The claimed input request to unfence is the call into the inactivated block, which the trap code converts into a request to the manager ([0041]); writing the retrieved block code over the trap code and marking the block active unfences the areas and enables execution with them ([0043], [0046]). The claimed applying hard fencing code to unfence corresponds to execution of the trap code itself, which is the inserted hard fencing code; its execution invokes the manager to restore the block code and mark the block active ([0041], [0043]).
Claim 24:
Regarding claim 24, Le discloses the elements of claim 1 as set forth above. Le further discloses wherein inserting the hard fencing code comprises overwriting code in the code areas with binary zeros such that hardware cannot execute code within the fenced code areas. The memory area of the inactivated block’s is written over with zeros, except for the trap code at the starting address, and the block’s code is no longer present to be executed. {Le [0025] “[W]hen the runtime agent inactivates a basic block from memory, a set of trap code (instructions) are written to the memory area where the inactivated block resided… the remainder of the memory area where the inactivated block resided is written over (e.g., writing zeros to all memory in the memory area except for the trap code, etc.)”} The claim recites that the inserting comprises the overwriting, an open-ended recitation. The trap code written alongside the zeros is additional matters and does not preclude anticipation. The claim recites overwriting code in the code areas, not overwriting the entirely of each code area. Le’s zeros overwrite code in the code areas ([0025]).
Le further discloses restoring the overwritten code from a local or remote backup, or by reapplying program temporary fixes, to unfence the code areas. {Le [0042] “The code for the basic block was previously stored in memory area 315 and step 610 retrieves the code from the memory area.” [0043] “At step 650, the process writes the basic block code to the assigned memory address area in memory area 320 that is used for running basic blocks with the writing overwriting the trap code that was previously found at the starting address location of the requested basic block.”} Also see [0025] and [0046]. The claimed local backup is private code storage 315, a memory area of the system that holds a copy pf the inactivated code ([0025]). The retrieval and write-back restore the overwritten code. The block is then marked active and executed ([0043], [0046]), so the restored areas are unfenced. Claim 24 recites its restore sources in the alternative, the rejection relies on the local backup alternative.
Claim Rejections - 35 USC § 103
8. 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.
9. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
10. Claims 3, 7 and 8 are rejected under 35 U.S.C. § 103 as being unpatentable over Le as applied to claim 1, and further in view of Gupta (US 2018/0004950 A1), hereafter Gupta.
The rejections are restated with express designations responsive to applicant’s remark, and the grounds are unchanged.
Regarding claim 3, Le teaches the elements of claim 1 as outlined above, including identifying, based on the input request, the code areas to be fenced of the one or more disabled program objects ([0025], [0037]; see the rejection of claim 1 above).
Le does not teach identifying registered functions and tagging code modules related to the registered functions for the one or more disabled program objects. Gupta cures this deficiency. Gupta identifies the code blocks exercised by each specific functionality of an application and records them, with their start and end memory address, in a golden table. {Gupta [Para. 42] “As specific functionality for a computer application is exercised, the host system, in turn, executes the code blocks corresponding to the functionality. The instrumentation engine captures the generated instructions (e.g., assembly code instructions) for each code block. As shown in FIG. 4, the instrumentation engine records an enumeration for each executed code block in the golden table. Further, the instrumentation engine records the start memory address and end memory address for the range of captured instructions for the respective code block.” [Para. 43] “In this embodiment the golden table contains memory addresses for all the active code blocks, however, in other embodiments, the golden table may instead contain the memory addresses for all the inoperative code blocks.”}
The claimed registered functions corresponds to the specific functionalities of the computer application whose executed code blocks the instrumentation engines enumerated and records in the golden table (Gupta, [0042]). The recording registers the code blocks of each exercised functionality. The claimed tagging of code modules corresponds to recordings, for each code block of a functionality, an enumeration and the start and end memory address of its instructions ([0042]). The recorded entry tags the code block as related to that functionality. In the embodiment of [0043], the golden table holds the memory addresses of the inoperative code blocks. The tag module are therefore those of the disabled program objects. Claim 3 does not recite where the tag resides. Amended claim 11, which recites code modules tagged in the program code, is addressed separately under its own ground below.
Gupta is analogous art. Gupta reduces the attack surface of a computer application by rendering identified code inoperative in memory, the same filed if endeavor as the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le to identify registered functions and tag code modules related to the registered functions for the one or more disabled program objects, in the manner taught by Gupta. In the combination, Le’s identification of the areas to be fenced ([0025], [0037]) uses Gupta’s recording of the code blocks of each exercised functionality ([0042]). The modification applies Gupta’s known recording technique to Le’s selection of blocks for inactivation, yielding the predictable result that the codes areas to be fenced are identified from the recorded functionalities and their captured code blocks (Gupta, 0042]). One of ordinary skills would have been motivated to make this modification because doing so would “reduce the attackable code surface of the application” (Gupta, [0035]). One of ordinary skill would have had a reasonable expectation of success. Both Le and Gupta operate on identified code blocks in memory, and Gupta’s golden table supplies the block address that Le’s overwriting uses.
Claim 7:
Regarding claim 7, Le teaches the elements of claim 1 as outlined above, including inserting hard fencing code for fencing the code areas ([0025], [0037], [0045]; see the rejection of claim 1 above). Le does not teach testing the code areas of the one or more program objects to identify sensitive code in the code areas to be fenced; and identifying a fencing method based on identifying sensitive code in the code areas to be fenced.
Gupta cures this deficiency. Gupta tests application functionality, including negative testing, determine whether the code is self-generating, or interpretive, and selects permanent or temporary overwriting at loas time or at runtime based on that determination. {[Para. 0049] “Based on the functionality testing 520, the instrumentation engine may perform negative testing 540 to further capture instructions related to the need functionality for the organization. Negative testing 540 tests the handling of invalid input or unexpected behavior in regards to the needed functionality (e.g., exception handling).” [Para. 0034] “In some embodiments, the instrumentation engine permanently changes the instructions to inoperative, and in other embodiments, the instrumentation engine temporarily changes the instructions to inoperative. The instrumentation engine may change the respective instructions to inoperative by overwriting the instructions with inoperative instructions during runtime or during load time. In some embodiments, the instrumentation engine may determine to overwrite the respective instructions at either runtime or load time based on the source code being self-generating or interpretive source code.” [Para. 0053] “If the application does contain self-generating or interpretive code, then the instrumentation engine 570 may perform the application lockdown during runtime (i.e., in real time).”} Also see [0052].
The claimed testing corresponds to Gupta’s evaluation of the application code to determine whether it contains self-generating or interpretive code ([0034, [0053]). Evaluating the code for that characteristic examines the code areas, and Gupta performs the evaluation within a testing workflow that also includes functionality testing and negative testing [0049]). The claimed sensitive code corresponds to the code determined to be self-generating or interpretive. The claim does not define the term. Under the broadest reasonable interpretation, sensitive code encompasses code of heightened risk character. Self-generating or interpretative code presents that risk through a greater chance of exploitation. The claimed identifying of a fencing method corresponds to Gupta’s selection, based on that determination, of the manner in which the code is rendered inoperative: a permanent or a temporary overwrite, applied at load time or at runtime ([0034], [0053]). A permanent load-time overwrite and a temporary runtime overwrite are different fencing methods; selecting between them based on the determined code characteristic is identifying a fencing method based on identifying sensitive code.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le to test the code areas of the one or more program objects to identify sensitive code in the code areas to be fenced and to identify a fencing method based on identifying sensitive code in the code areas to be fenced, in the manner taught by Gupta ([0034], [0049], [0053]). In the combination, the testing examines the code of the blocks that Le manages, and the selection governs how Le’s overwriting is applied: permanently or temporarily, at load time or at runtime ([0034]). The modification applies Gupta’s known selection of lockdown treatment based on the determined code characteristic to Le’s overwriting. The predictable result is that the overwriting treatment applied to the code areas is selected based on the determination of self-generating or interpretive code ([0034], [0053]). One of ordinary skills would have been motivated to make this modification because doing so would “reduce the attackable code surface of the application” (Gupta, [0035]). One of ordinary skill would have had a reasonable expectation of success. Both references overwrite code in memory to render it inoperative (Gupta, [0034]; Le, [0025]), so Gupta’s selection applies directly to Le’s overwriting of inactivated blocks.
Claim 8:
Regarding claim 8, Le and Gupta teaches the elements of claim 7 as outlined above. Le further teaches wherein the code removal fencing method comprises one of using encryption fencing method for encrypting the code in the code areas, or using an overwriting fencing method for overwriting the code in the code areas. {Le [Para. 0025] “When the runtime agent inactivates a basic block from memory, a set of trap code (instructions) are written to the memory area where the inactivated block resided… the remainder of the memory area where the inactivated block resided is written over (e.g., writing zeros to all memory in the memory area except for the trap code, etc.).”} The remainder of the memory area is written over with zeros. Le does not teach identifying a code removal fencing method, based on identifying sensitive code in the code areas to be fenced.
Gupta cure this deficiency. Gupta selects the overwriting treatment, and its permanence and timing, based on the presence of self-generating or interpretive code (Gupta, [0034], [0053], quote above in the rejection of claim 7). The claimed code removal fencing method corresponds to the overwriting of instructions with inoperative instructions (Gupta [0034]) and the overwriting with zeros (Le, [0025]). The claim recites is methods in the alternative, and the rejection relies on the overwriting alternative. Gupta’s selection is the claimed identifying of a code removal fencing method based on identifying sensitive code, as set forth in the rejection of claim 7 above. Th findings of analogous art, motivation, and reasonable expectation of success set forth in the rejection of claim 7 apply equally to this modification.
11. Claims 4, 5 and 6 are rejected under 35 U.S.C. § 103 as being unpatentable over Le and Gupta as applied to claims 1 and 3, and further in view of Boling et al. (US 2022/0309134 A1), hereafter Boling.
The rejections are restated with express designations responsive to applicant’s remark, and the grounds are unchanged.
Regarding claim 4, Le in view of Gupta teaches the elements of claim 3 as outlined above, including the identification of registered functions and the tagging of code modules related to the registered functions (see the rejection of claim 3 above). Le and Gupta do not teach creating a code path mapping table for each registered function, based on identifying registered functions and tagging the object code modules, comprising code areas of code modules corresponding to registered functions for the one or more program objects.
Boling cures this deficiency. Boling identifies named software entities, such as functions and modules, annotates their object code, and builds a tag map table from the loaded annotated code. {Boling [0094] “A named entity may represent a software component, such as a function, a module, a driver, a service routine, etc.” [0095] “The policy linker 225 may identify descriptions of those entities from the target description, and use the descriptions to annotate, with appropriate metadata symbols, the object code output by the linker 210.” [0100] “The loader 215 may create an entry in the tag map table 142 that maps an application memory address where an instruction is stored in the application memory 120, to a metadata memory address where metadata associated with the instruction is stored in the metadata memory 125. Alternatively, the loader 215 may store metadata in the tag map table 142 itself”} Also see [0088], [0093], [0096] and [0097].
The claimed registered functions correspond to Boling’s named entities, which represent software components such as functions and modules ([0094]) and are identified by matching entity names ([0096]). The claimed tagging of the object code modules corresponds to annotating the object code of those entities with metadata symbols ([0095]). The boundaries the compiler marks are used to tag instructions as function prologue or epilogue ([00088]). The claimed table corresponds to the tag map table, whose entries map the application memory addresses where the loaded instructions are stored, with the metadata label for those instructions identified from the initialization specifications ([0097], [0100]). Claim 4 recites what the table comprises, not the orientation of its entries. A table whose entries hold the memory addresses of each registered function’s instructions comprises the code areas of the code modules corresponding to the registered functions.
Boling is analogous art. Boling protects executable code in memory by tagging code regions with metadata that governs whether they may be executed, the same field of endeavor as the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le and Gupta to create a code path mapping table for each registered function, based on identifying registered functions and tagging the object code modules, comprising code areas of code modules corresponding to registered functions for the one or more program objects, in the manner taught by Boling ([0088], [0094]-[0096], [0100]). In the combination, the registered functions and tagged code modules of claim 3 (Gupta, [0042], [0043]) are recorded in a table that holds, for each registered function, the memory addresses of its code modules. The modification applies Boling’s known construction of the tag map table from annotated object code to the functionalities and code blocks that the combination of Le and Gupta already records. The predictable result is that the table’s entries map the applications memory address of the loaded instructions to the metadata memory addresses (Boling, [0100]).
One of ordinary skill would have been motivated to make this modification because doing so may “prevent malicious attacker code from loading an illegitimate binary image” (Boling, [0202]). One of ordinary skill would additionally have been motivated to organize the recorded addresses of each registered function because the combination of Le and Gupta already records the code blocks of each functionality with their memory addresses, the [0043] embodiment holding those of the inoperative blocks (Gupta (US2018/0004950A1), [0042], [0043]). This makes the code areas of a disabled function directly available to the fencing operation. One of ordinary skill would have had a reasonable expectation of success. Gupta already records the start and end memory addresses of each code block in a table ([0042]), and Boling’s table entries likewise map the application memory addresses of the loaded instructions ([0100]).
Claim 5:
Regarding claim 5, Le in view of Gupta and Boling teaches the elements of claim 4 as outlined above, including the code path mapping table (see the rejection of claim 4 above). Le in view of Gupta does not teach creating a fence-code table, based on the function mapping table, comprising the code areas of the code modules of each registered function and a status of fenced or not fenced.
Boling cures this deficiency. Boling’s tag map table associates application data with metadata that describes it, including whether the data is executable. {Boling [0063] “by mapping application memory addresses to metadata memory addresses, the tag map table 142 may create an association between application data and metadata that describes the application data. Metadata stored at the metadata memory address Y and thus associated with application data stored at the application memory address X may indicate that the application data may be readable, writable, and/or executable.” [Para. 0100] “Alternatively, the loader 215 may store metadata in the tag map table 142 itself.” [0095] “the policy linker 225 may apply a Read label to a .rodata section of an Executable and Linkable Format (ELF) file,… and an Execute label to a .text section of the ELF file. Such information may be used to enforce a policy for memory access control and/or executable code protection (e.g., by checking read, write, and/or execute privileges).”}
The entries in the tag map hold the application memory addresses of the loaded instructions ([0100], see the rejection of claim 4 above). Those addresses are the claimed code areas. The metadata associated with each address may indicate that the application data stored there is executable ([0063]). The claimed status of fenced or not fenced corresponds to that executability indication. An Execute label marks code as executable, a status of not fenced. The policy enforcement checks execute privileges, so metadata lacking execute permission marks code that is not to be executed, a status of fenced ([0063], [0095]). In the embodiment of [0100], the loader stores the metadata in the tag map table itself, so the table comprises both the code addresses and the status. Claim 5 recites that the fence-code table is based on the function mapping table. This corresponds to the metadata association being created by the address mapping of the tag map table ([0063]), the same table relied upon for the code mapping table of claim 4.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le, Gupta and Boling to create a fence-code table, based on the function mapping table, comprising the code areas of the code modules of each registered function and a status of fenced or not fenced, in the manner taught by Boling ([0063], [0095], [0100]). In the combination, the table of claim 4 carries, for the code areas of each registered function, metadata indicating whether that code is executable (Boling, [0100]), and the fenced status of a disabled function’s code areas is recorded in that metadata. The modification applies Boling’s known association of executability metadata with the application memory addresses in the table. The predictable result is that the metadata associated with each application memory address indicates whether the application data stored there is executable (Boling., [0063],[0095]). The findings of analogous art, motivation and reasonable expectation of success set forth in the rejection of claim 4 above apply equally to this modification.
Claim 6:
Regarding claim 6, Le in view of Gupta Boling teaches the elements of claim 5 as outlined above. Le teaches inserting hard fencing code for fencing the code areas to provide fenced code areas ([0025], [0037]; see the rejection of claim 1 above). The combination of Le and Boling does not teach applying hard fencing code to the code areas of the code modules of each disabled registered function that is not fenced.
Gupta cures this deficiency. Gupta traverses the complete range of the application’s memory addresses, compares each address with the active addresses retrieved from a table, and changes each instruction outside the active set to inoperative by overwriting it with an inoperative instruction. {Gupta [0033] “At step 240, for each available instruction not in the set of instructions, the instrumentation engine changes the respective instruction to inoperative. The instrumentation engine retrieves the memory addresses for the set of instructions determined in step 220. The instrumentation engine may then traverse the complete range of memory addresses for the application. If a traversed memory address does not correspond to a memory address retrieved for the set of active instruction, then the instrumentation engine changes the respective instruction to inoperative.” [Para. 0034] “The instructions engine may change the respective instructions to inoperative by overwriting the instruction with an inoperative instruction (or NOP) or equivalent inoperative instruction.”} Also see [0028], [0030], [0044] and [0052].
The claim is taught by the combination rather than by Gupta alone. The disabled registered functions are supplied by the combination set forth in the rejection for claim 3 above. The registered functions are the functionalities whose code blocks are recorded, and in the embodiment of [0043] the recorded blocks are those of the disabled program objects. The code modules of each such function and their code areas are supplied by the code path mapping table set forth in the rejection of claim 4 above. The status of fenced or not fenced is supplied by the fence-code table set forth in the rejection of claim 5 above. The claimed applying of hard fencing code corresponds to Gupta’s overwriting with inoperative instructions ([0033], [0034]). In the combination, the overwriting is applied to the code areas that the fence-code table lists for a disabled registered function with a status of not fenced. Gupta’s traversal is already table-driven, instructions whose addresses are not among those retrieved from the table are changed to inoperative (Gupta, [0033]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le, Gupta and Boling to apply hard fencing code to the code areas of the code modules of each disabled registered function that is not fenced, in the manner taught by Gupta ([0033], [0034]). In the combination, the fence-code table set forth in the rejection of claim 5 above supplies the code areas of each disabled registered function and their status, and the areas with a status of not fenced receive Gupta’s overwrite. The modification applies Gupta’s known table-driven overwriting to the code areas listed in the fence-code table. The predictable result is that the instructions at the listed addresses are changed to inoperative (Gupta, [0033], [0034]). One of ordinary skill would have been motivated to make this modification because doing so would “reduce the attackable code surface of the application” (Gupta, [0035]). One of ordinary skill would have had a reasonable expectation of success. Gupta’s overwrite operates by comparing traversed addresses with addresses retrieved from a table ([0033]), and the fenced-code table of the combination supplies the address of the code areas t which the overwrite is applied.
12. Claim 9 is rejected under 35 U.S.C. § 103 as being unpatentable over Le and Gupta as applied to claims 1 and 7 above, and further in view of Duale et al. (US2018/0173880 A1), hereafter Duale.
The rejections are restated with express designations responsive to applicant’s remark, and the grounds are unchanged.
Regarding claim 9, Le and Gupta teaches the elements of claim 7 as set forth above, including the selection of a fencing method based on the determined code characteristics (see the rejection of claim 7 above). Le in view Gupta does not teach identifying, based on not identifying sensitive code in the code areas to be fenced, a fencing method using a processor hardware based function that sets a non-executable state for the fenced code areas, where the processor hardware based function comprises using Instruction Execution Protection (IEP).
Duale cures this deficiency. Duale sets IEP bits of page tables, each bit preventing the code in a respective storage block from being executed. {Duale [0004] “A computer-implemented method includes executing one or more tests on a computing device. The computing device has Instruction Execution Protection (IEP), and each test of the one or more tests includes selectively setting one or more IEP bits of one or more page tables, where each IEP bit prevents code in a respective storage block from being executed.”} Also see [0020] and [0023]. The claimed processor hardware based function corresponds to Duale’s IEP, which sets a non-executable state for storage block through IEP bits of the page table ([0004], [0020]). The claimed negative branch, identifying the fencing method based on not identifying sensitive code, corresponds in the combination to Gupta’s selection framework: where the evaluation does not find self-generating or interpretive code, the hardware based method is selected for the code areas (see the rejection of claim 7 above).
Duale is analogous art. Duale renders storage blocks of non-executable through a processor hardware function, the same field of endeavor as the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le and Gupta to identify, based on not identifying sensitive code in the code areas to be fenced, a fencing method using a processor hardware based function that sets a non-executable state for the fenced code areas, the processor hardware based function comprising using Instruction Execution Protection (IEP), in the manner taught by Duale ([0004], [0020], [0023]). In the combination, when the evaluation does not find self-generating or interpretive code, the fenced code area are set to a non-executable state by IEP rather than overwritten. The modification apples Duale’s known IEP page-table protection to the code areas identified for fencing, yielding the predictable result that those areas are rendered non-executable through IEP bits of the page tables ([0040]).
One of ordinary skill would have been motivated to make this modification because doing so would “ensure that IEP is operating as expected on each computing device onto which is incorporated” (Duale, [0018]). One of ordinary skill would additionally have been motivated to select IEP for code not found sensitive because the IEP bits are set selectively per storage block while other blocks are left unset (Duale, [0004], [0023]). This protects the fenced areas without altering the stored code, so the blocks remain intact for the later return to execution that Le provides (Le, [0043]). One of ordinary skill would have had a reasonable expectation of success. IEP operates on storage blocks through page-table bits (Duale, [0004]), and Le manages and fences code at the same block granularity (Le, [0024], [0025]).
13. Claim 16 is rejected under 35 U.S.C. § 103 as being unpatentable over Le et al. (US 2023/0069035 A1), hereafter Le, in view of Gupta (US 2018/0004950 A1), hereafter Gupta.
The change of ground is necessitated by applicant’s amendment of claim 16, which added the testing and selecting limitations carrying the subject matter of canceled claims 18 and 19.
Regarding claims 16, Le teaches a computer program product comprising a computer-readable storage medium having computer-readable program code embodied therewith, the computer-readable program code executable by one or more computer processors to perform an operation. {Le [Para. 0049] “Present disclosure may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.” [Para. 0050]. “A computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.”}
Le teaches obtaining an input request to fence one or more program objects in a program code, wherein the program objects are disabled; identifying, based on the input request, code areas of the one or more disabled program objects that should be fenced off; and inserting hard fencing code for fencing the code areas to generate fenced code areas, wherein hardware cannot execute code within the fenced code areas, as set forth in the rejection of claim 1 above. Le does not teach testing the code areas to identify sensitive code in the code areas; selecting, based on identifying the sensitive code in the code areas, a code removal fencing method comprising encrypting code in the code areas or overwriting code in the code areas.
Gupta cures this deficiency. Gupta tests application functionality, including negative testing, determine whether the code is self-generating, or interpretive, and selects permanent or temporary overwriting at loas time or at runtime based on that determination. {[Para. 0049], [0034], [0053], quoted in the rejection of claim 7 above. Also see [0052]}. The claimed testing corresponds to Gupta’s evaluation of the application code to determine whether it contains self-generating or interpretive code ([0034, [0053]). Gupta performs the evaluation within a testing workflow that also includes functionality testing and negative testing [0049], see the rejection of claim 7 above). The claimed sensitive code corresponds to the code determined to be self-generating or interpretive, as set forth in the rejection of claim 7 above. The claimed selecting corresponds to Gupta’s selection, based on that determination, of a permanent or a temporary overwrite applied at load time or at runtime ([0034], [0053]). Claim 16 recites the code removal methods in the alternative; the rejection relies on the overwriting alternative, taught by Gupta’s overwriting of instructions with inoperative instructions ([0034]) and by Le’s overwriting with zeros ([0025]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le to test the code areas to identify sensitive code in the code areas and to select, based on identifying the sensitive code in the code areas, a code removal fencing method comprising overwriting code in the code areas, in the manner taught by Gupta ([0034], [0049], [0053]). In the combination, the testing examines the code of the blocks that Le manages, and the selection governs how Le’s overwriting is applied: permanently or temporarily, at load time or at runtime ([0034]). The modification applies Gupta’s known selection of lockdown treatment based on the determined code characteristic to Le’s overwriting. The predictable result is that the overwriting treatment applied to the code areas is selected based on the determination of self-generating or interpretive code ([0034], [0053]). One of ordinary skills would have been motivated to make this modification because doing so would “reduce the attackable code surface of the application” (Gupta, [0035]). One of ordinary skill would have had a reasonable expectation of success. Both references overwrite code in memory to render it inoperative (Gupta, [0034]; Le, [0025]), so Gupta’s selection applies directly to Le’s overwriting of inactivated blocks.
14. Claims 21 is rejected under 35 U.S.C. § 103 as being unpatentable over Le as applied to claim 1, in view of Godse (US 5,991,544), hereafter Godse.
Regarding claim 21, Le teaches the elements of claim 1 as set forth above. Le further teaches preventing the loading of fenced code into memory at program fetch time. In Le, when a program is launched, each basic block other than the starting block receives trap code at its starting address instead of its code, and the code of an inactivated block is withheld from the running memory area until the basic block manager restores it ([0035], [0037], [0045]).
Le does not teach cross-referencing a fence-code table and a code path mapping table to prevent loading fenced code into memory.
Godse cures this deficiency. Godse manages a computer’ software load image with two data structures consulted in the load path: a symbol table, searched in the load path for address resolution and for registration triggers, and a load description database, which records each registered sub-system. {Godse (col. 2, ll. 56-63) “a) a first data structure forming a Symbol table associated with at least one Software entity, said data Structure including an entry constituting a registration trigger…; b) a second data structure forming a load description database, said load description database capable of holding a plurality of entries indicative of respective Software entities in an active State”; (col. 4, ll. 10-13) “The registration information namely the Sub-System name, start and end functions are recorded in a file located in the local memory unit of the computer node, herein referred to as load description database.”} Also see FIG. 4 and is description (col. 5, l. 53 - col. 6, l. 29).
The claimed code path mapping table corresponds to the load description database, whose entries record each registered sub-system’s name and its start and end functions, the extent of the code implementing it (col. 4, ll. 10-13). Claim 21 does not recite the contents of either table. A per-function table recording each register function and how its code is entered and ended maps the code path of that function. The claimed fence-code table corresponds, in the combination, to Le’s per block status table: the metadata 310 holds each block’s code areas and its ‘active’ or ‘inactive’ status (Le, [0030], [0036], [0045]; see also the rejection of claim 22). The claimed cross-referencing at program fetch time corresponds, in the combination, to the launch flow consulting both records: the status table supplies which functions are fenced, the per-function records of the load description database identifies each registered function, and the blocks of a fenced function receive trap code instead of their code (Le, Para. 0035, 0037). Consulting a status-marked program table on the fetch path is conventional, as the z/OS directory evidence cited in the rejection of claim 22 below shows (System code, abend 706 entry, p. 472).
Godse is analogous art. Godse manages which software entities’ code is present in a computer’s load image as entities are added and removed, the same field of endeavor as the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le to cross-reference a fence-code table and a code path mapping table at program fetch time to prevent loading fenced code into memory, in the manner taught by Godse (col. 2, ll. 56-63; col. 4, ll. 10-13). In the combination, Le’s launch flow checks each registered function’s recorded entry against its fenced status and withholds the code of fenced functions, writing trap code in its place. The modification applies Godse’s known two-table load-path arrangement to the per-block withholding Le already performs. The predictable result is that the load or trap decision that Le makes per block is made based on the entries recorded per registered sub-system, each holding its name and start and end functions, as the load image changes (Godse, col. 4, ll. 10-13). One of ordinary skills would have been motivated to make this modification because recording each registered function “allows to maintain an accurate load description database” (Godse, col. 4, ll. 25-26), so the launch flow withholds exactly the code of the functions fenced at that time. One of ordinary skill would have had a reasonable expectation of success. Le’s launch flow already decides load or trap per block ([0035], [0037]). Godse’s load description database already records each registered function in the load path (Godse, col. 4, ll. 10-13), while Le’s metadata records each block’s addresses and status (Le, [0030], 0036]).
15. Claims 22 is rejected under 35 U.S.C. § 103 as being unpatentable over Le as applied to claim 1, and in view of IBM z/OS MVS System Codes (SA38-0665, 2021 edition), hereafter System Codes, and IBM z/OS MVS Program Management: User’s Guide and References (SA23-1393, 2019 edition), hereafter Program Management.
Regarding claim 22, Le teaches the elements of claim 1 as set forth above. Le further teaches updating a program vector table at fence time to mark affected code as being fenced. {Le, [0045] “At step 685, the process removes the basic blocks associated with identified types of code by writing trap code to the memory spaces of the basic blocks being inactivated and further marks each of these basic blocks as being ‘inactive’ in basic block metadata 310.”}
The claimed program vector corresponds to basic block metadata 310, organized as per-block entries with uniform fields: which holds, an identifier, the starting address, the length and a status ([0030], [0033], ]0036], [0045]). The metadata is gathered before launch, supplies the blocks’ starting addresses, and is updated as the blocks are loaded (Le, [0034], [0036]). The claim and the specification recite the term functionally, without a structural definition (Spec. [0052]). Under the broadest reasonable interpretation, that collection of entries, carrying each block’s starting address, is a program vector table. The claimed updating at fence time corresponds to step 685, which writes the trap code and marks the inactivated blocks ‘inactive’ in metadata 310 in the same operation (Le, [0045]). The ‘inactive’ mark designates the affected blocks as fenced, consistent with the mapping of claim above, under which Le’s inactivation is the fencing. To the extend the claimed program vector table is construed to require a table structure, or a fetch-consulted program-locating table, beyond Le’s metadata 310, Le does not teach the limitation under that construction. System Codes and Program Management cure this deficiency.
z/OS marks a load module not executable, recording the status in the module’s directory entry (Program Management, p. 140), and LINK, XCTL, ATTACH and LOAD processing refuses to fetch a module marked as not executable, ending the task unless ERRET is specified (System Codes, abend 706 entry, manual page 472). The binder marks a module not executable when an error exceeds the severity threshold of the LET option (Program Management, LET option, p. 86). A directory entry is a record in a program library directory holding the member’s name, a pointer to the member, and its attributes (program Management, p. 224). The directory consulted by program fetch is therefore a program-locating table with per-module executability marks.
System Codes and Program Management are analogous art. Each governs whether stored program code may be fetched and executed, the same field of endeavor as the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le to update a program vector table at fence time to mark affected code as being fenced, in the manner of the not-executable mark that z/OS records in the fetch-consulted directory entry (System Codes, abend 706 entry; Program Management, pp. 86, 140). In the combination, Le’s ‘inactive’ designation is recorded at fence time in the fetch-consulted table for the program. The modification applies the known not-executable marking of z/OS to the blocks that Le inactivates. The predictable result is that program fetch refuses code whose entry carries the mark (System Codes, abend 706 entry, p.472). One of ordinary skills would have been motivated to make this modification because the mark stops execution at program fetch, before the fenced code can be invoked, and the task can continue when ERRET is specified instead of ending abnormally (System Codes, abend 706 entry, p. 472). One of ordinary skill would have had a reasonable expectation of success. Le already records the ‘inactive’ status in a per-block table at fence time (Le, [0045]), and the z/OS mark is likewise a per-entry status in a program-locating table.
16. Claims 23 is rejected under 35 U.S.C. § 103 as being unpatentable over Le as applied to claim 1, and further in view of Chapman et al. (US 2023/0004650 A1), hereafter Chapman.
Regarding claim 23, Le teaches the elements of claim 1 as set forth above. Le further teaches the claimed attempt: a trap is encountered when an actively running basic block called an inactivated block, and the trap code at the block’s starting address transfers control to the basic block manger ([0037], [0041]). Le responds by restoring the block’s code for execution ( [0041], [0043]). Le does not teach responsive to a processor attempting to execute an instruction in one of the fenced code areas, raising an error or exception to a caller instead of allowing execution of the instruction.
Chapman cures this deficiency. Chapman’s code entities have an enabled state and a disabled state. A disabled entity does not run when called; it instead performs a back-out behavior, such as generating an error message. {Chapman [0004] “a disabled state, in which the code entity does not run when called but instead performs a back-out behavior such as generating an error message.” [0054] “The front end instance toggles the affected component to disabled, so that any subsequent attempts to access it results in an error being generated, which in turn triggers a security boundary to display a suitable error message to the user”} Also see [0047] and [0052].
Th claimed attempting to execute an instruction in a fenced code area corresponds, in Chapman, to the attempt to access the disabled component ([0054]). In the combination, the attempt occurs when a running block calls the fenced block and execution reaches the trap code at its starting address (Le, [0041]). The claimed raising of an error or exception to a caller corresponds to the error generated on the attempted access. The component using the disabled library throws the error, and the error is caught at a level of the application above that component (Chapman, [0052], [0054]). Execution is not allowed and the disabled entity does not run when called (Chapman, [0052], [0054]). Claim 23 recites an error or an exception in the alternative, the rejection relies on the error alternative. Chapman’s thrown error, caught within the application, is also an exception ([0052]).
Chapman is analogous art. Chapman disables code entities of an application and controls the response when the disabled code is called, the same field of endeavor as the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le to, responsive to a processor attempting to execute an instruction in one of the fenced code areas, raise an error or exception to a caller instead of allowing execution of the instruction, in the manner taught by Chapman ([0004], [0052], [0054]). In the combination, a call that reaches a block fenced on request receives the error response rather than the restored code, and Le’s trap already intercepts the call at the fenced area (Le, [0041]). The modification applies Chapman’s known disabled-entity error response at Le’s trap interception point. The predictable result is that an attempted access to the disabled code generates an error that is caught at a level of the application (Chapman: [0053], [0054]). One of ordinary skills would have been motivated to make this modification because the error response disables “only the affected part of the application, rather than the entire application” (Chapman, [0052]), keeping the remainder of the program running when fenced code is called. One of ordinary skill would have had a reasonable expectation of success. Le’s trap code already gains control on every call to a fenced block ([0037], [0041]), and Chapman’s error response can be issued form that same point of control.
17. Claims 11 and 12 are rejected under 35 U.S.C. § 103 as being unpatentable over Le et al. (US 2023/0069035 A1), hereafter Le, in view of Gupta (US 2021/0089299 A1), hereafter Gupta 299.
This new ground is necessitated by applicant’s amendment adding the functional registry and tagging limitations.
Regarding claim 11, Le teaches a system comprising: one or more computer processors; and a memory containing a program which when executed by the one or more computer processors performs an operation. {Le [Para. 0016] “Information handling system 100 includes one or more processors 110 coupled to processor interface bus 112. Processor interface bus 112 connects processors 110 to Northbridge 115. Northbridge 115 connects to system memory 120 and provides a means for processor(s) 110 to access the system memory.”}
Le also teaches obtaining an input request to fence one or more program objects in a program code, wherein the program objects are disabled identifying, based on the input request, code areas of the one or more disabled program objects that should be fenced off, and inserting hard fencing code for fencing the code areas to generate fenced code areas, wherein hardware cannot execute code within the fenced code areas, as set forth in the rejection of claim 1 above. Le further teaches hard fencing code that prevents execution of the instructions within the fenced code area: the trap code and zeros written over an inactivated block prevents its instructions from being executed ([0025], [0037]). In the combination below, the fenced instructions are those of the disabled registered function.
Le does not teach that the program objects are disabled according to a functional registry that identifies enabled or disabled status of registered functions, or that the code areas comprise code modules tagged in the program code as being related to a disabled registered function.
Gupta 299 cures this deficiency. Gupta 299 controls the execution of named program features using features flags held in a configuration database. Each flag value represents an enabled or disabled feature. Gupta 299 identifies the code of each feature by scanning the program code for occurrences of the flag names. {Gupta 299 [0002] “Feature toggles (also known as feature flags) are a design technique in software development by which the execution (or not) of certain features by a software program is controlled by variables that may be read from a configuration file or database.” [0046] “the graph creator 201 is functionally coupled to receive feature flag names from the configuration database 22 for the deployed service 21… the graph creator 201 recursively scans the program code of the deployed service 21 for occurrences of these flag names and for branching instructions (e.g. if-then constructs)…” {0050] “… loading and testing the service in the development environment with the appropriate feature toggles having values that represent a disabled feature, unlike the production environment (i.e. the configuration database 22) in which they have values that represent an enabled feature.”} Also see [0039] and [0051].
The claimed functional registry corresponds to the configuration database holding the feature flags. The flag values identify each named feature as enabled or disabled ([0002], [0050]). The claimed registered functions correspond to the named features whose flags are held in the database ([0046]0. The claimed code modules tagged in the program code correspond to the code containing occurrences of the flag names. An occurrence of the flag name in the program code tags the code containing it as related to the named feature ([0046]). Where the flag value represents a disabled feature, the tagged code is related to a disabled registered function ([0050]).
Gupta 299 is analogous art because it manages program features that are disabled in a configuration database and identifies their code in the program, the same field of endeavor as the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le so that the program objects are disabled according to a functional registry that identifies enabled or disabled status of registered functions and the code areas comprises code modules tagged in the program code as being related to a disabled registered function, in the manner taught by Gupta 299 ([0002], [0046], [0050]). In the combination, the input request identifies the blocks of a feature whose flag is disabled in the registry, and the code areas are identified from the occurrences of the flag names in the program code. Le’s trap code and zeros then prevent execution of that functions’ instructions (Le, [0025], [0037]). The modification applies Gupta 299’s known flag-based identification of disabled feature code to the blocks that Le fences. The predictable result is that the code of each named feature is identified through occurrences of its flag name in the program code, with the flag value representing a disabled feature ([Gupta 299: [0046], [0050]). One of ordinary skill would have been motivated to make this modification because the flags allow the operation of the program to be altered “without changing its program code” (Gupta 299: [0039]). One of ordinary skill would have had a reasonable expectation of success. Gupta already operates on blocks designated inactive ( Le, [0039]), and feature flags held in a configuration database are a known design technique for controlling which features execute (Gupta 299: [0002]).
Claim 12:
Regarding claim 12, Le in view of Gupta 299 teaches the limitation of claim 11 as set forth above. Le further teaches wherein obtaining the input request further comprises receiving the input request from one of a parameter library, a command line, a Graphical User Interface (GUI), or an automation function. {Le [0040] “At predefined process 580, the process performs the Enforce Thresholding routine… If the threshold is breached, then this routine operates to inactivate one or more basic blocks…”} The claimed automation function is the Enforce Thresholding routine executed by the runtime agent, which generates and acts on the inactivation request without human intervention ([0040]). Claim 2 recites its sources in the alternative.; the rejection relies on the automation function. See also [0025] and [0045].
18. Claims 13 and 14 are rejected under 35 U.S.C. § 103 as being unpatentable over Le and Gupta (US 2021/0089299 A1) as applied to claim 11 above, and further in view of Gupta (US 2018/0004950 A1), hereafter Gupta 950.
The ground is restated over amended clam 11 and the change is necessitated by the applicant’s amendment.
Regarding claim 13, the combination of Le in view of Gupta 299 teaches the elements of claim 11 as outlined above. The combination does not teach testing the code areas of the code modules related to the disabled registered function to identify sensitive code in the code areas to be fenced; and identifying a fencing method based on identifying sensitive code in the code areas to be fenced. Gupta 950 cures this deficiency. {Gupta (US 2018/0004950 A1): [0049], [0034], [0053], quoted in the rejection of claim 7 above. Also see [0052].}. The designation set forth in the rejection of claim 7 above apply equally to claim 13. In the combination, the tested code areas are those of the code modules tagged as related to the disabled registered function (see the rejection of claim 11 above). The code areas recited in claim 13 are those recited in claim 11, which comprise the tagged code modules. Applying that testing in the combination of claim 11 (Le in view of Gupta 299) tests those areas. The findings of analogous art, motivation and reasonable expectation of success set forth in the rejection of claim 7 above apply equally to this modification, in which the testing and selection taught by Gupta 950 are applied to the combination of Le and Gupta 299.
Claim 14:
Regarding claim 14, the combination of Le in view of Gupta 299 and Gupta 950 teaches the elements of claim 14 as outlined above. Le teaches wherein the code removal fencing method comprises one of using encryption fencing method for encrypting the code in the code areas, or using an overwriting fencing method for overwriting the code in the code areas. {le [0025], quoted in the rejection of claim 1 above. Le does not teach identifying a code removal fencing method, based on identifying sensitive code in the code areas to be fenced;
Gupta 950 cures this deficiency. Gupta 950 selects the overwriting treatment, and its permanence and timing, based on the presence of self-generating or interpretive code (Gupta, [0034], [0053], see the rejection of claim 8). Claim 14 recites its methods in the alternative, and the rejection relies on the overwriting alternative. The designations set forth in the rejection of claim 8 above, and the findings of analogous art, motivation and reasonable expectation of success set forth in the rejection of claim 7 above apply equally to this modification, in which the selection taught by Gupta 950 is applied to the combination of Le and Gupta 299.
19. Claim 15 is rejected under 35 U.S.C. § 103 as being unpatentable over Le in view of Gupta (US 2021/0089299 A1) and Gupta (US 2018/0004950 A1) as applied to claims 11 and 13 above, and further in view of Duale et al. (US2018/0173880 A1), hereafter Duale.
The ground is restated over amended clam 11 and the change is necessitated by the applicant’s amendment.
Regarding claim 15, Le in view Gupta 299 and Gupta 950 teaches the elements of claim 13 as set forth above, including the selection of a fencing method based on the determined code characteristics (see the rejection of claim 13 above. The combination does not teach identifying, based on not identifying sensitive code in the code areas to be fenced, a fencing method using a processor hardware based function that sets a non-executable state for the fenced code areas, where the processor hardware based function comprises using Instruction Execution Protection (IEP). Duale cures this deficiency. {Duale [0004], quoted in the rejection of claim 9 above.} Also see [0020] and [0023] of Duale. The designations and the findings of analogous art, motivation and reasonable expectation of success set forth in the rejection of claim 9 above apply equally to this modification.
Response to Arguments
20. Applicant’s arguments filed July 24, 2026 have been full considered. For claims 1 and 2, applicant argues that the rejection “has not sufficiently explained the pertinence of the cited Le passages….as required by 37 C.F.R. 1.104(C)(2),” that it “does not sufficiency explain how le discloses the claimed sequence as recited,” and that Le’s automated operation does not ‘established the particular input request recited in claim 1.” The restated rejection above supplies express designations for each limitation. As to the sequence, claim 1 recites no step of disabling and no required interval between the program objects becoming disabled and the fencing being applied. The wherein clause state the objects becoming disabled and the fencing being applied. The wherein clause states the program objects’ condition. Le disclose the order. Trap code is written at launch for blocks already in the not-activated state (Para. 0037, 0039), and step 680 identifies the blocks before step 685 writes the trap code (Para. 0044, 0045). The input request, the identification, and the automation function are designated in the restated rejections of claims 1 and 2 above. Claim 2 recites its sources in the alternative.; the rejection relies on the automation function.
21. For claim 3, applicant argues that “Applicant cannot discern with sufficient particularity” how the recording of Gupta “teaches or suggest’ identifying registered function and tagging code modules…” and that the interview discussion “confirms that the cited Gupta disclosure does not clearly teach the tagging relationship recited in claim 3.” The tagging relationship discussed at the interview is the tagging of code modules in the program code. The limitation resides in amended claim 11, not in claim 3, and is addressed under the ground over Gupta (US2021/00892299 A1). Claim 3 does not recite where the tag resides. The recording of an enumeration and the start and end memory addresses for each code block of a functionality tags the code block as related to that functionality (Gupta, US 2018/0004950A1: [0042]), as designated in the restated rejection of claim 3 above.
22. For claim 4, applicant argues that Boling’s “address-to-metadata mapping” does not teach the claimed “code path mapping table for each registered function,” and that the motivation is insufficiently explained. The restated rejection designates Boling’s named entities, the name matching, the object-code annotation, and the entries for the loaded instructions (Boling, [0094-0097, 0100]). Claim 4 recites what the table comprises, not the orientation of its entries. A supplemental motivation is added (Gupta, US2018/0004950A1, [0042, 0043) while the original motivation is retained (Boling, [0202]).
23. For claim 6, applicant argues that the rejection “does not sufficiently identify in Gupta” the disabled registered function, its code module, its fenced or not fenced status, or the application of hard fencing code based on that status. The rejection rests on the combination, not on Gupta (US2018/0004950A1) alone, and nonobviousness cannot be shown by attacking references individually where the rejection is based on a combination of references. See MPEP § 2145(IV). The restated rejection of claim 6 above identifies where each item resides: the disabled registered functions in the rejection of claims 3, the code modules and their code areas in the code path mapping table of 4, and the status of fenced or not fenced in the fenced-code table of claim 5, and the applying of hard fencing code in the overwriting of Gupta (US2018/0004950A1, [0033], [0034]).
24. For claims 7 and 8, applicant argues that selecting runtime or load-time lockdown based on whether code is self-generating or interpretive does not teach the sensitivity-based identifying recited in claim 7 and claim 8. Claim 7 does not define sensitive code. Under the broadest reasonable interpretation, it encompasses code presenting heightened risk, which self-generating or interpretive code presents through a greater chance of exploitation. A permanent load-time overwrite and a temporary runtime overwrite are different fencing methods, and selecting between them based on the determined code characteristic is identifying a fencing method based on identifying sensitive code. For claim 8, the overwriting alternative is relied upon (Gupta US2018/0004950A1, [0034]; Le, [0025]). See the restated rejections of claims 7 and 8 above.
25. The rejections for claims 9, 10 and 12 were not separately argued and are maintained as restated above.
26. For claims 11 and 13-15, applicants argues that the secondary references “do not show the amended combination of a functional registry identifying enabled and disabled status of registered functions, code modules tagged in the program code…” The argument addresses the prior ground. Amended claims 11 and 13-15 are rejected above on new grounds over Gupta (US 2021/0089299 A1), necessitated by the amendment.
27. Amended claim 16 incorporates the subject matter of canceled claims 18 and 19 and is rejected above under 35 U.S.C. § 103 over Le in view of Gupta (US 2018/0004950A1), the ground previously applied that subject matter. The change from 35 U.S.C. § 102 is necessitated by the amendment.
28. Claims 21-24 are new claims. Applicant stated that these claims are not taught or teach by the applied art. The new claims are rejected above on ground newly applied to them.
29. The rejection of claim 5 under 35 U.S. C. § 112(b) was not addressed in the arguments filed July 24, 2026 and is maintained above.
Conclusion
30. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Gupta et al. (US 10,079,841 B2) discloses building tables of function start and end addresses and overwriting instructions outside the needed set at load time.
31. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
31. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BIN QING ZHENG whose telephone number is 703-756-1535. The examiner can normally be reached on M-F at 10:00 am - 06:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip J. Chea can be reached on 571-272-3951. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BIN QING ZHENG/
Examiner, Art Unit 2499
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
