DETAILED ACTION
Claims 1-14 and 16-19, 22 and 23 are pending. Claims 13 and 17 have been amended. Claims 20 and 21 have been cancelled. Claim 22 and 23 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 non-final office action is in response to the applicant’s response received on 02/26/2026, for the final office action mailed on 11/26/2025.
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.
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 02/26/2026 has been entered.
Response to Arguments
Applicant's arguments filed 10/28/2025 with regards to rejection made under 35 U.S.C. § 103 with regards to claims 1 and 10 have been fully considered but are not persuasive.
Applicant argues Kohn does not teach an agent or java instrumentation agent, and the annotation scans and class loaders are not the same as agents, see applicant’s remarks pp. 8-9. Examiner respectfully disagrees as Examiner is interpreting the byte code injector 126 as the agent being used to generate the instrumentation 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).” Furthermore, Kohn goes into further detail regarding the byte code injector in paragraph [0031], “Upon detection of an annotation 210A associated with a class 114A, the class loader 124 may provide an annotation notification to the byte code injector 126. The byte code injector 126 may include injected byte code 330A with class 114A to generate a modified class 116A that includes the injected byte code 330A. For example, the modified class 116A may include the injected byte code 330A in the class's constructor, which directs the modified class 116A, when instantiated into an object instance 118A, to notify the message router 128 whenever data for its annotation field 214A has been updated or is otherwise new, as illustrated in FIG. 4A.”
Applicant's arguments filed 02/26/2026 with regards to rejection made under 35 U.S.C. § 103 for claim 17 have been fully considered but they 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-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 Kohn (US-PGPUB-NO: 2022/0100591 A1).
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 received, generating, by the computing device, in which the instrumentation code is 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, 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 instrumentation code in the software code at least in part by using an agent and transforming one or more class files of the software codes via bytecode manipulation. However, Kohn teaches instrumentation code in the software code at least in part by using an agent and transforming one or more class files of the software codes via bytecode manipulation (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 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 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 2, Nath modified with 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”).
As per claim 3, Nath modified with Kohn teaches wherein the injecting of the one or more faults is without compiling 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 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 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 Kohn teaches wherein the generating of the instrumentation code in the software code at least in part by using the agent is 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 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 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 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 in which 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 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 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 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 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 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 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 Kohn teaches wherein the generating of the instrumentation code in the software 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 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 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 Kohn teaches wherein the generating of the instrumentation code in the software 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 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 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 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 Kohn 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 Kohn 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 Kohn 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 Kohn 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”).
Nath 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 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) and Kohn (US-PGPUB-NO: 2022/0100591 A1), in further view of Abuelela et al. (US-PGPUB-NO: 2022/0100599 A1) hereinafter Abuelela.
As per claim 16, Nath modified with Kohn does not explicitly teach wherein the one or more parameters correspond to pre-specified instrumentation patterns, 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, 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, Kohn 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 and Kohn’s teaching of annotation-based intra-application non-coupled messaging facilitated by byte-code injection and manipulation 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 and Kohn (US-PGPUB-NO: 2022/0100591 A1).
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 instrumentation code for insertion into the software code at least in part by using an agent and transforming one or more class files of the software codes via bytecode manipulation. However, Kohn teaches instrumentation code in the software code at least in part by using an agent and transforming one or more class files of the software codes via bytecode manipulation (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, Hulick 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 and Hulick’s teaching of a reflection runtime protection and auditing system 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 18, Nath modified with Hulick and Kohn 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 and Kohn 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) 22 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Nath (US-PGPUB-NO: 2022/0391314 A1) and Kohn (US-PGPUB-NO: 2022/0100591 A1), in further view of Kohn (US-PGPUB-NO: 2019/0065216 A1) hereinafter Kohn 2.
As per claim 22, Nath modified with Kohn teaches wherein the software code includes the one or more class files (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”).
Nath modified with Kohn do not teach wherein the transforming of the one or more class files includes generating a customized class loader to inject the instrumentation code into. However, Kohn 2 teaches wherein the transforming of the one or more class files includes generating a customized class loader to inject the instrumentation code into (see Kohn 2 paragraph [0014], “The specially configured class loader 208 is further configured to write byte code into the class 206 that contains the at least one persistence-annotated field, resulting in a modified class 214 being generated in place of the original class 206. This byte code that is added to the class is configured to cause a first object that is later instantiated from the class 214 to have the persistence-annotated field. As illustrated in FIGS. 2B-2C, a Persistence Manager class 210 is called. The Persistence Manager class 210 contains instructions for injecting byte code 212 into the class 206 to create the modified class”).
Nath, Kohn and Kohn 2 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 Kohn’s teaching of annotation-based intra-application non-coupled messaging facilitated by byte-code injection and manipulation with Kohn 2’s teaching of persisting values in a computing environment to incorporate the use of a specially configured class loader to be able to write byte code into the class that contains at least one persistence-annotated field.
As per claim 23, Nath modified with Kohn and Kohn 2 teaches wherein the one or more class files are client library class files (see Nath paragraph [0037], “The fault-enabled SDK generator 140 generates a fault-enabled SDK based on a given SDK. The fault-enabled SDK generator 140 includes an SDK receiver 142, a fault determiner 144, a fault injector 146, a fault configuration data generator 148, and a fault-enabled SDK transmitter 150. The SDK receiver 142 receives an SDK (and/or a library code). The fault-enabled SDK generator 140 generates a fault-enabled SDK (e.g., the fault-enabled SDK 114) based on the received SDK”).
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.
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