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 December 3, 2025 has been entered.
Response to Arguments
Applicant’s arguments, see REMARKS/ARGUMENTS, filed December 3, 2025, with respect to the rejection of claims 1 – 20 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of new art found in a search of the prior art considering the amended claims.
Claim Rejections - 35 USC § 103
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.
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 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Banabic et al. (NPL, Fast Black-Box Testing of System Recovery Code), hereinafter Banabic, in view of Marinescu et al. (NPL, LFI: A Practical and General Library-Level Fault Injector), hereinafter Marinescu.
Regarding claim 1, Banabic teaches:
A computer-implemented method, comprising:
intercepting, during execution of a software component being tested (CBT) by a processor, a call invoked by the CBT during execution of the CBT (Page 9 Fault Space Definition Methodology paragraph 2, the LFI injector is used to inject error returns into calls made to functions in the standard C library libc.so) by a processor (Page 9 Experimental Platform describes the processors used), the CBT comprising one or more instructions executable by the processor (Page 9 Fault Space Definition Methodology, The CBT is the C library);
determining context information for the call, the context information comprising information identifying a fault location associated with the call (Pages 5 and 6 Injection Point Precision, system chooses an injection point for the fault, which includes the specific location in the program to inject it);
performing processing to determine whether to inject a fault for the call at the fault location associated with the call, the processing comprising, based on historical fault injection data stored for the CBT and the context information determined for the call, determining if a fault is to be injected for the call (Page 3 section 3 Fault Exploration, the fault injector explores the fault space to determine which fault is to be injected. Page 4 Algorithm 1, this determination considers the history of all previously executed tests, and the identity of the context information for the call represented by ϕ), wherein the historical fault injection data stored for the CBT includes data for previously injected faults for the CBT (The history in Algorithm 1) and historical context information, wherein the historical context information comprises, for each previously injected fault, information identifying a location in the CBT at which the previously inject fault was injected and information identifying any arguments for the previously injected fault (The history in Algorithm 1 stores the identifiers for previously injected faults; Page 2, the identifiers consist of a vector of attributes for the faults, including the call the fault was injected at);
in response to determining that a fault is to be injected, identifying a particular fault to be injected and injecting the particular fault at the fault location (Algorithm 1, a new fault is added to the queue of tests awaiting execution; Page 4 left column, the new test is executed).
Banabic does not explicitly teach that the context information for the call comprises information identifying arguments provided as input to the call (Although implied by Figs. 3 – 5 on Page 8, Banabic does not explicitly explain the fields of the fault space), nor does it teach, in response to determining that a fault is not to be injected, invoking a library implementation corresponding to the call (Banabic focuses on the scenario where a fault is to be injected. Although it can be reasoned that a library implementation is invoked, Banabic does not explicitly recite this scenario).
Marinescu teaches LFI, the fault injector used by Banabic. Marinescu teaches that, in LFI, the context information for the call comprises information identifying arguments provided as input to the call (Page 383, Fault Injection Scenarios, a fault trigger modifies an argument of the function. Because Banabic uses LFI, it follows that the fault space and fault parameters include this information), and in response to determining that a fault is not to be injected, a library implementation corresponding to the call is invoked (Page 384, Interception Mechanisms example code stub, if the eval_trigger returns false, determining that the fault is not to be injected, the original library function is invoked).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention that the context information would comprise arguments provided as input to the call, and that, if a fault is not to be injected, a library implementation corresponding to the call would be invoked. It would be obvious because Banabic directly cites Marinescu as the fault injector it is based on (Banabic page 3 Fig. 1, and Page 9 Fault Space Definition Methodology, the base fault space is created by LFI). It would be clear to one of ordinary skill in the art that the fault space would contain the faults provided by LFI, and that any information on LFI not described in Banabic may be found in Marinescu.
Regarding claim 2, Banabic in view of Marinescu teaches the method of claim 1, wherein the context information identifies a function or a workflow that caused the call to be invoked (Banabic page 6 left column, the injection point is partially defined by the cardinality of the call and the test from the test suite).
Regarding claim 3, Banabic in view of Marinescu teaches the method of claim 1, wherein:
performing processing to determine whether to inject the fault comprises selecting a particular fault to be injected based upon the historical fault injection data for a combination of the call and associated particular context (Banabic Algorithm 1 line 12, if the fault to be injected has already been called, based on its identifier/context, then it is not added to the queue of faults to inject); and
injecting the fault at the fault location during execution of the CBT comprises injecting the selected particular fault into the CBT by providing the selected particular fault to the CBT as a response to the call (Banabic page 2 Fault Space, returning an error code to a call is one type of fault that can be injected; Marinescu page 384 stub code, the interceptor returns a modified return code to the call).
Regarding claim 4, Banabic in view of Marinescu teaches the method of claim 3, wherein selecting the particular fault comprises:
determining, based on the historical fault injection data, a particular type of fault that has not been previously injected for the combination (Banabic Algorithm 1 lines 6 – 12, the algorithm generates a new fault by changing one attribute of a previous fault, making it a new type of fault for the combination. Line 12 checks to determine if the fault has not been previously injected); and
selecting the particular fault for injection to be of the particular type of fault (Banabic Algorithm 1 lines 13, the fault is added to the queue).
Regarding claim 5, Banabic in view of Marinescu teaches the method of claim 3, wherein selecting the particular fault comprises selecting a default type (Banabic page 9 Fault Space Definition Methodology, the fault space is defined by the default test suites of the test targets) or a customized fault type, and wherein the customized fault type is using configuration information provided to a computing system (Banabic page 5 Leveraging Domain Knowledge, the system can instead use existing knowledge on what tests are effective to select tests).
Regarding claim 6, Banabic in view of Marinescu teaches the method of claim 5, wherein:
intercepting the call from the CBT is performed by a dynamic proxy handler of the computing system that is configured to intercept the call, obtain the context information, and inject the select particular fault into the CBT (Marinescu page 384, LFI intercepts calls, checks the context, and injects the fault);
determining whether the fault is to be injected is performed by a fault driver of the computing system that is configured to select the particular fault for injection into the CBT (AFEX, the system of Banabic selects what faults are to be injected; Banabic Page 7 Fig. 2 shows the AFEX Explorer).
Regarding claim 7, Banabic in view of Marinescu teaches the method of claim 1, wherein determining whether the fault is to be injected comprises determining whether to inject multiple faults sequentially or at least partially in parallel (Banabic page 9 Fault Space Definition Methodology, although the evaluation of the system is limited to single-fault scenarios, AFEX is capable of exploring a fault space which contains multi-fault scenarios; Marinescu page 386 6.4 Performance Overhead, LFI can simultaneously perform fault injection on multiple calls).
Regarding claim 8, Banabic teaches a system comprising one or more processors (Page 9 Experimental Platform, the CPUs used to run the experiments); and
a memory couple to the one or more processors, the memory storing a plurality of instructions executable by the one or more processors, the plurality of instructions comprising instructions executable by the one or more processors to cause the one or more processors to perform operations (Page 9 Experimental Platform, the RAM and HDD).
Claims 8 – 14 otherwise recite similar language to claims 1 – 7, and are similarly rejected.
Regarding claim 15, Banabic teaches a non-transitory computer-readable memory storing a plurality of instructions executable by one or more processors, the plurality of instructions comprising instructions that when executed by the one or more processors cause the one or more processors to perform operations (Page 9 Experimental Platform, the CPUs, RAM, and HDD used to run the experiments).
Claims 15 – 19 otherwise recite similar language to claims 1, 3, 4, and 5, and are similarly rejected.
Regarding claim 20, Banabic in view of Marinescu teaches the non-transitory computer-readable memory of claim 10, wherein the configuration is specific for a fault injection system for controlling faults, at a CBT-level (Banabic page 5 Leveraging Domain Knowledge, the existing knowledge on the system being tested is used to determine which tests to first select), that are injected by the fault injection system.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Brouwer et al. (US Patent 6,279,124) and Lang (US Patent 7,356,432) teach methods for selecting tests.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRYAN PAI SONG HUANG whose telephone number is (571)272-0510. The examiner can normally be reached Monday - Friday 11:30 AM - 8:30 PM.
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, ASHISH THOMAS can be reached at (571) 272-0631. 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.
/B.P.H./ Examiner, Art Unit 2114
/ASHISH THOMAS/ Supervisory Patent Examiner, Art Unit 2114