DETAILED ACTION
Claims 1-14 and 16-19, 24 and 25 are pending. Claims 1, 3-5, 8-10, 16 and 17 have been amended. Claim 22 and 23 have been cancelled. Claims 24 and 25 are new.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This final office action is in response to the applicant’s response received on 06/09/2026, for the non-final office action mailed on 04/03/2026.
Examiner’s Notes
Examiner has cited particular columns and line numbers, paragraph numbers, or figures in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant, in preparing the responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Arguments
Applicant's arguments filed 06/09/2026 with regards to rejection made under 35 U.S.C. § 103 with regards to claims 1, 10 and 17 have been fully considered but are moot in view of new ground(s) rejection.
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.
Claim(s) 1 and 10-14 are rejected under 35 U.S.C. 103 as being unpatentable over Nath et al. (US-PGPUB-NO: 2022/0391314 A1) hereinafter Nath, in further view of Rozenman et al. (US-PGPUB-NO: 2015/0339214 A1) hereinafter Rozenman and Pistoia et al. (US-PGPUB-NO: 2012/0144491 A1) hereinafter Pistoia.
As per claim 1, Nath teaches a method comprising: identifying, by a computing device, software code (see Nath paragraph [0038], “The fault determiner 144 determines one or more faults to generate (and/or simulate) in the received SDK. In aspects, the fault determiner 144 analyzes code in the received SDK to identify commands and public methods that are available as API 116 to the client application 112 to use”); receiving, by the computing device, one or more fault configuration settings corresponding to one or more faults for fault injection (see Nath paragraph [0036], “The fault configuration data store 124 includes a set of faults and settings of whether to generate respective failures for testing the client application 112. For example, the fault configuration data may specify whether to generate a failure that results from the 401 error from the cloud server 130”); based on the one or more fault configuration settings, wherein the instrumentation code is configured to simulate the one or more faults (see Nath paragraph [0058], “Inject operation 412 injects a set of code that generate faults in the SDK. For example, the inject operation 412 injects codes that simulates a fault. The fault may indicate a network disconnect. The code may return a network timeout error to a command that attempts establishing a connection with a remote server. In some other aspects, the inject operation 412 injects an authentication error (e.g., an HTTP return code 401 for an authentication fault) in processing a command that includes an authentication of a client at a remote server); injecting, by the computing device, the one or more faults by executing the instrumentation code in the software code as the fault injection (see Nath paragraph [0058], “In aspects, the inject operation 412 may be termed as instrumentation of the SDK to generate a fault-enabled SDK. In some other aspects, the inject operation 412 injects faults in the SDK based on the fault configuration data. For example, when the fault configuration data instructs generating a fault indicating a user authentication in a read data command, the inject operation 412 injects and enables code that generates a user authentication error”); and responsive to the executing of the instrumentation code, generating, by the computing device, an outcome of the fault injection for display (see Nath paragraph [0069], “Transmit operation 528 transmits a result of the API call to the application. For example, when the SDK has its fault test mode ON, the SDK returns an error based on its transport layer generating a fault (e.g., the HTTP status 401) as specified by the fault configuration data. The method 500 ends with the end operation 530”).
Nath does not explicitly teach generating by an agent during runtime, instrumentation code for fault injection. However, Rozenman teaches generating by an agent during runtime, instrumentation code for fault injection (see Rozenman paragraph [0024], “The virtual prototyping tool 300 can include an instrumentation tool 330 to insert verification code or instrumentation code into the compiled embedded software for execution by the computing system”), wherein the instrumentation code is configured to simulate one or more faults (see Rozenman paragraph [0024], “The profile of the embedded software 302, in some embodiments, can help a programmer to ascertain or understand location and magnitude of various execution bottlenecks in the embedded software 302. When the verification code injects a fault into the simulation environment, the verification information 303 can correspond to the execution of the compiled embedded software and/or simulated hardware in response to the injected fault.”)
Nath and Rozenman are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit with Rozenman’s teaching of non-intrusive software verification to incorporate injecting faults code into a simulation environment in order to verify software using non-intrusive tracing techniques, see Rozenman paragraph [0006], “This application discloses a computing system configured to software verification utilizing a non-intrusive tracing technique. The computing system can simulate an embedded system including a processor capable of executing embedded software, compile the embedded software into a format capable of execution by the computing system, insert instrumentation code into the compiled embedded software, and execute the compiled embedded software and the instrumentation code. The execution of the compiled embedded software can simulate execution of the embedded software by the processor in the simulated embedded system, while the execution of the instrumentation code can configure the computing system to gather information corresponding to the execution of the compiled embedded software. Embodiments of non-intrusive software verification are described in greater detail below.”
Nath modified with Rozenman do not explicitly teach the agent inserts the instrumentation code into the software code by using one or more libraries that manipulate bytecode to transform one or more class files of the software code. However, Pistoia teaches the agent inserts the instrumentation code into the software code by using one or more libraries that manipulate bytecode to transform one or more class files of the software code (see Pistoia paragraph [0023], “Javassist (Java programming assistant) is one currently available tool for creating an instrumented version 201 of a Java software program 101. Javassist is a load-time reflective system for Java. It is a class library for editing bytecodes in Java. Javassist enables Java programs to define a new class at runtime and to modify a class file before the JVM (Java virtual machine) loads the class file.”).
Nath Rozenman and Pistoia are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit and Rozenman’s teaching of non-intrusive software verification with Pistoia’s teaching of answering security queries statically based on dynamically determined information to incorporate the use of the Javassist in order to modify class files using class libraries to define new classes at runtime and modifying class files before the virtual machine loads the class files.
As per claim 10, this is the system claim to method claim 1 in which Nath further teaches a memory component; and a processing device coupled to the memory component (see Nath paragraph [0078], “In a basic configuration, the computing device 700 may include at least one processing unit 702 and a system memory 704. Depending on the configuration and type of computing device, the system memory 704 may comprise, but is not limited to, volatile storage (e.g., random access memory), non-volatile storage (e.g., read-only memory), flash memory, or any combination of such memories”). Therefore, it is rejected for the same reasons as above.
As per claim 11, Nath modified with Rozenman and Pistoia teaches wherein the software code corresponds to one or more service provider systems (see Nath paragraph [0024], “A cloud server 130 provides a cloud service to the client application 112 for a user using the client device 102. The network 160 provides network connectivity among the client device 102, the application server 110, and the cloud server 130. The fault-enabled SDK 114 includes an application programming interface 116 (API), a transport layer 118, a network layer 120, a fault log store 122, and a fault configuration data store 124”).
As per claim 12, Nath modified with Rozenman and Pistoia teaches further comprising displaying the outcome of the fault injection via a user interface (see Nath paragraph [0024], “The fault-enabled SDK 114 provides an interface of commands to the client application 112 to use a cloud service (e.g., storing and reading data from a cloud storage service). The API 116 includes a set of commands and/or public methods for the client application 112. The API 116 interfaces the transport layer 118 in the fault-enabled SDK 114. The transport layer 118 processes one or more cloud commands that the client application 112 requests and returns a result of the requested commands”).
As per claim 13, Nath modified with Rozenman and Pistoia teaches wherein the software code is received from a service provider system (see Nath paragraph [0028], “In the normal course of processing requests without a fault, the client application 112 uses the API 116 of the fault-enabled SDK 114 in the application server 110 to place a request to process data in the cloud (e.g., storing data in the cloud storage)”).
As per claim 14, Nath modified with Rozenman and Pistoia teaches wherein the software code includes client libraries (see Nath paragraph [0038], “The fault determiner 144 determines one or more faults to generate (and/or simulate) in the received SDK. In aspects, the fault determiner 144 analyzes code in the received SDK to identify commands and public methods that are available as API 116 to the client application 112 to use. The fault determiner 144 further determines faults associated with respective public methods of the API 116 either by analyzing the binary code of the received SDK or information (e.g., a documentation) associated with the received SDK”).
Claim(s) 2-9 and 11-14 are rejected under 35 U.S.C. 103 as being unpatentable over Nath (US-PGPUB-NO: 2022/0391314 A1), Rozenman (US-PGPUB-NO: 2015/0339214 A1) and Pistoia (US-PGPUB-NO: 2012/0144491 A1), in further view of Kohn (US-PGPUB-NO: 2022/0100591 A1).
As per claim 2, Nath modified with Rozenman and Pistoia do not teach wherein the injecting of the one or more faults is by the agent during runtime. However, Kohn teaches wherein the injecting of the one or more faults is by the agent during runtime (see Kohn paragraph [0033], “FIG. 5 illustrates an example of a method 500 of intra-application messaging that is non-coupled. For illustrative purposes, method 500 will be described with reference to FIG. 1 in the context of a computer system 100 that facilitates intra-application messaging that is non-coupled through byte code injection responsive to annotations scanned and detected in classes that may be loaded at runtime”).
Nath, Rozenman, Pistoia and Kohn are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit, Rozenman’s teaching of non-intrusive software verification and Pistoia’s teaching of answering security queries statically based on dynamically determined information with Kohn’s teaching of annotation-based intra-application non-coupled messaging facilitated by byte-code injection and manipulation to incorporate injecting during runtime faults into source code in order to run customized class loaders to load code from annotations and incorporate transforming using an agent bytecode of bootstrap classes in order to dynamically transform the classes during runtime as opposed to static, see Kohn paragraph [0006], “Upon receipt of the notification, the message router may access its list of consumer objects that have registered for that particular data, and then calls each consumer object's annotated function with the data that was produced. In this way, a consumer class may be annotated to include annotations that cause the computer system to automatically inject byte code into the consumer class. The injected byte code causes the consumer object to register with the message router to subscribe to the specified data, regardless of the source of the data and without using specific interfaces that may fail if altered. Likewise, a producer class may be annotated to include annotations that cause the computer system to automatically inject byte code into the producer class. The injected byte code causes the producer object to notify the message router when the specified data is available, regardless of what other parts of the program code may consume the data and without relying on specific interfaces that may fail if altered”).
As per claim 3, Nath modified with Rozenman, Pistoia and Kohn teaches wherein the injecting of the one or more faults is without recompiling software code (see Kohn paragraph [0020], “The term “byte code injection” may refer to automatically writing byte code into existing byte code that has been compiled from source code and/or automatically modifying the existing byte code”).
Nath, Rozenman, Pistoia and Kohn are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit, Rozenman’s teaching of non-intrusive software verification and Pistoia’s teaching of answering security queries statically based on dynamically determined information with Kohn’s teaching of annotation-based intra-application non-coupled messaging facilitated by byte-code injection and manipulation to incorporate injecting during runtime faults into source code in order to run customized class loaders to load code from annotations, see Kohn paragraph [0020], “The term “byte code injection” may refer to automatically writing byte code into existing byte code that has been compiled from source code and/or automatically modifying the existing byte code. Byte code injection may therefore add or otherwise modify functionality of byte code compiled from source code, which may be written by a user such as a software developer. In this way, byte code injection as used herein may automatically facilitate intra-application messaging that is non-coupled without the source code having to define or use interfaces to provide or consume data produced by a producer object”).
As per claim 4, Nath modified with Rozenman, Pistoia and Kohn n teaches wherein the instrumentation code is generated based at least in part on annotations included in the software code (see Kohn paragraph [0025], “When an annotation is identified, the class loader 124 may provide a notification to the byte code injector 126 to inject appropriate byte code into a corresponding class 114 to generate a corresponding modified class 116 (collectively illustrated with other modified classes as modified classes 116A-N)”).
Nath, Rozenman, Pistoia and Kohn are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit, Rozenman’s teaching of non-intrusive software verification and Pistoia’s teaching of answering security queries statically based on dynamically determined information with Kohn’s teaching of annotation-based intra-application non-coupled messaging facilitated by byte-code injection and manipulation to incorporate injecting during runtime faults into source code in order to run customized class loaders to load code from annotations, see Kohn paragraph [0006], “Upon receipt of the notification, the message router may access its list of consumer objects that have registered for that particular data, and then calls each consumer object's annotated function with the data that was produced. In this way, a consumer class may be annotated to include annotations that cause the computer system to automatically inject byte code into the consumer class. The injected byte code causes the consumer object to register with the message router to subscribe to the specified data, regardless of the source of the data and without using specific interfaces that may fail if altered. Likewise, a producer class may be annotated to include annotations that cause the computer system to automatically inject byte code into the producer class. The injected byte code causes the producer object to notify the message router when the specified data is available, regardless of what other parts of the program code may consume the data and without relying on specific interfaces that may fail if altered”).
As per claim 5, Nath modified with Rozenman, Pistoia and Kohn teaches wherein the agent identifies a parameter corresponding to the one or more fault configuration settings (see Nath paragraph [0074], “Parameters and a syntax used by the REST API are based on HTTP and XML-based data in a text format. Accordingly, injecting faults includes adding the simulated fault in the code of the transport layer and replace the normal version of the transport layer with the fault-enabled transport layer. Code associated with other layers (e.g., API and the network layer) remain the same”) and the instrumentation code includes a portion of code and the portion of code replaces a value of the parameter during runtime (see Kohn paragraph [0025], “At runtime, to execute a computer program, the class loader 124 may access a plurality of classes 114 associated with the computer program and load the classes for execution. For example, the class loader 124 may load the plurality of classes 114 to a JVM for execution by the JVM. In association with loading the plurality of classes 114, the class loader 124 may scan each class of the plurality of classes 114 for an annotation. When an annotation is identified, the class loader 124 may provide a notification to the byte code injector 126 to inject appropriate byte code into a corresponding class 114 to generate a corresponding modified class 116 (collectively illustrated with other modified classes as modified classes 116A-N). Further details of byte code injection will be discussed later with reference to FIGS. 3 and 4. The message router 128 may use the injected byte code of a modified class 116 to recognize and match producer objects and consumer objects so that consumer objects are provided with data, specified in the annotations, from producer objects that produce the specified data. Further details of such provision of data will be described later with reference to FIG. 6”).
Nath, Rozenman, Pistoia and Kohn are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit, Rozenman’s teaching of non-intrusive software verification and Pistoia’s teaching of answering security queries statically based on dynamically determined information with Kohn’s teaching of annotation-based intra-application non-coupled messaging facilitated by byte-code injection and manipulation to incorporate injecting during runtime faults into source code in order to run customized class loaders to load code from annotations, see Kohn paragraph [0006], “Upon receipt of the notification, the message router may access its list of consumer objects that have registered for that particular data, and then calls each consumer object's annotated function with the data that was produced. In this way, a consumer class may be annotated to include annotations that cause the computer system to automatically inject byte code into the consumer class. The injected byte code causes the consumer object to register with the message router to subscribe to the specified data, regardless of the source of the data and without using specific interfaces that may fail if altered. Likewise, a producer class may be annotated to include annotations that cause the computer system to automatically inject byte code into the producer class. The injected byte code causes the producer object to notify the message router when the specified data is available, regardless of what other parts of the program code may consume the data and without relying on specific interfaces that may fail if altered”).
As per claim 6, Nath modified with Rozenman, Pistoia and Kohn teaches wherein the agent is a JAVA agent (see Kohn paragraph [0021], “The computer system 100 may include a compiler 122, a class loader 124, a byte code injector 126, a message router 128, and/or other components. The computer system 100 may provide a runtime environment 120 for which one or more components of the computer system 100 may operate. Examples described herein will refer to a JAVA runtime environment as an example of the runtime environment 120”).
Nath, Rozenman, Pistoia and Kohn are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit, Rozenman’s teaching of non-intrusive software verification and Pistoia’s teaching of answering security queries statically based on dynamically determined information with Kohn’s teaching of annotation-based intra-application non-coupled messaging facilitated by byte-code injection and manipulation to incorporate injecting during runtime faults into source code in order to run customized class loaders to load code from annotations, see Kohn paragraph [0021], “Examples described herein will refer to a JAVA runtime environment as an example of the runtime environment 120. For example, the computer program may be a JAVA Virtual Machine (“JVM”) compliant computer program being executed from within a first running JVM instance. An annotation may be metadata included in source code. In JAVA, an annotation may be indicated by an “@” symbol along with one or more annotation fields. The annotation can be used on different aspects of JAVA source code depending upon its definition, such as methods (functions), fields (variables), classes, etc. The JVM is an abstraction of a computer that uses JAVA as well as machine-specific microprocessor (such as x86 Intel Core i7) assembly language, and acts as an interpreter between them. A class loader is a part of the JAVA runtime environment that locates a specific class at run-time, loads the class into the JVM's memory, and readies it for use.”).
As per claim 7, Nath modified with Rozenman, Pistoia and Kohn teaches wherein the outcome of the fault injection includes a resilience of a system corresponding to the software code (see Nath paragraph [0020], “As applications interact with services across the network (e.g., cloud services), maintaining resilience of an application has become an issue because testing becomes complex. Many faults (or failures) may occur outside the control of the application. Application developers often do not know with accuracy all the types of faults that the application needs to expect and to process in a graceful and effectual manner”).
As per claim 8, Nath modified with Rozenman, Pistoia and Kohn teaches wherein generating the instrumentation code includes using a customized class loader (see Kohn paragraph [0025], “At runtime, to execute a computer program, the class loader 124 may access a plurality of classes 114 associated with the computer program and load the classes for execution. For example, the class loader 124 may load the plurality of classes 114 to a JVM for execution by the JVM. In association with loading the plurality of classes 114, the class loader 124 may scan each class of the plurality of classes 114 for an annotation. When an annotation is identified, the class loader 124 may provide a notification to the byte code injector 126 to inject appropriate byte code into a corresponding class 114 to generate a corresponding modified class 116 (collectively illustrated with other modified classes as modified classes 116A-N)”).
Nath, Rozenman, Pistoia and Kohn are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit, Rozenman’s teaching of non-intrusive software verification and Pistoia’s teaching of answering security queries statically based on dynamically determined information with Kohn’s teaching of annotation-based intra-application non-coupled messaging facilitated by byte-code injection and manipulation to incorporate injecting during runtime faults into source code in order to run customized class loaders to load code from annotations, see Kohn paragraph [0006], “Upon receipt of the notification, the message router may access its list of consumer objects that have registered for that particular data, and then calls each consumer object's annotated function with the data that was produced. In this way, a consumer class may be annotated to include annotations that cause the computer system to automatically inject byte code into the consumer class. The injected byte code causes the consumer object to register with the message router to subscribe to the specified data, regardless of the source of the data and without using specific interfaces that may fail if altered. Likewise, a producer class may be annotated to include annotations that cause the computer system to automatically inject byte code into the producer class. The injected byte code causes the producer object to notify the message router when the specified data is available, regardless of what other parts of the program code may consume the data and without relying on specific interfaces that may fail if altered”).
As per claim 9, Nath modified with Rozenman, Pistoia and Kohn teaches wherein generating the instrumentation code includes instrumenting class files of client libraries corresponding to the software code (see Kohn paragraph [0024], “The compiler 122 may compile source code files 110 into corresponding classes 114 (illustrated as classes 114A-N). For example, the compiler 122 may compile source code of each source code file 110 into byte code stored in corresponding classes 114. Each class 114 may be stored as a class file in a storage device of or accessible to the computer system 100. For example, a class file may be stored as a “.jar” class file. Each class 114 may be used to instantiate corresponding objects (not illustrated) that perform functions defined by the class 114, which was compiled from a source code file 110. Examples of source code files 110 and their contents (including annotations that facilitate non-coupled intra-application messaging) will be discussed later with reference to FIGS. 2A and 2B below”) and (see Nath paragraph [0038], “The fault determiner 144 determines one or more faults to generate (and/or simulate) in the received SDK. In aspects, the fault determiner 144 analyzes code in the received SDK to identify commands and public methods that are available as API 116 to the client application 112 to use. The fault determiner 144 further determines faults associated with respective public methods of the API 116 either by analyzing the binary code of the received SDK or information (e.g., a documentation) associated with the received SDK”).
Nath, Rozenman, Pistoia and Kohn are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit, Rozenman’s teaching of non-intrusive software verification and Pistoia’s teaching of answering security queries statically based on dynamically determined information with Kohn’s teaching of annotation-based intra-application non-coupled messaging facilitated by byte-code injection and manipulation to incorporate injecting during runtime faults into source code in order to run customized class loaders to load code from annotations, see Kohn paragraph [0006], “Upon receipt of the notification, the message router may access its list of consumer objects that have registered for that particular data, and then calls each consumer object's annotated function with the data that was produced. In this way, a consumer class may be annotated to include annotations that cause the computer system to automatically inject byte code into the consumer class. The injected byte code causes the consumer object to register with the message router to subscribe to the specified data, regardless of the source of the data and without using specific interfaces that may fail if altered. Likewise, a producer class may be annotated to include annotations that cause the computer system to automatically inject byte code into the producer class. The injected byte code causes the producer object to notify the message router when the specified data is available, regardless of what other parts of the program code may consume the data and without relying on specific interfaces that may fail if altered”).
Claim(s) 16 is rejected under 35 U.S.C. 103 as being unpatentable over Nath (US-PGPUB-NO: 2022/0391314 A1), Rozenman (US-PGPUB-NO: 2015/0339214 A1) and Pistoia (US-PGPUB-NO: 2012/0144491 A1), in further view of Abuelela et al. (US-PGPUB-NO: 2022/0100599 A1) hereinafter Abuelela.
As per claim 16, Nath modified with Rozenman and Pistoia do not explicitly teach wherein the one or more parameters correspond to pre-specified instrumentation patterns, and wherein the instrumentation patterns include at least one of: blocking method logic of the software code, interrupting the method logic of the software code, changing a state of one or more parameters of the software code, or replacing one or more values of the one or more parameters of the software code. However, Abuelela teaches wherein the one or more parameters correspond to pre-specified instrumentation patterns (see Abuelela paragraph [0050], “This container could be pre-provisioned with an event-driven, serverless computing platform, which can execute the package or container in response to receiving a notification of an event occurring. Such platforms may be referred to as “function as a service (FaaS)” platforms (e.g., AMAZON AWS LAMBDA, GOOGLE CLOUD FUNCTIONS, MICROSOFT AZURE FUNCTIONS, APACHE OPENWHISK, etc.). An example of an event that could serve as a trigger for execution of the code could be initiation or completion of the test 156”), in which the instrumentation patterns include at least one of blocking method logic of the software code, interrupting the method logic of the software code, changing a state of one or more parameters of the software code (see Abuelela paragraph [0070], “In another example, the fault instruction 159 could instruct the hypervisor 126 to modify the run-time state of the specified virtual compute instances 116. For example, the fault instruction 159 could specify that the hypervisor 126 is to shutdown, poweroff, or terminate the specified virtual compute instance 116. Similarly, the fault instruction 159 could specify that the hypervisor 126 is to reboot the specified virtual compute instance 116”), or replacing one or more values of the one or more parameters of the software code.
Nath, Rozenman, Pistoia and Abuelela are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit, Rozenman’s teaching of non-intrusive software verification and Pistoia’s teaching of answering security queries statically based on dynamically determined information with Abuelela’s teaching of a device configured to receive a fault instruction specifying a fault to inject into one or more service request sent to a service, parameters for the fault, and a duration of the fault to incorporate being able to pre-provision an event as to execute and trigger code injections, see Abuelela paragraph [0051], “Executable code could be used as an evaluation criterion 163 for a number of reasons. For example, the executable code could be used in order to access data or platforms outside of the cloud provider network 100. As another example, the executable code could be used in order to evaluate performance metrics that are not captured or recorded by the monitoring service 146. For instance, a test 156 may pass if an operations center responds to a fault in less than a predefined amount of time. Accordingly, executable code could be used to determine whether a member of the operations center undertook some action within the predefined amount of time.”
Claim(s) 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Nath et al. (US-PGPUB-NO: 2022/0391314 A1) hereinafter Nath, in further view of Hulick, JR (US-PGPUB-NO: 2023/0103992 A1) hereinafter Hulick, Rozenman et al. (US-PGPUB-NO: 2015/0339214 A1) hereinafter Rozenman and Pistoia et al. (US-PGPUB-NO: 2012/0144491 A1) hereinafter Pistoia.
As per claim 17, Nath teaches a non-transitory computer-readable storage medium storing executable instructions, which when executed by a processing device, cause the processing device to perform operations comprising: identifying software code (see Nath paragraph [0038], “The fault determiner 144 determines one or more faults to generate (and/or simulate) in the received SDK. In aspects, the fault determiner 144 analyzes code in the received SDK to identify commands and public methods that are available as API 116 to the client application 112 to use”); receiving user input selecting one or more fault configuration settings corresponding to one or more faults for fault injection (see Nath paragraph [0036], “The fault configuration data store 124 includes a set of faults and settings of whether to generate respective failures for testing the client application 112. For example, the fault configuration data may specify whether to generate a failure that results from the 401 error from the cloud server 130”); the instrumentation code configured to simulate the one or more faults corresponding to the one or more fault configuration settings (see Nath paragraph [0058], “Inject operation 412 injects a set of code that generate faults in the SDK. For example, the inject operation 412 injects codes that simulates a fault. The fault may indicate a network disconnect. The code may return a network timeout error to a command that attempts establishing a connection with a remote server. In some other aspects, the inject operation 412 injects an authentication error (e.g., an HTTP return code 401 for an authentication fault) in processing a command that includes an authentication of a client at a remote server); injecting the one or more faults by executing the instrumentation code in the software code as the fault injection (see Nath paragraph [0058], “In aspects, the inject operation 412 may be termed as instrumentation of the SDK to generate a fault-enabled SDK. In some other aspects, the inject operation 412 injects faults in the SDK based on the fault configuration data. For example, when the fault configuration data instructs generating a fault indicating a user authentication in a read data command, the inject operation 412 injects and enables code that generates a user authentication error”); and responsive to the executing of the instrumentation code, generating an outcome of the fault injection for display (see Nath paragraph [0069], “Transmit operation 528 transmits a result of the API call to the application. For example, when the SDK has its fault test mode ON, the SDK returns an error based on its transport layer generating a fault (e.g., the HTTP status 401) as specified by the fault configuration data. The method 500 ends with the end operation 530”).
Nath does not explicitly teach identifying, at runtime via reflection, one or more parameter names of one or more target methods of the software code; based on the one or more fault configuration settings received and the one or more parameter names identified at runtime. However, Hulick teaches identifying, at runtime via reflection, one or more parameter names of one or more target methods of the software code; based on the one or more fault configuration settings received and the one or more parameter names identified at runtime (see Hulick paragraph [0142], “Further, according to the embodiments herein an illustrative apparatus herein may comprise: one or more network interfaces to communicate with a network; a processor coupled to the network interfaces and configured to execute one or more processes; and a memory configured to store a process that is executable by the processor, the process, when executed, configured to: instrument runtime of a software application in a secure environment; detect reflection calls made within the runtime of the software application in the secure environment; determine, from the reflection calls, reflection targets and reflection callers of reflection calls respectively; generate a security policy based on approving one or more of: the reflection calls, the reflection targets, and the reflection callers seen during the runtime of the software application in the secure environment; and share the security policy with local instrumentors of the software application to cause the local instrumentors to enforce the security policy against a local runtime of the software application”).
Nath and Hulick are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit with Hulick’s teaching of a reflection runtime protection and auditing system to incorporate the use of reflectors during runtime and using an instrumentor for enforcing security policies to ensure same and secure software applications, see Hulick paragraph [0015], “According to one or more additional embodiments of the disclosure, another illustrative method herein may comprise: instrumenting, by a process, runtime of a software application; detecting, by the process, a reflection call made within the runtime of the software application; determining, by the process and from the reflection call, a reflection target and a reflection caller; comparing, by the process, the reflection target, the reflection caller, and the reflection call against a security policy; and performing, by the process, one or more mitigation actions on the reflection call in response to a violation of the security policy.”
Nath modified with Hulick do not explicitly teach generating by an agent during runtime, instrumentation code for fault injection. However, Rozenman teaches generating by an agent during runtime, instrumentation code for fault injection (see Rozenman paragraph [0024], “The virtual prototyping tool 300 can include an instrumentation tool 330 to insert verification code or instrumentation code into the compiled embedded software for execution by the computing system”), wherein the instrumentation code is configured to simulate one or more faults (see Rozenman paragraph [0024], “The profile of the embedded software 302, in some embodiments, can help a programmer to ascertain or understand location and magnitude of various execution bottlenecks in the embedded software 302. When the verification code injects a fault into the simulation environment, the verification information 303 can correspond to the execution of the compiled embedded software and/or simulated hardware in response to the injected fault.”)
Nath, Hulick and Rozenman are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit and Hulick’s teaching of a reflection runtime protection and auditing system with Rozenman’s teaching of non-intrusive software verification to incorporate injecting faults code into a simulation environment in order to verify software using non-intrusive tracing techniques, see Rozenman paragraph [0006], “This application discloses a computing system configured to software verification utilizing a non-intrusive tracing technique. The computing system can simulate an embedded system including a processor capable of executing embedded software, compile the embedded software into a format capable of execution by the computing system, insert instrumentation code into the compiled embedded software, and execute the compiled embedded software and the instrumentation code. The execution of the compiled embedded software can simulate execution of the embedded software by the processor in the simulated embedded system, while the execution of the instrumentation code can configure the computing system to gather information corresponding to the execution of the compiled embedded software. Embodiments of non-intrusive software verification are described in greater detail below.”
Nath modified with Hulick and Rozenman do not explicitly teach the agent inserts the instrumentation code into the software code by using one or more libraries that manipulate bytecode to transform one or more class files of the software code. However, Pistoia teaches the agent inserts the instrumentation code into the software code by using one or more libraries that manipulate bytecode to transform one or more class files of the software code (see Pistoia paragraph [0023], “Javassist (Java programming assistant) is one currently available tool for creating an instrumented version 201 of a Java software program 101. Javassist is a load-time reflective system for Java. It is a class library for editing bytecodes in Java. Javassist enables Java programs to define a new class at runtime and to modify a class file before the JVM (Java virtual machine) loads the class file.”).
Nath, Hulick Rozenman and Pistoia are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit, Hulick’s teaching of a reflection runtime protection and auditing system and Rozenman’s teaching of non-intrusive software verification with Pistoia’s teaching of answering security queries statically based on dynamically determined information to incorporate the use of the Javassist in order to modify class files using class libraries to define new classes at runtime and modifying class files before the virtual machine loads the class files.
As per claim 18, Nath modified with Hulick, Rozenman and Pistoia teaches wherein the outcome is a resilience of one or more corresponding applications (see Nath paragraph [0020], “As applications interact with services across the network (e.g., cloud services), maintaining resilience of an application has become an issue because testing becomes complex. Many faults (or failures) may occur outside the control of the application. Application developers often do not know with accuracy all the types of faults that the application needs to expect and to process in a graceful and effectual manner”).
As per claim 19, Nath modified with Hulick, Rozenman and Pistoia teaches wherein one or more fault types of the fault injection include at least one of a timeout, an exception, or a response status code (see Nath paragraph [0048], “In the fault test mode, the fault-enabled SDK 204 generates a fault as if the request to the remote server 220 has failed and returned an error (e.g., HTTP Status Code: 401 {“status”: 401, “message”: “Authentication Error Opening Storage”}). In aspects, the transport layer 210 of the fault-enabled SDK 204 generates the fault (e.g., the 401 error) according to the fault configuration data. The transport layer 210 returns the fault to the network layer 208. The network layer 208 processes the error and further returns a result of executing a command to the API 206. In some other aspects, the network layer 208 generates (and/or simulates) the fault when the fault configuration data specifies the network layer 208 for generating the fault. The API 206 processes the erroneous status from the network layer 208 and returns the error to the application 202”).
Claim(s) 24 is rejected under 35 U.S.C. 103 as being unpatentable over Nath (US-PGPUB-NO: 2022/0391314 A1), Rozenman (US-PGPUB-NO: 2015/0339214 A1) and Pistoia (US-PGPUB-NO: 2012/0144491 A1), in further view of Albot et al. (US-PGPUB-NO: 2012/0216078 A1) hereinafter Albot.
As per claim 24, Nath modified with Rozenman and Pistoia do not explicitly teach wherein injecting the one or more faults is restricted to an application layer of the software code. However, Albot teaches wherein injecting the one or more faults is restricted to an application layer of the software code (see Albot paragraph [0166], “The keyword errinjid is mandatory for all commands except list for which its absence is interpreted as "list all registered injection points". The keywords id, cpu, limit, mode and frequency are valid only with command set. If the command is passthru, the errinjid keyword must be present. The rest of the command line is passed directly to the control function(s) registered to the target error injection points in ASCII format. The keyword errinjctrl uses the system call errinj_ctrl to control the state and parameters of error injection points. Thus, this keyword has the same restrictions as the programming interface. In particular, the subcommand set which uses the subcommands EI_HOOK_SET_* of the system call only work if the target error injection point is disabled, and disabling an error injection point using the subcommand disable reset all the error injection parameters and they need to be re-set before re-enabling the error injection point”).
Nath, Rozenman, Pistoia and Albot are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit, Rozenman’s teaching of non-intrusive software verification and Pistoia’s teaching of answering security queries statically based on dynamically determined information with Albot’s teaching framework for conditionally executing code in an application using conditions in the framework and in the application to incorporate restrictions to error injections in order to have more control over the fault injections.
Claim(s) 25 is rejected under 35 U.S.C. 103 as being unpatentable over Nath (US-PGPUB-NO: 2022/0391314 A1), Rozenman (US-PGPUB-NO: 2015/0339214 A1) and Pistoia (US-PGPUB-NO: 2012/0144491 A1), in further view of Cunico et al. (US-PGPUB-NO: 2019/0108212 A1) hereinafter Cunico.
As per claim 25, Nath modified with Rozenman and Pistoia do not explicitly teach wherein receiving the one or more fault configuration settings comprises displaying, via a user interface of the at least one computing device, selectable fault configuration settings corresponding to a plurality of client libraries, and receiving user input selecting at least one fault configuration setting for at least one client library of the plurality of client libraries. However, Cunico teaches wherein receiving the one or more fault configuration settings comprises displaying, via a user interface of the at least one computing device, selectable fault configuration settings corresponding to a plurality of client libraries, and receiving user input selecting at least one fault configuration setting for at least one client library of the plurality of client libraries (see Cunico paragraph [0087], “FIG. 9 is an exemplary diagram depicting a user interface window that allows a document author to configure the fault injection system. User interface window 900 includes an area for author 300 to select a manual fault-injection assignment or an automatic fault-injection. When the user selects a manual fault-injection, user interface window 900 also allows the user to specify particular fault classes to particular segments. In one embodiment, user interface window 900 displays particular text segments while author 300 assigns the fault classes to the displayed text segments. User interface window 900 also allows author 300 to set priorities for fault-injection on a per-text segment basis. User interface window 900 may also include other selection areas for author 300 to provide parameters to fault injection system 320 as discussed herein”).
Nath, Rozenman, Pistoia and Albot are analogous art because they are in the same field of endeavor of software developments. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Nath’s teaching of generating fault condition using a fault-enabled software development kit, Rozenman’s teaching of non-intrusive software verification and Pistoia’s teaching of answering security queries statically based on dynamically determined information with Cunico’s teaching fault-injecting to incorporate an manual selection of fault parameters for the fault injection for more user control over the faults being injected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Baset et al. (US-PGPUB-NO: 2015/0161025 A1) teaches injecting faults at select execution points of distributed applications.
Tsingauz et al. (US-PGPUB-NO: 2018/0260197 A1) teaches instrumentation desired for a language construct using a dynamic analyzer.
Schmich et al. (US-PGPUB-NO: 2012/0167057 A1) teaches dynamic instrumentation of software code.
Farrell et al. (US-PGPUB-NO: 2013/0246770 A1) teaches controlling operation of a run-time instrumentation facility from a lesser-privileged state.
Rasmussen et al. (US-PGPUB-NO: 2014/0075422 A1) dynamically transforming the bytecode of java virtual machine bootstrap classes.
Southern (US-PGPUB-NO: 2015/0193319 A1) teaches allowing a method of injecting hardware faults into an executing application.
Kohn et al. (US-PGPUB-NO: 2019/006216 A1) teaches persisting values in a computing environment.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LENIN PAULINO whose telephone number is (571)270-1734. The examiner can normally be reached Week 1: Mon-Thu 7:30am - 5:00pm Week 2: Mon-Thu 7:30am - 5:00pm and Fri 7:30am - 4:00pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, 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.
/LENIN PAULINO/Examiner, Art Unit 2197 /BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights