DETAILED ACTION
Claims 1-20 are pending.
The present application is being examined under the pre-AIA first to invent provisions.
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.
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, 2, 6-10, 13-16, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hermanns et al. (US-PGPUB-NO: 2023/0267073 A1) hereinafter Hermanns, in further view of Zen (US-PGPUB-NO: 2007/0198445 A1).
As per claim 1, Hermanns teaches a method, comprising: obtaining a first mapping of a plurality of log event templates, related to one or more log events in one or more software logs, generated by executing a software application on one or more of a plurality of information technology assets of an information technology infrastructure, to respective ones of vector representations of the log event templates (see Hermanns paragraph [0082], “Each training vector V.sub.T consists of four vector components, one for each of the software modules M.sub.j. The vector components for a given software module M.sub.j in different training vectors V.sub.T are weighted relative to each other across the executed test cases T.sub.i. In the present variant, the weighting is performed such that the vector components for a given software module M.sub.j in different training vectors V.sub.T reflectes a amount of log information created by the given software module M.sub.j in different training vectors V.sub.T upon execution of a particular test case T.sub.i relative to an amount of log information created by the given software module M.sub.j in different training vectors V.sub.T upon execution of another test case T.sub.i. The weighting (i.e., the vector components) may be normalized relative to the test case T.sub.i that yielded the largest amount of log information”); obtaining a second mapping of a plurality of test step vector representations, generated using the vector representations of the log event templates, to respective ones of a plurality of test step functions, wherein a given test step vector representation comprises one or more of the vector representations of the log event templates, and wherein the second mapping is generated by analyzing an execution of a plurality of test steps related to the software application in an execution history of the one or more software logs (see Hermanns paragraph [0094], “Initially, the apparatus 300 receives the trained model in step 420. Moreover, in step 422, the apparatus 300 obtains a new release of the software modules M.sub.j that is to be tested. In step 424, the apparatus 300 first determines, per software module M.sub.j, if there is a modification relative to the earlier release. To this end, it is determined if there is any code difference between the two releases of a particular software module M.sub.j (see FIG. 8). For example, the numbers of code lines or the software module sizes may be compared in this context. The result of this determination is a matrix 700, as illustrated in FIG. 9”); wherein the method is performed by at least one processing device comprising a processor coupled to a memory (see Hermanns paragraph [0071], “The apparatus 200 for training the model comprises a processor 202 as well as a memory 204 coupled to the processor 202. The memory 204 stores program code that controls operation of the processor 202 so as carry out the operations involved in data structure generation. The apparatus 200 further comprises an input interface 206 and an output interface 208 as well as a database 210 in which historic log information is stored”).
Hermanns do not explicitly teach in response to obtaining information characterizing a software issue related to the software application: generating one or more test step vector representations of the information characterizing the software issue, using the first mapping; mapping the one or more test step vector representations of the information characterizing the software issue to respective ones of a plurality of test step functions using the second mapping; and automatically generating a test case logic flow to evaluate the software issue related to the software application using the mapped test step functions; wherein the method is performed by at least one processing device comprising a processor coupled to a memory. However, Zen teaches in response to obtaining information characterizing a software issue related to the software application (see Zen paragraph [0025], “Testing analyzer 106 may generate a set of vectors, with each vector representing a corresponding set of failure information for a given test result. Testing analyzer 106 may use some or all of the vectors to train multiple nodes for a self-organizing map (SOM). The SOM may comprise, for example, multiple nodes connected by various node links, arranged to form a structure similar to a topologically organized neural network, for example”): generating one or more test step vector representations of the information characterizing the software issue, using the first mapping (see Zen paragraph [0037], “In various embodiments, TAM 208 may include vector generator 302. Vector generator 302 may be arranged to generate vectors with failure information from test result files 112. Vector generator 302 may take a collection of failing results in the form of test result files 112, and convert them into vectors 312-1-r. Each vector 312-1-r may comprise an abstract representation of the result for which each dimension represents a salient part or characteristic of the result. Vector generator 302 may parse and extract failure information from test result files 112, generate vectors 312-1-r using the extracted failure information, and output vectors 312-1-r to trainer 304”); mapping the one or more test step vector representations of the information characterizing the software issue to respective ones of a plurality of test step functions using the second mapping (see Zen paragraph [0038], “In various embodiments, vectors 312-1-r may have any number of dimensions. In one embodiment, for example, vectors 312-1-r may have four dimensions, to include an exception message, a first call, a last call, and image histogram. The image histogram may comprise a more compact representation of an image extracted from a test result file 112, such as an exception message, for example. The first three dimensions are strings. The image histogram may comprise three 256-element double-floating point arrays. In this case, vectors 312-1-r may have a total of 3 strings plus 768 array elements for a total of 771 dimensions. Vectors 312-1-r may have any number of dimensions, however, as desired for a given implementation”); and automatically generating a test case logic flow to evaluate the software issue related to the software application using the mapped test step functions (see Zen paragraph [0072], “FIG. 5 illustrates one embodiment of a logic flow. FIG. 5 illustrates a logic flow 500. Logic flow 500 may be representative of the operations executed by one or more embodiments described herein, such as testing system 100, processing system 200, testing analyzer 106, and/or TAM 208. As shown in logic flow 500, vectors with failure information may be generated from test result files at block 502. Nodes for a self-organizing map may be trained with multiple vectors at block 504. Vector groups may be formed for multiple nodes with the self-organizing map at block 506. The embodiments are not limited in this context”).
Hermanns and Zen are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date to modify Hermanns’ teaching of software testing using AI to determine a test case by obtaining log information with Zen’s teaching of organizing test results using vectors with failure information from test result files to incorporate generating vectors using log information related to test results for improved classification, see Zen paragraph [0003], “Various embodiments may be generally directed to organizing test results to facilitate, for example, test result analysis. The test results may include multiple test result files having failure information. In one embodiment, for example, a vector may be generated with failure information from each test result file. Some or all of the vectors may be used to train multiple nodes for a self-organizing map. Once the self-organizing map has been trained, vector groups for multiple nodes may be formed with the self-organizing map. The vector groups may be displayed using, for example, a graphic user interface. Other embodiments are described and claimed”.
As per claim 2, Hermanns modified with Zen teaches wherein the first mapping is implemented using a log event template dictionary that is generated by: obtaining one or more software logs generated by executing the software application on one or more of the plurality of information technology assets of the information technology infrastructure (see Hermanns paragraph [0086], “To enhance supervised machine learning the raw log information (see FIG. 2) may in some embodiments be processed before deriving the vector components illustrated in FIG. 5. Processing of the raw log information targets, inter alia, at concentrating the input for the supervised machine learning on logged events that are potentially indicative of software module modifications”); parsing the one or more software logs to generate the plurality of log event templates to represent respective ones of log events in the one or more software logs; and generating the vector representation of the plurality of log event templates (see Hermanns paragraph [0086], “To this end, the individual logged events contained in log information created by a particular software module during a particular test case execution may optionally be parsed and split into a constant event part and a variable event part based on event templates as illustrated in FIG. 7. These event templates are used to identify and process particular events, so that individual logged events can selectively be pruned in case they are held to not be indicative of potential “anomalies””).
As per claim 6, Hermanns modified with Zen teaches wherein the given test step vector representation is generated by aggregating one or more of the vector representations of the log event templates (see Hermanns paragraph [0082], “Each training vector V.sub.T consists of four vector components, one for each of the software modules M.sub.j. The vector components for a given software module M.sub.j in different training vectors V.sub.T are weighted relative to each other across the executed test cases T.sub.i. In the present variant, the weighting is performed such that the vector components for a given software module M.sub.j in different training vectors V.sub.T reflectes a amount of log information created by the given software module M.sub.j in different training vectors V.sub.T upon execution of a particular test case T.sub.i relative to an amount of log information created by the given software module M.sub.j in different training vectors V.sub.T upon execution of another test case T.sub.i. The weighting (i.e., the vector components) may be normalized relative to the test case T.sub.i that yielded the largest amount of log information”).
As per claim 7, Hermanns modified with Zen teaches wherein the generating the one or more test step vector representations of the information characterizing the software issue comprises parsing the information to generate a plurality of log event templates to represent respective ones of log events in the information (see Zen paragraph [0025], “In one embodiment, for example, testing analyzer 106 may parse and extract failure information from one or more test result files 112. Testing analyzer 106 may generate a set of vectors, with each vector representing a corresponding set of failure information for a given test result”); and generating vector representations of the plurality of log event templates, using the first mapping (see Zen paragraph [0025], “Testing analyzer 106 may use some or all of the vectors to train multiple nodes for a self-organizing map (SOM). The SOM may comprise, for example, multiple nodes connected by various node links, arranged to form a structure similar to a topologically organized neural network, for example. Once testing analyzer 106 has trained the SOM, testing analyzer 106 may form one or more vector groups for multiple nodes with the SOM. The vector groups may then be displayed, for example, using a GUI”).
As per claim 8, Hermanns modified with Zen teaches wherein the generating the one or more test step vector representations of the information characterizing the software issue further comprises: identifying one or more additional test step vector representations based on a similarity metric for at least some of the one or more test step vector representations (see Hermanns paragraph [0082], “Each training vector V.sub.T consists of four vector components, one for each of the software modules M.sub.j. The vector components for a given software module M.sub.j in different training vectors V.sub.T are weighted relative to each other across the executed test cases T.sub.i. In the present variant, the weighting is performed such that the vector components for a given software module M.sub.j in different training vectors V.sub.T reflectes a amount of log information created by the given software module M.sub.j in different training vectors V.sub.T upon execution of a particular test case T.sub.i relative to an amount of log information created by the given software module M.sub.j in different training vectors V.sub.T upon execution of another test case T.sub.i. The weighting (i.e., the vector components) may be normalized relative to the test case T.sub.i that yielded the largest amount of log information”), mapping the one or more additional test step vector representations associated with a given test step vector representation of the information to a set of corresponding test step functions and selecting a given test step function from the set of corresponding test step functions for the given test step vector representation of the information (see Hermanns paragraph [0097], “In a further step 426, one or more test cases for testing the new software module release are determined based on the trained model and the input vector V.sub.I as determined in step 424. The result of the correlation in step 426, i.e., has the dimension of the one hot vectors illustrated in FIG. 6 and provides for each test case T.sub.i a numerical value, or weight, indicative of the test case's potential to yield a meaningful response to the specific software module modifications in the new release (i.e., to detect a failure upon test case execution). In some variants, each numerical value ranges between 0 and 1, see the matrix 800 of FIG. 10. The closer the numerical value is to 1, the more suitable the associated test case T.sub.i is for software testing”).
As per claim 9, 10, 13 and 14, these are the apparatus claims to method claims 1, 2, 7 and 8, respectively. Therefore, they are rejected for the same reasons as above.
As per claims 15,16, 19 and 20. These are the non-transitory processor-readable storage medium claims to method claims 1, 2, 7 and 8, respectively. Therefore, they are rejected for the same reasons as above.
Claim(s) 3, 4, 5, 11, 12, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Hermanns (US-PGPUB-NO: 2023/0267073 A1) and Zen (US-PGPUB-NO: 2007/0198445 A1), in further view of Srivatsa et al. (US-PGPUB-NO: 2022/0171670 A1) hereinafter Srivatsa.
As per claim 3, Hermanns modified with Zen do not explicitly teach wherein the parsing the one or more software logs to generate the plurality of log event templates to represent respective ones of log events in the one or more software logs comprises identifying a plurality of log events in the one or more software logs; and for each of the plurality of log events in the one or more software logs, extracting constant portions and converting the extracted constant portions of each of the plurality of log events in the one or more software logs to a given one of a plurality of log event templates. However, Srivatsa teaches wherein the parsing the one or more software logs to generate the plurality of log event templates to represent respective ones of log events in the one or more software logs comprises identifying a plurality of log events in the one or more software logs (see Srivatsa paragraph [0030], “In some embodiments, each log message is parsed into tokens or component word. It is noted that standard tokenization or parsing techniques based on specific symbols or words may not work, since the log messages may be laced with JSON, parenthesis, and other software related event monitoring instrumentation. In order to parses the log messages, the template generation module 132 is bootstrapped with regular expression (regex) processing capabilities. For example, punctuations at beginning and end are detached and added as separate tokens, such as “custom-characterwww.abc.com:8080custom-character” is processed as “custom-character”, “www.abc.com:8080”, “custom-character”. The template generation module 132 may also perform regular expression based type-marking, such as “www.abc.com:8080” is typed marked as “INTERNET_ADDR_WITH_PORT”. The template generation module 132 may also perform sequence regular expression replacement, such as replacing “1 sec” with “NUMBER” and “sec” with “TIME”. The template generation module 132 may also receive from the user interface 138 user defined regular expressions and be configured to perform corresponding parsing operations”); and for each of the plurality of log events in the one or more software logs, extracting constant portions and converting the extracted constant portions of each of the plurality of log events in the one or more software logs to a given one of a plurality of log event templates (see Srivatsa paragraph [0031], “FIG. 2 illustrates corresponding example log messages 211-214 and example templates 221-224. The example templates 221-224 are generated based on (or extracted from) the patterns of the log messages 211-214, respectively. Various portions of the messages 211-214 are identified as variable or static by the log analyzer 100. For example, in the message 211, “error” and “Found log configuration_id:” are identified as static portions of the message 211 and are reproduced in the extracted template 221. On the other hand, the string “TransactionID-AE12345678” and the string “20191016-011111-777-szM1ABab” are identified as variable portions of the message 211 and are replaced by a notation “<*>” in the extracted template 221”).
Hermanns, Zen and Srivatsa are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date to modify Hermanns’ teaching of software testing using AI to determine a test case by obtaining log information and Zen’s teaching of organizing test results using vectors with failure information from test result files with Srivatsa’s teaching of obtaining information and status about a monitoring system by adaptively analyzing log messages generated by the monitoring system to incorporate extracting related and static log messages in order to perform sequence regulation.
As per claim 4, Hermanns modified with Zen and Srivatsa teaches wherein the one or more software logs comprise at least one of: one or more execution logs generated by the execution of the software application; and one or more user logs generated in conjunction with execution of the software application by one or more users (see Srivatsa paragraph [0030], “The template generation module 132 may also perform regular expression based type-marking, such as “www.abc.com:8080” is typed marked as “INTERNET_ADDR_WITH_PORT”. The template generation module 132 may also perform sequence regular expression replacement, such as replacing “1 sec” with “NUMBER” and “sec” with “TIME”. The template generation module 132 may also receive from the user interface 138 user defined regular expressions and be configured to perform corresponding parsing operations”).
As per claim 5, Hermanns modified with Zen and Srivatsa teaches wherein the one or more user logs comprise at least some of the information characterizing the software issue related to the software application (see Srivatsa paragraph [0032], “The template generation module 132 may also identify a variable portion of the log messages 120 as belonging to a particular type. The log analyzer 100 may type-mark that variable portion based on certain known structures in a template. For example, for the message 214, the log analyzer 100 type-mark the variable portion of the message between the static portions “httpExecutor Retry count:” and “Reach maximum allowed retries” as “NUMBER” in the template 224. In some embodiments, the template generation module 132 is configured to identify multiple different types of variables, such as email addresses, IP addresses, time stamps, etc”).
As per claims 11 and 12, these are the apparatus claims to method claims 3 and 4, respectively. Therefore, they are rejected for the same reasons as above.
As per claims 17 and 18, these are the non-transitory processor-readable storage medium to the method claims 3 and 4, respectively. Therefore, they are rejected for the same reasons as above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Paradkar et al. (US-PGPUB-NO: 2022/0060371 A1) teaches fault localization for cloud-native applications.
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