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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on June 24, 2025 has been entered.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3, 5-10, 12 and 14-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite methods and systems for modifying test case coverage.
The limitations in Independent Claims 1 of 10, as drafted, are processes that, under their broadest reasonable interpretation, covers steps that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitations of “determining differences between first and second versions of firmware,” “identifying, based on the differences between the first and second versions, one or more impacted functions,” “modifying the binary code for the second version of firmware…to cause the one or more impacted functions, when called, to return an error value,” “determining, for each impacted function, configuration information indicative of: a return type (RTYPE)…and; an instruction location (ILOC)…determining, based on the RTYPE and a CPU architecture of the device under test, instruction data (IDATA),” “identifying any test cases returning the error value as selected test cases”, “including the selected test cases within target test cases for performing regression testing of the second version,” and “excluding, from the plurality of test cases run on the modified binary code, existing test cases, comprising any test case indicated by the mapping data as having an existing association with any of the one or more impacted functions” in Claims 1 and 10, as drafted, are processes that, under their broadest reasonable interpretation, recite the abstract idea of mental processes. These limitations encompass a human mind carrying out these functions through observation, evaluation judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas.
This judicial exception is not integrated into a practical application. Claims 1 and 10 recite the following additional elements “loading binary code for the second version of firmware into a random access memory of a device under test”, “modifying the binary code… stored in the random access memory” and “accessing mapping data indicative of existing associations between functions and test cases”, these limitations do nothing more than add insignificant extra solution activity to the judicial exception, such as data gathering and outputting the results of the abstract idea, see MPEP 2106.05(g). Furthermore, the “loading binary code…”, “modifying the binary code… stored in the random access memory” and “accessing mapping data…” elements recite functions which the courts have recognized as well‐understood, routine, and conventional (i.e. storing and retrieving information in memory) since they are recited at a high-level of generality. With regard to the additional limitations which recite, “a memory of a device under test” in Claims 1 and 10, these limitations do nothing more than generally link the judicial exception to a particular technological environment, see MPEP 2106.05(h).
Further, the “memory”, “overwriting the binary code at the ILOC with the IDATA” and “running a plurality of test cases once on the modified binary code” elements of Claim 1 and 10, as well as the additionally recited “central processing unit (CPU),” and “memory, accessible to the CPU” elements of Claim 10 are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, see MPEP 2106.05(f). Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea, thus failing to integrate the abstract idea into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements which recite “modifying binary code for the second firmware version, stored in a memory of a device under test …,” “running a plurality of test cases once on the modified binary code” in Claims 1 and 10; “central processing unit (CPU),” and “memory, accessible to the CPU” in Claim 10; amount to no more than mere instructions to apply the exception using well-known, routine and conventional generic computer component, and merely gathering data and outputting the results of the judicial exception which cannot provide an inventive concept. See MPEP 2106.05(d). Thus, Claims 1 and 10 are not patent eligible under 35 U.S.C.101.
With regard to the individual dependent claims:
Claims 3 and 12 recite, “including the existing test cases within the target test cases.”
Claims 7 and 16 recite, “wherein determining the configuration information comprises determining the RTYPE based on static analysis of source code for the firmware.”
Claims 8 and 17 further recite, “…determining the ILOC by: calculating an offset for the function… and identifying the last instruction in the function storing a value to the function return register.”
Claims 9 and 18 recite, “wherein the CPU architecture and the corresponding return value register are selected from: an ARM CPU architecture and the r0 register; and an Intel CPU architecture and the eax register.”
These limitations of Claims 3, 7-9, 12 and 16-18, as drafted, are processes that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. These limitations encompass a human mind carrying out this function through observation, evaluation judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claims 5 and 14 recite, “prior to overwriting the binary code at the ILOC, reading the binary code at the ILOC and storing the binary code for subsequently rolling back the binary code at the ILOC.”
Claims 8 and 17 recite, “debug information generated by a compiler… disassembling the binary code for the function into assembler code.”
These limitations of Claims 5, 8, 14 and 17 do nothing more than add insignificant extra solution activity to the judicial exception, such as data gathering, transmitting and outputting the results of the abstract idea, see MPEP 2106.05(g). Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Further, these limitations of Claims 5, 8, 14 and 17 amount to no more than mere instructions to apply the exception using well-understood, routine and conventional computer components and functions, recited at a high level of generality, i.e. receiving/transmitting data over a network and storing/retrieving information in memory. As such, these additional elements do not amount to an inventive concept and are not by themselves sufficient to transform the judicial exception into a patent eligible invention, see MPEP 2106.05(d).
Claims 6 and 15 recite, “wherein said modifying of the binary code is performed by a baseboard management controller of an information handling system.”
These limitations of Claims 6 and 15 are recited at a high-level of generality such that they amount to no more than mere instructions to apply the exception using generic computer components, see MPEP 2106.05(f). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Further, these limitations of Claims 6 and 15 amount to no more than mere instructions to apply the exception using well-understood, routine and conventional computer components and functions, recited at a high level of generality, i.e. receiving/transmitting data over a network and storing/retrieving information in memory. As such, these additional elements do not amount to an inventive concept and are not by themselves sufficient to transform the judicial exception into a patent eligible invention, see MPEP 2106.05(d).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 6, 10, 12 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Friedel et al. (US PGPUB 2022/0194775; hereinafter “Friedel”) in view of Deng et al. (US Patent 8,276,123; hereinafter “Deng”), Zhou et al. (US Patent 7,757,215; hereinafter “Zhou”), Rugina et al. (US PGPUB 2014/0289564; hereinafter “Rugina”) and Yim et al. (US PGPUB 2018/0060221; hereinafter “Yim”).
Claim 1: (Currently Amended)
Friedel teaches a test case selection method, comprising:
determining differences between first and second versions of firmware ([0022] “The fuel pump test environment 101 can be used to perform functional testing of a fuel pump and a fuel computer with one or more software versions and/or firmware versions installed.” [0038] “Each different release may be tested using a set of test cases 156 that may include both legacy or regression test cases as well as newly defined test cases directed specifically at changes introduced in the subject release,” wherein the “test cases directed specifically at changes introduced in the subject release” necessarily indicates a process of “determining differences”.); and
loading binary code for the second version of firmware into a random access memory of a device under test ([0061] “Additionally, after the system 380 is turned on or booted, the CPU 382 may execute a computer program or application. For example, the CPU 382 may execute… firmware… stored in the RAM 388,” wherein the “firmware” must necessarily have been “loaded” in to the “RAM 388” sometime after booting the system since the “RAM 388” is a volatile type memory and as such would have been empty immediately after booting the system. [0018] “Firmware is a specific class of software that may refer to relatively low-level logic instructions,” wherein the “low-level logic instructions” are “binary code”.);
the second version of firmware, stored in the random access memory of a device under test ([0061] “firmware… stored in the RAM 388,” as discussed above. [0018] “Fuel pump system testing is manually intensive because of the desired inclusion of physical fuel pump hardware in the testing system… Firmware is a specific class of software that may refer to relatively low-level logic instructions and data… to control how that hardware device operates.”).
With further regard to Claim 1, Friedel does not teach the following, however, Deng teaches:
identifying, based on the differences between the first and second versions, one or more impacted functions (Col. 5 Ln. 59: “a method comprises determining, with a computing device, those functions of source code whose lines of code have changed between different versions of the software program, determining, with the computing device, those of the functions of the source code whose lines of code have not changed but have been impacted by the changes based on dependency data and the determined changed functions, wherein the dependency data defines dependencies between the functions of the source code”)
accessing mapping data indicative of existing associations between functions and test cases (Col. 17 Ln. 4: “coverage data 28 may indicate that test case 26A exercises blocks 1-3 of a function, and test case 26B exercises blocks 2-4 of the same function.”); and
excluding, from the plurality of test cases run on the modified binary code, existing test cases, comprising any test case indicated by the mapping data as having an existing association with any of the one or more impacted functions (Col. 17 Ln. 15: “if both test cases 26A and 26B exercise the same set of blocks 1-3 of this function, intelligent RTS module 22 may select only one test case for this specific block combination and discard the other.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Friedel with the identification of impacted functions and test case exclusion as taught by Deng in order “to improve the efficiency of regression testing” (Deng Col. 8 Ln. 1).
With further regard to Claim 1, Friedel in view of Deng does not teach the following, however, Zhou teaches:
modifying the binary code for the second version of firmware, to cause the one or more impacted functions, when called, to return an error value (Col. 1 ln. 44: “The system further comprises a library that includes a fault injected version of the function called by the program binary. The system also includes a script that includes instructions for suspending the execution of the program binary when the function symbol is encountered, dynamically linking the function symbol to the fault injection version of the function included in the library, and resuming the execution of the program binary.” Col. 3 Ln. 46: “Program 110 is a binary file generated from the compilation of source code that has been selected for testing.” Col. 6 Ln. 31: “At step 206… the Fault Injection Library 108s can be customized library generated to include fault injected versions of the user-defined function(s) or module(s) called by Program 110.” Col. 6 Ln. 51: “determine how a software module will respond to an error returned from a call to an error-injected function.”),
running a plurality of test cases once on the modified binary code (Col. 7 Ln. 1: “At step 208, in an embodiment of the present invention, the binary version of Program 110 is executed within the Dynamic Trace Framework 106 according to instructions dynamically provided to the Dynamic Trace Framework 106 by the Algorithmic Script 103”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Friedel in view of Deng with the modification of binary code to cause errors as taught by Zhou in order to “allow a tester to utilize dynamically linked fault-injected functions of Library(s) 108 to perform any type of testing necessary to provide comprehensive testing of a software system” (Zhou Col. 6 Ln. 59).
Friedel in view of Deng and Zhou does not teach the following, however, Rugina teaches wherein modifying the binary code comprises:
determining, for each impacted function, configuration information indicative of ([0014] “a .vmx file for that VM, which stores configuration settings for that VM including configuration settings associated with VProbes,” wherein the “.vmx file” comprises the “configuration information” as further discussed below. [0017] “faults may be injected via probes to test the system's response… For example, a probe may modify a function's return value”):
a return type (RTYPE) of the impacted function ([0003] “A probe script is employed in VProbes as a mechanism to dynamically inject code for probing software modules.” [0028] “At step 414, the probe that is triggered writes a predefined test value to a return value register… The particular test value that is used may be specified in the probe script, and may generally depend on the function being instrumented,” wherein the “particular test value” specified by the “probe script” comprises the “return type”.) and
an instruction location (ILOC) for an instruction loading a return value to a return value register ([0029] “At step 416, the probe causes the function to be skipped... the probe may update an instruction pointer (e.g., the EIP x86 register) to point to the function's return instruction address,” wherein the “return instruction address” is the “ILOC”.);
determining, based on the RTYPE and a CPU architecture of the device under test, instruction data (IDATA) for loading the return value register with an error value ([0028] “At step 414, the probe that is triggered writes a predefined test value to a return value register (e.g., the EAX x86 register). Doing so permits the test value to be returned in lieu of the value which would otherwise be returned by the function. The particular test value that is used may be specified in the probe script, and may generally depend on the function being instrumented.” [0020] “For example, a test value of null may be returned during memory allocation to simulate an out-of-memory state. Behavior after the error is injected may then be observed,” wherein “null” is “an error value”.); and
overwriting the binary code at the ILOC with the IDATA ([0029] “At step 416, the probe causes the function to be skipped. That is, the function itself does not execute, and the test value is returned… Any feasible technique may be employed to skip function execution. For example, the probe may update an instruction pointer (e.g., the EIP x86 register) to point to the function's return instruction address, thereby causing the return instruction to execute.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Friedel in view of Deng and Zhou with the return type and error value loading as taught by Rugina in order “to test the system's response in various circumstances” (Rugina [0017]) and “such that undesired behavior (e.g., crashes) can be identified and/or corrected” (Rugina [0020]).
With further regard to Claim 1, Friedel in view of Deng, Zhou and Rugina does not teach the following, however, Yim teaches:
identifying any test cases returning the error value as selected test cases; and including the selected test cases within target test cases for performing regression testing of the second version ([0011] “methods configured to perform the operations of the processor of the regression testing system according to the instructions stored in the regression testing system's memory.” [0024] “If the currently injected software fault causes at least one test of the second test suite to fail, a test case corresponding to the currently injected software fault is added to the first test suite or the currently injected software fault is flagged for test case creation (to be added to the first test suite).” [0055] “For example, if execution of a test case from the second test suite results in an ArrayOutOfBounds Exception, the test suite generator may determine a test case corresponding to the injected fault causing the ArrayOutOfBounds Exception… when the fault injector injected the fault causing the ArrayOutOfBounds Exception”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Friedel in view of Deng, Zhou and Rugina with the identification and selection of test cases as taught by Yim since “it may be difficult to identify the location of the fault causing the defect” (Yim [0042]).
Claim 3: (Currently Amended)
Friedel in view of Deng, Zhou, Rugina and Yim teaches the method of claim 1. However, Friedel in view of Zhou, Rugina and Yim does not teach the following, but Deng teaches further comprising:
including the existing test cases within the target test cases (Col. 21 Ln. 20: “Impact analyzer 58 forwards changed and impacted function list 62 to test selection engine 60. Upon receiving this list 62, test selection engine 60 begins selecting those of test cases 26 that uniquely cover those changed and impacted functions indicated by list 62.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Friedel in view of Zhou, Rugina and Yim with the test case exclusion as taught by Deng in order “to improve the efficiency of regression testing” (Deng Col. 8 Ln. 1).
Claim 6: (Currently Amended)
Friedel in view of Deng, Zhou, Rugina and Yim teaches the method of claim 1. However, Friedel in view of Deng, Rugina and Yim does not teach the following, but Zhou teaches further comprising:
wherein said modifying of the binary code is performed by a baseboard management controller of an information handling system (Col. 5 Ln. 56: “the Dynamic Trace Framework 106 can be implemented as any module, system etc. that is capable of dynamically modifying and tracing software processes etc. to examine and collect information about the behavior of software programs etc. during execution.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Friedel in view of Deng, Rugina and Yim with the hardware implementation as taught by Zhou in order to “allow a tester to utilize dynamically linked fault-injected functions of Library(s) 108 to perform any type of testing necessary to provide comprehensive testing of a software system” (Zhou Col. 6 Ln. 59).
Claims 10, 12 and 15:
With regard to Claims 10, 12 and 15, these claims are equivalent in scope to Claims 1, 3 and 6 rejected above, merely having a different independent claim type, and as such Claims 10, 12 and 15 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1, 3 and 6.
With further regard to Claim 10, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Friedel reference also anticipates these additional elements of Claim 10, for example, wherein the information handling system comprises:
a central processing unit (CPU) ([0059] “FIG. 6 illustrates a computer system 380 suitable for implementing one or more embodiments disclosed herein. The computer system 380 includes a processor 382 (which may be referred to as a central processor unit or CPU)”); and
a memory, accessible to the CPU, including processor executable instructions that, when executed by the CPU, cause the system to perform test case selection operations ([0060] “It is understood that by programming and/or loading executable instructions onto the computer system 380, at least one of the CPU 382, the RAM 388, and the ROM 386 are changed, transforming the computer system 380 in part into a particular machine or apparatus having the novel functionality taught by the present disclosure.” [0061] “the CPU 382 may copy the application or portions of the application from the secondary storage 384 to the RAM 388 or to memory space within the CPU 382 itself, and the CPU 382 may then execute instructions that the application is comprised of.”).
Claims 5 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Friedel in view of Deng, Zhou, Rugina and Yim as applied to Claims 1 and 10 above, and further in view of Kalla et al. (US PGPUB 2009/0249301; hereinafter “Kalla”).
Claim 5: (Currently Amended)
Friedel in view of Deng, Zhou, Rugina and Yim teaches all the limitations of claim 1 as described above. Friedel in view of Deng, Zhou, Rugina and Yim does not teach the following, however, Kalla teaches further comprising,
prior to overwriting the binary code at the ILOC, reading the binary code at the ILOC and storing the binary code for subsequently rolling back the binary code at the ILOC ([0041] “If a source operand is to be modified (to inject a fault), the operand is logged and then modified at block 260, and then the modified instruction is executed at block 270. The operand that was modified is then restored to the previously logged value at block 280.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Friedel in view of Deng, Zhou, Rugina and Yim with the rolling back of code as taught by Kalla “in order to measure the software impact of a hardware soft error on an application program/operating system” (Kalla [0012]), and further wherein the ability to roll-back the fault injection simplifies restoration of the code to a prior fault-free state.
Claim 14:
With regard to Claim 14, this claim is equivalent in scope to Claim 5 rejected above, merely having a different independent claim type, and as such Claim 14 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 5.
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Friedel in view of Deng, Zhou, Rugina and Yim as applied to Claims 1 and 10 above, and further in view of Nair et al. (US PGPUB 2024/0232050; hereinafter “Nair”)
Claim 7: (Currently Amended)
Friedel in view of Deng, Zhou, Rugina and Yim teaches the method of claim 1. However, Friedel in view of Deng, Zhou, Rugina and Yim does not teach the following, however, Nair teaches
wherein determining the configuration information comprises determining the RTYPE based on static analysis of source code for the firmware ([0007] “the software testing tool may be configured to identify the return types of the identified function.” [0068] “the return errors 216 and the return types 218 corresponding to one or more external functions may be identified by one or more lines of code in the code-under-test 202 that may provide the return errors 216 and return types 218 corresponding to one or more external functions 212,” wherein the analysis of program code described in Nair is “static analysis” since it is performed on code prior to runtime.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Friedel in view of Deng, Zhou, Rugina and Yim with the return type and error value loading as taught by Nair in order to “help improve error testing of software programs, and thus may also help improve the software programs themselves” (Nair [0010]).
Claim 16:
With regard to Claim 16, this claim is equivalent in scope to Claim 7 rejected above, merely having a different independent claim type, and as such Claim 16 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 7.
Claims 8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Friedel in view of Deng, Zhou, Rugina and Yim as applied to Claims 1 and 10 above, and further in view of Yang et al. (US PGPUB 2015/0363198; hereinafter “Yang”).
Claim 8: (Currently Amended)
Friedel in view of Deng, Zhou, Rugina and Yim teaches all the limitations of claim 1 as described above. Friedel in view of Deng, Zhou, Rugina and Yim does not teach the following, however, Yang teaches wherein determining the configuration information comprises determining the ILOC by:
calculating an offset for the function from debug information generated by a compiler to locate binary code corresponding to the function ([0021] “the disassembler 110 may include two debugger components used to correct such inaccuracies: a tracker component 205 and a parser component 210. The tracker component 205 is configured to receive indirect function call information 215 from the target module 115.” [0022] “the target module 115 includes indirect function call information 215. The indirect function call information 215 may include memory addresses corresponding to the location of the function call.”);
disassembling the binary code for the function into assembler code ([0006] “One embodiment includes a method for disassembling compiled object code. The method may generally include disassembling a binary executable object to generate assembly language source code.”); and
identifying the last instruction in the function storing a value to the function return register ([0029] “the parser component 220 may replace register values specified in an indirect function call with function names obtained from the tracker component 205.” [0015] “the disassembler captures information generated by the instructions (e.g., the called address, register values, etc.)”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Friedel in view of Deng, Zhou, Rugina and Yim with the determination of configuration information as taught by Yang in order “to use the captured information to identify and correct function names that are inaccurate in the disassembled code” (Yang [0015]).
Claim 17:
With regard to Claim 17, this claim is equivalent in scope to Claim 8 rejected above, merely having a different independent claim type, and as such Claim 17 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 8.
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Friedel in view of Deng, Zhou, Rugina, Yim and Yang as applied to Claims 8 and 17 above, and further in view of Yi et al. (US PGPUB 2022/0164446; hereinafter “Yi”).
Claim 9:
Friedel in view of Deng, Zhou, Rugina, Yim and Yang teaches all the limitations of claim 4 as described above. Friedel in view of Deng, Zhou, Rugina, Yim and Yang does not teach the following, however, Yi teaches wherein the CPU architecture and the corresponding return value register are selected from:
an ARM CPU architecture and the r0 register; and an Intel CPU architecture and the eax register ([0130] “make a change to the register through a register replacer 531. In general, in the case of Intel CPU, the return value of method is stored in EAX or RAX register, and in the case of ARM CPU, the return value of method is stored in R0-R3 register.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Friedel in view of Deng, Zhou, Rugina, Yim and Yang with the CPU and corresponding register types as taught by Yi in order enable the method “to change an execution flow of the instruction by inserting IR that changes a value of a specific register after a return value of the method is stored or changes the register value after execution” (Yi [0033]).
Claim 18:
With regard to Claim 18, this claim is equivalent in scope to Claim 9 rejected above, merely having a different independent claim type, and as such Claim 18 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 9.
Response to Arguments
Applicant’s arguments, see Page 8 of the Remarks filed June 24, 2025, with respect to the rejections under 35 U.S.C. 101 of Claims 1, 3, 5-10, 12 and 14-18 have been fully considered but they are not persuasive.
With respect to the Applicant’s argument, Page 8 Paragraph 2, that “Applicant respectfully submits that the additional limitations recited in the amended independent claims integrate the subject recited in previously presented claim 1 into a practical application…,” the Office respectfully disagrees. The Office notes that these amended claim limitations were originally presented in dependent Claims 2, 4, 11 and 13, and no further amendments were made to the claim language when it was incorporated into Claims 1 and 10. The Office maintains, as originally stated in the previous Final Rejection, that the amended limitations either recite the abstract idea of a mental process, do nothing more than add insignificant extra solution activity, or amount to no more than mere instructions to apply the exception using a generic computer component, and directs the Applicant’s attention to the modified 35 U.S.C. 101 rejection above for further details.
As discussed above in the 35 U.S.C. 101 rejection, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception and the Office maintains that amended limitations do not integrate the abstract idea into a practical application.
Therefore, for at least the reasons discussed above, the 35 U.S.C. 101 rejection of Claims 1, 3, 5-10, 12 and 14-18 has been maintained.
Applicant's arguments, see Pages 8-10 of the Remarks, with respect to the rejections under 35 U.S.C. 103 of Claims 1, 3, 5-10, 12 and 14-18 have been fully considered but they are not persuasive.
With respect to the Applicant’s argument, Page 8 Paragraph 6 of the Remarks, that the newly amended language of Claims 1 and 10 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Rugina et al. (US PGPUB 2014/0289564) reference as discussed above in the respective rejections.
With respect to the Applicant’s further arguments, Pages 9-10 of the Remarks, that the features of the remaining claims are not taught by the cited prior art, the Office respectfully disagrees. These arguments rely upon the arguments as presented in relation to Claims 1 and 10 discussed above, and as such the Office directs the Applicant to the responses above regarding these arguments.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Chen (US PGPUB 2024/0193076) discloses techniques for injecting faults by instrumentation code, wherein an instrumentation module is able to change the state of method parameters which are returned from the response portion of the software code.
Guthoff et al. (“Combining Software-Implemented and Simulation-Based Fault Injection into a Single Fault Injection Method,” 1995) discusses results obtained from software-based and simulation-based fault injection experiments, as well as a mixed-mode fault injection approach which combines software-implemented and simulation-based fault injection techniques.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joanne G. Macasiano whose telephone number is (571)270-7749. The examiner can normally be reached Monday to Thursday, 10:30 AM to 6:00 PM Eastern Standard Time.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/J.G.M/Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197