DETAILED ACTION
Claims 1-3, 5, 8-10, 12-16, 18 and 21-23, 25 and 26 are pending.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This final office action is in response to the applicant’s response received on 02/23/2026, for the non-final office action mailed on 09/25/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.
Response to Arguments
Applicant's arguments filed 02/23/2026 regarding rejection made under 35 U.S.C. § 103 have been considered but are not persuasive.
Applicant argues Yalla doesn’t teach "wherein the generative model is established using a plurality of corpuses, each of the plurality of corpuses,” see applicant’s remarks pp. 8-9. Examiner respectfully disagrees as examiner is interpreting Yalla’s historical software data as the plurality of corpuses being claimed by the applicant which is used to train the execution model which is being interpreted as the generative model.
Applicant further argues Yalla doesn’t teach “comprising (i) a respective plurality of test cases to evaluate a respective application and (ii) a respective test package comprising (a) a respective test specification corresponding to execution of the respective plurality of test cases and (b) a respective test script defining execution of the respective plurality of test cases and comprising computer-executable instructions;" or "generating, by the one or more processors, based on providing the model input to the generative model, a test package," see applicant’s remarks pp. 8-9. Examiner respectfully disagrees as Yalla teaches the use of an execution model that processes test cases in order to identify configurations which examiner is interpreting as the test specification and scripts which examiner is interpreting as the test script defining the execution of the respective test cases as taught by Yalla in column 1, lines 42-61. Furthermore, examiner is interpreting Yalla’s execution model as the claimed generative model in which the execution model is an artificial intelligence model which can generate/identify the configurations, scripts and test targets for executing the set of test cases for the software development platform. Furthermore, Yalla teaches in column 8, lines 16-29, “In some implementations, the testing platform may train the execution model, in a manner similar to the neural network model described above in connection with FIG. 1B, to generate the trained execution model. In some implementations, rather than training the execution model, the testing platform may obtain the execution model from another system or device that trained the execution model to generate the trained execution model. In this case, the testing platform may provide the other system or device with the historical test configuration data for use in training the execution model, and may provide the other system or device with updated historical test configuration data to retrain the execution model in order to update the execution model.” Where in the generated trained execution model generates the data needed (i.e., configurations, scripts, test targets) in order to process the sets of test cases.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Yalla et al. (US-PAT-NO: 10,949,337 B1) hereinafter Yalla, in further view of DiJoseph (US-PGPUB-NO: 2003/0159089 A1) and Sluiman et al. (US-PGPUB-NO: 2003/0126586 A1) hereinafter Sluiman.
As per clam 1, Yalla teaches a method of generating test packages to check applications, comprising: receiving, by one or more processors, a test configuration comprising a plurality of test cases to evaluate an application executable on a user device for addressing an indication of a user (see Yalla [column 7, lines 29-34], showing the test configuration data which identifies test cases being received); providing, by the one or more processors, a model input generated using the test configuration to a generative model, wherein the generative model is established using a plurality of corpuses, each of the plurality of corpuses comprising (i) a respective plurality of test cases to evaluate a respective application (see Yalla [column 8, lines 7-8], “In some implementations, the testing platform may train the execution model to process sets of test cases”) and (ii) a respective test package comprising (a) a respective test specification corresponding to execution of the respective plurality of test cases and (b) a respective test script defining execution of the respective plurality of test cases and comprising computer-executable instructions (see Yalla [column 8, lines 9-10], “to identify configurations, scripts, test targets, and/or the like for executing the sets of test cases”); generating, by the one or more processors, based on providing the model input to the generative model, a test package comprising (i) test specification corresponding to execution of a plurality of test cases and (ii) a test script defining execution of the plurality of test cases to evaluate the application (see Yalla [column 9, lines 38-45], “The trained execution model may process the set of test cases to identify configurations, scripts, test targets, and/or the like for executing the set of test cases in the software development platform. In some implementations, the testing platform may provide the set of test cases to the trained execution model in near real-time relative to generating the set of test cases with the trained neural network model”); the test script comprising computer-readable instructions that, when executed, cause the application to be evaluated using at least one of the plurality of test cases and generate a report comprising an expected result for at least one of the plurality of test cases (see Yalla [column 11, lines 55-63], “In some implementations, the one or more actions may include the testing platform configuring software testing tools of the software development platform based on the configurations, and configuring the set of test cases, the scripts, and the test targets for execution based on the configurations. The testing platform may cause the set of test cases to be executed on the test targets, via the software testing tools and based on the scripts, and may provide, for display, results of executing the set of test cases”); executing, by the one or more processors, computer-executable instructions of the test script to evaluate the application in accordance with the test specification (see Yalla [column 9, lines 58-64], showing the execution of test scripts to test software in a software development platform to verify that the software performs as expected).
Yalla does not explicitly teach generating, by the one or more processors, the report comprising the expected result for at least one of the plurality of test cases and an association between one or more requirements of the application to at least one corresponding test case and a result of the test corresponding with the requirement; providing, by the one or more processors, a user interface including at least one of: (i) a user interface to accept the test configuration, (ii) a user interface to generate one or more test packages, (iii) a user interface to select from the one or more test packages for execution, (iv) a user interface to generate outputs using the execution of the one or more test packages, or (v) a user interface to provide a report generated based on the execution of the one or more test packages to a remote device; receiving, by the one or more processors, a response via the user interface; storing, by the one or more processors, a data structure corresponding to the report and the response. However, DiJoseph teaches generating, by the one or more processors, the report comprising the expected result for at least one of the plurality of test cases and an association between one or more requirements of the application to at least one corresponding test case and a result of the test corresponding with the requirement (see DiJoseph paragraph [0036], “In a preferred embodiment, test results repository 26 may be present to contain retrievable test results 26a, and each element 25 in test procedure repository 24 may be linked to at least one requirement 22a in software application requirements repository 22. A form 34, an example of which is shown in FIG. 1b, may be used to define and/or otherwise maintain test scenarios, e.g. actions undertaken in test procedure 25b and a test result expected in response to that action”); providing, by the one or more processors, a user interface including at least one of: (i) a user interface to accept the test configuration, (ii) a user interface to generate one or more test packages, (iii) a user interface to select from the one or more test packages for execution, (iv) a user interface to generate outputs using the execution of the one or more test packages, or (v) a user interface to provide a report generated based on the execution of the one or more test packages to a remote device (see DiJoseph paragraph [0038], “User interface 30 may comprise menus 36, sub-menus, and various controls that are used to value each of the data elements of the system and to initiate execution of processing options such as report generation. Any of the objects of user interface 30 may be modified to accommodate the capture of different data and/or the exercising of new processing features. This allows system 10 to be adapted to a predetermined look and feel and operation required to integrate smoothly with internal testing procedures and standards of the enterprise”); receiving, by the one or more processors, a response via the user interface (see DiJoseph paragraph [0037], “User interface 30 is adaptable to allow the user to customize a predetermined set of system characteristics 12 relating to system 10 and its certification database 20. For example, user interface 30 may comprise user customizable appearance characteristics of graphical interface 32, e.g. colors, content 34 of graphical interface 32, appearance characteristics of menu 36, and content 37 of menu 36”); storing, by the one or more processors, a data structure corresponding to the report and the response (see DiJoseph paragraph [0057], “Referring now to FIG. 3, an executable test application may be created for managing user adaptable test procedures 25b (FIG. 1) and reporting on user adaptable resulting test data 25c (FIG. 1). At step 300, a cross-platform capable user interface 30 (FIG. 1) to database 20 (FIG. 1) may be provided. User interface 30 may be used when customizing a predetermined set of characteristics 12 (FIG. 1) of database 20 relating to test procedure 25b, e.g. stored in database 20, and report 23 (FIG. 1) of test results 26a (FIG. 1). Such a cross-platform user interface 30 may include testing abilities which may be conducted on a plurality of platforms, e.g. it is not integrated with a single platform, such as UNIX or Microsoft.RTM. Windows.RTM., or language such as C++, Visual Basic, Java, or the like”).
Yalla and DiJospeh 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 of the claimed invention to modify Yalla’s teaching of utilizing neural network and AI models to select and execute test cases in a software development platform with DiJospeh’s teaching of creating, storing and using customizable software test procedures to incorporate generation of a report in order to transmit to the user the results from the execution of customized test cases created via a user interface, see DiJoseph paragraph [0011], “In an embodiment of a method, a first test procedure is stored for later use in user assisted testing of a set of functions of an executable application. A test system user may be allowed to customize a predetermined set of system characteristics relating to the stored test procedure. Test data may be acquired and task steps to be performed by the first test procedure may be identified. An executable second test procedure, corresponding to the first test procedure, may be created to automatically exercise a set of functions selected for the executable application. Result data may also be acquired”).
Yalla modified with DiJoseph do not explicitly teach wherein the data structure comprises an association based on the report and the response, the association comprising an identifier corresponding to a second test script or second test package; wherein the test script and second test script are at least one of a same test script or a different test script; and wherein the test package and second test package are at least one of a same test package or a different test package. However, Sluiman teaches wherein the data structure comprises an association based on the report and the response, the association comprising an identifier corresponding to a second test script or second test package; wherein the test script and second test script are at least one of a same test script or a different test script; and wherein the test package and second test package are at least one of a same test package or a different test package (see Sluiman paragraph [0078], “Referencing FIG. 8, a JAVA language implementation of a class which implements the test case association 408 is illustrated. Code portion 802 indicates that invoking the TestcaseAssociation method by providing a parent test case 402/414 and a child test case 402 (FIG. 6) results in a check being performed. The Check is performed to ensure that parent and child test cases 414, 402 are not the same test case. If the parent and child test cases are found to be different test cases, then the association between the child and parent test cases are created by code portion 804 invoking the addChildTestcaseAssociation method in the parent test case 414 and the addParentTestcaseAssociation method in the child test case. Code portions 802 and 804 are used when a test case association 408 is created. A parent association is created in the child test case 402 and a child association is created with reference to the parent test case 402/414. Code portion 716 (FIG. 7) is used to create the "child to parent" addition”).
Yalla, DiJospeh and Sluiman 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 of the claimed invention to modify Yalla’s teaching of utilizing neural network and AI models to select and execute test cases in a software development platform and DiJospeh’s teaching of creating, storing and using customizable software test procedures with Sluiman’s teaching of organization of test cases to incorporate being able to identify a parent and child test case in order to facilitate application testing and maintain organization, see Sluiman paragraph [0016], “Further aspects of the invention, which may be incorporated in some embodiments, include an encapsulated test case which, when associated with other encapsulated test case, results in an explicit tree-like hierarchical structure of test cases being defined. Embodiments incorporating these aspects of the invention enable a many:many relationship between encapsulated test cases. That is, a single encapsulated test case may have many parent encapsulated test cases. Additionally, the same single encapsulated test case may have many children encapsulated test case”).
As per claims 14, these are the system claims to method claims 1. Therefore, they are rejected for the same reasons as above.
Claim(s) 2, 3, 5, 15, 16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Yalla (US-PAT-NO: 10,949,337 B1), DiJoseph (US-PGPUB-NO: 2003/0159089 A1) and Sluiman (US-PGPUB-NO: 2003/0126586 A1), in further view of Blackwell et al. (US-PGPUB-NO: 2005/0166094 A1) hereinafter Blackwell.
As per claim 2, Yalla modified with DiJoseph and Sluiman teaches wherein the test configuration comprises (i) a scenario file defining a condition to test the application and the expected result from the application for at least one of the plurality of test cases (see Yalla [column 7, lines 39-46], showing expected conditions and expected results).
Yalla modified with DiJoseph and Sluiman do not explicitly teach (ii) a traceability table defining an association between a risk control measure and a specification for the application. However, Blackwell teaches (ii) a traceability table defining an association between a risk control measure and a specification for the application (see Blackwell paragraph [0133], showing a traceability matrix that describes the relationships between all components of interest in the complex software system).
Yalla, DiJoseph, Sluiman and Blackwell 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 of the claimed invention to modify Yalla’s teaching of utilizing neural network and AI models to select and execute test cases in a software development platform, DiJospeh’s teaching of creating, storing and using customizable software test procedures and Sluiman’s teaching of organization of test cases with Blackwell’s teaching of a testing tool comprising an automated multidimensional traceability matrix for implementing and validating complex software systems to incorporate the use of a traceability matrix in order to provide a single source into managing test cases and related documentations and an analytical tool to show interrelationships of test case dependencies.
As per claim 3, Yalla modified with DiJoseph, Sluiman and Blackwell teaches wherein the test configuration comprises at least one of: (iii) a specification document comprising a function to be executable by the application, or (iv) a code history comprising a modification to a code for the application (see Yalla [column 4, lines 10-25], showing historical data being used which includes software testing and test results data and software requirements such as modifications and such).
As per claim 5, Yalla modified with DiJoseph, Sluiman and Blackwell teaches wherein generating the test package further comprises generating a test script having computer-executable instructions comprising, for at least one test case of the plurality of test cases (see Blackwell paragraph [0030], showing test scripts being adapted to guide execution of associated test cases for testing software components): (i) a condition for the application (see Blackwell paragraph [0081], showing specified conditions), (ii) a result expected from the application for the respective condition (see Blackwell paragraph [0081], showing the recording of results from the specified conditions), (iii) a criterion against which to determine whether the at least one test case is satisfied (see Blackwell paragraph [0082], showing whether a system satisfies its acceptance criteria during testing), and (iv) a traceability mapping between the at least one test case and a risk control measure (see Blackwell paragraph [0133], showing a traceability matrix that describes the relationships between all components of interest in the complex software system).
As per claim 10, Yalla modified with DiJoseph and Sluiman teaches wherein receiving the test configuration further comprises receiving, via the user interface, a user input defining the plurality of test cases of the test configuration, and further comprising: providing, by the one or more processors, via the user interface, data associated with the test package (see DiJoseph paragraph [0051], “The user may elect to customize, step 210, one or more predetermined system characteristics 12 (FIG. 1) relating to test procedure 25b (FIG. 1), e.g. test procedure 25b stored in database 20 (FIG. 1). Using system characteristics 12 (FIG. 1), system 10 may be modified and adapted to meet requirements 22a (FIG. 1) of executable application 40 under test (FIG. 1), e.g. operating system and/or target language platform requirements, as well as a business' requirements, e.g. level of testing, level of reporting detail, and the like”).
As per claims 15, 16, 18 and 23 these are the system claims to method claims 2, 3, 5 and 10, respectively. Therefore, they are rejected for the same reason as above.
Claim(s) 8, 9, 21 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Yalla (US-PAT-NO: 10,949,337 B1), DiJoseph (US-PGPUB-NO: 2003/0159089 A1) and Sluiman (US-PGPUB-NO: 2003/0126586 A1), in further view of Brown et al. (US-PGPUB-NO: 2012/0266136 A1) hereinafter Brown.
As per claim 8, Yalla modified with DiJoseph and Sluiman do not explicitly teach further comprising receiving, by the one or more processors, via a user interface, a selection of one of approval or rejection of the test script, and wherein executing the computer-executable instructions further comprises executing the computer-executable instructions in response to the selection identifying approval of the test script. However, Brown teaches further comprising receiving, by the one or more processors, via a user interface, a selection of one of approval or rejection of the test script (see Brown paragraph [0032], showing a centralized workflow system for approving and rejecting modules (i.e., scripts)), and wherein executing the computer-executable instructions further comprises executing the computer-executable instructions in response to the selection identifying approval of the test script (see Brown paragraph [0033], showing the approval being conducted and execution the test from the test execution toolbar).
Yalla, DiJospeh, Sluiman and Brown 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 of the claimed invention to modify Yalla’s teaching of utilizing neural network and AI models to select and execute test cases in a software development platform, DiJospeh’s teaching of creating, storing and using customizable software test procedures and Sluiman’s teaching of organization of test cases with Brown’s teaching of modular script designer for next generation testing system to incorporate an approval process for approving test scripts in order to prevent additional work by making sure all test scripts are as intended by the user/client.
As per claim 9, Yalla modified with DiJoseph, Sluiman and Brown teaches further comprising: receiving, by the one or more processors, feedback data identifying a modification to a test script; and updating, by the one or more processors, at least one of a plurality of weights of the generative model using the feedback data (see Brown paragraph [0041], showing a planning tool which provides suggestions for appropriate regression/changes and also see Brown paragraph [0050], showing suggestion of modules for the tester to add to the script).
As per claims 21 and 22, these are the system claims to method claims 8 and 9, respectively. Therefore, they are rejected for the same reasons as above.
Claim(s) 12 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Yalla (US-PAT-NO: 10,949,337 B1), DiJoseph (US-PGPUB-NO: 2003/0159089 A1) and Sluiman (US-PGPUB-NO: 2003/0126586 A1), in further view of Raghavan et al. (US-PGPUB-NO: 2015/0227452 A1) hereinafter Raghavan.
As per claim 12, Yalla modified with DiJoseph and Sluiman do not explicitly teach wherein at least one of the plurality of corpuses includes a mapping between (i) a feature in at least one of (a) a respective scenario file, (b) a respective traceability table, (c) a specification document, or (d) a code history, with (ii) a feature in a respective test script, wherein at least one of the plurality of test cases identifies a risk control measure for the application to be checked. However, Raghavan teaches wherein at least one of the plurality of corpuses includes a mapping between (i) a feature in at least one of (a) a respective scenario file, (b) a respective traceability table, (c) a specification document, or (d) a code history, with (ii) a feature in a respective test script (see Raghavan paragraph [0043], showing the mapping of keywords to actions needed to be conducted in a test script), wherein at least one of the plurality of test cases identifies a risk control measure for the application to be checked (see Raghavan paragraph [0045], showing a risk management module associated with a risk index for each test scenarios).
Yalla, DiJoseph, Sluiman and Raghavan 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 of the claimed invention to modify Yalla’s teaching of utilizing neural network and AI models to select and execute test cases in a software development platform, DiJospeh’s teaching of creating, storing and using customizable software test procedures and Sluiman’s teaching of organization of test cases with Raghavan’s teaching of testing software application to incorporate risk management module to give the user risk ratings for the test scenarios.
As per claim 25, this is the system claim to method claim 12. Therefore, it is rejected for the same reasons as above.
Claim(s) 13 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Yalla (US-PAT-NO: 10,949,337 B1), DiJoseph (US-PGPUB-NO: 2003/0159089 A1) and Sluiman (US-PGPUB-NO: 2003/0126586 A1) in further view of Mann et al. (US-PAT-NO: 10,923,221 B1) hereinafter Mann.
As per claim 13, Yalla modified with DiJospeh and Sluiman do not explicitly teach wherein the user is administered with a medication to address the indication, concurrently with provision of the application. However, Mann teaches wherein the user is administered with a medication to address the indication, concurrently with provision of the application (see Mann [column 6, lines 17-36], showing the user administering medication while using an application).
Yalla, DiJoseph, Sluiman and Mann 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 of the claimed invention to modify Yalla’s teaching of utilizing neural network and AI models to select and execute test cases in a software development platform, DiJospeh’s teaching of creating, storing and using customizable software test procedures and Sluiman’s teaching of organization of test cases with Mann’s teaching of administering medication to incorporate the use of an application to help concurrently administer medication by a user.
As per claim 26, this is the system claim to method claim 13. Therefore, it is 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.
Cohen et al. (US-PGPUB-NO: 2016/0210224 A1) teaches generating a test scenario template from runs of test scenarios belonging to different organizations.
Lawrance et al. (US-PGPUB-NO: 2013/0055029 A1) teaches automated test case generation and scheduling.
Subramanian Rajalakshmi et al. (US-PGPUB-NO: 2021/0390037 A1) teaches test case generation for software development using machine learning.
West (US-PGPUB-NO: 2021/0279577 A1) teaches testing computer processes using artificial intelligence.
Holden (US-PGPUB-NO: 2016/0103748 A1) teaches test case execution.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LENIN PAULINO whose telephone number is (571)270-1734. The examiner can normally be reached Week 1: Mon-Thu 7:30am - 5:00pm Week 2: Mon-Thu 7:30am - 5:00pm and Fri 7:30am - 4:00pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached on (571) 272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/LENIN PAULINO/Examiner, Art Unit 2197 /BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights