DETAILED ACTION
This action is in response to the claims filed July 30, 2024. Claims 1-6 are pending. Claims 1, 5, and 6 are independent claims.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 5 and 6 are objected to because of the following informalities:
- Claim 5 recites “the test system configured to”. This should likely read “the software test system configured to” as is consistent with the first half of the claim.
- Claim 6 recites “A non-transitory computer-readable medium”. This should likely read “A non-transitory computer-readable storage medium”.
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “A software test system configured to test a computer program, the test system configured to…” in claim 5.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-6 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites “the predicted coverage” on lines 14 and 17-18. It is unclear whether “the predicted coverage” refers to the coverage predicted in the training step as described in the first limitation of the claim, or the coverage predicted in the “using the trained machine learning model” step as described in the third limitation of the claim. For the purposes of examination, “the predicted coverage” is interpreted to refer to the coverage predicted by using the trained machine learning model as described in the third limitation. The same rejection applies to the analogous limitations of claim 5 and claim 6.
Claims 2-4 are rejected in view of their dependency on claim 1.
Claim 4 recites “the predicted coverage” on lines 5-6. It is unclear whether “the predicted coverage” refers to the coverage predicted in the training step as described in the first limitation of claim 1, or the coverage predicted in the “using the trained machine learning model” step as described in the third limitation of claim 1. For the purposes of examination, “the predicted coverage” is interpreted to refer to the coverage predicted by using the trained machine learning model as described in the third limitation of claim 1.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5, and 6 are rejected under 35 U.S.C. 103 as being unpatentable over “Improving Grey-Box Fuzzing by Modeling Program Behavior” by Karamcheti et. al (hereinafter “Karamcheti”), in view of US 20240403198 A1 (hereinafter “Chandel”).
Regarding claim 1, Karamcheti discloses:
A method for testing a computer program, the method comprising the following steps (Abstract, “Grey-box fuzzers such as American Fuzzy Lop (AFL) are popular tools for finding bugs and potential vulnerabilities in programs. … Here, we present an approach to increase the efficiency of fuzzers like AFL by applying machine learning to directly model how programs behave.”):
…
- testing the computer program in a plurality of iterations, wherein in each iteration a test input is generated (Page 1, “These fuzzers work by maintaining a queue of interesting program inputs, or “parents”, that cover different parts of the program, and mutating them iteratively, with a set of stochastic mutation functions (e.g. flip bits, delete bits, insert random bits, etc.) to generate new “children” inputs. These children are then fed to a version of the program that has been lightly instrumented to trace the execution for a given input. If the input takes a path through the program that has not been observed before, it is added to the queue”) [Examiner’s remarks: There is a plurality of iterations to test the code (mutating iteratively), wherein in each iteration, a new input is generated via mutation.];
…
- ascertaining whether the predicted coverage increases an overall coverage previously achieved by testing the computer program (Page 1, “These fuzzers work by maintaining a queue of interesting program inputs, or “parents”, that cover different parts of the program, and mutating them iteratively, with a set of stochastic mutation functions (e.g. flip bits, delete bits, insert random bits, etc.) to generate new “children” inputs. These children are then fed to a version of the program that has been lightly instrumented to trace the execution for a given input. If the input takes a path through the program that has not been observed before, it is added to the queue”; Page 2, “While there are many ways to approach this modeling problem, in this work, we focus on learning forward prediction models: given an input, predict the corresponding execution path through the program. If we had a perfect execution model, we could simply skip inputs that lead to execution paths we have already seen, saving significant time. Our approach, described below, is based on the heuristic that the less confident our model is in the execution path it predicts for a given input, the more likely that input is to lead to an execution path that we have never seen before”) [Examiner’s remarks: The testing program ascertains whether the input directs the code through a path that has not previously been observed. If code traverses a new path, then code coverage has increased. Therefore, the program is able to ascertain, using predictions about code execution path, whether code coverage has increased as compared to previous inputs.]; and
- in response to ascertaining that the predicted coverage increases the overall coverage previously achieved by testing the computer program, executing the computer program with the generated test input (Page 2, “While there are many ways to approach this modeling problem, in this work, we focus on learning forward prediction models: given an input, predict the corresponding execution path through the program. If we had a perfect execution model, we could simply skip inputs that lead to execution paths we have already seen, saving significant time. Our approach, described below, is based on the heuristic that the less confident our model is in the execution path it predicts for a given input, the more likely that input is to lead to an execution path that we have never seen before”; Page 2-3, “At a high level, our approach is to repeatedly perform the following steps: 1) Use AFL to generate some number of possible children inputs, 2) Feed these inputs through our model to predict distributions over execution paths, 3) Rank these generated inputs by the confidence in the predictions, 4) Execute some fraction of those ranked inputs that we are the least confident about, and 5) Use the executed inputs to retrain our path prediction model”; Page 3, “As a measure of uncertainty, we use the entropy of the predicted distribution over execution paths, with high entropy referring to high uncertainty, and low entropy referring to low uncertainty. …With this formula, we then score each generated input in the batch, for the given iteration. Then we rank them by their entropy (highest- lowest). Finally, we select a fraction α of the highest entropy inputs to execute. A full breakdown of the process can be found in Algorithm 1”) [Examiner’s remarks: Based on the model predicting an execution path and certainty used as a heuristic for predicted code coverage, and comparing the predicted code coverage to previous code coverage, the program may execute only the test cases with high entropy (predicted to more likely increase code coverage).].
Karamcheti does not explicitly disclose:
- training a machine learning model to predict, for each test input supplied to the machine learning model, a coverage of the computer program that is achieved when the computer program;
…
- using the trained machine learning model to predict a coverage of the computer program that is achieved when the computer program is executed with the generated test input as input;
However, Chandel more explicitly discloses:
- training a machine learning model to predict, for each test input supplied to the machine learning model, a coverage of the computer program that is achieved when the computer program is executed with the test input as inputs (Paragraph [0025], “The code coverage prediction model 102 is a large language model trained to predict a sequence of code coverage symbols 110 given a focal method m, 112, and a test case t, 114”) [Examiner’s remarks: Karamcheti discloses a method for indirect prediction of code coverage using code path prediction and a level of confidence without directly executing the code. Chandel discloses a method of direct prediction of code coverage without code execution. One of ordinary skill in the art understands that the indirect model of Karamcheti may be replaced with the model of Chandel to achieve similar end goals of predicted code coverage.];
…
- using the trained machine learning model to predict a coverage of the computer program that is achieved when the computer program is executed with the generated test input as input (Paragraph [0004], “A code coverage prediction system utilizes a neural transformer model with attention to generate a sequence of code coverage symbols given a focal method and a test case. The code coverage symbols indicate whether a line of source code is covered by the test case, missed by the test case or unreachable. The sequence of coverage symbols is aligned with the focal method to produce a coverage-annotated focal method that associates a predicted coverage symbol with each line of source code in the focal method”) [Examiner’s remarks: Karamcheti discloses a method for indirect prediction of code coverage using code path prediction and a level of confidence without directly executing the code. Chandel discloses a method of direct prediction of code coverage without code execution. One of ordinary skill in the art understands that the indirect model of Karamcheti may be replaced with the model of Chandel to achieve similar end goals of predicted code coverage. The method of Chandel may also predict using a machine learning model, code coverage using test input (test case). One of ordinary skill in the art understands that a generic test case may be replaced with the specific test case generated in the method of Karamcheti];
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Chandel into the teachings of Karamcheti to include “training a machine learning model to predict, for each test input supplied to the machine learning model, a coverage of the computer program that is achieved when the computer program” and “using the trained machine learning model to predict a coverage of the computer program that is achieved when the computer program is executed with the generated test input as input”. As stated in Chandel, “Code coverage is a metric widely-used to estimate the quality of the testing of the software. Code coverage measures which program elements, such as statements or branches, have been executed by a set of test cases. A higher percentage of program elements covered by the test cases is indicative of a high-quality test case and a lower risk of software bugs residing in the program” (Paragraph [0001]). However, traditional methods of determining code coverage “is expensive for large software projects where a considerable amount of computing resources and time is needed to instrument, build and execute the program. It is not always possible to build and execute the program for a small portion of the source code when the entire program is not available”. Allowing for determination of code coverage without code execution saves time and resources in the process of code testing. Therefore, it would be obvious to one of ordinary skill in the art to combine coverage driven fuzz testing with machine learning prediction of code coverage.
Regarding claim 2, the rejection of claim 1 is incorporated; and Karamcheti further disclose:
- wherein, in each iteration, the test input is generated from a different test input depending on whether the coverage predicted by the trained machine learning model for the different test input increases the overall coverage achieved by the testing prior to executing the computer program with the different test input as input (Figure 1 (Attached below), The input queue is used to generate inputs for the prediction model, which generates an entropy score and path used as a predicted code coverage. The inputs are then added to the queue if they increase code coverage for the next round of mutations. Page 1, “These fuzzers work by maintaining a queue of interesting program inputs, or “parents”, that cover different parts of the program, and mutating them iteratively, with a set of stochastic mutation functions (e.g. flip bits, delete bits, insert random bits, etc.) to generate new “children” inputs. These children are then fed to a version of the program that has been lightly instrumented to trace the execution for a given input. If the input takes a path through the program that has not been observed before, it is added to the queue”; Page 2, “While there are many ways to approach this modeling problem, in this work, we focus on learning forward prediction models: given an input, predict the corresponding execution path through the program. If we had a perfect execution model, we could simply skip inputs that lead to execution paths we have already seen, saving significant time. Our approach, described below, is based on the heuristic that the less confident our model is in the execution path it predicts for a given input, the more likely that input is to lead to an execution path that we have never seen before”; Page 2-3, “At a high level, our approach is to repeatedly perform the following steps: 1) Use AFL to generate some number of possible children inputs, 2) Feed these inputs through our model to predict distributions over execution paths, 3) Rank these generated inputs by the confidence in the predictions, 4) Execute some fraction of those ranked inputs that we are the least confident about, and 5) Use the executed inputs to retrain our path prediction model”) [Examiner’s remarks: Each generated input has a predicted execution path and confidence level used as a stand in for code coverage. When the code coverage of the input is higher than the code coverage of the previous inputs, the input is added into the input queue for the next round of test generation. Therefore, the test input is generated on a previous test input depending on whether the coverage prediction indicated the previous test input had higher coverage.].
PNG
media_image1.png
497
1242
media_image1.png
Greyscale
Regarding claim 3, the rejection of claim 1 is incorporated; and Karamcheti further discloses:
- checking whether executing the computer program with the generated test input has increased the overall coverage achieved during testing of the computer program (Page 1, “These fuzzers work by maintaining a queue of interesting program inputs, or “parents”, that cover different parts of the program, and mutating them iteratively, with a set of stochastic mutation functions (e.g. flip bits, delete bits, insert random bits, etc.) to generate new “children” inputs. These children are then fed to a version of the program that has been lightly instrumented to trace the execution for a given input. If the input takes a path through the program that has not been observed before, it is added to the queue”) [Examiner’s remarks: A generated (children) input is traced to determine if it takes a novel path. If it takes a path that previous tests did not take, then code coverage has increased. ]; and
- in response to the execution of the computer program with the generated test input having increased the overall coverage achieved during testing of the computer program, adding the generated test input to a set of test inputs from which test inputs for further iterations are generated (Page 1, “These fuzzers work by maintaining a queue of interesting program inputs, or “parents”, that cover different parts of the program, and mutating them iteratively, with a set of stochastic mutation functions (e.g. flip bits, delete bits, insert random bits, etc.) to generate new “children” inputs. These children are then fed to a version of the program that has been lightly instrumented to trace the execution for a given input. If the input takes a path through the program that has not been observed before, it is added to the queue”) [Examiner’s remarks: When a test input takes the code through a new path (increased code coverage), the test is added to a queue (set of inputs) for later iterations of mutations.].
Claim 5 is a system claim corresponding to the method claim hereinabove (claim 1). Therefore, claim 5 is rejected for the same reasons as recited in the rejection of claim 1.
Claim 6 is a non-transitory computer-readable medium claim corresponding to the method claim hereinabove (claim 1). Therefore, claim 6 is rejected for the same reasons as recited in the rejection of claim 1.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over “Improving Grey-Box Fuzzing by Modeling Program Behavior” by Karamcheti et. al (hereinafter “Karamcheti”), in view of US 20240403198 A1 (hereinafter “Chandel”), and further in view of “Coverage-Guided Fuzzing of Embedded Systems Leveraging Hardware Tracing” by Beckmann and Steffan (hereinafter “Beckmann”).
Regarding claim 4, the rejection of claim 1 is incorporated; and Karamcheti further discloses:
- generating the test input on a test system (Page 1, “These fuzzers work by maintaining a queue of interesting program inputs, or “parents”, that cover different parts of the program, and mutating them iteratively, with a set of stochastic mutation functions (e.g. flip bits, delete bits, insert random bits, etc.) to generate new “children” inputs. These children are then fed to a version of the program that has been lightly instrumented to trace the execution for a given input. If the input takes a path through the program that has not been observed before, it is added to the queue”) [Examiner’s remarks: A test input is generated in the system via mutations.];
- ascertaining the coverage of the computer program on the test system (Page 1, “These fuzzers work by maintaining a queue of interesting program inputs, or “parents”, that cover different parts of the program, and mutating them iteratively, with a set of stochastic mutation functions (e.g. flip bits, delete bits, insert random bits, etc.) to generate new “children” inputs. These children are then fed to a version of the program that has been lightly instrumented to trace the execution for a given input. If the input takes a path through the program that has not been observed before, it is added to the queue”) [Examiner’s remarks: A code coverage (path through the program) is ascertained.]; and
- in response to the test system ascertaining that the predicted coverage increases the overall coverage previously achieved by testing the computer program, executing the computer program with the generated test input (Page 2, “While there are many ways to approach this modeling problem, in this work, we focus on learning forward prediction models: given an input, predict the corresponding execution path through the program. If we had a perfect execution model, we could simply skip inputs that lead to execution paths we have already seen, saving significant time. Our approach, described below, is based on the heuristic that the less confident our model is in the execution path it predicts for a given input, the more likely that input is to lead to an execution path that we have never seen before”; Page 2-3, “At a high level, our approach is to repeatedly perform the following steps: 1) Use AFL to generate some number of possible children inputs, 2) Feed these inputs through our model to predict distributions over execution paths, 3) Rank these generated inputs by the confidence in the predictions, 4) Execute some fraction of those ranked inputs that we are the least confident about, and 5) Use the executed inputs to retrain our path prediction model”; Page 3, “As a measure of uncertainty, we use the entropy of the predicted distribution over execution paths, with high entropy referring to high uncertainty, and low entropy referring to low uncertainty. …With this formula, we then score each generated input in the batch, for the given iteration. Then we rank them by their entropy (highest- lowest). Finally, we select a fraction α of the highest entropy inputs to execute. A full breakdown of the process can be found in Algorithm 1”) [Examiner’s remarks: Based on the model predicting an execution path and certainty used as a heuristic for predicted code coverage, and comparing the predicted code coverage to previous code coverage, the program may execute only the test cases with high entropy (predicted to more likely increase code coverage).]…
The combination of Karamcheti and Chandel does not explicitly disclose:
… on a system embedded with the test system.
However, Beckmann discloses:
… on a system embedded with the test system (Abstract, “We explore the use of hardware tracing interfaces integrated into many modern microcontroller units (MCUs), as an alternative feedback channel for coverage-guided fuzzing which requires practically no setup effort or changes to the target system. In contrast to related work, we use the single wire output (SWO) interface, which is frequently available in the widely used ARM Cortex-M product line”, Page 366, “Preparation of the target. The application is set up for testing. If the MCU has not already been started, it is powered up and allowed to execute its initialization routine. Then, peripherals are set up and the control flow enters an event loop, usually performing periodic tasks or waiting for events requiring further action. At this point, the application is ready to accept input data. … Execution of the test case. The test input is supplied to the peripheral inter face and processed by the tested application. Simultaneously, it is monitored for output data. The end of a test run is determined by either exceeding a time limit or receiving an expected output value”) [Examiner’s remarks: Beckmann discloses fuzz testing on an embedded system embedded within a test system including host and peripheries in order to test the embedded system.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Beckmann into the combined teachings of Karamcheti and Chandel to include “… on a system embedded with the test system”. As stated in Beckmann, “In addition to the high exposure and security impact, rolling out security updates to embedded systems in the field in many cases is complicated, if possible at all. Therefore, it is necessary to identify security vulnerabilities in embedded systems before deployment” (Page 363). Embedded systems are frequently used and require testing to ensure that they are able to complete a variety of tasks that are increasingly important. Therefore, it would be obvious to one of ordinary skill in the art to combine fuzz testing with a system embedded in the test system.
Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
- “JQF: Coverage-Guided Property-Based Testing in Java” by Padhye et. al discloses fuzz testing based on code coverage determined through instrumentation.
- US 20210056009 A1 discloses a method of testing wherein tests are determined based on coverage events.
- US 20220100640 A1 discloses using test coverage analysis to generate test inputs for testing components.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIVIAN WEIJIA DUAN whose telephone number is (703)756-5442. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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, Wei Y Mui can be reached at (571) 272-3708. 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.
/V.W.D./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights